Re: Linux and aliasing?

[Toon Moene <toon@moene.indiv.nluug.nl>]

Andi Kleen wrote:

> On Sat, Jun 05, 1999 at 02:37:20PM +0200, I wrote:

> > Ah, yes, but the discussion is whether we should have gcc generate
> > "reasonable" behaviour where "reasonable" is defined by a small group of
> > users.  Note that all "behaviours" not explicitly required by the
> > Standard are prone to:

> Generating faulty code is in my book always unreasonable, even when
> the source is not strictly conforming (and the compiler has a realistic
> chance to detect it).

Be careful to not run in circles here:  gcc generates "some" code that's
allowed because the construct invokes `undefined behaviour'.  That
doesn't make it "faulty" - just undefined.

> The argument that it may inhibit some optimizations for strictly conforming
> programs I also cannot follow. As I understand it there are basically two
> cases:

It does if you have to apply a compiler option to prevent this
optimisation - because in that case the optimisation will be prevented
for the whole compilation unit (a source file)

> > 1. Erosion (within a decade, gcc maintainers forget why we did this in
> >    the first place: "Hey, look at this code - what hair - and it is
> >    undefined behaviour according to the Standard in the first place;
> >    rip it out")

> If it is clearly documented that will not happen.

Yeah, sure.  Unfortunately, if the "correct" treatment of this feature
means to change a dozen source files (and rth's comments make me fear
that that's the case), the chance that someone, somewhere forgets to say
exactly why these changes were necessary (and on what other changes in
other files they depend) is far larger than I want to consider.  We've
seen this before.  Lucky we are that some long time gcc-hackers are
still among us, who might remark:  Oh yes, that's undefined by the C
Standard, but it happens to be an extension gcc supports ...  Seen that,
got the T-shirt.

> > 2. Contradiction (the C0X Standard defines the previously undefined
> >    behaviour, but in a way incompatible with the "reasonable" behaviour
> >    we thought up here).
> 
> I don't think that such a vague possibility should guide a gcc design
> decision ("in 30 years an asteroid may crash onto earth and ruin your
> whole day - don't implement it because the exception handlers don't handle
> that event") Also there is no cue in the future directions that that may
> happen. In any case it wouldn't strike me as a strong enough argument
> to suppress a useful feature.

If you think so, bring it up in comp.std.c.  At least that's the
ultimate criterium I use:  If I can explain an extension to the Fortran
Standard coherently on comp.lang.fortran (where all the J3 members
listen in), and no-one shoots it down in two weeks time, it might indeed
have some value.

Success !

[No, there's no smiley here - I really think you should try that route,
 because it's the only sane way.]

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html