[PATCH] Fix va_arg gimplification error for s390

[Tom de Vries]

Hi,

this patch fixes a gimplification error of the va_list argument of va_arg for 
target s390. The error was introduced by r223054, the fix for PR66010.



I.

consider test-case:
...
#include 

int
f1 (int i, ...)
{
  int res;
  va_list ap;

  va_start (ap, i);
  res = va_arg (ap, int);
  va_end (ap);

  return res;
}
...

For target s390, we're running into a gimplification error for valist '&ap' in 
gimplify_va_arg_internal when calling:

...
9326gimplify_expr (&valist, pre_p, post_p, is_gimple_min_lval, 
fb_lvalue);
...

Before committing r223054, we were calling instead:
...
9331  gimplify_expr (&valist, pre_p, post_p, is_gimple_val, fb_rvalue);
...
with valist '(struct  *) &ap', and the gimplification went fine.


II.

The successful gimplification was triggered using the following path, entering 
with valist 'ap':

...
gimplify_va_arg_internal (tree valist, tree type, location_t loc,
  gimple_seq *pre_p, gimple_seq *post_p)
{
  tree have_va_type = TREE_TYPE (valist);
  tree cano_type = targetm.canonical_va_list_type (have_va_type);

  if (cano_type != NULL_TREE)
have_va_type = cano_type;

  /* Make it easier for the backends by protecting the valist argument
 from multiple evaluations.  */
  if (TREE_CODE (have_va_type) == ARRAY_TYPE)
{
  /* For this case, the backends will be expecting a pointer to
 TREE_TYPE (abi), but it's possible we've
 actually been given an array (an actual TARGET_FN_ABI_VA_LIST).
 So fix it.  */
  if (TREE_CODE (TREE_TYPE (valist)) == ARRAY_TYPE)
{
  tree p1 = build_pointer_type (TREE_TYPE (have_va_type));
  valist = fold_convert_loc (loc, p1,
 build_fold_addr_expr_loc (loc, valist));
}

  gimplify_expr (&valist, pre_p, post_p, is_gimple_val, fb_rvalue);
}
...

In r223054, we've moved the fixup of adding the addr_expr to 
gimplify_va_arg_expr. Consequently, we're now entering with valist '&ap'. The 
have_va_type has changed to 'struct [1] *', and cano_type is NULL_TREE.
So have_va_type is no longer an array, and the other gimplification path is 
triggered, which causes the gimplification error.


[ For x86_64, the type of '&ap' is not 'struct [1] *' but 'struct *', and the
  cano_type is not NULL_TREE, so we didn't encounter this problem there. ]


III.

The patch fixes this error by inlining gimplify_va_arg_internal into 
expand_ifn_va_arg_1, and using the information present there to determine which 
gimplification path to choose:

...
if (do_deref == integer_one_node)
  gimplify_expr (&ap, &pre, &post, is_gimple_min_lval, fb_lvalue);
else
  gimplify_expr (&ap, &pre, &post, is_gimple_val, fb_rvalue);
...

So for an va_list ap given as argument of va_arg:
- in case the canonical va_list is an array type, we take the address in
  gimplify_va_arg_expr, set do_deref to zero, meaning we pass '&ap' to
  targetm.gimplify_va_arg_expr. The fact that it's an address means we can
  expect it to be an rvalue, but not an lvalue.
- in case the canonical va_list is not an array type, we take the address in
  gimplify_va_arg_expr, but set do_deref to one, meaning we pass 'ap' to
  targetm.gimplify_va_arg_expr. 'ap' may be modified by va_arg, so it needs to
  be an lvalue.


IV.

Bootstrapped and reg-tested on x86_64.

Noted to fix s390 bootstrap: 
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01176.html .


Noted to fix ppc build: 
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01162.html .

OK for trunk?

Thanks,
- Tom
Gimplify va_arg ap based on do_deref

2015-05-13  Tom de Vries  

	PR tree-optimization/66010
	* gimplify.h (gimplify_va_arg_internal): Remove declaration.
	* gimplify.c (gimplify_va_arg_internal): Remove and inline into ...
	* tree-stdarg.c (expand_ifn_va_arg_1): ... here.  Choose between lval
	and rval based on do_deref.
---
 gcc/gimplify.c| 26 --
 gcc/gimplify.h|  1 -
 gcc/tree-stdarg.c |  9 -
 3 files changed, 8 insertions(+), 28 deletions(-)

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 322d0ba..4846478 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -9302,32 +9302,6 @@ dummy_object (tree type)
   return build2 (MEM_REF, type, t, t);
 }
 
-/* Call the target expander for evaluating a va_arg call of VALIST
-   and TYPE.  */
-
-tree
-gimplify_va_arg_internal (tree valist, tree type, gimple_seq *pre_p,
-			  gimple_seq *post_p)
-{
-  tree have_va_type = TREE_TYPE (valist);
-  tree cano_type = targetm.canonical_va_list_type (have_va_type);
-
-  if (cano_type != NULL_TREE)
-have_va_type = cano_type;
-
-  /* Make it easier for the backends by protecting the valist argument
- from multiple evaluations.  */
-  if (TREE_CODE (have_va_type) == ARRAY_TYPE)
-{
-  gcc_assert (TREE_CODE (TREE_TYPE (valist)) != ARRAY_TYPE);
-  gimplify_expr (&valist, pre_p, post_p, is_gimple_val, fb_rvalue);
-}
-  else
-gimplify_exp

Re: [patch] Clean up detection of SJLJ exceptions in target libraries

[Eric Botcazou]

> Generally OK.  However, please confirm with ian on the libgo bits just
> in case you're hitting something that's shared with golang.

OK, I can certainly wait for Ian's approval for the libgo bits.

> We could certainly consider cleaning up the targets (hppa).  That'd be a
> fine follow-up :-)  ISTM we ought to be moving away from the EH model
> being something we explicitly ask for via enable/disable options on the
> configure command line.

It's more in Dave's court. :-)  I don't think we have any PA machine up and 
running at AdaCore these days.

> I trust you'll keep an eye out for any fallout.

Yes, I'm back in the SJLJ business.

-- 
Eric Botcazou

Re: [patch] Clean up detection of SJLJ exceptions in target libraries

[Andrew Pinski]

On Tue, May 12, 2015 at 9:42 AM, Eric Botcazou  wrote:
> Hi,
>
> 6 target libraries in the tree detect whether they are being compiled by a
> compiler configured for setjmp/longjmp exceptions: libada, libgcc, libgo,
> libjava, libobjc and libstdc++.  They can be divided into 3 categories:
>  1) libada only checks the preprocessor macro __USING_SJLJ_EXCEPTIONS__,
>  2) libgcc and libgo both check the preprocessor macro and implement a
> configure check that defines another macro (LIBGCC_SJLJ_EXCEPTIONS and
> LIBGO_SJLJ_EXCEPTIONS resp) so they'd better agree.
>  3) libjava, libobjc and libstdc++ implement a configure check that defines a
> macro (SJLJ_EXCEPTIONS, SJLJ_EXCEPTIONS and _GLIBCXX_SJLJ_EXCEPTIONS resp).
>
> The attached patch gets rid of the library-specific macros and replaces them
> with __USING_SJLJ_EXCEPTIONS__.  Moreover, it adds a config/sjlj.m4 fragment
> that defines GCC_CHECK_SJLJ_EXCEPTIONS for libraries that need to detect the
> exception model in the configure phase (libgcc and libjava only).
>
> Tested on x86_64-suse-linux with --enable-sjlj-exceptions.  The results are
> not clean (except for objc and obj-c++) but sufficient to see that exceptions
> still work after the patch.  OK for the mainline?
>
>
> 2015-05-12  Eric Botcazou  
>
> config/
> * sjlj.m4: New file.
>
> libgcc/
> * configure.ac: Include config/sjlj.m4.
> Remove manual SJLJ check, add GCC_CHECK_SJLJ_EXCEPTIONS and adjust.
> * config.in: Regenerate.
> * configure: Likewise.
> * config.host: Replace enable_sjlj_exceptions by 
> ac_cv_sjlj_exceptions.
>
> libgo/
> * configure.ac: Remove manual SJLJ check.
> * config.h.in: Regenerate.
> * configure: Likewise.
> * runtime/go-unwind.c: Replace LIBGO_SJLJ_EXCEPTIONS by
> __USING_SJLJ_EXCEPTIONS__.
>
> libjava/
> * configure.ac: Include config/sjlj.m4.
> Remove manual SJLJ check, add GCC_CHECK_SJLJ_EXCEPTIONS and adjust.
> * include/config.h.in: Regenerate.
> * configure: Likewise.
> * exception.cc: Replace SJLJ_EXCEPTIONS by __USING_SJLJ_EXCEPTIONS__.
> * stacktrace.cc: Likewise.
> * include/default-signal.h: Likewise.
> * sysdep/i386/backtrace.h: Likewise.
>
> libobjc/
> * configure.ac: Remove manual SJLJ check.
> * config.h.in: Regenerate.
> * configure: Likewise.
> * exception.c: Replace SJLJ_EXCEPTIONS by __USING_SJLJ_EXCEPTIONS__.


The libobjc parts are ok.

Thanks,
Andrew Pinski

>
> libstdc++-v3/
> * acinclude.m4 (GLIBCXX_ENABLE_SJLJ_EXCEPTIONS): Delete.
> * configure.ac: Remove GLIBCXX_ENABLE_SJLJ_EXCEPTIONS.
> * config.h.in: Regenerate.
> * configure: Likewise.
> * libsupc++/eh_personality.cc: Replace _GLIBCXX_SJLJ_EXCEPTIONS by
> __USING_SJLJ_EXCEPTIONS__.
> * libsupc++/eh_throw.cc: Likewise.
> * libsupc++/eh_ptr.cc: Likewise.
> * doc/html/manual/appendix_porting.html: Remove
> GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
> * doc/xml/manual/build_hacking.xml: Likewise.
> * doc/html/manual/configure.html: Remove --enable-sjlj-exceptions.
> * doc/xml/manual/configure.xml: Likewise.
>
>
> --
> Eric Botcazou

Re: [PATCH, PR target/65103, 3/3] Change rtx cost for i386 address constants

[Ilya Enkovich]

On 12 May 17:33, Uros Bizjak wrote:
> Hello!
> 
> >> 2015-03-10  Ilya Enkovich  
> >>
> >> PR target/65103
> >> * config/i386/i386.c (ix86_rtx_costs): We want to propagate
> >> link time constants into adress expressions and therefore set
> >> their cost to 0.
> >>
> >> gcc/testsuite/
> >>
> >> 2015-03-10  Ilya Enkovich  
> >>
> >> PR target/65103
> >> * gcc.target/i386/pr65103-3.c: New.
> >>
> >>
> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> >> index b3971b8..341a157 100644
> >> --- a/gcc/config/i386/i386.c
> >> +++ b/gcc/config/i386/i386.c
> >> @@ -42039,7 +42039,8 @@ ix86_rtx_costs (rtx x, int code_i, int 
> >> outer_code_i, int opno, int *total,
> >>&& !(TARGET_64BIT
> >> && (GET_CODE (x) == LABEL_REF
> >> || (GET_CODE (x) == SYMBOL_REF
> >> -   && SYMBOL_REF_LOCAL_P (x)
> >> +   && SYMBOL_REF_LOCAL_P (x
> >> +  && (TARGET_64BIT || GET_CODE (x) != CONST))
> 
> Please also add a one-line comment for the new condition.
> 
> OK with this change.
> 
> Uros.

Thanks! Here is committed version.

Ilya
--
gcc/

2015-05-13  Ilya Enkovich  

PR target/65103
* config/i386/i386.c (ix86_rtx_costs): We want to propagate
link time constants into adress expressions and therefore set
their cost to 0.

gcc/testsuite/

2015-05-13  Ilya Enkovich  

PR target/65103
* gcc.target/i386/pr65103-3.c: New.


diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index fd52d89..d739f89 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -42005,7 +42005,9 @@ ix86_rtx_costs (rtx x, int code_i, int outer_code_i, 
int opno, int *total,
   && !(TARGET_64BIT
&& (GET_CODE (x) == LABEL_REF
|| (GET_CODE (x) == SYMBOL_REF
-   && SYMBOL_REF_LOCAL_P (x)
+   && SYMBOL_REF_LOCAL_P (x
+  /* Use 0 cost for CONST to improve its propagation.  */
+  && (TARGET_64BIT || GET_CODE (x) != CONST))
*total = 1;
   else
*total = 0;
diff --git a/gcc/testsuite/gcc.target/i386/pr65103-3.c 
b/gcc/testsuite/gcc.target/i386/pr65103-3.c
new file mode 100644
index 000..eddf20b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr65103-3.c
@@ -0,0 +1,19 @@
+/* { dg-do compile { target ia32 } } */
+/* { dg-require-effective-target pie } */
+/* { dg-options "-O2 -fPIE" } */
+/* { dg-final { scan-assembler-not "GOTOFF," } } */
+
+static int *data[100];
+
+void test (long a, long b)
+{
+  do
+{
+  if( a < b )
+{
+ data[a] = data[b];
+ a++;
+}
+}
+  while (a <= b);
+}

Re: My patch for GCC 5 directory names

[Richard Biener]

On Tue, 12 May 2015, H.J. Lu wrote:

> On Tue, May 12, 2015 at 9:32 AM, Richard Biener  wrote:
> > On May 12, 2015 6:11:45 PM GMT+02:00, "H.J. Lu"  wrote:
> >>On Tue, May 12, 2015 at 9:09 AM, Richard Biener
> >> wrote:
> >>> On May 12, 2015 5:58:07 PM GMT+02:00, "H.J. Lu" 
> >>wrote:
> On Tue, May 12, 2015 at 8:28 AM, Michael Matz  wrote:
> > Hi,
> >
> > On Tue, 12 May 2015, H.J. Lu wrote:
> >
> >> >> So we have
> >> >>
> >> >> experimental
> >> >> release
> >> >> post-release
> >> >>
> >> >> Why not just rename prerelease to post-release? That is a
> one-line
> >> >> change.
> >> >
> >> > Why print anything at all?  5.1.1 is after 5.1.0 in obvious
> >>ways.
> >> >
> >>
> >> How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
> >> on May 12, 2015?
> >
> > Via the svn revision.  But as the subject says, this patch is not
> >>so
> much
> 
> So? Doesn't post-release display the svn revision.for gcc -v, which
> gcc -v doesn't display today? Something like this
> 
> diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE
> index e69de29..ee176f8 100644
> --- a/gcc/DEV-PHASE
> +++ b/gcc/DEV-PHASE
> @@ -0,0 +1 @@
> +post-release
> >>>
> >>> Printing post-release doesn't add any information.  I believe Jakub
> >>fixed the missing svn revision printing already.
> >>>
> >>
> >>What is the real benefit of your patch?
> >
> > It keeps an unchanging directory structure for the whole GCC 5 series (also 
> > requested by customers in the past). I've been asked to post the patch I am 
> > using for this.  Previous discussion concluded that we want a configury to 
> > control this.
> 
> Why do we have to change directory structure on GCC 5 branch?
> Is there a GCC bug for this request?

We don't have to do this and we definitely are not going to change the 
default.

Richard.

Re: [PATCH] Support vectorizing SLP with mixed plus/minus

[Andreas Schwab]

Richard Biener  writes:

>   PR tree-optimization/37021
>   * tree-vectorizer.h (struct _slp_tree): Add two_operators flag.
>   (SLP_TREE_TWO_OPERATORS): New define.
>   * tree-vect-slp.c (vect_create_new_slp_node): Initialize
>   SLP_TREE_TWO_OPERATORS.
>   (vect_build_slp_tree_1): Allow two mixing plus/minus in an
>   SLP node.
>   (vect_build_slp_tree): Adjust.
>   (vect_analyze_slp_cost_1): Likewise.
>   (vect_schedule_slp_instance): Vectorize mixing plus/minus by
>   emitting two vector stmts and mixing the results.

FAIL: gcc.dg/vect/vect-strided-a-mult.c execution test

on both aarch64 and ia64.

Andreas.

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

[PATCH 2/7] [D] libiberty: Fail if reached end of symbol string

[Iain Buclaw]

If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.

---
libiberty/ChangeLog

2015-05-13 Iain Buclaw  

* d-demangle.c (dlang_call_convention): Return NULL if have reached the
end of the symbol, but expected more.
(dlang_attributes): Likewise.
(dlang_function_type): Likewise.
(dlang_type): Likewise.
(dlang_identifier): Likewise.
(dlang_value): Likewise.
From e9806a182f8296d92a99d842edab6a4c29124eb1 Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Wed, 13 May 2015 08:50:55 +0200
Subject: [PATCH 2/7] D demangle: Fail early on bad symbols

---
 libiberty/d-demangle.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index fa01767..91c6d55 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -185,7 +185,7 @@ static const char *
 dlang_call_convention (string *decl, const char *mangled)
 {
   if (mangled == NULL || *mangled == '\0')
-return mangled;
+return NULL;
 
   switch (*mangled)
 {
@@ -221,7 +221,7 @@ static const char *
 dlang_attributes (string *decl, const char *mangled)
 {
   if (mangled == NULL || *mangled == '\0')
-return mangled;
+return NULL;
 
   while (*mangled == 'N')
 {
@@ -280,7 +280,7 @@ dlang_function_type (string *decl, const char *mangled)
   size_t szattr, szargs, sztype;
 
   if (mangled == NULL || *mangled == '\0')
-return mangled;
+return NULL;
 
   /* The order of the mangled string is:
 	CallConvention FuncAttrs Arguments ArgClose Type
@@ -380,7 +380,7 @@ static const char *
 dlang_type (string *decl, const char *mangled)
 {
   if (mangled == NULL || *mangled == '\0')
-return mangled;
+return NULL;
 
   switch (*mangled)
 {
@@ -600,7 +600,7 @@ static const char *
 dlang_identifier (string *decl, const char *mangled)
 {
   if (mangled == NULL || *mangled == '\0')
-return mangled;
+return NULL;
 
   if (ISDIGIT (*mangled))
 {
@@ -1061,7 +1061,7 @@ static const char *
 dlang_value (string *decl, const char *mangled, const char *name, char type)
 {
   if (mangled == NULL || *mangled == '\0')
-return mangled;
+return NULL;
 
   switch (*mangled)
 {
-- 
2.1.0

[PATCH 1/7] [D] libiberty: Correctly decode white or non-printable characters

[Iain Buclaw]

Hi,

Started these as separate patches, but as more came out of what I was
originally trying to achieve (see Patch 6/7), I thought it better to
have it as a running series.

These set out to update d-demangle.c for new ABI additions, general
bug fixes, and improved template support.
---

D templates can have string literals encoded inside them, which can
also include tabs, newlines, and other whitespace characters.  For
example:

return getHost!q{
auto he = gethostbyname(toStringz(param));
}(name);


In this case, rather than decoding and writing out every character
directly, whitespace or other non-printable characters should be
represented as escape sequences.

---
libiberty/ChangeLog:

2015-05-13 Iain Buclaw  

* d-demangle.c (dlang_parse_string): Represent embedded whitespace or
non-printable characters as hex or escape sequences.
* testsuite/d-demangle-expected: Add test for templates with tabs and
newlines embedded into the signature.
From f6d6383994f0537f3e9b527419232ae69e2ceb4a Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Mon, 11 May 2015 09:20:29 +0200
Subject: [PATCH 1/7] D demangle: Correctly decode white or non-printable
 characters

---
 libiberty/d-demangle.c  | 33 -
 libiberty/testsuite/d-demangle-expected |  4 
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index bb481c0..fa01767 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -931,7 +931,38 @@ dlang_parse_string (string *decl, const char *mangled)
 	  char a = ascii2hex (mangled[0]);
 	  char b = ascii2hex (mangled[1]);
 	  char val = (a << 4) | b;
-	  string_appendn (decl, &val, 1);
+
+	  /* Sanitize white and non-printable characters.  */
+	  switch (val)
+	{
+	case ' ':
+	  string_append (decl, " ");
+	  break;
+	case '\t':
+	  string_append (decl, "\\t");
+	  break;
+	case '\n':
+	  string_append (decl, "\\n");
+	  break;
+	case '\r':
+	  string_append (decl, "\\r");
+	  break;
+	case '\f':
+	  string_append (decl, "\\f");
+	  break;
+	case '\v':
+	  string_append (decl, "\\v");
+	  break;
+
+	default:
+	  if (ISPRINT (val))
+		string_appendn (decl, &val, 1);
+	  else
+		{
+		  string_append (decl, "\\x");
+		  string_appendn (decl, mangled, 2);
+		}
+	}
 	}
   else
 	return NULL;
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 2aeacb8..b023f6d 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -934,3 +934,7 @@ serenity.persister.Sqlite.SqlitePersister!(serenity.persister.Sqlite.__unittest6
 --format=dlang
 _D4test4mainFZv5localMFZi
 test.main().local()
+#
+--format=dlang
+_D3std6socket12InternetHost221__T13getHostNoSyncVAyaa96_0a09202020206175746f2078203d2068746f6e6c28706172616d293b0a09202020206175746f206865203d20676574686f73746279616464722826782c20342c206361737428696e74294164647265737346616d696c792e494e4554293b0a09TkZ13getHostNoSyncMFkZb
+std.socket.InternetHost.getHostNoSync!("\n\tauto x = htonl(param);\n\tauto he = gethostbyaddr(&x, 4, cast(int)AddressFamily.INET);\n\t", uint).getHostNoSync(uint)
-- 
2.1.0

[PATCH 3/7] [D] libiberty: Include type modifiers in demangled function symbols

[Iain Buclaw]

Like C++ const and volatile, in D mangled symbols can exist modifiers
that represent the const, immutable, inout and shared-ness of the
'this' parameter.

This information should be written out in the demangled symbol to show
that each variant has a unique identity.

---
libiberty/ChangeLog:

2015-05-13 Iain Buclaw  
* d-demangle.c (dlang_type_modifiers): New function.
(dlang_type_modifier_p): New function.
(dlang_call_convention_p): Ignore any kind of type modifier.
(dlang_type): Handle and emit the type modifier after delegate types.
(dlang_parse_symbol): Handle and emit the type modifier after the symbol.
* testsuite/d-demangle-expected: Add coverage tests for all valid
usages of function symbols with type modifiers.
From 6836ff778e26dd0312d4d33a0570d979ba59a4ca Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Mon, 11 May 2015 09:20:55 +0200
Subject: [PATCH 3/7] D demangle: Include type modifiers in demangled function
 symbols

---
 libiberty/d-demangle.c  | 111 
 libiberty/testsuite/d-demangle-expected |  32 +
 2 files changed, 130 insertions(+), 13 deletions(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 91c6d55..bfad5bb 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -215,6 +215,44 @@ dlang_call_convention (string *decl, const char *mangled)
   return mangled;
 }
 
+/* Extract the type modifiers from MANGLED and append them to DECL.
+   Returns the remaining signature on success or NULL on failure.  */
+static const char *
+dlang_type_modifiers (string *decl, const char *mangled)
+{
+  if (mangled == NULL || *mangled == '\0')
+return NULL;
+
+  switch (*mangled)
+{
+case 'x': /* const */
+  mangled++;
+  string_append (decl, " const");
+  return mangled;
+case 'y': /* immutable */
+  mangled++;
+  string_append (decl, " immutable");
+  return mangled;
+case 'O': /* shared */
+  mangled++;
+  string_append (decl, " shared");
+  return dlang_type_modifiers (decl, mangled);
+case 'N':
+  mangled++;
+  if (*mangled == 'g') /* wild */
+	{
+	  mangled++;
+	  string_append (decl, " inout");
+	  return dlang_type_modifiers (decl, mangled);
+	}
+  else
+	return NULL;
+
+default:
+  return mangled;
+}
+}
+
 /* Demangle the D function attributes from MANGLED and append it to DECL.
Return the remaining string on success or NULL on failure.  */
 static const char *
@@ -476,10 +514,22 @@ dlang_type (string *decl, const char *mangled)
   mangled++;
   return dlang_parse_symbol (decl, mangled);
 case 'D': /* delegate T */
+{
+  string mods;
+  size_t szmods;
   mangled++;
+
+  string_init (&mods);
+  mangled = dlang_type_modifiers (&mods, mangled);
+  szmods = string_length (&mods);
+
   mangled = dlang_function_type (decl, mangled);
   string_append (decl, "delegate");
+  string_appendn (decl, mods.b, szmods);
+
+  string_delete (&mods);
   return mangled;
+}
 case 'B': /* tuple T */
   mangled++;
   return dlang_parse_tuple (decl, mangled);
@@ -1135,28 +1185,54 @@ dlang_value (string *decl, const char *mangled, const char *name, char type)
   return mangled;
 }
 
+/* Extract the type modifiers from MANGLED and return the string
+   length that it consumes in MANGLED on success or 0 on failure.  */
 static int
-dlang_call_convention_p (const char *mangled)
+dlang_type_modifier_p (const char *mangled)
 {
-  size_t i;
+  int i;
 
   switch (*mangled)
 {
-case 'F': case 'U': case 'V':
-case 'W': case 'R':
+case 'x': case 'y':
   return 1;
 
-case 'M': /* Prefix for functions needing 'this' */
-  i = 1;
-  if (mangled[i] == 'x')
-	i++;
+case 'O':
+  mangled++;
+  i = dlang_type_modifier_p (mangled);
+  return i + 1;
 
-  switch (mangled[i])
+case 'N':
+  mangled++;
+  if (*mangled == 'g')
 	{
-	case 'F': case 'U': case 'V':
-	case 'W': case 'R':
-	  return 1;
+	  mangled++;
+	  i = dlang_type_modifier_p (mangled);
+	  return i + 2;
 	}
+}
+
+  return 0;
+}
+
+/* Extract the function calling convention from MANGLED and
+   return 1 on success or 0 on failure.  */
+static int
+dlang_call_convention_p (const char *mangled)
+{
+  /* Prefix for functions needing 'this' */
+  if (*mangled == 'M')
+{
+  mangled++;
+  /* Also skip over any type modifiers.  */
+  mangled += dlang_type_modifier_p (mangled);
+}
+
+  switch (*mangled)
+{
+case 'F': case 'U': case 'V':
+case 'W': case 'R':
+  return 1;
 
 default:
   return 0;
@@ -1178,11 +1254,16 @@ dlang_parse_symbol (string *decl, const char *mangled)
 
   if (mangled && dlang_call_convention_p (mangled))
 	{
+	  string mods;
 	  int saved;
 
 	  /* Skip over 'this' parameter.  */
 	  if (*mangled == 'M')
-	mangled += (mangled[1] == 'x') ? 2 : 1;
+	mangled++;
+
+	  /* S

[PATCH 5/7] [D] libiberty: Add support for return parameter and attributes

[Iain Buclaw]

The next version of D introduces two new mangle conventions.

- Nj to represent methods whose 'this' parameter is also the function
return value
- Nk to represent a 'ref' parameter that is also the function return value

This patch introduces support for these two symbols.

---
libiberty/ChangeLog:

2015-05-13 Iain Buclaw  

* d-demangle.c (dlang_attributes): Handle return attributes, ignoring
return parameters in the mangled string.  Return NULL if have encountered
an unknown attribute.
(dlang_function_args): Handle return parameters in the mangled string.
* testsuite/d-demangle-expected: Add coverage tests for functions with
return parameters and return attributes.
From 8d4f404a7181390983aef485e1bcb7d568d9751d Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Mon, 11 May 2015 09:22:21 +0200
Subject: [PATCH 5/7] D demangle: Add support for return parameter and
 attribute symbols

---
 libiberty/d-demangle.c  | 15 +
 libiberty/testsuite/d-demangle-expected | 40 +
 2 files changed, 55 insertions(+)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 4315071..0af926c 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -292,8 +292,10 @@ dlang_attributes (string *decl, const char *mangled)
 	  continue;
 	case 'g':
 	case 'h':
+	case 'k':
 	  /* inout parameter is represented as 'Ng'.
 	 vector parameter is represented as 'Nh'.
+	 return paramenter is represented as 'Nk'.
 	 If we see this, then we know we're really in the
 	 parameter list.  Rewind and break.  */
 	  mangled--;
@@ -302,6 +304,13 @@ dlang_attributes (string *decl, const char *mangled)
 	  mangled++;
 	  string_append (decl, "@nogc ");
 	  continue;
+	case 'j': /* return */
+	  mangled++;
+	  string_append (decl, "return ");
+	  continue;
+
+	default: /* unknown attribute */
+	  return NULL;
 	}
   break;
 }
@@ -391,6 +400,12 @@ dlang_function_args (string *decl, const char *mangled)
 	  string_append (decl, "scope ");
 	}
 
+  if (mangled[0] == 'N' && mangled[1] == 'k') /* return(T) */
+	{
+	  mangled += 2;
+	  string_append (decl, "return ");
+	}
+
   switch (*mangled)
 	{
 	case 'J': /* out(T) */
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 43de5af..ae0e8d3 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -314,6 +314,14 @@ _D8demangle4testFMaZv
 demangle.test(scope char)
 #
 --format=dlang
+_D8demangle4testFNjaZv
+demangle.test(char)
+#
+--format=dlang
+_D8demangle4testFNkaZv
+demangle.test(return char)
+#
+--format=dlang
 _D8demangle4testFaXv
 demangle.test(char...)
 #
@@ -434,6 +442,22 @@ _D8demangle4testFDFNdNfNaZaZv
 demangle.test(char() @property @safe pure delegate)
 #
 --format=dlang
+_D8demangle4testFNjDFZaZv
+demangle.test(char() delegate)
+#
+--format=dlang
+_D8demangle4testFNkDFZaZv
+demangle.test(return char() delegate)
+#
+--format=dlang
+_D8demangle4testFDFNjZaZv
+demangle.test(char() return delegate)
+#
+--format=dlang
+_D8demangle4testFNjNkDFNjZaZv
+demangle.test(return char() return delegate)
+#
+--format=dlang
 _D8demangle4testFFNaZaZv
 demangle.test(char() pure function)
 #
@@ -474,6 +498,22 @@ _D8demangle4testFFNdNfNaZaZv
 demangle.test(char() @property @safe pure function)
 #
 --format=dlang
+_D8demangle4testFNjFZaZv
+demangle.test(char() function)
+#
+--format=dlang
+_D8demangle4testFNkFZaZv
+demangle.test(return char() function)
+#
+--format=dlang
+_D8demangle4testFFNjZaZv
+demangle.test(char() return function)
+#
+--format=dlang
+_D8demangle4testFNjNkFNjZaZv
+demangle.test(return char() return function)
+#
+--format=dlang
 _D8demangle4test6__initZ
 demangle.test.init$
 #
-- 
2.1.0

[PATCH 4/7] [D] libiberty: Check symbol length before using strncmp

[Iain Buclaw]

This addresses a subtle logic error, noticed when I was in the middle
of testing out some other tightening up of parsing checks.

---
libiberty/ChangeLog

2015-05-13 Iain Buclaw  

* d-demangle.c (dlang_identifier): Check encoded length of identifier
to verify strncmp matches entire string.
* testsuite/d-demangle-expected: Fix wrong test for postblit symbols.
From 6326e0e960b234967d8fa2ccb47eeae8f5768fb3 Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Mon, 11 May 2015 09:21:43 +0200
Subject: [PATCH 4/7] D demangle: Check identifier length before using strncmp

---
 libiberty/d-demangle.c  | 133 ++--
 libiberty/testsuite/d-demangle-expected |   2 +-
 2 files changed, 76 insertions(+), 59 deletions(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index bfad5bb..4315071 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -672,65 +672,82 @@ dlang_identifier (string *decl, const char *mangled)
 	  return NULL;
 	}
 
-  if (strncmp (mangled, "__ctor", i) == 0)
+  switch (i)
 	{
-	  /* Constructor symbol for a class/struct.  */
-	  string_append (decl, "this");
-	  mangled += i;
-	  return mangled;
-	}
-  else if (strncmp (mangled, "__dtor", i) == 0)
-	{
-	  /* Destructor symbol for a class/struct.  */
-	  string_append (decl, "~this");
-	  mangled += i;
-	  return mangled;
-	}
-  else if (strncmp (mangled, "__postblit", i) == 0)
-	{
-	  /* Postblit symbol for a struct.  */
-	  string_append (decl, "this(this)");
-	  mangled += i;
-	  return mangled;
-	}
-  else if (strncmp (mangled, "__initZ", i+1) == 0)
-	{
-	  /* The static initialiser for a given symbol.  */
-	  string_append (decl, "init$");
-	  mangled += i + 1;
-	  return mangled;
-	}
-  else if (strncmp (mangled, "__ClassZ", i+1) == 0)
-	{
-	  /* The classinfo symbol for a given class.  */
-	  string_prepend (decl, "ClassInfo for ");
-	  string_setlength (decl, string_length (decl) - 1);
-	  mangled += i + 1;
-	  return mangled;
-	}
-  else if (strncmp (mangled, "__vtblZ", i+1) == 0)
-	{
-	  /* The vtable symbol for a given class.  */
-	  string_prepend (decl, "vtable for ");
-	  string_setlength (decl, string_length (decl) - 1);
-	  mangled += i + 1;
-	  return mangled;
-	}
-  else if (strncmp (mangled, "__InterfaceZ", i+1) == 0)
-	{
-	  /* The interface symbol for a given class.  */
-	  string_prepend (decl, "Interface for ");
-	  string_setlength (decl, string_length (decl) - 1);
-	  mangled += i + 1;
-	  return mangled;
-	}
-  else if (strncmp (mangled, "__ModuleInfoZ", i+1) == 0)
-	{
-	  /* The ModuleInfo symbol for a given module.  */
-	  string_prepend (decl, "ModuleInfo for ");
-	  string_setlength (decl, string_length (decl) - 1);
-	  mangled += i + 1;
-	  return mangled;
+	case 6:
+	  if (strncmp (mangled, "__ctor", i) == 0)
+	{
+	  /* Constructor symbol for a class/struct.  */
+	  string_append (decl, "this");
+	  mangled += i;
+	  return mangled;
+	}
+	  else if (strncmp (mangled, "__dtor", i) == 0)
+	{
+	  /* Destructor symbol for a class/struct.  */
+	  string_append (decl, "~this");
+	  mangled += i;
+	  return mangled;
+	}
+	  else if (strncmp (mangled, "__initZ", i+1) == 0)
+	{
+	  /* The static initialiser for a given symbol.  */
+	  string_append (decl, "init$");
+	  mangled += i;
+	  return mangled;
+	}
+	  else if (strncmp (mangled, "__vtblZ", i+1) == 0)
+	{
+	  /* The vtable symbol for a given class.  */
+	  string_prepend (decl, "vtable for ");
+	  string_setlength (decl, string_length (decl) - 1);
+	  mangled += i;
+	  return mangled;
+	}
+	  break;
+
+	case 7:
+	  if (strncmp (mangled, "__ClassZ", i+1) == 0)
+	{
+	  /* The classinfo symbol for a given class.  */
+	  string_prepend (decl, "ClassInfo for ");
+	  string_setlength (decl, string_length (decl) - 1);
+	  mangled += i;
+	  return mangled;
+	}
+	  break;
+
+	case 10:
+	  if (strncmp (mangled, "__postblitMFZ", i+3) == 0)
+	{
+	  /* Postblit symbol for a struct.  */
+	  string_append (decl, "this(this)");
+	  mangled += i + 3;
+	  return mangled;
+	}
+	  break;
+
+	case 11:
+	  if (strncmp (mangled, "__InterfaceZ", i+1) == 0)
+	{
+	  /* The interface symbol for a given class.  */
+	  string_prepend (decl, "Interface for ");
+	  string_setlength (decl, string_length (decl) - 1);
+	  mangled += i;
+	  return mangled;
+	}
+	  break;
+
+	case 12:
+	  if (strncmp (mangled, "__ModuleInfoZ", i+1) == 0)
+	{
+	  /* The ModuleInfo symbol for a given module.  */
+	  string_prepend (decl, "ModuleInfo for ");
+	  string_setlength (decl, string_length (decl) - 1);
+	  mangled += i;
+	  return mangled;
+	}
+	  break;
 	}
 
   string_appendn (decl, mangled, i);
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
inde

[PATCH 6/7] [D] libiberty: Improve support for demangling D2 templates

[Iain Buclaw]

In my tests, this gives the demangler near-complete support.  Of a
sample of about 75k symbols pulled from the standard library
unittester, all but 20 were successfully parsed.

---
libiberty/ChangeLog:

2015-05-13 Iain Buclaw  

* d-demangle.c (dlang_symbol_kinds): New enum.
(dlang_parse_symbol): Update signature.  Handle an ambiguity between mangle
symbol for pascal and template value arguments.  Only check for a type
if parsing a function, or at the top level.  Return failure if the
entire symbol was not successfully demangled.
(dlang_identifier): Update signature.  Handle an ambiguity between two
adjacent digits in a mangled symbol string.
(dlang_type): Update call to dlang_parse_symbol.
(dlang_template_args): Likewise.
(dlang_parse_template): Likewise.
(dlang_demangle): Likewise.
* testsuite/d-demangle-expected: Fix bad tests found, and add problematic
examples to the unittests.
From 32a49ea35f26964a7b4c8667835cd5c63b9baa43 Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Mon, 11 May 2015 10:08:31 +0200
Subject: [PATCH 6/7] D demangle: Better support for D template symbols

---
 libiberty/d-demangle.c  | 191 
 libiberty/testsuite/d-demangle-expected |  44 ++--
 2 files changed, 181 insertions(+), 54 deletions(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 0af926c..a7821d8 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -165,6 +165,21 @@ string_prepend (string *p, const char *s)
 }
 }
 
+/* What kinds of symbol we could be parsing.  */
+enum dlang_symbol_kinds
+{
+  /* Top-level symbol, needs it's type checked.  */
+  dlang_top_level,
+  /* Function symbol, needs it's type checked.   */
+  dlang_function,
+  /* Strongly typed name, such as for classes, structs and enums.  */
+  dlang_type_name,
+  /* Template identifier.  */
+  dlang_template_ident,
+  /* Template symbol parameter.  */
+  dlang_template_param
+};
+
 /* Prototypes for forward referenced functions */
 static const char *dlang_function_args (string *, const char *);
 
@@ -172,7 +187,8 @@ static const char *dlang_type (string *, const char *);
 
 static const char *dlang_value (string *, const char *, const char *, char);
 
-static const char *dlang_parse_symbol (string *, const char *);
+static const char *dlang_parse_symbol (string *, const char *,
+   enum dlang_symbol_kinds);
 
 static const char *dlang_parse_tuple (string *, const char *);
 
@@ -527,7 +543,7 @@ dlang_type (string *decl, const char *mangled)
 case 'E': /* enum T */
 case 'T': /* typedef T */
   mangled++;
-  return dlang_parse_symbol (decl, mangled);
+  return dlang_parse_symbol (decl, mangled, dlang_type_name);
 case 'D': /* delegate T */
 {
   string mods;
@@ -662,114 +678,168 @@ dlang_type (string *decl, const char *mangled)
 /* Extract the identifier from MANGLED and append it to DECL.
Return the remaining string on success or NULL on failure.  */
 static const char *
-dlang_identifier (string *decl, const char *mangled)
+dlang_identifier (string *decl, const char *mangled,
+		  enum dlang_symbol_kinds kind)
 {
+  char *endptr;
+  long len;
+
   if (mangled == NULL || *mangled == '\0')
 return NULL;
 
-  if (ISDIGIT (*mangled))
+  len = strtol (mangled, &endptr, 10);
+
+  if (endptr == NULL || len <= 0)
+return NULL;
+
+  /* In template parameter symbols, the first character of the mangled
+ name can be a digit.  This causes ambiguity issues because the
+ digits of the two numbers are adjacent.  */
+  if (kind == dlang_template_param)
 {
-  char *endptr;
-  long i = strtol (mangled, &endptr, 10);
+  const char *pstart = mangled;
+  char *pend = endptr;
+  long psize = len;
+  int saved = string_length (decl);
+
+  /* First handle any overflow.  */
+  while (strlen (endptr) < (size_t) len)
+	{
+	  len /= 10;
+	  endptr--;
+	}
 
-  if (endptr == NULL || i <= 0 || strlen (endptr) < (size_t) i)
+  /* Work backwards until a match is found.  */
+  for (; pend >= pstart; pend--)
+	{
+	  mangled = pend;
+
+	  /* Reached the beginning of the pointer to the name length,
+	 try parsing the entire symbol.  */
+	  if (psize == 0)
+	{
+	  psize = len;
+	  pend = endptr;
+	}
+
+	  /* Check whether template parameter is a function with a valid
+	 return type or an untyped identifier.  */
+	  if (ISDIGIT (*mangled))
+	mangled = dlang_parse_symbol (decl, mangled, dlang_template_ident);
+	  else if (strncmp (mangled, "_D", 2) == 0)
+	{
+	  mangled += 2;
+	  mangled = dlang_parse_symbol (decl, mangled, dlang_function);
+	}
+
+	  /* Check for name length mismatch.  */
+	  if (mangled && (mangled - pend) == psize)
+	return mangled;
+
+	  psize /= 10;
+	  string_setlength (decl, saved);
+	}
+
+  return NULL;
+}
+  else
+{
+  if (strlen (endptr) < (size_t) len)
 	return

[PATCH 7/7] [D] libiberty: Add support for cent and ucent types

[Iain Buclaw]

The next version of D adds support for cent and ucent for platforms
that are able to handle them natively.  This adds support for
demangling them.

---
libiberty/ChangeLog:

2015-05-13 Iain Buclaw  

* d-demangle.c (dlang_type): Handle cent and ucent types.
* testsuite/d-demangle-expected: Add coverage tests for cent and ucent.
From 7fe0bf5d0b218f18cba3097be8c166e9934091eb Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Mon, 11 May 2015 22:21:13 +0200
Subject: [PATCH 7/7] D demangle: Add support for cent and ucent types

---
 libiberty/d-demangle.c  | 14 ++
 libiberty/testsuite/d-demangle-expected |  8 
 2 files changed, 22 insertions(+)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index a7821d8..5c0f356 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -669,6 +669,20 @@ dlang_type (string *decl, const char *mangled)
   mangled++;
   string_append (decl, "dchar");
   return mangled;
+case 'z':
+  mangled++;
+  switch (*mangled)
+	{
+	case 'i':
+	  mangled++;
+	  string_append (decl, "cent");
+	  return mangled;
+	case 'k':
+	  mangled++;
+	  string_append (decl, "ucent");
+	  return mangled;
+	}
+  return NULL;
 
 default: /* unhandled */
   return NULL;
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index d88fb26..580da9b 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -114,6 +114,14 @@ _D8demangle4testFwZv
 demangle.test(dchar)
 #
 --format=dlang
+_D8demangle4testFziZv
+demangle.test(cent)
+#
+--format=dlang
+_D8demangle4testFzkZv
+demangle.test(ucent)
+#
+--format=dlang
 _D8demangle4testFOaZv
 demangle.test(shared(char))
 #
-- 
2.1.0

Re: [PATCH][PR66010] Don't take address of ap unless necessary

[Richard Biener]

On Wed, 13 May 2015, Andreas Krebbel wrote:

> On 05/12/2015 01:45 PM, Tom de Vries wrote:
> > On 12-05-15 12:04, Tom de Vries wrote:
> >> Committed with comments below added.
> > 
> > Hmm, this causes an ice for s390 in gcc.dg/tree-ssa/stdarg-2.c:
> > ...
> > gimplification failed:
> > &ap  >  type  >  type  > 0x7f132f46b888 __va_list_tag>
> >  sizes-gimplified BLK
> >  size 
> >  unit size 
> >  align 32 symtab 0 alias set -1 canonical type 0x7f132f46b9d8 
> > domain 
> >  context  > D.1477>
> >  pointer_to_this >
> >  unsigned SI
> >  size 
> >  unit size 
> >  align 32 symtab 0 alias set -1 canonical type 0x7f132f55f2a0>
> > 
> >  arg 0  > va_list>
> >  addressable used BLK file stdarg-2.c line 32 col 11 size 
> >  > 0x7f132f4539f0 128> unit size 
> >  align 32 context >
> >  stdarg-2.c:35:15>
> > stdarg-2.c: In function ‘f2’:
> > stdarg-2.c:35:15: internal compiler error: gimplification failed
> > res = f2_1 (ap);
> > ^
> > 0xad3d02 gimplify_expr(tree_node**, gimple_statement_base**, 
> > gimple_statement_base**, bool (*)(tree_node*), int)
> > /home/vries/gcc_versions/devel/devel3/src/gcc/gimplify.c:8856
> > 0xad5762 gimplify_va_arg_internal(tree_node*, tree_node*, 
> > gimple_statement_base**, gimple_statement_base**)
> > /home/vries/gcc_versions/devel/devel3/src/gcc/gimplify.c:9326
> > 0x10a3349 expand_ifn_va_arg_1
> > /home/vries/gcc_versions/devel/devel3/src/gcc/tree-stdarg.c:1062
> > 0x10a3596 expand_ifn_va_arg
> > /home/vries/gcc_versions/devel/devel3/src/gcc/tree-stdarg.c:1122
> > 0x10a36d3 execute
> > /home/vries/gcc_versions/devel/devel3/src/gcc/tree-stdarg.c:1174
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > ...
> > 
> > Attached patch is a tentative fix. I'll bootstrap and reg-test on x86_64.
> 
> S/390 doesn't bootstrap since r223054. This patch fixes it.

The patch is ok.

Richard.

> 
> -Andreas-
> 
> 

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

Re: [PATCH, ARM] attribute target (thumb,arm) [2.1/6] respin (5th)

[Kyrill Tkachov]

On 13/05/15 09:49, Christian Bruel wrote:

   2 parts for maintainers

   - c-family: machine descriptions export macro definitions into c
implementation : need to export 'builtin_define_with_int_value' and '
builtin_define_type_sizeof'


+1 on this. It would help me a lot in implementing
target attributes and pragmas in aarch64 as well.

Kyrill



 Could a global reviewer check this ?

   - ARM: Move the CPP builtins from arm.h to arm-c.c

many thanks

Christian

Re: [Patch, fortran, pr65548, 2nd take, v3] [5/6 Regression] gfc_conv_procedure_call

[Andre Vehreschild]

Hi Mikael,


> > --- 5198,5222 
> >   /* In all other cases evaluate the expr3 and create a
> >  temporary.  */
> >   gfc_init_se (&se, NULL);
> > + /* For more complicated expression, the decision when to get the
> > +descriptor and when to get a reference is depending on more
> > +conditions.  The descriptor is only retrieved for functions
> > +that are intrinsic, elemental user-defined and known, or
> > neither
> > +of the two, or are a class or type, that has a not deferred
> > type
> > +array_spec.  */
> >   if (code->expr3->rank != 0
> > ! && (code->expr3->expr_type != EXPR_FUNCTION
> > ! || code->expr3->value.function.isym
> > ! || (code->expr3->value.function.esym &&
> > ! code->expr3->value.function.esym->attr.elemental)
> > ! || (!code->expr3->value.function.isym
> > ! && !code->expr3->value.function.esym)
> > ! || (code->expr3->ts.type == BT_DERIVED
> > ! && code->expr3->ts.u.derived->as
> > ! && code->expr3->ts.u.derived->as->type !=
> > AS_DEFERRED) !|| (code->expr3->ts.type == BT_CLASS
> > ! && CLASS_DATA (code->expr3)->as
> > ! && CLASS_DATA (code->expr3)->as->type !=
> > AS_DEFERRED))) gfc_conv_expr_descriptor (&se, code->expr3);
> >   else
> > gfc_conv_expr_reference (&se, code->expr3);
> What is the rationale for choosing between gfc_conv_expr_descriptor and
> gfc_conv_expr_reference?

The rationale is to get the array descriptor for all arrays, but deferred type
ones. For deferred type ones gfc_conv_expr_descriptor either failed or the
result does not satisfy further processing needs.

> Is it contiguous array vs non-contiguous or needing an evaluation?

Neither. How the array is shaped is not of my concern.

> For example why not use gfc_conv_expr_descriptor for derived type arrays?

But it does use gfc_conv_expr_descriptor for derived type arrays! It is just
not used for deferred ones.

> > ***
> > *** 5646,5659 
> > }
> >   else if (code->expr3->ts.type == BT_CHARACTER)
> > {
> > ! tmp = INDIRECT_REF_P (se.expr) ?
> > se.expr :
> > build_fold_indirect_ref_loc (input_location,
> >  se.expr);
> > ! gfc_trans_string_copy (&block, al_len, tmp,
> > !code->expr3->ts.kind,
> > !expr3_len, expr3,
> > !code->expr3->ts.kind);
> >   tmp = NULL_TREE;
> > }
> >   else if (al->expr->ts.type == BT_CLASS)
> > --- 5658,5707 
> > }
> >   else if (code->expr3->ts.type == BT_CHARACTER)
> > {
> > ! tree dst, src, dlen, slen;
> > ! /* For arrays of char arrays, a ref to the data component
> > still !  needs to be added, because se.expr upto now only
> > contains the !   descritor.  */
> > ! if (expr->ref && se.expr && TREE_TYPE (se.expr) != NULL_TREE
> > ! && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se.expr)))
> > !   {
> > ! dst = gfc_conv_array_data (se.expr);
> > ! src = gfc_conv_array_data (expr3);
> > ! /* For CHARACTER (len=string_length), dimension (nelems)
> > !compute the total length of the string to copy.  */
> > ! if (nelems)
> > !   {
> > ! dlen = fold_build2_loc (input_location, MULT_EXPR,
> > ! size_type_node,
> > ! fold_convert
> > (size_type_node, !
> > se.string_length), !
> >   fold_convert
> > (size_type_node, !
> > nelems)); !
> >   slen = fold_build2_loc (input_location, MULT_EXPR, !
> >   size_type_node, !
> >   fold_convert
> > (size_type_node, !
> > expr3_len), !
> >   fold_convert
> > (size_type_node, !
> > nelems)); !
> > } !   else !{ !
> >   dlen = se.string_length; !  slen
> > = expr3_len; !  } ! }
> > ! else
> > !   {
> > ! dst = INDIRECT_REF_P (se.expr) ?
> > se.expr :
> > build_fold_indirect_ref_loc (input_location,
> >  se.expr);
> > ! src = expr3;
> > ! dlen = al_len;
> > ! 

Re: [PATCH] Fix va_arg gimplification error for s390

[Richard Biener]

On Wed, May 13, 2015 at 9:38 AM, Tom de Vries  wrote:
> Hi,
>
> this patch fixes a gimplification error of the va_list argument of va_arg
> for target s390. The error was introduced by r223054, the fix for PR66010.
>
>
> I.
>
> consider test-case:
> ...
> #include 
>
> int
> f1 (int i, ...)
> {
>   int res;
>   va_list ap;
>
>   va_start (ap, i);
>   res = va_arg (ap, int);
>   va_end (ap);
>
>   return res;
> }
> ...
>
> For target s390, we're running into a gimplification error for valist '&ap'
> in gimplify_va_arg_internal when calling:
> ...
> 9326gimplify_expr (&valist, pre_p, post_p, is_gimple_min_lval,
> fb_lvalue);
> ...
>
> Before committing r223054, we were calling instead:
> ...
> 9331  gimplify_expr (&valist, pre_p, post_p, is_gimple_val,
> fb_rvalue);
> ...
> with valist '(struct  *) &ap', and the gimplification went fine.
>
>
> II.
>
> The successful gimplification was triggered using the following path,
> entering with valist 'ap':
> ...
> gimplify_va_arg_internal (tree valist, tree type, location_t loc,
>   gimple_seq *pre_p, gimple_seq *post_p)
> {
>   tree have_va_type = TREE_TYPE (valist);
>   tree cano_type = targetm.canonical_va_list_type (have_va_type);
>
>   if (cano_type != NULL_TREE)
> have_va_type = cano_type;
>
>   /* Make it easier for the backends by protecting the valist argument
>  from multiple evaluations.  */
>   if (TREE_CODE (have_va_type) == ARRAY_TYPE)
> {
>   /* For this case, the backends will be expecting a pointer to
>  TREE_TYPE (abi), but it's possible we've
>  actually been given an array (an actual TARGET_FN_ABI_VA_LIST).
>  So fix it.  */
>   if (TREE_CODE (TREE_TYPE (valist)) == ARRAY_TYPE)
> {
>   tree p1 = build_pointer_type (TREE_TYPE (have_va_type));
>   valist = fold_convert_loc (loc, p1,
>  build_fold_addr_expr_loc (loc,
> valist));
> }
>
>   gimplify_expr (&valist, pre_p, post_p, is_gimple_val, fb_rvalue);
> }
> ...
>
> In r223054, we've moved the fixup of adding the addr_expr to
> gimplify_va_arg_expr. Consequently, we're now entering with valist '&ap'.
> The have_va_type has changed to 'struct [1] *', and cano_type is NULL_TREE.
> So have_va_type is no longer an array, and the other gimplification path is
> triggered, which causes the gimplification error.
>
> [ For x86_64, the type of '&ap' is not 'struct [1] *' but 'struct *', and
> the
>   cano_type is not NULL_TREE, so we didn't encounter this problem there. ]
>
>
> III.
>
> The patch fixes this error by inlining gimplify_va_arg_internal into
> expand_ifn_va_arg_1, and using the information present there to determine
> which gimplification path to choose:
> ...
> if (do_deref == integer_one_node)
>   gimplify_expr (&ap, &pre, &post, is_gimple_min_lval, fb_lvalue);
> else
>   gimplify_expr (&ap, &pre, &post, is_gimple_val, fb_rvalue);
> ...
>
> So for an va_list ap given as argument of va_arg:
> - in case the canonical va_list is an array type, we take the address in
>   gimplify_va_arg_expr, set do_deref to zero, meaning we pass '&ap' to
>   targetm.gimplify_va_arg_expr. The fact that it's an address means we can
>   expect it to be an rvalue, but not an lvalue.
> - in case the canonical va_list is not an array type, we take the address in
>   gimplify_va_arg_expr, but set do_deref to one, meaning we pass 'ap' to
>   targetm.gimplify_va_arg_expr. 'ap' may be modified by va_arg, so it needs
> to
>   be an lvalue.
>
>
> IV.
>
> Bootstrapped and reg-tested on x86_64.
>
> Noted to fix s390 bootstrap:
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01176.html .
>
> Noted to fix ppc build:
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01162.html .
>
> OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
> - Tom

Re: My patch for GCC 5 directory names

[Matthias Klose]

On 05/12/2015 03:42 PM, Richard Biener wrote:
> 
> I promised to send out my pat^Whack.  Before building I introduce
> gcc/FULL-VER as copy of gcc/BASE-VER and adjust gcc/BASE-VER to
> just the major number.  Then I only need the following small
> patch (where I don't speak enough tcl for fixing libjava.exp "properly").
> 

for reference, I'm using something similar for the distro packaging,
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-5/debian/patches/gcc-base-version.diff?view=markup

addressing additional things like

 - c++ incdir
 - differentiating between the full version and the base version
   (you probably want to print out the full version for -v)

> Without the FULL-VER trick the patch would be much larger (BASE-VER
> is referenced a lot).  For a "real" patch (including configury) we
> probably want to generate a BASE-VER in the toplevel (or have
> a @BASE-VER@ substitute).

that would be nice, but then maybe introduce another macro GCCSUBDIR for
gcc//.

Matthias

Re: [patch 26/29] libstdc++-v3: Use automake-1.11.6 (across the tree)

[Jonathan Wakely]

On 06/05/15 12:21 +0200, Michael Haubenwallner wrote:

Patch for libstdc++-v3.


The libstd++ parts are OK.

N.B. libstdc++ patches should be sent to the libstdc++ list (which
saves you CCing individual maintainers.)

(Will this change mean I need to have 1.11.1 and 1.11.6 both installed
and adjust my path depending on whether I'm working on trunk or a 4.x
branch?)

Re: [patch] Clean up detection of SJLJ exceptions in target libraries

[Jonathan Wakely]

On 12/05/15 18:42 +0200, Eric Botcazou wrote:

libstdc++-v3/
* acinclude.m4 (GLIBCXX_ENABLE_SJLJ_EXCEPTIONS): Delete.
* configure.ac: Remove GLIBCXX_ENABLE_SJLJ_EXCEPTIONS.
* config.h.in: Regenerate.
* configure: Likewise.
* libsupc++/eh_personality.cc: Replace _GLIBCXX_SJLJ_EXCEPTIONS by
__USING_SJLJ_EXCEPTIONS__.
* libsupc++/eh_throw.cc: Likewise.
* libsupc++/eh_ptr.cc: Likewise.
* doc/html/manual/appendix_porting.html: Remove
GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
* doc/xml/manual/build_hacking.xml: Likewise.
* doc/html/manual/configure.html: Remove --enable-sjlj-exceptions.
* doc/xml/manual/configure.xml: Likewise.


The libstdc++ parts are OK, thanks.

[patch] Update SJLJ buffer after dynamic stack allocation

[Eric Botcazou]

Hi,

the SJLJ EH schemes manipulate a buffer that contains a few pointers and, in 
particular, the stack pointer.  Therefore, when dynamic stack allocation is 
also used, you need to update its value in the buffer, otherwise Bad Things 
will happen if you resume execution where the stack is shifted.

GNAT uses a manual SJLJ EH scheme that is piggybacked on the __builtin_setjmp 
__builtin_longjmp machinery and has this block in gcc-interface/decl.c:

/* If we are defining an object with variable size or an object with
   fixed size that will be dynamically allocated, and we are using the
   setjmp/longjmp exception mechanism, update the setjmp buffer.  */
if (definition
&& Exception_Mechanism == Setjmp_Longjmp
&& get_block_jmpbuf_decl ()
&& DECL_SIZE_UNIT (gnu_decl)
&& (TREE_CODE (DECL_SIZE_UNIT (gnu_decl)) != INTEGER_CST
|| (flag_stack_check == GENERIC_STACK_CHECK
&& compare_tree_int (DECL_SIZE_UNIT (gnu_decl),
 STACK_CHECK_MAX_VAR_SIZE) > 0)))
  add_stmt_with_node (build_call_n_expr
  (update_setjmp_buf_decl, 1,
   build_unary_op (ADDR_EXPR, NULL_TREE,
   get_block_jmpbuf_decl ())),
  gnat_entity);

It is necessary if you want to pass the ACATS testsuite.

But the regular SJLJ scheme (--enable-sjlj-exceptions) doesn't do this update 
and, therefore, doesn't play nice with dynamic stack allocation.  It's a long-
standing issue and you can find messages about it in the archives.  On the 
other hand, this update has always been done for non-local gotos (they also 
use a buffer, the non-local goto save area).

The attached patch implements this update for the regular SJLJ scheme and 
yields a clean ACATS testsuite.  Tested on x86_64-suse-linux with --enable-
sjlj-exceptions, OK for the mainline?


2015-05-13  Eric Botcazou  
Tristan Gingold  

* insn-notes.def (UPDATE_SJLJ_CONTEXT): New note.
* builtins.c (expand_builtin_update_setjmp_buf): Make global.
(expand_stack_restore): Call record_new_stack_level.
(expand_stack_save): Do not call do_pending_stack_adjust.
* builtins.h (expand_builtin_update_setjmp_buf): Declare.
* calls.c (expand_call): Call record_new_stack_level for alloca.
* except.c (sjlj_mark_call_sites): Expand builtin_update_setjmp_buf
wherever a NOTE_INSN_UPDATE_SJLJ_CONTEXT note is present.
(update_sjlj_context): New global function.
* except.h (update_sjlj_context): Declare.
* explow.c (record_new_stack_level): New global function.
(allocate_dynamic_stack_space): Call record_new_stack_level.
* explow.h (record_new_stack_level): Declare.
* final.c (final_scan_insn): Deal with NOTE_INSN_UPDATE_SJLJ_CONTEXT.
* cfgrtl.c (duplicate_insn_chain): Likewise.


-- 
Eric BotcazouIndex: builtins.c
===
--- builtins.c	(revision 222673)
+++ builtins.c	(working copy)
@@ -120,7 +120,6 @@ static int apply_result_size (void);
 #if defined (HAVE_untyped_call) || defined (HAVE_untyped_return)
 static rtx result_vector (int, rtx);
 #endif
-static void expand_builtin_update_setjmp_buf (rtx);
 static void expand_builtin_prefetch (tree);
 static rtx expand_builtin_apply_args (void);
 static rtx expand_builtin_apply_args_1 (void);
@@ -1213,10 +1212,10 @@ expand_builtin_nonlocal_goto (tree exp)
 
 /* __builtin_update_setjmp_buf is passed a pointer to an array of five words
(not all will be used on all machines) that was passed to __builtin_setjmp.
-   It updates the stack pointer in that block to correspond to the current
-   stack pointer.  */
+   It updates the stack pointer in that block to the current value.  This is
+   also called directly by the SJLJ exception handling code.  */
 
-static void
+void
 expand_builtin_update_setjmp_buf (rtx buf_addr)
 {
   machine_mode sa_mode = STACK_SAVEAREA_MODE (SAVE_NONLOCAL);
@@ -5891,10 +5890,12 @@ expand_stack_restore (tree var)
 
   prev = get_last_insn ();
   emit_stack_restore (SAVE_BLOCK, sa);
+
+  record_new_stack_level ();
+
   fixup_args_size_notes (prev, get_last_insn (), 0);
 }
 
-
 /* Emit code to save the current value of stack.  */
 
 static rtx
@@ -5902,7 +5903,6 @@ expand_stack_save (void)
 {
   rtx ret = NULL_RTX;
 
-  do_pending_stack_adjust ();
   emit_stack_save (SAVE_BLOCK, &ret);
   return ret;
 }
Index: final.c
===
--- final.c	(revision 222673)
+++ final.c	(working copy)
@@ -2215,6 +2215,7 @@ final_scan_insn (rtx_insn *insn, FILE *f
   switch (NOTE_KIND (insn))
 	{
 	case NOTE_INSN_DELETED:
+	case NOTE_INSN_UPDATE_SJLJ_CONTEXT:
 	  break;
 
 	case NOTE_INSN_SWITCH_TEXT_SECTIONS:
Index: builtins.h
===

Re: [PATCH] Fix PR66110

[Richard Biener]

On Tue, 12 May 2015, Richard Biener wrote:

> 
> The following patch fixes PR66110 - there is no reason why two alias-sets
> conflict just because one or the other has a child with alias-set zero.
> 
> We need to paper over strict-aliasing bugs in dfp.c (re-using
> struct real_value unsigned long sig[] as decimal128) by adding
> -Wno-strict-aliasing, otherwise bootstrap with -Werror fails.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu (with 
> --disable-werror, now re-trying with just the dfp.c issue workaround).
> 
> I intent to commit this if that succeeds.

This is what I have committed.

Richard.

2015-05-13  Richard Biener  

PR middle-end/66110
* alias.c (alias_sets_conflict_p): Do not treat has_zero_child
specially.
* Makefile.in (dfp.o-warn): Add -Wno-strict-aliasing.

* gcc.dg/alias-2.c: Adjust.
* gcc.dg/tree-ssa/ssa-dse-17.c: New testcase.

Index: gcc/alias.c
===
--- gcc/alias.c (revision 223032)
+++ gcc/alias.c (working copy)
@@ -470,15 +470,13 @@ alias_sets_conflict_p (alias_set_type se
   /* See if the first alias set is a subset of the second.  */
   ase = get_alias_set_entry (set1);
   if (ase != 0
-  && (ase->has_zero_child
- || ase->children->get (set2)))
+  && ase->children->get (set2))
 return 1;
 
   /* Now do the same, but with the alias sets reversed.  */
   ase = get_alias_set_entry (set2);
   if (ase != 0
-  && (ase->has_zero_child
- || ase->children->get (set1)))
+  && ase->children->get (set1))
 return 1;
 
   /* The two alias sets are distinct and neither one is the
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 223032)
+++ gcc/Makefile.in (working copy)
@@ -211,6 +211,7 @@ libgcov-driver-tool.o-warn = -Wno-error
 libgcov-merge-tool.o-warn = -Wno-error
 gimple-match.o-warn = -Wno-unused
 generic-match.o-warn = -Wno-unused
+dfp.o-warn = -Wno-strict-aliasing
 
 # All warnings have to be shut off in stage1 if the compiler used then
 # isn't gcc; configure determines that.  WARN_CFLAGS will be either
Index: gcc/testsuite/gcc.dg/alias-2.c
===
--- gcc/testsuite/gcc.dg/alias-2.c  (revision 223032)
+++ gcc/testsuite/gcc.dg/alias-2.c  (working copy)
@@ -11,6 +11,6 @@ struct foo {
 int
 sub1 (long long int foobar)
 {
-  struct foo *tmp = (struct foo *) &foobar; // { dg-warning "type-punned 
pointer might" "" }
+  struct foo *tmp = (struct foo *) &foobar; // { dg-warning "type-punned 
pointer will" "" }
   return tmp->i;
 }
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-17.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-17.c  (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-17.c  (working copy)
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dse1" } */
+
+struct s1 {
+unsigned short f1;
+unsigned char f2;
+};
+
+struct s2 {
+struct s1 *p1;
+};
+
+void f1(struct s2 *p)
+{
+  p->p1->f2 = 9;
+  p->p1->f2 = 10;
+}
+
+/* { dg-final { scan-tree-dump-times "f2 =" 1 "dse1" } } */
+/* { dg-final { cleanup-tree-dump "dse1" } } */

Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

[Jonathan Wakely]

On 08/05/15 13:43 +0200, Rainer Orth wrote:

Jonathan Wakely  writes:


I've committed the two changes attached (only tested on linux again).

patch2.txt should fix the mingw-w64 errors above, as well as the
issues Daniel reported, and should fix the error on Solaris 10

Rainer, would you be able to test with
--enable-libstdcxx-filesystem-ts before we re-enable it to build by
default on solaris* ?


I just did: a bootstrap on i386-pc-solaris2.10 completed successfully
and the experimental/filesystem tests all PASSed.  Given that Solaris 11
was fine even before, I think it's safe to re-enable it by default on
Solaris again.


Thanks. Re-enabled with this patch, committed to trunk.
commit 38715a0b0a5afcb980570dfb65c591e3a7eb8cb9
Author: Jonathan Wakely 
Date:   Sun May 10 19:46:25 2015 +0100

	* acinclude.m4 (GLIBCXX_ENABLE_FILESYSTEM_TS): Re-enable on solaris.
	* configure: Regenerate.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 07b5bd7..6f67774 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3926,7 +3926,7 @@ AC_DEFUN([GLIBCXX_ENABLE_FILESYSTEM_TS], [
 enable_libstdcxx_filesystem_ts=yes
 ;;
   solaris*)
-enable_libstdcxx_filesystem_ts=no
+enable_libstdcxx_filesystem_ts=yes
 ;;
   *)
 enable_libstdcxx_filesystem_ts=no
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 90a5192..39fc28c 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -79166,7 +79166,7 @@ $as_echo_n "checking whether to build Filesystem TS support... " >&6; }
 enable_libstdcxx_filesystem_ts=yes
 ;;
   solaris*)
-enable_libstdcxx_filesystem_ts=no
+enable_libstdcxx_filesystem_ts=yes
 ;;
   *)
 enable_libstdcxx_filesystem_ts=no

[PATCH] Fix PR66123

[Richard Biener]

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

Richard.

2015-05-13  Richard Biener  

PR tree-optimization/66123
* tree-ssa-dom.c (propagate_rhs_into_lhs): Check if we found
a taken edge.

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

Index: gcc/tree-ssa-dom.c
===
*** gcc/tree-ssa-dom.c  (revision 223044)
--- gcc/tree-ssa-dom.c  (working copy)
*** propagate_rhs_into_lhs (gimple stmt, tre
*** 2918,2923 
--- 2918,2926 
{
  basic_block bb = gimple_bb (use_stmt);
  edge te = find_taken_edge (bb, val);
+ if (!te)
+   continue;
+ 
  edge_iterator ei;
  edge e;
  gimple_stmt_iterator gsi;
Index: gcc/testsuite/gcc.dg/torture/pr66123.c
===
*** gcc/testsuite/gcc.dg/torture/pr66123.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr66123.c  (working copy)
***
*** 0 
--- 1,11 
+ /* { dg-do compile } */
+ 
+ int
+ test (int foo)
+ {
+   static void *dummy[] = { &&a, &&b };
+   goto *((char *) &&b - 2 * (foo < 0));
+ a:
+ b:
+   return 0;
+ }

Re: [PATCH][tree-ssa-math-opts] Expand pow (x, CONST) using square roots when possible

[Richard Biener]

On Fri, May 8, 2015 at 5:09 PM, Kyrill Tkachov
 wrote:
>
> On 08/05/15 14:56, Kyrill Tkachov wrote:
>>
>> On 08/05/15 11:18, Richard Biener wrote:
>>>
>>> On Fri, May 1, 2015 at 6:02 PM, Kyrill Tkachov
>>>  wrote:

 Hi all,

 GCC has some logic to expand calls to pow (x, 0.75), pow (0.25) and pow
 (x,
 (int)k + 0.5)
 using square roots. So, for the above examples it would generate sqrt
 (x) *
 sqrt (sqrt (x)),
 sqrt (sqrt (x)) and powi (x, k) * sqrt (x) (assuming k > 0. For k < 0 it
 will calculate the
 reciprocal of that).

 However, the implementation of these optimisations is done on a bit of
 an
 ad-hoc basis with
 the 0.25, 0.5, 0.75 cases hardcoded.
 Judging by

 https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=meissner2.pdf
 these are the most commonly used exponents (at least in SPEC ;))

 This patch generalises this optimisation into a (hopefully) more robust
 algorithm.
 In particular, it expands calls to pow (x, CST) by expanding the integer
 part of CST
 using a powi, like it does already, and then expanding the fractional
 part
 as a product
 of repeated applications of a square root if the fractional part can be
 expressed
 as a multiple of a power of 0.5.

 I try to explain the algorithm in more detail in the comments in the
 patch
 but, for example:

 pow (x, 5.625) is not currently handled, but with this patch will be
 expanded
 to powi (x, 5) * sqrt (x) * sqrt (sqrt (sqrt (x))) because 5.625 == 5.0
 +
 0.5 + 0.5**3

 Negative exponents are handled in either of two ways, depending on the
 exponent value:
 * Using a simple reciprocal.
 For example:
 pow (x, -5.625) == 1.0 / pow (x, 5.625)
   --> 1.0 / (powi (x, 5) * sqrt (x) * sqrt (sqrt (sqrt (x

 * For pow (x, EXP) with negative exponent EXP with integer part INT and
 fractional part FRAC:
 pow (1.0 - FRAC) / powi (ceil (abs (EXP))).
 For example:
 pow (x, -5.875) == pow (x, 0.125) / powi (X, 6)
   --> sqrt (sqrt (sqrt (x))) / (powi (x, 6))


 Since hardware square root instructions tend to be expensive, we may
 want to
 reduce the number
 of square roots we are willing to calculate. Since we reuse intermediate
 square root results,
 this boils down to restricting the depth of the square root chains. In
 all
 the examples above
 that depth is 3. I've made this maximum depth parametrisable in
 params.def.
 By adjusting that
 parameter we can adjust the resolution of this optimisation. So, if it's
 set
 to '4' then we
 will synthesize every exponent that is a multiple of 0.5**4 == 0.0625,
 including negative
 multiples. Currently, GCC will not try to expand negative multiples of
 anything else than 0.5

 I have tried to keep the existing functionality intact and activate this
 only for
 -funsafe-math-optimizations and only when the target has a sqrt
 instruction.
An exception to that is pow (x, 0.5) which we prefer to transform to
 sqrt
 even
 when a hardware sqrt is not available, presumably because the library
 function for
 sqrt is usually faster than pow (?).
>>>
>>> Yes.  It's also a safe transform - which you seem to put under
>>> flag_unsafe_math_optimizations only with your patch.
>>>
>>> It would be clearer to just leave the special-case
>>>
>>> -  /* Optimize pow(x,0.5) = sqrt(x).  This replacement is always safe
>>> - unless signed zeros must be maintained.  pow(-0,0.5) = +0, while
>>> - sqrt(-0) = -0.  */
>>> -  if (sqrtfn
>>> -  && REAL_VALUES_EQUAL (c, dconsthalf)
>>> -  && !HONOR_SIGNED_ZEROS (mode))
>>> -return build_and_insert_call (gsi, loc, sqrtfn, arg0);
>>>
>>> in as-is.
>>
>> Ok, I'll leave that case explicit.
>>
>>> You also removed the Os constraint which you should put back in.
>>> Basically if !optimize_function_for_speed_p then generate at most
>>> two calls to sqrt (iff the HW has a sqrt instruction).
>>
>> I tried to move that logic into expand_with_sqrts but
>> I'll move it outside it. It seems that this boils down to
>> only 0.25, as any other 2xsqrt chain will also involve a
>> multiply or a divide which we currently avoid.
>>
>>> You fail to add a testcase that checks that the optimization applies.
>>
>> I'll add one to scan the sincos dump.
>> I notice that we don't have a testuite check that the target has
>> a hw sqrt instructions. Would you like me to add one? Or can I make
>> the testcase aarch64-specific?

Would be great to have a testsuite check for this.

>>
>>> Otherwise the idea looks good though there must be a better way
>>> to compute the series than by using real-arithmetic and forcefully
>>> trying out all possibilities...
>>
>> I get that feeling too. What I need is not only a way

[PATCH v2] libiberty: cleanup Makefile.in

[Bernhard Reutner-Fischer]

* configure.ac (TARGETLIB_PIC, TARGETLIB_NOASAN): New variables.
* configure: Regenerate.
* maint-tool: Refactor pic/ and noasan/ handling.
* Makefile.in: Likewise. Regenerate dependencies.

---
The below does the same but attempts to be limited to what POSIX
requires a make(1) to provide. Seems to compile fine with gnu-make and
bmake. Not sure how POSIX compliant the latter is, though, and i don't
have one myself nor plan to get me one anytime soon..

Ok for trunk?
---
 libiberty/Makefile.in  | 2413 +---
 libiberty/configure|8 +
 libiberty/configure.ac |6 +
 libiberty/maint-tool   |   33 +-
 4 files changed, 1491 insertions(+), 969 deletions(-)

diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in
index f06cc69..a134ff0 100644
--- a/libiberty/Makefile.in
+++ b/libiberty/Makefile.in
@@ -68,6 +68,7 @@ MAKEOVERRIDES =
 
 TARGETLIB = ./libiberty.a
 TESTLIB = ./testlib.a
+TARGETLIBS = $(TARGETLIB) @TARGETLIB_PIC@ @TARGETLIB_NOASAN@
 
 LIBOBJS = @LIBOBJS@
 
@@ -75,6 +76,9 @@ LIBOBJS = @LIBOBJS@
 # even if they are in libc. (Perhaps the libc version is buggy.)
 EXTRA_OFILES = 
 
+# build variants of libiberty in separate sub-directories with given flags
+SUB_CFLAGS =
+
 # Flags to pass to a recursive make.
 FLAGS_TO_PASS = \
"AR=$(AR)" \
@@ -102,7 +106,7 @@ FLAGS_TO_PASS = \
 SUBDIRS = testsuite
 
 # FIXME: add @BUILD_INFO@ once we're sure it works for everyone.
-all: stamp-picdir stamp-noasandir $(TARGETLIB) required-list all-subdir
+all: $(TARGETLIBS) required-list all-subdir
@: $(MAKE) ; $(MULTIDO) $(FLAGS_TO_PASS) multi-do DO=all
 
 .PHONY: check installcheck
@@ -113,7 +117,7 @@ installcheck: installcheck-subdir
 
 INCDIR=$(srcdir)/$(MULTISRCTOP)../include
 
-COMPILE.c = $(CC) -c @DEFS@ $(CFLAGS) $(CPPFLAGS) -I. -I$(INCDIR) $(HDEFINES) 
@ac_libiberty_warn_cflags@
+COMPILE.c = $(CC) -c @DEFS@ $(CFLAGS) $(SUB_CFLAGS) $(CPPFLAGS) -I. 
-I$(INCDIR) $(HDEFINES) @ac_libiberty_warn_cflags@
 
 # Just to make sure we don't use a built-in rule with VPATH
 .c.$(objext):
@@ -244,24 +248,24 @@ INSTALLED_HEADERS =   
  \
$(INCDIR)/timeval-utils.h
 
 $(TARGETLIB): $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS)
-   -rm -f $(TARGETLIB) pic/$(TARGETLIB) noasan/$(TARGETLIB)
-   $(AR) $(AR_FLAGS) $(TARGETLIB) \
+   -rm -f $@
+   $(AR) $(AR_FLAGS) $@ \
  $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS)
-   $(RANLIB) $(TARGETLIB)
-   if [ x"$(PICFLAG)" != x ]; then \
- cd pic; \
- $(AR) $(AR_FLAGS) $(TARGETLIB) \
-   $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS); \
- $(RANLIB) $(TARGETLIB); \
- cd ..; \
-   else true; fi; \
-   if [ x"$(NOASANFLAG)" != x ]; then \
- cd noasan; \
- $(AR) $(AR_FLAGS) $(TARGETLIB) \
-   $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS); \
- $(RANLIB) $(TARGETLIB); \
- cd ..; \
-   else true; fi
+   $(RANLIB) $@
+
+TARGETLIB_PIC_OFILES = `echo $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS) | \
+sed -e 's,[^/ ]*/,./pic/,g';`
+./pic/libiberty.a: stamp-pic-ofiles
+   -rm -f $@
+   $(AR) $(AR_FLAGS) $@ $(TARGETLIB_PIC_OFILES)
+   $(RANLIB) $@
+
+TARGETLIB_NOASAN_OFILES =`echo $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS) | 
\
+sed -e 's,[^/ ]*/,./noasan/,g';`
+./noasan/libiberty.a: stamp-noasan-ofiles
+   -rm -f $@
+   $(AR) $(AR_FLAGS) $@ $(TARGETLIB_NOASAN_OFILES)
+   $(RANLIB) $@
 
 $(TESTLIB): $(REQUIRED_OFILES) $(CONFIGURED_OFILES)
-rm -f $(TESTLIB)
@@ -393,17 +397,15 @@ install_to_tooldir: all
 required-list: Makefile
echo $(REQUIRED_OFILES) > required-list
 
-stamp-picdir:
-   if [ x"$(PICFLAG)" != x ] && [ ! -d pic ]; then \
- mkdir pic; \
-   else true; fi
-   touch stamp-picdir
+stamp-pic-ofiles:
+   [ ! -d pic ] && mkdir pic
+   $(MAKE) $(FLAGS_TO_PASS) $(TARGETLIB_PIC_OFILES)
+   touch $@
 
-stamp-noasandir:
-   if [ x"$(NOASANFLAG)" != x ] && [ ! -d noasan ]; then \
- mkdir noasan; \
-   else true; fi
-   touch stamp-noasandir
+stamp-noasan-ofiles:
+   [ ! -d noasan ] && mkdir noasan
+   $(MAKE) $(FLAGS_TO_PASS) $(TARGETLIB_NOASAN_OFILES)
+   touch $@
 
 .PHONY: all etags tags ls clean stage1 stage2
 
@@ -444,7 +446,7 @@ maint-deps :
 mostlyclean: mostlyclean-subdir
-rm -rf *.$(objext) pic noasan core errs \#* *.E a.out
-rm -f errors dummy config.h stamp-*
-   -rm -f $(CONFIG_H) stamp-picdir stamp-noasandir
+   -rm -f $(CONFIG_H)
-rm -f libiberty.aux libiberty.cp libiberty.cps libiberty.fn 
libiberty.ky
-rm -f libiberty.log libiberty.tmp libiberty.tps libiberty.pg
-rm -f libiberty.pgs libiberty.toc libiberty.tp libiberty.tpl 
libiberty.vr
@@ -501,9 +503,6 @@ maintainer-clean-subdir: config.h
  cd $$dir && $(MAKE) $(FLAGS_TO_PASS) $$

Re: [PATCH] combine: Don't create (set (reg:CC) (compare (reg:CC) (const0)))

[Segher Boessenkool]

On Mon, May 11, 2015 at 06:13:40AM -0700, Segher Boessenkool wrote:
>   * combine.c (simplify_set): When generating a CC set, if the
>   source already is in the correct mode, do not wrap it in a
>   compare.  Simplify the rest of that code.

Committed now.


Segher

Re: [PATCH PR65447]Improve IV handling by grouping address type uses with same base and step

[Richard Biener]

On Fri, May 8, 2015 at 12:47 PM, Bin Cheng  wrote:
> Hi,
> GCC's IVO currently handles every IV use independently, which is not right
> by learning from cases reported in PR65447.
>
> The rationale is:
> 1) Lots of address type IVs refer to the same memory object, share similar
> base and have same step.  We should handle these IVs as a group in order to
> maximize CSE opportunities, prefer reg+offset addressing mode.
> 2) GCC's IVO algorithm is expensive and only is run when candidate set is
> small enough.  By grouping same family uses, we can decrease the number of
> both uses and candidates.  Before this patch, number of candidates for
> PR65447 is too big to run expensive IVO algorithm, resulting in bad assembly
> code on targets like AArch64 and Mips.
> 3) Even for cases the assembly code isn't improved, we can still get
> compilation time benefit with this patch.
> 4) This is a prerequisite for enabling auto-increment support in IVO on
> AArch64.
>
> For now, this is only done to address type IVs, in the future I may extend
> it to general IVs too.
>
> For AArch64:
> Benchmarks 470.lbm/spec2k6 and 173.applu/spec2k are improved obviously by
> this patch.  A couple of cases from spec2k/fp appear regressed.  I looked
> into generated assembly code and can confirm the regression is false alarm
> except one case (189.lucas).  For that case, I think it's another issue
> exposed by this patch (GCC failed to CSE candidate setup code, resulting in
> bloated loop header).  Anyway, I also fined tuned the patch to minimize the
> impact.
>
> For AArch32, this patch seems to be able to improve spec2kfp too, but I
> didn't look deep into it.  I guess the reason is it can make life for
> auto-increment support in IVO better.
>
> One of defects of this patch is computation of max offset in
> compute_max_addr_offset is basically borrowed from get_address_cost.  The
> comment says we should find a better way to compute all information.  People
> also complained we need to refactor that part of code.  I don't have good
> solution to that yet, though I did try best to keep compute_max_addr_offset
> simple.
>
> I believe this is a generally wanted change, bootstrap and test on x86_64
> and AArch64, so is it ok?

I'm a little bit worried about the linked list of sub-uses and the "sorting"
(that's quadratic).  A little.  I don't have any good idea but to use a tree...
We don't seem to limit the number of sub-uses (if we'd do that it would
become O(1)).

Similar is searching in the list of uses for a group with same base/step
(but ISTR IVOPTs has multiple similar loops?)

Overall the patch looks like a good improvement to how we do IVO, so I think
it is ok as-is.

Thanks,
Richard.


>
> 2015-05-08  Bin Cheng  
>
> PR tree-optimization/65447
> * tree-ssa-loop-ivopts.c (struct iv_use): New fields.
> (dump_use, dump_uses): Support to dump sub use.
> (record_use): New parameters to support sub use.  Remove call to
> dump_use.
> (record_sub_use, record_group_use): New functions.
> (compute_max_addr_offset, split_all_small_groups): New functions.
> (group_address_uses, rewrite_use_address): New functions.
> (strip_offset): New declaration.
> (find_interesting_uses_address): Call record_group_use.
> (add_candidate): New assertion.
> (infinite_cost_p): Move definition forward.
> (add_costs): Check INFTY cost and return immediately.
> (get_computation_cost_at): Clear setup cost and dependent bitmap
> for sub uses.
> (determine_use_iv_cost_address): Compute cost for sub uses.
> (rewrite_use_address_1): Rename from old rewrite_use_address.
> (free_loop_data): Free sub uses.
> (tree_ssa_iv_optimize_loop): Call group_address_uses.
>
> gcc/testsuite/ChangeLog
> 2015-05-08  Bin Cheng  
>
> PR tree-optimization/65447
> * gcc.dg/tree-ssa/pr65447.c: New test.

[committed] [patch 0/27] Use automake-1.11.6 across the tree

[Michael Haubenwallner]

On 05/05/2015 06:03 PM, Michael Haubenwallner wrote:
> Hello build machinery maintainers,
> 
> following up
> http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462
> http://thread.gmane.org/gmane.comp.gcc.patches/332160
> 
> On 01/25/2015 08:42 PM, Jan-Benedict Glaw wrote:
>> On Sun, 2015-01-04 20:20:40 +0100, Michael Haubenwallner 
>>  wrote:
> 
>>> Updating to 1.14 might require more work like updating some .in
>>> files as well. I've seen automake-1.11 being explicitly used, so for
>>> now we really want 1.11.6 eventually?
>>
>> Probably yes, we may want to stick to a well-known version. (Maybe
>> another way could be to really upgrade to current versions, with is, I
>> guess, more work than just sync files and rerun. That might be
>> fruitful (ie. to not stick to older versions), but this is a change I
>> don't see in the current stage.)
>>
>>   To cut a long story short:
>>
>>   * Do we actually see *problems* from the version inconsistencies
>> already introduced by me and/or others?
> 
> There's a problem for gcc-developers: When I need to import a libtool
> upstream patch, by its nature it affects each library. As I prefer to
> avoid mixing these diffs with an automake version change in one commit,
> I need to bootstrap different libraries with different automake versions.
> 
> Even if I probably need to split this change into one commit per library
> anyway, the need for multiple automake versions still feels pointless.

Using automake-1.11.6 across the tree (except for libgo) is committed.

>>   * ...and: Do we want to stick to known versions, or update if?
>> (Probably not in such a late stage, though...)
> 
> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
> 
> BTW, the actual commands I use to re-run automake for everything (I found) is:

Commands used:

  $ /src/gcc-trunk/configure --prefix=/install \
  --enable-languages=c,c++,fortran,go,java,lto,objc,obj-c++,ada \
  --enable-liboffloadmic=target \
  --enable-libmpx \
  --enable-libada \
  --enable-maintainer-mode 
  $ make bootstrap

Reverted changes to libffi/doc/version.texi (would bump VERSION 3.).

Thanks!
/haubi/

[PATCH] Fix PR66129

[Richard Biener]

The following fixes PR66129.

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

Richard.

2015-05-13  Richard Biener  

PR tree-optimization/66129
* tree-vect-slp.c (vect_build_slp_tree): Make sure all ops are
commutative.
(vect_schedule_slp_instance): Fix typo.

Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c (revision 223119)
--- gcc/tree-vect-slp.c (working copy)
*** vect_build_slp_tree (loop_vec_info loop_
*** 1123,1128 
--- 1123,1129 
  && oprnds_info[1]->first_dt == vect_internal_def
  && is_gimple_assign (stmt)
  && commutative_tree_code (gimple_assign_rhs_code (stmt))
+ && !SLP_TREE_TWO_OPERATORS (*node)
  /* Do so only if the number of not successful permutes was nor more
 than a cut-ff as re-trying the recursive match on
 possibly each level of the tree would expose exponential
*** vect_schedule_slp_instance (slp_tree nod
*** 3459,3465 
  tree *melts = XALLOCAVEC (tree, TYPE_VECTOR_SUBPARTS (vectype));
  for (l = 0; l < TYPE_VECTOR_SUBPARTS (vectype); ++l)
{
! if (k > group_size)
k = 0;
  melts[l] = build_int_cst
  (meltype, mask[k++] * TYPE_VECTOR_SUBPARTS (vectype) + l);
--- 3460,3466 
  tree *melts = XALLOCAVEC (tree, TYPE_VECTOR_SUBPARTS (vectype));
  for (l = 0; l < TYPE_VECTOR_SUBPARTS (vectype); ++l)
{
! if (k >= group_size)
k = 0;
  melts[l] = build_int_cst
  (meltype, mask[k++] * TYPE_VECTOR_SUBPARTS (vectype) + l);

Re: [patch 26/29] libstdc++-v3: Use automake-1.11.6 (across the tree)

[Michael Haubenwallner]

On 05/13/2015 12:27 PM, Jonathan Wakely wrote:
> On 06/05/15 12:21 +0200, Michael Haubenwallner wrote:
>> Patch for libstdc++-v3.
> 
> The libstd++ parts are OK.
> 
> N.B. libstdc++ patches should be sent to the libstdc++ list (which
> saves you CCing individual maintainers.)

Indeed, thanks!

> (Will this change mean I need to have 1.11.1 and 1.11.6 both installed
> and adjust my path depending on whether I'm working on trunk or a 4.x
> branch?)

As long as 4.x stays with 1.11.1, basically yes...
There have been different versions used by different committers already,
which actually brought me to this version sync/bump topic. However, I'm
unsure whether (or how) to ensure automake versions persist in sync.

/haubi/

Re: [patch] Clean up detection of SJLJ exceptions in target libraries

[Matt Breedlove]

This patch fixes an issue preventing mingw-w64 i686 dwarf2-eh
bootstrapping described at:

http://sourceforge.net/p/mingw-w64/mailman/message/34101954/

I'm assuming this has more to do with switching away from the current
sjlj configuration method since configuring gcc with
"--disable-sjlj-exceptions --with-dwarf2" still suffers the same
issues.  Building with simply "--with-dwarf2" instead, however, now
works fine.  I'm not sure whether or not a bug has been created for it
and if one needs to be.

Much appreciated,
Matt

On Wed, May 13, 2015 at 6:36 AM, Jonathan Wakely  wrote:
> On 12/05/15 18:42 +0200, Eric Botcazou wrote:
>>
>> libstdc++-v3/
>> * acinclude.m4 (GLIBCXX_ENABLE_SJLJ_EXCEPTIONS): Delete.
>> * configure.ac: Remove GLIBCXX_ENABLE_SJLJ_EXCEPTIONS.
>> * config.h.in: Regenerate.
>> * configure: Likewise.
>> * libsupc++/eh_personality.cc: Replace _GLIBCXX_SJLJ_EXCEPTIONS by
>> __USING_SJLJ_EXCEPTIONS__.
>> * libsupc++/eh_throw.cc: Likewise.
>> * libsupc++/eh_ptr.cc: Likewise.
>> * doc/html/manual/appendix_porting.html: Remove
>> GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
>> * doc/xml/manual/build_hacking.xml: Likewise.
>> * doc/html/manual/configure.html: Remove --enable-sjlj-exceptions.
>> * doc/xml/manual/configure.xml: Likewise.
>
>
> The libstdc++ parts are OK, thanks.
>

[v3 patch] Implement LWG 2466 (allocator_traits::max_size() is stoopid)

[Jonathan Wakely]

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2466

We agreed to move this to Ready in Lenexa.

I'd like to see max_size() deprecated, it's useless, but if we can't
do that it might as well not give an impossible answer.

Tested powerpc64le-linux, committed to trunk.
commit 00f00caad92cbbc3d8893d5004df1ea2700d67af
Author: Jonathan Wakely 
Date:   Sun May 10 19:50:14 2015 +0100

	* include/bits/alloc_traits.h (_S_max_size): Implement LWG 2466.
	* testsuite/20_util/allocator_traits/members/max_size.cc: Adjust.
	* testsuite/23_containers/forward_list/allocator/minimal.cc:
	Likewise.
	* testsuite/23_containers/map/allocator/minimal.cc: Likewise.
	* testsuite/23_containers/multimap/allocator/minimal.cc: Likewise.
	* testsuite/23_containers/multiset/allocator/minimal.cc: Likewise.
	* testsuite/23_containers/set/allocator/minimal.cc: Likewise.
	* testsuite/23_containers/unordered_map/allocator/minimal.cc:
	Likewise.
	* testsuite/23_containers/unordered_multimap/allocator/minimal.cc:
	Likewise.
	* testsuite/23_containers/unordered_multiset/allocator/minimal.cc:
	Likewise.
	* testsuite/23_containers/unordered_set/allocator/minimal.cc:
	Likewise.
	* testsuite/util/testsuite_allocator.h: Remove unused parameter.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h b/libstdc++-v3/include/bits/alloc_traits.h
index 12c6c12..e434261 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -315,7 +315,12 @@ _GLIBCXX_ALLOC_TR_NESTED_TYPE(propagate_on_container_swap,
 	   typename = _Require<__not_<__has_max_size<_Alloc2
 	static size_type
 	_S_max_size(_Alloc2&, ...)
-	{ return __gnu_cxx::__numeric_traits::__max; }
+	{
+	  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+	  // 2466. allocator_traits::max_size() default behavior is incorrect
+	  return __gnu_cxx::__numeric_traits::__max
+	/ sizeof(value_type);
+	}
 
   template
 	struct __select_helper
diff --git a/libstdc++-v3/testsuite/20_util/allocator_traits/members/max_size.cc b/libstdc++-v3/testsuite/20_util/allocator_traits/members/max_size.cc
index 2678646..862ff4a 100644
--- a/libstdc++-v3/testsuite/20_util/allocator_traits/members/max_size.cc
+++ b/libstdc++-v3/testsuite/20_util/allocator_traits/members/max_size.cc
@@ -57,11 +57,22 @@ void test02()
   typedef std::allocator_traits> traits_type;
   traits_type::allocator_type a;
   auto size = std::numeric_limits::max();
-  VERIFY( traits_type::max_size(a) == size );
+  VERIFY( traits_type::max_size(a) == size / sizeof(X) );
+}
+
+void test03()
+{
+  bool test __attribute__((unused)) = true;
+
+  typedef std::allocator_traits> traits_type;
+  traits_type::allocator_type a;
+  auto size = std::numeric_limits::max();
+  VERIFY( traits_type::max_size(a) == size / sizeof(int) );
 }
 
 int main()
 {
   test01();
   test02();
+  test03();
 }
diff --git a/libstdc++-v3/testsuite/23_containers/forward_list/allocator/minimal.cc b/libstdc++-v3/testsuite/23_containers/forward_list/allocator/minimal.cc
index 514489b..a6b3ce2 100644
--- a/libstdc++-v3/testsuite/23_containers/forward_list/allocator/minimal.cc
+++ b/libstdc++-v3/testsuite/23_containers/forward_list/allocator/minimal.cc
@@ -38,7 +38,7 @@ void test01()
   typedef std::forward_list test_type;
   test_type v(alloc_type{});
   v.push_front(T());
-  VERIFY( v.max_size() == traits_type::max_size(v.get_allocator()) );
+  VERIFY( v.max_size() < traits_type::max_size(v.get_allocator()) );
 }
 
 int main()
diff --git a/libstdc++-v3/testsuite/23_containers/map/allocator/minimal.cc b/libstdc++-v3/testsuite/23_containers/map/allocator/minimal.cc
index bde6256..3351f70 100644
--- a/libstdc++-v3/testsuite/23_containers/map/allocator/minimal.cc
+++ b/libstdc++-v3/testsuite/23_containers/map/allocator/minimal.cc
@@ -42,7 +42,7 @@ void test01()
   typedef std::map test_type;
   test_type v(alloc_type{});
   v = { test_type::value_type{} };
-  VERIFY( v.max_size() == traits_type::max_size(v.get_allocator()) );
+  VERIFY( v.max_size() < traits_type::max_size(v.get_allocator()) );
 }
 
 int main()
diff --git a/libstdc++-v3/testsuite/23_containers/multimap/allocator/minimal.cc b/libstdc++-v3/testsuite/23_containers/multimap/allocator/minimal.cc
index 433bcec..1ac1213 100644
--- a/libstdc++-v3/testsuite/23_containers/multimap/allocator/minimal.cc
+++ b/libstdc++-v3/testsuite/23_containers/multimap/allocator/minimal.cc
@@ -42,7 +42,7 @@ void test01()
   typedef std::multimap test_type;
   test_type v(alloc_type{});
   v = { test_type::value_type{} };
-  VERIFY( v.max_size() == traits_type::max_size(v.get_allocator()) );
+  VERIFY( v.max_size() < traits_type::max_size(v.get_allocator()) );
 }
 
 int main()
diff --git a/libstdc++-v3/testsuite/23_containers/multiset/allocator/minimal.cc b/libstdc++-v3/testsuite/23_containers/multiset/allocator/minimal.cc
index 8d1b0ad..b8ccb64 100644
--- a/libstdc++-v3/testsuite/23_containers/multiset/allocator/minimal.cc
+++ b/

[patch] LWG 2440 std::seed_seq::size() should be noexcept

[Jonathan Wakely]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2440

This was resolved as a defect and voted into the working paper in
Lenexa. As an extension we can also make the default constructor
noexcept.

Tested powerpc64le-linux, committed to trunk.
commit 1629bfd40e615b5130d72d9759ca82cfca8f74d2
Author: Jonathan Wakely 
Date:   Wed May 13 13:13:37 2015 +0100

	* include/bits/random.h (seed_seq): More noexcept (LWG 2440).

diff --git a/libstdc++-v3/include/bits/random.h b/libstdc++-v3/include/bits/random.h
index 501243d..5905e60 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -6023,13 +6023,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*/
   class seed_seq
   {
-
   public:
 /** The type of the seed vales. */
 typedef uint_least32_t result_type;
 
 /** Default constructor. */
-seed_seq()
+seed_seq() noexcept
 : _M_v()
 { }
 
@@ -6045,7 +6044,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   generate(_RandomAccessIterator __begin, _RandomAccessIterator __end);
 
 // property functions
-size_t size() const
+size_t size() const noexcept
 { return _M_v.size(); }
 
 template
@@ -6058,7 +6057,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 seed_seq& operator=(const seed_seq&) = delete;
 
   private:
-///
 std::vector _M_v;
   };
 

Re: Work around PR65873

[Richard Biener]

On Wed, May 13, 2015 at 12:12 AM, Jan Hubicka  wrote:
>
> Hi,
> this patch works around PR where we refuse to inline always_inline memcpy
> into function with explicit Ofast optimization attribute.  This is because
> we think we can not promote -fno-fast-math code to -fast-math code.
> This is of course safe for memcpy because it contains to fast-math code,
> but we don't really do the analysis for each of the flags we check.
>
> Earlier compilers was happily producing wrong code here and it seems practical
> to do that on GCC 5 to deal with common falout.  I will implement the more
> fine grained check incrementally.
>
> Bootstrapped/regtested x86_64-linux. Will commit it to mainline shortly and
> to release branch later this week.

Hmm, the changelog or the description above doesn't cover the

@@ -481,6 +490,17 @@ can_inline_edge_p (struct cgraph_edge *e
  e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
  inlinable = false;
}
+  /* If explicit optimize attribute are not used, the mismatch is caused
+by different command line options used to build different units.
+Do not care about COMDAT functions - those are intended to be
+ optimized with the optimization flags of module they are used in.
+Also do not care about mixing up size/speed optimization when
+DECL_DISREGARD_INLINE_LIMITS is set.  */
+  else if ((callee->merged
+   && !lookup_attribute ("optimize",
+ DECL_ATTRIBUTES (caller->decl)))
+  || DECL_DISREGARD_INLINE_LIMITS (callee->decl))
+   ;
   /* If mismatch is caused by merging two LTO units with different
 optimizationflags we want to be bit nicer.  However never inline
 if one of functions is not optimized at all.  */

hunk.

> PR ipa/65873
> * ipa-inline.c (can_inline_edge_p): Allow early inlining of always
> inlines across optimization boundary.
> * testsuite/gcc.c-torture/compile/pr65873.c: New testcase.
> Index: ipa-inline.c
> ===
> --- ipa-inline.c(revision 223093)
> +++ ipa-inline.c(working copy)
> @@ -427,46 +427,55 @@ can_inline_edge_p (struct cgraph_edge *e
>   && lookup_attribute ("always_inline",
>DECL_ATTRIBUTES (callee->decl)));
>
> + /* Until GCC 4.9 we did not check the semantics alterning flags
> +   bellow and inline across optimization boundry.
> +   Enabling checks bellow breaks several packages by refusing
> +   to inline library always_inline functions. See PR65873.
> +   Disable the check for early inlining for now until better solution
> +   is found.  */
> + if (always_inline && early)
> +   ;
>/* There are some options that change IL semantics which means
>   we cannot inline in these cases for correctness reason.
>  Not even for always_inline declared functions.  */
>/* Strictly speaking only when the callee contains signed integer
>   math where overflow is undefined.  */
> -  if ((check_maybe_up (flag_strict_overflow)
> -  /* this flag is set by optimize.  Allow inlining across
> - optimize boundary.  */
> -  && (!opt_for_fn (caller->decl, optimize)
> -  == !opt_for_fn (callee->decl, optimize) || !always_inline))
> - || check_match (flag_wrapv)
> - || check_match (flag_trapv)
> - /* Strictly speaking only when the callee uses FP math.  */
> - || check_maybe_up (flag_rounding_math)
> - || check_maybe_up (flag_trapping_math)
> - || check_maybe_down (flag_unsafe_math_optimizations)
> - || check_maybe_down (flag_finite_math_only)
> - || check_maybe_up (flag_signaling_nans)
> - || check_maybe_down (flag_cx_limited_range)
> - || check_maybe_up (flag_signed_zeros)
> - || check_maybe_down (flag_associative_math)
> - || check_maybe_down (flag_reciprocal_math)
> - /* We do not want to make code compiled with exceptions to be 
> brought
> -into a non-EH function unless we know that the callee does not
> -throw.  This is tracked by DECL_FUNCTION_PERSONALITY.  */
> - || (check_match (flag_non_call_exceptions)
> - /* TODO: We also may allow bringing !flag_non_call_exceptions
> -to flag_non_call_exceptions function, but that may need
> -extra work in tree-inline to add the extra EH edges.  */
> - && (!opt_for_fn (callee->decl, flag_non_call_exceptions)
> - || DECL_FUNCTION_PERSONALITY (callee->decl)))
> - || (check_maybe_up (flag_exceptions)
> - && DECL_FUNCTION_PERSONALITY (callee->decl))
> - /* Strictly speaking only when the callee contains function
> -calls that may end up setting errno.  */
> - || chec

[patch] LWG 2418 make std:experimental::apply() work with pointers to member

[Jonathan Wakely]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2418

This was voted into the TS in Lenexa.

Tested powerpc64le-linux, committed to trunk.

commit ef712e821bc683fe3979251dcc09786bee0233e0
Author: Jonathan Wakely 
Date:   Wed May 13 13:37:05 2015 +0100

	* include/experimental/tuple (apply): Handle pointers to member (LWG
	2418).
	* include/std/functional (_Mem_fn_base): Make constructors constexpr.
	(_Maybe_wrap_member_pointer::__do_wrap): Make constexpr.
	* testsuite/experimental/tuple/apply.cc: Test pointer to member.

diff --git a/libstdc++-v3/include/experimental/tuple b/libstdc++-v3/include/experimental/tuple
index 4baede4..aa25c57 100644
--- a/libstdc++-v3/include/experimental/tuple
+++ b/libstdc++-v3/include/experimental/tuple
@@ -36,6 +36,7 @@
 #else
 
 #include 
+#include 
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -54,7 +55,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template 
 constexpr decltype(auto)
 __apply_impl(_Fn&& f, _Tuple&& t, std::index_sequence<_Idx...>)
-{ return std::forward<_Fn>(f)(get<_Idx>(forward<_Tuple>(t))...); }
+{
+  using _Wrap = _Maybe_wrap_member_pointer>;
+  return _Wrap::__do_wrap(std::forward<_Fn>(f))(
+	  get<_Idx>(forward<_Tuple>(t))...);
+}
 
   template 
 constexpr decltype(auto)
diff --git a/libstdc++-v3/include/std/functional b/libstdc++-v3/include/std/functional
index 946cf63..7dd149a 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -572,7 +572,7 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
 public:
   using result_type = typename _Traits::__result_type;
 
-  explicit _Mem_fn_base(_Pmf __pmf) : _M_pmf(__pmf) { }
+  explicit constexpr _Mem_fn_base(_Pmf __pmf) : _M_pmf(__pmf) { }
 
   // Handle objects
   template(__x); }
 };
@@ -1021,7 +1021,7 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
 {
   typedef _Mem_fn<_Tp _Class::*> type;
 
-  static type
+  static constexpr type
   __do_wrap(_Tp _Class::* __pm)
   { return type(__pm); }
 };
diff --git a/libstdc++-v3/testsuite/experimental/tuple/apply.cc b/libstdc++-v3/testsuite/experimental/tuple/apply.cc
index 88e174d..e52962b 100644
--- a/libstdc++-v3/testsuite/experimental/tuple/apply.cc
+++ b/libstdc++-v3/testsuite/experimental/tuple/apply.cc
@@ -41,9 +41,23 @@ test02()
   VERIFY( i == 3 );
 }
 
+struct F
+{
+  int f(int i, int j) const { return i + j; }
+};
+
+void
+test03()
+{
+  auto t = std::make_tuple(F{}, 1, 2);
+  int r = std::experimental::apply(&F::f, t);
+  VERIFY( r == 3 );
+}
+
 int
 main()
 {
   test01();
   test02();
+  test03();
 }

[patch] std::polar requires non-negative rho

[Jonathan Wakely]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2459

Voted into the WP in Lenexa.

Tested powerpc64le-linux, comitted to trunk.
commit 9bf3b9ea20334711ecdced656323f69959521a82
Author: Jonathan Wakely 
Date:   Wed May 13 14:18:03 2015 +0100

	* include/std/complex (polar): Check for negative rho (LWG 2459).

diff --git a/libstdc++-v3/include/std/complex b/libstdc++-v3/include/std/complex
index 585683c..f2a6cf9 100644
--- a/libstdc++-v3/include/std/complex
+++ b/libstdc++-v3/include/std/complex
@@ -667,7 +667,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 inline complex<_Tp>
 polar(const _Tp& __rho, const _Tp& __theta)
-{ return complex<_Tp>(__rho * cos(__theta), __rho * sin(__theta)); }
+{
+  _GLIBCXX_DEBUG_ASSERT( __rho >= 0 );
+  return complex<_Tp>(__rho * cos(__theta), __rho * sin(__theta));
+}
 
   template
 inline complex<_Tp>

[patch] Make std::string default constructor conditionally noexcept

[Jonathan Wakely]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2455

Voted into the WP in Lenexa.

We already did the right thing for vector, so only basic_string needs
to change.

Tested powerpc64le-linux, committed to trunk.
commit 634ed6e2d2ea4d69a29a8907044e6f68541d88aa
Author: Jonathan Wakely 
Date:   Wed May 13 14:21:37 2015 +0100

	* include/bits/basic_string.h (basic_string::basic_string()): Make
	noexcept conditional on allocator (LWG 2455).

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index 3e3eef4..093f502 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -377,7 +377,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   /**
*  @brief  Default constructor creates an empty string.
*/
-  basic_string() _GLIBCXX_NOEXCEPT
+  basic_string()
+#if __cplusplus >= 201103L
+  noexcept(is_nothrow_default_constructible<_Alloc>::value)
+#endif
   : _M_dataplus(_M_local_data())
   { _M_set_length(0); }
 

[PATCH] Don't fold away division by zero (PR middle-end/66127)

[Marek Polacek]

As discussed in the PR, match.pd happily folds 0 * whatever into 0.  That
is undesirable from the C/C++ FE POV, since it can make us accept invalid
initializers.

So fixed in match.pd -- I'd hope there's a better way to do this, but this
seems to work.  There was some fallout, but nothing unexpected or surprising.

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

2015-05-13  Marek Polacek  

PR middle-end/66127
* match.pd (0 * X): Preserve divisions by zero.

* g++.dg/warn/overflow-warn-1.C: Adjust dg-warning and dg-error.
* g++.dg/warn/overflow-warn-3.C: Likewise.
* g++.dg/warn/overflow-warn-4.C: Likewise.
* g++.dg/ubsan/div-by-zero-1.C: Likewise.

diff --git gcc/match.pd gcc/match.pd
index 51a950a..510e2db 100644
--- gcc/match.pd
+++ gcc/match.pd
@@ -78,7 +78,19 @@ along with GCC; see the file COPYING3.  If not see
 
 (simplify
  (mult @0 integer_zerop@1)
- @1)
+ /* Make sure to preserve divisions by zero.  */
+ (with { enum tree_code code = TREE_CODE (@0); }
+  (if ((code != TRUNC_DIV_EXPR
+   && code != EXACT_DIV_EXPR
+   && code != ROUND_DIV_EXPR
+   && code != FLOOR_DIV_EXPR
+   && code != CEIL_DIV_EXPR
+   && code != TRUNC_MOD_EXPR
+   && code != CEIL_MOD_EXPR
+   && code != FLOOR_MOD_EXPR
+   && code != ROUND_MOD_EXPR)
+   || !integer_zerop (TREE_OPERAND (@0, 1)))
+ @1)))
 
 /* Maybe fold x * 0 to 0.  The expressions aren't the same
when x is NaN, since x * 0 is also NaN.  Nor are they the
--- gcc/testsuite/g++.dg/warn/overflow-warn-1.C
+++ gcc/testsuite/g++.dg/warn/overflow-warn-1.C
@@ -17,7 +17,7 @@ enum e {
   /* But as in DR#031, the 1/0 in an evaluated subexpression means the
  whole expression violates the constraints.  */
   E4 = 0 * (1 / 0), /* { dg-warning "division by zero" } */
-  /* { dg-error "enumerator value for 'E4' is not an integer constant" "enum 
error" { xfail *-*-* } 19 } */
+  /* { dg-error "enumerator value for 'E4' is not an integer constant|not a 
constant.expression" "enum error" { target *-*-* } 19 } */
   E5 = INT_MAX + 1, /* { dg-warning "integer overflow in expression" } */
   /* { dg-warning "overflow in constant expression" "constant" { target *-*-* 
} 21 } */
   /* Again, overflow in evaluated subexpression.  */
@@ -30,8 +30,9 @@ enum e {
 struct s {
   int a;
   int : 0 * (1 / 0); /* { dg-warning "division by zero" } */
+  /* { dg-error "not an integer constant|not a constant.expression" "bit-field 
error" { target *-*-* } 32 } */
   int : 0 * (INT_MAX + 1); /* { dg-warning "integer overflow in expression" } 
*/
-  /* { dg-warning "overflow in constant expression" "constant" { target *-*-* 
} 33 } */
+  /* { dg-warning "overflow in constant expression" "constant" { target *-*-* 
} 34 } */
 };
 
 void
@@ -45,7 +46,6 @@ f (void)
 /* This expression is neither required to be constant.  */
 static int sc = INT_MAX + 1; /* { dg-warning "integer overflow in expression" 
} */
 
-
 // Test for overflow in null pointer constant.  
 void *n = 0;
 /* The first two of these involve overflow, so are not null pointer
@@ -54,7 +54,7 @@ void *n = 0;
 void *p = 0 * (INT_MAX + 1); /* { dg-warning "integer overflow in expression" 
} */
 /* { dg-warning "invalid conversion from 'int' to 'void" "null" { target *-*-* 
} 54 } */
 void *q = 0 * (1 / 0); /* { dg-warning "division by zero" } */
-/* { dg-error "invalid conversion from 'int' to 'void*'" "null" { xfail *-*-* 
} 56 } */
+/* { dg-warning "invalid conversion from 'int' to 'void\\*'" "null" { target 
*-*-* } 56 } */
 void *r = (1 ? 0 : INT_MAX+1); /* { dg-bogus "integer overflow in expression" 
"" { xfail *-*-* } } */
 
 void
@@ -63,9 +63,10 @@ g (int i)
   switch (i)
 {
 case 0 * (1/0): /* { dg-warning "division by zero" } */
+  /* { dg-error "not a constant.expression" "case error" { target *-*-* } 
65 } */
   ;
 case 1 + 0 * (INT_MAX + 1): /* { dg-warning "integer overflow in 
expression" } */
-  /* { dg-warning "overflow in constant expression" "constant" { target 
*-*-* } 67 } */
+  /* { dg-warning "overflow in constant expression" "constant" { target 
*-*-* } 68 } */
   ;
 }
 }
--- gcc/testsuite/g++.dg/warn/overflow-warn-3.C
+++ gcc/testsuite/g++.dg/warn/overflow-warn-3.C
@@ -17,7 +17,7 @@ enum e {
   /* But as in DR#031, the 1/0 in an evaluated subexpression means the
  whole expression violates the constraints.  */
   E4 = 0 * (1 / 0), /* { dg-warning "division by zero" } */
-  /* { dg-error "enumerator value for 'E4' is not an integer constant" "enum 
error" { xfail *-*-* } 19 } */
+  /* { dg-error "enumerator value for 'E4' is not an integer constant|not a 
constant.expression" "enum error" { target *-*-* } 19 } */
   E5 = INT_MAX + 1, /* { dg-warning "integer overflow in expression" } */
   /* { dg-warning "overflow in constant expression" "constant" { target *-*-* 
} 21 } */
   /* Again, overflow in evaluated subexpression.  */
@@ -30,8 +30,9 @@ enum e {
 struct s {
   int a;
   int

Re: [patch] std::polar requires non-negative rho

[Daniel Krügler]

2015-05-13 15:32 GMT+02:00 Jonathan Wakely :
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2459
>
> Voted into the WP in Lenexa.
>
> Tested powerpc64le-linux, comitted to trunk.

What about assertions regarding non-NAN rho and finite theta, as
decided for by the LWG 2439?

- Daniel

[C PATCH] Fold C_MAYBE_CONST_EXPRs with C_MAYBE_CONST_EXPR_INT_OPERANDS set (PR c/66066)

[Marek Polacek]

The following is an attempt to implement what Joseph outlined here:
.  This
patch relies on the match.pd I've just posted.  It shouldn't reduce
e.g. division by zero to pedwarn-if-pedantic (the tests test that).
But e.g. enum { A = 1 << -5 }; is already pedwarns-if-pedantic, and
this patch doesn't change that.
(It's especially important that this patch doesn't regress any of
overflow-warn-?.c tests.)

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

2015-05-13  Marek Polacek  

PR c/66066
* c-common.c (c_fully_fold_internal): Fold C_MAYBE_CONST_EXPRs with
C_MAYBE_CONST_EXPR_INT_OPERANDS set.

* c-typeck.c (digest_init): Call pedwarn_init with OPT_Wpedantic
rather than with 0.

* gcc.dg/pr19984.c: Add -Wpedantic.
* gcc.dg/pr14649-1.c: Likewise.
* gcc.dg/pr66066-1.c: New test.
* gcc.dg/pr66066-2.c: New test.
* gcc.dg/pr66066-3.c: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 7e5ac72..24200f0 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1209,7 +1209,11 @@ c_fully_fold_internal (tree expr, bool in_init, bool 
*maybe_const_operands,
   if (C_MAYBE_CONST_EXPR_NON_CONST (expr))
*maybe_const_operands = false;
   if (C_MAYBE_CONST_EXPR_INT_OPERANDS (expr))
-   *maybe_const_itself = false;
+   {
+ *maybe_const_itself = false;
+ inner = c_fully_fold_internal (inner, in_init, maybe_const_operands,
+maybe_const_itself);
+   }
   if (pre && !in_init)
ret = build2 (COMPOUND_EXPR, TREE_TYPE (expr), pre, inner);
   else
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 3fcb7c2..9b883a2 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -6864,7 +6864,7 @@ digest_init (location_t init_loc, tree type, tree init, 
tree origtype,
  inside_init = error_mark_node;
}
   else if (require_constant && !maybe_const)
-   pedwarn_init (init_loc, 0,
+   pedwarn_init (init_loc, OPT_Wpedantic,
  "initializer element is not a constant expression");
 
   /* Added to enable additional -Wsuggest-attribute=format warnings.  */
diff --git gcc/testsuite/gcc.dg/pr14649-1.c gcc/testsuite/gcc.dg/pr14649-1.c
index 34f42f0..b9fc4b9 100644
--- gcc/testsuite/gcc.dg/pr14649-1.c
+++ gcc/testsuite/gcc.dg/pr14649-1.c
@@ -1,6 +1,6 @@
 /* PR c/14649 */
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -Wpedantic" } */
 
 double atan(double);
 
diff --git gcc/testsuite/gcc.dg/pr19984.c gcc/testsuite/gcc.dg/pr19984.c
index 5323c46..a628e0e 100644
--- gcc/testsuite/gcc.dg/pr19984.c
+++ gcc/testsuite/gcc.dg/pr19984.c
@@ -1,6 +1,6 @@
 /* PR c/19984 */
 /* { dg-do compile } */
-/* { dg-options "-O2 -std=c99" } */
+/* { dg-options "-O2 -std=c99 -Wpedantic" } */
 
 
 double nan (const char *);
diff --git gcc/testsuite/gcc.dg/pr66066-1.c gcc/testsuite/gcc.dg/pr66066-1.c
index e69de29..7a1d342 100644
--- gcc/testsuite/gcc.dg/pr66066-1.c
+++ gcc/testsuite/gcc.dg/pr66066-1.c
@@ -0,0 +1,37 @@
+/* PR c/66066 */
+/* { dg-do compile } */
+/* { dg-options "-Wno-div-by-zero" } */
+
+/* Accept these unless -pedantic-errors/-Werror.  */
+int a1 = -1 << 0;
+int a2 = -1 << 0 | 0;
+int a3 = -1 << 0 & 1;
+int a4 = -1 << 2 ^ 1;
+int a5 = 4 & -1 << 2;
+int a6 = (-1 << 2) ^ (1 >> 1);
+int a7 = 0 || (-1 << 1);
+int a8 = 0 ? 2 : (-1 << 1);
+int a9 = 1 && -1 << 0;
+int a10 = !(-1 << 0);
+
+/* Don't accept these.  */
+int b1 = 1 / 0;/* { dg-error "initializer element is not 
constant" } */
+int b2 = 1 / (1 / 0);  /* { dg-error "initializer element is not constant" } */
+int b3 = 0 ? 2 : 1 / 0;/* { dg-error "initializer element is not 
constant" } */
+int b4 = 0 || 1 / 0;   /* { dg-error "initializer element is not constant" } */
+int b5 = 0 * (1 / 0);  /* { dg-error "initializer element is not constant" } */
+int b6 = 1 * (1 / 0);  /* { dg-error "initializer element is not constant" } */
+int b7 = (1 / 0) * 0;  /* { dg-error "initializer element is not constant" } */
+int b8 = (1 / 0) * 1;  /* { dg-error "initializer element is not constant" } */
+int b9 = 1 && 1 / 0;   /* { dg-error "initializer element is not constant" } */
+int b10 = !(1 / 0);/* { dg-error "initializer element is not constant" } */
+int c1 = 1 % 0;/* { dg-error "initializer element is not 
constant" } */
+int c2 = 1 / (1 % 0);  /* { dg-error "initializer element is not constant" } */
+int c3 = 0 ? 2 : 1 % 0;/* { dg-error "initializer element is not 
constant" } */
+int c4 = 0 || 1 % 0;   /* { dg-error "initializer element is not constant" } */
+int c5 = 0 * (1 % 0);  /* { dg-error "initializer element is not constant" } */
+int c6 = 1 * (1 % 0);  /* { dg-error "initializer element is not constant" } */
+int c7 = (1 % 0) * 0;  /* { dg-error "initializer element is not constant" } */
+int c8 = (1 % 0) *

[patch] std::packaged_task(allocator_arg_t, const A&, F&&) should not be explicit

[Jonathan Wakely]

http://wiki.edg.com/twiki/pub/Wg21lenexa/StrawPolls/N4525.html#2407

Voted into the WP in Lenexa.

Tested powerpc64le-linux, committed to trunk.
commit f58bb7ab1b098d525359869767286f9c8955acd3
Author: Jonathan Wakely 
Date:   Wed May 13 14:39:24 2015 +0100

	* include/std/future (packaged_task(allocator_arg_t, const A&, F&&):
	Remove explicit (LWG 2407).

diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future
index a67db98..c4baf90 100644
--- a/libstdc++-v3/include/std/future
+++ b/libstdc++-v3/include/std/future
@@ -1489,9 +1489,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
   // 2097.  packaged_task constructors should be constrained
+  // 2407. [this constructor should not be] explicit
   template::__type>
-	explicit
 	packaged_task(allocator_arg_t, const _Alloc& __a, _Fn&& __fn)
 	: _M_state(__create_task_state<_Res(_ArgTypes...)>(
 		std::forward<_Fn>(__fn), __a))

Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Jakub Jelinek]

On Wed, May 13, 2015 at 03:41:11PM +0200, Marek Polacek wrote:
> As discussed in the PR, match.pd happily folds 0 * whatever into 0.  That
> is undesirable from the C/C++ FE POV, since it can make us accept invalid
> initializers.
> 
> So fixed in match.pd -- I'd hope there's a better way to do this, but this
> seems to work.  There was some fallout, but nothing unexpected or surprising.

Will it handle cases 0 * (int) (1 / 0) etc., when perhaps the division by
zero isn't immediately the operand of mult, but somewhere deeper?
Also, can't the divisor be optimized into 0 only later on, so your code
would still see !integer_zerop there and fold into 0?
Perhaps the answer is that in both cases we'd have simplified those already
into a division by zero.

Jakub

[patch] Add std::raw_storage_iterator::base() member

[Jonathan Wakely]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2454

Voted into the WP in Lenexa.

Tested powerpc64le-linux, committed to trunk.
commit 8cb30e1ad50f1bb277c635d83796c64772b61d68
Author: redi 
Date:   Wed May 13 13:54:46 2015 +

	* include/bits/stl_raw_storage_iter.h (raw_storage_iterator::base()):
	Define (LWG 2454).
	* testsuite/20_util/raw_storage_iterator/base.cc: New.

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

diff --git a/libstdc++-v3/include/bits/stl_raw_storage_iter.h b/libstdc++-v3/include/bits/stl_raw_storage_iter.h
index 2ce83ff..fc9019c 100644
--- a/libstdc++-v3/include/bits/stl_raw_storage_iter.h
+++ b/libstdc++-v3/include/bits/stl_raw_storage_iter.h
@@ -100,6 +100,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	++_M_iter;
 	return __tmp;
   }
+
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2454. Add raw_storage_iterator::base() member
+  _OutputIterator base() const { return _M_iter; }
 };
 
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/testsuite/20_util/raw_storage_iterator/base.cc b/libstdc++-v3/testsuite/20_util/raw_storage_iterator/base.cc
new file mode 100644
index 000..f6429bd
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/raw_storage_iterator/base.cc
@@ -0,0 +1,36 @@
+// Copyright (C) 2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+
+#include 
+#include 
+
+void
+test01()
+{
+  int a[2];
+  auto it = std::raw_storage_iterator(a);
+  VERIFY( it.base() == a );
+  VERIFY( (++it).base() == a+1 );
+}
+
+int
+main()
+{
+  test01();
+}

Re: [patch] std::polar requires non-negative rho

[Jonathan Wakely]

On 13/05/15 15:36 +0200, Daniel Krügler wrote:

2015-05-13 15:32 GMT+02:00 Jonathan Wakely :

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2459

Voted into the WP in Lenexa.

Tested powerpc64le-linux, comitted to trunk.


What about assertions regarding non-NAN rho and finite theta, as
decided for by the LWG 2439?


I don't know how to reliably test those conditions. What if _Tp is not
a floating-point type?

The assertion I added addresses the original issue as reported
numerous times to libc++. I don't really care if it doesn't deal with
the additional preconditions added in Cologne, as users don't seem to
expect a meaningful answer for NaNs and infinities.

Re: [PATCH 3/4] libcpp/input.c: Add a way to visualize the linemaps

[David Malcolm]

On Mon, 2015-05-04 at 13:19 -0600, Jeff Law wrote:
> On 05/01/2015 06:56 PM, David Malcolm wrote:
> > As a relative newcomer to GCC, one of the issues I had was
> > becoming comfortable with the linemap API and its internal
> > representation.
> >
> > To familiarize myself with it, I wrote a dumping routine
> > to try to visualize how the source_location space is carved
> > up between line maps, and what each number can mean.
> >
> > It struck me that this would benefit others, so this patch
> > adds this visualization, via an undocumented option
> > -fdump-locations, and adds a text file to libcpp's sources
> > documenting a simple example of compiling a small C file,
> > with a header and macro expansions (built using the
> > -fdump-locations option and a little hand-editing).
> >
> > gcc/ChangeLog:
> > * common.opt (fdump-locations): New option.
> > * input.c: Include diagnostic-core.h.
> > (get_end_location): New function.
> > (write_digit): New function.
> > (write_digit_row): New function.
> > (dump_location_range): New function.
> > (dump_labelled_location_range): New function.
> > (dump_location_info): New function.
> > * input.h (dump_location_info): New prototype.
> > * toplev.c (compile_file): Handle flag_dump_locations.
> >
> > libcpp/ChangeLog:
> > * include/line-map.h (source_location): Add a reference to
> > location-example.txt to the descriptive comment.
> > * location-example.txt: New file.
> Maybe "dump-internal-locations"?  Not sure I want to bikeshed on the 
> name any more than that.   If you feel strongly about the option name, 
> then I won't stress about it.
> 
> 
> 
> > +void
> > +dump_location_info (FILE *stream)
> > +{
> > +  if (0)
> > +line_table_dump (stream,
> > +line_table,
> > +LINEMAPS_ORDINARY_USED (line_table),
> > +LINEMAPS_MACRO_USED (line_table));
> Should the if (0) code go away?
> 
> > +
> > +  /* A brute-force visualization: emit a warning at every location.  */
> > +  if (0)
> > +for (source_location loc = 0; loc < line_table->highest_location; 
> > loc++)
> > +  warning_at (loc, 0, "this is location %i", loc);
> > +  /* Alternatively, we could use inform (), though this
> > +also shows lots of locations in stdc-predef.h */
> And again.
> 
> 
> So I think with removing the if (0) code and the possible option name 
> change this is good to go.

Thanks.  I removed the if (0) code and renamed it to
-fdump-internal-locations.

Bootstrapped®rtested on x86_64-unknown-linux-gnu (Fedora 20).

Committed to trunk as r223163 (attached).

Index: gcc/input.c
===
--- gcc/input.c	(revision 223162)
+++ gcc/input.c	(revision 223163)
@@ -23,6 +23,7 @@
 #include "intl.h"
 #include "input.h"
 #include "vec.h"
+#include "diagnostic-core.h"
 
 /* This is a cache used by get_next_line to store the content of a
file to be searched for file lines.  */
@@ -869,3 +870,226 @@
STAT_LABEL (total_used_map_size));
   fprintf (stderr, "\n");
 }
+
+/* Get location one beyond the final location in ordinary map IDX.  */
+
+static source_location
+get_end_location (struct line_maps *set, unsigned int idx)
+{
+  if (idx == LINEMAPS_ORDINARY_USED (set) - 1)
+return set->highest_location;
+
+  struct line_map *next_map = LINEMAPS_ORDINARY_MAP_AT (set, idx + 1);
+  return MAP_START_LOCATION (next_map);
+}
+
+/* Helper function for write_digit_row.  */
+
+static void
+write_digit (FILE *stream, int digit)
+{
+  fputc ('0' + (digit % 10), stream);
+}
+
+/* Helper function for dump_location_info.
+   Write a row of numbers to STREAM, numbering a source line,
+   giving the units, tens, hundreds etc of the column number.  */
+
+static void
+write_digit_row (FILE *stream, int indent,
+		 source_location loc, int max_col, int divisor)
+{
+  fprintf (stream, "%*c", indent, ' ');
+  fprintf (stream, "|");
+  for (int column = 1; column < max_col; column++)
+{
+  source_location column_loc = loc + column;
+  write_digit (stream, column_loc / divisor);
+}
+  fprintf (stream, "\n");
+}
+
+/* Write a half-closed (START) / half-open (END) interval of
+   source_location to STREAM.  */
+
+static void
+dump_location_range (FILE *stream,
+		 source_location start, source_location end)
+{
+  fprintf (stream,
+	   "  source_location interval: %u <= loc < %u\n",
+	   start, end);
+}
+
+/* Write a labelled description of a half-closed (START) / half-open (END)
+   interval of source_location to STREAM.  */
+
+static void
+dump_labelled_location_range (FILE *stream,
+			  const char *name,
+			  source_location start, source_location end)
+{
+  fprintf (stream, "%s\n", name);
+  dump_location_range (stream, start, end);
+  fprintf (stream, "\n");
+}
+
+/* Write a visualization of the locations in the line_table to STREAM.  */
+
+void
+dump_location_info (FILE *stream)
+{
+  /* Visualize the reser

Re: [patch] std::polar requires non-negative rho

[Marc Glisse]

On Wed, 13 May 2015, Daniel Krügler wrote:


2015-05-13 15:32 GMT+02:00 Jonathan Wakely :

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2459

Voted into the WP in Lenexa.

Tested powerpc64le-linux, comitted to trunk.


What about assertions regarding non-NAN rho and finite theta, as
decided for by the LWG 2439?


non-NAN rho is already covered by rho >= 0.

--
Marc Glisse

Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Marek Polacek]

On Wed, May 13, 2015 at 03:55:10PM +0200, Jakub Jelinek wrote:
> On Wed, May 13, 2015 at 03:41:11PM +0200, Marek Polacek wrote:
> > As discussed in the PR, match.pd happily folds 0 * whatever into 0.  That
> > is undesirable from the C/C++ FE POV, since it can make us accept invalid
> > initializers.
> > 
> > So fixed in match.pd -- I'd hope there's a better way to do this, but this
> > seems to work.  There was some fallout, but nothing unexpected or 
> > surprising.
> 
> Will it handle cases 0 * (int) (1 / 0) etc., when perhaps the division by
> zero isn't immediately the operand of mult, but somewhere deeper?

It won't handle e.g. 0 * (unsigned) (1 / 0).

> Also, can't the divisor be optimized into 0 only later on, so your code
> would still see !integer_zerop there and fold into 0?
> Perhaps the answer is that in both cases we'd have simplified those already
> into a division by zero.

Yes, it's a dumb attempt.

I don't know how to reliably fix this :(.  We really want 
...

Marek

RFA: RL78: Place zero-initialised data into the .bss section

[Nick Clifton]

Hi DJ,

  Currently the RL78 port does not place zero-initialised data in the
  .bss section.  This is because of the rl78_select_section() function
  which does not handle bss data.  The patch below updates the function
  to handle that and other types of data so that they end up in the
  expected sections.

  Tested with no regressions on an rl8-elf toolchain.

  OK to apply ?

Cheers
  Nick

gcc/ChangeLog
2015-05-13  Nick Clifton  

* config/rl78/rl78.c (rl78_select_section): Select the correct
default section based upon the category of the decl.

Index: gcc/config/rl78/rl78.c
===
--- gcc/config/rl78/rl78.c  (revision 223119)
+++ gcc/config/rl78/rl78.c  (working copy)
@@ -4383,8 +4383,8 @@
 
 static section *
 rl78_select_section (tree decl,
-int reloc ATTRIBUTE_UNUSED,
-unsigned HOST_WIDE_INT align ATTRIBUTE_UNUSED)
+int reloc,
+unsigned HOST_WIDE_INT align)
 {
   int readonly = 1;
 
@@ -4428,7 +4428,30 @@
   if (readonly)
 return readonly_data_section;
 
-  return data_section;
+  switch (categorize_decl_for_section (decl, reloc))
+{
+case SECCAT_TEXT:   return text_section;
+case SECCAT_DATA:   return data_section;
+case SECCAT_BSS:return bss_section;
+case SECCAT_RODATA: return readonly_data_section;
+
+case SECCAT_RODATA_MERGE_STR:
+case SECCAT_RODATA_MERGE_STR_INIT:
+case SECCAT_RODATA_MERGE_CONST:
+case SECCAT_SRODATA:
+case SECCAT_DATA_REL:
+case SECCAT_DATA_REL_LOCAL:
+case SECCAT_DATA_REL_RO:
+case SECCAT_DATA_REL_RO_LOCAL:
+case SECCAT_SDATA:
+case SECCAT_SBSS:
+case SECCAT_TDATA:
+case SECCAT_TBSS:
+  return default_select_section (decl, reloc, align);
+
+default:
+  gcc_unreachable ();
+}
 }
 
 void

Re: Work around PR65873

[Jan Hubicka]

> On Wed, May 13, 2015 at 12:12 AM, Jan Hubicka  wrote:
> >
> > Hi,
> > this patch works around PR where we refuse to inline always_inline memcpy
> > into function with explicit Ofast optimization attribute.  This is because
> > we think we can not promote -fno-fast-math code to -fast-math code.
> > This is of course safe for memcpy because it contains to fast-math code,
> > but we don't really do the analysis for each of the flags we check.
> >
> > Earlier compilers was happily producing wrong code here and it seems 
> > practical
> > to do that on GCC 5 to deal with common falout.  I will implement the more
> > fine grained check incrementally.
> >
> > Bootstrapped/regtested x86_64-linux. Will commit it to mainline shortly and
> > to release branch later this week.
> 
> Hmm, the changelog or the description above doesn't cover the
> 
> @@ -481,6 +490,17 @@ can_inline_edge_p (struct cgraph_edge *e
>   e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
>   inlinable = false;
> }
> +  /* If explicit optimize attribute are not used, the mismatch is caused
> +by different command line options used to build different units.
> +Do not care about COMDAT functions - those are intended to be
> + optimized with the optimization flags of module they are used in.
> +Also do not care about mixing up size/speed optimization when
> +DECL_DISREGARD_INLINE_LIMITS is set.  */
> +  else if ((callee->merged
> +   && !lookup_attribute ("optimize",
> + DECL_ATTRIBUTES (caller->decl)))
> +  || DECL_DISREGARD_INLINE_LIMITS (callee->decl))
> +   ;
>/* If mismatch is caused by merging two LTO units with different
>  optimizationflags we want to be bit nicer.  However never inline
>  if one of functions is not optimized at all.  */
> 
> hunk.

Ah, sorry. The change was intended, but I forgot to write about it.
Yep, as comment says this makes us a bit more relaxed about inlining COMDATs
when the prevailing variant is -Os and caller body is -O3 or vice versa.

Honza
> 
> > PR ipa/65873
> > * ipa-inline.c (can_inline_edge_p): Allow early inlining of always
> > inlines across optimization boundary.
> > * testsuite/gcc.c-torture/compile/pr65873.c: New testcase.
> > Index: ipa-inline.c
> > ===
> > --- ipa-inline.c(revision 223093)
> > +++ ipa-inline.c(working copy)
> > @@ -427,46 +427,55 @@ can_inline_edge_p (struct cgraph_edge *e
> >   && lookup_attribute ("always_inline",
> >DECL_ATTRIBUTES (callee->decl)));
> >
> > + /* Until GCC 4.9 we did not check the semantics alterning flags
> > +   bellow and inline across optimization boundry.
> > +   Enabling checks bellow breaks several packages by refusing
> > +   to inline library always_inline functions. See PR65873.
> > +   Disable the check for early inlining for now until better solution
> > +   is found.  */
> > + if (always_inline && early)
> > +   ;
> >/* There are some options that change IL semantics which means
> >   we cannot inline in these cases for correctness reason.
> >  Not even for always_inline declared functions.  */
> >/* Strictly speaking only when the callee contains signed integer
> >   math where overflow is undefined.  */
> > -  if ((check_maybe_up (flag_strict_overflow)
> > -  /* this flag is set by optimize.  Allow inlining across
> > - optimize boundary.  */
> > -  && (!opt_for_fn (caller->decl, optimize)
> > -  == !opt_for_fn (callee->decl, optimize) || !always_inline))
> > - || check_match (flag_wrapv)
> > - || check_match (flag_trapv)
> > - /* Strictly speaking only when the callee uses FP math.  */
> > - || check_maybe_up (flag_rounding_math)
> > - || check_maybe_up (flag_trapping_math)
> > - || check_maybe_down (flag_unsafe_math_optimizations)
> > - || check_maybe_down (flag_finite_math_only)
> > - || check_maybe_up (flag_signaling_nans)
> > - || check_maybe_down (flag_cx_limited_range)
> > - || check_maybe_up (flag_signed_zeros)
> > - || check_maybe_down (flag_associative_math)
> > - || check_maybe_down (flag_reciprocal_math)
> > - /* We do not want to make code compiled with exceptions to be 
> > brought
> > -into a non-EH function unless we know that the callee does not
> > -throw.  This is tracked by DECL_FUNCTION_PERSONALITY.  */
> > - || (check_match (flag_non_call_exceptions)
> > - /* TODO: We also may allow bringing !flag_non_call_exceptions
> > -to flag_non_call_exceptions function, but that may need
> > -extra work in tree-inline to add the extra E

Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Marek Polacek]

On Wed, May 13, 2015 at 04:11:15PM +0200, Marek Polacek wrote:
> I don't know how to reliably fix this :(.

Except disabling (0 * X) -> 0 completely, that is.

Marek

Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Richard Biener]

On Wed, 13 May 2015, Marek Polacek wrote:

> On Wed, May 13, 2015 at 03:55:10PM +0200, Jakub Jelinek wrote:
> > On Wed, May 13, 2015 at 03:41:11PM +0200, Marek Polacek wrote:
> > > As discussed in the PR, match.pd happily folds 0 * whatever into 0.  That
> > > is undesirable from the C/C++ FE POV, since it can make us accept invalid
> > > initializers.
> > > 
> > > So fixed in match.pd -- I'd hope there's a better way to do this, but this
> > > seems to work.  There was some fallout, but nothing unexpected or 
> > > surprising.
> > 
> > Will it handle cases 0 * (int) (1 / 0) etc., when perhaps the division by
> > zero isn't immediately the operand of mult, but somewhere deeper?
> 
> It won't handle e.g. 0 * (unsigned) (1 / 0).
> 
> > Also, can't the divisor be optimized into 0 only later on, so your code
> > would still see !integer_zerop there and fold into 0?
> > Perhaps the answer is that in both cases we'd have simplified those already
> > into a division by zero.
> 
> Yes, it's a dumb attempt.
> 
> I don't know how to reliably fix this :(.  We really want 
> ...

Yeah, I think we can't reliably "avoid" folding away traps like this
so any attempt is useless (and we should simply not do this).

The only way I see is to make all expressions that might trap set
TREE_SIDE_EFFECTS on the expression, so we'd fold it to
a, 0.

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

Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Richard Biener]

On Wed, 13 May 2015, Marek Polacek wrote:

> On Wed, May 13, 2015 at 04:11:15PM +0200, Marek Polacek wrote:
> > I don't know how to reliably fix this :(.
> 
> Except disabling (0 * X) -> 0 completely, that is.

Well, make sure that X has TREE_SIDE_EFFECTS set.  That way we'd fold
to 0, X.

Richard.

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

Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Joseph Myers]

On Wed, 13 May 2015, Marek Polacek wrote:

> On Wed, May 13, 2015 at 03:55:10PM +0200, Jakub Jelinek wrote:
> > On Wed, May 13, 2015 at 03:41:11PM +0200, Marek Polacek wrote:
> > > As discussed in the PR, match.pd happily folds 0 * whatever into 0.  That
> > > is undesirable from the C/C++ FE POV, since it can make us accept invalid
> > > initializers.
> > > 
> > > So fixed in match.pd -- I'd hope there's a better way to do this, but this
> > > seems to work.  There was some fallout, but nothing unexpected or 
> > > surprising.
> > 
> > Will it handle cases 0 * (int) (1 / 0) etc., when perhaps the division by
> > zero isn't immediately the operand of mult, but somewhere deeper?
> 
> It won't handle e.g. 0 * (unsigned) (1 / 0).

I think this illustrates why handling this in the folding-for-optimization 
is a mistake.

For optimization, it's perfectly fine to fold away 0 * (something without 
side effects), and division by 0 should only be considered to have side 
effects if language semantic options were specified to that effect (such 
as using ubsan), which should then have the effect of producing GENERIC 
that's not a simple division but represents whatever checks are required.

Rather, how about having an extra argument to c_fully_fold_internal (e.g. 
for_int_const) indicating that the folding is of an expression with 
integer constant operands (so this argument would be true in the new case 
of folding the contents of a C_MAYBE_CONST_EXPR with 
C_MAYBE_CONST_EXPR_INT_OPERANDS set)?  In that special case, 
c_fully_fold_internal would only fold the expression itself if all 
evaluated operands folded to INTEGER_CSTs (so if something that doesn't 
get folded, such as division by 0, is encountered, then all evaluated 
expressions containing it also don't get folded).

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

[PATCH, alpha]: Some further HWI == 64 improvements

[Uros Bizjak]

Hello!

2015-05-13  Uros Bizjak  

* config/alpha/alpha.c (alpha_emit_set_long_const): Remove c1 argument.
(alpha_extract_integer): Redeclare as static HOST_WIDE_INT.
Remove *p0 and *p1 arguments.  Rewrite function.
(alpha_legitimate_constant_p): Update call to alpha_extract_integer.
(alpha_split_const_mov): Update calls to alpha_extract_integer and
alpha_emit_set_long_const.
(alpha_expand_epilogue): Update calls to alpha_emit_set_long_const.
(alpha_output_mi_thunk_osf): Ditto.
* config/alpha/alpha.md (movti): Do not check operands[1]
for CONST_DOUBLE.

Tested on alpha-linux-gnu and committed to mainline SVN.

Uros.
Index: config/alpha/alpha.c
===
--- config/alpha/alpha.c(revision 223097)
+++ config/alpha/alpha.c(working copy)
@@ -2068,13 +2068,12 @@ alpha_emit_set_const (rtx target, machine_mode mod
with alpha_emit_set_const.  */
 
 static rtx
-alpha_emit_set_long_const (rtx target, HOST_WIDE_INT c1, HOST_WIDE_INT c2)
+alpha_emit_set_long_const (rtx target, HOST_WIDE_INT c1)
 {
   HOST_WIDE_INT d1, d2, d3, d4;
 
   /* Decompose the entire word */
 
-  gcc_assert (c2 == -(c1 < 0));
   d1 = ((c1 & 0x) ^ 0x8000) - 0x8000;
   c1 -= d1;
   d2 = ((c1 & 0x) ^ 0x8000) - 0x8000;
@@ -2109,25 +2108,23 @@ static rtx
 /* Given an integral CONST_INT, CONST_WIDE_INT, CONST_DOUBLE,
or CONST_VECTOR, return the low 64 bits.  */
 
-static void
-alpha_extract_integer (rtx x, HOST_WIDE_INT *p0, HOST_WIDE_INT *p1)
+static HOST_WIDE_INT
+alpha_extract_integer (rtx x)
 {
-  HOST_WIDE_INT i0, i1;
-
   if (GET_CODE (x) == CONST_VECTOR)
 x = simplify_subreg (DImode, x, GET_MODE (x), 0);
 
-  if (CONST_INT_P (x))
-i0 = INTVAL (x);
-  else if (CONST_WIDE_INT_P (x))
-i0 = CONST_WIDE_INT_ELT (x, 0);
-  else
-i0 = CONST_DOUBLE_LOW (x);
-
-  i1 = -(i0 < 0);
-  
-  *p0 = i0;
-  *p1 = i1;
+  switch (GET_CODE (x))
+{
+case CONST_INT:
+  return INTVAL (x);
+case CONST_WIDE_INT:
+  return CONST_WIDE_INT_ELT (x, 0);
+case CONST_DOUBLE:
+  return CONST_DOUBLE_LOW (x);
+default:
+  gcc_unreachable ();
+}
 }
 
 /* Implement TARGET_LEGITIMATE_CONSTANT_P.  This is all constants for which
@@ -2138,7 +2135,7 @@ static rtx
 bool
 alpha_legitimate_constant_p (machine_mode mode, rtx x)
 {
-  HOST_WIDE_INT i0, i1;
+  HOST_WIDE_INT i0;
 
   switch (GET_CODE (x))
 {
@@ -2185,7 +2182,7 @@ alpha_legitimate_constant_p (machine_mode mode, rt
 do_integer:
   if (TARGET_BUILD_CONSTANTS)
return true;
-  alpha_extract_integer (x, &i0, &i1);
+  i0 = alpha_extract_integer (x);
   return alpha_emit_set_const_1 (x, mode, i0, 3, true) != NULL;
 
 default:
@@ -2199,15 +2196,15 @@ alpha_legitimate_constant_p (machine_mode mode, rt
 bool
 alpha_split_const_mov (machine_mode mode, rtx *operands)
 {
-  HOST_WIDE_INT i0, i1;
+  HOST_WIDE_INT i0;
   rtx temp = NULL_RTX;
 
-  alpha_extract_integer (operands[1], &i0, &i1);
+  i0 = alpha_extract_integer (operands[1]);
 
   temp = alpha_emit_set_const (operands[0], mode, i0, 3, false);
 
   if (!temp && TARGET_BUILD_CONSTANTS)
-temp = alpha_emit_set_long_const (operands[0], i0, i1);
+temp = alpha_emit_set_long_const (operands[0], i0);
 
   if (temp)
 {
@@ -8260,8 +8257,7 @@ alpha_expand_epilogue (void)
{
  /* We can't drop new things to memory this late, afaik,
 so build it up by pieces.  */
- sp_adj2 = alpha_emit_set_long_const (tmp, frame_size,
-  -(frame_size < 0));
+ sp_adj2 = alpha_emit_set_long_const (tmp, frame_size);
  gcc_assert (sp_adj2);
}
}
@@ -8388,8 +8384,7 @@ alpha_output_mi_thunk_osf (FILE *file, tree thunk_
 }
   else
 {
-  rtx tmp = alpha_emit_set_long_const (gen_rtx_REG (Pmode, 0),
-  delta, -(delta < 0));
+  rtx tmp = alpha_emit_set_long_const (gen_rtx_REG (Pmode, 0), delta);
   emit_insn (gen_adddi3 (this_rtx, this_rtx, tmp));
 }
 
@@ -8411,7 +8406,7 @@ alpha_output_mi_thunk_osf (FILE *file, tree thunk_
   else
{
  tmp2 = alpha_emit_set_long_const (gen_rtx_REG (Pmode, 1),
-   vcall_offset, -(vcall_offset < 0));
+   vcall_offset);
   emit_insn (gen_adddi3 (tmp, tmp, tmp2));
  lo = 0;
}
Index: config/alpha/alpha.md
===
--- config/alpha/alpha.md   (revision 223097)
+++ config/alpha/alpha.md   (working copy)
@@ -4154,8 +4154,7 @@
  32-bit constants in TImode and rely on the splitter, but
  this doesn't seem to be worth the pain.  */
   else if (CONST_INT_P (operands[1])
-  || GET_CODE (operands[1]) == CONST_WIDE_INT
-  || GET_CODE (operands[1

[PATCH] Avoid unnecessary work when -Wmisleading-indentation isn't enabled

[David Malcolm]

This might qualify as "obvious".

OK for trunk?  (if it passes bootstrap and regrtest)

gcc/c-family/ChangeLog:
* c-indentation.c (warn_for_misleading_indentation): Bail out
immediately if -Wmisleading-indentation isn't enabled.
---
 gcc/c-family/c-indentation.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c
index 94565f6..9aeebae 100644
--- a/gcc/c-family/c-indentation.c
+++ b/gcc/c-family/c-indentation.c
@@ -373,6 +373,12 @@ warn_for_misleading_indentation (location_t guard_loc,
 enum cpp_ttype next_tok_type,
 const char *guard_kind)
 {
+  /* Early reject for the case where -Wmisleading-indentation is disabled,
+ to avoid doing work only to have the warning suppressed inside the
+ diagnostic machinery.  */
+  if (!warn_misleading_indentation)
+return;
+
   if (should_warn_for_misleading_indentation (guard_loc,
  body_loc,
  next_stmt_loc,
-- 
1.8.5.3

Re: [PATCH] Avoid unnecessary work when -Wmisleading-indentation isn't enabled

[Marek Polacek]

On Wed, May 13, 2015 at 11:25:56AM -0400, David Malcolm wrote:
> This might qualify as "obvious".
> 
> OK for trunk?  (if it passes bootstrap and regrtest)

Ok.

Marek

Re: [PATCH][tree-ssa-math-opts] Expand pow (x, CONST) using square roots when possible

[Kyrill Tkachov]

Hi Richard,

On 13/05/15 12:27, Richard Biener wrote:

I notice that we don't have a testuite check that the target has
>>a hw sqrt instructions. Would you like me to add one? Or can I make
>>the testcase aarch64-specific?

Would be great to have a testsuite check for this.



I've committed the patch with r223167.

The attached patch adds a testsuite check for hardware sqrt instructions.
In this version I've included arm (on the condition that vfp is possible),
aarch64, x86_64 and powerpc with vsx.
Is this definition ok?

I'm particularly not familiar with the powerpc architectures.

With this check in place, I've migrated the pow synthesis test from 
gcc.target/aarch64 to gcc.dg.

This test passes on arm-none-eabi, aarch64-none-elf and x86_64-linux.

Ok?

2015-05-13  Kyrylo Tkachov  

* lib/target-supports.exp (check_effective_target_hw_sqrt): New check.
* gcc.dg/pow-sqrt-synth-1.c: New test.
* gcc.target/aarch64/pow-sqrt-synth-1.c: Delete.
commit e30889fa7024ccfd47731aafbaf2288646b65504
Author: Kyrylo Tkachov 
Date:   Wed May 13 16:08:03 2015 +0100

Add testsuite check for hw sqrt. Add generic test for pow sqrt synthesis

diff --git a/gcc/testsuite/gcc.dg/pow-sqrt-synth-1.c b/gcc/testsuite/gcc.dg/pow-sqrt-synth-1.c
new file mode 100644
index 000..a65efeb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pow-sqrt-synth-1.c
@@ -0,0 +1,38 @@
+/* { dg-do compile { target hw_sqrt } } */
+/* { dg-options "-fdump-tree-sincos -Ofast --param max-pow-sqrt-depth=8" } */
+/* { dg-additional-options "-mfloat-abi=softfp -mfpu=neon-vfpv4" { target arm*-*-* } } */
+
+double
+foo (double a)
+{
+  return __builtin_pow (a, -5.875);
+}
+
+double
+foof (double a)
+{
+  return __builtin_pow (a, 0.75f);
+}
+
+double
+bar (double a)
+{
+  return __builtin_pow (a, 1.0 + 0.00390625);
+}
+
+double
+baz (double a)
+{
+  return __builtin_pow (a, -1.25) + __builtin_pow (a, 5.75) - __builtin_pow (a, 3.375);
+}
+
+#define N 256
+void
+vecfoo (double *a)
+{
+  for (int i = 0; i < N; i++)
+a[i] = __builtin_pow (a[i], 1.25);
+}
+
+/* { dg-final { scan-tree-dump-times "synthesizing" 7 "sincos" } } */
+/* { dg-final { cleanup-tree-dump "sincos" } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/pow-sqrt-synth-1.c b/gcc/testsuite/gcc.target/aarch64/pow-sqrt-synth-1.c
deleted file mode 100644
index 52514fb..000
--- a/gcc/testsuite/gcc.target/aarch64/pow-sqrt-synth-1.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-fdump-tree-sincos -Ofast --param max-pow-sqrt-depth=8" } */
-
-
-double
-foo (double a)
-{
-  return __builtin_pow (a, -5.875);
-}
-
-double
-foof (double a)
-{
-  return __builtin_pow (a, 0.75f);
-}
-
-double
-bar (double a)
-{
-  return __builtin_pow (a, 1.0 + 0.00390625);
-}
-
-double
-baz (double a)
-{
-  return __builtin_pow (a, -1.25) + __builtin_pow (a, 5.75) - __builtin_pow (a, 3.375);
-}
-
-#define N 256
-void
-vecfoo (double *a)
-{
-  for (int i = 0; i < N; i++)
-a[i] = __builtin_pow (a[i], 1.25);
-}
-
-/* { dg-final { scan-tree-dump-times "synthesizing" 7 "sincos" } } */
-/* { dg-final { cleanup-tree-dump "sincos" } } */
\ No newline at end of file
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 3728927..c8f20a4 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4668,6 +4668,27 @@ proc check_effective_target_vect_call_copysignf { } {
 return $et_vect_call_copysignf_saved
 }
 
+# Return 1 if the target supports hardware square root instructions.
+
+proc check_effective_target_hw_sqrt { } {
+global et_hw_sqrt_saved
+
+if [info exists et_hw_sqrt_saved] {
+	verbose "check_effective_target_hw_sqrt: using cached result" 2
+} else {
+	set et_hw_sqrt_saved 0
+	if { [istarget x86_64-*-*]
+	 || ([istarget powerpc*-*-*] && [check_vsx_hw_available])
+	 || [istarget aarch64*-*-*]
+	 || ([istarget arm*-*-*] && [check_effective_target_arm_vfp_ok]) } {
+	   set et_hw_sqrt_saved 1
+	}
+}
+
+verbose "check_effective_target_hw_sqrt: returning et_hw_sqrt_saved" 2
+return $et_hw_sqrt_saved
+}
+
 # Return 1 if the target supports vector sqrtf calls.
 
 proc check_effective_target_vect_call_sqrtf { } {

Re: [PATCH, ARM, doc] add missing -mtune options

[Ramana Radhakrishnan]

On 07/05/15 23:12, Jim Wilson wrote:

I noticed that the list of -mtune options in the arm-cores.def file
didn't match the list in the doc/invoke.texi file.  There are 3 cores
missing: generic-armv7-a, cortex-a17, and cortex-a17.cortex-a7.  This
patch adds the missing cores to the docs.

Jim



This is OK thanks.


regards
Ramana

Re: [patch] Clean up detection of SJLJ exceptions in target libraries

[Eric Botcazou]

> This patch fixes an issue preventing mingw-w64 i686 dwarf2-eh
> bootstrapping described at:
> 
> http://sourceforge.net/p/mingw-w64/mailman/message/34101954/
> 
> I'm assuming this has more to do with switching away from the current
> sjlj configuration method since configuring gcc with
> "--disable-sjlj-exceptions --with-dwarf2" still suffers the same
> issues.  Building with simply "--with-dwarf2" instead, however, now
> works fine.  I'm not sure whether or not a bug has been created for it
> and if one needs to be.

Yes, if it makes any difference for a --with-dwarf2 bootstrap, this means that 
gcc and libgcc had different views of the EH scheme of the compiler.

The --disable-sjlj-exceptions breakage is worth investigating separately, so 
please create a PR with Bugzilla (https://gcc.gnu.org/bugzilla) for it.

-- 
Eric Botcazou

Re: [patch] Clean up detection of SJLJ exceptions in target libraries

[Ian Lance Taylor]

On Tue, May 12, 2015 at 9:42 AM, Eric Botcazou  wrote:
>
> 6 target libraries in the tree detect whether they are being compiled by a
> compiler configured for setjmp/longjmp exceptions: libada, libgcc, libgo,
> libjava, libobjc and libstdc++.  They can be divided into 3 categories:
>  1) libada only checks the preprocessor macro __USING_SJLJ_EXCEPTIONS__,
>  2) libgcc and libgo both check the preprocessor macro and implement a
> configure check that defines another macro (LIBGCC_SJLJ_EXCEPTIONS and
> LIBGO_SJLJ_EXCEPTIONS resp) so they'd better agree.
>  3) libjava, libobjc and libstdc++ implement a configure check that defines a
> macro (SJLJ_EXCEPTIONS, SJLJ_EXCEPTIONS and _GLIBCXX_SJLJ_EXCEPTIONS resp).
>
> The attached patch gets rid of the library-specific macros and replaces them
> with __USING_SJLJ_EXCEPTIONS__.  Moreover, it adds a config/sjlj.m4 fragment
> that defines GCC_CHECK_SJLJ_EXCEPTIONS for libraries that need to detect the
> exception model in the configure phase (libgcc and libjava only).
>
> Tested on x86_64-suse-linux with --enable-sjlj-exceptions.  The results are
> not clean (except for objc and obj-c++) but sufficient to see that exceptions
> still work after the patch.  OK for the mainline?

The libgo parts are fine, but since libgo is mirrored from an external
repository I'll commit those parts myself.

I assume I can go ahead and commit them now?  There is no reason to
wait for the rest of the patch, is there?

Ian

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

[Ramana Radhakrishnan]

On 12/05/15 14:01, Martin Galvan wrote:

On Tue, May 12, 2015 at 5:49 AM, Ramana Radhakrishnan
 wrote:

That's what I mean when I say email clients "munged it" : email clients and
/ or some popular email servers appear to end up munging white spaces and
patches don't apply cleanly.

So, no it doesn't work - once you've sent it through your email client /
server. I am unable to apply the patch as it stands today either taking the
raw text from the gcc-patches archive or from your email message in my
inbox. It's not like line endings and things have been munged but every
whitespace / tab is in trouble here.

Please send it back as an attachment if you want me to apply it.


Oh, I see! Sorry for that, I thought the problem was on my side.
Here's the patch, it's the cfi.patch file.




I'm not sure what's going on here and couldn't figure out what was going 
wrong in the 20 minutes I spent on it just now.


Applying the patch downloaded from 2 different inboxes still gives me 
the same result.


$> patch -p1 --dry-run < /work/cfi.patch
checking file libgcc/config/arm/ieee754-df.S
Hunk #2 FAILED at 57.
Hunk #3 succeeded at 70 with fuzz 2.
Hunk #4 FAILED at 86.
Hunk #5 FAILED at 153.
Hunk #6 FAILED at 418.
Hunk #7 FAILED at 425.
Hunk #8 FAILED at 440.
Hunk #9 FAILED at 462.
Hunk #10 FAILED at 485.
Hunk #11 FAILED at 555.
Hunk #12 FAILED at 566.
Hunk #13 FAILED at 601.
Hunk #14 FAILED at 653.
Hunk #15 FAILED at 720.
Hunk #16 FAILED at 868.
Hunk #17 FAILED at 1057.
Hunk #18 FAILED at 1068.
Hunk #19 FAILED at 1082.
Hunk #20 FAILED at 1090.
Hunk #21 FAILED at 1122.
Hunk #22 FAILED at 1133.
Hunk #23 succeeded at 1145 with fuzz 2.
Hunk #24 FAILED at 1155.
Hunk #25 FAILED at 1168.
Hunk #26 FAILED at 1228.
Hunk #27 succeeded at 1236 with fuzz 2.
Hunk #28 FAILED at 1254.
Hunk #29 succeeded at 1263 with fuzz 2.
Hunk #30 FAILED at 1297.
Hunk #31 succeeded at 1306 with fuzz 2.
Hunk #32 FAILED at 1336.
Hunk #33 succeeded at 1345 with fuzz 2.
Hunk #34 FAILED at 1410.
27 out of 34 hunks FAILED
checking file libgcc/config/arm/ieee754-sf.S
Hunk #1 FAILED at 31.
Hunk #2 succeeded at 49 with fuzz 2.
Hunk #3 FAILED at 285.
Hunk #4 FAILED at 293.
Hunk #5 FAILED at 317.
Hunk #6 succeeded at 324 with fuzz 2.
Hunk #7 FAILED at 411.
Hunk #8 succeeded at 422 with fuzz 2.
Hunk #9 FAILED at 457.
Hunk #10 FAILED at 468.
Hunk #11 FAILED at 621.
Hunk #12 FAILED at 761.
Hunk #13 FAILED at 785.
Hunk #14 FAILED at 799.
Hunk #15 FAILED at 807.
Hunk #16 FAILED at 826.
Hunk #17 FAILED at 835.
Hunk #18 succeeded at 847 with fuzz 2.
Hunk #19 FAILED at 860.
Hunk #20 FAILED at 869.
Hunk #21 FAILED at 927.
Hunk #22 succeeded at 935 with fuzz 2.
Hunk #23 FAILED at 952.
Hunk #24 succeeded at 961 with fuzz 2.
Hunk #25 FAILED at 995.
Hunk #26 succeeded at 1004 with fuzz 2.
Hunk #27 FAILED at 1034.
20 out of 27 hunks FAILED
checking file libgcc/config/arm/lib1funcs.S




@@ -1149,12 +1250,16 @@ ARM_FUNC_START aeabi_cdrcmple
 mov r3, ip
 b   6f

-ARM_FUNC_START aeabi_cdcmpeq
+; ARM_FUNC_START aeabi_cdcmpeq
 ARM_FUNC_ALIAS aeabi_cdcmple aeabi_cdcmpeq



There appears  to be a stray `;' there. How has this been tested ?



 @ The status-returning routines are required to preserve all
 @ registers except ip, lr, and cpsr.
 6:  do_push {r0, lr}
+.cfi_adjust_cfa_offset 8  @ CFA is now sp + previousOffset + 8.
+.cfi_rel_offset r0, 0 @ Previous r0 is saved at sp.
+.cfi_rel_offset lr, 4 @ Previous lr is saved at sp + 4.
+
 ARM_CALL cmpdf2
 @ Set the Z flag correctly, and the C flag unconditionally.
 cmp r0, #0



Can you please generate a diff using svn diff from a pristine checkout 
of the sources, please and resend it as an attachment, making sure you 
test this properly with a regression run.


regards
Ramana

[patch] Constructing std::shared_ptr from an empty std::unique_ptr

[Jonathan Wakely]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4383.html#2415

Voted in to the WP in Lenexa.

Tested powerpc64le-linux, committed to trunk.

commit 87937e036ae87944f7ac2b26d8ae17fe81525c4f
Author: Jonathan Wakely 
Date:   Wed May 13 15:54:45 2015 +0100

	* include/bits/shared_ptr_base.h (__shared_count(unique_ptr&&)): Check
	for nullptr (LWG 2415).
	* testsuite/20_util/shared_ptr/cons/unique_ptr_deleter.cc: Test
	construction from empty unique_ptr.
	* testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust dg-error.
	* testsuite/20_util/shared_ptr/cons/void_neg.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h b/libstdc++-v3/include/bits/shared_ptr_base.h
index 8c3af12..081df87 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -632,6 +632,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 explicit
 	__shared_count(std::unique_ptr<_Tp, _Del>&& __r) : _M_pi(0)
 	{
+	  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+	  // 2415. Inconsistency between unique_ptr and shared_ptr
+	  if (__r.get() == nullptr)
+	return;
+
 	  using _Ptr = typename unique_ptr<_Tp, _Del>::pointer;
 	  using _Del2 = typename conditional::value,
 	  reference_wrapper::type>,
diff --git a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
index 97cc139..6255522 100644
--- a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
@@ -32,7 +32,7 @@ void test01()
 {
   X* px = 0;
   std::shared_ptr p1(px);   // { dg-error "here" }
-  // { dg-error "incomplete" "" { target *-*-* } 886 }
+  // { dg-error "incomplete" "" { target *-*-* } 891 }
 
   std::shared_ptr p9(ap());  // { dg-error "here" }
   // { dg-error "incomplete" "" { target *-*-* } 307 }
diff --git a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/unique_ptr_deleter.cc b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/unique_ptr_deleter.cc
index 67bf577..e010977 100644
--- a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/unique_ptr_deleter.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/unique_ptr_deleter.cc
@@ -34,7 +34,7 @@ int D::count = 0;
 // 20.7.12.2.1 shared_ptr constructors [util.smartptr.shared.const]
 
 // Construction from unique_ptr
-int
+void
 test01()
 {
   bool test __attribute__((unused)) = true;
@@ -47,13 +47,25 @@ test01()
   VERIFY( sp.use_count() == 1 );
   }
   VERIFY( D::count == 1 );
+}
 
-  return 0;
+void
+test02()
+{
+  bool test __attribute__((unused)) = true;
+
+  D::count = 0;
+  std::unique_ptr up;
+  {
+std::shared_ptr sp = std::move(up);
+  }
+  VERIFY( D::count == 0 ); // LWG 2415
 }
 
 int
 main()
 {
   test01();
+  test02();
   return 0;
 }
diff --git a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/void_neg.cc b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/void_neg.cc
index 2afcd8b..3f6c4ae 100644
--- a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/void_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/void_neg.cc
@@ -25,5 +25,5 @@
 void test01()
 {
   std::shared_ptr p((void*)nullptr);   // { dg-error "here" }
-  // { dg-error "incomplete" "" { target *-*-* } 885 }
+  // { dg-error "incomplete" "" { target *-*-* } 890 }
 }

Re: [PATCH, alpha]: Some further HWI == 64 improvements

[Richard Henderson]

On 05/13/2015 08:04 AM, Uros Bizjak wrote:
> Hello!
> 
> 2015-05-13  Uros Bizjak  
> 
> * config/alpha/alpha.c (alpha_emit_set_long_const): Remove c1 argument.
> (alpha_extract_integer): Redeclare as static HOST_WIDE_INT.
> Remove *p0 and *p1 arguments.  Rewrite function.
> (alpha_legitimate_constant_p): Update call to alpha_extract_integer.
> (alpha_split_const_mov): Update calls to alpha_extract_integer and
> alpha_emit_set_long_const.
> (alpha_expand_epilogue): Update calls to alpha_emit_set_long_const.
> (alpha_output_mi_thunk_osf): Ditto.
> * config/alpha/alpha.md (movti): Do not check operands[1]
> for CONST_DOUBLE.
> 
> Tested on alpha-linux-gnu and committed to mainline SVN.
> 
> Uros.
> 
> 
> a.diff.txt
> 
> 
> Index: config/alpha/alpha.c
> ===
> --- config/alpha/alpha.c  (revision 223097)
> +++ config/alpha/alpha.c  (working copy)
> @@ -2068,13 +2068,12 @@ alpha_emit_set_const (rtx target, machine_mode mod
> with alpha_emit_set_const.  */
>  
>  static rtx
> -alpha_emit_set_long_const (rtx target, HOST_WIDE_INT c1, HOST_WIDE_INT c2)
> +alpha_emit_set_long_const (rtx target, HOST_WIDE_INT c1)
>  {
>HOST_WIDE_INT d1, d2, d3, d4;
>  
>/* Decompose the entire word */
>  
> -  gcc_assert (c2 == -(c1 < 0));
>d1 = ((c1 & 0x) ^ 0x8000) - 0x8000;
>c1 -= d1;
>d2 = ((c1 & 0x) ^ 0x8000) - 0x8000;
> @@ -2109,25 +2108,23 @@ static rtx
>  /* Given an integral CONST_INT, CONST_WIDE_INT, CONST_DOUBLE,
> or CONST_VECTOR, return the low 64 bits.  */
>  
> -static void
> -alpha_extract_integer (rtx x, HOST_WIDE_INT *p0, HOST_WIDE_INT *p1)
> +static HOST_WIDE_INT
> +alpha_extract_integer (rtx x)
>  {
> -  HOST_WIDE_INT i0, i1;
> -
>if (GET_CODE (x) == CONST_VECTOR)
>  x = simplify_subreg (DImode, x, GET_MODE (x), 0);
>  
> -  if (CONST_INT_P (x))
> -i0 = INTVAL (x);
> -  else if (CONST_WIDE_INT_P (x))
> -i0 = CONST_WIDE_INT_ELT (x, 0);
> -  else
> -i0 = CONST_DOUBLE_LOW (x);
> -
> -  i1 = -(i0 < 0);
> -  
> -  *p0 = i0;
> -  *p1 = i1;
> +  switch (GET_CODE (x))
> +{
> +case CONST_INT:
> +  return INTVAL (x);
> +case CONST_WIDE_INT:
> +  return CONST_WIDE_INT_ELT (x, 0);
> +case CONST_DOUBLE:
> +  return CONST_DOUBLE_LOW (x);
> +default:
> +  gcc_unreachable ();
> +}

Surely we don't actually need to test for CONST_DOUBLE anymore?

>  }
>  
>  /* Implement TARGET_LEGITIMATE_CONSTANT_P.  This is all constants for which
> @@ -2138,7 +2135,7 @@ static rtx
>  bool
>  alpha_legitimate_constant_p (machine_mode mode, rtx x)
>  {
> -  HOST_WIDE_INT i0, i1;
> +  HOST_WIDE_INT i0;
>  
>switch (GET_CODE (x))
>  {
> @@ -2185,7 +2182,7 @@ alpha_legitimate_constant_p (machine_mode mode, rt
>  do_integer:
>if (TARGET_BUILD_CONSTANTS)
>   return true;
> -  alpha_extract_integer (x, &i0, &i1);
> +  i0 = alpha_extract_integer (x);
>return alpha_emit_set_const_1 (x, mode, i0, 3, true) != NULL;

Doesn't this now allow CONST_WIDE_INT that are in fact wider than 64 bits?
Which I can't imagine being legitimate...

>  
>  default:
> @@ -2199,15 +2196,15 @@ alpha_legitimate_constant_p (machine_mode mode, rt
>  bool
>  alpha_split_const_mov (machine_mode mode, rtx *operands)
>  {
> -  HOST_WIDE_INT i0, i1;
> +  HOST_WIDE_INT i0;
>rtx temp = NULL_RTX;
>  
> -  alpha_extract_integer (operands[1], &i0, &i1);
> +  i0 = alpha_extract_integer (operands[1]);
>  
>temp = alpha_emit_set_const (operands[0], mode, i0, 3, false);
>  
>if (!temp && TARGET_BUILD_CONSTANTS)
> -temp = alpha_emit_set_long_const (operands[0], i0, i1);
> +temp = alpha_emit_set_long_const (operands[0], i0);
>  
>if (temp)
>  {
> @@ -8260,8 +8257,7 @@ alpha_expand_epilogue (void)
>   {
> /* We can't drop new things to memory this late, afaik,
>so build it up by pieces.  */
> -   sp_adj2 = alpha_emit_set_long_const (tmp, frame_size,
> --(frame_size < 0));
> +   sp_adj2 = alpha_emit_set_long_const (tmp, frame_size);
> gcc_assert (sp_adj2);
>   }
>   }
> @@ -8388,8 +8384,7 @@ alpha_output_mi_thunk_osf (FILE *file, tree thunk_
>  }
>else
>  {
> -  rtx tmp = alpha_emit_set_long_const (gen_rtx_REG (Pmode, 0),
> -delta, -(delta < 0));
> +  rtx tmp = alpha_emit_set_long_const (gen_rtx_REG (Pmode, 0), delta);
>emit_insn (gen_adddi3 (this_rtx, this_rtx, tmp));
>  }
>  
> @@ -8411,7 +8406,7 @@ alpha_output_mi_thunk_osf (FILE *file, tree thunk_
>else
>   {
> tmp2 = alpha_emit_set_long_const (gen_rtx_REG (Pmode, 1),
> - vcall_offset, -(vcall_offset < 0));
> + vcall_offset);
>emit_insn (gen_adddi3 (tmp

Re: [C frontend] Fix construction of TYPE_STUB_DECL

[Jan Hubicka]

Hello,
it seems that the discussion here got stuck without arriving to a consensus.
I generally see three options here
 1) make TYPE_PUBLIC flag of TYPE_STUB_DECL to work consistently across 
frontends
in a sense that types with flag !TYPE_PUBLIC (TYPE_STUB_DECL (t)) can be
considered local to the translation unit and thus we can consider these 
types
non-escaping (possibly changing the layout) and TBAA incompatible with types
from other units for LTO.
 2) Add TYPE_ODR flag that will mark all types that comply the ODR rule.  This
would be ideally set on C++ types by the FE.
 3) Make type_in_anonymous_namespace to walk context and look for non-public
namespace instead of relying on TYPE_STUB_DECL alone and if TREE_PUBLIC
flag on namespaces turns out to be not consistent across FEs, it may
walk up to check TRANSLATION_UNIT_DECL and work out if it is C++ lang.

In general I still lean toward 1 as it has hope to be useful for non-C++
languages that have notion of local types. I am trying to keep all the
ODR/devirt code as generic as posisble to make it useful for non-C++ based
languages, too. 1) is one of very few cases where we can "solve" type escape.

3) feels like a hack and would make type_in_anonymous_namespace
non-constant (probably still cheap enough for my needs).  It seems like
something useful for verify_type to check that 1) or 2) works as expected.

Any solution here would let me to apply
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01061.html which otherwise
triggers false positives on Firefox. Mixing C and C++ units makes us to
think that one of global vars (originating from C unit) is declared with type
in anonymous namespace and thus can not match declaration from other unit.
This is workaroundable, too, because C++ variables in anonymous namespaces
are never global so I know all those warnings are false positives, but I
would preffer to not go this way.

Together with the -Wodr warning on types the patch
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01061.html tests that the ODR
equivalency as established by ipa-devrt at linktime exactly match what C++
standard says - if it was wrongly defining two different types equivalent, we
will eventually get ODR type mismatch warning.  If it was wrongly defining two
types different, we will get eventually incompatible declaration warning. I
would like to get this tested and keep an eye at ODR warnings double checking
that they really indicate bugs in compiled programs and not bugs in GCC.
(current implementation seems correct so far on the bigger apps I built)

Moreover the patch is useful to catch some real bugs in Firefox or Libreoffice.

Honza

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

[Ramana Radhakrishnan]

On 13/05/15 17:37, Ramana Radhakrishnan wrote:



On 12/05/15 14:01, Martin Galvan wrote:

On Tue, May 12, 2015 at 5:49 AM, Ramana Radhakrishnan
 wrote:

That's what I mean when I say email clients "munged it" : email
clients and
/ or some popular email servers appear to end up munging white spaces
and
patches don't apply cleanly.

So, no it doesn't work - once you've sent it through your email client /
server. I am unable to apply the patch as it stands today either
taking the
raw text from the gcc-patches archive or from your email message in my
inbox. It's not like line endings and things have been munged but every
whitespace / tab is in trouble here.

Please send it back as an attachment if you want me to apply it.


Oh, I see! Sorry for that, I thought the problem was on my side.
Here's the patch, it's the cfi.patch file.




I'm not sure what's going on here and couldn't figure out what was going
wrong in the 20 minutes I spent on it just now.




Bah, I must be going blind.



@@ -53,11 +57,13 @@

 ARM_FUNC_START negdf2
 ARM_FUNC_ALIAS aeabi_dneg negdf2
+CFI_START_FUNCTION

 @ flip sign bit
 eor xh, xh, #0x8000


Either the mail server you are using or the source repository you have 
has replaced tabs with spaces, the eor here has a tab in the sources 
between eor and xh. Thus the patch is malformed according to the 
sources. I suspect that's the reason why all the other hunks are not 
applying.


Before reposting -

0. Please take care of the issue I mentioned in the previous email .

1. Please mail the patch so created to yourself on a different account 
and applying the patch you receive on pristine sources. Identify a mail 
server that you can use to send emails to lists that don't munge patches 
in this manner.


2. Please test such a tree and ensure no regressions in a run of the GCC 
testsuite.


3. Post the patch back to gcc-patches@gcc.gnu.org from the mail server 
that doesn't munge patches in this manner. I'll review it again then.


Thanks,
Ramana





 RET

+CFI_END_FUNCTION
 FUNC_END aeabi_dneg
 FUNC_END negdf2









Applying the patch downloaded from 2 different inboxes still gives me
the same result.

$> patch -p1 --dry-run < /work/cfi.patch
checking file libgcc/config/arm/ieee754-df.S
Hunk #2 FAILED at 57.
Hunk #3 succeeded at 70 with fuzz 2.
Hunk #4 FAILED at 86.
Hunk #5 FAILED at 153.
Hunk #6 FAILED at 418.
Hunk #7 FAILED at 425.
Hunk #8 FAILED at 440.
Hunk #9 FAILED at 462.
Hunk #10 FAILED at 485.
Hunk #11 FAILED at 555.
Hunk #12 FAILED at 566.
Hunk #13 FAILED at 601.
Hunk #14 FAILED at 653.
Hunk #15 FAILED at 720.
Hunk #16 FAILED at 868.
Hunk #17 FAILED at 1057.
Hunk #18 FAILED at 1068.
Hunk #19 FAILED at 1082.
Hunk #20 FAILED at 1090.
Hunk #21 FAILED at 1122.
Hunk #22 FAILED at 1133.
Hunk #23 succeeded at 1145 with fuzz 2.
Hunk #24 FAILED at 1155.
Hunk #25 FAILED at 1168.
Hunk #26 FAILED at 1228.
Hunk #27 succeeded at 1236 with fuzz 2.
Hunk #28 FAILED at 1254.
Hunk #29 succeeded at 1263 with fuzz 2.
Hunk #30 FAILED at 1297.
Hunk #31 succeeded at 1306 with fuzz 2.
Hunk #32 FAILED at 1336.
Hunk #33 succeeded at 1345 with fuzz 2.
Hunk #34 FAILED at 1410.
27 out of 34 hunks FAILED
checking file libgcc/config/arm/ieee754-sf.S
Hunk #1 FAILED at 31.
Hunk #2 succeeded at 49 with fuzz 2.
Hunk #3 FAILED at 285.
Hunk #4 FAILED at 293.
Hunk #5 FAILED at 317.
Hunk #6 succeeded at 324 with fuzz 2.
Hunk #7 FAILED at 411.
Hunk #8 succeeded at 422 with fuzz 2.
Hunk #9 FAILED at 457.
Hunk #10 FAILED at 468.
Hunk #11 FAILED at 621.
Hunk #12 FAILED at 761.
Hunk #13 FAILED at 785.
Hunk #14 FAILED at 799.
Hunk #15 FAILED at 807.
Hunk #16 FAILED at 826.
Hunk #17 FAILED at 835.
Hunk #18 succeeded at 847 with fuzz 2.
Hunk #19 FAILED at 860.
Hunk #20 FAILED at 869.
Hunk #21 FAILED at 927.
Hunk #22 succeeded at 935 with fuzz 2.
Hunk #23 FAILED at 952.
Hunk #24 succeeded at 961 with fuzz 2.
Hunk #25 FAILED at 995.
Hunk #26 succeeded at 1004 with fuzz 2.
Hunk #27 FAILED at 1034.
20 out of 27 hunks FAILED
checking file libgcc/config/arm/lib1funcs.S




@@ -1149,12 +1250,16 @@ ARM_FUNC_START aeabi_cdrcmple
 mov r3, ip
 b   6f

-ARM_FUNC_START aeabi_cdcmpeq
+; ARM_FUNC_START aeabi_cdcmpeq
 ARM_FUNC_ALIAS aeabi_cdcmple aeabi_cdcmpeq



There appears  to be a stray `;' there. How has this been tested ?



 @ The status-returning routines are required to preserve all
 @ registers except ip, lr, and cpsr.
 6:  do_push {r0, lr}
+.cfi_adjust_cfa_offset 8  @ CFA is now sp + previousOffset + 8.
+.cfi_rel_offset r0, 0 @ Previous r0 is saved at sp.
+.cfi_rel_offset lr, 4 @ Previous lr is saved at sp + 4.
+
 ARM_CALL cmpdf2
 @ Set the Z flag correctly, and the C flag unconditionally.
 cmp r0, #0



Can you please generate a diff using svn diff from a pristine checkout
of the sources, please and resend it as an attachment, making sure you
test this properly with a regression run.

regards
Ramana

[committed] Fix #pragma omp task expansion with noreturn task bodies (PR middle-end/66133)

[Jakub Jelinek]

Hi!

During taskloop development, I have noticed a bug in the GIMPLE_OMP_TASK
ompexp - unlike GIMPLE_OMP_PARALLEL, where if the parallel body is noreturn,
the GOMP_parallel call never returns either, for tasks it really depends
on whether the task is included or not.  If the library (the usual case)
schedules it to run in some other thread, or the same one when it starts
waiting on a barrier, then it will return immediately.
Without this patch we weren't representing this possible control flow
through a cfg edge (from cfg pass till ompexp), which meant that we
in that case assumed the GOMP_task call will not return.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.  Will backport after a few days to 5 branch, perhaps
older branches too.

2015-05-13  Jakub Jelinek  

PR middle-end/66133
* omp-low.c (expand_omp_taskreg): For GIMPLE_OMP_TASK expansion,
make sure it is never noreturn, even when the task body does not
return.
(lower_omp_taskreg): For GIMPLE_OMP_TASK, emit GIMPLE_OMP_CONTINUE
right before GIMPLE_OMP_RETURN.
(make_gimple_omp_edges): Accept GIMPLE_OMP_CONTINUE as ->cont
for GIMPLE_OMP_TASK.  For GIMPLE_OMP_RETURN corresponding to
GIMPLE_OMP_TASK add an EDGE_ABNORMAL edge from entry to exit.

* testsuite/libgomp.c/pr66133.c: New test.

--- gcc/omp-low.c.jj2015-04-21 18:23:24.0 +0200
+++ gcc/omp-low.c   2015-05-13 15:41:03.648446718 +0200
@@ -5377,7 +5377,10 @@ expand_omp_taskreg (struct omp_region *r
   child_cfun = DECL_STRUCT_FUNCTION (child_fn);
 
   entry_bb = region->entry;
-  exit_bb = region->exit;
+  if (gimple_code (entry_stmt) == GIMPLE_OMP_TASK)
+exit_bb = region->cont;
+  else
+exit_bb = region->exit;
 
   bool is_cilk_for
 = (flag_cilkplus
@@ -5436,7 +5439,9 @@ expand_omp_taskreg (struct omp_region *r
 variable.  In which case, we need to keep the assignment.  */
   if (gimple_omp_taskreg_data_arg (entry_stmt))
{
- basic_block entry_succ_bb = single_succ (entry_bb);
+ basic_block entry_succ_bb
+   = single_succ_p (entry_bb) ? single_succ (entry_bb)
+  : FALLTHRU_EDGE (entry_bb)->dest;
  tree arg, narg;
  gimple parcopy_stmt = NULL;
 
@@ -5524,14 +5529,28 @@ expand_omp_taskreg (struct omp_region *r
   e = split_block (entry_bb, stmt);
   gsi_remove (&gsi, true);
   entry_bb = e->dest;
-  single_succ_edge (entry_bb)->flags = EDGE_FALLTHRU;
+  edge e2 = NULL;
+  if (gimple_code (entry_stmt) == GIMPLE_OMP_PARALLEL)
+   single_succ_edge (entry_bb)->flags = EDGE_FALLTHRU;
+  else
+   {
+ e2 = make_edge (e->src, BRANCH_EDGE (entry_bb)->dest, EDGE_ABNORMAL);
+ gcc_assert (e2->dest == region->exit);
+ remove_edge (BRANCH_EDGE (entry_bb));
+ set_immediate_dominator (CDI_DOMINATORS, e2->dest, e->src);
+ gsi = gsi_last_bb (region->exit);
+ gcc_assert (!gsi_end_p (gsi)
+ && gimple_code (gsi_stmt (gsi)) == GIMPLE_OMP_RETURN);
+ gsi_remove (&gsi, true);
+   }
 
-  /* Convert GIMPLE_OMP_RETURN into a RETURN_EXPR.  */
+  /* Convert GIMPLE_OMP_{RETURN,CONTINUE} into a RETURN_EXPR.  */
   if (exit_bb)
{
  gsi = gsi_last_bb (exit_bb);
  gcc_assert (!gsi_end_p (gsi)
- && gimple_code (gsi_stmt (gsi)) == GIMPLE_OMP_RETURN);
+ && (gimple_code (gsi_stmt (gsi))
+ == (e2 ? GIMPLE_OMP_CONTINUE : GIMPLE_OMP_RETURN)));
  stmt = gimple_build_return (NULL);
  gsi_insert_after (&gsi, stmt, GSI_SAME_STMT);
  gsi_remove (&gsi, true);
@@ -5552,6 +5571,14 @@ expand_omp_taskreg (struct omp_region *r
   new_bb = move_sese_region_to_fn (child_cfun, entry_bb, exit_bb, block);
   if (exit_bb)
single_succ_edge (new_bb)->flags = EDGE_FALLTHRU;
+  if (e2)
+   {
+ basic_block dest_bb = e2->dest;
+ if (!exit_bb)
+   make_edge (new_bb, dest_bb, EDGE_FALLTHRU);
+ remove_edge (e2);
+ set_immediate_dominator (CDI_DOMINATORS, dest_bb, new_bb);
+   }
   /* When the OMP expansion process cannot guarantee an up-to-date
  loop tree arrange for the child function to fixup loops.  */
   if (loops_state_satisfies_p (LOOPS_NEED_FIXUP))
@@ -11158,6 +11185,10 @@ lower_omp_taskreg (gimple_stmt_iterator
 gimple_seq_add_stmt (&new_body, gimple_build_label (ctx->cancel_label));
   gimple_seq_add_seq (&new_body, par_olist);
   new_body = maybe_catch_exception (new_body);
+  if (gimple_code (stmt) == GIMPLE_OMP_TASK)
+gimple_seq_add_stmt (&new_body,
+gimple_build_omp_continue (integer_zero_node,
+   integer_zero_node));
   gimple_seq_add_stmt (&new_body, gimple_build_omp_return (false));
   gimple_omp_set_body (stmt,

Re: [patch] std::polar requires non-negative rho

[Daniel Krügler]

2015-05-13 16:05 GMT+02:00 Marc Glisse :
> On Wed, 13 May 2015, Daniel Krügler wrote:
>> What about assertions regarding non-NAN rho and finite theta, as
>> decided for by the LWG 2439?
>
> non-NAN rho is already covered by rho >= 0.

Agreed on that.

- Daniel

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

[Martin Galvan]

On Wed, May 13, 2015 at 1:58 PM, Ramana Radhakrishnan
 wrote:
> On 13/05/15 17:37, Ramana Radhakrishnan wrote:
>> I'm not sure what's going on here and couldn't figure out what was going
>> wrong in the 20 minutes I spent on it just now.
>>
> Bah, I must be going blind.
>
>>
>> @@ -53,11 +57,13 @@
>>
>>  ARM_FUNC_START negdf2
>>  ARM_FUNC_ALIAS aeabi_dneg negdf2
>> +CFI_START_FUNCTION
>>
>>  @ flip sign bit
>>  eor xh, xh, #0x8000
>
>
> Either the mail server you are using or the source repository you have has
> replaced tabs with spaces, the eor here has a tab in the sources between eor
> and xh. Thus the patch is malformed according to the sources. I suspect
> that's the reason why all the other hunks are not applying.

That makes sense. I downloaded the gcc sources from the git mirror at
github-- perhaps that's what's munging the patch?

> Before reposting -
>
> 0. Please take care of the issue I mentioned in the previous email .

Will do. I honestly have no idea how that semicolon ended there, since
I tried a dry run of the file I sent you and it didn't complain.
Perhaps I accidentally typed it in before closing the file, I don't
know.

> 1. Please mail the patch so created to yourself on a different account and
> applying the patch you receive on pristine sources. Identify a mail server
> that you can use to send emails to lists that don't munge patches in this
> manner.

I used git send-email through gmail when contributing to various
projects such as gdb, and so far haven't had any problems like this
one.

> 2. Please test such a tree and ensure no regressions in a run of the GCC
> testsuite.
>
> 3. Post the patch back to gcc-patches@gcc.gnu.org from the mail server that
> doesn't munge patches in this manner. I'll review it again then.

Will do. Thanks a lot!

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

[Marek Polacek]

On Wed, May 13, 2015 at 02:07:34PM -0300, Martin Galvan wrote:
> That makes sense. I downloaded the gcc sources from the git mirror at
> github-- perhaps that's what's munging the patch?

That mirror seems to be out-of-date.  I suggest using
.

Marek

[PATCH] rs6000: Improve rtx_costs for EQ a bit (PR30967)

[Segher Boessenkool]

This patch changes rs6000_rtx_costs to be closer to reality.  It is
still not quite right, but at least it handles more cases, so the

(set (reg:SI) (eq:SI (reg:SI) (reg:SI)))

from the PR isn't taken as costing 1 insn anymore, while setting
a reg:DI was cost 3 insns.  The mode of the dest doesn't matter at
all here, not for any of our current scc patterns.

Testing in progress; okay for trunk?


Segher


2015-05-13  Segher Boessenkool  

PR rtl-optimization/30967
* config/rs6000/rs6000.c (rs6000_rtx_costs): Don't consider
destination mode for the cost of scc patterns.

---
 gcc/config/rs6000/rs6000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index e5b8edd..1e32144 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -30631,7 +30631,7 @@ rs6000_rtx_costs (rtx x, int code, int outer_code, int 
opno ATTRIBUTE_UNUSED,
*total = COSTS_N_INSNS (2);
  return true;
}
- else if (mode == Pmode)
+ else
{
  *total = COSTS_N_INSNS (3);
  return false;
-- 
1.8.1.4

Re: [PATCH] rs6000: Improve rtx_costs for EQ a bit (PR30967)

[David Edelsohn]

On Wed, May 13, 2015 at 1:15 PM, Segher Boessenkool
 wrote:
> This patch changes rs6000_rtx_costs to be closer to reality.  It is
> still not quite right, but at least it handles more cases, so the
>
> (set (reg:SI) (eq:SI (reg:SI) (reg:SI)))
>
> from the PR isn't taken as costing 1 insn anymore, while setting
> a reg:DI was cost 3 insns.  The mode of the dest doesn't matter at
> all here, not for any of our current scc patterns.
>
> Testing in progress; okay for trunk?
>
>
> Segher
>
>
> 2015-05-13  Segher Boessenkool  
>
> PR rtl-optimization/30967
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Don't consider
> destination mode for the cost of scc patterns.

Okay.

Should this be applied to GCC 5 branch?

thanks, David

Re: [PATCH] rs6000: Improve rtx_costs for EQ a bit (PR30967)

[Segher Boessenkool]

On Wed, May 13, 2015 at 01:25:16PM -0400, David Edelsohn wrote:
> > PR rtl-optimization/30967
> > * config/rs6000/rs6000.c (rs6000_rtx_costs): Don't consider
> > destination mode for the cost of scc patterns.
> 
> Okay.
> 
> Should this be applied to GCC 5 branch?

[ Testing is still in progress. ]

It should be prefectly safe to backport; OTOH, it is just one of very
many cases where we generate an extra sign-extend, so I don't think it
is particularly useful.  Your choice :-)


Segher

Re: [PATCH, alpha]: Some further HWI == 64 improvements

[Uros Bizjak]

On Wed, May 13, 2015 at 6:46 PM, Richard Henderson  wrote:
> On 05/13/2015 08:04 AM, Uros Bizjak wrote:
>> Hello!
>>
>> 2015-05-13  Uros Bizjak  
>>
>> * config/alpha/alpha.c (alpha_emit_set_long_const): Remove c1 argument.
>> (alpha_extract_integer): Redeclare as static HOST_WIDE_INT.
>> Remove *p0 and *p1 arguments.  Rewrite function.
>> (alpha_legitimate_constant_p): Update call to alpha_extract_integer.
>> (alpha_split_const_mov): Update calls to alpha_extract_integer and
>> alpha_emit_set_long_const.
>> (alpha_expand_epilogue): Update calls to alpha_emit_set_long_const.
>> (alpha_output_mi_thunk_osf): Ditto.
>> * config/alpha/alpha.md (movti): Do not check operands[1]
>> for CONST_DOUBLE.
>>
>> Tested on alpha-linux-gnu and committed to mainline SVN.

>> +  switch (GET_CODE (x))
>> +{
>> +case CONST_INT:
>> +  return INTVAL (x);
>> +case CONST_WIDE_INT:
>> +  return CONST_WIDE_INT_ELT (x, 0);
>> +case CONST_DOUBLE:
>> +  return CONST_DOUBLE_LOW (x);
>> +default:
>> +  gcc_unreachable ();
>> +}
>
> Surely we don't actually need to test for CONST_DOUBLE anymore?

Indeed. I will look into it in a follow-up patch. There are probably
some more checks for CONST_DOUBLE, I'll look into this later.


>>  /* Implement TARGET_LEGITIMATE_CONSTANT_P.  This is all constants for which
>> @@ -2138,7 +2135,7 @@ static rtx
>>  bool
>>  alpha_legitimate_constant_p (machine_mode mode, rtx x)
>>  {
>> -  HOST_WIDE_INT i0, i1;
>> +  HOST_WIDE_INT i0;
>>
>>switch (GET_CODE (x))
>>  {
>> @@ -2185,7 +2182,7 @@ alpha_legitimate_constant_p (machine_mode mode, rt
>>  do_integer:
>>if (TARGET_BUILD_CONSTANTS)
>>   return true;
>> -  alpha_extract_integer (x, &i0, &i1);
>> +  i0 = alpha_extract_integer (x);
>>return alpha_emit_set_const_1 (x, mode, i0, 3, true) != NULL;
>
> Doesn't this now allow CONST_WIDE_INT that are in fact wider than 64 bits?
> Which I can't imagine being legitimate...

I did check this part with:

--cut here--
__int128 a;

void test (void)
{
  a = ((__int128) 7 << 100) + ((__int128) 1 << 30);
}
--cut here--

and generated code was identical to unpatched compiler:

ldah $1,16384($31)
lda $2,a
stq $1,0($2)
lda $1,7($31)
sll $1,36,$1
stq $1,8($2)
ret $31,($26),1

However, this works only for TARGET_BUILD_CONSTANTS. This is a
preexisting bug, it looks that we want:

--cut here--
Index: alpha.c
===
--- alpha.c (revision 223166)
+++ alpha.c (working copy)
@@ -2152,7 +2152,6 @@ alpha_legitimate_constant_p (machine_mode mode, rt

   if (GET_CODE (x) != SYMBOL_REF)
return true;
-
   /* FALLTHRU */

 case SYMBOL_REF:
@@ -2162,7 +2161,7 @@ alpha_legitimate_constant_p (machine_mode mode, rt
 case CONST_WIDE_INT:
   if (x == CONST0_RTX (mode))
return true;
-  goto do_integer;
+  return TARGET_BUILD_CONSTANTS != 0;

 case CONST_DOUBLE:
   if (x == CONST0_RTX (mode))
@@ -2176,10 +2175,9 @@ alpha_legitimate_constant_p (machine_mode mode, rt
return false;
   if (GET_MODE_SIZE (mode) != 8)
return false;
-  goto do_integer;
+  /* FALLTHRU */

 case CONST_INT:
-do_integer:
   if (TARGET_BUILD_CONSTANTS)
return true;
   i0 = alpha_extract_integer (x);
--cut here--

The only part that actually processes CONST_WIDE_INT is
alpha_legitimate_constant and movti expander. The latter immediately
splits any TImode CONST_WIDE_INTs.

Uros.

Re: [patch] Clean up detection of SJLJ exceptions in target libraries

[Eric Botcazou]

> The libgo parts are fine, but since libgo is mirrored from an external
> repository I'll commit those parts myself.

Thanks!

> I assume I can go ahead and commit them now?

Yes, you can, the libgo bits are independent.

-- 
Eric Botcazou

[PATCH, GOOGLE] Backport patch r212222 to google 4.9 branch

[Carrot Wei]

Hi

The more strict devirtualization condition in this patch helps to fix
google bug b/19872411.

Bootstraped and regression tested on x86-64.
OK for google 4.9 branch?


patch
Description: Binary data

Re: RFA: RL78: Place zero-initialised data into the .bss section

[DJ Delorie]

>   OK to apply ?

Ok but..

> +case SECCAT_TBSS:
> +  return default_select_section (decl, reloc, align);
> +
> +default:
> +  gcc_unreachable ();

Would it be better to just "default:" everything to
default_select_section, instead of enumerating everything we know
about today?

[PATCH, i386]: Macroize mul{,v} patterns some more

[Uros Bizjak]

Hello!

Also fixes a couple of operand constraints.

2015-05-13  Uros Bizjak  

* config/i386/i386.md (*mul3_1): Merge with *mulhi3_1
using SWIM248 mode iterator.
(*mulv4): Use x86_64_sext_operand for operand[2] constraint.
(*mulvhi4): mark operand[1] as commutative.  Use nonimmediate_operand
for operand[2] constraint.
(*mulv4_1): Merge with *mulvhi4_1 using SWI248 mode iterator.

Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 223117)
+++ config/i386/i386.md (working copy)
@@ -6477,12 +6477,22 @@
 ;; IMUL reg32/64, mem32/64 Direct
 ;;
 ;; On BDVER1, all above IMULs use DirectPath
+;;
+;; On AMDFAM10
+;; IMUL reg16, reg16, imm8 VectorPath
+;; IMUL reg16, mem16, imm8 VectorPath
+;; IMUL reg16, reg16, imm16VectorPath
+;; IMUL reg16, mem16, imm16VectorPath
+;; IMUL reg16, reg16   Direct
+;; IMUL reg16, mem16   Direct
+;;
+;; On BDVER1, all HI MULs use DoublePath
 
 (define_insn "*mul3_1"
-  [(set (match_operand:SWI48 0 "register_operand" "=r,r,r")
-   (mult:SWI48
- (match_operand:SWI48 1 "nonimmediate_operand" "%rm,rm,0")
- (match_operand:SWI48 2 "" "K,,mr")))
+  [(set (match_operand:SWIM248 0 "register_operand" "=r,r,r")
+   (mult:SWIM248
+ (match_operand:SWIM248 1 "nonimmediate_operand" "%rm,rm,0")
+ (match_operand:SWIM248 2 "" "K,,mr")))
(clobber (reg:CC FLAGS_REG))]
   "!(MEM_P (operands[1]) && MEM_P (operands[2]))"
   "@
@@ -6497,15 +6507,21 @@
   (eq_attr "alternative" "1")
  (const_string "vector")
   (and (eq_attr "alternative" "2")
-   (match_operand 1 "memory_operand"))
+   (ior (match_test "mode == HImode")
+(match_operand 1 "memory_operand")))
  (const_string "vector")]
  (const_string "direct")))
(set (attr "amdfam10_decode")
(cond [(and (eq_attr "alternative" "0,1")
-   (match_operand 1 "memory_operand"))
+   (ior (match_test "mode == HImode")
+(match_operand 1 "memory_operand")))
  (const_string "vector")]
  (const_string "direct")))
-   (set_attr "bdver1_decode" "direct")
+   (set (attr "bdver1_decode")
+   (if_then_else
+ (match_test "mode == HImode")
+   (const_string "double")
+   (const_string "direct")))
(set_attr "mode" "")])
 
 (define_insn "*mulsi3_1_zext"
@@ -6539,42 +6555,6 @@
(set_attr "bdver1_decode" "direct")
(set_attr "mode" "SI")])
 
-;; On AMDFAM10
-;; IMUL reg16, reg16, imm8 VectorPath
-;; IMUL reg16, mem16, imm8 VectorPath
-;; IMUL reg16, reg16, imm16VectorPath
-;; IMUL reg16, mem16, imm16VectorPath
-;; IMUL reg16, reg16   Direct
-;; IMUL reg16, mem16   Direct
-;;
-;; On BDVER1, all HI MULs use DoublePath
-
-(define_insn "*mulhi3_1"
-  [(set (match_operand:HI 0 "register_operand" "=r,r,r")
-   (mult:HI (match_operand:HI 1 "nonimmediate_operand" "%rm,rm,0")
-(match_operand:HI 2 "general_operand" "K,n,mr")))
-   (clobber (reg:CC FLAGS_REG))]
-  "TARGET_HIMODE_MATH
-   && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
-  "@
-   imul{w}\t{%2, %1, %0|%0, %1, %2}
-   imul{w}\t{%2, %1, %0|%0, %1, %2}
-   imul{w}\t{%2, %0|%0, %2}"
-  [(set_attr "type" "imul")
-   (set_attr "prefix_0f" "0,0,1")
-   (set (attr "athlon_decode")
-   (cond [(eq_attr "cpu" "athlon")
- (const_string "vector")
-  (eq_attr "alternative" "1,2")
- (const_string "vector")]
- (const_string "direct")))
-   (set (attr "amdfam10_decode")
-   (cond [(eq_attr "alternative" "0,1")
- (const_string "vector")]
- (const_string "direct")))
-   (set_attr "bdver1_decode" "double")
-   (set_attr "mode" "HI")])
-
 ;;On AMDFAM10 and BDVER1
 ;; MUL reg8Direct
 ;; MUL mem8Direct
@@ -6628,8 +6608,7 @@
   (sign_extend:
  (match_operand:SWI48 1 "nonimmediate_operand" "%rm,0"))
   (sign_extend:
- (match_operand:SWI48 2 ""
-"We,mr")))
+ (match_operand:SWI48 2 "x86_64_sext_operand" "We,mr")))
(sign_extend:
   (mult:SWI48 (match_dup 1) (match_dup 2)
(set (match_operand:SWI48 0 "register_operand" "=r,r")
@@ -6657,49 +6636,13 @@
(set_attr "bdver1_decode" "direct")
(set_attr "mode" "")])
 
-(define_insn "*mulv4_1"
-  [(set (reg:CCO FLAGS_REG)
-   (eq:CCO (mult:
-  (sign_extend:
- (match_operand:SWI48 1 "nonimmediate_operand" "rm,rm"))
-  (match_operand: 3 "const_int_operand" "K,i"))
-   (sign_extend:
-  (mult:SWI

Re: [PATCH, GOOGLE] Backport patch r212222 to google 4.9 branch

[Xinliang David Li]

ok.

David

On Wed, May 13, 2015 at 11:00 AM, Carrot Wei  wrote:
> Hi
>
> The more strict devirtualization condition in this patch helps to fix
> google bug b/19872411.
>
> Bootstraped and regression tested on x86-64.
> OK for google 4.9 branch?

[PATCH, alpha]: Remove some_operand and some_ni_operand

[Uros Bizjak]

We can use general_operand instead of some_operand.

2015-05-13  Uros Bizjak  

* config/alpha/alpha.md (extendqidi2): Use general_operand
instead of some_operand for operand[1] predicate.
(extendhidi2): Ditto.
(cbranchdi4): Use general_operand instead of some_operand
for operand[1] and operands[2] predicates.
(cstoredi4): Ditto.
* config/alpha/predicates.md (some_operand): Remove unused predicate.
(some_ni_operand): Ditto.

Tested on alpha-linux-gnu.

Richard, does this look OK to you, or is there any other reason that
general_operand predicates were not used here?

Uros.
Index: config/alpha/alpha.md
===
--- config/alpha/alpha.md   (revision 223097)
+++ config/alpha/alpha.md   (working copy)
@@ -1235,7 +1235,7 @@
 
 (define_expand "extendqidi2"
   [(set (match_operand:DI 0 "register_operand")
-   (sign_extend:DI (match_operand:QI 1 "some_operand")))]
+   (sign_extend:DI (match_operand:QI 1 "general_operand")))]
   ""
 {
   if (TARGET_BWX)
@@ -1280,7 +1280,7 @@
 
 (define_expand "extendhidi2"
   [(set (match_operand:DI 0 "register_operand")
-   (sign_extend:DI (match_operand:HI 1 "some_operand")))]
+   (sign_extend:DI (match_operand:HI 1 "general_operand")))]
   ""
 {
   if (TARGET_BWX)
@@ -2902,8 +2902,8 @@
 
 (define_expand "cbranchdi4"
   [(use (match_operator 0 "alpha_cbranch_operator"
- [(match_operand:DI 1 "some_operand")
-  (match_operand:DI 2 "some_operand")]))
+ [(match_operand:DI 1 "general_operand")
+  (match_operand:DI 2 "general_operand")]))
(use (match_operand 3))]
   ""
   "alpha_emit_conditional_branch (operands, DImode); DONE;")
@@ -2936,8 +2936,8 @@
 
 (define_expand "cstoredi4"
   [(use (match_operator:DI 1 "alpha_cbranch_operator"
- [(match_operand:DI 2 "some_operand")
-  (match_operand:DI 3 "some_operand")]))
+ [(match_operand:DI 2 "general_operand")
+  (match_operand:DI 3 "general_operand")]))
(clobber (match_operand:DI 0 "register_operand"))]
   ""
 {
Index: config/alpha/predicates.md
===
--- config/alpha/predicates.md  (revision 223097)
+++ config/alpha/predicates.md  (working copy)
@@ -148,20 +148,6 @@
   return REGNO_REG_CLASS (REGNO (op)) == GENERAL_REGS;
 })
 
-;; Return 1 if OP is something that can be reloaded into a register;
-;; if it is a MEM, it need not be valid.
-(define_predicate "some_operand"
-  (ior (match_code "reg,mem,const_int,const_wide_int,const_double,const_vector,
-   label_ref,symbol_ref,const,high")
-   (and (match_code "subreg")
-   (match_test "some_operand (SUBREG_REG (op), VOIDmode)"
-
-;; Likewise, but don't accept constants.
-(define_predicate "some_ni_operand"
-  (ior (match_code "reg,mem")
-   (and (match_code "subreg")
-   (match_test "some_ni_operand (SUBREG_REG (op), VOIDmode)"
-
 ;; Return 1 if OP is a valid operand for the source of a move insn.
 (define_predicate "input_operand"
   (match_code "label_ref,symbol_ref,const,high,reg,subreg,mem,

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

[Martin Galvan]

Here's the new patch. I downloaded the gcc sources from the SVN
repository, removed the extra semicolon from my version of the files
and re-generated the patch using svn diff, making sure the context
info had all the tabs from the original. I then e-mailed the patch to
myself as an attachment, applied it to the fresh SVN sources by doing
patch --dry-run -p0 < cfi-svn.patch and checked that the compilation
and tests were successful.
Index: libgcc/config/arm/ieee754-df.S
===
--- libgcc/config/arm/ieee754-df.S	(revision 223171)
+++ libgcc/config/arm/ieee754-df.S	(working copy)
@@ -33,8 +33,12 @@
  * Only the default rounding mode is intended for best performances.
  * Exceptions aren't supported yet, but that can be added quite easily
  * if necessary without impacting performances.
+ *
+ * In the CFI related comments, 'previousOffset' refers to the previous offset
+ * from sp used to compute the CFA.
  */
 
+	.cfi_sections .debug_frame
 
 #ifndef __ARMEB__
 #define xl r0
@@ -53,11 +57,13 @@
 
 ARM_FUNC_START negdf2
 ARM_FUNC_ALIAS aeabi_dneg negdf2
+	CFI_START_FUNCTION
 
 	@ flip sign bit
 	eor	xh, xh, #0x8000
 	RET
 
+	CFI_END_FUNCTION
 	FUNC_END aeabi_dneg
 	FUNC_END negdf2
 
@@ -66,6 +72,7 @@
 #ifdef L_arm_addsubdf3
 
 ARM_FUNC_START aeabi_drsub
+	CFI_START_FUNCTION
 
 	eor	xh, xh, #0x8000	@ flip sign bit of first arg
 	b	1f	
@@ -81,7 +88,11 @@
 ARM_FUNC_START adddf3
 ARM_FUNC_ALIAS aeabi_dadd adddf3
 
-1:	do_push	{r4, r5, lr}
+1:  do_push {r4, r5, lr}@ sp -= 12
+	.cfi_adjust_cfa_offset 12   @ CFA is now sp + previousOffset + 12
+	.cfi_rel_offset r4, 0   @ Registers are saved from sp to sp + 8
+	.cfi_rel_offset r5, 4
+	.cfi_rel_offset lr, 8
 
 	@ Look for zeroes, equal values, INF, or NAN.
 	shift1	lsl, r4, xh, #1
@@ -148,6 +159,11 @@
 	@ Since this is not common case, rescale them off line.
 	teq	r4, r5
 	beq	LSYM(Lad_d)
+
+@ CFI note: we're lucky that the branches to Lad_* that appear after this function
+@ have a CFI state that's exactly the same as the one we're in at this
+@ point. Otherwise the CFI would change to a different state after the branch,
+@ which would be disastrous for backtracing.
 LSYM(Lad_x):
 
 	@ Compensate for the exponent overlapping the mantissa MSB added later
@@ -413,6 +429,7 @@
 	orrne	xh, xh, #0x0008	@ quiet NAN
 	RETLDM	"r4, r5"
 
+	CFI_END_FUNCTION
 	FUNC_END aeabi_dsub
 	FUNC_END subdf3
 	FUNC_END aeabi_dadd
@@ -420,12 +437,19 @@
 
 ARM_FUNC_START floatunsidf
 ARM_FUNC_ALIAS aeabi_ui2d floatunsidf
+	CFI_START_FUNCTION
 
 	teq	r0, #0
 	do_it	eq, t
 	moveq	r1, #0
 	RETc(eq)
-	do_push	{r4, r5, lr}
+
+	do_push {r4, r5, lr}@ sp -= 12
+	.cfi_adjust_cfa_offset 12   @ CFA is now sp + previousOffset + 12
+	.cfi_rel_offset r4, 0   @ Registers are saved from sp + 0 to sp + 8.
+	.cfi_rel_offset r5, 4
+	.cfi_rel_offset lr, 8
+
 	mov	r4, #0x400		@ initial exponent
 	add	r4, r4, #(52-1 - 1)
 	mov	r5, #0			@ sign bit is 0
@@ -435,17 +459,25 @@
 	mov	xh, #0
 	b	LSYM(Lad_l)
 
+	CFI_END_FUNCTION
 	FUNC_END aeabi_ui2d
 	FUNC_END floatunsidf
 
 ARM_FUNC_START floatsidf
 ARM_FUNC_ALIAS aeabi_i2d floatsidf
+	CFI_START_FUNCTION
 
 	teq	r0, #0
 	do_it	eq, t
 	moveq	r1, #0
 	RETc(eq)
-	do_push	{r4, r5, lr}
+
+	do_push {r4, r5, lr}@ sp -= 12
+	.cfi_adjust_cfa_offset 12   @ CFA is now sp + previousOffset + 12
+	.cfi_rel_offset r4, 0   @ Registers are saved from sp + 0 to sp + 8.
+	.cfi_rel_offset r5, 4
+	.cfi_rel_offset lr, 8
+
 	mov	r4, #0x400		@ initial exponent
 	add	r4, r4, #(52-1 - 1)
 	ands	r5, r0, #0x8000	@ sign bit in r5
@@ -457,11 +489,13 @@
 	mov	xh, #0
 	b	LSYM(Lad_l)
 
+	CFI_END_FUNCTION
 	FUNC_END aeabi_i2d
 	FUNC_END floatsidf
 
 ARM_FUNC_START extendsfdf2
 ARM_FUNC_ALIAS aeabi_f2d extendsfdf2
+	CFI_START_FUNCTION
 
 	movs	r2, r0, lsl #1		@ toss sign bit
 	mov	xh, r2, asr #3		@ stretch exponent
@@ -480,22 +514,34 @@
 
 	@ value was denormalized.  We can normalize it now.
 	do_push	{r4, r5, lr}
+	.cfi_adjust_cfa_offset 12   @ CFA is now sp + previousOffset + 12
+	.cfi_rel_offset r4, 0   @ Registers are saved from sp + 0 to sp + 8.
+	.cfi_rel_offset r5, 4
+	.cfi_rel_offset lr, 8
+
 	mov	r4, #0x380		@ setup corresponding exponent
 	and	r5, xh, #0x8000	@ move sign bit in r5
 	bic	xh, xh, #0x8000
 	b	LSYM(Lad_l)
 
+	CFI_END_FUNCTION
 	FUNC_END aeabi_f2d
 	FUNC_END extendsfdf2
 
 ARM_FUNC_START floatundidf
 ARM_FUNC_ALIAS aeabi_ul2d floatundidf
+	CFI_START_FUNCTION
+	.cfi_remember_state@ Save the current CFA state.
 
 	orrs	r2, r0, r1
 	do_it	eq
 	RETc(eq)
 
-	do_push	{r4, r5, lr}
+	do_push {r4, r5, lr}   @ sp -= 12
+	.cfi_adjust_cfa_offset 12  @ CFA is now sp + previousOffset + 12
+	.cfi_rel_offset r4, 0  @ Registers are saved from sp + 0 to sp + 8
+	.cfi_rel_offset r5, 4
+	.cfi_rel_offset lr, 8
 
 	mov	r5, #0
 	b	2f
@@ -502,12 +548,20 @@
 
 ARM_FUNC_START floatdidf
 ARM_FUNC_ALIAS aeabi_l2d floatdidf
+	.cfi_restore_state
+	@ Restore the CFI state w

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

[Martin Galvan]

Forgot to mention: I first did a --dry-run of the patch and then
applied it to the gcc sources.

On Wed, May 13, 2015 at 3:11 PM, Martin Galvan
 wrote:
> Here's the new patch. I downloaded the gcc sources from the SVN
> repository, removed the extra semicolon from my version of the files
> and re-generated the patch using svn diff, making sure the context
> info had all the tabs from the original. I then e-mailed the patch to
> myself as an attachment, applied it to the fresh SVN sources by doing
> patch --dry-run -p0 < cfi-svn.patch and checked that the compilation
> and tests were successful.



-- 


Martin Galvan

Software Engineer

Taller Technologies Argentina


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: 54 351 4217888 / +54 351 4218211

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

[Alexander Monakov]

On Mon, 11 May 2015, Jan Hubicka wrote:
> Yes, to make my original email clear, I think we are safe to remove
> peep2_reg_dead_p.
> 
> I would however introduce a check that the call target is not also among
> parameters of the function. In this case the peephole would remove the load
> and make the parameter unefined.
> 
> While current mainline don't seem to be able to translate the testcase above
> that way, perhaps future improvements to LRA/postreload gcse may make it 
> happen
> and generally RTL patterns are better to be safe by definition not
> only for the actual RTL we are able to generate. I suppose reg_mentioned_p
> on call usage is enough.

Thanks.  I have bootstrapped and regtested the following patch.  OK?

* config/i386/i386.md (sibcall_memory): Check that register with
callee address is not also used as one of the arguments, instead
of checking that it is not live after the sibcall.
(sibcall_pop_memory): Ditto.
(sibcall_value_memory): Ditto.
(sibcall_value_pop_memory): Ditto.
testsuite:
* gcc.target/i386/sibcall-7.c: New test.

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 0959aef..9c1aa7d 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -11673,7 +11673,8 @@
(call (mem:QI (match_dup 0))
 (match_operand 3))]
   "!TARGET_X32 && SIBLING_CALL_P (peep2_next_insn (1))
-   && peep2_reg_dead_p (2, operands[0])"
+   && !reg_mentioned_p (operands[0],
+   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (1)))"
   [(parallel [(call (mem:QI (match_dup 1))
(match_dup 3))
  (unspec [(const_int 0)] UNSPEC_PEEPSIB)])])
@@ -11685,7 +11686,8 @@
(call (mem:QI (match_dup 0))
 (match_operand 3))]
   "!TARGET_X32 && SIBLING_CALL_P (peep2_next_insn (2))
-   && peep2_reg_dead_p (3, operands[0])"
+   && !reg_mentioned_p (operands[0],
+   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (2)))"
   [(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
(parallel [(call (mem:QI (match_dup 1))
(match_dup 3))
@@ -11744,7 +11746,8 @@
   (plus:SI (reg:SI SP_REG)
(match_operand:SI 4 "immediate_operand")))])]
   "!TARGET_64BIT && SIBLING_CALL_P (peep2_next_insn (1))
-   && peep2_reg_dead_p (2, operands[0])"
+   && !reg_mentioned_p (operands[0],
+   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (1)))"
   [(parallel [(call (mem:QI (match_dup 1))
(match_dup 3))
  (set (reg:SI SP_REG)
@@ -11762,7 +11765,8 @@
   (plus:SI (reg:SI SP_REG)
(match_operand:SI 4 "immediate_operand")))])]
   "!TARGET_64BIT && SIBLING_CALL_P (peep2_next_insn (2))
-   && peep2_reg_dead_p (3, operands[0])"
+   && !reg_mentioned_p (operands[0],
+   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (2)))"
   [(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
(parallel [(call (mem:QI (match_dup 1))
(match_dup 3))
@@ -11838,7 +11842,8 @@
(call (mem:QI (match_dup 0))
 (match_operand 3)))]
   "!TARGET_X32 && SIBLING_CALL_P (peep2_next_insn (1))
-   && peep2_reg_dead_p (2, operands[0])"
+   && !reg_mentioned_p (operands[0],
+   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (1)))"
   [(parallel [(set (match_dup 2)
   (call (mem:QI (match_dup 1))
 (match_dup 3)))
@@ -11852,7 +11857,8 @@
   (call (mem:QI (match_dup 0))
  (match_operand 3)))]
   "!TARGET_X32 && SIBLING_CALL_P (peep2_next_insn (2))
-   && peep2_reg_dead_p (3, operands[0])"
+   && !reg_mentioned_p (operands[0],
+   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (2)))"
   [(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
(parallel [(set (match_dup 2)
   (call (mem:QI (match_dup 1))
@@ -11917,7 +11923,8 @@
   (plus:SI (reg:SI SP_REG)
(match_operand:SI 4 "immediate_operand")))])]
   "!TARGET_64BIT && SIBLING_CALL_P (peep2_next_insn (1))
-   && peep2_reg_dead_p (2, operands[0])"
+   && !reg_mentioned_p (operands[0],
+   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (1)))"
   [(parallel [(set (match_dup 2)
   (call (mem:QI (match_dup 1))
 (match_dup 3)))
@@ -11937,7 +11944,8 @@
   (plus:SI (reg:SI SP_REG)
(match_operand:SI 4 "immediate_operand")))])]
   "!TARGET_64BIT && SIBLING_CALL_P (peep2_next_insn (2))
-   && peep2_reg_dead_p (3, operands[0])"
+   && !reg_mentioned_p (operands[0],
+   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (2)))"
   [(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
(parallel [(set (match_dup 2)
   (call (mem:QI (match_dup 1))
diff --git a/gcc/testsuite/gcc.target/i386/sibcall-7.c 
b/gcc/testsuite/gcc.targ

Re: [PATCH, alpha]: Some further HWI == 64 improvements

[Richard Henderson]

On 05/13/2015 10:53 AM, Uros Bizjak wrote:
> The only part that actually processes CONST_WIDE_INT is
> alpha_legitimate_constant and movti expander. The latter immediately
> splits any TImode CONST_WIDE_INTs.
> 

Indeed.  Also probably worth cleaning up is using CONST_SCALAR_INT_P, where
both CONST_INT and CONST_WIDE_INT are allowed.


r~

Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Marek Polacek]

On Wed, May 13, 2015 at 03:06:00PM +, Joseph Myers wrote:
> > It won't handle e.g. 0 * (unsigned) (1 / 0).
> 
> I think this illustrates why handling this in the folding-for-optimization 
> is a mistake.
> 
> For optimization, it's perfectly fine to fold away 0 * (something without 
> side effects), and division by 0 should only be considered to have side 
> effects if language semantic options were specified to that effect (such 
> as using ubsan), which should then have the effect of producing GENERIC 
> that's not a simple division but represents whatever checks are required.
> 
> Rather, how about having an extra argument to c_fully_fold_internal (e.g. 
> for_int_const) indicating that the folding is of an expression with 
> integer constant operands (so this argument would be true in the new case 
> of folding the contents of a C_MAYBE_CONST_EXPR with 
> C_MAYBE_CONST_EXPR_INT_OPERANDS set)?  In that special case, 
> c_fully_fold_internal would only fold the expression itself if all 
> evaluated operands folded to INTEGER_CSTs (so if something that doesn't 
> get folded, such as division by 0, is encountered, then all evaluated 
> expressions containing it also don't get folded).

Did you mean something like the following?  It is on top of the previous
c_fully_fold_internal patch; if it makes any sense, I'll squash these
into one.

With the following, I don't see any regressions in the C dg.exp testsuite.
This still doesn't reject enum { A = 0 * (unsigned) (1 / 0) };, but note
that we don't reject such an enum at present.

Thanks.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 24200f0..1dc181d 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -315,7 +315,7 @@ const struct fname_var_t fname_vars[] =
 /* Global visibility options.  */
 struct visibility_flags visibility_options;
 
-static tree c_fully_fold_internal (tree expr, bool, bool *, bool *);
+static tree c_fully_fold_internal (tree expr, bool, bool *, bool *, bool);
 static tree check_case_value (location_t, tree);
 static bool check_case_bounds (location_t, tree, tree, tree *, tree *);
 
@@ -1148,7 +1148,7 @@ c_fully_fold (tree expr, bool in_init, bool *maybe_const)
   expr = TREE_OPERAND (expr, 0);
 }
   ret = c_fully_fold_internal (expr, in_init, maybe_const,
-  &maybe_const_itself);
+  &maybe_const_itself, false);
   if (eptype)
 ret = fold_convert_loc (loc, eptype, ret);
   *maybe_const &= maybe_const_itself;
@@ -1161,11 +1161,13 @@ c_fully_fold (tree expr, bool in_init, bool 
*maybe_const)
arithmetic overflow (for C90, *MAYBE_CONST_OPERANDS is carried from
both evaluated and unevaluated subexpressions while
*MAYBE_CONST_ITSELF is carried from only evaluated
-   subexpressions).  */
+   subexpressions).  FOR_INT_CONST indicates if EXPR is an expression
+   with integer constant operands, and if any of the operands doesn't
+   get folded to an integer constant, don't fold the expression itself.  */
 
 static tree
 c_fully_fold_internal (tree expr, bool in_init, bool *maybe_const_operands,
-  bool *maybe_const_itself)
+  bool *maybe_const_itself, bool for_int_const)
 {
   tree ret = expr;
   enum tree_code code = TREE_CODE (expr);
@@ -1212,7 +1214,7 @@ c_fully_fold_internal (tree expr, bool in_init, bool 
*maybe_const_operands,
{
  *maybe_const_itself = false;
  inner = c_fully_fold_internal (inner, in_init, maybe_const_operands,
-maybe_const_itself);
+maybe_const_itself, true);
}
   if (pre && !in_init)
ret = build2 (COMPOUND_EXPR, TREE_TYPE (expr), pre, inner);
@@ -1263,7 +1265,7 @@ c_fully_fold_internal (tree expr, bool in_init, bool 
*maybe_const_operands,
   op1 = TREE_OPERAND (expr, 1);
   op2 = TREE_OPERAND (expr, 2);
   op0 = c_fully_fold_internal (op0, in_init, maybe_const_operands,
-  maybe_const_itself);
+  maybe_const_itself, for_int_const);
   STRIP_TYPE_NOPS (op0);
   if (op0 != orig_op0)
ret = build3 (COMPONENT_REF, TREE_TYPE (expr), op0, op1, op2);
@@ -1280,10 +1282,10 @@ c_fully_fold_internal (tree expr, bool in_init, bool 
*maybe_const_operands,
   op2 = TREE_OPERAND (expr, 2);
   op3 = TREE_OPERAND (expr, 3);
   op0 = c_fully_fold_internal (op0, in_init, maybe_const_operands,
-  maybe_const_itself);
+  maybe_const_itself, for_int_const);
   STRIP_TYPE_NOPS (op0);
   op1 = c_fully_fold_internal (op1, in_init, maybe_const_operands,
-  maybe_const_itself);
+  maybe_const_itself, for_int_const);
   STRIP_TYPE_NOPS (op1);
   op1 = decl_constant_value_for_optimization (op1);
   if (op0 != orig_op0 || op1 

Re: [PATCH, alpha]: Remove some_operand and some_ni_operand

[Richard Henderson]

On 05/13/2015 11:11 AM, Uros Bizjak wrote:
> We can use general_operand instead of some_operand.
> 
> 2015-05-13  Uros Bizjak  
> 
> * config/alpha/alpha.md (extendqidi2): Use general_operand
> instead of some_operand for operand[1] predicate.
> (extendhidi2): Ditto.
> (cbranchdi4): Use general_operand instead of some_operand
> for operand[1] and operands[2] predicates.
> (cstoredi4): Ditto.
> * config/alpha/predicates.md (some_operand): Remove unused predicate.
> (some_ni_operand): Ditto.
> 
> Tested on alpha-linux-gnu.
> 
> Richard, does this look OK to you, or is there any other reason that
> general_operand predicates were not used here?

For the extensions, it was put in by Kenner in 1997 (90f6b60d), to improve code
for unaligned memories.  That code was removed in 2011 by me (8b2983a3), so I
think dropping some_operand there is fine.

For the conditionals, it was added in 2004 by me (62350d6c), and that code is
still there.  Specifically,

@@ -3177,11 +3177,17 @@ alpha_emit_conditional_branch (enum rtx_code code)
cmp_code = NIL, branch_code = code;

  /* If the constants doesn't fit into an immediate, but can
 be generated by lda/ldah, we adjust the argument and
 compare against zero, so we can use beq/bne directly.  */
- else if (GET_CODE (op1) == CONST_INT && (code == EQ || code == NE))
+ /* ??? Don't do this when comparing against symbols, otherwise
+we'll reduce (&x == 0x1234) to (&x-0x1234 == 0), which will
+be declared false out of hand (at least for non-weak).  */
+ else if (GET_CODE (op1) == CONST_INT
+  && (code == EQ || code == NE)
+  && !(symbolic_operand (op0, VOIDmode)
+   || (GET_CODE (op0) == REG && REG_POINTER (op0

If I didn't use some_operand, the SYMBOL_REF would be lowered and we'll only
see a REG here.  Searching the mail archive I find

  https://gcc.gnu.org/ml/gcc-patches/2004-02/msg02436.html

pointing to the test case gcc.dg/20040123-1.c

Perhaps debugging that testcase to see what's reaching a_e_c_b in these modern
times will tell you what's most appropriate.


r~

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

[Jan Hubicka]

> On Mon, 11 May 2015, Jan Hubicka wrote:
> > Yes, to make my original email clear, I think we are safe to remove
> > peep2_reg_dead_p.
> > 
> > I would however introduce a check that the call target is not also among
> > parameters of the function. In this case the peephole would remove the load
> > and make the parameter unefined.
> > 
> > While current mainline don't seem to be able to translate the testcase above
> > that way, perhaps future improvements to LRA/postreload gcse may make it 
> > happen
> > and generally RTL patterns are better to be safe by definition not
> > only for the actual RTL we are able to generate. I suppose reg_mentioned_p
> > on call usage is enough.
> 
> Thanks.  I have bootstrapped and regtested the following patch.  OK?
> 
>   * config/i386/i386.md (sibcall_memory): Check that register with
>   callee address is not also used as one of the arguments, instead
>   of checking that it is not live after the sibcall.
>   (sibcall_pop_memory): Ditto.
>   (sibcall_value_memory): Ditto.
>   (sibcall_value_pop_memory): Ditto.
> testsuite:
>   * gcc.target/i386/sibcall-7.c: New test.

Thank you! This looks fine.  Please add also the testcase that should break if
the new test was wrong andosmeone fixed postreload to allow use of the same 
register
this check will prevent wrong code?

OK with that change.
Honza
> 
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 0959aef..9c1aa7d 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -11673,7 +11673,8 @@
> (call (mem:QI (match_dup 0))
>  (match_operand 3))]
>"!TARGET_X32 && SIBLING_CALL_P (peep2_next_insn (1))
> -   && peep2_reg_dead_p (2, operands[0])"
> +   && !reg_mentioned_p (operands[0],
> +   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (1)))"
>[(parallel [(call (mem:QI (match_dup 1))
> (match_dup 3))
>   (unspec [(const_int 0)] UNSPEC_PEEPSIB)])])
> @@ -11685,7 +11686,8 @@
> (call (mem:QI (match_dup 0))
>  (match_operand 3))]
>"!TARGET_X32 && SIBLING_CALL_P (peep2_next_insn (2))
> -   && peep2_reg_dead_p (3, operands[0])"
> +   && !reg_mentioned_p (operands[0],
> +   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (2)))"
>[(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
> (parallel [(call (mem:QI (match_dup 1))
> (match_dup 3))
> @@ -11744,7 +11746,8 @@
>(plus:SI (reg:SI SP_REG)
> (match_operand:SI 4 "immediate_operand")))])]
>"!TARGET_64BIT && SIBLING_CALL_P (peep2_next_insn (1))
> -   && peep2_reg_dead_p (2, operands[0])"
> +   && !reg_mentioned_p (operands[0],
> +   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (1)))"
>[(parallel [(call (mem:QI (match_dup 1))
> (match_dup 3))
>   (set (reg:SI SP_REG)
> @@ -11762,7 +11765,8 @@
>(plus:SI (reg:SI SP_REG)
> (match_operand:SI 4 "immediate_operand")))])]
>"!TARGET_64BIT && SIBLING_CALL_P (peep2_next_insn (2))
> -   && peep2_reg_dead_p (3, operands[0])"
> +   && !reg_mentioned_p (operands[0],
> +   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (2)))"
>[(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
> (parallel [(call (mem:QI (match_dup 1))
> (match_dup 3))
> @@ -11838,7 +11842,8 @@
> (call (mem:QI (match_dup 0))
>  (match_operand 3)))]
>"!TARGET_X32 && SIBLING_CALL_P (peep2_next_insn (1))
> -   && peep2_reg_dead_p (2, operands[0])"
> +   && !reg_mentioned_p (operands[0],
> +   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (1)))"
>[(parallel [(set (match_dup 2)
>(call (mem:QI (match_dup 1))
>  (match_dup 3)))
> @@ -11852,7 +11857,8 @@
>(call (mem:QI (match_dup 0))
>   (match_operand 3)))]
>"!TARGET_X32 && SIBLING_CALL_P (peep2_next_insn (2))
> -   && peep2_reg_dead_p (3, operands[0])"
> +   && !reg_mentioned_p (operands[0],
> +   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (2)))"
>[(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
> (parallel [(set (match_dup 2)
>(call (mem:QI (match_dup 1))
> @@ -11917,7 +11923,8 @@
>(plus:SI (reg:SI SP_REG)
> (match_operand:SI 4 "immediate_operand")))])]
>"!TARGET_64BIT && SIBLING_CALL_P (peep2_next_insn (1))
> -   && peep2_reg_dead_p (2, operands[0])"
> +   && !reg_mentioned_p (operands[0],
> +   CALL_INSN_FUNCTION_USAGE (peep2_next_insn (1)))"
>[(parallel [(set (match_dup 2)
>(call (mem:QI (match_dup 1))
>  (match_dup 3)))
> @@ -11937,7 +11944,8 @@
>(plus:SI (reg:SI SP_REG)
> (match_operand:SI 4 "immediate_operand")))])]
>"

Re: Work around PR65873

[Sandra Loosemore]

On 05/12/2015 04:12 PM, Jan Hubicka wrote:


Hi,
this patch works around PR where we refuse to inline always_inline memcpy
into function with explicit Ofast optimization attribute.  This is because
we think we can not promote -fno-fast-math code to -fast-math code.
This is of course safe for memcpy because it contains to fast-math code,
but we don't really do the analysis for each of the flags we check.

Earlier compilers was happily producing wrong code here and it seems practical
to do that on GCC 5 to deal with common falout.  I will implement the more
fine grained check incrementally.

Bootstrapped/regtested x86_64-linux. Will commit it to mainline shortly and
to release branch later this week.

PR ipa/65873
* ipa-inline.c (can_inline_edge_p): Allow early inlining of always
inlines across optimization boundary.
* testsuite/gcc.c-torture/compile/pr65873.c: New testcase.
Index: ipa-inline.c
===
--- ipa-inline.c(revision 223093)
+++ ipa-inline.c(working copy)
@@ -427,46 +427,55 @@ can_inline_edge_p (struct cgraph_edge *e
  && lookup_attribute ("always_inline",
   DECL_ATTRIBUTES (callee->decl)));



I'm having problems parsing the following comment block:


+ /* Until GCC 4.9 we did not check the semantics alterning flags


"alterning"?


+   bellow and inline across optimization boundry.


s/bellow/below/g
s/boundry/boundary/


+   Enabling checks bellow breaks several packages by refusing
+   to inline library always_inline functions. See PR65873.
+   Disable the check for early inlining for now until better solution
+   is found.  */
+ if (always_inline && early)
+   ;


-Sandra

[gomp4] nvptx offloading linking (was: [WIP] OpenMP 4 NVPTX support)

[Thomas Schwinge]

Hi!

On Wed, 22 Apr 2015 17:08:26 +0200, Bernd Schmidt  
wrote:
> On 04/21/2015 05:58 PM, Jakub Jelinek wrote:
> 
> > suggests that while it is nice that when building nvptx accel compiler
> > we build libgcc.a, libc.a, libm.a, libgfortran.a (and in the future 
> > hopefully libgomp.a),
> > nothing attempts to link those in :(.
> 
> I have that fixed; I expect I'll get around to posting this at some 
> point now that stage1 is open.

I have committed the following to gomp-4_0-branch in r223176.  We'll be
submitting this for trunk later on; some changes will need to be done, as
already discussed.

Note that this patch has some dependencies on a patch that I'll be
committing later, »Assorted OpenACC changes«.  These include
GOACC_get_num_threads and GOACC_get_thread_num interface changes; I
didn't see the point in completely disentangling these changes now.

You'll also want to update your nvptx newlib sources.

The nvptx-tools and offload-nvptx-none GCC installations need to be in
the same prefix, so that the latter can find the nvptx-none assembler,
and doesn't resort to using the »as« binary found first in $PATH, which
likely will be the host system's, and only spewing out a cascade of error
messages when confronted with PTX assembly code.  If you've been using my
build scripts (trunk-offload-big.tar.bz2, trunk-offload-light.tar.bz2;
will upload fixed tarballs later) as posted on
,
you'll need to apply the following patch:

diff --git BUILD-gcc-offload-nvptx-none BUILD-gcc-offload-nvptx-none
index 664a781..1e815eb 100755
--- BUILD-gcc-offload-nvptx-none
+++ BUILD-gcc-offload-nvptx-none
@@ -11,5 +11,5 @@ if ! test -f .have-configure; then
   ln -vs "$T"/source-newlib/newlib "$T"/source-gcc/newlib &&
-  rm -f "$T"/install/nvptx-none/usr &&
-  mkdir -p "$T"/install/nvptx-none &&
-  ln -vs . "$T"/install/nvptx-none/usr &&
+  rm -f "$T"/install/offload-nvptx-none/nvptx-none/usr &&
+  mkdir -p "$T"/install/offload-nvptx-none/nvptx-none &&
+  ln -vs . "$T"/install/offload-nvptx-none/nvptx-none/usr &&
   target=$("$T"/source-gcc/config.guess) &&
@@ -32,4 +32,4 @@ if ! test -f .have-configure; then
 --with-sysroot=/nvptx-none \
---with-build-sysroot="$T"/install/nvptx-none \
---with-build-time-tools="$T"/install/nvptx-none/bin \
+--with-build-sysroot="$T"/install/offload-nvptx-none/nvptx-none \
+--with-build-time-tools="$T"/install/offload-nvptx-none/nvptx-none/bin \
 --disable-sjlj-exceptions \
diff --git BUILD-nvptx-tools BUILD-nvptx-tools
index b58715d..c093983 100755
--- BUILD-nvptx-tools
+++ BUILD-nvptx-tools
@@ -11,3 +11,3 @@ if ! test -f .have-configure; then
 --target=nvptx-none \
---prefix="$T"/install \
+--prefix="$T"/install/offload-nvptx-none \
 --with-cuda-driver-include=$CUDA/targets/x86_64-linux/include \

commit c4e9c60e860e4bd9996df196bee54d52cda64038
Author: tschwinge 
Date:   Wed May 13 20:05:52 2015 +

nvptx offloading linking

gcc/
* config/nvptx/mkoffload.c (enum Kind, struct Token, enum Vis)
(struct Stmt): Remove.
(read_file, tokenize, write_token, write_tokens, alloc_stmt)
(alloc_comment, append_stmt, rev_stmts, write_stmt, write_stmts)
(parse_insn, parse_list_nosemi, parse_init, parse_file): Remove
functions and macros.
(decls, vars, fns): Remove variables.
(maybe_unlink): Use save_temps rather than debug to keep files.
(tool_cleanup): Unlink ptx_cfile_name and ptx_name.
(read_file): Accept a pointer to a length and store into it.
(process): Don't try to parse the input file, just write it out as a
string, but looking for maps.  Also write out the length.
(main): Don't use -S to compile ptx code.  Add -lgomp.  Add
COLLECT_MKOFFLOAD_OPTIONS.  Scan for -fopenacc and produce an empty
image if it is not set.  Scan for -save-temps.
* gcc.c (mkoffload_options): New static variable.
(display_help): Mention -Xoffload
(driver_handle_option): Handle it.
(add_mkoffload_option): New static function.
(set_collect_gcc_options): If offloading, set
COLLECT_MKOFFLOAD_OPTIONS.
* doc/invoke.texi (-Xoffload): Document.
* common.opt (Xoffload): New option.
* gcc.c (process_command): Use spec_machine rather than
spec_host_machine to build tooldir_prefix2.
gcc/fortran/
* gfortranspec.c (lang_specific_driver): Add -Xoffload options to
link -lm and -lgfortran.
libgcc/
* config.host (nvptx-*): For an offloading build, add libgomp.a
and libgomp.spec to extra_parts.
* config/nvptx/t-nvptx (gomp-acc_on_device.o, gomp-tids.o)
(gomp-atomic.o, libgomp.a, libgomp.spec): New rules.
(OBJS_libgomp): New variable.
* config/nvptx/gomp-acc_on_device.c: New file.
* config/nvptx/gomp-atomic.asm: Likewise.
* con

[gomp4] nvptx libgcc atomic routines

[Thomas Schwinge]

Hi!

On Fri, 10 Apr 2015 09:20:30 -0700, Cesar Philippidis 
 wrote:
> This patch implements the various atomic __sync_* functions inside
> libgcc. The original [motivation], were the calls to
> __sync_val_compare_and_swap_1 by openacc kernels involving boolean
> expressions. The reason for this failure is due to the fact that nvptx
> doesn't support byte-sized atomic compare and swaps, and boolean
> reductions update a bool which is an unsigned char.
> 
> Bernd suggested porting ARM's linux-atomic.c to nvptx. I tried that, but
> that particular port assumed that pointers were 4 bytes, so that caused
> some problems. I ended up using linux-atomic.c from nios2, because it
> didn't have that problem with pointers.
> 
> There are some caveats with this patch:
> 
>  * It only supports little endian nvptx targets.
> 
>  * My __kernel_cmpxchg wrapper is just an inline assembly function. It
>could, and probably should, be a nvptx specific built-in.
> 
>  * I'm not sure if I should be using a membar.cta or global, so I
>chose cta.

Committed to gomp-4_0-branch in r223177:

commit bf2d0c71d1ad06eb4e17dbb4fcc0951fd8920713
Author: tschwinge 
Date:   Wed May 13 20:17:52 2015 +

nvptx libgcc atomic routines

libgcc/
* config/nvptx/atomic.c: New file.
* config/nvptx/t-nvptx (LIB2ADD): Include it.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@223177 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgcc/ChangeLog.gomp|   5 +
 libgcc/config/nvptx/atomic.c | 279 +++
 libgcc/config/nvptx/t-nvptx  |   3 +-
 3 files changed, 286 insertions(+), 1 deletion(-)

diff --git libgcc/ChangeLog.gomp libgcc/ChangeLog.gomp
index d872575..71ea38e 100644
--- libgcc/ChangeLog.gomp
+++ libgcc/ChangeLog.gomp
@@ -1,3 +1,8 @@
+2015-05-13  Cesar Philippidis  
+
+   * config/nvptx/atomic.c: New file.
+   * config/nvptx/t-nvptx (LIB2ADD): Include it.
+
 2015-05-13  Bernd Schmidt  
Cesar Philippidis  
 
diff --git libgcc/config/nvptx/atomic.c libgcc/config/nvptx/atomic.c
new file mode 100644
index 000..deb1750
--- /dev/null
+++ libgcc/config/nvptx/atomic.c
@@ -0,0 +1,279 @@
+/* Atomic operations for PTX.
+   Copyright (C) 2015 Free Software Foundation, Inc.
+   Contributed by Mentor Graphics.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+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
+.  */
+
+/* Kernel helper for compare-and-exchange.  */
+static int
+nvidia_cas (int oldval, int newval, int *ptr)
+{
+  int ret;
+
+  asm volatile ("atom.cas.b32 %0, [%1], %2, %3;" : "=r"(ret) : "r"(ptr),
+   "r"(oldval), "r"(newval));
+
+  return ret;
+}
+
+#define __kernel_cmpxchg (nvidia_cas)
+
+/* Kernel helper for memory barrier.  */
+static void
+__threadfence_block (void)
+{
+  asm volatile ("membar.cta;");
+}
+
+#define __kernel_dmb (__threadfence_block)
+
+#define HIDDEN
+
+/* Warning: this assumes that all nvptx targets are little endian.  */
+
+#define INVERT_MASK_1 0
+#define INVERT_MASK_2 0
+
+#define MASK_1 0xffu
+#define MASK_2 0xu
+
+#define FETCH_AND_OP_WORD(OP, PFX_OP, INF_OP)  \
+  int HIDDEN   \
+  __sync_fetch_and_##OP##_4 (int *ptr, int val)
\
+  {\
+int failure, tmp;  \
+   \
+do {   \
+  tmp = *ptr;  \
+  failure = __kernel_cmpxchg (tmp, PFX_OP (tmp INF_OP val), ptr);  \
+} while (failure != 0);\
+   \
+return tmp;
\
+  }
+
+FETCH_AND_OP_WORD (add,   , +)
+FETCH_AND_OP_WORD (sub,   , -)
+FETCH_AND_OP_WORD (or,, |)
+FETCH_AND_OP_WORD (and,   , &)
+FETCH_AND_OP_WORD (xor,   , ^)
+FETCH_AND

Re: [PATCH 3/7] [D] libiberty: Include type modifiers in demangled function symbols

[Iain Buclaw]

On 13 May 2015 at 10:51, Iain Buclaw  wrote:
> Like C++ const and volatile, in D mangled symbols can exist modifiers
> that represent the const, immutable, inout and shared-ness of the
> 'this' parameter.
>
> This information should be written out in the demangled symbol to show
> that each variant has a unique identity.
>
> ---
> libiberty/ChangeLog:
>
> 2015-05-13 Iain Buclaw  
> * d-demangle.c (dlang_type_modifiers): New function.
> (dlang_type_modifier_p): New function.
> (dlang_call_convention_p): Ignore any kind of type modifier.
> (dlang_type): Handle and emit the type modifier after delegate types.
> (dlang_parse_symbol): Handle and emit the type modifier after the symbol.
> * testsuite/d-demangle-expected: Add coverage tests for all valid
> usages of function symbols with type modifiers.

Somehow in the small morning rush, I missed some extra coverage tests
in the patch, corrected in this new patch.
From 6836ff778e26dd0312d4d33a0570d979ba59a4ca Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Mon, 11 May 2015 09:20:55 +0200
Subject: [PATCH 3/7] D demangle: Include type modifiers in demangled function
 symbols

---
 libiberty/d-demangle.c  | 111 
 libiberty/testsuite/d-demangle-expected |  32 +
 2 files changed, 130 insertions(+), 13 deletions(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 91c6d55..bfad5bb 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -215,6 +215,44 @@ dlang_call_convention (string *decl, const char *mangled)
   return mangled;
 }
 
+/* Extract the type modifiers from MANGLED and append them to DECL.
+   Returns the remaining signature on success or NULL on failure.  */
+static const char *
+dlang_type_modifiers (string *decl, const char *mangled)
+{
+  if (mangled == NULL || *mangled == '\0')
+return NULL;
+
+  switch (*mangled)
+{
+case 'x': /* const */
+  mangled++;
+  string_append (decl, " const");
+  return mangled;
+case 'y': /* immutable */
+  mangled++;
+  string_append (decl, " immutable");
+  return mangled;
+case 'O': /* shared */
+  mangled++;
+  string_append (decl, " shared");
+  return dlang_type_modifiers (decl, mangled);
+case 'N':
+  mangled++;
+  if (*mangled == 'g') /* wild */
+	{
+	  mangled++;
+	  string_append (decl, " inout");
+	  return dlang_type_modifiers (decl, mangled);
+	}
+  else
+	return NULL;
+
+default:
+  return mangled;
+}
+}
+
 /* Demangle the D function attributes from MANGLED and append it to DECL.
Return the remaining string on success or NULL on failure.  */
 static const char *
@@ -476,10 +514,22 @@ dlang_type (string *decl, const char *mangled)
   mangled++;
   return dlang_parse_symbol (decl, mangled);
 case 'D': /* delegate T */
+{
+  string mods;
+  size_t szmods;
   mangled++;
+
+  string_init (&mods);
+  mangled = dlang_type_modifiers (&mods, mangled);
+  szmods = string_length (&mods);
+
   mangled = dlang_function_type (decl, mangled);
   string_append (decl, "delegate");
+  string_appendn (decl, mods.b, szmods);
+
+  string_delete (&mods);
   return mangled;
+}
 case 'B': /* tuple T */
   mangled++;
   return dlang_parse_tuple (decl, mangled);
@@ -1135,28 +1185,54 @@ dlang_value (string *decl, const char *mangled, const char *name, char type)
   return mangled;
 }
 
+/* Extract the type modifiers from MANGLED and return the string
+   length that it consumes in MANGLED on success or 0 on failure.  */
 static int
-dlang_call_convention_p (const char *mangled)
+dlang_type_modifier_p (const char *mangled)
 {
-  size_t i;
+  int i;
 
   switch (*mangled)
 {
-case 'F': case 'U': case 'V':
-case 'W': case 'R':
+case 'x': case 'y':
   return 1;
 
-case 'M': /* Prefix for functions needing 'this' */
-  i = 1;
-  if (mangled[i] == 'x')
-	i++;
+case 'O':
+  mangled++;
+  i = dlang_type_modifier_p (mangled);
+  return i + 1;
 
-  switch (mangled[i])
+case 'N':
+  mangled++;
+  if (*mangled == 'g')
 	{
-	case 'F': case 'U': case 'V':
-	case 'W': case 'R':
-	  return 1;
+	  mangled++;
+	  i = dlang_type_modifier_p (mangled);
+	  return i + 2;
 	}
+}
+
+  return 0;
+}
+
+/* Extract the function calling convention from MANGLED and
+   return 1 on success or 0 on failure.  */
+static int
+dlang_call_convention_p (const char *mangled)
+{
+  /* Prefix for functions needing 'this' */
+  if (*mangled == 'M')
+{
+  mangled++;
+  /* Also skip over any type modifiers.  */
+  mangled += dlang_type_modifier_p (mangled);
+}
+
+  switch (*mangled)
+{
+case 'F': case 'U': case 'V':
+case 'W': case 'R':
+  return 1;
 
 default:
   return 0;
@@ -1178,11 +1254,16 @@ dlang_parse_symbol (string *decl, const char *mangled)
 
   if (mangled && dlang_call_convent

Re: [PATCH 3/7] [D] libiberty: Include type modifiers in demangled function symbols

[Iain Buclaw]

On 13 May 2015 at 22:34, Iain Buclaw  wrote:
> On 13 May 2015 at 10:51, Iain Buclaw  wrote:
>> Like C++ const and volatile, in D mangled symbols can exist modifiers
>> that represent the const, immutable, inout and shared-ness of the
>> 'this' parameter.
>>
>> This information should be written out in the demangled symbol to show
>> that each variant has a unique identity.
>>
>> ---
>> libiberty/ChangeLog:
>>
>> 2015-05-13 Iain Buclaw  
>> * d-demangle.c (dlang_type_modifiers): New function.
>> (dlang_type_modifier_p): New function.
>> (dlang_call_convention_p): Ignore any kind of type modifier.
>> (dlang_type): Handle and emit the type modifier after delegate types.
>> (dlang_parse_symbol): Handle and emit the type modifier after the symbol.
>> * testsuite/d-demangle-expected: Add coverage tests for all valid
>> usages of function symbols with type modifiers.
>
> Somehow in the small morning rush, I missed some extra coverage tests
> in the patch, corrected in this new patch.

Ah, wrong file.  This explains everything (sorry for the added noise :)

Iain
From 47c8e0f723f35e89c90c3d9d88feae9fdd395279 Mon Sep 17 00:00:00 2001
From: Iain Buclaw 
Date: Mon, 11 May 2015 09:20:55 +0200
Subject: [PATCH 3/7] D demangle: Include type modifiers in demangled function
 symbols

---
 libiberty/d-demangle.c  | 111 
 libiberty/testsuite/d-demangle-expected |  64 ++
 2 files changed, 162 insertions(+), 13 deletions(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 91c6d55..bfad5bb 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -215,6 +215,44 @@ dlang_call_convention (string *decl, const char *mangled)
   return mangled;
 }
 
+/* Extract the type modifiers from MANGLED and append them to DECL.
+   Returns the remaining signature on success or NULL on failure.  */
+static const char *
+dlang_type_modifiers (string *decl, const char *mangled)
+{
+  if (mangled == NULL || *mangled == '\0')
+return NULL;
+
+  switch (*mangled)
+{
+case 'x': /* const */
+  mangled++;
+  string_append (decl, " const");
+  return mangled;
+case 'y': /* immutable */
+  mangled++;
+  string_append (decl, " immutable");
+  return mangled;
+case 'O': /* shared */
+  mangled++;
+  string_append (decl, " shared");
+  return dlang_type_modifiers (decl, mangled);
+case 'N':
+  mangled++;
+  if (*mangled == 'g') /* wild */
+	{
+	  mangled++;
+	  string_append (decl, " inout");
+	  return dlang_type_modifiers (decl, mangled);
+	}
+  else
+	return NULL;
+
+default:
+  return mangled;
+}
+}
+
 /* Demangle the D function attributes from MANGLED and append it to DECL.
Return the remaining string on success or NULL on failure.  */
 static const char *
@@ -476,10 +514,22 @@ dlang_type (string *decl, const char *mangled)
   mangled++;
   return dlang_parse_symbol (decl, mangled);
 case 'D': /* delegate T */
+{
+  string mods;
+  size_t szmods;
   mangled++;
+
+  string_init (&mods);
+  mangled = dlang_type_modifiers (&mods, mangled);
+  szmods = string_length (&mods);
+
   mangled = dlang_function_type (decl, mangled);
   string_append (decl, "delegate");
+  string_appendn (decl, mods.b, szmods);
+
+  string_delete (&mods);
   return mangled;
+}
 case 'B': /* tuple T */
   mangled++;
   return dlang_parse_tuple (decl, mangled);
@@ -1135,28 +1185,54 @@ dlang_value (string *decl, const char *mangled, const char *name, char type)
   return mangled;
 }
 
+/* Extract the type modifiers from MANGLED and return the string
+   length that it consumes in MANGLED on success or 0 on failure.  */
 static int
-dlang_call_convention_p (const char *mangled)
+dlang_type_modifier_p (const char *mangled)
 {
-  size_t i;
+  int i;
 
   switch (*mangled)
 {
-case 'F': case 'U': case 'V':
-case 'W': case 'R':
+case 'x': case 'y':
   return 1;
 
-case 'M': /* Prefix for functions needing 'this' */
-  i = 1;
-  if (mangled[i] == 'x')
-	i++;
+case 'O':
+  mangled++;
+  i = dlang_type_modifier_p (mangled);
+  return i + 1;
 
-  switch (mangled[i])
+case 'N':
+  mangled++;
+  if (*mangled == 'g')
 	{
-	case 'F': case 'U': case 'V':
-	case 'W': case 'R':
-	  return 1;
+	  mangled++;
+	  i = dlang_type_modifier_p (mangled);
+	  return i + 2;
 	}
+}
+
+  return 0;
+}
+
+/* Extract the function calling convention from MANGLED and
+   return 1 on success or 0 on failure.  */
+static int
+dlang_call_convention_p (const char *mangled)
+{
+  /* Prefix for functions needing 'this' */
+  if (*mangled == 'M')
+{
+  mangled++;
+  /* Also skip over any type modifiers.  */
+  mangled += dlang_type_modifier_p (mangled);
+}
+
+  switch (*mangled)
+{
+case 'F': case 'U': case 'V':
+case 'W': case 'R':
+  return

[gomp4] Assorted OpenACC changes (was: Next set of OpenACC changes)

[Thomas Schwinge]

Hi!

On Mon, 11 May 2015 18:35:12 +0200, I wrote:
> On Tue, 05 May 2015 10:54:02 +0200, I wrote:
> > In follow-up messages, I'll be posting the separated parts (for easier
> > review) of a next set of OpenACC changes that we'd like to commit.
> > ChangeLog updates not yet written; will do that before commit, obviously.
> 
> In order for us to be able to make progress with staging our other
> OpenACC changes in gomp-4_0-branch, I have now committed to
> gomp-4_0-branch r223007, which is these patches as posted plus a tiny
> last-minute typo fix (see below), and we shall then work on addressing
> the review comments already provided (thanks!) (as well as those which I
> found myself, upon reviewing our changes), before later re-submitting for
> trunk.

In a similar vein, I have now committed the following to gomp-4_0-branch
in r223178.  This is not meant to be integrated into trunk as-is: there
are incompatible libgomp ABI changes, for example.  We'd still appreciate
any review comments, of course.

To avoid running into mailing list size limits, the patch is attached as
gcc-gomp-4_0-branch-r223178.patch.gz, so here's just the commit log:

commit 631438a29e8d275570ba2e881ffcdea2dfe7b5e1
Author: tschwinge 
Date:   Wed May 13 20:25:48 2015 +

Assorted OpenACC changes

gcc/ada/
* gcc-interface/utils.c (DEF_FUNCTION_TYPE_VAR_11): Remove.
(DEF_FUNCTION_TYPE_VAR_12): New macro.
gcc/c-family/
* c-common.c (DEF_FUNCTION_TYPE_VAR_11): Remove.
(DEF_FUNCTION_TYPE_VAR_12): New macro.
gcc/c/
* c-parser.c (c_parser_oacc_data_clause, oacc_split_loop_clauses)
(c_parser_oacc_parallel): Handle PRAGMA_OACC_CLAUSE_FIRSTPRIVATE.
(c_parser_oacc_all_clauses): Update handling of
PRAGMA_OACC_CLAUSE_FIRSTPRIVATE.
* c-typeck.c (c_finish_omp_clauses): Add error checking for
GOMP_MAP_FORCE_TO_GANGLOCAL.
gcc/cp/
* parser.c (cp_parser_oacc_data_clause)
(cp_parser_oacc_all_clauses, oacc_split_loop_clauses)
(cp_parser_oacc_parallel): Handle PRAGMA_OACC_CLAUSE_FIRSTPRIVATE.
* semantics.c (finish_omp_clauses): Add error checking for
GOMP_MAP_FORCE_TO_GANGLOCAL.
gcc/fortran/
* f95-lang.c (DEF_FUNCTION_TYPE_VAR_11): Remove.
(DEF_FUNCTION_TYPE_VAR_12): New macro.
* gfortran.h (gfc_omp_map_op): Add OMP_MAP_GANGLOCAL,
OMP_MAP_FORCE_TO_GANGLOCAL.
* trans-openmp.c (gfc_trans_omp_clauses): Handle them.
* openmp.c (gfc_match_omp_clauses): Update handling of
OMP_CLAUSE_FIRSTPRIVATE.
* types.def
(BT_FN_VOID_INT_OMPFN_SIZE_PTR_PTR_PTR_INT_INT_INT_INT_INT_VAR):
Remove.
(BT_FN_INT_INT_INT_INT)
(BT_FN_VOID_INT_OMPFN_SIZE_PTR_PTR_PTR_INT_INT_INT_SIZE_INT_INT_VAR):
New function types.
gcc/jit/
* jit-builtins.c (DEF_FUNCTION_TYPE_VAR_11): Remove.
(DEF_FUNCTION_TYPE_VAR_12): New macro.
* jit-builtins.h (DEF_FUNCTION_TYPE_VAR_11): Remove.
(DEF_FUNCTION_TYPE_VAR_12): New macro.
gcc/lto/
* lto-lang.c (DEF_FUNCTION_TYPE_VAR_11): Remove.
(DEF_FUNCTION_TYPE_VAR_12): New macro.
gcc/testsuite/
* c-c++-common/goacc/dtype-1.c: Update.
* c-c++-common/goacc/dtype-2.c: Likewise.
* c-c++-common/goacc/host_data-1.c: Likewise.
* c-c++-common/goacc/host_data-2.c: Likewise.
* c-c++-common/goacc/host_data-3.c: Likewise.
* c-c++-common/goacc/host_data-4.c: Likewise.
* c-c++-common/goacc/sb-3.c: Likewise.
* c-c++-common/goacc/tile.c: Likewise.
* g++.dg/goacc/template-reduction.C: Likewise.
* g++.dg/goacc/template.C: Likewise.
* gfortran.dg/goacc/coarray.f95: Likewise.
* gfortran.dg/goacc/dtype-1.f95: Likewise.
* gfortran.dg/goacc/host_data-tree.f95: Likewise.
* gfortran.dg/goacc/list.f95: Likewise.
* gfortran.dg/goacc/loop-tree-1.f90: Likewise.
* gfortran.dg/goacc/parallel-tree.f95: Likewise.
* c-c++-common/goacc/executeables-1.c: New file.
* c-c++-common/goacc/firstprivate.c: Likewise.
* c-c++-common/goacc/private-reduction-1.c: Likewise.
* g++.dg/goacc/loop-1.c: Likewise.
* g++.dg/goacc/loop-2.c: Likewise.
* g++.dg/goacc/loop-3.c: Likewise.
* gcc.dg/goacc/sb-1.c: Likewise.
* gcc.dg/goacc/sb-2.c: Likewise.
* gcc.dg/goacc/sb-3.c: Likewise.
* gfortran.dg/goacc/firstprivate-1.f95: Likewise.
gcc/
* builtin-types.def
(BT_FN_VOID_INT_OMPFN_SIZE_PTR_PTR_PTR_INT_INT_INT_INT_INT_VAR):
Remove.
(BT_FN_INT_INT_INT_INT)
(BT_FN_VOID_INT_OMPFN_SIZE_PTR_PTR_PTR_INT_INT_INT_SIZE_INT_INT_VAR):
New function types.
* builtins.c (expand_oacc_builtin, expand_oacc_ganglocal_ptr): New
functions.
(expand_builtin, is_simple_builtin): Use them.
* config/nvptx/mkoffload.c (pro

[gomp4] Prohibit C++ reference types in OpenACC regions

[Thomas Schwinge]

Hi!

On Wed, 29 Apr 2015 09:27:49 -0700, Cesar Philippidis 
 wrote:
> This patch teaches the c++ front end to error when reference typed
> variables are used in openacc parallel and kernels regions. The c++
> front end changes are pretty straightforward. I did, however, have to
> make omp_mappable_type langhook aware of openacc. That's because openmp
> apparently supports reference types, whereas openacc does not. I guess
> aliased mapping isn't a problem for non-openmp target regions.

Committed to gomp-4_0-branch in r223179:

commit ee20456534e0fd80333e50bab0821a0e20f065e5
Author: tschwinge 
Date:   Wed May 13 20:56:31 2015 +

Prohibit C++ reference types in OpenACC regions

gcc/
* langhooks-def.h (lhd_omp_mappable_type): Add bool argument.
* langhooks.c (lhd_omp_mappable_type): Likewise, for the
parameter.
* langhooks.h (struct lang_hooks_for_types): Add bool oacc
argument.
* gimplify.c (omp_notice_variable): Use it when calling the
omp_mappable_type langhook.
gcc/c/
* c-decl.c (c_decl_attributes): Update call to omp_mappable_type.
* c-typeck.c (c_finish_omp_clauses): Likewise.
gcc/cp/
* cp-tree.h (cp_omp_mappable_type): Add bool parameter.
* decl2.c (cp_check_const_attributes): Likewise. Use it.
(cp_omp_mappable_type): Update call to cp_omp_mappable_type.
(cplus_decl_attributes): Likewise.
* semantics.c (finish_omp_clauses): Likewise.
gcc/testsuite/
* g++.dg/goacc/reference.C: New test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@223179 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog.gomp | 10 
 gcc/c/ChangeLog.gomp   |  5 
 gcc/c/c-decl.c |  3 ++-
 gcc/c/c-typeck.c   |  6 +++--
 gcc/cp/ChangeLog.gomp  |  8 +++
 gcc/cp/cp-tree.h   |  2 +-
 gcc/cp/decl2.c |  8 ---
 gcc/cp/semantics.c | 11 ++---
 gcc/gimplify.c |  4 +++-
 gcc/langhooks-def.h|  2 +-
 gcc/langhooks.c|  2 +-
 gcc/langhooks.h|  2 +-
 gcc/testsuite/ChangeLog.gomp   |  4 
 gcc/testsuite/g++.dg/goacc/reference.C | 42 ++
 14 files changed, 95 insertions(+), 14 deletions(-)

diff --git gcc/ChangeLog.gomp gcc/ChangeLog.gomp
index 4901bf9..9e72962 100644
--- gcc/ChangeLog.gomp
+++ gcc/ChangeLog.gomp
@@ -1,3 +1,13 @@
+2015-05-13  Cesar Philippidis  
+
+   * langhooks-def.h (lhd_omp_mappable_type): Add bool argument.
+   * langhooks.c (lhd_omp_mappable_type): Likewise, for the
+   parameter.
+   * langhooks.h (struct lang_hooks_for_types): Add bool oacc
+   argument.
+   * gimplify.c (omp_notice_variable): Use it when calling the
+   omp_mappable_type langhook.
+
 2015-05-13  Thomas Schwinge  
Bernd Schmidt  
Cesar Philippidis  
diff --git gcc/c/ChangeLog.gomp gcc/c/ChangeLog.gomp
index 2e3cd13..08c8ed0 100644
--- gcc/c/ChangeLog.gomp
+++ gcc/c/ChangeLog.gomp
@@ -1,3 +1,8 @@
+2015-05-13  Cesar Philippidis  
+
+   * c-decl.c (c_decl_attributes): Update call to omp_mappable_type.
+   * c-typeck.c (c_finish_omp_clauses): Likewise.
+
 2015-05-13  Thomas Schwinge  
Bernd Schmidt  
Cesar Philippidis  
diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 4f6761d..bf99a45 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -4414,7 +4414,8 @@ c_decl_attributes (tree *node, tree attributes, int flags)
error ("%q+D in block scope inside of declare target directive",
   *node);
   else if (TREE_CODE (*node) == VAR_DECL
-  && !lang_hooks.types.omp_mappable_type (TREE_TYPE (*node)))
+  && !lang_hooks.types.omp_mappable_type (TREE_TYPE (*node),
+  false))
error ("%q+D in declare target directive does not have mappable type",
   *node);
   else
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 5ec04cc..974a3fc 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -12445,7 +12445,8 @@ c_finish_omp_clauses (tree clauses, bool oacc)
  else
{
  t = OMP_CLAUSE_DECL (c);
- if (!lang_hooks.types.omp_mappable_type (TREE_TYPE (t)))
+ if (!lang_hooks.types.omp_mappable_type (TREE_TYPE (t),
+  oacc))
{
  error_at (OMP_CLAUSE_LOCATION (c),
"array section does not have mappable type "
@@ -12478,7 +12479,8 @@ c_finish_omp_clauses (tree clauses, bool oacc)
 && (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_POINTER
 || (OMP_CLAUSE_MAP_KIND 

[gomp4] Prohibit exceptions in OpenACC regions

[Thomas Schwinge]

Hi!

On Tue, 14 Apr 2015 17:01:23 -0700, Cesar Philippidis 
 wrote:
> This patch addresses the SjLj compile time failures, typically
> associated with routine calls in c++. My solution to this problem is to
> introduce a new "oacc function" attribute and prevent
> finish_eh_generation from inserting any EH code for functions marked
> with those attributes. I was thinking about creating a new target
> machine hook to selectively disable EH for targets which don't support
> it. However, I figured openacc acc shouldn't generate exceptions so I
> went with the attribute approach.
> 
> For those curious, I chose the name "oacc function" for the attribute
> because it gets attached to both parallel/kernels regions and acc routines.

Committed to gomp-4_0-branch in r223180:

commit 92c8a16805acc367b81f89ada760e136b5f7eab1
Author: tschwinge 
Date:   Wed May 13 21:00:33 2015 +

Prohibit exceptions in OpenACC regions

gcc/
* except.c (finish_eh_generation): Don't finalize exeception
handlers for functions containing the "oacc function" attribute.
* omp-low.c (create_omp_child_function): Add an "oacc function"
attribute to acc regions.
gcc/c-family/
* c-common.c (c_common_attribute_table): Add an "oacc function"
attribute.
gcc/c/
* c-parser.c (c_finish_oacc_routine): Add an "oacc function"
attribute to routines.
gcc/cp/
* parser.c (cp_parser_late_parsing_oacc_routine): Add an
"oacc function" attribute to routines.
gcc/fortran/
* f95-lang.c (gfc_attribute_table): Add and "oacc function"
attribute.
* gfortran.h (symbol_attribute): Add oacc_function bit.
* openmp.c (gfc_match_oacc_routine): Use it.
* trans-decl.c (add_attributes_to_decl): Lower it.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/routine-1.c: Remove
-fno-exceptions.
* testsuite/libgomp.oacc-c-c++-common/routine-2.c: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@223180 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog.gomp  | 5 +
 gcc/c-family/ChangeLog.gomp | 5 +
 gcc/c-family/c-common.c | 1 +
 gcc/c/ChangeLog.gomp| 3 +++
 gcc/c/c-parser.c| 4 +++-
 gcc/cp/ChangeLog.gomp   | 3 +++
 gcc/cp/parser.c | 1 +
 gcc/except.c| 4 
 gcc/fortran/ChangeLog.gomp  | 8 
 gcc/fortran/f95-lang.c  | 6 --
 gcc/fortran/gfortran.h  | 3 +++
 gcc/fortran/openmp.c| 1 +
 gcc/fortran/trans-decl.c| 4 
 gcc/omp-low.c   | 6 ++
 libgomp/ChangeLog.gomp  | 6 ++
 libgomp/testsuite/libgomp.oacc-c-c++-common/routine-1.c | 4 ++--
 libgomp/testsuite/libgomp.oacc-c-c++-common/routine-2.c | 4 ++--
 17 files changed, 61 insertions(+), 7 deletions(-)

diff --git gcc/ChangeLog.gomp gcc/ChangeLog.gomp
index 9e72962..a4683c3 100644
--- gcc/ChangeLog.gomp
+++ gcc/ChangeLog.gomp
@@ -1,5 +1,10 @@
 2015-05-13  Cesar Philippidis  
 
+   * except.c (finish_eh_generation): Don't finalize exeception
+   handlers for functions containing the "oacc function" attribute.
+   * omp-low.c (create_omp_child_function): Add an "oacc function"
+   attribute to acc regions.
+
* langhooks-def.h (lhd_omp_mappable_type): Add bool argument.
* langhooks.c (lhd_omp_mappable_type): Likewise, for the
parameter.
diff --git gcc/c-family/ChangeLog.gomp gcc/c-family/ChangeLog.gomp
index 3e01b28..9f999cd 100644
--- gcc/c-family/ChangeLog.gomp
+++ gcc/c-family/ChangeLog.gomp
@@ -1,3 +1,8 @@
+2015-05-13  Cesar Philippidis  
+
+   * c-common.c (c_common_attribute_table): Add an "oacc function"
+   attribute.
+
 2015-05-13  Thomas Schwinge  
Bernd Schmidt  
Cesar Philippidis  
diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 5835517..c6e15fc 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -824,6 +824,7 @@ const struct attribute_spec c_common_attribute_table[] =
   { "bnd_instrument", 0, 0, true, false, false,
  handle_bnd_instrument, false },
   { "oacc declare",   0, -1, true,  false, false, NULL, false },
+  { "oacc function",  0, 0, true,  false, false, NULL, false },
   { NULL, 0, 0, false, false, false, NULL, false }
 };
 
diff --git gcc/c/ChangeLog.gomp gcc/c/ChangeLog.gomp
index 08c8ed0..c99f29d 100644
--- gcc/c/ChangeLog.gomp
+++ gcc/c/ChangeLog.gomp
@@ -1,5 +1,

[PATCH 8/7] [D] libiberty: Add support for specialized template parameters

[Iain Buclaw]

One last thing that was added in the next D version's ABI (and I
subsequently missed).

This is a trivial patch to just ignore the new mangle symbol.

---
libiberty/ChangeLog:

2015-05-13 Iain Buclaw  

* d-demangle.c (dlang_template_args): Skip over specialized template
parameters in mangled symbol.
* testsuite/d-demangle-expected: Add coverage and unittest for specialized
template parameters.
---
 libiberty/d-demangle.c  | 4 
 libiberty/testsuite/d-demangle-expected | 8 
 2 files changed, 12 insertions(+)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 5c0f356..833f87a 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -1486,6 +1486,10 @@ dlang_template_args (string *decl, const char *mangled)
   if (n++)
 	string_append (decl, ", ");
 
+  /* Skip over specialised template prefix.  */
+  if (*mangled == 'H')
+	mangled++;
+
   switch (*mangled)
 	{
 	case 'S': /* Symbol parameter.  */
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 47746da..992ea4a 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -630,6 +630,10 @@ _D8demangle19__T4testS6symbolTaZv
 demangle.test!(symbol, char)
 #
 --format=dlang
+_D8demangle12__T4testHTaZv
+demangle.test!(char)
+#
+--format=dlang
 _D8demangle13__T4testVPinZv
 demangle.test!(null)
 #
@@ -1074,3 +1078,7 @@ std.traits.fqnSym!(std).adjustIdent(immutable(char)[])
 --format=dlang
 _D2rt8lifetime36__T14_d_newarrayOpTS13_d_newarrayiTZ14_d_newarrayOpTFNaNbxC8TypeInfomPmZAv
 rt.lifetime._d_newarrayOpT!(_d_newarrayiT)._d_newarrayOpT(const(TypeInfo), ulong, ulong*)
+#
+--format=dlang
+_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
+gc.config.parse!(float).parse(const(char)[], ref const(char)[], ref float)
-- 
2.1.0

[gomp4] Basic -misa support for nvptx (was: How to use old GPU (Fermi) in gcc with OpenACC?)

[Thomas Schwinge]

Hi!

On Sat, 9 May 2015 10:26:22 -0700, Satoshi_OHSHIMA  
wrote:
> I'm trying to use and evaluate gcc with OpenACC on some NVIDIA GPUs.
> I succeeded to build gcc with OpenACC by using
> http://scelementary.com/2015/04/25/openacc-in-gcc.html as a reference.

Heh, their build instructions very much look like the ones I provided in
:
trunk-offload-big.tar.bz2, trunk-offload-light.tar.bz2 (no problem with
them reusing these, of course).

> Then, I succeeded to use Kepler GPU.

:-)

> However, I tried to use it on old GPUs (Fermi), and I failed to execute it.
> I noticed that there are some "sm_30" and "COMPUTE_30" keywords in gcc and
> nvptx sources.
> Then, I modified them to "sm_20" and "COMPUTE_20", but I failed to execute
> my programs, too.
> Are there any developers who can make gcc with OpenACC to support other than
> "sm_30"?

"Can", yes, but this is unlikely to happen: a nontrivial amount of work
would be required to get the current code (and, in particular, our
patches under development) working on what nowadays is probably
considered "legacy" hardware.  (For example, if I remember correctly,
didn't Nvidia remove support for Fermi-class hardware from recent CUDA
toolkit releases?)

However, I committed the following patch to gomp-4_0-branch in r223182,
and you're of course very welcome to follow that route, and contribute
patches to properly conditionalize the respective PTX instructions,
provide replacement functions, and so on, in gcc/config/nvptx/nvptx.md,
libgcc/config/nvptx/, and probably other locations.

To use this patch, you'll also need to update your nvptx-tools sources.

commit 29001da9572e094164e1fca440925fafbceb67f2
Author: tschwinge 
Date:   Wed May 13 21:25:42 2015 +

Basic -misa support for nvptx

gcc/
* config/nvptx/nvptx-opts.h: New file.
* config/nvptx/nvptx.c (nvptx_file_start): Print the correct .target.
* config/nvptx/nvptx.h: Include "nvptx-opts.h".
(ASM_SPEC): Define.
(TARGET_SM35): New macro.
* config/nvptx/nvptx.md (atomic_fetch_): Enable with the
correct predicate.
* config/nvptx/nvptx.opt (ptx_isa, sm_30, sm_35): New enum and its
values.
(misa=): New option.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@223182 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog.gomp| 13 +
 gcc/config/nvptx/nvptx-opts.h | 31 +++
 gcc/config/nvptx/nvptx.c  |  5 -
 gcc/config/nvptx/nvptx.h  |  8 
 gcc/config/nvptx/nvptx.md |  3 +--
 gcc/config/nvptx/nvptx.opt| 14 ++
 6 files changed, 71 insertions(+), 3 deletions(-)

diff --git gcc/ChangeLog.gomp gcc/ChangeLog.gomp
index a4683c3..f43f668 100644
--- gcc/ChangeLog.gomp
+++ gcc/ChangeLog.gomp
@@ -1,3 +1,16 @@
+2015-05-13  Bernd Schmidt  
+
+   * config/nvptx/nvptx-opts.h: New file.
+   * config/nvptx/nvptx.c (nvptx_file_start): Print the correct .target.
+   * config/nvptx/nvptx.h: Include "nvptx-opts.h".
+   (ASM_SPEC): Define.
+   (TARGET_SM35): New macro.
+   * config/nvptx/nvptx.md (atomic_fetch_): Enable with the
+   correct predicate.
+   * config/nvptx/nvptx.opt (ptx_isa, sm_30, sm_35): New enum and its
+   values.
+   (misa=): New option.
+
 2015-05-13  Cesar Philippidis  
 
* except.c (finish_eh_generation): Don't finalize exeception
diff --git gcc/config/nvptx/nvptx-opts.h gcc/config/nvptx/nvptx-opts.h
new file mode 100644
index 000..512c37a
--- /dev/null
+++ gcc/config/nvptx/nvptx-opts.h
@@ -0,0 +1,31 @@
+/* Definitions for the NVPTX port needed for option handling.
+   Copyright (C) 2015 Free Software Foundation, Inc.
+   Contributed by Bernd Schmidt 
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#ifndef NVPTX_OPTS_H
+#define NVPTX_OPTS_H
+
+enum ptx_isa
+{
+  PTX_ISA_SM30,
+  PTX_ISA_SM35
+};
+
+#endif
+
diff --git gcc/config/nvptx/nvptx.c gcc/config/nvptx/nvptx.c
index 10ac976..9bec12f 100644
--- gcc/config/nvptx/nvptx.c
+++ gcc/config/nvptx/nvptx.c
@@ -2048,7 +2048,10 @@ nvptx_file_start (void)
 {
   fputs ("// BEGIN PREAMBLE\n", asm_out_file);
   fputs ("\t.version\t3.1\n", asm_out_file);
-  fputs ("\t.target\tsm_30\n", asm_out_file);
+  if (TARGET_SM35)
+fput

[gomp4] libgomp: Cope with DejaGnu having no mechanism to transfer environment variables to remote boards

[Thomas Schwinge]

Hi!

On Fri, 24 Oct 2014 00:18:10 +0200, I wrote:
> On Thu, 23 Oct 2014 17:02:20 +0200, I wrote:
> > On Fri, 16 May 2014 20:01:47 +0200, I wrote:
> > > On Fri, 16 May 2014 19:02:41 +0200, Tom de Vries  
> > > wrote:
> > > > Essentially I want to run the set of testcases in libgomp.oacc-c, 
> > > > similar to how
> > > > it is done in libgomp.oacc-c/c.exp, with the environment variable
> > > > ACC_DEVICE_TYPE set to host for the executable.
> > > 
> > > Thanks for working on this; indeed the idea is that we run the libgomp
> > > execution tests is as many configurations as possible -- sort of how
> > > certain classes of GCC tests are run for many different compiler options
> > > (optimization levels).  I suggest this to be implemented in the existing
> > > libgomp.*/*.exp files, by setting up some suitable looping over all
> > > supported accelerator targets (currently just the one GCC has been
> > > configured with) as well as host fallback, with suitable tags being added
> > > to the PASS/FAIL lines.  It appears to make sense to first separate any
> > > libgomp tests that test "traditional" OpenMP shared-memory, so don't run
> > > on acceleration devices; these of course only need to be run once.
> > > 
> > > > I'm not sure setenv is guaranteed to work.
> > 
> > Indeed that does not work for non-native testing, which is what we're
> > doing [...]...  That means, we can't do any testing of
> > offloading -- which is "a bit" unfortunate.

> > > > I found this related discussion:
> > > > http://marc.info/?t=12162271871&r=1&w=2 .
> > > 
> > > Is it just the shell quoting issue that remains?  That's fixable.
> > 
> > Instead of going this route (the approach has later been disputed
> > upstream), I cooked up something else.  This is clearly a hack, and I
> > hope to get rid of that as soon as possible.  But it works.
> 
> Here it is.  Don't look closely -- you've been warned.  My hope is that
> we'll be able to get rid of that rather sooner than later:
> [...] for this use of ACC_DEVICE_TYPE, I hope that soon we'll
> get a compiler option to specify the default offloading device.  (Intel
> are working into this direction, upstream, -foffload=[...].)

(That -foffload=[...] option exists, but we're not yet (able) to use it
as desired.)  See also the discussion in
,
,
and so on.

> Until then: committed [...], with disgust.

Until then: committed to gomp-4_0-branch in r223185, with disgust.

commit 5803a3376041706672baede225a2dc47d70dd9a1
Author: tschwinge 
Date:   Wed May 13 22:07:27 2015 +

libgomp: Cope with DejaGnu having no mechanism to transfer environment 
variables to remote boards

No doubt, looking forward to the day, when this can be reverted.

libgomp/
* env.c (initialize_env): Remove static attribute.
* libgomp.map (INTERNAL): Export initialize_env.
* testsuite/lib/libgomp.exp (libgomp_init): Build a few object
files to pre-set environment variables.
(ALWAYS_CFLAGS): Add constructor-setenv-defaults.o to ldflags.
(libgomp_target_compile): Don't set the compiler.
* testsuite/libgomp.c++/c++.exp (GXX_UNDER_TEST): Provide default.
(libgomp_compile_options): Set the compiler.
* testsuite/libgomp.c/c.exp (libgomp_compile_options): Set the
compiler.
* testsuite/libgomp.fortran/fortran.exp (GFORTRAN_UNDER_TEST):
Provide default.
(libgomp_compile_options): Set the compiler.
* testsuite/libgomp.graphite/graphite.exp
(libgomp_compile_options): Set the compiler.
* testsuite/libgomp.oacc-c++/c++.exp (SAVE_GCC_UNDER_TEST)
(GCC_UNDER_TEST): Don't set.
(GXX_UNDER_TEST): Provide default.
(libgomp_compile_options): Set the compiler.
(ALWAYS_CFLAGS): Add the respective
constructor-setenv-ACC_DEVICE_TYPE-$offload_target_openacc.o to
ldflags.
(ACC_DEVICE_TYPE): Don't set.
* testsuite/libgomp.oacc-c/c.exp (libgomp_compile_options): Set
the compiler.
(ALWAYS_CFLAGS): Add the respective
constructor-setenv-ACC_DEVICE_TYPE-$offload_target_openacc.o to
ldflags.
(ACC_DEVICE_TYPE): Don't set.
* testsuite/libgomp.oacc-fortran/fortran.exp
(libgomp_compile_options): Set the compiler.
(ALWAYS_CFLAGS): Add the respective
constructor-setenv-ACC_DEVICE_TYPE-$offload_target_openacc.o to
ldflags.
(ACC_DEVICE_TYPE): Don't set.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@223185 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog.gomp | 38 +++
 libgomp/env.c  |  6 ++-
 libgomp/libgomp.map|  6 +++
 libgomp/testsuite/l

Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Joseph Myers]

On Wed, 13 May 2015, Marek Polacek wrote:

> > Rather, how about having an extra argument to c_fully_fold_internal (e.g. 
> > for_int_const) indicating that the folding is of an expression with 
> > integer constant operands (so this argument would be true in the new case 
> > of folding the contents of a C_MAYBE_CONST_EXPR with 
> > C_MAYBE_CONST_EXPR_INT_OPERANDS set)?  In that special case, 
> > c_fully_fold_internal would only fold the expression itself if all 
> > evaluated operands folded to INTEGER_CSTs (so if something that doesn't 
> > get folded, such as division by 0, is encountered, then all evaluated 
> > expressions containing it also don't get folded).
> 
> Did you mean something like the following?  It is on top of the previous
> c_fully_fold_internal patch; if it makes any sense, I'll squash these
> into one.

Yes.  The two patches are OK together, though I think it would be better 
to add for_int_const checks also in the cases of unary operations, &&, || 
and ?: (the last three being cases where it's only the evaluated operands 
that need to fold to INTEGER_CSTs, not any unevaluated operands).  It may 
well be the case that no folding at present can fold any of those cases to 
an INTEGER_CST when it shouldn't be one, but I don't think we should rely 
on that.

> This still doesn't reject enum { A = 0 * (unsigned) (1 / 0) };, but note
> that we don't reject such an enum at present.

It's rejected with -pedantic-errors, but it should indeed be rejected 
unconditionally like the other cases.

Casts can do some optimization prematurely, but I don't know if that has 
anything to do with the non-rejection here.

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

Re: [gomp4] Basic -misa support for nvptx (was: How to use old GPU (Fermi) in gcc with OpenACC?)

[Joseph Myers]

On Wed, 13 May 2015, Thomas Schwinge wrote:

>   * config/nvptx/nvptx.opt (ptx_isa, sm_30, sm_35): New enum and its
>   values.
>   (misa=): New option.

New options do of course need documenting in invoke.texi.

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