Re: [PATCH] S/390: Ada: Enable Stack_Check_Probes.

[Andreas Krebbel]

On 03/01/2016 01:01 PM, Dominik Vogt wrote:
> gcc/ada/ChangeLog
> 
>   * system-linux-s390.adsx: Enable Stack_Check_Probes.
>   * system-linux-s390.ads: Likewise.

Applied. Thanks!

-Andreas-

Re: [PATCH] S/390: Reduce accuracy of bessel_6.f90.

[Andreas Krebbel]

On 01/11/2016 03:40 PM, Dominik Vogt wrote:
> gcc/testsuite/ChangeLog
> 
>   * gfortran.dg/bessel_6.f90: Reduce accuracy for S/390.

Applied. Thanks!

-Andreas-

Re: [PATCH][ARM] PR target/70008

[Michael Collison]

Hi Richard,

I think we could incorporate your feedback by changing the predicate on 
operand 1 to "arm_rhs_operand" which allows "s_register_operand" or 
"arm_immediate_operand". Everything else in my patch would stay the same 
including splitting the thumb2 pattern out into it's own insn. I'm 
testing this change now. Let me know if this direction is okay with you.


On 02/29/2016 08:29 AM, Richard Earnshaw (lists) wrote:

On 29/02/16 11:21, Michael Collison wrote:


On 2/29/2016 4:06 AM, Kyrill Tkachov wrote:

Hi Michael,

On 29/02/16 04:47, Michael Collison wrote:

This patches address PR 70008, where a reverse subtract with carry
instruction can be generated in thumb2 mode. It was tested with no
regressions in arm and thumb modes on the following targets:

arm-none-linux-gnueabi
arm-none-linux-gnuabihf
armeb-none-linux-gnuabihf
arm-none-eabi

Okay for trunk?

2016-02-28  Michael Collison 

 PR target/70008
 * config/arm/arm.md (*subsi3_carryin): Only match pattern if
 TARGET_ARM due to 'rsc' instruction alternative.
 * config/arm/thumb2.md (*thumb2_subsi3_carryin): New pattern.



The *subsi3_carrying pattern has the arch attribute:
(set_attr "arch" "*,a")

That means that the second alternative that generates the RSC
instruction is only enabled
for ARM mode. Do you have a testcase where this doesn't happen and
this pattern generates
the second alternative for Thumb2?

No I don't have a test case; i noticed the pattern when working on the
overflow project. I did not realize
that an attribute could affect the matching of an alternative. I will
close the bug.



Thanks,
Kyrill

This is all true, but there is a potential performance issue with this
pattern though, that could lead to sub-optimal code.

The predicate accepts reg-or-int, but in ARM state only simple
'const-ok-for-arm' immediates are permitted by the predicates, and in
thumb code, no immediates are permitted at all.  This could potentially
result in sub-optimal code due to late splitting of the pattern.  It
would be better if the predicate understood these limitations and
restricted immediates accordingly.

R.



--
Michael Collison
Linaro Toolchain Working Group
michael.colli...@linaro.org

Re: [C PATCH] Don't print -Waddress comparison warnings for macros (PR c/48778)

[Marek Polacek]

On Tue, Mar 01, 2016 at 04:38:13PM -0700, Jeff Law wrote:
> On 03/01/2016 07:10 AM, Marek Polacek wrote:
> >This PR from 2011 reports that -Waddress prints unhelpful warning when the
> >comparison comes from a macro.  Since I've added from_macro_expansion_at,
> >this is easy to circumvent.  I'm not so sure we actually want to disable
> >the warning in the case of a macro, but probably yes.
> >
> >Bootstrapped/regtested on x86_64-linux, ok for trunk or should I defer to
> >GCC 7?
> >
> >2016-03-01  Marek Polacek  
> >
> > PR c/48778
> > * c-typeck.c (build_binary_op): Don't issue -Waddress warnings
> > for macro expansions.
> >
> > * gcc.dg/Waddress-2.c: New test.
> I think deferral is the best option here.

I agree.  I will hold off, thanks.

Marek

Re: patch for PR233876

[Jakub Jelinek]

On Wed, Mar 02, 2016 at 07:30:12AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 01, 2016 at 08:43:21PM -0500, Vladimir Makarov wrote:
> >   The following patch should fix PR
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025
> > 
> >   The patch was successfully bootstrapped and tested on x86/x86-64.
> > 
> > Committed as rev. 233876.
> 
> Thanks.
> 
> >   I'll work on the test tomorrow -- I have no access to s390x right now.
> 
> I'll take care of it.

Here is what I've committed to trunk, turns out the bug used to be reproduceable
even with the least common -m64 s390x denominator (-march=z900) up to newer 
ones.

2016-03-02  Jakub Jelinek  

PR middle-end/70025
* gcc.dg/torture/pr70025.c: New test.

--- gcc/testsuite/gcc.dg/torture/pr70025.c.jj   2016-03-02 07:47:18.672709500 
+0100
+++ gcc/testsuite/gcc.dg/torture/pr70025.c  2016-03-02 07:52:17.659557439 
+0100
@@ -0,0 +1,81 @@
+/* PR middle-end/70025 */
+/* { dg-do run } */
+/* { dg-additional-options "-mtune=z10" { target s390*-*-* } } */
+
+typedef char (*F) (unsigned long, void *);
+typedef union { struct A { char a1, a2, a3, a4; unsigned long a5; F a6; void 
*a7; } b; char c[1]; } B;
+struct C { const char *c1; unsigned long c2; };
+typedef struct D { unsigned long d1; int d2; const char *d3; unsigned long d4, 
d5; struct C d6[49]; char d7[8]; } E[1];
+
+__attribute__ ((noinline, noclone))
+void foo (register E p)
+{
+  asm volatile ("" : : "r" (p) : "memory");
+}
+
+__attribute__ ((noinline, noclone))
+void bar (register E p)
+{
+  register unsigned long k = p[0].d1 + 1;
+  register struct C *l = [0].d6[p[0].d2];
+  register const char *m = l->c1;
+  p[0].d1 = k;
+  if (*m == '\0')
+{
+  register struct A *f = &((B *) m)->b;
+  register unsigned long n = l->c2;
+  register unsigned long o = n + f->a5;
+  if (k < o)
+   {
+ register unsigned long i;
+ register unsigned long q = k + 8;
+ register F a6 = f->a6;
+ register void *a7 = f->a7;
+ if (q > o)
+   q = o;
+ for (i = k; i < q; i++)
+   p[0].d7[i - k] = (*a6) (i - n, a7);
+ p[0].d4 = k;
+ p[0].d3 = p[0].d7;
+ p[0].d5 = q;
+ return;
+   }
+}
+  while (p[0].d2 > 0 && l[0].c2 != l[-1].c2)
+{
+  p[0].d2--;
+  l--;
+}
+  if (p[0].d2 == 0)
+{
+  p[0].d2 = 0x;
+  return;
+}
+  p[0].d2--;
+  foo (p);
+}
+
+char
+baz (unsigned long i, void *j)
+{
+  if (j != 0)
+__builtin_abort ();
+  return (char) i;
+}
+
+int
+main ()
+{
+  struct D p;
+  struct A f;
+  __builtin_memset (, 0, sizeof (f));
+  f.a2 = 4;
+  f.a5 = 13;
+  f.a6 = baz;
+  __builtin_memset (, 0, sizeof (p));
+  p.d6[0].c1 = (const char *) 
+  bar ();
+  if (p.d4 != 1 || p.d5 != 9 || p.d3 != p.d7)
+__builtin_abort ();
+  return 0;
+}


Jakub

Re: [PING 3, PATCH] S/390: Reduce accuracy of bessel_6.f90.

[Jakub Jelinek]

On Wed, Mar 02, 2016 at 07:36:23AM +0100, Dominik Vogt wrote:
> > Another patch reducing the accuracy required in the bessel_6 test.
> 
> > gcc/testsuite/ChangeLog
> > 
> > * gfortran.dg/bessel_6.f90: Reduce accuracy for S/390.

Ok, thanks.
> 
> > >From 70a35dd6f6bf906d8e5907667ad0f04f981a61ac Mon Sep 17 00:00:00 2001
> > From: Dominik Vogt 
> > Date: Mon, 11 Jan 2016 15:36:38 +0100
> > Subject: [PATCH] S/390: Reduce accuracy of bessel_6.f90.
> > 
> > ---
> >  gcc/testsuite/gfortran.dg/bessel_6.f90 | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/gcc/testsuite/gfortran.dg/bessel_6.f90 
> > b/gcc/testsuite/gfortran.dg/bessel_6.f90
> > index e0220f7..da917ff 100644
> > --- a/gcc/testsuite/gfortran.dg/bessel_6.f90
> > +++ b/gcc/testsuite/gfortran.dg/bessel_6.f90
> > @@ -12,7 +12,7 @@
> >  implicit none
> >  real,parameter :: values(*) = [0.0, 0.5, 1.0, 0.9, 
> > 1.8,2.0,3.0,4.0,4.25,8.0,34.53, 475.78] 
> >  real,parameter :: myeps(size(values)) = epsilon(0.0) &
> > -  * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 92, 15 ]
> > +  * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 98, 15 ]
> >  ! The following is sufficient for me - the values above are a bit
> >  ! more tolerant
> >  !  * [0, 5, 3, 4, 6, 7, 7, 5, 5, 6, 66, 4 ]
> > -- 
> > 2.3.0
> > 

Jakub

Re: [PING 2, PATCH] libitm: Introduce target macro TARGET_BEGIN_TRANSACTION_ATTRIBUTE.

[Dominik Vogt]

On Mon, Feb 01, 2016 at 02:18:48PM +0100, Dominik Vogt wrote:
> The attached patch adds the a target specific attribute via the
> new target macro TARGET_BEGIN_TRANSACTION_ATTRIBUTE to the
> function begin_transaction().  S/390 uses this to set the
> soft-float target attribute which is needed to fix a crash with
> -m31.
> 
> As there seems to be no place in libitm to document internal macros like
> USE_HTM_FASTPATH or the new macro, I've put the documentation in a
> comment where the macro is used.

Please note that we're waiting for approval of the libitm
maintainer, not for approval of the s390 maintainer.

> libitm/ChangeLog
> 
>   * config/s390/target.h (TARGET_BEGIN_TRANSACTION_ATTRIBUTE): Define
>   function attribute to disable floating point in begin_transaction() on
>   S/390.
>   * beginend.cc (begin_transaction): Use
>   TARGET_BEGIN_TRANSACTION_ATTRIBUTE.

> >From a5c8087753ab1f42082b9ab44d443005ed2c53ba Mon Sep 17 00:00:00 2001
> From: Dominik Vogt 
> Date: Mon, 1 Feb 2016 14:07:55 +0100
> Subject: [PATCH] libitm: Introduce target macro
>  TARGET_BEGIN_TRANSACTION_ATTRIBUTE.
> 
> The macro can be used to add attributes to the function begin_transaction.  
> Set
> it for S/390 to switch of harware floating point.
> ---
>  libitm/beginend.cc  | 6 ++
>  libitm/config/s390/target.h | 3 +++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/libitm/beginend.cc b/libitm/beginend.cc
> index 1a258ad..20b5547 100644
> --- a/libitm/beginend.cc
> +++ b/libitm/beginend.cc
> @@ -149,6 +149,12 @@ choose_code_path(uint32_t prop, abi_dispatch *disp)
>  return a_runInstrumentedCode;
>  }
>  
> +#ifdef TARGET_BEGIN_TRANSACTION_ATTRIBUTE
> +/* This macro can be used to define target specific attributes for this
> +   function.  For example, S/390 requires floating point to be disabled in
> +   begin_transaction.  */
> +TARGET_BEGIN_TRANSACTION_ATTRIBUTE
> +#endif
>  uint32_t
>  GTM::gtm_thread::begin_transaction (uint32_t prop, const gtm_jmpbuf *jb)
>  {
> diff --git a/libitm/config/s390/target.h b/libitm/config/s390/target.h
> index 44819a4..c9d5203 100644
> --- a/libitm/config/s390/target.h
> +++ b/libitm/config/s390/target.h
> @@ -69,6 +69,9 @@ cpu_relax (void)
>  /* Number of retries for transient failures.  */
>  #define _HTM_ITM_RETRIES 10
>  #define USE_HTM_FASTPATH
> +#define TARGET_BEGIN_TRANSACTION_ATTRIBUTE \
> +  __attribute__ ((target("soft-float")))
> +
>  
>  static inline bool
>  htm_available ()
> -- 
> 2.3.0
> 



Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PING 3, PATCH] S/390: Reduce accuracy of bessel_6.f90.

[Dominik Vogt]

On Mon, Jan 11, 2016 at 03:40:56PM +0100, Dominik Vogt wrote:
> Another patch reducing the accuracy required in the bessel_6 test.

> gcc/testsuite/ChangeLog
> 
>   * gfortran.dg/bessel_6.f90: Reduce accuracy for S/390.

> >From 70a35dd6f6bf906d8e5907667ad0f04f981a61ac Mon Sep 17 00:00:00 2001
> From: Dominik Vogt 
> Date: Mon, 11 Jan 2016 15:36:38 +0100
> Subject: [PATCH] S/390: Reduce accuracy of bessel_6.f90.
> 
> ---
>  gcc/testsuite/gfortran.dg/bessel_6.f90 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gfortran.dg/bessel_6.f90 
> b/gcc/testsuite/gfortran.dg/bessel_6.f90
> index e0220f7..da917ff 100644
> --- a/gcc/testsuite/gfortran.dg/bessel_6.f90
> +++ b/gcc/testsuite/gfortran.dg/bessel_6.f90
> @@ -12,7 +12,7 @@
>  implicit none
>  real,parameter :: values(*) = [0.0, 0.5, 1.0, 0.9, 
> 1.8,2.0,3.0,4.0,4.25,8.0,34.53, 475.78] 
>  real,parameter :: myeps(size(values)) = epsilon(0.0) &
> -  * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 92, 15 ]
> +  * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 98, 15 ]
>  ! The following is sufficient for me - the values above are a bit
>  ! more tolerant
>  !  * [0, 5, 3, 4, 6, 7, 7, 5, 5, 6, 66, 4 ]
> -- 
> 2.3.0
> 



Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PING 3, PATCH] PR/68089: C++-11: Ingore "alignas(0)".

[Dominik Vogt]

On Mon, Jan 04, 2016 at 12:33:21PM +0100, Dominik Vogt wrote:
> On Fri, Jan 01, 2016 at 05:53:08PM -0700, Martin Sebor wrote:
> > On 12/31/2015 04:50 AM, Dominik Vogt wrote:
> > >The attached patch fixes C++-11 handling of "alignas(0)" which
> > >should be ignored but currently generates an error message.  A
> > >test case is included; the patch has been tested on S390x.  Since
> > >it's a language issue it should be independent of the backend
> > >used.
> > 
> > The patch doesn't handle value-dependent expressions(*).
> 
> > It
> > seems that the problem is in handle_aligned_attribute() calling
> > check_user_alignment() with the second argument (ALLOW_ZERO)
> > set to false.  Calling it with true fixes the problem and handles
> > value-dependent expressions (I haven't done any more testing beyond
> > that).
> 
> Like the attached patch?  (Passes the testsuite on s390x.)
> 
> But wouldn't an "aligned" attribute be added, allowing the backend
> to possibly generate an error or a warning?
> 
> > Also, in the test, I noticed the definition of the first struct
> > is missing the terminating semicolon.
> 
> Yeah.

> gcc/c-family/ChangeLog
> 
>   PR/69089
>   * c-common.c (handle_aligned_attribute): Allow 0 as an argument to the
>   "aligned" attribute.
> 
> gcc/testsuite/ChangeLog
> 
>   PR/69089
>   * g++.dg/cpp0x/alignas5.C: New test.

> >From 2461293b9070da74950fd0ae055d1239cc69ce67 Mon Sep 17 00:00:00 2001
> From: Dominik Vogt 
> Date: Wed, 30 Dec 2015 15:08:52 +0100
> Subject: [PATCH] C++-11: Ingore "alignas(0)" instead of generating an
>  error message.
> 
> This is required by the C++-11 standard.
> ---
>  gcc/c-family/c-common.c   |  2 +-
>  gcc/testsuite/g++.dg/cpp0x/alignas5.C | 29 +
>  2 files changed, 30 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/alignas5.C
> 
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index 653d1dc..9eb25a9 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -7804,7 +7804,7 @@ handle_aligned_attribute (tree *node, tree ARG_UNUSED 
> (name), tree args,
>else if (TYPE_P (*node))
>  type = node, is_type = 1;
>  
> -  if ((i = check_user_alignment (align_expr, false)) == -1
> +  if ((i = check_user_alignment (align_expr, true)) == -1
>|| !check_cxx_fundamental_alignment_constraints (*node, i, flags))
>  *no_add_attrs = true;
>else if (is_type)
> diff --git a/gcc/testsuite/g++.dg/cpp0x/alignas5.C 
> b/gcc/testsuite/g++.dg/cpp0x/alignas5.C
> new file mode 100644
> index 000..f3252a9
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/alignas5.C
> @@ -0,0 +1,29 @@
> +// PR c++/69089
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-Wno-attributes" }
> +
> +alignas (0) int valid1;
> +alignas (1 - 1) int valid2;
> +struct Tvalid
> +{
> +  alignas (0) int i;
> +  alignas (2 * 0) int j;
> +};
> +
> +alignas (-1) int invalid1; /* { dg-error "not a positive power of 2" } */
> +alignas (1 - 2) int invalid2; /* { dg-error "not a positive power of 2" } */
> +struct Tinvalid
> +{
> +  alignas (-1) int i; /* { dg-error "not a positive power of 2" } */
> +  alignas (2 * 0 - 1) int j; /* { dg-error "not a positive power of 2" } */
> +};
> +
> +template  struct TNvalid1 { alignas (N) int i; };
> +TNvalid1<0> SNvalid1;
> +template  struct TNvalid2 { alignas (N) int i; };
> +TNvalid2<1 - 1> SNvalid2;
> +
> +template  struct TNinvalid1 { alignas (N) int i; }; /* { dg-error 
> "not a positive power of 2" } */
> +TNinvalid1<-1> SNinvalid1;
> +template  struct TNinvalid2 { alignas (N) int i; }; /* { dg-error 
> "not a positive power of 2" } */
> +TNinvalid2<1 - 2> SNinvalid2;
> -- 
> 2.3.0
> 



Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: patch for PR233876

[Jakub Jelinek]

On Tue, Mar 01, 2016 at 08:43:21PM -0500, Vladimir Makarov wrote:
>   The following patch should fix PR
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025
> 
>   The patch was successfully bootstrapped and tested on x86/x86-64.
> 
> Committed as rev. 233876.

Thanks.

>   I'll work on the test tomorrow -- I have no access to s390x right now.

I'll take care of it.

Jakub

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[DJ Delorie]

> Looks good to me.  Obviously you'll need appropriate ChangeLogs.  OK 
> with the ChangeLogs added.

Done.

Re: [PATCH] PR c/69993: improvements to wording of -Wmisleading-indentation

[Patrick Palka]

On Tue, Mar 1, 2016 at 3:29 PM, Patrick Palka  wrote:
> On Tue, Mar 1, 2016 at 1:51 PM, David Malcolm  wrote:
>> The wording of our output from -Wmisleading-indentation is rather
>> confusing, as noted by Reddit user "sysop073" here:
>>  
>> https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eonwd
>>
>>> The way they split up the warning looks designed to trick you.
>>> sslKeyExchange.c:631:8: warning: statement is indented as if it were 
>>> guarded by... [-Wmisleading-indentation]
>>> goto fail;
>>> ^~~~
>>> sslKeyExchange.c:629:4: note: ...this 'if' clause, but it is not
>>> if ((err = SSLHashSHA1.update(, )) != 0)
>>> ^~
>>> You read the first half and it sounds like goto fail; is guarding 
>>> something. Why would it not be:
>>> sslKeyExchange.c:631:8: warning: statement is wrongly indented... 
>>> [-Wmisleading-indentation]
>>> goto fail;
>>> ^~~~
>>> sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if' clause
>>> if ((err = SSLHashSHA1.update(, )) != 0)
>>> ^~
>>
>> I agree that the current wording is suboptimal; certainly the wording
>> would be much clearer if the wording of the "warning" only spoke about the
>> statement in question, and the "note"/inform should then talk about the
>> not-really-guarding guard.
>>
>> One rewording could be:
>>
>> sslKeyExchange.c:631:8: warning: statement is misleadingly indented... 
>> [-Wmisleading-indentation]
>> goto fail;
>> ^~~~
>> sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if' clause, 
>> but it is not
>> if ((err = SSLHashSHA1.update(, )) != 0)
>> ^~
>
> I prefer this one because it makes it clear that the problem is with
> the misleadingly-indented goto and not with the if.
>
>>
>> However another Reddit user ("ksion") noted here:
>>   
>> https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eqyih
>> that:
>>> This is just passive voice, there is nothing tricky about it.
>>> What I find more confusing -- and what your fix preserves -- is the
>>> reversed order of offending lines of code in the source file and the 
>>> message.
>>>
>>> I'd rather go with something like this:
>>> sslKeyExchange.c:629:4: warning: indentation of a statement below this 'if' 
>>> clause... [-Wmisleading-indentation]
>>> if ((err = SSLHashSHA1.update(, )) != 0)
>>> ^~
>>> sslKeyExchange.c:631:8: note: ...suggests it is guarded by the 'if' clause, 
>>> but it's not
>>> goto fail;
>>> ^~~~
>>> You can even see how the indentation is wrong in the very error message.
>>
>> which suggests reversing the order of the messages, so that they appear
>> in "source" order.
>>
>> I think this is a big improvement in the readability of the warning.
>
> Using this wording order makes it seem that the problem is with the if
> statement, because we emit a warning about it and then emit "only" a
> note for the misleadingly-indented goto statement.

... on second thought, I may be overthinking the semantic difference
between a warning and a note.  Feel free to disregard my nitpicking.

C++ PATCH for c++/70036 (ICE with unexpanded pack in requires-clause)

[Jason Merrill]

Straightforward change.

Tested x86_64-pc-linux-gnu, applying to trunk.

commit c11146bdabc5961956adfe00bef8e60657c60fa6
Author: Jason Merrill 
Date:   Tue Mar 1 20:52:24 2016 -0500

	PR c++/70036

	* parser.c (cp_parser_requires_clause): Call
	check_for_bare_parameter_packs.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 53decdc..535052f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -24206,6 +24206,8 @@ cp_parser_requires_clause (cp_parser *parser)
   ++processing_template_decl;
   tree expr = cp_parser_binary_expression (parser, false, false,
 	   PREC_NOT_OPERATOR, NULL);
+  if (check_for_bare_parameter_packs (expr))
+expr = error_mark_node;
   --processing_template_decl;
   return expr;
 }
diff --git a/gcc/testsuite/g++.dg/concepts/variadic3.C b/gcc/testsuite/g++.dg/concepts/variadic3.C
new file mode 100644
index 000..f980e99
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/variadic3.C
@@ -0,0 +1,8 @@
+// PR c++/70036
+// { dg-do compile { target c++14 } }
+// { dg-options "-fconcepts" }
+
+template  concept bool C = true;
+
+template 
+void f(T...) requires C;	// { dg-error "parameter pack" }

Re: C++ PATCH for c++/51489 (pointer subtraction in constant expression)

[Jason Merrill]

On 12/19/2011 12:56 AM, Jason Merrill wrote:

DR 1313 removes the blanket prohibition on pointer subtraction in
constant expressions and replaces it with a prohibition on operations
with undefined behavior, so this testcase ought to work.  It wasn't
working because our internal representation of pointer subtraction
involves converting the pointers to ptrdiff_t before subtracting, and
such a conversion is prohibited (previously specifically, now as a
reinterpret_cast).  There's currently no good way to distinguish between
a user-written cast and the compiler-generated one, so I've moved the
check to cxx_eval_outermost_constant_expr for now.


This fix worked for pointer arithmetic based on a static array, but not 
for a local array in a constexpr function.  The fix is a simple matter 
of not insisting that the ptrdiff_t operands be constant themselves.


Tested x86_64-pc-linux-gnu, applying to trunk and 5.


commit 9537133530fe9a6f6a9c0e61d9bbe7332a106c3c
Author: Jason Merrill 
Date:   Tue Mar 1 02:01:46 2016 -0500

	PR c++/51489

	* constexpr.c (cxx_eval_binary_expression): Don't VERIFY_CONSTANT
	the operands.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index a21997a..bcb129f 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1612,15 +1612,14 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, tree t,
   tree lhs, rhs;
   lhs = cxx_eval_constant_expression (ctx, orig_lhs, /*lval*/false,
   non_constant_p, overflow_p);
-  /* Don't VERIFY_CONSTANT if this might be dealing with a pointer to
- a local array in a constexpr function.  */
-  bool ptr = POINTER_TYPE_P (TREE_TYPE (lhs));
-  if (!ptr)
-VERIFY_CONSTANT (lhs);
+  /* Don't VERIFY_CONSTANT here, it's unnecessary and will break pointer
+ subtraction.  */
+  if (*non_constant_p)
+return t;
   rhs = cxx_eval_constant_expression (ctx, orig_rhs, /*lval*/false,
   non_constant_p, overflow_p);
-  if (!ptr)
-VERIFY_CONSTANT (rhs);
+  if (*non_constant_p)
+return t;
 
   location_t loc = EXPR_LOCATION (t);
   enum tree_code code = TREE_CODE (t);
@@ -1653,6 +1652,9 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, tree t,
 }
   else if (cxx_eval_check_shift_p (loc, ctx, code, type, lhs, rhs))
 *non_constant_p = true;
+  /* Don't VERIFY_CONSTANT if this might be dealing with a pointer to
+ a local array in a constexpr function.  */
+  bool ptr = POINTER_TYPE_P (TREE_TYPE (lhs));
   if (!ptr)
 VERIFY_CONSTANT (r);
   return r;
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-array4.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-array4.C
new file mode 100644
index 000..fc01047
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-array4.C
@@ -0,0 +1,12 @@
+// { dg-do compile { target c++14 } }
+
+constexpr bool g()
+{
+  int ar[4] = { 1, 2, 3, 4 };
+  auto e1 = ar;
+  auto e4 = ar+3;
+  return (e4-e1) == 3;
+}
+
+#define SA(X) static_assert((X),#X)
+SA(g());

Re: C++ PATCH for c++/69995 (wrong value with C++14 constexpr)

[Jason Merrill]

On 02/29/2016 09:25 AM, Jason Merrill wrote:

The bug here was that we were sharing the CONSTRUCTOR between the value
of 'a' and the elements of 'result', so changing 'a' also changed the
value of result[0].  Oops.


And there were a few other places with the same problem.

Tested x86_64-pc-linux-gnu, applying to trunk and 5.



commit 0b712dc1cf26859a8ae01eac4ea60005c82e95eb
Author: Jason Merrill 
Date:   Tue Mar 1 01:28:41 2016 -0500

	PR c++/69995

	* constexpr.c (cxx_eval_call_expression): Unshare arg.
	(cxx_eval_constant_expression) [DECL_EXPR]: Unshare init.
	[TARGET_EXPR]: Unshare init.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 5e35940..a21997a 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1365,6 +1365,8 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t,
 	  tree oparm = TREE_PURPOSE (bound);
 	  tree arg = TREE_VALUE (bound);
 	  gcc_assert (DECL_NAME (remapped) == DECL_NAME (oparm));
+	  /* Don't share a CONSTRUCTOR that might be changed.  */
+	  arg = unshare_expr (arg);
 	  ctx->values->put (remapped, arg);
 	  bound = TREE_CHAIN (bound);
 	  remapped = DECL_CHAIN (remapped);
@@ -3366,6 +3368,8 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, tree t,
 	init = cxx_eval_constant_expression (ctx, init,
 		 false,
 		 non_constant_p, overflow_p);
+	/* Don't share a CONSTRUCTOR that might be changed.  */
+	init = unshare_expr (init);
 	ctx->values->put (r, init);
 	  }
 	else if (ctx == _ctx)
@@ -3410,6 +3414,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, tree t,
   if (lval)
 	{
 	  tree slot = TARGET_EXPR_SLOT (t);
+	  r = unshare_expr (r);
 	  ctx->values->put (slot, r);
 	  return slot;
 	}
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-copy2.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-copy2.C
new file mode 100644
index 000..6707975
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-copy2.C
@@ -0,0 +1,24 @@
+// PR c++/69995
+// { dg-do compile { target c++14 } }
+
+struct A
+{
+  int i;
+};
+
+constexpr int f(A a)
+{
+  ++a.i;
+  return a.i;
+}
+
+constexpr bool g()
+{
+  A a = { 42 };
+  if (f(a) != 43) return false;
+  if (a.i != 42) return false;
+  return true;
+}
+
+#define SA(X) static_assert((X),#X)
+SA(g());
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-copy3.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-copy3.C
new file mode 100644
index 000..cce4b54
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-copy3.C
@@ -0,0 +1,26 @@
+// PR c++/69995
+// { dg-do compile { target c++14 } }
+
+struct A
+{
+  int i;
+};
+
+constexpr int f(A a)
+{
+  ++a.i;
+  return a.i;
+}
+
+constexpr bool g()
+{
+  A a = { 42 };
+  A b = a;
+  ++b.i;
+  if (b.i != 43) return false;
+  if (a.i != 42) return false;
+  return true;
+}
+
+#define SA(X) static_assert((X),#X)
+SA(g());

patch for PR233876

[Vladimir Makarov]

  The following patch should fix PR

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025

  The patch was successfully bootstrapped and tested on x86/x86-64.

Committed as rev. 233876.

  I'll work on the test tomorrow -- I have no access to s390x right now.
Index: ChangeLog
===
--- ChangeLog	(revision 233875)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2016-03-01  Vladimir Makarov  
+
+	PR middle-end/70025
+	* lra-constraints.c (regno_val_use_in): New.
+	(match_reload): Use it instead of regno_use_in.
+
 2016-03-01  Eric Botcazou  
 
 	PR rtl-optimization/70007
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 233861)
+++ lra-constraints.c	(working copy)
@@ -840,6 +840,36 @@ narrow_reload_pseudo_class (rtx reg, enu
 lra_change_class (REGNO (reg), rclass, "  Change to", true);
 }
 
+/* Searches X for any reference to a reg with the same value as REGNO,
+   returning the rtx of the reference found if any.  Otherwise,
+   returns NULL_RTX.  */
+static rtx
+regno_val_use_in (unsigned int regno, rtx x)
+{
+  const char *fmt;
+  int i, j;
+  rtx tem;
+
+  if (REG_P (x) && lra_reg_info[REGNO (x)].val == lra_reg_info[regno].val)
+return x;
+
+  fmt = GET_RTX_FORMAT (GET_CODE (x));
+  for (i = GET_RTX_LENGTH (GET_CODE (x)) - 1; i >= 0; i--)
+{
+  if (fmt[i] == 'e')
+	{
+	  if ((tem = regno_val_use_in (regno, XEXP (x, i
+	return tem;
+	}
+  else if (fmt[i] == 'E')
+	for (j = XVECLEN (x, i) - 1; j >= 0; j--)
+	  if ((tem = regno_val_use_in (regno , XVECEXP (x, i, j
+	return tem;
+}
+
+  return NULL_RTX;
+}
+
 /* Generate reloads for matching OUT and INS (array of input operand
numbers with end marker -1) with reg class GOAL_CLASS.  Add input
and output reloads correspondingly to the lists *BEFORE and *AFTER.
@@ -942,7 +972,8 @@ match_reload (signed char out, signed ch
 	= (! early_clobber_p && ins[1] < 0 && REG_P (in_rtx)
 	   && (int) REGNO (in_rtx) < lra_new_regno_start
 	   && find_regno_note (curr_insn, REG_DEAD, REGNO (in_rtx))
-	   && (out < 0 || regno_use_in (REGNO (in_rtx), out_rtx) == NULL_RTX)
+	   && (out < 0
+	   || regno_val_use_in (REGNO (in_rtx), out_rtx) == NULL_RTX)
 	   ? lra_create_new_reg (inmode, in_rtx, goal_class, "")
 	   : lra_create_new_reg_with_unique_value (outmode, out_rtx,
 		   goal_class, ""));

Re: [PATCH PR69052]Check if loop inv can be propagated into mem ref with additional addr expr canonicalization

[Jeff Law]

On 03/01/2016 10:08 AM, Bin.Cheng wrote:

On Thu, Feb 25, 2016 at 8:47 AM, Bin.Cheng  wrote:

On Thu, Feb 25, 2016 at 6:39 AM, Jeff Law  wrote:

On 02/22/2016 02:22 AM, Bin.Cheng wrote:


My only question is why didn't you use FOR_EACH_SUBRTX_VRA from
rtl-iter.h
to walk the RTX expressions in collect_address_parts and
canonicalize_address_mult?


Hi Jeff,
Nothing special, just I haven't used this before, also
canonicalize_address_mult is alphabetically copied from fwprop.c.  One
question is when rewriting SHIFT to MULT, we need to modify rtl
expression in place, does FOR_EACH_SUBRTX iterator support this?  If
yes, what is the behavior for modified sub-expression?


Hmm.  The question of semantics when we change the underlying
sub-expressions is an interesting one.

While I think we're OK in practice using the iterators, I think that's more
of an accident than by design -- if MULT/ASHIFT had a different underlying
RTL structure then I'm much less sure using the iterators would be safe.

Hi Jeff,
Yes, I thought about this too and finally decided to skip sub rtxes in
modified MULT/ASHIFT expressions.  I think this will make the patch
with FOR_EACH_SUBRTX iterator safe.  Although it doesn't dive into
MULT/ASHIFT while the original one does, I don't think there is such
case in practice, after all we can't handle such complicated address
expression either.


Let's go with your original patch that didn't use the iterators.  Sorry for
making you do the additional work/testing to build the iterator version.

Not even a problem.

But after pondering the issue you raised, I think your original patch is
safer.

So in conclusion, I think both versions should be safe, the iterator
one is definitely cleaner.  It is your call which version I should
apply.

Hi Jeff,
I tend to apply the new patch with FOR_EACH_SUBRTX because it's
clearer.  Does it work for you?  Of course if you do think it's not
that safe I will fall back to the old one.

Sorry, things are just busy here.

I'm reasonably comfortable with both as long as we're not diving inside 
the subexpressions in the ASHIFT/MULT case.  If you'd prefer the 
FOR_EACH_SUBRTX variant, that's OK with me.


jeff

Please include ada-hurd.diff upstream (try2)

[Svante Signell]

Hello,

As time progresses, the ada-hurd.diff patch has now been living in Debian since
gcc-4.6 and is now in gcc-5 and gcc-6. Last try to get it included upstream was
in 2012, and 2014, e.g see
https://gcc.gnu.org/ml/gcc-patches/2012-06/msg0.html
and follow-ups.

Maybe the time has come now for a proper inclusion of Ada/Gnat support in gcc-*
for GNU/Hurd. (Yes, I commit to maintain Ada in gcc for GNU/Hurd in the
foreseeable future, according to my abilities).

Attached is an updated patch, now living e.g. in GNU/Debian versions of gcc-5
and gcc-6.

Please tell me if you need a changelog entry too. And yes, I have already signed
all copyright papers for FSF wrt gcc (and other packages).

Thanks!


Index: gcc-6-6-20160109/src/gcc/ada/s-osinte-gnu.ads
===
--- /dev/null
+++ gcc-6-6-20160109/src/gcc/ada/s-osinte-gnu.ads
@@ -0,0 +1,801 @@
+--
+--  --
+--GNU ADA RUN-TIME LIBRARY (GNARL) COMPONENTS   --
+--  --
+--   S Y S T E M . O S _ I N T E R F A C E  --
+--  --
+--  S p e c --
+--  --
+-- Copyright (C) 1991-1994, Florida State University--
+--  Copyright (C) 1995-2014, Free Software Foundation, Inc. --
+--  --
+-- GNAT is free software;  you can  redistribute it  and/or modify it under --
+-- terms of the  GNU General Public License as published  by the Free Soft- --
+-- ware  Foundation;  either version 3,  or (at your option) any later ver- --
+-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
+-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
+-- or FITNESS FOR A PARTICULAR PURPOSE. --
+--  --
+-- As a special exception under Section 7 of GPL version 3, you are granted --
+-- additional permissions described in the GCC Runtime Library Exception,   --
+-- version 3.1, as published by the Free Software Foundation.   --
+--  --
+-- You should have received a copy of the GNU General Public License and--
+-- a copy of the GCC Runtime Library Exception along with this program; --
+-- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see--
+-- .  --
+--  --
+-- GNARL was developed by the GNARL team at Florida State University.   --
+-- Extensive contributions were provided by Ada Core Technologies, Inc. --
+--  --
+--
+
+--  This is the GNU/Hurd (POSIX Threads) version of this package
+
+--  This package encapsulates all direct interfaces to OS services
+--  that are needed by children of System.
+
+--  PLEASE DO NOT add any with-clauses to this package or remove the pragma
+--  Preelaborate. This package is designed to be a bottom-level (leaf) package
+
+with Interfaces.C;
+with Unchecked_Conversion;
+
+package System.OS_Interface is
+   pragma Preelaborate;
+
+   pragma Linker_Options ("-lpthread");
+   pragma Linker_Options ("-lrt");
+
+   subtype intis Interfaces.C.int;
+   subtype char   is Interfaces.C.char;
+   subtype short  is Interfaces.C.short;
+   subtype long   is Interfaces.C.long;
+   subtype unsigned   is Interfaces.C.unsigned;
+   subtype unsigned_short is Interfaces.C.unsigned_short;
+   subtype unsigned_long  is Interfaces.C.unsigned_long;
+   subtype unsigned_char  is Interfaces.C.unsigned_char;
+   subtype plain_char is Interfaces.C.plain_char;
+   subtype size_t is Interfaces.C.size_t;
+
+   ---
+   -- Errno --
+   ---
+   --  From /usr/include/i386-gnu/bits/errno.h
+
+   function errno return int;
+   pragma Import (C, errno, "__get_errno");
+
+   EAGAIN   : constant := 1073741859;
+   EINTR: constant := 1073741828;
+   EINVAL   : constant := 1073741846;
+   ENOMEM   : constant := 1073741836;
+   EPERM: constant := 1073741825;
+   ETIMEDOUT: constant := 1073741884;
+
+   -
+   -- Signals --
+   -
+   --  From /usr/include/i386-gnu/bits/signum.h
+
+   Max_Interrupt : 

Re: [PATCH] Fix PR68621

[Jeff Law]

On 03/01/2016 09:48 AM, Kumar, Venkataramanan wrote:

Hi Richard,

As discussed in PR, tried to adjust the test case by initializing array, but 
looks like for building with -fpic it needs visibility to be set a hidden.
The below patch does that.


Ok for trunk ?

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 82e538e..f6bcb07 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2016-03-01  Venkataramanan Kumar  
+
+   PR tree-optimization/68621
+   * gcc.dg/tree-ssa/ifc-8.c: Adjust test.

OK.

jeff

Re: [C PATCH] Don't print -Waddress comparison warnings for macros (PR c/48778)

[Jeff Law]

On 03/01/2016 07:10 AM, Marek Polacek wrote:

This PR from 2011 reports that -Waddress prints unhelpful warning when the
comparison comes from a macro.  Since I've added from_macro_expansion_at,
this is easy to circumvent.  I'm not so sure we actually want to disable
the warning in the case of a macro, but probably yes.

Bootstrapped/regtested on x86_64-linux, ok for trunk or should I defer to
GCC 7?

2016-03-01  Marek Polacek  

PR c/48778
* c-typeck.c (build_binary_op): Don't issue -Waddress warnings
for macro expansions.

* gcc.dg/Waddress-2.c: New test.

I think deferral is the best option here.

jeff

Re: Fix PR rtl-optimization/70007

[Uros Bizjak]

Hello!

> 2016-03-01  Eric Botcazou  
>
> PR rtl-optimization/70007
> * gcse.c (compute_ld_motion_mems): Tidy up and also invalidate memory
> references present in REG_EQUAL notes attached to non-SET patterns.
>
>
> 2016-03-01  Eric Botcazou  
>
> * gcc.target/i386/pr70007.c: New test.

The testcase will fail due to several problems:
- warning: large integer implicitly truncated to unsigned type [-Woverflow]
- warning: AVX vector argument without AVX enabled changes the ABI [-Wpsabi]
- missing int128 effective target check
- missing runtime checks for BMI2 ISA support

Attached patch fixes all of them.

Uros.
Index: testsuite/gcc.target/i386/pr70007.c
===
--- testsuite/gcc.target/i386/pr70007.c (revision 233869)
+++ testsuite/gcc.target/i386/pr70007.c (working copy)
@@ -1,8 +1,10 @@
 /* PR rtl-optimization/70007 */
-/* { dg-do run } */
-/* { dg-options "-O -fgcse -mbmi2" } */
-/* { dg-require-effective-target bmi2 } */
+/* { dg-do run { target bmi2 } } */
+/* { dg-options "-O -fgcse -mbmi2 -Wno-psabi" } */
+/* { dg-require-effective-target int128 } */
 
+#include "bmi2-check.h"
+
 typedef unsigned short v32u16 __attribute__ ((vector_size (32)));
 typedef unsigned long long v32u64 __attribute__ ((vector_size (32)));
 typedef unsigned __int128 u128;
@@ -19,11 +21,10 @@
   return v32u64_1[3];
 }
 
-int
-main (void)
+static void
+bmi2_test ()
 {
-  u128 x = foo((v32u16){~0xba31, 0x47c6}, (v32u64){64}, (v32u64){0, 
0x8b217e2514d23242, 0xac569b6dff9f82, 0x9d4cffe03c139c});
+  u128 x = foo((v32u16){(unsigned short) ~0xba31, 0x47c6}, (v32u64){64}, 
(v32u64){0, 0x8b217e2514d23242, 0xac569b6dff9f82, 0x9d4cffe03c139c});
   if (x != 0x3c74da5ca328d09)
 __builtin_abort();
-  return 0;
 }

Re: [PATCH] add more style checks to check_GNU_style.sh

[Jeff Law]

On 02/25/2016 08:05 PM, Martin Sebor wrote:

Recently I had the opportunity to learn about a number of rather
subtle style conventions sometimes enforced during code reviews
(though not inconsistently followed in GCC code).  To help find
these kinds of problems before a patch is submitted and cut down
on the subsequent back-and-forth, I've added checks for some of
these conventions to the check_GNU_style.sh script.  In addition,
since the script tends to produce lots of noise for things that
can't be fixed in tests like lines in excess of 80 characters
caused by dg-error directives, I tweaked it to suppress these.

To verify that the new checkers don't add too much noise I ran
the patched script on the last 1000 commits, both with and without
testsuite changes (all without libstdc++).  The results are below.
It's telling that over a quarter of all commits violate even the
limited subset of the GNU coding guidelines the script checks for.

   script w/o tests  w/tests
   baseline  258   434
   patched   282   466

FWIW, to make the script more usable (e.g., to check the rules
appropriate for each file type, including documentation), it
will need to be considerably enhanced.  I think most of it can
be done in AWK (already used by the script), and I might try
to tackle that at some point in the future.

Martin

check_GNU_style.sh.diff


contrib/ChangeLog:
2016-02-25  Martin Sebor

* check_GNU_style.sh: Add a new global variable.
Add checks for trailing operators and spaces before left brackets.
Tightened up a check for a trailing left curly brace.
(g, ag, vg): Use color.
(col): Don't complain about excessively long lines with DejaGnu
directives.

OK.

FWIW, I think a reasonable long term course would be to continue to 
update contrib/clang-format.  Ideally we could get to a point where we 
could declare the output of clang-format (with the configuration we've 
chosen) as the canonical formatting.  Which would go a long way towards 
having patch submissions & review focus much more on the content rather 
than the format of patches.



jeff

Re: [wwwdocs] Document 3 changes in GCC 6

[Eric Botcazou]

> How about saying "It specifies the storage order..."?
> 
> And "in structures and unions"?

OK.

> How about "...is passed to a subprogram in slot #15..."?

OK.

> Okay with the changes above.

Thanks!

-- 
Eric Botcazou

Re: [wwwdocs] Document 3 changes in GCC 6

[Gerald Pfeifer]

On Mon, 29 Feb 2016, Eric Botcazou wrote:
>  - new scalar_storage_order type attribute in C,
>  - ABI change for SPARC 64-bit,
>  - automatic enabling of -mstackrealign with SSE for Windows 32-bit.

+   A new type attribute scalar_storage_order applying to
+   structures and unions has been introduced.  It makes it possible
+   to specify the storage order (aka endianness) in memory of scalar
+   fields in the structures or unions.

How about saying "It specifies the storage order..."?

And "in structures and unions"?

+An ABI bug has been fixed in 64-bit mode. Unfortunately, this change
+will break binary compatibility with earlier releases for code it affects,
+but this should be pretty rare in practice.  The conditions are: a 16-byte
+structure containing a double or a 8-byte vector in the second
+half is passed in slot #15 to a subprogram, for example as 16th parameter
+if the first 15 ones have at most 8 bytes.  The double or
+vector was wrongly passed in floating-point register %d32
+in lieu of on the stack as per the SPARC calling conventions.

That really must occur super, super rarely. ;-)

How about "...is passed to a subprogram in slot #15..."?


Okay with the changes above.  Thanks for taking the time to 
document these!

Gerald

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[Jeff Law]

On 03/01/2016 12:45 PM, DJ Delorie wrote:

Write a patch to deprecate it in config.gcc (search for openbsd2 to help
you find the right spot) and an update to the gcc6 webpage.


How's this?
Looks good to me.  Obviously you'll need appropriate ChangeLogs.  OK 
with the ChangeLogs added.


jeff

Re: [wwwdocs] [PATCH] Add "id" attributes to the headings in the GCC 6 porting guide

[Jeff Law]

On 03/01/2016 12:41 PM, David Malcolm wrote:

htdocs/gcc-6/porting_to.html is now multiple screens of text.

The attached patch adds "id" attributes to every h2, h3 and h4 element
in the page, so that people can create URLs that reference specific
subsections of the guide.

Validates.

OK to commit?

OK.
jeff

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[Jeff Law]

On 03/01/2016 12:42 PM, Trevor Saunders wrote:

On Tue, Mar 01, 2016 at 11:29:25AM -0700, Jeff Law wrote:

On 03/01/2016 11:26 AM, DJ Delorie wrote:

Can we make that official?   64402, 49401 & 24998 go away when MEP is
deprecated.


We can, what's the next step?  I announced intent in Dec, nobody
commented or stepped up to take it.

Write a patch to deprecate it in config.gcc (search for openbsd2 to help you
find the right spot) and an update to the gcc6 webpage.


have we updated the web page for the other obsolete targets?

We have.



I think you also need to update config-list.mk to pass --enable-obsolete
for that target.
Yes.  I forgot about that (after making a note of it multiple times to 
myself).


jeff

[PATCH][PR tree-optimization/pr69196] Clamp number of statements to copy when not threading across a loop backedge

[Jeff Law]

This patch clamps the number of statements to copy when not threading 
across a loop backedge in the FSM/backwards threader.  This fixes the 
bulk of the regression in 69196.  I'm still evaluating whether or not 
69196 can be closed, but at the least it's a P2 now.


Bootstrapped and regression tested on x86_64-linux-gnu.  Also verified 
the size of the testcase in the BZ was drastically reduced.  Installing 
on the trunk.


The best idea I've got for further improvements would be to sort the FSM 
threads based on those which are perceived to be the most profitable. 
That would cause certain less profitable jump threads to be abandoned.


It also appears that the threads through the switch statement ought to 
be realized -- my recollection was those were profitable both from a 
codesize and a speed standpoint.  It may be the case that the path to 
realize those is just too long after the other jump threads are handled.


But my overall advice would be that if you care about codesize, use -Os 
which will disable most jump threading optimizations.  While the 
specific test included in the BZ wasn't improved by jump threading, in 
general jump threading has been shown to be profitable in an of itself 
with nice secondary benefits as well.


Jeff
commit 3d54e848883bc7c510c41b718aabe1771cb16fbf
Author: law 
Date:   Tue Mar 1 23:12:10 2016 +

PR tree-optimization/69196
* tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
Appropriately clamp the number of statements to copy when the
thread path does not traverse a loop backedge.

PR tree-optimization/69196
* gcc.dg/tree-ssa/pr69196.c: New test.

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

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 982a7c0..88f0806 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -8,6 +8,11 @@
 
PR tree-optimization/69196
* tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
+   Appropriately clamp the number of statements to copy when the
+   thread path does not traverse a loop backedge.
+
+   PR tree-optimization/69196
+   * tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
Do count some PHIs in the thread path against the insn count.  Decrease
final statement count by one as the control statement in the last
block will get removed.  Remove special cased code for handling PHIs
in the last block.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index bdc4b11..1e6a850 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -5,6 +5,9 @@
 2016-03-01  Jeff Law  
 
PR tree-optimization/69196
+   * gcc.dg/tree-ssa/pr69196.c: New test.
+
+   PR tree-optimization/69196
* gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
duplicating code and spoiling the expected output.
 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr69196-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr69196-1.c
new file mode 100644
index 000..11c7cf5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr69196-1.c
@@ -0,0 +1,138 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-vrp1-details" } */
+
+/* { dg-final { scan-tree-dump "FSM did not thread around loop and would copy 
too many statements" "vrp1" } } */
+
+
+typedef __builtin_va_list __gnuc_va_list;
+typedef __gnuc_va_list va_list;
+extern void rtems_putc(char c);
+
+void vprintk(
+  const char *fmt,
+  va_list ap
+)
+{
+  for (; *fmt != '\0'; fmt++) {
+unsigned base = 0;
+unsigned width = 0;
+enum {
+  LFLAG_INT,
+  LFLAG_LONG,
+  LFLAG_LONG_LONG
+} lflag = LFLAG_INT;
+_Bool minus = 0;
+_Bool sign = 0;
+char lead = ' ';
+char c = *fmt;
+long long num;
+
+if (c != '%') {
+  rtems_putc(c);
+  continue;
+}
+
+++fmt; c = *fmt;
+
+if (c == '0') {
+  lead = '0';
+  ++fmt; c = *fmt;
+}
+
+if (c == '-') {
+  minus = 1;
+  ++fmt; c = *fmt;
+}
+
+while (c >= '0' && c <= '9' ) {
+  width *= 10;
+  width += ((unsigned) c - '0');
+  ++fmt; c = *fmt;
+}
+
+if (c == 'l') {
+  lflag = LFLAG_LONG;
+  ++fmt; c = *fmt;
+
+  if (c == 'l') {
+lflag = LFLAG_LONG_LONG;
+++fmt; c = *fmt;
+  }
+}
+
+if ( c == 'c' ) {
+
+  char chr = (char) __builtin_va_arg(ap,int);
+  rtems_putc(chr);
+  continue;
+}
+
+if ( c == 's' ) {
+  unsigned i, len;
+  char *s, *str;
+
+  str = __builtin_va_arg(ap,char *);
+
+  if ( str == ((void *)0) ) {
+str = "";
+  }
+
+
+  for ( len=0, s=str ; *s ; len++, s++ )
+;
+
+
+  if ( !minus )
+for ( i=len ; i= PARAM_VALUE (PARAM_MAX_JUMP_THREAD_DUPLICATION_STMTS)))
+   {
+ if (dump_file && (dump_flags 

Re: [wwwdocs] [PATCH] Add "id" attributes to the headings in the GCC 6 porting guide

[Gerald Pfeifer]

Hi David,

On Tue, 1 Mar 2016, David Malcolm wrote:
> The attached patch adds "id" attributes to every h2, h3 and h4 element
> in the page, so that people can create URLs that reference specific
> subsections of the guide.

this is a great idea!

Allow me to suggest some potential tweaks wrt to the actual choices.

The patch is fine if you consider these (which is not the same is
necessarily implementing all of them though I might be disappointed
if you discard all of them ;-).

+C++ language issues

Here I believe "cxx" is more natural/common.

+Default standard is now GNU++14

"gxx14", perhaps?  Consider this a weaker recommendation than "cxx"
above, though.

+Call of overloaded 'abs(unsigned 
int)' is ambiguous

Somehow I couldn't help thinking about a six packs here. ;-)

+Deprecation of std::auto_ptr

Here, how about just using "auto_ptr"?

Gerald

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[H.J. Lu]

On Mon, Feb 29, 2016 at 5:02 PM, Jason Merrill  wrote:
> On 01/27/2016 10:39 AM, H.J. Lu wrote:
>>
>> Here is the updated patch with new testcases.  OK for trunk?
>
>
> This is not a complete patch.
>
> Please update type_is_empty_record_p to use the definition from the recent
> discussion:

Here are 3 patches.  If all targets should follow x86 backends
on passing empty types, only first 2 patches are needed.  Otherwise
the 3rd patch is needed to limit this to x86 targets.

>> An empty type is a type where it and all of its subobjects (recursively)
>> are of class, structure, union, or array type.
>
>
> This shouldn't need to rely on the front-end setting a flag.  Be sure to
> ignore unnamed bit-fields, as they are not subobjects.

Done.

> I would also suggest having this function abort if the type is
> TREE_ADDRESSABLE.
>

I have

bool
type_is_empty_type_p (const_tree type)
{
...
 if (TREE_ADDRESSABLE (type))
return false;
...
}

since any type may be passed to it.

Tested on x86-64 with

RUNTESTFLAGS="--target_board='unix{-mx32,-m32,}'"

OK for trunk?

Thanks.

-- 
H.J.
From 49bf71d9e6983b20150061ccd7332d4b73309cad Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Sun, 15 Nov 2015 13:19:05 -0800
Subject: [PATCH 1/3] Properly pass empty type for i386 targets

According to x86 psABIs, no memory slot nor register should be used to
pass or return an object of empty type whose address isn't needed.
Middle-end and x86 backend are updated to ignore empty types, whose
address aren't needed, for parameter passing and function value return.
Other targets need similar changes if they want to follow x86 psABIs.

get_ref_base_and_extent is changed to set bitsize to 0 for empty types
so that when ref_maybe_used_by_call_p_1 calls get_ref_base_and_extent to
get 0 as the maximum size on empty type.  Otherwise, find_tail_calls
won't perform tail call optimization for functions with empty type
parameters, as shown in g++.dg/pr68355.C.

This ABI change is enabled only if the ABI level is at least 10, which
is updated in GCC 6.

gcc/

	PR c++/60336
	PR middle-end/67239
	PR target/68355
	* calls.c (initialize_argument_information): Warn empty type
	if they are used in a variable argument list or aren't the last
	arguments.  Replace targetm.calls.function_arg,
	targetm.calls.function_incoming_arg and
	targetm.calls.function_arg_advance with function_arg,
	function_incoming_arg and function_arg_advance.
	(expand_call): Replace targetm.calls.function_arg,
	targetm.calls.function_incoming_arg and
	targetm.calls.function_arg_advance with function_arg,
	function_incoming_arg and function_arg_advance.
	(emit_library_call_value_1): Likewise.
	(store_one_arg): Use 0 for empty type size.  Don't
	push 0 size argument onto stack.
	(must_pass_in_stack_var_size_or_pad): Return false for empty
	type.
	* dse.c (get_call_args): Replace targetm.calls.function_arg
	and targetm.calls.function_arg_advance with function_arg and
	function_arg_advance.
	* explow.c (hard_function_value): Use 0 for empty type size.
	* expr.c (block_move_libcall_safe_for_call_parm): Replace
	targetm.calls.function_arg and targetm.calls.function_arg_advance
	with function_arg and function_arg_advance.
	(copy_blkmode_to_reg): Use 0 for empty type size.
	* function.c (aggregate_value_p): Replace
	targetm.calls.return_in_memory with return_in_memory.
	(assign_parm_data_all): Add warn_empty_type.
	(assign_parms_augmented_arg_list): Set warn_empty_type if
	empty types are used in a variable argument list or aren't
	the last arguments.
	(assign_parm_find_entry_rtl): Warn empty type if warn_empty_type
	is set.  Replace
	targetm.calls.function_incoming_arg with function_incoming_arg.
	(assign_parms): Only warn empty type once.  Replace
	targetm.calls.function_arg_advance with function_arg_advance.
	(gimplify_parameters): Replace targetm.calls.function_arg_advance
	with function_arg_advance.
	(locate_and_pad_parm): Use 0 for empty type size.
	(warn_empty_type): New function.
	(function_arg_advance): New wrapper function.
	(function_arg): Likewise.
	(function_incoming_arg): Likewise.
	(return_in_memory): Likewise.
	* target.h (function_arg_advance): New prototype.
	(function_arg): Likewise.
	(function_incoming_arg): Likewise.
	(return_in_memory): Likewise.
	* targhooks.c (std_gimplify_va_arg_expr): Use 0 for empty type
	size.
	* tree-dfa.c (get_ref_base_and_extent): Likewise.
	* tree.c (is_empty_type): New functiom.
	(type_is_empty_type_p): Likewise.
	* tree.h (type_is_empty_type_p): New prototype.
	* var-tracking.c (prepare_call_arguments): Replace
	targetm.calls.function_arg and targetm.calls.function_arg_advance
	with function_arg and function_arg_advance.
	* config/i386/i386.c (ix86_gimplify_va_arg): Use 0 for empty
	type size.

gcc/testsuite/

	PR c++/60336
	PR middle-end/67239
	PR target/68355
	* g++.dg/abi/empty12.C: New test.
	* g++.dg/abi/empty12.h: Likewise.
	* g++.dg/abi/empty12a.c: Likewise.
	* g++.dg/abi/empty13.C: Likewise.

Fix PR rtl-optimization/70007

[Eric Botcazou]

It's a regression present on all active branches caused by the RTL enhanced 
load motion optimization (-fgcse-lm), which performs PRE on "simple" MEMs and 
discards all other memory references.  The problem is that it fails to discard 
a particular memory reference present in a REG_EQUAL note:

(insn 7 6 8 3 (parallel [
(set (reg:DI 88 [ _4 ])
(rotatert:DI (reg:DI 117 [ v32u64_1+24 ])
(const_int 19 [0x13])))
(clobber (reg:CC 17 flags))
]) pr70007.c:10 607 {*rotrdi3_1}
 (expr_list:REG_DEAD (reg:DI 117 [ v32u64_1+24 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (rotatert:DI (mem/j/c:DI (plus:DI (reg/f:DI 
16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])
(const_int 19 [0x13]))
(nil)

because it only considers REG_EQUAL notes attached to SET patterns.  Here it's 
a PARALLEL with a single SET and that's allowed by set_for_reg_notes.

Tested on x86_64-suse-linux, applied on all active branches.


2016-03-01  Eric Botcazou  

PR rtl-optimization/70007
* gcse.c (compute_ld_motion_mems): Tidy up and also invalidate memory
references present in REG_EQUAL notes attached to non-SET patterns.


2016-03-01  Eric Botcazou  

* gcc.target/i386/pr70007.c: New test.

-- 
Eric Botcazou/* PR rtl-optimization/70007 */
/* { dg-do run } */
/* { dg-options "-O -fgcse -mbmi2" } */
/* { dg-require-effective-target bmi2 } */

typedef unsigned short v32u16 __attribute__ ((vector_size (32)));
typedef unsigned long long v32u64 __attribute__ ((vector_size (32)));
typedef unsigned __int128 u128;
typedef unsigned __int128 v32u128 __attribute__ ((vector_size (32)));

u128
foo (v32u16 v32u16_0, v32u64 v32u64_0, v32u64 v32u64_1)
{
  do {
v32u16_0[13] |= v32u64_1[3] = (v32u64_1[3] >> 19) | (v32u64_1[3] << 45);
v32u64_1 %= ~v32u64_1;
v32u64_0 *= (v32u64) v32u16_0;
  } while (v32u64_0[0]);
  return v32u64_1[3];
}

int
main (void)
{
  u128 x = foo((v32u16){~0xba31, 0x47c6}, (v32u64){64}, (v32u64){0, 0x8b217e2514d23242, 0xac569b6dff9f82, 0x9d4cffe03c139c});
  if (x != 0x3c74da5ca328d09)
__builtin_abort();
  return 0;
}
Index: gcse.c
===
--- gcse.c	(revision 233840)
+++ gcse.c	(working copy)
@@ -3796,10 +3796,8 @@ compute_ld_motion_mems (void)
 		{
 		  rtx src = SET_SRC (PATTERN (insn));
 		  rtx dest = SET_DEST (PATTERN (insn));
-		  rtx note = find_reg_equal_equiv_note (insn);
-		  rtx src_eq;
 
-		  /* Check for a simple LOAD...  */
+		  /* Check for a simple load.  */
 		  if (MEM_P (src) && simple_mem (src))
 		{
 		  ptr = ldst_entry (src);
@@ -3814,12 +3812,11 @@ compute_ld_motion_mems (void)
 		  invalidate_any_buried_refs (src);
 		}
 
-		  if (note != 0 && REG_NOTE_KIND (note) == REG_EQUAL)
-		src_eq = XEXP (note, 0);
-		  else
-		src_eq = NULL_RTX;
-
-		  if (src_eq != NULL_RTX
+		  /* Check for a simple load through a REG_EQUAL note.  */
+		  rtx note = find_reg_equal_equiv_note (insn), src_eq;
+		  if (note
+		  && REG_NOTE_KIND (note) == REG_EQUAL
+		  && (src_eq = XEXP (note, 0))
 		  && !(MEM_P (src_eq) && simple_mem (src_eq)))
 		invalidate_any_buried_refs (src_eq);
 
@@ -3843,7 +3840,17 @@ compute_ld_motion_mems (void)
 		}
 		}
 	  else
-		invalidate_any_buried_refs (PATTERN (insn));
+		{
+		  /* Invalidate all MEMs in the pattern and...  */
+		  invalidate_any_buried_refs (PATTERN (insn));
+
+		  /* ...in REG_EQUAL notes for PARALLELs with single SET.  */
+		  rtx note = find_reg_equal_equiv_note (insn), src_eq;
+		  if (note
+		  && REG_NOTE_KIND (note) == REG_EQUAL
+		  && (src_eq = XEXP (note, 0)))
+		invalidate_any_buried_refs (src_eq);
+		}
 	}
 	}
 }

Re: [PATCH, rs6000] Fixing PR 67145

[Peter Bergner]

On Mon, 2016-02-29 at 20:45 -0600, Segher Boessenkool wrote:
> On Mon, Feb 29, 2016 at 11:11:11AM -0800, Richard Henderson wrote:
> > > Where are these canonicalization rules described?
> > 
> > swap_commutative_operands_p?
> 
> That function never swaps reg+reg, or I don't see it.

commutative_operand_precedence gives registers that hold pointers
a higher precedence than registers that don't hold pointers, so
it can swap reg+reg if the second reg holds a pointer.
We did this as part of PR28690.

Peter

Re: [hsa, testsuite] Suppress hsa warnings in libgomp tests

[Jakub Jelinek]

On Tue, Mar 01, 2016 at 10:47:46PM +0100, Martin Jambor wrote:
> well, exactly what I wrote in the original email and what you have
> quoted (and me as well) above.  But let me quote the dejagnu source
> comment of dg-runtest, which is perhaps more clear:
> 
>   # FLAGS is a set of options to always pass.
>   # DEFAULT_EXTRA_FLAGS is a set of options to pass if the testcase
>   # doesn't
>   # specify any (with dg-option).
> 
> So if I changed DEFAULT_EXTRA_FLAGS rather than FLAGS, I'd have to go
> through all testcases specifying dg-options and add -Wno-hsa there
> too.  Moreover, we'd have to add -Wno-hsa to all appropriate future
> testcases if they specify their own dg-options.

Ah, ok; what about adding
# Disable HSA warnings by default.
lappend ALWAYS_CFLAGS "additional_flags=-Wno-hsa"
in libgomp/testsuite/lib/libgomp.exp (next to e.g.
-fno-diagnostics-show-caret)?

Jakub

Re: [hsa, testsuite] Suppress hsa warnings in libgomp tests

[Martin Jambor]

Hi

On Tue, Mar 01, 2016 at 07:47:49PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 01, 2016 at 07:39:18PM +0100, Martin Jambor wrote:
> > as Jakub requested, this patch deals with HSA "excess errors" in the
> > libgomp library testsuite by passing -Wno-hsa to all of them.  IIUC,
> > that passing it in the second parameter of dg-runtest (as opposed to
> > the third) means that it will apply even tests that have their own
> > dg-options, which is presumably easier for everyone, provided that hsa
> > will get is own libgomp testsuite directories.
> 
> What is the difference betwee the $flags and $default-extra-cflags
> arguments to dg-runtest?

well, exactly what I wrote in the original email and what you have
quoted (and me as well) above.  But let me quote the dejagnu source
comment of dg-runtest, which is perhaps more clear:

  # FLAGS is a set of options to always pass.
  # DEFAULT_EXTRA_FLAGS is a set of options to pass if the testcase
  # doesn't
  # specify any (with dg-option).

So if I changed DEFAULT_EXTRA_FLAGS rather than FLAGS, I'd have to go
through all testcases specifying dg-options and add -Wno-hsa there
too.  Moreover, we'd have to add -Wno-hsa to all appropriate future
testcases if they specify their own dg-options.

Perhaps we should be using dg-additional-options in libgomp testsuite
wherever possible but there certainly are testcases using dg-options.

> You seem to stick -Wno-hsa into the former,
> which to me looks like it will be mentioned as part of the test
> names (e.g. when cycling through -O* options, -Wno-hsa would be printed
> along with -O2 etc.)?

Yes, that is an unfortunate side-effect. Furthermore, automated
comparison scripts might be confused by the change (mine was,
reporting all testcases as newly passed/xfailed and old as
disappeared).

But again, I do not have a strong preference, I can change the patches
to use DEFAULT_EXTRA_FLAGS and am willing to be watching for fallout
and fixing dg-options if you prefer that.  So let me know what you
consider nicer and I'll do it.

Thanks,

Martin

[PATCH][PR tree-optimization/69196] Improve accounting in backwards (FSM) threader

[Jeff Law]

Another step along the path to fixing 69196.  As I was investigating the 
regression, one of the things that became quite clear was that we'd 
greatly increased the number of PHIs and many of the PHI arguments were 
constants (which in turn never coalesce and thus generate a constant 
initialization).


I think this addresses the accounting issues relevant to 69196 in the 
backwards (FSM) threader.  I don't expect this patch in and of itself to 
have any significant impact on the testcase -- it's just preparatory 
work for the clamp.


Bootstrapped and regression tested on x86_64-linux-gnu.  Installed on 
the trunk.


Jeff
commit 5810fc48902c737b3e0ea24bd2a709edbde41ff2
Author: Jeff Law 
Date:   Tue Mar 1 14:41:35 2016 -0700

PR tree-optimization/69196
* tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
Do count some PHIs in the thread path against the insn count.  Decrease
final statement count by one as the control statement in the last
block will get removed.  Remove special cased code for handling PHIs
in the last block.

PR tree-optimization/69196
* gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
duplicating code and spoiling the expected output.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b758d42..c1f2557 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2016-03-01  Jeff Law  
+
+   PR tree-optimization/69196
+   * tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
+   Do count some PHIs in the thread path against the insn count.  Decrease
+   final statement count by one as the control statement in the last
+   block will get removed.  Remove special cased code for handling PHIs
in the last block.
+
 2016-03-01  Uros Bizjak  
 
PR target/70027
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 000ece8..ef8a987 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2016-03-01  Jeff Law  
+
+   PR tree-optimization/69196
+   * gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
+   duplicating code and spoiling the expected output.
+
 2016-03-01  Michael Meissner  
 
PR target/70033
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c 
b/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
index 8923eb4..d3c9ed1 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-vrp1" } */
+/* { dg-options "-O2 -fdump-tree-vrp1 --param fsm-scale-path-blocks=1" } */
 
 int func_81 (int);
 int func_98 (int);
diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 55dbcad..3028504 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -286,6 +286,37 @@ fsm_find_control_statement_thread_paths (tree name,
  break;
}
 
+ /* PHIs in the path will create degenerate PHIS in the
+copied path which will then get propagated away, so
+looking at just the duplicate path the PHIs would
+seem unimportant.
+
+But those PHIs, because they're assignments to objects
+typically with lives that exist outside the thread path,
+will tend to generate PHIs (or at least new PHI arguments)
+at points where we leave the thread path and rejoin
+the original blocks.  So we do want to account for them.
+
+We ignore virtual PHIs.  We also ignore cases where BB
+has a single incoming edge.  That's the most common
+degenerate PHI we'll see here.  Finally we ignore PHIs
+that are associated with the value we're tracking as
+that object likely dies.  */
+ if (EDGE_COUNT (bb->succs) > 1 && EDGE_COUNT (bb->preds) > 1)
+   {
+ for (gphi_iterator gsip = gsi_start_phis (bb);
+  !gsi_end_p (gsip);
+  gsi_next ())
+   {
+ gphi *phi = gsip.phi ();
+ tree dst = gimple_phi_result (phi);
+
+ if (SSA_NAME_VAR (dst) != SSA_NAME_VAR (name)
+ && !virtual_operand_p (dst))
+   ++n_insns;
+   }
+   }
+
  for (gsi = gsi_after_labels (bb);
   !gsi_end_p (gsi);
   gsi_next_nondebug ())
@@ -324,6 +355,11 @@ fsm_find_control_statement_thread_paths (tree name,
threaded_through_latch = true;
 

[PATCH], Make Power9 tests check if compiler supports power9

[Michael Meissner]

I noticed that several of the power9 tests do not check if the power9 support
was built into the compiler.  This patch fixes this.  I'm going to apply these
patches as being obvious.

2016-03-01  Michael Meissner  

PR target/70033
* gcc.target/powerpc/p9-lxvx-stxvx-1.c: Make sure compiler
supports power9 before doing tests.
* gcc.target/powerpc/p9-lxvx-stxvx-2.c: Likewise.
* gcc.target/powerpc/p9-lxvx-stxvx-3.c: Likewise.
* gcc.target/powerpc/p9-permute.c: Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-1.c
===
--- gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-1.c  (revision 233835)
+++ gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-1.c  (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile { target { powerpc64le-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-options "-mcpu=power9 -O3" } */
 /* { dg-final { scan-assembler "lxvx" } } */
 /* { dg-final { scan-assembler "stxvx" } } */
Index: gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-2.c
===
--- gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-2.c  (revision 233835)
+++ gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-2.c  (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile { target { powerpc64le-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-options "-mcpu=power9 -O1" } */
 /* { dg-final { scan-assembler "lxvx" } } */
 /* { dg-final { scan-assembler "stvewx" } } */
Index: gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-3.c
===
--- gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-3.c  (revision 233835)
+++ gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-3.c  (working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc64le-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
 /* { dg-options "-mcpu=power9 -O3" } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-final { scan-assembler "lxvx" } } */
 /* { dg-final { scan-assembler "stxvx" } } */
 /* { dg-final { scan-assembler-not "lxvd2x" } } */
Index: gcc/testsuite/gcc.target/powerpc/p9-permute.c
===
--- gcc/testsuite/gcc.target/powerpc/p9-permute.c   (revision 233835)
+++ gcc/testsuite/gcc.target/powerpc/p9-permute.c   (working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc64le-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
 /* { dg-options "-mcpu=power9 -O2" } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
 
 #include 
 

RE: Fwd: DEC Extension Patches: Structure, Union, and Map

[Fritz Reese]

Please see the original thread
https://gcc.gnu.org/ml/fortran/2016-03/msg2.html.

I have to send the patches separately, as together they cause me to be
blocked for spamming. This is the big one, patch 4. It is compressed
with gzip since it is 150KB uncompressed.


---
Fritz Reese


0004-2016-03-01-Fritz-Reese-fritzoreese-gmail.com.patch.gz
Description: GNU Zip compressed data

Re: [PATCH,testsuite] Print markers to stderr to avoid races with sanitizer output

[Bernd Schmidt]

On 03/01/2016 02:20 PM, Maxim Kuvyrkov wrote:

On Mar 1, 2016, at 12:31 PM, Maxim Kuvyrkov  wrote:

This patch improves sanitizer testsuite to avoid sporadic failures, especially 
when [cross-]testing on a remote machine.

There are several unstable sanitizer tests in GCC testsuite (e.g., 
g++.dg/tsan/aligned_vs_unaligned_race.C), and the instability comes from the 
test doing this:

printf("Pass\n");
/* { dg-output "WARNING: ThreadSanitizer: data race.*(\n|\r\n|\r)" } */
/* { dg-output "Pass.*" } */

.  Thread sanitizer prints its data to stderr, and then printf prints to stdout.  The 
testcase expects stderr to be flushed before stdout, and "Pass" to be at the 
end of the output.  AFAIK, that works fine in native/local environment, but fails in 
remote testing from time to time.  The failure case happens when stdout output is printed 
before stderr output.  This is, likely, because there is no strict ordering of stdout and 
stderr when remote testing.

This patch fixes the affected tests in GCC testsuite, and I'll be also posting 
a similar patch for LLVM testsuite.


FYI, this was posted to LLVM (and approved) here: 
http://reviews.llvm.org/D17757 .


I guess it's OK then.


Bernd

RE: Fwd: DEC Extension Patches: Structure, Union, and Map

[Fritz Reese]

Please see the original thread
https://gcc.gnu.org/ml/fortran/2016-03/msg2.html.

I have to send the patches separately, as together they cause me to be
blocked for spamming. This is patch 3:


---
Fritz Reese
From 93e96b8a9e62c0413e6d9d33c01fa7825ecd9ee4 Mon Sep 17 00:00:00 2001
From: Fritz O. Reese 
Date: Thu, 13 Nov 2014 14:41:04 -0500
Subject: [PATCH 3/4] 2014-11-13  Fritz Reese  

gcc/fortran/
	* parse.c (check_component): New function.
(parse_derived): Move loop code to check_component.
---
 gcc/fortran/parse.c |  343 +++
 1 files changed, 179 insertions(+), 164 deletions(-)

diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 7bce47f..1374c13 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -2646,6 +2646,184 @@ error:
 }
 
 
+/* Set attributes for the parent symbol based on the attributes of a component
+   and raise errors if conflicting attributes are found for the component.  */
+
+static void
+check_component (gfc_symbol *sym, gfc_component *c, gfc_component **lockp,
+gfc_component **eventp)
+{
+  bool coarray, lock_type, event_type, allocatable, pointer;
+  coarray = lock_type = event_type = allocatable = pointer = false;
+  gfc_component *lock_comp, *event_comp;
+
+  lock_comp = *lockp;
+  event_comp = *eventp;
+
+  /* Look for allocatable components.  */
+  if (c->attr.allocatable
+  || (c->ts.type == BT_CLASS && c->attr.class_ok
+  && CLASS_DATA (c)->attr.allocatable)
+  || (c->ts.type == BT_DERIVED && !c->attr.pointer
+  && c->ts.u.derived->attr.alloc_comp))
+{
+  allocatable = true;
+  sym->attr.alloc_comp = 1;
+}
+
+  /* Look for pointer components.  */
+  if (c->attr.pointer
+  || (c->ts.type == BT_CLASS && c->attr.class_ok
+  && CLASS_DATA (c)->attr.class_pointer)
+  || (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.pointer_comp))
+{
+  pointer = true;
+  sym->attr.pointer_comp = 1;
+}
+
+  /* Look for procedure pointer components.  */
+  if (c->attr.proc_pointer
+  || (c->ts.type == BT_DERIVED
+  && c->ts.u.derived->attr.proc_pointer_comp))
+sym->attr.proc_pointer_comp = 1;
+
+  /* Looking for coarray components.  */
+  if (c->attr.codimension
+  || (c->ts.type == BT_CLASS && c->attr.class_ok
+  && CLASS_DATA (c)->attr.codimension))
+{
+  coarray = true;
+  sym->attr.coarray_comp = 1;
+}
+ 
+  if (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.coarray_comp
+  && !c->attr.pointer)
+{
+  coarray = true;
+  sym->attr.coarray_comp = 1;
+}
+
+  /* Looking for lock_type components.  */
+  if ((c->ts.type == BT_DERIVED
+  && c->ts.u.derived->from_intmod == INTMOD_ISO_FORTRAN_ENV
+  && c->ts.u.derived->intmod_sym_id == ISOFORTRAN_LOCK_TYPE)
+  || (c->ts.type == BT_CLASS && c->attr.class_ok
+  && CLASS_DATA (c)->ts.u.derived->from_intmod
+ == INTMOD_ISO_FORTRAN_ENV
+  && CLASS_DATA (c)->ts.u.derived->intmod_sym_id
+ == ISOFORTRAN_LOCK_TYPE)
+  || (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.lock_comp
+  && !allocatable && !pointer))
+{
+  lock_type = 1;
+  lock_comp = c;
+  sym->attr.lock_comp = 1;
+}
+
+/* Looking for event_type components.  */
+if ((c->ts.type == BT_DERIVED
+&& c->ts.u.derived->from_intmod == INTMOD_ISO_FORTRAN_ENV
+&& c->ts.u.derived->intmod_sym_id == ISOFORTRAN_EVENT_TYPE)
+|| (c->ts.type == BT_CLASS && c->attr.class_ok
+&& CLASS_DATA (c)->ts.u.derived->from_intmod
+   == INTMOD_ISO_FORTRAN_ENV
+&& CLASS_DATA (c)->ts.u.derived->intmod_sym_id
+   == ISOFORTRAN_EVENT_TYPE)
+|| (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.event_comp
+&& !allocatable && !pointer))
+  {
+event_type = 1;
+event_comp = c;
+sym->attr.event_comp = 1;
+  }
+
+  /* Check for F2008, C1302 - and recall that pointers may not be coarrays
+ (5.3.14) and that subobjects of coarray are coarray themselves (2.4.7),
+ unless there are nondirect [allocatable or pointer] components
+ involved (cf. 1.3.33.1 and 1.3.33.3).  */
+
+  if (pointer && !coarray && lock_type)
+gfc_error ("Component %s at %L of type LOCK_TYPE must have a "
+   "codimension or be a subcomponent of a coarray, "
+   "which is not possible as the component has the "
+   "pointer attribute", c->name, >loc);
+  else if (pointer && !coarray && c->ts.type == BT_DERIVED
+   && c->ts.u.derived->attr.lock_comp)
+gfc_error ("Pointer component %s at %L has a noncoarray subcomponent "
+   "of type LOCK_TYPE, which must have a codimension or be a "
+   "subcomponent of a coarray", c->name, >loc);
+
+  if (lock_type && allocatable && !coarray)
+gfc_error 

RE: Fwd: DEC Extension Patches: Structure, Union, and Map

[Fritz Reese]

Please see the original thread
https://gcc.gnu.org/ml/fortran/2016-03/msg2.html.

I have to send the patches separately, as together they cause me to be
blocked for spamming. This is patch 2:

---
Fritz Reese
From 2f7077c45fdcf2d05554d9d2e22fc5261bd95661 Mon Sep 17 00:00:00 2001
From: Fritz O. Reese 
Date: Mon, 10 Nov 2014 13:34:06 -0500
Subject: [PATCH 2/4] 2014-11-10  Fritz Reese  

gcc/fortran/
	* resolve.c (resolve_component): New function.
	(resolve_fl_derived0): Move component loop code to resolve_component.
---
 gcc/fortran/resolve.c |  742 -
 1 files changed, 365 insertions(+), 377 deletions(-)

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 556c846..1c3b814 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12899,438 +12899,426 @@ check_defined_assignments (gfc_symbol *derived)
 }
 
 
-/* Resolve the components of a derived type. This does not have to wait until
-   resolution stage, but can be done as soon as the dt declaration has been
-   parsed.  */
+/* Resolve a single component of a derived type.  */
 
 static bool
-resolve_fl_derived0 (gfc_symbol *sym)
+resolve_component (gfc_component *c, gfc_symbol *sym)
 {
-  gfc_symbol* super_type;
-  gfc_component *c;
+  gfc_symbol *super_type;
 
-  if (sym->attr.unlimited_polymorphic)
+  if (c->attr.artificial)
 return true;
 
-  super_type = gfc_get_derived_super_type (sym);
+  /* F2008, C442.  */
+  if ((!sym->attr.is_class || c != sym->components)
+  && c->attr.codimension
+  && (!c->attr.allocatable || (c->as && c->as->type != AS_DEFERRED)))
+{
+  gfc_error ("Coarray component %qs at %L must be allocatable with "
+ "deferred shape", c->name, >loc);
+  return false;
+}
 
-  /* F2008, C432.  */
-  if (super_type && sym->attr.coarray_comp && !super_type->attr.coarray_comp)
+  /* F2008, C443.  */
+  if (c->attr.codimension && c->ts.type == BT_DERIVED
+  && c->ts.u.derived->ts.is_iso_c)
 {
-  gfc_error ("As extending type %qs at %L has a coarray component, "
-		 "parent type %qs shall also have one", sym->name,
-		 >declared_at, super_type->name);
+  gfc_error ("Component %qs at %L of TYPE(C_PTR) or TYPE(C_FUNPTR) "
+ "shall not be a coarray", c->name, >loc);
   return false;
 }
 
-  /* Ensure the extended type gets resolved before we do.  */
-  if (super_type && !resolve_fl_derived0 (super_type))
-return false;
+  /* F2008, C444.  */
+  if (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.coarray_comp
+  && (c->attr.codimension || c->attr.pointer || c->attr.dimension
+  || c->attr.allocatable))
+{
+  gfc_error ("Component %qs at %L with coarray component "
+ "shall be a nonpointer, nonallocatable scalar",
+ c->name, >loc);
+  return false;
+}
 
-  /* An ABSTRACT type must be extensible.  */
-  if (sym->attr.abstract && !gfc_type_is_extensible (sym))
+  /* F2008, C448.  */
+  if (c->attr.contiguous && (!c->attr.dimension || !c->attr.pointer))
 {
-  gfc_error ("Non-extensible derived-type %qs at %L must not be ABSTRACT",
-		 sym->name, >declared_at);
+  gfc_error ("Component %qs at %L has the CONTIGUOUS attribute but "
+ "is not an array pointer", c->name, >loc);
   return false;
 }
 
-  c = (sym->attr.is_class) ? sym->components->ts.u.derived->components
-			   : sym->components;
+  if (c->attr.proc_pointer && c->ts.interface)
+{
+  gfc_symbol *ifc = c->ts.interface;
 
-  bool success = true;
+  if (!sym->attr.vtype
+  && !check_proc_interface (ifc, >loc))
+return false;
 
-  for ( ; c != NULL; c = c->next)
+  if (ifc->attr.if_source || ifc->attr.intrinsic)
+{
+  /* Resolve interface and copy attributes.  */
+  if (ifc->formal && !ifc->formal_ns)
+resolve_symbol (ifc);
+  if (ifc->attr.intrinsic)
+gfc_resolve_intrinsic (ifc, >declared_at);
+
+  if (ifc->result)
+{
+  c->ts = ifc->result->ts;
+  c->attr.allocatable = ifc->result->attr.allocatable;
+  c->attr.pointer = ifc->result->attr.pointer;
+  c->attr.dimension = ifc->result->attr.dimension;
+  c->as = gfc_copy_array_spec (ifc->result->as);
+  c->attr.class_ok = ifc->result->attr.class_ok;
+}
+  else
+{
+  c->ts = ifc->ts;
+  c->attr.allocatable = ifc->attr.allocatable;
+  c->attr.pointer = ifc->attr.pointer;
+  c->attr.dimension = ifc->attr.dimension;
+  c->as = gfc_copy_array_spec (ifc->as);
+  c->attr.class_ok = ifc->attr.class_ok;
+}
+  c->ts.interface = ifc;
+  c->attr.function = ifc->attr.function;
+  c->attr.subroutine = ifc->attr.subroutine;
+
+  

RE: Fwd: DEC Extension Patches: Structure, Union, and Map

[Fritz Reese]

Please see the original message:
https://gcc.gnu.org/ml/fortran/2016-03/msg2.html

I have to send the patches separately, as together they are blocked by
the spam filter. This is part 1:



---
Fritz Reese
From 00eaf54e4cc4bb63bfbcb1ffab97cb9b593f2c6d Mon Sep 17 00:00:00 2001
From: Fritz O. Reese 
Date: Thu, 16 Oct 2014 15:35:54 -0400
Subject: [PATCH 1/4] 2014-10-16  Fritz Reese  

* gcc/fortran/module.c (dt_upper_string): Rename to gfc_dt_upper_string
(dt_lower_string): Likewise.
* gcc/fortran/gfortran.h: Make new gfc_dt_upper/lower_string global.
* gcc/fortran/class.c: Use gfc_dt_upper_string.
* gcc/fortran/decl.c: Likewise.
* gcc/fortran/symbol.c: Likewise.
---
 gcc/fortran/class.c|3 +--
 gcc/fortran/decl.c |   12 +++-
 gcc/fortran/gfortran.h |2 ++
 gcc/fortran/module.c   |   26 +-
 gcc/fortran/symbol.c   |   11 +++
 5 files changed, 22 insertions(+), 32 deletions(-)

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 6a7339f..b3e1b45 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -477,8 +477,7 @@ get_unique_type_string (char *string, gfc_symbol *derived)
   if (derived->attr.unlimited_polymorphic)
 strcpy (dt_name, "STAR");
   else
-strcpy (dt_name, derived->name);
-  dt_name[0] = TOUPPER (dt_name[0]);
+strcpy (dt_name, gfc_dt_upper_string (derived->name));
   if (derived->attr.unlimited_polymorphic)
 sprintf (string, "_%s", dt_name);
   else if (derived->module)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index d3ddda2..2b92623 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2964,9 +2964,7 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag)
  stored in a symtree with the first letter of the name capitalized; the
  symtree with the all lower-case name contains the associated
  generic function.  */
-  dt_name = gfc_get_string ("%c%s",
-			(char) TOUPPER ((unsigned char) name[0]),
-			(const char*)[1]);
+  dt_name = gfc_dt_upper_string (name);
   sym = NULL;
   dt_sym = NULL;
   if (ts->kind != -1)
@@ -3480,9 +3478,7 @@ gfc_match_import (void)
 		 letter of the name capitalized; the symtree with the all
 		 lower-case name contains the associated generic function.  */
 	  st = gfc_new_symtree (_current_ns->sym_root,
-			gfc_get_string ("%c%s",
-(char) TOUPPER ((unsigned char) name[0]),
-[1]));
+gfc_dt_upper_string (name));
 	  st->n.sym = sym;
 	  sym->refs++;
 	  sym->attr.imported = 1;
@@ -8099,9 +8095,7 @@ gfc_match_derived_decl (void)
   if (!sym)
 {
   /* Use upper case to save the actual derived-type symbol.  */
-  gfc_get_symbol (gfc_get_string ("%c%s",
-			(char) TOUPPER ((unsigned char) gensym->name[0]),
-			>name[1]), NULL, );
+  gfc_get_symbol (gfc_dt_upper_string (gensym->name), NULL, );
   sym->name = gfc_get_string (gensym->name);
   head = gensym->generic;
   intr = gfc_get_interface ();
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 33fffd8..2e6ea4b 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3174,6 +3174,8 @@ void gfc_module_done_2 (void);
 void gfc_dump_module (const char *, int);
 bool gfc_check_symbol_access (gfc_symbol *);
 void gfc_free_use_stmts (gfc_use_list *);
+const char *gfc_dt_lower_string (const char *);
+const char *gfc_dt_upper_string (const char *);
 
 /* primary.c */
 symbol_attribute gfc_variable_attr (gfc_expr *, gfc_typespec *);
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 32ee526..152574c 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -422,8 +422,8 @@ resolve_fixups (fixup_t *f, void *gp)
to convert the symtree name of a derived-type to the symbol name or to
the name of the associated generic function.  */
 
-static const char *
-dt_lower_string (const char *name)
+const char *
+gfc_dt_lower_string (const char *name)
 {
   if (name[0] != (char) TOLOWER ((unsigned char) name[0]))
 return gfc_get_string ("%c%s", (char) TOLOWER ((unsigned char) name[0]),
@@ -437,8 +437,8 @@ dt_lower_string (const char *name)
symtree/symbol name of the associated generic function start with a lower-
case character.  */
 
-static const char *
-dt_upper_string (const char *name)
+const char *
+gfc_dt_upper_string (const char *name)
 {
   if (name[0] != (char) TOUPPER ((unsigned char) name[0]))
 return gfc_get_string ("%c%s", (char) TOUPPER ((unsigned char) name[0]),
@@ -832,7 +832,7 @@ find_use_name_n (const char *name, int *inst, bool interface)
 
   /* For derived types.  */
   if (name[0] != (char) TOLOWER ((unsigned char) name[0]))
-low_name = dt_lower_string (name);
+low_name = gfc_dt_lower_string (name);
 
   i = 0;
   for (u = gfc_rename_list; u; u = u->next)
@@ -861,7 +861,7 @@ find_use_name_n (const char *name, int *inst, bool interface)
 {
   if 

Re: [PATCH] PR c/69993: improvements to wording of -Wmisleading-indentation

[Patrick Palka]

On Tue, Mar 1, 2016 at 1:51 PM, David Malcolm  wrote:
> The wording of our output from -Wmisleading-indentation is rather
> confusing, as noted by Reddit user "sysop073" here:
>  
> https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eonwd
>
>> The way they split up the warning looks designed to trick you.
>> sslKeyExchange.c:631:8: warning: statement is indented as if it were guarded 
>> by... [-Wmisleading-indentation]
>> goto fail;
>> ^~~~
>> sslKeyExchange.c:629:4: note: ...this 'if' clause, but it is not
>> if ((err = SSLHashSHA1.update(, )) != 0)
>> ^~
>> You read the first half and it sounds like goto fail; is guarding something. 
>> Why would it not be:
>> sslKeyExchange.c:631:8: warning: statement is wrongly indented... 
>> [-Wmisleading-indentation]
>> goto fail;
>> ^~~~
>> sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if' clause
>> if ((err = SSLHashSHA1.update(, )) != 0)
>> ^~
>
> I agree that the current wording is suboptimal; certainly the wording
> would be much clearer if the wording of the "warning" only spoke about the
> statement in question, and the "note"/inform should then talk about the
> not-really-guarding guard.
>
> One rewording could be:
>
> sslKeyExchange.c:631:8: warning: statement is misleadingly indented... 
> [-Wmisleading-indentation]
> goto fail;
> ^~~~
> sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if' clause, 
> but it is not
> if ((err = SSLHashSHA1.update(, )) != 0)
> ^~

I prefer this one because it makes it clear that the problem is with
the misleadingly-indented goto and not with the if.

>
> However another Reddit user ("ksion") noted here:
>   
> https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eqyih
> that:
>> This is just passive voice, there is nothing tricky about it.
>> What I find more confusing -- and what your fix preserves -- is the
>> reversed order of offending lines of code in the source file and the message.
>>
>> I'd rather go with something like this:
>> sslKeyExchange.c:629:4: warning: indentation of a statement below this 'if' 
>> clause... [-Wmisleading-indentation]
>> if ((err = SSLHashSHA1.update(, )) != 0)
>> ^~
>> sslKeyExchange.c:631:8: note: ...suggests it is guarded by the 'if' clause, 
>> but it's not
>> goto fail;
>> ^~~~
>> You can even see how the indentation is wrong in the very error message.
>
> which suggests reversing the order of the messages, so that they appear
> in "source" order.
>
> I think this is a big improvement in the readability of the warning.

Using this wording order makes it seem that the problem is with the if
statement, because we emit a warning about it and then emit "only" a
note for the misleadingly-indented goto statement.

Re: [hsa,testsuite] New directory for HSA-specific C testcases

[Mike Stump]

On Feb 26, 2016, at 8:00 AM, Martin Jambor  wrote:
> we would like a place to have some HSA-specific tests

Sounds reasonable.

> I have very little experience with tcl, expect or DejaGNU and would
> appreciate very much any feedback or guidance of anyone more
> experience in these areas.  In particular, it would probably be better
> to structure the new predicate as an effective-target one but I am not
> sure what amount of caching would I have to do manually for such a new
> runtime test.

When you run the test suite, if you have more than 1 compile of the file to 
check if offloading is available per make -j instance, yes, you should cache 
the result.  Also, the other usual failure would be to change flags and not 
change them back, this would should up in a full test suite run when you 
compare the .log file and look for changes to other parts of the test suite 
that you are not changing.

So for how to cache, just copy one of the checks that cache, proc 
check_effective_target_dfprt is a nice simple one.  It is five lines, and the 
only changes to it is the spelling of the name from dfprt to 
hsa_offloading_available and the change of the prefix of the name to 
check_effective_target_ away from check_.  What means, you have to add _nocache 
to you existing name, and copy and update those five lines.

After you do that, you should notice that the test is run once.

> After I incorporate all feedback, I would of course like to commit
> this to trunk.

So, the only potential dangerous thing I saw was was unsetenv.  In the past, 
there have been problems with it.

I’m inclined to say Ok for trunk, but would like to give RMs or other 
maintainers a chance to say please no.  Let’s give people a few days to comment 
on the patch.

[PATCH, i386]: Fix PR70027, invalid assembly syntax generated with -fno-plt -masm=intel

[Uros Bizjak]

Just add -masm=intel asm dialect alternative.

2016-03-01  Uros Bizjak  

PR target/70027
* config/i386/i386.c (ix86_output_call_insn): Add -masm=intel
asm dialect alternatives to explicit GOTPCREL calls.

testsuite/ChangeLog:

2016-03-01  Uros Bizjak  

PR target/70027
* gcc.target/i386/pr70027.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 233856)
+++ config/i386/i386.c  (working copy)
@@ -27293,14 +27293,17 @@ ix86_output_call_insn (rtx_insn *insn, rtx call_op
 
   if (SIBLING_CALL_P (insn))
 {
-  if (direct_p && ix86_nopic_noplt_attribute_p (call_op))
-   xasm = "%!jmp\t*%p0@GOTPCREL(%%rip)";
-  else if (direct_p)
-   xasm = "%!jmp\t%P0";
+  if (direct_p)
+   {
+ if (ix86_nopic_noplt_attribute_p (call_op))
+   xasm = "%!jmp\t{*%p0@GOTPCREL(%%rip)|[QWORD PTR 
%p0@GOTPCREL[rip]]}";
+ else
+   xasm = "%!jmp\t%P0";
+   }
   /* SEH epilogue detection requires the indirect branch case
 to include REX.W.  */
   else if (TARGET_SEH)
-   xasm = "%!rex.W jmp %A0";
+   xasm = "%!rex.W jmp\t%A0";
   else
xasm = "%!jmp\t%A0";
 
@@ -27338,10 +27341,13 @@ ix86_output_call_insn (rtx_insn *insn, rtx call_op
seh_nop_p = true;
 }
 
-  if (direct_p && ix86_nopic_noplt_attribute_p (call_op))
-xasm = "%!call\t*%p0@GOTPCREL(%%rip)";
-  else if (direct_p)
-xasm = "%!call\t%P0";
+  if (direct_p)
+{
+  if (ix86_nopic_noplt_attribute_p (call_op))
+   xasm = "%!call\t{*%p0@GOTPCREL(%%rip)|[QWORD PTR %p0@GOTPCREL[rip]]}";
+  else
+   xasm = "%!call\t%P0";
+}
   else
 xasm = "%!call\t%A0";
 
Index: testsuite/gcc.target/i386/pr70027.c
===
--- testsuite/gcc.target/i386/pr70027.c (nonexistent)
+++ testsuite/gcc.target/i386/pr70027.c (working copy)
@@ -0,0 +1,11 @@
+/* { dg-do assemble } */
+/* { dg-options "-fno-plt -masm=intel" } */
+/* { dg-require-effective-target masm_intel } */
+
+extern void bar (int);
+
+void
+foo (void)
+{
+  bar (123);
+}

Reinstate generic stack checking warning with LRA

[Eric Botcazou]

When stack checking is entirely done by the middle-end (default if no specific 
back-end support or forced by -fstack-check=generic), the checking for the 
prologue is actually done in the caller with a default range and the hope is 
that the callee's static frame is not too large...  There are a few tricks to 
make it sort of work, but it's obviously not bullet proof so a warning will be 
issued in the problematic cases (lot of small variables).

But it is issued at the end of reload and LRA didn't replicate it, so it will 
no longer be issued e.g. for s390, as seen under PR ada/70017.  Therefore the 
attached patch moves it to the end of do_reload and also streamlines it a bit.

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


2016-03-01  Eric Botcazou  

PR ada/70017
* ira.c (do_reload): Issue warning for generic stack checking here...
* reload1.c (reload): ...instead of here and streamline it.


2016-03-01  Eric Botcazou  

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

-- 
Eric BotcazouIndex: ira.c
===
--- ira.c	(revision 233840)
+++ ira.c	(working copy)
@@ -5404,9 +5404,8 @@ do_reload (void)
 {
   df_set_flags (DF_NO_INSN_RESCAN);
   build_insn_chain ();
-  
-  need_dce = reload (get_insns (), ira_conflicts_p);
 
+  need_dce = reload (get_insns (), ira_conflicts_p);
 }
 
   timevar_pop (TV_RELOAD);
@@ -5484,6 +5483,20 @@ do_reload (void)
   inform (DECL_SOURCE_LOCATION (decl), "for %qD", decl);
 }
 
+  /* If we are doing generic stack checking, give a warning if this
+ function's frame size is larger than we expect.  */
+  if (flag_stack_check == GENERIC_STACK_CHECK)
+{
+  HOST_WIDE_INT size = get_frame_size () + STACK_CHECK_FIXED_FRAME_SIZE;
+
+  for (int i = 0; i < FIRST_PSEUDO_REGISTER; i++)
+	if (df_regs_ever_live_p (i) && !fixed_regs[i] && call_used_regs[i])
+	  size += UNITS_PER_WORD;
+
+  if (size > STACK_CHECK_MAX_FRAME_SIZE)
+	warning (0, "frame size too large for reliable stack checking");
+}
+
   if (pic_offset_table_regno != INVALID_REGNUM)
 pic_offset_table_rtx = gen_rtx_REG (Pmode, pic_offset_table_regno);
 
Index: reload1.c
===
--- reload1.c	(revision 233840)
+++ reload1.c	(working copy)
@@ -1258,28 +1258,6 @@ reload (rtx_insn *first, int global)
 	  }
   }
 
-  /* If we are doing generic stack checking, give a warning if this
- function's frame size is larger than we expect.  */
-  if (flag_stack_check == GENERIC_STACK_CHECK)
-{
-  HOST_WIDE_INT size = get_frame_size () + STACK_CHECK_FIXED_FRAME_SIZE;
-  static int verbose_warned = 0;
-
-  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
-	if (df_regs_ever_live_p (i) && ! fixed_regs[i] && call_used_regs[i])
-	  size += UNITS_PER_WORD;
-
-  if (size > STACK_CHECK_MAX_FRAME_SIZE)
-	{
-	  warning (0, "frame size too large for reliable stack checking");
-	  if (! verbose_warned)
-	{
-	  warning (0, "try reducing the number of local variables");
-	  verbose_warned = 1;
-	}
-	}
-}
-
   free (temp_pseudo_reg_arr);
 
   /* Indicate that we no longer have known memory locations or constants.  */
/* { dg-do compile } */
/* { dg-options "-fstack-check=generic" } */

/* Check that the expected warning is issued for large frames.  */

#define ONE(s) char a##s[32];
#define TEN(s) ONE(s##0) ONE(s##1) ONE(s##2) ONE(s##3) ONE(s##4) \
   ONE(s##5) ONE(s##6) ONE(s##7) ONE(s##8) ONE(s##9)
#define HUNDRED(s) TEN(s##0) TEN(s##1) TEN(s##2) TEN(s##3) TEN(s##4) \
   TEN(s##5) TEN(s##6) TEN(s##7) TEN(s##8) TEN(s##9)

void foo(void)
{
  HUNDRED(a)
  HUNDRED(b)
} /* { dg-warning "frame size too large for reliable stack checking" } */

[PATCH, match] Fix pr68714

[Richard Henderson]

This is similar to Mark Gilsse's patch in the OP, except that it ensures that
the expression will fold back to a single condition.  I did include Richi's
patch from #c6 to make it more likely to trigger asap.

I'd appreciate feedback on the match.pd changes; it's my first time looking
into this new(ish) mini-language.


r~
* gimplify.c (gimplify_expr) [VEC_COND_EXPR]: Allow the first
argument to be is_gimple_condexpr.
* match.pd: Simplify and + ior of vec_cond.

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 7be6bd7..c434e55 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -10773,8 +10773,21 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p,
goto expr_2;
  }
 
-   case FMA_EXPR:
case VEC_COND_EXPR:
+ {
+   gimplify_status r0, r1, r2;
+   r0 = gimplify_expr (_OPERAND (*expr_p, 0), pre_p,
+   post_p, is_gimple_condexpr, fb_rvalue);
+   r1 = gimplify_expr (_OPERAND (*expr_p, 1), pre_p,
+   post_p, is_gimple_val, fb_rvalue);
+   r2 = gimplify_expr (_OPERAND (*expr_p, 2), pre_p,
+   post_p, is_gimple_val, fb_rvalue);
+   ret = MIN (MIN (r0, r1), r2);
+recalculate_side_effects (*expr_p);
+   break;
+ }
+
+   case FMA_EXPR:
case VEC_PERM_EXPR:
  /* Classified as tcc_expression.  */
  goto expr_3;
diff --git a/gcc/match.pd b/gcc/match.pd
index 5903782..4192d29 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.  If not see
real_zerop real_onep real_minus_onep
zerop
CONSTANT_CLASS_P
+   COMPARISON_CLASS_P
tree_expr_nonnegative_p
integer_valued_real_p
integer_pow2p
@@ -2452,6 +2453,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
replace if (x == 0) with tem = ~x; if (tem != 0) which is
clearly less optimal and which we'll transform again in forwprop.  */
 
+/* Simplification of vec_cond.  */
+
+(for bcode (bit_and bit_ior)
+ (simplify
+  (bcode (vec_cond COMPARISON_CLASS_P@0 integer_all_onesp@2 integer_zerop@3)
+(vec_cond COMPARISON_CLASS_P@1 @2 @3))
+  (with
+{
+  tree al = TREE_OPERAND (@0, 0);
+  tree ar = TREE_OPERAND (@0, 1);
+  tree bl = TREE_OPERAND (@1, 0);
+  tree br = TREE_OPERAND (@1, 1);
+}
+(if (operand_equal_p (al, bl, 0) && operand_equal_p (ar, br, 0))
+  (with
+   {
+ tree_code tcode
+   = bcode == BIT_AND_EXPR ? TRUTH_AND_EXPR : TRUTH_OR_EXPR;
+ tree folded
+   = combine_comparisons (UNKNOWN_LOCATION, tcode, TREE_CODE (@0),
+  TREE_CODE (@1), TREE_TYPE (@0), al, ar);
+   }
+   (if (folded)
+ (switch
+   (if (integer_truep (folded)) @2)
+   (if (integer_zerop (folded)) @3)
+   (if (COMPARISON_CLASS_P (folded))
+ { build3 (VEC_COND_EXPR, TREE_TYPE (@2), folded, @2, @3); })))
+   )
 
 /* Simplification of math builtins.  These rules must all be optimizations
as well as IL simplifications.  If there is a possibility that the new

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[DJ Delorie]

> Write a patch to deprecate it in config.gcc (search for openbsd2 to help 
> you find the right spot) and an update to the gcc6 webpage.

How's this?

Index: htdocs/gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.64
diff -p -U 5 -r1.64 changes.html
--- htdocs/gcc-6/changes.html   26 Feb 2016 14:51:16 -  1.64
+++ htdocs/gcc-6/changes.html   1 Mar 2016 19:39:19 -
@@ -424,10 +424,17 @@ within strings:
   the -march=znver1 and -mtune=znver1 options.
  

 
 
+MeP
+  
+Support for the MeP (mep-elf) architecture has been
+  deprecated and will be removed in a future GCC release.
+
+  
+
 MSP430
   
 The MSP430 compiler now has the ability to automatically distribute 
code
   and data between low memory (addresses below 64K) and high memory.  This 
only
   applies to parts that actually have both memory regions and only if the


Index: contrib/config-list.mk
===
--- contrib/config-list.mk  (revision 233861)
+++ contrib/config-list.mk  (working copy)
@@ -36,13 +36,13 @@ LIST = aarch64-elf aarch64-linux-gnu aar
   i686-wrs-vxworksae \
   i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elf \
   ia64-freebsd6 ia64-linux ia64-hpux ia64-hp-vms iq2000-elf lm32-elf \
   lm32-rtems lm32-uclinux m32c-rtems m32c-elf m32r-elf m32rle-elf m32r-rtems \
   m32r-linux m32rle-linux m68k-elf m68k-netbsdelf \
   m68k-openbsd m68k-uclinux m68k-linux m68k-rtems \
-  mcore-elf mep-elf microblaze-linux microblaze-elf \
+  mcore-elf mep-elfOPT-enable-obsolete microblaze-linux microblaze-elf \
   mips-netbsd \
   mips64el-st-linux-gnu mips64octeon-linux mipsisa64r2-linux \
   mipsisa32r2-linux-gnu mipsisa64r2-sde-elf mipsisa32-elfoabi \
   mipsisa64-elfoabi mipsisa64r2el-elf mipsisa64sr71k-elf mipsisa64sb1-elf \
   mipsel-elf mips64-elf mips64vr-elf mips64orion-elf mips-rtems \
   mips-wrs-vxworks mipstx39-elf mmix-knuth-mmixware mn10300-elf moxie-elf \
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 233861)
+++ gcc/config.gcc  (working copy)
@@ -240,12 +240,13 @@ case ${target} in
  | *-knetbsd-* \
  | *-openbsd2* \
  | *-openbsd3* \
  | avr-*rtems* \
  | h8300-*rtems*   \
  | m32r-*rtems*\
+ | mep-*   \
  )
 if test "x$enable_obsolete" != xyes; then
   echo "*** Configuration ${target} is obsolete." >&2
   echo "*** Specify --enable-obsolete to build it anyway." >&2
   echo "*** Support will be REMOVED in the next major release of GCC," >&2
   echo "*** unless a maintainer comes forward." >&2

[wwwdocs] [PATCH] Add "id" attributes to the headings in the GCC 6 porting guide

[David Malcolm]

htdocs/gcc-6/porting_to.html is now multiple screens of text.

The attached patch adds "id" attributes to every h2, h3 and h4 element
in the page, so that people can create URLs that reference specific
subsections of the guide.

Validates.

OK to commit?Index: htdocs/gcc-6/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.19
diff -u -p -r1.19 porting_to.html
--- htdocs/gcc-6/porting_to.html	1 Mar 2016 19:22:05 -	1.19
+++ htdocs/gcc-6/porting_to.html	1 Mar 2016 19:36:49 -
@@ -25,15 +25,15 @@ manner. Additions and suggestions for im
 
 
 
-Preprocessor issues
+Preprocessor issues
 
 
-C language issues
+C language issues
 
 
-C++ language issues
+C++ language issues
 
-Default standard is now GNU++14
+Default standard is now GNU++14
 
 
 GCC 6 defaults to -std=gnu++14 instead of -std=gnu++98:
@@ -51,7 +51,7 @@ in CXXFLAGS or similar vari
 changes but not the C++14 ones.  If so, use the -std=gnu++11
 command-line option.
 
-Narrowing conversions
+Narrowing conversions
 
 
 The C++11 standard does not allow "narrowing conversions" inside braced
@@ -71,7 +71,7 @@ conversion. Narrowing conversions can be
 e.g. (char)i.
 
 
-Invalid literal suffixes
+Invalid literal suffixes
 
 
 The C++11 "user-defined literals" feature allows custom suffixes to be added
@@ -84,7 +84,7 @@ the code to compile in C++11 add whitesp
 macro: printf("%" PRIu64, uint64_value).
 
 
-Cannot convert 'bool' to 'T*'
+Cannot convert 'bool' to 'T*'
 
 
 The current C++ standard only allows integer literals to be used as null
@@ -94,7 +94,7 @@ fails to compile with this error should 
 or 0, or NULL.
 
 
-Cannot convert 'std::ostream' to 'bool'
+Cannot convert 'std::ostream' to 'bool'
 
 
 As of C++11, iostream classes are no longer implicitly convertible to
@@ -111,7 +111,7 @@ or
 return static_castbool(os);
 
 
-Lvalue required as left operand of assignment with complex numbers
+Lvalue required as left operand of assignment with complex numbers
 
 
 Since C++11 (as per DR#387) the member functions real() and 
@@ -132,7 +132,7 @@ following should be used instead:
   f.real (val);
 
 
-Destructors are noexcept by default
+Destructors are noexcept by default
 
 
 As of C++11, destructors have an implicit noexcept
@@ -168,7 +168,7 @@ behavior when defining the destructor li
 ~S() noexcept(false) { throw std::runtime_error ("oops"); }
 
 
-Header dependency changes
+Header dependency changes
 
 
 The algorithm header has been changed to reduce the
@@ -179,7 +179,7 @@ As such, C++ programs that used componen
 will no longer compile.
 
 
-Header cmath changes
+Header cmath changes
 
 
 Some C libraries declare obsolete int isinf(double) or
@@ -191,7 +191,7 @@ will use them and import them into names
 instead of defining the correct signatures.
 
 
-Header math.h changes
+Header math.h changes
 
 
 The C++ library now provides its own math.h header that
@@ -202,7 +202,7 @@ Code which assumes that sin
 isfinite etc. are macros may no longer compile.
 
 
-Header stdlib.h changes
+Header stdlib.h changes
 
 
 The C++ library now provides its own stdlib.h header that
@@ -220,7 +220,7 @@ responsible for ensuring their headers w
 the C++ standard library.
 
 
-Call of overloaded 'abs(unsigned int)' is ambiguous
+Call of overloaded 'abs(unsigned int)' is ambiguous
 
 
 The additional overloads can cause the compiler to reject invalid code that
@@ -241,7 +241,7 @@ Since calling abs() on an u
 this code will become explicitly invalid as per discussion in the LWG.
 
 
-Optimizations remove null pointer checks for this
+Optimizations remove null pointer checks for this
 
 
 When optimizing, GCC now assumes the this pointer can never be
@@ -260,7 +260,7 @@ this optimization. That option also disa
 pointers, not only those involving this.
 
 
-Deprecation of std::auto_ptr
+Deprecation of std::auto_ptr
 
 
 The std::auto_ptr class template was deprecated in C++11, so GCC
@@ -269,7 +269,7 @@ now warns about its usage.  This warning
 to port the code to use C++11's std::unique_ptr instead.
 
 
-'constexpr' needed for in-class initialization of static data member
+'constexpr' needed for in-class initialization of static data member
 
 
 Since C++11, the constexpr keyword is needed when initializing a
@@ -290,7 +290,7 @@ C++11 or later.  Programs relying on the
 error.  The fix is to use constexpr instead of const.
 
 
-Stricter flexible array member rules
+Stricter flexible array member rules
 
 
 As of this release, the C++ compiler is now more strict about flexible array
@@ -324,7 +324,7 @@ to T[0]).  This is a silent ABI
 -fabi-version or -Wabi option to disable or warn about.
 
 
-More aggressive optimization of -flifetime-dse
+More aggressive optimization of -flifetime-dse
 
 
 The C++ compiler (with enabled -flifetime-dse)
@@ -373,7 +373,7 @@ the option -flifetime-dse=1
 this optimization.
 
 
--Wmisleading-indentation

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[Trevor Saunders]

On Tue, Mar 01, 2016 at 11:29:25AM -0700, Jeff Law wrote:
> On 03/01/2016 11:26 AM, DJ Delorie wrote:
> >>Can we make that official?   64402, 49401 & 24998 go away when MEP is
> >>deprecated.
> >
> >We can, what's the next step?  I announced intent in Dec, nobody
> >commented or stepped up to take it.
> Write a patch to deprecate it in config.gcc (search for openbsd2 to help you
> find the right spot) and an update to the gcc6 webpage.

have we updated the web page for the other obsolete targets?

I think you also need to update config-list.mk to pass --enable-obsolete
for that target.

Trev

> 
> jeff

Re: [PATCH] Fix missing warning with bool (PR c/67854)

[Jakub Jelinek]

On Tue, Mar 01, 2016 at 08:08:03PM +0100, Marek Polacek wrote:
> On Tue, Mar 01, 2016 at 09:31:26AM -0700, Jeff Law wrote:
> > On 02/24/2016 09:31 AM, Marek Polacek wrote:
> > >The following is another issue with macros from system headers.  In this 
> > >case
> > >bool is defined in a system header to expand to _Bool and the "is promoted 
> > >to"
> > >warning didn't trigger because of that.  The fix is to use the expanded 
> > >location.
> > >
> > >Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > >
> > >2016-02-24  Marek Polacek  
> > >
> > >   PR c/67854
> > >   * gimplify.c (gimplify_va_arg_expr): Use expanded location for the
> > >   "is promoted to" warning.
> > >
> > >   * gcc.dg/pr67854.c: New test.
> > This isn't a regression, so I put it in my gcc-7 bucket.  Is this something
> > we really need to address in gcc-6?
>  
> Well, gcc4.7 warned, the warning disappeared in gcc4.8, so I think this is
> a regression.  I'm fine with deferring to 7 though.
> 
> > FWIW, I think the patch is technically fine.
> 
> Thanks,

This is ok for trunk.

Jakub

Re: [PATCH] PR c/69993: improvements to wording of -Wmisleading-indentation

[Richard Biener]

On March 1, 2016 7:51:01 PM GMT+01:00, David Malcolm  
wrote:
>The wording of our output from -Wmisleading-indentation is rather
>confusing, as noted by Reddit user "sysop073" here:
>https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eonwd
>
>> The way they split up the warning looks designed to trick you.
>> sslKeyExchange.c:631:8: warning: statement is indented as if it were
>guarded by... [-Wmisleading-indentation]
>> goto fail;
>> ^~~~
>> sslKeyExchange.c:629:4: note: ...this 'if' clause, but it is not
>> if ((err = SSLHashSHA1.update(, )) != 0)
>> ^~
>> You read the first half and it sounds like goto fail; is guarding
>something. Why would it not be:
>> sslKeyExchange.c:631:8: warning: statement is wrongly indented...
>[-Wmisleading-indentation]
>> goto fail;
>> ^~~~
>> sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if'
>clause
>> if ((err = SSLHashSHA1.update(, )) != 0)
>> ^~
>
>I agree that the current wording is suboptimal; certainly the wording
>would be much clearer if the wording of the "warning" only spoke about
>the
>statement in question, and the "note"/inform should then talk about the
>not-really-guarding guard.
>
>One rewording could be:
>
>sslKeyExchange.c:631:8: warning: statement is misleadingly indented...
>[-Wmisleading-indentation]
>goto fail;
>^~~~
>sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if'
>clause, but it is not
>if ((err = SSLHashSHA1.update(, )) != 0)
>^~
>
>However another Reddit user ("ksion") noted here:
>https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eqyih
>that:
>> This is just passive voice, there is nothing tricky about it.
>> What I find more confusing -- and what your fix preserves -- is the
>> reversed order of offending lines of code in the source file and the
>message.
>>
>> I'd rather go with something like this:
>> sslKeyExchange.c:629:4: warning: indentation of a statement below
>this 'if' clause... [-Wmisleading-indentation]
>> if ((err = SSLHashSHA1.update(, )) != 0)
>> ^~
>> sslKeyExchange.c:631:8: note: ...suggests it is guarded by the 'if'
>clause, but it's not
>> goto fail;
>> ^~~~
>> You can even see how the indentation is wrong in the very error
>message.
>
>which suggests reversing the order of the messages, so that they appear
>in "source" order.
>
>I think this is a big improvement in the readability of the warning.
>
>The attached patch implements such a change, so that the warning is
>issued on the supposed guard clause, followed by the note on the
>statement that isn't really guarded.
>
>Some examples:
>
>Wmisleading-indentation-3.c:18:3: warning: this 'for' clause does not
>guard... [-Wmisleading-indentation]
>   for (i = 0; i < 10; i++)
>   ^~~
>Wmisleading-indentation-3.c:20:5: note: ...this statement, but the
>latter is indented as if it does
> prod[i] = a[i] * b[i];
> ^~~~
>Wmisleading-indentation-3.c: In function 'fn_6':
>Wmisleading-indentation-3.c:39:2: warning: this 'if' clause does not
>guard... [-Wmisleading-indentation]
>  if ((err = foo (b)) != 0)
>  ^~
>Wmisleading-indentation-3.c:41:3: note: ...this statement, but the
>latter is indented as if it does
>   goto fail;
>   ^~~~
>
>I'm not totally convinced by my new wording; maybe the note could
>also mention the kind of clause ('if'/'while'/'else'/'for') for
>clarity, maybe something like:
>
>Wmisleading-indentation-3.c: In function 'fn_6':
>Wmisleading-indentation-3.c:39:2: warning: this 'if' clause does not
>guard... [-Wmisleading-indentation]
>  if ((err = foo (b)) != 0)
>  ^~
>Wmisleading-indentation-3.c:41:3: note: ...this statement, but the
>latter is misleadingly indented
>as if it is guarded by the 'if'
>   goto fail;
>   ^~~~
>
>Also, it's slightly clunkier when it comes to macros, e.g.:
>
>Wmisleading-indentation-3.c: In function 'fn_14':
>Wmisleading-indentation-3.c:60:3: warning: this 'for' clause does not
>guard... [-Wmisleading-indentation]
>   for ((VAR) = (START); (VAR) < (STOP); (VAR++))
>   ^
>Wmisleading-indentation-3.c:65:3: note: in expansion of macro
>'FOR_EACH'
>   FOR_EACH (i, 0, 10)
>   ^~~~
>Wmisleading-indentation-3.c:67:5: note: ...this statement, but the
>latter is indented as if it does
> bar (i, i);
> ^~~
>
>That said, the reordering idea is something I'd like to do for GCC 6.
>Failing that, there's the tweak to the wording suggested at the top.
>
>OK for trunk? (assuming we can agree on the wording, and that the
>latest
>version passes testing)

OK if others don't disagree.

Richard.

>gcc/c-family/ChangeLog:
>   PR c/69993
>   * c-indentation.c (warn_for_misleading_indentation): Rewrite the
>   diagnostic text, reversing the order of the warning and note so
>   that they appear in source order.
>
>gcc/testsuite/ChangeLog:
>   PR c/69993
>   * 

Re: [PATCH][AArch64] Replace insn to zero up DF register

[Evandro Menezes]

On 03/01/16 13:02, Wilco Dijkstra wrote:

Evandro Menezes wrote:

The meaning of these attributes are not clear to me.  Is there a
reference somewhere about which insns are FP or SIMD or neither?

The meaning should be clear, "fp" is a floating point instruction, "simd" a 
SIMD one
as defined in ARM-ARM.


Indeed, I had to add the Y for the f_mcr insn to match it with nosimd.
However, I didn't feel that it should be moved to the right, since it's
already disparaged.  Am I missing something detail?

It might not matter for this specific case, but I have seen reload forcing the 
very
first alternative without looking at any costs or preferences - as long as it 
is legal.
This suggests we need to order alternatives from most preferred alternative to 
least
preferred one.

I think it is good enough for commit, James?


Methinks that my issue with those attributes is that I'm not as fluent 
in AArch64 as I'd like to be.


Please, feel free to edit the patch changing the order then.

Thank you,

--
Evandro Menezes

Re: [PATCH] Fix missing warning with bool (PR c/67854)

[Marek Polacek]

On Tue, Mar 01, 2016 at 09:31:26AM -0700, Jeff Law wrote:
> On 02/24/2016 09:31 AM, Marek Polacek wrote:
> >The following is another issue with macros from system headers.  In this case
> >bool is defined in a system header to expand to _Bool and the "is promoted 
> >to"
> >warning didn't trigger because of that.  The fix is to use the expanded 
> >location.
> >
> >Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> >2016-02-24  Marek Polacek  
> >
> > PR c/67854
> > * gimplify.c (gimplify_va_arg_expr): Use expanded location for the
> > "is promoted to" warning.
> >
> > * gcc.dg/pr67854.c: New test.
> This isn't a regression, so I put it in my gcc-7 bucket.  Is this something
> we really need to address in gcc-6?
 
Well, gcc4.7 warned, the warning disappeared in gcc4.8, so I think this is
a regression.  I'm fine with deferring to 7 though.

> FWIW, I think the patch is technically fine.

Thanks,

Marek

Re: [hsa, testsuite] Suppress hsa warnings in libgomp tests

[Mike Stump]

On Mar 1, 2016, at 10:47 AM, Jakub Jelinek  wrote:
> What is the difference betwee the $flags and $default-extra-cflags
> arguments to dg-runtest?  You seem to stick -Wno-hsa into the former,
> which to me looks like it will be mentioned as part of the test
> names (e.g. when cycling through -O* options, -Wno-hsa would be printed
> along with -O2 etc.)?  Is there any reason not to stick it into the last
> argument instead?

Not including this option in the test case name sounds nicer.

Re: [hsa, testsuite] Suppress hsa warnings in compiler gomp tests

[Mike Stump]

On Mar 1, 2016, at 10:40 AM, Martin Jambor  wrote:
> as Jakub requested in another thread, this patch deals with HSA
> "excess errors" in the gomp compiler testsuite by passing -Wno-hsa to
> all of them.

> OK for trunk?

Ok.

Re: [PATCH][AArch64] Replace insn to zero up DF register

[Wilco Dijkstra]

Evandro Menezes wrote:
>
> The meaning of these attributes are not clear to me.  Is there a
> reference somewhere about which insns are FP or SIMD or neither?

The meaning should be clear, "fp" is a floating point instruction, "simd" a 
SIMD one
as defined in ARM-ARM.

> Indeed, I had to add the Y for the f_mcr insn to match it with nosimd.
> However, I didn't feel that it should be moved to the right, since it's
> already disparaged.  Am I missing something detail?

It might not matter for this specific case, but I have seen reload forcing the 
very
first alternative without looking at any costs or preferences - as long as it 
is legal.
This suggests we need to order alternatives from most preferred alternative to 
least
preferred one.

I think it is good enough for commit, James?

Wilco

Re: [hsa, testsuite] Suppress hsa warnings in libgomp tests

[Jakub Jelinek]

On Tue, Mar 01, 2016 at 07:39:18PM +0100, Martin Jambor wrote:
> as Jakub requested, this patch deals with HSA "excess errors" in the
> libgomp library testsuite by passing -Wno-hsa to all of them.  IIUC,
> that passing it in the second parameter of dg-runtest (as opposed to
> the third) means that it will apply even tests that have their own
> dg-options, which is presumably easier for everyone, provided that hsa
> will get is own libgomp testsuite directories.

What is the difference betwee the $flags and $default-extra-cflags
arguments to dg-runtest?  You seem to stick -Wno-hsa into the former,
which to me looks like it will be mentioned as part of the test
names (e.g. when cycling through -O* options, -Wno-hsa would be printed
along with -O2 etc.)?  Is there any reason not to stick it into the last
argument instead?

Jakub

Re: [hsa, testsuite] Suppress hsa warnings in compiler gomp tests

[Martin Jambor]

Hi,

as Jakub requested in another thread, this patch deals with HSA
"excess errors" in the gomp compiler testsuite by passing -Wno-hsa to
all of them.  IIUC, that passing it in the second parameter of
*-dg-runtest (as opposed to the third) means that it will apply even
tests that have their own dg-options, which is presumably easier for
everyone, provided that hsa will get is own libgomp testsuite
directories.

OK for trunk?

Thanks,

Martin

2016-02-29  Martin Jambor  

* g++.dg/gomp/gomp.exp: Pass -Wno-hsa to all tests.
* gcc.dg/gomp/gomp.exp: Likewise.
* gfortran.dg/gomp/gomp.exp: Likewise.
---
 gcc/testsuite/g++.dg/gomp/gomp.exp  | 2 +-
 gcc/testsuite/gcc.dg/gomp/gomp.exp  | 2 +-
 gcc/testsuite/gfortran.dg/gomp/gomp.exp | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/g++.dg/gomp/gomp.exp 
b/gcc/testsuite/g++.dg/gomp/gomp.exp
index 7365389..bee5441 100644
--- a/gcc/testsuite/g++.dg/gomp/gomp.exp
+++ b/gcc/testsuite/g++.dg/gomp/gomp.exp
@@ -29,7 +29,7 @@ dg-init
 # Main loop.
 g++-dg-runtest [lsort [concat \
[find $srcdir/$subdir *.C] \
-   [find $srcdir/c-c++-common/gomp *.c]]] "" "-fopenmp"
+   [find $srcdir/c-c++-common/gomp *.c]]] "-Wno-hsa" "-fopenmp"
 
 # All done.
 dg-finish
diff --git a/gcc/testsuite/gcc.dg/gomp/gomp.exp 
b/gcc/testsuite/gcc.dg/gomp/gomp.exp
index 78623fc..d0889c5 100644
--- a/gcc/testsuite/gcc.dg/gomp/gomp.exp
+++ b/gcc/testsuite/gcc.dg/gomp/gomp.exp
@@ -31,7 +31,7 @@ dg-init
 # Main loop.
 dg-runtest [lsort [concat \
[find $srcdir/$subdir *.c] \
-   [find $srcdir/c-c++-common/gomp *.c]]] "" "-fopenmp"
+   [find $srcdir/c-c++-common/gomp *.c]]] "-Wno-hsa" "-fopenmp"
 
 # All done.
 dg-finish
diff --git a/gcc/testsuite/gfortran.dg/gomp/gomp.exp 
b/gcc/testsuite/gfortran.dg/gomp/gomp.exp
index 625361b..78d70b5 100644
--- a/gcc/testsuite/gfortran.dg/gomp/gomp.exp
+++ b/gcc/testsuite/gfortran.dg/gomp/gomp.exp
@@ -30,7 +30,7 @@ dg-init
 
 # Main loop.
 gfortran-dg-runtest [lsort \
-   [find $srcdir/$subdir *.\[fF\]{,90,95,03,08} ] ] "" "-fopenmp"
+   [find $srcdir/$subdir *.\[fF\]{,90,95,03,08} ] ] "-Wno-hsa" "-fopenmp"
 
 # All done.
 dg-finish
-- 
2.7.1

Re: [hsa, testsuite] Suppress hsa warnings in libgomp tests

[Martin Jambor]

Hi,

On Fri, Feb 26, 2016 at 05:07:56PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 26, 2016 at 04:59:57PM +0100, Martin Jambor wrote:
> > just like with the compiler gomp testsuite, we need to add -Wno-hsa to
> > options when compiling libgomp testcases in order not to have "excess
> > errors" failures when HSA is enabled.

...
> 
> I don't like this very much.
> Couldn't you instead add -Wno-hsa next to -fopenmp in *.exp, and just where
> you want to explicitly check the hsa warnings, enable it manually in
> dg-options or dg-additional-options (it would need to be guarded with hsa
> being enabled etc. anyway).
> 

as Jakub requested, this patch deals with HSA "excess errors" in the
libgomp library testsuite by passing -Wno-hsa to all of them.  IIUC,
that passing it in the second parameter of dg-runtest (as opposed to
the third) means that it will apply even tests that have their own
dg-options, which is presumably easier for everyone, provided that hsa
will get is own libgomp testsuite directories.

OK for trunk?

Thanks,

Martin

2016-02-29  Martin Jambor  

* testsuite/libgomp.c/c.exp: Pass -Wno-hsa to all tests.
* testsuite/libgomp.c++/c++.exp: Likewise.
* testsuite/libgomp.fortran/fortran.exp: Likewise.
---
 libgomp/testsuite/libgomp.c++/c++.exp | 2 +-
 libgomp/testsuite/libgomp.c/c.exp | 2 +-
 libgomp/testsuite/libgomp.fortran/fortran.exp | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgomp/testsuite/libgomp.c++/c++.exp 
b/libgomp/testsuite/libgomp.c++/c++.exp
index 0454f95..120e573 100644
--- a/libgomp/testsuite/libgomp.c++/c++.exp
+++ b/libgomp/testsuite/libgomp.c++/c++.exp
@@ -65,7 +65,7 @@ if { $lang_test_file_found } {
 }
 
 # Main loop.
-dg-runtest $tests "" "$libstdcxx_includes $DEFAULT_CFLAGS"
+dg-runtest $tests "-Wno-hsa" "$libstdcxx_includes $DEFAULT_CFLAGS"
 }
 
 # All done.
diff --git a/libgomp/testsuite/libgomp.c/c.exp 
b/libgomp/testsuite/libgomp.c/c.exp
index 300b921..d3cd144 100644
--- a/libgomp/testsuite/libgomp.c/c.exp
+++ b/libgomp/testsuite/libgomp.c/c.exp
@@ -31,7 +31,7 @@ append ld_library_path [gcc-set-multilib-library-path 
$GCC_UNDER_TEST]
 set_ld_library_path_env_vars
 
 # Main loop.
-dg-runtest $tests "" $DEFAULT_CFLAGS
+dg-runtest $tests "-Wno-hsa" $DEFAULT_CFLAGS
 
 # All done.
 dg-finish
diff --git a/libgomp/testsuite/libgomp.fortran/fortran.exp 
b/libgomp/testsuite/libgomp.fortran/fortran.exp
index 9e6b643..ea84d5c 100644
--- a/libgomp/testsuite/libgomp.fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
@@ -66,7 +66,7 @@ if { $lang_test_file_found } {
 # For Fortran we're doing torture testing, as Fortran has far more tests
 # with arrays etc. that testing just -O0 or -O2 is insufficient, that is
 # typically not the case for C/C++.
-gfortran-dg-runtest $tests "" ""
+gfortran-dg-runtest $tests "-Wno-hsa" ""
 }
 
 # All done.
-- 
2.7.1

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[Jeff Law]

On 03/01/2016 11:26 AM, DJ Delorie wrote:

Can we make that official?   64402, 49401 & 24998 go away when MEP is
deprecated.


We can, what's the next step?  I announced intent in Dec, nobody
commented or stepped up to take it.
Write a patch to deprecate it in config.gcc (search for openbsd2 to help 
you find the right spot) and an update to the gcc6 webpage.


jeff

[PATCH] PR c/69993: improvements to wording of -Wmisleading-indentation

[David Malcolm]

The wording of our output from -Wmisleading-indentation is rather
confusing, as noted by Reddit user "sysop073" here:
 
https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eonwd

> The way they split up the warning looks designed to trick you.
> sslKeyExchange.c:631:8: warning: statement is indented as if it were guarded 
> by... [-Wmisleading-indentation]
> goto fail;
> ^~~~
> sslKeyExchange.c:629:4: note: ...this 'if' clause, but it is not
> if ((err = SSLHashSHA1.update(, )) != 0)
> ^~
> You read the first half and it sounds like goto fail; is guarding something. 
> Why would it not be:
> sslKeyExchange.c:631:8: warning: statement is wrongly indented... 
> [-Wmisleading-indentation]
> goto fail;
> ^~~~
> sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if' clause
> if ((err = SSLHashSHA1.update(, )) != 0)
> ^~

I agree that the current wording is suboptimal; certainly the wording
would be much clearer if the wording of the "warning" only spoke about the
statement in question, and the "note"/inform should then talk about the
not-really-guarding guard.

One rewording could be:

sslKeyExchange.c:631:8: warning: statement is misleadingly indented... 
[-Wmisleading-indentation]
goto fail;
^~~~
sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if' clause, but 
it is not
if ((err = SSLHashSHA1.update(, )) != 0)
^~

However another Reddit user ("ksion") noted here:
  
https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eqyih
that:
> This is just passive voice, there is nothing tricky about it.
> What I find more confusing -- and what your fix preserves -- is the
> reversed order of offending lines of code in the source file and the message.
>
> I'd rather go with something like this:
> sslKeyExchange.c:629:4: warning: indentation of a statement below this 'if' 
> clause... [-Wmisleading-indentation]
> if ((err = SSLHashSHA1.update(, )) != 0)
> ^~
> sslKeyExchange.c:631:8: note: ...suggests it is guarded by the 'if' clause, 
> but it's not
> goto fail;
> ^~~~
> You can even see how the indentation is wrong in the very error message.

which suggests reversing the order of the messages, so that they appear
in "source" order.

I think this is a big improvement in the readability of the warning.

The attached patch implements such a change, so that the warning is
issued on the supposed guard clause, followed by the note on the
statement that isn't really guarded.

Some examples:

Wmisleading-indentation-3.c:18:3: warning: this 'for' clause does not guard... 
[-Wmisleading-indentation]
   for (i = 0; i < 10; i++)
   ^~~
Wmisleading-indentation-3.c:20:5: note: ...this statement, but the latter is 
indented as if it does
 prod[i] = a[i] * b[i];
 ^~~~
Wmisleading-indentation-3.c: In function 'fn_6':
Wmisleading-indentation-3.c:39:2: warning: this 'if' clause does not guard... 
[-Wmisleading-indentation]
  if ((err = foo (b)) != 0)
  ^~
Wmisleading-indentation-3.c:41:3: note: ...this statement, but the latter is 
indented as if it does
   goto fail;
   ^~~~

I'm not totally convinced by my new wording; maybe the note could
also mention the kind of clause ('if'/'while'/'else'/'for') for
clarity, maybe something like:

Wmisleading-indentation-3.c: In function 'fn_6':
Wmisleading-indentation-3.c:39:2: warning: this 'if' clause does not guard... 
[-Wmisleading-indentation]
  if ((err = foo (b)) != 0)
  ^~
Wmisleading-indentation-3.c:41:3: note: ...this statement, but the latter is 
misleadingly indented
as if it is guarded by the 'if'
   goto fail;
   ^~~~

Also, it's slightly clunkier when it comes to macros, e.g.:

Wmisleading-indentation-3.c: In function 'fn_14':
Wmisleading-indentation-3.c:60:3: warning: this 'for' clause does not guard... 
[-Wmisleading-indentation]
   for ((VAR) = (START); (VAR) < (STOP); (VAR++))
   ^
Wmisleading-indentation-3.c:65:3: note: in expansion of macro 'FOR_EACH'
   FOR_EACH (i, 0, 10)
   ^~~~
Wmisleading-indentation-3.c:67:5: note: ...this statement, but the latter is 
indented as if it does
 bar (i, i);
 ^~~

That said, the reordering idea is something I'd like to do for GCC 6.
Failing that, there's the tweak to the wording suggested at the top.

OK for trunk? (assuming we can agree on the wording, and that the latest
version passes testing)

gcc/c-family/ChangeLog:
PR c/69993
* c-indentation.c (warn_for_misleading_indentation): Rewrite the
diagnostic text, reversing the order of the warning and note so
that they appear in source order.

gcc/testsuite/ChangeLog:
PR c/69993
* c-c++-common/Wmisleading-indentation-3.c: New test, based on
Wmisleading-indentation.c.
* c-c++-common/Wmisleading-indentation.c: Update thoughout to
reflect change to diagnostic text and order of messages.
* 

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[DJ Delorie]

> Can we make that official?   64402, 49401 & 24998 go away when MEP is 
> deprecated.

We can, what's the next step?  I announced intent in Dec, nobody
commented or stepped up to take it.

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[Jeff Law]

On 03/01/2016 11:05 AM, DJ Delorie wrote:

Note, though, that I'm in the process of deprecating mep...
Can we make that official?   64402, 49401 & 24998 go away when MEP is 
deprecated.


jeff

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[DJ Delorie]

Note, though, that I'm in the process of deprecating mep...

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

[DJ Delorie]

Ok.

Re: [testsuite] Invoke gdb with -batch to avoid prompts

[Mike Stump]

On Mar 1, 2016, at 6:20 AM, Rainer Orth  wrote:
> When switching from gdb 7.10 to the newly released gdb 7.11 on Solaris,
> all simulate-thread tests started to timeout

Ok.  If a domain expert prefers a different strategy, I’m fine with anything 
better as well.

Re: [PATCH][ARM] PR target/70014

[Richard Earnshaw (lists)]

On 01/03/16 17:33, Michael Collison wrote:
> This patches addresses PR 70014, where the predicates and operand do not
> match and could cause problems with the register allocator. Tested
> successfully on
> 
> arm-none-linux-gnueabi
> arm-none-linux-gnuabihf
> armeb-none-linux-gnuabihf
> arm-none-eabi
> 
> Okay for trunk?
> 
> 2016-03-01  Michael Collison  
> 
> PR target/70014
> * config/arm/arm.md (*subsi3_carryin_const): Change predicate
> for operand 1 to s_register_operand. Change predicate for operand
> 2 to arm_not_immediate_operand.
> 

OK.

R.

> 
> bugzilla-70014-upstream.patch
> 
> 
> diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
> index e67239d..47171b9 100644
> --- a/gcc/config/arm/arm.md
> +++ b/gcc/config/arm/arm.md
> @@ -883,8 +883,8 @@
>  
>  (define_insn "*subsi3_carryin_const"
>[(set (match_operand:SI 0 "s_register_operand" "=r")
> -(minus:SI (plus:SI (match_operand:SI 1 "reg_or_int_operand" "r")
> -   (match_operand:SI 2 "arm_not_operand" "K"))
> +(minus:SI (plus:SI (match_operand:SI 1 "s_register_operand" "r")
> +   (match_operand:SI 2 "arm_not_immediate_operand" 
> "K"))
>(ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
>"TARGET_32BIT"
>"sbc\\t%0, %1, #%B2"
> 

Re: [PATCH] Handle oacc region in oacc routine

[Jakub Jelinek]

On Tue, Mar 01, 2016 at 06:24:58PM +0100, Tom de Vries wrote:
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -3715,6 +3715,14 @@ check_omp_nesting_restrictions (gimple *stmt, 
> omp_context *ctx)
> kind == OMP_CLAUSE_DEPEND_SOURCE ? "source" : "sink");
>   return false;
> }
> +  if (is_gimple_omp_offloaded (stmt)
> +   && get_oacc_fn_attrib (cfun->decl) != NULL)
> + {
> +   error_at (gimple_location (stmt),
> + "OpenACC region inside of OpenACC routine, nested "
> + "parallelism not supported yet");
> +   return false;
> + }

Won't this emit the same error message even for
#pragma omp target
inside of #pragma acc routine function?  That would be misleading...

Jakub

Re: [Ada] Fix unexpectedly large frame with calls manipulating strings

[Eric Botcazou]

> This new test fails for me with -m32.

Thanks for the heads up, fixed thusly, applied.


2016-03-01  Eric Botcazou  

* gnat.dg/stack_usage3.adb: Robustify and enable for all targets.


-- 
Eric BotcazouIndex: gnat.dg/stack_usage3.adb
===
--- gnat.dg/stack_usage3.adb	(revision 233840)
+++ gnat.dg/stack_usage3.adb	(working copy)
@@ -5,9 +5,7 @@ with Ada.Text_IO; use Ada.Text_IO;
 with Stack_Usage3_Pkg; use Stack_Usage3_Pkg;
 
 procedure Stack_Usage3 is
-
 begin
-   Put_Line (Diag ("Diag line 0"));
Put_Line (Diag ("Diag line 1"));
Put_Line (Diag ("Diag line 2"));
Put_Line (Diag ("Diag line 3"));
@@ -22,7 +20,13 @@ begin
Put_Line (Diag ("Diag line 12"));
Put_Line (Diag ("Diag line 13"));
Put_Line (Diag ("Diag line 14"));
+   Put_Line (Diag ("Diag line 15"));
+   Put_Line (Diag ("Diag line 16"));
+   Put_Line (Diag ("Diag line 17"));
+   Put_Line (Diag ("Diag line 18"));
+   Put_Line (Diag ("Diag line 19"));
+   Put_Line (Diag ("Diag line 20"));
 end;
 
--- { dg-final { scan-stack-usage "\t\[0-9\]\[0-9\]\t" { target i?86-*-* x86_64-*-* } } }
+-- { dg-final { scan-stack-usage-not "\t\[0-9\]\[0-9\]\[0-9\]\[0-9\]\t" } }
 -- { dg-final { cleanup-stack-usage } }

[PATCH][ARM] PR target/70014

[Michael Collison]

This patches addresses PR 70014, where the predicates and operand do not 
match and could cause problems with the register allocator. Tested 
successfully on


arm-none-linux-gnueabi
arm-none-linux-gnuabihf
armeb-none-linux-gnuabihf
arm-none-eabi

Okay for trunk?

2016-03-01  Michael Collison  

PR target/70014
* config/arm/arm.md (*subsi3_carryin_const): Change predicate
for operand 1 to s_register_operand. Change predicate for operand
2 to arm_not_immediate_operand.

--
Michael Collison
Linaro Toolchain Working Group
michael.colli...@linaro.org

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index e67239d..47171b9 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -883,8 +883,8 @@
 
 (define_insn "*subsi3_carryin_const"
   [(set (match_operand:SI 0 "s_register_operand" "=r")
-(minus:SI (plus:SI (match_operand:SI 1 "reg_or_int_operand" "r")
-   (match_operand:SI 2 "arm_not_operand" "K"))
+(minus:SI (plus:SI (match_operand:SI 1 "s_register_operand" "r")
+   (match_operand:SI 2 "arm_not_immediate_operand" "K"))
   (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
   "TARGET_32BIT"
   "sbc\\t%0, %1, #%B2"
-- 
1.9.1

[PATCH] Handle oacc region in oacc routine

[Tom de Vries]

Hi,

this patch fixes an ICE in an openacc testcase. The patch fixes it by emitting 
an 'unsupported' error.


We've been carrying this patch for a while in the gomp-4_0-branch ( 
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01545.html ).


Build for C-only on top of trunk, ran goacc.exp regression test.

OK for stage4 trunk, if complete bootstrap/reg-test succeeds?

Thanks,
- Tom
Handle oacc region in oacc routine

2015-10-16  Tom de Vries  

	* omp-low.c (check_omp_nesting_restrictions): Check for oacc region in
	oacc routine.

	* c-c++-common/goacc/nesting-fail-1.c (f_acc_routine): Add oacc region
	in oacc routine test.

---
 gcc/omp-low.c | 8 
 gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c | 8 
 2 files changed, 16 insertions(+)

diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 989d03e..e84277b 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -3715,6 +3715,14 @@ check_omp_nesting_restrictions (gimple *stmt, omp_context *ctx)
 		  kind == OMP_CLAUSE_DEPEND_SOURCE ? "source" : "sink");
 	return false;
 	  }
+  if (is_gimple_omp_offloaded (stmt)
+	  && get_oacc_fn_attrib (cfun->decl) != NULL)
+	{
+	  error_at (gimple_location (stmt),
+		"OpenACC region inside of OpenACC routine, nested "
+		"parallelism not supported yet");
+	  return false;
+	}
   for (; ctx != NULL; ctx = ctx->outer)
 	{
 	  if (gimple_code (ctx->stmt) != GIMPLE_OMP_TARGET)
diff --git a/gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c b/gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c
index 7a36074..506a1ae 100644
--- a/gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c
+++ b/gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c
@@ -37,3 +37,11 @@ f_acc_kernels (void)
 #pragma acc exit data delete(i) /* { dg-error ".enter/exit data. construct inside of .kernels. region" } */
   }
 }
+
+#pragma acc routine
+void
+f_acc_routine (void)
+{
+#pragma acc parallel /* { dg-error "OpenACC region inside of OpenACC routine, nested parallelism not supported yet" } */
+  ;
+}

RFA: MEP: Add newlib-stdint.h to tm_file.

[Nick Clifton]

Hi DJ,

  Currently the MEP target does not define __INTPTR_TYPE__ or
  __INT32_TYPE__ which is a problem for newlib.  (The newlib header file
  _intsup.h depends upon these macros being defined).  Fortunately the
  fix is easy - add newlib-stdin.h to the tm_file list for MEP.

  So, is this patch OK to apply ?

  Tested with an mep-elf toolchain.

Cheers
  Nick

gcc/ChangeLog
2016-03-01  Nick Clifton  

* config.gcc (mep-*-elf): Add newlib-stdint.h to tm_file.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 233858)
+++ gcc/config.gcc  (working copy)
@@ -1973,7 +1973,7 @@
inhibit_libc=true
;;
 mep-*-*)
-   tm_file="dbxelf.h elfos.h ${tm_file}"
+   tm_file="dbxelf.h elfos.h ${tm_file} newlib-stdint.h"
tmake_file=mep/t-mep
c_target_objs="mep-pragma.o"
cxx_target_objs="mep-pragma.o"

Re: [PATCH PR69052]Check if loop inv can be propagated into mem ref with additional addr expr canonicalization

[Bin.Cheng]

On Thu, Feb 25, 2016 at 8:47 AM, Bin.Cheng  wrote:
> On Thu, Feb 25, 2016 at 6:39 AM, Jeff Law  wrote:
>> On 02/22/2016 02:22 AM, Bin.Cheng wrote:
>>
 My only question is why didn't you use FOR_EACH_SUBRTX_VRA from
 rtl-iter.h
 to walk the RTX expressions in collect_address_parts and
 canonicalize_address_mult?
>>>
>>> Hi Jeff,
>>> Nothing special, just I haven't used this before, also
>>> canonicalize_address_mult is alphabetically copied from fwprop.c.  One
>>> question is when rewriting SHIFT to MULT, we need to modify rtl
>>> expression in place, does FOR_EACH_SUBRTX iterator support this?  If
>>> yes, what is the behavior for modified sub-expression?
>>
>> Hmm.  The question of semantics when we change the underlying
>> sub-expressions is an interesting one.
>>
>> While I think we're OK in practice using the iterators, I think that's more
>> of an accident than by design -- if MULT/ASHIFT had a different underlying
>> RTL structure then I'm much less sure using the iterators would be safe.
> Hi Jeff,
> Yes, I thought about this too and finally decided to skip sub rtxes in
> modified MULT/ASHIFT expressions.  I think this will make the patch
> with FOR_EACH_SUBRTX iterator safe.  Although it doesn't dive into
> MULT/ASHIFT while the original one does, I don't think there is such
> case in practice, after all we can't handle such complicated address
> expression either.
>>
>> Let's go with your original patch that didn't use the iterators.  Sorry for
>> making you do the additional work/testing to build the iterator version.
> Not even a problem.
>> But after pondering the issue you raised, I think your original patch is
>> safer.
> So in conclusion, I think both versions should be safe, the iterator
> one is definitely cleaner.  It is your call which version I should
> apply.
Hi Jeff,
I tend to apply the new patch with FOR_EACH_SUBRTX because it's
clearer.  Does it work for you?  Of course if you do think it's not
that safe I will fall back to the old one.

Thanks,
bin

RE: [PATCH] Fix PR68621

[Kumar, Venkataramanan]

Hi Marek, 

Thank you for pointing out.  Yes I should add.

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 82e538e..f6bcb07 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2016-03-01  Venkataramanan Kumar  
+
+   PR tree-optimization/68621
+   * gcc.dg/tree-ssa/ifc-8.c: Adjust test.
+
 2016-02-29  Bill Schmidt  

PR target/70011
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ifc-8.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ifc-8.c
index 89a3410..81a4075 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ifc-8.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ifc-8.c
@@ -1,9 +1,10 @@

 /* { dg-do compile } */
-/* { dg-options "-Ofast -fdump-tree-ifcvt-details -fno-common 
-ftree-loop-if-convert-stores" } */
+/* { dg-options "-Ofast -fdump-tree-ifcvt-details 
-ftree-loop-if-convert-stores" } */
+/* { dg-require-visibility "" } */

 #define LEN 4096
- __attribute__((aligned (32))) float array[LEN];
+ __attribute__((visibility("hidden"), aligned (32))) float array[LEN] = {};

 void test ()
 {

Regards,
Venkat.

> -Original Message-
> From: Marek Polacek [mailto:pola...@redhat.com]
> Sent: Tuesday, March 01, 2016 10:23 PM
> To: Kumar, Venkataramanan
> Cc: Richard Beiner (richard.guent...@gmail.com); gcc-patches@gcc.gnu.org;
> hjl.to...@gmail.com
> Subject: Re: [PATCH] Fix PR68621
> 
> On Tue, Mar 01, 2016 at 04:48:40PM +, Kumar, Venkataramanan wrote:
> >  /* { dg-do compile } */
> > -/* { dg-options "-Ofast -fdump-tree-ifcvt-details -fno-common -ftree-
> loop-if-convert-stores" } */
> > +/* { dg-options "-Ofast -fdump-tree-ifcvt-details -ftree-loop-if-convert-
> stores" } */
> >
> >  #define LEN 4096
> > - __attribute__((aligned (32))) float array[LEN];
> > + __attribute__((visibility("hidden"), aligned (32))) float array[LEN] = {};
> 
> Don't you need
> /* { dg-require-visibility "" } */
> if you use __attribute__ ((visibility))?
> 
>   Marek

Re: [PATCH] Fix PR69951

[Christophe Lyon]

On 1 March 2016 at 10:51, James Greenhalgh  wrote:
> On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
>> On Mon, 29 Feb 2016, James Greenhalgh wrote:
>>
>> > On Fri, Feb 26, 2016 at 09:32:53AM +0100, Richard Biener wrote:
>> > >
>> > > The following fixes PR69951, hopefully the last case of decl alias
>> > > issues with alias analysis.  This time it's points-to and the DECL_UIDs
>> > > used in points-to sets not being canonicalized.
>> > >
>> > > The simplest (and cheapest) fix is to make aliases refer to the
>> > > ultimate alias target via their DECL_PT_UID which we conveniently
>> > > have available.
>> > >
>> > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>> > >
>> > > Richard.
>> > >
>> > > 2016-02-26  Richard Biener  
>> > >
>> > >   PR tree-optimization/69551
>> > >   * tree-ssa-structalias.c (get_constraint_for_ssa_var): When
>> > >   looking through aliases adjust DECL_PT_UID to refer to the
>> > >   ultimate alias target.
>> > >
>> > >   * gcc.dg/torture/pr69951.c: New testcase.
>> >
>> > I see this new testcase failing on an ARM target as so:
>> >
>> > /tmp/ccChjoFc.s: Assembler messages:
>> > /tmp/ccChjoFc.s:21: Warning: [-mwarn-syms]: Assignment makes a symbol 
>> > match an ARM instruction: b
>> >
>> > FAIL: gcc.dg/torture/pr69951.c   -O0  (test for excess errors)
>> >
>> > But I haven't managed to reproduce it outside of the test environment.
>> >
>> > The fix looks trivial, rename b to anything else you fancy (well... stay
>> > clear of add and ldr). I'll put a fix in myself if I can manage to get
>> > this to reproduce - though if anyone else wants to do it I won't be
>> > offended :-).
>>
>> Huh, I wonder what's the use of such warning.  After all 'ldr' is a valid
>> C symbol name, too.  In fact my cross arm as doesn't report this
>> warning (binutils 2.25.0)
>>
>> > arm-suse-linux-gnueabi-as t.s -mwarn-syms
>> Assembler messages:
>> Error: unrecognized option -mwarn-syms
>
> Right, I've figured out the set of conditions... You need to be targeting
> an arm-*-linux-* system to make sure that the ASM_OUTPUT_DEF definition
> from config/arm/linux-elf.h is pulled in. This causes us to emit:
>
> b = a
>
> Rather than
>
> .setb,a
>
> Writing it as "b = a" causes the warning added to resolve binutils
> PR18347 [1] to kick in, so you need binutils > 2.26 or to have backported
> that patch).
>
James,

What happens for you on arm-none-eabi configurations?
I'm using binutils-2.25, so I can't see this warning whatever the target.
However, I'm using qemu-arm and this test fails on arm-none-eabi,
because argc is set to 0 during the startup-code.

As I understand it, qemu-arm considers the code page as readonly,
and thus the GetCmdLine semi hosting call cannot write argc/argv
back to memory in the same code page (I'm using libgloss' crt0).

I tried to play with qemu-system-arm, but then libgloss' crt0 does not
set the reset vector and the simulation does random things, starting at
address 0.

Am I missing some newlib/libgloss configuration bits, or should I
send a newlib patch to address this?

Thanks

Christophe.


> Resolving it by hacking the testcase would be one fix, but I wonder why the
> ARM port prefers to emit "b = a" in a linux environment if .set does the
> same thing and always avoids the warning? Maybe Ramana/Richard/Kyrill/Nick
> remember? (AArch64 does the same thing, but the AArch64 gas port doesn't
> have the PR18347 fix).
>
> Cheers,
> James
>
> ---
>
> [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=18347
>
>>
>> Richard.
>>

Re: [PATCH] Fix PR68621

[Marek Polacek]

On Tue, Mar 01, 2016 at 04:48:40PM +, Kumar, Venkataramanan wrote:
>  /* { dg-do compile } */
> -/* { dg-options "-Ofast -fdump-tree-ifcvt-details -fno-common 
> -ftree-loop-if-convert-stores" } */
> +/* { dg-options "-Ofast -fdump-tree-ifcvt-details 
> -ftree-loop-if-convert-stores" } */
> 
>  #define LEN 4096
> - __attribute__((aligned (32))) float array[LEN];
> + __attribute__((visibility("hidden"), aligned (32))) float array[LEN] = {};

Don't you need
/* { dg-require-visibility "" } */
if you use __attribute__ ((visibility))?

Marek

Commit: CR16: Add newlib-stdint.h to tm_file.

[Nick Clifton]

Hi Guys,

  I am applying the patch below as an obvious fix for a problem with the
  CR16 target - the lack of a definition of __INTPTR_TYPE__.  This
  definition is needed by the newlib C library's _intsup.h header in
  order to correctly calculate the size of integers and pointers.

Cheers
  Nick

gcc/ChangeLog
2016-03-01  Nick Clifton  

* config.gcc (cr16-*-elf): Add newlib-stdint.h to tm_file.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 233857)
+++ gcc/config.gcc  (working copy)
@@ -1168,7 +1168,7 @@
use_gcc_stdint=wrap
;;
 cr16-*-elf)
-tm_file="elfos.h ${tm_file}"
+tm_file="elfos.h ${tm_file} newlib-stdint.h"
 tmake_file="${tmake_file} cr16/t-cr16 "
 use_collect2=no
 ;;

[PATCH] Fix PR68621

[Kumar, Venkataramanan]

Hi Richard,

As discussed in PR, tried to adjust the test case by initializing array, but 
looks like for building with -fpic it needs visibility to be set a hidden.
The below patch does that.


Ok for trunk ?

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 82e538e..f6bcb07 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2016-03-01  Venkataramanan Kumar  
+
+   PR tree-optimization/68621
+   * gcc.dg/tree-ssa/ifc-8.c: Adjust test.
+
 2016-02-29  Bill Schmidt  

PR target/70011
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ifc-8.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ifc-8.c
index 89a3410..7519a61 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ifc-8.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ifc-8.c
@@ -1,9 +1,9 @@

 /* { dg-do compile } */
-/* { dg-options "-Ofast -fdump-tree-ifcvt-details -fno-common 
-ftree-loop-if-convert-stores" } */
+/* { dg-options "-Ofast -fdump-tree-ifcvt-details 
-ftree-loop-if-convert-stores" } */

 #define LEN 4096
- __attribute__((aligned (32))) float array[LEN];
+ __attribute__((visibility("hidden"), aligned (32))) float array[LEN] = {};

 void test ()
 {   

[PATCH] Fix PR67278

[Richard Biener]

The following fixes a checking issue when verifying BIT_FIELD_REF
sizes of non-integral non-BLKmode types.  We should be using
MODE_SIZE, not MODE_PRECISION here as seen with the testcase.

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

typedef long double a __attribute__((vector_size (32)));

still explodes in our face - I suppose backends need to have
a lever to what we allow as component types here (after all
they define the ABI for this kind of stuff - or fail to ;))

Richard.

2016-03-01  Richard Biener  

PR middle-end/67278
* tree-cfg.c (verify_expr): Adjust BIT_FIELD_REF case.

* gcc.dg/simd-7.c: New testcase.

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 233852)
+++ gcc/tree-cfg.c  (working copy)
@@ -2959,10 +2959,10 @@ verify_expr (tree *tp, int *walk_subtree
}
  else if (!INTEGRAL_TYPE_P (TREE_TYPE (t))
   && TYPE_MODE (TREE_TYPE (t)) != BLKmode
-  && (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (t)))
+  && (GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (t)))
   != tree_to_uhwi (t1)))
{
- error ("mode precision of non-integral result does not "
+ error ("mode size of non-integral result does not "
 "match field size of BIT_FIELD_REF");
  return t;
}
Index: gcc/testsuite/gcc.dg/simd-7.c
===
--- gcc/testsuite/gcc.dg/simd-7.c   (revision 0)
+++ gcc/testsuite/gcc.dg/simd-7.c   (working copy)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+
+#if __SIZEOF_LONG_DOUBLE__ == 16 || __SIZEOF_LONG_DOUBLE__ == 8
+typedef long double a __attribute__((vector_size (16)));
+
+a __attribute__((noinline))
+sum (a first, a second)
+{
+return first + second;
+}
+
+a
+foo (a x, a y, a z)
+{
+  return sum (x, y) + z;
+}
+#endif

Re: [PATCH] Fix missing warning with bool (PR c/67854)

[Jeff Law]

On 02/24/2016 09:31 AM, Marek Polacek wrote:

The following is another issue with macros from system headers.  In this case
bool is defined in a system header to expand to _Bool and the "is promoted to"
warning didn't trigger because of that.  The fix is to use the expanded 
location.

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

2016-02-24  Marek Polacek  

PR c/67854
* gimplify.c (gimplify_va_arg_expr): Use expanded location for the
"is promoted to" warning.

* gcc.dg/pr67854.c: New test.
This isn't a regression, so I put it in my gcc-7 bucket.  Is this 
something we really need to address in gcc-6?


FWIW, I think the patch is technically fine.

Jeff

[PATCH] Additional tests for 69987, 69989, 69740

[Jeff Law]

Two additional regression tests for problems exposed by the 69740 
patches. They tickle a different path than the test HJ already checked 
in.  Obviously the idea is to have these in place so that when we attack 
69740 again, we don't regress these issues.


Installed on the trunk after verifying they PASS on the trunk.

Jeff
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 27e134f..83a41c7 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2016-02-29  Jeff Law  
+
+   PR tree-optimization/69987
+   * gfortran.dg/pr69987.f90: New test.
+
+   PR tree-optimization/69989
+   * gcc.c-torture/compile/pr69989-2.c: New test.
+
 2016-03-01  Marek Polacek  
 
PR c++/69795
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr69989-2.c 
b/gcc/testsuite/gcc.c-torture/compile/pr69989-2.c
new file mode 100644
index 000..39cd516
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr69989-2.c
@@ -0,0 +1,16 @@
+int a, b, d;
+short c[] = {4073709551611, 1, 4, 4};
+
+void fn1() {
+  if (a)
+goto LABEL_vhvhP;
+  for (;;) {
+for (; b; b++)
+  d = c[b + 3] | c[b];
+  LABEL_vhvhP:
+if (d)
+  break;
+  }
+}
+
+int main() { return 0; }
diff --git a/gcc/testsuite/gfortran.dg/pr69987.f90 
b/gcc/testsuite/gfortran.dg/pr69987.f90
new file mode 100644
index 000..6efc100
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr69987.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+! { dg-options "-O3 -fprefetch-loop-arrays" }
+
+MODULE cp_lbfgs
+  INTEGER, PARAMETER :: dp=8
+CONTAINS
+  SUBROUTINE mainlb(n, m, x, l, u, nbd, f, g, factr, pgtol, ws, wy, &
+   csave, lsave, isave, dsave)
+REAL(KIND=dp):: x(n), l(n), u(n)
+REAL(KIND=dp) :: f, g(n), factr, pgtol, ws(n, m), wy(n, m), sy(m, m), &
+  ss(m, m), wt(m, m), wn(2*m, 2*m), snd(2*m, 2*m), z(n), r(n), d(n), &
+  t(n), wa(8*m)
+CHARACTER(len=60):: task
+IF (task == 'START') THEN
+   IF (task(1:5) == 'FG_LN') GOTO 666
+ENDIF
+222 CONTINUE
+DO 40 i = 1, n
+   d(i) = z(i) - x(i)
+40  ENDDO
+666 CONTINUE
+IF (info /= 0 .OR. iback >= 20) THEN
+   CALL dcopy(n,r,1,g,1)
+ENDIF
+GOTO 222
+  END SUBROUTINE mainlb
+END MODULE cp_lbfgs
+

Re: [PATCH] Fix PR69951

[Richard Earnshaw (lists)]

On 01/03/16 10:49, Richard Biener wrote:
> On Tue, 1 Mar 2016, Ramana Radhakrishnan wrote:
> 
>>
>>
>> On 01/03/16 09:54, Richard Biener wrote:
>>> On Tue, 1 Mar 2016, James Greenhalgh wrote:
>>>
 On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
> On Mon, 29 Feb 2016, James Greenhalgh wrote:
>
>> On Fri, Feb 26, 2016 at 09:32:53AM +0100, Richard Biener wrote:
>>>
>>> The following fixes PR69951, hopefully the last case of decl alias
>>> issues with alias analysis.  This time it's points-to and the DECL_UIDs
>>> used in points-to sets not being canonicalized.
>>>
>>> The simplest (and cheapest) fix is to make aliases refer to the
>>> ultimate alias target via their DECL_PT_UID which we conveniently
>>> have available.
>>>
>>> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>>>
>>> Richard.
>>>
>>> 2016-02-26  Richard Biener  
>>>
>>> PR tree-optimization/69551
>>> * tree-ssa-structalias.c (get_constraint_for_ssa_var): When
>>> looking through aliases adjust DECL_PT_UID to refer to the
>>> ultimate alias target.
>>>
>>> * gcc.dg/torture/pr69951.c: New testcase.
>>
>> I see this new testcase failing on an ARM target as so:
>>
>> /tmp/ccChjoFc.s: Assembler messages:
>> /tmp/ccChjoFc.s:21: Warning: [-mwarn-syms]: Assignment makes a 
>> symbol match an ARM instruction: b
>>
>> FAIL: gcc.dg/torture/pr69951.c   -O0  (test for excess errors)
>>
>> But I haven't managed to reproduce it outside of the test environment.
>>
>> The fix looks trivial, rename b to anything else you fancy (well... stay
>> clear of add and ldr). I'll put a fix in myself if I can manage to get
>> this to reproduce - though if anyone else wants to do it I won't be
>> offended :-).
>
> Huh, I wonder what's the use of such warning.  After all 'ldr' is a valid
> C symbol name, too.  In fact my cross arm as doesn't report this
> warning (binutils 2.25.0)
>
>> arm-suse-linux-gnueabi-as t.s -mwarn-syms
> Assembler messages:
> Error: unrecognized option -mwarn-syms

 Right, I've figured out the set of conditions... You need to be targeting
 an arm-*-linux-* system to make sure that the ASM_OUTPUT_DEF definition
 from config/arm/linux-elf.h is pulled in. This causes us to emit:

 b = a

 Rather than

.setb,a

 Writing it as "b = a" causes the warning added to resolve binutils
 PR18347 [1] to kick in, so you need binutils > 2.26 or to have backported
 that patch).

 Resolving it by hacking the testcase would be one fix, but I wonder why the
 ARM port prefers to emit "b = a" in a linux environment if .set does the
 same thing and always avoids the warning? Maybe Ramana/Richard/Kyrill/Nick
 remember?
 (AArch64 does the same thing, but the AArch64 gas port doesn't
 have the PR18347 fix).
>>>
>>> So does b = a define a macro then and the warning is to avoid you
>>> doing
>>
>>
>>
>>
>> I don't think this is a macro, b = a seems to be a way of setting the 
>> value of a to b. in the assembler. If a is an expression , then I 
>> believe the expression is resolved at assemble time - (b ends up being a 
>> symbol in the symbol table produced with the value of a) in this case 
>> the address of a. .set b, a achieves the same thing from my experiments 
>> and reading of the sources. The reason ports appear to choose not to use 
>> the .set a, b idiom is if the assembler syntax has hijacked the .set 
>> directive for something else. Thus I don't see why we use the 
>> ASM_OUTPUT_DEF form in the GNU/Linux port TBH rather than the .set form 
>> especially as we don't reuse .set for anything else in the ARM assembler 
>> port and SET_ASM_OP is defined in config/arm/aout.h.
>>
>> The use of .set in the arm port of glibc for assembler code for the same 
>> purpose seems to also vindicate that kind of thought.
>>  No reasons were given here[1], maybe Nick or Richard remember from 
>> nearly 18 years ago ;)
>>
>>
>> Therefore this seems to be an assembler bug to me in that it doesn't 
>> allow such an assignment of values, and a backend wart to me that we 
>> have ASM_OUTPUT_DEF defined for no good reason. So, a patch that removes 
>> ASM_OUTPUT_DEF from linux-elf.h seems obvious to me pending testing.
>>
>>
>> Nick , Richard - any thoughts ?
> 
> So - why does it warn at all for this?  And why does it only warn
> for b = a and not .set b, a?
> 

Because b is the mnemonic for a branch instruction.  What follows is
probably garbage in reality if you start from that point.

> IMHO the warning is simply bogus?

I think the grammar for the '=' assignment is at best dubious, given
that the LHS could be any label and there's no guarantee that won't
conflict with a mnemonic.  .set is 

[PATCH][ARM] Add deprecation warning on pre-v4t architecture revisions

[Kyrill Tkachov]

Hi all,

For GCC 6 we want to deprecate architecture revisions prior to ARMv4T.
This patch implements this by documenting the deprecation in invoke.texi and 
adding
a warning whenever the user specifies an -march or -mcpu option that selects 
such
an architecture revision.

Bootstrapped and tested on arm.

Ok for trunk?

Thanks,
Kyrill

P.S. I'll add a note to changes.html to that effect separately.

2016-03-01  Kyrylo Tkachov  

* config/arm/arm.c (arm_option_override): Warn on pre-ARMv4T
architecture revisions.
* doc/invoke.texi (ARM Options): Add note on deprecation of pre-ARMv4T
architecture revisions.

2016-03-01  Kyrylo Tkachov  

* gcc.target/arm/ftest-armv4-arm.c: Add dg-warning for deprecation
warning.
* gcc.target/arm/pr62554.c: Likewise.
* gcc.target/arm/pr69610-1.c: Likewise.
* gcc.target/arm/pr69610-2.c: Likewise.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 520d6194a7d663685c3d2a38b2a63b9b8b4c6017..b64f0c70fc7359b87e4fad8a06bf72f691db286b 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3354,6 +3354,10 @@ arm_option_override (void)
   flag_reorder_blocks = 1;
 }
 
+  /* Pre-armv4t architecture revisions are deprecated.  */
+  if (TARGET_ARM_ARCH <= 4 && !ARM_FSET_HAS_CPU1 (insn_flags, FL_THUMB))
+warning (0, "architecture revisions earlier than ARMv4T are deprecated");
+
   if (flag_pic)
 /* Hoisting PIC address calculations more aggressively provides a small,
but measurable, size reduction for PIC code.  Therefore, we decrease
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 18b2b8f31075b6286d63d1f489c2769daac6cec5..6e0143428ed9b59b18df9ce6207054a064ab7889 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -13944,6 +13944,8 @@ of the @option{-mcpu=} option.  Permissible names are: @samp{armv2},
 @samp{armv7ve}, @samp{armv8-a}, @samp{armv8-a+crc}, @samp{armv8.1-a},
 @samp{armv8.1-a+crc}, @samp{iwmmxt}, @samp{iwmmxt2}, @samp{ep9312}.
 
+Architecture revisions older than @option{armv4t} are deprecated.
+
 @option{-march=armv7ve} is the armv7-a architecture with virtualization
 extensions.
 
diff --git a/gcc/testsuite/gcc.target/arm/ftest-armv4-arm.c b/gcc/testsuite/gcc.target/arm/ftest-armv4-arm.c
index 4b48ef803d4f53a67c4f36369cb4f537f584e7c7..b47feb99b78965dfe56a56917c1475c1dc622d3d 100644
--- a/gcc/testsuite/gcc.target/arm/ftest-armv4-arm.c
+++ b/gcc/testsuite/gcc.target/arm/ftest-armv4-arm.c
@@ -12,4 +12,5 @@
 
 #include "ftest-support.h"
 
+/* { dg-warning "architecture revisions earlier than ARMv4T are deprecated" "" { target *-*-* } 1 } */
 
diff --git a/gcc/testsuite/gcc.target/arm/pr62554.c b/gcc/testsuite/gcc.target/arm/pr62554.c
index 4d6501cba1fb5122cfa9e276766280414c338225..ef0aaa871f95201443a773e2935faed0baf40371 100644
--- a/gcc/testsuite/gcc.target/arm/pr62554.c
+++ b/gcc/testsuite/gcc.target/arm/pr62554.c
@@ -2,6 +2,7 @@
 /* { dg-do compile } */
 /* { dg-options "-marm -march=armv3 -O" } */
 /* { dg-require-effective-target arm_arm_ok } */
+/* { dg-warning "architecture revisions earlier than ARMv4T are deprecated" "" { target *-*-* } 1 } */
 
 typedef struct
 {
diff --git a/gcc/testsuite/gcc.target/arm/pr69610-1.c b/gcc/testsuite/gcc.target/arm/pr69610-1.c
index a671b93392bdac8679415cb49a3691dcbe672790..1343eb282b8a0994312d64d705120783804738d4 100644
--- a/gcc/testsuite/gcc.target/arm/pr69610-1.c
+++ b/gcc/testsuite/gcc.target/arm/pr69610-1.c
@@ -2,7 +2,7 @@
 /* { dg-do compile } */
 /* { dg-options "-marm -march=armv3 -ftree-ter" } */
 /* { dg-require-effective-target arm_arm_ok } */
-
+/* { dg-warning "architecture revisions earlier than ARMv4T are deprecated" "" { target *-*-* } 1 } */
 typedef unsigned short v16u16 __attribute__ ((vector_size (16)));
 typedef unsigned int v16u32 __attribute__ ((vector_size (16)));
 
diff --git a/gcc/testsuite/gcc.target/arm/pr69610-2.c b/gcc/testsuite/gcc.target/arm/pr69610-2.c
index e932c63b63962d95eff02ba26430e7eef454329f..eb5d72c35f97de8d0138441506fd8b28f1af6c56 100644
--- a/gcc/testsuite/gcc.target/arm/pr69610-2.c
+++ b/gcc/testsuite/gcc.target/arm/pr69610-2.c
@@ -2,7 +2,7 @@
 /* { dg-do compile } */
 /* { dg-options "-marm -march=armv3 -O2 -fno-forward-propagate" } */
 /* { dg-require-effective-target arm_arm_ok } */
-
+/* { dg-warning "architecture revisions earlier than ARMv4T are deprecated" "" { target *-*-* } 1 } */
 typedef short v16u16 __attribute__ ((vector_size (16)));
 typedef unsigned v16u32 __attribute__ ((vector_size (16)));
 typedef long long v16u64 __attribute__ ((vector_size (16)));

Re: [PATCH]Replace -shared with -r -nostdlib in gcc.dg/lto/pr61526 pr54709 pr64415 test cases.

[Renlin Li]

Hi Richard,

On 01/03/16 09:16, Richard Biener wrote:

On Mon, Feb 29, 2016 at 5:13 PM, Renlin Li  wrote:

Hi all,

The gcc.dg/lto/pr54709, pr61526, pr64415 linking testcases keep failing on
arm/aarch64 bare-metal target.

It's because statically built newlib library is used to link with shared
object.
And the linker complains about relocations which cannot be used in
shared object.

For example, the following errors are produced:

crtbegin.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be
used when making a shared object; recompile with -fPIC

crtbegin.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can
not
be used when making a shared object; recompile with -fPIC

librdimon.a(rdimon-syscalls.o): relocation R_AARCH64_ADR_PREL_PG_HI21
against
external symbol `_impure_ptr' can not be used when making a shared object;
recompile with -fPIC

Presumably, bare-metal toolchain for other architecture have those test case
failures as well?

In this patch, -shared option is replace by -r -nostdlib. So that the
standard
system startup files or libraries are not used when linking.

Note that -shared is not equivalent to -r -nostdlib so please verify that the
original issue can be still reproduced with its fix reverted but -r -nostdlib
used with the new -r -nostdlib handling on trunk.


pr54709_0.c: Cannot be reproduced with even -shared. The error message 
is the same as shown above.

pr64415_0.c: Reproduced with "-r -nostdlib".
pr61526_0.c: Reproduced with "-r -nostdlib".

By the way, those linking test cases all pass for linux toolchain. Only 
fail for aarch64/arm baremetal toolchain.


Andrew, I saw you have done similar things in r153555
https://gcc.gnu.org/viewcvs/gcc?view=revision=153555

Do you have any thoughts?

And also here, the last comments in this ticket suggests to add
check_effective_target_shared to the exp file to limit it to linux 
targets only:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526

Regards,
Renlin



Otherwise simply dg-skip for aarch64.

Richard.


arm-none-eabi, aarch64-none-elf regression test OK, OK for trunk?

Regards,
Renlin Li

gcc/testsuite/ChangeLog:

2016-02-29  Renlin Li

 * gcc.dg/lto/pr54709_0.c: Replace -shard with -r -nostdlib.
 * gcc.dg/lto/pr61526_0.c: Ditto.
 * gcc.dg/lto/pr64415_0.c: Ditto.

Re: [C++ PATCH] Fix ICE on invalid (PR c++/69795)

[Martin Sebor]

On 03/01/2016 06:38 AM, Marek Polacek wrote:

A trivial patch to fix an ICE on invalid: DECL_BUILT_IN only expects
a FUNCTION_DECL, so checking DECL_P is not enough.


You're right, that was caused by my r227458.  I vaguely remember
wondering about that when I saw the stack trace but I must have
got distracted by something else and never looked into it in more
detail.

Thanks for taking care of it!
Martin

Re: [PATCH] Fix PR69951

[Prathamesh Kulkarni]

On 1 March 2016 at 16:19, Richard Biener  wrote:
> On Tue, 1 Mar 2016, Ramana Radhakrishnan wrote:
>
>>
>>
>> On 01/03/16 09:54, Richard Biener wrote:
>> > On Tue, 1 Mar 2016, James Greenhalgh wrote:
>> >
>> >> On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
>> >>> On Mon, 29 Feb 2016, James Greenhalgh wrote:
>> >>>
>>  On Fri, Feb 26, 2016 at 09:32:53AM +0100, Richard Biener wrote:
>> >
>> > The following fixes PR69951, hopefully the last case of decl alias
>> > issues with alias analysis.  This time it's points-to and the DECL_UIDs
>> > used in points-to sets not being canonicalized.
>> >
>> > The simplest (and cheapest) fix is to make aliases refer to the
>> > ultimate alias target via their DECL_PT_UID which we conveniently
>> > have available.
>> >
>> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>> >
>> > Richard.
>> >
>> > 2016-02-26  Richard Biener  
>> >
>> > PR tree-optimization/69551
>> > * tree-ssa-structalias.c (get_constraint_for_ssa_var): When
>> > looking through aliases adjust DECL_PT_UID to refer to the
>> > ultimate alias target.
>> >
>> > * gcc.dg/torture/pr69951.c: New testcase.
>> 
>>  I see this new testcase failing on an ARM target as so:
>> 
>>  /tmp/ccChjoFc.s: Assembler messages:
>>  /tmp/ccChjoFc.s:21: Warning: [-mwarn-syms]: Assignment makes a 
>>  symbol match an ARM instruction: b
>> 
>>  FAIL: gcc.dg/torture/pr69951.c   -O0  (test for excess errors)
>> 
>>  But I haven't managed to reproduce it outside of the test environment.
>> 
>>  The fix looks trivial, rename b to anything else you fancy (well... stay
>>  clear of add and ldr). I'll put a fix in myself if I can manage to get
>>  this to reproduce - though if anyone else wants to do it I won't be
>>  offended :-).
>> >>>
>> >>> Huh, I wonder what's the use of such warning.  After all 'ldr' is a valid
>> >>> C symbol name, too.  In fact my cross arm as doesn't report this
>> >>> warning (binutils 2.25.0)
>> >>>
>>  arm-suse-linux-gnueabi-as t.s -mwarn-syms
>> >>> Assembler messages:
>> >>> Error: unrecognized option -mwarn-syms
>> >>
>> >> Right, I've figured out the set of conditions... You need to be targeting
>> >> an arm-*-linux-* system to make sure that the ASM_OUTPUT_DEF definition
>> >> from config/arm/linux-elf.h is pulled in. This causes us to emit:
>> >>
>> >> b = a
>> >>
>> >> Rather than
>> >>
>> >>.setb,a
>> >>
>> >> Writing it as "b = a" causes the warning added to resolve binutils
>> >> PR18347 [1] to kick in, so you need binutils > 2.26 or to have backported
>> >> that patch).
>> >>
>> >> Resolving it by hacking the testcase would be one fix, but I wonder why 
>> >> the
>> >> ARM port prefers to emit "b = a" in a linux environment if .set does the
>> >> same thing and always avoids the warning? Maybe Ramana/Richard/Kyrill/Nick
>> >> remember?
>> >> (AArch64 does the same thing, but the AArch64 gas port doesn't
>> >> have the PR18347 fix).
>> >
>> > So does b = a define a macro then and the warning is to avoid you
>> > doing
>>
>>
>>
>>
>> I don't think this is a macro, b = a seems to be a way of setting the
>> value of a to b. in the assembler. If a is an expression , then I
>> believe the expression is resolved at assemble time - (b ends up being a
>> symbol in the symbol table produced with the value of a) in this case
>> the address of a. .set b, a achieves the same thing from my experiments
>> and reading of the sources. The reason ports appear to choose not to use
>> the .set a, b idiom is if the assembler syntax has hijacked the .set
>> directive for something else. Thus I don't see why we use the
>> ASM_OUTPUT_DEF form in the GNU/Linux port TBH rather than the .set form
>> especially as we don't reuse .set for anything else in the ARM assembler
>> port and SET_ASM_OP is defined in config/arm/aout.h.
>>
>> The use of .set in the arm port of glibc for assembler code for the same
>> purpose seems to also vindicate that kind of thought.
>>  No reasons were given here[1], maybe Nick or Richard remember from
>> nearly 18 years ago ;)
>>
>>
>> Therefore this seems to be an assembler bug to me in that it doesn't
>> allow such an assignment of values, and a backend wart to me that we
>> have ASM_OUTPUT_DEF defined for no good reason. So, a patch that removes
>> ASM_OUTPUT_DEF from linux-elf.h seems obvious to me pending testing.
>>
>>
>> Nick , Richard - any thoughts ?
>
> So - why does it warn at all for this?  And why does it only warn
> for b = a and not .set b, a?
The rationale for that appears to be in comment 3 for binutils PR18347:
https://sourceware.org/bugzilla/show_bug.cgi?id=18347

"As far as adding some way to suppress the warning... Instruction set
extensions mean
that an acceptable symbol one day will 

Re: [Ada] Fix unexpectedly large frame with calls manipulating strings

[Tom de Vries]

On 29-02-16 10:17, Eric Botcazou wrote:

Another long-standing regression present in the compiler (dating back to the
Tree-SSA merge): the compiler generates code that has an unexpectedly large
stack usage for nested calls on strings, because the gimplifier creates
temporaries in the outermost scope that have overlapping live ranges.

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


2016-02-29  Eric Botcazou  

* gcc-interface/trans.c (finalize_nrv_r): Remove obsolete code.
(build_return_expr): Likewise.
(Call_to_gnu): If this is a function call and there is no target,
create a temporary for the return value for all aggregate types,
but never create it for a return statement.  Push a binding level
around the call in more cases.  Remove obsolete code.


2016-02-29  Eric Botcazou  

* gnat.dg/stack_usage3.adb: New test.
* gnat.dg/stack_usage3_pkg.ads: New helper.


Hi,

This new test fails for me with -m32.

Thanks,
- Tom

Re: [PATCH 7/9] S/390: Get rid of Y constraint in vector.md.

[Andreas Krebbel]

On 03/01/2016 04:11 PM, Ulrich Weigand wrote:
> I wrote:
>> Andreas Krebbel wrote:
>>
>>> +; vec_set is supposed to *modify* an existing vector so operand 0 is
>>> +; duplicated as input operand.
>>> +(define_expand "vec_set"
>>> +  [(set (match_operand:V0 "register_operand"   
>>>"")
>>> +   (unspec:V [(match_operand: 1 "general_operand"   
>>> "")
>>> +  (match_operand:SI2 "shift_count_or_setmem_operand" 
>>> "")
>>
>> This is probably only cosmetic, but should we use nonmemory_operand here
>> instead of shift_count_or_setmem_operand (just like everywhere else now)?
>>
>>> +(define_expand "vec_extract"
>>> +  [(set (match_operand: 0 "nonimmediate_operand" "")
>>> +   (unspec: [(match_operand:V  1 "register_operand" "")
>>> +  (match_operand:SI 2 "shift_count_or_setmem_operand" 
>>> "")]
>>
>> Likewise.
> 
> I just noticed that there are two more UNSPEC_VEC_SET expanders
> in vx-builtins.md.  I guess those should be likewise changed:
> 
> (define_expand "vec_insert"
>   [(set (match_operand:V_HW0 "register_operand" "")
> (unspec:V_HW [(match_operand: 2 "register_operand" "")
>   (match_operand:SI3 
> "shift_count_or_setmem_operand" "")
>   (match_operand:V_HW  1 "register_operand" "")]
>  UNSPEC_VEC_SET))]
>   "TARGET_VX"
>   "")
> 
> (define_expand "vec_promote"
>   [(set (match_operand:V_HW0 "register_operand" "")
> (unspec:V_HW [(match_operand: 1 "register_operand" "")
>   (match_operand:SI2 
> "shift_count_or_setmem_operand" "")
>   (match_dup 0)]
>  UNSPEC_VEC_SET))]
>   "TARGET_VX"
>   "")
> 
> Then the only remaining users of shift_count_or_setmem_operand are the
> actual setmem patterns (so maybe the predicate can be renamed to
> "setmem_operand") :-)

Yes. We probably should also try to get rid of s390_decompose_shift_count. 
Perhaps it can be merged
into decompose_address as a special case?! At least it should get a new name as 
well. I'll move
these changes into the next development cycle. I've caused enough stage4 
breakage for today ;)

Thanks for reviewing the patches!

Bye,

-Andreas-

Re: [PATCH 7/9] S/390: Get rid of Y constraint in vector.md.

[Ulrich Weigand]

I wrote:
> Andreas Krebbel wrote:
> 
> > +; vec_set is supposed to *modify* an existing vector so operand 0 is
> > +; duplicated as input operand.
> > +(define_expand "vec_set"
> > +  [(set (match_operand:V0 "register_operand"   
> >"")
> > +   (unspec:V [(match_operand: 1 "general_operand"   
> > "")
> > +  (match_operand:SI2 "shift_count_or_setmem_operand" 
> > "")
> 
> This is probably only cosmetic, but should we use nonmemory_operand here
> instead of shift_count_or_setmem_operand (just like everywhere else now)?
> 
> > +(define_expand "vec_extract"
> > +  [(set (match_operand: 0 "nonimmediate_operand" "")
> > +   (unspec: [(match_operand:V  1 "register_operand" "")
> > +  (match_operand:SI 2 "shift_count_or_setmem_operand" 
> > "")]
> 
> Likewise.

I just noticed that there are two more UNSPEC_VEC_SET expanders
in vx-builtins.md.  I guess those should be likewise changed:

(define_expand "vec_insert"
  [(set (match_operand:V_HW0 "register_operand" "")
(unspec:V_HW [(match_operand: 2 "register_operand" "")
  (match_operand:SI3 
"shift_count_or_setmem_operand" "")
  (match_operand:V_HW  1 "register_operand" "")]
 UNSPEC_VEC_SET))]
  "TARGET_VX"
  "")

(define_expand "vec_promote"
  [(set (match_operand:V_HW0 "register_operand" "")
(unspec:V_HW [(match_operand: 1 "register_operand" "")
  (match_operand:SI2 
"shift_count_or_setmem_operand" "")
  (match_dup 0)]
 UNSPEC_VEC_SET))]
  "TARGET_VX"
  "")

Then the only remaining users of shift_count_or_setmem_operand are the
actual setmem patterns (so maybe the predicate can be renamed to
"setmem_operand") :-)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: [PATCH 1/9] gensupport: Fix define_subst operand renumbering.

[Andreas Krebbel]

On 03/01/2016 02:38 PM, James Greenhalgh wrote:
> On Tue, Mar 01, 2016 at 01:35:18PM +0100, Andreas Krebbel wrote:
>> On 03/01/2016 01:15 PM, James Greenhalgh wrote:
>>> On Tue, Mar 01, 2016 at 10:29:28AM +0100, Andreas Krebbel wrote:
 On 02/29/2016 02:36 PM, Bernd Schmidt wrote:
> On 02/29/2016 09:46 AM, Andreas Krebbel wrote:
>> Ok for mainline?
>>
>>  * gensupport.c (process_substs_on_one_elem): Split loop to
>>  complete mark_operands_used_in_match_dup on all expressions in the
>>  vector first.
>>  (adjust_operands_numbers): Inline into process_substs_on_one_elem
>>  and remove function.
>
> Didn't I approve this a while ago? Not sure it's appropriate for stage4 
> though; is this series fixing an important regression?

 Yes you did. I didn't commit it until the rest of the patch series was 
 ready to commit.  The patch
 series fixes a fundamental problem in the backend. The first iteration was 
 posted before stage 4 but
 it took me a few iterations to get it right.

 I've committed the patch now after retesting.
>>>
>>> This looks like it has caused failures in the following tests on an
>>> x86_64-none-linux-gnu build.
>>
>> I've regression tested the patch on x86_64 as well.  Are there specific
>> options required to enable these tests?
> 
> The bisect robot just builds a stage one compiler, configured with:
> 
>   ./configure --disable-bootstrap, --enable-languages=c,c++,fortran
>   --disable-multilib --disable-libsanitizer
> 
> My system GCC is a 5.2 from the release sources with:
> 
>   ../gcc-5.2.0/configure --with-bugurl='Good luck'
>  --enable-languages=c,c++,go,fortran,objc,obj-c++
>  --prefix=/work/install-gcc-5.2.0 --enable-shared
>  --enable-linker-build-id --without-included-gettext
>  --enable-threads=posix --enable-nls
>--enable-clocale=gnu --enable-libstdcxx-debug
>  --enable-libstdcxx-time=yes
>  --enable-gnu-unique-object --disable-libmudflap
>  --enable-plugin --with-system-zlib
>  --disable-browser-plugin --enable-java-awt=gtk
>  --enable-gtk-cairo --with-arch-directory=amd64
>  --enable-objc-gc --enable-multiarch
>  --disable-werror --with-arch-32=i686
>  --with-abi=m64 --with-multilib-list=m32,m64,mx32
>  --with-tune=native --enable-checking=release
>  --build=x86_64-linux-gnu --host=x86_64-linux-gnu
>  --target=x86_64-linux-gnu
> 
> I tried a full bootstrap at that revision and still see these failures.
> Who knows what state has been corrupted, or that you silently get away with,
> if this is an undefined behaviour somewhere :-). I haven't tried with a
> valgrind checking build to see what it can spot.

Ok. Thanks for the infos.  I'll try to have a look. I've reverted the patch now.

Bye,

-Andreas-

[PATCH][AArch64][testsuite] PR target/70004: Remove check using undefined behaviour

[Kyrill Tkachov]

Hi all,

This test was reported as starting to fail a scan-assembler check with 
-mtune=thunderx.
The compiler decided to move the result back into the integer registers and 
perform the shift there
rather than do it on the SIMD side.
However, the C code is undefined because the shift is wider than the type. GCC 
even warns for it, but the
test catches it with dg-warning.
I don't think it's correct for the test to rely on undefined code, so the 
simplest thing to do is to delete
the undefined code.

Ok for trunk?

Thanks,
Kyrill

2016-03-01  Kyrylo Tkachov  

PR target/70004
* gcc.target/aarch64/scalar_shift_1.c: (test_corners_sisd_di):
Delete.
(test_corners_sisd_si): Likewise.
(main): Remove checks of the above.
diff --git a/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c b/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c
index 8465c896705dbfd4c76b0815511ea7b4b034e095..7be1b12a75bf9f201644aef471c5edb99979c0c5 100644
--- a/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c
@@ -181,34 +181,6 @@ test_ashift_right_int_si (Int32x1 b, Int32x1 c)
 /* { dg-final { scan-assembler "asr\tw\[0-9\]+,\ w\[0-9\]+,\ 4" } } */
 /* { dg-final { scan-assembler "asr\tw\[0-9\]+,\ w\[0-9\]+,\ w\[0-9\]+" } } */
 
-Int64x1
-test_corners_sisd_di (Int64x1 b)
-{
-  force_simd_di (b);
-  b = b >> 63;
-  force_simd_di (b);
-  b = b >> 0;
-  b += b >> 65; /* { dg-warning "right shift count >= width of type" } */
-
-  return b;
-}
-/* { dg-final { scan-assembler "sshr\td\[0-9\]+,\ d\[0-9\]+,\ 63" } } */
-
-Int32x1
-test_corners_sisd_si (Int32x1 b)
-{
-  force_simd_si (b);
-  b = b >> 31;
-  force_simd_si (b);
-  b = b >> 0;
-  b += b >> 33; /* { dg-warning "right shift count >= width of type" } */
-
-  return b;
-}
-/* { dg-final { scan-assembler "sshr\tv\[0-9\]+\.2s,\ v\[0-9\]+\.2s,\ 31" } } */
-
-
-
 #define CHECK(var,val) \
 do \
   {\
@@ -236,8 +208,6 @@ main ()
   CHECK (x, 0x21524110ull);
   x = test_ashift_right_sisd_di (x, 8);
   CHECK (x, 0x2152ull);
-  x = test_corners_sisd_di (x);
-  CHECK (x, 0xfffeull);
 
   y = test_lshift_left_sisd_si (y, 4);
   CHECK (y, 0xadbeef00);
@@ -252,8 +222,6 @@ main ()
   CHECK (y, 0x5241);
   y = test_ashift_right_sisd_si (y, 4);
   CHECK (y, 0xff52);
-  y = test_corners_sisd_si (y);
-  CHECK (y, 0xfffe);
 
   return 0;
 }

[testsuite] Invoke gdb with -batch to avoid prompts

[Rainer Orth]

When switching from gdb 7.10 to the newly released gdb 7.11 on Solaris,
all simulate-thread tests started to timeout, adding about 2 1/2 hours
to bootstrap time.  It turned out that this happens as follows: with gdb
7.10, a test is run like this and runs to completion without interaction:

/vol/gcc/bin/amd64/gdb-7.10 -nx -nw -x 
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/simulate-thread/simulate-thread.gdb
 ./atomic-load-int.exe

With gdb 7.11, OTOH, I see

/vol/gcc/bin/amd64/gdb-7.11 -nx -nw -x 
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/simulate-thread/simulate-thread.gdb
 ./atomic-load-int.exe 

and the test goes interactive once per page

Thread 2 hit Breakpoint 1, simulate_thread_main ()
at 
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/simulate-thread/atomic-load-int.c:97
97for (table_cycle_size = 16; table_cycle_size > 4 ; table_cycle_size--)
---Type  to continue, or q  to quit---

when run interactively, and hangs the test inside the testsuite.

Strangely, this doesn't happen on x86_64-pc-linux-gnu, and I couldn't
find anything related mentioned in the gdb NEWS file.  I didn't dig too
deeply into gdb source code to investigate.

Fortunately, it turns out that the fix is simple: when gdb is invoked
with -batch, both versions behave the same and never go interactive in
this scenario.  The -batch option goes way back (at least to gdb 5.2
which I still had lying around), so this seems a safe change.

Tested with the appropriate runtest invocation on i386-pc-solaris2.12
and x86_64-pc-linux-gnu (with GDB_FOR_GCC_TESTING set to either gdb
version) for gcc.dg/simulate-thread on both and gcc.dg/guality on Linux
only.

Ok for mainline, gcc-5 and gcc-4.9 branches (given that it adds hours to
total bootstrap time)?

Rainer


2016-02-29  Rainer Orth  

* lib/gcc-gdb-test.exp (gdb-test): Make log message match command.
Invoke gdb with -batch.
* lib/gcc-simulate-thread.exp (simulate-thread): Likewise.

# HG changeset patch
# Parent  b8273f68b9015179dc5b11f384d55efd5b4130a8
Invoke gdb with -batch to avoid prompts

diff --git a/gcc/testsuite/lib/gcc-gdb-test.exp b/gcc/testsuite/lib/gcc-gdb-test.exp
--- a/gcc/testsuite/lib/gcc-gdb-test.exp
+++ b/gcc/testsuite/lib/gcc-gdb-test.exp
@@ -73,8 +73,8 @@ proc gdb-test { args } {
 puts $fd "quit"
 close $fd
 
-send_log "Spawning: $gdb_name -nx -nw -quiet -x $cmd_file ./$output_file\n"
-set res [remote_spawn target "$gdb_name -nx -nw -quiet -x $cmd_file ./$output_file"]
+send_log "Spawning: $gdb_name -nx -nw -quiet -batch -x $cmd_file ./$output_file\n"
+set res [remote_spawn target "$gdb_name -nx -nw -quiet -batch -x $cmd_file ./$output_file"]
 if { $res < 0 || $res == "" } {
 	unsupported "$testname"
 	file delete $cmd_file
diff --git a/gcc/testsuite/lib/gcc-simulate-thread.exp b/gcc/testsuite/lib/gcc-simulate-thread.exp
--- a/gcc/testsuite/lib/gcc-simulate-thread.exp
+++ b/gcc/testsuite/lib/gcc-simulate-thread.exp
@@ -49,8 +49,8 @@ proc simulate-thread { args } {
 
 set message "thread simulation test"
 
-send_log "Spawning: $gdb_name -nx -nw -quiet -x $cmd_file ./$exec_file\n"
-set res [remote_spawn target "$gdb_name -nx -nw  -x $cmd_file ./$exec_file"]
+send_log "Spawning: $gdb_name -nx -nw -batch -x $cmd_file ./$exec_file\n"
+set res [remote_spawn target "$gdb_name -nx -nw -batch -x $cmd_file ./$exec_file"]
 if { $res < 0 || $res == "" } {
 	unsupported "$testcase $message"
 	return

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

Re: [C++ PATCH] Fix ICE on invalid (PR c++/69795)

[Jason Merrill]

OK.

Jason

[C PATCH] Don't print -Waddress comparison warnings for macros (PR c/48778)

[Marek Polacek]

This PR from 2011 reports that -Waddress prints unhelpful warning when the
comparison comes from a macro.  Since I've added from_macro_expansion_at,
this is easy to circumvent.  I'm not so sure we actually want to disable
the warning in the case of a macro, but probably yes.

Bootstrapped/regtested on x86_64-linux, ok for trunk or should I defer to
GCC 7?

2016-03-01  Marek Polacek  

PR c/48778
* c-typeck.c (build_binary_op): Don't issue -Waddress warnings
for macro expansions.

* gcc.dg/Waddress-2.c: New test.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 6aa0f03..0f415e0 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -11087,7 +11087,8 @@ build_binary_op (location_t location, enum tree_code 
code,
   else if (code0 == POINTER_TYPE && null_pointer_constant_p (orig_op1))
{
  if (TREE_CODE (op0) == ADDR_EXPR
- && decl_with_nonnull_addr_p (TREE_OPERAND (op0, 0)))
+ && decl_with_nonnull_addr_p (TREE_OPERAND (op0, 0))
+ && !from_macro_expansion_at (location))
{
  if (code == EQ_EXPR)
warning_at (location,
@@ -11107,7 +11108,8 @@ build_binary_op (location_t location, enum tree_code 
code,
   else if (code1 == POINTER_TYPE && null_pointer_constant_p (orig_op0))
{
  if (TREE_CODE (op1) == ADDR_EXPR
- && decl_with_nonnull_addr_p (TREE_OPERAND (op1, 0)))
+ && decl_with_nonnull_addr_p (TREE_OPERAND (op1, 0))
+ && !from_macro_expansion_at (location))
{
  if (code == EQ_EXPR)
warning_at (location,
diff --git gcc/testsuite/gcc.dg/Waddress-2.c gcc/testsuite/gcc.dg/Waddress-2.c
index e69de29..4d927f6 100644
--- gcc/testsuite/gcc.dg/Waddress-2.c
+++ gcc/testsuite/gcc.dg/Waddress-2.c
@@ -0,0 +1,24 @@
+/* PR c/48778 */
+/* { dg-do compile } */
+/* { dg-options "-Waddress" } */
+
+#define NULL ((void *) 0)
+
+#define M1(b) ((b) != NULL ? 0 : (b))
+#define M2(b) ((b) == NULL ? 0 : (b))
+#define M3(b) (NULL != (b) ? 0 : (b))
+#define M4(b) (NULL == (b) ? 0 : (b))
+
+int
+func (int b)
+{
+  if (M1 () > 0)
+return 1;
+  if (M2 () > 0)
+return 2;
+  if (M3 () > 0)
+return 3;
+  if (M4 () > 0)
+return 4;
+  return 0;
+}

Marek

Re: [PATCH 1/9] gensupport: Fix define_subst operand renumbering.

[James Greenhalgh]

On Tue, Mar 01, 2016 at 01:35:18PM +0100, Andreas Krebbel wrote:
> On 03/01/2016 01:15 PM, James Greenhalgh wrote:
> > On Tue, Mar 01, 2016 at 10:29:28AM +0100, Andreas Krebbel wrote:
> >> On 02/29/2016 02:36 PM, Bernd Schmidt wrote:
> >>> On 02/29/2016 09:46 AM, Andreas Krebbel wrote:
>  Ok for mainline?
> 
>   * gensupport.c (process_substs_on_one_elem): Split loop to
>   complete mark_operands_used_in_match_dup on all expressions in the
>   vector first.
>   (adjust_operands_numbers): Inline into process_substs_on_one_elem
>   and remove function.
> >>>
> >>> Didn't I approve this a while ago? Not sure it's appropriate for stage4 
> >>> though; is this series fixing an important regression?
> >>
> >> Yes you did. I didn't commit it until the rest of the patch series was 
> >> ready to commit.  The patch
> >> series fixes a fundamental problem in the backend. The first iteration was 
> >> posted before stage 4 but
> >> it took me a few iterations to get it right.
> >>
> >> I've committed the patch now after retesting.
> > 
> > This looks like it has caused failures in the following tests on an
> > x86_64-none-linux-gnu build.
> 
> I've regression tested the patch on x86_64 as well.  Are there specific
> options required to enable these tests?

The bisect robot just builds a stage one compiler, configured with:

  ./configure --disable-bootstrap, --enable-languages=c,c++,fortran
  --disable-multilib --disable-libsanitizer

My system GCC is a 5.2 from the release sources with:

  ../gcc-5.2.0/configure --with-bugurl='Good luck'
 --enable-languages=c,c++,go,fortran,objc,obj-c++
 --prefix=/work/install-gcc-5.2.0 --enable-shared
 --enable-linker-build-id --without-included-gettext
 --enable-threads=posix --enable-nls
 --enable-clocale=gnu --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --enable-gnu-unique-object --disable-libmudflap
 --enable-plugin --with-system-zlib
 --disable-browser-plugin --enable-java-awt=gtk
 --enable-gtk-cairo --with-arch-directory=amd64
 --enable-objc-gc --enable-multiarch
 --disable-werror --with-arch-32=i686
 --with-abi=m64 --with-multilib-list=m32,m64,mx32
 --with-tune=native --enable-checking=release
 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
 --target=x86_64-linux-gnu

I tried a full bootstrap at that revision and still see these failures.
Who knows what state has been corrupted, or that you silently get away with,
if this is an undefined behaviour somewhere :-). I haven't tried with a
valgrind checking build to see what it can spot.

Thanks,
James

> > 
> > The failures are of this form:
> > 
> > In file included from 
> > /data/work/gcc-bisect-bot/build/gcc/include/immintrin.h:45:0,
> >  from 
> > /work/gcc-bisect-bot/gcc/gcc/testsuite/gcc.target/i386/avx512f-vfnmsubXXXps-1.c:12:
> > /data/work/gcc-bisect-bot/build/gcc/include/avx512fintrin.h: In function 
> > 'avx512f_test':
> > /data/work/gcc-bisect-bot/build/gcc/include/avx512fintrin.h:11666:10: 
> > internal compiler error: Segmentation fault
> > 0xb1a18f crash_signal
> > /work/gcc-bisect-bot/gcc/gcc/toplev.c:335
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > 
> > There are lots of them, so I'm just mentioning the unique names below.
> > 
> >   gcc.target/i386/avx512f-vfmaddsubXXXps-2.c
> >   gcc.target/i386/avx512f-vfmsubaddXXXps-2.c
> >   gcc.target/i386/avx512f-vfnmsubXXXps-2.c
> >   gcc.target/i386/avx512f-vfnmsubXXXps-1.c
> >   gcc.target/i386/avx-2.c
> >   gcc.target/i386/avx512vl-vshufpd-1.c
> >   gcc.target/i386/avx512f-vfmsubXXXpd-2.c
> >   gcc.target/i386/avx-1.c
> >   gcc.target/i386/avx512f-vfixupimmsd-1.c
> >   gcc.target/i386/avx512f-vfmsubXXXps-1.c
> >   gcc.target/i386/avx512f-vfmsubaddXXXpd-2.c
> >   gcc.target/i386/avx512f-vfmsubXXXps-2.c
> >   gcc.target/i386/avx512vl-vshufps-1.c
> >   gcc.target/i386/avx512f-vfmaddsubXXXps-1.c
> >   gcc.target/i386/avx512f-vfixupimmsd-2.c
> >   gcc.target/i386/avx512f-vfmaddXXXps-1.c
> >   gcc.target/i386/avx512f-vfmaddsubXXXpd-1.c
> >   gcc.target/i386/avx512f-vfmaddXXXpd-2.c
> >   gcc.target/i386/avx512f-vfmaddXXXps-2.c
> >   gcc.target/i386/avx512f-vfmaddsubXXXpd-2.c
> >   gcc.target/i386/sse-22.c
> >   gcc.target/i386/avx512f-vfmsubXXXpd-1.c
> >   gcc.target/i386/testround-1.c
> >   gcc.target/i386/sse-23.c
> >   gcc.target/i386/avx512f-vfmsubaddXXXpd-1.c
> >   gcc.target/i386/sse-22a.c
> >   gcc.target/i386/sse-25.c
> >   gcc.target/i386/sse-24.c
> >   

[C++ PATCH] Fix ICE on invalid (PR c++/69795)

[Marek Polacek]

A trivial patch to fix an ICE on invalid: DECL_BUILT_IN only expects
a FUNCTION_DECL, so checking DECL_P is not enough.

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

2016-03-01  Marek Polacek  

PR c++/69795
* c-common.c (reject_gcc_builtin): Check for FUNCTION_DECL rather than
any DECL.

* g++.dg/parse/invalid1.C: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 71da6e9..22ea7da 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -12638,7 +12638,7 @@ reject_gcc_builtin (const_tree expr, location_t loc /* 
= UNKNOWN_LOCATION */)
 
   if (TREE_TYPE (expr)
   && TREE_CODE (TREE_TYPE (expr)) == FUNCTION_TYPE
-  && DECL_P (expr)
+  && TREE_CODE (expr) == FUNCTION_DECL
   /* The intersection of DECL_BUILT_IN and DECL_IS_BUILTIN avoids
 false positives for user-declared built-ins such as abs or
 strlen, and for C++ operators new and delete.
diff --git gcc/testsuite/g++.dg/parse/invalid1.C 
gcc/testsuite/g++.dg/parse/invalid1.C
index e69de29..f72e277 100644
--- gcc/testsuite/g++.dg/parse/invalid1.C
+++ gcc/testsuite/g++.dg/parse/invalid1.C
@@ -0,0 +1,5 @@
+// PR c++/69795
+// { dg-do compile { target c++11 } }
+// { dg-options "-w" }
+
+int foo ( foo += *[ // { dg-error "" }

Marek

[PATCH] Fix PR69983

[Richard Biener]

I am testing the following patch to fix PR69983 - SCEV was confused
by a PRE inserted PHI node where it checks for equality of the
evolution of all edges.  After my SCEV fix these have conversions
which are not handled by eq_evolutions_p.

I've noticed the function misses any type compatibility check
and operand_equal_p on INTEGER_CSTs will ignore types.

Also it will give up on SSA names or ADDR_EXPRs which can
occur in both the evolution and init part of SCEVs.  So simply
fall back to operand_equal_p for all bits where we don't expect
any further embeded CHRECs (operand_equal_p does no handle
TREE_CHREC currently).

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

Richard.

2016-03-01  Richard Biener  

PR tree-optimization/69983
* tree-chrec.c (eq_evolutions_p): Handle conversions, compare
types and fall back to operand_equal_p.

Index: gcc/tree-chrec.c
===
*** gcc/tree-chrec.c(revision 233840)
--- gcc/tree-chrec.c(working copy)
*** eq_evolutions_p (const_tree chrec0, cons
*** 1468,1478 
if (chrec0 == chrec1)
  return true;
  
switch (TREE_CODE (chrec0))
  {
- case INTEGER_CST:
-   return operand_equal_p (chrec0, chrec1, 0);
- 
  case POLYNOMIAL_CHREC:
return (CHREC_VARIABLE (chrec0) == CHREC_VARIABLE (chrec1)
  && eq_evolutions_p (CHREC_LEFT (chrec0), CHREC_LEFT (chrec1))
--- 1468,1478 
if (chrec0 == chrec1)
  return true;
  
+   if (! types_compatible_p (TREE_TYPE (chrec0), TREE_TYPE (chrec1)))
+ return false;
+ 
switch (TREE_CODE (chrec0))
  {
  case POLYNOMIAL_CHREC:
return (CHREC_VARIABLE (chrec0) == CHREC_VARIABLE (chrec1)
  && eq_evolutions_p (CHREC_LEFT (chrec0), CHREC_LEFT (chrec1))
*** eq_evolutions_p (const_tree chrec0, cons
*** 1487,1494 
  && eq_evolutions_p (TREE_OPERAND (chrec0, 1),
  TREE_OPERAND (chrec1, 1));
  
  default:
!   return false;
  }
  }
  
--- 1487,1498 
  && eq_evolutions_p (TREE_OPERAND (chrec0, 1),
  TREE_OPERAND (chrec1, 1));
  
+ CASE_CONVERT:
+   return eq_evolutions_p (TREE_OPERAND (chrec0, 0),
+ TREE_OPERAND (chrec1, 0));
+ 
  default:
!   return operand_equal_p (chrec0, chrec1, 0);
  }
  }
  

[PATCH] Fix PR70022

[Richard Biener]

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

Richard.

2016-03-01  Richard Biener  

PR middle-end/70022
* fold-const.c (fold_indirect_ref_1): Fix range checking for
vector BIT_FIELD_REF extract.

* gcc.dg/pr70022.c: New testcase.

Index: gcc/fold-const.c
===
*** gcc/fold-const.c(revision 233840)
--- gcc/fold-const.c(working copy)
*** fold_indirect_ref_1 (location_t loc, tre
*** 14218,14234 
  if (TREE_CODE (op00type) == VECTOR_TYPE
  && type == TREE_TYPE (op00type))
{
- HOST_WIDE_INT offset = tree_to_shwi (op01);
  tree part_width = TYPE_SIZE (type);
! unsigned HOST_WIDE_INT part_widthi = tree_to_shwi 
(part_width)/BITS_PER_UNIT;
! unsigned HOST_WIDE_INT indexi = offset * BITS_PER_UNIT;
! tree index = bitsize_int (indexi);
! 
! if (offset / part_widthi < TYPE_VECTOR_SUBPARTS (op00type))
!   return fold_build3_loc (loc,
!   BIT_FIELD_REF, type, op00,
!   part_width, index);
! 
}
  /* ((foo*))[1] => __imag__ complexfoo */
  else if (TREE_CODE (op00type) == COMPLEX_TYPE
--- 14218,14237 
  if (TREE_CODE (op00type) == VECTOR_TYPE
  && type == TREE_TYPE (op00type))
{
  tree part_width = TYPE_SIZE (type);
! unsigned HOST_WIDE_INT max_offset
!   = (tree_to_uhwi (part_width) / BITS_PER_UNIT
!  * TYPE_VECTOR_SUBPARTS (op00type));
! if (tree_int_cst_sign_bit (op01) == 0
! && compare_tree_int (op01, max_offset) == -1)
!   {
! unsigned HOST_WIDE_INT offset = tree_to_uhwi (op01);
! unsigned HOST_WIDE_INT indexi = offset * BITS_PER_UNIT;
! tree index = bitsize_int (indexi);
! return fold_build3_loc (loc,
! BIT_FIELD_REF, type, op00,
! part_width, index);
!   }
}
  /* ((foo*))[1] => __imag__ complexfoo */
  else if (TREE_CODE (op00type) == COMPLEX_TYPE
Index: gcc/testsuite/gcc.dg/pr70022.c
===
*** gcc/testsuite/gcc.dg/pr70022.c  (revision 0)
--- gcc/testsuite/gcc.dg/pr70022.c  (working copy)
***
*** 0 
--- 1,9 
+ /* { dg-do compile } */
+ 
+ typedef int v4si __attribute__ ((vector_size (16)));
+ 
+ int
+ foo (v4si v)
+ {
+   return v[~0UL];
+ }

Re: [PATCH,testsuite] Print markers to stderr to avoid races with sanitizer output

[Maxim Kuvyrkov]

> On Mar 1, 2016, at 12:31 PM, Maxim Kuvyrkov  wrote:
> 
> This patch improves sanitizer testsuite to avoid sporadic failures, 
> especially when [cross-]testing on a remote machine.
> 
> There are several unstable sanitizer tests in GCC testsuite (e.g., 
> g++.dg/tsan/aligned_vs_unaligned_race.C), and the instability comes from the 
> test doing this:
> 
> printf("Pass\n");
> /* { dg-output "WARNING: ThreadSanitizer: data race.*(\n|\r\n|\r)" } */
> /* { dg-output "Pass.*" } */
> 
> .  Thread sanitizer prints its data to stderr, and then printf prints to 
> stdout.  The testcase expects stderr to be flushed before stdout, and "Pass" 
> to be at the end of the output.  AFAIK, that works fine in native/local 
> environment, but fails in remote testing from time to time.  The failure case 
> happens when stdout output is printed before stderr output.  This is, likely, 
> because there is no strict ordering of stdout and stderr when remote testing.
> 
> This patch fixes the affected tests in GCC testsuite, and I'll be also 
> posting a similar patch for LLVM testsuite.

FYI, this was posted to LLVM (and approved) here: 
http://reviews.llvm.org/D17757 .

> 
> OK for trunk?


--
Maxim Kuvyrkov
www.linaro.org

Re: libgcc: On AIX, increase chances to find landing pads for exceptions

[David Edelsohn]

On Tue, Mar 1, 2016 at 7:09 AM, Michael Haubenwallner
 wrote:
> Hi David,
>
> On 02/10/2016 10:52 AM, Michael Haubenwallner wrote:
> 
>>> There are two remaining issues:
>>>
>>> 1) FDEs with overlapping ranges causing problems with exceptions.  I'm
>>> not sure of the best way to work around this.  Your patch is one
>>> possible solution.
>>
>> This patch is not meant as a final solution, but to improve current
>> situation with broken build systems exporting even _GLOBAL__ symbols.
>> I'm about to prepare another libtool patch to fix that one.
>
> so this is the libtool patch I'm about to submit.
>
> What do you think? Reasonable?

I don't think that Ian really cares about this.

I guess that the patch is reasonable, but the libtool command is
becoming extremely complicated.

- David