--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-10-22 23:08
---
Subject: Bug 33849
Author: jvdelisle
Date: Mon Oct 22 23:08:16 2007
New Revision: 129564
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129564
Log:
2007-10-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-10-22 23:09
---
Fixed
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-10-22 23:10
---
I will work this, maybe a cr-lf issue.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from amylaar at gcc dot gnu dot org 2007-10-22 23:17
---
(In reply to comment #0)
> See http://openmp.org/pipermail/omp/2007/000840.html
> and the rest of the lengthy threads:
> Memory consistency contradiction between 2.5 specification and GCC
> OpenMP spec 2.5 seems to
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-10-23 01:42
---
The example in Comment #8 is rejected by gfortran because of this bug. It is
rejected by Lahey:
Diagnostic messages: program name(main)
2204-S: "SOURCE.F90", line 18, column 6: In the reference to procedure
'
--- Comment #28 from Joey dot ye at intel dot com 2007-10-23 02:23 ---
Got similar result on x86_64, Core 2 improves 24% from 129469 to 129504. That's
great.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #7 from dorit at gcc dot gnu dot org 2007-10-23 03:24 ---
Subject: Bug 33834
Author: dorit
Date: Tue Oct 23 03:24:06 2007
New Revision: 129571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129571
Log:
PR tree-optimization/33834
PR tree-optimization/3
--- Comment #5 from dorit at gcc dot gnu dot org 2007-10-23 03:24 ---
Subject: Bug 33835
Author: dorit
Date: Tue Oct 23 03:24:06 2007
New Revision: 129571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129571
Log:
PR tree-optimization/33834
PR tree-optimization/3
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-10-23 06:09 ---
This is most likely just a latent bug that showed up wth Ollie's patch, looking
into it further.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pault at gcc dot gnu dot org 2007-10-23 06:19 ---
(In reply to comment #11)
> I'm adding Paul to the CC list, as perhaps he immediately knows what's
> happening (Paul, see comment #5). Otherwise I will investigate tomorrow
> evening or Saturday.
I'm pretty permanen
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-23 06:38 ---
So when out of SSA (TER) combines:
iftmp.1D.2042_25 = (derivedD.2000:: *) somemethodD.1996;
# SMT.36D.2106_36 = VDEF { SMT.36D.2106 }
iftmp.1_25 (0B);
It does not change the case where it knows it cannot thr
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-23 06:53 ---
Here is a "semi" undefined case which shows the same issue:
void f(void*) throw();
void somefunction()
{
try {
void (*g)(void*) = (void (*)(void*))f;
void (*g2)(int*) = (void (*)(int*))g;
g2(0);
} catch (.
--- Comment #5 from victork at gcc dot gnu dot org 2007-10-23 06:53 ---
Created an attachment (id=14394)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14394&action=view)
vectorizer dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
--- Comment #6 from victork at gcc dot gnu dot org 2007-10-23 06:57 ---
I think this bug is duplicate of pr31081.
Probably versioning which is done by vectorizer exposes the problem in inliner.
I've attached the vectorizer dump for analysys (pr27549.C.103t.vect)
% gdb --args ./gcc/cc1pl
101 - 114 of 114 matches
Mail list logo
