Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

[Thomas Preud'homme]

On Wednesday, January 13, 2016 06:39:20 PM Bernd Schmidt wrote:
> On 01/12/2016 08:55 AM, Thomas Preud'homme wrote:
> > On Monday, January 11, 2016 04:57:18 PM Bernd Schmidt wrote:
> >> On 01/08/2016 10:33 AM, Thomas Preud'homme wrote:
> >>> 2016-01-08  Thomas Preud'homme  
> >>> 
> >>>   * g++.dg/pr67989.C: Remove ARM-specific option.
> >>>   * gcc.target/arm/pr67989.C: New file.
> >> 
> >> I checked some other arm tests and they have things like
> >> 
> >> /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
> >> "-march=*" } { "-march=armv4t" } } */
> >> /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
> >> "-mthumb" } { "" } } */
> >> 
> >> Do you need the same in your testcase?
> > 
> > That was the first approach I took but Kyrill suggested me to use
> > arm_arch_v4t and arm_arch_v4t_ok machinery instead. It should take care
> > about whether the architecture can be selected.
> 
> Hmm, the ones I looked at did use dg-add-options, but not the
> corresponding _ok requirement. So I think this is OK.

Just to make sure: ok as in OK to commit as is?

Best regards,

Thomas

[PATCH] Another warning fix in adaint.c

[Jakub Jelinek]

Hi!

Following patch fixes another warning in adaint.c:
../../gcc/ada/adaint.c: In function 'void __gnat_killprocesstree(int, int)':
../../gcc/ada/adaint.c:3284:26: warning: suggest parentheses around assignment 
used as truth value [-Wparentheses]
   while (d = readdir (dir))
  ^

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

2016-01-17  Jakub Jelinek  

* adaint.c (__gnat_killprocesstree): Avoid -Wparentheses warning.

--- gcc/ada/adaint.c.jj 2016-01-15 21:15:09.0 +0100
+++ gcc/ada/adaint.c2016-01-16 10:32:44.133293832 +0100
@@ -3281,7 +3281,7 @@ void __gnat_killprocesstree (int pid, in
 
   /* kill child processes first */
 
-  while (d = readdir (dir))
+  while ((d = readdir (dir)) != NULL)
 {
   if ((d->d_type & DT_DIR) == DT_DIR)
 {


Jakub

[PATCH] Fix a warning in haifa-sched.c

[Jakub Jelinek]

Hi!

During profiledbootstrap, I'm seeing:
../../gcc/system.h: In function 'void autopref_multipass_init(const rtx_insn*, 
int)':
../../gcc/system.h:367:29: warning: 'max_offset' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
 #define MAX(X,Y) ((X) > (Y) ? (X) : (Y))
 ^
../../gcc/haifa-sched.c:5603:11: note: 'max_offset' was declared here
   int max_offset;
   ^~
and similarly for min_offset.  The warning is a false positive just because
the compiler can't know that a PARALLEL should never have zero XVECLEN (pat, 0).
prev_base which is also set during the first iteration and thus not set
if n_elems is 0 already have an initializer for this reason.

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

2016-01-17  Jakub Jelinek  

* haifa-sched.c (autopref_multipass_init): Work around
-Wmaybe-uninitialized warning.

--- gcc/haifa-sched.c.jj2016-01-04 14:55:52.0 +0100
+++ gcc/haifa-sched.c   2016-01-16 11:30:04.782594233 +0100
@@ -5599,8 +5599,8 @@ autopref_multipass_init (const rtx_insn
 
   int i = 0;
   rtx prev_base = NULL_RTX;
-  int min_offset;
-  int max_offset;
+  int min_offset = 0;
+  int max_offset = 0;
 
   for (i = 0; i < n_elems; i++)
{


Jakub

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Torvald Riegel]

On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
> On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek  wrote:
> > On Sat, Jan 16, 2016 at 07:47:33AM -0500, David Edelsohn wrote:
> >> stage1 libstdc++ builds just fine.  the problem is stage2 configure
> >> fails due to missing ITM_xxx symbols when configure tries to compile
> >> and run conftest programs.
> >
> > On x86_64-linux, the _ITM_xxx symbols are undef weak ones and thus it is
> > fine to load libstdc++ without libitm and libstdc++ doesn't depend on
> > libitm.
> >
> > So, is AIX defining __GXX_WEAK__ or not?  Perhaps some other macro or
> > configure check needs to be used to determine if undefined weak symbols
> > work the way libstdc++ needs them to.
> 
> __GXX_WEAK__ appears to be defined by gcc/c-family/c-cppbuiltin.c
> based on  SUPPORTS_ONE_ONLY.  gcc/defaults.h defines SUPPORTS_ONE_ONLY
> if the target supports MAKE_DECL_ONE_ONLY and link-once semantics.
> AIX weak correctly supports link-once semantics.  AIX also supports
> the definition of __GXX_WEAK__ in gcc/doc/cpp.texi, namely collapsing
> symbols with vague linkage in multiple translation units.
> 
> libstdc++/src/c++11/cow-stdexcept.cc appears to be using __GXX_WEAK__
> and __attribute__ ((weak)) for references to symbols that may not be
> defined at link time or run time.  AIX does not allow undefined symbol
> errors by default.  And the libstdc++ inference about the semantics of
> __GXX_WEAK__ are different than the documentation.
> 
> AIX supports MAKE_DECL_ONE_ONLY and the documented meaning of
> __GXX_WEAK__.  AIX does not support extension of the meaning to
> additional SVR4 semantics not specified in the documentation.

I see, so we might be assuming that __GXX_WEAK__ means more than it
actually does (I'm saying "might" because personally, I don't know; your
information supports this is the case, but the initial info I got was
that __GXX_WEAK__ would mean we could have weak decls without
definitions).

The attached patch works around this by always definining stubs for the
libitm functions, yet declaring them weak at the same time.  If
__GXX_WEAK__ is not supplied, the transactional clones aren't built at
all.  This tests fine on x86_64-linux, and I suppose that it should work
on AIX too (but I haven't tested).  Is it harmless if gnu.pre lists
symbols that we don't provide?

Thoughts?
commit 9008d4a610dccb5ec47f9c1e506492b8615a36fd
Author: Torvald Riegel 
Date:   Sun Jan 17 19:21:13 2016 +0100

libstdc++: Fix usage of weak symbols in TM TS support.

diff --git a/libstdc++-v3/src/c++11/cow-stdexcept.cc b/libstdc++-v3/src/c++11/cow-stdexcept.cc
index e2d7e76..8ccc7f5 100644
--- a/libstdc++-v3/src/c++11/cow-stdexcept.cc
+++ b/libstdc++-v3/src/c++11/cow-stdexcept.cc
@@ -179,6 +179,13 @@ _GLIBCXX_END_NAMESPACE_VERSION
 // Furthermore, _Rep will always have been allocated or deallocated via
 // global new or delete, so nontransactional writes we do to _Rep cannot
 // interfere with transactional accesses.
+
+// We require support for weak symbols because we need to call libitm but must
+// not depend on it.  The exception classes will not be declared
+// transaction-safe if there is no such support, so do not create
+// transactional clones in that case at all.
+#ifdef __GXX_WEAK__
+
 extern "C" {
 
 #ifndef _GLIBCXX_MANGLE_SIZE_T
@@ -195,7 +202,6 @@ extern "C" {
 # define ITM_REGPARM
 #endif
 
-#if __GXX_WEAK__
 // Declare all libitm symbols we rely on, but make them weak so that we do
 // not depend on libitm.
 extern void* _ZGTtnaX (size_t sz) __attribute__((weak));
@@ -213,9 +219,10 @@ extern void _ITM_memcpyRnWt(void *, const void *, size_t)
 extern void _ITM_addUserCommitAction(void (*)(void *), uint64_t, void *)
   ITM_REGPARM __attribute__((weak));
 
-#else
-// If there is no support for weak symbols, create dummies.  The exceptions
-// will not be declared transaction_safe in this case.
+// Also create stubs because some targets (e.g., AIX) do not support weak
+// symbols that do not have a definition.  These stubs will not be used
+// (unless users call the transactional clones directly or run transactions
+// without using libitm as well)
 void* _ZGTtnaX (size_t) { return NULL; }
 void _ZGTtdlPv (void*) { }
 uint8_t _ITM_RU1(const uint8_t *) { return 0; }
@@ -224,7 +231,6 @@ uint64_t _ITM_RU8(const uint64_t *) { return 0; }
 void _ITM_memcpyRtWn(void *, const void *, size_t) { }
 void _ITM_memcpyRnWt(void *, const void *, size_t) { }
 void _ITM_addUserCommitAction(void (*)(void *), uint64_t, void *) { };
-#endif
 
 }
 
@@ -440,3 +446,5 @@ CTORDTOR(14overflow_error, std::overflow_error, runtime_error)
 CTORDTOR(15underflow_error, std::underflow_error, runtime_error)
 
 }
+
+#endif  // __GXX_WEAK__

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Jakub Jelinek]

On Sun, Jan 17, 2016 at 09:21:45PM +0100, Torvald Riegel wrote:
> The attached patch works around this by always definining stubs for the
> libitm functions, yet declaring them weak at the same time.  If

This doesn't look like a good idea.  The dynamic linker doesn't make
difference between weak and non-weak definitions, only ld(1) does,
so if for whatever reason libstdc++ appears earlier in the search scope than
libitm, TM programs would stop working because of this.

Jakub

Re: [PATCH] Another warning fix in adaint.c

[Arnaud Charlet]

> Following patch fixes another warning in adaint.c:
> ../../gcc/ada/adaint.c: In function 'void
> __gnat_killprocesstree(int, int)':
> ../../gcc/ada/adaint.c:3284:26: warning: suggest parentheses around
> assignment used as truth value [-Wparentheses]
>while (d = readdir (dir))
>   ^
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?

Yes, thanks.

> 2016-01-17  Jakub Jelinek  
> 
>   * adaint.c (__gnat_killprocesstree): Avoid -Wparentheses warning.

Re: [PATCH, i386] Support ANDN in stv pass

[Uros Bizjak]

On Fri, Jan 15, 2016 at 4:46 PM, Ilya Enkovich  wrote:
> Hi,
>
> This patch continues resolving andn regression case in stv pass
> (see https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01017.html).
> In this patch a new andn pattern added similar to other bit
> DI patterns we have for stv pass.
>
> This improves performance of 462.libquantum benchmark on Haswell
> (+2.6% on -O2, +1% on -O3 -flto).
>
> Unfortunately this patch doesn't enable generation of pandn in case
> target doesn't have BMI.  Probably peephole may be used for such targets?
> Or we may allow andn and then split it back to and + xor for them.

IMO, we want a splitter here. We should optimize compiler for newer targets.

> Bootstrapped and regtested on x86_64-unknown-linux-gnu.  OK for trunk?
>
> Thanks,
> Ilya
> --
> gcc/
>
> 2016-01-15  Ilya Enkovich  
>
> * config/i386/i386.c (scalar_to_vector_candidate_p): Support
> andnot instruction.
> (scalar_chain::convert_op): Likewise.
> * config/i386/i386.md (*andndi3_doubleword): New.
>
> gcc/testsuite/
>
> 2016-01-15  Ilya Enkovich  
>
> * gcc.target/i386/pr65105-5.c: Adjust to andn generation.

OK for mainline.

Thanks,
Uros.

>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index de41477..a0b0d68 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2815,7 +2815,11 @@ scalar_to_vector_candidate_p (rtx_insn *insn)
>return false;
>  }
>
> -  if (!REG_P (XEXP (src, 0)) && !MEM_P (XEXP (src, 0)))
> +  if (!REG_P (XEXP (src, 0)) && !MEM_P (XEXP (src, 0))
> +  /* Check for andnot case.  */
> +  && (GET_CODE (src) != AND
> + || GET_CODE (XEXP (src, 0)) != NOT
> + || !REG_P (XEXP (XEXP (src, 0), 0
>return false;
>
>if (!REG_P (XEXP (src, 1)) && !MEM_P (XEXP (src, 1)))
> @@ -3383,7 +3387,12 @@ scalar_chain::convert_op (rtx *op, rtx_insn *insn)
>  {
>*op = copy_rtx_if_shared (*op);
>
> -  if (MEM_P (*op))
> +  if (GET_CODE (*op) == NOT)
> +{
> +  convert_op ( (*op, 0), insn);
> +  PUT_MODE (*op, V2DImode);
> +}
> +  else if (MEM_P (*op))
>  {
>rtx tmp = gen_reg_rtx (DImode);
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 71941d0..f16b42a 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -8645,6 +8645,23 @@
>   (clobber (reg:CC FLAGS_REG))])]
>"split_double_mode (DImode, [0], 3, [0], [3]);")
>
> +(define_insn_and_split "*andndi3_doubleword"
> +  [(set (match_operand:DI 0 "register_operand" "=r,r")
> +   (and:DI
> + (not:DI (match_operand:DI 1 "register_operand" "r,r"))
> + (match_operand:DI 2 "nonimmediate_operand" "r,m")))
> +   (clobber (reg:CC FLAGS_REG))]
> +  "TARGET_BMI && !TARGET_64BIT && TARGET_STV && TARGET_SSE"
> +  "#"
> +  "&& reload_completed"
> +  [(parallel [(set (match_dup 0)
> +  (and:SI (not:SI (match_dup 1)) (match_dup 2)))
> + (clobber (reg:CC FLAGS_REG))])
> +   (parallel [(set (match_dup 3)
> +  (and:SI (not:SI (match_dup 4)) (match_dup 5)))
> + (clobber (reg:CC FLAGS_REG))])]
> +  "split_double_mode (DImode, [0], 3, [0], [3]);")
> +
>  (define_insn "*hi_1"
>[(set (match_operand:HI 0 "nonimmediate_operand" "=r,rm,!k")
> (any_or:HI
> diff --git a/gcc/testsuite/gcc.target/i386/pr65105-5.c 
> b/gcc/testsuite/gcc.target/i386/pr65105-5.c
> index 5818c1c..639bbe1 100644
> --- a/gcc/testsuite/gcc.target/i386/pr65105-5.c
> +++ b/gcc/testsuite/gcc.target/i386/pr65105-5.c
> @@ -1,7 +1,7 @@
>  /* PR target/pr65105 */
>  /* { dg-do compile { target { ia32 } } } */
>  /* { dg-options "-O2 -march=core-avx2" } */
> -/* { dg-final { scan-assembler "pand" } } */
> +/* { dg-final { scan-assembler "pandn" } } */
>  /* { dg-final { scan-assembler "pxor" } } */
>  /* { dg-final { scan-assembler "ptest" } } */
>

Re: [PATCH] Fix math transformation on targets without c99 math functions

[John David Anglin]

On 2016-01-11, at 10:56 AM, John David Anglin wrote:

> On 2016-01-11 8:24 AM, Jakub Jelinek wrote:
>> On Mon, Jan 11, 2016 at 02:16:31PM +0100, Christophe Lyon wrote:
> In any case, we have no_c99_libc_has_function on hpux and everything on 
> linux.  So, I
> don't think testing with function_c99_misc on hppa will show any 
> difference.
> 
> Okay with function_c99_misc?
 Ok (but please make sure to adjust ChangeLog too).
 
>>> This patch made gcc.dg/torture/builtin-integral-1.c FAIL on
>>> bare metal targets (e.g. arm-non-eabi, aarch64-none-elf,
>>> using Newlib).
>>> The logs show link errors:
>>> /ccOMzAOC.o: In function `test':
>>> builtin-integral-1.c:(.text+0x3c): undefined reference to `link_failure'
>>> collect2: error: ld returned 1 exit status
>> I'd say you want to either split that test into the double and float+long
>> double functions and limit the latter only to c99_runtime targets
>> (and add add_options_for_c99_runtime), or just guard the whole test
>> with c99_runtime and add_options_for_c99_runtime.
> Attached is untested patch implementing the latter option.  I tend to think 
> there's not
> much benefit in testing these tests on non c99 targets.


Committed.

Dave
--
John David Anglin   dave.ang...@bell.net

[committed] Fix a warning in omp-low.c

[Jakub Jelinek]

Hi!

This fixes a warning in mark_loops_in_oacc_kernels_region.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2016-01-17  Jakub Jelinek  

* omp-low.c (mark_loops_in_oacc_kernels_region): Work around
-Wmaybe-uninitialized warning.

--- gcc/omp-low.c.jj2016-01-14 22:31:22.0 +0100
+++ gcc/omp-low.c   2016-01-16 11:30:49.321974885 +0100
@@ -12539,7 +12539,7 @@ mark_loops_in_oacc_kernels_region (basic
   /* Don't parallelize the kernels region if it contains more than one outer
  loop.  */
   unsigned int nr_outer_loops = 0;
-  struct loop *single_outer;
+  struct loop *single_outer = NULL;
   for (struct loop *loop = outer->inner; loop != NULL; loop = loop->next)
 {
   gcc_assert (loop_outer (loop) == outer);

Jakub

Re: [PATCH] DWARF: add abstract origin links on lexical blocks DIEs

[Eric Botcazou]

> Sounds like a good excuse to add a guality for Ada (which has unique
> needs for dwarf).

Well, the guality testsuite is a pain to maintain so I'd rather not.
The GDB testsuite is clearly the right place for this kind of testcases.

-- 
Eric Botcazou

Re: [PATCH] Fix a warning in haifa-sched.c

[Jeff Law]

On 01/17/2016 10:59 AM, Jakub Jelinek wrote:

Hi!

During profiledbootstrap, I'm seeing:
../../gcc/system.h: In function 'void autopref_multipass_init(const rtx_insn*, 
int)':
../../gcc/system.h:367:29: warning: 'max_offset' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
  #define MAX(X,Y) ((X) > (Y) ? (X) : (Y))
  ^
../../gcc/haifa-sched.c:5603:11: note: 'max_offset' was declared here
int max_offset;
^~
and similarly for min_offset.  The warning is a false positive just because
the compiler can't know that a PARALLEL should never have zero XVECLEN (pat, 0).
prev_base which is also set during the first iteration and thus not set
if n_elems is 0 already have an initializer for this reason.

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

2016-01-17  Jakub Jelinek  

* haifa-sched.c (autopref_multipass_init): Work around
-Wmaybe-uninitialized warning.
OK.  I was carrying a similar patch locally.  The difference is I used 
INT_MAX for min_offset and INT_MIN for max_offset, just for extra safety.


Jeff

[PATCH] Fix a warning in mpx wrappers

[Jakub Jelinek]

Hi!

The following patch fixes a warning in libmpx:
../../../../libmpx/mpxwrap/mpx_wrappers.c:492:8: warning: assignment discards 
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 *d = *s;
^

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

2016-01-17  Jakub Jelinek  

* mpxwrap/mpx_wrappers.c (__mpx_wrapper_memmove): Avoid
-Wdiscarded-qualifiers warning.  Fix up formatting.

--- libmpx/mpxwrap/mpx_wrappers.c.jj2015-12-31 01:11:17.0 +0100
+++ libmpx/mpxwrap/mpx_wrappers.c   2016-01-16 10:37:54.488048781 +0100
@@ -486,12 +486,12 @@ __mpx_wrapper_memmove (void *dst, const
   /* When we copy exactly one pointer it is faster to
  just use bndldx + bndstx.  */
   if (n == sizeof (void *))
-  {
-const void **s = (const void**)src;
-void **d = (void**)dst;
-*d = *s;
-return dst;
-  }
+{
+  void *const *s = (void *const *) src;
+  void **d = (void **) dst;
+  *d = *s;
+  return dst;
+}
 
   memmove (dst, src, n);
 


Jakub

[PATCH] Fix use of declare'd vars by routine procedures.

[James Norris]

Hi!

The attached patch addresses the failure of declare-4 in the libgomp testsuite.
The primary failure was the use a variable with a link clause for an OpenACC
routine function. The patch changes the test to use a create clause. The patch
also adds checking of those globals used within an OpenACC routine function.
Additional gcc testing is also included in the patch.

Regtested and bootstrapped on x86_64.

OK for trunk?

Thanks!

Jim
Index: gcc/c/ChangeLog
===
--- gcc/c/ChangeLog	(revision 232340)
+++ gcc/c/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2016-01-XX  James Norris  
+
+	* c-parser.c (build_external_ref): Add usage check.
+
 2016-01-06  David Malcolm  
 
 	* c-parser.c (c_parser_unary_expression): For dereferences, build
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c	(revision 232340)
+++ gcc/c/c-typeck.c	(working copy)
@@ -2677,6 +2677,26 @@
   tree ref;
   tree decl = lookup_name (id);
 
+  if (decl
+  && decl != error_mark_node
+  && current_function_decl
+  && TREE_CODE (decl) == VAR_DECL
+  && is_global_var (decl)
+  && get_oacc_fn_attrib (current_function_decl))
+{
+  /* Validate data type for use with routine directive.  */
+  if (lookup_attribute ("omp declare target link",
+			DECL_ATTRIBUTES (decl))
+	  || ((!lookup_attribute ("omp declare target",
+  DECL_ATTRIBUTES (decl))
+	   && ((TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
+		   || (!TREE_STATIC (decl) && DECL_EXTERNAL (decl))
+	{
+	  error_at (loc, "invalid use in % function");
+	  return error_mark_node;
+	}
+}
+
   /* In Objective-C, an instance variable (ivar) may be preferred to
  whatever lookup_name() found.  */
   decl = objc_lookup_ivar (decl, id);
Index: gcc/cp/ChangeLog
===
--- gcc/cp/ChangeLog	(revision 232340)
+++ gcc/cp/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2016-01-XX  James Norris  
+
+	* semantics.c (finish_id_expression): Add usage check.
+
 2016-01-12  Marek Polacek  
 
 	PR c++/68979
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c	(revision 232340)
+++ gcc/cp/semantics.c	(working copy)
@@ -3712,6 +3712,25 @@
 
 	  decl = convert_from_reference (decl);
 	}
+
+  if (decl != error_mark_node
+	  && current_function_decl
+	  && TREE_CODE (decl) == VAR_DECL
+	  && is_global_var (decl)
+	  && get_oacc_fn_attrib (current_function_decl))
+	{
+	  /* Validate data type for use with routine directive.  */
+	  if (lookup_attribute ("omp declare target link",
+DECL_ATTRIBUTES (decl))
+	  || ((!lookup_attribute ("omp declare target",
+  DECL_ATTRIBUTES (decl))
+		   && ((TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
+			|| (!TREE_STATIC (decl) && DECL_EXTERNAL (decl))
+	{
+	  *error_msg = "invalid use in % function";
+	  return error_mark_node;
+	}
+	}
 }
 
   return cp_expr (decl, location);
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(revision 232340)
+++ gcc/testsuite/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2016-01-XX  James Norris  
+
+	* c-c++-common/goacc/routine-5.c: Additional tests.
+
 2016-01-13  H.J. Lu  
 
 	* gcc.target/i386/pr69225-7.c: New test.
Index: gcc/testsuite/c-c++-common/goacc/routine-5.c
===
--- gcc/testsuite/c-c++-common/goacc/routine-5.c	(revision 232340)
+++ gcc/testsuite/c-c++-common/goacc/routine-5.c	(working copy)
@@ -45,3 +45,49 @@
 #pragma acc routine (a) /* { dg-error "does not refer to" } */
   
 #pragma acc routine (c) /* { dg-error "does not refer to" } */
+
+float vb1;
+
+#pragma acc routine
+int
+func1 (int a)
+{
+  vb1 = a + 1; /* { dg-error "invalid use in" } */
+
+  return vb1; /* { dg-error "invalid use in" } */
+}
+
+#pragma acc routine
+int
+func2 (int a)
+{
+  static int vb2;
+
+  vb2 = a + 1; /* { dg-error "invalid use in" } */
+
+  return vb2; /* { dg-error "invalid use in" } */
+}
+
+float vb3;
+#pragma acc declare link (vb3)
+
+#pragma acc routine
+int
+func3 (int a)
+{
+  vb3 = a + 1; /* { dg-error "invalid use in" } */
+
+  return vb3; /* { dg-error "invalid use in" } */
+}
+
+float vb4;
+#pragma acc declare create (vb4)
+
+#pragma acc routine
+int
+func4 (int a)
+{
+  vb4 = a + 1;
+
+  return vb4;
+}
Index: libgomp/ChangeLog
===
--- libgomp/ChangeLog	(revision 232341)
+++ libgomp/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2016-01-XX  James Norris  
+
+	* testsuite/libgomp.oacc-c-c++-common/declare-4.c: Fix test.
+
 2016-01-12  

Re: [PATCH] fix #69277 - [6 Regression] ICE mangling a flexible array member

[Martin Sebor]

On 01/15/2016 02:01 PM, Jason Merrill wrote:

On 01/14/2016 10:01 PM, Martin Sebor wrote:

In anticipation of needing to do something I put together the attached
patch that rolls this change into version 10, letting version 9 and
prior roll it back.  I also mention it in the manual.  What the patch
doesn't do is add a warning.


Looks good, but please also add a warning.  See the use of
abi_warn_or_compat_version_crosses elsewhere in mangle.c.


Attached is an updated patch with the warning plus a test for it.
The test depends on the fix that I posted yesterday for #69317 -
[6 regression] wrong ABI version in -Wabi warning.

Martin

gcc/testsuite/ChangeLog:
2016-01-14  Martin Sebor  

	PR c++/69277
	* gcc/testsuite/g++.dg/abi/flexarray-abi-v9.C: New test.
	* g++.dg/ext/flexarray-mangle-2.C: New test.
	* g++.dg/ext/flexarray-mangle.C: New test.
	* g++.dg/abi/flexarray-Wabi-9-10.C: New test.
gcc/cp/ChangeLog:
2016-01-14  Martin Sebor  

	PR c++/69277
	* mangle.c (write_array_type): Mangle flexible array members
	the same as arrays with an unspecified size.

gcc/ChangeLog:
2016-01-14  Martin Sebor  

	PR c++/69277
	* invoke.texi (-fabi-version=, -Wabi): Update version 10.

Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c	(revision 232296)
+++ gcc/cp/mangle.c	(working copy)
@@ -3280,8 +3280,10 @@ write_template_template_arg (const tree
 		  ::= A  _ 
 
  "Array types encode the dimension (number of elements) and the
- element type. For variable length arrays, the dimension (but not
- the '_' separator) is omitted."  */
+ element type.  For variable length arrays, the dimension (but not
+ the '_' separator) is omitted."
+ Note that for flexible array members, like for other arrays of
+ unspecified size, the dimension is also omitted.  */
 
 static void
 write_array_type (const tree type)
@@ -3289,30 +3291,42 @@ write_array_type (const tree type)
   write_char ('A');
   if (TYPE_DOMAIN (type))
 {
-  tree index_type;
-  tree max;
-
-  index_type = TYPE_DOMAIN (type);
-  /* The INDEX_TYPE gives the upper and lower bounds of the
-	 array.  */
-  max = TYPE_MAX_VALUE (index_type);
-  if (TREE_CODE (max) == INTEGER_CST)
+  tree index_type = TYPE_DOMAIN (type);
+  /* The INDEX_TYPE gives the upper and lower bounds of the array.
+	 It's null for flexible array members which have no upper bound
+	 (this is a change from GCC 5 and prior where such members were
+	 incorrectly mangled as zero-length arrays).  */
+  if (tree max = TYPE_MAX_VALUE (index_type))
 	{
-	  /* The ABI specifies that we should mangle the number of
-	 elements in the array, not the largest allowed index.  */
-	  offset_int wmax = wi::to_offset (max) + 1;
-	  /* Truncate the result - this will mangle [0, SIZE_INT_MAX]
-	 number of elements as zero.  */
-	  wmax = wi::zext (wmax, TYPE_PRECISION (TREE_TYPE (max)));
-	  gcc_assert (wi::fits_uhwi_p (wmax));
-	  write_unsigned_number (wmax.to_uhwi ());
+	  if (TREE_CODE (max) == INTEGER_CST)
+	{
+	  /* The ABI specifies that we should mangle the number of
+		 elements in the array, not the largest allowed index.  */
+	  offset_int wmax = wi::to_offset (max) + 1;
+	  /* Truncate the result - this will mangle [0, SIZE_INT_MAX]
+		 number of elements as zero.  */
+	  wmax = wi::zext (wmax, TYPE_PRECISION (TREE_TYPE (max)));
+	  gcc_assert (wi::fits_uhwi_p (wmax));
+	  write_unsigned_number (wmax.to_uhwi ());
+	}
+	  else
+	{
+	  max = TREE_OPERAND (max, 0);
+	  write_expression (max);
+	}
 	}
   else
-	{
-	  max = TREE_OPERAND (max, 0);
-	  write_expression (max);
-	}
+	{	  
+	  if (!abi_version_at_least (10))
+	{
+	  /* In ABI versions prior to 10 mangle flexible array members
+		 the same as zero-length arrays for compatibility.  */
+	  write_unsigned_number (0);
+	}
 
+	  if (abi_warn_or_compat_version_crosses (10))
+	G.need_abi_warning = true;
+	}
 }
   write_char ('_');
   write_type (TREE_TYPE (type));
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 232296)
+++ gcc/doc/invoke.texi	(working copy)
@@ -2173,7 +2173,8 @@ Version 9, which first appeared in G++ 5
 
 Version 10, which first appeared in G++ 6.1, adds mangling of
 attributes that affect type identity, such as ia32 calling convention
-attributes (e.g. @samp{stdcall}).
+attributes (e.g. @samp{stdcall}).  This version also corrects the mangling
+of flexible array members.
 
 See also @option{-Wabi}.
 
@@ -2605,16 +2606,16 @@ have meanings only for C++ programs:
 @item -Wabi @r{(C, Objective-C, C++ and Objective-C++ only)}
 @opindex Wabi
 @opindex Wno-abi
-Warn when G++ it generates code that is probably not compatible with
-the vendor-neutral C++ ABI@.  Since G++ now defaults to updating the
+Warn 

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[David Edelsohn]

On Sun, Jan 17, 2016 at 3:21 PM, Torvald Riegel  wrote:
> On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
>> On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek  wrote:
>> > On Sat, Jan 16, 2016 at 07:47:33AM -0500, David Edelsohn wrote:
>> >> stage1 libstdc++ builds just fine.  the problem is stage2 configure
>> >> fails due to missing ITM_xxx symbols when configure tries to compile
>> >> and run conftest programs.
>> >
>> > On x86_64-linux, the _ITM_xxx symbols are undef weak ones and thus it is
>> > fine to load libstdc++ without libitm and libstdc++ doesn't depend on
>> > libitm.
>> >
>> > So, is AIX defining __GXX_WEAK__ or not?  Perhaps some other macro or
>> > configure check needs to be used to determine if undefined weak symbols
>> > work the way libstdc++ needs them to.
>>
>> __GXX_WEAK__ appears to be defined by gcc/c-family/c-cppbuiltin.c
>> based on  SUPPORTS_ONE_ONLY.  gcc/defaults.h defines SUPPORTS_ONE_ONLY
>> if the target supports MAKE_DECL_ONE_ONLY and link-once semantics.
>> AIX weak correctly supports link-once semantics.  AIX also supports
>> the definition of __GXX_WEAK__ in gcc/doc/cpp.texi, namely collapsing
>> symbols with vague linkage in multiple translation units.
>>
>> libstdc++/src/c++11/cow-stdexcept.cc appears to be using __GXX_WEAK__
>> and __attribute__ ((weak)) for references to symbols that may not be
>> defined at link time or run time.  AIX does not allow undefined symbol
>> errors by default.  And the libstdc++ inference about the semantics of
>> __GXX_WEAK__ are different than the documentation.
>>
>> AIX supports MAKE_DECL_ONE_ONLY and the documented meaning of
>> __GXX_WEAK__.  AIX does not support extension of the meaning to
>> additional SVR4 semantics not specified in the documentation.
>
> I see, so we might be assuming that __GXX_WEAK__ means more than it
> actually does (I'm saying "might" because personally, I don't know; your
> information supports this is the case, but the initial info I got was
> that __GXX_WEAK__ would mean we could have weak decls without
> definitions).

I believe that libstdc++ must continue with the weak undefined
references to the symbols as designed, but protect them with a
different macro.  For example, __GXX_WEAK_REF__ or __GXX_WEAK_UNDEF__
defined in defaults.h based on configure test or simply overridden in
config/rs6000/aix.h.  Or the macro could be local to libstdc++ and
overridden in config/os/aix/os_defines.h.

Thanks, David

Re: [ARM] implement division using vrecpe/vrecps with -funsafe-math-optimizations

[Prathamesh Kulkarni]

On 31 July 2015 at 15:04, Ramana Radhakrishnan
 wrote:
>
>
> On 29/07/15 11:09, Prathamesh Kulkarni wrote:
>> Hi,
>> This patch tries to implement division with multiplication by
>> reciprocal using vrecpe/vrecps
>> with -funsafe-math-optimizations and -freciprocal-math enabled.
>> Tested on arm-none-linux-gnueabihf using qemu.
>> OK for trunk ?
>>
>> Thank you,
>> Prathamesh
>>
>
> I've tried this in the past and never been convinced that 2 iterations are 
> enough to get to stability with this given that the results are only precise 
> for 8 bits / iteration. Thus I've always believed you need 3 iterations 
> rather than 2 at which point I've never been sure that it's worth it. So the 
> testing that you've done with this currently is not enough for this to go 
> into the tree.
>
> I'd like this to be tested on a couple of different AArch32 implementations 
> with a wider range of inputs to verify that the results are acceptable as 
> well as running something like SPEC2k(6) with atleast one iteration to ensure 
> correctness.
Hi,
I got results of SPEC2k6 fp benchmarks:
a15: +0.64% overall, 481.wrf: +6.46%
a53: +0.21% overall, 416.gamess: -1.39%, 481.wrf: +6.76%
a57: +0.35% overall, 481.wrf: +3.84%
The other benchmarks had (almost) identical results.

Thanks,
Prathamesh
>
>
> moving on to the patches.
>
>> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
>> index 654d9d5..28c2e2a 100644
>> --- a/gcc/config/arm/neon.md
>> +++ b/gcc/config/arm/neon.md
>> @@ -548,6 +548,32 @@
>>  (const_string "neon_mul_")))]
>>  )
>>
>
> Please add a comment here.
>
>> +(define_expand "div3"
>> +  [(set (match_operand:VCVTF 0 "s_register_operand" "=w")
>> +(div:VCVTF (match_operand:VCVTF 1 "s_register_operand" "w")
>> +   (match_operand:VCVTF 2 "s_register_operand" "w")))]
>
> I want to double check that this doesn't collide with Alan's patches for FP16 
> especially if he reuses the VCVTF iterator for all the vcvt f16 cases.
>
>> +  "TARGET_NEON && flag_unsafe_math_optimizations && flag_reciprocal_math"
>> +  {
>> +rtx rec = gen_reg_rtx (mode);
>> +rtx vrecps_temp = gen_reg_rtx (mode);
>> +
>> +/* Reciprocal estimate */
>> +emit_insn (gen_neon_vrecpe (rec, operands[2]));
>> +
>> +/* Perform 2 iterations of Newton-Raphson method for better accuracy */
>> +for (int i = 0; i < 2; i++)
>> +  {
>> + emit_insn (gen_neon_vrecps (vrecps_temp, rec, operands[2]));
>> + emit_insn (gen_mul3 (rec, rec, vrecps_temp));
>> +  }
>> +
>> +/* We now have reciprocal in rec, perform operands[0] = operands[1] * 
>> rec */
>> +emit_insn (gen_mul3 (operands[0], operands[1], rec));
>> +DONE;
>> +  }
>> +)
>> +
>> +
>>  (define_insn "mul3add_neon"
>>[(set (match_operand:VDQW 0 "s_register_operand" "=w")
>>  (plus:VDQW (mult:VDQW (match_operand:VDQW 2 "s_register_operand" 
>> "w")
>> diff --git a/gcc/testsuite/gcc.target/arm/vect-div-1.c 
>> b/gcc/testsuite/gcc.target/arm/vect-div-1.c
>> new file mode 100644
>> index 000..e562ef3
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/vect-div-1.c
>> @@ -0,0 +1,14 @@
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target arm_v8_neon_ok } */
>> +/* { dg-options "-O2 -funsafe-math-optimizations -ftree-vectorize 
>> -fdump-tree-vect-all" } */
>> +/* { dg-add-options arm_v8_neon } */
>
> No this is wrong.
>
> What is armv8 specific about this test ? This is just like another test that 
> is for Neon. vrecpe / vrecps are not instructions that were introduced in the 
> v8 version of the architecture. They've existed in the base Neon instruction 
> set. The code generation above in the patterns will be enabled when 
> TARGET_NEON is true which can happen when -mfpu=neon 
> -mfloat-abi={softfp/hard} is true.
>
>> +
>> +void
>> +foo (int len, float * __restrict p, float *__restrict x)
>> +{
>> +  len = len & ~31;
>> +  for (int i = 0; i < len; i++)
>> +p[i] = p[i] / x[i];
>> +}
>> +
>> +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
>> diff --git a/gcc/testsuite/gcc.target/arm/vect-div-2.c 
>> b/gcc/testsuite/gcc.target/arm/vect-div-2.c
>> new file mode 100644
>> index 000..8e15d0a
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/vect-div-2.c
>> @@ -0,0 +1,14 @@
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target arm_v8_neon_ok } */
>
> And likewise.
>
>> +/* { dg-options "-O2 -funsafe-math-optimizations -fno-reciprocal-math 
>> -ftree-vectorize -fdump-tree-vect-all" } */
>> +/* { dg-add-options arm_v8_neon } */
>> +
>> +void
>> +foo (int len, float * __restrict p, float *__restrict x)
>> +{
>> +  len = len & ~31;
>> +  for (int i = 0; i < len; i++)
>> +p[i] = p[i] / x[i];
>> +}
>> +
>> +/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" } } */
>
>
> regards
> Ramana

[Patch, fortran] (4/5-regression) PR61831 side-effect deallocation of variable components)

[Paul Richard Thomas]

Dear Mikael,

I have gathered together the applicable patches to fix this PR on
5-branch. In so doing, the testcase for PR66082 was added
(alloc_comp_auto_array_3.f90), since a change was made for this PR. I
found that this leaked memory, of course, and so I have added the fix
for PR66082. I have checked that all the memory leaks mentioned in the
PR comments are fixed. The change in allocate_with_source_14.f03 is a
bit mysterious but I checked that it doesn't lose memory, so no harm
is done.

Bootstrapped and regtested on FC21/x86_64 - OK for 5-branch? (I
thought to commit it today, if that is OK?)

Cheers

Paul

2016-01-17  Mikael Morin  

Backport from trunk.
PR fortran/61831
* gfortran.dg/derived_constructor_components_6.f90: New file.
* gfortran.dg/allocate_with_source_14.f03: Change count of
__builtin_malloc from 21 to 23.

2016-01-17  Paul Thomas  

Backport from trunk.
PR fortran/66082
* gfortran.dg/alloc_comp_auto_array_3.f90: New file. Count of
__builtin_malloc increased from 3 to 4, relative to trunk.

2016-01-17  Mikael Morin  
Dominique d'Humieres  

Backport from trunk.
PR fortran/61831
* trans-array.c (gfc_conv_array_parameter): Guard allocatable
component deallocation code generation with descriptorless
calling convention flag.
* trans-expr.c (gfc_conv_expr_reference): Remove allocatable
component deallocation code generation from revision 212329.
(expr_may_alias_variables): New function.
(gfc_conv_procedure_call): New boolean elemental_proc to factor
check for procedure elemental-ness.  Rename boolean f to nodesc_arg
and declare it in the outer scope.  Use expr_may_alias_variables,
elemental_proc and nodesc_arg to decide whether generate allocatable
component deallocation code.
(gfc_trans_subarray_assign): Set deep copy flag.

2016-01-17  Paul Thomas  

Backport from trunk.
PR fortran/66082
* trans-array.c (gfc_conv_array_parameter): Ensure that all
non-variable arrays with allocatable components have the
components deallocated after the procedure call.


-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c   (revision 232481)
--- gcc/fortran/trans-array.c   (working copy)
*** gfc_conv_array_parameter (gfc_se * se, g
*** 7192,7197 
--- 7192,7208 
if (no_pack || array_constructor || good_allocatable || ultimate_alloc_comp)
  {
gfc_conv_expr_descriptor (se, expr);
+   /* Deallocate the allocatable components of structures that are
+not variable.  */
+   if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
+  && expr->ts.u.derived->attr.alloc_comp
+  && expr->expr_type != EXPR_VARIABLE)
+   {
+ tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, se->expr, 
expr->rank);
+
+ /* The components shall be deallocated before their containing 
entity.  */
+ gfc_prepend_expr_to_block (>post, tmp);
+   }
if (expr->ts.type == BT_CHARACTER)
se->string_length = expr->ts.u.cl->backend_decl;
if (size)
*** gfc_conv_array_parameter (gfc_se * se, g
*** 7227,7236 
  }

/* Deallocate the allocatable components of structures that are
!  not variable.  */
!   if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
!   && expr->ts.u.derived->attr.alloc_comp
!   && expr->expr_type != EXPR_VARIABLE)
  {
tmp = build_fold_indirect_ref_loc (input_location, se->expr);
tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
--- 7238,7248 
  }

/* Deallocate the allocatable components of structures that are
!  not variable, for descriptorless arguments.
!  Arguments with a descriptor are handled in gfc_conv_procedure_call.  */
!   if (g77 && (expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
! && expr->ts.u.derived->attr.alloc_comp
! && expr->expr_type != EXPR_VARIABLE)
  {
tmp = build_fold_indirect_ref_loc (input_location, se->expr);
tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 232481)
--- gcc/fortran/trans-expr.c(working copy)
*** conv_arglist_function (gfc_se *se, gfc_e
*** 4398,4403 
--- 4398,4459 
  }


+ /* This function tells whether the middle-end representation of the expression
+E given as input may point to data otherwise accessible through a variable
+(sub-)reference.
+It is assumed that the only expressions that may alias are variables,
+and array 

[patch, fortran] Inline MATMUL(A,TRANSPOSE(B)), PR 66094

[Thomas Koenig]

Hello world,

after the recent discussion about MATMUL(A,TRANSPOSE(B)) I have prepared
a patch which implements this.

The patch is a rather straightforward implementation using the machinery
that is already in place for matmul inlining, so the risk of introducing
a regression should be quite low.

Because of this, and beacuse this is a significant use case, I think
this could still be OK for trunk.  Jerry already indicated in the PR
that this could be the case.

Regression-tested.

So... comments?  Toon, would this help you?  Could yo maybe give this
a spin?

Regards

Thomas


2016-01-17  Thomas Koenig  

PR fortran/66094
* frontend-passes.c (enum matrix_case):  Add case A2B2T for
MATMUL(A,TRANSPoSE(B)) where A and B are rank 2.
(inline_limit_check):  Also add A2B2T.
(matmul_lhs_realloc):  Handle A2B2T.
(check_conjg_variable):  Rename to
(check_conjg_transpose_variable):  and also count TRANSPOSE.
(inline_matmul_assign):  Handle A2B2T.

2016-01-17  Thomas Koenig  

PR fortran/66094
* gfortran.dg/inline_matmul_13.f90:  New test.
* gfortran.dg/matmul_bounds_8.f90:  New test.
* gfortran.dg/matmul_bounds_9.f90:  New test.
* gfortran.dg/matmul_bounds_10.f90:  New test.
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 232467)
+++ frontend-passes.c	(Arbeitskopie)
@@ -106,7 +106,7 @@ static int var_num = 1;
 
 /* What sort of matrix we are dealing with when inlining MATMUL.  */
 
-enum matrix_case { none=0, A2B2, A2B1, A1B2 };
+enum matrix_case { none=0, A2B2, A2B1, A1B2, A2B2T };
 
 /* Keep track of the number of expressions we have inserted so far 
using create_var.  */
@@ -2080,7 +2080,7 @@ inline_limit_check (gfc_expr *a, gfc_expr *b, enum
   gfc_typespec ts;
   gfc_expr *cond;
 
-  gcc_assert (m_case == A2B2);
+  gcc_assert (m_case == A2B2 || m_case == A2B2T);
 
   /* Calculation is done in real to avoid integer overflow.  */
 
@@ -2240,6 +2240,18 @@ matmul_lhs_realloc (gfc_expr *c, gfc_expr *a, gfc_
   cond = build_logical_expr (INTRINSIC_OR, ne1, ne2);
   break;
 
+case A2B2T:
+  ar->start[0] = get_array_inq_function (GFC_ISYM_SIZE, a, 1);
+  ar->start[1] = get_array_inq_function (GFC_ISYM_SIZE, b, 1);
+
+  ne1 = build_logical_expr (INTRINSIC_NE,
+get_array_inq_function (GFC_ISYM_SIZE, c, 1),
+get_array_inq_function (GFC_ISYM_SIZE, a, 1));
+  ne2 = build_logical_expr (INTRINSIC_NE,
+get_array_inq_function (GFC_ISYM_SIZE, c, 2),
+get_array_inq_function (GFC_ISYM_SIZE, b, 1));
+  cond = build_logical_expr (INTRINSIC_OR, ne1, ne2);
+
 case A2B1:
   ar->start[0] = get_array_inq_function (GFC_ISYM_SIZE, a, 1);
   cond = build_logical_expr (INTRINSIC_NE,
@@ -2708,7 +2720,7 @@ has_dimen_vector_ref (gfc_expr *e)
 
 /* If handed an expression of the form
 
-   CONJG(A)
+   TRANSPOSE(CONJG(A))
 
check if A can be handled by matmul and return if there is an uneven number
of CONJG calls.  Return a pointer to the array when everything is OK, NULL
@@ -2715,9 +2727,10 @@ has_dimen_vector_ref (gfc_expr *e)
otherwise. The caller has to check for the correct rank.  */
 
 static gfc_expr*
-check_conjg_variable (gfc_expr *e, bool *conjg)
+check_conjg_transpose_variable (gfc_expr *e, bool *conjg, bool *transpose)
 {
   *conjg = false;
+  *transpose = false;
 
   do
 {
@@ -2733,6 +2746,8 @@ static gfc_expr*
 
 	  if (e->value.function.isym->id == GFC_ISYM_CONJG)
 	*conjg = !*conjg;
+	  else if (e->value.function.isym->id == GFC_ISYM_TRANSPOSE)
+	*transpose = !*transpose;
 	  else return NULL;
 	}
   else
@@ -2789,7 +2804,7 @@ inline_matmul_assign (gfc_code **c, int *walk_subt
   int i;
   gfc_code *if_limit = NULL;
   gfc_code **next_code_point;
-  bool conjg_a, conjg_b;
+  bool conjg_a, conjg_b, transpose_a, transpose_b;
 
   if (co->op != EXEC_ASSIGN)
 return 0;
@@ -2809,12 +2824,12 @@ inline_matmul_assign (gfc_code **c, int *walk_subt
   changed_statement = NULL;
 
   a = expr2->value.function.actual;
-  matrix_a = check_conjg_variable (a->expr, _a);
-  if (matrix_a == NULL)
+  matrix_a = check_conjg_transpose_variable (a->expr, _a, _a);
+  if (transpose_a || matrix_a == NULL)
 return 0;
 
   b = a->next;
-  matrix_b = check_conjg_variable (b->expr, _b);
+  matrix_b = check_conjg_transpose_variable (b->expr, _b, _b);
   if (matrix_b == NULL)
 return 0;
 
@@ -2828,10 +2843,28 @@ inline_matmul_assign (gfc_code **c, int *walk_subt
 return 0;
 
   if (matrix_a->rank == 2)
-m_case = matrix_b->rank == 1 ? A2B1 : A2B2;
+{
+  if (matrix_b->rank == 1)
+	m_case = A2B1;
+  else
+	{
+	  if (transpose_b)
+	m_case = A2B2T;
+	  else
+	m_case = A2B2;
+	}
+}
   else
-m_case = A1B2;
+{
+  /* Vector * Transpose(B) not handled yet.  */
+  if (transpose_b)
+	m_case = 

[PATCH] libcpp: use better locations for _Pragma tokens (preprocessor/69126)

[David Malcolm]

Our code for handling the "_Pragma" builtin macro is implemented in
libcpp/directives.c:destringize_and_run.  

It handles _Pragma by creating a one-line buffer containing the _Pragma
content, then sending it to do_pragma, which tokenizes it and handles
the input as if it were spelled as #pragma.

Unfortunately the tokens it generates have bogus location values; the
values are in the current highest ordinary map at the time of expansion,
and this determines the effective location of the synthesized #pragma.

Hence for PR preprocessor/69126:


#pragma GCC diagnostic push
#define MACRO \
_Pragma("GCC diagnostic ignored \"-Wunused-variable\"") \
int x;

int g()
{
MACRO;
return 0;
}
#pragma GCC diagnostic pop


although -save-temps looks sane:


#pragma GCC diagnostic push

int g()
{
# 19 "../../src/gcc/testsuite/c-c++-common/pr69126.c"
#pragma GCC diagnostic ignored "-Wunused-variable"
# 19 "../../src/gcc/testsuite/c-c++-common/pr69126.c"
int x;;
return 0;
}
#pragma GCC diagnostic pop


the "ignored" directive is treated as if it occured in this
bogus location:

(gdb) call inform (226930, "pre, the location of the ignore")
/tmp/test.cc:17:24: note: pre, the location of the ignore
 MACRO;
^
which is effectively *after* the
int x;;
line.

I believe this is a long-standing bug, but the cleanup of the
C++ FE's impl of -Wunused-variable in r226234 (to avoid using
%q+D) has exposed this as a regression (since the -Wunused-variable
warning is now emitted for this location:
int x;
 ^
rather than at input_location:
 return 0;
 ^
and hence isn't suppressed by the _Pragma.

The function destringize_and_run is full of comments like
  /* Ugh; an awful kludge.  We are really not set up to be lexing
and:
  /* ??? Antique Disgusting Hack.  What does this do?  */
and similar "???" lines.

I believe it predates macro maps (I believe they were added in
r180081 on 2011-10-15); as far as I can tell, the code is set
up for *line* maps, i.e. it may even predate column information
(it gets the line right, but not the column).

To minimize the change to destringize_and_run at this stage, the
following patch papers over the problem by fixing up the locations
for the tokens synthesized for _Pragma, setting them all to be at the
expansion point of the _Pragma directive, rather than some columns
after it.

This fixes the location of the synthesized #pragma and hence
fixes the regression seen in the PR.  The -save-temps output (which
was already correct) is unaffected.

Successfully bootstrapped on x86_64-pc-linux-gnu;
adds 3 PASS results to g++.sum and 1 to gcc.sum
(although the regression currently only affects C++, I put the new
test case into c-c++-common for good measure).

OK for trunk in stage 3?

gcc/testsuite/ChangeLog:
PR preprocessor/69126
* c-c++-common/pr69126.c: New test case.

libcpp/ChangeLog:
PR preprocessor/69126
* directives.c (destringize_and_run): Add expansion_loc param; use
it when handling unexpanded pragmas to fixup the locations of the
synthesized tokens.
(_cpp_do__Pragma): Add expansion_loc param and use it when calling
destringize_and_run.
* internal.h (_cpp_do__Pragma): Add expansion_loc param.
* macro.c (builtin_macro): Pass expansion location of _Pragma to
_cpp_do__Pragma.
---
 gcc/testsuite/c-c++-common/pr69126.c | 22 ++
 libcpp/directives.c  | 13 ++---
 libcpp/internal.h|  2 +-
 libcpp/macro.c   |  2 +-
 4 files changed, 34 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/pr69126.c

diff --git a/gcc/testsuite/c-c++-common/pr69126.c 
b/gcc/testsuite/c-c++-common/pr69126.c
new file mode 100644
index 000..fb4dcfb
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pr69126.c
@@ -0,0 +1,22 @@
+/* { dg-options "-Wunused-variable" } */
+
+#pragma GCC diagnostic push
+int f()
+{
+_Pragma("GCC diagnostic ignored \"-Wunused-variable\"")
+int x;
+return 0;
+}
+#pragma GCC diagnostic pop
+
+#pragma GCC diagnostic push
+#define MACRO \
+_Pragma("GCC diagnostic ignored \"-Wunused-variable\"") \
+int x;
+
+int g()
+{
+MACRO;
+return 0;
+}
+#pragma GCC diagnostic pop
diff --git a/libcpp/directives.c b/libcpp/directives.c
index eff1861..a1e1239 100644
--- a/libcpp/directives.c
+++ b/libcpp/directives.c
@@ -1753,7 +1753,8 @@ get__Pragma_string (cpp_reader *pfile)
 /* Destringize IN into a temporary buffer, by removing the first \ of
\" and \\ sequences, and process the result as a #pragma directive.  */
 static void
-destringize_and_run (cpp_reader *pfile, const cpp_string *in)

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Jonathan Wakely]

On 16 January 2016 at 22:58, H.J. Lu wrote:
> Don't you need to update baseline_symbols.txt?

That usually happens when we get near the release, not every time we
add symbols.

Re: [PATCH] libstdc++: Fix static_assert.

[Jonathan Wakely]

On 16 January 2016 at 22:47, Torvald Riegel wrote:
> This adds a missing string argument to a call to static_assert, thus not
> making it depend on c++1z extensions.  This fixes the build breakage on
> mingw introduced in 232454.
>
> Tested on x86_64-linux.  OK?

OK.

Re: [PATCH] libstdc++: Fix static_assert.

[Jonathan Wakely]

On 17 January 2016 at 17:01, Jonathan Wakely wrote:
> On 16 January 2016 at 22:47, Torvald Riegel wrote:
>> This adds a missing string argument to a call to static_assert, thus not
>> making it depend on c++1z extensions.  This fixes the build breakage on
>> mingw introduced in 232454.
>>
>> Tested on x86_64-linux.  OK?
>
> OK.

Actually please change the message, so it states the condition being
tested, not the negation.

e.g. "Pointers are 32 bits or 64 bits wide"

or state what must be true, "Pointers must be 32 bits or 64 bits wide"

Re: [Patch, fortran] (4/5-regression) PR61831 side-effect deallocation of variable components)

[Andre Vehreschild]

Hi Paul,

with the two changes mentioned on IRC ok by me. Thanks for the patch.

Regards,
Andre

On Sun, 17 Jan 2016 11:17:08 +0100
Paul Richard Thomas  wrote:

> Dear Mikael,
> 
> I have gathered together the applicable patches to fix this PR on
> 5-branch. In so doing, the testcase for PR66082 was added
> (alloc_comp_auto_array_3.f90), since a change was made for this PR. I
> found that this leaked memory, of course, and so I have added the fix
> for PR66082. I have checked that all the memory leaks mentioned in the
> PR comments are fixed. The change in allocate_with_source_14.f03 is a
> bit mysterious but I checked that it doesn't lose memory, so no harm
> is done.
> 
> Bootstrapped and regtested on FC21/x86_64 - OK for 5-branch? (I
> thought to commit it today, if that is OK?)
> 
> Cheers
> 
> Paul
> 
> 2016-01-17  Mikael Morin  
> 
> Backport from trunk.
> PR fortran/61831
> * gfortran.dg/derived_constructor_components_6.f90: New file.
> * gfortran.dg/allocate_with_source_14.f03: Change count of
> __builtin_malloc from 21 to 23.
> 
> 2016-01-17  Paul Thomas  
> 
> Backport from trunk.
> PR fortran/66082
> * gfortran.dg/alloc_comp_auto_array_3.f90: New file. Count of
> __builtin_malloc increased from 3 to 4, relative to trunk.
> 
> 2016-01-17  Mikael Morin  
> Dominique d'Humieres  
> 
> Backport from trunk.
> PR fortran/61831
> * trans-array.c (gfc_conv_array_parameter): Guard allocatable
> component deallocation code generation with descriptorless
> calling convention flag.
> * trans-expr.c (gfc_conv_expr_reference): Remove allocatable
> component deallocation code generation from revision 212329.
> (expr_may_alias_variables): New function.
> (gfc_conv_procedure_call): New boolean elemental_proc to factor
> check for procedure elemental-ness.  Rename boolean f to nodesc_arg
> and declare it in the outer scope.  Use expr_may_alias_variables,
> elemental_proc and nodesc_arg to decide whether generate allocatable
> component deallocation code.
> (gfc_trans_subarray_assign): Set deep copy flag.
> 
> 2016-01-17  Paul Thomas  
> 
> Backport from trunk.
> PR fortran/66082
> * trans-array.c (gfc_conv_array_parameter): Ensure that all
> non-variable arrays with allocatable components have the
> components deallocated after the procedure call.
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [Patch, fortran] (4/5-regression) PR61831 side-effect deallocation of variable components)

[Paul Richard Thomas]

Dear Andre,

Thanks for the very useful discussion. It cleared away one or two cobwebs!

Committed as revision 232482.

Now to see if it will apply to 4.9 branch This might be a step too
far, since all sorts of other prerequisites are not there. If it
doesn't go well, I will close the PR as a WONTFIX on 4.9.

Cheers

Paul

On 17 January 2016 at 18:14, Andre Vehreschild  wrote:
> Hi Paul,
>
> with the two changes mentioned on IRC ok by me. Thanks for the patch.
>
> Regards,
> Andre
>
> On Sun, 17 Jan 2016 11:17:08 +0100
> Paul Richard Thomas  wrote:
>
>> Dear Mikael,
>>
>> I have gathered together the applicable patches to fix this PR on
>> 5-branch. In so doing, the testcase for PR66082 was added
>> (alloc_comp_auto_array_3.f90), since a change was made for this PR. I
>> found that this leaked memory, of course, and so I have added the fix
>> for PR66082. I have checked that all the memory leaks mentioned in the
>> PR comments are fixed. The change in allocate_with_source_14.f03 is a
>> bit mysterious but I checked that it doesn't lose memory, so no harm
>> is done.
>>
>> Bootstrapped and regtested on FC21/x86_64 - OK for 5-branch? (I
>> thought to commit it today, if that is OK?)
>>
>> Cheers
>>
>> Paul
>>
>> 2016-01-17  Mikael Morin  
>>
>> Backport from trunk.
>> PR fortran/61831
>> * gfortran.dg/derived_constructor_components_6.f90: New file.
>> * gfortran.dg/allocate_with_source_14.f03: Change count of
>> __builtin_malloc from 21 to 23.
>>
>> 2016-01-17  Paul Thomas  
>>
>> Backport from trunk.
>> PR fortran/66082
>> * gfortran.dg/alloc_comp_auto_array_3.f90: New file. Count of
>> __builtin_malloc increased from 3 to 4, relative to trunk.
>>
>> 2016-01-17  Mikael Morin  
>> Dominique d'Humieres  
>>
>> Backport from trunk.
>> PR fortran/61831
>> * trans-array.c (gfc_conv_array_parameter): Guard allocatable
>> component deallocation code generation with descriptorless
>> calling convention flag.
>> * trans-expr.c (gfc_conv_expr_reference): Remove allocatable
>> component deallocation code generation from revision 212329.
>> (expr_may_alias_variables): New function.
>> (gfc_conv_procedure_call): New boolean elemental_proc to factor
>> check for procedure elemental-ness.  Rename boolean f to nodesc_arg
>> and declare it in the outer scope.  Use expr_may_alias_variables,
>> elemental_proc and nodesc_arg to decide whether generate allocatable
>> component deallocation code.
>> (gfc_trans_subarray_assign): Set deep copy flag.
>>
>> 2016-01-17  Paul Thomas  
>>
>> Backport from trunk.
>> PR fortran/66082
>> * trans-array.c (gfc_conv_array_parameter): Ensure that all
>> non-variable arrays with allocatable components have the
>> components deallocated after the procedure call.
>>
>>
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [PATCH] libstdc++: Fix static_assert.

[Torvald Riegel]

On Sun, 2016-01-17 at 17:03 +, Jonathan Wakely wrote:
> On 17 January 2016 at 17:01, Jonathan Wakely wrote:
> > On 16 January 2016 at 22:47, Torvald Riegel wrote:
> >> This adds a missing string argument to a call to static_assert, thus not
> >> making it depend on c++1z extensions.  This fixes the build breakage on
> >> mingw introduced in 232454.
> >>
> >> Tested on x86_64-linux.  OK?
> >
> > OK.
> 
> Actually please change the message, so it states the condition being
> tested, not the negation.
> 
> e.g. "Pointers are 32 bits or 64 bits wide"
> 
> or state what must be true, "Pointers must be 32 bits or 64 bits wide"

I committed the latter.