To answer upstream's question: yes, compiling that one particular input
file (radmul.f) with -ffloat-store causes all the problems (with both
g77-3.3 and g77-3.4) to go away.
However I don't see this as a real solution, only a workaround:
> `-ffloat-store' tries to remove the extra precision by
On 01/16/2005 11:39 AM, Matthias Klose wrote:
> Please could you subscribe to the upstream report?
Done.
> using the current g77-3.4 from unstable, I cannot reproduce the
> segfault (you should link with g77-3.4 as well).
I still get a segfault with -O1 under g77-3.4, even when linking with
g77
# submitted Debian report #290438 to gcc-gnats as PR 19469
# http://gcc.gnu.org/PR19469
forwarded 290438 http://gcc.gnu.org/PR19469
retitle 290438 [PR 19469] wrong code on i486 compiling with f77 -fno-automatic
-O1
tags 290438 + upstream
thanks
Please could you subscribe to the upstream report?
Package: g77-3.3
Version: 1:3.3.5-6
Severity: normal
Hi,
I have tracked down a bug report I was sent about libmathlib1 to a
compiler optimization problem in g77 on i386. Please see the attached
file for a test case. (Gunzip and un-tar it, cd into the resulting
directory, and run "make" on a sy
4 matches
Mail list logo
