--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-31 07:50 ---
Subject: Bug 26936
Author: rguenth
Date: Fri Mar 31 07:49:59 2006
New Revision: 112573
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112573
Log:
2006-03-31 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-31 07:50 ---
Subject: Bug 26936
Author: rguenth
Date: Fri Mar 31 07:49:59 2006
New Revision: 112573
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112573
Log:
2006-03-31 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #24 from paolo dot bonzini at lu dot unisi dot ch 2006-03-31
07:37 ---
Subject: Re: [4.1/4.2 Regression] Insane amount
of compile-time / memory needed at -O1 and above
> Note that the regression is in 4.1, too, so we should consider backporting
> changes that accumulate
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-03-31 07:16
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from widman at gimpel dot com 2006-03-31 05:36 ---
Subject: Re: Error diagnostic not issued for unacceptable result of lookup for
a name used in a nested-name-specifier
On Mar 30, 2006, at 11:47 PM, Daveed Vandevoorde wrote:
>
> On Mar 30, 2006, at 4:06 PM, James Widma
--- Comment #5 from rmathew at gcc dot gnu dot org 2006-03-31 05:30 ---
(In reply to comment #4)
>
> I was not intending to modify GCC (as the requirements for modifying it do
> list
> Texinfo). I was intending to compile it. Out of the box compile on my system
> failed, and Ranjit's s
--- Comment #4 from dave at joot dot com 2006-03-31 05:23 ---
The page at http://gcc.gnu.org/install/prerequisites.html under "Tools/packages
necessary for building GCC" does NOT list "Texinfo version 4.4 (or later)" as a
requirement.
I was not intending to modify GCC (as the requiremen
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-03-31 05:15
---
Subject: Bug 26890
Author: jvdelisle
Date: Fri Mar 31 05:15:42 2006
New Revision: 112571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112571
Log:
2006-03-30 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-03-31 05:11
---
Subject: Bug 26890
Author: jvdelisle
Date: Fri Mar 31 05:11:03 2006
New Revision: 112570
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112570
Log:
2006-03-30 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #11 from rmathew at gcc dot gnu dot org 2006-03-31 04:29
---
Created an attachment (id=11172)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11172&action=view)
Shell script to help narrow the problem in PR26879.
Save this file in a folder. Save "debugx" and "debug" fro
--- Comment #3 from rmathew at gcc dot gnu dot org 2006-03-31 03:43 ---
FWIW, I am getting the same error with GCC 3.4.6 and I *do have* GNU Texinfo
4.8.
I have FSF GCC 3.4.5 sources and I downloaded GCC 3.4.6 diffs for "core" and
"g++" - the patches applied successfully, but "make boot
--- Comment #2 from lucier at math dot purdue dot edu 2006-03-31 03:01
---
Subject: Re: Can't compile a 64-bit gcc
I don't know.
Why does 4.2 use libiconv and 4.1 not use it? (I'm presuming that 4.1
doesn't use it because I was able to build a 64-bit gcc on darwin).
Should gcc shi
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-03-31 02:52
---
Jakub --
Sorry about introducing this bug! I'm not sure how best to handle it, but I'll
fix it somehow, if you like. I won't have time to work on it for about a week,
but I'll be happy to handle it then. If you
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-03-31 02:28
---
As Roger says, this not a bug. Roger's analysis is spot on. (For reference,
EDG also rejects this program.)
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from amodra at bigpond dot net dot au 2006-03-31 01:54
---
Fixed
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
URL|
--- Comment #22 from amodra at gcc dot gnu dot org 2006-03-31 01:27 ---
Subject: Bug 26459
Author: amodra
Date: Fri Mar 31 01:27:44 2006
New Revision: 112562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112562
Log:
PR target/26459
* config/rs6000/rs6000.h (CANN
--- Comment #21 from amodra at gcc dot gnu dot org 2006-03-31 01:25 ---
Subject: Bug 26459
Author: amodra
Date: Fri Mar 31 01:25:35 2006
New Revision: 112561
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112561
Log:
PR target/26459
* config/rs6000/rs6000.h (CANN
--- Comment #12 from bdavis at gcc dot gnu dot org 2006-03-31 00:47 ---
Subject: Bug 21130
Author: bdavis
Date: Fri Mar 31 00:47:13 2006
New Revision: 112558
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112558
Log:
2006-03-30 Paul Thomas <[EMAIL PROTECTED]>
Bud Da
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 00:33 ---
I actually don't see why this is a problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26926
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-31 00:32 ---
Well if you read the instructions on how to report a bug, a tar file is not
really liked :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26922
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-31 00:12 ---
This works just fine on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from tausq at debian dot org 2006-03-30 23:52 ---
Created an attachment (id=11171)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11171&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
$ g++ -c bug.cc
bug.cc: In member function 'void
TAO_DynCommon::_ZTv0_n100_N13TAO_DynCommon17insert_longdoubleEN7ACE_CDR10LongDoubleE(CORBA::LongDouble)':
bug.cc:28887: internal compiler error: in make_decl_rtl, at varasm.c:871
Please submit a full bug report,
with preprocessed source if appropriat
--- Comment #3 from widman at gimpel dot com 2006-03-30 23:31 ---
Subject: Re: Error diagnostic not issued for unacceptable result of lookup for
a name used in a nested-name-specifier
On Mar 30, 2006, at 4:06 PM, widman at gimpel dot com wrote:
>
> So when I read that excerpt of 3.4
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 23:18 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 23:17 ---
Even in the sources from today I cannot reproduce this so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from roger at eyesopen dot com 2006-03-30 23:01 ---
This has now been fixed on mainline, and I've also checked that the
extra load mentioned in comment #1 is now also resolved.
--
roger at eyesopen dot com changed:
What|Removed |Adde
--- Comment #2 from sayle at gcc dot gnu dot org 2006-03-30 22:38 ---
Subject: Bug 22375
Author: sayle
Date: Thu Mar 30 22:37:55 2006
New Revision: 112547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112547
Log:
PR middle-end/22375
* trans.c (gfc_trans_runtime
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-03-30 22:25
---
Note that the patch for 23855 will only help for invariant conditions in the
loop header, while the problem exists also for non-invariant ones. So, as
Danny notes, SCEV should be improved to maybe handle this case
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-03-30 22:24
---
Yes, probably - though that patch doesn't apply anymore and wasn't reviewed
either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-30 22:18
---
*** Bug 26878 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-30 22:18 ---
*** This bug has been marked as a duplicate of 26879 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-30 22:16 ---
Won't this get fixed by the patch which patches loop header copy for PR 23855?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-30 22:16 ---
Related to / dup of PR22568. Meta-bug ifcvt sucks. Or cmov sucks on the P4 -
whatever you like ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-30 22:12 ---
It also works for combined CST < CST1 or CST2, i.e.
a +- c1 CMP b +- c2 to a CMP b +- c3 where c3 < c2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-03-30 22:08
---
4.1.x is broken for i686-darwin other ways so this is not to be fixed for
there.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 22:07 ---
This is not a bug with GCC but Darwin does not have the static libraries for
libc or even crt0.o for -static compiling.
You cannot compile with -static on Darwin.
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.1
http://
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 22:04 ---
Conditional move is not always faster.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-03-30 22:04
---
Can someone confirm this issue is now fixed on trunk? I'd then apply the patch
to 4.1 as well.
And Erik, btw, the assign_2.f90 failure is PR25765.
--
fxcoudert at gcc dot gnu dot org changed:
Wha
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-30 22:01 ---
3.4.x is no longer being updated, can you try 4.0.x or 4.1.0?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 22:00 ---
#pragma GCC visibility push(hidden)
struct __attribute__ ((visibility ("default"))) nsINIParser
{
static void Init();
};
__attribute__ ((visibility ("default")))
void
CheckCompatibility(void)
{
nsINIParser::Ini
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-03-30 22:00
---
Subject: Bug 26712
Author: fxcoudert
Date: Thu Mar 30 22:00:21 2006
New Revision: 112546
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112546
Log:
PR libfortran/26712
* config/fpu-387.h:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 21:53 ---
Note it works correctly without the inline-asm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 21:49 ---
Confirmed, only when CST1 == CST2 does this work based on:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01746.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 21:46 ---
ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested
architecture
ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested
architecture
I don't think there is anything GCC can d
--- Comment #3 from roger at eyesopen dot com 2006-03-30 21:35 ---
This is now be fixed on mainline. With -mpowerpc64, we now generate:
_div16:
rldimi 3,4,0,32
srdi 4,3,4
srdi 3,3,36
blr
--
roger at eyesopen dot com changed:
What|Rem
--- Comment #2 from roger at eyesopen dot com 2006-03-30 21:24 ---
This should now be fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #38 from quanah at stanford dot edu 2006-03-30 21:18 ---
Yeah, I'll give that a shot next week (i'm now in a freeze period).
I've also been poking at MPFR. There are apparently 10 or more patches now for
2.2.0, that may resolve the issues, too. I'll look at that. I've reb
--- Comment #3 from mbland at google dot com 2006-03-30 21:09 ---
Right, I've got a mainline patch now, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26857
--- Comment #2 from widman at gimpel dot com 2006-03-30 21:06 ---
Subject: Error diagnostic not issued for unacceptable result of lookup for a
name used in a nested-name-specifier
On Mar 30, 2006, at 2:56 PM, Daveed Vandevoorde wrote:
> Hi James,
>
> On Mar 30, 2006, at 2:31 PM, Jam
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|trivial |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26877
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 20:12 ---
Confirmed, just a note, all patches need to go on the mainline before even
thinking about being backported. (Yes I know how long the copyright issues are
because I am trying to get my fixed up too).
--
pinskia a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26853
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:09 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:04 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:02 ---
Hmm, Comeau C++ does not reject this code either (but that does not mean this
is not invalid code).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-30 19:59 ---
I am starting to think we should change a[outofbounds] = 1 to be an
__builtin_trap() so that we will not run into stuff like this again.
Also we should have a keyword for ice-on-undefined-code too :).
--
pinskia
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 19:57 ---
This has nothing to do with -fprofile-use and all to do with
-freorder-blocks-and-partition
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-30 19:55 ---
*** Bug 26940 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 19:55 ---
This is actually invalid code which the C++ standard says implementions don't
have to error out about.
*** This bug has been marked as a duplicate of 17353 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #9 from zerocool at modemsoft dot it 2006-03-30 19:31 ---
Hello Mathew,
i have tried to perform your indications, but without success; with a lot of
probability because of my little competence in matter. I would pray you,
considering that I have posted the build complete lo
--- Comment #8 from zerocool at modemsoft dot it 2006-03-30 19:28 ---
Created an attachment (id=11169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11169&action=view)
The Gcc Build Log
It's My build log...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
The following should elicit an error during processing of e0's initializer:
namespace N {
const int a = 42;
enum N { e0 = N::a };
}
... because 3.4.3p1 [basic.lookup.qual] indicates that the enumeration [tag]
name N should be found during lookup in the nested-name-specifier and renders
t
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2006-03-30 18:48
---
> From the GMP 4.2 NEWS file:
>
> Mis-features:
> * mpfr is gone, and will from now on be released only separately. Please
> see
> www.mpfr.org.
Grumpf... Could you downgrade to 4.1.x then?
--
ht
Compiling the code in PR26944 with -O2 -march=pentium4 -fno-tree-ch
generates this for the loop:
.L3:
movl%esi, -4(%eax)
addl$1, %edx
addl$4, %eax
cmpl-16(%ebp), %edx <- note an extra memory access here
jle .L3
compiling for -march=i
--- Comment #1 from micis at gmx dot de 2006-03-30 18:13 ---
Created an attachment (id=11168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11168&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
With the actual snapshot (gcc-4.2-20060325) I get the ICE: tree check:
expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466
Michael Cieslinski
g++42f -O1 -msse2 -mfpmath=sse -ftree-vectorize -c in.ii -S -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configure
--- Comment #36 from quanah at stanford dot edu 2006-03-30 17:48 ---
Just to note, if I haven't already, I was able to build gcc 4.0.3 with GMP 4.2
and MPFR 2.2.0 on i386 and amd64 without a problem (including fortran), so this
seems to be a problem specific to Solaris 8/9.
--
http:
--- Comment #2 from sayle at gcc dot gnu dot org 2006-03-30 17:47 ---
Subject: Bug 17959
Author: sayle
Date: Thu Mar 30 17:47:48 2006
New Revision: 112543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112543
Log:
PR target/17959
* expr.c (emit_group_store): Op
--- Comment #35 from quanah at stanford dot edu 2006-03-30 17:40 ---
>From the GMP 4.2 NEWS file:
Mis-features:
* mpfr is gone, and will from now on be released only separately. Please see
www.mpfr.org.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2006-03-30 17:35
---
> Program received signal SIGSEGV, Segmentation fault.
> 0x0035c398 in mpfr_set_default_prec ()
> (gdb) bt
> #0 0x0035c398 in mpfr_set_default_prec ()
OK. Could you ditch MPFR 2.2.0 entirely and use the MPFR l
--- Comment #33 from quanah at stanford dot edu 2006-03-30 17:17 ---
GDB shows:
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condit
--- Comment #14 from law at redhat dot com 2006-03-30 17:15 ---
Just a note on the compile-time regressions for tramp3d...
After fixing the timevars it was pretty clear that it isn't the cprop code
itself that is slow, it is in fact very fast. THe slowdowns for tramp3d are in
operand s
--- Comment #32 from quanah at stanford dot edu 2006-03-30 17:10 ---
Okay, I created the following file (as is generated by the script):
solaris8-build:/tmp> cat /tmp/q1.f90
integer (kind=1) :: x
end
Then ran the build command on it as is done by the script:
/afs/ir.stanford.edu/
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2006-03-30 16:52
---
> No errors or anything... It just spits out the broken bits.
OK. Could you then break apart the script and run the various pieces manually?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-30 16:49 ---
I checked the fix into the 4.1 branch and the trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #30 from quanah at stanford dot edu 2006-03-30 16:48 ---
Here is what happens when I run it by hand:
solaris8-build:/afs/ir/src/pubsw/languages/gcc-build/sun4x_58/sparc-sun-solaris2.8/libgfortran>
/bin/ksh ../../../../gcc-4.0.3/libgfortran/mk-sik-inc.sh
'/afs/ir.stanford.edu
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-30 16:47 ---
Subject: Bug 26042
Author: tromey
Date: Thu Mar 30 16:47:23 2006
New Revision: 112541
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112541
Log:
gcc/java
PR java/26042:
* parse.y (java_reorde
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-03-30
16:43 ---
(In reply to comment #1)
> Note that this may be also PRE confusing SCEV in presence of loop headers.
Talking about PRE, here's a maybe interesting observation in the PRE dump:
:;
pretmp.30_53 = Int_L
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-30 16:39 ---
Subject: Bug 26042
Author: tromey
Date: Thu Mar 30 16:39:17 2006
New Revision: 112540
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112540
Log:
gcc/java
PR java/26042:
* parse.y (java_reorde
--- Comment #2 from tausq at debian dot org 2006-03-30 16:31 ---
The code is valid syntactically, but there is actually a bug. the longoptions
array only has 3 elements, but we try to fill in 4 entries. if we make the
longoptions array bigger than it doesn't cause the ICE.
--
http:/
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-03-30 16:30 ---
Subject: Bug 25031
Author: tkoenig
Date: Thu Mar 30 16:30:26 2006
New Revision: 112539
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112539
Log:
2006-03-30 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #1 from tausq at debian dot org 2006-03-30 16:28 ---
Created an attachment (id=11167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11167&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
Compile attached test case with optimization causes an ICE:
$ gcc -c -O1 bug.c
bug.c: In function 'parsearguments':
bug.c:46: error: Attempt to delete prologue/epilogue insn:
(insn/f 97 96 98 0 (set (mem:SI (plus:SI (reg/f:SI 30 %r30)
(const_int -124 [0xff84])) [0 S4 A32])
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-30 16:25 ---
Note that this may be also PRE confusing SCEV in presence of loop headers.
I.e. a sort of dup of PR26939. Confirmed though. A regression from 4.0.3,
which is also fine.
--
rguenth at gcc dot gnu dot org change
--- Comment #8 from schnetter at aei dot mpg dot de 2006-03-30 16:18
---
I had the same problem. I replaced this file, ran the test cases, and sent the
results. The summary is
=== gfortran Summary ===
# of expected passes12636
# of unexpected failures
The loop from the code below is compiled to this when using gcc-4.1 -O2
.L5:
movl16(%ebp), %eax
addl%ecx, %eax
addl$1, %ecx
movl%edx, 20(%ebx,%eax,4)
leal(%edx,%ecx), %eax
cmpl%edi, %eax
jle .L5
but the code is much
--- Comment #1 from rth at gcc dot gnu dot org 2006-03-30 15:56 ---
Created an attachment (id=11166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11166&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
Two problems here. The first was trying to show that we don't necessarily
honor
the requirement that all firstprivate copies are executed before the
lastprivate
assignment happens. The second is that we're not properly substituting for the
global X here within the scope of the privatization.
--
--- Comment #32 from mckinlay at redhat dot com 2006-03-30 15:51 ---
(In reply to comment #31)
Yes, this patch should fix all the OpenOffice issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-03-30 15:49
---
Note that the regression is in 4.1, too, so we should consider backporting
changes that accumulate here to the branch after a while.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
--- Comment #31 from rguenth at gcc dot gnu dot org 2006-03-30 15:48
---
How did you test the patch with OpenOffice? Are there OpenOffice modifications
necessary?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
--- Comment #12 from mkuvyrkov at gcc dot gnu dot org 2006-03-30 15:43
---
The patch was reapplied:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01721.html
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2006-03-30 15:41
---
Subject: Bug 26734
Author: mkuvyrkov
Date: Thu Mar 30 15:41:00 2006
New Revision: 112538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112538
Log:
2006-03-30 Maxim Kuvyrkov <[EMAIL PROTECTED]>
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-30 15:29 ---
Just for the record, the attached patch bootstrapped and regtested on
x86_64-unknown-linux-gnu, with the following fallout:
FAIL: gcc.dg/tree-ssa/loadpre4.c scan-tree-dump-times Eliminated: 1 1
FAIL: gcc.dg/tree-ssa
1 - 100 of 139 matches
Mail list logo
