https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 33517
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33517action=edit
Here is my spec 2006 patch
I need this patch on x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
--- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Some SPEC benchmarks contain questionable code. It is true for SPEC2000 and
true for SPEC2006. So the PR is not a surprise for me.
Unfortunately, nobody from GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
--- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
common /a/ i(10)
subroutine foo (j)
common /a/ i(1)
Is that valid Fortran at all?
No. Fortran 2008 (in 5.7.2.5) has: Named common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
--- Comment #3 from Carrot carrot at google dot com ---
I don't have a reduced test case. But I have a reduced config file.
###
ext = Linux64
backup_config = 0
makeflags =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
Can you provide a reduced test case?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
--- Comment #1 from Carrot carrot at google dot com ---
I did some more experimentation on this benchmark.
O0/O1 generates correct result, but O2/Os generates wrong result. So the
problem should be in some optimization pass that is enabled in
11 matches
Mail list logo