Bug 146755

Summary: Result differs by no-option and optimization option.
Product: Red Hat Enterprise Linux 4 Reporter: L3support <linux-sid>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: halligan, jturner
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-06 19:28:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description L3support 2005-02-01 11:49:22 UTC
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):
gcc-3.4.2-6.fc3

How reproducible:
always

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

Expected results:
Result does not differ.

Additional info:
---------------------
[test001.c]
#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'

---------------------
[test002.c]
#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 12:57:02 UTC
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 19:28:25 UTC
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.