Re: [PATCH] rs6000: Check -+0 and NaN for smax/smin generation

[Jiufu Guo]

Segher Boessenkool  writes:

> Hi!
>
> On Thu, Mar 05, 2020 at 10:46:58AM +0800, Jiufu Guo wrote:
>> PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
>> relates to max of '-inf' and 'nan'. This regression occur on P9 which has
>> new instruction 'xsmaxcdp/xsmincdp'.
>> The similar issue also could be find on `a < b ? b : a` which is also
>> generated as `xsmaxcdp` under -O2 for P9. This instruction `xsmaxcdp`
>> more like C/C++ semantic (a>b?a:b). A testcase is added for this issue.
>> 
>> The following patch improve code to check -+0 and NaN before 'smax/smin' to
>> be generated for those cases.
>
>> -  else if (rtx_equal_p (op1, true_cond) && rtx_equal_p (op0, false_cond))
>> +  /* Only when -fno-signed-zeros and -ffinite_math_only are in effect,
>> + `op0 < op1 ? op1 : op0` works like `op1 > op0 ? op1 : op0` which 
>> + could use smax;
>> + `op0 > op1 ? op1 : op0` works like `op1 < op0 ? op1 : op0` which
>> + could use smin.  */
>> +  else if (rtx_equal_p (op1, true_cond) && rtx_equal_p (op0, false_cond)
>> +   && (flag_finite_math_only && !flag_signed_zeros))
>>  max_p = !max_p;
>
> I know I asked for it, but should this use HONOR_NANS (compare_mode)
> instead?  Infinities will work fine?  Just NaNs and zeros won't.
HONOR_NANS(mode) is `MODE_HAS_NANS (mode) && !flag_finite_math_only`.
We know the mode is SF or DF.  Both maybe ok for current code.

I agree with you HONOR_NANS would be better, it is more generic for
front-end, gimple and rtl.  And rs6000_emit_p9_fp_minmax maybe called
without checking mode in future code, in this case HONOR_NANS is
better.

I updated the code as:
```
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index f34e1ba70c6..b057f689b56 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -14836,7 +14836,11 @@ rs6000_emit_p9_fp_minmax (rtx dest, rtx op, rtx
true_cond, rtx false_cond)
   if (rtx_equal_p (op0, true_cond) && rtx_equal_p (op1, false_cond))
;

-  else if (rtx_equal_p (op1, true_cond) && rtx_equal_p (op0,
   false_cond))
   +  /* Only when NaNs and signed-zeros are not in effect, smax could be
   + used for `op0 < op1 ? op1 : op0`, and smin could be used for
   + `op0 > op1 ? op1 : op0`.  */
   +  else if (rtx_equal_p (op1, true_cond) && rtx_equal_p (op0, false_cond)
   +  && !HONOR_NANS (compare_mode) &&
   !HONOR_SIGNED_ZEROS(compare_mode))
max_p = !max_p;

   else
```
This code works fine. I'm going to submit it.

Thanks!
Jiufu Guo

>
> Okay for trunk with that change (if it works :-) )  Thanks!
>
>
> Segher

Re: [PATCH] [rs6000] Fix a wrong GC issue

[binbin]

Hi,

On 2020/3/9 下午10:32, Segher Boessenkool wrote:

Hi!

On Mon, Mar 09, 2020 at 01:58:01PM +0800, binbin wrote:

2020-03-09  Bin Bin Lv  

* config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,
builtin_mode_to_type[MAX_MACHINE_MODE][2]): Remove the declaration.


Just write "builtin_mode_to_type", nothing []?  Writing down the
dimensions here doesn't add anything, just is a bit noisy: you normally
put just the name here.


OK, modified.  Thanks.




* config/rs6000/rs6000.c (altivec_builtin_mask_for_load,
builtin_mode_to_type[MAX_MACHINE_MODE][2]): Remove the GTY(())
declaration and add the definition.


The definitions were already there, so lose the second part of this?


OK, removed.  Thanks.




diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 1697186..724085b 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -2490,6 +2490,8 @@ extern GTY(()) tree rs6000_builtin_types[RS6000_BTI_MAX];
  extern GTY(()) tree rs6000_builtin_decls[RS6000_BUILTIN_COUNT];
  
  #ifndef USED_FOR_TARGET

+extern GTY(()) tree builtin_mode_to_type[MAX_MACHINE_MODE][2];
+extern GTY(()) tree altivec_builtin_mask_for_load;


Add a newline here please?


OK, added a newline.  Thanks.




  /* A C structure for machine-specific, per-function data.
 This is added to the cfun structure.  */
  typedef struct GTY(()) machine_function


Okay for trunk with those tweaks.  Thanks!


Segher

gcc/ChangeLog

2020-03-10  Bin Bin Lv  

* config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,
builtin_mode_to_type): Remove the declaration.
* config/rs6000/rs6000.h (altivec_builtin_mask_for_load,
builtin_mode_to_type): Add an extern GTY(()) declaration.
* config/rs6000/rs6000.c (altivec_builtin_mask_for_load,
builtin_mode_to_type): Remove the GTY(()) declaration.
---
 gcc/config/rs6000/rs6000-internal.h | 2 --
 gcc/config/rs6000/rs6000.c  | 4 ++--
 gcc/config/rs6000/rs6000.h  | 3 +++
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-internal.h 
b/gcc/config/rs6000/rs6000-internal.h
index a23e956..d331b9e 100644
--- a/gcc/config/rs6000/rs6000-internal.h
+++ b/gcc/config/rs6000/rs6000-internal.h
@@ -187,7 +187,5 @@ extern bool rs6000_passes_long_double;
 extern bool rs6000_passes_vector;
 extern bool rs6000_returns_struct;
 extern bool cpu_builtin_p;
-extern GTY(()) tree builtin_mode_to_type[MAX_MACHINE_MODE][2];
-extern GTY(()) tree altivec_builtin_mask_for_load;
 
 #endif
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 9910b27..0faf44b 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -99,7 +99,7 @@
 #endif
 
 /* Support targetm.vectorize.builtin_mask_for_load.  */
-GTY(()) tree altivec_builtin_mask_for_load;
+tree altivec_builtin_mask_for_load;
 
 #ifdef USING_ELFOS_H
 /* Counter for labels which are to be placed in .fixup.  */
@@ -196,7 +196,7 @@ enum reg_class rs6000_constraints[RS6000_CONSTRAINT_MAX];
 int rs6000_vector_align[NUM_MACHINE_MODES];
 
 /* Map selected modes to types for builtins.  */
-GTY(()) tree builtin_mode_to_type[MAX_MACHINE_MODE][2];
+tree builtin_mode_to_type[MAX_MACHINE_MODE][2];
 
 /* What modes to automatically generate reciprocal divide estimate (fre) and
reciprocal sqrt (frsqrte) for.  */
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 1697186..79b3dd6 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -2490,6 +2490,9 @@ extern GTY(()) tree rs6000_builtin_types[RS6000_BTI_MAX];
 extern GTY(()) tree rs6000_builtin_decls[RS6000_BUILTIN_COUNT];
 
 #ifndef USED_FOR_TARGET
+extern GTY(()) tree builtin_mode_to_type[MAX_MACHINE_MODE][2];
+extern GTY(()) tree altivec_builtin_mask_for_load;
+
 /* A C structure for machine-specific, per-function data.
This is added to the cfun structure.  */
 typedef struct GTY(()) machine_function
-- 
1.8.3.1

Re: [PATCH] Backport to gcc-9: PR92398: Fix testcase failure of pr72804.c

[luoxhu]

On 2020/3/10 05:28, Segher Boessenkool wrote:

On Thu, Mar 05, 2020 at 02:21:58AM -0600, luo...@linux.ibm.com wrote:

From: Xionghu Luo 

Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.


No changes were needed?


Yes, no conflicts of the patch and instruction counts are same with
master.  Committed in r9-8357(85c08558c66dd8e2000a4ad282ca03368028fce3).


Thanks
Xionghu




Tested pass on P9/P8/P7, ok to commit?


Yes, okay for 9.  Thanks!


Segher



2020-03-05  Luo Xiong Hu  

backport from master.
PR testsuite/94036

2019-12-02  Luo Xiong Hu  

PR testsuite/92398
* gcc.target/powerpc/pr72804.c: Split the store function to...
* gcc.target/powerpc/pr92398.h: ... this one.  New.
* gcc.target/powerpc/pr92398.p9+.c: New.
* gcc.target/powerpc/pr92398.p9-.c: New.
* lib/target-supports.exp (check_effective_target_p8): New.
(check_effective_target_p9+): New.

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma]

On 2020-03-10 01:25, Segher Boessenkool wrote:
> On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote:
>> On 2020-03-09 19:01, Segher Boessenkool wrote:
>>> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
 int foo = 0
 try
   {
 asm volatile ("..." : "=r" (foo));
   }
 catch (...whatever...)
   {
 foo should be still zero, but SSA doesn't have the correct use 
 here
   }

 that means the compiler really assumes the asm will populate the outputs
 even when it throws.
>>>
>>> How is memory any different here?  In both cases you do not know if it
>>> is the old value or some new value in foo, after it threw an exception.
>>
>> If foo were a memory operand, the compiler makes no assumptions about
>> its value.  When you reference it in the catch block it is always read
>> back from memory.  Only register operands are clobbered and retain
>> their previous value.  If you compile such an example with -O3, you'll
>> see that the initial "int foo = 0;" is eliminated from the normal code
>> path.  It is only set to 0 in the catch block.
> 
> My question is *why* that is, and/or what in our code makes that so :-)
> 
> 
> Segher

The code I added in tree-eh.c does that.  Register outputs are assigned
to a temporary variable, which is discarded when the asm throws.  As I
said it's not possible to do this for memory operands too.  So, if this
behavior should be consistent for both types of operands, then you'd
have to assume that register outputs are valid after throwing.

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma]

On 2020-03-09 23:10, Segher Boessenkool wrote:
> Hi!
> 
> On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote:
>> There is also still the question of whether non-volatile asms should be
>> allowed to throw or not.  I don't know if that should be discussed here
>> or on the PR.
> 
> I think you should just allow it.  But almost always an asm that can
> throw *should* be volatile, or else the compiler might optimise it away
> in unexpected cases, etc.

I do think that allowing it for all asms is the best option.  My
initial idea was that the compiler could be made to expect exceptions
only from asms that take memory operands, but after giving that some
more thought, I don't think it's feasible.  So either allow all asms to
throw, or restrict this to volatile only.  Personally I'm in favor of
the former.  If an asm could throw, but does otherwise not have any
side effects or useful outputs, then it should be moved or optimized
away.

However I don't know if there is any performance cost associated with
this.  It is generally said that exceptions don't have any runtime
overhead if you don't throw them, I don't know if that is the full
story.  If certain optimizations are disabled for throwing statements,
then I expect there would be some resistance to this proposal.

Re: c: ignore initializers for elements of variable-size types [PR93577]

[Joseph Myers]

On Mon, 9 Mar 2020, Christophe Lyon wrote:

> Hi Joseph,
> 
> I've noticed that your patch introduces regressions on aarch64:
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> -march=armv8.2-a+sve  (test for errors, line 33)
> we now get
> /gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c:33:44:
> error: empty scalar initializer
> while we expect dg-error {initializer element is not constant}
> 
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> -march=armv8.2-a+sve  (test for errors, line 85)
> we no longer emit dg-error {empty scalar initializer }
> 
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> -march=armv8.2-a+sve (test for excess errors)
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> -march=armv8.2-a+sve  (test for errors, line 85)
> we no longer emit dg-error {empty scalar initializer }
> 
> Since the compiler did not ICE before your patch, is that new
> behaviour expected (and the tests need an update), or is that a
> problem with the patch?

Where there has already been an error about the type of an initializer, 
it's expected that some other errors about the value of that initializer 
will disappear.  So I think the cases where a previously expected error 
has disappeared are cases where the tests need an update; they already 
expect an error for the type.

That leaves the case where you report that "empty scalar initializer" has 
appeared.  That seems like a bug.  Maybe some SVE case means 
process_init_element is ignoring something in an initializer for an SVE 
type that did not in fact result in the variable-size error from 
digest_init?  Is the "empty scalar initializer" error coming from the 
compound literal on line 33, as opposed to the variable initialized on 
that line?

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

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[Segher Boessenkool]

On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote:
> On 2020-03-09 19:01, Segher Boessenkool wrote:
> > On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
> >> int foo = 0
> >> try
> >>   {
> >> asm volatile ("..." : "=r" (foo));
> >>   }
> >> catch (...whatever...)
> >>   {
> >> foo should be still zero, but SSA doesn't have the correct use 
> >> here
> >>   }
> >>
> >> that means the compiler really assumes the asm will populate the outputs
> >> even when it throws.
> > 
> > How is memory any different here?  In both cases you do not know if it
> > is the old value or some new value in foo, after it threw an exception.
> 
> If foo were a memory operand, the compiler makes no assumptions about
> its value.  When you reference it in the catch block it is always read
> back from memory.  Only register operands are clobbered and retain
> their previous value.  If you compile such an example with -O3, you'll
> see that the initial "int foo = 0;" is eliminated from the normal code
> path.  It is only set to 0 in the catch block.

My question is *why* that is, and/or what in our code makes that so :-)


Segher

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

[Jason Merrill]

On 3/9/20 5:39 PM, Martin Sebor wrote:

On 3/9/20 1:40 PM, Jason Merrill wrote:

On 3/9/20 12:31 PM, Martin Sebor wrote:

On 2/28/20 1:24 PM, Jason Merrill wrote:

On 2/28/20 12:45 PM, Martin Sebor wrote:

On 2/28/20 9:58 AM, Jason Merrill wrote:

On 2/24/20 6:58 PM, Martin Sebor wrote:

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also somewhat improves the 
detection

of both issues in template declarations (though more work is still
needed there).



+ a new entry for it and return unless it's a declaration
+ involving a template that may need to be diagnosed by
+ -Wredundant-tags.  */
   *rdl = class_decl_loc_t (class_key, false, def_p);
-  return;
+  if (TREE_CODE (decl) != TEMPLATE_DECL)
+    return;


How can the first appearance of a class template be redundant?


I'm not sure I correctly understand the question.  The comment says
"involving a template" (i.e., not one of the first declaration of
a template).  The test case that corresponds to this test is:

   template  struct S7 { };
   struct S7 s7v;  // { dg-warning "\\\[-Wredundant-tags" }

where DECL is the TEPLATE_DECL of S7.

As I mentioned, more work is still needed to handle templates right
because some redundant tags are still not diagnosed.  For example:

   template  struct S7 { };
   template 
   using U = struct S7;   // missing warning


When we get here for an instance of a template, it doesn't make 
sense to treat it as a new type.


If decl is a template and type_decl is an instance of that template, 
do we want to (before the lookup) change type_decl to the template 
or the corresponding generic TYPE_DECL, which should already be in 
the table?


I'm struggling with how to do this.  Given type (a RECORD_TYPE) and
type_decl (a TEMPLATE_DECL) representing the use of a template, how
do I get the corresponding template (or its explicit or partial
specialization) in the three cases below?

   1) Instance of the primary:
  template  class A;
  struct A a;

   2) Instance of an explicit specialization:
  template  class B;
  template <> struct B;
  class B b;

   3) Instance of a partial specialization:
  template  class C;
  template  struct C;
  class C c;

By trial and (lots of) error I figured out that in both (1) and (2),
but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns
the template's type_decl.

Is there some function to call to get it in (3), or even better,
in all three cases?


I think you're looking for most_general_template.


I don't think that's quite what I'm looking for.  At least it doesn't
return the template or its specialization in all three cases above.


Ah, true, that function stops at specializations.  Oddly, I don't think 
there's currently a similar function that looks through them.  You could 
create one that does a simple loop through DECL_TI_TEMPLATE like 
is_specialization_of.



In (2) and (3) it won't distinguish between specializations of B or
C on different types.  In (2), the function returns the same result
for both:

   template <> struct B;
   template <> struct B;

In (3), it similarly returns the same result for both of

   template  struct C;
   template  struct C;

even though they are declarations of distinct types.



Jason

Re: [PATCH v2] c++: Fix convert_like in template [PR91465, PR93870, PR92031]

[Jason Merrill]

On 3/9/20 7:32 PM, Marek Polacek wrote:

On Mon, Mar 02, 2020 at 05:50:01PM -0500, Jason Merrill wrote:

On 2/29/20 2:32 PM, Marek Polacek wrote:

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create _EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create _EXPR <0>.

And so on.  I'd like to fix it once and for all.  I wanted something
that fixes all the existing cases, removes the ugly check in
convert_nontype_argument, and something suitable for stage4.  I.e.,
I didn't implement any cleanups suggested in
 regarding
the pattern in e.g. build_explicit_specifier.


Hmm, it seems to me that addressing that pattern is an important part of
fixing this once and for all.


The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.  Is that something
that convert_like_real shouldn't do?
perform_direct_initialization_if_possible and perform_implicit_conversion_flags
can also create an IMPLICIT_CONV_EXPR.


This seems like a reasonable approach.


Great.


Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.  A problem with that is that now
we may instantiate something twice in a row (?).


Right, and we must not do that.


Ack.


Handling all of it in
build_converted_constant_expr won't be that straightforward because we
sometimes call cxx_constant_value to give errors, or use manifestly_const_eval
which should be honored.


Fair enough.  The alternative is ensuring that it's OK to call
build_converted_constant_expr when processing_template_decl is true, and
that the result in that case is still template trees.  I think that's what
you are doing.

With this approach, we can change

   expr = instantiate_non_dependent_expr_sfinae (expr, complain);
   /* Don't let convert_like_real create more template codes.  */
   processing_template_decl_sentinel s;
   expr = build_converted_constant_bool_expr (expr, complain);
   expr = cxx_constant_value (expr);

to

   expr = build_converted_constant_bool_expr (expr, complain);
   expr = instantiate_non_dependent_expr_sfinae (expr, complain);
   expr = cxx_constant_value (expr);

Yes?


Yes, that seems to work.  Changed in this patch per the above.


--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7383,6 +7383,12 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
 {
struct z_candidate *cand = convs->cand;
+   /* Creating _EXPR<> in a template breaks when substituting,
+  and creating a CALL_EXPR in a template breaks in finish_call_expr
+  so use an IMPLICIT_CONV_EXPR for this conversion.  */
+   if (processing_template_decl)
+ return build1 (IMPLICIT_CONV_EXPR, totype, expr);
+
if (cand == NULL)
  /* We chose the surrogate function from add_conv_candidate, now we
 actually need to build the conversion.  */
@@ -7760,6 +7766,12 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
expr = convert_bitfield_to_declared_type (expr);
expr = fold_convert (type, expr);
  }
+
+   /* Creating _EXPR<> in a template would break when
+  tsubsting the expression, so use an IMPLICIT_CONV_EXPR
+  instead.  */
+   if (processing_template_decl)
+ return build1 (IMPLICIT_CONV_EXPR, totype, expr);
expr = build_target_expr_with_type (expr, type, complain);
  }


Don't you need the same thing for ck_list, ck_aggr, ck_base?  Is there a
reason not to do this in one place for anything other than ck_identity, at
least if a class type is involved?


I didn't think I needed it because it didn't look like we might create either
_EXPR or CALL_EXPR there.  But maybe it'd be safer to do it even for
ck_list, ck_aggr, ck_base, so changed.

But the ck_ref_bind hunk had to stay: we can create a TARGET_EXPR even when
there's no class involved in the conversion, e.g. converting and integer to
a reference type, when a temporary is needed.


diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index e3f4b435a49..d04b042f880 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10281,8 +10281,8 @@ 

Re: [PATCH v2] c++: Fix convert_like in template [PR91465, PR93870, PR92031]

[Marek Polacek]

On Mon, Mar 02, 2020 at 05:50:01PM -0500, Jason Merrill wrote:
> On 2/29/20 2:32 PM, Marek Polacek wrote:
> > The point of this patch is to fix the recurring problem of trees
> > generated by convert_like while processing a template that break when
> > substituting.  For instance, when convert_like creates a CALL_EXPR
> > while in a template, substituting such a call breaks in finish_call_expr
> > because we have two 'this' arguments.  Another problem is that we
> > can create _EXPR<> and then fail when substituting because we're
> > taking the address of an rvalue.  I've analyzed some of the already fixed
> > PRs and also some of the currently open ones:
> > 
> > In c++/93870 we create EnumWrapper::operator E(~(E)).
> > In c++/87145 we create S::operator int (&{N}).
> > In c++/92031 we create _EXPR <0>.
> > 
> > And so on.  I'd like to fix it once and for all.  I wanted something
> > that fixes all the existing cases, removes the ugly check in
> > convert_nontype_argument, and something suitable for stage4.  I.e.,
> > I didn't implement any cleanups suggested in
> >  regarding
> > the pattern in e.g. build_explicit_specifier.
> 
> Hmm, it seems to me that addressing that pattern is an important part of
> fixing this once and for all.
> 
> > The gist of the problem is when convert_like_real creates a call for
> > a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
> > use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
> > actual conversion, we only need it's result type.  Is that something
> > that convert_like_real shouldn't do?
> > perform_direct_initialization_if_possible and 
> > perform_implicit_conversion_flags
> > can also create an IMPLICIT_CONV_EXPR.
> 
> This seems like a reasonable approach.

Great.

> > Given the change above, build_converted_constant_expr can return an
> > IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
> > maybe_constant_value to deal with that.  A problem with that is that now
> > we may instantiate something twice in a row (?).
> 
> Right, and we must not do that.

Ack.

> > Handling all of it in
> > build_converted_constant_expr won't be that straightforward because we
> > sometimes call cxx_constant_value to give errors, or use 
> > manifestly_const_eval
> > which should be honored.
> 
> Fair enough.  The alternative is ensuring that it's OK to call
> build_converted_constant_expr when processing_template_decl is true, and
> that the result in that case is still template trees.  I think that's what
> you are doing.
> 
> With this approach, we can change
> 
>   expr = instantiate_non_dependent_expr_sfinae (expr, complain);
>   /* Don't let convert_like_real create more template codes.  */
>   processing_template_decl_sentinel s;
>   expr = build_converted_constant_bool_expr (expr, complain);
>   expr = cxx_constant_value (expr);
> 
> to
> 
>   expr = build_converted_constant_bool_expr (expr, complain);
>   expr = instantiate_non_dependent_expr_sfinae (expr, complain);
>   expr = cxx_constant_value (expr);
> 
> Yes?

Yes, that seems to work.  Changed in this patch per the above.

> > --- a/gcc/cp/call.c
> > +++ b/gcc/cp/call.c
> > @@ -7383,6 +7383,12 @@ convert_like_real (conversion *convs, tree expr, 
> > tree fn, int argnum,
> > {
> > struct z_candidate *cand = convs->cand;
> > +   /* Creating _EXPR<> in a template breaks when substituting,
> > +  and creating a CALL_EXPR in a template breaks in finish_call_expr
> > +  so use an IMPLICIT_CONV_EXPR for this conversion.  */
> > +   if (processing_template_decl)
> > + return build1 (IMPLICIT_CONV_EXPR, totype, expr);
> > +
> > if (cand == NULL)
> >   /* We chose the surrogate function from add_conv_candidate, now we
> >  actually need to build the conversion.  */
> > @@ -7760,6 +7766,12 @@ convert_like_real (conversion *convs, tree expr, 
> > tree fn, int argnum,
> > expr = convert_bitfield_to_declared_type (expr);
> > expr = fold_convert (type, expr);
> >   }
> > +
> > +   /* Creating _EXPR<> in a template would break when
> > +  tsubsting the expression, so use an IMPLICIT_CONV_EXPR
> > +  instead.  */
> > +   if (processing_template_decl)
> > + return build1 (IMPLICIT_CONV_EXPR, totype, expr);
> > expr = build_target_expr_with_type (expr, type, complain);
> >   }
> 
> Don't you need the same thing for ck_list, ck_aggr, ck_base?  Is there a
> reason not to do this in one place for anything other than ck_identity, at
> least if a class type is involved?

I didn't think I needed it because it didn't look like we might create either
_EXPR or CALL_EXPR there.  But maybe it'd be safer to do it even for
ck_list, ck_aggr, ck_base, so changed.

But the ck_ref_bind hunk had to stay: we can create a TARGET_EXPR even when
there's no class involved in the conversion, e.g. converting and integer to
a 

[committed] libstdc++: Handle type-changing path concatenations (PR 94063)

[Jonathan Wakely]

The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.

For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".

Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.

This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated. That can be fixed later though.

PR libstdc++/94063
* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge to
handle concatenations that change the type of the first component.
(path::operator+=(basic_string_view)): Likewise.
* testsuite/27_io/filesystem/path/concat/94063.cc: New test.

Tested x86_64-pc-linux-gnu, x86_64-w64-mingw32 and x86_64-pc-cygwin.

Committed to master.

I'm very grateful to MetaNova on #cygwin for giving me access to a
machine for Cygwin testing.

commit ea182fe63634bb5b7913b3f1b6846e1900c5e0c4
Author: Jonathan Wakely 
Date:   Mon Mar 9 23:22:57 2020 +

libstdc++: Handle type-changing path concatenations (PR 94063)

The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.

For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".

Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.

This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated. That can be fixed later though.

PR libstdc++/94063
* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge to
handle concatenations that change the type of the first component.
(path::operator+=(basic_string_view)): Likewise.
* testsuite/27_io/filesystem/path/concat/94063.cc: New test.

diff --git a/libstdc++-v3/src/c++17/fs_path.cc 
b/libstdc++-v3/src/c++17/fs_path.cc
index 73071d8d052..5ff17741f81 100644
--- a/libstdc++-v3/src/c++17/fs_path.cc
+++ b/libstdc++-v3/src/c++17/fs_path.cc
@@ -852,6 +852,26 @@ path::operator+=(const path& p)
   return *this;
 }
 
+#if _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  if (_M_type() == _Type::_Root_name
+  || (_M_type() == _Type::_Filename && _M_pathname.size() == 1))
+{
+  // Handle path("C") += path(":") and path("C:") += path("/x")
+  // FIXME: do this more efficiently
+  *this = path(_M_pathname + p._M_pathname);
+  return *this;
+}
+#endif
+#if SLASHSLASH_IS_ROOTNAME
+  if (_M_type() == _Type::_Root_dir)
+{
+  // Handle path("/") += path("/x") and path("//") += path("x")
+  // FIXME: do this more efficiently
+  *this = path(_M_pathname + p._M_pathname);
+  return *this;
+}
+#endif
+
   const auto orig_pathlen = _M_pathname.length();
   const auto orig_type = _M_type();
   const auto orig_size = _M_cmpts.size();
@@ -1038,6 +1058,26 @@ path::_M_concat(basic_string_view s)
   return;
 }
 
+#if _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  if (_M_type() == _Type::_Root_name
+  || (_M_type() == _Type::_Filename && _M_pathname.size() == 1))
+{
+  // Handle path("C") += ":" and path("C:") += "/x"
+  // FIXME: do this more efficiently
+  *this = path(_M_pathname + string_type(s));
+  return;
+}
+#endif
+#if SLASHSLASH_IS_ROOTNAME
+  if (_M_type() == _Type::_Root_dir)
+{
+  // Handle path("/") += "/x" and path("//") += "x"
+  // FIXME: do this more efficiently
+  *this = path(_M_pathname + string_type(s));
+  return;
+}
+#endif
+
   const auto orig_pathlen = _M_pathname.length();
   const auto orig_type = _M_type();
   const auto orig_size = _M_cmpts.size();
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/concat/94063.cc 

[PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures

[Patrick Palka]

This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend
which controls how deeply we replay errors when diagnosing a constraint
satisfaction failure.  The default is -fconcepts-diagnostics-depth=1 which
diagnoses only the topmost constraint satisfaction failure and is consistent
with our behavior before this patch.  By increasing this flag's value, the user
can control how deeply they want the compiler to explain a constraint
satisfaction error.

For example, if the unsatisfied constraint is a disjunction, then the default
behavior is to just say "no branch in the disjunction is satisfied", but with
-fconcepts-diagnostics-depth=2 we will additionally replay and diagnose the
error in each branch of the disjunction.  And if the unsatisfied constraint is a
requires expression, then we will replay the error in the requires expression,
etc.  This proceeds recursively until there is nothing more to replay or we
reached the exceeded the maximum depth specified by the flag.

Implementation wise, this patch essentially just uncomments the existing
commented-out code that performs the error-replaying, adding logic to keep track
of the current replay depth along the way.  Besides that, there is a new routine
collect_operands_of_disjunction which flattens a disjunction and collects all of
its operands into a vector.

Here are some examples of diagnostics with the two patches in this series.

For the simple test case in which we call ranges::begin() on something that's
not a range:

#include 

struct S { } s;
auto x = std::ranges::begin(s);

we get the following diagnostics with -fconcepts-diagnostics-depth={1,2,3}
respectively:

 https://pppalka.github.io/ranges-begin-depth-1.html
 https://pppalka.github.io/ranges-begin-depth-2.html
 https://pppalka.github.io/ranges-begin-depth-3.html

And for the new test g++.dg/concepts/diagnostic5.C, we get:

https://pppalka.github.io/diagnostic5-depth-1.html
https://pppalka.github.io/diagnostic5-depth-2.html
https://pppalka.github.io/diagnostic5-depth-3.html
https://pppalka.github.io/diagnostic5-depth-4.html

The extra diagnostics enabled by this flag are at times longer than they need to
be (e.g.  "the operand is_array_v<...> is unsatisfied because \n the expression
is_array_v<...> [with ...] evaluated to false") and not immediately easy to
follow (especially when there are nested disjunctions), but the transparency
provided by these optional diagnostics seems to be pretty helpful in practice.

Does this seem like a sensible approach?  Thoughts and ideas for improvement
welcome.  Wording and naming suggestions would be much appreciated.

gcc/c-family/ChangeLog:

* c.opt: Add -fconcepts-diagnostics-depth.

gcc/cp/ChangeLog:

* constraint.cc (finish_constraint_binary_op): Set the location of EXPR
as well as its range, because build_x_binary_op doesn't always do so.
(current_constraint_diagnosis_depth): New.
(concepts_diagnostics_max_depth_exceeded_p): New.
(collect_operands_of_disjunction): New.
(satisfy_disjunction): When diagnosing a satisfaction failure, maybe
replay each branch of the disjunction, subject to the current diagnosis
depth.
(diagnose_valid_expression): When diagnosing a satisfaction failure,
maybe replay the substitution error, subject to the current diagnosis
recursion.
(diagnose_valid_type): Likewise.
(diagnose_nested_requiremnet): Likewise.
(diagnosing_failed_constraint::diagnosing_failed_constraint): Increment
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::~diagnosing_failed_constraint): Decrement
current_constraint_diagnosis_depth when diagnosing.
(diagnose_constraints): Don't diagnose if concepts_diagnostics_max_depth
is 0.  Emit a one-off note to increase -fconcepts-diagnostics-depth if
the limit was exceeded.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic2.C: Expect "no operand" instead of
"neither operand".
* g++.dg/concepts/diagnostic5.C: New test.
---
 gcc/c-family/c.opt  |   4 +
 gcc/cp/constraint.cc| 146 +---
 gcc/testsuite/g++.dg/concepts/diagnostic2.C |   2 +-
 gcc/testsuite/g++.dg/concepts/diagnostic5.C |  46 ++
 4 files changed, 177 insertions(+), 21 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic5.C

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 1cd585fa71d..97ef488931d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1453,6 +1453,10 @@ fconcepts-ts
 C++ ObjC++ Var(flag_concepts_ts) Init(0)
 Enable certain features present in the Concepts TS.
 
+fconcepts-diagnostics-depth=
+C++ ObjC++ Joined RejectNegative UInteger Var(concepts_diagnostics_max_depth) 
Init(1)
+Specify maximum error replay depth during recursive diagnosis of a constraint 

[PATCH 2/2] c++: Respect current_constraint_diagnosis_depth in diagnose_compound_requirement

[Patrick Palka]

The first patch tries to avoid changing our current default diagnostics.  But
for the sake of consistency we arguably should also respect
current_constraint_diagnosis_depth in diagnose_compound_requirement() like we do
in the other error-replaying diagnostic routine.  But doing so would be a change
to our default diagnostics behavior, so the change has been split out into this
separate patch for separate consideration.

gcc/cp/ChangeLog:

* constraint.cc (diagnose_compound_requirement): When diagnosing a
compound requirement, maybe replay the satisfaction failure, subject to
the current diagnosis depth.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic1.C: Pass -fconcepts-diagnostics-depth=2.
* g++.dg/concepts/diagnostic5.C: Adjust expected diagnostics.
* g++.dg/cpp2a/concepts-requires5.C: Pass
-fconcepts-diagnostics-depth=2.
---
 gcc/cp/constraint.cc  | 36 ++-
 gcc/testsuite/g++.dg/concepts/diagnostic1.C   |  1 +
 gcc/testsuite/g++.dg/concepts/diagnostic5.C   |  5 +--
 gcc/testsuite/g++.dg/cpp2a/concepts-iconv1.C  |  1 +
 .../g++.dg/cpp2a/concepts-requires5.C |  2 +-
 5 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c5e3d64daa6..2ad82937c7e 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3282,20 +3282,38 @@ diagnose_compound_requirement (tree req, tree args, 
tree in_decl)
  if (!type_deducible_p (expr, type, placeholder, args, quiet))
{
  tree orig_expr = TREE_OPERAND (req, 0);
- inform (loc, "%qE does not satisfy return-type-requirement",
- orig_expr);
-
- /* Further explain the reason for the error.  */
- type_deducible_p (expr, type, placeholder, args, noisy);
+ if (current_constraint_diagnosis_depth
+ < concepts_diagnostics_max_depth)
+   {
+ inform (loc,
+ "%qE does not satisfy return-type-requirement, "
+ "because", orig_expr);
+ /* Further explain the reason for the error.  */
+ type_deducible_p (expr, type, placeholder, args, noisy);
+   }
+ else
+   {
+ inform (loc, "%qE does not satisfy return-type-requirement",
+ orig_expr);
+ concepts_diagnostics_max_depth_exceeded_p = true;
+   }
}
}
   else if (!expression_convertible_p (expr, type, quiet))
{
  tree orig_expr = TREE_OPERAND (req, 0);
- inform (loc, "cannot convert %qE to %qT", orig_expr, type);
-
- /* Further explain the reason for the error.  */
- expression_convertible_p (expr, type, noisy);
+ if (current_constraint_diagnosis_depth
+ < concepts_diagnostics_max_depth)
+   {
+ inform (loc, "cannot convert %qE to %qT because", orig_expr, 
type);
+ /* Further explain the reason for the error.  */
+ expression_convertible_p (expr, type, noisy);
+   }
+ else
+   {
+ inform (loc, "cannot convert %qE to %qT", orig_expr, type);
+ concepts_diagnostics_max_depth_exceeded_p = true;
+   }
}
 }
 }
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic1.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic1.C
index 7da08db2792..c6589e2e671 100644
--- a/gcc/testsuite/g++.dg/concepts/diagnostic1.C
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic1.C
@@ -1,6 +1,7 @@
 // PR c++/67159
 // { dg-do compile { target c++17_only } }
 // { dg-options "-fconcepts" }
+// { dg-additional-options "-fconcepts-diagnostics-depth=2" }
 
 template 
 concept bool SameAs = __is_same_as(T, U);
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic5.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic5.C
index 3c3b42f566c..734c7fb87a6 100644
--- a/gcc/testsuite/g++.dg/concepts/diagnostic5.C
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic5.C
@@ -4,8 +4,7 @@
 template
   concept c1 = requires { typename T::blah; };
 // { dg-message "satisfaction of .c1." "" { target *-*-* } .-1 }
-// { dg-message "satisfaction of .c1." "" { target *-*-* } .-2 }
-// { dg-message ".typename T::blah. is invalid" "" { target *-*-* } .-3 }
+// { dg-message ".typename T::blah. is invalid" "" { target *-*-* } .-2 }
 
 template
   concept c2 = requires (T x) { *x; };
@@ -27,8 +26,6 @@ template
   concept c5 = requires (T x) { {  } -> c1; };
 // { dg-message "satisfaction of .c5." "" { target *-*-* } .-1 }
 // { dg-message "in requirements with .char x." "" { target *-*-* } .-2 }
-// { dg-message "does not satisfy return-type-requirement" "" { target *-*-* } 
.-3 }
-// { dg-error "deduced expression type does not satisfy" "" { target *-*-* } 
.-4 }
 
 template
   requires (c1 || c2) || (c3 || c4) || c5 // { dg-message 

Re: [PATCH v2][gcc] libgccjit: handle long literals in playback::context::new_string_literal

[Andrea Corallo]

Hi all,

second version of the patch for the 200 characters limit for literal
strings addressing comments.

make check-jit is passing clean.

Best Regards
  Andrea

gcc/jit/ChangeLog
2020-??-??  Andrea Corallo  

* jit-playback.h
(gcc::jit::playback::context m_recording_ctxt): Remove
m_char_array_type_node field.
* jit-playback.c
(playback::context::context) Remove m_char_array_type_node from member
initializer list.
(playback::context::new_string_literal) Fix logic to handle string
length > 200.

gcc/testsuite/ChangeLog
2020-??-??  Andrea Corallo  

* jit.dg/all-non-failing-tests.h: Add test-long-string-literal.c.
* jit.dg/test-long-string-literal.c: New testcase.

diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index 904cc167a0c..074434a9f6b 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -322,7 +322,6 @@ private:
 
   auto_vec m_functions;
   auto_vec m_globals;
-  tree m_char_array_type_node;
   tree m_const_char_ptr;
 
   /* Source location handling.  */
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index da687002a72..d2c8bb4c154 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -88,7 +88,6 @@ playback::context::context (recording::context *ctxt)
   : log_user (ctxt->get_logger ()),
 m_recording_ctxt (ctxt),
 m_tempdir (NULL),
-m_char_array_type_node (NULL),
 m_const_char_ptr (NULL)
 {
   JIT_LOG_SCOPE (get_logger ());
@@ -670,9 +669,14 @@ playback::rvalue *
 playback::context::
 new_string_literal (const char *value)
 {
-  tree t_str = build_string (strlen (value), value);
-  gcc_assert (m_char_array_type_node);
-  TREE_TYPE (t_str) = m_char_array_type_node;
+  /* Compare with c-family/c-common.c: fix_string_type.  */
+  size_t len = strlen (value);
+  tree i_type = build_index_type (size_int (len));
+  tree a_type = build_array_type (char_type_node, i_type);
+  /* build_string len parameter must include NUL terminator when
+ building C strings.  */
+  tree t_str = build_string (len + 1, value);
+  TREE_TYPE (t_str) = a_type;
 
   /* Convert to (const char*), loosely based on
  c/c-typeck.c: array_to_pointer_conversion,
@@ -2701,10 +2705,6 @@ playback::context::
 replay ()
 {
   JIT_LOG_SCOPE (get_logger ());
-  /* Adapted from c-common.c:c_common_nodes_and_builtins.  */
-  tree array_domain_type = build_index_type (size_int (200));
-  m_char_array_type_node
-= build_array_type (char_type_node, array_domain_type);
 
   m_const_char_ptr
 = build_pointer_type (build_qualified_type (char_type_node,
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index 0272e6f846f..1b3d5618779 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -220,6 +220,13 @@
 #undef create_code
 #undef verify_code
 
+/* test-long-string-literal.c */
+#define create_code create_code_long_string_literal
+#define verify_code verify_code_long_string_literal
+#include "test-long-string-literal.c"
+#undef create_code
+#undef verify_code
+
 /* test-sum-of-squares.c */
 #define create_code create_code_sum_of_squares
 #define verify_code verify_code_sum_of_squares
diff --git a/gcc/testsuite/jit.dg/test-long-string-literal.c b/gcc/testsuite/jit.dg/test-long-string-literal.c
new file mode 100644
index 000..6caaa781c0b
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-long-string-literal.c
@@ -0,0 +1,54 @@
+#include 
+#include 
+#include 
+#include 
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+const char very_long_string[] =
+  "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
+  "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
+  "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
+  "abcabcabcabcabcabcabcabcabcabca";
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+  /* Build the test_fn.  */
+  gcc_jit_function *f =
+gcc_jit_context_new_function (
+  ctxt, NULL,
+  GCC_JIT_FUNCTION_EXPORTED,
+  gcc_jit_context_get_type(ctxt,
+			   GCC_JIT_TYPE_CONST_CHAR_PTR),
+"test_long_string_literal",
+0, NULL, 0);
+  gcc_jit_block *blk =
+gcc_jit_function_new_block (f, "init_block");
+
+  /* very_long_string is longer than 200 characters to specifically
+ check that the previous limitation no longer apply.  */
+
+  assert (sizeof (very_long_string) > 200);
+  gcc_jit_rvalue *res =
+gcc_jit_context_new_string_literal (ctxt, very_long_string);
+
+  gcc_jit_block_end_with_return (blk, NULL, res);
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+  typedef const char *(*fn_type) (void);
+  CHECK_NON_NULL (result);
+  fn_type test_long_string_literal =
+(fn_type)gcc_jit_result_get_code (result, "test_long_string_literal");
+  CHECK_NON_NULL (test_long_string_literal);
+
+  /* Call the 

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[Segher Boessenkool]

Hi!

On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote:
> The only question I have left now is if my proposed change to the
> documentation is acceptable or should be expanded/reworded.

I think it is fine.  It's easier to judge if you look fresh at it, in
my experience, so I might think differently at stage1 time ;-)

> There is also still the question of whether non-volatile asms should be
> allowed to throw or not.  I don't know if that should be discussed here
> or on the PR.

I think you should just allow it.  But almost always an asm that can
throw *should* be volatile, or else the compiler might optimise it away
in unexpected cases, etc.


Segher

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Pop, Sebastian via Gcc-patches]

Hi,

Please see attached the patches to add -moutline-atomics to the gcc-9 branch.
Tested on graviton2 aarch64-linux with bootstrap and
`make check` passes with no new fails.
Tested `make check` on glibc built with gcc-9 with and without 
"-moutline-atomics"
and CFLAGS=" -O2 -g -fno-stack-protector -U_FORTIFY_SOURCE".

Ok to commit to gcc-9 branch?

Does this mechanical `git am *.patch` require a copyright assignment?
I am still working with my employer on getting the FSF assignment signed.

Thanks,
Sebastian

PS: For gcc-8 backports there are 5 cleanup and improvement patches
that are needed for -moutline-atomics patches to apply cleanly.
Should these patches be back-ported in the same time as the flag patches,
or should I update the patches to apply to the older code base?
Here is the list of the extra patches:

From 77f33f44baf24c22848197aa80962c003dd7b3e2 Mon Sep 17 00:00:00 2001
From: Richard Henderson 
Date: Wed, 31 Oct 2018 09:29:29 +
Subject: [PATCH] aarch64: Simplify LSE cas generation

The cas insn is a single insn, and if expanded properly need not
be split after reload.  Use the proper inputs for the insn.

* config/aarch64/aarch64.c (aarch64_expand_compare_and_swap):
Force oldval into the rval register for TARGET_LSE; emit the compare
during initial expansion so that it may be deleted if unused.
(aarch64_gen_atomic_cas): Remove.
* config/aarch64/atomics.md (@aarch64_compare_and_swap_lse):
Change = to +r for operand 0; use match_dup for operand 2;
remove is_weak and mod_f operands as unused.  Drop the split
and merge with...
(@aarch64_atomic_cas): ... this pattern's output; remove.
(@aarch64_compare_and_swap_lse): Similarly.
(@aarch64_atomic_cas): Similarly.

From-SVN: r265656

From d400fda3a8c3330f77eb9d51874f5482d3819a9f Mon Sep 17 00:00:00 2001
From: Richard Henderson 
Date: Wed, 31 Oct 2018 09:42:39 +
Subject: [PATCH] aarch64: Improve cas generation

Do not zero-extend the input to the cas for subword operations;
instead, use the appropriate zero-extending compare insns.
Correct the predicates and constraints for immediate expected operand.

* config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): New.
(aarch64_split_compare_and_swap): Use it.
(aarch64_expand_compare_and_swap): Likewise.  Remove convert_modes;
test oldval against the proper predicate.
* config/aarch64/atomics.md (@atomic_compare_and_swap):
Use nonmemory_operand for expected.
(cas_short_expected_pred): New.
(@aarch64_compare_and_swap): Use it; use "rn" not "rI" to match.
(@aarch64_compare_and_swap): Use "rn" not "rI" for expected.
* config/aarch64/predicates.md (aarch64_plushi_immediate): New.
(aarch64_plushi_operand): New.

From-SVN: r265657

From 8f5603d363a4e0453d2c38c7103aeb0bdca85c4e Mon Sep 17 00:00:00 2001
From: Richard Henderson 
Date: Wed, 31 Oct 2018 09:47:21 +
Subject: [PATCH] aarch64: Improve swp generation

Allow zero as an input; fix constraints; avoid unnecessary split.

* config/aarch64/aarch64.c (aarch64_emit_atomic_swap): Remove.
(aarch64_gen_atomic_ldop): Don't call it.
* config/aarch64/atomics.md (atomic_exchange):
Use aarch64_reg_or_zero.
(aarch64_atomic_exchange): Likewise.
(aarch64_atomic_exchange_lse): Remove split; remove & from
operand 0; use aarch64_reg_or_zero for input; merge ...
(@aarch64_atomic_swp): ... this and remove.

From-SVN: r265659

From 7803ec5ee2a547043fb6708a08ddb1361ba91202 Mon Sep 17 00:00:00 2001
From: Richard Henderson 
Date: Wed, 31 Oct 2018 09:58:48 +
Subject: [PATCH] aarch64: Improve atomic-op lse generation

Fix constraints; avoid unnecessary split.  Drop the use of the atomic_op
iterator in favor of the ATOMIC_LDOP iterator; this is simplier and more
logical for ldclr aka bic.

* config/aarch64/aarch64.c (aarch64_emit_bic): Remove.
(aarch64_atomic_ldop_supported_p): Remove.
(aarch64_gen_atomic_ldop): Remove.
* config/aarch64/atomic.md (atomic_):
Fully expand LSE operations here.
(atomic_fetch_): Likewise.
(atomic__fetch): Likewise.
(aarch64_atomic__lse): Drop atomic_op iterator
and use ATOMIC_LDOP instead; use register_operand for the input;
drop the split and emit insns directly.
(aarch64_atomic_fetch__lse): Likewise.
(aarch64_atomic__fetch_lse): Remove.
(@aarch64_atomic_load): Remove.

From-SVN: r265660

From 53de1ea800db54b47290d578c43892799b66c8dc Mon Sep 17 00:00:00 2001
From: Richard Henderson 
Date: Wed, 31 Oct 2018 23:11:22 +
Subject: [PATCH] aarch64: Remove early clobber from ATOMIC_LDOP scratch

* config/aarch64/atomics.md (aarch64_atomic__lse):
The scratch register need not be early-clobber.  Document the reason
why we cannot use ST.

From-SVN: r265703





On 2/27/20, 12:06 

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

[Martin Sebor]

On 3/9/20 1:40 PM, Jason Merrill wrote:

On 3/9/20 12:31 PM, Martin Sebor wrote:

On 2/28/20 1:24 PM, Jason Merrill wrote:

On 2/28/20 12:45 PM, Martin Sebor wrote:

On 2/28/20 9:58 AM, Jason Merrill wrote:

On 2/24/20 6:58 PM, Martin Sebor wrote:

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also somewhat improves the detection
of both issues in template declarations (though more work is still
needed there).



+ a new entry for it and return unless it's a declaration
+ involving a template that may need to be diagnosed by
+ -Wredundant-tags.  */
   *rdl = class_decl_loc_t (class_key, false, def_p);
-  return;
+  if (TREE_CODE (decl) != TEMPLATE_DECL)
+    return;


How can the first appearance of a class template be redundant?


I'm not sure I correctly understand the question.  The comment says
"involving a template" (i.e., not one of the first declaration of
a template).  The test case that corresponds to this test is:

   template  struct S7 { };
   struct S7 s7v;  // { dg-warning "\\\[-Wredundant-tags" }

where DECL is the TEPLATE_DECL of S7.

As I mentioned, more work is still needed to handle templates right
because some redundant tags are still not diagnosed.  For example:

   template  struct S7 { };
   template 
   using U = struct S7;   // missing warning


When we get here for an instance of a template, it doesn't make sense 
to treat it as a new type.


If decl is a template and type_decl is an instance of that template, 
do we want to (before the lookup) change type_decl to the template or 
the corresponding generic TYPE_DECL, which should already be in the 
table?


I'm struggling with how to do this.  Given type (a RECORD_TYPE) and
type_decl (a TEMPLATE_DECL) representing the use of a template, how
do I get the corresponding template (or its explicit or partial
specialization) in the three cases below?

   1) Instance of the primary:
  template  class A;
  struct A a;

   2) Instance of an explicit specialization:
  template  class B;
  template <> struct B;
  class B b;

   3) Instance of a partial specialization:
  template  class C;
  template  struct C;
  class C c;

By trial and (lots of) error I figured out that in both (1) and (2),
but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns
the template's type_decl.

Is there some function to call to get it in (3), or even better,
in all three cases?


I think you're looking for most_general_template.


I don't think that's quite what I'm looking for.  At least it doesn't
return the template or its specialization in all three cases above.
In (2) and (3) it won't distinguish between specializations of B or
C on different types.  In (2), the function returns the same result
for both:

  template <> struct B;
  template <> struct B;

In (3), it similarly returns the same result for both of

  template  struct C;
  template  struct C;

even though they are declarations of distinct types.

What I missing?

Martin

Re: [PATCH] Backport to gcc-9: PR92398: Fix testcase failure of pr72804.c

[Segher Boessenkool]

On Thu, Mar 05, 2020 at 02:21:58AM -0600, luo...@linux.ibm.com wrote:
> From: Xionghu Luo 
> 
> Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.

No changes were needed?

> Tested pass on P9/P8/P7, ok to commit?

Yes, okay for 9.  Thanks!


Segher


>   2020-03-05  Luo Xiong Hu  
> 
>   backport from master.
>   PR testsuite/94036
> 
>   2019-12-02  Luo Xiong Hu  
> 
>   PR testsuite/92398
>   * gcc.target/powerpc/pr72804.c: Split the store function to...
>   * gcc.target/powerpc/pr92398.h: ... this one.  New.
>   * gcc.target/powerpc/pr92398.p9+.c: New.
>   * gcc.target/powerpc/pr92398.p9-.c: New.
>   * lib/target-supports.exp (check_effective_target_p8): New.
>   (check_effective_target_p9+): New.

Re: [PATCH] c++: Readd [LR]ROTATE_EXPR support to constexpr.c [PR94067]

[Jason Merrill]

On 3/6/20 7:57 AM, Jakub Jelinek wrote:

Hi!

Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c


OK.  It's unfortunate that we're folding twice here, but probably better 
to leave fixing that for GCC 11.



Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2020-03-06  Jakub Jelinek  

PR c++/94067
Revert
2019-10-11  Paolo Carlini  

* constexpr.c (cxx_eval_constant_expression): Do not handle
RROTATE_EXPR and LROTATE_EXPR.

* g++.dg/warn/Wconversion-pr94067.C: New test.

--- gcc/cp/constexpr.c.jj   2020-03-05 07:58:02.578137680 +0100
+++ gcc/cp/constexpr.c  2020-03-06 11:55:27.126682726 +0100
@@ -5730,6 +5730,8 @@ cxx_eval_constant_expression (const cons
  case MAX_EXPR:
  case LSHIFT_EXPR:
  case RSHIFT_EXPR:
+case LROTATE_EXPR:
+case RROTATE_EXPR:
  case BIT_IOR_EXPR:
  case BIT_XOR_EXPR:
  case BIT_AND_EXPR:
@@ -7853,6 +7855,8 @@ potential_constant_expression_1 (tree t,
  case MAX_EXPR:
  case LSHIFT_EXPR:
  case RSHIFT_EXPR:
+case LROTATE_EXPR:
+case RROTATE_EXPR:
  case BIT_IOR_EXPR:
  case BIT_XOR_EXPR:
  case BIT_AND_EXPR:
--- gcc/testsuite/g++.dg/warn/Wconversion-pr94067.C.jj  2020-03-06 
11:57:08.335191087 +0100
+++ gcc/testsuite/g++.dg/warn/Wconversion-pr94067.C 2020-03-06 
11:59:55.843722307 +0100
@@ -0,0 +1,9 @@
+// PR c++/94067
+// { dg-do compile }
+// { dg-options "-Wconversion" }
+
+static inline unsigned short
+swap (unsigned short x)
+{
+  return (x >> 8) | static_cast(x << 8);
+}

Jakub



s

Re: [PATCH] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

[Marek Polacek]

On Mon, Mar 09, 2020 at 04:25:00PM -0400, Marek Polacek wrote:
> On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote:
> > On 3/9/20 9:40 AM, Marek Polacek wrote:
> > > On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
> > > > On 3/9/20 8:58 AM, Jakub Jelinek wrote:
> > > > > On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
> > > > > > On 3/6/20 6:54 PM, Marek Polacek wrote:
> > > > > > > I got a report that building Chromium fails with the "modifying a 
> > > > > > > const
> > > > > > > object" error.  After some poking I realized it's a bug in GCC, 
> > > > > > > not in
> > > > > > > their codebase.
> > > > > > > 
> > > > > > > Much like with ARRAY_REFs, which can be const even though the 
> > > > > > > array
> > > > > > > itself isn't, COMPONENT_REFs can be const although neither the 
> > > > > > > object
> > > > > > > nor the field were declared const.  So let's dial down the 
> > > > > > > checking.
> > > > > > > Here the COMPONENT_REF was const because of the "const_cast > > > > > > U &>(m)"
> > > > > > > thing -- cxx_eval_component_reference then builds a COMPONENT_REF 
> > > > > > > with
> > > > > > > TREE_TYPE (t).
> > > > > > 
> > > > > > What is folding the const into the COMPONENT_REF?
> > > > > 
> > > > > cxx_eval_component_reference when it is called on
> > > > > ((const struct array *) this)->elems
> > > > > with /*lval=*/true and lval is true because we are evaluating
> > > > >  = (const int &) &((const struct array *) 
> > > > > this)->elems[VIEW_CONVERT_EXPR(n)];
> > > > 
> > > > Ah, sure.  We're pretty loose with cv-quals in the constexpr code in
> > > > general, so it's probably not worth trying to change that here.  Getting
> > > > back to the patch:
> > > 
> > > Yes, here the additional const was caused by a const_cast adding a const.
> > > 
> > > But this could also happen with wrapper functions like this one from
> > > __array_traits in std::array:
> > > 
> > >static constexpr _Tp&
> > >_S_ref(const _Type& __t, std::size_t __n) noexcept
> > >{ return const_cast<_Tp&>(__t[__n]); }
> > > 
> > > where the ref-to-const parameter added the const.
> > > 
> > > > > +  if (TREE_CODE (obj) == COMPONENT_REF)
> > > > > + {
> > > > > +   tree op1 = TREE_OPERAND (obj, 1);
> > > > > +   if (CP_TYPE_CONST_P (TREE_TYPE (op1)))
> > > > > + return true;
> > > > > +   else
> > > > > + {
> > > > > +   tree op0 = TREE_OPERAND (obj, 0);
> > > > > +   /* The LHS of . or -> might itself be a COMPONENT_REF.  */
> > > > > +   if (TREE_CODE (op0) == COMPONENT_REF)
> > > > > + op0 = TREE_OPERAND (op0, 1);
> > > > > +   return CP_TYPE_CONST_P (TREE_TYPE (op0));
> > > > > + }
> > > > > + }
> > > > 
> > > > Shouldn't this be a loop?
> > > 
> > > I don't think so, though my earlier patch had a call to
> > > 
> > > +static bool
> > > +cref_has_const_field (tree ref)
> > > +{
> > > +  while (TREE_CODE (ref) == COMPONENT_REF)
> > > +{
> > > +  if (CP_TYPE_CONST_P (TREE_TYPE (TREE_OPERAND (ref, 1
> > > +   return true;
> > > +  ref = TREE_OPERAND (ref, 0);
> > > +}
> > > +  return false;
> > > +}
> > 
> > > here.  A problem arised when I checked even the outermost expression 
> > > (which is not a
> > > field_decl), then I saw another problematical error.
> > > 
> > > The more outer fields are expected to be checked in subsequent calls to
> > > modifying_const_object_p in next iterations of the
> > > 
> > > 4459   for (tree probe = target; object == NULL_TREE; )
> > > 
> > > loop in cxx_eval_store_expression.
> > 
> > OK, but then why do you want to check two levels here rather than just one?
> 
> It's a hack to keep constexpr-tracking-const7.C working.  There we have
> 
>   b.a.c.d.n
> 
> wherein 'd' is const struct D, but 'n' isn't const.  Without the hack
> const_object_being_modified would be 'b.a.c.d', but due to the problem I
> desribed in the original mail[1] the constructor for D wouldn't have
> TREE_READONLY set.  With the hack const_object_being_modified will be
> 'b.a.c.d.n', which is of non-class type so we error:
> 
> 4710   if (!CLASS_TYPE_P (const_objtype))
> 4711 fail = true;
> 
> I could remove the hack and maybe XFAIL constexpr-tracking-const7.C if you
> want.  Unfortunately I wasn't aware of [1] when I added that feature and
> checking if the whole COMPONENT_REF is const seemed to be enough.
> 
> It's probably not a good idea to make this checking more strict at this
> stage.
> 
> [1] "While looking into this I noticed that we don't detect modifying a const
> object in certain cases like in
> .  That's because
> we never evaluate an X::X() CALL_EXPR -- there's none.  So there's no
> CONSTRUCTOR to set TREE_READONLY on.  No idea how to fix this, but it's
> likely something for GCC 11 anyway."

The testcase disappeared from Bugzilla, but it was

Re: [PATCH] drop weakref attribute on function definitions (PR 92799)

[Martin Sebor]

On 3/5/20 5:26 PM, Jeff Law wrote:

On Fri, 2020-02-14 at 15:41 -0700, Martin Sebor wrote:

Because attribute weakref introduces a kind of a definition, it can
only be applied to declarations of symbols that are not defined.  GCC
normally issues a warning when the attribute is applied to a defined
symbol, but PR 92799 shows that it misses some cases on which it then
leads to an ICE.

The ICE was introduced in GCC 4.5.  Prior to then, GCC accepted such
invalid definitions and silently dropped the weakref attribute.

The attached patch avoids the ICE while again dropping the invalid
attribute from the definition, except with the (now) usual warning.

Tested on x86_64-linux.

I also looked for code bases that make use of attribute weakref to
rebuild them as another test but couldn't find any.  (There are
a couple of instances in the Linux kernel but they look #ifdef'd
out).  Does anyone know of any that do use it that I could try to
build on Linux?

So you added this check

... || DECL_INITIAL (decl) != error_mark_node

Do you need to check that DECL_INITIAL is not NULL?  IIUC DECL_INITIAL in this
context is a tri-state.

NULL -- DECL is not a function definition
error_mark_node -- it was a function definition, but the body was free'd
everything else -- the function definition


I've only seen two values come up for a function declared weakref in
the test suite: error_mark_node and something with the TREE_CODE of
BLOCK (the block where the weakref function is used when it's also
explicitly defined in the code, and when the attribute is subsequently
diagnosed by the warning).

The weakref attribute provides a definition for a declaration that
is not a definition.  DECL_INITIAL is set to error_mark_node in
handle_alias_ifunc_attribute called (indirectly) from
handle_weakref_attribute.  So case 1 never comes up and cases 2 and
3 above are an error.  Once defined by the means of the attribute,
the function can be redeclared but its DECL_INITIAL is still
error_mark_node.

For DECL_INITIAL (decl) weakref variables DECL_INITIAL is set to null
(in this case GCC issues a warning and ignores the attribute).  I don't
know why functions have this special treatment and there's no comment
to explain.

Anyway, I don't have a problem adding the check but (as always) I'd
like to be able to test it.  Let me know if you know how, or what
you want me to do.

Martin

Re: [PATCH] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

[Marek Polacek]

On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote:
> On 3/9/20 9:40 AM, Marek Polacek wrote:
> > On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
> > > On 3/9/20 8:58 AM, Jakub Jelinek wrote:
> > > > On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
> > > > > On 3/6/20 6:54 PM, Marek Polacek wrote:
> > > > > > I got a report that building Chromium fails with the "modifying a 
> > > > > > const
> > > > > > object" error.  After some poking I realized it's a bug in GCC, not 
> > > > > > in
> > > > > > their codebase.
> > > > > > 
> > > > > > Much like with ARRAY_REFs, which can be const even though the array
> > > > > > itself isn't, COMPONENT_REFs can be const although neither the 
> > > > > > object
> > > > > > nor the field were declared const.  So let's dial down the checking.
> > > > > > Here the COMPONENT_REF was const because of the "const_cast > > > > > &>(m)"
> > > > > > thing -- cxx_eval_component_reference then builds a COMPONENT_REF 
> > > > > > with
> > > > > > TREE_TYPE (t).
> > > > > 
> > > > > What is folding the const into the COMPONENT_REF?
> > > > 
> > > > cxx_eval_component_reference when it is called on
> > > > ((const struct array *) this)->elems
> > > > with /*lval=*/true and lval is true because we are evaluating
> > > >  = (const int &) &((const struct array *) 
> > > > this)->elems[VIEW_CONVERT_EXPR(n)];
> > > 
> > > Ah, sure.  We're pretty loose with cv-quals in the constexpr code in
> > > general, so it's probably not worth trying to change that here.  Getting
> > > back to the patch:
> > 
> > Yes, here the additional const was caused by a const_cast adding a const.
> > 
> > But this could also happen with wrapper functions like this one from
> > __array_traits in std::array:
> > 
> >static constexpr _Tp&
> >_S_ref(const _Type& __t, std::size_t __n) noexcept
> >{ return const_cast<_Tp&>(__t[__n]); }
> > 
> > where the ref-to-const parameter added the const.
> > 
> > > > +  if (TREE_CODE (obj) == COMPONENT_REF)
> > > > +   {
> > > > + tree op1 = TREE_OPERAND (obj, 1);
> > > > + if (CP_TYPE_CONST_P (TREE_TYPE (op1)))
> > > > +   return true;
> > > > + else
> > > > +   {
> > > > + tree op0 = TREE_OPERAND (obj, 0);
> > > > + /* The LHS of . or -> might itself be a COMPONENT_REF.  */
> > > > + if (TREE_CODE (op0) == COMPONENT_REF)
> > > > +   op0 = TREE_OPERAND (op0, 1);
> > > > + return CP_TYPE_CONST_P (TREE_TYPE (op0));
> > > > +   }
> > > > +   }
> > > 
> > > Shouldn't this be a loop?
> > 
> > I don't think so, though my earlier patch had a call to
> > 
> > +static bool
> > +cref_has_const_field (tree ref)
> > +{
> > +  while (TREE_CODE (ref) == COMPONENT_REF)
> > +{
> > +  if (CP_TYPE_CONST_P (TREE_TYPE (TREE_OPERAND (ref, 1
> > +   return true;
> > +  ref = TREE_OPERAND (ref, 0);
> > +}
> > +  return false;
> > +}
> 
> > here.  A problem arised when I checked even the outermost expression (which 
> > is not a
> > field_decl), then I saw another problematical error.
> > 
> > The more outer fields are expected to be checked in subsequent calls to
> > modifying_const_object_p in next iterations of the
> > 
> > 4459   for (tree probe = target; object == NULL_TREE; )
> > 
> > loop in cxx_eval_store_expression.
> 
> OK, but then why do you want to check two levels here rather than just one?

It's a hack to keep constexpr-tracking-const7.C working.  There we have

  b.a.c.d.n

wherein 'd' is const struct D, but 'n' isn't const.  Without the hack
const_object_being_modified would be 'b.a.c.d', but due to the problem I
desribed in the original mail[1] the constructor for D wouldn't have
TREE_READONLY set.  With the hack const_object_being_modified will be
'b.a.c.d.n', which is of non-class type so we error:

4710   if (!CLASS_TYPE_P (const_objtype))
4711 fail = true;

I could remove the hack and maybe XFAIL constexpr-tracking-const7.C if you
want.  Unfortunately I wasn't aware of [1] when I added that feature and
checking if the whole COMPONENT_REF is const seemed to be enough.

It's probably not a good idea to make this checking more strict at this
stage.

[1] "While looking into this I noticed that we don't detect modifying a const
object in certain cases like in
.  That's because
we never evaluate an X::X() CALL_EXPR -- there's none.  So there's no
CONSTRUCTOR to set TREE_READONLY on.  No idea how to fix this, but it's
likely something for GCC 11 anyway."

Marek

Re: [PATCH] rs6000: Check -+0 and NaN for smax/smin generation

[Segher Boessenkool]

Hi!

On Thu, Mar 05, 2020 at 10:46:58AM +0800, Jiufu Guo wrote:
> PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
> relates to max of '-inf' and 'nan'. This regression occur on P9 which has
> new instruction 'xsmaxcdp/xsmincdp'.
> The similar issue also could be find on `a < b ? b : a` which is also
> generated as `xsmaxcdp` under -O2 for P9. This instruction `xsmaxcdp`
> more like C/C++ semantic (a>b?a:b). A testcase is added for this issue.
> 
> The following patch improve code to check -+0 and NaN before 'smax/smin' to
> be generated for those cases.

> -  else if (rtx_equal_p (op1, true_cond) && rtx_equal_p (op0, false_cond))
> +  /* Only when -fno-signed-zeros and -ffinite_math_only are in effect,
> + `op0 < op1 ? op1 : op0` works like `op1 > op0 ? op1 : op0` which 
> + could use smax;
> + `op0 > op1 ? op1 : op0` works like `op1 < op0 ? op1 : op0` which
> + could use smin.  */
> +  else if (rtx_equal_p (op1, true_cond) && rtx_equal_p (op0, false_cond)
> +&& (flag_finite_math_only && !flag_signed_zeros))
>  max_p = !max_p;

I know I asked for it, but should this use HONOR_NANS (compare_mode)
instead?  Infinities will work fine?  Just NaNs and zeros won't.

Okay for trunk with that change (if it works :-) )  Thanks!


Segher

Re: [PATCH][RFC] API extension for binutils (type of symbols).

[Jan Hubicka]

> On Mon, Mar 9, 2020 at 9:56 AM Martin Liška  wrote:
> >
> > On 3/9/20 4:36 PM, H.J. Lu wrote:
> > > We nee to support different variables, like TLS, data and bss variables.
> >
> > Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
> 
> Since you are introducing symbol types, why not support TLS?
> 
> > About BSS and DATA I agree that it would be handy. I can theoretically
> > covered with code in get_variable_section/bss_initializer_p. But it's
> > quite logic and I'm not sure we should simulate it.

I think it should not be that hard to factor out the logic from
get_variable_section to return enum of what we want to do and then
have get_variale_section as a wrapper parsing this enum to actual
section.
> >
> > @Honza/Richi: Do you have any opinion about that?

I guess we indeed want to get as close to non-LTO nm behaviour as
possible. So we want to support them and perhaps think of .symtab
section file format that can be made backward compatible (such as having
attribute string for symbols where we can add new info in future in a
way that old plugins will still get info they want).

Of course IPA optimizations may migrate symbols around (say from data to
bss)/take them away/rename them, but with that we need to live. I would
expect most tools inspecting nm are interested in what will enter
linking not what will be in final output.

Since we discuss plugin extensions (and I do not want this to complicate
finishing Martin's patch).  Are we aware of other plugin limitations?
One thing that I consider unsafe is the way we produce local names when
we need to promote symbol to hidden due to partitining.  We add
.lto_priv, but that is not safe if we link with .o file that was
incrementally lto-optimized to target object file (this is reason why I
did not enabled WHOPR path for it). 

We may also want to inform lld and llvm's gold plugin maintainers about
intended changes.
Honza
> >
> > Thanks,
> > Martin
> 
> 
> 
> -- 
> H.J.

Re: [PATCH][RFC] API extension for binutils (type of symbols).

[Michael Matz]

Hello,

On Mon, 9 Mar 2020, Martin Liška wrote:

> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
> 
> Why do we need TLS? Right now, it's not supported by nm.

Of course it does.  It's the 'T' (or 't') character.  When you introduce 
symbol categories into the plugin system it would be advisable to include 
all we usually care about, and as the ELF categories are (roughly) a 
superset of everything we support, I'd say that should be the list to look 
at.  I.e. a mixture of visibility, locality (aka binding) and type:

   {object,function,common,tls}
 x {local,global,weak,unique}
 x {default,internal,hidden,protected}

That doesn't include symbols types section,file,ifunc or os or arch 
specific types or visibilities or bindings.  But it would probably not be 
the worst idea to simply encode what we need with ELF constants and names.  
While not all the world is ELF, all concepts we have can be mapped onto 
ELF.


Ciao,
Michael.

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

[Jason Merrill]

On 3/9/20 12:31 PM, Martin Sebor wrote:

On 2/28/20 1:24 PM, Jason Merrill wrote:

On 2/28/20 12:45 PM, Martin Sebor wrote:

On 2/28/20 9:58 AM, Jason Merrill wrote:

On 2/24/20 6:58 PM, Martin Sebor wrote:

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also somewhat improves the detection
of both issues in template declarations (though more work is still
needed there).



+ a new entry for it and return unless it's a declaration
+ involving a template that may need to be diagnosed by
+ -Wredundant-tags.  */
   *rdl = class_decl_loc_t (class_key, false, def_p);
-  return;
+  if (TREE_CODE (decl) != TEMPLATE_DECL)
+    return;


How can the first appearance of a class template be redundant?


I'm not sure I correctly understand the question.  The comment says
"involving a template" (i.e., not one of the first declaration of
a template).  The test case that corresponds to this test is:

   template  struct S7 { };
   struct S7 s7v;  // { dg-warning "\\\[-Wredundant-tags" }

where DECL is the TEPLATE_DECL of S7.

As I mentioned, more work is still needed to handle templates right
because some redundant tags are still not diagnosed.  For example:

   template  struct S7 { };
   template 
   using U = struct S7;   // missing warning


When we get here for an instance of a template, it doesn't make sense 
to treat it as a new type.


If decl is a template and type_decl is an instance of that template, 
do we want to (before the lookup) change type_decl to the template or 
the corresponding generic TYPE_DECL, which should already be in the 
table?


I'm struggling with how to do this.  Given type (a RECORD_TYPE) and
type_decl (a TEMPLATE_DECL) representing the use of a template, how
do I get the corresponding template (or its explicit or partial
specialization) in the three cases below?

   1) Instance of the primary:
  template  class A;
  struct A a;

   2) Instance of an explicit specialization:
  template  class B;
  template <> struct B;
  class B b;

   3) Instance of a partial specialization:
  template  class C;
  template  struct C;
  class C c;

By trial and (lots of) error I figured out that in both (1) and (2),
but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns
the template's type_decl.

Is there some function to call to get it in (3), or even better,
in all three cases?


I think you're looking for most_general_template.

Jason

Re: [PATCH] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

[Jason Merrill]

On 3/9/20 9:40 AM, Marek Polacek wrote:

On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:

On 3/9/20 8:58 AM, Jakub Jelinek wrote:

On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:

On 3/6/20 6:54 PM, Marek Polacek wrote:

I got a report that building Chromium fails with the "modifying a const
object" error.  After some poking I realized it's a bug in GCC, not in
their codebase.

Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
nor the field were declared const.  So let's dial down the checking.
Here the COMPONENT_REF was const because of the "const_cast(m)"
thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
TREE_TYPE (t).


What is folding the const into the COMPONENT_REF?


cxx_eval_component_reference when it is called on
((const struct array *) this)->elems
with /*lval=*/true and lval is true because we are evaluating
 = (const int &) &((const struct array *) 
this)->elems[VIEW_CONVERT_EXPR(n)];


Ah, sure.  We're pretty loose with cv-quals in the constexpr code in
general, so it's probably not worth trying to change that here.  Getting
back to the patch:


Yes, here the additional const was caused by a const_cast adding a const.

But this could also happen with wrapper functions like this one from
__array_traits in std::array:

   static constexpr _Tp&
   _S_ref(const _Type& __t, std::size_t __n) noexcept
   { return const_cast<_Tp&>(__t[__n]); }

where the ref-to-const parameter added the const.


+  if (TREE_CODE (obj) == COMPONENT_REF)
+   {
+ tree op1 = TREE_OPERAND (obj, 1);
+ if (CP_TYPE_CONST_P (TREE_TYPE (op1)))
+   return true;
+ else
+   {
+ tree op0 = TREE_OPERAND (obj, 0);
+ /* The LHS of . or -> might itself be a COMPONENT_REF.  */
+ if (TREE_CODE (op0) == COMPONENT_REF)
+   op0 = TREE_OPERAND (op0, 1);
+ return CP_TYPE_CONST_P (TREE_TYPE (op0));
+   }
+   }


Shouldn't this be a loop?


I don't think so, though my earlier patch had a call to

+static bool
+cref_has_const_field (tree ref)
+{
+  while (TREE_CODE (ref) == COMPONENT_REF)
+{
+  if (CP_TYPE_CONST_P (TREE_TYPE (TREE_OPERAND (ref, 1
+   return true;
+  ref = TREE_OPERAND (ref, 0);
+}
+  return false;
+}



here.  A problem arised when I checked even the outermost expression (which is 
not a
field_decl), then I saw another problematical error.

The more outer fields are expected to be checked in subsequent calls to
modifying_const_object_p in next iterations of the

4459   for (tree probe = target; object == NULL_TREE; )

loop in cxx_eval_store_expression.


OK, but then why do you want to check two levels here rather than just one?

Jason

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma]

On 2020-03-09 19:01, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
>> I think memory operands are fine - my original concern was about
>> register outputs and SSA form that should reflect the correct def
>> on the EH vs non-EH edge.  From a "miscompile" perspective
>> doing nothig which means pretending the asm actually set the output
>> could lead us to false DCE of the old value:
>>
>> int foo = 0
>> try
>>   {
>> asm volatile ("..." : "=r" (foo));
>>   }
>> catch (...whatever...)
>>   {
>> foo should be still zero, but SSA doesn't have the correct use 
>> here
>>   }
>>
>> that means the compiler really assumes the asm will populate the outputs
>> even when it throws.
> 
> How is memory any different here?  In both cases you do not know if it
> is the old value or some new value in foo, after it threw an exception.
> 
> 
> Segher

If foo were a memory operand, the compiler makes no assumptions about
its value.  When you reference it in the catch block it is always read
back from memory.  Only register operands are clobbered and retain
their previous value.  If you compile such an example with -O3, you'll
see that the initial "int foo = 0;" is eliminated from the normal code
path.  It is only set to 0 in the catch block.

Re: [PATCH][RFC] API extension for binutils (type of symbols).

[H.J. Lu]

On Mon, Mar 9, 2020 at 9:56 AM Martin Liška  wrote:
>
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?

Since you are introducing symbol types, why not support TLS?

> About BSS and DATA I agree that it would be handy. I can theoretically
> covered with code in get_variable_section/bss_initializer_p. But it's
> quite logic and I'm not sure we should simulate it.
>
> @Honza/Richi: Do you have any opinion about that?
>
> Thanks,
> Martin



-- 
H.J.

[PATCH] libstdc++: LWG 3286 ranges::size is not required to be valid after ...

[Patrick Palka]

... a call to ranges::begin on an input range.

This implements LWG 3286.  The new wording for the single-argument
subrange::subrange constructor is implemented by splitting the constructor into
two delegating constructors, one constrained by _S_store_size and the other by
!_S_store_size.

Tested on x86_64-pc-linux-gnu, both tests fail before the patch and pass with
the patch.

libstdc++-v3/ChangeLog:

LWG 3286 ranges::size is not required to be valid after a call to
ranges::begin on an input range
* include/std/ranges (subrange::subrange): Split single-argument
constructor into two, one constrained by _S_store_size and another by
!_S_store_size.
(take_view::begin): Call size() before calling ranges::begin(_M_base).
* testsuite/std/ranges/adaptors/lwg3286.cc: New test.
* testsuite/std/ranges/subrange/lwg3286.cc: New test.
---
 libstdc++-v3/include/std/ranges   | 26 +--
 .../testsuite/std/ranges/adaptors/lwg3286.cc  | 72 +++
 .../testsuite/std/ranges/subrange/lwg3286.cc  | 71 ++
 3 files changed, 162 insertions(+), 7 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/lwg3286.cc
 create mode 100644 libstdc++-v3/testsuite/std/ranges/subrange/lwg3286.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index eb54b110c04..625eccaddba 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -281,12 +281,18 @@ namespace ranges
  && __detail::__convertible_to_non_slicing, _It>
  && convertible_to, _Sent>
constexpr
-   subrange(_Rng&& __r) requires (!_S_store_size || sized_range<_Rng>)
+   subrange(_Rng&& __r) requires _S_store_size && sized_range<_Rng>
+   : subrange{__r, ranges::size(__r)}
+   { }
+
+  template<__detail::__not_same_as _Rng>
+   requires borrowed_range<_Rng>
+ && __detail::__convertible_to_non_slicing, _It>
+ && convertible_to, _Sent>
+   constexpr
+   subrange(_Rng&& __r) requires (!_S_store_size)
: subrange{ranges::begin(__r), ranges::end(__r)}
-   {
- if constexpr (_S_store_size)
-   _M_size._M_size = ranges::size(__r);
-   }
+   { }
 
   template
requires __detail::__convertible_to_non_slicing, _It>
@@ -2037,7 +2043,10 @@ namespace views
if constexpr (random_access_range<_Vp>)
  return ranges::begin(_M_base);
else
- return counted_iterator{ranges::begin(_M_base), size()};
+ {
+   auto __sz = size();
+   return counted_iterator{ranges::begin(_M_base), __sz};
+ }
  }
else
  return counted_iterator{ranges::begin(_M_base), _M_count};
@@ -2051,7 +2060,10 @@ namespace views
if constexpr (random_access_range)
  return ranges::begin(_M_base);
else
- return counted_iterator{ranges::begin(_M_base), size()};
+ {
+   auto __sz = size();
+   return counted_iterator{ranges::begin(_M_base), __sz};
+ }
  }
else
  return counted_iterator{ranges::begin(_M_base), _M_count};
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3286.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3286.cc
new file mode 100644
index 000..07a0f63fe23
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3286.cc
@@ -0,0 +1,72 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+#include 
+
+using __gnu_test::test_input_range;
+
+namespace ranges = std::ranges;
+namespace views = std::views;
+
+struct my_range
+{
+  static inline int x[] = {1,2,3};
+  static inline test_input_range r{x};
+
+  bool called_begin = false;
+
+  auto
+  begin()
+  {
+called_begin = true;
+return r.begin();
+  }
+
+  auto
+  end()
+  {
+return r.end();
+  }
+
+  ranges::range_difference_t
+  size()
+  {
+VERIFY( !called_begin );
+return 3;
+  }
+};
+
+void
+test01()
+{
+  my_range r;
+  static_assert(!ranges::forward_range);
+  

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[Segher Boessenkool]

Hi!

On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
> I think memory operands are fine - my original concern was about
> register outputs and SSA form that should reflect the correct def
> on the EH vs non-EH edge.  From a "miscompile" perspective
> doing nothig which means pretending the asm actually set the output
> could lead us to false DCE of the old value:
> 
> int foo = 0
> try
>   {
> asm volatile ("..." : "=r" (foo));
>   }
> catch (...whatever...)
>   {
> foo should be still zero, but SSA doesn't have the correct use 
> here
>   }
> 
> that means the compiler really assumes the asm will populate the outputs
> even when it throws.

How is memory any different here?  In both cases you do not know if it
is the old value or some new value in foo, after it threw an exception.


Segher

Re: [PING^2][PATCH] Fix documentation of -mpoke-function-name ARM option

[Wilco Dijkstra]

Hi,

There is no single PC offset that is correct given CPUs may use different 
offsets.
GCC may also schedule the instruction that stores the PC. This feature used to
work on early Arms but is no longer functional or useful today, so the best way
forward is to remove it altogether. There are many similar options that have
been deprecated for years.

Cheers,
Wilco

Re: ping Re: PR90763: PowerPC vec_xl_len should take const argument.

[Segher Boessenkool]

On Mon, Mar 09, 2020 at 09:48:01AM -0500, will schmidt wrote:
> On Tue, 2020-02-25 at 12:15 -0600, will schmidt wrote:
> > PR90763: PowerPC vec_xl_len should take const argument.
> 
> ping!   :-)

https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540969.html


Segher

Re: [PATCH][AArch64] Use intrinsics for widening multiplies (PR91598)

[Andrew Pinski]

On Mon, Mar 9, 2020 at 10:26 AM Wilco Dijkstra  wrote:
>
> Hi Christophe,
>
> > I noticed a regression introduced by Delia's patch "aarch64: ACLE
> > intrinsics for BFCVTN, BFCVTN2 and BFCVT":
> > (on aarch64-linux-gnu)
> > FAIL: g++.dg/cpp0x/variadic-sizeof4.C  -std=c++14 (internal compiler error)
> >
> > I couldn't reproduce it with current ToT, until I realized that your
> > patch fixes it. However, I'm wondering whether that's expected given
> > the context of both patches
>
> It sounds like this is memory corruption. Neither patch should have changed
> anything in the C++ frontend.

It sounds like some GC issue.  The patch would have changed a few
things related to the front-end though.  Mainly the decl UIDs do
increase due to the new builtins.  Note most likely Deli's patch did
the same too.

Thanks,
Andrew Pinski

>
> Cheers,
> Wilco
>

Re: [PATCH][AArch64] Use intrinsics for widening multiplies (PR91598)

[Wilco Dijkstra]

Hi Christophe,

> I noticed a regression introduced by Delia's patch "aarch64: ACLE
> intrinsics for BFCVTN, BFCVTN2 and BFCVT":
> (on aarch64-linux-gnu)
> FAIL: g++.dg/cpp0x/variadic-sizeof4.C  -std=c++14 (internal compiler error)
>
> I couldn't reproduce it with current ToT, until I realized that your
> patch fixes it. However, I'm wondering whether that's expected given
> the context of both patches

It sounds like this is memory corruption. Neither patch should have changed
anything in the C++ frontend.

Cheers,
Wilco

Re: [PATCH][RFC] API extension for binutils (type of symbols).

[Martin Liška]

On 3/9/20 4:36 PM, H.J. Lu wrote:

We nee to support different variables, like TLS, data and bss variables.


Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?

About BSS and DATA I agree that it would be handy. I can theoretically
covered with code in get_variable_section/bss_initializer_p. But it's
quite logic and I'm not sure we should simulate it.

@Honza/Richi: Do you have any opinion about that?

Thanks,
Martin

[PATCH] Fix 'A' operand modifier: PR inline-asm/94095

[apinski]

From: Andrew Pinski 

The problem here is there was a typo in the documentation
for the 'A' modifier in the table, it was recorded as 'a'
in the table on the modifier column.

Committed as obvious.

2020-03-09  Andrew Pinski  

PR inline-asm/94095
* doc/extend.texi (x86 Operand Modifiers): Fix column
for 'A' modifier.
---
 gcc/ChangeLog   | 6 ++
 gcc/doc/extend.texi | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6c4a505..99f0011 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-03-09  Andrew Pinski  
+
+   PR inline-asm/94095
+   * doc/extend.texi (x86 Operand Modifiers): Fix column
+   for 'A' modifier.
+
 2020-03-09  Martin Liska  
 
PR target/93800
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 11b79a5..e0e7f54 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10437,7 +10437,7 @@ The table below shows the list of supported modifiers 
and their effects.
 
 @multitable {Modifier} {Print the opcode suffix for the size of th} {Operand} 
{@samp{att}} {@samp{intel}}
 @headitem Modifier @tab Description @tab Operand @tab @samp{att} @tab 
@samp{intel}
-@item @code{a}
+@item @code{A}
 @tab Print an absolute memory reference.
 @tab @code{%A0}
 @tab @code{*%rax}
-- 
1.8.3.1

New Swedish PO file for 'gcc' (version 10.1-b20200209)

[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 Swedish team of translators.  The file is available at:

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

(This file, 'gcc-10.1-b20200209.sv.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] avoid -Wredundant-tags on a first declaration in use (PR 93824)

[Martin Sebor]

On 2/28/20 1:24 PM, Jason Merrill wrote:

On 2/28/20 12:45 PM, Martin Sebor wrote:

On 2/28/20 9:58 AM, Jason Merrill wrote:

On 2/24/20 6:58 PM, Martin Sebor wrote:

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also somewhat improves the detection
of both issues in template declarations (though more work is still
needed there).



+ a new entry for it and return unless it's a declaration
+ involving a template that may need to be diagnosed by
+ -Wredundant-tags.  */
   *rdl = class_decl_loc_t (class_key, false, def_p);
-  return;
+  if (TREE_CODE (decl) != TEMPLATE_DECL)
+    return;


How can the first appearance of a class template be redundant?


I'm not sure I correctly understand the question.  The comment says
"involving a template" (i.e., not one of the first declaration of
a template).  The test case that corresponds to this test is:

   template  struct S7 { };
   struct S7 s7v;  // { dg-warning "\\\[-Wredundant-tags" }

where DECL is the TEPLATE_DECL of S7.

As I mentioned, more work is still needed to handle templates right
because some redundant tags are still not diagnosed.  For example:

   template  struct S7 { };
   template 
   using U = struct S7;   // missing warning


When we get here for an instance of a template, it doesn't make sense to 
treat it as a new type.


If decl is a template and type_decl is an instance of that template, do 
we want to (before the lookup) change type_decl to the template or the 
corresponding generic TYPE_DECL, which should already be in the table?


I'm struggling with how to do this.  Given type (a RECORD_TYPE) and
type_decl (a TEMPLATE_DECL) representing the use of a template, how
do I get the corresponding template (or its explicit or partial
specialization) in the three cases below?

  1) Instance of the primary:
 template  class A;
 struct A a;

  2) Instance of an explicit specialization:
 template  class B;
 template <> struct B;
 class B b;

  3) Instance of a partial specialization:
 template  class C;
 template  struct C;
 class C c;

By trial and (lots of) error I figured out that in both (1) and (2),
but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns
the template's type_decl.

Is there some function to call to get it in (3), or even better,
in all three cases?

Martin

Re: [PATCH] [rs6000] Rewrite the declaration of a variable

[Segher Boessenkool]

Hi Bin Bin,

On Mon, Mar 09, 2020 at 09:55:22PM +0800, binbin wrote:
> OK, removed the empty line and showed the changelog.  And I found that the
> declaration in rs6000-internal.h should also be removed, right?  The
> attachment is the latest patch.  Thanks.

> gcc/ChangeLog
> 
> 2020-03-09  Bin Bin Lv  
> 
>   * config/rs6000/rs6000-internal.h (toc_section): Remove the declaration.
>   * config/rs6000/rs6000.h (toc_section): Add the declaration.
>   * config/rs6000/rs6000.c (toc_section): Remove the declaration.

This looks fine.  Okay for trunk.  Thanks!


Segher

Re: [Patch] ./configure.ac – build libgomp by default for amdgcn*-*-*

[Jakub Jelinek]

On Mon, Mar 09, 2020 at 04:24:20PM +0100, Tobias Burnus wrote:
> PS: While amdgcn was added in GCC 9, offloading is
> only supported in GCC 10 – hence, there is no backporting
> needed.
> 
> 2020-03-09  Tobias Burnus  
> 
>* configure.ac: Build libgomp by default for amdgcn.
>* configure: Regenerate.

> diff --git a/configure.ac b/configure.ac
> index df2af18f9bd..56c881770b8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -512,7 +512,7 @@ if test x$enable_libgomp = x ; then
>;;
>  *-*-darwin* | *-*-aix*)
>;;
> -nvptx*-*-*)
> +nvptx*-*-*|amdgcn*-*-*)

Please keep it consistent with the code around and use spaces around | .
Ok with that change.

Jakub

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma]

On 2020-03-09 13:13, Richard Sandiford wrote:
> Thanks for doing this.

Hi Richard, thanks for your response.

> "J.W. Jagersma"  writes:
>> On 2020-03-07 20:20, Segher Boessenkool wrote:
>>> Some comments:
>>>
 +When non-call exceptions (@option{-fnon-call-exceptions}) are enabled, a
 +@code{volatile asm} statement is also allowed to throw exceptions.  If it
 +does, then the compiler assumes that its output operands have not been 
 written
 +yet.
>>>
>>> That reads as if the compiler assumes the outputs retain their original
>>> value, but that isn't true (I hope!)  The compiler assumes the output
>>> are clobbered, but it doesn't assume they are assigned any definite
>>> value?
>>
>> Register outputs are assumed to be clobbered, yes.  For memory outputs
>> this is not the case, if the asm writes it before throwing then the
>> memory operand retains this value.  It should be the user's
>> responsibility to ensure that an asm has no side-effects if it throws.
> 
> I guess one problem is that something like "=" explicitly says that
> the operand is clobbered "early", and I think it would be fair for
> "early" to include clobbers before the exception.  So IMO we should
> allow at least early-clobbered memory outputs to be clobbered by the
> exception.

Is "=" not equivalent to "=m" in every case?  As I understand it, the
earlyclobber modifier is only relevant for register outputs.  It does
not specify anything about clobbering the output itself, it only says
that an input could be clobbered if it is allocated in the same
register (or if a memory input uses this register as index).

> And if we do that, then I'm not sure there's much benefit in trying to
> treat the non-earlyclobber memory case specially.
> 
> It would be good to have testcases for the output cases.  E.g. for:
> 
> int foo;
> int bar = 0;
> try
>   {
> foo = 1;
> asm volatile ("..." : "=m" (foo));
>   }
> catch (...whatever...)
>   {
> bar = foo;
>   }
> ...use bar...
> 
> What does "bar = foo" read?  Is it always undefined behaviour if executed?
> Or does it always read "foo" from memory?  Can it be optimised to "bar = 1"?
> Is "foo = 1" dead code?

These are very good points.  But I am not sure how to test for all of
these.  My test case now looks as follows:

// PR inline-asm/93981
// { dg-do run }
// { dg-options "-fnon-call-exceptions -O3" }
// { dg-xfail-run-if "" { ! *-linux-gnu } }

#include 

struct illegal_opcode { };

extern "C" void
sigill (int)
{
  throw illegal_opcode ( );
}

int
test_mem ()
{
  int i = 2;
  try
{
  asm volatile ("mov%z0 $1, %0; ud2" : "=m" (i));
}
  catch (const illegal_opcode&)
{
  if (i == 1) return 0;
}
  return i;
}

int
test_reg ()
{
  int i = 2;
  try
{
  asm volatile ("mov%z0 $1, %0; ud2" : "=r" (i));
}
  catch (const illegal_opcode&)
{
  if (i == 2) return 0;
}
  return i;
}

int
main ()
{
  std::signal (SIGILL, sigill);
  return test_reg () + test_mem ();
}

I think that should cover most of it.  Am I missing anything?

Re: [PATCH][AArch64] Use intrinsics for widening multiplies (PR91598)

[Christophe Lyon]

On Fri, 6 Mar 2020 at 16:03, Wilco Dijkstra  wrote:
>
> Inline assembler instructions don't have latency info and the scheduler does
> not attempt to schedule them at all - it does not even honor latencies of
> asm source operands. As a result, SIMD intrinsics which are implemented using
> inline assembler perform very poorly, particularly on in-order cores.
> Fix this by adding new patterns and intrinsics for widening multiplies, which
> results in a 63% speedup for the example in the PR. This fixes the performance
> regression.
>
> Passes regress
>
> ChangeLog:
> 2020-03-06  Wilco Dijkstra  
>
> PR target/91598
> * config/aarch64/aarch64-builtins.c (TYPES_TERNOPU_LANE): Add define.
> * config/aarch64/aarch64-simd.md
> (aarch64_vec_mult_lane): Add new insn for widening lane 
> mul.
> (aarch64_vec_mlal_lane): Likewise.
> * config/aarch64/aarch64-simd-builtins.def: Add intrinsics.
> * config/aarch64/arm_neon.h:
> (vmlal_lane_s16): Expand using intrinsics rather than inline asm.
> (vmlal_lane_u16): Likewise.
> (vmlal_lane_s32): Likewise.
> (vmlal_lane_u32): Likewise.
> (vmlal_laneq_s16): Likewise.
> (vmlal_laneq_u16): Likewise.
> (vmlal_laneq_s32): Likewise.
> (vmlal_laneq_u32): Likewise.
> (vmull_lane_s16): Likewise.
> (vmull_lane_u16): Likewise.
> (vmull_lane_s32): Likewise.
> (vmull_lane_u32): Likewise.
> (vmull_laneq_s16): Likewise.
> (vmull_laneq_u16): Likewise.
> (vmull_laneq_s32): Likewise.
> (vmull_laneq_u32): Likewise.
> * config/aarch64/iterators.md (Vtype2): Add new iterator for lane mul.
> (Qlane): Likewise.
>


Hi Wilco,

I noticed a regression introduced by Delia's patch "aarch64: ACLE
intrinsics for BFCVTN, BFCVTN2 and BFCVT":
(on aarch64-linux-gnu)
FAIL: g++.dg/cpp0x/variadic-sizeof4.C  -std=c++14 (internal compiler error)

I couldn't reproduce it with current ToT, until I realized that your
patch fixes it. However, I'm wondering whether that's expected given
the context of both patches

Christophe


> ---
> diff --git a/gcc/config/aarch64/aarch64-builtins.c 
> b/gcc/config/aarch64/aarch64-builtins.c
> index 
> 9c9c6d86ae29fcbcf42e84408c5e94990fed8348..5744e68ea08722dcc387254f44408eb0fd3ffe6e
>  100644
> --- a/gcc/config/aarch64/aarch64-builtins.c
> +++ b/gcc/config/aarch64/aarch64-builtins.c
> @@ -175,6 +175,11 @@ aarch64_types_ternopu_qualifiers[SIMD_MAX_BUILTIN_ARGS]
>qualifier_unsigned, qualifier_unsigned };
>  #define TYPES_TERNOPU (aarch64_types_ternopu_qualifiers)
>  static enum aarch64_type_qualifiers
> +aarch64_types_ternopu_lane_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> +  = { qualifier_unsigned, qualifier_unsigned,
> +  qualifier_unsigned, qualifier_lane_index };
> +#define TYPES_TERNOPU_LANE (aarch64_types_ternopu_lane_qualifiers)
> +static enum aarch64_type_qualifiers
>  aarch64_types_ternopu_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
>= { qualifier_unsigned, qualifier_unsigned,
>qualifier_unsigned, qualifier_immediate };
> diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def 
> b/gcc/config/aarch64/aarch64-simd-builtins.def
> index 
> d8bb96f8ed60648477f952ea6b88eae67cc9c921..e256e9c2086b48dfb1d95ce8391651ec9e86b696
>  100644
> --- a/gcc/config/aarch64/aarch64-simd-builtins.def
> +++ b/gcc/config/aarch64/aarch64-simd-builtins.def
> @@ -191,6 +191,15 @@
>BUILTIN_VQW (BINOP, vec_widen_smult_hi_, 10)
>BUILTIN_VQW (BINOPU, vec_widen_umult_hi_, 10)
>
> +  BUILTIN_VD_HSI (TERNOP_LANE, vec_smult_lane_, 0)
> +  BUILTIN_VD_HSI (QUADOP_LANE, vec_smlal_lane_, 0)
> +  BUILTIN_VD_HSI (TERNOP_LANE, vec_smult_laneq_, 0)
> +  BUILTIN_VD_HSI (QUADOP_LANE, vec_smlal_laneq_, 0)
> +  BUILTIN_VD_HSI (TERNOPU_LANE, vec_umult_lane_, 0)
> +  BUILTIN_VD_HSI (QUADOPU_LANE, vec_umlal_lane_, 0)
> +  BUILTIN_VD_HSI (TERNOPU_LANE, vec_umult_laneq_, 0)
> +  BUILTIN_VD_HSI (QUADOPU_LANE, vec_umlal_laneq_, 0)
> +
>BUILTIN_VSD_HSI (BINOP, sqdmull, 0)
>BUILTIN_VSD_HSI (TERNOP_LANE, sqdmull_lane, 0)
>BUILTIN_VSD_HSI (TERNOP_LANE, sqdmull_laneq, 0)
> diff --git a/gcc/config/aarch64/aarch64-simd.md 
> b/gcc/config/aarch64/aarch64-simd.md
> index 
> 999d80667b7cf06040515958c747d8bca0728acc..ccf4e394c1f6aa7d0adb23cfcd8da1b6d40d7ebf
>  100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -1892,6 +1892,45 @@ (define_expand "vec_widen_mult_hi_"
>   }
>  )
>
> +;; vmull_lane_s16 intrinsics
> +(define_insn "aarch64_vec_mult_lane"
> +  [(set (match_operand: 0 "register_operand" "=w")
> +   (mult:
> + (ANY_EXTEND:
> +   (match_operand: 1 "register_operand" "w"))
> + (ANY_EXTEND:
> +   (vec_duplicate:
> + (vec_select:
> +   (match_operand:VDQHS 2 "register_operand" "")
> +   (parallel [(match_operand:SI 3 "immediate_operand" 
> "i")]))]
> +  "TARGET_SIMD"
> +  {
> +

Re: [PATCH][RFC] API extension for binutils (type of symbols).

[H.J. Lu]

On Mon, Mar 9, 2020 at 2:30 AM Martin Liška  wrote:
>
> Hi.
>
> With change of -fno-common default for GCC 10 we're facing serious
> problem with LTO where one can't distinguish in between global symbols
> and variables based on the output of nm:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25355
>
> $ cat nm.c
> char nm_test_var;
>
> $ gcc-9 nm.c -c -fno-common
> $ nm nm.o
>  B nm_test_var
>
> $ gcc-9 nm.c -c -fno-common -flto
> $ nm nm.o
>  T nm_test_var
>
> H.J. decided to implement quite heavy solution which is about usage of 
> lto-wrapper
> that takes a LTO object file and makes a final assembly file. The file is then
> utilized with nm. That has some disadvantages:
>
> - it's slow - using nm x.a can take very long time
> - way of finding lto-wrapper is quite hard-coded to location of LTO plugin
> - we face issues with multiple final object files:
>https://sourceware.org/bugzilla/show_bug.cgi?id=25640
>
> That said, I'm suggesting to expect LTO plugin API to tell binutils whether
> a symbol is variable or function. That should help us to mark global variables
> with "D" in nm output.
>
> I would like to note that even with -fcommon, the nm output for LTO bytecode 
> is far
> from perfect:
>
> $ cat bss.c
> int global_zero;
> int global_one = 1;
>
> $ gcc-9 bss.c -c  -flto
> $ nm bss.o
>  T global_one
>  C global_zero
>
> I believe in this case we can mark both symbols with D as a reasonable guess.
>
> Thoughts?
> Martin
>
> gcc/ChangeLog:
>
> 2020-03-09  Martin Liska  
>
> * lto-streamer-out.c (write_symbol): Stream
> symbol type.
>
> include/ChangeLog:
>
> 2020-03-09  Martin Liska  
>
> * lto-symtab.h (enum gcc_plugin_symbol_type): New.
> * plugin-api.h (struct ld_plugin_symbol): New member
> symbols_type.
> (enum ld_plugin_symbol_type): New.
> (enum ld_plugin_tag): Add new tag LDPT_GET_SYMBOLS_V4.
>
> lto-plugin/ChangeLog:
>
> 2020-03-09  Martin Liska  
>
> * lto-plugin.c (parse_table_entry): Parse symbol type.
> ---
>   gcc/lto-streamer-out.c  |  2 ++
>   include/lto-symtab.h|  7 +++
>   include/plugin-api.h| 13 -
>   lto-plugin/lto-plugin.c | 12 
>   4 files changed, 33 insertions(+), 1 deletion(-)
>
>

We nee to support different variables, like TLS, data and bss variables.

-- 
H.J.

[Patch] ./configure.ac – build libgomp by default for amdgcn*-*-*

[Tobias Burnus]

As reported by richi on IRC, libgomp is not build
by default for amdgcn – and as Jakub pointed out,
that's setup in configure{,.ac}.

(It is disabled by default but enabled for POSIX systems,
nvptx

This patch adds it – OK for the trunk?

Tobias

PS: While amdgcn was added in GCC 9, offloading is
only supported in GCC 10 – hence, there is no backporting
needed.

2020-03-09  Tobias Burnus  

   * configure.ac: Build libgomp by default for amdgcn.
   * configure: Regenerate.

diff --git a/configure b/configure
index cde03b70052..f428bc498f0 100755
--- a/configure
+++ b/configure
@@ -3213,7 +3213,7 @@ if test x$enable_libgomp = x ; then
   ;;
 *-*-darwin* | *-*-aix*)
   ;;
-nvptx*-*-*)
+nvptx*-*-*|amdgcn*-*-*)
   ;;
 *)
   noconfigdirs="$noconfigdirs target-libgomp"
diff --git a/configure.ac b/configure.ac
index df2af18f9bd..56c881770b8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -512,7 +512,7 @@ if test x$enable_libgomp = x ; then
   ;;
 *-*-darwin* | *-*-aix*)
   ;;
-nvptx*-*-*)
+nvptx*-*-*|amdgcn*-*-*)
   ;;
 *)
   noconfigdirs="$noconfigdirs target-libgomp"

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
2020-03-09  Tobias Burnus  

* configure.ac: Build libgomp by default for amdgcn.
* configure: Regenerate.

diff --git a/configure b/configure
index cde03b70052..f428bc498f0 100755
--- a/configure
+++ b/configure
@@ -3213,7 +3213,7 @@ if test x$enable_libgomp = x ; then
;;
 *-*-darwin* | *-*-aix*)
;;
-nvptx*-*-*)
+nvptx*-*-*|amdgcn*-*-*)
;;
 *)
noconfigdirs="$noconfigdirs target-libgomp"
diff --git a/configure.ac b/configure.ac
index df2af18f9bd..56c881770b8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -512,7 +512,7 @@ if test x$enable_libgomp = x ; then
;;
 *-*-darwin* | *-*-aix*)
;;
-nvptx*-*-*)
+nvptx*-*-*|amdgcn*-*-*)
;;
 *)
noconfigdirs="$noconfigdirs target-libgomp"

RE: [PATCH][GCC][AArch64]: Break apart paradoxical subregs for VSTRUCT writes (PR target/94052)

[Tamar Christina]

My Attachment seems to have been stripped. So sending it again inline and 
hoping the tabs don't get stripped.

diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index 
89aaf8c018e3340dd2d53fc2a6538d3d1220b103..47428dd3e9c4fa8fc1f3d876e774defb6bc64640
 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -5330,6 +5330,29 @@ (define_expand "mov"
   if (GET_CODE (operands[0]) != REG)
operands[1] = force_reg (mode, operands[1]);
 }
+
+  /* If we have a paradoxical subreg trying to write to  from and the
+ registers don't overlap then we need to break it apart.  What it's trying
+ to do is give two kind of information at the same time.  It's trying to
+ convey liveness information by saying that the entire register will be
+ written to eventually, but it also only wants to write a single part of 
the
+ register.  Hence the paradoxical subreg.
+
+ However reload doesn't understand this concept and it will ultimately ICE.
+ Instead of allowing this we will split the two concerns.  The liveness
+ information will be conveyed using a clobber and then we break apart the
+ paradoxical subreg into just a normal write of the part that it wanted to
+ write originally.  */
+
+  if (paradoxical_subreg_p (operands[1]))
+{
+  if (!reg_overlap_mentioned_p (operands[0], operands[1]))
+   emit_clobber (operands[0]);
+  poly_uint64 offset = SUBREG_BYTE (operands[1]);
+  operands[1] = SUBREG_REG (operands[1]);
+  operands[0] = simplify_gen_subreg (GET_MODE (operands[1]), operands[0],
+mode, offset);
+}
 })
 
 
diff --git a/gcc/testsuite/g++.target/aarch64/pr94052.C 
b/gcc/testsuite/g++.target/aarch64/pr94052.C
new file mode 100644
index 
..d36c9bdc1588533db35eb3cbd2502034edd25452
--- /dev/null
+++ b/gcc/testsuite/g++.target/aarch64/pr94052.C
@@ -0,0 +1,174 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O2 -std=gnu++11 -w" } */
+
+namespace c {
+typedef int d;
+template  struct f { typedef e g; };
+template  struct h;
+template  e aa(typename f::g i) { return i; }
+template  struct j {};
+template  struct k;
+template  struct k<1, j> { typedef m g; };
+template  typename k>::g ab(j);
+} // namespace c
+typedef long d;
+typedef char o;
+typedef int p;
+typedef char q;
+typedef int r;
+namespace {
+struct s;
+constexpr d t = 6;
+template  class ad {
+public:
+  static constexpr d u = t;
+  d v();
+  d x();
+  d y();
+};
+class z : ad {};
+struct ae {
+  p af;
+};
+class ag {
+public:
+  ae ah();
+};
+} // namespace
+typedef __Int32x4_t ai;
+typedef struct {
+  ai aj[2];
+} ak;
+typedef int al;
+void am(p *a, ai b) { __builtin_aarch64_st1v4si(a, b); }
+namespace an {
+class ao {
+public:
+  bool operator==(ao);
+  d v();
+  d x();
+};
+class ap : public ad {};
+class aq {
+public:
+  c::j ar();
+  int as();
+  int at();
+};
+class au {
+public:
+  virtual d av(d);
+  virtual ap aw();
+  virtual ag ax();
+};
+class ay {};
+class az {
+  virtual void ba(const ay &, const s &);
+};
+using bb = az;
+class bc;
+class bd : bb {
+  void ba(const ay &, const s &);
+  bc *be;
+  bc *bf;
+  bc *bg;
+  aq bh;
+  int bi;
+  int bj;
+  ao bk;
+};
+namespace bl {
+namespace bm {
+namespace bn {
+class bo;
+}
+} // namespace bm
+} // namespace bl
+namespace bn {
+template >
+ai bp(ac *, ac *, ac *, al, al, al, d, p);
+template >
+ak bq(ac *br, ac *bs, ac *bt, al bu, al bv, al bw, d bx, int, int by) {
+  ak{bp(br, bs, bt, bu, bv, bw, bx, by), bp(br, bs, bt, bu, bv, bw, bx, by)};
+}
+template >
+ak bz(ac *, ac *, ac *, al, al, al &, int, p);
+template  void ca(p *, const ak &);
+template <> void ca<1>(p *buffer, const ak ) {
+  am(buffer, cb.aj[0]);
+  am(buffer + 4, cb.aj[1]);
+}
+int cc(int, int);
+} // namespace bn
+class bc {
+public:
+  virtual au *cd();
+};
+class ce {
+public:
+  q *cf();
+};
+template  struct cg {
+  template  static void ci(ay, z cj, ch ck) { ck(cj); }
+};
+template  void cl(ay w, ch ck) {
+  z cj;
+  cg::ci(w, cj, c::aa(ck));
+}
+namespace {
+template  class co {
+public:
+  static void convolve(ay, int cs, bc *cp, bc *cq, bc *cr, aq cw, int, ao ct) {
+int by = cp->cd()->ax().ah().af;
+int cu = cq->cd()->ax().ah().af;
+cp->cd()->aw().v();
+int cv = cp->cd()->aw().x();
+cp->cd()->aw().y();
+cp->cd()->aw();
+int da = cr->cd()->aw().x();
+int cx = cq->cd()->aw().x();
+cq->cd()->aw().y();
+int cy = cr->cd()->av(0);
+int cz = cr->cd()->av(1);
+bn::cc(cs, cn);
+int de = c::ab<1>(cw.ar());
+cw.as();
+cw.at();
+ay db;
+ce dc;
+ce dd;
+ce w;
+q *di = w.cf();
+cl(db, [&](z) {
+  int df;
+  dc;
+  di;
+  cx;
+  auto dg(cu);
+  auto dh(cu);
+  auto dl(cu);
+  for (; cz; df += de) {
+auto br = reinterpret_cast(cv);
+auto bs = reinterpret_cast(cv);
+

Re: c: ignore initializers for elements of variable-size types [PR93577]

[Christophe Lyon]

On Fri, 6 Mar 2020 at 00:50, Joseph Myers  wrote:
>
> Bug 93577, apparently a regression (although it isn't very clear to me
> exactly when it was introduced; tests I made with various past
> compilers produced inconclusive results, including e.g. ICEs appearing
> with 64-bit-host compilers for some versions but not 32-bit-host
> compilers for the same versions) is an C front-end tree-checking ICE
> processing initializers for structs using the VLA-in-struct extension.
> There is an error for such initializers, but other processing that
> still takes place for them results in the ICE.
>
> This patch ensures that processing of initializers for variable-size
> types stops earlier to avoid the code that results in the ICE (and
> ensures it stops earlier for error_mark_node to avoid ICEs in the
> check for variable-size types), adjusts the conditions for the "empty
> scalar initializer" diagnostic to avoid consequent excess errors in
> the case of a bad type name, and adds tests for a few variations on
> what such initializers might look like, as well as tests for cases
> identified from ICEs seen with an earlier version of this patch.
>
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to
> mainline.
>

Hi Joseph,

I've noticed that your patch introduces regressions on aarch64:
FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
-march=armv8.2-a+sve  (test for errors, line 33)
we now get
/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c:33:44:
error: empty scalar initializer
while we expect dg-error {initializer element is not constant}

FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
-march=armv8.2-a+sve  (test for errors, line 85)
we no longer emit dg-error {empty scalar initializer }

FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
-march=armv8.2-a+sve (test for excess errors)
FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
-march=armv8.2-a+sve  (test for errors, line 85)
we no longer emit dg-error {empty scalar initializer }

Since the compiler did not ICE before your patch, is that new
behaviour expected (and the tests need an update), or is that a
problem with the patch?

Thanks,

Christophe



> gcc/c:
> 2020-03-05  Joseph Myers  
>
> PR c/93577
> * c-typeck.c (pop_init_level): Do not diagnose initializers as
> empty when initialized type is error_mark_node.
> (set_designator, process_init_element): Ignore initializers for
> elements of a variable-size type or of error_mark_node.
>
> gcc/testsuite:
> 2020-03-05  Joseph Myers  
>
> PR c/93577
> * gcc.dg/pr93577-1.c, gcc.dg/pr93577-2.c, gcc.dg/pr93577-3.c,
> gcc.dg/pr93577-4.c, gcc.dg/pr93577-5.c, gcc.dg/pr93577-6.c: New
> tests.
> * gcc.dg/vla-init-1.c: Expect fewer errors about VLA initializer.
>
> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index 308fcffcfb0..d8025de1996 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -8759,7 +8759,7 @@ pop_init_level (location_t loc, int implicit,
>  the element, after verifying there is just one.  */
>if (vec_safe_is_empty (constructor_elements))
> {
> - if (!constructor_erroneous)
> + if (!constructor_erroneous && constructor_type != error_mark_node)
> error_init (loc, "empty scalar initializer");
>   ret.value = error_mark_node;
> }
> @@ -8836,8 +8836,8 @@ set_designator (location_t loc, bool array,
>enum tree_code subcode;
>
>/* Don't die if an entire brace-pair level is superfluous
> - in the containing level.  */
> -  if (constructor_type == NULL_TREE)
> + in the containing level, or for an erroneous type.  */
> +  if (constructor_type == NULL_TREE || constructor_type == error_mark_node)
>  return true;
>
>/* If there were errors in this designator list already, bail out
> @@ -8845,6 +8845,12 @@ set_designator (location_t loc, bool array,
>if (designator_erroneous)
>  return true;
>
> +  /* Likewise for an initializer for a variable-size type.  Those are
> + diagnosed in digest_init.  */
> +  if (COMPLETE_TYPE_P (constructor_type)
> +  && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
> +return true;
> +
>if (!designator_depth)
>  {
>gcc_assert (!constructor_range_stack);
> @@ -9955,8 +9961,14 @@ process_init_element (location_t loc, struct c_expr 
> value, bool implicit,
>  }
>
>/* Ignore elements of a brace group if it is entirely superfluous
> - and has already been diagnosed.  */
> -  if (constructor_type == NULL_TREE)
> + and has already been diagnosed, or if the type is erroneous.  */
> +  if (constructor_type == NULL_TREE || constructor_type == error_mark_node)
> +return;
> +
> +  /* Ignore elements of an initializer for a variable-size type.
> + Those are diagnosed in digest_init.  */
> +  if (COMPLETE_TYPE_P (constructor_type)
> +  && TREE_CODE (TYPE_SIZE 

ping Re: PR90763: PowerPC vec_xl_len should take const argument.

[will schmidt]

On Tue, 2020-02-25 at 12:15 -0600, will schmidt wrote:
> PR90763: PowerPC vec_xl_len should take const argument.

ping!   :-)

thanks
-Will

> 
> Hi,
> 
>   Adds some logic in altivec_resolve_overloaded_builtin() to handle
> the
> scenario where const * arguments are passed in to the
> vec_xl_len()
> builtin.
> The existing logic to remove const from pointers does not kick in
> since
> the return type is not itself a pointer type.
> 
> Regtested ok.
> OK for master?
> 
> Thanks,
> -Will
> 
> 2020-02-24:  Will Schmidt  
> 
> gcc/
>   PR target/90763
>   * config/rs6000/rs6000-c.c
> (altivec_resolve_overloaded_builtin): Add
>   clause to handle P9V_BUILTIN_VEC_LXVL with const arguments.
> 
> testsuite/
>   PR target/90763
>   * gcc.target/powerpc/pr90763: New.
> 
> diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-
> c.c
> index 37c74cf..9ad8309 100644
> --- a/gcc/config/rs6000/rs6000-c.c
> +++ b/gcc/config/rs6000/rs6000-c.c
> @@ -1636,10 +1636,24 @@ altivec_resolve_overloaded_builtin
> (location_t loc, tree fndecl,
> type = build_pointer_type (build_qualified_type (TREE_TYPE
> (type),
>  0));
> arg = fold_convert (type, arg);
>   }
> 
> +  /* For P9V_BUILTIN_VEC_LXVL, convert any const * to its non
> constant
> +  equivalent to simplify the overload matching below.  */
> +  if (fcode == P9V_BUILTIN_VEC_LXVL)
> + {
> +   if (POINTER_TYPE_P (type)
> +   && (TYPE_QUALS (TREE_TYPE (type)) != 0)
> +   && TYPE_READONLY (TREE_TYPE (type)))
> + {
> +   type = build_pointer_type (build_qualified_type (
> + TREE_TYPE (type),0));
> +   arg = fold_convert (type, arg);
> + }
> + }
> +
>args[n] = arg;
>types[n] = type;
>  }
> 
>/* If the number of arguments did not match the prototype, return
> NULL
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr90763.c
> b/gcc/testsuite/gcc.target/powerpc/pr90763.c
> new file mode 100644
> index 000..ec0e56e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr90763.c
> @@ -0,0 +1,87 @@
> +/* { dg-require-effective-target powerpc_p9vector_ok } */
> +/* { dg-options "-mcpu=power9" } */
> +
> +/* PR90763: PowerPC vec_xl_len should take const.
> +*/
> +
> +#include 
> +
> +vector unsigned char vec_load_uc(unsigned char *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned char vec_load_const_uc(const unsigned char *p, int
> num) {
> +return vec_xl_len(p, num);
> +}
> +vector signed char vec_load_sc(signed char *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector signed char vec_load_const_sc(const signed char *p, int num)
> {
> +return vec_xl_len(p, num);
> +}
> +
> +vector signed short vec_load_ss(signed short *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector signed short vec_load_const_ss(const signed short *p, int
> num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned short vec_load_us(unsigned short *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned short vec_load_const_us(const unsigned short *p, int
> num) {
> +return vec_xl_len(p, num);
> +}
> +
> +vector signed int vec_load_si(signed int *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector signed int vec_load_const_si(const signed int *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned int vec_load_ui(unsigned int *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned int vec_load_const_ui(const unsigned int *p, int
> num) {
> +return vec_xl_len(p, num);
> +}
> +
> +vector signed long long vec_load_sll(signed long long *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector signed long long vec_load_const_sll(const signed long long
> *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned long long vec_load_ull(unsigned long long *p, int
> num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned long long vec_load_const_ull(const unsigned long
> long *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +
> +vector signed __int128 vec_load_si128(signed __int128 *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector signed __int128 vec_load_const_si128(const signed __int128
> *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned __int128 vec_load_ui128(unsigned __int128 *p, int
> num) {
> +return vec_xl_len(p, num);
> +}
> +vector unsigned __int128 vec_load_const_ui128(const unsigned
> __int128 *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +
> +vector float vec_load_f(float *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector float vec_load_const_f(const float *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +
> +vector double vec_load_d(double *p, int num) {
> +return vec_xl_len(p, num);
> +}
> +vector double 

Re: [PATCH] [rs6000] Fix a wrong GC issue

[Segher Boessenkool]

Hi!

On Mon, Mar 09, 2020 at 01:58:01PM +0800, binbin wrote:
> 2020-03-09  Bin Bin Lv  
> 
>   * config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,
>   builtin_mode_to_type[MAX_MACHINE_MODE][2]): Remove the declaration.

Just write "builtin_mode_to_type", nothing []?  Writing down the
dimensions here doesn't add anything, just is a bit noisy: you normally
put just the name here.

>   * config/rs6000/rs6000.c (altivec_builtin_mask_for_load,
>   builtin_mode_to_type[MAX_MACHINE_MODE][2]): Remove the GTY(())
>   declaration and add the definition.

The definitions were already there, so lose the second part of this?

> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> index 1697186..724085b 100644
> --- a/gcc/config/rs6000/rs6000.h
> +++ b/gcc/config/rs6000/rs6000.h
> @@ -2490,6 +2490,8 @@ extern GTY(()) tree 
> rs6000_builtin_types[RS6000_BTI_MAX];
>  extern GTY(()) tree rs6000_builtin_decls[RS6000_BUILTIN_COUNT];
>  
>  #ifndef USED_FOR_TARGET
> +extern GTY(()) tree builtin_mode_to_type[MAX_MACHINE_MODE][2];
> +extern GTY(()) tree altivec_builtin_mask_for_load;

Add a newline here please?

>  /* A C structure for machine-specific, per-function data.
> This is added to the cfun structure.  */
>  typedef struct GTY(()) machine_function

Okay for trunk with those tweaks.  Thanks!


Segher

Re: PATCH -- Fix degree trignometric functions

[Fritz Reese]

On Sat, Mar 7, 2020 at 1:32 PM Steve Kargl
 wrote:
>
> Fix the simplification and handling of the degree trigonometric functions.
>  This includes fixing a number of ICEs.  See PR 93871.
>
>  ChangeLog and patch attached.

As the author of the original degree-trig functions I intend to review
this patch soon, and...

> On Fri, Mar 06, 2020 at 03:18:19PM -0800, Steve Kargl wrote:
> >
> >   3. Simplification routines do the following mappings:
> >  sind(x) = sin((pi/180) * x) asind(x) = (180/pi) * asin(x)
> >  cosd(x) = cos((pi/180) * x) acosd(x) = (180/pi) * acos(x)
> >  tand(x) = tan((pi/180) * x) atand(x) = (180/pi) * atan(x)
> >  atan2d(y,x) = (180/pi) * atan2(y,x)
> >  cotand(x) = cotan((pi/180) * x)
> >  All computations are carried out by MPFR or MPC.
>
> In looking at some basic tests, the above simplification will
> need to be modified to do what ...
>
>
> >   5. New functions have been added to libgfortran to handle sind, cosd,
> >  and tand.
>
> ... these functions do.  Otherwise, things like cos(real(60+123*360))
> give wrong values.  Modifications are so easy even a lurker can do
> them.

... extend the patch to include these changes (unless someone
enthusiastic gets around to these mods before I do).

I should be able to start on this next week (around 16 March).

---
Fritz Reese

Soap machine

[Linda Cheung via Gcc-patches]

Hi Sir,
Good day.
Are you looking for 
l Pleat soap wrapping machine
l Soap stretch film wapping machine
l Flow type soap wrapping machine 
we are one of the largest soap warpping machines manufacturers in China. we 
provide with reliable prices and Only High quality , which has good reputation 
all around the world.if you need these products, please reply us with your 
requirement details! 
waiting for your early reply!
Tks.
Linda Cheung

[PATCH][GCC][AArch64]: Break apart paradoxical subregs for VSTRUCT writes (PR target/94052)

[Tamar Christina]

Hi All,

This works around an ICE in reload where from expand we get the following RTL
generated for VSTRUCT mode writes:

(insn 446 354 445 2 (set (reg:CI 383)
 (subreg:CI (reg:V4SI 291) 0)) "small.i":146:22 3408 {*aarch64_movci}
 (nil))

This sequence is trying to say two things:

1) liveliness: It's trying to say that eventually the whole CI reg will be
   written to. It does this by generating the paradoxical subreg.
2) write data: It's trying to in the same instruction also write the V4SI mode
   component at offset 0 in the CI reg.

Reload is unable to understand this concept and so it attempts to handle this
instruction by breaking apart the instruction, first writing the data and then
tries to reload the paradoxical part.  This gets it to the same instruction
again and eventually we ICE since we reach the limit of no. reloads.

This patch fixes it by in the backend when we see such a paradoxical
construction breaking it apart and issuing a clobber to correct the liveliness
information and then emitting a normal subreg write for the component that the
paradoxical subreg was trying to write to.

Concretely we generate this:

(insn 42 41 43 (clobber (reg/v:CI 122 [ diD.5226 ])) "small.i":121:23 -1
 (nil))

(insn 43 42 44 (set (subreg:V4SI (reg/v:CI 122 [ diD.5226 ]) 0)
(reg:V4SI 136)) "small.i":121:23 -1
 (nil))

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for master and back-port to GCC 9 and GCC 8 after some stew?

I will look into seeing if we can not generate these at all, but I'm not sure
this is possible since the mid-end would need both the Mode and the Class to
know that a pseudo will be assigned to multiple hardregs.

Thanks,
Tamar

gcc/ChangeLog:

2020-03-09  Tamar Christina  

PR target/94052
* config/aarch64/aarch64-simd.md (mov): Remove paradoxical
subregs of VSTRUCT modes.

gcc/testsuite/ChangeLog:

2020-03-09  Tamar Christina  

PR target/94052
* gcc.target/aarch64/pr94052.C: New test.

-- 

Re: [PATCH] [rs6000] Rewrite the declaration of a variable

[binbin]

Hi Segher,

On 2020/3/6 下午11:25, Segher Boessenkool wrote:

Hi!

On Fri, Mar 06, 2020 at 10:20:08AM +0800, binbin wrote:

OK, changed the code.  Bootstrap and regression tests were done on
powerpc64le-linux-gnu (LE) with no regressions.  Thanks for your suggestion.


Yes, this is fine, approved for trunk (but add a changelog!)

And one triviality:


--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -2494,6 +2494,9 @@ extern GTY(()) tree 
builtin_mode_to_type[MAX_MACHINE_MODE][2];
  extern GTY(()) tree altivec_builtin_mask_for_load;
  
  #ifndef USED_FOR_TARGET

+
+extern GTY(()) section *toc_section;


No empty line before this please?

Thanks!


Segher



OK, removed the empty line and showed the changelog.  And I found that the
declaration in rs6000-internal.h should also be removed, right?  The
attachment is the latest patch.  Thanks.
gcc/ChangeLog

2020-03-09  Bin Bin Lv  

* config/rs6000/rs6000-internal.h (toc_section): Remove the declaration.
* config/rs6000/rs6000.h (toc_section): Add the declaration.
* config/rs6000/rs6000.c (toc_section): Remove the declaration.
---
diff --git a/gcc/config/rs6000/rs6000-internal.h 
b/gcc/config/rs6000/rs6000-internal.h
index d331b9e..9caef01 100644
--- a/gcc/config/rs6000/rs6000-internal.h
+++ b/gcc/config/rs6000/rs6000-internal.h
@@ -64,7 +64,6 @@ typedef struct rs6000_stack {
 extern int need_toc_init;
 extern char toc_label_name[10];
 extern int rs6000_pic_labelno;
-extern section *toc_section;
 
 #ifdef USING_ELFOS_H
 extern const char *rs6000_machine;
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 0faf44b..c0a6e86 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -181,7 +181,6 @@ static GTY(()) section *tls_private_data_section;
 static GTY(()) section *read_only_private_data_section;
 static GTY(()) section *sdata2_section;
 
-extern GTY(()) section *toc_section;
 section *toc_section = 0;
 
 /* Describe the vector unit used for modes.  */
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 724085b..8595b43 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -2492,6 +2492,7 @@ extern GTY(()) tree 
rs6000_builtin_decls[RS6000_BUILTIN_COUNT];
 #ifndef USED_FOR_TARGET
+extern GTY(()) section *toc_section;
 /* A C structure for machine-specific, per-function data.
This is added to the cfun structure.  */
 typedef struct GTY(()) machine_function

Re: [PATCH] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

[Marek Polacek]

On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
> On 3/9/20 8:58 AM, Jakub Jelinek wrote:
> > On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
> > > On 3/6/20 6:54 PM, Marek Polacek wrote:
> > > > I got a report that building Chromium fails with the "modifying a const
> > > > object" error.  After some poking I realized it's a bug in GCC, not in
> > > > their codebase.
> > > > 
> > > > Much like with ARRAY_REFs, which can be const even though the array
> > > > itself isn't, COMPONENT_REFs can be const although neither the object
> > > > nor the field were declared const.  So let's dial down the checking.
> > > > Here the COMPONENT_REF was const because of the "const_cast > > > &>(m)"
> > > > thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
> > > > TREE_TYPE (t).
> > > 
> > > What is folding the const into the COMPONENT_REF?
> > 
> > cxx_eval_component_reference when it is called on
> > ((const struct array *) this)->elems
> > with /*lval=*/true and lval is true because we are evaluating
> >  = (const int &) &((const struct array *) 
> > this)->elems[VIEW_CONVERT_EXPR(n)];
> 
> Ah, sure.  We're pretty loose with cv-quals in the constexpr code in
> general, so it's probably not worth trying to change that here.  Getting
> back to the patch:

Yes, here the additional const was caused by a const_cast adding a const.

But this could also happen with wrapper functions like this one from
__array_traits in std::array:

  static constexpr _Tp&
  _S_ref(const _Type& __t, std::size_t __n) noexcept
  { return const_cast<_Tp&>(__t[__n]); }

where the ref-to-const parameter added the const.

> > +  if (TREE_CODE (obj) == COMPONENT_REF)
> > +   {
> > + tree op1 = TREE_OPERAND (obj, 1);
> > + if (CP_TYPE_CONST_P (TREE_TYPE (op1)))
> > +   return true;
> > + else
> > +   {
> > + tree op0 = TREE_OPERAND (obj, 0);
> > + /* The LHS of . or -> might itself be a COMPONENT_REF.  */
> > + if (TREE_CODE (op0) == COMPONENT_REF)
> > +   op0 = TREE_OPERAND (op0, 1);
> > + return CP_TYPE_CONST_P (TREE_TYPE (op0));
> > +   }
> > +   }
> 
> Shouldn't this be a loop?

I don't think so, though my earlier patch had a call to 

+static bool
+cref_has_const_field (tree ref)
+{
+  while (TREE_CODE (ref) == COMPONENT_REF)
+{
+  if (CP_TYPE_CONST_P (TREE_TYPE (TREE_OPERAND (ref, 1
+   return true;
+  ref = TREE_OPERAND (ref, 0);
+}
+  return false;
+}

here.  A problem arised when I checked even the outermost expression (which is 
not a
field_decl), then I saw another problematical error.

The more outer fields are expected to be checked in subsequent calls to
modifying_const_object_p in next iterations of the

4459   for (tree probe = target; object == NULL_TREE; )

loop in cxx_eval_store_expression.

Marek

Re: [committed][ARM] Fix minor testsuite fallout on ARM due to recent IRA changes

[Christophe Lyon]

On Thu, 5 Mar 2020 at 16:49, Jeff Law  wrote:
>
> On Mon, 2020-03-02 at 16:40 +, Richard Earnshaw (lists) wrote:
> > On 02/03/2020 15:46, Jeff Law wrote:
> > > More minor fallout from Vlad's IRA changes.
> > >
> > > Previously this test used r3 to hold a value across a call (it's an ipa-ra
> > > test).  After Vlad's changes we're using r1 instead.
> > >
> > > This patch makes the obvious change to pattern we can for which should 
> > > bring
> > > the test back to a passing status.
> > >
> > > There's a note about r3 being special on thumb1 and the pattern check is
> > > skipped for thumb1.  That special casing my not be necessary anymore -- I
> > > leave
> > > that to the ARM maintainers to resolve one way or the other.
> > >
> > > Committing on the trunk momentarily.
> > >
> > > jeff
> > >
> >
> > Any of r1, r2, r3 could be chosen for the 'save' register, so why not
> > put that in the regexp?
> >
> > Something like:
> >
> > +/* { dg-final { scan-assembler-times "mov\tr[123], r0" 1 { target { !
> > arm_thumb1 } } } } */
> >
> > And then we are future-proof.
> Pushed to the trunk.  Thanks for the suggestion.
>

Hi,

I've just pushed a fix for the obvious typo: [] need to be escaped:
-/* { dg-final { scan-assembler-times "mov\tr[123], r0" 1 { target { !
arm_thumb1 } } } } */
+/* { dg-final { scan-assembler-times "mov\tr\[123\], r0" 1 { target {
! arm_thumb1 } } } } */


Christophe

> jeff
>

Re: [PATCH] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

[Jason Merrill]

On 3/9/20 8:58 AM, Jakub Jelinek wrote:

On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:

On 3/6/20 6:54 PM, Marek Polacek wrote:

I got a report that building Chromium fails with the "modifying a const
object" error.  After some poking I realized it's a bug in GCC, not in
their codebase.

Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
nor the field were declared const.  So let's dial down the checking.
Here the COMPONENT_REF was const because of the "const_cast(m)"
thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
TREE_TYPE (t).


What is folding the const into the COMPONENT_REF?


cxx_eval_component_reference when it is called on
((const struct array *) this)->elems
with /*lval=*/true and lval is true because we are evaluating
 = (const int &) &((const struct array *) 
this)->elems[VIEW_CONVERT_EXPR(n)];


Ah, sure.  We're pretty loose with cv-quals in the constexpr code in 
general, so it's probably not worth trying to change that here.  Getting 
back to the patch:



+  if (TREE_CODE (obj) == COMPONENT_REF)
+   {
+ tree op1 = TREE_OPERAND (obj, 1);
+ if (CP_TYPE_CONST_P (TREE_TYPE (op1)))
+   return true;
+ else
+   {
+ tree op0 = TREE_OPERAND (obj, 0);
+ /* The LHS of . or -> might itself be a COMPONENT_REF.  */
+ if (TREE_CODE (op0) == COMPONENT_REF)
+   op0 = TREE_OPERAND (op0, 1);
+ return CP_TYPE_CONST_P (TREE_TYPE (op0));
+   }
+   }


Shouldn't this be a loop?

Jason

Re: [PATCH v2] c++: Fix ABI issue with alignas on armv7hl [PR94050]

[Jason Merrill]

On 3/8/20 5:33 PM, Marek Polacek wrote:

On Sun, Mar 08, 2020 at 01:25:17AM -0500, Jason Merrill wrote:

On 3/7/20 6:02 PM, Marek Polacek wrote:

On Sat, Mar 07, 2020 at 01:21:41AM -0500, Jason Merrill wrote:

On 3/6/20 8:12 PM, Marek Polacek wrote:

On Fri, Mar 06, 2020 at 05:49:07PM -0500, Jason Merrill wrote:

On 3/5/20 2:40 PM, Marek Polacek wrote:

The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell.  BaseShape's data
takes up 20B on 32-bit architectures, but we failed to round up its
TYPE_SIZE.  This happens since the

patch: here, in layout_class_type for TenuredCell, we see that the size
of TenuredCell and its CLASSTYPE_AS_BASE match, so we set

  CLASSTYPE_AS_BASE (t) = t;

But while TYPE_USER_ALIGN of TenuredCell was 0, TYPE_USER_ALIGN of its
CLASSTYPE_AS_BASE was 1.


Surely the bug is that TYPE_USER_ALIGN isn't set for TenuredCell?


That's my understanding.


So why is that?  Where is setting TYPE_USER_ALIGN on as-base TenuredCell,
and why isn't it setting it on the main type as well?  Or is it getting
cleared on the main type for some reason?


Yeah, it's getting cleared in finalize_type_size, called from
   6703   /* Let the back end lay out the type.  */
   6704   finish_record_layout (rli, /*free_p=*/true);
because finalize_type_size has
1930   /* Don't override a larger alignment requirement coming from a user
1931  alignment of one of the fields.  */
1932   if (mode_align >= TYPE_ALIGN (type))
1933 {
1934   SET_TYPE_ALIGN (type, mode_align);
1935   TYPE_USER_ALIGN (type) = 0;
1936 }
(for aggregates it is only done on STRICT_ALIGNMENT platforms which is why we
   won't see this problem on e.g. i686).

Here's the story of TYPE_USER_ALIGN:
- first we set TYPE_USER_ALIGN on Cell in common_handle_aligned_attribute,
as expected
- in layout_class_type for Cell we copy T_U_A to its as-base type:
TYPE_USER_ALIGN (base_t) = TYPE_USER_ALIGN (t);
- then we call finish_record_layout and T_U_A is cleared on Cell, but not its
as-base type.  In finalize_type_size mode_align == TYPE_ALIGN (type) == 64.
- so in layout_empty_base_or_field we do this:
if (CLASSTYPE_USER_ALIGN (type))
  {
rli->record_align = MAX (rli->record_align, CLASSTYPE_ALIGN (type));
if (warn_packed)
  rli->unpacked_align = MAX (rli->unpacked_align, CLASSTYPE_ALIGN 
(type));
TYPE_USER_ALIGN (rli->t) = 1;
  }
type is Cell and rli->t is TenuredCell
- then in layout_class_type we copy T_U_A from TenuredCell to its as-base type,
then finish_record_layout clears it from the main type
- then we perform the new optimization by replacing the as-base type, making
T_U_A set to 0
- and so BaseShape's T_U_A is never set.

Does this explain things better?


Yes, thanks.  So the problem is the interaction of finalize_type_size
deciding that we don't need TYPE_USER_ALIGN if it's the same alignment we
would get anyway, and layout_empty_base_or_field only adjusting the
alignment if TYPE_USER_ALIGN is set, which happened to work before because
CLASSTYPE_USER_ALIGN was accidentally(?) still set.


I wish we had a comment to that effect -- then we'd know for sure that it
wasn't just an accident.


I think the right behavior is probably to update rli->*_align regardless of
CLASSTYPE_USER_ALIGN (type); if an empty base doesn't have user-specified
aligment, its alignment will be 1, so it shouldn't ever be harmful.  When I
added that code I wasn't aware of the finalize_type_size behavior.


And given it only triggers on STRICT_ALIGNMENT, no wonder we haven't seen this
before.


But I'm not confident that won't be an ABI break itself, so let's go ahead
with your approach for GCC 10, except


Yeah, it's tricky stuff :/


+  /* If T's CLASSTYPE_AS_BASE is TYPE_USER_ALIGN, but T is not,
+replacing the as-base type would change CLASSTYPE_USER_ALIGN,
+causing us to lose the user-specified alignment as in PR94050.  */
+  && !CLASSTYPE_USER_ALIGN (t)


How about

&& CLASSTYPE_USER_ALIGN (t) == CLASSTYPE_USER_ALIGN (CLASSTYPE_AS_BASE (t))


Presumably you mean TYPE_USER_ALIGN, but sure.  Thanks,

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


OK, thanks.


-- >8 --
The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell.  BaseShape's data
takes up 20B on 32-bit architectures, but we failed to round up its
TYPE_SIZE.  This happens since the

patch: here, in layout_class_type for TenuredCell, we see that the size
of TenuredCell and its CLASSTYPE_AS_BASE match, so we set

   CLASSTYPE_AS_BASE (t) = t;

While TYPE_USER_ALIGN of TenuredCell was 0, because finalize_type_size
called from finish_record_layout reset it, TYPE_USER_ALIGN of its
CLASSTYPE_AS_BASE still 

Re: [PATCH] Restore alignment in rs6000 target.

[Martin Liška]

On 3/6/20 6:07 PM, Segher Boessenkool wrote:

On Fri, Mar 06, 2020 at 02:07:15PM +0100, Martin Liška wrote:

After r9-1623-gc518c1025b435e1c593a745036fc9b8ed04c5819 the code was
changed to:

- if (align_jumps_max_skip <= 0)
-   align_jumps_max_skip = 15;
- if (align_loops_max_skip <= 0)
-   align_loops_max_skip = 15;
+
+ if (flag_align_jumps && !str_align_jumps)
+   str_align_jumps = "16";
+ if (flag_align_loops && !str_align_loops)
+   str_align_loops = "16";

which for situation where align_* was 0 caused that max_skip didn't play
any role.
My code wrongly changed that to str_align_jumps, which is now the was which
includes
both alignment (and max skip). The hunk should not be here.


Do you have a testsuite test as well?  Or, how else was this checked?


Yes, I've extended the patch by addition of a test-case.




PR target/93800
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Remove set of str_align_loops and str_align_jumps as these
should be set in previous 2 conditions in the function.


Okay for trunk, maybe with an added test.  Thanks!


I'm going to install the patch.
Martin




Segher

Re: [PATCH][DOCS] Document -fprofile-reproducible.

[Martin Liška]

On 3/2/20 1:26 PM, Martin Liška wrote:

Hi.

It's a documentation update for the new -fprofile-reproducible option.

Martin

---
  htdocs/gcc-10/changes.html | 6 ++
  1 file changed, 6 insertions(+)




Installed as 451b55cd9e598edff705b6dd3c4af496472aecef.

Martin

Re: [PATCH] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

[Jakub Jelinek]

On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
> On 3/6/20 6:54 PM, Marek Polacek wrote:
> > I got a report that building Chromium fails with the "modifying a const
> > object" error.  After some poking I realized it's a bug in GCC, not in
> > their codebase.
> > 
> > Much like with ARRAY_REFs, which can be const even though the array
> > itself isn't, COMPONENT_REFs can be const although neither the object
> > nor the field were declared const.  So let's dial down the checking.
> > Here the COMPONENT_REF was const because of the "const_cast(m)"
> > thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
> > TREE_TYPE (t).
> 
> What is folding the const into the COMPONENT_REF?

cxx_eval_component_reference when it is called on
((const struct array *) this)->elems
with /*lval=*/true and lval is true because we are evaluating
 = (const int &) &((const struct array *) 
this)->elems[VIEW_CONVERT_EXPR(n)];

Jakub

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[Richard Biener]

On Mon, Mar 9, 2020 at 1:14 PM Richard Sandiford
 wrote:
>
> Thanks for doing this.
>
> "J.W. Jagersma"  writes:
> > On 2020-03-07 20:20, Segher Boessenkool wrote:
> >> Hi!
> >>
> >> On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
> >>> The following patch extends the generation of exception handling
> >>> information to cover volatile asms too.  This was already mostly
> >>> implemented, and only minor changes are required in order to make it
> >>> work.
> >>
> >> This should wait for stage 1, IMO.  Looks pretty good to me, thanks!
> >
> > Hi, thanks for your response.
> > What does stage 1 refer to?  I'm sorry, this is my first gcc patch and
> > I'm still learning how this all works.
> >
> >> Some comments:
> >>
> >>> +When non-call exceptions (@option{-fnon-call-exceptions}) are enabled, a
> >>> +@code{volatile asm} statement is also allowed to throw exceptions.  If it
> >>> +does, then the compiler assumes that its output operands have not been 
> >>> written
> >>> +yet.
> >>
> >> That reads as if the compiler assumes the outputs retain their original
> >> value, but that isn't true (I hope!)  The compiler assumes the output
> >> are clobbered, but it doesn't assume they are assigned any definite
> >> value?
> >
> > Register outputs are assumed to be clobbered, yes.  For memory outputs
> > this is not the case, if the asm writes it before throwing then the
> > memory operand retains this value.  It should be the user's
> > responsibility to ensure that an asm has no side-effects if it throws.
>
> I guess one problem is that something like "=" explicitly says that
> the operand is clobbered "early", and I think it would be fair for
> "early" to include clobbers before the exception.  So IMO we should
> allow at least early-clobbered memory outputs to be clobbered by the
> exception.

I think memory operands are fine - my original concern was about
register outputs and SSA form that should reflect the correct def
on the EH vs non-EH edge.  From a "miscompile" perspective
doing nothig which means pretending the asm actually set the output
could lead us to false DCE of the old value:

int foo = 0
try
  {
asm volatile ("..." : "=r" (foo));
  }
catch (...whatever...)
  {
foo should be still zero, but SSA doesn't have the correct use here
  }

that means the compiler really assumes the asm will populate the outputs
even when it throws.

Test coverage for that would be nice.

> And if we do that, then I'm not sure there's much benefit in trying to
> treat the non-earlyclobber memory case specially.
>
> It would be good to have testcases for the output cases.  E.g. for:
>
> int foo;
> int bar = 0;
> try
>   {
> foo = 1;
> asm volatile ("..." : "=m" (foo));
>   }
> catch (...whatever...)
>   {
> bar = foo;
>   }
> ...use bar...
>
> What does "bar = foo" read?  Is it always undefined behaviour if executed?
> Or does it always read "foo" from memory?  Can it be optimised to "bar = 1"?
> Is "foo = 1" dead code?
>
> Thanks,
> Richard

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[Richard Sandiford]

Thanks for doing this.

"J.W. Jagersma"  writes:
> On 2020-03-07 20:20, Segher Boessenkool wrote:
>> Hi!
>> 
>> On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
>>> The following patch extends the generation of exception handling
>>> information to cover volatile asms too.  This was already mostly
>>> implemented, and only minor changes are required in order to make it
>>> work.
>> 
>> This should wait for stage 1, IMO.  Looks pretty good to me, thanks!
>
> Hi, thanks for your response.
> What does stage 1 refer to?  I'm sorry, this is my first gcc patch and
> I'm still learning how this all works.
>
>> Some comments:
>> 
>>> +When non-call exceptions (@option{-fnon-call-exceptions}) are enabled, a
>>> +@code{volatile asm} statement is also allowed to throw exceptions.  If it
>>> +does, then the compiler assumes that its output operands have not been 
>>> written
>>> +yet.
>> 
>> That reads as if the compiler assumes the outputs retain their original
>> value, but that isn't true (I hope!)  The compiler assumes the output
>> are clobbered, but it doesn't assume they are assigned any definite
>> value?
>
> Register outputs are assumed to be clobbered, yes.  For memory outputs
> this is not the case, if the asm writes it before throwing then the
> memory operand retains this value.  It should be the user's
> responsibility to ensure that an asm has no side-effects if it throws.

I guess one problem is that something like "=" explicitly says that
the operand is clobbered "early", and I think it would be fair for
"early" to include clobbers before the exception.  So IMO we should
allow at least early-clobbered memory outputs to be clobbered by the
exception.

And if we do that, then I'm not sure there's much benefit in trying to
treat the non-earlyclobber memory case specially.

It would be good to have testcases for the output cases.  E.g. for:

int foo;
int bar = 0;
try
  {
foo = 1;
asm volatile ("..." : "=m" (foo));
  }
catch (...whatever...)
  {
bar = foo;
  }
...use bar...

What does "bar = foo" read?  Is it always undefined behaviour if executed?
Or does it always read "foo" from memory?  Can it be optimised to "bar = 1"?
Is "foo = 1" dead code?

Thanks,
Richard

Re: [PATCH] alias: Punt after walking too many VALUEs during a toplevel find_base_term call [PR94045]

[Richard Biener]

On Mon, 9 Mar 2020, Jakub Jelinek wrote:

> Hi!
> 
> As mentioned in the PR, on a largish C++ testcase the compile time
> on i686-linux is about 16 minutes on a fast box, mostly spent in
> find_base_term recursive calls dealing with very deep chains of preserved
> VALUEs during var-tracking.
> 
> The following patch punts after we process many VALUEs (we already have code
> to punt if we run into a VALUE cycle).
> 
> I've gathered statistics on when we punt this way (with BITS_PER_WORD, TU,
> function columns piped through sort | uniq -c | sort -n):
>  36 32 ../../gcc/asan.c _Z29initialize_sanitizer_builtinsv.part.0
> 108 32 _first_test.go reflect_test.reflect_test..import
>1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
>1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
>1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
>1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
>2534 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/stack-check-9.c f3
>6346 32 ../../gcc/brig/brig-lang.c brig_define_builtins
>6398 32 ../../gcc/d/d-builtins.cc d_define_builtins
>8816 32 ../../gcc/c-family/c-common.c c_common_nodes_and_builtins
>8824 32 ../../gcc/lto/lto-lang.c lto_define_builtins
>   41413 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr43058.c test
> Additionally, for most of these (for the builtins definitions tested just
> one) I've verified with a different alias.c change which didn't punt but
> in the toplevel find_base_term recorded if visited_vals reached the limit
> whether the return value was NULL_RTX or something different, and in all
> these cases the end result was NULL_RTX, so at least in these cases it
> should just shorten the time until it returns NULL.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux. 

OK.

Thanks,
Richard.

> 2020-03-09  Jakub Jelinek  
> 
>   PR rtl-optimization/94045
>   * params.opt (-param=max-find-base-term-values=): New option.
>   * alias.c (find_base_term): Add cut-off for number of visited VALUEs
>   in a single toplevel find_base_term call.
> 
> --- gcc/params.opt.jj 2020-02-18 08:54:22.560195942 +0100
> +++ gcc/params.opt2020-03-06 12:56:28.607705143 +0100
> @@ -662,6 +662,10 @@ Max. size of loc list for which reverse
>  Common Joined UInteger Var(param_max_vartrack_size) Init(5000) Param 
> Optimization
>  Max. size of var tracking hash tables.
>  
> +-param=max-find-base-term-values=
> +Common Joined UInteger Var(param_max_find_base_term_values) Init(2000) Param 
> Optimization
> +Maximum number of VALUEs handled during a single find_base_term call.
> +
>  -param=max-vrp-switch-assertions=
>  Common Joined UInteger Var(param_max_vrp_switch_assertions) Init(10) Param 
> Optimization
>  Maximum number of assertions to add along the default edge of a switch 
> statement during VRP.
> --- gcc/alias.c.jj2020-03-05 15:13:14.391513145 +0100
> +++ gcc/alias.c   2020-03-06 12:59:25.388101668 +0100
> @@ -2005,6 +2005,9 @@ find_base_term (rtx x, vecif (cselib_sp_based_value_p (val))
>   return static_reg_base_value[STACK_POINTER_REGNUM];
>  
> +  if (visited_vals.length () > (unsigned) 
> param_max_find_base_term_values)
> + return ret;
> +
>f = val->locs;
>/* Reset val->locs to avoid infinite recursion.  */
>if (f)
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[PATCH] alias: Punt after walking too many VALUEs during a toplevel find_base_term call [PR94045]

[Jakub Jelinek]

Hi!

As mentioned in the PR, on a largish C++ testcase the compile time
on i686-linux is about 16 minutes on a fast box, mostly spent in
find_base_term recursive calls dealing with very deep chains of preserved
VALUEs during var-tracking.

The following patch punts after we process many VALUEs (we already have code
to punt if we run into a VALUE cycle).

I've gathered statistics on when we punt this way (with BITS_PER_WORD, TU,
function columns piped through sort | uniq -c | sort -n):
 36 32 ../../gcc/asan.c _Z29initialize_sanitizer_builtinsv.part.0
108 32 _first_test.go reflect_test.reflect_test..import
   1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
   1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
   1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
   1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
   2534 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/stack-check-9.c f3
   6346 32 ../../gcc/brig/brig-lang.c brig_define_builtins
   6398 32 ../../gcc/d/d-builtins.cc d_define_builtins
   8816 32 ../../gcc/c-family/c-common.c c_common_nodes_and_builtins
   8824 32 ../../gcc/lto/lto-lang.c lto_define_builtins
  41413 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr43058.c test
Additionally, for most of these (for the builtins definitions tested just
one) I've verified with a different alias.c change which didn't punt but
in the toplevel find_base_term recorded if visited_vals reached the limit
whether the return value was NULL_RTX or something different, and in all
these cases the end result was NULL_RTX, so at least in these cases it
should just shorten the time until it returns NULL.

Bootstrapped/regtested on x86_64-linux and i686-linux. 

2020-03-09  Jakub Jelinek  

PR rtl-optimization/94045
* params.opt (-param=max-find-base-term-values=): New option.
* alias.c (find_base_term): Add cut-off for number of visited VALUEs
in a single toplevel find_base_term call.

--- gcc/params.opt.jj   2020-02-18 08:54:22.560195942 +0100
+++ gcc/params.opt  2020-03-06 12:56:28.607705143 +0100
@@ -662,6 +662,10 @@ Max. size of loc list for which reverse
 Common Joined UInteger Var(param_max_vartrack_size) Init(5000) Param 
Optimization
 Max. size of var tracking hash tables.
 
+-param=max-find-base-term-values=
+Common Joined UInteger Var(param_max_find_base_term_values) Init(2000) Param 
Optimization
+Maximum number of VALUEs handled during a single find_base_term call.
+
 -param=max-vrp-switch-assertions=
 Common Joined UInteger Var(param_max_vrp_switch_assertions) Init(10) Param 
Optimization
 Maximum number of assertions to add along the default edge of a switch 
statement during VRP.
--- gcc/alias.c.jj  2020-03-05 15:13:14.391513145 +0100
+++ gcc/alias.c 2020-03-06 12:59:25.388101668 +0100
@@ -2005,6 +2005,9 @@ find_base_term (rtx x, vec (unsigned) param_max_find_base_term_values)
+   return ret;
+
   f = val->locs;
   /* Reset val->locs to avoid infinite recursion.  */
   if (f)

Jakub

Re: [PATCH] [COMMITTED] arc: Add ARC entry for gcc-10/changes.html

[Claudiu Zissulescu]

It looks great  I'll keep in mind this tip next time.

Thank you,
Clauidu

From: Gerald Pfeifer 
Sent: Saturday, March 7, 2020 11:05 PM
To: Claudiu Zissulescu ; Martin Sebor 
Cc: gcc-patches@gcc.gnu.org ; Jeff Law 
; Francois Bedard ; Claudiu Zissulescu 
; andrew.burg...@embecosm.com 

Subject: Re: [PATCH] [COMMITTED] arc: Add ARC entry for gcc-10/changes.html

On Tue, 3 Mar 2020, Claudiu Zissulescu wrote:
> Add ARC entry for gcc-10/changes.html

What do you think of the following refinement to mark up
mov and ior as code?

Gerald

PS: And thanks for your other feedback, Martin!

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 710e3863..5ba388cf 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -562,9 +562,9 @@ a work-in-progress.
   The interrupt service routine functions save all used
   registers, including extension registers and auxiliary registers
   used by Zero Overhead Loops.
-  Improve code size by using multiple short instructions instead
-  of a single long mov or ior instruction when its long immediate
-  constant is known.
+  Improve code size by using multiple short instructions instead of
+  a single long mov or ior instruction when its
+  long immediate constant is known.
   Fix usage of the accumulator register for ARC600.
   Fix issues with uncached attribute.
   Remove -mq-class option.

Re: ACLE intrinsics: BFloat16 load intrinsics for AArch32

[Christophe Lyon]

On Fri, 6 Mar 2020 at 11:46, Kyrill Tkachov  wrote:
>
> Hi Delia,
>
> On 3/5/20 4:38 PM, Delia Burduv wrote:
> > Hi,
> >
> > This is the latest version of the patch. I am forcing -mfloat-abi=hard
> > because the code generated is slightly differently depending on the
> > float-abi used.
>
>
> Thanks, I've pushed it with an updated ChangeLog.
>
> 2020-03-06  Delia Burduv  
>
>  * config/arm/arm_neon.h (vld2_bf16): New.
>  (vld2q_bf16): New.
>  (vld3_bf16): New.
>  (vld3q_bf16): New.
>  (vld4_bf16): New.
>  (vld4q_bf16): New.
>  (vld2_dup_bf16): New.
>  (vld2q_dup_bf16): New.
>  (vld3_dup_bf16): New.
>  (vld3q_dup_bf16): New.
>  (vld4_dup_bf16): New.
>  (vld4q_dup_bf16): New.
>  * config/arm/arm_neon_builtins.def
>  (vld2): Changed to VAR13 and added v4bf, v8bf
>  (vld2_dup): Changed to VAR8 and added v4bf, v8bf
>  (vld3): Changed to VAR13 and added v4bf, v8bf
>  (vld3_dup): Changed to VAR8 and added v4bf, v8bf
>  (vld4): Changed to VAR13 and added v4bf, v8bf
>  (vld4_dup): Changed to VAR8 and added v4bf, v8bf
>  * config/arm/iterators.md (VDXBF2): New iterator.
>  *config/arm/neon.md (neon_vld2): Use new iterators.
>  (neon_vld2_dup  (neon_vld3): Likewise.
>  (neon_vld3qa): Likewise.
>  (neon_vld3qb): Likewise.
>  (neon_vld3_dup): Likewise.
>  (neon_vld4): Likewise.
>  (neon_vld4qa): Likewise.
>  (neon_vld4qb): Likewise.
>  (neon_vld4_dup): Likewise.
>  (neon_vld2_dupv8bf): New.
>  (neon_vld3_dupv8bf): Likewise.
>  (neon_vld4_dupv8bf): Likewise.
>
> Kyrill

Hi!

There's a problem with the arm_neon.h update.
on arm-none-linux-gnueabihf, there is a regression on
g++.dg/other/pr54300.C and g++.dg/other/pr55073.C, because:
FAIL: g++.dg/other/pr54300.C  -std=gnu++98 (test for excess errors)
Excess errors:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/gcc/include/arm_neon.h:19565:39:
error: cannot convert 'const short int*' to 'const __bf16*'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/gcc/include/arm_neon.h:19574:39:
error: cannot convert 'const short int*' to 'const __bf16*'
[]

The same problem makes a lot (~365) of tests become unsupported on
arm-none-linux-gnueabi:
g++.dg/abi/mangle-arm-crypto.C
g++.dg/abi/mangle-neon.C

Can you fix it?

Thanks

Christophe

>
>
> >
> > Thanks,
> > Delia
> >
> > On 3/4/20 5:20 PM, Kyrill Tkachov wrote:
> >> Hi Delia,
> >>
> >> On 3/4/20 2:05 PM, Delia Burduv wrote:
> >>> Hi,
> >>>
> >>> The previous version of this patch shared part of its code with the
> >>> store intrinsics patch
> >>> (https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00145.html) so I removed
> >>> any duplicated code. This patch now depends on the previously mentioned
> >>> store intrinsics patch.
> >>>
> >>> Here is the latest version and the updated ChangeLog.
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>> 2019-03-04  Delia Burduv  
> >>>
> >>> * config/arm/arm_neon.h (bfloat16_t): New typedef.
> >>>  (vld2_bf16): New.
> >>> (vld2q_bf16): New.
> >>> (vld3_bf16): New.
> >>> (vld3q_bf16): New.
> >>> (vld4_bf16): New.
> >>> (vld4q_bf16): New.
> >>> (vld2_dup_bf16): New.
> >>> (vld2q_dup_bf16): New.
> >>>  (vld3_dup_bf16): New.
> >>> (vld3q_dup_bf16): New.
> >>> (vld4_dup_bf16): New.
> >>> (vld4q_dup_bf16): New.
> >>>  * config/arm/arm_neon_builtins.def
> >>>  (vld2): Changed to VAR13 and added v4bf, v8bf
> >>>  (vld2_dup): Changed to VAR8 and added v4bf, v8bf
> >>>  (vld3): Changed to VAR13 and added v4bf, v8bf
> >>>  (vld3_dup): Changed to VAR8 and added v4bf, v8bf
> >>>  (vld4): Changed to VAR13 and added v4bf, v8bf
> >>>  (vld4_dup): Changed to VAR8 and added v4bf, v8bf
> >>>  * config/arm/iterators.md (VDXBF): New iterator.
> >>>  (VQ2BF): New iterator.
> >>>  *config/arm/neon.md (vld2): Used new iterators.
> >>>  (vld2_dup): Used new iterators.
> >>>  (vld2_dupv8bf): New.
> >>>  (vst3): Used new iterators.
> >>>  (vst3qa): Used new iterators.
> >>>  (vst3qb): Used new iterators.
> >>>  (vld3_dup): Used new iterators.
> >>>  (vld3_dupv8bf): New.
> >>>  (vst4): Used new iterators.
> >>>  (vst4qa): Used new iterators.
> >>>  (vst4qb): Used new iterators.
> >>>  (vld4_dup): Used new iterators.
> >>>  (vld4_dupv8bf): New.
> >>>
> >>>
> >>> gcc/testsuite/ChangeLog:
> >>>
> >>> 2019-03-04  Delia Burduv  
> >>>
> >>> * gcc.target/arm/simd/bf16_vldn_1.c: New test.
> >>>
> >>> Thanks,
> >>> Delia
> >>>
> >>> On 2/19/20 5:25 PM, Delia Burduv wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Here is the latest version of the patch. It just has some minor
> >>> > formatting changes that were brought up by Richard Sandiford in the
> >>> > AArch64 patches
> >>> >
> >>> > 

[PATCH][RFC] API extension for binutils (type of symbols).

[Martin Liška]

Hi.

With change of -fno-common default for GCC 10 we're facing serious
problem with LTO where one can't distinguish in between global symbols
and variables based on the output of nm:
https://sourceware.org/bugzilla/show_bug.cgi?id=25355

$ cat nm.c
char nm_test_var;

$ gcc-9 nm.c -c -fno-common
$ nm nm.o
 B nm_test_var

$ gcc-9 nm.c -c -fno-common -flto
$ nm nm.o
 T nm_test_var

H.J. decided to implement quite heavy solution which is about usage of 
lto-wrapper
that takes a LTO object file and makes a final assembly file. The file is then
utilized with nm. That has some disadvantages:

- it's slow - using nm x.a can take very long time
- way of finding lto-wrapper is quite hard-coded to location of LTO plugin
- we face issues with multiple final object files:
  https://sourceware.org/bugzilla/show_bug.cgi?id=25640

That said, I'm suggesting to expect LTO plugin API to tell binutils whether
a symbol is variable or function. That should help us to mark global variables
with "D" in nm output.

I would like to note that even with -fcommon, the nm output for LTO bytecode is 
far
from perfect:

$ cat bss.c
int global_zero;
int global_one = 1;

$ gcc-9 bss.c -c  -flto
$ nm bss.o
 T global_one
 C global_zero

I believe in this case we can mark both symbols with D as a reasonable guess.

Thoughts?
Martin

gcc/ChangeLog:

2020-03-09  Martin Liska  

* lto-streamer-out.c (write_symbol): Stream
symbol type.

include/ChangeLog:

2020-03-09  Martin Liska  

* lto-symtab.h (enum gcc_plugin_symbol_type): New.
* plugin-api.h (struct ld_plugin_symbol): New member
symbols_type.
(enum ld_plugin_symbol_type): New.
(enum ld_plugin_tag): Add new tag LDPT_GET_SYMBOLS_V4.

lto-plugin/ChangeLog:

2020-03-09  Martin Liska  

* lto-plugin.c (parse_table_entry): Parse symbol type.
---
 gcc/lto-streamer-out.c  |  2 ++
 include/lto-symtab.h|  7 +++
 include/plugin-api.h| 13 -
 lto-plugin/lto-plugin.c | 12 
 4 files changed, 33 insertions(+), 1 deletion(-)

Fwd: [PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums

[Bin.Cheng]

Forwarding to public list.

-- Forwarded message -
From: Bin.Cheng 
Date: Mon, Mar 9, 2020 at 5:07 PM
Subject: Re: [PATCH PR93674]Avoid introducing IV of enumeral type in
case of -fstrict-enums
To: Richard Biener 


On Tue, Mar 3, 2020 at 5:36 PM Richard Biener
 wrote:
>
> On Mon, Mar 2, 2020 at 6:14 PM Andrew Pinski  wrote:
> >
> > On Mon, Mar 2, 2020 at 1:40 AM Richard Biener
> >  wrote:
> > >
> > > On Mon, Mar 2, 2020 at 9:07 AM bin.cheng  
> > > wrote:
> > > >
> > > > Hi,
> > > > This is a simple fix for PR93674.  It adds cand carefully for enumeral 
> > > > type iv_use in
> > > > case of -fstrict-enums, it also avoids computing, replacing iv_use with 
> > > > the candidate
> > > > so that no IV of enumeral type is introduced with -fstrict-enums option.
> > > >
> > > > Testcase is also added.  Bootstrap and test on x86_64.  Any comment?
> > >
> > > I think we should avoid enum-typed (or bool-typed) IVs in general, not 
> > > just
> > > with -fstrict-enums.  That said, the ENUMERAL_TYPE checks should be
> > > !(INTEGER_TYPE || POINTER_TYPE_P) checks.
> >
> > Maybe even check type_has_mode_precision_p or
> > TYPE_MIN_VALUE/TYPE_MAX_VALUE have the same as the min/max for that
> > precision/signedness.
>
> Indeed we don't want non-mode precision INTEGER_TYPE IVs either.  I wouldn't
> check TYPE_MIN/MAX_VALUE here though.

Thank all of you for the suggestions, I will update the change.
>
> Richard.
>
> > Thanks,
> > Andrew
> >
> > >
> > > +  /* Check if cand can represent values of use for strict enums.  */
> > > +  else if (TREE_CODE (ctype) == ENUMERAL_TYPE && flag_strict_enums)
> > > +{
> > >
> > > if we don't have enum-typed IV candidates then the computation should
> > > be carried out in INTEGER_TYPE and then be converted to enum type.
> > > So why's this and the may_eliminate_iv hunks necessary?
I was wondering if enum variable is used directly as loop variable?
Note above check
only happens for adding candidate for derived iv use.

Thanks,
bin
> > >
> > > Richard.
> > >
> > > > Thanks,
> > > > bin
> > > > 2020-03-02  Bin Cheng  
> > > >
> > > > PR tree-optimization/93674
> > > > * tree-ssa-loop-ivopts.c (add_iv_candidate_for_use): Add 
> > > > candidate
> > > > for enumeral type iv_use converted from other iv.
> > > > (get_computation_cost, may_eliminate_iv): Avoid compute, 
> > > > eliminate
> > > > iv_use with enumeral type iv_cand in case of -fstrict-enums.
> > > >
> > > > gcc/testsuite
> > > > 2020-03-02  Bin Cheng  
> > > >
> > > > PR tree-optimization/93674
> > > > * g++.dg/pr93674.C: New test.

[PATCH] pch: Specify reason of -Winvalid-pch warning [PR86674]

[Nicholas Guriev]

gcc/c-family/ChangeLog:

PR pch/86674
* c-pch.c (c_common_valid_pch): Use cpp_warning with CPP_W_INVALID_PCH
reason to fix -Werror=invalid-pch and -Wno-error=invalid-pch switches.
---
 gcc/c-family/ChangeLog |  6 ++
 gcc/c-family/c-pch.c   | 40 +++-
 libcpp/files.c |  2 +-
 3 files changed, 22 insertions(+), 26 deletions(-)

diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index 2e11b..1c83eeb0f 100644
--- a/gcc/c-family/ChangeLog
+++ b/gcc/c-family/ChangeLog
@@ -1,3 +1,9 @@
+2020-03-09  Nicholas Guriev 
+
+   PR pch/86674
+   * c-pch.c (c_common_valid_pch): Use cpp_warning with CPP_W_INVALID_PCH
+   reason to fix -Werror=invalid-pch and -Wno-error=invalid-pch switches.
+
 2020-03-02  Marek Polacek  
 
PR c++/93958 - add missing -std=gnu++20.
diff --git a/gcc/c-family/c-pch.c b/gcc/c-family/c-pch.c
index a2292f46a..9c0bd0b63 100644
--- a/gcc/c-family/c-pch.c
+++ b/gcc/c-family/c-pch.c
@@ -211,8 +211,7 @@ c_common_valid_pch (cpp_reader *pfile, const char *name, 
int fd)
 fatal_error (input_location, "cannot read %s: %m", name);
   else if (sizeread != IDENT_LENGTH + 16)
 {
-  if (cpp_get_options (pfile)->warn_invalid_pch)
-   cpp_error (pfile, CPP_DL_WARNING, "%s: too short to be a PCH file",
+  cpp_warning (pfile, CPP_W_INVALID_PCH, "%s: too short to be a PCH file",
   name);
   return 2;
 }
@@ -220,27 +219,22 @@ c_common_valid_pch (cpp_reader *pfile, const char *name, 
int fd)
   pch_ident = get_ident();
   if (memcmp (ident, pch_ident, IDENT_LENGTH) != 0)
 {
-  if (cpp_get_options (pfile)->warn_invalid_pch)
-   {
- if (memcmp (ident, pch_ident, 5) == 0)
-   /* It's a PCH, for the right language, but has the wrong version.
-*/
-   cpp_error (pfile, CPP_DL_WARNING,
+   if (memcmp (ident, pch_ident, 5) == 0)
+ /* It's a PCH, for the right language, but has the wrong version.  */
+ cpp_warning (pfile, CPP_W_INVALID_PCH,
   "%s: not compatible with this GCC version", name);
- else if (memcmp (ident, pch_ident, 4) == 0)
-   /* It's a PCH for the wrong language.  */
-   cpp_error (pfile, CPP_DL_WARNING, "%s: not for %s", name,
+   else if (memcmp (ident, pch_ident, 4) == 0)
+ /* It's a PCH for the wrong language.  */
+ cpp_warning (pfile, CPP_W_INVALID_PCH, "%s: not for %s", name,
   lang_hooks.name);
- else
-   /* Not any kind of PCH.  */
-   cpp_error (pfile, CPP_DL_WARNING, "%s: not a PCH file", name);
-   }
+   else
+ /* Not any kind of PCH.  */
+ cpp_warning (pfile, CPP_W_INVALID_PCH, "%s: not a PCH file", name);
   return 2;
 }
   if (memcmp (ident + IDENT_LENGTH, executable_checksum, 16) != 0)
 {
-  if (cpp_get_options (pfile)->warn_invalid_pch)
-   cpp_error (pfile, CPP_DL_WARNING,
+  cpp_warning (pfile, CPP_W_INVALID_PCH,
   "%s: created by a different GCC executable", name);
   return 2;
 }
@@ -257,8 +251,7 @@ c_common_valid_pch (cpp_reader *pfile, const char *name, 
int fd)
   if (v.debug_info_type != write_symbols
   && write_symbols != NO_DEBUG)
 {
-  if (cpp_get_options (pfile)->warn_invalid_pch)
-   cpp_error (pfile, CPP_DL_WARNING,
+  cpp_warning (pfile, CPP_W_INVALID_PCH,
   "%s: created with -g%s, but used with -g%s", name,
   debug_type_names[v.debug_info_type],
   debug_type_names[write_symbols]);
@@ -271,8 +264,7 @@ c_common_valid_pch (cpp_reader *pfile, const char *name, 
int fd)
 for (i = 0; i < MATCH_SIZE; i++)
   if (*pch_matching[i].flag_var != v.match[i])
{
- if (cpp_get_options (pfile)->warn_invalid_pch)
-   cpp_error (pfile, CPP_DL_WARNING,
+ cpp_warning (pfile, CPP_W_INVALID_PCH,
   "%s: settings for %s do not match", name,
   pch_matching[i].flag_name);
  return 2;
@@ -287,8 +279,7 @@ c_common_valid_pch (cpp_reader *pfile, const char *name, 
int fd)
  check one function.  */
   if (v.pch_init != _init)
 {
-  if (cpp_get_options (pfile)->warn_invalid_pch)
-   cpp_error (pfile, CPP_DL_WARNING,
+  cpp_warning (pfile, CPP_W_INVALID_PCH,
   "%s: had text segment at different address", name);
   return 2;
 }
@@ -305,8 +296,7 @@ c_common_valid_pch (cpp_reader *pfile, const char *name, 
int fd)
 free (this_file_data);
 if (msg != NULL)
   {
-   if (cpp_get_options (pfile)->warn_invalid_pch)
- cpp_error (pfile, CPP_DL_WARNING, "%s: %s", name, msg);
+   cpp_warning (pfile, CPP_W_INVALID_PCH, "%s: %s", name, msg);
return 2;
   }
   }
diff --git a/libcpp/files.c b/libcpp/files.c
index 260e787c3..a282263c6 100644
--- a/libcpp/files.c
+++ b/libcpp/files.c
@@ -576,7 

Re: Bind to std::equal plumbing in ranges::equal

[François Dumont]

On 3/6/20 11:12 AM, Jonathan Wakely wrote:

On 06/03/20 10:09 +, Jonathan Wakely wrote:

On 06/03/20 07:06 +0100, François Dumont wrote:
I started to work on ranges::equal to find out if what I am trying 
to do is totally silly.


With this patch ranges::equal is in pare with std::equal 
specializations that is to say that it correctly deals with Debug 
mode or std::deque iterators.


Once below patch is in:

https://gcc.gnu.org/ml/libstdc++/2019-12/msg00032.html

We will even be able to call std::__equal_aux1 directly using 
__niter_base to get rid of the Debug safe iterator layer. And even 
in this case get rid of the branch __use_memcmp and leave it to 
__equal_aux1.


I mainly fear the usage of std::iterator_traits in __equal_aux1 to 
be a problem. Is it in this context of sized_sentinel ?


I don't understand the question. No sentinel of type _Sent1 or _Sent2
gets passed to __equal_aux1 with your patch, you only pass iterators.


I just thought that std::iterator_traits was becoming somehow obsolete 
is the more recent Standard and that it was the reason for not using 
existing std algos.





But I think the patch is wrong:


+  return !std::__memcmp(__first1, __first2, __d1);
+    else
+  return std::__equal_aux(__first1, __first1 + __d1, 
__first2);


This last line will only compile if _Iter1 is random access, but all
we know at this point is that _Sent1 is a sized sentinel for _Iter1.
That doesn't mean it's necessarily random access.


Please try the example at https://wg21.link/counted.iterator#2 which
uses counted_iterator::iterator> and default_sentinel.
The sized_sentinel_for concept is satisfied, but you can't do first1+d1.


Thanks for this example, now I know what has to be supported. I'll see 
if I can find a solution before you do.


François