http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55381
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662
--- Comment #8 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #7)
> seems to ICE due to endless recursion with -O2 -m32 (every force_reg causes
> another force_reg, at least in x86_64-linux -> powerpc64-linux cross).
I see a simi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67281
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #10 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662
--- Comment #12 from Peter Bergner ---
Should we add an assert somewhere to ensure that flag_pic and
TARGET_RELOCATABLE are consistent?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
--- Comment #9 from Peter Bergner ---
I think we have another bug in addition to the bug where we reuse a register
that is already in use. We have the rtl below which is used to initialize a[]
before the call to foo:
(insn 5 39 40 2 (set (reg/f
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We ICE with the following test case.
bergner@genoa:~/gcc/BUGS/DFP/arith128-P8AT9/src$ cat ice.i
typedef struct
{
_Decimal128 td0;
_Decimal128 td1;
} TDx2_t;
TDx2_t
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
If we compile the following testcase, we see uneeded stores to the stack
followed by immediate loads from the same stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
Peter Bergner changed:
What|Removed |Added
Target||powerpc64le-linux
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #2 from Peter Bergner ---
One interesting point is if we delete the "return result;" that is within the
then clause and fall thru to the end "return result;" with is logically
identical, then we get the code we want:
D256_add_finite:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70928
--- Comment #2 from Peter Bergner ---
Can powers of 2 values be generated with a splat followed by a shift?
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Yet another fallout from the switch changes.
bergner@pike:~/gcc/BUGS/$ cat bug.i
struct a {
int b;
int c;
};
void
foo (void)
{
struct a *e;
switch (e->c)
{
cas
||2017-07-26
CC||wschmidt at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Peter Bergner ---
Mine. Testing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81564
--- Comment #2 from Peter Bergner ---
Author: bergner
Date: Thu Jul 27 14:05:14 2017
New Revision: 250628
URL: https://gcc.gnu.org/viewcvs?rev=250628&root=gcc&view=rev
Log:
gcc/
PR middle-end/81564
* tree-cfg.c (group_case_labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81564
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81564
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72804
--- Comment #5 from Peter Bergner ---
I'm testing a patch. The root cause is that the vsx_le_permute_*,
vsx_le_perm_load_* and vsx_le_perm_store_* patterns do not support the TImode
values in integer registers and it is these patterns that LRA i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72804
--- Comment #6 from Peter Bergner ---
Author: bergner
Date: Thu Aug 17 15:56:48 2017
New Revision: 251153
URL: https://gcc.gnu.org/viewcvs?rev=251153&root=gcc&view=rev
Log:
gcc/
PR target/72804
* config/rs6000/vsx.md (*vsx_le_per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72804
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #6 from Peter Bergner ---
I have a patch I'm testing. The problem is that rs6000_set_current_function()
is not clearing the rs6000_previous_fndecl cache correctly when it needs to.
With the test case, we notice
||2017-08-18
CC||bergner at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Peter Bergner ---
Confirmed.
GCC 6, GCC 7 and trunk all generate the same RTL going into IRA. This includes
a register copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #7 from Peter Bergner ---
Author: bergner
Date: Fri Aug 18 23:41:41 2017
New Revision: 251190
URL: https://gcc.gnu.org/viewcvs?rev=251190&root=gcc&view=rev
Log:
gcc/
PR target/80210
* config/rs6000/rs6000.c (rs6000_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #8 from Peter Bergner ---
Fixed on trunk. I'm testing backports to the open release branches and will
commit them after the trunk patch has aged a bit (next week?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #9 from Peter Bergner ---
Author: bergner
Date: Tue Aug 22 20:08:51 2017
New Revision: 251291
URL: https://gcc.gnu.org/viewcvs?rev=251291&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-08-17 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #10 from Peter Bergner ---
Author: bergner
Date: Tue Aug 22 20:10:58 2017
New Revision: 251292
URL: https://gcc.gnu.org/viewcvs?rev=251292&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-08-17 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #11 from Peter Bergner ---
Author: bergner
Date: Tue Aug 22 20:13:11 2017
New Revision: 251293
URL: https://gcc.gnu.org/viewcvs?rev=251293&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-08-17 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #13 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80503
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72804
--- Comment #8 from Peter Bergner ---
Author: bergner
Date: Wed Aug 23 20:03:46 2017
New Revision: 251318
URL: https://gcc.gnu.org/viewcvs?rev=251318&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-08-17 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72804
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #9 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700
--- Comment #3 from Peter Bergner ---
I don't think my patch is the cause of the problem, more like it just exposed
more problems in the SPE code. After RA, we call into LRA to spill a pseudo
that did not get allocated a register:
Breakpoint 5,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700
--- Comment #5 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Peter Bergner from comment #3)
>> (gdb) p reg_renumber[564]
>> $1 = 65
>
> 65 is LR. What.
Heh, I was thinking the same thing. Seriously, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
Peter Bergner changed:
What|Removed |Added
Status|CLOSED |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #16 from Peter Bergner ---
While investigating the new failure in Comment 15, I modified the test case
slightly to move the #pragma to the beginning of the test case. I found I get
another similar looking ICE, but which isn't the sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2017-05-11
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Peter Bergner ---
Confirmed. I'll have a look.
||bergner at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Peter Bergner ---
This is a dup.
*** This bug has been marked as a duplicate of bug 80707 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80707
Peter Bergner changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80714
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80707
--- Comment #4 from Peter Bergner ---
David and HJ, the following patch fixes the ICE Markus reported, so can you try
the following patch to see if it fixes your bootstrap issues?
Index: tree-cfg.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80707
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80707
--- Comment #8 from Peter Bergner ---
Author: bergner
Date: Fri May 12 17:13:07 2017
New Revision: 247984
URL: https://gcc.gnu.org/viewcvs?rev=247984&root=gcc&view=rev
Log:
gcc/
PR middle-end/80707
* tree-cfg.c: Remove cfg edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80707
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80707
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #10 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80382
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
--- Comment #6 from Peter Bergner ---
I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
--- Comment #7 from Peter Bergner ---
I have it recreated. Digging into it.
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #8 from Peter Bergner ---
I'm testing a patch. The special thing here, is that we try combining multiple
case statements that lead to the same block and that block contains a
__builtin_unreachable() call. If we remove the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
--- Comment #10 from Peter Bergner ---
Author: bergner
Date: Wed May 17 14:05:21 2017
New Revision: 248155
URL: https://gcc.gnu.org/viewcvs?rev=248155&root=gcc&view=rev
Log:
gcc/
PR middle-end/80775
* tree-cfg.c: Move deletion of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #12 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823
--- Comment #3 from Peter Bergner ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823
--- Comment #4 from Peter Bergner ---
Stupid thinko on my part. An extra increment is causing us to skip some of the
case labels in the switch statement, which only causes an ICE/problem if the
skipped case happens to point to the same unreachab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823
--- Comment #5 from Peter Bergner ---
Author: bergner
Date: Wed May 24 12:10:54 2017
New Revision: 248408
URL: https://gcc.gnu.org/viewcvs?rev=248408&root=gcc&view=rev
Log:
gcc/
PR middle-end/80823
* tree-cfg.c (group_case_labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #7 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193
Peter Bergner changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
--- Comment #4 from Peter Bergner ---
Will do, but as Jakub said, we'll need the compiler options used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
--- Comment #14 from Peter Bergner ---
I don't see this on powerpc64le-linux using -O3. What target are you using?
Any options other than -O3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
--- Comment #15 from Peter Bergner ---
(In reply to Peter Bergner from comment #14)
> I don't see this on powerpc64le-linux using -O3. What target are you using?
> Any options other than -O3?
Doesn't fail for me on x86_64 either, so I'll need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
--- Comment #5 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #3)
> I don't see g++ options mentioned anywhere, the testcase compiles even with
> latest trunk just fine with -O0 -std=c++17 or -O2 -std=c++17.
...and compiles fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193
--- Comment #5 from Peter Bergner ---
Given Alan's comments, I think the best thing to do here is to just emit a
warning when using those builtins when the compiler was configured to use an
old glibc.
If someone disagrees, let me know now, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
Peter Bergner changed:
What|Removed |Added
Status|REOPENED|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193
--- Comment #8 from Peter Bergner ---
(In reply to Michael Meissner from comment #4)
> I think for the problem of using __builtin_cpu_, we should issue a
> warning
> (not a fatal error) if the configured GLIBC is too old saying you need to link
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #8 from Peter Bergner ---
So we have a switch statement with onc case and a default case statement. The
normal case statement contains an __builtin_unreachable() call, so we delete
the case statement, leaving us with only the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
--- Comment #10 from Peter Bergner ---
Created attachment 41647
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41647&action=edit
Proposed patch
(In reply to Richard Biener from comment #9)
> (In reply to Peter Bergner from comment #8)
>> S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
--- Comment #11 from Peter Bergner ---
(In reply to Peter Bergner from comment #10)
> I'm testing the attached patch which fixes the ICE.
Except this ICEs on the following simple test case. I'll see if this is due to
a simple oversite or ...
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
--- Comment #12 from Peter Bergner ---
(In reply to Peter Bergner from comment #11)
> (In reply to Peter Bergner from comment #10)
> > I'm testing the attached patch which fixes the ICE.
>
> Except this ICEs on the following simple test case. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
Peter Bergner changed:
What|Removed |Added
Attachment #41647|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
--- Comment #14 from Peter Bergner ---
...or maybe simpler even would be:
Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c (revision 249649)
+++ gcc/cfgexpand.c (working copy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
--- Comment #16 from Peter Bergner ---
Author: bergner
Date: Thu Jun 29 12:58:32 2017
New Revision: 249783
URL: https://gcc.gnu.org/viewcvs?rev=249783&root=gcc&view=rev
Log:
gcc/
PR middle-end/81194
* cfgexpand.c (expand_gimple_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #18 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #17 from Peter Bergne
||2016-11-22
CC||bergner at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Peter Bergner ---
Confirmed with the following creduced test case:
bergner@genoa:~/gcc/BUGS/GNU_SPE$ cat pr78458.i
long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #5 from Peter Bergner ---
gdb show we don't like:
(gdb) frame 1
#1 0x10a7d328 in lra_set_insn_recog_data (insn=0x3fffb5584340) at
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:963
963 gcc_ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #6 from Peter Bergner ---
This whole lra reload is due to us trying to split insns like the following:
(insn 129 281 264 9 (set (subreg:TF (reg:TI 315 [orig:262 p1 ] [262]) 0)
(reg/v:TF 173 [ p1 ])) "pr78458.i":17 1930 {*frob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #7 from Peter Bergner ---
Here's a smaller test case that induces spilling which leads to our ICE:
extern void bar (void);
_Complex
foo (long double p1)
{
_Complex e;
bar ();
asm volatile ("# clobbers" :::
"r14"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #8 from Peter Bergner ---
Last one, I promise. We don't need _Complex at all:
extern void bar (void);
long double
foo (long double p1)
{
bar ();
asm volatile ("# clobbers" :::
"r14", "r15", "r16", "r17", "r18", "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #9 from Peter Bergner ---
The IFmode usage is coming from HARD_REGNO_CALLER_SAVE_MODE(8, 2, TFmode)
returning IFmode, which comes from choose_hard_reg_mode (8, 2, false). As a
quick hack, I modified HARD_REGNO_CALLER_SAVE_MODE() to i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #10 from Peter Bergner ---
(In reply to Peter Bergner from comment #9)
> I'm testing the following patch (which is a little more general) on a
> powerpc64le-linux bootstrap to see if this survives.
Ok, this patch passed bootstrap and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #13 from Peter Bergner ---
Author: bergner
Date: Thu Nov 24 02:07:51 2016
New Revision: 242818
URL: https://gcc.gnu.org/viewcvs?rev=242818&root=gcc&view=rev
Log:
gcc/
PR target/78458
* config/rs6000/rs6000.h (HARD_REG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
--- Comment #3 from Peter Bergner ---
I cannot recreate this using r242827 of the FSF 6 branch. What configure
options are you using? ...and in case it makes a difference (it can), what
binutils version?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
--- Comment #6 from Peter Bergner ---
(In reply to Breno Leitao from comment #5)
> I can reproduce this (or a very similar version of this) bug on my system.
>
> I am seeing this failure when compiling package yadifa-2.2.2 on Debian
> testing w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
--- Comment #8 from Peter Bergner ---
(In reply to Breno Leitao from comment #7)
> Created attachment 40182 [details]
> gcc dump with pre processed file
Ok, this on I have recreated. I'll dig into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #9 from Peter Bergner ---
(In reply to jos...@codesourcery.com from comment #7)
> What are the actual high and low doubles in the return from powl? The
> simplest reason for the reported result here would be that powl returns a
> r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71977
--- Comment #2 from Peter Bergner ---
(In reply to Michael Meissner from comment #1)
> Note in terms of the code in general, you have to make sure that the float
> value is converted to vector form before you do AND/OR/etc. on it. This is
> beca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69153
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69153
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #2 from Peter Bergner ---
So we're hitting this code in lra-assigns.c:lra_assign():1612:
if (flag_checking && !flag_ipa_ra)
for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
if (lra_reg_info[i].nrefs != 0 && reg_renumbe
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #3 from Peter Bergner ---
Here is a smaller test case which still fails at -O0 and -O1:
bergner@genoa:~/gcc/BUGS/PR78516$ cat pr78516.i
extern void bar (void);
double
foo (double one, double arg)
{
bar ();
volatile double neg0
601 - 700 of 1504 matches
Mail list logo
