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

[Martin Liška]

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?

Thanks,
Martin

Re: [PATCH] Fix file descriptor existence of MinGW.

[Martin Liška]

On 8/7/19 4:35 PM, Ian Lance Taylor wrote:
> On Wed, Aug 7, 2019 at 5:09 AM Martin Liška  wrote:
>>
>> There's one enhanced version where I added HAVE_FCNTL_H.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
> 
> I think a better name than fd_exists would be is_valid_fd.  If that's
> OK with you, the libiberty part of this patch seems fine with that
> change.  Thanks.

Thank you, I installed the patch with changed name.

> 
> (Although I'm not quite sure what problem this is trying to solve.
> What goes wrong if the driver just doesn't bother to check whether the
> file descriptors listed in --jobserver-auth are valid?

Because make provides a silly jobserver API. When you forget to add '+'
to your make target, then make will pass --jobserver-auth=x,y options,
but the file descriptors are not opened. And so that one can't use job
server. That's why we do the dance.

Martin

>  Why would that
> ever happen, and why would it matter if it did?  The ChangeLog talks
> about the linker using the same file descriptors, but in that case
> won't this test see the descriptors as valid?)
> 
> Ian
> 

[committed] Support map + use_device_{addr,ptr} clauses for the same var on the same construct

[Jakub Jelinek]

Hi!

OpenMP 5.0 also newly says:
"If one or more of the use_device_ptr or use_device_addr clauses and one or 
more map
clauses are present on the same construct, the address conversions of 
use_device_addr and
use_device_ptr clauses will occur as if performed after all variables are 
mapped according to
those map clauses."
Before this rule, one had to use a separate target data or target enter data
to map the variables first before it was possible to use use_device_* on
another target data.

The patch allows such cases in the FEs, sorts the use_device_* clauses last
in the gimplifier, ensures omp lowering doesn't ICE on that and finally in
libgomp arranges that if the mapping clauses really precede all use_device_*
clauses and something has not been already found during the map clause
processing, we defer the use_device_* lookups until after the new variables
are mapped too.

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

2019-08-08  Jakub Jelinek  

* gimplify.c (omp_add_variable): Use GOVD_PRIVATE | GOVD_EXPLICIT
for VLA helper variables on target data even if not GOVD_FIRSTPRIVATE.
(gimplify_scan_omp_clauses): For OMP_CLAUSE_USE_DEVICE_* use just
GOVD_EXPLICIT flags.
(gimplify_omp_workshare): For OMP_TARGET_DATA move all
OMP_CLAUSE_USE_DEVICE_* clauses to the end of clauses chain.
* omp-low.c (scan_sharing_clauses): For OMP_CLAUSE_USE_DEVICE_*
call install_var_field with mask 11 instead of 3.
(lower_omp_target): For OMP_CLAUSE_USE_DEVICE_* use pass
(splay_tree_key) _UID (var) to build_sender_ref instead of var.
gcc/c/
* c-typeck.c (c_finish_omp_clauses): For C_ORT_OMP
OMP_CLAUSE_USE_DEVICE_* clauses use oacc_reduction_head bitmap
instead of generic_head to track duplicates.
gcc/cp/
* semantics.c (finish_omp_clauses): For C_ORT_OMP
OMP_CLAUSE_USE_DEVICE_* clauses use oacc_reduction_head bitmap
instead of generic_head to track duplicates.
libgomp/
* target.c (gomp_map_vars_internal): For GOMP_MAP_USE_DEVICE_PTR
perform the lookup in the first loop only if !not_found_cnt, otherwise
perform lookups for it in the second loop guarded with
if (not_found_cnt || has_firstprivate).
* testsuite/libgomp.c/target-37.c: New test.
* testsuite/libgomp.c++/target-22.C: New test.

--- gcc/gimplify.c.jj   2019-08-07 09:24:35.646096085 +0200
+++ gcc/gimplify.c  2019-08-07 12:32:49.927990656 +0200
@@ -6932,8 +6932,10 @@ omp_add_variable (struct gimplify_omp_ct
nflags = GOVD_MAP | GOVD_MAP_TO_ONLY | GOVD_EXPLICIT;
  else if (flags & GOVD_PRIVATE)
nflags = GOVD_PRIVATE;
- else if ((ctx->region_type & (ORT_TARGET | ORT_TARGET_DATA)) != 0
-  && (flags & GOVD_FIRSTPRIVATE))
+ else if (((ctx->region_type & (ORT_TARGET | ORT_TARGET_DATA)) != 0
+   && (flags & GOVD_FIRSTPRIVATE))
+  || (ctx->region_type == ORT_TARGET_DATA
+  && (flags & GOVD_DATA_SHARE_CLASS) == 0))
nflags = GOVD_PRIVATE | GOVD_EXPLICIT;
  else
nflags = GOVD_FIRSTPRIVATE;
@@ -9016,6 +9018,9 @@ gimplify_scan_omp_clauses (tree *list_p,
 
case OMP_CLAUSE_USE_DEVICE_PTR:
case OMP_CLAUSE_USE_DEVICE_ADDR:
+ flags = GOVD_EXPLICIT;
+ goto do_add;
+
case OMP_CLAUSE_IS_DEVICE_PTR:
  flags = GOVD_FIRSTPRIVATE | GOVD_EXPLICIT;
  goto do_add;
@@ -12404,8 +12409,27 @@ gimplify_omp_workshare (tree *expr_p, gi
  OMP_CLAUSES (expr));
   break;
 case OMP_TARGET_DATA:
-  stmt = gimple_build_omp_target (body, GF_OMP_TARGET_KIND_DATA,
- OMP_CLAUSES (expr));
+  /* Put use_device_{ptr,addr} clauses last, as map clauses are supposed
+to be evaluated before the use_device_{ptr,addr} clauses if they
+refer to the same variables.  */
+  {
+   tree use_device_clauses;
+   tree *pc, *uc = _device_clauses;
+   for (pc = _CLAUSES (expr); *pc; )
+ if (OMP_CLAUSE_CODE (*pc) == OMP_CLAUSE_USE_DEVICE_PTR
+ || OMP_CLAUSE_CODE (*pc) == OMP_CLAUSE_USE_DEVICE_ADDR)
+   {
+ *uc = *pc;
+ *pc = OMP_CLAUSE_CHAIN (*pc);
+ uc = _CLAUSE_CHAIN (*uc);
+   }
+ else
+   pc = _CLAUSE_CHAIN (*pc);
+   *uc = NULL_TREE;
+   *pc = use_device_clauses;
+   stmt = gimple_build_omp_target (body, GF_OMP_TARGET_KIND_DATA,
+   OMP_CLAUSES (expr));
+  }
   break;
 case OMP_TEAMS:
   stmt = gimple_build_omp_teams (body, OMP_CLAUSES (expr));
--- gcc/omp-low.c.jj2019-08-07 09:24:35.647096069 +0200
+++ gcc/omp-low.c   2019-08-07 11:12:44.137779196 +0200
@@ -1243,9 +1243,9 @@ scan_sharing_clauses (tree clauses, omp_
  if ((OMP_CLAUSE_CODE (c) 

Re: Start implementing -frounding-math

[Marc Glisse]

On Wed, 7 Aug 2019, Joseph Myers wrote:


On Sat, 22 Jun 2019, Marc Glisse wrote:


as discussed in the PR, this seems like a simple enough approach to handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.


Could you give a high-level description of the implementation approach,


At the GIMPLE level, z = x + y is represented as a function call z = 
.FENV_PLUS (x, y, options). The floating point environment (rounding mode, 
exceptions) is considered to be somewhere in memory (I think it still 
works if it is a hard register). Unless options say so, .FENV_PLUS may 
read/write to memory. There are very little optimizations that can be done 
on general function calls, so this should avoid unwanted movement or 
removal. We can still implement some specific optimizations just for those 
functions.


At the RTL level, well the idea is that good back-ends would expand 
.FENV_PLUS however they want, but the default is to have the arguments and 
the result use an asm volatile pass-through, which is opaque to optimizers 
and prevents constant propagation, removal, movement, etc.


(the use of "options" is to avoid having many variants depending on 
whether we only care about rounding, exceptions, maybe ignore signed 
zeros, etc, with 0 as the strictest, always-safe version. For explicitly 
rounded operations as with pragma fenv_round, a different function might 
be better since the 0 case is not a safe replacement anymore)



and how this design is intended to (eventually) achieve the required
constraints on code movement and removal?  In
 I listed those
constraints as:

* General calls may set, clear or test exceptions, or manipulate the
rounding mode
(as may asms, depending on their inputs / outputs / clobbers).


If the asm is volatile, this works fine. I'll come back to this below.


* Floating-point operations have the rounding mode as input.  They may set
(but not clear or test) floating-point exception flags.

* Thus in general floating-point operations may not be moved across most
calls (or relevant asms), or values from one side of a call reused for the
same operation with the same inputs appearing on the other side of the
call.

* Statements such as "(void) (a * b);" can't be eliminated because they
may raise exceptions.  (That's purely about exceptions, not rounding
modes.)


I had to add TREE_SIDE_EFFECTS = 1 so the C++ front-end wouldn't remove it 
prematurely.



(I should add that const function calls should not depend on the rounding
mode, but pure calls may.


That perfectly fits with the idea of having the FP env as part of memory.


Also, on some architectures there are explicit
register names for asms to use in inputs / outputs / clobbers to refer to
the floating-point state registers, and asms not referring to those can be
taken not to manipulate floating-point state, but other architectures
don't have such names.  The safe approach for asms would be to assume that
all asms on all architectures can manipulate floating-point state, until
there is a way to declare what the relevant registers are.)


I assume that an asm using this register as a constraint is already 
prevented from moving across function calls somehow? If so, at least 
gimple seems safe.


For RTL, if those asm were volatile, the default expansion would be fine. 
If they don't need to be and somehow manage to cross the pass-through asm, 
I guess a target hook to add extra input/output/clobber to the 
pass-through asm would work. Or best the target would expand the 
operations to (unspec) insns that explicitly handle exactly those 
registers.



(I should also note that DFP has a separate rounding mode from binary FP,
but that is unlikely to affect anything in this patch - although there
might end up being potential minor optimizations from knowing that certain
asms only involve one of the two rounding modes.)


I'd like to handle this incrementally, rather than wait for a mega-patch that
does everything, if that's ok. For instance, I didn't handle vectors in this
first patch because the interaction with vector lowering was not completely
obvious. Plus it may help get others to implement some parts of it ;-)


Are there testcases that could be added initially to demonstrate how this
fixes cases that are currently broken, even if other cases aren't fixed?


Yes. I'll need to look into dg-require-effective-target fenv(_exceptions) 
to see how to disable those new tests where they are not supported. There 
are many easy tests that already start working, say computing 1./3 twice 
with a change of rounding mode in between and checking that the results 
differ, or computing 1./3 and ignoring the result but checking FE_INEXACT.



On Wed, 7 Aug 2019, Joseph Myers wrote:


On Sun, 23 Jun 2019, Marc Glisse wrote:


For constant expressions, I see a difference between
constexpr double third = 1. / 3.;
which really needs to be done at compile 

[testsuite] use rand instead of random

[Alexandre Oliva]

rand is in ISO C, whereas random is only in POSIX, so it makes sense
to use the more portable function everywhere instead of falling back
from one to the other on systems that miss the less portable one.

Tested on x86_64-linux-gnu, native and cross to ppc.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/i386/sse2-mul-1.c: Use rand.  Drop fallback.
* gcc.target/i386/sse4_1-blendps-2.c: Likewise.
* gcc.target/i386/sse4_1-blendps.c: Likewise.
* gcc.target/i386/xop-vshift-1.c: Likewise.
* gcc.target/powerpc/direct-move.h: Likewise.
---
 gcc/testsuite/gcc.target/i386/sse2-mul-1.c   |   13 -
 gcc/testsuite/gcc.target/i386/sse4_1-blendps-2.c |7 +--
 gcc/testsuite/gcc.target/i386/sse4_1-blendps.c   |7 +--
 gcc/testsuite/gcc.target/i386/xop-vshift-1.c |9 ++---
 gcc/testsuite/gcc.target/powerpc/direct-move.h   |2 +-
 5 files changed, 9 insertions(+), 29 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/sse2-mul-1.c 
b/gcc/testsuite/gcc.target/i386/sse2-mul-1.c
index 9cdc12763b0b9..af63d245d7916 100644
--- a/gcc/testsuite/gcc.target/i386/sse2-mul-1.c
+++ b/gcc/testsuite/gcc.target/i386/sse2-mul-1.c
@@ -14,11 +14,6 @@
 
 #include 
 
-/* mingw runtime don't provide random().  */
-#ifdef __MINGW32__
-#define random rand
-#endif
-
 #define N 512
 static short a1[N], a2[N], a3[N];
 static unsigned short b1[N], b2[N], b3[N];
@@ -160,12 +155,12 @@ TEST (void)
   asm volatile ("" : : "r" () : "memory");
   asm volatile ("" : : "r" () : "memory");
   asm volatile ("" : : "r" () : "memory");
-  b2[i] = (int) random ();
-  b3[i] = (int) random ();
+  b2[i] = (int) rand ();
+  b3[i] = (int) rand ();
   a2[i] = b2[i];
   a3[i] = b3[i];
-  d2[i] = (((int) random ()) << 16) | b2[i];
-  d3[i] = (((int) random ()) << 16) | b3[i];
+  d2[i] = (((int) rand ()) << 16) | b2[i];
+  d3[i] = (((int) rand ()) << 16) | b3[i];
   c2[i] = d2[i];
   c3[i] = d3[i];
   s1 += a2[i] * a3[i];
diff --git a/gcc/testsuite/gcc.target/i386/sse4_1-blendps-2.c 
b/gcc/testsuite/gcc.target/i386/sse4_1-blendps-2.c
index 8fe71b71c576a..512394ea37a00 100644
--- a/gcc/testsuite/gcc.target/i386/sse4_1-blendps-2.c
+++ b/gcc/testsuite/gcc.target/i386/sse4_1-blendps-2.c
@@ -8,11 +8,6 @@
 #include 
 #include 
 
-/* mingw runtime don't provide random().  */
-#ifdef __MINGW32__
-#define random rand
-#endif
-
 #define NUM 20
 
 #undef MASK
@@ -64,7 +59,7 @@ sse4_1_test (void)
   init_blendps (src1.f, src2.f);
 
   for (i = 0; i < 4; i++)
-src3.f[i] = (int) random ();
+src3.f[i] = (int) rand ();
 
   /* Check blendps imm8, m128, xmm */
   for (i = 0; i < NUM; i++)
diff --git a/gcc/testsuite/gcc.target/i386/sse4_1-blendps.c 
b/gcc/testsuite/gcc.target/i386/sse4_1-blendps.c
index 3f4b335aca6ae..556094bf9530e 100644
--- a/gcc/testsuite/gcc.target/i386/sse4_1-blendps.c
+++ b/gcc/testsuite/gcc.target/i386/sse4_1-blendps.c
@@ -16,11 +16,6 @@
 #include 
 #include 
 
-/* mingw runtime don't provide random().  */
-#ifdef __MINGW32__
-#define random rand
-#endif
-
 #define NUM 20
 
 #ifndef MASK
@@ -73,7 +68,7 @@ TEST (void)
   init_blendps (src1.f, src2.f);
 
   for (i = 0; i < 4; i++)
-src3.f[i] = (int) random ();
+src3.f[i] = (int) rand ();
 
   /* Check blendps imm8, m128, xmm */
   for (i = 0; i < NUM; i++)
diff --git a/gcc/testsuite/gcc.target/i386/xop-vshift-1.c 
b/gcc/testsuite/gcc.target/i386/xop-vshift-1.c
index ee3d2990390ab..f3713e8ffc656 100644
--- a/gcc/testsuite/gcc.target/i386/xop-vshift-1.c
+++ b/gcc/testsuite/gcc.target/i386/xop-vshift-1.c
@@ -19,11 +19,6 @@
 #define TYPE2 long long
 #endif
 
-/* mingw runtime don't provide random().  */
-#ifdef __MINGW32__
-#define random rand
-#endif
-
 signed TYPE1 a[N], b[N], g[N];
 unsigned TYPE1 c[N], h[N];
 signed TYPE2 d[N], e[N], j[N];
@@ -108,10 +103,10 @@ TEST ()
   for (i = 0; i < N; i++)
 {
   asm ("");
-  c[i] = (random () << 1) | (random () & 1);
+  c[i] = (rand () << 1) | (rand () & 1);
   b[i] = (i * 85) & (sizeof (TYPE1) * __CHAR_BIT__ - 1);
   a[i] = c[i];
-  d[i] = (random () << 1) | (random () & 1);
+  d[i] = (rand () << 1) | (rand () & 1);
   d[i] |= (unsigned long long) c[i] << 32;
   e[i] = (i * 85) & (sizeof (TYPE2) * __CHAR_BIT__ - 1);
   f[i] = d[i];
diff --git a/gcc/testsuite/gcc.target/powerpc/direct-move.h 
b/gcc/testsuite/gcc.target/powerpc/direct-move.h
index e29f10f5cd54f..80874adcea1ae 100644
--- a/gcc/testsuite/gcc.target/powerpc/direct-move.h
+++ b/gcc/testsuite/gcc.target/powerpc/direct-move.h
@@ -179,7 +179,7 @@ main (void)
   for (j = 0; j < 10; j++)
 {
   for (i = 0; i < sizeof (TYPE); i++)
-   u.bytes[i] = (unsigned char) (random () >> 4);
+   u.bytes[i] = (unsigned char) (rand () >> 4);
 
   test_value (u.value);
 }

-- 
Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF 

Re: [PATCH 9/9] Remove alias set comparison.

[Martin Liška]

On 8/7/19 5:20 PM, Martin Sebor wrote:
> On 6/11/19 1:36 AM, Martin Liska wrote:
>>
>> gcc/ChangeLog:
>>
>> 2019-07-24  Martin Liska  
>>
>> * ipa-icf-gimple.c (func_checker::compatible_types_p):
>> Do not compare alias sets.  It's handled by operand_equal_p.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2019-07-24  Martin Liska  
>>
>> * c-c++-common/Wstringop-truncation-4.c: Disable IPA ICF.
> 
> What fails without the change?

ICF will newly merge these functions:

grep hit: Wstringop-truncation-4.c.070i.icf 
Semantic equality hit:void test_arrays(Arrays*, const char*)->void 
test_const_arrays(ConstArrays*, const char*)
Semantic equality hit:void test_arrays(Arrays*, const char*)->void 
test_volatile_arrays(VolatileArrays*, const char*)
Semantic equality hit:void test_arrays(Arrays*, const char*)->void 
test_const_volatile_arrays(ConstVolatileArrays*, const char*)

So we'll get less warnings than expected.

Martin

> 
> Thanks
> Martin
> 
>> * gcc.dg/tree-ssa/pr64910-2.c: Likewise.
>> * gcc.dg/tree-ssa/pr79352.c: Likewise.
>> * gcc.dg/ipa/ipa-icf-40.c: New test.
>> ---
>>   gcc/ipa-icf-gimple.c  | 12 ---
>>   .../c-c++-common/Wstringop-truncation-4.c |  2 +-
>>   gcc/testsuite/gcc.dg/ipa/ipa-icf-40.c | 32 +++
>>   gcc/testsuite/gcc.dg/tree-ssa/pr64910-2.c |  2 +-
>>   gcc/testsuite/gcc.dg/tree-ssa/pr79352.c   |  2 +-
>>   5 files changed, 35 insertions(+), 15 deletions(-)
>>   create mode 100644 gcc/testsuite/gcc.dg/ipa/ipa-icf-40.c
>>
> 

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

[Mark Eggleston]

On 07/08/2019 19:56, Steve Kargl wrote:

On Wed, Aug 07, 2019 at 09:09:49AM -0700, Steve Kargl wrote:

On Wed, Aug 07, 2019 at 01:58:17PM +0100, Mark Eggleston wrote:

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

Prior versions of gfortran give

% gfc9 -c a.f90
a.f90:3:10:

 3 |data c / z'41424344' /
   |  1
Error: Incompatible types in DATA statement at (1); attempted conversion of 
INTEGER(16) to CHARACTER(1)

I have a patch that now does

gfcx -c a.f90
a.f90:3:10-23:

 3 |data c / z'41424344' /
   |  12
Error: data-stmt-object at (1) has type 'CHARACTER', which conflicts with the 
BOZ literal constant at (2)


Is there any particular reason for reverting to the earlier behaviour 
instead of fixing the contents of c?


"C4102 (R463) A boz-literal-constant shall appear only as a 
data-stmt-constant in a DATA statement, or where explicitly allowed in 
subclause 13.7 as an actual argument of an intrinsic procedure." from 
the 2008 standard implies that the use of a BOZ in the data statement of 
a character variable is allowed, it doesn't say that it is restricted to 
numeric types.




BTW, -fallow-invalid-boz does enable all previous broken
usages of BOZ.


In that case comparisons with BOZ should be allowed but they are not as 
indicated in my previous e-mail 
https://gcc.gnu.org/ml/fortran/2019-08/msg00031.html


regards,

Mark


   For example, BOZ can be an actual argument
in only a few intrinsic subprograms listed in F2018.  I've
allowed only a few exceptions such as AND(z'1234',4242)
which mirros IAND() is documented behavior.

PS: Have you gotten write access to the source code repository, yet?


--
https://www.codethink.co.uk/privacy.html

Re: [PATCH] Handle new operators with no arguments in DCE.

[Martin Liška]

On 8/7/19 4:12 PM, Richard Biener wrote:
> On Wed, Aug 7, 2019 at 2:04 PM Martin Liška  wrote:
>>
>> On 8/7/19 12:51 PM, Jakub Jelinek wrote:
>>> On Wed, Aug 07, 2019 at 12:44:28PM +0200, Martin Liška wrote:
 On 8/7/19 11:51 AM, Richard Biener wrote:
> I think the simplest way to achieve this is to not copy, aka clear,
> DECL_IS_OPERATOR_* when cloning and removing arguments
> (cloning for a constant align argument should be OK for example, as is
> for a constant address).  Or simply always when cloning.

 Ok, then I'm suggesting following tested patch.

 Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> What about LAMBDA_FUNCTION, doesn't cloning which changes arguments in any
>>> way invalidate that too, i.e. shouldn't it be just
>>>   FUNCTION_DECL_DECL_TYPE (new_node->decl) = NONE;
>>
>> Well, how are lambdas involved in the new/delete DCE here? Lambdas with 
>> removed
>> arguments should not interfere here.
> 
> But for coverage where we do
> 
>   gcov_write_unsigned (DECL_ARTIFICIAL (current_function_decl)
>&& !DECL_FUNCTION_VERSIONED (current_function_decl)
>&& !DECL_LAMBDA_FUNCTION_P (current_function_decl));
> 
> all clones should be considered artificial?

Well, from coverage perspective most of them are fine.

> 
> Anyway, your patch is OK, we can think about lambdas separately.  Can you
> simplify the DCE code after the patch?

I installed the patch and I'm sending the follow up cleanup.

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

Ready to be installed?
Thanks,
Martin

> 
> Thanks,
> Richard.
> 
>>> instead?  On the other side, if the cloning doesn't change arguments in any
>>> way, do we still want to clear those flags?
>>
>> Well, I would consider it safer to drop it always.
>>
>> Martin
>>
>>>
>>>   Jakub
>>>
>>

>From 9da5bd0a2c81a20807caf9cc6915971067b021c3 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 8 Aug 2019 09:58:34 +0200
Subject: [PATCH] Clean up dead condition for operators in DCE.

gcc/ChangeLog:

2019-08-08  Martin Liska  

	* tree-ssa-dce.c (propagate_necessity): We can't reach now
	operators with no arguments.
	(eliminate_unnecessary_stmts): Likewise here.
---
 gcc/tree-ssa-dce.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index afb7bd9dedc..80d5f5c30f7 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -810,11 +810,6 @@ propagate_necessity (bool aggressive)
 	  if (is_delete_operator
 	  || gimple_call_builtin_p (stmt, BUILT_IN_FREE))
 	{
-	  /* It can happen that a user delete operator has the pointer
-		 argument optimized out already.  */
-	  if (gimple_call_num_args (stmt) == 0)
-		continue;
-
 	  tree ptr = gimple_call_arg (stmt, 0);
 	  gimple *def_stmt;
 	  tree def_callee;
@@ -1328,18 +1323,13 @@ eliminate_unnecessary_stmts (void)
 		  || (is_gimple_call (stmt)
 		  && gimple_call_operator_delete_p (as_a  (stmt)
 	{
-	  /* It can happen that a user delete operator has the pointer
-		 argument optimized out already.  */
-	  if (gimple_call_num_args (stmt) > 0)
+	  tree ptr = gimple_call_arg (stmt, 0);
+	  if (TREE_CODE (ptr) == SSA_NAME)
 		{
-		  tree ptr = gimple_call_arg (stmt, 0);
-		  if (TREE_CODE (ptr) == SSA_NAME)
-		{
-		  gimple *def_stmt = SSA_NAME_DEF_STMT (ptr);
-		  if (!gimple_nop_p (def_stmt)
-			  && !gimple_plf (def_stmt, STMT_NECESSARY))
-			gimple_set_plf (stmt, STMT_NECESSARY, false);
-		}
+		  gimple *def_stmt = SSA_NAME_DEF_STMT (ptr);
+		  if (!gimple_nop_p (def_stmt)
+		  && !gimple_plf (def_stmt, STMT_NECESSARY))
+		gimple_set_plf (stmt, STMT_NECESSARY, false);
 		}
 	}
 
-- 
2.22.0

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

[Martin Liška]

On 7/11/19 11:42 AM, Richard Biener wrote:
> On Wed, Jul 10, 2019 at 5:52 PM Richard Biener
>  wrote:
>>
>> On July 10, 2019 2:11:17 PM GMT+02:00, Michael Matz  wrote:
>>> Hi,
>>>
>>> On Tue, 9 Jul 2019, Richard Biener wrote:
>>>
> The basic block index is not a DFS index, so no, that's not a test
>>> for
> backedge.

 I think in CFG RTL mode the BB index designates the order of the BBs
>>> in
 the object file? So this is a way to identify backwards jumps?
>>>
>>> Even if it means a backwards jump (and that's not always the case, the
>>> insns are emitted by following the NEXT_INSN links, without a CFG, and
>>> that all happens after machine-dependend reorg, and going out of cfg
>>> layout might link insn together even from high index BBs to low index
>>> BBs
>>> (e.g. because of fall-through)), that's still not a backedge in the
>>> general case.  If a heuristic is enough here it might be okay, though.
>>>
>>> OTOH, as here a CFG still exists, why not simply rely on a proper DFS
>>> marking backedges?
>>
>> Because proper backedges is not what we want here, see honzas example.
>>
>> So I'm second-guessing why we have different LOOP_ALIGN and when it makes 
>> sense to apply.
> 
> So docs have
> 
> @defmac JUMP_ALIGN (@var{label})
> The alignment (log base 2) to put in front of @var{label}, which is
> a common destination of jumps and has no fallthru incoming edge.
> 
> ...
> 
> @defmac LOOP_ALIGN (@var{label})
> The alignment (log base 2) to put in front of @var{label} that heads
> a frequently executed basic block (usually the header of a loop).
> 
> so I would expect the alignment pass to have
> 
>   if ( (branch_count > count_threshold
>   || (bb->count > bb->prev_bb->count.apply_scale (10, 1)
>   && (bb->prev_bb->count
>   <= ENTRY_BLOCK_PTR_FOR_FN (cfun)
>->count.apply_scale (1, 2)
> {
>   align_flags alignment = has_fallthru ? JUMP_ALIGN (label) :
> LOOP_ALIGN (label);
>   if (dump_file)
> fprintf (dump_file, "  jump alignment added.\n");
>   max_alignment = align_flags::max (max_alignment, alignment);
> }

Sorry for the delay.

> 
> instead of the two different conditions?  Or the JUMP_ALIGN case
> computing "common destination" instead of "frequently executed"
> somehow but I think it makes sense that those are actually the same
> here (frequently executed).  It oddly looks at prev_bb and is not
> guarded with optimize_bb_for_speed_p at all so this all is
> full of heuristics and changing anything here just based on x86
> measurements is surely going to cause issues for targets more
> sensitive to (mis-)alignment.

I like you patch, it's a rapid simplification of the code which
we have there.

I'm sending LNT results before and after the revision. It show
there are quite some significant changes. lbm is a known issue
where we are lucky with the patch.

Thoughts?
Martin

> 
> Richard.
> 
>> Richard.
>>
>>>
>>> Ciao,
>>> Michael.
>>

>From b5cad0c2bdc611aedf32a839ead1774fd82fdad4 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 6 Aug 2019 18:09:25 +0200
Subject: [PATCH] Simplify alignment.

---
 gcc/final.c | 32 
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/gcc/final.c b/gcc/final.c
index fefc4874b24..b33dfc6646e 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -722,32 +722,16 @@ compute_alignments (void)
 	 than the predecessor and the predecessor is likely to not be executed
 	 when function is called.  */
 
-  if (!has_fallthru
-	  && (branch_count > count_threshold
-	  || (bb->count > bb->prev_bb->count.apply_scale (10, 1)
-		  && (bb->prev_bb->count
-		  <= ENTRY_BLOCK_PTR_FOR_FN (cfun)
-			   ->count.apply_scale (1, 2)
+  if (branch_count > count_threshold
+	  || (bb->count > bb->prev_bb->count.apply_scale (10, 1)
+	  && (bb->prev_bb->count
+		  <= ENTRY_BLOCK_PTR_FOR_FN (cfun)->count.apply_scale (1, 2
 	{
-	  align_flags alignment = JUMP_ALIGN (label);
+	  align_flags alignment
+	= has_fallthru ? JUMP_ALIGN (label) : LOOP_ALIGN (label);
 	  if (dump_file)
-	fprintf (dump_file, "  jump alignment added.\n");
-	  max_alignment = align_flags::max (max_alignment, alignment);
-	}
-  /* In case block is frequent and reached mostly by non-fallthru edge,
-	 align it.  It is most likely a first block of loop.  */
-  if (has_fallthru
-	  && !(single_succ_p (bb)
-	   && single_succ (bb) == EXIT_BLOCK_PTR_FOR_FN (cfun))
-	  && optimize_bb_for_speed_p (bb)
-	  && branch_count + fallthru_count > count_threshold
-	  && (branch_count
-	  > fallthru_count.apply_scale
-		(PARAM_VALUE (PARAM_ALIGN_LOOP_ITERATIONS), 1)))
-	{
-	  align_flags alignment = LOOP_ALIGN (label);
-	  if (dump_file)
-	fprintf (dump_file, "  internal loop alignment added.\n");
+	fprintf (dump_file, "  %s alignment added.\n",
+		 has_fallthru ? "loop" : "internal 

Re: [PATCH 3/9] ifcvt: Only created temporaries as needed.

[Robin Dapp]

Hi Richard,

> Is the separate need_temps scan required for correctness?  It looked
> like we could test:
> 
>   if (reg_overlap_mentioned_p (dest, cond))
>   ...
> 
> on-the-fly during the main noce_convert_multiple_sets loop.

right, I didn't re-check it but after changes during interal patch
rounds the check is now degenerated enought to allow this. Going to
refactor that.

> Would it work to set temporaries[i] to targets[i] whenever a temporary
> isn't needed, and avoid temps_created?

Yes, that should work. Already made that change locally.

Regards
 Robin

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

[Mark Eggleston]

On 07/08/2019 17:09, Steve Kargl wrote:

On Wed, Aug 07, 2019 at 01:58:17PM +0100, Mark Eggleston wrote:

BOZ problems in the following areas

   * use of logical and character variables with BOZ constants
   * comparisons with BOZ constants
   * DATA statements

Comparing 9.1 and trunk:

The comparison is somewhat irrelevant.  I removed a
a number of undocumented extensions when I made the
handling of BOZ conform to the F2018 Fortran standard.


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. 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.




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


For the first testcase, that should be rejected.  I thought I had
that fixed in my tree.  It probably got lost in one of numerous
versions of the BOZ rewrite.


Apologies if this should have been reported via bugzilla. If so let me
know and I'll submit it split into 2 or 3 bug reports.

Reporting it here is fine.  I'll look at rejecting the one code
that compiles (as it shouldn't).  And, I'll toy with adding BOZ
as an operand of binary operators (I actually had this working in
an ancient patch) under -fallow-invalid-boz.



regards,

Mark

--
https://www.codethink.co.uk/privacy.html

Re: [PATCH 5/9] ifcvt: Allow constants operands in noce_convert_multiple_sets.

[Robin Dapp]

> It seems like this is making noce_convert_multiple_sets overlap
> a lot with cond_move_process_if_block (although that uses CONSTANT_P
> instead of CONST_INT_P).  How do they fit together after this patch,
> i.e. which cases is each one meant to handle that the other doesn't?

IMHO all of icvt is currently one unholy overlap with itself and the
backend where at least I could not decipher within reasonable time which
part is supposed to cover what :) Ok, it might not be that bad...

Currently convert_multiple only handles situations without an else_bb
but that seems a rather artificial limit and I see no reason why it
could not be unified with cond_move_process_if_block at a later time.

Regards
 Robin

[RFC] Some questions on aarch64 feature about IDC and DIC

[Shaokun Zhang]

Hi aarch64 maintainers,

Question 1:
In __aarch64_sync_cache_range function, if CTR_EL0.IDC = 0b1,
Shall the dc cvau and the dsb ish will be removed or
only dc cvau will be removed?

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

Question 2:
In __aarch64_sync_cache_range function, if CTR_EL0.DIC = 0b1,
Shall the ic ivau, dsb ish and isb will be removed or
only ic ivau and dsb ish will be removed, only isb left?
-  for (; address < (const char *) end; address += icache_lsize)
-asm volatile ("ic\tivau, %0"
- :
- : "r" (address)
- : "memory");
-
-  asm volatile ("dsb\tish; isb" : : : "memory");

Question 3:
For ic ivau/iallu/ialluis, is there any other place that would use these 
instructions except
self-modify scenario?

Question 4:
If CTR_EL0.IDC = 0b1 and CTR_EL0.DIC = 0b1, if software still execute ic 
ivau/iallu/ialluis
instrution, is it ok for cpu to treat it as NOP?

Cheers,
Shaokun

Re: [C++ Patch] More grokdeclarator locations fixes

[Jason Merrill]

On 8/8/19 5:41 AM, Paolo Carlini wrote:

Hi,

these are all more or less straightforward, exploit the existing 
infrastructure. Nits: the first change also removes an 'a' in the 
wording because all the other error messages - a few - mentioning class 
or namespace don't have it; the fixes using EXPR_LOCATION also change 
%qD to %qE because we are dealing with BIT_NOT_EXPRs.


OK.

Jason

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

[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: C++ PATCH for c++/87519 - bogus warning with -Wsign-conversion

[Jason Merrill]

On 8/8/19 10:50 AM, Marek Polacek wrote:

This PR complains about bogus -Wsign-conversion warning even with an
explicit cast, which the documentation says should suppress the warning.
Pretty similar to c++/86190 which I fixed here
.

The problem only happens when using a typedef, because in cp_build_binary_op
we're comparing the types using ==, which I think only works for canonical
types.  So use same_type_p to avoid this problem.

Bootstrapped/regtested on x86_64-linux, ok for trunk?  I think it makes sense
to fix in in 9.3 too.


OK for both.

Jason

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

[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

Re: [C] Fix bogus nested enum error message

[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

Re: Use predicates for RTL objects

[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: [PATCH] enable gcc.dg/struct-ret-1.c on all targets

[Jeff Law]

On 8/7/19 5:15 PM, Martin Sebor wrote:
> This test is reported as UNSUPPORTED when it runs on x86_64
> and I expect everywhere else except hppa-*-*.  There's nothing
> PA-RISC specific in it that I can see and it runs successfully,
> so I'm thinking I'll enable it everywhere just to get rid of
> the UNSUPPORTED result.
> 
> Jeff, it's a test you added back in 1997.  If you can think
> of a reason not to enable it please let me know, otherwise
> I'll go ahead with it as obvious.
> 
Actually I added it in 1995, 1997 is when we moved to a real VCS for GCC
development :-)



+Thu Jun  1 00:06:19 1995  Jeff Law  (l...@snake.cs.utah.edu)
+
+   * gcc.c-torture/compile/950512-1.c: New test.
+   * gcc.c-torture/execute/strct-pack-4.c, strct-pack-5.c}: Likewise.
+   * gcc.dg/struct-ret-1.c: Likewise.


Given the date and the contents of the test I suspect it won't
necessarily work on PCC_STATIC_STRUCT_RETURN targets which we still
cared about that the time.  Structure returns in general were
problematical and I was probably just being very conservative.

One could argue that PCC_STATIC_STRUCT_RETURN should just go away.
There's only two ports using it.  One is the m68k-openbsd port which I
think has been dead for several years and could probably just be
deprecated and removed.  The other is the vax -- I have no idea how hard
it would be for them to drop PCC_STATIC_STRUCT_RETURN since I don't know
their ABI stability concerns or need for compatibility with ancient vax
compilers.

So, no objections to the change.  Worst case is the vax guys would see a
failure for that test.  If they complain we can open the discussion
about dropping PCC_STATIC_STRUCT_RETURN.

jeff

Re: [testsuite] use rand instead of random

[Jeff Law]

On 8/8/19 12:30 AM, Alexandre Oliva wrote:
> rand is in ISO C, whereas random is only in POSIX, so it makes sense
> to use the more portable function everywhere instead of falling back
> from one to the other on systems that miss the less portable one.
> 
> Tested on x86_64-linux-gnu, native and cross to ppc.  Ok to install?
> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/i386/sse2-mul-1.c: Use rand.  Drop fallback.
>   * gcc.target/i386/sse4_1-blendps-2.c: Likewise.
>   * gcc.target/i386/sse4_1-blendps.c: Likewise.
>   * gcc.target/i386/xop-vshift-1.c: Likewise.
>   * gcc.target/powerpc/direct-move.h: Likewise.
OK
jeff

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

[Jeff Law]

On 8/5/19 6:32 AM, Uros Bizjak wrote:
> On Mon, Aug 5, 2019 at 1:50 PM Richard Biener  wrote:
>>
>> On Sun, 4 Aug 2019, Uros Bizjak wrote:
>>
>>> On Sat, Aug 3, 2019 at 7:26 PM Richard Biener  wrote:

 On Thu, 1 Aug 2019, Uros Bizjak wrote:

> On Thu, Aug 1, 2019 at 11:28 AM Richard Biener  wrote:
>
 So you unconditionally add a smaxdi3 pattern - indeed this looks
 necessary even when going the STV route.  The actual regression
 for the testcase could also be solved by turing the smaxsi3
 back into a compare and jump rather than a conditional move sequence.
 So I wonder how you'd do that given that there's pass_if_after_reload
 after pass_split_after_reload and I'm not sure we can split
 as late as pass_split_before_sched2 (there's also a split _after_
 sched2 on x86 it seems).

 So how would you go implement {s,u}{min,max}{si,di}3 for the
 case STV doesn't end up doing any transform?
>>>
>>> If STV doesn't transform the insn, then a pre-reload splitter splits
>>> the insn back to compare+cmove.
>>
>> OK, that would work.  But there's no way to force a jumpy sequence then
>> which we know is faster than compare+cmove because later RTL
>> if-conversion passes happily re-discover the smax (or conditional move)
>> sequence.
>>
>>> However, considering the SImode move
>>> from/to int/xmm register is relatively cheap, the cost function should
>>> be tuned so that STV always converts smaxsi3 pattern.
>>
>> Note that on both Zen and even more so bdverN the int/xmm transition
>> makes it no longer profitable but a _lot_ slower than the cmp/cmov
>> sequence... (for the loop in hmmer which is the only one I see
>> any effect of any of my patches).  So identifying chains that
>> start/end in memory is important for cost reasons.
>
> Please note that the cost function also considers the cost of move
> from/to xmm. So, the cost of the whole chain would disable the
> transformation.
>
>> So I think the splitting has to happen after the last if-conversion
>> pass (and thus we may need to allocate a scratch register for this
>> purpose?)
>
> I really hope that the underlying issue will be solved by a machine
> dependant pass inserted somewhere after the pre-reload split. This
> way, we can split unconverted smax to the cmove, and this later pass
> would handle jcc and cmove instructions. Until then... yes your
> proposed approach is one of the ways to avoid unwanted if-conversion,
> although sometimes we would like to split to cmove instead.

 So the following makes STV also consider SImode chains, re-using the
 DImode chain code.  I've kept a simple incomplete smaxsi3 pattern
 and also did not alter the {SI,DI}mode chain cost function - it's
 quite off for TARGET_64BIT.  With this I get the expected conversion
 for the testcase derived from hmmer.

 No further testing sofar.

 Is it OK to re-use the DImode chain code this way?  I'll clean things
 up some more of course.
>>>
>>> Yes, the approach looks OK to me. It makes chain building mode
>>> agnostic, and the chain building can be used for
>>> a) DImode x86_32 (as is now), but maybe 64bit minmax operation can be added.
>>> b) SImode x86_32 and x86_64 (this will be mainly used for SImode
>>> minmax and surrounding SImode operations)
>>> c) DImode x86_64 (also, mainly used for DImode minmax and surrounding
>>> DImode operations)
>>>
 Still need help with the actual patterns for minmax and how the splitters
 should look like.
>>>
>>> Please look at the attached patch. Maybe we can add memory_operand as
>>> operand 1 and operand 2 predicate, but let's keep things simple for
>>> now.
>>
>> Thanks.  The attached patch makes the patch cleaner and it survives
>> "some" barebone testing.  It also touches the cost function to
>> avoid being too overly trigger-happy.  I've also ended up using
>> ix86_cost->sse_op instead of COSTS_N_INSN-based magic.  In
>> particular we estimated GPR reg-reg move as COST_N_INSNS(2) while
>> move costs shouldn't be wrapped in COST_N_INSNS.
>> IMHO we should probably disregard any reg-reg moves for costing pre-RA.
>> At least with the current code every reg-reg move biases in favor of
>> SSE...
> 
> This is currently a bit mixed-up area in x86 target support. HJ is
> looking into this [1] and I hope Honza can review the patch.
Yea, Honza's input on that would be greatly appreciated.

Jeff
> 

Re: [PATCH 5/9] Come up with an abstraction.

[Michael Matz]

Hi,

On Mon, 10 Jun 2019, Martin Liska wrote:

> 2019-07-24  Martin Liska  
> 
>   * fold-const.c (operand_equal_p): Rename to ...
>   (operand_compare::operand_equal_p): ... this.
>   (add_expr):  Rename to ...
>   (operand_compare::hash_operand): ... this.
>   (operand_compare::operand_equal_valueize): Likewise.
>   (operand_compare::hash_operand_valueize): Likewise.
>   * fold-const.h (operand_equal_p): Set default
>   value for last argument.
>   (class operand_compare): New.

Hmpf.  A class without any data?  That doesn't sound like a good design.  
You seem to need it only to have the possibility of virtual functions, 
i.e. fancy callbacks.  AFAICS you only have one derived class, i.e. a 
simple distinction of two cases.  What do you think about encoding the 
additional new (ICF) case in the (existing) 'flags' argument to 
operand_equal_p (and in case the ICF flag is set simply call the 
"callback" directly)?  IMHO that would also make the logic within 
operand_equal_p clearer, because you don't have to think about all the 
potential callback functions that might be called.


Ciao,
Michael.

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

[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

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

[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

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

[Steve Kargl]

On Thu, Aug 08, 2019 at 09:31:37AM +0100, Mark Eggleston wrote:
> 
> On 07/08/2019 19:56, Steve Kargl wrote:
> > On Wed, Aug 07, 2019 at 09:09:49AM -0700, Steve Kargl wrote:
> >> On Wed, Aug 07, 2019 at 01:58:17PM +0100, Mark Eggleston wrote:
> >>> 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
> > Prior versions of gfortran give
> >
> > % gfc9 -c a.f90
> > a.f90:3:10:
> >
> >  3 |data c / z'41424344' /
> >|  1
> > Error: Incompatible types in DATA statement at (1); attempted conversion of 
> > INTEGER(16) to CHARACTER(1)
> >
> > I have a patch that now does
> >
> > gfcx -c a.f90
> > a.f90:3:10-23:
> >
> >  3 |data c / z'41424344' /
> >|  12
> > Error: data-stmt-object at (1) has type 'CHARACTER', which conflicts with 
> > the BOZ literal constant at (2)
> 
> Is there any particular reason for reverting to the earlier behaviour 
> instead of fixing the contents of c?
> 
> "C4102 (R463) A boz-literal-constant shall appear only as a 
> data-stmt-constant in a DATA statement, or where explicitly allowed in 
> subclause 13.7 as an actual argument of an intrinsic procedure." from 
> the 2008 standard implies that the use of a BOZ in the data statement of 
> a character variable is allowed, it doesn't say that it is restricted to 
> numeric types.

You're looking at the wrong part of the Fortran standard,
and yes, I know it can sometimes be hard to find the right
text.

Fortran working document, page. 111.

   If a data-stmt-constant is a boz-literal-constant, the corresponding
   variable shall be of type integer.

You should be able to find some version of this sentence in all version
of the Fortran standard starting with Fortran 95.  As an extension, 
gfortran allows a data-stmt-object to also have a type real.


> > BTW, -fallow-invalid-boz does enable all previous broken
> > usages of BOZ.

Whoops.  That sentences has been munged.  It should have read

  BTW, -fallow-invalid-boz does NOT enable all previous broken
  usages of BOZ.

The missing NOT certainly changed the intent.  Again, historically
a BOZ was converted to an INTEGER(16) right after the BOZ was parsed.
This allowed a BOZ to appear anywhere an INTEGER(16) could appear.
There was an is_boz sentinel in the gfc_expr structure, but it was
only used in a few places.

Consider this piece of code

% cat a.f90
   print *, abs(z'4049abdf')
   end
% gfortran8 -o z a.f90  && ./z
   1078569951

In F2008 and later, a BOZ is a typeless string of bits without a 
kind type parameter.  ABS() is a generic function.  Which specific
should be called?  It cannot be determined from the argument.  Now,
you get

% gfcx -c a.f90
a.f90:1:16:

1 |print *, abs(z'4049abdf')
  |1
Error: 'a' argument of 'abs' intrinsic at (1) must have a numeric type

> In that case comparisons with BOZ should be allowed but they are not as 
> indicated in my previous e-mail 
> https://gcc.gnu.org/ml/fortran/2019-08/msg00031.html

BOZ are not allowed as an operand in an expression.  If you have
code that does

   if (i .eq. z'1234') ...

The correct way to write this is

   if (i .eq. int(z'1234')) ...

I thought about introducing -fbroken-boz option where the
gfortran source code would have had code that looked like

   if (flag_broken_boz)
 {
   old implementation used in gfortran 9 and older
 }
   else
 {
   new implementation
 }

There were two problems with this.  First, it would become a
maintenance nightmare of unmanagable code.  Second, users 
would simply set -fbroken-boz as a default option and never
fix their codes, which then means the dual implementations
would both need to maintained forever.

-- 
Steve

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

[Jason Merrill]

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.



  (Also, all 6 TREE_LANG_FLAGs for a CONSTRUCTOR are used.)


TREE_READONLY seems suitable.

Jason

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

[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 2/3] [og9] Fix configury for AMD GCN testing

[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: 

Re: Use predicates for RTL objects

[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 1/3] [og9] Add missing exec_params libgomp plugin entry points

[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)
 {

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

[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, "");

C++ PATCH for c++/87519 - bogus warning with -Wsign-conversion

[Marek Polacek]

This PR complains about bogus -Wsign-conversion warning even with an
explicit cast, which the documentation says should suppress the warning.
Pretty similar to c++/86190 which I fixed here
.

The problem only happens when using a typedef, because in cp_build_binary_op
we're comparing the types using ==, which I think only works for canonical
types.  So use same_type_p to avoid this problem.

Bootstrapped/regtested on x86_64-linux, ok for trunk?  I think it makes sense
to fix in in 9.3 too.

2019-08-08  Marek Polacek  

PR c++/87519 - bogus warning with -Wsign-conversion.
* typeck.c (cp_build_binary_op): Use same_type_p instead of comparing
the types directly.

* g++.dg/warn/Wsign-conversion-5.C: New test.

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 7e4ea3bee75..4cc0ee0128d 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -5509,9 +5509,9 @@ cp_build_binary_op (const op_location_t ,
   if (! converted)
 {
   warning_sentinel w (warn_sign_conversion, short_compare);
-  if (TREE_TYPE (op0) != result_type)
+  if (!same_type_p (TREE_TYPE (op0), result_type))
op0 = cp_convert_and_check (result_type, op0, complain);
-  if (TREE_TYPE (op1) != result_type)
+  if (!same_type_p (TREE_TYPE (op1), result_type))
op1 = cp_convert_and_check (result_type, op1, complain);
 
   if (op0 == error_mark_node || op1 == error_mark_node)
diff --git gcc/testsuite/g++.dg/warn/Wsign-conversion-5.C 
gcc/testsuite/g++.dg/warn/Wsign-conversion-5.C
new file mode 100644
index 000..ff384164901
--- /dev/null
+++ gcc/testsuite/g++.dg/warn/Wsign-conversion-5.C
@@ -0,0 +1,18 @@
+// PR c++/87519 - bogus warning with -Wsign-conversion.
+// { dg-options "-Wsign-conversion" }
+
+typedef unsigned long int uint64_t;
+
+void f(unsigned long int a, int q)
+{
+  a += a + q; // { dg-warning "may change the sign" }
+
+  // Explicit cast should disable the warning.
+  a = a + static_cast(q);
+  a = a + (uint64_t) q;
+  a = a + uint64_t(q);
+  a = a + static_cast(q);
+  a = a + (const uint64_t) q;
+  a = a + static_cast(q);
+  a = a + static_cast(q);
+}

Re: Use predicates for RTL objects

[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

Re: C++ PATCH for c++/91346 - Implement C++2a P1668R1, allow unevaluated asm in constexpr

[Jason Merrill]

On 8/7/19 4:44 PM, Marek Polacek wrote:

On Wed, Aug 07, 2019 at 10:37:04PM +0200, Jakub Jelinek wrote:

On Wed, Aug 07, 2019 at 04:30:29PM -0400, Marek Polacek wrote:

+/* Complain about an attempt to evaluate inline assembly.  */
+
+static void
+inline_asm_in_constexpr_error (location_t loc)
+{
+  error_at (loc, "inline assembly is not a constant expression");
+  inform (loc, "only unevaluated inline assembly is allowed in a "
+ "% function in C++2a");


Note, I think in this case you do want a
   auto_diagnostic_group d;
before the two diagnostic calls, whether you apply this patch or not,
because they are a diagnostic group together.  See PR84889.


It's not like we talked about it just a while ago...  /facepalm

Will fix.


OK with that change.

Jason

Re: [C++ Patch] Improve start_function and grokmethod locations

[Jason Merrill]

On 8/6/19 8:28 AM, Paolo Carlini wrote:
apparently this is now easy to do, likely because a while ago I made 
sure that we consistently have meaningful locations for TYPE_DECLs too.


(I went through grokdeclarator and confirmed that when the third 
argument is FUNCDEF or MEMFUNCDEF it cannot return NULL_TREE)



-typedef void foo () {} // { dg-error "invalid function declaration" }
+typedef void foo () {} // { dg-error "14:invalid function declaration" }
 struct S
 {
-  typedef int bar (void) { return 0; } // { dg-error "invalid member function 
declaration" }
+  typedef int bar (void) { return 0; }  // { dg-error "15:invalid member function 
declaration" }


Maybe we could give a more specific diagnostic in grokdeclarator; 
perhaps under



  if (typedef_p && decl_context != TYPENAME)


complain and return error_mark_node in FUNCDEF or MEMFUNCDEF context.

Jason

Re: [PATCH][GCC][AARCH64] Add effective-target check to b key execution tests

[Jeff Law]

On 8/7/19 9:57 AM, Sam Tebbs wrote:
> Hi all,
> 
> This patch adds an effective target check to the pointer authentication B key 
> execution tests. These were failing with an assembler error when run with a 
> non-recent version of binutils, and this change will instead make them 
> unsupported in such cases.
> 
> Tested with a recent version of binutils where it passes, and with a 
> non-recent version where it is unsupported.
> 
> OK for trunk?
> 
> Sam
> 
> gcc/testsuite
> 2019-08-02  Sam Tebbs
> 
>   * lib/target-supports.exp
>   (check_effective_target_arm_v8_4a_bkey_directive): New proc.
>   * g++.target/aarch64/return_address_sign_b_exception.C,
>   return_address_sign_ab_exception.C: Add dg-require-effective-target
>   checks.
> 
OK
jeff

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

[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] Sync MIPS support from libffi master repository

[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: [PATCH] Add --with-static-standard-libraries to the top level

[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

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

[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

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

[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

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

[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")
+ 

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

[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 

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

[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] i386: Roundeven expansion for SSE4.1+

[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] Sync MIPS support from libffi master repository

[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

[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] Provide proper error message for -flto=abcd.

[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 v2] Use edge->indirect_unknown_callee in cgraph_edge::make_direct (PR ipa/89330).

[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

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

[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, ira] Invalid assert in reload1.c::finish_spills?

[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] Sync MIPS support from libffi master repository

[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

Re: [PATCH 7/9] IPA ICF: remove dead code

[Jeff Law]

On 7/24/19 6:24 AM, Martin Liska wrote:
> 
> gcc/ChangeLog:
> 
> 2019-07-24  Martin Liska  
> 
>   * ipa-icf-gimple.c (func_checker::compare_ssa_name): Call
>   compare_operand.
>   (func_checker::compare_memory_operand): Remove.
>   (func_checker::compare_cst_or_decl): Remove.
>   (func_checker::operand_equal_valueize): Do not handle
>   FIELD_DECL.
>   (func_checker::compare_gimple_call): Call compare_operand.
>   (func_checker::compare_gimple_assign): Likewise.
>   * ipa-icf-gimple.h: Remove compare_cst_or_decl.
>   * ipa-icf.c (sem_function::icf_handled_component_p): Remove.
>   * ipa-icf.h (icf_handled_component_p): Remove.
> ---
>  gcc/ipa-icf-gimple.c | 150 ++-
>  gcc/ipa-icf-gimple.h |   4 --
>  gcc/ipa-icf.c|  11 
>  gcc/ipa-icf.h|   3 -
>  4 files changed, 6 insertions(+), 162 deletions(-)
> 

OK for the trunk once any prereqs are approved.
Jeff

Re: [PATCH 9/9] Remove alias set comparison.

[Jeff Law]

On 6/11/19 1:36 AM, Martin Liska wrote:
> 
> gcc/ChangeLog:
> 
> 2019-07-24  Martin Liska  
> 
>   * ipa-icf-gimple.c (func_checker::compatible_types_p):
>   Do not compare alias sets.  It's handled by operand_equal_p.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-07-24  Martin Liska  
> 
>   * c-c++-common/Wstringop-truncation-4.c: Disable IPA ICF.
>   * gcc.dg/tree-ssa/pr64910-2.c: Likewise.
>   * gcc.dg/tree-ssa/pr79352.c: Likewise.
>   * gcc.dg/ipa/ipa-icf-40.c: New test.
OK for the trunk once any prereqs are approved.

jeff

Re: [PATCH 9/9] Remove alias set comparison.

[Martin Sebor]

On 8/8/19 2:14 AM, Martin Liška wrote:

On 8/7/19 5:20 PM, Martin Sebor wrote:

On 6/11/19 1:36 AM, Martin Liska wrote:


gcc/ChangeLog:

2019-07-24  Martin Liska  

 * ipa-icf-gimple.c (func_checker::compatible_types_p):
 Do not compare alias sets.  It's handled by operand_equal_p.

gcc/testsuite/ChangeLog:

2019-07-24  Martin Liska  

 * c-c++-common/Wstringop-truncation-4.c: Disable IPA ICF.


What fails without the change?


ICF will newly merge these functions:


I see.  I suppose the other alternatives are to either add
attribute noipa to the functions or make unique the string
each function copies so they can't be merged.

I have a mild preference for the last alternative but it's
your call.  If you decide to keep the option can you please
add a brief comment explaining why it's needed?

Thanks
Martin



grep hit: Wstringop-truncation-4.c.070i.icf
Semantic equality hit:void test_arrays(Arrays*, const char*)->void 
test_const_arrays(ConstArrays*, const char*)
Semantic equality hit:void test_arrays(Arrays*, const char*)->void 
test_volatile_arrays(VolatileArrays*, const char*)
Semantic equality hit:void test_arrays(Arrays*, const char*)->void 
test_const_volatile_arrays(ConstVolatileArrays*, const char*)

So we'll get less warnings than expected.

Martin



Thanks
Martin


 * gcc.dg/tree-ssa/pr64910-2.c: Likewise.
 * gcc.dg/tree-ssa/pr79352.c: Likewise.
 * gcc.dg/ipa/ipa-icf-40.c: New test.
---
   gcc/ipa-icf-gimple.c  | 12 ---
   .../c-c++-common/Wstringop-truncation-4.c |  2 +-
   gcc/testsuite/gcc.dg/ipa/ipa-icf-40.c | 32 +++
   gcc/testsuite/gcc.dg/tree-ssa/pr64910-2.c |  2 +-
   gcc/testsuite/gcc.dg/tree-ssa/pr79352.c   |  2 +-
   5 files changed, 35 insertions(+), 15 deletions(-)
   create mode 100644 gcc/testsuite/gcc.dg/ipa/ipa-icf-40.c

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

[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: Use predicates for RTL objects

[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: [PATCH] fix and improve strlen conditional handling of merged stores (PR 91183, 91294, 91315)

[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 

[PATCH] rs6000: Add ordered compares (PR58684)

[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 = 

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

[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: Start implementing -frounding-math

[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

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

[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

[Joseph Myers]

On Thu, 8 Aug 2019, Marc Glisse wrote:

> > FENV_ROUND (and FENV_DEC_ROUND) shouldn't be that hard, given the
> 
> On the glibc side I expect it to be a lot of work, it seems to require a
> correctly rounded version of all math functions...

No, it doesn't.  18661-4 reserves cr* names for correctly rounded 
functions; most of the non-cr* names are not bound to the IEEE operations 
and so have no specific accuracy requirements, with FENV_ROUND they just 
need to behave the same as if the relevant dynamic rounding mode were set 
(via the compiler temporarily setting it before calling the function).

> It seems that hex floats are accepted even in C89 with a pedwarn that can be

Not for -std=c90 (since accepting p+ or p- as part of a pp-number would 
change the semantics of some valid C90 programs, see 
gcc.dg/c90-hexfloat-2.c), only -std=gnu* and C99 and later standards.

> We could also have #pragma fenv_round to_nearest (not the exact syntax) in
> float.h, although the C standard doesn't seem to have a push/pop mechanism to
> restore fenv_round at the end of the file.

Also, what's relevant is the state when the macro is expanded, not when 
it's defined.

(The math.h M_* constants aren't a big issue; at most maybe they need a 
few more digits so the constant rounds the same as the underlying 
irrational number in all rounding modes.  The float.h constants are an 
issue precisely because the values are dyadic rationals but need many 
decimal digits to represent them exactly in decimal.)

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

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

[Martin Liška]

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.
---
 gcc/ipa-icf.c  | 208 +++--
 gcc/testsuite/g++.dg/ipa/ipa-icf-2.C   |   2 +-
 gcc/testsuite/g++.dg/ipa/ipa-icf-3.C   |   2 +-
 gcc/testsuite/g++.dg/ipa/ipa-icf-4.C   |   2 +-
 gcc/testsuite/g++.dg/ipa/ipa-icf-6.C   |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-1.c   |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-10.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-11.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-12.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-13.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-16.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-18.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-2.c   |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-20.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-21.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-23.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-25.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-26.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-27.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-3.c   |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-35.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-36.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-37.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c  |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-5.c   |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-7.c   |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-8.c   |   2 +-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-merge-1.c |   2 +-
 gcc/testsuite/gcc.dg/ipa/pr64307.c |   2 +-
 gcc/testsuite/gcc.dg/ipa/pr90555.c |   2 +-
 31 files changed, 144 insertions(+), 124 deletions(-)


diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index 13e63b77af1..c9c3cb4a331 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -1024,20 +1024,23 @@ sem_function::merge (sem_item *alias_item)
   bool original_address_matters = original->address_matters_p ();
   bool alias_address_matters = alias->address_matters_p ();
 
+  AUTO_DUMP_SCOPE ("merge",
+		   dump_user_location_t::from_function_decl (decl));
+
   if (DECL_EXTERNAL (alias->decl))
 {
-  if (dump_file)
-	fprintf (dump_file, "Not unifying; alias is external.\n\n");
+  if (dump_enabled_p ())
+	dump_printf (MSG_MISSED_OPTIMIZATION,
+		 "Not unifying; alias is external.\n");
   return false;
 }
 
   if (DECL_NO_INLINE_WARNING_P (original->decl)
   != DECL_NO_INLINE_WARNING_P (alias->decl))
 {
-  if (dump_file)
-	fprintf (dump_file,
-		 "Not unifying; "
-		 "DECL_NO_INLINE_WARNING mismatch.\n\n");
+  if (dump_enabled_p ())
+	dump_printf (MSG_MISSED_OPTIMIZATION,
+		 "Not unifying; DECL_NO_INLINE_WARNING mismatch.\n");
   return false;
 }
 
@@ -1047,21 +1050,20 @@ sem_function::merge (sem_item *alias_item)
|| (DECL_SECTION_NAME (alias->decl) && !alias->implicit_section))
   && DECL_SECTION_NAME (original->decl) != DECL_SECTION_NAME (alias->decl))
 {
-  if (dump_file)
-	fprintf (dump_file,
-		 "Not unifying; "
-		 

[MSP430][PATCH 2/2] Read MCU data from external file

[Jozef Lawrynowicz]

This patch extends the MCU data handling so that MCU data can be provided
in an external file (devices.csv). This means the compiler doesn't have to be
updated and rebuilt to support new devices when they are released.

TI distribute devices.csv with other support files (header files, linker
scripts) on their website. I have also tested that a program builds successfully
for every MCU and the correct hwmult library is passed to the linker.
I also built the msp430 cross compiler using a trunk build of native GCC to
ensure all the error and warning messages added by my code are correct, as
checked by -Wformat-diag.
From 6f67cdd282f2351d7450e343314beeaa745f0159 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Tue, 6 Aug 2019 10:52:54 +0100
Subject: [PATCH 2/2] MSP430: Devices [2]: Read MCU data from external
 devices.csv file, if it exists

gcc/ChangeLog:

2019-08-XX  Jozef Lawrynowicz  

	* gcc/config/msp430/driver-msp430.c (msp430_set_driver_var): New.
	* gcc/config/msp430/msp430-devices.c (canonicalize_path_dirsep): New.
	(msp430_check_path_for_devices): New.
	(parse_devices_csv_1): New.
	(parse_devices_csv): New.
	(msp430_extract_mcu_data): Try to find devices.csv and search for the
	MCU data in devices.csv before using the hard-coded data.
	Warn if devices.csv isn't found and the MCU wasn't found in the
	hard-coded data either.
	* gcc/config/msp430/msp430.h (DRIVER_SELF_SPECS): Call
	msp430_set_driver_var for -mno-warn-devices-csv and -mdevices-csv-loc.
	Search for devices.csv on -I and -L paths.
	(EXTRA_SPEC_FUNCTIONS): Add msp430_check_path_for_devices and
	msp430_set_driver_var.
	* gcc/config/msp430/msp430.opt: Add -mwarn-devices-csv and
	-mdevices-csv-loc=.
	* gcc/doc/invoke.texi (-mmcu): Document that -I and -L paths are
	searched for devices.csv.
	(mwarn-devices-csv): Document option.

gcc/testsuite/ChangeLog:

2019-08-XX  Jozef Lawrynowicz  

	* gcc.target/msp430/msp430.exp (msp430_device_permutations_runtest):
	Handle csv-* and bad-devices-* tests.
	* gcc.target/msp430/devices/README: Document how bad-devices-* tests
	work.
	* gcc.target/msp430/devices/bad-devices-1.c: New test.
	* gcc.target/msp430/devices/bad-devices-2.c: Likewise.
	* gcc.target/msp430/devices/bad-devices-3.c: Likewise.
	* gcc.target/msp430/devices/bad-devices-4.c: Likewise.
	* gcc.target/msp430/devices/bad-devices-5.c: Likewise.
	* gcc.target/msp430/devices/bad-devices-6.c: Likewise.
	* gcc.target/msp430/devices/csv-device-order.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_00.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_01.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_02.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_04.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_08.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_10.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_11.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_12.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_14.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_18.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_20.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_21.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_22.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_24.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430_28.c: Likewise.
	* gcc.target/msp430/devices/csv-msp430fr5969.c: Likewise.
	* gcc.target/msp430/devices/hard-foo.c: Likewise.
	* gcc.target/msp430/devices/bad-devices-1.csv: New test support file.
	* gcc.target/msp430/devices/bad-devices-2.csv: Likewise.
	* gcc.target/msp430/devices/bad-devices-3.csv: Likewise.
	* gcc.target/msp430/devices/bad-devices-4.csv: Likewise.
	* gcc.target/msp430/devices/bad-devices-5.csv: Likewise.
	* gcc.target/msp430/devices/bad-devices-6.csv: Likewise.
	* gcc.target/msp430/devices/devices.csv: Likewise.
---
 gcc/config/msp430/driver-msp430.c |  23 ++
 gcc/config/msp430/msp430-devices.c| 276 +-
 gcc/config/msp430/msp430.h|  10 +-
 gcc/config/msp430/msp430.opt  |   9 +
 gcc/doc/invoke.texi   |  14 +-
 .../gcc.target/msp430/devices/README  |   5 +
 .../gcc.target/msp430/devices/bad-devices-1.c |   5 +
 .../msp430/devices/bad-devices-1.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-2.c |   5 +
 .../msp430/devices/bad-devices-2.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-3.c |   5 +
 .../msp430/devices/bad-devices-3.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-4.c |   5 +
 .../msp430/devices/bad-devices-4.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-5.c |   5 +
 .../msp430/devices/bad-devices-5.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-6.c |   5 +
 .../msp430/devices/bad-devices-6.csv  |   3 +
 .../msp430/devices/csv-device-order.c |  11 +
 .../gcc.target/msp430/devices/csv-msp430_00.c |   7 +
 

[MSP430][PATCH 1/2] Consolidate handling of hard-coded MCU data

[Jozef Lawrynowicz]

This patch improves the handling of MCU data by consolidating multiple
copies of hard-coded MCU data into a single location, and adds a new function
to be used as a single entry point for the extraction of MCU data for the
selected MCU.

This ensures the data is only extracted once per invocation of the
driver/compiler, whilst previously, the data for the MCU is extracted each time
it is needed.

Some notes:
- The GNU assembler doesn't do anything with the -mmcu option beyond setting up
  the CPU ISA, so if the GCC driver passes it the -mcpu option, which it will
  always do if -mmcu is specified, then it is redundant to also pass it -mmcu.
- The indenting in some places (e.g. msp430_select_hwmult_lib) looks wrong in
  the patched file, but to make the diff a lot easier to read I have kept the
  indenting the same as it was before. I can fix this after the patch is
  accepted.
From cd131b07e0447d104c99317e7ac37c2420c1bf6e Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Wed, 31 Jul 2019 22:53:50 +0100
Subject: [PATCH 1/2] MSP430: Devices [1]: Consolidate handling of hard-coded
 MCU data

gcc/ChangeLog:

2019-08-XX  Jozef Lawrynowicz  

	* gcc/config.gcc (msp430*-*-*): Add msp430-devices.o to extra_objs and
	extra_gcc_objs.
	* gcc/config/msp430/driver-msp430.c: Remove msp430_mcu_data.
	(msp430_select_cpu): New spec function.
	(msp430_select_hwmult_lib): Use msp430_extract_mcu_data to extract
	MCU data.
	* gcc/config/msp430/msp430-devices.c: New file.
	* gcc/config/msp430/msp430-devices.h: New file.
	* gcc/config/msp430/msp430.c: Remove msp430_mcu_data.
	(msp430_option_override): Use msp430_extract_mcu_data to extract
	MCU data.
	(msp430_use_f5_series_hwmult): Likewise.
	(use_32bit_hwmult): Likewise.
	(msp430_no_hwmult): Likewise.
	* gcc/config/msp430/msp430.h (ASM_SPEC): Don't pass -mmcu to the
	assembler.
	(DRIVER_SELF_SPECS): Call msp430_select_cpu if -mmcu is used without
	and -mcpu option.
	(EXTRA_SPEC_FUNCTIONS): Add msp430_select_cpu.
	* gcc/config/msp430/t-msp430: Add rule to build msp430-devices.o.
	Remove hard-coded MCU multilib data.

gcc/testsuite/ChangeLog:

2019-08-XX  Jozef Lawrynowicz  

	* gcc.target/msp430/msp430.exp
	(check_effective_target_msp430_430_selected): New.
	(check_effective_target_msp430_430x_selected): New.
	(check_effective_target_msp430_mlarge_selected): New.
	(check_effective_target_msp430_hwmul_not_none): New.
	(check_effective_target_msp430_hwmul_not_16bit): New.
	(check_effective_target_msp430_hwmul_not_32bit): New.
	(check_effective_target_msp430_hwmul_not_f5): New.
	(msp430_get_opts): New.
	(msp430_device_permutations_runtest): New.
	* gcc.target/msp430/devices/README: New file.
	* gcc.target/msp430/devices-main.c: New test.
	* gcc.target/msp430/devices/hard-cc430f5123.c: Likewise.
	* gcc.target/msp430/devices/hard-foo.c: Likewise.
	* gcc.target/msp430/devices/hard-msp430afe253.c: Likewise.
	* gcc.target/msp430/devices/hard-msp430cg4616.c: Likewise.
	* gcc.target/msp430/devices/hard-msp430f4783.c: Likewise.
	* gcc.target/msp430/devices/hard-rf430frl154h_rom.c: Likewise.
---
 gcc/config.gcc|   3 +-
 gcc/config/msp430/driver-msp430.c | 654 +---
 gcc/config/msp430/msp430-devices.c| 697 ++
 gcc/config/msp430/msp430-devices.h|  31 +
 gcc/config/msp430/msp430.c| 680 +
 gcc/config/msp430/msp430.h|  10 +-
 gcc/config/msp430/t-msp430| 236 +-
 .../gcc.target/msp430/devices-main.c  |   6 +
 .../gcc.target/msp430/devices/README  |  12 +
 .../msp430/devices/hard-cc430f5123.c  |   7 +
 .../gcc.target/msp430/devices/hard-foo.c  |   5 +
 .../msp430/devices/hard-msp430afe253.c|   8 +
 .../msp430/devices/hard-msp430cg4616.c|   7 +
 .../msp430/devices/hard-msp430f4783.c |   8 +
 .../msp430/devices/hard-rf430frl154h_rom.c|   8 +
 gcc/testsuite/gcc.target/msp430/msp430.exp|  82 ++-
 16 files changed, 943 insertions(+), 1511 deletions(-)
 create mode 100644 gcc/config/msp430/msp430-devices.c
 create mode 100644 gcc/config/msp430/msp430-devices.h
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices-main.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/README
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/hard-cc430f5123.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/hard-foo.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/hard-msp430afe253.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/hard-msp430cg4616.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/hard-msp430f4783.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/hard-rf430frl154h_rom.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 291e2881f96..40cbc52dc99 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2519,7 +2519,8 @@ msp430*-*-*)
 	c_target_objs="msp430-c.o"
 	

Re: [PATCH] Port value profiling to -fopt-info infrastructure.

[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  
> 
>   * value-prof.c (gimple_divmod_fixed_value_transform):
>   Use dump_printf_loc.
>   (gimple_mod_pow2_value_transform): Likewise.
>   (gimple_mod_subtract_transform): Likewise.
>   (init_node_map): Likewise.
>   (gimple_ic_transform): Likewise.
>   (gimple_stringops_transform): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-08-08  Martin Liska  
> 
>   * g++.dg/tree-prof/indir-call-prof.C: Add -optimize
>   to -fdump-ipa-profile.
>   * g++.dg/tree-prof/morefunc.C: Likewise.
>   * g++.dg/tree-prof/reorder.C: Likewise.
>   * gcc.dg/tree-prof/ic-misattribution-1.c: Likewise.
>   * gcc.dg/tree-prof/indir-call-prof.c: Likewise.
>   * gcc.dg/tree-prof/stringop-1.c: Likewise.
>   * gcc.dg/tree-prof/stringop-2.c: Likewise.
>   * gcc.dg/tree-prof/val-prof-1.c: Likewise.
>   * gcc.dg/tree-prof/val-prof-2.c: Likewise.
>   * gcc.dg/tree-prof/val-prof-3.c: Likewise.
>   * gcc.dg/tree-prof/val-prof-4.c: Likewise.
>   * gcc.dg/tree-prof/val-prof-5.c: Likewise.
>   * gcc.dg/tree-prof/val-prof-7.c: Likewise.
> ---
>  .../g++.dg/tree-prof/indir-call-prof.C|   2 +-
> diff --git a/gcc/value-prof.c b/gcc/value-prof.c
> index 759458868a8..9d9785b179d 100644
> --- a/gcc/value-prof.c
> +++ b/gcc/value-prof.c
> @@ -809,12 +809,9 @@ gimple_divmod_fixed_value_transform 
> (gimple_stmt_iterator *si)
> @@ -1445,41 +1447,36 @@ gimple_ic_transform (gimple_stmt_iterator *gsi)
[ ... ]
> -  if (dump_file)
> +  if (dump_enabled_p ())
>  {
> -  fprintf (dump_file, "Indirect call -> direct call ");
> -  print_generic_expr (dump_file, gimple_call_fn (stmt), TDF_SLIM);
> -  fprintf (dump_file, "=> ");
> -  print_generic_expr (dump_file, direct_call->decl, TDF_SLIM);
> -  fprintf (dump_file, " transformation on insn postponned to 
> ipa-profile");
> -  print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
> -  fprintf (dump_file, "hist->count %" PRId64
> -" hist->all %" PRId64"\n", count, all);
> +  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, stmt,
> +"Indirect call -> direct call "
> +"%T => %T transformation on insn postponed "
> +"to ipa-profile: %G", gimple_call_fn (stmt),
> +direct_call->decl, stmt);
> +  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, stmt,
> +"hist->count %" PRId64
> +" hist->all %" PRId64"\n", count, all);
>  }
It's not entirely clear if you want MSG_OPTIMIZED_LOCATION vs
MSG_MISSED_OPTIMIZATION here.  Double check and adjust if needed.

OK with or without that adjustment.

Jeff

Re: [PATCH 4/9] Strengthen alias_ptr_types_compatible_p in LTO mode.

[Martin Liška]

On 8/7/19 1:57 PM, Richard Biener wrote:
> On Tue, Aug 6, 2019 at 5:43 PM Martin Liska  wrote:
> 
> This warrants a comment like
> 
>   /* This function originally abstracts from simply comparing
> get_deref_alias_set
>  so that we are sure this still computes the same result after LTO
> type merging
>  is applied.  When in LTO type merging is done we can actually do
> this compare.  */
>   if (in_lto_p)
> return get_deref_alias_set (t1) == get_deref_alias_set (t2);
> ...
> 
> also note you want to call get_deref_alias_set as mentioned in the
> function comment.

Thanks for review.

Hope it's addressed in the attached patch that I've just tested?

Martin

> 
> OK with this change.
> 
> Thanks,
> Richard.
> 
>> gcc/ChangeLog:
>>
>> 2019-07-24  Martin Liska  
>>
>> * alias.c (alias_ptr_types_compatible_p): Strengten
>> type comparison in LTO mode.
>> ---
>>  gcc/alias.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>

>From bedcf4da9f352674390304bed1e71b79c5c28cc5 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 4 Jun 2019 13:30:32 +0200
Subject: [PATCH] Strengthen alias_ptr_types_compatible_p in LTO mode.

gcc/ChangeLog:

2019-07-24  Martin Liska  

	* alias.c (alias_ptr_types_compatible_p): Strengten
	type comparison in LTO mode.
---
 gcc/alias.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/alias.c b/gcc/alias.c
index 2755df72907..1579dfa68a7 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -793,8 +793,16 @@ alias_ptr_types_compatible_p (tree t1, tree t2)
   || ref_all_alias_ptr_type_p (t2))
 return false;
 
-  return (TYPE_MAIN_VARIANT (TREE_TYPE (t1))
-	  == TYPE_MAIN_VARIANT (TREE_TYPE (t2)));
+/* This function originally abstracts from simply comparing
+   get_deref_alias_set so that we are sure this still computes
+   the same result after LTO type merging is applied.
+   When in LTO type merging is done we can actually do this compare.
+*/
+  if (in_lto_p)
+return get_deref_alias_set (t1) == get_deref_alias_set (t2);
+  else
+return (TYPE_MAIN_VARIANT (TREE_TYPE (t1))
+	== TYPE_MAIN_VARIANT (TREE_TYPE (t2)));
 }
 
 /* Create emptry alias set entry.  */
-- 
2.22.0

[PATCH] P0325R4 to_array from LFTS with updates

[Jonathan Wakely]

As an extension to what the standard requires, this also adds
conditional noexcept-specifiers to the std::to_array functions.

P0325R4 to_array from LFTS with updates
* include/experimental/array (to_array): Qualify call to __to_array.
* include/std/array (__cpp_lib_to_array, to_array): Define for C++20.
* include/std/version (__cpp_lib_to_array): Likewise.
* testsuite/23_containers/array/creation/1.cc: New test.
* testsuite/23_containers/array/creation/2.cc: New test.
* testsuite/23_containers/array/creation/3_neg.cc: New test.
* testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc:
Use zero for dg-error line number.

Another new C++20 feature. Tested x86_64-linux, committed to trunk.


commit e7545060fab47734c461ea6d0f85c12be14fbf9a
Author: Jonathan Wakely 
Date:   Wed Aug 7 21:02:56 2019 +0100

P0325R4 to_array from LFTS with updates

As an extension to what the standard requires, this also adds
conditional noexcept-specifiers to the std::to_array functions.

P0325R4 to_array from LFTS with updates
* include/experimental/array (to_array): Qualify call to __to_array.
* include/std/array (__cpp_lib_to_array, to_array): Define for 
C++20.
* include/std/version (__cpp_lib_to_array): Likewise.
* testsuite/23_containers/array/creation/1.cc: New test.
* testsuite/23_containers/array/creation/2.cc: New test.
* testsuite/23_containers/array/creation/3_neg.cc: New test.
* 
testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc:
Use zero for dg-error line number.

diff --git a/libstdc++-v3/include/experimental/array 
b/libstdc++-v3/include/experimental/array
index 5a35fd499d8..0064a0b3b3d 100644
--- a/libstdc++-v3/include/experimental/array
+++ b/libstdc++-v3/include/experimental/array
@@ -101,7 +101,7 @@ template 
   to_array(_Tp (&__a)[_Nm])
   noexcept(is_nothrow_constructible, _Tp&>::value)
   {
-return __to_array(__a, make_index_sequence<_Nm>{});
+return experimental::__to_array(__a, make_index_sequence<_Nm>{});
   }
 
   // @} group make_array
diff --git a/libstdc++-v3/include/std/array b/libstdc++-v3/include/std/array
index 31eff9e8e1d..a380f523d44 100644
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -88,7 +88,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*  Sets support random access iterators.
*
*  @tparam  Tp  Type of element. Required to be a complete type.
-   *  @tparam  N  Number of elements.
+   *  @tparam  Nm  Number of elements.
   */
   template
 struct array
@@ -343,6 +343,44 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   return std::move(_GLIBCXX_STD_C::get<_Int>(__arr));
 }
 
+#if __cplusplus > 201703L
+#define __cpp_lib_to_array 201907L
+
+  template
+constexpr array, sizeof...(_Idx)>
+__to_array(_Tp (&__a)[sizeof...(_Idx)], index_sequence<_Idx...>)
+{
+  if constexpr (_Move)
+   return {{std::move(__a[_Idx])...}};
+  else
+   return {{__a[_Idx]...}};
+}
+
+  template
+constexpr array, _Nm>
+to_array(_Tp (&__a)[_Nm])
+noexcept(is_nothrow_constructible_v<_Tp, _Tp&>)
+{
+  static_assert(!is_array_v<_Tp>);
+  static_assert(is_constructible_v<_Tp, _Tp&>);
+  if constexpr (is_constructible_v<_Tp, _Tp&>)
+   return _GLIBCXX_STD_C::__to_array(__a, make_index_sequence<_Nm>{});
+  __builtin_unreachable(); // FIXME: see PR c++/91388
+}
+
+  template
+constexpr array, _Nm>
+to_array(_Tp (&&__a)[_Nm])
+noexcept(is_nothrow_move_constructible_v<_Tp>)
+{
+  static_assert(!is_array_v<_Tp>);
+  static_assert(is_move_constructible_v<_Tp>);
+  if constexpr (is_move_constructible_v<_Tp>)
+   return _GLIBCXX_STD_C::__to_array<1>(__a, make_index_sequence<_Nm>{});
+  __builtin_unreachable(); // FIXME: see PR c++/91388
+}
+#endif // C++20
+
 _GLIBCXX_END_NAMESPACE_CONTAINER
 } // namespace std
 
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 9548725d1b7..5757568d639 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -153,6 +153,7 @@
 #define __cpp_lib_atomic_ref 201806L
 #define __cpp_lib_bind_front 201907L
 #define __cpp_lib_bounded_array_traits 201902L
+#define __cpp_lib_constexpr_algorithms 201711L
 #if __cpp_impl_destroying_delete
 # define __cpp_lib_destroying_delete 201806L
 #endif
@@ -164,7 +165,7 @@
 #endif
 #define __cpp_lib_list_remove_return_type 201806L
 #define __cpp_lib_math_constants 201907L
-#define __cpp_lib_constexpr_algorithms 201711L
+#define __cpp_lib_to_array 201907L
 #endif // C++2a
 #endif // C++17
 #endif // C++14
diff --git a/libstdc++-v3/testsuite/23_containers/array/creation/1.cc 
b/libstdc++-v3/testsuite/23_containers/array/creation/1.cc
new file mode 100644
index 000..6279d736353
--- /dev/null
+++ 

Re: Start implementing -frounding-math

[Marc Glisse]

On Thu, 8 Aug 2019, Joseph Myers wrote:


On Thu, 8 Aug 2019, Marc Glisse wrote:


FENV_ROUND (and FENV_DEC_ROUND) shouldn't be that hard, given the


On the glibc side I expect it to be a lot of work, it seems to require a
correctly rounded version of all math functions...


No, it doesn't.  18661-4 reserves cr* names for correctly rounded
functions; most of the non-cr* names are not bound to the IEEE operations
and so have no specific accuracy requirements, with FENV_ROUND they just
need to behave the same as if the relevant dynamic rounding mode were set
(via the compiler temporarily setting it before calling the function).


And since glibc just ignores the rounding mode, that's no constraint at 
all, at least on that platform. ok.


--
Marc Glisse

[PATCH] [MIPS] Fix handling of MSA SUBREG moves on big-endian targets

[Mihailo Stojanovic]

From: Mihailo Stojanovic 

Hi everybody,

This fixes the MSA implementation on big-endian targets which is
essentially broken for things like SUBREG handling and calling
convention for vector types. It borrows heavily from [1] as Aarch64 has
the same problem with SVE vectors.

Conceptually, register bitconverts should act as the data has been
stored to memory in one mode, and loaded from memory in the other.
This isn't what happens on big-endian as vector load/store instructions
are essentially mixed-endian with respect to the vector as a whole.
The in-register representation of data must be changed so that the
load/store round-trip becomes valid. This is done by inserting one or
two shuffle instructions for every SUBREG move, as previously
implemented in [2] for LLVM. Even if the shuffle instructions weren't
generated, constraint in mips_can_change_mode_class would force the
conceptual memory reload of SUBREG move operand, which would generate
correct, albeit very inefficient code.

New msa_reg_predicate was created in order to forbid SUBREG operands in
MSA patterns on big-endian targets. It weeds SUBREGs out of the
instruction patterns into SUBREG->REG moves which are caught by the new
msa_mov_subreg_be pattern and transformed into shuffle(s).

As for the MSA calling convention, ABI states that compiling for MSA
should not change the base ABIs vector calling convention, that is, MSA
vectors passed or returned by value do not use the MSA vector registers.
Instead, they are passed by general-purpose registers, as described by
the ABI. Passing the vector argument requires splitting it into 2 (or 4)
general-purpose registers and bitconverting it into V2DImode (or
V4SImode). The solution boils down to the one presented for SUBREG
moves: force every vector argument to the appropriate mode (V2DI or
V4SI) so that the shuffle instruction(s) might be generated in order to
conform to the calling convention. The same applies to vectors as return
values.

New testcases were added (thanks Dragan!) to check calling convention
compliance for all possible combinations of MSA and non-MSA
interlinking.

This fixes the following vectorization test failures:

vect/pr66251.c
vect/vect-alias-check-10.c
vect/vect-alias-check-11.c
vect/vect-alias-check-12.c
vect/vect-bswap32.c
vect/vect-bswap64.c
vect/vect-nop-move.c
vect/slp-41.c
vect/slp-43.c
vect/slp-45.c
vect/slp-perm-11.c

Tested on mips32-mti-linux-gnu and mips64-mti-linux-gnu.

Regards,
Mihailo

[1] https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02176.html
[2] https://reviews.llvm.org/rL189330

gcc/ChangeLog:

2019-08-08  Mihailo Stojanovic  

* config/mips/mips-msa.md: Replace register_operand predicate with
msa_reg_operand in every pattern.
(msa_change_mode): New pattern.
(*msa_change_mode_): New unspec.
(*msa_mov_subreg_be): New unspec.
* config/mips/mips-protos.h (mips_split_msa_subreg_move): Declare.
* config/mips/mips.c (mips_maybe_expand_msa_subreg_move): New
function.
(mips_replace_reg_mode): Ditto.
(mips_split_msa_subreg_move): Ditto.
(mips_legitimize_move): Modify machine modes of MSA vectors which
reside in general-purpose registers. Check whether SUBREG move can
be replaced with shuffle(s).
(mips_split_128bit_move): Replace new SUBREGs with REGs.
(mips_split_msa_copy_d): Ditto.
(mips_split_msa_insert_d): Ditto.
(mips_split_msa_fill_d): Ditto.
(mips_can_change_mode_class): Disallow mode change which would
result in lane width change.
(mips_expand_vec_unpack): Replace new SUBREG with REG on big-endian
targets.
* config/mips/predicates.md (msa_reg_operand): New predicate.

gcc/testsuite/ChangeLog:

2019-08-08  Dragan Mladjenovic  

* gcc.target/mips/inter/msa-inter.exp: New file.
* gcc.target/mips/inter/msa_1.h: New test.
* gcc.target/mips/inter/msa_1_main.c: New test.
* gcc.target/mips/inter/msa_1_x.c: New test.
* gcc.target/mips/inter/msa_1_y.c: New test.
---
 gcc/config/mips/mips-msa.md   | 1026 +++--
 gcc/config/mips/mips-protos.h |2 +
 gcc/config/mips/mips.c|  166 +++-
 gcc/config/mips/predicates.md |5 +
 gcc/testsuite/gcc.target/mips/inter/msa-inter.exp |   67 ++
 gcc/testsuite/gcc.target/mips/inter/msa_1.h   |   23 +
 gcc/testsuite/gcc.target/mips/inter/msa_1_main.c  |8 +
 gcc/testsuite/gcc.target/mips/inter/msa_1_x.c |   35 +
 gcc/testsuite/gcc.target/mips/inter/msa_1_y.c |   14 +
 9 files changed, 849 insertions(+), 497 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/mips/inter/msa-inter.exp
 create mode 100644 gcc/testsuite/gcc.target/mips/inter/msa_1.h
 create mode 100644 gcc/testsuite/gcc.target/mips/inter/msa_1_main.c
 create mode 100644 gcc/testsuite/gcc.target/mips/inter/msa_1_x.c
 create mode 100644 gcc/testsuite/gcc.target/mips/inter/msa_1_y.c

diff --git 

[PATCH] builtin fadd variants implementation

[Tejas Joshi]

Hi.
This patch includes fadd variants implementation for folding. The
patch bootstraps and survives regression tests on x86_64-linux-gnu.

Thanks,
Tejas

gcc/ChangeLog:

2019-08-08  Tejas Joshi  

* builtin-types.def: New function type variable arguments.
* builtins.def: New function definitions for fadd variants.
* fold-const-call.c (fold_const_fadd): New function for folding fadd
variants.
(fold_const_call): Add new cases for fadd variants.
* real.c (real_fadd): New function. Performs addition of two numbers
and returns result in narrowed down type.
* real.h: New function declaration for real_fadd.

gcc/testsuite/ChangeLog:

2019-08-08  Tejas Joshi  

* testsuite/gcc.dg/builtin-fadd-1.c: New test.
* testsuite/gcc.dg/builtin-fadd-2.c: New test.
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index e5c9e063c48..6bc552fa71a 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -387,8 +387,14 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_UINT_PTR,
 		 BT_VOID, BT_UINT, BT_PTR)
 DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_FLOAT_FLOAT,
 		 BT_FLOAT, BT_FLOAT, BT_FLOAT)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
+		 BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
+		 BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_DOUBLE_DOUBLE,
 		 BT_DOUBLE, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_LONGDOUBLE_LONGDOUBLE,
+		 BT_DOUBLE, BT_LONGDOUBLE, BT_LONGDOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE,
 		 BT_LONGDOUBLE, BT_LONGDOUBLE, BT_LONGDOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT16_FLOAT16_FLOAT16,
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 8bb7027aac7..2df616c477e 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -355,6 +355,9 @@ DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FABS, "fabs", FABS_TYPE, ATTR_CONST_NOT
 DEF_GCC_BUILTIN(BUILT_IN_FABSD32, "fabsd32", BT_FN_DFLOAT32_DFLOAT32, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_FABSD64, "fabsd64", BT_FN_DFLOAT64_DFLOAT64, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_FABSD128, "fabsd128", BT_FN_DFLOAT128_DFLOAT128, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADD, "fadd", BT_FN_FLOAT_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADDL, "faddl", BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_DADDL, "daddl", BT_FN_DOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_FDIM, "fdim", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_C99_BUILTIN(BUILT_IN_FDIMF, "fdimf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_C99_BUILTIN(BUILT_IN_FDIML, "fdiml", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index d9b546e6803..f895c89de96 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -570,6 +570,32 @@ fold_const_nextafter (real_value *result, const real_value *arg0,
   return true;
 }
 
+/* Try to evaluate:
+
+  *RESULT = fadd (*ARG0, *ARG1)
+
+   in format FORMAT.  Return true on success.  */
+
+static bool
+fold_const_fadd (real_value *result, const real_value *arg0,
+		 const real_value *arg1, const real_format *format)
+{
+  if (REAL_VALUE_ISSIGNALING_NAN (*arg0)
+  || REAL_VALUE_ISSIGNALING_NAN (*arg1))
+return false;
+
+  if (real_fadd (result, format, arg0, arg1)
+  && !flag_errno_math)
+return false;
+
+  if (!exact_real_truncate (format, result)
+  && !(flag_rounding_math && flag_trapping_math))
+return false;
+
+  real_convert (result, format, result);
+  return true;
+}
+
 /* Try to evaluate:
 
   *RESULT = ldexp (*ARG0, ARG1)
@@ -1644,6 +1670,25 @@ fold_const_call (combined_fn fn, tree type, tree arg0, tree arg1)
 case CFN_FOLD_LEFT_PLUS:
   return fold_const_fold_left (type, arg0, arg1, PLUS_EXPR);
 
+case CFN_BUILT_IN_FADD:
+case CFN_BUILT_IN_FADDL:
+case CFN_BUILT_IN_DADDL:
+  {
+	if (real_cst_p (arg0)
+	&& real_cst_p (arg1))
+	{
+	  machine_mode arg0_mode = TYPE_MODE (TREE_TYPE (arg0));
+	  gcc_checking_assert (SCALAR_FLOAT_MODE_P (arg0_mode));
+	  REAL_VALUE_TYPE result;
+	  machine_mode mode = TYPE_MODE (type);
+	  if (fold_const_fadd (, TREE_REAL_CST_PTR (arg0),
+			   TREE_REAL_CST_PTR (arg1),
+			   REAL_MODE_FORMAT (mode)))
+	return build_real (type, result);
+	}
+  }
+  return NULL_TREE;
+
 default:
   return fold_const_call_1 (fn, type, arg0, arg1);
 }
diff --git a/gcc/real.c b/gcc/real.c
index ab71430709f..280e434e897 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5093,6 +5093,30 @@ real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
 real_round (r, fmt, x);
 }
 
+/* Perform addition of X and Y and place the result in R to narrowed
+   down type. 

[PATCHv4] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

[Bernd Edlinger]

On 8/2/19 9:01 PM, Bernd Edlinger wrote:
> On 8/2/19 3:11 PM, Richard Biener wrote:
>> On Tue, 30 Jul 2019, Bernd Edlinger wrote:
>>
>>>
>>> I have no test coverage for the movmisalign optab though, so I
>>> rely on your code review for that part.
>>
>> It looks OK.  I tried to make it trigger on the following on
>> i?86 with -msse2:
>>
>> typedef int v4si __attribute__((vector_size (16)));
>>
>> struct S { v4si v; } __attribute__((packed));
>>
>> v4si foo (struct S s)
>> {
>>   return s.v;
>> }
>>
> 
> Hmm, the entry_parm need to be a MEM_P and an unaligned one.
> So the test case could be made to trigger it this way:
> 
> typedef int v4si __attribute__((vector_size (16)));
> 
> struct S { v4si v; } __attribute__((packed));
> 
> int t;
> v4si foo (struct S a, struct S b, struct S c, struct S d,
>   struct S e, struct S f, struct S g, struct S h,
>   int i, int j, int k, int l, int m, int n,
>   int o, struct S s)
> {
>   t = o;
>   return s.v;
> }
> 

Ah, I realized that there are already a couple of very similar
test cases: gcc.target/i386/pr35767-1.c, gcc.target/i386/pr35767-1d.c,
gcc.target/i386/pr35767-1i.c and gcc.target/i386/pr39445.c,
which also manage to execute the movmisalign code with the latest patch
version.  So I thought that it is not necessary to add another one.

> However the code path is still not reached, since targetm.slow_ualigned_access
> is always FALSE, which is probably a flaw in my patch.
> 
> So I think,
> 
> +  else if (MEM_P (data->entry_parm)
> +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
> + > MEM_ALIGN (data->entry_parm)
> +  && targetm.slow_unaligned_access (promoted_nominal_mode,
> +MEM_ALIGN (data->entry_parm)))
> 
> should probably better be
> 
> +  else if (MEM_P (data->entry_parm)
> +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
> + > MEM_ALIGN (data->entry_parm)
> +&& (((icode = optab_handler (movmisalign_optab, 
> promoted_nominal_mode))
> + != CODE_FOR_nothing)
> +|| targetm.slow_unaligned_access (promoted_nominal_mode,
> +  MEM_ALIGN (data->entry_parm
> 
> Right?
> 
> Then the modified test case would use the movmisalign optab.
> However nothing changes in the end, since the i386 back-end is used to work
> around the middle end not using movmisalign optab when it should do so.
> 

I prefer the second form of the check, as it offers more test coverage,
and is probably more correct than the former.

Note there are more variations of this misalign check in expr.c,
some are somehow odd, like expansion of MEM_REF and VIEW_CONVERT_EXPR:

&& mode != BLKmode
&& align < GET_MODE_ALIGNMENT (mode))
  {
if ((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothing)
  [...]
else if (targetm.slow_unaligned_access (mode, align))
  temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
0, TYPE_UNSIGNED (TREE_TYPE (exp)),
(modifier == EXPAND_STACK_PARM
 ? NULL_RTX : target),
mode, mode, false, alt_rtl);

I wonder if they are correct this way, why shouldn't we use the movmisalign
optab if it exists, regardless of TARGET_SLOW_UNALIGNED_ACCESSS ?


> I wonder if I should try to add a gcc_checking_assert to the mov expand
> patterns that the memory is properly aligned ?
>

Wow, that was a really exciting bug-hunt with those assertions around...

>> @@ -3292,6 +3306,23 @@ assign_parm_setup_reg (struct assign_parm_data_all
>>
>>did_conversion = true;
>>  }
>> +  else if (MEM_P (data->entry_parm)
>> +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
>> + > MEM_ALIGN (data->entry_parm)
>>
>> we arrive here by-passing
>>
>>   else if (need_conversion)
>> {
>>   /* We did not have an insn to convert directly, or the sequence
>>  generated appeared unsafe.  We must first copy the parm to a
>>  pseudo reg, and save the conversion until after all
>>  parameters have been moved.  */
>>
>>   int save_tree_used;
>>   rtx tempreg = gen_reg_rtx (GET_MODE (data->entry_parm));
>>
>>   emit_move_insn (tempreg, validated_mem);
>>
>> but this move instruction is invalid in the same way as the case
>> you fix, no?  So wouldn't it be better to do
>>
> 
> We could do that, but I supposed that there must be a reason why
> assign_parm_setup_stack gets away with that same:
> 
>   if (data->promoted_mode != data->nominal_mode)
> {
>   /* Conversion is required.  */
>   rtx tempreg = gen_reg_rtx (GET_MODE (data->entry_parm));
> 
>   emit_move_insn (tempreg, validize_mem (copy_rtx (data->entry_parm)));
> 
> 
> So either some back-ends are too permissive with 

[C++ Patch] More grokdeclarator locations fixes

[Paolo Carlini]

Hi,

these are all more or less straightforward, exploit the existing 
infrastructure. Nits: the first change also removes an 'a' in the 
wording because all the other error messages - a few - mentioning class 
or namespace don't have it; the fixes using EXPR_LOCATION also change 
%qD to %qE because we are dealing with BIT_NOT_EXPRs.


Thanks, Paolo.

///

/cp
2019-08-08  Paolo Carlini  

* decl.c (grokdeclarator): Use id_loc and EXPR_LOCATION in
a few error messages.

/testsuite
2019-08-08  Paolo Carlini  

* g++.dg/cpp0x/enum20.C: Test location(s) too.
* g++.dg/other/friend3.C: Likewise.
* g++.dg/parse/dtor5.C: Likewise.
* g++.dg/parse/friend7.C: Likewise.
* g++.dg/template/error22.C: Likewise.
* g++.old-deja/g++.brendan/err-msg5.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 274195)
+++ cp/decl.c   (working copy)
@@ -10579,7 +10579,8 @@ grokdeclarator (const cp_declarator *declarator,
ctype = qualifying_scope;
if (!MAYBE_CLASS_TYPE_P (ctype))
  {
-   error ("%q#T is not a class or a namespace", ctype);
+   error_at (id_declarator->id_loc,
+ "%q#T is not a class or namespace", ctype);
ctype = NULL_TREE;
  }
else if (innermost_code != cdk_function
@@ -10601,13 +10602,15 @@ grokdeclarator (const cp_declarator *declarator,
{
  if (innermost_code != cdk_function)
{
- error ("declaration of %qD as non-function", decl);
+ error_at (EXPR_LOCATION (decl),
+   "declaration of %qE as non-function", decl);
  return error_mark_node;
}
  else if (!qualifying_scope
   && !(current_class_type && at_class_scope_p ()))
{
- error ("declaration of %qD as non-member", decl);
+ error_at (EXPR_LOCATION (decl),
+   "declaration of %qE as non-member", decl);
  return error_mark_node;
}
 
@@ -12510,7 +12513,7 @@ grokdeclarator (const cp_declarator *declarator,
else if (in_namespace && !friendp)
  {
/* Something like struct S { int N::j; };  */
-   error ("invalid use of %<::%>");
+   error_at (id_loc, "invalid use of %<::%>");
return error_mark_node;
  }
else if (FUNC_OR_METHOD_TYPE_P (type) && unqualified_id)
@@ -12565,15 +12568,15 @@ grokdeclarator (const cp_declarator *declarator,
if (!ctype)
  {
gcc_assert (friendp);
-   error ("expected qualified name in friend declaration "
-  "for destructor %qD", uqname);
+   error_at (id_loc, "expected qualified name in friend "
+ "declaration for destructor %qD", uqname);
return error_mark_node;
  }
 
if (!check_dtor_name (ctype, TREE_OPERAND (uqname, 0)))
  {
-   error ("declaration of %qD as member of %qT",
-  uqname, ctype);
+   error_at (id_loc, "declaration of %qD as member of %qT",
+ uqname, ctype);
return error_mark_node;
  }
 if (concept_p)
Index: testsuite/g++.dg/cpp0x/enum20.C
===
--- testsuite/g++.dg/cpp0x/enum20.C (revision 274195)
+++ testsuite/g++.dg/cpp0x/enum20.C (working copy)
@@ -2,4 +2,4 @@
 // { dg-do compile { target c++11 } }
 
 enum A { };
-void A::f() { }// { dg-error "not a class" }
+void A::f() { }// { dg-error "6:.enum A. is not a 
class" }
Index: testsuite/g++.dg/other/friend3.C
===
--- testsuite/g++.dg/other/friend3.C(revision 274195)
+++ testsuite/g++.dg/other/friend3.C(working copy)
@@ -4,10 +4,10 @@
 
 struct A
 {
-  friend ~A();  // { dg-error "qualified name" }
+  friend ~A();  // { dg-error "10:expected qualified name" }
 };
 
 struct B
 {
-  friend ~A();  // { dg-error "qualified name" }
+  friend ~A();  // { dg-error "10:expected qualified name" }
 };
Index: testsuite/g++.dg/parse/dtor5.C
===
--- testsuite/g++.dg/parse/dtor5.C  (revision 274195)
+++ testsuite/g++.dg/parse/dtor5.C  (working copy)
@@ -1,12 +1,12 @@
 // PR c++/19732
 
 struct A;
-typedef int ~A; // { dg-error "non-function" }
+typedef int ~A; // { 

[MSP430][PATCH 0/2] Improve and extend MCU data handling

[Jozef Lawrynowicz]

Each different MSP430 MCU has two properties that affect code generation, the
CPU ISA and the hardware multiply support. These can be manually specified with
the -mcpu= and -mhwmult= options, respectively.
The existing -mmcu= option takes an MCU name as an argument and uses the CPU
ISA and hardware multiply known to be supported for that MCU during code
generation, so the user does not have to provide the -mcpu and -mhwmult options.

The first patch improves the handling of MCU data by consolidating multiple
copies of hard-coded MCU data into a single location, and adds a new function
to be used as a single entry point for the extraction of MCU data for the
selected MCU.

The second patch extends the MCU data handling so that MCU data can be provided
in an external file (devices.csv). This means the compiler doesn't have to be
updated and rebuilt to support new devices when they are released.

Successfully regtested for msp430-elf on trunk.

Ok for trunk?

Thanks,
Jozef

Jozef Lawrynowicz (2):
  MSP430: Devices [1]: Consolidate handling of hard-coded MCU data
  MSP430: Devices [2]: Read MCU data from external devices.csv file, if
it exists

 gcc/config.gcc|   3 +-
 gcc/config/msp430/driver-msp430.c | 675 +---
 gcc/config/msp430/msp430-devices.c| 971 ++
 gcc/config/msp430/msp430-devices.h|  31 +
 gcc/config/msp430/msp430.c| 680 +---
 gcc/config/msp430/msp430.h|  18 +-
 gcc/config/msp430/msp430.opt  |   9 +
 gcc/config/msp430/t-msp430| 236 +
 gcc/doc/invoke.texi   |  14 +-
 .../gcc.target/msp430/devices-main.c  |   6 +
 .../gcc.target/msp430/devices/README  |  17 +
 .../gcc.target/msp430/devices/bad-devices-1.c |   5 +
 .../msp430/devices/bad-devices-1.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-2.c |   5 +
 .../msp430/devices/bad-devices-2.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-3.c |   5 +
 .../msp430/devices/bad-devices-3.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-4.c |   5 +
 .../msp430/devices/bad-devices-4.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-5.c |   5 +
 .../msp430/devices/bad-devices-5.csv  |   3 +
 .../gcc.target/msp430/devices/bad-devices-6.c |   5 +
 .../msp430/devices/bad-devices-6.csv  |   3 +
 .../msp430/devices/csv-device-order.c |  11 +
 .../gcc.target/msp430/devices/csv-msp430_00.c |   7 +
 .../gcc.target/msp430/devices/csv-msp430_01.c |   7 +
 .../gcc.target/msp430/devices/csv-msp430_02.c |   7 +
 .../gcc.target/msp430/devices/csv-msp430_04.c |   7 +
 .../gcc.target/msp430/devices/csv-msp430_08.c |   7 +
 .../gcc.target/msp430/devices/csv-msp430_10.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_11.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_12.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_14.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_18.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_20.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_21.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_22.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_24.c |   6 +
 .../gcc.target/msp430/devices/csv-msp430_28.c |   6 +
 .../msp430/devices/csv-msp430fr5969.c |  11 +
 .../gcc.target/msp430/devices/devices.csv |  22 +
 .../msp430/devices/hard-cc430f5123.c  |   7 +
 .../gcc.target/msp430/devices/hard-foo.c  |   6 +
 .../msp430/devices/hard-msp430afe253.c|   8 +
 .../msp430/devices/hard-msp430cg4616.c|   7 +
 .../msp430/devices/hard-msp430f4783.c |   8 +
 .../msp430/devices/hard-rf430frl154h_rom.c|   8 +
 gcc/testsuite/gcc.target/msp430/msp430.exp|  96 +-
 48 files changed, 1476 insertions(+), 1511 deletions(-)
 create mode 100644 gcc/config/msp430/msp430-devices.c
 create mode 100644 gcc/config/msp430/msp430-devices.h
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices-main.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/README
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-1.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-1.csv
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-2.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-2.csv
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-3.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-3.csv
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-4.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-4.csv
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-5.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-5.csv
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/bad-devices-6.c
 

[PATCH] Port value profiling to -fopt-info infrastructure.

[Martin Liška]

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  

* value-prof.c (gimple_divmod_fixed_value_transform):
Use dump_printf_loc.
(gimple_mod_pow2_value_transform): Likewise.
(gimple_mod_subtract_transform): Likewise.
(init_node_map): Likewise.
(gimple_ic_transform): Likewise.
(gimple_stringops_transform): Likewise.

gcc/testsuite/ChangeLog:

2019-08-08  Martin Liska  

* g++.dg/tree-prof/indir-call-prof.C: Add -optimize
to -fdump-ipa-profile.
* g++.dg/tree-prof/morefunc.C: Likewise.
* g++.dg/tree-prof/reorder.C: Likewise.
* gcc.dg/tree-prof/ic-misattribution-1.c: Likewise.
* gcc.dg/tree-prof/indir-call-prof.c: Likewise.
* gcc.dg/tree-prof/stringop-1.c: Likewise.
* gcc.dg/tree-prof/stringop-2.c: Likewise.
* gcc.dg/tree-prof/val-prof-1.c: Likewise.
* gcc.dg/tree-prof/val-prof-2.c: Likewise.
* gcc.dg/tree-prof/val-prof-3.c: Likewise.
* gcc.dg/tree-prof/val-prof-4.c: Likewise.
* gcc.dg/tree-prof/val-prof-5.c: Likewise.
* gcc.dg/tree-prof/val-prof-7.c: Likewise.
---
 .../g++.dg/tree-prof/indir-call-prof.C|   2 +-
 gcc/testsuite/g++.dg/tree-prof/morefunc.C |   2 +-
 gcc/testsuite/g++.dg/tree-prof/reorder.C  |   2 +-
 .../gcc.dg/tree-prof/ic-misattribution-1.c|   2 +-
 .../gcc.dg/tree-prof/indir-call-prof.c|   2 +-
 gcc/testsuite/gcc.dg/tree-prof/stringop-1.c   |   2 +-
 gcc/testsuite/gcc.dg/tree-prof/stringop-2.c   |   2 +-
 gcc/testsuite/gcc.dg/tree-prof/val-prof-1.c   |   2 +-
 gcc/testsuite/gcc.dg/tree-prof/val-prof-2.c   |   2 +-
 gcc/testsuite/gcc.dg/tree-prof/val-prof-3.c   |   2 +-
 gcc/testsuite/gcc.dg/tree-prof/val-prof-4.c   |   2 +-
 gcc/testsuite/gcc.dg/tree-prof/val-prof-5.c   |   2 +-
 gcc/testsuite/gcc.dg/tree-prof/val-prof-7.c   |   2 +-
 gcc/value-prof.c  | 105 +-
 14 files changed, 64 insertions(+), 67 deletions(-)


diff --git a/gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C b/gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C
index 3134c3c0643..be896c02774 100644
--- a/gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C
+++ b/gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fdump-tree-optimized -fdump-ipa-profile -fdump-ipa-afdo" } */
+/* { dg-options "-O2 -fdump-tree-optimized -fdump-ipa-profile-optimized -fdump-ipa-afdo" } */
 
 struct A {
   A () {}
diff --git a/gcc/testsuite/g++.dg/tree-prof/morefunc.C b/gcc/testsuite/g++.dg/tree-prof/morefunc.C
index a9bdc167f45..621d09aec5b 100644
--- a/gcc/testsuite/g++.dg/tree-prof/morefunc.C
+++ b/gcc/testsuite/g++.dg/tree-prof/morefunc.C
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fno-devirtualize --param=profile-func-internal-id=0 -fdump-ipa-profile -fdump-ipa-afdo -Wno-attributes -Wno-coverage-mismatch -Wno-missing-profile" } */
+/* { dg-options "-O2 -fno-devirtualize --param=profile-func-internal-id=0 -fdump-ipa-profile-optimized -fdump-ipa-afdo -Wno-attributes -Wno-coverage-mismatch -Wno-missing-profile" } */
 #include "reorder_class1.h"
 #include "reorder_class2.h"
 
diff --git a/gcc/testsuite/g++.dg/tree-prof/reorder.C b/gcc/testsuite/g++.dg/tree-prof/reorder.C
index 6b3bad1f54d..000fb651a69 100644
--- a/gcc/testsuite/g++.dg/tree-prof/reorder.C
+++ b/gcc/testsuite/g++.dg/tree-prof/reorder.C
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fno-devirtualize --param=profile-func-internal-id=0 -fdump-ipa-profile -fdump-ipa-afdo -Wno-coverage-mismatch -Wno-attributes" } */
+/* { dg-options "-O2 -fno-devirtualize --param=profile-func-internal-id=0 -fdump-ipa-profile-optimized -fdump-ipa-afdo -Wno-coverage-mismatch -Wno-attributes" } */
 
 #ifdef _PROFILE_USE
 #include "reorder_class1.h"
diff --git a/gcc/testsuite/gcc.dg/tree-prof/ic-misattribution-1.c b/gcc/testsuite/gcc.dg/tree-prof/ic-misattribution-1.c
index 3979b17b156..126236eba8e 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/ic-misattribution-1.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/ic-misattribution-1.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fdump-ipa-profile" } */
+/* { dg-options "-O2 -fdump-ipa-profile-optimized" } */
 /* { dg-additional-sources "ic-misattribution-1a.c" } */
 
 extern void other_caller (void);
diff --git a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c
index 53063c3e7fa..3ca78936e1c 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fdump-tree-optimized -fdump-ipa-profile -fdump-ipa-afdo" } */
+/* { dg-options "-O2 -fdump-tree-optimized -fdump-ipa-profile-optimized -fdump-ipa-afdo" } */
 
 static int a1 (void)
 {
diff --git 

Re: [testsuite] use rand instead of random

[Segher Boessenkool]

On Thu, Aug 08, 2019 at 03:30:55AM -0300, Alexandre Oliva wrote:
> rand is in ISO C, whereas random is only in POSIX, so it makes sense
> to use the more portable function everywhere instead of falling back
> from one to the other on systems that miss the less portable one.
> 
> Tested on x86_64-linux-gnu, native and cross to ppc.  Ok to install?
> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/i386/sse2-mul-1.c: Use rand.  Drop fallback.
>   * gcc.target/i386/sse4_1-blendps-2.c: Likewise.
>   * gcc.target/i386/sse4_1-blendps.c: Likewise.
>   * gcc.target/i386/xop-vshift-1.c: Likewise.
>   * gcc.target/powerpc/direct-move.h: Likewise.

Okay for the powerpc part.  Thanks,


Segher

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

[Michael Matz]

Hi,

On Thu, 8 Aug 2019, Martin Liška wrote:

> > So docs have
> > 
> > @defmac JUMP_ALIGN (@var{label})
> > The alignment (log base 2) to put in front of @var{label}, which is
> > a common destination of jumps and has no fallthru incoming edge.

So, per docu: JUMP_ALIGN implies !fallthru ...

> >   align_flags alignment = has_fallthru ? JUMP_ALIGN (label) :
> > LOOP_ALIGN (label);

... exactly the opposite way here.

> > instead of the two different conditions?  Or the JUMP_ALIGN case
> > computing "common destination" instead of "frequently executed"
> > somehow but I think it makes sense that those are actually the same
> > here (frequently executed).  It oddly looks at prev_bb and is not
> > guarded with optimize_bb_for_speed_p at all so this all is
> > full of heuristics and changing anything here just based on x86
> > measurements is surely going to cause issues for targets more
> > sensitive to (mis-)alignment.
> 
> I like you patch, it's a rapid simplification of the code which
> we have there.

Yeah, but it's also contradicting the documentation.  And I think the docu 
makes sense, because it means that there is no padding inserted on the 
fall-thru path (because there is none).  So please measure with the 
opposite direction.  (I still think these conditions shouldn't be 
hot-needled, but rather should somewhat make sense in the abstract).


Ciao,
Michael.