Summary: | wrong code on i486 compiling with f77 -fno-automatic -O1 | ||
---|---|---|---|
Product: | gcc | Reporter: | Debian GCC Maintainers <debian-gcc> |
Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | gcc-bugs, jan.iven, kmccarty |
Priority: | P2 | Keywords: | wrong-code |
Version: | 3.3.6 | ||
Target Milestone: | --- | ||
Host: | i486-linux | Target: | |
Build: | Known to work: | ||
Known to fail: | 2.95.4 3.3.5 3.4.3 | Last reconfirmed: | |
Attachments: | test case |
Description
Debian GCC Maintainers
2005-01-16 16:33:35 UTC
Created attachment 7966 [details]
test case
Hmm, this really sounds like PR 323. (I would have them look at that PR and make sure they try out -ffloat-store. Also since this depends on a library, we really need a self contained example. I still think -ffloat-store will "fix" their problem. If it does then it is a dup of PR 323. g77 -O1 -ffloat-store work for 3.3.4, but not for 3.4.3. Hi, I'm the original submitter of the bug to Debian's BTS. On my system, as you predicted, adding -ffloat-store to the options used in compiling radmul.f to object code solves all the problems with g77 3.3 and 3.4. (I haven't re-tested 2.95.) This includes the g77-3.4 segfault. That is, the executable that has radmul.f compiled with "g77-3.4 -c -O1" segfaults, but with "g77-3.4 -c -O1 -ffloat-store" it exhibits the expected behavior. I will try to have a self-contained test case within a week or so (time permitting) so you can check whether this really is the same thing as PR 323. |