Re: [PATCH][AArch64] Remove '*' from movsi/di/ti patterns

[Andrew Pinski]

On Tue, Sep 12, 2017 at 9:10 AM, James Greenhalgh
 wrote:
> On Wed, Jul 26, 2017 at 02:46:14PM +0100, Wilco Dijkstra wrote:
>> Remove the remaining uses of '*' from the movsi/di/ti patterns.
>> Using '*' in alternatives is typically incorrect at it tells the register
>> allocator to ignore those alternatives.  So remove these from all the
>> integer move patterns.  This removes unnecessary int to float moves, for
>> example gcc.target/aarch64/pr62178.c no longer generates a redundant fmov
>> since the w = m variant is now allowed.
>>
>> Passes regress & bootstrap, OK for commit?
>
> OK.
>
> These attempts at register allocator costs are just trouble!

Note this caused a few testsuite failures:
gcc.target/aarch64/vmov_n_1.c scan-assembler-times dup\\tv[0-9]+.2d,
v[0-9]+.d\\[[0-9]+\\] 1
gcc.target/aarch64/vmov_n_1.c scan-assembler-times dup\\tv[0-9]+.2d, x[0-9]+ 2
gcc.target/aarch64/vmov_n_1.c scan-assembler-times dup\\tv[0-9]+.2s,
v[0-9]+.s\\[[0-9]+\\] 1
gcc.target/aarch64/vmov_n_1.c scan-assembler-times dup\\tv[0-9]+.2s, w[0-9]+ 2
gcc.target/aarch64/vmov_n_1.c scan-assembler-times dup\\tv[0-9]+.4s,
v[0-9]+.s\\[[0-9]+\\] 1
gcc.target/aarch64/vmov_n_1.c scan-assembler-times dup\\tv[0-9]+.4s, w[0-9]+ 2

I suspect we are using the d/s registers in these cases rather than
x/w register (I did not look into the code generation to check that
but if we are then this is better code anyways).

Thanks,
Andrew

>
> Thanks,
> James
>
>>
>> ChangeLog:
>> 2017-07-26  Wilco Dijkstra  
>>
>>   * gcc/config/aarch64/aarch64.md (movsi_aarch64): Remove all '*'.
>>   (movdi_aarch64): Likewise.
>>   (movti_aarch64): Likewise.
>> --
>>

Re: [PATCH version 2, rs6000] Add builtins to convert from float/double to int/long using current rounding mode

[Michael Meissner]

On Tue, Sep 12, 2017 at 05:41:34PM -0500, Segher Boessenkool wrote:
> This needs "TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT" I think?  Which
> is the same as "TARGET_DF_FPR".  "lrintdi2" also has "TARGET_FPRND"
> but that is a mistake I think.  Cc:ing Mike for that.

TARGET_FPRND is for ISA 2.02 (power5+) which added the various round to integer
instructions.  So, unless we are going to stop supporting older machines, it is
needed.

> The rest looks fine.  Okay for trunk with those changes, or resend if
> you prefer I take another look.  Thanks!

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

Re: [PATCH] Factor out division by squares and remove division around comparisons (0/2)

[Jeff Law]

On 09/06/2017 03:54 AM, Jackson Woodruff wrote:
> Hi all,
> 
> This patch is split from part (1/2). It includes the patterns that have
> been moved out of fold-const.c
> 
> 
> It also removes an (almost entirely) redundant pattern:
> 
> (A / C1) +- (A / C2) -> A * (1 / C1 +- 1 / C2)
> 
> which was only used in special cases, either with combinations
> of flags like -fno-reciprocal-math -funsafe-math-optimizations
> and cases where C was sNaN, or small enough to result in infinity.
> 
> This pattern is covered by:
> 
>(A / C1) +- (A / C2) -> (with O1 and reciprocal math)
>A * (1 / C1) +- A * (1 / C2) ->
>A * (1 / C1 +- 1 / C2)
> 
> The previous pattern required funsafe-math-optimizations.
> 
> To adjust for this case, the testcase has been updated to require O1 so
> that the optimization is still performed.
> 
> 
> This pattern is moved verbatim into match.pd:
> 
> (A / C) +- (B / C) -> (A +- B) / C.
> 
> OK for trunk?
> 
> Jackson
> 
> gcc/
> 
> 2017-08-30  Jackson Woodruff  
> 
> PR 71026/tree-optimization
> * match.pd: Move RDIV patterns from fold-const.c
> * fold-const.c (distribute_real_division): Removed.
> (fold_binary_loc): Remove calls to distribute_real_divison.
> 
> gcc/testsuite/
> 
> 2017-08-30  Jackson Woodruff  
> 
> PR 71026/tree-optimization
> * gcc/testsuire/gcc.dg/fold-div-1.c: Use O1.

Didn't you lose the case where the operator is MULT_EXPR rather than
RDIV_EXPR?

If I'm reading things correctly, arg0 and arg1 could be a RDIV_EXPR or a
MULT_EXPR and we distribute both cases (as long as they are both the
same code).

Your match.pd pattern only handle rdiv.

Now it may be the case that MULT_EXPR doesn't happen anymore in practice
-- the code in fold-const is quote old and much of it was written before
we regularly added tests for optimization and canonicalization.  So I'm
not surprised nothing in this testsuite trips over this omission.

ISTM you need to either argue that the MULT_EXPR case is handled
elsewhere or that it is no longer relevant.

jeff

Re: [PATCH version 2, rs6000] Add builtins to convert from float/double to int/long using current rounding mode

[Segher Boessenkool]

On Tue, Sep 12, 2017 at 02:07:43PM -0700, Carl Love wrote:
> On Tue, 2017-09-12 at 11:49 -0500, Segher Boessenkool wrote:
> > On Fri, Sep 08, 2017 at 11:41:13AM -0700, Carl Love wrote:
> > > The following patch adds support for a couple of requested builtins that
> > > convert from float/double to int / long using the current rounding
> > > mode.  I initially posted an early version of this patch which generated
> > > redundant instructions.  
> > 
> > > 2017-09-08  Carl Love  
> > > 
> > >   * config/rs6000/rs6000-builtin.def (FCTID, FCTIW): Add BU_P7_MISC_1
> > >   macro expansion for builtins.
> > >   * config/rs6000/rs6000.md (fctid, fctiw): Add define_insn for the
> > >   fctid and fctiw instructions.
> > 
> > There already is fctiwz_ for SF, DF; how do these relate?  Could they
> > be joined?  Similar for lrintdi2.
> Segher:
> 
> The requirement from Steve Munroe for the builtins was to have the
> conversions round using the current rounding mode.  Hence we need fctiw
> not fctiwz which only rounds to zero.

Ah, okay, I completely missed that "z" distinction.  I'm not actually
awake it seems.  Sorry.

> I looked at the lrintdi2 and for mode=df it is identical to my
> fctid code.  So, I removed my define_insn "fctid" and just mapped the
> builtin to lrintdfdi2.

Great!  Maybe name the other one similarly, if that makes sense?  And
then move them together too.

Some questions below.  Mostly nitpicking :-)

>   * config/rs6000/rs6000.md (fctid, fctiw): Add define_insn for the
>   fctiw instruction.

This needs updating now.

> diff --git a/gcc/config/rs6000/rs6000-builtin.def 
> b/gcc/config/rs6000/rs6000-builtin.def
> index 850164a..e85e1b3 100644
> --- a/gcc/config/rs6000/rs6000-builtin.def
> +++ b/gcc/config/rs6000/rs6000-builtin.def
> @@ -2231,6 +2231,8 @@ BU_DFP_MISC_2 (DSCRIQ,  "dscriq",   CONST,  
> dfp_dscri_td)
>  /* 1 argument BCD functions added in ISA 2.06.  */
>  BU_P7_MISC_1 (CDTBCD,"cdtbcd",   CONST,  cdtbcd)
>  BU_P7_MISC_1 (CBCDTD,"cbcdtd",   CONST,  cbcdtd)
> +BU_P7_MISC_1 (FCTID, "fctid",CONST,  lrintdfdi2)

You have spaces instead of a tab before lrintdfdi2 here.

> +BU_P7_MISC_1 (FCTIW, "fctiw",CONST,  fctiw)

Also, those two shouldn't be below the "1 arg BCD" heading; they also aren't
ISA 2.06 (the instructions are in ISA 1 already; the builtins are new).

> +(define_insn "fctiw"
> +  [(set (match_operand:SI 0 "gpc_reg_operand" "=d")
> + (unspec:SI [(match_operand:DF 1 "gpc_reg_operand" "d")]
> +UNSPEC_FCTIW))]
> +  ""

This needs "TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT" I think?  Which
is the same as "TARGET_DF_FPR".  "lrintdi2" also has "TARGET_FPRND"
but that is a mistake I think.  Cc:ing Mike for that.

The rest looks fine.  Okay for trunk with those changes, or resend if
you prefer I take another look.  Thanks!


Segher

Re: Turn SECONDARY_MEMORY_NEEDED into a hook

[Jeff Law]

On 09/12/2017 12:50 PM, Richard Sandiford wrote:
> Since the patch is going through all the definitions anyway, it seemed
> like a good opportunity to put the mode argument first, to match the
> order for register_move_cost.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2017-09-12  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * target.def (secondary_memory_needed): New hook.
>   (secondary_reload): Refer to TARGET_SECONDARY_MEMORY_NEEDED
>   instead of SECONDARY_MEMORY_NEEDED.
>   (secondary_memory_needed_mode): Likewise.
>   * hooks.h (hook_bool_mode_reg_class_t_reg_class_t_false): Declare.
>   * hooks.c (hook_bool_mode_reg_class_t_reg_class_t_false): New function.
>   * doc/tm.texi.in (SECONDARY_MEMORY_NEEDED): Replace with...
>   (TARGET_SECONDARY_MEMORY_NEEDED): ...this.
>   (SECONDARY_MEMORY_NEEDED_RTX): Update reference accordingly.
>   * doc/tm.texi: Regenerate.
>   * config/alpha/alpha.h (SECONDARY_MEMORY_NEEDED): Delete.
>   * config/alpha/alpha.c (alpha_secondary_memory_needed): New function.
>   (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   * config/i386/i386.h (SECONDARY_MEMORY_NEEDED): Delete.
>   * config/i386/i386-protos.h (ix86_secondary_memory_needed): Delete.
>   * config/i386/i386.c (inline_secondary_memory_needed): Put the
>   mode argument first and change the reg_class arguments to reg_class_t.
>   (ix86_secondary_memory_needed): Likewise.  Remove the strict parameter.
>   Make static.  Update the call to inline_secondary_memory_needed.
>   (ix86_register_move_cost): Update the call to
>   inline_secondary_memory_needed.
>   (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   * config/ia64/ia64.h (SECONDARY_MEMORY_NEEDED): Delete commented-out
>   definition.
>   * config/ia64/ia64.c (spill_xfmode_rfmode_operand): Refer to
>   TARGET_SECONDARY_MEMORY_NEEDED rather than SECONDARY_MEMORY_NEEDED
>   in comment.
>   * config/mips/mips.h (SECONDARY_MEMORY_NEEDED): Delete.
>   * config/mips/mips-protos.h (mips_secondary_memory_needed): Delete.
>   * config/mips/mips.c (mips_secondary_memory_needed): Make static
>   and match hook interface.  Add comment from mips.h.
>   (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   * config/mmix/mmix.md (truncdfsf2): Refer to
>   TARGET_SECONDARY_MEMORY_NEEDED rather than SECONDARY_MEMORY_NEEDED
>   in comment.
>   * config/pa/pa-64.h (SECONDARY_MEMORY_NEEDED): Rename to...
>   (PA_SECONDARY_MEMORY_NEEDED): ...this, and put the mode argument first.
>   * config/pa/pa.c (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   (pa_secondary_memory_needed): New function.
>   * config/pdp11/pdp11.h (SECONDARY_MEMORY_NEEDED): Delete.
>   * config/pdp11/pdp11-protos.h (pdp11_secondary_memory_needed): Delete.
>   * config/pdp11/pdp11.c (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   (pdp11_secondary_memory_needed): Make static and match hook interface.
>   * config/powerpcspe/powerpcspe.h (SECONDARY_MEMORY_NEEDED): Delete.
>   * config/powerpcspe/powerpcspe-protos.h
>   (rs6000_secondary_memory_needed_ptr): Delete.
>   * config/powerpcspe/powerpcspe.c (rs6000_secondary_memory_needed_ptr):
>   Delete.
>   (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   (rs6000_option_override_internal): Assign to
>   targetm.secondary_memory_needed rather than
>   rs6000_secondary_memory_needed_ptr.
>   (rs6000_secondary_memory_needed): Match hook interface.
>   (rs6000_debug_secondary_memory_needed): Likewise.
>   * config/riscv/riscv.h (SECONDARY_MEMORY_NEEDED): Delete.
>   * config/riscv/riscv.c (riscv_secondary_memory_needed): New function.
>   (riscv_register_move_cost): Use it instead of SECONDARY_MEMORY_NEEDED.
>   (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   * config/rs6000/rs6000.h (SECONDARY_MEMORY_NEEDED): Delete.
>   * config/rs6000/rs6000-protos.h (rs6000_secondary_memory_needed_ptr):
>   Delete.
>   * config/rs6000/rs6000.c (rs6000_secondary_memory_needed_ptr): Delete.
>   (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   (rs6000_option_override_internal): Assign to
>   targetm.secondary_memory_needed rather than
>   rs6000_secondary_memory_needed_ptr.
>   (rs6000_secondary_memory_needed): Match hook interface.
>   (rs6000_debug_secondary_memory_needed): Likewise.
>   * config/s390/s390.h (SECONDARY_MEMORY_NEEDED): Delete.
>   * config/s390/s390.c (s390_secondary_memory_needed): New function.
>   (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
>   * config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED): Delete.
>  

Re: Turn SECONDARY_MEMORY_NEEDED_MODE into a target hook

[Jeff Law]

On 09/12/2017 12:47 PM, Richard Sandiford wrote:
> It feels like SECONDARY_MEMORY_NEEDED and SECONDARY_MEMORY_NEEDED_MODE
> should be a single hook that returns the memory mode if memory is needed
> and an empty opt_mode otherwise.  The snag is this code in reload.c:
> 
>   /* If we need a memory location to copy between the two reload regs,
>  set it up now.  Note that we do the input case before making
>  the reload and the output case after.  This is due to the
>  way reloads are output.  */
> 
>   if (in_p && icode == CODE_FOR_nothing
>   && SECONDARY_MEMORY_NEEDED (rclass, reload_class, mode))
> {
>   get_secondary_mem (x, reload_mode, opnum, type);
> 
>   /* We may have just added new reloads.  Make sure we add
>  the new reload at the end.  */
>   s_reload = n_reloads;
> }
> 
> where we use "mode" to test whether a secondary reload is needed but pass
> "reload_mode" to get_secondary_mem (and thus SECONDARY_MEMORY_NEEDED_MODE).
> This difference appears to come from:
> 
> Thu Aug 21 17:56:06 1997  Richard Kenner  
> 
> * reload.c (push_secondary_reload): If SECONDARY_MEM_NEEDED,
> call get_secondary_mem for input before adding reload and
> for output after.
> (push_reload): Likewise.
> 
> which sounds like it was just moving the code, but also changed the
> get_secondary_mem mode argument from "mode" to "reload_mode".
> 
> It seems unlikely that the two modes should be different, but it's not
> obvious which one is right.  The corresponding code for output reloads
> uses "mode" consistently, like the input code did before the patch above:
> 
>   if (! in_p && icode == CODE_FOR_nothing
>   && SECONDARY_MEMORY_NEEDED (reload_class, rclass, mode))
> get_secondary_mem (x, mode, opnum, type);
> 
> while the main secondary_reload hook uses "reload_mode":
> 
>   rclass = (enum reg_class) targetm.secondary_reload (in_p, x, reload_class,
>   reload_mode, );
> 
> The difference only matters for reloads of paradoxical subregs that need
> to go through secondary memory, which is hardly a common case.  In the
> end the whole thing seemed too delicate to change, so the patch instead
> just converts the macro to a hook with itscurrent interface.


I wandered my private gcc2 archives, for Aug 1997, but didn't see
anything obviously relevant.  I don't have archives for the old gcc-bugs
list -- even if we had them and the change was in response to a bug
reported there I don't think we typically posted anything that would
allow us to map backwards from the change to the bug.

Note that Jim had changed some of this code a bit earlier in a way that
might be relevant:

commit c03001748750bec11636c34e93d77be19da49054
Author: wilson 
Date:   Wed Sep 25 00:44:04 1996 +

(push_secondary_reload): Do strip paradoxical SUBREG
even if reload_class is CLASS_CANNOT_CHANGE_SIZE.  Change reload_mode
to mode in SECONDARY_MEMORY_NEEDED and get_secondary_mem calls.


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

But nothing in the gcc2 archives about that patch either.


I won't even try to guess what's going on here.  As you note, the safe
thing to do is preserve current behavior.  We can always go back
independently and try to make this consistent and see what falls out.
Given the age, whatever port and attribute of the port in question may
be a dead end in processor architecture and no longer relevant.


> 
> There is also a change for LRA.  Previously the code was:
> 
> if (sclass == NO_REGS && dclass == NO_REGS)
>   return false;
>   #ifdef SECONDARY_MEMORY_NEEDED
> if (SECONDARY_MEMORY_NEEDED (sclass, dclass, GET_MODE (src))
>   #ifdef SECONDARY_MEMORY_NEEDED_MODE
> && ((sclass != NO_REGS && dclass != NO_REGS)
> || GET_MODE (src) != SECONDARY_MEMORY_NEEDED_MODE (GET_MODE 
> (src)))
>   #endif
> )
>   {
> *sec_mem_p = true;
> return false;
>   }
>   #endif
> 
> This allows reloads to and from memory (class == NO_REGS) to use
> secondary memory reloads.  It comes from:
> 
> 2013-05-24  Vladimir Makarov  
> 
> * lra-constraints.c (emit_spill_move): Use smaller mode for
> mem-mem moves.
> (check_and_process_move): Consider mem-reg moves for secondary
> too.
> (curr_insn_transform): Don't lose insns emitted before for
> secondary memory moves.
> (inherit_in_ebb): Mark defined reg.  Add usage only if it is not a
> reg set up in the current insn.
> 
> But the positioning of the second ifdef meant that defining
> SECONDARY_MEMORY_NEEDED_MODE to its default value was not a no-op:
> 
> (1) if a target does define SECONDARY_MEMORY_NEEDED_MODE, only cases
> that 

Re: [PATCH, rs6000] [v2] Folding of vector loads in GIMPLE

[Bill Schmidt]

> On Sep 12, 2017, at 4:08 PM, Will Schmidt  wrote:
> 
> Hi,
> 
> [PATCH, rs6000] [v2] Folding of vector loads in GIMPLE
> 
> Folding of vector loads in GIMPLE.
> 
> Add code to handle gimple folding for the vec_ld builtins.
> Remove the now obsoleted folding code for vec_ld from rs6000-c.c. Surrounding
> comments have been adjusted slightly so they continue to read OK for the
> existing vec_st code.
> 
> The resulting code is specifically verified by the powerpc/fold-vec-ld-*.c
> tests which have been posted separately.
> 
> For V2 of this patch, I've removed the chunk of code that prohibited the
> gimple fold from occurring in BE environments.   This had fixed an issue
> for me earlier during my development of the code, and turns out this was
> not necessary.  I've sniff-tested after removing that check and it looks
> OK.

Thanks!
> 
>> + /* Limit folding of loads to LE targets.  */ 
>> + if (BYTES_BIG_ENDIAN || VECTOR_ELT_ORDER_BIG)
>> +   return false;
> 
> I've restarted a regression test on this updated version.
> 
> OK for trunk (assuming successful regression test completion)  ?

Looks good to me otherwise, but Richard may have streamlining
improvements, so please wait for his review.  And of course Segher's.

Thanks,
Bill
> 
> Thanks,
> -Will
> 
> [gcc]
> 
>2017-09-12  Will Schmidt  
> 
>* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add handling
>for early folding of vector loads (ALTIVEC_BUILTIN_LVX_*).
>* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
>Remove obsoleted code for handling ALTIVEC_BUILTIN_VEC_LD.
> 
> diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
> index fbab0a2..bb8a77d 100644
> --- a/gcc/config/rs6000/rs6000-c.c
> +++ b/gcc/config/rs6000/rs6000-c.c
> @@ -6470,92 +6470,19 @@ altivec_resolve_overloaded_builtin (location_t loc, 
> tree fndecl,
>convert (TREE_TYPE (stmt), arg0));
>   stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
>   return stmt;
> }
> 
> -  /* Expand vec_ld into an expression that masks the address and
> - performs the load.  We need to expand this early to allow
> +  /* Expand vec_st into an expression that masks the address and
> + performs the store.  We need to expand this early to allow
>  the best aliasing, as by the time we get into RTL we no longer
>  are able to honor __restrict__, for example.  We may want to
>  consider this for all memory access built-ins.
> 
>  When -maltivec=be is specified, or the wrong number of arguments
>  is provided, simply punt to existing built-in processing.  */
> -  if (fcode == ALTIVEC_BUILTIN_VEC_LD
> -  && (BYTES_BIG_ENDIAN || !VECTOR_ELT_ORDER_BIG)
> -  && nargs == 2)
> -{
> -  tree arg0 = (*arglist)[0];
> -  tree arg1 = (*arglist)[1];
> -
> -  /* Strip qualifiers like "const" from the pointer arg.  */
> -  tree arg1_type = TREE_TYPE (arg1);
> -  if (!POINTER_TYPE_P (arg1_type) && TREE_CODE (arg1_type) != ARRAY_TYPE)
> - goto bad;
> -
> -  tree inner_type = TREE_TYPE (arg1_type);
> -  if (TYPE_QUALS (TREE_TYPE (arg1_type)) != 0)
> - {
> -   arg1_type = build_pointer_type (build_qualified_type (inner_type,
> - 0));
> -   arg1 = fold_convert (arg1_type, arg1);
> - }
> -
> -  /* Construct the masked address.  Let existing error handling take
> -  over if we don't have a constant offset.  */
> -  arg0 = fold (arg0);
> -
> -  if (TREE_CODE (arg0) == INTEGER_CST)
> - {
> -   if (!ptrofftype_p (TREE_TYPE (arg0)))
> - arg0 = build1 (NOP_EXPR, sizetype, arg0);
> -
> -   tree arg1_type = TREE_TYPE (arg1);
> -   if (TREE_CODE (arg1_type) == ARRAY_TYPE)
> - {
> -   arg1_type = TYPE_POINTER_TO (TREE_TYPE (arg1_type));
> -   tree const0 = build_int_cstu (sizetype, 0);
> -   tree arg1_elt0 = build_array_ref (loc, arg1, const0);
> -   arg1 = build1 (ADDR_EXPR, arg1_type, arg1_elt0);
> - }
> -
> -   tree addr = fold_build2_loc (loc, POINTER_PLUS_EXPR, arg1_type,
> -arg1, arg0);
> -   tree aligned = fold_build2_loc (loc, BIT_AND_EXPR, arg1_type, addr,
> -   build_int_cst (arg1_type, -16));
> -
> -   /* Find the built-in to get the return type so we can convert
> -  the result properly (or fall back to default handling if the
> -  arguments aren't compatible).  */
> -   for (desc = altivec_overloaded_builtins;
> -desc->code && desc->code != fcode; desc++)
> - continue;
> -
> -   for (; desc->code == fcode; desc++)
> - if (rs6000_builtin_type_compatible (TREE_TYPE (arg0), desc->op1)
> - && (rs6000_builtin_type_compatible (TREE_TYPE (arg1),
> -

Re: [PATCH, rs6000] [v2] Folding of vector loads in GIMPLE

[Will Schmidt]

Hi,

[PATCH, rs6000] [v2] Folding of vector loads in GIMPLE

Folding of vector loads in GIMPLE.

Add code to handle gimple folding for the vec_ld builtins.
Remove the now obsoleted folding code for vec_ld from rs6000-c.c. Surrounding
comments have been adjusted slightly so they continue to read OK for the
existing vec_st code.

The resulting code is specifically verified by the powerpc/fold-vec-ld-*.c
tests which have been posted separately.

For V2 of this patch, I've removed the chunk of code that prohibited the
gimple fold from occurring in BE environments.   This had fixed an issue
for me earlier during my development of the code, and turns out this was
not necessary.  I've sniff-tested after removing that check and it looks
OK.

>+ /* Limit folding of loads to LE targets.  */ 
> +  if (BYTES_BIG_ENDIAN || VECTOR_ELT_ORDER_BIG)
> +return false;

I've restarted a regression test on this updated version.

OK for trunk (assuming successful regression test completion)  ?

Thanks,
-Will

[gcc]

2017-09-12  Will Schmidt  

* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add handling
for early folding of vector loads (ALTIVEC_BUILTIN_LVX_*).
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Remove obsoleted code for handling ALTIVEC_BUILTIN_VEC_LD.

diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index fbab0a2..bb8a77d 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -6470,92 +6470,19 @@ altivec_resolve_overloaded_builtin (location_t loc, 
tree fndecl,
 convert (TREE_TYPE (stmt), arg0));
   stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
   return stmt;
 }
 
-  /* Expand vec_ld into an expression that masks the address and
- performs the load.  We need to expand this early to allow
+  /* Expand vec_st into an expression that masks the address and
+ performs the store.  We need to expand this early to allow
  the best aliasing, as by the time we get into RTL we no longer
  are able to honor __restrict__, for example.  We may want to
  consider this for all memory access built-ins.
 
  When -maltivec=be is specified, or the wrong number of arguments
  is provided, simply punt to existing built-in processing.  */
-  if (fcode == ALTIVEC_BUILTIN_VEC_LD
-  && (BYTES_BIG_ENDIAN || !VECTOR_ELT_ORDER_BIG)
-  && nargs == 2)
-{
-  tree arg0 = (*arglist)[0];
-  tree arg1 = (*arglist)[1];
-
-  /* Strip qualifiers like "const" from the pointer arg.  */
-  tree arg1_type = TREE_TYPE (arg1);
-  if (!POINTER_TYPE_P (arg1_type) && TREE_CODE (arg1_type) != ARRAY_TYPE)
-   goto bad;
-
-  tree inner_type = TREE_TYPE (arg1_type);
-  if (TYPE_QUALS (TREE_TYPE (arg1_type)) != 0)
-   {
- arg1_type = build_pointer_type (build_qualified_type (inner_type,
-   0));
- arg1 = fold_convert (arg1_type, arg1);
-   }
-
-  /* Construct the masked address.  Let existing error handling take
-over if we don't have a constant offset.  */
-  arg0 = fold (arg0);
-
-  if (TREE_CODE (arg0) == INTEGER_CST)
-   {
- if (!ptrofftype_p (TREE_TYPE (arg0)))
-   arg0 = build1 (NOP_EXPR, sizetype, arg0);
-
- tree arg1_type = TREE_TYPE (arg1);
- if (TREE_CODE (arg1_type) == ARRAY_TYPE)
-   {
- arg1_type = TYPE_POINTER_TO (TREE_TYPE (arg1_type));
- tree const0 = build_int_cstu (sizetype, 0);
- tree arg1_elt0 = build_array_ref (loc, arg1, const0);
- arg1 = build1 (ADDR_EXPR, arg1_type, arg1_elt0);
-   }
-
- tree addr = fold_build2_loc (loc, POINTER_PLUS_EXPR, arg1_type,
-  arg1, arg0);
- tree aligned = fold_build2_loc (loc, BIT_AND_EXPR, arg1_type, addr,
- build_int_cst (arg1_type, -16));
-
- /* Find the built-in to get the return type so we can convert
-the result properly (or fall back to default handling if the
-arguments aren't compatible).  */
- for (desc = altivec_overloaded_builtins;
-  desc->code && desc->code != fcode; desc++)
-   continue;
-
- for (; desc->code == fcode; desc++)
-   if (rs6000_builtin_type_compatible (TREE_TYPE (arg0), desc->op1)
-   && (rs6000_builtin_type_compatible (TREE_TYPE (arg1),
-   desc->op2)))
- {
-   tree ret_type = rs6000_builtin_type (desc->ret_type);
-   if (TYPE_MODE (ret_type) == V2DImode)
- /* Type-based aliasing analysis thinks vector long
-and vector long long are different and will put them
-in distinct alias 

Re: [PATCH version 2, rs6000] Add builtins to convert from float/double to int/long using current rounding mode

[Carl Love]

On Tue, 2017-09-12 at 11:49 -0500, Segher Boessenkool wrote:
> Hi Carl,
> 
> On Fri, Sep 08, 2017 at 11:41:13AM -0700, Carl Love wrote:
> > The following patch adds support for a couple of requested builtins that
> > convert from float/double to int / long using the current rounding
> > mode.  I initially posted an early version of this patch which generated
> > redundant instructions.  
> 
> > 2017-09-08  Carl Love  
> > 
> > * config/rs6000/rs6000-builtin.def (FCTID, FCTIW): Add BU_P7_MISC_1
> > macro expansion for builtins.
> > * config/rs6000/rs6000.md (fctid, fctiw): Add define_insn for the
> > fctid and fctiw instructions.
> 
> There already is fctiwz_ for SF, DF; how do these relate?  Could they
> be joined?  Similar for lrintdi2.
Segher:

The requirement from Steve Munroe for the builtins was to have the
conversions round using the current rounding mode.  Hence we need fctiw
not fctiwz which only rounds to zero.

I looked at the lrintdi2 and for mode=df it is identical to my
fctid code.  So, I removed my define_insn "fctid" and just mapped the
builtin to lrintdfdi2.

Pat:
>> +  ""
>> +  "fctiw %0,%1")

>These should have (set_attr "type" "fp").

Fixed that thanks.

I retested the updated patch powerpc64le-unknown-linux-gnu (Power 8 LE)
only.

Here is the updated patch.  Let me know if it still needs any work.
Thanks.

   Carl Love
--

gcc/ChangeLog:

2017-09-12  Carl Love  

* config/rs6000/rs6000-builtin.def (FCTID, FCTIW): Add BU_P7_MISC_1
macro expansion for builtins.
* config/rs6000/rs6000.md (fctid, fctiw): Add define_insn for the
fctiw instruction.

gcc/testsuite/ChangeLog:

2017-09-12 Carl Love  
* gcc.target/powerpc/builtin-fctid-fctiw-runnable.c: New test file
for the __builtin_fctid and __builtin_fctiw builtins.
---
 gcc/config/rs6000/rs6000-builtin.def   |   2 +
 gcc/config/rs6000/rs6000.md|   8 ++
 .../powerpc/builtin-fctid-fctiw-runnable.c | 138 +
 3 files changed, 148 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/powerpc/builtin-fctid-fctiw-runnable.c

diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 850164a..e85e1b3 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -2231,6 +2231,8 @@ BU_DFP_MISC_2 (DSCRIQ,"dscriq",   CONST,  
dfp_dscri_td)
 /* 1 argument BCD functions added in ISA 2.06.  */
 BU_P7_MISC_1 (CDTBCD,  "cdtbcd",   CONST,  cdtbcd)
 BU_P7_MISC_1 (CBCDTD,  "cbcdtd",   CONST,  cbcdtd)
+BU_P7_MISC_1 (FCTID,   "fctid",CONST,  lrintdfdi2)
+BU_P7_MISC_1 (FCTIW,   "fctiw",CONST,  fctiw)
 
 /* 2 argument BCD functions added in ISA 2.06.  */
 BU_P7_MISC_2 (ADDG6S,  "addg6s",   CONST,  addg6s)
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 20873ac..237be24 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -14054,6 +14054,14 @@
   [(set_attr "type" "integer")
(set_attr "length" "4")])
 
+(define_insn "fctiw"
+  [(set (match_operand:SI 0 "gpc_reg_operand" "=d")
+   (unspec:SI [(match_operand:DF 1 "gpc_reg_operand" "d")]
+  UNSPEC_FCTIW))]
+  ""
+  "fctiw %0,%1"
+  [(set_attr "type" "fp")])
+
 (define_int_iterator UNSPEC_DIV_EXTEND [UNSPEC_DIVE
UNSPEC_DIVEO
UNSPEC_DIVEU
diff --git a/gcc/testsuite/gcc.target/powerpc/builtin-fctid-fctiw-runnable.c 
b/gcc/testsuite/gcc.target/powerpc/builtin-fctid-fctiw-runnable.c
new file mode 100644
index 000..5a0e20e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/builtin-fctid-fctiw-runnable.c
@@ -0,0 +1,138 @@
+/* { dg-do run { target { powerpc*-*-* && { lp64 && p8vector_hw } } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-mcpu=power8" } */
+
+#ifdef DEBUG
+#include 
+#endif
+
+void abort (void);
+
+long
+test_bi_lrint_1 (float __A)
+{
+   return (__builtin_fctid (__A));
+}
+long
+test_bi_lrint_2 (double __A)
+{
+   return (__builtin_fctid (__A));
+}
+
+int
+test_bi_rint_1 (float __A)
+{
+   return (__builtin_fctiw (__A));
+}
+
+int
+test_bi_rint_2 (double __A)
+{
+   return (__builtin_fctiw (__A));
+}
+
+
+int main( void)
+{
+  signed long lx, expected_l;
+  double dy;
+
+  signed int x, expected_i;
+  float y;
+  
+  dy = 1.45;
+  expected_l = 1;
+  lx = __builtin_fctid (dy);
+
+  if( lx != expected_l)
+#ifdef DEBUG
+printf("ERROR: __builtin_fctid(dy= %f) = %ld, expected %ld\n",
+  dy, lx, expected_l);
+#else
+abort();
+#endif
+
+  dy = 3.51;
+  expected_l = 4;
+  lx = __builtin_fctid (dy);
+  
+  if( lx != expected_l)
+#ifdef DEBUG
+printf("ERROR: 

Re: std::forward_list optim for always equal allocator

[François Dumont]

On 12/09/2017 00:10, Jonathan Wakely wrote:

On 11/09/17 22:39 +0200, Daniel Krügler wrote:

2017-09-11 22:36 GMT+02:00 François Dumont :
[..]

So my remark was rather for the:

  _Fwd_list_iterator() noexcept
  : _M_node() { }

that could simply be

_Fwd_list_iterator() = default;

no ?


Yes, that should be fine.


I'm not sure there's much benefit to that change 

Sure, it would be a minor change.

Which is moreover not part of this patch proposal. Is the patch ok to 
commit ?


François

[SPARC] Small source location information fix

[Eric Botcazou]

output_return and output_sibcall manually emit the instruction present in the 
delay slot (if any) but fail to emit its source location information.

Tested on SPARC64/Linux, applied on the mainline.


2017-09-12  Eric Botcazou  

* config/sparc/sparc.c (output_return): Output the source location of
the insn in the delay slot, if any.
(output_sibcall): Likewise.

-- 
Eric BotcazouIndex: config/sparc/sparc.c
===
--- config/sparc/sparc.c	(revision 251996)
+++ config/sparc/sparc.c	(working copy)
@@ -6179,7 +6179,9 @@ output_return (rtx_insn *insn)
 
   if (final_sequence)
 	{
-	  rtx delay, pat;
+	  rtx_insn *delay;
+	  rtx pat;
+	  int seen;
 
 	  delay = NEXT_INSN (insn);
 	  gcc_assert (delay);
@@ -6194,9 +6196,15 @@ output_return (rtx_insn *insn)
 	  else
 	{
 	  output_asm_insn ("jmp\t%%i7+%)", NULL);
-	  output_restore (pat);
+
+	  /* We're going to output the insn in the delay slot manually.
+		 Make sure to output its source location first.  */
 	  PATTERN (delay) = gen_blockage ();
 	  INSN_CODE (delay) = -1;
+	  final_scan_insn (delay, asm_out_file, optimize, 0, );
+	  INSN_LOCATION (delay) = UNKNOWN_LOCATION;
+
+	  output_restore (pat);
 	}
 	}
   else
@@ -6252,13 +6260,23 @@ output_sibcall (rtx_insn *insn, rtx call
 
   if (final_sequence)
 	{
-	  rtx_insn *delay = NEXT_INSN (insn);
+	  rtx_insn *delay;
+	  rtx pat;
+	  int seen;
+
+	  delay = NEXT_INSN (insn);
 	  gcc_assert (delay);
 
-	  output_restore (PATTERN (delay));
+	  pat = PATTERN (delay);
 
+	  /* We're going to output the insn in the delay slot manually.
+	 Make sure to output its source location first.  */
 	  PATTERN (delay) = gen_blockage ();
 	  INSN_CODE (delay) = -1;
+	  final_scan_insn (delay, asm_out_file, optimize, 0, );
+	  INSN_LOCATION (delay) = UNKNOWN_LOCATION;
+
+	  output_restore (pat);
 	}
   else
 	output_restore (NULL_RTX);

Re: [PATCH] Add -static-pie to GCC driver to create static PIE

[H.J. Lu]

On Tue, Sep 12, 2017 at 11:48 AM, Aaron Sawdey
 wrote:
> On Tue, 2017-09-12 at 16:20 +, Joseph Myers wrote:
>> On Mon, 28 Aug 2017, H.J. Lu wrote:
>>
>> > Here is the updated patch.   OK for trunk?
>>
>> OK.
>
> This seems to be causing an issue for me on powerpc:
>
> /home/sawdey/src/gcc/trunk/build/./prev-gcc/xg++ 
> -B/home/sawdey/src/gcc/trunk/build/./prev-gcc/ 
> -B/home/sawdey/install/gcc/trunk_str/powerpc64le-unknown-linux-gnu/bin/ 
> -nostdinc++ 
> -B/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
>  
> -B/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
>   
> -I/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
>   
> -I/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
>   -I/home/sawdey/src/gcc/trunk/trunk/libstdc++-v3/libsupc++ 
> -L/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
>  
> -L/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
>  -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti 
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
> -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild 
> -I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include  
> -I../../trunk/gcc/../libcpp/include  \
> -o build/gencheck.o ../../trunk/gcc/gencheck.c
> In file included from ./tm.h:30:0,
>  from ../../trunk/gcc/gencheck.c:23:
> ../../trunk/gcc/config/rs6000/sysv4.h:819:0: error: "LINK_EH_SPEC" redefined 
> [-Werror]
>  # define LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
>
> In file included from ./tm.h:28:0,
>  from ../../trunk/gcc/gencheck.c:23:
> ../../trunk/gcc/config/gnu-user.h:135:0: note: this is the location of the 
> previous definition
>  #define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "
>
> I don't see the problem on 252033.
>

There are several problems in rs6000/sysv4.h:

1. It doesn't undef LINK_EH_SPEC before define it.
2. It shouldn't define it for Linux since it has been defined in
gnu-user.h.   You didn't see the problem since there were the
same before my patch.

Can you not define LINK_EH_SPEC for Linux targets?


-- 
H.J.

Turn SECONDARY_MEMORY_NEEDED into a hook

[Richard Sandiford]

Since the patch is going through all the definitions anyway, it seemed
like a good opportunity to put the mode argument first, to match the
order for register_move_cost.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-12  Richard Sandiford  
Alan Hayward  
David Sherwood  

gcc/
* target.def (secondary_memory_needed): New hook.
(secondary_reload): Refer to TARGET_SECONDARY_MEMORY_NEEDED
instead of SECONDARY_MEMORY_NEEDED.
(secondary_memory_needed_mode): Likewise.
* hooks.h (hook_bool_mode_reg_class_t_reg_class_t_false): Declare.
* hooks.c (hook_bool_mode_reg_class_t_reg_class_t_false): New function.
* doc/tm.texi.in (SECONDARY_MEMORY_NEEDED): Replace with...
(TARGET_SECONDARY_MEMORY_NEEDED): ...this.
(SECONDARY_MEMORY_NEEDED_RTX): Update reference accordingly.
* doc/tm.texi: Regenerate.
* config/alpha/alpha.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/alpha/alpha.c (alpha_secondary_memory_needed): New function.
(TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
* config/i386/i386.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/i386/i386-protos.h (ix86_secondary_memory_needed): Delete.
* config/i386/i386.c (inline_secondary_memory_needed): Put the
mode argument first and change the reg_class arguments to reg_class_t.
(ix86_secondary_memory_needed): Likewise.  Remove the strict parameter.
Make static.  Update the call to inline_secondary_memory_needed.
(ix86_register_move_cost): Update the call to
inline_secondary_memory_needed.
(TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
* config/ia64/ia64.h (SECONDARY_MEMORY_NEEDED): Delete commented-out
definition.
* config/ia64/ia64.c (spill_xfmode_rfmode_operand): Refer to
TARGET_SECONDARY_MEMORY_NEEDED rather than SECONDARY_MEMORY_NEEDED
in comment.
* config/mips/mips.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/mips/mips-protos.h (mips_secondary_memory_needed): Delete.
* config/mips/mips.c (mips_secondary_memory_needed): Make static
and match hook interface.  Add comment from mips.h.
(TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
* config/mmix/mmix.md (truncdfsf2): Refer to
TARGET_SECONDARY_MEMORY_NEEDED rather than SECONDARY_MEMORY_NEEDED
in comment.
* config/pa/pa-64.h (SECONDARY_MEMORY_NEEDED): Rename to...
(PA_SECONDARY_MEMORY_NEEDED): ...this, and put the mode argument first.
* config/pa/pa.c (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
(pa_secondary_memory_needed): New function.
* config/pdp11/pdp11.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/pdp11/pdp11-protos.h (pdp11_secondary_memory_needed): Delete.
* config/pdp11/pdp11.c (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
(pdp11_secondary_memory_needed): Make static and match hook interface.
* config/powerpcspe/powerpcspe.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/powerpcspe/powerpcspe-protos.h
(rs6000_secondary_memory_needed_ptr): Delete.
* config/powerpcspe/powerpcspe.c (rs6000_secondary_memory_needed_ptr):
Delete.
(TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
(rs6000_option_override_internal): Assign to
targetm.secondary_memory_needed rather than
rs6000_secondary_memory_needed_ptr.
(rs6000_secondary_memory_needed): Match hook interface.
(rs6000_debug_secondary_memory_needed): Likewise.
* config/riscv/riscv.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/riscv/riscv.c (riscv_secondary_memory_needed): New function.
(riscv_register_move_cost): Use it instead of SECONDARY_MEMORY_NEEDED.
(TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
* config/rs6000/rs6000.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/rs6000/rs6000-protos.h (rs6000_secondary_memory_needed_ptr):
Delete.
* config/rs6000/rs6000.c (rs6000_secondary_memory_needed_ptr): Delete.
(TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
(rs6000_option_override_internal): Assign to
targetm.secondary_memory_needed rather than
rs6000_secondary_memory_needed_ptr.
(rs6000_secondary_memory_needed): Match hook interface.
(rs6000_debug_secondary_memory_needed): Likewise.
* config/s390/s390.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/s390/s390.c (s390_secondary_memory_needed): New function.
(TARGET_SECONDARY_MEMORY_NEEDED): Redefine.
* config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED): Delete.
* config/sparc/sparc.c (TARGET_SECONDARY_MEMORY_NEEDED): Redefine.

Re: [PATCH] Add -static-pie to GCC driver to create static PIE

[Aaron Sawdey]

On Tue, 2017-09-12 at 16:20 +, Joseph Myers wrote:
> On Mon, 28 Aug 2017, H.J. Lu wrote:
> 
> > Here is the updated patch.   OK for trunk?
> 
> OK.

This seems to be causing an issue for me on powerpc:

/home/sawdey/src/gcc/trunk/build/./prev-gcc/xg++ 
-B/home/sawdey/src/gcc/trunk/build/./prev-gcc/ 
-B/home/sawdey/install/gcc/trunk_str/powerpc64le-unknown-linux-gnu/bin/ 
-nostdinc++ 
-B/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
 
-B/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  
-I/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
  
-I/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
  -I/home/sawdey/src/gcc/trunk/trunk/libstdc++-v3/libsupc++ 
-L/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
 
-L/home/sawdey/src/gcc/trunk/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../trunk/gcc 
-I../../trunk/gcc/build -I../../trunk/gcc/../include  
-I../../trunk/gcc/../libcpp/include  \
-o build/gencheck.o ../../trunk/gcc/gencheck.c
In file included from ./tm.h:30:0,
 from ../../trunk/gcc/gencheck.c:23:
../../trunk/gcc/config/rs6000/sysv4.h:819:0: error: "LINK_EH_SPEC" redefined 
[-Werror]
 # define LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
 
In file included from ./tm.h:28:0,
 from ../../trunk/gcc/gencheck.c:23:
../../trunk/gcc/config/gnu-user.h:135:0: note: this is the location of the 
previous definition
 #define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "

I don't see the problem on 252033.

Thanks,
   Aaron

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain

Turn SECONDARY_MEMORY_NEEDED_MODE into a target hook

[Richard Sandiford]

It feels like SECONDARY_MEMORY_NEEDED and SECONDARY_MEMORY_NEEDED_MODE
should be a single hook that returns the memory mode if memory is needed
and an empty opt_mode otherwise.  The snag is this code in reload.c:

  /* If we need a memory location to copy between the two reload regs,
 set it up now.  Note that we do the input case before making
 the reload and the output case after.  This is due to the
 way reloads are output.  */

  if (in_p && icode == CODE_FOR_nothing
  && SECONDARY_MEMORY_NEEDED (rclass, reload_class, mode))
{
  get_secondary_mem (x, reload_mode, opnum, type);

  /* We may have just added new reloads.  Make sure we add
 the new reload at the end.  */
  s_reload = n_reloads;
}

where we use "mode" to test whether a secondary reload is needed but pass
"reload_mode" to get_secondary_mem (and thus SECONDARY_MEMORY_NEEDED_MODE).
This difference appears to come from:

Thu Aug 21 17:56:06 1997  Richard Kenner  

* reload.c (push_secondary_reload): If SECONDARY_MEM_NEEDED,
call get_secondary_mem for input before adding reload and
for output after.
(push_reload): Likewise.

which sounds like it was just moving the code, but also changed the
get_secondary_mem mode argument from "mode" to "reload_mode".

It seems unlikely that the two modes should be different, but it's not
obvious which one is right.  The corresponding code for output reloads
uses "mode" consistently, like the input code did before the patch above:

  if (! in_p && icode == CODE_FOR_nothing
  && SECONDARY_MEMORY_NEEDED (reload_class, rclass, mode))
get_secondary_mem (x, mode, opnum, type);

while the main secondary_reload hook uses "reload_mode":

  rclass = (enum reg_class) targetm.secondary_reload (in_p, x, reload_class,
  reload_mode, );

The difference only matters for reloads of paradoxical subregs that need
to go through secondary memory, which is hardly a common case.  In the
end the whole thing seemed too delicate to change, so the patch instead
just converts the macro to a hook with its current interface.

There is also a change for LRA.  Previously the code was:

if (sclass == NO_REGS && dclass == NO_REGS)
  return false;
  #ifdef SECONDARY_MEMORY_NEEDED
if (SECONDARY_MEMORY_NEEDED (sclass, dclass, GET_MODE (src))
  #ifdef SECONDARY_MEMORY_NEEDED_MODE
&& ((sclass != NO_REGS && dclass != NO_REGS)
|| GET_MODE (src) != SECONDARY_MEMORY_NEEDED_MODE (GET_MODE (src)))
  #endif
)
  {
*sec_mem_p = true;
return false;
  }
  #endif

This allows reloads to and from memory (class == NO_REGS) to use
secondary memory reloads.  It comes from:

2013-05-24  Vladimir Makarov  

* lra-constraints.c (emit_spill_move): Use smaller mode for
mem-mem moves.
(check_and_process_move): Consider mem-reg moves for secondary
too.
(curr_insn_transform): Don't lose insns emitted before for
secondary memory moves.
(inherit_in_ebb): Mark defined reg.  Add usage only if it is not a
reg set up in the current insn.

But the positioning of the second ifdef meant that defining
SECONDARY_MEMORY_NEEDED_MODE to its default value was not a no-op:

(1) if a target does define SECONDARY_MEMORY_NEEDED_MODE, only cases
that need a different memory mode would use secondary memory reloads.
Cases that need the same memory mode would not use secondary reloads.

(2) if a target doesn't define SECONDARY_MEMORY_NEEDED_MODE, we would
always use secondary memory reloads for mem<->reg and reg<->mem,
even though the secondary memory would have the same mode as the
memory that we're moving to or from.

(1) seems like the correct behaviour, since in (2) there's nothing to
distinguish the secondary memory from the original; we'd just get
a redundant mem<->mem move.

The default is different for reload and LRA.  For LRA the default is
to use the original mode, while reload promotes smaller-than-word
integral modes to word mode:

  if (GET_MODE_BITSIZE (mode) < BITS_PER_WORD && INTEGRAL_MODE_P (mode))
mode = mode_for_size (BITS_PER_WORD,
  GET_MODE_CLASS (mode), 0).require ();

Some of the ports that have switched to LRA seemed to have
SECONDARY_MEMORY_NEEDED_MDOEs based on the old reload definition,
and still referred to the reload.c:get_secondary_mem function in
the comments.  The patch just keeps them as-is.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-12  Richard Sandiford  
Alan Hayward  
David Sherwood  

Re: [AArch64] Merge stores of D register values of different modes

[Richard Sandiford]

Thanks for doing this, looks good to me FWIW.  I was just wondering:

Jackson Woodruff  writes:
> @@ -14712,6 +14712,11 @@ aarch64_operands_ok_for_ldpstp (rtx *operands, bool 
> load,
>if (!rtx_equal_p (base_1, base_2))
>  return false;
>  
> +  /* Check that the operands are of the same size.  */
> +  if (GET_MODE_SIZE (GET_MODE (mem_1))
> +  != GET_MODE_SIZE (GET_MODE (mem_2)))
> +return false;
> +
>offval_1 = INTVAL (offset_1);
>offval_2 = INTVAL (offset_2);
>msize = GET_MODE_SIZE (mode);

when can this trigger?  Your iterators always seem to enforce correct
pairings, so maybe this should be an assert instead.

Thanks,
Richard

Re: [PATCH, rs6000] Fix PR target/80210: ICE in extract_insn

[Peter Bergner]

On 9/9/17 3:44 AM, Andreas Schwab wrote:
> On Sep 08 2017, Peter Bergner  wrote:
> 
>> The following patch fixes the problem I saw on Linux and bootstraps and 
>> regtests
>> with no regressions on LE and BE (running testsuite in both 32-bit and 64-bit
>> modes).  I was waiting to submit this until David had a chance to verify this
>> fixes the problem on AIX.
> 
> I've verified that this fixes the ICE.

So it seems this is only a partial fix.  If I modify the test case to
move the #pragma to the start of the file, we still ICE with the same
error.

Clearly, we're not disabling the generation of the HW sqrt in the
optabs when we should.  Basically, this is the opposite problem
than the pr80210.c test case.

Peter


bergner@bns:~/gcc/BUGS/PR80210> cat no-sqrt.i
#pragma GCC target "no-powerpc-gpopt"
double
foo (double a)
{
  return __builtin_sqrt (a);
}
bergner@bns:~/gcc/BUGS/PR80210>
/home/bergner/gcc/build/gcc-fsf-mainline-pr80210-64/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr80210-64/gcc -O2 -S no-sqrt.i
no-sqrt.i: In function ‘foo’:
no-sqrt.i:6:1: error: unrecognizable insn:
 }
 ^
(insn 6 3 7 2 (set (reg:DF 121 [  ])
(sqrt:DF (reg/v:DF 122 [ a ]))) "no-sqrt.i":5 -1
 (nil))
during RTL pass: vregs
no-sqrt.i:6:1: internal compiler error: in extract_insn, at recog.c:2311

Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

[Paul Richard Thomas]

Hi Janus et al.,

I had to do this quickly because of time pressure and I thought it to
be most efficient while the main patch was fresh in my mind.

Committed as revision 252039 with attributions suitably modified.

Thanks

Paul


On 11 September 2017 at 20:50, Janus Weil  wrote:
> Hi Paul,
>
>> I have fixed all the PDT bugs that have been reported to me so far in
>> the attached patch. The patch is straightforward and is commented for
>> clarity where necessary. Please note that whitespace changes have been
>> suppressed. For this reason, if you are tempted to try the patch use
>> the -l option when you apply it.
>>
>> Bootstrapped and regtested on FC23/x86_64 - OK for trunk?
>
> yes, looks good to me (except that you seem to confuse me with Thomas
> - I recognize those test cases as mine ;)
>
> Thanks for taking care of this so quickly!
>
> Cheers,
> Janus



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

[AArch64, patch] Refactor of aarch64-ldpstp.md

[Jackson Woodruff]

Hi all,

This patch removes a lot of duplicated code in aarch64-ldpstp.md.

The patterns that did not previously generate a base register now
do not check for aarch64_mem_pair_operand in the pattern. This has
been extracted to a check in aarch64_operands_ok_for_ldpstp.

All patterns in the file used to have explicit switching code to
swap loads and stores that were in the wrong order.

This has been extracted into aarch64_ldp_str_operands
and aarch64_gen_adjusted_ldp_stp.

This patch is based on my patch here: 
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00346.html so should go in 
after it.



Bootstrap and regtest OK on AArch64.

OK for trunk?

Jackson.

gcc/

2017-09-07  Jackson Woodruff  

* config/aarch64/aarch64-ldpstp.md: Replace uses of
aarch64_mem_pair_operand with memory_operand and delete
operand swapping code.
* config/aarch64/aarch64.c (aarch64_operands_ok_for_ldpstp):
Add check for legitimate_address.
(aarch64_gen_adjusted_ldpstp): Add swap.
(aarch64_swap_ldrstr_operands): New.
* config/aarch64/aarch64-protos.h: Add
aarch64_swap_ldrstr_operands.
diff --git a/gcc/config/aarch64/aarch64-ldpstp.md b/gcc/config/aarch64/aarch64-ldpstp.md
index 14e860d258e548d4118d957675f8bdbb74615337..126bb702f6399d13ab2dc6c8b99bcbbf3b3a7516 100644
--- a/gcc/config/aarch64/aarch64-ldpstp.md
+++ b/gcc/config/aarch64/aarch64-ldpstp.md
@@ -20,26 +20,18 @@
 
 (define_peephole2
   [(set (match_operand:GPI 0 "register_operand" "")
-	(match_operand:GPI 1 "aarch64_mem_pair_operand" ""))
+	(match_operand:GPI 1 "memory_operand" ""))
(set (match_operand:GPI 2 "register_operand" "")
 	(match_operand:GPI 3 "memory_operand" ""))]
   "aarch64_operands_ok_for_ldpstp (operands, true, mode)"
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2;
-
-  extract_base_offset_in_addr (operands[1], , _1);
-  extract_base_offset_in_addr (operands[3], , _2);
-  if (INTVAL (offset_1) > INTVAL (offset_2))
-{
-  std::swap (operands[0], operands[2]);
-  std::swap (operands[1], operands[3]);
-}
+  aarch64_swap_ldrstr_operands (operands, 1);
 })
 
 (define_peephole2
-  [(set (match_operand:GPI 0 "aarch64_mem_pair_operand" "")
+  [(set (match_operand:GPI 0 "memory_operand" "")
 	(match_operand:GPI 1 "aarch64_reg_or_zero" ""))
(set (match_operand:GPI 2 "memory_operand" "")
 	(match_operand:GPI 3 "aarch64_reg_or_zero" ""))]
@@ -47,39 +39,23 @@
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2;
-
-  extract_base_offset_in_addr (operands[0], , _1);
-  extract_base_offset_in_addr (operands[2], , _2);
-  if (INTVAL (offset_1) > INTVAL (offset_2))
-{
-  std::swap (operands[0], operands[2]);
-  std::swap (operands[1], operands[3]);
-}
+  aarch64_swap_ldrstr_operands (operands, 0);
 })
 
 (define_peephole2
   [(set (match_operand:GPF 0 "register_operand" "")
-	(match_operand:GPF 1 "aarch64_mem_pair_operand" ""))
+	(match_operand:GPF 1 "memory_operand" ""))
(set (match_operand:GPF 2 "register_operand" "")
 	(match_operand:GPF 3 "memory_operand" ""))]
   "aarch64_operands_ok_for_ldpstp (operands, true, mode)"
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2;
-
-  extract_base_offset_in_addr (operands[1], , _1);
-  extract_base_offset_in_addr (operands[3], , _2);
-  if (INTVAL (offset_1) > INTVAL (offset_2))
-{
-  std::swap (operands[0], operands[2]);
-  std::swap (operands[1], operands[3]);
-}
+  aarch64_swap_ldrstr_operands (operands, 1);
 })
 
 (define_peephole2
-  [(set (match_operand:GPF 0 "aarch64_mem_pair_operand" "")
+  [(set (match_operand:GPF 0 "memory_operand" "")
 	(match_operand:GPF 1 "aarch64_reg_or_fp_zero" ""))
(set (match_operand:GPF 2 "memory_operand" "")
 	(match_operand:GPF 3 "aarch64_reg_or_fp_zero" ""))]
@@ -87,39 +63,23 @@
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2;
-
-  extract_base_offset_in_addr (operands[0], , _1);
-  extract_base_offset_in_addr (operands[2], , _2);
-  if (INTVAL (offset_1) > INTVAL (offset_2))
-{
-  std::swap (operands[0], operands[2]);
-  std::swap (operands[1], operands[3]);
-}
+  aarch64_swap_ldrstr_operands (operands, 0);
 })
 
 (define_peephole2
   [(set (match_operand:DREG 0 "register_operand" "")
-	(match_operand:DREG 1 "aarch64_mem_pair_operand" ""))
+	(match_operand:DREG 1 "memory_operand" ""))
(set (match_operand:DREG2 2 "register_operand" "")
 	(match_operand:DREG2 3 "memory_operand" ""))]
   "aarch64_operands_ok_for_ldpstp (operands, true, mode)"
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2;
-
-  extract_base_offset_in_addr 

Re: [PATCH] Fix fortran vector tests on powerpc and aarch64, PR tree-optimization/80925

[Paul Richard Thomas]

Hi Steve,

This looks fine from the fortran side - especially since it involves
removing checks :-)

Thanks

Paul

On 12 September 2017 at 18:34, Steve Ellcey  wrote:
> Ping,  also adding fort...@gcc.gnu.org which I seem to left out when
> sending this to gcc-patches@gcc.gnu.org.
>
> Steve
>
>
> On Fri, 2017-08-25 at 09:46 -0700, Steve Ellcey wrote:
>> My earlier patch to update tests and resolve PR tree-
>> optimization/80925
>> did not include FORTRAN, just C and C++.  This patch makes the same
>> changes as the earlier patches but for FORTRAN.  Tested on aarch64.
>>
>> OK to checkin?
>>
>> Steve Ellcey
>> sell...@cavium.com
>>
>> Orginal patches/discussion is at:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01862.html
>> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg0.html
>>
>>
>> 2017-08-25  Steve Ellcey  
>>
>> PR tree-optimization/80925
>> * gfortran.dg/vect/vect-2.f90: Add
>> --param vect-max-peeling-for-alignment=0 option.
>> Remove unaligned access and peeling checks.
>> * gfortran.dg/vect/vect-3.f90: Ditto.
>> * gfortran.dg/vect/vect-4.f90: Ditto.
>> * gfortran.dg/vect/vect-5.f90: Ditto.
>>



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [PATCH, rs6000] Folding of vector loads in GIMPLE

[Will Schmidt]

On Tue, 2017-09-12 at 10:22 -0500, Bill Schmidt wrote:
> > On Sep 12, 2017, at 9:41 AM, Will Schmidt  wrote:
> > 
> > Hi
> > 
> > [PATCH, rs6000] Folding of vector loads in GIMPLE
> > 
> > Folding of vector loads in GIMPLE.
> > 
> > - Add code to handle gimple folding for the vec_ld builtins.
> > - Remove the now obsoleted folding code for vec_ld from rs6000-c.c. 
> > Surrounding
> > comments have been adjusted slightly so they continue to read OK for the
> > vec_st code that remains.
> > 
> > The resulting code is specifically verified by the powerpc/fold-vec-ld-*.c
> > tests which have been posted separately. (a few minutes ago).
> > 
> > Regtest successfully completed on power6 and newer. (p6,p7,p8le,p8be,p9).
> > 
> > OK for trunk?
> > 
> > Thanks,
> > -Will
> > 
> > [gcc]
> > 
> >2017-09-12  Will Schmidt  
> > 
> > * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add handling
> >   for early folding of vector loads (ALTIVEC_BUILTIN_LVX_*).
> > * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
> >   Remove obsoleted code for handling ALTIVEC_BUILTIN_VEC_LD.
> > 
> > diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
> > index 897306c..73e14d9 100644
> > --- a/gcc/config/rs6000/rs6000-c.c
> > +++ b/gcc/config/rs6000/rs6000-c.c
> > @@ -6459,92 +6459,19 @@ altivec_resolve_overloaded_builtin (location_t loc, 
> > tree fndecl,
> >  convert (TREE_TYPE (stmt), arg0));
> >   stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
> >   return stmt;
> > }
> > 
> > -  /* Expand vec_ld into an expression that masks the address and
> > - performs the load.  We need to expand this early to allow
> > +  /* Expand vec_st into an expression that masks the address and
> > + performs the store.  We need to expand this early to allow
> >  the best aliasing, as by the time we get into RTL we no longer
> >  are able to honor __restrict__, for example.  We may want to
> >  consider this for all memory access built-ins.
> > 
> >  When -maltivec=be is specified, or the wrong number of arguments
> >  is provided, simply punt to existing built-in processing.  */
> > -  if (fcode == ALTIVEC_BUILTIN_VEC_LD
> > -  && (BYTES_BIG_ENDIAN || !VECTOR_ELT_ORDER_BIG)
> > -  && nargs == 2)
> > -{
> > -  tree arg0 = (*arglist)[0];
> > -  tree arg1 = (*arglist)[1];
> > -
> > -  /* Strip qualifiers like "const" from the pointer arg.  */
> > -  tree arg1_type = TREE_TYPE (arg1);
> > -  if (!POINTER_TYPE_P (arg1_type) && TREE_CODE (arg1_type) != 
> > ARRAY_TYPE)
> > -   goto bad;
> > -
> > -  tree inner_type = TREE_TYPE (arg1_type);
> > -  if (TYPE_QUALS (TREE_TYPE (arg1_type)) != 0)
> > -   {
> > - arg1_type = build_pointer_type (build_qualified_type (inner_type,
> > -   0));
> > - arg1 = fold_convert (arg1_type, arg1);
> > -   }
> > -
> > -  /* Construct the masked address.  Let existing error handling take
> > -over if we don't have a constant offset.  */
> > -  arg0 = fold (arg0);
> > -
> > -  if (TREE_CODE (arg0) == INTEGER_CST)
> > -   {
> > - if (!ptrofftype_p (TREE_TYPE (arg0)))
> > -   arg0 = build1 (NOP_EXPR, sizetype, arg0);
> > -
> > - tree arg1_type = TREE_TYPE (arg1);
> > - if (TREE_CODE (arg1_type) == ARRAY_TYPE)
> > -   {
> > - arg1_type = TYPE_POINTER_TO (TREE_TYPE (arg1_type));
> > - tree const0 = build_int_cstu (sizetype, 0);
> > - tree arg1_elt0 = build_array_ref (loc, arg1, const0);
> > - arg1 = build1 (ADDR_EXPR, arg1_type, arg1_elt0);
> > -   }
> > -
> > - tree addr = fold_build2_loc (loc, POINTER_PLUS_EXPR, arg1_type,
> > -  arg1, arg0);
> > - tree aligned = fold_build2_loc (loc, BIT_AND_EXPR, arg1_type, addr,
> > - build_int_cst (arg1_type, -16));
> > -
> > - /* Find the built-in to get the return type so we can convert
> > -the result properly (or fall back to default handling if the
> > -arguments aren't compatible).  */
> > - for (desc = altivec_overloaded_builtins;
> > -  desc->code && desc->code != fcode; desc++)
> > -   continue;
> > -
> > - for (; desc->code == fcode; desc++)
> > -   if (rs6000_builtin_type_compatible (TREE_TYPE (arg0), desc->op1)
> > -   && (rs6000_builtin_type_compatible (TREE_TYPE (arg1),
> > -   desc->op2)))
> > - {
> > -   tree ret_type = rs6000_builtin_type (desc->ret_type);
> > -   if (TYPE_MODE (ret_type) == V2DImode)
> > - /* Type-based aliasing analysis thinks vector long
> > -and vector long long are different and will put them
> > -in distinct alias classes.  Force our return type
> > -

Re: [PATCH] Fix fortran vector tests on powerpc and aarch64, PR tree-optimization/80925

[Steve Ellcey]

Ping,  also adding fort...@gcc.gnu.org which I seem to left out when
sending this to gcc-patches@gcc.gnu.org.

Steve


On Fri, 2017-08-25 at 09:46 -0700, Steve Ellcey wrote:
> My earlier patch to update tests and resolve PR tree-
> optimization/80925
> did not include FORTRAN, just C and C++.  This patch makes the same
> changes as the earlier patches but for FORTRAN.  Tested on aarch64.
> 
> OK to checkin?
> 
> Steve Ellcey
> sell...@cavium.com
> 
> Orginal patches/discussion is at:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01862.html
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg0.html
> 
> 
> 2017-08-25  Steve Ellcey  
> 
> PR tree-optimization/80925
> * gfortran.dg/vect/vect-2.f90: Add
> --param vect-max-peeling-for-alignment=0 option.
> Remove unaligned access and peeling checks.
> * gfortran.dg/vect/vect-3.f90: Ditto.
> * gfortran.dg/vect/vect-4.f90: Ditto.
> * gfortran.dg/vect/vect-5.f90: Ditto.
> 

Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

[Paul Richard Thomas]

Dear Dominique,

That error is perfectly correct. Change the order of the assignment
and the declaration for 'b' and you will see that all is well.

The matching of type parameter specification list follows the same
rules as those of actual arguments, except that deferred and assumed
expressions are allowed for PDTs.

I am not convinced that I have deferred and assumed parameters fully
sorted out yet. I suspect that I am too permissive. On the other hand
entities declared in a module do not make any sense unless (i) All the
LEN parameters are deferred; or (ii) The default initialization is
somehow able to deal with variables in the specification expressions.
I will have to ask one of the gurus how to do this.

Cheers

Paul


On 12 September 2017 at 13:47, Dominique d'Humières  wrote:
> Dear Paul,
>
> I have been playing with the patch and found that the following variant of 
> the test for pr82168
>
> module mod
> implicit none
>
> integer, parameter :: dp = kind (0.0d0)
>
> type, public :: v(z, k)
>integer, len :: z
>integer, kind :: k = kind(0.0)
>real(kind = k) :: e(z)
> end type v
>
> end module mod
>
> program bug
> use mod
> implicit none
>
> type (v(2)) :: a
> a%e = 1.0
> type (v(z=:, k=dp)) :: b
>
> end program bug
>
> gives the error
>
> pr82168_db_1.f90:23:24:
>
>  type (v(z=:, k=dp)) :: b
> 1
> Error: Unexpected data declaration statement at (1)
>
> I am also puzzled by the meaning of ‘z=:’ in the main program. Should not it 
> be restricted to be inside a procedure?
>
> Cheers,
>
> Dominique
>
>



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [RFC, vectorizer] Allow single element vector types for vector reduction operations

[Tamar Christina]

I've been able to build spec again with this patch.

Thanks Richard!

Tamar.

From: Richard Biener 
Sent: Tuesday, September 12, 2017 5:36:10 PM
To: Andreas Schwab
Cc: Tamar Christina; Vidya Praveen; Andrew Pinski; Jon Beniston; 
gcc-patches@gcc.gnu.org; nd
Subject: Re: [RFC, vectorizer] Allow single element vector types for vector 
reduction operations

On September 12, 2017 6:25:32 PM GMT+02:00, Andreas Schwab 
 wrote:
>On Sep 12 2017, Richard Biener  wrote:
>
>> Index: gcc/tree-vect-generic.c
>> ===
>> --- gcc/tree-vect-generic.c  (revision 251997)
>> +++ gcc/tree-vect-generic.c  (working copy)
>> @@ -1638,7 +1638,11 @@ expand_vector_operations_1 (gimple_stmt_
>>/* The signedness is determined from input argument.  */
>>if (code == VEC_UNPACK_FLOAT_HI_EXPR
>>|| code == VEC_UNPACK_FLOAT_LO_EXPR)
>> -type = TREE_TYPE (rhs1);
>> +{
>> +  type = TREE_TYPE (rhs1);
>> +  /* We do not know how to scalarize those.  */
>> +  return;
>
>The assignment is surely useless.

Sure. I left it because all this needs further cleanup.

Richard.

>Andreas.

Re: [PATCH v2 11/13] D: GCC builtins and runtime support.

[Jeff Law]

On 09/11/2017 12:04 PM, Iain Buclaw wrote:
> On 11 September 2017 at 18:40, Jeff Law  wrote:
>> On 06/24/2017 11:53 AM, Iain Buclaw wrote:
>>> On 28 May 2017 at 23:17, Iain Buclaw  wrote:
 This patch adds GCC builtins and runtime support for GDC compiled code.

   - module __entrypoint defines the C main function.  Its contents are
 parsed and compiled in during compilation, but only if needed.
   - module gcc.atomic is a deprecated module that defines templated
 __sync builtins.  It's original user, core.atomic, now uses the GCC
 __atomic builtins.
   - module gcc.attribute exposes GDC-specific attributes.
   - module gcc.backtrace implements backtrace support for GDC.
   - module gcc.builtins exposes GCC builtins to D code.
   - module gcc.config exposes things determined at configure time to D 
 code.
   - module gcc.deh implements D unwind EH.
   - module gcc.libbacktrace defines C bindings to libbacktrace.
   - module gcc.unwind defines C bindings to libgcc unwind library.
   - libgphobos.spec contains a list of libraries to link in that are
 dependencies of D runtime and/or the Phobos standard library.  It is
 used by the GDC driver.

 ---
>>> Added GCC Runtime Library Exception to gcc modules as requested.
>> Nothing particularly concerning here now that the license is fixed.
>> Based on my reading, this is all code that the FSF will own, so we don't
>> have to worry about alternate upstreams, license exceptions, etc which
>> makes things so much easier.
>>
>> You may need to bump the copyright dates.
>>
> 
> I thought I bumped all copyright dates in v2 of the patch.  I will check 
> again.
> 
> However, I will prep a v3 of the patch, as it has been some time since
> June - I have made no changes to any of these files anyway.
I may have been looking at the V1 patch -- my email client didnt' thread
any of the D submission well and I was working from a coffee shop
yesterday afternoon.  If it's fixed in the V2, then sorry for the noise.


jeff

Re: [PATCH 3/13] D: The front-end (GDC) changelogs.

[Jeff Law]

On 09/11/2017 11:39 AM, Iain Buclaw wrote:
> On 11 September 2017 at 17:43, Jeff Law  wrote:
>> On 05/28/2017 03:11 PM, Iain Buclaw wrote:
>>> This patch just includes all changelogs for the D front-end (GDC),
>>> going back to the dawn of time itself.
>>>
>>> Change logs for the DMD front-end and libraries are kept on the dlang site.
>> Your call on how much of the historical record you want to keep.
>>
>> jeff
> 
> I'll paraphrase the words of Alan at the Cauldron last weekend: Would
> you want your name removed from the Changelog without you knowing?
> 
> This front-end has been going for over a decade now, and I wouldn't
> feel comfortable removing the original authors from that history.
That's fine with me.

Jeff

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Jeff Law]

On 08/17/2017 10:03 AM, Martin Sebor wrote:
> 
> First, there is the risk that someone will write code based
> on the pure declaration even if there's no intervening call
> to the function between it and the const one.  Code tends to
> be sloppy, and it's also not uncommon to declare the same
> function more than once, for whatever reason.  (The ssa-ccp-2.c
> test is an example of the latter.)
True.  But I think if we get into a state where the semantics of the
implementation are incompatible with the listed attributes (and we can
reliably detect that) then we should issue a separate and distinct
warning.   For example a pure function that reads global memory should
issue a warning/error.

ISTM such a warning/error would be a separate and distinct patch than
detection of attribute conflicts.


> 
> Second, there are cases of attribute conflicts that GCC already
> points out that are much more benign in their effects (the ones
> I know about are always_inline/noinline and cold/hot).  In light
> of the risk above it seems only helpful to include const/pure in
> the same set.
always_inline/noinline conflicts can cause build failures in codebases
that require certain functions to be inlined.  We can argue about
whether or not that's a good policy for those codebases, but they
certainly exist.  I could envision the hot/cold case generating a link
error if the linker script shoved them into different memory segments
and getting them wrong caused an overflow.

But these IMHO are corner cases and should not drive major decisions here.

> 
> Third, I couldn't find another pair of attributes that GCC would
> deliberately handle this way (silently accept both but prefer one
> over the other), and introducing a special case just for these
> two seemed like a wart.
Seems reasonable.

> I do still have the question whether diagnosing attribute
> conflicts under -Wattributes is right.  The manual implies
> that -Wattributes is for attributes in the wrong places or
> on the wrong entities, and that -Wignored-attributes should
> be expected instead when GCC decides to drop one for some
> reason.
This seems like it ought to be a distinct option given the way
-Wattributes is documented.  Alternately we can tweak the meaning of
-Wattributes.  I don't have strong opinions here.


> 
> It is a little unfortunate that many -Wattributes warnings
> print just "attribute ignored" (and have done so for years).
> I think they should all be enhanced to also print why the
> attribute is ignored (e.g., "'packed' attribute on function
> declarations ignored/not valid/not supported" or something
> like that).  Those that ignore attributes that would
> otherwise be valid e.g., because they conflict with other
> specifiers of the same attribute but with a different
> operand might then be candidate for changing to
> -Wignored-attributes.
Seems like a reasonable follow-up if you're interested.


> 
> Thanks
> Martin
> 
> 
> gcc-81544-1.diff
> 
> 
> PR c/81544 - attribute noreturn and warn_unused_result on the same function 
> accepted
> 
> gcc/c/ChangeLog:
> 
>   PR c/81544
>   * c-decl.c (c_decl_attributes): Look up existing declaration and
>   pass it to decl_attributes.
> 
> gcc/c-family/ChangeLog:
> 
>   PR c/81544
>   * c-attribs.c (attr_aligned_exclusions): New array.
>   (attr_alloc_exclusions, attr_cold_hot_exclusions): Same.
>   (attr_common_exclusions, attr_const_pure_exclusions): Same.
>   (attr_gnu_inline_exclusions, attr_inline_exclusions): Same.
>   (attr_noreturn_exclusions, attr_returns_twice_exclusions): Same.
>   (attr_warn_unused_result_exclusions): Same.
>   (handle_hot_attribute, handle_cold_attribute): Simplify.
>   (handle_const_attribute): Warn on function returning void.
>   (handle_pure_attribute): Same.
>   * c-warn.c (diagnose_mismatched_attributes): Simplify.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c/81544
>   * c-c++-common/Wattributes-2.c: New test.
>   * c-c++-common/Wattributes.c: New test.
>   * c-c++-common/attributes-3.c: Adjust.
>   * gcc.dg/attr-noinline.c: Adjust.
>   * gcc.dg/pr44964.c: Same.
>   * gcc.dg/torture/pr42363.c: Same.
>   * gcc.dg/tree-ssa/ssa-ccp-2.c: Same.
> 
> gcc/ChangeLog:
> 
>   PR c/81544
>   * attribs.c (empty_attribute_table): Initialize new member of
>   struct attribute_spec.
>   (decl_attributes): Add argument.  Handle mutually exclusive
>   combinations of attributes.
>   * attribs.h (decl_attributes): Add default argument.
>   * tree-core.h (attribute_spec::exclusions, exclude): New type and
>   member.
>   * doc/extend.texi (Common Function Attributes): Update const and pure.



> diff --git a/gcc/attribs.h b/gcc/attribs.h
> index d4a790b..a9eba0a 100644
> --- a/gcc/attribs.h
> +++ b/gcc/attribs.h
> @@ -31,7 +31,7 @@ extern void init_attributes (void);
> from tree.h.  Depending on these flags, some attributes may be
> returned to be applied at a 

Re: [PATCH] Fix PR 81096 (ttest failures)

[Steve Ellcey]

On Tue, 2017-09-12 at 09:39 -0700, Ian Lance Taylor wrote:
> On Tue, Sep 12, 2017 at 3:59 AM, Wilco Dijkstra  om> wrote:
> > 
> > Steve Ellcey wrote:
> > > 
> > > This patch fixes the ttest failures on aarch64 by adding
> > > AM_CFLAGS to
> > > the test options, like btest already does and as Wilco says works
> > > for
> > > him in Comment #4 of the bug report.
> > Thanks for picking this up, this looks OK.
> > 
> > > 
> > > Tested by me on aarch64.  Ok to checkin?
> > This counts as an obvious fix, so you can commit it.
> Wait, what?  This patch is at best incomplete.  Makefile.in is a
> generated file.  You need to change Makefile.am and re-run automake.
> 
> Ian

OK, here is the new patch that I will checkin.  I verified that after
running automake on Makefile.am, the Makefile.in I got was identical
to what I checked in earlier.

Steve Ellcey
sell...@cavium.com


2017-09-12  Steve Ellcey  

PR other/81096
* Makefile.am (ttest_CFLAGS): Add $(AM_CFLAGS)
* Makefile.in: Regenerate.

diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index b91d6bc..120beb1 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -117,7 +117,7 @@ if HAVE_PTHREAD
 check_PROGRAMS += ttest
 
 ttest_SOURCES = ttest.c testlib.c
-ttest_CFLAGS = -pthread
+ttest_CFLAGS = $(AM_CFLAGS) -pthread
 ttest_LDADD = libbacktrace.la
 
 endif HAVE_PTHREAD

Re: [PATCH version 2, rs6000] Add builtins to convert from float/double to int/long using current rounding mode

[Segher Boessenkool]

Hi Carl,

On Fri, Sep 08, 2017 at 11:41:13AM -0700, Carl Love wrote:
> The following patch adds support for a couple of requested builtins that
> convert from float/double to int / long using the current rounding
> mode.  I initially posted an early version of this patch which generated
> redundant instructions.  

> 2017-09-08  Carl Love  
> 
>   * config/rs6000/rs6000-builtin.def (FCTID, FCTIW): Add BU_P7_MISC_1
>   macro expansion for builtins.
>   * config/rs6000/rs6000.md (fctid, fctiw): Add define_insn for the
>   fctid and fctiw instructions.

There already is fctiwz_ for SF, DF; how do these relate?  Could they
be joined?  Similar for lrintdi2.

Or do we really want fcti* here instead of potentially the VSX equivalent?

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/builtin-fctid-fctiw-runnable.c
> @@ -0,0 +1,140 @@
> +/* { dg-do run { target { powerpc64*-*-* && { lp64 && p8vector_hw } } } } */

powerpc*-*-*


Segher

Re: [C PATCH] field_decl_cmp

[Joseph Myers]

On Tue, 12 Sep 2017, Nathan Sidwell wrote:

> On 09/12/2017 12:06 PM, Joseph Myers wrote:
> > On Tue, 12 Sep 2017, Nathan Sidwell wrote:
> 
> > > This patch removes that checking, and also asserts that when we see
> > > identically named decls, exactly one is a TYPE_DECL.
> > 
> > When do you get TYPE_DECLs here, for C?  I wouldn't expect them to be
> > possible.
> > 
> 
> oh, of course (C is so primitive!).  This patch survives a bootstrap, ok?

I'd be concerned about the possibility of a qsort implementation that 
calls the comparison function with two pointers to the same object (as far 
as I can tell, it's valid for qsort to do that).  That is, I think you 
need to check for the two DECLs being the same DECL, before asserting 
their names are different.

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

Re: [PATCH] Fix PR 81096 (ttest failures)

[Steve Ellcey]

On Tue, 2017-09-12 at 09:39 -0700, Ian Lance Taylor wrote:
> On Tue, Sep 12, 2017 at 3:59 AM, Wilco Dijkstra  om> wrote:
> > 
> > Steve Ellcey wrote:
> > > 
> > > This patch fixes the ttest failures on aarch64 by adding
> > > AM_CFLAGS to
> > > the test options, like btest already does and as Wilco says works
> > > for
> > > him in Comment #4 of the bug report.
> > Thanks for picking this up, this looks OK.
> > 
> > > 
> > > Tested by me on aarch64.  Ok to checkin?
> > This counts as an obvious fix, so you can commit it.
> Wait, what?  This patch is at best incomplete.  Makefile.in is a
> generated file.  You need to change Makefile.am and re-run automake.
> 
> Ian

Duh,  I completely missed the fact that there was a Makefile.am.  I
will create a new patch to fix that.

Steve Ellcey
sell...@cavium.com

Re: [C PATCH] field_decl_cmp

[Nathan Sidwell]

On 09/12/2017 12:06 PM, Joseph Myers wrote:

On Tue, 12 Sep 2017, Nathan Sidwell wrote:



This patch removes that checking, and also asserts that when we see
identically named decls, exactly one is a TYPE_DECL.


When do you get TYPE_DECLs here, for C?  I wouldn't expect them to be
possible.



oh, of course (C is so primitive!).  This patch survives a bootstrap, ok?

nathan

--
Nathan Sidwell
2017-09-12  Nathan Sidwell  

	* c-decl.c (field_decl_cmp): Don't handle NULL or equal names.

Index: c-decl.c
===
--- c-decl.c	(revision 252023)
+++ c-decl.c	(working copy)
@@ -7845,19 +7845,11 @@ warn_cxx_compat_finish_struct (tree fiel
 static int
 field_decl_cmp (const void *x_p, const void *y_p)
 {
-  const tree *const x = (const tree *) x_p;
-  const tree *const y = (const tree *) y_p;
+  const tree x = *(const tree *) x_p;
+  const tree y = *(const tree *) y_p;
 
-  if (DECL_NAME (*x) == DECL_NAME (*y))
-/* A nontype is "greater" than a type.  */
-return (TREE_CODE (*y) == TYPE_DECL) - (TREE_CODE (*x) == TYPE_DECL);
-  if (DECL_NAME (*x) == NULL_TREE)
-return -1;
-  if (DECL_NAME (*y) == NULL_TREE)
-return 1;
-  if (DECL_NAME (*x) < DECL_NAME (*y))
-return -1;
-  return 1;
+  gcc_checking_assert (DECL_NAME (x) != DECL_NAME (y));
+  return DECL_NAME (x) < DECL_NAME (y) ? -1 : +1;
 }
 
 /* Fill in the fields of a RECORD_TYPE or UNION_TYPE node, T.

Re: [PATCH] Fix PR 81096 (ttest failures)

[Ian Lance Taylor via gcc-patches]

On Tue, Sep 12, 2017 at 3:59 AM, Wilco Dijkstra  wrote:
> Steve Ellcey wrote:
>> This patch fixes the ttest failures on aarch64 by adding AM_CFLAGS to
>> the test options, like btest already does and as Wilco says works for
>> him in Comment #4 of the bug report.
>
> Thanks for picking this up, this looks OK.
>
>> Tested by me on aarch64.  Ok to checkin?
>
> This counts as an obvious fix, so you can commit it.

Wait, what?  This patch is at best incomplete.  Makefile.in is a
generated file.  You need to change Makefile.am and re-run automake.

Ian

Re: [RFC, vectorizer] Allow single element vector types for vector reduction operations

[Richard Biener]

On September 12, 2017 6:25:32 PM GMT+02:00, Andreas Schwab 
 wrote:
>On Sep 12 2017, Richard Biener  wrote:
>
>> Index: gcc/tree-vect-generic.c
>> ===
>> --- gcc/tree-vect-generic.c  (revision 251997)
>> +++ gcc/tree-vect-generic.c  (working copy)
>> @@ -1638,7 +1638,11 @@ expand_vector_operations_1 (gimple_stmt_
>>/* The signedness is determined from input argument.  */
>>if (code == VEC_UNPACK_FLOAT_HI_EXPR
>>|| code == VEC_UNPACK_FLOAT_LO_EXPR)
>> -type = TREE_TYPE (rhs1);
>> +{
>> +  type = TREE_TYPE (rhs1);
>> +  /* We do not know how to scalarize those.  */
>> +  return;
>
>The assignment is surely useless.

Sure. I left it because all this needs further cleanup. 

Richard. 

>Andreas.

Re: Add support to trace comparison instructions and switch statements

[Kostya Serebryany via gcc-patches]

On Tue, Sep 12, 2017 at 7:32 AM, Dmitry Vyukov  wrote:
> On Thu, Sep 7, 2017 at 9:02 AM, 吴潍浠(此彼)  wrote:
>> Hi
>> The trace-div and trace-gep options seems be used to evaluate corpus
>> to trigger specific kind of bugs. And they don't have strong effect to 
>> coverage.

These are used for what I call data-flow-driven mutations.
If we see x/y we tried to drive the inputs toward y==1.
Similarly, when we see a[idx], we try to drive towards idx being large
or negative.
When combined with value profiling, these do affect "generalized"
coverage and thus the corpus size.
They don't directly affect the regular edge coverage.

>>
>> The trace-pc-guard is useful, but it may be much more complex than trace-pc.
>> I think the best benefit of trace-pc-guard is avoiding dealing ASLR of 
>> programs,
>> especially programs with dlopen(). Seems hard to implement it in Linux 
>> kernel.

One of the benefits of trace-pc-guard is that you have to deal with
consecutive integers, not PCs (that are indeed affected by ARLR).

>>
>> The inline-8bit-counters and pc-table is too close to implementation of fuzz 
>> tool and
>> option trace-pc-guard .
>>
>> I am interesting in "stack-depth" and "func".

stack-depth is fully independent of all others.

"func" is a modifier that tells to insert callbacks only at the function entry.
It applies to trace-pc, trace-pc-guard, inline-8bit-counters, and pc-table
Other modifiers are bb (basic blocks) and edge (split critical edges,
then apply instrumentation to all BBs)

>> If we trace user-defined functions enter and exit,
>> we can calculate stack-depth and difference level of stack to past existed 
>> stack.
>> Adding __sanitizer_cov_trace_pc_{enter,exit} is easy , but it is not 
>> standard of llvm.

__sanitizer_cov_trace_pc_enter would be equivalent to trace-pc,func

we don't have __sanitizer_cov_trace_pc_exit. It's not very useful for
fuzzing (afaict).
I had one or two requests to implement __sanitizer_cov_trace_pc_exit
but at the end I was able to convince the folks that they don't need
it.

With pc-table and trace-pc[-guard] we already can distinguish func
entry from other blocks.
Can probably add special handling for exit, if someone explains why
this is interesting (in a separate thread, perhaps).

Also, gcc already has -finstrument-functions


>>
>> How do you think Dmitry ?
>>
>> Wish Wu
>>
>> --
>> From:Jakub Jelinek 
>> Time:2017 Sep 6 (Wed) 22:37
>> To:Wish Wu 
>> Cc:Dmitry Vyukov ; gcc-patches 
>> ; Jeff Law ; wishwu007 
>> 
>> Subject:Re: Add support to trace comparison instructions and switch 
>> statements
>>
>>
>> On Wed, Sep 06, 2017 at 07:47:29PM +0800, 吴潍浠(此彼) wrote:
>>> Hi Jakub
>>> I compiled libjpeg-turbo and libdng_sdk with options "-g -O3 -Wall 
>>> -fsanitize-coverage=trace-pc,trace-cmp -fsanitize=address".
>>> And run my fuzzer with pc and cmp feedbacks for hours. It works fine.
>>> About __sanitizer_cov_trace_cmp{f,d} , yes, it  isn't provided by llvm. But 
>>> once we trace integer comparisons, why not real type comparisons.

But why would you need to trace floats?
"Just for completeness" is not good enough.
It's extremely easy to add, but I don't want to pollute the code &
docs with something nobody needs.


>>> I remember Dmitry said it is not enough useful to trace real type 
>>> comparisons because it is rare to see them in programs.
>>> But libdng_sdk really has real type comparisons. So I want to keep them and 
>>> implementing __sanitizer_cov_trace_const_cmp{f,d} may be necessary.
>>
>> Ok.  Please make sure those entrypoints make it into the various example
>> __sanitier_cov_trace* fuzzer implementations though, so that people using
>> -fsanitize-coverage=trace-cmp in GCC will not need to hack stuff themselves.

Yes. It would be lovely if we can keep both LLVM and GCC in sync wrt
the interface.

>> At least it should be added to sanitizer_common (both in LLVM and GCC).
>>
>> BTW, https://clang.llvm.org/docs/SanitizerCoverage.html shows various other
>> -fsanitize-coverage= options, some of them terribly misnamed (e.g. trace-gep
>> using some weirdo LLVM IL acronym instead of being named by what it really
>> traces (trace-array-idx or something similar)).

I don't mind renaming trace-gep.

>>
>> Any plans to implement some or all of those?
>
>
> Thanks, Jakub!
>
> I've tested it on Linux kernel. Compiler does not crash, code is instrumented.
>
> Re  terribly misnamed trace-gep, dunno, I will leave this to Kostya.
>
> Re __sanitizer_cov_trace_cmp{f,d}, I am still not sure.
>
>> But libdng_sdk really has real type comparisons.
>
> Do they come from input data? In what format? How do you want to use
> them? E.g. if they come from input but with using some non-trivial
> transformation and the fuzzer will try to find them in the 

Re: [AArch64, PATCH] Improve Neon store of zero

[James Greenhalgh]

On Wed, Sep 06, 2017 at 10:02:52AM +0100, Jackson Woodruff wrote:
> Hi all,
> 
> I've attached a new patch that addresses some of the issues raised with 
> my original patch.
> 
> On 08/23/2017 03:35 PM, Wilco Dijkstra wrote:
> > Richard Sandiford wrote:
> >>
> >> Sorry for only noticing now, but the call to aarch64_legitimate_address_p
> >> is asking whether the MEM itself is a legitimate LDP/STP address.  Also,
> >> it might be better to pass false for strict_p, since this can be called
> >> before RA.  So maybe:
> >>
> >> if (GET_CODE (operands[0]) == MEM
> >>&& !(aarch64_simd_imm_zero (operands[1], mode)
> >> && aarch64_mem_pair_operand (operands[0], mode)))
> 
> There were also some issues with the choice of mode for the call the 
> aarch64_mem_pair_operand.
> 
> For a 128-bit wide mode, we want to check `aarch64_mem_pair_operand 
> (operands[0], DImode)` since that's what the stp will be.
> 
> For a 64-bit wide mode, we don't need to do that check because a normal
> `str` can be issued.
> 
> I've updated the condition as such.
> 
> > 
> > Is there any reason for doing this check at all (or at least this early 
> > during
> > expand)?
> 
> Not doing this check means that the zero is forced into a register, so 
> we then carry around a bit more RTL and rely on combine to merge things.
> 
> > 
> > There is a similar issue with this part:
> > 
> >   (define_insn "*aarch64_simd_mov"
> > [(set (match_operand:VQ 0 "nonimmediate_operand"
> > -   "=w, m,  w, ?r, ?w, ?r, w")
> > +   "=w, Ump,  m,  w, ?r, ?w, ?r, w")
> > 
> > The Ump causes the instruction to always split off the address offset. Ump
> > cannot be used in patterns that are generated before register allocation as 
> > it
> > also calls laarch64_legitimate_address_p with strict_p set to true.
> 
> I've changed the constraint to a new constraint 'Umq', that acts the 
> same as Ump, but calls aarch64_legitimate_address_p with strict_p set to 
> false and uses DImode for the mode to pass.

This looks mostly OK to me, but this conditional:

> +  if (GET_CODE (operands[0]) == MEM
> +  && !(aarch64_simd_imm_zero (operands[1], mode)
> +&& ((GET_MODE_SIZE (mode) == 16
> + && aarch64_mem_pair_operand (operands[0], DImode))
> +|| GET_MODE_SIZE (mode) == 8)))

Has grown a bit too big in such a general pattern to live without a comment
explaining what is going on.

> +(define_memory_constraint "Umq"
> +  "@internal
> +   A memory address which uses a base register with an offset small enough 
> for
> +   a load/store pair operation in DI mode."
> +   (and (match_code "mem")
> + (match_test "aarch64_legitimate_address_p (DImode, XEXP (op, 0),
> +PARALLEL, 0)")))

And here you want 'false' rather than '0'.

I'll happily merge the patch with those changes, please send an update.

Thanks,
James


> 
> ChangeLog:
> 
> gcc/
> 
> 2017-08-29  Jackson Woodruff  
> 
>   * config/aarch64/constraints.md (Umq): New constraint.
>   * config/aarch64/aarch64-simd.md (*aarch64_simd_mov):
>   Change to use Umq.
>   (mov): Update condition.
> 
> gcc/testsuite
> 
> 2017-08-29  Jackson Woodruff  
> 
>   * gcc.target/aarch64/simd/vect_str_zero.c:
>   Update testcase.

Re: [RFC, vectorizer] Allow single element vector types for vector reduction operations

[Andreas Schwab]

On Sep 12 2017, Richard Biener  wrote:

> Index: gcc/tree-vect-generic.c
> ===
> --- gcc/tree-vect-generic.c   (revision 251997)
> +++ gcc/tree-vect-generic.c   (working copy)
> @@ -1638,7 +1638,11 @@ expand_vector_operations_1 (gimple_stmt_
>/* The signedness is determined from input argument.  */
>if (code == VEC_UNPACK_FLOAT_HI_EXPR
>|| code == VEC_UNPACK_FLOAT_LO_EXPR)
> -type = TREE_TYPE (rhs1);
> +{
> +  type = TREE_TYPE (rhs1);
> +  /* We do not know how to scalarize those.  */
> +  return;

The assignment is surely useless.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

[Joseph Myers]

On Mon, 21 Aug 2017, H.J. Lu wrote:

> When warn_if_not_aligned_p is true, a warning will be issued on function
> declaration later.  There is no need to warn function alignment when
> warn_if_not_aligned_p is true.
> 
> OK for trunk?
> 
> H.J.
> --
>   * c-attribs.c (common_handle_aligned_attribute): Don't warn
>   function alignment if warn_if_not_aligned_p is true.

OK.

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

Re: [PATCH] Add -static-pie to GCC driver to create static PIE

[Joseph Myers]

On Mon, 28 Aug 2017, H.J. Lu wrote:

> Here is the updated patch.   OK for trunk?

OK.

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

Re: [PATCH] detect incompatible aliases (PR c/81854)

[Joseph Myers]

On Thu, 17 Aug 2017, Martin Sebor wrote:

> +   || (prototype_p (t1)
> +   && prototype_p (t2)
> +   && !types_compatible_p (t1, t2

Why the restriction to prototyped types?  I'd expect a warning for an 
alias between unprototyped functions of types int () and void (), for 
example.  Or for an alias between void () and void (char), as a function 
with a char argument is not compatible with a non-prototype function in C.  
Is this an issue with the problem being diagnosed at a point where the 
langhooks for language-specific type compatibility rules aren't available?  
If that's preventing diagnosing incompatibility involving unprototyped 
functions, then the patch is OK.

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

Re: [PATCH][AArch64] Remove '*' from movsi/di/ti patterns

[James Greenhalgh]

On Wed, Jul 26, 2017 at 02:46:14PM +0100, Wilco Dijkstra wrote:
> Remove the remaining uses of '*' from the movsi/di/ti patterns.
> Using '*' in alternatives is typically incorrect at it tells the register
> allocator to ignore those alternatives.  So remove these from all the
> integer move patterns.  This removes unnecessary int to float moves, for
> example gcc.target/aarch64/pr62178.c no longer generates a redundant fmov
> since the w = m variant is now allowed.
> 
> Passes regress & bootstrap, OK for commit?

OK.

These attempts at register allocator costs are just trouble!

Thanks,
James

> 
> ChangeLog:
> 2017-07-26  Wilco Dijkstra  
> 
>   * gcc/config/aarch64/aarch64.md (movsi_aarch64): Remove all '*'.
>   (movdi_aarch64): Likewise.
>   (movti_aarch64): Likewise.
> --
> 

Re: [PATCH version 2, rs6000] Add builtins to convert from float/double to int/long using current rounding mode

[Pat Haugen]

On 09/08/2017 01:41 PM, Carl Love wrote:
> +(define_insn "fctid"
> +  [(set (match_operand:DI 0 "gpc_reg_operand" "=d")
> +(unspec:DI [(match_operand:DF 1 "gpc_reg_operand" "d")]
> +   UNSPEC_FCTID_INST))]
> +  ""
> +  "fctid %0,%1")
> +
> +(define_insn "fctiw"
> +  [(set (match_operand:SI 0 "gpc_reg_operand" "=d")
> + (unspec:SI [(match_operand:DF 1 "gpc_reg_operand" "d")]
> +UNSPEC_FCTIW_INST))]
> +  ""
> +  "fctiw %0,%1")

These should have (set_attr "type" "fp").

-Pat

Re: [C PATCH] field_decl_cmp

[Joseph Myers]

On Tue, 12 Sep 2017, Nathan Sidwell wrote:

> Joseph,
> in moving field_decl_cmp to the C FE, I noticed it checks for NULL DECL_NAMES.
> Those don't occur.

To be clear: they don't occur in the case where field_decl_cmp is used; 
they can occur in other cases.

> This patch removes that checking, and also asserts that when we see
> identically named decls, exactly one is a TYPE_DECL.

When do you get TYPE_DECLs here, for C?  I wouldn't expect them to be 
possible.

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

RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

[Tsimbalist, Igor V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Friday, August 25, 2017 10:50 PM
> To: Tsimbalist, Igor V ; 'gcc-
> patc...@gcc.gnu.org' 
> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> On 08/01/2017 02:56 AM, Tsimbalist, Igor V wrote:
> > Part#1. Add generic part for Intel CET enabling.
> >
> > The spec is available at
> >
> > https://software.intel.com/sites/default/files/managed/4d/2a/control-f
> > low-enforcement-technology-preview.pdf
> >
> > High-level design.
> > --
> >
> > A proposal is to introduce a target independent flag
> > -finstrument-control-flow with a semantic to instrument a code to
> > control validness or integrity of control-flow transfers using jump
> > and call instructions. The main goal is to detect and block a possible
> > malware execution through transfer the execution to unknown target
> > address. Implementation could be either software or target based. Any
> > target platforms can provide their implementation for instrumentation
> > under this option.
> >
> > When the -finstrument-control-flow flag is set each implementation has
> > to check if a support exists for a target platform and report an error
> > if no support is found.
> >
> > The compiler should instrument any control-flow transfer points in a
> > program (ex. call/jmp/ret) as well as any landing pads, which are
> > targets of for control-flow transfers.
> >
> > A new 'notrack' attribute is introduced to provide hand tuning support.
> > The attribute directs the compiler to skip a call to a function and a
> > function's landing pad from instrumentation (tracking). The attribute
> > can be used for function and pointer to function types, otherwise it
> > will be ignored. The attribute is saved in a type and propagated to a
> > GIMPLE call statement and later to a call instruction.
> >
> > Currently all platforms except i386 will report the error and do no
> > instrumentation. i386 will provide the implementation based on a
> > specification published by Intel for a new technology called
> > Control-flow Enforcement Technology (CET).
> >
> >
> > 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling.patch
> >
> >
> > From 403fc8239fb1f690cc378287b4def57dcc9d25bf Mon Sep 17 00:00:00
> 2001
> > From: Igor Tsimbalist 
> > Date: Mon, 3 Jul 2017 17:11:58 +0300
> > Subject: [PATCH 1/9] Part#1. Add generic part for Intel CET enabling.
> >
> > The spec is available at
> >
> > https://software.intel.com/sites/default/files/managed/4d/2a/control-f
> > low-enforcement-technology-preview.pdf
> >
> > High-level design.
> > --
> >
> > A proposal is to introduce a target independent flag
> > -finstrument-control-flow with a semantic to instrument a code to
> > control validness or integrity of control-flow transfers using jump
> > and call instructions. The main goal is to detect and block a possible
> > malware execution through transfer the execution to unknown target
> > address. Implementation could be either software or target based. Any
> > target platforms can provide their implementation for instrumentation
> > under this option.
> >
> > When the -finstrument-control-flow flag is set each implementation has
> > to check if a support exists for a target platform and report an error
> > if no support is found.
> >
> > The compiler should instrument any control-flow transfer points in a
> > program (ex. call/jmp/ret) as well as any landing pads, which are
> > targets of for control-flow transfers.
> >
> > A new 'notrack' attribute is introduced to provide hand tuning support.
> > The attribute directs the compiler to skip a call to a function and a
> > function's landing pad from instrumentation (tracking). The attribute
> > can be used for function and pointer to function types, otherwise it
> > will be ignored. The attribute is saved in a type and propagated to a
> > GIMPLE call statement and later to a call instruction.
> >
> > Currently all platforms except i386 will report the error and do no
> > instrumentation. i386 will provide the implementation based on a
> > specification published by Intel for a new technology called
> > Control-flow Enforcement Technology (CET).
> >
> > gcc/c-family/
> >
> > * c-attribs.c (handle_notrack_attribute): New function.
> > (c_common_attribute_table): Add 'notrack' handling.
> >
> > gcc/
> >
> > * cfgexpand.c (expand_call_stmt): Set REG_CALL_NOTRACK.
> > * combine.c (distribute_notes): Add REG_CALL_NOTRACK handling.
> > * common.opt: Add finstrument-control-flow flag.
> > * emit-rtl.c (try_split): Add REG_CALL_NOTRACK handling.
> > * gimple.c (gimple_build_call_from_tree): Add 'notrack'
> > propogation.
> > * gimple.h (gf_mask): Add GF_CALL_WITH_NOTRACK.
> > (gimple_call_with_notrack_p): function.
> > (gimple_call_set_with_notrack): Likewise.
> > * recog.c 

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Jeff Law]

On 08/09/2017 01:55 PM, Joseph Myers wrote:
> On Wed, 9 Aug 2017, Martin Sebor wrote:
> 
>> the same function with the other of this pair attributes.  I'd
>> also be okay with not diagnosing this combination if I could
>> convince myself that it's safe (or can be made safe) and treated
>> consistently.
> 
> I'd expect it to be safe; it might simply happen that some calls are 
> optimized based on incomplete information (and even that is doubtful, as 
> all optimizations except front-end folding should be taking place after 
> all the declarations have been seen).
Right.  With the caveat that there may be paths we're simply unaware of
which might cause something to be handled earlier than expected.  For
example, interactions with nested functions, or with the backends
squirreling away information via ENCODE_SECTION_INFO and the like.  But
in general, we should be seeing all the declarations before we start
generating code.


> 
>> In any event, it sounds to me that conceptually, it might be
>> useful to be able to specify which of a pair of mutually
>> exclusive (or redundant) attributes to retain and/or accept:
>> the first or the second, and not just whether to accept or
>> drop the most recent one.  That will make it possible to make
>> the most appropriate decision about each specific pair of
>> attributes without impacting any of the others.
> 
> If they conflict, I'm not sure there's any basis for making a choice 
> specific to a particular pair of attributes.
Agreed.

> 
> In cases like const and pure where one is a subset of the other, it makes 
> sense to choose based on the pair of attributes - and not necessarily to 
> warn under the same conditions as the warnings for conflicting attributes.
In the subset case we could argue that there is a "winner" -- the set
that allows us to generate the best code.

Of course this assumes that the underlying semantics of the code match
the given attributes.

jeff

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Jeff Law]

On 08/10/2017 03:55 PM, Joseph Myers wrote:
> On Wed, 9 Aug 2017, Martin Sebor wrote:
> 
>> The problem isn't that the declarations aren't merged at the call
>> site but rather that the middle-end gives const precedence over
>> pure so when both attributes are provided the former wins.
> 
> But that precedence is correct.  Any function with the semantics of const 
> also has the semantics of pure. 
True.  Pure/const is one of the cases where we have a clear subset
relationship.  In the pure/const the worst that can happen is we don't
optimize as fully as we could (optimizing as pure then later see it as
const).  I can't think of any correctness issues that can arise in the
pure/const scenario.


> The problem is that the function doesn't 
> have the semantics of the attribute it's declared with. 
I think this is the key realization for Martin's testcase.  THe function
is declared const, but actually references global data.   ISTM detecting
that would be a useful warning in and of itself.



 And any
> diagnostic based purely on the presence of both attributes would be 
> essentially a style diagnostic - for the style principle "if you have 
> multiple declarations of a function, they should have the same 
> information" - rather than "these attributes are inconsistent".
Right.  This could be a warning unto itself when there's a
superset/subset relationship between the semantics of a particular pair
of attributes like we have with const/pure.

> 
> (An optional warning for different information in different declarations 
> is reasonable enough.  Actually in glibc it would be useful to have a 
> warning for a different but related case - two functions both declared, 
> later one defined as an alias of another, but the declarations don't have 
> the same attributes.  I'm pretty sure there are cases where the internal 
> declaration of __foo is missing attributes present on the public 
> declaration of foo.  But such a warning for aliases is only appropriate 
> for attributes that are properties of the function, not attributes that 
> are properties of particular names for it - __foo may well be a hidden 
> symbol where foo isn't.)
Yea, I can see how that would be useful.

jeff

RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

[Tsimbalist, Igor V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Friday, August 25, 2017 10:32 PM
> To: Richard Biener ; Tsimbalist, Igor V
> 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> On 08/15/2017 07:42 AM, Richard Biener wrote:
> >
> > Please change the names to omit 'with_', thus just notrack and
> > GF_CALL_NOTRACK.
> >
> > I think 'notrack' is somewhat unspecific of a name, what prevented you
> > to use 'nocet'?
> I think we should look for something better than notrack.  I think "control
> flow enforcement/CFE" is commonly used for this stuff.  CET is an Intel
> marketing name IIRC.
> 
> The tracking is for indirect branch/call targets.  So some combination of cfe,
> branch/call and track should be sufficient.
Still remaining question from me - is it ok to use 'notrack' as the attribute 
name. I've asked Richard
about this in this thread.

Thanks,
Igor

> 
> > Any idea how to implement a software-based solution efficiently?
> > Creating a table of valid destination addresses in a special section
> > should be possible without too much work, am I right in that only
> > indirect control transfer is checked?  Thus CET assumes the code
> > itself cannot be changed (and thus the stack isn't executable)?
> Well, there's two broad areas that have to be addressed.
> 
> First you need to separate the call stack from the rest of the call frame, or 
> at
> least the parts of the call frame that are potentially vulnerable to overruns.
> LLVM has some code to do this.  Essentially any object in the stack that is 
> not
> proven to be safely accessed gets put into a separate stack.  That roughly
> duplicates the shadow stack capability.  I think their implementation is just
> x86 and IIRC doesn't work in some circumstances -- I'd consider it a proof of
> concept, not something ready for production use.
> 
> 
> Bernd and I also spec'd a couple more approaches to protect the return
> address.  Essentially, the return address turns into a cookie that a 
> particular
> caller can use to lookup/map to a real return address.  We didn't take any of
> this to completion because it was pretty clear the ROP mitigation landscape
> was going to change and make software only solutions less appealing.
> 
> Second you need the indirect branch/call tracking.  I spec'd something out in
> this space with Intel's engineers years ago.  Essentially building tables of 
> valid
> targets for indirect branches and checking
> instrumentation.   You can have a global table, per-DSO tables or you
> can have a per-branch table.  It gets a little hairy in mixed mode
> environments.  But it basically works how you'd expect.  Indirect
> branches/calls turn into something considerably more complex as do the
> branch/call targets if you have access to something like a last-taken-branch.
> 
> Jeff

RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

[Tsimbalist, Igor V]

> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Friday, August 18, 2017 4:43 PM
> To: 'Richard Biener' 
> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> 
> Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> > -Original Message-
> > From: Richard Biener [mailto:richard.guent...@gmail.com]
> > Sent: Friday, August 18, 2017 3:53 PM
> > To: Tsimbalist, Igor V 
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> >
> > On Fri, Aug 18, 2017 at 3:11 PM, Tsimbalist, Igor V
> >  wrote:
> > >> -Original Message-
> > >> From: Richard Biener [mailto:richard.guent...@gmail.com]
> > >> Sent: Tuesday, August 15, 2017 3:43 PM
> > >> To: Tsimbalist, Igor V 
> > >> Cc: gcc-patches@gcc.gnu.org
> > >> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> > >>
> > >> On Tue, Aug 1, 2017 at 10:56 AM, Tsimbalist, Igor V
> > >>  wrote:
> > >> > Part#1. Add generic part for Intel CET enabling.
> > >> >
> > >> > The spec is available at
> > >> >
> > >> > https://software.intel.com/sites/default/files/managed/4d/2a/cont
> > >> > ro l-f low-enforcement-technology-preview.pdf
> > >> >
> > >> > High-level design.
> > >> > --
> > >> >
> > >> > A proposal is to introduce a target independent flag
> > >> > -finstrument-control-flow with a semantic to instrument a code to
> > >> > control validness or integrity of control-flow transfers using
> > >> > jump and call instructions. The main goal is to detect and block
> > >> > a possible malware execution through transfer the execution to
> > >> > unknown target address. Implementation could be either software
> > >> > or target based. Any target platforms can provide their
> > >> > implementation for instrumentation under this option.
> > >> >
> > >> > When the -finstrument-control-flow flag is set each
> > >> > implementation has to check if a support exists for a target
> > >> > platform and report an error if no support is found.
> > >> >
> > >> > The compiler should instrument any control-flow transfer points
> > >> > in a program (ex. call/jmp/ret) as well as any landing pads,
> > >> > which are targets of for control-flow transfers.
> > >> >
> > >> > A new 'notrack' attribute is introduced to provide hand tuning
> support.
> > >> > The attribute directs the compiler to skip a call to a function
> > >> > and a function's landing pad from instrumentation (tracking). The
> > >> > attribute can be used for function and pointer to function types,
> > >> > otherwise it will be ignored. The attribute is saved in a type
> > >> > and propagated to a GIMPLE call statement and later to a call
> instruction.
> > >> >
> > >> > Currently all platforms except i386 will report the error and do
> > >> > no instrumentation. i386 will provide the implementation based on
> > >> > a specification published by Intel for a new technology called
> > >> > Control-flow Enforcement Technology (CET).
> > >>
> > >> diff --git a/gcc/gimple.c b/gcc/gimple.c index 479f90c..2e4ab2d
> > >> 100644
> > >> --- a/gcc/gimple.c
> > >> +++ b/gcc/gimple.c
> > >> @@ -378,6 +378,23 @@ gimple_build_call_from_tree (tree t)
> > >>gimple_set_no_warning (call, TREE_NO_WARNING (t));
> > >>gimple_call_set_with_bounds (call, CALL_WITH_BOUNDS_P (t));
> > >>
> > >> +  if (fndecl == NULL_TREE)
> > >> +{
> > >> +  /* Find the type of an indirect call.  */
> > >> +  tree addr = CALL_EXPR_FN (t);
> > >> +  if (TREE_CODE (addr) != FUNCTION_DECL)
> > >> +   {
> > >> + tree fntype = TREE_TYPE (addr);
> > >> + gcc_assert (POINTER_TYPE_P (fntype));
> > >> + fntype = TREE_TYPE (fntype);
> > >> +
> > >> + /* Check if its type has the no-track attribute and propagate
> > >> +it to the CALL insn.  */
> > >> + if (lookup_attribute ("notrack", TYPE_ATTRIBUTES (fntype)))
> > >> +   gimple_call_set_with_notrack (call, TRUE);
> > >> +   }
> > >> +}
> > >>
> > >> this means notrack is not recognized if fndecl is not NULL.  Note
> > >> that only the two callers know the real function type in effect
> > >> (they call gimple_call_set_fntype with it).  I suggest to pass down
> > >> that type to gimple_build_call_from_tree and move the
> > >> gimple_call_set_fntype call there as well.  And simply use the type
> > >> for the
> > above.
> > >
> > > The best way to say is notrack is not propagated if fndecl is not NULL.
> > Fndecl, if not NULL, is a direct call and notrack is not applicable
> > for such calls. I will add a comment before the if.
> >
> > Hmm.  But what does this mean?  I guess direct calls are always
> > 'notrack' then and thus we're fine to ignore it.
> 
> Yes, that's correct - direct calls are always 'notrack' and we are ignoring 
> it in
> calls.
> 

Re: [PATCH]: PR target/80204 (Darwin macosx-version-min problem)

[Jeff Law]

On 09/04/2017 01:48 PM, Jakub Jelinek wrote:
> On Mon, Sep 04, 2017 at 08:47:07PM +0100, Simon Wright wrote:
>> On 1 Sep 2017, at 23:05, Simon Wright  wrote:
>>>
>>> 2017-09-01 Simon Wright 
>>>
>>> PR target/80204
>>> * config/darwin-driver.c (darwin_find_version_from_kernel): eliminate 
>>> calculation of the
>>>   minor version, always output as 0.
>>
>> Like this?
>>
>> Do you need the patch to be resubmitted as well?
>>
>> gcc/Changelog
>>
>> 2017-09-01 Simon Wright 
>>
>>  PR target/80204
>>  * config/darwin-driver.c (darwin_find_version_from_kernel):
>>  Eliminate calculation of the minor version, always output as 0.
> 
> Better
> 
> 2017-09-01 Simon Wright 
> 
>   PR target/80204
>   * config/darwin-driver.c (darwin_find_version_from_kernel): Eliminate
>   calculation of the minor version, always output as 0.
Committed with Jakub's ChangeLog fixes.

jeff

[C PATCH] field_decl_cmp

[Nathan Sidwell]

Joseph,
in moving field_decl_cmp to the C FE, I noticed it checks for NULL 
DECL_NAMES.  Those don't occur.


This patch removes that checking, and also asserts that when we see 
identically named decls, exactly one is a TYPE_DECL.


ok?

nathan
--
Nathan Sidwell
2017-09-12  Nathan Sidwell  

	* c-decl.c (field_decl_cmp): Don't handle NULL names.  Refactor.

Index: c-decl.c
===
--- c-decl.c	(revision 252023)
+++ c-decl.c	(working copy)
@@ -7845,19 +7845,17 @@ warn_cxx_compat_finish_struct (tree fiel
 static int
 field_decl_cmp (const void *x_p, const void *y_p)
 {
-  const tree *const x = (const tree *) x_p;
-  const tree *const y = (const tree *) y_p;
+  const tree x = *(const tree *) x_p;
+  const tree y = *(const tree *) y_p;
 
-  if (DECL_NAME (*x) == DECL_NAME (*y))
-/* A nontype is "greater" than a type.  */
-return (TREE_CODE (*y) == TYPE_DECL) - (TREE_CODE (*x) == TYPE_DECL);
-  if (DECL_NAME (*x) == NULL_TREE)
-return -1;
-  if (DECL_NAME (*y) == NULL_TREE)
-return 1;
-  if (DECL_NAME (*x) < DECL_NAME (*y))
-return -1;
-  return 1;
+  if (DECL_NAME (x) != DECL_NAME (y))
+return DECL_NAME (x) < DECL_NAME (y) ? -1 : +1;
+
+  /* If the names are the same, exactly one must be a TYPE_DECL, and
+ that one is less than (before) the other one.  */
+  gcc_checking_assert ((TREE_CODE (x) == TYPE_DECL)
+		   != (TREE_CODE (y) == TYPE_DECL));
+  return TREE_CODE (x) == TYPE_DECL ? -1 : +1;
 }
 
 /* Fill in the fields of a RECORD_TYPE or UNION_TYPE node, T.

Re: [PATCH, rs6000] Folding of vector loads in GIMPLE

[Bill Schmidt]

> On Sep 12, 2017, at 9:41 AM, Will Schmidt  wrote:
> 
> Hi
> 
> [PATCH, rs6000] Folding of vector loads in GIMPLE
> 
> Folding of vector loads in GIMPLE.
> 
> - Add code to handle gimple folding for the vec_ld builtins.
> - Remove the now obsoleted folding code for vec_ld from rs6000-c.c. 
> Surrounding
> comments have been adjusted slightly so they continue to read OK for the
> vec_st code that remains.
> 
> The resulting code is specifically verified by the powerpc/fold-vec-ld-*.c
> tests which have been posted separately. (a few minutes ago).
> 
> Regtest successfully completed on power6 and newer. (p6,p7,p8le,p8be,p9).
> 
> OK for trunk?
> 
> Thanks,
> -Will
> 
> [gcc]
> 
>2017-09-12  Will Schmidt  
> 
>   * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add handling
> for early folding of vector loads (ALTIVEC_BUILTIN_LVX_*).
>   * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
> Remove obsoleted code for handling ALTIVEC_BUILTIN_VEC_LD.
> 
> diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
> index 897306c..73e14d9 100644
> --- a/gcc/config/rs6000/rs6000-c.c
> +++ b/gcc/config/rs6000/rs6000-c.c
> @@ -6459,92 +6459,19 @@ altivec_resolve_overloaded_builtin (location_t loc, 
> tree fndecl,
>convert (TREE_TYPE (stmt), arg0));
>   stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
>   return stmt;
> }
> 
> -  /* Expand vec_ld into an expression that masks the address and
> - performs the load.  We need to expand this early to allow
> +  /* Expand vec_st into an expression that masks the address and
> + performs the store.  We need to expand this early to allow
>  the best aliasing, as by the time we get into RTL we no longer
>  are able to honor __restrict__, for example.  We may want to
>  consider this for all memory access built-ins.
> 
>  When -maltivec=be is specified, or the wrong number of arguments
>  is provided, simply punt to existing built-in processing.  */
> -  if (fcode == ALTIVEC_BUILTIN_VEC_LD
> -  && (BYTES_BIG_ENDIAN || !VECTOR_ELT_ORDER_BIG)
> -  && nargs == 2)
> -{
> -  tree arg0 = (*arglist)[0];
> -  tree arg1 = (*arglist)[1];
> -
> -  /* Strip qualifiers like "const" from the pointer arg.  */
> -  tree arg1_type = TREE_TYPE (arg1);
> -  if (!POINTER_TYPE_P (arg1_type) && TREE_CODE (arg1_type) != ARRAY_TYPE)
> - goto bad;
> -
> -  tree inner_type = TREE_TYPE (arg1_type);
> -  if (TYPE_QUALS (TREE_TYPE (arg1_type)) != 0)
> - {
> -   arg1_type = build_pointer_type (build_qualified_type (inner_type,
> - 0));
> -   arg1 = fold_convert (arg1_type, arg1);
> - }
> -
> -  /* Construct the masked address.  Let existing error handling take
> -  over if we don't have a constant offset.  */
> -  arg0 = fold (arg0);
> -
> -  if (TREE_CODE (arg0) == INTEGER_CST)
> - {
> -   if (!ptrofftype_p (TREE_TYPE (arg0)))
> - arg0 = build1 (NOP_EXPR, sizetype, arg0);
> -
> -   tree arg1_type = TREE_TYPE (arg1);
> -   if (TREE_CODE (arg1_type) == ARRAY_TYPE)
> - {
> -   arg1_type = TYPE_POINTER_TO (TREE_TYPE (arg1_type));
> -   tree const0 = build_int_cstu (sizetype, 0);
> -   tree arg1_elt0 = build_array_ref (loc, arg1, const0);
> -   arg1 = build1 (ADDR_EXPR, arg1_type, arg1_elt0);
> - }
> -
> -   tree addr = fold_build2_loc (loc, POINTER_PLUS_EXPR, arg1_type,
> -arg1, arg0);
> -   tree aligned = fold_build2_loc (loc, BIT_AND_EXPR, arg1_type, addr,
> -   build_int_cst (arg1_type, -16));
> -
> -   /* Find the built-in to get the return type so we can convert
> -  the result properly (or fall back to default handling if the
> -  arguments aren't compatible).  */
> -   for (desc = altivec_overloaded_builtins;
> -desc->code && desc->code != fcode; desc++)
> - continue;
> -
> -   for (; desc->code == fcode; desc++)
> - if (rs6000_builtin_type_compatible (TREE_TYPE (arg0), desc->op1)
> - && (rs6000_builtin_type_compatible (TREE_TYPE (arg1),
> - desc->op2)))
> -   {
> - tree ret_type = rs6000_builtin_type (desc->ret_type);
> - if (TYPE_MODE (ret_type) == V2DImode)
> -   /* Type-based aliasing analysis thinks vector long
> -  and vector long long are different and will put them
> -  in distinct alias classes.  Force our return type
> -  to be a may-alias type to avoid this.  */
> -   ret_type
> - = build_pointer_type_for_mode (ret_type, Pmode,
> -

Re: [PATCH] Fix emission of exception dispatch (PR middle-end/82154).

[Jeff Law]

On 09/12/2017 01:43 AM, Martin Liška wrote:
> Hello.
> 
> In transition to simple_case_node, I forgot to initialize m_high to m_low if 
> a case
> does not have CASE_HIGH.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Ready to be installed?
> Martin
> 
> gcc/ChangeLog:
> 
> 2017-09-11  Martin Liska  
> 
>   PR middle-end/82154
>   * stmt.c (struct simple_case_node): Assign low to high when
>   high is equal to null.
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-09-11  Martin Liska  
> 
>   PR middle-end/82154
>   * g++.dg/torture/pr82154.C: New test.
OK.

THough I have to wonder if we should unify the HIGH handling -- having
two different conventions is bound to be confusing.

In a CASE_LABEL_EXPR the CASE_HIGH can be NULL, which means the label
refers to a singleton value that is found in CASE_LOW.

That means we end up doing stuff like this:

 if (CASE_HIGH (elt))
maxval = fold_convert (index_type, CASE_HIGH (elt));
  else
maxval = fold_convert (index_type, CASE_LOW (elt));



You could legitimately argue for changing how this works for tree nodes
so that there's always a non-null CASE_HIGH.

jeff

Re: [PATCH] Fix powerpc ICE with __builtin_vec_ld on an array (PR target/82112, take 2)

[Bill Schmidt]

> On Sep 12, 2017, at 10:00 AM, Segher Boessenkool  
> wrote:
> 
> Hi Jakub,
> 
> On Tue, Sep 12, 2017 at 04:25:48PM +0200, Jakub Jelinek wrote:
>> On Thu, Sep 07, 2017 at 10:40:30AM +0200, Jakub Jelinek wrote:
>>> The C and C++ FE handle resolve_overloaded_builtin differently, the C FE
>>> calls it when e.g. array-to-pointer and function-to-pointer conversions
>>> are already done on the arguments, while C++ FE does that only much later.
>>> The c-common code e.g. for __sync/__atomic builtins deals with
>>> that e.g. by:
>>>  if (TREE_CODE (type) == ARRAY_TYPE)
>>>{
>>>  /* Force array-to-pointer decay for C++.  */
>>>  gcc_assert (c_dialect_cxx());
>>>  (*params)[0] = default_conversion ((*params)[0]);
>>>  type = TREE_TYPE ((*params)[0]);
>>>}
>>> while the rs6000 md hook uses default_conversion only in one spot (the
>>> generic handling), but for vec_ld and vec_st does something on its own.
>>> What is even worse is that for vec_ld, it does that too late, there is
>>> a fold_convert in between for the case where the element type is
>>> qualified, and that only works if the argument is pointer, not array
>>> (in which case it ICEs).
>>> So, the following patch moves the vec_ld conversion earlier and for both
>>> vec_ld and vec_st uses what c-common as well as later
>>> altivec_resolve_overloaded_builtin uses.
>> 
>> Here is an updated version of that patch, fixed for the C90 non-lvalue
>> arrays (which we want to reject as c-family rejects them for __atomic_*
>> etc.).  Bootstrapped/regtested on powerpc64-linux (regtest with {,-m32}), ok 
>> for
>> trunk?
> 
> It looks fine to me; Bill, could you take a look?  You know this stuff
> much better than I do :-)

This looks okay to me as well.  Jakub, FYI, Will Schmidt just posted a patch
that will delete all of this code and replace it with early gimple folding, 
which
will save us from these tedious parsing issues.  But I think we should take
this patch first and consider backports to 6 and 7, since those releases will
still use the parser hooks.

(Will's patch is only for vec_ld, but he will follow up with a vec_st patch
shortly.)

Thanks,
Bill
> 
> One question below:
> 
>> 2017-09-12  Jakub Jelinek  
>> 
>>  PR target/82112
>>  * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): For
>>  ALTIVEC_BUILTIN_VEC_LD if arg1 has array type call default_conversion
>>  on it early, rather than manual conversion late.  For
>>  ALTIVEC_BUILTIN_VEC_ST if arg2 has array type call default_conversion
>>  instead of performing manual conversion.
>> 
>>  * gcc.target/powerpc/pr82112.c: New test.
>>  * g++.dg/ext/altivec-18.C: New test.
>> 
>> --- gcc/config/rs6000/rs6000-c.c.jj  2017-09-08 09:13:59.863591547 +0200
>> +++ gcc/config/rs6000/rs6000-c.c 2017-09-08 09:16:36.354738183 +0200
>> @@ -6480,7 +6480,13 @@ altivec_resolve_overloaded_builtin (loca
>> 
>>   /* Strip qualifiers like "const" from the pointer arg.  */
>>   tree arg1_type = TREE_TYPE (arg1);
>> -  if (!POINTER_TYPE_P (arg1_type) && TREE_CODE (arg1_type) != 
>> ARRAY_TYPE)
>> +  if (TREE_CODE (arg1_type) == ARRAY_TYPE && c_dialect_cxx ())
>> +{
>> +  /* Force array-to-pointer decay for C++.  */
>> +  arg1 = default_conversion (arg1);
>> +  arg1_type = TREE_TYPE (arg1);
>> +}
>> +  if (!POINTER_TYPE_P (arg1_type))
>>  goto bad;
>> 
>>   tree inner_type = TREE_TYPE (arg1_type);
>> @@ -6500,15 +6506,6 @@ altivec_resolve_overloaded_builtin (loca
>>if (!ptrofftype_p (TREE_TYPE (arg0)))
>>  arg0 = build1 (NOP_EXPR, sizetype, arg0);
>> 
>> -  tree arg1_type = TREE_TYPE (arg1);
>> -  if (TREE_CODE (arg1_type) == ARRAY_TYPE)
>> -{
>> -  arg1_type = TYPE_POINTER_TO (TREE_TYPE (arg1_type));
>> -  tree const0 = build_int_cstu (sizetype, 0);
>> -  tree arg1_elt0 = build_array_ref (loc, arg1, const0);
>> -  arg1 = build1 (ADDR_EXPR, arg1_type, arg1_elt0);
>> -}
>> -
>>tree addr = fold_build2_loc (loc, POINTER_PLUS_EXPR, arg1_type,
>> arg1, arg0);
>>tree aligned = fold_build2_loc (loc, BIT_AND_EXPR, arg1_type, addr,
>> @@ -6563,12 +6560,11 @@ altivec_resolve_overloaded_builtin (loca
>>  arg1 = build1 (NOP_EXPR, sizetype, arg1);
>> 
>>tree arg2_type = TREE_TYPE (arg2);
>> -  if (TREE_CODE (arg2_type) == ARRAY_TYPE)
>> +  if (TREE_CODE (arg2_type) == ARRAY_TYPE && c_dialect_cxx ())
>>  {
>> -  arg2_type = TYPE_POINTER_TO (TREE_TYPE (arg2_type));
>> -  tree const0 = build_int_cstu (sizetype, 0);
>> -  tree arg2_elt0 = build_array_ref (loc, arg2, const0);
>> -  arg2 = build1 (ADDR_EXPR, arg2_type, arg2_elt0);
>> +  /* Force array-to-pointer decay for C++.  */
>> +  arg2 = default_conversion (arg2);
>> +  arg2_type = TREE_TYPE (arg2);
>>  }
>> 

Re: [PATCH, rs6000] testcase coverage for vector load builtins

[Segher Boessenkool]

On Tue, Sep 12, 2017 at 09:36:41AM -0500, Will Schmidt wrote:
> [PATCH, rs6000] testcase coverage for vector load builtins
> Add testcase coverage for the vec_ld intrinsic builtins.
> 
> Tested across power platforms (p6 and newer). OK for trunk?

Looks good, please apply.  Thanks!


Segher

[ Your mailer wrapped some lines btw. ]


> 2017-09-12  Will Schmidt  
> 
>   * gcc.target/powerpc/fold-vec-ld-char.c: New.
>   * gcc.target/powerpc/fold-vec-ld-double.c: New.
>   * gcc.target/powerpc/fold-vec-ld-float.c: New.
>   * gcc.target/powerpc/fold-vec-ld-int.c: New.
>   * gcc.target/powerpc/fold-vec-ld-longlong.c: New.
>   * gcc.target/powerpc/fold-vec-ld-short.c: New.

Re: [PATCH] Fix powerpc ICE with __builtin_vec_ld on an array (PR target/82112, take 2)

[Jakub Jelinek]

On Tue, Sep 12, 2017 at 10:00:44AM -0500, Segher Boessenkool wrote:
> > --- gcc/testsuite/g++.dg/ext/altivec-18.C.jj2017-09-08 
> > 09:15:20.593774717 +0200
> > +++ gcc/testsuite/g++.dg/ext/altivec-18.C   2017-09-08 09:15:20.593774717 
> > +0200
> > @@ -0,0 +1,14 @@
> > +// PR target/82112
> > +// { dg-do compile { target powerpc*-*-* } }
> > +// { dg-require-effective-target powerpc_altivec_ok }
> > +// { dg-options "-save-temps -maltivec" }
> 
> What is this -save-temps for?  Just a leftover?

It is not really needed, I've just copied/pasted those 3 lines
from some other testcase (which probably used it uselessly as well).
-save-temps can make sense for dg-do link/run testcases where somebody
also wants to dg-final scan-assembler, or for the very rare case when
actually the -save-temps behavior needs to be tested (using separate
preprocessor etc.).  Will fix.

Jakub

Re: [PATCH] Fix powerpc ICE with __builtin_vec_ld on an array (PR target/82112, take 2)

[Segher Boessenkool]

Hi Jakub,

On Tue, Sep 12, 2017 at 04:25:48PM +0200, Jakub Jelinek wrote:
> On Thu, Sep 07, 2017 at 10:40:30AM +0200, Jakub Jelinek wrote:
> > The C and C++ FE handle resolve_overloaded_builtin differently, the C FE
> > calls it when e.g. array-to-pointer and function-to-pointer conversions
> > are already done on the arguments, while C++ FE does that only much later.
> > The c-common code e.g. for __sync/__atomic builtins deals with
> > that e.g. by:
> >   if (TREE_CODE (type) == ARRAY_TYPE)
> > {
> >   /* Force array-to-pointer decay for C++.  */
> >   gcc_assert (c_dialect_cxx());
> >   (*params)[0] = default_conversion ((*params)[0]);
> >   type = TREE_TYPE ((*params)[0]);
> > }
> > while the rs6000 md hook uses default_conversion only in one spot (the
> > generic handling), but for vec_ld and vec_st does something on its own.
> > What is even worse is that for vec_ld, it does that too late, there is
> > a fold_convert in between for the case where the element type is
> > qualified, and that only works if the argument is pointer, not array
> > (in which case it ICEs).
> > So, the following patch moves the vec_ld conversion earlier and for both
> > vec_ld and vec_st uses what c-common as well as later
> > altivec_resolve_overloaded_builtin uses.
> 
> Here is an updated version of that patch, fixed for the C90 non-lvalue
> arrays (which we want to reject as c-family rejects them for __atomic_*
> etc.).  Bootstrapped/regtested on powerpc64-linux (regtest with {,-m32}), ok 
> for
> trunk?

It looks fine to me; Bill, could you take a look?  You know this stuff
much better than I do :-)

One question below:

> 2017-09-12  Jakub Jelinek  
> 
>   PR target/82112
>   * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): For
>   ALTIVEC_BUILTIN_VEC_LD if arg1 has array type call default_conversion
>   on it early, rather than manual conversion late.  For
>   ALTIVEC_BUILTIN_VEC_ST if arg2 has array type call default_conversion
>   instead of performing manual conversion.
> 
>   * gcc.target/powerpc/pr82112.c: New test.
>   * g++.dg/ext/altivec-18.C: New test.
> 
> --- gcc/config/rs6000/rs6000-c.c.jj   2017-09-08 09:13:59.863591547 +0200
> +++ gcc/config/rs6000/rs6000-c.c  2017-09-08 09:16:36.354738183 +0200
> @@ -6480,7 +6480,13 @@ altivec_resolve_overloaded_builtin (loca
>  
>/* Strip qualifiers like "const" from the pointer arg.  */
>tree arg1_type = TREE_TYPE (arg1);
> -  if (!POINTER_TYPE_P (arg1_type) && TREE_CODE (arg1_type) != ARRAY_TYPE)
> +  if (TREE_CODE (arg1_type) == ARRAY_TYPE && c_dialect_cxx ())
> + {
> +   /* Force array-to-pointer decay for C++.  */
> +   arg1 = default_conversion (arg1);
> +   arg1_type = TREE_TYPE (arg1);
> + }
> +  if (!POINTER_TYPE_P (arg1_type))
>   goto bad;
>  
>tree inner_type = TREE_TYPE (arg1_type);
> @@ -6500,15 +6506,6 @@ altivec_resolve_overloaded_builtin (loca
> if (!ptrofftype_p (TREE_TYPE (arg0)))
>   arg0 = build1 (NOP_EXPR, sizetype, arg0);
>  
> -   tree arg1_type = TREE_TYPE (arg1);
> -   if (TREE_CODE (arg1_type) == ARRAY_TYPE)
> - {
> -   arg1_type = TYPE_POINTER_TO (TREE_TYPE (arg1_type));
> -   tree const0 = build_int_cstu (sizetype, 0);
> -   tree arg1_elt0 = build_array_ref (loc, arg1, const0);
> -   arg1 = build1 (ADDR_EXPR, arg1_type, arg1_elt0);
> - }
> -
> tree addr = fold_build2_loc (loc, POINTER_PLUS_EXPR, arg1_type,
>  arg1, arg0);
> tree aligned = fold_build2_loc (loc, BIT_AND_EXPR, arg1_type, addr,
> @@ -6563,12 +6560,11 @@ altivec_resolve_overloaded_builtin (loca
>   arg1 = build1 (NOP_EXPR, sizetype, arg1);
>  
> tree arg2_type = TREE_TYPE (arg2);
> -   if (TREE_CODE (arg2_type) == ARRAY_TYPE)
> +   if (TREE_CODE (arg2_type) == ARRAY_TYPE && c_dialect_cxx ())
>   {
> -   arg2_type = TYPE_POINTER_TO (TREE_TYPE (arg2_type));
> -   tree const0 = build_int_cstu (sizetype, 0);
> -   tree arg2_elt0 = build_array_ref (loc, arg2, const0);
> -   arg2 = build1 (ADDR_EXPR, arg2_type, arg2_elt0);
> +   /* Force array-to-pointer decay for C++.  */
> +   arg2 = default_conversion (arg2);
> +   arg2_type = TREE_TYPE (arg2);
>   }
>  
> /* Find the built-in to make sure a compatible one exists; if not
> --- gcc/testsuite/gcc.target/powerpc/pr82112.c.jj 2017-09-08 
> 09:20:35.187912843 +0200
> +++ gcc/testsuite/gcc.target/powerpc/pr82112.c2017-09-08 
> 09:24:21.362376676 +0200
> @@ -0,0 +1,16 @@
> +/* PR target/82112 */
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-options "-maltivec -std=gnu90" } */
> +
> +#include 
> +
> +struct __attribute__((aligned (16))) S { unsigned char c[64]; } bar (void);
> +vector unsigned char v;

[Patch AArch64 2/2] Fix memory sizes to load/store patterns

[James Greenhalgh]

On Mon, Jun 12, 2017 at 02:54:00PM +0100, James Greenhalgh wrote:
>
> Hi,
>
> There seems to be a partial misconception in the AArch64 backend that
> load1/load2 referred to the number of registers to load, rather than the
> number of words to load. This patch fixes that using the new "number of
> byte" types added in the previous patch.
>
> That means using the load_16 and store_16 types that were defined in the
> previous patch for the first time in the AArch64 backend. To ensure
> continuity for scheduling models, I've just split this out from load_8.
> Please update your models if this is very wrong!

I've updated this patch on trunk, rechecked it, and committed this patch
as r252026.

Thanks,
James

---
2017-09-12  James Greenhalgh  

* config/aarch64/aarch64.md (movdi_aarch64): Set load/store
types correctly.
(movti_aarch64): Likewise.
(movdf_aarch64): Likewise.
(movtf_aarch64): Likewise.
(load_pairdi): Likewise.
(store_pairdi): Likewise.
(load_pairdf): Likewise.
(store_pairdf): Likewise.
(loadwb_pair_): Likewise.
(storewb_pair_): Likewise.
(ldr_got_small_): Likewise.
(ldr_got_small_28k_): Likewise.
(ldr_got_tiny): Likewise.
* config/aarch64/iterators.md (ldst_sz): New.
(ldpstp_sz): Likewise.
* config/aarch64/thunderx.md (thunderx_storepair): Split store_8
to store_16.
(thunderx_load): Split load_8 to load_16.
* config/aarch64/thunderx2t99.md (thunderx2t99_loadpair): Split
load_8 to load_16.
(thunderx2t99_storepair_basic): Split store_8 to store_16.
* config/arm/xgene1.md (xgene1_load_pair): Split load_8 to load_16.
(xgene1_store_pair): Split store_8 to store_16.
* config/aarch64/falkor.md (falkor_ld_3_ld): Split load_8 to load_16.
(falkor_st_0_st_sd): Split store_8 to store_16.

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 7cbb458..e85376c 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -994,8 +994,8 @@
aarch64_expand_mov_immediate (operands[0], operands[1]);
DONE;
 }"
-  [(set_attr "type" "mov_reg,mov_reg,mov_reg,mov_imm,mov_imm,mov_imm,load_4,\
- load_4,store_4,store_4,adr,adr,f_mcr,f_mrc,fmov,neon_move")
+  [(set_attr "type" "mov_reg,mov_reg,mov_reg,mov_imm,mov_imm,mov_imm,load_8,\
+ load_8,store_8,store_8,adr,adr,f_mcr,f_mrc,fmov,neon_move")
(set_attr "fp" "*,*,*,*,*,*,*,yes,*,yes,*,*,yes,yes,yes,*")
(set_attr "simd" "*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,yes")]
 )
@@ -1039,7 +1039,8 @@
ldr\\t%q0, %1
str\\t%q1, %0"
   [(set_attr "type" "multiple,f_mcr,f_mrc,neon_logic_q, \
-		 load_8,store_8,store_8,f_loadd,f_stored")
+		 load_16,store_16,store_16,\
+ load_16,store_16")
(set_attr "length" "8,8,8,4,4,4,4,4,4")
(set_attr "simd" "*,*,*,yes,*,*,*,*,*")
(set_attr "fp" "*,*,*,*,*,*,*,yes,yes")]
@@ -1142,7 +1143,7 @@
mov\\t%x0, %x1
mov\\t%x0, %1"
   [(set_attr "type" "neon_move,f_mcr,f_mrc,fmov,fconstd,neon_move,\
-		 f_loadd,f_stored,load_4,store_4,mov_reg,\
+		 f_loadd,f_stored,load_8,store_8,mov_reg,\
 		 fconstd")
(set_attr "simd" "yes,*,*,*,*,yes,*,*,*,*,*,*")]
 )
@@ -1187,7 +1188,7 @@
stp\\t%1, %H1, %0
stp\\txzr, xzr, %0"
   [(set_attr "type" "logic_reg,multiple,f_mcr,f_mrc,neon_move_q,f_mcr,\
- f_loadd,f_stored,load_8,store_8,store_8")
+ f_loadd,f_stored,load_16,store_16,store_16")
(set_attr "length" "4,8,8,8,4,4,4,4,4,4,4")
(set_attr "simd" "yes,*,*,*,yes,*,*,*,*,*,*")]
 )
@@ -1251,7 +1252,7 @@
   "@
ldp\\t%x0, %x2, %1
ldp\\t%d0, %d2, %1"
-  [(set_attr "type" "load_8,neon_load1_2reg")
+  [(set_attr "type" "load_16,neon_load1_2reg")
(set_attr "fp" "*,yes")]
 )
 
@@ -1286,7 +1287,7 @@
   "@
stp\\t%x1, %x3, %0
stp\\t%d1, %d3, %0"
-  [(set_attr "type" "store_8,neon_store1_2reg")
+  [(set_attr "type" "store_16,neon_store1_2reg")
(set_attr "fp" "*,yes")]
 )
 
@@ -1320,7 +1321,7 @@
   "@
ldp\\t%d0, %d2, %1
ldp\\t%x0, %x2, %1"
-  [(set_attr "type" "neon_load1_2reg,load_8")
+  [(set_attr "type" "neon_load1_2reg,load_16")
(set_attr "fp" "yes,*")]
 )
 
@@ -1354,7 +1355,7 @@
   "@
stp\\t%d1, %d3, %0
stp\\t%x1, %x3, %0"
-  [(set_attr "type" "neon_store1_2reg,store_8")
+  [(set_attr "type" "neon_store1_2reg,store_16")
(set_attr "fp" "yes,*")]
 )
 
@@ -1372,7 +1373,7 @@
(match_operand:P 5 "const_int_operand" "n"])]
   "INTVAL (operands[5]) == GET_MODE_SIZE (mode)"
   "ldp\\t%2, %3, [%1], %4"
-  [(set_attr "type" "load_8")]
+  [(set_attr "type" "load_")]
 )
 
 (define_insn "loadwb_pair_"
@@ -1405,7 +1406,7 @@
   (match_operand:GPI 3 "register_operand" "r"))])]
   "INTVAL (operands[5]) == INTVAL (operands[4]) + GET_MODE_SIZE 

Re: [Mechanical Patch ARM/AArch64 1/2] Rename load/store scheduling types to encode data size

[James Greenhalgh]

On Mon, Jun 12, 2017 at 02:53:59PM +0100, James Greenhalgh wrote:
>
> Hi,
>
> In the AArch64 backend and scheduling models there is some confusion as to
> what the load1/load2 etc. scheduling types refer to. This leads to us using
> load1/load2 in two contexts - for a variety of 32-bit, 64-bit and 128-bit
> loads in AArch32 and 128-bit loads in AArch64. That leads to an undesirable
> confusion in scheduling.
>
> Fixing it is easy, but mechanical and boring. Essentially,
>
>   s/load1/load_4/
>   s/load2/load_8/
>   s/load3/load_12/
>   s/load4/load_16/
>   s/store1/store_4/
>   s/store2/store_8/
>   s/store3/store_12/
>   s/store4/store_16/
>
> Across all sorts of pipeline models, and the two backends.
>
> I have intentionally not modified any of the patterns which now look obviously
> incorrect. I'll be doing a second pass over the AArch64 back-end in patch
> 2/2 which will fix these bugs. The AArch32 back-end looked to me to get this
> correct.
>
> Bootstrapped on AArch64 and ARM without issue - there's no functional
> change here.

Kyrill OKed the Arm parts of this, so I've committed this as r252025,
after rebasing to current trunk and updating for the addition of the Falkor
scheduling model and checking we can still bootstrap/pass the test suite.

Thanks,
James

---
gcc/

2017-06-12  James Greenhalgh  

* config/arm/types.md (type): Rename load1/2/3/4 to load_4/8/12/16
and store1/2/3/4 to store_4/8/12/16.
* config/aarch64/aarch64.md: Update for rename.
* config/arm/arm.md: Likewise.: Likewise.
* config/arm/arm.c: Likewise.
* config/arm/thumb1.md: Likewise.
* config/arm/thumb2.md: Likewise.
* config/arm/vfp.md: Likewise.
* config/arm/arm-generic.md: Likewise.
* config/arm/arm1020e.md: Likewise.
* config/arm/arm1026ejs.md: Likewise.
* config/arm/arm1136jfs.md: Likewise.
* config/arm/arm926ejs.md: Likewise.
* config/arm/cortex-a15.md: Likewise.
* config/arm/cortex-a17.md: Likewise.
* config/arm/cortex-a5.md: Likewise.
* config/arm/cortex-a53.md: Likewise.
* config/arm/cortex-a57.md: Likewise.
* config/arm/cortex-a7.md: Likewise.
* config/arm/cortex-a8.md: Likewise.
* config/arm/cortex-a9.md: Likewise.
* config/arm/cortex-m4.md: Likewise.
* config/arm/cortex-m7.md: Likewise.
* config/arm/cortex-r4.md: Likewise.
* config/arm/exynos-m1.md: Likewise.
* config/arm/fa526.md: Likewise.
* config/arm/fa606te.md: Likewise.
* config/arm/fa626te.md: Likewise.
* config/arm/fa726te.md: Likewise.
* config/arm/fmp626.md: Likewise.
* config/arm/iwmmxt.md: Likewise.
* config/arm/ldmstm.md: Likewise.
* config/arm/marvell-pj4.md: Likewise.
* config/arm/xgene1.md: Likewise.
* config/aarch64/thunderx.md: Likewise.
* config/aarch64/thunderx2t99.md: Likewise.
* config/aarch64/falkor.md: Likewise.

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index bb7f2c0..7cbb458 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -558,7 +558,7 @@
 operands[0] = gen_rtx_MEM (DImode, operands[0]);
 return pftype[INTVAL(operands[1])][locality];
   }
-  [(set_attr "type" "load1")]
+  [(set_attr "type" "load_4")]
 )
 
 (define_insn "trap"
@@ -902,7 +902,7 @@
gcc_unreachable ();
  }
 }
-  [(set_attr "type" "mov_reg,mov_imm,neon_move,load1,load1,store1,store1,\
+  [(set_attr "type" "mov_reg,mov_imm,neon_move,load_4,load_4,store_4,store_4,\
  neon_to_gp,neon_from_gp,neon_dup")
(set_attr "simd" "*,*,yes,*,*,*,*,yes,yes,yes")]
 )
@@ -959,7 +959,7 @@
aarch64_expand_mov_immediate (operands[0], operands[1]);
DONE;
 }"
-  [(set_attr "type" "mov_reg,mov_reg,mov_reg,mov_imm,mov_imm,load1,load1,store1,store1,\
+  [(set_attr "type" "mov_reg,mov_reg,mov_reg,mov_imm,mov_imm,load_4,load_4,store_4,store_4,\
 		adr,adr,f_mcr,f_mrc,fmov,neon_move")
(set_attr "fp" "*,*,*,*,*,*,yes,*,yes,*,*,yes,yes,yes,*")
(set_attr "simd" "*,*,*,*,*,*,*,*,*,*,*,*,*,*,yes")]
@@ -994,8 +994,8 @@
aarch64_expand_mov_immediate (operands[0], operands[1]);
DONE;
 }"
-  [(set_attr "type" "mov_reg,mov_reg,mov_reg,mov_imm,mov_imm,mov_imm,load1,\
- load1,store1,store1,adr,adr,f_mcr,f_mrc,fmov,neon_move")
+  [(set_attr "type" "mov_reg,mov_reg,mov_reg,mov_imm,mov_imm,mov_imm,load_4,\
+ load_4,store_4,store_4,adr,adr,f_mcr,f_mrc,fmov,neon_move")
(set_attr "fp" "*,*,*,*,*,*,*,yes,*,yes,*,*,yes,yes,yes,*")
(set_attr "simd" "*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,yes")]
 )
@@ -1039,7 +1039,7 @@
ldr\\t%q0, %1
str\\t%q1, %0"
   [(set_attr "type" "multiple,f_mcr,f_mrc,neon_logic_q, \
-		 load2,store2,store2,f_loadd,f_stored")
+		 

Re: C++ PATCH to reduced_constant_expression for partially-initialized objects

[Christophe Lyon]

On 12 September 2017 at 16:21, Andrew Pinski  wrote:
> On Tue, Sep 12, 2017 at 7:17 AM, Christophe Lyon
>  wrote:
>> Hi Jason
>>
>> On 10 September 2017 at 11:09, Jason Merrill  wrote:
>>> A few months back I queued this patch to bring back for GCC 8.
>>> Unfortunately I don't remember the context that it came up in, but it
>>> affects for instance cases of self-assignment, which can't have a
>>> constant value if there is no previous initialization.
>>>
>>> Tested x86_64-pc-linux-gnu, applying to trunk.
>>
>> I've noticed that this patch causes a regression in fortran on
>> armeb-linux-gnumeabihf
>> FAIL:gfortran.dg/allocate_zerosize_3.f   -O3 -fomit-frame-pointer
>> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution
>> test
>> FAIL:gfortran.dg/allocate_zerosize_3.f   -O3 -g  execution test
>> FAIL:gfortran.dg/assumed_rank_1.f90   -O3 -fomit-frame-pointer
>> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution
>> test
>> FAIL:gfortran.dg/assumed_rank_1.f90   -O3 -g  execution test
>> FAIL:gfortran.dg/assumed_rank_2.f90   -O3 -fomit-frame-pointer
>> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution
>> test
>> FAIL:gfortran.dg/assumed_rank_2.f90   -O3 -g  execution test
>>
>> target armeb-none-linux-gnueabihf
>> --with-mode arm
>> --with-cpu cortex-a9
>> --with-fpu neon-fp16
>>
>> using --with-fpu vfpv3-d16-fp16 does not introduce the regression.
>>
>> target arm-none-linux-gnueabihf with the same parameters is OK ('arm'
>> as opposed to 'armeb')
>>
>> My gfortran.log only shows:
>> spawn [open ...]
>> Program aborted. Backtrace:
>> qemu: uncaught target signal 6 (Aborted) - core dumped
>
> This makes little sense.  Are you compiling the cross compiler with
> the new native compiler?  Since this patch only touches the C++
> front-end and only C++11 even that makes less sense.  Are you sure
> this was not a bug in qemu which is just happening showing up now?
> Even then this makes little sense as the code generation between the
> two revisions should not touch anything related to fortran.
>

H you are probably right. I'm compiling the cross compiler
with the system's native compiler.

Looks like I need to check why my bisect script returns the wrong revision.

Thanks,

Christophe

> Thanks,
> Andrew Pinski
>
>>
>> Christophe

Re: Add support to trace comparison instructions and switch statements

[Dmitry Vyukov via gcc-patches]

Some stats from kernel build for number of trace_cmp callbacks:

gcc
non-const: 38051
const: 272726
total: 310777

clang:
non-const: 45944
const: 266299
total: 312243

The total is quite close. Gcc seems to emit more const callbacks, which is good.



On Tue, Sep 12, 2017 at 4:32 PM, Dmitry Vyukov  wrote:
> On Thu, Sep 7, 2017 at 9:02 AM, 吴潍浠(此彼)  wrote:
>> Hi
>> The trace-div and trace-gep options seems be used to evaluate corpus
>> to trigger specific kind of bugs. And they don't have strong effect to 
>> coverage.
>>
>> The trace-pc-guard is useful, but it may be much more complex than trace-pc.
>> I think the best benefit of trace-pc-guard is avoiding dealing ASLR of 
>> programs,
>> especially programs with dlopen(). Seems hard to implement it in Linux 
>> kernel.
>>
>> The inline-8bit-counters and pc-table is too close to implementation of fuzz 
>> tool and
>> option trace-pc-guard .
>>
>> I am interesting in "stack-depth" and "func". If we trace user-defined 
>> functions enter and exit,
>> we can calculate stack-depth and difference level of stack to past existed 
>> stack.
>> Adding __sanitizer_cov_trace_pc_{enter,exit} is easy , but it is not 
>> standard of llvm.
>>
>> How do you think Dmitry ?
>>
>> Wish Wu
>>
>> --
>> From:Jakub Jelinek 
>> Time:2017 Sep 6 (Wed) 22:37
>> To:Wish Wu 
>> Cc:Dmitry Vyukov ; gcc-patches 
>> ; Jeff Law ; wishwu007 
>> 
>> Subject:Re: Add support to trace comparison instructions and switch 
>> statements
>>
>>
>> On Wed, Sep 06, 2017 at 07:47:29PM +0800, 吴潍浠(此彼) wrote:
>>> Hi Jakub
>>> I compiled libjpeg-turbo and libdng_sdk with options "-g -O3 -Wall 
>>> -fsanitize-coverage=trace-pc,trace-cmp -fsanitize=address".
>>> And run my fuzzer with pc and cmp feedbacks for hours. It works fine.
>>> About __sanitizer_cov_trace_cmp{f,d} , yes, it  isn't provided by llvm. But 
>>> once we trace integer comparisons, why not real type comparisons.
>>> I remember Dmitry said it is not enough useful to trace real type 
>>> comparisons because it is rare to see them in programs.
>>> But libdng_sdk really has real type comparisons. So I want to keep them and 
>>> implementing __sanitizer_cov_trace_const_cmp{f,d} may be necessary.
>>
>> Ok.  Please make sure those entrypoints make it into the various example
>> __sanitier_cov_trace* fuzzer implementations though, so that people using
>> -fsanitize-coverage=trace-cmp in GCC will not need to hack stuff themselves.
>> At least it should be added to sanitizer_common (both in LLVM and GCC).
>>
>> BTW, https://clang.llvm.org/docs/SanitizerCoverage.html shows various other
>> -fsanitize-coverage= options, some of them terribly misnamed (e.g. trace-gep
>> using some weirdo LLVM IL acronym instead of being named by what it really
>> traces (trace-array-idx or something similar)).
>>
>> Any plans to implement some or all of those?
>
>
> Thanks, Jakub!
>
> I've tested it on Linux kernel. Compiler does not crash, code is instrumented.
>
> Re  terribly misnamed trace-gep, dunno, I will leave this to Kostya.
>
> Re __sanitizer_cov_trace_cmp{f,d}, I am still not sure.
>
>> But libdng_sdk really has real type comparisons.
>
> Do they come from input data? In what format? How do you want to use
> them? E.g. if they come from input but with using some non-trivial
> transformation and the fuzzer will try to find them in the input, it
> won't be able to do so.
> On the other hand, it does not seem to be harmful, fuzzers that are
> not interested in them can just add empty callbacks.
>
> Re trace-pc-guard, I also don't have strong preference. Global
> variables should work for kernel, but we probably will not use them in
> kernel, because even aslr aside we would need to establish some global
> numbering of these globals across multiple different machines. But
> then it's much easier and simper to just use PCs as identifiers.
>
> Re __sanitizer_cov_trace_pc_{enter,exit}, I don't think we ever
> experimented/evaluated this idea. Do you have any data that it's
> useful? I suspect that it can grow corpus too much.

Re: [PATCH] Fix PR82129

[Richard Biener]

On Tue, 12 Sep 2017, Jakub Jelinek wrote:

> On Tue, Sep 12, 2017 at 04:09:41PM +0200, Richard Biener wrote:
> > 
> > The following "fixes" PR82129 (hides the issue).  It folds
> > writes from uninitialized data to CLOBBERs:
> > 
> > -  *h5_26(D) = tv_24(D);
> > +  *h5_26(D) ={v} {CLOBBER};
> > 
> > Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> 
> Won't that affect -W{,maybe-}unitialized a lot?

Not sure - as current it fails bootstrap because I need to guard
against not folding things like foo.bar = x_2(D) (we assert to
have clobbers only on full objects).

Richard.

> > 2017-09-12  Richard Biener  
> > 
> > PR tree-optimization/82129
> > * gimple-fold.c (fold_gimple_assign): Fold stores from undefined
> > values to clobbers.
> > 
> > * gcc.dg/torture/pr82129.c: New testcase.

Re: [PATCH, rs6000] add vectorization to vec_mule and vec_mulo builtins

[Segher Boessenkool]

Hi Carl,

Just some nits:

On Mon, Sep 11, 2017 at 09:18:12AM -0700, Carl Love wrote:
> +(define_expand "vec_widen_smult_odd_v4si"
> +  [(use (match_operand:V2DI 0 "register_operand" ""))
> +   (use (match_operand:V4SI 1 "register_operand" ""))
> +   (use (match_operand:V4SI 2 "register_operand" ""))]

The "" here are superfluous.

> +  "TARGET_P8_VECTOR"
> +{
> +  if (VECTOR_ELT_ORDER_BIG)
> +emit_insn (gen_altivec_vmulosw (operands[0], operands[1],
+   operands[2]));
> +  else
> +emit_insn (gen_altivec_vmulesw (operands[0], operands[1],
> + operands[2]));
> +  DONE;
> +})

These lines fit without wrapping.

Looks fine otherwise, please commit!


Segher

[PATCH, rs6000] Folding of vector loads in GIMPLE

[Will Schmidt]

Hi

[PATCH, rs6000] Folding of vector loads in GIMPLE

Folding of vector loads in GIMPLE.

- Add code to handle gimple folding for the vec_ld builtins.
- Remove the now obsoleted folding code for vec_ld from rs6000-c.c. Surrounding
comments have been adjusted slightly so they continue to read OK for the
vec_st code that remains.

The resulting code is specifically verified by the powerpc/fold-vec-ld-*.c
tests which have been posted separately. (a few minutes ago).

Regtest successfully completed on power6 and newer. (p6,p7,p8le,p8be,p9).

OK for trunk?

Thanks,
-Will

[gcc]

2017-09-12  Will Schmidt  

* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add handling
  for early folding of vector loads (ALTIVEC_BUILTIN_LVX_*).
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
  Remove obsoleted code for handling ALTIVEC_BUILTIN_VEC_LD.

diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index 897306c..73e14d9 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -6459,92 +6459,19 @@ altivec_resolve_overloaded_builtin (location_t loc, 
tree fndecl,
 convert (TREE_TYPE (stmt), arg0));
   stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
   return stmt;
 }
 
-  /* Expand vec_ld into an expression that masks the address and
- performs the load.  We need to expand this early to allow
+  /* Expand vec_st into an expression that masks the address and
+ performs the store.  We need to expand this early to allow
  the best aliasing, as by the time we get into RTL we no longer
  are able to honor __restrict__, for example.  We may want to
  consider this for all memory access built-ins.
 
  When -maltivec=be is specified, or the wrong number of arguments
  is provided, simply punt to existing built-in processing.  */
-  if (fcode == ALTIVEC_BUILTIN_VEC_LD
-  && (BYTES_BIG_ENDIAN || !VECTOR_ELT_ORDER_BIG)
-  && nargs == 2)
-{
-  tree arg0 = (*arglist)[0];
-  tree arg1 = (*arglist)[1];
-
-  /* Strip qualifiers like "const" from the pointer arg.  */
-  tree arg1_type = TREE_TYPE (arg1);
-  if (!POINTER_TYPE_P (arg1_type) && TREE_CODE (arg1_type) != ARRAY_TYPE)
-   goto bad;
-
-  tree inner_type = TREE_TYPE (arg1_type);
-  if (TYPE_QUALS (TREE_TYPE (arg1_type)) != 0)
-   {
- arg1_type = build_pointer_type (build_qualified_type (inner_type,
-   0));
- arg1 = fold_convert (arg1_type, arg1);
-   }
-
-  /* Construct the masked address.  Let existing error handling take
-over if we don't have a constant offset.  */
-  arg0 = fold (arg0);
-
-  if (TREE_CODE (arg0) == INTEGER_CST)
-   {
- if (!ptrofftype_p (TREE_TYPE (arg0)))
-   arg0 = build1 (NOP_EXPR, sizetype, arg0);
-
- tree arg1_type = TREE_TYPE (arg1);
- if (TREE_CODE (arg1_type) == ARRAY_TYPE)
-   {
- arg1_type = TYPE_POINTER_TO (TREE_TYPE (arg1_type));
- tree const0 = build_int_cstu (sizetype, 0);
- tree arg1_elt0 = build_array_ref (loc, arg1, const0);
- arg1 = build1 (ADDR_EXPR, arg1_type, arg1_elt0);
-   }
-
- tree addr = fold_build2_loc (loc, POINTER_PLUS_EXPR, arg1_type,
-  arg1, arg0);
- tree aligned = fold_build2_loc (loc, BIT_AND_EXPR, arg1_type, addr,
- build_int_cst (arg1_type, -16));
-
- /* Find the built-in to get the return type so we can convert
-the result properly (or fall back to default handling if the
-arguments aren't compatible).  */
- for (desc = altivec_overloaded_builtins;
-  desc->code && desc->code != fcode; desc++)
-   continue;
-
- for (; desc->code == fcode; desc++)
-   if (rs6000_builtin_type_compatible (TREE_TYPE (arg0), desc->op1)
-   && (rs6000_builtin_type_compatible (TREE_TYPE (arg1),
-   desc->op2)))
- {
-   tree ret_type = rs6000_builtin_type (desc->ret_type);
-   if (TYPE_MODE (ret_type) == V2DImode)
- /* Type-based aliasing analysis thinks vector long
-and vector long long are different and will put them
-in distinct alias classes.  Force our return type
-to be a may-alias type to avoid this.  */
- ret_type
-   = build_pointer_type_for_mode (ret_type, Pmode,
-  true/*can_alias_all*/);
-   else
- ret_type = build_pointer_type (ret_type);
-   aligned = build1 (NOP_EXPR, ret_type, aligned);
-   tree ret_val = 

[PATCH, rs6000] testcase coverage for vector load builtins

[Will Schmidt]

Hi, 

[PATCH, rs6000] testcase coverage for vector load builtins
Add testcase coverage for the vec_ld intrinsic builtins.

Tested across power platforms (p6 and newer). OK for trunk?

Thanks,
-Will

[gcc/testsuite]

2017-09-12  Will Schmidt  

* gcc.target/powerpc/fold-vec-ld-char.c: New.
* gcc.target/powerpc/fold-vec-ld-double.c: New.
* gcc.target/powerpc/fold-vec-ld-float.c: New.
* gcc.target/powerpc/fold-vec-ld-int.c: New.
* gcc.target/powerpc/fold-vec-ld-longlong.c: New.
* gcc.target/powerpc/fold-vec-ld-short.c: New.

diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-char.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-char.c
new file mode 100644
index 000..f9ef3e0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-char.c
@@ -0,0 +1,71 @@
+/* Verify that overloaded built-ins for vec_ld* with char
+   inputs produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -O2" } */
+
+#include 
+
+vector signed char
+testld_sc_vsc (long long ll1, vector signed char vsc2)
+{
+  return vec_ld (ll1, );
+}
+
+vector signed char
+testld_sc_sc (long long ll1, signed char sc)
+{
+  return vec_ld (ll1, );
+}
+
+vector unsigned char
+testld_uc_vuc (long long ll1, vector unsigned char vuc2)
+{
+  return vec_ld (ll1, );
+}
+
+vector unsigned char
+testld_uc_uc (long long ll1, unsigned char uc)
+{
+  return vec_ld (ll1, );
+}
+
+vector bool char
+testld_bc_vbc (long long ll1, vector bool char vbc2)
+{
+  return vec_ld (ll1, );
+}
+
+vector signed char
+testld_cst_vsc (vector signed char vsc2)
+{
+  return vec_ld (16, );
+}
+
+vector signed char
+testld_cst_sc (signed char sc)
+{
+  return vec_ld (32, );
+}
+
+vector unsigned char
+testld_cst_vuc (vector unsigned char vuc2)
+{
+  return vec_ld (48, );
+}
+
+vector unsigned char
+testld_cst_uc (unsigned char uc)
+{
+  return vec_ld (64, );
+}
+
+vector bool char
+testld_cst_vbc (vector bool char vbc2)
+{
+  return vec_ld (80, );
+}
+
+/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M|\mlxvw4x\M}
10 } } */
+
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-double.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-double.c
new file mode 100644
index 000..9c6fbb2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-double.c
@@ -0,0 +1,22 @@
+/* Verify that overloaded built-ins for vec_ld with 
+   double inputs produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-mvsx -O2" } */
+
+#include 
+
+vector double
+testld_ll_vd (long long ll1, vector double vd)
+{
+  return vec_ld (ll1, );
+}
+
+vector double
+testld_cst_vd (long long ll1, vector double vd)
+{
+  return vec_ld (16, );
+}
+
+/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 2 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-float.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-float.c
new file mode 100644
index 000..eca847a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-float.c
@@ -0,0 +1,37 @@
+/* Verify that overloaded built-ins for vec_ld with float
+   inputs produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -O2" } */
+
+#include 
+
+vector float
+testld_ll_vf (long long ll1, vector float vf2)
+{
+  return vec_ld (ll1, );
+}
+
+vector float
+testld_ll_f (long long ll1, float f2)
+{
+  return vec_ld (ll1, );
+}
+
+vector float
+testld_cst_vf (vector float vf2)
+{
+  return vec_ld (16, );
+}
+
+vector float
+testld_cst_f (float f2)
+{
+  return vec_ld (16, );
+}
+
+// lvx - generated by ll_vf and ll_f
+// lxvd2x - generated by cst_vf and cst_f
+/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */
+
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-int.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-int.c
new file mode 100644
index 000..5dc6df6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-ld-int.c
@@ -0,0 +1,71 @@
+/* Verify that overloaded built-ins for vec_ld* with int
+   inputs produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -O2" } */
+
+#include 
+
+vector signed int
+testld_vsi_vsi (long long ll1, vector signed int vsi2)
+{
+  return vec_ld (ll1, );
+}
+
+vector signed int
+testld_vsi_si (long long ll1, signed int si)
+{
+  return vec_ld (ll1, );
+}
+
+vector unsigned int
+testld_vui_vui (long long ll1, vector unsigned int vui2)
+{
+  return vec_ld (ll1, );
+}
+
+vector unsigned int
+testld_vui_ui (long long ll1, unsigned int ui)
+{
+  return vec_ld (ll1, );
+}
+
+vector bool int
+testld_vbi_vbi (long long ll1, vector bool int vbi2)
+{
+  return vec_ld (ll1, );
+}
+
+vector signed int
+testld_cst_vsi (vector signed int vsi2)
+{
+  return vec_ld (16, );

Re: [PATCH] Fix GIMPLE FE test (PR testsuite/82114)

[Martin Liška]

On 09/12/2017 02:29 PM, Aldy Hernandez wrote:
> I'm going to abuse either my *gimpl* maintainer hat or my obvious hat
> and approve this.
> 
> However, since we already have another test that looks the same
> (gimplefe-error-2.c) but without the 0 case, it would probably be best
> to add a comment in gimplefe-14.c as to why there is a 0 case.  In the
> case of gimplefe-error-2.c, it doesn't matter because it is only a
> compile test.
> 
> OK with that nit.

Thanks for the note, installed as r252024.

Martin

> 
> 
> On Tue, Sep 12, 2017 at 3:44 AM, Martin Liška  wrote:
>> Hello.
>>
>> Simple fix for args == 0 also returns 0 return value.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>> Martin
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2017-09-11  Martin Liska  
>>
>> PR testsuite/82114
>> * gcc.dg/gimplefe-14.c (main): Add handling of case 0.
>> ---
>>  gcc/testsuite/gcc.dg/gimplefe-14.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>

Re: Add support to trace comparison instructions and switch statements

[Dmitry Vyukov via gcc-patches]

On Thu, Sep 7, 2017 at 9:02 AM, 吴潍浠(此彼)  wrote:
> Hi
> The trace-div and trace-gep options seems be used to evaluate corpus
> to trigger specific kind of bugs. And they don't have strong effect to 
> coverage.
>
> The trace-pc-guard is useful, but it may be much more complex than trace-pc.
> I think the best benefit of trace-pc-guard is avoiding dealing ASLR of 
> programs,
> especially programs with dlopen(). Seems hard to implement it in Linux kernel.
>
> The inline-8bit-counters and pc-table is too close to implementation of fuzz 
> tool and
> option trace-pc-guard .
>
> I am interesting in "stack-depth" and "func". If we trace user-defined 
> functions enter and exit,
> we can calculate stack-depth and difference level of stack to past existed 
> stack.
> Adding __sanitizer_cov_trace_pc_{enter,exit} is easy , but it is not standard 
> of llvm.
>
> How do you think Dmitry ?
>
> Wish Wu
>
> --
> From:Jakub Jelinek 
> Time:2017 Sep 6 (Wed) 22:37
> To:Wish Wu 
> Cc:Dmitry Vyukov ; gcc-patches ; 
> Jeff Law ; wishwu007 
> Subject:Re: Add support to trace comparison instructions and switch statements
>
>
> On Wed, Sep 06, 2017 at 07:47:29PM +0800, 吴潍浠(此彼) wrote:
>> Hi Jakub
>> I compiled libjpeg-turbo and libdng_sdk with options "-g -O3 -Wall 
>> -fsanitize-coverage=trace-pc,trace-cmp -fsanitize=address".
>> And run my fuzzer with pc and cmp feedbacks for hours. It works fine.
>> About __sanitizer_cov_trace_cmp{f,d} , yes, it  isn't provided by llvm. But 
>> once we trace integer comparisons, why not real type comparisons.
>> I remember Dmitry said it is not enough useful to trace real type 
>> comparisons because it is rare to see them in programs.
>> But libdng_sdk really has real type comparisons. So I want to keep them and 
>> implementing __sanitizer_cov_trace_const_cmp{f,d} may be necessary.
>
> Ok.  Please make sure those entrypoints make it into the various example
> __sanitier_cov_trace* fuzzer implementations though, so that people using
> -fsanitize-coverage=trace-cmp in GCC will not need to hack stuff themselves.
> At least it should be added to sanitizer_common (both in LLVM and GCC).
>
> BTW, https://clang.llvm.org/docs/SanitizerCoverage.html shows various other
> -fsanitize-coverage= options, some of them terribly misnamed (e.g. trace-gep
> using some weirdo LLVM IL acronym instead of being named by what it really
> traces (trace-array-idx or something similar)).
>
> Any plans to implement some or all of those?


Thanks, Jakub!

I've tested it on Linux kernel. Compiler does not crash, code is instrumented.

Re  terribly misnamed trace-gep, dunno, I will leave this to Kostya.

Re __sanitizer_cov_trace_cmp{f,d}, I am still not sure.

> But libdng_sdk really has real type comparisons.

Do they come from input data? In what format? How do you want to use
them? E.g. if they come from input but with using some non-trivial
transformation and the fuzzer will try to find them in the input, it
won't be able to do so.
On the other hand, it does not seem to be harmful, fuzzers that are
not interested in them can just add empty callbacks.

Re trace-pc-guard, I also don't have strong preference. Global
variables should work for kernel, but we probably will not use them in
kernel, because even aslr aside we would need to establish some global
numbering of these globals across multiple different machines. But
then it's much easier and simper to just use PCs as identifiers.

Re __sanitizer_cov_trace_pc_{enter,exit}, I don't think we ever
experimented/evaluated this idea. Do you have any data that it's
useful? I suspect that it can grow corpus too much.

[PATCH] move sorted field handling to C FE

[Nathan Sidwell]

Now that I've excised sorted fields from the C++ FE (as a distinct 
concept), we can move some helper functions from c-family/ to c/


this patch does exactly that.  Applied to trunk.


nathan
--
Nathan Sidwell
2017-09-12  Nathan Sidwell  

	c-family/
	* c-common.c (field_decl_cmp, resort_data, resort_field_decl_cmp,
	resort_sorted_fields): Move to c/c-decl.c.
	* c-common.h (field_decl_cmp, resort_sorted_fields): Delete.
	(struct sorted_fields_type): Move to c/c-lang.h.

	c/
	* c-decl.c (field_decl_cmp, resort_data, resort_field_decl_cmp,
	resort_sorted_fields): Moved from c-family/c-common.c.
	* c-lang.h (struct sorted_fields_type): Moved from c-family/c-common.h.

Index: c/c-decl.c
===
--- c/c-decl.c	(revision 252007)
+++ c/c-decl.c	(working copy)
@@ -7840,6 +7840,26 @@ warn_cxx_compat_finish_struct (tree fiel
 b->in_struct = 0;
 }
 
+/* Function to help qsort sort FIELD_DECLs by name order.  */
+
+static int
+field_decl_cmp (const void *x_p, const void *y_p)
+{
+  const tree *const x = (const tree *) x_p;
+  const tree *const y = (const tree *) y_p;
+
+  if (DECL_NAME (*x) == DECL_NAME (*y))
+/* A nontype is "greater" than a type.  */
+return (TREE_CODE (*y) == TYPE_DECL) - (TREE_CODE (*x) == TYPE_DECL);
+  if (DECL_NAME (*x) == NULL_TREE)
+return -1;
+  if (DECL_NAME (*y) == NULL_TREE)
+return 1;
+  if (DECL_NAME (*x) < DECL_NAME (*y))
+return -1;
+  return 1;
+}
+
 /* Fill in the fields of a RECORD_TYPE or UNION_TYPE node, T.
LOC is the location of the RECORD_TYPE or UNION_TYPE's definition.
FIELDLIST is a chain of FIELD_DECL nodes for the fields.
@@ -8165,6 +8185,53 @@ finish_struct (location_t loc, tree t, t
   return t;
 }
 
+static struct {
+  gt_pointer_operator new_value;
+  void *cookie;
+} resort_data;
+
+/* This routine compares two fields like field_decl_cmp but using the
+pointer operator in resort_data.  */
+
+static int
+resort_field_decl_cmp (const void *x_p, const void *y_p)
+{
+  const tree *const x = (const tree *) x_p;
+  const tree *const y = (const tree *) y_p;
+
+  if (DECL_NAME (*x) == DECL_NAME (*y))
+/* A nontype is "greater" than a type.  */
+return (TREE_CODE (*y) == TYPE_DECL) - (TREE_CODE (*x) == TYPE_DECL);
+  if (DECL_NAME (*x) == NULL_TREE)
+return -1;
+  if (DECL_NAME (*y) == NULL_TREE)
+return 1;
+  {
+tree d1 = DECL_NAME (*x);
+tree d2 = DECL_NAME (*y);
+resort_data.new_value (, resort_data.cookie);
+resort_data.new_value (, resort_data.cookie);
+if (d1 < d2)
+  return -1;
+  }
+  return 1;
+}
+
+/* Resort DECL_SORTED_FIELDS because pointers have been reordered.  */
+
+void
+resort_sorted_fields (void *obj,
+		  void * ARG_UNUSED (orig_obj),
+		  gt_pointer_operator new_value,
+		  void *cookie)
+{
+  struct sorted_fields_type *sf = (struct sorted_fields_type *) obj;
+  resort_data.new_value = new_value;
+  resort_data.cookie = cookie;
+  qsort (>elts[0], sf->len, sizeof (tree),
+	 resort_field_decl_cmp);
+}
+
 /* Lay out the type T, and its element type, and so on.  */
 
 static void
Index: c/c-lang.h
===
--- c/c-lang.h	(revision 252007)
+++ c/c-lang.h	(working copy)
@@ -22,6 +22,13 @@ along with GCC; see the file COPYING3.
 
 #include "c-family/c-common.h"
 
+/* In a RECORD_TYPE, a sorted array of the fields of the type, not a
+   tree for size reasons.  */
+struct GTY(()) sorted_fields_type {
+  int len;
+  tree GTY((length ("%h.len"))) elts[1];
+};
+
 struct GTY(()) lang_type {
   /* In a RECORD_TYPE, a sorted array of the fields of the type.  */
   struct sorted_fields_type * GTY ((reorder ("resort_sorted_fields"))) s;
Index: c-family/c-common.c
===
--- c-family/c-common.c	(revision 252007)
+++ c-family/c-common.c	(working copy)
@@ -309,7 +309,6 @@ static bool check_case_bounds (location_
 
 static void check_nonnull_arg (void *, tree, unsigned HOST_WIDE_INT);
 static bool nonnull_check_p (tree, unsigned HOST_WIDE_INT);
-static int resort_field_decl_cmp (const void *, const void *);
 
 /* Reserved words.  The third field is a mask: keywords are disabled
if they match the mask.
@@ -5871,73 +5870,6 @@ check_builtin_function_arguments (locati
 }
 }
 
-/* Function to help qsort sort FIELD_DECLs by name order.  */
-
-int
-field_decl_cmp (const void *x_p, const void *y_p)
-{
-  const tree *const x = (const tree *) x_p;
-  const tree *const y = (const tree *) y_p;
-
-  if (DECL_NAME (*x) == DECL_NAME (*y))
-/* A nontype is "greater" than a type.  */
-return (TREE_CODE (*y) == TYPE_DECL) - (TREE_CODE (*x) == TYPE_DECL);
-  if (DECL_NAME (*x) == NULL_TREE)
-return -1;
-  if (DECL_NAME (*y) == NULL_TREE)
-return 1;
-  if (DECL_NAME (*x) < DECL_NAME (*y))
-return -1;
-  return 1;
-}
-
-static struct {
-  gt_pointer_operator new_value;
-  void *cookie;
-} 

Re: [RFC][PATCH] Do refactoring of attribute functions and move them to attribs.[hc].

[Martin Liška]

On 09/12/2017 01:39 PM, Jakub Jelinek wrote:
> On Tue, Sep 12, 2017 at 01:31:47PM +0200, Martin Liška wrote:
>> >From a40c06fc06afcb7bb886d7a3106e6da631a48430 Mon Sep 17 00:00:00 2001
>> From: marxin 
>> Date: Tue, 12 Sep 2017 13:30:39 +0200
>> Subject: [PATCH] Reduce lookup_attribute memory footprint.
>>
>> gcc/ChangeLog:
>>
>> 2017-09-12  Martin Liska  
>>
>>  * attribs.c (private_lookup_attribute): New function.
>>  * attribs.h (private_lookup_attribute): Declared here.
>>  (lookup_attribute): Called from this place.
>> ---
>>  gcc/attribs.c | 17 +
>>  gcc/attribs.h | 17 ++---
>>  2 files changed, 23 insertions(+), 11 deletions(-)
>>
>> diff --git a/gcc/attribs.c b/gcc/attribs.c
>> index b8f58a74596..9064434e5f2 100644
>> --- a/gcc/attribs.c
>> +++ b/gcc/attribs.c
>> @@ -1584,3 +1584,20 @@ attribute_list_contained (const_tree l1, const_tree 
>> l2)
>>  
>>return 1;
>>  }
>> +
>> +
> 
> Can you please add a function comment (and in addition to arguments explain
> there why lookup_attribute is split into the two parts)?

Yes.

> 
>> +tree
>> +private_lookup_attribute (const char *attr_name, size_t attr_len, tree list)
>> +{
>> +  while (list)
>> +{
> 
>> @@ -151,17 +156,7 @@ lookup_attribute (const char *attr_name, tree list)
>>/* Do the strlen() before calling the out-of-line implementation.
>>   In most cases attr_name is a string constant, and the compiler
>>   will optimize the strlen() away.  */
> 
> Part of the comment is of course here and that comment didn't make any sense
> when everything was inlined.

You're completely right.

> 
>> -  while (list)
>> -{
>> -  tree attr = get_attribute_name (list);
>> -  size_t ident_len = IDENTIFIER_LENGTH (attr);
>> -  if (cmp_attribs (attr_name, attr_len, IDENTIFIER_POINTER (attr),
>> -   ident_len))
>> -break;
>> -  list = TREE_CHAIN (list);
>> -}
>> -
>> -  return list;
>> +  return private_lookup_attribute (attr_name, attr_len, list);
>>  }
>>  }
> 
> LGTM with the comment added.  In theory fnsplit could handle that too,
> but 1) it would emit out of line stuff in every TU separately 2) the
> compiler doesn't know that NULL DECL_ATTRIBUTES is so common (it could
> with profiledbootstrap).  And of course LTO can decide to inline it
> from attribs.c back anyway if there are reasons why it would be beneficial
> somewhere (but I doubt it is beneficial at least in most spots).

Doing it as it was is the right way ;)
Installed as r252022.

Martin

> 
>   Jakub
> 

[PATCH] Fix powerpc ICE with __builtin_vec_ld on an array (PR target/82112, take 2)

[Jakub Jelinek]

Hi!

On Thu, Sep 07, 2017 at 10:40:30AM +0200, Jakub Jelinek wrote:
> The C and C++ FE handle resolve_overloaded_builtin differently, the C FE
> calls it when e.g. array-to-pointer and function-to-pointer conversions
> are already done on the arguments, while C++ FE does that only much later.
> The c-common code e.g. for __sync/__atomic builtins deals with
> that e.g. by:
>   if (TREE_CODE (type) == ARRAY_TYPE)
> {
>   /* Force array-to-pointer decay for C++.  */
>   gcc_assert (c_dialect_cxx());
>   (*params)[0] = default_conversion ((*params)[0]);
>   type = TREE_TYPE ((*params)[0]);
> }
> while the rs6000 md hook uses default_conversion only in one spot (the
> generic handling), but for vec_ld and vec_st does something on its own.
> What is even worse is that for vec_ld, it does that too late, there is
> a fold_convert in between for the case where the element type is
> qualified, and that only works if the argument is pointer, not array
> (in which case it ICEs).
> So, the following patch moves the vec_ld conversion earlier and for both
> vec_ld and vec_st uses what c-common as well as later
> altivec_resolve_overloaded_builtin uses.
> 
> Bootstrapped/regtested on powerpc64-linux (regtest with {,-m32}), ok for
> trunk?

Here is an updated version of that patch, fixed for the C90 non-lvalue
arrays (which we want to reject as c-family rejects them for __atomic_*
etc.).  Bootstrapped/regtested on powerpc64-linux (regtest with {,-m32}), ok for
trunk?

2017-09-12  Jakub Jelinek  

PR target/82112
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): For
ALTIVEC_BUILTIN_VEC_LD if arg1 has array type call default_conversion
on it early, rather than manual conversion late.  For
ALTIVEC_BUILTIN_VEC_ST if arg2 has array type call default_conversion
instead of performing manual conversion.

* gcc.target/powerpc/pr82112.c: New test.
* g++.dg/ext/altivec-18.C: New test.

--- gcc/config/rs6000/rs6000-c.c.jj 2017-09-08 09:13:59.863591547 +0200
+++ gcc/config/rs6000/rs6000-c.c2017-09-08 09:16:36.354738183 +0200
@@ -6480,7 +6480,13 @@ altivec_resolve_overloaded_builtin (loca
 
   /* Strip qualifiers like "const" from the pointer arg.  */
   tree arg1_type = TREE_TYPE (arg1);
-  if (!POINTER_TYPE_P (arg1_type) && TREE_CODE (arg1_type) != ARRAY_TYPE)
+  if (TREE_CODE (arg1_type) == ARRAY_TYPE && c_dialect_cxx ())
+   {
+ /* Force array-to-pointer decay for C++.  */
+ arg1 = default_conversion (arg1);
+ arg1_type = TREE_TYPE (arg1);
+   }
+  if (!POINTER_TYPE_P (arg1_type))
goto bad;
 
   tree inner_type = TREE_TYPE (arg1_type);
@@ -6500,15 +6506,6 @@ altivec_resolve_overloaded_builtin (loca
  if (!ptrofftype_p (TREE_TYPE (arg0)))
arg0 = build1 (NOP_EXPR, sizetype, arg0);
 
- tree arg1_type = TREE_TYPE (arg1);
- if (TREE_CODE (arg1_type) == ARRAY_TYPE)
-   {
- arg1_type = TYPE_POINTER_TO (TREE_TYPE (arg1_type));
- tree const0 = build_int_cstu (sizetype, 0);
- tree arg1_elt0 = build_array_ref (loc, arg1, const0);
- arg1 = build1 (ADDR_EXPR, arg1_type, arg1_elt0);
-   }
-
  tree addr = fold_build2_loc (loc, POINTER_PLUS_EXPR, arg1_type,
   arg1, arg0);
  tree aligned = fold_build2_loc (loc, BIT_AND_EXPR, arg1_type, addr,
@@ -6563,12 +6560,11 @@ altivec_resolve_overloaded_builtin (loca
arg1 = build1 (NOP_EXPR, sizetype, arg1);
 
  tree arg2_type = TREE_TYPE (arg2);
- if (TREE_CODE (arg2_type) == ARRAY_TYPE)
+ if (TREE_CODE (arg2_type) == ARRAY_TYPE && c_dialect_cxx ())
{
- arg2_type = TYPE_POINTER_TO (TREE_TYPE (arg2_type));
- tree const0 = build_int_cstu (sizetype, 0);
- tree arg2_elt0 = build_array_ref (loc, arg2, const0);
- arg2 = build1 (ADDR_EXPR, arg2_type, arg2_elt0);
+ /* Force array-to-pointer decay for C++.  */
+ arg2 = default_conversion (arg2);
+ arg2_type = TREE_TYPE (arg2);
}
 
  /* Find the built-in to make sure a compatible one exists; if not
--- gcc/testsuite/gcc.target/powerpc/pr82112.c.jj   2017-09-08 
09:20:35.187912843 +0200
+++ gcc/testsuite/gcc.target/powerpc/pr82112.c  2017-09-08 09:24:21.362376676 
+0200
@@ -0,0 +1,16 @@
+/* PR target/82112 */
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -std=gnu90" } */
+
+#include 
+
+struct __attribute__((aligned (16))) S { unsigned char c[64]; } bar (void);
+vector unsigned char v;
+
+void
+foo (void)
+{
+  vec_ld (0, bar ().c);/* { dg-error "invalid parameter combination 
for AltiVec intrinsic" } */
+  vec_st (v, 0, bar ().c); /* { dg-error "invalid parameter combination 
for AltiVec 

Re: C++ PATCH to reduced_constant_expression for partially-initialized objects

[Andrew Pinski]

On Tue, Sep 12, 2017 at 7:17 AM, Christophe Lyon
 wrote:
> Hi Jason
>
> On 10 September 2017 at 11:09, Jason Merrill  wrote:
>> A few months back I queued this patch to bring back for GCC 8.
>> Unfortunately I don't remember the context that it came up in, but it
>> affects for instance cases of self-assignment, which can't have a
>> constant value if there is no previous initialization.
>>
>> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> I've noticed that this patch causes a regression in fortran on
> armeb-linux-gnumeabihf
> FAIL:gfortran.dg/allocate_zerosize_3.f   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution
> test
> FAIL:gfortran.dg/allocate_zerosize_3.f   -O3 -g  execution test
> FAIL:gfortran.dg/assumed_rank_1.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution
> test
> FAIL:gfortran.dg/assumed_rank_1.f90   -O3 -g  execution test
> FAIL:gfortran.dg/assumed_rank_2.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution
> test
> FAIL:gfortran.dg/assumed_rank_2.f90   -O3 -g  execution test
>
> target armeb-none-linux-gnueabihf
> --with-mode arm
> --with-cpu cortex-a9
> --with-fpu neon-fp16
>
> using --with-fpu vfpv3-d16-fp16 does not introduce the regression.
>
> target arm-none-linux-gnueabihf with the same parameters is OK ('arm'
> as opposed to 'armeb')
>
> My gfortran.log only shows:
> spawn [open ...]
> Program aborted. Backtrace:
> qemu: uncaught target signal 6 (Aborted) - core dumped

This makes little sense.  Are you compiling the cross compiler with
the new native compiler?  Since this patch only touches the C++
front-end and only C++11 even that makes less sense.  Are you sure
this was not a bug in qemu which is just happening showing up now?
Even then this makes little sense as the code generation between the
two revisions should not touch anything related to fortran.

Thanks,
Andrew Pinski

>
> Christophe

Re: C++ PATCH to reduced_constant_expression for partially-initialized objects

[Christophe Lyon]

Hi Jason

On 10 September 2017 at 11:09, Jason Merrill  wrote:
> A few months back I queued this patch to bring back for GCC 8.
> Unfortunately I don't remember the context that it came up in, but it
> affects for instance cases of self-assignment, which can't have a
> constant value if there is no previous initialization.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.

I've noticed that this patch causes a regression in fortran on
armeb-linux-gnumeabihf
FAIL:gfortran.dg/allocate_zerosize_3.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution
test
FAIL:gfortran.dg/allocate_zerosize_3.f   -O3 -g  execution test
FAIL:gfortran.dg/assumed_rank_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution
test
FAIL:gfortran.dg/assumed_rank_1.f90   -O3 -g  execution test
FAIL:gfortran.dg/assumed_rank_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution
test
FAIL:gfortran.dg/assumed_rank_2.f90   -O3 -g  execution test

target armeb-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16

using --with-fpu vfpv3-d16-fp16 does not introduce the regression.

target arm-none-linux-gnueabihf with the same parameters is OK ('arm'
as opposed to 'armeb')

My gfortran.log only shows:
spawn [open ...]
Program aborted. Backtrace:
qemu: uncaught target signal 6 (Aborted) - core dumped

Christophe

Re: [PATCH] Fix PR82129

[Jakub Jelinek]

On Tue, Sep 12, 2017 at 04:09:41PM +0200, Richard Biener wrote:
> 
> The following "fixes" PR82129 (hides the issue).  It folds
> writes from uninitialized data to CLOBBERs:
> 
> -  *h5_26(D) = tv_24(D);
> +  *h5_26(D) ={v} {CLOBBER};
> 
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Won't that affect -W{,maybe-}unitialized a lot?

> 2017-09-12  Richard Biener  
> 
>   PR tree-optimization/82129
>   * gimple-fold.c (fold_gimple_assign): Fold stores from undefined
>   values to clobbers.
> 
>   * gcc.dg/torture/pr82129.c: New testcase.

Jakub

[PATCH] Fix PR82129

[Richard Biener]

The following "fixes" PR82129 (hides the issue).  It folds
writes from uninitialized data to CLOBBERs:

-  *h5_26(D) = tv_24(D);
+  *h5_26(D) ={v} {CLOBBER};

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Richard.

2017-09-12  Richard Biener  

PR tree-optimization/82129
* gimple-fold.c (fold_gimple_assign): Fold stores from undefined
values to clobbers.

* gcc.dg/torture/pr82129.c: New testcase.

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 252002)
+++ gcc/gimple-fold.c   (working copy)
@@ -410,6 +410,20 @@ fold_gimple_assign (gimple_stmt_iterator
 
else if (DECL_P (rhs))
  return get_symbol_constant_value (rhs);
+
+   else if (TREE_CODE (rhs) == SSA_NAME
+&& SSA_NAME_IS_DEFAULT_DEF (rhs)
+&& ! ssa_defined_default_def_p (rhs)
+&& gimple_store_p (stmt)
+&& ! gimple_has_volatile_ops (stmt))
+ {
+   /* Replace a store from an undefined value with a clobber
+  which will not generate code, thus avoid doing this when
+  the store is volatile.  */
+   tree clobber = build_constructor (TREE_TYPE (rhs), NULL);
+   TREE_THIS_VOLATILE (clobber) = true;
+   return clobber;
+ }
   }
   break;
 
Index: gcc/testsuite/gcc.dg/torture/pr82129.c
===
--- gcc/testsuite/gcc.dg/torture/pr82129.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr82129.c  (working copy)
@@ -0,0 +1,51 @@
+/* { dg-do compile } */
+
+int pj;
+
+void
+g4 (unsigned long int *bc, unsigned long int *h5)
+{
+  if (pj != 0)
+{
+  int ib = 0;
+
+  while (bc != 0)
+   {
+m6:
+ for (pj = 0; pj < 2; ++pj)
+   pj = 0;
+
+ while (pj != 0)
+   {
+ for (;;)
+   {
+   }
+
+ while (ib != 0)
+   {
+ unsigned long int tv = *bc;
+ unsigned long int n7;
+
+ *bc = 1;
+ while (*bc != 0)
+   {
+   }
+
+ut:
+ if (pj == 0)
+   n7 = *h5 > 0;
+ else
+   {
+ *h5 = tv;
+ n7 = *h5;
+   }
+ ib += n7;
+   }
+   }
+   }
+
+  goto ut;
+}
+
+  goto m6;
+}

Re: [PATCH] PR libstdc++/79433 no #error for including headers with wrong -std

[Jonathan Wakely]

On 07/09/17 15:18 +0100, Jonathan Wakely wrote:

As discussed in PR 79433, the recommended way to test for new features
such as std::optional has problems. The current version of SD-6 at
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
says to simply check __has_include(optional). This test will be true
even when using -std=c++98, but actually including the header gives an
error. This works OK for ahead-of-time autoconf-style checks, but not
for preprocessor-based checks directly in the source code.

The latest draft of SD-6 (to be published soon) changes the
recommendation to use __has_include, then include the header and also
check for a feature-test macro e.g.

#ifdef __has_include
# if __has_include(optional)
#  include 
#  if __cpp_lib_optional >= 201606
#   define HAVE_STD_OPTIONAL
#  endif
# endif
#endif

For this to work we need to make including  always valid
(even in C++{98,03,11,14} modes) instead of failing with #error. When
included pre-C++17 the header should be empty, and specifically not
define the __cpp_lib_optional macro.

This implements that change. The  header is also
affected for C++14, as that defines std::shared_timed_mutex in C++14
mode, and adds std::shared_mutex in C++17 mode.

With this change nothing else includes c++17_warning.h so we can
remove it.


I've committed that change to trunk now.


In a follow-up patch I plan to do the same for the 
headers. The TS documents already give a macro for every header, and
LibFundTS suggests testing both __has_include and a macro, see ¶3 at
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#general.feature.test


And here's the follow-up for the TS headers, also committed to trunk.


commit 5563d1e2214a32e3fe07a56fa49ad5a75b20c8ba
Author: Jonathan Wakely 
Date:   Thu Sep 7 18:20:25 2017 +0100

PR libstdc++/79433 no #error for including TS headers with wrong -std

PR libstdc++/79433
* include/Makefile.am: Remove .
* include/Makefile.in: Regenerate.
* include/bits/c++14_warning.h: Remove.
* include/experimental/algorithm: Do not include .
* include/experimental/any: Likewise.
* include/experimental/array: Likewise.
* include/experimental/bits/erase_if.h: Likewise.
* include/experimental/bits/lfts_config.h: Likewise.
* include/experimental/bits/shared_ptr.h: Likewise.
* include/experimental/bits/string_view.tcc: Likewise.
* include/experimental/chrono: Likewise.
* include/experimental/deque: Likewise.
* include/experimental/filesystem: Do not include .
* include/experimental/forward_list: Do not include .
* include/experimental/functional: Likewise.
* include/experimental/iterator: Likewise.
* include/experimental/list: Likewise.
* include/experimental/map: Likewise.
* include/experimental/memory: Likewise.
* include/experimental/numeric: Likewise.
* include/experimental/optional: Likewise.
* include/experimental/propagate_const: Likewise.
* include/experimental/ratio: Likewise.
* include/experimental/regex: Likewise.
* include/experimental/set: Likewise.
* include/experimental/string: Likewise.
* include/experimental/string_view: Likewise.
* include/experimental/system_error: Likewise.
* include/experimental/tuple: Likewise.
* include/experimental/type_traits: Likewise.
* include/experimental/unordered_map: Likewise.
* include/experimental/unordered_set: Likewise.
* include/experimental/vector: Likewise.
* testsuite/experimental/any/misc/any_cast_neg.cc: Adjust dg-error
line number.
* testsuite/experimental/array/neg.cc: Likewise.
* testsuite/experimental/propagate_const/assignment/move_neg.cc:
Likewise.
* testsuite/experimental/propagate_const/cons/move_neg.cc: Likewise.
* testsuite/experimental/propagate_const/requirements2.cc: Likewise.
* testsuite/experimental/propagate_const/requirements3.cc: Likewise.
* testsuite/experimental/propagate_const/requirements4.cc: Likewise.
* testsuite/experimental/propagate_const/requirements5.cc: Likewise.

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 6395f1e6ae0..87a41f59027 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -95,7 +95,6 @@ bits_headers = \
 	${bits_srcdir}/basic_string.tcc \
 	${bits_srcdir}/boost_concept_check.h \
 	${bits_srcdir}/c++0x_warning.h \
-	${bits_srcdir}/c++14_warning.h \
 	${bits_srcdir}/char_traits.h \
 	${bits_srcdir}/codecvt.h \
 	

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

[Ian Lance Taylor via gcc-patches]

On Mon, Sep 11, 2017 at 3:06 AM, Denis Khalikov
 wrote:
> Thanks for answer.
> I understood all points which you mentioned, but can't
> find last one
>> It seems to work
>> out the file name a second time, even though the file name must
>> already be known.
>
> Can you please show me where I've missed that, if you have a time for that.

It's quite possible that I misunderstand the patch.  I was looking at
the call to a copy of get_exec_filename in fileline_initialize.

> Anyway, your patch works for me.

Thanks for testing.  I will commit it later, probably today.

Ian


> On 09/11/2017 12:11 AM, Ian Lance Taylor wrote:
>>
>> On Sat, Jul 29, 2017 at 1:42 PM, Denis Khalikov
>>  wrote:
>>>
>>>
>>> Hello Ian,
>>> thanks for review.
>>> I've updated the patch, can you please take a look.
>>
>>
>> Apologies again for the length of time it took to reply.  I've had a
>> hard time understanding the patch.  It's quite likely that I don't
>> understand how it works, but it seems to pass the same file descriptor
>> to process_elf_header twice.  It seems to look for debug files with
>> the buildid in places where they will not be found.  It seems to work
>> out the file name a second time, even though the file name must
>> already be known.  I eventually just wrote my own implementation.
>>
>> Could you try this patch and see if it works for your cases?  The
>> patch is against current mainline.  Thanks.
>>
>> Ian
>>
>

[PATCH] Fix PR82128

[Richard Biener]

This is the one with the folding fix...

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2017-09-12  Richard Biener  

PR middle-end/82128
* gimple-fold.c (gimple_fold_call): Update iterator properly.

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 252002)
+++ gcc/gimple-fold.c   (working copy)
@@ -3872,7 +3872,7 @@ gimple_fold_call (gimple_stmt_iterator *
 we need to preserve GIMPLE_CALL statement
 at position of GSI iterator.  */
  update_call_from_tree (gsi, def);
- gsi_insert_before (gsi, new_stmt, GSI_NEW_STMT);
+ gsi_insert_before (gsi, new_stmt, GSI_SAME_STMT);
}
  else
{

[PATCH] Fix PR82157

[Richard Biener]

The following fixes a latent issue in fold_stmt uncovered by
PRE re-org.  We muck with the gsi in inapprorpate ways.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2017-09-12  Richard Biener  

PR tree-optimization/82157
* tree-ssa-pre.c (remove_dead_inserted_code): Do not remove
stmts with side-effects.

* gcc.dg/torture/pr82157.c: New testcase.

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 252002)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -4913,6 +4964,8 @@ remove_dead_inserted_code (void)
continue;
 
   gimple *t = SSA_NAME_DEF_STMT (def);
+  if (gimple_has_side_effects (t))
+   continue;
 
   /* Add uses to the worklist.  */
   ssa_op_iter iter;
Index: gcc/testsuite/gcc.dg/torture/pr82157.c
===
--- gcc/testsuite/gcc.dg/torture/pr82157.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr82157.c  (working copy)
@@ -0,0 +1,43 @@
+/* { dg-do compile } */
+
+int a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, 
z;
+
+int aa ()
+{ 
+  w = f < 0 || e >> f;
+  while (z)
+h = i && (r && p) | ((l = p) == c % d);
+  k = v + 1 < a;
+  t = -(j < 1) * q;
+  return u;
+}
+
+int ab ()
+{ 
+  for (j = 0; 1; j = 5)
+if (!s)
+  return d;
+}
+
+void ac ()
+{ 
+  char ad = aa ();
+  ab ();
+  if (x)
+{ 
+  for (m = 0; m < 3; m = a)
+   { 
+ y = a && b;
+ if (g)
+   break;
+   }
+  n = j;
+}
+  o = j & ad;
+}
+
+int main ()
+{ 
+  ac ();
+  return 0;
+}

[PATCH] Fix PR82144

[Richard Biener]

The following avoids adding DW_AT_alignment twice by not doing it
for incomplete types.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Alex, is that ok or do we want DW_AT_alignment for incomplete types as 
well?

Thanks,
Richard.

2017-09-12  Richard Biener  

PR middle-end/82144
* dwarf2out.c (gen_enumeration_type_die): Do not add alignment
attribute for incomplete types nor twice for complete ones.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 252002)
+++ gcc/dwarf2out.c (working copy)
@@ -21258,8 +21258,6 @@ gen_enumeration_type_die (tree type, dw_
   else
 add_AT_flag (type_die, DW_AT_declaration, 1);
 
-  add_alignment_attribute (type_die, type);
-
   add_pubtype (type, type_die);
 
   return type_die;

Re: [PATCH] PR libstdc++/70483 make std::string_view fully constexpr

[Jonathan Wakely]

On 11/09/17 22:48 +0100, Jonathan Wakely wrote:

This adds 'constexpr' everywhere it's missing from
std::basic_string_view.


And this does it for std::experimental::basic_string_view, fixing the
bug as reported.

Tested powerpc64le-linux, committed to trunk.



commit d1cb3e5ac0bf7b07a06d4b8bbdd4f6752be112ae
Author: Jonathan Wakely 
Date:   Tue Sep 12 10:44:38 2017 +0100

PR libstdc++/70483 make std::experimental::string_view fully constexpr

PR libstdc++/70483
* include/experimental/bits/string_view.tcc (basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of): Add constexpr specifier.
* include/experimental/string_view (basic_string_view::remove_prefix)
(basic_string_view::remove_suffix, basic_string_view::swap)
(basic_string_view::compare, basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of, operator==, operator!=)
(operator<, operator>, operator<=, operator>=): Likewise.
* testsuite/experimental/string_view/operations/compare/char/70483.cc:
New.

diff --git a/libstdc++-v3/include/experimental/bits/string_view.tcc b/libstdc++-v3/include/experimental/bits/string_view.tcc
index e66932d1ac0..450a43c7876 100644
--- a/libstdc++-v3/include/experimental/bits/string_view.tcc
+++ b/libstdc++-v3/include/experimental/bits/string_view.tcc
@@ -49,7 +49,7 @@ namespace experimental
 inline namespace fundamentals_v1
 {
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 find(const _CharT* __str, size_type __pos, size_type __n) const noexcept
 {
@@ -70,7 +70,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 find(_CharT __c, size_type __pos) const noexcept
 {
@@ -86,7 +86,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 rfind(const _CharT* __str, size_type __pos, size_type __n) const noexcept
 {
@@ -106,7 +106,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 rfind(_CharT __c, size_type __pos) const noexcept
 {
@@ -123,7 +123,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 find_first_of(const _CharT* __str, size_type __pos, size_type __n) const
 {
@@ -139,7 +139,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 find_last_of(const _CharT* __str, size_type __pos, size_type __n) const
 {
@@ -160,7 +160,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 find_first_not_of(const _CharT* __str, size_type __pos, size_type __n) const
 {
@@ -172,7 +172,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 find_first_not_of(_CharT __c, size_type __pos) const noexcept
 {
@@ -183,7 +183,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 find_last_not_of(const _CharT* __str, size_type __pos, size_type __n) const
 {
@@ -204,7 +204,7 @@ inline namespace fundamentals_v1
 }
 
   template
-typename basic_string_view<_CharT, _Traits>::size_type
+constexpr typename basic_string_view<_CharT, _Traits>::size_type
 basic_string_view<_CharT, _Traits>::
 find_last_not_of(_CharT __c, size_type __pos) const noexcept
 {
diff 

[PATCH] Fix typo in recent match.pd pattern

[Richard Biener]

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

Richard.

2017-09-12  Richard Biener  

PR middle-end/82149
* match.pd ((FTYPE) N CMP CST): Fix typo.

Index: gcc/match.pd
===
--- gcc/match.pd(revision 252002)
+++ gcc/match.pd(working copy)
@@ -2916,7 +2916,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  -fno-signaling-nans.  */
bool exception_p
  = real_isnan (cst) && (cst->signalling
-   || (cmp != EQ_EXPR || cmp != NE_EXPR));
+   || (cmp != EQ_EXPR && cmp != NE_EXPR));
/* INT?_MIN is power-of-two so it takes
  only one mantissa bit.  */
bool signed_p = isign == SIGNED;

[gotools] Fix some gotools testing problems

[Rainer Orth]

A couple of gotools test FAIL on Solaris, and there are several issues
that make investigation particularly tedious.

* The one invocation of gotest doesn't support passing additional flags
  (--keep in particular).  Added below.

* The order of some of the summaries isn't stable (cmd/go and runtime,
  while cgo and carchive are, it seems).  I'm now sorting the output by
  test name, both for make check output and the creation of gotools.sum.

  Otherwise, it's hard to compare mail-report.log between builds.

* The freshly built go, cgo, and gofmt rely on LD_LIBRARY_PATH to be set
  so libgcc.so is found at runtime.  The right value is passed in from
  the toplevel during a bootstrap, but missing when I run make check in
  gotools manually.

* The most glaring problem is getting your hands on the failing
  executables: there are several levels of indirection here

  make -> gotest ... -> go build -> gccgo -> a.out
   -> go test
   
  Many of those steps also depend on lots of environment variables set
  to the check-gcc or check-gccgo wrapper scripts and it's hard to
  determine what's necessary to be able to lay my hand on the resulting
  executable to run it under gdb.  I've found no way to pass e.g. -work
  to go build from the outside (e.g. via an environment variable), nor
  can I see the commands executed, so this means modifying the test
  sources or run the full testsuite under truss in the hope to determine
  all that's necessary to reproduce the build.

Anyway, here's the trivial part so far.  Ok for mainline?

Rainer

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


2017-09-12  Rainer Orth  

* Makefile.am (GOTESTFLAGS): New variable.
(check-runtime): Pass it to gotest.
(check-go-tools): Sort summary.
(check-runtime): Likewise.
(check-cgo-test): Likewise.
(check-carchive-test): Likewise.
(check): Likewise.
* Makefile.in: Regenerate.

# HG changeset patch
# Parent  6cf2b85bf501a5d54f0e0558b078b90b6d6ea0dc
Fix some gotools testing problems

diff --git a/gotools/Makefile.am b/gotools/Makefile.am
--- a/gotools/Makefile.am
+++ b/gotools/Makefile.am
@@ -139,6 +139,8 @@ install-exec-local: cgo$(EXEEXT)
 uninstall-local:
 	rm -f $(DESTDIR)$(libexecsubdir)/cgo$(exeext)
 
+GOTESTFLAGS =
+
 # Run tests using the go tool, and frob the output to look like that
 # generated by DejaGNU.  The main output of this is two files:
 # gotools.sum and gotools.log.
@@ -211,7 +213,7 @@ check-go-tool: go$(EXEEXT) cgo$(EXEEXT) 
 	GOPATH=`cd check-go-dir && $(PWD_COMMAND)`; \
 	export GOPATH; \
 	(cd check-go-dir/src/cmd/go && $(abs_builddir)/go$(EXEEXT) test -test.short -test.v) > cmd_go-testlog 2>&1 || true
-	grep '^--- ' cmd_go-testlog | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/'
+	grep '^--- ' cmd_go-testlog | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' | sort -k 2
 
 # check-runtime runs `go test runtime` in our environment.
 # The runtime package is also tested as part of libgo,
@@ -225,15 +227,15 @@ check-runtime: go$(EXEEXT) cgo$(EXEEXT) 
 	GOARCH=`$(abs_builddir)/go$(EXEEXT) env GOARCH`; \
 	GOOS=`$(abs_builddir)/go$(EXEEXT) env GOOS`; \
 	files=`$(SHELL) $(libgosrcdir)/../match.sh --goarch=$${GOARCH} --goos=$${GOOS} --srcdir=$(libgosrcdir)/runtime --extrafiles="$(libgodir)/runtime_sysinfo.go $(libgodir)/sigtab.go" --tag=libffi`; \
-	echo "$(ECHO_ENV) GC='$(abs_builddir)/check-gccgo -fgo-compiling-runtime' GOARCH=$${GOARCH} GOOS=$${GOOS} $(SHELL) $(libgosrcdir)/../testsuite/gotest --goarch=$${GOARCH} --goos=$${GOOS} --basedir=$(libgosrcdir)/.. --srcdir=$(libgosrcdir)/runtime --pkgpath=runtime --pkgfiles='$${files}' -test.v" > runtime-testlog
+	echo "$(ECHO_ENV) GC='$(abs_builddir)/check-gccgo -fgo-compiling-runtime' GOARCH=$${GOARCH} GOOS=$${GOOS} $(SHELL) $(libgosrcdir)/../testsuite/gotest --goarch=$${GOARCH} --goos=$${GOOS} --basedir=$(libgosrcdir)/.. --srcdir=$(libgosrcdir)/runtime --pkgpath=runtime --pkgfiles='$${files}' $(GOTESTFLAGS) -test.v" > runtime-testlog
 	$(CHECK_ENV) \
 	GC="$${GCCGO} -fgo-compiling-runtime"; \
 	export GC; \
 	GOARCH=`$(abs_builddir)/go$(EXEEXT) env GOARCH`; \
 	GOOS=`$(abs_builddir)/go$(EXEEXT) env GOOS`; \
 	files=`$(SHELL) $(libgosrcdir)/../match.sh --goarch=$${GOARCH} --goos=$${GOOS} --srcdir=$(libgosrcdir)/runtime --extrafiles="$(libgodir)/runtime_sysinfo.go $(libgodir)/sigtab.go" --tag=libffi`; \
-	$(SHELL) $(libgosrcdir)/../testsuite/gotest --goarch=$${GOARCH} --goos=$${GOOS} --basedir=$(libgosrcdir)/.. --srcdir=$(libgosrcdir)/runtime --pkgpath=runtime --pkgfiles="$${files}" -test.v >> runtime-testlog 2>&1 || true
-	grep '^--- ' runtime-testlog | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/'
+	$(SHELL) $(libgosrcdir)/../testsuite/gotest --goarch=$${GOARCH} --goos=$${GOOS} --basedir=$(libgosrcdir)/.. --srcdir=$(libgosrcdir)/runtime --pkgpath=runtime --pkgfiles="$${files}" $(GOTESTFLAGS) -test.v 

[C++ PATCH] Kill SORTED_FIELDS

[Nathan Sidwell]

This patch kills the SORTED_FIELDS vector from the C++ FE.  After a type 
is completed, we now hold everthing on METHOD_VEC, and thus only need 1 
binary search, rather than 2 (or worse, under certain conditions).


As I said at the Cauldron, my earlier attempt to approach this from a 
different direction proved too difficult, so I reverted the patch 
changing SORTED_FIELDS into a hash-map.


There's no change in the lookup during class definition (so, linear 
METHOD_VEC walk followed by linear TYPE_FIELDS walk).  At class 
completion, we extend the METHOD_VEC, push the (non-function) 
TYPE_FIELDS members onto it and then sort it.  This can result in 
adjacent members with the same name.  Examples being record-name and 
non-record member, or function-set and dependent using declaration.  I 
modify the method-cmp function to provide a complete order for these, 
and then deploy a de-duping pass.  The de-duping has to handle the 
following 2 cases:

1) elaborated-type name and something else.  Deploy STAT_HACK machinery.
2) dependent using declaration and overload set.  Wrap the using decl as 
the first member of an overload set.


Once that is done, we have a single slot per name (unlike the 
SORTED_FIELDS handling, which dealt with the STAT_HACK by ordering them 
in a specific order and then tweaking the binary search behaviour).


We need to handle the dependent using decl vs overload in the way we do, 
because some subsequent lookups explicitly want the overload set, but 
the general lookup needs the using-decl to make sure the lookup is 
redone at instantiation time.


Cursory performance testing showed a 3%-4% parsing and instantiation 
improvement.  I think memory useage is essentially unchanged as we're 
replacing 2 vectors with 1 vector containing the concatenation.


There are 2 follow on patches:
1) method_vec is now the wrong name.  It should be member_vec.
2) the remaining sorted_fields handling can be moved from c-common to 
the C FE itself.


Applied to trunk

nathan
--
Nathan Sidwell
2017-09-12  Nathan Sidwell  

	Kill CLASSTYPE_SORTED_FIELDS.
	* cp-tree.h (struct lang_type): Lose sorted_fields member.
	(CLASSTYPE_SORTED_FIELDS): Delete.
	* name-lookup.h (set_class_bindings): Add EXTRA arg.
	* name-lookup.c (fields_linear_search): New, broken out of ...
	(lookup_field_1): ... here.  Delete remainder of function.
	(get_class_binding_direct): Reimplement without sorted_fields.
	(get_class_binding): Rename TYPE arg to KLASS, for consistency.
	(get_method_slot): Call set_class_binding when creating method_vec
	on complete type.
	(method_name_cmp): Order identically named slots.
	(sorted_fields_type_new): Delete.
	(field_vc_append_class_fields): Rename to ...
	(method_vec_append_class_fields): ... here.  Adjust.
	(field_vec_append_enum_values): Renme to ...
	(method_vec_append_enum_values): ... here. Adjust.
	(method_vec_dedup): New.
	(set_class_bindings): Reimplement.
	(insert_late_enum_def_bindings): Reimplement.

Index: cp-tree.h
===
--- cp-tree.h	(revision 252002)
+++ cp-tree.h	(working copy)
@@ -2008,10 +2008,6 @@ struct GTY(()) lang_type {
  as a list of adopted protocols or a pointer to a corresponding
  @interface.  See objc/objc-act.h for details.  */
   tree objc_info;
-  /* sorted_fields is sorted based on a pointer, so we need to be able
- to resort it if pointers get rearranged.  */
-  struct sorted_fields_type * GTY ((reorder ("resort_sorted_fields")))
-sorted_fields;
   /* FIXME reuse another field?  */
   tree lambda_expr;
 };
@@ -3229,11 +3225,6 @@ extern void decl_shadowed_for_var_insert
&& TREE_CODE (TYPE_NAME (NODE)) == TYPE_DECL	\
&& TYPE_DECL_ALIAS_P (TYPE_NAME (NODE)))
 
-/* For a class type: if this structure has many fields, we'll sort them
-   and put them into a TREE_VEC.  */
-#define CLASSTYPE_SORTED_FIELDS(NODE) \
-  (LANG_TYPE_CLASS_CHECK (NODE)->sorted_fields)
-
 /* If non-NULL for a VAR_DECL, FUNCTION_DECL, TYPE_DECL or
TEMPLATE_DECL, the entity is either a template specialization (if
DECL_USE_TEMPLATE is nonzero) or the abstract instance of the
Index: name-lookup.c
===
--- name-lookup.c	(revision 252004)
+++ name-lookup.c	(working copy)
@@ -1156,103 +1156,54 @@ method_vec_linear_search (vec

[libgo] Support 32-bit SPARC relocs

[Rainer Orth]

A couple of gotools tests were FAILing on 32-bit Solaris/SPARC like
this:

FAIL: TestCgoHandlesWlORIGIN
go_test.go:267: running testgo [build origin]
go_test.go:286: standard error:
go_test.go:287: # origin
cannot load DWARF output from $WORK/origin/_obj//_cgo_.o: 
applyRelocations: not implemented

go_test.go:296: go [build origin] failed unexpectedly: exit status 2

The following patch fixes this by implementing applyRelocationsSPARC.
It's a straightforward derivative of applyRelocationsSPARC64.  The only
point of not is support for the SPARC V8Plus ABI, which is the default
on Solaris these days.  The testcase above PASSes now, a couple of
others still FAIL for different reasons.

Rainer

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


2017-09-11  Rainer Orth  

* go/debug/elf/file.go (applyRelocations): Handle 32-bit SPARC.
(applyRelocationsSPARC): New function.

# HG changeset patch
# Parent  ec46539a4547c0a3db20b4c0a5309e8fbbe81bd8
Support 32-bit SPARC relocs

diff --git a/libgo/go/debug/elf/file.go b/libgo/go/debug/elf/file.go
--- a/libgo/go/debug/elf/file.go
+++ b/libgo/go/debug/elf/file.go
@@ -600,6 +600,8 @@ func (f *File) applyRelocations(dst []by
 		return f.applyRelocationsMIPS64(dst, rels)
 	case f.Class == ELFCLASS64 && f.Machine == EM_S390:
 		return f.applyRelocationss390x(dst, rels)
+	case f.Class == ELFCLASS32 && (f.Machine == EM_SPARC || f.Machine == EM_SPARC32PLUS):
+		return f.applyRelocationsSPARC(dst, rels)
 	case f.Class == ELFCLASS64 && f.Machine == EM_SPARCV9:
 		return f.applyRelocationsSPARC64(dst, rels)
 	case f.Class == ELFCLASS64 && f.Machine == EM_ALPHA:
@@ -1006,6 +1008,46 @@ func (f *File) applyRelocationss390x(dst
 	return nil
 }
 
+func (f *File) applyRelocationsSPARC(dst []byte, rels []byte) error {
+	// 12 is the size of Rela32.
+	if len(rels)%12 != 0 {
+		return errors.New("length of relocation section is not a multiple of 12")
+	}
+
+	symbols, _, err := f.getSymbols(SHT_SYMTAB)
+	if err != nil {
+		return err
+	}
+
+	b := bytes.NewReader(rels)
+	var rela Rela32
+
+	for b.Len() > 0 {
+		binary.Read(b, f.ByteOrder, )
+		symNo := rela.Info >> 32
+		t := R_SPARC(rela.Info & 0xff)
+
+		if symNo == 0 || symNo > uint32(len(symbols)) {
+			continue
+		}
+		sym := [symNo-1]
+		if SymType(sym.Info&0xf) != STT_SECTION {
+			// We don't handle non-section relocations for now.
+			continue
+		}
+
+		switch t {
+		case R_SPARC_32, R_SPARC_UA32:
+			if rela.Off+4 >= uint32(len(dst)) || rela.Addend < 0 {
+continue
+			}
+			f.ByteOrder.PutUint32(dst[rela.Off:rela.Off+4], uint32(rela.Addend))
+		}
+	}
+
+	return nil
+}
+
 func (f *File) applyRelocationsSPARC64(dst []byte, rels []byte) error {
 	// 24 is the size of Rela64.
 	if len(rels)%24 != 0 {

RE: [PATCH] Add 'short_call' attribute for MIPS targets

[Matthew Fortune]

Simon Atanasyan  writes:
> On Mon, Sep 11, 2017 at 03:26:52PM +, Matthew Fortune wrote:
> > Simon Atanasyan  writes:
> > > Here is the updated patch with chnaged e-mail address and fixed
> > > indentation issues:
> > > -8<
> > > Currently GCC supports 'long_call', 'far', and 'near' attributes.
> > > The 'long_call' and 'far' attributes are synonyms. This patch adds
> > > support for the 'short_call' attribute as a synonym for `near` to
> > > make this list complete, consistent with other targets, and
> > > compatible with attributes supported by the Clang.
> > >
> > > Tested on mipsel-linux-gnu.
> > >
> > > 2017-08-18  Simon Atanasyan  
> > >
> > > gcc/
> > >   * config/mips/mips.c (mips_attribute_table): Add 'short_call'
> > >   attribute.
> > >   (mips_near_type_p): Add 'short_call' attribute as a synonym
> > >   for 'near'.
> > >   * doc/extend.texi (short_call): Document new function attribute.
> > >
> > > gcc/testsuite
> > >
> > >   * gcc.target/mips/near-far-1.c: Add check for 'short_call'
> > >   attribute.
> > >   * gcc.target/mips/near-far-2.c: Likewise.
> > >   * gcc.target/mips/near-far-3.c: Likewise.
> > >   * gcc.target/mips/near-far-4.c: Likewise.
> >
> > OK to commit, thanks.
> 
> Thanks for review. I do not have commit access. Could you commit the
> patch?

Sure, committed as r252006.

Matthew

Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

[Dominique d'Humières]

Dear Paul,

I have been playing with the patch and found that the following variant of the 
test for pr82168

module mod
implicit none

integer, parameter :: dp = kind (0.0d0)

type, public :: v(z, k)
   integer, len :: z
   integer, kind :: k = kind(0.0)
   real(kind = k) :: e(z)
end type v

end module mod

program bug
use mod
implicit none

type (v(2)) :: a
a%e = 1.0
type (v(z=:, k=dp)) :: b

end program bug

gives the error

pr82168_db_1.f90:23:24:

 type (v(z=:, k=dp)) :: b
1
Error: Unexpected data declaration statement at (1)

I am also puzzled by the meaning of ‘z=:’ in the main program. Should not it be 
restricted to be inside a procedure?

Cheers,

Dominique

Re: [PATCH] Add 'short_call' attribute for MIPS targets

[Simon Atanasyan]

On Mon, Sep 11, 2017 at 03:26:52PM +, Matthew Fortune wrote:
> Simon Atanasyan  writes:
> > Here is the updated patch with chnaged e-mail address and fixed
> > indentation issues:
> > -8<
> > Currently GCC supports 'long_call', 'far', and 'near' attributes. The
> > 'long_call' and 'far' attributes are synonyms. This patch adds support
> > for the 'short_call' attribute as a synonym for `near` to make this list
> > complete, consistent with other targets, and compatible with attributes
> > supported by the Clang.
> > 
> > Tested on mipsel-linux-gnu.
> > 
> > 2017-08-18  Simon Atanasyan  
> > 
> > gcc/
> > * config/mips/mips.c (mips_attribute_table): Add 'short_call'
> > attribute.
> > (mips_near_type_p): Add 'short_call' attribute as a synonym
> > for 'near'.
> > * doc/extend.texi (short_call): Document new function attribute.
> > 
> > gcc/testsuite
> > 
> > * gcc.target/mips/near-far-1.c: Add check for 'short_call'
> > attribute.
> > * gcc.target/mips/near-far-2.c: Likewise.
> > * gcc.target/mips/near-far-3.c: Likewise.
> > * gcc.target/mips/near-far-4.c: Likewise.
> 
> OK to commit, thanks.

Thanks for review. I do not have commit access. Could you commit the patch?

Re: [PATCH] Fix GIMPLE FE test (PR testsuite/82114)

[Aldy Hernandez]

I'm going to abuse either my *gimpl* maintainer hat or my obvious hat
and approve this.

However, since we already have another test that looks the same
(gimplefe-error-2.c) but without the 0 case, it would probably be best
to add a comment in gimplefe-14.c as to why there is a 0 case.  In the
case of gimplefe-error-2.c, it doesn't matter because it is only a
compile test.

OK with that nit.


On Tue, Sep 12, 2017 at 3:44 AM, Martin Liška  wrote:
> Hello.
>
> Simple fix for args == 0 also returns 0 return value.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/testsuite/ChangeLog:
>
> 2017-09-11  Martin Liska  
>
> PR testsuite/82114
> * gcc.dg/gimplefe-14.c (main): Add handling of case 0.
> ---
>  gcc/testsuite/gcc.dg/gimplefe-14.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
>

[C++ PATCH] small METHOD_VEC cleanup

[Nathan Sidwell]

It turned out I wasn't quite at the point of committing my sorted_fields 
killing patch.  This one  just cleans up some functions affected by 
that, and I've applied it separately to reduce the churn.


nathan
--
Nathan Sidwell
2017-09-12  Nathan Sidwell  

	* name-lookup.c (get_class_binding): Rename TYPE arg to KLASS for
	consistency.
	(restort_data): Move later.
	(method_name_cmp, resort_method_name_cmp): Simplify.
	(resort_type_method_vec): Reformat.

Index: name-lookup.c
===
--- name-lookup.c	(revision 252002)
+++ name-lookup.c	(working copy)
@@ -1311,36 +1311,37 @@ get_class_binding_direct (tree klass, tr
special function creation as necessary.  */
 
 tree
-get_class_binding (tree type, tree name, int type_or_fns)
+get_class_binding (tree klass, tree name, int type_or_fns)
 {
-  type = complete_type (type);
+  klass = complete_type (klass);
 
-  if (COMPLETE_TYPE_P (type))
+  if (COMPLETE_TYPE_P (klass))
 {
+  /* Lazily declare functions, if we're going to search these.  */
   if (IDENTIFIER_CTOR_P (name))
 	{
-	  if (CLASSTYPE_LAZY_DEFAULT_CTOR (type))
-	lazily_declare_fn (sfk_constructor, type);
-	  if (CLASSTYPE_LAZY_COPY_CTOR (type))
-	lazily_declare_fn (sfk_copy_constructor, type);
-	  if (CLASSTYPE_LAZY_MOVE_CTOR (type))
-	lazily_declare_fn (sfk_move_constructor, type);
+	  if (CLASSTYPE_LAZY_DEFAULT_CTOR (klass))
+	lazily_declare_fn (sfk_constructor, klass);
+	  if (CLASSTYPE_LAZY_COPY_CTOR (klass))
+	lazily_declare_fn (sfk_copy_constructor, klass);
+	  if (CLASSTYPE_LAZY_MOVE_CTOR (klass))
+	lazily_declare_fn (sfk_move_constructor, klass);
 	}
-  else if (name == cp_assignment_operator_id (NOP_EXPR))
+  else if (IDENTIFIER_DTOR_P (name))
 	{
-	  if (CLASSTYPE_LAZY_COPY_ASSIGN (type))
-	lazily_declare_fn (sfk_copy_assignment, type);
-	  if (CLASSTYPE_LAZY_MOVE_ASSIGN (type))
-	lazily_declare_fn (sfk_move_assignment, type);
+	  if (CLASSTYPE_LAZY_DESTRUCTOR (klass))
+	lazily_declare_fn (sfk_destructor, klass);
 	}
-  else if (IDENTIFIER_DTOR_P (name))
+  else if (name == cp_assignment_operator_id (NOP_EXPR))
 	{
-	  if (CLASSTYPE_LAZY_DESTRUCTOR (type))
-	lazily_declare_fn (sfk_destructor, type);
+	  if (CLASSTYPE_LAZY_COPY_ASSIGN (klass))
+	lazily_declare_fn (sfk_copy_assignment, klass);
+	  if (CLASSTYPE_LAZY_MOVE_ASSIGN (klass))
+	lazily_declare_fn (sfk_move_assignment, klass);
 	}
 }
 
-  return get_class_binding_direct (type, name, type_or_fns);
+  return get_class_binding_direct (klass, name, type_or_fns);
 }
 
 /* Find the slot containing overloads called 'NAME'.  If there is no
@@ -1411,56 +1412,58 @@ get_method_slot (tree klass, tree name)
   return slot;
 }
 
-static struct {
-  gt_pointer_operator new_value;
-  void *cookie;
-} resort_data;
-
-/* Comparison function to compare two TYPE_METHOD_VEC entries by name.  */
+/* Comparison function to compare two TYPE_METHOD_VEC entries by
+   name.  */
 
 static int
-method_name_cmp (const void* m1_p, const void* m2_p)
+method_name_cmp (const void *a_p, const void *b_p)
 {
-  const tree *const m1 = (const tree *) m1_p;
-  const tree *const m2 = (const tree *) m2_p;
+  tree a = *(const tree *)a_p;
+  tree b = *(const tree *)b_p;
+  tree name_a = DECL_NAME (TREE_CODE (a) == OVERLOAD ? OVL_FUNCTION (a) : a);
+  tree name_b = DECL_NAME (TREE_CODE (b) == OVERLOAD ? OVL_FUNCTION (b) : b);
 
-  if (OVL_NAME (*m1) < OVL_NAME (*m2))
-return -1;
-  return 1;
+  gcc_checking_assert (name_a && name_b && name_a != name_b);
+  return name_a < name_b ? -1 : +1;
 }
 
+static struct {
+  gt_pointer_operator new_value;
+  void *cookie;
+} resort_data;
+
 /* This routine compares two fields like method_name_cmp but using the
-   pointer operator in resort_field_decl_data.  */
+   pointer operator in resort_field_decl_data.  We don't have to deal
+   with duplicates here.  */
 
 static int
-resort_method_name_cmp (const void* m1_p, const void* m2_p)
+resort_method_name_cmp (const void *a_p, const void *b_p)
 {
-  const tree *const m1 = (const tree *) m1_p;
-  const tree *const m2 = (const tree *) m2_p;
+  tree a = *(const tree *)a_p;
+  tree b = *(const tree *)b_p;
+  tree name_a = OVL_NAME (a);
+  tree name_b = OVL_NAME (b);
+
+  resort_data.new_value (_a, resort_data.cookie);
+  resort_data.new_value (_b, resort_data.cookie);
+
+  gcc_checking_assert (name_a != name_b);
 
-  tree n1 = OVL_NAME (*m1);
-  tree n2 = OVL_NAME (*m2);
-  resort_data.new_value (, resort_data.cookie);
-  resort_data.new_value (, resort_data.cookie);
-  if (n1 < n2)
-return -1;
-  return 1;
+  return name_a < name_b ? -1 : +1;
 }
 
 /* Resort TYPE_METHOD_VEC because pointers have been reordered.  */
 
 void
-resort_type_method_vec (void* obj,
-			void* /*orig_obj*/,
-			gt_pointer_operator new_value,
-			void* cookie)
+resort_type_method_vec (void *obj, void */*orig_obj*/,
+			gt_pointer_operator new_value, void* 

Re: [RFC][PATCH] Do refactoring of attribute functions and move them to attribs.[hc].

[Jakub Jelinek]

On Tue, Sep 12, 2017 at 01:31:47PM +0200, Martin Liška wrote:
> >From a40c06fc06afcb7bb886d7a3106e6da631a48430 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Tue, 12 Sep 2017 13:30:39 +0200
> Subject: [PATCH] Reduce lookup_attribute memory footprint.
> 
> gcc/ChangeLog:
> 
> 2017-09-12  Martin Liska  
> 
>   * attribs.c (private_lookup_attribute): New function.
>   * attribs.h (private_lookup_attribute): Declared here.
>   (lookup_attribute): Called from this place.
> ---
>  gcc/attribs.c | 17 +
>  gcc/attribs.h | 17 ++---
>  2 files changed, 23 insertions(+), 11 deletions(-)
> 
> diff --git a/gcc/attribs.c b/gcc/attribs.c
> index b8f58a74596..9064434e5f2 100644
> --- a/gcc/attribs.c
> +++ b/gcc/attribs.c
> @@ -1584,3 +1584,20 @@ attribute_list_contained (const_tree l1, const_tree l2)
>  
>return 1;
>  }
> +
> +

Can you please add a function comment (and in addition to arguments explain
there why lookup_attribute is split into the two parts)?

> +tree
> +private_lookup_attribute (const char *attr_name, size_t attr_len, tree list)
> +{
> +  while (list)
> +{

> @@ -151,17 +156,7 @@ lookup_attribute (const char *attr_name, tree list)
>/* Do the strlen() before calling the out-of-line implementation.
>In most cases attr_name is a string constant, and the compiler
>will optimize the strlen() away.  */

Part of the comment is of course here and that comment didn't make any sense
when everything was inlined.

> -  while (list)
> - {
> -   tree attr = get_attribute_name (list);
> -   size_t ident_len = IDENTIFIER_LENGTH (attr);
> -   if (cmp_attribs (attr_name, attr_len, IDENTIFIER_POINTER (attr),
> -ident_len))
> - break;
> -   list = TREE_CHAIN (list);
> - }
> -
> -  return list;
> +  return private_lookup_attribute (attr_name, attr_len, list);
>  }
>  }

LGTM with the comment added.  In theory fnsplit could handle that too,
but 1) it would emit out of line stuff in every TU separately 2) the
compiler doesn't know that NULL DECL_ATTRIBUTES is so common (it could
with profiledbootstrap).  And of course LTO can decide to inline it
from attribs.c back anyway if there are reasons why it would be beneficial
somewhere (but I doubt it is beneficial at least in most spots).

Jakub

[libgfortran] Replace implicit conversions between enums in io/transfer.c by explicit casts.

[Prathamesh Kulkarni]

Hi,
I am working on patch for PR78736
(https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00011.html),
which adds a new warning -Wenum-conversion to C front-end to warn for
implicit conversion between different enums.
The warning in that patch triggered on io/transfer.c for following
implicit conversions:
i) Implicit conversion from unit_mode to file_mode
ii) Implicit conversion from unit_sign_s to unit_sign.

I was wondering if the warning for above implicit conversions would be
correct since unit_mode
and file_mode are different enums and similarly unit_sign_s and
unit_sign are different enums ?
Or are these warnings false positives ?

The attached patch makes the conversion explicit to silence the warnings.
Bootstrap+tested on x86_64-unknown-linux-gnu.
Does the patch look OK ?

Thanks,
Prathamesh
2017-09-12  Prathamesh Kulkarni  

libgfortran/
* io/transfer.c (current_mode): Cast FORM_UNSPECIFIED to file_mode.
(formatted_transfer_scalar_read): Cast SIGN_S, SIGN_SS, SIGN_SP to
unit_sign.
(formatted_transfer_scalar_write): Likewise.

diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 529637061b1..3307d213bb7 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -196,7 +196,7 @@ current_mode (st_parameter_dt *dtp)
 {
   file_mode m;
 
-  m = FORM_UNSPECIFIED;
+  m = (file_mode) FORM_UNSPECIFIED;
 
   if (dtp->u.p.current_unit->flags.access == ACCESS_DIRECT)
 {
@@ -1671,17 +1671,17 @@ formatted_transfer_scalar_read (st_parameter_dt *dtp, 
bt type, void *p, int kind
 
case FMT_S:
  consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_S;
+ dtp->u.p.sign_status = (unit_sign) SIGN_S;
  break;
 
case FMT_SS:
  consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SS;
+ dtp->u.p.sign_status = (unit_sign) SIGN_SS;
  break;
 
case FMT_SP:
  consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SP;
+ dtp->u.p.sign_status = (unit_sign) SIGN_SP;
  break;
 
case FMT_BN:
@@ -2130,17 +2130,17 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, 
bt type, void *p, int kin
 
case FMT_S:
  consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_S;
+ dtp->u.p.sign_status = (unit_sign) SIGN_S;
  break;
 
case FMT_SS:
  consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SS;
+ dtp->u.p.sign_status = (unit_sign) SIGN_SS;
  break;
 
case FMT_SP:
  consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SP;
+ dtp->u.p.sign_status = (unit_sign) SIGN_SP;
  break;
 
case FMT_BN:

Re: [RFC][PATCH] Do refactoring of attribute functions and move them to attribs.[hc].

[Martin Liška]

On 09/12/2017 09:54 AM, Jakub Jelinek wrote:
> On Thu, Jul 13, 2017 at 03:51:31PM +0200, Martin Liška wrote:
>> It's request for comment where I mechanically moved attribute-related 
>> function to attribs.[hc].
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Thoughts?
> 
> I've only noticed this now, what is the reason for undoing the size
> optimization we had, i.e. inline lookup_attribute that handles the most
> common case inline only and inline computes the strlen (an important
> optimization, because we almost always call it with a string literal
> and strlen of that is a constant) and doing the rest out of line?
> 
>> -/* Given an attribute name ATTR_NAME and a list of attributes LIST,
>> -   return a pointer to the attribute's list element if the attribute
>> -   is part of the list, or NULL_TREE if not found.  If the attribute
>> -   appears more than once, this only returns the first occurrence; the
>> -   TREE_CHAIN of the return value should be passed back in if further
>> -   occurrences are wanted.  ATTR_NAME must be in the form 'text' (not
>> -   '__text__').  */
>> -
>> -static inline tree
>> -lookup_attribute (const char *attr_name, tree list)
>> -{
>> -  gcc_checking_assert (attr_name[0] != '_');  
>> -  /* In most cases, list is NULL_TREE.  */
>> -  if (list == NULL_TREE)
>> -return NULL_TREE;
>> -  else
>> -/* Do the strlen() before calling the out-of-line implementation.
>> -   In most cases attr_name is a string constant, and the compiler
>> -   will optimize the strlen() away.  */
>> -return private_lookup_attribute (attr_name, strlen (attr_name), list);
>> -}
> 
> The current code instead inlines the whole lookup_attribute which is larger.
> Have you looked at the code size effects of that change?
> 
>   Jakub
> 

Hi.

Sorry for removal of the optimization. You're right it really adds some size 
(~30K of .text):

$ bloaty gcc/cc1plus -- /tmp/cc1plus 
 VM SIZE  FILE SIZE
 ++ GROWING++
  [ = ]   0 .debug_loc  +277Ki  +0.4%
  [ = ]   0 .debug_info+86.9Ki  +0.1%
  [ = ]   0 .debug_ranges  +59.9Ki  +0.5%
  +0.2% +32.1Ki .text  +32.1Ki  +0.2%
  [ = ]   0 .debug_line+9.36Ki  +0.1%
  +0.0% +2.06Ki .rodata+2.06Ki  +0.0%
  [ = ]   0 .symtab+1.73Ki  +0.1%
  +0.1% +1.72Ki .eh_frame  +1.72Ki  +0.1%
  +0.0%+272 .dynstr   +272  +0.0%
  [ = ]   0 .debug_abbrev +140  +0.0%
  +0.0% +72 .dynsym+72  +0.0%
  +0.0% +64 .eh_frame_hdr  +64  +0.0%
  [ = ]   0 .debug_aranges +48  +0.0%
  +0.0% +12 .gnu.hash  +12  +0.0%
  +0.0% +12 .hash  +12  +0.0%
  +0.0%  +6 .gnu.version+6  +0.0%

 -- SHRINKING  --
 -10.2%  -6 [Unmapped]-317 -20.8%
  [ = ]   0 .strtab-66  -0.0%
  [ = ]   0 .debug_str -52  -0.0%

  +0.1% +36.3Ki TOTAL   +471Ki  +0.2%

$ bloaty gcc/cc1 -- /tmp/cc1
 VM SIZE  FILE SIZE
 ++ GROWING++
  [ = ]   0 .debug_loc  +232Ki  +0.4%
  [ = ]   0 .debug_info+74.1Ki  +0.1%
  [ = ]   0 .debug_ranges  +48.9Ki  +0.4%
  +0.2% +26.9Ki .text  +26.9Ki  +0.2%
  [ = ]   0 .debug_line+8.22Ki  +0.1%
  +0.1% +1.79Ki .eh_frame  +1.79Ki  +0.1%
  +0.0% +1.75Ki .rodata+1.75Ki  +0.0%
  [ = ]   0 .symtab+1.50Ki  +0.1%
  +0.0%+272 .dynstr   +272  +0.0%
  [ = ]   0 .debug_abbrev  +72  +0.0%
  +0.0% +72 .dynsym+72  +0.0%
  +0.0% +64 .eh_frame_hdr  +64  +0.0%
  [ = ]   0 .debug_aranges +48  +0.0%
  +0.0% +12 .gnu.hash  +12  +0.0%
  +0.0% +12 .hash  +12  +0.0%
  +0.0%  +6 .gnu.version+6  +0.0%

 -- SHRINKING  --
  [ = ]   0 .debug_str -52  -0.0%
  [ = ]   0 .strtab-26  -0.0%

 -+-+-+-+-+-+-+ MIXED  +-+-+-+-+-+-+-
   +19% +10 [Unmapped] -2.87Ki -75.1%

  +0.1% +30.9Ki TOTAL   +392Ki  +0.2%

Thus I'm suggesting to the how it was. Is the patch OK after testing?

Martin
>From a40c06fc06afcb7bb886d7a3106e6da631a48430 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 12 Sep 2017 13:30:39 +0200
Subject: [PATCH] Reduce lookup_attribute memory footprint.

gcc/ChangeLog:

2017-09-12  Martin Liska  

	* attribs.c (private_lookup_attribute): New function.
	* attribs.h (private_lookup_attribute): Declared here.
	(lookup_attribute): Called from this place.
---
 gcc/attribs.c | 17 +
 gcc/attribs.h | 17 ++---
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/gcc/attribs.c b/gcc/attribs.c
index b8f58a74596..9064434e5f2 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -1584,3 +1584,20 @@ attribute_list_contained (const_tree l1, const_tree l2)
 
   

[PATCH] [ARC] Check the assembler for gdwarf2 support.

[Claudiu Zissulescu]

From: claziss 

This small patch enables the gcc driver to pass dwarf related options to the 
assembler.

Ok to apply?
Claudiu

gcc/
2017-06-21  Claudiu Zissulescu  

* configure.ac: Add arc and check if assembler supports gdwarf2.
* configure: Regenerate.
---
 gcc/configure| 6 +++---
 gcc/configure.ac | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index 9cee670..13f97cd 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -27664,9 +27664,9 @@ esac
 # ??? Once 2.11 is released, probably need to add first known working
 # version to the per-target configury.
 case "$cpu_type" in
-  aarch64 | alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze \
-  | mips | nios2 | pa | riscv | rs6000 | score | sparc | spu | tilegx \
-  | tilepro | visium | xstormy16 | xtensa)
+  aarch64 | alpha | arc | arm | avr | bfin | cris | i386 | m32c | m68k \
+  | microblaze | mips | nios2 | pa | riscv | rs6000 | score | sparc | spu \
+  | tilegx | tilepro | visium | xstormy16 | xtensa)
 insn="nop"
 ;;
   ia64 | s390)
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0c0e359..8271138 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4810,9 +4810,9 @@ esac
 # ??? Once 2.11 is released, probably need to add first known working
 # version to the per-target configury.
 case "$cpu_type" in
-  aarch64 | alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze \
-  | mips | nios2 | pa | riscv | rs6000 | score | sparc | spu | tilegx \
-  | tilepro | visium | xstormy16 | xtensa)
+  aarch64 | alpha | arc | arm | avr | bfin | cris | i386 | m32c | m68k \
+  | microblaze | mips | nios2 | pa | riscv | rs6000 | score | sparc | spu \
+  | tilegx | tilepro | visium | xstormy16 | xtensa)
 insn="nop"
 ;;
   ia64 | s390)
-- 
1.9.1

RE: [PATCH] Fix PR 81096 (ttest failures)

[Wilco Dijkstra]

Steve Ellcey wrote:
> This patch fixes the ttest failures on aarch64 by adding AM_CFLAGS to
> the test options, like btest already does and as Wilco says works for
> him in Comment #4 of the bug report.

Thanks for picking this up, this looks OK.

> Tested by me on aarch64.  Ok to checkin?

This counts as an obvious fix, so you can commit it.

Wilco

RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations

[Richard Biener]

On Tue, 12 Sep 2017, Richard Biener wrote:

> On Tue, 12 Sep 2017, Tamar Christina wrote:
> 
> > Hi Jon, Richard,
> > 
> > > > >
> > > > > Testing the following instead:
> > > >
> > > > Any news on this?
> > > 
> > > Didn't work out as expected.  I think the logic in tree-vect-generic is 
> > > the one
> > > to be fixed but I have to carve out some time to look into it so stay 
> > > tuned.
> > 
> > In the meantime can this patch be reverted? It is causing ICEs on 
> > AArch64 and ARM Preventing us from building benchmarks and tracking the 
> > toolchain performance.
> 
> You can always locally patch things.  I have yet another patch in
> testing right now.

I've installed the following.

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

Richard.

2017-09-12  Richard Biener  

* tree-vect-generic.c (expand_vector_operations_1): Do nothing
for operations we cannot scalarize.

Index: gcc/tree-vect-generic.c
===
--- gcc/tree-vect-generic.c (revision 251997)
+++ gcc/tree-vect-generic.c (working copy)
@@ -1638,7 +1638,11 @@ expand_vector_operations_1 (gimple_stmt_
   /* The signedness is determined from input argument.  */
   if (code == VEC_UNPACK_FLOAT_HI_EXPR
   || code == VEC_UNPACK_FLOAT_LO_EXPR)
-type = TREE_TYPE (rhs1);
+{
+  type = TREE_TYPE (rhs1);
+  /* We do not know how to scalarize those.  */
+  return;
+}
 
   /* For widening/narrowing vector operations, the relevant type is of the
  arguments, not the widened result.  VEC_UNPACK_FLOAT_*_EXPR is
@@ -1655,7 +1659,11 @@ expand_vector_operations_1 (gimple_stmt_
   || code == VEC_PACK_FIX_TRUNC_EXPR
   || code == VEC_WIDEN_LSHIFT_HI_EXPR
   || code == VEC_WIDEN_LSHIFT_LO_EXPR)
-type = TREE_TYPE (rhs1);
+{
+  type = TREE_TYPE (rhs1);
+  /* We do not know how to scalarize those.  */
+  return;
+}
 
   /* Choose between vector shift/rotate by vector and vector shift/rotate by
  scalar */

Re: [patch, fortran, RFC] warn about out-of-bounds errors in DO loops

[Richard Sandiford]

Thanks for doing this, looks really useful.

Thomas Koenig  writes:
> Well, here's a version which actually throws a hard error in
> obvious cases; the other cases are reserved for -Wextra.

Is it OK to throw a hard error for this?  Maybe the rules are different
from C and C++, but normally we can't do that for code that's only
invalid if executed.  An unconditional warning would be good though.

Thanks,
Richard

[Ada] Enforce check on wrong usage names in aspect definitions

[Arnaud Charlet]

The frontend does not report an error on aspect clases defined in the
public part of a nested package that reference names defined in the
private part.

After this patch the error is reported on the following sources:

pragma Ada_2012;
with Ada.Text_IO;
use Ada.Text_IO;
procedure Small is
   package Pack is
  type T is tagged private
with Constant_Indexing => F;   --  Error
   private
  function F
(Obj : T; S : String; Pos : Positive) return Character;
  type T is tagged null record;
   end Pack;
   package body Pack is
  function F
(Obj : T; S : String; Pos : Positive) return Character is
  begin
 return S (Pos);
  end F;
   end Pack;
   use Pack;
   V : T;
begin
   Put (V ("abcd", 1));
   Put (V ("abcd", 2));
   New_Line;
end;

Command: gcc -c small.adb
Output:
  small.adb:7:14: aspect must be fully defined before "T" is frozen
  small.adb:7:35: "F" is undefined

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

2017-09-12  Javier Miranda  

* sem_ch3.adb (Analyze_Declarations): In nested
package declarations that have a private part enable missing check
of the RM rule 13.1.1(11/3): usage names in aspect definitions are
resolved at the end of the immediately enclosing declaration list.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 251998)
+++ sem_ch3.adb (working copy)
@@ -2676,14 +2676,11 @@
   and then not Is_Child_Unit (Current_Scope)
   and then No (Generic_Parent (Parent (L)))
 then
-   --  This is needed in all cases to catch visibility errors in
-   --  aspect expressions, but several large user tests are now
-   --  rejected. Pending notification we restrict this call to
-   --  ASIS mode.
+   --  ARM rule 13.1.1(11/3): usage names in aspect definitions are
+   --  resolved at the end of the immediately enclosing declaration
+   --  list (AI05-0183-1).
 
-   if ASIS_Mode then
-  Resolve_Aspects;
-   end if;
+   Resolve_Aspects;
 
 elsif L /= Visible_Declarations (Parent (L))
   or else No (Private_Declarations (Parent (L)))

[Ada] Spurious warning in Containers.Bounded_Doubly_Linked_Lists

[Arnaud Charlet]

This patch fixes a bug in which an instantiation of
Containers.Bounded_Doubly_Linked_Lists can give warnings if the actual
type passed to Element_Type is not fully default-initialized.

The following test should compile quietly.

with Ada.Containers.Bounded_Doubly_Linked_Lists;

procedure Test is
  type Async_Construct_Query_Info_T is
record
  From_Index  : Positive;
  To_Index: Positive;
end record;

  package Async_Construct_Query_Info_Queue
is new Ada.Containers.Bounded_Doubly_Linked_Lists
 (Async_Construct_Query_Info_T);
begin
  null;
end;

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

2017-09-12  Bob Duff  

* libgnat/a-cbdlli.adb, libgnat/a-cbhama.adb,
libgnat/a-cbmutr.adb, libgnat/a-cborma.adb: Rename New_Item to
be Default_Initialized_Item, and apply pragma Unmodified to it,
to suppress the warning.

Index: libgnat/a-cbhama.adb
===
--- libgnat/a-cbhama.adb(revision 251998)
+++ libgnat/a-cbhama.adb(working copy)
@@ -578,8 +578,9 @@
   -
 
   procedure Assign_Key (Node : in out Node_Type) is
- New_Item : Element_Type;
- pragma Unmodified (New_Item);
+ pragma Warnings (Off);
+ Default_Initialized_Item : Element_Type;
+ pragma Unmodified (Default_Initialized_Item);
  --  Default-initialized element (ok to reference, see below)
 
   begin
@@ -591,7 +592,8 @@
  --  default initialization, so insert a possibly initialized element
  --  under the given key.
 
- Node.Element := New_Item;
+ Node.Element := Default_Initialized_Item;
+ pragma Warnings (On);
   end Assign_Key;
 
   --
Index: libgnat/a-cborma.adb
===
--- libgnat/a-cborma.adb(revision 251998)
+++ libgnat/a-cborma.adb(working copy)
@@ -851,8 +851,9 @@
   
 
   procedure Assign (Node : in out Node_Type) is
- New_Item : Element_Type;
- pragma Unmodified (New_Item);
+ pragma Warnings (Off);
+ Default_Initialized_Item : Element_Type;
+ pragma Unmodified (Default_Initialized_Item);
  --  Default-initialized element (ok to reference, see below)
 
   begin
@@ -863,7 +864,8 @@
   --  with such a scalar component or with defaulted components, so insert
   --  possibly initialized elements at the given position.
 
- Node.Element := New_Item;
+ Node.Element := Default_Initialized_Item;
+ pragma Warnings (On);
   end Assign;
 
   --
Index: libgnat/a-cbdlli.adb
===
--- libgnat/a-cbdlli.adb(revision 251998)
+++ libgnat/a-cbdlli.adb(working copy)
@@ -1016,9 +1016,13 @@
   Count : Count_Type := 1)
is
   pragma Warnings (Off);
-  New_Item : Element_Type;
+  Default_Initialized_Item : Element_Type;
+  pragma Unmodified (Default_Initialized_Item);
   --  OK to reference, see below. Note that we need to suppress both the
-  --  front end warning and the back end warning.
+  --  front end warning and the back end warning. In addition, pragma
+  --  Unmodified is needed to suppress the warning ``actual type for
+  --  "Element_Type" should be fully initialized type'' on certain
+  --  instantiations.
 
begin
   --  There is no explicit element provided, but in an instance the element
@@ -1027,7 +1031,7 @@
   --  initialization, so insert the specified number of possibly
   --  initialized elements at the given position.
 
-  Insert (Container, Before, New_Item, Position, Count);
+  Insert (Container, Before, Default_Initialized_Item, Position, Count);
   pragma Warnings (On);
end Insert;
 
Index: libgnat/a-cbmutr.adb
===
--- libgnat/a-cbmutr.adb(revision 251998)
+++ libgnat/a-cbmutr.adb(working copy)
@@ -1581,8 +1581,9 @@
   First : Count_Type;
   Last  : Count_Type;
 
-  New_Item : Element_Type;
-  pragma Unmodified (New_Item);
+  pragma Warnings (Off);
+  Default_Initialized_Item : Element_Type;
+  pragma Unmodified (Default_Initialized_Item);
   --  OK to reference, see below
 
begin
@@ -1629,12 +1630,13 @@
   --  initialization, so insert the specified number of possibly
   --  initialized elements at the given position.
 
-  Allocate_Node (Container, New_Item, First);
+  Allocate_Node (Container, Default_Initialized_Item, First);
   Nodes (First).Parent := Parent.Node;
 
   Last := First;
   for J in Count_Type'(2) .. Count loop
- Allocate_Node (Container, New_Item, Nodes (Last).Next);
+ Allocate_Node
+   (Container, 

[Ada] Ignore both Global and Refined_Global in CodePeer mode

[Arnaud Charlet]

Only the first pragma was ignored in CodePeer mode, to allow analysis of
legacy code, which caused errors when the second was also present. Now
both are ignored in CodePeer mode.

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

2017-09-12  Yannick Moy  

* gnat1drv.adb (Adjust_Global_Switches): Consider Refined_Global
together with Global when ignoring one in CodePeer mode.

Index: gnat1drv.adb
===
--- gnat1drv.adb(revision 252000)
+++ gnat1drv.adb(working copy)
@@ -66,7 +66,7 @@
 with Set_Targ;
 with Sinfo;use Sinfo;
 with Sinput.L; use Sinput.L;
-with Snames;
+with Snames;   use Snames;
 with Sprint;   use Sprint;
 with Stringt;
 with Stylesw;  use Stylesw;
@@ -272,9 +272,13 @@
  Restrict.Restrictions.Set   (Max_Asynchronous_Select_Nesting) := True;
  Restrict.Restrictions.Value (Max_Asynchronous_Select_Nesting) := 0;
 
- --  Enable pragma Ignore_Pragma (Global) to support legacy code
+ --  Enable pragma Ignore_Pragma (Global) to support legacy code. As a
+ --  consequence, Refined_Global pragma should be ignored as well, as
+ --  it is only allowed on a body when pragma Global is given for the
+ --  spec.
 
- Set_Name_Table_Boolean3 (Name_Id'(Name_Find ("global")), True);
+ Set_Name_Table_Boolean3 (Name_Global, True);
+ Set_Name_Table_Boolean3 (Name_Refined_Global, True);
 
  --  Suppress division by zero checks since they are handled
  --  implicitly by CodePeer.

[Ada] Dynamically tagged expr of expr function is illegal

[Arnaud Charlet]

It is illegal to return a dynamically tagged expression
from an expression function that returns a specific type. See
RM-3.9.2(9). This patch fixes a bug that caused the compiler
to fail to detect this illegality.

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

2017-09-12  Bob Duff  

* sem_ch6.adb (Analyze_Expression_Function): Call
Check_Dynamically_Tagged_Expression.
* sem_util.adb (Check_Dynamically_Tagged_Expression): Remove
"and then Is_Tagged_Type (Typ)" because there is an earlier
"Assert (Is_Tagged_Type (Typ))".

Index: sem_util.adb
===
--- sem_util.adb(revision 251998)
+++ sem_util.adb(working copy)
@@ -2022,7 +2022,6 @@
or else In_Generic_Actual (Expr))
 and then (Is_Class_Wide_Type (Etype (Expr))
or else Is_Dynamically_Tagged (Expr))
-and then Is_Tagged_Type (Typ)
 and then not Is_Class_Wide_Type (Typ)
   then
  Error_Msg_N ("dynamically tagged expression not allowed!", Expr);
Index: sem_ch6.adb
===
--- sem_ch6.adb (revision 251998)
+++ sem_ch6.adb (working copy)
@@ -741,6 +741,21 @@
  end;
   end if;
 
+  --  Check incorrect use of dynamically tagged expression. This doesn't
+  --  fall out automatically when analyzing the generated function body,
+  --  because Check_Dynamically_Tagged_Expression deliberately ignores
+  --  nodes that don't come from source.
+
+  if Present (Def_Id)
+and then Nkind (Def_Id) in N_Has_Etype
+and then Is_Tagged_Type (Etype (Def_Id))
+  then
+ Check_Dynamically_Tagged_Expression
+   (Expr => Expr,
+Typ  => Etype (Def_Id),
+Related_Nod => Original_Node (N));
+  end if;
+
   --  If the return expression is a static constant, we suppress warning
   --  messages on unused formals, which in most cases will be noise.
 

RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations

[Richard Biener]

On Tue, 12 Sep 2017, Tamar Christina wrote:

> Hi Jon, Richard,
> 
> > > >
> > > > Testing the following instead:
> > >
> > > Any news on this?
> > 
> > Didn't work out as expected.  I think the logic in tree-vect-generic is the 
> > one
> > to be fixed but I have to carve out some time to look into it so stay tuned.
> 
> In the meantime can this patch be reverted? It is causing ICEs on 
> AArch64 and ARM Preventing us from building benchmarks and tracking the 
> toolchain performance.

You can always locally patch things.  I have yet another patch in
testing right now.

Richard.

> Thanks,
> Tamar
> 
> > 
> > Richard.
> > 
> > > VP.
> > >
> > >
> > > >
> > > > Index: gcc/tree-vect-generic.c
> > > >
> > ==
> > =
> > > > --- gcc/tree-vect-generic.c (revision 251642)
> > > > +++ gcc/tree-vect-generic.c (working copy)
> > > > @@ -1640,7 +1640,7 @@ expand_vector_operations_1 (gimple_stmt_
> > > >|| code == VEC_UNPACK_FLOAT_LO_EXPR)
> > > >  type = TREE_TYPE (rhs1);
> > > >
> > > > -  /* For widening/narrowing vector operations, the relevant type is
> > > > of the
> > > > +  /* For widening vector operations, the relevant type is of the
> > > >   arguments, not the widened result.  VEC_UNPACK_FLOAT_*_EXPR is
> > > >   calculated in the same way above.  */
> > > >if (code == WIDEN_SUM_EXPR
> > > > @@ -1650,9 +1650,6 @@ expand_vector_operations_1 (gimple_stmt_
> > > >|| code == VEC_WIDEN_MULT_ODD_EXPR
> > > >|| code == VEC_UNPACK_HI_EXPR
> > > >|| code == VEC_UNPACK_LO_EXPR
> > > > -  || code == VEC_PACK_TRUNC_EXPR
> > > > -  || code == VEC_PACK_SAT_EXPR
> > > > -  || code == VEC_PACK_FIX_TRUNC_EXPR
> > > >|| code == VEC_WIDEN_LSHIFT_HI_EXPR
> > > >|| code == VEC_WIDEN_LSHIFT_LO_EXPR)
> > > >  type = TREE_TYPE (rhs1);
> > > >
> > > >
> > > > also fix for a bug uncovered by the previous one:
> > > >
> > > > Index: gcc/gimple-ssa-strength-reduction.c
> > > >
> > ==
> > =
> > > > --- gcc/gimple-ssa-strength-reduction.c (revision 251710)
> > > > +++ gcc/gimple-ssa-strength-reduction.c (working copy)
> > > > @@ -1742,8 +1742,7 @@ find_candidates_dom_walker::before_dom_c
> > > > slsr_process_ref (gs);
> > > >
> > > >else if (is_gimple_assign (gs)
> > > > -  && SCALAR_INT_MODE_P
> > > > -   (TYPE_MODE (TREE_TYPE (gimple_assign_lhs (gs)
> > > > +  && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs
> > > > + (gs
> > > > {
> > > >   tree rhs1 = NULL_TREE, rhs2 = NULL_TREE;
> > > >
> > > >
> > >
> > >
> > 
> > --
> > Richard Biener 
> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton,
> > HRB 21284 (AG Nuernberg)
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)