[Bug target/100693] PPC: missing 64-bit addg6s

[willschm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100693

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #2 from Will Schmidt  ---
(In reply to Segher Boessenkool from comment #1)
> Confirmed.  The define_insn for it is for SImode only as well.

I see the SImode for the define as mentioned

(define_insn "addg6s"
  [(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI [(match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")]
   UNSPEC_ADDG6S))]
  "TARGET_POPCNTD"
  "addg6s %0,%1,%2"
  [(set_attr "type" "integer")])


But.. a simple testcase with unsigned long long parms builds ok.   (both gcc 11
and older gcc 9).  


unsigned long long bcd_arith_longlong (unsigned long long a, unsigned long long
b)
{
return __builtin_addg6s (a, b); 
}

Expand shows.. this instruction is using a subset, erm, subreg of the inputs. 
Is this expected behavior?

(insn 11 10 12 2 (set (reg:SI 128)
(unspec:SI [
(subreg/s/v:SI (reg:DI 121 [ _1 ]) 0)
(subreg/s/v:SI (reg:DI 122 [ _2 ]) 0)
] UNSPEC_ADDG6S)) "./addg6s.c":11:16 -1
 (nil))

[Bug target/104643] gcc/config/rs6000/driver-rs6000.cc: 2 * pointless call ?

[willschm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104643

Will Schmidt  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||willschm at gcc dot gnu.org

--- Comment #2 from Will Schmidt  ---
(In reply to David Binderman from comment #0)
> Static analyser cppcheck says:
> 
> 1.
> 
> gcc/config/rs6000/driver-rs6000.cc:578:13: style: Variable 'cache' is
> reassigned a value before the old one has been used. [redundantAssignment]
> 
> Source code is
> 
>   cache = detect_caches_freebsd ();
>   /* FreeBSD PPC does not provide any cache information yet.  */
>   cache = "";
> 
> The function call looks pointless.
> 
> 2.
> 
> gcc/config/rs6000/driver-rs6000.cc:582:13: style: Variable 'cache' is
> reassigned a value before the old one has been used. [redundantAssignment]

There is a similar pattern for the __linux__ if/else path. 

#elif defined (__FreeBSD__)
  cache = detect_caches_freebsd ();
  /* FreeBSD PPC does not provide any cache information yet.  */
  cache = "";
#elif defined (__linux__)
  cache = detect_caches_linux ();
  /* PPC Linux does not provide any cache information yet.  */
  cache = "";
#else

It looks like the __linux__ reassignment has been there for quite a while as
well.
when not overridden, the detect_caches_foo functions call describe_cache, which
builds a string ala
  sprintf (l1size, "--param l1-cache-size=%u", l1_sizekb);
  sprintf (line, "--param l1-cache-line-size=%u", l1_line);
  sprintf (l2size, "--param l2-cache-size=%u", l2_sizekb);
  return concat (l1size, " ", line, " ", l2size, " ", NULL);

We've obviously not noticed that the param values are no longer being set, for
quite a while.  Is there value in re-enabling this, or could this simply be
removed?The other logic in detect_caches_linux() does set values for
l1_sizekb and friends, based on the detected platform string, which has a
special case for power6* or not.  Possibly would need some touch-ups for
processors later than power6.

[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946

[willschm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686

--- Comment #11 from Will Schmidt  ---
(In reply to Bill Schmidt from comment #10)
> It turns out not to be undocumented -- but I'd like to remove it anyway. 
> Any objections?

Realistically I believe I was the only user of that feature, was to help with
comparing the before/after codegen for the builtins as I added the gimple
folding logic for them.

No objections for removal of the option from me.

Knowing the history and the compromises involved, at this point I actually
encourage the removal of the option.  :-) 
Thanks,
-Will

[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840

[willschm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051

Will Schmidt  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #6 from Will Schmidt  ---
(In reply to Martin Liška from comment #4)
> All right, so I would ideally use:
> 
> /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target
> { has_arch_pwr7 } } } } */
> 
> but I see the following problem with detection of the target:
> 
>  78 Executing on host: /dev/shm/objdir/gcc/xgcc -B/dev/shm/objdir/gcc/
> arch_pwr759296.c  -fdiagnostics-plain-output  -S   -o arch_pwr759296.s   
> (timeout = 300)
>  79 spawn -ignore SIGHUP /dev/shm/objdir/gcc/xgcc -B/dev/shm/objdir/gcc/
> arch_pwr759296.c -fdiagnostics-plain-output -S -o arch_pwr759296.s^M
>  80 arch_pwr759296.c:3:18: error: #error does not have power7 support.^M
> 
>  81 compiler exited with status 1   
> 
>  82 output is:  
> 
>  83 arch_pwr759296.c:3:18: error: #error does not have power7 support.^M
> 
> 
> Note the 
> 
> #ifndef _ARCH_PWR7
> 
> only works when one uses -mcpu=native (or a corresponding -mflag), am I
> right?
> Shouldn't the function check_effective_target_has_arch_pwr7 pass
> -mcpu=native?

I would expect it to pass with -mcpu=native.   
Needs a closer look, not sure if I can get to it in short order.  Added Bill
and Segher to cc.

[Bug target/101882] New: modulus with input and output set to a hard register

[willschm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882

Bug ID: 101882
   Summary: modulus with input and output set to a hard register
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Noted on powerpc using recent GCC.
  gcc version 12.0.0 20210812 (experimental) (GCC) 


foofoo9.c:
  register a __asm__("r20");
  b() { a = a % 9 ; }

# does not occur with -O0, or with -mcpu=power8.
$ gcc  -O -mcpu=power9 foofoo9.c 

foofoo9.c: In function ‘b’:
foofoo9.c:2:19: error: unable to generate reloads for impossible constraints:
2 | b() { a = a % 9 ; }
  |   ^
(insn 7 9 12 2 (set (reg/v:SI 20 20 [ a ])
(mod:SI (reg/v:SI 20 20 [ a ])
(reg:SI 120))) "foofoo9.c":2:13 183 {*modsi3}
 (expr_list:REG_DEAD (reg:SI 120)
(nil)))
during RTL pass: reload
foofoo9.c:2:19: internal compiler error: in process_alt_operands, at
lra-constraints.c:3108
0x101d9597 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/willschm/gcc/gcc-baseline/gcc/rtl-error.c:108
0x10912b4f process_alt_operands
/home/willschm/gcc/gcc-baseline/gcc/lra-constraints.c:3108
0x10912b4f curr_insn_transform
/home/willschm/gcc/gcc-baseline/gcc/lra-constraints.c:4102
0x10916dbb lra_constraints(bool)
/home/willschm/gcc/gcc-baseline/gcc/lra-constraints.c:5168
0x108fc46f lra(_IO_FILE*)
/home/willschm/gcc/gcc-baseline/gcc/lra.c:2336
0x1089be8b do_reload
/home/willschm/gcc/gcc-baseline/gcc/ira.c:5932
0x1089be8b execute
/home/willschm/gcc/gcc-baseline/gcc/ira.c:6118
Please submit a full bug report,

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

[willschm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692

--- Comment #14 from Will Schmidt  ---


Using gdb/vgdb to view the valgrind shadow register values, it looks like
the uninitialized values are being loaded in via the
_restgpr0_25 call being made at the end of isVariable().

Dump of assembler code for function isVariable(char*):
   0x16ac <+0>: lis r2,4098
   0x16b0 <+4>: addir2,r2,32512
   0x16b4 <+8>: mflrr0
   0x16b8 <+12>:addis   r9,r2,-2
   0x16bc <+16>:addir9,r9,-30152

(here: r1 is 0x1fff00e440 ; shadow registers r24..r31 show zero).

   0x16c0 <+20>:bl  0x1820 <_savegpr0_25>

savegpr0_25 stores r25 thru r31 into the stack (offset of r1)

   0x16c4 <+24>:stdur1,-128(r1)

And stack pointer updates itself.   r1 is now 0x1fff00e3c0


   0x16c8 <+28>:ld  r29,0(r9)
   0x16cc <+32>:ld  r28,8(r9)
   0x16d0 <+36>:nop
   0x16d4 <+40>:mr  r30,r3
   0x16d8 <+44>:ld  r27,16(r9)
   0x16dc <+48>:li  r31,0
   0x16e0 <+52>:addir25,r2,-32456
   0x16e4 <+56>:addir26,r1,32
   0x16e8 <+60>:std r29,32(r1)
   0x16ec <+64>:std r28,40(r1)
   0x16f0 <+68>:rldicr  r9,r31,3,60
   0x16f4 <+72>:li  r5,2
   0x16f8 <+76>:std r27,48(r1)
   0x16fc <+80>:mr  r3,r30
   0x1700 <+84>:ldx r4,r26,r9
   0x1704 <+88>:bl  0x14c0
<0023.plt_call.strncmp@@GLIBC_2.17>
   0x1708 <+92>:ld  r2,24(r1)
   0x170c <+96>:mr. r9,r3
   0x1710 <+100>:   bne 0x1718 
   0x1714 <+104>:   stw r9,0(r25)
   0x1718 <+108>:   cmpldi  r31,1
   0x171c <+112>:   bne 0x1728 

r1 still 0x1fff00e3c0

   0x1720 <+116>:   addir1,r1,128

now r1 is 0x1fff00e440

   0x1724 <+120>:   b   0x1844 <_restgpr0_25>

and as we progress through restoring the regs, the valgrind shadow registers
are indicating the values are uninitialized as they are restored off the stack
(r1).

   0x1964 <_restgpr0_25>:   ld  r25,-56(r1)

(gdb) p/x $r25s1
$29 = 0x

(gdb) p/x $r26s1
$31 = 0x0
=> 0x1968 <_restgpr0_26>:   ld  r26,-48(r1)
(gdb) p/x $r26s1
$32 = 0x

   0x196c <_restgpr0_27>:   ld  r27,-40(r1)
   0x1970 <_restgpr0_28>:   ld  r28,-32(r1)
   0x1974 <_restgpr0_29>:   ld  r0,16(r1)



The _restgpr* and _savegpr* functions are not referenced when the test is built
at other optimization levels.  (I've looked at disassembly from -O0 .. -O4).

I do note that the _restgpr and _savegpr functions are called differently. 
savegpr is called with bl while the restgpr is called via a direct branch; i
can't immediately tell if this is by design or if it is in error.


17d0:   71 01 00 48 bl  1940 <_savegpr0_25>
1834:   30 01 00 48 b   1964 <_restgpr0_25>

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

[willschm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692

--- Comment #11 from Will Schmidt  ---
(In reply to Mark Wielaard from comment #10)
> (In reply to Will Schmidt from comment #9)
> > (In reply to Segher Boessenkool from comment #5)
> > > Have you tried a new valgrind?
> > > 
> > > Either this is (or was) a known problem in valgrind, or it is related to
> > > one.  Cc:ing Aaron, he might know more (he wrote the GCC optimisations
> > > that expose the problem).
> > 
> > 
> > I've recreated against new (built out of upstream git) valgrind:
> > with --track-origins=yes
> > 
> > 
> > ==37507== 
> > argv[0]=./a.out
> > ==37507== Use of uninitialised value of size 8
> > ==37507==at 0x1618: main (pr9862.C:16)
> > ==37507==  Uninitialised value was created by a stack allocation
> > ==37507==at 0x17D4: isVariable(char*) (pr9862.C:5)
> 
> Trying to get hold of a ppc64 setup. But could you try with --vgdb-error=0
> and then (in another window) gdb ./a.out and target remote | vgdb and
> continue till you get the TRAP. Then disassamble so we can see the exact
> instruction that generates the use of uninitialised value?

Yes.  so this traps on a ld instruction upon the return from the isVariable
call.  As seen below here:


Window #1:
==79608== 
argv[0]=./a.out
==79608== Use of uninitialised value of size 8
==79608==at 0x1618: main (pr9862.C:16)
==79608==  Uninitialised value was created by a stack allocation
==79608==at 0x17D4: isVariable(char*) (pr9862.C:5)
==79608== 
==79608== (action on error) vgdb me ... 

Window #2:
(gdb) target remote | vgdb
Remote debugging using | vgdb
relaying data between gdb and process 79608
warning: remote target does not support file transfer, attempting to access
files from local filesystem.
Reading symbols from /lib64/ld64.so.2...
(No debugging symbols found in /lib64/ld64.so.2)
0x04001720 in ?? () from /lib64/ld64.so.2
(gdb) 
(gdb) set disassemble-next-line on 
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
main (argc=, argv=0x1fff00e8a8) at pr9862.C:16
16len = __builtin_strlen (argv[1]);
=> 0x1618 :   08 00 7f e8 ld 
r3,8(r31)
   0x161c :   a5 ff ff 4b bl 
0x15c0 <0037.plt_call.strlen@@GLIBC_2.17>
   0x1620 :   18 00 41 e8 ld 
r2,24(r1)
   0x1624 :   00 00 00 60 nop
   0x1628 :   70 00 21 38 addi   
r1,r1,112
   0x162c :   50 81 62 90 stw
r3,-32432(r2)

(gdb) disas
Dump of assembler code for function main(int, char**):
   0x15e0 <+0>: lis r2,4098
   0x15e4 <+4>: addir2,r2,32512
   0x15e8 <+8>: mflrr0
   0x15ec <+12>:std r31,-8(r1)
   0x15f0 <+16>:addis   r3,r2,-2
   0x15f4 <+20>:mr  r31,r4
   0x15f8 <+24>:addir3,r3,-29882
   0x15fc <+28>:std r0,16(r1)
   0x1600 <+32>:stdur1,-112(r1)
   0x1604 <+36>:ld  r4,0(r4)
   0x1608 <+40>:bl  0x1580
<0037.plt_call.printf@@GLIBC_2.17>
   0x160c <+44>:ld  r2,24(r1)
   0x1610 <+48>:ld  r3,0(r31)
   0x1614 <+52>:bl  0x17c4 
=> 0x1618 <+56>:ld  r3,8(r31)
   0x161c <+60>:bl  0x15c0
<0037.plt_call.strlen@@GLIBC_2.17>
   0x1620 <+64>:ld  r2,24(r1)
   0x1624 <+68>:nop
   0x1628 <+72>:addir1,r1,112
   0x162c <+76>:stw r3,-32432(r2)
   0x1630 <+80>:li  r3,0
   0x1634 <+84>:b   0x198c <_restgpr0_31>
   0x1638 <+88>:.long 0x0
   0x163c <+92>:.long 0x1000900
   0x1640 <+96>:.long 0x180
End of assembler dump.
(gdb)  




WIndow#1:

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

[willschm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #9 from Will Schmidt  ---
(In reply to Segher Boessenkool from comment #5)
> Have you tried a new valgrind?
> 
> Either this is (or was) a known problem in valgrind, or it is related to
> one.  Cc:ing Aaron, he might know more (he wrote the GCC optimisations
> that expose the problem).


I've recreated against new (built out of upstream git) valgrind:
with --track-origins=yes


==37507== 
argv[0]=./a.out
==37507== Use of uninitialised value of size 8
==37507==at 0x1618: main (pr9862.C:16)
==37507==  Uninitialised value was created by a stack allocation
==37507==at 0x17D4: isVariable(char*) (pr9862.C:5)

[Bug target/96139] Vector element extract mistypes long long int down to long int

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139

Will Schmidt  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #10 from Will Schmidt  ---
fix committed. closing out.

[Bug target/96139] Vector element extract mistypes long long int down to long int

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139

Will Schmidt  changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #8 from Will Schmidt  ---
*** Bug 85198 has been marked as a duplicate of this bug. ***

[Bug target/85198] long long int vector mistaken as long int vector

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85198

Will Schmidt  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||willschm at gcc dot gnu.org

--- Comment #6 from Will Schmidt  ---
This is a duplicate of PR96139.

*** This bug has been marked as a duplicate of bug 96139 ***

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952

Will Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Will Schmidt  ---
fix committed, should be done here.   Thanks.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952

Will Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #19 from Will Schmidt  ---
closed.

[Bug target/96139] Vector element extract mistypes long long int down to long int

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #5 from Will Schmidt  ---
(In reply to Bill Schmidt from comment #2)
> Have you tried it for -m32, out of curiosity?

Local experimentation indicates building with -m32 does not report the warning.

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94954

Will Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from Will Schmidt  ---
Fixed, Closing.

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94954

Will Schmidt  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Will Schmidt  ---
Should now be fixed in all of the right places.  
closing. 
Thanks

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952

--- Comment #16 from Will Schmidt  ---
(In reply to Mikael Pettersson from comment #15)
> (In reply to Will Schmidt from comment #14)
> > (In reply to Will Schmidt from comment #13)
> > > Created attachment 48871 [details]
> > > proposed patch
> > > 
> > > Attached patch appears sufficient to resolve the issue on the 970 based 
> > > box
> > > I have access to.
> > 
> > Mikael, would be appreciated if you could give that a run-through to confirm
> > it fixes the problem on your system.
> > thanks,
> 
> I can confirm that this patch restores gcc-8 bootstrap with the older
> binutils.

Thanks :-) 
Patch posted to list for review.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952

--- Comment #14 from Will Schmidt  ---
(In reply to Will Schmidt from comment #13)
> Created attachment 48871 [details]
> proposed patch
> 
> Attached patch appears sufficient to resolve the issue on the 970 based box
> I have access to.

Mikael, would be appreciated if you could give that a run-through to confirm it
fixes the problem on your system.
thanks,

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952

--- Comment #13 from Will Schmidt  ---
Created attachment 48871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48871=edit
proposed patch

Attached patch appears sufficient to resolve the issue on the 970 based box I
have access to.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952

--- Comment #10 from Will Schmidt  ---
(In reply to Segher Boessenkool from comment #8)
> So what is the instruction / builtin / anything where it fails?

I've managed to recreate the altivec_init_builtins ICE issue on a yellowdog
box.  (4-core 970MP).

Looks like it is trying to parse 
__builtin_altivec_vcmpnezb_p
at the time it fails.

Continuing to debug.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952

--- Comment #3 from Will Schmidt  ---
Couldn't duplicate on P8/BE.  I still have a couple builds going to see if I
can duplicate elsewhere.

I see "--with-cpu=default32 " in the config string.  Is this an older hardware
platform?  

thanks

[Bug target/90000] Compile-time hog w/ impossible asm constraints on powerpc

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

--- Comment #5 from Will Schmidt  ---
Created attachment 48486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48486=edit
Patch that seemed promising but is not sufficient.

[Bug target/90000] Compile-time hog w/ impossible asm constraints on powerpc

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

--- Comment #4 from Will Schmidt  ---

I'll be attaching a proposed(/rfc) patch momentarily.

I'm able to add logic in cfgexpand.c expand_asm_stmt() to catch the use of a FP
register when our target is SOFT_FLOAT ; but the result is an ICE while trying
to process a subsequent instruction.



FAIL: gcc.target/powerpc/pr9.c (test for excess errors)
Excess errors:
/home/willschm/gcc/gcc-patches/gcc/testsuite/gcc.target/powerpc/pr9.c:14:3:
error: invalid fp register usage with a soft_float target


^ desired error.


during RTL pass: expand
/home/willschm/gcc/gcc-patches/gcc/testsuite/gcc.target/powerpc/pr9.c:16:3:
internal compiler error: in operator[], at vec.h:867
0x1018dc3f vec::operator[](unsigned int)
/home/willschm/gcc/gcc-patches/gcc/vec.h:867
0x103f0a0f vec::operator[](unsigned int)
/home/willschm/gcc/gcc-patches/gcc/tree.h:3417
0x103f0a0f vec::operator[](unsigned int)
/home/willschm/gcc/gcc-patches/gcc/vec.h:1433
0x103f0a0f expand_asm_stmt
/home/willschm/gcc/gcc-patches/gcc/cfgexpand.c:2959
0x103f829f expand_gimple_stmt_1
/home/willschm/gcc/gcc-patches/gcc/cfgexpand.c:3694
0x103f829f expand_gimple_stmt
/home/willschm/gcc/gcc-patches/gcc/cfgexpand.c:3862
0x103ffde3 expand_gimple_basic_block
/home/willschm/gcc/gcc-patches/gcc/cfgexpand.c:5902
0x10402907 execute
/home/willschm/gcc/gcc-patches/gcc/cfgexpand.c:6557

^ subsequent undesired.  


Per debug, the subsequent error is occurring when trying to process a
subsequent instruction.

Breakpoint 7, expand_asm_stmt (stmt=stmt@entry=0x20c1) at
cfgexpand.c:2920
2920  location_t locus = gimple_location (stmt);
# .MEM_3 = VDEF <.MEM_2(D)>
__asm__("#" : "=d" fr1);

(gdb) c
Continuing./tmp/pr9.c: In function 'foo':
/tmp/pr9.c:14:3: error: invalid fp register usage with a soft-float target
   14 |   __asm__ ("#" : "=d" (fr1)); /* { dg-error "invalid fp register usage
with a soft-float target" } */
  |   ^~~



#0  expand_asm_stmt (stmt=stmt@entry=0x20c10058) at
cfgexpand.c:2920Breakpoint 7, expand_asm_stmt (stmt=stmt@entry=0x20c10058)
at cfgexpand.c:2920
2920  location_t locus = gimple_location (stmt);
# VUSE <.MEM_4>
__asm__ __volatile__("#" :  : "r" r31);


(gdb) c
Continuing.
#0  fancy_abort (file=0x11912d80 "/home/willschm/gcc/gcc-patches/gcc/vec.h",
line=0x363, 
function=0x11919948 "operator[]") at diagnostic.c:1778

[Bug target/90000] Compile-time hog w/ impossible asm constraints on powerpc

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #2 from Will Schmidt  ---
Debug dump.

Testcase looks like so:

void foo (void)
{
  register float __attribute__ ((mode(SD))) r31 __asm__ ("r31");
  register float __attribute__ ((mode(SD))) fr1 __asm__ ("fr1");

  __asm__ ("#" : "=d" (fr1));
  r31 = fr1;
  __asm__ ("#" : : "r" (r31));
}


# When we reach function.c: instantiate_virtual_regs_in_insn() ->
error_for_asm(), pcfun looks like so.

Breakpoint 12, error_for_asm (insn=0x20710340, gmsgid=0x1195d100
"impossible constraint in %") at rtl-error.c:82
82va_start (ap, gmsgid);
foo ()
{
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 6 2 (parallel [
(set (reg/v:SD 33 1 [ fr1 ])
(asm_operands:SD ("#") ("=d") 0 []
 []
 [] /tmp/pr60032.c:10))
(clobber (reg:SI 98 ca))
]) "/tmp/pr60032.c":10:3 -1
 (nil))
(insn 6 5 7 2 (set (subreg:SI (reg:SD 117 [ fr1.0_1 ]) 0)
(subreg:SI (reg/v:SD 33 1 [ fr1 ]) 0)) "/tmp/pr60032.c":11:7 -1
 (nil))
(insn 7 6 8 2 (set (reg:SI 30 30 [ r31 ])
(subreg:SI (reg:SD 117 [ fr1.0_1 ]) 0)) "/tmp/pr60032.c":11:7 -1
 (nil))
(insn 8 7 0 2 (parallel [
(asm_operands/v ("#") ("") 0 [
(reg/v:SD 30 30 [ r31 ])
]
 [
(asm_input:SD ("r") /tmp/pr60032.c:12)
]
 [] /tmp/pr60032.c:12)
(clobber (reg:SI 98 ca))
]) "/tmp/pr60032.c":12:3 -1
 (nil))

}

# The error is reported:
/tmp/pr60032.c: In function 'foo':
/tmp/pr60032.c:10:3: error: impossible constraint in 'asm'
   10 |   __asm__ ("#" : "=d" (fr1));
  |   ^~~
"..."84   va_end (ap);

# set a break at the subsequent call into delete_insn().
   0x1063486c <+2268>:  cmpwi   r9,10
   0x10634870 <+2272>:  beq 0x10634e5c <(anonymous
namespace)::pass_instantiate_virtual_regs::execute(function*)+3788>
=> 0x10634874 <+2276>:  mr  r3,r31
   0x10634878 <+2280>:  bl  0x1041d528 
   0x1063487c <+2284>:  nop

(gdb) break * 0x1063487c
Breakpoint 15 at 0x1063487c: file function.c, line 1796.
(gdb) c
Continuing.
"..."
Breakpoint 15, 0x1063487c in instantiate_virtual_regs_in_insn
(insn=0x20710340) at function.c:1796
1796delete_insn (insn);


(gdb) p insn
$7 = (rtx_insn *) 0x20710340
(gdb) pr insn
warning: Expression is not an assignment (and might have no effect)
(insn/v 5 2 6 2 (parallel [
(set (reg/v:SD 33 1 [ fr1 ])
(asm_operands:SD ("#") ("=d") 0 []
 []
 [] /tmp/pr60032.c:10))
(clobber (reg:SI 98 ca))
]) "/tmp/pr60032.c":10:3 -1
 (nil))
(gdb)  


# And we can see via pcfun that the instruction (#5) has been removed.

(gdb) pcfun
foo ()
{
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 2 7 2 (set (subreg:SI (reg:SD 117 [ fr1.0_1 ]) 0)
(subreg:SI (reg/v:SD 33 1 [ fr1 ]) 0)) "/tmp/pr60032.c":11:7 -1
 (nil))
(insn 7 6 8 2 (set (reg:SI 30 30 [ r31 ])
(subreg:SI (reg:SD 117 [ fr1.0_1 ]) 0)) "/tmp/pr60032.c":11:7 -1
 (nil))
(insn 8 7 0 2 (parallel [
(asm_operands/v ("#") ("") 0 [
(reg/v:SD 30 30 [ r31 ])
]
 [
(asm_input:SD ("r") /tmp/pr60032.c:12)
]
 [] /tmp/pr60032.c:12)
(clobber (reg:SI 98 ca))
]) "/tmp/pr60032.c":12:3 -1
 (nil))
}


(
When we get to lra, we are spinning in the loop 
  lra_init_equiv ();
  for (;;)
{
  for (;;)
{
  bool reloads_p = lra_constraints (lra_constraint_iter == 0);
  ...
  lra_eliminate (false, false);
  ...


# backtrace and assorted debug shows we are repeatedly emitting an instruction
via emit_move_insn down this call path:

#0  emit_move_insn (x=0x2065ed48, y=0x2065ac80) at expr.c:3804
#1  0x1085f7bc in lra_emit_move (x=0x2065ed48, y=)
at lra.c:499
#2  0x1087cf5c in curr_insn_transform
(check_only_p=check_only_p@entry=0x0) at lra-constraints.c:4425
#3  0x1087ec00 in lra_constraints (first_p=) at
lra-constraints.c:5025
#4  0x10860518 in lra (f=) at lra.c:2437
#5  0x000

[Bug target/90763] PowerPC vec_xl_len should take const

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763

Will Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from Will Schmidt  ---
closing.

[Bug target/90763] PowerPC vec_xl_len should take const

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763

Will Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Will Schmidt  ---
Should be all fixed. closing.
thanks
-Will

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

Will Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Will Schmidt  ---
(In reply to Segher Boessenkool from comment #4)
> Is this fixed now?

Backport to 8 has been committed.  should be done with this one, thanks. :-)

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

--- Comment #6 from Will Schmidt  ---
Author: willschm
Date: Tue Oct  9 20:55:25 2018
New Revision: 264994

URL: https://gcc.gnu.org/viewcvs?rev=264994=gcc=rev
Log:

[gcc]
2018-10-09  Will Schmidt 

Backport from trunk.
2018-09-06  Will Schmidt  

PR target/86731
* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Update logic
around folding of vec_sl to handle out of range shift values.

[testsuite]

2018-10-09  Will Schmidt 

Backport from trunk
2018-09-06  Will Schmidt  

PR target/86731
* gcc.target/powerpc/pr86731.c: New test.
* gcc.target/powerpc/pr86731-longlong.c: New test.
* gcc.target/powerpc/pr86731-fwrapv.c: New test.
* gcc.target/powerpc/pr86731-fwrapv-longlong.c: New test.
* gcc.target/powerpc/pr86731-nogimplefold.c: New test.
* gcc.target/powerpc/pr86731-nogimplefold-longlong.c: New test.


Added:
   
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-longlong.c
   
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-nogimplefold-longlong.c
   
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731-nogimplefold.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86731.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

--- Comment #5 from Will Schmidt  ---
(In reply to Segher Boessenkool from comment #4)
> Is this fixed now?

This should be fixed on trunk with Revision: 264150

Has not yet been backported to 8.

Let me find and do a follow-up comment on the thread on gcc-patches. 

thanks,
-Will

[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532

--- Comment #1 from Will Schmidt  ---
Created attachment 44797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44797=edit
simpler testcase variation

Simplified the testcase a bit.
comment/uncomment the noinline attribute on the get_auto_n() function to toggle 
pass/fail.
Fails with -O2.
on Power8.  (probably also power9).

[Bug c/87532] New: bad results from vec_extract(unsigned char, foo) dependent upon function inline

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532

Bug ID: 87532
   Summary: bad results from vec_extract(unsigned char, foo)
dependent upon function inline
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44796=edit
patch to add powerpc testcase vec-extract-v16qiu-v2a.c  and -v2b.c

Debugging an issue with an existing testcase that exercises
vec_extract(unsigned char, #); and have run into this.  Using gcc trunk built
Oct 1, but believe this is not a new issue.

Results from a call into get_auto_n(a,i) are correct/incorrect depending on
whether the function being called is marked as __noinline__ .  

Attaching a stripped down and slightly modified version of an existing
vec-extract-v16qiu testcase.   Per the output below, the 'get_auto_n return
values are not consistent.


> cat gcc/testsuite/gcc/gcc.log  | egrep "^get_|PASS"
PASS: gcc.target/powerpc/vec-extract-v16qiu-v2a.c (test for excess errors)
get_auto_n return: -202182160
PASS: gcc.target/powerpc/vec-extract-v16qiu-v2a.c execution test
PASS: gcc.target/powerpc/vec-extract-v16qiu-v2b.c (test for excess errors)
get_auto_n return:  4
PASS: gcc.target/powerpc/vec-extract-v16qiu-v2b.c execution test

[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592

--- Comment #2 from Will Schmidt  ---
This was fixed via r264538

r264538 | willschm | 2018-09-24 10:47:22 -0500 (Mon, 24 Sep 2018) | 8 lines

[testsuite]

2018-09-24  Will Schmidt  

PR testsuite/86952
* gcc.target/powerpc/p8-vec-xl-xst-v2.c: Add and
update expected codegen

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952

--- Comment #1 from Will Schmidt  ---
Author: willschm
Date: Mon Sep 24 15:47:22 2018
New Revision: 264538

URL: https://gcc.gnu.org/viewcvs?rev=264538=gcc=rev
Log:
[testsuite]

2018-09-24  Will Schmidt  

PR testsuite/86952
* gcc.target/powerpc/p8-vec-xl-xst-v2.c: Add and
update expected codegen

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

--- Comment #3 from Will Schmidt  ---
Author: willschm
Date: Thu Sep  6 19:47:06 2018
New Revision: 264150

URL: https://gcc.gnu.org/viewcvs?rev=264150=gcc=rev
Log:
[gcc]

2018-09-06  Will Schmidt  

PR target/86731
* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Update logic
around folding of vec_sl to handle out of range shift values.

[testsuite]

2018-08-15  Will Schmidt  

PR target/86731
* gcc.target/powerpc/pr86731.c: New test.
* gcc.target/powerpc/pr86731-longlong.c: New test.
* gcc.target/powerpc/pr86731-fwrapv.c: New test.
* gcc.target/powerpc/pr86731-fwrapv-longlong.c: New test.
* gcc.target/powerpc/pr86731-nogimplefold.c: New test.
* gcc.target/powerpc/pr86731-nogimplefold-longlong.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-longlong.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-nogimplefold-longlong.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-nogimplefold.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/87021] New powerpc test cases from r263570 fail

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87021

--- Comment #1 from Will Schmidt  ---
These should clear up once the gimple-folding for vec_splat() code goes in.
If that patch is held up much longer (relatively), i will probably disable the
scan-assembler counts for those tests.

[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592

--- Comment #1 from Will Schmidt  ---
This should have cleared up once the gimple-folding support for unaligned loads
and stores went in, and the instruction counts settled on the expected values.
   commit c16f12a2dc14256226e85a9a9f82b54eb1de2187
   Author: willschm 
   Date:   Mon Aug 13 18:13:20 2018 +

I'll keep an eye on this space to make sure.
thanks,

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

--- Comment #2 from Will Schmidt  ---
Thanks for the bug report.
The patch  (attached) has also been posted to gcc-patches for review.

Thanks,

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

--- Comment #1 from Will Schmidt  ---
Created attachment 44542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44542=edit
preliminary patch to resolve the problem

preliminary/rfc patch.

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

Will Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-14
   Assignee|unassigned at gcc dot gnu.org  |willschm at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592

Will Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84751

Will Schmidt  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Will Schmidt  ---
Talked briefly with Segher about this one.   I am going to reject this one as
invalid.  I'll re-open if I run into this again.

[Bug target/83660] ICE with vec_extract inside expression statement

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660

Will Schmidt  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #8 from Will Schmidt  ---
Per top half of comment 7, could use insights from someone with better
understanding of the gimplify code, particularly gimplify_cleanup_point_expr().

Adding Richi and Jakub to cc.

[Bug target/83660] ICE with vec_extract inside expression statement

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #7 from Will Schmidt  ---
The ICE is triggered on the gcc_unreachable() at the bottom of the
switch(gimple_code(stmt)) clause in gimple-low.c: lower_stmt().

We enter the switch with our gimple_code(stmt) == GIMPLE_WITH_CLEANUP_EXPR.

# cfun at this point is:
(gdb) pcfun
get_word (__vector __bool int v)
{
  unsigned int D.3236;

  {
const unsigned int _B2;

_B2 = 32;
D.3235 = v;
<<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>

retval.0 = BIT_FIELD_REF <D.3235, 32, 64>;
  }
  D.3236 = retval.0;
  return D.3236;
}


Doing some code-browsing, I see some logic to handle GIMPLE_WITH_CLEANUP_EXPR
in remap_gimple_stmt() and in gimple_copy() , but not in lower_stmt().

However, at gimplify.c: gimplify_cleanup_point_expr() i see the comment:

/* Gimplify a CLEANUP_POINT_EXPR.  Currently this works by adding
   GIMPLE_WITH_CLEANUP_EXPRs to the prequeue as we encounter cleanups while
   gimplifying the body, and converting them to TRY_FINALLY_EXPRs when we
   return to this function.

Debug on the logic there...
  for (iter = gsi_start (body_sequence); !gsi_end_p (iter); )
{
  gimple *wce = gsi_stmt (iter);
  if (gimple_code (wce) == GIMPLE_WITH_CLEANUP_EXPR)

does not show any matches with GIMPLE_WITH_CLEANUP_EXPR. (one GIMPLE_ASSIGN, 3
GIMPLE_BIND).  so we're not catching and generating TRY_FINALLY_EXPRS on the
way out like we want or need to.

(I can scratch and dig around some more,.. but could use a hint or do a
hand-off to someone..  :-)   



Additional debug, possibly not relevant:
During (first?) gimple pass, we get to gimple_build_wce by way of multiple
calls through ..  hard to paraphrase, heres the bt. 

(gdb) bt
#0  0x1088da08 in gimple_build_wce (cleanup=0x109e00f0) at
gimple.c:742
#1  0x108e9984 in gimple_push_cleanup (var=0x10080a20,
cleanup=, eh_only=false, pre_p=0x3fffd7a0,
force_uncond=true) at gimplify.c:6528
#2  0x108f7cbc in gimplify_target_expr (expr_p=0x106b0d38,
pre_p=0x3fffd7a0, post_p=0x3fffd390) at gimplify.c:6611
#3  0x108e3410 in gimplify_expr (expr_p=0x106b0d38,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x1089b130
<is_gimple_lvalue(tree_node*)>, 
fallback=) at gimplify.c:11815
#4  0x108e2f28 in gimplify_expr (expr_p=0x108c8e50,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x108d1660
<is_gimple_reg_rhs_or_call(tree)>, 
fallback=1) at gimplify.c:11739
#5  0x108f9cdc in gimplify_modify_expr (expr_p=0x106ff598,
pre_p=0x3fffd7a0, post_p=0x3fffd390, want_value=false) at
gimplify.c:5626
#6  0x108e3430 in gimplify_expr (expr_p=0x106ff598,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x108d6cc0
<is_gimple_stmt(tree)>, fallback=0)
at gimplify.c:11435
#7  0x108e7288 in gimplify_stmt (stmt_p=,
seq_p=0x3fffd7a0) at gimplify.c:6658
#8  0x108e402c in gimplify_statement_list (pre_p=,
expr_p=0x106b0c80) at gimplify.c:1767
#9  gimplify_expr (expr_p=0x106b0c80, pre_p=0x3fffd7a0,
post_p=0x3fffd5c0, gimple_test_f=0x108d6cc0 <is_gimple_stmt(tree)>,
fallback=0) at gimplify.c:11863
#10 0x108e72dc in gimplify_stmt (stmt_p=0x106b0c80,
seq_p=0x3fffd7a0) at gimplify.c:6658
#11 0x108e8b8c in gimplify_bind_expr (expr_p=0x108c8e00,
pre_p=0x3fffe0d0) at gimplify.c:1335
#12 0x108e31ec in gimplify_expr (expr_p=0x108c8e00,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, gimple_test_f=0x108d1660
<is_gimple_reg_rhs_or_call(tree)>, 
fallback=1) at gimplify.c:11635
#13 0x108f9cdc in gimplify_modify_expr (expr_p=0x3fffde70,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, want_value=false) at
gimplify.c:5626
#14 0x108e3430 in gimplify_expr (expr_p=0x3fffde70,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, gimple_test_f=0x108d6cc0
<is_gimple_stmt(tree)>, fallback=0)
at gimplify.c:11435
#15 0x108e72dc in gimplify_stmt (stmt_p=0x3fffde70,
seq_p=0x3fffe0d0) at gimplify.c:6658
#16 0x108e3cc0 in gimplify_and_add (seq_p=0x3fffe0d0, t=) at gimplify.c:441
#17 gimplify_return_expr (pre_p=0x3fffe0d0, stmt=) at
gimplify.c:1571
#18 gimplify_expr (expr_p=0x109b4bd8, pre_p=0x3fffe0d0,
post_p=0x3fffde50, gimple_test_f=0x108d6cc0 <is_gimple_stmt(tree)>,
fallback=0) at gimplify.c:11695
#19 0x108e72dc in gimplify_stmt (stmt_p=,
seq_p=0x3fffe0d0) at gimplify.c:6658
#20 0x108e3050 in gimplify_cleanup_point_expr (pre_p=,
expr_p=0x106b0cb0) at gimplify.c:6400
#21 gimplify_expr (expr_p=0x106b0cb0, pre_p=0x3fffe26

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84751

--- Comment #5 from Will Schmidt  ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Will Schmidt from comment #3)
> >   $ /home/willschm/gcc/trunk.svn/configure --with-cpu=power7
> > --with-long-double-128 --prefix=/home/willschm/gcc/install/gnc
> > --disable-bootstrap --enable-languages=c,c++,lto --no-create --no-recursion
> 
> If it is --disable-bootstrap, then it matters what exact your system gcc is,
> perhaps it miscompiles something?

Ok.  Yeah, this is a somewhat vintage distro compiler here.

gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) 

Let me see if I can try with a newer version.

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84751

--- Comment #3 from Will Schmidt  ---
(In reply to Jakub Jelinek from comment #1)
> What configure flags for that specially configured gcc?
> Can you in a debugger pt whatever tree_operand_hash::hash is called on?
> I certainly can't reproduce this with a cross to powerpc64-linux, even under
> valgrind it is clear.

I just attached the config.log for reference.

This environment is .. Power7, BE.(i'll see if I can verify that this
does/does not occur in other Power envs shortly.)

willschm@bns:~/gcc/generic.noprereqs.noconfig.debug> head config.log 
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /home/willschm/gcc/trunk.svn/configure --with-cpu=power7
--with-long-double-128 --prefix=/home/willschm/gcc/install/gnc
--disable-bootstrap --enable-languages=c,c++,lto --no-create --no-recursion

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84751

--- Comment #2 from Will Schmidt  ---
Created attachment 43602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43602=edit
config.log

[Bug target/84751] New: ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84751

Bug ID: 84751
   Summary: ICE  with debug build of gcc  GIMPLE pass:
store-merging or IPA pass: cp
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43587=edit
testcase

This was noticed during investigation into pr82982 on powerpc64-*-linux-gnu* ,
but believed to be a separate issue.

With a 'debug' build of gcc, where $CPU_COUNT is any value, and the assorted
CFLAGS values are set like in the following. 

make -j $CPU_COUNT CFLAGS="-O0 -g3 -fno-inline" CXXFLAGS="-O0 -g3 -fno-inline"
CFLAGS_FOR_BUILD="-O0 -g3 -fno-inline" CFLAGS_FOR_TARGET="-O0 -g3 -fno-inline"
CXXFLAGS_FOR_BUILD="-O0 -g3 -fno-inline" CXXFLAGS_FOR_TARGET="-O0 -g3
-fno-inline" 

the resulting gcc will ICE when building the testcase with -O2 or higher. 

# driver with -O2
~/gcc/generic.noprereqs.noconfig.debug> ./gcc/cc1 ../pr82982.c  -O2
 km
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   

  
 Assembling functions:
  kmduring GIMPLE pass: store-merging

../pr82982.c: In function ‘km’:
../pr82982.c:4:1: internal compiler error: Segmentation fault
 km (void)
 ^~
0x10f2da87 crash_signal
/home/willschm/gcc/trunk.svn/gcc/toplev.c:325
0x11f76638 trim_filename(char const*)
/home/willschm/gcc/trunk.svn/gcc/diagnostic.c:1023
0x11f78517 fancy_abort(char const*, int, char const*)
/home/willschm/gcc/trunk.svn/gcc/diagnostic.c:1509
0x114b56df inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
/home/willschm/gcc/trunk.svn/gcc/tree.c:7425
0x10f82493 iterative_hash_expr
/home/willschm/gcc/trunk.svn/gcc/tree.h:4934
0x10f89467 tree_operand_hash::hash(tree_node* const&)
/home/willschm/gcc/trunk.svn/gcc/tree-hash-traits.h:34
0x11d73dbb hash
/home/willschm/gcc/trunk.svn/gcc/hash-map-traits.h:49
0x11d7497b get
/home/willschm/gcc/trunk.svn/gcc/hash-map.h:161
0x11d84fab process_store
/home/willschm/gcc/trunk.svn/gcc/gimple-ssa-store-merging.c:4171
0x11d85697 execute
/home/willschm/gcc/trunk.svn/gcc/gimple-ssa-store-merging.c:4279
Please submit a full bug report,
with preprocessed source if appropriate.

# gcc with -O2
/home/willschm/gcc/install/gcc-mainline-pr82982/bin/gcc ~/gcc/pr82982.c -c -O2
during GIMPLE pass: store-merging
/home/willschm/gcc/pr82982.c: In function ‘km’:
/home/willschm/gcc/pr82982.c:4:1: internal compiler error: Segmentation fault
 km (void)
 ^~
0x10f76343 crash_signal
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/toplev.c:325
0x11fd5d98 internal_error(char const*, ...)
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/diagnostic.c:1433
0x11fd5e3f fancy_abort(char const*, int, char const*)
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/diagnostic.c:1500
0x114fd4cb inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree.c:7425
0x10fcad2f iterative_hash_expr
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree.h:4934
0x10fd1d03 tree_operand_hash::hash(tree_node* const&)
   
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree-hash-traits.h:34
0x11da7caf hash
   
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/hash-map-traits.h:49
0x11da886f get
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/hash-map.h:161
0x11db8e9f process_store
   
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/gimple-ssa-store-merging.c:4171
0x11db958b execute
   
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/gimple-ssa-store-merging.c:4279
Please submit a full bug report,

# gcc with -O3
# looks like the failure shows up during IPA pass: cp with -O3.
/home/willschm/gcc/install/gcc-mainline-pr82982/bin/gcc ~/gcc/pr82982.c -c -O3
during IPA pass: cp
/home/willschm/gcc/pr82982.c:31:1: internal compiler error: Segmentation fault
 }
 ^
0x10f76343 crash_signal
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/toplev.c:325
0x103de144 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree.h:3131
0x10daaa6f opts_for_fn
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree.h:5319
0x10dbec43 cgraph_node::optimize_for_size_p()
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/cgraph.h:3152
0x11e526bf ipcp_cloning_candidate_p
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/ipa-cp.c:727
0x11e52ab7 initialize_node_lattices
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/g

[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982

--- Comment #8 from Will Schmidt  ---
(In reply to Will Schmidt from comment #6)
> (In reply to Arseny Solokha from comment #5)
> > (In reply to Will Schmidt from comment #4)
> > > Tried to re-create locally, I've gotten two ICE's using the provided
> > > testcode snippet, neither look quite like the originally reported issue. 
> > 
> > You are right. I also cannot reproduce the original issue anymore w/ 
> > r257975.
> 
> Today I cannot get any ICE's out of this test.  Wonder if things were fixed
> up in the mean-time, or if I tickled a config option and managed to hide the
> issue(s).   Going to try a few more runs with older trees to see if I can
> verify things are fixed.

(In reply to Arseny Solokha from comment #7)
> OK, the original issue still reproduces for the powerpc-e500v2-linux-gnuspe
> target as of r257975, so the change that affected this issue must have been
> local to the rs6000 backend.

Ok.  so at the moment I'm going to claim that I am unable to recreate the
initially reported problem in my environments, which are 64-bit or 64/32 mixed.
 Nothing pure 32-bit here, nothing e300* or e500*, etc.

The ICe's that I did see (comment #4) seem to be to be a separate issue.  Those
only occur in my sandbox/debug build of gcc, which has
CFLAGS,CXXFLAGS,CFLAGS_FOR_BUILD, CFLAGS_FOR_TARGET, etc all  set to "-O0 -g3
-fno-inline".  I otherwise don't see any ICE with this test case.

[Bug target/84371] test case gcc.target/powerpc/builtins-3.c fails on power9

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84371

Will Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Will Schmidt  ---
fixed and backported.   Closing now.

[Bug target/84371] test case gcc.target/powerpc/builtins-3.c fails on power9

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84371

--- Comment #6 from Will Schmidt  ---
Author: willschm
Date: Mon Mar  5 17:11:16 2018
New Revision: 258257

URL: https://gcc.gnu.org/viewcvs?rev=258257=gcc=rev
Log:
2018-03-05  Will Schmidt  

Backport from trunk.

2018-02-16  Will Schmidt  

PR target/84371
* gcc.target/powerpc/builtins-3.c: Update dg-options and dg-skip-if
stanzas.
* gcc.target/powerpc/builtins-3.p8.c: Add dg-skip-if stanza.
* gcc.target/powerpc/builtins-3.p9.c: Add dg-skip-if stanza.

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/builtins-3-p9.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/builtins-3.c

[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982

--- Comment #6 from Will Schmidt  ---
(In reply to Will Schmidt from comment #4)
> Tried to re-create locally, I've gotten two ICE's using the provided
> testcode snippet, neither look quite like the originally reported issue. 
> (thus I don't know if this is actually the same issue).
> 
> Neither of these require the -fgraphite-identity option be specified.  -m32
> or -m64 doesn't seem to matter for me. 
><...>


(In reply to Arseny Solokha from comment #5)
> (In reply to Will Schmidt from comment #4)
> > Tried to re-create locally, I've gotten two ICE's using the provided
> > testcode snippet, neither look quite like the originally reported issue. 
> 
> You are right. I also cannot reproduce the original issue anymore w/ r257975.

Today I cannot get any ICE's out of this test.  Wonder if things were fixed up
in the mean-time, or if I tickled a config option and managed to hide the
issue(s).   Going to try a few more runs with older trees to see if I can
verify things are fixed.

[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #4 from Will Schmidt  ---
Tried to re-create locally, I've gotten two ICE's using the provided testcode
snippet, neither look quite like the originally reported issue.  (thus I don't
know if this is actually the same issue).

Neither of these require the -fgraphite-identity option be specified.  -m32 or
-m64 doesn't seem to matter for me. 

Target: powerpc64-unknown-linux-gnu
Configured with: /home/willschm/gcc/gcc-mainline-regtest_patches/configure
--enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7
--with-long-double-128
--prefix=/home/willschm/gcc/install/gcc-mainline-regtest_patches
--disable-bootstrap --with-isl --with-graphite : (reconfigured)
/home/willschm/gcc/gcc-mainline-regtest_patches/configure
--enable-languages=c,c++ --with-cpu=power7 --with-long-double-128
--prefix=/home/willschm/gcc/install/gcc-mainline-regtest_patches
--disable-bootstrap --with-isl --with-graphite

# with -O2.  
> $GCC_INSTALL/bin/gcc ./pr82982.c  -c -O2 -m32
during GIMPLE pass: store-merging
./pr82982.c: In function ‘km’:
./pr82982.c:4:1: internal compiler error: Segmentation fault
 km (void)
 ^~
0x10f75447 crash_signal
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/toplev.c:325

# with -O3.
> $GCC_INSTALL/bin/gcc ./pr82982.c  -c -O3
during IPA pass: cp
./pr82982.c:31:1: internal compiler error: Segmentation fault
 }
 ^
0x10f75447 crash_signal
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/toplev.c:325
0x103de084 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/tree.h:3131
0x10da9e77 opts_for_fn
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/tree.h:5319
0x10dbe04b cgraph_node::optimize_for_size_p()
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/cgraph.h:3152
0x11e50afb ipcp_cloning_candidate_p
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:709
0x11e50ef3 initialize_node_lattices
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:1177
0x11e5df7b ipcp_propagate_stage
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:3284
0x11e5e317 ipcp_driver
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:5026
0x11e5e3ff execute
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:5120

[Bug target/84371] test case gcc.target/powerpc/builtins-3.c fails on power9

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84371

--- Comment #4 from Will Schmidt  ---
The scope of the problem here seems to have changed in the last week.  
Now seeing a number of 
 " error: builtin function '__builtin_altivec_neg_v2df' requires the
'-mpower8-vector' option "
will investigate, & probably run the builtin-3 tests through a blender to sort
this out..

[Bug target/84371] test case gcc.target/powerpc/builtins-3.c fails on power9

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84371

--- Comment #3 from Will Schmidt  ---
(In reply to seurer from comment #1)
> In addition to trunk this also fails with gcc 7

Yup. 
There was/is an ice in one of the builtins-3.* tests that should be better now
, per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422#c1

it is in my queue to re-check the results, and possibly loosen up the requires
or options on one of the tests.  I'll pursue a backport to gcc7 after I check
that over.

[Bug testsuite/84388] test case gcc/testsuite/gcc.target/powerpc/fold-vec-mult-int128-p9.c fails for gcc 7 on power9

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84388

Will Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Will Schmidt  ---
Fixed on gcc-7 branch.

[Bug target/84220] rs6000 builtin __builtin_vec_sld() ICEs on invalid 3rd argument

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84220

Will Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Will Schmidt  ---
Fixed on trunk.

[Bug testsuite/84388] test case gcc/testsuite/gcc.target/powerpc/fold-vec-mult-int128-p9.c fails for gcc 7 on power9

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84388

--- Comment #1 from Will Schmidt  ---
Author: willschm
Date: Thu Feb 15 14:50:15 2018
New Revision: 257692

URL: https://gcc.gnu.org/viewcvs?rev=257692=gcc=rev
Log:
[testsuite]

2018-02-15  Will Schmidt  

PR target/84388
* gcc.target/powerpc/fold-vec-mult-int128-p8.c: Update dg-options
and scan-assembler stanzas.
* gcc.target/powerpc/fold-vec-mult-int128-p9.c: Same.

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/fold-vec-mult-int128-p8.c
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/fold-vec-mult-int128-p9.c

[Bug target/84220] rs6000 builtin __builtin_vec_sld() ICEs on invalid 3rd argument

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84220

--- Comment #2 from Will Schmidt  ---
Author: willschm
Date: Wed Feb 14 15:32:02 2018
New Revision: 257662

URL: https://gcc.gnu.org/viewcvs?rev=257662=gcc=rev
Log:

[gcc]

2018-02-14  Will Schmidt  

PR target/84220
* config/rs6000/rs6000-c.c: Update definitions for
ALTIVEC_BUILTIN_VEC_SLD, ALTIVEC_BUILTIN_VEC_SLDW,
ALTIVEC_BUILTIN_VEC_XXPERMDI builtins.

[testsuite]

2018-02-14  Will Schmidt  

PR target/84220
* gcc.target/powerpc/pr84220-sld.c: New test.
* gcc.target/powerpc/pr84220-sld2.c: New test.
* gcc.target/powerpc/pr84220-sldw.c: New test.
* gcc.target/powerpc/pr84220-xxperm.c: New test.
* gcc.target/powerpc/pr84220-xxsld.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr84220-sld.c
trunk/gcc/testsuite/gcc.target/powerpc/pr84220-sld2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr84220-sldw.c
trunk/gcc/testsuite/gcc.target/powerpc/pr84220-xxperm.c
trunk/gcc/testsuite/gcc.target/powerpc/pr84220-xxsld.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81535

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #10 from Will Schmidt  ---
(In reply to seurer from comment #9)
> Just an FYI that the output of this test case changed a bit somewhere in the
> range r256987 to r257017:
> 
> Now it gets this:
> 
> FAIL: gcc.target/powerpc/pr79439.c scan-assembler-times \\mbl g\\M 1 (found
> 2 times)
> 
> previously it failed with this:
> 
> FAIL: gcc.target/powerpc/pr79439.c scan-assembler-times \\mnop\\M 3 (found 2
> times)

I looked briefly.  Per the generated assembly, the "bl g" check is failing
because the branch to 'g' now occurs twice in the generated code.  (occurs with
-O2, unless -fdisable-tree-early_optimizations is specified)  The "
scan-assembler-times 'nop' 3 " now passes, but that is only due to the
additional nop associated with the extra branch to 'g'.

[Bug target/83707] g++.dg/eh/simd-3.C fails on power7 -m32

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707

--- Comment #3 from Will Schmidt  ---
Created attachment 43360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43360=edit
.expand dump from a build with -O1.

the .expand dump from a build with -O1.

[Bug target/83707] g++.dg/eh/simd-3.C fails on power7 -m32

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #2 from Will Schmidt  ---

The troublesome snippet of code reads as so
( from gcc/testsuite/g++.dg/eh/simd-3.C )
" 
int main(void)
{
  v v1 = vt;
  try {
thrower();
  } catch (int x) {
  }
  v2 = v1;
  if (memcmp(,,...)) abort();
"
where thrower() is a function meant to scramble contents of the VSRs.
And the problem (that we abort during the test run) occurs when any non-zero
optimization level is specified, due to vt != v2.  

high-level debug suggests that we are not storing the v1=vt result to memory,
(only to a reg), so the call to thrower clobbers the contents, and we
ultimately fail. 


When built with -O0, on the "v1 = vt" statement, i can see (.expand dump)

;; Generating RTL for gimple basic block 2

;; v1_5 ={v} vt;

(insn # # # (set (reg:SI 129)
(high:SI (symbol_ref:SI ("vt") [flags 0x2]  )))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

(insn # # # (set (reg/f:SI 128)
(lo_sum:SI (reg:SI 129)
(symbol_ref:SI ("vt") [flags 0x2]  )))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (expr_list:REG_EQUAL (symbol_ref:SI ("vt") [flags 0x2]  )
(nil)))

(insn # # # (set (reg:V4SI 130)
(mem/v/c:V4SI (reg/f:SI 128) [1 vt+0 S16 A128]))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

(insn # # 0 (set (mem/c:V4SI (plus:SI (reg/f:SI 116 virtual-stack-vars)
(const_int 8 [0x8])) [1 v1+0 S16 A128])
(reg:V4SI 130))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

;; thrower ();

Noting the "set (mem/c..." statement.  This code works, in that the v1 value
survives the call to thrower.


When built with -O1, that chunk of the dump now reads:
;; v1_4 ={v} vt;

(insn # # # (set (reg:SI 128)
(high:SI (symbol_ref:SI ("*.LANCHOR1") [flags 0x182])))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

(insn # # # (set (reg/f:SI 127)
(lo_sum:SI (reg:SI 128)
(symbol_ref:SI ("*.LANCHOR1") [flags 0x182])))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (expr_list:REG_EQUAL (symbol_ref:SI ("*.LANCHOR1") [flags 0x182])
(nil)))

(insn # # 0 (set (reg/v:V4SI 123 [ v1 ])
(mem/v/c:V4SI (reg/f:SI 127) [1 vt+0 S16 A128]))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

;; thrower ();


And here, note that this is a "set (reg".  There is no "set (mem" until after
the "v2 = v1" statement, after the call to thrower(). 

This seems to fit with what I see via objdump : 
(working code)
xx :
xx: 94 21 ff c0 stwur1,-64(r1)
xx: 7c 08 02 a6 mflrr0
xx: 90 01 00 44 stw r0,68(r1)
xx: 93 e1 00 3c stw r31,60(r1)
xx: 7c 3f 0b 78 mr  r31,r1
xx: 3d 20 10 02 lis r9,4098
xx: 39 29 00 40 addir9,r9,64
xx: 7c 00 4e 18 lxvw4x  vs0,0,r9   <- load.
xx: 39 20 00 10 li  r9,16
xx: 7c 1f 4f 18 stxvw4x vs0,r31,r9  <- store.
xx: 4b ff ff 61 bl  174c <_Z7throwerv>

versus (failing code):
xx :
xx: 94 21 ff d0 stwur1,-48(r1)
xx: 7c 08 02 a6 mflrr0
xx: 90 01 00 34 stw r0,52(r1)
xx: 38 00 00 10 li  r0,16
xx: 7f e1 01 ce stvxv31,r1,r0
xx: 3d 20 10 02 lis r9,4098
xx: 39 29 00 40 addir9,r9,64
xx: 7f e0 4e 19 lxvw4x  vs63,0,r9<- load, no store.
xx: 4b ff ff 89 bl  16f0 <_Z7throwerv>


most previous tree dump before expand (232t.optimized) shows bb2 having:
   :
  v1_5 ={v} vt;
  thrower ();

versus 
   [local count: 1073741825]:
  v1_4 ={v} vt;
  thrower ();

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926

--- Comment #4 from Will Schmidt  ---
I'm having a moment of doubt on the validity of the testcases involved here.

vector long long a =  vec_div(long long b, long long c);

Any chance that is invalid for -m32 ?  I don't see a whole lot of vec_div()
references in the test suite with long long types.

I don't see it called out in the ABI, but the VSX_BUILTIN_DIV_V2DI and
VSX_BUILTIN_UDIV_V2DI do seem to exist.

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926

--- Comment #3 from Will Schmidt  ---
(In reply to Bill Schmidt from comment #2)
> Does this work on GCC 7 (obviously without -mno-fold-gimple)?  If so, please
> mark as [8 regression] in title.

looks like No, this also fails on the gcc 7 branch. 
(the -mno-fold-gimple option, as well as the vec_div folding, were both added
after gcc7 branched.)


(On a Power7)
# checkout
svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch  gcc-7-branch
# configure
../../gcc-7-branch/configure --enable-languages=c,c++,fortran,objc,obj-c++
--with-cpu=power7 --disable-multilib --with-long-double-128
--prefix=/home/willschm/gcc/install/gcc-7-branch --disable-bootstrap 

# check version
~/gcc/build/gcc-7-branch> /home/willschm/gcc/build/gcc-7-branch/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/home/willschm/gcc/build/gcc-7-branch/gcc/xgcc
Target: powerpc64-unknown-linux-gnu
Configured with: ../../gcc-7-branch/configure
--enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7
--disable-multilib --with-long-double-128
--prefix=/home/willschm/gcc/install/gcc-7-branch --disable-bootstrap
Thread model: posix
gcc version 7.2.1 20180124 (GCC) 

# run
~/gcc/build/gcc-7-branch> /home/willschm/gcc/build/gcc-7-branch/gcc/xgcc
-B/home/willschm/gcc/build/gcc-7-branch/gcc/ /home/willschm/testme.c   
-fno-diagnostics-show-caret -fdiagnostics-color=never  -maltivec
-ffat-lto-objects -S -o testme.o -m32 
/home/willschm/testme.c: In function ‘main’:
/home/willschm/testme.c:19:1: internal compiler error: in
elimination_costs_in_insn, at reload1.c:3617
0x10699b5b elimination_costs_in_insn
../../../gcc-7-branch/gcc/reload1.c:3614
0x1069a3db calculate_elim_costs_all_insns()
../../../gcc-7-branch/gcc/reload1.c:1607
0x10537343 ira_costs()
../../../gcc-7-branch/gcc/ira-costs.c:2261
0x1052f443 ira_build()
../../../gcc-7-branch/gcc/ira-build.c:3420
0x10524187 ira
../../../gcc-7-branch/gcc/ira.c:5308
0x10524187 execute
../../../gcc-7-branch/gcc/ira.c:5619

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #1 from Will Schmidt  ---
Created attachment 43172
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43172=edit
ira dump

ira dump.

[Bug target/83926] New: ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926

Bug ID: 83926
   Summary: ICE during RTL pass: ira, in
elimination_costs_in_insn, at reload1.c:3633
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43171=edit
simplified testcase

Failure seen on Power8 BE, discovered while reworking some tests to disable
gimple-folding.   

/home/willschm/gcc/build/gcc-mainline-baseline/gcc/xgcc
-B/home/willschm/gcc/build/gcc-mainline-baseline/gcc/
/home/willschm/gcc/testme.c  -fno-diagnostics-show-caret
-fdiagnostics-color=never -mcpu=power8 -O0 -ffat-lto-objects -S -m32  -o
testme.s -dap -mno-fold-gimple
gimple folding of rs6000 builtins has been disabled.
during RTL pass: ira
dump file: testme.c.278r.ira
/home/willschm/gcc/testme.c: In function ‘main’:
/home/willschm/gcc/testme.c:19:1: internal compiler error: in
elimination_costs_in_insn, at reload1.c:3633
0x108a05af elimination_costs_in_insn
/home/willschm/gcc/gcc-mainline-baseline/gcc/reload1.c:3630
0x108a8be7 calculate_elim_costs_all_insns()
/home/willschm/gcc/gcc-mainline-baseline/gcc/reload1.c:1607
0x106f79b7 ira_costs()
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira-costs.c:2249
0x106ef2d3 ira_build()
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira-build.c:3421
0x106e30af ira
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira.c:5292
0x106e30af execute
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira.c:5603
Please submit a full bug report,

[Bug target/82848] [8 Regression] ICE in expand_expr_real_2, at expr.c:8715

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82848

--- Comment #3 from Will Schmidt  ---

(In reply to Martin Liška from comment #0)
> Note that GCC 7.1 did:
> 
> $ powerpc64-suse-linux-gcc-7
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c -c 
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c: In
> function 'foo':
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c:12:
> 16: error: Builtin function __builtin_altivec_vmaddfp requires the -maltivec
> option
>vector float b = __builtin_vec_madd (b, a, (vector float) { C, C, C, C });
> ^
> 
> So the error somehow disappeared.

Yes,.. with the gimple-folding in place, that particular function (at .gimple
time) is no longer in play.
  bD.2759 = __builtin_altivec_vmaddfpD.1680 (bD.2759, aD.2756, {
3.64337600724452438440169691655378194132868104887894100657e-44,
3.64337600724452438440169691655378194132868104887894100657e-44,
3.64337600724452438440169691655378194132868104887894100657e-44,
3.64337600724452438440169691655378194132868104887894100657e-44 });
is now
  bD.2759 = bD.2759 * aD.2756 + {
3.64337600724452438440169691655378194132868104887894100657e-44,
3.64337600724452438440169691655378194132868104887894100657e-44,
3.64337600724452438440169691655378194132868104887894100657e-44,
3.64337600724452438440169691655378194132868104887894100657e-44 };
.  

If you use the option " -mno-fold-gimple " you should get the un-folded
behavior.  Which would be good to confirm this is the root cause, but not
long-term recommended for optimization reasons.

So all that said.. I'm struggling to recreate this one.   
My latest attempt was on gcc110.  I've tried on a few other power systems, with
similar/same results.

Anything obvious that I may have mis-configured here?

[willschm@gcc1-power7 gcc]$ /home/willschm/gcc/install/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/willschm/gcc/install/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/home/willschm/gcc/install/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/8.0.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../../src/gcc/configure
--enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7
--with-long-double-128 --prefix=/home/willschm/gcc/install/gcc/
--disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171117 (experimental) (GCC) 

[willschm@gcc1-power7 gcc]$ /home/willschm/gcc/install/gcc/bin/gcc 
/home/willschm/gcc/src/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c -c
[willschm@gcc1-power7 gcc]$ ls -lart pr37168.o 
-rw-rw-r--. 1 willschm willschm 1200 Nov 17 21:06 pr37168.o

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317

--- Comment #16 from Will Schmidt  ---
(In reply to Bill Schmidt from comment #13)
> CCing Will Schmidt for the general gimple-folding issue of built-in calls
> with missing LHSes.

revision 250185 has been committed to handle the gimple-folding issue.

[Bug target/79941] [7 Regression] Altivec vec_vmuleub regression

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79941

--- Comment #2 from Will Schmidt  ---
Author: willschm
Date: Fri Mar 10 16:18:44 2017
New Revision: 246040

URL: https://gcc.gnu.org/viewcvs?rev=246040=gcc=rev
Log:

gcc:
2017-03-10  Will Schmidt 

 PR target/79941
 * config/rs6000/rs6000.c (builtin_function_type): Add VMUL*U[HB]
 entries to the case statement that marks unsigned arguments to
 overloaded functions.

testsuite:
2017-03-10  Will Schmidt 

 PR target/79941
 * gcc.target/powerpc/fold-vec-mult-even_odd_misc.c: New test.
 * gcc.target/powerpc/fold-vec-mult-even_odd_char.c: New test.
 * gcc.target/powerpc/fold-vec-mult-even_odd_short.c: New test.



Added:
trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-char.c
trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c
trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-short.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79544] New: vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79544

Bug ID: 79544
   Summary: vec_sra (unsigned long long,foo) generating vsrd
instead of vsrad
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40756=edit
sample test

Noticed that vec_sra is generating a vsrd instruction rather than the expected
vsrad instruction when using "unsigned long long" parameter.   

>   #include 
>   vector unsigned long long
>   test6_sra (vector unsigned long long x, vector unsigned long long y)
>   {
> return vec_sra (x, y);
>   }

> #> gcc -c testme_sra.c  -S -mvsx -O3 

> #> grep -A 3 test6_sra: testme_sra.s
> test6_sra:
>   vsrd 2,2,3
>   blr
>   .long 0

vec_sra() against char,short,int appear OK. 

Seeing this on trunk (20170208) as well as older distro supplied compilers. 

test attached.

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747

Will Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Will Schmidt  ---
Patches committed to trunk, and backported to both gcc-5 and gcc-6 branches.  
all fixed. :-)

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747

--- Comment #4 from Will Schmidt  ---
Author: willschm
Date: Wed Nov  2 14:13:07 2016
New Revision: 241793

URL: https://gcc.gnu.org/viewcvs?rev=241793=gcc=rev
Log:
[gcc]

2016-11-02  Will Schmidt 

Backport from trunk
2016-10-26  Will Schmidt 

PR middle-end/72747
* gimplify.c (gimplify_init_constructor): Move emit of constructor
assignment to earlier in the if/else logic.

[gcc/testsuite]

2016-11-02  Will Schmidt  

Backport from trunk
2016-10-26  Will Schmidt 

PR middle-end/72747
* c-c++-common/pr72747-1.c: New test.
* c-c++-common/pr72747-2.c: Likewise.


Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/pr72747-1.c
branches/gcc-5-branch/gcc/testsuite/c-c++-common/pr72747-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimplify.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747

--- Comment #3 from Will Schmidt  ---
Author: willschm
Date: Wed Nov  2 14:12:23 2016
New Revision: 241792

URL: https://gcc.gnu.org/viewcvs?rev=241792=gcc=rev
Log:
[gcc]

2016-11-02  Will Schmidt 

Backport from trunk
2016-10-26  Will Schmidt 

PR middle-end/72747
* gimplify.c (gimplify_init_constructor): Move emit of constructor
assignment to earlier in the if/else logic.

[gcc/testsuite]

2016-11-02  Will Schmidt  

Backport from trunk
2016-10-26  Will Schmidt 

PR middle-end/72747
* c-c++-common/pr72747-1.c: New test.
* c-c++-common/pr72747-2.c: Likewise.


Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr72747-1.c
branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr72747-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747

--- Comment #2 from Will Schmidt  ---
Author: willschm
Date: Fri Oct 28 13:28:46 2016
New Revision: 241647

URL: https://gcc.gnu.org/viewcvs?rev=241647=gcc=rev
Log:
gcc:
2016-10-26  Will Schmidt 

PR middle-end/72747
* gimplify.c (gimplify_init_constructor): Move emit of constructor
assignment to earlier in the if/else logic.

testsuite:
2016-10-26  Will Schmidt 

PR middle-end/72747
* c-c++-common/pr72747-1.c: New test.
* c-c++-common/pr72747-2.c: Likewise.


Added:
trunk/gcc/testsuite/c-c++-common/pr72747-1.c
trunk/gcc/testsuite/c-c++-common/pr72747-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog