Bug 146755
| Summary: | Result differs by no-option and optimization option. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | L3support <linux-sid> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. |
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