Bug 146755 - Result differs by no-option and optimization option.
Result differs by no-option and optimization option.
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2005-02-01 06:49 EST by L3support
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-06 14:28:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description L3support 2005-02-01 06:49:22 EST
Description of problem:

We compiled with the following case.
1) no-option
2) optimization option

Result differs by no-option and optimization option.

We know our code compiled is invalid.

But we think result doesn't differ 
by option and optimization option.
(not concerned with whether the code is invalid)

We think gcc includes bug not discovered yet.
Or it is not a problem whether the result is different ?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. compile with no/optimization option
   our code(test001.c/test002.c).
2. compare result
Actual results:
Result differs.

Expected results:
Result does not differ.

Additional info:
#include <string.h>

int main(){
  char *calloc();
$ gcc test001.c
test001.c: In function `main':
test001.c:4: warning: conflicting types for built-in function 'calloc'
$ gcc -O2 test001.c
test001.c: In function `main':
test001.c:4: error: conflicting types for 'calloc'

#include <string.h>

extern  char *strchr( );

int main(){
$ gcc test002.c
$ gcc -O2 test002.c
test002.c:3:23: macro "strchr" requires 2 arguments, but only 1 given
test002.c:3: error: 'strchr' redeclared as different kind of symbol
test002.c:3: error: 'strchr' redeclared as different kind of symbol
Comment 1 Jay Turner 2005-02-03 07:57:02 EST
I suspect this is nothing more than the side-effect of the optimization.

Neither of these pieces of code is valid, so I'm not sure that it's safe to
assume that you're going to get the same results with and without optimization
when you're starting with invalid code.
Comment 2 Jakub Jelinek 2005-02-06 14:28:25 EST
test001.c differs between -O0 and -O2, because unlike -std=c89 or -std=c99
and other strict namespace modes, the default one (and a couple of others)
allows (but does not mandate) parts of stdlib.h to be included in string.h.
Whether it is included or not is an implementation detail and in this case
depends on optimizations (stdlib.h is included for malloc/calloc for the strdup
inline optimization).  So, if you want the same result in this case, use
-std=c89 or -std=c99 where stdlib.h must not be included by string.h.

test002.c is different - the standard allows strchr to be a macro when you
#include <string.h>, but doesn't mandate it.  If you want to do what the
test is doing, you must #undef strchr first, and if you fail to do that,
anything can happen.

Note You need to log in before you can comment on or make changes to this bug.