Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds_cb1 at t-online dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://g
--- Comment #2 from bernds_cb1 at t-online dot de 2006-05-16 01:44 ---
safe_from_p always returns 0 for CONSTRUCTORs. That seems to be the fault of
revision 102182.
Off to bed now, I think I can fix this tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27620
--- Comment #16 from bernds_cb1 at t-online dot de 2006-05-16 21:30 ---
I saw the fallout of this on the mailing list, but was the patch ever sent to
gcc-patches before it was committed?
--
bernds_cb1 at t-online dot de changed:
What|Removed
--- Comment #6 from bernds_cb1 at t-online dot de 2006-05-25 14:33 ---
Does that mean you reverted the patch and I should reapply it later?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27620
id during vrp2
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds_cb1 at t-online dot de
GCC host tr
--- Comment #1 from bernds_cb1 at t-online dot de 2009-01-30 10:51 ---
Created an attachment (id=17212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17212&action=view)
Testcase to reproduce the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
--- Comment #4 from bernds_cb1 at t-online dot de 2005-11-27 11:09 ---
The preprocessed source is where?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25027
ority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds_cb1 at t-online dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: bfin-elf (probably any target)
http://gcc.gn
--- Comment #1 from bernds_cb1 at t-online dot de 2007-09-13 15:54 ---
Created an attachment (id=14205)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14205&action=view)
Preprocessed source
Use this input file to reproduce the problem.
--
http://gcc.gnu.org/b
--- Additional Comments From bernds_cb1 at t-online dot de 2005-03-15
11:44 ---
Interesting problem. I was temporarily confused by rth's mention of secondary
reloads; it's actually secondary memory that we allocate here. What happens is
1. Notice none of the alternatives f
--- Additional Comments From bernds_cb1 at t-online dot de 2005-04-13
10:08 ---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes
one argument null on entry
Jakub Jelinek wrote:
> PR target/20126
> * loop.c (loop_givs_rescan): If replacement of DEST_ADDR
--- Comment #1 from bernds_cb1 at t-online dot de 2008-04-02 13:17 ---
We don't support a bfin-linux-gnu target. Does any of bfin-elf, bfin-uclinux
or bfin-linux-uclibc work for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35419
--- Comment #2 from bernds_cb1 at t-online dot de 2009-09-17 14:24 ---
Created an attachment (id=18601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18601&action=view)
A patch that fixes the immediate problem
This is a bug in the ia64 backend, which puts autoinc addressin
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds_cb1 at t-online dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41718
--- Comment #1 from bernds_cb1 at t-online dot de 2009-10-15 19:05 ---
Created an attachment (id=18802)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18802&action=view)
Testcase to reproduce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41718
--- Comment #20 from bernds_cb1 at t-online dot de 2010-02-16 17:40 ---
Sorry I've seen this so late; the mails I got have been hidden in my unread
fortran folder so far. Need to change the filters.
Comment #9 suggests you can reproduce this without -frename-registers. Is
--- Comment #23 from bernds_cb1 at t-online dot de 2010-02-17 22:13 ---
Created an attachment (id=19900)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19900&action=view)
Possible fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #24 from bernds_cb1 at t-online dot de 2010-02-17 22:14 ---
Would you mind testing the attached patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #26 from bernds_cb1 at t-online dot de 2010-02-18 11:51 ---
Created an attachment (id=19905)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19905&action=view)
A patch to help debug the problem
I'll need some help since on my system a compiler targetting
p
--- Comment #28 from bernds_cb1 at t-online dot de 2010-02-18 12:21 ---
Only when building the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #32 from bernds_cb1 at t-online dot de 2010-02-18 14:17 ---
Created an attachment (id=19908)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19908&action=view)
Additional patch on top of the previous one
Sorry about that. Yes, you'll need to add that in db
--- Comment #35 from bernds_cb1 at t-online dot de 2010-02-18 15:32 ---
Okay, great. Could you attach the .rnreg dumps and assembly output for both
values?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #39 from bernds_cb1 at t-online dot de 2010-02-18 15:52 ---
(In reply to comment #36)
> > Could you attach the .rnreg dumps
>
> How do I get them?
>
-fdump-rtl-rnreg-details
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #42 from bernds_cb1 at t-online dot de 2010-02-18 18:13 ---
Created an attachment (id=19917)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19917&action=view)
Another test patch that attempts to fix the problem.
Could you test whether this fixes it?
--
ber
--- Comment #23 from bernds_cb1 at t-online dot de 2010-03-08 23:04 ---
Created an attachment (id=20048)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20048&action=view)
Alternative fix for 42220
If you wouldn't mind, please test the attached patch which should be an
--- Comment #49 from bernds_cb1 at t-online dot de 2010-03-08 23:06 ---
This fix caused a SPEC regression (see bug 42216). Could you test the patch I
attached to #42216, on top of current mainline, to see whether it does not
cause your problem to reappear?
--
http://gcc.gnu.org
--- Additional Comments From bernds_cb1 at t-online dot de 2005-08-12
09:07 ---
The reload-branch takes apart all this code, so there's a good chance it's
fixed. That doesn't mean we shouldn't try to get it right in the mainline...
--
http://gcc.gnu.org/bugz
--- Comment #5 from bernds_cb1 at t-online dot de 2009-12-01 15:26 ---
Code generation changes are expected for two reasons - the code became less
conservative when determining conflicts with other registers, so we can usually
rename in more cases. There are also a few cases where we
--- Comment #9 from bernds_cb1 at t-online dot de 2009-12-01 17:25 ---
Created an attachment (id=19202)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19202&action=view)
Test patch to attempt to narrow down the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
--- Comment #10 from bernds_cb1 at t-online dot de 2009-12-01 17:27 ---
Yes, regrename should only affect the second scheduling pass.
I'm attaching a stab-in-the-dark patch. It contains a fix for the ia64
regressions (testing in progress), it adds a few warnings which could be u
--- Comment #13 from bernds_cb1 at t-online dot de 2009-12-02 16:28 ---
Created an attachment (id=19211)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19211&action=view)
Patch to make it less conservative when accepting matching constraints with
different modes
--
--- Comment #14 from bernds_cb1 at t-online dot de 2009-12-02 16:29 ---
Would you mind trying another patch, both for testing performance, and if that
fails, for interesting warnings?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
--- Comment #16 from bernds_cb1 at t-online dot de 2009-12-02 17:06 ---
Thanks for testing. This means the regression is fixed by the patch? I'll do
a full test run then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
--- Comment #18 from bernds_cb1 at t-online dot de 2009-12-04 14:26 ---
Unfortunately it causes failures. Tracking these mismatches really is quite
tricky.
I'll try to fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
--- Comment #6 from bernds_cb1 at t-online dot de 2009-12-16 19:57 ---
I'm having a hard time reproducing this. How do you folks configure your
compilers?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
--- Comment #8 from bernds_cb1 at t-online dot de 2009-12-16 23:17 ---
This seems to be a bug in arm.md. Operand 0 in tls_load_dot_plus_eight is
marked in-out, but there's no matching match_dup to show the input. Adding
that to the unspec seems to make the problem go away. Rich
--- Comment #29 from bernds_cb1 at t-online dot de 2006-01-24 15:18 ---
Does anyone have a preprocessed source file handy?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
--- Comment #33 from bernds_cb1 at t-online dot de 2006-02-14 23:27 ---
Candidate patch posted in
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01100.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
38 matches
Mail list logo
