This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: finding strict aliasing problems

> I have a few hundred thousand lines of heavily-macroized C code that
> implements the runtime system of Gambit-C, a Scheme->C compiler and
> interpreter.  When compiled with gcc-3.1 of 04/30/2001 on
> alphaev6-unknown-linux-gnu, the runtime behaves differently with and
> without the -fno-strict-aliasing option.  (It also behaves differently
> with and without some other options, but I'm going to start with this
> one.)

For those that took the rigorous language lawyer side in that debate,
note that even an expert programmer like Brad has difficulty getting this
stuff right.  Clearly making no-strict-aliasing the default was a wise
move for 2.95.2.

> I've just read a lot of the mail from 1999 on this issue, looked around
> the FAQ, grepped the info files, blah-blah-blah.  Can anyone offer
> any advice on how to ferret out possible aliasing errors in this code?

For this purpose I'll assume that the reader knows the rules, and is just
looking for ways to scan a lot of code.  You're looking for casts to
pointer types that change something other than a const, volatile, signed
or unsigned tag, where neither the original type nor the new type is
a form of {const,volatile,signed,unsigned} char.  So you need a way to
find and check the casts.  (there are a few ways to violate the aliasing
rules without an actual cast being present, but I think they are very
likely to occur in practice).

First shot: form regular expressions that match things like

(xxxx *)
(xxxx xxxx *)
(xxxx xxx * const)
where none of the xxx's are the word "char".

Eliminate those that are clearly OK, then look at the rest.  If you find
an attempt to access memory as two distinct types and no union is used,
you need to change the code to use a union.

If you go back to the 1999 discussion you'll see people talking about ways
to have the compiler warn about suspicious cases.  This was objected to on
the grounds that the compiler cannot find all violations (at least not
without a lot of false positives).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]