Re: [PATCH] Use tail calls to memcpy/memset even for structure assignments (PR target/41455, PR target/82935)

[Jeff Law]

On 12/06/2017 02:04 PM, Jakub Jelinek wrote:
> Hi!
> 
> Aggregate assignments and clears aren't in GIMPLE represented as calls,
> and while often they expand inline, sometimes we emit libcalls for them.
> This patch allows us to tail call those libcalls if there is nothing
> after them.  The patch changes the tailcall pass, so that it recognizes
> a = b; and c = {}; statements under certain conditions as potential tail
> calls returning void, and if it finds good tail call candidates, it marks
> them specially.  Because we have only a single bit left for GIMPLE_ASSIGN,
> I've decided to wrap the rhs1 into a new internal call, so
> a = b; will be transformed into a = TAILCALL_ASSIGN (b); and
> c = {}; will be transformed into c = TAILCALL_ASSIGN ();
> The rest of the patch is about propagating the flag (may use tailcall if
> the emit_block_move or clear_storage is the last thing emitted) down
> through expand_assignment and functions it calls.
> 
> Those functions use 1-3 other flags, so instead of adding another bool
> to all of them (next to nontemporal, call_param_p, reverse) I've decided
> to pass around a bitmask of flags.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2017-12-06  Jakub Jelinek  
> 
>   PR target/41455
>   PR target/82935
>   * internal-fn.def (TAILCALL_ASSIGN): New internal function.
>   * internal-fn.c (expand_LAUNDER): Pass EXPAND_FLAG_NORMAL to
>   expand_assignment.
>   (expand_TAILCALL_ASSIGN): New function.
>   * tree-tailcall.c (struct tailcall): Adjust comment.
>   (find_tail_calls): Recognize also aggregate assignments and
>   aggregate clearing as possible tail calls.  Use is_gimple_assign
>   instead of gimple_code check.
>   (optimize_tail_call): Rewrite aggregate assignments or aggregate
>   clearing in tail call positions using IFN_TAILCALL_ASSIGN
>   internal function.
>   * tree-outof-ssa.c (insert_value_copy_on_edge): Adjust store_expr
>   caller.
>   * tree-chkp.c (chkp_expand_bounds_reset_for_mem): Adjust
>   expand_assignment caller.
>   * function.c (assign_parm_setup_reg): Likewise.
>   * ubsan.c (ubsan_encode_value): Likewise.
>   * cfgexpand.c (expand_call_stmt, expand_asm_stmt): Likewise.
>   (expand_gimple_stmt_1): Likewise.  Fix up formatting.
>   * calls.c (initialize_argument_information): Adjust store_expr caller.
>   * expr.h (enum expand_flag): New.
>   (expand_assignment): Replace bool argument with enum expand_flag.
>   (store_expr_with_bounds, store_expr): Replace int, bool, bool arguments
>   with enum expand_flag.
>   * expr.c (expand_assignment): Replace nontemporal argument with flags.
>   Assert no bits other than EXPAND_FLAG_NONTEMPORAL and
>   EXPAND_FLAG_TAILCALL are set.  Adjust store_expr, store_fields and
>   store_expr_with_bounds callers.
>   (store_expr_with_bounds): Replace call_param_p, nontemporal and
>   reverse args with flags argument.  Adjust recursive calls.  Pass
>   BLOCK_OP_TAILCALL to clear_storage and expand_block_move if
>   EXPAND_FLAG_TAILCALL is set.  Call clear_storage directly for
>   EXPAND_FLAG_TAILCALL assignments from emtpy CONSTRUCTOR.
>   (store_expr): Replace call_param_p, nontemporal and reverse args
>   with flags argument.  Adjust store_expr_with_bounds caller.
>   (store_constructor_field): Adjust store_field caller.
>   (store_constructor): Adjust store_expr and expand_assignment callers.
>   (store_field): Replace nontemporal and reverse arguments with flags
>   argument.  Adjust store_expr callers.  Pass BLOCK_OP_TAILCALL to
>   emit_block_move if EXPAND_FLAG_TAILCALL is set.
>   (expand_expr_real_2): Adjust store_expr and store_field callers.
>   (expand_expr_real_1): Adjust store_expr and expand_assignment callers.
> 
>   * gcc.target/i386/pr41455.c: New test.
This looks pretty reasonable to me.  Is it big?  Yes, but a fair amount
is changing how we pass flags into the expanders.

I think you just need to merge back to the trunk retest and this should
be good to go.

jeff

Re: [PATCH] Remove stale doc notes about netbsd and openbsd

[Jeff Law]

On 06/22/2018 03:34 PM, Maya Rashish wrote:
> That isn't a default any more because the default is 80486 with FPU.
> 
> ---
>  gcc/doc/invoke.texi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
Thanks.  Installed on the trunk.

jeff

Re: [13/n] PR85694: Try to avoid vectorising casts of invariants

[Jeff Law]

On 06/20/2018 04:32 AM, Richard Sandiford wrote:
> vect_recog_rotate_pattern had code to prevent operations
> on invariants being vectorised unnecessarily:
> 
>   if (dt == vect_external_def
>   && TREE_CODE (oprnd1) == SSA_NAME
>   && is_a  (vinfo))
> {
>   struct loop *loop = as_a  (vinfo)->loop;
>   ext_def = loop_preheader_edge (loop);
>   if (!SSA_NAME_IS_DEFAULT_DEF (oprnd1))
> {
>   basic_block bb = gimple_bb (SSA_NAME_DEF_STMT (oprnd1));
>   if (bb == NULL
>   || !dominated_by_p (CDI_DOMINATORS, ext_def->dest, bb))
> ext_def = NULL;
> }
> }
>   [..]
>   if (ext_def)
> {
>   basic_block new_bb
> = gsi_insert_on_edge_immediate (ext_def, def_stmt);
>   gcc_assert (!new_bb);
> }
> 
> This patch reuses the same idea for casts of invariants created
> during widening optimisations.
> 
> One hitch was that vect_loop_versioning asserted that the vector loop
> preheader was still empty, although the cfg transformation it's doing
> should be correct either way.
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
> 
> Richard
> 
> 
> 2018-06-20  Richard Sandiford  
> 
> gcc/
>   * tree-vect-patterns.c (vect_get_external_def_edge): New function,
>   split out from...
>   (vect_recog_rotate_pattern): ...here.
>   (vect_convert_input): Try to insert casts of invariants in the
>   preheader.
>   * tree-vect-loop-manip.c (vect_loop_versioning): Don't require the
>   preheader to be empty.
> 
> gcc/testsuite/
>   * gcc.dg/vect/vect-widen-mult-extern-1.c: New test.
OK
jeff
igned int *x2, unsigned short *y, unsigned char z)
> +{
> +  unsigned short zu = z;
> +  for (int i = 0; i < N; ++i)
> +{
> +  unsigned short yi = y[i];
> +  x1[i] = x1[i] > 10 ? yi * zu : x1[i] + 1;
> +  x2[i] += 1;
> +}
> +}
> 

Re: PING [PATCH] update Zero-length array documentation

[Jeff Law]

On 06/18/2018 05:00 PM, Martin Sebor wrote:
> Attached is an updated patch with the additional text as
> discussed below.
OK with a ChangeLog entry.

jeff

Re: [10/n] PR85694: Split out check for vectorizable associative reductions

[Jeff Law]

On 06/18/2018 09:07 AM, Richard Sandiford wrote:
> This patch adds an overload of vect_reassociating_reduction_p
> that checks for a vectorizable associative reduction,
> since the check was duplicated in three functions.
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
> 
> Richard
> 
> 
> 2018-06-18  Richard Sandiford  
> 
> gcc/
>   * tree-vect-patterns.c (vect_reassociating_reduction_p): New function.
>   (vect_recog_dot_prod_pattern, vect_recog_sad_pattern)
>   (vect_recog_widen_sum_pattern): Use it.
OK.
jeff

Re: [PATCH][Middle-end][version 3]2nd patch of PR78809 and PR83026

[Jeff Law]

On 05/29/2018 06:08 PM, Qing Zhao wrote:
> Hi, Jeff,
> 
> Thanks a lot for your review and comments.
> 
> I have updated my patch based on your suggestion, and retested this whole 
> patch on both X86 and aarch64.
> 
> please take a look at the patch again.
> 
> thanks.
> 
> Qing
> 
>> On May 25, 2018, at 3:38 PM, Jeff Law  wrote:
>> So I originally thought you had the core logic wrong in the immediate
>> uses loop.  But it's actually the case that the return value is the
>> exact opposite of what I expected.
>>
>> ie, I expected "TRUE" to mean the call was transformed, "FALSE" if it
>> was not transformed.
>>
>> Can you fix that so it's not so confusing?
>>
>> I think with that change we'll be good to go, but please repost for a
>> final looksie.
>>
>> THanks,
>> Jeff
> 
> 
> 0001-2nd-Patch-for-PR78009.patch
> 
> 
> From 750f44ee0777d55b568f07e263babdedd532d315 Mon Sep 17 00:00:00 2001
> From: qing zhao 
> Date: Tue, 29 May 2018 16:15:21 -0400
> Subject: [PATCH] 2nd Patch for PR78009 Patch for PR83026
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
> Inline strcmp with small constant strings
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026
> missing strlen optimization for strcmp of unequal strings
> 
> The design doc for PR78809 is at:
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html
> 
> this patch is for the second part of change of PR78809 and PR83026:
> 
> B. for strncmp (s1, s2, n) (!)= 0 or strcmp (s1, s2) (!)= 0
> 
>B.1. (PR83026) When the lengths of both arguments are constant and
> it's a strcmp:
>   * if the lengths are NOT equal, we can safely fold the call
> to a non-zero value.
>   * otherwise, do nothing now.
> 
>B.2. (PR78809) When the length of one argument is constant, try to replace
>the call with a __builtin_str(n)cmp_eq call where possible, i.e:
> 
>strncmp (s, STR, C) (!)= 0 in which, s is a pointer to a string, STR is a
>string with constant length, C is a constant.
>  if (C <= strlen(STR) && sizeof_array(s) > C)
>{
>  replace this call with
>  __builtin_strncmp_eq (s, STR, C) (!)= 0
>}
>  if (C > strlen(STR)
>{
>  it can be safely treated as a call to strcmp (s, STR) (!)= 0
>  can handled by the following strcmp.
>}
> 
>strcmp (s, STR) (!)= 0 in which, s is a pointer to a string, STR is a
>string with constant length.
>  if  (sizeof_array(s) > strlen(STR))
>{
>  replace this call with
>  __builtin_strcmp_eq (s, STR, strlen(STR)+1) (!)= 0
>}
> 
>later when expanding the new __builtin_str(n)cmp_eq calls, first expand 
> them
>as __builtin_memcmp_eq, if the expansion does not succeed, change them back
>to call to __builtin_str(n)cmp.
> 
> adding test case strcmpopt_2.c and strcmpopt_4.c into gcc.dg for part B of
> PR78809 adding test case strcmpopt_3.c into gcc.dg for PR83026
> 
> bootstraped and tested on both X86 and Aarch64. no regression.
> ---
>  gcc/builtins.c |  33 
>  gcc/builtins.def   |   5 +
>  gcc/gimple-fold.c  |   5 +
>  gcc/testsuite/gcc.dg/strcmpopt_2.c |  67 
>  gcc/testsuite/gcc.dg/strcmpopt_3.c |  31 
>  gcc/testsuite/gcc.dg/strcmpopt_4.c |  16 ++
>  gcc/tree-ssa-strlen.c  | 304 
> ++---
>  gcc/tree-ssa-structalias.c |   2 +
>  gcc/tree.c |   8 +
>  9 files changed, 454 insertions(+), 17 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/strcmpopt_2.c
>  create mode 100644 gcc/testsuite/gcc.dg/strcmpopt_3.c
>  create mode 100644 gcc/testsuite/gcc.dg/strcmpopt_4.c
Sorry for the long delay.  This needs a ChangeLog.  With the ChangeLog
it is OK for the trunk.

Jeff

Re: [PATCH] allow more strncat calls with -Wstringop-truncation (PR 85700)

[Jeff Law]

On 05/22/2018 07:40 PM, Martin Sebor wrote:
> Here's another small refinement to -Wstringop-truncation to
> avoid diagnosing more arguably "safe" cases of strncat() that
> match the expected pattern of
> 
>   strncat (d, s, sizeof d - strlen (d) - 1);
> 
> such as
> 
>   extern char a[4];
>   strncat (a, "12", sizeof d - strlen (a) - 1);
> 
> Since the bound is derived from the length of the destination
> as GCC documents is the expected use, the call should probably
> not be diagnosed even though truncation is possible.
> 
> The trouble with strncat is that it specifies a single count
> that can be (and has been) used to specify either the remaining
> space in the destination or the maximum number of characters
> to append, but not both.  It's nearly impossible to tell for
> certain which the author meant, and if it's safe, hence all
> this fine-tuning.  I suspect this isn't the last tweak, either.
> 
> In any event, I'd like to commit the patch to both trunk and
> gcc-8-branch.  The bug isn't marked regression but I suppose
> it could (should) well be considered one.
> 
> Martin
> 
> gcc-85700.diff
> 
> 
> PR tree-optimization/85700 - Spurious -Wstringop-truncation warning with 
> strncat
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/85700
>   * gimple-fold.c (gimple_fold_builtin_strncat): Adjust comment.
>   * tree-ssa-strlen.c (is_strlen_related_p): Handle integer subtraction.
>   (maybe_diag_stxncpy_trunc): Distinguish strncat from strncpy.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/85700
>   * gcc.dg/Wstringop-truncation-3.c: New test.
OK for the trunk.  Sorry for the delay.

I don't see that strong of a case for backporting -- the distro rebuilds
with gcc-8 didn't trip over it (at least not in a -Werror build).  It
doesn't fix a codegen issue and we've only got the one report (unknown
what source the report originated with).  But you can certainly ask
Jakub or Richi.

jeff

libgo patch committed: Test USING_SPLIT_STACK using #ifdef, not #if

[Ian Lance Taylor]

This patch by Cherry Zhang fixes the libgo runtime code to
consistently use #ifdef instead of #if for USING_SPLIT_STACK.
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 261896)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-bdead75ea02fa852a559f35b41453df0c47c9a66
+7008302f1f0eaa9508b2857185505d4dc7baac1e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/runtime/proc.c
===
--- libgo/runtime/proc.c(revision 261819)
+++ libgo/runtime/proc.c(working copy)
@@ -716,7 +716,7 @@ runtime_malg(bool allocatestack, bool si
G *newg;
byte* unused_stack;
uintptr unused_stacksize;
-#if USING_SPLIT_STACK
+#ifdef USING_SPLIT_STACK
int dont_block_signals = 0;
size_t ss_stacksize;
 #endif
@@ -738,7 +738,7 @@ runtime_malg(bool allocatestack, bool si
 #endif
}
 
-#if USING_SPLIT_STACK
+#ifdef USING_SPLIT_STACK
*ret_stack = __splitstack_makecontext(stacksize,
  
(void*)(&newg->stackcontext[0]),
  &ss_stacksize);
@@ -777,7 +777,7 @@ void stackfree(G*)
 void
 stackfree(G* gp)
 {
-#if USING_SPLIT_STACK
+#ifdef USING_SPLIT_STACK
   __splitstack_releasecontext((void*)(&gp->stackcontext[0]));
 #else
   // If gcstacksize is 0, the stack is allocated by libc and will be

Re: [PATCH, rs6000] Change word selector to prefered location for vec_insert builtin

[Segher Boessenkool]

Hi Carl,

On Fri, Jun 22, 2018 at 07:32:47AM -0700, Carl Love wrote:
> The following patch changes the word selected when extracting the word
> from the second vector to insert into the first vector by the
> vec_insert() builtin.
> 
> Specifically, the test case
> 
> vector float
> fn2 (float a, vector float b)
> {
>   return vec_insert (a, b, 1);
> }
> 
> without the patch  generates the code sequence 
> 
>  xscvdpspn vs0,vs1
>  xxextractuw vs0,vs0,4
>  xxinsertw vs34,vs0,8

[ For -mcpu=power9 -mlittle ]

Is this from something in the testsuite?  I can't find it.

> The xscvdpspn places the extracted word into words 0 and 1 of the
> destination.  The xxextractuw extracts word 1 (offset of 4 bytes)from
> the source.  The patch changes the offset so that the xxexractuw will
> extract word 0 (offset 0 bytes) instead of word 1.  The values are the
> same so there is no functional change. But it was decided that using
> word 0 was preferred choice.

The patch looks fine.  Okay for trunk.  Thanks!


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #7 (fix IBM extended double tests to use __ibm128 as needed)

[Segher Boessenkool]

On Thu, Jun 21, 2018 at 07:11:37PM -0400, Michael Meissner wrote:
> On Thu, Jun 21, 2018 at 06:07:36PM -0500, Segher Boessenkool wrote:
> > On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> > > This patch fixes the tests in the testsuite that implicitly were 
> > > expecting long
> > > double to be IBM extended double to use __ibm128 if long double is 
> > > configured
> > > to be IEEE 128-bit floating point.
> > 
> > And just always using __ibm128 does not work?  That needs fixing then.
> 
> As we've discussed before, __ibm128 is only created when the float128 support
> is enabled (VSX and Linux).  If I changed the tests without adding a condition
> to only run it on the appropriate systems, it would give errors on AIX, and
> 32-bit embedded systems.

See the next lines:

> > (Perhaps test long double in a separate testcase, too, then, and only run
> > that if the appropriate long double type is active).

So, have a test for long double (gated on when long double is an appropriate
type for those tests), and one for __ibm128 (with a quite different
condition for those).


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #3 (use correct way to get the IEEE 128-bit complex type)

[Segher Boessenkool]

On Thu, Jun 21, 2018 at 10:43:16PM +, Joseph Myers wrote:
> On Thu, 21 Jun 2018, Segher Boessenkool wrote:
> 
> > The comment doesn't make much sense.  If long double is IBM, the long
> > double complex mode is ICmode, not KCmode.  "To get the IEEE128 complex
> > type", perhaps?  And can't you do _Complex __ieee128 or such?
> 
> You can do _Complex _Float128, in C only, not C++ (which doesn't have the 
> _Float128 keyword).  _Complex can be used with keywords for type names, 
> but not with a typedef name (built-in or otherwise, see discussion in bug 
> 32187).

__ieee128 is a type, not a typedef:

lang_hooks.types.register_builtin_type (ieee128_float_type_node, "__ieee128");

(Or what am I missing?  Or are we talking past eachother?)


Segher

Re: [PRs fortran/82972, fortran/83088, fortran/85851] Fix ICE with -finit-derived when using iso_c_binding

[Steve Kargl]

On Fri, Jun 22, 2018 at 04:46:19PM -0400, Fritz Reese wrote:
> 
> With the patch, the trunk compiler does not exhibit the bugs in the
> mentioned PRs (82972, 83088, 85851). I did encounter some issues
> building and regression testing the trunk compiler which I am certain
> are unrelated. The current trunk fails to bootstrap for me so I am
> using an older revision which appears to have some testcase issues.
> The issues are attached at the bottom of this e-mail for reference.

I applied your patch to my tree and everything passed regression testing.  

> In any case, the changelog is here, and the patch is attached. Aside
> from the issues mentioned below the compile bootstraps and regression
> tests successfully. Does this look OK for trunk? Furthermore, this
> patch comes a bit late as the PRs were submitted before 8.1 was
> released; is it appropriate to backport this to 7-branch and/or
> 8-branch?

I'll read through the patch in more detail tomorrow
(as long as it doesn't interfere with my World Cup
viewing).  As far as backporting, I've always deferred
to the person doing the work.  If you have time and
desire to backport, I don't have an issue with it.

-- 
Steve

Re: [PATCH v2, rs6000] Backport Fix implementation of vec_pack (vector double, vector double) built-in function

[Kelvin Nilsen]

Hi Segher,

After waiting a few days for this newly committed patch to settle, is it ok to 
backport to gcc 6, gcc 7, and gcc 8?

Thanks.


On 6/22/18 5:34 PM, Kelvin Nilsen wrote:
> Thanks for feedback.  It turns out that the vmrgew and vmrgow instructions 
> require power 8.
> 
> After coordinating with Segher on minor refinements to the test cases, I have 
> committed the patch as quoted below to the trunk.
> 
> On 6/19/18 5:37 PM, Segher Boessenkool wrote:
>> Hi!
>>
>> On Tue, Jun 19, 2018 at 01:37:51PM -0500, Kelvin Nilsen wrote:
>>> --- gcc/testsuite/gcc.target/powerpc/builtins-9.c   (nonexistent)
>>> +++ gcc/testsuite/gcc.target/powerpc/builtins-9.c   (working copy)
>>> @@ -0,0 +1,21 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-require-effective-target powerpc_p8vector_ok } */
>>> +/* Expect same instruction selecton on p8 and above.  Fix if future
>>> +   targets behave differently.  */
>>> +/* { dg-options "-O3 -maltivec" } */
>>
>> But this doesn't use -mcpu=power8 or similar.  Does it need it anyway?
>> Both xxpermdi and xvcvdpsp are Power7 (ISA 2.06) and the rest is AltiVec?
>> So maybe just powerpc_vsx_ok?
>>
>>> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } } */
>>
>> You do not use -mcpu= so you don't need this.
>>
>> Same issues in the next test.  Rest looks good though :-)
>>
>>
>> Segher
>>
>>
> 
> gcc/ChangeLog:
> 
> 2018-06-22  Kelvin Nilsen  
> 
>   * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Change
>   behavior of vec_pack (vector double, vector double) to match
>   behavior of vec_float2 (vector double, vector double).
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-06-22  Kelvin Nilsen  
> 
>   * gcc.target/powerpc/builtins-3-p8.c (test_pack_float): Remove
>   this test.
>   * gcc.target/powerpc/builtins-9.c: New test.
>   * gcc.target/powerpc/fold-vec-pack-double.c: Modify dg directives
>   to expect different code generation on big-endian vs.
>   little-endian targets.
> 
> Index: gcc/config/rs6000/rs6000-c.c
> ===
> --- gcc/config/rs6000/rs6000-c.c  (revision 261775)
> +++ gcc/config/rs6000/rs6000-c.c  (working copy)
> @@ -2425,7 +2425,7 @@ const struct altivec_builtin_types altivec_overloa
>  RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V2DI, 
> RS6000_BTI_unsigned_V2DI, 0 },
>{ ALTIVEC_BUILTIN_VEC_PACK, P8V_BUILTIN_VPKUDUM,
>  RS6000_BTI_bool_V4SI, RS6000_BTI_bool_V2DI, RS6000_BTI_bool_V2DI, 0 },
> -  { ALTIVEC_BUILTIN_VEC_PACK, P8V_BUILTIN_VPKUDUM,
> +  { ALTIVEC_BUILTIN_VEC_PACK, P8V_BUILTIN_FLOAT2_V2DF,
>  RS6000_BTI_V4SF, RS6000_BTI_V2DF, RS6000_BTI_V2DF, 0 },
> 
>{ P8V_BUILTIN_VEC_NEG, P8V_BUILTIN_NEG_V16QI,
> Index: gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c  (revision 261775)
> +++ gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c  (working copy)
> @@ -11,12 +11,6 @@ test_eq_long_long (vector bool long long x, vector
>   return vec_cmpeq (x, y);
>  }
> 
> -vector float
> -test_pack_float (vector double x, vector double y)
> -{
> -  return vec_pack (x, y);
> -}
> -
>  vector unsigned char
>  test_vsi_packs_vusi_vusi (vector unsigned short x,
>vector unsigned short y)
> @@ -214,7 +208,6 @@ test_neg_double (vector double x)
>  /* Expected test results:
> 
>   test_eq_long_long 1 vcmpequd inst
> - test_pack_float   1 vpkudum inst
>   test_vsi_packs_vsll_vsll  1 vpksdss
>   test_vui_packs_vull_vull  1 vpkudus
>   test_vui_packs_vssi_vssi  1 vpkshss
> @@ -239,7 +232,6 @@ test_neg_double (vector double x)
>   */
> 
>  /* { dg-final { scan-assembler-times "vcmpequd" 1 } } */
> -/* { dg-final { scan-assembler-times "vpkudum"  1 } } */
>  /* { dg-final { scan-assembler-times "vpksdss"  1 } } */
>  /* { dg-final { scan-assembler-times "vpkudus"  1 } } */  
>  /* { dg-final { scan-assembler-times "vpkuhus"  2 } } */
> Index: gcc/testsuite/gcc.target/powerpc/builtins-9.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/builtins-9.c (nonexistent)
> +++ gcc/testsuite/gcc.target/powerpc/builtins-9.c (working copy)
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */
> +/* { dg-options "-maltivec -mcpu=power8 -O3" } */
> +
> +#include 
> +
> +vector float
> +test_pack_float (vector double x, vector double y)
> +{
> +  return vec_pack (x, y);
> +}
> +
> +/* { dg-final { scan-assembler-times "vmrgew" 1 { target be } } } */
> +/* { dg-final { scan-assembler-times "vmrgow"  1 { target le } } } */
> +
> +/* { dg-final { scan-assembler-times "x

Re: [PATCH v2, rs6000] Fix implementation of vec_pack (vector double, vector double) built-in function

[Kelvin Nilsen]

Thanks for feedback.  It turns out that the vmrgew and vmrgow instructions 
require power 8.

After coordinating with Segher on minor refinements to the test cases, I have 
committed the patch as quoted below to the trunk.

On 6/19/18 5:37 PM, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Jun 19, 2018 at 01:37:51PM -0500, Kelvin Nilsen wrote:
>> --- gcc/testsuite/gcc.target/powerpc/builtins-9.c(nonexistent)
>> +++ gcc/testsuite/gcc.target/powerpc/builtins-9.c(working copy)
>> @@ -0,0 +1,21 @@
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target powerpc_p8vector_ok } */
>> +/* Expect same instruction selecton on p8 and above.  Fix if future
>> +   targets behave differently.  */
>> +/* { dg-options "-O3 -maltivec" } */
> 
> But this doesn't use -mcpu=power8 or similar.  Does it need it anyway?
> Both xxpermdi and xvcvdpsp are Power7 (ISA 2.06) and the rest is AltiVec?
> So maybe just powerpc_vsx_ok?
> 
>> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } } */
> 
> You do not use -mcpu= so you don't need this.
> 
> Same issues in the next test.  Rest looks good though :-)
> 
> 
> Segher
> 
> 

gcc/ChangeLog:

2018-06-22  Kelvin Nilsen  

* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Change
behavior of vec_pack (vector double, vector double) to match
behavior of vec_float2 (vector double, vector double).

gcc/testsuite/ChangeLog:

2018-06-22  Kelvin Nilsen  

* gcc.target/powerpc/builtins-3-p8.c (test_pack_float): Remove
this test.
* gcc.target/powerpc/builtins-9.c: New test.
* gcc.target/powerpc/fold-vec-pack-double.c: Modify dg directives
to expect different code generation on big-endian vs.
little-endian targets.

Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 261775)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -2425,7 +2425,7 @@ const struct altivec_builtin_types altivec_overloa
 RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V2DI, 
RS6000_BTI_unsigned_V2DI, 0 },
   { ALTIVEC_BUILTIN_VEC_PACK, P8V_BUILTIN_VPKUDUM,
 RS6000_BTI_bool_V4SI, RS6000_BTI_bool_V2DI, RS6000_BTI_bool_V2DI, 0 },
-  { ALTIVEC_BUILTIN_VEC_PACK, P8V_BUILTIN_VPKUDUM,
+  { ALTIVEC_BUILTIN_VEC_PACK, P8V_BUILTIN_FLOAT2_V2DF,
 RS6000_BTI_V4SF, RS6000_BTI_V2DF, RS6000_BTI_V2DF, 0 },
 
   { P8V_BUILTIN_VEC_NEG, P8V_BUILTIN_NEG_V16QI,
Index: gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c
===
--- gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c(revision 261775)
+++ gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c(working copy)
@@ -11,12 +11,6 @@ test_eq_long_long (vector bool long long x, vector
return vec_cmpeq (x, y);
 }
 
-vector float
-test_pack_float (vector double x, vector double y)
-{
-  return vec_pack (x, y);
-}
-
 vector unsigned char
 test_vsi_packs_vusi_vusi (vector unsigned short x,
   vector unsigned short y)
@@ -214,7 +208,6 @@ test_neg_double (vector double x)
 /* Expected test results:
 
  test_eq_long_long 1 vcmpequd inst
- test_pack_float   1 vpkudum inst
  test_vsi_packs_vsll_vsll  1 vpksdss
  test_vui_packs_vull_vull  1 vpkudus
  test_vui_packs_vssi_vssi  1 vpkshss
@@ -239,7 +232,6 @@ test_neg_double (vector double x)
  */
 
 /* { dg-final { scan-assembler-times "vcmpequd" 1 } } */
-/* { dg-final { scan-assembler-times "vpkudum"  1 } } */
 /* { dg-final { scan-assembler-times "vpksdss"  1 } } */
 /* { dg-final { scan-assembler-times "vpkudus"  1 } } */  
 /* { dg-final { scan-assembler-times "vpkuhus"  2 } } */
Index: gcc/testsuite/gcc.target/powerpc/builtins-9.c
===
--- gcc/testsuite/gcc.target/powerpc/builtins-9.c   (nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/builtins-9.c   (working copy)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
+/* { dg-options "-maltivec -mcpu=power8 -O3" } */
+
+#include 
+
+vector float
+test_pack_float (vector double x, vector double y)
+{
+  return vec_pack (x, y);
+}
+
+/* { dg-final { scan-assembler-times "vmrgew" 1 { target be } } } */
+/* { dg-final { scan-assembler-times "vmrgow"  1 { target le } } } */
+
+/* { dg-final { scan-assembler-times "xvcvdpsp"  2 } } */
+/* { dg-final { scan-assembler-times "xxpermdi"  2 } } */
+
Index: gcc/testsuite/gcc.target/powerpc/fold-vec-pack-double.c
===
--- gcc/testsuite/gcc.target/powerpc/fold-vec-pack-double.c (revision 
261775)
+++ gcc/testsuite/gcc.target/powerpc/fold-vec-pack-double.c 

Re: [PATCH] avoid using strnlen result for late calls to strlen (PR 82604)

[Jeff Law]

On 06/18/2018 01:15 PM, Martin Sebor wrote:
> While looking into opportunities to detect strnlen/strlen coding
> mistakes (pr86199) I noticed a bug in the strnlen implementation
> I committed earlier today that lets a strnlen() result be saved
> and used in subsequent calls to strlen() with the same argument.
> The attached patch changes the handle_builtin_strlen() function
> to discard the strnlen() result unless its bound is greater than
> the length of the string.
> 
> Martin
> 
> gcc-86204.diff
> 
> 
> PR tree-optimization/86204 -  wrong strlen result after prior strnlen
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/86204
>   * tree-ssa-strlen.c (handle_builtin_strlen): Avoid storing
>   a strnlen result if it's less than the length of the string.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/86204
>   * gcc.dg/strlenopt-46.c: New test.
OK.  Though I must admit I don't like having variables "bounded" and
"bound" in the same function.  So consider renaming one to avoid future
confusion.

jeff

C++ PATCHes for c++/86219, ICE with erroneous init in template

[Jason Merrill]

The problem in this testcase was that the initializer looked constant
to is_nondependent_constant_expression, but instantiating it found the
conversion error, but because fold_non_dependent_expr passed tf_none
to the instantiation, we didn't give an error.  store_init_value then
happily stuck the error_mark_node in DECL_INITIAL, leading to an abort
later on when we find it without seen_error().

Basically, if we're going to keep around the result of the
instantiation, we need to pass in the appropriate complain argument.
So this patch adds a complain parameter to fold_non_dependent_expr.
It also changes the default to tf_warning_or_error, like it was in
older releases.

This change meant that the use in build_cxx_call would start to
diagnose conversion problems without the relevant information about
which parameter the conversion was for, so I've disabled that folding
when we're in a template.

In store_init_value, I also think we want to go back to the original
uninstantiated initializer if folding doesn't actually produce a
constant value: we want something that's OK to re-tsubst later.

I considered switching store_init_value back to using
instantiate_non_dependent_expr; the switch to fold_non_dependent_expr
was motivated by a problem with force_paren_expr making an expression
dependent that wasn't previously.  To address that, since we're using
VIEW_CONVERT_EXPR for location wrappers now, let's try using it here
as well.  But I ended up staying with fold_non_dependent_expr anyway.

Tested x86_64-pc-linux-gnu, applying to trunk.  For GCC 8 I'm applying
a much more localized patch, that just switches to tf_warning_or_error
for store_init_value.
commit d78857c84e5daf8b8f4cfa9db0833748e23f76b1
Author: Jason Merrill 
Date:   Thu Jun 21 14:54:59 2018 -0400

PR c++/86219 - ICE with erroneous initializer in template.

* constexpr.c (fold_non_dependent_expr): Add complain parm.
* call.c, expr.c, init.c, pt.c, semantics.c, typeck.c, typeck2.c:
Pass it.
* call.c (build_cxx_call): Don't mess with builtins in a template.
* typeck2.c (store_init_value): If fold_non_dependent_expr didn't
produce a constant value, go back to the uninstantiated form.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index e417590e97d..aa0e696972a 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -544,7 +544,7 @@ null_ptr_cst_p (tree t)
 }
   else if (CP_INTEGRAL_TYPE_P (type))
 {
-  t = fold_non_dependent_expr (t);
+  t = fold_non_dependent_expr (t, tf_none);
   STRIP_NOPS (t);
   if (integer_zerop (t) && !TREE_OVERFLOW (t))
 	return true;
@@ -8796,6 +8796,7 @@ build_cxx_call (tree fn, int nargs, tree *argarray,
 
   /* Check that arguments to builtin functions match the expectations.  */
   if (fndecl
+  && !processing_template_decl
   && DECL_BUILT_IN (fndecl)
   && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
 {
@@ -8804,7 +8805,7 @@ build_cxx_call (tree fn, int nargs, tree *argarray,
   /* We need to take care that values to BUILT_IN_NORMAL
  are reduced.  */
   for (i = 0; i < nargs; i++)
-	argarray[i] = fold_non_dependent_expr (argarray[i]);
+	argarray[i] = maybe_constant_value (argarray[i]);
 
   if (!check_builtin_function_arguments (EXPR_LOCATION (fn), vNULL, fndecl,
 	 nargs, argarray))
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index dea2a4e57b3..365296d6e3b 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -5179,12 +5179,20 @@ clear_cv_and_fold_caches (void)
 /* Like maybe_constant_value but first fully instantiate the argument.
 
Note: this is equivalent to instantiate_non_dependent_expr_sfinae
-   (t, tf_none) followed by maybe_constant_value but is more efficient,
-   because calls instantiation_dependent_expression_p and
-   potential_constant_expression at most once.  */
+   (t, complain) followed by maybe_constant_value but is more efficient,
+   because it calls instantiation_dependent_expression_p and
+   potential_constant_expression at most once.
+
+   Callers should generally pass their active complain, or if they are in a
+   non-template, diagnosing context, they can use the default of
+   tf_warning_or_error.  Callers that might be within a template context, don't
+   have a complain parameter, and aren't going to remember the result for long
+   (e.g. null_ptr_cst_p), can pass tf_none and deal with error_mark_node
+   appropriately.  */
 
 tree
-fold_non_dependent_expr (tree t)
+fold_non_dependent_expr (tree t,
+			 tsubst_flags_t complain /* = tf_warning_or_error */)
 {
   if (t == NULL_TREE)
 return NULL_TREE;
@@ -5201,7 +5209,7 @@ fold_non_dependent_expr (tree t)
   if (is_nondependent_constant_expression (t))
 	{
 	  processing_template_decl_sentinel s;
-	  t = instantiate_non_dependent_expr_internal (t, tf_none);
+	  t = instantiate_non_dependent_expr_internal (t, complain);
 
 	  if (type_unknown_p (t)
 	  || BRACE_E

[PATCH, rs6000] Fix AIX test case failures

[Carl Love]

GCC Maintainers:

The following patch addresses test failures on AIX.  

The patch has been tested on 

powerpc64le-unknown-linux-gnu (Power 8 LE)  
powerpc64-unknown-linux-gnu (Power 8 BE)
AIX 7200-00-01-1543 (Power 8 BE)

With no regressions.

Please let me know if the patch looks OK for GCC mainline. 

 Carl Love
--

gcc/testsuite/ChangeLog:

2018-06-22  Carl Love  

* gcc.target/powerpc/divkc3-2.c: Make check Linux and AIX specific.
* gcc.target/powerpc/divkc3-3.c: Make check Linux and AIX specific.
* gcc.target/powerpc/fold-vec-mergehl-double.c: Update counts.
* gcc.target/powerpc/mulkc3-2.c: Make check Linux and AIX specific.
* gcc.target/powerpc/mulkc3-3.c: Make check Linux and AIX specific.
* gcc.target/powerpc/pr85456.c: Make check Linux and AIX specific.
---
 gcc/testsuite/gcc.target/powerpc/divkc3-2.c| 3 ++-
 gcc/testsuite/gcc.target/powerpc/divkc3-3.c| 3 ++-
 gcc/testsuite/gcc.target/powerpc/fold-vec-mergehl-double.c | 5 ++---
 gcc/testsuite/gcc.target/powerpc/mulkc3-2.c| 3 ++-
 gcc/testsuite/gcc.target/powerpc/mulkc3-3.c| 3 ++-
 gcc/testsuite/gcc.target/powerpc/pr85456.c | 3 ++-
 6 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/divkc3-2.c 
b/gcc/testsuite/gcc.target/powerpc/divkc3-2.c
index d3fcbed..79d9157 100644
--- a/gcc/testsuite/gcc.target/powerpc/divkc3-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/divkc3-2.c
@@ -13,4 +13,5 @@ divide (cld_t *p, cld_t *q, cld_t *r)
   *p = *q / *r;
 }
 
-/* { dg-final { scan-assembler "bl __divkc3" } } */
+/* { dg-final { scan-assembler "bl __divkc3" { target { powerpc*-*-linux* } } 
} } */
+/* { dg-final { scan-assembler "bl .__divdc3" { target { powerpc*-*-aix* } } } 
} */
diff --git a/gcc/testsuite/gcc.target/powerpc/divkc3-3.c 
b/gcc/testsuite/gcc.target/powerpc/divkc3-3.c
index 45695fe..462e77f 100644
--- a/gcc/testsuite/gcc.target/powerpc/divkc3-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/divkc3-3.c
@@ -13,4 +13,5 @@ divide (cld_t *p, cld_t *q, cld_t *r)
   *p = *q / *r;
 }
 
-/* { dg-final { scan-assembler "bl __divtc3" } } */
+/* { dg-final { scan-assembler "bl __divtc3" { target { powerpc*-*-linux* } } 
} } */
+/* { dg-final { scan-assembler "bl .__divdc3" { target { powerpc*-*-aix* } } } 
} */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-mergehl-double.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-mergehl-double.c
index 25f4bc6..403876d 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-mergehl-double.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-mergehl-double.c
@@ -19,7 +19,6 @@ testd_h (vector double vd2, vector double vd3)
   return vec_mergeh (vd2, vd3);
 }
 
-/* vec_merge with doubles tend to just use xxpermdi (3 ea for BE, 1 ea for 
LE).  */
-/* { dg-final { scan-assembler-times "xxpermdi" 2  { target { powerpc*le-*-* } 
}} } */
-/* { dg-final { scan-assembler-times "xxpermdi" 6  { target { powerpc-*-* } }  
   } } */
+/* { dg-final { scan-assembler-times "xxpermdi" 2 } } */
+
 
diff --git a/gcc/testsuite/gcc.target/powerpc/mulkc3-2.c 
b/gcc/testsuite/gcc.target/powerpc/mulkc3-2.c
index 9ba577a..f3ba80e 100644
--- a/gcc/testsuite/gcc.target/powerpc/mulkc3-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/mulkc3-2.c
@@ -13,4 +13,5 @@ multiply (cld_t *p, cld_t *q, cld_t *r)
   *p = *q * *r;
 }
 
-/* { dg-final { scan-assembler "bl __mulkc3" } } */
+/* { dg-final { scan-assembler "bl __mulkc3" { target { powerpc*-*-linux* } } 
} } */
+/* { dg-final { scan-assembler "bl .__muldc3" { target { powerpc*-*-aix* } } } 
} */
diff --git a/gcc/testsuite/gcc.target/powerpc/mulkc3-3.c 
b/gcc/testsuite/gcc.target/powerpc/mulkc3-3.c
index db87301..0c27dea 100644
--- a/gcc/testsuite/gcc.target/powerpc/mulkc3-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/mulkc3-3.c
@@ -13,4 +13,5 @@ multiply (cld_t *p, cld_t *q, cld_t *r)
   *p = *q * *r;
 }
 
-/* { dg-final { scan-assembler "bl __multc3" } } */
+/* { dg-final { scan-assembler "bl __multc3" { target { powerpc*-*-linux* } } 
} } */
+/* { dg-final { scan-assembler "bl .__muldc3" { target { powerpc*-*-aix* } } } 
} */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr85456.c 
b/gcc/testsuite/gcc.target/powerpc/pr85456.c
index b9df16a..b928292 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr85456.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr85456.c
@@ -11,4 +11,5 @@ do_powl (long double a, int i)
   return __builtin_powil (a, i);
 }
 
-/* { dg-final { scan-assembler "bl __powikf2" } } */
+/* { dg-final { scan-assembler "bl __powikf2" { target { powerpc*-*-linux* } } 
} } */
+/* { dg-final { scan-assembler "bl .__powidf2" { target { powerpc*-*-aix* } } 
} } */
-- 
2.7.4

[PATCH] Fix up AVX512F 128/256-bit shifts from using EVEX counts (PR target/84786)

[Jakub Jelinek]

Hi!

The following testcase got fixed in 8/trunk with r253924 part of
PR82370 enhancements, but that is not IMHO something we should backport.
So instead the following patch adds something simpler, use Yv constraint
for the DImode shift count in instructions that need AVX512VL when EVEX
encoded if AVX512VL is not enabled instead of v.  Bootstrapped/regtested
on 7.x branch on x86_64-linux and i686-linux, ok for 7.x?

Is the testcase alone ok also for trunk/8.2?

2018-06-22  Jakub Jelinek  

PR target/84786
* config/i386/sse.md (vshift_count): New mode attr.
(3): Use N instead of vN
as last operand's constraint for VI2_AVX2_AVX512BW shifts.  Use YvN
instead of vN as last operand's constraint for VI48_AVX2 shifts.

* gcc.target/i386/avx512f-pr84786-3.c: New test.

--- gcc/config/i386/sse.md.jj   2018-06-22 16:26:34.960232598 +0200
+++ gcc/config/i386/sse.md  2018-06-22 18:04:12.948857074 +0200
@@ -10680,11 +10680,14 @@ (define_insn "ashr3"
(const_string "0")))
(set_attr "mode" "")])
 
+(define_mode_attr vshift_count
+  [(V32HI "v") (V16HI "Yv") (V8HI "Yv")])
+
 (define_insn "3"
   [(set (match_operand:VI2_AVX2_AVX512BW 0 "register_operand" "=x,v")
(any_lshift:VI2_AVX2_AVX512BW
  (match_operand:VI2_AVX2_AVX512BW 1 "register_operand" "0,v")
- (match_operand:DI 2 "nonmemory_operand" "xN,vN")))]
+ (match_operand:DI 2 "nonmemory_operand" "xN,N")))]
   "TARGET_SSE2 &&  && "
   "@
p\t{%2, %0|%0, %2}
@@ -10703,7 +10706,7 @@ (define_insn "3"
   "@
p\t{%2, %0|%0, %2}
--- gcc/testsuite/gcc.target/i386/avx512f-pr84786-3.c.jj2018-06-22 
18:05:06.267926542 +0200
+++ gcc/testsuite/gcc.target/i386/avx512f-pr84786-3.c   2018-06-22 
17:39:23.445546062 +0200
@@ -0,0 +1,50 @@
+/* PR target/84786 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-mavx512f -mno-avx512vl -O2" } */
+
+#include 
+
+__m512i v;
+__m128i w;
+
+__m128i
+foo (__m128i x, int y)
+{
+  __m128i z;
+#define A(n) register __m512i zmm##n __asm ("zmm" #n);
+#define B A(1) A(2) A(3) A(4) A(5) A(6) A(7) \
+ A(8) A(9) A(10) A(11) A(12) A(13) A(14)
+  B
+#undef A
+#define A(n) asm volatile ("" : "=v" (zmm##n) : "0" (v));
+  B
+  asm volatile ("" : "=x" (z) : "0" (w));
+  x = _mm_srli_epi16 (x, y);
+  asm volatile ("" : : "x" (z));
+#undef A
+#define A(n) asm volatile ("" : : "v" (zmm##n));
+  B
+  return x;
+}
+
+__m256i
+bar (__m256i x, int y)
+{
+  __m128i z;
+#undef A
+#define A(n) register __m512i zmm##n __asm ("zmm" #n);
+  B
+#undef A
+#define A(n) asm volatile ("" : "=v" (zmm##n) : "0" (v));
+  B
+  asm volatile ("" : "=x" (z) : "0" (w));
+  x = _mm256_slli_epi16 (x, y);
+  asm volatile ("" : : "x" (z));
+#undef A
+#define A(n) asm volatile ("" : : "v" (zmm##n));
+  B
+  return x;
+}
+
+/* { dg-final { scan-assembler-not "vpsrlw\[\^\n\r]*xmm(1\[6-9]|\[23]\[0-9])" 
} } */
+/* { dg-final { scan-assembler-not "vpsllw\[\^\n\r]*xmm(1\[6-9]|\[23]\[0-9])" 
} } */

Jakub

Re: [PATCH] libiberty: fix memory usage explosion for invalid templates (PR demangler/84668)

[Jeff Law]

On 03/03/2018 05:48 AM, David Malcolm wrote:
> PR demangler/84668 reports this failure of c++filt (found by fuzzing):
> 
> $ c++filt '__H5z55_H5z555'
> c++filt: out of memory allocating 18446744071696285694 bytes after a total of 
> 135168 bytes
> 
> internal_cplus_demangle handles the "H5" as a template with 5 arguments;
> the "z55" is handled as a template parameter length of
> 55, though this is truncated to 32-bits to 1260588259:
> 
> (gdb) p /x 55
> $19 = 0x14b230ce3
> 
> (gdb) p /x r
> $18 = 0x4b230ce3
> 
> (gdb) p r
> $17 = 1260588259
> 
> demangle_template_template_parm repeatedly calls do_type for each of
> these 1.2 billion template params, and each call attempts to handle the
> "_", but hits this within demangle_fund_type:
> 
> 3996/* Now pick off the fundamental type.  There can be only one.  */
> 3997
> 3998switch (**mangled)
> 3999  {
> 4000  case '\0':
> 4001  case '_':
> 4002break;
> 
> and thus returns true for success.  It does this without consuming any
> of the input string.
> 
> At each iteration, it appends ", ", leading to the construction of
> a string of the form:
> 
>   " 
> and eventually the allocation fails.
> 
> It seems like a bug for demangle_template_template_parm to be able to
> arbitrarily grow like this without consuming the input string (or failing).
> 
> This patch fixes the issue by making the NIL / '_' cases quoted above be
> a failure, thus ending the iteration.  I'm not sure if this is the
> correct behavior (I'm new to this code), but none of the existing testcases
> are affected.
> 
> Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
> 
> OK for trunk?
> 
> libiberty/ChangeLog:
>   PR demangler/84668
>   * cplus-dem.c (demangle_fund_type) <'\0', '_'>: Fail.
>   * testsuite/demangle-expected: Add test.
I kept hoping someone else would chime in here :(

You should probably ping Jason directly.  He's more likely to know if we
can blindly return a failure at this point.

Jeff

Backports to 7.x branch

[Jakub Jelinek]

Hi!

I've backported following 61 trunk commits to 7.x branch (2 patches contain
more than one commit), bootstrapped/regtested them on x86_64-linux and
i686-linux and committed to 7.x branch.

Jakub
2018-06-22  Jakub Jelinek  

Backported from mainline
2018-03-02  Jakub Jelinek  

PR c++/84662
* pt.c (tsubst_copy_and_build) : Use
RETURN instead of return.
: Likewise.
: If op0 is error_mark_node, just return
it instead of wrapping it into CONVERT_EXPR.

* g++.dg/cpp1y/pr84662.C: New test.

--- gcc/cp/pt.c (revision 258145)
+++ gcc/cp/pt.c (revision 258146)
@@ -17318,14 +17318,14 @@ tsubst_copy_and_build (tree t,
if (targs)
  targs = tsubst_template_args (targs, args, complain, in_decl);
if (targs == error_mark_node)
- return error_mark_node;
+ RETURN (error_mark_node);
 
if (TREE_CODE (templ) == SCOPE_REF)
  {
tree name = TREE_OPERAND (templ, 1);
tree tid = lookup_template_function (name, targs);
TREE_OPERAND (templ, 1) = tid;
-   return templ;
+   RETURN (templ);
  }
 
if (variable_template_p (templ))
@@ -17401,6 +17401,8 @@ tsubst_copy_and_build (tree t,
   {
tree type = tsubst (TREE_TYPE (t), args, complain, in_decl);
tree op0 = RECUR (TREE_OPERAND (t, 0));
+   if (op0 == error_mark_node)
+ RETURN (error_mark_node);
RETURN (build1 (CONVERT_EXPR, type, op0));
   }
 
@@ -17549,7 +17551,7 @@ tsubst_copy_and_build (tree t,
   {
tree op0 = RECUR (TREE_OPERAND (t, 0));
tree op1 = RECUR (TREE_OPERAND (t, 1));
-   return fold_build_pointer_plus (op0, op1);
+   RETURN (fold_build_pointer_plus (op0, op1));
   }
 
 case SCOPE_REF:
--- gcc/testsuite/g++.dg/cpp1y/pr84662.C(nonexistent)
+++ gcc/testsuite/g++.dg/cpp1y/pr84662.C(revision 258146)
@@ -0,0 +1,6 @@
+// PR c++/84662
+// { dg-do compile { target c++14 } }
+// { dg-options "" }
+
+double b;
+a (__attribute__((c (0 && int() - ([] {} && b) || auto;// { dg-error 
"expected constructor, destructor, or type conversion before" }
2018-06-22  Jakub Jelinek  

Backported from mainline
2018-03-05  Jakub Jelinek  

PR target/84700
* combine.c (combine_simplify_rtx): Don't try to simplify if
if_then_else_cond returned non-NULL, but either true_rtx or false_rtx
are equal to x.

* gcc.target/powerpc/pr84700.c: New test.

--- gcc/combine.c   (revision 258262)
+++ gcc/combine.c   (revision 258263)
@@ -5734,7 +5734,11 @@ combine_simplify_rtx (rtx x, machine_mod
  /* If everything is a comparison, what we have is highly unlikely
 to be simpler, so don't use it.  */
  && ! (COMPARISON_P (x)
-   && (COMPARISON_P (true_rtx) || COMPARISON_P (false_rtx
+   && (COMPARISON_P (true_rtx) || COMPARISON_P (false_rtx)))
+ /* Similarly, if we end up with one of the expressions the same
+as the original, it is certainly not simpler.  */
+ && ! rtx_equal_p (x, true_rtx)
+ && ! rtx_equal_p (x, false_rtx))
{
  rtx cop1 = const0_rtx;
  enum rtx_code cond_code = simplify_comparison (NE, &cond, &cop1);
--- gcc/testsuite/gcc.target/powerpc/pr84700.c  (nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr84700.c  (revision 258263)
@@ -0,0 +1,12 @@
+/* PR target/84700 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -misel" } */
+
+long long int
+foo (long long int x)
+{
+  long long int a = x < 2;
+  int b = a >= 0;
+
+  return a + ((x == 0) ? a : b);
+}
2018-06-22  Jakub Jelinek  

Backported from mainline
2018-03-08  Jakub Jelinek  

PR tree-optimization/84739
* tree-tailcall.c (find_tail_calls): Check call arguments against
DECL_ARGUMENTS (current_function_decl) rather than
DECL_ARGUMENTS (func) when checking for tail recursion.

* gcc.dg/pr84739.c: New test.

--- gcc/tree-tailcall.c (revision 258350)
+++ gcc/tree-tailcall.c (revision 258351)
@@ -481,7 +481,7 @@ find_tail_calls (basic_block bb, struct
 {
   tree arg;
 
-  for (param = DECL_ARGUMENTS (func), idx = 0;
+  for (param = DECL_ARGUMENTS (current_function_decl), idx = 0;
   param && idx < gimple_call_num_args (call);
   param = DECL_CHAIN (param), idx ++)
{
--- gcc/testsuite/gcc.dg/pr84739.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/pr84739.c  (revision 258351)
@@ -0,0 +1,26 @@
+/* PR tree-optimization/84739 */
+/* { dg-do compile } */
+/* { dg-require-weak "" } */
+/* { dg-options "-O2 -w" } */
+
+static void baz (void) __attribute__((weakref("bar")));
+
+int
+foo (int x, int y)
+{
+  if (x)
+y = 0;
+  if (y)
+goto lab;
+  y = 0;
+lab:
+  return y;
+}
+
+void
+bar (int x, int y)
+{
+  y = foo (x, y);
+  if (y != 0)
+baz ();
+}
2018-06-22  Jakub J

[PATCH] Remove stale doc notes about netbsd and openbsd

[Maya Rashish]

That isn't a default any more because the default is 80486 with FPU.

---
 gcc/doc/invoke.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 9bb1a4910b2..f231da3cde2 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -26851,8 +26851,8 @@ in ordinary CPU registers instead.
 @opindex mno-fancy-math-387
 Some 387 emulators do not support the @code{sin}, @code{cos} and
 @code{sqrt} instructions for the 387.  Specify this option to avoid
-generating those instructions.  This option is the default on
-OpenBSD and NetBSD@.  This option is overridden when @option{-march}
+generating those instructions.
+This option is overridden when @option{-march}
 indicates that the target CPU always has an FPU and so the
 instruction does not need emulation.  These
 instructions are not generated unless you also use the
-- 
2.17.0

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Michael Meissner]

On Thu, Jun 21, 2018 at 02:22:50PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 21, 2018 at 01:26:19PM -0400, Michael Meissner wrote:
> > On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> > > > * config.gcc (powerpc64le*): Remove multilib support for IEEE 
> > > > and
> > > > IBM long double.
> > > > * config/rs6000/rs6000.c (rs6000_option_override_internal):
> > > > Likewise.
> > > > * config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
> > > > * config/rs6000/t-ldouble-linux64le-ibm: Delete, IEEE/IBM long
> > > > double multilib no longer supported.
> > > > * config/rs6000/t-ldouble-linux64le-ieee: Likewise.
> > > > * doc/install.texi (PowerPC options): Delete information about
> > > > IEEE/IBM long double multilibs.
> > > 
> > > This reverts r256775 (the commit message should say), except the linux64.h
> > > parts, and it seems you just missed those?
> > 
> > No it only reverts part of r256775.  The main part of the r256775 change is 
> > to
> > add support for --with-long-double-format={ieee,ibm} which we need to keep.
> 
> That is r256558 as far as I see?

Yes you were right, r256775 was the patch that enabled multilibs by default,
and 256558 was the patch that added --with-long-double-format=.  I thought
I had submitted them as part of one patch.

Here is the patch redone to disable multilib support altogether.  I verified
that without --{enable,disable}-multilib that it no longer builds a multilib
compiler.  Can I install this into the trunk and to the GCC 8.x branch?

2018-06-22  Michael Meissner  

* config.gcc (powerpc64le*): Revert January 16th, 2018 patch that
added IEEE/IBM long double multilib support on PowerPC little
endian Linux systems.
* config/rs6000/linux64.h (MULTILIB_DEFAULTS_IEEE): Likewise.
(MULTILIB_DEFAULTS): Likewise.
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Likewise.
* config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
* config/rs6000/t-ldouble-linux64le-ibm: Delete, no longer used.
* config/rs6000/t-ldouble-linux64le-ieee: Delete, no longer used.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 261910)
+++ gcc/config.gcc  (working copy)
@@ -4566,16 +4566,6 @@ case "${target}" in
elif test x$with_long_double_format = xibm; then
tm_defines="${tm_defines} TARGET_IEEEQUAD_DEFAULT=0"
fi
-
-   case "${target}:${enable_multilib}:${with_long_double_format}" 
in
-   powerpc64le*:yes:ieee | powerpc64le*:yes:ibm)
-   tm_defines="${tm_defines} TARGET_IEEEQUAD_MULTILIB=1"
-   tmake_file="${tmake_file} 
rs6000/t-ldouble-linux64le-${with_long_double_format}"
-   ;;
-   *)
-   :
-   ;;
-   esac
;;
 
s390*-*-*)
Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 261910)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -245,18 +245,11 @@ extern int dot_symbols;
 #define DYNAMIC_LINKER_PREFIX  ""
 #endif
 
-#if TARGET_IEEEQUAD_DEFAULT
-#define MULTILIB_DEFAULTS_IEEE "mabi=ieeelongdouble"
-
-#else  /* TARGET_IEEEQUAD_DEFAULT.  */
-#define MULTILIB_DEFAULTS_IEEE "mabi=ibmlongdouble"
-#endif /* TARGET_IEEEQUAD_DEFAULT.  */
-
-#undef MULTILIB_DEFAULTS
+#undef MULTILIB_DEFAULTS
 #if DEFAULT_ARCH64_P
-#define MULTILIB_DEFAULTS { "m64", MULTILIB_DEFAULTS_IEEE }
+#define MULTILIB_DEFAULTS { "m64" }
 #else
-#define MULTILIB_DEFAULTS { "m32", MULTILIB_DEFAULTS_IEEE }
+#define MULTILIB_DEFAULTS { "m32" }
 #endif
 
 /* Split stack is only supported for 64 bit, and requires glibc >= 2.18.  */
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 261910)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -4582,15 +4582,11 @@ rs6000_option_override_internal (bool gl
  systems will also set long double to be IEEE 128-bit.  AIX and Darwin
  explicitly redefine TARGET_IEEEQUAD and TARGET_IEEEQUAD_DEFAULT to 0, so
  those systems will not pick up this default.  Warn if the user changes the
- default unless either the user used the -Wno-psabi option, or the compiler
- was built to enable multilibs to switch between the two long double
- types.  */
+ default unless -Wno-psabi.  */
   if (!global_options_set.x_rs6000_ieeequad)
 rs6000_ieeequad = TARGET_IEEEQUAD_DEFAULT;
 
-  else if (!TARGET_IEEEQUAD_MULTILIB
-  && rs6000_ieeequad != 

[PRs fortran/82972, fortran/83088, fortran/85851] Fix ICE with -finit-derived when using iso_c_binding

[Fritz Reese]

All,

The attached patch generates special initializers for derived-type
c_ptr and c_funptr symbols so they are handled correctly by the
translation phase. Previously, an EXPR_STRUCTURE expression was
generated for both types, as c_ptr and c_funptr are structure types
with a c_address field. The c_address field never had its backend_decl
generated, because it is typically handled specially.

With the patch, the trunk compiler does not exhibit the bugs in the
mentioned PRs (82972, 83088, 85851). I did encounter some issues
building and regression testing the trunk compiler which I am certain
are unrelated. The current trunk fails to bootstrap for me so I am
using an older revision which appears to have some testcase issues.
The issues are attached at the bottom of this e-mail for reference.

In any case, the changelog is here, and the patch is attached. Aside
from the issues mentioned below the compile bootstraps and regression
tests successfully. Does this look OK for trunk? Furthermore, this
patch comes a bit late as the PRs were submitted before 8.1 was
released; is it appropriate to backport this to 7-branch and/or
8-branch?


>From b6fbe8e429d5c98675741234e2ac5cc6810df3c5 Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Fri, 22 Jun 2018 16:11:02 -0400
Subject: [PATCH] PR fortran/82972

Fix -finit-derived for c_ptr and c_funptr in programs which use iso_c_binding.

gcc/fortran/
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

gcc/testsuite/
* gfortran.dg/init_flag_17.f90: New testcase.
---
 gcc/fortran/expr.c | 33 +-
 gcc/testsuite/gfortran.dg/init_flag_17.f90 | 28 +
 2 files changed, 60 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/init_flag_17.f90


=== TEST ISSUES ===


$ gfortran --version
GNU Fortran (GCC) 8.0.0 20180110 (experimental)
...
$ make -sk check-fortran
...
FAIL: gfortran.dg/pr68078.f90   -O0  execution test
FAIL: gfortran.fortran-torture/compile/pr83081.f90,  -O3 -g
(internal compiler error)
...

In the first case (pr68078) the process appears to occasionally run
out of stack memory due to the setrlimit(), causing it to receive
SIGSEGV.

$ cd gcc/testsuite/gfortran.dg
$ gfortran pr68078.f90 set_vm_limit.c -o pr68078
$ i=0; time while ./a.out >/dev/null; do echo attempt $i; i=$(($i+1)) ; done
attempt 0
attempt 1
attempt 2
attempt 3
attempt 4
attempt 5
attempt 6
attempt 7
attempt 8
attempt 9
attempt 10
Segmentation fault (core dumped)

real0m0.104s
user0m0.007s
sys0m0.023s

The second case appears positively unrelated (and only occurs with -O3):

$ gfortran -c -O3 pr83081.f90
during GIMPLE pass: pcom
pr83081.f90:4:0:

   Subroutine SPLIFT (X,Y,YP,YPP,N,IERR,ISX,A1,B1,AN,BN)

internal compiler error: in probability_in, at profile-count.h:1038
0x6f47ee profile_count::probability_in(profile_count) const
/data/midas/foreese/src/gcc-trunk/gcc/profile-count.h:1038
0x6f47ee tree_transform_and_unroll_loop(loop*, unsigned int,
edge_def*, tree_niter_desc*, void (*)(loop*, void*), void*)
/data/midas/foreese/src/gcc-trunk/gcc/tree-ssa-loop-manip.c:1382
0xe36716 tree_predictive_commoning_loop
/data/midas/foreese/src/gcc-trunk/gcc/tree-predcom.c:3278
0xe37e7d tree_predictive_commoning()
/data/midas/foreese/src/gcc-trunk/gcc/tree-predcom.c:3312
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


=== END TEST ISSUES ===
From b6fbe8e429d5c98675741234e2ac5cc6810df3c5 Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Fri, 22 Jun 2018 16:11:02 -0400
Subject: [PATCH] PR fortran/82972

Fix -finit-derived for c_ptr and c_funptr in programs which use iso_c_binding.

gcc/fortran/
	* expr.c (component_initializer): Assign init expr to c->initializer.
	(generate_isocbinding_initializer): New.
	(gfc_generate_initializer): Call generate_isocbinding_initializer to
	generate initializers for c_ptr and c_funptr with -finit-derived.

gcc/testsuite/
	* gfortran.dg/init_flag_17.f90: New testcase.
---
 gcc/fortran/expr.c | 33 +-
 gcc/testsuite/gfortran.dg/init_flag_17.f90 | 28 +
 2 files changed, 60 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/init_flag_17.f90

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 45ccc184fc1..ad549911cd1 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4476,7 +4476,7 @@ component_initializer (gfc_typespec *ts, gfc_component *c, bool generate)
   gfc_apply_init (&c->ts, &c->attr, init);
 }
 
-  return init;
+  return (c->initializer = init);
 }
 
 
@@ -4488,6 +4488,33 @@

Re: [patch] add -nolibc option

[Jeff Law]

On 06/21/2018 11:06 AM, Olivier Hainque wrote:
> Hello Joseph,
> 
> Thanks for getting back to me on this!
> 
>> On 19 Jun 2018, at 17:50, Joseph Myers  wrote:
>>
>> On Thu, 7 Jun 2018, Olivier Hainque wrote:
>>
>>> An updated version of the patch is attached, accounting for
>>> your two comments and expanding on the .texi documentation a
>>> bit. 
>> I see you're not changing LINK_GCC_C_SEQUENCE_SPEC in arc/elf.h.  That's a 
>> slightly odd case in that it isn't actually using %L, but is using -lc 
>> directly, whereas there's an empty definition of LIB_SPEC.
> Indeed. I hadn't changed it because it was only added very recently
> (like last week or so) and so wasn't there when I shaped the patch.
> 
>> I'd expect the documentation to say something about libraries added only 
>> for particular languages by the front-end drivers (-lstdc++ -lm, 
>> -lgfortran -lm, etc.).  It may be that the option isn't particularly 
>> meaningful for code using such front-end drivers that add those libraries, 
>> because those libraries depend on libc (and code in those languages will 
>> generally depend on their libraries), but it should still say what the 
>> effects are.
> Agreed.
> 
> Attached is an updated version with the doc reworded to this
> effect, referring to "the system C library or system libraries tightly
> coupled with it", as opposed to "toolchain provided language support
> libraries".
> 
> -lm is a bit annoying. There are very few explicit occurrences as
> this is usually to be added by users. Still, among the few that are there,
> some are in LIB_SPEC and some are not. I have qualified this with a
> "in some configurations" which has the advantage on conveying honestly
> that the effect isn't very precisely defined.
> 
> It has been working well for the uses we had, indeed on bareboard
> configurations which is the stated intent.
> 
> Reboostrapping on x86_64-linux now. If there's meaningful extra
> testing you think I could make, I'll be happy to comply.
> 
> Thanks again for your input.
> 
> With Kind Regards,
> 
> Olivier
> 
> 
> nolibc2.diff

> +@item -nolibc
> +@opindex nolibc
> +Do not use the C library or system libraries tightly couple with it when
s/tightly couple/ that tightly couple/

or

s/couple/coupled/

OK with either of those trivial fixes.

jeff

Re: [x86] Do not omit the frame pointer at -O0

[Jeff Law]

On 06/20/2018 07:56 AM, Eric Botcazou wrote:
> Hi,
> 
> the fix for PR target/81736 unconditionally overrules 
> -fno-omit-frame-pointer, 
> including at -O0 where it is implicit.  That seems brutal and unnecessary so 
> the attached patch reverts it at -O0 and thus fixes 135 failures in the GDB 
> testsuite:
> 
> === gdb Summary ===
>  
> -# of expected passes   55397
> -# of unexpected failures   359
> +# of expected passes   55534
> +# of unexpected failures   224
>  # of unexpected successes  3
>  # of expected failures 64
>  # of unknown successes 3
> 
> Tested on x86-64/Linux, OK for mainline and 8 branch?
> 
> 
> 2018-06-20  Eric Botcazou  
> 
>   * config/i386/i386.c (ix86_finalize_stack_frame_flags): Do not overrule
>   -fno-omit-frame-pointer when not optimizing.
> 
OK
jeff

Re: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).

[Jeff Law]

On 05/16/2018 05:53 AM, Martin Liška wrote:
> On 12/21/2017 10:13 AM, Martin Liška wrote:
>> On 12/20/2017 06:45 PM, Jakub Jelinek wrote:
>>> Another thing is that the "/" in there is wrong, so
>>>   const char dir_separator_str[] = { DIR_SEPARATOR, '\0' };
>>>   char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL);
>>> needs to be used instead.
>> This looks much nicer, I forgot about DIR_SEPARATOR.
>>
>>> Does profile_data_prefix have any dir separators stripped from the end?
>> That's easy to achieve..
>>
>>> Is pwd guaranteed to be relative in this case?
>> .. however this is absolute path, which would be problematic on a DOC based 
>> FS.
>> Maybe we should do the same path mangling as we do for purpose of gcov:
>>
>> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424
> Hi.
> 
> I decided to implement that. Which means for:
> 
> $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out 
> 
> we get following file:
> /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda
> 
> That guarantees we have a unique file path. As seen in the PR it
> can produce a funny ICE.
> 
> I've been testing the patch.
> Ready after it finishes tests?
> 
> Martin
> 
>> What do you think about it?
>> Regarding the string manipulation: I'm not an expert, but work with string 
>> in C
>> is for me always a pain :)
>>
>> Martin
>>
> 
> 0001-When-using-fprofile-generate-some-path-mangle-absolu.patch
> 
> 
> From 386a4561a4d1501e8959871791289e95f6a89af5 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Wed, 16 Aug 2017 10:22:57 +0200
> Subject: [PATCH] When using -fprofile-generate=/some/path mangle absolute path
>  of file (PR lto/85759).
> 
> gcc/ChangeLog:
> 
> 2018-05-16  Martin Liska  
> 
>   PR lto/85759
>   * coverage.c (coverage_init): Mangle full path name.
>   * doc/invoke.texi: Document the change.
>   * gcov-io.c (mangle_path): New.
>   * gcov-io.h (mangle_path): Likewise.
>   * gcov.c (mangle_name): Use mangle_path for path mangling.
ISTM you can self-approve this now if you want it to move forward :-)

jeff

Re: [PATCH] [PR86064] split single cross-partition range with nonzero locviews

[Jeff Law]

On 06/12/2018 08:02 PM, Alexandre Oliva wrote:
> 
> We didn't split cross-partition ranges in loclists to output a
> whole-function location expression, but with nonzero locviews, we
> force loclists, and then we have to split to avoid cross-partition
> list entries.
> 
> From: Alexandre Oliva 
> for  gcc/ChangeLog
> 
>   PR debug/86064
>   * dwarf2out.c (loc_list_has_views): Adjust comments.
>   (dw_loc_list): Split single cross-partition range with
>   nonzero locview.
> 
> for  gcc/testsuite/ChangeLog
> 
>   PR debug/86064
>   * gcc.dg/pr86064.c: New.
OK.
Jeff

Re: [PATCH] c/55976 -Werror=return-type should error on returning a value from a void function

[Jeff Law]

On 06/19/2018 09:13 AM, dave.pa...@oracle.com wrote:
> This patch fixes spurious failure for C test added with original patch
> for bug 55976.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976
> 
> Added dg-prune-output for extraneous message causing unexpected test
> failure for test gcc.dg/noncompile/pr55976-1.c
> 
> Bootstrap tests run successfully x86_64-linux.
> 
> --Dave
> 
> CL-55976
> 
> 
> /testsuite
> 2018-06-19  David Pagan  
> 
>   PR c/55976
>   * gcc.dg/noncompile/pr55976-1.c: Add dg-prune-output for extraneous
> message causing unexpected test FAIL.
OK.
jeff

[PATCH] [RFC] Higher-level reporting of vectorization problems

[David Malcolm]

NightStrike and I were chatting on IRC last week about
issues with trying to vectorize the following code:

#include 
std::size_t f(std::vector> const & v) {
std::size_t ret = 0;
for (auto const & w: v)
ret += w.size();
return ret;
}

icc could vectorize it, but gcc couldn't, but neither of us could
immediately figure out what the problem was.

Using -fopt-info leads to a wall of text.

I tried using my patch here:

 "[PATCH] v3 of optinfo, remarks and optimization records"
  https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01267.html

It improved things somewhat, by showing:
(a) the nesting structure via indentation, and
(b) the GCC line at which each message is emitted (by using the
"remark" output)

but it's still a wall of text:

  https://dmalcolm.fedorapeople.org/gcc/2018-06-18/test.cc.remarks.html
  
https://dmalcolm.fedorapeople.org/gcc/2018-06-18/test.cc.d/..%7C..%7Csrc%7Ctest.cc.html#line-4

It doesn't yet provide a simple high-level message to a
tech-savvy user on what they need to do to get GCC to
vectorize their loop.

The pertinent dump messages are:

test.cc:4:23: remark: === try_vectorize_loop_1 === 
[../../src/gcc/tree-vectorizer.c:674:try_vectorize_loop_1]
cc1plus: remark:
Analyzing loop at test.cc:4 
[../../src/gcc/dumpfile.c:735:ensure_pending_optinfo]
test.cc:4:23: remark:  === analyze_loop_nest === 
[../../src/gcc/tree-vect-loop.c:2299:vect_analyze_loop]
[...snip...]
test.cc:4:23: remark:   === vect_analyze_loop_operations === 
[../../src/gcc/tree-vect-loop.c:1520:vect_analyze_loop_operations]
[...snip...]
test.cc:4:23: remark:==> examining statement: ‘_15 = _14 /[ex] 4;’ 
[../../src/gcc/tree-vect-stmts.c:9382:vect_analyze_stmt]
test.cc:4:23: remark:vect_is_simple_use: operand ‘_14’ 
[../../src/gcc/tree-vect-stmts.c:10064:vect_is_simple_use]
test.cc:4:23: remark:def_stmt: ‘_14 = _8 - _7;’ 
[../../src/gcc/tree-vect-stmts.c:10098:vect_is_simple_use]
test.cc:4:23: remark:type of def: internal 
[../../src/gcc/tree-vect-stmts.c:10112:vect_is_simple_use]
test.cc:4:23: remark:vect_is_simple_use: operand ‘4’ 
[../../src/gcc/tree-vect-stmts.c:10064:vect_is_simple_use]
test.cc:4:23: remark:op not supported by target. 
[../../src/gcc/tree-vect-stmts.c:5932:vectorizable_operation]
test.cc:4:23: remark:not vectorized: relevant stmt not supported: ‘_15 = 
_14 /[ex] 4;’ [../../src/gcc/tree-vect-stmts.c:9565:vect_analyze_stmt]
test.cc:4:23: remark:   bad operation or unsupported loop bound. 
[../../src/gcc/tree-vect-loop.c:2043:vect_analyze_loop_2]
cc1plus: remark: vectorized 0 loops in function. 
[../../src/gcc/tree-vectorizer.c:904:vectorize_loops]

In particular, that complaint from
  [../../src/gcc/tree-vect-stmts.c:9565:vect_analyze_stmt]
is coming from:

  if (!ok)
{
  if (dump_enabled_p ())
{
  dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
   "not vectorized: relevant stmt not ");
  dump_printf (MSG_MISSED_OPTIMIZATION, "supported: ");
  dump_gimple_stmt (MSG_MISSED_OPTIMIZATION, TDF_SLIM, stmt, 0);
}

  return false;
}

This got me thinking: the user presumably wants to know several
things:

* the location of the loop that can't be vectorized (vect_location
  captures this)
* location of the problematic statement
* why it's problematic
* the problematic statement itself.

The following is an experiment at capturing that information, by
recording an "opt_problem" instance describing what the optimization
problem is, created deep in the callstack when it occurs, for use
later on back at the top of the vectorization callstack.

This extra work is only done if dump_enabled_p.

It feels vaguely analogous to an exception object (in terms of
packaging up a problem that occurs deep in the stack for reporting
back at a higher level).

With this patch, we emit:

../../src/test.cc: In function ‘std::size_t f(const 
std::vector >&)’:
../../src/test.cc:4:23: remark: couldn't vectorize loop
  for (auto const & w: v)
   ^
In file included from ../x86_64-pc-linux-gnu/libstdc++-v3/include/vector:64,
 from ../../src/test.cc:1:
../x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:806:50:
note: relevant stmt not supported: ‘_15 = _14 /[ex] 4;’
   { return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }
  ^~~~

which reports both the location of the loop and the statement that's
problematic (if I'm reading it right, the pointer arithmetic leads to a
division by 4, and presumably we're not able to handle that).

(not bootstrapped or anything, just experimenting at this stage)

Thoughts?

gcc/ChangeLog:
* Makefile.in (OBJS): Add opt-problem.o.
* opt-problem.cc: New file.
* opt-problem.h: New file.
* tree-vect-stmts.c (vect_analyze_stmt): Replace "not vectorized"
dumps with calls to push_ve

Re: [PATCH] Let env var CLICOLOR_FORCE set -fdiagnostics-color=always.

[Adam Borowski]

On Fri, Jun 22, 2018 at 02:08:27PM -0600, Jeff Law wrote:
> On 06/12/2018 04:46 PM, Adam Borowski wrote:
> > Here's a patch for Bugzilla 80271, to add support for env CLICOLOR_FORCE.
> > 
> > Automated build environments -- and even some which you run by hand --
> > redirect the output somewhere to save a log, even if they tee it to the
> > terminal anyway.  This kills all colored highlights for diagnostics.
> > Those highlights are really nice for a human -- unlike the old days when
> > a single-threaded build always had the failure at the end, modern setups
> > tend to spew pages of stuff after the real reason your build failed.  As
> > human vision evolved to be extremely good at noticing a fleck of color,
> > it's easy to spot that bit of red even when scrolling very fast.
> > 
> > Besides terminals, you can read colored logs via "less -R", ansi2html, etc.
> > 
> > For such piped setups, gcc has -fdiagnostics-color=always.  Alas, while this
> > flag is easy to set by someone writing a given piece of software, there's
> > no reasonable way to set it globally in the build environment.
> > 
> > Thus, in #80271 Jan Niklas Hasse requested, and I concur, to be able to
> > set the same via an env var.  This flag doesn't affect code produced by gcc
> > in any way, thus it's reasonable to set it via env.  There's already
> > GCC_COLORS letting you customize colors used, you just can't tell it to
> > ignore stderr not being a terminal.

> We _strongly_ discourage the use of environment variables to control the
> compiler.  Really the way to go here is to use the
> -fdiagnostics-color=always and deal with the difficulties of flag injection.

As discussed in #80271, color vs b&w diagnostics don't change any produced
files in any way.  The presentation of these diagnostics is already affected
by things not included in -f args (namely, isatty(2)).

And, this very feature is already controlled by another env variable, ie,
GCC_COLORS.

Another reason is that, certain build systems store -f flags and consider a
build to be different if the flags differ.  This can cause spurious
recompiles just because one invocation was redirected but another was not,
something likely to happen in a debugging session.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones.
⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes
⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious.  It's also interesting to see OSes
⠈⠳⣄ go back and forth wrt their intended target.

Re: [PATCH] Let env var CLICOLOR_FORCE set -fdiagnostics-color=always.

[Jeff Law]

On 06/12/2018 04:46 PM, Adam Borowski wrote:
> Hi!
> Here's a patch for Bugzilla 80271, to add support for env CLICOLOR_FORCE.
> 
> Automated build environments -- and even some which you run by hand --
> redirect the output somewhere to save a log, even if they tee it to the
> terminal anyway.  This kills all colored highlights for diagnostics.
> Those highlights are really nice for a human -- unlike the old days when
> a single-threaded build always had the failure at the end, modern setups
> tend to spew pages of stuff after the real reason your build failed.  As
> human vision evolved to be extremely good at noticing a fleck of color,
> it's easy to spot that bit of red even when scrolling very fast.
> 
> Besides terminals, you can read colored logs via "less -R", ansi2html, etc.
> 
> For such piped setups, gcc has -fdiagnostics-color=always.  Alas, while this
> flag is easy to set by someone writing a given piece of software, there's
> no reasonable way to set it globally in the build environment.
> 
> Thus, in #80271 Jan Niklas Hasse requested, and I concur, to be able to
> set the same via an env var.  This flag doesn't affect code produced by gcc
> in any way, thus it's reasonable to set it via env.  There's already
> GCC_COLORS letting you customize colors used, you just can't tell it to
> ignore stderr not being a terminal.
> 
> 
> Please forgive my lack of knowledge wrt proper ways of submitting patches to
> gcc (ie, when biting please point to piece of TFM I failed to R).  In
> particular, I'm not sure how to run the testsuite: it produces a lot of
> fails even without my patch, and I don't know what is your way to spot new
> failures.  The testsuite could be interesting as gcc in a lot of places sets
> and unsets CLICOLOR_FORCE despite not supporting it itself (yet a number of
> other tools do).  Weirdly, in every case you unset it in the very next line
> after enabling it.
> 
> I've submitted an equivalent of this patch to llvm/clang as well.
We _strongly_ discourage the use of environment variables to control the
compiler.  Really the way to go here is to use the
-fdiagnostics-color=always and deal with the difficulties of flag injection.

Jeff

Re: [PATCH 02/11] Initial TI PRU libgcc port

[Dimitar Dimitrov]

On петък, 22 юни 2018 г. 10:55:29 EEST Jeff Law wrote:
> On 06/13/2018 12:57 PM, Dimitar Dimitrov wrote:
> > The floating point support has been borrowed from C6X libgcc port
> > to help with TI PRU toolchain ABI compatibility.
> > 
> > libgcc/ChangeLog:
> > 
> > 2018-06-13  Dimitar Dimitrov  
> > 
> > * config.host: Add PRU target.
> > * config/pru/asri.c: New file.
> > * config/pru/eqd.c: New file.
> > * config/pru/eqf.c: New file.
> > * config/pru/ged.c: New file.
> > * config/pru/gef.c: New file.
> > * config/pru/gtd.c: New file.
> > * config/pru/gtf.c: New file.
> > * config/pru/led.c: New file.
> > * config/pru/lef.c: New file.
> > * config/pru/lib2bitcountHI.c: New file.
> > * config/pru/lib2divHI.c: New file.
> > * config/pru/lib2divQI.c: New file.
> > * config/pru/lib2divSI.c: New file.
> > * config/pru/libgcc-eabi.ver: New file.
> > * config/pru/ltd.c: New file.
> > * config/pru/ltf.c: New file.
> > * config/pru/mpyll.S: New file.
> > * config/pru/pru-abi.h: New file.
> > * config/pru/pru-asm.h: New file.
> > * config/pru/pru-divmod.h: New file.
> > * config/pru/sfp-machine.h: New file.
> > * config/pru/t-pru: New file.
> 
> I don't see anything particularly concerning here.  It looks like the
> floating point stuff is a direct copy from the c6x port.  I'm going to
> assume the assembly code you've written in the various files is correct.
>  I'm also assuming we're trying to be compatible with another toolchain
> or published ABI, hence the exposure of the new symbols for low level
> operations.
> 
> So I'll this too.  Obviously it needs to wait for the main port patch to
> be reviewed as well.
That is correct, my main goal has been to be ABI compatible with the 
proprietary TI PRU toolchain. Luckily, TI folks reused c6x floating point ABI 
for PRU.

Regards,
Dimitar

Re: [PATCH], PowerPC long double transition patches, v2, Patch #6 (fix long double tests for -mno-float128)

[Michael Meissner]

On Thu, Jun 21, 2018 at 06:12:52PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:49:41AM -0400, Michael Meissner wrote:
> > These patches fix the tests in the testsuite that check whether 
> > -mno-float128
> > works properly.  In these cases, I explicitly run them with long double 
> > being
> > set to IBM extended double.
> 
> So what happened without this patch?

To give context, it was this patch you were asking about:

2018-06-20  Michael Meissner  

* gcc.target/powerpc/float128-3.c: Change tests that test for
errors in enabling/disable IEEE 128-bit floating point use the
-mabi=ibmlongdouble to force long double to be IBM extended.
* gcc.target/powerpc/float128-5.c: Likewise.
* gcc.target/powerpc/float128-mix.c: Likewise.

float128-3.c and float128-5.c both issues no error (because they both test if
__FLOAT128__ defined even if you use the -mno-float128 option), instead of the
two errors that the test checks for.

float128-mix.c also issues no error because with -mabi=ieeelongdouble, it is
legal to allow __float128 and long double to be combined.

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

Re: [C++ Patch] Use declspecs->locations more in grokdeclarator (and grokvardecl)

[Jason Merrill]

OK.

On Fri, Jun 22, 2018 at 1:18 PM, Paolo Carlini  wrote:
> Hi,
>
> this rather straightforward patch simply uses available location information
> - in the form of declspecs->locations - in diagnostic messages. In order to
> do that, the information is also propagated to bad_specifiers and
> mark_inline_variable. Tested x86_64-linux.
>
> Thanks, Paolo.
>
> ///
>

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

[Jeff Law]

On 06/13/2018 12:57 PM, Dimitar Dimitrov wrote:
> ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * configure: Regenerate.
>   * configure.ac: Add PRU target.
> 
> gcc/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * config/pru/pru-ldst-multiple.md: Generate using pru-ldst-multiple.ml.
>   * common/config/pru/pru-common.c: New file.
>   * config.gcc: Add PRU target.
>   * config/pru/alu-zext.md: New file.
>   * config/pru/constraints.md: New file.
>   * config/pru/predicates.md: New file.
>   * config/pru/pru-ldst-multiple.ml: New file.
>   * config/pru/pru-opts.h: New file.
>   * config/pru/pru-passes.c: New file.
>   * config/pru/pru-pragma.c: New file.
>   * config/pru/pru-protos.h: New file.
>   * config/pru/pru.c: New file.
>   * config/pru/pru.h: New file.
>   * config/pru/pru.md: New file.
>   * config/pru/pru.opt: New file.
>   * config/pru/t-pru: New file.
>   * doc/extend.texi: Document PRU pragmas.
>   * doc/invoke.texi: Document PRU-specific options.
>   * doc/md.texi: Document PRU asm constraints.
Joseph has already made some notes about diagnostics.  Those will need
to be addressed.

A couple global comments on style issues.

First, each function should have a comment describing what it does,
ideally describing the input parameters and output value.

Second the function definition should always look like

[static] 
name (type1 arg1, type2 arg2)
{
  body
}

In some cases you've joined the linkage/type line with the function's
name.  Can you please review pru.c in particular to fix these issues.

There's been another round of rtx -> rtx_insn * conversions done in the
generic parts of the compiler.  There's a reasonable chance they will
require trivial updates to the pru port.   When the time comes for
integration the trivial changes to cope with those conversions are
pre-approved and will not require a separate review cycle.

I've already asked about your copyright assignment status.  So you know,
we can't go forward with any nontrivial contributions until the
assignment is in place.

I'm going to assume that you plan to maintain this port.  Ideally you'll
have it using an auto-builder and posting tests gcc-testresults :-0

I'm assuming that since you're patching LRA in a different patch that
you're using LRA rather than reload :-)  That also implies that you're
not using the deprecated cc0 bits, which is good.


> 
> diff --git a/configure.ac b/configure.ac
> index 28155a0e593..684a7f58515 100644
> --- a/configure.ac
> +++ b/configure.ac
[ ... ]
So it looks like you're supporting libgloss/newlib.  Does it work with
the current libgloss/newlib trunk?  I've had troubles over the last few
months with 16 bit targets.


> diff --git a/gcc/common/config/pru/pru-common.c 
> b/gcc/common/config/pru/pru-common.c
> new file mode 100644
> index 000..e87d70ce9ca
> --- /dev/null
> +++ b/gcc/common/config/pru/pru-common.c
[ ... ]
> @@ -0,0 +1,36 @@
> +
> +#undef TARGET_EXCEPT_UNWIND_INFO
> +#define TARGET_EXCEPT_UNWIND_INFO sjlj_except_unwind_info

SJLJ exceptions?  Is there some reason you're not using dwarf2 unwind
info?  It may mean adding some notes in the prologue generation code,
but otherwise I'd expect it to "just work".

> +
> +struct gcc_targetm_common targetm_common = TARGETM_COMMON_INITIALIZER;
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 8b2fd908c38..d1cddb86c36 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
[ ... ]
> +pru*-*-*)
> + tm_file="dbxelf.h elfos.h newlib-stdint.h ${tm_file}"
> + tmake_file="${tmake_file} pru/t-pru"
> + extra_objs="pru-pragma.o pru-passes.o"
> + use_gcc_stdint=wrap
Can you try to avoid dbxelf.h?  We're trying to get away from embedded
stabs.  I'd like to avoid creating new ports that reference this stuff.



> diff --git a/gcc/config/pru/pru-ldst-multiple.ml 
> b/gcc/config/pru/pru-ldst-multiple.ml
> new file mode 100644
> index 000..961a9fb33e6
> --- /dev/null
> +++ b/gcc/config/pru/pru-ldst-multiple.ml
> @@ -0,0 +1,144 @@
> +(* Auto-generate PRU load/store-multiple patterns
> +   Copyright (C) 2014-2018 Free Software Foundation, Inc.
> +   Based on arm-ldmstm.ml
[ ... ]
So please make sure to include the generated file in the repository.  We
don't want to force developers to have to have ocaml installed to build
the port.  I believe this is consistent with how the ARM port works.

> diff --git a/gcc/config/pru/pru-opts.h b/gcc/config/pru/pru-opts.h
> new file mode 100644
> index 000..1c1514cb2a3
> --- /dev/null
> +++ b/gcc/config/pru/pru-opts.h
[ ... ]
> +
> +/* Definitions for option handling for PRU.  */
> +
> +#ifndef GCC_PRU_OPTS_H
> +#define GCC_PRU_OPTS_H
> +
> +/* ABI variant for code generation.  */
> +enum pru_abi {
> +PRU_ABI_GNU,
> +PRU_ABI_TI
Is there really any value in having two ABIs?  If there's another
toolchain out there it'd be best if we were just compatible with that
rather than defining

Re: [PATCH 11/11] Increase MAX_MAX_OPERANDS limit

[Jakub Jelinek]

On Fri, Jun 22, 2018 at 11:33:06AM -0600, Jeff Law wrote:
> On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote:
> > The PRU load/store instructions can access memory with byte
> > granularity for all 30 of its 32-bit GP registers. Examples:
> > 
> ># Load 17 bytes from address r0[0] into registers r10.b1-r14.b2
> >lbbo r10.b1, r0, 0, 17
> > 
> ># Load 100 bytes from address r28[0] into registers r0-r25
> >lbbo r0.b0, r28, 0, 100
> > 
> > The load/store multiple patterns declare all subsequent registers
> > as distinct operands. Hence the need to increase the limit.

Can't you have a look on how other targets, e.g. arm, aarch64, s390x
etc. handle load/store multiple patterns, e.g. with match_parallel or
match_par_dup?
The instructions then don't have dozens of operands, and the predicate
is just supposed to check everything is the way it should be.

Jakub

Re: [PATCH, rs6000] Backport Fix implementation of vec_packsu (vector unsigned long long, vector unsigned long long) built-in function

[Segher Boessenkool]

On Fri, Jun 22, 2018 at 08:30:12AM -0500, Kelvin Nilsen wrote:
> This has been committed to trunk.
> 
> Is this ok to backport to gcc6, gcc7, and gcc8?

Yes, but wait a few days please.  Thanks!


Segher

Re: [PATCH 11/11] Increase MAX_MAX_OPERANDS limit

[Jeff Law]

On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote:
> The PRU load/store instructions can access memory with byte
> granularity for all 30 of its 32-bit GP registers. Examples:
> 
># Load 17 bytes from address r0[0] into registers r10.b1-r14.b2
>lbbo r10.b1, r0, 0, 17
> 
># Load 100 bytes from address r28[0] into registers r0-r25
>lbbo r0.b0, r28, 0, 100
> 
> The load/store multiple patterns declare all subsequent registers
> as distinct operands. Hence the need to increase the limit.
> 
> Increase the value to just 60 in order to avoid modifying regrename.c.
> 
> 2018-06-13  Dimitar Dimitrov  
> 
> * genoutput.c (MAX_MAX_OPERANDS): Increase to 60.
Not ideal.  I'm not aware of any other port which puts each register
into a class then has an alternative for each class in its patterns.
I'm not even really sure what that's buying you WRT the feature your
noted above.

I'll also note that there a MAX_OPERANDS for gensupport.c which you
probably should investigate.

It's probably not a huge deal, but I'm going to defer judgment on this
right now.

jeff

[committed] Add another testcase for PR c++/85662

[Jakub Jelinek]

Hi!

On the 7.x branch, without the fix offsetof2.C testcase passes at -O0,
which is how it is compiled in the testsuite, and only fails at -O2.

Thus, this patch adds a copy of that testcase to be compiled for -O2, so
that it is tested too, and I'll backport then both the original fix and this
new addition.

Tested on x86_64-linux, committed to trunk and 8.2.

2018-06-22  Jakub Jelinek  

PR c++/85662
* g++.dg/ext/offsetof3.C: New test.

--- gcc/testsuite/g++.dg/ext/offsetof3.C.jj 2018-06-22 19:20:34.530606396 
+0200
+++ gcc/testsuite/g++.dg/ext/offsetof3.C2018-06-22 19:20:53.313622055 
+0200
@@ -0,0 +1,5 @@
+// PR c++/85662
+// { dg-do compile { target c++11 } }
+// { dg-options "-O2" }
+
+#include "offsetof2.C"

Jakub

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

[Joseph Myers]

On Thu, 21 Jun 2018, Eric Gallager wrote:

> On 6/21/18, Jeff Law  wrote:
> > On 06/12/2018 11:21 AM, Joseph Myers wrote:
> >> On Tue, 12 Jun 2018, Martin Sebor wrote:
> >>
> >>> The proposal to enable -Wstrict-prototypes discussed below
> >>> was considered too late for GCC 8.  I'd like to revive it
> >>> now for GCC 9.
> >>>
> >>>   https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00935.html
> >>
> >> My point from that discussion stands that () for no arguments should be
> >> considered separately from warning for all the other cases.
> > There's a lot of legacy code out there...  What's the proposal for
> > handling the no argument () case?  Are we thinking multiple levels?  And
> > if so what's the default?
> 
> -Wstrict-prototypes and -Wstricter-prototypes for the prototypes case?
> And then split
> -Wold-style-definition into -Wold-style-definition and
> -Wc++-style-definition for the equivalent use of () in function
> definitions?

I think the existing options, when explicitly used, should keep warning 
for all the cases they currently warn for, including (), even if you also 
have new warning options available that correspond to a subset of the 
existing options.

It's the possible enabled-by-default warnings that I think should be a 
subset, as I don't think using () for no-argument functions is such an 
obsolescent practice as using old-style definitions, or () declarations, 
for functions with arguments (especially since () for no-argument 
functions is perfectly idiomatic in C++, and if C obsoletes non-prototype 
functions I'd expect it to end up with () having the same meaning as in 
C++, rather than being disallowed).

The vast bulk of the places where that previous patch changes testcases 
are for (), which would not need changing under my proposal.

(No doubt there *is* a lot of legacy code that uses old-style definitions 
together with function prototypes in separate declarations; I eliminated 
old-style definitions from glibc only in 2015.  Hopefully code with 
old-style definitions and no prototype declarations is rarer.)

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

[C++ Patch] Use declspecs->locations more in grokdeclarator (and grokvardecl)

[Paolo Carlini]

Hi,

this rather straightforward patch simply uses available location 
information - in the form of declspecs->locations - in diagnostic 
messages. In order to do that, the information is also propagated to 
bad_specifiers and mark_inline_variable. Tested x86_64-linux.


Thanks, Paolo.

///

/cp
2018-06-22  Paolo Carlini  

* decl.c (bad_specifiers): Add const location_t* parameter and
use locations in error messages about 'inline' and 'virtual'.
(mark_inline_variable): Add location_t parameter and use it in
error_at and pedwarn messages.
(grokdeclarator): Use declspecs->locations[ds_constexpr],
declspecs->locations[ds_concept], declspecs->locations[ds_virtual],
declspecs->locations[ds_inline] in many error messages; adjust
bad_specifiers and mark_inline_variable calls.
(grokvardecl): Use declspecs->locations[ds_concept] in error message.

/testsuite
2018-06-22  Paolo Carlini  

* g++.dg/concepts/locations1.C: New.
* g++.dg/cpp0x/locations1.C: Likewise.
* g++.dg/cpp1z/inline-var2.C: Test locations too.
* g++.dg/cpp1z/inline-var3.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 261891)
+++ cp/decl.c   (working copy)
@@ -8406,13 +8406,15 @@ bad_specifiers (tree object,
int quals,
int inlinep,
int friendp,
-   int raises)
+   int raises,
+   const location_t* locations)
 {
   switch (type)
 {
   case BSP_VAR:
if (virtualp)
- error ("%qD declared as a % variable", object);
+ error_at (locations[ds_virtual],
+   "%qD declared as a % variable", object);
if (quals)
  error ("% and % function specifiers on "
 "%qD invalid in variable declaration", object);
@@ -8419,9 +8421,11 @@ bad_specifiers (tree object,
break;
   case BSP_PARM:
if (virtualp)
- error ("%qD declared as a % parameter", object);
+ error_at (locations[ds_virtual],
+   "%qD declared as a % parameter", object);
if (inlinep)
- error ("%qD declared as an % parameter", object);
+ error_at (locations[ds_inline],
+   "%qD declared as an % parameter", object);
if (quals)
  error ("% and % function specifiers on "
 "%qD invalid in parameter declaration", object);
@@ -8428,9 +8432,11 @@ bad_specifiers (tree object,
break;
   case BSP_TYPE:
if (virtualp)
- error ("%qD declared as a % type", object);
+ error_at (locations[ds_virtual],
+   "%qD declared as a % type", object);
if (inlinep)
- error ("%qD declared as an % type", object);
+ error_at (locations[ds_inline],
+   "%qD declared as an % type", object);
if (quals)
  error ("% and % function specifiers on "
 "%qD invalid in type declaration", object);
@@ -8437,9 +8443,11 @@ bad_specifiers (tree object,
break;
   case BSP_FIELD:
if (virtualp)
- error ("%qD declared as a % field", object);
+ error_at (locations[ds_virtual],
+   "%qD declared as a % field", object);
if (inlinep)
- error ("%qD declared as an % field", object);
+ error_at (locations[ds_inline],
+   "%qD declared as an % field", object);
if (quals)
  error ("% and % function specifiers on "
 "%qD invalid in field declaration", object);
@@ -9254,7 +9262,8 @@ grokvardecl (tree type,
 {
   if (!processing_template_decl)
 {
-  error ("a non-template variable cannot be %");
+  error_at (declspecs->locations[ds_concept],
+   "a non-template variable cannot be %");
   return NULL_TREE;
 }
   else
@@ -9920,18 +9929,17 @@ check_var_type (tree identifier, tree type)
 /* Handle declaring DECL as an inline variable.  */
 
 static void
-mark_inline_variable (tree decl)
+mark_inline_variable (tree decl, location_t loc)
 {
   bool inlinep = true;
   if (! toplevel_bindings_p ())
 {
-  error ("% specifier invalid for variable "
-"%qD declared at block scope", decl);
+  error_at (loc, "% specifier invalid for variable "
+   "%qD declared at block scope", decl);
   inlinep = false;
 }
   else if (cxx_dialect < cxx17)
-pedwarn (DECL_SOURCE_LOCATION (decl), 0,
-"inline variables are only available "
+pedwarn (loc, 0, "inline variables are only available "
 "with -std=c++17 or -std=gnu++17");
   if (inlinep)
 {
@@ -10375,13 +10383,15 @@ grokdeclarator (const cp_declarator *declarator,
 
   if (concept_p && typedef_p)
 {
-  error ("% cannot appear in a typedef declaration");
+  error_at (decl

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

[Joseph Myers]

On Thu, 21 Jun 2018, Jeff Law wrote:

> I think all this implies that the setting of -fno-math-errno by default
> really depends on the math library in use since it's the library that
> has to arrange for either errno to get set or for an exception to be raised.

If the library does not set errno, clearly -fno-math-errno by default is 
appropriate (and is the default on Darwin).

If the library does set errno, but the user doesn't care about the errno 
setting, -fno-math-errno is useful to that user; the question here is 
whether it's also an appropriate default to assume the user doesn't care 
about errno setting and so require them to pass -fmath-errno if they do.  
There are separate cases here for if the library does or does not set 
exceptions (the latter including most soft-float cases).

Then there are various built-in functions in GCC that use 
ATTR_MATHFN_FPROUNDING when they should use ATTR_MATHFN_FPROUNDING_ERRNO - 
because there are legitimate error cases for those functions for which 
errno setting is appropriate.  sin, cos, tan (domain errors for infinite 
arguments) are obvious examples.  (We have bug 64101 for erf, which is a 
case where the glibc model of when to set errno for underflow does *not* 
ever involve setting errno for this function, but some other 
implementations might have other models for when setting errno is 
appropriate.)

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

Re: [PATCH 02/11] Initial TI PRU libgcc port

[Jeff Law]

On 06/13/2018 12:57 PM, Dimitar Dimitrov wrote:
> The floating point support has been borrowed from C6X libgcc port
> to help with TI PRU toolchain ABI compatibility.
> 
> libgcc/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * config.host: Add PRU target.
>   * config/pru/asri.c: New file.
>   * config/pru/eqd.c: New file.
>   * config/pru/eqf.c: New file.
>   * config/pru/ged.c: New file.
>   * config/pru/gef.c: New file.
>   * config/pru/gtd.c: New file.
>   * config/pru/gtf.c: New file.
>   * config/pru/led.c: New file.
>   * config/pru/lef.c: New file.
>   * config/pru/lib2bitcountHI.c: New file.
>   * config/pru/lib2divHI.c: New file.
>   * config/pru/lib2divQI.c: New file.
>   * config/pru/lib2divSI.c: New file.
>   * config/pru/libgcc-eabi.ver: New file.
>   * config/pru/ltd.c: New file.
>   * config/pru/ltf.c: New file.
>   * config/pru/mpyll.S: New file.
>   * config/pru/pru-abi.h: New file.
>   * config/pru/pru-asm.h: New file.
>   * config/pru/pru-divmod.h: New file.
>   * config/pru/sfp-machine.h: New file.
>   * config/pru/t-pru: New file.
I don't see anything particularly concerning here.  It looks like the
floating point stuff is a direct copy from the c6x port.  I'm going to
assume the assembly code you've written in the various files is correct.
 I'm also assuming we're trying to be compatible with another toolchain
or published ABI, hence the exposure of the new symbols for low level
operations.

So I'll this too.  Obviously it needs to wait for the main port patch to
be reviewed as well.

jeff

Re: [PATCH 09/11] testsuite: Mark that PRU uses all function pointer bits

[Jeff Law]

On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote:
> gcc/testsuite/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * g++.old-deja/g++.abi/ptrmem.C: Add PRU to list.
OK once the rest of the kit is approved.

jeff

Re: [PATCH 08/11] testsuite: Mark that PRU has one-cycle jumps

[Jeff Law]

On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote:
> gcc/testsuite/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * gcc.dg/tree-ssa/20040204-1.c: XFAIL on pru.
>   * gcc.dg/tree-ssa/reassoc-33.c: Ditto.
>   * gcc.dg/tree-ssa/reassoc-34.c: Ditto.
>   * gcc.dg/tree-ssa/reassoc-35.c: Ditto.
>   * gcc.dg/tree-ssa/reassoc-36.c: Ditto.
>   * gcc.dg/tree-ssa/ssa-thread-14.c: Ditto.
OK once the rest of the kit is approved.

jeff

Re: [PATCH 07/11] testsuite: Define PRU stack usage

[Jeff Law]

On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote:
> gcc/testsuite/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * gcc.dg/stack-usage-1.c: Define PRU stack usage.
This is OK once the rest of the kit is approved.

Jeff

Re: [PATCH 06/11] testsuite: Remove PRU from test cases requiring hosted environment

[Jeff Law]

On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote:
> gcc/testsuite/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * gcc.c-torture/execute/20101011-1.c: Define DO_TEST to 0 for PRU.
>   * gcc.dg/20020312-2.c: No PIC register for PRU.
This is OK once the rest of the kit is approved.

jeff

Re: [PATCH 05/11] testsuite: Add check for unsupported TI ABI PRU features to testsuite

[Jeff Law]

On 06/13/2018 12:57 PM, Dimitar Dimitrov wrote:
> Not all C language features are supported when -mabi=ti option is
> used for PRU target.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * lib/gcc-dg.exp: Filter unsupported features in PRU's TI ABI mode.
>   * lib/target-utils.exp: Ditto.
I think a level of indirection would be better here.  ie, define a new
routines that indicate if the target has function pointers and large
return values and call that routine from within gcc-dg-prune and
*_check_supported_p.

Those routines would obviously return true for pru :-)

With that change this will be OK once the rest of the kit is approved.

jeff

Re: [PATCH 04/11] testsuite: Add check for overflowed IMEM region to testsuite

[Jeff Law]

On 06/13/2018 12:57 PM, Dimitar Dimitrov wrote:
> PRU architecture supports maximum 256k program memory (IMEM). Some GCC
> test cases manage to produce executables bigger than that.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * lib/gcc-dg.exp: Bail on region overflow for tiny targets.
>   * lib/target-utils.exp: Ditto.
>   * lib/target-supports.exp: Declare PRU target as tiny.
This is fine once the rest of the port is approved.

jeff

Re: [PATCH 03/11] testsuite: Add PRU tests

[Jeff Law]

On 06/13/2018 12:57 PM, Dimitar Dimitrov wrote:
> gcc/testsuite/ChangeLog:
> 
> 2018-06-13  Dimitar Dimitrov  
> 
>   * gcc.target/pru/abi-arg-struct.c: New test.
>   * gcc.target/pru/ashiftrt.c: New test.
>   * gcc.target/pru/builtins-1.c: New test.
>   * gcc.target/pru/builtins-error.c: New test.
>   * gcc.target/pru/clearbit.c: New test.
>   * gcc.target/pru/loop-asm.c: New test.
>   * gcc.target/pru/loop-dowhile.c: New test.
>   * gcc.target/pru/loop-hi-1.c: New test.
>   * gcc.target/pru/loop-hi-2.c: New test.
>   * gcc.target/pru/loop-qi-1.c: New test.
>   * gcc.target/pru/loop-qi-2.c: New test.
>   * gcc.target/pru/loop-short-1.c: New test.
>   * gcc.target/pru/loop-short-2.c: New test.
>   * gcc.target/pru/loop-si-1.c: New test.
>   * gcc.target/pru/loop-si-2.c: New test.
>   * gcc.target/pru/loop-u8_pcrel_overflow.c: New test.
>   * gcc.target/pru/loop-ubyte-1.c: New test.
>   * gcc.target/pru/loop-ubyte-2.c: New test.
>   * gcc.target/pru/mabi-ti-1.c: New test.
>   * gcc.target/pru/mabi-ti-2.c: New test.
>   * gcc.target/pru/mabi-ti-3.c: New test.
>   * gcc.target/pru/mabi-ti-4.c: New test.
>   * gcc.target/pru/mabi-ti-5.c: New test.
>   * gcc.target/pru/mabi-ti-6.c: New test.
>   * gcc.target/pru/mabi-ti-7.c: New test.
>   * gcc.target/pru/pr64366.c: New test.
>   * gcc.target/pru/pragma-ctable_entry.c: New test.
>   * gcc.target/pru/pru.exp: New file.
>   * gcc.target/pru/qbbc-1.c: New test.
>   * gcc.target/pru/qbbc-2.c: New test.
>   * gcc.target/pru/qbbc-3.c: New test.
>   * gcc.target/pru/qbbs-1.c: New test.
>   * gcc.target/pru/qbbs-2.c: New test.
>   * gcc.target/pru/setbit.c: New test.
>   * gcc.target/pru/zero_extend-and-hisi.c: New test.
>   * gcc.target/pru/zero_extend-and-qihi.c: New test.
>   * gcc.target/pru/zero_extend-and-qisi.c: New test.
>   * gcc.target/pru/zero_extend-hisi.c: New test.
>   * gcc.target/pru/zero_extend-qihi.c: New test.
>   * gcc.target/pru/zero_extend-qisi.c: New test.
>   * lib/target-supports.exp: Add PRU to feature filters.
This is fine once the main part of the port is approved.

jeff

Re: [PATCH 10/11] Fix LRA to handle multi-word eliminable registers

[Jeff Law]

On 06/21/2018 10:01 PM, Dimitar Dimitrov wrote:
> On четвъртък, 21 юни 2018 г. 17:03:55 EEST Jeff Law wrote:
>> On 06/21/2018 11:44 AM, Vladimir Makarov wrote:
>>> On 06/13/2018 02:58 PM, Dimitar Dimitrov wrote:
 From: Dimitar Dimitrov 

 For some targets, Pmode != UNITS_PER_WORD. Take this into account
 when marking hard registers as being used.

 I tested C and C++ testsuits for x86_64 with and without this
 patch. There was no regression, i.e. gcc.sum and g++.sum matched
 exactly.

 gcc/ChangeLog:

 2018-06-13  Dimitar Dimitrov  

 * lra-eliminations.c (set_ptr_hard_reg_bits): New function.
 (update_reg_eliminate): Mark all spanning hw registers.

 gcc/testsuite/ChangeLog:

 2018-06-13  Dimitar Dimitrov  

 * gcc.target/pru/lra-framepointer-fragmentation-1.c: New test.
 * gcc.target/pru/lra-framepointer-fragmentation-2.c: New test.

 Cc: Vladimir Makarov 
 Cc: Peter Bergner 
 Cc: Kenneth Zadeck 
 Cc: Seongbae Park 
 Signed-off-by: Dimitar Dimitrov 
 ---
   gcc/lra-eliminations.c | 14 -
   .../pru/lra-framepointer-fragmentation-1.c | 33 
   .../pru/lra-framepointer-fragmentation-2.c | 61
 ++
   3 files changed, 106 insertions(+), 2 deletions(-)
   create mode 100644
 gcc/testsuite/gcc.target/pru/lra-framepointer-fragmentation-1.c
   create mode 100644
 gcc/testsuite/gcc.target/pru/lra-framepointer-fragmentation-2.c

 diff --git a/gcc/lra-eliminations.c b/gcc/lra-eliminations.c
 index 21d8d5f8018..566cc2c8248 100644
 --- a/gcc/lra-eliminations.c
 +++ b/gcc/lra-eliminations.c
 @@ -1180,6 +1180,16 @@ spill_pseudos (HARD_REG_SET set)
 bitmap_clear (&to_process);
   }
   +static void set_ptr_hard_reg_bits (HARD_REG_SET *hard_reg_set, int r)
 +{
 +  int w;
 +
 +  for (w = 0; w < GET_MODE_SIZE (Pmode); w += UNITS_PER_WORD, r++)
 +{
 +  SET_HARD_REG_BIT (*hard_reg_set, r);
 +}
 +}
 +
>>>
>>> The patch itself is ok but for uniformity I'd use
>>>
>>> for (int i = hard_regno_nregs (r, Pmode) - 1; i >= 0; i--)
>>>   SET_HARD_REG_BIT (*hard_reg_set, r + i);
>>
>> I'm a bit surprised we don't already have a utility function to do this.
>> Hmmm
>>
>> add_to_hard_reg_set (hard_reg_set, Pmode, r)
>>
>> So instead LRA ought to be using that function in the places where calls
>> to set_ptr_hard_reg_bits were introduced.
>>
>> Dimitar, can you verify that change works?
> 
> Thank you. I'll test it and will update the patch.
And go ahead and either break out the two new tests.  I suspect we'll
want to install the LRA patch immediately since it's an independent bugfix.


> 
> 
> The SET_HARD_REG_BIT call in check_pseudos_live_through_calls also seems 
> suspicous to me. I'll try to come up with a regression test case to justify 
> its upgrade to add_to_hard_reg_set().
If you can construct a test, great, but from my reading it's clearly
wrong as well and we ought to fix it too.

Jeff

ps.  Do you have a copyright assignment on file with the FSF for GCC work?

Re: [patch] improve entry/exit instrumentation wrt trampolines

[Olivier Hainque]

Hi Jeff,

> On 22 Jun 2018, at 18:13, Jeff Law  wrote:
> 
>>> * gimplify.c (gimplify_function_tree): Prevent creation
>>> of a trampoline for the address of the current function
>>> passed to entry/exit instrumentation hooks.

> I was a little concerned about the TREE_NO_TRAMPOLINE bit, but that's
> only applied to the result of the build_fold_addr_expr, not to the
> actual decl itself AFAICT.

Yes, exactly.

> So, OK.

Great :) Thanks for the super fast review!

Regards,

Olivier

[patch] refine getenv_spec_function fallback value for undefined variable

[Olivier Hainque]

Hello,

getenv_spec_function features code to return a fake
value for an undefined variable when we know that we
shouldn't complain about the variable being undefined
and that the variable value doesn't matter.

This code is there to prevent errors about undefined
variables referenced in specs when we're processing for
mere "--version" on the command line, for example.

The current code sets the value to the variable name.

We have a local configuration (for VxWorks, patch coming) where
%:getenv is used at the beginning of a STARTFILE_PREFIX_SPEC,
like:

  #define STARTFILE_PREFIX_SPEC "%:getenv(VSB_DIR /usr/lib/common)"

Now, for this spec we have a check that the value is an
absolute path, and gcc --version for this configuration then
complains with a message like:

   i586-wrs-vxworks7-gcc: fatal error: system path 'VSB_DIR/usr/lib/common' is 
not absolute

This patch fixes this glitch by simply prepending a '/' to
the fake value returned by getenv_spec_function for acceptable
undefined variables.

We have been using this in-house for months with gcc-7 on a wide
range of targets.

Bootstrapped and regression tested with mainline on x86_64-linux.

Ok to commit ?

Thanks in advance,

With Kind Regards,

Olivier

2018-06-22  Olivier Hainque  

* gcc.c (getenv_spec_function): Prepend '/' to value for allowed
undefined variables.



getenv-absolute-path.diff
Description: Binary data

Re: [PATCH] Fix clustering algorithm in switch expansion.

[Jeff Law]

On 06/22/2018 03:23 AM, Martin Liška wrote:
> Hi.
> 
> For correctness of clustering algorithm:
> https://www.semanticscholar.org/paper/Short-Communication%3A-Correction-to-'Producing-Good-Kannan-Proebsting/311091fb9fb9d38f7b76e768a603c02acc799fe0
> 
> one needs to allow single case clusters as possible. Note that we never
> end with a jump table, or a bit test handling just a single case.
> I also add tests for that catch that.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Ready to be installed?
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-06-21  Martin Liska  
> 
>   * tree-switch-conversion.c (jump_table_cluster::find_jump_tables):
> Add new checking assert to catch invalid state.
>   (jump_table_cluster::can_be_handled): Handle single case
> clusters.
>   (jump_table_cluster::is_beneficial): Bail out for such case.
>   (bit_test_cluster::find_bit_tests):
> Add new checking assert to catch invalid state.
>   (bit_test_cluster::can_be_handled): Handle single case
> clusters.
>   (bit_test_cluster::is_beneficial): Bail out for such case.
>   (switch_decision_tree::analyze_switch_statement):
> Fix comment.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-06-21  Martin Liska  
> 
>   * gcc.dg/tree-ssa/switch-1.c: New test.
OK.
jeff

Re: [PATCH 1/3] Introduce auto_string_vec class.

[Jeff Law]

On 06/22/2018 05:06 AM, Martin Liška wrote:
> On 06/20/2018 04:41 PM, David Malcolm wrote:
>> On Mon, 2018-05-14 at 14:50 +0200, Martin Liška wrote:
>>> First part with introduction of auto_string_vec class.
>>>
>> FWIW, I'm fine with the changes to the jit subdir, but I don't think I
>> have approval rights on the vec.h changes.
> Hi.
> 
> Good, I'll wait a review from a global reviewer.
> 
>> BTW, was the move of vec_alloc in vec.h intentional?  (I take it that
>> it's the same before/after, but it seems to have added some churn to
>> the vec.h part of the patch).
> It's not intentional, fixed in attached patch.
> 
> Martin
> 
>> Dave
>>
> 
> 0001-Introduce-auto_string_vec-class.patch
> 
> 
> From abd1b31ec6807d101bbf868acfbdf3bd02319463 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Mon, 14 May 2018 14:00:07 +0200
> Subject: [PATCH] Introduce auto_string_vec class.
> 
> gcc/ChangeLog:
> 
> 2018-05-14  Martin Liska  
> 
>   * vec.h (class auto_string_vec): New (moved from auto_argvec).
>   (auto_string_vec::~auto_string_vec): Likewise.
> 
> gcc/jit/ChangeLog:
> 
> 2018-05-14  Martin Liska  
> 
>   * jit-playback.c (class auto_argvec): Moved to vec.h.
>   (auto_argvec::~auto_argvec): Likewise.
>   (compile): Use the renamed name.
>   (invoke_driver): Likewise.
OK
jeff

Re: PATCH to fix ICE with -Wint-conversion (PR middle-end/86202)

[Jeff Law]

On 06/18/2018 02:34 PM, Marek Polacek wrote:
> This patch improves the checks in size_must_be_zero_p so that we don't
> call get_range_info with SIZE of a pointer type.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk and 8?
> 
> 2018-06-18  Marek Polacek  
> 
>   PR middle-end/86202
>   * gimple-fold.c (size_must_be_zero_p): Check the type of the size.
> 
>   * gcc.dg/Wint-conversion-2.c: New test.
OK.
jeff

Re: [patch] improve entry/exit instrumentation wrt trampolines

[Jeff Law]

On 06/22/2018 09:47 AM, Olivier Hainque wrote:
> 
> 
>> On 22 Jun 2018, at 17:44, Olivier Hainque  wrote:
> 
>> Receiving the actual function address would seem more
>> useful for function-instrumentation purposes, and this
>> patch adjusts the compiler to do that instead.
>>
>> 2018-06-22  Olivier Hainque  
>>
>>  * gimplify.c (gimplify_function_tree): Prevent creation
>>  of a trampoline for the address of the current function
>>  passed to entry/exit instrumentation hooks.
I was a little concerned about the TREE_NO_TRAMPOLINE bit, but that's
only applied to the result of the build_fold_addr_expr, not to the
actual decl itself AFAICT.

So, OK.

Thanks,
jeff

Re: [PATCH 3/3] Come up with new --completion option.

[Jeff Law]

On 06/22/2018 05:25 AM, Martin Liška wrote:
> On 06/20/2018 05:27 PM, David Malcolm wrote:
>> On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
>>> Main part where I still need to write ChangeLog file and
>>> gcc.sh needs to be moved to bash-completions project.
>>>
>>> Martin
>>
>> As before, I'm not an official reviewer for it, but it touches code
>> that I wrote, so here goes.
>>
>> Overall looks good to me, but I have some nitpicks:
>>
>> (needs a ChangeLog)
> 
> Added.
> 
>>
>> [...snip gcc.sh change; I don't feel qualified to comment...]
>>
>> [...snip sane-looking changes to common.opt and gcc.c.  */
>>  
>> diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c
>> index e322fcd91c5..2da094a5960 100644
>> --- a/gcc/opt-suggestions.c
>> +++ b/gcc/opt-suggestions.c
>> @@ -28,18 +28,6 @@ along with GCC; see the file COPYING3.  If not see
>>  #include "opt-suggestions.h"
>>  #include "selftest.h"
>>  
>> -option_proposer::~option_proposer ()
>> -{
>> -  if (m_option_suggestions)
>> -{
>> -  int i;
>> -  char *str;
>> -  FOR_EACH_VEC_ELT (*m_option_suggestions, i, str)
>> -   free (str);
>> -  delete m_option_suggestions;
>> -}
>> -}
>>
>> Why is this dtor going away?  If I'm reading the patch correctly,
>> option_proposer still "owns" m_option_suggestions.
>>
>> What happens if you run "make selftest-valgrind" ?  (my guess is some
>> new memory leaks)
> 
> Fixed that, should not be removed.
> 
>>  
>> +void
>> +option_proposer::get_completions (const char *option_prefix,
>> +  auto_string_vec &results)
>>
>> Missing leading comment.  Maybe something like:
>>
>> /* Populate RESULTS with valid completions of options that begin
>>with OPTION_PREFIX.  */
>>
>> or somesuch.
>>
>> +{
>> +  /* Bail out for an invalid input.  */
>> +  if (option_prefix == NULL || option_prefix[0] == '\0')
>> +return;
>> +
>> +  /* Option suggestions are built without first leading dash character.  */
>> +  if (option_prefix[0] == '-')
>> +option_prefix++;
>> +
>> +  size_t length = strlen (option_prefix);
>> +
>> +  /* Handle parameters.  */
>> +  const char *prefix = "-param";
>> +  if (length >= strlen (prefix)
>> +  && strstr (option_prefix, prefix) == option_prefix)
>>
>> Maybe reword that leading comment to
>>
>>/* Handle OPTION_PREFIX starting with "-param".  */
>>
>> (or somesuch) to clarify the intent?
> 
> Thanks, done.
> 
>>
>> [...snip...]
>>
>> +void
>> +option_proposer::suggest_completion (const char *option_prefix)
>> +{
>>
>> Missing leading comment.  Maybe something like:
>>
>> /* Print on stdout a list of valid options that begin with OPTION_PREFIX,
>>one per line, suitable for use by Bash completion.
>>
>>Implementation of the "-completion=" option.  */
>>
>> or somesuch.
> 
> Likewise.
> 
>>
>> [...snip...]
>>
>> +void
>> +option_proposer::find_param_completions (const char separator,
>> + const char *option_prefix,
>> + auto_string_vec &results)
>>
>> Maybe rename "option_prefix" to "param_prefix"?  I believe it's now
>> the prefix of the param name, rather than the option.
> 
> Makes sense.
> 
>>
>> Missing leading comment.  Maybe something like:
>>
>> /* Populate RESULTS with bash-completions options for all parameters
>>that begin with PARAM_PREFIX, using SEPARATOR.
> 
> It's in header file, thus I copied that.
> 
>>
>>For example, if PARAM_PREFIX is "max-" and SEPARATOR is "=" then
>>strings of the form:
>>  "--param=max-unrolled-insns"
>>  "--param=max-early-inliner-iterations"
>>will be added to RESULTS.  */
>>
>> (did I get that right?)
> 
> Yes.
> 
>>
>> +{
>> +  char separator_str[] {separator, '\0'};
>>
>> Is the above initialization valid C++98, or is it a C++11-ism?
> 
> You are right. I fixed that and 2 more occurrences of the same
> issue.
> 
>>
>> +  size_t length = strlen (option_prefix);
>> +  for (unsigned i = 0; i < get_num_compiler_params (); ++i)
>> +{
>> +  const char *candidate = compiler_params[i].option;
>> +  if (strlen (candidate) >= length
>> +  && strstr (candidate, option_prefix) == candidate)
>> +results.safe_push (concat ("--param", separator_str, candidate, NULL));
>> +}
>> +}
>> +
>> +#if CHECKING_P
>> +
>> +namespace selftest {
>> +
>> +/* Verify that PROPOSER generates sane auto-completion suggestions
>> +   for OPTION_PREFIX.  */
>> +static void
>> +verify_autocompletions (option_proposer &proposer, const char 
>> *option_prefix)
>> +{
>> +  auto_string_vec suggestions;
>> +  proposer.get_completions (option_prefix, suggestions);
>>
>>
>> Maybe a comment here to specify:
>>
>>/* There must be at least one suggestion, and every suggestion must
>>   indeed begin with OPTION_PREFIX.  */
> 
> Yes!
> 
>>
>> +  ASSERT_GT (suggestions.length (), 0);
>> +
>> +  for (unsigned i = 0; i < suggestions.length (); i++)
>> +ASSERT_STR_STARTSWITH (suggestions[i], opt

Re: [PATCH 2/3] Refactoring to opt-suggestions.[ch].

[Jeff Law]

On 06/22/2018 05:07 AM, Martin Liška wrote:
> On 06/20/2018 04:57 PM, David Malcolm wrote:
>> On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
>>> Second part refactors function from gcc.c into a new class
>>> option_proposer.
>>>
>>> Martin
>>
>> [...snip...]
>>
>> diff --git a/gcc/c-family/cppspec.c b/gcc/c-family/cppspec.c
>> index 1e0a8bcd294..66540239f53 100644
>> --- a/gcc/c-family/cppspec.c
>> +++ b/gcc/c-family/cppspec.c
>> @@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
>>  #include "system.h"
>>  #include "coretypes.h"
>>  #include "tm.h"
>> +#include "opt-suggestions.h"
>>  #include "gcc.h"
>>
>> I'm not a reviewer for this, and I don't know what our policy here is,
>> but please can we make "gcc.h" self-contained, and have it include this
>> the header it needs, rather than have every file that includes "gcc.h"
>> need to know what includes gcc.h might need.  Seems like a violation of
>> the DRY principle.
> 
> You mean here including "opt-suggestions.h" in "gcc.h"? I believe we have
> still the rule to not include a header from header file :/
> 
>>
>> [...snip more examples of added headers...]
>>
>> [...snip changes to gcc.c and gcc.h which I can't approve but which
>>  look sane to me...]
>>
>> [...snip more examples of added headers...]
>>
>> diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c
>>
>> [...snip...]
>>
>> +option_proposer::~option_proposer ()
>> +{
>> +  if (m_option_suggestions)
>> +{
>> +  int i;
>> +  char *str;
>> +  FOR_EACH_VEC_ELT (*m_option_suggestions, i, str)
>> +   free (str);
>> +  delete m_option_suggestions;
>> +}
>> +}
>>
>> Could m_option_suggestions be a
>>   auto_string_vec *m_option_suggestions;
>> rather than a:
>>   auto_vec  *m_option_suggestions;
> 
> Yes.
> 
>> ?
>>
>> If so, then this dtor's body could simply be:
>>
>>  option_proposer::~option_proposer ()
>>  {
>>delete m_option_suggestions;
>>  }
> 
> Sure.
> 
>>
>> [...snip...]
>>
>> Everything else looks sane to me (I'm not a reviewer, but I
>> wrote much of the code you're touching).
>>
>> Dave
>>
> 
> I'm attaching updated version.
Based on David's comments, this is fine once the set as a whole is ACK'd.

jeff

Re: [PATCH 2/4] Switch other switch expansion methods into classes.

[Jeff Law]

On 06/22/2018 04:32 AM, Martin Liška wrote:
> On 06/20/2018 05:16 PM, Jeff Law wrote:
>> On 06/20/2018 05:25 AM, Steven Bosscher wrote:
>>> On Tue, Jun 12, 2018 at 10:44 PM, Jeff Law wrote:
 On 06/05/2018 01:15 AM, marxin wrote:
> + The definition of "much bigger" depends on whether we are
> + optimizing for size or for speed.  If the former, the maximum
> + ratio range/count = 3, because this was found to be the optimal
> + ratio for size on i686-pc-linux-gnu, see PR11823.  The ratio
> + 10 is much older, and was probably selected after an extensive
> + benchmarking investigation on numerous platforms.  Or maybe it
> + just made sense to someone at some point in the history of GCC,
> + who knows...  */
 "much older" is an understatement.  I believe the magic "10" pre-dates
 my involvement in GCC.  You can find evidence of it as far back as
 gcc-0.9.  I doubt it was extensively benchmarked, and even if it was,
 the targets on which it was benchmarked don't reflect modern target
 reality in terms of importance.
>>> When I added this comment
>>> (https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/stmt.c?r1=189284&r2=189285&;)
>>> it as an attempt at humor. I should have turned the number into a
>>> PARAM at the time. Maybe that's something Martin could still do now?
>> A PARAM feels like overkill, but I certainly wouldn't object.I'd be
>> happy with that, a const member in the class or even the adjusted
>> constant.
>>
>> jeff
>>
> Hi.
> 
> Agree with Jeff, there's a patch that does that.
> Ready after it finishes tests?
> 
> Martin
> 
> 
> 0001-Come-up-with-jump_table-ratio-constants-used-in-jump.patch
> 
> 
> From 27d7c87720dc464b6ed998bc7344cf2226d5f9ea Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Fri, 22 Jun 2018 12:24:13 +0200
> Subject: [PATCH] Come up with jump_table ratio constants used in
>  jump_table_cluster.
> 
> gcc/ChangeLog:
> 
> 2018-06-22  Martin Liska  
> 
>   * tree-switch-conversion.c (jump_table_cluster::can_be_handled):
> Use newly introduced constants.
>   * tree-switch-conversion.h (struct jump_table_cluster):
> Define max_ratio_for_size and max_ratio_for_speed.
OK.
jeff

Re: [PATCH 0/3][POPCOUNT]

[Jeff Law]

On 06/22/2018 03:11 AM, Kugan Vivekanandarajah wrote:
> When we set niter with maybe_zero, currently final_value_relacement
> will not happen due to expression_expensive_p not handling. Patch 1
> adds this.
> 
> With that we have the following optimized gimple.
> 
>[local count: 118111601]:
>   if (b_4(D) != 0)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 105119324]:
>   _2 = (unsigned long) b_4(D);
>   _9 = __builtin_popcountl (_2);
>   c_3 = b_4(D) != 0 ? _9 : 1;
> 
>[local count: 118111601]:
>   # c_12 = PHI 
> 
> I assume that 1 in  b_4(D) != 0 ? _9 : 1; is OK (?) because when the
> latch execute zero times for b_4 == 0 means that the body will execute
> ones.
ISTM that DOM ought to have simplified the conditional, unless there's
some other way to get to bb3.  We know that b_4 is nonzero and thus c_3
must have the value _9.


> 
> The issue here is, since we are checking if (b_4(D) != 0) before
> entering the loop means we don't need to set maybe_zero. Patch 2
> handles this.
> 
> With that we have
>[local count: 118111601]:
>   if (b_4(D) != 0)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 105119324]:
>   _2 = (unsigned long) b_4(D);
>   _9 = __builtin_popcountl (_2);
> 
>[local count: 118111601]:
>   # c_12 = PHI <0(2), _9(3)>
> 
> As advised earlier, patch 3 adds phiopt support to remove this.
So if DOM or some other pass fixed up the assignment to c_3 I'd hope we
wouldn't set maybe_zero.

So I'd like to start by first determining if we should have already
simplified the COND_EXPR in bb3.  Do you have a testcase for that?


jeff

Re: [PATCH][testsuite/guality] Use buildarea gdb by default in combined build

[Jeff Law]

On 06/22/2018 05:38 AM, Tom de Vries wrote:
> Hi,
> 
> when doing a combined build of gcc and binutils-gdb repos, guality still
> uses the gdb in PATH by default.
> 
> This patch makes sure that quality uses the gdb from the combined build
> instead.
> 
> Tested on x86_64.
> 
> OK for trunk?
> 
> Thanks,
> - Tom
> 
> [testsuite/guality] Use buildarea gdb by default in combined build
> 
> 2018-06-22  Tom de Vries  
> 
>   * g++.dg/guality/guality.exp (guality_gdb_name): Default to
>   $rootme/../gdb/gdb, if available.
>   * gcc.dg/guality/guality.exp (guality_gdb_name): Same.
>   * gfortran.dg/guality/guality.exp (guality_gdb_name): Same.
OK.  Most folks aren't doing combined tree builds anymore, but I
certainly understand their appeal and the desire to pick the just built
tools.

jeff

Re: [PATCH][testsuite/guality] Be verbose about gdb version used

[Jeff Law]

On 06/22/2018 05:35 AM, Tom de Vries wrote:
> Hi,
> 
> by default, guality invokes gdb with --quiet to avoid being unnecessarily
> verbose for each test.  But as a consequence, we don't see which version of
> gdb is used.
> 
> This patch adds printing of the full path to the gdb used, as well as the
> gdb version as printed by gdb.
> 
> Tested on x86_64.
> 
> OK for trunk?
> 
> Thanks,
> - Tom
> 
> [testsuite/guality] Be verbose about gdb version used
> 
> 2018-06-22  Tom de Vries  
> 
>   * lib/gcc-gdb-test.exp (report_gdb): New proc.
>   * g++.dg/guality/guality.exp: Use report_gdb.
>   * gcc.dg/guality/guality.exp: Same.
>   * gfortran.dg/guality/guality.exp: Same.
OK.
jeff

Re: Do not emit unnecessary NOPs at -O0

[Jeff Law]

On 06/22/2018 02:39 AM, Richard Biener wrote:
> On Thu, Jun 21, 2018 at 9:37 PM Jeff Law  wrote:
>>
>> On 06/21/2018 11:04 AM, Eric Botcazou wrote:
>>> When code is compiled at -O0, the RTL middle-end makes sure that location
>>> information is preserved as much as possible by generating NOPs with the
>>> location information (goto_locus) present on edges in the CFG, if it thinks
>>> that these edges are the only place where a particular location is 
>>> mentioned.
>>>
>>> The attached patch prevents this from happening in a couple of cases:
>>>  1. if the function has the DECL_IGNORED_P flag set,
>>>  2. if the NOP is emitted by merge_blocks and the 2nd block is a forwarder
>>> block whose outgoing edge has no location, because in this case the location
>>> of the to-be-elided edge is copied onto the aforementioned outgoing edge.
>>>
>>> Tested (GCC and GDB) on x86-64/Linux, applied on the mainline.
>>>
>>>
>>> 2018-06-21  Eric Botcazou  
>>>
>>>   * cfgrtl.c (fixup_reorder_chain): Do not emit NOPs in DECL_IGNORED_P
>>>   functions.
>>>   (rtl_merge_blocks): Likewise.  Do not emit a NOP if the location of 
>>> the
>>>   edge can be forwarded.
>>>   (cfg_layout_merge_blocks): Likewise.
>> Funny Alex and I were just talking about the need to stuff away debug
>> info on edges for gimple.   Attaching it to gimple nops sounds like a
>> fairly straightforward approach :-)
> 
> But wouldn't that create BBs?  Sounds like you want DEBUG PHIs... :/
We talked about those too :-)

Jeff

Re: [Patch] Do not call the linker if we are creating precompiled header files

[Steve Ellcey]

On Tue, 2018-06-19 at 15:22 +, Joseph Myers wrote:
> 
> 
> What should plain
> 
>   gcc -Wl,-rpath=/foo
> 
> do?  Whatever it should do regarding trying to link or not trying to link,
> it should do the same if you also name a header on the command line to be
> compiled to a precompiled header.  So if you don't want it to try to link
> when building a precompiled header, you presumably want it to say "gcc:
> fatal error: no input files" just like if you pass some compilation option
> to GCC, rather than trying to run the linker.

Actually my preference would be for gcc to not call the linker and to
not print an error message.  If I use gcc to call the linker and link
object files into an executable and I pass it compiler options like
'-fauto-inc-dec' or '-Wa,--gdwarf-2' GCC does not complain that it is
not calling the compiler or the assembler.  We seem to accept the fact
that some flags may not be used due to what type of compilation is
being done and just ignore them.  I would like to do the same with
linker flags.

> So the basic question is: is it valid to link a program (or shared
> library) using *only* -Wl, / -Xlinker to provide input files?  Given that
> those are documented as being for passing options rather than input files
> I think it's reasonable to say it's not valid - so when -Wl, / -Xlinker
> are used, their arguments, stored alongside actual linker input files (any
> non-option that doesn't have a file extension known to be a language
> compiled by GCC), should be marked in some way to indicate that they are
> options not input files and so should not by themselves cause linking to
> be done.

I think this seems right.

> Then there's the question of whether -l counts as an input file
> or an option for this purpose.  Using it as an input file is a bit less
> contrived than using -Wl, options for that purpose - for example, it's
> valid to define main in a shared library (there's a glibc test for this),
> and then you can link a program using just -l without naming any
> object files to link - so I'd be inclined to keep it as an input file, not
> an option.

I can see both sides of this and don't feel strongly one way or the
other.  I have attached a new patch that does allow for the use of just
-l options to force the linker to be called.

Currently explicit_link_files gets set for arguments and options that
get sent to the linker and if there are at least one of these then GCC
calls the linker.  I added a new field that gets set for arguments but
not for files and changed GCC to only call the linker if it sees at
least one non-argument input.  Originally I was just not setting
explicit_link_files for arguments but that did not work because
outfiles was still getting set and that was still triggering the linker
call. '-l' arguments are handled in two ways, if the user passes in a
'-l' we count that as an input file (since a user could put main in a
library and pass that to the linker with a -l), but if the -l comes
from a SPEC file (like the -lstdc++ that gets added automtically) we do
not count that as an input to the linker.

I changed explicit_link_files from an array of char to an array of bool
since that was how it was being used and made explicit_link_args to
be an array of bool also.

My reason for wanting this patch is that I build a complete toolchain
with gcc, binutils, and glibc in a non-standard place and then run
the GCC testsuite with:

make check RUNTESTFLAGS="--tool_opts  '--sysroot=$T/install
-Wl,--dynamic-linker=$T/install/lib/ld-linux-aarch64.so.1 -Wl,-
rpath=$T/install/lib64'"

and without my patch a number of pch tests fail.

Steve Ellcey
sell...@cavium.com


2018-06-22  Steve Ellcey  

* gcc.h (driver): Add explicit_link_args field.
* gcc.c (driver::driver): Initialize explicit_link_args.
(driver::~driver): Delete explicit_link_args.
(driver::prepare_infiles): Allocate explicit_link_args
and set it if a non library argument is seen.
(driver::do_spec_on_infiles): Set explicit_link_args
if linker argument is seen.
(driver::maybe_run_linker): Do not increment num_linker_inputs
for linker arguments (only for linker inputs).

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 405d2e3..8c09687 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -7270,6 +7270,7 @@ compare_files (char *cmpfile[])
 
 driver::driver (bool can_finalize, bool debug) :
   explicit_link_files (NULL),
+  explicit_link_args (NULL),
   decoded_options (NULL),
   m_option_suggestions (NULL)
 {
@@ -7279,6 +7280,7 @@ driver::driver (bool can_finalize, bool debug) :
 driver::~driver ()
 {
   XDELETEVEC (explicit_link_files);
+  XDELETEVEC (explicit_link_args);
   XDELETEVEC (decoded_options);
   if (m_option_suggestions)
 {
@@ -8092,7 +8094,8 @@ driver::prepare_infiles ()
 
   /* Record which files were specified explicitly as link input.  */
 
-  explicit_link_files = XCNEWVEC (char, n_infiles);
+  explicit_link_files = XCNEWVEC (bool,

Re: [patch] improve entry/exit instrumentation wrt trampolines

[Olivier Hainque]

> On 22 Jun 2018, at 17:44, Olivier Hainque  wrote:

> Receiving the actual function address would seem more
> useful for function-instrumentation purposes, and this
> patch adjusts the compiler to do that instead.
> 
> 2018-06-22  Olivier Hainque  
> 
>   * gimplify.c (gimplify_function_tree): Prevent creation
>   of a trampoline for the address of the current function
>   passed to entry/exit instrumentation hooks.

With the patch attached ...

Thanks in advance,

Regards,

Olivier



instrument-no-trampoline.diff
Description: Binary data

[patch] improve entry/exit instrumentation wrt trampolines

[Olivier Hainque]

Hello,

Execution of the example program below shows that when
a nested function is called by way of a stack trampoline,
the -finstrument-functions hooks receive the address of
the trampoline as the "this function" parameter.

Receiving the actual function address would seem more
useful for function-instrumentation purposes, and this
patch adjusts the compiler to do that instead.

On x86_64-linux, without the patch, the code below compiled
with -finstrument-functions outputs something like

  entering function at 0x4005a1
  entering function at 0x7fffae4acc34

And with the patch, we get instead:

  entering function at 0x400583
  entering function at 0x400557

where the second address corresponds to the bump_by
symbol address.

Bootstrapped and regression tested on x86_64-linux.

Ok to commit ?

Thanks in advance,

With Kind Regards,

2018-06-22  Olivier Hainque  

* gimplify.c (gimplify_function_tree): Prevent creation
of a trampoline for the address of the current function
passed to entry/exit instrumentation hooks.

---

int main ()
{
  volatile int count = 0;

  void bump_by (int x)
  {
count += x;
  }

  { void (* bumper)(int) = &bump_by;
(*bumper)(5);
  }
   
  return 0;
}

#include 

__attribute__((no_instrument_function))
void __cyg_profile_func_exit (void * this_fn, void * call_site)
{
}

__attribute__((no_instrument_function))
void __cyg_profile_func_enter (void * this_fn, void * call_site)
{
  printf ("entering function at %p\n", this_fn);
}

[PATCH, rs6000] Add vec_extract builtin tests, fix arguments on existing tests

[Carl Love]

GCC Maintainers:

The following patch adds tests for the vec_extract builtin.  I also
adjusts the second argument on the existing tests so they match the
ABI, specifically an integer not a const integer.

The patch has been tested on 

powerpc64le-unknown-linux-gnu (Power 9 LE)
 
With no regressions.

Please let me know if the patch looks OK for GCC mainline. 

 Carl Love



gcc/testsuite/ChangeLog:

2018-06-21  Carl Love  

* gcc.target/powerpc/p9-extract-1.c: Make second argument of
vec_extract a signed int. Add vec_extract tests for bool char
and bool int.
* gcc.target/powerpc/p9-extract-4.c:  New test file for long long
vec_extract tests.
---
 gcc/testsuite/gcc.target/powerpc/p9-extract-1.c | 52 +++--
 gcc/testsuite/gcc.target/powerpc/p9-extract-4.c | 30 ++
 2 files changed, 70 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/p9-extract-4.c

diff --git a/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c 
b/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
index ecbe0ed..ab9e766 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
@@ -13,84 +13,112 @@
 int
 extract_int_0 (vector int a)
 {
-  int b = vec_extract (a, 0);
+  int c = 0;
+  int b = vec_extract (a, c);
   return b;
 }
 
 int
 extract_int_3 (vector int a)
 {
-  int b = vec_extract (a, 3);
+  int c = 3;
+  int b = vec_extract (a, c);
   return b;
 }
 
 unsigned int
 extract_uint_0 (vector unsigned int a)
 {
-  unsigned int b = vec_extract (a, 0);
+  int c = 0;
+  unsigned int b = vec_extract (a, c);
   return b;
 }
 
 unsigned int
 extract_uint_3 (vector unsigned int a)
 {
-  unsigned int b = vec_extract (a, 3);
+  int c = 3;
+  unsigned int b = vec_extract (a, c);
   return b;
 }
 
 short
 extract_short_0 (vector short a)
 {
-  short b = vec_extract (a, 0);
+  int c = 0;
+  short b = vec_extract (a, c);
   return b;
 }
 
 short
 extract_short_7 (vector short a)
 {
-  short b = vec_extract (a, 7);
+  int c = 7;
+  short b = vec_extract (a, c);
   return b;
 }
 
 unsigned short
 extract_ushort_0 (vector unsigned short a)
 {
-  unsigned short b = vec_extract (a, 0);
+  int c = 0;
+  unsigned short b = vec_extract (a, c);
   return b;
 }
 
 unsigned short
 extract_ushort_7 (vector unsigned short a)
 {
-  unsigned short b = vec_extract (a, 7);
+  int c = 7;
+  unsigned short b = vec_extract (a, c);
   return b;
 }
 
 signed char
 extract_schar_0 (vector signed char a)
 {
-  signed char b = vec_extract (a, 0);
+  int c = 0;
+  signed char b = vec_extract (a, c);
   return b;
 }
 
 signed char
 extract_schar_15 (vector signed char a)
 {
-  signed char b = vec_extract (a, 15);
+  int c = 15;
+  signed char b = vec_extract (a, c);
   return b;
 }
 
 unsigned char
 extract_uchar_0 (vector unsigned char a)
 {
-  unsigned char b = vec_extract (a, 0);
+  int c = 0;
+  unsigned char b = vec_extract (a, c);
   return b;
 }
 
 unsigned char
 extract_uchar_15 (vector unsigned char a)
 {
-  signed char b = vec_extract (a, 15);
+  int c = 15;
+  signed char b = vec_extract (a, c);
+  return b;
+}
+
+unsigned char
+extract_bool_char_0 (vector bool char a)
+{
+  int c = 0;
+  unsigned char b = vec_extract (a, c);
+  return b;
+}
+
+unsigned int
+extract_bool_int_0 (vector bool int a)
+{
+  int c = 0;
+  unsigned int b = vec_extract (a, c);
   return b;
 }
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-extract-4.c 
b/gcc/testsuite/gcc.target/powerpc/p9-extract-4.c
new file mode 100644
index 000..5212949
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/p9-extract-4.c
@@ -0,0 +1,30 @@
+/* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-options "-mcpu=power9 -O2" } */
+
+/* This file tests the extraction of 64-bit values.  The direct move is
+   prefered for the  64-bit extract as it is either lower latency or the same
+   latency as the extract instruction depending on the Endianess of the system.
+   Furthermore, there can be up to four move instructions in flight at a time
+   versus only two extract intructions at a time.  */
+
+#include 
+
+unsigned long long
+extract_bool_long_long_0 (vector bool long long a)
+{
+  int c = 0;
+  unsigned long long b = vec_extract (a, c);
+  return b;
+}
+
+unsigned long long int
+extract_long_long_0 (vector unsigned long long int a)
+{
+  int c = 0;
+  unsigned long long int b = vec_extract (a, c);
+  return b;
+}
+
+/* { dg-final { scan-assembler-times "m\[ft\]vsr" 2 } } */
-- 
2.7.4

[PATCH, committed] fix pdp11 target test failures

[Paul Koning]

This patch fixes a number of test suite failures caused by data too large for 
the address space or alignment larger than supported by this target.

paul

testsuite/ChangeLog:

2018-06-22  Paul Koning  

* gcc.c-torture/execute/builtins/lib/chk.c: Use smaller alignment
if pdp11.
* gcc.c-torture/compile/20010518-2.c: Skip if pdp11 -mint32.
* gcc.c-torture/compile/20040101-1.c: Ditto.
* gcc.c-torture/compile/20050622-1.c: Ditto.
* gcc.c-torture/compile/20080625-1.c: Ditto.
* gcc.c-torture/compile/20090107-1.c: Ditto.
* gcc.c-torture/compile/920501-12.c: Ditto.
* gcc.c-torture/compile/920501-4.c: Ditto.
* gcc.c-torture/compile/961203-1.c: Ditto.
* gcc.c-torture/compile/limits-externdecl.c: Ditto.
* gcc.c-torture/compile/pr25310.c: Ditto.

Index: testsuite/gcc.c-torture/execute/builtins/lib/chk.c
===
--- testsuite/gcc.c-torture/execute/builtins/lib/chk.c  (revision 261896)
+++ testsuite/gcc.c-torture/execute/builtins/lib/chk.c  (revision 261897)
@@ -3,10 +3,18 @@
 #include 
 #endif
 
+/* If some target has a Max alignment less than 16, please create
+   a #ifdef around the alignment and add your alignment.  */
+#ifdef __pdp11__
+#define ALIGNMENT 2
+#else
+#define ALIGNMENT 16
+#endif
+
 extern void abort (void);
 
 extern int inside_main;
-void *chk_fail_buf[256] __attribute__((aligned (16)));
+void *chk_fail_buf[256] __attribute__((aligned (ALIGNMENT)));
 volatile int chk_fail_allowed, chk_calls;
 volatile int memcpy_disallowed, mempcpy_disallowed, memmove_disallowed;
 volatile int memset_disallowed, strcpy_disallowed, stpcpy_disallowed;
Index: testsuite/gcc.c-torture/compile/920501-4.c
===
--- testsuite/gcc.c-torture/compile/920501-4.c  (revision 261896)
+++ testsuite/gcc.c-torture/compile/920501-4.c  (revision 261897)
@@ -1,5 +1,6 @@
 /* { dg-do assemble } */
 /* { dg-skip-if "ptxas times out" { nvptx-*-* } { "-O1" } { "" } } */
+/* { dg-skip-if "Array too big" { "pdp11-*-*" } { "-mint32" } } */
 
 foo ()
 {
Index: testsuite/gcc.c-torture/compile/20080625-1.c
===
--- testsuite/gcc.c-torture/compile/20080625-1.c(revision 261896)
+++ testsuite/gcc.c-torture/compile/20080625-1.c(revision 261897)
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target int32plus } */
+/* { dg-skip-if "Array too big" { "pdp11-*-*" } { "-mint32" } } */
 
 struct peakbufStruct {
 unsigned int lnum [5000];
Index: testsuite/gcc.c-torture/compile/20040101-1.c
===
--- testsuite/gcc.c-torture/compile/20040101-1.c(revision 261896)
+++ testsuite/gcc.c-torture/compile/20040101-1.c(revision 261897)
@@ -1,4 +1,4 @@
-/* { dg-skip-if "not enough registers" { pdp11-*-* } { "-O[12s]" } { "" } } */
+/* { dg-skip-if "not enough registers" { pdp11-*-* } } */
 
 typedef unsigned short uint16_t;
 typedef unsigned int uint32_t;
Index: testsuite/gcc.c-torture/compile/20090107-1.c
===
--- testsuite/gcc.c-torture/compile/20090107-1.c(revision 261896)
+++ testsuite/gcc.c-torture/compile/20090107-1.c(revision 261897)
@@ -1,3 +1,5 @@
+/* { dg-skip-if "Array too big" { "pdp11-*-*" } { "-mint32" } } */
+
 /* Verify that we don't ICE by forming invalid addresses for unaligned
doubleword loads (originally for PPC64).  */
 
Index: testsuite/gcc.c-torture/compile/20010518-2.c
===
--- testsuite/gcc.c-torture/compile/20010518-2.c(revision 261896)
+++ testsuite/gcc.c-torture/compile/20010518-2.c(revision 261897)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-skip-if "Array too big" { "pdp11-*-*" } { "-mint32" } } */
 
 /* Large static storage.  */
 
Index: testsuite/gcc.c-torture/compile/920501-12.c
===
--- testsuite/gcc.c-torture/compile/920501-12.c (revision 261896)
+++ testsuite/gcc.c-torture/compile/920501-12.c (revision 261897)
@@ -1,4 +1,5 @@
 /* { dg-do assemble } */
+/* { dg-skip-if "Array too big" { "pdp11-*-*" } { "-mint32" } } */
 
 x(x){return 3 + x;}
 a(x){int y[994]; return 3 + x;}
Index: testsuite/gcc.c-torture/compile/limits-externdecl.c
===
--- testsuite/gcc.c-torture/compile/limits-externdecl.c (revision 261896)
+++ testsuite/gcc.c-torture/compile/limits-externdecl.c (revision 261897)
@@ -1,4 +1,5 @@
 /* { dg-skip-if "ptxas runs out of memory" { nvptx-*-* } } */
+/* { dg-skip-if "Array too big" { "pdp11-*-*" } { "-mint32" } } */
 
 /* { dg-require-effective-target int32plus } */
 /* Inspired by the test case for PR middle-end/52640.  */
Index: testsuite/gcc.c-tort

[PATCH, rs6000] Change word selector to prefered location for vec_insert builtin

[Carl Love]

GCC Maintainers:

The following patch changes the word selected when extracting the word
from the second vector to insert into the first vector by the
vec_insert() builtin.  

Specifically, the test case

vector float
fn2 (float a, vector float b)   
{   
  return vec_insert (a, b, 1);  
}   

without the patch  generates the code sequence 

 xscvdpspn vs0,vs1
 xxextractuw vs0,vs0,4
 xxinsertw vs34,vs0,8

The xscvdpspn places the extracted word into words 0 and 1 of the
destination.  The xxextractuw extracts word 1 (offset of 4 bytes)from
the source.  The patch changes the offset so that the xxexractuw will
extract word 0 (offset 0 bytes) instead of word 1.  The values are the
same so there is no functional change. But it was decided that using
word 0 was preferred choice.

 Carl Love

-

gcc/ChangeLog:

2018-06-19  Carl Love  

* config/rs6000/vsx.md: Change word selector to prefered location.

Signed-off-by: Carl Love 
---
 gcc/config/rs6000/vsx.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index a528ef2e8..6e7a4277f 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -3934,7 +3934,7 @@
 
   operands[5] = gen_rtx_REG (V4SFmode, tmp_regno);
   operands[6] = gen_rtx_REG (V4SImode, tmp_regno);
-  operands[7] = GEN_INT (BYTES_BIG_ENDIAN ? 1 : 2);
+  operands[7] = GEN_INT (BYTES_BIG_ENDIAN ? 0 : 3);
   operands[8] = gen_rtx_REG (V4SImode, reg_or_subregno (operands[0]));
 }
   [(set_attr "type" "vecperm")
-- 
2.17.1

libgo patch committed: Remove syscall.Ustat

[Ian Lance Taylor]

Reportedly glibc 2.28 removes the ustat.h header file and the ustat
function.  This breaks libgo, which provides syscall.Ustat that calls
the C ustat function.  Fix this by removing syscall.Ustat from libgo.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline, GCC 8 branch, and GCC 7 branch.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 261871)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-d3eb93c1b8990dbfd4bb660c5c8454916b62655c
+bdead75ea02fa852a559f35b41453df0c47c9a66
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/configure.ac
===
--- libgo/configure.ac  (revision 261819)
+++ libgo/configure.ac  (working copy)
@@ -537,24 +537,6 @@ AC_CHECK_HEADERS([linux/filter.h linux/i
 #endif
 ])
 
-AC_CACHE_CHECK([whether  can be used],
-[libgo_cv_c_ustat_h],
-[CFLAGS_hold=$CFLAGS
-CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE $OSCFLAGS"
-AC_COMPILE_IFELSE(
-[AC_LANG_SOURCE([
-#include 
-#ifdef HAVE_LINUX_FILTER_H
-#include 
-#endif
-#include 
-])], [libgo_cv_c_ustat_h=yes], [libgo_cv_c_ustat_h=no])
-CFLAGS=$CFLAGS_hold])
-if test $libgo_cv_c_ustat_h = yes; then
-  AC_DEFINE(HAVE_USTAT_H, 1,
-[Define to 1 if you have the  header file and it works.])
-fi
-
 AM_CONDITIONAL(HAVE_SYS_MMAN_H, test "$ac_cv_header_sys_mman_h" = yes)
 
 AC_CHECK_FUNCS(strerror_r strsignal wait4 mincore setenv unsetenv 
dl_iterate_phdr)
Index: libgo/go/syscall/libcall_linux_ustat.go
===
--- libgo/go/syscall/libcall_linux_ustat.go (revision 261819)
+++ libgo/go/syscall/libcall_linux_ustat.go (nonexistent)
@@ -1,12 +0,0 @@
-// Copyright 2015 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-// GNU/Linux library ustat call.
-// This is not supported on some kernels, such as arm64.
-// +build !arm64,!nios2,!riscv64
-
-package syscall
-
-//sys  Ustat(dev int, ubuf *Ustat_t) (err error)
-//ustat(dev _dev_t, ubuf *Ustat_t) _C_int
Index: libgo/mksysinfo.sh
===
--- libgo/mksysinfo.sh  (revision 261819)
+++ libgo/mksysinfo.sh  (working copy)
@@ -1164,20 +1164,6 @@ grep '^type _sysinfo ' gen-sysinfo.go |
   -e 's/mem_unit/Unit/' \
 >> ${OUT}
 
-# The ustat struct.
-grep '^type _ustat ' gen-sysinfo.go | \
-sed -e 's/_ustat/Ustat_t/' \
-  -e 's/f_tfree/Tfree/' \
-  -e 's/f_tinode/Tinoe/' \
-  -e 's/f_fname/Fname/' \
-  -e 's/f_fpack/Fpack/' \
->> ${OUT}
-# Force it to be defined, as on some older GNU/Linux systems the
-# header file fails when using with .
-if ! grep 'type _ustat ' gen-sysinfo.go >/dev/null 2>&1; then
-  echo 'type Ustat_t struct { Tfree int32; Tinoe uint64; Fname [5+1]int8; 
Fpack [5+1]int8; }' >> ${OUT}
-fi
-
 # The utimbuf struct.
 grep '^type _utimbuf ' gen-sysinfo.go | \
 sed -e 's/_utimbuf/Utimbuf/' \
Index: libgo/sysinfo.c
===
--- libgo/sysinfo.c (revision 261819)
+++ libgo/sysinfo.c (working copy)
@@ -144,9 +144,6 @@
 #if defined(HAVE_SYS_SYSINFO_H)
 #include 
 #endif
-#if defined(HAVE_USTAT_H)
-#include 
-#endif
 #if defined(HAVE_UTIME_H)
 #include 
 #endif

Re: [PATCH] PR libstdc++/83328 add correct basic_string::insert for initializer_list

[Jonathan Wakely]

On 22/06/18 15:14 +0200, Christophe Lyon wrote:

Hi,

On Fri, 22 Jun 2018 at 14:54, Jonathan Wakely  wrote:


On 22/06/18 14:51 +0200, Rainer Orth wrote:
>Hi Jonathan,
>
>> The SSO basic_string has a non-standard insert(iterator, initializer_list)
>> overload, from a C++0x draft. This adds the correct overload, while also
>> preserving the old one so that the old symbol is still exported from the
>> library.
>>
>> The COW basic_string doesn't have any of the C++11 changes to the insert
>> overloads (they all still have non-const iterator parameters and the
>> ones that should return an iterator still return void). This doesn't
>> make any change to the COW string.
>>
>>  PR libstdc++/83328
>>  * acinclude.m4 (libtool_VERSION): Bump to 6:26:0.
>>  * config/abi/pre/gnu.ver: Add GLIBCXX_3.4.26 and export new symbol.
>>  * configure: Regenerate.
>>  * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
>>  (basic_string::insert(const_iterator, initializer_list)): Add.
>>  [_GLIBCXX_USE_CXX11_ABI && !_GLIBCXX_DEFINING_STRING_INSTANTIATIONS]
>>  (basic_string::insert(iterator, initializer_list)): Suppress
>>  definition.
>>  * include/debug/string (basic_string::insert(iterator, C)): Change
>>  first parameter to const_iterator.
>>  (basic_string::insert(iterator, size_type, C)): Likewise. Change
>>  return type to iterator.
>>  (basic_string::insert(iterator, InputIterator, InputIterator)):
>>  Likewise.
>>  (basic_string::insert(iterator, initializer_list)): Change first
>>  parameter to const_iterator and return type to iterator.
>>  * src/c++11/string-inst.cc: Extend comment.
>>  * testsuite/21_strings/basic_string/modifiers/insert/char/83328.cc:
>>  New.
>>  * testsuite/21_strings/basic_string/modifiers/insert/wchar_t/83328.cc:
>>  New.
>>  * testsuite/util/testsuite_abi.cc: Add new symbol version.
>>
>> Tested x86_64-linux, committed to trunk.
>
>it seems a couple of pattners are a bit too tight now in gnu.ver: this
>caused a couple of failures on 32-bit Solaris and subsequent tests
>failing to link due to symbols now hidden:

Oops, it's the usual mangling difference for size_t, I'll fix it
today.



I've also noticed a few regressions after this patch on arm:
FAIL:g++.dg/torture/pr60750.C   -O0  (test for excess errors)
FAIL:g++.dg/torture/pr60750.C   -Os  (test for excess errors)
Excess errors:
pr60750.C:(.text._ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EERKS8_OS8_[_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EERKS8_OS8_]+0x24):
undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int,
std::__cxx11::basic_string,
std::allocator > const&)'


Yep, that should be fixed by r261892.

Re: [PATCH] PR libstdc++/83328 add correct basic_string::insert for initializer_list

[Jonathan Wakely]

On 22/06/18 14:13 +0100, Jonathan Wakely wrote:

On 22/06/18 13:54 +0100, Jonathan Wakely wrote:

On 22/06/18 14:51 +0200, Rainer Orth wrote:

Hi Jonathan,


The SSO basic_string has a non-standard insert(iterator, initializer_list)
overload, from a C++0x draft. This adds the correct overload, while also
preserving the old one so that the old symbol is still exported from the
library.

The COW basic_string doesn't have any of the C++11 changes to the insert
overloads (they all still have non-const iterator parameters and the
ones that should return an iterator still return void). This doesn't
make any change to the COW string.

PR libstdc++/83328
* acinclude.m4 (libtool_VERSION): Bump to 6:26:0.
* config/abi/pre/gnu.ver: Add GLIBCXX_3.4.26 and export new symbol.
* configure: Regenerate.
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::insert(const_iterator, initializer_list)): Add.
[_GLIBCXX_USE_CXX11_ABI && !_GLIBCXX_DEFINING_STRING_INSTANTIATIONS]
(basic_string::insert(iterator, initializer_list)): Suppress
definition.
* include/debug/string (basic_string::insert(iterator, C)): Change
first parameter to const_iterator.
(basic_string::insert(iterator, size_type, C)): Likewise. Change
return type to iterator.
(basic_string::insert(iterator, InputIterator, InputIterator)):
Likewise.
(basic_string::insert(iterator, initializer_list)): Change first
parameter to const_iterator and return type to iterator.
* src/c++11/string-inst.cc: Extend comment.
* testsuite/21_strings/basic_string/modifiers/insert/char/83328.cc:
New.
* testsuite/21_strings/basic_string/modifiers/insert/wchar_t/83328.cc:
New.
* testsuite/util/testsuite_abi.cc: Add new symbol version.

Tested x86_64-linux, committed to trunk.


it seems a couple of pattners are a bit too tight now in gnu.ver: this
caused a couple of failures on 32-bit Solaris and subsequent tests
failing to link due to symbols now hidden:


Oops, it's the usual mangling difference for size_t, I'll fix it
today.


I'm testing this ...


Tested multilib x86_64-linux, committed to trunk.

Sorry for the silly mistake. I think I'll add a local git hook so that
when I commit changes to the linker script it checks that I've used
'[jmy]' not 'm' in any symbols that use size_t.



commit 3c22cca756b18420d042d19fbcc8892c2aa81ea5
Author: Jonathan Wakely 
Date:   Fri Jun 22 14:11:08 2018 +0100

   Fix unexported basic_string symbols for 32-bit targets
   
   * config/abi/pre/gnu.ver: Fix __cxx11::basic_string patterns for

   different size_t mangling on 32-bit targets.

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index b59b9a0ff1f..782b1238742 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1716,14 +1716,14 @@ GLIBCXX_3.4.21 {
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6append*;
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6assign*;
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertI*;
-
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmPK[cw];
-
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmPK[cw]m;
-
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmRKS4_;
-
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmRKS4_mm;
-
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmm[cw];
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy]PK[cw];
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy]PK[cw][jmy];
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy]RKS4_;
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy]RKS4_[jmy][jmy];
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy][jmy][cw];

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEN9__gnu_cxx17__normal_iteratorIP[cw]*;

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEN9__gnu_cxx17__normal_iteratorIPK[cw]S4_EE[cw];
-
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEN9__gnu_cxx17__normal_iteratorIPK[cw]S4_EEm[cw];
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEN9__gnu_cxx17__normal_iteratorIPK[cw]S4_EE[jmy][cw];
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6rbegin*;
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6resize*;
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE7replace*;

Re: [PATCH ARM] Fix armv8-m multilib build failure with stdint.h

[Kyrill Tkachov]

On 22/06/18 14:56, Andre Vieira (lists) wrote:

On 17/05/18 09:29, Kyrill Tkachov wrote:
>
> On 16/05/18 10:22, Jérôme Lambourg wrote:
>> Hello Kyrill,
>>
>>> Thanks for the patch! To validate it your changes you can also look
>>> at the disassembly
>>> of the cmse.c binary in the build tree. If the binary changes with
>>> your patch then that
>>> would indicate some trouble.
>> Good idea. So I just did that and the assembly of both objects are
>> identical
>> (before and after the patch).
>>
>>> There are places in arm_cmse.h that use intptr_t. You should replace
>>> those as well.
>>> Look for the cmse_nsfptr_create and cmse_is_nsfptr macros...
>> Indeed, good catch. I did not see those as this part is not included
>> in the armv8-m.
>>
>> Below the updated patch and modified changelog.
>
> Thanks this looks good with one nit below.
>
>> 2018-05-16  Jerome Lambourg 
>> gcc/
>> * config/arm/arm_cmse.h (cmse_nsfptr_create, cmse_is_nsfptr): Remove
>> #include . Replace intptr_t with __INTPTR_TYPE__.
>>
>> libgcc/
>> * config/arm/cmse.c (cmse_check_address_range): Replace
>> UINTPTR_MAX with __UINTPTR_MAX__ and uintptr_t with __UINTPTR_TYPE__.
>>
>
> @@ -51,7 +51,8 @@
>
>/* Execute the right variant of the TT instructions.  */
>pe = pb + size - 1;
> -  const int singleCheck = (((uintptr_t) pb ^ (uintptr_t) pe) < 32);
> +  const int singleCheck =
> +(((__UINTPTR_TYPE__) pb ^ (__UINTPTR_TYPE__) pe) < 32);
>
> The "=" should go on the next line together with the initialisation.
>
> Ok for trunk with that fixed.
> Thanks,
> Kyrill
Hi,

Is it OK to backport this to gcc-7?



Ok.
Thanks,
Kyrill


Applies cleanly and I ran the cmse tests.

Cheers,
Andre

Re: [ARM][PATCH] Make arm_cmse.h C99 compatible

[Kyrill Tkachov]

On 22/06/18 14:56, Andre Vieira (lists) wrote:

On 05/06/18 11:18, Kyrill Tkachov wrote:
>
> On 05/06/18 11:03, Andre Vieira (lists) wrote:
>> On 05/06/18 10:42, Kyrill Tkachov wrote:
>>> Hi Andre,
>>>
>>> On 05/06/18 10:40, Andre Vieira (lists) wrote:
 Hi all,

 This patch makes the arm_cmse.h header file ISO C compliant. We were
 using 'typeof' before when we should be using '__typeof__'.
 Duplicated cmse-1.c with -std=c99 on the command line to test this.

 Ran the cmse tests for arm-none-eabi.

 Is this OK for trunk?

>>> I think you forgot to attach the patch.
>>>
>> Someone must have switched my coffee for a decaf...
>>
>> Here it is.Thanks!
>>
>> Cheers,
>> Andre
>>> Kyrill
>>>
 Cheers,
 Andre

 gcc
 2018-06-xx  Andre Vieira 

  * config/arm/arm_cmse.h (cmse_nsfptr_create): Change typeof to
  __typeof__.
  (cmse_check_pointed_opject): Idem.

 gcc/testsuite
 2018-06-xx  Andre Vieira 

  * gcc.target/arm/cmse/cmse-1c99.c: New test.
>
> Thanks, this is ok for trunk.
> Kyrill
>
>
Hi,

Is it OK to backport this to gcc-7?



Ok.
Thanks,
Kyrill


Applies cleanly (after backporting Jerome's arm_cmse.h patch too) and I
ran the cmse tests.

Cheers,
Andre

Re: [PATCH ARM] Fix armv8-m multilib build failure with stdint.h

[Andre Vieira (lists)]

On 17/05/18 09:29, Kyrill Tkachov wrote:
> 
> On 16/05/18 10:22, Jérôme Lambourg wrote:
>> Hello Kyrill,
>>
>>> Thanks for the patch! To validate it your changes you can also look
>>> at the disassembly
>>> of the cmse.c binary in the build tree. If the binary changes with
>>> your patch then that
>>> would indicate some trouble.
>> Good idea. So I just did that and the assembly of both objects are
>> identical
>> (before and after the patch).
>>
>>> There are places in arm_cmse.h that use intptr_t. You should replace
>>> those as well.
>>> Look for the cmse_nsfptr_create and cmse_is_nsfptr macros...
>> Indeed, good catch. I did not see those as this part is not included
>> in the armv8-m.
>>
>> Below the updated patch and modified changelog.
> 
> Thanks this looks good with one nit below.
> 
>> 2018-05-16  Jerome Lambourg  
>> gcc/
>> * config/arm/arm_cmse.h (cmse_nsfptr_create, cmse_is_nsfptr): Remove
>> #include . Replace intptr_t with __INTPTR_TYPE__.
>>
>> libgcc/
>> * config/arm/cmse.c (cmse_check_address_range): Replace
>> UINTPTR_MAX with __UINTPTR_MAX__ and uintptr_t with __UINTPTR_TYPE__.
>>
> 
> @@ -51,7 +51,8 @@
>  
>/* Execute the right variant of the TT instructions.  */
>pe = pb + size - 1;
> -  const int singleCheck = (((uintptr_t) pb ^ (uintptr_t) pe) < 32);
> +  const int singleCheck =
> +(((__UINTPTR_TYPE__) pb ^ (__UINTPTR_TYPE__) pe) < 32);
> 
> The "=" should go on the next line together with the initialisation.
> 
> Ok for trunk with that fixed.
> Thanks,
> Kyrill
Hi,

Is it OK to backport this to gcc-7?

Applies cleanly and I ran the cmse tests.

Cheers,
Andre

Re: [ARM][PATCH] Make arm_cmse.h C99 compatible

[Andre Vieira (lists)]

On 05/06/18 11:18, Kyrill Tkachov wrote:
> 
> On 05/06/18 11:03, Andre Vieira (lists) wrote:
>> On 05/06/18 10:42, Kyrill Tkachov wrote:
>>> Hi Andre,
>>>
>>> On 05/06/18 10:40, Andre Vieira (lists) wrote:
 Hi all,

 This patch makes the arm_cmse.h header file ISO C compliant. We were
 using 'typeof' before when we should be using '__typeof__'.
 Duplicated cmse-1.c with -std=c99 on the command line to test this.

 Ran the cmse tests for arm-none-eabi.

 Is this OK for trunk?

>>> I think you forgot to attach the patch.
>>>
>> Someone must have switched my coffee for a decaf...
>>
>> Here it is.Thanks!
>>
>> Cheers,
>> Andre
>>> Kyrill
>>>
 Cheers,
 Andre

 gcc
 2018-06-xx  Andre Vieira 

  * config/arm/arm_cmse.h (cmse_nsfptr_create): Change typeof to
  __typeof__.
  (cmse_check_pointed_opject): Idem.

 gcc/testsuite
 2018-06-xx  Andre Vieira 

  * gcc.target/arm/cmse/cmse-1c99.c: New test.
> 
> Thanks, this is ok for trunk.
> Kyrill
> 
> 
Hi,

Is it OK to backport this to gcc-7?

Applies cleanly (after backporting Jerome's arm_cmse.h patch too) and I
ran the cmse tests.

Cheers,
Andre

Re: [PATCH, rs6000] Backport Fix implementation of vec_packsu (vector unsigned long long, vector unsigned long long) built-in function

[Kelvin Nilsen]

This has been committed to trunk.

Is this ok to backport to gcc6, gcc7, and gcc8?

Thanks.

On 6/19/18 2:30 PM, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Jun 18, 2018 at 11:29:55AM -0500, Kelvin Nilsen wrote:
>> +/* A single vpkudus matches twice because this is compiled with -dp,
>> +   causing diagnostic comments to appear in the resulting .s file, one
>> +   of which matches vpkudus.  */
> 
> -dp prints the name of the instruction pattern, which is altivec_vpkudus.
> So if you look for the full word instead, this problem isn't there I
> think?
> 
>> +/* { dg-final { scan-assembler-times "vpkudus" 2 } } */
> 
> /* { dg-final { scan-assembler-times {\mvpkudus\M} 1 } } */
> 
> Okay with that change (and comment changes).  Thanks!
> 
> 
> Segher
> 
> 

Re: [PATCH 3/3] Come up with new --completion option.

[David Malcolm]

On Fri, 2018-06-22 at 13:25 +0200, Martin Liška wrote:
> On 06/20/2018 05:27 PM, David Malcolm wrote:
> > On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:

[...snip...]

> > Thanks for working on this; the rest looks good to me (though as I
> > said, I'm not officially a reviewer for this).

FWIW I noticed a few other minor nits in the revised version of the
patch, all just in comments:

> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index dda1fd35398..9e5b153bc53 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -221,6 +221,10 @@ static int print_help_list;
>  
>  static int print_version;
>  
> +/* Flag that stores string value for which we provide bash completion.  */
> +
> +static const char *completion = NULL;
> +

Maybe reword "value" to "prefix" in the above?


[...snip...]

> diff --git a/gcc/selftest.c b/gcc/selftest.c
> index 74adc63e65c..78ae778ca14 100644
> --- a/gcc/selftest.c
> +++ b/gcc/selftest.c
> @@ -125,6 +125,39 @@ assert_str_contains (const location &loc,
>desc_haystack, desc_needle, val_haystack, val_needle);
>  }
>  
> +/* Implementation detail of ASSERT_STR_STARTSWITH.
> +   Use strstr to determine if val_haystack starts with val_needle.
> +   ::selftest::pass if it starts.
> +   ::selftest::fail if it does not start.  */
> +
> +void
> +assert_str_startswith (const location &loc,
> +const char *desc_str,
> +const char *desc_prefix,
> +const char *val_str,
> +const char *val_prefix)
> +{

The above leading comment is out of date, maybe change it to:

/* Implementation detail of ASSERT_STR_STARTSWITH.
   Determine if VAL_STR starts with VAL_PREFIX.
   ::selftest::pass if VAL_STR does start with VAL_PREFIX.
   ::selftest::fail if it does not, or either is NULL (using
   DESC_STR and DESC_PREFIX in the error message).  */


> +/* Evaluate STRING and PREFIX and determine if STRING starts with PREFIX.
> + ::selftest::pass if STRING does start with PREFIX.
> + ::selftest::fail if does not, or either is NULL.  */
> +
> +#define ASSERT_STR_STARTSWITH(STR, PREFIX)   \
> +  SELFTEST_BEGIN_STMT
> \
> +  ::selftest::assert_str_startswith (SELFTEST_LOCATION, #STR, #PREFIX,   
> \
> +  (STR), (PREFIX));  \
> +  SELFTEST_END_STMT
> +

The argnames in the leading comment don't match those in the macro
itself; change the usages of STRING in the leading comment to STR.


Dave

Re: [PATCH] PR libstdc++/83328 add correct basic_string::insert for initializer_list

[Christophe Lyon]

Hi,

On Fri, 22 Jun 2018 at 14:54, Jonathan Wakely  wrote:
>
> On 22/06/18 14:51 +0200, Rainer Orth wrote:
> >Hi Jonathan,
> >
> >> The SSO basic_string has a non-standard insert(iterator, initializer_list)
> >> overload, from a C++0x draft. This adds the correct overload, while also
> >> preserving the old one so that the old symbol is still exported from the
> >> library.
> >>
> >> The COW basic_string doesn't have any of the C++11 changes to the insert
> >> overloads (they all still have non-const iterator parameters and the
> >> ones that should return an iterator still return void). This doesn't
> >> make any change to the COW string.
> >>
> >>  PR libstdc++/83328
> >>  * acinclude.m4 (libtool_VERSION): Bump to 6:26:0.
> >>  * config/abi/pre/gnu.ver: Add GLIBCXX_3.4.26 and export new symbol.
> >>  * configure: Regenerate.
> >>  * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
> >>  (basic_string::insert(const_iterator, initializer_list)): Add.
> >>  [_GLIBCXX_USE_CXX11_ABI && !_GLIBCXX_DEFINING_STRING_INSTANTIATIONS]
> >>  (basic_string::insert(iterator, initializer_list)): Suppress
> >>  definition.
> >>  * include/debug/string (basic_string::insert(iterator, C)): Change
> >>  first parameter to const_iterator.
> >>  (basic_string::insert(iterator, size_type, C)): Likewise. Change
> >>  return type to iterator.
> >>  (basic_string::insert(iterator, InputIterator, InputIterator)):
> >>  Likewise.
> >>  (basic_string::insert(iterator, initializer_list)): Change first
> >>  parameter to const_iterator and return type to iterator.
> >>  * src/c++11/string-inst.cc: Extend comment.
> >>  * testsuite/21_strings/basic_string/modifiers/insert/char/83328.cc:
> >>  New.
> >>  * testsuite/21_strings/basic_string/modifiers/insert/wchar_t/83328.cc:
> >>  New.
> >>  * testsuite/util/testsuite_abi.cc: Add new symbol version.
> >>
> >> Tested x86_64-linux, committed to trunk.
> >
> >it seems a couple of pattners are a bit too tight now in gnu.ver: this
> >caused a couple of failures on 32-bit Solaris and subsequent tests
> >failing to link due to symbols now hidden:
>
> Oops, it's the usual mangling difference for size_t, I'll fix it
> today.
>

I've also noticed a few regressions after this patch on arm:
FAIL:g++.dg/torture/pr60750.C   -O0  (test for excess errors)
FAIL:g++.dg/torture/pr60750.C   -Os  (test for excess errors)
Excess errors:
pr60750.C:(.text._ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EERKS8_OS8_[_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EERKS8_OS8_]+0x24):
undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int,
std::__cxx11::basic_string,
std::allocator > const&)'

FAIL: 21_strings/basic_string/modifiers/64422.cc (test for excess errors)
Excess errors:
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/64422.cc:29:
undefined reference to `std::__cxx11::basic_string, std::allocator
>::insert(__gnu_cxx::__normal_iterator,
std::allocator > >, unsigned int, char)'
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/64422.cc:39:
undefined reference to `std::__cxx11::basic_string, std::allocator
>::insert(__gnu_cxx::__normal_iterator,
std::allocator > >, unsigned int, wchar_t)'
collect2: error: ld returned 1 exit status


FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc (test for
excess errors)
Excess errors:
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc:67:
undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int,
std::__cxx11::basic_string,
std::allocator > const&, unsigned int, unsigned int)'
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc:83:
undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int,
std::__cxx11::basic_string,
std::allocator > const&, unsigned int, unsigned int)'
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc:103:
undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int,
std::__cxx11::basic_string,
std::allocator > const&, unsigned int, unsigned int)'
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc:109:
undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int,
std::__cxx11::basic_string,
std::allocator > const&, unsigned int, unsigned int)'
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc:115:
undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int,
std::__cxx11::basic_string,
std::allocator > const&, unsigned int, unsigned int)'
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc:142:
undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int,
char const*)'
/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.c

Re: [PATCH] PR libstdc++/83328 add correct basic_string::insert for initializer_list

[Jonathan Wakely]

On 22/06/18 13:54 +0100, Jonathan Wakely wrote:

On 22/06/18 14:51 +0200, Rainer Orth wrote:

Hi Jonathan,


The SSO basic_string has a non-standard insert(iterator, initializer_list)
overload, from a C++0x draft. This adds the correct overload, while also
preserving the old one so that the old symbol is still exported from the
library.

The COW basic_string doesn't have any of the C++11 changes to the insert
overloads (they all still have non-const iterator parameters and the
ones that should return an iterator still return void). This doesn't
make any change to the COW string.

PR libstdc++/83328
* acinclude.m4 (libtool_VERSION): Bump to 6:26:0.
* config/abi/pre/gnu.ver: Add GLIBCXX_3.4.26 and export new symbol.
* configure: Regenerate.
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::insert(const_iterator, initializer_list)): Add.
[_GLIBCXX_USE_CXX11_ABI && !_GLIBCXX_DEFINING_STRING_INSTANTIATIONS]
(basic_string::insert(iterator, initializer_list)): Suppress
definition.
* include/debug/string (basic_string::insert(iterator, C)): Change
first parameter to const_iterator.
(basic_string::insert(iterator, size_type, C)): Likewise. Change
return type to iterator.
(basic_string::insert(iterator, InputIterator, InputIterator)):
Likewise.
(basic_string::insert(iterator, initializer_list)): Change first
parameter to const_iterator and return type to iterator.
* src/c++11/string-inst.cc: Extend comment.
* testsuite/21_strings/basic_string/modifiers/insert/char/83328.cc:
New.
* testsuite/21_strings/basic_string/modifiers/insert/wchar_t/83328.cc:
New.
* testsuite/util/testsuite_abi.cc: Add new symbol version.

Tested x86_64-linux, committed to trunk.


it seems a couple of pattners are a bit too tight now in gnu.ver: this
caused a couple of failures on 32-bit Solaris and subsequent tests
failing to link due to symbols now hidden:


Oops, it's the usual mangling difference for size_t, I'll fix it
today.


I'm testing this ...

commit 3c22cca756b18420d042d19fbcc8892c2aa81ea5
Author: Jonathan Wakely 
Date:   Fri Jun 22 14:11:08 2018 +0100

Fix unexported basic_string symbols for 32-bit targets

* config/abi/pre/gnu.ver: Fix __cxx11::basic_string patterns for
different size_t mangling on 32-bit targets.

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index b59b9a0ff1f..782b1238742 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1716,14 +1716,14 @@ GLIBCXX_3.4.21 {
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6append*;
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6assign*;
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertI*;
-_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmPK[cw];
-_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmPK[cw]m;
-_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmRKS4_;
-_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmRKS4_mm;
-_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEmm[cw];
+_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy]PK[cw];
+_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy]PK[cw][jmy];
+_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy]RKS4_;
+_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy]RKS4_[jmy][jmy];
+_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertE[jmy][jmy][cw];
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEN9__gnu_cxx17__normal_iteratorIP[cw]*;
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEN9__gnu_cxx17__normal_iteratorIPK[cw]S4_EE[cw];
-_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEN9__gnu_cxx17__normal_iteratorIPK[cw]S4_EEm[cw];
+_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6insertEN9__gnu_cxx17__normal_iteratorIPK[cw]S4_EE[jmy][cw];
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6rbegin*;
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE6resize*;
 _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE7replace*;

Re: [PATCH] PR libstdc++/70940 make pmr::resource_adaptor return aligned memory

[Jonathan Wakely]

On 22/06/18 13:42 +0100, Jonathan Wakely wrote:

On 22/06/18 14:34 +0200, Rainer Orth wrote:

Hi Jonathan,


PR libstdc++/70940
* include/experimental/memory_resource (__resource_adaptor_common):
New base class.
(__resource_adaptor_common::_AlignMgr): Helper for obtaining aligned
pointer from unaligned, and vice versa.
(__resource_adaptor_imp::do_allocate): Use _AlignMgr to adjust
allocated pointer to meet alignment request.
(__resource_adaptor_imp::do_deallocate): Use _AlignMgr to retrieve
original pointer for deallocation.
(__resource_adaptor_imp::do_is_equal): Reformat.
(__resource_adaptor_imp::_S_aligned_size): Remove.
(__resource_adaptor_imp::_S_supported): Remove.
(new_delete_resource): Use __gnu_cxx::new_allocator.
* testsuite/experimental/memory_resource/resource_adaptor.cc: Test
extended alignments and use debug_allocator to check for matching
allocate/deallocate pairs.

Tested x86_64-linux, committed to trunk. This is more experimental TS
material, so I'll probably backport it.


this patch has cause a couple of FAILures on 32-bit targets/multilibs.
I'm seeing it on i386-pc-solaris2.11 and sparc-sun-solaris2.11, with
gcc-testresults postings to the same effect for
i586-unknown-freebsd10.4, i686-pc-linux-gnu, s390x-ibm-linux-gnu,
x86_64-pc-linux-gnu:

+FAIL: experimental/memory_resource/1.cc (test for excess errors)
+FAIL: experimental/memory_resource/70966.cc (test for excess errors)
+FAIL: experimental/memory_resource/null_memory_resource.cc (test for excess 
errors)
+FAIL: experimental/memory_resource/resource_adaptor.cc (test for excess errors)
+XPASS: experimental/memory_resource/resource_adaptor.cc execution test
+FAIL: experimental/type_erased_allocator/2.cc (test for excess errors)

FAIL: experimental/type_erased_allocator/2.cc (test for excess errors)
Excess errors:
/var/gcc/regression/trunk/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/experimental/memory_resource:329:
 warning: left shift count >= width of type [-Wshift-count-overflow]


David just created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86280

This should fix it. I'll commit it later, or if you want to test and
commit it please go ahead.

--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -326,7 +326,7 @@ namespace pmr {
return 1;
  if (_M_align <= (1ul << (sizeof(short) * __CHAR_BIT__)))
return sizeof(short);
-   if (_M_align <= (1ul << (sizeof(int) * __CHAR_BIT__)))
+   if (_M_align <= (1ull << (sizeof(int) * __CHAR_BIT__)))
return sizeof(int);
  return sizeof(char*);
 }



Committed to trunk.

Re: [PATCH] PR libstdc++/83328 add correct basic_string::insert for initializer_list

[Jonathan Wakely]

On 22/06/18 14:51 +0200, Rainer Orth wrote:

Hi Jonathan,


The SSO basic_string has a non-standard insert(iterator, initializer_list)
overload, from a C++0x draft. This adds the correct overload, while also
preserving the old one so that the old symbol is still exported from the
library.

The COW basic_string doesn't have any of the C++11 changes to the insert
overloads (they all still have non-const iterator parameters and the
ones that should return an iterator still return void). This doesn't
make any change to the COW string.

PR libstdc++/83328
* acinclude.m4 (libtool_VERSION): Bump to 6:26:0.
* config/abi/pre/gnu.ver: Add GLIBCXX_3.4.26 and export new symbol.
* configure: Regenerate.
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::insert(const_iterator, initializer_list)): Add.
[_GLIBCXX_USE_CXX11_ABI && !_GLIBCXX_DEFINING_STRING_INSTANTIATIONS]
(basic_string::insert(iterator, initializer_list)): Suppress
definition.
* include/debug/string (basic_string::insert(iterator, C)): Change
first parameter to const_iterator.
(basic_string::insert(iterator, size_type, C)): Likewise. Change
return type to iterator.
(basic_string::insert(iterator, InputIterator, InputIterator)):
Likewise.
(basic_string::insert(iterator, initializer_list)): Change first
parameter to const_iterator and return type to iterator.
* src/c++11/string-inst.cc: Extend comment.
* testsuite/21_strings/basic_string/modifiers/insert/char/83328.cc:
New.
* testsuite/21_strings/basic_string/modifiers/insert/wchar_t/83328.cc:
New.
* testsuite/util/testsuite_abi.cc: Add new symbol version.

Tested x86_64-linux, committed to trunk.


it seems a couple of pattners are a bit too tight now in gnu.ver: this
caused a couple of failures on 32-bit Solaris and subsequent tests
failing to link due to symbols now hidden:


Oops, it's the usual mangling difference for size_t, I'll fix it
today.

Re: [PATCH] PR libstdc++/83328 add correct basic_string::insert for initializer_list

[Rainer Orth]

Hi Jonathan,

> The SSO basic_string has a non-standard insert(iterator, initializer_list)
> overload, from a C++0x draft. This adds the correct overload, while also
> preserving the old one so that the old symbol is still exported from the
> library.
>
> The COW basic_string doesn't have any of the C++11 changes to the insert
> overloads (they all still have non-const iterator parameters and the
> ones that should return an iterator still return void). This doesn't
> make any change to the COW string.
>
>   PR libstdc++/83328
>   * acinclude.m4 (libtool_VERSION): Bump to 6:26:0.
>   * config/abi/pre/gnu.ver: Add GLIBCXX_3.4.26 and export new symbol.
>   * configure: Regenerate.
>   * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
>   (basic_string::insert(const_iterator, initializer_list)): Add.
>   [_GLIBCXX_USE_CXX11_ABI && !_GLIBCXX_DEFINING_STRING_INSTANTIATIONS]
>   (basic_string::insert(iterator, initializer_list)): Suppress
>   definition.
>   * include/debug/string (basic_string::insert(iterator, C)): Change
>   first parameter to const_iterator.
>   (basic_string::insert(iterator, size_type, C)): Likewise. Change
>   return type to iterator.
>   (basic_string::insert(iterator, InputIterator, InputIterator)):
>   Likewise.
>   (basic_string::insert(iterator, initializer_list)): Change first
>   parameter to const_iterator and return type to iterator.
>   * src/c++11/string-inst.cc: Extend comment.
>   * testsuite/21_strings/basic_string/modifiers/insert/char/83328.cc:
>   New.
>   * testsuite/21_strings/basic_string/modifiers/insert/wchar_t/83328.cc:
>   New.
>   * testsuite/util/testsuite_abi.cc: Add new symbol version.
>
> Tested x86_64-linux, committed to trunk.

it seems a couple of pattners are a bit too tight now in gnu.ver: this
caused a couple of failures on 32-bit Solaris and subsequent tests
failing to link due to symbols now hidden:

+FAIL: libstdc++-abi/abi_check

# of added symbols:  3
# of missing symbols:12
# of undesignated symbols:   0
# of incompatible symbols:   12

3 added symbols 
0
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6insertEN9__gnu_cxx17__normal_iteratorIPKcS4_EESt16initializer_listIcE
std::__cxx11::basic_string, std::allocator 
>::insert(__gnu_cxx::__normal_iterator, std::allocator > 
>, std::initializer_list)
version status: compatible
GLIBCXX_3.4.26
type: function
status: added

1
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE6insertEN9__gnu_cxx17__normal_iteratorIPKwS4_EESt16initializer_listIwE
std::__cxx11::basic_string, 
std::allocator >::insert(__gnu_cxx::__normal_iterator, 
std::allocator > >, std::initializer_list)
version status: compatible
GLIBCXX_3.4.26
type: function
status: added

2
GLIBCXX_3.4.26
version status: compatible
type: object
type size: 0
status: added


12 missing symbols 
0
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE6insertEjRKS4_jj
std::__cxx11::basic_string, 
std::allocator >::insert(unsigned int, 
std::__cxx11::basic_string, 
std::allocator > const&, unsigned int, unsigned int)
version status: unversioned
type: function
status: subtracted

1
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE6insertEjPKwj
std::__cxx11::basic_string, 
std::allocator >::insert(unsigned int, wchar_t const*, unsigned int)
version status: unversioned
type: function
status: subtracted

2
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE6insertEjPKw
std::__cxx11::basic_string, 
std::allocator >::insert(unsigned int, wchar_t const*)
version status: unversioned
type: function
status: subtracted

3
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6insertEN9__gnu_cxx17__normal_iteratorIPKcS4_EEjc
std::__cxx11::basic_string, std::allocator 
>::insert(__gnu_cxx::__normal_iterator, std::allocator > 
>, unsigned int, char)
version status: unversioned
type: function
status: subtracted

4
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE6insertEjjw
std::__cxx11::basic_string, 
std::allocator >::insert(unsigned int, unsigned int, wchar_t)
version status: unversioned
type: function
status: subtracted

5
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6insertEjPKcj
std::__cxx11::basic_string, std::allocator 
>::insert(unsigned int, char const*, unsigned int)
version status: unversioned
type: function
status: subtracted

6
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE6insertEN9__gnu_cxx17__normal_iteratorIPKwS4_EEjw
std::__cxx11::basic_string, 
std::allocator >::insert(__gnu_cxx::__normal_iterator, 
std::allocator > >, unsigned int, wchar_t)
version status: unversioned
type: function
status: subtracted

7
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE6insertEjRKS4_
std::__cxx11::basic_string, 
std::allocator >::insert(unsigned int, 
std::__cxx11::basic_string, 
std::allocator > const&)
version status: unversioned
type: function
status: subtracted

8
_ZNSt7__cxx1112basic_stringIcSt11char_t

Re: [PATCH] PR libstdc++/70940 make pmr::resource_adaptor return aligned memory

[Jonathan Wakely]

On 22/06/18 14:34 +0200, Rainer Orth wrote:

Hi Jonathan,


PR libstdc++/70940
* include/experimental/memory_resource (__resource_adaptor_common):
New base class.
(__resource_adaptor_common::_AlignMgr): Helper for obtaining aligned
pointer from unaligned, and vice versa.
(__resource_adaptor_imp::do_allocate): Use _AlignMgr to adjust
allocated pointer to meet alignment request.
(__resource_adaptor_imp::do_deallocate): Use _AlignMgr to retrieve
original pointer for deallocation.
(__resource_adaptor_imp::do_is_equal): Reformat.
(__resource_adaptor_imp::_S_aligned_size): Remove.
(__resource_adaptor_imp::_S_supported): Remove.
(new_delete_resource): Use __gnu_cxx::new_allocator.
* testsuite/experimental/memory_resource/resource_adaptor.cc: Test
extended alignments and use debug_allocator to check for matching
allocate/deallocate pairs.

Tested x86_64-linux, committed to trunk. This is more experimental TS
material, so I'll probably backport it.


this patch has cause a couple of FAILures on 32-bit targets/multilibs.
I'm seeing it on i386-pc-solaris2.11 and sparc-sun-solaris2.11, with
gcc-testresults postings to the same effect for
i586-unknown-freebsd10.4, i686-pc-linux-gnu, s390x-ibm-linux-gnu,
x86_64-pc-linux-gnu:

+FAIL: experimental/memory_resource/1.cc (test for excess errors)
+FAIL: experimental/memory_resource/70966.cc (test for excess errors)
+FAIL: experimental/memory_resource/null_memory_resource.cc (test for excess 
errors)
+FAIL: experimental/memory_resource/resource_adaptor.cc (test for excess errors)
+XPASS: experimental/memory_resource/resource_adaptor.cc execution test
+FAIL: experimental/type_erased_allocator/2.cc (test for excess errors)

FAIL: experimental/type_erased_allocator/2.cc (test for excess errors)
Excess errors:
/var/gcc/regression/trunk/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/experimental/memory_resource:329:
 warning: left shift count >= width of type [-Wshift-count-overflow]


David just created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86280

This should fix it. I'll commit it later, or if you want to test and
commit it please go ahead.

--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -326,7 +326,7 @@ namespace pmr {
 return 1;
   if (_M_align <= (1ul << (sizeof(short) * __CHAR_BIT__)))
 return sizeof(short);
-   if (_M_align <= (1ul << (sizeof(int) * __CHAR_BIT__)))
+   if (_M_align <= (1ull << (sizeof(int) * __CHAR_BIT__)))
 return sizeof(int);
   return sizeof(char*);
  }

Re: [PATCH] PR libstdc++/70940 make pmr::resource_adaptor return aligned memory

[Rainer Orth]

Hi Jonathan,

>   PR libstdc++/70940
>   * include/experimental/memory_resource (__resource_adaptor_common):
>   New base class.
>   (__resource_adaptor_common::_AlignMgr): Helper for obtaining aligned
>   pointer from unaligned, and vice versa.
>   (__resource_adaptor_imp::do_allocate): Use _AlignMgr to adjust
>   allocated pointer to meet alignment request.
>   (__resource_adaptor_imp::do_deallocate): Use _AlignMgr to retrieve
>   original pointer for deallocation.
>   (__resource_adaptor_imp::do_is_equal): Reformat.
>   (__resource_adaptor_imp::_S_aligned_size): Remove.
>   (__resource_adaptor_imp::_S_supported): Remove.
>   (new_delete_resource): Use __gnu_cxx::new_allocator.
>   * testsuite/experimental/memory_resource/resource_adaptor.cc: Test
>   extended alignments and use debug_allocator to check for matching
>   allocate/deallocate pairs.
>
> Tested x86_64-linux, committed to trunk. This is more experimental TS
> material, so I'll probably backport it.

this patch has cause a couple of FAILures on 32-bit targets/multilibs.
I'm seeing it on i386-pc-solaris2.11 and sparc-sun-solaris2.11, with
gcc-testresults postings to the same effect for
i586-unknown-freebsd10.4, i686-pc-linux-gnu, s390x-ibm-linux-gnu,
x86_64-pc-linux-gnu:

+FAIL: experimental/memory_resource/1.cc (test for excess errors)
+FAIL: experimental/memory_resource/70966.cc (test for excess errors)
+FAIL: experimental/memory_resource/null_memory_resource.cc (test for excess 
errors)
+FAIL: experimental/memory_resource/resource_adaptor.cc (test for excess errors)
+XPASS: experimental/memory_resource/resource_adaptor.cc execution test
+FAIL: experimental/type_erased_allocator/2.cc (test for excess errors)

FAIL: experimental/type_erased_allocator/2.cc (test for excess errors)
Excess errors:
/var/gcc/regression/trunk/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/experimental/memory_resource:329:
 warning: left shift count >= width of type [-Wshift-count-overflow]

Rainer

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

[PATCH][testsuite/guality] Use buildarea gdb by default in combined build

[Tom de Vries]

Hi,

when doing a combined build of gcc and binutils-gdb repos, guality still
uses the gdb in PATH by default.

This patch makes sure that quality uses the gdb from the combined build
instead.

Tested on x86_64.

OK for trunk?

Thanks,
- Tom

[testsuite/guality] Use buildarea gdb by default in combined build

2018-06-22  Tom de Vries  

* g++.dg/guality/guality.exp (guality_gdb_name): Default to
$rootme/../gdb/gdb, if available.
* gcc.dg/guality/guality.exp (guality_gdb_name): Same.
* gfortran.dg/guality/guality.exp (guality_gdb_name): Same.

---
 gcc/testsuite/g++.dg/guality/guality.exp  | 3 +++
 gcc/testsuite/gcc.dg/guality/guality.exp  | 3 +++
 gcc/testsuite/gfortran.dg/guality/guality.exp | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/gcc/testsuite/g++.dg/guality/guality.exp 
b/gcc/testsuite/g++.dg/guality/guality.exp
index 72f23c8cca7..e5eaceedc9a 100644
--- a/gcc/testsuite/g++.dg/guality/guality.exp
+++ b/gcc/testsuite/g++.dg/guality/guality.exp
@@ -38,6 +38,9 @@ global GDB
 if ![info exists ::env(GUALITY_GDB_NAME)] {
 if [info exists GDB] {
set guality_gdb_name "$GDB"
+} elseif [file exists $rootme/../gdb/gdb] {
+   # If we're doing a combined build, and gdb is available, use it.
+   set guality_gdb_name "$rootme/../gdb/gdb"
 } else {
set guality_gdb_name "[transform gdb]"
 }
diff --git a/gcc/testsuite/gcc.dg/guality/guality.exp 
b/gcc/testsuite/gcc.dg/guality/guality.exp
index 7eebd27b544..2a90ec3c8c8 100644
--- a/gcc/testsuite/gcc.dg/guality/guality.exp
+++ b/gcc/testsuite/gcc.dg/guality/guality.exp
@@ -38,6 +38,9 @@ global GDB
 if ![info exists ::env(GUALITY_GDB_NAME)] {
 if [info exists GDB] {
set guality_gdb_name "$GDB"
+} elseif [file exists $rootme/../gdb/gdb] {
+   # If we're doing a combined build, and gdb is available, use it.
+   set guality_gdb_name "$rootme/../gdb/gdb"
 } else {
set guality_gdb_name "[transform gdb]"
 }
diff --git a/gcc/testsuite/gfortran.dg/guality/guality.exp 
b/gcc/testsuite/gfortran.dg/guality/guality.exp
index 62875fd54b8..3784cac1ef3 100644
--- a/gcc/testsuite/gfortran.dg/guality/guality.exp
+++ b/gcc/testsuite/gfortran.dg/guality/guality.exp
@@ -19,6 +19,9 @@ global GDB
 if ![info exists ::env(GUALITY_GDB_NAME)] {
 if [info exists GDB] {
set guality_gdb_name "$GDB"
+} elseif [file exists $rootme/../gdb/gdb] {
+   # If we're doing a combined build, and gdb is available, use it.
+   set guality_gdb_name "$rootme/../gdb/gdb"
 } else {
set guality_gdb_name "[transform gdb]"
 }

Re: [Patch, fortran] PR49630 - [OOP] ICE on obsolescent deferred-length type bound character function

[Martin Liška]

On 06/21/2018 05:25 PM, Steve Kargl wrote:
> On Thu, Jun 21, 2018 at 09:03:47AM +0100, Paul Richard Thomas wrote:
>> Ping!
>>
>>> 2018-06-19  Paul Thomas  
>>>
>>> PR fortran/49630
>>> * resolve.c (resolve_contained_fntype): Change standard ref.
>>> from F95 to F2003: C418. Correct a spelling error in a comment.
>>> It is an error for an abstract interface to have an assumed
>>> character length result.
>>> * trans-expr.c (gfc_conv_procedure_call): Likewise change the
>>> standard reference.
>>>
>>> 2018-06-19  Paul Thomas  
>>>
>>> PR fortran/49630
>>> * gfortran.dg/assumed_charlen_function_7.f90: New test.
> 
> OK.
> 

Hi.

If I see correctly it caused:

$ ./xgcc -B. 
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/typebound_proc_35.f90 -c
f951: internal compiler error: Segmentation fault
0x10d0b55 crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:324
0x76d8ba6f ???

/usr/src/debug/glibc-2.27-5.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x916122 resolve_function
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:3119
0x91e829 gfc_resolve_expr(gfc_expr*)
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:6741
0x91d7b8 resolve_compcall
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:6299
0x91dbb5 resolve_typebound_function
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:6408
0x91e89f gfc_resolve_expr(gfc_expr*)
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:6752
0x928b2a gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:11137
0x9364ad resolve_codes
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:16581
0x93638b resolve_codes
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:16565
0x9365d7 gfc_resolve(gfc_namespace*)
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:16616
0x9070f9 gfc_parse_file()
/home/marxin/Programming/gcc/gcc/fortran/parse.c:6266
0x962a81 gfc_be_parse_file
/home/marxin/Programming/gcc/gcc/fortran/f95-lang.c:204

and some other ICEs:

FAIL: gfortran.dg/actual_array_offset_1.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
error)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
errors)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/actual_array_offset_1.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/actual_array_offset_1.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/actual_array_offset_1.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/assumed_charlen_function_7.f90   -O  (test for excess errors)
FAIL: gfortran.dg/interface_abstract_4.f90   -O  (internal compiler error)
FAIL: gfortran.dg/interface_abstract_4.f90   -O  (test for excess errors)
FAIL: gfortran.dg/typebound_proc_35.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_35.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/typebound_proc_35.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_35.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/typebound_proc_35.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_35.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/typebound_proc_35.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
error)
FAIL: gfortran.dg/typebound_proc_35.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
errors)
FAIL: gfortran.dg/typebound_proc_35.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_35.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/typebound_proc_35.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_35.f90   -Os  (test for excess errors)

Martin

[PATCH][testsuite/guality] Be verbose about gdb version used

[Tom de Vries]

Hi,

by default, guality invokes gdb with --quiet to avoid being unnecessarily
verbose for each test.  But as a consequence, we don't see which version of
gdb is used.

This patch adds printing of the full path to the gdb used, as well as the
gdb version as printed by gdb.

Tested on x86_64.

OK for trunk?

Thanks,
- Tom

[testsuite/guality] Be verbose about gdb version used

2018-06-22  Tom de Vries  

* lib/gcc-gdb-test.exp (report_gdb): New proc.
* g++.dg/guality/guality.exp: Use report_gdb.
* gcc.dg/guality/guality.exp: Same.
* gfortran.dg/guality/guality.exp: Same.

---
 gcc/testsuite/g++.dg/guality/guality.exp  |  1 +
 gcc/testsuite/gcc.dg/guality/guality.exp  |  1 +
 gcc/testsuite/gfortran.dg/guality/guality.exp |  1 +
 gcc/testsuite/lib/gcc-gdb-test.exp| 10 ++
 4 files changed, 13 insertions(+)

diff --git a/gcc/testsuite/g++.dg/guality/guality.exp 
b/gcc/testsuite/g++.dg/guality/guality.exp
index 5bffd9df1a0..72f23c8cca7 100644
--- a/gcc/testsuite/g++.dg/guality/guality.exp
+++ b/gcc/testsuite/g++.dg/guality/guality.exp
@@ -43,6 +43,7 @@ if ![info exists ::env(GUALITY_GDB_NAME)] {
 }
 setenv GUALITY_GDB_NAME "$guality_gdb_name"
 }
+report_gdb [exec which $::env(GUALITY_GDB_NAME)] [info script]
 
 if {[check_guality "
   #include \"$srcdir/$subdir/guality.h\"
diff --git a/gcc/testsuite/gcc.dg/guality/guality.exp 
b/gcc/testsuite/gcc.dg/guality/guality.exp
index d2b863397ba..7eebd27b544 100644
--- a/gcc/testsuite/gcc.dg/guality/guality.exp
+++ b/gcc/testsuite/gcc.dg/guality/guality.exp
@@ -43,6 +43,7 @@ if ![info exists ::env(GUALITY_GDB_NAME)] {
 }
 setenv GUALITY_GDB_NAME "$guality_gdb_name"
 }
+report_gdb [exec which $::env(GUALITY_GDB_NAME)] [info script]
 
 if {[check_guality "
   #include \"$srcdir/$subdir/guality.h\"
diff --git a/gcc/testsuite/gfortran.dg/guality/guality.exp 
b/gcc/testsuite/gfortran.dg/guality/guality.exp
index 3f96a04bd26..62875fd54b8 100644
--- a/gcc/testsuite/gfortran.dg/guality/guality.exp
+++ b/gcc/testsuite/gfortran.dg/guality/guality.exp
@@ -24,6 +24,7 @@ if ![info exists ::env(GUALITY_GDB_NAME)] {
 }
 setenv GUALITY_GDB_NAME "$guality_gdb_name"
 }
+report_gdb [exec which $::env(GUALITY_GDB_NAME)] [info script]
 
 gfortran-dg-runtest [lsort [glob $srcdir/$subdir/*.\[fF\]{,90,95,03,08} ]] "" 
""
 
diff --git a/gcc/testsuite/lib/gcc-gdb-test.exp 
b/gcc/testsuite/lib/gcc-gdb-test.exp
index 0c4d2a533f6..f3726635c03 100644
--- a/gcc/testsuite/lib/gcc-gdb-test.exp
+++ b/gcc/testsuite/lib/gcc-gdb-test.exp
@@ -139,3 +139,13 @@ proc gdb-test { args } {
 file delete $cmd_file
 return
 }
+
+# Report the gdb path and version log the .log file
+# Argument 0 is the gdb path
+# Argument 1 is the location where gdb is used
+# 
+proc report_gdb { gdb loc } {
+send_log "gdb used in $loc: $gdb\n"
+set gdb_version [exec $gdb -v]
+send_log "gdb used in $loc: version:\n---\n$gdb_version\n---\n"
+}

Re: [PATCH 3/3] Come up with new --completion option.

[Martin Liška]

On 06/20/2018 05:27 PM, David Malcolm wrote:
> On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
>> Main part where I still need to write ChangeLog file and
>> gcc.sh needs to be moved to bash-completions project.
>>
>> Martin
> 
> As before, I'm not an official reviewer for it, but it touches code
> that I wrote, so here goes.
> 
> Overall looks good to me, but I have some nitpicks:
> 
> (needs a ChangeLog)

Added.

> 
> [...snip gcc.sh change; I don't feel qualified to comment...]
> 
> [...snip sane-looking changes to common.opt and gcc.c.  */
>  
> diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c
> index e322fcd91c5..2da094a5960 100644
> --- a/gcc/opt-suggestions.c
> +++ b/gcc/opt-suggestions.c
> @@ -28,18 +28,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "opt-suggestions.h"
>  #include "selftest.h"
>  
> -option_proposer::~option_proposer ()
> -{
> -  if (m_option_suggestions)
> -{
> -  int i;
> -  char *str;
> -  FOR_EACH_VEC_ELT (*m_option_suggestions, i, str)
> -   free (str);
> -  delete m_option_suggestions;
> -}
> -}
> 
> Why is this dtor going away?  If I'm reading the patch correctly,
> option_proposer still "owns" m_option_suggestions.
> 
> What happens if you run "make selftest-valgrind" ?  (my guess is some
> new memory leaks)

Fixed that, should not be removed.

>  
> +void
> +option_proposer::get_completions (const char *option_prefix,
> +   auto_string_vec &results)
> 
> Missing leading comment.  Maybe something like:
> 
> /* Populate RESULTS with valid completions of options that begin
>with OPTION_PREFIX.  */
> 
> or somesuch.
> 
> +{
> +  /* Bail out for an invalid input.  */
> +  if (option_prefix == NULL || option_prefix[0] == '\0')
> +return;
> +
> +  /* Option suggestions are built without first leading dash character.  */
> +  if (option_prefix[0] == '-')
> +option_prefix++;
> +
> +  size_t length = strlen (option_prefix);
> +
> +  /* Handle parameters.  */
> +  const char *prefix = "-param";
> +  if (length >= strlen (prefix)
> +  && strstr (option_prefix, prefix) == option_prefix)
> 
> Maybe reword that leading comment to
> 
>/* Handle OPTION_PREFIX starting with "-param".  */
> 
> (or somesuch) to clarify the intent?

Thanks, done.

> 
> [...snip...]
> 
> +void
> +option_proposer::suggest_completion (const char *option_prefix)
> +{
> 
> Missing leading comment.  Maybe something like:
> 
> /* Print on stdout a list of valid options that begin with OPTION_PREFIX,
>one per line, suitable for use by Bash completion.
> 
>Implementation of the "-completion=" option.  */
> 
> or somesuch.

Likewise.

> 
> [...snip...]
> 
> +void
> +option_proposer::find_param_completions (const char separator,
> +  const char *option_prefix,
> +  auto_string_vec &results)
> 
> Maybe rename "option_prefix" to "param_prefix"?  I believe it's now
> the prefix of the param name, rather than the option.

Makes sense.

> 
> Missing leading comment.  Maybe something like:
> 
> /* Populate RESULTS with bash-completions options for all parameters
>that begin with PARAM_PREFIX, using SEPARATOR.

It's in header file, thus I copied that.

> 
>For example, if PARAM_PREFIX is "max-" and SEPARATOR is "=" then
>strings of the form:
>  "--param=max-unrolled-insns"
>  "--param=max-early-inliner-iterations"
>will be added to RESULTS.  */
> 
> (did I get that right?)

Yes.

> 
> +{
> +  char separator_str[] {separator, '\0'};
> 
> Is the above initialization valid C++98, or is it a C++11-ism?

You are right. I fixed that and 2 more occurrences of the same
issue.

> 
> +  size_t length = strlen (option_prefix);
> +  for (unsigned i = 0; i < get_num_compiler_params (); ++i)
> +{
> +  const char *candidate = compiler_params[i].option;
> +  if (strlen (candidate) >= length
> +   && strstr (candidate, option_prefix) == candidate)
> + results.safe_push (concat ("--param", separator_str, candidate, NULL));
> +}
> +}
> +
> +#if CHECKING_P
> +
> +namespace selftest {
> +
> +/* Verify that PROPOSER generates sane auto-completion suggestions
> +   for OPTION_PREFIX.  */
> +static void
> +verify_autocompletions (option_proposer &proposer, const char *option_prefix)
> +{
> +  auto_string_vec suggestions;
> +  proposer.get_completions (option_prefix, suggestions);
> 
> 
> Maybe a comment here to specify:
> 
>/* There must be at least one suggestion, and every suggestion must
>   indeed begin with OPTION_PREFIX.  */

Yes!

> 
> +  ASSERT_GT (suggestions.length (), 0);
> +
> +  for (unsigned i = 0; i < suggestions.length (); i++)
> +ASSERT_STR_STARTSWITH (suggestions[i], option_prefix);
> +}
> 
> [...snip...]
> 
> diff --git a/gcc/opt-suggestions.h b/gcc/opt-suggestions.h
> index 5e3ee9e2671..d0c32af7e5c 100644
> --- a/gcc/opt-suggestions.h
> +++ b/gcc/opt-suggestions.h
> @@ -33,9 +33,6 @

Add support for dumping multiple dump files under one name

[Jan Hubicka]

Hi,
this patch adds dumpfile support for dumps that come in multiple parts.  This
is needed for WPA stream-out dump since we stream partitions in parallel and
the dumps would come up in random order.  Parts are added by new parameter that
is initialzed by default to -1 (no parts). 

One thing I skipped is any support for duplicated opening of file
with parts since I do not need it.

Bootstrapped/regtested x86_64-linux, OK?

Honza

* dumpfile.c (gcc::dump_manager::get_dump_file_name): Add PART
 parameter.
(gcc::dump_manager::get_dump_file_name): likewise.
(dump_begin): Likewise.
* dumpfile.h (dump_begin): Update prototype.
(gcc::dump_manager::get_dump_file_name,
gcc::dump_manager::get_dump_file_name): Update prototype.
Index: dumpfile.c
===
--- dumpfile.c  (revision 261885)
+++ dumpfile.c  (working copy)
@@ -269,7 +269,7 @@ get_dump_file_info_by_switch (const char
 
 char *
 gcc::dump_manager::
-get_dump_file_name (int phase) const
+get_dump_file_name (int phase, int part) const
 {
   struct dump_file_info *dfi;
 
@@ -278,7 +278,7 @@ get_dump_file_name (int phase) const
 
   dfi = get_dump_file_info (phase);
 
-  return get_dump_file_name (dfi);
+  return get_dump_file_name (dfi, part);
 }
 
 /* Return the name of the dump file for the given dump_file_info.
@@ -288,7 +288,7 @@ get_dump_file_name (int phase) const
 
 char *
 gcc::dump_manager::
-get_dump_file_name (struct dump_file_info *dfi) const
+get_dump_file_name (struct dump_file_info *dfi, int part) const
 {
   char dump_id[10];
 
@@ -312,7 +312,14 @@ get_dump_file_name (struct dump_file_inf
dump_id[0] = '\0';
 }
 
-  return concat (dump_base_name, dump_id, dfi->suffix, NULL);
+  if (part != -1)
+{
+   char part_id[8];
+   snprintf (part_id, sizeof (part_id), ".%i", part);
+   return concat (dump_base_name, dump_id, part_id, dfi->suffix, NULL);
+}
+  else
+return concat (dump_base_name, dump_id, dfi->suffix, NULL);
 }
 
 /* Open a dump file called FILENAME.  Some filenames are special and
@@ -592,17 +599,19 @@ dump_finish (int phase)
 /* Begin a tree dump for PHASE. Stores any user supplied flag in
*FLAG_PTR and returns a stream to write to. If the dump is not
enabled, returns NULL.
-   Multiple calls will reopen and append to the dump file.  */
+   PART can be used for dump files which should be split to multiple
+   parts. PART == -1 indicates dump file with no parts.
+   If PART is -1, multiple calls will reopen and append to the dump file.  */
 
 FILE *
-dump_begin (int phase, dump_flags_t *flag_ptr)
+dump_begin (int phase, dump_flags_t *flag_ptr, int part)
 {
-  return g->get_dumps ()->dump_begin (phase, flag_ptr);
+  return g->get_dumps ()->dump_begin (phase, flag_ptr, part);
 }
 
 FILE *
 gcc::dump_manager::
-dump_begin (int phase, dump_flags_t *flag_ptr)
+dump_begin (int phase, dump_flags_t *flag_ptr, int part)
 {
   char *name;
   struct dump_file_info *dfi;
@@ -611,12 +620,14 @@ dump_begin (int phase, dump_flags_t *fla
   if (phase == TDI_none || !dump_phase_enabled_p (phase))
 return NULL;
 
-  name = get_dump_file_name (phase);
+  name = get_dump_file_name (phase, part);
   if (!name)
 return NULL;
   dfi = get_dump_file_info (phase);
 
-  stream = dump_open (name, dfi->pstate < 0);
+  /* We do not support re-opening of dump files with parts.  This would require
+ tracking pstate per part of the dump file.  */
+  stream = dump_open (name, part != -1 || dfi->pstate < 0);
   if (stream)
 dfi->pstate = 1;
   free (name);
Index: dumpfile.h
===
--- dumpfile.h  (revision 261885)
+++ dumpfile.h  (working copy)
@@ -269,7 +269,7 @@ struct dump_file_info
 };
 
 /* In dumpfile.c */
-extern FILE *dump_begin (int, dump_flags_t *);
+extern FILE *dump_begin (int, dump_flags_t *, int part=-1);
 extern void dump_end (int, FILE *);
 extern int opt_info_switch_p (const char *);
 extern const char *dump_flag_name (int);
@@ -343,10 +343,10 @@ public:
   /* Return the name of the dump file for the given phase.
  If the dump is not enabled, returns NULL.  */
   char *
-  get_dump_file_name (int phase) const;
+  get_dump_file_name (int phase, int part = -1) const;
 
   char *
-  get_dump_file_name (struct dump_file_info *dfi) const;
+  get_dump_file_name (struct dump_file_info *dfi, int part = -1) const;
 
   int
   dump_switch_p (const char *arg);
@@ -365,7 +365,7 @@ public:
   dump_finish (int phase);
 
   FILE *
-  dump_begin (int phase, dump_flags_t *flag_ptr);
+  dump_begin (int phase, dump_flags_t *flag_ptr, int part);
 
   /* Returns nonzero if tree dump PHASE has been initialized.  */
   int

Re: [PATCH 2/3] Refactoring to opt-suggestions.[ch].

[Martin Liška]

On 06/20/2018 04:57 PM, David Malcolm wrote:
> On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
>> Second part refactors function from gcc.c into a new class
>> option_proposer.
>>
>> Martin
> 
> [...snip...]
> 
> diff --git a/gcc/c-family/cppspec.c b/gcc/c-family/cppspec.c
> index 1e0a8bcd294..66540239f53 100644
> --- a/gcc/c-family/cppspec.c
> +++ b/gcc/c-family/cppspec.c
> @@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "system.h"
>  #include "coretypes.h"
>  #include "tm.h"
> +#include "opt-suggestions.h"
>  #include "gcc.h"
> 
> I'm not a reviewer for this, and I don't know what our policy here is,
> but please can we make "gcc.h" self-contained, and have it include this
> the header it needs, rather than have every file that includes "gcc.h"
> need to know what includes gcc.h might need.  Seems like a violation of
> the DRY principle.

You mean here including "opt-suggestions.h" in "gcc.h"? I believe we have
still the rule to not include a header from header file :/

> 
> [...snip more examples of added headers...]
> 
> [...snip changes to gcc.c and gcc.h which I can't approve but which
>  look sane to me...]
> 
> [...snip more examples of added headers...]
> 
> diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c
> 
> [...snip...]
> 
> +option_proposer::~option_proposer ()
> +{
> +  if (m_option_suggestions)
> +{
> +  int i;
> +  char *str;
> +  FOR_EACH_VEC_ELT (*m_option_suggestions, i, str)
> +   free (str);
> +  delete m_option_suggestions;
> +}
> +}
> 
> Could m_option_suggestions be a
>   auto_string_vec *m_option_suggestions;
> rather than a:
>   auto_vec  *m_option_suggestions;

Yes.

> ?
> 
> If so, then this dtor's body could simply be:
> 
>  option_proposer::~option_proposer ()
>  {
>delete m_option_suggestions;
>  }

Sure.

> 
> [...snip...]
> 
> Everything else looks sane to me (I'm not a reviewer, but I
> wrote much of the code you're touching).
> 
> Dave
> 

I'm attaching updated version.

Martin
>From c76e1f0913e3b925516a79ade51a37f496bd2081 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 14 May 2018 11:47:08 +0200
Subject: [PATCH] Refactoring to opt-suggestions.[ch].

gcc/ChangeLog:

2018-05-14  Martin Liska  

	* Makefile.in: Add opt-suggestions.o.
	* gcc-main.c: Include opt-suggestions.h.
	* gcc.c (driver::driver): Likewise.
	(driver::~driver): Remove m_option_suggestions.
	(driver::build_option_suggestions): Moved to option_proposer.
	(driver::suggest_option): Likewise.
	(driver::handle_unrecognized_options): Use option_proposer.
	* gcc.h (class driver): Add new memver m_option_proposer.
	* opt-suggestions.c: New file.
	* opt-suggestions.h: New file.

gcc/c-family/ChangeLog:

2018-05-14  Martin Liska  

	* cppspec.c: Include opt-suggestions.h.

gcc/fortran/ChangeLog:

2018-05-14  Martin Liska  

	* gfortranspec.c: Include opt-suggestions.h.

gcc/jit/ChangeLog:

2018-05-14  Martin Liska  

	* jit-playback.c: Include opt-suggestions.h.
---
 gcc/Makefile.in|   2 +-
 gcc/c-family/cppspec.c |   1 +
 gcc/fortran/gfortranspec.c |   1 +
 gcc/gcc-main.c |   1 +
 gcc/gcc.c  | 114 +-
 gcc/gcc.h  |   4 +-
 gcc/jit/jit-playback.c |   1 +
 gcc/opt-suggestions.c  | 122 +
 gcc/opt-suggestions.h  |  59 ++
 9 files changed, 190 insertions(+), 115 deletions(-)
 create mode 100644 gcc/opt-suggestions.c
 create mode 100644 gcc/opt-suggestions.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index d8f3e886118..4cc184415fa 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1613,7 +1613,7 @@ OBJS-libcommon = diagnostic.o diagnostic-color.o diagnostic-show-locus.o \
 # compiler and containing target-dependent code.
 OBJS-libcommon-target = $(common_out_object_file) prefix.o params.o \
 	opts.o opts-common.o options.o vec.o hooks.o common/common-targhooks.o \
-	hash-table.o file-find.o spellcheck.o selftest.o
+	hash-table.o file-find.o spellcheck.o selftest.o opt-suggestions.o
 
 # This lists all host objects for the front ends.
 ALL_HOST_FRONTEND_OBJS = $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
diff --git a/gcc/c-family/cppspec.c b/gcc/c-family/cppspec.c
index 1e0a8bcd294..66540239f53 100644
--- a/gcc/c-family/cppspec.c
+++ b/gcc/c-family/cppspec.c
@@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
+#include "opt-suggestions.h"
 #include "gcc.h"
 #include "opts.h"
 
diff --git a/gcc/fortran/gfortranspec.c b/gcc/fortran/gfortranspec.c
index fe1ec0447b3..4ba3a8dba60 100644
--- a/gcc/fortran/gfortranspec.c
+++ b/gcc/fortran/gfortranspec.c
@@ -47,6 +47,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
+#include "opt-suggestions.h"
 #include "gcc.h"
 #include "opts.h"
 
diff --git a/gcc/gcc-main.c b/gcc/gcc-main.c
index 

Re: [PATCH 1/3] Introduce auto_string_vec class.

[Martin Liška]

On 06/20/2018 04:41 PM, David Malcolm wrote:
> On Mon, 2018-05-14 at 14:50 +0200, Martin Liška wrote:
>> First part with introduction of auto_string_vec class.
>>
> 
> FWIW, I'm fine with the changes to the jit subdir, but I don't think I
> have approval rights on the vec.h changes.

Hi.

Good, I'll wait a review from a global reviewer.

> 
> BTW, was the move of vec_alloc in vec.h intentional?  (I take it that
> it's the same before/after, but it seems to have added some churn to
> the vec.h part of the patch).

It's not intentional, fixed in attached patch.

Martin

> 
> Dave
> 

>From abd1b31ec6807d101bbf868acfbdf3bd02319463 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 14 May 2018 14:00:07 +0200
Subject: [PATCH] Introduce auto_string_vec class.

gcc/ChangeLog:

2018-05-14  Martin Liska  

	* vec.h (class auto_string_vec): New (moved from auto_argvec).
	(auto_string_vec::~auto_string_vec): Likewise.

gcc/jit/ChangeLog:

2018-05-14  Martin Liska  

	* jit-playback.c (class auto_argvec): Moved to vec.h.
	(auto_argvec::~auto_argvec): Likewise.
	(compile): Use the renamed name.
	(invoke_driver): Likewise.
---
 gcc/jit/jit-playback.c | 24 ++--
 gcc/vec.h  | 21 +
 2 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 258ebe8ef86..01c4567de05 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -1749,26 +1749,6 @@ block (function *func,
   m_label_expr = NULL;
 }
 
-/* A subclass of auto_vec  that frees all of its elements on
-   deletion.  */
-
-class auto_argvec : public auto_vec 
-{
- public:
-  ~auto_argvec ();
-};
-
-/* auto_argvec's dtor, freeing all contained strings, automatically
-   chaining up to ~auto_vec , which frees the internal buffer.  */
-
-auto_argvec::~auto_argvec ()
-{
-  int i;
-  char *str;
-  FOR_EACH_VEC_ELT (*this, i, str)
-free (str);
-}
-
 /* Compile a playback::context:
 
- Use the context's options to cconstruct command-line options, and
@@ -1822,7 +1802,7 @@ compile ()
   /* Acquire the JIT mutex and set "this" as the active playback ctxt.  */
   acquire_mutex ();
 
-  auto_argvec fake_args;
+  auto_string_vec fake_args;
   make_fake_args (&fake_args, ctxt_progname, &requested_dumps);
   if (errors_occurred ())
 {
@@ -2440,7 +2420,7 @@ invoke_driver (const char *ctxt_progname,
   /* Currently this lumps together both assembling and linking into
  TV_ASSEMBLE.  */
   auto_timevar assemble_timevar (get_timer (), tv_id);
-  auto_argvec argvec;
+  auto_string_vec argvec;
 #define ADD_ARG(arg) argvec.safe_push (xstrdup (arg))
 
   ADD_ARG (gcc_driver_name);
diff --git a/gcc/vec.h b/gcc/vec.h
index a9f3bcf09eb..0af5187782e 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1462,6 +1462,15 @@ vec_alloc (vec *&v, unsigned nelems CXX_MEM_STAT_INFO)
 }
 
 
+/* A subclass of auto_vec  that frees all of its elements on
+   deletion.  */
+
+class auto_string_vec : public auto_vec 
+{
+ public:
+  ~auto_string_vec ();
+};
+
 /* Conditionally allocate heap memory for VEC and its internal vector.  */
 
 template
@@ -1554,6 +1563,18 @@ vec::iterate (unsigned ix, T **ptr) const
vec_safe_iterate ((V), (I), &(P));	\
(I)--)
 
+/* auto_string_vec's dtor, freeing all contained strings, automatically
+   chaining up to ~auto_vec , which frees the internal buffer.  */
+
+inline
+auto_string_vec::~auto_string_vec ()
+{
+  int i;
+  char *str;
+  FOR_EACH_VEC_ELT (*this, i, str)
+free (str);
+}
+
 
 /* Return a copy of this vector.  */
 
-- 
2.17.1

[PATCH][3/3] Consider multiple vector sizes for vectorization based on cost

[Richard Biener]

The following makes the vectorizer consider all vector sizes as advertised
by targetm.vectorize.autovectorize_vector_sizes and decide on which
vector size to use based on costs.

Given comparing costs is difficult if you do not know the number of
scalar iterations the patch simply uses the cost of a single vector
iteration (weighted by vectorization factor) to decide which variant
is better.  For this we compute this cost also for -fno-vect-cost-model
(so even with that you'll get the vectorizer choose between sizes)
and store it in a new LOOP_VINFO_SINGLE_VECTOR_ITERATION_COST.

Otherwise this is straight-forward and doesn't really depend on
dataref/ddr analysis sharing (but that makes it less costly).

Bootstrap / regtest pending on x86_64-unknown-linux-gnu.

Richard.

>From 4234213fcd5e6fe844bc1171938e12ab189ef290 Mon Sep 17 00:00:00 2001
From: Richard Guenther 
Date: Thu, 21 Jun 2018 13:40:14 +0200
Subject: [PATCH] try-multiple-vector-sizes-and-compare-costs

2018-06-22  Richard Biener  

* tree-vectorizer.h (struct _loop_vec_info): Add
single_vector_iteration_cost member.
(LOOP_VINFO_SINGLE_VECTOR_ITERATION_COST): New.
* tree-vect-loop.c (_loop_vec_info::~_loop_vec_info): Do not
reset loop->aux here.
(vect_analyze_loop_form): Do not assert or set loop->aux here.
(vect_analyze_loop): Iterate over all vector sizes and decide
based on the vector iteration cost which one to use.
(vect_estimate_min_profitable_iters): Move check for
unlimited cost model later to not skip cost computation or
dumping.  Set LOOP_VINFO_SINGLE_VECTOR_ITERATION_COST.
(vect_create_epilog_for_reduction): Use loop_vinfo rather
than loop_vec_info_for_loop.

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index dacc8811636..0c2ab57bb20 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -947,8 +947,6 @@ _loop_vec_info::~_loop_vec_info ()
 
   release_vec_loop_masks (&masks);
   delete ivexpr_map;
-
-  loop->aux = NULL;
 }
 
 /* Return an invariant or register for EXPR and emit necessary
@@ -1395,8 +1393,6 @@ vect_analyze_loop_form (struct loop *loop, 
vec_info_shared *shared)
 STMT_VINFO_TYPE (vinfo_for_stmt (inner_loop_cond))
   = loop_exit_ctrl_vec_info_type;
 
-  gcc_assert (!loop->aux);
-  loop->aux = loop_vinfo;
   return loop_vinfo;
 }
 
@@ -2285,7 +2281,6 @@ loop_vec_info
 vect_analyze_loop (struct loop *loop, loop_vec_info orig_loop_vinfo,
   vec_info_shared *shared)
 {
-  loop_vec_info loop_vinfo;
   auto_vector_sizes vector_sizes;
 
   /* Autodetect first vector size we try.  */
@@ -2316,11 +2311,12 @@ vect_analyze_loop (struct loop *loop, loop_vec_info 
orig_loop_vinfo,
 }
 
   unsigned n_stmts;
+  auto_vec > loop_vinfos;
   poly_uint64 autodetected_vector_size = 0;
   while (1)
 {
   /* Check the CFG characteristics of the loop (nesting, entry/exit).  */
-  loop_vinfo = vect_analyze_loop_form (loop, shared);
+  loop_vec_info loop_vinfo = vect_analyze_loop_form (loop, shared);
   if (!loop_vinfo)
{
  if (dump_enabled_p ())
@@ -2338,10 +2334,24 @@ vect_analyze_loop (struct loop *loop, loop_vec_info 
orig_loop_vinfo,
{
  LOOP_VINFO_VECTORIZABLE_P (loop_vinfo) = 1;
 
- return loop_vinfo;
+ loop_vinfos.safe_push (std::make_pair (loop_vinfo,
+current_vector_size));
}
+  else
+   delete loop_vinfo;
 
-  delete loop_vinfo;
+  /* If all vector sizes are going to fail or if we didn't end up
+ with any vector fail.  */
+  if (fatal
+ || known_eq (current_vector_size, 0U))
+   {
+ /* With gathers/scatters we can end up claiming dataref analysis
+failed for one but not the other vector size so we can't
+really trust "fatal" here and assert loop_vinfos has length
+zero.  Still stop looking for other vector sizes since that
+is what we've done before.  */
+ break;
+   }
 
   if (next_size == 0)
autodetected_vector_size = current_vector_size;
@@ -2350,10 +2360,8 @@ vect_analyze_loop (struct loop *loop, loop_vec_info 
orig_loop_vinfo,
  && known_eq (vector_sizes[next_size], autodetected_vector_size))
next_size += 1;
 
-  if (fatal
- || next_size == vector_sizes.length ()
- || known_eq (current_vector_size, 0U))
-   return NULL;
+  if (next_size == vector_sizes.length ())
+   break;
 
   /* Try the next biggest vector size.  */
   current_vector_size = vector_sizes[next_size++];
@@ -2366,6 +2374,30 @@ vect_analyze_loop (struct loop *loop, loop_vec_info 
orig_loop_vinfo,
  dump_printf (MSG_NOTE, "\n");
}
 }
+
+  if (loop_vinfos.is_empty ())
+return NULL;
+
+  /* Go over vinfos, selecting the one with best cost.  */
+  loop_vec_info loop_vinfo = loop_vinfos[0].first;
+  cu

[PATCH][2/3] Share dataref and dependence analysis for multi-vector size vectorization

[Richard Biener]

This is the main part to make considering multiple vector sizes based on
costs less compile-time costly.  It shares dataref analysis and
dependence analysis for loop vectorization (BB vectorization is only
adjusted to comply with the new APIs sofar).

Sharing means that DRs (and of course DDRs) may not be modified during
vectorization analysis which means splitting out dataref_aux from
dangling from dr->aux to separate copies in the DR_STMTs vinfo.
I've put measures in place that assure that DRs are not modified
(because they were) but refrained from doing the same for DDRs
(because I didn't run into any issues).

The sharing then is accomplished by moving the dataref and
ddr array as well as the dependent loop-nest array into a
separate structure with bigger lifetime than vinfo and appropriately
link to it from there.

Bootstrapped on x86_64-unknown-linux-gnu (together with [1/3]),
testing in progress.

Richard.

>From 2ef07d775e4eef1b52a77cb9ecd65c37e9f73d95 Mon Sep 17 00:00:00 2001
From: Richard Guenther 
Date: Mon, 18 Jun 2018 15:21:22 +0200
Subject: [PATCH] share-dr-and-ddr-analysis

2018-06-22  Richard Biener  

* tree-vectorizer.h (struct vec_info_shared): New structure
with parts split out from struct vec_info and loop_nest from
struct _loop_vec_info.
(struct vec_info): Adjust accordingly.
(struct _loop_vec_info): Likewise.
(LOOP_VINFO_LOOP_NEST): Adjust.
(LOOP_VINFO_DATAREFS): Likewise.
(LOOP_VINFO_DDRS): Likewise.
(struct _bb_vec_info): Likewise.
(BB_VINFO_DATAREFS): Likewise.
(BB_VINFO_DDRS): Likewise.
(struct _stmt_vec_info): Add dr_aux member.
(DR_VECT_AUX): Adjust to refer to member of DR_STMTs vinfo.
(DR_MISALIGNMENT_UNINITIALIZED): New.
(set_dr_misalignment): Adjust.
(dr_misalignment): Assert misalign isn't DR_MISALIGNMENT_UNINITIALIZED.
(vect_analyze_loop): Adjust prototype.
(vect_analyze_loop_form): Likewise.
* tree-vect-data-refs.c (vect_analyze_data_ref_dependences):
Compute dependences lazily.
(vect_record_base_alignments): Use shared datarefs/ddrs.
(vect_verify_datarefs_alignment): Likewise.
(vect_analyze_data_refs_alignment): Likewise.
(vect_analyze_data_ref_accesses): Likewise.
(vect_analyze_data_refs): Likewise.
* tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Add
constructor parameter for shared part.
(vect_analyze_loop_form): Pass in shared part and adjust.
(vect_analyze_loop_2): Pass in storage for the number of
stmts.  Move loop nest finding to the caller.  Compute
datarefs lazily.
(vect_analyze_loop): Pass in shared part.
(vect_transform_loop): Verify shared datarefs are unchanged.
* tree-vect-slp.c (_bb_vec_info::_bb_vec_info): Add
constructor parameter for shared part.
(vect_slp_analyze_bb_1): Pass in shared part and adjust.
(vect_slp_bb): Verify shared datarefs are unchanged before
transform.
* tree-vect-stmts.c (ensure_base_align): Adjust for DR_AUX
change.
(new_stmt_vec_info): Initialize DR_AUX misalignment to
DR_MISALIGNMENT_UNINITIALIZED.
* tree-vectorizer.c (vec_info::vec_info): Add constructor
parameter for shared part.
(vec_info::~vec_info): Adjust.
(vec_info_shared::vec_info_shared): New.
(vec_info_shared::~vec_info_shared): Likewise.
(vec_info_shared::save_datarefs): Likewise.
(vec_info_shared::check_datarefs): Likewise.
(try_vectorize_loop_1): Construct shared part live for analyses
of a single loop for multiple vector sizes.
* tree-parloops.c (gather_scalar_reductions): Adjust.

diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
index aa74427296e..c49f032b655 100644
--- a/gcc/tree-parloops.c
+++ b/gcc/tree-parloops.c
@@ -2597,7 +2597,8 @@ gather_scalar_reductions (loop_p loop, 
reduction_info_table_type *reduction_list
   stmt_vec_infos.create (50);
   set_stmt_vec_info_vec (&stmt_vec_infos);
 
-  simple_loop_info = vect_analyze_loop_form (loop);
+  vec_info_shared shared;
+  simple_loop_info = vect_analyze_loop_form (loop, &shared);
   if (simple_loop_info == NULL)
 goto gather_done;
 
@@ -2636,7 +2637,8 @@ gather_scalar_reductions (loop_p loop, 
reduction_info_table_type *reduction_list
 
   if (!double_reduc_phis.is_empty ())
 {
-  simple_loop_info = vect_analyze_loop_form (loop->inner);
+  vec_info_shared shared;
+  simple_loop_info = vect_analyze_loop_form (loop->inner, &shared);
   if (simple_loop_info)
{
  gphi *phi;
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index bd71735585e..0094a04f740 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -568,15 +568,20 @@ vect_analyze_data_ref_dependences (loop_vec_info 
loop_vinfo,
 
   DUMP_VECT_SCOPE ("vect_analyz

[PATCH][1/3] Refactor SIMD lane handling in vect_find_stmt_data_reference

[Richard Biener]

This is a prerequesite for sharing dataref and dependence analysis
results between different vector size vectorization attempts.

Bootstrapped on x86_64-unknown-linux-gnu (with 2/3 included),
testing in progress.

Richard.

>From 9b406b12269d2a0fe86591df862c2ffd0197df37 Mon Sep 17 00:00:00 2001
From: Richard Guenther 
Date: Fri, 22 Jun 2018 11:33:34 +0200
Subject: [PATCH] do-not-modify-drs-for-simd-lane

2018-06-22  Richard Biener  

* tree-vect-data-refs.c (vect_find_stmt_data_reference): Modify
DR for SIMD lane accesses here and mark DR with (void *)-1 aux.
(vect_analyze_data_refs): Remove similar code from here and
simplify accordingly.

diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 1ac37bf5001..bd71735585e 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -4030,6 +4030,70 @@ vect_find_stmt_data_reference (loop_p loop, gimple *stmt,
   return false;
 }
 
+  /* Check whether this may be a SIMD lane access and adjust the
+ DR to make it easier for us to handle it.  */
+  if (loop
+  && loop->simduid
+  && (!DR_BASE_ADDRESS (dr)
+ || !DR_OFFSET (dr)
+ || !DR_INIT (dr)
+ || !DR_STEP (dr)))
+{
+  struct data_reference *newdr
+   = create_data_ref (NULL, loop_containing_stmt (stmt), DR_REF (dr), stmt,
+  DR_IS_READ (dr), DR_IS_CONDITIONAL_IN_STMT (dr));
+  if (DR_BASE_ADDRESS (newdr)
+ && DR_OFFSET (newdr)
+ && DR_INIT (newdr)
+ && DR_STEP (newdr)
+ && integer_zerop (DR_STEP (newdr)))
+   {
+ tree off = DR_OFFSET (newdr);
+ STRIP_NOPS (off);
+ if (TREE_CODE (DR_INIT (newdr)) == INTEGER_CST
+ && TREE_CODE (off) == MULT_EXPR
+ && tree_fits_uhwi_p (TREE_OPERAND (off, 1)))
+   {
+ tree step = TREE_OPERAND (off, 1);
+ off = TREE_OPERAND (off, 0);
+ STRIP_NOPS (off);
+ if (CONVERT_EXPR_P (off)
+ && (TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (off, 0)))
+ < TYPE_PRECISION (TREE_TYPE (off
+   off = TREE_OPERAND (off, 0);
+ if (TREE_CODE (off) == SSA_NAME)
+   {
+ gimple *def = SSA_NAME_DEF_STMT (off);
+ tree reft = TREE_TYPE (DR_REF (newdr));
+ if (is_gimple_call (def)
+ && gimple_call_internal_p (def)
+ && (gimple_call_internal_fn (def) == IFN_GOMP_SIMD_LANE))
+   {
+ tree arg = gimple_call_arg (def, 0);
+ gcc_assert (TREE_CODE (arg) == SSA_NAME);
+ arg = SSA_NAME_VAR (arg);
+ if (arg == loop->simduid
+ /* For now.  */
+ && tree_int_cst_equal (TYPE_SIZE_UNIT (reft), step))
+   {
+ DR_OFFSET (newdr) = ssize_int (0);
+ DR_STEP (newdr) = step;
+ DR_OFFSET_ALIGNMENT (newdr) = BIGGEST_ALIGNMENT;
+ DR_STEP_ALIGNMENT (newdr)
+   = highest_pow2_factor (step);
+ /* Mark as simd-lane access.  */
+ newdr->aux = (void *)-1;
+ free_data_ref (dr);
+ datarefs->safe_push (newdr);
+ return true;
+   }
+   }
+   }
+   }
+   }
+  free_data_ref (newdr);
+}
+
   datarefs->safe_push (dr);
   return true;
 }
@@ -4071,7 +4135,6 @@ vect_analyze_data_refs (vec_info *vinfo, poly_uint64 
*min_vf)
   gimple *stmt;
   stmt_vec_info stmt_info;
   enum { SG_NONE, GATHER, SCATTER } gatherscatter = SG_NONE;
-  bool simd_lane_access = false;
   poly_uint64 vf;
 
   gcc_assert (DR_REF (dr));
@@ -4092,76 +4155,13 @@ vect_analyze_data_refs (vec_info *vinfo, poly_uint64 
*min_vf)
  && !TREE_THIS_VOLATILE (DR_REF (dr))
  && (targetm.vectorize.builtin_scatter != NULL
  || supports_vec_scatter_store_p ());
- bool maybe_simd_lane_access
-   = is_a  (vinfo) && loop->simduid;
 
- /* If target supports vector gather loads or scatter stores, or if
-this might be a SIMD lane access, see if they can't be used.  */
+ /* If target supports vector gather loads or scatter stores,
+see if they can't be used.  */
  if (is_a  (vinfo)
  && !nested_in_vect_loop_p (loop, stmt))
{
- if (maybe_simd_lane_access)
-   {
- struct data_reference *newdr
-   = create_data_ref (NULL, loop_containing_stmt (stmt),
-  DR_REF (dr), stmt, !maybe_scatter,
-  DR_IS_CONDITIONAL_IN_STMT (dr));

Re: [PATCH] Fix emission of jump tables (PR tree-optimization/86263).

[Richard Biener]

On Fri, Jun 22, 2018 at 11:21 AM Martin Liška  wrote:
>
> Hello.
>
> Quite obvious patch where I accidentally removed check for:
> if (!targetm.have_casesi () && !targetm.have_tablejump ())
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?

OK.
Richard.

> Martin
>
> gcc/ChangeLog:
>
> 2018-06-21  Martin Liska  
>
> PR tree-optimization/86263
> * tree-switch-conversion.c (jump_table_cluster::find_jump_tables):
> Bail out if is_enabled is false.
> * tree-switch-conversion.h (jump_table_cluster::is_enabled):
> New declaration.
> (jump_table_cluster::is_enabled): New function.
> ---
>  gcc/tree-switch-conversion.c |  3 +++
>  gcc/tree-switch-conversion.h | 20 
>  2 files changed, 23 insertions(+)
>
>

Re: [PATCH 2/4] Switch other switch expansion methods into classes.

[Martin Liška]

On 06/20/2018 05:16 PM, Jeff Law wrote:
> On 06/20/2018 05:25 AM, Steven Bosscher wrote:
>> On Tue, Jun 12, 2018 at 10:44 PM, Jeff Law wrote:
>>> On 06/05/2018 01:15 AM, marxin wrote:

 + The definition of "much bigger" depends on whether we are
 + optimizing for size or for speed.  If the former, the maximum
 + ratio range/count = 3, because this was found to be the optimal
 + ratio for size on i686-pc-linux-gnu, see PR11823.  The ratio
 + 10 is much older, and was probably selected after an extensive
 + benchmarking investigation on numerous platforms.  Or maybe it
 + just made sense to someone at some point in the history of GCC,
 + who knows...  */
>>> "much older" is an understatement.  I believe the magic "10" pre-dates
>>> my involvement in GCC.  You can find evidence of it as far back as
>>> gcc-0.9.  I doubt it was extensively benchmarked, and even if it was,
>>> the targets on which it was benchmarked don't reflect modern target
>>> reality in terms of importance.
>>
>> When I added this comment
>> (https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/stmt.c?r1=189284&r2=189285&;)
>> it as an attempt at humor. I should have turned the number into a
>> PARAM at the time. Maybe that's something Martin could still do now?
> A PARAM feels like overkill, but I certainly wouldn't object.I'd be
> happy with that, a const member in the class or even the adjusted
> constant.
> 
> jeff
> 

Hi.

Agree with Jeff, there's a patch that does that.
Ready after it finishes tests?

Martin
>From 27d7c87720dc464b6ed998bc7344cf2226d5f9ea Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 22 Jun 2018 12:24:13 +0200
Subject: [PATCH] Come up with jump_table ratio constants used in
 jump_table_cluster.

gcc/ChangeLog:

2018-06-22  Martin Liska  

	* tree-switch-conversion.c (jump_table_cluster::can_be_handled):
Use newly introduced constants.
	* tree-switch-conversion.h (struct jump_table_cluster):
Define max_ratio_for_size and max_ratio_for_speed.
---
 gcc/tree-switch-conversion.c | 3 ++-
 gcc/tree-switch-conversion.h | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
index ddd8cba7b98..b79f2fdb6e6 100644
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -1180,7 +1180,8 @@ jump_table_cluster::can_be_handled (const vec &clusters,
   if (start == end)
 return true;
 
-  unsigned HOST_WIDE_INT max_ratio = optimize_insn_for_size_p () ? 3 : 8;
+  unsigned HOST_WIDE_INT max_ratio
+= optimize_insn_for_size_p () ? max_ratio_for_size : max_ratio_for_speed;
   unsigned HOST_WIDE_INT range = get_range (clusters[start]->get_low (),
 	clusters[end]->get_high ());
   /* Check overflow.  */
diff --git a/gcc/tree-switch-conversion.h b/gcc/tree-switch-conversion.h
index 79a1320c448..4beac785f05 100644
--- a/gcc/tree-switch-conversion.h
+++ b/gcc/tree-switch-conversion.h
@@ -257,6 +257,12 @@ struct jump_table_cluster: public group_cluster
 
   /* Return whether jump table expansion is allowed.  */
   static bool is_enabled (void);
+
+  /* Max growth ratio for code that is optimized for size.  */
+  static const unsigned HOST_WIDE_INT max_ratio_for_size = 3;
+
+  /* Max growth ratio for code that is optimized for speed.  */
+  static const unsigned HOST_WIDE_INT max_ratio_for_speed = 8;
 };
 
 /* A GIMPLE switch statement can be expanded to a short sequence of bit-wise
-- 
2.17.1

Re: Have g++ define _FILE_OFFSET_BITS=64 on Solaris

[Franz Sirl]

Am 2018-06-22 um 09:51 schrieb Rainer Orth:

Hi Franz,


No idea about possible problems, but isn't it usually recommended to use
either _FILE_OFFSET_BITS=64 or _LARGEFILE{64}_SOURCE=1, not both at the
same time?


quite the contrary: for regular largefile support, you're supposed to
use `getconf LFS_CFLAGS', i.e. -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64, while `getconf LFS64_CFLAGS'
(-D_LARGEFILE64_SOURCE) enables the transitional largefile interfaces
(e.g. explicit stat64 calls and struct stat64 instead of making stat and
struct stat largefile-aware).

For all the gory details, see the lfcompile(7), lfcompile64(7), and
lf64(7) man pages:

https://docs.oracle.com/cd/E88353_01/html/E37853/index.html

Rainer



Hi Rainer,

so you are supposed to use "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", 
but at least a quick glance at the Sol10 headers shows that the 
additional -D_LARGEFILE_SOURCE only makes a difference for 
fseeko/ftello. That still doesn't explain -D_LARGEFILE64_SOURCE, does 
libstdc++ really need to use _LARGEFILE64_SOURCE functions?


Re-reading lfcompile(7) again shows that you can use either 
"-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" (for portable applications) 
or only "-D_FILE_OFFSET_BITS=64". But in the GCC case we only need it 
for C++/libstdc++ so it seems "-D_FILE_OFFSET_BITS=64" should be enough. 
The rest is up to the users application, or?
My guess is that without defining _LARGEFILE_SOURCE and 
_LARGEFILE64_SOURCE the configure check in libstdc++-v3/acinclude.m4 
just won't define _GLIBCXX_USE_LFS and everything will fall in place. 
This would leave HPUX as the last user of _GLIBCXX_USE_LFS.


Franz

[ping] Improve specs processing to allow %* in function arguments

[Olivier Hainque]

Hello,

ping for https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00228.html

> On 5 Jun 2018, at 16:13, Olivier Hainque  wrote:

> The attached patch is a proposal to improve specs processing
> so %* works in spec function arguments (it doesn't as of today).

Thanks in advance!

With Kind Regards,

Olivier