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=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=91851
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #39 from Bernd Schmidt 2013-04-11
11:35:33 UTC ---
Created attachment 29857
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29857
Candidate fix
Ok, the --enable-checking made it reproducible. The lesson here is that a go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
--- Comment #20 from Bernd Schmidt 2013-04-25
10:12:12 UTC ---
Patch is OK, thanks Jakub - you were too fast for me on this one.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411
--- Comment #6 from Bernd Schmidt 2012-08-13
11:07:27 UTC ---
If the call to delete_trivially_dead_insns is supposed to eliminate only
pre-existing dead insns, then just moving it to the beginning of IRA fixes this
bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645
--- Comment #1 from Bernd Schmidt 2012-09-20
19:19:05 UTC ---
gcc.dg/pch and g++.dg/pch just completed here without problems. I don't see how
a scheduler patch could cause primarily PCH failures. Can you check your
bisection, and can you r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54643
--- Comment #2 from Bernd Schmidt 2012-09-20
22:01:57 UTC ---
Author: bernds
Date: Thu Sep 20 22:01:47 2012
New Revision: 191595
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191595
Log:
PR bootstrap/54643
* haifa-sch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688
--- Comment #5 from Bernd Schmidt 2012-09-26
13:18:41 UTC ---
(In reply to comment #3)
> It's r191493, the transformation is applied to a %sp-based load, which is
> invalid since the frame is destroyed, and the resulting offset is bogus:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688
--- Comment #7 from Bernd Schmidt 2012-09-26
13:50:06 UTC ---
Oh, I missed that it was a MINUS rtx. This is noncanonical RTL, it should be
(plus (sp) (negated constant)).
Does the bug persist if you fix the sparc port in this way?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688
--- Comment #9 from Bernd Schmidt 2012-09-26
14:13:31 UTC ---
Created attachment 28283
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28283
Candidate patch.
The offset range should not be an issue with the right constraints etc.; t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688
--- Comment #11 from Bernd Schmidt 2012-09-27
13:28:12 UTC ---
Hmm, strange. What if you just make a change like this:
@@ -4600,8 +4600,7 @@ parse_add_or_inc (struct mem_inc_info *m
if (!REG_P (SET_DEST (pat)))
return false;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688
--- Comment #14 from Bernd Schmidt 2012-09-28
20:33:00 UTC ---
Author: bernds
Date: Fri Sep 28 20:32:55 2012
New Revision: 191838
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191838
Log:
PR bootstrap/54688
* sched-de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
--- Comment #2 from Bernd Schmidt 2012-10-08
14:18:58 UTC ---
Could you attach both dumps? (and use -fsched-verbose=5)
Did your test include r191838?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
--- Comment #9 from Bernd Schmidt 2012-10-18
11:54:34 UTC ---
Created attachment 28482
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28482
Candidate patch.
Could you both please test this patch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54747
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
--- Comment #13 from Bernd Schmidt 2012-11-08
17:10:34 UTC ---
Author: bernds
Date: Thu Nov 8 17:10:26 2012
New Revision: 193332
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193332
Log:
PR rtl-optimization/54850
* s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
--- Comment #8 from Bernd Schmidt 2011-01-11
15:45:34 UTC ---
I think the real problem here is that when reloading autoincs, we somehow end
up with
(gdb) p spill_reg_store[3]
$42 = (rtx) 0xf7a1118c
(gdb) pr
(insn 3163 3161 3164 99 rectmm.c:1041
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
--- Comment #9 from Bernd Schmidt 2011-01-11
17:02:40 UTC ---
Created attachment 22945
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22945
Test patch
Could you try the following? It's a variant of a patch Richard Sandiford
recently posted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
--- Comment #14 from Bernd Schmidt 2011-01-19
19:31:20 UTC ---
(In reply to comment #13)
> Please consider reverting the reload change on the branch. I don't think we
> want to keep fiddling with reload there.
I don't see how this makes any sen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
--- Comment #20 from Bernd Schmidt 2011-01-23
21:11:27 UTC ---
Author: bernds
Date: Sun Jan 23 21:11:24 2011
New Revision: 169144
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169144
Log:
PR rtl-optimization/47166
* reload1.c (em
||bernds at gcc dot gnu.org
Resolution||FIXED
--- Comment #6 from Bernd Schmidt 2011-02-01
01:10:36 UTC ---
Fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
--- Comment #26 from Bernd Schmidt 2011-02-01
01:34:59 UTC ---
I'll be testing the backport and committing the patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
--- Comment #28 from Bernd Schmidt 2011-02-11
16:01:24 UTC ---
Author: bernds
Date: Fri Feb 11 16:01:19 2011
New Revision: 170053
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170053
Log:
PR rtl-optimization/47166
* reload1.c (em
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893
--- Comment #6 from Bernd Schmidt 2011-02-25
16:10:55 UTC ---
(In reply to comment #5)
> Similarly not queuing anything into frame_space lists
> when assign_stack_local is called from within assign_stack_temp_for_type would
> kill most of the sav
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893
--- Comment #8 from Bernd Schmidt 2011-02-25
17:24:15 UTC ---
(In reply to comment #7)
> My temptation would be to revert until someone can get in there and design
> things so that we either have a single list or there's clear rules for
> manipul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893
--- Comment #9 from Bernd Schmidt 2011-02-25
17:25:13 UTC ---
Created attachment 23468
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23468
Test patch
Does this fix it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50198
Bug #: 50198
Summary: New test gcc.c-torture/execute/scal-to-vec1.c fails on
many targets
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50215
--- Comment #2 from Bernd Schmidt 2011-08-28
11:44:05 UTC ---
How was this caused by my patch then? I can't even reproduce this here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232
--- Comment #2 from Bernd Schmidt 2011-08-30
11:31:34 UTC ---
Ugh, code prettyfication gone wrong. Will fix.
However, you'll probably also want to add "return" patterns to PA for
optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232
--- Comment #4 from Bernd Schmidt 2011-08-30
15:06:05 UTC ---
Surely the PA has some kind of return instruction?
Most ports define a "return" pattern with an insn condition that requires that
the epilogue is empty. In that case, jumps to the end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
--- Comment #8 from Bernd Schmidt 2011-09-02
14:49:51 UTC ---
I'm guessing it was this:
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02175.html
||2011-09-06
AssignedTo|unassigned at gcc dot |bernds at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #8 from Bernd Schmidt 2011-09-06
13:11:24 UTC ---
Created attachment 25202
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50326
--- Comment #2 from Bernd Schmidt 2011-09-09
11:22:00 UTC ---
Hmm, are you sure you bisected that correctly? I did a build on gcc60 with the
patch reverted, and it failed with the same error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249
--- Comment #7 from Bernd Schmidt 2011-09-27
14:55:16 UTC ---
Author: bernds
Date: Tue Sep 27 14:55:11 2011
New Revision: 179272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179272
Log:
PR rtl-optimization/50249
* reload1.c (rel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
--- Comment #7 from Bernd Schmidt 2011-10-05
17:17:17 UTC ---
Author: bernds
Date: Wed Oct 5 17:17:12 2011
New Revision: 179560
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179560
Log:
PR bootstrap/50621
* config/i386/i386.c (i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049
--- Comment #8 from Bernd Schmidt 2011-10-06
13:13:00 UTC ---
Author: bernds
Date: Thu Oct 6 13:12:50 2011
New Revision: 179607
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179607
Log:
PR target/49049
* config/arm/arm.md (arm_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588
--- Comment #14 from Bernd Schmidt 2011-10-06
13:30:31 UTC ---
It looks like ifcvt (or rather, can_move_insns_across_p) is doing the right
thing. The problem is that may_trap_or_fault_p returns false for the memory
reference with an out-of-range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
--- Comment #6 from Bernd Schmidt 2011-10-06
18:43:21 UTC ---
How do you build this? What's the target triplet?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
--- Comment #9 from Bernd Schmidt 2011-10-06
19:59:18 UTC ---
Created attachment 25434
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25434
Test patch
Can you give this a try? Seems to fix the testcase.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
--- Comment #11 from Bernd Schmidt 2011-10-07
12:10:11 UTC ---
I see none of these failures in the x86_64 test run with my last patch applied.
Can you confirm that it's fixed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
--- Comment #12 from Bernd Schmidt 2011-10-07
12:20:57 UTC ---
Sorry, commit didn't go through earlier - it's in now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049
--- Comment #9 from Bernd Schmidt 2011-10-07
12:56:55 UTC ---
Author: bernds
Date: Fri Oct 7 12:56:52 2011
New Revision: 179657
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179657
Log:
PR target/49049
* config/arm/arm.md (arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #4 from Bernd Schmidt 2011-10-12
16:46:23 UTC ---
This doesn't seem to happen with a cross compiler :(
When you say "in stage 2", do you mean the stage 1 compiler is crashing, or the
stage 2 compiler is crashing?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50721
--- Comment #8 from Bernd Schmidt 2011-10-14
13:23:58 UTC ---
It looks like gsl_poly_dd_taylor overwrites part of the caller's stack frame.
Specifically, this statement
w[size - 1] = 1.0;
appears to go out of bounds. Can someone who understands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50721
--- Comment #9 from Bernd Schmidt 2011-10-14
13:29:35 UTC ---
Hmm, even without understanding Fortran it looks like
real(fgsl_double) :: ra, xa(10), ya(10), da(10), di(10), d(2)
declares d as a 2 element array, but
#0 gsl_poly_dd_taylor (c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #7 from Bernd Schmidt 2011-10-17
11:40:25 UTC ---
AFAIK there's no IRIX6.5 machine in the compile farm. Can you debug a bit at
the point of the crash to see what's going on?
Configure won't let me build the target without "--neable-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #9 from Bernd Schmidt 2011-10-17
15:04:17 UTC ---
Well, shooting in the dark, let's get a few preliminaries out of the way - what
are the return values of dwarf2out_do_cfi_asm() and targetm.debug_unwind_info
()?
Also, a few of the la
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #14 from Bernd Schmidt 2011-10-17
16:34:42 UTC ---
Ok, so there are two restore_state notes following each other; note 374 and
note 375. We'll want a breakpoint in add_cfi to catch the two calls where these
notes are added. I'd expect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #16 from Bernd Schmidt 2011-10-17
17:37:11 UTC ---
Sorry, I was being imprecise - only the instances where we generate notes 374
and 375 are interesting. Can you identify these two?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50825
--- Comment #1 from Bernd Schmidt 2011-10-21
18:38:48 UTC ---
Author: bernds
Date: Fri Oct 21 18:38:44 2011
New Revision: 180310
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180310
Log:
PR bootstrap/50825
* sched-deps.c (add_dep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50836
--- Comment #2 from Bernd Schmidt 2011-10-24
11:03:16 UTC ---
Author: bernds
Date: Mon Oct 24 11:03:12 2011
New Revision: 180376
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180376
Log:
PR bootstrap/50836
* rtlanal.c: Swap inclu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50833
--- Comment #1 from Bernd Schmidt 2011-10-24
11:46:09 UTC ---
Author: bernds
Date: Mon Oct 24 11:46:04 2011
New Revision: 180377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180377
Log:
PR rtl-optimization/50833
* function.c (th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #19 from Bernd Schmidt 2011-10-24
12:10:21 UTC ---
It's really hard to run a gdb session this way. You're not a gcc newbie, and
you're the only one with an IRIX machine - can you not debug a bit further from
where we are now? You'll h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #14 from Bernd Schmidt 2011-11-10
13:34:02 UTC ---
Is this with your patch from comment 6? You really can't have a CONST_INT
inside a zero_extend; the abort is justified.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180
--- Comment #1 from Bernd Schmidt 2012-05-08
10:35:21 UTC ---
Created attachment 27344
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27344
Candidate patch
I think I have a theory of what's going wrong. Can you test this patch?
||bernds at gcc dot gnu.org
Resolution||FIXED
--- Comment #4 from Bernd Schmidt 2012-05-10
16:36:34 UTC ---
I think this got fixed in r154689.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381
--- Comment #2 from Bernd Schmidt 2012-05-16
22:30:53 UTC ---
What's it actually trying to access, and failing? Is dest NULL or something?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381
--- Comment #4 from Bernd Schmidt 2012-05-16
23:14:32 UTC ---
Created attachment 27427
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27427
Candidate patch
Ok, seriously weird call insns. If you can fix that in the port, it'll benefit
from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411
--- Comment #3 from Bernd Schmidt 2012-05-21
16:52:06 UTC ---
Odd. The following is in 190r.asmcons:
(insn 39 51 141 3 (set (reg:DI 135 [ D.1745 ])
(sign_extend:DI (reg:SI 132 [ j ]))) regehr.c:22 122
{*extendsidi2_rex64}
(expr_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373
--- Comment #11 from Bernd Schmidt 2012-05-21
21:37:05 UTC ---
Author: bernds
Date: Mon May 21 21:37:01 2012
New Revision: 187745
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187745
Log:
PR rtl-optimization/53373
* caller-save.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411
--- Comment #4 from Bernd Schmidt 2012-05-25
18:32:40 UTC ---
Looks like an earlier dce pass (during .ce2) leaves a dead insn lying around.
Bug in DCE?
||bernds at gcc dot gnu.org
Resolution||FIXED
--- Comment #13 from Bernd Schmidt 2012-06-20
18:30:54 UTC ---
Yeah.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
--- Comment #1 from Bernd Schmidt 2012-02-16
19:47:29 UTC ---
Please attach the reginfo.ii file.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
--- Comment #3 from Bernd Schmidt 2012-02-16
20:43:03 UTC ---
Not reproducible with a cross compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
--- Comment #9 from Bernd Schmidt 2012-02-23
15:41:49 UTC ---
(In reply to comment #8)
> This reproduces only on Solaris 8 because the sort of the ready list isn't
> stable in the presence of debug insns, given that rank_for_schedule isn't
> anti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52425
--- Comment #4 from Bernd Schmidt 2012-03-02
14:22:54 UTC ---
For some reason I can never reproduce sparc bugs with cross compilers. The
original testcase doesn't fail here; the reduced one fails but with a different
error message, and it fails i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813
Bernd Schmidt changed:
What|Removed |Added
CC|bernds at gcc dot gnu.org |
--- Comment #14 from Bernd Schmidt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573
--- Comment #2 from Bernd Schmidt 2012-04-13
13:02:03 UTC ---
(expr_list:REG_DEAD (reg:SI 3 %d3 [236])
(expr_list:REG_UNUSED (reg:SI 3 %d3 [236])
The REG_DEAD note is bogus and confuses the renamer. Only REG_UNUSED should be
on this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52997
Bernd Schmidt changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |bernds at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52997
--- Comment #3 from Bernd Schmidt 2012-04-26
13:25:48 UTC ---
Author: bernds
Date: Thu Apr 26 13:25:41 2012
New Revision: 186875
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186875
Log:
* PR middle-end/52997
* ira.c (find_moveab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52940
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52940
--- Comment #2 from Bernd Schmidt 2012-04-26
14:20:50 UTC ---
Author: bernds
Date: Thu Apr 26 14:20:39 2012
New Revision: 186877
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186877
Log:
PR middle-end/52940
* machmode.h (CLASS_HA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52997
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791
--- Comment #10 from Bernd Schmidt ---
(In reply to John David Anglin from comment #9)
> Any chance the candidate patch can be submitted?
I guess this means you've tested it and it works?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51003
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
||bernds at gcc dot gnu.org
Resolution||FIXED
--- Comment #3 from Bernd Schmidt 2011-12-21
01:22:08 UTC ---
Fixed, I think?
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #20 from Bernd Schmidt 2012-12-04
11:06:07 UTC ---
Created attachment 28873
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28873
Another patch
Here's another attempt, given that it seems to be the speculation code that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814
--- Comment #9 from Bernd Schmidt 2012-12-08
14:08:52 UTC ---
Created attachment 28900
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28900
Candidate patch
Try this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814
Bernd Schmidt changed:
What|Removed |Added
Attachment #28900|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68730
--- Comment #14 from Bernd Schmidt ---
It does look like an issue with lra-remat...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522
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=69522
--- Comment #8 from Bernd Schmidt ---
Ok so the warning is irrelevant. Slightly improved testcase that doesn't have
it:
struct str {};
struct {
struct str b;
float c[1];
int d[1];
float e[2];
int f[1];
} a = {{}, 0, {0.5}, 0, 0, {0}};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
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=69570
--- Comment #8 from Bernd Schmidt ---
Looks like it can be slightly reduced, removing not executed paths.
template constexpr inline const T &
min (const T &a, const T &b)
{
if (b < a)
return b;
return a;
}
template < typename T > const
1 - 100 of 490 matches
Mail list logo
