Re: [patch, fortran] Handling of .and. and .or. expressions

[Janus Weil]

2018-06-27 23:47 GMT+02:00 Steve Kargl :
> On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
>> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
>> >
>> > And we are not going to change Fortran semantics. And I also oppose
>> > defining our own subset of Fortran in the hope that people will make
>> > fewer mistakes.
>> >
>> > A function is something that produces a value.  If the value is not
>> > needed to produce the correct result, the function need not be called.
>>
>> That's a bit oversimplified, isn't it?
>
> Technically, the standard says an operand need not be evaluate,
> but you've asked people not to cite the Standard.  I've also
> pointed you to F2018 Note 10.28 where it very clearly says that
> a function need not be evaluated with example nearly identical
> to the one in the PR.  PURE vs IMPURE (or unmarked) function
> is a red herring.  The standard makes no distinction.

Look, Steve. This argument has been going in circles for weeks now. I
think we can stop it here.

So, again: I know that the Fortran standard allows the
short-circuiting of impure functions. I'm not trying to change that
behavior. (I don't like it but I certainly have to accept it.)

But that still leaves us with a problem: The standard allows the
short-circuiting but it doesn't require it. Meaning that any other
compiler that does not do it (like ifort) is not in conflict with the
standard either.

Many people may want to avoid such compiler-dependent behavior. That's
why we need a warning. All of the discussion here has shown that using
impure functions in logical expressions is not a good idea in Fortran.
It is not illegal, but it should be considered bad style. That's why
we need a warning:

https://gcc.gnu.org/ml/fortran/2018-06/msg00160.html

Does anyone agree with me that this is a useful diagnostic? Whether
this warning should be included in -Wall or -Wextra or -Whereever can
be debated. Is this patch ok for trunk?

Cheers,
Janus


2018-06-27 23:47 GMT+02:00 Steve Kargl :
> On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
>> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
>> >
>> > And we are not going to change Fortran semantics. And I also oppose
>> > defining our own subset of Fortran in the hope that people will make
>> > fewer mistakes.
>> >
>> > A function is something that produces a value.  If the value is not
>> > needed to produce the correct result, the function need not be called.
>>
>> That's a bit oversimplified, isn't it?
>
> Technically, the standard says an operand need not be evaluate,
> but you've asked people not to cite the Standard.  I've also
> pointed you to F2018 Note 10.28 where it very clearly says that
> a function need not be evaluated with example nearly identical
> to the one in the PR.  PURE vs IMPURE (or unmarked) function
> is a red herring.  The standard makes no distinction.
>
> --
> Steve

Re: [PATCH] Fix PR84101, account for function ABI details in vectorization costs

[Jeff Law]

[ Returning to an old patch... ]
On 02/14/2018 04:52 AM, Richard Biener wrote:
> On Tue, 13 Feb 2018, Jeff Law wrote:
> 
>> On 01/30/2018 02:59 AM, Richard Biener wrote:
>>>
>>> This patch tries to deal with the "easy" part of a function ABI,
>>> the return value location, in vectorization costing.  The testcase
>>> shows that if we vectorize the returned value but the function
>>> doesn't return in memory or in a vector register but as in this
>>> case in an integer register pair (reg:TI ax) (bah, ABI details
>>> exposed late?  why's this not a parallel?) we end up spilling
>>> badly.
>> PARALLEL is used when the ABI mandates a value be returned in multiple
>> places.  Typically that happens when the value is returned in different
>> types of registers (integer, floating point, vector).
>>
>> Presumably it's not a PARALLEL in this case because the value is only
>> returned in %eax.
> 
> It's returned in %eax and %rdx (TImode after all).  But maybe
> "standard register pairs" are not represented as PARALLEL ...
Register pairs and PARALLELs handle two different issues.

A register pair such as eax/edx is used to hold a value that is larger
than a single register.

A PARALLEL is used to hold a return value that has to appear in multiple
places.  So for example a0/d0 on m68k in some circumstances.

They can even be combined.  You might have eax/edx as the first entry in
a parallel with xmm0 as the second entry.  That would indicate a TImode
value that is in eax/edx as well as in xmm0.

>From the standpoint of costing the spills for a return value we can
generate the return value into any object in the PARALLEL, but we will
have to copy it to all the other objects in the PARALLEL.

So if none of the objects in the PARALLEL are suitable for vector
operations, then obviously we're going to have to copy from the vector
register to all the elements in the PARALLEL.  This is the most
expensive case.

If one of the objects in the PARALLEL is suitable for vector ops, then
that's where we want the result to end up.  We still have to copy the
result to the other elements in the PARALLEL, but it's one less
copy/spill than the previous case.

Note that copying might have to go through memory on some targets if the
registers in the PARALLEL are in different register files.

CONCAT is (IIRC) not supposed to show up in the RTL chain at all.

Note that expr.c may do something stupid with vectors.  Just looking at
emit_group_load_1 makes me wonder if everything is going to go through
memory when we've got PARALLELs and vectors.  That may actually make
your changes to vect_mode_store_cost more correct.

Jeff

Re: [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125)

[Jeff Law]

On 06/26/2018 05:32 PM, Martin Sebor wrote:
> Attached is an updated patch to tighten up the warning and also
> prevent ICEs in the middle-end like in PR 86308 or PR 86202.
> 
> I took Richard's suggestion to add the POINTER_TYPE_P() check
> to detect pointer/integer conflicts.  That also avoids the ICEs
> above.
> 
> I also dealt with the fileptr_type_node problem so that file
> I/O built-ins can be declared to take any object pointer type
> as an argument, and that argument has to be the same for all
> them.
> 
> I'm not too happy about the interaction with -Wextra but short
> of enabling the stricter checks even without it or introducing
> multiple levels for -Wbuiltin-declaration-mismatch I don't see
> a good alternative.
> 
> Martin
> 
> gcc-86125.diff
> 
> 
> PR c/86125 - missing -Wbuiltin-declaration-mismatch on a mismatched return 
> type
> PR middle-end/86308 - ICE in verify_gimple calling index() with an invalid 
> declaration
> PR middle-end/86202 - ICE in get_range_info calling an invalid memcpy() 
> declaration
> 
> gcc/c/ChangeLog:
> 
>   PR c/86125
>   PR middle-end/86202
>   PR middle-end/86308
>   * c-decl.c (match_builtin_function_types): Add arguments.
>   (diagnose_mismatched_decls): Diagnose mismatched declarations
>   of built-ins more strictly.
>   * doc/invoke.texi (-Wbuiltin-declaration-mismatch): Update.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c/86125
>   PR middle-end/86202
>   PR middle-end/86308
>   * gcc.dg/Wbuiltin-declaration-mismatch.c: New test.
>   * gcc.dg/Wbuiltin-declaration-mismatch-2.c: New test.
>   * gcc.dg/Wbuiltin-declaration-mismatch-3.c: New test.
>   * gcc.dg/Wbuiltin-declaration-mismatch-4.c: New test.
>   * gcc.dg/builtins-69.c: New test.

[ ... ]

> 
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index af16cfd..6c9e667 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -1628,43 +1628,82 @@ c_bind (location_t loc, tree decl, bool is_global)
>bind (DECL_NAME (decl), decl, scope, false, nested, loc);
>  }
>  
> +
>  /* Subroutine of compare_decls.  Allow harmless mismatches in return
> and argument types provided that the type modes match.  This function
> -   return a unified type given a suitable match, and 0 otherwise.  */
> +   returns a unified type given a suitable match, and 0 otherwise.  */
>  
>  static tree
> -match_builtin_function_types (tree newtype, tree oldtype)
> +match_builtin_function_types (tree newtype, tree oldtype,
> +   tree *strict, unsigned *argno)
As Joseph notes, you need to update the function comment here.

[ ... ]

>> +  /* Store the first FILE* argument type seen (whatever it is),
> +  and expect any subsequent declarations of file I/O built-ins
> +  to refer to it rather than to fileptr_type_node which is just
> +  void*.  */
> +   static tree last_fileptr_type;
Is this actually safe?  Isn't the type in GC memory?  And if so, what
prevents it from being GC'd?  At the least I think you need to register
this as a GC root.  Why are we handling fileptr_types specially here to
begin with?

jeff

Re: [PATCH][Middle-end]3rd patch of PR78809

[Jeff Law]

On 06/18/2018 09:37 AM, Qing Zhao wrote:
> Hi,
> 
> this is the 3rd (and the last) patch for PR78809:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
> Inline strcmp with small constant strings
> 
> The design doc for PR78809 is at:
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html
> 
> this patch is for the third part of change of PR78809.
> 
> C. for strcmp (s1, s2), strncmp (s1, s2, n), and memcmp (s1, s2, n)
>if the result is NOT used to do simple equality test against zero, one of
> "s1" or "s2" is a small constant string, n is a constant, and the Min value of
> the length of the constant string and "n" is smaller than a predefined
> threshold T,
>inline the call by a byte-to-byte comparision sequence to avoid calling
> overhead.
> 
> adding test case strcmpopt_5.c into gcc.dg for part C of PR78809.
> 
> bootstraped and tested on both X86 and Aarch64. no regression.
> 
> I have done some experiments to check the run-time performance impact 
> and code-size impact from such inlining with different threshold for the
> length of the constant string to inline, the data were recorded in the 
> attachments of 
> PR78809:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809.
> 
> and finally decide that the default value of the threshold is 3. 
> this value of the threshold can be adjusted by the new option:
> 
> --param builtin-string-cmp-inline-length=
> 
> The following is the patch.
> 
> thanks.
> 
> Qing
> 
> gcc/ChangeLog:
> 
> +2018-06-18  Qing Zhao  
> +
> +   PR middle-end/78809
> +   * builtins.c (expand_builtin_memcmp): Inline the calls first
> +   when result_eq is false.
> +   (expand_builtin_strcmp): Inline the calls first.
> +   (expand_builtin_strncmp): Likewise.
> +   (inline_string_cmp): New routine. Expand a string compare 
> +   call by using a sequence of char comparison.
> +   (inline_expand_builtin_string_cmp): New routine. Inline expansion
> +   a call to str(n)cmp/memcmp.
> +   * doc/invoke.texi (--param builtin-string-cmp-inline-length): New 
> option.
> +   * params.def (BUILTIN_STRING_CMP_INLINE_LENGTH): New.
> +
> 
> gcc/testsuite/ChangeLog:
> 
> +2018-06-18  Qing Zhao  
> +
> +   PR middle-end/78809
> +   * gcc.dg/strcmpopt_5.c: New test.
So I still need to dig into this patch.  But I wanted to raise an
potential issue and get yours and Martin's thoughts on it.

Martin (and others) have been working hard to improve GCC's ability to
give good diagnostics for various problems with calls to mem* and str*
functions (buffer overflows, restrict issues, etc).

One of the problems Martin has identified is early conversion of these
calls into inlined direct operations.  If those conversions happen prior
to the analysis for warnings we obviously can't issue any relevant warnings.


> +
> 
> 
> 
> 0001-3nd-Patch-for-PR78009.patch
> 
> 
> From fcf6ced44e6e3e4a14894cc8f43ac39bc17aafee Mon Sep 17 00:00:00 2001
> From: qing zhao 
> Date: Thu, 14 Jun 2018 14:32:46 -0700
> Subject: [PATCH] 3nd Patch for PR78009
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
> Inline strcmp with small constant strings
> 
> The design doc for PR78809 is at:
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html
> 
> this patch is for the third part of change of PR78809.
> 
> C. for strcmp (s1, s2), strncmp (s1, s2, n), and memcmp (s1, s2, n)
>if the result is NOT used to do simple equality test against zero, one of
> "s1" or "s2" is a small constant string, n is a constant, and the Min value of
> the length of the constant string and "n" is smaller than a predefined
> threshold T,
>inline the call by a byte-to-byte comparision sequence to avoid calling
> overhead.
> 
> adding test case strcmpopt_5.c into gcc.dg for part C of PR78809.
> 
> bootstraped and tested on both X86 and Aarch64. no regression.
> ---
>  gcc/builtins.c | 172 
> +++--
>  gcc/doc/invoke.texi|   5 ++
>  gcc/params.def |   4 +
>  gcc/testsuite/gcc.dg/strcmpopt_5.c |  80 +
>  4 files changed, 253 insertions(+), 8 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/strcmpopt_5.c
> 
> diff --git a/gcc/builtins.c b/gcc/builtins.c
> index 6b3e6b2..cf50d05 100644
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -4358,6 +4360,17 @@ expand_builtin_memcmp (tree exp, rtx target, bool 
> result_eq)
>POINTER_TYPE, POINTER_TYPE, INTEGER_TYPE, VOID_TYPE))
>  return NULL_RTX;
>  
> +  /* due to the performance benefit, always inline the calls first 
> + when result_eq is false.  */
Please capitalize the first word in sentences like this.  This nit
appears in most of your comments.


> +  rtx result = NULL_RTX;
> +   
> +  if (!result_eq) 
> +{
> +  result = inline_expand_builtin_string_cmp (exp, target, true);
> +  if (result)
> + return result;
> +}
> +
So I believe you do inline expansion here 

Re: [patch, i386] false dependencies fix

[Jeff Law]

On 05/02/2018 03:55 AM, Nesterovskiy, Alexander wrote:
> This patch fixes false dependencies for vmovss, vmovsd, vrcpss, vrsqrtss, 
> vsqrtss and vsqrtsd instructions.
> 
> Tested on x86-64/Linux, no new test fails, some SPEC 2006/2017 performance 
> gains.
> Please let me know if something is wrong here and should be changed.
> 
> --
> Alexander Nesterovskiy
> 
> 
> falsedep.patch
> 
> 
> --- i386.md   (revision 259756)
> +++ i386.md   (working copy)
> @@ -3547,7 +3547,7 @@
>   {
>   case MODE_DF:
> if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
> - return "vmovsd\t{%1, %0, %0|%0, %0, %1}";
> + return "%vmovsd\t{%d1, %0|%0, %d1}";
> return "%vmovsd\t{%1, %0|%0, %1}";
>  
>   case MODE_V4SF:
> @@ -3748,7 +3748,7 @@
>   {
>   case MODE_SF:
> if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
> - return "vmovss\t{%1, %0, %0|%0, %0, %1}";
> + return "%vmovss\t{%d1, %0|%0, %d1}";
> return "%vmovss\t{%1, %0|%0, %1}";
So what I'm confused about is in the original output template operand 0
is duplicated. In the new template operand 1 is duplicated.

Presumably what you're trying to accomplish is avoiding a false read on
operand 0 (the destination)?  Can you please confirm?

Knowing that should also help me evaluate the changes to recp and rsqrt
since they're being changed to the same style encoding when operating
strictly on registers.


THanks,
jeff

Re: [ABSU_EXPR] Add some of the missing patterns in match,pd

[Jeff Law]

On 06/27/2018 10:11 PM, Marc Glisse wrote:
> (why is there no mention of ABSU_EXPR in doc/* ?)
[ ... ]
Kugan,

Please address Marc's comments and repost.

Marc, thanks for chiming in.

jeff

Re: [ABSU_EXPR] Add some of the missing patterns in match,pd

[Marc Glisse]

(why is there no mention of ABSU_EXPR in doc/* ?)

--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -571,10 +571,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(copysigns (op @0) @1)
(copysigns @0 @1

-/* abs(x)*abs(x) -> x*x.  Should be valid for all types.  */
-(simplify
- (mult (abs@1 @0) @1)
- (mult @0 @0))
+/* abs(x)*abs(x) -> x*x.  Should be valid for all types.
+   also for absu(x)*absu(x) -> x*x.  */
+(for op (abs absu)
+ (simplify
+  (mult (op@1 @0) @1)
+  (mult @0 @0)))

1) the types are wrong, it should be (convert (mult @0 @0)), or maybe 
view_convert if vectors also use absu.
2) this is only valid with -fwrapv (TYPE_OVERFLOW_WRAPS(TREE_TYPE(@0))), 
otherwise you are possibly replacing a multiplication on unsigned with a 
multiplication on signed that may overflow. So maybe it is actually 
supposed to be

(mult (convert @0) (convert @0))

 /* cos(copysign(x, y)) -> cos(x).  Similarly for cosh.  */
 (for coss (COS COSH)
@@ -1013,15 +1015,24 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   && tree_nop_conversion_p (type, TREE_TYPE (@2)))
   (bit_xor (convert @1) (convert @2

-(simplify
- (abs (abs@1 @0))
- @1)
-(simplify
- (abs (negate @0))
- (abs @0))
-(simplify
- (abs tree_expr_nonnegative_p@0)
- @0)
+/* Convert abs (abs (X)) into abs (X).
+   also absu (absu (X)) into absu (X).  */
+(for op (abs absu)
+ (simplify
+  (op (op@1 @0))
+  @1))

You cannot have (absu (absu @0)) since absu takes a signed integer and 
returns an unsigned one. (absu (abs @0)) may indeed be equivalent to 
(convert (abs @0)). Possibly (op (convert (absu @0))) could also be 
simplified if convert is a NOP.


+/* Convert abs[u] (-X) -> abs[u] (X).  */
+(for op (abs absu)
+ (simplify
+  (op (negate @0))
+  (op @0)))
+
+/* Convert abs[u] (X)  where X is nonnegative -> (X).  */
+(for op (abs absu)
+ (simplify
+  (op tree_expr_nonnegative_p@0)
+  @0))

Missing convert again.

Where are the testcases?

Bootstrap and regression testing on x86_64-linux-gnu. Is this OK if no 
regressions.


Does it mean you have run the tests or intend to run them in the future? 
It is confusing.


--
Marc Glisse

Re: [ABSU_EXPR] Add some of the missing patterns in match,pd

[Jeff Law]

On 06/27/2018 06:25 PM, Kugan Vivekanandarajah wrote:
> Hi,
> 
> This patch adds some of the missing patterns in match.pd for ABSU_EXPR.
> 
> Bootstrap and regression testing on x86_64-linux-gnu. Is this OK if no
> regressions.
> 
> Thanks,
> Kugan
> 
> gcc/ChangeLog:
> 
> 2018-06-28  Kugan Vivekanandarajah  
> 
> * match.pd (absu(x)*absu(x) -> x*x): Handle.
> (absu(absu(X)) -> absu(X)): Likewise.
> (absu(-X) -> absu(X)): Likewise.
> (absu(X)  where X is nonnegative -> X): Likewise.
> 
OK once testing is complete.

Thanks,
jeff

Re: Documentation: -gsplit-dwarf missing from Option Summary

[Jeff Law]

On 06/26/2018 07:10 AM, Stephan Bergmann wrote:
> Cannot identify what sorting is used for that list (if any), so putting
> it at the end (and -gsplit-dwarf also follows -fvar-tracking-assignments
> in the "Options for Debugging Your Program" section).
> 
> 
> Author: Stephan Bergmann 
> Date:   Tue Jun 26 15:04:54 2018 +0200
> 
>     Documentation: -gsplit-dwarf missing from Option Summary
It is a bit of a mess and unclear where precisely it belongs within that
list.  But it most certainly does belong somewhere in the list.

I put it in a slightly different place and commmitted the patch to the
trunk.

Thanks,
jeff

Re: [PATCH v2] Fix LRA to handle multi-word eliminable registers

[Jeff Law]

On 06/23/2018 06:38 AM, Dimitar Dimitrov wrote:
> 2018-06-23  Dimitar Dimitrov  
> 
>   * lra-eliminations.c (update_reg_eliminate): Mark all spanning hard
>   registers for Pmode..
>   * lra-lives.c (check_pseudos_live_through_calls): Mark all spanning
>   hard registers for the clobbered pseudo.
Thanks.  I put this through the usual bootstrap & regression tests and
installed the change onto the trunk.

jeff

Re: [PATCH 11/11] Increase MAX_MAX_OPERANDS limit

[Jeff Law]

On 06/23/2018 06:26 AM, Dimitar Dimitrov wrote:
> On петък, 22 юни 2018 г. 19:41:55 EEST Jakub Jelinek wrote:
>> On Fri, Jun 22, 2018 at 11:33:06AM -0600, Jeff Law wrote:
>>> On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote:
 The PRU load/store instructions can access memory with byte

 granularity for all 30 of its 32-bit GP registers. Examples:
# Load 17 bytes from address r0[0] into registers r10.b1-r14.b2
lbbo r10.b1, r0, 0, 17

# Load 100 bytes from address r28[0] into registers r0-r25
lbbo r0.b0, r28, 0, 100

 The load/store multiple patterns declare all subsequent registers
 as distinct operands. Hence the need to increase the limit.
>>
>> Can't you have a look on how other targets, e.g. arm, aarch64, s390x
>> etc. handle load/store multiple patterns, e.g. with match_parallel or
>> match_par_dup?
>> The instructions then don't have dozens of operands, and the predicate
>> is just supposed to check everything is the way it should be.
> I took arm/ldmstm.md as an inspiration. See attached machine description for 
> PRU that requires the increase. I omitted this machine-generated MD file from 
> my first patch set, but per comments will include it in v2.
> 
> PRU has a total of 32 32-bit registers with flexible subregister addressing. 
> The PRU GCC port represents the register file as 128 individual 8-bit 
> registers. Rationale: http://gcc.gnu.org/ml/gcc/2017-01/msg00217.html
> 
> Load/store instructions can load anywhere between 1 and 124 consecutive 8-bit 
> registers. The load/store-multiple patterns seem to require const_int_operand 
> offsets for each loaded register, hence the explosion of operands.
> 
> I make no distintion for class - patterns accept any GP register.
Right, but is that level of generality really all that useful?  Based on
what I know about the PRU I'd probably stick mostly to 32bit registers
and only expose the byte level addressibility when it's clearly a win,
particularly for bitfield insertions/extractions.  I probably wouldn't
expose operations which cross 32bit boundaries, except perhaps for
arithmetic through the carry.

I guess my point is I'd like to see a stronger justification for
exposing this much of the architecture before bumping up the maximum
operand limits.

jeff

Re: [RFC] New features for multilib control

[Jeff Law]

On 06/13/2018 07:56 AM, Matthew Fortune wrote:
> Hi,
> 
> This patch was developed as part of preparing ever more complex multilib
> combinations for the MIPS architecture and aims to solve several problems
> in this area. I've attempted to be quite verbose in the description, so
> that I can explain how I am using various terms as pretty much everyone
> has a different understanding (and I don't claim mine to be 'right'
> either).
> 
> The changes aim to:
> 
> 1) Eliminate the fallback multilib
> The fallback multilib (top level of 'lib') is often annoying because it is
> used for any combination of options that do not match a specific multilib.
> Quite often this default multilib is incompatible with the build options
> that end up linking against it, leading to bizarre link time messages that
> confuse ordinary users.
> 
> 2) Move the default multilib to a subfolder
> Having successfully eliminated the fallback multilib it is also true that
> it would eliminate the 'default' multilib as well. I.e. the library used
> when no relevant user options are supplied. Moving this library to a
> subfolder has two benefits. a) it still exists! and b) the location of
> this library becomes invariant irrespective of which options are
> build-time configured as default.
> 
> 3) Preserve/use invariant paths for multilib variants
> A simplistic multilib specification leads to a nested set of folders,
> where the top level is the left-most multilib directory and the bottom is
> the right most. Introducing a new axis of multilib configuration changes
> this path structure leading to the different library configurations to 
> move around. This is not in itself a problem, as the compiler driver can
> always locate the right path for any given build, but it does cause issues
> when doing configuration management of binary toolchains. When there are
> many different multilibs it is ideal to ship/install only the ones that
> are important and if the paths keep changing over time this process is
> complex and confusing. This issue is effectively solved by the
> MULTI_OSDIRNAMES feature but using it for both sysroot and compiler
> internal libraries is even better.
> 
> 4) Support un-released multilib configurations
> This one sounds weird but it is quite valuable. When an architecture has
> 70+ possible multilib variants but only 40 of them are currently known to
> be needed then only build and release 40 variants. However, if it turns
> out that another configuration becomes useful then it is often handy to
> just build the missing configuration and install it into the pre-existing
> release. So, the driver needs to know about all multilibs and their paths
> but the build process should only build a subset.
> 
> So, the solution...
> 
> Firstly, be verbose about the MULTILIB_OPTIONS needed for a target. Add
> in the default options as well as all the others that may, or could, ever
> be supported by the current compiler features. For MIPS supporting
> MIPS32r1 onwards it looks like this:
> 
> MULTILIB_OPTIONS = muclibc mips32/mips32r2/mips32r6/mips64/mips64r2/mips64r6
> mips16/mmicromips mabi=32/mabi=n32/mabi=64 EB/EL msoft-float mnan=2008
> 
> This does create an enormous matrix of possible configurations so this
> has to be trimmed to the valid set using MULTILIB_REQUIRED. Note that
> the valid set should include any that you may wish to support even if
> you don't want to build/release them. By having the default options in
> then this leads to having two copies of the 'default' multilib; one with
> the options implicitly set and one with them explicitly set.
> 
> Second, remove the multilib with the implicit default options. This
> equates to the '.' multilib entry. To do this use MULTILIB_EXCLUSIONS to
> remove the negated form of every MULTILIB_OPTION:
> 
> MULTILIB_EXCLUSIONS =
> !muclibc/!mips32/!mips32r2/!mips32r6/!mips64/!mips64r2/!mips64r6/!mips16/!mm
> icromips/!mabi=32/!mabi=n32/!mabi=64/!EB/!EL/!msoft-float/!mnan=2008
> 
> Third, set the MULTILIB_OSDIRNAMES to have an entry for every valid
> combination of options and use the '!' modifier. Honestly, I'm not sure
> how/why this works but this leads to both the internal library paths and
> sysroot paths using the OSDIRNAME instead of the nested tree of
> MULTILIB_DIRNAMES. Choose a path for each variant that you will never
> change again; I used an encoded form of the configuration for MIPS:
> 
> MULTILIB_OSDIRNAMES =
> mips32r6/mabi.32/EB/mnan.2008=!mips-r6-hard$(is_newlib)/lib
> 
> Fourth, deal with the fallout from the config-ml.in logic which handles
> the initial 'configure' of a library differently to all of the multilib
> configurations. The basic idea is that since the default multilib will now
> report that it belongs in a subdirectory then, when configuring the top
> level multilib, query the driver for the folder. Later when iterating
> through the multilib specs skip the one that matches the default
> configuration. Each configuration will be built 

Re: Warning about -Wmain for local variables

[Jeff Law]

On 05/30/2018 09:51 AM, Prathamesh Kulkarni wrote:
> On 30 May 2018 at 18:12, Jonathan Wakely  wrote:
>> On 30 May 2018 at 11:40, Prathamesh Kulkarni wrote:
>>> gcc with -Wmain warns for local variables named main.
>>>
>>> int foo()
>>> {
>>>   int main = 0;
>>>   return main;
>>> }
>>>
>>> a.c: In function ‘foo’:
>>> a.c:3:7: warning: ‘main’ is usually a function [-Wmain]
>>>int main = 1;
>>>^~~~
>>>
>>> Is this intended ? I assumed that the warning's intent was for
>>> diagnosing variable named main having only external linkage.
>> It was added more than 20 years ago by https://gcc.gnu.org/r13517 and
>> looks like it has always worked as it does now, without considering
>> linkage.
>>
>> Only warning for entities with external linkage seems reasonable to
>> me, but that would be for the C front-end or diagnostics maintainers
>> to decide.
> Thanks for the suggestions. I have attached (untested) patch that warns
> for Wmain if TREE_PUBLIC (decl) is true.
> Does it look OK ?
> 
> Thanks,
> Prathamesh
> 
> 
> wmain-1.txt
> 
> 
> 2018-05-30  Prathamesh Kulkarni  
> 
>   * c/c-decl.c (start_decl): Add check TREE_PUBLIC (decl) for -Wmain.
> 
> testsuite/
>   * gcc.dg/wmain.c: New.
After the usual testing, this is OK.

jeff

Re: [PATCH][GCC][mid-end] Correct subreg no-op handling for big-endian vec_select.

[Jeff Law]

On 06/19/2018 08:11 AM, Tamar Christina wrote:
> Hi All,
> 
> Previously GCC's no-op detection could would consider something a no-op even 
> when the
> mode change is not directly possible.  This caused subregs that shouldn't be 
> removed
> to be treated as a no-op and deleted.
> 
> Regtested on armeb-none-eabi and no regressions.
> Bootstrapped on arm-none-linux-gnueabihf and no issues.
> 
> Ok for trunk? and for backport to GCC 8?
> 
> Thanks,
> Tamar
> 
> gcc/
> 2018-06-19  Tamar Christina  
> 
>   PR target/84711
>   * rtlanal.c (set_noop_p): Constrain on mode change,
>   include hard-reg-set.h
> 
OK.  Though please include a testcase.  I believe you had
big-endian-subreg.c in the original target specific approach to fixing
this problem.  That'd be fine to re-use here.

jeff

Re: [patch] refine getenv_spec_function fallback value for undefined variable

[Jeff Law]

On 06/22/2018 10:23 AM, Olivier Hainque wrote:
> Hello,
> 
> getenv_spec_function features code to return a fake
> value for an undefined variable when we know that we
> shouldn't complain about the variable being undefined
> and that the variable value doesn't matter.
> 
> This code is there to prevent errors about undefined
> variables referenced in specs when we're processing for
> mere "--version" on the command line, for example.
> 
> The current code sets the value to the variable name.
> 
> We have a local configuration (for VxWorks, patch coming) where
> %:getenv is used at the beginning of a STARTFILE_PREFIX_SPEC,
> like:
> 
>   #define STARTFILE_PREFIX_SPEC "%:getenv(VSB_DIR /usr/lib/common)"
> 
> Now, for this spec we have a check that the value is an
> absolute path, and gcc --version for this configuration then
> complains with a message like:
> 
>i586-wrs-vxworks7-gcc: fatal error: system path 'VSB_DIR/usr/lib/common' 
> is not absolute
> 
> This patch fixes this glitch by simply prepending a '/' to
> the fake value returned by getenv_spec_function for acceptable
> undefined variables.
> 
> We have been using this in-house for months with gcc-7 on a wide
> range of targets.
> 
> Bootstrapped and regression tested with mainline on x86_64-linux.
> 
> Ok to commit ?
> 
> Thanks in advance,
> 
> With Kind Regards,
> 
> Olivier
> 
> 2018-06-22  Olivier Hainque  
> 
> * gcc.c (getenv_spec_function): Prepend '/' to value for allowed
> undefined variables.
> 
OK
jeff

Re: [PATCH 0/3][POPCOUNT]

[Jeff Law]

On 06/24/2018 08:41 PM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
> 
> Thanks for the comments.
> 
> On 23 June 2018 at 02:06, Jeff Law  wrote:
>> On 06/22/2018 03:11 AM, Kugan Vivekanandarajah wrote:
>>> When we set niter with maybe_zero, currently final_value_relacement
>>> will not happen due to expression_expensive_p not handling. Patch 1
>>> adds this.
>>>
>>> With that we have the following optimized gimple.
>>>
>>>[local count: 118111601]:
>>>   if (b_4(D) != 0)
>>> goto ; [89.00%]
>>>   else
>>> goto ; [11.00%]
>>>
>>>[local count: 105119324]:
>>>   _2 = (unsigned long) b_4(D);
>>>   _9 = __builtin_popcountl (_2);
>>>   c_3 = b_4(D) != 0 ? _9 : 1;
>>>
>>>[local count: 118111601]:
>>>   # c_12 = PHI 
>>>
>>> I assume that 1 in  b_4(D) != 0 ? _9 : 1; is OK (?) because when the
>>> latch execute zero times for b_4 == 0 means that the body will execute
>>> ones.
>> ISTM that DOM ought to have simplified the conditional, unless there's
>> some other way to get to bb3.  We know that b_4 is nonzero and thus c_3
>> must have the value _9.
> As of now, dom is not optimizing it. With the attached hack, it can be made 
> to.
Thanks.   It's not as much of a hack as you might think.

Right now there's two ways to get at the data we're looking for.  One is
to query the VRP engine like you've done.  The other is to query the
expression table which should have something like 1 = (b4 != 0) in it as
that expression holds on the 2->3 edge which dominates bb3.

One of the things I want to do this summer is integrate the VRP engine
queries better into DOM and stop relying on adding conditionals into the
expression table (which isn't as powerful and doesn't scale well).  So
your patch isn't a terrible hack.  It's just not the well integrated
solution I want to pull together :-)


I think it was just last year when I started wondering if we were
handling COND_EXPRs on the RHS of an assignment correctly, but it got
lost on my stack of TODO items.  It's good to have a testcase which
confirms my suspicion that we're not handling them as well as we should.

I've opened bz86339 to track this issue.

Jeff

Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)

[Martin Sebor]

On 06/27/2018 03:53 PM, Jeff Law wrote:

On 06/27/2018 09:27 AM, Jakub Jelinek wrote:

On Wed, Jun 27, 2018 at 09:17:07AM -0600, Jeff Law wrote:

About 115 tests fail due to incompatible declarations of
the built-in functions below (the number shows the number
of warnings for each functions):

428   abort
 58   exit
 36   memcpy
 17   memmove
 15   realloc
 14   cabs
  5   strncpy
  4   strcmp
  3   alloca
  2   rindex
  1   aligned_alloc

I'm supportive of this change.  Though I'm more worried about the
affects on the distros than I am on the testsuite (which I expected to
be in worse shape WRT this issue than your analysis indicates).


I'm mainly worried about configure tests, those will be hit hardest by
this and might result in silently turning off many features of the compiled
programs.

It's certainly a concern.  Sadly, it's a hard one to deal with because
we can't just throw code at it and see what complains.  Instead we end
up with packages that don't configure in the appropriate features.


I checked all GCC's config logs and although there are 543
instances of the -Wbuiltin-declaration-mismatch warning in
an x86_64-linux build, none of them is an error and
the number is the same as before the patch.

Martin



I think when Roland and I discussed this in the context of gold the
thing we sketched out was to build the distro, capturing the resultant
config.h, then rebuild with gold, capture the new config.h and compare.

We never actually tried that -- we didn't green light the gold
transition due to other reasons.

Just wandering around our own configury bits does show some of these
kinds of problems.  No idea if they'd manifest themselves in a visible
ways though.

Maybe it's a case where it's an opt-in argument in the immediate term
and we work with the autoconf folks to squash out as many problems as we
can and build out some kind of distro-like testing before flipping the
default.

jeff

Re: [patch] Do not leak location information during inlining (2nd try)

[Jeff Law]

On 06/27/2018 07:24 AM, Eric Botcazou wrote:
> Hi,
> 
> the Ada compiler uses small functions defined in its runtime to implement 
> various intrinsic operations and it always inlines them, even at -O0.  But it 
> doesn't want location information from the runtime files to appear in the 
> debug info so it puts DECL_IGNORED_P on these functions.  final.c already 
> knows how not to generate location information for DECL_IGNORED_P functions 
> when they are standalone but that's not the case for the inliner, i.e. it 
> leaks location information from these functions where they are inlined.
> 
> The attached patch is aimed at preventing this from happening by explicitly 
> forcing input_location on the inlined bodies in this case.
> 
> Tested (GCC and GDB) on x86-64/Linux, OK for the mainline?
> 
> 
> 2018-06-27  Eric Botcazou  
> 
>   * tree-inline.c (remap_gimple_stmt): Force input_location on the new
>   statement if id->reset_location is true.
>   (copy_edges_for_bb): Do not set goto_locus on the new edges if
>   id->reset_location is true.
>   (copy_phis_for_bb): Force input_location on the arguments if
>   id->reset_location is true.
>   (expand_call_inline): Set id->reset_location if DECL_IGNORED_P
>   is set on the function to be inlined.
>   * tree-inline.h (struct copy_body_data): Move remapping_type_depth and
>   prevent_decl_creation_for_types fields up and add reset_location field.
> 
> 
> 2018-06-27  Eric Botcazou  
> 
> * gnat.dg/debug15.adb: New test.
More references to input_location aren't ideal.  But I don't think
that's a strong enough reason to reject.  OK for the trunk.

jeff

Re: [PATCH] contrib: introduce Vim addon directory, add match.pd syntax plugin

[Jeff Law]

On 06/26/2018 02:12 PM, Alexander Monakov wrote:
> Hi,
> 
> This adds Vim syntax highlighting rules for match.pd and packages them 
> together
> with gcc-rtl.vim and gimple.vim, creating contrib/vim-gcc-dev subtree that can
> be installed as a common Vim plugin.
> 
> Thanks.
> Alexander
> 
>   * vim-gcc-dev/README: New file.
>   * vim-gcc-dev/ftdetect/gcc-dev.vim: New file.
>   * vim-gcc-dev/syntax/gcc-match.vim: New file.
>   * gimple.vim: Move under vim-gcc-dev/syntax/.
>   * gcc-rtl.vim: Likewise.
OK.
jeff

Re: [PATCH 01/11] Initial TI PRU GCC port

[Jeff Law]

On 06/23/2018 09:42 AM, Dimitar Dimitrov wrote:

>>
>> I've already asked about your copyright assignment status.  So you know,
>> we can't go forward with any nontrivial contributions until the
>> assignment is in place.
> Yes, FSF has my assignment since November 2016.
Great.  Thanks.




>> So it looks like you're supporting libgloss/newlib.  Does it work with
>> the current libgloss/newlib trunk?  I've had troubles over the last few
>> months with 16 bit targets.
> I have not detected issues with top-of-tree. But keep in mind that PRU is 8-
> bit only for the GCC internal representation. The port declares efficient 32-
> bit ops for SImode. From newlib's point of view, PRU is native 32-bit.
The issues are with targets that have 16 bit ints.  At least that's
that's my recollection.  They're not something I worry about too deeply
anymore, so I didn't dig into the details of what broke within newlib.

It sounds like you're lucky in that what you're exposing avoids these
recent breakages in newlib.

> 
> Some history here: http://gcc.gnu.org/ml/gcc/2017-01/msg00217.html
Thanks.  As Nathan mentioned, PRU is a little extreme in its register
handling.  There's always a tradeoff for what level of granularity to
expose on these oddball architectures.

Typically we have the register size match a natural word on the given
architecture and we don't try to allocate the sub-register objects
independently (ie, ah/al on x86 or something like the left/right
registers on the h8).

Given what little I know about the PRU, the actual operations on the
processor are 32 bits wide.  So I probably wouldn't have bothered
exposing byte level operations, except for byte loads/stores and
zero/sign extension from byte to 32bit words.  SImilarly for half-words.

Furthermore I would have restricted the byte and half-word operations to
the lowest covering sub-object.

But that'd just be my choice.  You're obviously allowed to do something
different.

>>
>>> diff --git a/gcc/common/config/pru/pru-common.c
>>> b/gcc/common/config/pru/pru-common.c new file mode 100644
>>> index 000..e87d70ce9ca
>>> --- /dev/null
>>> +++ b/gcc/common/config/pru/pru-common.c
>>
>> [ ... ]
>>
>>> @@ -0,0 +1,36 @@
>>> +
>>> +#undef TARGET_EXCEPT_UNWIND_INFO
>>> +#define TARGET_EXCEPT_UNWIND_INFO sjlj_except_unwind_info
>>
>> SJLJ exceptions?  Is there some reason you're not using dwarf2 unwind
>> info?  It may mean adding some notes in the prologue generation code,
>> but otherwise I'd expect it to "just work".
> I would like to avoid increasing memory footprint. I saw that AVR folks use 
> it, too. My understanding is that eh_frame data will have to be included for 
> each function when using dwarf2 unwind.
> 
> For reference, typical data memory size for PRU is 4kb.
Understood.  Of course one could argue that trying to do C++ in a 4kb
footprint is on the absurd side. :-)


>>> +
>>> +/* ABI variant for code generation.  */
>>> +enum pru_abi {
>>> +PRU_ABI_GNU,
>>> +PRU_ABI_TI
>>
>> Is there really any value in having two ABIs?  If there's another
>> toolchain out there it'd be best if we were just compatible with that
>> rather than defining a GNU ABI.  I guess it might be helpful if the TI
>> ABI is crippled enough that it's hard to run the testsuite..
> 
> TI ABI defines data pointers as 32-bit and function pointers as 16-bit. I 
> could not implement this reliably for the PRU GCC port. And it doesn't seem 
> to 
> be a good idea anyway:
>   http://gcc.gnu.org/ml/gcc/2012-04/msg00870.html
Ah.  Yea, we've never supported multiple pointer sizes like that.
While we do have special data segments on some architectures, that's
more about the ability to use short offsets from specific base pointers
rather than different sized pointers.

More recently we have added some limited address space support, but
again I don't think it's really a good match for this problem.


> 
> My GCC implementation for TI ABI does not support function pointers and large 
> return values. Hence I defined GNU ABI where those are supported, users can 
> enjoy full C language capabilities, and a decent testsuite coverage is 
> achieved.
ACK.  Thanks for explaining.

>>
>>> +
>>> +/* Say that the epilogue uses the return address register.  Note that
>>> +   in the case of sibcalls, the values "used by the epilogue" are
>>> +   considered live at the start of the called function.  */
>>> +#define EPILOGUE_USES(REGNO) (epilogue_completed &&  \
>>> + (((REGNO) == RA_REGNO)  \
>>> +  || (REGNO) == (RA_REGNO + 1)))
>>
>> Is this really needed?  If you properly describe the dataflow for your
>> epilogues I don't think you need this hack.
> Yes it is needed. I saw that nios2 port uses it, and I had no idea it is a 
> hack.
It looks like most ports are using EPILOGUE_USES these days by way of
the df infrastructure which went in a few years ago.  So I probably
shouldn't call it a hack anymore.  Don't worry about 

Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)

[Martin Sebor]

On 06/27/2018 12:44 PM, Eric Gallager wrote:

On 6/26/18, Martin Sebor  wrote:

With the exception of built-ins with the ellipsis (like sprintf),
GCC silently accepts declarations of built-in functions without
prototypes as well as calls to such functions with any numbers
or types of arguments, compatible or otherwise.  Calls with
arguments whose number and types match exactly those of
the built-in are considered by the middle-end for optimization.
Other calls (compatible or not, irrespective of whether their
number matches the number expected by the function) are then
made to the library functions.

Attached is a small fix to -Wbuiltin-declaration-mismatch to
have it diagnose built-in declarations without a prototype.
The warning is enabled by default so it causes a fair number
of tests to fail because of declarations like 'void abort();'
The breakdown of the built-ins behind the test failures is
below.

Before I take the time to clean up the test suite let me post
what I have in case going this route is not acceptable.  As
an alternative, I could try to avoid some of these warnings,
e.g., by diagnosing incompatible calls instead but I think
it's even less worthwhile for built-ins than trying to do
it for ordinary functions with -Wstrict-prototypes.  There
is, in my view, no justification today for standard functions
to be declared without a prototype.  (I could also make
the warning depend on language mode and -Wpedantic if that
were more preferable.)

Martin

About 115 tests fail due to incompatible declarations of
the built-in functions below (the number shows the number
of warnings for each functions):

428   abort
  58   exit
  36   memcpy
  17   memmove
  15   realloc
  14   cabs
   5   strncpy
   4   strcmp
   3   alloca
   2   rindex
   1   aligned_alloc



Could you do something to differentiate it a bit more from the
-Wshadow warning that is also touched in this patch? It'd be kind of
annoying to get warnings from both flags for the same code...


I don't think it's possible to get both warnings.  The block
with the -Wshadow warning returns before the one
-Wbuiltin-declaration-mismatch is entered.

Martin

Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)

[Martin Sebor]

I was hoping to avoid the complexity but I appreciate
the desire for a more permissive solution, at least for
some transitional period.

I've reworked the patch to avoid diagnosing 'void abort();'
(the only library built-in that takes no arguments).
Instead, calls that pass arguments to it are diagnosed.

While at it, I generalized the convert_arguments() function
to diagnose argument mismatches in calls to any built-in
declared without a prototype.  I think this is a useful
feature regardless because many such calls are not considered
for optimization even when they are safe.  But with it in
place, declarations of built-ins without a prototype could
continue to be silently accepted by default for a period and
only diagnosed with -Wextra until we are ready to turn on
the warnings by default.  (If that's thought necessary --
the patch as is doesn't do that.)

Since these changes involve factoring quite a bit of code into
a new function (with only very minor tweaks), to make review
easier, I attach two diffs: one with -w, and another full one.
The full diff also contains the cleanup of the failing tests.

Martin

On 06/27/2018 09:27 AM, Jakub Jelinek wrote:

On Wed, Jun 27, 2018 at 09:17:07AM -0600, Jeff Law wrote:

About 115 tests fail due to incompatible declarations of
the built-in functions below (the number shows the number
of warnings for each functions):

428   abort
 58   exit
 36   memcpy
 17   memmove
 15   realloc
 14   cabs
  5   strncpy
  4   strcmp
  3   alloca
  2   rindex
  1   aligned_alloc

I'm supportive of this change.  Though I'm more worried about the
affects on the distros than I am on the testsuite (which I expected to
be in worse shape WRT this issue than your analysis indicates).


I'm mainly worried about configure tests, those will be hit hardest by
this and might result in silently turning off many features of the compiled
programs.

I think
void abort ();
is very common and if people actually don't pass any arguments to abort, I
think warning by default about this is too much.

Jakub



PR c/83656 - missing -Wbuiltin-declaration-mismatch on declaration without 
prototype

gcc/c/ChangeLog:

PR c/83656
* c-decl.c (diagnose_mismatched_decls): Diagnose declarations of
built-in functions without a prototype.
* c-typeck.c (convert_argument): New function.
(convert_arguments): Factor code out into convert_argument.
Detect mismatches between built-in formal arguments in calls
to built-in without prototype.
(convert_for_assignment): Add argument.  Conditionally issue
warnings instead of errors for mismatches.

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index af16cfd..07beaa1 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -1886,8 +1886,9 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
 built-in.  No point in calling locate_old_decl here, it
 won't print anything.  */
  warning (OPT_Wbuiltin_declaration_mismatch,
-  "conflicting types for built-in function %q+D",
-  newdecl);
+  "conflicting types for built-in function %q+D; "
+  "expected %qT",
+  newdecl, oldtype);
  return false;
}
}
@@ -2021,17 +2022,35 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
 can't validate the argument list) the built-in definition is
 overridden, but optionally warn this was a bad choice of name.  */
   if (DECL_BUILT_IN (olddecl)
- && !C_DECL_DECLARED_BUILTIN (olddecl)
- && (!TREE_PUBLIC (newdecl)
+ && !C_DECL_DECLARED_BUILTIN (olddecl))
+   {
+ if (!TREE_PUBLIC (newdecl)
  || (DECL_INITIAL (newdecl)
- && !prototype_p (TREE_TYPE (newdecl)
+ && !prototype_p (TREE_TYPE (newdecl
{
- warning (OPT_Wshadow, "declaration of %q+D shadows "
+ warning_at (DECL_SOURCE_LOCATION (newdecl),
+ OPT_Wshadow, "declaration of %qD shadows "
  "a built-in function", newdecl);
  /* Discard the old built-in function.  */
  return false;
}
 
+ if (!prototype_p (TREE_TYPE (newdecl)))
+   {
+ /* Set for built-ins that take no arguments.  */
+ bool func_void_args = false;
+ if (tree at = TYPE_ARG_TYPES (oldtype))
+   func_void_args = VOID_TYPE_P (TREE_VALUE (at));
+
+ if (extra_warnings || !func_void_args)
+   warning_at (DECL_SOURCE_LOCATION (newdecl),
+   OPT_Wbuiltin_declaration_mismatch,
+   "declaration of built-in function %qD without "
+   "a prototype; expected %qT",
+   newdecl, TREE_TYPE (olddecl));
+   }
+   }
+
   if 

Re: [C++ Patch] More location fixes to grokdeclarator

[David Malcolm]

On Wed, 2018-06-27 at 21:13 -0400, David Malcolm wrote:
> On Thu, 2018-06-28 at 02:28 +0200, Paolo Carlini wrote:
> > Hi,
> > 
> > On 28/06/2018 01:31, Jason Merrill wrote:
> > > 
> > > > +/* Returns the smallest location.  */
> > > 
> > > This should probably say "...that is not UNKNOWN_LOCATION."
> > 
> > I agree.
> > > Actually, the places you use min_location would seem to work fine
> > > with
> > > max_location as well.  What are your criteria for choosing one or
> > > the
> > > other?
> > 
> > I should have explained that in better detail. I see two different 
> > circumstances: either we have error messages where we say something
> > like 
> > "cannot be both":
> > 
> > - error ("member %qD cannot be declared both % "
> > -"and %", dname);
> > + error_at (max_location (declspecs-
> > >locations[ds_virtual],
> > + declspecs-
> > > locations[ds_storage_class]),
> > 
> > +   "member %qD cannot be declared both
> > %
> > "
> > +   "and %", dname);
> > 
> > where, in my opinion, we want to point to the max_location, we want
> > to point to where the contradiction shows up in the code. Or, we
> > have
> > errors like:
> > 
> > - error ("storage class specified for template parameter
> > %qs", name);
> > + error_at (min_location (declspecs->locations[ds_thread],
> > + declspecs-
> > > locations[ds_storage_class]),
> > 
> > +   "storage class specified for template
> > parameter
> > %qs",
> > +   name);
> > 
> > where ill-formed code has either one or two such specifiers (that
> > is
> > __thread and/or static) but even one would wrong, thus we want to
> > point to the first one, thus min_location (this is in fact a
> > variant
> > of the reasoning behind smallest_type_quals_location).
> > 
> > Did I explain myself clearly enough? If we are going for something
> > simple, I would suggest uniformly using min_location, not
> > max_location.
> 
> If I'm following you right, the idea is that gcc should complain
> because two different things in the user's source code contradict
> each
> other.
> 
> In such circumstances, I think we ought to try to print *both*
> locations, so that we're showing, rather than just telling.

Or to put in another way, if two things in the user's source contradict
each other, we should show the user both.  The user is going to have to
decide to delete one (or both) of them, and we don't know which one,
but at least by showing both it helps him/her take their next action.

> So the user experience might be something like:
> 
> test.cc:42:1: error: member 'bar::foo' cannot be declared both
> 'virtual' and 'static'
>  static virtual foo ();
>  ^~ ~~~
> 
> It's possible to send two locations through one diagnostic using
> rich_location, via e.g.:
> 
>gcc_rich_location richloc (primary_location);
>richloc.add_range (secondary_location, false);
>error_at (, "member %qD etc etc"", .../* etc*/);
> 
> For this case, I don't think it matters which one is primary and
> which
> is secondary (it merely determines the file:line:column in the
> preliminary message of the diagnostic).
> 
> Another approach would be to use two diagnostics, for something like:
> 
> test.cc:42:8: error: member 'foo' cannot be declared both
> 'virtual'...
>  static virtual foo ();
> ^~~
> test.cc:42:1: note: ...and 'static'
>  static virtual foo ();
>  ^~
>  
> but given that in this case the two things are likely to be close
> together in the user's source, I prefer the "two locations in one
> diagnostic" approach.
> 
> Hope this is constructive
> Dave
> 
> > By the way, I think I found examples of locations following both
> > the
> > patterns above in clang and icc too.
> > 
> > Thanks,
> > Paolo.
> > 

Re: [C++ Patch] More location fixes to grokdeclarator

[David Malcolm]

On Thu, 2018-06-28 at 02:28 +0200, Paolo Carlini wrote:
> Hi,
> 
> On 28/06/2018 01:31, Jason Merrill wrote:
> > 
> > > +/* Returns the smallest location.  */
> > 
> > This should probably say "...that is not UNKNOWN_LOCATION."
> 
> I agree.
> > Actually, the places you use min_location would seem to work fine
> > with
> > max_location as well.  What are your criteria for choosing one or
> > the
> > other?
> 
> I should have explained that in better detail. I see two different 
> circumstances: either we have error messages where we say something
> like 
> "cannot be both":
> 
> -   error ("member %qD cannot be declared both % "
> -  "and %", dname);
> +   error_at (max_location (declspecs->locations[ds_virtual],
> +   declspecs-
> >locations[ds_storage_class]),
> + "member %qD cannot be declared both %
> "
> + "and %", dname);
> 
> where, in my opinion, we want to point to the max_location, we want
> to point to where the contradiction shows up in the code. Or, we have
> errors like:
> 
> -   error ("storage class specified for template parameter
> %qs", name);
> +   error_at (min_location (declspecs->locations[ds_thread],
> +   declspecs-
> >locations[ds_storage_class]),
> + "storage class specified for template parameter
> %qs",
> + name);
> 
> where ill-formed code has either one or two such specifiers (that is
> __thread and/or static) but even one would wrong, thus we want to
> point to the first one, thus min_location (this is in fact a variant
> of the reasoning behind smallest_type_quals_location).
> 
> Did I explain myself clearly enough? If we are going for something
> simple, I would suggest uniformly using min_location, not
> max_location.

If I'm following you right, the idea is that gcc should complain
because two different things in the user's source code contradict each
other.

In such circumstances, I think we ought to try to print *both*
locations, so that we're showing, rather than just telling.

So the user experience might be something like:

test.cc:42:1: error: member 'bar::foo' cannot be declared both 'virtual' and 
'static'
 static virtual foo ();
 ^~ ~~~

It's possible to send two locations through one diagnostic using
rich_location, via e.g.:

   gcc_rich_location richloc (primary_location);
   richloc.add_range (secondary_location, false);
   error_at (, "member %qD etc etc"", .../* etc*/);

For this case, I don't think it matters which one is primary and which
is secondary (it merely determines the file:line:column in the
preliminary message of the diagnostic).

Another approach would be to use two diagnostics, for something like:

test.cc:42:8: error: member 'foo' cannot be declared both 'virtual'...
 static virtual foo ();
^~~
test.cc:42:1: note: ...and 'static'
 static virtual foo ();
 ^~
 
but given that in this case the two things are likely to be close
together in the user's source, I prefer the "two locations in one
diagnostic" approach.

Hope this is constructive
Dave

> By the way, I think I found examples of locations following both the
> patterns above in clang and icc too.
> 
> Thanks,
> Paolo.
> 

Re: [C++ Patch] More location fixes to grokdeclarator

[Paolo Carlini]

Hi,

On 28/06/2018 01:31, Jason Merrill wrote:



+/* Returns the smallest location.  */

This should probably say "...that is not UNKNOWN_LOCATION."

I agree.

Actually, the places you use min_location would seem to work fine with
max_location as well.  What are your criteria for choosing one or the
other?
I should have explained that in better detail. I see two different 
circumstances: either we have error messages where we say something like 
"cannot be both":


- error ("member %qD cannot be declared both % "
-"and %", dname);
+ error_at (max_location (declspecs->locations[ds_virtual],
+ declspecs->locations[ds_storage_class]),
+   "member %qD cannot be declared both % "
+   "and %", dname);

where, in my opinion, we want to point to the max_location, we want to point to 
where the contradiction shows up in the code. Or, we have errors like:

- error ("storage class specified for template parameter %qs", name);
+ error_at (min_location (declspecs->locations[ds_thread],
+ declspecs->locations[ds_storage_class]),
+   "storage class specified for template parameter %qs",
+   name);

where ill-formed code has either one or two such specifiers (that is __thread 
and/or static) but even one would wrong, thus we want to point to the first 
one, thus min_location (this is in fact a variant of the reasoning behind 
smallest_type_quals_location).

Did I explain myself clearly enough? If we are going for something simple, I 
would suggest uniformly using min_location, not max_location.

By the way, I think I found examples of locations following both the patterns 
above in clang and icc too.

Thanks,
Paolo.

[ABSU_EXPR] Add some of the missing patterns in match,pd

[Kugan Vivekanandarajah]

Hi,

This patch adds some of the missing patterns in match.pd for ABSU_EXPR.

Bootstrap and regression testing on x86_64-linux-gnu. Is this OK if no
regressions.

Thanks,
Kugan

gcc/ChangeLog:

2018-06-28  Kugan Vivekanandarajah  

* match.pd (absu(x)*absu(x) -> x*x): Handle.
(absu(absu(X)) -> absu(X)): Likewise.
(absu(-X) -> absu(X)): Likewise.
(absu(X)  where X is nonnegative -> X): Likewise.
From 374ee7928039c16cb091bd02d5efd4c493aab86e Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Mon, 18 Jun 2018 10:51:06 +1000
Subject: [PATCH] add absu patterns

Change-Id: Ied504be83f00041a6c815d23e16a394b71445f27
---
 gcc/match.pd | 37 -
 1 file changed, 24 insertions(+), 13 deletions(-)

diff --git a/gcc/match.pd b/gcc/match.pd
index c1e0963..a356a92 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -571,10 +571,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(copysigns (op @0) @1)
(copysigns @0 @1
 
-/* abs(x)*abs(x) -> x*x.  Should be valid for all types.  */
-(simplify
- (mult (abs@1 @0) @1)
- (mult @0 @0))
+/* abs(x)*abs(x) -> x*x.  Should be valid for all types.
+   also for absu(x)*absu(x) -> x*x.  */
+(for op (abs absu)
+ (simplify
+  (mult (op@1 @0) @1)
+  (mult @0 @0)))
 
 /* cos(copysign(x, y)) -> cos(x).  Similarly for cosh.  */
 (for coss (COS COSH)
@@ -1013,15 +1015,24 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   && tree_nop_conversion_p (type, TREE_TYPE (@2)))
   (bit_xor (convert @1) (convert @2
 
-(simplify
- (abs (abs@1 @0))
- @1)
-(simplify
- (abs (negate @0))
- (abs @0))
-(simplify
- (abs tree_expr_nonnegative_p@0)
- @0)
+/* Convert abs (abs (X)) into abs (X).
+   also absu (absu (X)) into absu (X).  */
+(for op (abs absu)
+ (simplify
+  (op (op@1 @0))
+  @1))
+
+/* Convert abs[u] (-X) -> abs[u] (X).  */
+(for op (abs absu)
+ (simplify
+  (op (negate @0))
+  (op @0)))
+
+/* Convert abs[u] (X)  where X is nonnegative -> (X).  */
+(for op (abs absu)
+ (simplify
+  (op tree_expr_nonnegative_p@0)
+  @0))
 
 /* A few cases of fold-const.c negate_expr_p predicate.  */
 (match negate_expr_p
-- 
2.7.4

Re: C++ PATCH for c++/57891, narrowing conversions in non-type template arguments

[Jason Merrill]

On Wed, Jun 27, 2018 at 12:53 PM, Marek Polacek  wrote:
> This PR complains about us accepting invalid code like
>
>   template struct A {};
>   A<-1> a;
>
> Where we should detect the narrowing: [temp.arg.nontype] says
> "A template-argument for a non-type template-parameter shall be a converted
> constant expression ([expr.const]) of the type of the template-parameter."
> and a converted constant expression can contain only
> - integral conversions other than narrowing conversions,
> - [...]."
> It spurred e.g.
> 
> and has >=3 dups so it has some visibility.
>
> I think build_converted_constant_expr needs to set check_narrowing.
> check_narrowing also always mentions that it's in { } but that is no longer
> true; in the future it will also apply to <=>.  We'd probably have to add a 
> new
> flag to struct conversion if wanted to distinguish between these.
>
> This does not yet fix detecting narrowing in function templates (78244).
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-06-27  Marek Polacek  
>
> PR c++/57891
> * call.c (build_converted_constant_expr): Set check_narrowing.
> * decl.c (compute_array_index_type): Add warning sentinel.  Use
> input_location.
> * pt.c (convert_nontype_argument): Return NULL_TREE if any errors
> were reported.
> * typeck2.c (check_narrowing): Don't mention { } in diagnostic.
>
> * g++.dg/cpp0x/Wnarrowing6.C: New test.
> * g++.dg/cpp0x/Wnarrowing7.C: New test.
> * g++.dg/cpp0x/Wnarrowing8.C: New test.
> * g++.dg/cpp0x/constexpr-data2.C: Add dg-error.
> * g++.dg/init/new43.C: Adjust dg-error.
> * g++.dg/other/fold1.C: Likewise.
> * g++.dg/parse/array-size2.C: Likewise.
> * g++.dg/other/vrp1.C: Add dg-error.
> * g++.dg/template/char1.C: Likewise.
> * g++.dg/ext/builtin12.C: Likewise.
> * g++.dg/template/dependent-name3.C: Adjust dg-error.
>
> diff --git gcc/cp/call.c gcc/cp/call.c
> index 209c1fd2f0e..956c7b149dc 100644
> --- gcc/cp/call.c
> +++ gcc/cp/call.c
> @@ -4152,7 +4152,10 @@ build_converted_constant_expr (tree type, tree expr, 
> tsubst_flags_t complain)
>  }
>
>if (conv)
> -expr = convert_like (conv, expr, complain);
> +{
> +  conv->check_narrowing = !processing_template_decl;

Why !processing_template_decl?  This needs a comment.

> +  expr = convert_like (conv, expr, complain);
> +}
>else
>  expr = error_mark_node;
>
> diff --git gcc/cp/pt.c gcc/cp/pt.c
> index 3780f3492aa..12d1a1e1cd3 100644
> --- gcc/cp/pt.c
> +++ gcc/cp/pt.c
> @@ -6669,9 +6669,10 @@ convert_nontype_argument (tree type, tree expr, 
> tsubst_flags_t complain)
>   /* C++17: A template-argument for a non-type template-parameter 
> shall
>  be a converted constant expression (8.20) of the type of the
>  template-parameter.  */
> + int errs = errorcount;
>   expr = build_converted_constant_expr (type, expr, complain);
>   if (expr == error_mark_node)
> -   return error_mark_node;
> +   return errorcount > errs ? NULL_TREE : error_mark_node;

I suspect that what you want here is to check (complain & tf_error)
rather than errorcount.  Otherwise it needs a comment.

Jason

Re: [PATCH, rs6000, C/C++] Fix PR target/86324: divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble

[Peter Bergner]

On 6/27/18 4:35 PM, Segher Boessenkool wrote:
>> +DEFHOOK
>> +(translate_mode_attribute,
>> + "Define this hook if the port should translate machine_mode @var{mode}\n\
>> +to another mode.  For example, rs6000's @code{KFmode}, when it is the 
>> same\n\
>> +as @code{TFmode}.\n\
>> +\n\
>> +The default version of the hook returns that mode that was passed in.",
>> + machine_mode, (machine_mode mode),
>> + default_translate_mode_attribute)
> 
> It isn't clear here when this hook is called.  Is the idea to use it
> everywhere where modes are created, or only where it is used now (the arg
> to a "mode" attribute)?  Probably the latter, but it's not really clear
> from the text.

The latter and good idea.  How about this wording instead?

Peter

Index: gcc/target.def
===
--- gcc/target.def  (revision 262159)
+++ gcc/target.def  (working copy)
@@ -3310,6 +3310,16 @@ constants can be done inline.  The funct
  HOST_WIDE_INT, (const_tree constant, HOST_WIDE_INT basic_align),
  default_constant_alignment)

+DEFHOOK
+(translate_mode_attribute,
+ "Define this hook if during mode attribute processing, the port should\n\
+translate machine_mode @var{mode} to another mode.  For example, rs6000's\n\
+@code{KFmode}, when it is the same as @code{TFmode}.\n\
+\n\
+The default version of the hook returns that mode that was passed in.",
+ machine_mode, (machine_mode mode),
+ default_translate_mode_attribute)
+
 /* True if MODE is valid for the target.  By "valid", we mean able to
be manipulated in non-trivial ways.  In particular, this means all
the arithmetic is supported.  */

Re: [C++ Patch] More location fixes to grokdeclarator

[Jason Merrill]

On Wed, Jun 27, 2018 at 5:11 AM, Paolo Carlini  wrote:
> Hi David,
>
> On 27/06/2018 01:52, David Malcolm wrote:
>>
>> On Tue, 2018-06-26 at 01:44 +0200, Paolo Carlini wrote:
>>>
>>> Hi,
>>>
>>> this includes straightforward tweaks to check_concept_fn and quite a
>>> bit
>>> of additional work on grokdeclarator: most of it is also rather
>>> straightforward. In a few places there is the subtlety that we want
>>> to
>>> handle together ds_storage_class and ds_thread, whichever location
>>> is
>>> the smallest but != UNKNOWN_LOCATION (UNKNWON_LOCATION meaning that
>>> the
>>> issue is with the other one) or use the biggest location when say
>>> ds_virtual and ds_storage_class conflict, because - I believe - we
>>> want
>>> to point to the place where we give up. Thus I added the
>>> min_location
>>> and max_location helpers.
>>
>> Note that directly comparing location_t values can be problematic: (one
>> value might be an ad-hoc location, and the other not; one might be a
>> macro expansion, etc).
>>
>> You might want to use linemap_compare_locations or
>> linemap_location_before_p for this.
>
> Thanks David, I was not aware of this issue. In the below I amended the new
> functions and the existing smallest_type_quals_location (which I wrote a
> while ago) to use linemap_location_before_p.

> +/* Returns the smallest location.  */

This should probably say "...that is not UNKNOWN_LOCATION."

Actually, the places you use min_location would seem to work fine with
max_location as well.  What are your criteria for choosing one or the
other?

Jason

Re: [PATCH] Adjust subprogram DIE re-usal

[Jason Merrill]

On Tue, Jun 26, 2018 at 8:43 AM, Richard Biener  wrote:
>
> A patch from Honza not LTO streaming DECL_ORIGINAL_TYPE ends up
> ICEing during LTO bootstrap because we end up not re-using the
> DIE we create late during LTRANS for a subprogram because its
> parent is a namespace rather than a CU DIE (or a module).
>
> I'm wondering of the general reason why we enforce (inconsistently)
> "We always want the DIE for this function that has the *_pc attributes to
> be under comp_unit_die so the debugger can find it."
> We indeed generate a specification DIE rooted at the CU in addition to the
> declaration DIE inside the namespace for sth as simple as
>
> namespace Foo { void foo () {} }

The reason was to make it easier for debuggers to collect function
definitions by scanning the top-level DIEs.  I don't know how
useful/important that is to actual debuggers nowadays, since there are
various accelerated lookup tables as well.

> anyhow - the comment also says "We also need to do this [re-use the DIE]
> for abstract instances of inlines, since the spec requires the out-of-line
> copy to have the same parent.".  Not sure what condition this part of
> the comment applies to.

I think it's saying that we shouldn't re-use an in-class declaration
die for the abstract instance of an inline, just like we shouldn't
re-use it for a non-inline definition.

Incidentally, the same parent was only required by DWARF 2; DWARF 3+
say it's typical but not required.

> So my fix is to move the || get_AT (old_die, DW_AT_abstract_origin)
> check I added for early LTO debug to a global override - forcing
> DIE re-use for any DIE with an abstract origin set.  That is, all
> concrete instances are fine where they are.  That also avoids
> double-indirection DW_AT_specification -> DW_AT_abstract_origin -> DIE.
>
> But as said, I wonder about the overall condition, esp. the
> DW_TAG_module special-casing (but not at the same time
> special-casing DW_TAG_namespace or DW_TAG_partial_unit).

Hmm, the DW_TAG_module check seems to have come in with the
early-debug merge.  I don't know what the rationale was for that; it
certainly does weaken the case for treating CU scope specially.

As for DW_TAG_partial_unit, probably the is_cu_die check should change
to is_unit_die.

> LTO bootstrap is in progress on x86_64-unknown-linux-gnu.
>
> OK if that succeeds?

OK.

Jason

Re: [PATCH v3] Change default to -fno-math-errno

[Joseph Myers]

On Wed, 27 Jun 2018, Wilco Dijkstra wrote:

> Joseph Myers wrote:
> > On Tue, 26 Jun 2018, Wilco Dijkstra wrote:
> 
> > > That looks incorrect indeed but that's mostly a problem with -fmath-errno 
> > > as it
> > > would result in GCC assuming the function is const/pure when in fact it 
> > > isn't.
> > > Does ATTR_MATHFN_FPROUNDING imply that errno is dead after the call?
> >
> > No, it implies a pure function, so the previous errno value is still live 
> > after the call.
> 
> OK, so given GLIBC math functions may set errno anyway (irrespectively of the
> math-errno setting used), those 2 settings are not sufficient. Ideally you'd 
> need
> to model GLIBC style errno as may or may not be set (still pure since it 
> doesn't
> affect global state but not assuming errno is live afterwards). But perhaps it
> doesn't matter since this has been incorrect for years now...

Well, in some cases I think it can be treated as pure with 
-fno-math-errno, because that option implies functions may or may not set 
errno.  So (in the absence of spurious errno settings from libm functions 
not encountering errors), if the compiler reuses an errno value from 
before a libm function call because the function was marked as pure, 
that's equivalent to the function call not in fact setting errno.  The 
trouble is that (a) generating a read of errno after the call when the 
actual access in the abstract machine was before the call would be bad if 
that call in fact sets errno, and (b) each execution of a call in the 
abstract machine should either execute as if it set errno, or execute as 
if it did not set errno, and optimizations might not preserve that 
property.

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

[PATCH, rs6000] Add missing builtin test cases

[Carl Love]

GCC Maintainers:

The following patch adds missing test cases for
vec_extract_fp32_from_shortl(), vec_extract_fp32_from_shorth(), and
vec_extract().  

The patch has been run on:

  powerpc64le-unknown-linux-gnu (Power 8 LE)
  powerpc64le-unknown-linux-gnu (Power 9 LE)

without regressions.  

Please let me know if the following patch is acceptable.  Thanks.

  Carl Love

-

gcc/testsuite/ChangeLog:

2018-06-27  Carl Love  

* gcc.target/p9-extract-1.c: Add test case.
* gcc.target/builtins-3-p9-runnable.c: Add test case to match
name in ABI.
---
 .../gcc.target/powerpc/builtins-3-p9-runnable.c| 42 ++
 gcc/testsuite/gcc.target/powerpc/p9-extract-1.c|  8 +
 2 files changed, 50 insertions(+)

diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-3-p9-runnable.c 
b/gcc/testsuite/gcc.target/powerpc/builtins-3-p9-runnable.c
index 3197a50..35a81a7 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-3-p9-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-3-p9-runnable.c
@@ -30,6 +30,48 @@ int main() {
printf ("0B001, 
0B10110100};\n\n");
 #endif
 
+   /* The ABI lists the builtins as:
+
+vec_extract_fp32_from_shorth()
+vec_extract_fp32_from_shortl()
+
+  GCC will also accept and map the builtin names
+
+vec_extract_fp_from_shorth()
+vec_extract_fp_from_shortl()
+
+  to the same builtins internally.  For completeness,
+  test both builtin function names.  */
+
+   vfexpt = (vector float){1.0, -2.0, 0.0, 8.5};
+   vfr = vec_extract_fp32_from_shorth(vusha);
+
+#ifdef DEBUG
+   printf ("vec_extract_fp32_from_shorth\n");
+   for (i=0; i<4; i++)
+ printf("result[%d] = %f; expected[%d] = %f\n",
+   i, vfr[i], i, vfexpt[i]);
+#endif
+
+   for (i=0; i<4; i++) {
+  if (vfr[i] != vfexpt[i])
+ abort();
+   }
+
+   vfexpt = (vector float){1.5, 0.5, 1.25, -0.25};
+   vfr = vec_extract_fp32_from_shortl(vusha);
+
+#ifdef DEBUG
+   printf ("\nvec_extract_fp32_from_shortl\n");
+   for (i=0; i<4; i++)
+ printf("result[%d] = %f; expected[%d] = %f\n",
+   i, vfr[i], i, vfexpt[i]);
+#endif
+
+for (i=0; i<4; i++) {
+  if (vfr[i] != vfexpt[i])
+ abort();
+   }
vfexpt = (vector float){1.0, -2.0, 0.0, 8.5};
vfr = vec_extract_fp_from_shorth(vusha);
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c 
b/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
index ab9e766..203f5bf 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
@@ -122,6 +122,14 @@ extract_bool_int_0 (vector bool int a)
   return b;
 }
 
+unsigned short int
+extract_bool_short_int_0 (vector bool short int a)
+{
+  int c = 0;
+  unsigned short int b = vec_extract (a, c);
+  return b;
+}
+
 /* { dg-final { scan-assembler "vextub\[lr\]x " } } */
 /* { dg-final { scan-assembler "vextuh\[lr\]x " } } */
 /* { dg-final { scan-assembler "vextuw\[lr\]x " } } */
-- 
2.7.4

Re: [PATCH v3] Change default to -fno-math-errno

[Wilco Dijkstra]

Joseph Myers wrote:
> On Tue, 26 Jun 2018, Wilco Dijkstra wrote:

> > That looks incorrect indeed but that's mostly a problem with -fmath-errno 
> > as it
> > would result in GCC assuming the function is const/pure when in fact it 
> > isn't.
> > Does ATTR_MATHFN_FPROUNDING imply that errno is dead after the call?
>
> No, it implies a pure function, so the previous errno value is still live 
> after the call.

OK, so given GLIBC math functions may set errno anyway (irrespectively of the
math-errno setting used), those 2 settings are not sufficient. Ideally you'd 
need
to model GLIBC style errno as may or may not be set (still pure since it doesn't
affect global state but not assuming errno is live afterwards). But perhaps it
doesn't matter since this has been incorrect for years now...

Wilco

[PATCH, committed] Convert pdp11 back end to CCmode

[Paul Koning]

This change converts the pdp11 back end to use CCmode rather than cc0.  It is 
functional and the testsuite compile sections runs at least as well as before.

There is additional work left to be done; for example, the compare elimination 
pass, which this target uses, does not know how to deal with a machine that has 
two condition code registers.

Committed.

paul

ChangeLog:

2018-06-27  Paul Koning  

* common/config/pdp11/pdp11-common.c (pdp11_handle_option): Handle
mutually exclusive options.
* config/pdp11/constraints.md (h): New constraint.
(O): Update definition to match shift code generation.
(D): New constraint.
* config/pdp11/pdp11-modes.def (CCNZ): Define mode.
(CCFP): Remove.
* config/pdp11/pdp11-protos.h (int_no_side_effect_operand): New
function.
(output_jump): Change arguments.
(pdp11_fixed_cc_regs): New function.
(pdp11_cc_mode): Ditto.
(pdp11_expand_shift): Ditto.
(pdp11_assemble_shift): Ditto.
(pdp11_small_shift): Ditto.
(pdp11_branch_cost): Remove.
* config/pdp11/pdp11.c (pdp11_assemble_integer): Remove comments
from output.
(pdp11_register_move_cost): Update for CC registers.
(pdp11_rtx_costs): Add case for LSHIFTRT.
(pdp11_output_jump): Add CCNZ mode conditional branches.
(notice_update_cc_on_set): Remove.
(pdp11_cc_mode): New function.
(simple_memory_operand): Correct pre/post decrement case.
(no_side_effect_operand): New function.
(pdp11_regno_reg_class): Add CC_REGS class.
(pdp11_fixed_cc_regs): New function.
(pdp11_small_shift): New function.
(pdp11_expand_shift): New function to expand shift insns.
(pdp11_assemble_shift): New function to output shifts.
(pdp11_branch_cost): Remove.
(pdp11_modes_tieable_p): Make QI/HI modes tieable.
* config/pdp11/pdp11.h (SIZE_TYPE): Ensure 16-bit type.
(WCHAR_TYPE): Ditto.
(PTRDIFF_TYPE): Ditto.
(ADJUST_INSN_LENGTH): New macro.
(FIXED_REGISTERS): Add CC registers.
(CALL_USED_REGISTERS): Ditto.
(reg_class): Ditto.
(REG_CLASS_NAMES): Ditto.
(REG_CLASS_CONTENTS): Ditto.
(SELECT_CC_MODE): Use new function.
(TARGET_FLAGS_REGNUM): New macro.
(TARGET_FIXED_CONDITION_CODE_REGS): Ditto.
(cc0_reg_rtx): Remove.
(CC_STATUS_MDEP): Remove.
(CC_STATUS_MDEFP_INIT): Remove.
(CC_IN_FPU): Remove.
(NOTICE_UPDATE_CC): Remove.
(REGISTER_NAMES): Add CC registers.
(BRANCH_COST): Change to constant 1.
* config/pdp11/pdp11.md: Rewrite for CCmode condition code
handling.
* config/pdp11/pdp11.opt (mbcopy): Remove.
(mbcopy-builtin): Remove.
(mbranch-cheap): Remove.
(mbranch-expensive): Remove.
* config/pdp11/predicates.md (expand_shift_operand): Update to
match shift code generation.
(ccnz_operator): New predicate.
* doc/invoke.texi (PDP-11 Options): Remove deleted options
-mbcopy, -mbcopy-builtin, -mbranch-cheap, -mbranch-expensive.
Remove non-existent option -mabshi, -mno-abshi.  Document mutually
exclusive options.
* doc/md.texi (PDP-11): Document new D and h constraints.  Update
description of O constraint.

Index: common/config/pdp11/pdp11-common.c
===
--- common/config/pdp11/pdp11-common.c  (revision 262195)
+++ common/config/pdp11/pdp11-common.c  (working copy)
@@ -39,9 +39,27 @@ pdp11_handle_option (struct gcc_options *opts,
   switch (code)
 {
 case OPT_m10:
-  opts->x_target_flags &= ~(MASK_40 | MASK_45);
+  opts->x_target_flags &= ~(MASK_40 | MASK_45 | MASK_FPU | MASK_AC0 | 
MASK_SPLIT);
   return true;
 
+case OPT_m40:
+  opts->x_target_flags &= ~(MASK_45 | MASK_FPU | MASK_AC0 | MASK_SPLIT);
+  return true;
+
+case OPT_mfpu:
+  opts->x_target_flags &= ~MASK_40;
+  opts->x_target_flags |= MASK_45;
+  return true;
+  
+case OPT_msoft_float:
+  opts->x_target_flags &= ~MASK_AC0;
+  return true;
+
+case OPT_msplit:
+  opts->x_target_flags &= ~MASK_40;
+  opts->x_target_flags |= MASK_45;
+  return true;
+  
 default:
   return true;
 }
Index: config/pdp11/constraints.md
===
--- config/pdp11/constraints.md (revision 262195)
+++ config/pdp11/constraints.md (working copy)
@@ -18,11 +18,14 @@
 ;; along with GCC; see the file COPYING3.  If not see
 ;; .
 
+(define_register_constraint "a" "LOAD_FPU_REGS"
+  "FPU register that can be directly loaded from memory")
+
 (define_register_constraint "f" "FPU_REGS"
   "Any FPU register")
 
-(define_register_constraint "a" "LOAD_FPU_REGS"
-  "FPU register 

Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)

[Jeff Law]

On 06/27/2018 09:27 AM, Jakub Jelinek wrote:
> On Wed, Jun 27, 2018 at 09:17:07AM -0600, Jeff Law wrote:
>>> About 115 tests fail due to incompatible declarations of
>>> the built-in functions below (the number shows the number
>>> of warnings for each functions):
>>>
>>> 428   abort
>>>  58   exit
>>>  36   memcpy
>>>  17   memmove
>>>  15   realloc
>>>  14   cabs
>>>   5   strncpy
>>>   4   strcmp
>>>   3   alloca
>>>   2   rindex
>>>   1   aligned_alloc
>> I'm supportive of this change.  Though I'm more worried about the
>> affects on the distros than I am on the testsuite (which I expected to
>> be in worse shape WRT this issue than your analysis indicates).
> 
> I'm mainly worried about configure tests, those will be hit hardest by
> this and might result in silently turning off many features of the compiled
> programs.
It's certainly a concern.  Sadly, it's a hard one to deal with because
we can't just throw code at it and see what complains.  Instead we end
up with packages that don't configure in the appropriate features.

I think when Roland and I discussed this in the context of gold the
thing we sketched out was to build the distro, capturing the resultant
config.h, then rebuild with gold, capture the new config.h and compare.

We never actually tried that -- we didn't green light the gold
transition due to other reasons.

Just wandering around our own configury bits does show some of these
kinds of problems.  No idea if they'd manifest themselves in a visible
ways though.

Maybe it's a case where it's an opt-in argument in the immediate term
and we work with the autoconf folks to squash out as many problems as we
can and build out some kind of distro-like testing before flipping the
default.

jeff

Re: C++ PATCH for c++/86184, rejects-valid with ?: and omitted operand

[Jason Merrill]

On Thu, Jun 21, 2018 at 2:22 PM, Marek Polacek  wrote:
> The following testcase is rejected because, for this line:
>
>   bool b = X() ?: false;
>
> arg2 is missing and arg1 is a TARGET_EXPR.  A TARGET_EXPR is a class
> prvalue so we wrap it in a SAVE_EXPR.  Later when building 'this' we
> call build_this (SAVE_EXPR >) which triggers lvalue_error:
>  5856   cp_lvalue_kind kind = lvalue_kind (arg);
>  5857   if (kind == clk_none)
>  5858 {
>  5859   if (complain & tf_error)
>  5860 lvalue_error (input_location, lv_addressof);
> because all SAVE_EXPRs are non-lvalue.
>
> Since
> a) cp_build_addr_expr_1 can process xvalues and class prvalues,
> b) TARGET_EXPRs are only evaluated once (gimplify_target_expr),
> I thought we could do the following.  The testcase ensures that
> with the omitted operand we only construct X once.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-06-21  Marek Polacek  
>
> PR c++/86184
> * call.c (build_conditional_expr_1): Don't wrap TARGET_EXPRs
> in a SAVE_EXPR.
>
> * g++.dg/ext/cond3.C: New test.
>
> --- gcc/cp/call.c
> +++ gcc/cp/call.c
> @@ -4806,6 +4806,10 @@ build_conditional_expr_1 (location_t loc, tree arg1, 
> tree arg2, tree arg3,
>/* Make sure that lvalues remain lvalues.  See g++.oliva/ext1.C.  */
>if (lvalue_p (arg1))
> arg2 = arg1 = cp_stabilize_reference (arg1);
> +  else if (TREE_CODE (arg1) == TARGET_EXPR)
> +   /* TARGET_EXPRs are only expanded once, don't wrap it in a SAVE_EXPR,
> +  rendering it clk_none of clk_class.  */
> +   arg2 = arg1;
>else
> arg2 = arg1 = cp_save_expr (arg1);

How about adding the special handling in cp_save_expr rather than
here, so other callers also benefit?

OK with that change.

Jason

Re: [patch, fortran] Handling of .and. and .or. expressions

[Steve Kargl]

On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
> >
> > And we are not going to change Fortran semantics. And I also oppose
> > defining our own subset of Fortran in the hope that people will make
> > fewer mistakes.
> >
> > A function is something that produces a value.  If the value is not
> > needed to produce the correct result, the function need not be called.
> 
> That's a bit oversimplified, isn't it?

Technically, the standard says an operand need not be evaluate,
but you've asked people not to cite the Standard.  I've also
pointed you to F2018 Note 10.28 where it very clearly says that
a function need not be evaluated with example nearly identical
to the one in the PR.  PURE vs IMPURE (or unmarked) function
is a red herring.  The standard makes no distinction.  

-- 
Steve

[committed] [0/3] Converting the v850 port away from cc0

[Jeff Law]

So as noted earlier, my son needed a project to occupy him, so he's
learning a bit of vi, git, & gcc by doing some of the easier parts of
cc0 -> REG_CC conversions.

I selected the v8 port as the first target based on the (flawed)
assumption that it would be the easiest.  It turns out a fair amount has
changed since I did the original v8 port many years ago.  Regardless,
it's done with a bit more head banging than expected.

Just a few notes for anyone who cares about this port.

Testing:

I haven't upstreamed all the bits I used for testing.

In the simulator/binutils/newlib I've given the simulator an extra
megabyte of memory.  The inconsistencies caused by collisions in the
various segments are painful to deal with.  However, I have not
upstreamed that change -- various comments lead me to believe the
current memory map may be derived from real hardware.

I haven't upstreamed a tweak in sim_fpu_neg where I think we're
mis-handling negation of NaNs.  I believe we're supposed to return a NaN
with the sign flipped.  But right now it just returns the original NaN.

There's a couple places in the simulator that are not 64 bit clean, in
particular handling of multiply and divide insns.  These are v850
specific issues and I'll likely upstream these fixes.  I suspect there's
other 64 bit issues it the code.  I'm not going to do a full audit of
the v850 simulator.

I'm pretty sure the v850 simulator mis-handles the "bins" instruction.
But it's also the case that I don't have any documentation on that insn,
so there may be some kind of restrictions that I'm not aware of.  For
testing purposes I disabled use of "bins".  But I'm not upstreaming that
hack.

I believe I've found a bug in the FNMAS handling in tree-ssa-mathopts.c.
 I still need to go through the relevant parts of the IEEE standard to
be sure.  In the mean time I've got a little hack that guards the
suspicious transformation on HONOR_SIGNED_ZEROs.

[Whoops, sent the 01-03 messages, but not the cover... ]

In the testsuite, there are many tests which simply use too much memory,
even with the extra megabyte added.  I'm currently guarding those with a
hack.  I'll probably upstream some kind of tweak here.

I'm pretty sure newlib's sprintf is not compliant enough to pass
builtin-sprintf.c's test.  So that's guarded as well.  Similarly there's
a guard for trapv tests which want to use fork and one or two other
oddballs.

So, with those caveats, the tests look really good now.  Essentially the
only differences between the trunk and a converted port are the
additional tests that we get a dumpfile from the compare-elim pass.

Code quality:

>From a code generation standpoint the trunk and the converted port are
essentially the same when comparing libgcc and newlib.  I've seen the
converted port miss a couple compare eliminations due to the CFG shape
changing after compare-elim.  But there's other cases where we're doing
a slightly better job at compare elimination -- in the end it's a wash.

Style:

The v8 does not have the ability to add two registers without changing
the condition codes.  So we don't expose the condition codes until after
reload, except as clobbers.  For insns where the condition codes are set
in a useful manner we have define_insn_and_split patterns to handle the
pre-reload and post-reload case (with and without clobbers respectively)
as well as patterns which set the condition codes.

A few insns do potentially set the condition codes in a useful way, but
I haven't bothered to describe the condition code handling as it's
unlikely to be all that important relative to the bloat they'd introduce
in v850.md (for example the divide instructions).

Future work

With cc0 eliminated on the v850 port, it can potentially convert to LRA.
 I've done light testing which looks promising, but haven't looked at it
extensively.   I'll probably do the conversion since it looks so easy.

If someone had an interest, they probably could do things like exploit
the C bit to improve 64bit arithmetic.  We're probably not using the
tst1 and similar instructions very aggressively either.  I'm not
planning to work on either of these issues.

I don't expect I'll do much, if anything, else on the v8 port.   My son
is currently working on the mechanical changes to convert the h8 port
away from cc0.

Jeff

Re: [PATCH, rs6000, C/C++] Fix PR target/86324: divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble

[Segher Boessenkool]

On Wed, Jun 27, 2018 at 03:26:42PM -0500, Peter Bergner wrote:
> The test case in PR86324 exposes a problem when long double is the same as
> __ieee128 and we attempt to use the KC mode attribute.  A complimentary
> problem exists when long double is the same as __ibm128 and we try to use
> the IC mode attribute.  The problem is that for the type that long double
> is set to, we always use internally the long double type and TFmode/TCmode
> rather than __ieee128/K[FC]mode or __ibm128/I[FC]mode, so we have problems
> when looking up the unused modes during attribute processing.
> 
> Talking with Joseph offline, he suggested to add a hook that allows the
> target to translate mode attributes like the above into the mode that
> should be used.  The patch below implements that suggestion and it fixes
> the problem test cases.
> 
> This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
> Ok for trunk?
> 
> This is also broken in GCC 8, is this ok to backport once it has has baked
> on trunk for a few days and assuming testing comes out clean?
> 
> The pr86324-2.c test case is also broken in GCC 7, but it looks like that
> has been broken forever, so I'm not sure I'm inclined to want to backport
> this that far.  Thoughts?

This is all okay with me, if someone approves the generic parts.

One thing:

> --- gcc/target.def(revision 262159)
> +++ gcc/target.def(working copy)
> @@ -3310,6 +3310,16 @@ constants can be done inline.  The funct
>   HOST_WIDE_INT, (const_tree constant, HOST_WIDE_INT basic_align),
>   default_constant_alignment)
>  
> +DEFHOOK
> +(translate_mode_attribute,
> + "Define this hook if the port should translate machine_mode @var{mode}\n\
> +to another mode.  For example, rs6000's @code{KFmode}, when it is the same\n\
> +as @code{TFmode}.\n\
> +\n\
> +The default version of the hook returns that mode that was passed in.",
> + machine_mode, (machine_mode mode),
> + default_translate_mode_attribute)

It isn't clear here when this hook is called.  Is the idea to use it
everywhere where modes are created, or only where it is used now (the arg
to a "mode" attribute)?  Probably the latter, but it's not really clear
from the text.

Thanks,


Segher

Re: [PATCH] C++: don't offer bogus "._0" suggestions (PR c++/86329)

[Jason Merrill]

OK.

On Wed, Jun 27, 2018 at 3:01 PM, David Malcolm  wrote:
> PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:
>
> #include 
>
> int compare()
> {
>   return __n1 - __n2;
> }
>
> suggested.cc: In function 'int compare()':
> suggested.cc:5:10: error: '__n1' was not declared in this scope
>return __n1 - __n2;
>   ^~~~
> suggested.cc:5:10: note: suggested alternative: '._61'
>return __n1 - __n2;
>   ^~~~
>   ._61
> suggested.cc:5:17: error: '__n2' was not declared in this scope
>return __n1 - __n2;
>  ^~~~
> suggested.cc:5:17: note: suggested alternative: '._72'
>return __n1 - __n2;
>  ^~~~
>  ._72
>
> The dot-prefixed names are an implementation detail of how we implement
> anonymous enums found in the header files, generated via
> anon_aggrname_format in make_anon_name.
>
> This patch uses anon_aggrname_p to filter them out when considering
> which names to suggest.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
> adds 9 PASS results to g++.sum
>
> OK for trunk, gcc-8, gcc-7 branches?
>
> gcc/cp/ChangeLog:
> PR c++/86329
> * name-lookup.c (consider_binding_level): Filter out names that
> match anon_aggrname_p.
>
> gcc/testsuite/ChangeLog:
> PR c++/86329
> * g++.dg/lookup/pr86329.C: New test.
> ---
>  gcc/cp/name-lookup.c  |  5 +
>  gcc/testsuite/g++.dg/lookup/pr86329.C | 11 +++
>  2 files changed, 16 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/lookup/pr86329.C
>
> diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
> index a30c374..6ec4e6e 100644
> --- a/gcc/cp/name-lookup.c
> +++ b/gcc/cp/name-lookup.c
> @@ -5786,6 +5786,11 @@ consider_binding_level (tree name, best_match  const char *> ,
>if (!suggestion)
> continue;
>
> +  /* Don't suggest names that are for anonymous aggregate types, as
> +they are an implementation detail generated by the compiler.  */
> +  if (anon_aggrname_p (suggestion))
> +   continue;
> +
>const char *suggestion_str = IDENTIFIER_POINTER (suggestion);
>
>/* Ignore internal names with spaces in them.  */
> diff --git a/gcc/testsuite/g++.dg/lookup/pr86329.C 
> b/gcc/testsuite/g++.dg/lookup/pr86329.C
> new file mode 100644
> index 000..fc091ba
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/lookup/pr86329.C
> @@ -0,0 +1,11 @@
> +/* PR c++/86329: ensure we don't erroneously offer suggestions like "._0",
> +   which are an implementation detail of how e.g. anonymous enums are
> +   handled internally.  */
> +
> +enum {NONEMPTY};
> +
> +int test()
> +{
> +  return __0; // { dg-error "'__0' was not declared in this scope" }
> +  // { dg-bogus "suggested alternative" "" { target *-*-* } .-1 }
> +}
> --
> 1.8.5.3
>

[PR fortran/82865] Fix PDT declarations being parsed as PRINT statements with -fdec

[Fritz Reese]

One extension enabled by -fdec is the ability to interpret TYPE 
as a PRINT statement for compatibility purposes. When PDTs were
introduced, the code that handles -fde TYPE matching was not updated.
This patch fixes TYPE matching to no longer interpret  as a PRINT statement when -fdec is asserted. Passes
regression tests as well.

The patch is attached. OK for trunk and 7/8-branch?

0dd08cefc2476014487b3eeab059784ab21bb41b Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Wed, 27 Jun 2018 15:43:45 -0400
Subject: [PATCH 3/3] PR fortran/82865

Do not override PDT declarations from gfc_match_type with -fdec.

gcc/fortran/

* decl.c (gfc_match_type): Refactor and check for PDT declarations.

gcc/testsuite/

* gfortran.dg/dec_type_print_2.f03: New testcase.
---
 gcc/fortran/decl.c | 66 +-
 gcc/testsuite/gfortran.dg/dec_type_print_2.f03 | 59 +++
 2 files changed, 93 insertions(+), 32 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/dec_type_print_2.f03
From 0dd08cefc2476014487b3eeab059784ab21bb41b Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Wed, 27 Jun 2018 15:43:45 -0400
Subject: [PATCH 3/3] PR fortran/82865

Do not override PDT declarations from gfc_match_type with -fdec.

gcc/fortran/

	* decl.c (gfc_match_type): Refactor and check for PDT declarations.

gcc/testsuite/

	* gfortran.dg/dec_type_print_2.f03: New testcase.
---
 gcc/fortran/decl.c | 66 +-
 gcc/testsuite/gfortran.dg/dec_type_print_2.f03 | 59 +++
 2 files changed, 93 insertions(+), 32 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/dec_type_print_2.f03

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index af724658d8d..ef59d1679ed 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -9607,9 +9607,9 @@ gfc_match_structure_decl (void)
 
 
 /* This function does some work to determine which matcher should be used to
- * match a statement beginning with "TYPE". This is used to disambiguate TYPE
+ * match a statement beginning with "TYPE".  This is used to disambiguate TYPE
  * as an alias for PRINT from derived type declarations, TYPE IS statements,
- * and derived type data declarations.  */
+ * and [parameterized] derived type declarations.  */
 
 match
 gfc_match_type (gfc_statement *st)
@@ -9636,11 +9636,7 @@ gfc_match_type (gfc_statement *st)
   /* If we see an attribute list before anything else it's definitely a derived
* type declaration.  */
   if (gfc_match (" ,") == MATCH_YES || gfc_match (" ::") == MATCH_YES)
-{
-  gfc_current_locus = old_loc;
-  *st = ST_DERIVED_DECL;
-  return gfc_match_derived_decl ();
-}
+goto derived;
 
   /* By now "TYPE" has already been matched. If we do not see a name, this may
* be something like "TYPE *" or "TYPE ".  */
@@ -9655,29 +9651,11 @@ gfc_match_type (gfc_statement *st)
 	  *st = ST_WRITE;
 	  return MATCH_YES;
 	}
-  gfc_current_locus = old_loc;
-  *st = ST_DERIVED_DECL;
-  return gfc_match_derived_decl ();
+  goto derived;
 }
 
-  /* A derived type declaration requires an EOS. Without it, assume print.  */
-  m = gfc_match_eos ();
-  if (m == MATCH_NO)
-{
-  /* Check manually for TYPE IS (... - this is invalid print syntax.  */
-  if (strncmp ("is", name, 3) == 0
-	  && gfc_match (" (", name) == MATCH_YES)
-	{
-	  gfc_current_locus = old_loc;
-	  gcc_assert (gfc_match (" is") == MATCH_YES);
-	  *st = ST_TYPE_IS;
-	  return gfc_match_type_is ();
-	}
-  gfc_current_locus = old_loc;
-  *st = ST_WRITE;
-  return gfc_match_print ();
-}
-  else
+  /* Check for EOS.  */
+  if (gfc_match_eos () == MATCH_YES)
 {
   /* By now we have "TYPE  ". Check first if the name is an
* intrinsic typename - if so let gfc_match_derived_decl dump an error.
@@ -9690,12 +9668,36 @@ gfc_match_type (gfc_statement *st)
 	  *st = ST_DERIVED_DECL;
 	  return m;
 	}
-  gfc_current_locus = old_loc;
-  *st = ST_WRITE;
-  return gfc_match_print ();
 }
+  else
+{
+  /* Here we have "TYPE ". Check for  or a PDT declaration
+	 like .  */
+  gfc_gobble_whitespace ();
+  bool paren = gfc_peek_ascii_char () == '(';
+  if (paren)
+	{
+	  if (strcmp ("is", name) == 0)
+	goto typeis;
+	  else
+	goto derived;
+	}
+}
+
+  /* Treat TYPE... like PRINT...  */
+  gfc_current_locus = old_loc;
+  *st = ST_WRITE;
+  return gfc_match_print ();
 
-  return MATCH_NO;
+derived:
+  gfc_current_locus = old_loc;
+  *st = ST_DERIVED_DECL;
+  return gfc_match_derived_decl ();
+
+typeis:
+  gfc_current_locus = old_loc;
+  *st = ST_TYPE_IS;
+  return gfc_match_type_is ();
 }
 
 
diff --git a/gcc/testsuite/gfortran.dg/dec_type_print_2.f03 b/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
new file mode 100644
index 000..31b8c3ad934
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
@@ -0,0 +1,59 @@
+! { 

[PR fortran/83184] Fix matching code for clist/old-style initializers when encountering assumed-rank declarations

[Fritz Reese]

The attached patch fixes PR fortran/83184, which is actually two
distinct bugs as described in the PR. Passes regtests.

The patch is attached. OK for trunk and 7/8-branch?

>From 238f0a0e80c93209bb4e62ba2f719f74f5da164f Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Wed, 27 Jun 2018 16:16:31 -0400
Subject: [PATCH 2/3] PR fortran/83184

Fix handling of invalid assumed-shape/size arrays in legacy initializer
lists.

gcc/fortran/

* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.

gcc/testsuite/

* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.
---
 gcc/fortran/decl.c | 63 +++---
 gcc/testsuite/gfortran.dg/assumed_rank_14.f90  | 11 +
 gcc/testsuite/gfortran.dg/assumed_rank_15.f90  | 11 +
 gcc/testsuite/gfortran.dg/dec_structure_23.f90 |  6 +--
 gcc/testsuite/gfortran.dg/dec_structure_8.f90  |  6 +--
 5 files changed, 64 insertions(+), 33 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_14.f90
 create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_15.f90
From 238f0a0e80c93209bb4e62ba2f719f74f5da164f Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Wed, 27 Jun 2018 16:16:31 -0400
Subject: [PATCH 2/3] PR fortran/83184

Fix handling of invalid assumed-shape/size arrays in legacy initializer
lists.

gcc/fortran/

	* decl.c (match_old_style_init): Initialize locus of variable expr when
	creating a data variable.
	(match_clist_expr): Verify array is explicit shape/size before
	attempting to allocate constant array constructor.

gcc/testsuite/

	* gfortran.dg/assumed_rank_14.f90: New testcase.
	* gfortran.dg/assumed_rank_15.f90: New testcase.
	* gfortran.dg/dec_structure_8.f90: Update error messages.
	* gfortran.dg/dec_structure_23.f90: Update error messages.
---
 gcc/fortran/decl.c | 63 +++---
 gcc/testsuite/gfortran.dg/assumed_rank_14.f90  | 11 +
 gcc/testsuite/gfortran.dg/assumed_rank_15.f90  | 11 +
 gcc/testsuite/gfortran.dg/dec_structure_23.f90 |  6 +--
 gcc/testsuite/gfortran.dg/dec_structure_8.f90  |  6 +--
 5 files changed, 64 insertions(+), 33 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_14.f90
 create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_15.f90

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index cb235343962..af724658d8d 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -521,6 +521,7 @@ match_old_style_init (const char *name)
   newdata = gfc_get_data ();
   newdata->var = gfc_get_data_variable ();
   newdata->var->expr = gfc_get_variable_expr (st);
+  newdata->var->expr->where = sym->declared_at;
   newdata->where = gfc_current_locus;
 
   /* Match initial value list. This also eats the terminal '/'.  */
@@ -632,7 +633,7 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
 {
   gfc_constructor_base array_head = NULL;
   gfc_expr *expr = NULL;
-  match m;
+  match m = MATCH_ERROR;
   locus where;
   mpz_t repeat, cons_size, as_size;
   bool scalar;
@@ -640,18 +641,27 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
 
   gcc_assert (ts);
 
-  mpz_init_set_ui (repeat, 0);
-  scalar = !as || !as->rank;
-
   /* We have already matched '/' - now look for a constant list, as with
  top_val_list from decl.c, but append the result to an array.  */
   if (gfc_match ("/") == MATCH_YES)
 {
   gfc_error ("Empty old style initializer list at %C");
-  goto cleanup;
+  return MATCH_ERROR;
 }
 
   where = gfc_current_locus;
+  scalar = !as || !as->rank;
+
+  if (!scalar && !spec_size (as, _size))
+{
+  gfc_error ("Array in initializer list at %L must have an explicit shape",
+		 as->type == AS_EXPLICIT ? >upper[0]->where : );
+  /* Nothing to cleanup yet.  */
+  return MATCH_ERROR;
+}
+
+  mpz_init_set_ui (repeat, 0);
+
   for (;;)
 {
   m = match_data_constant ();
@@ -681,7 +691,10 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
 
   m = match_data_constant ();
   if (m == MATCH_NO)
-gfc_error ("Expected data constant after repeat spec at %C");
+	{
+	  m = MATCH_ERROR;
+	  gfc_error ("Expected data constant after repeat spec at %C");
+	}
   if (m != MATCH_YES)
 goto cleanup;
 }
@@ -724,6 +737,9 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
 goto syntax;
 }
 
+  /* If we break early from here out, we encountered an error.  */
+  m = MATCH_ERROR;
+
   /* Set up expr as an array constructor. 

Re: [PR Fortran/83183] Fix infinite recursion (ICE) with -finit-derived when initializing allocatable BT_DERIVED components

[Fritz Reese]

On Mon, Jun 25, 2018 at 9:04 PM Steve Kargl
 wrote:
> ... It does seem odd to me
> that BT_CLASS has !c->attr.allocatable and BT_DERIVED
> is c->attr.allocatable, i.e., bang vs no bang.  Is this
> because class is not affected by -finit-derived?
>

I'm glad you raised the question. As a result I looked a little harder
at the condition -- it had always been somewhat of a mystery to me
actually, as I copied it from some old initializer code. I'll talk
about what I discovered here. For a tl;dr see the bottom for a new
patch.

There are a few subtleties involved. First, 'ts->type' refers to the
type of the structure containing the component, rather than the
component itself. For this reason my patch is actually incorrect. The
new condition should read:

-  || (ts->type == BT_DERIVED && c->attr.allocatable)
+  || (c->ts.type == BT_DERIVED && c->attr.allocatable)

The BT_CLASS clause is to prevent generating initializers for
components within a BT_CLASS definition, because these components are
special (_hash, _size, _extends, _def_init, _copy, _final,
_deallocate, _data, _vptr). I believe it is true that the
c->attr.allocatable check is bogus along with c->ts.type == BT_CLASS.
The intent is likely to pass-through component_initializer() for the
special "_data" component, so that EXPR_NULL will be used in
gfc_generate_initializer() for the condition around line 4580:

>  if (comp->attr.allocatable
> || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)->attr.allocatable))
>   {

I've found I could exploit these weak conditions by using a BT_CLASS
pointer component with -finit-derived. I've reported the issue in PR
86325. After taking a good hard look at the conditions involved, I've
learned the following rules, which were previously unenforced:

  * with -finit-derived, allocatable and pointer components (including
BT_CLASS components with an allocatable or pointer _data component)
should initialize with EXPR_NULL
  * even without -finit-derived, allocatable components (including
BT_CLASS components with an allocatable _data component) should be
initialized using EXPR_NULL
  * special components of a BT_CLASS structure (named _*) should never
have an initializer generated by gfc_generate_initializer()
  * gfc_component::initializer is for user-defined assignment
initializers and should never be set by gfc_generate_initializer()

I have thus simplified, implemented, and documented the conditions and
rules above. Vacuously this fixes PR 83183, since a component which
would invoke a recursive derived-type initializer generation must be
allocatable or a pointer; with the above rules, such components are
now assigned EXPR_NULL with -finit-derived which avoids the recursion.
Without -finit-derived, allocatable components are still generated an
EXPR_NULL expression, matching the compiler's original behavior. This
also fixes PR 86325 (mentioned above).

The patch is attached. OK for trunk and 7/8-branch?

>From e190d59153eaa7fbfcfabc93db31ddda0de3b869 Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Mon, 25 Jun 2018 17:51:00 -0400
Subject: [PATCH 1/3] PR fortran/83183 PR fortran/86325

Fix allocatable/pointer conditions for -finit-derived.

gcc/fortran/

* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into component_initializer().

gcc/testsuite/

* gfortran.dg/init_flag_19.f03: New testcase.
---
 gcc/fortran/expr.c | 73 --
 gcc/testsuite/gfortran.dg/init_flag_18.f90 | 19 
 gcc/testsuite/gfortran.dg/init_flag_19.f03 | 36 +++
 3 files changed, 103 insertions(+), 25 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/init_flag_18.f90
 create mode 100644 gcc/testsuite/gfortran.dg/init_flag_19.f03
From e190d59153eaa7fbfcfabc93db31ddda0de3b869 Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Mon, 25 Jun 2018 17:51:00 -0400
Subject: [PATCH 1/3] PR fortran/83183 PR fortran/86325

Fix allocatable/pointer conditions for -finit-derived.

gcc/fortran/

	* expr.c (class_allocatable, class_pointer, comp_allocatable,
	comp_pointer): New helpers.
	(component_initializer): Generate EXPR_NULL for allocatable or pointer
	components. Do not generate initializers for components within BT_CLASS.
	Do not assign to comp->initializer.
	(gfc_generate_initializer): Use new helpers; move code to generate
	EXPR_NULL for class allocatable components into component_initializer().

gcc/testsuite/

	* gfortran.dg/init_flag_19.f03: New testcase.
---
 gcc/fortran/expr.c | 73 --
 

Re: [PATCH, rs6000] Backport Fix tests that are failing in gcc.target/powerpc/bfp with -m32

[Segher Boessenkool]

Hi!

On Tue, Jun 26, 2018 at 02:56:40PM -0500, Kelvin Nilsen wrote:
> This patch, as revised in response to your suggestions, was committed to 
> trunk on 4/17/2018.
> 
> Is this ok for backporting to gcc8, gcc7, and gcc6?

Okay for all.  Thanks!


Segher


> > 2018-04-13  Kelvin Nilsen  
> > 
> >     * config/rs6000/rs6000-protos.h (rs6000_builtin_is_supported_p):
> >     New prototype.
> >     * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
> >     Add note to error message to explain internal mapping of overloaded
> >     built-in function name to non-overloaded built-in function name.
> >     * config/rs6000/rs6000.c (rs6000_builtin_is_supported_p): New
> >     function.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2018-04-13  Kelvin Nilsen  
> > 
> >     * gcc.target/powerpc/bfp/scalar-extract-sig-5.c: Simplify to
> >     prevent cascading of errors and change expected error message.
> >     * gcc.target/powerpc/bfp/scalar-test-neg-4.c: Restrict this test
> >     to 64-bit targets.
> >     * gcc.target/powerpc/bfp/scalar-test-data-class-8.c: Likewise.
> >     * gcc.target/powerpc/bfp/scalar-test-data-class-9.c: Likewise.
> >     * gcc.target/powerpc/bfp/scalar-test-data-class-10.c: Likewise.
> >     * gcc.target/powerpc/bfp/scalar-insert-exp-11.c: Change expected
> >     error message.
> >     * gcc.target/powerpc/bfp/scalar-extract-exp-5.c: Likewise.

Re: [PATCH, rs6000, C/C++] Fix PR target/86324: divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble

[Peter Bergner]

On 6/27/18 3:26 PM, Peter Bergner wrote:
> gcc/
>   PR target/86324
>   * target.def (translate_mode_attribute): New hook.
>   * targhooks.h (default_translate_mode_attribute): Declare.
>   * targhooks.c (default_translate_mode_attribute): New function.
>   * doc/tm.texi.in (TARGET_TRANSLATE_MODE_ATTRIBUTE): New hook.
>   * doc/tm.texi: Regenerate.
>   * config/rs6000/rs6000.c (TARGET_TRANSLATE_MODE_ATTRIBUTE): Define.
>   (rs6000_translate_mode_attribute): New function.
> 
> gcc/c-family/
>   PR target/86324
>   * c-attribs.c (handle_mode_attribute): Call new translate_mode_attribute
>   target hook.

Oops, I forgot the test cases.  Here they are.

Peter


gcc/testsuite/
PR target/86324
gcc.target/powerpc/pr86324-1.c: New test.
gcc.target/powerpc/pr86324-2.c: Likewise.

Index: gcc/testsuite/gcc.target/powerpc/pr86324-1.c
===
--- gcc/testsuite/gcc.target/powerpc/pr86324-1.c(nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr86324-1.c(working copy)
@@ -0,0 +1,10 @@
+/* { dg-do compile { target { powerpc*-*-linux* } } } */
+/* { dg-options "-mlong-double-128 -mabi=ieeelongdouble -Wno-psabi" } */
+
+typedef __complex float cflt_t __attribute__((mode(KC)));
+
+cflt_t
+divide (cflt_t *ptr)
+{
+  return *ptr;
+}
Index: gcc/testsuite/gcc.target/powerpc/pr86324-2.c
===
--- gcc/testsuite/gcc.target/powerpc/pr86324-2.c(nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr86324-2.c(working copy)
@@ -0,0 +1,10 @@
+/* { dg-do compile { target { powerpc*-*-linux* } } } */
+/* { dg-options "-mlong-double-128 -mabi=ibmlongdouble -Wno-psabi" } */
+
+typedef __complex float cflt_t __attribute__((mode(IC)));
+
+cflt_t
+divide (cflt_t *ptr)
+{
+  return *ptr;
+}

Re: [PATCH v3] add support for --disable-gcov

[Rasmus Villemoes]

On 2018-06-27 21:22, Rainer Orth wrote:
> Hi Jeff,
> 
>>> So add an option for disabling build and install of libgcov and the
>>> related host tools.
>>>
>>> 2018-06-10  Rasmus Villemoes  
>>>
>>> gcc/
>>> * configure.ac: Add --disable-gcov option.
>>> * configure: Regenerate.
>>> * Makefile.in: Honour @enable_gcov@.
>>> * doc/install.texi: Document --disable-gcov.
>>>
>>> libgcc/
>>> * configure.ac: Add --disable-gcov option.
>>> * configure: Regenerate.
>>> * Makefile.in: Honour @enable_gcov@.
>> OK.  Presumably you're going through the process to get write access.
>> Once that's wrapped up you can install this patch.
> 
> this patch badly broke all -fprofile-generate/-fprofile-use tests in the
> default case like this:
> 
> UNRESOLVED: g++.dg/bprob/g++-bprob-1.C compilation,  -O0  
> -fbranch-probabilities
> FAIL: g++.dg/bprob/g++-bprob-1.C compilation,  -O0  -fprofile-arcs
> 
> ld: fatal: library -lgcov: not found
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
> FAIL: g++.dg/bprob/g++-bprob-1.C compilation,  -g  -fprofile-arcs
> 
> libgcov.a is not copied over from libgcc to gcc due to a typo in
> libgcc/Makefile.in.  Fixed as follows; will install as obvious once
> bootstrap has finished.
> 

I'm terribly sorry about that! I was sure I had tested all of
--enable-gcov, --disable-gcov and none of those, and convinced myself
that the default behaviour was unchanged. Thanks for spotting the
problem and fixing it. I will try to be much more careful in the future.

Rasmus

Re: Limit Debug mode impact: overload __niter_base

[François Dumont]

On 27/06/2018 22:02, Jonathan Wakely wrote:

On 27/06/18 21:25 +0200, François Dumont wrote:

On 27/06/2018 02:13, Jonathan Wakely wrote:

On 26/06/18 17:03 +0100, Jonathan Wakely wrote:

On 18/06/18 23:01 +0200, François Dumont wrote:

Hi

    I abandon the idea of providing Debug algos, it would be too 
much code to add and maintain. However I haven't quit on reducing 
Debug mode performance impact.


    So this patch make use of the existing std::__niter_base to 
get rid of the debug layer around __gnu_debug::vector<>::iterator 
so that __builtin_memmove replacement can take place.


    As _Safe_iterator<> do not have a constructor taking a pointer 
I change algos implementation so that we do not try to instantiate 
the iterator type ourselves but rather rely on its operators + or -.


    The small drawback is that for std::equal algo where we can't 
use the __glibcxx_can_increment we need to keep the debug layer to 
make sure we don't reach past-the-end iterator. So I had to remove 
usage of __niter_base when in Debug mode, doing so it also disable 
potential usage of __builtin_memcmp when calling std::equal on 
std::__cxx1998::vector<> iterators. A rather rare situation I think.


We don't need to give up all checks in std::equal, we can do this:

@@ -1044,7 +1085,13 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
   typename iterator_traits<_II1>::value_type,
   typename iterator_traits<_II2>::value_type>)
  __glibcxx_requires_valid_range(__first1, __last1);
-
+#ifdef _GLIBCXX_DEBUG
+  typedef typename iterator_traits<_II1>::iterator_category _Cat1;
+  typedef typename iterator_traits<_II2>::iterator_category _Cat2;
+  if (!__are_same<_Cat1, input_iterator_tag>::__value
+ && __are_same<_Cat2, random_access_iterator_tag>::__value)
+   __glibcxx_requires_can_increment_range(__first1, __last1, 
__first2);

+#endif
  return std::__equal_aux(std::__niter_base(__first1),
 std::__niter_base(__last1),
 std::__niter_base(__first2));


We don't give up any check.


We do for my version of the patch, because with the new __niter_base
overload the debug layer gets removed. Your patch kept the checking by
not removing the debug layer, but loses the memcmp optimization.

My suggestion above removes the debug layer so uses the optimization,
but adds a separate range check, so we still get checking as well.

We only give up on using the __builtin_memcmp when std::equal is 
being used while Debug mode is active and std::equal is called 
directly with std::__cxx1998::vector.


Moreover this check is wrong and will introduce regression when 
running testsuite in Debug mode (this is why I know). It will assert 
in the following case:

vector v1 { 0, 0, 0 };
vector v2 { 0, 1 };
equal(v1.begin(), v1.end(), v2.begin());


We should assert for that test, it's undefined behaviour.


Oh, ok, then __glibcxx_requires_can_increment_range can be called 
unconditionnaly. It already takes care of doing the right thing.


And some tests might need to be fixed because they contain this 
undefined behavior. I'll do it.


François

Re: std::vector default default and move constructors

[François Dumont]

Commited attached patch.

It fixes the missing noexcept qualification on a __gnu_debug::vector<> 
constructor.


2018-06-27  François Dumont  

    * include/bits/stl_vector.h
    (struct _Vector_base<>::_Vector_impl_data): New.
    (struct _Vector_base<>::_Vector_impl): Inherit from latter.
    (_Vector_base<>::_Vector_impl::_M_swap_data): Move...
    (_Vector_base<>::_Vector_impl_data::_M_swap_data): ...here.
    (_Vector_base<>::_Vector_impl()): Add noexcept qualification.
    (_Vector_base<>::_Vector_impl(_Vector_impl&&)): New.
    (_Vector_base<>::_Vector_impl(_Tp_alloc_type&&, _Vector_impl&&)): New.
    (_Vector_base(const allocator_type&, _Vector_base&&)): New, use latter.
    (_Vector_base()): Default.
    (_Vector_base(_Vector_base&&)): Default.
    (_Vector_base(size_t)) [_GLIBCXX_INLINE_VERSION]: Delete.
    (_Vector_base(_Tp_alloc_type&&)) [_GLIBCXX_INLINE_VERSION]: Delete.
    (_Vector_base::_M_create_storage(size_t)): Make protected.
    (vector()): Default.
    (vector(vector&&)): Default.
    (vector(vector&&, const allocator_type&, true_type)): New.
    (vector(vector&&, const allocator_type&, false_type)): New.
    (vector(vector&&, const allocator_type&)): Use latters.
    (vector(_InputIte, _InputIte, const allocator_type&)): Call
    _M_range_initialize directly.
    * include/debug/vector
    (vector(vector&&, const allocator_type&)): Add noexcept qualification.
    * testsuite/23_containers/vector/allocator/default_init.cc: New.
    * testsuite/23_containers/vector/cons/noexcept_move_construct.cc: Add
    static assertions.

On 26/06/2018 15:46, Jonathan Wakely wrote:

On 02/06/18 14:00 +0200, François Dumont wrote:

Hi

    Here is this patch again, I consider all your remarks and also 
made some changes considering feedback on rbtree patch.





+    _Vector_impl(_Tp_alloc_type const& __a) _GLIBCXX_NOEXCEPT
+    : _Tp_alloc_type(__a)
+    { }
+
+#if __cplusplus >= 201103L
+    // Not defaulted to avoid noexcept qualification dependency on the
+    // _Tp_alloc_type move constructor one.


Could you please rephrase this comment as:

   // Not defaulted, to enforce noexcept(true) even when
   // !is_nothrow_move_constructible<_Tp_alloc_type>.

I prefer this wording, because most allocators don't have a move
constructor at all (just a copy constructor) so talking about its move
constructor is misleading.


+    _Vector_impl(_Vector_impl&& __x) noexcept
+    : _Tp_alloc_type(std::move(__x)), _Vector_impl_data(std::move(__x))
+    { }
+
+    _Vector_impl(_Tp_alloc_type&& __a) noexcept
+    : _Tp_alloc_type(std::move(__a))
+    { }
+
+    _Vector_impl(_Tp_alloc_type&& __a, _Vector_impl&& __rv) noexcept
+    : _Tp_alloc_type(std::move(__a)), 
_Vector_impl_data(std::move(__rv))

+    { }
+#endif

#if _GLIBCXX_SANITIZE_STD_ALLOCATOR && _GLIBCXX_SANITIZE_VECTOR
template
@@ -235,38 +259,42 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER

  _Tp_alloc_type&
  _M_get_Tp_allocator() _GLIBCXX_NOEXCEPT
-  { return *static_cast<_Tp_alloc_type*>(>_M_impl); }
+  { return this->_M_impl; }

  const _Tp_alloc_type&
  _M_get_Tp_allocator() const _GLIBCXX_NOEXCEPT
-  { return *static_cast(>_M_impl); }
+  { return this->_M_impl; }

  allocator_type
  get_allocator() const _GLIBCXX_NOEXCEPT
  { return allocator_type(_M_get_Tp_allocator()); }

-  _Vector_base()
-  : _M_impl() { }
+#if __cplusplus >= 201103L
+  _Vector_base() = default;
+#else
+  _Vector_base() { }
+#endif

  _Vector_base(const allocator_type& __a) _GLIBCXX_NOEXCEPT
  : _M_impl(__a) { }


Please add "// Kept for ABI compatibility" before this #if:


+#if !_GLIBCXX_INLINE_VERSION
  _Vector_base(size_t __n)
  : _M_impl()
  { _M_create_storage(__n); }
+#endif

  _Vector_base(size_t __n, const allocator_type& __a)
  : _M_impl(__a)
  { _M_create_storage(__n); }

#if __cplusplus >= 201103L
+  _Vector_base(_Vector_base&&) = default;
+


And here too:


+# if !_GLIBCXX_INLINE_VERSION
  _Vector_base(_Tp_alloc_type&& __a) noexcept
  : _M_impl(std::move(__a)) { }



OK for trunk with those three comment changes.

Thanks for your patience waiting for the review.







diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h
index acec501..76829fa 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -85,34 +85,58 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   typedef typename __gnu_cxx::__alloc_traits<_Tp_alloc_type>::pointer
	pointer;
 
-  struct _Vector_impl
-  : public _Tp_alloc_type
+  struct _Vector_impl_data
   {
 	pointer _M_start;
 	pointer _M_finish;
 	pointer _M_end_of_storage;
 
-	_Vector_impl()
-	: _Tp_alloc_type(), _M_start(), _M_finish(), _M_end_of_storage()
-	{ }
-
-	_Vector_impl(_Tp_alloc_type const& __a) _GLIBCXX_NOEXCEPT
-	: _Tp_alloc_type(__a), _M_start(), _M_finish(), _M_end_of_storage()
+	_Vector_impl_data() _GLIBCXX_NOEXCEPT

[PATCH, rs6000, C/C++] Fix PR target/86324: divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble

[Peter Bergner]

The test case in PR86324 exposes a problem when long double is the same as
__ieee128 and we attempt to use the KC mode attribute.  A complimentary
problem exists when long double is the same as __ibm128 and we try to use
the IC mode attribute.  The problem is that for the type that long double
is set to, we always use internally the long double type and TFmode/TCmode
rather than __ieee128/K[FC]mode or __ibm128/I[FC]mode, so we have problems
when looking up the unused modes during attribute processing.

Talking with Joseph offline, he suggested to add a hook that allows the
target to translate mode attributes like the above into the mode that
should be used.  The patch below implements that suggestion and it fixes
the problem test cases.

This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
Ok for trunk?

This is also broken in GCC 8, is this ok to backport once it has has baked
on trunk for a few days and assuming testing comes out clean?

The pr86324-2.c test case is also broken in GCC 7, but it looks like that
has been broken forever, so I'm not sure I'm inclined to want to backport
this that far.  Thoughts?

Peter


gcc/
PR target/86324
* target.def (translate_mode_attribute): New hook.
* targhooks.h (default_translate_mode_attribute): Declare.
* targhooks.c (default_translate_mode_attribute): New function.
* doc/tm.texi.in (TARGET_TRANSLATE_MODE_ATTRIBUTE): New hook.
* doc/tm.texi: Regenerate.
* config/rs6000/rs6000.c (TARGET_TRANSLATE_MODE_ATTRIBUTE): Define.
(rs6000_translate_mode_attribute): New function.

gcc/c-family/
PR target/86324
* c-attribs.c (handle_mode_attribute): Call new translate_mode_attribute
target hook.

Index: gcc/target.def
===
--- gcc/target.def  (revision 262159)
+++ gcc/target.def  (working copy)
@@ -3310,6 +3310,16 @@ constants can be done inline.  The funct
  HOST_WIDE_INT, (const_tree constant, HOST_WIDE_INT basic_align),
  default_constant_alignment)
 
+DEFHOOK
+(translate_mode_attribute,
+ "Define this hook if the port should translate machine_mode @var{mode}\n\
+to another mode.  For example, rs6000's @code{KFmode}, when it is the same\n\
+as @code{TFmode}.\n\
+\n\
+The default version of the hook returns that mode that was passed in.",
+ machine_mode, (machine_mode mode),
+ default_translate_mode_attribute)
+
 /* True if MODE is valid for the target.  By "valid", we mean able to
be manipulated in non-trivial ways.  In particular, this means all
the arithmetic is supported.  */
Index: gcc/targhooks.c
===
--- gcc/targhooks.c (revision 262159)
+++ gcc/targhooks.c (working copy)
@@ -393,6 +393,14 @@ default_mangle_assembler_name (const cha
   return get_identifier (stripped);
 }
 
+/* The default implementation of TARGET_TRANSLATE_MODE_ATTRIBUTE.  */
+
+machine_mode
+default_translate_mode_attribute (machine_mode mode)
+{
+  return mode;
+}
+
 /* True if MODE is valid for the target.  By "valid", we mean able to
be manipulated in non-trivial ways.  In particular, this means all
the arithmetic is supported.
Index: gcc/targhooks.h
===
--- gcc/targhooks.h (revision 262159)
+++ gcc/targhooks.h (working copy)
@@ -72,6 +72,7 @@ extern void default_print_operand_addres
 extern bool default_print_operand_punct_valid_p (unsigned char);
 extern tree default_mangle_assembler_name (const char *);
 
+extern machine_mode default_translate_mode_attribute (machine_mode);
 extern bool default_scalar_mode_supported_p (scalar_mode);
 extern bool default_libgcc_floating_mode_supported_p (scalar_float_mode);
 extern opt_scalar_float_mode default_floatn_mode (int, bool);
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 262159)
+++ gcc/doc/tm.texi (working copy)
@@ -4255,6 +4255,14 @@ hook returns true for both @code{ptr_mod
 Define this to return nonzero if the memory reference @var{ref}  may alias 
with the system C library errno location.  The default  version of this hook 
assumes the system C library errno location  is either a declaration of type 
int or accessed by dereferencing  a pointer to int.
 @end deftypefn
 
+@deftypefn {Target Hook} machine_mode TARGET_TRANSLATE_MODE_ATTRIBUTE 
(machine_mode @var{mode})
+Define this hook if the port should translate machine_mode @var{mode}
+to another mode.  For example, rs6000's @code{KFmode}, when it is the same
+as @code{TFmode}.
+
+The default version of the hook returns that mode that was passed in.
+@end deftypefn
+
 @deftypefn {Target Hook} bool TARGET_SCALAR_MODE_SUPPORTED_P (scalar_mode 
@var{mode})
 Define this to return nonzero if the port is prepared to handle
 insns involving scalar mode @var{mode}.  For a scalar mode 

Re: [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125)

[Joseph Myers]

On Tue, 26 Jun 2018, Martin Sebor wrote:

> Attached is an updated patch to tighten up the warning and also
> prevent ICEs in the middle-end like in PR 86308 or PR 86202.

This patch adds two arguments to match_builtin_function_types, but doesn't 
update the comment on that function to define their semantics.

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

Re: [PATCH v3] Change default to -fno-math-errno

[Joseph Myers]

On Tue, 26 Jun 2018, Wilco Dijkstra wrote:

> > If the library does not set errno, clearly -fno-math-errno by default is 
> > appropriate (and is the default on Darwin).
> 
> Various librarys no longer set errno nowadays, for example BSD, MUSL, Bionic
> etc. For GLIBC 3.0 I'd propose to drop setting of errno as well since very few
> applications check errno after math functions that may set it (C89 support
> could be added using wrappers that set errno if required).

I think that's clearly something that would require new symbol versions 
for all affected symbols, or a new SONAME.

> That looks incorrect indeed but that's mostly a problem with -fmath-errno as 
> it
> would result in GCC assuming the function is const/pure when in fact it isn't.
> Does ATTR_MATHFN_FPROUNDING imply that errno is dead after the call?

No, it implies a pure function, so the previous errno value is still live 
after the call.

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

Re: Limit Debug mode impact: overload __niter_base

[Jonathan Wakely]

On 27/06/18 21:25 +0200, François Dumont wrote:

On 27/06/2018 02:13, Jonathan Wakely wrote:

On 26/06/18 17:03 +0100, Jonathan Wakely wrote:

On 18/06/18 23:01 +0200, François Dumont wrote:

Hi

    I abandon the idea of providing Debug algos, it would be too 
much code to add and maintain. However I haven't quit on 
reducing Debug mode performance impact.


    So this patch make use of the existing std::__niter_base to 
get rid of the debug layer around 
__gnu_debug::vector<>::iterator so that __builtin_memmove 
replacement can take place.


    As _Safe_iterator<> do not have a constructor taking a 
pointer I change algos implementation so that we do not try to 
instantiate the iterator type ourselves but rather rely on its 
operators + or -.


    The small drawback is that for std::equal algo where we 
can't use the __glibcxx_can_increment we need to keep the debug 
layer to make sure we don't reach past-the-end iterator. So I 
had to remove usage of __niter_base when in Debug mode, doing so 
it also disable potential usage of __builtin_memcmp when calling 
std::equal on std::__cxx1998::vector<> iterators. A rather rare 
situation I think.


We don't need to give up all checks in std::equal, we can do this:

@@ -1044,7 +1085,13 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
   typename iterator_traits<_II1>::value_type,
   typename iterator_traits<_II2>::value_type>)
  __glibcxx_requires_valid_range(__first1, __last1);
-
+#ifdef _GLIBCXX_DEBUG
+  typedef typename iterator_traits<_II1>::iterator_category _Cat1;
+  typedef typename iterator_traits<_II2>::iterator_category _Cat2;
+  if (!__are_same<_Cat1, input_iterator_tag>::__value
+ && __are_same<_Cat2, random_access_iterator_tag>::__value)
+   __glibcxx_requires_can_increment_range(__first1, __last1, 
__first2);

+#endif
  return std::__equal_aux(std::__niter_base(__first1),
 std::__niter_base(__last1),
 std::__niter_base(__first2));


We don't give up any check.


We do for my version of the patch, because with the new __niter_base
overload the debug layer gets removed. Your patch kept the checking by
not removing the debug layer, but loses the memcmp optimization.

My suggestion above removes the debug layer so uses the optimization,
but adds a separate range check, so we still get checking as well.

We only give up on using the 
__builtin_memcmp when std::equal is being used while Debug mode is 
active and std::equal is called directly with std::__cxx1998::vector.


Moreover this check is wrong and will introduce regression when 
running testsuite in Debug mode (this is why I know). It will assert 
in the following case:

vector v1 { 0, 0, 0 };
vector v2 { 0, 1 };
equal(v1.begin(), v1.end(), v2.begin());


We should assert for that test, it's undefined behaviour.








    Note that I don't know how to test that __builtin_memmove 
has been indeed used. So I've been through some debug sessions 
to check that.


The attached patch (not fully tested) seems to be a much simpler way
to achieve the same thing. Instead of modifying all the helper
structs, just define a new function to re-wrap the result into the
desired iterator type.


diff --git a/libstdc++-v3/include/debug/stl_iterator.h 
b/libstdc++-v3/include/debug/stl_iterator.h

index a6a2a76..eca7203 100644
--- a/libstdc++-v3/include/debug/stl_iterator.h
+++ b/libstdc++-v3/include/debug/stl_iterator.h
@@ -120,4 +120,19 @@ namespace __gnu_debug
#endif
}

+#if __cplusplus >= 201103L
+namespace std
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+template
+    _Iterator
+    __niter_base(const __gnu_debug::_Safe_iterator<
+ __gnu_cxx::__normal_iterator<_Iterator, _Container>,
+ _Sequence>&);
+
+_GLIBCXX_END_NAMESPACE_VERSION
+}
+#endif


Why is this overload only defined for C++11 and later? I defined it
unconditionally in the attached patch.

What do you think?


Here's a complete patch that passes all tests in normal mode and
causes no regressions in debug mode (we already have some debug test
failing).

I wondered whether we need another overload of __wrap_iter for
handling move_iterator, but I think the first overload works OK.


I don't think we need it neither. Algos that handle move iterator are 
already doing it.


OK great.

Re: [PATCH/RFC] enable -Wstrict-prototypes (PR 82922)

[Joseph Myers]

On Mon, 25 Jun 2018, Martin Sebor wrote:

> Sure.  I think we could easily exempt most of the tests from
> diagnosing without compromising the efficacy of the warning
> by silently accepting definitions of () functions that take no
> arguments (and diagnosing calls to them that pass some).  What
> I think is important to preserve is diagnosing () declarations.

My general rule of thumb here is: if the function definitions / 
declarations / calls in question would be valid C++, with () interpreted 
as no arguments, warning by default is questionable.  If you have an 
old-style definition with arguments and no prior prototype, or a () 
declaration followed by a call or definition with arguments, warning by 
default is more reasonable.

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

Re: fix libcc1 dependencies in toplevel Makefile

[Olivier Hainque]

> On 26 Jun 2018, at 07:38, Alexandre Oliva  wrote:
> 
> Here's the patch I'll install if nobody objects in the next few days.
> Tested on x86_64-linux-gnu with a gcc bootstrap tree, a gcc
> non-bootstrap tree, and a binutils+gdb tree.

Thanks a lot for this Alex!

Re: [patch, fortran] Handling of .and. and .or. expressions

[Thomas Koenig]

Am 27.06.2018 um 21:15 schrieb Janne Blomqvist:


If the semantic model is unclear on whether a function with potential
side-effects might or might not be evaluated, then IMNSHO the semantic
model is shit, and should be fixed or replaced.


I disagree here, strongly. We are talking Fortran, and not C (where
everything is a function, and often the whole point of calling a
function is its side effects).

And we are not going to change Fortran semantics. And I also oppose
defining our own subset of Fortran in the hope that people will make
fewer mistakes.

A function is something that produces a value.  If the value is not
needed to produce the correct result, the function need not be called.

Regards

Thomas

Re: Limit Debug mode impact: overload __niter_base

[François Dumont]

On 27/06/2018 02:13, Jonathan Wakely wrote:

On 26/06/18 17:03 +0100, Jonathan Wakely wrote:

On 18/06/18 23:01 +0200, François Dumont wrote:

Hi

    I abandon the idea of providing Debug algos, it would be too 
much code to add and maintain. However I haven't quit on reducing 
Debug mode performance impact.


    So this patch make use of the existing std::__niter_base to get 
rid of the debug layer around __gnu_debug::vector<>::iterator so 
that __builtin_memmove replacement can take place.


    As _Safe_iterator<> do not have a constructor taking a pointer I 
change algos implementation so that we do not try to instantiate the 
iterator type ourselves but rather rely on its operators + or -.


    The small drawback is that for std::equal algo where we can't 
use the __glibcxx_can_increment we need to keep the debug layer to 
make sure we don't reach past-the-end iterator. So I had to remove 
usage of __niter_base when in Debug mode, doing so it also disable 
potential usage of __builtin_memcmp when calling std::equal on 
std::__cxx1998::vector<> iterators. A rather rare situation I think.


We don't need to give up all checks in std::equal, we can do this:

@@ -1044,7 +1085,13 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
   typename iterator_traits<_II1>::value_type,
   typename iterator_traits<_II2>::value_type>)
  __glibcxx_requires_valid_range(__first1, __last1);
-
+#ifdef _GLIBCXX_DEBUG
+  typedef typename iterator_traits<_II1>::iterator_category _Cat1;
+  typedef typename iterator_traits<_II2>::iterator_category _Cat2;
+  if (!__are_same<_Cat1, input_iterator_tag>::__value
+ && __are_same<_Cat2, random_access_iterator_tag>::__value)
+   __glibcxx_requires_can_increment_range(__first1, __last1, 
__first2);

+#endif
  return std::__equal_aux(std::__niter_base(__first1),
 std::__niter_base(__last1),
 std::__niter_base(__first2));


We don't give up any check. We only give up on using the 
__builtin_memcmp when std::equal is being used while Debug mode is 
active and std::equal is called directly with std::__cxx1998::vector.


Moreover this check is wrong and will introduce regression when running 
testsuite in Debug mode (this is why I know). It will assert in the 
following case:

vector v1 { 0, 0, 0 };
vector v2 { 0, 1 };
equal(v1.begin(), v1.end(), v2.begin());





    Note that I don't know how to test that __builtin_memmove has 
been indeed used. So I've been through some debug sessions to check 
that.


The attached patch (not fully tested) seems to be a much simpler way
to achieve the same thing. Instead of modifying all the helper
structs, just define a new function to re-wrap the result into the
desired iterator type.


diff --git a/libstdc++-v3/include/debug/stl_iterator.h 
b/libstdc++-v3/include/debug/stl_iterator.h

index a6a2a76..eca7203 100644
--- a/libstdc++-v3/include/debug/stl_iterator.h
+++ b/libstdc++-v3/include/debug/stl_iterator.h
@@ -120,4 +120,19 @@ namespace __gnu_debug
#endif
}

+#if __cplusplus >= 201103L
+namespace std
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+template
+    _Iterator
+    __niter_base(const __gnu_debug::_Safe_iterator<
+ __gnu_cxx::__normal_iterator<_Iterator, _Container>,
+ _Sequence>&);
+
+_GLIBCXX_END_NAMESPACE_VERSION
+}
+#endif


Why is this overload only defined for C++11 and later? I defined it
unconditionally in the attached patch.

What do you think?


Here's a complete patch that passes all tests in normal mode and
causes no regressions in debug mode (we already have some debug test
failing).

I wondered whether we need another overload of __wrap_iter for
handling move_iterator, but I think the first overload works OK.


I don't think we need it neither. Algos that handle move iterator are 
already doing it.


François

Re: [PATCH v3] add support for --disable-gcov

[Rainer Orth]

Hi Jeff,

>> So add an option for disabling build and install of libgcov and the
>> related host tools.
>> 
>> 2018-06-10  Rasmus Villemoes  
>> 
>> gcc/
>>  * configure.ac: Add --disable-gcov option.
>>  * configure: Regenerate.
>>  * Makefile.in: Honour @enable_gcov@.
>>  * doc/install.texi: Document --disable-gcov.
>> 
>> libgcc/
>>  * configure.ac: Add --disable-gcov option.
>>  * configure: Regenerate.
>>  * Makefile.in: Honour @enable_gcov@.
> OK.  Presumably you're going through the process to get write access.
> Once that's wrapped up you can install this patch.

this patch badly broke all -fprofile-generate/-fprofile-use tests in the
default case like this:

UNRESOLVED: g++.dg/bprob/g++-bprob-1.C compilation,  -O0  -fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-1.C compilation,  -O0  -fprofile-arcs

ld: fatal: library -lgcov: not found
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: g++.dg/bprob/g++-bprob-1.C compilation,  -g  -fprofile-arcs

libgcov.a is not copied over from libgcc to gcc due to a typo in
libgcc/Makefile.in.  Fixed as follows; will install as obvious once
bootstrap has finished.

Rainer

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


2018-06-27  Rainer Orth  

* Makefile.in (install_leaf): Use enable_gcov instead of
enable_libgcov.

# HG changeset patch
# Parent  5c87d0c29765b05d7da38622b0c67a4931fe47ce
Fix typo in Makefile.in

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -1168,7 +1168,7 @@ install-leaf: $(install-shared) $(instal
 	$(INSTALL_DATA) libgcc.a $(DESTDIR)$(inst_libdir)/
 	chmod 644 $(DESTDIR)$(inst_libdir)/libgcc.a
 	$(RANLIB) $(DESTDIR)$(inst_libdir)/libgcc.a
-ifeq ($(enable_libgcov),yes)
+ifeq ($(enable_gcov),yes)
 	$(INSTALL_DATA) libgcov.a $(DESTDIR)$(inst_libdir)/
 	chmod 644 $(DESTDIR)$(inst_libdir)/libgcov.a
 	$(RANLIB) $(DESTDIR)$(inst_libdir)/libgcov.a

Re: Limit Debug mode impact: overload __niter_base

[Jonathan Wakely]

On 27/06/18 21:03 +0200, François Dumont wrote:

On 26/06/2018 18:03, Jonathan Wakely wrote:

On 18/06/18 23:01 +0200, François Dumont wrote:

Hi

    I abandon the idea of providing Debug algos, it would be too 
much code to add and maintain. However I haven't quit on reducing 
Debug mode performance impact.


    So this patch make use of the existing std::__niter_base to 
get rid of the debug layer around __gnu_debug::vector<>::iterator 
so that __builtin_memmove replacement can take place.


    As _Safe_iterator<> do not have a constructor taking a pointer 
I change algos implementation so that we do not try to instantiate 
the iterator type ourselves but rather rely on its operators + or 
-.


    The small drawback is that for std::equal algo where we can't 
use the __glibcxx_can_increment we need to keep the debug layer to 
make sure we don't reach past-the-end iterator. So I had to remove 
usage of __niter_base when in Debug mode, doing so it also disable 
potential usage of __builtin_memcmp when calling std::equal on 
std::__cxx1998::vector<> iterators. A rather rare situation I 
think.


    Note that I don't know how to test that __builtin_memmove has 
been indeed used. So I've been through some debug sessions to 
check that.


The attached patch (not fully tested) seems to be a much simpler way
to achieve the same thing. Instead of modifying all the helper
structs, just define a new function to re-wrap the result into the
desired iterator type.


Through my proposal I tried to limit the presence of Debug code in the 
normal mode code. If you prefer to preserve existing code it is indeed 
a simpler approach.


But to avoid any dependency on _GLIBCXX_DEBUG you had to make more
changes in more places, and complicate all the helper structs.

If we really want to avoid the #ifdef _GLIBCXX_DEBUG code in
 we could move the debug mode overloads into
. I don't feel strongly about that, I think it's
OK in  and would be OK in the debug header too
(assuming it still works).


diff --git a/libstdc++-v3/include/debug/stl_iterator.h 
b/libstdc++-v3/include/debug/stl_iterator.h

index a6a2a76..eca7203 100644
--- a/libstdc++-v3/include/debug/stl_iterator.h
+++ b/libstdc++-v3/include/debug/stl_iterator.h
@@ -120,4 +120,19 @@ namespace __gnu_debug
#endif
}

+#if __cplusplus >= 201103L
+namespace std
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+template
+    _Iterator
+    __niter_base(const __gnu_debug::_Safe_iterator<
+ __gnu_cxx::__normal_iterator<_Iterator, _Container>,
+ _Sequence>&);
+
+_GLIBCXX_END_NAMESPACE_VERSION
+}
+#endif


Why is this overload only defined for C++11 and later? I defined it
unconditionally in the attached patch.


I initially wrote something like:
template
    inline auto
    __niter_base(const __gnu_debug::_Safe_iterator<_Iterator, 
_Container>& __it)

    -> decltype(__niter_base(__it.base()))
    { return __niter_base(__it.base()); }

which require C++11

I forgot to remove the __cplusplus check when I eventually use a more 
specific overload.


Ah OK, I wondered if there was some reason I had missed.




What do you think?


Yes, that is a fine approach. Do you wat to apply it or do you want me 
to work on it a little and re-submit the patch ?


I sent a follow-up with a complete patch that passes the testsuite.
I'm happy with that version of the patch, but do you have any
suggestions to improve it?

Re: [patch, fortran] Handling of .and. and .or. expressions

[Janne Blomqvist]

On Wed, Jun 27, 2018 at 8:26 PM, N.M. Maclaren  wrote:

> On Jun 27 2018, Janus Weil wrote:
>
>> What is so complicated about putting a statement into the Fortran
>> standard that says: "Ok, if this function has side effects, we
>> definitely must evaluate it, otherwise we lose the side effects. They
>> might be important."  ???
>>
>
> Because that would mean a complete redesign of Fortran's semantic model
> of execution.


If the semantic model is unclear on whether a function with potential
side-effects might or might not be evaluated, then IMNSHO the semantic
model is shit, and should be fixed or replaced.


> It would also NOT be what a lot of people want.


Huh? Who wants that? And why??


>   Inter
> alia, you would have to define what a side-effect is - and my point
> about IEEE 754 is very relevant here.
>

AFAIU most languages that take purity seriously, including in particular
Haskell, explicitly consider the IEEE exceptions outside the purity model.
Similarly, evaluating a pure expression might cause you to run out of
memory and the program is killed, which is most definitely a side-effect
but not one that is taken into account in the Haskell concept of purity.

I could certainly live with such compromises on purity, and I don't think
those examples are a good excuse to do nothing.


-- 
Janne Blomqvist

Re: [patch, fortran] Handling of .and. and .or. expressions

[Janne Blomqvist]

On Wed, Jun 27, 2018 at 7:46 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Wed, Jun 27, 2018 at 11:09:56AM +0300, Janne Blomqvist wrote:
> >
> > How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and
> then
> > check benchmark results (polyhedron, spec etc.)? If performance worsens,
> we
> > revert, if it improves, great, lets keep it?
> >
> > To clarify, I'm not objecting to using TRUTH_{AND|OR}_EXPR, I'm objecting
> > to the notion that this is somehow "more correct" or "less bad" than the
> > current short-circuiting. The Fortran standard does not specify an
> > evaluation strategy; IMHO very unfortunately, but it is what it is.
> >
>
> Benchmarks aren't going to prove anything unless the
> benchmarks have the specific construct under discuss.
>

What I'm saying is that as the Fortran standard doesn't specify exactly how
logical expressions are to be evaluated, we are free to use either
short-circuiting or non-short-circuiting (or choosing between them based on
the phase of the moon). While I'm sure we may produce synthetic benchmarks
to show either to be better [1], what matters is actual applications. Hence
we should check benchmarks based on actual applications, like polyhedron or
spec. Now, if this hypothetical patch has no impact on those benchmarks,
then, well, I don't have any particular opinion whether it should be kept.

[1] While obviously short-circuiting can avoid the evaluation of an
expensive function like in your example, a naive translation of
short-circuiting would produce more branches which aren't good either
(though I guess and hope the middle end can get rid of most of them). Thus
IMHO the decision should be based on the performance impact on real
applications.


-- 
Janne Blomqvist

Re: Limit Debug mode impact: overload __niter_base

[François Dumont]

On 26/06/2018 18:03, Jonathan Wakely wrote:

On 18/06/18 23:01 +0200, François Dumont wrote:

Hi

    I abandon the idea of providing Debug algos, it would be too much 
code to add and maintain. However I haven't quit on reducing Debug 
mode performance impact.


    So this patch make use of the existing std::__niter_base to get 
rid of the debug layer around __gnu_debug::vector<>::iterator so that 
__builtin_memmove replacement can take place.


    As _Safe_iterator<> do not have a constructor taking a pointer I 
change algos implementation so that we do not try to instantiate the 
iterator type ourselves but rather rely on its operators + or -.


    The small drawback is that for std::equal algo where we can't use 
the __glibcxx_can_increment we need to keep the debug layer to make 
sure we don't reach past-the-end iterator. So I had to remove usage 
of __niter_base when in Debug mode, doing so it also disable 
potential usage of __builtin_memcmp when calling std::equal on 
std::__cxx1998::vector<> iterators. A rather rare situation I think.


    Note that I don't know how to test that __builtin_memmove has 
been indeed used. So I've been through some debug sessions to check 
that.


The attached patch (not fully tested) seems to be a much simpler way
to achieve the same thing. Instead of modifying all the helper
structs, just define a new function to re-wrap the result into the
desired iterator type.


Through my proposal I tried to limit the presence of Debug code in the 
normal mode code. If you prefer to preserve existing code it is indeed a 
simpler approach.





diff --git a/libstdc++-v3/include/debug/stl_iterator.h 
b/libstdc++-v3/include/debug/stl_iterator.h

index a6a2a76..eca7203 100644
--- a/libstdc++-v3/include/debug/stl_iterator.h
+++ b/libstdc++-v3/include/debug/stl_iterator.h
@@ -120,4 +120,19 @@ namespace __gnu_debug
#endif
}

+#if __cplusplus >= 201103L
+namespace std
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+template
+    _Iterator
+    __niter_base(const __gnu_debug::_Safe_iterator<
+ __gnu_cxx::__normal_iterator<_Iterator, _Container>,
+ _Sequence>&);
+
+_GLIBCXX_END_NAMESPACE_VERSION
+}
+#endif


Why is this overload only defined for C++11 and later? I defined it
unconditionally in the attached patch.


I initially wrote something like:
template
    inline auto
    __niter_base(const __gnu_debug::_Safe_iterator<_Iterator, 
_Container>& __it)

    -> decltype(__niter_base(__it.base()))
    { return __niter_base(__it.base()); }

which require C++11

I forgot to remove the __cplusplus check when I eventually use a more 
specific overload.




What do you think?


Yes, that is a fine approach. Do you wat to apply it or do you want me 
to work on it a little and re-submit the patch ?


François

Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)

[Eric Gallager]

On 6/26/18, Martin Sebor  wrote:
> With the exception of built-ins with the ellipsis (like sprintf),
> GCC silently accepts declarations of built-in functions without
> prototypes as well as calls to such functions with any numbers
> or types of arguments, compatible or otherwise.  Calls with
> arguments whose number and types match exactly those of
> the built-in are considered by the middle-end for optimization.
> Other calls (compatible or not, irrespective of whether their
> number matches the number expected by the function) are then
> made to the library functions.
>
> Attached is a small fix to -Wbuiltin-declaration-mismatch to
> have it diagnose built-in declarations without a prototype.
> The warning is enabled by default so it causes a fair number
> of tests to fail because of declarations like 'void abort();'
> The breakdown of the built-ins behind the test failures is
> below.
>
> Before I take the time to clean up the test suite let me post
> what I have in case going this route is not acceptable.  As
> an alternative, I could try to avoid some of these warnings,
> e.g., by diagnosing incompatible calls instead but I think
> it's even less worthwhile for built-ins than trying to do
> it for ordinary functions with -Wstrict-prototypes.  There
> is, in my view, no justification today for standard functions
> to be declared without a prototype.  (I could also make
> the warning depend on language mode and -Wpedantic if that
> were more preferable.)
>
> Martin
>
> About 115 tests fail due to incompatible declarations of
> the built-in functions below (the number shows the number
> of warnings for each functions):
>
> 428   abort
>   58   exit
>   36   memcpy
>   17   memmove
>   15   realloc
>   14   cabs
>5   strncpy
>4   strcmp
>3   alloca
>2   rindex
>1   aligned_alloc
>

Could you do something to differentiate it a bit more from the
-Wshadow warning that is also touched in this patch? It'd be kind of
annoying to get warnings from both flags for the same code...

Re: [PATCH] Backport testsuite: Introduce be/le selectors

[Jeff Law]

On 06/27/2018 10:01 AM, Kelvin Nilsen wrote:
> Hi Jeff,
> 
> Is it ok to backport this patch to gcc 8?  There are other backports of test 
> programs that would like to use the new selector options.
Sure.
jeff

[committed] [3/3] Converting the v850 port away from cc0 -- add flag setting patterns

[Jeff Law]

This is strictly an optimization patch.  It adds flag setting variants
of key arithmetic, logical, extensions, shifts, etc.  That in turn
allows the compare-elim pass to do its job.

At this point the v8 port is converted and should be functioning at the
same level it was before the conversion.  As I noted in the cover
message, there are some further things that could be improved, the only
one I plan to look at is conversion to LRA.

Committed to the trunk.

Jeff
* config/v850/v850.md (addsi3_set_flags): New pattern.
(subsi3_set_flags, negsi2_set_flags, andsi3_set_flags): Likewise.
(iorsi3_set_flags, xorsi3_set_flags, one_cmplsi2_set_flags): Likewise.
(zero_extendhisi2_v850_set_flags): Likewise.
(zero_extendqisi2_v850_set_flags): Likewise.
(ashlsi3_set_flags, ashlsi3_v850e2_set_flags): Likewise.
(lshrsi3_set_flags, lshrsi3_v850e2_set_flags): Likewise.
(ashrsi3_set_flags, ashrsi3_v850e2_set_flags): Likewise.


diff --git a/gcc/config/v850/v850.md b/gcc/config/v850/v850.md
index 3cfec74..b8f098b 100644
--- a/gcc/config/v850/v850.md
+++ b/gcc/config/v850/v850.md
@@ -569,6 +569,20 @@
addi %O2(%P2),%1,%0"
   [(set_attr "length" "2,4,4")])
 
+(define_insn "addsi3_set_flags"
+  [(set (reg:CCNZ CC_REGNUM)
+   (compare:CCNZ (plus:SI (match_operand:SI 1 "register_operand" "%0,r,r")
+  (match_operand:SI 2 "nonmemory_operand" 
"rJ,K,U"))
+   (const_int 0)))
+   (set (match_operand:SI 0 "register_operand" "=r,r,r")
+   (plus:SI (match_dup 1) (match_dup 2)))]
+  "reload_completed"
+  "@
+   add %2,%0
+   addi %2,%1,%0
+   addi %O2(%P2),%1,%0"
+  [(set_attr "length" "2,4,4")])
+
 ;; --
 ;; SUBTRACT INSTRUCTIONS
 ;; --
@@ -593,6 +607,19 @@
   subr %1,%0"
   [(set_attr "length" "2,2")])
 
+(define_insn "*subsi3_set_flags"
+  [(set (reg:CCNZ CC_REGNUM)
+   (compare:CCNZ (minus:SI (match_operand:SI 1 "register_operand" "0,r")
+   (match_operand:SI 2 "nonmemory_operand" "r,0"))
+   (const_int 0)))
+   (set (match_operand:SI 0 "register_operand" "=r,r")
+   (minus:SI (match_dup 1) (match_dup 2)))]
+  "reload_completed"
+  "@
+  sub %2,%0
+  subr %1,%0"
+  [(set_attr "length" "2,2")])
+
 (define_insn_and_split "negsi2"
   [(set (match_operand:SI 0 "register_operand" "=r")
(neg:SI (match_operand:SI 1 "register_operand" "0")))]
@@ -610,6 +637,16 @@
   "subr %.,%0"
   [(set_attr "length" "2")])
 
+(define_insn "*negsi2_set_flags"
+  [(set (reg:CCNZ CC_REGNUM)
+   (compare:CCNZ (neg:SI (match_operand:SI 1 "register_operand" "0"))
+ (const_int 0)))
+   (set (match_operand:SI 0 "register_operand" "=r")
+   (neg:SI (match_dup 1)))]
+  "reload_completed"
+  "subr %.,%0"
+  [(set_attr "length" "2")])
+
 ;; --
 ;; MULTIPLY INSTRUCTIONS
 ;; --
@@ -831,6 +868,20 @@
   andi %2,%1,%0"
   [(set_attr "length" "2,2,4")])
 
+(define_insn "andsi3_set_flags"
+  [(set (reg:CC CC_REGNUM)
+   (compare:CC (and:SI (match_operand:SI 1 "register_operand" "%0,0,r")
+   (match_operand:SI 2 "nonmemory_operand" "r,I,M"))
+   (const_int 0)))
+   (set (match_operand:SI 0 "register_operand" "=r,r,r")
+   (and:SI (match_dup 1) (match_dup 2)))]
+  "reload_completed"
+  "@
+  and %2,%0
+  and %.,%0
+  andi %2,%1,%0"
+  [(set_attr "length" "2,2,4")])
+
 ;; --
 ;; OR INSTRUCTIONS
 ;; --
@@ -916,6 +967,20 @@
   ori %2,%1,%0"
   [(set_attr "length" "2,2,4")])
 
+(define_insn "*iorsi3_set_flags"
+  [(set (reg:CC CC_REGNUM)
+   (compare:CC (ior:SI (match_operand:SI 1 "register_operand" "%0,0,r")
+   (match_operand:SI 2 "nonmemory_operand" "r,I,M"))
+   (const_int 0)))
+   (set (match_operand:SI 0 "register_operand" "=r,r,r")
+   (ior:SI (match_dup 1) (match_dup 2)))]
+  "reload_completed"
+  "@
+  or %2,%0
+  or %.,%0
+  ori %2,%1,%0"
+  [(set_attr "length" "2,2,4")])
+
 ;; --
 ;; XOR INSTRUCTIONS
 ;; --
@@ -1001,6 +1066,20 @@
   xori %2,%1,%0"
   [(set_attr "length" "2,2,4")])
 
+(define_insn "*xorsi3_set_flags"
+  [(set (reg:CC CC_REGNUM)
+   (compare:CC (xor:SI (match_operand:SI 1 "register_operand" "%0,0,r")
+   (match_operand:SI 2 "nonmemory_operand" "r,I,M"))
+   (const_int 0)))
+   (set (match_operand:SI 0 "register_operand" "=r,r,r")
+   (xor:SI (match_dup 1) (match_dup 2)))]
+  

[committed] [2/3] Converting the v850 port away from cc0 -- basic support for new scheme

[Jeff Law]

This is the bulk of the changes.  With this change in installed the v850
port should be using the new mechanism for condition code handling
consistently, though without optimizing well.

This is a fairly large change which hits a great many patterns.

It's largely what one would expect.  THe comparison/branch are kept
together as a unit prior to reload, but split post-reload.  Similarly
for things like conditional moves and tst insns.  Clobbers get added to
several patterns that were missing them.

One of the interesting v8 tidbits is that it was already using the new
style for its floating point comparisons & branches.  We actually get to
simplify that a bit because we no longer need special branching patterns
(FP comparison initially are stored in FCC, then get copied into the Z
bit of CC_REG, then we use standard bz/bnz insns).

This commit should work independently of #3 as #3 strictly adds flags
setting variants of arithmetic, logicals and other patterns.  But I
haven't tested that extensively.

Jeff
* config/v850/v850-protos.h (notice_update_cc): Remove.
* config/v850/v850.c (v850_compare_op0, v850_compare_op1): Remove.
(v850_print_operand): Handle 'D' and "d".
(v850_select_cc_mode): Remove ATTRIBUTE_UNUSED for last argument.
Add handling of arithmetic/logical operations compared against zero.
(v850_gen_float_compare): Remove ATTRIBUTE_UNUSED for last argument.
Do not look at v850_compare_op, instead get mode from last argument.
(v850_gen_compare): Remove
(increment_stack): Use addsi3_clobber_flags to avoid splitting failure
after reload for prologue insns.
(expand_prologue): Account for CLOBBER of CC_REGNUM in various
patterns.
(construct_save_jarl): Likewise.
(TARGET_FLAGS_REGNUM): Define.
* config/v850/v850.h (v850_compare_op0, v850_compare_op1): Remove.
(NOTICE_UPDATE_CC): Remove.
* config/v850/v850.md (v850_tst1): Use (reg:CCZ CC_REGNUM) rather
than cc0.  Conditionalize on reload_completed.
(cmpsi_insn, setfcc_insn): Likewise.
(tst1 splitter): Turn into define_and_split which sets the flags
after reload.
(cstoresi4, cbranchsf4, cbranchdf4, cbranchsi4_insn): Likewise.
(cbranchsi4, branch_normal, branch_invert): Do not expose cc0 here.
(cstoresf4, cstoredf4): Clobber the flags.
(cmpsi, cmpsf, cmpdf): Remove expanders.
(setf_insn): Remove pattern.
(addsi3): Turn into define_and_split which clobbers the flags after
reload and a suitable pattern (addsi3_clobber_flags) for use after
reload.
(subsi3, negsi2, andsi3, iorsi3, xorsi3, one_cmplsi2) Likewise.
(ashlsi3, ashlsi3_v850e2, lshrsi3, lsh4si3_v850e2): Likewise.
(ashrsi3, ashrsi3_v850e2): Likewise.
(bins): Clobber the flags.
(movsicc_normal_cc, movsicc_normal, movsicc_tst1): Likewise.
(movsicc_tst1_revesed, sasf, swap and rotate patterns): Likewise.
(fix_loop_counter, call_internal_short, call_internal_long): Likewise.
(call_value_internal_short, call_value_internal_long): Likewise.
(callt_save_interrupt, callt_return_interrupt): Likewise.
(save_interrupt, return_interrupt): Likewise.
(callt_save_all_interrupt, save_all_interrupt): Likewise.
(_save_all_interrupt, callt_restore_all_interrupt): Likewise.
(restore_all_interrupt, _restore_all_interrupt): Likewise.
(All FP comparisons): Only allow after reload has completed.
(trfsr): Likewise.
(divh, divhu): Tweak output template.
(branch_z_normal, branch_z_invert): Remove
(branch_nz_normal, branch_nz_invert): Likewise.
(extendhisi_insn, extendqisi_insn): Do not clobber flags.


diff --git a/gcc/config/v850/v850-protos.h b/gcc/config/v850/v850-protos.h
index e8ff280..ca99703 100644
--- a/gcc/config/v850/v850-protos.h
+++ b/gcc/config/v850/v850-protos.h
@@ -32,7 +32,6 @@ extern void   v850_init_expanders   (void);
 #ifdef RTX_CODE
 extern rtxv850_return_addr  (int);
 extern const char *output_move_single   (rtx *);
-extern void   notice_update_cc  (rtx, rtx_insn *);
 extern char * construct_save_jarl   (rtx);
 extern char * construct_restore_jr  (rtx);
 #ifdef HAVE_MACHINE_MODES
diff --git a/gcc/config/v850/v850.c b/gcc/config/v850/v850.c
index e184718..cb2debf 100644
--- a/gcc/config/v850/v850.c
+++ b/gcc/config/v850/v850.c
@@ -68,8 +68,6 @@ data_area_stack_element * data_area_stack = NULL;
function is an interrupt handler.  */
 static int v850_interrupt_cache_p = FALSE;
 
-rtx v850_compare_op0, v850_compare_op1;
-
 /* Whether current function is an interrupt handler.  */
 static int v850_interrupt_p = FALSE;
 
@@ -418,7 +416,9 @@ v850_print_operand (FILE * file, rtx x, int code)
 case 'b':
 case 'B':
 case 'C':
-  switch ((code == 'B' || code 

[committed] [1/3] Converting the v850 port away from cc0 -- removing most of cc0 handling

[Jeff Law]

This is a fairly mechanical change -- it removes a large amount of the
cc0 machinery, but not all of it.  It's not really meant to stand
independently of the subsequent changes.  I've broken it out merely to
aid anyone who perhaps wants to see the more significant changes in
subsequent patches without the noise of all the mechanical stuff.

This also fixes a number of trivial style nits in v850.md.

While I have built gcc, libgcc and newlib with this change, again, it's
not really meant to be used independently.

Jeff
* config/v850/v850-modes.def (CCZ, CCNZ): Add new modes.
* config/v850/v850.c (notice_update_cc): Remove.
* config/v850/v850.h  (CC_OVERFLOW_UNUSABLE): Remove
(CC_NO_CARRY): Likewise.
(NOTICE_UPDATE_CC): Define to nothing.
* config/v850/v850.md: Remove block comment on cc0 handling
Remove "cc" attribute from all patterns.  Remove cc_status handling
from all patterns.  Minor formatting fixes.


diff --git a/gcc/config/v850/v850-modes.def b/gcc/config/v850/v850-modes.def
index ed37c79..5503d6a 100644
--- a/gcc/config/v850/v850-modes.def
+++ b/gcc/config/v850/v850-modes.def
@@ -18,6 +18,8 @@
along with GCC; see the file COPYING3.  If not see
.  */
 
+CC_MODE (CCZ);
+CC_MODE (CCNZ);
 CC_MODE (CC_FPU_LT);
 CC_MODE (CC_FPU_LE);
 CC_MODE (CC_FPU_GT);
diff --git a/gcc/config/v850/v850.c b/gcc/config/v850/v850.c
index 720cce8..e184718 100644
--- a/gcc/config/v850/v850.c
+++ b/gcc/config/v850/v850.c
@@ -1985,55 +1985,6 @@ expand_epilogue (void)
   v850_interrupt_p = FALSE;
 }
 
-/* Update the condition code from the insn.  */
-void
-notice_update_cc (rtx body, rtx_insn *insn)
-{
-  switch (get_attr_cc (insn))
-{
-case CC_NONE:
-  /* Insn does not affect CC at all.  */
-  break;
-
-case CC_NONE_0HIT:
-  /* Insn does not change CC, but the 0'th operand has been changed.  */
-  if (cc_status.value1 != 0
- && reg_overlap_mentioned_p (recog_data.operand[0], cc_status.value1))
-   cc_status.value1 = 0;
-  break;
-
-case CC_SET_ZN:
-  /* Insn sets the Z,N flags of CC to recog_data.operand[0].
-V,C is in an unusable state.  */
-  CC_STATUS_INIT;
-  cc_status.flags |= CC_OVERFLOW_UNUSABLE | CC_NO_CARRY;
-  cc_status.value1 = recog_data.operand[0];
-  break;
-
-case CC_SET_ZNV:
-  /* Insn sets the Z,N,V flags of CC to recog_data.operand[0].
-C is in an unusable state.  */
-  CC_STATUS_INIT;
-  cc_status.flags |= CC_NO_CARRY;
-  cc_status.value1 = recog_data.operand[0];
-  break;
-
-case CC_COMPARE:
-  /* The insn is a compare instruction.  */
-  CC_STATUS_INIT;
-  cc_status.value1 = SET_SRC (body);
-  break;
-
-case CC_CLOBBER:
-  /* Insn doesn't leave CC in a usable state.  */
-  CC_STATUS_INIT;
-  break;
-
-default:
-  break;
-}
-}
-
 /* Retrieve the data area that has been chosen for the given decl.  */
 
 v850_data_area
diff --git a/gcc/config/v850/v850.h b/gcc/config/v850/v850.h
index 2e737a8..96bddc2 100644
--- a/gcc/config/v850/v850.h
+++ b/gcc/config/v850/v850.h
@@ -567,19 +567,7 @@ struct cum_arg { int nbytes; };
 
 #define SELECT_CC_MODE(OP, X, Y)   v850_select_cc_mode (OP, X, Y)
 
-/* Tell final.c how to eliminate redundant test instructions.  */
-
-/* Here we define machine-dependent flags and fields in cc_status
-   (see `conditions.h').  No extra ones are needed for the VAX.  */
-
-/* Store in cc_status the expressions
-   that the condition codes will describe
-   after execution of an instruction whose pattern is EXP.
-   Do not alter them if the instruction would not alter the cc's.  */
-
-#define CC_OVERFLOW_UNUSABLE 0x200
-#define CC_NO_CARRY CC_NO_OVERFLOW
-#define NOTICE_UPDATE_CC(EXP, INSN) notice_update_cc(EXP, INSN)
+#define NOTICE_UPDATE_CC(EXP, INSN)
 
 /* Nonzero if access to memory by bytes or half words is no faster
than accessing full words.  */
diff --git a/gcc/config/v850/v850.md b/gcc/config/v850/v850.md
index 67d9063..0fad9ea 100644
--- a/gcc/config/v850/v850.md
+++ b/gcc/config/v850/v850.md
@@ -81,17 +81,6 @@
 (const_string "v850e3v5")]  
 (const_string "none")))
 
-;; Condition code settings.
-;; none - insn does not affect cc
-;; none_0hit - insn does not affect cc but it does modify operand 0
-;; This attribute is used to keep track of when operand 0 changes.
-;; See the description of NOTICE_UPDATE_CC for more info.
-;; set_znv - sets z,n,v to usable values; c is unknown.
-;; set_zn  - sets z,n to usable values; v,c is unknown.
-;; compare - compare instruction
-;; clobber - value of cc is unknown
-(define_attr "cc" "none,none_0hit,set_z,set_zn,set_znv,compare,clobber"
-  (const_string "clobber"))
 
 ;; Function units for the V850.  As best as I can tell, there's
 ;; a traditional memory load/use stall as well as a stall if
@@ -120,8 +109,7 @@
 (match_operand 

[PATCH] C++: don't offer bogus "._0" suggestions (PR c++/86329)

[David Malcolm]

PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:

#include 

int compare()
{
  return __n1 - __n2;
}

suggested.cc: In function 'int compare()':
suggested.cc:5:10: error: '__n1' was not declared in this scope
   return __n1 - __n2;
  ^~~~
suggested.cc:5:10: note: suggested alternative: '._61'
   return __n1 - __n2;
  ^~~~
  ._61
suggested.cc:5:17: error: '__n2' was not declared in this scope
   return __n1 - __n2;
 ^~~~
suggested.cc:5:17: note: suggested alternative: '._72'
   return __n1 - __n2;
 ^~~~
 ._72

The dot-prefixed names are an implementation detail of how we implement
anonymous enums found in the header files, generated via
anon_aggrname_format in make_anon_name.

This patch uses anon_aggrname_p to filter them out when considering
which names to suggest.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
adds 9 PASS results to g++.sum

OK for trunk, gcc-8, gcc-7 branches?

gcc/cp/ChangeLog:
PR c++/86329
* name-lookup.c (consider_binding_level): Filter out names that
match anon_aggrname_p.

gcc/testsuite/ChangeLog:
PR c++/86329
* g++.dg/lookup/pr86329.C: New test.
---
 gcc/cp/name-lookup.c  |  5 +
 gcc/testsuite/g++.dg/lookup/pr86329.C | 11 +++
 2 files changed, 16 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/lookup/pr86329.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index a30c374..6ec4e6e 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -5786,6 +5786,11 @@ consider_binding_level (tree name, best_match  ,
   if (!suggestion)
continue;
 
+  /* Don't suggest names that are for anonymous aggregate types, as
+they are an implementation detail generated by the compiler.  */
+  if (anon_aggrname_p (suggestion))
+   continue;
+
   const char *suggestion_str = IDENTIFIER_POINTER (suggestion);
 
   /* Ignore internal names with spaces in them.  */
diff --git a/gcc/testsuite/g++.dg/lookup/pr86329.C 
b/gcc/testsuite/g++.dg/lookup/pr86329.C
new file mode 100644
index 000..fc091ba
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/pr86329.C
@@ -0,0 +1,11 @@
+/* PR c++/86329: ensure we don't erroneously offer suggestions like "._0",
+   which are an implementation detail of how e.g. anonymous enums are
+   handled internally.  */
+   
+enum {NONEMPTY};
+
+int test()
+{
+  return __0; // { dg-error "'__0' was not declared in this scope" }
+  // { dg-bogus "suggested alternative" "" { target *-*-* } .-1 }
+}
-- 
1.8.5.3

Re: C++ PATCHes for c++/82882, ICE with lambda in template default argument

[Jason Merrill]

On Fri, Jun 15, 2018 at 4:21 PM, Jason Merrill  wrote:
> This testcase was broken by the lambda rewrite.  This turned out to be
> because the lambda in the template's default argument had namespace
> scope, while the instantiation had function scope, because of
> tsubst_default_argument calling push_access_scope and do_pushtag using
> the resulting value of current_function_decl.
>
> The fix is to teach do_pushtag to do better.  For GCC 8 I'm applying a
> focused patch that just recognizes when we're trying to give a lambda
> a function scope we aren't actually in.  This re-broke bug 59949, so
> to avoid that I needed to fix tsubst_lambda_expr to use and update the
> discriminator for global lambda scope when the template lambda has no
> extra scope.
>
> Looking at do_pushtag led me to wonder why we were relying on
> current_* for the scope in the first place; since we're going to add
> the tag to current_binding_level, we should get the scope from there
> as well.  Making that change revealed a few more issues:
>
> * With a lambda in a default argument, we would frequently be in the
> binding_level for the calling function.  Fixed by calling
> push_to_top_level.
> * Redeclarations of C++11 enums with specified underlying type were
> getting pushed into an arbitrary binding level.  Fixed by removing the
> unnecessary permissiveness around such redeclarations with underlying
> types that are not template-equivalent, so a redeclaration isn't
> pushed anywhere.
> * Lambdas in default member initializers were also getting pushed into
> an arbitrary binding level, due to the code for allowing type
> definition in a compound literal in a static data member initializer.
> Fixed by no longer looking through the binding_level for a complete
> class, but instead not pushing the tag anywhere if the class is
> complete; a lambda type isn't found by name anyway.

One more: looking through one class binding level then stopped at its
enclosing template parms level even if that's still inside another
class binding level.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit fa24a18a557cc0f7a7cb42416b0150a4847916c6
Author: Jason Merrill 
Date:   Wed Jun 27 12:25:07 2018 -0400

Avoid crash on friend in nested class template.

* name-lookup.c (do_pushtag): If we skip a class level, also skip
its template level.

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index a30c37428ad..e0500d83071 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -6509,20 +6509,30 @@ do_pushtag (tree name, tree type, tag_scope scope)
   tree decl;
 
   cp_binding_level *b = current_binding_level;
-  while (/* Cleanup scopes are not scopes from the point of view of
-	the language.  */
-	 b->kind == sk_cleanup
-	 /* Neither are function parameter scopes.  */
-	 || b->kind == sk_function_parms
-	 /* Neither are the scopes used to hold template parameters
-	for an explicit specialization.  For an ordinary template
-	declaration, these scopes are not scopes from the point of
-	view of the language.  */
-	 || (b->kind == sk_template_parms
-	 && (b->explicit_spec_p || scope == ts_global))
-	 || (b->kind == sk_class
-	 && scope != ts_current))
-b = b->level_chain;
+  while (true)
+{
+  if (/* Cleanup scopes are not scopes from the point of view of
+	 the language.  */
+	  b->kind == sk_cleanup
+	  /* Neither are function parameter scopes.  */
+	  || b->kind == sk_function_parms
+	  /* Neither are the scopes used to hold template parameters
+	 for an explicit specialization.  For an ordinary template
+	 declaration, these scopes are not scopes from the point of
+	 view of the language.  */
+	  || (b->kind == sk_template_parms
+	  && (b->explicit_spec_p || scope == ts_global)))
+	b = b->level_chain;
+  else if (b->kind == sk_class
+	   && scope != ts_current)
+	{
+	  b = b->level_chain;
+	  if (b->kind == sk_template_parms)
+	b = b->level_chain;
+	}
+  else
+	break;
+}
 
   gcc_assert (identifier_p (name));
 
diff --git a/gcc/testsuite/g++.dg/template/friend66.C b/gcc/testsuite/g++.dg/template/friend66.C
new file mode 100644
index 000..f8c95f844b3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/friend66.C
@@ -0,0 +1,9 @@
+template 
+struct A
+{
+  template 
+  struct B
+  {
+friend struct C;
+  };
+};
diff --git a/gcc/testsuite/g++.old-deja/g++.law/visibility13.C b/gcc/testsuite/g++.old-deja/g++.law/visibility13.C
index 025b0b1ef54..451ef1afaf8 100644
--- a/gcc/testsuite/g++.old-deja/g++.law/visibility13.C
+++ b/gcc/testsuite/g++.old-deja/g++.law/visibility13.C
@@ -15,9 +15,11 @@ using namespace std;
 
 const int ArraySize = 12;
 
+template  class Array_RC;
+
 template 
-class Array { // { dg-error "" } .struct Array_RC redecl.*
-friend class Array_RC;
+class Array {
+  friend class Array_RC;
 public:
 Array(const Type *ar, int sz) { init(ar,sz); }
 virtual ~Array() { delete [] ia; }
@@ -76,8 +78,8 @@ 

Re: [patch, fortran] Handling of .and. and .or. expressions

[N.M. Maclaren]

On Jun 27 2018, Janus Weil wrote:


I'm not completely sure what you deduce from all these quoted
paragraphs, but applied to the cases we're discussing here, e.g.

A = .false. .and. my_boldly_impure_function()

I read them as saying that a compiler does not have to invoke the
function if it doesn't feel like it, but with no definite obligation
to remove the call either. Do you agree?


Yes.


it's one of the few places in
Fortran where there are conforming constructs that do not have specified
semantics or at least a clearly specified intention.


And I really wonder why one would do such a thing. Like, ever.

I'm curious: Are there actually other such cases in Fortran that
you're aware of?


Yes.  Some in the I/O area, where every language has problems, because
systems vary so much in their basic models.  Some in the coarray area,
especially atomics.  And a few others that I now forget where.  I would
have to search my files (and memory!) to remind myself of exactly which
issues I was referring to, even in the areas that I can remember have
such issues.  But see below.

Where impure functions are different is because the others are all either
in extreme cases or in areas that everybody knows are iffy.  You can
avoid all of them (including the impure function ones) except a few of
the I/O ones by writing in a highly disciplined fashion - which is the
key to high RAS, and portability over long periods of time and wildly
different systems.

Many, many people have tried to sort that out, and all have failed 
dismally. I regret that the proposal to deprecate impure functions did 
not succeed, because at least that would have made one sane direction 
clear.


I don't know. Why do so many people in the Fortran community have such
a big problem with functions? Ok, they haven't been around in 77, but
if you even bother to introduce them, why do it so half-heartedly and
not just embrace them in their full beauty?


Er, functions have been present in Fortran since 1958, and wording with
similar effects to the current wording since 1966.  This is an OLD
problem :-(


What is so complicated about putting a statement into the Fortran
standard that says: "Ok, if this function has side effects, we
definitely must evaluate it, otherwise we lose the side effects. They
might be important."  ???


Because that would mean a complete redesign of Fortran's semantic model
of execution.  It would also NOT be what a lot of people want.  Inter
alia, you would have to define what a side-effect is - and my point
about IEEE 754 is very relevant here.

Look on the bright side. If you thought this problem is a mess (it is), 
I can assure you that most other languages get it far, far worse - often 
with logically impossible or contradictory promises and requirements.


I don't quite see that. Which languages are you talking about
specifically? I see that C/C++ gives you a nice choice of writing

A = false & my_boldly_impure_function()
or
A = false && my_boldly_impure_function()

where the first option guarantees that your function is evaluated,
while the second one allows (or even demands?) it to be optimized
away. That's a much clearer situation than the Fortran mess, isn't it?


Demands.  But I can assure you that things are NOT that simple, and
C and C++ were among the languages I was referring to.  I could go
into horrible detail, but this is not the place to do that.  And, no,
the problems are not where you probably think they are.

I never counted them up, but my estimate was that they were at least
ten times as numerous and serious as for Fortran and, worse, they could
NOT be avoided even in very clean code.  I base this on being involved
with the standards, personal experience of writing highly-portable code,
and experience of being the local expert of last resort in the languages.


Regards,
Nick Maclaren.

C++ PATCH for c++/57891, narrowing conversions in non-type template arguments

[Marek Polacek]

This PR complains about us accepting invalid code like

  template struct A {};
  A<-1> a;

Where we should detect the narrowing: [temp.arg.nontype] says
"A template-argument for a non-type template-parameter shall be a converted
constant expression ([expr.const]) of the type of the template-parameter."
and a converted constant expression can contain only
- integral conversions other than narrowing conversions,
- [...]."
It spurred e.g.

and has >=3 dups so it has some visibility.

I think build_converted_constant_expr needs to set check_narrowing.
check_narrowing also always mentions that it's in { } but that is no longer
true; in the future it will also apply to <=>.  We'd probably have to add a new
flag to struct conversion if wanted to distinguish between these.

This does not yet fix detecting narrowing in function templates (78244).

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

2018-06-27  Marek Polacek  

PR c++/57891
* call.c (build_converted_constant_expr): Set check_narrowing.
* decl.c (compute_array_index_type): Add warning sentinel.  Use
input_location.
* pt.c (convert_nontype_argument): Return NULL_TREE if any errors
were reported.
* typeck2.c (check_narrowing): Don't mention { } in diagnostic.

* g++.dg/cpp0x/Wnarrowing6.C: New test.
* g++.dg/cpp0x/Wnarrowing7.C: New test.
* g++.dg/cpp0x/Wnarrowing8.C: New test.
* g++.dg/cpp0x/constexpr-data2.C: Add dg-error.
* g++.dg/init/new43.C: Adjust dg-error.
* g++.dg/other/fold1.C: Likewise.
* g++.dg/parse/array-size2.C: Likewise.
* g++.dg/other/vrp1.C: Add dg-error.
* g++.dg/template/char1.C: Likewise.
* g++.dg/ext/builtin12.C: Likewise.
* g++.dg/template/dependent-name3.C: Adjust dg-error.

diff --git gcc/cp/call.c gcc/cp/call.c
index 209c1fd2f0e..956c7b149dc 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -4152,7 +4152,10 @@ build_converted_constant_expr (tree type, tree expr, 
tsubst_flags_t complain)
 }
 
   if (conv)
-expr = convert_like (conv, expr, complain);
+{
+  conv->check_narrowing = !processing_template_decl;
+  expr = convert_like (conv, expr, complain);
+}
   else
 expr = error_mark_node;
 
diff --git gcc/cp/decl.c gcc/cp/decl.c
index c04b9b7d457..8da63fa2aaa 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -9508,6 +9508,8 @@ compute_array_index_type (tree name, tree size, 
tsubst_flags_t complain)
   else
{
  size = instantiate_non_dependent_expr_sfinae (size, complain);
+ /* Don't warn about narrowing for VLAs.  */
+ warning_sentinel s (warn_narrowing, !TREE_CONSTANT (osize));
  size = build_converted_constant_expr (size_type_node, size, complain);
  size = maybe_constant_value (size);
 
@@ -9556,7 +9558,7 @@ compute_array_index_type (tree name, tree size, 
tsubst_flags_t complain)
 {
   tree folded = cp_fully_fold (size);
   if (TREE_CODE (folded) == INTEGER_CST)
-   pedwarn (location_of (size), OPT_Wpedantic,
+   pedwarn (input_location, OPT_Wpedantic,
 "size of array is not an integral constant-expression");
   /* Use the folded result for VLAs, too; it will have resolved
 SIZEOF_EXPR.  */
diff --git gcc/cp/pt.c gcc/cp/pt.c
index 3780f3492aa..12d1a1e1cd3 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -6669,9 +6669,10 @@ convert_nontype_argument (tree type, tree expr, 
tsubst_flags_t complain)
  /* C++17: A template-argument for a non-type template-parameter shall
 be a converted constant expression (8.20) of the type of the
 template-parameter.  */
+ int errs = errorcount;
  expr = build_converted_constant_expr (type, expr, complain);
  if (expr == error_mark_node)
-   return error_mark_node;
+   return errorcount > errs ? NULL_TREE : error_mark_node;
  expr = maybe_constant_value (expr);
  expr = convert_from_reference (expr);
}
diff --git gcc/cp/typeck2.c gcc/cp/typeck2.c
index 91aa5a62856..d82e3b608da 100644
--- gcc/cp/typeck2.c
+++ gcc/cp/typeck2.c
@@ -875,7 +875,8 @@ store_init_value (tree decl, tree init, vec** 
cleanups, int flags)
 }
 
 
-/* Give diagnostic about narrowing conversions within { }.  */
+/* Give diagnostic about narrowing conversions within { }, or as part of
+   a converted constant expression.  */
 
 bool
 check_narrowing (tree type, tree init, tsubst_flags_t complain)
@@ -967,7 +968,7 @@ check_narrowing (tree type, tree init, tsubst_flags_t 
complain)
{
  if (complain & tf_warning)
warning_at (loc, OPT_Wnarrowing, "narrowing conversion of %qE "
-   "from %qH to %qI inside { } is ill-formed in C++11",
+   "from %qH to %qI is ill-formed in C++11",

Re: [patch, fortran] Handling of .and. and .or. expressions

[Steve Kargl]

On Wed, Jun 27, 2018 at 11:09:56AM +0300, Janne Blomqvist wrote:
> 
> How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and then
> check benchmark results (polyhedron, spec etc.)? If performance worsens, we
> revert, if it improves, great, lets keep it?
> 
> To clarify, I'm not objecting to using TRUTH_{AND|OR}_EXPR, I'm objecting
> to the notion that this is somehow "more correct" or "less bad" than the
> current short-circuiting. The Fortran standard does not specify an
> evaluation strategy; IMHO very unfortunately, but it is what it is.
> 

Benchmarks aren't going to prove anything unless the 
benchmarks have the specific construct under discuss.
Here's my benchmark that uses '.false. .and. check()'
construct.  Note, check() has no side-effect.

% cat b.f90
program b
  logical, external :: check
  if (.false. .and. check()) then
 print *, 'here'
  else
 print *, 'there'
  end if
end program b
% cat a.f90
logical function check()
   real x
10 call random_number(x)
   if (x < 2) goto 10
   check = .false.
end function check
% gfortran -o z a.f90 b.f90 && ./z
 there

-- 
Steve

Re: [patch, fortran] Handling of .and. and .or. expressions

[Thomas Koenig]

Hi Janus,


I don't think it's ok to not evaluate expressions that have side
effects


The Fortran standard disagrees with you (as you know, this has
been quoted previously).

Evaluating a function in such a case is a missed optimization.

> but as long as it is guarded by a non-default
> optimization flag, I'm perfectly happy with optimizing away stuff with
> side effects as well.

Why would we need a non-default flag for an optimization that is
perfectly OK with the language standard?

I think we should follow the example of -fstrict-aliasing: Optimize by
default according to what the language rules permit, and warn (with
a flag included with -Wall) if we do so.  I had always thought this
to be the gcc way. Or would you also like to change the behavior of
this flag?

Regards

Thomas

[PATCH] Backport testsuite: Introduce be/le selectors

[Kelvin Nilsen]

Hi Jeff,

Is it ok to backport this patch to gcc 8?  There are other backports of test 
programs that would like to use the new selector options.

Thanks.


On 5/23/18 12:31 PM, Segher Boessenkool wrote:
> On Tue, May 22, 2018 at 03:21:30PM -0600, Jeff Law wrote:
>> On 05/21/2018 03:46 PM, Segher Boessenkool wrote:
>>> This patch creates "be" and "le" selectors, which can be used by all
>>> architectures, similar to ilp32 and lp64.
>>
>> I think this is fine.  "be" "le" are used all over the place in gcc and
>> the kernel to denote big/little endian.
> 
> Thanks.  This is what I checked in (to trunk):
> 
> 
> 2017-05-23  Segher Boessenkool  
> 
>   * doc/sourcebuild.texi (Endianness): New subsubsection.
> 
> gcc/testsuite/
>   * lib/target-supports.exp (check_effective_target_be): New.
>   (check_effective_target_le): New.
> 
> 
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index dfb0578..596007d 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -1313,6 +1313,16 @@ By convention, keywords ending in @code{_nocache} can 
> also include options
>  specified for the particular test in an earlier @code{dg-options} or
>  @code{dg-add-options} directive.
> 
> +@subsubsection Endianness
> +
> +@table @code
> +@item be
> +Target uses big-endian memory order for multi-byte and multi-word data.
> +
> +@item le
> +Target uses little-endian memory order for multi-byte and multi-word data.
> +@end table
> +
>  @subsubsection Data type sizes
> 
>  @table @code
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index aa1296e6..0a53d7b 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -2523,6 +2523,22 @@ proc check_effective_target_next_runtime { } {
>  }]
>  }
> 
> +# Return 1 if we're generating code for big-endian memory order.
> +
> +proc check_effective_target_be { } {
> +return [check_no_compiler_messages be object {
> + int dummy[__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? 1 : -1];
> +}]
> +}
> +
> +# Return 1 if we're generating code for little-endian memory order.
> +
> +proc check_effective_target_le { } {
> +return [check_no_compiler_messages le object {
> + int dummy[__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ ? 1 : -1];
> +}]
> +}
> +
>  # Return 1 if we're generating 32-bit code using default options, 0
>  # otherwise.
> 

Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)

[Jakub Jelinek]

On Wed, Jun 27, 2018 at 09:17:07AM -0600, Jeff Law wrote:
> > About 115 tests fail due to incompatible declarations of
> > the built-in functions below (the number shows the number
> > of warnings for each functions):
> > 
> > 428   abort
> >  58   exit
> >  36   memcpy
> >  17   memmove
> >  15   realloc
> >  14   cabs
> >   5   strncpy
> >   4   strcmp
> >   3   alloca
> >   2   rindex
> >   1   aligned_alloc
> I'm supportive of this change.  Though I'm more worried about the
> affects on the distros than I am on the testsuite (which I expected to
> be in worse shape WRT this issue than your analysis indicates).

I'm mainly worried about configure tests, those will be hit hardest by
this and might result in silently turning off many features of the compiled
programs.

I think
void abort ();
is very common and if people actually don't pass any arguments to abort, I
think warning by default about this is too much.

Jakub

Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)

[Jeff Law]

On 06/26/2018 08:57 PM, Martin Sebor wrote:
> With the exception of built-ins with the ellipsis (like sprintf),
> GCC silently accepts declarations of built-in functions without
> prototypes as well as calls to such functions with any numbers
> or types of arguments, compatible or otherwise.  Calls with
> arguments whose number and types match exactly those of
> the built-in are considered by the middle-end for optimization.
> Other calls (compatible or not, irrespective of whether their
> number matches the number expected by the function) are then
> made to the library functions.
> 
> Attached is a small fix to -Wbuiltin-declaration-mismatch to
> have it diagnose built-in declarations without a prototype.
> The warning is enabled by default so it causes a fair number
> of tests to fail because of declarations like 'void abort();'
> The breakdown of the built-ins behind the test failures is
> below.
> 
> Before I take the time to clean up the test suite let me post
> what I have in case going this route is not acceptable.  As
> an alternative, I could try to avoid some of these warnings,
> e.g., by diagnosing incompatible calls instead but I think
> it's even less worthwhile for built-ins than trying to do
> it for ordinary functions with -Wstrict-prototypes.  There
> is, in my view, no justification today for standard functions
> to be declared without a prototype.  (I could also make
> the warning depend on language mode and -Wpedantic if that
> were more preferable.)
> 
> Martin
> 
> About 115 tests fail due to incompatible declarations of
> the built-in functions below (the number shows the number
> of warnings for each functions):
> 
> 428   abort
>  58   exit
>  36   memcpy
>  17   memmove
>  15   realloc
>  14   cabs
>   5   strncpy
>   4   strcmp
>   3   alloca
>   2   rindex
>   1   aligned_alloc
I'm supportive of this change.  Though I'm more worried about the
affects on the distros than I am on the testsuite (which I expected to
be in worse shape WRT this issue than your analysis indicates).

Unfortunately I don't have the tester set up to do distro style testing
yet.  So I can't just throw your patch in and see what is spit out.  But
even so, I still think this is the right thing to do.

Jeff

Re: [patch, fortran] Handling of .and. and .or. expressions

[Steve Kargl]

On Wed, Jun 27, 2018 at 08:15:13AM +0200, Jakub Jelinek wrote:
> 
> I think best would be to change the above to
> code = TRUTH_AND_EXPR and code = TRUTH_OR_EXPR and have some
> non-default aggressive optimization option that would optimize
> away in the FE impure function calls from those operands if
> one operand is cheap to evaluate and another one
> contains function calls, by optimizing it into TRUTH_{AND,OR}IF_EXPR where
> the cheap operand is the first operand and operand with function calls is
> the second.

I completely disagree.  The Fortran standards (ie., F95,
F2003, F2008, and F2018) clearly state that the operands
of an expression need not be evaluate if the result of
an expression can be determined.  If an option is introduced,
then it should be -fforce-evaluation.  The standards also state
that the order of evaluation is unspecified, which permits the
optimization introduced by Thomas to provide the lack of
symmetry that Janus observed in '.false. .and. check()' and
'check() .and. .false.' should be committed.

-- 
Steve

[committed] Remove -m8byte-align as a standard multilib on v8 port

[Jeff Law]

The v850 port has an option to increase alignment of objects.  However,
from my testing it looks fundamentally broken.  I suspect some kind of
dynamic stack/frame realignment is necessary for this to work properly.

As it stands using -m8byte-align can result in corrupted stack frames.

I'm leaving the option in the v8 port, but removing it from the standard
set of multilibs to be built.

Installing on the trunk,

Jeff
commit 0ae463d575053c83d2bfba3656a58a406787822d
Author: law 
Date:   Wed Jun 27 14:27:44 2018 +

* config/v850/t-v850 (MULTILIB_OPTIONS): Remove 8byte-align.
(MULTILIB_DIRNAMES): Similarly.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@262185 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b9be9d55325..2d0fd08cb49 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2018-06-27  Jeff Law  
+
+   * config/v850/t-v850 (MULTILIB_OPTIONS): Remove 8byte-align.
+   (MULTILIB_DIRNAMES): Similarly.
+
 2018-06-27  Eric Botcazou  
 
* gimple.h (gimple_return_retbnd): Delete.
diff --git a/gcc/config/v850/t-v850 b/gcc/config/v850/t-v850
index a7af1be3a19..984993a4fdf 100644
--- a/gcc/config/v850/t-v850
+++ b/gcc/config/v850/t-v850
@@ -17,8 +17,8 @@
 # .
 
 # Create target-specific versions of the libraries
-MULTILIB_OPTIONS  = m8byte-align mgcc-abi msoft-float
-MULTILIB_DIRNAMES =  8bytegcc-abi  soft-float
+MULTILIB_OPTIONS  = mgcc-abi msoft-float
+MULTILIB_DIRNAMES =  gcc-abi  soft-float
 
 MULTILIB_OPTIONS  += mv850e3v5
 MULTILIB_DIRNAMES +=  v850e3v5

[PATCH] fixincludes: vxworks: regs.h: Guard include of vxTypesOld.h by !_ASMLANGUAGE

[Rasmus Villemoes]

VxWorks' regs.h does include some files that need types defined in
vxTypesOld.h, and it does not itself include that header, directly or
indirectly. Moreover, vxTypesOld.h ends up pulling in definitions of
various cpufamily macros (from types/vxCpu.h) that are also needed
directly by regs.h.

However, when compiling some assembly files that #include "regs.h", the
typedefs in vxTypesOld.h break the build:

/tmp/ccPxG4gA.s: Assembler messages:
/tmp/ccPxG4gA.s:1: Error: unrecognized opcode: `typedef'
/tmp/ccPxG4gA.s:2: Error: unrecognized opcode: `typedef'

etc. The simplest fix is to guard the include of vxTypesOld.h by
!defined(_ASMLANGUAGE). This should not affect C code, and existing
assembly files that include regs.h must already have arranged for
including types/vxCpu.h prior to including regs.h.

==changelog==

fixincludes/

* inclhack.def (AAB_vxworks_regs_vxtypes): Guard include of
types/vxTypesOld.h by #ifndef _ASMLANGUAGE.
* fixincl.x: Regenerate.
---
 fixincludes/inclhack.def | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index c1f5a13eda4..bac0079b69f 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -426,7 +426,9 @@ fix = {
 replace = <<- _EndOfHeader_
#ifndef _REGS_H
#define _REGS_H
+   #ifndef _ASMLANGUAGE
#include 
+   #endif
#include_next 
#endif
_EndOfHeader_;
-- 
2.16.4

Re: [patch, fortran] Handling of .and. and .or. expressions

[Janus Weil]

2018-06-27 15:43 GMT+02:00 N.M. Maclaren :
> On Jun 27 2018, Janus Weil wrote:
>>
>>
>> It is very unfortunate, and it means that the Fortran standard simply
>> does not provide a measure for "more correct" here. (My common-sense
>> drop-in notion of correctness would be that an optimization is
>> 'correct' as long as it can be proven to not change any results.)
>
>
> Actually, yes, it does.  Fortran 2008 7.1.4p2, 7.1.5.2.4p2, 7.1.5.3.2p1,
> 7.1.5.4.2p1, 7.1.5.5.2p1 and 7.1.6.3p1/2.

I'm not completely sure what you deduce from all these quoted
paragraphs, but applied to the cases we're discussing here, e.g.

A = .false. .and. my_boldly_impure_function()

I read them as saying that a compiler does not have to invoke the
function if it doesn't feel like it, but with no definite obligation
to remove the call either. Do you agree?


> The problem is that the Fortran
> standard has never resolved the inconsistency that OTHER side-effects in
> functions are not explicitly forbidden

Exactly.


> it's one of the few places in
> Fortran where there are conforming constructs that do not have specified
> semantics or at least a clearly specified intention.

And I really wonder why one would do such a thing. Like, ever.

I'm curious: Are there actually other such cases in Fortran that
you're aware of?


> Many, many people have tried to sort that out, and all have failed dismally.
> I regret that the proposal to deprecate impure functions did not succeed,
> because at least that would have made one sane direction clear.

I don't know. Why do so many people in the Fortran community have such
a big problem with functions? Ok, they haven't been around in 77, but
if you even bother to introduce them, why do it so half-heartedly and
not just embrace them in their full beauty?

What is so complicated about putting a statement into the Fortran
standard that says: "Ok, if this function has side effects, we
definitely must evaluate it, otherwise we lose the side effects. They
might be important."  ???


> This has been made much worse by IEEE 754 and (worse) coarray support. Like
> almost all languages with threading and shared-memory, Fortran's concept of
> pure is satisfactory for single-threaded code but not parallel. You need the
> stronger concept, where a pure function does not depend on anything that
> might change in its scope.

We don't even need to start discussing these things if we can't even
figure out what to do with an impure function in a simple
single-threaded program.


> Look on the bright side.  If you thought this problem is a mess (it is), I
> can assure you that most other languages get it far, far worse - often with
> logically impossible or contradictory promises and requirements.

I don't quite see that. Which languages are you talking about
specifically? I see that C/C++ gives you a nice choice of writing

A = false & my_boldly_impure_function()

or

A = false && my_boldly_impure_function()

where the first option guarantees that your function is evaluated,
while the second one allows (or even demands?) it to be optimized
away. That's a much clearer situation than the Fortran mess, isn't it?


My wish would be that instead of deprecating impure functions, the
Fortran standard should rather introduce .ANDIF. / .ORELSE. operators.


Cheers,
Janus

Re: [PATCH][AArch64] Add support for Arm Cortex-A76

[James Greenhalgh]

On Wed, Jun 27, 2018 at 04:50:33AM -0500, Kyrill Tkachov wrote:
> Hi all,
> 
> The Cortex-A76 is an Armv8.2-A processor with dotproduct and FP16 support.
> It can be paired with the Cortex-A55 and hence the option
> -mcpu/-mtune=cortex-a76.cortex-a55 is also introduced.
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> 
> Ok for trunk?

OK.

Thanks,
James

> 2018-06-27  Kyrylo Tkachov  
> 
>  * config/aarch64/aarch64-cores.def (cortex-a76): New entry.
>  (cortex-a76.cortex-a55): Likewise.
>  * config/aarch64/aarch64-tune.md: Regenerate.
>  * doc/invoke.texi (AArch64 Options): Document cortex-a76 and
>  cortex-a76.cortex-a55.

[Patch, fortran] PR45305 - Array-valued calls to elementals are not simplified

[Paul Richard Thomas]

I posted a patch for this on the PR in August 2010. Dominique pointed
out that it caused repeated error messages in some testcases; eg.
arithmetic_overflow_1.f90

As it happens, that seems to have crept in at some time even without
the patch for this PR. Nevertheless, I have modified the patch
slightly to prevent any more escalation. Apart from this, the patch is
very straightforward.

Bootstraps and regtests on FC28/x86_64 - OK for trunk and?

Paul

2018-06-27  Paul Thomas  

PR fortran/45305
* expr.c : Add a prototype for scalarize_intrinsic_call.
(gfc_simplify_expr): Use scalarize_intrinsic_call for elemental
intrinsic function calls.
(scalarize_intrinsic_call): Add 'init_flag' argument. Check if
the expression or any of the actual argument expressions are
NULL. Before calling gfc_check_init_expr, check 'init_flag'.
Only simplify the scalarized expressions if there are no errors
on the stack.
(gfc_check_init_expr): Set 'init_flag' true in the call to
scalarize_intrinsic_call.

2018-06-27  Paul Thomas  

PR fortran/45305
* gfortran.dg/scalarize_parameter_array_3.f90: New test.


Change.Logs
Description: Binary data

Re: [patch, fortran] Handling of .and. and .or. expressions

[N.M. Maclaren]

On Jun 27 2018, Janus Weil wrote:


It is very unfortunate, and it means that the Fortran standard simply
does not provide a measure for "more correct" here. (My common-sense
drop-in notion of correctness would be that an optimization is
'correct' as long as it can be proven to not change any results.)


Actually, yes, it does.  Fortran 2008 7.1.4p2, 7.1.5.2.4p2, 7.1.5.3.2p1,
7.1.5.4.2p1, 7.1.5.5.2p1 and 7.1.6.3p1/2.  The problem is that the Fortran
standard has never resolved the inconsistency that OTHER side-effects in
functions are not explicitly forbidden - it's one of the few places in
Fortran where there are conforming constructs that do not have specified
semantics or at least a clearly specified intention.

Many, many people have tried to sort that out, and all have failed dismally.
I regret that the proposal to deprecate impure functions did not succeed,
because at least that would have made one sane direction clear.

This has been made much worse by IEEE 754 and (worse) coarray support. Like 
almost all languages with threading and shared-memory, Fortran's concept of 
pure is satisfactory for single-threaded code but not parallel. You need 
the stronger concept, where a pure function does not depend on anything 
that might change in its scope.


Look on the bright side.  If you thought this problem is a mess (it is), I
can assure you that most other languages get it far, far worse - often with
logically impossible or contradictory promises and requirements.


Regards,
Nick Maclaren.

[patch] Do not leak location information during inlining (2nd try)

[Eric Botcazou]

Hi,

the Ada compiler uses small functions defined in its runtime to implement 
various intrinsic operations and it always inlines them, even at -O0.  But it 
doesn't want location information from the runtime files to appear in the 
debug info so it puts DECL_IGNORED_P on these functions.  final.c already 
knows how not to generate location information for DECL_IGNORED_P functions 
when they are standalone but that's not the case for the inliner, i.e. it 
leaks location information from these functions where they are inlined.

The attached patch is aimed at preventing this from happening by explicitly 
forcing input_location on the inlined bodies in this case.

Tested (GCC and GDB) on x86-64/Linux, OK for the mainline?


2018-06-27  Eric Botcazou  

* tree-inline.c (remap_gimple_stmt): Force input_location on the new
statement if id->reset_location is true.
(copy_edges_for_bb): Do not set goto_locus on the new edges if
id->reset_location is true.
(copy_phis_for_bb): Force input_location on the arguments if
id->reset_location is true.
(expand_call_inline): Set id->reset_location if DECL_IGNORED_P
is set on the function to be inlined.
* tree-inline.h (struct copy_body_data): Move remapping_type_depth and
prevent_decl_creation_for_types fields up and add reset_location field.


2018-06-27  Eric Botcazou  

* gnat.dg/debug15.adb: New test.

-- 
Eric BotcazouIndex: tree-inline.c
===
--- tree-inline.c	(revision 262181)
+++ tree-inline.c	(working copy)
@@ -1630,6 +1630,8 @@ remap_gimple_stmt (gimple *stmt, copy_bo
 	= gimple_build_debug_bind (gimple_debug_bind_get_var (stmt),
    gimple_debug_bind_get_value (stmt),
    stmt);
+	  if (id->reset_location)
+	gimple_set_location (copy, input_location);
 	  id->debug_stmts.safe_push (copy);
 	  gimple_seq_add_stmt (, copy);
 	  return stmts;
@@ -1640,6 +1642,8 @@ remap_gimple_stmt (gimple *stmt, copy_bo
 	   (gimple_debug_source_bind_get_var (stmt),
 			gimple_debug_source_bind_get_value (stmt),
 			stmt);
+	  if (id->reset_location)
+	gimple_set_location (copy, input_location);
 	  id->debug_stmts.safe_push (copy);
 	  gimple_seq_add_stmt (, copy);
 	  return stmts;
@@ -1653,6 +1657,8 @@ remap_gimple_stmt (gimple *stmt, copy_bo
 	return stmts;
 
 	  gdebug *copy = as_a  (gimple_copy (stmt));
+	  if (id->reset_location)
+	gimple_set_location (copy, input_location);
 	  id->debug_stmts.safe_push (copy);
 	  gimple_seq_add_stmt (, copy);
 	  return stmts;
@@ -1751,6 +1757,9 @@ remap_gimple_stmt (gimple *stmt, copy_bo
   gimple_set_block (copy, *n);
 }
 
+  if (id->reset_location)
+gimple_set_location (copy, input_location);
+
   /* Debug statements ought to be rebuilt and not copied.  */
   gcc_checking_assert (!is_gimple_debug (copy));
 
@@ -2178,7 +2187,8 @@ copy_edges_for_bb (basic_block bb, profi
 	new_edge
 	  = make_edge (new_bb, (basic_block) old_edge->dest->aux, flags);
 	new_edge->probability = old_edge->probability;
-	new_edge->goto_locus = remap_location (locus, id);
+	if (!id->reset_location)
+	  new_edge->goto_locus = remap_location (locus, id);
   }
 
   if (bb->index == ENTRY_BLOCK || bb->index == EXIT_BLOCK)
@@ -2375,7 +2385,10 @@ copy_phis_for_bb (basic_block bb, copy_b
 		  inserted = true;
 		}
 		  locus = gimple_phi_arg_location_from_edge (phi, old_edge);
-		  locus = remap_location (locus, id);
+		  if (id->reset_location)
+		locus = input_location;
+		  else
+		locus = remap_location (locus, id);
 		  add_phi_arg (new_phi, new_arg, new_edge, locus);
 		}
 	}
@@ -4499,8 +4512,7 @@ expand_call_inline (basic_block bb, gimp
   prepend_lexical_block (gimple_block (stmt), id->block);
 }
 
-  /* Local declarations will be replaced by their equivalents in this
- map.  */
+  /* Local declarations will be replaced by their equivalents in this map.  */
   st = id->decl_map;
   id->decl_map = new hash_map;
   dst = id->debug_map;
@@ -4509,6 +4521,7 @@ expand_call_inline (basic_block bb, gimp
   /* Record the function we are about to inline.  */
   id->src_fn = fn;
   id->src_cfun = DECL_STRUCT_FUNCTION (fn);
+  id->reset_location = DECL_IGNORED_P (fn);
   id->call_stmt = call_stmt;
 
   /* When inlining into an OpenMP SIMD-on-SIMT loop, arrange for new automatic
Index: tree-inline.h
===
--- tree-inline.h	(revision 262181)
+++ tree-inline.h	(working copy)
@@ -80,6 +80,9 @@ struct copy_body_data
  is not.  */
   gcall *call_stmt;
 
+  /* > 0 if we are remapping a type currently.  */
+  int remapping_type_depth;
+
   /* Exception landing pad the inlined call lies in.  */
   int eh_lp_nr;
 
@@ -110,11 +113,14 @@ struct copy_body_data
   /* True if this statement will need to be regimplified.  */
   bool regimplify;
 
-  /* True if trees 

Re: C++ PATCH for c++/86184, rejects-valid with ?: and omitted operand

[Marek Polacek]

Ping.

On Thu, Jun 21, 2018 at 02:22:31PM -0400, Marek Polacek wrote:
> The following testcase is rejected because, for this line:
> 
>   bool b = X() ?: false;
> 
> arg2 is missing and arg1 is a TARGET_EXPR.  A TARGET_EXPR is a class
> prvalue so we wrap it in a SAVE_EXPR.  Later when building 'this' we
> call build_this (SAVE_EXPR >) which triggers lvalue_error:
>  5856   cp_lvalue_kind kind = lvalue_kind (arg);
>  5857   if (kind == clk_none)
>  5858 {
>  5859   if (complain & tf_error)
>  5860 lvalue_error (input_location, lv_addressof);
> because all SAVE_EXPRs are non-lvalue.
> 
> Since
> a) cp_build_addr_expr_1 can process xvalues and class prvalues,
> b) TARGET_EXPRs are only evaluated once (gimplify_target_expr),
> I thought we could do the following.  The testcase ensures that
> with the omitted operand we only construct X once.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2018-06-21  Marek Polacek  
> 
>   PR c++/86184
>   * call.c (build_conditional_expr_1): Don't wrap TARGET_EXPRs
>   in a SAVE_EXPR.
> 
>   * g++.dg/ext/cond3.C: New test.
> 
> --- gcc/cp/call.c
> +++ gcc/cp/call.c
> @@ -4806,6 +4806,10 @@ build_conditional_expr_1 (location_t loc, tree arg1, 
> tree arg2, tree arg3,
>/* Make sure that lvalues remain lvalues.  See g++.oliva/ext1.C.  */
>if (lvalue_p (arg1))
>   arg2 = arg1 = cp_stabilize_reference (arg1);
> +  else if (TREE_CODE (arg1) == TARGET_EXPR)
> + /* TARGET_EXPRs are only expanded once, don't wrap it in a SAVE_EXPR,
> +rendering it clk_none of clk_class.  */
> + arg2 = arg1;
>else
>   arg2 = arg1 = cp_save_expr (arg1);
>  }
> --- gcc/testsuite/g++.dg/ext/cond3.C
> +++ gcc/testsuite/g++.dg/ext/cond3.C
> @@ -0,0 +1,20 @@
> +// PR c++/86184
> +// { dg-do run }
> +// { dg-options "" }
> +
> +int j;
> +struct X {
> +  X() { j++; }
> +  operator bool() { return true; }
> +};
> +
> +/* Only create X once.  */
> +bool b = X() ?: false;
> +bool b2 = X() ? X() : false;
> +
> +int
> +main ()
> +{
> +  if (j != 3)
> +__builtin_abort ();
> +}

Marek

[PATCH 4/4] [MSP430] Search for MCU data file using environment variable and in a toolchain subdirectory

[Jozef Lawrynowicz]

The fourth and final patch adds functionality to search for 
devices.csv in both
the path specified by the environment variable 
"MSP430_GCC_INCLUDE_DIR", and

the directory "msp430-elf/include/devices" from the toolchain root. These
locations are searched if devices.csv is not found on an include path.
If devices.csv is found using one of these methods, the directory 
containing
devices.csv is also registered as an include path and linker library 
path.




>From 43a9106e71a8b7545f894b4c1c495288b6144876 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Tue, 26 Jun 2018 15:02:58 +0100
Subject: [PATCH 4/4] MSP430 - Devices 3 - Add functionality to read
 devices.csv path from env var

2018-06-27  Jozef Lawrynowicz  

gcc/config/msp430/

	* driver-msp430.c (msp430_select_hwmult_lib): Fix formatting.
	(msp430_get_linker_devices_include_path): New.
	* msp430-devices.c (msp430_dirname): New.
	(canonicalize_path_dirsep): New.
	(process_collect_gcc_into_devices_dir): New.
	(msp430_check_env_var_for_devices): New.
	(parse_devices_csv): Call msp430_check_env_var_for_devices after trying
	other methods.
	* msp430-devices.h (msp430_check_env_var_for_devices): New.
	(msp430_dirname): New.
	* msp430.c (msp430_register_pre_includes): New.
	* msp430.h (EXTRA_SPEC_FUNCTIONS): Add
	msp430_get_linker_devices_include_path.
	(LINK_SPEC): Likewise.
	Define TARGET_EXTRA_PRE_INCLUDES to msp430_register_pre_includes.

gcc/doc/

	* invoke.texi: Document that devices.csv is searched for using an
	environment variable and in a subdirectory of the toolchain
	installation.

gcc/testsuite/gcc.target/msp430/

	* devices/csv_using_env_var.c: New.
	* devices/csv_using_installed.c: New.
	* devices/csv_using_option.c: New.
	* msp430.exp (msp430_device_permutations_runtest): Prepare for
	csv_using_* tests as appropriate.
	(get_installed_device_data_path): New.
	(msp430_hide_installed_devices_data): New.
	(msp430_restore_installed_devices_data): New.
	(msp430_test_installed_device_data): New.
---
 gcc/config/msp430/driver-msp430.c  | 13 +++-
 gcc/config/msp430/msp430-devices.c | 87 +-
 gcc/config/msp430/msp430-devices.h |  2 +
 gcc/config/msp430/msp430.c | 16 
 gcc/config/msp430/msp430.h | 12 ++-
 gcc/doc/invoke.texi| 28 ++-
 .../gcc.target/msp430/devices/csv_using_env_var.c  | 10 +++
 .../msp430/devices/csv_using_installed.c   | 11 +++
 .../gcc.target/msp430/devices/csv_using_option.c   | 12 +++
 gcc/testsuite/gcc.target/msp430/msp430.exp | 70 -
 10 files changed, 254 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_using_env_var.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_using_installed.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_using_option.c

diff --git a/gcc/config/msp430/driver-msp430.c b/gcc/config/msp430/driver-msp430.c
index 4242274..3facdc2 100644
--- a/gcc/config/msp430/driver-msp430.c
+++ b/gcc/config/msp430/driver-msp430.c
@@ -52,7 +52,8 @@ msp430_select_cpu (int argc, const char ** argv)
 /* Implement spec function `msp430_hwmult_lib´.  */
 
 const char *
-msp430_select_hwmult_lib (int argc ATTRIBUTE_UNUSED, const char ** argv ATTRIBUTE_UNUSED)
+msp430_select_hwmult_lib (int argc ATTRIBUTE_UNUSED,
+			  const char ** argv ATTRIBUTE_UNUSED)
 {
   int i;
 
@@ -116,3 +117,13 @@ msp430_select_hwmult_lib (int argc ATTRIBUTE_UNUSED, const char ** argv ATTRIBUT
   
   return "-lmul_none";
 }
+
+const char *
+msp430_get_linker_devices_include_path (int argc ATTRIBUTE_UNUSED,
+	const char **argv ATTRIBUTE_UNUSED)
+{
+  char *devices_csv_path;
+  if (msp430_check_env_var_for_devices (_csv_path))
+return NULL;
+  return concat ("-L", msp430_dirname (devices_csv_path), NULL);
+}
diff --git a/gcc/config/msp430/msp430-devices.c b/gcc/config/msp430/msp430-devices.c
index a87a439..597568c 100644
--- a/gcc/config/msp430/msp430-devices.c
+++ b/gcc/config/msp430/msp430-devices.c
@@ -23,6 +23,88 @@ char * derived_devices_csv_loc = NULL;
 /* Set to true by msp430_extract_mcu_data if called from the driver.  */
 bool surpress_devices_warn = false;
 
+/* This modifies the string pointed to by path.  */
+char *
+msp430_dirname (char *path)
+{
+  int last_elem = strlen (path) - 1;
+  int i = last_elem - (IS_DIR_SEPARATOR (path[last_elem]) ? 1 : 0);
+  for (; i >= 0; i--)
+{
+  if (IS_DIR_SEPARATOR (path[i]))
+	{
+	  path[i] = '\0';
+	  return path;
+	}
+}
+  return path;
+}
+
+/* This is to canonicalize the path.  On Windows we can have a mix of forward
+   and backslashes which leads to issues following paths.  */
+static void
+canonicalize_path_dirsep (char **path)
+{
+  char *t_path = *path;
+  unsigned int i;
+  for (i = 0; i < strlen (t_path); i++)
+if (IS_DIR_SEPARATOR (t_path[i]))
+  t_path[i] = DIR_SEPARATOR;
+}
+
+static void

[PATCH 3/4] [MSP430] Search for MCU data file on include paths

[Jozef Lawrynowicz]

The third patch adds functionality to search the include paths 
specified with
-I for "devices.csv". If the file is found, and a device name has been 
passed
to the -mmcu option, then devices.csv is parsed, and the MCU data for 
the given

device is extracted.



>From 7e24ade1d4d16d71dca3f4d7d3e66a784d2563fd Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Tue, 26 Jun 2018 12:21:09 +0100
Subject: [PATCH 3/4] MSP430 - Devices 2 - Add functionality to read device
 data from CSV file

2018-06-27  Jozef Lawrynowicz  

gcc/config/msp430/

	* msp430-devices.c (msp430_check_path_for_devices): New.
	(devices_csv_warning): New.
	(parse_devices_csv_1): New.
	(parse_devices_csv): New.
	(msp430_extract_mcu_data): Add argument to choose if devices.csv
	warnings should be surpressed.
	* msp430.c (msp430_mcu_name): Update invocation of msp430_extract_mcu_data.
	(msp430_option_override): Likewise.
	(msp430_use_f5_series_hwmult): Likewise.
	(use_32bit_hwmult): Likewise.
	(msp430_no_hwmult): Likewise.
	* msp430-devices.h (msp430_extract_mcu_data): Add argument to choose
	if devices.csv warnings should be surpressed.
	* msp430.h (EXTRA_SPEC_FUNCTIONS): Add msp430_check_path_for_devices.
	(DRIVER_SELF_SPECS): Likewise.
	* msp430.opt: Add -mdevices-csv-loc= and -mdisable-device-warnings
	options.
	* driver-msp430.c (msp430_select_cpu): Update invocation of
	msp430_extract_mcu_data.
	(msp430_select_hwmult_lib): Likewise.

gcc/doc/

	* invoke.texi: Document that MCU data for the -mmcu option value can be
	loaded from an external file.
	Document -mdisable-device-warnings.

gcc/testsuite/gcc.target/msp430/

	* devices/csv_msp430_{0,1,2}{0,1,2,4,8}.c: New.
	* devices/csv_msp430f5529.c: New.
	* devices/csv_msp430fr5969.c: New.
	* devices/devices.csv: New.
	* devices/msp430.h: New.
	* msp430.exp (msp430_get_multidir): Extend so MCU data is loaded from
	devices.csv for csv_* tests.
	(dg-msp-options): Update invocation to msp430_get_multidir.
	(msp430_get_supported_opts): Likewise.
	(msp430_device_permutations_runtest): Extend to handle csv_* tests.
---
 gcc/config/msp430/driver-msp430.c  |   5 +-
 gcc/config/msp430/msp430-devices.c | 203 -
 gcc/config/msp430/msp430-devices.h |   2 +-
 gcc/config/msp430/msp430.c |  10 +-
 gcc/config/msp430/msp430.h |   7 +-
 gcc/config/msp430/msp430.opt   |   9 +
 gcc/doc/invoke.texi|  10 +-
 .../gcc.target/msp430/devices/csv_msp430_00.c  |   6 +
 .../gcc.target/msp430/devices/csv_msp430_01.c  |   6 +
 .../gcc.target/msp430/devices/csv_msp430_02.c  |   6 +
 .../gcc.target/msp430/devices/csv_msp430_04.c  |   6 +
 .../gcc.target/msp430/devices/csv_msp430_08.c  |   6 +
 .../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 +
 .../gcc.target/msp430/devices/csv_msp430f5529.c|   8 +
 .../gcc.target/msp430/devices/csv_msp430fr5969.c   |  10 +
 .../gcc.target/msp430/devices/devices.csv  |  17 ++
 gcc/testsuite/gcc.target/msp430/devices/msp430.h   |   3 +
 gcc/testsuite/gcc.target/msp430/msp430.exp |  35 +++-
 27 files changed, 386 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_00.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_01.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_02.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_04.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_08.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_10.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_11.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_12.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_14.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_18.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_20.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_21.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_22.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_24.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430_28.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv_msp430f5529.c
 create 

[PATCH 2/4] [MSP430] Update hard-coded MCU data

[Jozef Lawrynowicz]

The second patch updates the hard-coded MCU data to the latest version.


>From 7da6e1edcffc1fa1a93dde5e23c87f9653132768 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Mon, 25 Jun 2018 19:56:53 +0100
Subject: [PATCH 2/4] MSP430 - Devices 1.1 Update hard-coded MCU data

2018-06-27  Jozef Lawrynowicz  

gcc/config/msp430/

	* msp430-devices.c (hard_msp430_mcu_data): Add new devices.
---
 gcc/config/msp430/msp430-devices.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/gcc/config/msp430/msp430-devices.c b/gcc/config/msp430/msp430-devices.c
index f20b379..fff5554 100644
--- a/gcc/config/msp430/msp430-devices.c
+++ b/gcc/config/msp430/msp430-devices.c
@@ -13,7 +13,7 @@
 
 struct t_msp430_mcu_data extracted_mcu_data;
 /* Initialized at the bottom for improved readability.  */
-extern struct t_msp430_mcu_data hard_msp430_mcu_data[605];
+extern struct t_msp430_mcu_data hard_msp430_mcu_data[626];
 
 /* This function only needs to be executed once, but it can be first called
from a number of different locations.  */
@@ -60,10 +60,9 @@ msp430_extract_mcu_data (const char * mcu_name)
 }
 }
 
-/* The data in this structure has been extracted from version 1.194 of the
-   devices.csv file released by TI in September 2016.  */
-
-struct t_msp430_mcu_data hard_msp430_mcu_data[605] =
+/* The data in this structure has been extracted from version 1.205 of the
+   devices.csv file released by TI in April 2018.  */
+struct t_msp430_mcu_data hard_msp430_mcu_data[626] =
 {
   { "cc430f5123",2,8 },
   { "cc430f5125",2,8 },
@@ -479,13 +478,22 @@ struct t_msp430_mcu_data hard_msp430_mcu_data[605] =
   { "msp430fg6426",2,8 },
   { "msp430fg6625",2,8 },
   { "msp430fg6626",2,8 },
+  { "msp430fr2000",2,0 },
   { "msp430fr2032",2,0 },
   { "msp430fr2033",2,0 },
+  { "msp430fr2100",2,0 },
   { "msp430fr2110",2,0 },
   { "msp430fr2111",2,0 },
+  { "msp430fr2153",2,8 },
+  { "msp430fr2155",2,8 },
   { "msp430fr2310",2,0 },
   { "msp430fr2311",2,0 },
+  { "msp430fr2353",2,8 },
+  { "msp430fr2355",2,8 },
+  { "msp430fr2422",2,8 },
   { "msp430fr2433",2,8 },
+  { "msp430fr2512",2,8 },
+  { "msp430fr2522",2,8 },
   { "msp430fr2532",2,8 },
   { "msp430fr2533",2,8 },
   { "msp430fr2632",2,8 },
@@ -494,6 +502,9 @@ struct t_msp430_mcu_data hard_msp430_mcu_data[605] =
   { "msp430fr4131",2,0 },
   { "msp430fr4132",2,0 },
   { "msp430fr4133",2,0 },
+  { "msp430fr5041",2,8 },
+  { "msp430fr5043",2,8 },
+  { "msp430fr50431",2,8 },
   { "msp430fr5720",2,8 },
   { "msp430fr5721",2,8 },
   { "msp430fr5722",2,8 },
@@ -560,6 +571,15 @@ struct t_msp430_mcu_data hard_msp430_mcu_data[605] =
   { "msp430fr5994",2,8 },
   { "msp430fr59941",2,8 },
   { "msp430fr5xx_6xxgeneric",2,8 },
+  { "msp430fr6035",2,8 },
+  { "msp430fr6037",2,8 },
+  { "msp430fr60371",2,8 },
+  { "msp430fr6041",2,8 },
+  { "msp430fr6043",2,8 },
+  { "msp430fr60431",2,8 },
+  { "msp430fr6045",2,8 },
+  { "msp430fr6047",2,8 },
+  { "msp430fr60471",2,8 },
   { "msp430fr6820",2,8 },
   { "msp430fr6822",2,8 },
   { "msp430fr68221",2,8 },
-- 
2.7.4

[PATCH 1/4] [MSP430] Consolidate hard-coded MCU data

[Jozef Lawrynowicz]

The first patch keeps the hard-coded data as the only way of reading 
MCU data,

but consolidates it in a single file. Extensions to the spec handling in
msp430.h mean that the hard-coded data is no longer needed in 
't-msp430' for
multilib selection, or in the assembler. This is achieved by the 
driver which

places the corresponding mcpu value for the MCU on its command line.


Ok for trunk?

>From 751a5b4f32a91d697b56fa94ca8426fa6679c5fa Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Thu, 7 Jun 2018 14:44:10 +0100
Subject: [PATCH 1/4] MSP430 - Devices 1 - Handle device tasks in separate file

2018-06-27  Jozef Lawrynowicz  

gcc/
	* config.gcc (msp430*-*-*): Add msp430-devices.o to extra_objs and
	extra_gcc_objs.

gcc/config/msp430/

	* msp430-devices.c: New.
	* msp430-devices.h: New.
	* driver-msp430.c (msp430_select_cpu): New spec function to return
	-mcpu value for given mcu.
	(msp430_select_hwmult_lib): Call msp430_extract_mcu_data to get MCU
	data.
	(msp430_mcu_data): Remove.
	* msp430.c (msp430_mcu_data): Remove.
	(msp430_mcu_name): Call msp430_extract_mcu_data to get MCU data.
	(msp430_option_override): Likewise.
	(msp430_use_f5_series_hwmult): Likewise.
	(use_32bit_hwmult): Likewise.
	(msp430_no_hwmult): Likewise.
	* msp430.h (EXTRA_SPEC_FUNCTIONS): Add msp430_select_cpu.
	(DRIVER_SELF_SPECS): Define.
	(ASM_SPEC): Don't pass mmcu option to assembler.
	* t-msp430: Add makefile rule for msp430-devices.o.
	Remove MULTILIB_MATCHES containing MCU names.

gcc/testsuite/gcc.target/msp430/

	* devices-main.c: New generic test source file.
	* msp430.exp (msp430_set_old_board_info_ldflags): New.
	(msp430_reset_board_info_ldflags): New.
	(msp430_get_multidir): New.
	(check_effective_target_430_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_supported_opts): New.
	(msp430_device_permutations_runtest): New.
	(dg-msp-options): New dg-directive for MSP430.
	* devices/README
	* devices/hard_cc430f5123.c
	* devices/hard_foo.c
	* devices/hard_msp430afe253.c
	* devices/hard_msp430cg4616.c
	* devices/hard_msp430f4783.c
	* devices/hard_rf430frl154h_rom.c
---
 gcc/config.gcc |   3 +-
 gcc/config/msp430/driver-msp430.c  | 667 +--
 gcc/config/msp430/msp430-devices.c | 673 +++
 gcc/config/msp430/msp430-devices.h |  11 +
 gcc/config/msp430/msp430.c | 732 ++---
 gcc/config/msp430/msp430.h |  14 +-
 gcc/config/msp430/t-msp430 | 237 +--
 gcc/testsuite/gcc.target/msp430/devices-main.c |   5 +
 gcc/testsuite/gcc.target/msp430/devices/README |  15 +
 .../gcc.target/msp430/devices/hard_cc430f5123.c|   7 +
 gcc/testsuite/gcc.target/msp430/devices/hard_foo.c |   5 +
 .../gcc.target/msp430/devices/hard_msp430afe253.c  |   7 +
 .../gcc.target/msp430/devices/hard_msp430cg4616.c  |   7 +
 .../gcc.target/msp430/devices/hard_msp430f4783.c   |   7 +
 .../msp430/devices/hard_rf430frl154h_rom.c |   7 +
 gcc/testsuite/gcc.target/msp430/msp430.exp | 207 +-
 16 files changed, 1057 insertions(+), 1547 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 63162aa..0ba941f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2340,7 +2340,8 @@ msp430*-*-*)
 	c_target_objs="msp430-c.o"
 	cxx_target_objs="msp430-c.o"
 	tmake_file="${tmake_file} msp430/t-msp430"
-	extra_gcc_objs="driver-msp430.o"
+	extra_objs="${extra_objs} msp430-devices.o"
+	extra_gcc_objs="driver-msp430.o msp430-devices.o"
 	;;
 nds32*-*-*)
 	target_cpu_default="0"
diff --git a/gcc/config/msp430/driver-msp430.c b/gcc/config/msp430/driver-msp430.c
index 09b4b9c..e83c20f 100644
--- a/gcc/config/msp430/driver-msp430.c
+++ b/gcc/config/msp430/driver-msp430.c
@@ -25,627 +25,30 @@
 #include "coretypes.h"
 #include "diagnostic.h"
 #include "tm.h"
+#include "msp430-devices.h"
 
-/* This is a copy of the same data structure found in gas/config/tc-msp430.c
-   Also another (sort-of) copy can be found in gcc/config/msp430/msp430.c
-   

[PATCH 0/4] [MSP430] Add methods to extract MCU data from file

[Jozef Lawrynowicz]

The following series of patches extends MCU device data handling for the msp430
target, allowing an external file to be read which describes the CPU ISA and
hardware multiply supported for different MCUs.
The current hard-coded solution means that new MCUs can only be supported by
updating the GCC itself.

The first patch keeps the hard-coded data as the only way of reading MCU data,
but consolidates it in a single file. Extensions to the spec handling in
msp430.h mean that the hard-coded data is no longer needed in 't-msp430' for
multilib selection, or in the assembler. This is achieved by the driver which
places the corresponding mcpu value for the MCU on its command line.

Some extensions to msp430.exp were necessary to ensure that full test coverage
is achieved when the testsuite is run using "make check".
As the tests for different MCUs result in different ISAs/memory
models being used, the hard-coded libgloss multilib directories on the command
line needed to be fixed up to allow the non-default "430" and "large" multilibs
to be tested.
The tests could be downgraded from link tests to assemble tests, (the mips
testsuite does this), but then we would lose coverage that the spec strings
and multilib selection work as expected.

The second patch updates the hard-coded MCU data to the latest version.

The third patch adds functionality to search the include paths specified with
-I for "devices.csv". If the file is found, and a device name has been passed
to the -mmcu option, then devices.csv is parsed, and the MCU data for the given
device is extracted.

The fourth and final patch adds functionality to search for devices.csv in both
the path specified by the environment variable "MSP430_GCC_INCLUDE_DIR", and
the directory "msp430-elf/include/devices" from the toolchain root. These
locations are searched if devices.csv is not found on an include path.
If devices.csv is found using one of these methods, the directory containing
devices.csv is also registered as an include path and linker library path.

Re: [PATCH][AARCH64] PR target/84521 Fix frame pointer corruption with -fomit-frame-pointer with __builtin_setjmp

[Wilco Dijkstra]

Eric Botcazou wrote:

>> This test can easily be changed not to use optimize since it doesn't look
>> like it needs it. We really need to tests these builtins properly,
>> otherwise they will continue to fail on most targets.
>
> As far as I can see PR target/84521 has been reported only for Aarch64 so I'd 
> just leave the other targets alone (and avoid propagating FUD if possible).

It's quite obvious from PR84521 that this is an issue affecting all targets.
Adding better generic tests for __builtin_setjmp can only be a good thing.

Wilco

[PATCH] Add std::__is_byte specialization

[Jonathan Wakely]

* include/bits/cpp_type_traits.h [__cplusplus >= 201703]
(__is_byte): Define specialization for std::byte.

This is used in  to decide whether to optimize fills to
memset, so we want to enable it for std::byte.

It could also be used to simplify __is_byte_like in ,
which I might do at a later date.

Tested x86_64-linux, committed to trunk.

commit 4f1f2fba9a43e5f63cb771f7c9c358734bbbd92a
Author: Jonathan Wakely 
Date:   Wed Jun 27 01:14:33 2018 +0100

Add std::__is_byte specialization

* include/bits/cpp_type_traits.h [__cplusplus >= 201703]
(__is_byte): Define specialization for std::byte.

diff --git a/libstdc++-v3/include/bits/cpp_type_traits.h 
b/libstdc++-v3/include/bits/cpp_type_traits.h
index ed6de4696c7..960d469f412 100644
--- a/libstdc++-v3/include/bits/cpp_type_traits.h
+++ b/libstdc++-v3/include/bits/cpp_type_traits.h
@@ -391,6 +391,17 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
   typedef __true_type __type;
 };
 
+#if __cplusplus >= 201703L
+  enum class byte : unsigned char;
+
+  template<>
+struct __is_byte
+{
+  enum { __value = 1 };
+  typedef __true_type __type;
+};
+#endif // C++17
+
   //
   // Move iterator type
   //

Re: [patch] Remove left-overs from BND support

[Richard Biener]

On June 27, 2018 9:54:50 AM GMT+02:00, Eric Botcazou  
wrote:
>Tested on x86-64/Linux, OK for the mainline?

OK. 

Richard. 

>
>2018-06-27  Eric Botcazou  
>
>   * gimple.h (gimple_return_retbnd): Delete.
>   (gimple_return_set_retbnd): Likewise.
>   * cgraphunit.c (cgraph_node::expand_thunk): Remove call to
>   gimple_return_set_retbnd.
>   * gimple-pretty-print.c (dump_gimple_return): Remove call to
>   gimple_return_retbnd and adjust.
>   * tree-inline.h (struct copy_body_data): Remove retbnd field.
>   * tree-inline.c (remap_gimple_stmt): Remove handling of retbnd.
>   Explicitly return NULL in a couple more cases.  Move assertion
>   on debug statements and remove unreachable code.
>   (reset_debug_binding): Do not test id->retbnd.
>   (expand_call_inline): Do not set it.

[PATCH][AArch64] Add support for Arm Cortex-A76

[Kyrill Tkachov]

Hi all,

The Cortex-A76 is an Armv8.2-A processor with dotproduct and FP16 support.
It can be paired with the Cortex-A55 and hence the option
-mcpu/-mtune=cortex-a76.cortex-a55 is also introduced.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

2018-06-27  Kyrylo Tkachov  

* config/aarch64/aarch64-cores.def (cortex-a76): New entry.
(cortex-a76.cortex-a55): Likewise.
* config/aarch64/aarch64-tune.md: Regenerate.
* doc/invoke.texi (AArch64 Options): Document cortex-a76 and
cortex-a76.cortex-a55.
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index e64d8314fa9dd159d46c7047b0eaaa89e29c612c..3d876b8049dfbc3187ee4f13c9c83598e4cbd83e 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -85,6 +85,7 @@ AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  AARCH64_FL_FOR
 /* ARM ('A') cores. */
 AARCH64_CORE("cortex-a55",  cortexa55, cortexa53, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa53, 0x41, 0xd05, -1)
 AARCH64_CORE("cortex-a75",  cortexa75, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa73, 0x41, 0xd0a, -1)
+AARCH64_CORE("cortex-a76",  cortexa76, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa72, 0x41, 0xd0b, -1)
 
 /* ARMv8.4-A Architecture Processors.  */
 
@@ -101,5 +102,6 @@ AARCH64_CORE("cortex-a73.cortex-a53",  cortexa73cortexa53, cortexa53, 8A,  AARCH
 /* ARM DynamIQ big.LITTLE configurations.  */
 
 AARCH64_CORE("cortex-a75.cortex-a55",  cortexa75cortexa55, cortexa53, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa73, 0x41, AARCH64_BIG_LITTLE (0xd0a, 0xd05), -1)
+AARCH64_CORE("cortex-a76.cortex-a55",  cortexa76cortexa55, cortexa53, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa72, 0x41, AARCH64_BIG_LITTLE (0xd0b, 0xd05), -1)
 
 #undef AARCH64_CORE
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 7b3a7460561ee87e13799f726919c3f870781f6d..f8c8f6a82b325194e31d61c734e3f96e0196 100644
--- a/gcc/config/aarch64/aarch64-tune.md
+++ b/gcc/config/aarch64/aarch64-tune.md
@@ -1,5 +1,5 @@
 ;; -*- buffer-read-only: t -*-
 ;; Generated automatically by gentune.sh from aarch64-cores.def
 (define_attr "tune"
-	"cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,thunderxt81,thunderxt83,xgene1,falkor,qdf24xx,exynosm1,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55"
+	"cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,thunderxt81,thunderxt83,xgene1,falkor,qdf24xx,exynosm1,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
 	(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 79c47f4bb514a6183fe744c1d88ba4396ed06714..053f9080bff69371ed2983e5d0943c768f694fcb 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14633,18 +14633,19 @@ Specify the name of the target processor for which GCC should tune the
 performance of the code.  Permissible values for this option are:
 @samp{generic}, @samp{cortex-a35}, @samp{cortex-a53}, @samp{cortex-a55},
 @samp{cortex-a57}, @samp{cortex-a72}, @samp{cortex-a73}, @samp{cortex-a75},
-@samp{exynos-m1}, @samp{falkor}, @samp{qdf24xx}, @samp{saphira},
-@samp{xgene1}, @samp{vulcan}, @samp{thunderx},
+@samp{cortex-a76}, @samp{exynos-m1}, @samp{falkor}, @samp{qdf24xx},
+@samp{saphira}, @samp{xgene1}, @samp{vulcan}, @samp{thunderx},
 @samp{thunderxt88}, @samp{thunderxt88p1}, @samp{thunderxt81},
 @samp{thunderxt83}, @samp{thunderx2t99}, @samp{cortex-a57.cortex-a53},
 @samp{cortex-a72.cortex-a53}, @samp{cortex-a73.cortex-a35},
 @samp{cortex-a73.cortex-a53}, @samp{cortex-a75.cortex-a55},
+@samp{cortex-a75.cortex-a55}
 @samp{native}.
 
 The values @samp{cortex-a57.cortex-a53}, @samp{cortex-a72.cortex-a53},
 @samp{cortex-a73.cortex-a35}, @samp{cortex-a73.cortex-a53},
-@samp{cortex-a75.cortex-a55} specify that GCC should tune for a
-big.LITTLE system.
+@samp{cortex-a75.cortex-a55}, @samp{cortex-a76.cortex-a55} specify that GCC
+should tune for a big.LITTLE system.
 
 Additionally on native AArch64 GNU/Linux systems the value
 @samp{native} tunes performance to the host system.  This option has no effect

[PATCH][arm] Add support for Arm Cortex-A76

[Kyrill Tkachov]

Hi all,

The Cortex-A76 is an Armv8.2-A processor with dotproduct and FP16 support.
It can be paired with the Cortex-A55 and hence the option
-mcpu/-mtune=cortex-a76.cortex-a55 is also introduced.

Bootstrapped and tested on arm-none-linux-gnueabihf.

Committing to trunk.

Thanks,
Kyrill

2018-06-27  Kyrylo Tkachov  

* config/arm/arm-cpus.in (cortex-a76): New entry.
(cortex-a76.cortex-a55): Likewise.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/arm-tune.md: Likewise.
* config/arm/driver-arm.c (arm_cpu_table): Add Cortex-A76 entry.
* doc/invoke.texi (ARM Options): Document cortex-a76 and
cortex-a76.cortex-a55.
diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
index aec73b5cae0b9d62c521c230aff510ce3d816e3b..e100610a58364f78489a72ea8bfdfedf8d3ca47b 100644
--- a/gcc/config/arm/arm-cpus.in
+++ b/gcc/config/arm/arm-cpus.in
@@ -1339,6 +1339,15 @@ begin cpu cortex-a75
  costs cortex_a73
 end cpu cortex-a75
 
+begin cpu cortex-a76
+ cname cortexa76
+ tune for cortex-a57
+ tune flags LDSCHED
+ architecture armv8.2-a+fp16+dotprod
+ fpu neon-fp-armv8
+ option crypto add FP_ARMv8 CRYPTO
+ costs cortex_a57
+end cpu cortex-a76
 
 # ARMv8.2 A-profile ARM DynamIQ big.LITTLE implementations
 begin cpu cortex-a75.cortex-a55
@@ -1351,6 +1360,16 @@ begin cpu cortex-a75.cortex-a55
  costs cortex_a73
 end cpu cortex-a75.cortex-a55
 
+begin cpu cortex-a76.cortex-a55
+ cname cortexa76cortexa55
+ tune for cortex-a53
+ tune flags LDSCHED
+ architecture armv8.2-a+fp16+dotprod
+ fpu neon-fp-armv8
+ option crypto add FP_ARMv8 CRYPTO
+ costs cortex_a57
+end cpu cortex-a76.cortex-a55
+
 # V8 M-profile implementations.
 begin cpu cortex-m23
  cname cortexm23
diff --git a/gcc/config/arm/arm-tables.opt b/gcc/config/arm/arm-tables.opt
index 0ffb4c86ca46718bbfaf65eb41ab8e87f924e903..eacee746a39912d04aa03c636f9a95e0e72ce43b 100644
--- a/gcc/config/arm/arm-tables.opt
+++ b/gcc/config/arm/arm-tables.opt
@@ -280,9 +280,15 @@ EnumValue
 Enum(processor_type) String(cortex-a75) Value( TARGET_CPU_cortexa75)
 
 EnumValue
+Enum(processor_type) String(cortex-a76) Value( TARGET_CPU_cortexa76)
+
+EnumValue
 Enum(processor_type) String(cortex-a75.cortex-a55) Value( TARGET_CPU_cortexa75cortexa55)
 
 EnumValue
+Enum(processor_type) String(cortex-a76.cortex-a55) Value( TARGET_CPU_cortexa76cortexa55)
+
+EnumValue
 Enum(processor_type) String(cortex-m23) Value( TARGET_CPU_cortexm23)
 
 EnumValue
diff --git a/gcc/config/arm/arm-tune.md b/gcc/config/arm/arm-tune.md
index 877e3465147b8b829166b8c0f9c464ca38e0b73a..f64c1ef176de6c31659cce35326de8393e9cd886 100644
--- a/gcc/config/arm/arm-tune.md
+++ b/gcc/config/arm/arm-tune.md
@@ -49,6 +49,7 @@ (define_attr "tune"
 	cortexa72,cortexa73,exynosm1,
 	xgene1,cortexa57cortexa53,cortexa72cortexa53,
 	cortexa73cortexa35,cortexa73cortexa53,cortexa55,
-	cortexa75,cortexa75cortexa55,cortexm23,
-	cortexm33,cortexr52"
+	cortexa75,cortexa76,cortexa75cortexa55,
+	cortexa76cortexa55,cortexm23,cortexm33,
+	cortexr52"
 	(const (symbol_ref "((enum attr_tune) arm_tune)")))
diff --git a/gcc/config/arm/driver-arm.c b/gcc/config/arm/driver-arm.c
index dc2f1de01a8de89adccfde3834ae7a04fa3095a6..356a5e664b6bb9489f98d3cfe54703f6aadf8ed4 100644
--- a/gcc/config/arm/driver-arm.c
+++ b/gcc/config/arm/driver-arm.c
@@ -56,6 +56,7 @@ static struct vendor_cpu arm_cpu_table[] = {
 {"0xd09", "armv8-a+crc", "cortex-a73"},
 {"0xd05", "armv8.2-a+fp16+dotprod", "cortex-a55"},
 {"0xd0a", "armv8.2-a+fp16+dotprod", "cortex-a75"},
+{"0xd0b", "armv8.2-a+fp16+dotprod", "cortex-a76"},
 {"0xc14", "armv7-r", "cortex-r4"},
 {"0xc15", "armv7-r", "cortex-r5"},
 {"0xc17", "armv7-r", "cortex-r7"},
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a56b6afc0167e8589aa3b5372c29342e3372a833..a6f432422c96e84c161d11786f795f2c35ec7e97 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -16281,8 +16281,8 @@ Permissible names are: @samp{arm2}, @samp{arm250},
 @samp{cortex-a9}, @samp{cortex-a12}, @samp{cortex-a15}, @samp{cortex-a17},
 @samp{cortex-a32}, @samp{cortex-a35}, @samp{cortex-a53}, @samp{cortex-a55},
 @samp{cortex-a57}, @samp{cortex-a72}, @samp{cortex-a73}, @samp{cortex-a75},
-@samp{cortex-r4}, @samp{cortex-r4f}, @samp{cortex-r5}, @samp{cortex-r7},
-@samp{cortex-r8}, @samp{cortex-r52},
+@samp{cortex-a76}, @samp{cortex-r4}, @samp{cortex-r4f}, @samp{cortex-r5},
+@samp{cortex-r7}, @samp{cortex-r8}, @samp{cortex-r52},
 @samp{cortex-m33},
 @samp{cortex-m23},
 @samp{cortex-m7},
@@ -16306,7 +16306,7 @@ of the code for a big.LITTLE system.  Permissible names are:
 @samp{cortex-a15.cortex-a7}, @samp{cortex-a17.cortex-a7},
 @samp{cortex-a57.cortex-a53}, @samp{cortex-a72.cortex-a53},
 @samp{cortex-a72.cortex-a35}, @samp{cortex-a73.cortex-a53},
-@samp{cortex-a75.cortex-a55}.
+@samp{cortex-a75.cortex-a55}, @samp{cortex-a76.cortex-a55}.
 
 @option{-mtune=generic-@var{arch}} specifies that GCC should tune the
 performance for a blend of processors within architecture 

[9b/n] PR85694: Make vect_is_simple_use look through pattern statements

[Richard Sandiford]

Richard Sandiford  writes:
> Richard Biener  writes:
>> On Mon, Jun 18, 2018 at 5:04 PM Richard Sandiford
>>  wrote:
>>>
>>> When following the definitions of SSA names, some recognisers
>>> already cope with statements that have been replaced by patterns.
>>> This patch makes that happen automatically for users of
>>> type_conversion_p and vect_get_internal_def.  It also adds
>>> a vect_look_through_pattern helper that can be used directly.
>>>
>>> The reason for doing this is that the main patch for PR85694
>>> makes over_widening handle more general cases.  These over-widened
>>> patterns can still be useful when matching later statements;
>>> e.g. an overwidened MULT_EXPR could be the input to a DOT_PROD_EXPR.
>>>
>>> The patch doesn't do anything with the STMT_VINFO_IN_PATTERN_P checks
>>> in vect_recog_over_widening_pattern or vect_recog_widen_shift_pattern
>>> since later patches rewrite them anyway.
>>>
>>> Doing this fixed an XFAIL in vect-reduc-dot-u16b.c.
>>>
>>> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
>>
>> Hmm.  It seems to me that *def_stmt for vect_is_simple_use should
>> eventually be the pattern def given the vectype overload takes the
>> vectype from the pattern def already but oddly enough the
>> DEF_TYPE is taken from the non-pattern stmt.
>>
>> I wonder which callers look at def_stmt at all (and how...)
>>
>> I guess swapping the def_stmt and dt arguments and adding yet another
>> overload to remove all unused _stmt args might this easier to review...
>>
>> So - I'm suggesting to change vect_is_simple_use.
>
> OK, I'll try that.  Might end up being its own mini-series. :-)

And here's the second and final part: make vect_is_simple_use check
whether a defining statement has been replaced by a pattern statement,
and if so return the pattern statement instead.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-14  Richard Sandiford  

gcc/
* tree-vect-loop.c (vectorizable_reduction): Assert that the
phi is not a pattern statement and has not been replaced by
a pattern statement.
* tree-vect-patterns.c (type_conversion_p): Don't check
STMT_VINFO_IN_PATTERN_P.
(vect_recog_vector_vector_shift_pattern): Likewise.
(vect_recog_dot_prod_pattern): Expect vect_is_simple_use to return
the pattern statement rather than the original statement; check
directly for a WIDEN_MULT_EXPR here.
* tree-vect-slp.c (vect_get_and_check_slp_defs): Expect
vect_is_simple_use to return the pattern statement rather
than the original statement; use is_pattern_stmt_p to check
for such a pattern statement.
* tree-vect-stmts.c (process_use): Expect vect_is_simple_use
to return the pattern statement rather than the original statement;
don't do the same transformation here.
(vect_is_simple_use): If the defining statement has been replaced
by a pattern statement, return the pattern statement instead.
Remove the corresponding (local) transformation from the vectype
overload.

gcc/testsuite/
* gcc.dg/vect/vect-reduc-dot-u16b.c: Remove xfail and update the
test for vectorization along the lines described in the comment.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c2018-06-27 10:27:31.782458413 +0100
+++ gcc/tree-vect-loop.c2018-06-27 10:27:34.490434751 +0100
@@ -6482,6 +6482,8 @@ vectorizable_reduction (gimple *stmt, gi
 }
 
   stmt_vec_info reduc_def_info = vinfo_for_stmt (reduc_def_stmt);
+  /* PHIs should not participate in patterns.  */
+  gcc_assert (!STMT_VINFO_RELATED_STMT (reduc_def_info));
   enum vect_reduction_type v_reduc_type
 = STMT_VINFO_REDUC_TYPE (reduc_def_info);
   gimple *tmp = STMT_VINFO_REDUC_DEF (reduc_def_info);
Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c2018-06-27 10:27:31.782458413 +0100
+++ gcc/tree-vect-patterns.c2018-06-27 10:27:34.490434751 +0100
@@ -193,13 +193,6 @@ type_conversion_p (tree name, gimple *us
   if (!*def_stmt)
 return false;
 
-  if (dt == vect_internal_def)
-{
-  stmt_vec_info def_vinfo = vinfo_for_stmt (*def_stmt);
-  if (STMT_VINFO_IN_PATTERN_P (def_vinfo))
-   return false;
-}
-
   if (!is_gimple_assign (*def_stmt))
 return false;
 
@@ -383,20 +376,11 @@ vect_recog_dot_prod_pattern (vec (mult_vinfo->stmt);
-  if (!mult || gimple_assign_rhs_code (mult) != MULT_EXPR)
+  if (!mult)
 return NULL;
-  if (STMT_VINFO_IN_PATTERN_P (mult_vinfo))
+  if (gimple_assign_rhs_code (mult) == WIDEN_MULT_EXPR)
 {
   /* Has been detected as a widening multiplication?  */
-
-  mult = dyn_cast  (STMT_VINFO_RELATED_STMT (mult_vinfo));
-  if (!mult || gimple_assign_rhs_code (mult) != WIDEN_MULT_EXPR)
-return NULL;
-  

[9a/n] PR85694: Reorder vect_is_simple_use arguments

[Richard Sandiford]

Richard Sandiford  writes:
> Richard Biener  writes:
>> On Mon, Jun 18, 2018 at 5:04 PM Richard Sandiford
>>  wrote:
>>>
>>> When following the definitions of SSA names, some recognisers
>>> already cope with statements that have been replaced by patterns.
>>> This patch makes that happen automatically for users of
>>> type_conversion_p and vect_get_internal_def.  It also adds
>>> a vect_look_through_pattern helper that can be used directly.
>>>
>>> The reason for doing this is that the main patch for PR85694
>>> makes over_widening handle more general cases.  These over-widened
>>> patterns can still be useful when matching later statements;
>>> e.g. an overwidened MULT_EXPR could be the input to a DOT_PROD_EXPR.
>>>
>>> The patch doesn't do anything with the STMT_VINFO_IN_PATTERN_P checks
>>> in vect_recog_over_widening_pattern or vect_recog_widen_shift_pattern
>>> since later patches rewrite them anyway.
>>>
>>> Doing this fixed an XFAIL in vect-reduc-dot-u16b.c.
>>>
>>> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
>>
>> Hmm.  It seems to me that *def_stmt for vect_is_simple_use should
>> eventually be the pattern def given the vectype overload takes the
>> vectype from the pattern def already but oddly enough the
>> DEF_TYPE is taken from the non-pattern stmt.
>>
>> I wonder which callers look at def_stmt at all (and how...)
>>
>> I guess swapping the def_stmt and dt arguments and adding yet another
>> overload to remove all unused _stmt args might this easier to review...
>>
>> So - I'm suggesting to change vect_is_simple_use.
>
> OK, I'll try that.  Might end up being its own mini-series. :-)

Turned out to be simpler than feared. :-)

This patch does the first bit: reorder the arguments to
vect_is_simple_use so that def_stmt comes last and is optional.
Many callers can then drop it, making it more obvious which of the
remaining calls would be affected by the next patch.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-27  Richard Sandiford  

gcc/
* tree-vectorizer.h (vect_is_simple_use): Move the gimple ** to the
end and default to null.
* tree-vect-loop.c (vect_create_epilog_for_reduction)
(vectorizable_reduction): Update calls accordingly, dropping the
gimple ** argument if the passed-back statement isn't needed.
* tree-vect-patterns.c (vect_get_internal_def, type_conversion_p)
(vect_recog_rotate_pattern): Likewise.
(vect_recog_mask_conversion_pattern): Likewise.
* tree-vect-slp.c (vect_get_and_check_slp_defs): Likewise.
(vect_mask_constant_operand_p): Likewise.
* tree-vect-stmts.c (is_simple_and_all_uses_invariant, process_use):
(vect_model_simple_cost, vect_get_vec_def_for_operand): Likewise.
(get_group_load_store_type, get_load_store_type): Likewise.
(vect_check_load_store_mask, vect_check_store_rhs): Likewise.
(vectorizable_call, vectorizable_simd_clone_call): Likewise.
(vectorizable_conversion, vectorizable_assignment): Likewise.
(vectorizable_shift, vectorizable_operation): Likewise.
(vectorizable_store, vect_is_simple_cond): Likewise.
(vectorizable_condition, vectorizable_comparison): Likewise.
(get_same_sized_vectype, vect_get_mask_type_for_stmt): Likewise.
(vect_is_simple_use): Rename the def_stmt argument to def_stmt_out
and move it to the end.  Cope with null def_stmt_outs.

Index: gcc/tree-vectorizer.h
===
--- gcc/tree-vectorizer.h   2018-06-27 10:27:12.366628072 +0100
+++ gcc/tree-vectorizer.h   2018-06-27 10:27:31.782458413 +0100
@@ -1476,10 +1476,10 @@ extern tree get_vectype_for_scalar_type_
 extern tree get_mask_type_for_scalar_type (tree);
 extern tree get_same_sized_vectype (tree, tree);
 extern bool vect_get_loop_mask_type (loop_vec_info);
-extern bool vect_is_simple_use (tree, vec_info *, gimple **,
-enum vect_def_type *);
-extern bool vect_is_simple_use (tree, vec_info *, gimple **,
-   enum vect_def_type *, tree *);
+extern bool vect_is_simple_use (tree, vec_info *, enum vect_def_type *,
+   gimple ** = NULL);
+extern bool vect_is_simple_use (tree, vec_info *, enum vect_def_type *,
+   tree *, gimple ** = NULL);
 extern bool supportable_widening_operation (enum tree_code, gimple *, tree,
tree, enum tree_code *,
enum tree_code *, int *,
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c2018-06-27 10:27:09.038657152 +0100
+++ gcc/tree-vect-loop.c2018-06-27 10:27:31.782458413 +0100
@@ -4567,7 +4567,6 @@ vect_create_epilog_for_reduction (vecvinfo, def_stmt, ))
+  if (!vect_is_simple_use 

Re: [patch, fortran] Handling of .and. and .or. expressions

[Janus Weil]

2018-06-27 10:09 GMT+02:00 Janne Blomqvist :
> On Wed, Jun 27, 2018 at 10:52 AM, Janus Weil  wrote:
>>
>> 2018-06-27 9:42 GMT+02:00 Jakub Jelinek :
>> > On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
>> >> > and have some non-default aggressive
>> >> > optimization option that would optimize away in the FE impure
>> >> > function calls
>> >>
>> >> IMHO an optimization to remove functions calls is unproblematic only
>> >> for pure functions, but as long as it is guarded by a non-default
>> >
>> > For pure functions, which are hopefully marked as ECF_PURE for the
>> > middle-end
>>
>> Not sure if that's the case. Grepping for ECF_PURE in
>> trunk/gcc/fortran only yields a single occurrence:
>>
>> f95-lang.c:#define ATTR_PURE_NOTHROW_LEAF_LIST(ECF_NOTHROW |
>> ECF_LEAF | ECF_PURE)
>>
>> Seems like that is only used for built-ins?
>>
>>
>> > the middle-end can already optimize away those calls where the
>> > result isn't needed.
>>
>> Ah, great. Even with TRUTH_AND_EXPR, you mean?
>
> How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and then
> check benchmark results (polyhedron, spec etc.)? If performance worsens, we
> revert, if it improves, great, lets keep it?

I would definitely support that. I cannot imagine that it will have a
large impact on benchmarks, but it's certainly a good idea to check.
(After all: ifort, which is usually perceived as being slightly ahead
of GCC in terms of performance, does not do this kind of
short-circuiting either.)

If the middle-end already does all 'non-problematic' optimizations by
itself, all the better.


> To clarify, I'm not objecting to using TRUTH_{AND|OR}_EXPR, I'm objecting to
> the notion that this is somehow "more correct" or "less bad" than the
> current short-circuiting. The Fortran standard does not specify an
> evaluation strategy; IMHO very unfortunately, but it is what it is.

It is very unfortunate, and it means that the Fortran standard simply
does not provide a measure for "more correct" here. (My common-sense
drop-in notion of correctness would be that an optimization is
'correct' as long as it can be proven to not change any results.)

Cheers,
Janus

Re: [C++ Patch] More location fixes to grokdeclarator

[Paolo Carlini]

Hi David,

On 27/06/2018 01:52, David Malcolm wrote:

On Tue, 2018-06-26 at 01:44 +0200, Paolo Carlini wrote:

Hi,

this includes straightforward tweaks to check_concept_fn and quite a
bit
of additional work on grokdeclarator: most of it is also rather
straightforward. In a few places there is the subtlety that we want
to
handle together ds_storage_class and ds_thread, whichever location
is
the smallest but != UNKNOWN_LOCATION (UNKNWON_LOCATION meaning that
the
issue is with the other one) or use the biggest location when say
ds_virtual and ds_storage_class conflict, because - I believe - we
want
to point to the place where we give up. Thus I added the
min_location
and max_location helpers.

Note that directly comparing location_t values can be problematic: (one
value might be an ad-hoc location, and the other not; one might be a
macro expansion, etc).

You might want to use linemap_compare_locations or
linemap_location_before_p for this.
Thanks David, I was not aware of this issue. In the below I amended the 
new functions and the existing smallest_type_quals_location (which I 
wrote a while ago) to use linemap_location_before_p.


Thanks again,
Paolo.

/
Index: cp/decl.c
===
--- cp/decl.c   (revision 262178)
+++ cp/decl.c   (working copy)
@@ -8545,15 +8545,18 @@ check_concept_fn (tree fn)
 {
   // A constraint is nullary.
   if (DECL_ARGUMENTS (fn))
-error ("concept %q#D declared with function parameters", fn);
+error_at (DECL_SOURCE_LOCATION (fn),
+ "concept %q#D declared with function parameters", fn);
 
   // The declared return type of the concept shall be bool, and
   // it shall not be deduced from it definition.
   tree type = TREE_TYPE (TREE_TYPE (fn));
   if (is_auto (type))
-error ("concept %q#D declared with a deduced return type", fn);
+error_at (DECL_SOURCE_LOCATION (fn),
+ "concept %q#D declared with a deduced return type", fn);
   else if (type != boolean_type_node)
-error ("concept %q#D with non-% return type %qT", fn, type);
+error_at (DECL_SOURCE_LOCATION (fn),
+ "concept %q#D with non-% return type %qT", fn, type);
 }
 
 /* Helper function.  Replace the temporary this parameter injected
@@ -9808,16 +9811,42 @@ smallest_type_quals_location (int type_quals, cons
 loc = locations[ds_const];
 
   if ((type_quals & TYPE_QUAL_VOLATILE)
-  && (loc == UNKNOWN_LOCATION || locations[ds_volatile] < loc))
+  && (loc == UNKNOWN_LOCATION
+ || linemap_location_before_p (line_table,
+   locations[ds_volatile], loc)))
 loc = locations[ds_volatile];
 
   if ((type_quals & TYPE_QUAL_RESTRICT)
-  && (loc == UNKNOWN_LOCATION || locations[ds_restrict] < loc))
+  && (loc == UNKNOWN_LOCATION
+ || linemap_location_before_p (line_table,
+   locations[ds_restrict], loc)))
 loc = locations[ds_restrict];
 
   return loc;
 }
 
+/* Returns the smallest location.  */
+
+static location_t
+min_location (location_t loca, location_t locb)
+{
+  if (loca == UNKNOWN_LOCATION
+  || (locb != UNKNOWN_LOCATION
+ && linemap_location_before_p (line_table, locb, loca)))
+return locb;
+  return loca;
+}
+
+/* Returns the biggest location.  */
+
+static location_t
+max_location (location_t loca, location_t locb)
+{
+  if (linemap_location_before_p (line_table, loca, locb))
+return locb;
+  return loca;
+}
+
 /* Check that it's OK to declare a function with the indicated TYPE
and TYPE_QUALS.  SFK indicates the kind of special function (if any)
that this function is.  OPTYPE is the type given in a conversion
@@ -10710,14 +10739,18 @@ grokdeclarator (const cp_declarator *declarator,
 {
   if (staticp == 2)
{
- error ("member %qD cannot be declared both % "
-"and %", dname);
+ error_at (max_location (declspecs->locations[ds_virtual],
+ declspecs->locations[ds_storage_class]),
+   "member %qD cannot be declared both % "
+   "and %", dname);
  storage_class = sc_none;
  staticp = 0;
}
   if (constexpr_p)
-   error ("member %qD cannot be declared both % "
-  "and %", dname);
+   error_at (max_location (declspecs->locations[ds_virtual],
+   declspecs->locations[ds_constexpr]),
+ "member %qD cannot be declared both % "
+ "and %", dname);
 }
   friendp = decl_spec_seq_has_spec_p (declspecs, ds_friend);
 
@@ -10726,18 +10759,27 @@ grokdeclarator (const cp_declarator *declarator,
 {
   if (typedef_p)
{
- error ("typedef declaration invalid in parameter declaration");
+ error_at (declspecs->locations[ds_typedef],
+   "typedef declaration invalid in parameter declaration");
  return 

Re: [RFC PATCH 0/6] some vxworks/powerpc patches

[Olivier Hainque]

Hello Rasmus,

> On 26 Jun 2018, at 14:45, Rasmus Villemoes  wrote:
> 
> On 2018-06-19 18:45, Olivier Hainque wrote:
>> 
>> Before we get there: are you familiar with the "munch" facility
>> of VxWorks ?
> 
> Yes, but doing regexp match on nm output feels wrong (though I am aware
> that that is how things have been done for decades), and I really prefer
> using the modern methods, which also allows e.g. use of constructor
> priorities.

I agree the perspective of having an alternate mechanism is
attractive :)

>> I'm a bit worried that forcing .init_array for constructors
>> might not work for RTPs, at least on some versions of VxWorks.
>> 
>> We probably would need to fallback to ".ctors" as the section
>> base name for not so recent versions. I'm not clear on all the
>> ramifications there.
> 
> Hm, but if somebody built a compiler with --enable-initfini-array today
> and passed -mrtp to it, they would already get .init_array instead of
> .ctors, no? I.e., initfini-array.h would be included by tm.h after
> vxworks.h, and the logic there would unconditionally override
> vxworks.h's setting of TARGET_ASM_CONSTRUCTOR. So this "forcing" seems
> to happen already for such a compiler, regardless of my patch?

Right. It's just that there is no trace of init-fini support
before the patch, so it is not really expected to work. The
presence of conditions on HAVE_INITFINI_ARRAY here and there sends
a pretty strong signal that --enable-initfini-array is expected
to do something sensible, and obviously breaking RTPs would be
annoying.

Now the patches we're discussing (without 4 and 5) are non-intrusive
enough to allow a quick understanding and simple definition of the effects,
and it's not clear that RTPs would indeed be broken to this is not
blocking at this stage.

This can be seen as a step forward which maybe will call for adjustments
for RTPs.

>> 6/6:
>>> vxworks: don't define vxworks_asm_out_constructor when using .init_array
>> 
>> Would be ok together with the previous one, and as long as we don't
>> uncover fallouts for RTPs (meaning, we might have to revisit this in the
>> future).
> 
> See above, I don't see how that could happen. Patch 6/6 is essentially a
> no-op, except that it makes the compiler binary a tiny bit smaller.

In the current state, I agree. Experiments on RTPs might show a need
for adjustments but we're not there and it's fine to defer this part.

>> 2/6:
>>> libgcc: add crt{begin,end} for powerpc-wrs-vxworks target
>> 
>> That one would be fine as well. Even if we don't immediately add them
>> to link closures from the config files (see below), I see how handy it
>> can be to be able to reference them from user specs for instance.
> 
> Yes, I hope that building and installing crtbegin/end should be
> harmless; it just requires that crtstuff.c actually compiles cleanly.
> 
>> 4 and 5/6
>>> powerpc/vxworks: add {START,END}FILE_SPEC for HAVE_INITFINI_ARRAY_SUPPORT
>>> powerpc/vxworks: [hack] add crti.o file
>> 
>> I really think those two should stay out.

> Yes, these two are the most hackish ones, and I don't much like them
> myself. So I'm happy to leave them out of mainline, and just use them
> (or something equivalent) in-house.

Ok, glad we agree on this.

> Using a custom spec file, custom linker script and something like the
> vx_ctors_begin.o will probably be the long-term solution for us. We'd be
> really happy to be able to use an upstream gcc out-of-the-box apart from
> those few pieces of glue.
> 
> I'll fix and resend 1,2,3,6.

Works for me. I won't be able to review for 3+ weeks.

> Once again, thank you for you time, Olivier!

Sure. Thanks for your proposing the approach and input
on how it works for you. This is an interesting way to address
a pretty hairy issue.

Regards,

Olivier

Re: [PATCH][AARCH64] PR target/84521 Fix frame pointer corruption with -fomit-frame-pointer with __builtin_setjmp

[Eric Botcazou]

> This test can easily be changed not to use optimize since it doesn't look
> like it needs it. We really need to tests these builtins properly,
> otherwise they will continue to fail on most targets.

As far as I can see PR target/84521 has been reported only for Aarch64 so I'd 
just leave the other targets alone (and avoid propagating FUD if possible).

-- 
Eric Botcazou