| Summary: | Nonconstant expression compiled away? | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jerry James <loganjerry> | ||||
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | jakub | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-01-18 15:49:04 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
Please attach preprocessed source on which this happens and all the gcc options used to compile that file. Guessing from code snippets above is impossible, and I certainly don't have time to download/build/debug all the packages in the distro. Created attachment 555627 [details]
Preprocessed file
The command line is:
gcc -c -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wdeclaration-after-statement -Wunused-parameter -g -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -Demacs -I. -DHAVE_CONFIG_H lread.c
Should be fixed in gcc-4.7.0-0.7.fc17. Yes, I saw that a new gcc was built on Rawhide, and that its Changelog referred to this bug, so I kicked off a new build of XEmacs, which succeeded. Thank you for a quick resolution of this bug. |
Description of problem: I don't know if this is a bug in gcc or in the XEmacs code. Any help you can give me in figuring that out is much appreciated. XEmacs fails to build on x86_64 with GCC 4.7.0, although it builds successfully on i686. I have tracked the build failure down to this code in src/lread.c, lines 2989-92: if (!NILP (s->tail)) XCDR (s->tail) = read0 (readcharfun); else s->head = read0 (readcharfun); I'm not very good with Intel assembly, but a look at the generated code for this function seems to show that this is being compiled down to just the "else" branch; i.e., I don't see any code corresponding to the conditional or to the "then" branch. When this code is executed, either s->head is non-nil and s->tail is nil, or the two pointers are aliases. XEmacs is compiled with -fno-strict-aliasing. Version-Release number of selected component (if applicable): gcc-4.7.0-0.6.fc17.x86_64 How reproducible: Always. Steps to Reproduce: 1. Attempt to rpmbuild the xemacs package. The build will fail. 2. Create a file, say /tmp/test.el, with these contents: "(princ '(1 . 2))". 3. cd ~/rpmbuild/BUILD/xemacs-21.5.31/src 4. gdb ./temacs 5. At the gdb prompt, type "break lread.c:2989". 6. run -nd -no-packages -batch -l /tmp/test.el 7. Observe that s->head and s->tail are equal (use "pobj s->tail" to see the Lisp interpretation of the object), and non-nil. 8. Step forward, and watch the "else" branch be taken. Actual results: The wrong branch of the conditional is taken. Indeed, the correct branch doesn't seem to exist in the object code. Expected results: The correct branch should not be compiled away, and should be taken. Additional info: