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

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

[Andris Kalnozols]

I've got a bit of a quandry here and would like the advice
of people who are more experienced than I am at C programming
and debugging.

We've got a legacy application that compiles and runs fine
using the following compilers/platforms:

  HP-UX 11.23 (PA-RISC) ANSI-C and aC++ C.11.23.04
  HP-UX 11.31 (ia64)    HP C/aC++ B3910B A.06.23 [May 18, 2009]
  Debian "squeeze" i686 gcc-2.95

Here is some debugging output during a runtime parse
of the application's custom scripting language after
compiling with gcc-2.95:

    'encountered _endif_; leaving gen_if()
    '*cmd->cmd' is '134523664'
    ' cmd->op'  is '200'
    ' flags'    is '0'
    ' pc'       is '200'
    'tokenbuf' is 'endif'
    ' pcptr      '     is '155572084'
    '*pcptr      '     is '0'
    ' pcptr->code'     is '155572068'
    '*pcptr->code'     is '200'
    ' pc'              is '155572068'
    '*pc'              is '200'
    ' pcptr->code->op' is '200'
    calling '[while]parse_cmd' in parse_body
  in parse_cmd():
    'tokenbuf [before tokenize()]' is 'end'
    'tokenbuf  [after tokenize()]' is 'end'
  Database ready 20:53:08

The problem is that gcc-3.X and gcc-4.X compilers generate
code (no matter the optimization level) that fails at
runtime like this:

    'encountered _endif_; leaving gen_if()
    '*cmd->cmd' is '134523035'
    ' cmd->op'  is '200'
    ' flags'    is '0'
    ' pc'       is '200'
    'tokenbuf' is 'endif'
    ' pcptr      '     is '160593780'
    '*pcptr      '     is '0'
    ' pcptr->code'     is '0'
  Segmentation fault

If the bug was a basic programming error, one would expect a
runtime failure (dereferencing a NULL pointer) no matter which
compiler was used.  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?

Thanks,
Andris

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

[Andrew Haley]

[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.

> 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.

Andrew.