[Bug lto/98971] New: LTO removes __patchable_function_entries

2021-02-04 Thread gabriel at inconstante dot net.br via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98971

Bug ID: 98971
   Summary: LTO removes __patchable_function_entries
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel at inconstante dot net.br
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Building with -flto removes the effects of -fpatchable-function-entries, or at
least some of them.

For instance, building the following code:

$ cat libtesta.c
int
testa7(void)
{
  return 7;
}

with:

$ gcc libtesta.c -fPIC -fpatchable-function-entry=4,2 -flto -c -o libtesta.o
$ gcc libtesta.o -flto -shared -o libtesta.so

removes the nop padding usually generated with -fpatchable-function-entry, as
well as it removes the __patchable_function_entries section from the resulting
binaries. The intermediate libtesta.o already lacks both:

$ readelf --sections libtesta.o | grep __patchable
$ readelf --sections libtesta.so | grep __patchable
$ objdump -d libtesta.so | grep ":" -C3
10f0 :
10f0:   e9 7b ff ff ff  jmpq   1070 

10f5 :
10f5:   55  push   %rbp
10f6:   48 89 e5mov%rsp,%rbp
10f9:   b8 07 00 00 00  mov$0x7,%eax

Without -flto, I get what I expected:

$ readelf --sections libtesta.o | grep __patchable
  [ 4] __patchable_[...] PROGBITS   0050
$ readelf --sections libtesta.so | grep __patchable
  [19] __patchable_[...] PROGBITS 4020  3020
$ objdump -d libtesta.so | grep ":" -C3
10f5:   90  nop
10f6:   90  nop

10f7 :
10f7:   90  nop
10f8:   90  nop
10f9:   55  push   %rbp

Building with a single gcc command, such as:

$ gcc libtesta.c -fPIC -fpatchable-function-entry=4,2 -flto -shared -o
libtesta.so

also works as I expected, i.e.: the nops and the __patchable_function_entries
are kept.


Is this the intended behavior? Am I using it wrong? Or is this a bug?

Cheers

PS: Tested with the branch for gcc 10, with trunk, and with the compilers from
openSUSE and Debian.

[Bug target/93987] Regression (ICE) on gcc-9 branch

2020-03-01 Thread gabriel at inconstante dot net.br 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93987

--- Comment #3 from Gabriel F. T. Gomes  ---
Update: with the tip of the gcc-9 branch (commit ID 4630b748e63c), as well as
with the tip of trunk (commit ID 151bf47e78f5), it works.

[Bug target/93987] Regression (ICE) on gcc-9 branch

2020-03-01 Thread gabriel at inconstante dot net.br 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93987

--- Comment #2 from Gabriel F. T. Gomes  ---
Oh, I forgot to paste the output:

$
/home/debian/build/powerpc64le/tools/install/compilers/powerpc64le-linux-gnu/bin/powerpc64le-glibc-linux-gnu-gcc
-c -O2 ice.c 
ice.c: In function ‘test_addcq’:
ice.c:128:1: error: insn does not satisfy its constraints:
  128 | }
  | ^
(insn 305 304 306 3 (set (reg:V1TI 80 3)
(rotate:V1TI (mem/u/c:V1TI (and:DI (reg/f:DI 29 29 [240])
(const_int -16 [0xfff0])) [0  S16 A128])
(const_int 64 [0x40]))) 1043 {*vsx_le_permute_v1ti}
 (nil))
during RTL pass: cprop_hardreg
ice.c:128:1: internal compiler error: in extract_constrain_insn, at
recog.c:2211
0x1012c7ef _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/debian/build/powerpc64le/tools/src/gcc/gcc/rtl-error.c:108
0x1012c84b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/debian/build/powerpc64le/tools/src/gcc/gcc/rtl-error.c:118
0x106f4cd7 extract_constrain_insn(rtx_insn*)
/home/debian/build/powerpc64le/tools/src/gcc/gcc/recog.c:2211
0x106f9fbb copyprop_hardreg_forward_1
/home/debian/build/powerpc64le/tools/src/gcc/gcc/regcprop.c:817
0x106faf5f execute
/home/debian/build/powerpc64le/tools/src/gcc/gcc/regcprop.c:1385
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


I'll check with trunk and with the tip of gcc-9, thanks!

[Bug target/93987] New: Regression (ICE) on gcc-9 branch

2020-03-01 Thread gabriel at inconstante dot net.br 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93987

Bug ID: 93987
   Summary: Regression (ICE) on gcc-9 branch
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel at inconstante dot net.br
CC: bergner at vnet dot ibm.com
  Target Milestone: ---
Target: powerpc64le-glibc-linux-gnu

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

Current pveclib (https://github.com/open-power-sdk/pveclib) tests fail to build
with the tip of the gcc-9 branch.  I have bisected the problem, and it seems
that the following commit is to blame:

  066184a282b622ac6880150eb4e42fe57881b606 is the first bad commit
  commit 066184a282b622ac6880150eb4e42fe57881b606
  Author: Peter Bergner 
  Date:   Sun Feb 23 18:22:57 2020 -0600

rs6000: Fix infinite loop building ghostscript and icu [PR93658]

The testcases ("make check") in pveclib fail to build with GCC-9 in Debian
Unstable, and with a compiler built locally from that commit (I'm using glibc's
build-many-glibcs.py script).

I tried to reduce the testcase to a small standalone file, but I couldn't
reduce it further than the attachement