Help with RTL expand and a builtins

[Martin Liška]

Hello.

I've been working on PR59521 and I'm unable to properly emit RTL instructions
in expand_builtin_mempcpy. At the end of the function I have:

...
(insn 12 11 13 (set (reg:DI 5 di)
(reg:DI 90)) "/home/marxin/Programming/testcases/mempcpy-1.c":1 -1
 (nil))

(call_insn/j 13 12 14 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("memcpy") [flags 0x41] ) [0 __builtin_memcpy S1 A8])
(const_int 0 [0]))) 
"/home/marxin/Programming/testcases/mempcpy-1.c":1 -1
 (expr_list:REG_CALL_DECL (symbol_ref:DI ("memcpy") [flags 0x41] 
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:DI (use (reg:DI 5 di))
(expr_list:DI (use (reg:DI 4 si))
(expr_list:DI (use (reg:DI 1 dx))
(nil)

(barrier 14 13 15)

(insn 15 14 16 (set (reg:DI 93)
(reg:DI 0 ax)) "/home/marxin/Programming/testcases/mempcpy-1.c":1 -1
 (nil))

(insn 16 15 17 (set (reg:DI 94)
(reg:DI 93)) "/home/marxin/Programming/testcases/mempcpy-1.c":1 -1
 (nil))

(insn 17 16 18 (set (reg:DI 95)
(plus:DI (reg:DI 94)
(const_int 1000 [0x989680]))) 
"/home/marxin/Programming/testcases/mempcpy-1.c":1 -1
 (nil))

(insn 18 17 0 (set (reg/f:DI 87 [  ])
(reg:DI 95)) "/home/marxin/Programming/testcases/mempcpy-1.c":1 -1
 (nil))

and
(gdb) p debug_rtx(target)
(reg/f:DI 87 [  ])
$3 = void


which is fine, it's basically return memcpy (x,y,1000) + 1000. However 
-fdump-rtl-expand shows:

...
(insn 12 11 13 2 (set (reg:DI 5 di)
(reg:DI 90)) "/home/marxin/Programming/testcases/mempcpy-1.c":1 -1
 (nil))
(call_insn/j 13 12 14 2 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("memcpy") [flags 0x41] ) [0 __builtin_memcpy S1 A8])
(const_int 0 [0]))) 
"/home/marxin/Programming/testcases/mempcpy-1.c":1 -1
 (expr_list:REG_CALL_DECL (symbol_ref:DI ("memcpy") [flags 0x41] 
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:DI (use (reg:DI 5 di))
(expr_list:DI (use (reg:DI 4 si))
(expr_list:DI (use (reg:DI 1 dx))
(nil)
(barrier 14 13 0)

I'm attaching patch and there's test-case:

$ cat ~/Programming/testcases/mempcpy-1.c
void *f1(void *p, void *q) { return __builtin_mempcpy(p, q, 1000); }

Thanks,
Martin
>From fbdf35a1f55d5d862404398b0621fdeaf90b2dd7 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 14 Jul 2017 12:54:33 +0200
Subject: [PATCH] Make mempcpy more optimal (PR middle-end/70140).

gcc/testsuite/ChangeLog:

2017-07-17  Martin Liska  

	PR middle-end/70140
	* gcc.dg/string-opt-1.c: Adjust test-case to scan for memcpy.

gcc/ChangeLog:

2017-07-17  Martin Liska  

	PR middle-end/70140
	* builtins.c (expand_builtin_memcpy_args): Remove.
	(expand_builtin_memcpy): Call newly added function
	expand_builtin_memory_copy_args.
	(expand_builtin_memcpy_with_bounds): Likewise.
	(expand_builtin_mempcpy): Remove last argument.
	(expand_builtin_mempcpy_with_bounds): Likewise.
	(expand_builtin_memory_copy_args): New function created from
	expand_builtin_mempcpy_args with small modifications.
	(expand_builtin_mempcpy_args): Remove.
	(expand_builtin_stpcpy): Remove unused argument.
	(expand_builtin): Likewise.
	(expand_builtin_with_bounds): Likewise.
---
 gcc/builtins.c  | 272 ++--
 gcc/testsuite/gcc.dg/string-opt-1.c |   5 +-
 2 files changed, 110 insertions(+), 167 deletions(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 2deef725620..b3cc58fb49f 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -121,12 +121,12 @@ static rtx builtin_memcpy_read_str (void *, HOST_WIDE_INT, machine_mode);
 static rtx expand_builtin_memchr (tree, rtx);
 static rtx expand_builtin_memcpy (tree, rtx);
 static rtx expand_builtin_memcpy_with_bounds (tree, rtx);
-static rtx expand_builtin_memcpy_args (tree, tree, tree, rtx, tree);
+static rtx expand_builtin_memory_copy_args (tree dest, tree src, tree len,
+	rtx target, tree exp, int endp);
 static rtx expand_builtin_memmove (tree, rtx);
-static rtx expand_builtin_mempcpy (tree, rtx, machine_mode);
-static rtx expand_builtin_mempcpy_with_bounds (tree, rtx, machine_mode);
-static rtx expand_builtin_mempcpy_args (tree, tree, tree, rtx,
-	machine_mode, int, tree);
+static rtx expand_builtin_mempcpy (tree, rtx);
+static rtx expand_builtin_mempcpy_with_bounds (tree, rtx);
+static rtx expand_builtin_mempcpy_args (tree, tree, tree, rtx, tree, int);
 static rtx expand_builtin_strcat (tree, rtx);
 static rtx expand_builtin_strcpy (tree, rtx);
 static rtx expand_builtin_strcpy_args (tree, tree, rtx);
@@ -2961,81 +2961,6 @@ determine_block_size (tree len, rtx len_rtx,
 			  GET_MODE_MASK (GET_MODE (len_rtx)));
 }
 
-/* Helper function to do the actual work for expand_builtin_memcpy.  */
-
-static rtx
-expand_builtin_memcpy_args (tree dest, tree src, tree len, rtx target, tree exp)
-{
-  const char *src_str;
-  unsigne

Re: Help with RTL expand and a builtins

[Martin Liška]

On 07/18/2017 09:16 AM, Martin Liška wrote:
> I've been working on PR59521 and I'm unable to properly emit RTL instructions
> in expand_builtin_mempcpy. At the end of the function I have:

Correction, it's PR70140.

M.

Re: whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?

[Leslie Zhai]

Hi Trevor,

Thanks for your kind response!

在 2017年07月17日 19:51, Trevor Saunders 写道:

On Wed, Jul 12, 2017 at 10:12:03AM +0800, Leslie Zhai wrote:

PS: Trevor's email is not available? thanks!

Sorry about that, I've left Mozilla and been vacationing for a month, so
didn't get to updating MAINTAINERS yet.  Here's a patch doing that.
Could I use PLUGIN_REGISTER_GGC_ROOTS to take place of 
PLUGIN_REGISTER_GGC_CACHES? https://gcc.gnu.org/ml/gcc/2017-07/msg00052.html




Trev

commit ff900f40d23f765fd59047a90a7e3ff18cbcbf5a
Author: Trevor Saunders 
Date:   Mon Jul 17 07:44:50 2017 -0400

 update my entry in MAINTAINERS
 
 ChangeLog:
 
 * MAINTAINERS: Update my email address.


diff --git a/MAINTAINERS b/MAINTAINERS
index a2f24742374..6a314049c42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -557,7 +557,7 @@ Hariharan Sandanagobalane   

  Iain Sandoe   
  Duncan Sands  
  Sujoy Saraswati   

-Trevor Saunders
+Trevor Saunders

  Aaron Sawdey  
  Roger Sayle   
  Will Schmidt  


--
Regards,
Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/

Re: Help with RTL expand and a builtins

[Martin Liška]

Solved, tail call was responsible for dead RTL instructions.

Martin

Re: Killing old dead bugs

[Jonathan Wakely]

On 17 July 2017 at 21:25, Yuri Gribov wrote:
> What to do about bugs originating in upstream packages?  I noticed
> they sometimes get closed with "RESOLVED MOVED" resolution
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
> does not happen and they just hang in tracker forever for no good
> reason.
>
> Actually what I tried to emphasize is that it's impossible for a
> casual commiter (who does not have maintainer access to Bugzilla i.e.
> rights to close bugs) to contribute to project by cleaning stale bugs,
> because requests to close them are mostly ignored (because
> maintainers, obviously, have much more interesting work to do).

Even if the bug remains open until a maintainer happens to look at it
again, the information that it's fixed in a current release is still
useful to add.

So I'd encourage you to still add such information, you're not wasting
your time.

Re: Help with RTL expand and a builtins

[Segher Boessenkool]

On Tue, Jul 18, 2017 at 12:49:06PM +0200, Martin Liška wrote:
> Solved, tail call was responsible for dead RTL instructions.

This seems similar to https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00362.html
then.  Is it?

There are many cases where we generated dead code during expand on
purpose (some just laziness, some to avoid code complications).
Because of this it is hard to detect where we generate dead code that
is just plain wrong (should not be dead).  And such things aren't
trivial to debug :-(


Segher

Re: Killing old dead bugs

[Martin Sebor]

On 07/17/2017 02:25 PM, Yuri Gribov wrote:

On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor  wrote:

On 07/17/2017 02:14 AM, Yuri Gribov wrote:


Hi Mikhail,

On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
wrote:


Hi. Yes, bug maintenance is appreciated. See this message and replies
to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .



Replies in your link suggest to leave a final comment in bugs with
explanatory suggestion to close them so that maintainers who read
gcc-bugs list hopefully notice them and act appropriately.
Unfortunately I found this to _not_ work in practice. Below you can
see a list of bugs I've investigated (and often bisected) in the past
weeks - none of them were closed by maintainers (or at least
commented).

So I'm afraid we have to conclude that there's no working process to
close stale bugs in place (which may be one of the reasons of bugcount
growth).



The informal process that some (most?) of us have been following
is to close them with a comment explaining our rationale.
It's good to fill in the Known to fail/Known to work versions if they
can be determined.  Mentioning the commit that fixed the bug as
you did for the bugs below is ideal.  Adding a test case if one
doesn't exist in the test suite is also very useful, though quite
a bit more work.  In my experience, if a bug is closed that should
stay open, someone usually notices pretty quickly and reopens it,
so I wouldn't be too worried about doing something wrong.


Martin,

Firstly, thanks for detailed explanation.

What to do about bugs originating in upstream packages?  I noticed
they sometimes get closed with "RESOLVED MOVED" resolution
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
does not happen and they just hang in tracker forever for no good
reason.

Actually what I tried to emphasize is that it's impossible for a
casual commiter (who does not have maintainer access to Bugzilla i.e.
rights to close bugs) to contribute to project by cleaning stale bugs,
because requests to close them are mostly ignored (because
maintainers, obviously, have much more interesting work to do).


I take your point.  I didn't realize closing bugs was restricted.
Given the work you've done on the bugs below (and elsewhere) you
should be able to close them.  If you aren't and would like to be
able to, please request it by emailing overse...@gcc.gnu.org ((at
least I think that's the right way to go about it), or follow up
here and I'm sure someone with the right karma will make it happen.

Martin




The process for managing bugs is in more detail described here:

  https://gcc.gnu.org/bugs/management.html

If you think it should be clarified in some way please feel free
to send in a patch.

Martin




* Bug 41992 - ICE on invalid dereferencing of void *
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
* Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
underlying type
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
* Bug 61693 - [asan] is not intercepting aligned_alloc
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
* Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
format mismatch between libasan and GCC
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
* Bug 78028 - ASAN doesn't find memory leak
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
* Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
"Unsupported arch"
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
* Bug 78654 - ubsan can lead to excessive stack usage
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
* Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
* Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
* Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
* Bug 54123 - inline functions not optimized as well as static inline
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)

-Y

[og7] Git branch "openacc-gcc-7-branch"

[Thomas Schwinge]

Hi!

There is a new Git-only branch: "openacc-gcc-7-branch",
,
.

This is a non-subdirectory branch for collaborative development of
OpenACC and related things, based on gcc-7-branch.  Please send email
with a short-hand "[og7]" tag, and use "ChangeLog.openacc" files.

With some clean-up, the new branch contains the features/patches of the
current "gomp-4_0-branch", and is based on the gcc-7-branch branch point,
trunk r247015.  I'll soon merge in some recent revision of gcc-7-branch.

This being a Git-only branch, should it nevertheless be listed on
, in the "Active Development Branches"
section, replacing "gomp-4_0-branch" there?


Grüße
 Thomas

Re: Killing old dead bugs

[Yuri Gribov]

On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor  wrote:
> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>
>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor  wrote:
>>>
>>> On 07/17/2017 02:14 AM, Yuri Gribov wrote:


 Hi Mikhail,

 On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
 wrote:
>
>
> Hi. Yes, bug maintenance is appreciated. See this message and replies
> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .



 Replies in your link suggest to leave a final comment in bugs with
 explanatory suggestion to close them so that maintainers who read
 gcc-bugs list hopefully notice them and act appropriately.
 Unfortunately I found this to _not_ work in practice. Below you can
 see a list of bugs I've investigated (and often bisected) in the past
 weeks - none of them were closed by maintainers (or at least
 commented).

 So I'm afraid we have to conclude that there's no working process to
 close stale bugs in place (which may be one of the reasons of bugcount
 growth).
>>>
>>>
>>>
>>> The informal process that some (most?) of us have been following
>>> is to close them with a comment explaining our rationale.
>>> It's good to fill in the Known to fail/Known to work versions if they
>>> can be determined.  Mentioning the commit that fixed the bug as
>>> you did for the bugs below is ideal.  Adding a test case if one
>>> doesn't exist in the test suite is also very useful, though quite
>>> a bit more work.  In my experience, if a bug is closed that should
>>> stay open, someone usually notices pretty quickly and reopens it,
>>> so I wouldn't be too worried about doing something wrong.
>>
>>
>> Martin,
>>
>> Firstly, thanks for detailed explanation.
>>
>> What to do about bugs originating in upstream packages?  I noticed
>> they sometimes get closed with "RESOLVED MOVED" resolution
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
>> does not happen and they just hang in tracker forever for no good
>> reason.
>>
>> Actually what I tried to emphasize is that it's impossible for a
>> casual commiter (who does not have maintainer access to Bugzilla i.e.
>> rights to close bugs) to contribute to project by cleaning stale bugs,
>> because requests to close them are mostly ignored (because
>> maintainers, obviously, have much more interesting work to do).
>
>
> I take your point.  I didn't realize closing bugs was restricted.
> Given the work you've done on the bugs below (and elsewhere) you
> should be able to close them.  If you aren't and would like to be
> able to, please request it by emailing overse...@gcc.gnu.org ((at
> least I think that's the right way to go about it), or follow up
> here and I'm sure someone with the right karma will make it happen.

Jonathan also mentioned something not immediately obvious in IRC:
logging into BZ with gcc.gnu.org account provides elevated privileges.
So if you have write access, you should get extra BZ rights for free.

>>> The process for managing bugs is in more detail described here:
>>>
>>>   https://gcc.gnu.org/bugs/management.html
>>>
>>> If you think it should be clarified in some way please feel free
>>> to send in a patch.
>>>
>>> Martin
>>>
>>>

 * Bug 41992 - ICE on invalid dereferencing of void *
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
 * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
 underlying type
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
 * Bug 61693 - [asan] is not intercepting aligned_alloc
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
 * Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
 format mismatch between libasan and GCC
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
 * Bug 78028 - ASAN doesn't find memory leak
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
 * Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
 "Unsupported arch"
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
 * Bug 78654 - ubsan can lead to excessive stack usage
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
 * Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
 headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
 * Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
 * Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
 * Bug 54123 - inline functions not optimized as well as static inline
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)

 -Y

>>>
>

Re: Killing old dead bugs

[Jonathan Wakely]

On 18 July 2017 at 16:32, Yuri Gribov wrote:
> Jonathan also mentioned something not immediately obvious in IRC:
> logging into BZ with gcc.gnu.org account provides elevated privileges.
> So if you have write access, you should get extra BZ rights for free.

We should document this at https://gcc.gnu.org/bugs/management.html
and maybe also somewhere more visible (I'd forgotten that page even
existed).

Bug in lto-plugin.c ?

[Georg-Johann Lay]

Hi, I tried to build a canadian cross with Configured with
--build=x86_64-linux-gnu
--host=i686-w64-mingw32
--target=avr

While the result appears to work under wine, I am getting the
following error from ld in a non-LTO compile + link:

e:/winavr/8.0_2017-07-18/bin/../lib/gcc/avr/8.0.0/../../../../avr/bin/ld.exe: 
error: asprintf failed


After playing around I found that -fno-use-linker-plugin avoids that
message, and I speculated that the error is emit by lto-plugin.c

In claim_file_handler() we have:


  /* We pass the offset of the actual file, not the archive header.
 Can't use PRIx64, because that's C99, so we have to print the
 64-bit hex int as two 32-bit ones. */
  int lo, hi, t;
  lo = file->offset & 0x;
  hi = ((int64_t)file->offset >> 32) & 0x;
  t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi)
 : asprintf (&objname, "%s@0x%x", file->name, lo);
  check (t >= 0, LDPL_FATAL, "asprintf failed");


If hi != 0, then why is hi printed at the low end? Shouldn't hi and lo
be swapped like so

  t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, hi, lo)

if this is supposed to yield a 64-bit print?

What else could lead to an "asprintf failed" ?  Unfortunately I have
no idea how to debug that on the host...

Johann

Re: whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?

[Trevor Saunders]

On Tue, Jul 18, 2017 at 03:52:55PM +0800, Leslie Zhai wrote:
> Hi Trevor,
> 
> Thanks for your kind response!
> 
> 在 2017年07月17日 19:51, Trevor Saunders 写道:
> > On Wed, Jul 12, 2017 at 10:12:03AM +0800, Leslie Zhai wrote:
> > > PS: Trevor's email is not available? thanks!
> > Sorry about that, I've left Mozilla and been vacationing for a month, so
> > didn't get to updating MAINTAINERS yet.  Here's a patch doing that.
> Could I use PLUGIN_REGISTER_GGC_ROOTS to take place of
> PLUGIN_REGISTER_GGC_CACHES? https://gcc.gnu.org/ml/gcc/2017-07/msg00052.html

If you are ok with your plugin keeping things alive that would otherwise
be garbage collected because they are no longer needed sure I think that
will work.  Though some things are ggc_free()ed and so you might want to
be careful touching those things that should be collected but you are
keeping alive.  Does that help?

Trev

> 
> > 
> > Trev
> > 
> > commit ff900f40d23f765fd59047a90a7e3ff18cbcbf5a
> > Author: Trevor Saunders 
> > Date:   Mon Jul 17 07:44:50 2017 -0400
> > 
> >  update my entry in MAINTAINERS
> >  ChangeLog:
> >  * MAINTAINERS: Update my email address.
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index a2f24742374..6a314049c42 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -557,7 +557,7 @@ Hariharan Sandanagobalane   
> > 
> >   Iain Sandoe   
> >   Duncan Sands  
> >   Sujoy Saraswati   
> > 
> > -Trevor Saunders
> > +Trevor Saunders
> > 
> >   Aaron Sawdey  
> > 
> >   Roger Sayle   
> >   Will Schmidt  
> > 
> 
> -- 
> Regards,
> Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/
> 
> 
> 

gcc-5-20170718 is now available

[gccadmin]

Snapshot gcc-5-20170718 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170718/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 250325

You'll find:

 gcc-5-20170718.tar.xzComplete GCC

  SHA256=bd54b008e0e948d84a8a60a4a2dc97de5b7ea252577cc1d7b3d4c7f1988b14c5
  SHA1=78f7e8fbe2a6ce8d07f54a99ad4d6ebad4244eb0

Diffs from 5-20170711 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?

[Leslie Zhai]

在 2017年07月19日 04:54, Trevor Saunders 写道:

On Tue, Jul 18, 2017 at 03:52:55PM +0800, Leslie Zhai wrote:

Hi Trevor,

Thanks for your kind response!

在 2017年07月17日 19:51, Trevor Saunders 写道:

On Wed, Jul 12, 2017 at 10:12:03AM +0800, Leslie Zhai wrote:

PS: Trevor's email is not available? thanks!

Sorry about that, I've left Mozilla and been vacationing for a month, so
didn't get to updating MAINTAINERS yet.  Here's a patch doing that.

Could I use PLUGIN_REGISTER_GGC_ROOTS to take place of
PLUGIN_REGISTER_GGC_CACHES? https://gcc.gnu.org/ml/gcc/2017-07/msg00052.html

If you are ok with your plugin keeping things alive that would otherwise
be garbage collected because they are no longer needed sure I think that
will work.  Though some things are ggc_free()ed and so you might want to
be careful touching those things that should be collected but you are
keeping alive.  Does that help?

Very helpful :) thank you so much!




Trev


Trev

commit ff900f40d23f765fd59047a90a7e3ff18cbcbf5a
Author: Trevor Saunders 
Date:   Mon Jul 17 07:44:50 2017 -0400

  update my entry in MAINTAINERS
  ChangeLog:
  * MAINTAINERS: Update my email address.

diff --git a/MAINTAINERS b/MAINTAINERS
index a2f24742374..6a314049c42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -557,7 +557,7 @@ Hariharan Sandanagobalane   

   Iain Sandoe  
   Duncan Sands 
   Sujoy Saraswati  

-Trevor Saunders
+Trevor Saunders

   Aaron Sawdey 
   Roger Sayle  
   Will Schmidt 

--
Regards,
Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/





--
Regards,
Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/

Re: Help with RTL expand and a builtins

[Martin Liška]

On 07/18/2017 04:49 PM, Segher Boessenkool wrote:

On Tue, Jul 18, 2017 at 12:49:06PM +0200, Martin Liška wrote:

Solved, tail call was responsible for dead RTL instructions.


This seems similar to https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00362.html
then.  Is it?

There are many cases where we generated dead code during expand on
purpose (some just laziness, some to avoid code complications).
Because of this it is hard to detect where we generate dead code that
is just plain wrong (should not be dead).  And such things aren't
trivial to debug :-(


Yep, exactly. It was really hard to debug! I tried many different approaches 
how to
generate sequence of RTL instructions and nothing :) Maybe writing to a 
dump_file
that RTL insns are eliminated will be handy?

Martin




Segher