--- Comment #10 from jamborm at gcc dot gnu dot org 2008-12-02 14:32
---
Subject: Bug 37861
Author: jamborm
Date: Tue Dec 2 14:30:55 2008
New Revision: 142355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142355
Log:
2008-12-02 Martin Jambor <[EMAIL PROTECTED]&g
d check error during bootstrap
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jamborm at gcc dot gnu dot org
G
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-12-02 10:27 ---
Created an attachment (id=16808)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16808&action=view)
Preprocessed source
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38371
--- Comment #2 from jamborm at gcc dot gnu dot org 2008-12-30 13:08 ---
Apparently, the problem is that when some expression arithmetics is
folded to D.1241_18 = a[0], the statement volatile flag is not set
which triggers the assert.
The following simple patch makes the ICE go
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-12-30 16:58 ---
I discussed this bug with Richi on IRC and was told that we should
avoid having the statement marked as volatile since it is not an
access through a volatile variable in the original source code
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-05-10 10:29 ---
New SRA handles this fine by not scalarizing anything that has volatile fields
in it. There is already a fortran testcase with a union with a volatile field
that made me aware of this.
--
http://gcc.gnu.org
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-05-21 16:02 ---
With he new SRA, the optimized dump looks like:
D.6886_10 = {1, 1, 1, 1};
D.6887_11 = VIEW_CONVERT_EXPR(D.6886_10);
D.6893_12 = VIEW_CONVERT_EXPR(D.6887_11);
D.6891_14 = __builtin_ia32_pcmpeqd128 (D.6893_12
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-05-25 15:20 ---
...hm, when I wanted to make such a testcase I realized that the SSE
code is not very portable. So I changed my mind and won't use it.
I'll be adding different union scalarization checks, though.
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-02 10:51 ---
Apparently I was not careful enough when turning an if branch to a while loop.
I'll prepare and test a patch straight away.
--
jamborm at gcc dot gnu dot org changed:
What|Re
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-02 17:06 ---
Created an attachment (id=17946)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17946&action=view)
Fix
Ok, creating a simple testcase was not easy for me but here is a patch
that includes one (and fi
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-03 11:56 ---
Subject: Bug 40323
Author: jamborm
Date: Wed Jun 3 11:56:05 2009
New Revision: 148126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148126
Log:
2009-06-03 Martin Jambor
PR tree-opti
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-03 12:54 ---
I have just verified this is fixed on the current trunk.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-05 11:49 ---
Mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-05 15:48 ---
Created an attachment (id=17955)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17955&action=view)
Fix
This patch fixes this problem. I'll post it to the mailing list once
I get to bootstrap it wh
--- Comment #15 from jamborm at gcc dot gnu dot org 2009-06-07 14:41
---
(In reply to comment #11)
> It is caused by revision 147980:
>
> http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html
>
Revision 147978 also does not work if you compile the testcase with
the -
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-08 13:27 ---
This is obviously mine. Will look into it shortly.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from jamborm at gcc dot gnu dot org 2009-06-08 17:49
---
(In reply to comment #16)
> Wait, (In reply to comment #15)
> > (In reply to comment #11)
> > > It is caused by revision 147980:
> > >
> > > http://gcc.gnu.
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-09 16:53 ---
Subject: Bug 40351
Author: jamborm
Date: Tue Jun 9 16:52:57 2009
New Revision: 148315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148315
Log:
2009-06-09 Martin Jambor
PR tree-opti
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-09 20:59 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-14 01:30 ---
Mine, will look into it shortly.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #94 from jamborm at gcc dot gnu dot org 2009-06-14 04:43
---
(In reply to comment #92)
> In the meanwhile something caused "tree incremental SSA" to jump up from 10s
> to
> 26s. Sob.
>
(In reply to comment #93)
> I would say that was the new
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-14 04:55 ---
(In reply to comment #1)
> I want to say the SRA changes caused this ...
>
Yes it did. I can reproduce it and it should not be difficult to
fix. However, I'll have a look at why SRA constructs such
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-15 09:07 ---
Created an attachment (id=18001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18001&action=view)
Fix
This was quite a serious oversight on my part, I wonder how it went
for so long unnoticed. I am a
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-15 09:09 ---
Created an attachment (id=18002)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18002&action=view)
Fix
OK, the statement is fine except that it is not gimple ;-). Fixed
with this patch, I will su
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-06-16 09:54
---
Bootstrap and testing passed, submitted in
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01179.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40413
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-16 09:57 ---
Bootstrapped, tested, submitted in
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01182.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40432
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-06-16 10:12
---
Subject: Bug 40413
Author: jamborm
Date: Tue Jun 16 10:11:55 2009
New Revision: 148520
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148520
Log:
2009-06-16 Martin Jambor
PR tree-opti
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-16 10:16 ---
Subject: Bug 40432
Author: jamborm
Date: Tue Jun 16 10:16:40 2009
New Revision: 148522
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148522
Log:
2009-06-16 Martin Jambor
PR tree-opti
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-16 10:24 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-06-16 10:24
---
Fixed
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-19 13:14 ---
(In reply to comment #2)
> Confirmed. Caused by new SRA - we are creating a temporary with
> TREE_ADDRESSABLE
> type.
>
Again? Well, let me see where...
--
jamborm at gcc dot gnu dot
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-19 17:27 ---
Created an attachment (id=18025)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18025&action=view)
Fix
The offset we pass to build_ref_for_offset in sra_modify_assign does not make
any sense. I am a
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-06-19 18:09 ---
I will look into this next week. However, I have never compiled binutils
before, so unless it is obvious, please describe how to reproduce the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-22 10:54 ---
Subject: Bug 40492
Author: jamborm
Date: Mon Jun 22 10:54:16 2009
New Revision: 148787
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148787
Log:
2009-06-22 Martin Jambor
PR tree-opti
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-22 18:57 ---
Right, now I can reproduce the problem and it indeed is introduced by the new
SRA commit. None of the fixes I have done so far deals with this one either. I
am investigating this further (but don't hold your b
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-06-23 13:21
---
The miscompiled file seems to be gas/tc-i386.o. Early SRA is enough to trigger
the problem. Digging deeper...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-23 14:12 ---
Fixed
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-06-23 16:45
---
Reduced testcase:
extern void abort (void);
typedef union i386_operand_type
{
struct
{
unsigned int reg8:1;
unsigned int reg16:1;
unsigned int reg32:1;
unsigned int reg64:1
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-06-24 16:38
---
Fix submitted to the mailing list, pending maintainer approval:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01918.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
--- Comment #14 from jamborm at gcc dot gnu dot org 2009-06-25 10:38
---
Subject: Bug 40493
Author: jamborm
Date: Thu Jun 25 10:38:13 2009
New Revision: 148941
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148941
Log:
2009-06-25 Martin Jambor
PR tree-opti
--- Comment #15 from jamborm at gcc dot gnu dot org 2009-06-25 14:21
---
I have checked out trunk 148941, compiled binutils with it (configured
with --disable-werror), ran the testsuite and there were no failures.
Thus I consider this fixed.
--
jamborm at gcc dot gnu dot org
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-06-26 13:53 ---
This is some sort of cgraph consistency check. Honza added it and he also said
he will look into this :-)
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-06-26 14:59 ---
OK, I have finally managed to reproduce this and the patch does indeed result
into a segfault. I will keep looking into this, even though probably won't be
able to do much until Monday.
--
jamborm at gc
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-06-26 15:08 ---
The miscompiled file seems to be derivative_approximation.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-27 23:41 ---
I believe the following (but yet untested) patch fixes this issue.
I will bootstrap and test it once I have a testcase that is simple
enough to be put into the testsuite. I hope to do all of this on
Monday
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-29 11:16 ---
OK, I'll have a look at it after I am done with PR 40554.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-29 11:22 ---
I'm quite confident this is a cgraph bug => CCing honza. (I'll try to keep
this on my radar but there are other issues for which I am certainly
responsible now).
--
jamborm at gcc dot gnu do
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-29 17:11 ---
Created an attachment (id=18094)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18094&action=view)
Fix
It turns out that build_ref_for_offset apparently needs to check for
full type compatibility an
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-30 09:34 ---
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02214.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-30 09:35 ---
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02215.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40582
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-30 10:03 ---
Subject: Bug 40554
Author: jamborm
Date: Tue Jun 30 10:03:26 2009
New Revision: 149087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149087
Log:
2009-06-30 Martin Jambor
PR middle-e
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-30 10:10 ---
Subject: Bug 40582
Author: jamborm
Date: Tue Jun 30 10:10:29 2009
New Revision: 149088
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149088
Log:
2009-06-30 Martin Jambor
PR tree-opti
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-30 11:39 ---
As you may have noticed, I changed the testcase a little bit so that
it ICEs as my i386 desktop too. A freshly checked out trunk no longer
does. So I believe this is indeed fixed.
--
jamborm at gcc dot gnu
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-30 11:44 ---
When compiled with a freshly checked-out trunk the testcase no longer
segfaults and gives exactly the same output as if compiled with trunk
revision 147978 (i.e. just before my new SRA got in). So I consider
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-07-14 16:32 ---
OK, I have now added this to my todo list. The simple tweaks would be
simple. On the other hand, if DCE is clever, it still might figure
out a structure is dead at some code paths while I don't even attem
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-28 13:28 ---
Honza, unless there are any new problems, can you commit the patch? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-28 20:14 ---
When I move "e->inline_failed = CIF_OK" in cgraph_mark_inline_edge()
until after call to cgraph_clone_inlined_nodes(), the endless
recursion goes away. However, I now get
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59 ---
Ha, please disregard the previous message, obviously I had to make a
fool out of myself before realizing that loops in the inlining plan
are the bug, not how we handle them.
The reason there are such loops is that
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-07-28 21:33 ---
I can confirm that if we schedule pass_ccp right after pass_sra_early,
g gets inlined. Moreover, if we schedule one more pass_forwprop right
afterwards, even the testcase for PR 3713, comment #12 gets optimized
as
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-07-29 09:27 ---
Can you please try this with -fno-tree-sra? If you have a revision
earlier than 147980 (new SRA) at hand, can you try that with
-fno-tree-sra? Thanks.
I'll try to reproduce this on gcc61 at the compile far
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-07-29 09:51 ---
(In reply to comment #8)
> > --- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59
> > ---
> > So, I belive the patch below fixes this issue and I am going to
> >
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-29 10:16
---
(In reply to comment #12)
> ... at least scheduling FRE is still on the list of possible things
> todo (can you check if that fixes 3713 as well?)
>
No, it doesn't (unlike the testcase above, fo
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-07-29 10:33
---
Bootstrap and testing finished fine, I submitted the patch:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01642.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-07-29 13:40
---
(In reply to comment #8)
> That only detects direct loops, does it?
Actually, now I may understand but no, it is exactly the other way
round. The patch above only detects indirect loops, when there are
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-07-30 14:18 ---
Richi, not scalarizing things like the second foo() in the original
bug description will inevitably lead to warning failures in
g++.dg/warn/unit-1.C and gcc.dg/uninit-I.c. Is that OK? Should I
remove or XFAIl them
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-07-30 16:26
---
Subject: Bug 40570
Author: jamborm
Date: Thu Jul 30 16:26:09 2009
New Revision: 150263
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150263
Log:
2009-07-30 Martin Jambor
PR tree-opti
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-30 16:43
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-30 17:07 ---
Created an attachment (id=18273)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18273&action=view)
Proposed patch
The attached patch does turn SRA down a bit. Specifically, in order
to create a repl
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-30 17:10 ---
Created an attachment (id=18274)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18274&action=view)
Proposed patch
Well, apparently I forgot to run quilt refresh, this is the current
patch with the t
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-08-04 16:54 ---
Right. The number in identifiers I see are different, of course, but
what happens is this. Early SRA replaces structure b.3 with
SR.4_25. In BB2, it is assigned into from parameter b:
SR.4_25 = b._M_value;
This
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-08-05 20:51 ---
The long-dead declaration is brought back to life by the following
line in gimplify_var_or_parm_decl() in gimplify.c:
tree value_expr = DECL_VALUE_EXPR (decl);
I don't know why that happens yet.
--
--- Comment #16 from jamborm at gcc dot gnu dot org 2009-08-06 11:55
---
Subject: Bug 32964
Author: jamborm
Date: Thu Aug 6 11:55:30 2009
New Revision: 150523
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150523
Log:
2009-08-06 Martin Jambor
PR middle-e
--- Comment #17 from jamborm at gcc dot gnu dot org 2009-08-06 12:09
---
New SRA scalarizes the unions in this testcase and so this is no
longer a 4.5 regression. I have committed a testcase for reference
and am updating relevant bugzilla tags/summary now.
As I won't be backpo
--- Comment #17 from jamborm at gcc dot gnu dot org 2009-08-06 12:22
---
Note to self: PR 40874 is related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-08-06 17:31
---
Created an attachment (id=18311)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18311&action=view)
workaround patch
I still believe that the gimplifier should not do this substitution
this late
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-08-06 17:55
---
Patch posted to mailing list:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00367.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464
d
AssignedTo: jamborm at gcc dot gnu dot org
ReportedBy: jamborm at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-08-07 10:11 ---
I am testing the patch below which should fix the problem:
2008-08-07 Martin Jambor <[EMAIL PROTECTED]>
* tree-inline.c (remap_gimple_stmt): Remove extraneous addr_expr
from call stat
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-08-07 15:49 ---
Unfortunately, I got a fortran regression:
/abuild/mjambor/iinln/gcc/testsuite/gfortran.dg/char_cast_1.f90:24: internal
com
piler error: in expand_call_inline, at tree-inline.c:3117
The assert is gcc_assert (dest
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-08-08 07:50 ---
(In reply to comment #4)
> Interesting. I may have a look into the CCP problem.
>
Well, I think that we have pass_rebuild_cgraph_edges precisely because
passes like CCP are not trusted to update call
--- Comment #9 from jamborm at gcc dot gnu dot org 2008-09-10 10:11 ---
I've been away from computer for a rather long time so I could not check
earlier. However, the problem is indeed gone. Thanks Richi.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-09-11 11:42 ---
I guess this is mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from jamborm at gcc dot gnu dot org 2008-10-22 15:09
---
OK, here is the status regarding the trunk (4.4) and the test cases
posted here:
1. The test case in the bug description now works in the sense that
funk is inlined even when not performing early inlining
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-10-30 17:43 ---
Well, yes, we do generate that code. However, the loop is unrolled
later on and the IR code on which the vrp complains later on actually is:
main ()
{
unsigned int ivtmp.27;
unsigned int pretmp.17;
int
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-10-31 17:52 ---
The test-case in the bug description leads to bogus warnings in the
second run of the VRP pass. Yesterday me and Richi discussed the
possibility of simply not-giving out any warnings in the second runs
--- Comment #4 from jamborm at gcc dot gnu dot org 2008-10-31 18:01 ---
(In reply to comment #2)
> So what is this? Is the warning logic wrong or is the IR wrong? It seems to me
> that IR is valid.
>
Well, it probabaly isn't. I guess the second index should not ev
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-11-04 15:51 ---
Right, so this is the most simple (albeit not yet tested) patch I've
been able to come up with. I am not sure what overall impact this is
going to have. I'll briefly try to come up with some
--- Comment #6 from jamborm at gcc dot gnu dot org 2008-11-05 16:08 ---
Subject: Bug 37861
Author: jamborm
Date: Wed Nov 5 16:06:38 2008
New Revision: 141613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141613
Log:
2008-11-05 Martin Jambor <[EMAIL PROTECTED]&g
--- Comment #8 from jamborm at gcc dot gnu dot org 2008-11-10 10:06 ---
The previous patch resulted into a regression on m32c-unknown-elf and
thus I prepared a less intrusive one below. See also:
* http://gcc.gnu.org/ml/gcc/2008-11/msg00058.html and
* http://gcc.gnu.org/ml/gcc-patches
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot
|dot org
--- Comment #18 from jamborm at gcc dot gnu dot org 2008-04-01 14:50
---
I'm now working on a proper fix.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jamborm at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-02-03 15:09 ---
Created an attachment (id=17232)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17232&action=view)
Preprocessed source
Enough to compile with -O2 -g -fno-tree-sra explicit_instantiation.ii
--
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-02-03 16:56 ---
Created an attachment (id=17236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17236&action=view)
Preprocessed source
OK, this one is hopefully without any precompiled headers.
--
jamborm at gcc
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-02-06 21:45
---
Indeed, this testcase is fully scalarized by the new SRA even as it is
today. (If you don't know what new SRA I mean, I hope I'll post it to
the list as an RFC next week).
--
jamborm at gcc dot g
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-02-23 14:09 ---
I don't understand the comment above the assert at all (Honza probably
does) and so this might not be the correct approach but the following
patch should just obviously work. At least it does for this tes
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-02-24 13:44 ---
After discussion with Honza, I have tried a more complex approach, the
patch is at:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01118.html
--
jamborm at gcc dot gnu dot org changed:
What
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-02-25 18:19 ---
Fixed with:
Author: jamborm
Date: Wed Feb 25 17:34:40 2009
New Revision: 144428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144428
Log:
2009-02-25 Martin Jambor
* tree-
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-02-28 00:30
---
I have just posted a patch to fix this issue on the 4.3 branch to the
mailing list:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01245.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
1 - 100 of 442 matches
Mail list logo
