On Mon, 5 Mar 2007, Camm Maguire wrote:
| Greetings!
|
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > On Fri, 2 Mar 2007, Camm Maguire wrote:
| >
| > | > | C99 language semantics now assume that pointers to different types
| > | > | point to different memory locations, which is obvious nonsense, but
| > | > | part of the new standard.
| > | >
| > | > That statement is obviously untrue.
| > | >
| > | > The non-aliasing rule, which has always been there since I don't know
| > | > when -- certainly, it is part of C89, and it is not a C99 invention --
| > | > says that the following is undefined behaviour
| > | >
| > | > double z;
| > | > *(long*)&z = 1;
| > | > printf ("%g", z);
| > | >
| > | > That makes perfect sense. Why would you think it is nonsense?
| > | >
| > | > | You might want to add -fno-strict-aliasing option to the GCC command
line.
| > | >
| > | > Instead of papering over the incorrectness, I would suggest to fix it.
| > | >
| > |
| > | Agreed.
| >
| > Interestingly, ECL -- another CL implementation with KCL as
| > grandfather -- invokes GCC explicitly with -fstrict-aliasing, e.g. it
| > is explicitly askign the compiler to exploit aliasing rules, when
| > compiling generated C codes.
| >
|
| Great! Isn't this enabled by -O2 and higher anyway:
Yes, it is in the official release. Some people prefer to mention it
explicitly, in case their vendor have turned it off by default -- I
think that is the case for some *BSD systems.
[...]
| Still can't reproduce any aliasing warnings with gcl 2.6.8pre and gcc
| 4.1.2.
I saw it many times in the past (notably with some GCC-3.3.x compilers).
I upgraded my OS this week-end and my development machine is not
accessible at this time. But, I'll post a build log once I'm
back to normal.
-- Gaby
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
