On 22 April 2003, Ned Konz wrote:
> The problem is this, for the record:
> 
> gcc 3.2 has gotten much cleverer with optimization.
> 
> The AC_C_DOUBLE_ORDER test from Ian's aclocal.m4 is this:
> 
> main(){ double d= 1.0; return *(int *)&d == 0;}
> 
> However, with the default -O2 optimization flag, this program returns 
> 0, which makes the ac_cv_double_order="yes", which is wrong. Without 
> the -O2, this program returns 1.
> 
> I *think* the configure program could/should use something like this:
> 
> int main(void)
> {
> 	union { double d; int i[ sizeof(double) / sizeof(int) ]; } d;
> 	d.d = 1.0;
> 	return d.i[0] == 0;
> }
> 
> which seems to work right (for me, anyway) with and without 
> optimization.
> 
> The attached patch to acinclude.m4 should work. Though it should of 
> course be tested by people on different platforms.
> 
> You have to apply it to platforms/unix/config/acinclude.m4, and then 
> run "make" in that directory first.

That's quite the same, I wrote a month ago. I got a message, that Ian
already incorporated my patch, but it has not appeared on his UNIX web
site since then, I think.

Lars


On 17 March 2003, Lars Dornheim wrote:
> Hi,
> 
> there has been a open problem with all GCC 3.x on Linux x86 for quite a
> long time. If you run configure the double order is not determined
> correctly. So you still have to set
> 
> #define DOUBLE_WORD_ORDER 1
> 
> manually in the automatically created config.h. Otherwise Squeak will
> produce later a lot of float errors and break down quickly.
> 
> Responsible for the detection of the double order is the
> AC_C_DOUBLE_ORDER macro used in the configure script. This macro is
> defined in acinclude.m4. It tries to detect the double order using the
> following test program:
> 
> main()
>      {
>      double d = 1.0;
>      return *(int*)&d == 0;
>      }
> 
> If you compile it with "gcc -g -O2" as it is normal within configure
> scripts on Linux, the program does not yield the desired results when
> using GCC 3.x. This is because of the "-O2" optimizing option, which
> seems to have a different behavior since GCC 3.0. The reason seems to be
> a mix of options that -O2 stands for. If you, for example, provide
> "-fno-strict-aliasing" or "-fno-schedule-insns2" in addition to "-O2",
> then the result is the originally intended. But only providing the two
> complementary options without "-O2" is not enough to reproduce the
> strange behavior that "-O2" alone leads to.
> 
> However, the problem follows from the double*-to-int*-cast, because a
> pointer to an 8-byte-value is cast to a 4-byte-value. Such a cast has
> actually no defined behavior. So the result can change at different
> optimization levels.
> 
> By means of an union struct one can perform the double order test in a
> consistent way. You just have to replace the test program from above by
> the following in the AC_C_DOUBLE_ORDER macro definition in acinclude.m4:
> 
> 
> main()
>      {
>      union
>           {
>           double d;
>           int i;
>           } u;
>      u.d = 1.0;
>      return u.i == 0;
>      }
> 
> 
> I have tested it and it seems to work fine on Linux 2.4.20 and Solaris
> 2.8 with GCC 2.95.3 and GCC 3.2. Does it work generally or could there
> appear any problems? If not, it would be nice, if Ian could incorporate
> this change into the current UNIX Squeak source distros.
> 
> Lars
>