RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: Jeff Law 
> Sent: Friday, August 3, 2018 19:03
> To: Tamar Christina ; Joseph Myers
> 
> Cc: gcc-patches@gcc.gnu.org; nd ; bonz...@gnu.org;
> d...@redhat.com; nero...@gcc.gnu.org; aol...@redhat.com;
> ralf.wildenh...@gmx.de
> Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework]
> Allow setting of stack-clash via configure options. [Patch (4/6)]
> 
> On 07/24/2018 08:14 AM, Tamar Christina wrote:
> > Hi All,
> >
> > Here's an updated patch with documentation.
> >
> >
> > Ok for trunk?
> >
> > Thanks,
> > Tamar
> >
> > gcc/
> > 2018-07-24  Tamar Christina  
> >
> > PR target/86486
> > * configure.ac: Add stack-clash-protection-guard-size.
> > * doc/install.texi: Document it.
> > * config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
> > * params.def: Update comment for guard-size.
> > * configure: Regenerate.
> >
> > The 07/24/2018 11:34, Joseph Myers wrote:
> >> On Tue, 24 Jul 2018, tamar.christ...@arm.com wrote:
> >>
> >>> This patch defines a configure option to allow the setting of the
> >>> default guard size via configure flags when building the target.
> >> If you add a configure option, you must also add documentation for it
> >> in install.texi.
> >>
> >> --
> >> Joseph S. Myers
> >> jos...@codesourcery.com
> > --
> >
> >
> > rb9473-3.patch
> >
> 
> OK.
> jeff

RE: [PATCH][GCC][AArch64] Cleanup the AArch64 testsuite when stack-clash is on [Patch (7/7)]

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org 
> On Behalf Of Tamar Christina
> Sent: Friday, September 28, 2018 17:36
> To: Jeff Law ; gcc-patches@gcc.gnu.org
> Cc: nd ; James Greenhalgh ;
> Richard Earnshaw ; Marcus Shawcroft
> 
> Subject: RE: [PATCH][GCC][AArch64] Cleanup the AArch64 testsuite when
> stack-clash is on [Patch (7/7)]
> 
> Hi All,
> 
> This is a minor update to fix stack-check-12.c for ilp32.
> The datatype would be too small on ilp32 to require a probe.
> 
> gcc/testsuite/
> 2018-08-28  Tamar Christina  
> 
>   PR target/86486
>   * gcc.dg/pr82788.c: Skip for AArch64.
>   * gcc.dg/guality/vla-1.c: Turn off stack-clash.
>   * gcc.target/aarch64/subsp.c: Likewise.
>   * gcc.dg/params/blocksort-part.c: Skip stack-clash checks
>   on AArch64.
>   * gcc.dg/stack-check-10.c: Add AArch64 specific checks.
>   * gcc.dg/stack-check-12.c: ILP32 fixup.
>   * gcc.dg/stack-check-5.c: Add AArch64 specific checks.
>   * gcc.dg/stack-check-6a.c: Skip on AArch64, we don't support this.
>   * testsuite/lib/target-supports.exp
>   (check_effective_target_frame_pointer_for_non_leaf): AArch64
> does not
>   require frame pointer for non-leaf functions.
> 
> As before I assume the OK still applies as the change is trivial so will 
> commit
> this with the rest once all approved.
> 
> Thanks,
> Tamar
> 
> > -Original Message-
> > From: Jeff Law 
> > Sent: Tuesday, August 28, 2018 19:13
> > To: Tamar Christina ; gcc-patches@gcc.gnu.org
> > Cc: nd ; James Greenhalgh ;
> > Richard Earnshaw ; Marcus Shawcroft
> > 
> > Subject: Re: [PATCH][GCC][AArch64] Cleanup the AArch64 testsuite when
> > stack-clash is on [Patch (7/7)]
> >
> > On 08/28/2018 06:18 AM, Tamar Christina wrote:
> > > Hi All,
> > >
> > > Since this patch series now contains SVE support I am removing the
> > > changes to the SVE tests in this patch series.  I assume the OK
> > > still stands as the only change here is undoing updates to three files.
> > >
> > > Thanks,
> > > Tamar
> > >
> > > gcc/testsuite/
> > > 2018-08-28  Tamar Christina  
> > >
> > >   PR target/86486
> > >   * gcc.dg/pr82788.c: Skip for AArch64.
> > >   * gcc.dg/guality/vla-1.c: Turn off stack-clash.
> > >   * gcc.target/aarch64/subsp.c: Likewise.
> > >   * gcc.dg/params/blocksort-part.c: Skip stack-clash checks
> > >   on AArch64.
> > >   * gcc.dg/stack-check-10.c: Add AArch64 specific checks.
> > >   * gcc.dg/stack-check-5.c: Add AArch64 specific checks.
> > >   * gcc.dg/stack-check-6a.c: Skip on AArch64, we don't support this.
> > >   * testsuite/lib/target-supports.exp
> > >   (check_effective_target_frame_pointer_for_non_leaf): AArch64
> > does not
> > >   require frame pointer for non-leaf functions.
> > Yea, the OK still applies.
> > jeff

RE: [PATCH][GCC][AArch64] Set default values for stack-clash and do basic validation in back-end. [Patch (5/6)]

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: James Greenhalgh 
> Sent: Tuesday, July 31, 2018 22:02
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> 
> Subject: Re: [PATCH][GCC][AArch64] Set default values for stack-clash and
> do basic validation in back-end. [Patch (5/6)]
> 
> On Tue, Jul 24, 2018 at 05:27:05AM -0500, Tamar Christina wrote:
> > Hi All,
> >
> > This patch is a cascade update from having to re-spin the configure patch
> (no# 4 in the series).
> >
> > This patch enforces that the default guard size for stack-clash
> > protection for
> > AArch64 be 64KB unless the user has overriden it via configure in
> > which case the user value is used as long as that value is within the valid
> range.
> >
> > It also does some basic validation to ensure that the guard size is
> > only 4KB or 64KB and also enforces that for aarch64 the stack-clash
> > probing interval is equal to the guard size.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> > Target was tested with stack clash on and off by default.
> >
> > Ok for trunk?
> 
> This is OK with the style changes below.
> 
> Thanks,
> James
> 
> > gcc/
> > 2018-07-24  Tamar Christina  
> >
> > PR target/86486
> > * config/aarch64/aarch64.c (aarch64_override_options_internal):
> > Add validation for stack-clash parameters and set defaults.
> >
> > > -Original Message-
> > > From: Tamar Christina 
> > > Sent: Wednesday, July 11, 2018 12:23
> > > To: gcc-patches@gcc.gnu.org
> > > Cc: nd ; James Greenhalgh
> ;
> > > Richard Earnshaw ; Marcus Shawcroft
> > > 
> > > Subject: [PATCH][GCC][AArch64] Set default values for stack-clash
> > > and do basic validation in back-end. [Patch (5/6)]
> > >
> > > Hi All,
> > >
> > > This patch enforces that the default guard size for stack-clash
> > > protection for
> > > AArch64 be 64KB unless the user has overriden it via configure in
> > > which case the user value is used as long as that value is within the 
> > > valid
> range.
> > >
> > > It also does some basic validation to ensure that the guard size is
> > > only 4KB or 64KB and also enforces that for aarch64 the stack-clash
> > > probing interval is equal to the guard size.
> > >
> > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> > > Target was tested with stack clash on and off by default.
> > >
> > > Ok for trunk?
> > >
> > > Thanks,
> > > Tamar
> > >
> > > gcc/
> > > 2018-07-11  Tamar Christina  
> > >
> > >   PR target/86486
> > >   * config/aarch64/aarch64.c (aarch64_override_options_internal):
> > >   Add validation for stack-clash parameters.
> > >
> > > --
> 
> > diff --git a/gcc/config/aarch64/aarch64.c
> > b/gcc/config/aarch64/aarch64.c index
> >
> e2c34cdfc96a1d3f99f7e4834c66a7551464a518..30c62c406e10793fe041d54c733
> 1
> > 6a6c8d7c229f 100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/aarch64/aarch64.c
> > @@ -10916,6 +10916,37 @@ aarch64_override_options_internal (struct
> gcc_options *opts)
> >  opts->x_param_values,
> >  global_options_set.x_param_values);
> >
> > +  /* If the user hasn't change it via configure then set the default
> > + to 64 KB
> 
> s/change/changed/
> 
> > + for the backend.  */
> > +  maybe_set_param_value
> (PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE,
> > +DEFAULT_STK_CLASH_GUARD_SIZE == 0
> > +  ? 16 : DEFAULT_STK_CLASH_GUARD_SIZE,
> > +opts->x_param_values,
> > +global_options_set.x_param_values);
> > +
> > +  /* Validate the guard size.  */
> > +  int guard_size = PARAM_VALUE
> > + (PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE);
> > +  if (guard_size != 12 && guard_size != 16)
> > +  error ("only values 12 (4 KB) and 16 (64 KB) are supported for guard 
> > "
> 
> Formatting is wrong, two spaces to indent error.
> 
> > +"size.  Given value %d (%llu KB) is out of range.\n",
> 
> No \n on errors. s/out of range/invalid/
> 
> > +guard_size, (1ULL << guard_size) / 1024ULL);
> > +
> > +  /* Enforce that interval is the same size as size so the mid-end does the
> > + right thing.  */
> > +  maybe_set_param_value
> (PARAM_STACK_CLASH_PROTECTION_PROBE_INTERVAL,
> > +guard_size,
> > +opts->x_param_values,
> > +global_options_set.x_param_values);
> > +
> > +  /* The maybe_set calls won't update the value if the user has explicitly
> set
> > + one.  Which means we need to validate that probing interval and guard
> size
> > + are equal.  */
> > +  int probe_interval
> > += PARAM_VALUE
> (PARAM_STACK_CLASH_PROTECTION_PROBE_INTERVAL);
> > +  if (guard_size != probe_interval)
> > +error ("stack clash guard size '%d' must be equal to probing interval "
> > +  "'%d'\n", guard_si

RE: [PATCH][GCC][mid-end] Add a hook to support telling the mid-end when to probe the stack [patch (2/6)]

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: Jeff Law 
> Sent: Wednesday, July 11, 2018 19:53
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de; i...@airs.com
> Subject: Re: [PATCH][GCC][mid-end] Add a hook to support telling the mid-
> end when to probe the stack [patch (2/6)]
> 
> On 07/11/2018 05:21 AM, Tamar Christina wrote:
> > Hi All,
> >
> > This patch adds a hook to tell the mid-end about the probing
> > requirements of the target.  On AArch64 we allow a specific range for
> > which no probing needs to be done.  This same range is also the amount
> > that will have to be probed up when a probe is needed after dropping the
> stack.
> >
> > Defining this probe comes with the extra requirement that the outgoing
> > arguments size of any function that uses alloca and stack clash be at
> > the very least 8 bytes.  With this invariant we can skip doing the
> > zero checks for alloca and save some code.
> >
> > A simplified version of the AArch64 stack frame is:
> >
> >+---+
> >|   |
> >|   |
> >|   |
> >+---+
> >|LR |
> >+---+
> >|FP |
> >+---+
> >|dynamic allocations| -\  probe range hook effects these
> >+---+   --\   and ensures that outgoing stack
> >|padding|  -- args is always > 8 when alloca.
> >+---+  ---/   Which means it's always safe to probe
> >|outgoing stack args|-/   at SP
> >+---+
> >
> >
> > This allows us to generate better code than without the hook without
> > affecting other targets.
> >
> > With this patch I am also removing the
> > stack_clash_protection_final_dynamic_probe
> > hook which was added specifically for AArch64 but that is no longer needed.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues.
> > Both targets were tested with stack clash on and off by default.
> >
> > Ok for trunk?
> >
> > Thanks,
> > Tamar
> >
> > gcc/
> > 2018-07-11  Tamar Christina  
> >
> > PR target/86486
> > * explow.c (anti_adjust_stack_and_probe_stack_clash): Support
> custom
> > probe ranges.
> > * target.def (stack_clash_protection_alloca_probe_range): New.
> > (stack_clash_protection_final_dynamic_probe): Remove.
> > * targhooks.h (default_stack_clash_protection_alloca_probe_range)
> New.
> > (default_stack_clash_protection_final_dynamic_probe): Remove.
> > * targhooks.c: Likewise.
> > * doc/tm.texi.in
> (TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE): New.
> > (TARGET_STACK_CLASH_PROTECTION_FINAL_DYNAMIC_PROBE):
> Remove.
> > * doc/tm.texi: Regenerate.
> >
> The control flow is a bit convoluted here, but after a few false starts where 
> I
> thought this was wrong, I think it's OK.
> 
> Jeff
> 
> 
> 
> 
> 
> 
> 
> 
> 

RE: [PATCH 8/8][GCC][AArch64] stack-clash: Add LR assert to layout_frame.

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org 
> On Behalf Of Tamar Christina
> Sent: Wednesday, September 26, 2018 09:30
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; James Greenhalgh ;
> Richard Earnshaw ; Marcus Shawcroft
> 
> Subject: [PATCH 8/8][GCC][AArch64] stack-clash: Add LR assert to
> layout_frame.
> 
> Hi All,
> 
> Since stack clash depends on the LR being saved for non-leaf functions this
> patch adds an assert such that if this changes we would notice this.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> This patch has been pre-approved by AArch64 maintainer here
>   https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00555.html
> and will be committed with the rest.
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
> 2018-09-26  Tamar Christina  
> 
>   * config/aarch64/aarch64.c (aarch64_layout_frame): Add assert.
> 
> --

RE: [PATCH][GCC][AArch64] Ensure that outgoing argument size is at least 8 bytes when alloca and stack-clash. [Patch (3/6)]

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: James Greenhalgh 
> Sent: Tuesday, August 7, 2018 17:18
> To: Tamar Christina 
> Cc: Jeff Law ; gcc-patches@gcc.gnu.org; nd
> ; Richard Earnshaw ; Marcus
> Shawcroft 
> Subject: Re: [PATCH][GCC][AArch64] Ensure that outgoing argument size is at
> least 8 bytes when alloca and stack-clash. [Patch (3/6)]
> 
> On Tue, Aug 07, 2018 at 05:09:34AM -0500, Tamar Christina wrote:
> > Hi All,
> >
> > This is a re-spin to address review comments. No code change aside from a
> variable rename.
> >
> > Ok for trunk?
> 
> OK.
> 
> Thanks,
> James
> 
> > gcc/
> > 2018-08-07  Tamar Christina  
> >
> > PR target/86486
> > * config/aarch64/aarch64.h
> (STACK_CLASH_MIN_BYTES_OUTGOING_ARGS,
> > STACK_DYNAMIC_OFFSET): New.
> > * config/aarch64/aarch64.c (aarch64_layout_frame):
> > Update outgoing args size.
> > (aarch64_stack_clash_protection_alloca_probe_range,
> > TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE):
> New.
> >
> > gcc/testsuite/
> > 2018-08-07  Tamar Christina  
> >
> > PR target/86486
> > * gcc.target/aarch64/stack-check-alloca-1.c: New.
> > * gcc.target/aarch64/stack-check-alloca-10.c: New.
> > * gcc.target/aarch64/stack-check-alloca-2.c: New.
> > * gcc.target/aarch64/stack-check-alloca-3.c: New.
> > * gcc.target/aarch64/stack-check-alloca-4.c: New.
> > * gcc.target/aarch64/stack-check-alloca-5.c: New.
> > * gcc.target/aarch64/stack-check-alloca-6.c: New.
> > * gcc.target/aarch64/stack-check-alloca-7.c: New.
> > * gcc.target/aarch64/stack-check-alloca-8.c: New.
> > * gcc.target/aarch64/stack-check-alloca-9.c: New.
> > * gcc.target/aarch64/stack-check-alloca.h: New.
> > * gcc.target/aarch64/stack-check-14.c: New.
> > * gcc.target/aarch64/stack-check-15.c: New.

RE: [PATCH][GCC][AArch64] Updated stack-clash implementation supporting 64k probes. [patch (1/7)]

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: James Greenhalgh 
> Sent: Tuesday, September 11, 2018 16:56
> To: Tamar Christina 
> Cc: Richard Sandiford ; Jeff Law
> ; gcc-patches@gcc.gnu.org; nd ; Richard
> Earnshaw ; Marcus Shawcroft
> 
> Subject: Re: [PATCH][GCC][AArch64] Updated stack-clash implementation
> supporting 64k probes. [patch (1/7)]
> 
> On Fri, Sep 07, 2018 at 11:03:28AM -0500, Tamar Christina wrote:
> > Hi Richard,
> >
> > The 08/28/2018 21:58, Richard Sandiford wrote:
> > > Tamar Christina  writes:
> > > > +  HOST_WIDE_INT guard_used_by_caller =
> STACK_CLASH_CALLER_GUARD;
> > > > +  /* When doing the final adjustment for the outgoing argument size
> we can't
> > > > + assume that LR was saved at position 0.  So subtract it's offset 
> > > > from
> the
> > > > + ABI safe buffer so that we don't accidentally allow an adjustment
> that
> > > > + would result in an allocation larger than the ABI buffer without
> > > > + probing.  */
> > > > +  HOST_WIDE_INT min_probe_threshold
> > > > += final_adjustment_p
> > > > +  ? guard_used_by_caller - cfun->machine-
> >frame.reg_offset[LR_REGNUM]
> > > > +  : guard_size - guard_used_by_caller;
> > > [...]
> > > > +  if (residual)
> > > > +{
> > > > +  aarch64_sub_sp (temp1, temp2, residual, frame_related_p);
> > > > +  if (residual >= min_probe_threshold)
> > > > +   {
> > > > + if (dump_file)
> > > > +   fprintf (dump_file,
> > > > +"Stack clash AArch64 prologue residuals: "
> > > > +HOST_WIDE_INT_PRINT_DEC " bytes, probing will be
> required."
> > > > +"\n", residual);
> > > > + emit_stack_probe (plus_constant (Pmode, stack_pointer_rtx,
> > > > +  STACK_CLASH_CALLER_GUARD));
> > >
> > > reg_offsets are nonnegative, so if LR_REGNUM isn't saved at position
> > > 0, min_probe_threshold will be less than STACK_CLASH_CALLER_GUARD.
> > > It looks like the probe would then write above the region.
> > >
> > > Using >= rather than > means that the same thing could happen when
> > > LR_REGNUM is at position 0, if the residual is exactly
> > > STACK_CLASH_CALLER_GUARD.
> >
> > That's true. While addressing this we changed how the residuals are
> probed.
> >
> > To address a comment you raised offline about the saving of LR when
> > calling a no-return function using a tail call and
> > -fomit-frame-pointer, I think this should be safe as the code in
> frame_layout (line 4131-4136) would ensure that R30 is saved.
> >
> > I have added two new tests to check for this, so that if it does
> > change in the future they would fail.
> >
> > Attached is the updated patch and new changelog
> >
> > Ok for trunk?
> 
> I'm happy with this patch version; I'd have preferred a FORNOW comment on
> this:
> 
> > +  /* If SIZE is not large enough to require probing, just adjust the stack 
> > and
> > + exit.  */
> > +  if (!poly_size.is_constant (&size)
> > +  || known_lt (poly_size, min_probe_threshold)
> > +  || !flag_stack_clash_protection)
> 
> as you don't fix it until 2/7, but that is a minor point.
> 
> I'm happy with you responding to Richard S' request for an assert either in
> this patch, or tacked on as an 8/7.
> 
> OK.
> 
> Thanks,
> James
> 
> > Thanks,
> > Tamar
> >
> > gcc/
> > 2018-09-07  Jeff Law  
> > Richard Sandiford 
> > Tamar Christina  
> >
> > PR target/86486
> > * config/aarch64/aarch64.md
> > (probe_stack_range): Add k (SP) constraint.
> > * config/aarch64/aarch64.h (STACK_CLASH_CALLER_GUARD,
> > STACK_CLASH_MAX_UNROLL_PAGES): New.
> > * config/aarch64/aarch64.c (aarch64_output_probe_stack_range):
> Emit
> > stack probes for stack clash.
> > (aarch64_allocate_and_probe_stack_space): New.
> > (aarch64_expand_prologue): Use it.
> > (aarch64_expand_epilogue): Likewise and update IP regs re-use
> criteria.
> > (aarch64_sub_sp): Add emit_move_imm optional param.
> >
> > gcc/testsuite/
> > 2018-09-07  Jeff Law  
> > Richard Sandiford 
> > Tamar Christina  
> >
> > PR target/86486
> > * gcc.target/aarch64/stack-check-12.c: New.
> > * gcc.target/aarch64/stack-check-13.c: New.
> > * gcc.target/aarch64/stack-check-cfa-1.c: New.
> > * gcc.target/aarch64/stack-check-cfa-2.c: New.
> > * gcc.target/aarch64/stack-check-prologue-1.c: New.
> > * gcc.target/aarch64/stack-check-prologue-10.c: New.
> > * gcc.target/aarch64/stack-check-prologue-11.c: New.
> > * gcc.target/aarch64/stack-check-prologue-12.c: New.
> > * gcc.target/aarch64/stack-check-prologue-13.c: New.
> > * gcc.target/aarch64/stack-check-prologue-14.c: New.
> > * gcc.target/aarch64/stack-check-prologue-15.c: New.
> > * gcc.target/aarch64/stack-check-prologue-2.c: New.
> > * gcc.target/

RE: [PATCH][GCC][AArch64] Add support for SVE stack clash probing [patch (2/7)]

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: Richard Sandiford 
> Sent: Friday, September 28, 2018 18:18
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ; James Greenhalgh
> ; Richard Earnshaw
> ; Marcus Shawcroft
> 
> Subject: Re: [PATCH][GCC][AArch64] Add support for SVE stack clash probing
> [patch (2/7)]
> 
> Tamar Christina  writes:
> > Hi Richard,
> >
> > Here's the updated patch with all the feedback processed.
> >
> > I have also run the compile tests through with -mabi=ilp32 as well.
> >
> > Ok for trunk?
> 
> OK.  Thanks for your patience through all the reviews.
> 
> Richard

Re: introduce --enable-mingw-full32 to default to --large-address-aware

[Alexandre Oliva]

On Oct  5, 2018, Joseph Myers  wrote:

> A new configure option needs documenting in install.texi.

Ah, yes, thanks for the reminder.

On Oct  6, 2018, JonY <10wa...@gmail.com> wrote:

> They're both OK as far as I can see. I just don't like the configure
> name implying all 32bit pointers are used by userspace. Perhaps just
> --enable-large-address-aware?

That might suggest the flag affects all targets, including Cygwin, so
I'm following the existing (undocumented) practice in suggesting
--enable-mingw-large-address-aware instead.  Please let me know if you'd
rather not have mingw in the option name, and for it to affect (in the
--disable form) the Cygwin target as well.

> Be sure to also update the documentation as Joseph says.

*nod*, thanks.  Here's the patch I'm testing now.  Ok to install?

Add a configure knob for mingw32 and 64 toolchains to default passing
--large-address-aware to the linker, when creating 32-bit binaries.
-Wl,--disable-large-address-aware can still reverse its effects.

for  gcc/ChangeLog

* configure.ac: Introduce --enable-mingw-large-address-aware
to define MINGW_DEFAULT_LARGE_ADDR_AWARE.
* doc/install.texi: Document it.
* configure, config.in: Rebuilt.
* config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define,
based on MINGW_DEFAULT_LARGE_ADDR_AWARE.
(LINK_SPEC): Insert it.
* config/i386/mingw-264.h: Likewise.
---
 gcc/config.in   |6 ++
 gcc/config/i386/mingw-w64.h |9 +
 gcc/config/i386/mingw32.h   |8 
 gcc/configure   |   18 --
 gcc/configure.ac|7 +++
 gcc/doc/install.texi|8 
 6 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/gcc/config.in b/gcc/config.in
index 4db8aa1ea154..44c3d04ab83c 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1986,6 +1986,12 @@
 #endif
 
 
+/* Define if we should link with --large-address-aware by default */
+#ifndef USED_FOR_TARGET
+#undef MINGW_DEFAULT_LARGE_ADDR_AWARE
+#endif
+
+
 /* Value to set mingw's _dowildcard to. */
 #ifndef USED_FOR_TARGET
 #undef MINGW_DOWILDCARD
diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h
index 484dc7a9e9f2..00b3f042a36c 100644
--- a/gcc/config/i386/mingw-w64.h
+++ b/gcc/config/i386/mingw-w64.h
@@ -81,6 +81,14 @@ along with GCC; see the file COPYING3.  If not see
 #define MULTILIB_DEFAULTS { "m32" }
 #endif
 
+#undef LINK_SPEC_LARGE_ADDR_AWARE
+#if MINGW_DEFAULT_LARGE_ADDR_AWARE
+# define LINK_SPEC_LARGE_ADDR_AWARE \
+  "%{!shared:%{!mdll:%{" SPEC_32 ":--large-address-aware}}}"
+#else
+# define LINK_SPEC_LARGE_ADDR_AWARE ""
+#endif
+
 #undef LINK_SPEC
 #define LINK_SPEC SUB_LINK_SPEC " %{mwindows:--subsystem windows} \
   %{mconsole:--subsystem console} \
@@ -88,4 +96,5 @@ along with GCC; see the file COPYING3.  If not see
   %{shared: --shared} %{mdll:--dll} \
   %{static:-Bstatic} %{!static:-Bdynamic} \
   %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \
+  " LINK_SPEC_LARGE_ADDR_AWARE "\
   %(shared_libgcc_undefs)"
diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
index a66010894208..c9d8a7a31f30 100644
--- a/gcc/config/i386/mingw32.h
+++ b/gcc/config/i386/mingw32.h
@@ -114,12 +114,20 @@ along with GCC; see the file COPYING3.  If not see
 #define SUBTARGET_EXTRA_SPECS  \
   { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC }
 
+#if MINGW_DEFAULT_LARGE_ADDR_AWARE
+# define LINK_SPEC_LARGE_ADDR_AWARE \
+  "%{!shared:%{!mdll:--large-address-aware}}"
+#else
+# define LINK_SPEC_LARGE_ADDR_AWARE ""
+#endif
+
 #define LINK_SPEC "%{mwindows:--subsystem windows} \
   %{mconsole:--subsystem console} \
   %{shared: %{mdll: %eshared and mdll are not compatible}} \
   %{shared: --shared} %{mdll:--dll} \
   %{static:-Bstatic} %{!static:-Bdynamic} \
   %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \
+  " LINK_SPEC_LARGE_ADDR_AWARE "\
   %(shared_libgcc_undefs)"
 
 /* Include in the mingw32 libraries with libgcc */
diff --git a/gcc/configure b/gcc/configure
index 9fb0eb57a8a1..17eb8d9a6154 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -927,6 +927,7 @@ enable_sjlj_exceptions
 with_gcc_major_version_only
 enable_secureplt
 enable_mingw_wildcard
+enable_mingw_large_address_aware
 enable_leading_mingw64_underscores
 enable_cld
 enable_frame_pointer
@@ -1644,6 +1645,8 @@ Optional Features:
   --enable-secureplt  enable -msecure-plt by default for PowerPC
   --enable-mingw-wildcard Set whether to expand wildcard on command-line.
   Default to platform configuration
+  --enable-mingw-large-address-aware
+  Link mingw executables with --large-address-aware
   --enable-leading-mingw64-underscores
   enable leading underscores on 64 bit mingw targets
   --enable-cldenable -mcld by default for 32bit x86
@@ -12005,6 +12008,17 @@ _ACEOF
 
 fi
 
+# Che

[PATCH] Make std::list::iterator == and != global inline friend

[François Dumont]

As we talked one day I would like to make all iterator operators global 
for consistency. So here is the patch to do so for std::list iterators.


Thanks to this change the operators ==(iterator, const_iterator) and != 
are not necessary anymore, one less ==|!= operator candidate.


    * include/bits/stl_list.h
    (_List_operator<>::operator==): Make global inline friend.
    (_List_operator<>::operator!=): Likewise.
    (_List_const_operator<>::operator==): Likewise.
    (_List_const_operator<>::operator!=): Likewise.
    (operator==(const _List_iterator<>&, const _List_const_iterator<>&)):
    Remove.
    (operator!=(const _List_iterator<>&, const _List_const_iterator<>&)):
    Remove.

Tested under Linux x86_64.

Ok to commit ?

François
diff --git a/libstdc++-v3/include/bits/stl_list.h b/libstdc++-v3/include/bits/stl_list.h
index 47749142e0e..3544981698c 100644
--- a/libstdc++-v3/include/bits/stl_list.h
+++ b/libstdc++-v3/include/bits/stl_list.h
@@ -243,13 +243,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 	return __tmp;
   }
 
-  bool
-  operator==(const _Self& __x) const _GLIBCXX_NOEXCEPT
-  { return _M_node == __x._M_node; }
+  friend bool
+  operator==(const _Self& __x, const _Self& __y) _GLIBCXX_NOEXCEPT
+  { return __x._M_node == __y._M_node; }
 
-  bool
-  operator!=(const _Self& __x) const _GLIBCXX_NOEXCEPT
-  { return _M_node != __x._M_node; }
+  friend bool
+  operator!=(const _Self& __x, const _Self& __y) _GLIBCXX_NOEXCEPT
+  { return __x._M_node != __y._M_node; }
 
   // The only member points to the %list element.
   __detail::_List_node_base* _M_node;
@@ -327,30 +327,18 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 	return __tmp;
   }
 
-  bool
-  operator==(const _Self& __x) const _GLIBCXX_NOEXCEPT
-  { return _M_node == __x._M_node; }
+  friend bool
+  operator==(const _Self& __x, const _Self& __y) _GLIBCXX_NOEXCEPT
+  { return __x._M_node == __y._M_node; }
 
-  bool
-  operator!=(const _Self& __x) const _GLIBCXX_NOEXCEPT
-  { return _M_node != __x._M_node; }
+  friend bool
+  operator!=(const _Self& __x, const _Self& __y) _GLIBCXX_NOEXCEPT
+  { return __x._M_node != __y._M_node; }
 
   // The only member points to the %list element.
   const __detail::_List_node_base* _M_node;
 };
 
-  template
-inline bool
-operator==(const _List_iterator<_Val>& __x,
-	   const _List_const_iterator<_Val>& __y) _GLIBCXX_NOEXCEPT
-{ return __x._M_node == __y._M_node; }
-
-  template
-inline bool
-operator!=(const _List_iterator<_Val>& __x,
-	   const _List_const_iterator<_Val>& __y) _GLIBCXX_NOEXCEPT
-{ return __x._M_node != __y._M_node; }
-
 _GLIBCXX_BEGIN_NAMESPACE_CXX11
   /// See bits/stl_deque.h's _Deque_base for an explanation.
   template

[PATCH] __debug::list use C++11 direct initialization

[François Dumont]

Here is the communication for my yesterday's patch which I thought svn 
had failed to commit (I had to interrupt it).


Similarly to what I've done for associative containers here is a cleanup 
of the std::__debug::list implementation leveraging more on C++11 direct 
initialization.


I also made sure we use consistent comparison between 
iterator/const_iterator in erase and emplace methods.


2018-10-08  François Dumont 

    * include/debug/list (list<>::cbegin()): Use C++11 direct
    initialization.
    (list<>::cend()): Likewise.
    (list<>::emplace<>(const_iterator, _Args&&...)): Likewise.
    (list<>::insert(const_iterator, initializer_list<>)): Likewise.
    (list<>::insert(const_iterator, size_type, const _Tp&)): Likewise.
    (list<>::erase(const_iterator, const_iterator)): Ensure consistent
    iterator comparisons.
    (list<>::splice(const_iterator, list&&, const_iterator,
    const_iterator)): Likewise.

Tested under Linux x86_64 Debug mode and committed.

François

diff --git a/libstdc++-v3/include/debug/list b/libstdc++-v3/include/debug/list
index 8add1d596e0..879e1177497 100644
--- a/libstdc++-v3/include/debug/list
+++ b/libstdc++-v3/include/debug/list
@@ -244,11 +244,11 @@ namespace __debug
 #if __cplusplus >= 201103L
   const_iterator
   cbegin() const noexcept
-  { return const_iterator(_Base::begin(), this); }
+  { return { _Base::begin(), this }; }
 
   const_iterator
   cend() const noexcept
-  { return const_iterator(_Base::end(), this); }
+  { return { _Base::end(), this }; }
 
   const_reverse_iterator
   crbegin() const noexcept
@@ -405,8 +405,8 @@ namespace __debug
 	emplace(const_iterator __position, _Args&&... __args)
 	{
 	  __glibcxx_check_insert(__position);
-	  return iterator(_Base::emplace(__position.base(),
-	std::forward<_Args>(__args)...), this);
+	  return  { _Base::emplace(__position.base(),
+   std::forward<_Args>(__args)...), this };
 	}
 #endif
 
@@ -430,7 +430,7 @@ namespace __debug
   insert(const_iterator __p, initializer_list __l)
   {
 	__glibcxx_check_insert(__p);
-	return iterator(_Base::insert(__p.base(), __l), this);
+	return { _Base::insert(__p.base(), __l), this };
   }
 #endif
 
@@ -439,7 +439,7 @@ namespace __debug
   insert(const_iterator __position, size_type __n, const _Tp& __x)
   {
 	__glibcxx_check_insert(__position);
-	return iterator(_Base::insert(__position.base(), __n, __x), this);
+	return { _Base::insert(__position.base(), __n, __x), this };
   }
 #else
   void
@@ -465,7 +465,7 @@ namespace __debug
 		_Base::insert(__position.base(),
 			  __gnu_debug::__unsafe(__first),
 			  __gnu_debug::__unsafe(__last)),
-		  this
+		this
 	  };
 	  else
 	return { _Base::insert(__position.base(), __first, __last), this };
@@ -521,15 +521,17 @@ namespace __debug
 	// _GLIBCXX_RESOLVE_LIB_DEFECTS
 	// 151. can't currently clear() empty container
 	__glibcxx_check_erase_range(__first, __last);
-	for (_Base_const_iterator __victim = __first.base();
+	for (__decltype(__first.base()) __victim = __first.base();
 	 __victim != __last.base(); ++__victim)
 	  {
-	_GLIBCXX_DEBUG_VERIFY(__victim != _Base::end(),
-  _M_message(__gnu_debug::__msg_valid_range)
-  ._M_iterator(__first, "position")
-  ._M_iterator(__last, "last"));
+	_GLIBCXX_DEBUG_VERIFY(
+		__victim != __first._M_get_sequence()->_M_base().end(),
+		_M_message(__gnu_debug::__msg_valid_range)
+		._M_iterator(__first, "position")
+		._M_iterator(__last, "last"));
 	this->_M_invalidate_if(_Equal(__victim));
 	  }
+
 	return iterator(_Base::erase(__first.base(), __last.base()), this);
   }
 
@@ -586,7 +588,7 @@ namespace __debug
 			  ._M_iterator(__i, "__i"));
 	_GLIBCXX_DEBUG_VERIFY(__i._M_attached_to(std::__addressof(__x)),
 			  _M_message(__gnu_debug::__msg_splice_other)
-			 ._M_iterator(__i, "__i")._M_sequence(__x, "__x"));
+			  ._M_iterator(__i, "__i")._M_sequence(__x, "__x"));
 
 	// _GLIBCXX_RESOLVE_LIB_DEFECTS
 	// 250. splicing invalidates iterators
@@ -620,19 +622,21 @@ namespace __debug
 	// We used to perform the splice_alloc check:  not anymore, redundant
 	// after implementing the relevant bits of N1599.
 
-	for (_Base_const_iterator __tmp = __first.base();
+	for (__decltype(__first.base()) __tmp = __first.base();
 	 __tmp != __last.base(); ++__tmp)
 	  {
-	_GLIBCXX_DEBUG_VERIFY(__tmp != _Base::end(),
-  _M_message(__gnu_debug::__msg_valid_range)
-  ._M_iterator(__first, "first")
-  ._M_iterator(__last, "last"));
+	_GLIBCXX_DEBUG_VERIFY(
+		__tmp != __first._M_get_sequence()->_M_base().end(),
+		_M_message(__gnu_debug::__msg_valid_range)
+		._M_iterator(__first, "first")
+		._M_iterator(__last, "last"));
 	_GLIBCXX_DEBUG_VERIFY(std::__addressof(__x) != this
   || __tmp != __position.base(),
 _M_message(__gnu_debug::__msg_splice_overlap)
   ._M_iterator(__tmp, "position")
   ._M_iterator(__first, "first"

[PING][PATCH] tighten up -Wclass-memaccess for ctors/dtors (PR 84851)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01528.html

I will go ahead and commit this as obvious this week if there
are no objections.

On 05/25/2018 02:20 PM, Martin Sebor wrote:

(I just now noticed the first two attempts were sent to the wrong
list.  Sorry about that.)

On 05/25/2018 02:16 PM, Martin Sebor wrote:

A fix for 84851 - missing -Wclass-memaccess for a memcpy in a copy
ctor with a non-trivial member was implemented but disabled for GCC
8 but because it was late, with the expectation we would enable it
for GCC 9.  The attached removes the code that guards the full fix
to enable it.

Martin

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Martin Sebor]

Attached is an updated patch with the INTEGRAL_TYPE_P test added
to detect constant non-integer arguments like (void*)0, and with
quoting made unconditional.  I also removed the pretty printer
business to avoid the "value%s" format, and modified the manual
to clarify when each of the attributes are applicable and what
their meaningful argument values are.

On 10/07/2018 04:38 PM, Martin Sebor wrote:

While still testing an enhancement in the area of attributes
I ran across bugs and inconsistencies in how different handlers
deal with positional arguments.  The bugs are either an ICE due
to the handlers not consistently converting positional arguments
to constants (i.e., CONST_DEL to INTEGER_CST in C++) for which
downstream code is unprepared (PR 87541), or errors for valid
code (PR 87542), or failing to diagnose invalid arguments.
The other inconsistencies are simply in responding to the same
invalid condition differently for different attributes .

The attached patch introduces a new function to do validate
positional arguments in a uniform way and replaces the existing
handling with it.

As a consequence of the handling being made consistent a number
of tests needed adjusting. In addition, some invalid arguments
that were previously rejected with a hard error are diagnosed
with just a warning (invalid argument values in attribute format),
and in one other instance what previously triggered a warning is
now accepted without one (attribute alloc_size on a function
without a prototype).  I'd be up tightening things up if that's
preferable as long it's done consistently.

Tested on x86_64-linux.

Martin

PS It would be nice to have a general policy for how to respond
to invalid attribute arguments (warning or error).  Even better,
it would be ideal to move the validation from the front-ends and
back-ends into the middle-end.  I.e., describe attribute arguments
in more detail in struct attribute_spec and have decl_attributes
validate nut just the number of arguments but also their types
and, when appropriate, expected values.


PR c++/87541 - ICE using a constant decl as an attribute alloc_size argument
PR c++/87542 - bogus error on attribute format with a named constant argument

gcc/ChangeLog:

	PR c++/87541
	PR c++/87542
	* tree.c (type_argument_type): New function.
	* tree.h (type_argument_type): Declare it.
	* gcc/doc/extend.texi (alloc_align): Update and clarify.
	(alloc_size, nonnull, sentinel): Same.

gcc/c-family/ChangeLog:

	PR c++/87541
	PR c++/87542
	* c-attribs.c (positional_argument): New function.
	(handle_alloc_size_attribute): Use it and simplify.
	(handle_alloc_align_attribute): Same.
	(handle_assume_aligned_attribute): Same.
	(handle_nonnull_attribute): Same.
	* c-common.c (check_function_arguments): Pass fntype to
	check_function_format.
	* c-common.h (check_function_format): Add an argument.
	(PosArgFlags, positional_argument): Declare new type and function.
	* c-format.c (decode_format_attr): Add arguments.
	(check_format_string, get_constant): Same.
	(convert_format_name_to_system_name): Adjust.

gcc/testsuite/ChangeLog:

	PR c++/87541
	PR c++/87542
	* g++.dg/ext/attr-alloc_size.C: New test.
	* c-c++-common/pr71574.c: Adjust diagnostics.
	* c-c++-common/attributes-1.c: Same.
	* gcc.dg/attr-alloc_align-2.c: Same.
	* gcc.dg/attr-alloc_align-4.c: New test.
	* gcc.dg/attr-alloc_size-2.c: Adjust diagnostics.
	* gcc.dg/attr-alloc_size.c: Same.
	* gcc.dg/attr-assume_aligned-4.c: New test.
	* gcc.dg/format/attr-3.c: Adjust diagnostics.
	* gcc.dg/nonnull-2.c: Same.
	* obj-c++.dg/attributes/method-format-1.mm: Same.
	* obj-c++.dg/attributes/method-nonnull-1.mm: Same.
	* objc.dg/attributes/method-format-1.m: same.
	* objc.dg/attributes/method-nonnull-1.m: Same.

Index: gcc/c-family/c-attribs.c
===
--- gcc/c-family/c-attribs.c	(revision 264941)
+++ gcc/c-family/c-attribs.c	(working copy)
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-iterator.h"
 #include "opts.h"
 #include "gimplify.h"
+#include "tree-pretty-print.h"
 
 static tree handle_packed_attribute (tree *, tree, tree, int, bool *);
 static tree handle_nocommon_attribute (tree *, tree, tree, int, bool *);
@@ -492,6 +493,188 @@ attribute_takes_identifier_p (const_tree attr_id)
 return targetm.attribute_takes_identifier_p (attr_id);
 }
 
+/* Verify that argument value POS at position ARGNO to attribute NAME
+   applied to function TYPE refers to a function parameter at position
+   POS and the expected type CODE.  If so, return POS after default
+   conversions, if any.  Otherwise, issue appropriate warnings and
+   return null.  A non-zero 1-based ARGNO should be passed ib by
+   callers only for attributes with more than one argument.  */
+
+tree
+positional_argument (const_tree fntype, const_tree atname, tree pos,
+		 tree_code code, int argno /* = 0 */,
+		 int flags /* = PosArgFlags () */)
+{
+  if (pos && TREE_CODE (pos) != 

Print column information in RTL dumps

[Eric Botcazou]

Now that -gcolum-info is the default, I think that it makes sense to print the 
column info in the RTL dumps to be able to find out where numbers come from.

Tested on x86_64-suse-linux, applied on the mainline.


2018-10-08  Eric Botcazou  

* print-rtl.c (rtx_writer::print_rtx_operand_code_i): Print column
information.


2018-10-08  Eric Botcazou  

* gcc.target/i386/vararg-loc.c: Accept a column number.

-- 
Eric BotcazouIndex: print-rtl.c
===
--- print-rtl.c	(revision 264863)
+++ print-rtl.c	(working copy)
@@ -398,7 +398,8 @@ rtx_writer::print_rtx_operand_code_i (co
   if (INSN_HAS_LOCATION (in_insn))
 	{
 	  expanded_location xloc = insn_location (in_insn);
-	  fprintf (m_outfile, " \"%s\":%i", xloc.file, xloc.line);
+	  fprintf (m_outfile, " \"%s\":%i:%i", xloc.file, xloc.line,
+		   xloc.column);
 	}
 #endif
 }
Index: testsuite/gcc.target/i386/vararg-loc.c
===
--- testsuite/gcc.target/i386/vararg-loc.c	(revision 264863)
+++ testsuite/gcc.target/i386/vararg-loc.c	(working copy)
@@ -23,5 +23,5 @@ f (int a, ...)			/* 8.  */
 }
 
 /* { dg-final { scan-rtl-dump-not "vararg-loc\\.c.:\[6789\] " "final" } } */
-/* { dg-final { scan-rtl-dump "vararg-loc\\.c.:18 " "final" } } */
-/* { dg-final { scan-rtl-dump "vararg-loc\\.c.:20 " "final" } } */
+/* { dg-final { scan-rtl-dump "vararg-loc\\.c.:18:\[0-9\]+ " "final" } } */
+/* { dg-final { scan-rtl-dump "vararg-loc\\.c.:20:\[0-9\]+ " "final" } } */

Re: [Patch, regrename] Fix PR87330 : ICE in scan_rtx_reg, at regrename.c

[Eric Botcazou]

> Other notes need not be changed, as they don't hold renamed register
> information.
> 
> Ok for trunk?

No, REG_DEAD & REG_UNUSED note must be recomputed by passes consuming them.

> 2018-10-09 Sameera Deshpande  
> * gcc/regrename.c (regrename_do_replace): Add condition to alter
> regname if note has same register marked dead in notes.

No gcc/ prefix in gcc/ChangeLog.

-- 
Eric Botcazou

[Patch, regrename] Fix PR87330 : ICE in scan_rtx_reg, at regrename.c

[Sameera Deshpande]

Hi!

Please find attached the patch fixing the issue PR87330 : ICE in
scan_rtx_reg, at regrename.c:1097.
The regrename pass does not rename the registers which are in notes,
because of which the REG_DEAD note had previous register names, which
caused conflicting liveness information generated for tag collision
pass.

It is better to do it in regrename_do_replace instead while
regrename_analyze, because the note information does not really
contribute into the regrename analysis, hence need not be added in the
def-use chains that are computed. regrename_do_replace is where the
decision to finally rename the register is made - where the note can
be altered with new regname.

Other notes need not be changed, as they don't hold renamed register
information.

Ok for trunk?

Changelog:

2018-10-09 Sameera Deshpande diff --git a/gcc/regrename.c b/gcc/regrename.c
index 8424093..a3446a2 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -970,6 +970,7 @@ regrename_do_replace (struct du_head *head, int reg)
   unsigned int regno = ORIGINAL_REGNO (*chain->loc);
   struct reg_attrs *attr = REG_ATTRS (*chain->loc);
   int reg_ptr = REG_POINTER (*chain->loc);
+  rtx note;
 
   if (DEBUG_INSN_P (chain->insn) && REGNO (*chain->loc) != base_regno)
 	validate_change (chain->insn, &(INSN_VAR_LOCATION_LOC (chain->insn)),
@@ -986,6 +987,11 @@ regrename_do_replace (struct du_head *head, int reg)
 	  last_reg = *chain->loc;
 	}
 	  validate_change (chain->insn, chain->loc, last_repl, true);
+	  note = find_regno_note (chain->insn, REG_DEAD, base_regno);
+	  if (note != 0)
+	{
+	  validate_change (chain->insn, &XEXP (note, 0), last_repl, true);
+	}
 	}
 }
 

Re: [Patch, fortran] PR87151 - allocating array of character

[Thomas Koenig]

Hi Paul,


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


OK.

Thanks for the patch!

Regards

Thomas

Re: [Patch, Fortran] PR fortran/83522 – reject array-valued substrings

[Thomas Koenig]

Hi Tobias,

nice to hear from you again!


Build and regtested on x86_64-linux.
OK for the trunk?


OK. Thanks for the patch!

Regards

Thomas

Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections

[Eric Botcazou]

> Besides, the patch seems to have produced more fallout on Solaris: I see
> many new Go testsuite failures on Solaris 10 which probably are related,
> and Solaris bootstrap with Ada included is broken due to the extended
> usage of string merging.  I'm currently investigating what's going on
> there.

I can bootstrap on SPARC/Solaris 10 and 11 (GNU as and system linker) but I 
have regressions on Solaris 11 (and not 10) under the form of SIGBUSes:

=== acats tests ===
FAIL:   c34005g
FAIL:   c35508c
FAIL:   ce3602d
FAIL:   cxa4005
FAIL:   ee3412c

FAIL: gfortran.dg/allocatable_function_5.f90   -O1  execution test
FAIL: gfortran.dg/allocatable_function_5.f90   -O2  execution test
FAIL: gfortran.dg/allocatable_function_5.f90   -O3 -fomit-frame-pointer -
funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/allocatable_function_5.f90   -O3 -g  execution test
FAIL: gfortran.dg/allocatable_function_5.f90   -Os  execution test
FAIL: gfortran.dg/char_allocation_1.f90   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/char_allocation_1.f90   -O1  compilation failed to 
produce executable
FAIL: gfortran.dg/char_allocation_1.f90   -O2  (test for excess errors)
UNRESOLVED: gfortran.dg/char_allocation_1.f90   -O2  compilation failed to 
produce executable
FAIL: gfortran.dg/char_allocation_1.f90   -O3 -fomit-frame-pointer -funroll-
loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)
UNRESOLVED: gfortran.dg/char_allocation_1.f90   -O3 -fomit-frame-pointer -
funroll-loops -fpeel-loops -ftracer -finline-functions  compilation failed to 
produce executable
FAIL: gfortran.dg/char_allocation_1.f90   -O3 -g  (test for excess errors)
UNRESOLVED: gfortran.dg/char_allocation_1.f90   -O3 -g  compilation failed to 
produce executable
FAIL: gfortran.dg/char_pointer_assign_3.f90   -O2  execution test
FAIL: gfortran.dg/char_pointer_assign_3.f90   -O3 -fomit-frame-pointer -
funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/char_pointer_assign_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/implied_do_io_2.f90   -Os  execution test
FAIL: gfortran.dg/namelist_38.f90   -O2  execution test
FAIL: gfortran.dg/namelist_38.f90   -O3 -fomit-frame-pointer -funroll-loops -
fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/namelist_38.f90   -O3 -g  execution test
FAIL: gfortran.dg/namelist_70.f90   -O1  execution test
FAIL: gfortran.dg/namelist_70.f90   -O2  execution test
FAIL: gfortran.dg/namelist_70.f90   -O3 -fomit-frame-pointer -funroll-loops -
fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/namelist_70.f90   -O3 -g  execution test
FAIL: gfortran.dg/namelist_70.f90   -Os  execution test
FAIL: gfortran.dg/nan_6.f90   -O1  execution test
FAIL: gfortran.dg/realloc_on_assign_4.f03   -O1  execution test
FAIL: gfortran.dg/realloc_on_assign_4.f03   -O2  execution test
FAIL: gfortran.dg/realloc_on_assign_4.f03   -O3 -fomit-frame-pointer -funroll-
loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/realloc_on_assign_4.f03   -O3 -g  execution test
FAIL: gfortran.dg/realloc_on_assign_4.f03   -Os  execution test
FAIL: gfortran.dg/streamio_14.f90   -O2  execution test
FAIL: gfortran.dg/streamio_14.f90   -O3 -fomit-frame-pointer -funroll-loops -
fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/streamio_14.f90   -O3 -g  execution test
FAIL: gfortran.dg/substr_7.f90   -O  (test for excess errors)
UNRESOLVED: gfortran.dg/substr_7.f90   -O  compilation failed to produce 
executable
FAIL: gfortran.dg/widechar_2.f90   -O1  execution test
FAIL: gfortran.dg/widechar_2.f90   -Os  execution test
FAIL: gfortran.fortran-torture/execute/adjustr.f90 execution,  -Os

FAIL: go.test/test/fixedbugs/issue4562.go execution,  -O2 -g 
FAIL: go.test/test/nil.go execution,  -O2 -g

-- 
Eric Botcazou

Re: [PING] [PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html

As with the other patch (bug 84561), there may be ways to redesign
the warning, but I don't have the cycles to undertake it before
stage 1 ends.  Unless someone has a simpler suggestion for how
to avoid this false positive now can we please accept this patch
for GCC 9 and consider the more ambitious approaches for GCC 10?

On 10/01/2018 03:24 PM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html

On 09/21/2018 11:13 AM, Martin Sebor wrote:

On 09/17/2018 07:30 PM, Jeff Law wrote:

On 8/28/18 6:12 PM, Martin Sebor wrote:

Sadly, dstbase is the PARM_DECL for d.  That's where things are going
"wrong".  Not sure why you're getting the PARM_DECL in that case.
I'd
debug get_addr_base_and_unit_offset to understand what's going on.
Essentially you're getting different results of
get_addr_base_and_unit_offset in a case where they arguably should be
the same.


Probably get_attr_nonstring_decl has the same "mistake" and returns
the PARM_DECL instead of the SSA name pointer.  So we're comparing
apples and oranges here.


Returning the SSA_NAME_VAR from get_attr_nonstring_decl() is
intentional but the function need not (perhaps should not)
also set *REF to it.



Yeah:

/* If EXPR refers to a character array or pointer declared attribute
   nonstring return a decl for that array or pointer and set *REF to
   the referenced enclosing object or pointer.  Otherwise returns
   null.  */

tree
get_attr_nonstring_decl (tree expr, tree *ref)
{
  tree decl = expr;
  if (TREE_CODE (decl) == SSA_NAME)
{
  gimple *def = SSA_NAME_DEF_STMT (decl);

  if (is_gimple_assign (def))
{
  tree_code code = gimple_assign_rhs_code (def);
  if (code == ADDR_EXPR
  || code == COMPONENT_REF
  || code == VAR_DECL)
decl = gimple_assign_rhs1 (def);
}
  else if (tree var = SSA_NAME_VAR (decl))
decl = var;
}

  if (TREE_CODE (decl) == ADDR_EXPR)
decl = TREE_OPERAND (decl, 0);

  if (ref)
*ref = decl;

I see a lot of "magic" here again in the attempt to "propagate"
a nonstring attribute.


That's the function's purpose: to look for the attribute.  Is
there a better way to do this?


Note

foo (char *p __attribute__(("nonstring")))
{
  p = "bar";
  strlen (p); // or whatever is necessary to call
get_attr_nonstring_decl
}

is perfectly valid and p as passed to strlen is _not_ nonstring(?).


I don't know if you're saying that it should get a warning or
shouldn't.  Right now it doesn't because the strlen() call is
folded before we check for nonstring.

I could see an argument for diagnosing it but I suspect you
wouldn't like it because it would mean more warning from
the folder.  I could also see an argument against it because,
as you said, it's safe.

If you take the assignment to p away then a warning is issued,
and that's because p is declared with attribute nonstring.
That's also why get_attr_nonstring_decl looks at SSA_NAME_VAR.


I think in your code comparing bases you want to look at the
_original_
argument to the string function rather than what
get_attr_nonstring_decl
returned as ref.


I've adjusted get_attr_nonstring_decl() to avoid setting *REF
to SSA_NAME_VAR.  That let me remove the GIMPLE_NOP code from
the patch.  I've also updated the comment above SSA_NAME_VAR
to clarify its purpose per Jeff's comments.

Attached is an updated revision with these changes.

Martin

gcc-87028.diff

PR tree-optimization/87028 - false positive -Wstringop-truncation
strncpy with global variable source string
gcc/ChangeLog:

PR tree-optimization/87028
* calls.c (get_attr_nonstring_decl): Avoid setting *REF to
SSA_NAME_VAR.
* gimple-fold.c (gimple_fold_builtin_strncpy): Avoid folding
when statement doesn't belong to a basic block.
* tree.h (SSA_NAME_VAR): Update comment.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Simplify.

gcc/testsuite/ChangeLog:

PR tree-optimization/87028
* c-c++-common/Wstringop-truncation.c: Remove xfails.
* gcc.dg/Wstringop-truncation-5.c: New test.




Index: gcc/calls.c
===
--- gcc/calls.c(revision 263928)
+++ gcc/calls.c(working copy)
@@ -1503,6 +1503,7 @@ tree
 get_attr_nonstring_decl (tree expr, tree *ref)
 {
   tree decl = expr;
+  tree var = NULL_TREE;
   if (TREE_CODE (decl) == SSA_NAME)
 {
   gimple *def = SSA_NAME_DEF_STMT (decl);
@@ -1515,17 +1516,25 @@ get_attr_nonstring_decl (tree expr, tree *ref)
   || code == VAR_DECL)
 decl = gimple_assign_rhs1 (def);
 }
-  else if (tree var = SSA_NAME_VAR (decl))
-decl = var;
+  else
+var = SSA_NAME_VAR (decl);
 }

   if (TREE_CODE (decl) == ADDR_EXPR)
 decl = TREE_OPERAND (decl, 0);

+  /* To simplify calling code, store the referenced DECL regardless of
+ the attribute determined below, but avoid storing the
SSA_N

[PING #2] [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01934.html

On 10/01/2018 03:30 PM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01934.html

We have discussed a number of different approaches to moving
the warning somewhere else but none is feasible in the limited
amount of time remaining in stage 1 of GCC 9.  I'd like to
avoid the false positive in GCC 9 by using the originally
submitted, simple approach and look into the suggested design
changes for GCC 10.

On 09/21/2018 08:36 AM, Martin Sebor wrote:

On 09/20/2018 03:06 AM, Richard Biener wrote:

On Wed, Sep 19, 2018 at 4:19 PM Martin Sebor  wrote:


On 09/18/2018 10:23 PM, Jeff Law wrote:

On 9/18/18 1:46 PM, Martin Sebor wrote:

On 09/18/2018 12:58 PM, Jeff Law wrote:

On 9/18/18 11:12 AM, Martin Sebor wrote:


My bad.  Sigh. CCP doesn't track copies, just constants, so
there's not
going to be any data structure you can exploit.  And I don't think
there's a value number you can use to determine the two objects
are the
same.

Hmm, let's back up a bit, what is does the relevant part of the
IL look
like before CCP?  Is the real problem here that we have
unpropagated
copies lying around in the IL?  Hmm, more likely the IL looksl
ike:

   _8 = &pb_3(D)->a;
   _9 = _8;
   _1 = _9;
   strncpy (MEM_REF (&pb_3(D)->a), ...);
   MEM[(struct S *)_1].a[n_7] = 0;


Yes, that is what the folder sees while the strncpy call is
being transformed/folded by ccp.  The MEM_REF is folded just
after the strncpy call and that's when it's transformed into

  MEM[(struct S *)_8].a[n_7] = 0;

(The assignments to _1 and _9 don't get removed until after
the dom walk finishes).



If we were to propagate the copies out we'd at best have:

   _8 = &pb_3(D)->a;
   strncpy (MEM_REF (&pb_3(D)->a), ...);
   MEM[(struct S *)_8].a[n_7] = 0;


Is that in a form you can handle?  Or would we also need to
forward
propagate the address computation into the use of _8?


The above works as long as we look at the def_stmt of _8 in
the MEM_REF (we currently don't).  That's also what the last
iteration of the loop does.  In this case (with _8) it would
be discovered in the first iteration, so the loop could be
replaced by a simple if statement.

But I'm not sure I understand the concern with the loop.  Is
it that we are looping at all, i.e., the cost?  Or that ccp
is doing something wrong or suboptimal? (Should have
propagated the value of _8 earlier?)

I suspect it's more a concern that things like copies are typically
propagated away.   So their existence in the IL (and consequently
your
need to handle them) raises the question "has something else
failed to
do its job earlier".

During which of the CCP passes is this happening?  Can we pull the
warning out of the folder (even if that means having a distinct
warning
pass over the IL?)


It happens during the third run of the pass.

The only way to do what you suggest that I could think of is
to defer the strncpy to memcpy transformation until after
the warning pass.  That was also my earlier suggestion: defer
both it and the warning until the tree-ssa-strlen pass (where
the warning is implemented to begin with -- the folder calls
into it).

If it's happening that late (CCP3) in general, then ISTM we ought
to be
able to get the warning out of the folder.  We just have to pick the
right spot.

warn_restrict runs before fold_all_builtins, but after dom/vrp so we
should have the IL in pretty good shape.  That seems like about the
right time.

I wonder if we could generalize warn_restrict to be a more generic
warning pass over the IL and place it right before fold_builtins.


The restrict pass doesn't know about string lengths so it can't
handle all the warnings about string built-ins (the strlen pass
now calls into it to issue some).  The strlen pass does so it
could handle most if not all of them (the folder also calls
into it to issue some warnings).  It would work even better if
it were also integrated with the object size pass.

We're already working on merging strlen with sprintf.  It seems
to me that the strlen pass would benefit not only from that but
also from integrating with object size and warn-restrict.  With
that, -Wstringop-overflow could be moved from builtins.c into
it as well (and also benefit not only from accurate string
lengths but also from the more accurate object size info).

What do you think about that?


I think integrating the various "passes" (objectsize is also
as much a facility as a pass) generally makes sense given
it might end up improving all of them and reduce code duplication.


Okay.  If Jeff agrees I'll see if I can make it happen for GCC
10.  Until then, does either of you have any suggestions for
a different approach in this patch or is it acceptable with
the loop as is?

Martin



Richard.



Martin

PS I don't think I could do more than merger strlen and sprintf
before stage 1 ends (if even that much) so this would be a longer
term goal.

[PATCH] Folding and check_function_arguments

[David Malcolm]

On Mon, 2018-10-08 at 10:37 -0400, Jason Merrill wrote:
> On Thu, Oct 4, 2018 at 10:12 AM David Malcolm 
> wrote:
> > 
> > -Wformat in the C++ FE doesn't work as well as it could:
> > (a) it doesn't report precise locations within the string literal,
> > and
> > (b) it doesn't underline arguments for those arguments
> > !CAN_HAVE_LOCATION_P,
> > despite having location wrapper nodes.
> > 
> > For example:
> > 
> >   Wformat-ranges.C:32:10: warning: format '%s' expects argument of
> > type 'char*', but argument 2 has type 'int' [-Wformat=]
> >   32 |   printf("hello %s", 42);
> >  |  ^~
> > 
> > (a) is due to not wiring up the langhook for extracting substring
> > locations.
> > 
> > This patch uses the one in c-family; it also fixes string
> > literal
> > parsing so that it records string concatenations (needed for
> > extracting substring locations from concatenated strings).
> > 
> > (b) is due to the call to maybe_constant_value here:
> >fargs[j] = maybe_constant_value (argarray[j]);
> > within build_over_call.
> 
> Maybe we should remove that in favor of fold_for_warn in
> check_function_arguments.
> 
> Jason

This patch eliminates the arglocs array I introduced to build_over_call
in r264887, and eliminates the call to maybe_constant_value when building
"fargs" (thus retaining location wrapper nodes).

Instead, this patch requires that any checks within
check_function_arguments that need folded arguments do their own folding.

Of the various checks:
(a) check_function_nonnull already calls fold_for_warn,
(b) check_function_format doesn't need folding
(c) check_function_sentinel needs fold_for_warn in one place, which the
patch adds, and
(d) check_function_restrict needs per-argument folding, which the patch
adds.  Given that it scans before and after resetting TREE_VISITED on
each argument, it seemed best to make a copy of the array, folding each
argument from the outset, rather than repeatedly calling fold_for_warn;

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?

gcc/c-family/ChangeLog:
PR c++/56856
* c-common.c (check_function_sentinel): Call fold_for_warn on the
argument.
(check_function_restrict): Rename param "argarray" to
"unfolded_argarray", and make a copy named "argarray", calling
fold_for_warn on each argument.
(check_function_arguments): Add note about responsibility for
folding the arguments.

gcc/cp/ChangeLog:
PR c++/56856
* call.c (build_over_call): Eliminate the "arglocs" array, and the
call to maybe_constant_value when building "fargs".
---
 gcc/c-family/c-common.c | 17 +
 gcc/cp/call.c   |  6 ++
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index c0198e1..11fa360 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5297,7 +5297,7 @@ check_function_sentinel (const_tree fntype, int nargs, 
tree *argarray)
}
 
   /* Validate the sentinel.  */
-  sentinel = argarray[nargs - 1 - pos];
+  sentinel = fold_for_warn (argarray[nargs - 1 - pos]);
   if ((!POINTER_TYPE_P (TREE_TYPE (sentinel))
   || !integer_zerop (sentinel))
  /* Although __null (in C++) is only an integer we allow it
@@ -5316,11 +5316,16 @@ check_function_sentinel (const_tree fntype, int nargs, 
tree *argarray)
 
 static bool
 check_function_restrict (const_tree fndecl, const_tree fntype,
-int nargs, tree *argarray)
+int nargs, tree *unfolded_argarray)
 {
   int i;
   tree parms = TYPE_ARG_TYPES (fntype);
 
+  /* Call fold_for_warn on all of the arguments.  */
+  auto_vec argarray (nargs);
+  for (i = 0; i < nargs; i++)
+argarray.quick_push (fold_for_warn (unfolded_argarray[i]));
+
   if (fndecl
   && TREE_CODE (fndecl) == FUNCTION_DECL)
 {
@@ -5357,7 +5362,7 @@ check_function_restrict (const_tree fndecl, const_tree 
fntype,
   if (POINTER_TYPE_P (type)
  && TYPE_RESTRICT (type)
  && !TYPE_READONLY (TREE_TYPE (type)))
-   warned |= warn_for_restrict (i, argarray, nargs);
+   warned |= warn_for_restrict (i, argarray.address (), nargs);
 }
 
   for (i = 0; i < nargs; i++)
@@ -5604,7 +5609,11 @@ attribute_fallthrough_p (tree attr)
 /* Check for valid arguments being passed to a function with FNTYPE.
There are NARGS arguments in the array ARGARRAY.  LOC should be used
for diagnostics.  Return true if either -Wnonnull or -Wrestrict has
-   been issued.  */
+   been issued.
+
+   The arguments in ARGARRAY may not have been folded yet (e.g. for C++,
+   to preserve location wrappers); checks that require folded arguments
+   should call fold_for_warn on them.  */
 
 bool
 check_function_arguments (location_t loc, const_tree fndecl, const_tree fntype,
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 747f837..51da771 10064

Re: [PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

[Martin Sebor]

On 10/08/2018 04:05 AM, Richard Biener wrote:

On Thu, Oct 4, 2018 at 5:51 PM Martin Sebor  wrote:


On 10/04/2018 08:58 AM, Jeff Law wrote:

On 8/27/18 9:42 AM, Richard Biener wrote:

On Mon, Aug 27, 2018 at 5:32 PM Jeff Law  wrote:


On 08/27/2018 02:29 AM, Richard Biener wrote:

On Sun, Aug 26, 2018 at 7:26 AM Jeff Law  wrote:


On 08/24/2018 09:58 AM, Martin Sebor wrote:

The warning suppression for -Wstringop-truncation looks for
the next statement after a truncating strncpy to see if it
adds a terminating nul.  This only works when the next
statement can be reached using the Gimple statement iterator
which isn't until after gimplification.  As a result, strncpy
calls that truncate their constant argument that are being
folded to memcpy this early get diagnosed even if they are
followed by the nul assignment:

  const char s[] = "12345";
  char d[3];

  void f (void)
  {
strncpy (d, s, sizeof d - 1);   // -Wstringop-truncation
d[sizeof d - 1] = 0;
  }

To avoid the warning I propose to defer folding strncpy to
memcpy until the pointer to the basic block the strnpy call
is in can be used to try to reach the next statement (this
happens as early as ccp1).  I'm aware of the preference to
fold things early but in the case of strncpy (a relatively
rarely used function that is often misused), getting
the warning right while folding a bit later but still fairly
early on seems like a reasonable compromise.  I fear that
otherwise, the false positives will drive users to adopt
other unsafe solutions (like memcpy) where these kinds of
bugs cannot be as readily detected.

Tested on x86_64-linux.

Martin

PS There still are outstanding cases where the warning can
be avoided.  I xfailed them in the test for now but will
still try to get them to work for GCC 9.

gcc-87028.diff


PR tree-optimization/87028 - false positive -Wstringop-truncation strncpy with 
global variable source string
gcc/ChangeLog:

  PR tree-optimization/87028
  * gimple-fold.c (gimple_fold_builtin_strncpy): Avoid folding when
  statement doesn't belong to a basic block.
  * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Handle MEM_REF on
  the left hand side of assignment.

gcc/testsuite/ChangeLog:

  PR tree-optimization/87028
  * c-c++-common/Wstringop-truncation.c: Remove xfails.
  * gcc.dg/Wstringop-truncation-5.c: New test.

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 07341eb..284c2fb 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -1702,6 +1702,11 @@ gimple_fold_builtin_strncpy (gimple_stmt_iterator *gsi,
   if (tree_int_cst_lt (ssize, len))
 return false;

+  /* Defer warning (and folding) until the next statement in the basic
+ block is reachable.  */
+  if (!gimple_bb (stmt))
+return false;

I think you want cfun->cfg as the test here.  They should be equivalent
in practice.


Please do not add 'cfun' references.  Note that the next stmt is also accessible
when there is no CFG.  I guess the issue is that we fold this during
gimplification where the next stmt is not yet "there" (but still in GENERIC)?

That was my assumption.  I almost suggested peeking at gsi_next and
avoiding in that case.


So I'd rather add guards to maybe_fold_stmt in the gimplifier then.

So I think the concern with adding the guards to maybe_fold_stmt is the
possibility of further fallout.

I guess they could be written to target this case specifically to
minimize fallout, but that feels like we're doing the same thing
(band-aid) just in a different place.







We generally do not want to have unfolded stmts in the IL when we can avoid that
which is why we fold most stmts during gimplification.  We also do that because
we now do less folding on GENERIC.

But an unfolded call in the IL should always be safe and we've got
plenty of opportunities to fold it later.


Well - we do.  The very first one is forwprop though which means we'll miss to
re-write some memcpy parts into SSA:

  NEXT_PASS (pass_ccp, false /* nonzero_p */);
  /* After CCP we rewrite no longer addressed locals into SSA
 form if possible.  */
  NEXT_PASS (pass_forwprop);

likewise early object-size will be confused by memcpy calls that just exist
to avoid TBAA issues (another of our recommendations besides using unions).

We do fold mem* early for a reason ;)

"We can always do warnings earlier" would be a similar true sentence.

I'm not disagreeing at all.  There's a natural tension between the
benefits of folding early to enable more optimizations downstream and
leaving the IL in a state where we can give actionable warnings.


Similar trade-offs between folding early and losing information
as a result also impact high-level optimizations.

For instance, folding the strlen argument below

   void f3 (struct A* p)
   {
 __builtin_strcpy (p->a, "123");

 if (__builtin_strlen (p->a + 1) != 2)   // not folded
   __builtin_abort ();
   }

into

   _2 = &MEM[(void *)p_4(D) + 2B];

Re: [C++ PATCH] Fix pretty-print of enumerator ids (PR c++/87364)

[Jason Merrill]

OK.
On Mon, Oct 8, 2018 at 1:12 PM will wray  wrote:
>
> Hi,
>
> A PR to fix Bug 87364 - Pretty print of enumerator never prints the id,
> always falls back to C-style cast output
>
> The fix is tested with the code attached to the bug report and additional
> usage over the past few weeks.
>
> Bootstrap and regtested on x86_64-linux. OK for trunk?
>
>
> 2018-10-08  Will Wray  
>
> PR c++/87364
> * c-pretty-print.c (pp_c_enumeration_constant): fix comparison.
> * cxx-pretty-print.c (pp_cxx_enumeration_constant): New; add
> nested-specifiers prefix to enum id plus enum type for scoped enum.
>
> Index: gcc/c-family/c-pretty-print.h
> ===
> --- gcc/c-family/c-pretty-print.h (revision 264938)
> +++ gcc/c-family/c-pretty-print.h (working copy)
> @@ -128,11 +128,13 @@ void pp_c_logical_or_expression (c_prett
>  void pp_c_expression_list (c_pretty_printer *, tree);
>  void pp_c_constructor_elts (c_pretty_printer *, vec va_gc> *);
>  void pp_c_call_argument_list (c_pretty_printer *, tree);
> +void pp_c_type_cast (c_pretty_printer *, tree);
>  void pp_c_cast_expression (c_pretty_printer *, tree);
>  void pp_c_init_declarator (c_pretty_printer *, tree);
>  void pp_c_ws_string (c_pretty_printer *, const char *);
>  void pp_c_identifier (c_pretty_printer *, const char *);
>  void pp_c_string_literal (c_pretty_printer *, tree);
> +void pp_c_integer_constant (c_pretty_printer *, tree);
>
>  void print_c_tree (FILE *file, tree t);
>
> Index: gcc/c-family/c-pretty-print.c
> ===
> --- gcc/c-family/c-pretty-print.c (revision 264938)
> +++ gcc/c-family/c-pretty-print.c (working copy)
> @@ -192,7 +192,7 @@ pp_c_cv_qualifiers (c_pretty_printer *pp
>
>  /* Pretty-print T using the type-cast notation '( type-name )'.  */
>
> -static void
> +void
>  pp_c_type_cast (c_pretty_printer *pp, tree t)
>  {
>pp_c_left_paren (pp);
> @@ -908,7 +908,7 @@ pp_c_void_constant (c_pretty_printer *pp
>
>  /* Pretty-print an INTEGER literal.  */
>
> -static void
> +void
>  pp_c_integer_constant (c_pretty_printer *pp, tree i)
>  {
>if (tree_fits_shwi_p (i))
> @@ -968,21 +968,20 @@ pp_c_bool_constant (c_pretty_printer *pp
>  pp_unsupported_tree (pp, b);
>  }
>
> -/* Attempt to print out an ENUMERATOR.  Return true on success.  Else
> return
> -   false; that means the value was obtained by a cast, in which case
> -   print out the type-id part of the cast-expression -- the casted value
> -   is then printed by pp_c_integer_literal.  */
> +/* Given a value e of ENUMERAL_TYPE:
> +   Print out the first ENUMERATOR id with value e, if one is found,
> +   else print out the value as a C-style cast (type-id)value.  */
>
> -static bool
> +static void
>  pp_c_enumeration_constant (c_pretty_printer *pp, tree e)
>  {
> -  bool value_is_named = true;
>tree type = TREE_TYPE (e);
>tree value;
>
>/* Find the name of this constant.  */
>for (value = TYPE_VALUES (type);
> -   value != NULL_TREE && !tree_int_cst_equal (TREE_VALUE (value), e);
> +   value != NULL_TREE
> +   && !tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e);
> value = TREE_CHAIN (value))
>  ;
>
> @@ -992,10 +991,8 @@ pp_c_enumeration_constant (c_pretty_prin
>  {
>/* Value must have been cast.  */
>pp_c_type_cast (pp, type);
> -  value_is_named = false;
> +  pp_c_integer_constant (pp, e);
>  }
> -
> -  return value_is_named;
>  }
>
>  /* Print out a REAL value as a decimal-floating-constant.  */
> @@ -1140,9 +1137,8 @@ c_pretty_printer::constant (tree e)
> pp_c_bool_constant (this, e);
>   else if (type == char_type_node)
> pp_c_character_constant (this, e);
> - else if (TREE_CODE (type) == ENUMERAL_TYPE
> - && pp_c_enumeration_constant (this, e))
> -   ;
> + else if (TREE_CODE (type) == ENUMERAL_TYPE)
> +   pp_c_enumeration_constant (this, e);
>   else
> pp_c_integer_constant (this, e);
>}
> Index: gcc/cp/cxx-pretty-print.c
> ===
> --- gcc/cp/cxx-pretty-print.c (revision 264938)
> +++ gcc/cp/cxx-pretty-print.c (working copy)
> @@ -294,6 +294,39 @@ pp_cxx_qualified_id (cxx_pretty_printer
>  }
>  }
>
> +/* Given a value e of ENUMERAL_TYPE:
> +   Print out the first ENUMERATOR id with value e, if one is found,
> +   (including nested names but excluding the enum name if unscoped)
> +   else print out the value as a C-style cast (type-id)value.  */
> +
> +static void
> +pp_cxx_enumeration_constant (cxx_pretty_printer *pp, tree e)
> +{
> +  tree type = TREE_TYPE (e);
> +  tree value;
> +
> +  /* Find the name of this constant.  */
> +  for (value = TYPE_VALUES (type);
> +   value != NULL_TREE
> +   && !tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e);
> +   value = TREE_CHAIN (value))
> +;
> +
> +  if (value != NULL_TREE)
> +{
> +  if (!ENUM_IS_SCOPED (type))
> + type = get_co

Re: [PATCH, rs6000] Fix PR86731 vec_sl()

[Segher Boessenkool]

On Mon, Oct 08, 2018 at 02:34:53PM -0500, Will Schmidt wrote:
> On Sat, 2018-08-25 at 12:46 -0500, Segher Boessenkool wrote:
> > Rest looks fine to me (whatever that means :-) )
> 
> I took that as an OK for trunk, so this (with whitespace adjustments as
> recommended) went into trunk via
>( https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=264150 )
> 
> Is this OK for backport to 8 ?

Yes, that is fine, please do.  Thanks!


Segher

[RFC][PATCH IRA] Fix PR87507, IRA unnecessarily uses non-volatile registers during register assignment

[Peter Bergner]

PR87507 shows a problem where IRA assigns a non-volatile TImode reg pair to
a pseudo when there is a volatile reg pair available to use.  This then
causes us to emit save/restore code for the non-volatile reg usage.

The problem here is that the only volatile reg pair that is available is an
odd/even reg pair (r7,r8) and ira-costs.c:ira_tune_allocno_costs() disparages
odd/even reg pairs by increasing their cost.  That's fine, but an even/odd
non-volatile reg pair should still be more expensive than an odd/even reg
pair given the save/restore that we'd need to use it.  However, the costs
used in assign_hard_reg() show that non-volatile reg pair (r30,r31) is
cheaper than odd/even reg pair (r7,r8) (15 versus 1000).  That's a huge
disparity in costs, so looking at where the non-volatile cost comes from,
it comes from the code below in ira-color.c:assign_hard_reg():

   if (!HONOR_REG_ALLOC_ORDER)
{
  if ((saved_nregs = calculate_saved_nregs (hard_regno, mode)) != 0)
  /* We need to save/restore the hard register in
 epilogue/prologue.  Therefore we increase the cost.  */
  {
rclass = REGNO_REG_CLASS (hard_regno);
add_cost = ((ira_memory_move_cost[mode][rclass][0]
 + ira_memory_move_cost[mode][rclass][1])
* saved_nregs / hard_regno_nregs (hard_regno,
  mode) - 1);
cost += add_cost;
full_cost += add_cost;
  }
}

I'm not sure I understand the "* saved_nregs / h_r_n (h_r, m) - 1" part
of the calculation.  If saved_nregs is the number of hard regs that
need to be saved for hard_regno in mode MODE (ie, we don't need to
save a hard reg if it's already been saved, etc.), then why aren't we
just multiplying by saved_nregs?  The other problem I see here is
that we're not scaling the cost by the basic block frequency of the
prologue/epilogue, which is what is causing the non-volatile reg
cost to be so low compared to the odd/even volatile reg use, which
is scaled.  However, even if I fix that, improve_allocation() comes
along and undoes it, because it too does not correctly compute the
cost of non-volatiles, so that seems to me that it needs fixing too.

I have the following work in progress patch I'd like some comments on.
Am I on the right track here?  I noticed that assign_hard_reg() tracks
min_cost and min_full_cost, but min_cost is actually never used for
anything other than setting min_cost, so I removed it.  I also don't
understand why we don't charge non-volatile usage for targets that define
HONOR_REG_ALLOC_ORDER.  Why shouldn't we always account for save/restore
of non-volatile reg usage?  I'll note I did not change that behavior.

Thoughts on the patch below?  Vlad, can you comment on some of my
questions above?

Peter


gcc/
PR rtl-optimization/87507
* ira-color.c (calculate_saved_nregs): Rename from this...
(calculate_saved_nregs_cost): ...to this.  Return cost of saving NREGS.
(assign_hard_reg):
(improve_allocation):

gcc/testsuite/
PR rtl-optimization/87507
* gcc.dg/pr10474.c: Don't XFAIL for powerpc*-*-*.
* gcc.target/powerpc/vsx-vector-6.p8.c: Update expected output.

Index: gcc/ira-color.c
===
--- gcc/ira-color.c (revision 264795)
+++ gcc/ira-color.c (working copy)
@@ -1648,11 +1648,10 @@ check_hard_reg_p (ira_allocno_t a, int h
   return j == nregs;
 }
 
-/* Return number of registers needed to be saved and restored at
-   function prologue/epilogue if we allocate HARD_REGNO to hold value
-   of MODE.  */
+/* Return the cost of saving and restoring HARD_REGNO in mode MODE at
+   function prologue and epilogue.  */
 static int
-calculate_saved_nregs (int hard_regno, machine_mode mode)
+calculate_saved_nregs_cost (int hard_regno, machine_mode mode)
 {
   int i;
   int nregs = 0;
@@ -1663,7 +1662,14 @@ calculate_saved_nregs (int hard_regno, m
&& !TEST_HARD_REG_BIT (call_used_reg_set, hard_regno + i)
&& !LOCAL_REGNO (hard_regno + i))
   nregs++;
-  return nregs;
+  if (nregs == 0)
+return 0;
+
+  enum reg_class rclass = REGNO_REG_CLASS (hard_regno);
+  return (ira_memory_move_cost[mode][rclass][0]
+ + ira_memory_move_cost[mode][rclass][1])
+* nregs
+* REG_FREQ_FROM_BB (ENTRY_BLOCK_PTR_FOR_FN (cfun));
 }
 
 /* Choose a hard register for allocno A.  If RETRY_P is TRUE, it means
@@ -1694,14 +1700,11 @@ assign_hard_reg (ira_allocno_t a, bool r
 {
   HARD_REG_SET conflicting_regs[2], profitable_hard_regs;
   int i, j, hard_regno, best_hard_regno, class_size;
-  int cost, mem_cost, min_cost, full_cost, min_full_cost, nwords, word;
+  int cost, mem_cost, full_cost, min_full_cost, nwords, word;
   int *a_costs;
   enum reg_class aclass;
   machine_mode mode;
-  static int costs[FIRST_PSEUDO_REGISTER], full_costs[FIRST_PSE

Re: [PATCH, rs6000] Fix PR86731 vec_sl()

[Will Schmidt]

On Sat, 2018-08-25 at 12:46 -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Aug 14, 2018 at 06:18:28PM -0500, Will Schmidt wrote:
> > PR target/86731
> > * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Update logic
> >   around folding of vec_sl() to handle out of range shift values.
> 
> Shouldn't indent continuation lines in changelog.
> 
> > +  {
> > +   location_t loc;
> > +   gimple_seq stmts = NULL;
> > +   arg0 = gimple_call_arg (stmt, 0);
> > +   tree arg0_type = TREE_TYPE (arg0);
> > +   if (INTEGRAL_TYPE_P (TREE_TYPE (arg0_type))
> > +   && !TYPE_OVERFLOW_WRAPS (TREE_TYPE (arg0_type)))
> > +   return false;
> 
>   if (INTEGRAL_TYPE_P (TREE_TYPE (arg0_type))
>   && !TYPE_OVERFLOW_WRAPS (TREE_TYPE (arg0_type)))
> return false;
> 
> > +/* { dg-final { scan-assembler-times 
> > {\mvspltisb\M|\mvspltish\M|\mvspltisw\M} 7 } } */
> 
> Maybe you want
> /* { dg-final { scan-assembler-times {\mvspltis[bhw]\M} 7 } } */
> instead?
> 
> Rest looks fine to me (whatever that means :-) )

I took that as an OK for trunk, so this (with whitespace adjustments as
recommended) went into trunk via
   ( https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=264150 )

Is this OK for backport to 8 ?

Thanks,
-Will

> 
> 
> Segher
> 

[gomp5] Fix task reduction handling in implicit parallel regions

[Jakub Jelinek]

Hi!

In implicit parallel regions, we have NULL teams and often NULL task.
For task reductions we need both non-NULL, so this patch creates such a team
in that case, like we do already for target nowait.

Tested on x86_64-linux, committed to gomp-5_0-branch.

2018-10-08  Jakub Jelinek  

* task.c (GOMP_taskgroup_reduction_register): If team is NULL, create
implicit team with 1 thread and call GOMP_taskgroup_start again.  Don't
mix declarations with statements.
* team.c (gomp_team_end): Determine nesting by thr->ts.level != 0
rather than thr->ts.team != NULL.
* testsuite/libgomp.c-c++-common/task-reduction-4.c: New test.

--- libgomp/task.c.jj   2018-10-08 12:20:53.712125100 +0200
+++ libgomp/task.c  2018-10-08 18:29:51.410292170 +0200
@@ -1968,11 +1968,45 @@ GOMP_taskgroup_reduction_register (uintp
 {
   struct gomp_thread *thr = gomp_thread ();
   struct gomp_team *team = thr->ts.team;
-  struct gomp_task *task = thr->task;
-  unsigned nthreads = team ? team->nthreads : 1;
+  struct gomp_task *task;
+  if (__builtin_expect (team == NULL, 0))
+{
+  /* The task reduction code needs a team and task, so for
+orphaned taskgroups just create the implicit team.  */
+  struct gomp_task_icv *icv;
+  team = gomp_new_team (1);
+  task = thr->task;
+  icv = task ? &task->icv : &gomp_global_icv;
+  team->prev_ts = thr->ts;
+  thr->ts.team = team;
+  thr->ts.team_id = 0;
+  thr->ts.work_share = &team->work_shares[0];
+  thr->ts.last_work_share = NULL;
+#ifdef HAVE_SYNC_BUILTINS
+  thr->ts.single_count = 0;
+#endif
+  thr->ts.static_trip = 0;
+  thr->task = &team->implicit_task[0];
+  gomp_init_task (thr->task, NULL, icv);
+  if (task)
+   {
+ thr->task = task;
+ gomp_end_task ();
+ free (task);
+ thr->task = &team->implicit_task[0];
+   }
+#ifdef LIBGOMP_USE_PTHREADS
+  else
+   pthread_setspecific (gomp_thread_destructor, thr);
+#endif
+  GOMP_taskgroup_start ();
+}
+  unsigned nthreads = team->nthreads;
   size_t total_cnt = 0;
-  uintptr_t *d = data;
-  uintptr_t *old = task->taskgroup->reductions;
+  uintptr_t *d = data, *old;
+  struct htab *old_htab = NULL, *new_htab;
+  task = thr->task;
+  old = task->taskgroup->reductions;
   do
 {
   size_t sz = d[1] * nthreads;
@@ -1992,13 +2026,12 @@ GOMP_taskgroup_reduction_register (uintp
d = (uintptr_t *) d[4];
 }
   while (1);
-  struct htab *old_htab = NULL;
   if (old && old[5])
 {
   old_htab = (struct htab *) old[5];
   total_cnt += htab_elements (old_htab);
 }
-  struct htab *new_htab = htab_create (total_cnt);
+  new_htab = htab_create (total_cnt);
   if (old_htab)
 {
   /* Copy old hash table, like in htab_expand.  */
--- libgomp/team.c.jj   2018-07-27 12:57:16.0 +0200
+++ libgomp/team.c  2018-10-08 19:05:58.135130888 +0200
@@ -945,7 +945,7 @@ gomp_team_end (void)
   gomp_end_task ();
   thr->ts = team->prev_ts;
 
-  if (__builtin_expect (thr->ts.team != NULL, 0))
+  if (__builtin_expect (thr->ts.level != 0, 0))
 {
 #ifdef HAVE_SYNC_BUILTINS
   __sync_fetch_and_add (&gomp_managed_threads, 1L - team->nthreads);
--- libgomp/testsuite/libgomp.c-c++-common/task-reduction-4.c.jj
2018-10-08 18:35:52.181268647 +0200
+++ libgomp/testsuite/libgomp.c-c++-common/task-reduction-4.c   2018-10-08 
18:35:52.181268647 +0200
@@ -0,0 +1,70 @@
+extern
+#ifdef __cplusplus
+"C"
+#endif
+void abort (void);
+
+void
+bar (long long int *p)
+{
+  p[0] *= 2;
+  #pragma omp task in_reduction (*: p[0])
+  p[0] *= 3;
+}
+
+void
+foo (long long int *p, long long int *q)
+{
+  #pragma omp taskgroup task_reduction (*: p[0])
+  {
+#pragma omp task in_reduction (*: p[0])
+bar (p);
+#pragma omp task in_reduction (*: p[0])
+bar (p);
+bar (p);
+#pragma omp taskgroup task_reduction (*: q[0])
+{
+  #pragma omp task in_reduction (*: q[0])
+  bar (q);
+  #pragma omp task in_reduction (*: q[0])
+  bar (q);
+  #pragma omp task in_reduction (*: q[0])
+  bar (q);
+  bar (q);
+  #pragma omp task in_reduction (*: p[0])
+  {
+   #pragma omp taskgroup task_reduction (*: p[0])
+   {
+ #pragma omp task in_reduction (*: p[0])
+ bar (p);
+ p[0] *= 2;
+ #pragma omp task in_reduction (*: p[0])
+ bar (p);
+   }
+  }
+}
+  }
+}
+
+int
+main ()
+{
+  long long int p = 1LL, q = 1LL;
+  foo (&p, &q);
+  if (p != 6LL * 6LL * 6LL * 6LL * 6LL * 2LL || q != 6LL * 6LL * 6LL * 6LL)
+abort ();
+  p = 1LL;
+  q = 1LL;
+  #pragma omp taskgroup
+  foo (&p, &q);
+  if (p != 6LL * 6LL * 6LL * 6LL * 6LL * 2LL || q != 6LL * 6LL * 6LL * 6LL)
+abort ();
+  p = 1LL;
+  q = 1LL;
+  #pragma omp parallel
+  #pragma omp single
+  foo (&p, &q);
+  if (p != 6LL * 6LL * 6LL * 6LL * 6LL * 2LL || q != 6LL * 6LL * 6LL * 6LL)
+abort ();
+  return 0;
+}


Jakub

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Martin Sebor]

On 10/08/2018 07:27 AM, Manuel López-Ibáñez wrote:

On 07/10/18 23:38, Martin Sebor wrote:

+  pretty_printer posval;
+  if (pos != error_mark_node)
+{
+  /* Only format the position value when it's valid.  By convention
+ do not quote constant integers.  */
+  pp_space (&posval);
+  if (TREE_CODE (pos) != INTEGER_CST)
+pp_begin_quote (&posval, pp_show_color (global_dc->printer));
+  dump_generic_node (&posval, pos, 0, TDF_NONE, false);
+  if (TREE_CODE (pos) != INTEGER_CST)
+pp_end_quote (&posval, pp_show_color (global_dc->printer));
+}


Sorry for the bike-shedding but is this really necessary?

First, you handle != INTEGER_CST separately, so you can simply use %qE
for that case and %E for the rest. Nevertheless, I think the convention
is (https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Quoting): "elements
such as numbers that do no refer to numeric constants that appear in the
source code should not be quoted". Since this is a integer constant that
appears in the source code, then it should be quoted.


Ah, I forgot about this.  I'm happy to quote it.



Also, "value%s" where %s can be empty, will not translate correctly.


Why not?  (I had thought about it but convinced myself it would
not be a problem, but it's certainly possible I missed something.)



Perhaps you need a small function:

warn_attributes(const char * msg_no_value_no_arg,
const char * msg_no_value_arg,
const char * msg_value_no_arg,
const char * msg_value_arg,
tree atname, int argno, tree pos, ...)



+  if (TREE_CODE (pos) != INTEGER_CST)
+{
+  /* Only mention the argument number when it's non-zero.  */
+  if (argno < 1)
+warning (OPT_Wattributes,
+ "%qE attribute argument value%s is not an integer "
+ "constant",
+ atname, pp_formatted_text (&posval));
+  else
+warning (OPT_Wattributes,
+ "%qE attribute argument %i value%s is not an integer "
+ "constant",
+ atname, argno, pp_formatted_text (&posval));
+
+  return NULL_TREE;
+}


So that in the code above you can say:

if (TREE_CODE (pos) != INTEGER_CST)
{
warn_attributes("%qE attribute argument value is not an integer",
"%qE attribute argument %i value is not an integer",
"%qE attribute argument value %qE is not an integer",
"%qE attribute argument %i value %qE is not an integer",
 atname, argno, pos);
return NULL_TREE;
}


Thanks.  If it it turns out I'm wrong about the translation I'll
see if I can use something like it.  The concern raised with this
approach in the past was that GCC's -Wformat can't check the format
strings but I can't think of a better way.



Also, I wonder where input_location is pointing at for these warnings.
There may be a better location. Clang is doing:

:5:1: error: 'alloc_align' attribute requires parameter 1 to be
an integer constant
ALIGN ("1") void*
^  ~~~
:1:36: note: expanded from macro 'ALIGN'
#define ALIGN(N)   __attribute__ ((alloc_align (N)))
   ^~

while GCC does:

:6:16: warning: alloc_align parameter outside range [-Wattributes]
6 | fpvi_str_1 (int);
  |^



Unfortunately, there is no location information associated with
attribute arguments -- they are locationless constants -- so
the warnings point at (or just past) the current function
declaration.  David would know how difficult it might be to
add it to make the diagnostics look better.


Apart from the above, this seems a major improvement, so I hope it goes in.


Thanks
Martin

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Martin Sebor]

On 10/08/2018 05:33 AM, Joseph Myers wrote:

On Sun, 7 Oct 2018, Martin Sebor wrote:


While still testing an enhancement in the area of attributes
I ran across bugs and inconsistencies in how different handlers
deal with positional arguments.  The bugs are either an ICE due
to the handlers not consistently converting positional arguments
to constants (i.e., CONST_DEL to INTEGER_CST in C++) for which
downstream code is unprepared (PR 87541), or errors for valid
code (PR 87542), or failing to diagnose invalid arguments.
The other inconsistencies are simply in responding to the same
invalid condition differently for different attributes .


Note there's also a common bug that, where an integer constant expression
should be required, an INTEGER_CST of pointer type is wrongly accepted.
There's an INTEGRAL_TYPE_P check for sentinel attributes, and for
constructor / destructor (see gcc.dg/initpri2.c for that being tested),
but not for others.


Right, thanks.




PS It would be nice to have a general policy for how to respond
to invalid attribute arguments (warning or error).  Even better,
it would be ideal to move the validation from the front-ends and
back-ends into the middle-end.  I.e., describe attribute arguments
in more detail in struct attribute_spec and have decl_attributes
validate nut just the number of arguments but also their types
and, when appropriate, expected values.


I don't think the middle-end can handle the default_conversion part of
things (although attribute_spec could have the information for generic
code in the front ends, rather than every attribute handler, to do that).


I think it could be handled by each front-end passing the handler
a callback function (e.g., as a new argument to decl_attributes).
Built-ins wouldn't benefit from it but they can all be trusted
to specify integer literals as arguments.

Martin

Re: Use FOR_EACH_IMM_USE_FAST in gimple-ssa-backprop.c

[Jeff Law]

On 10/8/18 11:27 AM, Richard Sandiford wrote:
> As pointed out by Richard in PR63155.  It speeds up the testcase a few %.
> 
> Tested on aarch64-linux-gnu.  OK to install?
> 
> Richard
> 
> 
> 2018-10-08  Richard Sandiford  
> 
> gcc/
>   PR middle-end/63155
>   * gimple-ssa-backprop.c (backprop::intersect_uses): Use
>   FOR_EACH_IMM_USE_FAST instead of FOR_EACH_IMM_USE_STMT.
OK.
jeff

Re: [PATCH][4/n] Remove BLOCK_ABSTRACT

[Jason Merrill]

On Fri, Oct 5, 2018 at 7:47 AM Richard Biener  wrote:
>
> On Fri, 28 Sep 2018, Richard Biener wrote:
>
> >
> > It turns out that nobody sets this anymore (dwarf2out did with the
> > original code of outputting abstract instances, temporarily so IIRC).
> >
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> >
> > Any objection to purge it completely like this?
>
> It's gone now (r264868).
>
> > DECL_ABSTRACT_P is a similar beast but I see the C++ FE still sets it
> > on ctors-in-charge (or so).  Is this pure FE use or does the middle-end
> > really need to care about that?  I'd possibly turn each DECL_ABSTRACT_P
> > use in the middle-end into an assert but I wonder if you have any
> > thoughts about this.
>
> That question still stands.

Yes, I think it's been obsolete since you removed
set_decl_abstract_flags.  My hack in vague_linkage_p will need to
change before we can remove it entirely, though.  And I'd want to make
sure that the use in real_symbol_p isn't doing anything useful.

Jason

Use FOR_EACH_IMM_USE_FAST in gimple-ssa-backprop.c

[Richard Sandiford]

As pointed out by Richard in PR63155.  It speeds up the testcase a few %.

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

Richard


2018-10-08  Richard Sandiford  

gcc/
PR middle-end/63155
* gimple-ssa-backprop.c (backprop::intersect_uses): Use
FOR_EACH_IMM_USE_FAST instead of FOR_EACH_IMM_USE_STMT.

Index: gcc/gimple-ssa-backprop.c
===
--- gcc/gimple-ssa-backprop.c   2018-06-18 15:22:36.918297134 +0100
+++ gcc/gimple-ssa-backprop.c   2018-10-08 18:27:00.874770262 +0100
@@ -496,10 +496,11 @@ backprop::process_use (gimple *stmt, tre
 backprop::intersect_uses (tree var, usage_info *info)
 {
   imm_use_iterator iter;
-  gimple *stmt;
+  use_operand_p use_p;
   *info = usage_info::intersection_identity ();
-  FOR_EACH_IMM_USE_STMT (stmt, iter, var)
+  FOR_EACH_IMM_USE_FAST (use_p, iter, var)
 {
+  gimple *stmt = USE_STMT (use_p);
   if (is_gimple_debug (stmt))
continue;
   gphi *phi = dyn_cast  (stmt);
@@ -523,10 +524,7 @@ backprop::intersect_uses (tree var, usag
  process_use (stmt, var, &subinfo);
  *info &= subinfo;
  if (!info->is_useful ())
-   {
- BREAK_FROM_IMM_USE_STMT (iter);
- return false;
-   }
+   return false;
}
 }
   return true;

[C++ PATCH] Fix pretty-print of enumerator ids (PR c++/87364)

[will wray]

Hi,

A PR to fix Bug 87364 - Pretty print of enumerator never prints the id,
always falls back to C-style cast output

The fix is tested with the code attached to the bug report and additional
usage over the past few weeks.

Bootstrap and regtested on x86_64-linux. OK for trunk?


2018-10-08  Will Wray  

PR c++/87364
* c-pretty-print.c (pp_c_enumeration_constant): fix comparison.
* cxx-pretty-print.c (pp_cxx_enumeration_constant): New; add
nested-specifiers prefix to enum id plus enum type for scoped enum.

Index: gcc/c-family/c-pretty-print.h
===
--- gcc/c-family/c-pretty-print.h (revision 264938)
+++ gcc/c-family/c-pretty-print.h (working copy)
@@ -128,11 +128,13 @@ void pp_c_logical_or_expression (c_prett
 void pp_c_expression_list (c_pretty_printer *, tree);
 void pp_c_constructor_elts (c_pretty_printer *, vec *);
 void pp_c_call_argument_list (c_pretty_printer *, tree);
+void pp_c_type_cast (c_pretty_printer *, tree);
 void pp_c_cast_expression (c_pretty_printer *, tree);
 void pp_c_init_declarator (c_pretty_printer *, tree);
 void pp_c_ws_string (c_pretty_printer *, const char *);
 void pp_c_identifier (c_pretty_printer *, const char *);
 void pp_c_string_literal (c_pretty_printer *, tree);
+void pp_c_integer_constant (c_pretty_printer *, tree);

 void print_c_tree (FILE *file, tree t);

Index: gcc/c-family/c-pretty-print.c
===
--- gcc/c-family/c-pretty-print.c (revision 264938)
+++ gcc/c-family/c-pretty-print.c (working copy)
@@ -192,7 +192,7 @@ pp_c_cv_qualifiers (c_pretty_printer *pp

 /* Pretty-print T using the type-cast notation '( type-name )'.  */

-static void
+void
 pp_c_type_cast (c_pretty_printer *pp, tree t)
 {
   pp_c_left_paren (pp);
@@ -908,7 +908,7 @@ pp_c_void_constant (c_pretty_printer *pp

 /* Pretty-print an INTEGER literal.  */

-static void
+void
 pp_c_integer_constant (c_pretty_printer *pp, tree i)
 {
   if (tree_fits_shwi_p (i))
@@ -968,21 +968,20 @@ pp_c_bool_constant (c_pretty_printer *pp
 pp_unsupported_tree (pp, b);
 }

-/* Attempt to print out an ENUMERATOR.  Return true on success.  Else
return
-   false; that means the value was obtained by a cast, in which case
-   print out the type-id part of the cast-expression -- the casted value
-   is then printed by pp_c_integer_literal.  */
+/* Given a value e of ENUMERAL_TYPE:
+   Print out the first ENUMERATOR id with value e, if one is found,
+   else print out the value as a C-style cast (type-id)value.  */

-static bool
+static void
 pp_c_enumeration_constant (c_pretty_printer *pp, tree e)
 {
-  bool value_is_named = true;
   tree type = TREE_TYPE (e);
   tree value;

   /* Find the name of this constant.  */
   for (value = TYPE_VALUES (type);
-   value != NULL_TREE && !tree_int_cst_equal (TREE_VALUE (value), e);
+   value != NULL_TREE
+   && !tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e);
value = TREE_CHAIN (value))
 ;

@@ -992,10 +991,8 @@ pp_c_enumeration_constant (c_pretty_prin
 {
   /* Value must have been cast.  */
   pp_c_type_cast (pp, type);
-  value_is_named = false;
+  pp_c_integer_constant (pp, e);
 }
-
-  return value_is_named;
 }

 /* Print out a REAL value as a decimal-floating-constant.  */
@@ -1140,9 +1137,8 @@ c_pretty_printer::constant (tree e)
pp_c_bool_constant (this, e);
  else if (type == char_type_node)
pp_c_character_constant (this, e);
- else if (TREE_CODE (type) == ENUMERAL_TYPE
- && pp_c_enumeration_constant (this, e))
-   ;
+ else if (TREE_CODE (type) == ENUMERAL_TYPE)
+   pp_c_enumeration_constant (this, e);
  else
pp_c_integer_constant (this, e);
   }
Index: gcc/cp/cxx-pretty-print.c
===
--- gcc/cp/cxx-pretty-print.c (revision 264938)
+++ gcc/cp/cxx-pretty-print.c (working copy)
@@ -294,6 +294,39 @@ pp_cxx_qualified_id (cxx_pretty_printer
 }
 }

+/* Given a value e of ENUMERAL_TYPE:
+   Print out the first ENUMERATOR id with value e, if one is found,
+   (including nested names but excluding the enum name if unscoped)
+   else print out the value as a C-style cast (type-id)value.  */
+
+static void
+pp_cxx_enumeration_constant (cxx_pretty_printer *pp, tree e)
+{
+  tree type = TREE_TYPE (e);
+  tree value;
+
+  /* Find the name of this constant.  */
+  for (value = TYPE_VALUES (type);
+   value != NULL_TREE
+   && !tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e);
+   value = TREE_CHAIN (value))
+;
+
+  if (value != NULL_TREE)
+{
+  if (!ENUM_IS_SCOPED (type))
+ type = get_containing_scope (type);
+  pp_cxx_nested_name_specifier (pp, type);
+  pp->id_expression (TREE_PURPOSE (value));
+}
+  else
+{
+  /* Value must have been cast.  */
+   pp_c_type_cast (pp, type);
+   pp_c_integer_constant (pp, e);
+}
+}
+

 void
 cxx_pretty_printer::constant (tree t)
@@ -317,6 

[PATCH, pdp11] libgcc: remove -mfloat32

[Paul Koning]

I missed a file that needed to be updated for the removal of -mfloat32.

Committed.

paul

ChangeLog:

2018-10-08  Paul Koning  

* config/pdp11/t-pdp11: Remove -mfloat32 switch.

Index: config/pdp11/t-pdp11
===
--- config/pdp11/t-pdp11(revision 264938)
+++ config/pdp11/t-pdp11(working copy)
@@ -5,4 +5,4 @@ LIB2ADD = $(srcdir)/udivmod.c \
  $(srcdir)/memmove.c \
  $(srcdir)/memset.c
 
-HOST_LIBGCC2_CFLAGS += -O2 -mfloat32
+HOST_LIBGCC2_CFLAGS += -O2

[gomp5] Don't recompute addresses of original array sections at the end of taskgroup

[Jakub Jelinek]

Hi!

Last week we've agreed that it is allowed to modify the base of array
section used in task_reductions within the taskgroup construct, so we can't
reread/recompute the base and bias again, either we'd need to save those at
the start of the region, or we can just read it from where we've previously
stored it into the array passed to the runtime library.

Tested on x86_64-linux, committed to gomp-5_0-branch.

2018-10-08  Jakub Jelinek  

* omp-low.c (lower_omp_task_reductions): For array section reductions,
read address from avar array instead of computing it again at the end
of taskgroup, as the base might have changed during the taskgroup.

* testsuite/libgomp.c-c++-common/task-reduction-5.c: New test.

--- gcc/omp-low.c.jj2018-09-27 21:13:24.946076732 +0200
+++ gcc/omp-low.c   2018-10-08 17:30:42.147353172 +0200
@@ -6787,7 +6787,7 @@ lower_omp_task_reductions (omp_context *
   omp_task_reduction_iterate (pass, code, ccode,
   &c, &decl, &type, &next); c = next)
{
- tree var = decl, ref, orig_var = decl;
+ tree var = decl, ref;
  if (TREE_CODE (decl) == MEM_REF)
{
  var = TREE_OPERAND (var, 0);
@@ -6798,7 +6798,6 @@ lower_omp_task_reductions (omp_context *
var = TREE_OPERAND (var, 0);
  else if (TREE_CODE (var) == INDIRECT_REF)
var = TREE_OPERAND (var, 0);
- orig_var = var;
  if (is_variable_sized (var))
{
  gcc_assert (DECL_HAS_VALUE_EXPR_P (var));
@@ -6895,48 +6894,17 @@ lower_omp_task_reductions (omp_context *
rcode = PLUS_EXPR;
  if (TREE_CODE (decl) == MEM_REF)
{
- tree d = decl;
  tree type = TREE_TYPE (new_var);
  tree v = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
  tree i = create_tmp_var (TREE_TYPE (v), NULL);
  tree ptype = build_pointer_type (TREE_TYPE (type));
- tree bias = TREE_OPERAND (d, 1);
- d = TREE_OPERAND (d, 0);
- if (TREE_CODE (d) == POINTER_PLUS_EXPR)
-   {
- tree b = TREE_OPERAND (d, 1);
- b = maybe_lookup_decl_in_outer_ctx (b, ctx);
- if (integer_zerop (bias))
-   bias = b;
- else
-   {
- bias = fold_convert (TREE_TYPE (b), bias);
- bias = fold_build2 (PLUS_EXPR, TREE_TYPE (b), b, bias);
-   }
- d = TREE_OPERAND (d, 0);
-   }
- /* For ref build_outer_var_ref already performs this, so
-only new_var needs a dereference.  */
- if (TREE_CODE (d) == INDIRECT_REF)
-   ref = build_fold_indirect_ref (ref);
- else if (TREE_CODE (d) == ADDR_EXPR)
-   {
- if (orig_var == var)
-   ref = build_fold_addr_expr (ref);
-   }
- else
-   gcc_assert (orig_var == var);
  if (DECL_P (v))
{
  v = maybe_lookup_decl_in_outer_ctx (v, ctx);
  gimplify_expr (&v, end, NULL, is_gimple_val, fb_rvalue);
}
- if (!integer_zerop (bias))
-   {
- bias = fold_convert (sizetype, bias);
- ref = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (ref),
-ref, bias);
-   }
+ ref = build4 (ARRAY_REF, pointer_sized_int_node, avar,
+   size_int (7 + cnt * 3), NULL_TREE, NULL_TREE);
  new_var = build_fold_addr_expr (new_var);
  new_var = fold_convert (ptype, new_var);
  ref = fold_convert (ptype, ref);
--- libgomp/testsuite/libgomp.c-c++-common/task-reduction-5.c.jj
2018-10-08 17:31:11.993853975 +0200
+++ libgomp/testsuite/libgomp.c-c++-common/task-reduction-5.c   2018-10-08 
17:22:33.200531039 +0200
@@ -0,0 +1,55 @@
+extern
+#ifdef __cplusplus
+"C"
+#endif
+void abort (void);
+
+int *q;
+
+void
+bar (int *p, int *r, int s)
+{
+  #pragma omp task in_reduction (*: p[0], q[0], r[s - 1])
+  {
+*p *= 4;
+*q *= 5;
+r[s - 1] *= 6;
+  }
+}
+
+void
+foo (int *p, int *r, int s)
+{
+  int *p2 = p;
+  #pragma omp taskgroup task_reduction (*: p[0], q[0], r[s])
+  {
+p = (int *) 0;
+s++;
+bar (p2, r, s);
+r++;
+#pragma omp taskwait
+#pragma omp task in_reduction (*: p2[0], q[0], r[s - 2])
+{
+  *p2 *= 2;
+  *q *= 3;
+  r[s - 2] *= 7;
+}
+s++;
+p2 = (int *) 0;
+q = (int *) 0;
+r = (int *) 0;
+  }
+}
+
+int
+main ()
+{
+  int a = 1, b = 1, c[2] = { 1, 0 };
+  q = &b;
+  #pragma omp parallel num_threads (2)
+  #pragma omp master
+  foo (&a, &c[0], 0);
+  if (a != 8 || b != 15 || c[0] != 42 || c[1] != 0)
+abort ();
+  return 0;
+}

  

[PATCH][i386] Split reductions (was: Re: [PATCH][RFC][i386] Change sminmax reduction patterns)

[Richard Biener]

On Fri, 5 Oct 2018, Uros Bizjak wrote:

> On Thu, Oct 4, 2018 at 2:05 PM Richard Biener  wrote:
> >
> >
> > This tries to apply the same trick to sminmax reduction patterns
> > as for the reduc_plus_scal ones, namely reduce %zmm -> %ymm -> %xmm
> > first.  On a microbenchmark this improves performance on Zen
> > by ~30% for AVX2 and on Skylake-SP by ~10% for AVX512 (for AVX2
> > there's no measurable difference).
> >
> > I guess I'm mostly looking for feedback on the approach I took
> > in not rewriting ix86_expand_reduc but instead "recurse" on the
> > expanders as well as the need to define recursion stops for
> > SSE modes previously not covered.
> >
> > I'll throw this on a bootstrap & regtest on x86_64-unknown-linux-gnu
> > later.
> >
> > Any comments sofar?  Writing .md patterns is new for me ;)
> 
> LGTM for the implementation.

So this applies the method to all AVX2/AVX512 reduc_*_scal_* patterns
we have.  I've inspected the assembly and it looks as expected.

Note I tried relying on the vectorizer to perform this, thus delete
the patterns.  Trying that for the reduc_plus_* ones reveals that
the final (SSE width) reduction step looks different and
unconditionally uses psrldq as the vectorizer expands the final
reduction step using whole-vector shifts.  Well, it actually
generates permutes like

  vect_res_6.10_22 = VEC_PERM_EXPR <_21, { 0.0, 0.0, 0.0, 0.0 }, { 2, 3, 
4, 5 }>;

but those end up using the vec_shr_ expander which puns
everything to V1TImode.  Removing the vec_shr_ expander
also doesn't get us the desired movhlps instruction for the
above (but a vshufps).  I'm not sure where to best fix that
(I think with good vec_perm expanders we shouldn't neeed the
vec_shr one - at least we'd keep the float/int domain), so I
kept all the reduc_* expanders we have now.  But I'll note
those we do not have (luckily all non-FP) use that
"inefficient"(?) instructions.  Like on Zen psrldq has a reciprocal
throughput of 1 while movhlps has one of 0.5, so using movhlps
would help loops with two reductions, on Skylake the opposite
seems to be the case...

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

OK for trunk?

Thanks,
Richard.

2018-10-08  Richard Biener  

* config/i386/sse.md (reduc_plus_scal_v8df, reduc_plus_scal_v4df,
reduc_plus_scal_v2df, reduc_plus_scal_v16sf, reduc_plus_scal_v8sf,
reduc_plus_scal_v4sf): Merge into pattern reducing to half width
and recursing and pattern terminating the recursion on SSE
vector width using ix86_expand_reduc.
(reduc_sminmax_scal_): Split into part reducing to half
width and recursing and SSE2 vector variant doing the final
reduction with ix86_expand_reduc.
(reduc_uminmax_scal_): Likewise for the AVX512 variants
with terminating the recursion at AVX level, splitting that
to SSE there.

Index: gcc/config/i386/sse.md
===
--- gcc/config/i386/sse.md  (revision 264923)
+++ gcc/config/i386/sse.md  (working copy)
@@ -2457,98 +2457,65 @@ (define_insn "sse3_hv4sf
(set_attr "prefix_rep" "1,*")
(set_attr "mode" "V4SF")])
 
-(define_expand "reduc_plus_scal_v8df"
-  [(match_operand:DF 0 "register_operand")
-   (match_operand:V8DF 1 "register_operand")]
-  "TARGET_AVX512F"
-{
-  rtx tmp = gen_reg_rtx (V8DFmode);
-  ix86_expand_reduc (gen_addv8df3, tmp, operands[1]);
-  emit_insn (gen_vec_extractv8dfdf (operands[0], tmp, const0_rtx));
-  DONE;
-})
+(define_mode_iterator REDUC_SSE_PLUS_MODE
+ [(V2DF "TARGET_SSE") (V4SF "TARGET_SSE")])
 
-(define_expand "reduc_plus_scal_v4df"
-  [(match_operand:DF 0 "register_operand")
-   (match_operand:V4DF 1 "register_operand")]
-  "TARGET_AVX"
+(define_expand "reduc_plus_scal_"
+ [(plus:REDUC_SSE_PLUS_MODE
+   (match_operand: 0 "register_operand")
+   (match_operand:REDUC_SSE_PLUS_MODE 1 "register_operand"))]
+ ""
 {
-  rtx tmp = gen_reg_rtx (V2DFmode);
-  emit_insn (gen_vec_extract_hi_v4df (tmp, operands[1]));
-  rtx tmp2 = gen_reg_rtx (V2DFmode);
-  emit_insn (gen_addv2df3 (tmp2, tmp, gen_lowpart (V2DFmode, operands[1])));
-  rtx tmp3 = gen_reg_rtx (V2DFmode);
-  emit_insn (gen_vec_interleave_highv2df (tmp3, tmp2, tmp2));
-  emit_insn (gen_adddf3 (operands[0],
-gen_lowpart (DFmode, tmp2),
-gen_lowpart (DFmode, tmp3)));
-  DONE;
-})
-
-(define_expand "reduc_plus_scal_v2df"
-  [(match_operand:DF 0 "register_operand")
-   (match_operand:V2DF 1 "register_operand")]
-  "TARGET_SSE2"
-{
-  rtx tmp = gen_reg_rtx (V2DFmode);
-  emit_insn (gen_vec_interleave_highv2df (tmp, operands[1], operands[1]));
-  emit_insn (gen_adddf3 (operands[0],
-gen_lowpart (DFmode, tmp),
-gen_lowpart (DFmode, operands[1])));
+  rtx tmp = gen_reg_rtx (mode);
+  ix86_expand_reduc (gen_add3, tmp, operands[1]);
+  emit_insn (gen_vec_extract (operands[0], tmp,
+   

Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections

[Bernd Edlinger]

On 10/08/18 13:14, Rainer Orth wrote:
> Hi Bernd,
> 
>> On 10/05/18 20:15, Andreas Schwab wrote:
>>> On Sep 14 2018, Bernd Edlinger  wrote:
>>>
 diff -Npur gcc/testsuite/gnat.dg/string_merge1.adb
 gcc/testsuite/gnat.dg/string_merge1.adb
 --- gcc/testsuite/gnat.dg/string_merge1.adb 1970-01-01
 01:00:00.0 +0100
 +++ gcc/testsuite/gnat.dg/string_merge1.adb 2018-08-26
 16:31:12.650271931 +0200
 @@ -0,0 +1,19 @@
 +-- { dg-do compile }
 +-- { dg-options "-O1 -fmerge-all-constants" }
 +
 +procedure String_Merge1 is
 +   procedure Process (X : String);
 +   pragma Import (Ada, Process);
 +begin
 +   Process ("ABCD");
 +end;
 +
 +-- We expect something like:
 +
 +-- .section  .rodata.str1.1,"aMS",@progbits,1
 +-- .LC1:
 +-- .string "ABCD"
 +
 +-- { dg-final { scan-assembler-times "\\.rodata\\.str" 1 } }
 +-- { dg-final { scan-assembler-times "\\.string" 1 } }
 +-- { dg-final { scan-assembler-times "\"ABCD\"" 1 } }
>>>
>>> FAIL: gnat.dg/string_merge1.adb scan-assembler-times \\.string 1
>>>
>>> $ grep ABCD string_merge1.s
>>>   stringz "ABCD"
>>>
>>
>> Ah, thanks.
>>
>> Turns out there are too much variations, like mentioned stringz, and asciz, 
>> and
>> probably lots more here.
>>
>> But for the purpose of testing the optimization it should be sufficient to 
>> look for
>> ".rodata.str" in the assembler.
>>
>> So I committed the following as obvious:
> 
> unfortunately that patch is not enough and still shows a fundamental
> problem:
> 
> * The tests still FAIL on Solaris with /bin/as and Darwin:
> 
> FAIL: gcc.dg/merge-all-constants-2.c scan-assembler-not .rodata[\\n\\r]
> 
> FAIL: gnat.dg/string_merge1.adb scan-assembler-times .rodata.str 1
> FAIL: gnat.dg/string_merge2.adb scan-assembler-times .rodata.str 1
> 
>Both targets lack string merging support, so the tests should check
>for that.
> 
> * The merge-all-constants-2.c test doesn't FAIL on Solaris/SPARC with
>/bin/as, although it lacks string merging support, too.  The assembler
>output contains
> 
>  .section".rodata"
> 
>so the pattern currently used to check for .rodata is too
>restrictive.  There is assembler syntax beyond gas on x86 ;-)
> 

For the test that failed with the quotes around .rodata.  I think
instead of looking for a end of line immediately after .rodata, it
would be sufficient to make sure it does not continue with .str, so
could you please try to add something like the following to your patch?

Index: gcc/testsuite/gcc.dg/merge-all-constants-2.c
===
--- gcc/testsuite/gcc.dg/merge-all-constants-2.c(revision 264888)
+++ gcc/testsuite/gcc.dg/merge-all-constants-2.c(working copy)
@@ -5,4 +5,4 @@
  const char str2[37] = "0123456789abcdefghijklmnopqrstuvwxyz";
  const char str3[10] = "0123456789abcdefghijklmnopqrstuvwxyz";
  
-/* { dg-final { scan-assembler-not "\\.rodata\[\n\r\]" } } */
+/* { dg-final { scan-assembler-not "\\.rodata\[^.]" } } */


> The following patch fixes the former issue; tested on
> sparc-sun-solaris2.11 with as (no string merging) resp. gas (with string
> merging).  Installed on mainline.
> 
> Besides, the patch seems to have produced more fallout on Solaris: I see
> many new Go testsuite failures on Solaris 10 which probably are related,
> and Solaris bootstrap with Ada included is broken due to the extended
> usage of string merging.  I'm currently investigating what's going on
> there.
> 
>   Rainer
> 

Re: [PATCH] i386: Correct _mm512_mask3_fmaddsub_round_pd

[H.J. Lu]

On Thu, Oct 4, 2018 at 5:46 AM H.J. Lu  wrote:
>
> Define _mm512_mask3_fmaddsub_round_pd with
> __builtin_ia32_vfmaddsubpd512_mask, instead of
> __builtin_ia32_vfmaddpd512_mask.
>
> PR target/87517
> * config/i386/avx512fintrin.h (_mm512_mask_fmaddsub_round_pd):
> Defined with __builtin_ia32_vfmaddsubpd512_mask.
> ---
>  gcc/config/i386/avx512fintrin.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/i386/avx512fintrin.h b/gcc/config/i386/avx512fintrin.h
> index 550c2b60886..f9bb4f3be49 100644
> --- a/gcc/config/i386/avx512fintrin.h
> +++ b/gcc/config/i386/avx512fintrin.h
> @@ -3833,7 +3833,7 @@ _mm512_maskz_fnmsub_round_ps (__mmask16 __U, __m512 
> __A, __m512 __B,
>  (__m512d)__builtin_ia32_vfmaddsubpd512_mask(A, B, C, -1, R)
>
>  #define _mm512_mask_fmaddsub_round_pd(A, U, B, C, R)\
> -(__m512d)__builtin_ia32_vfmaddpd512_mask(A, B, C, U, R)
> +(__m512d)__builtin_ia32_vfmaddsubpd512_mask(A, B, C, U, R)
>
>  #define _mm512_mask3_fmaddsub_round_pd(A, B, C, U, R)   \
>  (__m512d)__builtin_ia32_vfmaddsubpd512_mask3(A, B, C, U, R)
> --
> 2.17.1

I checked it into trunk under obvious rule.  I will backport it to
release branches
later.

-- 
H.J.

Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

[Jeff Law]

On 10/8/18 8:43 AM, Christophe Lyon wrote:
> On Mon, 8 Oct 2018 at 16:13, Peter Bergner  wrote:
>>
>> On 10/8/18 4:14 AM, Christophe Lyon wrote:
>>> Since r264897, we are seeing lots of regressions when bootstrapping on arm.
>>> There are execution errors as well as ICEs.
>>> A detailed list can be found at:
>>> https://ci.linaro.org/job/tcwg-compare-results/6498/artifact/artifacts/logs/1-diff-d05_32.tcwg-d05_32-build.txt
>>>
>>> You can also see the results posted on gcc-testresults.
>>
>> Sorry for the breakage.  I'll try and build a cross compiler to fix the
>> ICEs.  Hopefully all the other issues are related.
>>
> 
> Note that I saw ICEs only when bootstrapping, not when testing a 
> cross-compiler.
My tester is showing a variety of problems as well.  hppa, sh4, aarch64,
aarch64_be, alpha arm* and s390x bootstraps are all failing at various
points.   Others may trickle in over time, but clearly something went
wrong recently.  I'm going to start trying to pick them off after the
morning meetings are wrapped up.


jeff

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

[Jeff Law]

On 10/4/18 1:43 PM, Joseph Myers wrote:
> On Thu, 4 Oct 2018, Jeff Law wrote:
> 
>>> I doubt you could prove that without LTO of the whole program because an 
>>> errno value set by a libm function call could always be checked in the 
>>> caller of whatever function is being compiled.
>> Right, but if you have a series of calls like
>>
>>
>>   t1 = sqrt (x);
>>   t2 = sqrt (y);
>>   t3 = sqrt (z);
>>   return t1 + t2 + t3;
>>
>> You know that errno from the first two isn't examined and you could emit
>> the hardware insn for sqrt in those cases.  You couldn't do so for the
>> 3rd because you don't necessarily have the caller context.
> 
> No, you don't know that error from the first two isn't examined.  sqrt 
> doesn't set errno on success.  A caller could set errno to 0 before that 
> code, then check for errno == EDOM afterwards, meaning that any of the 
> sqrt arguments were negative.  (The caller could also check whether the 
> result is a NaN and so not need errno, of course.)
You're right of course.

Jeff

Re: [PATCH][i386] Update Zen tuning for vector load cost

[Richard Biener]

On Mon, 8 Oct 2018, Jan Hubicka wrote:

> > 
> > This adjusts Zen AVX256 vector load cost to be twice as expensive
> > than AVX128 vector load cost (twice via ix86_vec_cost keying on
> > TARGET_AVX128_OPTIMAL - should rather use some
> > TARGET_VECTOR_IMPL_WIDTH or so).
> > 
> > Likely the current cost value was meant to make AVX256 loads _cheaper_
> > than two AVX128 ones in which case we'd have to use 5 here.  Honza,
> > what was the intent here?  Maybe not call ix86_vec_cost for loads or
> > stores at all (given we model different sizes explicitely?)?  The
> > odd thing is that in some places you pass ix86_vec_cost
> > COSNTS_N_INSNS (ix86_cost->...) and in others just
> > ix86_cost->  That's probably caused by most entries in the cost
> > tables being scaled via COSTS_N_INSNS but not all which makes them
> > not easily comparable... (I found a comment that says
> > "We assume COSTS_N_INSNS is defined as (N)*4")
> > 
> > That ix86_vec_cost adds a factor of two for AVX256 also is throwing
> > throughput into the mix because latency-wise AVX256 behaves the
> > same as AVX128 AFAICs.  That is, the modeling isn't very precise...
> > (multiplying by two still makes sense IMHO - but for example stores
> > have only one 128bit port so those are the ones that should be
> > more than factor-of-two pessimized if any)
> 
> Hmm the intent was to make the tables latency based, so 256bit load should be
> definitly cheaper than two 128loads.  I guess the current state is result of
> getting TARGET_AVX128_OPTIMAL adjustemnt inconsistent.  It did not make much
> difference previously becuase TARGET_AVX128_OPTIMAL prevents us from using 256
> instructions in most cases.

Yeah, I guess I'll propose splitting that TARGET_AVX128_OPTIMAL use
in ix86_vec_cost to a different flag/tunable (possibly just a cost
table entry because it really is closely tied to the costs we assign).

> Vectorizer cost model is bit odd mix of throughputs and latencies in general.
> I wondered if it would make sense to compute the cost of a loop by computing
> producing the DAG of dependencies and computing cost of the most expensive
> path through the DAG...

Yeah - in office we threw around some thoughts about throwing
all stmts added via add_stmt hook at the scheduler pipeline model
and compute that path, basically only modeling resources and dependences.
We'd need to identify instructions (do instruction selection) at the
granularity of the pipeline description of course which may be
"interesting".

> Patch looks OK to me (it makes situation better than previously for sure :)

Thanks, I've also done some benchmarking with this and only saw
positive effects.

Applied.

Richard.

> Honza
> > 
> > Anyhow, the patch removes one oddity comparing costs of vectorized
> > loops when there are no lane-crossing operations (after the patch
> > such loops will cost the same with AVX128 and AVX256 even though
> > Zens frontend will benefit from using AVX256).
> > 
> > Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> > 
> > OK?
> > 
> > Thanks,
> > Richard.
> > 
> > 2018-10-08  Richard Biener  
> > 
> > * config/i386/x86-tune-costs.h (znver1_cost): Make AVX256 vector loads
> > cost the same as AVX128 ones.
> > 
> > diff --git a/gcc/config/i386/x86-tune-costs.h 
> > b/gcc/config/i386/x86-tune-costs.h
> > index 71a5854c09a..c7f3945d72c 100644
> > --- a/gcc/config/i386/x86-tune-costs.h
> > +++ b/gcc/config/i386/x86-tune-costs.h
> > @@ -1518,9 +1518,9 @@ struct processor_costs znver1_cost = {
> >{8, 8},  /* cost of storing MMX registers
> >in SImode and DImode.  */
> >2, 3, 6, /* cost of moving XMM,YMM,ZMM register. 
> >  */
> > -  {6, 6, 6, 10, 20},   /* cost of loading SSE registers
> > +  {6, 6, 6, 6, 12},/* cost of loading SSE registers
> >in 32,64,128,256 and 512-bit.  */
> > -  {6, 6, 6, 10, 20},   /* cost of unaligned loads.  */
> > +  {6, 6, 6, 6, 12},/* cost of unaligned loads.  */
> >{8, 8, 8, 8, 16},/* cost of storing SSE registers
> >in 32,64,128,256 and 512-bit.  */
> >{8, 8, 8, 8, 16},/* cost of unaligned stores.  */
> > 
> 
> 

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

Re: Merge from trunk to gccgo branch

[Ian Lance Taylor]

I merged trunk revision 264932 to the gccgo branch.

Ian

Re: [PATCH 2/2] Support string locations for C++ in -Wformat (PR c++/56856)

[Jason Merrill]

On Thu, Oct 4, 2018 at 10:12 AM David Malcolm  wrote:
>
> -Wformat in the C++ FE doesn't work as well as it could:
> (a) it doesn't report precise locations within the string literal, and
> (b) it doesn't underline arguments for those arguments !CAN_HAVE_LOCATION_P,
> despite having location wrapper nodes.
>
> For example:
>
>   Wformat-ranges.C:32:10: warning: format '%s' expects argument of type 
> 'char*', but argument 2 has type 'int' [-Wformat=]
>   32 |   printf("hello %s", 42);
>  |  ^~
>
> (a) is due to not wiring up the langhook for extracting substring
> locations.
>
> This patch uses the one in c-family; it also fixes string literal
> parsing so that it records string concatenations (needed for
> extracting substring locations from concatenated strings).
>
> (b) is due to the call to maybe_constant_value here:
>fargs[j] = maybe_constant_value (argarray[j]);
> within build_over_call.

Maybe we should remove that in favor of fold_for_warn in
check_function_arguments.

Jason

[PATCH] libgcc: remove t-ppccomm from powerpc-wrs-vxworks

[Rasmus Villemoes]

VxWorks doesn't use the __eabi function (in fact, the ecrti.o and
ecrtn.o files are not added to extra_parts). This means that the
__SBSS_END__ etc. symbols in eabi.S are always undefined. This is mostly
harmless, but it is inconvenient when one wants to create a libgcc
runtime module by doing a --whole-archive link of libgcc.a.

Moreover, it turns out that ibm-ldouble.o ends up being empty for
powerpc-wrs-vxworks, since only __ppc__ and __PPC__ are
TARGET_OS_CPP_BUILTINS, while the entire ibm-ldouble.c is protected by

#if (defined (__MACH__) || defined (__powerpc__) || defined (_AIX)) \
&& !defined (__rtems__)

To avoid the above inconvenience, and make it a little more clear what
actually gets built and used for powerpc-wrs-vxworks, create a new
t-vxworks which adds tramp.S to LIB2ADD, and use that instead of
t-ppccomm.

==changelog==

libgcc/

* config.host: Remove rs6000/t-ppccomm from powerpc-wrs-vxworks.
* config/rs6000/t-vxworks: New file.
---
 libgcc/config.host | 2 +-
 libgcc/config/rs6000/t-vxworks | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 libgcc/config/rs6000/t-vxworks

diff --git a/libgcc/config.host b/libgcc/config.host
index 029f6569caf..3e083ec4e34 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1140,7 +1140,7 @@ powerpc*-*-linux*)
md_unwind_header=rs6000/linux-unwind.h
;;
 powerpc-wrs-vxworks*)
-   tmake_file="$tmake_file rs6000/t-ppccomm rs6000/t-savresfgpr t-fdpbit"
+   tmake_file="$tmake_file rs6000/t-vxworks rs6000/t-savresfgpr t-fdpbit"
extra_parts="$extra_parts crtbegin.o crtend.o"
;;
 powerpc-*-lynxos*)
diff --git a/libgcc/config/rs6000/t-vxworks b/libgcc/config/rs6000/t-vxworks
new file mode 100644
index 000..8c7a56fb446
--- /dev/null
+++ b/libgcc/config/rs6000/t-vxworks
@@ -0,0 +1 @@
+LIB2ADD += $(srcdir)/config/rs6000/tramp.S
-- 
2.19.1.3.g1d92a00e68

Re: [PATCH][i386] Update Zen tuning for vector load cost

[Jan Hubicka]

> 
> This adjusts Zen AVX256 vector load cost to be twice as expensive
> than AVX128 vector load cost (twice via ix86_vec_cost keying on
> TARGET_AVX128_OPTIMAL - should rather use some
> TARGET_VECTOR_IMPL_WIDTH or so).
> 
> Likely the current cost value was meant to make AVX256 loads _cheaper_
> than two AVX128 ones in which case we'd have to use 5 here.  Honza,
> what was the intent here?  Maybe not call ix86_vec_cost for loads or
> stores at all (given we model different sizes explicitely?)?  The
> odd thing is that in some places you pass ix86_vec_cost
> COSNTS_N_INSNS (ix86_cost->...) and in others just
> ix86_cost->  That's probably caused by most entries in the cost
> tables being scaled via COSTS_N_INSNS but not all which makes them
> not easily comparable... (I found a comment that says
> "We assume COSTS_N_INSNS is defined as (N)*4")
> 
> That ix86_vec_cost adds a factor of two for AVX256 also is throwing
> throughput into the mix because latency-wise AVX256 behaves the
> same as AVX128 AFAICs.  That is, the modeling isn't very precise...
> (multiplying by two still makes sense IMHO - but for example stores
> have only one 128bit port so those are the ones that should be
> more than factor-of-two pessimized if any)

Hmm the intent was to make the tables latency based, so 256bit load should be
definitly cheaper than two 128loads.  I guess the current state is result of
getting TARGET_AVX128_OPTIMAL adjustemnt inconsistent.  It did not make much
difference previously becuase TARGET_AVX128_OPTIMAL prevents us from using 256
instructions in most cases.

Vectorizer cost model is bit odd mix of throughputs and latencies in general.
I wondered if it would make sense to compute the cost of a loop by computing
producing the DAG of dependencies and computing cost of the most expensive
path through the DAG...

Patch looks OK to me (it makes situation better than previously for sure :)
Honza
> 
> Anyhow, the patch removes one oddity comparing costs of vectorized
> loops when there are no lane-crossing operations (after the patch
> such loops will cost the same with AVX128 and AVX256 even though
> Zens frontend will benefit from using AVX256).
> 
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> 
> OK?
> 
> Thanks,
> Richard.
> 
> 2018-10-08  Richard Biener  
> 
>   * config/i386/x86-tune-costs.h (znver1_cost): Make AVX256 vector loads
>   cost the same as AVX128 ones.
> 
> diff --git a/gcc/config/i386/x86-tune-costs.h 
> b/gcc/config/i386/x86-tune-costs.h
> index 71a5854c09a..c7f3945d72c 100644
> --- a/gcc/config/i386/x86-tune-costs.h
> +++ b/gcc/config/i386/x86-tune-costs.h
> @@ -1518,9 +1518,9 @@ struct processor_costs znver1_cost = {
>{8, 8},/* cost of storing MMX registers
>  in SImode and DImode.  */
>2, 3, 6,   /* cost of moving XMM,YMM,ZMM register. 
>  */
> -  {6, 6, 6, 10, 20}, /* cost of loading SSE registers
> +  {6, 6, 6, 6, 12},  /* cost of loading SSE registers
>  in 32,64,128,256 and 512-bit.  */
> -  {6, 6, 6, 10, 20}, /* cost of unaligned loads.  */
> +  {6, 6, 6, 6, 12},  /* cost of unaligned loads.  */
>{8, 8, 8, 8, 16},  /* cost of storing SSE registers
>  in 32,64,128,256 and 512-bit.  */
>{8, 8, 8, 8, 16},  /* cost of unaligned stores.  */
> 

libgo patch committed: Update to 1.11.1 release

[Ian Lance Taylor]

This patch updates libgo to the 1.11.1 release.  Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 264882)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-d0739c13ca3686df1f8d0fae7c6c5caaed058503
+a9da4d34a2f878a5058f7e7d2beef52aa62471a1
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/MERGE
===
--- libgo/MERGE (revision 264813)
+++ libgo/MERGE (working copy)
@@ -1,4 +1,4 @@
-41e62b8c49d21659b48a95216e3062032285250f
+26957168c4c0cdcc7ca4f0b19d0eb19474d224ac
 
 The first line of this file holds the git revision number of the
 last merge done from the master library sources.
Index: libgo/VERSION
===
--- libgo/VERSION   (revision 264813)
+++ libgo/VERSION   (working copy)
@@ -1 +1 @@
-go1.11
+go1.11.1
Index: libgo/go/cmd/go/alldocs.go
===
--- libgo/go/cmd/go/alldocs.go  (revision 264813)
+++ libgo/go/cmd/go/alldocs.go  (working copy)
@@ -1449,6 +1449,12 @@
 // The directory where the go command will write
 // temporary source files, packages, and binaries.
 //
+// Each entry in the GOFLAGS list must be a standalone flag.
+// Because the entries are space-separated, flag values must
+// not contain spaces. In some cases, you can provide multiple flag
+// values instead: for example, to set '-ldflags=-s -w'
+// you can use 'GOFLAGS=-ldflags=-s -ldflags=-w'.
+//
 // Environment variables for use with cgo:
 //
 // CC
Index: libgo/go/cmd/go/internal/help/helpdoc.go
===
--- libgo/go/cmd/go/internal/help/helpdoc.go(revision 264813)
+++ libgo/go/cmd/go/internal/help/helpdoc.go(working copy)
@@ -507,6 +507,12 @@ General-purpose environment variables:
The directory where the go command will write
temporary source files, packages, and binaries.
 
+Each entry in the GOFLAGS list must be a standalone flag.
+Because the entries are space-separated, flag values must
+not contain spaces. In some cases, you can provide multiple flag
+values instead: for example, to set '-ldflags=-s -w'
+you can use 'GOFLAGS=-ldflags=-s -ldflags=-w'.
+
 Environment variables for use with cgo:
 
CC
Index: libgo/go/cmd/go/internal/work/exec.go
===
--- libgo/go/cmd/go/internal/work/exec.go   (revision 264813)
+++ libgo/go/cmd/go/internal/work/exec.go   (working copy)
@@ -224,7 +224,9 @@ func (b *Builder) buildActionID(a *Actio
if len(p.SFiles) > 0 {
fmt.Fprintf(h, "asm %q %q %q\n", b.toolID("asm"), 
forcedAsmflags, p.Internal.Asmflags)
}
-   fmt.Fprintf(h, "GO$GOARCH=%s\n", 
os.Getenv("GO"+strings.ToUpper(cfg.BuildContext.GOARCH))) // GO386, GOARM, etc
+   // GO386, GOARM, GOMIPS, etc.
+   baseArch := strings.TrimSuffix(cfg.BuildContext.GOARCH, "le")
+   fmt.Fprintf(h, "GO$GOARCH=%s\n", 
os.Getenv("GO"+strings.ToUpper(baseArch)))
 
// TODO(rsc): Convince compiler team not to add more magic 
environment variables,
// or perhaps restrict the environment variables passed to 
subprocesses.
Index: libgo/go/cmd/go/internal/work/security.go
===
--- libgo/go/cmd/go/internal/work/security.go   (revision 264813)
+++ libgo/go/cmd/go/internal/work/security.go   (working copy)
@@ -170,6 +170,7 @@ var validLinkerFlags = []*regexp.Regexp{
re(`-Wl,-e[=,][a-zA-Z0-9]*`),
re(`-Wl,--enable-new-dtags`),
re(`-Wl,--end-group`),
+   re(`-Wl,--(no-)?export-dynamic`),
re(`-Wl,-framework,[^,@\-][^,]+`),
re(`-Wl,-headerpad_max_install_names`),
re(`-Wl,--no-undefined`),
Index: libgo/go/cmd/go/script_test.go
===
--- libgo/go/cmd/go/script_test.go  (revision 264813)
+++ libgo/go/cmd/go/script_test.go  (working copy)
@@ -635,6 +635,9 @@ func scriptMatch(ts *testScript, neg boo
text = string(data)
}
 
+   // Matching against workdir would be misleading.
+   text = strings.Replace(text, ts.workdir, "$WORK", -1)
+
if neg {
if re.MatchString(text) {
if isGrep {
Index: libgo/go/crypto/x509/verify.go
===
--- libgo/go/crypto/x509/verify.go  (revision 264813)
+++ libgo/go/crypto/x509/verify.go  (working copy)
@@ -894,8 +894,8 @@ func validHostna

[PATCH, pdp11] Fix LRA failure

[Paul Koning]

This patch fixes a failure handling block moves when the LRA register allocator 
is used. 

Committed.

paul

ChangeLog:

2018-10-08  Paul Koning  

* config/pdp11/pdp11-protos.h (output_block_move): Remove.
(expand_block_move): New function.
* config/pdp11/pdp11.c (output_block_move): Remove.
(expand_block_move): New function.
* config/pdp11/pdp11.h (MOVE_RATIO): New definition.
* config/pdp11/pdp11.md (movmemhi): Use expand_block_move.
(*movmemhi1): Remove.

Index: config/pdp11/pdp11-protos.h
===
--- config/pdp11/pdp11-protos.h (revision 264929)
+++ config/pdp11/pdp11-protos.h (revision 264930)
@@ -26,7 +26,7 @@ extern int legitimate_const_double_p (rtx);
 extern void notice_update_cc_on_set (rtx, rtx);
 extern void output_addr_const_pdp11 (FILE *, rtx);
 extern const char *output_move_multiple (rtx *);
-extern const char *output_block_move (rtx *);
+extern void expand_block_move (rtx *);
 extern const char *output_jump (rtx *, int, int);
 extern void print_operand_address (FILE *, rtx);
 typedef enum { no_action, dec_before, inc_after } pdp11_action;
Index: config/pdp11/pdp11.md
===
--- config/pdp11/pdp11.md   (revision 264929)
+++ config/pdp11/pdp11.md   (revision 264930)
@@ -570,48 +570,20 @@
   clrf\t%0"
   [(set_attr "length" "2,2,4,4,2")])
 
-;; maybe fiddle a bit with move_ratio, then 
-;; let constraints only accept a register ...
-
+;; Expand a block move.  We turn this into a move loop.
 (define_expand "movmemhi"
-  [(parallel [(set (match_operand:BLK 0 "general_operand" "=g,g")
-  (match_operand:BLK 1 "general_operand" "g,g"))
- (use (match_operand:HI 2 "general_operand" "n,mr"))
- (use (match_operand:HI 3 "immediate_operand" "i,i"))
- (clobber (match_scratch:HI 6 "=&r,X"))
- (clobber (match_dup 4))
- (clobber (match_dup 5))
- (clobber (match_dup 2))])]
+  [(match_operand:BLK 0 "general_operand" "=g")
+   (match_operand:BLK 1 "general_operand" "g")
+   (match_operand:HI 2 "immediate_operand" "i")
+   (match_operand:HI 3 "immediate_operand" "i")]
   ""
   "
 {
-  operands[0]
-= replace_equiv_address (operands[0],
-copy_to_mode_reg (Pmode, XEXP (operands[0], 0)));
-  operands[1]
-= replace_equiv_address (operands[1],
-copy_to_mode_reg (Pmode, XEXP (operands[1], 0)));
-
-  operands[4] = XEXP (operands[0], 0);
-  operands[5] = XEXP (operands[1], 0);
+  if (INTVAL (operands[2]) != 0)
+expand_block_move (operands);
+  DONE;
 }")
 
-
-(define_insn "*movmemhi1"
-  [(set (mem:BLK (match_operand:HI 0 "register_operand" "r,r"))
-   (mem:BLK (match_operand:HI 1 "register_operand" "r,r")))
-   (use (match_operand:HI 2 "general_operand" "n,r"))
-   (use (match_operand:HI 3 "immediate_operand" "i,i"))
-   (clobber (match_scratch:HI 4 "=&r,X"))
-   (clobber (match_dup 0))
-   (clobber (match_dup 1))
-   (clobber (match_dup 2))]
-  ""
-  "* return output_block_move (operands);"
-;;; just a guess
-  [(set_attr "length" "80")])
-   
-
 

 ;;- truncation instructions
 
Index: config/pdp11/pdp11.c
===
--- config/pdp11/pdp11.c(revision 264929)
+++ config/pdp11/pdp11.c(revision 264930)
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "expr.h"
 #include "builtins.h"
 #include "dbxout.h"
+#include "explow.h"
 #include "expmed.h"
 
 /* This file should be included last.  */
@@ -1513,173 +1514,48 @@ no_side_effect_operand(rtx op, machine_mode mode A
 
 
 /*
- * output a block move:
+ * expand a block move:
  *
  * operands[0] ... to
  * operands[1]  ... from
  * operands[2]  ... length
  * operands[3]  ... alignment
- * operands[4]  ... scratch register
  */
 
- 
-const char *
-output_block_move(rtx *operands)
+void
+expand_block_move(rtx *operands)
 {
-static int count = 0;
-char buf[200];
-int unroll;
-int lastbyte = 0;
-
-/* Move of zero bytes is a NOP.  */
-if (operands[2] == const0_rtx)
-  return "";
-
-/* Look for moves by small constant byte counts, those we'll
-   expand to straight line code.  */
-if (CONSTANT_P (operands[2]))
-{
-   if (INTVAL (operands[2]) < 16
-   && (!optimize_size || INTVAL (operands[2]) < 5)
-   && INTVAL (operands[3]) == 1)
-   {
-   register int i;
-   
-   for (i = 1; i <= INTVAL (operands[2]); i++)
-   output_asm_insn("movb\t(%1)+,(%0)+", operands);
+rtx lb, test;
+rtx fromop, toop, counter;
+int count;
 
-   return "";
-   }
-   else if (INTVAL(operands[2]) < 32
-&& (!optimize_size || INTVAL (operands[2]) < 9)
-&& INTVAL (operands[3]) >= 2)
-   {
-  

Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

[Peter Bergner]

On 10/8/18 4:14 AM, Christophe Lyon wrote:
> Since r264897, we are seeing lots of regressions when bootstrapping on arm.
> There are execution errors as well as ICEs.
> A detailed list can be found at:
> https://ci.linaro.org/job/tcwg-compare-results/6498/artifact/artifacts/logs/1-diff-d05_32.tcwg-d05_32-build.txt
> 
> You can also see the results posted on gcc-testresults.

Sorry for the breakage.  I'll try and build a cross compiler to fix the
ICEs.  Hopefully all the other issues are related.

Peter

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

[Andreas Schwab]

On Sep 20 2018, Jakub Jelinek  wrote:

> --- gcc/cp/class.c.jj 2018-09-20 09:56:59.229751895 +0200
> +++ gcc/cp/class.c2018-09-20 10:12:17.447370890 +0200
> @@ -9266,7 +9266,6 @@ build_vtbl_initializer (tree binfo,
>tree vcall_index;
>tree fn, fn_original;
>tree init = NULL_TREE;
> -  tree idx = size_int (jx++);
>  
>fn = BV_FN (v);
>fn_original = fn;
> @@ -9370,7 +9369,7 @@ build_vtbl_initializer (tree binfo,
> int i;
> if (init == size_zero_node)
>   for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
> -   CONSTRUCTOR_APPEND_ELT (*inits, idx, init);
> +   CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), init);
> else
>   for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
> {
> @@ -9378,11 +9377,11 @@ build_vtbl_initializer (tree binfo,
>fn, build_int_cst (NULL_TREE, i));
>   TREE_CONSTANT (fdesc) = 1;
>  
> - CONSTRUCTOR_APPEND_ELT (*inits, idx, fdesc);
> + CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), fdesc);
> }
>   }
>else
> - CONSTRUCTOR_APPEND_ELT (*inits, idx, init);
> + CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), init);
>  }
>  }

This still doesn't fix the tests.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Manuel López-Ibáñez]

On 07/10/18 23:38, Martin Sebor wrote:

+  pretty_printer posval;
+  if (pos != error_mark_node)
+{
+  /* Only format the position value when it's valid.  By convention
+do not quote constant integers.  */
+  pp_space (&posval);
+  if (TREE_CODE (pos) != INTEGER_CST)
+   pp_begin_quote (&posval, pp_show_color (global_dc->printer));
+  dump_generic_node (&posval, pos, 0, TDF_NONE, false);
+  if (TREE_CODE (pos) != INTEGER_CST)
+   pp_end_quote (&posval, pp_show_color (global_dc->printer));
+}


Sorry for the bike-shedding but is this really necessary?

First, you handle != INTEGER_CST separately, so you can simply use %qE for that 
case and %E for the rest. Nevertheless, I think the convention is 
(https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Quoting): "elements such as 
numbers that do no refer to numeric constants that appear in the source code 
should not be quoted". Since this is a integer constant that appears in the 
source code, then it should be quoted.


Also, "value%s" where %s can be empty, will not translate correctly.

Perhaps you need a small function:

warn_attributes(const char * msg_no_value_no_arg,
const char * msg_no_value_arg,
const char * msg_value_no_arg,
const char * msg_value_arg,
tree atname, int argno, tree pos, ...)



+  if (TREE_CODE (pos) != INTEGER_CST)
+{
+  /* Only mention the argument number when it's non-zero.  */
+  if (argno < 1)
+   warning (OPT_Wattributes,
+"%qE attribute argument value%s is not an integer "
+"constant",
+atname, pp_formatted_text (&posval));
+  else
+   warning (OPT_Wattributes,
+"%qE attribute argument %i value%s is not an integer "
+"constant",
+atname, argno, pp_formatted_text (&posval));
+   
+  return NULL_TREE;
+}


So that in the code above you can say:

if (TREE_CODE (pos) != INTEGER_CST)
{
warn_attributes("%qE attribute argument value is not an integer",
"%qE attribute argument %i value is not an integer",
"%qE attribute argument value %qE is not an integer",
"%qE attribute argument %i value %qE is not an integer",
 atname, argno, pos);
return NULL_TREE;
}

Also, I wonder where input_location is pointing at for these warnings. There 
may be a better location. Clang is doing:


:5:1: error: 'alloc_align' attribute requires parameter 1 to be an 
integer constant

ALIGN ("1") void*
^  ~~~
:1:36: note: expanded from macro 'ALIGN'
#define ALIGN(N)   __attribute__ ((alloc_align (N)))
   ^~

while GCC does:

:6:16: warning: alloc_align parameter outside range [-Wattributes]
6 | fpvi_str_1 (int);
  |^

Apart from the above, this seems a major improvement, so I hope it goes in.

Cheers,

Manuel.

Re: [Patch, fortran] PR87151 - allocating array of character

[Paul Richard Thomas]

Hi Dominique,

Thanks for the testing. Although the tests for PR80931 and PR83196,
comment #4, compiled OK, when I attempted to use the modules both
segfaulted for the same reason ('span' not being set on the array
descriptor) and these required a slightly different version of the
same tweak.

The attached regtests fine on FC28/x86_64 - OK for trunk and later for 8-branch?

Cheers

Paul

2018-10-07  Paul Thomas  

PR fortran/87151
* trans-array.c (gfc_get_array_span): Deal with deferred char
array components having a TYPE_MAX_VALUE of zero.
(gfc_array_init_size): Use the hidden string length component
to build the descriptor dtype.
(gfc_array_allocate): Remove the erroneous replacement of the
charlen backend decl with a temporary.
(gfc_conv_expr_descriptor): Use the ss_info string length in
the case of deferred character components.
(gfc_alloc_allocatable_for_assignment): Actually compare the
string lengths for deferred characters. Make sure that kind > 1
is handled correctly. Set the span field of the descriptor.
* trans-intrinsic.c (gfc_conv_intrinsic_len): Remove the stupid
comment.

PR fortran/80931
* trans-array.c (gfc_array_allocate): Set the span field for
variable length character arrays.


2018-10-07  Paul Thomas  

PR fortran/87151
* gfortran.dg/deferred_type_component_3.f90: New test.

PR fortran/80931
* gfortran.dg/deferred_character_28.f90: New test.
* gfortran.dg/deferred_character_29.f90: New test (note that
this test appears in PR83196 comment #4 by mistake).

On Mon, 8 Oct 2018 at 10:08, Dominique d'Humières  wrote:
>
> Hi Paul,
>
> Your patch works as expected. It also fixes the ICEs for the tests in pr80931
> (and the test accidentally attached to pr83196).
>
> Thanks for the patch.
>
> Dominique
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c	(revision 264918)
--- gcc/fortran/trans-array.c	(working copy)
*** gfc_get_array_span (tree desc, gfc_expr
*** 853,859 
  	 types if possible. Otherwise, return NULL_TREE.  */
tmp = gfc_get_element_type (TREE_TYPE (desc));
if (tmp && TREE_CODE (tmp) == ARRAY_TYPE
! 	  && TYPE_MAX_VALUE (TYPE_DOMAIN (tmp)) == NULL_TREE)
  	{
  	  if (expr->expr_type == EXPR_VARIABLE
  	  && expr->ts.type == BT_CHARACTER)
--- 853,860 
  	 types if possible. Otherwise, return NULL_TREE.  */
tmp = gfc_get_element_type (TREE_TYPE (desc));
if (tmp && TREE_CODE (tmp) == ARRAY_TYPE
! 	  && (TYPE_MAX_VALUE (TYPE_DOMAIN (tmp)) == NULL_TREE
! 	  || integer_zerop (TYPE_MAX_VALUE (TYPE_DOMAIN (tmp)
  	{
  	  if (expr->expr_type == EXPR_VARIABLE
  	  && expr->ts.type == BT_CHARACTER)
*** gfc_array_init_size (tree descriptor, in
*** 5366,5371 
--- 5367,5394 
tmp = gfc_conv_descriptor_dtype (descriptor);
gfc_add_modify (pblock, tmp, gfc_get_dtype_rank_type (rank, type));
  }
+   else if (expr->ts.type == BT_CHARACTER
+ 	   && expr->ts.deferred
+ 	   && TREE_CODE (descriptor) == COMPONENT_REF)
+ {
+   /* Deferred character components have their string length tucked away
+ 	 in a hidden field of the derived type. Obtain that and use it to
+ 	 set the dtype. The charlen backend decl is zero because the field
+ 	 type is zero length.  */
+   gfc_ref *ref;
+   tmp = NULL_TREE;
+   for (ref = expr->ref; ref; ref = ref->next)
+ 	if (ref->type == REF_COMPONENT
+ 	&& gfc_deferred_strlen (ref->u.c.component, &tmp))
+ 	  break;
+   gcc_assert (tmp != NULL_TREE);
+   tmp = fold_build3_loc (input_location, COMPONENT_REF, TREE_TYPE (tmp),
+ 			 TREE_OPERAND (descriptor, 0), tmp, NULL_TREE);
+   tmp = fold_convert (gfc_charlen_type_node, tmp);
+   type = gfc_get_character_type_len (expr->ts.kind, tmp);
+   tmp = gfc_conv_descriptor_dtype (descriptor);
+   gfc_add_modify (pblock, tmp, gfc_get_dtype_rank_type (rank, type));
+ }
else
  {
tmp = gfc_conv_descriptor_dtype (descriptor);
*** gfc_array_allocate (gfc_se * se, gfc_exp
*** 5774,5789 
  
if (expr->ts.type == BT_CHARACTER
&& TREE_CODE (se->string_length) == COMPONENT_REF
!   && expr->ts.u.cl->backend_decl != se->string_length)
! {
!   if (VAR_P (expr->ts.u.cl->backend_decl))
! 	gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl,
! 			fold_convert (TREE_TYPE (expr->ts.u.cl->backend_decl),
!   se->string_length));
!   else
! 	expr->ts.u.cl->backend_decl = gfc_evaluate_now (se->string_length,
! 			&se->pre);
! }
  
gfc_init_block (&set_descriptor_block);
/* Take the corank only from the actual ref and not from the coref.  The
--- 5797,5807 
  
if (expr->ts.type == BT_CHARACTER
&& TREE_CODE (se->string_length) == COMPO

Re: [PATCH 1/2] zEC12 pipeline

[Robin Dapp]

Hi,

committed only the zEC12 part for now.  Performance behavior of z13 with
the patch is still unclear and will be tackled separately.

Regards
 Robin

{Patch, fortran] PR86372 - [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable

[Paul Richard Thomas]

I have fixed this as 'obvious' on 8-branch(r264925) and trunk(r264915).

Paul

2018-10-08  Paul Thomas  

Backport from trunk
PR fortran/86372
* trans-stmt.c (trans_associate_var): Character associate names
with variable string length do not have to be deferred length
for the string length to be set, if variable.

2018-10-08  Paul Thomas  

Backport from trunk
PR fortran/86372
* gfortran.dg/associate_41.f90: New test.
Index: gcc/fortran/trans-stmt.c
===
*** gcc/fortran/trans-stmt.c	(revision 264912)
--- gcc/fortran/trans-stmt.c	(working copy)
*** trans_associate_var (gfc_symbol *sym, gf
*** 1885,1891 
  	}
  
if (sym->ts.type == BT_CHARACTER
- 	  && sym->ts.deferred
  	  && !sym->attr.select_type_temporary
  	  && VAR_P (sym->ts.u.cl->backend_decl)
  	  && se.string_length != sym->ts.u.cl->backend_decl)
--- 1885,1890 
Index: gcc/testsuite/gfortran.dg/associate_41.f90
===
*** gcc/testsuite/gfortran.dg/associate_41.f90	(nonexistent)
--- gcc/testsuite/gfortran.dg/associate_41.f90	(working copy)
***
*** 0 
--- 1,25 
+ ! { dg-do run }
+ !
+ ! Test the fix for PR86372 in which the associate name string length was
+ ! not being set, thereby causing a segfault.
+ !
+ ! Contributed by Janus Weil  
+ !
+ program xxx
+ 
+character(len=50) :: s
+ 
+s = repeat ('*', len(s))
+call sub(s)
+if (s .ne. '**'//'123'//repeat ('*', len(s) - 5)) stop 1
+ 
+ contains
+ 
+subroutine sub(str)
+   character(len=*), intent(inout) :: str
+   associate (substr => str(3:5))
+  substr = '123'
+   end associate
+end subroutine
+ 
+ end

Re: [PATCH] Come up with gcc/testsuite/g++.target/i386/i386.dg and move there some tests.

[Uros Bizjak]

On Mon, Oct 8, 2018 at 2:20 PM Martin Liška  wrote:
>
> On 10/8/18 1:29 PM, Uros Bizjak wrote:
> > On Mon, Oct 8, 2018 at 1:21 PM Jakub Jelinek  wrote:
> >>
> >> On Mon, Oct 08, 2018 at 01:17:14PM +0200, Martin Liška wrote:
> >>> I'm suggesting following patch that comes up with new g++.target 
> >>> subfolder.
> >>> I moved there i386 multiversioning tests.
> >>
> >> I think you want Uros to review and decide this one.
> >>
> >>> 2018-10-08  Martin Liska  
> >>>
> >>>   * gcc.target/i386/i386.exp: Include lib/i386.exp.
> >>>   * g++.target/i386/i386.exp: New file.
> >>>   * gcc.target/i386/mv*.C: Move here tests and remove
> >>>   target filter in these tests.
> >>>   * lib/i386.exp: New file.
> >>
> >> My preference would be to move all that content to
> >> lib/target-supports.exp, next to all the other i386 specific effective
> >> targets, rather than a new file.  That way it can be used in other
> >> testsuites too (lib*, gfortran.dg, etc.).
> >
> > I agree with the above reasoning. These tests were put in i386.exp
> > with the idea that they will be used only in the gcc.target/i386
> > directory. This is obviously not the case anymore, and as Jakub
> > mentioned, their usage will spread to other directories in the future.
> > So, please simply copy all tests from gcc.target/i386/i386.exp to
> > target-supports.exp to share them with the new g++.target directory.
> >
> > Thanks,
> > Uros.
> >> Jakub
>
> Ok, it's done in updated patch.

OK.

Thanks,
Uros.

[PATCH v2] fixincludes: vxworks: regs.h: Fix includes in regs.h wrapper

[Rasmus Villemoes]

A quick experiment reveals that this hack is needed for C code - simply
removing this hack entirely breaks the build of libstdc++, since
regs.h (more accurately, the cpu-specific header it pulls in) defines
structs in terms of types from vxTypesOld. Those definitions are
properly guarded by #ifndef _ASMLANGUAGE, but the cpu-files do not take
care to include vxTypesOld.h for the types they depend on.

But when using regs.h from some assembly file, the assembler chokes on
the typedefs in vxTypesOld.h. We can fix that by guarding the include of
vxTypesOld by !_ASMLANGUAGE. This should not affect existing C code.

Now, the OS' regs.h contains preprocessor conditionals such as

#if CPU_FAMILY==I960
...
#endif  /* CPU_FAMILY==I960 */
#if CPU_FAMILY==MC680X0
...
#endif  /* CPU_FAMILY==MC680X0 */

Without definitions of CPU_FAMILY, I960 etc., these would all be true,
which will not end well. Code using the fix-included regs.h
automatically get vxCpu.h via a chain of includes from vxTypesOld.h, but
we can make regs.h a little more self-contained for both C and asm users
by doing an explicit include of vxCpu.h.

==changelog==

fixincludes/

* inclhack.def (AAB_vxworks_regs_vxtypes): Add unconditional
include of vxCpu.h, guard include of vxTypesOld.h by
!_ASMLANGUAGE.
* fixincl.x: Regenerate.
---
 fixincludes/inclhack.def | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index f9ba9774f32..8fd9f7ef295 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -426,7 +426,17 @@ fix = {
 replace = <<- _EndOfHeader_
#ifndef _REGS_H
#define _REGS_H
+   /* regs.h depends on CPU_FAMILY being properly defined, which
+  is done by vxCpu.h.  */
+   #include 
+   /* regs.h includes a CPU_FAMILY-specific header that requires
+  vxTypesOld.h to already have been included.  Those headers
+  contain proper _ASMLANGUAGE guards around their typedefs,
+  but vxTypesOld.h itself does not. So we avoid including
+  vxTypesOld.h from assembly.  */
+   #ifndef _ASMLANGUAGE
#include 
+   #endif
#include_next 
#endif
_EndOfHeader_;
-- 
2.19.1.3.g1d92a00e68

Re: [Patch 3/3][Aarch64] Implement Aarch64 SIMD ABI

[Richard Sandiford]

Steve Ellcey  writes:
> This is the third of three patches for Aarch64 SIMD ABI support.  This
> patch is not fully tested yet but I want to post it to get comments.
>
> This is the only patch of the three that touches non-aarch64 specific
> code.  The changes here are made to allow GCC to have better information
> about what registers are clobbered by functions.  With the new SIMD
> ABI on Aarch64 the registers clobbered by a SIMD function is a subset
> of the registers clobbered by a normal (non-SIMD) function.  This can
> result in the caller saving and restoring more registers than is necessary.
>
> This patch addresses that by passing information about the call insn to 
> various routines so that they can check on what type of function is being
> called and modify the clobbered register set based on that information.
>
> As an example, this code:
>
>   __attribute__ ((__simd__ ("notinbranch"))) extern double sin (double __x);
>   __attribute__ ((__simd__ ("notinbranch"))) extern double log (double __x);
>   __attribute__ ((__simd__ ("notinbranch"))) extern double exp (double __x);
>
>   double foo(double * __restrict__ x, double * __restrict__ y,
>  double * __restrict__ z, int n)
>   {
>   int i;
>   double a = 0.0;
>   for (i = 0; i < n; i++)
>   a = a + sin(x[i]) + log(y[i]) + exp (z[i]);
>   return a;
>   }
>
> Will generate stores inside the main vectorized loop to preserve registers
> without this patch, but after the patch, will not do any stores and will
> use registers it knows the vector sin/log/exp functions do not clobber.
>
> Comments?

I think it'd be better to keep the get_call_reg_set_usage interface
the same, since:

  get_call_reg_set_usage (insn, &used_regs, call_used_reg_set);

is easier to read than:

  get_call_reg_set_usage (insn, &used_regs, true);

I don't think it would be possible as things stand for an ABI variant
to *add* call-clobbered registers here.  Instead it would need to
clobber the registers explicitly in CALL_INSN_FUNCTION_USAGE.
So I think in practice the new hook can only remove call-clobbered
registers.  It might then be better to have it filter out registers
from the set that it's given.  I.e. something like:

  targetm.remove_extra_call_preserved_regs (insn, &used_regs);

which get_call_reg_set_usage could call immediately before
returning.

The change to targetm.hard_regno_call_part_clobbered looks good.

I guess targetm.check_part_clobbered is probably an expedient
fix for now.  It might be better to call it something like
honor_part_clobbered_p, to make it clearer that the hook doesn't
actually do the checking itself.

When you submit the final patch, could you split off each hook and
interface change?  That would make things easier to review.

Thanks,
Richard

Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections

[Rainer Orth]

Hi Bernd,

> Besides, the patch seems to have produced more fallout on Solaris: I see
> many new Go testsuite failures on Solaris 10 which probably are related,
> and Solaris bootstrap with Ada included is broken due to the extended
> usage of string merging.  I'm currently investigating what's going on
> there.

I've filed PR bootstrap/87551 for the libgnat-9.so link failure.

Rainer

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

[PATCH] Better vectorizer cost model debugging

[Richard Biener]

We dump the target hook calls but sofar omit the resulting cost
(which might not be final).  It's still useful info for debugging
a target cost model.

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

Richard.

2018-10-08  Richard Biener  

* tree-vect-loop.c (vect_compute_single_scalar_iteration_cost):
Open a dump scope.
* tree-vectorizer.c (dump_stmt_cost): Add cost param and dump it.
* tree-vectorizer.h (dump_stmt_cost): Adjust.
(add_stmt_cost): Dump return value of the hook.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 264912)
+++ gcc/tree-vect-loop.c(working copy)
@@ -1072,6 +1072,8 @@ vect_compute_single_scalar_iteration_cos
   int nbbs = loop->num_nodes, factor;
   int innerloop_iters, i;
 
+  DUMP_VECT_SCOPE ("vect_compute_single_scalar_iteration_cost");
+
   /* Gather costs for statements in the scalar loop.  */
 
   /* FORNOW.  */
Index: gcc/tree-vectorizer.c
===
--- gcc/tree-vectorizer.c   (revision 264912)
+++ gcc/tree-vectorizer.c   (working copy)
@@ -89,7 +89,7 @@ dump_user_location_t vect_location;
 
 void
 dump_stmt_cost (FILE *f, void *data, int count, enum vect_cost_for_stmt kind,
-   stmt_vec_info stmt_info, int misalign,
+   stmt_vec_info stmt_info, int misalign, unsigned cost,
enum vect_cost_model_location where)
 {
   fprintf (f, "%p ", data);
@@ -159,6 +159,7 @@ dump_stmt_cost (FILE *f, void *data, int
   fprintf (f, "%s ", ks);
   if (kind == unaligned_load || kind == unaligned_store)
 fprintf (f, "(misalign %d) ", misalign);
+  fprintf (f, "costs %u ", cost);
   const char *ws = "unknown";
   switch (where)
 {
Index: gcc/tree-vectorizer.h
===
--- gcc/tree-vectorizer.h   (revision 264912)
+++ gcc/tree-vectorizer.h   (working copy)
@@ -1199,7 +1199,8 @@ init_cost (struct loop *loop_info)
 }
 
 extern void dump_stmt_cost (FILE *, void *, int, enum vect_cost_for_stmt,
-   stmt_vec_info, int, enum vect_cost_model_location);
+   stmt_vec_info, int, unsigned,
+   enum vect_cost_model_location);
 
 /* Alias targetm.vectorize.add_stmt_cost.  */
 
@@ -1208,10 +1209,12 @@ add_stmt_cost (void *data, int count, en
   stmt_vec_info stmt_info, int misalign,
   enum vect_cost_model_location where)
 {
+  unsigned cost = targetm.vectorize.add_stmt_cost (data, count, kind,
+  stmt_info, misalign, where);
   if (dump_file && (dump_flags & TDF_DETAILS))
-dump_stmt_cost (dump_file, data, count, kind, stmt_info, misalign, where);
-  return targetm.vectorize.add_stmt_cost (data, count, kind,
- stmt_info, misalign, where);
+dump_stmt_cost (dump_file, data, count, kind, stmt_info, misalign,
+   cost, where);
+  return cost;
 }
 
 /* Alias targetm.vectorize.finish_cost.  */

Re: [PATCH] Come up with gcc/testsuite/g++.target/i386/i386.dg and move there some tests.

[Martin Liška]

On 10/8/18 1:29 PM, Uros Bizjak wrote:
> On Mon, Oct 8, 2018 at 1:21 PM Jakub Jelinek  wrote:
>>
>> On Mon, Oct 08, 2018 at 01:17:14PM +0200, Martin Liška wrote:
>>> I'm suggesting following patch that comes up with new g++.target subfolder.
>>> I moved there i386 multiversioning tests.
>>
>> I think you want Uros to review and decide this one.
>>
>>> 2018-10-08  Martin Liska  
>>>
>>>   * gcc.target/i386/i386.exp: Include lib/i386.exp.
>>>   * g++.target/i386/i386.exp: New file.
>>>   * gcc.target/i386/mv*.C: Move here tests and remove
>>>   target filter in these tests.
>>>   * lib/i386.exp: New file.
>>
>> My preference would be to move all that content to
>> lib/target-supports.exp, next to all the other i386 specific effective
>> targets, rather than a new file.  That way it can be used in other
>> testsuites too (lib*, gfortran.dg, etc.).
> 
> I agree with the above reasoning. These tests were put in i386.exp
> with the idea that they will be used only in the gcc.target/i386
> directory. This is obviously not the case anymore, and as Jakub
> mentioned, their usage will spread to other directories in the future.
> So, please simply copy all tests from gcc.target/i386/i386.exp to
> target-supports.exp to share them with the new g++.target directory.
> 
> Thanks,
> Uros.
>> Jakub

Ok, it's done in updated patch.

Martin
>From f5b46864168f9807c6c19becec10ff17c19fd699 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 8 Oct 2018 13:13:23 +0200
Subject: [PATCH] Come up with gcc/testsuite/g++.target/i386/i386.dg and move
 there some tests.

gcc/testsuite/ChangeLog:

2018-10-08  Martin Liska  

	* gcc.target/i386/i386.exp: Move procedures to
	target-supports.exp.
	* g++.target/i386/i386.exp: New file.
	* gcc.target/i386/mv*.C: Move here tests and remove
	target filter in these tests.
---
 gcc/testsuite/g++.target/i386/i386.exp|  43 ++
 .../{g++.dg/ext => g++.target/i386}/mv1.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv10.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv11.C|   2 +-
 .../ext => g++.target/i386}/mv12-aux.cc   |   0
 .../{g++.dg/ext => g++.target/i386}/mv12.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv12.h|   0
 .../{g++.dg/ext => g++.target/i386}/mv13.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv14.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv15.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv16.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv17.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv18.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv19.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv2.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv20.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv21.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv22.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv23.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv24.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv25.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv26.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv27.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv3.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv4.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv5.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv6.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv7.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv8.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv9.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mvc1.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mvc2.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mvc3.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mvc4.C|   2 +-
 gcc/testsuite/gcc.target/i386/i386.exp| 471 --
 gcc/testsuite/lib/target-supports.exp | 470 +
 36 files changed, 544 insertions(+), 502 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/i386/i386.exp
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv1.C (98%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv10.C (74%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv11.C (84%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv12-aux.cc (100%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv12.C (89%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv12.h (100%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv13.C (86%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv14.C (93%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv15.C (93%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv16.C (97%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv17.C (97%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv18.C (78%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv19.C (79%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv2.C (97%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv2

Re: [Patch 1/3][Aarch64] Implement Aarch64 SIMD ABI

[Richard Sandiford]

Steve Ellcey  writes:
> @@ -1005,6 +1005,15 @@ static const struct processor *selected_tune;
>  /* The current tuning set.  */
>  struct tune_params aarch64_tune_params = generic_tunings;
>  
> +/* Table of machine attributes.  */
> +static const struct attribute_spec aarch64_attribute_table[] =
> +{
> +  /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
> +   affects_type_identity, handler, exclude } */
> +  { "aarch64_vector_pcs", 0, 0, true,  false, false, false, NULL, NULL },
> +  { NULL, 0, 0, false, false, false, false, NULL, NULL }
> +};

Maybe it would be better to make this a type attribute instead,
so that it's possible to create pointers to PCS functions without
losing the ABI information.

> @@ -1383,6 +1392,31 @@ aarch64_hard_regno_mode_ok (unsigned regno, 
> machine_mode mode)
>return false;
>  }
>  
> +/* Return true if this is a definition of a vectorized simd function.  */
> +
> +static bool
> +aarch64_simd_decl_p (tree fndecl)
> +{
> +  if (lookup_attribute ("aarch64_vector_pcs", DECL_ATTRIBUTES (fndecl)) != 
> NULL)
> +return true;
> +  if (lookup_attribute ("simd", DECL_ATTRIBUTES (fndecl)) == NULL)
> +return false;
> +  return (VECTOR_TYPE_P (TREE_TYPE (TREE_TYPE (fndecl;

Why's only the return type relevant here?  Think this deserves a comment.

> @@ -3181,7 +3215,9 @@ static bool
>  aarch64_function_ok_for_sibcall (tree decl ATTRIBUTE_UNUSED,
>tree exp ATTRIBUTE_UNUSED)
>  {
> -  /* Currently, always true.  */
> +  if (aarch64_simd_decl_p (cfun->decl))
> +return false;

This should be OK if the target is also a vector PCS function.

> @@ -4012,7 +4061,8 @@ aarch64_layout_frame (void)
>{
>   /* If there is an alignment gap between integer and fp callee-saves,
>  allocate the last fp register to it if possible.  */
> - if (regno == last_fp_reg && has_align_gap && (offset & 8) == 0)
> + if (regno == last_fp_reg && has_align_gap
> + && !simd_function && (offset & 8) == 0)
> {
>   cfun->machine->frame.reg_offset[regno] = max_int_offset;
>   break;

Nit: one condition per line once the whole thing no longer fits
on a line.

> @@ -4024,7 +4074,7 @@ aarch64_layout_frame (void)
>   else if (cfun->machine->frame.wb_candidate2 == INVALID_REGNUM
>&& cfun->machine->frame.wb_candidate1 >= V0_REGNUM)
> cfun->machine->frame.wb_candidate2 = regno;
> - offset += UNITS_PER_WORD;
> + offset += simd_function ? UNITS_PER_VREG : UNITS_PER_WORD;
>}
>  
>offset = ROUND_UP (offset, STACK_BOUNDARY / BITS_PER_UNIT);
> @@ -4167,6 +4217,10 @@ aarch64_gen_storewb_pair (machine_mode mode, rtx base, 
> rtx reg, rtx reg2,
>return gen_storewb_pairdf_di (base, base, reg, reg2,
>   GEN_INT (-adjustment),
>   GEN_INT (UNITS_PER_WORD - adjustment));
> +case E_TFmode:
> +  return gen_storewb_pairtf_di (base, base, reg, reg2,
> + GEN_INT (-adjustment),
> + GEN_INT (UNITS_PER_VREG - adjustment));
>  default:
>gcc_unreachable ();
>  }
> @@ -4179,7 +4233,7 @@ static void
>  aarch64_push_regs (unsigned regno1, unsigned regno2, HOST_WIDE_INT 
> adjustment)
>  {
>rtx_insn *insn;
> -  machine_mode mode = (regno1 <= R30_REGNUM) ? E_DImode : E_DFmode;
> +  machine_mode mode = aarch64_reg_save_mode (cfun->decl, regno1);
>  
>if (regno2 == INVALID_REGNUM)
>  return aarch64_pushwb_single_reg (mode, regno1, adjustment);
> @@ -4209,6 +4263,9 @@ aarch64_gen_loadwb_pair (machine_mode mode, rtx base, 
> rtx reg, rtx reg2,
>  case E_DFmode:
>return gen_loadwb_pairdf_di (base, base, reg, reg2, GEN_INT 
> (adjustment),
>  GEN_INT (UNITS_PER_WORD));
> +case E_TFmode:
> +  return gen_loadwb_pairtf_di (base, base, reg, reg2, GEN_INT 
> (adjustment),
> +GEN_INT (UNITS_PER_VREG));
>  default:
>gcc_unreachable ();
>  }
> @@ -4222,7 +4279,7 @@ static void
>  aarch64_pop_regs (unsigned regno1, unsigned regno2, HOST_WIDE_INT adjustment,
> rtx *cfi_ops)
>  {
> -  machine_mode mode = (regno1 <= R30_REGNUM) ? E_DImode : E_DFmode;
> +  machine_mode mode = aarch64_reg_save_mode (cfun->decl, regno1);
>rtx reg1 = gen_rtx_REG (mode, regno1);
>  
>*cfi_ops = alloc_reg_note (REG_CFA_RESTORE, reg1, *cfi_ops);
> @@ -4257,6 +4314,9 @@ aarch64_gen_store_pair (machine_mode mode, rtx mem1, 
> rtx reg1, rtx mem2,
>  case E_DFmode:
>return gen_store_pair_dw_dfdf (mem1, reg1, mem2, reg2);
>  
> +case E_TFmode:
> +  return gen_store_pair_dw_tftf (mem1, reg1, mem2, reg2);
> +
>  default:
>gcc_unreachable ();
>  }
> @@ -4277,6 +4337,9 @@ aarch64_gen_load_pair (machine_mode mode, rtx reg1, rtx 
> mem1, rtx reg2,
>  case E_DFmode:
>return gen_load_pa

Re: [PATCH] PR libstdc++/87538 fix std::not_fn exception specifications

[Jonathan Wakely]

On 08/10/18 12:59 +0100, Jonathan Wakely wrote:

PR libstdc++/87538
* include/std/functional (_Not_fn::operator()): Check value of
__is_nothrow_invocable as well.
* testsuite/20_util/function_objects/not_fn/87538.cc: New test.

Tested x86_64-linux, committed to trunk.

I'll backport this to gcc-7 and gcc-8 too.


Here's a testcase to verify the regression for
std::experimental::not_fn is fixed.

Tested x86_64-linux, committed to trunk.


commit 0bd818b99a532b88da0daa9632054cdc6ba7953a
Author: Jonathan Wakely 
Date:   Mon Oct 8 13:15:21 2018 +0100

PR libstdc++/87538 Verify fix for std::experimental::not_fn

PR libstdc++/87538
* testsuite/experimental/functional/87538.cc: New test.

diff --git a/libstdc++-v3/testsuite/experimental/functional/87538.cc b/libstdc++-v3/testsuite/experimental/functional/87538.cc
new file mode 100644
index 000..1ee9ecd55f3
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/functional/87538.cc
@@ -0,0 +1,48 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target c++14 } }
+
+#include 
+#include 
+
+struct N {
+  int operator()(int i) { if (i == 0) throw -1; return i; }
+};
+
+void
+test01()
+{
+  N n;
+  auto not_n = std::experimental::not_fn(n);
+  static_assert( !noexcept(not_n(1)), "can throw" );
+  VERIFY(not_n(1) == 0);
+  int exception = 0;
+  try {
+not_n(0);
+  }
+  catch (int e) {
+exception = e;
+  }
+  VERIFY(exception == -1);
+}
+
+int
+main()
+{
+  test01();
+}

[gomp5] Tweak OMP_AFFINITY_FORMAT handling

[Jakub Jelinek]

Hi!

With the addition of host teams, it makes a lot of sense to be able to print
also the team number and number of teams.  This change made it into OpenMP
5.0, together with various changes to mostly the short names, but two long
names too.

The following adjusts our implementation to match what will appear in OpenMP
5.0:

2018-10-08  Jakub Jelinek  

* env.c (gomp_affinity_format_var): Use %i instead of %T and
%A instead of %a.
* affinity-fmt.c (affinity_types): Change short forms h to H,
a to A, A to a and T to i.  Change long forms thread_level to
nesting_level and thread_identifier to native_thread_id.  Add
team_num/t and num_teams/T entries.
(gomp_display_affinity): Adjust for the above changes.
* testsuite/libgomp.c-c++-common/display-affinity-1.c: Likewise.
Add test also for %{team_num}, %{num_teams}, %t and %T.
* testsuite/libgomp.fortran/display-affinity-1.f90: Likewise.

--- libgomp/env.c.jj2018-07-26 16:09:18.510102373 +0200
+++ libgomp/env.c   2018-10-08 12:37:39.126304066 +0200
@@ -89,7 +89,7 @@ unsigned long gomp_places_list_len;
 int gomp_debug_var;
 unsigned int gomp_num_teams_var;
 bool gomp_display_affinity_var;
-char *gomp_affinity_format_var = "level %L thread %T affinity %a";
+char *gomp_affinity_format_var = "level %L thread %i affinity %A";
 size_t gomp_affinity_format_len;
 char *goacc_device_type;
 int goacc_device_num;
--- libgomp/affinity-fmt.c.jj   2018-05-23 16:22:32.610813049 +0200
+++ libgomp/affinity-fmt.c  2018-10-08 13:27:41.021061844 +0200
@@ -237,14 +237,16 @@ static struct affinity_types_struct affi
 {
 #define AFFINITY_TYPE(l, s) \
   { #l, sizeof (#l) - 1, s }
-  AFFINITY_TYPE (thread_level, 'L'),
+  AFFINITY_TYPE (team_num, 't'),
+  AFFINITY_TYPE (num_teams, 'T'),
+  AFFINITY_TYPE (nesting_level, 'L'),
   AFFINITY_TYPE (thread_num, 'n'),
-  AFFINITY_TYPE (host, 'h'),
-  AFFINITY_TYPE (process_id, 'P'),
-  AFFINITY_TYPE (thread_identifier, 'T'),
   AFFINITY_TYPE (num_threads, 'N'),
-  AFFINITY_TYPE (ancestor_tnum, 'A'),
-  AFFINITY_TYPE (thread_affinity, 'a')
+  AFFINITY_TYPE (ancestor_tnum, 'a'),
+  AFFINITY_TYPE (host, 'H'),
+  AFFINITY_TYPE (process_id, 'P'),
+  AFFINITY_TYPE (native_thread_id, 'i'),
+  AFFINITY_TYPE (thread_affinity, 'A')
 #undef AFFINITY_TYPE
 };
 
@@ -324,13 +326,25 @@ gomp_display_affinity (char *buffer, siz
}
   switch (c)
{
+   case 't':
+ val = omp_get_team_num ();
+ goto do_int;
+   case 'T':
+ val = omp_get_num_teams ();
+ goto do_int;
case 'L':
  val = ts->level;
  goto do_int;
case 'n':
  val = ts->team_id;
  goto do_int;
-   case 'h':
+   case 'N':
+ val = ts->team ? ts->team->nthreads : 1;
+ goto do_int;
+   case 'a':
+ val = ts->team ? ts->team->prev_ts.team_id : -1;
+ goto do_int;
+   case 'H':
  gomp_display_hostname (buffer, size, &ret, right, sz);
  break;
case 'P':
@@ -340,7 +354,7 @@ gomp_display_affinity (char *buffer, siz
  val = 0;
 #endif
  goto do_int;
-   case 'T':
+   case 'i':
 #if defined(LIBGOMP_USE_PTHREADS) && defined(__GNUC__)
  /* Handle integral pthread_t.  */
  if (__builtin_classify_type (handle) == 1)
@@ -373,13 +387,7 @@ gomp_display_affinity (char *buffer, siz
 #endif
  val = 0;
  goto do_int;
-   case 'N':
- val = ts->team ? ts->team->nthreads : 1;
- goto do_int;
case 'A':
- val = ts->team ? ts->team->prev_ts.team_id : -1;
- goto do_int;
-   case 'a':
  if (sz == (size_t) -1)
gomp_display_affinity_place (buffer, size, &ret,
 place - 1);
--- libgomp/testsuite/libgomp.c-c++-common/display-affinity-1.c.jj  
2018-05-23 11:21:57.641972727 +0200
+++ libgomp/testsuite/libgomp.c-c++-common/display-affinity-1.c 2018-10-08 
13:43:45.226946161 +0200
@@ -10,7 +10,7 @@
 int
 main ()
 {
-#define FMT "L:%0.5L%%%n>%32h%32H 32 ? l : 32) + 3 + (l > 33 ? l : 33)
 + 7 + 3 + 1 + 1 + 1))
abort ();
-  omp_set_affinity_format ("%.5L%%%32h|||%.33{host}%0.7{ancestor_tnum}"
+  omp_set_affinity_format ("%.5L%%%32H|||%.33{host}%0.7{ancestor_tnum}"
   "%3{num_threads}!%{num_threads}!");
   l3 = omp_capture_affinity (buf2, sizeof buf2, "");
   if (l3 != l2)
@@ -86,6 +86,6 @@ main ()
abort ();
 }
   #pragma omp parallel num_threads (4) proc_bind(spread)
-  omp_display_affinity ("%0.2A!%n!%.4L!%N;%a");
+  omp_display_affinity 
("%0.2a!%n!%.4L!%N;%.2t;%0.2T;%{team_num};%{num_teams};%A");
   return 0;
 }
--- libgomp/testsuite/libgomp.fortran/display-affinity-1.f90.jj 2018-05-23 
14:24:01.349865094 +0200
+++ libgomp/testsuite/libgomp.fortran/display-affinity-1.f902018-10-08 
13:47:22.664311686 +0200
@@ -9,7 +9,7 @@
   character

[PATCH] PR libstdc++/87538 fix std::not_fn exception specifications

[Jonathan Wakely]

PR libstdc++/87538
* include/std/functional (_Not_fn::operator()): Check value of
__is_nothrow_invocable as well.
* testsuite/20_util/function_objects/not_fn/87538.cc: New test.

Tested x86_64-linux, committed to trunk.

I'll backport this to gcc-7 and gcc-8 too.

commit ece63ca7236e5a85dfa6464ef7ca0a7b7b77b16d
Author: Jonathan Wakely 
Date:   Mon Oct 8 12:13:30 2018 +0100

PR libstdc++/87538 fix std::not_fn exception specifications

PR libstdc++/87538
* include/std/functional (_Not_fn::operator()): Check value of
__is_nothrow_invocable as well.
* testsuite/20_util/function_objects/not_fn/87538.cc: New test.

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index 2b46ba899dd..093528bcc4f 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -864,7 +864,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template  \
decltype(_S_not<__inv_res_t<_Fn _QUALS, _Args...>>())   \
operator()(_Args&&... __args) _QUALS\
-   noexcept(noexcept(_S_not<__inv_res_t<_Fn _QUALS, _Args...>>())) \
+   noexcept(__is_nothrow_invocable<_Fn _QUALS, _Args...>::value\
+   && noexcept(_S_not<__inv_res_t<_Fn _QUALS, _Args...>>()))   \
{   \
  return !std::__invoke(std::forward< _Fn _QUALS >(_M_fn),  \
std::forward<_Args>(__args)...);\
diff --git a/libstdc++-v3/testsuite/20_util/function_objects/not_fn/87538.cc 
b/libstdc++-v3/testsuite/20_util/function_objects/not_fn/87538.cc
new file mode 100644
index 000..7f4f0df54ae
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/function_objects/not_fn/87538.cc
@@ -0,0 +1,49 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++17" }
+// { dg-do run { target c++17 } }
+
+#include 
+#include 
+
+struct N {
+  int operator()(int i) { if (i == 0) throw -1; return i; }
+};
+
+void
+test01()
+{
+  N n;
+  auto not_n = std::not_fn(n);
+  static_assert( !noexcept(not_n(1)) );
+  VERIFY(not_n(1) == 0);
+  int exception = 0;
+  try {
+not_n(0);
+  }
+  catch (int e) {
+exception = e;
+  }
+  VERIFY(exception == -1);
+}
+
+int
+main()
+{
+  test01();
+}

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

[Joseph Myers]

On Mon, 8 Oct 2018, Richard Biener wrote:

> So I think it would be fine if we'd have -fno-math-errno as documented
> and then the C library would annotate their math functions according
> to whether they will ever set errno or not.  Once a math function is
> const or pure it cannot ever set errno so -fno-math-errno shouldn't have
> any effect.

Note that "will ever set errno" includes possibly setting it in the 
future, since code may be built with one libm version and used with 
another.  So it wouldn't be correct to have a "never sets errno" attribute 
on glibc logb / lround / llround / lrint / llrint / fma / remquo (missing 
errno setting is a known bug).  It also wouldn't be correct to have it on 
many complex.h functions, because while a requirement to set errno is 
never part of their interface, they may call real functions which may set 
errno (and may sometimes move from not setting it to setting it; e.g., 
they call the internal exp, sincos etc. functions, which for 
implementations using a wrapper do not set errno, but for implementations 
without a wrapper have errno setting integrated; whether this results in 
errno set by complex functions depends on details of exactly how they 
handle overflow etc. cases).

(Also, directly setting const/pure on most libm functions runs into issues 
of what exactly that means regarding floating-point exceptions and 
rounding modes - and the need to avoid libm specifying a stricter 
attribute than the built-in function if that results in diagnostics from 
GCC.  glibc specifies const on a few functions that don't raise exceptions 
or depend on the rounding mode, and even some of those are questionable if 
raising "invalid" for signaling NaNs is an issue.)

> glibc has the ieee entry points but I'm not sure if it has any way
> to use those by default.

__ieee754_* have never been exported from shared libm.

The old -lieee mechanism, no longer supported, involved libm function 
wrappers reading a writable global variable _LIB_VERSION to determine how 
to handle errors; depending on writable global data like that was itself 
obviously problematic.

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

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

[Rasmus Villemoes]

On 2018-09-14 14:39, Olivier Hainque wrote:
> 
> 
>> On 13 Sep 2018, at 00:25, Rasmus Villemoes  wrote:
> 
>>> What happens on your end if you just remove the hack ?
> 
>> Unfortunately, the libstdc++ build breaks:
>>
>> In file included from
>> /usr/powerpc-wrs-vxworks/wind_base/target/h/regs.h:66:0,
>> from
>> /bld/vestas/auto/work.20180912.214646/gcc-build/gcc/include-fixed/setjmp.h:57,
>> from
>> /bld/vestas/auto/work.20180912.214646/gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/csetjmp:42,
>> from
>> /bld/vestas/auto/work.20180912.214646/gcc-src/libstdc++-v3/include/precompiled/stdc++.h:42:
>> /usr/powerpc-wrs-vxworks/wind_base/target/h/arch/ppc/regsPpc.h:33:5:
>> error: 'UINT32' does not name a type
>> UINT32 cr;   /* condition register */
>> ^~
> 
> Ah, I see. Thanks for the experiment.
> 
>> I'm happy to add an include of vxCpu in the _ASMLANGUAGE case, along
>> with a big comment. But, it's also a small enough patch that we can
>> carry it internally, if you prefer that we don't touch this hack upstream.
> 
> I'm fine with a change here. It could only possibly impact inclusions
> of regs.h from assembly, and should normally improve that, so the risk
> of breaking something is very low.

OK, I'll send an updated patch in a moment, adding the vxCpu include in
the _ASMLANGUAGE case and keeping vxTypesOld out of _ASMLANGUAGE.

> I wonder how we haven't hit the stop above, as it indicates an
> inclusion of regs.h without a prior inclusion of vxTypes from the
> VxWorks setjmp.h, included unconditionally from precompiled/stdc++.h
> via csetjmp. Maybe different set of headers for different versions
> of the OS.

Yes, I believe other (newer) versions of VxWorks might have more
self-contained headers, so they themselves pull in whatever other
headers they rely on.

Rasmus

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Joseph Myers]

On Sun, 7 Oct 2018, Martin Sebor wrote:

> While still testing an enhancement in the area of attributes
> I ran across bugs and inconsistencies in how different handlers
> deal with positional arguments.  The bugs are either an ICE due
> to the handlers not consistently converting positional arguments
> to constants (i.e., CONST_DEL to INTEGER_CST in C++) for which
> downstream code is unprepared (PR 87541), or errors for valid
> code (PR 87542), or failing to diagnose invalid arguments.
> The other inconsistencies are simply in responding to the same
> invalid condition differently for different attributes .

Note there's also a common bug that, where an integer constant expression 
should be required, an INTEGER_CST of pointer type is wrongly accepted.  
There's an INTEGRAL_TYPE_P check for sentinel attributes, and for 
constructor / destructor (see gcc.dg/initpri2.c for that being tested), 
but not for others.

> PS It would be nice to have a general policy for how to respond
> to invalid attribute arguments (warning or error).  Even better,
> it would be ideal to move the validation from the front-ends and
> back-ends into the middle-end.  I.e., describe attribute arguments
> in more detail in struct attribute_spec and have decl_attributes
> validate nut just the number of arguments but also their types
> and, when appropriate, expected values.

I don't think the middle-end can handle the default_conversion part of 
things (although attribute_spec could have the information for generic 
code in the front ends, rather than every attribute handler, to do that).

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

Re: [PATCH] Come up with gcc/testsuite/g++.target/i386/i386.dg and move there some tests.

[Uros Bizjak]

On Mon, Oct 8, 2018 at 1:21 PM Jakub Jelinek  wrote:
>
> On Mon, Oct 08, 2018 at 01:17:14PM +0200, Martin Liška wrote:
> > I'm suggesting following patch that comes up with new g++.target subfolder.
> > I moved there i386 multiversioning tests.
>
> I think you want Uros to review and decide this one.
>
> > 2018-10-08  Martin Liska  
> >
> >   * gcc.target/i386/i386.exp: Include lib/i386.exp.
> >   * g++.target/i386/i386.exp: New file.
> >   * gcc.target/i386/mv*.C: Move here tests and remove
> >   target filter in these tests.
> >   * lib/i386.exp: New file.
>
> My preference would be to move all that content to
> lib/target-supports.exp, next to all the other i386 specific effective
> targets, rather than a new file.  That way it can be used in other
> testsuites too (lib*, gfortran.dg, etc.).

I agree with the above reasoning. These tests were put in i386.exp
with the idea that they will be used only in the gcc.target/i386
directory. This is obviously not the case anymore, and as Jakub
mentioned, their usage will spread to other directories in the future.
So, please simply copy all tests from gcc.target/i386/i386.exp to
target-supports.exp to share them with the new g++.target directory.

Thanks,
Uros.
> Jakub

Re: [PATCH] Come up with gcc/testsuite/g++.target/i386/i386.dg and move there some tests.

[Jakub Jelinek]

On Mon, Oct 08, 2018 at 01:17:14PM +0200, Martin Liška wrote:
> I'm suggesting following patch that comes up with new g++.target subfolder.
> I moved there i386 multiversioning tests.

I think you want Uros to review and decide this one.

> 2018-10-08  Martin Liska  
> 
>   * gcc.target/i386/i386.exp: Include lib/i386.exp.
>   * g++.target/i386/i386.exp: New file.
>   * gcc.target/i386/mv*.C: Move here tests and remove
>   target filter in these tests.
>   * lib/i386.exp: New file.

My preference would be to move all that content to
lib/target-supports.exp, next to all the other i386 specific effective
targets, rather than a new file.  That way it can be used in other
testsuites too (lib*, gfortran.dg, etc.).

Jakub

[PATCH] Come up with gcc/testsuite/g++.target/i386/i386.dg and move there some tests.

[Martin Liška]

Hi.

I'm suggesting following patch that comes up with new g++.target subfolder.
I moved there i386 multiversioning tests.

Ready for trunk?
Martin
>From 152e66a766b69019ef6632276579d9fa9f14f4c4 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 8 Oct 2018 13:13:23 +0200
Subject: [PATCH] Come up with gcc/testsuite/g++.target/i386/i386.dg and move there some tests.

gcc/testsuite/ChangeLog:

2018-10-08  Martin Liska  

	* gcc.target/i386/i386.exp: Include lib/i386.exp.
	* g++.target/i386/i386.exp: New file.
	* gcc.target/i386/mv*.C: Move here tests and remove
	target filter in these tests.
	* lib/i386.exp: New file.
---
 gcc/testsuite/g++.target/i386/i386.exp|  44 ++
 .../{g++.dg/ext => g++.target/i386}/mv1.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv10.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv11.C|   2 +-
 .../ext => g++.target/i386}/mv12-aux.cc   |   0
 .../{g++.dg/ext => g++.target/i386}/mv12.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv12.h|   0
 .../{g++.dg/ext => g++.target/i386}/mv13.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv14.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv15.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv16.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv17.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv18.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv19.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv2.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv20.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv21.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv22.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv23.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv24.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv25.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv26.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv27.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv3.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv4.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv5.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv6.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv7.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv8.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mv9.C |   2 +-
 .../{g++.dg/ext => g++.target/i386}/mvc1.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mvc2.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mvc3.C|   2 +-
 .../{g++.dg/ext => g++.target/i386}/mvc4.C|   2 +-
 gcc/testsuite/gcc.target/i386/i386.exp| 472 +
 gcc/testsuite/lib/i386.exp| 488 ++
 36 files changed, 564 insertions(+), 502 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/i386/i386.exp
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv1.C (98%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv10.C (74%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv11.C (84%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv12-aux.cc (100%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv12.C (89%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv12.h (100%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv13.C (86%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv14.C (93%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv15.C (93%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv16.C (97%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv17.C (97%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv18.C (78%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv19.C (79%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv2.C (97%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv20.C (79%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv21.C (78%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv22.C (79%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv23.C (79%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv24.C (91%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv25.C (91%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv26.C (82%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv27.C (82%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv3.C (93%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv4.C (89%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv5.C (88%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv6.C (89%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv7.C (80%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv8.C (57%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mv9.C (80%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mvc1.C (88%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mvc2.C (88%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mvc3.C (88%)
 rename gcc/testsuite/{g++.dg/ext => g++.target/i386}/mvc4.C (88%)
 create m

Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections

[Rainer Orth]

Hi Bernd,

> On 10/05/18 20:15, Andreas Schwab wrote:
>> On Sep 14 2018, Bernd Edlinger  wrote:
>> 
>>> diff -Npur gcc/testsuite/gnat.dg/string_merge1.adb
>>> gcc/testsuite/gnat.dg/string_merge1.adb
>>> --- gcc/testsuite/gnat.dg/string_merge1.adb 1970-01-01
>>> 01:00:00.0 +0100
>>> +++ gcc/testsuite/gnat.dg/string_merge1.adb 2018-08-26
>>> 16:31:12.650271931 +0200
>>> @@ -0,0 +1,19 @@
>>> +-- { dg-do compile }
>>> +-- { dg-options "-O1 -fmerge-all-constants" }
>>> +
>>> +procedure String_Merge1 is
>>> +   procedure Process (X : String);
>>> +   pragma Import (Ada, Process);
>>> +begin
>>> +   Process ("ABCD");
>>> +end;
>>> +
>>> +-- We expect something like:
>>> +
>>> +-- .section  .rodata.str1.1,"aMS",@progbits,1
>>> +-- .LC1:
>>> +-- .string "ABCD"
>>> +
>>> +-- { dg-final { scan-assembler-times "\\.rodata\\.str" 1 } }
>>> +-- { dg-final { scan-assembler-times "\\.string" 1 } }
>>> +-- { dg-final { scan-assembler-times "\"ABCD\"" 1 } }
>> 
>> FAIL: gnat.dg/string_merge1.adb scan-assembler-times \\.string 1
>> 
>> $ grep ABCD string_merge1.s
>>  stringz "ABCD"
>> 
>
> Ah, thanks.
>
> Turns out there are too much variations, like mentioned stringz, and asciz, 
> and
> probably lots more here.
>
> But for the purpose of testing the optimization it should be sufficient to 
> look for
> ".rodata.str" in the assembler.
>
> So I committed the following as obvious:

unfortunately that patch is not enough and still shows a fundamental
problem:

* The tests still FAIL on Solaris with /bin/as and Darwin:

FAIL: gcc.dg/merge-all-constants-2.c scan-assembler-not .rodata[\\n\\r]

FAIL: gnat.dg/string_merge1.adb scan-assembler-times .rodata.str 1
FAIL: gnat.dg/string_merge2.adb scan-assembler-times .rodata.str 1

  Both targets lack string merging support, so the tests should check
  for that.

* The merge-all-constants-2.c test doesn't FAIL on Solaris/SPARC with
  /bin/as, although it lacks string merging support, too.  The assembler
  output contains

.section".rodata"

  so the pattern currently used to check for .rodata is too
  restrictive.  There is assembler syntax beyond gas on x86 ;-)

The following patch fixes the former issue; tested on
sparc-sun-solaris2.11 with as (no string merging) resp. gas (with string
merging).  Installed on mainline.

Besides, the patch seems to have produced more fallout on Solaris: I see
many new Go testsuite failures on Solaris 10 which probably are related,
and Solaris bootstrap with Ada included is broken due to the extended
usage of string merging.  I'm currently investigating what's going on
there.

Rainer

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


2018-10-08  Rainer Orth  

* gcc.dg/merge-all-constants-2.c: Require string_merging support.
* gnat.dg/string_merge1.adb: Likewise.
* gnat.dg/string_merge2.adb: Likewise.

# HG changeset patch
# Parent  69da4995a4d01be3b3fb5cbf466648a814da22b1
Require string merging support in gnat.dg/string_merge?.adb etc.

diff --git a/gcc/testsuite/gcc.dg/merge-all-constants-2.c b/gcc/testsuite/gcc.dg/merge-all-constants-2.c
--- a/gcc/testsuite/gcc.dg/merge-all-constants-2.c
+++ b/gcc/testsuite/gcc.dg/merge-all-constants-2.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target string_merging } */
 /* { dg-options "-w -O2 -fmerge-all-constants" } */
 
 const char str1[36] = "0123456789abcdefghijklmnopqrstuvwxyz";
diff --git a/gcc/testsuite/gnat.dg/string_merge1.adb b/gcc/testsuite/gnat.dg/string_merge1.adb
--- a/gcc/testsuite/gnat.dg/string_merge1.adb
+++ b/gcc/testsuite/gnat.dg/string_merge1.adb
@@ -1,4 +1,5 @@
 -- { dg-do compile }
+-- { dg-require-effective-target string_merging }
 -- { dg-options "-O1 -fmerge-all-constants" }
 
 procedure String_Merge1 is
diff --git a/gcc/testsuite/gnat.dg/string_merge2.adb b/gcc/testsuite/gnat.dg/string_merge2.adb
--- a/gcc/testsuite/gnat.dg/string_merge2.adb
+++ b/gcc/testsuite/gnat.dg/string_merge2.adb
@@ -1,4 +1,5 @@
 -- { dg-do compile }
+-- { dg-require-effective-target string_merging }
 -- { dg-options "-O1 -fmerge-all-constants" }
 
 procedure String_Merge2 is

Re: Add new warning flag "warn_prio_ctor_dtor"

[Rainer Orth]

Jeff Law  writes:

> On 9/3/18 8:48 AM, Vinay Kumar wrote:
>> Hi Joseph,
>> 
 The documentation is of a new option, not of -Wreturn-type 
>> Done
>> 
 you should list the option as -Wno-prio-ctor-dtor when documenting 
>> Done
>> 
 You're not meant to have the literal text ", no ()" in the manual 
>> Sorry for the confusion. Modified it accordingly
>> 
 I don't see why a g++.dg one is needed as well 
>> Removed.
>> 
>> Thanks for reviewing the patch and your suggestions.
>> Please find attached the modified patch as per your review comments.
>> Please review the patch and let me know if its okay?
>> 
>> Thanks,
>> Vinay
>> 
>> 
>> Wprio-ctor-dtor.patch
> [ ... ]
> THanks.  I've installed this on the trunk.

the new test FAILs on Solaris 10 and Darwin:

+FAIL: c-c++-common/Wprio-ctor-dtor.c  -std=gnu++11 (test for excess errors)
+FAIL: c-c++-common/Wprio-ctor-dtor.c  -std=gnu++14 (test for excess errors)
+FAIL: c-c++-common/Wprio-ctor-dtor.c  -std=gnu++98 (test for excess errors)

+FAIL: c-c++-common/Wprio-ctor-dtor.c  -Wc++-compat  (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c:4:1: 
error: constructor priorities are not supported
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c:5:1: 
error: constructor priorities are not supported
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c:6:1: 
error: constructor priorities are not supported
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c:7:1: 
error: destructor priorities are not supported
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c:8:1: 
error: destructor priorities are not supported
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c:9:1: 
error: destructor priorities are not supported

Fixed as follows.  Tested on i386-pc-solaris2.10 and i386-pc-solaris2.11
(which supports constructor priorities), installed on mainline.

Rainer

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


2018-10-08  Rainer Orth  

* c-c++-common/Wprio-ctor-dtor.c: Require init_priority support.

# HG changeset patch
# Parent  cc66d1590b066afb38169d9313af97f741401e80
Require constructor priority support in c-c++-common/Wprio-ctor-dtor.c

diff --git a/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c b/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c
--- a/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c
+++ b/gcc/testsuite/c-c++-common/Wprio-ctor-dtor.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target init_priority } */
 /* { dg-options "-Wno-prio-ctor-dtor" } */
 
 void construct1 () __attribute__ ((constructor (10)));

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Richard Earnshaw (lists)]

On 08/10/18 11:29, Richard Biener wrote:
> On Mon, Oct 8, 2018 at 12:14 PM Martin Liška  wrote:
>>
>> On 10/8/18 11:55 AM, Richard Earnshaw (lists) wrote:
>>> On 08/10/18 10:47, Martin Liška wrote:
 On 10/8/18 10:46 AM, Renlin Li wrote:
> Hi Martin,
>
> pr82625.C failed on compiler builds which don't support "default" and 
> "avx" target.
> For example, arm/aarch64 native linux gcc compiler.
>
>
> As I found in this gcc wiki: 
> https://gcc.gnu.org/wiki/FunctionMultiVersioning
> '''
> This support is available in GCC 4.8 and later. Support is only available 
> in C++ for i386 targets.
> '''
>
> Should the test be guarded with a target selector or require function 
> multi-versioning instead of ifunc?

 Hi.

 Sure, sorry for the breakage. I'm going to install following tested patch.

 Martin

>
> Regards,
> Renlin
>
>
> On 10/04/2018 02:56 PM, Martin Liška wrote:
>> Hi.
>>
>> When having a pair of target clones where foo calls bar, if the target
>> attribute are equal we can redirect the call and not use ifunc 
>> dispatcher.
>>
>> Patch survives regression tests on x86_64-linux-gnu.
>> Ready for trunk?
>>
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2018-10-04  Martin Liska  
>>
>> PR ipa/82625
>> * multiple_target.c (redirect_to_specific_clone): New function.
>> (ipa_target_clone): Use it.
>> * tree-inline.c: Fix comment.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-10-04  Martin Liska  
>>
>> PR ipa/82625
>> * g++.dg/ext/pr82625.C: New test.
>> ---
>>   gcc/multiple_target.c  | 51 ++
>>   gcc/testsuite/g++.dg/ext/pr82625.C | 36 +
>>   gcc/tree-inline.c  |  2 +-
>>   3 files changed, 88 insertions(+), 1 deletion(-)
>>   create mode 100644 gcc/testsuite/g++.dg/ext/pr82625.C
>>
>>


 0001-Limit-a-MV-test-just-for-x86-target.patch


 From e3053abe58eba832262db0af77980012010a642c Mon Sep 17 00:00:00 2001
 From: marxin 
 Date: Mon, 8 Oct 2018 11:07:29 +0200
 Subject: [PATCH] Limit a MV test just for x86 target.

 gcc/testsuite/ChangeLog:

 2018-10-08  Martin Liska  

  * g++.dg/ext/pr82625.C: Add dg-compile filter.
 ---
  gcc/testsuite/g++.dg/ext/pr82625.C | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/gcc/testsuite/g++.dg/ext/pr82625.C 
 b/gcc/testsuite/g++.dg/ext/pr82625.C
 index 47bd2df1104..59b174f8c51 100644
 --- a/gcc/testsuite/g++.dg/ext/pr82625.C
 +++ b/gcc/testsuite/g++.dg/ext/pr82625.C
 @@ -1,6 +1,7 @@
  /* { dg-do compile } */
  /* { dg-require-ifunc "" } */
  /* { dg-options "-O2 -fdump-tree-optimized" } */
 +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */

  __attribute__ ((target ("default")))
  static unsigned foo(const char *buf, unsigned size) {

>>>
>>> Which begs the question why is this not put under g++.target?
>>>
>>> R.
>>>
>>
>> Agree, apparently we have quite some tests that should be moved:
>> gcc/testsuite/g++.dg/ext/pr57362.C:/* { dg-require-ifunc "" }  */
>> gcc/testsuite/g++.dg/ext/pr57548.C:/* { dg-require-ifunc "" }  */
>> gcc/testsuite/g++.dg/ext/pr82625.C:/* { dg-require-ifunc "" } */
>> gcc/testsuite/g++.dg/ext/pr85329-2.C:/* { dg-require-ifunc "" } */
>> gcc/testsuite/g++.dg/ext/pr85329.C:/* { dg-require-ifunc "" } */
>> ...
>> gcc/testsuite/g++.dg/ext/mv*.C
> 
> You cannot move C++ tests to gcc.target/

Which is why I said g++.target...

R.

> 
>> I'll prepare patch for it.
>> Martin
>>

[PATCH][i386] Update Zen tuning for vector load cost

[Richard Biener]

This adjusts Zen AVX256 vector load cost to be twice as expensive
than AVX128 vector load cost (twice via ix86_vec_cost keying on
TARGET_AVX128_OPTIMAL - should rather use some
TARGET_VECTOR_IMPL_WIDTH or so).

Likely the current cost value was meant to make AVX256 loads _cheaper_
than two AVX128 ones in which case we'd have to use 5 here.  Honza,
what was the intent here?  Maybe not call ix86_vec_cost for loads or
stores at all (given we model different sizes explicitely?)?  The
odd thing is that in some places you pass ix86_vec_cost
COSNTS_N_INSNS (ix86_cost->...) and in others just
ix86_cost->  That's probably caused by most entries in the cost
tables being scaled via COSTS_N_INSNS but not all which makes them
not easily comparable... (I found a comment that says
"We assume COSTS_N_INSNS is defined as (N)*4")

That ix86_vec_cost adds a factor of two for AVX256 also is throwing
throughput into the mix because latency-wise AVX256 behaves the
same as AVX128 AFAICs.  That is, the modeling isn't very precise...
(multiplying by two still makes sense IMHO - but for example stores
have only one 128bit port so those are the ones that should be
more than factor-of-two pessimized if any)

Anyhow, the patch removes one oddity comparing costs of vectorized
loops when there are no lane-crossing operations (after the patch
such loops will cost the same with AVX128 and AVX256 even though
Zens frontend will benefit from using AVX256).

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

OK?

Thanks,
Richard.

2018-10-08  Richard Biener  

* config/i386/x86-tune-costs.h (znver1_cost): Make AVX256 vector loads
cost the same as AVX128 ones.

diff --git a/gcc/config/i386/x86-tune-costs.h b/gcc/config/i386/x86-tune-costs.h
index 71a5854c09a..c7f3945d72c 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -1518,9 +1518,9 @@ struct processor_costs znver1_cost = {
   {8, 8},  /* cost of storing MMX registers
   in SImode and DImode.  */
   2, 3, 6, /* cost of moving XMM,YMM,ZMM register. 
 */
-  {6, 6, 6, 10, 20},   /* cost of loading SSE registers
+  {6, 6, 6, 6, 12},/* cost of loading SSE registers
   in 32,64,128,256 and 512-bit.  */
-  {6, 6, 6, 10, 20},   /* cost of unaligned loads.  */
+  {6, 6, 6, 6, 12},/* cost of unaligned loads.  */
   {8, 8, 8, 8, 16},/* cost of storing SSE registers
   in 32,64,128,256 and 512-bit.  */
   {8, 8, 8, 8, 16},/* cost of unaligned stores.  */

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Martin Liška]

On 10/8/18 12:46 PM, Jakub Jelinek wrote:
> On Mon, Oct 08, 2018 at 12:34:19PM +0200, Martin Liška wrote:
 gcc/testsuite/g++.dg/ext/mv*.C
>>>
>>> You cannot move C++ tests to gcc.target/
>>
>> I realized that we don't have ./gcc/testsuite/g++.target/i386 yet :/
> 
> But we want it and there are multiple tests waiting for that move.
> 
>   Jakub
> 

I'll try to set it up.

Martin

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Jakub Jelinek]

On Mon, Oct 08, 2018 at 12:34:19PM +0200, Martin Liška wrote:
> >> gcc/testsuite/g++.dg/ext/mv*.C
> > 
> > You cannot move C++ tests to gcc.target/
> 
> I realized that we don't have ./gcc/testsuite/g++.target/i386 yet :/

But we want it and there are multiple tests waiting for that move.

Jakub

Re: [PATCH] Provide extension hint for aarch64 target (PR driver/83193).

[Martin Liška]

Hi.

I'm attaching updated version of the patch.

Martin
>From d36974540cda9fb0e159103fdcf92d26ef2f1b94 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 4 Oct 2018 16:31:49 +0200
Subject: [PATCH] Provide extension hint for aarch64 target (PR driver/83193).

gcc/ChangeLog:

2018-10-05  Martin Liska  

	PR driver/83193
	* common/config/aarch64/aarch64-common.c (aarch64_parse_extension):
	Add new argument invalid_extension.
	(aarch64_get_all_extension_candidates): New function.
	(aarch64_rewrite_selected_cpu): Add NULL to function call.
	* config/aarch64/aarch64-protos.h (aarch64_parse_extension): Add
	new argument.
	(aarch64_get_all_extension_candidates): New function.
	* config/aarch64/aarch64.c (aarch64_parse_arch): Add new
	argument invalid_extension.
	(aarch64_parse_cpu): Likewise.
	(aarch64_print_hint_for_extensions): New function.
	(aarch64_validate_mcpu): Provide hint about invalid extension.
	(aarch64_validate_march): Likewise.
	(aarch64_handle_attr_arch): Pass new argument.
	(aarch64_handle_attr_cpu): Provide hint about invalid extension.
	(aarch64_handle_attr_isa_flags): Likewise.

gcc/testsuite/ChangeLog:

2018-10-05  Martin Liska  

	PR driver/83193
	* gcc.target/aarch64/spellcheck_7.c: New test.
	* gcc.target/aarch64/spellcheck_8.c: New test.
	* gcc.target/aarch64/spellcheck_9.c: New test.
---
 gcc/common/config/aarch64/aarch64-common.c| 24 +-
 gcc/config/aarch64/aarch64-protos.h   |  4 +-
 gcc/config/aarch64/aarch64.c  | 75 +++
 .../gcc.target/aarch64/spellcheck_7.c | 12 +++
 .../gcc.target/aarch64/spellcheck_8.c | 13 
 .../gcc.target/aarch64/spellcheck_9.c | 13 
 6 files changed, 121 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_7.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_8.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_9.c

diff --git a/gcc/common/config/aarch64/aarch64-common.c b/gcc/common/config/aarch64/aarch64-common.c
index ffddc4d16d8..2bebe70c021 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -220,10 +220,13 @@ static const struct arch_to_arch_name all_architectures[] =
 
 /* Parse the architecture extension string STR and update ISA_FLAGS
with the architecture features turned on or off.  Return a
-   aarch64_parse_opt_result describing the result.  */
+   aarch64_parse_opt_result describing the result.
+   When the STR string contains an invalid extension,
+   a copy of the string is created and stored to INVALID_EXTENSION.  */
 
 enum aarch64_parse_opt_result
-aarch64_parse_extension (const char *str, unsigned long *isa_flags)
+aarch64_parse_extension (const char *str, unsigned long *isa_flags,
+			 char **invalid_extension)
 {
   /* The extension string is parsed left to right.  */
   const struct aarch64_option_extension *opt = NULL;
@@ -274,6 +277,11 @@ aarch64_parse_extension (const char *str, unsigned long *isa_flags)
   if (opt->name == NULL)
 	{
 	  /* Extension not found in list.  */
+	  if (invalid_extension)
+	{
+	  *invalid_extension = xstrdup (str);
+	  (*invalid_extension)[len] = '\0';
+	}
 	  return AARCH64_PARSE_INVALID_FEATURE;
 	}
 
@@ -283,6 +291,16 @@ aarch64_parse_extension (const char *str, unsigned long *isa_flags)
   return AARCH64_PARSE_OK;
 }
 
+/* Append all architecture extension candidates to the CANDIDATES vector.  */
+
+void
+aarch64_get_all_extension_candidates (auto_vec *candidates)
+{
+  const struct aarch64_option_extension *opt;
+  for (opt = all_extensions; opt->name != NULL; opt++)
+candidates->safe_push (opt->name);
+}
+
 /* Return a string representation of ISA_FLAGS.  DEFAULT_ARCH_FLAGS
gives the default set of flags which are implied by whatever -march
we'd put out.  Our job is to figure out the minimal set of "+" and
@@ -370,7 +388,7 @@ aarch64_rewrite_selected_cpu (const char *name)
 fatal_error (input_location, "unknown value %qs for -mcpu", name);
 
   unsigned long extensions = p_to_a->flags;
-  aarch64_parse_extension (extension_str.c_str (), &extensions);
+  aarch64_parse_extension (extension_str.c_str (), &extensions, NULL);
 
   std::string outstr = a_to_an->arch_name
 	+ aarch64_get_extension_string_for_isa_flags (extensions,
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 5f18837418e..2f1b0b10250 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -616,7 +616,9 @@ bool aarch64_handle_option (struct gcc_options *, struct gcc_options *,
 			 const struct cl_decoded_option *, location_t);
 const char *aarch64_rewrite_selected_cpu (const char *name);
 enum aarch64_parse_opt_result aarch64_parse_extension (const char *,
-		   unsigned long *);
+		   unsigned long *,
+		   char **);
+void aarch64_get_all_extension_candidates (auto_vec *candidates);
 std::st

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Martin Liška]

On 10/8/18 12:29 PM, Richard Biener wrote:
> On Mon, Oct 8, 2018 at 12:14 PM Martin Liška  wrote:
>>
>> On 10/8/18 11:55 AM, Richard Earnshaw (lists) wrote:
>>> On 08/10/18 10:47, Martin Liška wrote:
 On 10/8/18 10:46 AM, Renlin Li wrote:
> Hi Martin,
>
> pr82625.C failed on compiler builds which don't support "default" and 
> "avx" target.
> For example, arm/aarch64 native linux gcc compiler.
>
>
> As I found in this gcc wiki: 
> https://gcc.gnu.org/wiki/FunctionMultiVersioning
> '''
> This support is available in GCC 4.8 and later. Support is only available 
> in C++ for i386 targets.
> '''
>
> Should the test be guarded with a target selector or require function 
> multi-versioning instead of ifunc?

 Hi.

 Sure, sorry for the breakage. I'm going to install following tested patch.

 Martin

>
> Regards,
> Renlin
>
>
> On 10/04/2018 02:56 PM, Martin Liška wrote:
>> Hi.
>>
>> When having a pair of target clones where foo calls bar, if the target
>> attribute are equal we can redirect the call and not use ifunc 
>> dispatcher.
>>
>> Patch survives regression tests on x86_64-linux-gnu.
>> Ready for trunk?
>>
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2018-10-04  Martin Liska  
>>
>> PR ipa/82625
>> * multiple_target.c (redirect_to_specific_clone): New function.
>> (ipa_target_clone): Use it.
>> * tree-inline.c: Fix comment.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-10-04  Martin Liska  
>>
>> PR ipa/82625
>> * g++.dg/ext/pr82625.C: New test.
>> ---
>>   gcc/multiple_target.c  | 51 ++
>>   gcc/testsuite/g++.dg/ext/pr82625.C | 36 +
>>   gcc/tree-inline.c  |  2 +-
>>   3 files changed, 88 insertions(+), 1 deletion(-)
>>   create mode 100644 gcc/testsuite/g++.dg/ext/pr82625.C
>>
>>


 0001-Limit-a-MV-test-just-for-x86-target.patch


 From e3053abe58eba832262db0af77980012010a642c Mon Sep 17 00:00:00 2001
 From: marxin 
 Date: Mon, 8 Oct 2018 11:07:29 +0200
 Subject: [PATCH] Limit a MV test just for x86 target.

 gcc/testsuite/ChangeLog:

 2018-10-08  Martin Liska  

  * g++.dg/ext/pr82625.C: Add dg-compile filter.
 ---
  gcc/testsuite/g++.dg/ext/pr82625.C | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/gcc/testsuite/g++.dg/ext/pr82625.C 
 b/gcc/testsuite/g++.dg/ext/pr82625.C
 index 47bd2df1104..59b174f8c51 100644
 --- a/gcc/testsuite/g++.dg/ext/pr82625.C
 +++ b/gcc/testsuite/g++.dg/ext/pr82625.C
 @@ -1,6 +1,7 @@
  /* { dg-do compile } */
  /* { dg-require-ifunc "" } */
  /* { dg-options "-O2 -fdump-tree-optimized" } */
 +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */

  __attribute__ ((target ("default")))
  static unsigned foo(const char *buf, unsigned size) {

>>>
>>> Which begs the question why is this not put under g++.target?
>>>
>>> R.
>>>
>>
>> Agree, apparently we have quite some tests that should be moved:
>> gcc/testsuite/g++.dg/ext/pr57362.C:/* { dg-require-ifunc "" }  */
>> gcc/testsuite/g++.dg/ext/pr57548.C:/* { dg-require-ifunc "" }  */
>> gcc/testsuite/g++.dg/ext/pr82625.C:/* { dg-require-ifunc "" } */
>> gcc/testsuite/g++.dg/ext/pr85329-2.C:/* { dg-require-ifunc "" } */
>> gcc/testsuite/g++.dg/ext/pr85329.C:/* { dg-require-ifunc "" } */
>> ...
>> gcc/testsuite/g++.dg/ext/mv*.C
> 
> You cannot move C++ tests to gcc.target/

I realized that we don't have ./gcc/testsuite/g++.target/i386 yet :/

Martin

> 
>> I'll prepare patch for it.
>> Martin
>>

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Richard Biener]

On Mon, Oct 8, 2018 at 12:14 PM Martin Liška  wrote:
>
> On 10/8/18 11:55 AM, Richard Earnshaw (lists) wrote:
> > On 08/10/18 10:47, Martin Liška wrote:
> >> On 10/8/18 10:46 AM, Renlin Li wrote:
> >>> Hi Martin,
> >>>
> >>> pr82625.C failed on compiler builds which don't support "default" and 
> >>> "avx" target.
> >>> For example, arm/aarch64 native linux gcc compiler.
> >>>
> >>>
> >>> As I found in this gcc wiki: 
> >>> https://gcc.gnu.org/wiki/FunctionMultiVersioning
> >>> '''
> >>> This support is available in GCC 4.8 and later. Support is only available 
> >>> in C++ for i386 targets.
> >>> '''
> >>>
> >>> Should the test be guarded with a target selector or require function 
> >>> multi-versioning instead of ifunc?
> >>
> >> Hi.
> >>
> >> Sure, sorry for the breakage. I'm going to install following tested patch.
> >>
> >> Martin
> >>
> >>>
> >>> Regards,
> >>> Renlin
> >>>
> >>>
> >>> On 10/04/2018 02:56 PM, Martin Liška wrote:
>  Hi.
> 
>  When having a pair of target clones where foo calls bar, if the target
>  attribute are equal we can redirect the call and not use ifunc 
>  dispatcher.
> 
>  Patch survives regression tests on x86_64-linux-gnu.
>  Ready for trunk?
> 
>  Martin
> 
>  gcc/ChangeLog:
> 
>  2018-10-04  Martin Liska  
> 
>  PR ipa/82625
>  * multiple_target.c (redirect_to_specific_clone): New function.
>  (ipa_target_clone): Use it.
>  * tree-inline.c: Fix comment.
> 
>  gcc/testsuite/ChangeLog:
> 
>  2018-10-04  Martin Liska  
> 
>  PR ipa/82625
>  * g++.dg/ext/pr82625.C: New test.
>  ---
>    gcc/multiple_target.c  | 51 ++
>    gcc/testsuite/g++.dg/ext/pr82625.C | 36 +
>    gcc/tree-inline.c  |  2 +-
>    3 files changed, 88 insertions(+), 1 deletion(-)
>    create mode 100644 gcc/testsuite/g++.dg/ext/pr82625.C
> 
> 
> >>
> >>
> >> 0001-Limit-a-MV-test-just-for-x86-target.patch
> >>
> >>
> >> From e3053abe58eba832262db0af77980012010a642c Mon Sep 17 00:00:00 2001
> >> From: marxin 
> >> Date: Mon, 8 Oct 2018 11:07:29 +0200
> >> Subject: [PATCH] Limit a MV test just for x86 target.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >> 2018-10-08  Martin Liska  
> >>
> >>  * g++.dg/ext/pr82625.C: Add dg-compile filter.
> >> ---
> >>  gcc/testsuite/g++.dg/ext/pr82625.C | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/gcc/testsuite/g++.dg/ext/pr82625.C 
> >> b/gcc/testsuite/g++.dg/ext/pr82625.C
> >> index 47bd2df1104..59b174f8c51 100644
> >> --- a/gcc/testsuite/g++.dg/ext/pr82625.C
> >> +++ b/gcc/testsuite/g++.dg/ext/pr82625.C
> >> @@ -1,6 +1,7 @@
> >>  /* { dg-do compile } */
> >>  /* { dg-require-ifunc "" } */
> >>  /* { dg-options "-O2 -fdump-tree-optimized" } */
> >> +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
> >>
> >>  __attribute__ ((target ("default")))
> >>  static unsigned foo(const char *buf, unsigned size) {
> >>
> >
> > Which begs the question why is this not put under g++.target?
> >
> > R.
> >
>
> Agree, apparently we have quite some tests that should be moved:
> gcc/testsuite/g++.dg/ext/pr57362.C:/* { dg-require-ifunc "" }  */
> gcc/testsuite/g++.dg/ext/pr57548.C:/* { dg-require-ifunc "" }  */
> gcc/testsuite/g++.dg/ext/pr82625.C:/* { dg-require-ifunc "" } */
> gcc/testsuite/g++.dg/ext/pr85329-2.C:/* { dg-require-ifunc "" } */
> gcc/testsuite/g++.dg/ext/pr85329.C:/* { dg-require-ifunc "" } */
> ...
> gcc/testsuite/g++.dg/ext/mv*.C

You cannot move C++ tests to gcc.target/

> I'll prepare patch for it.
> Martin
>

Re: [patch] Fix PR tree-optimization/86659

[Richard Biener]

On Fri, Oct 5, 2018 at 10:29 AM Eric Botcazou  wrote:
>
> > So I wonder why it is necessary to track 'reverse' in gimple_match_op
> > at all given we bail out without optimizing as far as I can see?
>
> Because of the valueization?  If it is done, gimple_simplify returns true so
> the result will be synthetized from res_op by means of maybe_build_generic_op.
> That's what I was referring to in the opening message by "the underlying issue
> of the missing propagation of the flag during GIMPLE folding".

Ah, indeed.

Patch is OK - sorry for the confusion.

Richard.

> --
> Eric Botcazou

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Martin Liška]

On 10/8/18 11:55 AM, Richard Earnshaw (lists) wrote:
> On 08/10/18 10:47, Martin Liška wrote:
>> On 10/8/18 10:46 AM, Renlin Li wrote:
>>> Hi Martin,
>>>
>>> pr82625.C failed on compiler builds which don't support "default" and "avx" 
>>> target.
>>> For example, arm/aarch64 native linux gcc compiler.
>>>
>>>
>>> As I found in this gcc wiki: 
>>> https://gcc.gnu.org/wiki/FunctionMultiVersioning
>>> '''
>>> This support is available in GCC 4.8 and later. Support is only available 
>>> in C++ for i386 targets.
>>> '''
>>>
>>> Should the test be guarded with a target selector or require function 
>>> multi-versioning instead of ifunc?
>>
>> Hi.
>>
>> Sure, sorry for the breakage. I'm going to install following tested patch.
>>
>> Martin
>>
>>>
>>> Regards,
>>> Renlin
>>>
>>>
>>> On 10/04/2018 02:56 PM, Martin Liška wrote:
 Hi.

 When having a pair of target clones where foo calls bar, if the target
 attribute are equal we can redirect the call and not use ifunc dispatcher.

 Patch survives regression tests on x86_64-linux-gnu.
 Ready for trunk?

 Martin

 gcc/ChangeLog:

 2018-10-04  Martin Liska  

 PR ipa/82625
 * multiple_target.c (redirect_to_specific_clone): New function.
 (ipa_target_clone): Use it.
 * tree-inline.c: Fix comment.

 gcc/testsuite/ChangeLog:

 2018-10-04  Martin Liska  

 PR ipa/82625
 * g++.dg/ext/pr82625.C: New test.
 ---
   gcc/multiple_target.c  | 51 ++
   gcc/testsuite/g++.dg/ext/pr82625.C | 36 +
   gcc/tree-inline.c  |  2 +-
   3 files changed, 88 insertions(+), 1 deletion(-)
   create mode 100644 gcc/testsuite/g++.dg/ext/pr82625.C


>>
>>
>> 0001-Limit-a-MV-test-just-for-x86-target.patch
>>
>>
>> From e3053abe58eba832262db0af77980012010a642c Mon Sep 17 00:00:00 2001
>> From: marxin 
>> Date: Mon, 8 Oct 2018 11:07:29 +0200
>> Subject: [PATCH] Limit a MV test just for x86 target.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-10-08  Martin Liska  
>>
>>  * g++.dg/ext/pr82625.C: Add dg-compile filter.
>> ---
>>  gcc/testsuite/g++.dg/ext/pr82625.C | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/gcc/testsuite/g++.dg/ext/pr82625.C 
>> b/gcc/testsuite/g++.dg/ext/pr82625.C
>> index 47bd2df1104..59b174f8c51 100644
>> --- a/gcc/testsuite/g++.dg/ext/pr82625.C
>> +++ b/gcc/testsuite/g++.dg/ext/pr82625.C
>> @@ -1,6 +1,7 @@
>>  /* { dg-do compile } */
>>  /* { dg-require-ifunc "" } */
>>  /* { dg-options "-O2 -fdump-tree-optimized" } */
>> +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
>>  
>>  __attribute__ ((target ("default")))
>>  static unsigned foo(const char *buf, unsigned size) {
>>
> 
> Which begs the question why is this not put under g++.target?
> 
> R.
> 

Agree, apparently we have quite some tests that should be moved:
gcc/testsuite/g++.dg/ext/pr57362.C:/* { dg-require-ifunc "" }  */
gcc/testsuite/g++.dg/ext/pr57548.C:/* { dg-require-ifunc "" }  */
gcc/testsuite/g++.dg/ext/pr82625.C:/* { dg-require-ifunc "" } */
gcc/testsuite/g++.dg/ext/pr85329-2.C:/* { dg-require-ifunc "" } */
gcc/testsuite/g++.dg/ext/pr85329.C:/* { dg-require-ifunc "" } */
...
gcc/testsuite/g++.dg/ext/mv*.C

I'll prepare patch for it.
Martin

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

[Richard Biener]

On Thu, Oct 4, 2018 at 9:43 PM Joseph Myers  wrote:
>
> On Thu, 4 Oct 2018, Jeff Law wrote:
>
> > > I doubt you could prove that without LTO of the whole program because an
> > > errno value set by a libm function call could always be checked in the
> > > caller of whatever function is being compiled.
> > Right, but if you have a series of calls like
> >
> >
> >   t1 = sqrt (x);
> >   t2 = sqrt (y);
> >   t3 = sqrt (z);
> >   return t1 + t2 + t3;
> >
> > You know that errno from the first two isn't examined and you could emit
> > the hardware insn for sqrt in those cases.  You couldn't do so for the
> > 3rd because you don't necessarily have the caller context.
>
> No, you don't know that error from the first two isn't examined.  sqrt
> doesn't set errno on success.  A caller could set errno to 0 before that
> code, then check for errno == EDOM afterwards, meaning that any of the
> sqrt arguments were negative.  (The caller could also check whether the
> result is a NaN and so not need errno, of course.)

So I think it would be fine if we'd have -fno-math-errno as documented
and then the C library would annotate their math functions according
to whether they will ever set errno or not.  Once a math function is
const or pure it cannot ever set errno so -fno-math-errno shouldn't have
any effect.

Then a C library could say that if a user says -D_I_NEED_NO_ERRNO_FROM_MATH
then it could redirect to appropriate functions?

Just assuming that the latter is easier for the library itself than
from the compiler.

glibc has the ieee entry points but I'm not sure if it has any way
to use those by default.

Richard.

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

Re: [PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

[Richard Biener]

On Thu, Oct 4, 2018 at 5:51 PM Martin Sebor  wrote:
>
> On 10/04/2018 08:58 AM, Jeff Law wrote:
> > On 8/27/18 9:42 AM, Richard Biener wrote:
> >> On Mon, Aug 27, 2018 at 5:32 PM Jeff Law  wrote:
> >>>
> >>> On 08/27/2018 02:29 AM, Richard Biener wrote:
>  On Sun, Aug 26, 2018 at 7:26 AM Jeff Law  wrote:
> >
> > On 08/24/2018 09:58 AM, Martin Sebor wrote:
> >> The warning suppression for -Wstringop-truncation looks for
> >> the next statement after a truncating strncpy to see if it
> >> adds a terminating nul.  This only works when the next
> >> statement can be reached using the Gimple statement iterator
> >> which isn't until after gimplification.  As a result, strncpy
> >> calls that truncate their constant argument that are being
> >> folded to memcpy this early get diagnosed even if they are
> >> followed by the nul assignment:
> >>
> >>   const char s[] = "12345";
> >>   char d[3];
> >>
> >>   void f (void)
> >>   {
> >> strncpy (d, s, sizeof d - 1);   // -Wstringop-truncation
> >> d[sizeof d - 1] = 0;
> >>   }
> >>
> >> To avoid the warning I propose to defer folding strncpy to
> >> memcpy until the pointer to the basic block the strnpy call
> >> is in can be used to try to reach the next statement (this
> >> happens as early as ccp1).  I'm aware of the preference to
> >> fold things early but in the case of strncpy (a relatively
> >> rarely used function that is often misused), getting
> >> the warning right while folding a bit later but still fairly
> >> early on seems like a reasonable compromise.  I fear that
> >> otherwise, the false positives will drive users to adopt
> >> other unsafe solutions (like memcpy) where these kinds of
> >> bugs cannot be as readily detected.
> >>
> >> Tested on x86_64-linux.
> >>
> >> Martin
> >>
> >> PS There still are outstanding cases where the warning can
> >> be avoided.  I xfailed them in the test for now but will
> >> still try to get them to work for GCC 9.
> >>
> >> gcc-87028.diff
> >>
> >>
> >> PR tree-optimization/87028 - false positive -Wstringop-truncation 
> >> strncpy with global variable source string
> >> gcc/ChangeLog:
> >>
> >>   PR tree-optimization/87028
> >>   * gimple-fold.c (gimple_fold_builtin_strncpy): Avoid folding when
> >>   statement doesn't belong to a basic block.
> >>   * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Handle MEM_REF on
> >>   the left hand side of assignment.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >>   PR tree-optimization/87028
> >>   * c-c++-common/Wstringop-truncation.c: Remove xfails.
> >>   * gcc.dg/Wstringop-truncation-5.c: New test.
> >>
> >> diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
> >> index 07341eb..284c2fb 100644
> >> --- a/gcc/gimple-fold.c
> >> +++ b/gcc/gimple-fold.c
> >> @@ -1702,6 +1702,11 @@ gimple_fold_builtin_strncpy 
> >> (gimple_stmt_iterator *gsi,
> >>if (tree_int_cst_lt (ssize, len))
> >>  return false;
> >>
> >> +  /* Defer warning (and folding) until the next statement in the basic
> >> + block is reachable.  */
> >> +  if (!gimple_bb (stmt))
> >> +return false;
> > I think you want cfun->cfg as the test here.  They should be equivalent
> > in practice.
> 
>  Please do not add 'cfun' references.  Note that the next stmt is also 
>  accessible
>  when there is no CFG.  I guess the issue is that we fold this during
>  gimplification where the next stmt is not yet "there" (but still in 
>  GENERIC)?
> >>> That was my assumption.  I almost suggested peeking at gsi_next and
> >>> avoiding in that case.
> >>
> >> So I'd rather add guards to maybe_fold_stmt in the gimplifier then.
> > So I think the concern with adding the guards to maybe_fold_stmt is the
> > possibility of further fallout.
> >
> > I guess they could be written to target this case specifically to
> > minimize fallout, but that feels like we're doing the same thing
> > (band-aid) just in a different place.
> >
> >
> >
> >>
> 
>  We generally do not want to have unfolded stmts in the IL when we can 
>  avoid that
>  which is why we fold most stmts during gimplification.  We also do that 
>  because
>  we now do less folding on GENERIC.
> >>> But an unfolded call in the IL should always be safe and we've got
> >>> plenty of opportunities to fold it later.
> >>
> >> Well - we do.  The very first one is forwprop though which means we'll 
> >> miss to
> >> re-write some memcpy parts into SSA:
> >>
> >>   NEXT_PASS (pass_ccp, false /* nonzero_p */);
> >>   /* After CCP we rewrite no longer addressed locals into SSA
> >>  form if possible.  */
> >>   NEXT_PASS (pass_forwprop);
> >>
> >> likewise 

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Richard Earnshaw (lists)]

On 08/10/18 10:47, Martin Liška wrote:
> On 10/8/18 10:46 AM, Renlin Li wrote:
>> Hi Martin,
>>
>> pr82625.C failed on compiler builds which don't support "default" and "avx" 
>> target.
>> For example, arm/aarch64 native linux gcc compiler.
>>
>>
>> As I found in this gcc wiki: https://gcc.gnu.org/wiki/FunctionMultiVersioning
>> '''
>> This support is available in GCC 4.8 and later. Support is only available in 
>> C++ for i386 targets.
>> '''
>>
>> Should the test be guarded with a target selector or require function 
>> multi-versioning instead of ifunc?
> 
> Hi.
> 
> Sure, sorry for the breakage. I'm going to install following tested patch.
> 
> Martin
> 
>>
>> Regards,
>> Renlin
>>
>>
>> On 10/04/2018 02:56 PM, Martin Liška wrote:
>>> Hi.
>>>
>>> When having a pair of target clones where foo calls bar, if the target
>>> attribute are equal we can redirect the call and not use ifunc dispatcher.
>>>
>>> Patch survives regression tests on x86_64-linux-gnu.
>>> Ready for trunk?
>>>
>>> Martin
>>>
>>> gcc/ChangeLog:
>>>
>>> 2018-10-04  Martin Liska  
>>>
>>> PR ipa/82625
>>> * multiple_target.c (redirect_to_specific_clone): New function.
>>> (ipa_target_clone): Use it.
>>> * tree-inline.c: Fix comment.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2018-10-04  Martin Liska  
>>>
>>> PR ipa/82625
>>> * g++.dg/ext/pr82625.C: New test.
>>> ---
>>>   gcc/multiple_target.c  | 51 ++
>>>   gcc/testsuite/g++.dg/ext/pr82625.C | 36 +
>>>   gcc/tree-inline.c  |  2 +-
>>>   3 files changed, 88 insertions(+), 1 deletion(-)
>>>   create mode 100644 gcc/testsuite/g++.dg/ext/pr82625.C
>>>
>>>
> 
> 
> 0001-Limit-a-MV-test-just-for-x86-target.patch
> 
> 
> From e3053abe58eba832262db0af77980012010a642c Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Mon, 8 Oct 2018 11:07:29 +0200
> Subject: [PATCH] Limit a MV test just for x86 target.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-10-08  Martin Liska  
> 
>   * g++.dg/ext/pr82625.C: Add dg-compile filter.
> ---
>  gcc/testsuite/g++.dg/ext/pr82625.C | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/testsuite/g++.dg/ext/pr82625.C 
> b/gcc/testsuite/g++.dg/ext/pr82625.C
> index 47bd2df1104..59b174f8c51 100644
> --- a/gcc/testsuite/g++.dg/ext/pr82625.C
> +++ b/gcc/testsuite/g++.dg/ext/pr82625.C
> @@ -1,6 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-require-ifunc "" } */
>  /* { dg-options "-O2 -fdump-tree-optimized" } */
> +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
>  
>  __attribute__ ((target ("default")))
>  static unsigned foo(const char *buf, unsigned size) {
> 

Which begs the question why is this not put under g++.target?

R.

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Martin Liška]

On 10/8/18 10:46 AM, Renlin Li wrote:
> Hi Martin,
> 
> pr82625.C failed on compiler builds which don't support "default" and "avx" 
> target.
> For example, arm/aarch64 native linux gcc compiler.
> 
> 
> As I found in this gcc wiki: https://gcc.gnu.org/wiki/FunctionMultiVersioning
> '''
> This support is available in GCC 4.8 and later. Support is only available in 
> C++ for i386 targets.
> '''
> 
> Should the test be guarded with a target selector or require function 
> multi-versioning instead of ifunc?

Hi.

Sure, sorry for the breakage. I'm going to install following tested patch.

Martin

> 
> Regards,
> Renlin
> 
> 
> On 10/04/2018 02:56 PM, Martin Liška wrote:
>> Hi.
>>
>> When having a pair of target clones where foo calls bar, if the target
>> attribute are equal we can redirect the call and not use ifunc dispatcher.
>>
>> Patch survives regression tests on x86_64-linux-gnu.
>> Ready for trunk?
>>
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2018-10-04  Martin Liska  
>>
>> PR ipa/82625
>> * multiple_target.c (redirect_to_specific_clone): New function.
>> (ipa_target_clone): Use it.
>> * tree-inline.c: Fix comment.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-10-04  Martin Liska  
>>
>> PR ipa/82625
>> * g++.dg/ext/pr82625.C: New test.
>> ---
>>   gcc/multiple_target.c  | 51 ++
>>   gcc/testsuite/g++.dg/ext/pr82625.C | 36 +
>>   gcc/tree-inline.c  |  2 +-
>>   3 files changed, 88 insertions(+), 1 deletion(-)
>>   create mode 100644 gcc/testsuite/g++.dg/ext/pr82625.C
>>
>>

>From e3053abe58eba832262db0af77980012010a642c Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 8 Oct 2018 11:07:29 +0200
Subject: [PATCH] Limit a MV test just for x86 target.

gcc/testsuite/ChangeLog:

2018-10-08  Martin Liska  

	* g++.dg/ext/pr82625.C: Add dg-compile filter.
---
 gcc/testsuite/g++.dg/ext/pr82625.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.dg/ext/pr82625.C b/gcc/testsuite/g++.dg/ext/pr82625.C
index 47bd2df1104..59b174f8c51 100644
--- a/gcc/testsuite/g++.dg/ext/pr82625.C
+++ b/gcc/testsuite/g++.dg/ext/pr82625.C
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-ifunc "" } */
 /* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
 
 __attribute__ ((target ("default")))
 static unsigned foo(const char *buf, unsigned size) {
-- 
2.19.0

Re: [PATCH] EfficiencySanitizer implementation.

[Denis Khalikov]

I assume that the compiler based instrumentation,
should be more efficient than binary instrumentation.
But, I was just interested in the process of implementation
for that tool.
Sorry for the noise.

On 10/07/2018 11:03 AM, Richard Biener wrote:
> On October 6, 2018 10:17:48 PM GMT+02:00, Denis Khalikov 
>  wrote:
>> Hello everyone,
>> this is a patch which implements EfficiencySanitizer aka ESan
>> into GCC. The EfficiencySanitizer tool is available in the llvm.
>> So, the main idea was to port the runtime library into GCC and
>> implement GCC compiler pass on GIMPLE IR with the same semantics
>> as llvm does on llvm IR.
>> The main difference that this patch also enables ESan under 32 bit
>> ARM CPU with some changes to runtime library.
>> Link to the RFC on the llvm-dev:
>> https://lists.llvm.org/pipermail/llvm-dev/2016-April/098355.html
>>
>> I know this patch is not acceptable into GCC trunk, so, I send
>> this patch in the weekend to don't bother anyone, but may be
>> someone will be interested. Also, I'll be very appreciated for
>> any feedback.
>> GCC should be build with --enable-checking=release.
>>
>> This patch includes:
>>
>> 1. GCC pass for the CacheFragmentation tool on the GIMPLE IR.
>> Special compiler pass instruments every memory access into the struct
>> field with gimple internal call ESAN_RECORD_ACCESS and expands
>> it in sanopt pass.
>> Creates fields counter array, each cell of that array
>> counts memory accesses to the special field. Creates array of
>> the structs, where the every instance of the struct represents meta
>> info of the real struct.
>>
>> a. Source example:
>>
>> struct node {
>>   int a;
>>   int b;
>>   int c;
>> };
>>
>> int main () {
>>   struct node c;
>>   for (int i = 0; i < 100; ++i) {
>> c.a = i + 1;
>> c.b = i + 1;
>> c.c = i + 1;
>>   }
>>   return 0;
>> }
>>
>> b. Instrumented GIMPLE:
>>:
>>   _1 = i_4 + 1;
>>   .ESAN_RECORD_ACCESS (0B, 0);
>>   c.a = _1;
>>   _2 = i_4 + 1;
>>   .ESAN_RECORD_ACCESS (0B, 1);
>>   c.b = _2;
>>   _3 = i_4 + 1;
>>   .ESAN_RECORD_ACCESS (0B, 2);
>>   c.c = _3;
>>   i_11 = i_4 + 1;
>>
>> c. Assembler:
>>
>> # The fields counter array.
>> # Every cell 8 bytes long and represents the amount
>> # of the field accesses.
>>
>> .weakstruct.node$1$1$1
>> .bss
>> .align 8
>> .typestruct.node$1$1$1, @object
>> .sizestruct.node$1$1$1, 24
>> struct.node$1$1$1:
>> .zero24
>>
>> # Increment the specific cell by the field index.
>> # Actually __esan_increment, could be inlined.
>>movl$struct.node$1$1$1, %eax
>>movq%rax, %rdi
>>call__esan_increment
>>movl%ebx, -32(%rbp)
>>movl-20(%rbp), %eax
>>leal1(%rax), %ebx
>>movl$struct.node$1$1$1+8, %eax
>>movq%rax, %rdi
>>call__esan_increment
>>movl%ebx, -28(%rbp)
>>movl-20(%rbp), %eax
>>leal1(%rax), %ebx
>>movl$struct.node$1$1$1+16, %eax
>>movq%rax, %rdi
>>call__esan_increment
>>
>> # The array of the structs with
>> # meta info like size of the special struct,
>> # number of the fields and pointer to the
>> # fields counter array.
>>
>> .Lesan_info0:
>> .quad.LC0
>> .long12
>> .long3
>> .quad0
>> .quad0
>> .quad0
>> .quadstruct.node$1$1$1
>> .quad0
>>
>> __esan_init is inserted to the static constructor.
>> __esan_exit is inserted to the static destructor.
>>
>> d. Output:
>>
>> ==28719==  struct node
>> ==28719==   size = 12, count = 300, ratio = 2
>> ==28719==   # 0: count = 100
>> ==28719==   # 1: count = 100
>> ==28719==   # 2: count = 100
>> ==28719==EfficiencySanitizer: total struct field access count = 300
>>
>> 2. GCC pass for the WorkingSet tool.
>> Special compiler pass instruments every memory access in the program.
>> Memory accesses are simply prepended with a function call like
>> __esan_aligned_load(addr), __esan_aligned_store(addr).
>> Also, __esan_init is inserted to the static constructor and
>> __esan_exit is inserted to the static destructor.
>>
>> a. Assembler:
>>
>>   movq-32(%rbp), %rax
>>   movq%rax, %rdi
>>   call__esan_aligned_store1
>>
>> The runtime library simply manages shadow memory and computes statistic
>> of the program efficiency. The tool maps one cache line (64 bytes) of
>> the program to the one byte of the shadow memory.
>> The runtime library measures the data working set size of an
>> application
>> at each snapshot during execution.
>>
>> b. Output:
>>
>> ==28742== EfficiencySanitizer: the total working set size: 32 MB
>> (524291
>> cache lines)
>>
>> HOW TO USE:
>>
>> WorkingSet tool.
>> To measure the working set size, you should build your binary or
>> shared library with compile time flag
>> -fsanitize=efficiency-working-set and set runtime options
>> ESAN_OPTIONS=process_range_access=1:record_snapshots=1
>>
>> CacheFragmentation tool.
>> To enable CacheFragmentation tool you should compile your binary or

Re: sched2 priorities and replacements

[Robin Dapp]

ping, any insight on this?

Regards
 Robin

Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

[Christophe Lyon]

On Sat, 6 Oct 2018 at 04:38, Peter Bergner  wrote:
>
> On 10/5/18 4:12 PM, Vladimir Makarov wrote:
> > On 10/05/2018 04:00 PM, Peter Bergner wrote:
> >> How about non_conflicting_reg_copy or non_conflicting_copy_insn?
> > OK. I like the first name more.
>
> Ok, I committed the patch using the first function name.
> Thank you very much for the patch reviews and approvals!
>

Hi,

Since r264897, we are seeing lots of regressions when bootstrapping on arm.
There are execution errors as well as ICEs.
A detailed list can be found at:
https://ci.linaro.org/job/tcwg-compare-results/6498/artifact/artifacts/logs/1-diff-d05_32.tcwg-d05_32-build.txt

You can also see the results posted on gcc-testresults.

Christophe

> Peter
>
>
>

Re: [Patch, fortran] PR87151 - allocating array of character

[Dominique d'Humières]

Hi Paul,

Your patch works as expected. It also fixes the ICEs for the tests in pr80931 
(and the test accidentally attached to pr83196).

Thanks for the patch.

Dominique

Re: [PATCH] Redirect call within specific target attribute among MV clones (PR ipa/82625).

[Renlin Li]

Hi Martin,

pr82625.C failed on compiler builds which don't support "default" and "avx" 
target.
For example, arm/aarch64 native linux gcc compiler.


As I found in this gcc wiki: https://gcc.gnu.org/wiki/FunctionMultiVersioning
'''
This support is available in GCC 4.8 and later. Support is only available in 
C++ for i386 targets.
'''

Should the test be guarded with a target selector or require function 
multi-versioning instead of ifunc?

Regards,
Renlin


On 10/04/2018 02:56 PM, Martin Liška wrote:

Hi.

When having a pair of target clones where foo calls bar, if the target
attribute are equal we can redirect the call and not use ifunc dispatcher.

Patch survives regression tests on x86_64-linux-gnu.
Ready for trunk?

Martin

gcc/ChangeLog:

2018-10-04  Martin Liska  

PR ipa/82625
* multiple_target.c (redirect_to_specific_clone): New function.
(ipa_target_clone): Use it.
* tree-inline.c: Fix comment.

gcc/testsuite/ChangeLog:

2018-10-04  Martin Liska  

PR ipa/82625
* g++.dg/ext/pr82625.C: New test.
---
  gcc/multiple_target.c  | 51 ++
  gcc/testsuite/g++.dg/ext/pr82625.C | 36 +
  gcc/tree-inline.c  |  2 +-
  3 files changed, 88 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/ext/pr82625.C

Re: [patch] tighten toplevel guard on ibm-ldouble.c

[Olivier Hainque]

Hi Segher,

> On 05 Oct 2018, at 11:35, Segher Boessenkool  
> wrote:
> 
> I think it looks fine.  Okay for trunk after some testing.

Thanks for your feedback.

I can't get a pristine mainline to build on our powerpc-linux
host - SEGVs from the newly built cc1 during libgcc. Updated
ulimits helped a bit, investigating ...

> (Please don't use application/octet-stream for patches btw).

Ah, huh, ok. My mailer probably picked the
attachement type from the .diff extension. 

Thanks for the note, I'll see what I can do. 

Cheers,

Olivier

Re: [wwwdocs] Add no_sanitize attribute

[Martin Liška]

On 10/7/18 2:15 PM, Gerald Pfeifer wrote:
> On Wed, 18 Apr 2018, Martin Liška wrote:
>> I would like to mention the attribute in GCC 8 changes.
> 
> Index: htdocs/gcc-8/changes.html
> ===
>>   
>> New no_sanitize attribute has been added.  The attribute
>> on functions is used to inform the compiler that it should
>> not do sanitization of all options mentioned in sanitize option.
>> A list of values acceptable by -fsanitize option can be
>> provided.
>> 
>> void __attribute__ ((no_sanitize ("alignment", "object-size")))
>> f () { /* Do something. */; }
>> 
>>   
> 
> I've been struggling with this from a language perspective and 
> while not fully happy, believe/hope the below may improve things
> a bit.
> 
> Sandra, any recommendations from your end?
> 
> Martin, is my update technically acurate?

Hi.

Yes, it's equivalent, thanks for the improvement.

Martin

> 
> Index: gcc-8/changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
> retrieving revision 1.97
> diff -u -r1.97 changes.html
> --- gcc-8/changes.html30 Sep 2018 14:38:54 -  1.97
> +++ gcc-8/changes.html7 Oct 2018 12:13:03 -
> @@ -251,11 +251,10 @@
>  tests for pointer wrapping.
>
>
> -New no_sanitize attribute has been added.  The attribute
> -on functions is used to inform the compiler that it should
> -not do sanitization of all options mentioned in sanitize option.
> -A list of values acceptable by -fsanitize option can be
> -provided.
> +A new attribute no_sanitize can be applied to functions
> +to instruct the compiler not to do sanitization of any of the options
> +specified.  Acceptable values for no_sanitize match those
> +acceptable by the -fsanitize command-line option.
>  
>  void __attribute__ ((no_sanitize ("alignment", "object-size")))
>  f () { /* Do something. */; }
> 
> Gerald
> 

[PATCH] Minor cleanups / PR63155

[Richard Biener]

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

Richard.

2018-10-08  Richard Biener  

PR tree-optimization/63155
* tree-ssa-propagate.c (add_ssa_edge): Do cheap check first.
(ssa_propagation_engine::ssa_propagate): Remove redundant
bitmap bit clearing.

Index: gcc/tree-ssa-propagate.c
===
--- gcc/tree-ssa-propagate.c(revision 264911)
+++ gcc/tree-ssa-propagate.c(working copy)
@@ -143,10 +143,12 @@ add_ssa_edge (tree var)
   FOR_EACH_IMM_USE_FAST (use_p, iter, var)
 {
   gimple *use_stmt = USE_STMT (use_p);
-  basic_block use_bb = gimple_bb (use_stmt);
+  if (!prop_simulate_again_p (use_stmt))
+   continue;
 
   /* If we did not yet simulate the block wait for this to happen
  and do not add the stmt to the SSA edge worklist.  */
+  basic_block use_bb = gimple_bb (use_stmt);
   if (! (use_bb->flags & BB_VISITED))
continue;
 
@@ -157,9 +159,6 @@ add_ssa_edge (tree var)
   & EDGE_EXECUTABLE))
continue;
 
-  if (!prop_simulate_again_p (use_stmt))
-   continue;
-
   bitmap worklist;
   if (bb_to_cfg_order[gimple_bb (use_stmt)->index] < curr_order)
worklist = ssa_edge_worklist_back;
@@ -804,7 +803,6 @@ ssa_propagation_engine::ssa_propagate (v
   else
{
  curr_order = next_stmt_bb_order;
- bitmap_clear_bit (ssa_edge_worklist, next_stmt_uid);
  if (dump_file && (dump_flags & TDF_DETAILS))
{
  fprintf (dump_file, "\nSimulating statement: ");