--- Comment #109 from pepalogik at seznam dot cz 2008-05-20 16:59 ---
I also encountered such problems and was going to report it as a bug in GCC...
But in the GCC bug (not) reporting guide, there is fortunately a link to this
page and here (comment #96) is a link to David Monniaux's
--- Comment #110 from pepalogik at seznam dot cz 2008-06-12 14:14 ---
I used an old version of GCC documentation so I omitted some new processors
with SSE: core2, k8-sse3, opteron-sse3, athlon64-sse3, amdfam10 and barcelona.
I think you can use -march=pentium3 for all Intel's CPUs
--- Comment #112 from pepalogik at seznam dot cz 2008-06-21 22:38 ---
(In reply to comment #111)
Concerning the standards: The x87 FPU does obey the IEEE754-1985 standard,
which *allows* extended precision, and double precision is *available*.
It's true that double *precision
--- Comment #114 from pepalogik at seznam dot cz 2008-06-22 16:59 ---
(In reply to comment #113)
It is available when storing a result to memory.
Yes, but this requires quite a complicated workaround (solution (4) in my
comment #109). So you could say that the IEEE754 double precision
--- Comment #115 from pepalogik at seznam dot cz 2008-06-22 17:28 ---
That #174; should be (R).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #117 from pepalogik at seznam dot cz 2008-06-24 20:12 ---
(In reply to comment #116)
Yes, but this requires quite a complicated workaround (solution (4) in my
comment #109).
The problem is on the compiler side, which could store every result of a cast
--- Comment #22 from pepalogik at seznam dot cz 2008-09-21 15:02 ---
I'm probably not the one who'll find the core of the bug but I'd like to
mention two simple facts:
1: mingw-w64-bin_i686-mingw_20080707 WORKS
2: mingw-w64-bin_x86_64-mingw_20080724 DOESN'T WORK
(Vista64 SP1)
I don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621
Bug #: 52621
Summary: ICE when compiling Fortran77 code with optimization
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621
--- Comment #1 from Jan Lachnitt pepalogik at seznam dot cz 2012-03-19
16:13:22 UTC ---
Created attachment 26921
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26921
Compiler output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621
--- Comment #3 from Jan Lachnitt pepalogik at seznam dot cz 2012-03-21
12:18:59 UTC ---
Thanks for testing and for the link to GFortranBinaries. I have just installed
the very recent unofficial build of gfortran:
Using built-in specs.
COLLECT_GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78611
--- Comment #11 from Jan Lachnitt ---
Thank you all for a rapid investigation of the problem.
Here is a confirmation with the large test case:
jenda@VivoBook ~/Bug reports/gfortran/6/PhSh1 $ gfortran-6 phsh1.f -std=legacy
-I. -march=core-avx-i
Assignee: unassigned at gcc dot gnu.org
Reporter: pepalogik at seznam dot cz
Target Milestone: ---
Created attachment 40199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40199=edit
Source code, include files, and inputs
Hi,
I encountered the problem in version 5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78611
--- Comment #1 from Jan Lachnitt ---
Created attachment 40200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40200=edit
Smaller test case
Here is a smaller test case, which runs for a second only, not hours.
without -march=native:
real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78611
--- Comment #4 from Jan Lachnitt ---
Small test case with -march=core-avx-i:
real0m1.300s
user0m1.296s
sys 0m0.000s
I.e., reproduced.
14 matches
Mail list logo
