Re: [patch, mips] Fix for PR target/56942

[Eric Botcazou]

> And I can't get it to fail. I also can't find any place where the
> label and jump table might get separated. I was expecting some trouble
> with cross-jumping but it seems that it takes care of updating the
> label reference, and skip_insns_after_block already expects the label
> and table to be adjacent.

As well as inside_basic_block_p and delete_dead_jumptables.

> So let's just see if/what breaks...
> 
> Bootstrapped&tested on powerpc64-unknown-linux-gnu (unix{,-m32}).
> Bootstrapped&tested on x86_64-unknown-linux-gnu (unix{,-m32}).
> Build&tested powerpc64 X mips-elf.
> 
> OK for trunk?

Yes, but I'd go one step farther and replace next_active_insn with NEXT_INSN 
in tablejump_p; however it's your call.

-- 
Eric Botcazou

Re: [ada, build] host/target configuration

[Eric Botcazou]

> However, it seems that the first androideabi snippet was dead code.
> Can you delete it in a follow-up?

No, it's not dead code, just broken at the moment, now fixed by:


2013-05-30  Eric Botcazou  

* gcc-interface/Makefile.in (arm% androideabi): Robustify.


-- 
Eric BotcazouIndex: gcc-interface/Makefile.in
===
--- gcc-interface/Makefile.in	(revision 199343)
+++ gcc-interface/Makefile.in	(working copy)
@@ -995,7 +995,7 @@ ifeq ($(strip $(filter-out mips% wrs vx%
   EXTRA_LIBGNAT_OBJS+=vx_stack_info.o
 endif
 
-ifeq ($(strip $(filter-out arm% linux-androideabi,$(arch) $(osys)-$(word 4,$(targ,)
+ifeq ($(strip $(filter-out arm% androideabi,$(arch) $(osys))),)
   LIBGNAT_TARGET_PAIRS = \
   a-intnam.ads

Re: [ada, build] host/target configuration

[Paolo Bonzini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 29/05/2013 23:36, Thomas Schwinge ha scritto:
> Hi!
> 
> On Wed, 29 May 2013 16:21:38 +0200, Paolo Bonzini 
> wrote:
>> Il 29/05/2013 12:50, Thomas Schwinge ha scritto:
> How about we use something like the following [...] patch?
> In essence, replace the manual parsing in 
> gcc/ada/gcc-interface/Makefile.in by using the values the 
> configure script already computed for us.  This is largely 
> straightforward (I would hope); please especially review
> the more involved cases such as the one where I'm now
> using linux%eabi -- for example, does that do the right
> thing or interfere with the Android configurations?
> 
>> I agree that using $(target_os) and linux% matches is a better
>> way to strip out the "-gnu"s.
>> 
>> The patch is long, but I think I reviewed it carefully enough.
>> It's okay for mainline.
> 
> Thanks for the review.  Before I commit however:
> 
>> Regarding the android change:
>> 
>>> -ifeq ($(strip $(filter-out arm%-linux,$(arch)-$(osys)) $(if
>>> $(findstring eabi,$(word 4,$(targ))),,$(word 4,$(targ,) 
>>> +ifeq ($(strip $(filter-out arm% linux%eabi,$(target_cpu)
>>> $(target_os))),)
>> 
>> This is okay, it will match arm-none-linux-androideabi both
>> before and after
> 
> Well, upon more carful inspection I came to realize that the
> old/still current code accepts arm-*-linux-*eabi but also plain
> arm-*-linux, which my new code no longer accepts.  Is the old/still
> current behavior intentional here, or a bug?  It has been
> introduced in commit f49eb158fa5618dbd1130e47281e0bae13798ec6
> (r192475):

Looking at http://thread.gmane.org/gmane.comp.gcc.patches/265800, it's
a bug.  The right way would have been something like

$(if $(findstring eabi,$(word 4,$(targ))),,no-match)

Your patch fixes it.

It would be really really nice to move all this to fragments, using a
saner bash case statement to pick the right one.  It's a huge amount
of work though.

> gcc/ada/ 2012-10-15  Matthias Klose  
> 
> * gcc-interface/Makefile.in: Match arm*-*-linux-*eabi* for ARM
> Linux/GNU.
> 
> -ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch)
> $(osys)-$(word 4,$(targ,) +ifeq ($(strip $(filter-out
> arm%-linux,$(arch)-$(osys)) $(if $(findstring eabi,$(word
> 4,$(targ))),,$(word 4,$(targ,)
> 
> From the description, I understand that change to mean any ARM, 
> Linux-kernel, EABI configuration with any kind of user-land, so my
> new interpretation seems correct, and the current code wrong to
> also accept plain arm-*-linux.  That change just cite should just
> have replaced linux-gnueabi with linux-%eabi?
> 
>> (perhaps linux-%eabi would be more readable).
> 
> As soon as we've clarified the previous question, I'll do that
> change.

Thanks.

>> However, it seems that the first androideabi snippet was dead
>> code. Can you delete it in a follow-up?
> 
> That has been added in commit
> 7a5ee35f18bc945ec8abbcd1377c446352504e6e (r193238):
> 
> 2012-11-06  Arnaud Charlet  
> 
> [...] * gcc-interface/Makefile.in: Add runtime pairs for Android. 
> Rework handling of s-oscons.ads. * s-osinte-android.ads,
> s-osinte-android.adb: New files.
> 
> +ifeq ($(strip $(filter-out arm% linux-androideabi,$(arch)
> $(osys)-$(word 4,$(targ,) +  LIBGNAT_TARGET_PAIRS = \ +  [...] 
> +  s-osinte.adb s-osinte.ads 
> Indeed I agree that the second snippet in the Makefile.in (as
> changed by Matthias on 2012-10-15) triggers anytime the first one
> (as added by Arnaud on 2012-11-06) triggered, so Arnaud's
> LIBGNAT_TARGET_PAIRS setting will always be overwritten by
> Matthias', so to speak, and thus the new s-osinte-android.* files
> never be used in the current code.  Arnaud, Matthias, please
> clarify the intended behavior?  Of course I would assume that for
> *-android* configurations the new s-osinte-android.* files be used,
> but as Arnaud's change has gone in after Matthias', so this can 
> never have worked (unless I'm confused)?

I think it is an unintended conflict, but then I'd leave it to Arnaud
to move the second snippet after the first.

(This shows that, in such a conversion to bash case statements, the
order should be reversed).

Paolo

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRpv8VAAoJEBvWZb6bTYbydrAP/2l4gMGykKZGtqbj+/9ta0jm
IlKJ3tZ1u8LupMX75Rb6l7Cx3268WLoAZY1gGceQZuSWX6cD1KNkHR8uMEsgXwmR
WAyRmp8m0FXcQEGC2rdUvRmV0OXIJU/EWhNGiH70pCxteLR8z3/rFAlRUNXGko/o
1od0RaR2jlT2+EBNaKE6PwMdFG94b0qeXEEpFy3/f7jr/5e+E5tcq1YuMg06xs6Q
xMIG9QyQlUUbR5o/1J4MVdDGbL0APqMm/E0R7aUsGHpNFBdn2hurEvVx72ZWWXv/
loEBDIkiNQAdv0JGRSJ+NhreoyZbbRXHzZnMXc0coQyLe+wmn396MAWaCadF7Vie
lKXN0HRUHTHzeroZPExxOvcXWx/+orgZLlXMMdC/jG3oGiouNQnEuJbKul53hmWz
VD1g7gCDyvZBaksFfZcV9GKQKbstf0y4ONOSJP2MyqIhLAzDLy59winv9ph95ymM
B/DFN+u3XWMIh0LV4+ngL2afhRpbLyhP0BOzrnNqiJ5fB9RiRhEHXJ4VCnMongB2
DAX2Fw2bsqKgJDi5pKesvXpozyAou2rRi+MQPKvkuHSI5xMg0w1qMgmesoLugPEu
Z1vMAr8H

Re: [ada, build] host/target configuration

[Paolo Bonzini]

Il 30/05/2013 09:21, Eric Botcazou ha scritto:
>> However, it seems that the first androideabi snippet was dead code.
>> Can you delete it in a follow-up?
> 
> No, it's not dead code, just broken at the moment, now fixed by:
> 
> 
> 2013-05-30  Eric Botcazou  
> 
>   * gcc-interface/Makefile.in (arm% androideabi): Robustify.
> 
> 

I don't think this fixes it.  The problem is that the second eabi
conditional overrides the first (the one for Android).

Paolo

Re: [ada, build] host/target configuration

[Eric Botcazou]

> I don't think this fixes it.  The problem is that the second eabi
> conditional overrides the first (the one for Android).

Then let's fix the second eabi or swap them, but the first one must stay.

-- 
Eric Botcazou

Re: [ada, build] host/target configuration

[Paolo Bonzini]

Il 30/05/2013 09:33, Eric Botcazou ha scritto:
>> I don't think this fixes it.  The problem is that the second eabi
>> > conditional overrides the first (the one for Android).
> Then let's fix the second eabi or swap them, but the first one must stay.

Yes, got it.  Swapping them looks like the right thing to do.

Paolo

[Patch, Fortran, committed] PR57458 - Relax two constraints for TS29113/assumed-rank

[Tobias Burnus]

A rather obvious patch - see PR for the quote from the standard. Thanks 
goes to Bill Long for finding and reporting the issue.


Committed as Rev. 199437 after build+regtesting on x86-64-gnu-linux.

Tobias
2013-05-30  Tobias Burnus  

	PR fortran/57458
	* interface.c (compare_parameter): Update C1239/C1240 constraint
	check for assumed-rank/TS29113.

2013-05-30  Tobias Burnus  

	PR fortran/57458
	* gfortran.dg/assumed_rank_13.f90: New.

diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 2f8c6a5..adc4e63 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2031,14 +2031,15 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
  || actual->symtree->n.sym->attr.volatile_)
   &&  (formal->attr.asynchronous || formal->attr.volatile_)
   && actual->rank && !gfc_is_simply_contiguous (actual, true)
-  && ((formal->as->type != AS_ASSUMED_SHAPE && !formal->attr.pointer)
+  && ((formal->as->type != AS_ASSUMED_SHAPE
+	   && formal->as->type != AS_ASSUMED_RANK && !formal->attr.pointer)
 	  || formal->attr.contiguous))
 {
   if (where)
-	gfc_error ("Dummy argument '%s' has to be a pointer or assumed-shape "
-		   "array without CONTIGUOUS attribute - as actual argument at"
-		   " %L is not simply contiguous and both are ASYNCHRONOUS "
-		   "or VOLATILE", formal->name, &actual->where);
+	gfc_error ("Dummy argument '%s' has to be a pointer, assumed-shape or "
+		   "assumed-rank array without CONTIGUOUS attribute - as actual"
+		   " argument at %L is not simply contiguous and both are "
+		   "ASYNCHRONOUS or VOLATILE", formal->name, &actual->where);
   return 0;
 }
 
--- /dev/null	2013-05-30 08:32:37.588061020 +0200
+++ gcc/gcc/testsuite/gfortran.dg/assumed_rank_13.f90	2013-05-30 09:15:58.302491343 +0200
@@ -0,0 +1,26 @@
+! { dg-do compile }
+!
+! PR fortran/57458
+!
+!
+
+  integer, pointer, asynchronous :: i(:)
+  integer, pointer, volatile :: j(:)
+  call foo(i)
+  call foo2(i)
+  call foo3(j)
+  call foo4(j)
+contains
+  subroutine foo(x)
+type(*), dimension(:), asynchronous :: x
+  end subroutine foo
+  subroutine foo2(x)
+type(*), dimension(..), asynchronous :: x
+  end subroutine foo2
+  subroutine foo3(x)
+type(*), dimension(:), asynchronous :: x
+  end subroutine foo3
+  subroutine foo4(x)
+type(*), dimension(..), asynchronous :: x
+  end subroutine foo4
+end

Re: [PATCH,i386] Default alignment for AMD BD and BT

[Uros Bizjak]

On Wed, May 29, 2013 at 1:28 PM, Gopalasubramanian, Ganesh
 wrote:

> We want this to be backported to GCC48 branch.
> Please approve.
>
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Tuesday, May 07, 2013 6:22 PM
> To: Gopalasubramanian, Ganesh
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH,i386] Default alignment for AMD BD and BT
>
> On Tue, May 7, 2013 at 9:16 AM, Gopalasubramanian, Ganesh 
>  wrote:
>
>> The patch updates the alignment values for AMD BD and BT architectures.
>>
>> "make -k check" passes.
>>
>> Is it OK for upstream?
>>
>> 2013-05-07  Ganesh Gopalasubramanian
>> 
>>
>> * config/i386/i386.c (processor_target_table): Modified default
>> alignment values for AMD BD and BT architectures.

This is OK, but please wait until 4.8 branch is open again.

Thanks,
Uros.

Re: [PATCH] Fix incorrect discriminator assignment.

[Andreas Schwab]

Rainer Orth  writes:

> And why do you add -gdwarf-2 in dg-options?  AFAICS all tests in
> gcc.dg/debug/dwarf2 are built with -gdwarf-2 anyway.

Do they?  Not here.

Executing on host: /daten/aranym/gcc/gcc-20130530/Build/gcc/xgcc 
-B/daten/aranym/gcc/gcc-20130530/Build/gcc/ 
/daten/aranym/gcc/gcc-20130530/gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never  -ansi -pedantic-errors 
-O0 -ffat-lto-objects -ffat-lto-objects -ffat-lto-objects -S  -o 
discriminator.s(timeout = 300)
spawn /daten/aranym/gcc/gcc-20130530/Build/gcc/xgcc 
-B/daten/aranym/gcc/gcc-20130530/Build/gcc/ 
/daten/aranym/gcc/gcc-20130530/gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never -ansi -pedantic-errors 
-O0 -ffat-lto-objects -ffat-lto-objects -ffat-lto-objects -S -o discriminator.s
PASS: gcc.dg/debug/dwarf2/discriminator.c (test for excess errors)
FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 11 [0-9]( 
is_stmt [0-9])?\n
FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 11 [0-9]( 
is_stmt [0-9])? discriminator 2\n
FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 11 [0-9]( 
is_stmt [0-9])? discriminator 1\n

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH, ARM][1 of 2] Add epilogue dwarf info for shrink-wrap

[Zhenqiang Chen]

On 17 May 2013 22:22, Ramana Radhakrishnan  wrote:
> On 05/16/13 07:27, Zhenqiang Chen wrote:
>>
>> On 15 May 2013 06:31, Ramana Radhakrishnan 
>> wrote:
>>>
>>> Sorry this had dropped off my list of patches to review somehow but
>>> anyway here's a first cut review.
>>>
>>> On Thu, Mar 21, 2013 at 6:58 AM, Zhenqiang Chen
>>>  wrote:

 Hi,

 When shrink-wrap is enabled, the "returns" from simple-return path and
 normal return path can be merged. The code is like:

   tst ...
   /  \
  |  push ...
  |  ...
  |  pop ...
   \  /
   bx lr

 If the dwarf info after "pop ..." is incorrect, the dwarf checks will
 fail at dwarf2cfi.c: function maybe_record_trace_start.

/* We ought to have the same state incoming to a given trace no
   matter how we arrive at the trace.  Anything else means we've
   got some kind of optimization error.  */
gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));

 The patch is to add epilogue dwarf info to make sure:

 Before "bx lr",
 * All registers saved in stack had been "restored".
 * .cfi_def_cfa_offset 0
 * .cfi_def_cfa_register is sp even if frame_pointer_needed

 Boot strapped and no make check regression.
>>>
>>>
>>> in what configuration - thumb2 / arm / cortex-a15 / cortex-a9 ? what
>>> languages and on what platform ?
>>
>>
>> Bootstrapped both arm and thumb2 on Pandaboard ES and Chromebook.
>> Pandaboard ES (cortex-a9):
>> --enable-languages=c,c++,fortran,objc,obj-c++ --with-arch=armv7-a
>> --with-float=hard --with-fpu=vfpv3-d16
>> --enable-languages=c,c++,fortran,objc,obj-c++ --with-arch=armv7-a
>> --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb
>>
>> Chromebook (cortext-a15):
>> --enable-languages=c,c++,fortran,objc,obj-c++ --with-arch=armv7-a
>> --with-tune=cortex-a15 --with-float=hard --with-fpu=vfpv3-d16
>> --enable-languages=c,c++,fortran,objc,obj-c++ --with-arch=armv7-a
>> --with-tune=cortex-a15 --with-float=hard --with-fpu=vfpv3-d16
>> --with-mode=thumb
>>
>> Regression tests on Pandborad ES for both arm and thumb2 with the same
>> configure as bootstrap.
>>

 Is it OK?
>>>
>>>
>>>
 @@ -25447,9 +25519,15 @@ arm_unwind_emit (FILE * asm_out_file, rtx insn)
handled_one = true;
break;
>>>
>>>
 +/* The INSN is generated in epilogue.  It is set as
 RTX_FRAME_RELATED_P
 +   to get correct dwarf info for shrink-wrap.  But We should not
 emit
 +   unwind info for it.  */
>>>
>>>
>>> s/dwarf/debug frame.
>>>
>>> REplace "But We should not emit unwind info for it " with " We should
>>> not emit unwind info for it because these are used either for pretend
>>> arguments or .  "
>>>
>>> I think you are correct that there is no need for unwind information
>>> as we only have unwind information valid at call points and in this
>>> case I wouldn't expect unwind information to need to be exact for
>>> pretend arguments
>>
>>
>> Thanks for the comments. The patch is updated and rebased to trunk.
>
>
>
> Ok if no regressions.
>
> regards
> Ramana

Thanks, committed to trunk (bootstrap on PandboardES and Chromebook
and no make check regression).

-Zhenqiang

RFA: Fix rtl-optimization/57439

[Joern Rennecke]

bootstrapped / regtested on i686-pc-linux-gnu
build / regtested for i686-pc-linux-gnu X sh-elf

Also, Andreas Schwab reported in the PR that he has successfully  
tested this patch on m68k.
2013-05-29  Joern Rennecke 

PR rtl-optimization/57439
* postreload.c (move2add_valid_value_p): Check that we have
a zero subreg_regno_offset when accessing the register in
the requested mode.

Index: postreload.c
===
--- postreload.c(revision 199387)
+++ postreload.c(working copy)
@@ -1726,10 +1726,25 @@ move2add_record_sym_value (rtx reg, rtx
 static bool
 move2add_valid_value_p (int regno, enum machine_mode mode)
 {
-  if (reg_set_luid[regno] <= move2add_last_label_luid
-  || !MODES_OK_FOR_MOVE2ADD (mode, reg_mode[regno]))
+  if (reg_set_luid[regno] <= move2add_last_label_luid)
 return false;
 
+  if (mode != reg_mode[regno])
+{
+  if (!MODES_OK_FOR_MOVE2ADD (mode, reg_mode[regno]))
+   return false;
+  /* For big endian, the starting regno for the subreg might be
+different.  */
+  int s_off = subreg_lowpart_offset (mode, reg_mode[regno]);
+  s_off = subreg_regno_offset (regno, reg_mode[regno], s_off, mode);
+  if (s_off != 0)
+   /* We could in principle adjust regno, check reg_mode[regno] to be
+  BLKmode, and return s_off to the caller (vs. -1 for failure),
+  but we currently have no callers that could make use of this
+  information.  */
+   return false;
+}
+
   for (int i = hard_regno_nregs[regno][mode] - 1; i > 0; i--)
 if (reg_mode[regno + i] != BLKmode)
   return false;

Re: [PATCH] Fix BB vectorization cost model wrt scalar uses

[Andreas Schwab]

Richard Biener  writes:

> Index: gcc/testsuite/gcc.dg/vect/bb-slp-32.c
> ===
> *** gcc/testsuite/gcc.dg/vect/bb-slp-32.c (revision 0)
> --- gcc/testsuite/gcc.dg/vect/bb-slp-32.c (working copy)
> ***
> *** 0 
> --- 1,23 
> + /* { dg-do compile } */
> + /* { dg-require-effective-target vect_int } */
> + /* { dg-additional-options "-fvect-cost-model" } */

The test fails on ia64.  The slp dump contains this:

/usr/local/gcc/gcc-20130530/gcc/testsuite/gcc.dg/vect/bb-slp-32.c:10: note: 
Failed to SLP the basic block.
/usr/local/gcc/gcc-20130530/gcc/testsuite/gcc.dg/vect/bb-slp-32.c:10: note: not 
vectorized: failed to find SLP opportunities in basic block.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [x86, PATCH 1/2] Enabling of the new Intel microarchitecture Silvermont

[Kirill Yukhin]

> This is OK for mainline.
Hi. Checked into GCC trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00965.html


Thanks, K

Re: [PATCH, AArch64] Re-organize aarch64_classify_symbol

[Marcus Shawcroft]

On 29/05/13 13:55, Marcus Shawcroft wrote:

This patch re-organizes the implementation of aarch64_classify_symbol in
preparation for add tiny absolute memory model support.

Regressed aarch64-none-elf, applied.

/Marcus

2013-05-29  Chris Schlumberger-Socha 
 Marcus Shawcroft  

 * config/aarch64/aarch64.c (aarch64_classify_symbol): Remove comment.
 Refactor if/switch.  Replace gcc_assert with if.


This time with patch attached...diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 12a7055..cbe7847 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5016,6 +5016,7 @@ aarch64_classify_tls_symbol (rtx x)
 
 /* Return the method that should be used to access SYMBOL_REF or
LABEL_REF X in context CONTEXT.  */
+
 enum aarch64_symbol_type
 aarch64_classify_symbol (rtx x,
 			 enum aarch64_symbol_context context ATTRIBUTE_UNUSED)
@@ -5038,48 +5039,34 @@ aarch64_classify_symbol (rtx x,
 	}
 }
 
-  gcc_assert (GET_CODE (x) == SYMBOL_REF);
-
-  switch (aarch64_cmodel)
+  if (GET_CODE (x) == SYMBOL_REF)
 {
-case AARCH64_CMODEL_LARGE:
-  return SYMBOL_FORCE_TO_MEM;
-
-case AARCH64_CMODEL_TINY:
-case AARCH64_CMODEL_SMALL:
-
-  /* This is needed to get DFmode, TImode constants to be loaded off
- the constant pool.  Is it necessary to dump TImode values into
- the constant pool.  We don't handle TImode constant loads properly
- yet and hence need to use the constant pool.  */
-  if (CONSTANT_POOL_ADDRESS_P (x))
-	return SYMBOL_FORCE_TO_MEM;
-
-  if (aarch64_tls_symbol_p (x))
-	return aarch64_classify_tls_symbol (x);
-
-  if (SYMBOL_REF_WEAK (x))
-	return SYMBOL_FORCE_TO_MEM;
-
-  return SYMBOL_SMALL_ABSOLUTE;
-
-case AARCH64_CMODEL_TINY_PIC:
-case AARCH64_CMODEL_SMALL_PIC:
-
-  if (CONSTANT_POOL_ADDRESS_P (x))
+  if (aarch64_cmodel == AARCH64_CMODEL_LARGE
+	  || CONSTANT_POOL_ADDRESS_P (x))
 	return SYMBOL_FORCE_TO_MEM;
 
   if (aarch64_tls_symbol_p (x))
 	return aarch64_classify_tls_symbol (x);
 
-  if (!aarch64_symbol_binds_local_p (x))
-	return SYMBOL_SMALL_GOT;
+  switch (aarch64_cmodel)
+	{
+	case AARCH64_CMODEL_TINY:
+	case AARCH64_CMODEL_SMALL:
+	  if (SYMBOL_REF_WEAK (x))
+	return SYMBOL_FORCE_TO_MEM;
+	  return SYMBOL_SMALL_ABSOLUTE;
 
-  return SYMBOL_SMALL_ABSOLUTE;
+	case AARCH64_CMODEL_TINY_PIC:
+	case AARCH64_CMODEL_SMALL_PIC:
+	  if (!aarch64_symbol_binds_local_p (x))
+	return SYMBOL_SMALL_GOT;
+	  return SYMBOL_SMALL_ABSOLUTE;
 
-default:
-  gcc_unreachable ();
+	default:
+	  gcc_unreachable ();
+	}
 }
+
   /* By default push everything into the constant pool.  */
   return SYMBOL_FORCE_TO_MEM;
 }

[Patch, Fortran, committed] PR 54189: ICE (segfault) with invalid assumed-size dummy

[Janus Weil]

Hi all,

I have just committed as obvious a small ICE-on-invalid fix:

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199445

Cheers,
Janus

Re: [Patch, Fortran] Enable FINALization/poly dealloc for allocatables

[Tobias Burnus]

Small update of the patch. Changes:

* There was a problem finalizing  "var(:)%comp", which lead to an ICE. 
Thanks to Dominique pointed out. See "expr->rank =" code added in 
gfc_add_finalizer_call. I added the full test case from PR37336 (dg-do 
compile: finalize_14.f90) to test for this.


* I added a new test case, which ensures that the built-in scalarizer 
and packer works correctly (it did), see finalize_13.f90.


The latter test case depends on the patch posted at: 
http://gcc.gnu.org/ml/fortran/2013-05/msg00114.html
[As Domique has pointed out, I forgot to change the allocate back to "t2 
::" in that test case. I will do so before committal (and change the 
malloc check to "(40)".)]



OK for the trunk?

Tobias


Tobias Burnus wrote:
this patch enables finalization (and polymorphic deallocation) for 
allocatables for: end of scope, DEALLOCATE and intent(out).


As a side effect, an allocatable is no longer deallocated at the end 
of the main program. (Variables declared in the main program have 
automatically SAVE attribute; before finalization, it made no 
difference but with finalization it is detectable. And only finalizing 
nonfinalizable allocatables seems to be too much effort for too little 
gain.)

...

Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias

PS: Fortran requires additional cases where finalization has to 
happen; those will be added in follow-up patches.
2013-05-30  Tobias Burnus  

	PR fortran/37336
	* trans-array.c (gfc_trans_dealloc_allocated): Support finalization.
	(structure_alloc_comps): Update caller.
	(gfc_trans_deferred_array): Call finalizer.
	* trans-array.h (gfc_trans_dealloc_allocated): Update prototype.
	* trans-decl.c (gfc_trans_deferred_vars): Don't deallocate/finalize
	variables of the main program.
	* trans-expr.c (gfc_conv_procedure_call): Support finalization.
	* trans-openmp.c (gfc_omp_clause_dtor,
	gfc_trans_omp_array_reduction): Update calls.
	* trans-stmt.c (gfc_trans_deallocate): Avoid double deallocation
	of alloc components.
	* trans.c (gfc_add_finalizer_call): New function.
	(gfc_deallocate_with_status,
	gfc_deallocate_scalar_with_status): Call it
	(gfc_build_final_call): Fix handling of scalar coarrays.

2013-05-30  Tobias Burnus  

	PR fortran/37336
	* gfortran.dg/finalize_12.f90: New.
	* gfortran.dg/alloc_comp_basics_1.f90: Add BLOCK for
	end of scope finalization.
	* gfortran.dg/alloc_comp_constructor_1.f90: Ditto.
	* gfortran.dg/allocatable_scalar_9.f90: Ditto.
	* gfortran.dg/auto_dealloc_2.f90: Ditto.
	* gfortran.dg/class_19.f03: Ditto.
	* gfortran.dg/coarray_lib_alloc_1.f90: Ditto.
	* gfortran.dg/coarray_lib_alloc_2.f90: Ditto.
	* gfortran.dg/extends_14.f03: Ditto.
	* gfortran.dg/move_alloc_4.f90: Ditto.
	* gfortran.dg/typebound_proc_27.f03: Ditto.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index be3a5a0..89f26d7 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -4834,7 +4834,8 @@ static tree
 gfc_array_init_size (tree descriptor, int rank, int corank, tree * poffset,
 		 gfc_expr ** lower, gfc_expr ** upper, stmtblock_t * pblock,
 		 stmtblock_t * descriptor_block, tree * overflow,
-		 tree expr3_elem_size, tree *nelems, gfc_expr *expr3)
+		 tree expr3_elem_size, tree *nelems, gfc_expr *expr3,
+		 gfc_typespec *ts)
 {
   tree type;
   tree tmp;
@@ -5012,6 +5013,9 @@ gfc_array_init_size (tree descriptor, int rank, int corank, tree * poffset,
 	  tmp = TYPE_SIZE_UNIT (tmp);
 	}
 }
+  else if (ts->type != BT_UNKNOWN && ts->type != BT_CHARACTER)
+/* FIXME: Properly handle characters.  See PR 57456.  */
+tmp = TYPE_SIZE_UNIT (gfc_typenode_for_spec (ts));
   else
 tmp = TYPE_SIZE_UNIT (gfc_get_element_type (type));
 
@@ -5081,7 +5085,7 @@ gfc_array_init_size (tree descriptor, int rank, int corank, tree * poffset,
 bool
 gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg,
 		tree errlen, tree label_finish, tree expr3_elem_size,
-		tree *nelems, gfc_expr *expr3)
+		tree *nelems, gfc_expr *expr3, gfc_typespec *ts)
 {
   tree tmp;
   tree pointer;
@@ -5166,7 +5170,7 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg,
   size = gfc_array_init_size (se->expr, ref->u.ar.as->rank,
 			  ref->u.ar.as->corank, &offset, lower, upper,
 			  &se->pre, &set_descriptor_block, &overflow,
-			  expr3_elem_size, nelems, expr3);
+			  expr3_elem_size, nelems, expr3, ts);
 
   if (dimension)
 {
@@ -7243,7 +7247,7 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr * expr, bool g77,
 /* Generate code to deallocate an array, if it is allocated.  */
 
 tree
-gfc_trans_dealloc_allocated (tree descriptor, bool coarray)
+gfc_trans_dealloc_allocated (tree descriptor, bool coarray, gfc_expr *expr)
 {
   tree tmp;
   tree var;
@@ -7259,7 +7263,7 @@ gfc_trans_dealloc_allocated (tree descriptor, bool coarray)
  are already deallocated are ignored.  */
   tmp = gfc_deallocate_with_status (coar

Re: Symtab cleanups 1/17

[Dominique Dhumieres]

Honza,

This caused/exposed pr57467.

TIA

Dominique

RE: [PATCH, AArch64] Support BFI instruction and insv standard pattern

[Ian Bolton]

> On 05/20/2013 11:55 AM, Ian Bolton wrote:
> > I improved this patch during the work I did on the recent insv_imm
> patch
> > (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01007.html).
> 
> Thanks, you cleaned up almost everything on which I would have
> commented
> with the previous patch revision.  The only thing left is:
> 
> > +  else if (!register_operand (value, mode))
> > +operands[3] = force_reg (mode, value);
> 
> Checking register_operand before force_reg is unnecessary; you're not
> saving a
> function call, and force_reg will itself perform the register check.

Thanks for the review, Richard.

Latest patch is attached, which fixes this.

Linux and bare-metal regression runs successful.

OK for trunk?

Cheers,
Ian


2013-05-30  Ian Bolton  

gcc/
* config/aarch64/aarch64.md (insv): New define_expand.
(*insv_reg): New define_insn.

testsuite/
* gcc.target/aarch64/insv_1.c: New test.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 2bdbfa9..89db092 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -3163,6 +3163,50 @@
(set_attr "mode" "")]
 )
 
+;; Bitfield Insert (insv)
+(define_expand "insv"
+  [(set (zero_extract:GPI (match_operand:GPI 0 "register_operand")
+ (match_operand 1 "const_int_operand")
+ (match_operand 2 "const_int_operand"))
+   (match_operand:GPI 3 "general_operand"))]
+  ""
+{
+  unsigned HOST_WIDE_INT width = UINTVAL (operands[1]);
+  unsigned HOST_WIDE_INT pos = UINTVAL (operands[2]);
+  rtx value = operands[3];
+
+  if (width == 0 || (pos + width) > GET_MODE_BITSIZE (mode))
+FAIL;
+
+  if (CONST_INT_P (value))
+{
+  unsigned HOST_WIDE_INT mask = ((unsigned HOST_WIDE_INT)1 << width) - 1;
+
+  /* Prefer AND/OR for inserting all zeros or all ones.  */
+  if ((UINTVAL (value) & mask) == 0
+  || (UINTVAL (value) & mask) == mask)
+   FAIL;
+
+  /* 16-bit aligned 16-bit wide insert is handled by insv_imm.  */
+  if (width == 16 && (pos % 16) == 0)
+   DONE;
+}
+  operands[3] = force_reg (mode, value);
+})
+
+(define_insn "*insv_reg"
+  [(set (zero_extract:GPI (match_operand:GPI 0 "register_operand" "+r")
+ (match_operand 1 "const_int_operand" "n")
+ (match_operand 2 "const_int_operand" "n"))
+   (match_operand:GPI 3 "register_operand" "r"))]
+  "!(UINTVAL (operands[1]) == 0
+ || (UINTVAL (operands[2]) + UINTVAL (operands[1])
+> GET_MODE_BITSIZE (mode)))"
+  "bfi\\t%0, %3, %2, %1"
+  [(set_attr "v8type" "bfm")
+   (set_attr "mode" "")]
+)
+
 (define_insn "*_shft_"
   [(set (match_operand:GPI 0 "register_operand" "=r")
(ashift:GPI (ANY_EXTEND:GPI
diff --git a/gcc/testsuite/gcc.target/aarch64/insv_1.c 
b/gcc/testsuite/gcc.target/aarch64/insv_1.c
new file mode 100644
index 000..bc8928d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/insv_1.c
@@ -0,0 +1,84 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps -fno-inline" } */
+
+extern void abort (void);
+
+typedef struct bitfield
+{
+  unsigned short eight: 8;
+  unsigned short four: 4;
+  unsigned short five: 5;
+  unsigned short seven: 7;
+  unsigned int sixteen: 16;
+} bitfield;
+
+bitfield
+bfi1 (bitfield a)
+{
+  /* { dg-final { scan-assembler "bfi\tx\[0-9\]+, x\[0-9\]+, 0, 8" } } */
+  a.eight = 3;
+  return a;
+}
+
+bitfield
+bfi2 (bitfield a)
+{
+  /* { dg-final { scan-assembler "bfi\tx\[0-9\]+, x\[0-9\]+, 16, 5" } } */
+  a.five = 7;
+  return a;
+}
+
+bitfield
+movk (bitfield a)
+{
+  /* { dg-final { scan-assembler "movk\tx\[0-9\]+, 0x1d6b, lsl 32" } } */
+  a.sixteen = 7531;
+  return a;
+}
+
+bitfield
+set1 (bitfield a)
+{
+  /* { dg-final { scan-assembler "orr\tx\[0-9\]+, x\[0-9\]+, 2031616" } } */
+  a.five = 0x1f;
+  return a;
+}
+
+bitfield
+set0 (bitfield a)
+{
+  /* { dg-final { scan-assembler "and\tx\[0-9\]+, x\[0-9\]+, -2031617" } } */
+  a.five = 0;
+  return a;
+}
+
+
+int
+main (int argc, char** argv)
+{
+  static bitfield a;
+  bitfield b = bfi1 (a);
+  bitfield c = bfi2 (b);
+  bitfield d = movk (c);
+
+  if (d.eight != 3)
+abort ();
+
+  if (d.five != 7)
+abort ();
+
+  if (d.sixteen != 7531)
+abort ();
+
+  d = set1 (d);
+  if (d.five != 0x1f)
+abort ();
+
+  d = set0 (d);
+  if (d.five != 0)
+abort ();
+
+  return 0;
+}
+
+/* { dg-final { cleanup-saved-temps } } */

Reduction of Logic to Arithmetic

[Ranganath kulkarni]

By using logic functions we can convert logical algorithm into simple
algorithm without logical trees. This converts logical operation to
algebraic manipulation or math equation. This article is posted to
viXra pre print archive link http://vixra.org/abs/1305.0080 Therefore
we can make efficient programming. A complex program can be executable
in an ordinary processor. Therefore it can be useful for mobile tablet
and all computers.

RE: [PATCH:RL78] Add new insn for mulqi3 and mulhi3

[Kaushik Phatak]

Ping.
Can I commit this with below changes?

Thanks,
Kaushik

-Original Message-
From: Kaushik Phatak 
Sent: 20 May 2013 20:17
To: gcc-patches@gcc.gnu.org
Cc: 'Richard Henderson'; DJ Delorie (d...@redhat.com)
Subject: RE: [PATCH:RL78] Add new insn for mulqi3 and mulhi3

Hi Richard,
Thanks for the quick review.

> No constraints on define_expand, only predicates.
>> +(define_insn "mulhi3_g13"
>These names are not used.  They should be prefixed with "*" to indicate the 
>name is just for documentation.

I have made the suggested changes. Please find below an updated version of this 
patch.
Let me know if OK to commit the same.

Regards,
Kaushik

2013-05-20  Kaushik Phatak  
   
* config/rl78/rl78.md (mulqi3,mulhi3): New define_expands.
(mulqi3_rl78,mulhi3_rl78,mulhi3_g13): New define_insns.

Index: gcc/config/rl78/rl78.md
===
--- gcc/config/rl78/rl78.md (revision 199105)
+++ gcc/config/rl78/rl78.md (working copy)
@@ -235,6 +235,24 @@
   [(set_attr "valloc" "macax")]
 )
 
+(define_expand "mulqi3"
+  [(set (match_operand:QI  0 "register_operand" "")
+   (mult:QI  (match_operand:QI 1 "general_operand" "")
+ (match_operand:QI 2 "nonmemory_operand" "")))
+   ]
+  "" ; mulu supported by all targets
+  ""
+)
+
+(define_expand "mulhi3"
+  [(set (match_operand:HI  0 "register_operand" "")
+   (mult:HI (match_operand:HI 1 "general_operand" "")
+(match_operand:HI 2 "nonmemory_operand" "")))
+   ]
+  "! RL78_MUL_NONE"
+  ""
+)
+
 (define_expand "mulsi3"
   [(set (match_operand:SI  0 "register_operand" "=&v")
(mult:SI (match_operand:SI 1 "nonmemory_operand" "vi") @@ -244,6 
+262,55 @@
   ""
 )
 
+(define_insn "*mulqi3_rl78"
+  [(set (match_operand:QI  0 "register_operand" "=&v")
+   (mult:QI (match_operand:QI 1 "general_operand" "+viU")
+(match_operand:QI 2 "general_operand" "vi")))
+   ]
+  "" ; mulu supported by all targets
+  "; mulqi macro %0 = %1 * %2
+   mova, %h1
+   movx, a
+   mova, %h2
+   mulu   x ; ax = a * x
+   mova, x
+   mov%h0, a
+   ; end of mulqi macro"
+)
+
+(define_insn "*mulhi3_rl78"
+  [(set (match_operand:HI  0 "register_operand" "=&v")
+   (mult:HI (match_operand:HI 1 "general_operand" "+viU")
+(match_operand:HI 2 "general_operand" "vi")))
+   ]
+  "RL78_MUL_RL78"
+  "; mulhi macro %0 = %1 * %2
+   movwax, %h1
+   movwbc, %h2
+   mulhu   ; bcax = bc * ax
+   movw%h0, ax
+   ; end of mulhi macro"
+)
+
+(define_insn "*mulhi3_g13"
+  [(set (match_operand:HI  0 "register_operand" "=&v")
+   (mult:HI (match_operand:HI 1 "general_operand" "+viU")
+(match_operand:HI 2 "general_operand" "vi")))
+   ]
+  "RL78_MUL_G13"
+  "; mulhi macro %0 = %1 * %2
+   mov a, #0x00
+   mov !0xf00e8, a ; MDUC
+   movwax, %h1
+   movw0x0, ax ; MDAL
+   movwax, %h2
+   movw0x2, ax ; MDAH
+   nop ; mdb = mdal * mdah
+   movwax, 0x6 ; MDBL
+   movw%h0, ax
+; end of mulhi macro"
+)
+
 ;; 0x0 is MACR(L).  0x2 is MACR(H) but we don't care about it  ;; 
because we're only using the lower 16 bits (which is the upper 16  ;; bits of 
the result).

Re: [ada, build] host/target configuration

[Arnaud Charlet]

> >>> The target_cpu_canonical substitution has been added in commit
> >>> 369e542b3ad1c0acfa9bfaeb72b338d8db5ba2ef (2009-02-27, r144463,
> >>> schwab) but unused ever since, thus removed.
> >>> 
> >>> I'll now be testing for x86 GNU/Linux and GNU/Hurd; further
> >>> testing appreciated.
> > For these two configurations, I have now successfully tested the
> > patch I posted.  Further review/testing appreciated.  (Adding
> > »build machinery (*.in)« maintainers.)
> > 
> > 
> 
> I agree that using $(target_os) and linux% matches is a better way to
> strip out the "-gnu"s.
> 
> The patch is long, but I think I reviewed it carefully enough.  It's
> okay for mainline.

Not so fast, we are talking about the Ada build machinery which requires
an Ada maintainer to review it.

The patch seems to go in the right direction but needs careful review
which hasn't been done yet, so please hold on your change for now, thanks.

In other words, this change will impact basically all targets, so needs
either much more testing, or more review, which is on going.

Arno

[x86, PATCH 2/2] Enabling of the new Intel microarchitecture Silvermont

[Yuri Rumyantsev]

Hi All!



Second patch enables several Silvermont uarch features which improve
performance of the new processor (based on experiments on real SLM
hardware):



1. If using a 2-source or 3-source LEA for non-destructive destination
purposes, or due to wanting ability to use SCALE, the use of LEA is
preferable.

2. Transformation of FP conversion for memory operands into conversion
from register.

3. Couple of improvements  for post-reload scheduling:

- increase latency of integer loads and load/store with exact dependence;

- simple re-ordering of the top of ready list - if 2 instructions
at the top of the list have the same priority we consider instruction
which producer(s) were scheduled earlier as the best candidate.

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

2013-05-30  Yuri Rumyantsev  
 Igor Zamyatin  

Silvermont (SLM) architecture performance tuning.
* config/i386/i386.h (enum ix86_tune_indices): Add
X86_TUNE_SPLIT_MEM_OPND_FOR_FP_CONVERTS.
(TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS): New define.

* config/i386/i386.c (initial_ix86_tune_features)
: Initialize.
(ix86_lea_outperforms): Handle Silvermont tuning.
(ix86_avoid_lea_for_add): Add new argument to ix86_lea_outperforms
call.
(ix86_use_lea_for_mov): Likewise.
(ix86_avoid_lea_for_addr): Likewise.
(ix86_lea_for_add_ok): Likewise.
(exact_dependency_1): New function.
(exact_store_load_dependency): Likewise.
(ix86_adjust_cost): Handle Silvermont tuning.
(do_reoder_for_imul): Likewise.
(swap_top_of_ready_list): New function.
(ix86_sched_reorder): Changed to handle Silvermont tuning.

* config/i386/i386.md (peepholes that split memory operand in fp
converts): New.

Re: [PATCH:RL78] Add new insn for mulqi3 and mulhi3

[Richard Henderson]

On 2013-05-30 06:25, Kaushik Phatak wrote:

Ping.
Can I commit this with below changes?

Thanks,
Kaushik

-Original Message-
From: Kaushik Phatak
Sent: 20 May 2013 20:17
To: gcc-patches@gcc.gnu.org
Cc: 'Richard Henderson'; DJ Delorie (d...@redhat.com)
Subject: RE: [PATCH:RL78] Add new insn for mulqi3 and mulhi3

Hi Richard,
Thanks for the quick review.


No constraints on define_expand, only predicates.

+(define_insn "mulhi3_g13"

These names are not used.  They should be prefixed with "*" to indicate the 
name is just for documentation.


I have made the suggested changes. Please find below an updated version of this 
patch.
Let me know if OK to commit the same.



Yes, this is fine.


r~

Re: [PATCH, AArch64] Support BFI instruction and insv standard pattern

[Richard Henderson]

On 2013-05-30 04:32, Ian Bolton wrote:

On 05/20/2013 11:55 AM, Ian Bolton wrote:

> >I improved this patch during the work I did on the recent insv_imm

>patch

> >(http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01007.html).

>
>Thanks, you cleaned up almost everything on which I would have
>commented
>with the previous patch revision.  The only thing left is:
>

> >+  else if (!register_operand (value, mode))
> >+operands[3] = force_reg (mode, value);

>
>Checking register_operand before force_reg is unnecessary; you're not
>saving a
>function call, and force_reg will itself perform the register check.

Thanks for the review, Richard.

Latest patch is attached, which fixes this.

Linux and bare-metal regression runs successful.



Ok.


r~

[x86, PATCH 2/2] Enabling of the new Intel microarchitecture Silvermont

[Yuri Rumyantsev]

Hi All

Second patch enables several Silvermont uarch features which improve
performance of the new processor (based on experiments on real SLM
hardware):
1. If using a 2-source or 3-source LEA for non-destructive destination
purposes, or due to wanting ability to use SCALE, the use of LEA is
preferable.
2. Transformation of FP conversion for memory operands into conversion
from register.
3. Couple of improvements  for post-reload scheduling:
- increase latency of integer loads and load/store with exact dependence;
- simple re-ordering of the top of ready list - if 2 instructions
at the top of the list have the same priority we consider instruction
which producer(s) were scheduled earlier as the best candidate.

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

2013-05-30  Yuri Rumyantsev  
 Igor Zamyatin  

Silvermont (SLM) architecture performance tuning.
* config/i386/i386.h (enum ix86_tune_indices): Add
X86_TUNE_SPLIT_MEM_OPND_FOR_FP_CONVERTS.
(TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS): New define.

* config/i386/i386.c (initial_ix86_tune_features)
: Initialize.
(ix86_lea_outperforms): Handle Silvermont tuning.
(ix86_avoid_lea_for_add): Add new argument to ix86_lea_outperforms
call.
(ix86_use_lea_for_mov): Likewise.
(ix86_avoid_lea_for_addr): Likewise.
(ix86_lea_for_add_ok): Likewise.
(exact_dependency_1): New function.
(exact_store_load_dependency): Likewise.
(ix86_adjust_cost): Handle Silvermont tuning.
(do_reoder_for_imul): Likewise.
(swap_top_of_ready_list): New function.
(ix86_sched_reorder): Changed to handle Silvermont tuning.

* config/i386/i386.md (peepholes that split memory operand in fp
converts): New


gcc_slm_patch2_2_review.patch
Description: Binary data

Re: [patch, mips] Fix for PR target/56942

[Steve Ellcey]

On Thu, 2013-05-30 at 00:15 +0200, Steven Bosscher wrote:

> And I can't get it to fail. I also can't find any place where the
> label and jump table might get separated. I was expecting some trouble
> with cross-jumping but it seems that it takes care of updating the
> label reference, and skip_insns_after_block already expects the label
> and table to be adjacent.
> 
> So let's just see if/what breaks...
> 
> Bootstrapped&tested on powerpc64-unknown-linux-gnu (unix{,-m32}).
> Bootstrapped&tested on x86_64-unknown-linux-gnu (unix{,-m32}).
> Build&tested powerpc64 X mips-elf.

I tested this with mips-mti-linux-gnu and mips-mti-elf by building cross
compilers and testing and I did not hit the assert either.

Steve Ellcey
sell...@imgtec.com

Re: [PATCH] Fix incorrect discriminator assignment.

[Dehao Chen]

On Thu, May 30, 2013 at 1:40 AM, Andreas Schwab  wrote:
> Rainer Orth  writes:
>
>> And why do you add -gdwarf-2 in dg-options?  AFAICS all tests in
>> gcc.dg/debug/dwarf2 are built with -gdwarf-2 anyway.
>
> Do they?  Not here.
>
> Executing on host: /daten/aranym/gcc/gcc-20130530/Build/gcc/xgcc 
> -B/daten/aranym/gcc/gcc-20130530/Build/gcc/ 
> /daten/aranym/gcc/gcc-20130530/gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c
>   -fno-diagnostics-show-caret -fdiagnostics-color=never  -ansi 
> -pedantic-errors -O0 -ffat-lto-objects -ffat-lto-objects -ffat-lto-objects -S 
>  -o discriminator.s(timeout = 300)
> spawn /daten/aranym/gcc/gcc-20130530/Build/gcc/xgcc 
> -B/daten/aranym/gcc/gcc-20130530/Build/gcc/ 
> /daten/aranym/gcc/gcc-20130530/gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c
>  -fno-diagnostics-show-caret -fdiagnostics-color=never -ansi -pedantic-errors 
> -O0 -ffat-lto-objects -ffat-lto-objects -ffat-lto-objects -S -o 
> discriminator.s
> PASS: gcc.dg/debug/dwarf2/discriminator.c (test for excess errors)
> FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 11 [0-9]( 
> is_stmt [0-9])?\n
> FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 11 [0-9]( 
> is_stmt [0-9])? discriminator 2\n
> FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 11 [0-9]( 
> is_stmt [0-9])? discriminator 1\n

That's weird cause in dwarf2.exp:

# If a testcase doesn't have special options, use these.
global DEFAULT_CFLAGS
if ![info exists DEFAULT_CFLAGS] then {
set DEFAULT_CFLAGS " -ansi -pedantic-errors -gdwarf-2"
}

But anyway, shall I add the -gdwarf-2 option back to discriminator.c?

Dehao

>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

[Patch, Fortran] Better error messages for type/rank checks

[Janus Weil]

Hi all,

the attached patch is a follow-up to my recent patch for PR57217. It
splits up the function 'compare_type_rank' into two separate ones
('compare_type' and 'compare_rank'), in order to generate more precise
error messages. In particular it now prints the values of the
differing types or ranks. The old function 'compare_type_rank' is
kept, since it is still needed in some places, but calls the two new
functions now.

In addition to this, the patch contains a part which concerns the
function 'gfc_terminal_width': Currently this returns a fixed value of
80, which means that all source lines are trimmed to 80 characters in
the error messages. I increased this default value to 132 (in order to
accommodate standard free-format lines), and added a part which tries
to determine the terminal width from the environment variable $COLUMNS
(the corresponding code was borrowed from gcc/opts.c). Further, I
moved the function to error.c (which is the only place where it is
used), made it static and renamed it.

The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2013-05-30  Janus Weil  

PR fortran/57217
* gfortran. h (gfc_terminal_width): Remove prototype.
* error.c (get_terminal_width): Moved here from misc.c. Renamed.
Try to determine terminal width from environment variable. Increase
default value to 132.
* interface.c (compare_type, compare_rank): New functions.
(compare_type_rank, check_dummy_characteristics,
check_result_characteristics, gfc_compare_interfaces): Use them.
(symbol_rank): Slightly modified and moved.
* misc.c (gfc_terminal_width): Moved to error.c.


2013-05-30  Janus Weil  

PR fortran/57217
* gfortran.dg/dummy_procedure_5.f90: Modified error message.
* gfortran.dg/interface_26.f90: Ditto.
* gfortran.dg/proc_ptr_11.f90: Ditto.
* gfortran.dg/proc_ptr_15.f90: Ditto.
* gfortran.dg/proc_ptr_comp_20.f90: Ditto.
* gfortran.dg/proc_ptr_comp_33.f90: Ditto.
* gfortran.dg/proc_ptr_result_5.f90: Ditto.
* gfortran.dg/typebound_override_1.f90: Ditto.
* gfortran.dg/typebound_override_4.f90: Ditto.
* gfortran.dg/typebound_proc_6.f03: Ditto.


compare_type_rank.diff
Description: Binary data

Re: [x86, PATCH 2/2] Enabling of the new Intel microarchitecture Silvermont

[Uros Bizjak]

On Thu, May 30, 2013 at 4:25 PM, Yuri Rumyantsev  wrote:
> Hi All
>
> Second patch enables several Silvermont uarch features which improve
> performance of the new processor (based on experiments on real SLM
> hardware):
> 1. If using a 2-source or 3-source LEA for non-destructive destination
> purposes, or due to wanting ability to use SCALE, the use of LEA is
> preferable.
> 2. Transformation of FP conversion for memory operands into conversion
> from register.
> 3. Couple of improvements  for post-reload scheduling:
> - increase latency of integer loads and load/store with exact dependence;
> - simple re-ordering of the top of ready list - if 2 instructions
> at the top of the list have the same priority we consider instruction
> which producer(s) were scheduled earlier as the best candidate.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
>
> 2013-05-30  Yuri Rumyantsev  
>  Igor Zamyatin  
>
> Silvermont (SLM) architecture performance tuning.
> * config/i386/i386.h (enum ix86_tune_indices): Add
> X86_TUNE_SPLIT_MEM_OPND_FOR_FP_CONVERTS.
> (TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS): New define.
>
> * config/i386/i386.c (initial_ix86_tune_features)
> : Initialize.
> (ix86_lea_outperforms): Handle Silvermont tuning.
> (ix86_avoid_lea_for_add): Add new argument to ix86_lea_outperforms
> call.
> (ix86_use_lea_for_mov): Likewise.
> (ix86_avoid_lea_for_addr): Likewise.
> (ix86_lea_for_add_ok): Likewise.
> (exact_dependency_1): New function.
> (exact_store_load_dependency): Likewise.
> (ix86_adjust_cost): Handle Silvermont tuning.
> (do_reoder_for_imul): Likewise.
> (swap_top_of_ready_list): New function.
> (ix86_sched_reorder): Changed to handle Silvermont tuning.
>
> * config/i386/i386.md (peepholes that split memory operand in fp
> converts): New

@@ -24625,9 +24730,9 @@ ix86_sched_reorder(FILE *dump, int
sched_verbose, rtx *ready, int *pn_ready,

-  con = DEP_CON (dep);
-  if (!NONDEBUG_INSN_P (con))
-continue;
+  con = DEP_CON (dep);
+  if (!NONDEBUG_INSN_P (con))
+continue;

There are some unnecessary whitespace changes (tabs->spaces) in a
couple of places throughout the patch, such as in the above lines.

+(define_peephole2
+  [(set (match_operand:DF 0 "register_operand")
+(float_extend:DF
+  (match_operand:SF 1 "memory_operand")))]
+  "TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS
+   && optimize_insn_for_speed_p ()
+   && SSE_REG_P (operands[0])"
+  [(set (match_dup 2) (match_dup 1))
+   (set (match_dup 0) (float_extend:DF (match_dup 2)))]
+{
+  operands[2] = gen_rtx_REG (SFmode, REGNO (operands[0]));
+})

You should use

(match_scratch:SF 2 "x")

at the top of the peephole2 pattern, and you will get a free scratch
register (assuming that it is not necessary to use the same register
for input and output operand of the float_extend insn).

Otherwise, the patch looks OK to me.

Uros.

Re: [PATCH] Fix incorrect discriminator assignment.

[Cary Coutant]

> That's weird cause in dwarf2.exp:
>
> # If a testcase doesn't have special options, use these.
> global DEFAULT_CFLAGS
> if ![info exists DEFAULT_CFLAGS] then {
> set DEFAULT_CFLAGS " -ansi -pedantic-errors -gdwarf-2"
> }
>
> But anyway, shall I add the -gdwarf-2 option back to discriminator.c?

I think that gets overridden by dg-options. If you use {
dg-additional-options "-O2" } instead, it should still pass -gdwarf-2
(along with the other two).

-cary

Re: [PATCH] Fix incorrect discriminator assignment.

[Dehao Chen]

On Thu, May 30, 2013 at 10:41 AM, Cary Coutant  wrote:
>> That's weird cause in dwarf2.exp:
>>
>> # If a testcase doesn't have special options, use these.
>> global DEFAULT_CFLAGS
>> if ![info exists DEFAULT_CFLAGS] then {
>> set DEFAULT_CFLAGS " -ansi -pedantic-errors -gdwarf-2"
>> }
>>
>> But anyway, shall I add the -gdwarf-2 option back to discriminator.c?
>
> I think that gets overridden by dg-options. If you use {
> dg-additional-options "-O2" } instead, it should still pass -gdwarf-2
> (along with the other two).

In the current test, I didn't use dg-options, but dg-additional-options instead:

/* { dg-additional-options "-O0" } */

Dehao
>
> -cary

PR57073 - Optimize __builtin_powif (-1.0, k) to k & 1 ? -1.0 : 1.0

[Tobias Burnus]

The attached patch optimizes
  __result_f = __builtin_powif (-1.0e+0, k);
to
  powi_cond_4 = k_1(D) & 1;
  powi_5 = powi_cond_4 ? -1.0e+0 : 1.0e+0;

I did an all-language (all,ada,go,objc++) bootstrap and regtest on 
x86-64-gnu-linux.

OK for the trunk?


Additionally, I would like to thank Thomas, who tried several approaches 
(e.g. fold_builtin_powi - which turned out to failed when called during 
optimization time, as regimplifing had problems with the COND_EXPR) and 
paved the way for this patch. And to Jakub, who gave helpful hints.


Note: Other replacements are also possible, e.g. "1.0 - (float) ((k & 1) 
<< 1)". However, the condition above turned out to be fasted as Jakub 
expected and Thomas has tested (see PR).



Tobias
2013-05-30  Tobias Brusnu  

	PR middle-end/57073
	* tree-ssa-math-opts.c (execute_cse_sincos): Optimize
	powi (-1.0, k) to (k & 1) ? -1.0 : 1.0.

2013-05-30  Tobias Brusnu  

	PR middle-end/57073
	* gfortran.dg/power_6.f90: New.

diff --git a/gcc/testsuite/gfortran.dg/power_6.f90 b/gcc/testsuite/gfortran.dg/power_6.f90
new file mode 100644
index 000..65d1bd0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/power_6.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-options "-O1 -fdump-tree-optimized" }
+!
+! PR middle-end/57073
+! See also PR 57073
+!
+real function f(k)
+  integer, value :: k
+  f = (-1.0)**k
+end
+
+! { dg-final { scan-tree-dump-not "__builtin_powif"  "optimized" } }
+! { dg-final { scan-tree-dump "powi_cond_\[0-9\] = k_\[0-9\]\\(D\\) & 1;"  "optimized" } }
+! { dg-final { scan-tree-dump "powi_\[0-9\] = powi_cond_\[0-9\] \\? -1.0e\\+0 : 1.0e\\+0;"  "optimized" } }
+! { dg-final { cleanup-tree-dump "optimized" } }
diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index a94172d..a15c404 100644
--- a/gcc/tree-ssa-math-opts.c
+++ b/gcc/tree-ssa-math-opts.c
@@ -1445,12 +1445,43 @@ execute_cse_sincos (void)
 		CASE_FLT_FN (BUILT_IN_POWI):
 		  arg0 = gimple_call_arg (stmt, 0);
 		  arg1 = gimple_call_arg (stmt, 1);
-		  if (!host_integerp (arg1, 0))
-		break;
-
-		  n = TREE_INT_CST_LOW (arg1);
 		  loc = gimple_location (stmt);
-		  result = gimple_expand_builtin_powi (&gsi, loc, arg0, n);
+
+		  if (real_minus_onep (arg0)
+		  && TREE_CODE (TREE_TYPE (arg1)) == INTEGER_TYPE
+		  && !host_integerp (arg1,0))
+		{
+  tree t0, t1, cond, one, minus_one;
+		  gimple stmt;
+
+		  t0 = TREE_TYPE (arg0);
+		  t1 = TREE_TYPE (arg1);
+		  one = build_real (t0, dconst1);
+		  minus_one = build_real (t0, dconstm1);
+
+		  cond = make_temp_ssa_name (t1, NULL, "powi_cond");
+		  stmt = gimple_build_assign_with_ops (BIT_AND_EXPR, cond,
+			   arg1,
+			   build_int_cst (t1,
+	  1));
+		  gimple_set_location (stmt, loc);
+		  gsi_insert_before (&gsi, stmt, GSI_SAME_STMT);
+
+		  result = make_temp_ssa_name (t0, NULL, "powi");
+		  stmt = gimple_build_assign_with_ops (COND_EXPR, result,
+			   cond,
+			   minus_one, one);
+		  gimple_set_location (stmt, loc);
+		  gsi_insert_before (&gsi, stmt, GSI_SAME_STMT);
+		}
+		  else
+		{
+		  if (!host_integerp (arg1, 0))
+			break;
+
+		  n = TREE_INT_CST_LOW (arg1);
+		  result = gimple_expand_builtin_powi (&gsi, loc, arg0, n);
+		}
 
 		  if (result)
 		{

Re: PR57073 - Optimize __builtin_powif (-1.0, k) to k & 1 ? -1.0 : 1.0

[Jeff Law]

On 05/30/2013 12:08 PM, Tobias Burnus wrote:

+   }
+ else
+   {
+ if (!host_integerp (arg1, 0))
+   break;
+
+ n = TREE_INT_CST_LOW (arg1);
+ result = gimple_expand_builtin_powi (&gsi, loc, arg0, n);
+   }
In this case, why even bother with gimple_expand_builtin_powi.  Don't we 
know the result simply by looking at N and setting the dest to -1.0 or 
1.0 appropriately?


I don't see that powi_as_mults optimizes the case where both args are 
constants and thus the result is a trivially computable compile time 
constant.


Am I missing something?

Granted, I wouldn't expect it to happen often, but we might have started 
with a variable exponent and through various opts eventually collapsed 
it down to a known constant.



jeff

Re: [c++-concepts]

[Gabriel Dos Reis]

Andrew Sutton  writes:

| This is a kind of large patch. It provides support for parsing
| constraints, the new concept declaration specifier (with some
| semantics implemented), and the infrastructure for creating and
| comparing constraints.

See comments below.  Patch OK when the comments are addressed.

In general:
  * Check against cxx11 dialect, not cxx0x.

  * Any particular reason to use classes with operator() for the 
parseers and the combinators?  GCC can inline indirect calls to
functions with internal linkage.  That should cut down on the
constructor boilerplates.  This particular change can be addressed
after the commit.

| +
| +namespace {
| +// A helper function. Returns the object pointed to by P
| +// and sets P to NULL.
| +template
| +inline T* take(T*& p)
| +{
| +  T* q = p;
| +  p = NULL;
| +  return q;
| +}
| +} // namespace
| +
| +

Call it 'release' -- following standard library terminology.

| +// Require that pointer P is non-null before returning.
| +template
| +inline T*
| +require (T* p)
| +{
| +  gcc_assert (p);
| +  return p;
| +}

The name 'require' is too vague compared to the documentation; and also
too close to 'requires' when the later becomes a keyword in C++17, we
don't want to get confused.

Suggestion: nonnull_or_else? or assert_nonnull? or check_nonnull?
or validate?

| -  /* 1 spare bit */
| +  unsigned concept_p : 1;  /* var or fn */
| +  /* 0 spare bit */
|  };

Hmm I don't understand the comment "var or fn".
If it is declared a concept, how can it it be a var?


-- Gaby

Re: [c++-concepts]

[Andrew Sutton]

>   * Check against cxx11 dialect, not cxx0x.

Let's talk about this tomorrow. I'm not quite sure how to do this.

>   * Any particular reason to use classes with operator() for the
> parseers and the combinators?  GCC can inline indirect calls to
> functions with internal linkage.  That should cut down on the
> constructor boilerplates.  This particular change can be addressed
> after the commit.

Some of the other combinators that I've built for the requires
expression have data fields that act as arguments to the actual other
cp_parser_* calls. I'll submit those with the relevant patch.

This should be easy to refactor, though.

> | +template
> | +inline T* take(T*& p)
> | +{
> | +  T* q = p;
> | +  p = NULL;
> | +  return q;
> | +}
> | +} // namespace
> | +
> | +
>
> Call it 'release' -- following standard library terminology.

Ah... yes. Good name.

> Suggestion: nonnull_or_else? or assert_nonnull? or check_nonnull?
> or validate?

check_nonnull is a good name.

> | -  /* 1 spare bit */
> | +  unsigned concept_p : 1;  /* var or fn */
> | +  /* 0 spare bit */
> |  };
>
> Hmm I don't understand the comment "var or fn".
> If it is declared a concept, how can it it be a var?

Copied from the other bits in the class. I think it means it applies
to either variables or functions. I left it that way in anticipation
of template variables.

C++ PATCH for c++/57404 (ICE with -g and VLA capture)

[Jason Merrill]

The anonymous struct type that I'm using for VLA capture doesn't have 
TYPE_LANG_SPECIFIC.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8cc312abec2ea0f134d6991c0c8e7a070ce611db
Author: Jason Merrill 
Date:   Thu May 30 09:59:25 2013 -0400

	PR c++/57404
	* cp-lang.c (cp_classify_record): Handle structs without
	TYPE_LANG_SPECIFIC.

diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
index 47a6004..a7fa8e4 100644
--- a/gcc/cp/cp-lang.c
+++ b/gcc/cp/cp-lang.c
@@ -127,7 +127,8 @@ cxx_dwarf_name (tree t, int verbosity)
 static enum classify_record
 cp_classify_record (tree type)
 {
-  if (CLASSTYPE_DECLARED_CLASS (type))
+  if (TYPE_LANG_SPECIFIC (type)
+  && CLASSTYPE_DECLARED_CLASS (type))
 return RECORD_IS_CLASS;
 
   return RECORD_IS_STRUCT;
diff --git a/gcc/testsuite/g++.dg/cpp1y/vla6.C b/gcc/testsuite/g++.dg/cpp1y/vla6.C
new file mode 100644
index 000..b725e7b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/vla6.C
@@ -0,0 +1,14 @@
+// PR c++/57404
+// { dg-options "-std=c++11 -g" }
+
+void f (int i)
+{
+  int a[i];
+  [&a] {};
+}
+
+void g (int i)
+{
+  int a[i];
+  [&a] {} ();
+}

C++ PATCH for c++/52377 (NSDMI and unions)

[Jason Merrill]

sort_mem_initializers was skipping over all fields without a 
mem-initializer, even ones with an NSDMI.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 25b01320a7aefae42d9e14f3807247ca8f88ae40
Author: Jason Merrill 
Date:   Sat May 25 17:28:15 2013 -0400

	PR c++/52377
	* class.c (common_enclosing_class): New.
	* cp-tree.h: Declare it.
	* init.c (sort_mem_initializers): Don't splice out a union member
	with an NSDMI.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 90b31bf..64918c6 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -9261,4 +9261,30 @@ publicly_uniquely_derived_p (tree parent, tree type)
   return base && base != error_mark_node;
 }
 
+/* CTX1 and CTX2 are declaration contexts.  Return the innermost common
+   class between them, if any.  */
+
+tree
+common_enclosing_class (tree ctx1, tree ctx2)
+{
+  if (!TYPE_P (ctx1) || !TYPE_P (ctx2))
+return NULL_TREE;
+  gcc_assert (ctx1 == TYPE_MAIN_VARIANT (ctx1)
+	  && ctx2 == TYPE_MAIN_VARIANT (ctx2));
+  if (ctx1 == ctx2)
+return ctx1;
+  for (tree t = ctx1; TYPE_P (t); t = TYPE_CONTEXT (t))
+TYPE_MARKED_P (t) = true;
+  tree found = NULL_TREE;
+  for (tree t = ctx2; TYPE_P (t); t = TYPE_CONTEXT (t))
+if (TYPE_MARKED_P (t))
+  {
+	found = t;
+	break;
+  }
+  for (tree t = ctx1; TYPE_P (t); t = TYPE_CONTEXT (t))
+TYPE_MARKED_P (t) = false;
+  return found;
+}
+
 #include "gt-cp-class.h"
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 1f85ca7..aebc440 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5112,6 +5112,7 @@ extern void deduce_noexcept_on_destructor   (tree);
 extern void insert_late_enum_def_into_classtype_sorted_fields (tree, tree);
 extern bool uniquely_derived_from_p (tree, tree);
 extern bool publicly_uniquely_derived_p (tree, tree);
+extern tree common_enclosing_class		(tree, tree);
 
 /* in cvt.c */
 extern tree convert_to_reference		(tree, tree, int, int, tree,
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 671c774..4edd150 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -914,13 +914,12 @@ sort_mem_initializers (tree t, tree mem_inits)
  Here we also splice out uninitialized union members.  */
   if (uses_unions_p)
 {
-  tree last_field = NULL_TREE;
+  tree *last_p = NULL;
   tree *p;
   for (p = &sorted_inits; *p; )
 	{
 	  tree field;
 	  tree ctx;
-	  int done;
 
 	  init = *p;
 
@@ -940,22 +939,25 @@ sort_mem_initializers (tree t, tree mem_inits)
 	  for (ctx = DECL_CONTEXT (field);
 	   !same_type_p (ctx, t);
 	   ctx = TYPE_CONTEXT (ctx))
-	if (TREE_CODE (ctx) == UNION_TYPE)
+	if (TREE_CODE (ctx) == UNION_TYPE
+		|| !ANON_AGGR_TYPE_P (ctx))
 	  break;
 	  /* If this field is not a member of a union, skip it.  */
 	  if (TREE_CODE (ctx) != UNION_TYPE)
 	goto next;
 
-	  /* If this union member has no explicit initializer, splice
-	 it out.  */
-	  if (!TREE_VALUE (init))
+	  /* If this union member has no explicit initializer and no NSDMI,
+	 splice it out.  */
+	  if (TREE_VALUE (init) || DECL_INITIAL (field))
+	/* OK.  */;
+	  else
 	goto splice;
 
 	  /* It's only an error if we have two initializers for the same
 	 union type.  */
-	  if (!last_field)
+	  if (!last_p)
 	{
-	  last_field = field;
+	  last_p = p;
 	  goto next;
 	}
 
@@ -967,41 +969,23 @@ sort_mem_initializers (tree t, tree mem_inits)
 	   union { struct { int i; int j; }; };
 
 	 initializing both `i' and `j' makes sense.  */
-	  ctx = DECL_CONTEXT (field);
-	  done = 0;
-	  do
+	  ctx = common_enclosing_class (DECL_CONTEXT (field),
+	DECL_CONTEXT (TREE_PURPOSE (*last_p)));
+
+	  if (ctx && TREE_CODE (ctx) == UNION_TYPE)
 	{
-	  tree last_ctx;
-
-	  last_ctx = DECL_CONTEXT (last_field);
-	  while (1)
-		{
-		  if (same_type_p (last_ctx, ctx))
-		{
-		  if (TREE_CODE (ctx) == UNION_TYPE)
-			error_at (DECL_SOURCE_LOCATION (current_function_decl),
-  "initializations for multiple members of %qT",
-  last_ctx);
-		  done = 1;
-		  break;
-		}
-
-		  if (same_type_p (last_ctx, t))
-		break;
-
-		  last_ctx = TYPE_CONTEXT (last_ctx);
-		}
-
-	  /* If we've reached the outermost class, then we're
-		 done.  */
-	  if (same_type_p (ctx, t))
-		break;
-
-	  ctx = TYPE_CONTEXT (ctx);
+	  /* A mem-initializer hides an NSDMI.  */
+	  if (TREE_VALUE (init) && !TREE_VALUE (*last_p))
+		*last_p = TREE_CHAIN (*last_p);
+	  else if (TREE_VALUE (*last_p) && !TREE_VALUE (init))
+		goto splice;
+	  else
+		error_at (DECL_SOURCE_LOCATION (current_function_decl),
+			  "initializations for multiple members of %qT",
+			  ctx);
 	}
-	  while (!done);
 
-	  last_field = field;
+	  last_p = p;
 
 	next:
 	  p = &TREE_CHAIN (*p);
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-union1.C b/gcc/testsuite/g++.dg/cpp0x/nsdmi-union1.C
new file mode 100644
index 000..11bdd88
--- /dev/null
+++ b/gcc/testsu

[PATCH] libgomp testsuite fixes

[Cesar Philippidis]

Here is a patch from our backlog at Mentor Graphics that addresses a 
libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following 
error with dejagnu:

ERROR: (DejaGnu) proc "libgomp_target_compile linker_plugin9263.c 
linker_plugin9263.exe executable {{additional_flags=-flto 
-fuse-linker-plugin}}" does not exist.

This problem usually does not occur since the default site.exp does not
contain ENABLE_LTO=1. I tested both with and without our custom site.exp.

Is it OK for trunk? If so, please check it in since I do not have commit
rights.

Cesar Philippidis


2013-05-30  Iain Sandoe  
Cesar Philippidis  

libgomp/
* testsuite/lib/libgomp.exp: Reorder lib loads into dependency order.
Do not load_gcc_lib gcc-dg.exp and add a comment as to why.
* testsuite/libgomp.c/c.exp: load_gcc_lib gcc-dg.exp.
* testsuite/libgomp.fortran/fortran.exp: Likewise.
* testsuite/libgomp.graphite/graphite.exp: Likewise.
* testsuite/libgomp.c++/c++.exp: load_gcc_lib gcc-dg.exp.
Use dg-runtest rather than gfortran-dg-runtest.
Index: libgomp/testsuite/libgomp.fortran/fortran.exp
===
--- libgomp/testsuite/libgomp.fortran/fortran.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.fortran/fortran.exp   (working copy)
@@ -1,4 +1,6 @@
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
+load_gcc_lib gfortran-dg.exp
 
 global shlib_ext
 global ALWAYS_CFLAGS
Index: libgomp/testsuite/lib/libgomp.exp
===
--- libgomp/testsuite/lib/libgomp.exp   (revision 199267)
+++ libgomp/testsuite/lib/libgomp.exp   (working copy)
@@ -9,24 +9,27 @@
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
+load_gcc_lib prune.exp
+load_gcc_lib target-libpath.exp
+load_gcc_lib wrapper.exp
+load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
 load_gcc_lib target-supports-dg.exp
 load_gcc_lib scanasm.exp
 load_gcc_lib scandump.exp
 load_gcc_lib scanrtl.exp
 load_gcc_lib scantree.exp
 load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout-dg.exp
 load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
-load_gcc_lib gfortran-dg.exp
 
 set dg-do-what-default run
 
Index: libgomp/testsuite/libgomp.c/c.exp
===
--- libgomp/testsuite/libgomp.c/c.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.c/c.exp   (working copy)
@@ -7,6 +7,7 @@
 }
 
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 # If a testcase doesn't have special options, use these.
 if ![info exists DEFAULT_CFLAGS] then {
Index: libgomp/testsuite/libgomp.graphite/graphite.exp
===
--- libgomp/testsuite/libgomp.graphite/graphite.exp (revision 199267)
+++ libgomp/testsuite/libgomp.graphite/graphite.exp (working copy)
@@ -23,6 +23,7 @@
 }
 
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 if ![check_effective_target_pthread] {
   return
Index: libgomp/testsuite/libgomp.c++/c++.exp
===
--- libgomp/testsuite/libgomp.c++/c++.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.c++/c++.exp   (working copy)
@@ -1,4 +1,5 @@
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 global shlib_ext
 
@@ -53,7 +54,7 @@
 }
 
 # Main loop.
-gfortran-dg-runtest $tests $libstdcxx_includes
+dg-runtest $tests "" $libstdcxx_includes
 }
 
 # All done.

[PATCH] libitm testsuite fixes

[Cesar Philippidis]

Here is a patch from our backlog that addresses a libitm issue where 
setting ENABLE_LTO=1 in site.exp causes the following error with dejagnu:

ERROR: (DejaGnu) proc "libitm_target_compile linker_plugin19344.c 
linker_plugin19344.exe executable {{additional_flags=-flto 
-fuse-linker-plugin}}" does not exist.

This problem usually does not occur since the default site.exp does not
contain ENABLE_LTO=1. This patch has been tested both with and without
our custom site.exp.

Is this OK for trunk? If so, please check it in since I do not have commit
rights.

Cesar Philippidis


2013-05-30  Iain Sandoe  
Cesar Philippidis  

libitm/
* testsuite/lib/libitm.exp: Reorder lib loads into dependency order.
Do not load_gcc_lib gcc-dg.exp and add a comment as to why.
* testsuite/libitm.c/c.exp: load_gcc_lib gcc-dg.exp.
* testsuite/libitm.c++/c++.exp: load_gcc_lib gcc-dg.exp.
Index: libitm/testsuite/lib/libitm.exp
===
--- libitm/testsuite/lib/libitm.exp (revision 199267)
+++ libitm/testsuite/lib/libitm.exp (working copy)
@@ -23,23 +23,27 @@
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
+load_gcc_lib prune.exp
+load_gcc_lib target-libpath.exp
+load_gcc_lib wrapper.exp
+load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
 load_gcc_lib target-supports-dg.exp
 load_gcc_lib scanasm.exp
 load_gcc_lib scandump.exp
 load_gcc_lib scanrtl.exp
 load_gcc_lib scantree.exp
 load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout-dg.exp
 load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
 
 set dg-do-what-default run
 
Index: libitm/testsuite/libitm.c++/c++.exp
===
--- libitm/testsuite/libitm.c++/c++.exp (revision 199267)
+++ libitm/testsuite/libitm.c++/c++.exp (working copy)
@@ -15,6 +15,7 @@
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
 
 load_lib libitm-dg.exp
+load_gcc_lib gcc-dg.exp
 
 global shlib_ext
 
Index: libitm/testsuite/libitm.c/c.exp
===
--- libitm/testsuite/libitm.c/c.exp (revision 199267)
+++ libitm/testsuite/libitm.c/c.exp (working copy)
@@ -21,6 +21,7 @@
 }
 
 load_lib libitm-dg.exp
+load_gcc_lib gcc-dg.exp
 
 # If a testcase doesn't have special options, use these.
 if ![info exists DEFAULT_CFLAGS] then {

Re: [c++-concepts]

[Gabriel Dos Reis]

Andrew Sutton  writes:

| >   * Check against cxx11 dialect, not cxx0x.
| 
| Let's talk about this tomorrow. I'm not quite sure how to do this.
| 
| >   * Any particular reason to use classes with operator() for the
| > parseers and the combinators?  GCC can inline indirect calls to
| > functions with internal linkage.  That should cut down on the
| > constructor boilerplates.  This particular change can be addressed
| > after the commit.
| 
| Some of the other combinators that I've built for the requires
| expression have data fields that act as arguments to the actual other
| cp_parser_* calls. I'll submit those with the relevant patch.

Ah, OK, that makes sense.

[...]

| > | -  /* 1 spare bit */
| > | +  unsigned concept_p : 1;  /* var or fn */
| > | +  /* 0 spare bit */
| > |  };
| >
| > Hmm I don't understand the comment "var or fn".
| > If it is declared a concept, how can it it be a var?
| 
| Copied from the other bits in the class. I think it means it applies
| to either variables or functions. I left it that way in anticipation
| of template variables.

OK; in that case, add some expalanation :-)

Once you've committed the patch, let me know so I can synchronize with
trunk -- or is there another patch coming in this week?

-- Gaby

RE: [PING]RE: [patch] cilkplus: Array notation for C patch

[Iyer, Balaji V]

Hi David, 
Please see my response below:

> -Original Message-
> From: David Edelsohn [mailto:dje@gmail.com]
> Sent: Wednesday, May 29, 2013 11:44 AM
> To: Iyer, Balaji V
> Cc: Richard Henderson; Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S.
> Myers'; gcc-patches
> Subject: RE: [PING]RE: [patch] cilkplus: Array notation for C patch
> 
> Balaji,
> 
> Thanks for this new feature and I am relieved that so much of it works
> successfully on PowerLinux and AIX.
> 
> I know that you have received a deluge of reports of issues with the cilkplus
> support that you slowly are working through.  I am seeing the following new
> testsuite failures on AIX:
> 
> /nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-plus/AN/sec_implicit2.c:
> In function 'main2':
> /nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
> plus/AN/sec_implicit2.c:23:15:
> error: __sec_implicit_index parameter must be an integer constant expression

I have this line flagged for error using dg-error.
Here is the cut and paste of it:

===
  array[:][:] = __sec_implicit_index(argc) + array[:][:]; /* { dg-error 
"__sec_implicit_index parameter" } */
  return 0;


I just have a partial message inside quotes, not the whole thing. My x86_64 
machine seem to accept it. I am not very familiar with deja-gnu, but does 
dg-error require the complete error message?

> 
> /nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
> plus/AN/sec_reduce_max_min_ind.c:
> In function 'main2':
> /nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
> plus/AN/sec_reduce_max_min_ind.c:23:28:
> error: __sec_reduce_min_ind or __sec_reduce_max_ind cannot have arrays
> with dimension greater than 1
> /nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
> plus/AN/sec_reduce_max_min_ind.c:27:28:
> error: __sec_reduce_min_ind or __sec_reduce_max_ind cannot have arrays
> with dimension greater than 1

Same as above for this also.

> 
> I hope that you can help resolve these errors.
> 
> Thanks, David

Re: [c++-concepts]

[Andrew Sutton]

I'll clean it up and commit tomorrow morning.

> Once you've committed the patch, let me know so I can synchronize with
> trunk -- or is there another patch coming in this week?

I'm hoping to get all of the function-related functionality sent off
by tomorrow or Saturday. I found a showstopper in the class template,
and I think it will take some time to address.

Andrew

patch introducing a hook for lra register usage leveling

[Vladimir Makarov]

  Investigating size increase of LRA generated code on PPC64 (> 0.2% on 
SPEC2006), I found that register usage leveling can hurt cross-jumping 
optimization for ppc besides if-conversion one for targets with 
conditional execution.


So I decided to introduce a machine target hook switching on the 
optimization (I believe introducing an option would be to much).  The 
following patch implements it.  Currently only x86/x86-64 uses register 
usage leveling.


  The patch was successfully bootstrapped on x86/x86-64 (it actually 
does not change generated code on x86/x86-64).


  Committed as rev. 199459.

2013-05-30  Vladimir Makarov  

* target.def (register_usage_leveling_p): New hook.
* targhooks.c (default_register_usage_leveling_p): New.
* targhooks.h (default_register_usage_leveling_p): New prototype.
* lra-assigns.c (register_usage_leveling_p): Use the hook.
* doc/tm.texi.in (TARGET_REGISTER_USAGE_LEVELING_P): New hook.
* doc/tm.texi: Update.
* config/i386/i386.c (TARGET_REGISTER_USAGE_LEVELING_P): Define.

Index: config/i386/i386.c
===
--- config/i386/i386.c	(revision 199453)
+++ config/i386/i386.c	(working copy)
@@ -42812,6 +42812,9 @@ ix86_memmodel_check (unsigned HOST_WIDE_
 #undef TARGET_REGISTER_PRIORITY
 #define TARGET_REGISTER_PRIORITY ix86_register_priority
 
+#undef TARGET_REGISTER_USAGE_LEVELING_P
+#define TARGET_REGISTER_USAGE_LEVELING_P hook_bool_void_true
+
 #undef TARGET_LEGITIMATE_CONSTANT_P
 #define TARGET_LEGITIMATE_CONSTANT_P ix86_legitimate_constant_p
 
Index: doc/tm.texi
===
--- doc/tm.texi	(revision 199453)
+++ doc/tm.texi	(working copy)
@@ -2898,6 +2898,10 @@ A target hook which returns true if we u
 A target hook which returns the register priority number to which the  register @var{hard_regno} belongs to.  The bigger the number, the  more preferable the hard register usage (when all other conditions are  the same).  This hook can be used to prefer some hard register over  others in LRA.  For example, some x86-64 register usage needs  additional prefix which makes instructions longer.  The hook can  return lower priority number for such registers make them less favorable  and as result making the generated code smaller.The default version of this target hook returns always zero.
 @end deftypefn
 
+@deftypefn {Target Hook} bool TARGET_REGISTER_USAGE_LEVELING_P (void)
+A target hook which returns true if we need register usage leveling.  That means if a few hard registers are equally good for the  assignment, we choose the least used hard register.  The register  usage leveling may be profitable for some targets.  Don't use the  usage leveling for targets with conditional execution or targets  with big register files as it hurts if-conversion and cross-jumping  optimizations.The default version of this target hook returns always false.
+@end deftypefn
+
 @deftypefn {Target Hook} bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void)
 A target hook which returns true if an address with the same structure  can have different maximal legitimate displacement.  For example, the  displacement can depend on memory mode or on operand combinations in  the insn.The default version of this target hook returns always false.
 @end deftypefn
Index: doc/tm.texi.in
===
--- doc/tm.texi.in	(revision 199453)
+++ doc/tm.texi.in	(working copy)
@@ -2870,6 +2870,8 @@ as below:
 
 @hook TARGET_REGISTER_PRIORITY
 
+@hook TARGET_REGISTER_USAGE_LEVELING_P
+
 @hook TARGET_DIFFERENT_ADDR_DISPLACEMENT_P
 
 @hook TARGET_SPILL_CLASS
Index: lra-assigns.c
===
--- lra-assigns.c	(revision 199453)
+++ lra-assigns.c	(working copy)
@@ -603,11 +603,7 @@ find_hard_regno_for (int regno, int *cos
 	  if (best_hard_regno < 0 || hard_regno_costs[hard_regno] < best_cost
 	  || (hard_regno_costs[hard_regno] == best_cost
 		  && (priority > best_priority
-		  /* Hard register usage leveling actually results
-			 in bigger code for targets with conditional
-			 execution like ARM because it reduces chance
-			 of if-conversion after LRA.  */
-		  || (! targetm.have_conditional_execution ()
+		  || (targetm.register_usage_leveling_p ()
 			  && priority == best_priority
 			  && best_usage > lra_hard_reg_usage[hard_regno]
 	{
Index: target.def
===
--- target.def	(revision 199453)
+++ target.def	(working copy)
@@ -2444,6 +2444,21 @@ DEFHOOK
  int, (int),
  default_register_priority)
 
+/* Return true if we need register usage leveling.  */
+DEFHOOK
+(register_usage_leveling_p,
+ "A target hook which returns true if we need register usage leveling.\
+  That means if a few hard registers are equally good for the\
+  assignment, we ch

Re: [c++-concepts]

[Jason Merrill]

On 05/30/2013 03:17 PM, Andrew Sutton wrote:

| -  /* 1 spare bit */
| +  unsigned concept_p : 1;  /* var or fn */
| +  /* 0 spare bit */
|  };

Hmm I don't understand the comment "var or fn".
If it is declared a concept, how can it it be a var?


Copied from the other bits in the class. I think it means it applies
to either variables or functions. I left it that way in anticipation
of template variables.


Can template variables be concepts?

Jason

Re: PR57073 - Optimize __builtin_powif (-1.0, k) to k & 1 ? -1.0 : 1.0

[Tobias Burnus]

Jeff Law wrote:

On 05/30/2013 12:08 PM, Tobias Burnus wrote:

+}
+  else
+{
+  if (!host_integerp (arg1, 0))
+break;
+
+  n = TREE_INT_CST_LOW (arg1);
+  result = gimple_expand_builtin_powi (&gsi, loc, arg0, n);
+}


In this case, why even bother with gimple_expand_builtin_powi. Don't 
we know the result simply by looking at N and setting the dest to -1.0 
or 1.0 appropriately?


I am a bit lost. The code quoted above is the old code - just moved down 
a bit. It is supposed to handle powi(x,n) for unknown x with known n - 
while the new code handles x == -1.0 for unknown n. Thus, 
gimple_expand_builtin_powi should be unreachable for x == -1.


My - possibly wrong - impression is that the case of n being constant 
*and* x being also a constant (e.g. x == -1) is handled before. One 
place where it is handled is at fold_builtin_powi. However, I do not 
understand GCC's passes well enough to know whether it is possible that 
one can reach tree-ssa-math-opts.c's execute_cse_sincos with x and n 
being becoming constant after the call to builtins.c's fold_builtin_powi.



Side remark: fold_builtin_powi would have been a more suitable case to 
do the conversion of this patch. However, re-gimplification does not 
like if one suddenly add an COND_EXPR at tree level, where the condition 
is neither a constant nor a variable. The problem is in the call to 
gimplify_modify_expr (from gimplify_cond_expr). If I recall correctly, 
for re-gimplification (but not for the initial gimplification), the code 
assumes that for "cond" is_gimple_val() is true. But as one has "x & 1", 
it is false - leading to an ICE. Thus, Richard + Jakub suggested to 
handle this case not on tree level during folding but on gimple level. 
That's how it ended up in tree-ssa-math-opts.c, where a special case for 
BUILT_IN_POWI already existed.


I don't see that powi_as_mults optimizes the case where both args are 
constants and thus the result is a trivially computable compile time 
constant. Am I missing something?
Granted, I wouldn't expect it to happen often, but we might have 
started with a variable exponent and through various opts eventually 
collapsed it down to a known constant.


If I understood it correctly, you would like to have an additional case 
before the newly added "k == 1", which does something like:


result = fold_builtin_powi (loc, NULL_TREE, arg1, arg2, TREE_TYPE (arg1);

if (result != NULL_TREE &&    /* Newly added  x == -1.0 case.  */

Is that what you propose?

Tobias

Re: [c++-concepts]

[Andrew Sutton]

I presented that at C++Now, so I hope so :) It lets me write:

template
  requires Input_iterator // no parens!
void f(T x);

Walter Brown also suggested this usage in his object alias paper.

In concepts lite, a concept is essentially an expression. Thus far,
we've packaged those expressions in constexpr functions (using
"concept" as a declaration specifier to impose additional
restrictions). Variable templates fall easily into this same set of
restrictions. Plus, no overloading.

Andrew

On Thu, May 30, 2013 at 3:34 PM, Jason Merrill  wrote:
> On 05/30/2013 03:17 PM, Andrew Sutton wrote:
>>>
>>> | -  /* 1 spare bit */
>>> | +  unsigned concept_p : 1;  /* var or fn */
>>> | +  /* 0 spare bit */
>>> |  };
>>>
>>> Hmm I don't understand the comment "var or fn".
>>> If it is declared a concept, how can it it be a var?
>>
>>
>> Copied from the other bits in the class. I think it means it applies
>> to either variables or functions. I left it that way in anticipation
>> of template variables.
>
>
> Can template variables be concepts?
>
> Jason
>



-- 
Andrew Sutton
andrew.n.sut...@gmail.com

Re: patch introducing a hook for lra register usage leveling

[Basile Starynkevitch]

On Thu, May 30, 2013 at 04:20:46PM -0400, Vladimir Makarov wrote:
>   Investigating size increase of LRA generated code on PPC64 (> 0.2%
> on SPEC2006), I found that register usage leveling can hurt
> cross-jumping optimization for ppc besides if-conversion one for
> targets with conditional execution.
> 
> So I decided to introduce a machine target hook switching on the
> optimization (I believe introducing an option would be to much).
> The following patch implements it.  Currently only x86/x86-64 uses
> register usage leveling.


Did you consider providing plugin hooks for that purpose?

It might be a good idea, for back-end related plugins (which probably don't 
exist today).

Cheers.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: PR57073 - Optimize __builtin_powif (-1.0, k) to k & 1 ? -1.0 : 1.0

[Jeff Law]

On 05/30/2013 02:38 PM, Tobias Burnus wrote:


I am a bit lost. The code quoted above is the old code - just moved down
a bit. It is supposed to handle powi(x,n) for unknown x with known n -
while the new code handles x == -1.0 for unknown n. Thus,
gimple_expand_builtin_powi should be unreachable for x == -1.
Sorry, I misread the patch.I was focused on the new lines and never 
looked back up to see if they were just copied from before.





If I understood it correctly, you would like to have an additional case
before the newly added "k == 1", which does something like:

result = fold_builtin_powi (loc, NULL_TREE, arg1, arg2, TREE_TYPE (arg1);

if (result != NULL_TREE &&    /* Newly added  x == -1.0 case.  */

Is that what you propose?

Don't worry about it.The patch is good as-is.



Jeff

Re: [PING]RE: [patch] cilkplus: Array notation for C patch

[Jeff Law]

On 05/30/2013 02:13 PM, Iyer, Balaji V wrote:

Hi David,
Please see my response below:


-Original Message-
From: David Edelsohn [mailto:dje@gmail.com]
Sent: Wednesday, May 29, 2013 11:44 AM
To: Iyer, Balaji V
Cc: Richard Henderson; Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S.
Myers'; gcc-patches
Subject: RE: [PING]RE: [patch] cilkplus: Array notation for C patch

Balaji,

Thanks for this new feature and I am relieved that so much of it works
successfully on PowerLinux and AIX.

I know that you have received a deluge of reports of issues with the cilkplus
support that you slowly are working through.  I am seeing the following new
testsuite failures on AIX:

/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-plus/AN/sec_implicit2.c:
In function 'main2':
/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
plus/AN/sec_implicit2.c:23:15:
error: __sec_implicit_index parameter must be an integer constant expression


I have this line flagged for error using dg-error.
Here is the cut and paste of it:

===
   array[:][:] = __sec_implicit_index(argc) + array[:][:]; /* { dg-error 
"__sec_implicit_index parameter" } */
   return 0;


Looking at my tree, dg-error refers to "argument" not "parameter"




I just have a partial message inside quotes, not the whole thing. My x86_64 
machine seem to accept it. I am not very familiar with deja-gnu, but does 
dg-error require the complete error message?




/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
plus/AN/sec_reduce_max_min_ind.c:
In function 'main2':
/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
plus/AN/sec_reduce_max_min_ind.c:23:28:
error: __sec_reduce_min_ind or __sec_reduce_max_ind cannot have arrays
with dimension greater than 1
/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
plus/AN/sec_reduce_max_min_ind.c:27:28:
error: __sec_reduce_min_ind or __sec_reduce_max_ind cannot have arrays
with dimension greater than 1


Same as above for this also.
Not sure about this one.  It's possible (I'd have to sit down with 
dg.exp for a while) that it's looking for "error: " immediately followed 
by your string.   If that's the case, then it's looking for

"error: cannot have arrays with dimension greater than"

which won't match
"error: __sec_reduce_min_ind or __sec_reduce_max_ind cannot have arrays 
with dimension greater than"


jeff

Re: [PATCH, rs6000] power8 patches, patch #2, add crypto builtins

[Michael Meissner]

On Sat, May 25, 2013 at 12:07:32AM -0400, David Edelsohn wrote:
> [gcc/testsuite]
> 2013-05-20  Michael Meissner  
> 
> * gcc.target/powerpc/crypto-builtin-1.c: New file, test for power8
> crypto builtins.
> 
> The testcase needs to check something more than
> 
> /* { dg-require-effective-target powerpc_vsx_ok } */
> 
> I don't know if we need to separate the new VSX operations from the
> crypto opterations, but the new testcases need to ensure that the
> assembler and/or processor support the new instructions.

I believe I did this test before adding powerpc_p8vector_ok in patch #5.
Thanks for noticing it.  I think I'll commit the target-supports.exp change and
then change this test to use powerpc_p8vector_ok unless you have objections to
the target-supports.exp part of the patch.

I don't think it is important enough to have a separate category for crypto
vs. the other p8 vector stuff, since the assembler change added both at the
same time.

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

Re: [ada, build] host/target configuration

[Olivier Hainque]

On May 30, 2013, at 15:44 , Arnaud Charlet  wrote:
> In other words, this change will impact basically all targets, so needs
> either much more testing, or more review, which is on going.

 Part of the issue comes from the need to support some targets
 with non-canonical names (in the configure --target sense) for
 which we want the canonical behavior except for a few variations
 in the Ada RTSes, for example powerpc-wrs-vxworksmils instead of
 powerpc-wrs-vxworksae.

 Adjusting the loads of case selections everywhere, missing some
 cases at times, to attempt materializing the 99.9% equivalence
 turned out problematic, and leveraging config.sub sounded a lot
 simpler and more appropriate.

 The idea of the "target->target_alias" change in gcc-interface/Makefile.in
 for Ada was to let us still distinguish for the purpose of the Ada RTSes in
 particular.

 This happens to be significant in a limited amount of cases only.

 We need to assess which ones and how best we could deal
 with the differences in a different manner if possible.

 Olivier

Re: [c++-concepts]

[Gabriel Dos Reis]

Andrew Sutton  writes:

| I presented that at C++Now, so I hope so :) It lets me write:
| 
| template
|   requires Input_iterator // no parens!
| void f(T x);
| 
| Walter Brown also suggested this usage in his object alias paper.
| 
| In concepts lite, a concept is essentially an expression. Thus far,
| we've packaged those expressions in constexpr functions (using
| "concept" as a declaration specifier to impose additional
| restrictions). Variable templates fall easily into this same set of
| restrictions. Plus, no overloading.

In this scenario, Input_iterator (my prefered syntax!) is a constant
expression (or will be a constant expression.)  The real question is
whether we need yet another way of declaring a constexpr variable
template.   I have not made up my mind on that, but I am leaning
towards "no".  

So, we do need a comment in the code about this flag.

-- Gaby

Re: [PING]RE: [patch] cilkplus: Array notation for C patch

[Jakub Jelinek]

On Thu, May 30, 2013 at 03:02:27PM -0600, Jeff Law wrote:
> >>error: __sec_reduce_min_ind or __sec_reduce_max_ind cannot have arrays
> >>with dimension greater than 1
> >
> >Same as above for this also.
> Not sure about this one.  It's possible (I'd have to sit down with
> dg.exp for a while) that it's looking for "error: " immediately
> followed by your string.   If that's the case, then it's looking for
> "error: cannot have arrays with dimension greater than"
> 
> which won't match
> "error: __sec_reduce_min_ind or __sec_reduce_max_ind cannot have
> arrays with dimension greater than"

No, if the dg-error regexp doesn't start with number followed by :
(column), then it is matched as:
\[0-9\]+: error:\[^\n\]*
followed by the provided regexp.

Jakub

Re: [Patch, Fortran] Better error messages for type/rank checks

[Tobias Burnus]

Hi Janus,

Janus Weil wrote:

In addition to this, the patch contains a part which concerns the
function 'gfc_terminal_width': Currently this returns a fixed value of
80, which means that all source lines are trimmed to 80 characters in
the error messages. I increased this default value to 132 (in order to
accommodate standard free-format lines), and added a part which tries
to determine the terminal width from the environment variable $COLUMNS
(the corresponding code was borrowed from gcc/opts.c).


I think it is a good idea to use $COLUMNS (which is, e.g. set by the 
shell under Unix); however, if the variable is not available, I think 
one should keep the value 80.



2013-05-30  Janus Weil

 PR fortran/57217
 * gfortran. h (gfc_terminal_width): Remove prototype.

Spurious space before "h".


-/* Given two symbols that are formal arguments, compare their ranks
-   and types.  Returns nonzero if they have the same rank and type,
-   zero otherwise.  */
+static int
+compare_type (gfc_symbol *s1, gfc_symbol *s2)
+{
+  if (s1->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK)
+  || s2->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
+return 1;
  
+  return gfc_compare_types (&s1->ts, &s2->ts)

+|| s1->ts.type == BT_ASSUMED || s2->ts.type == BT_ASSUMED;
+}


I admit it is a slightly different issue, but it came up in the same 
thread: I believe it should be:


+  if (s2->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
+return 1;
...
+  return s2->ts.type == BT_ASSUMED || gfc_compare_types (&s1->ts, &s2->ts);


That should fix the issue with the two of the three test cases at 
http://gcc.gnu.org/ml/fortran/2013-05/msg00089.html



-compare_type_rank (gfc_symbol *s1, gfc_symbol *s2)
+compare_rank (gfc_symbol *s1, gfc_symbol *s2)
  {
gfc_array_spec *as1, *as2;
int r1, r2;
@@ -533,11 +541,21 @@ static int
&& (!as2 || as2->type != AS_ASSUMED_RANK))
  return 0; /* Ranks differ.  */


Ditto here:
  if (r1 != r2
  && (!as1 || as1->type != AS_ASSUMED_RANK)
  && (!as2 || as2->type != AS_ASSUMED_RANK))
return 0;   /* Ranks differ.  */

where the "!as1" line should be removed, which fixes the third of the 
three test cases of the email mentioned above.



Otherwise, the patch looks okay.

I'd like if you could include the mentioned changes to the type/rank 
checks together with the three test cases. But as strictly speaking 
those are about separate issues, one could also do it in a follow up patch.




Regarding the error printing: My long standing wish is to ignore ignore 
trailing comments when trimming the error message, i.e. instead of printing


e" ! some very long comment line

one should rather show

print *, some "line" ! some ver

where one cuts of the comment line. I think the issue mostly occurs with 
%C error printing where the current location is at the end of the line, 
while for %L the location should be fine.


Tobias

PS: If you have time, please have a look at my patch at 
http://gcc.gnu.org/ml/fortran/2013-05/msg00118.html - as I just saw, I 
managed again to attach the wrong patch. That patch also includes the 
gcc/fortran bits of http://gcc.gnu.org/ml/fortran/2013-05/msg00114.html 
, which also still has to be reviewed.

Re: [Patch] Fix PR56780: --disable-install-libiberty still installs libiberty.a

[Matt Burgess]

On Wed, 2013-05-22 at 15:13 -0700, Ian Lance Taylor wrote:
> On Wed, May 22, 2013 at 2:41 PM, Matt Burgess
>  wrote:
> >
> > 2013-05-22 Matt Burgess 
> >
> > other/PR56780
> > * libiberty/configure.ac: Move test for --enable-install-libiberty
> > outside of the 'with_target_subdir' test so that it actually gets 
> > run.
> > Add output messages to show the test result.
> > * libiberty/configure: Regenerate.
> > * libiberty/Makefile.in (install_to_libdir): Place the installation
> > of the libiberty library in the same guard as that used for the
> > headers to prevent it being installed unless requested via
> > --enable-install-libiberty.
> 
> This is OK.

Thanks, Ian.  Another step in the contributing guidelines I seem to have
missed is to inform you that I don't have write access to the GCC repo.
If you could commit this for me please, I'd appreciate it.

Thanks,

Matt.

PR 57452

[Iyer, Balaji V]

Hello Everyone,
One of the test in Cilk Plus array notation execution test for C was 
wrong. Here is a fixed one:

Here is the Change log entry for it:

2013-05-30  Balaji V. Iyer  

PR c/57452
* c-c++-common/cilk-plus/AN/if_test.c: Fixed out of bounds issue in
test-case.

Is this OK for trunk?

Thanks,

Balaji V. Iyer.
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c 
b/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
old mode 100644
new mode 100755
index b150b18..53ceeec
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
@@ -1,6 +1,9 @@
 /* { dg-do run } */
 /* { dg-options "-fcilkplus" } */
 
+#if HAVE_IO
+#include 
+#endif
 #include 
 int main2 (int argc, char **argv);
 int main(int argc, char **argv)
@@ -23,8 +26,9 @@ int main(int argc, char **argv)
 int main2 (int argc, char **argv)
 {
   int x = 3, y, z, array[10], array2[10], TwodArray[10][10], jj,kk,ll ;
-  int array2_check[10];
-  int FourDArray[10][10][10][10];
+  int array2_check[10], array2d_check[10][10], array2d[10][10];
+  int FourDArray[10][10][10][10], array4[10][10][10][10];
+  int array4_check[10][10][10][10];
   int ii = 0; 
 
   for (ii = 0; ii < 10; ii++)
@@ -71,10 +75,6 @@ int main2 (int argc, char **argv)
 if (array2_check[ii] != array2[ii])
   return 3;
   
-
-  
-   
-
   x = atoi (argv[1])-10;
   y = atoi (argv[1])/2;
   z = (atoi (argv[1]))/5;
@@ -110,14 +110,16 @@ int main2 (int argc, char **argv)
 if (array2_check[ii] != array2[ii])
   return 4;
 
-  for (ii = 0; ii < 10; ii++)
+  for (ii = 0; ii < 10; ii++) {
 array2[ii] = 10;
+array2_check[ii] = 10;
+  }
 
   /* This if loop will change all the 10's to 5's */
-  if (array[atoi(argv[1])-10:atoi(argv[1]): atoi(argv[1])/5])
-array2[:] = 5;
+  if (array[atoi(argv[1])-10:atoi(argv[1])/2: atoi(argv[1])/5])
+array2[atoi(argv[1])-10: atoi (argv[1])/2: atoi(argv[1])/5] = 5;
   else
-array2[:] = 10;
+array2[atoi(argv[1])-10: atoi (argv[1])/2: atoi(argv[1])/5] = 10;
 
   for (ii = atoi(argv[1])-10; ii < atoi(argv[1]) + (atoi (argv[1])-10);
ii +=atoi(argv[1])/5)
@@ -127,9 +129,13 @@ int main2 (int argc, char **argv)
   array2_check[ii] = 10;
 
   for (ii = 0; ii < 10; ii++)
-if (array2_check[ii] != array2[ii])
+if (array2_check[ii] != array2[ii]) {
+#if HAVE_IO
+  printf("array2[%2d] = %2d array2_check[%2d] = %2d\n", ii, array2[ii],
+ii, array2_check[ii]);
+#endif
   return 5;
- 
+}
 
   for (ii = 0; ii < 10; ii++)
 for (jj = 0; jj < 10; jj++)
@@ -137,29 +143,39 @@ int main2 (int argc, char **argv)
 
 
   for (ii = 0; ii < 10; ii++)
-{
-  array2[ii] = 10;
-  array2_check[ii] = 10;
+for (ii = 0; ii < 10; ii++) {
+  array2d[ii][jj] = 10;
+  array2d_check[ii][jj] = 10;
 }
 
   /* atoi(argv[1]) == 10, so it will convert all 10's to 5's */
   if (TwodArray[:][:] != 10) 
-array2[:] = 10; 
+array2d[:][:] = 10; 
   else
-array2[:] = 5;
+array2d[:][:] = 5;
 
   for (ii = 0; ii < 10; ii++) {
 for (jj = 0; jj < 10; jj++) {
   if (TwodArray[ii][jj] != 10)
-   array2_check[ii] = 10;
+   array2d_check[ii][jj] = 10;
+  else
+   array2d_check[ii][jj] = 5;
 }
   }
 
   for (ii = 0; ii < 10; ii++)
-{
-  array2[ii] = 10;
-  array2_check[ii] = 10;
-}
+for (jj = 0; jj < 10; jj++)
+  if (array2d[ii][jj] != array2d_check[ii][jj])
+   return 6;
+
+  for (ii = 0; ii < 10; ii++)
+for (jj = 0; jj < 10; jj++)
+  for (kk = 0; kk < 10; kk++)
+   for (ll = 0; ll < 10; ll++)
+ {
+   array4[ii][jj][kk][ll] = 10;
+   array4_check[ii][jj][kk][ll] = 10;
+ }
 
   for (ii = 0; ii < 10; ii++)
 for (jj = 0; jj < 10; jj++)
@@ -169,26 +185,38 @@ int main2 (int argc, char **argv)
   
   /* atoi(argv[1]) == 10, so it will convert all 10's to 5's */
   if (FourDArray[:][:][:][:] != 10) 
-array2[:] = 10; 
+array4[:][:][:][:] = 10; 
   else
-array2[:] = 5;
+array4[:][:][:][:] = 5;
 
   for (ii = 0; ii < 10; ii++) {
 for (jj = 0; jj < 10; jj++) {
   for (kk = 0; kk < 10; kk++) {
for (ll = 0; ll < 10; ll++) {
  if (FourDArray[ii][jj][kk][ll] != 10)
-   array2_check[ii] = 10;
+   array4_check[ii][jj][kk][ll] = 10;
+ else
+   array4_check[ii][jj][kk][ll] = 5;
}
   }
 }
   }
-  
+
   for (ii = 0; ii < 10; ii++)
-{
-  array2[ii] = 10;
-  array2_check[ii] = 10;
-}
+for (jj = 0; jj < 10; jj++)
+  for (kk = 0; kk < 10; kk++)
+   for (ll = 0; ll < 10; ll++)
+ if (array4_check[ii][jj][kk][ll] != array4[ii][jj][kk][ll])
+   return 7;
+
+  for (ii = 0; ii < 10; ii++)
+for (jj = 0; jj < 10; jj++)
+  for (kk = 0; kk < 10; kk++)
+   for (ll = 0; ll < 10; ll++)
+ {
+   array4[ii][jj][kk][ll] = 10;
+   array4_check[ii][jj][kk][ll] = 10;
+ 

RE: [PING]RE: [patch] cilkplus: Array notation for C patch

[Iyer, Balaji V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Thursday, May 30, 2013 5:02 PM
> To: Iyer, Balaji V
> Cc: David Edelsohn; Richard Henderson; Jakub Jelinek; Aldy Hernandez; 'Joseph
> S. Myers'; gcc-patches
> Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
> 
> On 05/30/2013 02:13 PM, Iyer, Balaji V wrote:
> > Hi David,
> > Please see my response below:
> >
> >> -Original Message-
> >> From: David Edelsohn [mailto:dje@gmail.com]
> >> Sent: Wednesday, May 29, 2013 11:44 AM
> >> To: Iyer, Balaji V
> >> Cc: Richard Henderson; Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S.
> >> Myers'; gcc-patches
> >> Subject: RE: [PING]RE: [patch] cilkplus: Array notation for C patch
> >>
> >> Balaji,
> >>
> >> Thanks for this new feature and I am relieved that so much of it
> >> works successfully on PowerLinux and AIX.
> >>
> >> I know that you have received a deluge of reports of issues with the
> >> cilkplus support that you slowly are working through.  I am seeing
> >> the following new testsuite failures on AIX:
> >>
> >> /nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
> plus/AN/sec_implicit2.c:
> >> In function 'main2':
> >> /nasfarm/dje/src/src/gcc/testsuite/c-c++-common/cilk-
> >> plus/AN/sec_implicit2.c:23:15:
> >> error: __sec_implicit_index parameter must be an integer constant
> >> expression
> >
> > I have this line flagged for error using dg-error.
> > Here is the cut and paste of it:
> >
> > ===
> >array[:][:] = __sec_implicit_index(argc) + array[:][:]; /* { dg-error
> "__sec_implicit_index parameter" } */
> >return 0;
> >
> 
> Looking at my tree, dg-error refers to "argument" not "parameter"


Hmm.. I have used "__sec_implicit_index parameter" in dg-error. Here is the 
link from gcc-git web portal 
(http://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/testsuite/c-c%2B%2B-common/cilk-plus/AN/sec_implicit2.c;hb=4a2ca8f34c2b84bbd04eff0d22f97046dfbd0f07)

Also, it should hit the error in function extract_sec_implicit_index_arg in the 
file array-notation-common.c 
(http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/array-notation-common.c;h=1d288464eee6a8c805ef627d58c14249da5ae143;hb=4a2ca8f34c2b84bbd04eff0d22f97046dfbd0f07)
  and it does have "__sec_implicit_index parameter..." 

I think David is getting the correct output but just that dg-error is not 
catching it correctly.

Thanks,

Balaji V. Iyer.

[google gcc-4_7,gcc-4_8,integration] Relax vector validity checks

[Paul Pluzhnikov]

Greetings,

The vector validity checks introduced here:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00415.html

proved too strict: older versions of GCC used to do this:

  _M_start = _M_end = _M_end_of_storage = new_allocator(sizeof(T) * n)

even when n == 0, and we have code compiled by such version linked in
with new code, and failing the check.

Google ref b/9198806

Attached patch relaxes the check, while still catching dangling vector
accesses.

Ok for google/gcc_4-7, gcc-4_8 and integration branches?

Thanks,

--
Paul Pluzhnikov

Index: libstdc++-v3/include/bits/stl_vector.h
===
--- libstdc++-v3/include/bits/stl_vector.h  (revision 199461)
+++ libstdc++-v3/include/bits/stl_vector.h  (working copy)
@@ -244,12 +244,27 @@
 
   bool _M_is_valid() const
   {
-return (this->_M_impl._M_end_of_storage == 0
-   && this->_M_impl._M_start == 0
-   && this->_M_impl._M_finish == 0)
- || (this->_M_impl._M_start <= this->_M_impl._M_finish
- && this->_M_impl._M_finish <= this->_M_impl._M_end_of_storage
- && this->_M_impl._M_start < this->_M_impl._M_end_of_storage);
+if (this->_M_impl._M_end_of_storage == 0
+   && this->_M_impl._M_start == 0
+   && this->_M_impl._M_finish == 0)
+ return true;
+
+   if (this->_M_impl._M_start <= this->_M_impl._M_finish
+   && this->_M_impl._M_finish <= this->_M_impl._M_end_of_storage)
+ {
+   if (this->_M_impl._M_start < this->_M_impl._M_end_of_storage)
+ return true;
+   else if (this->_M_impl._M_start == this->_M_impl._M_end_of_storage
+&& this->_M_impl._M_start == this->_M_impl._M_finish)
+ {
+   pointer _0xcdcd;
+
+   __builtin_memset(&_0xcdcd, 0xcd, sizeof(_0xcdcd));
+   return this->_M_impl._M_finish != _0xcdcd;
+ }
+ }
+
+   return false;
   }
 
 public:

[GOOGLE] More strict checking for call args

[Dehao Chen]

This patch makes more strict check of call args to make sure the
number of args match.

Bootstrapped and passed regression tests.

OK for google branches?

Thanks,
Dehao

Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c (revision 199414)
+++ gcc/gimple-low.c (working copy)
@@ -254,9 +254,13 @@ gimple_check_call_args (gimple stmt, tree fndecl)
   && !fold_convertible_p (DECL_ARG_TYPE (p), arg)))
 return false;
  }
+  if (p != NULL)
+ return false;
 }
   else if (parms)
 {
+  if (list_length (parms) - nargs != 1)
+ return false;
   for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
  {
   tree arg;

Re: [GOOGLE] More strict checking for call args

[Xinliang David Li]

On Thu, May 30, 2013 at 3:47 PM, Dehao Chen  wrote:
> This patch makes more strict check of call args to make sure the
> number of args match.
>
> Bootstrapped and passed regression tests.
>
> OK for google branches?
>
> Thanks,
> Dehao
>
> Index: gcc/gimple-low.c
> ===
> --- gcc/gimple-low.c (revision 199414)
> +++ gcc/gimple-low.c (working copy)
> @@ -254,9 +254,13 @@ gimple_check_call_args (gimple stmt, tree fndecl)
>&& !fold_convertible_p (DECL_ARG_TYPE (p), arg)))
>  return false;
>   }
> +  if (p != NULL)
> + return false;
>  }
>else if (parms)
>  {
> +  if (list_length (parms) - nargs != 1)
> + return false;

This does not seem to be correct for vararg functions.

David


>for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
>   {
>tree arg;

Re: [PATCH, rs6000] power8 patches, patch #4, new power8 builtins

[Michael Meissner]

On Sat, May 25, 2013 at 12:03:51AM -0400, David Edelsohn wrote:
> On Tue, May 21, 2013 at 7:47 PM, Michael Meissner
>  wrote:
> 
> 
> > * config/rs6000/rs6000.c (rs6000_option_override_internal): Only
> > allow power8 quad mode in 64-bit.  Turn off splitting wide types
> > if we have quad mode.
> 
> Completely turning off splitting wide types seems like an
> unnecessarily large hammer to prevent splitting a value across
> registers within logical atomic operations.  I think we need to
> examine other alternatives.

Ok, I tracked down what the problem is.  We never implemented the EQV, ORC, or
NAND insns in the GPRs.  When I added the power8 vector versions, the split
wide types pass tried to do its thing in the GPRs, it creates a bad insn. I
originally saw it in the atomic ops, because I was testing all of the
combinations provided, but I can reproduce it just by using __int128_t.

In looking at the code, we don't seem to implement nor of two values either.

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

Re: [GOOGLE] More strict checking for call args

[Dehao Chen]

Yes, patch updated:

Testing on-going.

Dehao

Index: gimple-low.c
===
--- gimple-low.c (revision 199414)
+++ gimple-low.c (working copy)
@@ -254,6 +254,8 @@
   && !fold_convertible_p (DECL_ARG_TYPE (p), arg)))
 return false;
  }
+  if (p != NULL)
+ return false;
 }
   else if (parms)
 {

On Thu, May 30, 2013 at 4:10 PM, Xinliang David Li  wrote:
> On Thu, May 30, 2013 at 3:47 PM, Dehao Chen  wrote:
>> This patch makes more strict check of call args to make sure the
>> number of args match.
>>
>> Bootstrapped and passed regression tests.
>>
>> OK for google branches?
>>
>> Thanks,
>> Dehao
>>
>> Index: gcc/gimple-low.c
>> ===
>> --- gcc/gimple-low.c (revision 199414)
>> +++ gcc/gimple-low.c (working copy)
>> @@ -254,9 +254,13 @@ gimple_check_call_args (gimple stmt, tree fndecl)
>>&& !fold_convertible_p (DECL_ARG_TYPE (p), arg)))
>>  return false;
>>   }
>> +  if (p != NULL)
>> + return false;
>>  }
>>else if (parms)
>>  {
>> +  if (list_length (parms) - nargs != 1)
>> + return false;
>
> This does not seem to be correct for vararg functions.
>
> David
>
>
>>for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
>>   {
>>tree arg;

Re: [google gcc-4_7,gcc-4_8,integration] Relax vector validity checks

[Diego Novillo]

On 2013-05-30 18:19 , Paul Pluzhnikov wrote:

Ok for google/gcc_4-7, gcc-4_8 and integration branches?


OK.  Is this applicable to trunk and/or release branches?


Diego.

[google] Prune -fopt-info output

[Teresa Johnson]

This patch reduces the copious -fopt-info output by making the default for
-fopt-info to be -fopt-info=optimized instead of -fopt-info=all. It also
changes most of the vectorizer messages to use MSG_NOTE instead of
MSG_OPTIMIZED_LOCATION.

Reduced the output of -fopt-info for one application by >75%. Testing in
progress.

Ok for google/4_8 if testing passes?

Thanks, Teresa

Index: dumpfile.c
===
--- dumpfile.c  (revision 199426)
+++ dumpfile.c  (working copy)
@@ -867,7 +867,7 @@ opt_info_switch_p (const char *arg)
 
   file_seen = xstrdup (filename);
   if (!flags)
-flags = MSG_ALL;
+flags = MSG_OPTIMIZED_LOCATIONS;
   if (!optgroup_flags)
 optgroup_flags = OPTGROUP_ALL;
 
Index: tree-vect-loop-manip.c
===
--- tree-vect-loop-manip.c  (revision 199426)
+++ tree-vect-loop-manip.c  (working copy)
@@ -1774,7 +1774,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
   gimple_seq cond_expr_stmt_list = NULL;
 
   if (dump_enabled_p ())
-dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+dump_printf_loc (MSG_NOTE, vect_location,
  "=== vect_do_peeling_for_loop_bound ===");
 
   initialize_original_copy_tables ();
@@ -1828,7 +1828,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
   if (check_profitability)
 max_iter = MAX (max_iter, (int) th - 1);
   record_niter_bound (new_loop, double_int::from_shwi (max_iter), false, true);
-  dump_printf (MSG_OPTIMIZED_LOCATIONS,
+  dump_printf (MSG_NOTE,
"Setting upper bound of nb iterations for epilogue "
"loop to %d\n", max_iter);
 
@@ -1893,7 +1893,7 @@ vect_gen_niters_for_prolog_loop (loop_vec_info loo
   int npeel = LOOP_PEELING_FOR_ALIGNMENT (loop_vinfo);
 
   if (dump_enabled_p ())
-dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+dump_printf_loc (MSG_NOTE, vect_location,
  "known peeling = %d.", npeel);
 
   iters = build_int_cst (niters_type, npeel);
@@ -1948,9 +1948,9 @@ vect_gen_niters_for_prolog_loop (loop_vec_info loo
 
   if (dump_enabled_p ())
 {
-  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+  dump_printf_loc (MSG_NOTE, vect_location,
"niters for prolog loop: ");
-  dump_generic_expr (MSG_OPTIMIZED_LOCATIONS, TDF_SLIM, iters);
+  dump_generic_expr (MSG_NOTE, TDF_SLIM, iters);
 }
 
   var = create_tmp_var (niters_type, "prolog_loop_niters");
@@ -2005,7 +2005,7 @@ vect_update_inits_of_drs (loop_vec_info loop_vinfo
   struct data_reference *dr;
  
  if (dump_enabled_p ())
-dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+dump_printf_loc (MSG_NOTE, vect_location,
  "=== vect_update_inits_of_dr ===");
 
   FOR_EACH_VEC_ELT (datarefs, i, dr)
@@ -2034,7 +2034,7 @@ vect_do_peeling_for_alignment (loop_vec_info loop_
   int bound = 0;
 
   if (dump_enabled_p ())
-dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+dump_printf_loc (MSG_NOTE, vect_location,
  "=== vect_do_peeling_for_alignment ===");
 
   initialize_original_copy_tables ();
@@ -2062,7 +2062,7 @@ vect_do_peeling_for_alignment (loop_vec_info loop_
   if (check_profitability)
 max_iter = MAX (max_iter, (int) th - 1);
   record_niter_bound (new_loop, double_int::from_shwi (max_iter), false, true);
-  dump_printf (MSG_OPTIMIZED_LOCATIONS,
+  dump_printf (MSG_NOTE,
"Setting upper bound of nb iterations for prologue "
"loop to %d\n", max_iter);
 
@@ -2349,11 +2349,11 @@ vect_create_cond_for_alias_checks (loop_vec_info l
 
   if (dump_enabled_p ())
{
- dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location, 
+ dump_printf_loc (MSG_NOTE, vect_location, 
"create runtime check for data references ");
- dump_generic_expr (MSG_OPTIMIZED_LOCATIONS, TDF_SLIM, DR_REF (dr_a));
- dump_printf (MSG_OPTIMIZED_LOCATIONS, " and ");
- dump_generic_expr (MSG_OPTIMIZED_LOCATIONS, TDF_SLIM, DR_REF (dr_b));
+ dump_generic_expr (MSG_NOTE, TDF_SLIM, DR_REF (dr_a));
+ dump_printf (MSG_NOTE, " and ");
+ dump_generic_expr (MSG_NOTE, TDF_SLIM, DR_REF (dr_b));
}
 
   seg_a_min = addr_base_a;
@@ -2379,7 +2379,7 @@ vect_create_cond_for_alias_checks (loop_vec_info l
 }
 
   if (dump_enabled_p ())
-dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+dump_printf_loc (MSG_NOTE, vect_location,
 "created %u versioning for alias checks.\n",
 may_alias_ddrs.length ());
 }
Index: tree-vectorizer.c
===
--- tree-vectorizer.c   (revision 199426)
+++ tree-vectorizer.c   (working copy)
@@ -107,7 +107,7 @@ vectorize_loops (void)
vect_location = find_loop_locatio

Re: [google gcc-4_7,gcc-4_8,integration] Relax vector validity checks

[Paul Pluzhnikov]

On Thu, May 30, 2013 at 6:48 PM, Diego Novillo  wrote:

> OK.  Is this applicable to trunk and/or release branches?

No: the "cheap" vector and string checks are on google branches only.


-- 
Paul Pluzhnikov

Re: [google] Prune -fopt-info output

[Teresa Johnson]

Testing passed. I forgot to include the documentation change in the first patch:

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 199426)
+++ doc/invoke.texi (working copy)
@@ -6219,7 +6219,7 @@ Controls optimization dumps from various optimizat
 @samp{-@var{options}} form is used, @var{options} is a list of
 @samp{-} separated options to select the dump details and
 optimizations.  If @var{options} is not specified, it defaults to
-@option{all} for details and @option{optall} for optimization
+@option{optimized} for details and @option{optall} for optimization
 groups. If the @var{filename} is not specified, it defaults to
 @file{stderr}. Note that the output @var{filename} will be overwritten
 in case of multiple translation units. If a combined output from

Teresa

On Thu, May 30, 2013 at 6:49 PM, Teresa Johnson  wrote:
> This patch reduces the copious -fopt-info output by making the default for
> -fopt-info to be -fopt-info=optimized instead of -fopt-info=all. It also
> changes most of the vectorizer messages to use MSG_NOTE instead of
> MSG_OPTIMIZED_LOCATION.
>
> Reduced the output of -fopt-info for one application by >75%. Testing in
> progress.
>
> Ok for google/4_8 if testing passes?
>
> Thanks, Teresa
>
> Index: dumpfile.c
> ===
> --- dumpfile.c  (revision 199426)
> +++ dumpfile.c  (working copy)
> @@ -867,7 +867,7 @@ opt_info_switch_p (const char *arg)
>
>file_seen = xstrdup (filename);
>if (!flags)
> -flags = MSG_ALL;
> +flags = MSG_OPTIMIZED_LOCATIONS;
>if (!optgroup_flags)
>  optgroup_flags = OPTGROUP_ALL;
>
> Index: tree-vect-loop-manip.c
> ===
> --- tree-vect-loop-manip.c  (revision 199426)
> +++ tree-vect-loop-manip.c  (working copy)
> @@ -1774,7 +1774,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
>gimple_seq cond_expr_stmt_list = NULL;
>
>if (dump_enabled_p ())
> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
> +dump_printf_loc (MSG_NOTE, vect_location,
>   "=== vect_do_peeling_for_loop_bound ===");
>
>initialize_original_copy_tables ();
> @@ -1828,7 +1828,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
>if (check_profitability)
>  max_iter = MAX (max_iter, (int) th - 1);
>record_niter_bound (new_loop, double_int::from_shwi (max_iter), false, 
> true);
> -  dump_printf (MSG_OPTIMIZED_LOCATIONS,
> +  dump_printf (MSG_NOTE,
> "Setting upper bound of nb iterations for epilogue "
> "loop to %d\n", max_iter);
>
> @@ -1893,7 +1893,7 @@ vect_gen_niters_for_prolog_loop (loop_vec_info loo
>int npeel = LOOP_PEELING_FOR_ALIGNMENT (loop_vinfo);
>
>if (dump_enabled_p ())
> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
> +dump_printf_loc (MSG_NOTE, vect_location,
>   "known peeling = %d.", npeel);
>
>iters = build_int_cst (niters_type, npeel);
> @@ -1948,9 +1948,9 @@ vect_gen_niters_for_prolog_loop (loop_vec_info loo
>
>if (dump_enabled_p ())
>  {
> -  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
> +  dump_printf_loc (MSG_NOTE, vect_location,
> "niters for prolog loop: ");
> -  dump_generic_expr (MSG_OPTIMIZED_LOCATIONS, TDF_SLIM, iters);
> +  dump_generic_expr (MSG_NOTE, TDF_SLIM, iters);
>  }
>
>var = create_tmp_var (niters_type, "prolog_loop_niters");
> @@ -2005,7 +2005,7 @@ vect_update_inits_of_drs (loop_vec_info loop_vinfo
>struct data_reference *dr;
>
>   if (dump_enabled_p ())
> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
> +dump_printf_loc (MSG_NOTE, vect_location,
>   "=== vect_update_inits_of_dr ===");
>
>FOR_EACH_VEC_ELT (datarefs, i, dr)
> @@ -2034,7 +2034,7 @@ vect_do_peeling_for_alignment (loop_vec_info loop_
>int bound = 0;
>
>if (dump_enabled_p ())
> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
> +dump_printf_loc (MSG_NOTE, vect_location,
>   "=== vect_do_peeling_for_alignment ===");
>
>initialize_original_copy_tables ();
> @@ -2062,7 +2062,7 @@ vect_do_peeling_for_alignment (loop_vec_info loop_
>if (check_profitability)
>  max_iter = MAX (max_iter, (int) th - 1);
>record_niter_bound (new_loop, double_int::from_shwi (max_iter), false, 
> true);
> -  dump_printf (MSG_OPTIMIZED_LOCATIONS,
> +  dump_printf (MSG_NOTE,
> "Setting upper bound of nb iterations for prologue "
> "loop to %d\n", max_iter);
>
> @@ -2349,11 +2349,11 @@ vect_create_cond_for_alias_checks (loop_vec_info l
>
>if (dump_enabled_p ())
> {
> - dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
> + dump_printf_loc (MSG_NOTE, vect_location,
> 

Re: [google] Prune -fopt-info output

[Xinliang David Li]

Ok. I think this is a useful patch for trunk too.

Thanks,

David

On Thu, May 30, 2013 at 7:03 PM, Teresa Johnson  wrote:
> Testing passed. I forgot to include the documentation change in the first 
> patch:
>
> Index: doc/invoke.texi
> ===
> --- doc/invoke.texi (revision 199426)
> +++ doc/invoke.texi (working copy)
> @@ -6219,7 +6219,7 @@ Controls optimization dumps from various optimizat
>  @samp{-@var{options}} form is used, @var{options} is a list of
>  @samp{-} separated options to select the dump details and
>  optimizations.  If @var{options} is not specified, it defaults to
> -@option{all} for details and @option{optall} for optimization
> +@option{optimized} for details and @option{optall} for optimization
>  groups. If the @var{filename} is not specified, it defaults to
>  @file{stderr}. Note that the output @var{filename} will be overwritten
>  in case of multiple translation units. If a combined output from
>
> Teresa
>
> On Thu, May 30, 2013 at 6:49 PM, Teresa Johnson  wrote:
>> This patch reduces the copious -fopt-info output by making the default for
>> -fopt-info to be -fopt-info=optimized instead of -fopt-info=all. It also
>> changes most of the vectorizer messages to use MSG_NOTE instead of
>> MSG_OPTIMIZED_LOCATION.
>>
>> Reduced the output of -fopt-info for one application by >75%. Testing in
>> progress.
>>
>> Ok for google/4_8 if testing passes?
>>
>> Thanks, Teresa
>>
>> Index: dumpfile.c
>> ===
>> --- dumpfile.c  (revision 199426)
>> +++ dumpfile.c  (working copy)
>> @@ -867,7 +867,7 @@ opt_info_switch_p (const char *arg)
>>
>>file_seen = xstrdup (filename);
>>if (!flags)
>> -flags = MSG_ALL;
>> +flags = MSG_OPTIMIZED_LOCATIONS;
>>if (!optgroup_flags)
>>  optgroup_flags = OPTGROUP_ALL;
>>
>> Index: tree-vect-loop-manip.c
>> ===
>> --- tree-vect-loop-manip.c  (revision 199426)
>> +++ tree-vect-loop-manip.c  (working copy)
>> @@ -1774,7 +1774,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
>>gimple_seq cond_expr_stmt_list = NULL;
>>
>>if (dump_enabled_p ())
>> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>> +dump_printf_loc (MSG_NOTE, vect_location,
>>   "=== vect_do_peeling_for_loop_bound ===");
>>
>>initialize_original_copy_tables ();
>> @@ -1828,7 +1828,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
>>if (check_profitability)
>>  max_iter = MAX (max_iter, (int) th - 1);
>>record_niter_bound (new_loop, double_int::from_shwi (max_iter), false, 
>> true);
>> -  dump_printf (MSG_OPTIMIZED_LOCATIONS,
>> +  dump_printf (MSG_NOTE,
>> "Setting upper bound of nb iterations for epilogue "
>> "loop to %d\n", max_iter);
>>
>> @@ -1893,7 +1893,7 @@ vect_gen_niters_for_prolog_loop (loop_vec_info loo
>>int npeel = LOOP_PEELING_FOR_ALIGNMENT (loop_vinfo);
>>
>>if (dump_enabled_p ())
>> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>> +dump_printf_loc (MSG_NOTE, vect_location,
>>   "known peeling = %d.", npeel);
>>
>>iters = build_int_cst (niters_type, npeel);
>> @@ -1948,9 +1948,9 @@ vect_gen_niters_for_prolog_loop (loop_vec_info loo
>>
>>if (dump_enabled_p ())
>>  {
>> -  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>> +  dump_printf_loc (MSG_NOTE, vect_location,
>> "niters for prolog loop: ");
>> -  dump_generic_expr (MSG_OPTIMIZED_LOCATIONS, TDF_SLIM, iters);
>> +  dump_generic_expr (MSG_NOTE, TDF_SLIM, iters);
>>  }
>>
>>var = create_tmp_var (niters_type, "prolog_loop_niters");
>> @@ -2005,7 +2005,7 @@ vect_update_inits_of_drs (loop_vec_info loop_vinfo
>>struct data_reference *dr;
>>
>>   if (dump_enabled_p ())
>> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>> +dump_printf_loc (MSG_NOTE, vect_location,
>>   "=== vect_update_inits_of_dr ===");
>>
>>FOR_EACH_VEC_ELT (datarefs, i, dr)
>> @@ -2034,7 +2034,7 @@ vect_do_peeling_for_alignment (loop_vec_info loop_
>>int bound = 0;
>>
>>if (dump_enabled_p ())
>> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>> +dump_printf_loc (MSG_NOTE, vect_location,
>>   "=== vect_do_peeling_for_alignment ===");
>>
>>initialize_original_copy_tables ();
>> @@ -2062,7 +2062,7 @@ vect_do_peeling_for_alignment (loop_vec_info loop_
>>if (check_profitability)
>>  max_iter = MAX (max_iter, (int) th - 1);
>>record_niter_bound (new_loop, double_int::from_shwi (max_iter), false, 
>> true);
>> -  dump_printf (MSG_OPTIMIZED_LOCATIONS,
>> +  dump_printf (MSG_NOTE,
>> "Setting upper bound of nb iterations for prologue "
>> "loop to %d\n", max_iter);
>>
>>

[PATCH] Expanding array notations inside conditions

[Iyer, Balaji V]

Hello Everyone,
When I was looking at the erroneous test on PR 57452, I found out that 
array notations in conditions were not expanded correctly. The rank for the 
array notation condition must be same (or equal to zero) as the rank of the 
array notations inside the else-block and then-block (or they could be zero). I 
found out that GCC was not detecting these errors. I am very sorry for this 
mishap. The attached patch should fix that issue. I have also enclosed a 
test-suite code to make sure this gets caught in future. 

It is tested on x86_64 and seem to work OK. The only test that it is 
failing is the erronous test called if_test.c, and if patch specified in 
(http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01815.html) is applied, then that 
test will pass. 

Is this OK for trunk?

Here are the ChangeLog entries:
gcc/c/ChangeLog
2013-05-30  Balaji V. Iyer  

* c-typeck.c (c_finish_if_stmt): Added a check to see if the rank of the
condition of the if-statement matches the rank of else-block and then-
block when array notations are used.
* c-parser.c (c_parser_declaration_or_fndef): Expanded array notation
expression after the entire function body is parsed.
(c_parser_expr_no_commas): Delayed creating array notation expressions
to the end of function parsing.
* c-array-notation.c (fix_conditional_array_notations_1): Expanded the
whole if-statement instead of just the condition.
(expand_array_notation_exprs): Added MODIFY_EXPR case.

gcc/testsuite/ChangeLog
2013-05-30  Balaji V. Iyer  

* c-c++-common/cilk-plus/AN/if_test_errors.c (main): New testcase.
* c-c++-common/cilk-plus/AN/rank_mismatch.c: Added a '-w' option to
dg-option and an header comment.


Thanks,

Balaji V. Iyer.
diff --git gcc/c/ChangeLog gcc/c/ChangeLog
old mode 100644
new mode 100755
index d33fa2b..828d7c8
--- gcc/c/ChangeLog
+++ gcc/c/ChangeLog
@@ -1,3 +1,16 @@
+2013-05-30  Balaji V. Iyer  
+
+   * c-typeck.c (c_finish_if_stmt): Added a check to see if the rank of the
+   condition of the if-statement matches the rank of else_block and then-
+   block when array notations are used.
+   * c-parser.c (c_parser_declaration_or_fndef): Expanded array notation
+   expression after the entire function body is parsed.
+   (c_parser_expr_no_commas): Delayed creating array notation expressions
+   to the end of function parsing.
+   * c-array-notation.c (fix_conditional_array_notations_1): Expanded the
+   whole if-statement instead of just the condition.
+   (expand_array_notation_exprs): Added MODIFY_EXPR case.
+
 2013-05-29  Rainer Orth  
 
PR bootstrap/57450
diff --git gcc/c/c-array-notation.c gcc/c/c-array-notation.c
old mode 100644
new mode 100755
index bf139a8..681e111
--- gcc/c/c-array-notation.c
+++ gcc/c/c-array-notation.c
@@ -1875,7 +1875,7 @@ fix_conditional_array_notations_1 (tree stmt)
   if (!find_rank (location, cond, cond, false, &rank))
 return error_mark_node;
   
-  extract_array_notation_exprs (cond, false, &array_list);
+  extract_array_notation_exprs (stmt, false, &array_list);
   loop_init = push_stmt_list ();
   for (ii = 0; ii < vec_safe_length (array_list); ii++)
 { 
@@ -1895,12 +1895,12 @@ fix_conditional_array_notations_1 (tree stmt)
  vec_safe_push (sub_list, array_node);
  vec_safe_push (new_var_list, new_var);
  add_stmt (builtin_loop);
- replace_array_notations (&cond, false, sub_list, new_var_list); 
+ replace_array_notations (&stmt, false, sub_list, new_var_list); 
}
}
 }
 
-  if (!find_rank (location, cond, cond, true, &rank))
+  if (!find_rank (location, stmt, stmt, true, &rank))
 {
   pop_stmt_list (loop_init);
   return error_mark_node;
@@ -1911,7 +1911,7 @@ fix_conditional_array_notations_1 (tree stmt)
   pop_stmt_list (loop_init); 
   return loop_init;
 }  
-  extract_array_notation_exprs (cond, true, &array_list);
+  extract_array_notation_exprs (stmt, true, &array_list);
 
   if (vec_safe_length (array_list) == 0)
 return stmt;
@@ -2761,6 +2761,18 @@ expand_array_notation_exprs (tree t)
expand_array_notation_exprs (*tsi_stmt_ptr (ii_tsi));
   }
   return t;
+case MODIFY_EXPR:
+  {
+   location_t loc = EXPR_HAS_LOCATION (t) ? EXPR_LOCATION (t) :
+ UNKNOWN_LOCATION;
+   tree lhs = TREE_OPERAND (t, 0);
+   tree rhs = TREE_OPERAND (t, 1);
+   location_t rhs_loc = EXPR_HAS_LOCATION (rhs) ? EXPR_LOCATION (rhs) :
+ UNKNOWN_LOCATION;
+   t = build_array_notation_expr (loc, lhs, TREE_TYPE (lhs), NOP_EXPR,
+  rhs_loc, rhs, TREE_TYPE (rhs));
+   return t;
+  }
 case CALL_EXPR:
   t = fix_array_notation_call_expr (t);
   return t;
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
old mode 100644
new mode 100755

Re: [google] Prune -fopt-info output

[Teresa Johnson]

On Thu, May 30, 2013 at 7:17 PM, Xinliang David Li  wrote:
> Ok. I think this is a useful patch for trunk too.

Agreed, I will send it up to trunk too. In the meantime it is now in google/4_8.

Thanks,
Teresa

>
> Thanks,
>
> David
>
> On Thu, May 30, 2013 at 7:03 PM, Teresa Johnson  wrote:
>> Testing passed. I forgot to include the documentation change in the first 
>> patch:
>>
>> Index: doc/invoke.texi
>> ===
>> --- doc/invoke.texi (revision 199426)
>> +++ doc/invoke.texi (working copy)
>> @@ -6219,7 +6219,7 @@ Controls optimization dumps from various optimizat
>>  @samp{-@var{options}} form is used, @var{options} is a list of
>>  @samp{-} separated options to select the dump details and
>>  optimizations.  If @var{options} is not specified, it defaults to
>> -@option{all} for details and @option{optall} for optimization
>> +@option{optimized} for details and @option{optall} for optimization
>>  groups. If the @var{filename} is not specified, it defaults to
>>  @file{stderr}. Note that the output @var{filename} will be overwritten
>>  in case of multiple translation units. If a combined output from
>>
>> Teresa
>>
>> On Thu, May 30, 2013 at 6:49 PM, Teresa Johnson  wrote:
>>> This patch reduces the copious -fopt-info output by making the default for
>>> -fopt-info to be -fopt-info=optimized instead of -fopt-info=all. It also
>>> changes most of the vectorizer messages to use MSG_NOTE instead of
>>> MSG_OPTIMIZED_LOCATION.
>>>
>>> Reduced the output of -fopt-info for one application by >75%. Testing in
>>> progress.
>>>
>>> Ok for google/4_8 if testing passes?
>>>
>>> Thanks, Teresa
>>>
>>> Index: dumpfile.c
>>> ===
>>> --- dumpfile.c  (revision 199426)
>>> +++ dumpfile.c  (working copy)
>>> @@ -867,7 +867,7 @@ opt_info_switch_p (const char *arg)
>>>
>>>file_seen = xstrdup (filename);
>>>if (!flags)
>>> -flags = MSG_ALL;
>>> +flags = MSG_OPTIMIZED_LOCATIONS;
>>>if (!optgroup_flags)
>>>  optgroup_flags = OPTGROUP_ALL;
>>>
>>> Index: tree-vect-loop-manip.c
>>> ===
>>> --- tree-vect-loop-manip.c  (revision 199426)
>>> +++ tree-vect-loop-manip.c  (working copy)
>>> @@ -1774,7 +1774,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
>>>gimple_seq cond_expr_stmt_list = NULL;
>>>
>>>if (dump_enabled_p ())
>>> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>>> +dump_printf_loc (MSG_NOTE, vect_location,
>>>   "=== vect_do_peeling_for_loop_bound ===");
>>>
>>>initialize_original_copy_tables ();
>>> @@ -1828,7 +1828,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
>>>if (check_profitability)
>>>  max_iter = MAX (max_iter, (int) th - 1);
>>>record_niter_bound (new_loop, double_int::from_shwi (max_iter), false, 
>>> true);
>>> -  dump_printf (MSG_OPTIMIZED_LOCATIONS,
>>> +  dump_printf (MSG_NOTE,
>>> "Setting upper bound of nb iterations for epilogue "
>>> "loop to %d\n", max_iter);
>>>
>>> @@ -1893,7 +1893,7 @@ vect_gen_niters_for_prolog_loop (loop_vec_info loo
>>>int npeel = LOOP_PEELING_FOR_ALIGNMENT (loop_vinfo);
>>>
>>>if (dump_enabled_p ())
>>> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>>> +dump_printf_loc (MSG_NOTE, vect_location,
>>>   "known peeling = %d.", npeel);
>>>
>>>iters = build_int_cst (niters_type, npeel);
>>> @@ -1948,9 +1948,9 @@ vect_gen_niters_for_prolog_loop (loop_vec_info loo
>>>
>>>if (dump_enabled_p ())
>>>  {
>>> -  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>>> +  dump_printf_loc (MSG_NOTE, vect_location,
>>> "niters for prolog loop: ");
>>> -  dump_generic_expr (MSG_OPTIMIZED_LOCATIONS, TDF_SLIM, iters);
>>> +  dump_generic_expr (MSG_NOTE, TDF_SLIM, iters);
>>>  }
>>>
>>>var = create_tmp_var (niters_type, "prolog_loop_niters");
>>> @@ -2005,7 +2005,7 @@ vect_update_inits_of_drs (loop_vec_info loop_vinfo
>>>struct data_reference *dr;
>>>
>>>   if (dump_enabled_p ())
>>> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>>> +dump_printf_loc (MSG_NOTE, vect_location,
>>>   "=== vect_update_inits_of_dr ===");
>>>
>>>FOR_EACH_VEC_ELT (datarefs, i, dr)
>>> @@ -2034,7 +2034,7 @@ vect_do_peeling_for_alignment (loop_vec_info loop_
>>>int bound = 0;
>>>
>>>if (dump_enabled_p ())
>>> -dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>>> +dump_printf_loc (MSG_NOTE, vect_location,
>>>   "=== vect_do_peeling_for_alignment ===");
>>>
>>>initialize_original_copy_tables ();
>>> @@ -2062,7 +2062,7 @@ vect_do_peeling_for_alignment (loop_vec_info loop_
>>>if (check_profitability)
>>>  max_iter = MAX (max_iter, (int) th - 1);
>>>  

[google gcc-4_8 commited] Adjust testsuite line numbers for r199468.

[Paul Pluzhnikov]

I've committed attached patch on google/gcc-4_8 branch to fix testsuite
failures broken by r199468.

Thanks,

--
Paul Pluzhnikov


Index: 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc
===
--- 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc
(revision 199470)
+++ 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc
(working copy)
@@ -18,7 +18,7 @@
 // .
 
 // { dg-do compile }
-// { dg-error "no matching" "" { target *-*-* } 1346 }
+// { dg-error "no matching" "" { target *-*-* } 1361 }
 
 #include 
 
Index: 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc
===
--- 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc
(revision 199470)
+++ 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc
(working copy)
@@ -18,7 +18,7 @@
 // .
 
 // { dg-do compile }
-// { dg-error "no matching" "" { target *-*-* } 1387 }
+// { dg-error "no matching" "" { target *-*-* } 1402 }
 
 #include 
 
Index: 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc
===
--- 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc
 (revision 199470)
+++ 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc
 (working copy)
@@ -18,7 +18,7 @@
 // .
 
 // { dg-do compile }
-// { dg-error "no matching" "" { target *-*-* } 1272 }
+// { dg-error "no matching" "" { target *-*-* } 1287 }
 
 #include 
 
Index: 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc
===
--- 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc
 (revision 199470)
+++ 
libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc
 (working copy)
@@ -18,7 +18,7 @@
 // .
 
 // { dg-do compile }
-// { dg-error "no matching" "" { target *-*-* } 1272 }
+// { dg-error "no matching" "" { target *-*-* } 1287 }
 
 #include 
 #include