[MIPS] hsdis need non-executable PT_GNU_STACK support

[Leslie Zhai]

Hi all,

hsdis PrintLIRWithAssembly failed to work for mips64el after upgraded to 
jdk8u181-b13.


http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-August/007753.html

The root cause is the patch [MIPS] Enable non-executable PT_GNU_STACK 
support, contributed by Faraz in 2016 February, had not been merged by 
GCC toolchain upstream.


https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00444.html

And Maciej also need to increase `MAJOR_VERSION` to check whether or not 
support IFUNC, unfortunately still not merged by upstream.


https://sourceware.org/ml/libc-alpha/2016-12/msg00856.html

But I would apply the patch and rebuild gcc-8.1, binutils-gdb-2.30, 
glibc-2.27, to support Faraz, Joseph and Maciej :)


Thanks for your great job!


在 2018年08月14日 14:15, Florian Weimer 写道:

On 08/14/2018 04:08 AM, Leslie Zhai wrote:
But workaround for mips64el's PrintLIRWithAssembly is adding 
-Wl,-z,noexecstack linking flag, strangely X86 does *not* need such 
flag, so I am investigating the root cause.


MIPS soft-float apparently needs an executable stack:




This could be why the toolchain does not specify a non-executable 
stack by default.


Florian


--
Regards,
Leslie Zhai

Re: [MIPS] hsdis need non-executable PT_GNU_STACK support

[Joseph Myers]

On Tue, 14 Aug 2018, Leslie Zhai wrote:

> The root cause is the patch [MIPS] Enable non-executable PT_GNU_STACK support,
> contributed by Faraz in 2016 February, had not been merged by GCC toolchain
> upstream.
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00444.html

Was there a non-RFC GCC patch posting?  RFC means you're looking for 
comments with a view to producing later patch versions, not for an actual 
review with a view to getting that version of the changes checked in.

As noted in  
you'll need a non-RFC glibc patch posting, with architecture-independent 
and MIPS-specific parts split out, and with comments pointing to the 
upstream releases of kernel, GCC, binutils with relevant support.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [MIPS] hsdis need non-executable PT_GNU_STACK support

[Leslie Zhai]

Hi Joseph,

Thanks for your response!

hsdis is just able to workaround when linking with -Wl,-z,noexecstack 
flag, and my environment:


$ uname -a
Linux localhost.localdomain 3.10.84-19.fc21.loongson.2.mips64el #1 SMP 
PREEMPT Fri Jul 6 18:47:47 CST 2018 mips64 mips64 mips64 GNU/Linux


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mips64el-redhat-linux/4.9.3/lto-wrapper
Target: mips64el-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap 
--enable-shared --enable-threads=posix --enable-checking=release 
--enable-multilib --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-gnu-unique-object 
--enable-linker-build-id --with-arch=loongson3a 
--enable-languages=c,c++,objc,obj-c++,fortran,go,lto --enable-plugin 
--disable-libgcj 
--with-isl=/builddir/build/BUILD/gcc-4.9.3/obj-mips64el-redhat-linux/isl-install 
--with-cloog=/builddir/build/BUILD/gcc-4.9.3/obj-mips64el-redhat-linux/cloog-install 
--enable-gnu-indirect-function --with-long-double-128 
--build=mips64el-redhat-linux

Thread model: posix
gcc version 4.9.3 20150626 (Red Hat 4.9.3-8) (GCC)

$ ld -v
GNU ld version 2.24

$ rpm -q glibc
glibc-2.20-15.fc21.loongson.10.mips64el

But I want to find out the root cause, I have no idea whether or not 
kernel supported ELF MIPS_GNU_STACK:


+ /* Flag to indicate that non-executable stack supported by kernel.
+Ref: arch/mips/include/asm/elf.h in kernel sources. */
+#define AV_FLAGS_MIPS_GNU_STACK(1 << 24)

https://sourceware.org/ml/libc-alpha/2016-01/msg00568.html

But what is the status of kernel and toolchain for X86? Why it is *not* able to 
reproduce the hsdis issue for X86?

And I can prepare the test environment with the latest kernel and toolchain 
applied with your patch. Please give me some suggestion to support your job, 
thanks a lot!


在 2018年08月14日 17:43, Joseph Myers 写道:

On Tue, 14 Aug 2018, Leslie Zhai wrote:


The root cause is the patch [MIPS] Enable non-executable PT_GNU_STACK support,
contributed by Faraz in 2016 February, had not been merged by GCC toolchain
upstream.

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00444.html

Was there a non-RFC GCC patch posting?  RFC means you're looking for
comments with a view to producing later patch versions, not for an actual
review with a view to getting that version of the changes checked in.

As noted in 
you'll need a non-RFC glibc patch posting, with architecture-independent
and MIPS-specific parts split out, and with comments pointing to the
upstream releases of kernel, GCC, binutils with relevant support.



--
Regards,
Leslie Zhai

Re: Questions related to creation of libgcov.so

[Martin Liška]

On 08/03/2018 04:42 PM, Joseph Myers wrote:
> On Fri, 3 Aug 2018, Jakub Jelinek wrote:
> 
>>> 3) Should I come up with a symbol versioning of the libgcov API?
>>
>> Certainly.
> 
> Furthermore, make sure that the libgcov.a symbols remain hidden (via 
> building the static objects with $(vis_hide), since you're removing 
> ATTRIBUTE_HIDDEN).
> 

Hello.

I'm sending second version of the patch candidate. I was able to create
a mapfile and generate versioned symbols for libgcov.so file.

Unresolved issues:
1) I still see linking with static library:

$ find /home/marxin/bin/gcc -name libgcov*
/home/marxin/bin/gcc/lib64/libgcov.so.1
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.a
/home/marxin/bin/gcc/lib64/libgcov.so

$ export PATH=/home/marxin/bin/gcc/bin/:$PATH && export 
LD_LIBRARY_PATH=/home/marxin/bin/gcc/lib64/:$LD_LIBRARY_PATH
$ gcc main.c -fprofile-generate -Wl,--verbose | grep gcov
attempt to open 
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so failed
attempt to open 
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.a succeeded
(/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.a)_gcov_merge_add.o
(/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.a)_gcov_merge_time_profile.o
(/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.a)_gcov_indirect_call_profiler_v2.o
(/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.a)_gcov_time_profiler.o
(/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.a)_gcov.o

2) Do I understand that correctly that I need to build .o files twice: once 
with hidden visibility and second time
without for the shared library?

3) I added t-libgcov t-libgcov-gld t-libgcov-elf-ver into *-linux for now. Am I 
right that it should be added
basically to all places where e.g. 't-slibgcc-elf-ver' is?

Alexander: I added the -Wl,-z,now.

Thanks,
Martin
>From 66ee61145c0bd864bb5046b7ce17344cf3c705ea Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 3 Aug 2018 11:14:15 +0200
Subject: [PATCH] Add libgcov.so: work in progress.

---
 libgcc/Makefile.in  | 38 +-
 libgcc/config.host  |  4 +--
 libgcc/config/t-libgcov | 50 ++
 libgcc/config/t-libgcov-gld |  5 
 libgcc/libgcov-profiler.c   |  6 ++---
 libgcc/libgcov-std.ver.in   | 53 +
 libgcc/libgcov.h| 31 +++---
 7 files changed, 165 insertions(+), 22 deletions(-)
 create mode 100644 libgcc/config/t-libgcov
 create mode 100644 libgcc/config/t-libgcov-gld
 create mode 100644 libgcc/libgcov-std.ver.in

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 0c5b264f717..63d18bf861b 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -944,7 +944,7 @@ libgcc.a libgcov.a libunwind.a libgcc_eh.a:
 
 all: libgcc.a
 ifeq ($(enable_gcov),yes)
-all: libgcov.a
+all: libgcov.a libgcov$(SHLIB_EXT)
 endif
 
 ifneq ($(LIBUNWIND),)
@@ -1006,6 +1006,38 @@ libunwind$(SHLIB_EXT): $(libunwind-s-objects) $(extra-parts)
 		@shlib_base_name@,libunwind,$(subst \
 		@shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(SHLIBUNWIND_LINK))
 
+# Map-file generation.
+libgcov.map.in: $(SHLIBGCOV_MAPFILES)
+	{ cat $(SHLIBGCOV_MAPFILES) \
+	| sed -e '/^[ 	]*#/d' \
+		  -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
+	| $(gcc_compile_bare) -E -xassembler-with-cpp -; \
+	} > tmp-$@
+	mv tmp-$@ $@
+libgcov.map: $(SHLIBGCOV_MKMAP) libgcov.map.in $(libgcov-objects)
+	{ $(NM) $(SHLIBGCOV_NM_FLAGS) $(libgcov-objects); echo %%; \
+	  cat libgcov.map.in; \
+	} | $(AWK) -f $(SHLIBGCOV_MKMAP) $(SHLIBGCOV_MKMAP_OPTS) > tmp-$@
+	mv tmp-$@ $@
+libgcov$(SHLIB_EXT): libgcov.map
+libgcov_mapfile = libgcov.map
+
+libgcov-std.ver: $(srcdir)/libgcov-std.ver.in
+	cat < $< > $@
+
+libgcov$(SHLIB_EXT): $(libgcov-objects) libgcc_s$(SHLIB_EXT)
+	# @multilib_flags@ is still needed because this may use
+	# $(GCC_FOR_TARGET) and $(LIBGCC2_CFLAGS) directly.
+	# @multilib_dir@ is not really necessary, but sometimes it has
+	# more uses than just a directory name.
+	$(mkinstalldirs) $(MULTIDIR)
+	$(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \
+		@multilib_dir@,$(MULTIDIR),$(subst \
+		@shlib_objs@,$(objects),$(subst \
+		@shlib_base_name@,libgcov,$(subst \
+		@shlib_map_file@,$(libgcov_mapfile),$(subst \
+		@shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(SHLIBGCOV_LINK)))
+
 endif
 
 # Build the standard GCC startfiles and endfiles.
@@ -1172,6 +1204,10 @@ ifeq ($(enable_gcov),yes)
 	$(INSTALL_DATA) libgcov.a $(DESTDIR)$(inst_libdir)/
 	chmod 644 $(DESTDIR)$(inst_libdir)/libgcov.a
 	$(RANLIB) $(DESTDIR)$(inst_libdir)/libgcov.a
+
+	$(subst @multilib_dir@,$(MULTIDIR),$(subst \
+		@shlib_base_name@,libgcov,$(subst \
+		@shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(SHLIBGCOV_INSTALL
 endif
 
 	parts="$(INSTALL_PARTS)";\
diff --git a/libgcc/config.host b/libgcc/config.host
index 18cabaf24f6..2d32046e27f 100644
--- a/libgcc/config.host

Why did Intel change his static branch prediction mechanism over these years?

[2016 quekong]

( I don't know if it's allowed to ask such question, if not, please remind
me. )

I know Intel implemented several static branch prediction mechanisms these
years:

  * 80486 age: Always-not-take

  * Pentium4 age: Backwards Taken/Forwards Not-Taken

  * PM, Core2: Didn't use static prediction,  randomly depending on what
happens to be in corresponding BTB entry , according to agner's
optimization guide ¹.

  * Newer CPUs like Ivy Bridge, Haswell have become increasingly
intangible, according to Matt G's experiment ².

And Intel seems don't want to talk about it any more, because the latest
material I found within Intel Document was written about ten years ago.

I know static branch prediction is (far?) less important than dynamic, but
in quite a few situations, CPU will be completely lost and programmers(with
compiler) are usually the best guide. Of course these situations are
usually not performance bottleneck, because once a branch is frequently
executed, the dynamic predictor will capture it.

Since Intel no longer clearly statements the dynamic prediction mechanism
in its document, the builtin_expect() of GCC can do nothing more than
removing the unlikely branch from hot path or reversely for likely branch.

I am not familiar with CPU design and I don't know what exactly mechanism
Intel use nowadays for its static predictor, I just feel the best static
mechanism for Intel should be to clearly document his CPU "where I plan to
go when dynamic predictor failed, forward or backward", because usually the
programmer is the best guide at that time.


APPENDIX:

¹ Agner's optimization guide:
https://www.agner.org/optimize/microarchitecture.pdf   ,  section 3.5 .

² Matt G's experiment: https://xania.org/201602/bpu-part-two

Re: Questions related to creation of libgcov.so

[Michael Matz]

Hi,

On Tue, 14 Aug 2018, Martin Liška wrote:

> I'm sending second version of the patch candidate. I was able to create
> a mapfile and generate versioned symbols for libgcov.so file.
> 
> Unresolved issues:
> 1) I still see linking with static library:
> 
> $ find /home/marxin/bin/gcc -name libgcov*
> /home/marxin/bin/gcc/lib64/libgcov.so.1
> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.a
> /home/marxin/bin/gcc/lib64/libgcov.so

The .so softlink needs to go into into the same directory as libgcov.a.  
See how libgcc_s is installed using the SHLIB_INSTALL macro (defined in 
libgcc/config/t-slibgcc).  In fact, with the right substitutions you 
should be able to use that macro directly without writing your own (you 
need to subst @shlib_base_name@, @multilib_dir@ and @shlib_slibdir_qual@).

> 3) I added t-libgcov t-libgcov-gld t-libgcov-elf-ver into *-linux for now. Am 
> I right that it should be added
> basically to all places where e.g. 't-slibgcc-elf-ver' is?

I think you only need to add further makefile includes if you need new 
macros.  I don't think you should need any?  Also for linking you 
probably should be able to reuse the SHLIB_LINK macro (maybe a bit 
extending it is required).


Ciao,
Michael.

Trying to convert to LRA, running into an ICE (infinite reload loop)

[Paul Koning]

I'm trying to convert the pdp11 target to use LRA.

A lot of it "just works".  But one of the test suite files fails in a way that 
I can't figure out at all.  I'm hoping for some help or hints to track down the 
cause and come up with a fix.

The failing program is testsuite/gcc.c-torture/compile/ifreg.c:

union foo
{
  float f;
  int i;
};

foo (int a, float c)
{
  union foo b;
  b.i = a;
  return b.f + c;
}

When compiled in LRA mode, I get this:

during RTL pass: reload
dump file: ifreg.c.274r.reload
../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c: In function ‘foo’:
../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c:12:1: internal compiler 
error: Max. number of generated reload insns per insn is achieved (90)

I fiddled a bit with the mov patterns, for example disabling the patterns 
that work on multi-word values (SI and DI mode, since pdp11 word is HImode).  
That doesn't fix (or create) the failure, though the specific insns change as a 
result.

What I see going in to reload (from the "ira" dump file) is:

(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 5 4 2 NOTE_INSN_DELETED)
(note 4 2 22 2 NOTE_INSN_FUNCTION_BEG)
(insn 22 4 18 2 (clobber (reg/v:DI 26 [ b ])) 
"../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 -1
 (nil))
(insn 18 22 19 2 (set (subreg:HI (reg/v:DI 26 [ b ]) 0)
(const_int 0 [0])) 
"../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
 (nil))
(insn 19 18 20 2 (set (subreg:HI (reg/v:DI 26 [ b ]) 2)
(const_int 0 [0])) 
"../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
 (nil))
...

Reload shows this:

(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 5 4 2 NOTE_INSN_DELETED)
(note 4 2 22 2 NOTE_INSN_FUNCTION_BEG)
(insn 22 4 18 2 (clobber (reg/v:DI 26 [ b ])) 
"../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 -1
 (nil))
(insn 18 22 25 2 (set (reg:HI 32)
(const_int 0 [0])) 
"../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
 (nil))
(insn 25 18 26 2 (set (reg:HI 33)
(reg:HI 32)) "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 
21 {movhi}
 (nil))
(insn 26 25 27 2 (set (reg:HI 34)
(reg:HI 33)) "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 
21 {movhi}
 (nil))
(insn 27 26 28 2 (set (reg:HI 35)
(reg:HI 34)) "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 
21 {movhi}
 (nil))
... with insns that do nothing, like the one above, repeating until it gives up.

At the top of the dump file where LRA is reporting what it's doing, I see this:

** Local #1: **

   Spilling non-eliminable hard regs: 6
New elimination table:
Can eliminate 15 to 6 (offset=10, prev_offset=0)
Can eliminate 15 to 5 (offset=4, prev_offset=0)
Can eliminate 14 to 6 (offset=8, prev_offset=0)
Can eliminate 14 to 5 (offset=0, prev_offset=0)
0 Non input pseudo reload: reject++
  alt=0,overall=7,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
  alt=1,overall=7,losers=1,rld_nregs=1
alt=2: Bad operand -- refuse
alt=3: Bad operand -- refuse
 Choosing alt 0 in insn 18:  (0) =rR  (1) rRN {movhi}
  Creating newreg=32, assigning class GENERAL_REGS to r32
   18: r32:HI=0
Inserting insn reload after:
   25: r26:DI#0=r32:HI

0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
Cycle danger: overall += LRA_MAX_REJECT
  alt=0,overall=608,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
alt=1: Bad operand -- refuse
alt=2: Bad operand -- refuse
alt=3: Bad operand -- refuse
 Choosing alt 0 in insn 25:  (0) =rR  (1) rRN {movhi}
  Creating newreg=33, assigning class GENERAL_REGS to r33
   25: r33:HI=r32:HI
Inserting insn reload after:
   26: r26:DI#0=r33:HI

0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
Cycle danger: overall += LRA_MAX_REJECT
  alt=0,overall=608,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
alt=1: Bad operand -- refuse
alt=2: Bad operand -- refuse
alt=3: Bad operand -- refuse
 Choosing alt 0 in insn 26:  (0) =rR  (1) rRN {movhi}
  Creating newreg=34, assigning class GENERAL_REGS to r34
   26: r34:HI=r33:HI
Inserting insn reload after:
   27: r26:DI#0=r34:HI
...

I don't know how to read that, and I don't know what to look for to find a 
cause or a cure.  Apart from turning on LRA, the code I'm running is what's in 
the repository, if anyone wants to look at the md file or other bits to offer 
suggestions.

paul

Re: Questions related to creation of libgcov.so

[Joseph Myers]

On Tue, 14 Aug 2018, Martin Liška wrote:

> 2) Do I understand that correctly that I need to build .o files twice: 
> once with hidden visibility and second time without for the shared 
> library?

Yes.

-- 
Joseph S. Myers
jos...@codesourcery.com

Can offsetting a non-null pointer result in a null one?

[Liu Hao]

Dear GCC people,

At the moment, with GCC 8.2, I compile the program

```
int foo(const char *p)
{
if(p == 0)
return 2;
const char *q = p + 1;
if(q == 0)
return 1;
return 0;
}
```

using

```
gcc-8 test.c -Wall -Wextra -Wpedantic -O3 -S
```

and get the following assembly (with irrelevant directives stripped out):

```
foo:
testq   %rdi, %rdi
je  .L3
xorl%eax, %eax
cmpq$-1, %rdi
sete%al
ret
.L3:
movl$2, %eax
ret
```

My question is that, when the first `if` is not taken, i.e. when `p` is 
not null, is it possible that after adding 1 to `p` would result in a 
null `q`?  Clang has been assuming that the result can't be null and 
optimize out the second `if` statement for years, but GCC is still 
emitting a check there. Are there any special reasons that prevent GCC 
from optimizing code this way?


--
Best regards,
LH_Mouse

Re: Can offsetting a non-null pointer result in a null one?

[Jeff Law]

On 08/14/2018 09:45 PM, Liu Hao wrote:
> Dear GCC people,
> 
> At the moment, with GCC 8.2, I compile the program
> 
> ```
> int foo(const char *p)
> {
>     if(p == 0)
>     return 2;
>     const char *q = p + 1;
>     if(q == 0)
>     return 1;
>     return 0;
> }
> ```
> 
> using
> 
> ```
> gcc-8 test.c -Wall -Wextra -Wpedantic -O3 -S
> ```
> 
> and get the following assembly (with irrelevant directives stripped out):
> 
> ```
> foo:
>     testq   %rdi, %rdi
>     je  .L3
>     xorl    %eax, %eax
>     cmpq    $-1, %rdi
>     sete    %al
>     ret
> .L3:
>     movl    $2, %eax
>     ret
> ```
> 
> My question is that, when the first `if` is not taken, i.e. when `p` is
> not null, is it possible that after adding 1 to `p` would result in a
> null `q`?  Clang has been assuming that the result can't be null and
> optimize out the second `if` statement for years, but GCC is still
> emitting a check there. Are there any special reasons that prevent GCC
> from optimizing code this way?
I just don't think anyone's ever bothered to catch this case.  I believe
there is a BZ which touches on this issue.

Jeff

Re: Trying to convert to LRA, running into an ICE (infinite reload loop)

[Jeff Law]

On 08/14/2018 01:32 PM, Paul Koning wrote:
> I'm trying to convert the pdp11 target to use LRA.
> 
> A lot of it "just works".  But one of the test suite files fails in a way 
> that I can't figure out at all.  I'm hoping for some help or hints to track 
> down the cause and come up with a fix.
> 
> The failing program is testsuite/gcc.c-torture/compile/ifreg.c:
> 
> union foo
> {
>   float f;
>   int i;
> };
> 
> foo (int a, float c)
> {
>   union foo b;
>   b.i = a;
>   return b.f + c;
> }
> 
> When compiled in LRA mode, I get this:
> 
> during RTL pass: reload
> dump file: ifreg.c.274r.reload
> ../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c: In function ‘foo’:
> ../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c:12:1: internal compiler 
> error: Max. number of generated reload insns per insn is achieved (90)
> 
> I fiddled a bit with the mov patterns, for example disabling the 
> patterns that work on multi-word values (SI and DI mode, since pdp11 word is 
> HImode).  That doesn't fix (or create) the failure, though the specific insns 
> change as a result.
> 
> What I see going in to reload (from the "ira" dump file) is:
> 
> (note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (note 2 5 4 2 NOTE_INSN_DELETED)
> (note 4 2 22 2 NOTE_INSN_FUNCTION_BEG)
> (insn 22 4 18 2 (clobber (reg/v:DI 26 [ b ])) 
> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 -1
>  (nil))
> (insn 18 22 19 2 (set (subreg:HI (reg/v:DI 26 [ b ]) 0)
> (const_int 0 [0])) 
> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>  (nil))
> (insn 19 18 20 2 (set (subreg:HI (reg/v:DI 26 [ b ]) 2)
> (const_int 0 [0])) 
> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>  (nil))
> ...
> 
> Reload shows this:
> 
> (note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (note 2 5 4 2 NOTE_INSN_DELETED)
> (note 4 2 22 2 NOTE_INSN_FUNCTION_BEG)
> (insn 22 4 18 2 (clobber (reg/v:DI 26 [ b ])) 
> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 -1
>  (nil))
> (insn 18 22 25 2 (set (reg:HI 32)
> (const_int 0 [0])) 
> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>  (nil))
> (insn 25 18 26 2 (set (reg:HI 33)
> (reg:HI 32)) 
> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>  (nil))
> (insn 26 25 27 2 (set (reg:HI 34)
> (reg:HI 33)) 
> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>  (nil))
> (insn 27 26 28 2 (set (reg:HI 35)
> (reg:HI 34)) 
> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>  (nil))
> ... with insns that do nothing, like the one above, repeating until it gives 
> up.
> 
> At the top of the dump file where LRA is reporting what it's doing, I see 
> this:
> 
> ** Local #1: **
> 
>  Spilling non-eliminable hard regs: 6
> New elimination table:
> Can eliminate 15 to 6 (offset=10, prev_offset=0)
> Can eliminate 15 to 5 (offset=4, prev_offset=0)
> Can eliminate 14 to 6 (offset=8, prev_offset=0)
> Can eliminate 14 to 5 (offset=0, prev_offset=0)
> 0 Non input pseudo reload: reject++
>   alt=0,overall=7,losers=1,rld_nregs=1
> 0 Non input pseudo reload: reject++
>   alt=1,overall=7,losers=1,rld_nregs=1
> alt=2: Bad operand -- refuse
> alt=3: Bad operand -- refuse
>Choosing alt 0 in insn 18:  (0) =rR  (1) rRN {movhi}
We've selected alternative 0 for insn 18.  I believe that's the rRN ->
=rR alternative.


>   Creating newreg=32, assigning class GENERAL_REGS to r32
The insn did not match its constraints.  So some kind of reload is
needed.  We allocate a new reload register r32.

>18: r32:HI=0
> Inserting insn reload after:
And we try to initialize r32 to 0.  Which of course needs another reload.

I suspect LRA is somehow missing that the operand could live in memory.


Jeff

Re: Can offsetting a non-null pointer result in a null one?

[Liu Hao]

在 2018-08-15 12:48, Jeff Law 写道:

I just don't think anyone's ever bothered to catch this case.  I believe
there is a BZ which touches on this issue.



Yes, here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655

This PR uses a placement new as the example, which in GCC 8 assumes the 
pointer argument to `operator new()` is never null. But for a general 
case it is still not fixed.


So it looks like nobody has been working on this. I will just fix my 
code then.



Jeff




--
Best regards,
LH_Mouse