This is the mail archive of the gcc-help@gcc.gnu.org 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]
Other format: [Raw text]

Re: gcc-2.95 OK, gcc-{3,4}.X not OK


> [redir to gcc-help]
>
> On 01/01/2010 05:44 AM, Andris Kalnozols wrote:
> 
> > If the bug was a basic programming error, one would expect a
> > runtime failure (dereferencing a NULL pointer) no matter which
> > compiler was used.
> 
> I would not expect that, and I have no idea whay you would.  Undefined
> behaviour can happen in any way: maybe the program appears to run
> correctly, maybe it faults.

I stand corrected.  Dumb luck was hiding a programming flaw.

> > The application compiles cleanly with no warnings using "-Wall".
> > Were there any transition issues with the newer gcc compilers of
> > which I may not be aware?
> 
> No.  As you've done the obvious first stage (using -Wall) you now
> should run your program under Valgrind, assuming that it is available
> on your system.

Having already looked at Valgrind a few years ago, I revisited it per
your suggestion and studied its options this time.  With the help of
this website:

  https://computing.llnl.gov/code/memcheck/#deciphering4

the Valgrind application revealed this flaw:

  pcptr = pcptr->code = nop;

"code" can't be reached through "pcptr" if the pointer does not
yet have the proper address.

Since multiple assignments are legal and evaluated from right to left,
one could expect the following to work:

  pcptr->code = pcptr = nop;

It does *not* work, however, using the gcc 3.3 or 4.3 compilers.
To summarize:

  pcptr = pcptr->code = nop;   /* crashes with no compiler warning */
  pcptr->code = pcptr = nop;   /* crashes with the warning:
                                * operation on `pcptr' may be undefined
                                */
  pcptr->code = (pcptr = nop); /* same as above */
  pcptr = nop;  pcptr->code = nop;  /* this works */

FWIW, the HP-UX 11.31 compiler warns/not warns in the same
way but the compiled program is "luckier" at run time.

Perhaps the compiler should regard the above bootstrapping-style
multiple assignments as ambiguous and issue the warning regardless
of the order in which the targets appear.

Valgrind is an awesome tool.

------
Andris


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