Re: [PATCH/RFC] Simplify wrapped RTL op

[Segher Boessenkool]

On Tue, Aug 27, 2019 at 05:09:52AM -0500, Segher Boessenkool wrote:
> On Tue, Aug 27, 2019 at 11:12:32AM +0200, Robin Dapp wrote:
> > as announced in the wrapped-binop gimple patch mail, on s390 we still
> > emit odd code in front of loops:
> 
> >aghi%r1,-8
> >srlg%r1,%r1,3
> >aghi%r1,1
> 
> This is done like this because %r1 might be 0.
> 
> We see this same problem on Power; there are quite a few PRs about it.
> 
> [ ... ]
> 
> > helps immediately, yet overflow/range information is not considered.
> 
> Yeah, and it has to be.
> 
> > Do
> > we somehow guarantee that the niter-related we created until doloop do
> > not overflow?  I did not note something when looking through the code.
> > Granted, the simplification seems oddly specific and is probably not
> > useful for a wide range of targets and situations.
> 
> You're at least the third target, and it's pretty annoying, and it tends
> to cost more than two insns (because things can often be simplified
> further after this).  It won't do super much for execution time, there
> is a loop after this after all, a handful of insns executed once can't
> be all that expensive relatively.
> 
> > Another approach would be to store "niter+1" (== n) when niter (== n-1)
> > is calculated and, when we need to do the increment, use the niter+1
> > that we already have without needing to simplify (n - 8) >> 3 + 1.
> > 
> > Any comments on this?
> > 
> > The patch above bootstraps and test suite is without regressions on s390
> > fwiw.
> 
> When something similar was tried before there were regressions for
> rs6000.  I'll find the PR later.

PR37451.  Not clear what target that regressed on, btw.

> I was hoping that now that ivopts learns about doloops, this can be
> handled better as well.  Ideally the doloop pass can move closer to
> expand, and do much less analysis and work, all the heavy lifting has
> been done already.


Segher

Re: [PATCH] PR fortran/91565 -- Extra checks on ORDER

[Janne Blomqvist]

On Wed, Aug 28, 2019 at 1:01 AM Steve Kargl
 wrote:
>
> The attached ptch implements additional checks on the
> ORDER dummy argument for the RESHAPE intrinsic function.
> Built and regression tested on x86_64-*-freebsd.  OK to
> commit?

Ok.


-- 
Janne Blomqvist

Re: [PATCH/RFC] Simplify wrapped RTL op

[Segher Boessenkool]

On Wed, Aug 28, 2019 at 02:05:58AM -0500, Segher Boessenkool wrote:
> On Tue, Aug 27, 2019 at 05:09:52AM -0500, Segher Boessenkool wrote:
> > On Tue, Aug 27, 2019 at 11:12:32AM +0200, Robin Dapp wrote:
> > > as announced in the wrapped-binop gimple patch mail, on s390 we still
> > > emit odd code in front of loops:
> > 
> > >aghi%r1,-8
> > >srlg%r1,%r1,3
> > >aghi%r1,1
> > 
> > This is done like this because %r1 might be 0.
> > 
> > We see this same problem on Power; there are quite a few PRs about it.
> > 
> > [ ... ]
> > 
> > > helps immediately, yet overflow/range information is not considered.
> > 
> > Yeah, and it has to be.
> > 
> > > Do
> > > we somehow guarantee that the niter-related we created until doloop do
> > > not overflow?  I did not note something when looking through the code.
> > > Granted, the simplification seems oddly specific and is probably not
> > > useful for a wide range of targets and situations.
> > 
> > You're at least the third target, and it's pretty annoying, and it tends
> > to cost more than two insns (because things can often be simplified
> > further after this).  It won't do super much for execution time, there
> > is a loop after this after all, a handful of insns executed once can't
> > be all that expensive relatively.
> > 
> > > Another approach would be to store "niter+1" (== n) when niter (== n-1)
> > > is calculated and, when we need to do the increment, use the niter+1
> > > that we already have without needing to simplify (n - 8) >> 3 + 1.
> > > 
> > > Any comments on this?
> > > 
> > > The patch above bootstraps and test suite is without regressions on s390
> > > fwiw.
> > 
> > When something similar was tried before there were regressions for
> > rs6000.  I'll find the PR later.
> 
> PR37451.  Not clear what target that regressed on, btw.

And PR55190 and PR67288 and probably more.

> > I was hoping that now that ivopts learns about doloops, this can be
> > handled better as well.  Ideally the doloop pass can move closer to
> > expand, and do much less analysis and work, all the heavy lifting has
> > been done already.


Segher

New Spanish PO file for 'gcc' (version 9.1.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/es.po

(This file, 'gcc-9.1.0.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH V3 05/11] bpf: new GCC port

[Richard Sandiford]

jose.march...@oracle.com (Jose E. Marchesi) writes:
> > +(define_expand "zero_extendsidi2"
> > +  [(set (match_operand:DI 0 "register_operand")
> > +   (zero_extend:DI (match_operand:SI 1 
> "reg_or_indirect_memory_operand")))]
> > +  ""
> > +{
> > +  if (register_operand (operands[1], SImode))
> > +{
> > +  operands[1] = gen_lowpart (DImode, operands[1]);
> > +  emit_insn (gen_ashldi3 (operands[0], operands[1], GEN_INT 
> (32)));
> > +  emit_insn (gen_lshrdi3 (operands[0], operands[0], GEN_INT 
> (32)));
> > +  DONE;
> > +}
> > +})
> > +
> > +(define_insn "*zero_extendsidi2"
> > +  [(set (match_operand:DI 0 "register_operand" "=r,r")
> > +   (zero_extend:DI (match_operand:SI 1 
> "reg_or_indirect_memory_operand" "0,m")))]
> > +  ""
> > +  "@
> > +   lsh\t%0,32\n\trsh\t%0,32
> > +   ldxw\t%0,%1"
> > +  [(set_attr "type" "alu,ldx")
> > +   (set_attr "length" "16,8")])
> 
> Sorry, should have noticed last time, but: you shouldn't need to 
> handle
> register operands here given the expander above.  It's OK if you find 
> it
> improves code quality, but it'd be interesting to know why if so
> 
> If I remove the 0,=r alternative from the insn above, and also adjust
> the predicate to indirect_memory_operand, then I get a segfault in one
> test, in update_costs_from_allocno (ira-color.c:1382), because:
> 
> (gdb) print mode
> $1 = E_SImode
> (gdb) print default_target_ira_int->x_ira_register_move_cost[mode]
> $13 = (move_table *) 0x0
> 
> What I think is going on is:
> 
> 1. The expand above is used, and
> 
> 2. there is no insn in the program matched by a pattern that involves a
>SI operand, and therefore record_operand_costs is never called on
>SImode operand, and therefore the lazily-initialized
>x_ira_register_move_cost is never filled in for E_SImode, and then
> 
> 3. ira() -> ira_color() -> color () -> do_coloring () ->
>ira_traverse_loop_tree () -> color_pass () -> color_allocnos () ->
>update_costs_from_prefs () -> update_costs_from_allocno () *CRASH*
> 
> Is this a bug, or am I expected to somehow trigger the initialization of
> the SImode entry in the ira register move table in some other way?
>
> This is the backtrace btw:
>
> jemarch@termi:~/gnu/src/gcc-git/build-bpf/gcc$ PATH=.:$PATH ./xgcc -O2 -c 
> /home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c
> during RTL pass: ira
> /home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c:
>  In function ‘vq_nbest’:
> /home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c:8:1:
>  internal compiler error: Segmentation fault
> 8 | }
>   | ^
> 0xfa8cb7 crash_signal
>   ../../gcc/toplev.c:326
> 0x7f278d44e05f ???
>   
> /build/glibc-yWQXbR/glibc-2.24/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
> 0xd4ec8b update_costs_from_allocno
>   ../../gcc/ira-color.c:1382
> 0xd4ee09 update_costs_from_prefs
>   ../../gcc/ira-color.c:1422
> 0xd535d9 color_allocnos
>   ../../gcc/ira-color.c:3170
> 0xd53e21 color_pass
>   ../../gcc/ira-color.c:3309
> 0xd39b10 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void 
> (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
>   ../../gcc/ira-build.c:1781
> 0xd54703 do_coloring
>   ../../gcc/ira-color.c:3460
> 0xd58203 color
>   ../../gcc/ira-color.c:4837
> 0xd58746 ira_color()
>   ../../gcc/ira-color.c:4968
> 0xd34990 ira
>   ../../gcc/ira.c:5365
> 0xd35118 execute
>   ../../gcc/ira.c:5663
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

Yeah, this looks like a bug.  Further up we have:

  mode = ALLOCNO_MODE (allocno);
  ira_init_register_move_cost_if_necessary (mode);

which copes with the lazy initialisation.  But then we have:

  mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
  
  cost = (cp->second == allocno
  ? ira_register_move_cost[mode][rclass][aclass]
  : ira_register_move_cost[mode][aclass][rclass]);

where we can change the mode without initialising the move cost tables.
Does it work if you change it to:

  if (paradoxical_subreg_p (mode, ALLOCNO_MODE (cp->second)))
{
  mode = ALLOCNO_MODE (cp->second);
  ira_init_register_move_cost_if_necessary (mode);
}

?  The mode handling seems generally a bit weird though: we never
reset "mode" when processing the next copy, and "cp->second" might
be "allocno" itself, depending on which way round the move is.

Re: [PATCH V4 00/11] eBPF support for GCC

[Richard Sandiford]

"Jose E. Marchesi"  writes:
> [Differences from V3:
> . Formatting/style fixes:
>   + Remove redundant braces.
>   + Remove unneeded ATTRIBUTE_UNUSED.
>   + Truncate too long lines.
>   + Remove an odd line split.
>   + Do not break after returns.
>   + Use function_arg_info methods instead of auxiliary functions.
>   + Fix indentation in cbranchdi4.
> . Use `sorry' and sorry_at to report lack of support for valid
>   constructs.
> . Rename GR_REGS to GENERAL_REGS and exclude the pseudo arg_reg
>   from the class.

As discussed on IRC, a simple NO_REGS/ALL_REGS split should be fine,
as for VAX.  I don't think there's any reason in principle why
GENERAL_REGS mustn't include the arg pointer while ALL_REGS must.

The IRA move cost segfault looks like a simple oversight.  It'd be
interesting to know why you only see the segfault with two classes --
is there a specific reason that it can only happen there? -- but
I don't think the segfault itself should be the reason for defining
the classes as above.

Thanks,
Richard

[PATCH] Remove MD problem from STV

[Richard Biener]

STV is interested in DU/UD chains only but for some reason
(since first patch submission) adds MD.  I can't make any sense
of this and in fact I miss the difference between RD and MD.
The only other user of MD is fwprop which says

  /* We use the multiple definitions problem to compute our restricted
 use-def chains.  */

but does not add the chain problems (only md and note), instead it

  /* Walk the dominator tree looking for single reaching definitions
 dominating the uses.  This is similar to how SSA form is built.  */

talking about "reaching definitions" again.  The comments in
df-problems.c do not talk about differences between MD and RD,
the first sentences suggest that MD does not compute anything
if there's just a single reaching definition?  It also doesn't
talk about relative cost of the two problems.  RD doesn't seem
to be used on its own by anyone.

Well.  The following patch removes MD from STV, bootstrapped and
tested on x86_64-unknown-linux-gnu with Westmere arch and STV
forced on.

OK?

Thanks,
Richard.

2019-08-28  Richard Biener  

* config/i386/i386-features.c (convert_scalars_to_vector): Do not
add the MD problem.

Index: gcc/config/i386/i386-features.c
===
--- gcc/config/i386/i386-features.c (revision 274983)
+++ gcc/config/i386/i386-features.c (working copy)
@@ -1564,7 +1570,6 @@ convert_scalars_to_vector (bool timode_p
   calculate_dominance_info (CDI_DOMINATORS);
   df_set_flags (DF_DEFER_INSN_RESCAN);
   df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
-  df_md_add_problem ();
   df_analyze ();
 
   /* Find all instructions we want to convert into vector mode.  */

Re: [RFC] [AARCH64] Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

[Shaokun Zhang]

Hi Kyrill,

On 2019/8/27 18:16, Kyrill Tkachov wrote:
> Hi Shaokun,
> 
> On 8/22/19 3:10 PM, Shaokun Zhang wrote:
>> The DCache clean & ICache invalidation requirements for instructions
>> to be data coherence are discoverable through new fields in CTR_EL0.
>> Let's support the two bits if they are enabled, then we can get some
>> performance benefit from this feature.
>>
>> 2019-08-22  Shaokun Zhang 
>>
>> * config/aarch64/sync-cache.c: Support CTR_EL0.IDC and CTR_EL0.DIC
>>
> This needs to mention __aarch64_sync_cache_range as the function being 
> changed.
> 

Ok, I will update in next version.

> 
>> ---
>>  libgcc/config/aarch64/sync-cache.c | 56 
>> --
>>  1 file changed, 35 insertions(+), 21 deletions(-)
>>
>> diff --git a/libgcc/config/aarch64/sync-cache.c 
>> b/libgcc/config/aarch64/sync-cache.c
>> index 791f5e42ff44..0b057efbdcab 100644
>> --- a/libgcc/config/aarch64/sync-cache.c
>> +++ b/libgcc/config/aarch64/sync-cache.c
>> @@ -23,6 +23,9 @@ a copy of the GCC Runtime Library Exception along with 
>> this program;
>>  see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
>>  . */
>>
>> +#define CTR_IDC_SHIFT   28
>> +#define CTR_DIC_SHIFT   29
>> +
>>  void __aarch64_sync_cache_range (const void *, const void *);
>>
>>  void
>> @@ -41,32 +44,43 @@ __aarch64_sync_cache_range (const void *base, const void 
>> *end)
>>icache_lsize = 4 << (cache_info & 0xF);
>>dcache_lsize = 4 << ((cache_info >> 16) & 0xF);
>>
>> -  /* Loop over the address range, clearing one cache line at once.
>> - Data cache must be flushed to unification first to make sure the
>> - instruction cache fetches the updated data.  'end' is exclusive,
>> - as per the GNU definition of __clear_cache.  */
>> +  /* If CTR_EL0.IDC is enabled, Data cache clean to the Point of 
>> Unification is
>> + not required for instruction to data coherence.  */
>> +
>> +  if ((cache_info >> CTR_IDC_SHIFT) & 0x1 == 0x0) {
>> +/* Loop over the address range, clearing one cache line at once.
>> +   Data cache must be flushed to unification first to make sure the
>> +   instruction cache fetches the updated data.  'end' is exclusive,
>> +   as per the GNU definition of __clear_cache.  */
>>
>> -  /* Make the start address of the loop cache aligned.  */
>> -  address = (const char*) ((__UINTPTR_TYPE__) base
>> -  & ~ (__UINTPTR_TYPE__) (dcache_lsize - 1));
>> +/* Make the start address of the loop cache aligned. */
>> +address = (const char*) ((__UINTPTR_TYPE__) base
>> +& ~ (__UINTPTR_TYPE__) (dcache_lsize - 1));
>>
>> -  for (; address < (const char *) end; address += dcache_lsize)
>> -asm volatile ("dc\tcvau, %0"
>> - :
>> - : "r" (address)
>> - : "memory");
>> +for (; address < (const char *) end; address += dcache_lsize)
>> +  asm volatile ("dc\tcvau, %0"
>> +   :
>> +   : "r" (address)
>> +   : "memory");
>> +  }
>>
>>asm volatile ("dsb\tish" : : : "memory");
>>
>> -  /* Make the start address of the loop cache aligned.  */
>> -  address = (const char*) ((__UINTPTR_TYPE__) base
>> -  & ~ (__UINTPTR_TYPE__) (icache_lsize - 1));
>> +  /* If CTR_EL0.DIC is enabled, Instruction cache cleaning to the Point of
>> + Unification is not required for instruction to data coherence.  */
>> +
>> +  if ((cache_info >> CTR_DIC_SHIFT) & 0x1 == 0x0) {
>> +/* Make the start address of the loop cache aligned. */
>> +address = (const char*) ((__UINTPTR_TYPE__) base
>> +& ~ (__UINTPTR_TYPE__) (icache_lsize - 1));
>>
>> -  for (; address < (const char *) end; address += icache_lsize)
>> -asm volatile ("ic\tivau, %0"
>> - :
>> - : "r" (address)
>> - : "memory");
>> +for (; address < (const char *) end; address += icache_lsize)
>> +  asm volatile ("ic\tivau, %0"
>> +   :
>> +   : "r" (address)
>> +   : "memory");
>>
>> -  asm volatile ("dsb\tish; isb" : : : "memory");
>> +asm volatile ("dsb\tish" : : : "memory");
>> +  }
>> +  asm volatile("isb" : : : "memory")
>>  }
> 
> This looks ok to me (but you'll need approval from the maintainers).
> 
> There is a question of whether we need the barriers if both DIC and IDC are 1 
> (in which case no cache-maintentance instructions are emitted).
> 
> I think we still want them to ensure the writes have been completed and the 
> fetches from the updated cache are up-to-date.
> 

At the beginning, I'm not sure how to deal with the barrier instructions if DIC 
and IDC
are 1, So I sent one mail to discuss it, it is a pity that no response.
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg217561.html

>From the arm ARM document:
STR W11, [X1]   

Re: [RFC] [AARCH64] Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

[Kyrill Tkachov]

Hi Shaokun,

On 8/28/19 9:47 AM, Shaokun Zhang wrote:

Hi Kyrill,

On 2019/8/27 18:16, Kyrill Tkachov wrote:

Hi Shaokun,

On 8/22/19 3:10 PM, Shaokun Zhang wrote:

The DCache clean & ICache invalidation requirements for instructions
to be data coherence are discoverable through new fields in CTR_EL0.
Let's support the two bits if they are enabled, then we can get some
performance benefit from this feature.

2019-08-22  Shaokun Zhang 

 * config/aarch64/sync-cache.c: Support CTR_EL0.IDC and CTR_EL0.DIC


This needs to mention __aarch64_sync_cache_range as the function being changed.


Ok, I will update in next version.


---
  libgcc/config/aarch64/sync-cache.c | 56 --
  1 file changed, 35 insertions(+), 21 deletions(-)

diff --git a/libgcc/config/aarch64/sync-cache.c 
b/libgcc/config/aarch64/sync-cache.c
index 791f5e42ff44..0b057efbdcab 100644
--- a/libgcc/config/aarch64/sync-cache.c
+++ b/libgcc/config/aarch64/sync-cache.c
@@ -23,6 +23,9 @@ a copy of the GCC Runtime Library Exception along with this 
program;
  see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
  . */

+#define CTR_IDC_SHIFT   28
+#define CTR_DIC_SHIFT   29
+
  void __aarch64_sync_cache_range (const void *, const void *);

  void
@@ -41,32 +44,43 @@ __aarch64_sync_cache_range (const void *base, const void 
*end)
icache_lsize = 4 << (cache_info & 0xF);
dcache_lsize = 4 << ((cache_info >> 16) & 0xF);

-  /* Loop over the address range, clearing one cache line at once.
- Data cache must be flushed to unification first to make sure the
- instruction cache fetches the updated data.  'end' is exclusive,
- as per the GNU definition of __clear_cache.  */
+  /* If CTR_EL0.IDC is enabled, Data cache clean to the Point of Unification is
+ not required for instruction to data coherence.  */
+
+  if ((cache_info >> CTR_IDC_SHIFT) & 0x1 == 0x0) {
+/* Loop over the address range, clearing one cache line at once.
+   Data cache must be flushed to unification first to make sure the
+   instruction cache fetches the updated data.  'end' is exclusive,
+   as per the GNU definition of __clear_cache.  */

-  /* Make the start address of the loop cache aligned.  */
-  address = (const char*) ((__UINTPTR_TYPE__) base
-  & ~ (__UINTPTR_TYPE__) (dcache_lsize - 1));
+/* Make the start address of the loop cache aligned. */
+address = (const char*) ((__UINTPTR_TYPE__) base
+& ~ (__UINTPTR_TYPE__) (dcache_lsize - 1));

-  for (; address < (const char *) end; address += dcache_lsize)
-asm volatile ("dc\tcvau, %0"
- :
- : "r" (address)
- : "memory");
+for (; address < (const char *) end; address += dcache_lsize)
+  asm volatile ("dc\tcvau, %0"
+   :
+   : "r" (address)
+   : "memory");
+  }

asm volatile ("dsb\tish" : : : "memory");

-  /* Make the start address of the loop cache aligned.  */
-  address = (const char*) ((__UINTPTR_TYPE__) base
-  & ~ (__UINTPTR_TYPE__) (icache_lsize - 1));
+  /* If CTR_EL0.DIC is enabled, Instruction cache cleaning to the Point of
+ Unification is not required for instruction to data coherence.  */
+
+  if ((cache_info >> CTR_DIC_SHIFT) & 0x1 == 0x0) {
+/* Make the start address of the loop cache aligned. */
+address = (const char*) ((__UINTPTR_TYPE__) base
+& ~ (__UINTPTR_TYPE__) (icache_lsize - 1));

-  for (; address < (const char *) end; address += icache_lsize)
-asm volatile ("ic\tivau, %0"
- :
- : "r" (address)
- : "memory");
+for (; address < (const char *) end; address += icache_lsize)
+  asm volatile ("ic\tivau, %0"
+   :
+   : "r" (address)
+   : "memory");

-  asm volatile ("dsb\tish; isb" : : : "memory");
+asm volatile ("dsb\tish" : : : "memory");
+  }
+  asm volatile("isb" : : : "memory")
  }

This looks ok to me (but you'll need approval from the maintainers).

There is a question of whether we need the barriers if both DIC and IDC are 1 
(in which case no cache-maintentance instructions are emitted).

I think we still want them to ensure the writes have been completed and the 
fetches from the updated cache are up-to-date.


At the beginning, I'm not sure how to deal with the barrier instructions if DIC 
and IDC
are 1, So I sent one mail to discuss it, it is a pity that no response.
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg217561.html


Sorry for that. August is a tricky month due to summer vacation in many 
places and mail can slip through the cracks...


I recommend you ping your question if you haven't had a reply within a 
week or so.




 From the arm ARM document:
 STR W11, [X1] ; W11 contains a new inst

Re: [SVE] PR86753

[Richard Sandiford]

Prathamesh Kulkarni  writes:
> On Tue, 27 Aug 2019 at 21:14, Richard Sandiford
>  wrote:
>>
>> Richard should have the final say, but some comments...
>>
>> Prathamesh Kulkarni  writes:
>> > diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
>> > index 1e2dfe5d22d..862206b3256 100644
>> > --- a/gcc/tree-vect-stmts.c
>> > +++ b/gcc/tree-vect-stmts.c
>> > @@ -1989,17 +1989,31 @@ check_load_store_masking (loop_vec_info 
>> > loop_vinfo, tree vectype,
>> >
>> >  static tree
>> >  prepare_load_store_mask (tree mask_type, tree loop_mask, tree vec_mask,
>> > -  gimple_stmt_iterator *gsi)
>> > +  gimple_stmt_iterator *gsi, tree mask,
>> > +  cond_vmask_map_type *cond_to_vec_mask)
>>
>> "scalar_mask" might be a better name.  But maybe we should key off the
>> vector mask after all, now that we're relying on the code having no
>> redundancies.
>>
>> Passing the vinfo would be better than passing the cond_vmask_map_type
>> directly.
>>
>> >  {
>> >gcc_assert (useless_type_conversion_p (mask_type, TREE_TYPE 
>> > (vec_mask)));
>> >if (!loop_mask)
>> >  return vec_mask;
>> >
>> >gcc_assert (TREE_TYPE (loop_mask) == mask_type);
>> > +
>> > +  tree *slot = 0;
>> > +  if (cond_to_vec_mask)
>>
>> The pointer should never be null in this context.
> Disabling check for NULL results in segfault with cond_arith_4.c because we
> reach prepare_load_store_mask via vect_schedule_slp, called from
> here in vect_transform_loop:
>  /* Schedule the SLP instances first, then handle loop vectorization
>  below.  */
>   if (!loop_vinfo->slp_instances.is_empty ())
> {
>   DUMP_VECT_SCOPE ("scheduling SLP instances");
>   vect_schedule_slp (loop_vinfo);
> }
>
> which is before bb processing loop.

We want this optimisation to be applied to SLP too though.  Especially
since non-SLP will be going away at some point.

But as Richard says, the problem with SLP is that the statements aren't
traversed in block order, so I guess we can't do the on-the-fly
redundancy elimination there...

Maybe an alternative would be to record during the analysis phase which
scalar conditions need which loop masks.  Statements that need a loop
mask currently do:

  vect_record_loop_mask (loop_vinfo, masks, ncopies, vectype);

If we also pass the scalar condition, we can maintain a hash_set of
 pairs, representing the conditions that have
loop masks applied at some point in the vectorised code.  The COND_EXPR
code can use that set to decide whether to apply the loop mask or not.

Trying to avoid duplicate ANDs with the loop mask would then become a
separate follow-on change.  Not sure whether it's worth it on its own.

Thanks,
Richard

Re: [RFC] [AARCH64] Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

[Shaokun Zhang]

Hi Kyrill,

On 2019/8/28 16:57, Kyrill Tkachov wrote:
> Hi Shaokun,
> 
> On 8/28/19 9:47 AM, Shaokun Zhang wrote:
>> Hi Kyrill,
>>
>> On 2019/8/27 18:16, Kyrill Tkachov wrote:
>>> Hi Shaokun,
>>>
>>> On 8/22/19 3:10 PM, Shaokun Zhang wrote:
 The DCache clean & ICache invalidation requirements for instructions
 to be data coherence are discoverable through new fields in CTR_EL0.
 Let's support the two bits if they are enabled, then we can get some
 performance benefit from this feature.

 2019-08-22  Shaokun Zhang 

  * config/aarch64/sync-cache.c: Support CTR_EL0.IDC and CTR_EL0.DIC

>>> This needs to mention __aarch64_sync_cache_range as the function being 
>>> changed.
>>>
>> Ok, I will update in next version.
>>
 ---
   libgcc/config/aarch64/sync-cache.c | 56 
 --
   1 file changed, 35 insertions(+), 21 deletions(-)

 diff --git a/libgcc/config/aarch64/sync-cache.c 
 b/libgcc/config/aarch64/sync-cache.c
 index 791f5e42ff44..0b057efbdcab 100644
 --- a/libgcc/config/aarch64/sync-cache.c
 +++ b/libgcc/config/aarch64/sync-cache.c
 @@ -23,6 +23,9 @@ a copy of the GCC Runtime Library Exception along with 
 this program;
   see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
   . */

 +#define CTR_IDC_SHIFT   28
 +#define CTR_DIC_SHIFT   29
 +
   void __aarch64_sync_cache_range (const void *, const void *);

   void
 @@ -41,32 +44,43 @@ __aarch64_sync_cache_range (const void *base, const 
 void *end)
 icache_lsize = 4 << (cache_info & 0xF);
 dcache_lsize = 4 << ((cache_info >> 16) & 0xF);

 -  /* Loop over the address range, clearing one cache line at once.
 - Data cache must be flushed to unification first to make sure the
 - instruction cache fetches the updated data.  'end' is exclusive,
 - as per the GNU definition of __clear_cache.  */
 +  /* If CTR_EL0.IDC is enabled, Data cache clean to the Point of 
 Unification is
 + not required for instruction to data coherence.  */
 +
 +  if ((cache_info >> CTR_IDC_SHIFT) & 0x1 == 0x0) {
 +/* Loop over the address range, clearing one cache line at once.
 +   Data cache must be flushed to unification first to make sure the
 +   instruction cache fetches the updated data.  'end' is exclusive,
 +   as per the GNU definition of __clear_cache.  */

 -  /* Make the start address of the loop cache aligned.  */
 -  address = (const char*) ((__UINTPTR_TYPE__) base
 -  & ~ (__UINTPTR_TYPE__) (dcache_lsize - 1));
 +/* Make the start address of the loop cache aligned. */
 +address = (const char*) ((__UINTPTR_TYPE__) base
 +& ~ (__UINTPTR_TYPE__) (dcache_lsize - 1));

 -  for (; address < (const char *) end; address += dcache_lsize)
 -asm volatile ("dc\tcvau, %0"
 - :
 - : "r" (address)
 - : "memory");
 +for (; address < (const char *) end; address += dcache_lsize)
 +  asm volatile ("dc\tcvau, %0"
 +   :
 +   : "r" (address)
 +   : "memory");
 +  }

 asm volatile ("dsb\tish" : : : "memory");

 -  /* Make the start address of the loop cache aligned.  */
 -  address = (const char*) ((__UINTPTR_TYPE__) base
 -  & ~ (__UINTPTR_TYPE__) (icache_lsize - 1));
 +  /* If CTR_EL0.DIC is enabled, Instruction cache cleaning to the Point of
 + Unification is not required for instruction to data coherence.  */
 +
 +  if ((cache_info >> CTR_DIC_SHIFT) & 0x1 == 0x0) {
 +/* Make the start address of the loop cache aligned. */
 +address = (const char*) ((__UINTPTR_TYPE__) base
 +& ~ (__UINTPTR_TYPE__) (icache_lsize - 1));

 -  for (; address < (const char *) end; address += icache_lsize)
 -asm volatile ("ic\tivau, %0"
 - :
 - : "r" (address)
 - : "memory");
 +for (; address < (const char *) end; address += icache_lsize)
 +  asm volatile ("ic\tivau, %0"
 +   :
 +   : "r" (address)
 +   : "memory");

 -  asm volatile ("dsb\tish; isb" : : : "memory");
 +asm volatile ("dsb\tish" : : : "memory");
 +  }
 +  asm volatile("isb" : : : "memory")
   }
>>> This looks ok to me (but you'll need approval from the maintainers).
>>>
>>> There is a question of whether we need the barriers if both DIC and IDC are 
>>> 1 (in which case no cache-maintentance instructions are emitted).
>>>
>>> I think we still want them to ensure the writes have been compl

Re: [PATCH] Remove MD problem from STV

[Uros Bizjak]

On Wed, Aug 28, 2019 at 10:14 AM Richard Biener  wrote:
>
>
> STV is interested in DU/UD chains only but for some reason
> (since first patch submission) adds MD.  I can't make any sense
> of this and in fact I miss the difference between RD and MD.
> The only other user of MD is fwprop which says
>
>   /* We use the multiple definitions problem to compute our restricted
>  use-def chains.  */
>
> but does not add the chain problems (only md and note), instead it
>
>   /* Walk the dominator tree looking for single reaching definitions
>  dominating the uses.  This is similar to how SSA form is built.  */
>
> talking about "reaching definitions" again.  The comments in
> df-problems.c do not talk about differences between MD and RD,
> the first sentences suggest that MD does not compute anything
> if there's just a single reaching definition?  It also doesn't
> talk about relative cost of the two problems.  RD doesn't seem
> to be used on its own by anyone.
>
> Well.  The following patch removes MD from STV, bootstrapped and
> tested on x86_64-unknown-linux-gnu with Westmere arch and STV
> forced on.
>
> OK?
>
> Thanks,
> Richard.
>
> 2019-08-28  Richard Biener  
>
> * config/i386/i386-features.c (convert_scalars_to_vector): Do not
> add the MD problem.

OK.

Thanks,
Uros.

> Index: gcc/config/i386/i386-features.c
> ===
> --- gcc/config/i386/i386-features.c (revision 274983)
> +++ gcc/config/i386/i386-features.c (working copy)
> @@ -1564,7 +1570,6 @@ convert_scalars_to_vector (bool timode_p
>calculate_dominance_info (CDI_DOMINATORS);
>df_set_flags (DF_DEFER_INSN_RESCAN);
>df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
> -  df_md_add_problem ();
>df_analyze ();
>
>/* Find all instructions we want to convert into vector mode.  */

Re: [PATCH] Sanitizing the middle-end interface to the back-end for strict alignment

[Bernd Edlinger]

On 8/27/19 11:25 AM, Kyrill Tkachov wrote:
> Hi Bernd,
> 
> On 8/15/19 8:47 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this is the split out part from the "Fix not 8-byte aligned ldrd/strd on 
>> ARMv5 (PR 89544)"
>> which is sanitizing the middle-end interface to the back-end for strict 
>> alignment,
>> and a couple of bug-fixes that are necessary to survive boot-strap.
>> It is intended to be applied after the PR 89544 fix.
>>
>> I think it would be possible to change the default implementation of 
>> STACK_SLOT_ALIGNMENT
>> to make all stack variables always naturally aligned instead of doing that 
>> only
>> in assign_parm_setup_stack, but would still like to avoid changing too many 
>> things
>> that do not seem to have a problem.  Since this would affect many targets, 
>> and more
>> kinds of variables that may probably not have a strict alignment problem.
>> But I am ready to take your advice though.
>>
>>
>> Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf
>> Is it OK for trunk?
> 
> I'm not opposed to the checks but...
> 
> 
>>
>> Thanks
>> Bernd.
>>
> 
> Index: gcc/config/arm/vec-common.md
> ===
> --- gcc/config/arm/vec-common.md    (Revision 274531)
> +++ gcc/config/arm/vec-common.md    (Arbeitskopie)
> @@ -26,6 +26,12 @@
>    "TARGET_NEON
>     || (TARGET_REALLY_IWMMXT && VALID_IWMMXT_REG_MODE (mode))"
>  {
> +  gcc_checking_assert (!MEM_P (operands[0])
> +   || MEM_ALIGN (operands[0])
> +  >= GET_MODE_ALIGNMENT (mode));
> +  gcc_checking_assert (!MEM_P (operands[1])
> +   || MEM_ALIGN (operands[1])
> +  >= GET_MODE_ALIGNMENT (mode));
>    if (can_create_pseudo_p ())
>  {
>    if (!REG_P (operands[0]))
> 
> ... can we please factor the (!MEM_P (operands[0]) || MEM_ALIGN (operands[0]) 
> >= GET_MODE_ALIGNMENT (mode)) checks into a common function and use 
> that?
> 

Sure, good idea.  How about converting it to a predicate?
This creates 1:1 equivalent code to the open coded assertions.

Is it OK for trunk?


Thanks
Bernd.
2019-08-15  Bernd Edlinger  
	Richard Biener  

	* expr.c (expand_assignment): Handle misaligned DECLs.
	(expand_expr_real_1): Handle FUNCTION_DECL as unaligned.
	* function.c (assign_parm_adjust_stack_rtl): Check movmisalign optab
	too.
	(assign_parm_setup_stack): Allocate properly aligned stack slots.
	* varasm.c (build_constant_desc): Align constants of misaligned types.
	* config/arm/predicates.md (aligned_operand): New predicate.
	* config/arm/arm.md (movdi, movsi, movhi, movhf, movsf, movdf): Use
	sligned_operand to check restrictions on memory addresses.
	* config/arm/neon.md (movti, mov, mov): Likewise.
	* config/arm/vec-common.md (mov): Likewise.

Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md	(revision 274946)
+++ gcc/config/arm/arm.md	(working copy)
@@ -5231,6 +5231,8 @@
 	(match_operand:DI 1 "general_operand"))]
   "TARGET_EITHER"
   "
+  gcc_checking_assert (aligned_operand (operands[0], DImode));
+  gcc_checking_assert (aligned_operand (operands[1], DImode));
   if (can_create_pseudo_p ())
 {
   if (!REG_P (operands[0]))
@@ -5407,6 +5409,8 @@
   {
   rtx base, offset, tmp;
 
+  gcc_checking_assert (aligned_operand (operands[0], SImode));
+  gcc_checking_assert (aligned_operand (operands[1], SImode));
   if (TARGET_32BIT || TARGET_HAVE_MOVT)
 {
   /* Everything except mem = const or mem = mem can be done easily.  */
@@ -5896,6 +5900,8 @@
 	(match_operand:HI 1 "general_operand"))]
   "TARGET_EITHER"
   "
+  gcc_checking_assert (aligned_operand (operands[0], HImode));
+  gcc_checking_assert (aligned_operand (operands[1], HImode));
   if (TARGET_ARM)
 {
   if (can_create_pseudo_p ())
@@ -6305,6 +6311,8 @@
 	(match_operand:HF 1 "general_operand"))]
   "TARGET_EITHER"
   "
+  gcc_checking_assert (aligned_operand (operands[0], HFmode));
+  gcc_checking_assert (aligned_operand (operands[1], HFmode));
   if (TARGET_32BIT)
 {
   if (MEM_P (operands[0]))
@@ -6369,6 +6377,8 @@
 	(match_operand:SF 1 "general_operand"))]
   "TARGET_EITHER"
   "
+  gcc_checking_assert (aligned_operand (operands[0], SFmode));
+  gcc_checking_assert (aligned_operand (operands[1], SFmode));
   if (TARGET_32BIT)
 {
   if (MEM_P (operands[0]))
@@ -6464,6 +6474,8 @@
 	(match_operand:DF 1 "general_operand"))]
   "TARGET_EITHER"
   "
+  gcc_checking_assert (aligned_operand (operands[0], DFmode));
+  gcc_checking_assert (aligned_operand (operands[1], DFmode));
   if (TARGET_32BIT)
 {
   if (MEM_P (operands[0]))
Index: gcc/config/arm/neon.md
===
--- gcc/config/arm/neon.md	(revision 274946)
+++ gcc/config/arm/neon.md	(working copy)
@@ -127,6 +127,8 @@
 	(match_operand:TI 1 "general_operand"))]
   "TARGET_NEON"
 {
+  gcc_checking_assert (aligned_operand (operands[0], TImode));

Re: [PATCH] Sanitizing the middle-end interface to the back-end for strict alignment

[Kyrill Tkachov]

On 8/28/19 10:38 AM, Bernd Edlinger wrote:

On 8/27/19 11:25 AM, Kyrill Tkachov wrote:

Hi Bernd,

On 8/15/19 8:47 PM, Bernd Edlinger wrote:

Hi,

this is the split out part from the "Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 
89544)"
which is sanitizing the middle-end interface to the back-end for strict 
alignment,
and a couple of bug-fixes that are necessary to survive boot-strap.
It is intended to be applied after the PR 89544 fix.

I think it would be possible to change the default implementation of 
STACK_SLOT_ALIGNMENT
to make all stack variables always naturally aligned instead of doing that only
in assign_parm_setup_stack, but would still like to avoid changing too many 
things
that do not seem to have a problem.  Since this would affect many targets, and 
more
kinds of variables that may probably not have a strict alignment problem.
But I am ready to take your advice though.


Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf
Is it OK for trunk?

I'm not opposed to the checks but...



Thanks
Bernd.


Index: gcc/config/arm/vec-common.md
===
--- gcc/config/arm/vec-common.md    (Revision 274531)
+++ gcc/config/arm/vec-common.md    (Arbeitskopie)
@@ -26,6 +26,12 @@
    "TARGET_NEON
     || (TARGET_REALLY_IWMMXT && VALID_IWMMXT_REG_MODE (mode))"
  {
+  gcc_checking_assert (!MEM_P (operands[0])
+   || MEM_ALIGN (operands[0])
+  >= GET_MODE_ALIGNMENT (mode));
+  gcc_checking_assert (!MEM_P (operands[1])
+   || MEM_ALIGN (operands[1])
+  >= GET_MODE_ALIGNMENT (mode));
    if (can_create_pseudo_p ())
  {
    if (!REG_P (operands[0]))

... can we please factor the (!MEM_P (operands[0]) || MEM_ALIGN (operands[0]) >= 
GET_MODE_ALIGNMENT (mode)) checks into a common function and use that?


Sure, good idea.  How about converting it to a predicate?
This creates 1:1 equivalent code to the open coded assertions.

Is it OK for trunk?


Thanks
Bernd.



patch-strict-align.diff

2019-08-15  Bernd Edlinger
Richard Biener

* expr.c (expand_assignment): Handle misaligned DECLs.
(expand_expr_real_1): Handle FUNCTION_DECL as unaligned.
* function.c (assign_parm_adjust_stack_rtl): Check movmisalign optab
too.
(assign_parm_setup_stack): Allocate properly aligned stack slots.
* varasm.c (build_constant_desc): Align constants of misaligned types.
* config/arm/predicates.md (aligned_operand): New predicate.
* config/arm/arm.md (movdi, movsi, movhi, movhf, movsf, movdf): Use
sligned_operand to check restrictions on memory addresses.

typo in "aligned_operand"

    * config/arm/neon.md (movti, mov, mov): Likewise.
* config/arm/vec-common.md (mov): Likewise.


Looks good now.

Ok, thanks!

Kyrill

Re: [PATCH] Add vec_sh{l,r}_v4sf (PR libgomp/91530)

[Uros Bizjak]

On Wed, Aug 28, 2019 at 8:45 AM Jakub Jelinek  wrote:
>
> Hi!
>
> The following two testcases FAIL to be vectorized, because SSE2 doesn't have
> many permutation instructions and the one that actually works (whole vector
> shifts) aren't enabled for the V4SFmode.
>
> The following patch fixes it by enabling those optabs also for V4SFmode (and
> V2DFmode).  Strictly speaking, we need it only for the VI_128 modes plus
> V4SFmode, but I'm not sure it is worth adding yet another iterator for
> VI_128 + V4SF and the instructions actually do work for V2DFmode too, just
> there are also other permutation instructions that handle V2DFmode.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-08-28  Jakub Jelinek  
>
> PR libgomp/91530
> * config/i386/sse.md (vec_shl_, vec_shr_): Use
> V_128 iterator instead of VI_128.
>
> * testsuite/libgomp.c/scan-21.c: New test.
> * testsuite/libgomp.c/scan-22.c: New test.

OK.

(We already use integer shifts in floating-point context, e.g.
signbit2 expander in sse.md.)

Thanks,
Uros.

> --- gcc/config/i386/sse.md.jj   2019-08-27 12:26:25.385089103 +0200
> +++ gcc/config/i386/sse.md  2019-08-27 13:50:42.594849445 +0200
> @@ -12047,9 +12047,9 @@ (define_insn "3  (define_expand "vec_shl_"
>[(set (match_dup 3)
> (ashift:V1TI
> -(match_operand:VI_128 1 "register_operand")
> +(match_operand:V_128 1 "register_operand")
>  (match_operand:SI 2 "const_0_to_255_mul_8_operand")))
> -   (set (match_operand:VI_128 0 "register_operand") (match_dup 4))]
> +   (set (match_operand:V_128 0 "register_operand") (match_dup 4))]
>"TARGET_SSE2"
>  {
>operands[1] = gen_lowpart (V1TImode, operands[1]);
> @@ -12060,9 +12060,9 @@ (define_expand "vec_shl_"
>  (define_expand "vec_shr_"
>[(set (match_dup 3)
> (lshiftrt:V1TI
> -(match_operand:VI_128 1 "register_operand")
> +(match_operand:V_128 1 "register_operand")
>  (match_operand:SI 2 "const_0_to_255_mul_8_operand")))
> -   (set (match_operand:VI_128 0 "register_operand") (match_dup 4))]
> +   (set (match_operand:V_128 0 "register_operand") (match_dup 4))]
>"TARGET_SSE2"
>  {
>operands[1] = gen_lowpart (V1TImode, operands[1]);
> --- libgomp/testsuite/libgomp.c/scan-21.c.jj2019-08-27 22:56:03.805127837 
> +0200
> +++ libgomp/testsuite/libgomp.c/scan-21.c   2019-08-27 22:58:26.347043679 
> +0200
> @@ -0,0 +1,6 @@
> +/* { dg-require-effective-target size32plus } */
> +/* { dg-require-effective-target avx_runtime } */
> +/* { dg-additional-options "-O2 -fopenmp -fdump-tree-vect-details -msse2 
> -mno-sse3" } */
> +/* { dg-final { scan-tree-dump-times "vectorized \[2-6] loops" 2 "vect" } } 
> */
> +
> +#include "scan-13.c"
> --- libgomp/testsuite/libgomp.c/scan-22.c.jj2019-08-27 22:56:51.034437425 
> +0200
> +++ libgomp/testsuite/libgomp.c/scan-22.c   2019-08-27 22:59:01.978522645 
> +0200
> @@ -0,0 +1,6 @@
> +/* { dg-require-effective-target size32plus } */
> +/* { dg-require-effective-target avx_runtime } */
> +/* { dg-additional-options "-O2 -fopenmp -fdump-tree-vect-details -msse2 
> -mno-sse3" } */
> +/* { dg-final { scan-tree-dump-times "vectorized \[2-6] loops" 2 "vect" } } 
> */
> +
> +#include "scan-17.c"
>
> Jakub

[PATCH] Fix PR91568

[Richard Biener]

When making the SLP tree a graph I messed up and in some cases we can
fail to propagate a higher max_nunits upwards when re-using a subtree.
For the testcase, but only on the gcc-9-branch, this causes us to
miss a higher value of 4 completely since it comes from a
single widening stmt which we remember but throw out of the window
due to an early mismatch fixable by commutating.

I hope TYPE_VECTOR_SUBPARTS are all ordered, at least aarch64-sve.exp
is clean as it gets with a cc1 cross (it doesn't seem to find
gcc/include/stdint.h so has more compile-time errors than necessary...).

Richard, is that an OK-ish assumption?

For dumping I simply use estimated_poly_value (didn't find a
format for dump_printf_loc suitable for poly_uint64).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Will apply unless you find issues with the patch.

Thanks,
Richard.

2019-08-28  Richard Biener  

PR tree-optimization/91568
* tree-vectorizer.h (_slp_tree::max_nunits): Add.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize it.
(vect_build_slp_tree): Record max_nunits into the subtree
and merge it upwards.
(vect_print_slp_tree): Print max_nunits.

* gfortran.dg/pr91568.f: New testcase.

Index: gcc/testsuite/gfortran.dg/pr91568.f
===
--- gcc/testsuite/gfortran.dg/pr91568.f (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91568.f (working copy)
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-options "-Ofast" }
+  subroutine h3dall(z,hvec,hder,nterms)
+  complex *16 hvec(0:1),hder(0:1)
+  complex *16 z,zinv,ztmp/1.0/
+  zinv=1.0/z
+  do i=1,nterms
+ ztmp=zinv*i
+ hder(i)=hvec(i-1)-ztmp*hvec(i)
+  enddo
+  end
Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 274983)
+++ gcc/tree-vect-slp.c (working copy)
@@ -129,6 +129,7 @@ vect_create_new_slp_node (vecrefcnt = 1;
+  node->max_nunits = 1;
 
   unsigned i;
   FOR_EACH_VEC_ELT (scalar_stmts, i, stmt_info)
@@ -1051,15 +1052,24 @@ vect_build_slp_tree (vec_info *vinfo,
dump_printf_loc (MSG_NOTE, vect_location, "re-using %sSLP tree %p\n",
 *leader ? "" : "failed ", *leader);
   if (*leader)
-   (*leader)->refcnt++;
+   {
+ (*leader)->refcnt++;
+ *max_nunits = ordered_max ((*leader)->max_nunits, *max_nunits);
+   }
   return *leader;
 }
-  slp_tree res = vect_build_slp_tree_2 (vinfo, stmts, group_size, max_nunits,
+  poly_uint64 this_max_nunits = 1;
+  slp_tree res = vect_build_slp_tree_2 (vinfo, stmts, group_size,
+   &this_max_nunits,
matches, npermutes, tree_size,
max_tree_size, bst_map);
-  /* Keep a reference for the bst_map use.  */
   if (res)
-res->refcnt++;
+{
+  res->max_nunits = this_max_nunits;
+  *max_nunits = ordered_max (this_max_nunits, *max_nunits);
+  /* Keep a reference for the bst_map use.  */
+  res->refcnt++;
+}
   bst_map->put (stmts.copy (), res);
   return res;
 }
@@ -1463,9 +1473,10 @@ vect_print_slp_tree (dump_flags_t dump_k
 
   dump_metadata_t metadata (dump_kind, loc.get_impl_location ());
   dump_user_location_t user_loc = loc.get_user_location ();
-  dump_printf_loc (metadata, user_loc, "node%s %p\n",
+  dump_printf_loc (metadata, user_loc, "node%s %p (max_nunits=%u)\n",
   SLP_TREE_DEF_TYPE (node) != vect_internal_def
-  ? " (external)" : "", node);
+  ? " (external)" : "", node,
+  estimated_poly_value (node->max_nunits));
   FOR_EACH_VEC_ELT (SLP_TREE_SCALAR_STMTS (node), i, stmt_info)
 dump_printf_loc (metadata, user_loc, "\tstmt %d %G", i, stmt_info->stmt);
   if (SLP_TREE_CHILDREN (node).is_empty ())
Index: gcc/tree-vectorizer.h
===
--- gcc/tree-vectorizer.h   (revision 274983)
+++ gcc/tree-vectorizer.h   (working copy)
@@ -132,6 +132,9 @@ struct _slp_tree {
   unsigned int vec_stmts_size;
   /* Reference count in the SLP graph.  */
   unsigned int refcnt;
+  /* The maximum number of vector elements for the subtree rooted
+ at this node.  */
+  poly_uint64 max_nunits;
   /* Whether the scalar computations use two different operators.  */
   bool two_operators;
   /* The DEF type of this node.  */

Re: [PATCH V4 02/11] opt-functions.awk: fix comparison of limit, begin and end

[Jose E. Marchesi]

>  function integer_range_info(range_option, init, option)
>  {
>  if (range_option != "") {
> -   start = nth_arg(0, range_option);
> -   end = nth_arg(1, range_option);
> +   init = init + 0;
> +   start = nth_arg(0, range_option) + 0;
> +   end = nth_arg(1, range_option) + 0;
> if (init != "" && init != "-1" && (init < start || init > end))


In this case the test for init != "" is at least unnecessary.

Right! Thanks for noticing.

Maybe something else has to be used.  I didn't trace the uses but if init
is deliberately set to "" then the test would have to be replaced with init
!= 0.

Hm, in principle Init() can specify any non-negative number, including
0... what about a conservative approach that fixes the ordering problem
but leaves the "special cases" -1 and "" with exactly the same semantics
than before:

function integer_range_info(range_option, init, option)
{
if (range_option != "") {
ival = init + 0;
start = nth_arg(0, range_option) + 0;
end = nth_arg(1, range_option) + 0;
if (init != "" && init != "-1" && (ival < start || ival > end))
  print "#error initial value " init " of '" option "' must be in range 
[" start "," end "]"
return start ", " end
}
else
return "-1, -1"
}

Re: [PR 91468] Small fixes in ipa-cp.c and ipa-prop.c

[Richard Biener]

On Tue, Aug 27, 2019 at 3:15 PM Martin Jambor  wrote:
>
> Hi,
>
> Feng Xue read through much of ipa-cp.c and ipa-prop.c and reported a few
> redundancies and small errors in PR 91468.  The patch below fixes all of
> them, specifically:
>
> 1) A typo in ipcp_modif_dom_walker::before_dom_children where a wrong
>tree variable was checked if it is not a VIEW_CONVERT_EXPR.
>
> 2) update_jump_functions_after_inlining currently handles combinations
>of unary arithmetic functions and ancestor jump functions which make
>no sense, cannot happen in meaningful code, and the code path could
>conceivably be triggered only if LTO was abused to avoid
>type-casting.  In any case the handling should not be there and does
>not do anything useful (see discussion in bugzilla for more) and so
>the patch removes it.
>
> 3) compute_complex_assign_jump_func tests a few things twice, because of
>a rather mechanical cleanup of mine, so these are removed.
>
> 4) merge_agg_lats_step contains a redundant condition too, but this one
>is an important correctness invariant, so I strengthened the already
>existing checking assert afterwards to be a normal assert.
>
> Passed bootstrap and testing on x86_64-linux.  OK for trunk?

OK.

Richard.

> Thanks,
>
> Martin
>
>
> 2019-08-26  Martin Jambor  
>
> PR ipa/91468
> * ipa-cp.c (merge_agg_lats_step): Removed redundant test, made a
> checking assert a normal assert to test it really is redundant.
> * ipa-prop.c (compute_complex_assign_jump_func): Removed
> redundant test.
> (update_jump_functions_after_inlining): Removed combining unary
> arithmetic operations with an ancestor jump function.
> (ipcp_modif_dom_walker::before_dom_children): Fix wrong use of rhs
> instead of t.
> ---
>  gcc/ipa-cp.c   |  8 +++-
>  gcc/ipa-prop.c | 12 ++--
>  2 files changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 0046064fea1..33d52fe5537 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -2026,15 +2026,13 @@ merge_agg_lats_step (class ipcp_param_lattices 
> *dest_plats,
>
>if (**aglat && (**aglat)->offset == offset)
>  {
> -  if ((**aglat)->size != val_size
> - || ((**aglat)->next
> - && (**aglat)->next->offset < offset + val_size))
> +  if ((**aglat)->size != val_size)
> {
>   set_agg_lats_to_bottom (dest_plats);
>   return false;
> }
> -  gcc_checking_assert (!(**aglat)->next
> -  || (**aglat)->next->offset >= offset + val_size);
> +  gcc_assert (!(**aglat)->next
> + || (**aglat)->next->offset >= offset + val_size);
>return true;
>  }
>else
> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 1a0e12e6c0c..a23aa2590a0 100644
> --- a/gcc/ipa-prop.c
> +++ b/gcc/ipa-prop.c
> @@ -1243,9 +1243,7 @@ compute_complex_assign_jump_func (struct 
> ipa_func_body_info *fbi,
> break;
>   }
> case GIMPLE_UNARY_RHS:
> - if (is_gimple_assign (stmt)
> - && gimple_assign_rhs_class (stmt) == GIMPLE_UNARY_RHS
> - && ! CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt)))
> + if (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt)))
> ipa_set_jf_unary_pass_through (jfunc, index,
>gimple_assign_rhs_code (stmt));
> default:;
> @@ -2725,12 +2723,6 @@ update_jump_functions_after_inlining (struct 
> cgraph_edge *cs,
>   dst->value.ancestor.agg_preserved &=
> src->value.pass_through.agg_preserved;
> }
> - else if (src->type == IPA_JF_PASS_THROUGH
> -  && TREE_CODE_CLASS (src->value.pass_through.operation) == 
> tcc_unary)
> -   {
> - dst->value.ancestor.formal_id = 
> src->value.pass_through.formal_id;
> - dst->value.ancestor.agg_preserved = false;
> -   }
>   else if (src->type == IPA_JF_ANCESTOR)
> {
>   dst->value.ancestor.formal_id = src->value.ancestor.formal_id;
> @@ -4933,7 +4925,7 @@ ipcp_modif_dom_walker::before_dom_children (basic_block 
> bb)
> {
>   /* V_C_E can do things like convert an array of integers to one
>  bigger integer and similar things we do not handle below.  */
> - if (TREE_CODE (rhs) == VIEW_CONVERT_EXPR)
> + if (TREE_CODE (t) == VIEW_CONVERT_EXPR)
> {
>   vce = true;
>   break;
> --
> 2.22.0
>

Re: [PATCH V3 05/11] bpf: new GCC port

[Jose E. Marchesi]

> jemarch@termi:~/gnu/src/gcc-git/build-bpf/gcc$ PATH=.:$PATH ./xgcc -O2 -c 
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c
> during RTL pass: ira
> 
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c: 
In function ‘vq_nbest’:
> 
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c:8:1:
 internal compiler error: Segmentation fault
> 8 | }
>   | ^
> 0xfa8cb7 crash_signal
>   ../../gcc/toplev.c:326
> 0x7f278d44e05f ???
>   
/build/glibc-yWQXbR/glibc-2.24/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
> 0xd4ec8b update_costs_from_allocno
>   ../../gcc/ira-color.c:1382
> 0xd4ee09 update_costs_from_prefs
>   ../../gcc/ira-color.c:1422
> 0xd535d9 color_allocnos
>   ../../gcc/ira-color.c:3170
> 0xd53e21 color_pass
>   ../../gcc/ira-color.c:3309
> 0xd39b10 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void 
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
>   ../../gcc/ira-build.c:1781
> 0xd54703 do_coloring
>   ../../gcc/ira-color.c:3460
> 0xd58203 color
>   ../../gcc/ira-color.c:4837
> 0xd58746 ira_color()
>   ../../gcc/ira-color.c:4968
> 0xd34990 ira
>   ../../gcc/ira.c:5365
> 0xd35118 execute
>   ../../gcc/ira.c:5663
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

Yeah, this looks like a bug.  Further up we have:

  mode = ALLOCNO_MODE (allocno);
  ira_init_register_move_cost_if_necessary (mode);

which copes with the lazy initialisation.  But then we have:

  mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
  
  cost = (cp->second == allocno
  ? ira_register_move_cost[mode][rclass][aclass]
  : ira_register_move_cost[mode][aclass][rclass]);

where we can change the mode without initialising the move cost tables.
Does it work if you change it to:

  if (paradoxical_subreg_p (mode, ALLOCNO_MODE (cp->second)))
{
  mode = ALLOCNO_MODE (cp->second);
  ira_init_register_move_cost_if_necessary (mode);
}

?  The mode handling seems generally a bit weird though: we never
reset "mode" when processing the next copy, and "cp->second" might
be "allocno" itself, depending on which way round the move is.
But the above seems like an obvious change relative to the status quo.

That change fixes the segfault :)

Re: [PATCH] Sanitizing the middle-end interface to the back-end for strict alignment

[Christophe Lyon]

On Wed, 28 Aug 2019 at 11:42, Kyrill Tkachov
 wrote:
>
>
> On 8/28/19 10:38 AM, Bernd Edlinger wrote:
> > On 8/27/19 11:25 AM, Kyrill Tkachov wrote:
> >> Hi Bernd,
> >>
> >> On 8/15/19 8:47 PM, Bernd Edlinger wrote:
> >>> Hi,
> >>>
> >>> this is the split out part from the "Fix not 8-byte aligned ldrd/strd on 
> >>> ARMv5 (PR 89544)"
> >>> which is sanitizing the middle-end interface to the back-end for strict 
> >>> alignment,
> >>> and a couple of bug-fixes that are necessary to survive boot-strap.
> >>> It is intended to be applied after the PR 89544 fix.
> >>>
> >>> I think it would be possible to change the default implementation of 
> >>> STACK_SLOT_ALIGNMENT
> >>> to make all stack variables always naturally aligned instead of doing 
> >>> that only
> >>> in assign_parm_setup_stack, but would still like to avoid changing too 
> >>> many things
> >>> that do not seem to have a problem.  Since this would affect many 
> >>> targets, and more
> >>> kinds of variables that may probably not have a strict alignment problem.
> >>> But I am ready to take your advice though.
> >>>
> >>>
> >>> Boot-strapped and reg-tested on x86_64-pc-linux-gnu and 
> >>> arm-linux-gnueabihf
> >>> Is it OK for trunk?
> >> I'm not opposed to the checks but...
> >>
> >>
> >>> Thanks
> >>> Bernd.
> >>>
> >> Index: gcc/config/arm/vec-common.md
> >> ===
> >> --- gcc/config/arm/vec-common.md(Revision 274531)
> >> +++ gcc/config/arm/vec-common.md(Arbeitskopie)
> >> @@ -26,6 +26,12 @@
> >> "TARGET_NEON
> >>  || (TARGET_REALLY_IWMMXT && VALID_IWMMXT_REG_MODE (mode))"
> >>   {
> >> +  gcc_checking_assert (!MEM_P (operands[0])
> >> +   || MEM_ALIGN (operands[0])
> >> +  >= GET_MODE_ALIGNMENT (mode));
> >> +  gcc_checking_assert (!MEM_P (operands[1])
> >> +   || MEM_ALIGN (operands[1])
> >> +  >= GET_MODE_ALIGNMENT (mode));
> >> if (can_create_pseudo_p ())
> >>   {
> >> if (!REG_P (operands[0]))
> >>
> >> ... can we please factor the (!MEM_P (operands[0]) || MEM_ALIGN 
> >> (operands[0]) >= GET_MODE_ALIGNMENT (mode)) checks into a common 
> >> function and use that?
> >>
> > Sure, good idea.  How about converting it to a predicate?
> > This creates 1:1 equivalent code to the open coded assertions.
> >
> > Is it OK for trunk?
> >
> >
> > Thanks
> > Bernd.
>
>
> patch-strict-align.diff
>
> 2019-08-15  Bernd Edlinger
> Richard Biener
>
> * expr.c (expand_assignment): Handle misaligned DECLs.
> (expand_expr_real_1): Handle FUNCTION_DECL as unaligned.
> * function.c (assign_parm_adjust_stack_rtl): Check movmisalign optab
> too.
> (assign_parm_setup_stack): Allocate properly aligned stack slots.
> * varasm.c (build_constant_desc): Align constants of misaligned types.
> * config/arm/predicates.md (aligned_operand): New predicate.
> * config/arm/arm.md (movdi, movsi, movhi, movhf, movsf, movdf): Use
> sligned_operand to check restrictions on memory addresses.
>
> typo in "aligned_operand"
>
>  * config/arm/neon.md (movti, mov, mov): Likewise.
> * config/arm/vec-common.md (mov): Likewise.
>
>
> Looks good now.
>

Hi,

This patch causes an ICE when building libgcc's unwind-arm.o
when configuring GCC:
--target  arm-none-linux-gnueabihf --with-mode thumb --with-cpu
cortex-a15 --with-fpu neon-vfpv4:

The build works for the same target, but --with-mode arm --with-cpu
cortex a9 --with-fpu vfp

In file included from
/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/config/arm/unwind-arm.c:144:
/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-arm-common.inc:
In function 'get_eit_entry':
/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-arm-common.inc:245:29:
warning: cast discards 'const' qualifier from pointer target type
[-Wcast-qual]
  245 |   ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content;
  | ^
during RTL pass: expand
/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-arm-common.inc:
In function 'unwind_phase2_forced':
/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-arm-common.inc:319:18:
internal compiler error: in gen_movdi, at config/arm/arm.md:5235
  319 |   saved_vrs.core = entry_vrs->core;
  |   ~~~^
0x126530f gen_movdi(rtx_def*, rtx_def*)

/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/arm/arm.md:5235
0x896d92 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/recog.h:318
0x896d92 emit_move_insn_1(rtx_def*, rtx_def*)
/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:3694
0x897083 emit_move_insn(rtx_def*, rtx_def*)
/tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:3790
0xfc25d6 gen

Re: [PATCH] Fix PR91522

[Iain Sandoe]

> On 26 Aug 2019, at 11:06, Uros Bizjak  wrote:
> 
> On Mon, Aug 26, 2019 at 10:40 AM Richard Biener  wrote:
>> 
>> On Fri, 23 Aug 2019, Richard Biener wrote:
>> 
>>> On Fri, 23 Aug 2019, Richard Biener wrote:
>>> 
 On Fri, 23 Aug 2019, Uros Bizjak wrote:
 
> On Thu, Aug 22, 2019 at 3:35 PM Richard Biener  wrote:
>> 
>> 
>> This fixes quadraticness in STV and makes
>> 
>> machine dep reorg  :  89.07 ( 95%)   0.02 ( 18%)  89.10 (
>> 95%)  54 kB (  0%)
>> 
>> drop to zero.  Anybody remembers why it is the way it is now?
>> 
>> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
>> 
>> OK?
> 
> Looking at the PR, comment #3 [1], I assume this patch is obsoltete
> and will be updated?
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91522#c3
 
 Yes.  I'm still learning how STV operates (and learing DF and RTL...).
 The following is a rewrite of the non-TImode chain conversion
 according to I think how it should operate als allowing the hunk
 that fixes the compile-time and fixing PR91527 on the way
 (which I ran into during more extensive testing of the patch myself).
 
 So compared to the state before which I still do not 100% understand
 we now do the following.  Chain detection works as before including
 recording of all defs (both defined by the insns in the chain and
 insns outside) that need copy-in or copy-out operations.
 
 But then the patch changes things as to guarantee that
 after the conversion all uses/defs of a pseudo are
 of the (subreg:Vmode ..) form or of the original scalar form.
 In particular it avoids the need to change any insns that
 are not part of the chain (besides emitting the extra copy
 instructions).  For this all defs that were marked as needing
 copies (thus they have uses/defs both in the chain and outside)
 the chain will use a new pseudo that we copy to from scalar sources
 and that we copy from for scalar uses.  There's the new defs_map
 which records the mapping of old to new reg.  pseudos that are
 only used in the chain already are not remapped.
 
 The conversion itself then happens in two stages, first,
 in make_vector_copies, we emit the copy-in insns and
 allocate all pseudos we need.  Then the rest of the
 conversion happens fully inside of convert_insn where
 we generate the copy-outs of the insns def, replace
 defs and uses according to the mapping and replace uses
 and defs with the (subreg:Vmode ..) style.
 
 For PR91527 IRA doesn't like the REG_EQUIV note in
 
 (insn 4 24 5 2 (set (subreg:V4SI (reg/v:SI 90 [ c ]) 0)
(subreg:V4SI (reg:SI 100) 0))
 "/space/rguenther/src/svn/trunk2/gcc/testsuite/g++.dg/tree-ssa/pr21463.C":11:4
 1248 {movv4si_internal}
 (expr_list:REG_DEAD (reg:SI 100)
(expr_list:REG_EQUIV (mem/c:SI (plus:DI (reg/f:DI 16 argp)
(const_int 16 [0x10])) [1 c+0 S4 A64])
(nil
 
 because the SET_DEST is not a REG_P.  I'm not sure if this
 is invalid RTL, docs say SET_DEST might be a strict_low_part
 or a zero_extract but doesn't mention a subreg.  So I opted
 to simply remove equal/equiv notes on insns we convert
 and since the above has a REG_DEAD note I took the liberty
 to update that according to the mapping (so that would have
 been not needed before this patch) rather than dropping it.
 
 Bootstrapped with and without --with-march=westmere (to get
 some STV coverage, this included all languages) on
 x88_64-unknown-linux-gnu, testing in progress.
 
 OK if testing succeeds?
>>> 
>>> Testing revealed I made an error in general_scalar_chain::convert_insn
>>> failing to move down SET_SRC extraction below replacing with
>>> the defs map.  This showed in 4 execute FAILs in 32bit fortran
>>> testing (only).  Fixed by moving down the whole def_set/src/dst
>>> extraction.
>>> 
>>> Re-testing on x86_64-unknown-linux-gnu.
>> 
>> Bootstrapped / tested on x86_64-unknown-linux-gnu.  The "no-costmodel"
>> run runs into the latent PR91528 building 32bit libada in stage3
>> for a few sources, I've manually built those with -mno-stv and
>> bootstrap finishes successfully.  I hope HJ can help with this
>> dynamic stack-alignment issue.
>> 
>> So - OK for trunk?
>> 
>> As followup we can now remove general_remove_non_convertible_regs
>> because we can handle defs that cannot be converted just fine
>> with the patch since we're splitting live-ranges of all defs at
>> the chain boundary.
>> 
>> Thanks,
>> Richard.
>> 
>>> Updated patch below.  I'm feeling adventurous and will run
>>> the "westmere" bootstrap with costing disabled (aka always
>>> convert detected chains...).
>>> 
>>> Richard.
>>> 
>>> 2019-08-23  Richard Biener  
>>> 
>>>  PR target/91522
>>>  PR target/91527
>>>

[PR c++/90613] Fix using-decl debug bloat

[Nathan Sidwell]

My patch reorganizing using decl handling caused a regression in the 
size of debug information.  The culprit was that we were passing an 
overload set when previously we'd pass a single decl.  And that broke an 
elision test.


Fixed by moving that test into the iteration of the overload set.

Martin was kind enough to provide a reduced testcase, and I've verified 
that the debug info on one of the benchmarks reported has returned to 
what it was.


The testcase isn't in the g++.dg/debug directory, because that 
unconditionally iterates over different debug formats, and I only wanted 
to check dwarf, because I know how to do that :)


Committing to trunk.

nathan
--
Nathan Sidwell
2019-08-28  Nathan Sidwell  

	cp/
	PR c++/90613
	* name-lookup.c (cp_emit_debug_info): Check for builtins during
	overload iteration.

2019-08-16  Martin Liska  

	testsuite/
	PR c++/90613
	* g++.dg/lookup/using61.C: New.

Index: gcc/cp/name-lookup.c
===
--- gcc/cp/name-lookup.c	(revision 274930)
+++ gcc/cp/name-lookup.c	(working copy)
@@ -7456,11 +7456,4 @@ cp_emit_debug_info_for_using (tree t, tr
 return;
 
-  /* Ignore this FUNCTION_DECL if it refers to a builtin declaration
- of a builtin function.  */
-  if (TREE_CODE (t) == FUNCTION_DECL
-  && DECL_EXTERNAL (t)
-  && fndecl_built_in_p (t))
-return;
-
   /* Do not supply context to imported_module_or_decl, if
  it is a global namespace.  */
@@ -7470,16 +7463,24 @@ cp_emit_debug_info_for_using (tree t, tr
   t = MAYBE_BASELINK_FUNCTIONS (t);
 
-  /* FIXME: Handle TEMPLATE_DECLs.  */
   for (lkp_iterator iter (t); iter; ++iter)
 {
   tree fn = *iter;
-  if (TREE_CODE (fn) != TEMPLATE_DECL)
-	{
-	  if (building_stmt_list_p ())
-	add_stmt (build_stmt (input_location, USING_STMT, fn));
-	  else
-	debug_hooks->imported_module_or_decl (fn, NULL_TREE, context,
-		  false, false);
-	}
+
+  if (TREE_CODE (fn) == TEMPLATE_DECL)
+	/* FIXME: Handle TEMPLATE_DECLs.  */
+	continue;
+  
+  /* Ignore this FUNCTION_DECL if it refers to a builtin declaration
+	 of a builtin function.  */
+  if (TREE_CODE (fn) == FUNCTION_DECL
+	  && DECL_EXTERNAL (fn)
+	  && fndecl_built_in_p (fn))
+	continue;
+
+  if (building_stmt_list_p ())
+	add_stmt (build_stmt (input_location, USING_STMT, fn));
+  else
+	debug_hooks->imported_module_or_decl (fn, NULL_TREE, context,
+	  false, false);
 }
 }
Index: gcc/testsuite/g++.dg/lookup/using61.C
===
--- gcc/testsuite/g++.dg/lookup/using61.C	(revision 0)
+++ gcc/testsuite/g++.dg/lookup/using61.C	(working copy)
@@ -0,0 +1,8 @@
+// { dg-options "-gdwarf-2" }
+/* { dg-skip-if "No Dwarf" { { *-*-aix* hppa*-*-hpux* } && { ! hppa*64*-*-* } } } */
+
+extern "C" long double nanl(const char *);
+using ::nanl;
+
+// We should elide the using for this extern C builtin
+// { dg-final { scan-assembler-not ".debug_info" } }

Re: [PATCH][ARM] Cleanup logical DImode operations

[Wilco Dijkstra]

Hi Christophe,

> After this was committed (r274823), I've noticed 2 regressions on arm*:
> FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (ldrd|vldr\\.64) 20
> FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (strd|vstr\\.64) 18
> 
> Does this test still pass for you?
 
You're right, this fails for me too when I configure GCC for armv7-a or higher.
It looks like a latent issue in that the Arm backend isn't able to recombine 
separate
loads/stores into LDRD/STRD - eventhough it should really do that. There is a
workaround - I can add back the logical DImode expanders which split off all
memory operands before the DImode split (rather than the other way around).

Cheers,
Wilco

Re: [PATCH] Fix PR91568

[Richard Sandiford]

Richard Biener  writes:
> When making the SLP tree a graph I messed up and in some cases we can
> fail to propagate a higher max_nunits upwards when re-using a subtree.
> For the testcase, but only on the gcc-9-branch, this causes us to
> miss a higher value of 4 completely since it comes from a
> single widening stmt which we remember but throw out of the window
> due to an early mismatch fixable by commutating.
>
> I hope TYPE_VECTOR_SUBPARTS are all ordered, at least aarch64-sve.exp
> is clean as it gets with a cc1 cross (it doesn't seem to find
> gcc/include/stdint.h so has more compile-time errors than necessary...).
>
> Richard, is that an OK-ish assumption?

Yeah, it's probably a reasonable assumption for types and sizes
currently chosen by the target vectorisation hooks (although not
more generally).  But the existing max_nunits code goes through
vect_update_max_nunits, with the idea being to keep the assumption
in a single place.  So IMO it'd be better to split that into:

static inline void
vect_update_max_nunits (poly_uint64 *max_nunits, poly_uint64 nunits)
{
  /* All unit counts have the form current_vector_size * X for some
 rational X, so two unit sizes must have a common multiple.
 Everything is a multiple of the initial value of 1.  */
  *max_nunits = force_common_multiple (*max_nunits, nunits);
}

static inline void
vect_update_max_nunits (poly_uint64 *max_nunits, tree vectype)
{
  vect_update_max_nunits (max_nunits, TYPE_VECTOR_SUBPARTS (vectype));
}

LGTM otherwise.  The estimated_poly_value could end up being a bit
confusing when reading dumps, but I'll take that as a sign that you
don't want to add poly_* printers ;-)

Thanks,
Richard

>
> For dumping I simply use estimated_poly_value (didn't find a
> format for dump_printf_loc suitable for poly_uint64).
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Will apply unless you find issues with the patch.
>
> Thanks,
> Richard.
>
> 2019-08-28  Richard Biener  
>
>   PR tree-optimization/91568
>   * tree-vectorizer.h (_slp_tree::max_nunits): Add.
>   * tree-vect-slp.c (vect_create_new_slp_node): Initialize it.
>   (vect_build_slp_tree): Record max_nunits into the subtree
>   and merge it upwards.
>   (vect_print_slp_tree): Print max_nunits.
>
>   * gfortran.dg/pr91568.f: New testcase.
>
> Index: gcc/testsuite/gfortran.dg/pr91568.f
> ===
> --- gcc/testsuite/gfortran.dg/pr91568.f   (nonexistent)
> +++ gcc/testsuite/gfortran.dg/pr91568.f   (working copy)
> @@ -0,0 +1,11 @@
> +! { dg-do compile }
> +! { dg-options "-Ofast" }
> +  subroutine h3dall(z,hvec,hder,nterms)
> +  complex *16 hvec(0:1),hder(0:1)
> +  complex *16 z,zinv,ztmp/1.0/
> +  zinv=1.0/z
> +  do i=1,nterms
> + ztmp=zinv*i
> + hder(i)=hvec(i-1)-ztmp*hvec(i)
> +  enddo
> +  end
> Index: gcc/tree-vect-slp.c
> ===
> --- gcc/tree-vect-slp.c   (revision 274983)
> +++ gcc/tree-vect-slp.c   (working copy)
> @@ -129,6 +129,7 @@ vect_create_new_slp_node (vecSLP_TREE_TWO_OPERATORS (node) = false;
>SLP_TREE_DEF_TYPE (node) = vect_internal_def;
>node->refcnt = 1;
> +  node->max_nunits = 1;
>  
>unsigned i;
>FOR_EACH_VEC_ELT (scalar_stmts, i, stmt_info)
> @@ -1051,15 +1052,24 @@ vect_build_slp_tree (vec_info *vinfo,
>   dump_printf_loc (MSG_NOTE, vect_location, "re-using %sSLP tree %p\n",
>*leader ? "" : "failed ", *leader);
>if (*leader)
> - (*leader)->refcnt++;
> + {
> +   (*leader)->refcnt++;
> +   *max_nunits = ordered_max ((*leader)->max_nunits, *max_nunits);
> + }
>return *leader;
>  }
> -  slp_tree res = vect_build_slp_tree_2 (vinfo, stmts, group_size, max_nunits,
> +  poly_uint64 this_max_nunits = 1;
> +  slp_tree res = vect_build_slp_tree_2 (vinfo, stmts, group_size,
> + &this_max_nunits,
>   matches, npermutes, tree_size,
>   max_tree_size, bst_map);
> -  /* Keep a reference for the bst_map use.  */
>if (res)
> -res->refcnt++;
> +{
> +  res->max_nunits = this_max_nunits;
> +  *max_nunits = ordered_max (this_max_nunits, *max_nunits);
> +  /* Keep a reference for the bst_map use.  */
> +  res->refcnt++;
> +}
>bst_map->put (stmts.copy (), res);
>return res;
>  }
> @@ -1463,9 +1473,10 @@ vect_print_slp_tree (dump_flags_t dump_k
>  
>dump_metadata_t metadata (dump_kind, loc.get_impl_location ());
>dump_user_location_t user_loc = loc.get_user_location ();
> -  dump_printf_loc (metadata, user_loc, "node%s %p\n",
> +  dump_printf_loc (metadata, user_loc, "node%s %p (max_nunits=%u)\n",
>  SLP_TREE_DEF_TYPE (node) != vect_internal_def
> -? " (external)" : "", node);
> +

Re: [PATCH] Fix PR91522

[Richard Biener]

On Wed, 28 Aug 2019, Iain Sandoe wrote:

> 
> 
> 
> > On 26 Aug 2019, at 11:06, Uros Bizjak  wrote:
> > 
> > On Mon, Aug 26, 2019 at 10:40 AM Richard Biener  wrote:
> >> 
> >> On Fri, 23 Aug 2019, Richard Biener wrote:
> >> 
> >>> On Fri, 23 Aug 2019, Richard Biener wrote:
> >>> 
>  On Fri, 23 Aug 2019, Uros Bizjak wrote:
>  
> > On Thu, Aug 22, 2019 at 3:35 PM Richard Biener  
> > wrote:
> >> 
> >> 
> >> This fixes quadraticness in STV and makes
> >> 
> >> machine dep reorg  :  89.07 ( 95%)   0.02 ( 18%)  
> >> 89.10 (
> >> 95%)  54 kB (  0%)
> >> 
> >> drop to zero.  Anybody remembers why it is the way it is now?
> >> 
> >> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
> >> 
> >> OK?
> > 
> > Looking at the PR, comment #3 [1], I assume this patch is obsoltete
> > and will be updated?
> > 
> > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91522#c3
>  
>  Yes.  I'm still learning how STV operates (and learing DF and RTL...).
>  The following is a rewrite of the non-TImode chain conversion
>  according to I think how it should operate als allowing the hunk
>  that fixes the compile-time and fixing PR91527 on the way
>  (which I ran into during more extensive testing of the patch myself).
>  
>  So compared to the state before which I still do not 100% understand
>  we now do the following.  Chain detection works as before including
>  recording of all defs (both defined by the insns in the chain and
>  insns outside) that need copy-in or copy-out operations.
>  
>  But then the patch changes things as to guarantee that
>  after the conversion all uses/defs of a pseudo are
>  of the (subreg:Vmode ..) form or of the original scalar form.
>  In particular it avoids the need to change any insns that
>  are not part of the chain (besides emitting the extra copy
>  instructions).  For this all defs that were marked as needing
>  copies (thus they have uses/defs both in the chain and outside)
>  the chain will use a new pseudo that we copy to from scalar sources
>  and that we copy from for scalar uses.  There's the new defs_map
>  which records the mapping of old to new reg.  pseudos that are
>  only used in the chain already are not remapped.
>  
>  The conversion itself then happens in two stages, first,
>  in make_vector_copies, we emit the copy-in insns and
>  allocate all pseudos we need.  Then the rest of the
>  conversion happens fully inside of convert_insn where
>  we generate the copy-outs of the insns def, replace
>  defs and uses according to the mapping and replace uses
>  and defs with the (subreg:Vmode ..) style.
>  
>  For PR91527 IRA doesn't like the REG_EQUIV note in
>  
>  (insn 4 24 5 2 (set (subreg:V4SI (reg/v:SI 90 [ c ]) 0)
> (subreg:V4SI (reg:SI 100) 0))
>  "/space/rguenther/src/svn/trunk2/gcc/testsuite/g++.dg/tree-ssa/pr21463.C":11:4
>  1248 {movv4si_internal}
>  (expr_list:REG_DEAD (reg:SI 100)
> (expr_list:REG_EQUIV (mem/c:SI (plus:DI (reg/f:DI 16 argp)
> (const_int 16 [0x10])) [1 c+0 S4 A64])
> (nil
>  
>  because the SET_DEST is not a REG_P.  I'm not sure if this
>  is invalid RTL, docs say SET_DEST might be a strict_low_part
>  or a zero_extract but doesn't mention a subreg.  So I opted
>  to simply remove equal/equiv notes on insns we convert
>  and since the above has a REG_DEAD note I took the liberty
>  to update that according to the mapping (so that would have
>  been not needed before this patch) rather than dropping it.
>  
>  Bootstrapped with and without --with-march=westmere (to get
>  some STV coverage, this included all languages) on
>  x88_64-unknown-linux-gnu, testing in progress.
>  
>  OK if testing succeeds?
> >>> 
> >>> Testing revealed I made an error in general_scalar_chain::convert_insn
> >>> failing to move down SET_SRC extraction below replacing with
> >>> the defs map.  This showed in 4 execute FAILs in 32bit fortran
> >>> testing (only).  Fixed by moving down the whole def_set/src/dst
> >>> extraction.
> >>> 
> >>> Re-testing on x86_64-unknown-linux-gnu.
> >> 
> >> Bootstrapped / tested on x86_64-unknown-linux-gnu.  The "no-costmodel"
> >> run runs into the latent PR91528 building 32bit libada in stage3
> >> for a few sources, I've manually built those with -mno-stv and
> >> bootstrap finishes successfully.  I hope HJ can help with this
> >> dynamic stack-alignment issue.
> >> 
> >> So - OK for trunk?
> >> 
> >> As followup we can now remove general_remove_non_convertible_regs
> >> because we can handle defs that cannot be converted just fine
> >> with the patch since we're splitting live-ranges of all defs at
> >> the chain boundary.
> >> 
> >> Thanks,
> >> Richa

Re: [PATCH resend 1/2] PR c/65403 - Ignore -Wno-error=

[Martin Sebor]

On 8/26/19 6:24 AM, Martin Liška wrote:

On 8/23/19 6:52 PM, Alex Henrie wrote:

On Fri, Aug 23, 2019 at 3:13 AM Martin Liška  wrote:

On 8/23/19 6:17 AM, Alex Henrie wrote:

+vec ignored_wnoerror_options;


Here you'll need to add a comment.


The declaration of ignored_options in opts-global.c doesn't have a
comment either. What would you like the comment to say?


I would just write a comment for
ignored_wnoerror_options


FWIW, since the vector stores pointers it doesn't own, it might
be helpful to consider (and mention in the comment) who owns them.
I assume the strings they point to stick around for the lifetime
of the vector but that they do isn't obvious from its use, and
neither is how they are allocated (does the vector need to be
annotated with GTY?)

Martin






+  const char * opt = ignored_wnoerror_options.pop ();


No space between '*' and 'opt' please.


Okay.


You don't want to append and option that is already in the 
ignored_wnoerror_options:

$
./xgcc -B. -Wunused-variable -Werror -Wno-error=some-future-warning 
-Wno-error=some-future-warning /tmp/main2.c
/tmp/main2.c: In function ‘main’:
/tmp/main2.c:3:7: error: unused variable ‘foo’ [-Werror=unused-variable]
 3 |   int foo; /* { dg-error "unused variable 'foo'" } */
   |   ^~~
/tmp/main2.c: At top level:
cc1: error: ‘-Wno-error=some-future-warning’: no option ‘-Wsome-future-warning’ 
[-Werror]
cc1: error: ‘-Wno-error=some-future-warning’: no option ‘-Wsome-future-warning’ 
[-Werror]
cc1: all warnings being treated as errors

As seen the error is there twice.


Joseph explicitly asked me to make -Wno-error=some-future-warning
behave the same as -Wno-some-future-warning (see
), and
-Wno-some-future-warning prints multiple warnings if the option is
given multiple times.


One question about the behavior:

Why do I need to have another warning to get the warning: 
‘-Wno-error=some-future-warning’ printed?


If we always give a warning about -Wno-error=some-future-warning then
combining that option with -Werror would cause compilation to fail,
which we don't want.


Ah, I see. It's not easy to implement that in a reasonable way. Now I 
understand that.

Thanks,
Martin



-Alex

Re: [PATCH] Fix PR91522

[Uros Bizjak]

On Wed, Aug 28, 2019 at 3:54 PM Richard Biener  wrote:
> > >>> 2019-08-23  Richard Biener  
> > >>>
> > >>>  PR target/91522
> > >>>  PR target/91527
> > >>>  * config/i386/i386-features.h (general_scalar_chain::defs_map):
> > >>>  New member.
> > >>>  (general_scalar_chain::replace_with_subreg): Remove.
> > >>>  (general_scalar_chain::replace_with_subreg_in_insn): Likewise.
> > >>>  (general_scalar_chain::convert_reg): Adjust signature.
> > >>>  * config/i386/i386-features.c (scalar_chain::add_insn): Do not
> > >>>  iterate over all defs of a reg.
> > >>>  (general_scalar_chain::replace_with_subreg): Remove.
> > >>>  (general_scalar_chain::replace_with_subreg_in_insn): Likewise.
> > >>>  (general_scalar_chain::make_vector_copies): Populate defs_map,
> > >>>  place copy only after defs that are used as vectors in the chain.
> > >>>  (general_scalar_chain::convert_reg): Emit a copy for a specific
> > >>>  def in a specific instruction.
> > >>>  (general_scalar_chain::convert_op): All reg uses are converted 
> > >>> here.
> > >>>  (general_scalar_chain::convert_insn): Emit copies for scalar
> > >>>  uses of defs here.  Replace uses with the copies we created.
> > >>>  Replace and convert the def.  Adjust REG_DEAD notes, remove
> > >>>  REG_EQUIV/EQUAL notes.
> > >>>  (general_scalar_chain::convert_registers): Only handle copies
> > >>>  into the chain here.
> > >
> > > Rubberstamped with LGTM. It looks you are the master of this domain now ;)
> >
> > This  breaks bootstrap for i686-darwin (and most likely is the cause of 
> > bootstrap fail on
> > i686-linux i686-linux-gnu at 
> > https://gcc.gnu.org/ml/gcc-regression/2019-08/msg00398.html
> > et al)
> > It gives a bunch of compare errors spread around the tree - so no specific 
> > pointer there.
> >
> > There’s a secondary fail overlaying it between 274933-or so and 274980 
> > which confused
> > my initial search.
>
> Please file a bugreport.  Don't have time today to dig into but will do
> tomorrow (but now at least try to reproduce).

Looking at HJ's testreports, it looks configuring  for i686-linux
--with-fpmath=sse should be enough to trigger comparison failure.

Uros.

Re: [PATCH V4 00/11] eBPF support for GCC

[Jose E. Marchesi]

> [Differences from V3:
> . Formatting/style fixes:
>   + Remove redundant braces.
>   + Remove unneeded ATTRIBUTE_UNUSED.
>   + Truncate too long lines.
>   + Remove an odd line split.
>   + Do not break after returns.
>   + Use function_arg_info methods instead of auxiliary functions.
>   + Fix indentation in cbranchdi4.
> . Use `sorry' and sorry_at to report lack of support for valid
>   constructs.
> . Rename GR_REGS to GENERAL_REGS and exclude the pseudo arg_reg
>   from the class.

As discussed on IRC, a simple NO_REGS/ALL_REGS split should be fine,
as for VAX.  I don't think there's any reason in principle why
GENERAL_REGS mustn't include the arg pointer while ALL_REGS must.

The IRA move cost segfault looks like a simple oversight.  It'd be
interesting to know why you only see the segfault with two classes --
is there a specific reason that it can only happen there? -- but
I don't think the segfault itself should be the reason for defining
the classes as above.

On one hand, it is sort of silly to use three register classes when two
classes can, in theory, do the job.

On the other, my lazyne^Wpreservation instinct impells me to be
conservative to avoid the possibility of uncovering more bugs...

However, I realize that accomodating bugs in the common code by
modifying backend's behavior is counter-productive in the long term, for
both the backend and the common code.

Ooook, I will be a good citizen and settle in using NO_REGS/ALL_REGS.
If it is supposed to be a valid configuration, then it should work
damnit :D

Re: [PATCH V4 05/11] bpf: new GCC port

[Jose E. Marchesi]

+(define_insn "zero_extendsidi2"
+  [(set (match_operand:DI 0 "register_operand" "=r,r")
+   (zero_extend:DI
+ (match_operand:SI 1 "reg_or_memory_operand" "0,m")))]
+  ""
+  "@
+   mov32\t%0,%1
+   ldxw\t%0,%1"
+  [(set_attr "type" "alu,ldx")])

Auto review: the 0 above should be `r'.
Fixed for the next version.

[PATCH, i386]: Improve STV conversion of shifts

[Uros Bizjak]

Attached patch improves costing for STV shifts and corrects reject
condition for out of range shift count operands.

2019-08-28  Uroš Bizjak  

* config/i386/i386-features.c
(general_scalar_chain::compute_convert_gain):
Correct cost for double-word shifts.
(general_scalar_to_vector_candidate_p): Reject count operands
greater or equal to mode bitsize.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 6eb1482a9f01..766ec355e07b 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -549,11 +549,18 @@ general_scalar_chain::compute_convert_gain ()
   || GET_CODE (src) == ASHIFTRT
   || GET_CODE (src) == LSHIFTRT)
{
+ if (m == 2)
+   {
+ if (INTVAL (XEXP (src, 1)) >= 32)
+   igain += ix86_cost->add;
+ else
+   igain += ix86_cost->shift_const;
+   }
+
+ igain += ix86_cost->shift_const - ix86_cost->sse_op;
+
  if (CONST_INT_P (XEXP (src, 0)))
igain -= vector_const_cost (XEXP (src, 0));
- igain += m * ix86_cost->shift_const - ix86_cost->sse_op;
- if (INTVAL (XEXP (src, 1)) >= 32)
-   igain -= COSTS_N_INSNS (1);
}
   else if (GET_CODE (src) == PLUS
   || GET_CODE (src) == MINUS
@@ -1325,7 +1332,7 @@ general_scalar_to_vector_candidate_p (rtx_insn *insn, 
enum machine_mode mode)
 case ASHIFT:
 case LSHIFTRT:
   if (!CONST_INT_P (XEXP (src, 1))
- || !IN_RANGE (INTVAL (XEXP (src, 1)), 0, 63))
+ || !IN_RANGE (INTVAL (XEXP (src, 1)), 0, GET_MODE_BITSIZE (mode)-1))
return false;
   break;
 

Re: [PATCH] Simplify and generalize rust-demangle's unescaping logic.

[Eduard-Mihai Burtescu]

Could you, or someone else, commit this for me (as I have no commit access)?

Thanks.

On Mon, Aug 26, 2019, at 11:04 PM, Ian Lance Taylor wrote:
> On Wed, Aug 14, 2019 at 10:24 AM Eduard-Mihai Burtescu  wrote:
> >
> > Previously, rust-demangle.c was special-casing a fixed number
> > of '$uXY$' escapes, but 'XY' can technically be any hex value,
> > representing some Unicode codepoint.
> >
> > This patch adds more general support for '$u...$' escapes,
> > similar to https://github.com/alexcrichton/rustc-demangle/pull/29,
> > but only for the the ASCII subset. More complete Unicode support
> > may come at a later time, but right now I want to keep it simple.
> >
> > Escapes that decode to ASCII control codes are considered invalid,
> > as the Rust compiler should never emit them, and to avoid any
> > undesirable effects from accidentally outputting a control code.
> >
> > Additionally, the switch statements, which had one case for each
> > alphanumeric character, were replaced with if-else chains.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > 2019-08-14  Eduard-Mihai Burtescu  
> > libiberty/ChangeLog:
> > * rust-demangle.c (unescape): Remove.
> > (parse_lower_hex_nibble): New function.
> > (parse_legacy_escape): New function.
> > (is_prefixed_hash): Use parse_lower_hex_nibble.
> > (looks_like_rust): Use parse_legacy_escape.
> > (rust_demangle_sym): Use parse_legacy_escape.
> > * testsuite/rust-demangle-expected: Add 'llv$u6d$' test.
> 
> This is OK.
> 
> Thanks.
> 
> Ian
>

[PATCH] correct checking of language options (PR 80545)

[Martin Sebor]

The patch for PR 80545 I committed sometime ago in r273771 needs
an additional tweak to be fully effective.  Besides a thinko
(using a bitwise OR instead of an AND) it doesn't handle common
options.  Attached is this tweak, retested on x86_64-linux.
I will go ahead and commit it shortly.

Martin
PR driver/80545 - option -Wstringop-overflow not recognized by Fortran

gcc/ChangeLog:

	PR driver/80545
	* opts-common.c (option_enabled): Correct checking for language
	options.

Index: gcc/opts-common.c
===
--- gcc/opts-common.c	(revision 274932)
+++ gcc/opts-common.c	(working copy)
@@ -1532,7 +1532,9 @@ option_enabled (int opt_idx, unsigned lang_mask, v
 
   /* A language-specific option can only be considered enabled when it's
  valid for the current language.  */
-  if (option->flags & CL_LANG_ALL && !(option->flags | lang_mask))
+  if (!(option->flags & CL_COMMON)
+  && (option->flags & CL_LANG_ALL)
+  && !(option->flags & lang_mask))
 return 0;
 
   struct gcc_options *optsg = (struct gcc_options *) opts;

Re: [PATCH] issue consistent warning for past-the-end array stores (PR 91457)

[Martin Sebor]

With the PR 91490 subset committed, attached is what's left
of the original fix.  It seems simple enough that I decided it's
not worth chopping up any further.  The meat of the change is in
builtins.c.  Everything else just adjusts warnings either by
making use of it (tree-ssa-strlen.c) or by setting the no-warning
bit (tree-vrp.c).

Retested on x86_64-linux.

Martin
PR tree-optimization/91457 - inconsistent warning for writing past the end of an array member

gcc/ChangeLog:

	PR tree-optimization/91457
	* builtins.c (component_size): New function.
	(compute_objsize): Add argument. Handle ARRAY_REF and COMPONENT_REF.
	* builtins.h (compute_objsize): Add argument.
	* tree-ssa-strlen.c (handle_store): Handle no-warning bit.
	* tree-vrp.c (vrp_prop::check_array_ref): Return warning result.
	(vrp_prop::check_mem_ref): Same.
	(vrp_prop::search_for_addr_array): Set no-warning bit.
	(check_array_bounds): Same.

gcc/testsuite/ChangeLog:

	PR tree-optimization/91457
	* c-c++-common/Wstringop-overflow-2.c: New test.
	* g++.dg/warn/Warray-bounds-8.C: New test.
	* g++.dg/warn/Wstringop-overflow-3.C: New test.
	* gcc.dg/Wstringop-overflow-15.c: New test.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 0b25adc17a0..f8063c138a3 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -72,6 +72,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "file-prefix-map.h" /* remap_macro_filename()  */
 #include "gomp-constants.h"
 #include "omp-general.h"
+#include "tree-dfa.h"
 
 struct target_builtins default_target_builtins;
 #if SWITCHABLE_TARGET
@@ -3561,6 +3562,54 @@ check_access (tree exp, tree, tree, tree dstwrite,
   return true;
 }
 
+/* Determines the size of the member referenced by the COMPONENT_REF
+   REF, using its initializer expression if necessary in order to
+   determine the size of an initialized flexible array member.
+   Returns the size (which might be zero for an object with
+   an uninitialized flexible array member) or null if the size
+   cannot be determined.  */
+
+static tree
+component_size (tree ref)
+{
+  gcc_assert (TREE_CODE (ref) == COMPONENT_REF);
+
+  tree member = TREE_OPERAND (ref, 1);
+
+  /* If the member is not last or has a size greater than one, return
+ it.  Otherwise it's either a flexible array member or a zero-length
+ array member, or an array of length one treated as such.  */
+  tree size = DECL_SIZE_UNIT (member);
+  if (size
+  && (!array_at_struct_end_p (ref)
+	  || (!integer_zerop (size)
+	  && !integer_onep (size
+return size;
+
+  /* If the reference is to a declared object and the member a true
+ flexible array, try to determine its size from its initializer.  */
+  poly_int64 off = 0;
+  tree base = get_addr_base_and_unit_offset (ref, &off);
+  if (!base || !VAR_P (base))
+return NULL_TREE;
+
+  /* The size of any member of a declared object other than a flexible
+ array member is that obtained above.  */
+  if (size)
+return size;
+
+  if (tree init = DECL_INITIAL (base))
+if (TREE_CODE (init) == CONSTRUCTOR)
+  {
+	off <<= LOG2_BITS_PER_UNIT;
+	init = fold_ctor_reference (NULL_TREE, init, off, 0, base);
+	if (init)
+	  return TYPE_SIZE_UNIT (TREE_TYPE (init));
+  }
+
+  return DECL_EXTERNAL (base) ? NULL_TREE : integer_zero_node;
+}
+
 /* Helper to compute the size of the object referenced by the DEST
expression which must have pointer type, using Object Size type
OSTYPE (only the least significant 2 bits are used).  Return
@@ -3568,12 +3617,18 @@ check_access (tree exp, tree, tree, tree dstwrite,
the size cannot be determined.  When the referenced object involves
a non-constant offset in some range the returned value represents
the largest size given the smallest non-negative offset in the
-   range.  The function is intended for diagnostics and should not
-   be used to influence code generation or optimization.  */
+   range.  If nonnull, set *PDECL to the decl of the referenced
+   subobject if it can be determined, or to null otherwise.
+   The function is intended for diagnostics and should not be used
+   to influence code generation or optimization.  */
 
 tree
-compute_objsize (tree dest, int ostype)
+compute_objsize (tree dest, int ostype, tree *pdecl /* = NULL */)
 {
+  tree dummy = NULL_TREE;
+  if (!pdecl)
+pdecl = &dummy;
+
   unsigned HOST_WIDE_INT size;
 
   /* Only the two least significant bits are meaningful.  */
@@ -3600,7 +3655,7 @@ compute_objsize (tree dest, int ostype)
 	  tree off = gimple_assign_rhs2 (stmt);
 	  if (TREE_CODE (off) == INTEGER_CST)
 	{
-	  if (tree size = compute_objsize (dest, ostype))
+	  if (tree size = compute_objsize (dest, ostype, pdecl))
 		{
 		  wide_int wioff = wi::to_wide (off);
 		  wide_int wisiz = wi::to_wide (size);
@@ -3625,7 +3680,7 @@ compute_objsize (tree dest, int ostype)
 
 	  if (rng == VR_RANGE)
 		{
-		  if (tree size = compute_objsize (dest, ostype))
+		  if (tree size = compute_objsize (dest, os

Re: [PATCH] issue consistent warning for past-the-end array stores (PR 91457)

[Jeff Law]

On 8/28/19 9:44 AM, Martin Sebor wrote:
> With the PR 91490 subset committed, attached is what's left
> of the original fix.  It seems simple enough that I decided it's
> not worth chopping up any further.  The meat of the change is in
> builtins.c.  Everything else just adjusts warnings either by
> making use of it (tree-ssa-strlen.c) or by setting the no-warning
> bit (tree-vrp.c).
> 
> Retested on x86_64-linux.
> 
> Martin
> 
> gcc-91457.diff
> 
> PR tree-optimization/91457 - inconsistent warning for writing past the end of 
> an array member
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/91457
>   * builtins.c (component_size): New function.
>   (compute_objsize): Add argument. Handle ARRAY_REF and COMPONENT_REF.
>   * builtins.h (compute_objsize): Add argument.
>   * tree-ssa-strlen.c (handle_store): Handle no-warning bit.
>   * tree-vrp.c (vrp_prop::check_array_ref): Return warning result.
>   (vrp_prop::check_mem_ref): Same.
>   (vrp_prop::search_for_addr_array): Set no-warning bit.
>   (check_array_bounds): Same.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/91457
>   * c-c++-common/Wstringop-overflow-2.c: New test.
>   * g++.dg/warn/Warray-bounds-8.C: New test.
>   * g++.dg/warn/Wstringop-overflow-3.C: New test.
>   * gcc.dg/Wstringop-overflow-15.c: New test.
OK
jeff

Re: [PATCH V3, #1 of 10], Add basic pc-relative support

[Segher Boessenkool]

Hi Mike,

On Mon, Aug 26, 2019 at 03:54:14PM -0400, Michael Meissner wrote:
> @@ -1626,8 +1626,8 @@ (define_predicate "small_toc_ref"
>return GET_CODE (op) == UNSPEC && XINT (op, 1) == UNSPEC_TOCREL;
>  })
>  
> -;; Return true if the operand is a pc-relative address.
> -(define_predicate "pcrel_address"
> +;; Return true if the operand is a pc-relative address to a local label.
> +(define_predicate "pcrel_local_address"
>(match_code "label_ref,symbol_ref,const")

Not just to a local label?  Please fix the comment.

> -(define_predicate "pcrel_external_address"
> +(define_predicate "pcrel_ext_address"

That is a much worse name.  "ext" can mean "extended" or many more things.

Having good names for these very basic things is important.  The names
shape the concepts, how you think about the code.

> +/* Enumeration giving the type of traditional addressing that would be used 
> to
> +   decide whether an instruction uses prefixed memory or not.  If the
> +   traditional instruction uses the DS instruction format, and the bottom 2
> +   bits of the offset are not 0, the traditional instruction cannot be used,
> +   but a prefixed instruction can be used.  */

"Traditional" is a bad word for documentation.  What you mean is what was
supported before.  Before you know it "new" will be old as well.

What you mean is non-prefixed addressing?  Please say so, then.

(And it is "form", not "format", in all the insn descriptions etc...
Like "D-form".  Please use the same.)

> -#define RELOAD_REG_VALID 0x01/* Mode valid in register..  */
> -#define RELOAD_REG_MULTIPLE  0x02/* Mode takes multiple registers.  */
> -#define RELOAD_REG_INDEXED   0x04/* Reg+reg addressing.  */
> -#define RELOAD_REG_OFFSET0x08/* Reg+offset addressing. */
> -#define RELOAD_REG_PRE_INCDEC0x10/* PRE_INC/PRE_DEC valid.  */
> -#define RELOAD_REG_PRE_MODIFY0x20/* PRE_MODIFY valid.  */
> -#define RELOAD_REG_AND_M16   0x40/* AND -16 addressing.  */
> -#define RELOAD_REG_QUAD_OFFSET   0x80/* quad offset is limited.  */
> +#define RELOAD_REG_VALID 0x001   /* Mode valid in register..  */
> +#define RELOAD_REG_MULTIPLE  0x002   /* Mode takes multiple registers.  */
> +#define RELOAD_REG_INDEXED   0x004   /* Reg+reg addressing.  */
> +#define RELOAD_REG_OFFSET0x008   /* Reg+offset addressing. */
> +#define RELOAD_REG_PRE_INCDEC0x010   /* PRE_INC/PRE_DEC valid.  */
> +#define RELOAD_REG_PRE_MODIFY0x020   /* PRE_MODIFY valid.  */
> +#define RELOAD_REG_AND_M16   0x040   /* AND -16 addressing.  */
> +#define RELOAD_REG_QUAD_OFFSET   0x080   /* DQ offset (bottom 4 bits 0). 
>  */
> +#define RELOAD_REG_DS_OFFSET 0x100   /* DS offset (bottom 2 bits 0).  */

As explained before, do not do this.  Do not use 3-digit hex numbers; don't
change existing definitions for no reason, not in the middle of an unrelated
patch, either.

> @@ -370,6 +369,8 @@ struct rs6000_reg_addr {

Can you fix this struct / arrays / whatever, instead of adding more to it?

>enum insn_code reload_gpr_vsx; /* INSN to move from GPR to VSX.  */
>enum insn_code reload_vsx_gpr; /* INSN to move from VSX to GPR.  */
>addr_mask_type addr_mask[(int)N_RELOAD_REG]; /* Valid address masks.  */
> +  addr_mask_type any_addr_mask;  /* OR of GPR/FPR/VMX 
> addr_masks.  */
> +  addr_mask_type default_addr_mask;  /* Default addr_mask to use.  */

And these "address masks" are bitmaps of random flags, one for each
"register class" (which is not related to the core GCC concept of "register
class", and the bits are called "RELOAD_REG_*" although this isn't for
reload at all?


Don't pile new stuff on without cleaning up the old stuff first.


> +   /* 64-bit and larger values on GPRs need DS format instructions.  All

"Need"...  Well you want to use ld insns, please just say that?

> +  non-vector offset instructions in Altivec registers need the DS
> +  format instructions.  */

And this is talking about lxsd / lxssp?

> +   const addr_mask_type quad_flags = (RELOAD_REG_OFFSET
> +  | RELOAD_REG_QUAD_OFFSET);
> +
> +   if ((addr_mask & quad_flags) == RELOAD_REG_OFFSET
> +   && ((rc == RELOAD_REG_GPR && msize >= 8 && TARGET_POWERPC64)
> +   || (rc == RELOAD_REG_VMX)))
> + addr_mask |= RELOAD_REG_DS_OFFSET;
> +
> reg_addr[m].addr_mask[rc] = addr_mask;
> -   any_addr_mask |= addr_mask;
> +   any_addr_mask |= (addr_mask & ~RELOAD_REG_AND_M16);

Why do you need this last line?  Why was that flag set at all?  What does
"any mask" mean if it is not?

> +  /* Figure out what the default reload register set that should be used
> +  for each mode,

"Figure out what register set should be used by default for each mode"?

And what does reload have to do with it?

> that should mirror the expected usage (i.e. vectors in
> +  vector registers, ints in GPRs, etc).  Fall back t

Re: [PR c++/90613] Fix using-decl debug bloat

[Jason Merrill]

On Wed, Aug 28, 2019 at 9:35 AM Nathan Sidwell  wrote:
>
> My patch reorganizing using decl handling caused a regression in the
> size of debug information.  The culprit was that we were passing an
> overload set when previously we'd pass a single decl.  And that broke an
> elision test.
>
> Fixed by moving that test into the iteration of the overload set.
>
> Martin was kind enough to provide a reduced testcase, and I've verified
> that the debug info on one of the benchmarks reported has returned to
> what it was.
>
> The testcase isn't in the g++.dg/debug directory, because that
> unconditionally iterates over different debug formats, and I only wanted
> to check dwarf, because I know how to do that :)

FYI there is the g++.dg/debug/dwarf2 directory for dwarf tests.

Jason

Go patch committed: Provide index information on bounds check failure

[Ian Lance Taylor]

This patch to the Go frontend and libgo changes the panic message
reported for an out of bounds index or slice operation to include the
invalid values.  This makes it easier for the user to see what the
problem is.  This implements https://golang.org/cl/161477 in the
gofrontend, for https://golang.org/issue/30116.  Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Unfortunately, GMail has once again blocked the patch attachment.  So
if you want to see the patch, see
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=274998 .

Ian

[Preprocessor] small cleanups

[Nathan Sidwell]

From the modules branch, here are some cleanups inspired by changes 
I've made there.


1) directive handling gets a bool arg, not a 0/1 int
2) documented the enumerators of an enum
3) make a bunch of structure flags 1-bit bools.

applying to trunk.

nathan

--
Nathan Sidwell
2019-08-28  Nathan Sidwell  

	* directives-only.c (_cpp_preprocess_dir_only): Use false, not
	zero for _cpp_handle_directive call.
	* directives.c (_cpp_handle_directive): Indented is bool.
	* files.c (struct _cpp_file): Make bools 1 bit bitfields.
	* internal.h (enum include_type): Reformat and comment.
	(struct cpp_buffer): Make flags 1 bit bitfields.
	(_cpp_handle_directive): Indented is bool.

Index: libcpp/directives-only.c
===
--- libcpp/directives-only.c	(revision 274992)
+++ libcpp/directives-only.c	(working copy)
@@ -102,5 +102,5 @@ _cpp_preprocess_dir_only (cpp_reader *pf
 	buffer->line_base -= col - 1;
 
-	_cpp_handle_directive (pfile, 0 /* ignore indented */);
+	_cpp_handle_directive (pfile, false /* ignore indented */);
 
 	/* Sanitize the line settings.  Duplicate #include's can mess
Index: libcpp/directives.c
===
--- libcpp/directives.c	(revision 274992)
+++ libcpp/directives.c	(working copy)
@@ -407,5 +407,5 @@ directive_diagnostics (cpp_reader *pfile
 }
 
-/* Check if we have a known directive.  INDENTED is nonzero if the
+/* Check if we have a known directive.  INDENTED is true if the
'#' of the directive was indented.  This function is in this file
to save unnecessarily exporting dtable etc. to lex.c.  Returns
@@ -413,5 +413,5 @@ directive_diagnostics (cpp_reader *pfile
continue processing the line.  */
 int
-_cpp_handle_directive (cpp_reader *pfile, int indented)
+_cpp_handle_directive (cpp_reader *pfile, bool indented)
 {
   const directive *dir = 0;
Index: libcpp/files.c
===
--- libcpp/files.c	(revision 274992)
+++ libcpp/files.c	(working copy)
@@ -99,17 +99,17 @@ struct _cpp_file
 
   /* If opened with #import or contains #pragma once.  */
-  bool once_only;
+  bool once_only : 1;
 
   /* If read() failed before.  */
-  bool dont_read;
+  bool dont_read : 1;
 
   /* If this file is the main file.  */
-  bool main_file;
+  bool main_file : 1;
 
   /* If BUFFER above contains the true contents of the file.  */
-  bool buffer_valid;
+  bool buffer_valid : 1;
 
   /* If this file is implicitly preincluded.  */
-  bool implicit_preinclude;
+  bool implicit_preinclude : 1;
 };
 
Index: libcpp/internal.h
===
--- libcpp/internal.h	(revision 274992)
+++ libcpp/internal.h	(working copy)
@@ -114,5 +114,15 @@ extern unsigned char *_cpp_unaligned_all
 
 /* #include types.  */
-enum include_type {IT_INCLUDE, IT_INCLUDE_NEXT, IT_IMPORT, IT_CMDLINE, IT_DEFAULT};
+enum include_type
+  {
+   /* Directive-based including mechanisms.  */
+   IT_INCLUDE,  /* #include */
+   IT_INCLUDE_NEXT,  /* #include_next */
+   IT_IMPORT,   /* #import  */
+
+   /* Non-directive including mechanisms.  */
+   IT_CMDLINE,  /* -include */
+   IT_DEFAULT,  /* forced header  */
+  };
 
 union utoken
@@ -328,5 +338,5 @@ struct cpp_buffer
 
   /* True if we need to get the next clean line.  */
-  bool need_line;
+  bool need_line : 1;
 
   /* True if we have already warned about C++ comments in this file.
@@ -334,15 +344,15 @@ struct cpp_buffer
  or for -Wtraditional, and only once per file (otherwise it would
  be far too noisy).  */
-  unsigned int warned_cplusplus_comments : 1;
+  bool warned_cplusplus_comments : 1;
 
   /* True if we don't process trigraphs and escaped newlines.  True
  for preprocessed input, command line directives, and _Pragma
  buffers.  */
-  unsigned int from_stage3 : 1;
+  bool from_stage3 : 1;
 
   /* At EOF, a buffer is automatically popped.  If RETURN_AT_EOF is
  true, a CPP_EOF token is then returned.  Otherwise, the next
  token from the enclosing buffer is returned.  */
-  unsigned int return_at_eof : 1;
+  bool return_at_eof : 1;
 
   /* One for a system header, two for a C system header file that therefore
@@ -420,5 +430,5 @@ struct cpp_reader
   /* This is the node representing the macro being expanded at
  top-level.  The value of this data member is valid iff
- in_macro_expansion_p() returns TRUE.  */
+ cpp_in_macro_expansion_p() returns TRUE.  */
   cpp_hashnode *top_most_macro_node;
 
@@ -426,5 +436,5 @@ struct cpp_reader
  really expanding a macro, the function macro_of_context returns
  the macro being expanded and this flag is set to false.  Client
- code should use the function in_macro_expansion_p to know if we
+ code should use the function cpp_in_macro_expansion_p to know if we
  are either about to expand a macro, or are actually expanding
  one.  */
@@ -712,5 +722,5

Go patch committed: Handle unsafe conversions in escape analysis

[Ian Lance Taylor]

This patch to the Go frontend by Cherry Zhang handles unsafe
conversion expression in escape analysis.  Previously escape analysis
never saw these, but now it does for the case of a map assignment.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 274998)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-189ff44b2c26f29f41f0eb159e0d8f3fa508ecae
+5d15923ada640befb236d5fe94f0c724e98e99d7
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/escape.cc
===
--- gcc/go/gofrontend/escape.cc (revision 274169)
+++ gcc/go/gofrontend/escape.cc (working copy)
@@ -1706,6 +1706,15 @@ Escape_analysis_assign::expression(Expre
   }
   break;
 
+case Expression::EXPRESSION_UNSAFE_CONVERSION:
+  {
+Unsafe_type_conversion_expression* uce =
+  (*pexpr)->unsafe_conversion_expression();
+Node* expr_node = Node::make_node(uce->expr());
+this->assign(n, expr_node);
+  }
+  break;
+
 case Expression::EXPRESSION_FIXED_ARRAY_CONSTRUCTION:
 case Expression::EXPRESSION_SLICE_CONSTRUCTION:
   {

Re: [PR fortran/91496] !GCC$ directives error if mistyped or unknown

[Bernhard Reutner-Fischer]

On Tue, 27 Aug 2019 21:49:38 +0200
Harald Anlauf  wrote:

> Committed to trunk as svn revision 274966, after removing some
> accidentally left-over unused variable declarations (copy&paste).
> The actual committed version is attached.
> 
> Thanks, Paul, for the quick review!
> 
> Unless there are strong objections, I'd like to commit this to
> 9-branch, too, so that this can be used in the 9.3 release.
> Applies/regtests cleanly.  Will wait for a week or so.

I see that you copied the unfortunate error-message "commence a loop"
and i see that i completely forgot to adjust it as per Mike's
preference in
 https://gcc.gnu.org/ml/fortran/2015-05/msg00166.html

So can you please change your new errors (and the unroll error message
too) to something like the suggested
"directive not at the start of a loop at %C" please?

Many thanks in advance!
PS: This is border obvious, i'd send the patch for review anyway,
maybe a native speaker can provide a better wording.
PPS: I'm still a bit unhappy about the following kludges in unroll even
more so since you copied the concept:
(1) The globals to diagnose misplaced directives are very ugly.
(2) putting the payload into gfc_iterator is ugly, too. I don't
remember offhand how ugly or intrusive it would be to provide means for
passing down an additional optional structure to act as sink for the
directive payload data. Putting those into the iterator is AFAIR not
all that clean. Maybe you could have a look if you can extend this area
to look less clumsy? "hinted_iterator" maybe, or maybe the iterator is
seldomly used anyway and hence we don't care?

thanks and cheers,

> 
> Harald
> 
> On 08/27/19 10:33, Paul Richard Thomas wrote:
> > Hi Harald,
> >
> > This is OK for trunk.
> >
> > Thanks!
> >
> > Paul
> >
> > On Mon, 26 Aug 2019 at 22:13, Harald Anlauf  wrote:  
> >>
> >> Dear all,
> >>
> >> the attached patch adds Fortran support for the following pragmas
> >> (loop annotations): IVDEP (ignore vector dependencies), VECTOR, and
> >> NOVECTOR.  Furthermore, it downgrades unsupported directives from
> >> error to warning (by default, it stays an error with -pedantic),
> >> thus fixing the PR.
> >>
> >> It has no effect on existing code (thus regtested cleanly on
> >> x86_64-pc-linux-gnu), but gives users an option for fine-grained
> >> control of optimization.  The above pragmas are supported by other
> >> compilers (with different sentinels, e.g. !DIR$ for Intel, Cray,
> >> sometimes with slightly different keywords).
> >>
> >> OK for trunk, and backport to 9?
> >>
> >> Thanks,
> >> Harald
> >>
> >>
> >> 2019-08-26  Harald Anlauf  
> >>
> >> PR fortran/91496
> >> * gfortran.h: Extend struct gfc_iterator for loop annotations.
> >> * array.c (gfc_copy_iterator): Copy loop annotations by IVDEP,
> >> VECTOR, and NOVECTOR pragmas.
> >> * decl.c (gfc_match_gcc_ivdep, gfc_match_gcc_vector)
> >> (gfc_match_gcc_novector): New matcher functions handling IVDEP,
> >> VECTOR, and NOVECTOR pragmas.
> >> * match.h: Declare prototypes of matcher functions handling IVDEP,
> >> VECTOR, and NOVECTOR pragmas.
> >> * parse.c (decode_gcc_attribute, parse_do_block)
> >> (parse_executable): Decode IVDEP, VECTOR, and NOVECTOR pragmas;
> >> emit warning for unrecognized pragmas instead of error.
> >> * trans-stmt.c (gfc_trans_simple_do, gfc_trans_do): Add code to
> >> emit annotations for IVDEP, VECTOR, and NOVECTOR pragmas.
> >> * gfortran.texi: Document IVDEP, VECTOR, and NOVECTOR pragmas.
> >>
> >> 2019-08-26  Harald Anlauf  
> >>
> >> PR fortran/91496
> >> * gfortran.dg/pr91496.f90: New testcase.
> >>  
> >
> >  
> 

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Bernhard Reutner-Fischer]

On Fri, 23 Aug 2019 17:17:37 -0700
Andrew Benson  wrote:

> This PR is still open - I re-tested the patch on the current trunk. The patch 
> still applies with some line offsets (I've attached the updated patch) and 
> regtests cleanly. It would be very helpful to me to get this patch committed 
> if possible.

I think Jerry ACKed the patch back then. I'll try to find the time to
commit it maybe during one of the coming weekends unless someone else
beats me to it..

Thanks for the reminder!
Bernhard
> 
> Thanks,
> Andrew
> 
> On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer 
> wrote:
> > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle  wrote:  
> > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote:  
> > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson 
> > > >
> wrote:
> > > >> As suggested by Janus, PR87103 is easily fixed by the attached patch
> > > >> which
> > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum
> > > >> allowed F08 symbol length of 63, plus a null terminator, plus the
> > > >> "__tmp_class_" prefix).> >   
> > > > This is so much wrong.
> > > > Note that this will be fixed properly by the changes contained in the
> > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/fortran
> > > > -fe-stringpool branch.
> > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an internal
> > > > buffer double that size which in turn is sufficient to hold all
> > > > compiler-generated identifiers.
> > > > See gfc_get_string() even in current TOT.
> > > > 
> > > > Maybe we should bite the bullet and start to merge the stringpool
> > > > changes now instead of this hack?  
> > > 
> > > It all makes sense to me, please proceed. (my 2 cents worth)  
> > 
> > Ok so i will reread the fortran-fe-stringpool series and submit it
> > here for review.
> > 
> > Let's return to the issue at hand for a moment, though.
> > I tested the attached alternate fix on top of the
> > fortran-fe-stringpool branch where it fixes PR87103.
> > Maybe somebody has spare cycles to test it on top of current trunk?
> > 
> > thanks,
> > 
> > [PATCH,FORTRAN] PR87103: Remove max symbol length check from gfc_new_symbol
> > 
> > gfc_match_name does check for too long names already. Since
> > gfc_new_symbol is also called for symbols with internal names containing
> > compiler-generated prefixes, these internal names can easily exceed the
> > max_identifier_length mandated by the standard.
> > 
> > gcc/fortran/ChangeLog
> > 
> > 2018-09-04  Bernhard Reutner-Fischer  
> > 
> > PR fortran/87103
> > * expr.c (gfc_check_conformance): Check vsnprintf for truncation.
> > * iresolve.c (gfc_get_string): Likewise.
> > * symbol.c (gfc_new_symbol): Remove check for maximum symbol
> > name length.  Remove redundant 0 setting of new calloc()ed
> > gfc_symbol.  
> 
> 

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Andrew Benson]

Thanks Bernhard.

On Wednesday, August 28, 2019 9:00:36 PM PDT Bernhard Reutner-Fischer wrote:
> On Fri, 23 Aug 2019 17:17:37 -0700
> 
> Andrew Benson  wrote:
> > This PR is still open - I re-tested the patch on the current trunk. The
> > patch still applies with some line offsets (I've attached the updated
> > patch) and regtests cleanly. It would be very helpful to me to get this
> > patch committed if possible.
> 
> I think Jerry ACKed the patch back then. I'll try to find the time to
> commit it maybe during one of the coming weekends unless someone else
> beats me to it..
> 
> Thanks for the reminder!
> Bernhard
> 
> > Thanks,
> > Andrew
> > 
> > On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer
> > 
> > wrote:
> > > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle  
wrote:
> > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote:
> > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson
> > > > > 
> > 
> > wrote:
> > > > >> As suggested by Janus, PR87103 is easily fixed by the attached
> > > > >> patch
> > > > >> which
> > > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum
> > > > >> allowed F08 symbol length of 63, plus a null terminator, plus the
> > > > >> "__tmp_class_" prefix).> >
> > > > > 
> > > > > This is so much wrong.
> > > > > Note that this will be fixed properly by the changes contained in
> > > > > the
> > > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/for
> > > > > tran
> > > > > -fe-stringpool branch.
> > > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an
> > > > > internal
> > > > > buffer double that size which in turn is sufficient to hold all
> > > > > compiler-generated identifiers.
> > > > > See gfc_get_string() even in current TOT.
> > > > > 
> > > > > Maybe we should bite the bullet and start to merge the stringpool
> > > > > changes now instead of this hack?
> > > > 
> > > > It all makes sense to me, please proceed. (my 2 cents worth)
> > > 
> > > Ok so i will reread the fortran-fe-stringpool series and submit it
> > > here for review.
> > > 
> > > Let's return to the issue at hand for a moment, though.
> > > I tested the attached alternate fix on top of the
> > > fortran-fe-stringpool branch where it fixes PR87103.
> > > Maybe somebody has spare cycles to test it on top of current trunk?
> > > 
> > > thanks,
> > > 
> > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from
> > > gfc_new_symbol
> > > 
> > > gfc_match_name does check for too long names already. Since
> > > gfc_new_symbol is also called for symbols with internal names containing
> > > compiler-generated prefixes, these internal names can easily exceed the
> > > max_identifier_length mandated by the standard.
> > > 
> > > gcc/fortran/ChangeLog
> > > 
> > > 2018-09-04  Bernhard Reutner-Fischer  
> > > 
> > > PR fortran/87103
> > > * expr.c (gfc_check_conformance): Check vsnprintf for truncation.
> > > * iresolve.c (gfc_get_string): Likewise.
> > > * symbol.c (gfc_new_symbol): Remove check for maximum symbol
> > > name length.  Remove redundant 0 setting of new calloc()ed
> > > gfc_symbol.


-- 

* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html

* Galacticus: https://bitbucket.org/galacticusdev/galacticus

[PATCH] Use cxx_printable_name for __PRETTY_FUNCTION__ in cp_fname_init.

[Martin Liška]

Hi.

The patch restores behavior before r265711 where we used
cxx_printable_name for __PRETTY_FUNCTION__.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/c-family/ChangeLog:

2019-08-27  Martin Liska  

PR c++/91155
* c-common.c (fname_as_string): Use cxx_printable_name for
__PRETTY_FUNCTION__ same as was used before r265711.

gcc/testsuite/ChangeLog:

2019-08-27  Martin Liska  

PR c++/91155
* g++.dg/torture/pr91155.C: New test.
---
 gcc/cp/decl.c  | 17 -
 gcc/testsuite/g++.dg/torture/pr91155.C | 18 ++
 2 files changed, 30 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/torture/pr91155.C


diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 847817029e4..3ba019afcbf 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4511,15 +4511,22 @@ cp_fname_init (const char* name, tree *type_p)
 static tree
 cp_make_fname_decl (location_t loc, tree id, int type_dep)
 {
-  const char *const name = (type_dep && in_template_function ()
-			? NULL : fname_as_string (type_dep));
+  const char * name = NULL;
+  if (!(type_dep && in_template_function ()))
+{
+  if (current_function_decl == NULL_TREE)
+	name = "top level";
+  else if (type_dep == 1) /* __PRETTY_FUNCTION__ */
+	name = cxx_printable_name (current_function_decl, 2);
+  else if (type_dep == 0) /* __FUNCTION__ */
+	name = fname_as_string (type_dep);
+  else
+	gcc_unreachable ();
+}
   tree type;
   tree init = cp_fname_init (name, &type);
   tree decl = build_decl (loc, VAR_DECL, id, type);
 
-  if (name)
-free (CONST_CAST (char *, name));
-
   /* As we're using pushdecl_with_scope, we must set the context.  */
   DECL_CONTEXT (decl) = current_function_decl;
 
diff --git a/gcc/testsuite/g++.dg/torture/pr91155.C b/gcc/testsuite/g++.dg/torture/pr91155.C
new file mode 100644
index 000..04e4f7ab41b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr91155.C
@@ -0,0 +1,18 @@
+/* PR c++/91155.  */
+
+template< char C > struct dummy {};
+
+template< typename T > const char *test()
+{
+  __builtin_printf ("test: %s\n", __PRETTY_FUNCTION__);
+  return __PRETTY_FUNCTION__;
+}
+
+int main()
+{
+if (__builtin_strcmp ("const char* test() [with T = dummy<\'\\000\'>]", test< dummy< '\0' > > ()) != 0)
+{};//  __builtin_abort ();
+if (__builtin_strcmp ("const char* test() [with T = dummy<\'\\\'\'>]", test< dummy< '\'' > > ()) != 0)
+{};//  __builtin_abort ();
+return 0;
+}

[PATCH][OBVIOUS] Add .clangd and compile_commands.json to .gitignore.

[Martin Liška]

Hi.

These 2 files are used for clangd.

I'm going to install the patch.
Martin

ChangeLog:

2019-08-28  Martin Liska  

* .gitignore: Add .clangd and compile_commands.json
to .gitignore.
---
 .gitignore | 2 ++
 1 file changed, 2 insertions(+)


diff --git a/.gitignore b/.gitignore
index b53f60db792..d9d3967a12c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,8 @@ TAGS.sub
 .lvimrc
 
 .clang-format
+.clangd
+compile_commands.json
 
 .gdbinit
 .gdb_history

Re: [PR fortran/91496] !GCC$ directives error if mistyped or unknown

[Harald Anlauf]

Hi Bernhard,

On 08/28/19 20:57, Bernhard Reutner-Fischer wrote:
> I see that you copied the unfortunate error-message "commence a loop"
> and i see that i completely forgot to adjust it as per Mike's
> preference in
>  https://gcc.gnu.org/ml/fortran/2015-05/msg00166.html
>
> So can you please change your new errors (and the unroll error message
> too) to something like the suggested
> "directive not at the start of a loop at %C" please?
>
> Many thanks in advance!
> PS: This is border obvious, i'd send the patch for review anyway,
> maybe a native speaker can provide a better wording.

see attachment and below for Changelog.  Regtested OK.

I have opted for the variant "directive not at the start of a loop",
which is what Mike preferred, and what matches the current capabilities.

Is that OK?

> PPS: I'm still a bit unhappy about the following kludges in unroll even
> more so since you copied the concept:
> (1) The globals to diagnose misplaced directives are very ugly.
> (2) putting the payload into gfc_iterator is ugly, too. I don't
> remember offhand how ugly or intrusive it would be to provide means for
> passing down an additional optional structure to act as sink for the
> directive payload data. Putting those into the iterator is AFAIR not
> all that clean. Maybe you could have a look if you can extend this area
> to look less clumsy? "hinted_iterator" maybe, or maybe the iterator is
> seldomly used anyway and hence we don't care?

Could you please open a new PR for this?

There are many things that could be improved in this context.
There is a lot that could be learned from e.g. the Cray or NEC
compilers, where you can explicitly control loop fusion, loop
blocking, which are very important in (my) practice.

The current implementation also does not support array notation,
which I consider a major limitation.  I'll have to learn how this
could be done.

> thanks and cheers,
>

Thanks for the feedback!

Harald

2019-08-28  Harald Anlauf  

PR fortran/91496
* parse.c (parse_executable): Improve error messages for
improperly placed pragmas not preceeding a loop.

2019-08-28  Harald Anlauf  

PR fortran/91496
* gfortran.dg/directive_unroll_5.f90: Adjust error message.

Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 274998)
+++ gcc/fortran/parse.c (working copy)
@@ -5454,16 +5454,17 @@
}

   if (directive_unroll != -1)
-   gfc_error ("% directive does not commence a loop at %C");
+   gfc_error ("% directive not at the start of a loop at %C");

   if (directive_ivdep)
-   gfc_error ("% directive does not commence a loop at %C");
+   gfc_error ("% directive not at the start of a loop at %C");

   if (directive_vector)
-   gfc_error ("% directive does not commence a loop at %C");
+   gfc_error ("% directive not at the start of a loop at %C");

   if (directive_novector)
-   gfc_error ("% directive does not commence a loop at %C");
+   gfc_error ("% "
+  "directive not at the start of a loop at %C");

   st = next_statement ();
 }
Index: gcc/testsuite/gfortran.dg/directive_unroll_5.f90
===
--- gcc/testsuite/gfortran.dg/directive_unroll_5.f90(revision 274998)
+++ gcc/testsuite/gfortran.dg/directive_unroll_5.f90(working copy)
@@ -31,7 +31,7 @@
   integer :: a(n), b(n)
   integer (kind=4) :: i
 !GCC$ unroll 8
-  write (*,*) "wrong"! { dg-error "directive does not commence a loop" }
+  write (*,*) "wrong"! { dg-error "directive not at the start of a loop" }
   DO i=n, 1, -1
 call dummy2(a(i), b(i), i)
   ENDDO

Re: C++ PATCH for P1152R4: Deprecating some uses of volatile (PR c++/91361)

[Jason Merrill]

On 8/26/19 1:46 PM, Marek Polacek wrote:

On Fri, Aug 23, 2019 at 07:39:57PM -0400, Marek Polacek wrote:

On Fri, Aug 23, 2019 at 02:43:42PM -0700, Jason Merrill wrote:

On 8/23/19 9:32 AM, Marek Polacek wrote:

This patch implements another C++20 feature, partially deprecating volatile.
You can read the proposal here: .  I encourage
interested people to read the background in  which
provides a lot of interesting volatile-related information.

Note that P1152R4 differs slightly from what's now in the standard: the mention
of "non-class type" was dropped.  (Assignment to objects of a class type is
defined by the copy/move assignment operator.)

The gist is that expressions that involve both load and store of a volatile
lvalue, such as ++ or += are deprecated, as are volatile-qualified parameter
and return types.  Chained assignments of the form "a = b = c" are also
deprecated because there's some confusion as to if 'b' is re-read before storing
the value to 'a' (GCC claims not to do it).  See Annex D [depr.volatile.type].

[expr.ass] further says that "A simple assignment whose left operand is of
a volatile-qualified type is deprecated unless the assignment is either
a discarded-value expression or appears in an unevaluated context."
and therein lies the rub.  When parsing/building the MODIFY_EXPR, we don't know
if the assignment's value is going to be discared.  We only know that after
mark_discarded_use has run, which for expression-statements takes place in
finish_expr_stmt -> conver_to_void, and that is quite late.


It wouldn't work to warn in mark_[lr]value_use?


My worry is that we might be calling those too often and generate redundant
diagnostics but I'll have to play with that a bit before I can say for sure.


So indeed we call mark_use multiple times on the same expr, but that is not an
unsurmountable problem, I just need to use TREE_THIS_VOLATILE to prevent that.
FWIW, using TREE_NO_WARNING didn't work for

   &(vi = i);

because finish_parenthesized_expr sets TREE_NO_WARNING and so we wouldn't warn
at all.  But warning in mark_use did simplify things a bit, thanks for the
suggestion.

One nit is that we emit two warnings for

   vi = vi += 10;

which could be fixed but I'm not entirely sure it's even worth it.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2019-08-26  Marek Polacek  

Implement P1152R4: Deprecating some uses of volatile.
PR c++/91361
* c-opts.c (c_common_post_options): Enable -Wvolatile by
default for C++2a, unless -Wno-deprecated.
* c.opt (Wvolatile): New warning.

* cp-gimplify.c (cp_fold): Set TREE_THIS_VOLATILE.
* decl.c (grokdeclarator): Warn about a volatile-qualified structured
binding and return type.
(grokparms): Warn about a volatile-qualified function parameter.
* expr.c (mark_use) : Emit a -Wvolatile warning.
* typeck.c (cp_build_unary_op): Emit a -Wvolatile warning for pre and
post ++/-- on a volatile operand.
(genericize_compound_lvalue): Use a better location.  Don't lose
TREE_THIS_VOLATILE.
(cp_build_modify_expr): Emit a -Wvolatile warning for a compound
assignment whose LHS is volatile-qualified.  Build the assignment with
a more precise location.

* doc/invoke.texi: Document -Wvolatile.

* c-c++-common/Wbool-operation-1.c: Use -Wno-volatile in C++.
* c-c++-common/gomp/atomic-1.c: Likewise.
* c-c++-common/gomp/atomic-9.c: Likewise.
* c-c++-common/gomp/depend-iterator-1.c: Likewise.
* c-c++-common/gomp/loop-1.c: Adjust warning location for C++.
* c-c++-common/gomp/order-3.c: Likewise.
* c-c++-common/pr69733.c: Use -Wno-volatile in C++.
* c-c++-common/spec-barrier-2.c: Likewise.
* c-c++-common/tm/pr54893.c: Likewise.
* g++.dg/cpp0x/pr65327.C: Add dg-warning.
* g++.dg/cpp0x/rv-conv2.C: Likewise.
* g++.dg/cpp0x/rv1n.C: Likewise.
* g++.dg/cpp0x/rv1p.C: Likewise.
* g++.dg/cpp0x/rv2n.C: Likewise.
* g++.dg/cpp0x/rv2p.C: Likewise.
* g++.dg/cpp0x/rv3n.C: Likewise.
* g++.dg/cpp0x/rv3p.C: Likewise.
* g++.dg/cpp0x/rv4n.C: Likewise.
* g++.dg/cpp0x/rv4p.C: Likewise.
* g++.dg/cpp0x/rv5n.C: Likewise.
* g++.dg/cpp0x/rv5p.C: Likewise.
* g++.dg/cpp0x/rv6n.C: Likewise.
* g++.dg/cpp0x/rv6p.C: Likewise.
* g++.dg/cpp0x/rv7n.C: Likewise.
* g++.dg/cpp0x/rv7p.C: Likewise.
* g++.dg/cpp0x/rv8p.C: Likewise.
* g++.dg/cpp0x/trailing14.C: Use -Wno-volatile.
* g++.dg/cpp1y/new1.C: Add dg-warning.
* g++.dg/cpp2a/volatile1.C: New test.
* g++.dg/cpp2a/volatile2.C: New test.
* g++.dg/cpp2a/volatile3.C: New test.
* g++.dg/cpp2a/volatile4.C: New test.
* g++.dg/expr/bool3.C: Add dg-warning.
* g++.dg/expr/bool4.C: Likewise.
   

Re: [C++ Patch] Improve check_var_type locations

[Jason Merrill]

On 8/27/19 4:09 AM, Paolo Carlini wrote:

Hi,

by adding a location_t parameter we can improve the locations of the 
error messages. At the moment the locations of the first and third 
message end up being input_location anyway, but we can imagine improving 
those later (this a much more general issue, the locations we use when 
unnamed entities are involved, see for example all the 'if (name)' in 
grokdeclarator and elsewhere: input_location is very rarely the best 
location).


OK.

Jason

Re: C++ PATCH to implement C++20 P1143R2, constinit (PR c++/91360)

[Jason Merrill]

On 8/27/19 11:24 AM, Marek Polacek wrote:

On Fri, Aug 23, 2019 at 03:10:37PM -0700, Jason Merrill wrote:

+/* True if DECL is declared 'constinit'.  */
+#define DECL_DECLARED_CONSTINIT_P(DECL) \
+  DECL_LANG_FLAG_0 (VAR_DECL_CHECK (STRIP_TEMPLATE (DECL)))


Hmm, given that 'constinit' only affects the declaration, do we really need
a flag on the VAR_DECL?


I was able to do without DECL_DECLARED_CONSTINIT_P.  To achieve that I
introduced LOOKUP_CONSTINIT (yes, it's an abomination; we should probably
extirpate those LOOKUP_ macros).

But that wasn't enough for variable templates, so I also had to introduce
TINFO_VAR_DECLARED_CONSTINIT.  I suppose those DECL_TEMPLATE_INFO aren't
as precious as the VAR_DECL bits.


Hmm, the existing code limiting the unification of constexpr to class-scope
variables seems wrong:

constexpr float pi = 3.14;
extern const float pi;
constexpr float x = pi; // should be OK


Thanks for fixing this meanwhile.

Is this any better?

Bootstrapped/regtested on x86_64-linux.

2019-08-27  Marek Polacek  

PR c++/91360 - Implement C++20 P1143R2: constinit.
* c-common.c (c_common_reswords): Add constinit and __constinit.
(keyword_is_decl_specifier): Handle RID_CONSTINIT.
* c-common.h (enum rid): Add RID_CONSTINIT, RID_FIRST_CXX20, and
RID_LAST_CXX20.
(D_CXX20): Define.
* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_constinit.
* c-format.c (cxx_keywords): Add "constinit".
* c.opt (Wc++2a-compat, Wc++20-compat): New options.

* cp-tree.h (TINFO_VAR_DECLARED_CONSTINIT): Define.
(LOOKUP_CONSTINIT): Define.
(enum cp_decl_spec): Add ds_constinit.
* decl.c (check_tag_decl): Give an error for constinit in type
declarations.
(check_initializer): Also check LOOKUP_CONSTINIT.
(cp_finish_decl): Add checking for a constinit declaration.  Set
TINFO_VAR_DECLARED_CONSTINIT.
(grokdeclarator): Add checking for a declaration with the constinit
specifier.
* lex.c (init_reswords): Handle D_CXX20.
* parser.c (cp_lexer_get_preprocessor_token): Pass a better location
to warning_at.  Warn about C++20 keywords.
(cp_keyword_starts_decl_specifier_p): Handle RID_CONSTINIT.
(cp_parser_diagnose_invalid_type_name): Add an inform about constinit.
(cp_parser_decomposition_declaration): Maybe pass LOOKUP_CONSTINIT to
cp_finish_decl.
(cp_parser_decl_specifier_seq): Handle RID_CONSTINIT.
(cp_parser_init_declarator): Maybe pass LOOKUP_CONSTINIT to
cp_finish_decl.
(set_and_check_decl_spec_loc): Add "constinit".
* pt.c (tsubst_decl): Set TINFO_VAR_DECLARED_CONSTINIT.
(instantiate_decl): Maybe pass LOOKUP_CONSTINIT to cp_finish_decl.
* typeck2.c (store_init_value): If a constinit variable wasn't
initialized using a constant initializer, give an error.


OK, thanks.

Jason

Re: [PATCH] Use cxx_printable_name for __PRETTY_FUNCTION__ in cp_fname_init.

[Jason Merrill]

On 8/28/19 12:29 PM, Martin Liška wrote:

The patch restores behavior before r265711 where we used
cxx_printable_name for __PRETTY_FUNCTION__.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/c-family/ChangeLog:

2019-08-27  Martin Liska  

 PR c++/91155
 * c-common.c (fname_as_string): Use cxx_printable_name for
 __PRETTY_FUNCTION__ same as was used before r265711.



-  if (name)
-free (CONST_CAST (char *, name));


This creates a memory leak for the fname_as_string case.

Jason

libgo patch committed: Move osinit code to Go

[Ian Lance Taylor]

This libgo patch moves the osinit code to Go.  This is a step toward
updating libgo to 1.13.  This adds the 1.13 version of the osinit
function to Go code, and removes the corresponding code from the C
runtime.  This should simplify future updates.  Some additional 1.13
code was brought in to simplify this change.  Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 275000)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-5d15923ada640befb236d5fe94f0c724e98e99d7
+db738935c77443840994e5a9f77e619e67a4c43a
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 274956)
+++ libgo/Makefile.am   (working copy)
@@ -413,40 +413,6 @@ else
 rtems_task_variable_add_file =
 endif
 
-if LIBGO_IS_LINUX
-runtime_getncpu_file = runtime/getncpu-linux.c
-else
-if LIBGO_IS_DARWIN
-runtime_getncpu_file = runtime/getncpu-bsd.c
-else
-if LIBGO_IS_IRIX
-runtime_getncpu_file = runtime/getncpu-irix.c
-else
-if LIBGO_IS_SOLARIS
-runtime_getncpu_file = runtime/getncpu-solaris.c
-else
-if LIBGO_IS_FREEBSD
-runtime_getncpu_file = runtime/getncpu-bsd.c
-else
-if LIBGO_IS_NETBSD
-runtime_getncpu_file = runtime/getncpu-bsd.c
-else
-if LIBGO_IS_AIX
-runtime_getncpu_file = runtime/getncpu-aix.c
-else
-if LIBGO_IS_HURD
-runtime_getncpu_file = runtime/getncpu-hurd.c
-else
-runtime_getncpu_file = runtime/getncpu-none.c
-endif
-endif
-endif
-endif
-endif
-endif
-endif
-endif
-
 runtime_files = \
runtime/aeshash.c \
runtime/go-assert.c \
@@ -479,8 +445,7 @@ runtime_files = \
runtime/stack.c \
runtime/yield.c \
runtime/go-context.S \
-   $(rtems_task_variable_add_file) \
-   $(runtime_getncpu_file)
+   $(rtems_task_variable_add_file)
 
 version.go: s-version; @true
 s-version: Makefile
Index: libgo/Makefile.in
===
--- libgo/Makefile.in   (revision 274956)
+++ libgo/Makefile.in   (working copy)
@@ -230,16 +230,7 @@ am__DEPENDENCIES_4 = $(am__DEPENDENCIES_
 libgo_llgo_la_DEPENDENCIES = $(am__DEPENDENCIES_4)
 @LIBGO_IS_RTEMS_TRUE@am__objects_1 =  \
 @LIBGO_IS_RTEMS_TRUE@  runtime/rtems-task-variable-add.lo
-@LIBGO_IS_AIX_FALSE@@LIBGO_IS_DARWIN_FALSE@@LIBGO_IS_FREEBSD_FALSE@@LIBGO_IS_HURD_FALSE@@LIBGO_IS_IRIX_FALSE@@LIBGO_IS_LINUX_FALSE@@LIBGO_IS_NETBSD_FALSE@@LIBGO_IS_SOLARIS_FALSE@am__objects_2
 = runtime/getncpu-none.lo
-@LIBGO_IS_AIX_FALSE@@LIBGO_IS_DARWIN_FALSE@@LIBGO_IS_FREEBSD_FALSE@@LIBGO_IS_HURD_TRUE@@LIBGO_IS_IRIX_FALSE@@LIBGO_IS_LINUX_FALSE@@LIBGO_IS_NETBSD_FALSE@@LIBGO_IS_SOLARIS_FALSE@am__objects_2
 = runtime/getncpu-hurd.lo
-@LIBGO_IS_AIX_TRUE@@LIBGO_IS_DARWIN_FALSE@@LIBGO_IS_FREEBSD_FALSE@@LIBGO_IS_IRIX_FALSE@@LIBGO_IS_LINUX_FALSE@@LIBGO_IS_NETBSD_FALSE@@LIBGO_IS_SOLARIS_FALSE@am__objects_2
 = runtime/getncpu-aix.lo
-@LIBGO_IS_DARWIN_FALSE@@LIBGO_IS_FREEBSD_FALSE@@LIBGO_IS_IRIX_FALSE@@LIBGO_IS_LINUX_FALSE@@LIBGO_IS_NETBSD_TRUE@@LIBGO_IS_SOLARIS_FALSE@am__objects_2
 = runtime/getncpu-bsd.lo
-@LIBGO_IS_DARWIN_FALSE@@LIBGO_IS_FREEBSD_TRUE@@LIBGO_IS_IRIX_FALSE@@LIBGO_IS_LINUX_FALSE@@LIBGO_IS_SOLARIS_FALSE@am__objects_2
 = runtime/getncpu-bsd.lo
-@LIBGO_IS_DARWIN_FALSE@@LIBGO_IS_IRIX_FALSE@@LIBGO_IS_LINUX_FALSE@@LIBGO_IS_SOLARIS_TRUE@am__objects_2
 = runtime/getncpu-solaris.lo
-@LIBGO_IS_DARWIN_FALSE@@LIBGO_IS_IRIX_TRUE@@LIBGO_IS_LINUX_FALSE@am__objects_2 
= runtime/getncpu-irix.lo
-@LIBGO_IS_DARWIN_TRUE@@LIBGO_IS_LINUX_FALSE@am__objects_2 = 
runtime/getncpu-bsd.lo
-@LIBGO_IS_LINUX_TRUE@am__objects_2 = runtime/getncpu-linux.lo
-am__objects_3 = runtime/aeshash.lo runtime/go-assert.lo \
+am__objects_2 = runtime/aeshash.lo runtime/go-assert.lo \
runtime/go-caller.lo runtime/go-callers.lo runtime/go-cdiv.lo \
runtime/go-cgo.lo runtime/go-construct-map.lo \
runtime/go-ffi.lo runtime/go-fieldtrack.lo \
@@ -252,9 +243,8 @@ am__objects_3 = runtime/aeshash.lo runti
runtime/go-unwind.lo runtime/go-varargs.lo \
runtime/env_posix.lo runtime/panic.lo runtime/print.lo \
runtime/proc.lo runtime/runtime_c.lo runtime/stack.lo \
-   runtime/yield.lo runtime/go-context.lo $(am__objects_1) \
-   $(am__objects_2)
-am_libgo_llgo_la_OBJECTS = $(am__objects_3)
+   runtime/yield.lo runtime/go-context.lo $(am__objects_1)
+am_libgo_llgo_la_OBJECTS = $(am__objects_2)
 libgo_llgo_la_OBJECTS = $(am_libgo_llgo_la_OBJECTS)
 AM_V_lt = $(am__v_lt_@AM_V@)
 am__v_lt_ = $(am__v_lt_@AM_DEFAULT_V@)
@@ -265,7 +255,7 @@ libgo_llgo_la_LINK = $(LIBTOOL) $(AM_V_l
$(libgo_llgo_la_LDFLAGS) $(LDFLAGS) -o $@
 @GOC_IS_LLGO_TRUE@am_libgo_llgo_la_rpath = -rpath $(toolexeclibdir)
 libgo_la_DEPENDENCIES = $(am__DEPENDENCIES_4)
-am_libgo_la

Re: C++ PATCH to implement C++20 P1143R2, constinit (PR c++/91360)

[Marek Polacek]

On Wed, Aug 28, 2019 at 04:15:54PM -0400, Jason Merrill wrote:
> OK, thanks.

Thanks!  I've now updated wwwdocs:

Index: gcc-10/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-10/changes.html,v
retrieving revision 1.11
diff -u -r1.11 changes.html
--- gcc-10/changes.html 27 Aug 2019 12:29:26 -  1.11
+++ gcc-10/changes.html 28 Aug 2019 20:38:12 -
@@ -61,6 +61,7 @@
 P1161R3, Deprecate a[b,c]
 P0848R3, Conditionally Trivial Special Member Functions
 P1091R3, Extending structured bindings
+P1143R2, Adding the constinit keyword
 
   
   Several C++ Defect Reports have been resolved, e.g.:
Index: projects/cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.98
diff -u -r1.98 cxx-status.html
--- projects/cxx-status.html17 Aug 2019 14:18:38 -  1.98
+++ projects/cxx-status.html28 Aug 2019 20:38:12 -
@@ -419,7 +419,7 @@
 
   constinit
   http://wg21.link/p1143r2";>P1143R2
-  No (https://gcc.gnu.org/PR91360";>PR91360)
+  10
   
 
 

Re: [PATCH] fold more string comparison with known result (PR 90879)

[Martin Sebor]

On 8/22/19 3:31 PM, Jeff Law wrote:

On 8/20/19 8:10 PM, Martin Sebor wrote:

Jeff,

Please let me know if you agree/disagree and what I need to
do to advance this work:

   https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html

For the official record, I agree :-)


Great! :)

Any comments/suggestions on the patch?

  https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html

Martin

[PATCH] Update ABI baselines for x86 and powerpc GNU targets

[Jonathan Wakely]

* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.

I need to bump the library version again, to fix PR 91067 (again).

After doing that, the make check-abi test fails, because the
GLIBCXX_3.4.27 symbols aren't in the baseline files yet. This updates
the baselines to match what's in gcc-9.2 and trunk already. I'll
commit this to trunk and gcc-9-branch.

Then after that, I'll export the missing symbols and bump the library
version (on trunk and gcc-9-branch).

commit 1756789a699b14aa4705226a239591191cb4efa7
Author: Jonathan Wakely 
Date:   Tue Aug 27 18:07:38 2019 +0100

Update ABI baselines for x86 and powerpc GNU targets

* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: 
Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.

diff --git a/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
index dcc61af7410..e488ada5c72 100644
--- a/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
@@ -1829,6 +1829,7 @@ 
FUNC:_ZNSt10filesystem28recursive_directory_iteratorC2ERKNS_4pathENS_17directory
 FUNC:_ZNSt10filesystem28recursive_directory_iteratorD1Ev@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem28recursive_directory_iteratorD2Ev@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem28recursive_directory_iteratoraSEOS0_@@GLIBCXX_3.4.26
+FUNC:_ZNSt10filesystem28recursive_directory_iteratoraSERKS0_@@GLIBCXX_3.4.27
 FUNC:_ZNSt10filesystem28recursive_directory_iteratorppEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem4copyERKNS_4pathES2_NS_12copy_optionsE@@GLIBCXX_3.4.26
 
FUNC:_ZNSt10filesystem4copyERKNS_4pathES2_NS_12copy_optionsERSt10error_code@@GLIBCXX_3.4.26
@@ -1885,6 +1886,7 @@ 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorC2ERKNS0_4pathENS_17
 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorD1Ev@@GLIBCXX_3.4.26
 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorD2Ev@@GLIBCXX_3.4.26
 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSEOS1_@@GLIBCXX_3.4.26
+FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSERKS1_@@GLIBCXX_3.4.27
 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorppEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv@@GLIBCXX_3.4.26
 
FUNC:_ZNSt10filesystem7__cxx114path14_S_convert_locEPKcS3_RKSt6locale@@GLIBCXX_3.4.26
@@ -2060,13 +2062,17 @@ FUNC:_ZNSt12__basic_fileIcED1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt12__basic_fileIcED2Ev@@GLIBCXX_3.4
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3

Re: [PATCH V3, #1 of 10], Add basic pc-relative support

[Michael Meissner]

On Wed, Aug 28, 2019 at 12:14:58PM -0500, Segher Boessenkool wrote:
> Hi Mike,
> 
> On Mon, Aug 26, 2019 at 03:54:14PM -0400, Michael Meissner wrote:
> > @@ -1626,8 +1626,8 @@ (define_predicate "small_toc_ref"
> >return GET_CODE (op) == UNSPEC && XINT (op, 1) == UNSPEC_TOCREL;
> >  })
> >  
> > -;; Return true if the operand is a pc-relative address.
> > -(define_predicate "pcrel_address"
> > +;; Return true if the operand is a pc-relative address to a local label.
> > +(define_predicate "pcrel_local_address"
> >(match_code "label_ref,symbol_ref,const")
> 
> Not just to a local label?  Please fix the comment.

Ok.

> > -(define_predicate "pcrel_external_address"
> > +(define_predicate "pcrel_ext_address"
> 
> That is a much worse name.  "ext" can mean "extended" or many more things.

Ok.

> Having good names for these very basic things is important.  The names
> shape the concepts, how you think about the code.
> 
> > +/* Enumeration giving the type of traditional addressing that would be 
> > used to
> > +   decide whether an instruction uses prefixed memory or not.  If the
> > +   traditional instruction uses the DS instruction format, and the bottom 2
> > +   bits of the offset are not 0, the traditional instruction cannot be 
> > used,
> > +   but a prefixed instruction can be used.  */
> 
> "Traditional" is a bad word for documentation.  What you mean is what was
> supported before.  Before you know it "new" will be old as well.

Yeah, yeah, yeah.  I recall in Amsterdam there is the "Oude Kerk" (old church)
built in the 1200's and the "De Nieuwe Kerk" in Amsterdam (built in the 1500's)
and thinking then of the problems of calling something "new" and "old".


> What you mean is non-prefixed addressing?  Please say so, then.
> 
> (And it is "form", not "format", in all the insn descriptions etc...
> Like "D-form".  Please use the same.)

Ok.

> > -#define RELOAD_REG_VALID   0x01/* Mode valid in register..  */
> > -#define RELOAD_REG_MULTIPLE0x02/* Mode takes multiple 
> > registers.  */
> > -#define RELOAD_REG_INDEXED 0x04/* Reg+reg addressing.  */
> > -#define RELOAD_REG_OFFSET  0x08/* Reg+offset addressing. */
> > -#define RELOAD_REG_PRE_INCDEC  0x10/* PRE_INC/PRE_DEC valid.  */
> > -#define RELOAD_REG_PRE_MODIFY  0x20/* PRE_MODIFY valid.  */
> > -#define RELOAD_REG_AND_M16 0x40/* AND -16 addressing.  */
> > -#define RELOAD_REG_QUAD_OFFSET 0x80/* quad offset is limited.  */
> > +#define RELOAD_REG_VALID   0x001   /* Mode valid in register..  */
> > +#define RELOAD_REG_MULTIPLE0x002   /* Mode takes multiple 
> > registers.  */
> > +#define RELOAD_REG_INDEXED 0x004   /* Reg+reg addressing.  */
> > +#define RELOAD_REG_OFFSET  0x008   /* Reg+offset addressing. */
> > +#define RELOAD_REG_PRE_INCDEC  0x010   /* PRE_INC/PRE_DEC valid.  */
> > +#define RELOAD_REG_PRE_MODIFY  0x020   /* PRE_MODIFY valid.  */
> > +#define RELOAD_REG_AND_M16 0x040   /* AND -16 addressing.  */
> > +#define RELOAD_REG_QUAD_OFFSET 0x080   /* DQ offset (bottom 4 bits 0). 
> >  */
> > +#define RELOAD_REG_DS_OFFSET   0x100   /* DS offset (bottom 2 bits 0). 
> >  */
> 
> As explained before, do not do this.  Do not use 3-digit hex numbers; don't
> change existing definitions for no reason, not in the middle of an unrelated
> patch, either.

Ok, but I do hate things not lining up.  But I will keep the original masks as 
they are.

> > @@ -370,6 +369,8 @@ struct rs6000_reg_addr {
> 
> Can you fix this struct / arrays / whatever, instead of adding more to it?
> 
> >enum insn_code reload_gpr_vsx;   /* INSN to move from GPR to VSX.  */
> >enum insn_code reload_vsx_gpr;   /* INSN to move from VSX to GPR.  */
> >addr_mask_type addr_mask[(int)N_RELOAD_REG]; /* Valid address masks.  */
> > +  addr_mask_type any_addr_mask;/* OR of GPR/FPR/VMX 
> > addr_masks.  */
> > +  addr_mask_type default_addr_mask;/* Default addr_mask to use.  */
> 
> And these "address masks" are bitmaps of random flags, one for each
> "register class" (which is not related to the core GCC concept of "register
> class", and the bits are called "RELOAD_REG_*" although this isn't for
> reload at all?

Actually no, they were created explicitly for the secondary reload handler when
I wrote this interface to add VSX support.  These masks were created for the
secondary reload handler to tell what type of addressing a mode has for the 3
hardware register classes (GPR, FPR, VMX) when you are given an address and
told to fix it up.

Now when I wrote them, I always meant to extend their use to the legitimate
address functions to replace all of the if this type is foo, then allow
increment or offset, etc.  I didn't get to other things as time, energy, and
deadlines came up.

> Don't pile new stuff on without cleaning up the old stuff first.
> 
> 
> > + /* 64-bit and larger values on GPRs need DS format instructions.  All
> 
> "Need"...  Well you want to use ld insns

Re: [PATCH, V3, #7 of 10], Implement PCREL_OPT relocation optimization

[Michael Meissner]

Note, there is a minor error in this patch.  However, since I will need to
create V4 patches shortly, I will fix the bug in those patches.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Sanitizing the middle-end interface to the back-end for strict alignment

[Bernd Edlinger]

On 8/28/19 2:07 PM, Christophe Lyon wrote:
> Hi,
> 
> This patch causes an ICE when building libgcc's unwind-arm.o
> when configuring GCC:
> --target  arm-none-linux-gnueabihf --with-mode thumb --with-cpu
> cortex-a15 --with-fpu neon-vfpv4:
> 
> The build works for the same target, but --with-mode arm --with-cpu
> cortex a9 --with-fpu vfp
> 
> In file included from
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/config/arm/unwind-arm.c:144:
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-arm-common.inc:
> In function 'get_eit_entry':
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-arm-common.inc:245:29:
> warning: cast discards 'const' qualifier from pointer target type
> [-Wcast-qual]
>   245 |   ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content;
>   | ^
> during RTL pass: expand
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-arm-common.inc:
> In function 'unwind_phase2_forced':
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-arm-common.inc:319:18:
> internal compiler error: in gen_movdi, at config/arm/arm.md:5235
>   319 |   saved_vrs.core = entry_vrs->core;
>   |   ~~~^
> 0x126530f gen_movdi(rtx_def*, rtx_def*)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/arm/arm.md:5235
> 0x896d92 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/recog.h:318
> 0x896d92 emit_move_insn_1(rtx_def*, rtx_def*)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:3694
> 0x897083 emit_move_insn(rtx_def*, rtx_def*)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:3790
> 0xfc25d6 gen_cpymem_ldrd_strd(rtx_def**)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/arm/arm.c:14582
> 0x126a1f1 gen_cpymemqi(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/arm/arm.md:6688
> 0xb0bc08 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/optabs.c:7440
> 0x89ba1e emit_block_move_via_cpymem
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:1808
> 0x89ba1e emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*,
> block_op_methods, unsigned int, long, unsigned long, unsigned long,
> unsigned long, bool, bool*)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:1627
> 0x89c383 emit_block_move(rtx_def*, rtx_def*, rtx_def*, block_op_methods)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:1667
> 0x89fb4e store_expr(tree_node*, rtx_def*, int, bool, bool)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:5845
> 0x88c1f9 store_field
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:7149
> 0x8a0c22 expand_assignment(tree_node*, tree_node*, bool)
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/expr.c:5304
> 0x761964 expand_gimple_stmt_1
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:3779
> 0x761964 expand_gimple_stmt
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:3875
> 0x768583 expand_gimple_basic_block
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:5915
> 0x76abc6 execute
> 
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:6538
> 
> Christophe
> 

Okay, sorry for the breakage.

What is happening in gen_cpymem_ldrd_strd is of course against the rules:

It uses emit_move_insn on only 4-byte aligned DI-mode memory operands.

I have a patch for this, which is able to fix the libgcc build on a cross, but 
have no
possibility to bootstrap the affected target.

Could you please help?


Thanks
Bernd.
2019-08-28  Bernd Edlinger  

	* config/arm/arm.md (unaligned_loaddi,
	unaligned_storedi): New unspec insn patterns.
	* config/arm/arm.c (gen_cpymem_ldrd_strd): Use unaligned_loaddi
	and unaligned_storedi for 4-byte aligned memory.

Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c	(revision 274987)
+++ gcc/config/arm/arm.c	(working copy)
@@ -14578,8 +14578,10 @@ gen_cpymem_ldrd_strd (rtx *operands)
 	  low_reg = gen_lowpart (SImode, reg0);
 	  hi_reg = gen_highpart_mode (SImode, DImode, reg0);
 	}
-  if (src_aligned)
-emit_move_insn (reg0, src);
+  if (MEM_ALIGN (src) >= 2 * BITS_PER_WORD)
+	emit_move_insn (reg0, src);
+  else if (src_aligned)
+	emit_insn (gen_unaligned_loaddi (reg0, src));
   else
 	{
 	  emit_insn (gen_unaligned_loadsi (low_reg, src));
@@ -14587,8 +14589,10 @@ gen_cpymem_ldrd_strd (rtx

[PATCH V5 03/11] testsuite: annotate c-torture/compile tests with dg-require-stack-size

[Jose E. Marchesi]

This patch annotates tests that make use of a significant a mount of
stack space.  Embedded and other restricted targets may have problems
compiling and running these tests.  Note that the annotations are in
many cases not exact.

testsuite/ChangeLog:

* gcc.c-torture/compile/2609-1.c: Annotate with
dg-require-stack-size.
* gcc/testsuite/gcc.c-torture/compile/2804-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20020304-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20020604-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20021015-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20050303-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20060421-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20071207-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20080903-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20121027-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20151204.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/920501-12.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/920501-4.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/920723-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/921202-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/931003-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/931004-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/950719-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/951222-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/990517-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/bcopy.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr23929.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr25310.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr34458.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr39937.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr41181.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr41634.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr43415.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr43417.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr44788.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/sound.c: Likewise.
---
 gcc/testsuite/ChangeLog  | 35 
 gcc/testsuite/gcc.c-torture/compile/2609-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/2804-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20020304-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/20020604-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20021015-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20050303-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20060421-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/20071207-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20080903-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/20121027-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/20151204.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/920501-12.c  |  1 +
 gcc/testsuite/gcc.c-torture/compile/920501-4.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/920723-1.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/921202-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/931003-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/931004-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/950719-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/951222-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/990517-1.c   |  3 ++
 gcc/testsuite/gcc.c-torture/compile/bcopy.c  |  1 +
 gcc/testsuite/gcc.c-torture/compile/pr23929.c|  1 +
 gcc/testsuite/gcc.c-torture/compile/pr25310.c|  1 +
 gcc/testsuite/gcc.c-torture/compile/pr34458.c|  1 +
 gcc/testsuite/gcc.c-torture/compile/pr39937.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr41181.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr41634.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr43415.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr43417.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr44788.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/sound.c  |  1 +
 32 files changed, 84 insertions(+)

diff --git a/gcc/testsuite/gcc.c-torture/compile/2609-1.c 
b/gcc/testsuite/gcc.c-torture/compile/2609-1.c
index f03aa35a7ac..e41701cc6d9 100644
--- a/gcc/testsuite/gcc.c-torture/compile/2609-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/2609-1.c
@@ -1,3 +1,5 @@
+/* { dg-require-stack-size "1024" } */
+
 int main ()
 {
   char temp[1024] = "tempfile";
diff --git a/gcc/testsuite/gcc.c-torture/compile/2804-1.c 
b/gcc/testsuite/gcc.c-torture/compile/2804-1.c
index 35464c212d2..550669b53a3 100644
--- a/gcc/testsuite/gcc.c-torture/compile/2804-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/2804-1.c
@@ -6,6 +6,7 @@
 /* { dg-skip-if "Not enough 64-bit registers" { pdp11-*-* 

[PATCH V5 09/11] bpf: adjust GCC testsuite to eBPF limitations

[Jose E. Marchesi]

This patch makes many tests in gcc.dg and gcc.c-torture to be skipped
in bpf-*-* targets.  This is due to the many limitations imposed by
eBPF to what would be perfectly valid C code: no support for more than
5 arguments to function calls, no support for indirect jumps, a very
limited range for direct jumps, etc.

Hopefully some of these restrictions will be relaxed in the future.
Also, as semantics associated with object linking get developed in
eBPF, it may be possible at some point to provide a set of standard
run-time libraries for eBPF programs.

gcc/testsuite/ChangeLog:

* gcc.dg/builtins-config.h: eBPF doesn't support C99 standard
functions.
* gcc.c-torture/compile/20101217-1.c: Add a function prototype for
printf.
* gcc.c-torture/compile/2211-1.c: Skip if target bpf-*-*.
* gcc.c-torture/compile/poor.c: Likewise.
* gcc.c-torture/compile/pr25311.c: Likewise.
* gcc.c-torture/compile/pr39928-1.c: Likewise.
* gcc.c-torture/compile/pr70061.c: Likewise.
* gcc.c-torture/compile/920501-7.c: Likewise.
* gcc.c-torture/compile/2403-1.c: Likewise.
* gcc.c-torture/compile/20001226-1.c: Likewise.
* gcc.c-torture/compile/20030903-1.c: Likewise.
* gcc.c-torture/compile/20031125-1.c: Likewise.
* gcc.c-torture/compile/20040101-1.c: Likewise.
* gcc.c-torture/compile/20040317-2.c: Likewise.
* gcc.c-torture/compile/20040726-1.c: Likewise.
* gcc.c-torture/compile/20051216-1.c: Likewise.
* gcc.c-torture/compile/900313-1.c: Likewise.
* gcc.c-torture/compile/920625-1.c: Likewise.
* gcc.c-torture/compile/930421-1.c: Likewise.
* gcc.c-torture/compile/930623-1.c: Likewise.
* gcc.c-torture/compile/961004-1.c: Likewise.
* gcc.c-torture/compile/980504-1.c: Likewise.
* gcc.c-torture/compile/980816-1.c: Likewise.
* gcc.c-torture/compile/990625-1.c: Likewise.
* gcc.c-torture/compile/DFcmp.c: Likewise.
* gcc.c-torture/compile/HIcmp.c: Likewise.
* gcc.c-torture/compile/HIset.c: Likewise.
* gcc.c-torture/compile/QIcmp.c: Likewise.
* gcc.c-torture/compile/QIset.c: Likewise.
* gcc.c-torture/compile/SFset.c: Likewise.
* gcc.c-torture/compile/SIcmp.c: Likewise.
* gcc.c-torture/compile/SIset.c: Likewise.
* gcc.c-torture/compile/UHIcmp.c: Likewise.
* gcc.c-torture/compile/UQIcmp.c: Likewise.
* gcc.c-torture/compile/USIcmp.c: Likewise.
* gcc.c-torture/compile/consec.c: Likewise.
* gcc.c-torture/compile/limits-fndefn.c: Likewise.
* gcc.c-torture/compile/lll.c: Likewise.
* gcc.c-torture/compile/parms.c: Likewise.
* gcc.c-torture/compile/pass.c: Likewise.
* gcc.c-torture/compile/pp.c: Likewise.
* gcc.c-torture/compile/pr32399.c: Likewise.
* gcc.c-torture/compile/pr34091.c: Likewise.
* gcc.c-torture/compile/pr34688.c: Likewise.
* gcc.c-torture/compile/pr37258.c: Likewise.
* gcc.c-torture/compile/pr37327.c: Likewise.
* gcc.c-torture/compile/pr37381.c: Likewise.
* gcc.c-torture/compile/pr37669-2.c: Likewise.
* gcc.c-torture/compile/pr37669.c: Likewise.
* gcc.c-torture/compile/pr37742-3.c: Likewise.
* gcc.c-torture/compile/pr44063.c: Likewise.
* gcc.c-torture/compile/pr48596.c: Likewise.
* gcc.c-torture/compile/pr51856.c: Likewise.
* gcc.c-torture/compile/pr54428.c: Likewise.
* gcc.c-torture/compile/pr54713-1.c: Likewise.
* gcc.c-torture/compile/pr54713-2.c: Likewise.
* gcc.c-torture/compile/pr54713-3.c: Likewise.
* gcc.c-torture/compile/pr55921.c: Likewise.
* gcc.c-torture/compile/pr70240.c: Likewise.
* gcc.c-torture/compile/pr70355.c: Likewise.
* gcc.c-torture/compile/pr82052.c: Likewise.
* gcc.c-torture/compile/pr83487.c: Likewise.
* gcc.c-torture/compile/pr86122.c: Likewise.
* gcc.c-torture/compile/pret-arg.c: Likewise.
* gcc.c-torture/compile/regs-arg-size.c: Likewise.
* gcc.c-torture/compile/structret.c: Likewise.
* gcc.c-torture/compile/uuarg.c: Likewise.
* gcc.dg/20001009-1.c: Likewise.
* gcc.dg/20020418-1.c: Likewise.
* gcc.dg/20020426-2.c: Likewise.
* gcc.dg/20020430-1.c: Likewise.
* gcc.dg/20040306-1.c: Likewise.
* gcc.dg/20040622-2.c: Likewise.
* gcc.dg/20050603-2.c: Likewise.
* gcc.dg/20050629-1.c: Likewise.
* gcc.dg/20061026.c: Likewise.
* gcc.dg/Warray-bounds-3.c: Likewise.
* gcc.dg/Warray-bounds-30.c: Likewise.
* gcc.dg/Wframe-larger-than-2.c: Likewise.
* gcc.dg/Wframe-larger-than.c: Likewise.
* gcc.dg/Wrestrict-11.c: Likewise.
* gcc.c-torture/compile/2804-1.c: Likewise.
---
 gcc/testsuite/ChangeLog| 87 ++
 gcc/test

[PATCH V5 08/11] bpf: make target-supports.exp aware of eBPF

[Jose E. Marchesi]

This patch makes the several effective target checks in
target-supports.exp to be aware of eBPF targets.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp
(check_effective_target_trampolines): Adapt to eBPF.
(check_effective_target_stack_size): Likewise.
(dg-effective-target-value): Likewise.
(check_effective_target_indirect_jumps): Likewise.
(check_effective_target_nonlocal_goto): Likewise.
(check_effective_target_global_constructor): Likewise.
(check_effective_target_return_address): Likewise.
---
 gcc/testsuite/ChangeLog   |  9 +
 gcc/testsuite/lib/target-supports.exp | 18 +++---
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index f457a46a02b..ce08a2f8421 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -526,7 +526,8 @@ proc check_effective_target_trampolines { } {
 || [istarget nvptx-*-*]
 || [istarget hppa2.0w-hp-hpux11.23]
 || [istarget hppa64-hp-hpux11.23]
-|| [istarget pru-*-*] } {
+|| [istarget pru-*-*]
+|| [istarget bpf-*-*] } {
return 0;
 }
 return 1
@@ -781,7 +782,7 @@ proc add_options_for_tls { flags } {
 # Return 1 if indirect jumps are supported, 0 otherwise.
 
 proc check_effective_target_indirect_jumps {} {
-if { [istarget nvptx-*-*] } {
+if { [istarget nvptx-*-*] || [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -790,7 +791,7 @@ proc check_effective_target_indirect_jumps {} {
 # Return 1 if nonlocal goto is supported, 0 otherwise.
 
 proc check_effective_target_nonlocal_goto {} {
-if { [istarget nvptx-*-*] } {
+if { [istarget nvptx-*-*] || [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -799,10 +800,9 @@ proc check_effective_target_nonlocal_goto {} {
 # Return 1 if global constructors are supported, 0 otherwise.
 
 proc check_effective_target_global_constructor {} {
-if { [istarget nvptx-*-*] } {
-   return 0
-}
-if { [istarget amdgcn-*-*] } {
+if { [istarget nvptx-*-*]
+|| [istarget amdgcn-*-*]
+|| [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -825,6 +825,10 @@ proc check_effective_target_return_address {} {
 if { [istarget nvptx-*-*] } {
return 0
 }
+# No notion of return address in eBPF.
+if { [istarget bpf-*-*] } {
+   return 0
+}
 # It could be supported on amdgcn, but isn't yet.
 if { [istarget amdgcn*-*-*] } {
return 0
-- 
2.11.0

[PATCH V5 00/11] eBPF support for GCC

[Jose E. Marchesi]

[Differences from V4:
. Use only two register classes: NO_REGS and ALL_REGS.
. Keep same handling of special cases Init="" and Init="-1" in
  integer_range_info.
. Skip tests pr70061.c and pr39928-1.c, which are now (correctly)
  failing due to the fixed bpf_function_arg_advance.
. Fix constraint in zero_extendsidi2.
. Define FASTEST_ALIGNMENT and LOCAL_ALIGNMENT to help the
  expander generate better code for storing string constant
  locals.
. Rebased to latest master.]

Hi people!

This patch series introduces a port of GCC to eBPF, which is a virtual
machine that resides in the Linux kernel.  Initially intended for
user-level packet capture and filtering, eBPF is nowadays generalized
to serve as a general-purpose infrastructure also for non-networking
purposes.

The binutils support is already upstream.  See
https://sourceware.org/ml/binutils/2019-05/msg00306.html.

eBPF architecture and ABI
=
   
Documentation for eBPF can be found in the linux kernel source tree,
file Documentation/networking/filter.txt.  It covers the instructions
set, the way the interpreter works and the many restrictions imposed
by the kernel verifier.
   
As for the ABI, att this moment compiled eBPF doesn't have very well
established conventions.  The details on what is expected to be in an
ELF file containing eBPF is determined, in practice, by what the llvm
BPF backend generates and what is expected by the the two existing
kernel loaders: bpf_load.c and libbpf.

We hope that the addition of this port to the GNU toolchain will help
to mature this domain.

Overview of the patch series

   
The first few patches are preparatory:

. The first patch updates config.guess and config.sub from the
  'config' upstream project, in order to recognize bpf-*-* triplets.

. The second patch fixes an integrity check in opt-functions.awk.

. The third patch annotates many tests in the gcc.c-torture/compile
  testsuite with their requirements in terms of stack frame size,
  using the existing dg-require-stack-size machinery.

. The fourth patch introduces a new effective target flag called
  indirect_call, and annotates the tests in gcc.c-torture/compile
  accordingly.

The rest of the patches are BPF specific:

The fifth patch adds the new GCC port proper.  Machine description,
implementation of target hooks and macros, command-line options and
the like.

The sixth patch adds a libgcc port for eBPF.  At the moment, it is
minimal and it basically addresses the limitations imposed by the
target, by excluding a few functions in libgcc2 (all of them related
to TImodes) whose default implementations exceed the eBPF stack limit.

The seventh, eight and ninth patches deal with testing the new
port. The gcc.target testsuite is extended with eBPF-specific tests,
covering the backend-specific built-in functions and diagnostics.  The
check-effective-target functions are made aware of eBPF targets. Many
tests in the gcc.c-torture/compile testsuite are annotated to be
skipped in bpf-*-* targets, since they violate some restriction
imposed by the hardware (such as surpassing the stack limit.)  The
resulting testsuite doesn't have unexpected failures, and is currently
the principal way to check for regressions in the port.  Likewise,
many tests in the gcc.dg testsuite are annotated to be skipped in
bpf-*-* targets.

The tenth patch adds documentation updates to the GCC manual,
including information on the new command line options and compiler
built-ins.

Finally, the last patch adds myself as the maintainer of the BPF port.
I personally commit to evolve and maintain the port for as long as
necessary, and to find a suitable replacement in case I have to step
down for whatever reason.

Some notes on the port
==

As a compilation target, eBPF is rather peculiar.  This is mainly due
to the quite hard restrictions imposed by the kernel verifier, and
also due to the security-driven design of the architecture itself.

To list a few examples:

. The stack is disjoint, and each stack frame corresponding to a
  function activation is isolated: it is not possible for a callee to
  access the stack frame of the caller, nor for a caller to access the
  stack frame of it's callees.  The frame pointer register is
  read-only.

. Therefore it is not possible to pass arguments in the stack.

. Argument passing is restricted to 5 arguments.

. Each stack frame is limited to 512 bytes by default.

. The instruction set doesn't support indirect jumps.

. The instruction set doesn't support indirect calls.

. The architecture doesn't provide an explicit stack pointer.
  Instead, the eBPF "hardware" (in this case the kernel verifier)
  examines the compiled program and, by looking at the way the stack
  is accessed, estimates the size of the stack frame for each
  function.

. eBPF "programs" are not ELF executables, but relocatable ELF
  objects.  This is because the kernel loaders need access to certain
  

[PATCH V5 01/11] Update config.sub and config.guess.

[Jose E. Marchesi]

* config.sub: Import upstream version 2019-06-30.
* config.guess: Import upstream version 2019-07-24.
---
 ChangeLog|   5 ++
 config.guess | 264 +++
 config.sub   |  50 +--
 3 files changed, 240 insertions(+), 79 deletions(-)

diff --git a/config.guess b/config.guess
index 8e2a58b864f..97ad0733304 100755
--- a/config.guess
+++ b/config.guess
@@ -2,7 +2,7 @@
 # Attempt to guess a canonical system name.
 #   Copyright 1992-2019 Free Software Foundation, Inc.
 
-timestamp='2019-01-03'
+timestamp='2019-07-24'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -262,6 +262,9 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
 *:SolidBSD:*:*)
echo "$UNAME_MACHINE"-unknown-solidbsd"$UNAME_RELEASE"
exit ;;
+*:OS108:*:*)
+   echo "$UNAME_MACHINE"-unknown-os108_"$UNAME_RELEASE"
+   exit ;;
 macppc:MirBSD:*:*)
echo powerpc-unknown-mirbsd"$UNAME_RELEASE"
exit ;;
@@ -275,8 +278,8 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
echo "$UNAME_MACHINE"-unknown-redox
exit ;;
 mips:OSF1:*.*)
-echo mips-dec-osf1
-exit ;;
+   echo mips-dec-osf1
+   exit ;;
 alpha:OSF1:*:*)
case $UNAME_RELEASE in
*4.0)
@@ -385,20 +388,7 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
echo sparc-hal-solaris2"`echo "$UNAME_RELEASE"|sed -e 's/[^.]*//'`"
exit ;;
 sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
-   set_cc_for_build
-   SUN_ARCH=sparc
-   # If there is a compiler, see if it is configured for 64-bit objects.
-   # Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
-   # This test works for both compilers.
-   if [ "$CC_FOR_BUILD" != no_compiler_found ]; then
-   if (echo '#ifdef __sparcv9'; echo IS_64BIT_ARCH; echo '#endif') | \
-   (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
-   grep IS_64BIT_ARCH >/dev/null
-   then
-   SUN_ARCH=sparcv9
-   fi
-   fi
-   echo "$SUN_ARCH"-sun-solaris2"`echo "$UNAME_RELEASE"|sed -e 
's/[^.]*//'`"
+   echo sparc-sun-solaris2"`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`"
exit ;;
 i86pc:AuroraUX:5.*:* | i86xen:AuroraUX:5.*:*)
echo i386-pc-auroraux"$UNAME_RELEASE"
@@ -998,22 +988,50 @@ EOF
exit ;;
 mips:Linux:*:* | mips64:Linux:*:*)
set_cc_for_build
+   IS_GLIBC=0
+   test x"${LIBC}" = xgnu && IS_GLIBC=1
sed 's/^//' << EOF > "$dummy.c"
#undef CPU
-   #undef ${UNAME_MACHINE}
-   #undef ${UNAME_MACHINE}el
+   #undef mips
+   #undef mipsel
+   #undef mips64
+   #undef mips64el
+   #if ${IS_GLIBC} && defined(_ABI64)
+   LIBCABI=gnuabi64
+   #else
+   #if ${IS_GLIBC} && defined(_ABIN32)
+   LIBCABI=gnuabin32
+   #else
+   LIBCABI=${LIBC}
+   #endif
+   #endif
+
+   #if ${IS_GLIBC} && defined(__mips64) && defined(__mips_isa_rev) && 
__mips_isa_rev>=6
+   CPU=mipsisa64r6
+   #else
+   #if ${IS_GLIBC} && !defined(__mips64) && defined(__mips_isa_rev) && 
__mips_isa_rev>=6
+   CPU=mipsisa32r6
+   #else
+   #if defined(__mips64)
+   CPU=mips64
+   #else
+   CPU=mips
+   #endif
+   #endif
+   #endif
+
#if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || 
defined(MIPSEL)
-   CPU=${UNAME_MACHINE}el
+   MIPS_ENDIAN=el
#else
#if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || 
defined(MIPSEB)
-   CPU=${UNAME_MACHINE}
+   MIPS_ENDIAN=
#else
-   CPU=
+   MIPS_ENDIAN=
#endif
#endif
 EOF
-   eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^CPU'`"
-   test "x$CPU" != x && { echo "$CPU-unknown-linux-$LIBC"; exit; }
+   eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep 
'^CPU\|^MIPS_ENDIAN\|^LIBCABI'`"
+   test "x$CPU" != x && { echo 
"$CPU${MIPS_ENDIAN}-unknown-linux-$LIBCABI"; exit; }
;;
 mips64el:Linux:*:*)
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
@@ -1126,7 +1144,7 @@ EOF
*Pentium)UNAME_MACHINE=i586 ;;
*Pent*|*Celeron) UNAME_MACHINE=i686 ;;
esac
-   echo 
"$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}{$UNAME_VERSION}"
+   echo 
"$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}${UNAME_VERSION}"
exit ;;
 i*86:*:3.2:*)
if test -f /usr/options/cb.name; then
@@ -1310,38 +1328,39 @@ EOF
echo "$UNAME_MACHINE"-apple-rhapsody"$UNAME_RELEASE"
exit ;;
 *:Darwin:*:*)
-   UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
-   set_cc_for_build
-   if test "$UNAME_PROCESSOR" = unknown ; then
-   

[PATCH V5 11/11] bpf: add myself as the maintainer for the eBPF port

[Jose E. Marchesi]

ChangeLog:

* MAINTAINERS: Add myself as the maintainer of the eBPF port.
Remove myself from Write After Approval section.
---
 ChangeLog   | 5 +
 MAINTAINERS | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d8402949bc..5d69d696c2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -57,6 +57,7 @@ arm port  Ramana Radhakrishnan

 arm port   Kyrylo Tkachov  
 avr port   Denis Chertykov 
 bfin port  Jie Zhang   
+bpf port   Jose E. Marchesi
 c6x port   Bernd Schmidt   
 cris port  Hans-Peter Nilsson  
 c-sky port Xianmiao Qu 
@@ -497,7 +498,6 @@ Luis Machado

 Ziga Mahkovec  
 Matthew Malcomson  
 Mikhail Maltsev
-Jose E. Marchesi   
 Patrick Marlier

 Simon Martin   
 Alejandro Martinez 

-- 
2.11.0

[PATCH V5 06/11] bpf: new libgcc port

[Jose E. Marchesi]

This patch adds an eBPF port to libgcc.

As of today, compiled eBPF programs do not support a single-entry
point schema.  Instead, a BPF "executable" is a relocatable ELF object
file containing multiple entry points, in certain named sections.

Also, the BPF loaders in the kernel do not execute .ini/.fini
constructors/destructors.  Therefore, this patch provides empty crtn.S
and cri.S files.

libgcc/ChangeLog:

* config.host: Set cpu_type for bpf-*-* targets.
* config/bpf/t-bpf: Likewise.
* config/bpf/crtn.S: Likewise.
* config/bpf/crti.S: New file.
---
 libgcc/ChangeLog |  7 +++
 libgcc/config.host   |  7 +++
 libgcc/config/bpf/crti.S |  0
 libgcc/config/bpf/crtn.S |  0
 libgcc/config/bpf/t-bpf  | 23 +++
 5 files changed, 37 insertions(+)
 create mode 100644 libgcc/config/bpf/crti.S
 create mode 100644 libgcc/config/bpf/crtn.S
 create mode 100644 libgcc/config/bpf/t-bpf

diff --git a/libgcc/config.host b/libgcc/config.host
index 503ebb6be20..2e9fbc35482 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -107,6 +107,9 @@ avr-*-*)
 bfin*-*)
cpu_type=bfin
;;
+bpf-*-*)
+cpu_type=bpf
+;;
 cr16-*-*)
;;
 crisv32-*-*)
@@ -526,6 +529,10 @@ bfin*-*)
tmake_file="$tmake_file bfin/t-bfin t-fdpbit"
extra_parts="crtbegin.o crtend.o crti.o crtn.o"
 ;;
+bpf-*-*)
+tmake_file="$tmake_file ${cpu_type}/t-${cpu_type}"
+extra_parts="crti.o crtn.o"
+   ;;
 cr16-*-elf)
tmake_file="${tmake_file} cr16/t-cr16 cr16/t-crtlibid t-fdpbit"
extra_parts="$extra_parts crti.o crtn.o crtlibid.o"
diff --git a/libgcc/config/bpf/crti.S b/libgcc/config/bpf/crti.S
new file mode 100644
index 000..e69de29bb2d
diff --git a/libgcc/config/bpf/crtn.S b/libgcc/config/bpf/crtn.S
new file mode 100644
index 000..e69de29bb2d
diff --git a/libgcc/config/bpf/t-bpf b/libgcc/config/bpf/t-bpf
new file mode 100644
index 000..88129a78f61
--- /dev/null
+++ b/libgcc/config/bpf/t-bpf
@@ -0,0 +1,23 @@
+LIB2ADDEH = 
+
+crti.o: $(srcdir)/config/bpf/crti.S
+   $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $<
+
+crtn.o: $(srcdir)/config/bpf/crtn.S
+   $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $<
+
+# Some of the functions defined in libgcc2 exceed the eBPF stack
+# limit, or other restrictions imposed by this peculiar target.
+# Therefore we have to exclude them here.
+#
+# Patterns in bpf.md must guarantee that no calls to the excluded
+# functions are ever generated, and compiler tests should make sure
+# this holds.
+#
+# Note that the modes in the function names below are misleading: di
+# means TImode.
+LIB2FUNCS_EXCLUDE = _mulvdi3 _divdi3 _moddi3 _divmoddi4 _udivdi3 _umoddi3 \
+_udivmoddi4
+
+# Prevent building "advanced" stuff (for example, gcov support).
+INHIBIT_LIBC_CFLAGS = -Dinhibit_libc
-- 
2.11.0

[PATCH V5 02/11] opt-functions.awk: fix comparison of limit, begin and end

[Jose E. Marchesi]

The function integer_range_info makes sure that, if provided, the
initial value fills in the especified range.  However, it is necessary
to convert the values to a numerical context before comparing, to make
sure awk is using arithmetical order and not lexicographical order.

gcc/ChangeLog:

* opt-functions.awk (integer_range_info): Make sure values are in
numeric context before operating with them.
---
 gcc/ChangeLog | 5 +
 gcc/opt-functions.awk | 7 ---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk
index 1190e6d6b66..c1da80c648c 100644
--- a/gcc/opt-functions.awk
+++ b/gcc/opt-functions.awk
@@ -346,9 +346,10 @@ function search_var_name(name, opt_numbers, opts, flags, 
n_opts)
 function integer_range_info(range_option, init, option)
 {
 if (range_option != "") {
-   start = nth_arg(0, range_option);
-   end = nth_arg(1, range_option);
-   if (init != "" && init != "-1" && (init < start || init > end))
+   ival = init + 0;
+   start = nth_arg(0, range_option) + 0;
+   end = nth_arg(1, range_option) + 0;
+   if (init != "" && init != "-1" && (ival < start || ival > end))
  print "#error initial value " init " of '" option "' must be in range 
[" start "," end "]"
return start ", " end
 }
-- 
2.11.0

[PATCH V5 07/11] bpf: gcc.target eBPF testsuite

[Jose E. Marchesi]

This patch adds a new testsuite to gcc.target, with eBPF specific
tests.

Tests are included for:
- Target specific diagnostics.
- All built-in functions.

testsuite/ChangeLog:

* gcc.target/bpf/bpf.exp: New file.
* gcc.target/bpf/builtin-load.c: Likewise.
* cc.target/bpf/constant-calls.c: Likewise.
* gcc.target/bpf/diag-funargs.c: Likewise.
* cc.target/bpf/diag-indcalls.c: Likewise.
* gcc.target/bpf/helper-bind.c: Likewise.
* cc.target/bpf/helper-bpf-redirect.c: Likewise.
* gcc.target/bpf/helper-clone-redirect.c: Likewise.
* gcc.target/bpf/helper-csum-diff.c: Likewise.
* gcc.target/bpf/helper-csum-update.c: Likewise.
* gcc.target/bpf/helper-current-task-under-cgroup.c: Likewise.
* gcc.target/bpf/helper-fib-lookup.c: Likewise.
* gcc.target/bpf/helper-get-cgroup-classid.c: Likewise.
* gcc.target/bpf/helper-get-current-cgroup-id.c: Likewise.
* gcc.target/bpf/helper-get-current-comm.c: Likewise.
* gcc.target/bpf/helper-get-current-pid-tgid.c: Likewise.
* gcc.target/bpf/helper-get-current-task.c: Likewise.
* gcc.target/bpf/helper-get-current-uid-gid.c: Likewise.
* gcc.target/bpf/helper-get-hash-recalc.c: Likewise.
* gcc.target/bpf/helper-get-listener-sock.c: Likewise.
* gcc.target/bpf/helper-get-local-storage.c: Likewise.
* gcc.target/bpf/helper-get-numa-node-id.c: Likewise.
* gcc.target/bpf/helper-get-prandom-u32.c: Likewise.
* gcc.target/bpf/helper-get-route-realm.c: Likewise.
* gcc.target/bpf/helper-get-smp-processor-id.c: Likewise.
* gcc.target/bpf/helper-get-socket-cookie.c: Likewise.
* gcc.target/bpf/helper-get-socket-uid.c: Likewise.
* gcc.target/bpf/helper-getsockopt.c: Likewise.
* gcc.target/bpf/helper-get-stack.c: Likewise.
* gcc.target/bpf/helper-get-stackid.c: Likewise.
* gcc.target/bpf/helper-ktime-get-ns.c: Likewise.
* gcc.target/bpf/helper-l3-csum-replace.c: Likewise.
* gcc.target/bpf/helper-l4-csum-replace.c: Likewise.
* gcc.target/bpf/helper-lwt-push-encap.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-action.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-adjust-srh.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-store-bytes.c: Likewise.
* gcc.target/bpf/helper-map-delete-elem.c: Likewise.
* gcc.target/bpf/helper-map-lookup-elem.c: Likewise.
* gcc.target/bpf/helper-map-peek-elem.c: Likewise.
* gcc.target/bpf/helper-map-pop-elem.c: Likewise.
* gcc.target/bpf/helper-map-push-elem.c: Likewise.
* gcc.target/bpf/helper-map-update-elem.c: Likewise.
* gcc.target/bpf/helper-msg-apply-bytes.c: Likewise.
* gcc.target/bpf/helper-msg-cork-bytes.c: Likewise.
* gcc.target/bpf/helper-msg-pop-data.c: Likewise.
* gcc.target/bpf/helper-msg-pull-data.c: Likewise.
* gcc.target/bpf/helper-msg-push-data.c: Likewise.
* gcc.target/bpf/helper-msg-redirect-hash.c: Likewise.
* gcc.target/bpf/helper-msg-redirect-map.c: Likewise.
* gcc.target/bpf/helper-override-return.c: Likewise.
* gcc.target/bpf/helper-perf-event-output.c: Likewise.
* gcc.target/bpf/helper-perf-event-read.c: Likewise.
* gcc.target/bpf/helper-perf-event-read-value.c: Likewise.
* gcc.target/bpf/helper-perf-prog-read-value.c: Likewise.
* gcc.target/bpf/helper-probe-read.c: Likewise.
* gcc.target/bpf/helper-probe-read-str.c: Likewise.
* gcc.target/bpf/helper-probe-write-user.c: Likewise.
* gcc.target/bpf/helper-rc-keydown.c: Likewise.
* gcc.target/bpf/helper-rc-pointer-rel.c: Likewise.
* gcc.target/bpf/helper-rc-repeat.c: Likewise.
* gcc.target/bpf/helper-redirect-map.c: Likewise.
* gcc.target/bpf/helper-set-hash.c: Likewise.
* gcc.target/bpf/helper-set-hash-invalid.c: Likewise.
* gcc.target/bpf/helper-setsockopt.c: Likewise.
* gcc.target/bpf/helper-skb-adjust-room.c: Likewise.
* gcc.target/bpf/helper-skb-cgroup-id.c: Likewise.
* gcc.target/bpf/helper-skb-change-head.c: Likewise.
* gcc.target/bpf/helper-skb-change-proto.c: Likewise.
* gcc.target/bpf/helper-skb-change-tail.c: Likewise.
* gcc.target/bpf/helper-skb-change-type.c: Likewise.
* gcc.target/bpf/helper-skb-ecn-set-ce.c: Likewise.
* gcc.target/bpf/helper-skb-get-tunnel-key.c: Likewise.
* gcc.target/bpf/helper-skb-get-tunnel-opt.c: Likewise.
* gcc.target/bpf/helper-skb-get-xfrm-state.c: Likewise.
* gcc.target/bpf/helper-skb-load-bytes.c: Likewise.
* gcc.target/bpf/helper-skb-load-bytes-relative.c: Likewise.
* gcc.target/bpf/helper-skb-pull-data.c: Likewise.
* gcc.target/bpf/helper-skb-set-tunnel-key.c: Likewise.
* gcc.target/bpf/helper-skb-set-tunnel-opt.c: Likewise.
*

[PATCH V5 04/11] testsuite: new require effective target indirect_calls

[Jose E. Marchesi]

This patch adds a new dg_require_effective_target procedure to the
testsuite infrastructure: indirect_calls.  This new function tells
whether a target supports calls to non-constant call targets.

This patch also annotates the tests in the gcc.c-torture testuite that
require support for indirect calls.

gcc/ChangeLog:

* doc/sourcebuild.texi (Effective-Target Keywords): Document
indirect_calls.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_indirect_calls):
New proc.
* gcc.c-torture/compile/20010102-1.c: Annotate with
dg-require-effective-target indirect_calls.
* gcc.c-torture/compile/20010107-1.c: Likewise.
* gcc.c-torture/compile/20011109-1.c: Likewise.
* gcc.c-torture/compile/20011218-1.c: Likewise.
* gcc.c-torture/compile/20011229-1.c: Likewise.
* gcc.c-torture/compile/20020129-1.c: Likewise.
* gcc.c-torture/compile/20020320-1.c: Likewise.
* gcc.c-torture/compile/20020706-1.c: Likewise.
* gcc.c-torture/compile/20020706-2.c: Likewise.
* gcc.c-torture/compile/20021205-1.c: Likewise.
* gcc.c-torture/compile/20030921-1.c: Likewise.
* gcc.c-torture/compile/20031023-1.c: Likewise.
* gcc.c-torture/compile/20031023-2.c: Likewise.
* gcc.c-torture/compile/20031023-3.c: Likewise.
* gcc.c-torture/compile/20031023-4.c: Likewise.
* gcc.c-torture/compile/20040614-1.c: Likewise.
* gcc.c-torture/compile/20040909-1.c: Likewise.
* gcc.c-torture/compile/20050122-1.c: Likewise.
* gcc.c-torture/compile/20050202-1.c: Likewise.
* gcc.c-torture/compile/20060208-1.c: Likewise.
* gcc.c-torture/compile/20081108-1.c: Likewise.
* gcc.c-torture/compile/20150327.c: Likewise.
* gcc.c-torture/compile/920428-2.c: Likewise.
* gcc.c-torture/compile/920928-5.c: Likewise.
* gcc.c-torture/compile/930117-1.c: Likewise.
* gcc.c-torture/compile/930607-1.c: Likewise.
* gcc.c-torture/compile/991213-2.c: Likewise.
* gcc.c-torture/compile/callind.c: Likewise.
* gcc.c-torture/compile/calls-void.c: Likewise.
* gcc.c-torture/compile/calls.c: Likewise.
* gcc.c-torture/compile/pr21840.c: Likewise.
* gcc.c-torture/compile/pr32139.c: Likewise.
* gcc.c-torture/compile/pr35607.c: Likewise.
* gcc.c-torture/compile/pr37433-1.c: Likewise.
* gcc.c-torture/compile/pr37433.c: Likewise.
* gcc.c-torture/compile/pr39941.c: Likewise.
* gcc.c-torture/compile/pr40080.c: Likewise.
* gcc.c-torture/compile/pr43635.c: Likewise.
* gcc.c-torture/compile/pr43791.c: Likewise.
* gcc.c-torture/compile/pr43845.c: Likewise.
* gcc.c-torture/compile/pr44043.c: Likewise.
* gcc.c-torture/compile/pr51694.c: Likewise.
* gcc.c-torture/compile/pr77754-2.c: Likewise.
* gcc.c-torture/compile/pr77754-3.c: Likewise.
* gcc.c-torture/compile/pr77754-4.c: Likewise.
* gcc.c-torture/compile/pr89663-2.c: Likewise.
* gcc.c-torture/compile/pta-1.c: Likewise.
* gcc.c-torture/compile/stack-check-1.c: Likewise.
* gcc.dg/Walloc-size-larger-than-18.c: Likewise.
---
 gcc/ChangeLog  |  5 ++
 gcc/doc/sourcebuild.texi   |  4 ++
 gcc/testsuite/ChangeLog| 55 ++
 gcc/testsuite/gcc.c-torture/compile/20010102-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20010107-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20011109-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20011218-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20011229-1.c   |  3 ++
 gcc/testsuite/gcc.c-torture/compile/20020129-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20020320-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20020706-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20020706-2.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20021205-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20030921-1.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/20031023-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20031023-2.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20031023-3.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20031023-4.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20040614-1.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/20040909-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20050122-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20050202-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20060208-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20081108-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20150327.c |  2 +
 gcc/testsuite/gcc.c-torture/compile/920428-2.c |  2 +
 gcc/testsuite/gcc.c-torture/compile/920928-5.c |  3 ++
 gcc/testsuite/gcc.c-torture/compile/930117-1.c |  2 +
 gcc/testsuite/gcc.c-torture/compile/930607

[PATCH V5 05/11] bpf: new GCC port

[Jose E. Marchesi]

This patch adds a port for the Linux kernel eBPF architecture to GCC.

ChangeLog:

  * configure.ac: Support for bpf-*-* targets.
  * configure: Regenerate.

contrib/ChangeLog:

  * config-list.mk (LIST): Disable go in bpf-*-* targets.

gcc/ChangeLog:

  * config.gcc: Support for bpf-*-* targets.
  * common/config/bpf/bpf-common.c: New file.
  * config/bpf/t-bpf: Likewise.
  * config/bpf/predicates.md: Likewise.
  * config/bpf/constraints.md: Likewise.
  * config/bpf/bpf.opt: Likewise.
  * config/bpf/bpf.md: Likewise.
  * config/bpf/bpf.h: Likewise.
  * config/bpf/bpf.c: Likewise.
  * config/bpf/bpf-protos.h: Likewise.
  * config/bpf/bpf-opts.h: Likewise.
  * config/bpf/bpf-helpers.h: Likewise.
  * config/bpf/bpf-helpers.def: Likewise.
---
 ChangeLog  |   5 +
 configure  |  54 ++-
 configure.ac   |  54 ++-
 contrib/ChangeLog  |   4 +
 contrib/config-list.mk |   3 +-
 gcc/ChangeLog  |  16 +
 gcc/common/config/bpf/bpf-common.c |  55 +++
 gcc/config.gcc |   9 +
 gcc/config/bpf/bpf-helpers.def | 194 
 gcc/config/bpf/bpf-helpers.h   | 327 +
 gcc/config/bpf/bpf-opts.h  |  56 +++
 gcc/config/bpf/bpf-protos.h|  33 ++
 gcc/config/bpf/bpf.c   | 958 +
 gcc/config/bpf/bpf.h   | 539 +
 gcc/config/bpf/bpf.md  | 497 +++
 gcc/config/bpf/bpf.opt | 123 +
 gcc/config/bpf/constraints.md  |  32 ++
 gcc/config/bpf/predicates.md   |  72 +++
 gcc/config/bpf/t-bpf   |   0
 19 files changed, 3028 insertions(+), 3 deletions(-)
 create mode 100644 gcc/common/config/bpf/bpf-common.c
 create mode 100644 gcc/config/bpf/bpf-helpers.def
 create mode 100644 gcc/config/bpf/bpf-helpers.h
 create mode 100644 gcc/config/bpf/bpf-opts.h
 create mode 100644 gcc/config/bpf/bpf-protos.h
 create mode 100644 gcc/config/bpf/bpf.c
 create mode 100644 gcc/config/bpf/bpf.h
 create mode 100644 gcc/config/bpf/bpf.md
 create mode 100644 gcc/config/bpf/bpf.opt
 create mode 100644 gcc/config/bpf/constraints.md
 create mode 100644 gcc/config/bpf/predicates.md
 create mode 100644 gcc/config/bpf/t-bpf

diff --git a/configure.ac b/configure.ac
index 1fe97c001cc..b8ce2ad20b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -638,6 +638,9 @@ case "${target}" in
 # No hosted I/O support.
 noconfigdirs="$noconfigdirs target-libssp"
 ;;
+  bpf-*-*)
+noconfigdirs="$noconfigdirs target-libssp"
+;;
   powerpc-*-aix* | rs6000-*-aix*)
 noconfigdirs="$noconfigdirs target-libssp"
 ;;
@@ -672,12 +675,43 @@ if test "${ENABLE_LIBSTDCXX}" = "default" ; then
 avr-*-*)
   noconfigdirs="$noconfigdirs target-libstdc++-v3"
   ;;
+bpf-*-*)
+  noconfigdirs="$noconfigdirs target-libstdc++-v3"
+  ;;
 ft32-*-*)
   noconfigdirs="$noconfigdirs target-libstdc++-v3"
   ;;
   esac
 fi
 
+# Disable C++ on systems where it is known to not work.
+# For testing, you can override this with --enable-languages=c++.
+case ,${enable_languages}, in
+  *,c++,*)
+;;
+  *)
+  case "${target}" in
+bpf-*-*)
+  unsupported_languages="$unsupported_languages c++"
+  ;;
+  esac
+  ;;
+esac
+
+# Disable Objc on systems where it is known to not work.
+# For testing, you can override this with --enable-languages=objc.
+case ,${enable_languages}, in
+  *,objc,*)
+;;
+  *)
+  case "${target}" in
+bpf-*-*)
+  unsupported_languages="$unsupported_languages objc"
+  ;;
+  esac
+  ;;
+esac
+
 # Disable D on systems where it is known to not work.
 # For testing, you can override this with --enable-languages=d.
 case ,${enable_languages}, in
@@ -687,6 +721,9 @@ case ,${enable_languages}, in
 case "${target}" in
   *-*-darwin*)
unsupported_languages="$unsupported_languages d"
+;;
+  bpf-*-*)
+   unsupported_languages="$unsupported_languages d"
;;
 esac
 ;;
@@ -715,6 +752,9 @@ case "${target}" in
 # See .
 unsupported_languages="$unsupported_languages fortran"
 ;;
+  bpf-*-*)
+unsupported_languages="$unsupported_languages fortran"
+;;
 esac
 
 # Disable libffi for some systems.
@@ -761,6 +801,9 @@ case "${target}" in
   arm*-*-symbianelf*)
 noconfigdirs="$noconfigdirs target-libffi"
 ;;
+  bpf-*-*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
   cris-*-* | crisv32-*-*)
 case "${target}" in
   *-*-linux*)
@@ -807,7 +850,7 @@ esac
 # Disable the go frontend on systems where it is known to not work. Please keep
 # this in sync with contrib/config-list.mk.
 case "${target}" in
-*-*-darwin* | *-*-cygwin* | *-*-mingw*)
+*-*-darwin* | *-*-cygwin* | *-*-mingw* | bpf-* )
 unsupported_languages="$unsupported_languages go"

[PATCH V5 10/11] bpf: manual updates for eBPF

[Jose E. Marchesi]

gcc/ChangeLog:

* doc/invoke.texi (Option Summary): Cover eBPF.
(eBPF Options): New section.
* doc/extend.texi (BPF Built-in Functions): Likewise.
(BPF Kernel Helpers): Likewise.
---
 gcc/ChangeLog   |   7 +++
 gcc/doc/extend.texi | 171 
 gcc/doc/invoke.texi |  37 
 3 files changed, 215 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 4aea4d31761..e821cafff1e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13604,6 +13604,8 @@ instructions, but allow the compiler to schedule those 
calls.
 * ARM ARMv8-M Security Extensions::
 * AVR Built-in Functions::
 * Blackfin Built-in Functions::
+* BPF Built-in Functions::
+* BPF Kernel Helpers::
 * FR-V Built-in Functions::
 * MIPS DSP Built-in Functions::
 * MIPS Paired-Single Support::
@@ -14601,6 +14603,175 @@ void __builtin_bfin_csync (void)
 void __builtin_bfin_ssync (void)
 @end smallexample
 
+@node BPF Built-in Functions
+@subsection BPF Built-in Functions
+
+The following built-in functions are available for eBPF targets.
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_byte 
(unsigned long long @var{offset})
+Load a byte from the @code{struct sk_buff} packet data pointed by the register 
@code{%r6} and return it.
+@end deftypefn
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_half 
(unsigned long long @var{offset})
+Load 16-bits from the @code{struct sk_buff} packet data pointed by the 
register @code{%r6} and return it.
+@end deftypefn
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_word 
(unsigned long long @var{offset})
+Load 32-bits from the @code{struct sk_buff} packet data pointed by the 
register @code{%r6} and return it.
+@end deftypefn
+
+@node BPF Kernel Helpers
+@subsection BPF Kernel Helpers
+
+These built-in functions are available for calling kernel helpers, and
+they are available depending on the kernel version selected as the
+CPU.
+
+Rather than using the built-ins directly, it is preferred for programs
+to include @file{bpf-helpers.h} and use the wrappers defined there.
+
+For a full description of what the helpers do, the arguments they
+take, and the returned value, see the
+@file{linux/include/uapi/linux/bpf.h} in a Linux source tree.
+
+@smallexample
+void *__builtin_bpf_helper_map_lookup_elem (void *map, void *key)
+int   __builtin_bpf_helper_map_update_elem (void *map, void *key,
+void *value,
+unsigned long long flags)
+int   __builtin_bpf_helper_map_delete_elem (void *map, const void *key)
+int   __builtin_bpf_helper_map_push_elem (void *map, const void *value,
+  unsigned long long flags)
+int   __builtin_bpf_helper_map_pop_elem (void *map, void *value)
+int   __builtin_bpf_helper_map_peek_elem (void *map, void *value)
+int __builtin_bpf_helper_clone_redirect (void *skb,
+ unsigned int ifindex,
+ unsigned long long flags)
+int __builtin_bpf_helper_skb_get_tunnel_key (void *ctx, void *key, int size, 
int flags)
+int __builtin_bpf_helper_skb_set_tunnel_key (void *ctx, void *key, int size, 
int flags)
+int __builtin_bpf_helper_skb_get_tunnel_opt (void *ctx, void *md, int size)
+int __builtin_bpf_helper_skb_set_tunnel_opt (void *ctx, void *md, int size)
+int __builtin_bpf_helper_skb_get_xfrm_state (void *ctx, int index, void *state,
+int size, int flags)
+static unsigned long long __builtin_bpf_helper_skb_cgroup_id (void *ctx)
+static unsigned long long __builtin_bpf_helper_skb_ancestor_cgroup_id
+ (void *ctx, int level)
+int __builtin_bpf_helper_skb_vlan_push (void *ctx, __be16 vlan_proto, __u16 
vlan_tci)
+int __builtin_bpf_helper_skb_vlan_pop (void *ctx)
+int __builtin_bpf_helper_skb_ecn_set_ce (void *ctx)
+
+int __builtin_bpf_helper_skb_load_bytes (void *ctx, int off, void *to, int len)
+int __builtin_bpf_helper_skb_load_bytes_relative (void *ctx, int off, void 
*to, int len, __u32 start_header)
+int __builtin_bpf_helper_skb_store_bytes (void *ctx, int off, void *from, int 
len, int flags)
+int __builtin_bpf_helper_skb_under_cgroup (void *ctx, void *map, int index)
+int __builtin_bpf_helper_skb_change_head (void *, int len, int flags)
+int __builtin_bpf_helper_skb_pull_data (void *, int len)
+int __builtin_bpf_helper_skb_change_proto (void *ctx, __be16 proto, __u64 
flags)
+int __builtin_bpf_helper_skb_change_type (void *ctx, __u32 type)
+int __builtin_bpf_helper_skb_change_tail (void *ctx, __u32 len, __u64 flags)
+int __builtin_bpf_helper_skb_adjust_room (void *ctx, __s32 len_diff, __u32 
mode,
+ unsigned long long flags)
+@end smallexample
+
+Other helpers:
+
+@smallexample
+int __builtin_bpf_helper_probe_r

Re: [PATCH, V3, #2 of 10], Improve rs6000_setup_addr_mask

[Segher Boessenkool]

Hi!

Thanks for splitting things out, that makes it easier to understand.

On Mon, Aug 26, 2019 at 04:10:22PM -0400, Michael Meissner wrote:
> This code attempts to make this clearer by moving the settings for
> GPRs, FPRs, and traditional Altivec registers to separate functions.

They are called VRs.  They always were, but it really doesn't make much
sense to call them "traditional AltiVec registers" now; they are used
for so many more things.

> The second issue is SDmode indicates that it can do PRE_INCREMENT,
> PRE_DECREMENT, and PRE_MODIFY in the floating point registers.  It
> can't since you need to use the LFIWZX instruction to load SDmode, and

(Or lxsiwzx -- you can do all floating point in VRs, too!)

> that does not have an pre-increment format.  I was not able to make a
> test case that actually failed with SDmode.  I opted to make my
> comparison simpler by returning the same information that the current
> compiler uses.  If you prefer, I can change it so the address mask does
> not indicate that the mode can do pre increment, etc.

Does that result in better code?  Does it make the compiler simpler?  If
either of those is "yes", then yes please.

> +/* Return true if the mode is a type that uses the full vector register (like
> +   V2DImode or KFmode).  Do not return true for 128-bit types like TDmode or
> +   IFmode.  */

(_A_ full vector register, "the" makes no sense if the mode doesn't go in
vector registers at all).

As opposed to?  Using only (part of) dword 0?

> +static bool
> +mode_uses_full_vector_reg (machine_mode mode)
>  {
> +  if (GET_MODE_SIZE (mode) < 16)
> +return false;

Is this needed, given the other conditions?  Or...

> +  if (TARGET_VSX)
> +return (VECTOR_MODE_P (mode)
> + || FLOAT128_VECTOR_P (mode)
> + || mode == TImode);
> +
> +  if (TARGET_ALTIVEC)
> +return ALTIVEC_VECTOR_MODE (mode);

... maybe it should be just ALTIVEC_OR_VSX_VECTOR_MODE instead?  And the
TImode test?

> +/* Figure out if we can do PRE_INC, PRE_DEC, or PRE_MODIFY addressing for a
> +   given MODE.  If we allow scalars into Altivec registers, don't allow
> +   PRE_INC, PRE_DEC, or PRE_MODIFY.
> +
> +   For VSX systems, we don't allow update addressing for DFmode/SFmode if 
> those
> +   registers can go in both the traditional floating point registers and
> +   Altivec registers.  The load/store instructions for the Altivec registers 
> do
> +   not have update forms.  If we allowed update addressing, it seems to break
> +   IV-OPT code using floating point if the index type is int instead of long
> +   (PR target/81550 and target/84042).  */

"Seems to break"...  Well, ivopts makes a different decision, which isn't
very surprising, and that leads to a loop that is *better* optimised?

Not that load/store-with-update is terribly interesting for floating
point, on modern cores anyway, or that it is ideal to have insns that
only exist for half of the allowed registers :-)

> +/* Return the address mask bits for whether we allow PRE_INCREMENT,
> +   PRE_DECREMENT, and PRE_MODIFY for a given MODE.  */

Why do we do decrement and increment separately here?  There are no insns
like that at all.  Not allowing pre_modify because you need to have an
"extra" like in other cases for bigger modes, well, just do that then?

> +static addr_mask_type
> +setup_reg_addr_masks_pre_incdec (machine_mode mode)
> +{
> +  addr_mask_type addr_mask = 0;
> +
> +  if (TARGET_UPDATE
> +  && GET_MODE_SIZE (mode) <= 8
> +  && !VECTOR_MODE_P (mode)

If it is at most 8 bytes, it cannot be a vector (all our vector modes
are 16 or 32 bytes).

> +  && !FLOAT128_VECTOR_P (mode)
> +  && !COMPLEX_MODE_P (mode)
> +  && (mode != E_DFmode || !TARGET_VSX)
> +  && (mode != E_SFmode || !TARGET_P8_VECTOR))

(Please use DFmode etc. where you can).

We probably should have some helper to say what modes can go in vector
regs.  Well, don't we have that already?  rs6000_vector_unit[mode]?

> +  bool indexed_only = (mode == SDmode && TARGET_LFIWZX);
> +
> +  if (!indexed_only
> +   && (mode_size_inner <= 8
> +   || (mode_size_inner == 16 && TARGET_P9_VECTOR
> +   && mode_uses_full_vector_reg (mode_inner

The P9 part here needs a comment (and/or a nicer condition).

> +  else if (mode == SFmode || mode_size == 8

Newline before the || please.

> +|| mode_uses_full_vector_reg (mode_inner)
> +|| (TARGET_LFIWAX && (mode == SImode || mode == SDmode))
> +|| (TARGET_P9_VECTOR && (mode == QImode || mode == HImode)))
> + addr_mask |= RELOAD_REG_INDEXED;

These last two really only care about the size of the mode?  So write it
like that, too?

> +  /* It is weird that previous versions of GCC supported pre increment,
> +  etc. forms of addressing for SDmode, when you could only use an
> +  indexed instruction, but allow it for now.  Previous versions of GCC
> +  also set the indexed flag for SDmode, even though

[PATCH V5 10/11] bpf: manual updates for eBPF

[Jose E. Marchesi]

gcc/ChangeLog:

* doc/invoke.texi (Option Summary): Cover eBPF.
(eBPF Options): New section.
* doc/extend.texi (BPF Built-in Functions): Likewise.
(BPF Kernel Helpers): Likewise.
---
 gcc/ChangeLog   |   7 +++
 gcc/doc/extend.texi | 171 
 gcc/doc/invoke.texi |  37 
 3 files changed, 215 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 4aea4d31761..e821cafff1e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13604,6 +13604,8 @@ instructions, but allow the compiler to schedule those 
calls.
 * ARM ARMv8-M Security Extensions::
 * AVR Built-in Functions::
 * Blackfin Built-in Functions::
+* BPF Built-in Functions::
+* BPF Kernel Helpers::
 * FR-V Built-in Functions::
 * MIPS DSP Built-in Functions::
 * MIPS Paired-Single Support::
@@ -14601,6 +14603,175 @@ void __builtin_bfin_csync (void)
 void __builtin_bfin_ssync (void)
 @end smallexample
 
+@node BPF Built-in Functions
+@subsection BPF Built-in Functions
+
+The following built-in functions are available for eBPF targets.
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_byte 
(unsigned long long @var{offset})
+Load a byte from the @code{struct sk_buff} packet data pointed by the register 
@code{%r6} and return it.
+@end deftypefn
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_half 
(unsigned long long @var{offset})
+Load 16-bits from the @code{struct sk_buff} packet data pointed by the 
register @code{%r6} and return it.
+@end deftypefn
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_word 
(unsigned long long @var{offset})
+Load 32-bits from the @code{struct sk_buff} packet data pointed by the 
register @code{%r6} and return it.
+@end deftypefn
+
+@node BPF Kernel Helpers
+@subsection BPF Kernel Helpers
+
+These built-in functions are available for calling kernel helpers, and
+they are available depending on the kernel version selected as the
+CPU.
+
+Rather than using the built-ins directly, it is preferred for programs
+to include @file{bpf-helpers.h} and use the wrappers defined there.
+
+For a full description of what the helpers do, the arguments they
+take, and the returned value, see the
+@file{linux/include/uapi/linux/bpf.h} in a Linux source tree.
+
+@smallexample
+void *__builtin_bpf_helper_map_lookup_elem (void *map, void *key)
+int   __builtin_bpf_helper_map_update_elem (void *map, void *key,
+void *value,
+unsigned long long flags)
+int   __builtin_bpf_helper_map_delete_elem (void *map, const void *key)
+int   __builtin_bpf_helper_map_push_elem (void *map, const void *value,
+  unsigned long long flags)
+int   __builtin_bpf_helper_map_pop_elem (void *map, void *value)
+int   __builtin_bpf_helper_map_peek_elem (void *map, void *value)
+int __builtin_bpf_helper_clone_redirect (void *skb,
+ unsigned int ifindex,
+ unsigned long long flags)
+int __builtin_bpf_helper_skb_get_tunnel_key (void *ctx, void *key, int size, 
int flags)
+int __builtin_bpf_helper_skb_set_tunnel_key (void *ctx, void *key, int size, 
int flags)
+int __builtin_bpf_helper_skb_get_tunnel_opt (void *ctx, void *md, int size)
+int __builtin_bpf_helper_skb_set_tunnel_opt (void *ctx, void *md, int size)
+int __builtin_bpf_helper_skb_get_xfrm_state (void *ctx, int index, void *state,
+int size, int flags)
+static unsigned long long __builtin_bpf_helper_skb_cgroup_id (void *ctx)
+static unsigned long long __builtin_bpf_helper_skb_ancestor_cgroup_id
+ (void *ctx, int level)
+int __builtin_bpf_helper_skb_vlan_push (void *ctx, __be16 vlan_proto, __u16 
vlan_tci)
+int __builtin_bpf_helper_skb_vlan_pop (void *ctx)
+int __builtin_bpf_helper_skb_ecn_set_ce (void *ctx)
+
+int __builtin_bpf_helper_skb_load_bytes (void *ctx, int off, void *to, int len)
+int __builtin_bpf_helper_skb_load_bytes_relative (void *ctx, int off, void 
*to, int len, __u32 start_header)
+int __builtin_bpf_helper_skb_store_bytes (void *ctx, int off, void *from, int 
len, int flags)
+int __builtin_bpf_helper_skb_under_cgroup (void *ctx, void *map, int index)
+int __builtin_bpf_helper_skb_change_head (void *, int len, int flags)
+int __builtin_bpf_helper_skb_pull_data (void *, int len)
+int __builtin_bpf_helper_skb_change_proto (void *ctx, __be16 proto, __u64 
flags)
+int __builtin_bpf_helper_skb_change_type (void *ctx, __u32 type)
+int __builtin_bpf_helper_skb_change_tail (void *ctx, __u32 len, __u64 flags)
+int __builtin_bpf_helper_skb_adjust_room (void *ctx, __s32 len_diff, __u32 
mode,
+ unsigned long long flags)
+@end smallexample
+
+Other helpers:
+
+@smallexample
+int __builtin_bpf_helper_probe_rea

Re: C++ PATCH for P1152R4: Deprecating some uses of volatile (PR c++/91361)

[Marek Polacek]

On Wed, Aug 28, 2019 at 04:08:39PM -0400, Jason Merrill wrote:
> On 8/26/19 1:46 PM, Marek Polacek wrote:
> > +Wvolatile
> > +C++ ObjC++ Var(warn_volatile) Warning
> > +Warn about certain uses of volatile qualifier.
> 
> Maybe "deprecated uses"?

Ok, changed.

> > --- gcc/cp/expr.c
> > +++ gcc/cp/expr.c
> > @@ -207,6 +207,27 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
> > recurse_op[0] = true;
> > break;
> > +case MODIFY_EXPR:
> > +   {
> > + tree lhs = TREE_OPERAND (expr, 0);
> > + /* [expr.ass] "A simple assignment whose left operand is of
> > +a volatile-qualified type is deprecated unless the assignment
> > +is either a discarded-value expression or appears in an
> > +unevaluated context."  */
> > + if (read_p
> > + && (TREE_THIS_VOLATILE (lhs)
> > + || CP_TYPE_VOLATILE_P (TREE_TYPE (lhs)))
> > + && !TREE_THIS_VOLATILE (expr))
> > +   {
> > + warning_at (location_of (expr), OPT_Wvolatile,
> > + "assignment with %-qualified left "
> > + "operand is deprecated");
> 
> This should be more specific; the assignment itself isn't deprecated, but
> rather using the assignment as an lvalue or rvalue.

This now reads "using value of simple assignment with volatile-qualified left
operand is deprecated".

> > + /* An expression of the form E1 op= E2.  [expr.ass] says:
> > +"Such expressions are deprecated if E1 has volatile-qualified
> > +type."  We warn here rather than in cp_genericize_r because
> > +for compound assignments we are supposed to warn even if the
> > +assignment is a discarded-value expression.  */
> > + if (TREE_THIS_VOLATILE (lhs) || CP_TYPE_VOLATILE_P (lhstype))
> > +   warning_at (loc, OPT_Wvolatile,
> > +   "assignment with %-qualified left operand "
> > +   "is deprecated");
> 
> And this should say "compound assignment ..."

Fixed.

> > +@item -Wvolatile @r{(C++ and Objective-C++ only)}
> > +@opindex Wvolatile
> > +@opindex Wno-volatile
> > +Warn about certain uses of volatile qualifier.  This includes postfix
> > +@code{++} and @code{--} expressions, prefix @code{++} and @code{--}
> > +expressions, certain assignments where the left operand is a
> > +volatile-qualified non-class type
> 
> This should also be more specific.

Improved (hopefully).

> > +
> > +  // Unevaluated operand.
> > +  decltype(vi = 42) x = vi;
> 
> I guess we should also test that there's no warning for
> 
> decltype(i = vi = 42)
> 
> since this is also an unevaluated context.  It's a bit odd the proposal uses
> "unevaluated context" rather than "unevaluated operand".

Yes we should, and *of course* it was a case where my patch emitted a bogus
warning.  But it was trivial to fix by checking cp_unevaluated_operand.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2019-08-28  Marek Polacek  

Implement P1152R4: Deprecating some uses of volatile.
PR c++/91361
* c-opts.c (c_common_post_options): Enable -Wvolatile by
default for C++2a, unless -Wno-deprecated.
* c.opt (Wvolatile): New warning.

* cp-gimplify.c (cp_fold): Set TREE_THIS_VOLATILE.
* decl.c (grokdeclarator): Warn about a volatile-qualified structured
binding and return type.
(grokparms): Warn about a volatile-qualified function parameter.
* expr.c (mark_use) : Emit a -Wvolatile warning.
* typeck.c (cp_build_unary_op): Emit a -Wvolatile warning for pre and
post ++/-- on a volatile operand.
(genericize_compound_lvalue): Use a better location.  Don't lose
TREE_THIS_VOLATILE.
(cp_build_modify_expr): Emit a -Wvolatile warning for a compound
assignment whose LHS is volatile-qualified.  Build the assignment with
a more precise location.

* doc/invoke.texi: Document -Wvolatile.

* c-c++-common/Wbool-operation-1.c: Use -Wno-volatile in C++.
* c-c++-common/gomp/atomic-1.c: Likewise.
* c-c++-common/gomp/atomic-9.c: Likewise.
* c-c++-common/gomp/depend-iterator-1.c: Likewise.
* c-c++-common/gomp/loop-1.c: Adjust warning location for C++.
* c-c++-common/gomp/order-3.c: Likewise.
* c-c++-common/pr69733.c: Use -Wno-volatile in C++.
* c-c++-common/spec-barrier-2.c: Likewise.
* c-c++-common/tm/pr54893.c: Likewise.
* g++.dg/cpp0x/pr65327.C: Add dg-warning.
* g++.dg/cpp0x/rv-conv2.C: Likewise.
* g++.dg/cpp0x/rv1n.C: Likewise.
* g++.dg/cpp0x/rv1p.C: Likewise.
* g++.dg/cpp0x/rv2n.C: Likewise.
* g++.dg/cpp0x/rv2p.C: Likewise.
* g++.dg/cpp0x/rv3n.C: Likewise.
* g++.dg/cpp0x/rv3p.C: Likewise.
* g++.dg/cpp0x/rv4n.C: Likewise.
* g++.dg/cpp0x/rv4p.C: Likewise.
* g++.dg/cpp0x/rv5n.C: Likewise.
* g++.dg/cpp0x/rv5p.C: Likewise.
* g++.dg/cpp0x/rv6n.C: Like

PR78736

[Prathamesh Kulkarni]

Hi,
This is a rebased patch on trunk for PR78736. The last time, it got
stuck, because of warning issues with libgfortran, for which I filed
PR91593. The patch relegates the warning to Wextra instead, which only
triggers (non-fatal) warnings in libgfortran/io/transfer.c, and
survives bootstrap+test on x86_64-unknown-linux-gnu. (Also IIRC, Wall
triggered several instances of the warning with allmodconfig kernel
build last time).
Is the patch OK to commit ?

Thanks,
Prathamesh
2019-08-29  Prathamesh Kulkarni  

* doc/invoke.texi: Document -Wenum-conversion.
* c-family/c.opt (Wenum-conversion): New option.
* c/c-typeck.c (convert_for_assignment): Handle Wenum-conversion.

testsuite/
* gcc.dg/Wenum-conversion.c: New test-case.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 257cadfa5f1..601457b3762 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -534,6 +534,10 @@ Wenum-compare
 C ObjC C++ ObjC++ Var(warn_enum_compare) Init(-1) Warning LangEnabledBy(C 
ObjC,Wall || Wc++-compat)
 Warn about comparison of different enum types.
 
+Wenum-conversion
+C ObjC Var(warn_enum_conversion) Init(0) Warning LangEnabledBy(C ObjC,Wextra)
+Warn about implicit conversion of enum types.
+
 Werror
 C ObjC C++ ObjC++
 ; Documented in common.opt
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 2bbf0e21fb9..d4e12eb93d1 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -6726,6 +6726,21 @@ convert_for_assignment (location_t location, location_t 
expr_loc, tree type,
  }
 }
 
+  if (warn_enum_conversion)
+{
+  tree checktype = origtype != NULL_TREE ? origtype : rhstype;
+  if (checktype != error_mark_node
+ && TREE_CODE (checktype) == ENUMERAL_TYPE
+ && TREE_CODE (type) == ENUMERAL_TYPE
+ && TYPE_MAIN_VARIANT (checktype) != TYPE_MAIN_VARIANT (type))
+   {
+ gcc_rich_location loc (location);
+ warning_at (&loc, OPT_Wenum_conversion,
+ "implicit conversion from %qT to %qT",
+ checktype, type);
+   }
+}
+
   if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (rhstype))
 {
   warn_for_address_or_pointer_of_packed_member (type, orig_rhs);
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 549e043c67c..d497eb1f098 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -306,7 +306,8 @@ Objective-C and Objective-C++ Dialects}.
 -Wno-discarded-qualifiers  -Wno-discarded-array-qualifiers @gol
 -Wno-div-by-zero  -Wdouble-promotion @gol
 -Wduplicated-branches  -Wduplicated-cond @gol
--Wempty-body  -Wenum-compare  -Wno-endif-labels  -Wexpansion-to-defined @gol
+-Wempty-body  -Wenum-compare  -Wenum-conversion @gol
+-Wno-endif-labels  -Wexpansion-to-defined @gol
 -Werror  -Werror=*  -Wextra-semi  -Wfatal-errors @gol
 -Wfloat-equal  -Wformat  -Wformat=2 @gol
 -Wno-format-contains-nul  -Wno-format-extra-args  @gol
@@ -4430,6 +4431,7 @@ Options} and @ref{Objective-C and Objective-C++ Dialect 
Options}.
 -Wcomment  @gol
 -Wduplicate-decl-specifier @r{(C and Objective-C only)} @gol
 -Wenum-compare @r{(in C/ObjC; this is on by default in C++)} @gol
+-Wenum-conversion @r{in C/ObjC;} @gol
 -Wformat   @gol
 -Wint-in-bool-context  @gol
 -Wimplicit @r{(C and Objective-C only)} @gol
@@ -7002,6 +7004,12 @@ In C++ enumerated type mismatches in conditional 
expressions are also
 diagnosed and the warning is enabled by default.  In C this warning is 
 enabled by @option{-Wall}.
 
+@item -Wenum-conversion @r{(C, Objective-C only)}
+@opindex Wenum-conversion
+@opindex Wno-enum-conversion
+Warn when a value of enumerated type is implicitly converted to a 
+different enumerated type.  This warning is enabled by @option{-Wextra}.
+
 @item -Wextra-semi @r{(C++, Objective-C++ only)}
 @opindex Wextra-semi
 @opindex Wno-extra-semi
diff --git a/gcc/testsuite/gcc.dg/Wenum-conversion.c 
b/gcc/testsuite/gcc.dg/Wenum-conversion.c
new file mode 100644
index 000..86033399b7d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wenum-conversion.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-Wenum-conversion" } */
+
+enum X { x1, x2 };
+enum Y { y1, y2 };
+
+enum X obj = y1;  /* { dg-warning "implicit conversion from .enum Y. to .enum 
X." } */
+enum Y obj2 = y1;
+
+enum X obj3;
+void foo()
+{
+  obj3 = y2; /* { dg-warning "implicit conversion from .enum Y. to .enum X." } 
*/
+}
+
+void bar(enum X);
+void f(void)
+{
+  bar (y1); /* { dg-warning "implicit conversion from .enum Y. to .enum X." } 
*/
+}

Re: C++ PATCH for P1152R4: Deprecating some uses of volatile (PR c++/91361)

[Jason Merrill]

OK.

On Wed, Aug 28, 2019 at 7:56 PM Marek Polacek  wrote:
>
> On Wed, Aug 28, 2019 at 04:08:39PM -0400, Jason Merrill wrote:
> > On 8/26/19 1:46 PM, Marek Polacek wrote:
> > > +Wvolatile
> > > +C++ ObjC++ Var(warn_volatile) Warning
> > > +Warn about certain uses of volatile qualifier.
> >
> > Maybe "deprecated uses"?
>
> Ok, changed.
>
> > > --- gcc/cp/expr.c
> > > +++ gcc/cp/expr.c
> > > @@ -207,6 +207,27 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
> > > recurse_op[0] = true;
> > > break;
> > > +case MODIFY_EXPR:
> > > +   {
> > > + tree lhs = TREE_OPERAND (expr, 0);
> > > + /* [expr.ass] "A simple assignment whose left operand is of
> > > +a volatile-qualified type is deprecated unless the assignment
> > > +is either a discarded-value expression or appears in an
> > > +unevaluated context."  */
> > > + if (read_p
> > > + && (TREE_THIS_VOLATILE (lhs)
> > > + || CP_TYPE_VOLATILE_P (TREE_TYPE (lhs)))
> > > + && !TREE_THIS_VOLATILE (expr))
> > > +   {
> > > + warning_at (location_of (expr), OPT_Wvolatile,
> > > + "assignment with %-qualified left "
> > > + "operand is deprecated");
> >
> > This should be more specific; the assignment itself isn't deprecated, but
> > rather using the assignment as an lvalue or rvalue.
>
> This now reads "using value of simple assignment with volatile-qualified left
> operand is deprecated".
>
> > > + /* An expression of the form E1 op= E2.  [expr.ass] says:
> > > +"Such expressions are deprecated if E1 has volatile-qualified
> > > +type."  We warn here rather than in cp_genericize_r because
> > > +for compound assignments we are supposed to warn even if the
> > > +assignment is a discarded-value expression.  */
> > > + if (TREE_THIS_VOLATILE (lhs) || CP_TYPE_VOLATILE_P (lhstype))
> > > +   warning_at (loc, OPT_Wvolatile,
> > > +   "assignment with %-qualified left operand "
> > > +   "is deprecated");
> >
> > And this should say "compound assignment ..."
>
> Fixed.
>
> > > +@item -Wvolatile @r{(C++ and Objective-C++ only)}
> > > +@opindex Wvolatile
> > > +@opindex Wno-volatile
> > > +Warn about certain uses of volatile qualifier.  This includes postfix
> > > +@code{++} and @code{--} expressions, prefix @code{++} and @code{--}
> > > +expressions, certain assignments where the left operand is a
> > > +volatile-qualified non-class type
> >
> > This should also be more specific.
>
> Improved (hopefully).
>
> > > +
> > > +  // Unevaluated operand.
> > > +  decltype(vi = 42) x = vi;
> >
> > I guess we should also test that there's no warning for
> >
> > decltype(i = vi = 42)
> >
> > since this is also an unevaluated context.  It's a bit odd the proposal uses
> > "unevaluated context" rather than "unevaluated operand".
>
> Yes we should, and *of course* it was a case where my patch emitted a bogus
> warning.  But it was trivial to fix by checking cp_unevaluated_operand.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-08-28  Marek Polacek  
>
> Implement P1152R4: Deprecating some uses of volatile.
> PR c++/91361
> * c-opts.c (c_common_post_options): Enable -Wvolatile by
> default for C++2a, unless -Wno-deprecated.
> * c.opt (Wvolatile): New warning.
>
> * cp-gimplify.c (cp_fold): Set TREE_THIS_VOLATILE.
> * decl.c (grokdeclarator): Warn about a volatile-qualified structured
> binding and return type.
> (grokparms): Warn about a volatile-qualified function parameter.
> * expr.c (mark_use) : Emit a -Wvolatile warning.
> * typeck.c (cp_build_unary_op): Emit a -Wvolatile warning for pre and
> post ++/-- on a volatile operand.
> (genericize_compound_lvalue): Use a better location.  Don't lose
> TREE_THIS_VOLATILE.
> (cp_build_modify_expr): Emit a -Wvolatile warning for a compound
> assignment whose LHS is volatile-qualified.  Build the assignment with
> a more precise location.
>
> * doc/invoke.texi: Document -Wvolatile.
>
> * c-c++-common/Wbool-operation-1.c: Use -Wno-volatile in C++.
> * c-c++-common/gomp/atomic-1.c: Likewise.
> * c-c++-common/gomp/atomic-9.c: Likewise.
> * c-c++-common/gomp/depend-iterator-1.c: Likewise.
> * c-c++-common/gomp/loop-1.c: Adjust warning location for C++.
> * c-c++-common/gomp/order-3.c: Likewise.
> * c-c++-common/pr69733.c: Use -Wno-volatile in C++.
> * c-c++-common/spec-barrier-2.c: Likewise.
> * c-c++-common/tm/pr54893.c: Likewise.
> * g++.dg/cpp0x/pr65327.C: Add dg-warning.
> * g++.dg/cpp0x/rv-conv2.C: Likewise.
> * g++.dg/cpp0x/rv1n.C: Likewise.
> * g++.dg/cpp0x/rv1p.C: Likewise.
> * g++.dg/cpp0x/rv2n.C: Likewise.
> * g++.dg/cpp0x/rv2p.C: Likewise.
>