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
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.
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&action=edit
Smaller test case
Here is a smaller test case, which runs for a second only, not hours.
without -march=native:
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&action=edit
Source code, include files, and inputs
Hi,
I encountered the problem in versio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621
--- Comment #3 from Jan Lachnitt 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=gfortran
COLLECT_LTO_WRAPP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621
--- Comment #1 from Jan Lachnitt 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
Bug #: 52621
Summary: ICE when compiling Fortran77 code with optimization
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
--- 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
(V
--- 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
--- Comment #115 from pepalogik at seznam dot cz 2008-06-22 17:28 ---
That ® should be (R).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- 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 dou
--- 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 *pr
--- 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 CPU
--- 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&#
14 matches
Mail list logo
