https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92767
--- Comment #1 from Bernd Schmidt ---
People will be more likely to look at it if there's a preprocessed .i file that
reproduces the issue, ideally with a cross compiler rather than a native
bootstrap.
If it only occurs when bootstrapping, narrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
--- Comment #8 from Bernd Schmidt ---
Author: bernds
Date: Mon Nov 25 12:31:16 2019
New Revision: 278681
URL: https://gcc.gnu.org/viewcvs?rev=278681&root=gcc&view=rev
Log:
Convert m68k to not use cc0
* config/m68k/m68k.c (output_move_hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #2 from Bernd Schmidt ---
Jakub seems to be the author of gcc.target/i386/pr49095.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972
--- Comment #11 from Bernd Schmidt ---
For reference: patch and discussion here.
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283
--- Comment #15 from Bernd Schmidt ---
For reference: patch and discussion here.
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283
--- Comment #9 from Bernd Schmidt ---
Cou(In reply to Michael_S from comment #8)
> Here is a variant that makes an issue to show on x64 with -fno-tree-ter.
> https://godbolt.org/g/mSLiRZ
Could you attach this here as well? I've been trying to ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283
--- Comment #7 from Bernd Schmidt ---
Well, I've made a small tweak to the patch I have for PR78972, and I've got
what at a glance looks like optimal code (no spills).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80160
--- Comment #7 from Bernd Schmidt ---
Author: bernds
Date: Sat Mar 25 01:12:04 2017
New Revision: 246473
URL: https://gcc.gnu.org/viewcvs?rev=246473&root=gcc&view=rev
Log:
PR rtl-optimization/80160
PR rtl-optimization/80159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80159
--- Comment #4 from Bernd Schmidt ---
Author: bernds
Date: Sat Mar 25 01:12:04 2017
New Revision: 246473
URL: https://gcc.gnu.org/viewcvs?rev=246473&root=gcc&view=rev
Log:
PR rtl-optimization/80160
PR rtl-optimization/80159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80160
--- Comment #4 from Bernd Schmidt ---
Perhaps this.
Index: lra-assigns.c
===
--- lra-assigns.c (revision 246226)
+++ lra-assigns.c (working copy)
@@ -908,7 +908,8 @@ mus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80025
--- Comment #12 from Bernd Schmidt ---
That still doesn't seem to address the root cause though? Isn't the problem
that this reversible mappings code can create cycles and we should avoid
creating these in the first place?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185
Bernd Schmidt changed:
What|Removed |Added
Assignee|bernds at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185
--- Comment #8 from Bernd Schmidt ---
Created attachment 40997
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40997&action=edit
Some steps towards solving it
There are some relatively obvious issues in ira-lives:
a) We briefly mark a regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71294
--- Comment #14 from Bernd Schmidt ---
I can't reproduce this, but that's probably because of
cc1plus: warning: will not generate power8 instructions because assembler
lacks power8 support
Binutils was just configured for ppc64le-linux - do I
,
||bernds at gcc dot gnu.org
--- Comment #7 from Bernd Schmidt ---
CC'ing Alex. I've poked around this a bit and it seems to be in code he's
written and which I don't fully understand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911
Bernd Schmidt changed:
What|Removed |Added
Summary|[5/6/7 Regression] Infinite |[5/6 Regression] Infinite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911
--- Comment #13 from Bernd Schmidt ---
Author: bernds
Date: Fri Mar 10 21:17:13 2017
New Revision: 246059
URL: https://gcc.gnu.org/viewcvs?rev=246059&root=gcc&view=rev
Log:
PR rtl-optimization/78911
* lra-assigns.c (must_not_spil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972
Bernd Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79806
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916
--- Comment #4 from Bernd Schmidt ---
I also have trouble reproducing this. Rather than the g++ commandline, please
post what is passed to cc1plus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910
--- Comment #4 from Bernd Schmidt ---
(In reply to Zdenek Sojka from comment #0)
> Trying 27, 28 -> 33:
> ...
> Successfully matched this instruction:
> (set (reg:QI 128 [ _6 ])
> (plus:QI (subreg:QI (reg:DI 111 [ p1D.1798 ]) 0)
> (su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
--- Comment #13 from Bernd Schmidt ---
(In reply to Martin Liška from comment #11)
> I see a similar test-case on ppc64le-linux-gnu (w/ cross-compiler):
>
> $ ppc64le-linux-gnu-g++
> /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
--- Comment #12 from Bernd Schmidt ---
(In reply to Jakub Jelinek from comment #10)
> Wouldn't it penalize other code? E.g. if you have a TImode MEM and store
> from something in XMM register, then it doesn't have to be offsetable and
> can use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405
Bernd Schmidt changed:
What|Removed |Added
Assignee|bernds at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405
--- Comment #5 from Bernd Schmidt ---
Patch and discussion here:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01063.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728
--- Comment #4 from Bernd Schmidt ---
Actually here's mine from last week:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00176.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910
Bernd Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
--- Comment #9 from Bernd Schmidt ---
Maybe we just need to declare this address to be invalid for TImode. The
following seems to cure the testcase; untested otherwise.
Index: i386.c
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79780
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728
Bernd Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot
gnu.org
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bernds at gcc dot gnu.org
Target Milestone: ---
Created attachment 40753
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40753&action=edit
Reproducer
Disclaimer: I'm uncertain how severe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79386
--- Comment #3 from Bernd Schmidt ---
Gah. If we clean up the CFG after bypass_conditional_jumps, it can crash if it
finds an unconditional trap in the middle of a block. If we do it beforehand,
we're referencing data by the wrong bb number.
May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634
--- Comment #5 from Bernd Schmidt ---
I don't know the machine, but with a branch cost of 1 this seems like it might
be expected. Do you think this is a testcase problem or something else?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
||2017-01-30
CC||bernds at gcc dot gnu.org
Component|target |tree-optimization
Ever confirmed|0 |1
--- Comment #9 from Bernd Schmidt ---
Confirmed, and it does seem to be ter doing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559
--- Comment #12 from Bernd Schmidt ---
Sorry, long pause while editing that comment made me leave out part of what I
was trying to say - I meant only discard notes that reference the CC reg. But
it seems an unnecessary complication.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559
--- Comment #11 from Bernd Schmidt ---
Looks like other_insn is only used for cases where we rewrite cc sets in this
way, so Bin's patch does look reasonably narrow. We could maybe record the CC
reg being changed and only discard reg notes, but i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724
--- Comment #7 from Bernd Schmidt ---
Author: bernds
Date: Mon Jan 23 16:30:55 2017
New Revision: 244817
URL: https://gcc.gnu.org/viewcvs?rev=244817&root=gcc&view=rev
Log:
PR rtl-optimization/71724
* combine.c (if_then_else_cond)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634
--- Comment #2 from Bernd Schmidt ---
Author: bernds
Date: Mon Jan 23 16:17:33 2017
New Revision: 244816
URL: https://gcc.gnu.org/viewcvs?rev=244816&root=gcc&view=rev
Log:
PR rtl-optimization/78634
* config/i386/i386.c (ix86_max_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79194
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
--- Comment #16 from Bernd Schmidt ---
I retested again with a few different combinations of things. With an older
gdb, I can still reproduce the issue that sra-1 becomes UNSUPPORTED (presumably
through a gdb crash). With gdb-7.12 installed the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79125
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634
--- Comment #1 from Bernd Schmidt ---
Patch and discussion here.
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00212.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724
--- Comment #4 from Bernd Schmidt ---
Maybe we just need to test for that condition, even though it's ugly. However,
I think there are some other improvements we could make here.
Part of the problem seems to be what if_then_else_cond does on thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77345
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71321
--- Comment #6 from Bernd Schmidt ---
Author: bernds
Date: Wed Dec 21 16:45:33 2016
New Revision: 243861
URL: https://gcc.gnu.org/viewcvs?rev=243861&root=gcc&view=rev
Log:
PR target/71321
* config/i386/i386.md (lea_general_2b, l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71321
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78727
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309
Bernd Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78669
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78669
--- Comment #5 from Bernd Schmidt ---
Author: bernds
Date: Mon Dec 12 13:29:48 2016
New Revision: 243551
URL: https://gcc.gnu.org/viewcvs?rev=243551&root=gcc&view=rev
Log:
PR rtl-optimization/78669
* ira.c (combine_and_move_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309
--- Comment #6 from Bernd Schmidt ---
Author: bernds
Date: Mon Dec 12 13:01:28 2016
New Revision: 243550
URL: https://gcc.gnu.org/viewcvs?rev=243550&root=gcc&view=rev
Log:
Backport from mainline
2016-11-07 Bernd Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309
--- Comment #5 from Bernd Schmidt ---
Author: bernds
Date: Mon Dec 12 13:00:53 2016
New Revision: 243549
URL: https://gcc.gnu.org/viewcvs?rev=243549&root=gcc&view=rev
Log:
Backport from mainline
2016-11-07 Bernd Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
--- Comment #9 from Bernd Schmidt ---
I can't read that assembly language, but I'll take your word for it. I'm
testing the patch on x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
--- Comment #4 from Bernd Schmidt ---
Created attachment 40269
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40269&action=edit
Candidate patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
--- Comment #3 from Bernd Schmidt ---
Not sure it's that bad really. An unconditional trap is pretty much by
definition not performance-critical. Then again, there's a possible alternate
fix, which I'll attach.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78338
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78338
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78669
--- Comment #4 from Bernd Schmidt ---
Something like this perhaps.
Index: ira.c
===
--- ira.c (revision 242958)
+++ ira.c (working copy)
@@ -3705,6 +3705,14 @@ combine_a
||bernds at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #1 from Bernd Schmidt ---
Tried this with an aarch64-linux cross, and it seems to work now:
PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so
(test for errors
||bernds at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Bernd Schmidt ---
PR71443 was a similar issue for aarch64 which also seems to have gotten solved.
Closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436
--- Comment #14 from Bernd Schmidt ---
Maybe the match_parallel predicate ought to also check that you have more than
4 loads, so that it doesn't match anything that could also be handled by
ldmstm.md.
||bernds at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #1 from Bernd Schmidt ---
No longer seems to happen with a powerpc-linux cross and -frename-registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436
--- Comment #7 from Bernd Schmidt ---
Ooh, ouch. Maybe load_multiple needs a "&& reload_completed" predicate?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826
Bernd Schmidt changed:
What|Removed |Added
CC||sch...@linux-m68k.org
--- Comment #12 fr
||bernds at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Bernd Schmidt ---
Seems already fixed.
*** This bug has been marked as a duplicate of bug 70826 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
Bernd Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
--- Comment #13 from Bernd Schmidt ---
Author: bernds
Date: Mon Nov 28 08:59:01 2016
New Revision: 242908
URL: https://gcc.gnu.org/viewcvs?rev=242908&root=gcc&view=rev
Log:
PR rtl-optimization/78120
* rtlanal.c (insn_rtx_cost): R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
--- Comment #12 from Bernd Schmidt ---
Author: bernds
Date: Thu Nov 24 12:22:16 2016
New Revision: 242834
URL: https://gcc.gnu.org/viewcvs?rev=242834&root=gcc&view=rev
Log:
PR rtl-optimization/78120
* ifcvt.c (noce_conversion_pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
--- Comment #11 from Bernd Schmidt ---
Author: bernds
Date: Thu Nov 24 12:17:52 2016
New Revision: 242833
URL: https://gcc.gnu.org/viewcvs?rev=242833&root=gcc&view=rev
Log:
PR rtl-optimization/78120
* rtlanal.c (insn_rtx_cost): U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
--- Comment #10 from Bernd Schmidt ---
Author: bernds
Date: Thu Nov 24 12:16:47 2016
New Revision: 242832
URL: https://gcc.gnu.org/viewcvs?rev=242832&root=gcc&view=rev
Log:
PR rtl-optimization/78120
* config/i386/i386.c (ix86_rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
--- Comment #7 from Bernd Schmidt ---
Sorry James, I think these two got mixed up in my memory.
I've attached a candidate patch I'm testing. This tries to make a better effort
to calculate before/after costs for the speed case so we don't rely e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
--- Comment #6 from Bernd Schmidt ---
Created attachment 40028
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40028&action=edit
Candidate patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
--- Comment #4 from Bernd Schmidt ---
The other issue here seems to be simply that BRANCH_COST is 0 for predictable
branches on x86. Which makes the default implementation of the hook used here
if_info.max_seq_cost
= targetm.max_noce_ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
--- Comment #3 from Bernd Schmidt ---
Gah, that's obviously bogus and fails elsewhere. Still looking...
||bernds at gcc dot gnu.org,
||jgreenhalgh at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot
gnu.org
--- Comment #2 from Bernd Schmidt ---
Looks like a mismatch where we use different cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309
--- Comment #3 from Bernd Schmidt ---
Author: bernds
Date: Mon Nov 7 16:59:11 2016
New Revision: 241912
URL: https://gcc.gnu.org/viewcvs?rev=241912&root=gcc&view=rev
Log:
PR rtl-optimization/77309
* combine.c (make_compound_oper
||bernds at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot
gnu.org
--- Comment #2 from Bernd Schmidt ---
Investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733
--- Comment #2 from Bernd Schmidt ---
Author: bernds
Date: Fri Oct 7 12:21:55 2016
New Revision: 240863
URL: https://gcc.gnu.org/viewcvs?rev=240863&root=gcc&view=rev
Log:
c/
PR c++/69733
* c-decl.c (smallest_type_quals_location)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880
--- Comment #4 from Bernd Schmidt ---
Author: bernds
Date: Fri Oct 7 12:16:55 2016
New Revision: 240862
URL: https://gcc.gnu.org/viewcvs?rev=240862&root=gcc&view=rev
Log:
PR tree-optimization/77880
* expr.c (by_pieces_ninsns): U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880
--- Comment #2 from Bernd Schmidt ---
Hmm, a memcmp with ULONG_MAX as the size. Try this?
Index: expr.c
===
--- expr.c (revision 240429)
+++ expr.c (working copy)
@@ -785,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718
--- Comment #4 from Bernd Schmidt ---
So something like this maybe?
Index: builtins.c
===
--- builtins.c (revision 240511)
+++ builtins.c (working copy)
@@ -3707,11 +3707,13 @@ ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718
--- Comment #2 from Bernd Schmidt ---
Over here the testcase seems not to arrive in this function, and it prints the
same value (-5) twice, which I think is supposed to be expected?
Please clarify.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72774
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
1 - 100 of 490 matches
Mail list logo