[Bug target/48595] score-elf fails to build with --enable-werror-always

2019-08-08 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48595

Eric Gallager  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2013-02-25 00:00:00 |2019-08-09
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> does this still happen?

WAITING on a reply

[Bug c++/80078] Incorrect classification of address of volatile as not constant

2019-08-08 Thread headch at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80078

--- Comment #3 from Christopher Head  ---
I tried 9.1 at gcc.godbolt.org and it looks like this is fixed. Anyone else
care to take a look? If there are no further comments, I guess I’ll close this
ticket in a few days.

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

2019-08-08 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #10 from Martin Sebor  ---
GCC assumes that no object can be bigger than PTRDIFF_MAX - 1 bytes and warns
when it detects code that expects otherwise.  A more general condition to add
to mem_strdupl() to avoid the warning is:

  if (len >= PTRDIFF_MAX)
__builtin_unreachable ();

GCC doesn't track pointer ranges as well as it does integers and it easily
"loses" information about their relationships.  For instance, in the functions
below, GCC folds the first test to false but it doesn't fold the second.

  void f (long a, long b)
  { 
if (a < b)
  return;

if (a - b < 0)   // folded to false
  __builtin_abort ();
  }

  void g (int *a, int *b)
  {
if (a < b)
  return;

if (a - b < 0)   // not folded
  __builtin_abort ();
  }

Re: [PATCH] fix and improve strlen conditional handling of merged stores (PR 91183, 91294, 91315)

2019-08-08 Thread Jeff Law
On 7/31/19 6:36 PM, Martin Sebor wrote:
> More extensive testing of the last week's strlen patch for
> PR91183 on various non-mainstream targets and with better tests
> has exposed a few gaps and a couple of bugs.  The attached patch
> addresses all in one change.  I considered splitting it up but
> in the end decided the changes were small and sufficiently
> isolated that it wasn't necessary.  (If someone feels strongly
> otherwise it can be easily split t up.)
> 
> The wrong-code bug (PR 91294) is due to handle_store neglecting
> to fully consider the case when a single multi-byte store
> involving a PHI of two "strings" the same size (so they are merged
> into a single int store) but of unequal length.  The function
> simply takes the length of the shorter string as the resulting
> length when it needs to only set the lower bound of the length
> (it does that treating the result as potentially not nul-
> terminated).
> 
> The gaps are in not handling some MEM_REF forms that come up
> in multi-byte assignments (this is the rest of PR 91183 and was
> exposed on strictly aligned targets), and in handle_builtin_strlen
> discarding the lower bound on a string length instead of exposing
> it to downstream passes.  This is PR 91315 that was exposed by
> a few cases in the existing tests for PR 91294 failing after
> the fix for PR 91294.
> 
> Tested on x86_64-linux and spot-checked with a sparc-solaris2.11
> cross-compiler.
> 
> Martin
> 
> gcc-91294-2.diff
> 
> PR tree-optimization/91315 - missing strlen lower bound of a string known to 
> be at least N characters
> PR tree-optimization/91294 - wrong strlen result of a conditional with an 
> offset
> PR tree-optimization/91183 - strlen of a strcpy result with a conditional 
> source not folded
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/91315
>   PR tree-optimization/91294
>   PR tree-optimization/91183
>   * gcc.dg/strlenopt-44.c: Avoid using length of 1.
>   * gcc.dg/strlenopt-70.c: Disable overly optimistic tests.
>   * gcc.dg/strlenopt-73.c: New test.
>   * gcc.dg/strlenopt-74.c: New test.
>   * gcc.dg/strlenopt-75.c: New test.
>   * gcc.dg/strlenopt-76.c: New test.
>   * gcc.dg/strlenopt-77.c: New test.
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/91315
>   PR tree-optimization/91294
>   PR tree-optimization/91183
>   * gimple-fold.c (gimple_fold_builtin_strlen): Add expected argument.
>   * tree-ssa-strlen.c (set_strlen_range): Add function argument.
>   (maybe_set_strlen_range): Add expected argument.
>   (handle_builtin_strlen): Call set_strlen_range.
>   (count_nonzero_bytes): Add function arguments.  Handle strinfo
>   first.  Handle "single" assignment.
>   (handle_store): Set the lower bound of length for multibyte stores
>   of unequal lengths.
>   * tree-ssa-strlen.h (set_strlen_range): Add function argument.
> 
> Index: gcc/tree-ssa-strlen.c
> ===
> --- gcc/tree-ssa-strlen.c (revision 273914)
> +++ gcc/tree-ssa-strlen.c (working copy)
> @@ -1434,6 +1434,12 @@ handle_builtin_strlen (gimple_stmt_iterator *gsi)
> tree adj = fold_build2_loc (loc, MINUS_EXPR,
> TREE_TYPE (lhs), lhs, old);
> adjust_related_strinfos (loc, si, adj);
> +   /* Use the constant minimim length as the lower bound
s/minimim/minimum/


> @@ -3408,7 +3457,13 @@ static bool
>   }
>  
>gimple *stmt = SSA_NAME_DEF_STMT (exp);
> -  if (gimple_code (stmt) != GIMPLE_PHI)
> +  if (gimple_assign_single_p (stmt))
> + {
> +   tree rhs = gimple_assign_rhs1 (stmt);
> +   return count_nonzero_bytes (rhs, offset, nbytes, lenrange, nulterm,
> +   allnul, allnonnul, snlim);
> + }
> +  else if (gimple_code (stmt) != GIMPLE_PHI)
>   return false;
What cases are you handling here?  Are there any cases where a single
operand expression on the RHS affects the result.  For example, if we've
got a NOP_EXPR which zero extends RHS?  Does that change the nonzero
bytes in a way that is significant?

I'm not opposed to handling single operand objects here, I'm just
concerned that we're being very lenient in just stripping away the
operator and looking at the underlying object.



> @@ -3795,7 +3824,14 @@ handle_store (gimple_stmt_iterator *gsi)
>   }
> else
>   si->nonzero_chars = build_int_cst (size_type_node, offset);
> -   si->full_string_p = full_string_p;
> +
> +   /* Set FULL_STRING_P only if the length of the strings being
> +  written is the same, and clear it if the strings have
> +  different lengths.  In the latter case the length stored
> +  in si->NONZERO_CHARS becomes the lower bound.
> +  FIXME: Handle the upper bound of the length if possible.  */
> +   si->full_string_p = full_string_p 

[Bug c++/90473] gcc does not call function in comma operator for default argument

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90473

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00597.html

C++ PATCH for c++/90473 - wrong code with nullptr in default argument

2019-08-08 Thread Marek Polacek
This is a wrong-code bug where we are throwing away the function call in
the default argument here:

  void fn1 (void* p = (f(), nullptr)) { }

and thus dropping the possible side-effects of that call to the floor.

That happens because check_default_argument returns nullptr_node when it
sees a null_ptr_cst_p argument.  In this case the argument is a COMPOUND_EXPR
"f(), nullptr" and null_ptr_cst_p returns true for it.  And so the effects of
the LHS expression of the compound expr are forgotten.  Fixed as below.

It's tempting to change null_ptr_cst_p to return false when it sees something
that has TREE_SIDE_EFFECTS, but that would be wrong I think: [conv.ptr] says
that a null pointer constant is an integer literal with value zero or a prvalue
of type std::nullptr_t.  An expression "a, b", the built-in comma expression,
is a prvalue if 'b' is an rvalue.  And so "f(), nullptr" is a prvalue of type
std::nullptr_t.

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

2019-08-08  Marek Polacek  

PR c++/90473 - wrong code with nullptr in default argument.
* call.c (null_ptr_cst_p): Update quote from the standard.
* decl.c (check_default_argument): Don't return nullptr when the arg
has side-effects.

* g++.dg/cpp0x/nullptr42.C: New test.

diff --git gcc/cp/call.c gcc/cp/call.c
index 61334a16248..01a25ad6e1e 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -529,9 +529,8 @@ null_ptr_cst_p (tree t)
 
   /* [conv.ptr]
 
- A null pointer constant is an integral constant expression
- (_expr.const_) rvalue of integer type that evaluates to zero or
- an rvalue of type std::nullptr_t. */
+ A null pointer constant is an integer literal ([lex.icon]) with value
+ zero or a prvalue of type std::nullptr_t.  */
   if (NULLPTR_TYPE_P (type))
 return true;
 
diff --git gcc/cp/decl.c gcc/cp/decl.c
index b8806e4628d..d91f25183fb 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -13177,7 +13177,9 @@ check_default_argument (tree decl, tree arg, 
tsubst_flags_t complain)
   /* Avoid redundant -Wzero-as-null-pointer-constant warnings at
  the call sites.  */
   if (TYPE_PTR_OR_PTRMEM_P (decl_type)
-  && null_ptr_cst_p (arg))
+  && null_ptr_cst_p (arg)
+  /* Don't lose side-effects as in PR90473.  */
+  && !TREE_SIDE_EFFECTS (arg))
 return nullptr_node;
 
   /* [dcl.fct.default]
diff --git gcc/testsuite/g++.dg/cpp0x/nullptr42.C 
gcc/testsuite/g++.dg/cpp0x/nullptr42.C
new file mode 100644
index 000..2fb628df6d7
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/nullptr42.C
@@ -0,0 +1,18 @@
+// PR c++/90473 - wrong code with nullptr in default argument.
+// { dg-do run { target c++11 } }
+
+int g;
+void f() { g++; }
+
+void fn1 (void* p = (f(), nullptr)) { }
+void fn2 (int p = (f(), 0)) { }
+
+int main()
+{
+  fn1 ();
+  if (g != 1)
+__builtin_abort ();
+  fn2 ();
+  if (g != 2)
+__builtin_abort ();
+}


Re: Start implementing -frounding-math

2019-08-08 Thread Joseph Myers
On Mon, 24 Jun 2019, Marc Glisse wrote:

> > OK, fair enough.  I just hoped that global
> > 
> > double x = 1.0/3.0;
> > 
> > do not become runtime initializers with -frounding-math ...
> 
> Ah, I wasn't thinking of globals. Ignoring the new pragma fenv_round, which I
> guess could affect this (the C draft isn't very explicit), the program doesn't

I think FENV_ROUND (for C) definitely affects both interpretation of 
constants (if the constant isn't exactly representable in the format in 
which it is evaluated) and the evaluation of operations in initializers 
with static or thread storage duration.  (F.8.2 in the current C2x draft 
says "During translation, constant rounding direction modes (7.6.2) are in 
effect where specified." and F.8.5 says "All computation for 
initialization of objects that have static or thread storage duration is 
done (as if) at translation time.".)

> One issue is that the C pragmas do not let me convey that I am interested in
> dynamic rounding but not exception flags. It is possible to optimize quite a

TS 18661-5 allows e.g. "#pragma STDC FENV_EXCEPT FE_ALL_EXCEPT NO_FLAG" 
or "#pragma STDC FENV_EXCEPT FE_ALL_EXCEPT OPTIONAL_FLAG".  (But it 
doesn't allow for saying you don't care about exceptions to the extent 
that raising spurious exceptions is OK.)

Some parts of 18661-5 are probably substantially more complicated to 
implement than any of the other floating-point pragmas.  I'm not sure if 
there's any implementation experience at all with 18661-5, in any C 
implementation.

(On the other hand, CX_LIMITED_RANGE is probably the easiest of the 
floating-point pragmas to implement, because it has purely local effects - 
you just need two different forms of IR for complex multiplication and 
division, chosen based on whether the pragma is in effect in the current 
scope, and then lower them in two different ways that GCC already 
supports.)

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


[PATCH,Fortran] -- Tidy up the BOZ rewrite

2019-08-08 Thread Steve Kargl
The attach patch has been regression tested on x86_64-*-freebsd.

It does a number of things.

1) It tightens the adherence to F2018 Fortran standard.  For example,
   this program and execute with gfortran 9 and older.

   program foo
   integer i
   data i/z'40490adf'/ ! Explicit declaration
   data j/z'40490adf'/ ! Implicit typing
   integer :: k = z'40490adf'  ! Invalid F2018
   integer l /z'40490adf'/ ! Old-style initialization.  Invalid F2018.
   print *, i, j, k, l
   end program foo

% gfc9 -o z a.f90 && ./z
  1078528735  1078528735  1078528735  1078528735

With trunk, the lines marked as "Invalid F2018" will invoke error
messages.  The errors can be downgraded to warnings with the
-fallow-invalid-boz.

% gfcx -fallow-invalid-boz -o z a.f90 && ./z
a.f90:5:16:

5 |   integer :: k = z'40490adf' ! Invalid F2018
  |1
Warning: BOZ literal constant at (1) is neither a data-stmt-constant nor
an actual argument to INT, REAL, DBLE, or CMPLX intrinsic function
a.f90:6:24:

6 |   integer l /z'40490adf'/! Old-style initialization. Invalid F2018.
  |1
Warning: BOZ at (1) cannot appear in an old-style initialization
  1078528735  1078528735  1078528735  1078528735

2) Mark Eggleston point out the that following invalid code would compile
   with my original patch while older versions of gfortran rejected the
   code.

   program foo
   character(4) i
   data i /z'40490adf'/
   logical j
   data j /z'40490adf'/
   print *, i, j
   end program foo

  This code now generates 

% gfcx -c z a.f90
a.f90:5:21:

5 |   data j /z'40490adf'/
  | 1
Error: BOZ literal constant near (1) cannot be assigned to
a 'LOGICAL(4)' variable
a.f90:3:21:

3 |   data i /z'40490adf'/
  | 1
Error: BOZ literal constant near (1) cannot be assigned to
a 'CHARACTER(1)' variable

3) Mark also asked about allowing a BOZ in a rational expression.
   In particular, he has/had code with statements of the form
   "if (i < z'12334') then".  Under F2018, a BOZ cannot appear
   as an operand in an expression.  My original patch issued
   an error.

   This patch disallows a BOZ as an oprand to an unary operator.
   It disallows both operand of a binary operator to be BOZ.  If
   one operand is a BOZ, it is converted to the type and kind of
   the other operand.  Note, everthing is guarded with gfc_invalid_boz.
   For example, 

   program foo
   integer i
   i = 42
   if (i < z'40490adf') print *, i
   end program foo

% gfcx -o z a.f90 && ./z
a.f90:4:9:

4 |   if (i < z'40490adf') print *, i
  | 1
Error: BOZ literal constant near (1) cannot appear as an operand
of a rational operator
% gfcx -fallow-invalid-boz -o z a.f90 && ./z
a.f90:4:9:

4 |   if (i < z'40490adf') print *, i
  | 1
Warning: BOZ literal constant near (1) cannot appear as an operand
of a rational operator
  42

OK to commit?

2019-08-08  Steven G. Kargl  

* decl.c (match_old_style_init): Use a clearer error message.
* expr.c (gfc_check_assign): Update BOZ checking to provide a stricter
adherence to the Fortran standard.  Use gfc_invalid_boz () to
relax errors into warnings.
* gfortran.h (gfc_isym_id): Add new ids GFC_ISYM_DFLOAT,
GFC_ISYM_FLOAT, GFC_ISYM_REALPART, and GFC_ISYM_SNGL
* intrinsic.c (add_functions): Use new ids to split REAL generic into
REAL, FLOAT, DFLOAT, SNGL, and REALPART generics.
(gfc_intrinsic_func_interface): Allow new intrinsics in an
initialization expression
* resolve.c (resolve_operator): Deal with BOZ as operands.
Use gfc_invalid_boz to allow for errors or warnings via the
-fallow-invalid-boz option.  A BOZ cannot be an operand to an
unary operator.  Both operands of a binary operator cannot be BOZ.
For binary operators, convert a BOZ operand into the type and
kind of the other operand for REAL or INTEGER operand.
* trans-intrinsic.c: Use new ids to cause conversions to happen.

2019-08-08  Steven G. Kargl  

* gfortran.dg/boz_8.f90: Adjust error messages.
* gfortran.dg/nan_4.f90: Ditto.
* gfortran.dg/boz_1.f90: Add -fallow-invalid-boz to dg-options,
and test for warnings.
* gfortran.dg/boz_3.f90: Ditto.
* gfortran.dg/boz_4.f90: Ditto.
* gfortran.dg/dec_structure_6.f90: Ditto.
* gfortran.dg/ibits.f90: Ditto.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 274214)
+++ gcc/fortran/decl.c	(working copy)
@@ -579,9 +579,10 @@ match_old_style_init (const char *name)
 	  && nd->var->expr->ts.type != BT_REAL
 	  && nd->value->expr->ts.type == BT_BOZ)
 	{
-	  gfc_error ("Mismatch in variable type and BOZ literal constant "
-		 "at %L in an old-style initialization",
-		 >value->expr->where);
+	  

Re: Expansion of narrowing math built-ins into power instructions

2019-08-08 Thread Joseph Myers
On Thu, 8 Aug 2019, Segher Boessenkool wrote:

> These current patterns all take the same mode for all inputs and outputs
> (that's what 3 indicates, say, fadddf3).  You will need to define
> something that takes two SFs in and produces a DF.  That cannot really

For example, md.texi describes standard patterns such as mulhisi3 that 
multiply two HImode values and produce an SImode result (widening integer 
multiply).

Using a similar naming pattern, you might have a pattern adddfsf3 that 
multiplies two DFmode values and produces an SFmode result (or you could 
call it something like add_truncdfsf3 if you wish to emphasise the 
truncation involved, for example).  Similarly addtfsf3 that multiplies 
TFmode and produces an SFmode result, and so on.  Of course these names 
need documenting (and you need corresponding RTL for them to generate that 
distinguishes the fused add+truncate from the different RTL for separate 
addition and truncation with double rounding).  In cases where long double 
and double have the same mode, the daddl function should use the existing 
adddf3 pattern.

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


[PATCH] rs6000: Add ordered compares (PR58684)

2019-08-08 Thread Segher Boessenkool
This adds ordered compares to most unordered compares, in rs6000.

It does not handle the XL_COMPAT double-double compares yet (that is
the pattern with 16 operands).  It also does not handle the vector
compare instructions; those only exist as unordered, for the equality
comparisons, or as ordered, for the inequality comparisons.

The *cmpo machine instructions do exactly the same thing as the *cmpu
instructions do, but they trigger an invalid operation exception (or
just set the sticky flag for it) if any of the inputs is a NaN.

This patch models *cmpo as a parallel of the comparison with an
unspec UNSPEC_CMPO of the comparison inputs.  This means an ordered
compare will never be deleted.  Multiple comparisons can still be
combined (including with unordered combines).

Questions:

1) Is this *correct*?
2) Is it *required*, or can we delete ordered compares in some cases?
2a) Like, if we test ab, we only need one compare instruction,
not the two that are generate right now.
2b) How can we model things so this happens automatically?  Without having
to write new passes ;-)


Bootstrapped and regression tested on powerpc64-linux {-m32,-m64}
(a Power7) so far.


Segher


2019-08-08  Segher Boessenkool  

PR target/58684
* config/rs6000/dfp.md (*cmp_internal1 for DDTD): Rename to ...
(*cmp_cmpu for DDTD): ... this.
(*cmp_cmpo for DDTD): New define_insn.
* config/rs6000/rs6000.c (rs6000_generate_compare): Handle scalar
floating point ordered compares, by generating a parallel with an
unspec UNSPEC_CMPO,
* config/rs6000/rs6000.md (unspec): Add UNSPEC_CMPO.
(*cmp_fpr for SFDF): Rename to ...
(*cmp_cmpu for SFDF): ... this.
(*cmp_cmpo for SFDF): New define_insn.
(*cmp_internal1 for IBM128): Rename to ...
(*cmp_cmpu for IBM128): ... this.
(*cmp_cmpo for IBM128): New define_insn.
(*cmp_hw for IEEE128): Rename to ...
(*cmp_cmpu for IEEE128): ... this.
(*cmp_cmpo for IEEE128): New define_insn.

gcc/testsuite/
* gcc.dg/torture/inf-compare-1.c: Remove powerpc xfail.
* gcc.dg/torture/inf-compare-2.c: Ditto.
* gcc.dg/torture/inf-compare-3.c: Ditto.
* gcc.dg/torture/inf-compare-4.c: Ditto.
* gcc.target/powerpc/dfp-dd.c: Expect 2 unordered and 4 ordered
comparisons, instead of 6 unordered ones.
* gcc.target/powerpc/dfp-td.c: Ditto.

---
 gcc/config/rs6000/dfp.md | 11 +++-
 gcc/config/rs6000/rs6000.c   | 19 --
 gcc/config/rs6000/rs6000.md  | 39 +---
 gcc/testsuite/gcc.dg/torture/inf-compare-1.c |  2 --
 gcc/testsuite/gcc.dg/torture/inf-compare-2.c |  2 --
 gcc/testsuite/gcc.dg/torture/inf-compare-3.c |  2 --
 gcc/testsuite/gcc.dg/torture/inf-compare-4.c |  2 --
 gcc/testsuite/gcc.target/powerpc/dfp-dd.c|  3 ++-
 gcc/testsuite/gcc.target/powerpc/dfp-td.c|  3 ++-
 9 files changed, 67 insertions(+), 16 deletions(-)

diff --git a/gcc/config/rs6000/dfp.md b/gcc/config/rs6000/dfp.md
index 659b3c9..55a8665 100644
--- a/gcc/config/rs6000/dfp.md
+++ b/gcc/config/rs6000/dfp.md
@@ -187,7 +187,7 @@ (define_insn "div3"
   "ddiv %0,%1,%2"
   [(set_attr "type" "dfp")])
 
-(define_insn "*cmp_internal1"
+(define_insn "*cmp_cmpu"
   [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
(compare:CCFP (match_operand:DDTD 1 "gpc_reg_operand" "d")
  (match_operand:DDTD 2 "gpc_reg_operand" "d")))]
@@ -195,6 +195,15 @@ (define_insn "*cmp_internal1"
   "dcmpu %0,%1,%2"
   [(set_attr "type" "dfp")])
 
+(define_insn "*cmp_cmpo"
+  [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
+   (compare:CCFP (match_operand:DDTD 1 "gpc_reg_operand" "d")
+ (match_operand:DDTD 2 "gpc_reg_operand" "d")))
+   (unspec [(match_dup 1) (match_dup 2)] UNSPEC_CMPO)]
+  "TARGET_DFP"
+  "dcmpo %0,%1,%2"
+  [(set_attr "type" "dfp")])
+
 (define_insn "floatdidd2"
   [(set (match_operand:DD 0 "gpc_reg_operand" "=d")
(float:DD (match_operand:DI 1 "gpc_reg_operand" "d")))]
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 4080c82..c2299fe 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -13878,8 +13878,23 @@ rs6000_generate_compare (rtx cmp, machine_mode mode)
emit_insn (gen_stack_protect_testsi (compare_result, op0, op1b));
}
   else
-   emit_insn (gen_rtx_SET (compare_result,
-   gen_rtx_COMPARE (comp_mode, op0, op1)));
+   {
+ rtx compare = gen_rtx_SET (compare_result,
+gen_rtx_COMPARE (comp_mode, op0, op1));
+
+ /* If this FP compare should be an ordered compare, mark it.  */
+ if (SCALAR_FLOAT_MODE_P (mode)
+ && HONOR_NANS (mode)
+ && (code == LT || code == GT || code == LE || code == GE))
+   {
+ rtx unspec = 

[Bug driver/80545] option -Wstringop-overflow not recognized by Fortran

2019-08-08 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
I believe r273771 fully this bug.

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

2019-08-08 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82813
Bug 82813 depends on bug 80545, which changed state.

Bug 80545 Summary: option -Wstringop-overflow not recognized by Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/89176] Vectorizer fails to consider narrower vector width for res[i] = v1[i] < v2[i] ? v2[i] : v1[i]

2019-08-08 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89176

H.J. Lu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> 
> The epilogue vectorization issue also needs investigation.

Epilogue vectorization doesn't seem to work:

[hjl@gnu-cfl-1 pr89176]$ cat x.i
extern float *v1;
extern float *v2;
extern float *res;


void
foo (int n)
{
  int i;

  for (i = 0; i < n; i++)
res[i] = v2[i] * v1[i];
}
[hjl@gnu-cfl-1 pr89176]$ make x.s
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O3
-march=skylake  -S x.i
[hjl@gnu-cfl-1 pr89176]$ cat x.s
.file   "x.i"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
testl   %edi, %edi
jle .L23
movqv2(%rip), %rcx
movqres(%rip), %rdx
movqv1(%rip), %rsi
leaq31(%rcx), %r8
subq%rdx, %r8
cmpq$62, %r8
leaq31(%rsi), %r8
seta%r9b
subq%rdx, %r8
cmpq$62, %r8
seta%r8b
leal-1(%rdi), %eax
testb   %r8b, %r9b
je  .L3
cmpl$6, %eax
jbe .L3
movl%edi, %r8d
shrl$3, %r8d
salq$5, %r8
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L4:
vmovups (%rcx,%rax), %ymm1
vmulps  (%rsi,%rax), %ymm1, %ymm0
vmovups %ymm0, (%rdx,%rax)
addq$32, %rax
cmpq%r8, %rax
jne .L4
movl%edi, %eax
andl$-8, %eax
testb   $7, %dil
je  .L22
movl%eax, %r8d
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal1(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal2(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal3(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal4(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal5(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
addl$6, %eax
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
cmpl%eax, %edi
jle .L22
cltq
vmovss  (%rcx,%rax,4), %xmm0
vmulss  (%rsi,%rax,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%rax,4)
vzeroupper
ret
.p2align 4,,10
.p2align 3
.L22:
vzeroupper
.L23:
ret
.p2align 4,,10
.p2align 3
.L3:
movl%eax, %edi
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L6:
vmovss  (%rcx,%rax,4), %xmm0
movq%rax, %r8
vmulss  (%rsi,%rax,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%rax,4)
incq%rax
cmpq%rdi, %r8
jne .L6
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 10.0.0 20190723 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr89176]$

gcc-7-20190808 is now available

2019-08-08 Thread gccadmin
Snapshot gcc-7-20190808 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190808/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

 gcc-7-20190808.tar.xzComplete GCC

  SHA256=c9f13f2ec51ef8419a6a70fceb090602b8c39ab951a6b43f1a63984398b47024
  SHA1=80791c4a40d73e9fde1a53e3c3a1bb28d5a128d7

Diffs from 7-20190801 are available in the diffs/ subdirectory.

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


Re: [PATCH] Sync MIPS support from libffi master repository

2019-08-08 Thread Jeff Law
On 8/8/19 4:18 PM, Aurelien Jarno wrote:
> 
> It is used by libgo, but it seems to be the last user.
Ah, yes, I should have remembered libgo.  And it links via
../../blahblah.  Thanks for digging into it.

So, yea, we need it.  So I think the best path forward is to just resync
everything to the upstream master.

Jeff


Re: [PATCH] Sync MIPS support from libffi master repository

2019-08-08 Thread Aurelien Jarno
On 2019-08-08 15:00, Jeff Law wrote:
> On 8/8/19 2:56 PM, Aurelien Jarno wrote:
> > On 2019-08-08 14:41, Jeff Law wrote:
> >> On 8/5/19 2:33 PM, Aurelien Jarno wrote:
> >>> This updates the libffi MIPS support up to commit 746dbe3a6a79, with the
> >>> exception of commit bd72848c7af9 which prefixes the ALIGN macro with
> >>> FFI_ for all ports.
> >>>
> >>> These patches, with the exception of the softfloat one, have been used
> >>> on the Debian GCC packages for quite some time.
> >>>
> >>> libffi/Changelog:
> >>>
> >>> 2019-08-05  Aurelien Jarno  
> >>>
> >>>   Import from upstream
> >>>   * src/mips/ffi.c (ffi_call_O32, ffi_call_N32,
> >>>   ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust
> >>>   interface.
> >>>   (ffi_call_int): Renamed from ffi_call.
> >>>   (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions.
> >>>   (ffi_prep_closure_loc): Define jr instruction for R6.
> >>>   * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define.
> >>>   (FFI_TRAMPOLINE_SIZE): Define to 56 for N64.
> >>>   Test for __linux__ instead of linux.
> >>>   * src/mips/n32.S (ffi_go_closure_N32): New function.
> >>>   (ffi_call_N32): Adjust code for softfloat.
> >>>   (.set mips4): Guard with !defined(__mips_isa_rev) ||
> >>>   (__mips_isa_rev<6).
> >>>   * src/mips/o32.S (ffi_go_closure_O32): New function.
> >>>   (ffi_call_O32): Adjust code for softfloat.
> >> What's the motivation here?
> > 
> > The original motivation is that it improves go support on MIPS in
> > general and fixes it on MIPS R6.
> > 
> > The more recent motivation is that Debian has been patching GCC with
> > those changes for quite some time, however we are now requested that
> > those patches are merged upstream.
> Understood.
> 
> > 
> >> Would we just be better off moving all of libffi forward rather than
> >> just MIPS bits?
> > 
> > Looking at the history, each port has be doing its own sync from libffi.
> > Now I agree with you that if possible, moving all of libffi forward
> > looks like a good idea.
> If we still need libffi, this would be my preference...  But...
> 
> >  
> >> Do we even still need a bundled libffi in GCC anymore?
> > 
> > The issue might be that the last libffi release has been done 5 years
> > ago, and most of the recent commits done in the libffi/ directory are
> > not present in a released version of libffi.
> > 
> > Otherwise I do not have idea if it is feasible to use the shared libffi
> > library.
> My point is I'm not even sure we're using libffi within gcc anymore.  I
> know we used it for Java bits, but that was killed some time ago.  Some
> quick grepping for lffi, ffi.h and ffitarget.h aren't turning up
> anything outside the libffi directory itself.  So I really question if
> we still need it at all within gcc.

It is used by libgo, but it seems to be the last user.


Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


[Bug c++/90473] gcc does not call function in comma operator for default argument

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90473

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #3 from Marek Polacek  ---
I think checking TREE_SIDE_EFFECTS there should be enough.

Re: [Patch, ira] Invalid assert in reload1.c::finish_spills?

2019-08-08 Thread Jeff Law
On 8/7/19 8:15 AM, Vladimir Makarov wrote:
> On 8/7/19 7:36 AM, senthilkumar.selva...@microchip.com wrote:
>> Hi,
>>
>>    gcc/testsuite/c-c++-common/pr60101.c fails with an ICE for the
>>    avr target, because of a gcc_assert firing at reload1.c:4233
>>
>>    The assert (in the patch below) looks bogus to me, as it's in
>>    the if block of
>>
>>  if (! ira_conflicts_p || reg_renumber[i] >= 0)
>>
>>    For this testcase and for the avr target, ira_conflicts_p is
>>    false because build_conflict_bit_table bailed out early
>>    (conflict table too big).
>>    If reg_renumber[i] is now negative, the assert fires and causes
>>    the ICE.
>>
>>    Getting rid of the assert (patch below) makes the ICE go away,
>>    not sure if that's the right fix though.
>>
>>    Comments?
> 
> Mike Matz is right.  Removing the assertion will make the bug even worse
> (changing memory beyond pseudo_previous_regs).
> 
> I did some investigation.  This bug occurred from a 10 years old patch
> avoiding building big conflict tables in IRA.  And the assert was in
> reload before IRA.
> 
> I think the solution should be
[ ... ]
That seems to be working on the embedded targets which probably covers
most of the remaining reload targets.

m68k will bootstrap with it overnight, that's probably the most
interesting test we'll get for this change.

Jeff


Re: [PATCH 2/9] ifcvt: Use enum instead of transform_name string.

2019-08-08 Thread Jeff Law
On 8/6/19 2:42 PM, Richard Sandiford wrote:
> Robin Dapp  writes:
>> This patch introduces an enum for ifcvt's various noce transformations.
>> As the transformation might be queried by the backend, I find it nicer
>> to allow checking for a proper type instead of a string comparison.
> 
> TBH I think the names of internal ifcvt routines are too level to expose as
> an "official" part of the interface.  (OK, like you say, the information's
> already there and rogue backends could already check it if they wanted.)
> 
> If we were going to have an enum, I think it should be a higher-level
> description of what the converted code is going to do, rather than the
> name of the routine that's going to do it.
> 
> It sounded from the covering note that you might not need this
> any more though.
You're probably right on the naming.   I think the main question with
patch #1 and #2 is whether or not targets would likely use that information.

My sense is that arm & aarch64 want to be doing if-conversion very
aggressively and likely wouldn't care about them.  On x86 if-conversion
costing seems more complex -- in fact, I don't think we really have a
clear picture of what the costing factors really are for x86.  It sounds
like at least for the issues Robin is addressing that s390 won't care.

So my inclination would be to defer #1 and #2 until a particular target
indicates that it needs this information.  If that happens, we dust off
patches #1 and #2.

Jeff


Re: [PATCH v2] Use edge->indirect_unknown_callee in cgraph_edge::make_direct (PR ipa/89330).

2019-08-08 Thread Jeff Law
On 8/8/19 1:41 AM, Martin Liška wrote:
> On 8/8/19 12:08 AM, Jeff Law wrote:
>> Would this possibly be the cause of this error building the kernel:
> 
> Probably yes. You see the same as H.J.:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334
> 
> Can you please create a pre-processed source with and command line options?
> And please tell me how you configure your compiler?
Ugh.  I was going to do a litle bisection and investigation and, of
course, it's not triggering.   I'm moving a bit between multiple tasks
as a dig out from vacation, but will try to get you something useful as
soon as I can.

jeff


[Bug c++/90473] gcc does not call function in comma operator for default argument

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90473

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
This is where we lose the side-effect:

check_default_argument
13174   /* Avoid redundant -Wzero-as-null-pointer-constant warnings at
13175  the call sites.  */
13176   if (TYPE_PTR_OR_PTRMEM_P (decl_type)
13177   && null_ptr_cst_p (arg))
13178 return nullptr_node;

Poking more...

[Bug c++/91394] C++ ABI incompatibility (stdexcept)

2019-08-08 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394

--- Comment #4 from Jonathan Wakely  ---
Some programs which happen to not use any new features might work with an older
version of libstdc++.so but that is not guaranteed, and definitely not
supported.

Removing one or two functions from a header is not going to solve the problem
in the general case. Using _GLIBCXX_USE_CXX11_ABI is also not a solution for
this, that's not what it's for.

If you want to run with the libstdc++.so from GCC 4.9.4 then compile with GCC
4.9.4, that's guaranteed to work.

[Bug driver/91406] New: gcc -Q -v lies about what flags are enabled

2019-08-08 Thread sje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91406

Bug ID: 91406
   Summary: gcc -Q -v lies about what flags are enabled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

If you run 'gcc -Q -v x.c'  and look at the 'options enabled:' list, it is not
accurate.  For example, on aarch64 it will show '-fprefetch-loop-arrays' which
is not on by default for a generic aarch64 compiles (even at -O3).  The problem
is that this flag is initialized to -1 and it might be overridden by
aarch64_override_options_internal in some cases to turn it on but if it is not
overridden it stays at -1 and then option_enabled (opts-common.c) checks
to see if it is zero or not-zero and if not-zero it returns true and says it
is enabled.  Note that in this case the compiler will not actually generate
prefetch instructions because the gate function is checking for 'x > 0', not
'x != 0' like option_enabled does.

This can affect any option in commons.opt (or elsewhere) that is initialized to
-1.  There are also flags that are initialized to 1 but probably should not
show up if compiling at -O0 because in that case the pass that would check the
flag is never called, such as -faggressive-loop-optimizations for example.  If
you run a '-Q -v -O0' compilation on x86 the list of enabled options will
include -faggressive-loop-optimizations which I am sure is not actually run.  I
guess you could claim it is enabled but not run, but that seems unhelpful.

I could fix the specific aarch64 '-fprefetch-loop-arrays' bug by having
aarch64_override_options_internal set the prefetch flag to 0 in those cases
where it is not setting it to 1.  That way it would never be -1 when
option_enabled checks it, but I am not sure this the right/best fix.

Re: [PATCH] i386: Roundeven expansion for SSE4.1+

2019-08-08 Thread Jeff Law
On 7/27/19 3:04 AM, Uros Bizjak wrote:
> On Wed, Jul 24, 2019 at 12:43 PM Tejas Joshi  wrote:
>>
>> Hi.
>> This is a patch that Uros suggested for roundeven expansion, here.
>> Thanks for the heads up.
>> 
>> I have rerun the testsuite on the patch, it survives the regression
>> tests and bootstraps on x86_64-linux-gnu. Note, patch to be applied on
>> top of
>> 
>>
>> Thanks,
>> Tejas
>>
>> gcc/ChangeLog:
>>
>> 2019-07-24  Tejas Joshi  
>>
>> * builtins.c (mathfn_built_in_2): Change CASE_MATHFN to
>> CASE_MATHFN_FLOATN for roundeven.
>> * config/i386/i386.c (ix86_i387_mode_needed): Add case I387_ROUNDEVEN.
>> (ix86_mode_needed): Likewise.
>> (ix86_mode_after): Likewise.
>> (ix86_mode_entry): Likewise.
>> (ix86_mode_exit): Likewise.
>> (ix86_emit_mode_set): Likewise.
>> (emit_i387_cw_initialization): Add case I387_CW_ROUNDEVEN.
>> * config/i386/i386.h (ix86_stack_slot) : Add SLOT_CW_ROUNDEVEN.
>> (ix86_entry): Add I387_ROUNDEVEN.
>> (avx_u128_state): Add I387_CW_ANY.
>> * config/i386/i386.md: Define UNSPEC_FRNDINT_ROUNDEVEN.
>> (define_int_iterator): Likewise.
>> (define_int_attr): Likewise for rounding_insn, rounding and ROUNDING.
>> (define_constant): Define ROUND_ROUNDEVEN mode.
>> (define_attr): Add roundeven mode for i387_cw.
>> (2): Add condition for ROUND_ROUNDEVEN.
>> * internal-fn.def (ROUNDEVEN): New builtin function.
>> * optabs.def (roundeven_optab): New optab.
>>
> 
> LGTM for the x86 part, but you are mixing middle-end changes in the
> patch, so you also need an OK from a middle-end maintainer.
I think the middle end bits are fine too.

Jeff



Re: [PATCH] Provide proper error message for -flto=abcd.

2019-08-08 Thread Jeff Law
On 7/29/19 7:36 AM, Martin Liška wrote:
> Hi.
> 
> The patch is about proper error message for situations where
> user give a wrong argument to -flto option.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2019-07-29  Martin Liska  
> 
>   * opts.c (common_handle_option): Error for an invalid argument
>   to -flto=.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-07-29  Martin Liska  
> 
>   * gcc.dg/spellcheck-options-21.c: New test.
OK, including any minor adjustments to deal with any changes in the
-flto option made since this was originally submitted.

jeff


Re: [PATCH] [MIPS] Add missing const qualifier in MSA ld intrinsic documentation

2019-08-08 Thread Jeff Law
On 7/26/19 3:12 AM, Mihailo Stojanovic wrote:
> From: Mihailo Stojanovic 
> 
> The documentation is not reflecting the fact that the first argument of
> MSA ld intrinsics is a const void pointer.
> 
> gcc/
> 
> * doc/extend.texi: Add const qualifier to ld intrinsics.
THanks.  Installed.

jeff


Re: [PATCH] Sync MIPS support from libffi master repository

2019-08-08 Thread Jeff Law
On 8/8/19 2:56 PM, Aurelien Jarno wrote:
> On 2019-08-08 14:41, Jeff Law wrote:
>> On 8/5/19 2:33 PM, Aurelien Jarno wrote:
>>> This updates the libffi MIPS support up to commit 746dbe3a6a79, with the
>>> exception of commit bd72848c7af9 which prefixes the ALIGN macro with
>>> FFI_ for all ports.
>>>
>>> These patches, with the exception of the softfloat one, have been used
>>> on the Debian GCC packages for quite some time.
>>>
>>> libffi/Changelog:
>>>
>>> 2019-08-05  Aurelien Jarno  
>>>
>>> Import from upstream
>>> * src/mips/ffi.c (ffi_call_O32, ffi_call_N32,
>>> ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust
>>> interface.
>>> (ffi_call_int): Renamed from ffi_call.
>>> (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions.
>>> (ffi_prep_closure_loc): Define jr instruction for R6.
>>> * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define.
>>> (FFI_TRAMPOLINE_SIZE): Define to 56 for N64.
>>> Test for __linux__ instead of linux.
>>> * src/mips/n32.S (ffi_go_closure_N32): New function.
>>> (ffi_call_N32): Adjust code for softfloat.
>>> (.set mips4): Guard with !defined(__mips_isa_rev) ||
>>> (__mips_isa_rev<6).
>>> * src/mips/o32.S (ffi_go_closure_O32): New function.
>>> (ffi_call_O32): Adjust code for softfloat.
>> What's the motivation here?
> 
> The original motivation is that it improves go support on MIPS in
> general and fixes it on MIPS R6.
> 
> The more recent motivation is that Debian has been patching GCC with
> those changes for quite some time, however we are now requested that
> those patches are merged upstream.
Understood.

> 
>> Would we just be better off moving all of libffi forward rather than
>> just MIPS bits?
> 
> Looking at the history, each port has be doing its own sync from libffi.
> Now I agree with you that if possible, moving all of libffi forward
> looks like a good idea.
If we still need libffi, this would be my preference...  But...

>  
>> Do we even still need a bundled libffi in GCC anymore?
> 
> The issue might be that the last libffi release has been done 5 years
> ago, and most of the recent commits done in the libffi/ directory are
> not present in a released version of libffi.
> 
> Otherwise I do not have idea if it is feasible to use the shared libffi
> library.
My point is I'm not even sure we're using libffi within gcc anymore.  I
know we used it for Java bits, but that was killed some time ago.  Some
quick grepping for lffi, ffi.h and ffitarget.h aren't turning up
anything outside the libffi directory itself.  So I really question if
we still need it at all within gcc.

jeff



Re: [PATCH] Sync MIPS support from libffi master repository

2019-08-08 Thread Aurelien Jarno
On 2019-08-08 14:41, Jeff Law wrote:
> On 8/5/19 2:33 PM, Aurelien Jarno wrote:
> > This updates the libffi MIPS support up to commit 746dbe3a6a79, with the
> > exception of commit bd72848c7af9 which prefixes the ALIGN macro with
> > FFI_ for all ports.
> > 
> > These patches, with the exception of the softfloat one, have been used
> > on the Debian GCC packages for quite some time.
> > 
> > libffi/Changelog:
> > 
> > 2019-08-05  Aurelien Jarno  
> > 
> > Import from upstream
> > * src/mips/ffi.c (ffi_call_O32, ffi_call_N32,
> > ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust
> > interface.
> > (ffi_call_int): Renamed from ffi_call.
> > (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions.
> > (ffi_prep_closure_loc): Define jr instruction for R6.
> > * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define.
> > (FFI_TRAMPOLINE_SIZE): Define to 56 for N64.
> > Test for __linux__ instead of linux.
> > * src/mips/n32.S (ffi_go_closure_N32): New function.
> > (ffi_call_N32): Adjust code for softfloat.
> > (.set mips4): Guard with !defined(__mips_isa_rev) ||
> > (__mips_isa_rev<6).
> > * src/mips/o32.S (ffi_go_closure_O32): New function.
> > (ffi_call_O32): Adjust code for softfloat.
> What's the motivation here?

The original motivation is that it improves go support on MIPS in
general and fixes it on MIPS R6.

The more recent motivation is that Debian has been patching GCC with
those changes for quite some time, however we are now requested that
those patches are merged upstream.

> Would we just be better off moving all of libffi forward rather than
> just MIPS bits?

Looking at the history, each port has be doing its own sync from libffi.
Now I agree with you that if possible, moving all of libffi forward
looks like a good idea.
 
> Do we even still need a bundled libffi in GCC anymore?

The issue might be that the last libffi release has been done 5 years
ago, and most of the recent commits done in the libffi/ directory are
not present in a released version of libffi.

Otherwise I do not have idea if it is feasible to use the shared libffi
library.


Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


Re: [PATCH] Add --with-static-standard-libraries to the top level

2019-08-08 Thread Jeff Law
On 8/5/19 12:02 PM, Tom Tromey wrote:
> gdb should normally not be linked with -static-libstdc++.  Currently
> this has not caused problems, but it's incompatible with catching an
> exception thrown from a shared library -- and a subsequent patch
> changes gdb to do just this.
> 
> This patch adds a new --with-static-standard-libraries flag to the
> top-level configure.  It defaults to "auto", which means enabled if
> gcc is being built, and disabled otherwise.
> 
> Tom
> 
> 2019-07-27  Tom Tromey  
> 
>   * configure: Rebuild.
>   * configure.ac: Add --with-static-standard-libraries.
Deferring to Jon.

It might be worth reviewing:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56750

And this thread:

> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00403.html

While I NAK'd Aldy's patch in the email thread, if Jon thinks we should
have this capability I won't object.


jeff


[Bug target/47779] Problem cross-compiling trunk for bfin

2019-08-08 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47779

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Per c#7.

Re: [PATCH] Sync MIPS support from libffi master repository

2019-08-08 Thread Jeff Law
On 8/5/19 2:33 PM, Aurelien Jarno wrote:
> This updates the libffi MIPS support up to commit 746dbe3a6a79, with the
> exception of commit bd72848c7af9 which prefixes the ALIGN macro with
> FFI_ for all ports.
> 
> These patches, with the exception of the softfloat one, have been used
> on the Debian GCC packages for quite some time.
> 
> libffi/Changelog:
> 
> 2019-08-05  Aurelien Jarno  
> 
>   Import from upstream
>   * src/mips/ffi.c (ffi_call_O32, ffi_call_N32,
>   ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust
>   interface.
>   (ffi_call_int): Renamed from ffi_call.
>   (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions.
>   (ffi_prep_closure_loc): Define jr instruction for R6.
>   * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define.
>   (FFI_TRAMPOLINE_SIZE): Define to 56 for N64.
>   Test for __linux__ instead of linux.
>   * src/mips/n32.S (ffi_go_closure_N32): New function.
>   (ffi_call_N32): Adjust code for softfloat.
>   (.set mips4): Guard with !defined(__mips_isa_rev) ||
>   (__mips_isa_rev<6).
>   * src/mips/o32.S (ffi_go_closure_O32): New function.
>   (ffi_call_O32): Adjust code for softfloat.
What's the motivation here?

Would we just be better off moving all of libffi forward rather than
just MIPS bits?

Do we even still need a bundled libffi in GCC anymore?


Jeff


Re: Use predicates for RTL objects

2019-08-08 Thread Jeff Law
On 8/8/19 12:46 PM, Jakub Jelinek wrote:
> On Thu, Aug 08, 2019 at 02:35:27PM -0400, Arvind Sankar wrote:
>> Surely there's general agreement on using REG_P etc? I don't see anyone
> 
> No objections from me for using REG_P and other *_P macros more.
Right.  These are convenience macros and I think they're generally a
good thing.  Other good examples would be things like POINTER_TYPE_P
which accepts POINTER_TYPE or REFERENCE type -- it's way to easy to do
something like TREE_TYPE (x) == POINTER_TYPE and thus miss handling
reference types.


> 
>> objecting to it, and that's all the patchset does: to avoid any
>> confusion the second half of the email asking about opinions on is_a is
>> entirely independent from the first half describing the existing patchset.
> 
> My comment was mainly targetted at the ->is_a stuff, but also a general
> comment that having something written in some wiki doesn't mean there is
> agreement on it.
Agreed on both points.

jeff


Re: Use predicates for RTL objects

2019-08-08 Thread Jeff Law
On 8/8/19 11:42 AM, Arvind Sankar wrote:
> On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote:
>> On Wed, Aug 07, 2019 at 02:58:12PM -0400, Arvind Sankar wrote:
>> code does is cheap.  With "x->is_a (PLUS)", who knows what is happening
 That's not my point -- my point was that it is *obvious* the way things
 are now, which is nice.
>>>
>>> My reply is pointing out that it is just as (non-)obvious with or
>>> without that inline function, if you want to use any of the helper
>>> macros.
>>
>> But that is not what you suggested, or at least not how I read it.
>>   x->is_a (PLUS)
>> is not obviously cheap or simple at all, while
>>   GET_CODE (x) == PLUS
>> obviously *is*.
>>
>> The former also isn't readable.
> 
> That's a matter of what style you prefer and it seems like no-one else
> shares my preference, and I accept that we're not going to make such a
> change.
> 
> But there is really nothing more or less obvious about it. It's easy to
> go look at the code, as you probably once did when checking what
> GET_CODE or REG_P actually did, and is_a methods are expected to be
> lightweight. Regarding hiding things, consider that we just added
> LABEL_REF_P, which is for a comparison that happens less than half as
> often as PLUS in the codebase (and I think it was actually only
> used in one place). It was done presumably because the author/reviewers
> felt that LABEL_REF_P (x) is more readable than GET_CODE (x) == LABEL_REF, 
> even if the latter might be ever so slightly more transparent as to what
> its doing than the former.
I think what Segher is referring to is that GCC developers should know
that GET_CODE is just x->code, ie, a single dereference, similarly for
other RTL/TREE accessors.  A function call (or something that looks like
a function call) has traditionally been reserved for things that are
less performance sensitive and could be doing more work within GCC.

But those are merely conventions and ones that we've had in this project
for 30+ years and are to some degree driven by the C language as it
stood in the 80s.   We're not as strict about those conventions as we've
been in the past, but I don't think we're ready to throw them totally
out the window.

There's nothing *inherently* cheaper about either form.  Both could be
used in either way.

Jeff



[Bug c++/91394] C++ ABI incompatibility (stdexcept)

2019-08-08 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
Forwards compatible is not guaranteed; only backwards compatible.
That is you can compile with X and run with (X+1) libraries but not the
opposite way around.  This is true with almost all software including but not
limited to GLIBC, GCC, libstdc++ (and even Windows).

Re: Use predicates for RTL objects

2019-08-08 Thread Jeff Law
On 8/8/19 11:06 AM, Arvind Sankar wrote:
> On Thu, Aug 08, 2019 at 08:31:28AM -0600, Jeff Law wrote:
>> True, but they could be.  When David was working in this space a few
>> years ago I concluded that the main value in sub-classing the various
>> RTL operators just wansn't worth the effort.  Instead we focused on
>> starting to tear apart things like the toplevel objects into rtx_insn
>> and the like.  THere's little value in treating those as simple RTXs.
>> INSN_LIST and the like were also ripe for this treatment.
>>
>> The biggest value in making a real class for the operators things would
>> be to move the runtime RTL checking into a compile-time check.  But I
>> couldn't really green light something like that without first completing
>> the rtx_insn changes.
> 
> Are there any notes or old discussion threads on what remains? I would
> be interested in taking a look if no-one else is.
I don't recall if that discussion was internal or external.  If the
latter, then it'd be in the gcc-patches archives.

Jeff


[Bug libgcc/91379] internal compiler error __gcov_fork

2019-08-08 Thread cbunch at cfhp dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91379

--- Comment #4 from Clinton Bunch  ---
Setting the CFLAGS and CXXFLAGS to -O0 -g as suggested didn't help. It still
blew up at the same point building libgcc.

  Interestingly, I noticed that it doesn't blow up if the code is compiled in
-mlp64 mode, only in the default -milp32 mode.  The process successfully builds
a 64-bit libgcc_s.so

Re: Expansion of narrowing math built-ins into power instructions

2019-08-08 Thread Segher Boessenkool
Hi!

On Fri, Aug 09, 2019 at 12:14:54AM +0530, Tejas Joshi wrote:
> > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> > which could be extended to allow DF inputs with an SF output; it doesn't
> > yet allow it.
> 
> This might be very lousy but I am confused with the optabs and insn
> name rn, the comments in obtabs.def says that these patterns are
> present in md as insn names. How can fadd function be mapped with the
> "fadd3_fpr" pattern name?

The actual name starts with an asterisk, which means as it is it can
never be used by name.  But, right above this pattern, there is the
define_expand named add3 (for modes SFDF).

These current patterns all take the same mode for all inputs and outputs
(that's what 3 indicates, say, fadddf3).  You will need to define
something that takes two SFs in and produces a DF.  That cannot really
be in this same pattern, it needs a float_extend added (you can do all
kinds of trickery, but just adding a few extra patterns is much easier
than define_subst and whatnot).

> Also, faddl and daddl functions take long double as argument, can they
> also be expanded on DF to SF mode or only on QP float on power9?

We can have three different long double modes on powerpc: DP float, QP
float, or "IBM long double", also known as "double double", which is
essentially the sum of two double precision numbers.

Types (a source level construct) are not the same as modes (an RTL
concept).


Segher


Re: Indirect memory addresses vs. lra

2019-08-08 Thread Jeff Law
On 8/8/19 1:19 PM, Segher Boessenkool wrote:
> On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote:
>>
>>
>>> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool  
>>> wrote:
>>>
>>> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
> The old reload (reload[1].c) supports such addressing.  As modern 
> mainstream architectures have no this kind of addressing, it was not 
> implemented in LRA.

 Is LRA only intended for "modern mainstream architectures"?
>>>
>>> I sure hope not!  But it has only been *used* and *tested* much on such,
>>> so far. 
>>
>> That's not entirely accurate.  At the prodding of people pushing for
>> the removal of CC0 and reload, I've added LRA support to pdp11 in the
>> V9 cycle.
> 
> I said "much" :-)
> 
> Pretty much all design input so far has been from "modern mainstream
> architectures", as far as I can make out.  Now one of those has the
> most "interesting" (for RA) features that many less mainstream archs
> have (a not-so-very-flat register file), so it should still work pretty
> well hopefully.
Yea, it's certainly designed with the more mainstream architectures in
mind.  THe double-indirect case that's being talked about here is well
out of the mainstream and not a feature of anything LRA has targetted to
date.  So I'm not surprised it's not working.

My suggestion would be to ignore the double-indirect aspect of the
architecture right now, get the port working, then come back and try to
make double-indirect addressing modes work.

> 
>> And it works pretty well, in the sense of passing the
>> compile tests.  But I haven't yet examined the code quality vs. the
>> old one in any detail.
> 
> That would be quite interesting to see, also for the other ports that
> still need conversion: how much (if any) degradation should you expect
> from a straight-up conversion of a port to LRA, without any retuning?
I did the v850 last year where it was a wash or perhaps a slight
improvement for codesize, which is a reasonable approximation for
performance on that target.

I was working a bit on converting the H8 away from cc0 with an eye
towards LRA as well.  Given how registers overlap on the H8, the most
straightforward port should end up with properties much like 32bit x86.
  I suspect the independent addressing of the high/low register parts
might be better handled by LRA, but I wasn't going to do anything beyond
the "just make it work".

jeff


[PATCH 1/2] rs6000: Use iterators in more DFP patterns

2019-08-08 Thread Segher Boessenkool
I noticed some patterns in dfp.md could use the D64_D128 iterator but
don't yet.  This converts all remaining simple cases.

Tested on powerpc64-linux {-m32,-m64}; committing to trunk.


Segher


2019-08-08  Segher Boessenkool  

* config/rs6000/dfp.md (D64_D128): Move earlier in the file.
(dfp_suffix): Ditto.
(a3, addtd3): Merge to ...
(add3 for D64_D128): ... this.
(subdd3, subtd3): Merge to ...
(sub3 for D64_D128): ... this.
(muldd3, multd3): Merge to ...
(mul3 for D64_D128): ... this.
(divdd3, divtd3): Merge to ...
(div3 for D64_D128): ... this.
(*cmpdd_internal1, *cmptd_internal1): Merge to ...
(*cmp_internal1 for D64_D128): ... this.
(ftruncdd2, ftrunctd2): Merge to ...
(ftrunc2 for D64_D128): ... this.
(fixdddi2, fixtddi2): Merge to ...
(fixdi2 for D64_D128): ... this.

---
 gcc/config/rs6000/dfp.md | 138 ++-
 1 file changed, 39 insertions(+), 99 deletions(-)

diff --git a/gcc/config/rs6000/dfp.md b/gcc/config/rs6000/dfp.md
index 1b238d2..61ede5d 100644
--- a/gcc/config/rs6000/dfp.md
+++ b/gcc/config/rs6000/dfp.md
@@ -28,6 +28,12 @@ (define_c_enum "unspec"
UNSPEC_MOVSD_STORE
   ])
 
+; Either of the two decimal modes.
+(define_mode_iterator D64_D128 [DD TD])
+
+(define_mode_attr dfp_suffix [(DD "")
+ (TD "q")])
+
 
 (define_insn "movsd_store"
   [(set (match_operand:DD 0 "nonimmediate_operand" "=m")
@@ -150,84 +156,44 @@ (define_insn "trunctddd2"
   [(set_attr "type" "dfp")
(set_attr "length" "8")])
 
-(define_insn "a3"
-  [(set (match_operand:DD 0 "gpc_reg_operand" "=d")
-   (plus:DD (match_operand:DD 1 "gpc_reg_operand" "%d")
-(match_operand:DD 2 "gpc_reg_operand" "d")))]
+(define_insn "add3"
+  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
+   (plus:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "%d")
+  (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "dadd %0,%1,%2"
+  "dadd %0,%1,%2"
   [(set_attr "type" "dfp")])
 
-(define_insn "addtd3"
-  [(set (match_operand:TD 0 "gpc_reg_operand" "=d")
-   (plus:TD (match_operand:TD 1 "gpc_reg_operand" "%d")
-(match_operand:TD 2 "gpc_reg_operand" "d")))]
+(define_insn "sub3"
+  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
+   (minus:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "d")
+   (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "daddq %0,%1,%2"
+  "dsub %0,%1,%2"
   [(set_attr "type" "dfp")])
 
-(define_insn "subdd3"
-  [(set (match_operand:DD 0 "gpc_reg_operand" "=d")
-   (minus:DD (match_operand:DD 1 "gpc_reg_operand" "d")
- (match_operand:DD 2 "gpc_reg_operand" "d")))]
+(define_insn "mul3"
+  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
+   (mult:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "%d")
+  (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "dsub %0,%1,%2"
+  "dmul %0,%1,%2"
   [(set_attr "type" "dfp")])
 
-(define_insn "subtd3"
-  [(set (match_operand:TD 0 "gpc_reg_operand" "=d")
-   (minus:TD (match_operand:TD 1 "gpc_reg_operand" "d")
- (match_operand:TD 2 "gpc_reg_operand" "d")))]
+(define_insn "div3"
+  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
+   (div:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "d")
+ (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "dsubq %0,%1,%2"
+  "ddiv %0,%1,%2"
   [(set_attr "type" "dfp")])
 
-(define_insn "muldd3"
-  [(set (match_operand:DD 0 "gpc_reg_operand" "=d")
-   (mult:DD (match_operand:DD 1 "gpc_reg_operand" "%d")
-(match_operand:DD 2 "gpc_reg_operand" "d")))]
-  "TARGET_DFP"
-  "dmul %0,%1,%2"
-  [(set_attr "type" "dfp")])
-
-(define_insn "multd3"
-  [(set (match_operand:TD 0 "gpc_reg_operand" "=d")
-   (mult:TD (match_operand:TD 1 "gpc_reg_operand" "%d")
-(match_operand:TD 2 "gpc_reg_operand" "d")))]
-  "TARGET_DFP"
-  "dmulq %0,%1,%2"
-  [(set_attr "type" "dfp")])
-
-(define_insn "divdd3"
-  [(set (match_operand:DD 0 "gpc_reg_operand" "=d")
-   (div:DD (match_operand:DD 1 "gpc_reg_operand" "d")
-   (match_operand:DD 2 "gpc_reg_operand" "d")))]
-  "TARGET_DFP"
-  "ddiv %0,%1,%2"
-  [(set_attr "type" "dfp")])
-
-(define_insn "divtd3"
-  [(set (match_operand:TD 0 "gpc_reg_operand" "=d")
-   (div:TD (match_operand:TD 1 "gpc_reg_operand" "d")
-   (match_operand:TD 2 "gpc_reg_operand" "d")))]
-  "TARGET_DFP"
-  "ddivq %0,%1,%2"
-  [(set_attr "type" "dfp")])
-
-(define_insn "*cmpdd_internal1"
+(define_insn "*cmp_internal1"
   [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
-   (compare:CCFP (match_operand:DD 1 "gpc_reg_operand" "d")
- (match_operand:DD 2 

[PATCH 2/2] rs6000: Rename DFP iterator and attr to DDTD and q

2019-08-08 Thread Segher Boessenkool
This is more in line with the other iterators we have, and a bit easier
to read and write.

Tested on powerpc64-linux {-m32,-m64}; committing to trunk.


Segher


2019-08-08  Segher Boessenkool  

* config/rs6000/dfp.md (D64_D128): Rename to ...
(DDTD): ... this, throughout.
(dfp_suffix): Rename to ...
(q): ... this, throughout.

---
 gcc/config/rs6000/dfp.md | 130 +++
 1 file changed, 63 insertions(+), 67 deletions(-)

diff --git a/gcc/config/rs6000/dfp.md b/gcc/config/rs6000/dfp.md
index 61ede5d..659b3c9 100644
--- a/gcc/config/rs6000/dfp.md
+++ b/gcc/config/rs6000/dfp.md
@@ -29,10 +29,9 @@ (define_c_enum "unspec"
   ])
 
 ; Either of the two decimal modes.
-(define_mode_iterator D64_D128 [DD TD])
+(define_mode_iterator DDTD [DD TD])
 
-(define_mode_attr dfp_suffix [(DD "")
- (TD "q")])
+(define_mode_attr q [(DD "") (TD "q")])
 
 
 (define_insn "movsd_store"
@@ -157,43 +156,43 @@ (define_insn "trunctddd2"
(set_attr "length" "8")])
 
 (define_insn "add3"
-  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
-   (plus:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "%d")
-  (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
+  [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
+   (plus:DDTD (match_operand:DDTD 1 "gpc_reg_operand" "%d")
+  (match_operand:DDTD 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "dadd %0,%1,%2"
+  "dadd %0,%1,%2"
   [(set_attr "type" "dfp")])
 
 (define_insn "sub3"
-  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
-   (minus:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "d")
-   (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
+  [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
+   (minus:DDTD (match_operand:DDTD 1 "gpc_reg_operand" "d")
+   (match_operand:DDTD 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "dsub %0,%1,%2"
+  "dsub %0,%1,%2"
   [(set_attr "type" "dfp")])
 
 (define_insn "mul3"
-  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
-   (mult:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "%d")
-  (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
+  [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
+   (mult:DDTD (match_operand:DDTD 1 "gpc_reg_operand" "%d")
+  (match_operand:DDTD 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "dmul %0,%1,%2"
+  "dmul %0,%1,%2"
   [(set_attr "type" "dfp")])
 
 (define_insn "div3"
-  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
-   (div:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "d")
- (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
+  [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
+   (div:DDTD (match_operand:DDTD 1 "gpc_reg_operand" "d")
+ (match_operand:DDTD 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "ddiv %0,%1,%2"
+  "ddiv %0,%1,%2"
   [(set_attr "type" "dfp")])
 
 (define_insn "*cmp_internal1"
   [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
-   (compare:CCFP (match_operand:D64_D128 1 "gpc_reg_operand" "d")
- (match_operand:D64_D128 2 "gpc_reg_operand" "d")))]
+   (compare:CCFP (match_operand:DDTD 1 "gpc_reg_operand" "d")
+ (match_operand:DDTD 2 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "dcmpu %0,%1,%2"
+  "dcmpu %0,%1,%2"
   [(set_attr "type" "dfp")])
 
 (define_insn "floatdidd2"
@@ -214,10 +213,10 @@ (define_insn "floatditd2"
 ;; This is the first stage of converting it to an integer type.
 
 (define_insn "ftrunc2"
-  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
-   (fix:D64_D128 (match_operand:D64_D128 1 "gpc_reg_operand" "d")))]
+  [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
+   (fix:DDTD (match_operand:DDTD 1 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "drintn. 0,%0,%1,1"
+  "drintn. 0,%0,%1,1"
   [(set_attr "type" "dfp")])
 
 ;; Convert a decimal64/128 whose value is an integer to an actual integer.
@@ -225,9 +224,9 @@ (define_insn "ftrunc2"
 
 (define_insn "fixdi2"
   [(set (match_operand:DI 0 "gpc_reg_operand" "=d")
-   (fix:DI (match_operand:D64_D128 1 "gpc_reg_operand" "d")))]
+   (fix:DI (match_operand:DDTD 1 "gpc_reg_operand" "d")))]
   "TARGET_DFP"
-  "dctfix %0,%1"
+  "dctfix %0,%1"
   [(set_attr "type" "dfp")])
 
 ;; Decimal builtin support
@@ -244,64 +243,61 @@ (define_c_enum "unspec"
 (define_code_iterator DFP_TEST [eq lt gt unordered])
 
 (define_insn "dfp_ddedpd_"
-  [(set (match_operand:D64_D128 0 "gpc_reg_operand" "=d")
-   (unspec:D64_D128 [(match_operand:QI 1 "const_0_to_3_operand" "i")
- (match_operand:D64_D128 2 "gpc_reg_operand" "d")]
-UNSPEC_DDEDPD))]
+  [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
+   (unspec:DDTD [(match_operand:QI 1 "const_0_to_3_operand" "i")
+ 

[Bug c++/91405] [concepts] internal compiler error: in synthesize_implicit_template_parm, at cp/parser.c:41206

2019-08-08 Thread kingoipo at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91405

--- Comment #1 from Michael de Lang  ---
Correction, the reported line number for 7.4.0 is cp.parser.c:38874

[Bug c++/91405] New: [concepts] internal compiler error: in synthesize_implicit_template_parm, at cp/parser.c:41206

2019-08-08 Thread kingoipo at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91405

Bug ID: 91405
   Summary: [concepts] internal compiler error: in
synthesize_implicit_template_parm, at
cp/parser.c:41206
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kingoipo at gmail dot com
  Target Milestone: ---

Created attachment 46691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46691=edit
Wrong usage of concepts leads to ICE

The compiler ICE's on the attached file. There are some simular bug reports
which might be the same problem or a related one, but they report a different
parser.c line.

I believe the code is incorrect and would have expected an error message like
"cannot use concept as type specifier, use template arguments instead". But it
gives an ICE.

The error happens with both g++ 7.4.0 and 9.1.0, using -fconcepts and latest
supported std version.

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

2019-08-08 Thread Marek Polacek
On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
> On 8/6/19 3:20 PM, Marek Polacek wrote:
> > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote:
> > > On 7/31/19 3:26 PM, Marek Polacek wrote:
> > > > One of the features of constexpr is that it doesn't allow UB; and such 
> > > > UB must
> > > > be detected at compile-time.  So running your code in a context that 
> > > > requires
> > > > a constant expression should ensure that the code in question is free 
> > > > of UB.
> > > > In effect, constexpr can serve as a sanitizer.  E.g. this article 
> > > > describes in
> > > > in more detail:
> > > > 
> > > > 
> > > > [dcl.type.cv]p4 says "Any attempt to modify a const object during its 
> > > > lifetime
> > > > results in undefined behavior." However, as the article above points 
> > > > out, we
> > > > aren't detecting that case in constexpr evaluation.
> > > > 
> > > > This patch fixes that.  It's not that easy, though, because we have to 
> > > > keep in
> > > > mind [class.ctor]p5:
> > > > "A constructor can be invoked for a const, volatile or const volatile 
> > > > object.
> > > > const and volatile semantics are not applied on an object under 
> > > > construction.
> > > > They come into effect when the constructor for the most derived object 
> > > > ends."
> > > > 
> > > > I handled this by keeping a hash set which tracks objects under 
> > > > construction.
> > > > I considered other options, such as going up call_stack, but that 
> > > > wouldn't
> > > > work with trivial constructor/op=.  It was also interesting to find out 
> > > > that
> > > > the definition of TREE_HAS_CONSTRUCTOR says "When appearing in a 
> > > > FIELD_DECL,
> > > > it means that this field has been duly initialized in its constructor" 
> > > > though
> > > > nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR on a FIELD_DECL 
> > > > as far
> > > > as I can see.  Unfortunately, using this bit proved useless for my 
> > > > needs here.
> > > 
> > > > Also, be mindful of mutable subobjects.
> > > > 
> > > > Does this approach look like an appropriate strategy for tracking 
> > > > objects'
> > > > construction?
> > > 
> > > For scalar objects, we should be able to rely on INIT_EXPR vs. MODIFY_EXPR
> > > to distinguish between initialization and modification; for class 
> > > objects, I
> > 
> > This is already true: only class object go into the hash set.
> > 
> > > wonder about setting a flag on the CONSTRUCTOR after initialization is
> > > complete to indicate that the value is now constant.
> > 
> > But here we're not dealing with CONSTRUCTORs in the gcc sense (i.e. exprs 
> > with
> > TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y ((struct Y *) ),
> > which initializes the object "y".  Setting a flag on the CALL_EXPR or its 
> > underlying
> > function decl wouldn't help.
> > 
> > Am I missing something?
> 
> I was thinking that where in your current patch you call
> remove_object_under_construction, we could instead mark the object's value
> CONSTRUCTOR as immutable.

Ah, what you meant was to look at DECL_INITIAL of the object we're
constructing, which could be a CONSTRUCTOR.  Unfortunately, this
DECL_INITIAL is null (in all the new tests when doing
remove_object_under_construction), so there's nothing to mark as TREE_READONLY 
:/.

Marek


[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

2019-08-08 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227

--- Comment #19 from Martin Sebor  ---
That's a valid concern.  Issuing a warning (either at the same time as or in
lieu of the folding) would be a way to detect and prevent these kinds of
problems.  Exposing it to enough code (like in a whole distro rebuild) would
give us a pretty good idea about what the appropriate defaults ought to be.

Re: Indirect memory addresses vs. lra

2019-08-08 Thread Segher Boessenkool
On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote:
> 
> 
> > On Aug 8, 2019, at 1:21 PM, Segher Boessenkool  
> > wrote:
> > 
> > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
> >>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
> >>> The old reload (reload[1].c) supports such addressing.  As modern 
> >>> mainstream architectures have no this kind of addressing, it was not 
> >>> implemented in LRA.
> >> 
> >> Is LRA only intended for "modern mainstream architectures"?
> > 
> > I sure hope not!  But it has only been *used* and *tested* much on such,
> > so far. 
> 
> That's not entirely accurate.  At the prodding of people pushing for
> the removal of CC0 and reload, I've added LRA support to pdp11 in the
> V9 cycle.

I said "much" :-)

Pretty much all design input so far has been from "modern mainstream
architectures", as far as I can make out.  Now one of those has the
most "interesting" (for RA) features that many less mainstream archs
have (a not-so-very-flat register file), so it should still work pretty
well hopefully.

> And it works pretty well, in the sense of passing the
> compile tests.  But I haven't yet examined the code quality vs. the
> old one in any detail.

That would be quite interesting to see, also for the other ports that
still need conversion: how much (if any) degradation should you expect
from a straight-up conversion of a port to LRA, without any retuning?


Segher


Re: Indirect memory addresses vs. lra

2019-08-08 Thread Segher Boessenkool
On Thu, Aug 08, 2019 at 01:25:27PM -0400, Paul Koning wrote:
> > On Aug 8, 2019, at 1:21 PM, Segher Boessenkool  
> > wrote:
> > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
> >> Indirect addressing is a key feature in size-optimized code.
> > 
> > That doesn't mean that LRA has to support it, btw, not necessarily; it
> > may well be possible to do a good job of this in the later passes?
> > Maybe postreload, maybe some peepholes, etc.?
> 
> Possibly.  But as Vladimir points out, indirect addressing affects
> register allocation (reducing register pressure).

Yeah, good point, esp. if you have only one or two registers that you
can use for addressing at all.  So it will have to happen during (or
before?) RA, alright.


Segher


[Bug target/91229] RISC-V ABI problem with zero-length bit-fields and float struct fields

2019-08-08 Thread wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229

Jim Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jim Wilson  ---
Fixed on mainline.

[Bug target/91229] RISC-V ABI problem with zero-length bit-fields and float struct fields

2019-08-08 Thread wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229

--- Comment #3 from Jim Wilson  ---
Author: wilson
Date: Thu Aug  8 19:04:56 2019
New Revision: 274215

URL: https://gcc.gnu.org/viewcvs?rev=274215=gcc=rev
Log:
RISC-V: Fix C ABI for flattened struct with 0-length bitfield.

gcc/
PR target/91229
* config/riscv/riscv.c (riscv_flatten_aggregate_field): New arg
ignore_zero_width_bit_field_p.  Skip zero size bitfields when true.
Pass into recursive call.
(riscv_flatten_aggregate_argument): New arg.  Pass to
riscv_flatten_aggregate_field.
(riscv_pass_aggregate_in_fpr_pair_p): New local warned.  Call
riscv_flatten_aggregate_argument twice, with false and true as last
arg.  Process result twice.  Compare results and warn if different.
(riscv_pass_aggregate_in_fpr_and_gpr_p): Likewise.

gcc/testsuite/
* gcc.target/riscv/flattened-struct-abi-1.c: New test.
* gcc.target/riscv/flattened-struct-abi-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/riscv/flattened-struct-abi-1.c
trunk/gcc/testsuite/gcc.target/riscv/flattened-struct-abi-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/riscv/riscv.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91403] GCC fails with ICE.

2019-08-08 Thread belyshev at depni dot sinp.msu.ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403

Serge Belyshev  changed:

   What|Removed |Added

 CC||belyshev at depni dot 
sinp.msu.ru

--- Comment #2 from Serge Belyshev  ---
Crashes here in predcom:

Program received signal SIGSEGV, Segmentation fault.
...
(gdb) bt -100
...
#662173 0x012f7c09 in follow_ssa_edge (loop=0x778cd000,
def=0x7fffd8be5160, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1350
#662174 0x012f6f22 in follow_ssa_edge_binary (loop=0x778cd000,
at_stmt=0x7fffd8be51b8, type=0x778c31f8, rhs0=0x7fffd8be6120,
code=POINTER_PLUS_EXPR, rhs1=0x77775d38, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:947
#662175 0x012f769e in follow_ssa_edge_in_rhs (loop=0x778cd000,
stmt=0x7fffd8be51b8, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1135
#662176 0x012f7c09 in follow_ssa_edge (loop=0x778cd000,
def=0x7fffd8be51b8, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1350
#662177 0x012f6f22 in follow_ssa_edge_binary (loop=0x778cd000,
at_stmt=0x778ccf20, type=0x778c31f8, rhs0=0x7fffd8be61b0,
code=POINTER_PLUS_EXPR, rhs1=0x77775d38, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:947
#662178 0x012f769e in follow_ssa_edge_in_rhs (loop=0x778cd000,
stmt=0x778ccf20, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1135
#662179 0x012f7c09 in follow_ssa_edge (loop=0x778cd000,
def=0x778ccf20, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1350
#662180 0x012f812d in analyze_evolution_in_loop
(loop_phi_node=0x778d4200, init_cond=0x778ce0d8) at
../../gcc/gcc/tree-scalar-evolution.c:1467
#662181 0x012f864d in interpret_loop_phi (loop=0x778cd000,
loop_phi_node=0x778d4200) at ../../gcc/gcc/tree-scalar-evolution.c:1630
#662182 0x012fa1bd in analyze_scalar_evolution_1 (loop=0x778cd000,
var=0x7777fee8) at ../../gcc/gcc/tree-scalar-evolution.c:2044
#662183 0x012fa393 in analyze_scalar_evolution (loop=0x778cd000,
var=0x7777fee8) at ../../gcc/gcc/tree-scalar-evolution.c:2108
#662184 0x012fa49e in analyze_scalar_evolution_in_loop
(wrto_loop=0x778cd000, use_loop=0x778cd000, version=0x7777fee8,
folded_casts=0x7fffe0df) at ../../gcc/gcc/tree-scalar-evolution.c:2210
#662185 0x012fd082 in simple_iv_with_niters (wrto_loop=0x778cd000,
use_loop=0x778cd000, op=0x7777fee8, iv=0x7fffe280, iv_niters=0x0,
allow_nonconstant_step=true) at ../../gcc/gcc/tree-scalar-evolution.c:3288
#662186 0x012fd8e0 in simple_iv (wrto_loop=0x778cd000,
use_loop=0x778cd000, op=0x7777fee8, iv=0x7fffe280,
allow_nonconstant_step=true) at ../../gcc/gcc/tree-scalar-evolution.c:3413
#662187 0x0207e0ef in dr_analyze_innermost (drb=0x3166a50,
ref=0x778e11b8, loop=0x778cd000, stmt=0x778d8dc0) at
../../gcc/gcc/tree-data-ref.c:950
#662188 0x0207f342 in create_data_ref (nest=0x778d0f00,
loop=0x778cd000, memref=0x778e11b8, stmt=0x778d8dc0, is_read=true,
is_conditional_in_stmt=false) at ../../gcc/gcc/tree-data-ref.c:1255
#662189 0x02089d1c in find_data_references_in_stmt
(nest=0x778cd000, stmt=0x778d8dc0, datarefs=0x7fffe7f8) at
../../gcc/gcc/tree-data-ref.c:5149
#662190 0x02089f0e in find_data_references_in_bb (loop=0x778cd000,
bb=0x778da410, datarefs=0x7fffe7f8) at
../../gcc/gcc/tree-data-ref.c:5203
#662191 0x02089fce in find_data_references_in_loop
(loop=0x778cd000, datarefs=0x7fffe7f8) at
../../gcc/gcc/tree-data-ref.c:5236
#662192 0x0208a604 in compute_data_dependences_for_loop
(loop=0x778cd000, compute_self_and_read_read_dependences=true,
loop_nest=0x7fffe750, datarefs=0x7fffe7f8,
dependence_relations=0x7fffe7f0) at ../../gcc/gcc/tree-data-ref.c:5411
#662193 0x012d7b7e in tree_predictive_commoning_loop
(loop=0x778cd000) at ../../gcc/gcc/tree-predcom.c:3192
#662194 0x012d8134 in tree_predictive_commoning () at
../../gcc/gcc/tree-predcom.c:3314
#662195 0x012d81b4 in run_tree_predictive_commoning
(fun=0x778c6000) at ../../gcc/gcc/tree-predcom.c:3339
#662196 0x012d8222 in (anonymous namespace)::pass_predcom::execute
(this=0x2fc7cb0, fun=0x778c6000) at ../../gcc/gcc/tree-predcom.c:3368
#662197 0x0102b1c3 in execute_one_pass (pass=0x2fc7cb0) at

Re: Use predicates for RTL objects

2019-08-08 Thread Arvind Sankar
On Thu, Aug 08, 2019 at 01:26:42PM -0500, Segher Boessenkool wrote:
> LABEL_REF_P works out nicely because it is referring to something that
> is data, is not an operator.  "Leaves" in an RTL expression, if you want
> to look at it that way.
> 
> Predicates for other RTX codes aren't always as obvious, see CONST_P as
> example.  PLUS_P would be a bit borderline.
> 
> Part of the reason why REG_P and MEM_P and the like are nice, is that
> these predicates are often used in bigger conditions, maybe together
> with some XEXP and whatnot.  Is that the case for PLUS_P?
> 

Yes, it's used quite often in more complex conditions checking the
operands (eg to see whether they're constants), or applied to XEXP's
itself.

But I'm in agreement that PLUS_P just seems odd somehow. The leaf/data
vs operator distinction makes sense, maybe RTXOP_PLUS_P, but then you'd
want that to check if it was being called on an operator, so I don't
know if you'd do it unless/until we eventually have an rtx_op class and
have done the other bits of converting to C++.


Re: Use predicates for RTL objects

2019-08-08 Thread Jakub Jelinek
On Thu, Aug 08, 2019 at 02:35:27PM -0400, Arvind Sankar wrote:
> Surely there's general agreement on using REG_P etc? I don't see anyone

No objections from me for using REG_P and other *_P macros more.

> objecting to it, and that's all the patchset does: to avoid any
> confusion the second half of the email asking about opinions on is_a is
> entirely independent from the first half describing the existing patchset.

My comment was mainly targetted at the ->is_a stuff, but also a general
comment that having something written in some wiki doesn't mean there is
agreement on it.

Jakub


Re: Indirect memory addresses vs. lra

2019-08-08 Thread Vladimir Makarov



On 2019-08-08 12:43 p.m., Paul Koning wrote:



On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:


On 2019-08-04 3:18 p.m., John Darrington wrote:

I'm trying to write a back-end for an architecture (s12z - the ISA you can
download from [1]).  This arch accepts indirect memory addresses.   That is to
say, those of the form (mem (mem (...)))  and although my 
TARGET_LEGITIMATE_ADDRESS
function returns true for such addresses, LRA insists on reloading them out of
existence.
...

The old reload (reload[1].c) supports such addressing.  As modern mainstream 
architectures have no this kind of addressing, it was not implemented in LRA.

Is LRA only intended for "modern mainstream architectures"?



No.  As I wrote patches implementing indirect addressing is welcomed.  
It is hard to implement everything at once and by one person.




If yes, why is the old reload being deprecated?
   You can't have it both ways.  Unless you want to obsolete all "not modern 
mainstream architectures" in GCC, it doesn't make sense to get rid of core 
functionality used by those architectures.

Indirect addressing is a key feature in size-optimized code.




Re: Expansion of narrowing math built-ins into power instructions

2019-08-08 Thread Tejas Joshi
Hi.
It took some time for me to finish with the folding part for fadd
variants and till it is reviewed, I want to move ahead with power8/9
expansions on top of the current fadd patch.

> In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> which could be extended to allow DF inputs with an SF output; it doesn't
> yet allow it.

This might be very lousy but I am confused with the optabs and insn
name rn, the comments in obtabs.def says that these patterns are
present in md as insn names. How can fadd function be mapped with the
"fadd3_fpr" pattern name?
Also, faddl and daddl functions take long double as argument, can they
also be expanded on DF to SF mode or only on QP float on power9?

I have built GCC and applied my current patches on gcc112 and yes, on
gcc135 too.

Thanks,
Tejas


On Wed, 31 Jul 2019 at 20:17, Segher Boessenkool
 wrote:
>
> On Wed, Jul 31, 2019 at 12:23:18PM +0530, Tejas Joshi wrote:
> > > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> > > which could be extended to allow DF inputs with an SF output; it doesn't
> > > yet allow it.
> >
> > Thanks for the inputs, I will try to address these points now. I have
> > built GCC on gcc112 and will apply patch and test testcases there.
>
> For the QP float (binary128, KFmode, take your pick) you need Power9 or
> newer, so gcc135.
>
>
> Segher


Re: Use predicates for RTL objects

2019-08-08 Thread Arvind Sankar
On Thu, Aug 08, 2019 at 08:14:01PM +0200, Jakub Jelinek wrote:
> On Thu, Aug 08, 2019 at 01:12:33PM -0400, Arvind Sankar wrote:
> > On Thu, Aug 08, 2019 at 03:04:53PM +, Michael Matz wrote:
> > > Hi,
> > > 
> > > On Wed, 7 Aug 2019, Arvind Sankar wrote:
> > > 
> > > > => x->is_a (REG)
> > > 
> > > Oh god, please no.  Currently at least the RTL parts of GCC still have 
> > > mostly a consistent and obvious style, which is a good thing.  I have no 
> > > idea why anyone would think the above is easier to read than REG_P (x).
> > > 
> > > 
> > > Ciao,
> > > Michael.
> > > P.S: Consider this: the current style served us quite well for the last 
> > > 35 
> > > or so years, so before suggesting style changes, shouldn't you first work 
> > > on the sources for some time?
> > 
> > Well, the main point of the email was to ask for review of a patchset
> > that attempts to make progress on a TODO that has been outstanding for
> > at least 15 of those 35 years.
> 
> Not everything that is in some TODO list somewhere is something generally
> agreed upon.
> 
>   Jakub

Surely there's general agreement on using REG_P etc? I don't see anyone
objecting to it, and that's all the patchset does: to avoid any
confusion the second half of the email asking about opinions on is_a is
entirely independent from the first half describing the existing patchset.


[Bug tree-optimization/91403] GCC fails with ICE.

2019-08-08 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Doesn't ICE for me, but SLP during vectorization goes wild, for very short
*.ifcvt
   [local count: 12199019]:
  b_lsm.4_24 = b;

   [local count: 97603136]:
  # d_69 = PHI <2(2), d_9(5)>
  # b_lsm.4_17 = PHI 
  # ivtmp_76 = PHI <8(2), ivtmp_73(5)>
  _14 = a[d_69][5];
  _16 = _14 + b_lsm.4_17;
  _23 = _14 + _16;
  _30 = _14 + _23;
  _37 = _14 + _30;
  _44 = _14 + _37;
  _51 = _14 + _44;
  _58 = _14 + _51;
  _65 = _14 + _58;
  _72 = _14 + _65;
  _79 = _14 + _72;
  d_9 = d_69 + 1;
  ivtmp_73 = ivtmp_76 - 1;
  if (ivtmp_73 != 0)
goto ; [87.50%]
  else
goto ; [12.50%]

   [local count: 85404116]:
  goto ; [100.00%]

   [local count: 12199019]:
  # _80 = PHI <_79(3)>
  b = _80;
  return;
it creates a *.vect dump with 1860297 lines, with:
  vect__14.10_5 = MEM  [(int *)vectp_a.8_7];
  vectp_a.8_4 = vectp_a.8_7 + 32;
  vect__14.11_3 = MEM  [(int *)vectp_a.8_4];
  vectp_a.8_2 = vectp_a.8_4 + 32;
  vect__14.12_1 = MEM  [(int *)vectp_a.8_2];
  vectp_a.8_10 = vectp_a.8_2 + 32;
  vect__14.13_15 = MEM  [(int *)vectp_a.8_10];
  vectp_a.8_31 = vectp_a.8_10 + 32;
...
where there are 620046 those MEM loads that nothing consumes and 620046
additions of 32.

[Bug c++/91334] [10 Regression] ICE in propagate_necessity at gcc/tree-ssa-dce.c:813 since r273791

2019-08-08 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from H.J. Lu  ---
I opened PR 91404.

[Bug ipa/91404] New: [10 Regression] internal compiler error: Segmentation fault

2019-08-08 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91404

Bug ID: 91404
   Summary: [10 Regression] internal compiler error: Segmentation
fault
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

On x86-64, when building 483.xalancbmk in SPEC CPU 2006, r273857 caused:

$ gcc  -S -DSPEC_CPU -DNDEBUG  -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I.
-Ixercesc -Ixercesc/dom -Ixercesc/dom/impl -Ixercesc/sax
-Ixercesc/util/MsgLoaders/InMemory -Ixercesc/util/Transcoders/Iconv
-Ixalanc/include -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C
-DPROJ_SAX2 -DPROJ_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER
-DXML_USE_INMEM_MESSAGELOADER -O2-DSPEC_CPU_LP64  -DSPEC_CPU_LINUX
XPath.cpp  -ffast-math
./PlatformDefinitions.hpp:66:35: internal compiler error: Segmentation fault
   66 |  #define XALAN_CPP_NAMESPACE_END  }
  |   ^
0xfbc09f crash_signal
../../src-trunk/gcc/toplev.c:326
0xb26383 lookup_page_table_entry
../../src-trunk/gcc/ggc-page.c:632
0xb26383 ggc_set_mark(void const*)
../../src-trunk/gcc/ggc-page.c:1531
0xd69c41 gt_ggc_mx_symtab_node(void*)
/export/gnu/import/git/gcc-test-spec-lto/bld/gcc/gtype-desc.c:1302
0xee468d gt_ggc_ma_order
./gt-passes.h:31
0xee468d gt_ggc_ma_order
./gt-passes.h:26
0xcf6115 ggc_mark_root_tab
../../src-trunk/gcc/ggc-common.c:77
0xcf631c ggc_mark_roots()
../../src-trunk/gcc/ggc-common.c:94
0xb26d05 ggc_collect()
../../src-trunk/gcc/ggc-page.c:2201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

It doesn't fail with pre-processed file.

[Bug c++/91402] PowerPC unecessary -Wignored-attriubte warnings on template specialization with -mlongcall

2019-08-08 Thread andrewdkaster at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91402

--- Comment #1 from Andrew Kaster  ---
As a note, I was able to reproduce using godbolt, but they don't have very
recent versions of gcc for powerpc:

https://godbolt.org/z/20lNhf

Of the available compilers:

No warnings:
power64le clang (trunk)
powerpc64 clang (trunk)
PowerPC gcc 4.8.5

Warnings:
power64 AT 12.0
power64le AT 12.0
power64le gcc 6.3.0

Re: Use predicates for RTL objects

2019-08-08 Thread Segher Boessenkool
On Thu, Aug 08, 2019 at 01:42:40PM -0400, Arvind Sankar wrote:
> On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote:
> But there is really nothing more or less obvious about it.

That depends on what you are used to seeing, a lot.

> It's easy to
> go look at the code, as you probably once did when checking what
> GET_CODE or REG_P actually did,

It's in the documentation as well, and there are examples every tenth
line of code to look at.

> and is_a methods are expected to be
> lightweight. Regarding hiding things, consider that we just added
> LABEL_REF_P, which is for a comparison that happens less than half as
> often as PLUS in the codebase (and I think it was actually only
> used in one place). It was done presumably because the author/reviewers
> felt that LABEL_REF_P (x) is more readable than GET_CODE (x) == LABEL_REF, 
> even if the latter might be ever so slightly more transparent as to what
> its doing than the former.

LABEL_REF_P works out nicely because it is referring to something that
is data, is not an operator.  "Leaves" in an RTL expression, if you want
to look at it that way.

Predicates for other RTX codes aren't always as obvious, see CONST_P as
example.  PLUS_P would be a bit borderline.

Part of the reason why REG_P and MEM_P and the like are nice, is that
these predicates are often used in bigger conditions, maybe together
with some XEXP and whatnot.  Is that the case for PLUS_P?

> > Indirection is *the* evil in programming.
> 
> Some would say that "All problems in computer science can be solved by
> another level of indirection" ;)

Yes, and that is the problem.  :-P

Indirection doesn't solve problems, it just hides them.  Diluting your
code does not make it simpler, quite the opposite; it just makes it hard
to spot the problem parts.


Segher


[Bug tree-optimization/91403] New: GCC fails with ICE.

2019-08-08 Thread vsevolod.livinskij at frtk dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403

Bug ID: 91403
   Summary: GCC fails with ICE.
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

GCC fails with an internal compiler error. Sometimes the compilation takes
about 12 minutes before it fails. Originally the bug was reported in r91178.

Reproducer:
extern int a[][1240092];
int b;
void c() {
  for (int d = 2; d <= 9; d++)
for (int e = 32; e <= 41; e++)
  b += a[d][5];
}

Error:
>$ gcc -march=skylake-avx512 -c -O3 small.c
gcc: internal compiler error: Segmentation fault signal terminated program cc1

GCC version:
gcc version 10.0.0 (rev. 274155)

[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289

2019-08-08 Thread vsevolod.livinskij at frtk dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178

--- Comment #17 from Vsevolod Livinskiy  ---
(In reply to Serge Belyshev from comment #16)
> (In reply to Vsevolod Livinskiy from comment #15)
> > I don't know if it is the same error or not, but the reproducer looks
> > similar.
> 
> This one is different.  It does not fail for me with -O3
> -march=skylake-avx512, just slow and consumes over 1G of memory.
> 
> But with just "-O3" it blows up the stack during predictive commoning pass
> via  follow_ssa_edge tree-scalar-evolution.c:1350 --> follow_ssa_edge_in_rhs
> tree-scalar-evolution.c:1135 -->  follow_ssa_edge_binary
> tree-scalar-evolution.c:947 --> follow_ssa_edge tree-scalar-evolution.c:1350
> recursion.
> 
> Git bisect points at r256634.

Thank you! I'll open a new bug to keep them separated.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

2019-08-08 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535

--- Comment #23 from Ian Lance Taylor  ---
Look for _kern in runtime.inc.  See what struct it is part of.  The struct is
likely defined in the generated file runtime_sysinfo.go.  You may need to
modify libgo/mkrsysinfo.sh to not add that struct to runtime_sysinfo.go, or you
may need to modify mkrsysinfo.sh to define __usem2.

Re: Use predicates for RTL objects

2019-08-08 Thread Jakub Jelinek
On Thu, Aug 08, 2019 at 01:12:33PM -0400, Arvind Sankar wrote:
> On Thu, Aug 08, 2019 at 03:04:53PM +, Michael Matz wrote:
> > Hi,
> > 
> > On Wed, 7 Aug 2019, Arvind Sankar wrote:
> > 
> > >   => x->is_a (REG)
> > 
> > Oh god, please no.  Currently at least the RTL parts of GCC still have 
> > mostly a consistent and obvious style, which is a good thing.  I have no 
> > idea why anyone would think the above is easier to read than REG_P (x).
> > 
> > 
> > Ciao,
> > Michael.
> > P.S: Consider this: the current style served us quite well for the last 35 
> > or so years, so before suggesting style changes, shouldn't you first work 
> > on the sources for some time?
> 
> Well, the main point of the email was to ask for review of a patchset
> that attempts to make progress on a TODO that has been outstanding for
> at least 15 of those 35 years.

Not everything that is in some TODO list somewhere is something generally
agreed upon.

Jakub


[Bug c++/79520] Spurious caching for constexpr arguments

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79520

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Done.

[Bug c++/79520] Spurious caching for constexpr arguments

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79520

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug  8 17:54:58 2019
New Revision: 274214

URL: https://gcc.gnu.org/viewcvs?rev=274214=gcc=rev
Log:
PR c++/79520
* g++.dg/cpp1y/constexpr-79520.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-79520.C
Modified:
trunk/gcc/testsuite/ChangeLog

C++ PATCH to add test for c++/79520

2019-08-08 Thread Marek Polacek
Fixed by r255788.

Tested on x86_64-linux, applying to trunk.

2019-08-08  Marek Polacek  

PR c++/79520
* g++.dg/cpp1y/constexpr-79520.C: New test.

--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-79520.C
@@ -0,0 +1,11 @@
+// PR c++/79520
+// { dg-do compile { target c++14 } }
+
+constexpr int f(int const& x) { return x; }
+
+constexpr struct S {
+int x = 0;
+constexpr S() {(void)f(x); x = 1;}
+} s;
+
+static_assert(f(s.x) == 1, "");


[Bug c++/91402] New: PowerPC unecessary -Wignored-attriubte warnings on template specialization with -mlongcall

2019-08-08 Thread andrewdkaster at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91402

Bug ID: 91402
   Summary: PowerPC unecessary -Wignored-attriubte warnings on
template specialization with -mlongcall
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewdkaster at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: powerpc-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 46690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46690=edit
Reproducer

When using the option -mlongcall for powerpc, g++ appears to treat my template
parameter for my template specialization as a function declaration and add the
longcall attribute, which then is later ignored and generates a warning.

~: powerpc-linux-gnu-g++ -mlongcall -Wall -Wextra -c test.cpp -o test.o
test.cpp:5:15: warning: ignoring attributes on template argument ‘R(A)’
[-Wignored-attributes]
 struct S  {};
   ^
test.cpp:11:18: warning: ignoring attributes on template argument ‘Ret(Arg)’
[-Wignored-attributes]
 struct D {
  ^
I am using this class to wrap a generic delegate, per the second example.

Tested on Ubuntu 18.04.03, powerpc-linux-gnu-g++ version 7.4.0

~: powerpc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=powerpc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/powerpc-linux-gnu/7/lto-wrapper
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --enable-secureplt --disable-softfloat --with-cpu=default32
--disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux
--enable-multiarch --disable-werror --with-long-double-128 --enable-multilib
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=powerpc-linux-gnu --program-prefix=powerpc-linux-gnu-
--includedir=/usr/powerpc-linux-gnu/include
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)


The same results happen when using a version of g++ 8.1 obtained from WindRiver
to target PowerPC VxWorks (running on Rhel-7):

./powerpc-linux-gnu-g++ -v
Reading specs from
/opt/workbench4-r2/compilers/gnu-8.1.0.1/x86_64-linux2/bin/../lib/gcc/powerpc-linux-gnu/8.1.0/../../../../powerpc-linux-gnu/lib/specs
COLLECT_GCC=./powerpc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/opt/workbench4-r2/compilers/gnu-8.1.0.1/x86_64-linux2/bin/../libexec/gcc/powerpc-linux-gnu/8.1.0/lto-wrapper
Target: powerpc-linux-gnu
Configured with:
/folk/prj-llvm-build/gcc/build-storage/master/20190313_161647/wr-gcc/gcc/configure
--target=powerpc-linux-gnu --prefix=/usr/local/wind/tmp/compilers
--with-pkgversion='Wind River VxWorks GCC 8.1.0.1 - 2019.03.13' --disable-nls
--enable-languages=c,c++ --enable-targets=all --disable-multilib
--enable-threads --enable-tls --enable-__cxa_atexit --enable-secureplt
Thread model: posix
gcc version 8.1.0 (Wind River VxWorks GCC 8.1.0.1 - 2019.03.13)

[Bug c++/79520] Spurious caching for constexpr arguments

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79520

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
Fixed by r255788.  Probably it's worth to add the new test.

Re: Use predicates for RTL objects

2019-08-08 Thread Arvind Sankar
On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote:
> On Wed, Aug 07, 2019 at 02:58:12PM -0400, Arvind Sankar wrote:
> > > > > code does is cheap.  With "x->is_a (PLUS)", who knows what is 
> > > > > happening
> > > That's not my point -- my point was that it is *obvious* the way things
> > > are now, which is nice.
> > 
> > My reply is pointing out that it is just as (non-)obvious with or
> > without that inline function, if you want to use any of the helper
> > macros.
> 
> But that is not what you suggested, or at least not how I read it.
>   x->is_a (PLUS)
> is not obviously cheap or simple at all, while
>   GET_CODE (x) == PLUS
> obviously *is*.
> 
> The former also isn't readable.

That's a matter of what style you prefer and it seems like no-one else
shares my preference, and I accept that we're not going to make such a
change.

But there is really nothing more or less obvious about it. It's easy to
go look at the code, as you probably once did when checking what
GET_CODE or REG_P actually did, and is_a methods are expected to be
lightweight. Regarding hiding things, consider that we just added
LABEL_REF_P, which is for a comparison that happens less than half as
often as PLUS in the codebase (and I think it was actually only
used in one place). It was done presumably because the author/reviewers
felt that LABEL_REF_P (x) is more readable than GET_CODE (x) == LABEL_REF, 
even if the latter might be ever so slightly more transparent as to what
its doing than the former.

> 
> Indirection is *the* evil in programming.

Some would say that "All problems in computer science can be solved by
another level of indirection" ;)


Re: Indirect memory addresses vs. lra

2019-08-08 Thread Paul Koning



> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool  
> wrote:
> 
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
>>> The old reload (reload[1].c) supports such addressing.  As modern 
>>> mainstream architectures have no this kind of addressing, it was not 
>>> implemented in LRA.
>> 
>> Is LRA only intended for "modern mainstream architectures"?
> 
> I sure hope not!  But it has only been *used* and *tested* much on such,
> so far. 

That's not entirely accurate.  At the prodding of people pushing for the 
removal of CC0 and reload, I've added LRA support to pdp11 in the V9 cycle.  
And it works pretty well, in the sense of passing the compile tests.  But I 
haven't yet examined the code quality vs. the old one in any detail.

paul



[Bug c++/88330] Implement P0542R5, P1289R1, C++20 contract based programming.

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88330

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
Since contracts were pulled out of C++20, I'm closing this PR.

[Bug c++/88323] implement C++20 language features.

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 88330, which changed state.

Bug 88330 Summary: Implement P0542R5, P1289R1, C++20 contract based programming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88330

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

Re: Indirect memory addresses vs. lra

2019-08-08 Thread Paul Koning



> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool  
> wrote:
> 
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
>>> The old reload (reload[1].c) supports such addressing.  As modern 
>>> mainstream architectures have no this kind of addressing, it was not 
>>> implemented in LRA.
>> 
>> Is LRA only intended for "modern mainstream architectures"?
> 
> I sure hope not!  But it has only been *used* and *tested* much on such,
> so far.  Things are designed to work well for modern archs.
> 
>> If yes, why is the old reload being deprecated?  You can't have it both 
>> ways.  Unless you want to obsolete all "not modern mainstream architectures" 
>> in GCC, it doesn't make sense to get rid of core functionality used by those 
>> architectures.
>> 
>> Indirect addressing is a key feature in size-optimized code.
> 
> That doesn't mean that LRA has to support it, btw, not necessarily; it
> may well be possible to do a good job of this in the later passes?
> Maybe postreload, maybe some peepholes, etc.?

Possibly.  But as Vladimir points out, indirect addressing affects register 
allocation (reducing register pressure).  In older architectures that implement 
indirect addressing, that is one of the key ways in which the feature reduces 
code size.  While I can see how peephole optimization can convert a address 
load plus a register indirect into a memory indirect instruction, does that 
help the register become available for other uses or is post-LRA too late for 
that?  My impression is that it is too late, since at this point we're dealing 
with hard registers and making one free via peephole helps no one else.

paul




Re: Indirect memory addresses vs. lra

2019-08-08 Thread Segher Boessenkool
On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
> > On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
> > The old reload (reload[1].c) supports such addressing.  As modern 
> > mainstream architectures have no this kind of addressing, it was not 
> > implemented in LRA.
> 
> Is LRA only intended for "modern mainstream architectures"?

I sure hope not!  But it has only been *used* and *tested* much on such,
so far.  Things are designed to work well for modern archs.

> If yes, why is the old reload being deprecated?  You can't have it both ways. 
>  Unless you want to obsolete all "not modern mainstream architectures" in 
> GCC, it doesn't make sense to get rid of core functionality used by those 
> architectures.
> 
> Indirect addressing is a key feature in size-optimized code.

That doesn't mean that LRA has to support it, btw, not necessarily; it
may well be possible to do a good job of this in the later passes?
Maybe postreload, maybe some peepholes, etc.?


Segher


Re: Use predicates for RTL objects

2019-08-08 Thread Arvind Sankar
On Thu, Aug 08, 2019 at 03:04:53PM +, Michael Matz wrote:
> Hi,
> 
> On Wed, 7 Aug 2019, Arvind Sankar wrote:
> 
> > => x->is_a (REG)
> 
> Oh god, please no.  Currently at least the RTL parts of GCC still have 
> mostly a consistent and obvious style, which is a good thing.  I have no 
> idea why anyone would think the above is easier to read than REG_P (x).
> 
> 
> Ciao,
> Michael.
> P.S: Consider this: the current style served us quite well for the last 35 
> or so years, so before suggesting style changes, shouldn't you first work 
> on the sources for some time?

Well, the main point of the email was to ask for review of a patchset
that attempts to make progress on a TODO that has been outstanding for
at least 15 of those 35 years.


Re: Use predicates for RTL objects

2019-08-08 Thread Arvind Sankar
On Thu, Aug 08, 2019 at 08:31:28AM -0600, Jeff Law wrote:
> True, but they could be.  When David was working in this space a few
> years ago I concluded that the main value in sub-classing the various
> RTL operators just wansn't worth the effort.  Instead we focused on
> starting to tear apart things like the toplevel objects into rtx_insn
> and the like.  THere's little value in treating those as simple RTXs.
> INSN_LIST and the like were also ripe for this treatment.
> 
> The biggest value in making a real class for the operators things would
> be to move the runtime RTL checking into a compile-time check.  But I
> couldn't really green light something like that without first completing
> the rtx_insn changes.

Are there any notes or old discussion threads on what remains? I would
be interested in taking a look if no-one else is.

Thanks

> 
> > 
> > 
> > If you really want to convert RTL to C++, you should start with getting
> > rid of rtx_format and rtx_class, and make REG_P etc. work just as they
> > have always done.
> Yup.  And continue pushing the rtx_insn bits deeper, tackling INSN_LIST,
> etc.
> 
> jeff


[Bug c++/88102] Implement P0542R5, C++20 contracts

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88102

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Marek Polacek  ---
Since contracts were pulled out of C++20, I'm closing this PR.

[Bug c++/88323] implement C++20 language features.

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 88102, which changed state.

Bug 88102 Summary: Implement P0542R5, C++20 contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88102

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug c/91398] Possible missed optimization: Can a pointer be passed as hidden pointer in x86-64 System V ABI

2019-08-08 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398

--- Comment #1 from joseph at codesourcery dot com  ---
ABI question: is a function that returns a value through such a hidden 
pointer required not to write anything to the storage pointed to until it 
knows that it will definitely be returning normally (rather than e.g. 
through longjmp)?  The ABI document seems silent on this matter.  This 
optimization is only valid if there is such a requirement, since *out in 
the example given must not be written if the function returns through 
longjmp.

Re: Use predicates for RTL objects

2019-08-08 Thread Arvind Sankar
On Thu, Aug 08, 2019 at 10:42:06AM -0600, Jeff Law wrote:
> On 8/5/19 12:29 PM, Segher Boessenkool wrote:
> > On Mon, Aug 05, 2019 at 02:14:50PM -0400, Arvind Sankar wrote:
> >> On Mon, Aug 05, 2019 at 12:48:46PM -0500, Segher Boessenkool wrote:
> >>> First: do you have a copyright assignment?  See
> >>>   https://gcc.gnu.org/contribute.html
> >>> for instructions.
> >>
> >> Nope, is this really substantial enough to warrant one?
> > 
> > Some might say it is, the sheer amount of code changed :-)  If some
> > maintainer okays it without assignment, that is fine with me of course.
> > 
> > This is also easier if it is all machine-generated and nice simple
> > patches :-)
> If it's entirely machine generated and you don't want to do a copyright
> assignment, then the way to go will be for someone with an assignment to
> run the scripts and commit the change.  Then we'd only need an
> assignment if we wanted the scripts in the repo.
> 
I have just got the forms from GNU, probably a few days to actually send
it in. I am not too fussed about how to do this particular change,
whatever's easiest.
> 
> 
> > 
>  -/* Predicate yielding true iff X is an rtx for a double-int.  */
>  +/* Predicate yielding true iff X is an rtx for a floating point 
>  constant.  */
>   #define CONST_DOUBLE_AS_FLOAT_P(X) \
> (GET_CODE (X) == CONST_DOUBLE && GET_MODE (X) != VOIDmode)
> >>>
> >>> Is const_double really only used for floating point these days?
> > 
> >> Are you asking if the CONST_DOUBLE_AS_INT_P possibility is dead code
> >> now? That's beyond my current level of understanding of the code,
> >> hopefully someone else will chime in.
> > 
> > I am asking if the change to this comment is correct.
> I thought we used CONST_DOUBLE for scalar constants that are wider than
> a HOST_WIDE_INT, or perhaps wider than 2 HOST_WIDE_INTs.  If that's
> still the case, then the comment change is wrong.
> 
> Jeff

Please note that this is the comment for CONST_DOUBLE_AS_FLOAT_P, not
CONST_DOUBLE_P. CONST_DOUBLE_AS_INT_P is the predicate to represent a
CONST_DOUBLE being used to store large integers, and, as I understand
it, it will be used if the target does not define TARGET_SUPPORTS_WIDE_INT.

At present, the comment for both CONST_DOUBLE_AS_INT_P and
CONST_DOUBLE_AS_FLOAT_P claim that they are the predicates for
double-int.


Re: Use predicates for RTL objects

2019-08-08 Thread Segher Boessenkool
On Thu, Aug 08, 2019 at 10:42:06AM -0600, Jeff Law wrote:
> On 8/5/19 12:29 PM, Segher Boessenkool wrote:
> > On Mon, Aug 05, 2019 at 02:14:50PM -0400, Arvind Sankar wrote:
> >> On Mon, Aug 05, 2019 at 12:48:46PM -0500, Segher Boessenkool wrote:
> >>> First: do you have a copyright assignment?  See
> >>>   https://gcc.gnu.org/contribute.html
> >>> for instructions.
> >>
> >> Nope, is this really substantial enough to warrant one?
> > 
> > Some might say it is, the sheer amount of code changed :-)  If some
> > maintainer okays it without assignment, that is fine with me of course.
> > 
> > This is also easier if it is all machine-generated and nice simple
> > patches :-)
> If it's entirely machine generated and you don't want to do a copyright
> assignment, then the way to go will be for someone with an assignment to
> run the scripts and commit the change.  Then we'd only need an
> assignment if we wanted the scripts in the repo.

(/me thinks someone set him up to volunteer for this...  Well I guess
that was me who did that?  Oh well.)

Yes, I'll do that, and I'll rewrite the script so it is maintainable
(as far as that is possible with REs :-) ).

That leaves the new predicates...

>  -/* Predicate yielding true iff X is an rtx for a double-int.  */
>  +/* Predicate yielding true iff X is an rtx for a floating point 
>  constant.  */
>   #define CONST_DOUBLE_AS_FLOAT_P(X) \
> (GET_CODE (X) == CONST_DOUBLE && GET_MODE (X) != VOIDmode)
> >>>
> >>> Is const_double really only used for floating point these days?
> > 
> >> Are you asking if the CONST_DOUBLE_AS_INT_P possibility is dead code
> >> now? That's beyond my current level of understanding of the code,
> >> hopefully someone else will chime in.
> > 
> > I am asking if the change to this comment is correct.
> I thought we used CONST_DOUBLE for scalar constants that are wider than
> a HOST_WIDE_INT, or perhaps wider than 2 HOST_WIDE_INTs.  If that's
> still the case, then the comment change is wrong.

Some lines above there is

/* Predicate yielding true iff X is an rtx for a double-int.  */
#define CONST_DOUBLE_AS_INT_P(X) \
  (GET_CODE (X) == CONST_DOUBLE && GET_MODE (X) == VOIDmode)

so the change is actually good?  But these macros should be moved
together.


Segher


Re: Use predicates for RTL objects

2019-08-08 Thread Jakub Jelinek
On Thu, Aug 08, 2019 at 10:42:06AM -0600, Jeff Law wrote:
>  -/* Predicate yielding true iff X is an rtx for a double-int.  */
>  +/* Predicate yielding true iff X is an rtx for a floating point 
>  constant.  */
>   #define CONST_DOUBLE_AS_FLOAT_P(X) \
> (GET_CODE (X) == CONST_DOUBLE && GET_MODE (X) != VOIDmode)
> >>>
> >>> Is const_double really only used for floating point these days?

No.  But it is used for integers only if it has VOIDmode, so I
think the above comment change is fine.
CONST_DOUBLE isn't used for integers on targets that define
TARGET_SUPPORTS_WIDE_INT, but that is a minority of targets (though, the
most common ones).

Jakub


[PATCH 2/3] [og9] Fix configury for AMD GCN testing

2019-08-08 Thread Julian Brown
This patch updates the configury for AMD GCN for version
of the patch "Forward -foffload=[...] from the driver (compile-time)
to libgomp (run-time)" currently applied to the og9 branch. This is
necessary for OpenACC testing on AMD GCN to work properly, at least in
our test environment.

Julian

ChangeLog

libgomp/
* plugin/configfrag.ac (amdgcn): Set tgt_plugin.
* testsuite/lib/libgomp.exp (offload_target_to_openacc_device_type):
Add AMD GCN support.
(check_effective_target_openacc_amdgcn_accel_selected): Test
offload_target instead of offload_target_openacc.
* testsuite/libgomp.oacc-c++/c++.exp (amdgcn*): Rename stanza to...
(gcn): ...this. Don't set tagopt redundantly here.
* testsuite/libgomp.oacc-c/c.exp (amdgcn*, gcn): Likewise.
* testsuite/libgomp.oacc-fortran/fortran.exp (amdgcn*, gcn): Likewise.
* configure: Regenerated.
---
 libgomp/ChangeLog.openacc  | 13 +
 libgomp/configure  |  1 +
 libgomp/plugin/configfrag.ac   |  1 +
 libgomp/testsuite/lib/libgomp.exp  |  7 +--
 libgomp/testsuite/libgomp.oacc-c++/c++.exp |  3 +--
 libgomp/testsuite/libgomp.oacc-c/c.exp |  3 +--
 libgomp/testsuite/libgomp.oacc-fortran/fortran.exp |  3 +--
 7 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/libgomp/ChangeLog.openacc b/libgomp/ChangeLog.openacc
index 80d089f49e2..62c56e3bf92 100644
--- a/libgomp/ChangeLog.openacc
+++ b/libgomp/ChangeLog.openacc
@@ -1,3 +1,16 @@
+2019-08-08  Julian Brown  
+
+	* plugin/configfrag.ac (amdgcn): Set tgt_plugin.
+	* testsuite/lib/libgomp.exp (offload_target_to_openacc_device_type):
+	Add AMD GCN support.
+	(check_effective_target_openacc_amdgcn_accel_selected): Test
+	offload_target instead of offload_target_openacc.
+	* testsuite/libgomp.oacc-c++/c++.exp (amdgcn*): Rename stanza to...
+	(gcn): ...this. Don't set tagopt redundantly here.
+	* testsuite/libgomp.oacc-c/c.exp (amdgcn*, gcn): Likewise.
+	* testsuite/libgomp.oacc-fortran/fortran.exp (amdgcn*, gcn): Likewise.
+	* configure: Regenerated.
+
 2019-08-08  Julian Brown  
 
 	* plugin/plugin-gcn.c (GOMP_OFFLOAD_openacc_exec_params,
diff --git a/libgomp/configure b/libgomp/configure
index 39da8af4546..85a29c5b5e1 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15781,6 +15781,7 @@ rm -f core conftest.err conftest.$ac_objext \
 		;;
 	  *)
 		tgt_name=gcn
+		tgt_plugin=gcn
 		PLUGIN_GCN=$tgt
 		PLUGIN_GCN_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
 		PLUGIN_GCN_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
diff --git a/libgomp/plugin/configfrag.ac b/libgomp/plugin/configfrag.ac
index 6fedd28eccc..1ea67c913ba 100644
--- a/libgomp/plugin/configfrag.ac
+++ b/libgomp/plugin/configfrag.ac
@@ -256,6 +256,7 @@ if test x"$enable_offload_targets" != x; then
 		;;
 	  *)
 		tgt_name=gcn
+		tgt_plugin=gcn
 		PLUGIN_GCN=$tgt
 		PLUGIN_GCN_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
 		PLUGIN_GCN_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index 19bee806fb0..9644176da2a 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -316,6 +316,9 @@ proc offload_target_to_openacc_device_type { offload_target } {
 	nvptx* {
 	return "nvidia"
 	}
+	amdgcn* {
+	return "gcn"
+	}
 	default {
 	error "Unknown offload target: $offload_target"
 	}
@@ -463,8 +466,8 @@ proc check_effective_target_openacc_amdgcn_accel_selected { } {
 if { ![check_effective_target_openacc_amdgcn_accel_present] } {
 	return 0;
 }
-global offload_target_openacc
-if { [string match "amdgcn*" $offload_target_openacc] } {
+global offload_target
+if { [string match "amdgcn*" $offload_target] } {
 return 1;
 }
 return 0;
diff --git a/libgomp/testsuite/libgomp.oacc-c++/c++.exp b/libgomp/testsuite/libgomp.oacc-c++/c++.exp
index 1285a6a1c6d..86aacff0c37 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/c++.exp
+++ b/libgomp/testsuite/libgomp.oacc-c++/c++.exp
@@ -111,9 +111,8 @@ if { $lang_test_file_found } {
 
 		set acc_mem_shared 0
 	}
-	amdgcn* {
+	gcn {
 		set acc_mem_shared 0
-		set tagopt "-DACC_DEVICE_TYPE_gcn=\"$offload_target_openacc\""
 	}
 	default {
 		error "Unknown OpenACC device type: $openacc_device_type (offload target: $offload_target)"
diff --git a/libgomp/testsuite/libgomp.oacc-c/c.exp b/libgomp/testsuite/libgomp.oacc-c/c.exp
index f7005ebba48..9ab68bbef14 100644
--- a/libgomp/testsuite/libgomp.oacc-c/c.exp
+++ b/libgomp/testsuite/libgomp.oacc-c/c.exp
@@ -72,9 +72,8 @@ foreach offload_target [concat [split $offload_targets ":"] "disable"] {
 
 	set acc_mem_shared 0
 	}
-	amdgcn* {
+	gcn {
 	set acc_mem_shared 0
-	set tagopt "-DACC_DEVICE_TYPE_gcn=\"$offload_target_openacc\""
 	}
 	default {
 	error "Unknown OpenACC device type: $openacc_device_type (offload target: 

[PATCH 3/3] [og9] Use a single worker for OpenACC on AMD GCN

2019-08-08 Thread Julian Brown
This patch sets the number of workers (per-gang) to 1 for AMD GCN,
as a stop-gap measure until the middle-end transformations to enable
multiple workers have been applied.

Julian

ChangeLog

gcc/
* config/gcn/gcn.c (gcn_goacc_validate_dims): Ensure
flag_worker_partitioning is not set.
(TARGET_GOACC_WORKER_PARTITIONING): Remove target hook definition.
* config/gcn/gcn.opt (macc-experimental-workers): Default to off.

libgomp/
* plugin/plugin-gcn.c (gcn_exec): Use 1 for the default number of
workers.
---
 gcc/ChangeLog.openacc   | 7 +++
 gcc/config/gcn/gcn.c| 4 ++--
 gcc/config/gcn/gcn.opt  | 2 +-
 libgomp/ChangeLog.openacc   | 5 +
 libgomp/plugin/plugin-gcn.c | 4 +++-
 5 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
index 0caa1cd1401..84d80511603 100644
--- a/gcc/ChangeLog.openacc
+++ b/gcc/ChangeLog.openacc
@@ -1,3 +1,10 @@
+2019-08-08  Julian Brown  
+
+	* config/gcn/gcn.c (gcn_goacc_validate_dims): Ensure
+	flag_worker_partitioning is not set.
+	(TARGET_GOACC_WORKER_PARTITIONING): Remove target hook definition.
+	* config/gcn/gcn.opt (macc-experimental-workers): Default to off.
+
 2019-07-31  Julian Brown  
 
 	* builtin-types.def (BT_FN_VOID_INT_INT_OMPFN_SIZE_PTR_PTR_PTR_VAR):
diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 9f73fc8161a..f3f112d95a9 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -4662,6 +4662,8 @@ gcn_goacc_validate_dims (tree decl, int dims[], int fn_level,
   /* FIXME: remove -facc-experimental-workers when they're ready.  */
   int max_workers = flag_worker_partitioning ? 16 : 1;
 
+  gcc_assert (!flag_worker_partitioning);
+
   /* The vector size must appear to be 64, to the user, unless this is a
  SEQ routine.  The real, internal value is always 1, which means use
  autovectorization, but the user should not see that.  */
@@ -6038,8 +6040,6 @@ print_operand (FILE *file, rtx x, int code)
 #define TARGET_GOACC_REDUCTION gcn_goacc_reduction
 #undef  TARGET_GOACC_VALIDATE_DIMS
 #define TARGET_GOACC_VALIDATE_DIMS gcn_goacc_validate_dims
-#undef  TARGET_GOACC_WORKER_PARTITIONING
-#define TARGET_GOACC_WORKER_PARTITIONING true
 #undef  TARGET_HARD_REGNO_MODE_OK
 #define TARGET_HARD_REGNO_MODE_OK gcn_hard_regno_mode_ok
 #undef  TARGET_HARD_REGNO_NREGS
diff --git a/gcc/config/gcn/gcn.opt b/gcc/config/gcn/gcn.opt
index 2fd3996edba..90d35f42e57 100644
--- a/gcc/config/gcn/gcn.opt
+++ b/gcc/config/gcn/gcn.opt
@@ -62,7 +62,7 @@ Target Report RejectNegative Var(flag_bypass_init_error)
 bool flag_worker_partitioning = false
 
 macc-experimental-workers
-Target Report Var(flag_worker_partitioning) Init(1)
+Target Report Var(flag_worker_partitioning) Init(0)
 
 int stack_size_opt = -1
 
diff --git a/libgomp/ChangeLog.openacc b/libgomp/ChangeLog.openacc
index 62c56e3bf92..2279545f361 100644
--- a/libgomp/ChangeLog.openacc
+++ b/libgomp/ChangeLog.openacc
@@ -1,3 +1,8 @@
+2019-08-08  Julian Brown  
+
+	* plugin/plugin-gcn.c (gcn_exec): Use 1 for the default number of
+	workers.
+
 2019-08-08  Julian Brown  
 
 	* plugin/configfrag.ac (amdgcn): Set tgt_plugin.
diff --git a/libgomp/plugin/plugin-gcn.c b/libgomp/plugin/plugin-gcn.c
index 6eaae66c1a9..a41568b3306 100644
--- a/libgomp/plugin/plugin-gcn.c
+++ b/libgomp/plugin/plugin-gcn.c
@@ -3233,8 +3233,10 @@ gcn_exec (struct kernel_info *kernel, size_t mapnum, void **hostaddrs,
  problem size, so let's do a reasonable number of single-worker gangs.
  64 gangs matches a typical Fiji device.  */
 
+  /* NOTE: Until support for middle-end worker partitioning is merged, use 1
+ for the default number of workers.  */
   if (dims[0] == 0) dims[0] = 64; /* Gangs.  */
-  if (dims[1] == 0) dims[1] = 16; /* Workers.  */
+  if (dims[1] == 0) dims[1] = 1;  /* Workers.  */
 
   /* The incoming dimensions are expressed in terms of gangs, workers, and
  vectors.  The HSA dimensions are expressed in terms of "work-items",


[PATCH 1/3] [og9] Add missing exec_params libgomp plugin entry points

2019-08-08 Thread Julian Brown
This patch adds two missing (dummy) entry points to the GCN libgomp
plugin. These are not used at present, because we have not enabled the
function parameter flattening transformation that uses these entry points
on GCN.

Julian

ChangeLog

libgomp/
* plugin/plugin-gcn.c (GOMP_OFFLOAD_openacc_exec_params,
GOMP_OFFLOAD_openacc_async_exec_params): New functions.
---
 libgomp/ChangeLog.openacc   |  5 +
 libgomp/plugin/plugin-gcn.c | 17 +
 2 files changed, 22 insertions(+)

diff --git a/libgomp/ChangeLog.openacc b/libgomp/ChangeLog.openacc
index a187ebb7295..80d089f49e2 100644
--- a/libgomp/ChangeLog.openacc
+++ b/libgomp/ChangeLog.openacc
@@ -1,3 +1,8 @@
+2019-08-08  Julian Brown  
+
+	* plugin/plugin-gcn.c (GOMP_OFFLOAD_openacc_exec_params,
+	GOMP_OFFLOAD_openacc_async_exec_params): New functions.
+
 2019-07-31  Julian Brown  
 
 	* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Use relative
diff --git a/libgomp/plugin/plugin-gcn.c b/libgomp/plugin/plugin-gcn.c
index b059348c7bf..6eaae66c1a9 100644
--- a/libgomp/plugin/plugin-gcn.c
+++ b/libgomp/plugin/plugin-gcn.c
@@ -3291,6 +3291,14 @@ GOMP_OFFLOAD_openacc_exec (void (*fn_ptr) (void *), size_t mapnum,
 	NULL);
 }
 
+void
+GOMP_OFFLOAD_openacc_exec_params (void (*fn_ptr) (void *), size_t mapnum,
+  void **hostaddrs, void **devaddrs,
+  unsigned *dims, void *targ_mem_desc)
+{
+  GOMP_PLUGIN_fatal ("OpenACC exec params unimplemented.");
+}
+
 void
 GOMP_OFFLOAD_openacc_async_exec (void (*fn_ptr) (void *), size_t mapnum,
  void **hostaddrs, void **devaddrs,
@@ -3303,6 +3311,15 @@ GOMP_OFFLOAD_openacc_async_exec (void (*fn_ptr) (void *), size_t mapnum,
 	aq);
 }
 
+void
+GOMP_OFFLOAD_openacc_async_exec_params (void (*fn) (void *), size_t mapnum,
+	void **hostaddrs, void **devaddrs,
+	unsigned *dims, void *targ_mem_desc,
+	struct goacc_asyncqueue *aq)
+{
+  GOMP_PLUGIN_fatal ("OpenACC async exec params unimplemented.");
+}
+
 struct goacc_asyncqueue *
 GOMP_OFFLOAD_openacc_async_construct (int device)
 {


[PATCH 0/3] [og9] Initial OpenACC fixes for AMD GCN

2019-08-08 Thread Julian Brown
Hi,

This patch series provides basic support for OpenACC on AMD GCN,
using a single worker (per-gang) only. This is enough to improve test
results significantly over the previous state on the og9 branch, but
bugs still remain.

Further commentary attached to individual patches. Tested with offloading
to AMD GCN. I will apply shortly.

Thanks,

Julian

Julian Brown (3):
  [og9] Add missing exec_params libgomp plugin entry points
  [og9] Fix configury for AMD GCN testing
  [og9] Use a single worker for OpenACC on AMD GCN

 gcc/ChangeLog.openacc |  7 ++
 gcc/config/gcn/gcn.c  |  4 ++--
 gcc/config/gcn/gcn.opt|  2 +-
 libgomp/ChangeLog.openacc | 23 +++
 libgomp/configure |  1 +
 libgomp/plugin/configfrag.ac  |  1 +
 libgomp/plugin/plugin-gcn.c   | 21 -
 libgomp/testsuite/lib/libgomp.exp |  7 --
 libgomp/testsuite/libgomp.oacc-c++/c++.exp|  3 +--
 libgomp/testsuite/libgomp.oacc-c/c.exp|  3 +--
 .../libgomp.oacc-fortran/fortran.exp  |  3 +--
 11 files changed, 63 insertions(+), 12 deletions(-)

-- 
2.22.0



[Bug middle-end/91395] Report an uninitialized variable on its initialization statement (setjmp)

2019-08-08 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91395

--- Comment #5 from joseph at codesourcery dot com  ---
It's *accessible objects* whose value on second return from setjmp is the 
same as when longjmp is called (unless non-volatile, automatic storage 
duration and changed between setjmp and longjmp).  The point is that when 
longjmp is called, save_exception_stack may not be an accessible object 
(because of having gone out of scope), so has no defined value, so it's 
just like goto jumping into the block where save_exception_stack is 
declared and thus bypassing its initialization - it's valid to jump into 
the scope like that (unless jumping into the scope of a declaration with 
variably modified type), but the variable is uninitialized.

Re: [C] Fix bogus nested enum error message

2019-08-08 Thread Jeff Law
On 8/5/19 3:00 AM, Richard Sandiford wrote:
> For:
> 
> enum a { A };
> enum a { B };
> 
> we emit a bogus error about nested definitions before the real error:
> 
> foo.c:2:6: error: nested redefinition of ‘enum a’
> 2 | enum a { B };
>   |  ^
> foo.c:2:6: error: redeclaration of ‘enum a’
> foo.c:1:6: note: originally defined here
> 1 | enum a { A };
>   |  ^
> 
> This is because we weren't clearing C_TYPE_BEING_DEFINED once the
> definition was over.
> 
> I think it's OK to clear C_TYPE_BEING_DEFINED even for a definition
> that actually is nested (and so whose outer definition is still open),
> since we'll already have given an error by then.  It means that second
> and subsequent attempts to define a nested enum will usually get the
> redeclaration error instead of the nested error, but that seems just
> as accurate (nested_first and nested_second in the test).  The only
> exception is if the first nested enum was also invalid by being empty,
> but then the enum as a whole has already produced two errors
> (nested_empty in the test).
> 
> Tested on aarch64-linux-gnu, armeb-eabi and x86_64-linux-gnu.
> OK to install?
> 
> Richard
> 
> 
> 2019-08-05  Richard Sandiford  
> 
> gcc/c/
>   * c-decl.c (finish_enum): Clear C_TYPE_BEING_DEFINED.
> 
> gcc/testsuite/
>   * gcc.dg/pr79983.c (enum E): Don't allow an error about nested
>   definitions.
>   * gcc.dg/enum-redef-1.c: New test.
OK
jeff


[Bug c++/81930] [meta-bug] Issues with -Weffc++

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930
Bug 81930 depends on bug 57854, which changed state.

Bug 57854 Summary: Would like to have a warning for virtual overrides without 
C++11 "override" keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/57854] Would like to have a warning for virtual overrides without C++11 "override" keyword

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
-Wsuggest-override is already present, closing.

Re: [PATCH] issue a correct fix-it hint for bad argument in GCC diagnostics (PR 80619)

2019-08-08 Thread Jeff Law
On 8/5/19 11:51 AM, Martin Sebor wrote:
> When the argument to a directive with a length modifier like %lu
> in a call to a GCC diagnostic function such as warning()) is not
> of the right integer type, GCC suggests to replace the length
> modifier in the directive with 'w'.  For instance:
> 
>   warning: format ‘%lu’ expects argument of type ‘long unsigned int’,
> but argument 2 has type ‘int’ [-Wformat=]
>    f ("%lu", 0);
>    ~~^
>    %wu
> 
> To issue the right hint (i.e., %u in the message above) the attached
> patch introduces a new format_lengths enumerator to represent the 'w'
> modifier.
> 
> Tested on x86_64-linux.
> 
> Martin
> 
> gcc-80619.diff
> 
> PR c/80619 - bad fix-it hint for GCC %lu directive with int argument: %wu
> 
> gcc/c-family/ChangeLog:
> 
>   PR c/80619
>   * c-format.c (printf_length_specs): Set FMT_LEN_w for "w".
>   (asm_fprintf_length_spec): Same.
>   * c-format.h (format_lengths): Add FMT_LEN_w.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c/80619
>   * gcc.dg/format/pr80619.c: New test.
OK
jeff


Re: Indirect memory addresses vs. lra

2019-08-08 Thread Paul Koning



> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
> 
> 
> On 2019-08-04 3:18 p.m., John Darrington wrote:
>> I'm trying to write a back-end for an architecture (s12z - the ISA you can
>> download from [1]).  This arch accepts indirect memory addresses.   That is 
>> to
>> say, those of the form (mem (mem (...)))  and although my 
>> TARGET_LEGITIMATE_ADDRESS
>> function returns true for such addresses, LRA insists on reloading them out 
>> of
>> existence.
>> ...
> The old reload (reload[1].c) supports such addressing.  As modern mainstream 
> architectures have no this kind of addressing, it was not implemented in LRA.

Is LRA only intended for "modern mainstream architectures"?

If yes, why is the old reload being deprecated?  You can't have it both ways.  
Unless you want to obsolete all "not modern mainstream architectures" in GCC, 
it doesn't make sense to get rid of core functionality used by those 
architectures.

Indirect addressing is a key feature in size-optimized code.

paul



[Bug c++/80061] error on constexpr function with an unevaluated throw

2019-08-08 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
Comment 1 compiles fine since r264171.

Re: Use predicates for RTL objects

2019-08-08 Thread Jeff Law
On 8/5/19 12:29 PM, Segher Boessenkool wrote:
> On Mon, Aug 05, 2019 at 02:14:50PM -0400, Arvind Sankar wrote:
>> On Mon, Aug 05, 2019 at 12:48:46PM -0500, Segher Boessenkool wrote:
>>> First: do you have a copyright assignment?  See
>>>   https://gcc.gnu.org/contribute.html
>>> for instructions.
>>
>> Nope, is this really substantial enough to warrant one?
> 
> Some might say it is, the sheer amount of code changed :-)  If some
> maintainer okays it without assignment, that is fine with me of course.
> 
> This is also easier if it is all machine-generated and nice simple
> patches :-)
If it's entirely machine generated and you don't want to do a copyright
assignment, then the way to go will be for someone with an assignment to
run the scripts and commit the change.  Then we'd only need an
assignment if we wanted the scripts in the repo.



> 
 -/* Predicate yielding true iff X is an rtx for a double-int.  */
 +/* Predicate yielding true iff X is an rtx for a floating point constant. 
  */
  #define CONST_DOUBLE_AS_FLOAT_P(X) \
(GET_CODE (X) == CONST_DOUBLE && GET_MODE (X) != VOIDmode)
>>>
>>> Is const_double really only used for floating point these days?
> 
>> Are you asking if the CONST_DOUBLE_AS_INT_P possibility is dead code
>> now? That's beyond my current level of understanding of the code,
>> hopefully someone else will chime in.
> 
> I am asking if the change to this comment is correct.
I thought we used CONST_DOUBLE for scalar constants that are wider than
a HOST_WIDE_INT, or perhaps wider than 2 HOST_WIDE_INTs.  If that's
still the case, then the comment change is wrong.

Jeff


[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

2019-08-08 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227

--- Comment #18 from joseph at codesourcery dot com  ---
I don't expect people to do such comparisons with addresses of local 
variables directly.  It is plausible that they have a memmove-like 
function, and once it gets inlined the compiler can see that, at a 
particular call site, it's doing such comparisons involving addresses of 
local variables.  The question then is whether this might result in 
problems if e.g. the comparisons say two arrays are both before and after 
each other and the memmove-like function isn't prepared for that.  And, 
then, whether we say that's OK and such a function needs to cast to 
uintptr_t as the way to make something that's valid in 
C-with-ABI-boundaries into something that works in GNU C in the presence 
of (possibly LTO) inlining.

Re: Run the combine part of combine_and_move_insns even if -fsched-pressure

2019-08-08 Thread Jeff Law
On 8/7/19 12:16 PM, Richard Sandiford wrote:
> The main IRA routine includes the code:
> 
>   /* Don't move insns if live range shrinkage or register
>  pressure-sensitive scheduling were done because it will not
>  improve allocation but likely worsen insn scheduling.  */
>   if (optimize
>   && !flag_live_range_shrinkage
>   && !(flag_sched_pressure && flag_schedule_insns))
> combine_and_move_insns ();
> 
> The comment about not moving insns for pressure-sensitive scheduling
> makes sense, but I think the combine part of combine_and_move_insns is
> still useful, since it's folding a set of an equivalent value into its
> single user and so eliminates the need for one register altogether.
> 
> (That also means that it's likely to undo live range shrinkage in
> some cases, so I think the blanket skip still makes sense there.)
> 
> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
> OK to install?
> 
> Richard
> 
> 
> 2019-08-07  Richard Sandiford  
> 
> gcc/
>   * ira.c (combine_and_move_insns): Don't move insns if
>   pressure-sensitive scheduling is enabled.
>   (ira): Remove check for pressure-sensitive scheduling here.
> 
> gcc/testsuite/
>   * gcc.target/aarch64/csinc-3.c: New test.
>   * gcc.target/aarch64/csinv-2.c: Likewise.
OK
jeff


Re: [Committed] PR fortran/54072 -- More fun with BOZ

2019-08-08 Thread Steve Kargl
On Thu, Aug 08, 2019 at 09:23:11AM -0700, Steve Kargl wrote:
> On Thu, Aug 08, 2019 at 10:11:39AM +0100, Mark Eggleston wrote:
> > 
> > >> Comparisons with BOZ constants was allowed using 9.1 with
> > >> -Wconversion-extra:
> > >>
> > >>       5 | if (i4 .eq. z'1000') then
> > >>     |    1
> > >> Warning: Conversion from INTEGER(4) to INTEGER(16) at (1)
> > >> [-Wconversion-extra]
> > > This is the old behavior were a BOZ upon parsing is
> > > immediately converted to an INTEGER with the widest decimal
> > > range.  It is a holdover from when I made BOZ work in
> > > accordance with the Fortran 95 standard, where a BOZ is
> > > only allowed as a data-stmt-constant.  On your target, that
> > > is INTEGER(16).  Because of that conversion, a BOZ could
> > > be used anywhere an INTEGER can be used.
> > 
> > Other invalid BOZ usage is enable with -fallow-invalid-box, why not this?
> > 
> > This is from a test suite for a customer to check that gfortran supports 
> > various legacy features. This feature is supported by all the compilers 
> > they use including gfortran up to 9.1. This change will break legacy 
> > code.
> 
> Because, I choose not to support invalid code.  One would need
> to add a bunch of code to expr.c(simplify_intrinsic_op) to 
> detect the BOZ usage and report an error or warning and then
> do some conversion.  What does one do with

Ugh.  expr.c(simplify_intrinsic_op) would need updates if
we do some sort of constant-folding of BOZs.

For resolution of 'if (i .eq. z"123")'  one gets to 
resolve.c(resolve_operator).  The same questions still
apply.

-- 
Steve


Re: [PATCH] Implement -fopt-info support for IPA ICF.

2019-08-08 Thread Jeff Law
On 8/8/19 7:04 AM, Martin Liška wrote:
> Hi.
> 
> As requested by Richi, I'm suggesting to use new dump_printf
> optimization info infrastructure.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2019-08-08  Martin Liska  
> 
>   * ipa-icf.c (sem_function::merge): Define AUTO_DUMP_SCOPE and
>   use dump_printf to report optimization.
>   (sem_variable::merge): Likwise.
>   (sem_item_optimizer::merge_classes): Use dump_printf to report
>   ICF hits.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-08-08  Martin Liska  
> 
>   * g++.dg/ipa/ipa-icf-2.C: Add -optimized to -fdump-ipa-icf.
>   * g++.dg/ipa/ipa-icf-3.C: Likewise.
>   * g++.dg/ipa/ipa-icf-4.C: Likewise.
>   * g++.dg/ipa/ipa-icf-6.C: Likewise.
>   * gcc.dg/ipa/ipa-icf-1.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-10.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-11.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-12.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-13.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-16.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-18.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-2.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-20.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-21.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-23.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-25.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-26.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-27.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-3.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-35.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-36.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-37.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-38.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-39.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-5.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-7.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-8.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-merge-1.c: Likewise.
>   * gcc.dg/ipa/pr64307.c: Likewise.
>   * gcc.dg/ipa/pr90555.c: Likewise.
OK. As are any adjustments you may need to make if there's conflicts or
dependencies on the on the other ICF work you've got in the works.

This also seems straighforward enough that other patches that convert to
using the new infrastructure are pre-approved, just post them for
archival purposes.

jeff


Re: Indirect memory addresses vs. lra

2019-08-08 Thread Vladimir Makarov



On 2019-08-04 3:18 p.m., John Darrington wrote:

I'm trying to write a back-end for an architecture (s12z - the ISA you can
download from [1]).  This arch accepts indirect memory addresses.   That is to
say, those of the form (mem (mem (...)))  and although my 
TARGET_LEGITIMATE_ADDRESS
function returns true for such addresses, LRA insists on reloading them out of
existence.

For example, when compiling a code fragment:

   volatile unsigned char *led = 0x2F2;
   *led = 1;

the ira dump file shows:

(insn 7 6 8 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])
 (const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movpsi}
  (nil))
(insn 8 7 14 2 (set (mem/v:QI (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]) [0 
*led_7+0 S1 A8])
 (const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi}
  (nil))

which is a perfectly valid insn, and the most efficient assembler for it is:
mov.p #0x2f2, y
mov.b #1, [0,y]

However the reload dump shows this has been changed to:

(insn 7 6 22 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])
 (const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movpsi}
  (nil))
(insn 22 7 8 2 (set (reg:PSI 8 x [22])
 (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])) 
"/home/jmd/MemMem/memmem.c":16:8 96 {movpsi}
  (nil))
(insn 8 22 14 2 (set (mem/v:QI (reg:PSI 8 x [22]) [0 *led_7+0 S1 A8])
 (const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi}
  (nil))

and ends up as:

mov.p #0x2f2, y
mov.p (0,y) x
mov.b #1, (0,x)

So this wastes a register (which leads to other issues which I don't want to go
into in this email).

After a lot of debugging I tracked down the part of lra which is doing this
reload to the function process_addr_reg at lra-constraints.c:1378

  if (! REG_P (reg))
 {
   if (check_only_p)
 return true;
   /* Always reload memory in an address even if the target supports such 
addresses.  */
   new_reg = lra_create_new_reg_with_unique_value (mode, reg, cl, 
"address");
   before_p = true;
 }

Changing this to

  if (! REG_P (reg))
 {
   if (check_only_p)
 return true;
   return false;
 }

solves my immediate problem.  However I imagine there was a reason for doing
this reload, and presumably a better way of avoiding it.

Can someone explain the reason for this reload, and how I can best ensure that
indirect memory operands are left in the compiled code?

The old reload (reload[1].c) supports such addressing.  As modern 
mainstream architectures have no this kind of addressing, it was not 
implemented in LRA.


I don't think the above simple change will work fully.  For example, you 
need to constrain memory nesting.  The constraints should be described, 
may be some hooks should be implemented (may be not and 
TARGET_LEGITIMATE_ADDRESS will be enough), may be additional address 
anslysis and transformations should be implemented in LRA, etc.  But may 
be implementing this is not hard either.


It is also difficult for me to say is it worth to do.  Removing such 
addressing helps to remove redundant memory reads.  On the other hand, 
its usage can decrease #insns and save registers for better RA and 
utilize hardware on design of which a lot of efforts were spent.


In any case, if somebody implements this, it can be included in LRA.



[1] https://www.nxp.com/docs/en/reference-manual/S12ZCPU_RM_V1.pdf



Re: [Committed] PR fortran/54072 -- More fun with BOZ

2019-08-08 Thread Steve Kargl
On Thu, Aug 08, 2019 at 10:11:39AM +0100, Mark Eggleston wrote:
> 
> >> Comparisons with BOZ constants was allowed using 9.1 with
> >> -Wconversion-extra:
> >>
> >>       5 | if (i4 .eq. z'1000') then
> >>     |    1
> >> Warning: Conversion from INTEGER(4) to INTEGER(16) at (1)
> >> [-Wconversion-extra]
> > This is the old behavior were a BOZ upon parsing is
> > immediately converted to an INTEGER with the widest decimal
> > range.  It is a holdover from when I made BOZ work in
> > accordance with the Fortran 95 standard, where a BOZ is
> > only allowed as a data-stmt-constant.  On your target, that
> > is INTEGER(16).  Because of that conversion, a BOZ could
> > be used anywhere an INTEGER can be used.
> 
> Other invalid BOZ usage is enable with -fallow-invalid-box, why not this?
> 
> This is from a test suite for a customer to check that gfortran supports 
> various legacy features. This feature is supported by all the compilers 
> they use including gfortran up to 9.1. This change will break legacy 
> code.

Because, I choose not to support invalid code.  One would need
to add a bunch of code to expr.c(simplify_intrinsic_op) to 
detect the BOZ usage and report an error or warning and then
do some conversion.  What does one do with

  if (z'12' .eq. z'4312')

Is this a hard error because both operands are BOZ?
Do you truncate the rhs operand or pad the lhs operand?
Do you simply convert these to INTEGER(16) and let the
compiler generate 128-bit integer code?

For the case

  if (i .eq. z'1234')  ! assuming i is integer

A conversion of the BOZ to the type and kind type of 'i' is possible.
Do we restrict the conversion to only rational operators?
Do we restrict the conversion to only integer comparisons?

What should this code do?

x = 4 * atan(1.) + 1
if (x .ge. z'40490FDB') print* , x
end

with gfortran 9, when compiled and executed it does not
produce output.

Should z'40490FDB' be converted to the type and kind of x?
In that case, gfortran-trunk would print out 4.14159...,
which is incompatiable with previous gfortran 9 and older. 
 
What should be done with unary operators?

i = - z'1234'  ! Assume i is integer.

The evaluation of the rhs is done first, and then assigned
to 'i' where possible conversion is done.

> Of course the best solution is to update their code i.e:
> 
> if (i4 .eq. int(z'1000',4)) then
> 
> I'll check whether the old behaviour is still required.

Yes, fixing the code would be preferred.

> >> Using trunk  with -fallow-invalid-boz comparison is not allowed:
> >>
> >>       5 | if (i4 .eq. z'1000') then
> >>     |    1
> >> Error: Operands of comparison operator '.eq.' at (1) are INTEGER(4)/BOZ
> >>
> >> I would have expected a suitable warning about using the BOZ in an
> >> inappropriate place.
> > A BOZ cannot be an operand to a binary operator.
> >
> > Consider
> >
> > x = 1.0 + z'40490fdb'   ! Is this 4.14159 or 1.07853005E+09
> >
> > y = z'40490fdb' + z'40490fbd' + 1. ! Is this 2*pi+1 or 2.15...E+09.
> >
> > Note, gfortran does left-to-right evaluation, but Fortran standard
> > does not require this ordering.  For 'x' it is possible to convert
> > op2 to the type of op1, which would give 4.1415  That behavior
> > is different in comparison to the historical accident of 1.08E9.
> > For 'y', there is no valid conversion of op1 into op2.  In older
> > versions, the first addition is of 2 INTEGER(16).  The second
> > addition converts a INTEGER(16) to a REAL(4) and then adds.
> >
> >> DATA statements for logical and character variable compile but do not work:
> >>
> >> program test
> >>     character(4) :: c
> >>     data c / z'41424344' /
> >>     write(*, *) "'" // c // "'", transfer(c, 0_4)
> >> end program test
> >>
> >> Outputs:
> >>
> >>    ''   0
> >>
> >> program test
> >>     logical(4) b / z'0001' /
> >>     write(*, *) b
> >> end program test
> >>
> >> Outputs:
> >>
> >>    F
> >  From the current Fortran working documenti, page 111:
> >
> > If a data-stmt-constant is a boz-literal-constant, the corresponding
> > variable shall be of type integer.  The boz-literal-constant is
> > treated as if it were converted by the intrinsic function INT(16.9.100)
> > to type integer with the kind type parameter of the variable.
> do have a link for the current workinng documentation it'll be useful.
> >
> > For the second program, I get
> >
> > gfcx -o z a.f90 && ./z
> > a.f90:8:26:
> >
> >  8 | logical(4) b / z'0001' /
> >|  1
> > Error: BOZ at (1) cannot appear in an old-style initialization
> >
> > which to me is acceptable.
> 
> whoops, I added the wrong program, it should have had a DATA statement 
> in it...
> 
> program test
>     logical(4) b
> data b / z'0001' /
>     write(*, *) b
> end program test

Thanks,  I take a look at this.  It should be rejected.

-- 
Steve


  1   2   3   >