pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 01:47
---
SSA copy prop with dce after that should really be the correct way.
Err, SSA copy prop should be enough, actually, since after copy-prop,
the phi will have no users (and
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-08-08 06:14 ---
Subject: Re: redundant phi-node in latch-block
prevents vectorization
pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 01:47
---
SSA copy prop with
--- Comment #46 from hubicka at gcc dot gnu dot org 2006-08-08 06:15
---
In x86/x86-64 world one can be almost sure that the load+execute instruction
pair will execute (marginaly to noticeably) faster than move+load-and-execute
instruction pair as the more complex instructions are
In x86/x86-64 world one can be almost sure that the load+execute instruction
pair will execute (marginaly to noticeably) faster than move+load-and-execute
instruction pair as the more complex instructions are harder for on-chip
scheduling (they retire later).
^^^
--- Comment #47 from hubicka at ucw dot cz 2006-08-08 06:28 ---
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 (marginaly to noticeably) faster
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-08-08 06:35 ---
The strlen inlining depends on the -mtune switch. -mtune=athlon,generic and
i686
unrolls the strlen by in-line loop, while -mtune=pentium4 use the rep
operation.
Would be possible to benchmark both -mtune=generic
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2006-08-08 06:54
---
Probably this is a dublicate of 27883.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- 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 (marginaly
--- 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
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
--- 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
--- 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
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
--
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
--- 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
--
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 stdlib.h
#include stdio.h
--- 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
--- 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
--
--- 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=12042action=view)
fix target linker emulation for arm elf and eabi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
--- 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=11245action=view) [edit]
gcc-4.1.0-arm-bigendian.patch
gcc-4.1.x needs slight tweak since all the
Build the following C program with gcc -fmudflap program name -lmudflap:
***
#include stdlib.h
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:
***
--- 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
--
--- 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
--- 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] *)
--- 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=revrev=109938
r109938 | dberlin | 2006-01-19 01:42:48
--- 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=revrev=111300
r111300 | dberlin | 2006-02-20 13:38:01
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |middle-end
Summary|[4.2.0 regression] ICE with |[4.2
--- 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
--- 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 #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=revrev=65103
r65103 | jason | 2003-03-31 20:25:11 + (Mon, 31 Mar 2003)
There was
(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
--- 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
--- 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
--
--- 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 !=
--- 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 or
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 #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=revrev=102570
--- 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 #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
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);
}
--- 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
--- 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 #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 #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 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 #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 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 #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=revrev=95356
r95356 | paolo | 2005-02-21
/usr/src/ark/BUILD/kdelibs/phonon/objectdescription.cpp: In member function
'Phonon::ObjectDescriptionT Phonon::ObjectDescriptionT::operator=(const
Phonon::ObjectDescriptionT)':
/usr/src/ark/BUILD/kdelibs/phonon/objectdescription.cpp:54: internal compiler
error: Segmentation fault
Please submit a
--- 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=12043action=view)
Preprocessed source
--
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=12044action=view)
Simplified test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
--- 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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
--- 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
--- 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.
--
--- Comment #4 from tbm at gcc dot gnu dot org 2006-08-08 20:50 ---
Confirmed.
test::TestDescriptionT test::TestDescriptionT::operator=(const
test::TestDescriptionT)
Program received signal SIGSEGV, Segmentation fault.
0x00477cd3 in min_vis_r (tp=value optimized out,
--- 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=revrev=107702
r107702 | bonzini | 2005-11-30 08:20:23 + (Wed, 30 Nov 2005)
--- 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 #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 #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
--- 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 #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 #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,
--- 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:
--- 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=revrev=115086
r115086 | jason | 2006-06-30 01:15:56 + (Fri, 30 Jun 2006)
--
janis 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--- 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=12045action=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 #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):
$
--- 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
73 matches
Mail list logo
