--- Comment #51 from paolo dot bonzini at lu dot unisi dot ch 2006-08-09
04:33 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> I've been scoping this a little closer on the Athlon64X2. I have found that
> the patched gcc can achieve
--- Comment #12 from atgraham at gmail dot com 2006-08-09 01:30 ---
(In reply to comment #11)
[...]
> it may be a problem with WRS running initializers or
> initializing the frame tables.
Both of the gcc builds I'm testing with are cross compilers (host
i686-pc-linux-gnu):
$ powerpc-li
--- Comment #8 from bero at arklinux dot org 2006-08-09 01:04 ---
Created an attachment (id=12045)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12045&action=view)
Updated fix, works for multilib arches too
This new fix is even more ugly than the old one because I couldn't find a
--- Comment #4 from bero at arklinux dot org 2006-08-09 01:02 ---
Right, it's a matter of not getting the right includes -- I'm attaching a fixed
patch to bug 25404.
--
bero at arklinux 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 #11 from dje at gcc dot gnu dot org 2006-08-09 00:39 ---
Let's consider this PR as only the -O1 and above bug that has been confirmed
and regression hunted. Another PR can be opened for the -O0 bug that does not
appear to be as general -- it may be a problem with WRS running
--- Comment #1 from janis at gcc dot gnu dot org 2006-08-09 00:36 ---
A regression hunt on powerpc-linux identified this large patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=115086
r115086 | jason | 2006-06-30 01:15:56 + (Fri, 30 Jun 2006)
--
janis at gcc dot gnu dot or
--- Comment #10 from janis at gcc dot gnu dot org 2006-08-09 00:21 ---
A regression hunt using the testcase from comment #7 compiled with -O1, with a
powerpc-linux compiler configured with --enable-sjlj-exceptions, identified the
following patch:
http://gcc.gnu.org/viewcvs?view=rev&
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-09 00:13 ---
Aaron, I had not noticed that the stack pointer is modified in some of the code
that I had thought looked correct. My example works correctly with -O0 for
powerpc-linux with sjlj exceptions for 4.0 and 4.1 branches, b
--- Comment #2 from pbrook at gcc dot gnu dot org 2006-08-08 23:47 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00230.html
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from atgraham at gmail dot com 2006-08-08 23:21 ---
(In reply to comment #7)
> I don't get any failures with the 4.0-branch for powerpc-linux with sjlj
> exceptions. Here's the executable test case I'm using for a regression hunt:
Janis,
Thank you for looking into this.
--- Comment #11 from pbrook at gcc dot gnu dot org 2006-08-08 23:05 ---
Assembly in initial comment is bogus. Should be ldmfd {..., pc}^. ldmrd {...
lr}^ does somethething completely different.
*** This bug has been marked as a duplicate of 16634 ***
--
pbrook at gcc dot gnu dot org
--- Comment #1 from pbrook at gcc dot gnu dot org 2006-08-08 23:05 ---
*** Bug 25428 has been marked as a duplicate of this bug. ***
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from janis at gcc dot gnu dot org 2006-08-08 21:08 ---
I don't get any failures with the 4.0-branch for powerpc-linux with sjlj
exceptions. Here's the executable test case I'm using for a regression hunt:
extern "C" void abort (void);
void *pc, *
--- Comment #6 from janis at gcc dot gnu dot org 2006-08-08 20:59 ---
A regression hunt on powerpc-linux confirmed that this patch caused the change
in behavior:
http://gcc.gnu.org/viewcvs?view=rev&rev=107702
r107702 | bonzini | 2005-11-30 08:20:23 + (Wed, 30 Nov 2005)
Her
--- Comment #4 from tbm at gcc dot gnu dot org 2006-08-08 20:50 ---
Confirmed.
test::TestDescription& test::TestDescription::operator=(const
test::TestDescription&)
Program received signal SIGSEGV, Segmentation fault.
0x00477cd3 in min_vis_r (tp=,
walk_subtrees=0x7fffcc62fa84,
--- Comment #6 from janis at gcc dot gnu dot org 2006-08-08 20:49 ---
Oops, I meant that for 4.1 powerpc-linux with sjlj exceptions, it passes for
-O0 but fails for -O[s123]. I'm trying 4.0 now, then will back up if I see
problems with 4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #4 from pcarlini at suse dot de 2006-08-08 20:47 ---
Maybe Doug can help (certainly not me ;) ...
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.2
--- Comment #5 from janis at gcc dot gnu dot org 2006-08-08 20:35 ---
David asked me to run a regression hunt on this, but I'm very confused about
when the problem occurs, since some of the submitter's examples look just fine
to me. Here's what it looks like to me, based on the generate
--- Comment #3 from bero at arklinux dot org 2006-08-08 20:19 ---
The problem in the simplified test case goes away when removing the
__attribute__((visibility("default")))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
--- Comment #2 from bero at arklinux dot org 2006-08-08 20:17 ---
Created an attachment (id=12044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12044&action=view)
Simplified test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
--- Comment #1 from bero at arklinux dot org 2006-08-08 20:08 ---
Created an attachment (id=12043)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12043&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
/usr/src/ark/BUILD/kdelibs/phonon/objectdescription.cpp: In member function
'Phonon::ObjectDescription& Phonon::ObjectDescription::operator=(const
Phonon::ObjectDescription&)':
/usr/src/ark/BUILD/kdelibs/phonon/objectdescription.cpp:54: internal compiler
error: Segmentation fault
Please submit a fu
--- Comment #3 from janis at gcc dot gnu dot org 2006-08-08 19:55 ---
A regression hunt on powerpc-linux identified this patch where a testcase based
on the submitter's test (see below) starts failing:
http://gcc.gnu.org/viewcvs?view=rev&rev=95356
r95356 | paolo | 2005-02-21 23
--- Comment #2 from pault at gcc dot gnu dot org 2006-08-08 19:46 ---
A patch has alredy been posted.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-08 19:45 ---
A patch is on its way to the list, just as soon as it has finished regtesting.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-08-08 19:08
---
DejaGnu 1.4.4 did the trick. Thanks!
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-08-08 18:52
---
*** Bug 28569 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-08-08 18:52
---
*** This bug has been marked as a duplicate of 27616 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 18:37 ---
3.4.x is no longer maintained and there will not be another release of 3.4.6 so
closing as fixed for 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #50 from whaley at cs dot utsa dot edu 2006-08-08 18:36 ---
Guys,
I've been scoping this a little closer on the Athlon64X2. I have found that
the patched gcc can achieve as much as 93% of theoretical peak (5218Mflop on a
2800Mhz Athlon64X2!) for in-cache matmul when the cod
this code example could not be build for arm-elf correctly
static inline __attribute__((always_inline)) __attribute__((always_inline))
void *my_alloc(unsigned int size)
{
if (__builtin_constant_p(size)) {
__I_think_size_is_a_constant();
return func2(size);
}
return func3(size);
}
static
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-08-08 18:33
---
*** Bug 28010 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-08 18:33 ---
Yes this is a dup.
*** This bug has been marked as a duplicate of 27616 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janis at gcc dot gnu dot org 2006-08-08 18:31 ---
A regression hunt using an i686-linux cross compiler with the testcase from
comment #1 identified the following patch where the compiler starts
segfaulting:
http://gcc.gnu.org/viewcvs?view=rev&rev=102570
r102
The warning below doesn't seem justified and is not helpful (certainly not in
this case or whenever the last argument can be proven to be 0). IMO, where the
warning would be helpful is the second invocation of memcpy() since that one
has undefined behavior.
$ cat -n t.cpp && g++ -Wall t.cpp
1
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-08-08 17:18 ---
Which means it was probably "fixed" by
2005-11-30 Paolo Bonzini <[EMAIL PROTECTED]>
* simplify-rtx.c (simplify_plus_minus): Remove final parameter.
Always produce an output if we can remove NEGs o
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-08-08 17:17 ---
Breakpoint 4, simplify_const_relational_operation (code=LT, mode=SImode,
op0=0xb7cc9f60, op1=0xb7d3ef60)
at /space/rguenther/src/svn/gcc-4_1-branch/gcc/simplify-rtx.c:3040
3040 gcc_assert (mode != VOIDm
--- Comment #5 from patchapp at dberlin dot org 2006-08-08 17:00 ---
Subject: Bug number PR c/28136
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00214.html
--
http://gcc.gnu.org/bugzilla
--- Comment #49 from whaley at cs dot utsa dot edu 2006-08-08 16:43 ---
Paolo,
>Yes, so far so good and this part has already been committed. But does
>a *single* load-and-execute instruction execute faster than the two
>instructions in a load+execute sequence?
As I said, in my hand-t
(should block F2003 meta PR 20585)
gfortran should support:
- DECIMAL= 'COMMA' or 'POINT' specifier in OPEN, READ, WRITE and INQUIRE
(9.4.5.5, 9.5.1.6 in F2003 standard)
- DP and DC as edit descriptors (10.7.8)
- SIGN= 'PLUS', 'SUPPRESS' or 'PROCESSOR_DEFINED' specifier for OPEN, WRITE and
INQU
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-08-08 16:26 ---
Janis, can you look what fixed this on the mainline?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-08-08 16:13 ---
ppc also broken. But not a regression, so technically FIXED. Still this looks
like something we want to fix - but maybe someone can convince me it is
undefined ;)
Shorter testcase ("folds" to return 0):
int foo(u
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |middle-end
Summary|[4.2.0 regression] ICE with |[4.2 regre
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-08 16:06 ---
Confirmed. After combine it's broked.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from janis at gcc dot gnu dot org 2006-08-08 16:05 ---
A regression hunt on powerpc-linux showed that the behavior changed with this
patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=65103
r65103 | jason | 2003-03-31 20:25:11 + (Mon, 31 Mar 2003)
There was disc
--- Comment #7 from janis at gcc dot gnu dot org 2006-08-08 15:54 ---
A regression hunt using an i686-linux cross compiler with the testcase from
comment #6 identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=111300
r111300 | dberlin | 2006-02-20 13:38:01 +0
--- Comment #10 from janis at gcc dot gnu dot org 2006-08-08 15:51 ---
A regression hunt on powerpc-linux identified the following patch where the
testcase from comment #3 starts failing:
http://gcc.gnu.org/viewcvs?view=rev&rev=109938
r109938 | dberlin | 2006-01-19 01:42:48 +00
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-08
14:15 ---
(In reply to comment #2)
> I wonder if this was caused by Jakub's patches for openmp.
Or Richard Sandiford's patches. The above produces:
gee ()
{
int4 .s;
__builtin_memmove (&(*(char[0:][1:3] *) m.
--- Comment #1 from vesselinpeev at hotmail dot com 2006-08-08 13:51
---
If both -fmudflap and -fmudflapth is specified, there is no problem. I read
about it at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
It says that a patch has been committed to mainline, i.e. what would be
re
--- Comment #1 from patchapp at dberlin dot org 2006-08-08 13:45 ---
Subject: Bug number PR28630
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00205.html
--
http://gcc.gnu.org/bugzilla/sh
Build the following C program with "gcc -fmudflap -lmudflap":
***
#include
int main()
{
char* crash = (char*)malloc(1);
crash[1] = 1;
crash[-1] = 1;
return 0;
}
***
The output is expected and correct -- 2 violations are reported:
***
mudflap violation 1 (ch
--- Comment #11 from mkl at pengutronix dot de 2006-08-08 13:33 ---
(In reply to comment #9)
> Created an attachment (id=11245)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11245&action=view) [edit]
> gcc-4.1.0-arm-bigendian.patch
>
> gcc-4.1.x needs slight tweak since all the AR
--- Comment #10 from mkl at pengutronix dot de 2006-08-08 13:31 ---
Created an attachment (id=12042)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12042&action=view)
fix target linker emulation for arm elf and eabi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
--- Comment #6 from patchapp at dberlin dot org 2006-08-08 13:20 ---
Subject: Bug number PR target/21299
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00204.html
--
http://gcc.gnu.org/bug
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-08-08 11:12
---
Ugh. This is an oscillation with period 6 (not 3 as indicated in comment #3)
between fold_rtx and fold_rtx_mem:
#0 fold_rtx (x=0x55759dd4, insn=0x0) at /home/eric/svn/gcc/gcc/cse.c:3621
#1 0x081a640a in fold_
This happens with 4.1.1 release too but not with gcc-4.2-20060805. Also happens
for gcc 4.1.1 on i386 Solaris 10.
bash-3.00$ uname -a
Linux bonk.sics.se 2.6.16-1.2111_FC4smp #1 SMP Sat May 20 20:16:24 EDT 2006
i686 unknown unknown GNU/Linux
bash-3.00$ cat bug.c
#include
#include
int main(int ar
--- Comment #1 from patchapp at dberlin dot org 2006-08-08 10:00 ---
Subject: Bug number PR c/28649
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00201.html
--
http://gcc.gnu.org/bugzilla
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28649
The error recovery of the C parser sometimes gets confused.
The following testcase contains three bugs:
void foo()
{
+;
+;
}
int +;
But the C frontend only reports the first one:
bug.c: In function 'foo':
bug.c:3: error: expected expression before ';' token
The old yacc-b
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-08-08 09:09 ---
Confirmed. The problem is probably latent on mainline. check_header is being
miscompiled, -O -fno-loop-optimize2 -fno-loop-optimize -fno-branch-count-reg
is enough to trigger the bug (i.e. no loop bug).
extern voi
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-08-08
09:08 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00200.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28648
The following causes ICE on windows targets on mainline.
void foo (int __attribute__ ((dllimport)) bar);
dllimp_parm.c:1: internal compiler error: tree check: expected tree that
contains 'decl with visibility' structure, have 'parm_decl' in
handle_dll_attribute, at tree.c:3762
Please submit a
--- Comment #3 from dorit at il dot ibm dot com 2006-08-08 07:38 ---
> Err, SSA copy prop should be enough, actually, since after copy-prop,
> the phi will have no users (and they shouldn't care about code with no
> uses that doesn't access memory).
> Though it's interesting that this re
--- Comment #48 from paolo dot bonzini at lu dot unisi dot ch 2006-08-08
07:05 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> In x86/x86-64 world one can be almost sure that the load+execute instruction
> pair will execute (marginal
66 matches
Mail list logo
