Request for becoming a contributor

2019-10-10 Thread Harsh Arora
   Hi,

I would love to provide a guest contribution to your blog.

Let me know what you think. I'm excited to hear back from you!

Keep Up The Good Work.

Best,
Harsh


Re: [PATCH] Modify simplify_truncation to handle extended CONST_INT.

2019-10-10 Thread Richard Sandiford
Jim Wilson  writes:
> This addresses PR 91860 which has four testcases triggering internal errors.
> The problem here is that in combine when handling debug insns, we are trying
> to substitute
> (sign_extend:DI (const_int 8160 [0x1fe0]))
> as the value for
> (reg:DI 78 [ _9 ])
> in the debug insn
> (debug_insn 29 28 30 2 (var_location:QI d (subreg:QI (reg:DI 78 [ _9 ]) 0)) 
> "tmp4.c":11:5 -1
>  (nil))
>
> The place where this starts to go wrong is in simplify_truncation, where it
> tries to compare the size of the original mode VOIDmode with the subreg mode
> QI and decides that we need to sign extend the constant to convert it from
> VOIDmode to QImode.  We actually need a truncation not a extension here.  Also
> note that the GET_MODE_UNIT_PRECISION (VOIDmode) isn't useful.  We can fix
> this by changing the mode to MAX_MODE_INT, as the CONST_INT should already be
> valid for the largest supported integer mode.  There are already a number of
> other places in simplify-rtx.c that do the same thing.
>
> This was tested with rv32/newlib and rv64/linux cross builds and make checks.
> There were no regressions.  The new tests all fail for rv64 without the patch,
> and work with the patch.

subst tries to avoid creating invalid (zero_extend:DI (const_int N)):

  else if (CONST_SCALAR_INT_P (new_rtx)
   && (GET_CODE (x) == ZERO_EXTEND
   || GET_CODE (x) == FLOAT
   || GET_CODE (x) == UNSIGNED_FLOAT))

Does adding SIGN_EXTEND to the list fix the bug?

I guess SIGN_EXTEND was excluded here (and in a couple of other places
in combine) on the basis that CONST_INTs are naturally sign-extended,
so the substitution doesn't lose information.  But is a SIGN_EXTEND
of a CONST_INT really valid rtl?  I agree with what you said in the PR
that it shouldn't be, for two reasons:

(1) SIGN_EXTENDs operate on distinct source and destination modes
(unlike binary operations that operate on one mode).  The natural
way of getting the source mode is GET_MODE (XEXP (x, 0)), and allowing
CONST_INTs means that potentially any code processing SIGN_EXTENDs
would need to check for CONST_INTs before using GET_MODE.

(2) we're still finding cases in which CONST_INTs aren't properly
canonicalised into sign-extended form.  Allowing SIGN_EXTENDs
of them turns that from being an internal consistency failure
to a wrong code bug.

There's also the argument that SIGN_EXTEND and ZERO_EXTEND should
be handled consistently.

Thanks,
Richard


Re: [patch] disentangle range_fold_*ary_expr into various pieces

2019-10-10 Thread Christophe Lyon
On Mon, 7 Oct 2019 at 13:53, Aldy Hernandez  wrote:

>
> > +bool
> > +ipa_vr::nonzero_p (tree expr_type) const
> > +{
> > +  if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p (max, 0))
> > +return true;
> > +
> > +  unsigned prec = TYPE_PRECISION (expr_type);
> > +  return (type == VR_RANGE
> > + && wi::eq_p (min, wi::one (prec))
> > + && wi::eq_p (max, wi::max_value (prec, TYPE_SIGN
> (expr_type;
> > +}
>
> Errr, wrong version posted.  There was a TYPE_UNSIGNED missing.
>
> Fixed and committed.
>
>
Hi,

Since this was committed (r276654), I've noticed regressions on aarch64:
gcc.target/aarch64/pr88838.c (test for excess errors)
gcc.target/aarch64/stack-check-cfa-3.c (test for excess errors)
gcc.target/aarch64/stack-check-prologue-16.c (test for excess errors)
gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve
 scan-assembler-times \\tabs\\tz[0-9]+\\.b, p[0-7]/m, z[0-9]+\\.b\\n 1
gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve
 scan-assembler-times \\tabs\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1
gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve
 scan-assembler-times \\tabs\\tz[0-9]+\\.h, p[0-7]/m, z[0-9]+\\.h\\n 1
gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve
 scan-assembler-times \\tabs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.s\\n 1
gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve (test for excess
errors)
gcc.target/aarch64/sve/adr_1.c -march=armv8.2-a+sve (test for excess
errors)

and many others

For instance:
compiler exited with status 1
FAIL: gcc.target/aarch64/pr88838.c (internal compiler error)
FAIL: gcc.target/aarch64/pr88838.c (test for excess errors)
Excess errors:
during GIMPLE pass: dom
/gcc/testsuite/gcc.target/aarch64/pr88838.c:5:1: internal compiler error:
tree check: expected integer_cst, have poly_int_cst in to_wide, at
tree.h:5795
0x5efa71 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/gcc/tree.c:9926
0x749584 tree_check(tree_node const*, char const*, int, char const*,
tree_code)
/gcc/tree.h:3523
0x749584 wi::to_wide(tree_node const*)
/gcc/tree.h:5795
0xf7c0c0 value_range_base::lower_bound(unsigned int) const
/gcc/tree-vrp.c:6136
0x155d2e6 range_operator::fold_range(tree_node*, value_range_base const&,
value_range_base const&) const
/gcc/range-op.cc:156
0xf87597 range_fold_binary_expr(value_range_base*, tree_code, tree_node*,
value_range_base const*, value_range_base const*)
/gcc/tree-vrp.c:1915
0x1007962 vr_values::extract_range_from_binary_expr(value_range*,
tree_code, tree_node*, tree_node*, tree_node*)
/gcc/vr-values.c:808
0x1011f0c vr_values::extract_range_from_assignment(value_range*, gassign*)
/gcc/vr-values.c:1469
0x1499d21 evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool)
/gcc/gimple-ssa-evrp-analyze.c:307
0xdd76dd dom_opt_dom_walker::before_dom_children(basic_block_def*)
/gcc/tree-ssa-dom.c:1503
0x146e68a dom_walker::walk(basic_block_def*)
/gcc/domwalk.c:309
0xdd4759 execute
/gcc/tree-ssa-dom.c:724

gcc.target/aarch64/pr88838.c: output file does not exist
UNRESOLVED: gcc.target/aarch64/pr88838.c scan-assembler-not sxtw

Christophe

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 20a0bddcbab..5020f4a44d5 100644
> --- a/gcc/ipa-prop.c
> +++ b/gcc/ipa-prop.c
> @@ -5117,6 +5117,7 @@ ipa_vr::nonzero_p (tree expr_type) const
>
> unsigned prec = TYPE_PRECISION (expr_type);
> return (type == VR_RANGE
> + && TYPE_UNSIGNED (expr_type)
>&& wi::eq_p (min, wi::one (prec))
>&& wi::eq_p (max, wi::max_value (prec, TYPE_SIGN (expr_type;
>   }
>


Re: [PR 70929] IPA call type compatibility fix/workaround

2019-10-10 Thread Martin Jambor
Hi,

On Wed, Oct 09 2019, Richard Biener wrote:
>>

...

>> +  /* If we only have the fntype extracted from the call statement, check it
>> + against the type of declarations while being pessimistic about
>> + promotions.  */
>> +  tree p;
>> +
>> +  if (fndecl)
>> +p = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
>> +  else
>> +p = TYPE_ARG_TYPES (gimple_call_fntype (stmt));
>
> This else case is bougs - you are then comparing the call arguments
> against the call arguments...  Oh, I see it was there before :/

Right, and one hand I noticed id did not make much sense, on the other
there were few cases where it was necessary to make the new predicate as
permissive as the old one (not that any of those that I saw looked
interesting).

>
> So it is that the FEs are expected to promote function arguments
> according to the originally called function and that "ABI" is
> recorded in gimple_call_fntype.  That means that we can either
> look at the actual arguments or at TYPE_ARG_TYPES of
> gimple_call_fntype.  But the fndecl ABI we want to verify
> against is either its DECL_ARGUMENTS or TYPE_ARG_TYPEs of its type.
>
> Verifying gimple_call_arg () against gimple_call_fntype ()
> is pointless.  What should have been used here is
>
>else
>  p = TYPE_ARG_TYPES (TREE_TYPE (gimple_call_fn (stmt)));
>
> so, gimple_call_fn is the function called (if no fndecl then
> this is a function pointer), thus look at the pointed-to type
> and then its arguments.

OK, this is a very nice idea, I have made the change in the patch.

>
> Maybe you can test/fix that as independent commit.
>
> Your second case
>
>> +  if (fndecl
>> +  && TYPE_ARG_TYPES (TREE_TYPE (fndecl))
>> +  && TYPE_ARG_TYPES (gimple_call_fntype (stmt)))
>
> then collapses with this and is also the better fallback IMHO
> (so enter this case by using TYPE_ARG_TYPES (TREE_TYPE (gimple_call_fn 
> (...))) instead of the fndecl).
>

The fndecl here is not the decl extracted from the gimple statement.  It
is received as a function parameter and two callers extract it from a
call graph edge callee and one - speculation resolution - even from the
ipa reference associated with the speculation.  So I don't think th
should be replaced.

So, is the following OK (bootstrapped and tested on x86_64-linux,  no
LTO bootstrap this time because of PR 92037)?

Martin


2019-10-09  Martin Jambor  

PR lto/70929
* cgraph.c (gimple_check_call_args): Also compare types of argumen
types and call statement fntype types.

testsuite/
* g++.dg/lto/pr70929_[01].C: New test.
---
 gcc/cgraph.c | 83 ++--
 gcc/testsuite/g++.dg/lto/pr70929_0.C | 18 ++
 gcc/testsuite/g++.dg/lto/pr70929_1.C | 10 
 3 files changed, 95 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/lto/pr70929_0.C
 create mode 100644 gcc/testsuite/g++.dg/lto/pr70929_1.C

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 0c3c6e7cac4..4f7bfa28f37 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3636,26 +3636,19 @@ cgraph_node::get_fun () const
 static bool
 gimple_check_call_args (gimple *stmt, tree fndecl, bool args_count_match)
 {
-  tree parms, p;
-  unsigned int i, nargs;
-
   /* Calls to internal functions always match their signature.  */
   if (gimple_call_internal_p (stmt))
 return true;
 
-  nargs = gimple_call_num_args (stmt);
+  unsigned int nargs = gimple_call_num_args (stmt);
 
-  /* Get argument types for verification.  */
-  if (fndecl)
-parms = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
-  else
-parms = TYPE_ARG_TYPES (gimple_call_fntype (stmt));
-
-  /* Verify if the type of the argument matches that of the function
- declaration.  If we cannot verify this or there is a mismatch,
- return false.  */
+  /* If we have access to the declarations of formal parameters, match against
+ those.  */
   if (fndecl && DECL_ARGUMENTS (fndecl))
 {
+  unsigned int i;
+  tree p;
+
   for (i = 0, p = DECL_ARGUMENTS (fndecl);
   i < nargs;
   i++, p = DECL_CHAIN (p))
@@ -3676,17 +3669,75 @@ gimple_check_call_args (gimple *stmt, tree fndecl, bool 
args_count_match)
}
   if (args_count_match && p)
return false;
+
+  return true;
 }
-  else if (parms)
+
+  /* If we don't have decls of formal parameters, see if we have both the type
+ of the callee arguments in the fntype of the call statement and compare
+ those.  We rely on the fact that whatever promotions happened to
+ declarations for exactly the same sequence of types of parameters also
+ happened on the callee side.  */
+  if (fndecl
+  && TYPE_ARG_TYPES (TREE_TYPE (fndecl))
+  && TYPE_ARG_TYPES (gimple_call_fntype (stmt)))
 {
-  for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
+  unsigned int arg_idx = 0;
+  for (tree f = TYPE_ARG_TYPES (TREE_TYPE (fndecl)),
+s = TYPE_ARG_TYPES (gimple_call_fntype (stmt));

[PATCH] [MIPS] Reject vector constants from the constant pool

2019-10-10 Thread Mihailo Stojanovic
This rejects vector constants from the constant pool, which removes
unnecessary reloads of zero constant around function call in the test
case.

Tested with mips-mti-linux-gnu.

gcc/ChangeLog:

* config/mips/mips.c (mips_cannot_force_const_mem): Reject
vector constants.

gcc/testsuite/ChangeLog:

* gcc.target/mips/constant-spill.c: New test.
---
 gcc/config/mips/mips.c |  3 ++-
 gcc/testsuite/gcc.target/mips/constant-spill.c | 31 ++
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/mips/constant-spill.c

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index e7c2212..7f6a0db 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -2409,7 +2409,8 @@ mips_cannot_force_const_mem (machine_mode mode, rtx x)
  references, reload will consider forcing C into memory and using
  one of the instruction's memory alternatives.  Returning false
  here will force it to use an input reload instead.  */
-  if (CONST_INT_P (x) && mips_legitimate_constant_p (mode, x))
+  if ((CONST_INT_P (x) || GET_CODE (x) == CONST_VECTOR)
+  && mips_legitimate_constant_p (mode, x))
 return true;
 
   split_const (x, , );
diff --git a/gcc/testsuite/gcc.target/mips/constant-spill.c 
b/gcc/testsuite/gcc.target/mips/constant-spill.c
new file mode 100644
index 000..1494705
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/constant-spill.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-mfp64 -mhard-float -mmsa" } */
+/* { dg-skip-if "code quality test" { *-*-* } { "-Os" "-O0" "-O1" "-O2" } { "" 
} } */
+
+void foo (void);
+
+void bar (void)
+{
+  int x[4];
+  int y[4];
+  int i;
+
+  while (1)
+{
+  foo ();
+
+  for (i = 0; i < 4; i++)
+{
+  x[i] = 0;
+  y[i] = 0;
+}
+
+  asm volatile (""
+:
+:"m"(x), "m"(y)
+:"memory");
+}
+}
+
+/* { dg-final { scan-assembler-not "ld.w" } } */
+/* { dg-final { scan-assembler-times "st.w" 2 } } */
-- 
2.7.4



Re: [PR target/85401][v2] Add test-cases

2019-10-10 Thread coypu
On Thu, Oct 10, 2019 at 09:41:35AM +0100, Maciej W. Rozycki wrote:
> On Wed, 9 Oct 2019, co...@sdf.org wrote:
> 
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c 
> > b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> > new file mode 100644
> > index 000..1d68d0b
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
> > @@ -0,0 +1,18 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2" } */
> > +
> > +int h(void);
> > +int i(int);
> > +
> > +struct a b;
> > +struct a {
> > +  unsigned c : 4;
> > +} d() {
> > +  int e, f = b.c << 2, g = h();
> > +  for (; g;)
> > +;
> > +  if (e == 0)
> > +if (f)
> > +  i(f);
> > +  return b;
> > +}
> 
>  Can you please run this (and the other test case) through `indent -gnu'?
> 
>   Maciej

OK.

2019-10-09  Maya Rashish  
* gcc.c-torture/compile/pr85401: New test.

diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401.c 
b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
new file mode 100644
index 000..fa8fa19be59
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int h (void);
+int i (int);
+
+struct a b;
+struct a
+{
+  unsigned c:4;
+} d ()
+{
+  int e, f = b.c << 2, g = h ();
+  for (; g;)
+;
+  if (e == 0)
+if (f)
+  i (f);
+  return b;
+}



Re: [ARM] Enable DF only when TARGET_VFP_DOUBLE

2019-10-10 Thread Kyrill Tkachov

Hi Kugan,

On 10/10/19 2:55 AM, Kugan Vivekanandarajah wrote:

As reported in Linaro bug report
(https://bugs.linaro.org/show_bug.cgi?id=4636 ; there is no
reproducible testcase provided), for some applications, we see

(insn 126 125 127 9 (set (reg:DF 189)
 (fma:DF (reg:DF 126 [ _74 ])
 (reg:DF 190)
 (reg:DF 191))) "ops.c":30 -1
  (nil))

This looks like due to a typo in the md patterns. Attached patch fixes
this. Bootsrapped and regression tested on arm-linux-gnueabihf without
any regressions.  Is this OK for trunk?

Thanks,
Kugan

gcc/ChangeLog:

2019-10-10  kugan.vivekanandarajah  


I think the ChangeLog rules require to put your name with a space and 
capitalised first letters.




 * config/arm/vfp.md (fma4): Enable DF only when
 TARGET_VFP_DOUBLE.
 (*fmsub4): Likewise.
 (*fnmsub4): Likewise.
 (*fnmadd4): Likewise.



diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
index 661919e2357..1979aa6fdb4 100644
--- a/gcc/config/arm/vfp.md
+++ b/gcc/config/arm/vfp.md
@@ -1321,7 +1321,7 @@
 (fma:SDF (match_operand:SDF 1 "register_operand" "")
 (match_operand:SDF 2 "register_operand" "")
 (match_operand:SDF 3 "register_operand" "0")))]
-  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA"
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
   "vfma%?.\\t%0, %1, %2"
   [(set_attr "predicable" "yes")
(set_attr "type" "ffma")]


I'm a bit surprised that TARGET_FMA (which just checks isa_bit_vfpv4) doesn't 
imply TARGET_VFP_DOUBLE.
Can one really have a VFPV4 single-precision-only configuration? Richard?

Thanks,
Kyrill


 @@ -1357,7 +1357,7 @@
 ""))
 (match_operand:SDF 2 "register_operand" "")
 (match_operand:SDF 3 "register_operand" "0")))]
-  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA"
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
   "vfms%?.\\t%0, %1, %2"
   [(set_attr "predicable" "yes")
(set_attr "type" "ffma")]
@@ -1379,7 +1379,7 @@
(fma:SDF (match_operand:SDF 1 "register_operand" "")
 (match_operand:SDF 2 "register_operand" "")
 (neg:SDF (match_operand:SDF 3 "register_operand" "0"]
-  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA"
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
   "vfnms%?.\\t%0, %1, %2"
   [(set_attr "predicable" "yes")
(set_attr "type" "ffma")]
@@ -1402,7 +1402,7 @@
   ""))
 (match_operand:SDF 2 "register_operand" "")
 (neg:SDF (match_operand:SDF 3 "register_operand" "0"]
-  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA"
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
   "vfnma%?.\\t%0, %1, %2"
   [(set_attr "predicable" "yes")
(set_attr "type" "ffma")]



Re: [ARM] Enable DF only when TARGET_VFP_DOUBLE

2019-10-10 Thread Kyrill Tkachov

Hi Andre,

On 10/10/19 11:28 AM, Andre Vieira (lists) wrote:

Hi Kyrill,

On 10/10/2019 10:53, Kyrill Tkachov wrote:

>
>
> I'm a bit surprised that TARGET_FMA (which just checks isa_bit_vfpv4)
> doesn't imply TARGET_VFP_DOUBLE.
> Can one really have a VFPV4 single-precision-only configuration? 
Richard?

>

Armv7e-M supports single precision only FPv4, which also includes a
single precision only VFMA instruction. So I think this is correct.

See Section A.7.7.233 VFMA, VFMS in
https://static.docs.arm.com/ddi0403/ed/DDI0403E_d_armv7m_arm.pdf

You can target this variant using one of the following three(six):
'-march=armv7e-m+fp -mfpu=auto -mfloat-abi={softfp,hard}'
'-march=cortex-m4 -mfpu=auto -mfloat-abi={softfp,hard}'
'-march=cortex-m7+nofp.dp -mfpu=auto -mfloat-abi={softfp,hard}'


Ah, thanks.

Kugan, your patch is ok then with the ChangeLog fixed.

Thanks,

Kyrill


Cheers,
Andre


[C++ PATCH] Partial fix for further -fstrong-eval-order issues (PR c++/91987, take 2)

2019-10-10 Thread Jakub Jelinek
On Mon, Oct 07, 2019 at 05:17:56PM -0400, Jason Merrill wrote:
> Ah, I see.  And it occurs to me this situation fails condition #1 for
> get_formal_tmp_var anyway.  So I guess the predicate direction doesn't make
> sense.  Let's factor out the above pattern differently, then. Maybe a
> preevaluate function that takes a predicate as an argument?

Ok, so this patch does, compared to the previous one:
1) shifts are now done in cp_build_binary_op with the cp_save_expr,
   so no fold-const.c or cp-gimplify.c change is needed
2) the array ref x[y] -> *(x + y) where y has side-effects is now handled
   as *(SAVE_EXPR, SAVE_EXPR + y) rather than
   SAVE_EXPR, *(SAVE_EXPR + y) where the former is friendlier to
   wrapping it in ADDR_EXPR etc.; nevertheless, I had to disable it for the
   OpenMP reductions, I'll discuss in the language committee what to do if
   anything in that case
3) I've added the new function in cp-gimplify.c and used it in the CALL_EXPR
   case

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
If wanted, can commit the 3 unrelated changes separately.

And the call argument side-effects aren't handled yet.

2019-10-10  Jakub Jelinek  

PR c++/91987
cp/
* decl2.c (grok_array_decl): For -fstrong-eval-order, when array ref
operands have been swapped and at least one operand has side-effects,
revert the swapping before calling build_array_ref.
* typeck.c (cp_build_array_ref): For non-ARRAY_TYPE array ref with
side-effects on the index operand, if -fstrong-eval-order use
save_expr around the array operand.
(cp_build_binary_op): For shifts with side-effects in the second
operand, wrap first operand into SAVE_EXPR and evaluate it before
the shift.
* semantics.c (handle_omp_array_sections_1): Temporarily disable
flag_strong_eval_order during OMP_CLAUSE_REDUCTION array section
processing.
* cp-gimplify.c (gimplify_to_rvalue): New function.
(cp_gimplify_expr): Use it.
testsuite/
* g++.dg/cpp1z/eval-order6.C: New test.
* g++.dg/cpp1z/eval-order7.C: New test.
* g++.dg/cpp1z/eval-order8.C: New test.
* c-c++-common/gomp/pr91987.c: New test.

--- gcc/cp/decl2.c.jj   2019-10-09 10:27:12.704400889 +0200
+++ gcc/cp/decl2.c  2019-10-09 10:32:44.932416373 +0200
@@ -405,6 +405,7 @@ grok_array_decl (location_t loc, tree ar
   else
 {
   tree p1, p2, i1, i2;
+  bool swapped = false;
 
   /* Otherwise, create an ARRAY_REF for a pointer or array type.
 It is a little-known fact that, if `a' is an array and `i' is
@@ -431,7 +432,7 @@ grok_array_decl (location_t loc, tree ar
   if (p1 && i2)
array_expr = p1, index_exp = i2;
   else if (i1 && p2)
-   array_expr = p2, index_exp = i1;
+   swapped = true, array_expr = p2, index_exp = i1;
   else
{
  error_at (loc, "invalid types %<%T[%T]%> for array subscript",
@@ -447,7 +448,12 @@ grok_array_decl (location_t loc, tree ar
   else
array_expr = mark_lvalue_use_nonread (array_expr);
   index_exp = mark_rvalue_use (index_exp);
-  expr = build_array_ref (input_location, array_expr, index_exp);
+  if (swapped
+ && flag_strong_eval_order == 2
+ && (TREE_SIDE_EFFECTS (array_expr) || TREE_SIDE_EFFECTS (index_exp)))
+   expr = build_array_ref (input_location, index_exp, array_expr);
+  else
+   expr = build_array_ref (input_location, array_expr, index_exp);
 }
   if (processing_template_decl && expr != error_mark_node)
 {
--- gcc/cp/typeck.c.jj  2019-10-09 10:27:12.625402077 +0200
+++ gcc/cp/typeck.c 2019-10-09 11:21:09.058765959 +0200
@@ -3550,6 +3550,10 @@ cp_build_array_ref (location_t loc, tree
   {
 tree ar = cp_default_conversion (array, complain);
 tree ind = cp_default_conversion (idx, complain);
+tree first = NULL_TREE;
+
+if (flag_strong_eval_order == 2 && TREE_SIDE_EFFECTS (ind))
+  ar = first = cp_save_expr (ar);
 
 /* Put the integer in IND to simplify error checking.  */
 if (TREE_CODE (TREE_TYPE (ar)) == INTEGER_TYPE)
@@ -3573,11 +3577,10 @@ cp_build_array_ref (location_t loc, tree
 
 warn_array_subscript_with_type_char (loc, idx);
 
-ret = cp_build_indirect_ref (cp_build_binary_op (input_location,
-PLUS_EXPR, ar, ind,
-complain),
- RO_ARRAY_INDEXING,
- complain);
+ret = cp_build_binary_op (input_location, PLUS_EXPR, ar, ind, complain);
+if (first)
+  ret = build2_loc (loc, COMPOUND_EXPR, TREE_TYPE (ret), first, ret);
+ret = cp_build_indirect_ref (ret, RO_ARRAY_INDEXING, complain);
 protected_set_expr_location (ret, loc);
 if (non_lvalue)
   ret = non_lvalue_loc (loc, ret);
@@ -,6 +5558,17 @@ cp_build_binary_op (const op_location_t
   

Re: [PR target/85401][v2] Add test-cases

2019-10-10 Thread Maciej W. Rozycki
On Wed, 9 Oct 2019, co...@sdf.org wrote:

> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c 
> b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> new file mode 100644
> index 000..1d68d0b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +int h(void);
> +int i(int);
> +
> +struct a b;
> +struct a {
> +  unsigned c : 4;
> +} d() {
> +  int e, f = b.c << 2, g = h();
> +  for (; g;)
> +;
> +  if (e == 0)
> +if (f)
> +  i(f);
> +  return b;
> +}

 Can you please run this (and the other test case) through `indent -gnu'?

  Maciej


[Committed] S/390: Add support for z15 as CPU name.

2019-10-10 Thread Andreas Krebbel
So far z15 was identified as arch13. After the machine has been
announced we can now add the real name.

gcc/ChangeLog:

2019-10-10  Andreas Krebbel  

* common/config/s390/s390-common.c (PF_ARCH13): Rename to...
(PF_Z15): ... this.
* config.gcc: Add z15 as option for --with-arch and --with-tune
configure switches.
* config/s390/s390-c.c (s390_resolve_overloaded_builtin): Add
error reporting for unsupported builtins.
* config/s390/s390-opts.h (enum processor_type): Rename
PROCESSOR_8561_ARCH13 to PROCESSOR_8561_Z15.
* config/s390/8561.md: Rename arch13 to z15 throughout the file.
* config/s390/driver-native.c (s390_host_detect_local_cpu):
Likewise.
* config/s390/s390-builtins.def: Likewise.
* config/s390/s390.c (processor_table): Add z15 as option and keep 
arch13 as alternative.
(s390_expand_builtin): Add missing check for unsupported builtins.
(s390_canonicalize_comparison): Rename TARGET_ARCH13 to TARGET_Z15.
(s390_rtx_costs): Likewise.
(s390_get_sched_attrmask): Rename arch13 to z15.
(s390_get_unit_mask): Likewise.
(s390_is_fpd): Likewise.
(s390_is_fxd): Likewise.
* config/s390/s390.h (enum processor_flags): Likewise.
* config/s390/s390.md: Likewise.
* config/s390/vector.md: Likewise.
* config/s390/vx-builtins.md: Likewise.
* config/s390/s390.opt: Add z15 to processor_type value.
---
 gcc/common/config/s390/s390-common.c |  4 +-
 gcc/config.gcc   |  2 +-
 gcc/config/s390/8561.md  | 92 ++--
 gcc/config/s390/driver-native.c  |  4 +-
 gcc/config/s390/s390-builtins.def|  2 +-
 gcc/config/s390/s390-c.c | 15 +
 gcc/config/s390/s390-opts.h  |  2 +-
 gcc/config/s390/s390.c   | 48 ---
 gcc/config/s390/s390.h   | 18 +++---
 gcc/config/s390/s390.md  | 58 +-
 gcc/config/s390/s390.opt |  5 +-
 gcc/config/s390/vector.md|  2 +-
 gcc/config/s390/vx-builtins.md   |  6 +-
 13 files changed, 141 insertions(+), 117 deletions(-)

diff --git a/gcc/common/config/s390/s390-common.c 
b/gcc/common/config/s390/s390-common.c
index f9c3a95f897..2e1914e3768 100644
--- a/gcc/common/config/s390/s390-common.c
+++ b/gcc/common/config/s390/s390-common.c
@@ -47,9 +47,9 @@ EXPORTED_CONST int processor_flags_table[] =
 /* z14 */PF_IEEE_FLOAT | PF_ZARCH | PF_LONG_DISPLACEMENT
 | PF_EXTIMM | PF_DFP | PF_Z10 | PF_Z196 | PF_ZEC12 | PF_TX
 | PF_Z13 | PF_VX | PF_VXE | PF_Z14,
-/* arch13 */ PF_IEEE_FLOAT | PF_ZARCH | PF_LONG_DISPLACEMENT
+/* z15 */PF_IEEE_FLOAT | PF_ZARCH | PF_LONG_DISPLACEMENT
 | PF_EXTIMM | PF_DFP | PF_Z10 | PF_Z196 | PF_ZEC12 | PF_TX
-| PF_Z13 | PF_VX | PF_VXE | PF_Z14 | PF_VXE2 | PF_ARCH13
+| PF_Z13 | PF_VX | PF_VXE | PF_Z14 | PF_VXE2 | PF_Z15
   };
 
 /* Change optimizations to be performed, depending on the
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 511aeb454bf..bdc2253f8ef 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4826,7 +4826,7 @@ case "${target}" in
for which in arch tune; do
eval "val=\$with_$which"
case ${val} in
-   "" | native | z900 | z990 | z9-109 | z9-ec | z10 | z196 
| zEC12 | z13 | z14 | arch5 | arch6 | arch7 | arch8 | arch9 | arch10 | arch11 | 
arch12 | arch13 )
+   "" | native | z900 | z990 | z9-109 | z9-ec | z10 | z196 
| zEC12 | z13 | z14 | z15 | arch5 | arch6 | arch7 | arch8 | arch9 | arch10 | 
arch11 | arch12 | arch13 )
# OK
;;
*)
diff --git a/gcc/config/s390/8561.md b/gcc/config/s390/8561.md
index e5a345f4dba..2442349271b 100644
--- a/gcc/config/s390/8561.md
+++ b/gcc/config/s390/8561.md
@@ -1,4 +1,4 @@
-;; Scheduling description for arch13.
+;; Scheduling description for z15.
 ;;   Copyright (C) 2019 Free Software Foundation, Inc.
 ;;   Contributed by Robin Dapp (rd...@linux.ibm.com)
 ;; This file is part of GCC.
@@ -17,12 +17,12 @@
 ;; along with GCC; see the file COPYING3.  If not see
 ;; .
 
-(define_attr "arch13_unit_fpd" ""
+(define_attr "z15_unit_fpd" ""
 (cond [(eq_attr "mnemonic" "ddb,ddbr,deb,debr,dxbr,sqdb,sqdbr,sqeb,\
 sqebr,sqxbr,vfddb,vfdsb,vfsqdb,vfsqsb,wfddb,wfdsb,wfdxb,wfsqdb,wfsqxb")
  (const_int 1)] (const_int 0)))
 
-(define_attr "arch13_unit_fxa" ""
+(define_attr "z15_unit_fxa" ""
 (cond [(eq_attr "mnemonic" "a,afi,ag,agf,agfi,agfr,agh,aghi,aghik,\
 agr,agrk,ah,ahi,ahik,ahy,al,alc,alcg,alcgr,alcr,alfi,alg,algf,algfi,algfr,\
 alghsik,algr,algrk,alhsik,alr,alrk,aly,ar,ark,ay,bras,brasl,etnd,exrl,flogr,\
@@ -39,7 +39,7 @@ 

Re: C++ PATCH for C++20 P0388R4 (conversions to arrays of unknown bounds) and CWG 1307 (c++/91364, c++/69531)

2019-10-10 Thread Jonathan Wakely

On 09/10/19 16:29 -0400, Marek Polacek wrote:

On Wed, Oct 09, 2019 at 11:01:39AM +0100, Jonathan Wakely wrote:

On 07/10/19 14:56 -0400, Jason Merrill wrote:
> On 10/7/19 1:42 PM, Marek Polacek wrote:
> > @@ -7401,8 +7432,20 @@ convert_like_real (conversion *convs, tree expr, 
tree fn, int argnum,
> > error_at (loc, "cannot bind non-const lvalue reference of "
> >   "type %qH to an rvalue of type %qI", totype, extype);
> >   else if (!reference_compatible_p (TREE_TYPE (totype), extype))
> > -   error_at (loc, "binding reference of type %qH to %qI "
> > - "discards qualifiers", totype, extype);
> > +   {
> > + /* If we're converting from T[] to T[N], don't talk
> > +about discarding qualifiers.  (Converting from T[N] to
> > +T[] is allowed by P0388R4.)  */
> > + if (TREE_CODE (extype) == ARRAY_TYPE
> > + && TYPE_DOMAIN (extype) == NULL_TREE
> > + && TREE_CODE (TREE_TYPE (totype)) == ARRAY_TYPE
> > + && TYPE_DOMAIN (TREE_TYPE (totype)) != NULL_TREE)
> > +   error_at (loc, "binding reference of type %qH to %qI "
> > + "discards array bounds", totype, extype);
>
> If we're converting to T[N], that would be adding, not discarding, array
> bounds?

I don't think the diagnostic would be very good if we say "adds array
bounds" though. How about being consistent with the existing error for
similar cases?

a.cc:4:17: error: invalid initialization of reference of type ‘int (&)[3]’ from 
expression of type ‘int []’
  int ()[3] = a;
^


In my latest patch the error message reads "cannot bind reference of type T to U due 
to different array bounds".
It'd be trivial to adjust it if anyone hates that.


Works for me.



Re: [PATCH][wwwdocs] Purge CVS from gccmission.html

2019-10-10 Thread Richard Sandiford
Kyrill Tkachov  writes:
> Hopefully an obvious amendment.
>
> Will test out the new git repo soon!
>
> Thanks,
>
> Kyrill
>
> commit ddf1524244ac30ab3473d0df6d8e76d5c9a42276
> Author: Kyrylo Tkachov 
> Date:   Wed Oct 9 16:15:00 2019 +0100
>
> [gcccmission.html] Replace cvs with version control
>
> diff --git a/htdocs/gccmission.html b/htdocs/gccmission.html
> index 25aa3ad0..6aef 100644
> --- a/htdocs/gccmission.html
> +++ b/htdocs/gccmission.html
> @@ -60,7 +60,7 @@ GCC.
>   as long as they accept the groundrules.
>   
>  Open mailing lists.
> -Developer friendly tools and procedures (i.e., cvs, multiple
> +Developer friendly tools and procedures (i.e. version control, multiple
>  maintainers, etc).
>  Conflicts of interest exist for many GCC developers; the
>  developers as well as the GCC Steering

Not sure whether this is supposed to be a living document or just a record
of what the mission statement was when egcs became GCC.  The date at the top
is still 1999-04-22.

Richard


Re: Make C2X imply -fno-fp-int-builtin-inexact

2019-10-10 Thread Rainer Orth
Hi Joseph,

> On Wed, 9 Oct 2019, Rainer Orth wrote:
>
>> the new test FAILs on Solaris/x86, both 32 and 64-bit:
>> 
>> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O0  execution test
>> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O1  execution test
>> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2  execution test
>> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2 -flto  execution test
>> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O2 -flto
>> -flto-partition=none execution test
>> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O3 -g  execution test
>> 
>> The test aborts.  This happens because dg-add-options c99_runtime
>> appends -std=c99 to the options, yielding -std=c2x -std=c99.  If I
>> manually omit the -std=c99, the test PASSes.  I'm uncertain yet how to
>> handle this.  Maybe prepending -std=c99 is an option, but that may well
>> break other tests...
>
> Since the default standard is now gnu11, I'd hope that dg-add-options 
> c99_runtime doesn't actually need to add any options at all.  (Unless 
> there are tests using it with an explicit pre-C99 standard, which would 
> seem rather nonsensical.)

sometimes one misses the obvious ;-)  I'll give the Solaris bootstrap a
try with the Solaris handling in add_options_for_c99_runtime removed.

No idea about Darwin/PowerPC though.  If pre-10.3 is supposed to be
supported, the -mmacosx-version-min=10.3 probably needs to go into
rs6000/darwin.h first.  Iain?

Once this is resolved, all uses of dg-add-options c99_runtime in the
testsuite can go.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PATCH][ARM] Enable code hoisting with -Os (PR80155)

2019-10-10 Thread Joey Ye
Committed to ARM/arm-9-branch

On Wed, Sep 11, 2019 at 4:50 PM Wilco Dijkstra  wrote:
>
> While code hoisting generally improves codesize, it can affect performance
> negatively.  Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks, so only enable code hoisting with -Os on Arm.
>
> Bootstrap OK, OK for commit?
>
> ChangeLog:
> 2019-09-11  Wilco Dijkstra  
>
>
> PR tree-optimization/80155
> * common/config/arm/arm-common.c (arm_option_optimization_table):
> Enable -fcode-hoisting with -Os.
>
> --
> diff --git a/gcc/common/config/arm/arm-common.c 
> b/gcc/common/config/arm/arm-common.c
> index 
> 41a920f6dc96833e778faa8dbcc19beac483734c..b0d5fb300bf01acc1fb6f4631635f8a1bfe6441c
>  100644
> --- a/gcc/common/config/arm/arm-common.c
> +++ b/gcc/common/config/arm/arm-common.c
> @@ -39,6 +39,8 @@ static const struct default_options 
> arm_option_optimization_table[] =
>  /* Enable section anchors by default at -O1 or higher.  */
>  { OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
>  { OPT_LEVELS_1_PLUS, OPT_fsched_pressure, NULL, 1 },
> +/* Enable code hoisting only with -Os.  */
> +{ OPT_LEVELS_SIZE, OPT_fcode_hoisting, NULL, 1 },
>  { OPT_LEVELS_NONE, 0, NULL, 0 }
>};
>
>


[committed] Initial OpenMP 5.0 #pragma omp declare variant parsing

2019-10-10 Thread Jakub Jelinek
Hi!

The following patch adds parsing support for #pragma omp declare variant.
The contexts are kept in attributes and nothing is done with them so far,
later on I'll need to add support for determining whether a context selector
matches the current context (will need several modes, some done in the FEs
or during gimplification, others later on e.g. to be callable during IPA
or to be used during vectorization), scoring the variants and finally
replacing one set of calls with another one.
In the C parsing, there is no handling of argument transformation for simd
construct contexts, in C++ I need to perform argument dependent lookup.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2019-10-10  Jakub Jelinek  

c-family/
* c-common.h (c_omp_check_context_selector,
c_omp_get_context_selector): Declare.
* c-omp.c (c_omp_declare_simd_clauses_to_numbers): Fix spelling
in diagnostic message.
(c_omp_check_context_selector, c_omp_get_context_selector): New
functions.
* c-attribs.c (c_common_attribute_table): Add "omp declare variant"
attribute.
(handle_omp_declare_variant_attribute): New function.
c/
* c-parser.c (c_parser_omp_all_clauses): Add NESTED_P argument, if
true, terminate processing on closing paren and don't skip to end of
pragma line.
(c_parser_omp_declare_simd): Handle also declare variant.
(omp_construct_selectors, omp_device_selectors,
omp_implementation_selectors, omp_user_selectors): New variables.
(c_parser_omp_context_selector,
c_parser_omp_context_selector_specification,
c_finish_omp_declare_variant): New functions.
(c_finish_omp_declare_simd): Handle both declare simd and
declare variant.
(c_parser_omp_declare): Handle declare variant.
cp/
* parser.h (struct cp_omp_declare_simd_data): Add variant_p member.
* parser.c (cp_ensure_no_omp_declare_simd): Handle both declare simd
and declare variant.
(cp_parser_oacc_all_clauses): Formatting fix.
(cp_parser_omp_all_clauses): Add NESTED_P argument, if true, terminate
processing on closing paren and don't skip to end of pragma line.
(cp_parser_omp_declare_simd): Add VARIANT_P argument.  Handle also
declare variant.
(omp_construct_selectors, omp_device_selectors,
omp_implementation_selectors, omp_user_selectors): New variables.
(cp_parser_omp_context_selector,
cp_parser_omp_context_selector_specification,
cp_finish_omp_declare_variant): New functions.
(cp_parser_late_parsing_omp_declare_simd): Handle also declare variant.
(cp_parser_omp_declare): Handle declare variant.
testsuite/
* c-c++-common/gomp/declare-variant-1.c: New test.
* c-c++-common/gomp/declare-variant-2.c: New test.
* c-c++-common/gomp/declare-variant-3.c: New test.
* g++.dg/gomp/this-1.C: Adjust for diagnostic message spelling fix.
* gcc.dg/gomp/declare-variant-1.c: New test.
* gcc.dg/gomp/declare-variant-2.c: New test.

--- gcc/c-family/c-common.h.jj  2019-10-09 10:27:12.938397370 +0200
+++ gcc/c-family/c-common.h 2019-10-09 17:11:52.348385875 +0200
@@ -1189,6 +1189,8 @@ extern tree c_omp_declare_simd_clauses_t
 extern void c_omp_declare_simd_clauses_to_decls (tree, tree);
 extern bool c_omp_predefined_variable (tree);
 extern enum omp_clause_default_kind c_omp_predetermined_sharing (tree);
+extern tree c_omp_check_context_selector (location_t, tree);
+extern tree c_omp_get_context_selector (tree, const char *, const char *);
 
 /* Return next tree in the chain for chain_next walking of tree nodes.  */
 static inline tree
--- gcc/c-family/c-omp.c.jj 2019-10-09 10:27:12.877398287 +0200
+++ gcc/c-family/c-omp.c2019-10-09 17:10:47.574357967 +0200
@@ -2011,7 +2011,7 @@ c_omp_declare_simd_clauses_to_numbers (t
  if (arg == NULL_TREE)
{
  error_at (OMP_CLAUSE_LOCATION (c),
-   "%qD is not an function argument", decl);
+   "%qD is not a function argument", decl);
  continue;
}
  OMP_CLAUSE_DECL (c) = build_int_cst (integer_type_node, idx);
@@ -2026,7 +2026,7 @@ c_omp_declare_simd_clauses_to_numbers (t
  if (arg == NULL_TREE)
{
  error_at (OMP_CLAUSE_LOCATION (c),
-   "%qD is not an function argument", decl);
+   "%qD is not a function argument", decl);
  continue;
}
  OMP_CLAUSE_LINEAR_STEP (c)
@@ -2120,3 +2120,133 @@ c_omp_predetermined_sharing (tree decl)
 
   return OMP_CLAUSE_DEFAULT_UNSPECIFIED;
 }
+
+/* Diagnose errors in an OpenMP context selector, return CTX if
+   it is correct or error_mark_node otherwise.  */
+
+tree
+c_omp_check_context_selector (location_t loc, tree ctx)
+{

[Committed] S/390: PR91035 Fix call to __morestack

2019-10-10 Thread Andreas Krebbel
For the call to __morestack we use a special ABI in the S/390 back-end
which requires us to emit a parameter block to the .rodata section
which contains the label whereto __morestack needs to return.  The
parameter block needs to be explicit in RTL since we also need the
address of it loaded into r1 in order to pass its address to
__morestack.  In order to express correctly what __morestack does its
RTX also contained the return label. Hence we had the return label to
occur twice in the insn stream.  This is problematic when it comes to
redirecting edges.  The correlation between these two occurrences of
the label cannot be expressed so when doing a redirect only the label
in the jump RTX gets modified while the parameter block label stays as
is.

The patch avoids having two instancs of the label by merging the
parameter block generation and the __morestack call RTX into one. By
doing this I could also get rid of the unspec which was required for
the parameter block generation so far.

gcc/ChangeLog:

2019-10-10  Andreas Krebbel  

PR target/91035
* config/s390/s390-protos.h (s390_output_split_stack_data): Add
prototype.
* config/s390/s390.md (UNSPECV_SPLIT_STACK_DATA): Remove.
("split_stack_data", "split_stack_call")
("split_stack_call_", "split_stack_cond_call")
("split_stack_cond_call_"): Remove.
("@split_stack_call", "@split_stack_cond_call"): New
insn definition.
* config/s390/s390.c (s390_output_split_stack_data): New function.
(s390_expand_split_stack_prologue): Use the merged expander.
---
 gcc/config/s390/s390-protos.h |   1 +
 gcc/config/s390/s390.c|  78 ++--
 gcc/config/s390/s390.md   | 111 +++---
 3 files changed, 95 insertions(+), 95 deletions(-)

diff --git a/gcc/config/s390/s390-protos.h b/gcc/config/s390/s390-protos.h
index ae70b2fee18..f760f152932 100644
--- a/gcc/config/s390/s390-protos.h
+++ b/gcc/config/s390/s390-protos.h
@@ -146,6 +146,7 @@ extern int s390_branch_condition_mask (rtx);
 extern int s390_compare_and_branch_condition_mask (rtx);
 extern bool s390_extzv_shift_ok (int, int, unsigned HOST_WIDE_INT);
 extern void s390_asm_output_function_label (FILE *, const char *, tree);
+extern void s390_output_split_stack_data (rtx, rtx, rtx, rtx);
 
 enum s390_indirect_branch_type
   {
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 062cbd8099d..8241bd5bbf8 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -11600,6 +11600,44 @@ static GTY(()) rtx morestack_ref;
 
 #define SPLIT_STACK_AVAILABLE 1024
 
+/* Emit the parmblock for __morestack into .rodata section.  It
+   consists of 3 pointer size entries:
+   - frame size
+   - size of stack arguments
+   - offset between parm block and __morestack return label  */
+
+void
+s390_output_split_stack_data (rtx parm_block, rtx call_done,
+ rtx frame_size, rtx args_size)
+{
+  rtx ops[] = { parm_block, call_done };
+
+  switch_to_section (targetm.asm_out.function_rodata_section
+(current_function_decl));
+
+  if (TARGET_64BIT)
+output_asm_insn (".align\t8", NULL);
+  else
+output_asm_insn (".align\t4", NULL);
+
+  (*targetm.asm_out.internal_label) (asm_out_file, "L",
+CODE_LABEL_NUMBER (parm_block));
+  if (TARGET_64BIT)
+{
+  output_asm_insn (".quad\t%0", _size);
+  output_asm_insn (".quad\t%0", _size);
+  output_asm_insn (".quad\t%1-%0", ops);
+}
+  else
+{
+  output_asm_insn (".long\t%0", _size);
+  output_asm_insn (".long\t%0", _size);
+  output_asm_insn (".long\t%1-%0", ops);
+}
+
+  switch_to_section (current_function_section ());
+}
+
 /* Emit -fsplit-stack prologue, which goes before the regular function
prologue.  */
 
@@ -11677,16 +11715,8 @@ s390_expand_split_stack_prologue (void)
 
   call_done = gen_label_rtx ();
   parm_base = gen_label_rtx ();
-
-  /* Emit the parameter block.  */
-  tmp = gen_split_stack_data (parm_base, call_done,
- GEN_INT (frame_size),
- GEN_INT (args_size));
-  insn = emit_insn (tmp);
-  add_reg_note (insn, REG_LABEL_OPERAND, call_done);
-  LABEL_NUSES (call_done)++;
-  add_reg_note (insn, REG_LABEL_OPERAND, parm_base);
   LABEL_NUSES (parm_base)++;
+  LABEL_NUSES (call_done)++;
 
   /* %r1 = litbase.  */
   insn = emit_move_insn (r1, gen_rtx_LABEL_REF (VOIDmode, parm_base));
@@ -11696,15 +11726,29 @@ s390_expand_split_stack_prologue (void)
   /* Now, we need to call __morestack.  It has very special calling
  conventions: it preserves param/return/static chain registers for
  calling main function body, and looks for its own parameters at %r1. */
+  if (cc != NULL)
+tmp = gen_split_stack_cond_call (Pmode,
+morestack_ref,
+parm_base,
+  

[PATCH][wwwdocs] Purge CVS from gccmission.html

2019-10-10 Thread Kyrill Tkachov

Hopefully an obvious amendment.

Will test out the new git repo soon!

Thanks,

Kyrill

commit ddf1524244ac30ab3473d0df6d8e76d5c9a42276
Author: Kyrylo Tkachov 
Date:   Wed Oct 9 16:15:00 2019 +0100

[gcccmission.html] Replace cvs with version control

diff --git a/htdocs/gccmission.html b/htdocs/gccmission.html
index 25aa3ad0..6aef 100644
--- a/htdocs/gccmission.html
+++ b/htdocs/gccmission.html
@@ -60,7 +60,7 @@ GCC.
  as long as they accept the groundrules.
  
 Open mailing lists.
-Developer friendly tools and procedures (i.e., cvs, multiple
+Developer friendly tools and procedures (i.e. version control, multiple
 maintainers, etc).
 Conflicts of interest exist for many GCC developers; the
 developers as well as the GCC Steering


Re: Make C2X imply -fno-fp-int-builtin-inexact

2019-10-10 Thread Iain Sandoe

Hi Rainer,

Rainer Orth  wrote:


Hi Joseph,


On Wed, 9 Oct 2019, Rainer Orth wrote:


the new test FAILs on Solaris/x86, both 32 and 64-bit:

FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O0  execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O1  execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2  execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2 -flto   
execution test

FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O3 -g  execution  
test


The test aborts.  This happens because dg-add-options c99_runtime
appends -std=c99 to the options, yielding -std=c2x -std=c99.  If I
manually omit the -std=c99, the test PASSes.  I'm uncertain yet how to
handle this.  Maybe prepending -std=c99 is an option, but that may well
break other tests...


Since the default standard is now gnu11, I'd hope that dg-add-options
c99_runtime doesn't actually need to add any options at all.  (Unless
there are tests using it with an explicit pre-C99 standard, which would
seem rather nonsensical.)


sometimes one misses the obvious ;-)  I'll give the Solaris bootstrap a
try with the Solaris handling in add_options_for_c99_runtime removed.

No idea about Darwin/PowerPC though.


Right now, anything < 10.4 is not a viable host (without jumping through
a lot of hoops, regardless of the c99 requirements)...

… but It would be good to continue to support these earlier versions as  
cross-
targets (however, it’s low on my priority list to do any serious lifting  
there).



 If pre-10.3 is supposed to be
supported, the -mmacosx-version-min=10.3 probably needs to go into
rs6000/darwin.h first.  Iain?


I’m not quite sure what you’re proposing here (probably missing something
obvious).


Once this is resolved, all uses of dg-add-options c99_runtime in the
testsuite can go.


cheers
Iain


Re: [patch, fortran] Fix PR 92004, restore Lapack compilation

2019-10-10 Thread Tobias Burnus

Hi Thomas,

On 10/10/19 12:23 AM, Thomas Koenig wrote:

+  if (s->ts.type == BT_CLASS || s->as->type == AS_ASSUMED_SHAPE
+  || s->attr.pointer)
+    return false;


dt%foo – again, "foo" can be an allocatable of polymorphic type or a 
pointer, but at least, it cannot be of assumed shape.


Really? The paragraph reads […]


What I meant is assumed-shape implies dummy argument. Hence, 
"s->as->type" is a good check.


Whereas for deferred-shape, one had to take care of "dt%allocatable_arg" 
– thus, the s->attr.pointer and the s->ts.type check aren't good.


Technical background for those requirements: pointers and assumed-shape 
arrays can have strides, but if one passes a scalar to an array dummy 
argument, one wants to be reasonably sure that the memory is contiguous.


(Actually, one could permit assumed-shape or pointer with contiguous 
argument. But as one doesn't want to encourage this abuse. The reason 
for permitting character(kind=1) is to call C "char*" functions without 
using ["H", "e", "l", "l", "o", null] instead of "Hello" + null].)




Anyway, here's an update of the patch. OK, or is there still something
missing?


It would be nice to have a ChangeLog item (not as diff).



+ /* Set if an interface to a procedure could actually be to an array
+ although the actual argument is scalar. */
+ unsigned maybe_array:1; 


Actually, I find this sentence hard to parse. Maybe:
"Set if the dummy argument of a procedure could be an array despite
being called with a scalar actual argument."

Or something along this line.



+/* Under certain conditions, a scalar actual argument can be passed
+   to an array dummy argument - see F2018, 15.5.2.4, clause 14.  This
+   functin returns true for these conditions so that an error or

Old patch? Still "functin".


+   warning for this can be suppressed later.  */
+
+bool
+maybe_dummy_array_arg (gfc_expr *e)
+{
+  gfc_symbol *s;
+  gfc_ref *ref;
+  bool last_array_ref;
+
+  if (e->rank > 0)
+return false;


Maybe add a comment "/* Return false as for arrays, the rank always 
needs to be checked. */" or something like that. Otherweise, 
"maybe_dummy_array_arg" + description above the function cause one to 
stumble over this.




+  s = e->symtree->n.sym;
+  if (s->as == NULL)
+return false;


Again, assume  "call foo(dt%array(1))" – I think that's fine but 
rejected by this check as "dt" is a scalar and only "dt%array" is an 
array. – You have have to keep that array spec and then look the the 
last component reference and see at its array spec.



+  if (s->ts.type == BT_CLASS || s->as->type == AS_ASSUMED_SHAPE
+  || s->attr.pointer)
+return false;


Similarly, "class%int_array(1)" is fine – I think you need "e->ts.type" 
instead of "s".


For s->attr.pointer, likewise "ptr%int_array(1)" is fine, hence, 
"gfc_expr_attr (e).pointer" or something like that is needed.


And for the "s->as->type", the following should be valid:

type t
integer :: ia(100)
end type t

type(t), allocatable :: x(:)
allocate(x(1))
call foo(x(1)%ia(5), 100-5)

But while x is assumed-shape


+  last_array_ref = false;
+
+  for (ref=e->ref; ref; ref=ref->next)
+last_array_ref = ref->type == REF_ARRAY;


This rejects too much - you can also have a substring reference at the 
end – and then the arrayness still matters.


character(type=4, len=5) :: str(50)

   call foo(str(1))  ! This makes sense
   call foo(str(1)(3:4))  ! Technically valid, but feels odd


argument_checking_24.f90



I also would prefer to have some more test coverage.

For instance:

type(tt), pointer :: tt_var2
allocate(tt_var2)
call s2(tt_var2%x(1)) ! Valid

subroutine foo3(x)
type(tt) :: tt_var2(:)
call s1(tt_var2%x(1)) ! Valid

call s4(dt%array_var%scalar) ! Invalid


Actually, I wonder whether you code as any effects on strings as at 
least the test for "Element of assumed-shaped or pointer array passed to 
array dummy argument" permits any string and not only 
default-kind/c_char strings. – I am pretty sure that some C-binding test 
case already checks that those are accepted.



Cheers,

Tobias



[Patch, committed] [Fortran, OpenMP] Actually pass use_device_addr on to the middle end

2019-10-10 Thread Tobias Burnus
Committed as obvious (r276791) – cherry picked from the patch (still 
awaiting review):


https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00503.html
("[patch][OpenMP,Fortran] Fix several OpenMP use_device_addr/map/update 
errors found by a length test case")


Tobias

PS: This bit was missing from the original patch at 
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00115.html


Index: gcc/fortran/trans-openmp.c
===
--- gcc/fortran/trans-openmp.c	(revision 276790)
+++ gcc/fortran/trans-openmp.c	(revision 276791)
@@ -1887,6 +1887,9 @@
 	case OMP_LIST_USE_DEVICE_PTR:
 	  clause_code = OMP_CLAUSE_USE_DEVICE_PTR;
 	  goto add_clause;
+	case OMP_LIST_USE_DEVICE_ADDR:
+	  clause_code = OMP_CLAUSE_USE_DEVICE_ADDR;
+	  goto add_clause;
 	case OMP_LIST_IS_DEVICE_PTR:
 	  clause_code = OMP_CLAUSE_IS_DEVICE_PTR;
 	  goto add_clause;
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(revision 276790)
+++ gcc/fortran/ChangeLog	(revision 276791)
@@ -1,3 +1,8 @@
+2019-10-10  Tobias Burnus  
+
+	* trans-openmp.c (gfc_trans_omp_clauses): Actually pass use_device_addr
+	on to the middle end.
+
 2019-10-08  Steven G. Kargl  
 
 	PR fortran/91801


Re: [PATCH][wwwdocs] Purge CVS from gccmission.html

2019-10-10 Thread Kyrill Tkachov



On 10/10/19 10:18 AM, Richard Sandiford wrote:

Kyrill Tkachov  writes:

Hopefully an obvious amendment.

Will test out the new git repo soon!

Thanks,

Kyrill

commit ddf1524244ac30ab3473d0df6d8e76d5c9a42276
Author: Kyrylo Tkachov 
Date:   Wed Oct 9 16:15:00 2019 +0100

 [gcccmission.html] Replace cvs with version control

diff --git a/htdocs/gccmission.html b/htdocs/gccmission.html
index 25aa3ad0..6aef 100644
--- a/htdocs/gccmission.html
+++ b/htdocs/gccmission.html
@@ -60,7 +60,7 @@ GCC.
   as long as they accept the groundrules.
   
  Open mailing lists.
-Developer friendly tools and procedures (i.e., cvs, multiple
+Developer friendly tools and procedures (i.e. version control, multiple
  maintainers, etc).
  Conflicts of interest exist for many GCC developers; the
  developers as well as the GCC Steering

Not sure whether this is supposed to be a living document or just a record
of what the mission statement was when egcs became GCC.  The date at the top
is still 1999-04-22.


Ah, I hadn't considered that. Good thing I didn't get around to 
committing it just yet.


Gerald, do you happen to know?

Thanks,

Kyrill



Richard


Re: [ARM] Enable DF only when TARGET_VFP_DOUBLE

2019-10-10 Thread Andre Vieira (lists)

Hi Kyrill,

On 10/10/2019 10:53, Kyrill Tkachov wrote:




I'm a bit surprised that TARGET_FMA (which just checks isa_bit_vfpv4) 
doesn't imply TARGET_VFP_DOUBLE.

Can one really have a VFPV4 single-precision-only configuration? Richard?



Armv7e-M supports single precision only FPv4, which also includes a 
single precision only VFMA instruction. So I think this is correct.


See Section A.7.7.233 VFMA, VFMS in 
https://static.docs.arm.com/ddi0403/ed/DDI0403E_d_armv7m_arm.pdf


You can target this variant using one of the following three(six):
'-march=armv7e-m+fp -mfpu=auto -mfloat-abi={softfp,hard}'
'-march=cortex-m4 -mfpu=auto -mfloat-abi={softfp,hard}'
'-march=cortex-m7+nofp.dp -mfpu=auto -mfloat-abi={softfp,hard}'

Cheers,
Andre


[DOC] Replace reference to removed macro

2019-10-10 Thread Joel Hutton
Hi all,

I noticed when reading the documentation that BREAK_FROM_IMM_USE_SAFE 
was removed at some point in 2006 and replaced with BREAK_FROM_IMM_USE_STMT.


2019-10-10 Joel Hutton joel.hut...@arm.com

     * doc/tree-ssa.texi: Update renamed macro name.

From a9569599ee885842eabc6cc22e718486ceb7034d Mon Sep 17 00:00:00 2001
From: Joel Hutton 
Date: Thu, 10 Oct 2019 11:12:17 +0100
Subject: [PATCH] Doc: FOR_EACH_IMM_USE_SAFE removed

---
 gcc/doc/tree-ssa.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/tree-ssa.texi b/gcc/doc/tree-ssa.texi
index 9714c5addfaad5d8418e88ded309a713439184b0..a7da6f9ef04264465d06cc55eded4a810642eaa5 100644
--- a/gcc/doc/tree-ssa.texi
+++ b/gcc/doc/tree-ssa.texi
@@ -385,14 +385,14 @@ optimization can manipulate the stmt when all the uses have been
 processed.  This is a little slower than the FAST version since it adds a
 placeholder element and must sort through the list a bit for each statement.
 This placeholder element must be also be removed if the loop is
-terminated early.  The macro @code{BREAK_FROM_IMM_USE_SAFE} is provided
+terminated early.  The macro @code{BREAK_FROM_IMM_USE_STMT} is provided
 to do this :
 
 @smallexample
   FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var)
 @{
   if (stmt == last_stmt)
-BREAK_FROM_SAFE_IMM_USE (iter);
+BREAK_FROM_IMM_USE_STMT (iter);
 
   FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator)
 SET_USE (imm_use_p, ssa_var_2);
-- 
2.17.1



PR 91770 - emit a warning in a system header

2019-10-10 Thread Nathan Sidwell
In addressing 91770, I need to emit a warning for a location inside a 
system header file[1].  The diagnostics machinery elides warnings when 
the location is in a system header :(


As I happen to have located the appropriate line_map in the process of 
determining the nested extern "C", I could clear the map's 
in-system-header flag around the warning emission.  But that's, well, urgh:(


Is there a neater way?

nathan

[1] The user may have included the system header inside an extern "C" 
region, but this is also so the glibc maintainers can locate where glibc 
does it itself.

--
Nathan Sidwell


Re: PR 91770 - emit a warning in a system header

2019-10-10 Thread Jakub Jelinek
On Thu, Oct 10, 2019 at 08:24:29AM -0400, Nathan Sidwell wrote:
> In addressing 91770, I need to emit a warning for a location inside a system
> header file[1].  The diagnostics machinery elides warnings when the location
> is in a system header :(
> 
> As I happen to have located the appropriate line_map in the process of
> determining the nested extern "C", I could clear the map's in-system-header
> flag around the warning emission.  But that's, well, urgh:(
> 
> Is there a neater way?

  bool save_warn_system_headers = global_dc->dc_warn_system_headers;
  global_dc->dc_warn_system_headers = 1;
...
  global_dc->dc_warn_system_headers = save_warn_system_headers;

?

I'm afraid warning_sentinel can't be used here, because that clears, rather
than sets it.

Jakub


Re: Make C2X imply -fno-fp-int-builtin-inexact

2019-10-10 Thread Rainer Orth
Hi Iain,

> Rainer Orth  wrote:
>
>> Hi Joseph,
>>
>>> On Wed, 9 Oct 2019, Rainer Orth wrote:
>>>
 the new test FAILs on Solaris/x86, both 32 and 64-bit:

 FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O0  execution test
 FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O1  execution test
 FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2  execution test
 FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2 -flto
 execution test
 FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O2 -flto
 -flto-partition=none execution test
 FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O3 -g  execution
 test

 The test aborts.  This happens because dg-add-options c99_runtime
 appends -std=c99 to the options, yielding -std=c2x -std=c99.  If I
 manually omit the -std=c99, the test PASSes.  I'm uncertain yet how to
 handle this.  Maybe prepending -std=c99 is an option, but that may well
 break other tests...
>>>
>>> Since the default standard is now gnu11, I'd hope that dg-add-options
>>> c99_runtime doesn't actually need to add any options at all.  (Unless
>>> there are tests using it with an explicit pre-C99 standard, which would
>>> seem rather nonsensical.)
>>
>> sometimes one misses the obvious ;-)  I'll give the Solaris bootstrap a
>> try with the Solaris handling in add_options_for_c99_runtime removed.
>>
>> No idea about Darwin/PowerPC though.
>
> Right now, anything < 10.4 is not a viable host (without jumping through
> a lot of hoops, regardless of the c99 requirements)...
>
> … but It would be good to continue to support these earlier versions as
> cross-
> targets (however, it’s low on my priority list to do any serious lifting
> there).

ok, good to know.

>>  If pre-10.3 is supposed to be
>> supported, the -mmacosx-version-min=10.3 probably needs to go into
>> rs6000/darwin.h first.  Iain?
>
> I’m not quite sure what you’re proposing here (probably missing something
> obvious).

At the moment, gcc/testsuite/lib/target-supports.exp
(add_options_for_c99_runtime) adds -mmacosx-version-min=10.3 to the
testcase flags on powerpc-*-darwin*.  Since, as Joseph mentioned, gcc
now defaults to -std=gnu11 (which implies a C99 runtime), this (or
something similar) would always be needed now (unless someone forces,
say, -std=c90) and should be handled in the Darwin/PowerPC driver code,
not just the testsuite.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PR 70929] IPA call type compatibility fix/workaround

2019-10-10 Thread Richard Biener


Now also to the list...

On Thu, 10 Oct 2019, Richard Biener wrote:

> On Thu, 10 Oct 2019, Martin Jambor wrote:
> 
> > Hi,
> > 
> > On Wed, Oct 09 2019, Richard Biener wrote:
> > >>
> > 
> > ...
> > 
> > >> +  /* If we only have the fntype extracted from the call statement, 
> > >> check it
> > >> + against the type of declarations while being pessimistic about
> > >> + promotions.  */
> > >> +  tree p;
> > >> +
> > >> +  if (fndecl)
> > >> +p = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
> > >> +  else
> > >> +p = TYPE_ARG_TYPES (gimple_call_fntype (stmt));
> > >
> > > This else case is bougs - you are then comparing the call arguments
> > > against the call arguments...  Oh, I see it was there before :/
> > 
> > Right, and one hand I noticed id did not make much sense, on the other
> > there were few cases where it was necessary to make the new predicate as
> > permissive as the old one (not that any of those that I saw looked
> > interesting).
> > 
> > >
> > > So it is that the FEs are expected to promote function arguments
> > > according to the originally called function and that "ABI" is
> > > recorded in gimple_call_fntype.  That means that we can either
> > > look at the actual arguments or at TYPE_ARG_TYPES of
> > > gimple_call_fntype.  But the fndecl ABI we want to verify
> > > against is either its DECL_ARGUMENTS or TYPE_ARG_TYPEs of its type.
> > >
> > > Verifying gimple_call_arg () against gimple_call_fntype ()
> > > is pointless.  What should have been used here is
> > >
> > >else
> > >  p = TYPE_ARG_TYPES (TREE_TYPE (gimple_call_fn (stmt)));
> > >
> > > so, gimple_call_fn is the function called (if no fndecl then
> > > this is a function pointer), thus look at the pointed-to type
> > > and then its arguments.
> > 
> > OK, this is a very nice idea, I have made the change in the patch.
> > 
> > >
> > > Maybe you can test/fix that as independent commit.
> > >
> > > Your second case
> > >
> > >> +  if (fndecl
> > >> +  && TYPE_ARG_TYPES (TREE_TYPE (fndecl))
> > >> +  && TYPE_ARG_TYPES (gimple_call_fntype (stmt)))
> > >
> > > then collapses with this and is also the better fallback IMHO
> > > (so enter this case by using TYPE_ARG_TYPES (TREE_TYPE (gimple_call_fn 
> > > (...))) instead of the fndecl).
> > >
> > 
> > The fndecl here is not the decl extracted from the gimple statement.  It
> > is received as a function parameter and two callers extract it from a
> > call graph edge callee and one - speculation resolution - even from the
> > ipa reference associated with the speculation.  So I don't think th
> > should be replaced.
> 
> Hmm, OK.  But then the code cares for fndecl == NULL which as far as
> I can see should not happen.  And in that case it does something
> completely different, so...
> 
> > So, is the following OK (bootstrapped and tested on x86_64-linux,  no
> > LTO bootstrap this time because of PR 92037)?
> > 
> > Martin
> > 
> > 
> > 2019-10-09  Martin Jambor  
> > 
> > PR lto/70929
> > * cgraph.c (gimple_check_call_args): Also compare types of argumen
> > types and call statement fntype types.
> > 
> > testsuite/
> > * g++.dg/lto/pr70929_[01].C: New test.
> > ---
> >  gcc/cgraph.c | 83 ++--
> >  gcc/testsuite/g++.dg/lto/pr70929_0.C | 18 ++
> >  gcc/testsuite/g++.dg/lto/pr70929_1.C | 10 
> >  3 files changed, 95 insertions(+), 16 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.dg/lto/pr70929_0.C
> >  create mode 100644 gcc/testsuite/g++.dg/lto/pr70929_1.C
> > 
> > diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> > index 0c3c6e7cac4..4f7bfa28f37 100644
> > --- a/gcc/cgraph.c
> > +++ b/gcc/cgraph.c
> > @@ -3636,26 +3636,19 @@ cgraph_node::get_fun () const
> >  static bool
> >  gimple_check_call_args (gimple *stmt, tree fndecl, bool args_count_match)
> >  {
> > -  tree parms, p;
> > -  unsigned int i, nargs;
> > -
> >/* Calls to internal functions always match their signature.  */
> >if (gimple_call_internal_p (stmt))
> >  return true;
> >  
> > -  nargs = gimple_call_num_args (stmt);
> > +  unsigned int nargs = gimple_call_num_args (stmt);
> >  
> > -  /* Get argument types for verification.  */
> > -  if (fndecl)
> > -parms = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
> > -  else
> > -parms = TYPE_ARG_TYPES (gimple_call_fntype (stmt));
> > -
> > -  /* Verify if the type of the argument matches that of the function
> > - declaration.  If we cannot verify this or there is a mismatch,
> > - return false.  */
> > +  /* If we have access to the declarations of formal parameters, match 
> > against
> > + those.  */
> >if (fndecl && DECL_ARGUMENTS (fndecl))
> >  {
> > +  unsigned int i;
> > +  tree p;
> > +
> >for (i = 0, p = DECL_ARGUMENTS (fndecl);
> >i < nargs;
> >i++, p = DECL_CHAIN (p))
> > @@ -3676,17 +3669,75 @@ gimple_check_call_args (gimple *stmt, tree fndecl, 
> > bool args_count_match)
> > }
> >if 

Re: Make C2X imply -fno-fp-int-builtin-inexact

2019-10-10 Thread Rainer Orth
Hi Iain,

>>> I’m not quite sure what you’re proposing here (probably missing something
>>> obvious).
>>
>> At the moment, gcc/testsuite/lib/target-supports.exp
>> (add_options_for_c99_runtime) adds -mmacosx-version-min=10.3 to the
>> testcase flags on powerpc-*-darwin*.  Since, as Joseph mentioned, gcc
>> now defaults to -std=gnu11 (which implies a C99 runtime), this (or
>> something similar) would always be needed now (unless someone forces,
>> say, -std=c90) and should be handled in the Darwin/PowerPC driver code,
>> not just the testsuite.
>
> The driver has the following rules:
>
>   * if the user puts -mmacosx-version-min= on the command line that trumps all
>
>   * else we pick a default using the following priority.
> 1. MACOSX_DEPLOYMENT_TARGET env var.
> 2. (native)
>  - what the kernel returns for the system version.
> (cross)
>  - what was set at configure time for DEF_MIN_OSX_VERSION (which will
>be >= 10.3.9 as things stand)
>
> So, of course, if we were hosted on 10.2.8 - that would create a problem
> (2, native)
> but if the system doesn’t have c99 support, that’s a problem anyway.
>
> Otherwise, deliberate mis-configuration or passing -mmacosx-version-min=  in
> RUNTESTFLAGS … but we don’t need to support that.

Right: users should be allowed to shoot themselves ;-)

> Therefore, I suspect that the addition of the "-mmacosx-version-min=10.3”
> is not
> necessary and is a hang-over from older toolchains.

I know now what's going on...

> Perhaps, we could have a target_supports_c99 (maybe we already do), since
> it’s
> feasible that some embedded platforms might also want that exclusion - that
> would
> cover earlier Darwin “automagically” assuming folks remember to apply it.

We do, and it's unsurprisingly called c99_runtime, too: in this as in a
few other cases where a specific feature may need additional options to
enable it, we have dg-add-options  corresponding to the
.

What's happening for c99_runtime, as can be seen in
lib/target-supports.exp (check_effective_target_c99_runtime) is that it
checks gcc.dg/builtins-config.h for a definition of HAVE_C99_RUNTIME.

In the Darwin/PowerPC case, that isn't defined before 10.3, skipping the
affected tests.  However, if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
isn't defined, builtins-config.h #error's out.  Fortunately, gcc on
Darwin always passes -mmacosx-version-min now, so there's no need to
explicitly pass it in add_options_for_c99_runtime and that proc together
with all calls to dg-add-options c99_runtime can go unless something
really unexpected comes up during Solaris testing.

> In any event, there’s no need to hold up fixing this issue,
> If there’s any fallout from it on powerpc-darwin9, I should pick it up
> quite quickly, since
> it’s tested regularly.

Amazing, 14 years after the end of OS updates.  And I thought I were
dealing with software versions right from the museum ;-)

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Fix LTO bootstrap

2019-10-10 Thread Jan Hubicka
Hi,
enabling inlining triggered lifetime-dse issue with symbol_table
constructor.

Bootstrapped/regtested x86_64-linux
* cgraph.c (symbol_table_test::symbol_table_test): Use ggc_alloc
rather than ggc_alloc_cleared to alloc symbol table.
* toplev.c (general_init): Likewise.
* cgraph.h (symbol_table): Explicitly construct every field.
Index: cgraph.c
===
--- cgraph.c(revision 276707)
+++ cgraph.c(working copy)
@@ -3835,7 +3832,7 @@ symbol_table_test::symbol_table_test ()
 {
   gcc_assert (saved_symtab == NULL);
   saved_symtab = symtab;
-  symtab = new (ggc_cleared_alloc  ()) symbol_table ();
+  symtab = new (ggc_alloc  ()) symbol_table ();
 }
 
 /* Destructor.  Restore the old value of symtab.  */
Index: toplev.c
===
--- toplev.c(revision 276707)
+++ toplev.c(working copy)
@@ -1170,7 +1170,7 @@ general_init (const char *argv0, bool in
   /* Create the passes.  */
   g->set_passes (new gcc::pass_manager (g));
 
-  symtab = new (ggc_cleared_alloc  ()) symbol_table ();
+  symtab = new (ggc_alloc  ()) symbol_table ();
 
   statistics_early_init ();
   debuginfo_early_init ();
Index: cgraph.h
===
--- cgraph.h(revision 276707)
+++ cgraph.h(working copy)
@@ -2095,9 +2095,19 @@ public:
   friend struct cgraph_node;
   friend struct cgraph_edge;
 
-  symbol_table (): cgraph_max_uid (1), cgraph_max_summary_id (0),
-  edges_max_uid (1), edges_max_summary_id (0),
-  cgraph_released_summary_ids (), edge_released_summary_ids ()
+  symbol_table (): 
+  cgraph_count (0), cgraph_max_uid (1), cgraph_max_summary_id (0),
+  edges_count (0), edges_max_uid (1), edges_max_summary_id (0),
+  cgraph_released_summary_ids (), edge_released_summary_ids (),
+  nodes (NULL), asmnodes (NULL), asm_last_node (NULL),
+  order (0), global_info_ready (false), state (PARSING),
+  function_flags_ready (false), cpp_implicit_aliases_done (false),
+  section_hash (NULL), assembler_name_hash (NULL), init_priority_hash (NULL),
+  dump_file (NULL), ipa_clones_dump_file (NULL), cloned_nodes (),
+  m_first_edge_removal_hook (NULL), m_first_cgraph_removal_hook (NULL),
+  m_first_edge_duplicated_hook (NULL), m_first_cgraph_duplicated_hook (NULL),
+  m_first_cgraph_insertion_hook (NULL), m_first_varpool_insertion_hook (NULL),
+  m_first_varpool_removal_hook (NULL)
   {
   }
 
@@ -2343,6 +2353,9 @@ public:
   /* Vector of released summary IDS for cgraph nodes.  */
   vec GTY ((skip)) edge_released_summary_ids;
 
+  /* Return symbol used to separate symbol name from suffix.  */
+  static char symbol_suffix_separator ();
+
   symtab_node* GTY(()) nodes;
   asm_node* GTY(()) asmnodes;
   asm_node* GTY(()) asm_last_node;
@@ -2372,9 +2385,6 @@ public:
 
   FILE* GTY ((skip)) dump_file;
 
-  /* Return symbol used to separate symbol name from suffix.  */
-  static char symbol_suffix_separator ();
-
   FILE* GTY ((skip)) ipa_clones_dump_file;
 
   hash_set  GTY ((skip)) cloned_nodes;


Re: [PATCH 1/2][vect]PR 88915: Vectorize epilogues when versioning loops

2019-10-10 Thread Andre Vieira (lists)

Hi,

After all the discussions and respins I now believe this patch is close 
to what we envisioned.


This patch achieves two things when vect-epilogues-nomask=1:
1) It analyzes the original loop for each supported vector size and 
saves this analysis per loop, as well as the vector sizes we know we can 
vectorize the loop for.
2) When loop versioning it uses the 'skip_vector' code path to vectorize 
the epilogue, and uses the lowest versioning threshold between the main 
and epilogue's.


As side effects of this patch I also changed ensure_base_align to only 
update the alignment if the new alignment is lower than the current one. 
 This function already did that if the object was a symbol, now it 
behaves this way for any object.


I bootstrapped this patch with both vect-epilogues-nomask turned on and 
off on x86_64 (AVX512) and aarch64.  Regression tests looked good.


Is this OK for trunk?

gcc/ChangeLog:
2019-10-10  Andre Vieira  

PR 88915
* cfgloop.h (loop): Add epilogue_vsizes member.
* cfgloop.c (flow_loop_free): Release epilogue_vsizes.
(alloc_loop): Initialize epilogue_vsizes.
* gentype.c (main): Add poly_uint64 type and vector_sizes to
generator.
* tree-vect-loop.c (vect_get_loop_niters): Make externally visible.
(_loop_vec_info): Initialize epilogue_vinfos.
(~_loop_vec_info): Release epilogue_vinfos.
(vect_analyze_loop_costing): Use knowledge of main VF to estimate
number of iterations of epilogue.
(determine_peel_for_niter): New. Outlined code to re-use in two
places.
(vect_analyze_loop_2): Adapt to analyse main loop for all supported
vector sizes when vect-epilogues-nomask=1.  Also keep track of lowest
versioning threshold needed for main loop.
(vect_analyze_loop): Likewise.
(replace_ops): New helper function.
(vect_transform_loop): When vectorizing epilogues re-use analysis done
on main loop and update necessary information.
* tree-vect-loop-manip.c (vect_update_inits_of_drs): No longer insert
stmts on loop preheader edge.
(vect_do_peeling): Enable skip-vectors when doing loop versioning if
we decided to vectorize epilogues.  Update epilogues NITERS and
construct ADVANCE to update epilogues data references where needed.
(vect_loop_versioning): Moved decision to check_profitability
based on cost model.
* tree-vect-stmts.c (ensure_base_align): Only update alignment
if new alignment is lower.
* tree-vectorizer.h (_loop_vec_info): Add epilogue_vinfos member.
(vect_loop_versioning, vect_do_peeling, vect_get_loop_niters,
vect_update_inits_of_drs, determine_peel_for_niter,
vect_analyze_loop): Add or update declarations.
* tree-vectorizer.c (try_vectorize_loop_1): Make sure to use already
create loop_vec_info's for epilogues when available.  Otherwise analyse
epilogue separately.



Cheers,
Andre
diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index 0b0154ffd7bf031a005de993b101d9db6dd98c43..d01512ea46467f1cf77793bdc75b48e71b0b9641 100644
--- a/gcc/cfgloop.h
+++ b/gcc/cfgloop.h
@@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
 #define GCC_CFGLOOP_H
 
 #include "cfgloopmanip.h"
+#include "target.h"
 
 /* Structure to hold decision about unrolling/peeling.  */
 enum lpt_dec
@@ -268,6 +269,9 @@ public:
  the basic-block from being collected but its index can still be
  reused.  */
   basic_block former_header;
+
+  /* Keep track of vector sizes we know we can vectorize the epilogue with.  */
+  vector_sizes epilogue_vsizes;
 };
 
 /* Set if the loop is known to be infinite.  */
diff --git a/gcc/cfgloop.c b/gcc/cfgloop.c
index 4ad1f658708f83dbd8789666c26d4bd056837bc6..f3e81bcd00b3f125389aa15b12dc5201b3578d20 100644
--- a/gcc/cfgloop.c
+++ b/gcc/cfgloop.c
@@ -198,6 +198,7 @@ flow_loop_free (class loop *loop)
   exit->prev = exit;
 }
 
+  loop->epilogue_vsizes.release();
   ggc_free (loop->exits);
   ggc_free (loop);
 }
@@ -355,6 +356,7 @@ alloc_loop (void)
   loop->nb_iterations_upper_bound = 0;
   loop->nb_iterations_likely_upper_bound = 0;
   loop->nb_iterations_estimate = 0;
+  loop->epilogue_vsizes.create(8);
   return loop;
 }
 
diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 53317337cf8c8e8caefd6b819d28b3bba301e755..80fb6ef71465b24e034fa45d69fec56be6b2e7f8 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -5197,6 +5197,7 @@ main (int argc, char **argv)
   POS_HERE (do_scalar_typedef ("widest_int", ));
   POS_HERE (do_scalar_typedef ("int64_t", ));
   POS_HERE (do_scalar_typedef ("poly_int64", ));
+  POS_HERE (do_scalar_typedef ("poly_uint64", ));
   POS_HERE (do_scalar_typedef ("uint64_t", ));
   POS_HERE (do_scalar_typedef ("uint8", ));
   POS_HERE (do_scalar_typedef ("uintptr_t", ));
@@ -5206,6 +5207,7 @@ main (int argc, char **argv)
   POS_HERE (do_scalar_typedef ("machine_mode", ));
   POS_HERE (do_scalar_typedef ("fixed_size_mode", ));
   POS_HERE (do_scalar_typedef 

[PATCH] Fix PR92046

2019-10-10 Thread Richard Biener


The following fixes a few param adjustments that are made based on
per-function adjustable flags by moving the adjustments to their
users.  Semantics change in some minor ways but that's allowed
for --params.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2019-10-10  Richard Biener  

PR middle-end/92046
* opts.c (finish_options): Do not influence global --params
from options that are adjustable per function.
* tree-vect-data-refs.c (vect_enhance_data_refs_alignment):
Apply --param adjustment based on active cost-model.
* tree-ssa-phiopt.c (cond_if_else_store_replacement): Disable
further store-sinking when vectorization or if-conversion
are not enabled.

Index: gcc/opts.c
===
--- gcc/opts.c  (revision 276795)+++ gcc/opts.c (working copy)
+++ gcc/opts.c  (working copy)
@@ -1123,24 +1123,6 @@ finish_options (struct gcc_options *opts
   && !opts_set->x_flag_reorder_functions)
 opts->x_flag_reorder_functions = 1;
 
-  /* Tune vectorization related parametees according to cost model.  */
-  if (opts->x_flag_vect_cost_model == VECT_COST_MODEL_CHEAP)
-{
-  maybe_set_param_value (PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS,
-6, opts->x_param_values, opts_set->x_param_values);
-  maybe_set_param_value (PARAM_VECT_MAX_VERSION_FOR_ALIGNMENT_CHECKS,
-0, opts->x_param_values, opts_set->x_param_values);
-  maybe_set_param_value (PARAM_VECT_MAX_PEELING_FOR_ALIGNMENT,
-0, opts->x_param_values, opts_set->x_param_values);
-}
-
-  /* Set PARAM_MAX_STORES_TO_SINK to 0 if either vectorization or if-conversion
- is disabled.  */
-  if ((!opts->x_flag_tree_loop_vectorize && !opts->x_flag_tree_slp_vectorize)
-   || !opts->x_flag_tree_loop_if_convert)
-maybe_set_param_value (PARAM_MAX_STORES_TO_SINK, 0,
-   opts->x_param_values, opts_set->x_param_values);
-
   /* The -gsplit-dwarf option requires -ggnu-pubnames.  */
   if (opts->x_dwarf_split_debug_info)
 opts->x_debug_generate_pub_sections = 2;
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   (revision 276795)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -2075,6 +2075,8 @@ vect_enhance_data_refs_alignment (loop_v
 {
   unsigned max_allowed_peel
 = PARAM_VALUE (PARAM_VECT_MAX_PEELING_FOR_ALIGNMENT);
+ if (flag_vect_cost_model == VECT_COST_MODEL_CHEAP)
+   max_allowed_peel = 0;
   if (max_allowed_peel != (unsigned)-1)
 {
   unsigned max_peel = npeel;
@@ -2168,15 +2170,16 @@ vect_enhance_data_refs_alignment (loop_v
   /* (2) Versioning to force alignment.  */
 
   /* Try versioning if:
- 1) optimize loop for speed
+ 1) optimize loop for speed and the cost-model is not cheap
  2) there is at least one unsupported misaligned data ref with an unknown
 misalignment, and
  3) all misaligned data refs with a known misalignment are supported, and
  4) the number of runtime alignment checks is within reason.  */
 
-  do_versioning =
-   optimize_loop_nest_for_speed_p (loop)
-   && (!loop->inner); /* FORNOW */
+  do_versioning
+= (optimize_loop_nest_for_speed_p (loop)
+   && !loop->inner /* FORNOW */
+   && flag_vect_cost_model > VECT_COST_MODEL_CHEAP);
 
   if (do_versioning)
 {
@@ -3641,13 +3644,15 @@ vect_prune_runtime_alias_test_list (loop
 dump_printf_loc (MSG_NOTE, vect_location,
 "improved number of alias checks from %d to %d\n",
 may_alias_ddrs.length (), count);
-  if ((int) count > PARAM_VALUE (PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS))
+  unsigned limit = PARAM_VALUE (PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS);
+  if (flag_simd_cost_model == VECT_COST_MODEL_CHEAP)
+limit = default_param_value
+ (PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS) * 6 / 10;
+  if (count > limit)
 return opt_result::failure_at
   (vect_location,
-   "number of versioning for alias "
-   "run-time tests exceeds %d "
-   "(--param vect-max-version-for-alias-checks)\n",
-   PARAM_VALUE (PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS));
+   "number of versioning for alias run-time tests exceeds %d "
+   "(--param vect-max-version-for-alias-checks)\n", limit);
 
   return opt_result::success ();
 }
Index: gcc/tree-ssa-phiopt.c
===
--- gcc/tree-ssa-phiopt.c   (revision 276795)
+++ gcc/tree-ssa-phiopt.c   (working copy)
@@ -2467,7 +2467,11 @@ cond_if_else_store_replacement (basic_bl
 then_assign, else_assign);
 }
 
-  if (MAX_STORES_TO_SINK == 0)
+  /* If either vectorization or if-conversion is disabled then do
+ not sink any stores.  */
+  if 

Re: Make C2X imply -fno-fp-int-builtin-inexact

2019-10-10 Thread Iain Sandoe

Hi Rainer,

Rainer Orth  wrote:


Rainer Orth  wrote:




No idea about Darwin/PowerPC though.


Right now, anything < 10.4 is not a viable host (without jumping through
a lot of hoops, regardless of the c99 requirements)...

… but It would be good to continue to support these earlier versions as
cross-
targets (however, it’s low on my priority list to do any serious lifting
there).


ok, good to know.


If pre-10.3 is supposed to be
supported, the -mmacosx-version-min=10.3 probably needs to go into
rs6000/darwin.h first.  Iain?


I’m not quite sure what you’re proposing here (probably missing something
obvious).


At the moment, gcc/testsuite/lib/target-supports.exp
(add_options_for_c99_runtime) adds -mmacosx-version-min=10.3 to the
testcase flags on powerpc-*-darwin*.  Since, as Joseph mentioned, gcc
now defaults to -std=gnu11 (which implies a C99 runtime), this (or
something similar) would always be needed now (unless someone forces,
say, -std=c90) and should be handled in the Darwin/PowerPC driver code,
not just the testsuite.


The driver has the following rules:

  * if the user puts -mmacosx-version-min= on the command line that trumps all

  * else we pick a default using the following priority.
1. MACOSX_DEPLOYMENT_TARGET env var.
2. (native)
 - what the kernel returns for the system version.
(cross)
 - what was set at configure time for DEF_MIN_OSX_VERSION (which will
   be >= 10.3.9 as things stand)

So, of course, if we were hosted on 10.2.8 - that would create a problem  
(2, native)

but if the system doesn’t have c99 support, that’s a problem anyway.

Otherwise, deliberate mis-configuration or passing -mmacosx-version-min=  in
RUNTESTFLAGS … but we don’t need to support that.

Therefore, I suspect that the addition of the "-mmacosx-version-min=10.3”  
is not

necessary and is a hang-over from older toolchains.

Perhaps, we could have a target_supports_c99 (maybe we already do), since  
it’s
feasible that some embedded platforms might also want that exclusion - that  
would

cover earlier Darwin “automagically” assuming folks remember to apply it.

In any event, there’s no need to hold up fixing this issue,
If there’s any fallout from it on powerpc-darwin9, I should pick it up  
quite quickly, since

it’s tested regularly.

thanks,
Iain





Re: [patch][OpenMP,Fortran] Fix several OpenMP use_device_addr/map/update errors found by a length test case

2019-10-10 Thread Jakub Jelinek
On Tue, Oct 08, 2019 at 01:11:53AM +0200, Tobias Burnus wrote:
>   gcc/fortran/
>   * f95-lang.c (LANG_HOOKS_OMP_IS_ALLOCATABLE_OR_PTR): Re-define to
>   gfc_omp_is_allocatable_or_ptr.
>   * trans-decl.c (create_function_arglist): Set GFC_DECL_OPTIONAL_ARGUMENT
>   only if not passed by value.
>   * trans-openmp.c (gfc_omp_is_allocatable_or_ptr): New.
>   (gfc_trans_omp_clauses): Actually pass use_device_addr on to the middle
>   end; for MAP, handle (present) optional arguments; for target update,
>   handle allocatable/pointer scalars.
>   * trans.h (gfc_omp_is_allocatable_or_ptr): Declare.
> 
>   gcc/
>   * langhooks-def.h (LANG_HOOKS_OMP_IS_ALLOCATABLE_OR_PTR): Define.
>   (LANG_HOOKS_DECLS): Add it.
>   * langhooks.h (lang_hooks_for_decls): Add omp_is_allocatable_or_ptr;
>   update comment for omp_is_optional_argument.
>   * omp-general.c (omp_is_allocatable_or_ptr): New.
>   * omp-general.h (omp_is_allocatable_or_ptr): Declare.
>   * omp-low.c (scan_sharing_clauses, lower_omp_target): Handle
>   Fortran's optional arguments and allocatable/pointer scalars
>   with use_device_addr.

This looks reasonable, with a small nit.

>   libgomp/
>   * testsuite/libgomp.fortran/use_device_addr-1.f90: New.
>   * testsuite/libgomp.fortran/use_device_addr-2.f90: New.

I'm worried about the tests though.

> @@ -11678,7 +11680,18 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
> omp_context *ctx)
> }
>   else
> {
> - var = build_fold_addr_expr (var);
> + // While MAP is handled explicitly by the FE,
> + // for 'target update', only the identified is passed.

omp-low.c (like most of gcc/*.c) uses /* ... */ comments almost everywhere,
can you please just use the same here?
Otherwise the non-test part LGTM.

What worries me about the test is that the officially only portable way
to use it in a target region is is_device_ptr.  I believe the intention was
to allow the implementation to transform the pointers from e.g.
use_device_ptr to whatever the implementation wants, where it could be e.g.
a structure containing pointer and something or whatever and is_device_ptr
actually finishing it up, even when in our implementation is_device_ptr is
basically just copying the pointer bits from host to device (==
firstprivate).
Yes, I know there is the restriction that the is_device_ptr list item must
be a dummy variable without VALUE/ALLOCATABLE/POINTER.  VALUE itself
wouldn't be a big deal, we could call just by reference instead of value,
but allocatable/pointer I bet is a problem.  So, if there is no portable
way in Fortran to pass c_loc result as a dummy argument to some subprogram
where the dummy argument is not allocatable/pointer, and the caller doesn't
access the actual data in any way, I'm afraid we need to do what you are
doing.  But then the test should start with a comment that it is not
portable and assumes that is_device_ptr doesn't need to transform the
use_device_ptr addresses in any way.  Or another option would be to use C
code for the actual target region, c_loc is for C pointers and if you pass
to C code the c_loc as a pointer and pass in the array size/whatever else it
needs to know, it can then implement it portably with is_device_ptr clause
on the C pointer.

Jakub


[Ada] Fix awkward placement of freeze node for actual subtype

2019-10-10 Thread Pierre-Marie de Rodat
In the case where the tyoe of the formal has a predicate, the compiler
generates a freeze node for the actual subtype of the formal that is
placed just before the declaration of that subtype.  No big deal, but
awkward enough as to warrant a correction.  No functional changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Eric Botcazou  

gcc/ada/

* sem_ch6.adb (Set_Actual_Subtypes): Put the freeze node of the
actual subtype after its declaration when the type of the formal
has a predicate.--- gcc/ada/sem_ch6.adb
+++ gcc/ada/sem_ch6.adb
@@ -12038,7 +12038,7 @@ package body Sem_Ch6 is
 --  predicate may come from an explicit aspect of be inherited.
 
 elsif Has_Predicates (T) then
-   Insert_List_Before_And_Analyze (Decl,
+   Insert_List_After_And_Analyze (Decl,
  Freeze_Entity (Defining_Identifier (Decl), N));
 end if;
 



[Ada] Spurious restriction violation on Ghost code

2019-10-10 Thread Pierre-Marie de Rodat
This patch fixes a spurious error when expanding the code for a function
that appears in a Ghost context, when return return type of the function
is unconstrainedm and the restriction No_Secondary_Stack is active.

Running this command:

  gcc -c repro_main.adb

On the following sources:

with Bounded_Table;

procedure Repro_Main
is
   package B is new
 Bounded_Table (Element_Type => Integer, Max => 1000, Null_Elem => 0);

   pragma Unreferenced (B);
begin
   null;
end Repro_Main;
package body Bounded_Table is

   function Model (Table : T) return Model_Type
   is (Model_Type (Table.Elems (Table.Elems'First .. Table.Last)));

end Bounded_Table;

Should execute silently.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Ed Schonberg  

gcc/ada/

* exp_ch6.adb (Expand_Simple_Function_Return_Statement): If the
function to which the return statement applies is an
Ignored_Ghost_Function, do not indicate that it uses the
secondary stack when the return type is unconstrained.--- gcc/ada/exp_ch6.adb
+++ gcc/ada/exp_ch6.adb
@@ -6895,7 +6895,12 @@ package body Exp_Ch6 is
   elsif Is_Thunk (Current_Scope) and then Is_Incomplete_Type (Exptyp) then
  return;
 
-  elsif not Requires_Transient_Scope (R_Type) then
+  --  A return statement from a Ghost function does not use the secondary
+  --  stack (or any other one).
+
+  elsif not Requires_Transient_Scope (R_Type)
+or else Is_Ignored_Ghost_Entity (Scope_Id)
+  then
 
  --  Mutable records with variable-length components are not returned
  --  on the sec-stack, so we need to make sure that the back end will



[Ada] Do not inline subprograms with deep parameter/result in GNATprove

2019-10-10 Thread Pierre-Marie de Rodat
Subprograms with a parameter or function result with deep type should
not be inlined in the special mode for GNATprove, as inlining may lead
to spurious violations of SPARK borrow-checking rules for pointers.

There is no impact on compilation and thus no test.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Yannick Moy  

gcc/ada/

* inline.adb (Can_Be_Inlined_In_GNATprove_Mode): Add subprograms
with deep parameter or result type as not candidates for
inlining.--- gcc/ada/inline.adb
+++ gcc/ada/inline.adb
@@ -1493,6 +1493,12 @@ package body Inline is
  (Spec_Id : Entity_Id;
   Body_Id : Entity_Id) return Boolean
is
+  function Has_Formal_Or_Result_Of_Deep_Type
+(Id : Entity_Id) return Boolean;
+  --  Returns true if the subprogram has at least one formal parameter or
+  --  a return type of a deep type: either an access type or a composite
+  --  type containing an access type.
+
   function Has_Formal_With_Discriminant_Dependent_Fields
 (Id : Entity_Id) return Boolean;
   --  Returns true if the subprogram has at least one formal parameter of
@@ -1518,6 +1524,104 @@ package body Inline is
   --  knowledge of the SPARK boundary is needed to determine exactly
   --  traversal functions.
 
+  ---
+  -- Has_Formal_Or_Result_Of_Deep_Type --
+  ---
+
+  function Has_Formal_Or_Result_Of_Deep_Type
+(Id : Entity_Id) return Boolean
+  is
+ function Is_Deep (Typ : Entity_Id) return Boolean;
+ --  Return True if Typ is deep: either an access type or a composite
+ --  type containing an access type.
+
+ -
+ -- Is_Deep --
+ -
+
+ function Is_Deep (Typ : Entity_Id) return Boolean is
+ begin
+case Type_Kind'(Ekind (Typ)) is
+   when Access_Kind =>
+  return True;
+
+   when E_Array_Type
+  | E_Array_Subtype
+   =>
+  return Is_Deep (Component_Type (Typ));
+
+   when Record_Kind =>
+  declare
+ Comp : Entity_Id := First_Component_Or_Discriminant (Typ);
+  begin
+ while Present (Comp) loop
+if Is_Deep (Etype (Comp)) then
+   return True;
+end if;
+Next_Component_Or_Discriminant (Comp);
+ end loop;
+  end;
+  return False;
+
+   when Scalar_Kind
+  | E_String_Literal_Subtype
+  | Concurrent_Kind
+  | Incomplete_Kind
+  | E_Exception_Type
+  | E_Subprogram_Type
+   =>
+  return False;
+
+   when E_Private_Type
+  | E_Private_Subtype
+  | E_Limited_Private_Type
+  | E_Limited_Private_Subtype
+   =>
+  --  Conservatively consider that the type might be deep if
+  --  its completion has not been seen yet.
+
+  if No (Underlying_Type (Typ)) then
+ return True;
+  else
+ return Is_Deep (Underlying_Type (Typ));
+  end if;
+end case;
+ end Is_Deep;
+
+ --  Local variables
+
+ Subp_Id: constant Entity_Id := Ultimate_Alias (Id);
+ Formal : Entity_Id;
+ Formal_Typ : Entity_Id;
+
+  --  Start of processing for Has_Formal_Or_Result_Of_Deep_Type
+
+  begin
+ --  Inspect all parameters of the subprogram looking for a formal
+ --  of a deep type.
+
+ Formal := First_Formal (Subp_Id);
+ while Present (Formal) loop
+Formal_Typ := Etype (Formal);
+
+if Is_Deep (Formal_Typ) then
+   return True;
+end if;
+
+Next_Formal (Formal);
+ end loop;
+
+ --  Check whether this is a function whose return type is deep
+
+ if Ekind (Subp_Id) = E_Function
+   and then Is_Deep (Etype (Subp_Id))
+ then
+return True;
+ end if;
+
+ return False;
+  end Has_Formal_Or_Result_Of_Deep_Type;
+
   ---
   -- Has_Formal_With_Discriminant_Dependent_Fields --
   ---
@@ -1777,6 +1881,14 @@ package body Inline is
   elsif Has_Formal_With_Discriminant_Dependent_Fields (Id) then
  return False;
 
+  --  Do not inline subprograms with a formal parameter or return type of
+  --  a deep type, as in that case inlining might generate code that
+  --  violates borrow-checking rules of SPARK 3.10 even if the 

[Ada] Spurious visibility error on formal package with Abstract_State

2019-10-10 Thread Pierre-Marie de Rodat
Compiler rejects a formal package in a generic unit, when the
corresponding generic package includes the SPARK aspect Abstract_State,
and the name introduced by the aspect is referenced in the generic
package.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Ed Schonberg  

gcc/ada/

* sem_ch12.adb (Analyze_Formal_Package_Declaration): Propagate
an aspect specification for Abstract_State from generic package
to formal package, so that it is available when analyzing the
constructed formal.--- gcc/ada/sem_ch12.adb
+++ gcc/ada/sem_ch12.adb
@@ -2925,6 +2925,41 @@ package body Sem_Ch12 is
   Set_Ekind  (Formal, E_Package);
   Set_Etype  (Formal, Standard_Void_Type);
   Set_Inner_Instances (Formal, New_Elmt_List);
+
+  --  It is unclear that any aspects can apply to a formal package
+  --  declaration, given that they look like a hidden comformance
+  --  requirement on the corresponding actual. However, Abstract_State
+  --  must be treated specially because it generates declarations that
+  --  must appear before other declarations in the specification and
+  --  must be analyzed at once.
+
+  if Present (Aspect_Specifications (Gen_Decl)) then
+ if No (Aspect_Specifications (N)) then
+Set_Aspect_Specifications (N, New_List);
+Set_Has_Aspects (N);
+ end if;
+
+ declare
+ASN   : Node_Id := First (Aspect_Specifications (Gen_Decl));
+New_A : Node_Id;
+
+ begin
+while Present (ASN) loop
+   if Get_Aspect_Id (ASN) = Aspect_Abstract_State then
+  New_A :=
+Copy_Generic_Node (ASN, Empty, Instantiating => True);
+  Set_Entity (New_A, Formal);
+  Set_Analyzed (New_A, False);
+  Append (New_A, Aspect_Specifications (N));
+  Analyze_Aspect_Specifications (N, Formal);
+  exit;
+   end if;
+
+   Next (ASN);
+end loop;
+ end;
+  end if;
+
   Push_Scope  (Formal);
 
   --  Manually set the SPARK_Mode from the context because the package
@@ -3023,6 +3058,9 @@ package body Sem_Ch12 is
 
<>
   if Has_Aspects (N) then
+ --  Unclear that any other aspects may appear here, snalyze them
+ --  for completion, given that the grammar allows their appearance.
+
  Analyze_Aspect_Specifications (N, Pack_Id);
   end if;
 



[Ada] Ensure constructor is a C++ constructor

2019-10-10 Thread Pierre-Marie de Rodat
Freeze_Subprogram has special handling of C++ constructor interfacing.
This is currently implicit but assuming we introduce other conventions
(e.g. Java) the current code won't hold.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Arnaud Charlet  

gcc/ada/

* freeze.adb (Freeze_Subprogram): Ensure constructor is a C++
constructor.--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -8780,6 +8780,7 @@ package body Freeze is
   --  (either in pragma CPP_Constructor or in a pragma import).
 
   if Is_Constructor (E)
+and then Convention (E) = Convention_CPP
 and then
(No (Interface_Name (E))
   or else String_Equal



Re: [patch] disentangle range_fold_*ary_expr into various pieces

2019-10-10 Thread Christophe Lyon
On Thu, 10 Oct 2019 at 17:19, Aldy Hernandez  wrote:

> It's not that particular commit, but the previous one, but yeah, that's
> all me.

Interesting, bisect really identified r276654.

I think that's what Steve reported as PR 92051 (although his backtrace is
different, but it's also for a different testcase).




> (gdb)
> #4  0x0145bf44 in value_range_base::lower_bound
> (this=0x7fffc360,
>  pair=0) at /home/cygnus/aldyh/src/gcc/gcc/tree-vrp.c:6148
> 6148  return wi::to_wide (t);
> (gdb)
> #5  0x01ccb1d9 in range_operator::fold_range (
>  this=0x271edc8 , type=, lh=...,
>  rh=...) at /home/cygnus/aldyh/src/gcc/gcc/range-op.cc:156
> 156 wide_int rh_lb = rh.lower_bound (y);
> (gdb)
> #6  0x0144b850 in range_fold_binary_expr (vr=0x7fffc6c0,
>  code=PLUS_EXPR, expr_type=,
>  vr0_=0x7fffc480, vr1_=0x7fffc460)
>  at /home/cygnus/aldyh/src/gcc/gcc/tree-vrp.c:1927
> 1927vr1.normalize_addresses ());
> (gdb) l
> 1922  if (range_fold_binary_symbolics_p (vr, code, expr_type, ,
> ))
> 1923return;
> 1924
> 1925  *vr = op->fold_range (expr_type,
> 1926vr0.normalize_addresses (),
> 1927vr1.normalize_addresses ());
> 1928}
> 1929
> 1930/* Perform a unary operation on a range.  */
> 1931
> (gdb) print vr1.dump()
> unsigned long [POLY_INT_CST [4, 4], POLY_INT_CST [4, 4]]$1 = void
> (gdb)
>
> We have a value_range_base containing a POLYT_INT_CST which we don't
> handle.
>
> That's rather unfortunate.  I was hoping by this point, anything we
> couldn't handle was just an address.  The previous range-ops code was
> normalizing anything not INTEGER_CST into VARYING, which I thought was a
> rather big hammer, and was trying to avoid.
>
> Interesting that the old VRP code also allowing the POLY_INT to pass on
> through all the way into extract_range_binary_expr, only to bail when it
> see's it's not an INTEGER_CST:
>
>&& (TREE_CODE (max_op0) == INTEGER_CST
>|| (sym_max_op0
>= get_single_symbol (max_op0, _max_op0, _op0)))
>&& (TREE_CODE (max_op1) == INTEGER_CST
>|| (sym_max_op1
>= get_single_symbol (max_op1, _max_op1, _op1)))
>
> I guess we could bring out the big hammer again if normalize_addresses
> doesn't give us an INTEGER_CST.
>
> I'll take a look at this.  Thanks for pointing it out.
>
> Thanks,

Christophe


> Aldy
>
> On 10/10/19 5:25 AM, Christophe Lyon wrote:
> >
> >
> > On Mon, 7 Oct 2019 at 13:53, Aldy Hernandez  > > wrote:
> >
> >
> >  > +bool
> >  > +ipa_vr::nonzero_p (tree expr_type) const
> >  > +{
> >  > +  if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p
> > (max, 0))
> >  > +return true;
> >  > +
> >  > +  unsigned prec = TYPE_PRECISION (expr_type);
> >  > +  return (type == VR_RANGE
> >  > + && wi::eq_p (min, wi::one (prec))
> >  > + && wi::eq_p (max, wi::max_value (prec, TYPE_SIGN
> > (expr_type;
> >  > +}
> >
> > Errr, wrong version posted.  There was a TYPE_UNSIGNED missing.
> >
> > Fixed and committed.
> >
> >
> > Hi,
> > Since this was committed (r276654), I've noticed regressions on aarch64:
> >  gcc.target/aarch64/pr88838.c (test for excess errors)
> >  gcc.target/aarch64/stack-check-cfa-3.c (test for excess errors)
> >  gcc.target/aarch64/stack-check-prologue-16.c (test for excess
> errors)
> >  gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve
> >   scan-assembler-times \\tabs\\tz[0-9]+\\.b, p[0-7]/m, z[0-9]+\\.b\\n 1
> >  gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve
> >   scan-assembler-times \\tabs\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1
> >  gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve
> >   scan-assembler-times \\tabs\\tz[0-9]+\\.h, p[0-7]/m, z[0-9]+\\.h\\n 1
> >  gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve
> >   scan-assembler-times \\tabs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.s\\n 1
> >  gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve (test for
> > excess errors)
> >  gcc.target/aarch64/sve/adr_1.c -march=armv8.2-a+sve (test for
> > excess errors)
> >
> > and many others
> >
> > For instance:
> > compiler exited with status 1
> > FAIL: gcc.target/aarch64/pr88838.c (internal compiler error)
> > FAIL: gcc.target/aarch64/pr88838.c (test for excess errors)
> > Excess errors:
> > during GIMPLE pass: dom
> > /gcc/testsuite/gcc.target/aarch64/pr88838.c:5:1: internal compiler
> > error: tree check: expected integer_cst, have poly_int_cst in to_wide,
> > at tree.h:5795
> > 0x5efa71 tree_check_failed(tree_node const*, char const*, int, char
> > const*, ...)
> >  /gcc/tree.c:9926
> > 0x749584 tree_check(tree_node const*, char const*, int, char const*,
> > tree_code)
> >  /gcc/tree.h:3523
> > 0x749584 wi::to_wide(tree_node const*)

Re: [PATCH][ARM] Remove support for MULS

2019-10-10 Thread Wilco Dijkstra
Any further comments? Note GCC doesn't support S/UMULLS either since it is 
equally
useless. It's no surprise that Thumb-2 removed support for flag-setting 64-bit 
multiplies,
while AArch64 didn't add flag-setting multiplies. So there is no argument that 
these
instructions are in any way useful to compilers.

Wilco

Hi Richard, Kyrill,

>> I disagree. If they still trigger and generate better code than without 
>> we should keep them.
> 
>> What kind of code is *common* varies greatly from user to user.

Not really - doing a multiply and checking whether the result is zero is
exceedingly rare. I found only 3 cases out of 7300 mul/mla in all of
SPEC2006... Overall codesize effect with -Os: 28 bytes or 0.00045%.

So we really should not even consider wasting any more time on
maintaining such useless patterns.

> Also, the main reason for restricting their use was that in the 'olden 
> days', when we had multi-cycle implementations of the multiply 
> instructions with short-circuit fast termination when the result was 
> completed, the flag setting variants would never short-circuit.

That only applied to conditional multiplies IIRC, some implementations
would not early-terminate if the condition failed. Today there are serious
penalties for conditional multiplies - but that's something to address in a
different patch.

> These days we have fixed cycle counts for multiply instructions, so this 
> is no-longer a penalty.  

No, there is a large overhead on modern cores when you set the flags,
and there are other penalties due to the extra micro-ops.

> In the thumb2 case in particular we can often 
> reduce mul-cmp (6 bytes) to muls (2 bytes), that's a 66% saving on this 
> sequence and definitely worth exploiting when we can, even if it's not 
> all that common.

Using muls+cbz is equally small. With my patch we generate this with -Os:

void g(void);
int f(int x)
{
  if (x * x != 0)
g();
}

f:
mulsr0, r0, r0
push{r3, lr}
cbz r0, .L9
bl  g
.L9:
pop {r3, pc}

Wilco

Re: [PATCH][ARM] Correctly set SLOW_BYTE_ACCESS

2019-10-10 Thread Wilco Dijkstra
ping

Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration
on practically any target.  So set it correctly to 1 on Arm.

As a result we generate much better code for bitfields:

typedef struct
{
  int x : 2, y : 8, z : 2;
} X;

int bitfield (X *p)
{
  return p->x + p->y + p->z;
}


Before:
ldrbr3, [r0]@ zero_extendqisi2
ldrhr2, [r0]
ldrbr0, [r0, #1]@ zero_extendqisi2
sbfxr3, r3, #0, #2
sbfxr2, r2, #2, #8
sbfxr0, r0, #2, #2
sxtab   r3, r2, r3
sxtab   r0, r3, r0
bx  lr

After:
ldr r0, [r0]
sbfxr3, r0, #0, #2
sbfxr2, r0, #2, #8
sbfxr0, r0, #10, #2
sxtab   r3, r2, r3
add r0, r0, r3
bx  lr

Bootstrap OK, OK for commit?

ChangeLog:
2019-09-11  Wilco Dijkstra  

* config/arm/arm.h (SLOW_BYTE_ACCESS): Set to 1.

--

diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
8b92c830de09a3ad49420fdfacde02d8efc2a89b..11212d988a0f56299c2266bace80170d074be56c
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1892,8 +1892,9 @@ enum arm_auto_incmodes
((arm_arch4 || (MODE) == QImode) ? ZERO_EXTEND  \
 : ((BYTES_BIG_ENDIAN && (MODE) == HImode) ? SIGN_EXTEND : UNKNOWN)))
 
-/* Nonzero if access to memory by bytes is slow and undesirable.  */
-#define SLOW_BYTE_ACCESS 0
+/* Contrary to all documentation, this enables wide bitfield accesses,
+   which results in better code when accessing multiple bitfields.  */
+#define SLOW_BYTE_ACCESS 1
 
 /* Immediate shift counts are truncated by the output routines (or was it
the assembler?).  Shift counts in a register are truncated by ARM.  Note


[Ada] Replace in Ordered_Maps gets tampering failure

2019-10-10 Thread Pierre-Marie de Rodat
This patch fixes a bug in which a call such as
Some_Map.Replace(10, Some_Map(5)) fails a tampering check. This happens
with the Some_Map(5) notation, or with the equivalent explicit call to
Constant_Reference. A call to Some_Map.Delete(10, Some_Map(5)) fails in
the same way. Other children of Ada.Containers are affected in the same
way.

Running these commands:

  gnatmake -q -f -g -O0 -gnata test_vectors.adb
  test_vectors

On the following sources:

with Ada.Containers.Vectors;

procedure Test_Vectors is

   package My_Vectors is new Ada.Containers.Vectors (Positive, Float);
   use My_Vectors;

   My_Vector : Vector := To_Vector (10.123, 20);

begin
   My_Vector.Replace_Element(10, My_Vector(5));
end Test_Vectors;

Should execute silently.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Bob Duff  

gcc/ada/

* libgnat/a-cbdlli.adb, libgnat/a-cbhama.adb,
libgnat/a-cbhase.adb, libgnat/a-cbmutr.adb,
libgnat/a-cborma.adb, libgnat/a-cborse.adb,
libgnat/a-cdlili.adb, libgnat/a-cidlli.adb,
libgnat/a-cihama.adb, libgnat/a-cihase.adb,
libgnat/a-cimutr.adb, libgnat/a-ciorma.adb,
libgnat/a-ciorse.adb, libgnat/a-cobove.adb,
libgnat/a-cohama.adb, libgnat/a-cohase.adb,
libgnat/a-coinve.adb, libgnat/a-comutr.adb,
libgnat/a-conhel.adb, libgnat/a-convec.adb,
libgnat/a-coorma.adb, libgnat/a-coorse.adb (Reference,
Constant_Reference): Use Busy instead of Lock, so we forbid
tampering with cursors, rather than tampering with elements.

patch.diff.gz
Description: application/gzip


[Ada] Spurious visibility error in predicate in generic instance

2019-10-10 Thread Pierre-Marie de Rodat
Compilation_Unit pragmas that appear after the corresponding unit are
analyzed before the declarations in the unit, in order to set proper
categorization flags and verify that they are respected by those
declarations. If the unit is a child unit and also the instance of a
generic child unit the parent unit may have to become visible during the
analysis of the pragma.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Ed Schonberg  

gcc/ada/

* sem_cat.adb (Set_Categorization_From_Pragma): Do not modify
any visibility settings if there are no compilation_unit pragmas
following the package declaration. Add comments for future
cleanup.--- gcc/ada/sem_cat.adb
+++ gcc/ada/sem_cat.adb
@@ -721,9 +721,15 @@ package body Sem_Cat is
   --  The purpose is to set categorization flags before analyzing the
   --  unit itself, so as to diagnose violations of categorization as
   --  we process each declaration, even though the pragma appears after
-  --  the unit.
-
-  if Nkind (P) /= N_Compilation_Unit then
+  --  the unit. This processing is only needsd if compilation unit
+  --  pragmas are present.
+  --  Note: this code may be incorrect in the unlikely case a child
+  --  genericc unit is instantiated as a child of its (non-generic)
+  --  parent, so that generic and insstance are siblings,
+
+  if Nkind (P) /= N_Compilation_Unit
+ or else No (First (Pragmas_After (Aux_Decls_Node (P
+  then
  return;
   end if;
 



[Ada] Use declared type for deciding on SPARK pointer rules

2019-10-10 Thread Pierre-Marie de Rodat
A constant of pointer type is considered as mutable in SPARK, according
to SPARK RM 3.10, but this should be based on the declared type of the
constant instead of its underlying type.

This rule has been already reflected in a recent commit for the Depends
contract; this commit is for the Global contract.

There is no impact on compilation hence no test.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Piotr Trojanek  

gcc/ada/

* sem_prag.adb (Analyze_Global_In_Decl_Part): Simplify previous
test, just like in a recent commit we simplified a similar test
for Depends contract.--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -2429,8 +2429,7 @@ package body Sem_Prag is
--  Constant related checks
 
elsif Ekind (Item_Id) = E_Constant
- and then
-   not Is_Access_Type (Underlying_Type (Etype (Item_Id)))
+ and then not Is_Access_Type (Etype (Item_Id))
then
 
   --  Unless it is of an access type, a constant is a read-only



Re: [PATCH][AArch64] Fix symbol offset limit

2019-10-10 Thread Wilco Dijkstra
ping

In aarch64_classify_symbol symbols are allowed full-range offsets on 
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset 
available
for the symbol itself.  This results in relocation overflow and link-time 
errors
for simple expressions like _char + 0xff00.

To avoid this, limit the offset to +/-1MB so that the symbol needs to be 
within a
3.9GB offset from its references.  For the tiny code model use a 64KB 
offset, allowing
most of the 1MB range for code/data between the symbol and its references.

Bootstrapped on AArch64, passes regress, OK for commit?

ChangeLog:
2018-11-09  Wilco Dijkstra  

gcc/
* config/aarch64/aarch64.c (aarch64_classify_symbol):
Apply reasonable limit to symbol offsets.

testsuite/
* gcc.target/aarch64/symbol-range.c (foo): Set new limit.
* gcc.target/aarch64/symbol-range-tiny.c (foo): Likewise.

--

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 
83453d03095018eddd1801e71ef3836849267444..0023cb37bbae5afe9387840c1bb6b43586d4fac2
 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -13047,26 +13047,26 @@ aarch64_classify_symbol (rtx x, HOST_WIDE_INT 
offset)
  the offset does not cause overflow of the final address.  But
  we have no way of knowing the address of symbol at compile 
time
  so we can't accurately say if the distance between the PC and
-symbol + offset is outside the addressible range of +/-1M in 
the
-TINY code model.  So we rely on images not being greater than
-1M and cap the offset at 1M and anything beyond 1M will have to
-be loaded using an alternative mechanism.  Furthermore if the
-symbol is a weak reference to something that isn't known to
-resolve to a symbol in this module, then force to memory.  */
+symbol + offset is outside the addressible range of +/-1MB in 
the
+TINY code model.  So we limit the maximum offset to +/-64KB and
+assume the offset to the symbol is not larger than +/-(1MB - 
64KB).
+Furthermore force to memory if the symbol is a weak reference 
to
+something that doesn't resolve to a symbol in this module.  */
   if ((SYMBOL_REF_WEAK (x)
&& !aarch64_symbol_binds_local_p (x))
- || !IN_RANGE (offset, -1048575, 1048575))
+ || !IN_RANGE (offset, -0x1, 0x1))
 return SYMBOL_FORCE_TO_MEM;
+
   return SYMBOL_TINY_ABSOLUTE;
 
 case AARCH64_CMODEL_SMALL:
   /* Same reasoning as the tiny code model, but the offset cap 
here is
-4G.  */
+1MB, allowing +/-3.9GB for the offset to the symbol.  */
   if ((SYMBOL_REF_WEAK (x)
&& !aarch64_symbol_binds_local_p (x))
- || !IN_RANGE (offset, HOST_WIDE_INT_C (-4294967263),
-   HOST_WIDE_INT_C (4294967264)))
+ || !IN_RANGE (offset, -0x10, 0x10))
 return SYMBOL_FORCE_TO_MEM;
+
   return SYMBOL_SMALL_ABSOLUTE;
 
 case AARCH64_CMODEL_TINY_PIC:
diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range-tiny.c 
b/gcc/testsuite/gcc.target/aarch64/symbol-range-tiny.c
index 
d7e46b059e41f2672b3a1da5506fa8944e752e01..d49ff4dbe5786ef6d343d2b90052c09676dd7fe5
 100644
--- a/gcc/testsuite/gcc.target/aarch64/symbol-range-tiny.c
+++ b/gcc/testsuite/gcc.target/aarch64/symbol-range-tiny.c
@@ -1,12 +1,12 @@
-/* { dg-do compile } */
+/* { dg-do link } */
 /* { dg-options "-O3 -save-temps -mcmodel=tiny" } */
 
-int fixed_regs[0x0020];
+char fixed_regs[0x0020];
 
 int
-foo()
+main ()
 {
-  return fixed_regs[0x0008];
+  return fixed_regs[0x000ff000];
 }
 
 /* { dg-final { scan-assembler-not "adr\tx\[0-9\]+, fixed_regs\\\+" } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range.c 
b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
index 
6574cf4310430b847e77ea56bf8f20ef312d53e4..75c87c12f08004c153efc5192e5cfab566c089db
 100644
--- a/gcc/testsuite/gcc.target/aarch64/symbol-range.c
+++ b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
@@ -1,12 +1,12 @@
-/* { dg-do compile } */
+/* { dg-do link } */
 /* { dg-options "-O3 -save-temps -mcmodel=small" } */
 
-int fixed_regs[0x2ULL];
+char fixed_regs[0x2ULL];
 
 int
-foo()
+main ()
 {
-  return fixed_regs[0x1ULL];
+  return fixed_regs[0xf000ULL];
 }
 
 /* { dg-final { scan-assembler-not 

Re: [C++ Patch] Remove RROTATE_EXPR and LROTATE_EXPR handling

2019-10-10 Thread Jason Merrill

On 10/10/19 12:12 PM, Paolo Carlini wrote:

Hi,

while working on cp_build_binary_op I noticed that the testsuite wasn't 
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even more 
the code handling those tree codes seemed completely unused. Turned out 
that the C front-end doesn't handle those tree codes at all: I'm coming 
to the conclusion that the C++ front-end bits too are now obsolete and 
may be removed, because only the middle-end generates those codes in 
order to implement optimizations. Anything I'm missing? Any additional 
testing? Tested x86_64-linux.


Thanks, Paolo.

///


OK.



Re: [patch][OpenMP,Fortran] Fix several OpenMP use_device_addr/map/update errors found by a length test case

2019-10-10 Thread Tobias Burnus

Hi Jakub,

On 10/10/19 1:55 PM, Jakub Jelinek wrote:

What worries me about the test is that the officially only portable way
to use it in a target region is is_device_ptr.


How about the attached test cases? The only difference is in "module 
target_procs".


OK now?


Still, I hope the next round of the OpenMP spec permits additionally 
"type(c_ptr)" – locally defined or as dummy argument with value attribute.


Tobias

PS: is_device_ptr(scalar_real_dummy) crashes as one does a dereference 
too much. I make a detour by creating a 1-element array out the 
c-pointer. That's not nice but I believe it is standard conform. In any 
case, I would prefer to defer modifying the code for is_device_ptr 
and/or use_device_ptr to another round. (And I need also to get a better 
understanding what is_device_ptr should actually accept as argument and 
do with it. It is as unclear to me as use_device_ptr.)


! Comprehensive run-time test for use_device_addr
!
! Differs from use_device_addr-2.f90 by using a 8-byte variable (c_double)
!
! This test case assumes that a 'var' appearing in 'use_device_addr' is
! only used as 'c_loc(var)' - such that only the actual data is used/usable
! on the device - and not meta data ((dynamic) type information, 'present()'
! status, array shape).
!
! Untested in this test case are:
! - arrays with array descriptor
! - polymorphic variables
! - absent optional arguments
!
module target_procs
  use iso_c_binding
  implicit none
  private
  public :: copy3_array, copy3_scalar
contains
  subroutine copy3_array_int(from_ptr, to_ptr, N)
!$omp declare target
real(c_double) :: from_ptr(:)
real(c_double) :: to_ptr(:)
integer, value :: N
integer :: i

!$omp parallel do
do i = 1, N
  to_ptr(i) = 3 * from_ptr(i)
end do
!$omp end parallel do
  end subroutine copy3_array_int

  subroutine copy3_scalar_int(from, to)
!$omp declare target
real(c_double) :: from, to

to = 3 * from
  end subroutine copy3_scalar_int


  subroutine copy3_array(from, to, N)
type(c_ptr), value :: from, to
integer, value :: N
real(c_double), pointer :: from_ptr(:), to_ptr(:)

call c_f_pointer(from, from_ptr, shape=[N])
call c_f_pointer(to, to_ptr, shape=[N])

call do_offload_scalar(from_ptr,to_ptr)
  contains
subroutine do_offload_scalar(from_r, to_r)
  real(c_double), target :: from_r(:), to_r(:)
  ! The extra function is needed as is_device_ptr
  ! requires non-value, non-pointer dummy arguments

  !$omp target is_device_ptr(from_r, to_r)
  call copy3_array_int(from_r, to_r, N)
  !$omp end target
end subroutine do_offload_scalar
  end subroutine copy3_array

  subroutine copy3_scalar(from, to)
type(c_ptr), value, target :: from, to
real(c_double), pointer :: from_ptr(:), to_ptr(:)

! Standard-conform detour of using an array as at time of writing
! is_device_ptr below does not handle scalars
call c_f_pointer(from, from_ptr, shape=[1])
call c_f_pointer(to, to_ptr, shape=[1])

call do_offload_scalar(from_ptr,to_ptr)
  contains
subroutine do_offload_scalar(from_r, to_r)
  real(c_double), target :: from_r(:), to_r(:)
  ! The extra function is needed as is_device_ptr
  ! requires non-value, non-pointer dummy arguments

  !$omp target is_device_ptr(from_r, to_r)
  call copy3_scalar_int(from_r(1), to_r(1))
  !$omp end target
end subroutine do_offload_scalar
  end subroutine copy3_scalar
end module target_procs



! Test local dummy arguments (w/o optional)
module test_dummies
  use iso_c_binding
  use target_procs
  implicit none
  private
  public :: test_dummy_call_1, test_dummy_call_2
contains
  subroutine test_dummy_call_1()
 integer, parameter :: N = 1000

 ! scalars
 real(c_double), target :: aa, bb
 real(c_double), target, allocatable :: cc, dd
 real(c_double), pointer :: ee, ff

 ! non-descriptor arrays
 real(c_double), target :: gg(N), hh(N)

 allocate(cc, dd, ee, ff)

 aa = 11.0_c_double
 bb = 22.0_c_double
 cc = 33.0_c_double
 dd = 44.0_c_double
 ee = 55.0_c_double
 ff = 66.0_c_double
 gg = 77.0_c_double
 hh = 88.0_c_double

 call test_dummy_callee_1(aa, bb, cc, dd, ee, ff, gg, hh, N)
 deallocate(ee, ff) ! pointers, only
  end subroutine test_dummy_call_1

  subroutine test_dummy_callee_1(aa, bb, cc, dd, ee, ff, gg, hh, N)
 ! scalars
 real(c_double), target :: aa, bb
 real(c_double), target, allocatable :: cc, dd
 real(c_double), pointer :: ee, ff

 ! non-descriptor arrays
 real(c_double), target :: gg(N), hh(N)
 integer, value :: N

 !$omp target data map(to:aa) map(from:bb) use_device_addr(aa,bb)
 call copy3_scalar(c_loc(aa), c_loc(bb))
 !$omp end target data
 if (abs(aa - 11.0_c_double) > 10.0_c_double * epsilon(aa)) call abort()
 if (abs(3.0_c_double * aa - bb) > 10.0_c_double * epsilon(aa)) call abort()

 !$omp target data 

C++ PATCH for comp_ptr_ttypes_real

2019-10-10 Thread Marek Polacek
comp_ptr_ttypes_real could use bool instead of int since it only returns
0 or 1.

Bootstrapped/regtested on x86_64-linux, applying to trunk.

2019-10-10  Marek Polacek  

* typeck.c (comp_ptr_ttypes_real): Change the return type to bool.
Use false instead of 0.

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index a67dd4b155a..38664ecd177 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -52,7 +52,7 @@ static tree cp_pointer_int_sum (location_t, enum tree_code, 
tree, tree,
tsubst_flags_t);
 static tree rationalize_conditional_expr (enum tree_code, tree, 
  tsubst_flags_t);
-static int comp_ptr_ttypes_real (tree, tree, int);
+static bool comp_ptr_ttypes_real (tree, tree, int);
 static bool comp_except_types (tree, tree, bool);
 static bool comp_array_types (const_tree, const_tree, compare_bounds_t, bool);
 static tree pointer_diff (location_t, tree, tree, tree, tsubst_flags_t, tree 
*);
@@ -9903,7 +9903,7 @@ check_return_expr (tree retval, bool *no_warning)
If CONSTP is positive, then all outer pointers have been
const-qualified.  */
 
-static int
+static bool
 comp_ptr_ttypes_real (tree to, tree from, int constp)
 {
   bool to_more_cv_qualified = false;
@@ -9912,12 +9912,12 @@ comp_ptr_ttypes_real (tree to, tree from, int constp)
   for (; ; to = TREE_TYPE (to), from = TREE_TYPE (from))
 {
   if (TREE_CODE (to) != TREE_CODE (from))
-   return 0;
+   return false;
 
   if (TREE_CODE (from) == OFFSET_TYPE
  && !same_type_p (TYPE_OFFSET_BASETYPE (from),
   TYPE_OFFSET_BASETYPE (to)))
-   return 0;
+   return false;
 
   /* Const and volatile mean something different for function and
 array types, so the usual checks are not appropriate.  We'll
@@ -9925,12 +9925,12 @@ comp_ptr_ttypes_real (tree to, tree from, int constp)
   if (!FUNC_OR_METHOD_TYPE_P (to) && TREE_CODE (to) != ARRAY_TYPE)
{
  if (!at_least_as_qualified_p (to, from))
-   return 0;
+   return false;
 
  if (!at_least_as_qualified_p (from, to))
{
  if (constp == 0)
-   return 0;
+   return false;
  to_more_cv_qualified = true;
}
 
@@ -9946,7 +9946,7 @@ comp_ptr_ttypes_real (tree to, tree from, int constp)
 not match, then no conversion is possible.  */
   if (TREE_CODE (to) == ARRAY_TYPE
  && !comp_array_types (to, from, bounds_first, /*strict=*/false))
-   return 0;
+   return false;
 
   if (!TYPE_PTR_P (to)
  && !TYPE_PTRDATAMEM_P (to)


[Ada] Generation of procedures for blocks occurring in elaboration code for LLVM

2019-10-10 Thread Pierre-Marie de Rodat
For compilers such as GNAT-LLVM that requiring unnesting of subprograms
that make up-level references, the GNAT front end needs to check for
block statements occurring within elaboration of library-level packages,
and transform those into procedures that can be passed an
activation-record parameter. Some of that was already implemented, but
it was incomplete in various ways, and didn't account for nested
library-level packages (including instantiations), cases involving
blocks within loops, and blocks within top-level exception handlers,
which are now addressed.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Gary Dismukes  

gcc/ada/

* exp_ch7.adb (Check_Unnesting_Elaboration_Code): Various
cleanups.
(Set_Elab_Proc): New procedure to create the defining identifier
for a procedure created to encapsulate top-level blocks
occurring as a part of library package elaboration.
(First_Local_Scope): Function replaced by
Reset_Scopes_To_Elab_Proc.
(Reset_Scopes_To_Elab_Proc): New recursive procedure based on
First_Local_Scope, which it replaces, that is called to traverse
the statements of a library package body to locate top-level
blocks and determine whether they contain nested subprograms
that might address library-level objects of the package. Such
blocks (and loops) and certain top-level subprograms within the
statements will have their Scope reset here to match an
encapsulating procedure created by
Check_Unnesting_Elaboration_Code that will contain the
statements.
(Check_Unnesting_In_Decls_Or_Stmts): Code for handling blocks
factored out into Unnest_Block. Add handling for package
declarations and bodies, making recursive calls for
visible/private declarations, body declarations, statements, and
exception handlers. Also remove test for Is_Compilation_Unit:
caller tests for Is_Library_Level_Entity instead.  Also, this
proc's name was changed from Check_Unnesting_In_Declarations.
(Check_Unnesting_In_Handlers): New procedure to traverse a
sequence of exception handlers, calling
Check_Unnesting_In_Decls_Or_Stmts on the statements of each
handler.
(Expand_N_Package_Body): Call Check_Unnesting_* routines only
when Unnest_Subprogram_Mode is set and the current scope is a
library-level entity (which includes packages and instantiations
nested directly within a library unit).
(Expand_N_Package_Declaration): Call Check_Unnesting_* routines
only when Unnest_Subprogram_Mode is set and the current scope is
a library-level entity (which includes packages and
instantiations nested directly within a library unit).
(Unnest_Block): New procedure factored out of
Check_Unnesting_In_Decls_Or_Stmts, for creating a new procedure
to replace a block statement and resetting the Scope fields of
the block's top-level entities.--- gcc/ada/exp_ch7.adb
+++ gcc/ada/exp_ch7.adb
@@ -364,20 +364,39 @@ package body Exp_Ch7 is
 
procedure Check_Unnesting_Elaboration_Code (N : Node_Id);
--  The statement part of a package body that is a compilation unit may
-   --  contain blocks that declare local subprograms. In Subprogram_Unnesting
+   --  contain blocks that declare local subprograms. In Subprogram_Unnesting_
--  Mode such subprograms must be handled as nested inside the (implicit)
--  elaboration procedure that executes that statement part. To handle
--  properly uplevel references we construct that subprogram explicitly,
--  to contain blocks and inner subprograms, The statement part becomes
--  a call to this subprogram. This is only done if blocks are present
-   --  in the statement list of the body.
-
-   procedure Check_Unnesting_In_Declarations (Decls : List_Id);
-   --  Similarly, the declarations in the package body may have created
-   --  blocks with nested subprograms. Such a block must be transformed into a
-   --  procedure followed by a call to it, so that unnesting can handle uplevel
-   --  references within these nested subprograms (typically generated
-   --  subprograms to handle finalization actions).
+   --  in the statement list of the body. (It would be nice to unify this
+   --  procedure with Check_Unnesting_In_Decls_Or_Stmts, if possible, since
+   --  they're doing very similar work, but are structured differently. ???)
+
+   procedure Check_Unnesting_In_Decls_Or_Stmts (Decls_Or_Stmts : List_Id);
+   --  Similarly, the declarations or statements in library-level packages may
+   --  have created blocks blocks with nested subprograms. Such a block must be
+   --  transformed into a procedure followed by a call to it, so that unnesting
+   --  can handle uplevel references within these nested subprograms (typically
+   --  subprograms that handle 

[Ada] Unnesting issues with entry families and accept statements

2019-10-10 Thread Pierre-Marie de Rodat
The case of a protected entry family body with a nested subprogram
wasn't recognized for purposes of unnesting, leading to unhandled
up-level references, because Has_Nested_Subprogram was incorrectly
returning False. This was due to Set_Has_Nested_Subprogram not being
called on the procedure created for the entry body, because
Enclosing_Subprogram wasn't locating any subprogram. That function
needed to be modified to account for the E_Entry_Family case and return
the Protected_Body_Subprogram in that case (as it already did for
E_Entry).

That fix happened to expose another unnesting problem involving selected
accept alternatives containing a nested accept statement, where
references to local temporaries of the nested accept statement were
improperly treated as up-level because their Scope was pointing to the
inner accept statement's entry entity rather than the procedure
generated for the enclosing accept statement. This turned out to be
another case where Reset_Scopes_To needs to be called to reset the Scope
field of local declared entities within the block created for accept
statements.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Gary Dismukes  

gcc/ada/

* sem_util.adb (Enclosing_Subprogram): Handle the case of
E_Entry_Family, returning the entry family's associated
Protected_Body_Subprogram (as was already done for E_Entry).
* exp_ch9.adb (Expand_N_Accept_Statement): Call Reset_Scopes_To
on the block created for an accept statement to reset the scopes
of any local entities to the block scope.--- gcc/ada/exp_ch9.adb
+++ gcc/ada/exp_ch9.adb
@@ -6624,6 +6624,13 @@ package body Exp_Ch9 is
  Declarations   => Declarations (N),
  Handled_Statement_Sequence => Build_Accept_Body (N));
 
+ --  Reset the Scope of local entities associated with the accept
+ --  statement (that currently reference the entry scope) to the
+ --  block scope, to avoid having references to the locals treated
+ --  as up-level references.
+
+ Reset_Scopes_To (Block, Blkent);
+
  --  For the analysis of the generated declarations, the parent node
  --  must be properly set.
 

--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -6997,17 +6997,17 @@ package body Sem_Util is
   elsif Ekind_In (Dyn_Scop, E_Block, E_Loop, E_Return_Statement) then
  return Enclosing_Subprogram (Dyn_Scop);
 
-  elsif Ekind (Dyn_Scop) = E_Entry then
+  elsif Ekind_In (Dyn_Scop, E_Entry, E_Entry_Family) then
 
- --  For a task entry, return the enclosing subprogram of the
- --  task itself.
+ --  For a task entry or entry family, return the enclosing subprogram
+ --  of the task itself.
 
  if Ekind (Scope (Dyn_Scop)) = E_Task_Type then
 return Enclosing_Subprogram (Dyn_Scop);
 
- --  A protected entry is rewritten as a protected procedure which is
- --  the desired enclosing subprogram. This is relevant when unnesting
- --  a procedure local to an entry body.
+ --  A protected entry or entry family is rewritten as a protected
+ --  procedure which is the desired enclosing subprogram. This is
+ --  relevant when unnesting a procedure local to an entry body.
 
  else
 return Protected_Body_Subprogram (Dyn_Scop);



[Ada] Assertion_Policy (Ignore) ignores invariants

2019-10-10 Thread Pierre-Marie de Rodat
A pragma Assertion_Policy (Ignore) was ignored with respect to
invariants; invariants are checked even in the presence of this pragma.
This patch fixes that bug.

Running these commands:

  gcc -S -fverbose-asm -g ess-main.adb -gnata
  grep Invariant ess-main.s

On the following sources:

pragma Assertion_Policy (Ignore);

package Ess is
   type T is private;
   procedure P (X : T);
private

   type T is record
  A : Integer;
   end record with
  Invariant => T.A = 3;

end Ess;

pragma Assertion_Policy (Ignore);

package body Ess is
   procedure P (X : T) is
  Obj : T;
   begin
  Obj.A := 4;
   end P;
end Ess;

pragma Assertion_Policy (Ignore);

procedure Ess.Main (X : T) is
   Obj : T;
begin
   Obj.A := 4;
   P (Obj);
end Ess.Main;

Should execute silently.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Bob Duff  

gcc/ada/

* einfo.ads, einfo.adb (Invariants_Ignored): New flag on types.
This leaves just one unused flag.
* sem_prag.adb (Invariant): Set the flag if appropriate.
* exp_util.adb (Make_Invariant_Call): Check the flag.--- gcc/ada/einfo.adb
+++ gcc/ada/einfo.adb
@@ -629,8 +629,8 @@ package body Einfo is
--Is_Activation_RecordFlag305
--Needs_Activation_Record Flag306
--Is_Loop_Parameter   Flag307
+   --Invariants_Ignored  Flag308
 
-   --(unused)Flag308
--(unused)Flag309
 
--  Note: Flag310-317 are defined in atree.ads/adb, but not yet in atree.h
@@ -2077,6 +2077,12 @@ package body Einfo is
   return Node21 (Id);
end Interface_Name;
 
+   function Invariants_Ignored (Id : E) return B is
+   begin
+  pragma Assert (Is_Type (Id));
+  return Flag308 (Id);
+   end Invariants_Ignored;
+
function Is_Abstract_Subprogram (Id : E) return B is
begin
   pragma Assert (Is_Overloadable (Id));
@@ -5278,6 +5284,12 @@ package body Einfo is
   Set_Node21 (Id, V);
end Set_Interface_Name;
 
+   procedure Set_Invariants_Ignored (Id : E; V : B := True) is
+   begin
+  pragma Assert (Is_Type (Id));
+  Set_Flag308 (Id, V);
+   end Set_Invariants_Ignored;
+
procedure Set_Is_Abstract_Subprogram (Id : E; V : B := True) is
begin
   pragma Assert (Is_Overloadable (Id));
@@ -9785,6 +9797,7 @@ package body Einfo is
   W ("In_Package_Body", Flag48  (Id));
   W ("In_Private_Part", Flag45  (Id));
   W ("In_Use",  Flag8   (Id));
+  W ("Invariants_Ignored",  Flag308 (Id));
   W ("Is_Abstract_Subprogram",  Flag19  (Id));
   W ("Is_Abstract_Type",Flag146 (Id));
   W ("Is_Access_Constant",  Flag69  (Id));

--- gcc/ada/einfo.ads
+++ gcc/ada/einfo.ads
@@ -1739,7 +1739,7 @@ package Einfo is
 
 --Has_Inherited_Invariants (Flag291) [base type only]
 --   Defined in all type entities. Set on private extensions and derived
---   types which inherit at least on class-wide invariant from a parent or
+--   types which inherit at least one class-wide invariant from a parent or
 --   an interface type. The flag is also set on the full view of a private
 --   extension for completeness.
 
@@ -1841,7 +1841,7 @@ package Einfo is
 --   when the type is subject to pragma Default_Initial_Condition.
 
 --Has_Own_Invariants (Flag232) [base type only]
---   Defined in all type entities. Set on any type which defines at least
+--   Defined in all type entities. Set on any type that defines at least
 --   one invariant of its own. The flag is also set on the full view of a
 --   private type for completeness.
 
@@ -2259,6 +2259,11 @@ package Einfo is
 --   implemented by a tagged type that are not already implemented by the
 --   ancestors (Ada 2005: AI-251).
 
+--Invariants_Ignored (Flag308)
+--   Defined on all types. Indicates whether the type declaration is in
+--   a context where Assertion_Policy is Ignore, in which case no checks
+--   (static or dynamic) must be generated for objects of the type.
+
 --Invariant_Procedure (synthesized)
 --   Defined in types and subtypes. Set for private types and their full
 --   views if one or more [class-wide] invariants apply to the type, or
@@ -7272,6 +7277,7 @@ package Einfo is
function Interface_Alias (Id : E) return E;
function Interface_Name  (Id : E) return N;
function Interfaces  (Id : E) return L;
+   function Invariants_Ignored  (Id : E) return B;
function Is_Abstract_Subprogram  (Id : E) return B;
function Is_Abstract_Type(Id : E) return B;
function Is_Access_Constant  (Id : E) return B;
@@ -7973,6 +7979,7 @@ package Einfo is
procedure Set_Interface_Alias (Id : E; V : 

[Ada] Fix inlining of subprograms with deep param/result in GNATprove

2019-10-10 Thread Pierre-Marie de Rodat
In the special inlining done for GNATprove, subprograms with parameters
or result of deep type (i.e. containing an access type) should not be
inlined. This was the purpose of a previous patch. But this should not
be applied to private types whose completion has SPARK_Mode Off, as
these types are not considered as deep by GNATprove.

There is no impact on compilation, hence no test.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Yannick Moy  

gcc/ada/

* inline.adb (Can_Be_Inlined_In_GNATprove_Mode): Do not peek
under private types whose completion is SPARK_Mode Off.--- gcc/ada/inline.adb
+++ gcc/ada/inline.adb
@@ -1582,6 +1582,20 @@ package body Inline is
 
   if No (Underlying_Type (Typ)) then
  return True;
+
+  --  Do not peek under a private type if its completion has
+  --  SPARK_Mode Off. In such a case, a deep type is considered
+  --  by GNATprove to be not deep.
+
+  elsif Present (Full_View (Typ))
+and then Present (SPARK_Pragma (Full_View (Typ)))
+and then Get_SPARK_Mode_From_Annotation
+  (SPARK_Pragma (Full_View (Typ))) = Off
+  then
+ return False;
+
+  --  Otherwise peek under the private type.
+
   else
  return Is_Deep (Underlying_Type (Typ));
   end if;



[Ada] Add pragma Preelaborable_Initialization to Stream_IO.File_Type

2019-10-10 Thread Pierre-Marie de Rodat
Pragma Preelaborable_Initialization is added to type File_Type in
package Ada.Streams.Stream_IO, per the Binding Interpretation of
AI12-0102. No other source or tool changes are required.

No test needed.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Gary Dismukes  

gcc/ada/

* libgnat/a-ststio.ads (File_Type): Apply pragma
Preelaborable_Initialization to the type.--- gcc/ada/libgnat/a-ststio.ads
+++ gcc/ada/libgnat/a-ststio.ads
@@ -42,6 +42,7 @@ package Ada.Streams.Stream_IO is
type Stream_Access is access all Root_Stream_Type'Class;
 
type File_Type is limited private with Default_Initial_Condition;
+   pragma Preelaborable_Initialization (File_Type);
 
type File_Mode is (In_File, Out_File, Append_File);
 



[Ada] Handling up-level references in loops within library-level declarations

2019-10-10 Thread Pierre-Marie de Rodat
For GNAT-LLVM, we now wrap top-level loop statements in library package
declaration lists within a procedure when there are nested subprograms
within the loop that might make up-level references to entities of the
loop (or to entities of loops and blocks nested within the outer loop
for that matter).

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Gary Dismukes  

gcc/ada/

* exp_ch7.adb (Check_Unnesting_In_Decls_Or_Stmts): When
encountering a loop at the top level of a package declaration
list (that is, within the declarations of a package spec or
body) that has nested subprograms, call Unnest_Loop to create a
new library-level procedure that will contain the loop, to allow
for proper handling of up-level references from within nested
subprograms, such as to loop parameters.
(Unnest_Loop): New procedure that takes a loop statement and
creates a new procedure body to enclose the loop statement,
along with generating a call to the procedure.--- gcc/ada/exp_ch7.adb
+++ gcc/ada/exp_ch7.adb
@@ -398,6 +398,14 @@ package body Exp_Ch7 is
--  actions or secondary-stack management, in which case the nested
--  subprogram is a finalizer.
 
+   procedure Unnest_Loop (Loop_Stmt : Node_Id);
+   --  Top-level Loops that contain nested subprograms with up-level references
+   --  need to have activation records. We do this by rewriting the loop as a
+   --  procedure containing the loop, followed by a call to the procedure in
+   --  the same library-level declarative list, to replicate the semantics of
+   --  the original loop. Such loops can occur due to aggregate expansions and
+   --  other constructs.
+
procedure Check_Visibly_Controlled
  (Prim : Final_Primitives;
   Typ  : Entity_Id;
@@ -4230,6 +4238,23 @@ package body Exp_Ch7 is
 then
Unnest_Block (Decl_Or_Stmt);
 
+elsif Nkind (Decl_Or_Stmt) = N_Loop_Statement then
+   declare
+  Id : constant Entity_Id :=
+ Entity (Identifier (Decl_Or_Stmt));
+
+   begin
+  --  When a top-level loop within declarations of a library
+  --  package spec or body contains nested subprograms, we wrap
+  --  it in a procedure to handle possible up-level references
+  --  to entities associated with the loop (such as loop
+  --  parameters).
+
+  if Present (Id) and then Contains_Subprogram (Id) then
+ Unnest_Loop (Decl_Or_Stmt);
+  end if;
+   end;
+
 elsif Nkind (Decl_Or_Stmt) = N_Package_Declaration
   and then not Modify_Tree_For_C
 then
@@ -9256,6 +9281,67 @@ package body Exp_Ch7 is
   end loop;
end Unnest_Block;
 
+   -
+   -- Unnest_Loop --
+   -
+
+   procedure Unnest_Loop (Loop_Stmt : Node_Id) is
+  Loc: constant Source_Ptr := Sloc (Loop_Stmt);
+  Ent: Entity_Id;
+  Local_Body : Node_Id;
+  Local_Call : Node_Id;
+  Local_Proc : Entity_Id;
+  Local_Scop : Entity_Id;
+  Loop_Copy  : constant Node_Id :=
+ Relocate_Node (Loop_Stmt);
+   begin
+  Local_Scop := Entity (Identifier (Loop_Stmt));
+  Ent := First_Entity (Local_Scop);
+
+  Local_Proc :=
+Make_Defining_Identifier (Loc,
+  Chars => New_Internal_Name ('P'));
+
+  Local_Body :=
+Make_Subprogram_Body (Loc,
+  Specification  =>
+Make_Procedure_Specification (Loc,
+  Defining_Unit_Name => Local_Proc),
+  Declarations   => Empty_List,
+  Handled_Statement_Sequence =>
+Make_Handled_Sequence_Of_Statements (Loc,
+  Statements => New_List (Loop_Copy)));
+
+  Set_First_Real_Statement
+(Handled_Statement_Sequence (Local_Body), Loop_Copy);
+
+  Rewrite (Loop_Stmt, Local_Body);
+  Analyze (Loop_Stmt);
+
+  Set_Has_Nested_Subprogram (Local_Proc);
+
+  Local_Call :=
+Make_Procedure_Call_Statement (Loc,
+  Name => New_Occurrence_Of (Local_Proc, Loc));
+
+  Insert_After (Loop_Stmt, Local_Call);
+  Analyze (Local_Call);
+
+  --  New procedure has the same scope as the original loop, and the scope
+  --  of the loop is the new procedure.
+
+  Set_Scope (Local_Proc, Scope (Local_Scop));
+  Set_Scope (Local_Scop, Local_Proc);
+
+  --  The entity list of the new procedure is that of the loop
+
+  Set_First_Entity (Local_Proc, Ent);
+
+  --  Note that the entities associated with the loop don't need to have
+  --  their Scope fields reset, since they're still associated with the
+  --  same loop entity that now belongs to the copied loop statement.
+   end Unnest_Loop;
+

-- 

[C++ Patch] Remove RROTATE_EXPR and LROTATE_EXPR handling

2019-10-10 Thread Paolo Carlini

Hi,

while working on cp_build_binary_op I noticed that the testsuite wasn't 
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even more 
the code handling those tree codes seemed completely unused. Turned out 
that the C front-end doesn't handle those tree codes at all: I'm coming 
to the conclusion that the C++ front-end bits too are now obsolete and 
may be removed, because only the middle-end generates those codes in 
order to implement optimizations. Anything I'm missing? Any additional 
testing? Tested x86_64-linux.


Thanks, Paolo.

///

2019-10-10  Paolo Carlini  

* typeck.c (cp_build_binary_op): Do not handle RROTATE_EXPR and
LROTATE_EXPR.
* constexpr.c (cxx_eval_constant_expression): Likewise.
(potential_constant_expression_1): Likewise.
* cp-gimplify.c (cp_fold): Likewise.
* pt.c (tsubst_copy): Likewise.
Index: constexpr.c
===
--- constexpr.c (revision 276805)
+++ constexpr.c (working copy)
@@ -5115,8 +5115,6 @@ cxx_eval_constant_expression (const constexpr_ctx
 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:
@@ -7103,8 +7101,6 @@ potential_constant_expression_1 (tree t, bool want
 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:
Index: cp-gimplify.c
===
--- cp-gimplify.c   (revision 276805)
+++ cp-gimplify.c   (working copy)
@@ -2468,8 +2468,6 @@ cp_fold (tree x)
 case MAX_EXPR:
 case LSHIFT_EXPR:
 case RSHIFT_EXPR:
-case LROTATE_EXPR:
-case RROTATE_EXPR:
 case BIT_AND_EXPR:
 case BIT_IOR_EXPR:
 case BIT_XOR_EXPR:
Index: pt.c
===
--- pt.c(revision 276805)
+++ pt.c(working copy)
@@ -16308,8 +16308,6 @@ tsubst_copy (tree t, tree args, tsubst_flags_t com
 case TRUTH_OR_EXPR:
 case RSHIFT_EXPR:
 case LSHIFT_EXPR:
-case RROTATE_EXPR:
-case LROTATE_EXPR:
 case EQ_EXPR:
 case NE_EXPR:
 case MAX_EXPR:
@@ -18913,8 +18911,6 @@ tsubst_copy_and_build (tree t,
 case TRUTH_OR_EXPR:
 case RSHIFT_EXPR:
 case LSHIFT_EXPR:
-case RROTATE_EXPR:
-case LROTATE_EXPR:
 case EQ_EXPR:
 case NE_EXPR:
 case MAX_EXPR:
Index: typeck.c
===
--- typeck.c(revision 276805)
+++ typeck.c(working copy)
@@ -4896,35 +4896,6 @@ cp_build_binary_op (const op_location_t ,
}
   break;
 
-case RROTATE_EXPR:
-case LROTATE_EXPR:
-  if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
-   {
- result_type = type0;
- if (TREE_CODE (op1) == INTEGER_CST)
-   {
- if (tree_int_cst_lt (op1, integer_zero_node))
-   {
- if (complain & tf_warning)
-   warning (0, (code == LROTATE_EXPR)
- ? G_("left rotate count is negative")
- : G_("right rotate count is negative"));
-   }
- else if (compare_tree_int (op1, TYPE_PRECISION (type0)) >= 0)
-   {
- if (complain & tf_warning)
-   warning (0, (code == LROTATE_EXPR) 
-  ? G_("left rotate count >= width of type")
-  : G_("right rotate count >= width of type"));
-   }
-   }
- /* Convert the shift-count to an integer, regardless of
-size of value being shifted.  */
- if (TYPE_MAIN_VARIANT (TREE_TYPE (op1)) != integer_type_node)
-   op1 = cp_convert (integer_type_node, op1, complain);
-   }
-  break;
-
 case EQ_EXPR:
 case NE_EXPR:
   if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE)


Re: [patch][OpenMP,Fortran] Fix several OpenMP use_device_addr/map/update errors found by a length test case

2019-10-10 Thread Jakub Jelinek
On Thu, Oct 10, 2019 at 06:49:52PM +0200, Tobias Burnus wrote:
> On 10/10/19 1:55 PM, Jakub Jelinek wrote:
> > What worries me about the test is that the officially only portable way
> > to use it in a target region is is_device_ptr.
> 
> How about the attached test cases? The only difference is in "module
> target_procs".
> 
> OK now?

Ok then.  If is_device_ptr is clarified/the restriction lifted, we can
always change it.

Jakub


Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

2019-10-10 Thread Wilco Dijkstra
ping

Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration on 
practically
any target.

I'm thinking we should completely remove all trace of SLOW_BYTE_ACCESS
from GCC as it's confusing and useless.

OK for commit until we get rid of it?

ChangeLog:
2017-11-17  Wilco Dijkstra  

gcc/
* config/aarch64/aarch64.h (SLOW_BYTE_ACCESS): Set to 1.
--
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 
056110afb228fb919e837c04aa5e5552a4868ec3..d8f4d129a02fb89eb00d256aba8c4764d6026078
 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -769,14 +769,9 @@ typedef struct
if given data not on the nominal alignment.  */
 #define STRICT_ALIGNMENTTARGET_STRICT_ALIGN
 
-/* Define this macro to be non-zero if accessing less than a word of
-   memory is no faster than accessing a word of memory, i.e., if such
-   accesses require more than one instruction or if there is no
-   difference in cost.
-   Although there's no difference in instruction count or cycles,
-   in AArch64 we don't want to expand to a sub-word to a 64-bit access
-   if we don't have to, for power-saving reasons.  */
-#define SLOW_BYTE_ACCESS   0
+/* Contrary to all documentation, this enables wide bitfield accesses,
+   which results in better code when accessing multiple bitfields.  */
+#define SLOW_BYTE_ACCESS   1
 
 #define NO_FUNCTION_CSE 1


[PATCH] Fix PR c++/92024

2019-10-10 Thread Bernd Edlinger
Hi,

this fixes a crash when -Wshadow=compatible-local is
enabled in the testcase g++.dg/parse/crash68.C


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.


patch-pr92024.diff
Description: patch-pr92024.diff


[Ada] Flag Sec_Stack_Used incorrectly set by ghost code

2019-10-10 Thread Pierre-Marie de Rodat
Correct an issue where ghost code will set the flag Sec_Stack_Used even
though the code will be eliminated and result in the program not using
the secondary stack. This could confuse the binder into importing
objects from System.Secondary_Stack even though that package is not in
the program's closure.

The setting of Sec_Stack_Used has moved from Load_RTU to RTE to cover
the case that if the ignored ghost code is the first to call Load_RTU,
the flag may never be set.

The secondary stack code in the binder has also been refactored to make
its intentions clearer.

Running this command:

  gprbuild --RTS=zfp main.adb

On the following sources:

procedure Main is
   function Mk_Test return String with Ghost;
   function Mk_Test return String is ("test");
begin
   null;
end Main;

Should execute silently.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Patrick Bernardi  

gcc/ada/

* bindgen.adb (System_Secondary_Stack_Package_In_Closure):
Renamed flag System_Secondary_Stack_Used to be clearer of what
it represents.
(Gen_Adainit): Refactor secondary stack related code to make it
clearer.
* rtsfind.adb (Load_RTU): Don't set Sec_Stack_Used flag here
(RTE): Set Sec_Stack_Used if the System.Secondary_Stack is
referenced, but not if we're ignoring ghost code.--- gcc/ada/bindgen.adb
+++ gcc/ada/bindgen.adb
@@ -81,7 +81,7 @@ package body Bindgen is
--  domains just before calling the main procedure from the environment
--  task.
 
-   System_Secondary_Stack_Used : Boolean := False;
+   System_Secondary_Stack_Package_In_Closure : Boolean := False;
--  Flag indicating whether the unit System.Secondary_Stack is in the
--  closure of the partition. This is set by Resolve_Binder_Options, and
--  is used to initialize the package in cases where the run-time brings
@@ -585,29 +585,33 @@ package body Bindgen is
 WBI ("");
  end if;
 
- --  A restricted run-time may attempt to initialize the main task's
- --  secondary stack even if the stack is not used. Consequently,
- --  the binder needs to initialize Binder_Sec_Stacks_Count anytime
- --  System.Secondary_Stack is in the enclosure of the partition.
+ if System_Secondary_Stack_Package_In_Closure then
+--  System.Secondary_Stack is in the closure of the program
+--  because the program uses the secondary stack or the restricted
+--  run-time is unconditionally calling SS_Init. In both cases,
+--  SS_Init needs to know the number of secondary stacks created by
+--  the binder.
 
- if System_Secondary_Stack_Used then
 WBI ("  Binder_Sec_Stacks_Count : Natural;");
 WBI ("  pragma Import (Ada, Binder_Sec_Stacks_Count, " &
  """__gnat_binder_ss_count"");");
 WBI ("");
- end if;
 
- if Sec_Stack_Used then
-WBI ("  Default_Secondary_Stack_Size : " &
- "System.Parameters.Size_Type;");
-WBI ("  pragma Import (C, Default_Secondary_Stack_Size, " &
- """__gnat_default_ss_size"");");
+--  Import secondary stack pool variables if the secondary stack
+--  used. They are not referenced otherwise.
 
-WBI ("  Default_Sized_SS_Pool : System.Address;");
-WBI ("  pragma Import (Ada, Default_Sized_SS_Pool, " &
- """__gnat_default_ss_pool"");");
+if Sec_Stack_Used then
+   WBI ("  Default_Secondary_Stack_Size : " &
+"System.Parameters.Size_Type;");
+   WBI ("  pragma Import (C, Default_Secondary_Stack_Size, " &
+"""__gnat_default_ss_size"");");
 
-WBI ("");
+   WBI ("  Default_Sized_SS_Pool : System.Address;");
+   WBI ("  pragma Import (Ada, Default_Sized_SS_Pool, " &
+"""__gnat_default_ss_pool"");");
+
+   WBI ("");
+end if;
  end if;
 
  WBI ("   begin");
@@ -642,48 +646,49 @@ package body Bindgen is
 WBI ("  null;");
  end if;
 
- --  Generate default-sized secondary stack pool and set secondary
- --  stack globals.
-
- if Sec_Stack_Used then
+ --  Generate the default-sized secondary stack pool if the secondary
+ --  stack is used by the program.
 
---  Elaborate the body of the binder to initialize the default-
---  sized secondary stack pool.
+ if System_Secondary_Stack_Package_In_Closure then
+if Sec_Stack_Used then
+   --  Elaborate the body of the binder to initialize the default-
+   --  sized secondary stack pool.
 
-WBI ("");
-WBI ("  " & Get_Ada_Main_Name & "'Elab_Body;");
+   WBI ("");
+  

[Ada] 'others' in conditional_expressions

2019-10-10 Thread Pierre-Marie de Rodat
This patch fixes a bug in which an 'others' array aggregate in a
dependent_expression of a conditional_expression is rejected, even in
cases where 'others' is legal. See RM-4.3.3(15.1).

Running this command:

  gcc -c others_test.ads

On the following sources:

package Others_Test is

   X : String (1 .. 10) := (case True is when Boolean => (others => 'x'));

end Others_Test;

Should execute silently.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Bob Duff  

gcc/ada/

* sem_aggr.adb (Resolve_Aggregate): Add missing cases in the
Others_Allowed => True case -- N_Case_Expression_Alternative and
N_If_Expression.  Use Nkind_In.
* atree.adb, atree.ads, sinfo.adb, sinfo.ads (Nkind_In): New
16-parameter version.--- gcc/ada/atree.adb
+++ gcc/ada/atree.adb
@@ -1924,6 +1924,30 @@ package body Atree is
   V11);
end Nkind_In;
 
+   function Nkind_In
+ (N   : Node_Id;
+  V1  : Node_Kind;
+  V2  : Node_Kind;
+  V3  : Node_Kind;
+  V4  : Node_Kind;
+  V5  : Node_Kind;
+  V6  : Node_Kind;
+  V7  : Node_Kind;
+  V8  : Node_Kind;
+  V9  : Node_Kind;
+  V10 : Node_Kind;
+  V11 : Node_Kind;
+  V12 : Node_Kind;
+  V13 : Node_Kind;
+  V14 : Node_Kind;
+  V15 : Node_Kind;
+  V16 : Node_Kind) return Boolean
+   is
+   begin
+  return Nkind_In (Nkind (N), V1, V2, V3, V4, V5, V6, V7, V8, V9, V10,
+  V11, V12, V13, V14, V15, V16);
+   end Nkind_In;
+

-- No --


--- gcc/ada/atree.ads
+++ gcc/ada/atree.ads
@@ -780,6 +780,27 @@ package Atree is
   V10 : Node_Kind;
   V11 : Node_Kind) return Boolean;
 
+   --  12..15-parameter versions are not yet needed
+
+   function Nkind_In
+ (N   : Node_Id;
+  V1  : Node_Kind;
+  V2  : Node_Kind;
+  V3  : Node_Kind;
+  V4  : Node_Kind;
+  V5  : Node_Kind;
+  V6  : Node_Kind;
+  V7  : Node_Kind;
+  V8  : Node_Kind;
+  V9  : Node_Kind;
+  V10 : Node_Kind;
+  V11 : Node_Kind;
+  V12 : Node_Kind;
+  V13 : Node_Kind;
+  V14 : Node_Kind;
+  V15 : Node_Kind;
+  V16 : Node_Kind) return Boolean;
+
pragma Inline (Nkind_In);
--  Inline all above functions
 

--- gcc/ada/sem_aggr.adb
+++ gcc/ada/sem_aggr.adb
@@ -893,7 +893,6 @@ package body Sem_Aggr is
 
procedure Resolve_Aggregate (N : Node_Id; Typ : Entity_Id) is
   Loc   : constant Source_Ptr := Sloc (N);
-  Pkind : constant Node_Kind  := Nkind (Parent (N));
 
   Aggr_Subtyp : Entity_Id;
   --  The actual aggregate subtype. This is not necessarily the same as Typ
@@ -1078,16 +1077,17 @@ package body Sem_Aggr is
 --  permit it, or the aggregate type is unconstrained, an OTHERS
 --  choice is not allowed (except that it is always allowed on the
 --  right-hand side of an assignment statement; in this case the
---  constrainedness of the type doesn't matter).
+--  constrainedness of the type doesn't matter, because an array
+--  object is always constrained).
 
 --  If expansion is disabled (generic context, or semantics-only
 --  mode) actual subtypes cannot be constructed, and the type of an
 --  object may be its unconstrained nominal type. However, if the
---  context is an assignment, we assume that OTHERS is allowed,
---  because the target of the assignment will have a constrained
---  subtype when fully compiled. Ditto if the context is an
---  initialization procedure where a component may have a predicate
---  function that carries the base type.
+--  context is an assignment statement, OTHERS is allowed, because
+--  the target of the assignment will have a constrained subtype
+--  when fully compiled. Ditto if the context is an initialization
+--  procedure where a component may have a predicate function that
+--  carries the base type.
 
 --  Note that there is no node for Explicit_Actual_Parameter.
 --  To test for this context we therefore have to test for node
@@ -1101,24 +1101,26 @@ package body Sem_Aggr is
 
 Set_Etype (N, Aggr_Typ);  --  May be overridden later on
 
-if Pkind = N_Assignment_Statement
+if Nkind (Parent (N)) = N_Assignment_Statement
   or else Inside_Init_Proc
   or else (Is_Constrained (Typ)
-and then
-  (Pkind = N_Parameter_Association or else
-   Pkind = N_Function_Call or else
-   Pkind = N_Procedure_Call_Statement  or else
-   Pkind = N_Generic_Association   or else
-   Pkind = N_Formal_Object_Declaration or else
-

[Ada] T'Size in pragma Compile_Time_Error

2019-10-10 Thread Pierre-Marie de Rodat
If a pragma Compile_Time_Error contains T'Size, then T'Size can be
computed as 0 instead of the correct value, causing missing or extra
error messages. The same applies to pragma Compile_Time_Warning.  This
patch fixes that bug.

Running these commands:

  gcc -c -g -O0 -gnata fillers-neq_error.ads
  gcc -c -g -O0 -gnata fillers-neq_error-main.adb

On the following sources:

package Fillers is

   Filler_Bytes : constant Long_Long_Integer := 1024 / 8;

   type Filler_Range is new Long_Long_Integer range 0 .. Filler_Bytes - 1;

   type Integer_8 is mod 2**8 with Size => 8;

   type Filler_Type is array (Filler_Range) of Integer_8
   with Pack;

end Fillers;
package Fillers.Neq_Error is

   pragma Compile_Time_Error
 (Filler_Type'Size /= 1024, "Filler_Type'Size /= 1024");

end Fillers.Neq_Error;
with Text_IO; use Text_IO;
procedure Fillers.Neq_Error.Main is
   X : constant Integer := Filler_Type'Size;
begin
   Put_Line (X'Img);
end Fillers.Neq_Error.Main;

Should execute silently.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Bob Duff  

gcc/ada/

* sem_prag.adb (Defer_Compile_Time_Warning_Error_To_BE): In
addition to saving the pragma for further processing, copy the
pragma into the main unit if necessary.--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -32197,6 +32197,15 @@ package body Sem_Prag is
 (New_Val => CTWE_Entry'(Eloc  => Sloc (Arg1),
 Scope => Current_Scope,
 Prag  => N));
+
+  --  If the Boolean expression contains T'Size, and we're not in the main
+  --  unit being compiled, then we need to copy the pragma into the main
+  --  unit, because otherwise T'Size might never be computed, leaving it
+  --  as 0.
+
+  if not In_Extended_Main_Code_Unit (N) then
+ Insert_Library_Level_Action (New_Copy_Tree (N));
+  end if;
end Defer_Compile_Time_Warning_Error_To_BE;
 
--



[Ada] Plug minor loophole for integer named number

2019-10-10 Thread Pierre-Marie de Rodat
Analyze_Number_Declaration contains a fast track for the case where the
expression of an integer named number is a literal, but it fails to set
the Debug_Info_Needed flag on the named number.

No functional changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Eric Botcazou  

gcc/ada/

* sem_ch3.adb (Analyze_Number_Declaration): Set
Debug_Info_Needed in the case where the expression is an integer
literal.--- gcc/ada/sem_ch3.adb
+++ gcc/ada/sem_ch3.adb
@@ -3522,6 +3522,8 @@ package body Sem_Ch3 is
  Set_Etype (Id, Universal_Integer);
  Set_Ekind (Id, E_Named_Integer);
  Set_Is_Frozen (Id, True);
+
+ Set_Debug_Info_Needed (Id);
  return;
   end if;
 



Re: [PATCH] PR libstdc++/91057 set locale::id::_M_index atomically

2019-10-10 Thread Jonathan Wakely

On 09/10/19 16:59 +0100, Jonathan Wakely wrote:

If two threads see _M_index==0 concurrently they will both try to set
it, potentially storing the facet at two different indices in the array.

Either set the _M_index data member using an atomic compare-exchange
operation or while holding a mutex.

Also move the LONG_DOUBLE_COMPAT code into a separate function to remove
the visual noise it creates.

PR libstdc++/91057
* src/c++98/locale.cc (locale::id::_M_id()) [__GTHREADS]: Use atomic
compare-exchange or double-checked lock to ensure only one thread sets
the _M_index variable.
[_GLIBCXX_LONG_DOUBLE_COMPAT]: Call find_ldbl_sync_facet to detect
facets that share another facet's ID.
[_GLIBCXX_LONG_DOUBLE_COMPAT] (find_ldbl_sync_facet): New function.

Tested x86_64-linux, committed to trunk.


That patch was broken on powerpc and other targets with long double
compat symbols.

Tested powerpc64le-linux, committed to trunk.


commit 0964424db7ff62b3b1f561af60b1cc6560b4a742
Author: Jonathan Wakely 
Date:   Thu Oct 10 16:42:08 2019 +0100

PR libstdc++/91057 fix bootstrap failure on powerpc

PR libstdc++/91057
* src/c++98/locale.cc [_GLIBCXX_LONG_DOUBLE_COMPAT]
(find_ldbl_sync_facet): Fix parameter type and missing return.

diff --git a/libstdc++-v3/src/c++98/locale.cc b/libstdc++-v3/src/c++98/locale.cc
index 1d00edc6f51..74a800c9c15 100644
--- a/libstdc++-v3/src/c++98/locale.cc
+++ b/libstdc++-v3/src/c++98/locale.cc
@@ -478,7 +478,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #ifdef _GLIBCXX_LONG_DOUBLE_COMPAT
 namespace {
   inline locale::id*
-  find_ldbl_sync_facet(locale::id* __idp)
+  find_ldbl_sync_facet(const locale::id* __idp)
   {
 # define _GLIBCXX_SYNC_ID(facet, mangled) \
 if (__idp == &::mangled)		  \
@@ -494,6 +494,7 @@ namespace {
 _GLIBCXX_SYNC_ID (money_get, _ZNSt9money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE2idE);
 _GLIBCXX_SYNC_ID (money_put, _ZNSt9money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE2idE);
 # endif
+return 0;
   }
 } // namespace
 #endif


[PATCH 1/2] pretty-print: support URL escape sequences (PR 87488)

2019-10-10 Thread David Malcolm
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
describes an emerging standard for embedding URLs in escape sequences
for marking up text output.  This is supported e.g. by recent releases
of GNOME Terminal.

This patch adds support to our pretty-printing framework for emitting
URLs.

Successfully bootstrapped on x86_64-pc-linux-gnu.

Committed to trunk as r276841.

A followup patch uses this to add URLs to the pertinent documentation
for the output of -fdiagnostics-show-option.

gcc/ChangeLog:
PR 87488
* common.opt (fdiagnostics-urls=): New option.
(diagnostic-url.h): Add SourceInclude.
(diagnostic_url_rule): New enum.
* diagnostic-color.c: Include "diagnostic-url.h".
(diagnostic_urls_enabled_p): New function.
* diagnostic-url.h: New file.
* diagnostic.c: Include "diagnostic-url.h".
(diagnostic_urls_init): New function.
* diagnostic.h (diagnostic_urls_init): New decl.
* doc/invoke.texi (Diagnostic Message Formatting Options): Add
-fdiagnostics-urls to the list.
(-fdiagnostics-urls): New option.
* gcc.c (driver_handle_option): Handle OPT_fdiagnostics_urls_.
(driver::global_initializations): Call diagnostic_urls_init.
* opts-global.c (init_options_once): Likewise.
* opts.c (common_handle_option): Handle OPT_fdiagnostics_urls_.
* pretty-print.c (pretty_printer::pretty_printer): Initialize
show_urls.
(pp_begin_url): New function.
(pp_end_url): New function.
(selftest::test_urls): New selftest.
(selftest::pretty_print_c_tests): Call it.
* pretty-print.h (pretty_printer::show_urls): New field.
(pp_begin_url): New decl.
(pp_end_url): New decl.

gcc/testsuite/ChangeLog:
PR 87488
* lib/prune.exp (TEST_ALWAYS_FLAGS): Add -fdiagnostics-urls=never.
---
 gcc/common.opt  | 20 ++
 gcc/diagnostic-color.c  | 20 ++
 gcc/diagnostic-url.h| 36 +
 gcc/diagnostic.c| 13 +
 gcc/diagnostic.h|  1 +
 gcc/doc/invoke.texi | 13 +
 gcc/gcc.c   |  5 
 gcc/opts-global.c   |  1 +
 gcc/opts.c  |  4 +++
 gcc/pretty-print.c  | 65 -
 gcc/pretty-print.h  |  6 +
 gcc/testsuite/lib/prune.exp |  2 +-
 12 files changed, 184 insertions(+), 2 deletions(-)
 create mode 100644 gcc/diagnostic-url.h

diff --git a/gcc/common.opt b/gcc/common.opt
index 1b9e0f3..124e8cf 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1281,6 +1281,26 @@ Enum(diagnostic_color_rule) String(always) 
Value(DIAGNOSTICS_COLOR_YES)
 EnumValue
 Enum(diagnostic_color_rule) String(auto) Value(DIAGNOSTICS_COLOR_AUTO)
 
+fdiagnostics-urls=
+Driver Common Joined RejectNegative Var(flag_diagnostics_show_urls) 
Enum(diagnostic_url_rule) Init(DIAGNOSTICS_URL_AUTO)
+-fdiagnostics-urls=[never|always|auto] Embed URLs in diagnostics.
+
+; Required for these enum values.
+SourceInclude
+diagnostic-url.h
+
+Enum
+Name(diagnostic_url_rule) Type(int)
+
+EnumValue
+Enum(diagnostic_url_rule) String(never) Value(DIAGNOSTICS_URL_NO)
+
+EnumValue
+Enum(diagnostic_url_rule) String(always) Value(DIAGNOSTICS_URL_YES)
+
+EnumValue
+Enum(diagnostic_url_rule) String(auto) Value(DIAGNOSTICS_URL_AUTO)
+
 fdiagnostics-format=
 Common Joined RejectNegative Enum(diagnostics_output_format)
 -fdiagnostics-format=[text|json] Select output format.
diff --git a/gcc/diagnostic-color.c b/gcc/diagnostic-color.c
index 69e759f..abc919f 100644
--- a/gcc/diagnostic-color.c
+++ b/gcc/diagnostic-color.c
@@ -19,6 +19,7 @@
 #include "config.h"
 #include "system.h"
 #include "diagnostic-color.h"
+#include "diagnostic-url.h"
 
 #ifdef __MINGW32__
 #  include 
@@ -236,3 +237,22 @@ colorize_init (diagnostic_color_rule_t rule)
   gcc_unreachable ();
 }
 }
+
+/* Determine if URLs should be enabled, based on RULE.
+   This reuses the logic for colorization.  */
+
+bool
+diagnostic_urls_enabled_p (diagnostic_url_rule_t rule)
+{
+  switch (rule)
+{
+case DIAGNOSTICS_URL_NO:
+  return false;
+case DIAGNOSTICS_URL_YES:
+  return true;
+case DIAGNOSTICS_URL_AUTO:
+  return should_colorize ();
+default:
+  gcc_unreachable ();
+}
+}
diff --git a/gcc/diagnostic-url.h b/gcc/diagnostic-url.h
new file mode 100644
index 000..ce0de45
--- /dev/null
+++ b/gcc/diagnostic-url.h
@@ -0,0 +1,36 @@
+/* Copyright (C) 2019 Free Software Foundation, Inc.
+   Contributed by David Malcolm .
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the 

[PATCH 2/2] Documentation hyperlinks for [-Wname-of-option] (PR 87488)

2019-10-10 Thread David Malcolm
This patch uses the support for pretty-printing escaped URLs added in
the previous patch (PR 87488) so that in a sufficiently capable terminal
the [-Wname-of-option] emitted at the end of each diagnostic becomes a
hyperlink to the documentation for that option on the GCC website.

I've tested it with Fedora 30's GNOME Terminal (3.32.2 with VTE 0.56.3);
the option text is printed with a dotted underline, hovering shows the
URL, and on right-clicking it offers menu items to visit/copy the URL.

Successfully bootstrapped on x86_64-pc-linux-gnu.

Committed to trunk as r276843.

gcc/ChangeLog:
PR 87488
* Makefile.in (CFLAGS-opts.o): Pass in DOCUMENTATION_ROOT_URL via
-D.
* configure.ac (--with-documentation-root-url): New option.
* configure: Regenerate.
* diagnostic-format-json.cc (json_end_diagnostic): If there is an
option URL, add it as a new string field of the diagnostic option.
* diagnostic.c (diagnostic_initialize): Initialize get_option_url.
(print_option_information): If get_option_url is non-NULL, call
it, and if the result is non-NULL, potentially emit an escape
sequence to markup the option text with the resulting URL.
* diagnostic.h (diagnostic_context::get_option_url): New callback.
* doc/invoke.texi (-fdiagnostics-format=): Add "option_url" to
example of JSON output.
* opts-diagnostic.h (get_option_url): New decl.
* opts.c (get_option_url): New function.
* toplev.c (general_init): Initialize the get_option_url callback.

gcc/testsuite/ChangeLog:
PR 87488
* c-c++-common/diagnostic-format-json-2.c: Expect an "option_url"
field.
* c-c++-common/diagnostic-format-json-3.c: Likewise.
* gfortran.dg/diagnostic-format-json-2.F90: Likewise.
* gfortran.dg/diagnostic-format-json-3.F90: Likewise.
* jit.dg/test-error-array-bounds.c (create_code): Ensure that
error messages don't contain escaped URLs.
---
 gcc/Makefile.in |  2 ++
 gcc/configure.ac| 14 ++
 gcc/diagnostic-format-json.cc   | 11 +++
 gcc/diagnostic.c| 12 
 gcc/diagnostic.h|  6 ++
 gcc/doc/invoke.texi |  1 +
 gcc/opts-diagnostic.h   |  3 +++
 gcc/opts.c  | 21 +
 .../c-c++-common/diagnostic-format-json-2.c |  1 +
 .../c-c++-common/diagnostic-format-json-3.c |  1 +
 .../c-c++-common/diagnostic-format-json-4.c | 10 --
 .../gfortran.dg/diagnostic-format-json-2.F90|  1 +
 .../gfortran.dg/diagnostic-format-json-3.F90|  1 +
 gcc/testsuite/jit.dg/test-error-array-bounds.c  |  5 +++--
 gcc/toplev.c|  1 +
 15 files changed, 86 insertions(+), 4 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 59adfaa..c82858f 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2142,6 +2142,8 @@ lto-wrapper$(exeext): $(LTO_WRAPPER_OBJS) 
libcommon-target.a $(LIBDEPS)
   $(LTO_WRAPPER_OBJS) libcommon-target.a $(LIBS)
mv -f T$@ $@
 
+CFLAGS-opts.o += -DDOCUMENTATION_ROOT_URL=\"@DOCUMENTATION_ROOT_URL@\"
+
 # Files used by all variants of C or by the stand-alone pre-processor.
 
 CFLAGS-c-family/c-opts.o += @TARGET_SYSTEM_ROOT_DEFINE@
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 54a6715..62f4b26 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -960,6 +960,20 @@ AC_SUBST(CONFIGURE_SPECS)
 ACX_PKGVERSION([GCC])
 ACX_BUGURL([https://gcc.gnu.org/bugs/])
 
+# Allow overriding the default URL for documentation
+AC_ARG_WITH(documentation-root-url,
+AS_HELP_STRING([--with-documentation-root-url=URL],
+   [Root for documentation URLs]),
+[case "$withval" in
+  yes) AC_MSG_ERROR([documentation root URL not specified]) ;;
+  no)  AC_MSG_ERROR([documentation root URL not specified]) ;;
+  *)   DOCUMENTATION_ROOT_URL="$withval"
+  ;;
+ esac],
+ DOCUMENTATION_ROOT_URL="https://gcc.gnu.org/onlinedocs/gcc/;
+)
+AC_SUBST(DOCUMENTATION_ROOT_URL)
+
 # Sanity check enable_languages in case someone does not run the toplevel
 # configure # script.
 AC_ARG_ENABLE(languages,
diff --git a/gcc/diagnostic-format-json.cc b/gcc/diagnostic-format-json.cc
index 53c3b63..eb99952 100644
--- a/gcc/diagnostic-format-json.cc
+++ b/gcc/diagnostic-format-json.cc
@@ -154,6 +154,17 @@ json_end_diagnostic (diagnostic_context *context, 
diagnostic_info *diagnostic,
   free (option_text);
 }
 
+  if (context->get_option_url)
+{
+  char *option_url = context->get_option_url (context,
+ diagnostic->option_index);
+  if (option_url)
+   {
+ 

Re: [patch] disentangle range_fold_*ary_expr into various pieces

2019-10-10 Thread Aldy Hernandez
It's not that particular commit, but the previous one, but yeah, that's 
all me.


(gdb)
#4  0x0145bf44 in value_range_base::lower_bound 
(this=0x7fffc360,

pair=0) at /home/cygnus/aldyh/src/gcc/gcc/tree-vrp.c:6148
6148  return wi::to_wide (t);
(gdb)
#5  0x01ccb1d9 in range_operator::fold_range (
this=0x271edc8 , type=, lh=...,
rh=...) at /home/cygnus/aldyh/src/gcc/gcc/range-op.cc:156
156 wide_int rh_lb = rh.lower_bound (y);
(gdb)
#6  0x0144b850 in range_fold_binary_expr (vr=0x7fffc6c0,
code=PLUS_EXPR, expr_type=,
vr0_=0x7fffc480, vr1_=0x7fffc460)
at /home/cygnus/aldyh/src/gcc/gcc/tree-vrp.c:1927
1927vr1.normalize_addresses ());
(gdb) l
1922  if (range_fold_binary_symbolics_p (vr, code, expr_type, , 
))

1923return;
1924
1925  *vr = op->fold_range (expr_type,
1926vr0.normalize_addresses (),
1927vr1.normalize_addresses ());
1928}
1929
1930/* Perform a unary operation on a range.  */
1931
(gdb) print vr1.dump()
unsigned long [POLY_INT_CST [4, 4], POLY_INT_CST [4, 4]]$1 = void
(gdb)

We have a value_range_base containing a POLYT_INT_CST which we don't handle.

That's rather unfortunate.  I was hoping by this point, anything we 
couldn't handle was just an address.  The previous range-ops code was 
normalizing anything not INTEGER_CST into VARYING, which I thought was a 
rather big hammer, and was trying to avoid.


Interesting that the old VRP code also allowing the POLY_INT to pass on 
through all the way into extract_range_binary_expr, only to bail when it 
see's it's not an INTEGER_CST:


  && (TREE_CODE (max_op0) == INTEGER_CST
  || (sym_max_op0
  = get_single_symbol (max_op0, _max_op0, _op0)))
  && (TREE_CODE (max_op1) == INTEGER_CST
  || (sym_max_op1
  = get_single_symbol (max_op1, _max_op1, _op1)))

I guess we could bring out the big hammer again if normalize_addresses 
doesn't give us an INTEGER_CST.


I'll take a look at this.  Thanks for pointing it out.

Aldy

On 10/10/19 5:25 AM, Christophe Lyon wrote:



On Mon, 7 Oct 2019 at 13:53, Aldy Hernandez > wrote:



 > +bool
 > +ipa_vr::nonzero_p (tree expr_type) const
 > +{
 > +  if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p
(max, 0))
 > +    return true;
 > +
 > +  unsigned prec = TYPE_PRECISION (expr_type);
 > +  return (type == VR_RANGE
 > + && wi::eq_p (min, wi::one (prec))
 > + && wi::eq_p (max, wi::max_value (prec, TYPE_SIGN
(expr_type;
 > +}

Errr, wrong version posted.  There was a TYPE_UNSIGNED missing.

Fixed and committed.


Hi,
Since this was committed (r276654), I've noticed regressions on aarch64:
     gcc.target/aarch64/pr88838.c (test for excess errors)
     gcc.target/aarch64/stack-check-cfa-3.c (test for excess errors)
     gcc.target/aarch64/stack-check-prologue-16.c (test for excess errors)
     gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve 
  scan-assembler-times \\tabs\\tz[0-9]+\\.b, p[0-7]/m, z[0-9]+\\.b\\n 1
     gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve 
  scan-assembler-times \\tabs\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1
     gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve 
  scan-assembler-times \\tabs\\tz[0-9]+\\.h, p[0-7]/m, z[0-9]+\\.h\\n 1
     gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve 
  scan-assembler-times \\tabs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.s\\n 1
     gcc.target/aarch64/sve/abs_1.c -march=armv8.2-a+sve (test for 
excess errors)
     gcc.target/aarch64/sve/adr_1.c -march=armv8.2-a+sve (test for 
excess errors)


and many others

For instance:
compiler exited with status 1
FAIL: gcc.target/aarch64/pr88838.c (internal compiler error)
FAIL: gcc.target/aarch64/pr88838.c (test for excess errors)
Excess errors:
during GIMPLE pass: dom
/gcc/testsuite/gcc.target/aarch64/pr88838.c:5:1: internal compiler 
error: tree check: expected integer_cst, have poly_int_cst in to_wide, 
at tree.h:5795
0x5efa71 tree_check_failed(tree_node const*, char const*, int, char 
const*, ...)

         /gcc/tree.c:9926
0x749584 tree_check(tree_node const*, char const*, int, char const*, 
tree_code)

         /gcc/tree.h:3523
0x749584 wi::to_wide(tree_node const*)
         /gcc/tree.h:5795
0xf7c0c0 value_range_base::lower_bound(unsigned int) const
         /gcc/tree-vrp.c:6136
0x155d2e6 range_operator::fold_range(tree_node*, value_range_base 
const&, value_range_base const&) const

         /gcc/range-op.cc:156
0xf87597 range_fold_binary_expr(value_range_base*, tree_code, 
tree_node*, value_range_base const*, value_range_base const*)

         /gcc/tree-vrp.c:1915
0x1007962 vr_values::extract_range_from_binary_expr(value_range*, 
tree_code, tree_node*, tree_node*, tree_node*)

         /gcc/vr-values.c:808
0x1011f0c 

[Ada] Get rid of spurious error for _Tag on extension with reverse bit order

2019-10-10 Thread Pierre-Marie de Rodat
This prevents the compiler from issuing a spurious error for the _Tag
component of a tagged record extension if the parent type has a
Bit_Order clause specifying the reverse order and a component clause.
The cause is a simple off-by-one bug in the artificial component clause
synthetized for the _Tag component in these circumstances.

This also fixes a secondary issue in
Adjust_Record_For_Reverse_Bit_Order, which would issue a bogus warning
for the components of the extension inheriting a component clause,
because it would assume that their layout has already been computed,
which is wrong.

This also improves a little bit Analyze_Record_Representation_Clause by
removing a useless local variable and preventing it from laying out the
components twice in a tagged record type.

Running this command:

  gcc -c p.ads

On the following sources:

with System;

package P is

type Rec is tagged record
A : Integer;
end record;
for Rec'Bit_Order use System.High_Order_First;
for Rec use record
A at 8 range 0 .. 31;
end record;

type Derived_Type is new Rec with null record;

end P;

Should produce the following output:

  p.ads:10:22: info: reverse bit order in machine scalar of length 32
  p.ads:10:22: info: little-endian range for component "A" is 0 .. 31

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Eric Botcazou  

gcc/ada/

* sem_ch13.adb (Adjust_Record_For_Reverse_Bit_Order): Do not use
the Esize of the component to compute its layout, but only the
Component_Clause.  Do not issue a warning for the _Tag
component.  Also set the Esize of the component at the end of
the layout.
(Analyze_Record_Representation_Clause): Remove Hbit local
variable.  Lay out the Original_Record_Component only if it's
distinct from the component.
(Check_Record_Representation_Clause): Fix off-by-one bug for the
Last_Bit of the artificial clause built for the _Tag component.--- gcc/ada/sem_ch13.adb
+++ gcc/ada/sem_ch13.adb
@@ -360,11 +360,11 @@ package body Sem_Ch13 is
   Num_CC : Natural;
 
begin
-  --  Processing here used to depend on Ada version: the behavior was
-  --  changed by AI95-0133. However this AI is a Binding interpretation,
-  --  so we now implement it even in Ada 95 mode. The original behavior
-  --  from unamended Ada 95 is still available for compatibility under
-  --  debugging switch -gnatd.
+  --  The processing done here used to depend on the Ada version, but the
+  --  behavior has been changed by AI95-0133. However this AI is a Binding
+  --  Interpretation, so we now implement it even in Ada 95 mode. But the
+  --  original behavior from unamended Ada 95 is available for the sake of
+  --  compatibility under the debugging switch -gnatd.p in Ada 95 mode.
 
   if Ada_Version < Ada_2005 and then Debug_Flag_Dot_P then
  Adjust_Record_For_Reverse_Bit_Order_Ada_95 (R);
@@ -376,6 +376,11 @@ package body Sem_Ch13 is
   --  same byte offset and processing them together. Same approach is still
   --  valid in later versions including Ada 2012.
 
+  --  Note that component clauses found on record types may be inherited,
+  --  in which case the layout of the component with such a clause still
+  --  has to be done at this point. Therefore, the processing done here
+  --  must exclusively rely on the Component_Clause of the component.
+
   --  This first loop through components does two things. First it deals
   --  with the case of components with component clauses whose length is
   --  greater than the maximum machine scalar size (either accepting them
@@ -616,13 +621,19 @@ package body Sem_Ch13 is
   Comp : constant Entity_Id := Comps (C);
   CC   : constant Node_Id   := Component_Clause (Comp);
 
+  FB   : constant Uint := Static_Integer (First_Bit (CC));
   LB   : constant Uint := Static_Integer (Last_Bit (CC));
-  NFB  : constant Uint := MSS - Uint_1 - LB;
-  NLB  : constant Uint := NFB + Esize (Comp) - 1;
+  NFB  : constant Uint := MSS - 1 - LB;
+  NLB  : constant Uint := NFB + LB - FB;
   Pos  : constant Uint := Static_Integer (Position (CC));
 
begin
-  if Warn_On_Reverse_Bit_Order then
+  --  Do not warn for the artificial clause built for the tag
+  --  in Check_Record_Representation_Clause if it is inherited.
+
+  if Warn_On_Reverse_Bit_Order
+and then Chars (Comp) /= Name_uTag
+  then
  Error_Msg_Uint_1 := MSS;
  Error_Msg_N
("info: reverse bit order in machine scalar of "
@@ -642,8 +653,9 @@ package body Sem_Ch13 is
   end if;
 
   

[Ada] Spurious warning on call with out parameter in expression function

2019-10-10 Thread Pierre-Marie de Rodat
If the exprsssion in an expression function includes a function call
with an out-parameter, the corresponding assignment may be flagged as
redundant because it is analyzed twice, once in the expression function
and once in the body constructed for it.

Running this command:

  gcc -c -gnatg warn.adb

On the following sources:

package Warn is
   function T1 (Y : Integer; X : out Integer) return Boolean
with Import;
   function T2 (X : out Integer) return Boolean is (T1 (20, X));
end Warn;

Should execute silently.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-10-10  Ed Schonberg  

gcc/ada/

* sem_warn.adb (Warn_On_Useless_Assignment): Do not warn if the
second assignment is at the same source position as the first.--- gcc/ada/sem_warn.adb
+++ gcc/ada/sem_warn.adb
@@ -4546,9 +4546,15 @@ package body Sem_Warn is
   --  to capture the value. We are not going to capture any value, but
   --  the warning message depends on the same kind of conditions.
 
+  --  If the assignment appears as an out-parameter in a call within an
+  --  expression function it may be detected twice: once when expression
+  --  itself is analyzed, and once when the constructed body is analyzed.
+  --  We don't want to emit a spurious warning in this case.
+
   if Is_Assignable (Ent)
 and then not Is_Return_Object (Ent)
 and then Present (Last_Assignment (Ent))
+and then Last_Assignment (Ent) /= N
 and then not Is_Imported (Ent)
 and then not Is_Exported (Ent)
 and then Safe_To_Capture_Value (N, Ent)



[SH][committed] Fix PR 88630

2019-10-10 Thread Oleg Endo
Hi,

When we did the refactoring of SH's FPSCR handling back in GCC 5, we
missed one thing regarding ST-40, it seems.

The attached patch fixes the issue as confirmed on the real hardware. 
Also tested on sh-sim with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-
m2a/-mb,-m4/-ml,-m4/-mb}"


Committed to trunk, GCC 9, GCC 8 as r276809, r276825, r276837.

Cheers,
Oleg

gcc/ChangeLog:
PR target/88630
* config/sh/sh.h (TARGET_FPU_SH4_300): New macro.
* config/sh/sh.c (sh_option_override): Enable fsca and fsrra insns
also for TARGET_FPU_SH4_300.
(sh_emit_mode_set): Check for TARGET_FPU_SH4_300 instead of
TARGET_SH4_300.
* config/sh/sh.md (toggle_pr): Add TARGET_FPU_SH4_300 condition.
(negsf2): Expand to either negsf2_fpscr or negsf2_no_fpscr.
(*negsf2_i): Split into ...
(negsf2_fpscr, negsf2_no_fpscr): ... these new patterns.
(abssf2): Expand to either abssf2_fpsc or abssf2_no_fpsc.
(**abssf2_i): Split into ...
(abssf2_fpscr, abssf2_no_fpscr): ... these new patterns.
(negdf2): Expand to either negdf2_fpscr or negdf2_no_fpscr.
(*negdf2_i): Split into ...
(negdf2_fpscr, negdf2_no_fpscr): ... these new patterns.
(absdf2): Expand to either absdf2_fpscr or absdf2_no_fpsc.
(**abssf2_i): Split into ...
(absdf2_fpscr, absdf2_no_fpscr): ... these new patterns.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 276411)
+++ gcc/config/sh/sh.c	(working copy)
@@ -958,11 +958,13 @@
   if (flag_unsafe_math_optimizations)
 {
   /* Enable fsca insn for SH4A if not otherwise specified by the user.  */
-  if (global_options_set.x_TARGET_FSCA == 0 && TARGET_SH4A_FP)
+  if (global_options_set.x_TARGET_FSCA == 0
+	  && (TARGET_SH4A_FP || TARGET_FPU_SH4_300))
 	TARGET_FSCA = 1;
 
   /* Enable fsrra insn for SH4A if not otherwise specified by the user.  */
-  if (global_options_set.x_TARGET_FSRRA == 0 && TARGET_SH4A_FP)
+  if (global_options_set.x_TARGET_FSRRA == 0
+	  && (TARGET_SH4A_FP || TARGET_FPU_SH4_300))
 	TARGET_FSRRA = 1;
 }
 
@@ -12490,7 +12492,7 @@
 sh_emit_mode_set (int entity ATTRIBUTE_UNUSED, int mode,
 		  int prev_mode, HARD_REG_SET regs_live ATTRIBUTE_UNUSED)
 {
-  if ((TARGET_SH4A_FP || TARGET_SH4_300)
+  if ((TARGET_SH4A_FP || TARGET_FPU_SH4_300)
   && prev_mode != FP_MODE_NONE && prev_mode != mode)
 {
   emit_insn (gen_toggle_pr ());
Index: gcc/config/sh/sh.h
===
--- gcc/config/sh/sh.h	(revision 276410)
+++ gcc/config/sh/sh.h	(working copy)
@@ -69,6 +69,8 @@
FPU is disabled (which makes it compatible with SH4al-dsp).  */
 #define TARGET_SH4A_FP (TARGET_SH4A && TARGET_FPU_ANY)
 
+/* True if the FPU is a SH4-300 variant.  */
+#define TARGET_FPU_SH4_300 (TARGET_FPU_ANY && TARGET_SH4_300)
 
 /* This is not used by the SH2E calling convention  */
 #define TARGET_VARARGS_PRETEND_ARGS(FUN_DECL) \
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 276410)
+++ gcc/config/sh/sh.md	(working copy)
@@ -9163,7 +9163,7 @@
 	(xor:SI (reg:SI FPSCR_REG) (const_int FPSCR_PR)))
(set (reg:SI FPSCR_MODES_REG)
 	(unspec_volatile:SI [(const_int 0)] UNSPECV_FPSCR_MODES))]
-  "TARGET_SH4A_FP"
+  "TARGET_SH4A_FP || TARGET_FPU_SH4_300"
   "fpchg"
   [(set_attr "type" "fpscr_toggle")])
 
@@ -9391,15 +9391,31 @@
 (define_expand "negsf2"
   [(set (match_operand:SF 0 "fp_arith_reg_operand")
 	(neg:SF (match_operand:SF 1 "fp_arith_reg_operand")))]
-  "TARGET_SH2E")
+  "TARGET_FPU_ANY"
+{
+  if (TARGET_FPU_SH4_300)
+emit_insn (gen_negsf2_fpscr (operands[0], operands[1]));
+  else
+emit_insn (gen_negsf2_no_fpscr (operands[0], operands[1]));
+  DONE;
+})
 
-(define_insn "*negsf2_i"
+(define_insn "negsf2_no_fpscr"
   [(set (match_operand:SF 0 "fp_arith_reg_operand" "=f")
 	(neg:SF (match_operand:SF 1 "fp_arith_reg_operand" "0")))]
-  "TARGET_SH2E"
+  "TARGET_FPU_ANY && !TARGET_FPU_SH4_300"
   "fneg	%0"
   [(set_attr "type" "fmove")])
 
+(define_insn "negsf2_fpscr"
+  [(set (match_operand:SF 0 "fp_arith_reg_operand" "=f")
+	(neg:SF (match_operand:SF 1 "fp_arith_reg_operand" "0")))
+   (use (reg:SI FPSCR_MODES_REG))]
+  "TARGET_FPU_SH4_300"
+  "fneg	%0"
+  [(set_attr "type" "fmove")
+   (set_attr "fp_mode" "single")])
+
 (define_expand "sqrtsf2"
   [(set (match_operand:SF 0 "fp_arith_reg_operand" "")
 	(sqrt:SF (match_operand:SF 1 "fp_arith_reg_operand" "")))]
@@ -9489,15 +9505,31 @@
 (define_expand "abssf2"
   [(set (match_operand:SF 0 "fp_arith_reg_operand")
 	(abs:SF (match_operand:SF 1 "fp_arith_reg_operand")))]
-  "TARGET_SH2E")
+  "TARGET_FPU_ANY"
+{
+  if (TARGET_FPU_SH4_300)
+emit_insn (gen_abssf2_fpscr (operands[0], operands[1]));
+  else
+emit_insn (gen_abssf2_no_fpscr (operands[0], 

[PATCH, alpha]: Fix PR92022, ICE in alpha_handle_trap_shadows

2019-10-10 Thread Uros Bizjak
We have to handle (skip) DEBUG_INSN in alpha_handle_trap_shadows.

2019-10-10  Uroš Bizjak  

PR target/92022
* config/alpha/alpha.c (alpha_handle_trap_shadows): Skip DEBUG_INSN.

testsuite/ChangeLog:

2019-10-10  Uroš Bizjak  

PR target/92022
* g++.dg/pr92022.C: New test.

Bootstrapped and regression tested on alpha-linux-gnu.

Committed to mainline, will be backported to release branches.

Uros.
Index: config/alpha/alpha.c
===
--- config/alpha/alpha.c(revision 276808)
+++ config/alpha/alpha.c(working copy)
@@ -8708,6 +8708,9 @@ alpha_handle_trap_shadows (void)
case CODE_LABEL:
  goto close_shadow;
 
+   case DEBUG_INSN:
+ break;
+
default:
  gcc_unreachable ();
}
Index: testsuite/g++.dg/pr92022.C
===
--- testsuite/g++.dg/pr92022.C  (nonexistent)
+++ testsuite/g++.dg/pr92022.C  (working copy)
@@ -0,0 +1,13 @@
+// { dg-do compile { target alpha*-*-* } }
+// { dg-options "-O1 -g -fno-var-tracking -mcpu=ev4 -mieee" }
+
+struct a {
+  a(long);
+};
+long b;
+void c() {
+  a d(1);
+  double e = b;
+  for (; b;)
+d = e;
+}


Re: [patch][OpenMP,Fortran] Fix several OpenMP use_device_addr/map/update errors found by a length test case

2019-10-10 Thread Janne Blomqvist
On Thu, Oct 10, 2019 at 7:50 PM Tobias Burnus  wrote:
>
> Hi Jakub,
>
> On 10/10/19 1:55 PM, Jakub Jelinek wrote:
> > What worries me about the test is that the officially only portable way
> > to use it in a target region is is_device_ptr.
>
> How about the attached test cases? The only difference is in "module
> target_procs".

As previously mentioned, please use "stop N" instead of "call abort()".

-- 
Janne Blomqvist


Re: [PATCH][ARM] Switch to default sched pressure algorithm

2019-10-10 Thread Wilco Dijkstra
ping

   Currently the Arm backend selects the alternative sched pressure algorithm.
   The issue is that this doesn't take register pressure into account, and so
   it causes significant additional spilling on Arm where there are only 14
   allocatable registers.  SPEC2006 shows significant codesize reduction
   with the default pressure algorithm, so switch back to that.  PR77308 shows
   ~800 fewer instructions.
   
   SPECINT2006 is ~0.6% faster on Cortex-A57 together with the other DImode
   patches. Overall SPEC codesize is 1.1% smaller.
   
   Bootstrap & regress OK on arm-none-linux-gnueabihf --with-cpu=cortex-a57
   
   ChangeLog:
   2019-07-29  Wilco Dijkstra  
   
   * config/arm/arm.c (arm_option_override): Don't override sched
   pressure algorithm.
   
   --
   
   diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
   index 
81286cadf32f908e045d704128c5e06842e0cc92..628cf02f23fb29392a63d87f561c3ee2fb73a515
 100644
   --- a/gcc/config/arm/arm.c
   +++ b/gcc/config/arm/arm.c
   @@ -3575,11 +3575,6 @@ arm_option_override (void)
  if (use_neon_for_64bits == 1)
 prefer_neon_for_64bits = true;

   -  /* Use the alternative scheduling-pressure algorithm by default.  */
   -  maybe_set_param_value (PARAM_SCHED_PRESSURE_ALGORITHM, 
SCHED_PRESSURE_MODEL,
   -global_options.x_param_values,
   -global_options_set.x_param_values);
   -
  /* Look through ready list and all of queue for instructions
 relevant for L2 auto-prefetcher.  */
  int param_sched_autopref_queue_depth;


Re: [PATCH][ARM] Tweak HONOR_REG_ALLOC_ORDER

2019-10-10 Thread Wilco Dijkstra
ping

Setting HONOR_REG_ALLOC_ORDER improves codesize with -Os, however it generates
slower and larger code with -O2 and higher.  So only set it when optimizing for
size.  On Cortex-A57 this improves SPECINT2006 by 0.15% and SPECFP2006 by 0.25%
while reducing codesize.

Bootstrap OK, OK for commit?

ChangeLog:
2019-09-09  Wilco Dijkstra  

* config/arm/arm.h (HONOR_REG_ALLOC_ORDER): Set when optimizing for 
size.

--
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
8d023389eec469ad9c8a4e88edebdad5f3c23769..e3473e29fbbb964ff1136c226fbe30d35dbf7b39
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1065,9 +1065,8 @@ extern int arm_regs_in_sequence[];
 /* Use different register alloc ordering for Thumb.  */
 #define ADJUST_REG_ALLOC_ORDER arm_order_regs_for_local_alloc ()
 
-/* Tell IRA to use the order we define rather than messing it up with its
-   own cost calculations.  */
-#define HONOR_REG_ALLOC_ORDER 1
+/* Tell IRA to use the order we define when optimizing for size.  */
+#define HONOR_REG_ALLOC_ORDER optimize_size
 
 /* Interrupt functions can only use registers that have already been
saved by the prologue, even if they would normally be




Re: [PATCH][ARM] Enable arm_legitimize_address for Thumb-2

2019-10-10 Thread Wilco Dijkstra
ping

Currently arm_legitimize_address doesn't handle Thumb-2 at all, resulting in
inefficient code.  Since Thumb-2 supports similar address offsets use the Arm
legitimization code for Thumb-2 to get significant codesize and performance
gains.  SPECINT2006 shows 0.4% gain on Cortex-A57, while SPECFP improves 0.2%.

Bootstrap OK, OK for commit?

ChangeLog:
2019-09-09  Wilco Dijkstra  

* config/arm/arm.c (arm_legitimize_address): Remove Thumb-2 bailout.

--

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
a5a6a0fab1b4b7ef07931522e7d47e59842d7f27..2601708e7e0716e4668b79e015e366d2164562fd
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -8652,13 +8652,8 @@ arm_legitimize_address (rtx x, rtx orig_x, machine_mode 
mode)
 return x;
 }
 
-  if (!TARGET_ARM)
-{
-  /* TODO: legitimize_address for Thumb2.  */
-  if (TARGET_THUMB2)
-return x;
-  return thumb_legitimize_address (x, orig_x, mode);
-}
+  if (TARGET_THUMB1)
+return thumb_legitimize_address (x, orig_x, mode);
 
   if (GET_CODE (x) == PLUS)
 {



[PATCH] V5, #13 of 15: Prefixed address tests with large offsets

2019-10-10 Thread Michael Meissner
These tests go through each of the types to make sure the number of expected
prefixed instructions are generated.


With patches #1-12 installed, these tests all pass.  Can I install them into
the trunck once pages 1-11 are committed?

2019-10-03  Michael Meissner  

* gcc/testsuite/gcc.target/powerpc/prefix-large.h: New set of
tests to test prefixed addressing on 'future' system with large
numeric offsets.
* gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-df.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-di.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-qi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-sd.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-sf.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-si.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-udi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-uhi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-uqi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-usi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-v2df.c: New test.

Index: gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c  (revision 276777)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-df.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-df.c  (revision 276777)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-df.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE double
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-di.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-di.c  (revision 276777)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-di.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE long
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mpld\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c  (revision 276777)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE short
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplh[az]\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpsth\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c  (revision 276777)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE __float128
+

[PATCH] V5, #14 of 15: PC-relative tests

2019-10-10 Thread Michael Meissner
These tests add tests for PC-relative addressing with the various types.

With patches #1-12 installed, these tests all pass.  Can I install them into
the trunk once pages 1-11 are committed?

2019-10-08  Michael Meissner  

* gcc/testsuite/gcc.target/powerpc/prefix-pcrel.h: New set of
tests to test prefixed addressing on 'future' system with
PC-relative tests.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-qi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-sd.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-sf.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-si.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-udi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-uhi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-uqi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-usi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-v2df.c: New test.

Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c  (revision 276779)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for SImode.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c  (revision 276779)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for DFmode.  */
+
+#define TYPE double
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c  (revision 276779)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for DImode.  */
+
+#define TYPE long
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mpld\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c  (revision 276779)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for HImode.  */
+
+#define TYPE short
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplh[az]\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpsth\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c  (revision 276779)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for KFmode.  */
+
+#define TYPE __float128
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplxv\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstxv\M} 2 } } */
Index: 

Re: [C++ Patch] Remove RROTATE_EXPR and LROTATE_EXPR handling

2019-10-10 Thread Jakub Jelinek
On Thu, Oct 10, 2019 at 06:12:02PM +0200, Paolo Carlini wrote:
> while working on cp_build_binary_op I noticed that the testsuite wasn't
> exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even more the
> code handling those tree codes seemed completely unused. Turned out that the
> C front-end doesn't handle those tree codes at all: I'm coming to the
> conclusion that the C++ front-end bits too are now obsolete and may be
> removed, because only the middle-end generates those codes in order to
> implement optimizations. Anything I'm missing? Any additional testing?

I guess it depends on where.
fold_binary_loc certainly has code to create {L,R}ROTATE_EXPR,
just look at
unsigned foo (unsigned x)
{
  return (x << 3) + (x >> (__SIZEOF_INT__ * __CHAR_BIT__ - 3));
}

unsigned bar (unsigned x, unsigned y)
{
  return (x << y) | (x >> (__SIZEOF_INT__ * __CHAR_BIT__ - y));
}
and the *.original dump.
The cp_build_binary_op case is unlikely to ever trigger, unless we'd rerun
it on cp_folded trees.
cxx_eval_constant_expression is unlikely, because recently we've switched to
performing constexpr evaluation on pre-cp_folded bodies, not sure if we
never encounter folded trees though.
cp_fold itself depends on whether we ever reprocess the already folded
trees, I'd be afraid we could.
pt.c again unlikely, we should be cp_folding only later on.

Jakub


Re: [PATCH][wwwdocs] Purge CVS from gccmission.html

2019-10-10 Thread Gerald Pfeifer
On Thu, 10 Oct 2019, Kyrill Tkachov wrote:
>> Not sure whether this is supposed to be a living document or just a 
>> record of what the mission statement was when egcs became GCC.  The 
>> date at the top is still 1999-04-22.
> Ah, I hadn't considered that. Good thing I didn't get around to 
> committing it just yet.
> 
> Gerald, do you happen to know?

Yes, this is not really a living document, but more reference 
(though those bits generally are still revelant).

Looking at your patch, indeed CVS is something less and less
known, and CVS vs whatever else wasn't the point, so how about
if we go with your proposal and just write "[version control]", 
i.e., with the angle brackets commonly used in quotes to indicate 
when something is not verbatim, but adjusted for context?

Surely would be fine with me.

Thanks,
Gerald


Re: [PATCH] Modify simplify_truncation to handle extended CONST_INT.

2019-10-10 Thread Jim Wilson
On Thu, Oct 10, 2019 at 1:46 AM Richard Sandiford
 wrote:
> subst tries to avoid creating invalid (zero_extend:DI (const_int N)):
>
>   else if (CONST_SCALAR_INT_P (new_rtx)
>&& (GET_CODE (x) == ZERO_EXTEND
>|| GET_CODE (x) == FLOAT
>|| GET_CODE (x) == UNSIGNED_FLOAT))
>
> Does adding SIGN_EXTEND to the list fix the bug?

I missed that.  I tried that, and it does work.  This looks like a
better solution.  I'm sending a new patch.

Jim


Re: [PATCH] V5, #2 of 15: Fix prefixed instruction length for some 128-bit types

2019-10-10 Thread Segher Boessenkool
On Wed, Oct 09, 2019 at 03:56:01PM -0400, Michael Meissner wrote:
> This patch fixes the prefixed and non-prefixed instruction sizes for the
> 128-bit types that aren't loaded into 128-bit vectors (TDmode, TFmode, IFmode,
> PTImode).

> 2019-10-08  Michael Meissner  
> 
>   * config/rs6000/rs6000.md (mov_64bit_dm): Set prefixed and
>   non-prefixed length.
>   (movtd_64bit_nodm): Set prefixed and non-prefixed length.
>   (mov_ppc64): Set prefixed and non-prefixed length.

Please also note the patterns you reformatted.  (Just "Reformat." is
enough of course).

>  (define_insn_and_split "*movtd_64bit_nodm"
>[(set (match_operand:TD 0 "nonimmediate_operand" "=m,d,d,Y,r,r")
> @@ -7786,8 +7790,12 @@ (define_insn_and_split "*movtd_64bit_nod
>"#"
>"&& reload_completed"
>[(pc)]
> -{ rs6000_split_multireg_move (operands[0], operands[1]); DONE; }
> -  [(set_attr "length" "8,8,8,12,12,8")])
> +{
> +  rs6000_split_multireg_move (operands[0], operands[1]);
> +  DONE;
> +}
> +  [(set_attr "non_prefixed_length" "8")
> +   (set_attr "prefixed_length" "20")])

It used to be 8,8,8,12,12,8 before.  Was that in error?  Please explain.


Segher


Update DFP macros in float.h for C2x and TS 18661-2

2019-10-10 Thread Joseph Myers
GCC's  includes various macros for decimal floating-point
types, defined if __STDC_WANT_DEC_FP__, as defined in TR 24732.

TS 18661-2 and C2X make some changes to those macros.  In TS 18661-2,
they are to be defined if __STDC_WANT_IEC_60559_DFP_EXT__, and the
*_SUBNORMAL_MIN macros are renamed to *_TRUE_MIN.  In C2X, the macros
are to be defined whenever DFP is supported, without needing any
feature test macro to be defined.

This patch updates the header accordingly.  There is no existing
predefined macro for whether the target supports DFP; rather than
adding a new macro for that purpose, this patch changes the predefined
macros used in  so that they are only defined when DFP is
supported and thus can be used as conditionals; this is the same way
predefined macros for _FloatN and _FloatNx types work.  Although
formally TR 24732 and TS 18661-2 say nothing about implementations
lacking DFP support, it seems appropriate to avoid defining the macros
in , in the absence of DFP support, even if the respective
feature test macros are defined.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.  Also tested
the c2x-float-no-dfp-* tests for aarch64-linux-gnu to make sure they
do pass in a no-DFP configuration.  Applied to mainline.

gcc:
2019-10-10  Joseph Myers  

* ginclude/float.h [!__DEC32_MANT_DIG__]: Do not define DFP
macros.
[__STDC_WANT_IEC_60559_DFP_EXT__ || __STDC_VERSION__ > 201710L]:
Also define DFP macros for these conditions.
[!__STDC_WANT_DEC_FP__] (DEC32_SUBNORMAL_MIN, DEC64_SUBNORMAL_MIN,
DEC128_SUBNORMAL_MIN): Do not define.
[__STDC_WANT_IEC_60559_DFP_EXT__ || __STDC_VERSION__ > 201710L]
(DEC32_TRUE_MIN, DEC64_TRUE_MIN, DEC128_TRUE_MIN): New macros.

gcc/c-family:
2019-10-10  Joseph Myers  

* c-cppbuiltin.c (c_cpp_builtins): Do not define macros for DFP
types if DFP not supported.

gcc/testsuite:
2019-10-10  Joseph Myers  

* gcc.dg/c11-float-dfp-1.c, gcc.dg/c2x-float-no-dfp-1.c,
gcc.dg/c2x-float-no-dfp-2.c, gcc.dg/dfp/c2x-float-dfp-1.c,
gcc.dg/dfp/c2x-float-dfp-2.c, gcc.dg/dfp/c2x-float-dfp-3.c,
gcc.dg/dfp/tr24732-float-dfp-1.c,
gcc.dg/dfp/ts18661-2-float-dfp-1.c: New tests.

Index: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 276841)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -1151,10 +1151,16 @@ c_cpp_builtins (cpp_reader *pfile)
  csuffix, FLOATN_NX_TYPE_NODE (i));
 }
 
-  /* For decfloat.h.  */
-  builtin_define_decimal_float_constants ("DEC32", "DF", dfloat32_type_node);
-  builtin_define_decimal_float_constants ("DEC64", "DD", dfloat64_type_node);
-  builtin_define_decimal_float_constants ("DEC128", "DL", dfloat128_type_node);
+  /* For float.h.  */
+  if (targetm.decimal_float_supported_p ())
+{
+  builtin_define_decimal_float_constants ("DEC32", "DF",
+ dfloat32_type_node);
+  builtin_define_decimal_float_constants ("DEC64", "DD",
+ dfloat64_type_node);
+  builtin_define_decimal_float_constants ("DEC128", "DL",
+ dfloat128_type_node);
+}
 
   /* For fixed-point fibt, ibit, max, min, and epsilon.  */
   if (targetm.fixed_point_supported_p ())
Index: gcc/ginclude/float.h
===
--- gcc/ginclude/float.h(revision 276841)
+++ gcc/ginclude/float.h(working copy)
@@ -426,9 +426,13 @@ see the files COPYING3 and COPYING.RUNTIME respect
 
 #endif /* __STDC_WANT_IEC_60559_TYPES_EXT__.  */
 
-#ifdef __STDC_WANT_DEC_FP__
-/* Draft Technical Report 24732, extension for decimal floating-point
-   arithmetic: Characteristic of decimal floating types .  */
+#ifdef __DEC32_MANT_DIG__
+#if (defined __STDC_WANT_DEC_FP__ \
+ || defined __STDC_WANT_IEC_60559_DFP_EXT__ \
+ || (defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L))
+/* C2X; formerly Technical Report 24732, extension for decimal
+   floating-point arithmetic: Characteristic of decimal floating types
+   , and TS 18661-2.  */
 
 /* Number of base-FLT_RADIX digits in the significand, p.  */
 #undef DEC32_MANT_DIG
@@ -480,14 +484,6 @@ see the files COPYING3 and COPYING.RUNTIME respect
 #define DEC64_MIN  __DEC64_MIN__
 #define DEC128_MIN __DEC128_MIN__
 
-/* Minimum subnormal positive floating-point number. */
-#undef DEC32_SUBNORMAL_MIN
-#undef DEC64_SUBNORMAL_MIN
-#undef DEC128_SUBNORMAL_MIN
-#define DEC32_SUBNORMAL_MIN   __DEC32_SUBNORMAL_MIN__
-#define DEC64_SUBNORMAL_MIN   __DEC64_SUBNORMAL_MIN__
-#define DEC128_SUBNORMAL_MIN  __DEC128_SUBNORMAL_MIN__
-
 /* The floating-point expression evaluation method.
  -1  indeterminate
  0  evaluate all operations and constants just to the range and
@@ -502,6 +498,33 @@ 

[PATCH] PR fortran/91649 -- Add additional checking for FINDLOC

2019-10-10 Thread Steve Kargl
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?

The patch adds additional check for the ARRAY and VALUE
arguments.  First, ARRAY and VALUE need to be type
conformant, but gfortran did not check for the CHARACTER
type nor for numeric types.  Second, ARRAY must be an
intrinsic type, which implies that VALUE must also be
an intrinsic type.

2019-10-10  Steven G. Kargl  

PR fortran/91649
check.c (gfc_check_findloc): Additional checking for valid arguments

2019-10-10  Steven G. Kargl  

PR fortran/91649
* gfortran.dg/pr91649.f90

-- 
Steve
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c	(revision 276837)
+++ gcc/fortran/check.c	(working copy)
@@ -3879,26 +3921,27 @@ bool
 gfc_check_findloc (gfc_actual_arglist *ap)
 {
   gfc_expr *a, *v, *m, *d, *k, *b;
+  bool a1, v1;
 
   a = ap->expr;
   if (!intrinsic_type_check (a, 0) || !array_check (a, 0))
 return false;
 
   v = ap->next->expr;
-  if (!scalar_check (v,1))
+  if (!intrinsic_type_check (v, 1) || !scalar_check (v,1))
 return false;
 
-  /* Check if the type is compatible.  */
+  /* Check if the type are both logical.  */
+  a1 = a->ts.type == BT_LOGICAL;
+  v1 = v->ts.type == BT_LOGICAL;
+  if ((a1 && !v1) || (!a1 && v1))
+goto incompat;
 
-  if ((a->ts.type == BT_LOGICAL && v->ts.type != BT_LOGICAL)
-  || (a->ts.type != BT_LOGICAL && v->ts.type == BT_LOGICAL))
-{
-  gfc_error ("Argument %qs of %qs intrinsic at %L must be in type "
-		 "conformance to argument %qs at %L",
-		 gfc_current_intrinsic_arg[0]->name,
-		 gfc_current_intrinsic, >where,
-		 gfc_current_intrinsic_arg[1]->name, >where);
-}
+  /* Check if the type are both character.  */
+  a1 = a->ts.type == BT_CHARACTER;
+  v1 = v->ts.type == BT_CHARACTER;
+  if ((a1 && !v1) || (!a1 && v1))
+goto incompat;
 	 
   d = ap->next->next->expr;
   m = ap->next->next->next->expr;
@@ -3946,6 +3989,14 @@ gfc_check_findloc (gfc_actual_arglist *ap)
 return false;
 
   return true;
+
+incompat:
+  gfc_error ("Argument %qs of %qs intrinsic at %L must be in type "
+	 "conformance to argument %qs at %L",
+	 gfc_current_intrinsic_arg[0]->name,
+	 gfc_current_intrinsic, >where,
+	 gfc_current_intrinsic_arg[1]->name, >where);
+  return false;
 }
 
 
Index: gcc/testsuite/gfortran.dg/pr91649.f90
===
--- gcc/testsuite/gfortran.dg/pr91649.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91649.f90	(working copy)
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! PR fortran/91649
+! Code originally contributed by Gerhard Steinmetz
+subroutine p
+   logical :: back = .true.
+   integer :: x(1) = findloc([1, 2, 1], '1', back=back) ! { dg-error "must be in type conformance" }
+   print *, x
+end
+
+subroutine q
+   type t
+   end type
+   logical :: back = .false.
+   integer :: x(1) = findloc([1, 2, 1], t(), back=back) ! { dg-error "must be of intrinsic type" }
+   print *, x
+end
+
+subroutine s
+   character(4) :: c = '1234'
+   integer :: x(1) = findloc([1, 2, 1], c, back=.true.) ! { dg-error "must be in type conformance" }
+   print *, x
+end
+


Re: Type representation in CTF and DWARF

2019-10-10 Thread Indu Bhagat




On 10/09/2019 12:49 AM, Jakub Jelinek wrote:

On Wed, Oct 09, 2019 at 09:41:09AM +0200, Richard Biener wrote:

There's a mechanism to get type (and decl - I suppose CTF also
contains debug info
for function declarations not only its type?) info as part of early
debug generation.
The attached "hack" simply mangles dwarf2out to output this early info as the
only debug info (only verified on a small .c file).  We still have things like
file, line and column numbers for entities (not sure if CTF has those).

It should be possible to "hide" the hack behind a -gdwarf-like-ctf or similar.
I guess -g0.5 isn't desirable and we've taken both -g0 and -g1 already...
(and -g1 doesn't include types but just decls).

Yeah.  And if location info isn't in CTF, you can as well add an early
return in add_src_coords_attributes, like it has one for UNKNOWN_LOCATION
already.  Or if it is there, but just file/line and not column, you can use
-gno-column-info.  As has been mentioned earlier, you can use dwz utility
post-linking instead of -fdebug-types-section.

Jakub


Thanks for your pointers.

CTF does not encode location information. So, I used early exit in the
add_src_coords_attributes to avoid generation of location info (file, line,
column). To answer Richard's question, CTF does have type debug info
for function declarations and the argument types. So I think with these
changes, both CTF and DWARF generation will emit debug info for the same set of
types and decl.

Compile with -g -gdwarf-like-ctf and use dwz -o   (using
dwz compiled from the master branch) on the generated binaries:

(coreutils-0.22)
 .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf (uncompressed) 
| ratio (.ctf/(D1+D2+0.5*D4))
ls   30616   |1136   |21098   | 26240   
| 0.62
pwd  10734   |788|10433   | 13929   
| 0.83
groups 10706 |811|10249   | 13378   
| 0.80

(emacs-26.3)
 .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf (uncompressed) 
| ratio (.ctf/(D1+D2+0.5*D4))
emacs-26.3.1 674657  |6402   |   273963   |   273910
| 0.33

I chose to account for 50% of .debug_str because at this point, it will be
unfair to not account for them. Actually, one could even argue that upto 70%
of the .debug_str are names of entities. CTF section sizes do include the CTF
string tables.

Across coreutils, I see a geomean of 0.73 (ratio of
.ctf/(.debug_info + .debug_abbrev + 50% of .debug_str)). So, with the
"-gdwarf-like-ctf code stubs" and dwz, DWARF continues to have a larger
footprint than CTF (with 50% of .debug_str accounted for).

Indu



Re: C++ PATCH to merge concepts-cxx2a branch

2019-10-10 Thread Jason Merrill
On Thu, Oct 10, 2019 at 3:55 PM Christophe Lyon 
wrote:

> On Thu, 10 Oct 2019 at 01:44, Romain Geissler 
> wrote:
>
>> Le mer. 9 oct. 2019 à 19:20, Jason Merrill  a écrit :
>> >
>> > Andrew has done a lot of work to update the GCC implementation of C++
>> > concepts to conform to the upcoming C++20 standard, which clarifies,
>> > removes, and changes various aspects of the earlier concepts TS.  It can
>> > still use some polishing, but other stage 1 projects are waiting for it
>> > to land on trunk and it's already a big improvement from what's
>> > currently there, so I'm going to go ahead and merge it now.
>> >
>> > Tested x86_64-pc-linux-gnu, applying to trunk.
>>
>> Hi Jason,
>>
>> This is a very good news to see preliminary concept support being
>> merged in the trunk :)
>>
>> However for me, this caused the following bootstrap failure:
>>
>> In file included from /workdir/src/gcc-10.0.0/gcc/cp/cp-lang.c:24:
>> /workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h: In function 'tree_node*
>> template_info_decl_check(const_tree, const char*, int, const char*)':
>> /workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h:3368:3: error:
>> 'tree_check_failed' was not declared in this scope
>>tree_check_failed (t, f, l, fn,
>>^
>> /workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h:3368:3: note: suggested
>> alternative: 'vec_check_alloc'
>>tree_check_failed (t, f, l, fn,
>>^
>>vec_check_alloc
>> make[2]: *** [Makefile:1118: cp/cp-lang.o] Error 1
>>
>>
> On arm, this is causing:
>  FAIL: g++.dg/ext/arm-fp16/arm-fp16-ops-1.C  -std=gnu++2a (test for excess
> errors)
> Excess errors:
> /gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops.h:31:10: warning: '++'
> expression of 'volatile'-qualified type is deprecated [-Wvolatile]
>

These would be due to

2019-08-28  Marek Polacek  

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

and not the concepts merge.  You probably want to turn off -Wvolatile for
affected tests.

 and also:

> FAIL: g++.dg/cpp2a/constexpr-dtor3.C  -std=c++2a (test for excess errors)
> Excess errors:
> /gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:152:12:   in 'constexpr'
> expansion of '(& w13)->W7::~W7()'
>

This also seems unrelated, but I'll take a look.

Jason


Re: [PATCH] V5, #1 of 15: Support 34-bit offsets for prefixed instructions

2019-10-10 Thread Segher Boessenkool
On Wed, Oct 09, 2019 at 03:52:54PM -0400, Michael Meissner wrote:
> This patch adds support in the various functions that check memory offsets for
> the 34-bit offset with prefixed instructions on the 'future' machine.

> 2019-10-08  Michael Meissner  
> 
>   * config/rs6000/rs6000.c (quad_address_p): Add check for prefixed
>   addresses.
>   (mem_operand_gpr): Add check for prefixed addresses.
>   (mem_operand_ds_form): Add check for prefixed addresses.
>   (rs6000_legitimate_offset_address_p): If we support prefixed
>   addresses, check for a 34-bit offset instead of 16-bit.
>   (rs6000_legitimate_address_p): Add check for prefixed addresses.
>   Do not allow load/store with update if the address is prefixed.
>   (rs6000_mode_dependent_address):  If we support prefixed
>   addresses, check for a 34-bit offset instead of 16-bit.

s/  If/ If/

Okay for trunk.  Thanks!


Segher


[PATCH, v2] Extend subst to simplify CONST_INT inside SIGN_EXTEND.

2019-10-10 Thread Jim Wilson
This addresses PR 91860 which has four testcases triggering internal errors.
The problem here is that in combine when handling debug insns, we are trying
to substitute
(sign_extend:DI (const_int 8160 [0x1fe0]))
as the value for
(reg:DI 78 [ _9 ])
in the debug insn
(debug_insn 29 28 30 2 (var_location:QI d (subreg:QI (reg:DI 78 [ _9 ]) 0)) 
"tmp4.c":11:5 -1
 (nil))
This eventually triggers an abort because 8160 is not a sign-extended
QImode value.

We should avoid creating the invalid RTL in the first place.  In subst there
is already code to avoid putting a CONST_INT inside a ZERO_EXTEND.  This
needs to be extended to also handle a SIGN_EXTEND the same way.

This was tested with rv32/newlib and rv64/linux cross builds and make checks.
There were no regressions.  The new tests all fail for rv64 without the patch,
and work with the patch.

OK?

Jim

gcc/
PR rtl-optimization/91860
* combine.c (subst): If new_rtx is a constant, also check for
SIGN_EXTEND when deciding whether to call simplify_unary_operation.

gcc/testsuite/
PR rtl-optimization/91860
* gcc.dg/pr91860-1.c: New testcase.
* gcc.dg/pr91860-2.c: New testcase.
* gcc.dg/pr91860-3.c: New testcase.
* gcc.dg/pr91860-4.c: New testcase.
---
 gcc/combine.c|  1 +
 gcc/testsuite/gcc.dg/pr91860-1.c | 18 ++
 gcc/testsuite/gcc.dg/pr91860-2.c | 13 +
 gcc/testsuite/gcc.dg/pr91860-3.c | 15 +++
 gcc/testsuite/gcc.dg/pr91860-4.c | 24 
 5 files changed, 71 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr91860-1.c
 create mode 100644 gcc/testsuite/gcc.dg/pr91860-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr91860-3.c
 create mode 100644 gcc/testsuite/gcc.dg/pr91860-4.c

diff --git a/gcc/combine.c b/gcc/combine.c
index d295a81abf9..92e4e5e6898 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5680,6 +5680,7 @@ subst (rtx x, rtx from, rtx to, int in_dest, int in_cond, 
int unique_copy)
}
  else if (CONST_SCALAR_INT_P (new_rtx)
   && (GET_CODE (x) == ZERO_EXTEND
+  || GET_CODE (x) == SIGN_EXTEND
   || GET_CODE (x) == FLOAT
   || GET_CODE (x) == UNSIGNED_FLOAT))
{
diff --git a/gcc/testsuite/gcc.dg/pr91860-1.c b/gcc/testsuite/gcc.dg/pr91860-1.c
new file mode 100644
index 000..e715040e33d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91860-1.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -fipa-cp -g --param=max-combine-insns=3" } */
+
+char a;
+int b;
+
+static void
+bar (short d)
+{
+  d <<= __builtin_sub_overflow (0, d, );
+  b = __builtin_bswap16 (~d);
+}
+
+void
+foo (void)
+{
+  bar (21043);
+}
diff --git a/gcc/testsuite/gcc.dg/pr91860-2.c b/gcc/testsuite/gcc.dg/pr91860-2.c
new file mode 100644
index 000..7b44e648ca6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91860-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -fexpensive-optimizations -fno-tree-fre -g 
--param=max-combine-insns=4" } */
+
+unsigned a, b, c;
+void
+foo (void)
+{
+  unsigned short e;
+  __builtin_mul_overflow (0, b, );
+  __builtin_sub_overflow (59347, 9, );
+  e <<= a & 5;
+  c = e;
+}
diff --git a/gcc/testsuite/gcc.dg/pr91860-3.c b/gcc/testsuite/gcc.dg/pr91860-3.c
new file mode 100644
index 000..2b488cc9048
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91860-3.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -g2 --param=max-combine-insns=3" } */
+
+int a, b;
+
+void
+foo (void)
+{
+  unsigned short d = 46067;
+  int e = e;
+  d <<= __builtin_mul_overflow (~0, e, );
+  d |= -68719476735;
+  b = d;
+}
+
diff --git a/gcc/testsuite/gcc.dg/pr91860-4.c b/gcc/testsuite/gcc.dg/pr91860-4.c
new file mode 100644
index 000..36f2bd55c64
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91860-4.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
+/* { dg-options "-O2 -g" } */
+
+typedef unsigned char u8;
+typedef unsigned int u32;
+typedef unsigned __int128 u128;
+
+u32 b, c;
+
+static inline
+u128 bar (u8 d, u128 e)
+{
+  __builtin_memset (11 + (char *) , b, 1);
+  d <<= e & 7;
+  d = d | d > 0;
+  return d + e;
+}
+
+void
+foo (void)
+{
+  c = bar (~0, 5);
+}
-- 
2.17.1



Re: [PATCH][ARM] Tweak HONOR_REG_ALLOC_ORDER

2019-10-10 Thread Ramana Radhakrishnan
On Mon, Sep 9, 2019 at 6:05 PM Wilco Dijkstra  wrote:
>
> Setting HONOR_REG_ALLOC_ORDER improves codesize with -Os, however it generates
> slower and larger code with -O2 and higher.  So only set it when optimizing 
> for
> size.  On Cortex-A57 this improves SPECINT2006 by 0.15% and SPECFP2006 by 
> 0.25%
> while reducing codesize.
>
> Bootstrap OK, OK for commit?
>
> ChangeLog:
> 2019-09-09  Wilco Dijkstra  
>
> * config/arm/arm.h (HONOR_REG_ALLOC_ORDER): Set when optimizing for 
> size.
>
> --
> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> index 
> 8d023389eec469ad9c8a4e88edebdad5f3c23769..e3473e29fbbb964ff1136c226fbe30d35dbf7b39
>  100644
> --- a/gcc/config/arm/arm.h
> +++ b/gcc/config/arm/arm.h
> @@ -1065,9 +1065,8 @@ extern int arm_regs_in_sequence[];
>  /* Use different register alloc ordering for Thumb.  */
>  #define ADJUST_REG_ALLOC_ORDER arm_order_regs_for_local_alloc ()
>
> -/* Tell IRA to use the order we define rather than messing it up with its
> -   own cost calculations.  */
> -#define HONOR_REG_ALLOC_ORDER 1
> +/* Tell IRA to use the order we define when optimizing for size.  */
> +#define HONOR_REG_ALLOC_ORDER optimize_size

My only question would be whether it's more suitable to use
optimize_function_for_size_p(cfun) instead as IIRC that gives us a
chance with lto rather than the global optimize_size.

Otherwise ok .

regards
Ramana


>
>  /* Interrupt functions can only use registers that have already been
> saved by the prologue, even if they would normally be


Re: [Patch 2/2][Arm] Implement TARGET_HOOK_SANITIZE_CLONE_ATTRIBUTES to remove cmse_nonsecure_entry

2019-10-10 Thread Ramana Radhakrishnan
On Tue, Oct 8, 2019 at 4:21 PM Andre Vieira (lists)
 wrote:
>
> Hi,
>
> This patch implements the TARGET_HOOK_SANITIZE_CLONE_ATTRIBUTES for the
> arm backend to remove the 'cmse_nonsecure_entry' attribute from cmse.
>
> Bootstrapped the series on x86_64 and built arm-none-eabi, running the
> cmse testsuite for armv8-m.main and armv8-m.base.
>
> Is this OK for trunk?

Ok if the common bit is approved.  And do watch out for any testsuite
multilib fallout.

Ramana
>
> Cheers,
> Andre
>
> gcc/ChangeLog:
>
> 2019-10-08  Andre Vieira  
>
>  * config/arm/arm.c (TARGET_SANITIZE_CLONE_ATTRIBUTES): Define.
>  (arm_sanitize_clone_attributes): New.
>
> gcc/testsuite/ChangeLog:
> 2019-10-08  Andre Vieira  
>
>  * gcc.target/arm/cmse/ipa-clone.c: New test.


[wwwdocs] Update C++ status

2019-10-10 Thread Marek Polacek
Applied to git.

commit 0c282ad0b1233276cebe081a75bd6dc5ca85593d
Author: Marek Polacek 
Date:   Thu Oct 10 17:45:46 2019 -0400

Update C++ status (DRs 330, 1307, 1601 done).

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 6b85892a..31d54871 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -68,17 +68,23 @@ a work-in-progress.
 P1091R3, Extending structured bindings
 P1143R2, Adding the constinit keyword
 P1152R4, Deprecating volatile
+P0388R4, Permit conversions to arrays of unknown bound
+P0784R7, constexpr new
 
   
   Several C++ Defect Reports have been resolved, e.g.:
   
-DR 1560 (lvalue-to-rvalue conversion in ?:),
-DR 1813 (__is_standard_layout for a class with repeated
-   bases),
-DR 2094 (volatile scalars are trivially copyable),
-DR 2096 (constraints on literal unions),
-DR 2413 (typename in 
conversion-function-ids),
-DR 2352 (Similar types and reference binding).
+DR 1560, lvalue-to-rvalue conversion in ?:
+DR 1813, __is_standard_layout for a class with repeated
+   bases
+DR 2094, volatile scalars are trivially copyable,
+DR 2096, constraints on literal unions
+DR 2413, typename in 
conversion-function-ids
+DR 2352, Similar types and reference binding
+DR 1601, Promotion of enumeration with fixed underlying type
+DR 330, Qualification conversions and pointers to arrays of 
pointers
+DR 1307, Overload resolution based on size of array
+   initializer-list
 
   
   
diff --git a/htdocs/projects/cxx-dr-status.html 
b/htdocs/projects/cxx-dr-status.html
index 55e3ae4f..3775cab4 100644
--- a/htdocs/projects/cxx-dr-status.html
+++ b/htdocs/projects/cxx-dr-status.html
@@ -2332,7 +2332,7 @@
   http://wg21.link/cwg330;>330
   CD4
   Qualification conversions and pointers to arrays of pointers
-  No
+  10
   https://gcc.gnu.org/PR88128;>PR88128
 
 
@@ -9173,7 +9173,7 @@
   http://wg21.link/cwg1307;>1307
   C++14
   Overload resolution based on size of array 
initializer-list
-  ?
+  10
   https://gcc.gnu.org/PR69531;>PR69531
 
 
@@ -11235,7 +11235,7 @@
   http://wg21.link/cwg1601;>1601
   C++14
   Promotion of enumeration with fixed underlying type
-  No
+  10
   https://gcc.gnu.org/PR92032;>PR92032
 
 
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 2b4c0f3b..a17f9b95 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -324,7 +324,7 @@
 
 
   http://wg21.link/p0784r7;>P0784R7
-  No (https://gcc.gnu.org/PR91369;>PR91369)
+  10

 
 
@@ -416,7 +416,7 @@
 
   Permit conversions to arrays of unknown bound
   http://wg21.link/p0388r4;>P0388R4
-  No (https://gcc.gnu.org/PR91364;>PR91364)
+  10
   
 
 


Re: [PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

2019-10-10 Thread Segher Boessenkool
On Wed, Oct 09, 2019 at 07:40:23PM -0400, Michael Meissner wrote:
> On Wed, Oct 09, 2019 at 04:56:48PM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 04, 2019 at 08:29:11AM -0400, Michael Meissner wrote:
> > > @@ -8651,6 +8675,11 @@ rs6000_legitimate_address_p (machine_mod
> > >&& mode_supports_pre_incdec_p (mode)
> > >&& legitimate_indirect_address_p (XEXP (x, 0), reg_ok_strict))
> > >  return 1;
> > > +
> > > +  /* Handle prefixed addresses (PC-relative or 34-bit offset).  */
> > > +  if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
> > > +return 1;
> > 
> > Is this correct?  Are addresses with a larger offset always legitimate?
> > I don't see why that would be the case.

> The function address_to_insn_form, which is called by address_is_prefixed,
> checks if the offset is 34-bits or less

Ah, right.

And "address_is_prefixed" is a long enough name, 
"address_is_a_valid_prefixed_address"
isn't better ;-)


Segher


Re: [PATCH][ARM] Enable arm_legitimize_address for Thumb-2

2019-10-10 Thread Ramana Radhakrishnan
On Mon, Sep 9, 2019 at 6:03 PM Wilco Dijkstra  wrote:
>
> Currently arm_legitimize_address doesn't handle Thumb-2 at all, resulting in
> inefficient code.  Since Thumb-2 supports similar address offsets use the Arm
> legitimization code for Thumb-2 to get significant codesize and performance
> gains.  SPECINT2006 shows 0.4% gain on Cortex-A57, while SPECFP improves 0.2%.
>
What were the sort of code size gains  ? It did end up piquing my
curiosity as to how we missed something so basic.  For instance ldr
r0, [r0, #-4080] is valid in Arm state but not in Thumb2. Thus if
there was an illegitimate address given here, would we end up
producing plus (r0, -4080) ? Yeah a simple testcase doesn't work out.
Scratching my head a bit , it's late at night.

Orthogonally it looks like you can clean up the MINUS handling here
and in legitimate_address_p , I'm not sure what the status of LRA with
MINUS is either and thus we should now look to clean this up or look
to turn this on and see what happens. However that's a subject of a
future patch.

> Bootstrap OK, OK for commit?
>

For the record, bootstrap with Thumb2  presumably and the testruns were clean ?

regards
Ramana



Ramana


> ChangeLog:
> 2019-09-09  Wilco Dijkstra  
>
> * config/arm/arm.c (arm_legitimize_address): Remove Thumb-2 bailout.
>
> --
>
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 
> a5a6a0fab1b4b7ef07931522e7d47e59842d7f27..2601708e7e0716e4668b79e015e366d2164562fd
>  100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -8652,13 +8652,8 @@ arm_legitimize_address (rtx x, rtx orig_x, 
> machine_mode mode)
> return x;
>  }
>
> -  if (!TARGET_ARM)
> -{
> -  /* TODO: legitimize_address for Thumb2.  */
> -  if (TARGET_THUMB2)
> -return x;
> -  return thumb_legitimize_address (x, orig_x, mode);
> -}
> +  if (TARGET_THUMB1)
> +return thumb_legitimize_address (x, orig_x, mode);
>
>if (GET_CODE (x) == PLUS)
>  {


Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

2019-10-10 Thread Ramana Radhakrishnan
On Thu, Oct 10, 2019 at 7:06 PM Richard Sandiford
 wrote:
>
> Wilco Dijkstra  writes:
> > ping
> >
> > Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> > bitfields by their declared type, which results in better codegeneration on 
> > practically
> > any target.
>
> The name is confusing, but the documentation looks accurate to me:
>
> Define this macro as a C expression which is nonzero if accessing less
> than a word of memory (i.e.@: a @code{char} or a @code{short}) is no
> faster than accessing a word of memory, i.e., if such access
> require more than one instruction or if there is no difference in cost
> between byte and (aligned) word loads.
>
> When this macro is not defined, the compiler will access a field by
> finding the smallest containing object; when it is defined, a fullword
> load will be used if alignment permits.  Unless bytes accesses are
> faster than word accesses, using word accesses is preferable since it
> may eliminate subsequent memory access if subsequent accesses occur to
> other fields in the same word of the structure, but to different bytes.
>
> > I'm thinking we should completely remove all trace of SLOW_BYTE_ACCESS
> > from GCC as it's confusing and useless.
>
> I disagree.  Some targets can optimise single-bit operations when the
> container is a byte, for example.
>
> > OK for commit until we get rid of it?
> >
> > ChangeLog:
> > 2017-11-17  Wilco Dijkstra  
> >
> > gcc/
> > * config/aarch64/aarch64.h (SLOW_BYTE_ACCESS): Set to 1.
> > --
> > diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
> > index 
> > 056110afb228fb919e837c04aa5e5552a4868ec3..d8f4d129a02fb89eb00d256aba8c4764d6026078
> >  100644
> > --- a/gcc/config/aarch64/aarch64.h
> > +++ b/gcc/config/aarch64/aarch64.h
> > @@ -769,14 +769,9 @@ typedef struct
> > if given data not on the nominal alignment.  */
> >  #define STRICT_ALIGNMENTTARGET_STRICT_ALIGN
> >
> > -/* Define this macro to be non-zero if accessing less than a word of
> > -   memory is no faster than accessing a word of memory, i.e., if such
> > -   accesses require more than one instruction or if there is no
> > -   difference in cost.
> > -   Although there's no difference in instruction count or cycles,
> > -   in AArch64 we don't want to expand to a sub-word to a 64-bit access
> > -   if we don't have to, for power-saving reasons.  */
> > -#define SLOW_BYTE_ACCESS   0
> > +/* Contrary to all documentation, this enables wide bitfield accesses,
> > +   which results in better code when accessing multiple bitfields.  */
> > +#define SLOW_BYTE_ACCESS   1
> >
> >  #define NO_FUNCTION_CSE 1
>
> I agree this makes sense from a performance point of view, and I think
> the existing comment is admitting that AArch64 has the properties that
> would normally cause us to set SLOW_BYTE_ACCESS to 1.  But the comment
> is claiming that there's a power-saving benefit to leaving it off.
>
> It seems like a weak argument though.  Bitfields are used when several
> values are packed into the same integer, so there's a high likelihood
> we'll need the whole integer anyway.  Avoiding the redundancies described
> in the documention should if anything help with power usage.
>
> Maybe the main concern was using a 64-bit access when a 32-bit one
> would do, since 32-bit bitfield containers are the most common.  But the:
>
>  && GET_MODE_ALIGNMENT (mode) <= align
>
> condition in get_best_mode should avoid that unless the 64-bit
> access is naturally aligned.  (See the big comment above for the
> pros and cons of this.)
>
> So I think we should change the macro value unless anyone can back up the
> power-saving claim.  Let's wait a week (more) to see if anyone objects.

IIRC, that power saving comment comes from the original port and
probably from when
the port was first written which is probably more than 10 years now.

regards
Ramana

Ramana

>
> The comment change isn't OK though.  Please keep the first paragraph
> and just reword the second to say that's why we set the value to 1.
>
> Thanks,
> Richard


C++ PATCH for c++/92049 - extra error with -fchecking=2

2019-10-10 Thread Marek Polacek
The concepts merge brought this bit

@@ -26326,9 +26559,9 @@ build_non_dependent_expr (tree expr)
 unexpected recursive instantiations.  */
   && !parsing_nsdmi ()
   /* Don't do this during concept expansion either and for
- the same reason.  */
-  && !expanding_concept ())
-fold_non_dependent_expr (expr, tf_none);
+the same reason.  */
+  && !parsing_constraint_expression_p ())
+fold_non_dependent_expr (expr);

   STRIP_ANY_LOCATION_WRAPPER (expr);

(which I'm not finding in the ChangeLog).  Dropping tf_none means that
fold_non_dependent_expr will use tf_warning_or_error by default, and in
this test that causes an error:

  template struct cond;

  template struct S { 
void f(int i) {
  cond<__builtin_constant_p(i)>();
}
  };

  S<1> s;

where it complains that cond is incomplete.  Which it is, but we're not
actually instantiating the function f, so we need not issue an error.  It's
broken a bunch of tests if --enable-checking=extra is in effect.  This patch
brings that tf_none back.  We will still complain if we do instantiate f.

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

2019-10-10  Marek Polacek  

PR c++/92049 - extra error with -fchecking=2.
* pt.c (build_non_dependent_expr): Call fold_non_dependent_expr
with tf_none.

* g++.dg/template/builtin2.C: New test.

diff --git gcc/cp/pt.c gcc/cp/pt.c
index 84464436991..12bab062e61 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -27063,7 +27063,7 @@ build_non_dependent_expr (tree expr)
   /* Don't do this during concept processing either and for
  the same reason.  */
   && !processing_constraint_expression_p ())
-fold_non_dependent_expr (expr);
+fold_non_dependent_expr (expr, tf_none);
 
   STRIP_ANY_LOCATION_WRAPPER (expr);
 
diff --git gcc/testsuite/g++.dg/template/builtin2.C 
gcc/testsuite/g++.dg/template/builtin2.C
new file mode 100644
index 000..d4d9d2ef3a4
--- /dev/null
+++ gcc/testsuite/g++.dg/template/builtin2.C
@@ -0,0 +1,5 @@
+// PR c++/92049 - extra error with -fchecking=2.
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-fchecking=2" }
+
+#include "builtin1.C"


Ping: [C][C++] Avoid exposing internal details in aka types

2019-10-10 Thread Richard Sandiford
Ping

Richard Sandiford  writes:
> The current aka diagnostics can sometimes leak internal details that
> seem more likely to be distracting than useful.  E.g. on aarch64:
>
>   void f (va_list *va) { *va = 1; }
>
> gives:
>
>   incompatible types when assigning to type ‘va_list’ {aka ‘__va_list’} from 
> type ‘int’
>
> where __va_list isn't something the user is expected to know about.
> A similar thing happens for C++ on the arm_neon.h-based:
>
>   float x;
>   int8x8_t y = x;
>
> which gives:
>
>   cannot convert ‘float’ to ‘int8x8_t’ {aka ‘__Int8x8_t’} in initialization
>
> This is accurate -- and __Int8x8_t is defined by the AArch64 PCS --
> but it's not going to be meaningful to most users.
>
> This patch stops the aka code looking through typedefs if all of
> the following are true:
>
> (1) the typedef is built into the compiler or comes from a system header
>
> (2) the target of the typedef is anonymous or has a name in the
> implementation namespace
>
> (3) the target type is a tag type or vector type, which have in common that:
> (a) we print their type names if they have one
> (b) what we print for anonymous types isn't all that useful
> ("struct " etc. for tag types, pseudo-C "__vector(N) T"
> for vector types)
>
> The C side does this by recursively looking for the aka type, like the
> C++ side already does.  This in turn makes "aka" work for distinct type
> copies like __Int8x8_t on aarch64, fixing the ??? in aarch64/diag_aka_1.c.
>
> On the C++ side, strip_typedefs had:
>
> /* Explicitly get the underlying type, as TYPE_MAIN_VARIANT doesn't
>strip typedefs with attributes.  */
> result = TYPE_MAIN_VARIANT (DECL_ORIGINAL_TYPE (TYPE_NAME (t)));
> result = strip_typedefs (result);
>
> Applying TYPE_MAIN_VARIANT predates the strip_typedefs call, with the
> comment originally contrasting with plain:
>
> result = TYPE_MAIN_VARIANT (t);
>
> But the recursive call to strip_typedefs will apply TYPE_MAIN_VARIANT,
> so it doesn't seem necessary to do it here too.  I think there was also
> a missing "remove_attributes" argument, since wrapping something in a
> typedef shouldn't change which attributes get removed.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
>
> Richard

2019-09-30  Richard Sandiford  

gcc/c-family/
* c-common.h (user_facing_original_type_p): Declare.
* c-common.c (user_facing_original_type_p): New function.

gcc/c/
* c-objc-common.c (useful_aka_type_p): Replace with...
(get_aka_type): ...this new function.  Given the original type,
decide which aka type to print (if any).  Only look through typedefs
if user_facing_original_type_p.
(print_type): Update accordingly.

gcc/cp/
* cp-tree.h (STF_USER_VISIBLE): New constant.
(strip_typedefs, strip_typedefs_expr): Take a flags argument.
* tree.c (strip_typedefs, strip_typedefs_expr): Likewise,
updating mutual calls accordingly.  When STF_USER_VISIBLE is true,
only look through typedefs if user_facing_original_type_p.
* error.c (dump_template_bindings, type_to_string): Pass
STF_USER_VISIBLE to strip_typedefs.
(dump_type): Likewise, unless pp_c_flag_gnu_v3 is set.

gcc/testsuite/
* g++.dg/diagnostic/aka5.h: New test.
* g++.dg/diagnostic/aka5a.C: Likewise.
* g++.dg/diagnostic/aka5b.C: Likewise.
* g++.target/aarch64/diag_aka_1.C: Likewise.
* gcc.dg/diag-aka-5.h: Likewise.
* gcc.dg/diag-aka-5a.c: Likewise.
* gcc.dg/diag-aka-5b.c: Likewise.
* gcc.target/aarch64/diag_aka_1.c (f): Expect an aka to be printed
for myvec.

Index: gcc/c-family/c-common.h
===
--- gcc/c-family/c-common.h	2019-09-30 13:54:16.0 +0100
+++ gcc/c-family/c-common.h	2019-09-30 14:16:45.002103890 +0100
@@ -1063,6 +1063,7 @@ extern tree builtin_type_for_size (int,
 extern void c_common_mark_addressable_vec (tree);
 
 extern void set_underlying_type (tree);
+extern bool user_facing_original_type_p (const_tree);
 extern void record_types_used_by_current_var_decl (tree);
 extern vec *make_tree_vector (void);
 extern void release_tree_vector (vec *);
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c	2019-09-30 13:54:16.0 +0100
+++ gcc/c-family/c-common.c	2019-09-30 14:16:45.002103890 +0100
@@ -7713,6 +7713,55 @@ set_underlying_type (tree x)
 }
 }
 
+/* Return true if it is worth exposing the DECL_ORIGINAL_TYPE of TYPE to
+   the user in diagnostics, false if it would be better to use TYPE itself.
+   TYPE is known to satisfy typedef_variant_p.  */
+
+bool
+user_facing_original_type_p (const_tree type)
+{
+  gcc_assert (typedef_variant_p (type));
+  tree decl = TYPE_NAME (type);
+
+  /* Look through any typedef in "user" code.  */
+  if 

Re: [PATCH][wwwdocs] Update GCC 9 release note

2019-10-10 Thread H.J. Lu
On Thu, Oct 3, 2019 at 4:55 PM H.J. Lu  wrote:
>
> Here is the patch to update GCC 9 release note.   Is it OK?
>

Here is the same patch for git repo.  Is it OK?

Thanks.

-- 
H.J.
From 5d5ce91669258720bb47b254faa6308db3ebeed4 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 10 Oct 2019 11:59:56 -0700
Subject: [PATCH] [GCC 9] Mention Intel PTWRITE and Cascade Lake

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

diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index 2ed8409e..58f714ae 100644
--- a/htdocs/gcc-9/changes.html
+++ b/htdocs/gcc-9/changes.html
@@ -936,6 +936,13 @@ $ g++ typo.cc
 IA-32/x86-64
 
   Support of Intel MPX (Memory Protection Extensions) has been removed.
+  New ISA extension support for Intel PTWRITE was added to GCC.  PTWRITE
+  intrinsics are available via the -mptwrite compiler switch.
+  
+  GCC now supports the Intel CPU named Cascade Lake with AVX512 extensions
+  through -march=cascadelake. The switch enables the following
+  ISA extensions: AVX512F, AVX512VL, AVX512CD, AVX512BW, AVX512DQ, AVX512VNNI.
+  
 
 
 
-- 
2.21.0



Re: [PATCH][AArch64] PR79262: Adjust vector cost

2019-10-10 Thread Wilco Dijkstra
ping

PR79262 has been fixed for almost all AArch64 cpus, however the example is still
vectorized in a few cases, resulting in lower performance.  Increase the cost of
vector-to-scalar moves so it is more similar to the other vector costs. As a 
result
-mcpu=cortex-a53 no longer vectorizes the testcase - libquantum and SPECv6
performance improves.

OK for commit?

ChangeLog:
2018-01-22  Wilco Dijkstra  

PR target/79262
* config/aarch64/aarch64.c (generic_vector_cost): Adjust 
vec_to_scalar_cost.
--

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 
c6a83c881038873d8b68e36f906783be63ddde56..43f5b7162152ca92a916f4febee01f624c375202
 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -403,7 +403,7 @@ static const struct cpu_vector_cost generic_vector_cost =
   1, /* vec_int_stmt_cost  */
   1, /* vec_fp_stmt_cost  */
   2, /* vec_permute_cost  */
-  1, /* vec_to_scalar_cost  */
+  2, /* vec_to_scalar_cost  */
   1, /* scalar_to_vec_cost  */
   1, /* vec_align_load_cost  */
   1, /* vec_unalign_load_cost  */


Re: [PATCH] Fix PR c++/92024

2019-10-10 Thread Jason Merrill

On 10/10/19 10:42 AM, Bernd Edlinger wrote:

Hi,

this fixes a crash when -Wshadow=compatible-local is
enabled in the testcase g++.dg/parse/crash68.C


Why does that flag cause this crash?

Jason



Re: [C++ Patch] Remove RROTATE_EXPR and LROTATE_EXPR handling

2019-10-10 Thread Jason Merrill

On 10/10/19 1:53 PM, Jakub Jelinek wrote:

On Thu, Oct 10, 2019 at 06:12:02PM +0200, Paolo Carlini wrote:

while working on cp_build_binary_op I noticed that the testsuite wasn't
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even more the
code handling those tree codes seemed completely unused. Turned out that the
C front-end doesn't handle those tree codes at all: I'm coming to the
conclusion that the C++ front-end bits too are now obsolete and may be
removed, because only the middle-end generates those codes in order to
implement optimizations. Anything I'm missing? Any additional testing?


I guess it depends on where.
fold_binary_loc certainly has code to create {L,R}ROTATE_EXPR,
just look at
unsigned foo (unsigned x)
{
   return (x << 3) + (x >> (__SIZEOF_INT__ * __CHAR_BIT__ - 3));
}

unsigned bar (unsigned x, unsigned y)
{
   return (x << y) | (x >> (__SIZEOF_INT__ * __CHAR_BIT__ - y));
}
and the *.original dump.
The cp_build_binary_op case is unlikely to ever trigger, unless we'd rerun
it on cp_folded trees.
cxx_eval_constant_expression is unlikely, because recently we've switched to
performing constexpr evaluation on pre-cp_folded bodies, not sure if we
never encounter folded trees though.
cp_fold itself depends on whether we ever reprocess the already folded
trees, I'd be afraid we could.


True, and the failure mode there is silent.  Let's leave the codes in 
that switch.


Jason


[PATCH] V5, #15 of 15: Add (0),1 to @pcrel syntax

2019-10-10 Thread Michael Meissner
In the code gaffe I had with the V4 patches, where I mistakenly did:

PADDI rt,ra,label@pcrel

(which the machine does not support), it was suggested that perhaps I should
add an explicit (0),1 to each @pcrel relocation, so that the assembler will
flag any usage where you try to combine an index register and a PC-relative
offset.

With this patch applied, I bootstrapped the compiler on a power8 little endian
machine running Linux, and there were no regressions in the test suite.  I also
built both Spec 2017 rate and Spec 2006 cpu benchmarks with the compiler, and
there were no regressions in the benchmarks that built previously (Spec 2017
parest_r fails in gimple, both with the original compiler and the patched
version of the compiler).

2019-10-09  Michael Meissner  

* config/rs6000/rs6000.c (print_operand_address): Add (0),1 to
@pcrel to catch errant usage.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 276758)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -13271,7 +13271,10 @@ print_operand_address (FILE *file, rtx x
   if (SYMBOL_REF_P (x) && !SYMBOL_REF_LOCAL_P (x))
fprintf (file, "@got");
 
-  fprintf (file, "@pcrel");
+  /* Specifically add (0),1 to catch uses where a @pcrel was added to a an
+address with a base register, since the hardware does not support
+adding a base register to a PC-relative address.  */
+  fprintf (file, "@pcrel(0),1");
 }
   else if (SYMBOL_REF_P (x) || GET_CODE (x) == CONST
   || GET_CODE (x) == LABEL_REF)

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


  1   2   >