Re: [PATCH,rs6000] AIX test fixes 2

2018-07-21 Thread Segher Boessenkool
Hi Carl,

On Fri, Jul 20, 2018 at 12:42:33PM -0700, Carl Love wrote:
> The following patch fixes errors on AIX for the "vector double" tests
> in altivec-1-runnable.c file.  The type "vector double" requires the
> use of the GCC command line option -mvsx. The vector double tests
> in altivec-1-runnable.c should be in altivec-2-runnable.c.  It looks
> like my Linux testing of the original patch worked because I configured
> GCC by default with -mcpu=power8.  AIX is not using that as the default
> processor thus causing the compile of altivec-1-runnable.c to fail.

This also fails on powerpc64-linux on a Power7.

> The vec_or tests in builtins-1.c were moved to another file by a
> previous patch.  The vec_or test generated the xxlor instruction.  The
> count of the xxlor instruction varies depending on the target as it is
> used as a move instruction.  No other tests generate the xxlor
> instruction. Hence, the count check was removed.

Okay, good idea.

> --- a/gcc/testsuite/gcc.target/powerpc/builtins-1.c
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1.c
> @@ -287,7 +287,6 @@ int main ()
> vec_mergeh  xxmrglw, vmrglh
> vec_mul mulld | mullw, mulhwu
> vec_nor xxlnor
> -   vec_or  xxlor

So there is no vec_or test anymore?  Is there more incorrect / out of date
in this comment?

> @@ -334,8 +331,10 @@ int main ()
>  /* { dg-final { scan-assembler-times "divd" 8  { target lp64 } } } */
>  /* { dg-final { scan-assembler-times "divdu" 2  { target lp64 } } } */
>  /* { dg-final { scan-assembler-times "mulld" 4  { target lp64 } } } */
> -/* { dg-final { scan-assembler-times {\mbl __divdi3\M} 2  { target { ilp32 } 
> } } } */
> -/* { dg-final { scan-assembler-times {\mbl __udivdi3\M} 2  { target {ilp32 } 
> } } } */
> +/* { dg-final { scan-assembler-times {\mbl .__divdi3\M} 2   { target { ilp32 
> &&  powerpc*-*-aix* } } } } */
> +/* { dg-final { scan-assembler-times {\mbl .__udivdi3\M} 2  { target { ilp32 
> &&  powerpc*-*-aix* } } } } */
> +/* { dg-final { scan-assembler-times {\mbl __divdi3\M} 2  { target { ilp32 
> && powerpc*-*-linux* } } } } */
> +/* { dg-final { scan-assembler-times {\mbl __udivdi3\M} 2 { target { ilp32 
> && powerpc*-*-linux* } } } } */

Those "." are the dot in a regexp, i.e. they match any character.

You could do something like

/* { dg-final { scan-assembler-times {\mbl \.?__divdi3\M} 2   { target { ilp32 
} } } } */
/* { dg-final { scan-assembler-times {\mbl \.?__udivdi3\M} 2  { target { ilp32 
} } } } */

to handle both ABIs with and without dots.

But, current patch is okay for trunk as well.  Thanks!


Segher


Re: [wwwdocs] Mention LTO link-time issue fixed in gcc 8.2

2018-07-21 Thread Gerald Pfeifer
On Thu, 19 Jul 2018, Jan Hubicka wrote:
> since we now mention the problem with Intel tuning, I tought we also may 
> mention the LTO link-time issue that was fixed.  It was mentioned by 
> several folks at the phoronix forum. (Basicaly sometimes the partition 
> size has overlfown which made partitioner to put every symbol into 
> separate parition causing fork bomb while streaming and overall very 
> slow compile times).

Thanks, Jan, this looks fine to me.

Gerald


Re: [PATCH] specify large command line option arguments (PR 82063)

2018-07-21 Thread H.J. Lu
On Fri, Jul 20, 2018 at 1:57 PM, Martin Sebor  wrote:
> On 07/19/2018 04:31 PM, Jeff Law wrote:
>>
>> On 06/24/2018 03:05 PM, Martin Sebor wrote:
>>>
>>> Storing integer command line option arguments in type int
>>> limits options such as -Wlarger-than= or -Walloca-larger-than
>>> to at most INT_MAX (see bug 71905).  Larger values wrap around
>>> zero.  The value zero is considered to disable the option,
>>> making it impossible to specify a zero limit.
>>>
>>> To get around these limitations, the -Walloc-size-larger-than=
>>> option accepts a string argument that it then parses itself
>>> and interprets as HOST_WIDE_INT.  The option also accepts byte
>>> size suffixes like KB, MB, GiB, etc. to make it convenient to
>>> specify very large limits.
>>>
>>> The int limitation is obviously less than ideal in a 64-bit
>>> world.  The treatment of zero as a toggle is just a minor wart.
>>> The special treatment to make it work for just a single option
>>> makes option handling inconsistent.  It should be possible for
>>> any option that takes an integer argument to use the same logic.
>>>
>>> The attached patch enhances GCC option processing to do that.
>>> It changes the storage type of option arguments from int to
>>> HOST_WIDE_INT and extends the existing (although undocumented)
>>> option property Host_Wide_Int to specify wide option arguments.
>>> It also introduces the ByteSize property for options for which
>>> specifying the byte-size suffix makes sense.
>>>
>>> To make it possible to consider zero as a meaningful argument
>>> value rather than a flag indicating that an option is disabled
>>> the patch also adds a CLVC_SIZE enumerator to the cl_var_type
>>> enumeration, and modifies how options of the kind are handled.
>>>
>>> Warning options that take large byte-size arguments can be
>>> disabled by specifying a value equal to or greater than
>>> HOST_WIDE_INT_M1U.  For convenience, aliases in the form of
>>> -Wno-xxx-larger-than have been provided for all the affected
>>> options.
>>>
>>> In the patch all the existing -larger-than options are set
>>> to PTRDIFF_MAX.  This makes them effectively enabled, but
>>> because the setting is exceedingly permissive, and because
>>> some of the existing warnings are already set to the same
>>> value and some other checks detect and reject such exceedingly
>>> large values with errors, this change shouldn't noticeably
>>> affect what constructs are diagnosed.
>>>
>>> Although all the options are set to PTRDIFF_MAX, I think it
>>> would make sense to consider setting some of them lower, say
>>> to PTRDIFF_MAX / 2.  I'd like to propose that in a followup
>>> patch.
>>>
>>> To minimize observable changes the -Walloca-larger-than and
>>> -Wvla-larger-than warnings required more extensive work to
>>> make of the new mechanism because of the "unbounded" argument
>>> handling (the warnings trigger for arguments that are not
>>> visibly constrained), and because of the zero handling
>>> (the warnings also trigger
>>>
>>>
>>> Martin
>>>
>>>
>>> gcc-82063.diff
>>>
>>>
>>> PR middle-end/82063 - issues with arguments enabled by -Wall
>>>
>>> gcc/ada/ChangeLog:
>>>
>>> PR middle-end/82063
>>> * gcc-interface/misc.c (gnat_handle_option): Change function
>>> argument
>>> to HOST_WIDE_INT.
>>>
>>> gcc/brig/ChangeLog:
>>> * brig/brig-lang.c (brig_langhook_handle_option): Change function
>>> argument to HOST_WIDE_INT.
>>>
>>> gcc/c-family/ChangeLog:
>>>
>>> PR middle-end/82063
>>> * c-common.h (c_common_handle_option): Change function argument
>>> to HOST_WIDE_INT.
>>> * c-opts.c (c_common_init_options): Same.
>>> (c_common_handle_option): Same.  Remove special handling of
>>> OPT_Walloca_larger_than_ and OPT_Wvla_larger_than_.
>>> * c.opt (-Walloc-size-larger-than, -Walloca-larger-than): Change
>>> options to take a HOST_WIDE_INT argument and accept a byte-size
>>> suffix.  Initialize.
>>> (-Wvla-larger-than): Same.
>>> (-Wno-alloc-size-larger-than, -Wno-alloca-larger-than): New.
>>> (-Wno-vla-larger-than): Same.
>>>
>>>
>>> gcc/fortran/ChangeLog:
>>>
>>> PR middle-end/82063
>>> * gfortran.h (gfc_handle_option): Change function argument
>>> to HOST_WIDE_INT.
>>> * options.c (gfc_handle_option): Same.
>>>
>>> gcc/go/ChangeLog:
>>>
>>> PR middle-end/82063
>>> * go-lang.c (go_langhook_handle_option): Change function argument
>>> to HOST_WIDE_INT.
>>>
>>> gcc/lto/ChangeLog:
>>>
>>> PR middle-end/82063
>>> * lto-lang.c (lto_handle_option): Change function argument
>>> to HOST_WIDE_INT.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR middle-end/82063
>>> * gcc.dg/Walloc-size-larger-than-16.c: Adjust.
>>> * gcc.dg/Walloca-larger-than.c: New test.
>>> * gcc.dg/Wframe-larger-than-2.c: New test.
>>> * gcc.dg/Wlarger-than3.c: New test.
>>>