Re: [Patch, Fortran, OOP] PR 48095: Invalid assignment to procedure pointer component not rejected

[Tobias Burnus]

On 03/29/2011 12:17 AM, Janus Weil wrote:

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


OK.

Tobias


2011-03-28  Janus Weil

PR fortran/48095
* decl.c (match_procedure_decl,match_ppc_decl): Set flavor of interface.
* module.c (MOD_VERSION): Bump.
(mio_typespec): Read/write 'interface' field.
* primary.c (match_string_constant,match_logical_constant): Remove
unneeded code.
(match_complex_constant): Make sure to clear the typespec.

2011-03-28  Janus Weil

PR fortran/48095
* gfortran.dg/module_md5_1.f90: Modified MD5 sum.
* gfortran.dg/proc_ptr_comp_32.f90: New.

[ patch, committed] Warn about array temporary creation in front end optimization

[Thomas Koenig]

Hello world,

I have committed the attached patch as obvious, revision 171653, after 
regression-testing.


Thomas

2011-03-29  Thomas Koenig  

* frontend-passes.c (create_var):  Warn about creating an
array temporary if requested.

2011-03-29  Thomas Koenig  

* gfortran.dg/function_optimize_1.f90:  Add -Warray-temporaries,
check for corresponding warning.

2011-03-29  Thomas Koenig  

* frontend-passes.c (create_var):  Warn about creating an
array temporary if requested.
Index: fortran/frontend-passes.c
===
--- fortran/frontend-passes.c	(Revision 171618)
+++ fortran/frontend-passes.c	(Arbeitskopie)
@@ -256,6 +256,8 @@ create_var (gfc_expr * e)
   result->ref->u.ar.type = AR_FULL;
   result->ref->u.ar.where = e->where;
   result->ref->u.ar.as = symbol->as;
+  if (gfc_option.warn_array_temp)
+	gfc_warning ("Creating array temporary at %L", &(e->where));
 }
 
   /* Generate the new assignment.  */
Index: testsuite/gfortran.dg/function_optimize_1.f90
===
--- testsuite/gfortran.dg/function_optimize_1.f90	(Revision 171618)
+++ testsuite/gfortran.dg/function_optimize_1.f90	(Arbeitskopie)
@@ -1,5 +1,5 @@
 ! { dg-do compile }
-! { dg-options "-O -fdump-tree-original" }
+! { dg-options "-O -fdump-tree-original -Warray-temporaries" }
 program main
   implicit none
   real, dimension(2,2) :: a, b, c, d
@@ -24,7 +24,8 @@ program main
 
   data a /2., 3., 5., 7./
   data b /11., 13., 17., 23./
-  write (unit=line, fmt='(4F7.2)') matmul(a,b) + matmul(a,b)
+  write (unit=line, fmt='(4F7.2)') matmul(a,b)  &
+   & + matmul(a,b)! { dg-warning "Creating array temporary" }
   z = sin(x) + cos(x) + sin(x) + cos(x)
   print *,z
   x = ext_func(a) + 23 + ext_func(a)

Re: [C++0x] Range-based for statements and ADL

[Jonathan Wakely]

On 29 March 2011 01:49, Rodrigo Rivas wrote:
> Hi again.
>
> Here it is my first try at this. I have changed the list to
> gcc-patches, I don't know if cross post would be correct.
> Please, note that this patch is not finished: the new test cases are
> still missing, and expect format mistakes, misspellings and the
> like...
>
> A few comments:
>
> 1. I'm not sure about what should happen if the begin/end found in
> class scope are not ordinary functions. My guess is that if it is a
> function (static or non-static) it is called normally, and if it is a
> member variable it is searched for an operator()(). If it is a type it
> should fail. That is what I tried to implement (I think it works).

The wording was carefully written so that if name lookup finds any
"r.begin" then it will try "r.begin()" so yes, it should be able to
call data members of callable type.

> 2. The function cp_parser_perform_range_for_lookup() does the same job
> twice, but interleaved, so it's not easy to avoid typing everything
> once and again. Maybe it should be split in several pieces.
> Suggestions welcome.
>
> 3. In the function cp_parser_perform_range_for_lookup() I made quite a
> shameful, but clever, abuse of the local variables and arguments. I've
> seen similar patterns in the code, but if you think it is too much, I
> can rewrite it.
>
> 4. The approach to error diagnostics can be done in so many ways that
> I cannot make my mind. I think that the attached patch does a
> reasonable job, but again...

Should we consistently refer to % so the keyword is highlighted?

> 5. Hidden in the new wording, there are a restriction about arrays of
> incomplete type or unknown size. That restriction should have been
> obvious before (easy to say now ;-), and it is quite unrelated to the
> other changes. But I don't know if it is worth its own patch (3 lines
> an a future test).
>
> Awaiting for comments.
>
> --
> Rodrigo
>

[Ping][Patch, testsuite]: Don't xfail sibcalls on AVR

[Georg-Johann Lay]

Target avr now supports tail calls, so don't xfail on that.

testsuite/

2011-03-29  Georg-Johann Lay  

* gcc.dg/sibcall-3.c: Don't xfail on AVR.
* gcc.dg/sibcall-4.c: Don't xfail on AVR.

Index: testsuite/gcc.dg/sibcall-3.c
===
--- testsuite/gcc.dg/sibcall-3.c	(Revision 171039)
+++ testsuite/gcc.dg/sibcall-3.c	(Arbeitskopie)
@@ -5,7 +5,7 @@
Copyright (C) 2002 Free Software Foundation Inc.
Contributed by Hans-Peter Nilsson*/
 
-/* { dg-do run { xfail { { arc-*-* avr-*-* cris-*-* crisv32-*-* h8300-*-* hppa*64*-*-* m32r-*-* m68hc1?-*-* mcore-*-* mn10300-*-* xstormy16-*-* v850*-*-* vax-*-* xtensa*-*-* } || { arm*-*-* && { ! arm32 } } } } } */
+/* { dg-do run { xfail { { arc-*-* cris-*-* crisv32-*-* h8300-*-* hppa*64*-*-* m32r-*-* m68hc1?-*-* mcore-*-* mn10300-*-* xstormy16-*-* v850*-*-* vax-*-* xtensa*-*-* } || { arm*-*-* && { ! arm32 } } } } } */
 /* -mlongcall disables sibcall patterns.  */
 /* { dg-skip-if "" { powerpc*-*-* } { "-mlongcall" } { "" } } */
 /* { dg-options "-O2 -foptimize-sibling-calls" } */
Index: testsuite/gcc.dg/sibcall-4.c
===
--- testsuite/gcc.dg/sibcall-4.c	(Revision 171039)
+++ testsuite/gcc.dg/sibcall-4.c	(Arbeitskopie)
@@ -5,7 +5,7 @@
Copyright (C) 2002 Free Software Foundation Inc.
Contributed by Hans-Peter Nilsson*/
 
-/* { dg-do run { xfail { { arc-*-* avr-*-* cris-*-* crisv32-*-* h8300-*-* hppa*64*-*-* m32r-*-* m68hc1?-*-* mcore-*-* mn10300-*-* xstormy16-*-* v850*-*-* vax-*-* xtensa*-*-* } || { arm*-*-* && { ! arm32 } } } } } */
+/* { dg-do run { xfail { { arc-*-* cris-*-* crisv32-*-* h8300-*-* hppa*64*-*-* m32r-*-* m68hc1?-*-* mcore-*-* mn10300-*-* xstormy16-*-* v850*-*-* vax-*-* xtensa*-*-* } || { arm*-*-* && { ! arm32 } } } } } */
 /* -mlongcall disables sibcall patterns.  */
 /* { dg-skip-if "" { powerpc*-*-* } { "-mlongcall" } { "" } } */
 /* { dg-options "-O2 -foptimize-sibling-calls" } */

Re: [C++0x] Range-based for statements and ADL

[Rodrigo Rivas]

On Tue, Mar 29, 2011 at 10:12 AM, Jonathan Wakely  wrote:
> Should we consistently refer to % so the keyword is highlighted?
Now that you say... I've not been quite consistent. We could say
"range-based %", with only a dash between 'range' and 'based'.

Re: [Patch, Fortran, OOP] PR 48095: Invalid assignment to procedure pointer component not rejected

[Janus Weil]

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

Thanks, Tobias. Committed as r171654.

Cheers,
Janus



>> 2011-03-28  Janus Weil
>>
>>        PR fortran/48095
>>        * decl.c (match_procedure_decl,match_ppc_decl): Set flavor of
>> interface.
>>        * module.c (MOD_VERSION): Bump.
>>        (mio_typespec): Read/write 'interface' field.
>>        * primary.c (match_string_constant,match_logical_constant): Remove
>>        unneeded code.
>>        (match_complex_constant): Make sure to clear the typespec.
>>
>> 2011-03-28  Janus Weil
>>
>>        PR fortran/48095
>>        * gfortran.dg/module_md5_1.f90: Modified MD5 sum.
>>        * gfortran.dg/proc_ptr_comp_32.f90: New.
>

Re: [PATCH: ARM] PR 45335 Use ldrd and strd to access two consecutive words

[Carrot Wei]

Thank you for the knowledge. I've updated the insn patterns
accordingly. Again tested on arm qemu.

thanks
Carrot

ChangeLog:
2011-03-29  Wei Guozhi  

PR target/45335
* gcc/config/arm/ldmstm.md (ldm2_ia, stm2_ia, ldm2_ib, stm2_ib, ldm2_da,
stm2_da, ldm2_db, stm2_db): Add condition !arm_arch7 to these insns.
(ldrd, ldrd_reg1, ldrd_reg2 and peephole2): New insn patterns and
related peephole2.
(strd, strd_reg1, strd_reg2 and peephole2): New insn patterns and
related peephole2.
* gcc/config/arm/arm-protos.h (arm_check_ldrd_operands): New prototype.
(arm_legitimate_ldrd_p): New prototype.
(arm_output_ldrd): New prototype.
* gcc/config/arm/arm.c (arm_check_ldrd_operands): New function.
(arm_legitimate_ldrd_p): New function.
(arm_output_ldrd): New function.


2011-03-29  Wei Guozhi  

PR target/45335
* gcc.target/arm/pr45335.c: New test.
* gcc.target/arm/pr45335-2.c: New test.
* gcc.target/arm/pr45335-3.c: New test.
* gcc.target/arm/pr40457-1.c: Add another possible output "ldrd".
* gcc.target/arm/pr40457-2.c: Changed to store 3 words.
* gcc.target/arm/pr40457-3.c: Changed to store 3 words.


On Thu, Mar 24, 2011 at 8:25 AM, Mike Stump  wrote:
> On Jan 18, 2011, at 6:59 AM, Carrot Wei wrote:
>> +(define_insn "*ldrd"
>> +  [(parallel [(set (match_operand:SI 0 "arm_hard_register_operand" "")
>
> parallel is implicit, you can safely remove it from all define_insns.
>
Index: testsuite/gcc.target/arm/pr40457-3.c
===
--- testsuite/gcc.target/arm/pr40457-3.c(revision 171439)
+++ testsuite/gcc.target/arm/pr40457-3.c(working copy)
@@ -5,6 +5,7 @@ void foo(int* p)
 {
   p[0] = 1;
   p[1] = 0;
+  p[2] = 2;
 }
 
 /* { dg-final { scan-assembler "stm" } } */
Index: testsuite/gcc.target/arm/pr45335-2.c
===
--- testsuite/gcc.target/arm/pr45335-2.c(revision 0)
+++ testsuite/gcc.target/arm/pr45335-2.c(revision 0)
@@ -0,0 +1,10 @@
+/* { dg-options "-Os -march=armv7-a" }  */
+/* { dg-do compile } */
+
+void foo(int a, int b, int* p)
+{
+  p[2] = a;
+  p[3] = b;
+}
+
+/* { dg-final { scan-assembler "strd" } } */
Index: testsuite/gcc.target/arm/pr45335-3.c
===
--- testsuite/gcc.target/arm/pr45335-3.c(revision 0)
+++ testsuite/gcc.target/arm/pr45335-3.c(revision 0)
@@ -0,0 +1,12 @@
+/* { dg-options "-Os -march=armv7-a" }  */
+/* { dg-do compile } */
+
+int foo(int a, int b, int* p, int *q)
+{
+  a = p[2] + p[3];
+  *q = a;
+  *p = a;
+  return a;
+}
+
+/* { dg-final { scan-assembler "ldrd" } } */
Index: testsuite/gcc.target/arm/pr40457-1.c
===
--- testsuite/gcc.target/arm/pr40457-1.c(revision 171439)
+++ testsuite/gcc.target/arm/pr40457-1.c(working copy)
@@ -7,4 +7,4 @@ int bar(int* p)
   return x;
 }
 
-/* { dg-final { scan-assembler "ldm" } } */
+/* { dg-final { scan-assembler "ldm|ldrd" } } */
Index: testsuite/gcc.target/arm/pr40457-2.c
===
--- testsuite/gcc.target/arm/pr40457-2.c(revision 171439)
+++ testsuite/gcc.target/arm/pr40457-2.c(working copy)
@@ -5,6 +5,7 @@ void foo(int* p)
 {
   p[0] = 1;
   p[1] = 0;
+  p[2] = 2;
 }
 
 /* { dg-final { scan-assembler "stm" } } */
Index: testsuite/gcc.target/arm/pr45335.c
===
--- testsuite/gcc.target/arm/pr45335.c  (revision 0)
+++ testsuite/gcc.target/arm/pr45335.c  (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-options "-mthumb -O2" } */
+/* { dg-require-effective-target arm_thumb2_ok } */
+/* { dg-final { scan-assembler "ldrd" } } */
+/* { dg-final { scan-assembler "strd" } } */
+
+struct S
+{
+void* p1;
+void* p2;
+void* p3;
+void* p4;
+};
+
+extern printf(char*, ...);
+
+void foo1(struct S* fp, struct S* otherSaveArea)
+{
+struct S* saveA = fp - 1;
+printf("StackSaveArea for fp %p [%p/%p]:\n", fp, saveA, otherSaveArea);
+printf("prevFrame=%p savedPc=%p meth=%p curPc=%p fp[0]=0x%08x\n",
+saveA->p1, saveA->p2, saveA->p3, saveA->p4, *(unsigned int*)fp);
+}
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 171439)
+++ config/arm/arm.c(working copy)
@@ -23681,4 +23681,234 @@ arm_preferred_rename_class (reg_class_t 
 return NO_REGS;
 }
 
+/* Check the validity of operands in an ldrd/strd instruction.  */
+bool
+arm_check_ldrd_operands (rtx reg1, rtx reg2, rtx off1, rtx off2)
+{
+  HOST_WIDE_INT offset1 = 0;
+  HOST_WIDE_INT offset2 = 0;
+  int regno1 = REGNO (reg1);
+  int regno2 = REGNO (reg2);
+  HOST_WIDE_INT max_offset = 1020;
+
+  if (TARGET_ARM)
+max_offset 

PING^3: PR 47551: ARM patch for Neon-related spill failure

[Richard Sandiford]

Third ping for this ARM-specific reload fix:

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02266.html

Thanks,
Richard

[debug] Introduce -fno-debug-types-section flag

[Mark Wielaard]

Hi,

Some dwarf consumers (dwarves, systemtap and dwarflint) grok Dwarf V4,
but not yet the new .debug_types section. To make it easier to use these
tools with -gdwarf-4 this patch introduces a new
-fno-debug-types-section flag and guards all code that is type unit
specific with use_debug_types instead of a generic dwarf_version >= 4
flag. IMHO this makes the code also slightly more readable. And it
re-enables the usage of -feliminate-dwarf2-dups with -gdwarf-4. Although
admittedly the value of that is probably pretty low. I found it helpful
in debugging some issues with dwarf consumers and DW_FORM_ref_addr
usage.

2011-03-29  Mark Wielaard  

* common.opt (fdebug-types-section): New flag.
* doc/invoke.texi: Document new -fno-debug-types-section flag.
* dwarf2out.c (use_debug_types): New define.
(struct die_struct): Mark die_id with GTY desc use_debug_types.
(print_die): Guard output of type unit signatures using
use_debug_types.
(build_abbrev_table): Replace assert of dwarf_version >= 4
with assert on use_debug_types.
(size_of_die): Likewise.
(unmark_dies): Likewise.
(value_format): Decide AT_ref_external form on use_debug_types.
(output_die): Replace dwarf_version version check guard with
use_debug_types where appropriate.
(modified_type_die): Likewise.
(gen_reference_type_die): Likewise.
(dwarf2out_start_source_file): Likewise.
(dwarf2out_end_source_file): Likewise.
(prune_unused_types_walk_attribs): Likewise.
(dwarf2out_finish): Likewise.

Bootstrapped on x86_64 GNU/Linux, no regressions.

Thanks,

Mark
diff --git a/gcc/common.opt b/gcc/common.opt
index 88ae101..213645c 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1012,6 +1012,10 @@ femit-class-debug-always
 Common Report Var(flag_emit_class_debug_always) Init(0)
 Do not suppress C++ class debug information.
 
+fdebug-types-section
+Common Report Var(flag_debug_types_section) Init(1)
+Output .debug_types section when using DWARF v4 debuginfo.
+
 fexceptions
 Common Report Var(flag_exceptions) Optimization
 Enable exception handling
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 85bf2b4..928e322 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -312,7 +312,8 @@ Objective-C and Objective-C++ Dialects}.
 -fdump-final-insns=@var{file} @gol
 -fcompare-debug@r{[}=@var{opts}@r{]}  -fcompare-debug-second @gol
 -feliminate-dwarf2-dups -feliminate-unused-debug-types @gol
--feliminate-unused-debug-symbols -femit-class-debug-always @gol
+-feliminate-unused-debug-symbols -femit-class-debug-always
+-fdebug-types-section @gol
 -fmem-report -fpre-ipa-mem-report -fpost-ipa-mem-report -fprofile-arcs @gol
 -frandom-seed=@var{string} -fsched-verbose=@var{n} @gol
 -fsel-sched-verbose -fsel-sched-dump-cfg -fsel-sched-pipelining-verbose @gol
@@ -4585,6 +4586,15 @@ normally emits debugging information for classes because using this
 option will increase the size of debugging information by as much as a
 factor of two.
 
+@item -fno-debug-types-section
+@opindex fno-types-section
+@opindex ftypes-section
+By default when using Dwarf v4 or higher type DIEs will be put into
+their own .debug_types section instead of making them part of the
+.debug_info section.  It is more efficient to put them in a separate
+comdat sections since the linker will then be able to remove duplicates.
+But not all dwarf consumers support .debug_types sections yet.
+
 @item -gstabs+
 @opindex gstabs+
 Produce debugging information in stabs format (if that is supported),
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 7803ab7..6e80a0b 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -5795,6 +5795,16 @@ const struct gcc_debug_hooks dwarf2_debug_hooks =
representation is done after the entire program has been compiled.
The types below are used to describe the internal representation.  */
 
+/* Whether to put type DIEs into their own section .debug_types instead
+   of making them part of the .debug_info section.  Only supported for
+   Dwarf V4 or higher and the user didn't disable them through
+   -fno-debug-types-section.  It is more efficient to put them in a
+   separate comdat sections since the linker will then be able to
+   remove duplicates.  But not all tools support .debug_types sections
+   yet.  */
+
+#define use_debug_types (dwarf_version >= 4 && flag_debug_types_section)
+
 /* Various DIE's use offsets relative to the beginning of the
.debug_info section to refer to each other.  */
 
@@ -5853,7 +5863,7 @@ typedef struct GTY((chain_circular ("%h.die_sib"))) die_struct {
   char * GTY ((tag ("0"))) die_symbol;
   comdat_type_node_ref GTY ((tag ("1"))) die_type_node;
 }
-  GTY ((desc ("dwarf_version >= 4"))) die_id;
+  GTY ((desc ("use_debug_types"))) die_id;
   VEC(dw_attr_node,gc) * die_attr;
   dw_die_ref die_parent;
   dw_die_ref die_child;
@@ -8524,7 +8534,7 @@ print_die (dw_die_ref die, FILE *outfile)
   fprintf (outfile, " offset: %ld", die->d

Re: [patch, ARM] Fix PR48250, adjust DImode reload address legitimizing

[Chung-Lin Tang]

On 2011/3/24 06:51 PM, Richard Earnshaw wrote:
> 
> On Thu, 2011-03-24 at 12:56 +0900, Chung-Lin Tang wrote:
>> Hi,
>> PR48250 happens under TARGET_NEON, where DImode is included within the
>> valid NEON modes. This turns the range of legitimate constant indexes to
>> step-4 (coproc load/store), thus arm_legitimize_reload_address() when
>> trying to decompose the [reg+index] reload address into
>> [(reg+index_high)+index_low], can cause an ICE later when 'index_low'
>> part is not aligned to 4.
>>
>> I'm not sure why the current DImode index is computed as:
>> low = ((val & 0xf) ^ 0x8) - 0x8;  the sign-extending into negative
>> values, then subtracting back, actually creates further off indexes.
>> e.g. in the supplied testcase, [sp+13] was turned into [(sp+16)-3].
>>
> 
> Hysterical Raisins... the code there was clearly written for the days
> before we had LDRD in the architecture.  At that time the most efficient
> way to load a 64-bit object was to use the LDM{ia,ib,da,db}
> instructions.  The computation here was (I think), intended to try and
> make the most efficient use of an add/sub instruction followed by
> LDM/STM offsetting.  At that time the architecture had no unaligned
> access either, so dealing with 64-bit that were less than 32-bit aligned
> (in those days 32-bit was the maximum alignment) probably wasn't
> considered, or couldn't even get through to reload.
>

I see it now. The code in output_move_double() returning assembly for
ldm/stm(db/da/ib) for offsets -8/-4/+4 seems to confirm this.

I have changed the patch to let the new code handle the TARGET_LDRD case
only.  The pre-LDRD case is still handled by the original code, with an
additional & ~0x3 for aligning the offset to 4.

I've also added a comment for the pre-TARGET_LDRD case. Please see if
the description is accurate enough.

>> My patch changes the index decomposing to a more straightforward way; it
>> also sort of outlines the way the other reload address indexes are
>> broken by using and-masks, is not the most effective.  The address is
>> computed by addition, subtracting away the parts to obtain low+high
>> should be the optimal way of giving the largest computable index range.
>>
>> I have included a few Thumb-2 bits in the patch; I know currently
>> arm_legitimize_reload_address() is only used under TARGET_ARM, but I
>> guess it might eventually be turned into TARGET_32BIT.
>>
> 
> I think this needs to be looked at carefully on ARMv4/ARMv4T to check
> that it doesn't cause regressions there when we don't have LDRD in the
> instruction set.

I'll be testing the modified patch under an ARMv4/ARMv4T configuration.
Okay for trunk if no regressions?

Thanks,
Chung-Lin

PR target/48250
* config/arm/arm.c (arm_legitimize_reload_address): Adjust
DImode constant index decomposing under TARGET_LDRD. Clear
lower two bits for NEON, Thumb-2, and !TARGET_LDRD. Add
comment for !TARGET_LDRD case.
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 171652)
+++ config/arm/arm.c(working copy)
@@ -6420,7 +6420,32 @@
   HOST_WIDE_INT low, high;
 
   if (mode == DImode || (mode == DFmode && TARGET_SOFT_FLOAT))
-   low = ((val & 0xf) ^ 0x8) - 0x8;
+   {
+ if (TARGET_LDRD)
+   {
+ /* ??? There may be more adjustments later for Thumb-2,
+which has a ldrd insn with +-1020 index range.  */
+ int max_idx = 255;
+
+ /* low == val, if val is within range [-max_idx, +max_idx].
+If not, val is set to the boundary +-max_idx.  */
+ low = (-max_idx <= val && val <= max_idx
+? val : (val > 0 ? max_idx : -max_idx));
+
+ /* Thumb-2 ldrd, and NEON coprocessor load/store indexes
+are in steps of 4, so the least two bits need to be
+cleared to zero.  */
+ if (TARGET_NEON || TARGET_THUMB2)
+   low &= ~0x3;
+   }
+ else
+   {
+ /* For pre-ARMv5TE (without ldrd), we use ldm/stm(db/da/ib)
+to access doublewords. The supported load/store offsets are
+-8, -4, and 4, which we try to produce here.  */
+ low = (((val & 0xf) ^ 0x8) - 0x8) & ~0x3;
+   }
+   }
   else if (TARGET_MAVERICK && TARGET_HARD_FLOAT)
/* Need to be careful, -256 is not a valid offset.  */
low = val >= 0 ? (val & 0xff) : -((-val) & 0xff);

[patch] Fix PR tree-optmization/48290

[Ira Rosen]

Hi,

This patch fixes the vectorizer part of PR tree-optmization/48290 by
checking that if we have a phi in outer loop in the basic block after the
inner loop, then this phi is really inner loop's exit phi, i.e., its
operand is defined in the inner loop.

Bootstrapped with vectorization enabled on powerpc64-suse-linux and tested
on x86_64-suse-linux.
Committed.

Ira

ChangeLog:

PR tree-optimization/48290
* tree-vect-loop.c (vect_analyze_loop_operations): In outer loop
vectorization, check that relevant phis in the basic block after
the inner loop are really inner loop's exit phis.


Index: tree-vect-loop.c
===
--- tree-vect-loop.c(revision 171654)
+++ tree-vect-loop.c(working copy)
@@ -1184,11 +1184,11 @@ vect_analyze_loop_operations (loop_vec_info loop_v
   print_gimple_stmt (vect_dump, phi, 0, TDF_SLIM);
 }

+  /* Inner-loop loop-closed exit phi in outer-loop vectorization
+ (i.e., a phi in the tail of the outer-loop).  */
   if (! is_loop_header_bb_p (bb))
 {
-  /* inner-loop loop-closed exit phi in outer-loop
vectorization
- (i.e. a phi in the tail of the outer-loop).
- FORNOW: we currently don't support the case that these
phis
+  /* FORNOW: we currently don't support the case that these
phis
  are not used in the outerloop (unless it is double
reduction,
  i.e., this phi is vect_reduction_def), cause this case
  requires to actually do something here.  */
@@ -1202,6 +1202,32 @@ vect_analyze_loop_operations (loop_vec_info loop_v
  "Unsupported loop-closed phi in
outer-loop.");
   return false;
 }
+
+  /* If PHI is used in the outer loop, we check that its
operand
+ is defined in the inner loop.  */
+  if (STMT_VINFO_RELEVANT_P (stmt_info))
+{
+  tree phi_op;
+  gimple op_def_stmt;
+
+  if (gimple_phi_num_args (phi) != 1)
+return false;
+
+  phi_op = PHI_ARG_DEF (phi, 0);
+  if (TREE_CODE (phi_op) != SSA_NAME)
+return false;
+
+  op_def_stmt = SSA_NAME_DEF_STMT (phi_op);
+  if (!op_def_stmt || !vinfo_for_stmt (op_def_stmt))
+return false;
+
+  if (STMT_VINFO_RELEVANT (vinfo_for_stmt (op_def_stmt))
+!= vect_used_in_outer
+  && STMT_VINFO_RELEVANT (vinfo_for_stmt
(op_def_stmt))
+   != vect_used_in_outer_by_reduction)
+return false;
+}
+
   continue;
 }

Re: [patch] Fix PR48183, NEON ICE in emit-rtl.c:immed_double_const() under -g

[Richard Sandiford]

Julian Brown  writes:
> On Thu, 24 Mar 2011 10:57:06 +
> Richard Sandiford  wrote:
>
>> Chung-Lin Tang  writes:
>> > PR48183 is a case where ARM NEON instrinsics, under -O -g, produce
>> > debug insns that tries to expand OImode (32-byte integer) zero
>> > constants, much too large to represent as two HOST_WIDE_INTs; as
>> > the internals manual indicates, such large constants are not
>> > supported in general, and ICEs on the GET_MODE_BITSIZE(mode) ==
>> > 2*HOST_BITS_PER_WIDE_INT assertion.
>> >
>> > This patch allows the cases where the large integer constant is
>> > still representable using a single CONST_INT, such as zero(0).
>> > Bootstrapped and tested on i686 and x86_64, cross-tested on ARM,
>> > all without regressions. Okay for trunk?
>> >
>> > Thanks,
>> > Chung-Lin
>> >
>> > 2011-03-20  Chung-Lin Tang  
>> >
>> >* emit-rtl.c (immed_double_const): Allow wider than
>> >2*HOST_BITS_PER_WIDE_INT mode constants when they are
>> >representable as a single const_int RTX.
>> 
>> I realise this might be seen as a good expedient fix, but it makes
>> me a bit uneasy.  Not a very constructive rationale, sorry.
>
> FWIW I also had a "fix" for this issue, which is equivalent to
> Chung-Lin's patch apart from only allowing constant-zero (attached).
> That's not really a vote from me for this approach, but maybe limiting
> the extent to which we pretend to support wide-integer constants like
> this is sensible, if we do go that way.

So that each suggestion has a patch, here's mine.  I've snipped the
regenerated file from the testcase, but to get a flavour, the changes
are like this:

@@ -6099,63 +6099,72 @@ vtbl1_p8 (poly8x8_t __a, uint8x8_t __b)
 __extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
 vtbl2_s8 (int8x8x2_t __a, int8x8_t __b)
 {
-  union { int8x8x2_t __i; __builtin_neon_ti __o; } __au = { __a };
+  union { int8x8x2_t __i; __builtin_neon_ti __o; } __au;
+  __au.__i = __a;
   return (int8x8_t)__builtin_neon_vtbl2v8qi (__au.__o, __b);
 }

Of course, Chung-Lin's testcase should be included whichever way we go.

Richard


gcc/
* config/arm/neon-gen.ml (params): Separate the union initialisation
from the union itself.  Return a list of statements.
(print_variant): Update call accordingly.  Add the returned statements
before the ones returned by "return".
* config/arm/arm_neon.h: Regenerate.

Index: gcc/config/arm/neon-gen.ml
===
--- gcc/config/arm/neon-gen.ml  2009-11-11 15:08:40.0 +
+++ gcc/config/arm/neon-gen.ml  2011-03-29 11:37:52.0 +0100
@@ -165,12 +165,14 @@ let rec element_type ctype =
 
 let params return_by_ptr ps =
   let pdecls = ref [] in
+  let pstmts = ref [] in
   let ptype t p =
 match t with
   T_arrayof (num, elts) ->
-let uname = union_string num elts (p ^ "u") in
-let decl = Printf.sprintf "%s = { %s };" uname p in
+let decl = union_string num elts (p ^ "u") ^ ";" in
+let assignment = p ^ "u.__i = " ^ p ^ ";" in
 pdecls := decl :: !pdecls;
+pstmts := assignment :: !pstmts;
 p ^ "u.__o"
 | _ -> add_cast t p in
   let plist = match ps with
@@ -183,10 +185,11 @@ let params return_by_ptr ps =
   match ps with
 Arity0 ret | Arity1 (ret, _) | Arity2 (ret, _, _) | Arity3 (ret, _, _, _)
   | Arity4 (ret, _, _, _, _) ->
+  !pdecls, !pstmts,
   if return_by_ptr then
-!pdecls, add_cast (T_ptrto (element_type ret)) "&__rv.val[0]" :: plist
+add_cast (T_ptrto (element_type ret)) "&__rv.val[0]" :: plist
   else
-!pdecls, plist
+plist
 
 let modify_params features plist =
   let is_flipped =
@@ -243,14 +246,14 @@ let print_variant opcode features shape 
   let bits = infoword_value elttype features in
   let modesuf = mode_suffix elttype shape in
   let return_by_ptr = return_by_ptr features in
-  let pdecls, paramlist = params return_by_ptr ctype in
+  let pdecls, pstmts, paramlist = params return_by_ptr ctype in
   let paramlist' = modify_params features paramlist in
   let paramlist'' = extra_word shape features paramlist' bits in
   let parstr = String.concat ", " paramlist'' in
   let builtin = Printf.sprintf "__builtin_neon_%s%s (%s)"
   (builtin_name features name) modesuf parstr in
-  let rdecls, stmts = return ctype return_by_ptr builtin in
-  let body = pdecls @ rdecls @ stmts
+  let rdecls, rstmts = return ctype return_by_ptr builtin in
+  let body = pdecls @ rdecls @ pstmts @ rstmts
   and fnname = (intrinsic_name name) ^ "_" ^ (string_of_elt elttype) in
   print_function ctype fnname body
 

Re: [patch] Fix PR48183, NEON ICE in emit-rtl.c:immed_double_const() under -g

[Richard Guenther]

On Thu, Mar 24, 2011 at 11:57 AM, Richard Sandiford
 wrote:
> Chung-Lin Tang  writes:
>> PR48183 is a case where ARM NEON instrinsics, under -O -g, produce debug
>> insns that tries to expand OImode (32-byte integer) zero constants, much
>> too large to represent as two HOST_WIDE_INTs; as the internals manual
>> indicates, such large constants are not supported in general, and ICEs
>> on the GET_MODE_BITSIZE(mode) == 2*HOST_BITS_PER_WIDE_INT assertion.
>>
>> This patch allows the cases where the large integer constant is still
>> representable using a single CONST_INT, such as zero(0). Bootstrapped
>> and tested on i686 and x86_64, cross-tested on ARM, all without
>> regressions. Okay for trunk?
>>
>> Thanks,
>> Chung-Lin
>>
>> 2011-03-20  Chung-Lin Tang  
>>
>>       * emit-rtl.c (immed_double_const): Allow wider than
>>       2*HOST_BITS_PER_WIDE_INT mode constants when they are
>>       representable as a single const_int RTX.
>
> I realise this might be seen as a good expedient fix, but it makes
> me a bit uneasy.  Not a very constructive rationale, sorry.
>
> For this particular case, the problem is that vst2q_s32 and the
> like initialise a union directly:
>
>  union { int32x4x2_t __i; __builtin_neon_oi __o; } __bu = { __b; };
>
> and this gets translated into a zeroing of the whole union followed
> by an assignment to __i:
>
>  __bu = {};
>  __bu.__i = __b;

Btw, this looks like a missed optimization in gimplification.  Worth
a bugreport (or even a fix).  Might be a target but as well, dependent
on how __builtin_neon_oi looks like.  Do you have a complete testcase
that reproduces the above with a cross?

Richard.

> We later optimise away the first assignment, but it still exists
> in the debug info.
>
> Another expedient fix might be to replace these initialisations with:
>
>  union { int32x4x2_t __i; __builtin_neon_oi __o; } __bu;
>  __bu.__i = __b;
>
> so that we never get a zeroing statement.
>
> I realise both "fixes" are papering over the real problem.  What we really
> need is arbitrary-length constant integers, like we already have for vectors.
> But that's going to be a much bigger patch.  It just seems to me that,
> if we're going for a work-around, the arm_neon.h change is neutral,
> while changing immed_double_const feels more risky.
>
> Richard
>

[testsuite, fortran] Compile gfortran.dg/bessel_[67].f90 with -mieee

[Rainer Orth]

The gfortran.dg/bessel_[67].f90 execution tests FAIL on Tru64 UNIX
V5.1B.  I've noticed that adding -mieee makes bessel_7.f90 pass and
improves the situation for bessel_6.f90.  With the print statements
uncommented, here's what I get for the unmodifed source:

 YN for X =0.000  -- Epsilon =   1.19209290E-07
 0  0.1E+01  0.1E+010.00E+00  0.00  T
Floating point exception

With -mieee, I get instead:

 YN for X =0.000  -- Epsilon =   1.19209290E-07
 0  0.1E+01  0.1E+010.00E+00  0.00  T
 1  0.0E+00  0.0E+000.00E+00   NaN  T
 2  0.0E+00  0.0E+000.00E+00   NaN  T
 3  0.0E+00  0.0E+000.00E+00   NaN  T
 4  0.0E+00  0.0E+000.00E+00   NaN  T
 5  0.0E+00  0.0E+000.00E+00   NaN  T
 6  0.0E+00  0.0E+000.00E+00   NaN  T
 7  0.0E+00  0.0E+000.00E+00   NaN  T
 8  0.0E+00  0.0E+000.00E+00   NaN  T
 9  0.0E+00  0.0E+000.00E+00   NaN  T
10  0.0E+00  0.0E+000.00E+00   NaN  T
11  0.0E+00  0.0E+000.00E+00   NaN  T
12  0.0E+00  0.0E+000.00E+00   NaN  T
13  0.0E+00  0.0E+000.00E+00   NaN  T
14  0.0E+00  0.0E+000.00E+00   NaN  T
15  0.0E+00  0.0E+000.00E+00   NaN  T
16  0.0E+00  0.0E+000.00E+00   NaN  T
17  0.0E+00  0.0E+000.00E+00   NaN  T
18  0.0E+00  0.0E+000.00E+00   NaN  T
19  0.0E+00  0.0E+000.00E+00   NaN  T
20  0.0E+00  0.0E+000.00E+00   NaN  T
21  0.0E+00  0.0E+000.00E+00   NaN  T
22  0.0E+00  0.0E+000.00E+00   NaN  T
23  0.0E+00  0.0E+000.00E+00   NaN  T
24  0.0E+00  0.0E+000.00E+00   NaN  T
25  0.0E+00  0.0E+000.00E+00   NaN  T
26  0.0E+00  0.0E+000.00E+00   NaN  T
27  0.0E+00  0.0E+000.00E+00   NaN  T
28  0.0E+00  0.0E+000.00E+00   NaN  T
29  0.0E+00  0.0E+000.00E+00   NaN  T
30  0.0E+00  0.0E+000.00E+00   NaN  T
31  0.0E+00  0.0E+000.00E+00   NaN  T
32  0.0E+00  0.0E+000.00E+00   NaN  T
33  0.0E+00  0.0E+000.00E+00   NaN  T
34  0.0E+00  0.0E+000.00E+00   NaN  T
35  0.0E+00  0.0E+000.00E+00   NaN  T
36  0.0E+00  0.0E+000.00E+00   NaN  T
37  0.0E+00  0.0E+000.00E+00   NaN  T
38  0.0E+00  0.0E+000.00E+00   NaN  T
39  0.0E+00  0.0E+000.00E+00   NaN  T
40  0.0E+00  0.0E+000.00E+00   NaN  T
41  0.0E+00  0.0E+000.00E+00   NaN  T
42  0.0E+00  0.0E+000.00E+00   NaN  T
43  0.0E+00  0.0E+000.00E+00   NaN  T
44  0.0E+00  0.0E+000.00E+00   NaN  T
45  0.0E+00  0.0E+000.00E+00   NaN  T
46  0.0E+00  0.0E+000.00E+00   NaN  T
47  0.0E+00  0.0E+000.00E+00   NaN  T
48  0.0E+00  0.0E+000.00E+00   NaN  T
49  0.0E+00  0.0E+000.00E+00   NaN  T
50  0.0E+00  0.0E+000.00E+00   NaN  T
51  0.0E+00  0.0E+000.00E+00   NaN  T
52  0.0E+00  0.0E+000.00E+00   NaN  T
53  0.0E+00  0.0E+000.00E+00   NaN  T
54  0.0E+00  0.0E+000.00E+00   NaN  T
55  0.0E+00  0.0E+000.00E+00   NaN  T
56  0.0E+00  0.0E+000.00E+00   NaN  T
57  0.0E+00  0.0E+000.00E+00   NaN  T
58  0.0E+00  0.0E+000.00E+00   NaN  T
59  0.0E+00  0.0E+000.00E+00   NaN  T
60  0.0E+00  0.0E+000.00E+00   NaN  T
61  0.0E+00  0.0E+000.00E+00   NaN  T
62  0.0E+00  0.0E+000.00E+00   NaN  T
63  0.0E+00  0.0E+000.00E+00   NaN  T
64  0.000

[PATCH, alpha]: Fix ICE in mems_in_disjoint_alias_sets_p

[Uros Bizjak]

Hello!

Attached patch fixes the same ICE as seen on sparc [1], where it was
fixed by [2].

2011-03-29  Uros Bizjak  

* config/alpha/alpha.c (alpha_sr_alias_set): Don't define.
(alpha_option_override): Don't set alpha_sr_alias_set.
(emit_frame_store_1): Use gen_frame_mem rather than calling
set_mem_alias_set.
(alpha_expand_epilogue): Ditto.

This patch is prerequisite to build libgo on alpha. Due to
binutils-2.21 bug [3] and independently of this patch, the bootstrap
with go enabled fails with an (otherwise harmless) compare failure in
the go directory.

Patch was bootstrapped and regression tested on alphaev68-pc-linux-gnu.

OK for 4.7 and 4.6.1?

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47219
[2] http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00916.html

[3] http://sourceware.org/bugzilla/show_bug.cgi?id=12610

Uros.
Index: alpha.c
===
--- alpha.c (revision 171651)
+++ alpha.c (working copy)
@@ -95,10 +95,6 @@ int alpha_memory_latency = 3;
 
 static int alpha_function_needs_gp;
 
-/* The alias set for prologue/epilogue register save/restore.  */
-
-static GTY(()) alias_set_type alpha_sr_alias_set;
-
 /* The assembler name of the current function.  */
 
 static const char *alpha_fnname;
@@ -476,9 +472,6 @@ alpha_option_override (void)
   if (align_functions <= 0)
 align_functions = 16;
 
-  /* Acquire a unique set number for our register saves and restores.  */
-  alpha_sr_alias_set = new_alias_set ();
-
   /* Register variables and functions with the garbage collector.  */
 
   /* Set up function hooks.  */
@@ -7448,8 +7441,7 @@ emit_frame_store_1 (rtx value, rtx base_
   rtx addr, mem, insn;
 
   addr = plus_constant (base_reg, base_ofs);
-  mem = gen_rtx_MEM (DImode, addr);
-  set_mem_alias_set (mem, alpha_sr_alias_set);
+  mem = gen_frame_mem (DImode, addr);
 
   insn = emit_move_insn (mem, value);
   RTX_FRAME_RELATED_P (insn) = 1;
@@ -8056,9 +8048,7 @@ alpha_expand_epilogue (void)
 
   /* Restore registers in order, excepting a true frame pointer.  */
 
-  mem = gen_rtx_MEM (DImode, plus_constant (sa_reg, reg_offset));
-  if (! eh_ofs)
-set_mem_alias_set (mem, alpha_sr_alias_set);
+  mem = gen_frame_mem (DImode, plus_constant (sa_reg, reg_offset));
   reg = gen_rtx_REG (DImode, REG_RA);
   emit_move_insn (reg, mem);
   cfa_restores = alloc_reg_note (REG_CFA_RESTORE, reg, cfa_restores);
@@ -8073,8 +8063,8 @@ alpha_expand_epilogue (void)
  fp_offset = reg_offset;
else
  {
-   mem = gen_rtx_MEM (DImode, plus_constant(sa_reg, reg_offset));
-   set_mem_alias_set (mem, alpha_sr_alias_set);
+   mem = gen_frame_mem (DImode,
+plus_constant (sa_reg, reg_offset));
reg = gen_rtx_REG (DImode, i);
emit_move_insn (reg, mem);
cfa_restores = alloc_reg_note (REG_CFA_RESTORE, reg,
@@ -8086,8 +8076,7 @@ alpha_expand_epilogue (void)
   for (i = 0; i < 31; ++i)
if (fmask & (1UL << i))
  {
-   mem = gen_rtx_MEM (DFmode, plus_constant(sa_reg, reg_offset));
-   set_mem_alias_set (mem, alpha_sr_alias_set);
+   mem = gen_frame_mem (DFmode, plus_constant (sa_reg, reg_offset));
reg = gen_rtx_REG (DFmode, i+32);
emit_move_insn (reg, mem);
cfa_restores = alloc_reg_note (REG_CFA_RESTORE, reg, cfa_restores);
@@ -8145,8 +8134,7 @@ alpha_expand_epilogue (void)
   if (fp_is_frame_pointer)
{
  emit_insn (gen_blockage ());
- mem = gen_rtx_MEM (DImode, plus_constant (sa_reg, fp_offset));
- set_mem_alias_set (mem, alpha_sr_alias_set);
+ mem = gen_frame_mem (DImode, plus_constant (sa_reg, fp_offset));
  emit_move_insn (hard_frame_pointer_rtx, mem);
  cfa_restores = alloc_reg_note (REG_CFA_RESTORE,
 hard_frame_pointer_rtx, cfa_restores);

[PATCH, PR 48195] Move around ipa_check_create_node_params and ipa_check_create_edge_args

[Martin Jambor]

Hi,

PR 48195 happens because analyze_node in ipa-inline can be called from
add_new_function hook and thus bypass calls for
ipa_check_create_node_params and ipa_check_create_edge_args in
inline_generate_summary.  The two functions are required to reallocate
info arrays if necessary before calling ipa_analyze_node.

This revealed the whole setup is rather fragile so I moved the
reallocation functions directly to ipa_analyze_node.  This means the
node count is checked each time we analyze a node but the overhead
should be tiny and we'll avoid issues like this.

The other caller of ipa_analyze_node is ipa-cp so I removed the now
unnecessary calls in ipcp_generate_summary too.  This in turn revealed
that ipcp_driver lacks these calls (which has always been basically a
hidden bug ever since we made ipa-cp a proper IPA pass) so I added it
there.

Bootstrapped and tested on x86_64-linux on both trunk and 4.6 branch
without any issues.  OK for both?

Thanks,

Martin


Index: src/gcc/ipa-cp.c
===
--- src.orig/gcc/ipa-cp.c
+++ src/gcc/ipa-cp.c
@@ -1516,6 +1516,8 @@ ipcp_driver (void)
 ipa_print_all_params (dump_file);
   ipa_print_all_jump_functions (dump_file);
 }
+  ipa_check_create_node_params ();
+  ipa_check_create_edge_args ();
   /* 2. Do the interprocedural propagation.  */
   ipcp_iterate_stage ();
   /* 3. Insert the constants found to the functions.  */
@@ -1543,8 +1545,6 @@ ipcp_generate_summary (void)
 
   if (dump_file)
 fprintf (dump_file, "\nIPA constant propagation start:\n");
-  ipa_check_create_node_params ();
-  ipa_check_create_edge_args ();
   ipa_register_cgraph_hooks ();
 
   for (node = cgraph_nodes; node; node = node->next)
Index: src/gcc/ipa-inline.c
===
--- src.orig/gcc/ipa-inline.c
+++ src/gcc/ipa-inline.c
@@ -2091,11 +2091,7 @@ inline_generate_summary (void)
   cgraph_add_function_insertion_hook (&add_new_function, NULL);
 
   if (flag_indirect_inlining)
-{
-  ipa_register_cgraph_hooks ();
-  ipa_check_create_node_params ();
-  ipa_check_create_edge_args ();
-}
+ipa_register_cgraph_hooks ();
 
   for (node = cgraph_nodes; node; node = node->next)
 if (node->analyzed)
Index: src/gcc/ipa-prop.c
===
--- src.orig/gcc/ipa-prop.c
+++ src/gcc/ipa-prop.c
@@ -1522,10 +1522,13 @@ ipa_analyze_params_uses (struct cgraph_n
 void
 ipa_analyze_node (struct cgraph_node *node)
 {
-  struct ipa_node_params *info = IPA_NODE_REF (node);
+  struct ipa_node_params *info;
   struct param_analysis_info *parms_info;
   int i, param_count;
 
+  ipa_check_create_node_params ();
+  ipa_check_create_edge_args ();
+  info = IPA_NODE_REF (node);
   push_cfun (DECL_STRUCT_FUNCTION (node->decl));
   current_function_decl = node->decl;
   ipa_initialize_node_params (node);
Index: src/gcc/testsuite/gcc.dg/ipa/pr48195.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/ipa/pr48195.c
@@ -0,0 +1,24 @@
+/* { dg-do link } */
+/* { dg-options "-O2 -flto --param partial-inlining-entry-probability=101" } */
+
+extern void abort(void);
+
+int i;
+
+void __attribute__ ((constructor))
+c2 ()
+{
+  if (i)
+abort ();
+}
+
+void __attribute__ ((destructor))
+d1 ()
+{
+  if (i)
+abort ();
+}
+
+void main ()
+{
+}

Re: [patch] Fix PR48183, NEON ICE in emit-rtl.c:immed_double_const() under -g

[Richard Sandiford]

Richard Guenther  writes:
> On Thu, Mar 24, 2011 at 11:57 AM, Richard Sandiford
>  wrote:
>> Chung-Lin Tang  writes:
>>> PR48183 is a case where ARM NEON instrinsics, under -O -g, produce debug
>>> insns that tries to expand OImode (32-byte integer) zero constants, much
>>> too large to represent as two HOST_WIDE_INTs; as the internals manual
>>> indicates, such large constants are not supported in general, and ICEs
>>> on the GET_MODE_BITSIZE(mode) == 2*HOST_BITS_PER_WIDE_INT assertion.
>>>
>>> This patch allows the cases where the large integer constant is still
>>> representable using a single CONST_INT, such as zero(0). Bootstrapped
>>> and tested on i686 and x86_64, cross-tested on ARM, all without
>>> regressions. Okay for trunk?
>>>
>>> Thanks,
>>> Chung-Lin
>>>
>>> 2011-03-20  Chung-Lin Tang  
>>>
>>>       * emit-rtl.c (immed_double_const): Allow wider than
>>>       2*HOST_BITS_PER_WIDE_INT mode constants when they are
>>>       representable as a single const_int RTX.
>>
>> I realise this might be seen as a good expedient fix, but it makes
>> me a bit uneasy.  Not a very constructive rationale, sorry.
>>
>> For this particular case, the problem is that vst2q_s32 and the
>> like initialise a union directly:
>>
>>  union { int32x4x2_t __i; __builtin_neon_oi __o; } __bu = { __b; };
>>
>> and this gets translated into a zeroing of the whole union followed
>> by an assignment to __i:
>>
>>  __bu = {};
>>  __bu.__i = __b;
>
> Btw, this looks like a missed optimization in gimplification.  Worth
> a bugreport (or even a fix).  Might be a target but as well, dependent
> on how __builtin_neon_oi looks like.  Do you have a complete testcase
> that reproduces the above with a cross?

Yeah, build cc1 for arm-linux-gnueabi and compile the attached
testcase (from Chung-Lin) using:

  -O2 -g -mfpu=neon -mfloat-abi=softfp

Rchard

/* { dg-do compile } */
/* { dg-require-effective-target arm_neon_ok } */
/* { dg-options "-O -g" } */
/* { dg-add-options arm_neon } */

#include 

void move_16bit_to_32bit (int32_t *dst, const short *src, unsigned n)
{
unsigned i;
int16x4x2_t input;
int32x4x2_t mid;
int32x4x2_t output;

for (i = 0; i < n/2; i += 8) {
input = vld2_s16(src + i);
mid.val[0] = vmovl_s16(input.val[0]);
mid.val[1] = vmovl_s16(input.val[1]);
output.val[0] = vshlq_n_s32(mid.val[0], 8);
output.val[1] = vshlq_n_s32(mid.val[1], 8);
vst2q_s32((int32_t *)dst + i, output);
}
}

Re: [PING][PATCH, testsuite] Update gcc.dg/stack-usage-1.c SIZE values for powerpc

[Peter Bergner]

On Tue, 2011-03-29 at 07:39 +0200, Dominique Dhumieres wrote:
> > Ok, slightly updated.  How about this? ...
> 
> It did not work either at -m64, but the following one seems to work
> (manual testing):
> 
> --- /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/stack-usage-1.c  2011-03-28 
> 20:27:57.0 +0200
> +++ /opt/gcc/work/gcc/testsuite/gcc.dg/stack-usage-1.c2011-03-29 
> 07:35:59.0 +0200
> @@ -30,12 +30,17 @@
>  #  else
>  #define SIZE 248
>  #  endif
> -#elif defined (__powerpc64__) || defined (__PPC64__)
> +#elif defined (__powerpc64__) || defined (__ppc64__) || defined 
> (__POWERPC64__) \
> +  || defined (__PPC64__)
>  #  define SIZE 180

Ahh, I thought the SIZE was off and it was just that darwin doesn't
define the same macros.  Well it's good to see both 64-bit
Linux and darwin share the same stack usage, which makes sense.
Thanks.

Mike and David, I assume the updated patch below is ok for mainline?

Peter

* gcc.dg/stack-usage-1.c (SIZE): Provide proper values for __ppc64__
and __APPLE__ && __PPC__ && __ALTIVEC__.

--- /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/stack-usage-1.c2011-03-28 
20:27:57.0 +0200
+++ /opt/gcc/work/gcc/testsuite/gcc.dg/stack-usage-1.c  2011-03-29 
07:35:59.0 +0200
@@ -30,12 +30,17 @@
 #  else
 #define SIZE 248
 #  endif
-#elif defined (__powerpc64__) || defined (__PPC64__)
+#elif defined (__powerpc64__) || defined (__ppc64__) || defined 
(__POWERPC64__) \
+  || defined (__PPC64__)
 #  define SIZE 180
 #elif defined (__powerpc__) || defined (__PPC__) || defined (__ppc__) \
   || defined (__POWERPC__) || defined (PPC) || defined (_IBMR2)
 #  if defined (__ALTIVEC__)
-#define SIZE 220
+#if defined (__APPLE__)
+#  define SIZE 204
+#else
+#  define SIZE 220
+#endif
 #  else
 #define SIZE 240
 #  endif

Re: Cleaning up expand optabs code

[Mikael Pettersson]

Richard Sandiford writes:
 > Andreas Krebbel  writes:
 > > On 03/22/2011 06:48 PM, Richard Henderson wrote:
 > >
 > >> Ok.  Watch out for other target problems this week.
 > >
 > > This unfortunately broke bootstrap on s390.
 > 
 > This is PR 48263.  Since it seems to be affecting several targets,
 > and since my bootstrap seems to be taking a looong time, I'll post
 > the patch here before testing has finished.
 > 
 > > Just copying the pre-patch behaviour fixes the problem for me:
 > 
 > I think we need to undo more of the patch, and leave the conversion
 > outside of the new interface.
 > 
 > Sorry for the breakage.
 > 
 > Richard
 > 
 > 
 > gcc/
 >  PR rtl-optimization/48263
 >  * optabs.c (expand_binop_directly): Reinstate convert_modes code
 >  and original commutative_p handling.  Use maybe_gen_insn.

Unfortunately this fix (r171418) broke m68k-linux, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48332

/Mikael

Fix RX performance regressions on 4.6 branch

[Nick Clifton]

Hi Guys,

  I am applying the patch below to fix a couple of performance
  regressions for the RX toolchain on the 4.6 branch (when compared to
  the 4.5 branch).  These include aligning jumps, loops and labels, and
  combining extending loads and simple arithmetic operations.

Cheers
  Nick

gcc/ChangeLog
2011-03-29  Nick Clifton  

* config/rx/rx.h (LABEL_ALIGN_AFTER_BARRIER): Define.
(ASM_OUTPUT_MAX_SKIP): Define.
* config/rx/predicates.md (rx_zs_comparison_operator): Do not
allow LT aor GE comparisons.
* config/rx/rx-protos.h (rx_align_for_label): Prototype.
* config/rx/rx.md: Add peepholes and patterns to combine extending
loads with simple arithmetic instructions.
* config/rx/rx.c (rx_is_legitimate_address): Allow QI and HI modes
to use pre-decrement and post-increment addressing.
(rx_is_restricted_memory_address): For REG+INT addressing, ensure
that the INT is a valid offset.
(rx_print_operand): Handle %R.
Fix %Q's handling of MEMs.
(rx_option_override): Set alignments.
(rx_align_for_label): New function.
(rx_max_skip_for_label): New function.
(TARGET_ASM_JUMP_ALIGN_MAX_SKIP): Define.
(TARGET_ASM_LOOP_ALIGN_MAX_SKIP): Define.
(TARGET_ASM_LABEL_ALIGN_MAX_SKIP): Define.
(TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP): Define.

Index: gcc/config/rx/rx.h
===
--- gcc/config/rx/rx.h  (revision 171651)
+++ gcc/config/rx/rx.h  (working copy)
@@ -615,4 +615,23 @@
 #define BRANCH_COST(SPEED,PREDICT)   1
 #define REGISTER_MOVE_COST(MODE,FROM,TO) 2
 
-#define SELECT_CC_MODE(OP,X,Y)  rx_select_cc_mode(OP, X, Y)
+#define SELECT_CC_MODE(OP,X,Y)  rx_select_cc_mode((OP), (X), (Y))
+
+#define LABEL_ALIGN_AFTER_BARRIER(x)   rx_align_for_label ()
+
+#define ASM_OUTPUT_MAX_SKIP_ALIGN(STREAM, LOG, MAX_SKIP)   \
+  do   \
+{  \
+  if ((LOG) == 0 || (MAX_SKIP) == 0)   \
+break; \
+  if (TARGET_AS100_SYNTAX) \
+   {   \
+ if ((LOG) >= 2)   \
+   fprintf (STREAM, "\t.ALIGN 4\t; %d alignment actually requested\n", 
1 << (LOG)); \
+ else  \
+   fprintf (STREAM, "\t.ALIGN 2\n");   \
+   }   \
+  else \
+   fprintf (STREAM, "\t.balign %d,3,%d\n", 1 << (LOG), (MAX_SKIP));
\
+}  \
+  while (0)
Index: gcc/config/rx/predicates.md
===
--- gcc/config/rx/predicates.md (revision 171651)
+++ gcc/config/rx/predicates.md (working copy)
@@ -284,7 +284,7 @@
 )
 
 (define_predicate "rx_zs_comparison_operator"
-  (match_code "eq,ne,lt,ge")
+  (match_code "eq,ne")
 )
 
 ;; GT and LE omitted due to operand swap required.
Index: gcc/config/rx/rx-protos.h
===
--- gcc/config/rx/rx-protos.h   (revision 171651)
+++ gcc/config/rx/rx-protos.h   (working copy)
@@ -30,16 +30,17 @@
 extern int rx_initial_elimination_offset (int, int);
 
 #ifdef RTX_CODE
+extern int rx_align_for_label (void);
 extern void rx_emit_stack_popm (rtx *, bool);
 extern void rx_emit_stack_pushm (rtx *);
 extern voidrx_expand_epilogue (bool);
 extern char *  rx_gen_move_template (rtx *, bool);
 extern boolrx_is_legitimate_constant (rtx);
 extern boolrx_is_restricted_memory_address (rtx, Mmode);
+extern boolrx_match_ccmode (rtx, Mmode);
 extern voidrx_notice_update_cc (rtx body, rtx insn);
 extern voidrx_split_cbranch (Mmode, Rcode, rtx, rtx, rtx);
 extern Mmode   rx_select_cc_mode (Rcode, rtx, rtx);
-extern boolrx_match_ccmode (rtx, Mmode);
 #endif
 
 #endif /* GCC_RX_PROTOS_H */
Index: gcc/config/rx/rx.md
===
--- gcc/config/rx/rx.md (revision 171651)
+++ gcc/config/rx/rx.md (working copy)
@@ -1545,6 +1545,139 @@
(set_attr "length" "3,4,5,6,7,6")]
 )
 
+;; A set of peepholes to catch extending loads followed by arithmetic 
operations.
+;; We use iterators where possible to reduce the amount of typing and hence the
+;; possibilities for typos.
+
+(define_code_iterator extend_types [(zero_extend "") (sign_extend "")])
+(define_code_attr letter   [(zero_extend "R") (sign_extend "Q")])
+
+(define_code_iterator memex_commutative [(plus "") (and "") (ior "") (xor "")])
+(define_code_iterator memex_noncomm [(div "") (udiv "") (minus "")])
+(define_code_iterator memex_nocc[(smax "") (smin ""

Re: [patch] Fix PR48183, NEON ICE in emit-rtl.c:immed_double_const() under -g

[Richard Guenther]

On Tue, Mar 29, 2011 at 1:52 PM, Richard Sandiford
 wrote:
> Richard Guenther  writes:
>> On Thu, Mar 24, 2011 at 11:57 AM, Richard Sandiford
>>  wrote:
>>> Chung-Lin Tang  writes:
 PR48183 is a case where ARM NEON instrinsics, under -O -g, produce debug
 insns that tries to expand OImode (32-byte integer) zero constants, much
 too large to represent as two HOST_WIDE_INTs; as the internals manual
 indicates, such large constants are not supported in general, and ICEs
 on the GET_MODE_BITSIZE(mode) == 2*HOST_BITS_PER_WIDE_INT assertion.

 This patch allows the cases where the large integer constant is still
 representable using a single CONST_INT, such as zero(0). Bootstrapped
 and tested on i686 and x86_64, cross-tested on ARM, all without
 regressions. Okay for trunk?

 Thanks,
 Chung-Lin

 2011-03-20  Chung-Lin Tang  

       * emit-rtl.c (immed_double_const): Allow wider than
       2*HOST_BITS_PER_WIDE_INT mode constants when they are
       representable as a single const_int RTX.
>>>
>>> I realise this might be seen as a good expedient fix, but it makes
>>> me a bit uneasy.  Not a very constructive rationale, sorry.
>>>
>>> For this particular case, the problem is that vst2q_s32 and the
>>> like initialise a union directly:
>>>
>>>  union { int32x4x2_t __i; __builtin_neon_oi __o; } __bu = { __b; };
>>>
>>> and this gets translated into a zeroing of the whole union followed
>>> by an assignment to __i:
>>>
>>>  __bu = {};
>>>  __bu.__i = __b;
>>
>> Btw, this looks like a missed optimization in gimplification.  Worth
>> a bugreport (or even a fix).  Might be a target but as well, dependent
>> on how __builtin_neon_oi looks like.  Do you have a complete testcase
>> that reproduces the above with a cross?
>
> Yeah, build cc1 for arm-linux-gnueabi and compile the attached
> testcase (from Chung-Lin) using:
>
>  -O2 -g -mfpu=neon -mfloat-abi=softfp

It seems that count_type_elements is confused by unions and thus clearing
is always performed.  I fail to see why count_type_elements could not
simply return 1 for all unions (non-initialized parts have undefined rather
than zero content).

categorize_ctor_elements also counts 8 elements for some reason.

The following fixes it for me:

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 171606)
+++ gcc/expr.c  (working copy)
@@ -5059,7 +5059,7 @@ count_type_elements (const_tree type, bo

 case UNION_TYPE:
 case QUAL_UNION_TYPE:
-  return -1;
+  return 1;

 case COMPLEX_TYPE:
   return 2;

disclaimer: completely untested, might confuse the hell out of
output_init_constructor and friends.

Richard.

> Rchard
>
>

[Patch] improve bfin conditional move support

[Henderson, Stuart]

The attached patch improves conditional move mode support for Blackfin.


2011-03-29  Stuart Henderson  

From Bernd Schmidt:
* config/bfin/bfin.md (MOVCC): New mode_macro.
(movcc_insn1, movcc_insn2, movcc): Renamed from
movsicc_insn1, movsicc_insn2 and movsicc and macroized.  Remove
comments from generated assembly.


I don't have write permissions.

Thanks,
Stu


upstream.patch
Description: upstream.patch

Re: [Patch] improve bfin conditional move support

[Bernd Schmidt]

On 03/29/2011 02:57 PM, Henderson, Stuart wrote:
> I don't have write permissions.

You'll need to get that fixed. See
  http://gcc.gnu.org/svnwrite.html

That page makes it sound like any maintainer can sponsor access, so
please use my name for it.


Bernd

Re: Cleaning up expand optabs code

[Richard Sandiford]

Mikael Pettersson  writes:
> Richard Sandiford writes:
>  > Andreas Krebbel  writes:
>  > > On 03/22/2011 06:48 PM, Richard Henderson wrote:
>  > >
>  > >> Ok.  Watch out for other target problems this week.
>  > >
>  > > This unfortunately broke bootstrap on s390.
>  > 
>  > This is PR 48263.  Since it seems to be affecting several targets,
>  > and since my bootstrap seems to be taking a looong time, I'll post
>  > the patch here before testing has finished.
>  > 
>  > > Just copying the pre-patch behaviour fixes the problem for me:
>  > 
>  > I think we need to undo more of the patch, and leave the conversion
>  > outside of the new interface.
>  > 
>  > Sorry for the breakage.
>  > 
>  > Richard
>  > 
>  > 
>  > gcc/
>  >PR rtl-optimization/48263
>  >* optabs.c (expand_binop_directly): Reinstate convert_modes code
>  >and original commutative_p handling.  Use maybe_gen_insn.
>
> Unfortunately this fix (r171418) broke m68k-linux, see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48332

Please try the attached

Richard


gcc/
PR rtl-optimization/48332
* optabs.c (expand_binop_directly): Set xmodeN to the target-mandated
mode of input operand N and modeN to its actual mode.

Index: gcc/optabs.c
===
--- gcc/optabs.c2011-03-24 17:23:05.0 +
+++ gcc/optabs.c2011-03-29 14:18:02.0 +0100
@@ -1243,9 +1243,9 @@ expand_binop_directly (enum machine_mode
   rtx last)
 {
   enum insn_code icode = optab_handler (binoptab, mode);
-  enum machine_mode mode0 = insn_data[(int) icode].operand[1].mode;
-  enum machine_mode mode1 = insn_data[(int) icode].operand[2].mode;
-  enum machine_mode tmp_mode;
+  enum machine_mode xmode0 = insn_data[(int) icode].operand[1].mode;
+  enum machine_mode xmode1 = insn_data[(int) icode].operand[2].mode;
+  enum machine_mode mode0, mode1, tmp_mode;
   struct expand_operand ops[3];
   bool commutative_p;
   rtx pat;
@@ -1256,8 +1256,8 @@ expand_binop_directly (enum machine_mode
  if we would swap the operands, we can save the conversions.  */
   commutative_p = commutative_optab_p (binoptab);
   if (commutative_p
-  && GET_MODE (xop0) != mode0 && GET_MODE (xop1) != mode1
-  && GET_MODE (xop0) == mode1 && GET_MODE (xop1) == mode1)
+  && GET_MODE (xop0) != xmode0 && GET_MODE (xop1) != xmode1
+  && GET_MODE (xop0) == xmode1 && GET_MODE (xop1) == xmode1)
 {
   swap = xop0;
   xop0 = xop1;
@@ -1265,9 +1265,9 @@ expand_binop_directly (enum machine_mode
 }
 
   /* If we are optimizing, force expensive constants into a register.  */
-  xop0 = avoid_expensive_constant (mode0, binoptab, xop0, unsignedp);
+  xop0 = avoid_expensive_constant (xmode0, binoptab, xop0, unsignedp);
   if (!shift_optab_p (binoptab))
-xop1 = avoid_expensive_constant (mode1, binoptab, xop1, unsignedp);
+xop1 = avoid_expensive_constant (xmode1, binoptab, xop1, unsignedp);
 
   /* In case the insn wants input operands in modes different from
  those of the actual operands, convert the operands.  It would
@@ -1275,19 +1275,19 @@ expand_binop_directly (enum machine_mode
  that they're properly zero-extended, sign-extended or truncated
  for their mode.  */
 
-  if (GET_MODE (xop0) != mode0 && mode0 != VOIDmode)
-xop0 = convert_modes (mode0,
- GET_MODE (xop0) != VOIDmode
- ? GET_MODE (xop0)
- : mode,
- xop0, unsignedp);
-
-  if (GET_MODE (xop1) != mode1 && mode1 != VOIDmode)
-xop1 = convert_modes (mode1,
- GET_MODE (xop1) != VOIDmode
- ? GET_MODE (xop1)
- : mode,
- xop1, unsignedp);
+  mode0 = GET_MODE (xop0) != VOIDmode ? GET_MODE (xop0) : mode;
+  if (xmode0 != VOIDmode && xmode0 != mode0)
+{
+  xop0 = convert_modes (xmode0, mode0, xop0, unsignedp);
+  mode0 = xmode0;
+}
+
+  mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
+  if (xmode1 != VOIDmode && xmode1 != mode1)
+{
+  xop1 = convert_modes (xmode1, mode1, xop1, unsignedp);
+  mode1 = xmode1;
+}
 
   /* If operation is commutative,
  try to make the first operand a register.

C++ PATCHes for c++/48296 (constexpr function returning current class)

[Jason Merrill]

In 48296, the problem was that we were checking the parameter and return 
types for literality too soon; we don't know whether the current class 
is literal until we're done defining it.  So let's be more patient about 
checking.


The second patch changes the validation errors to point at the locus of 
the function declaration in question, which improves their usefulness.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.6.
commit ff8fcc903da4c162cdc99f5f967767148fe94d34
Author: Jason Merrill 
Date:   Tue Mar 29 00:45:42 2011 -0400

PR c++/48296
* decl.c (cp_finish_decl): Defer validation of constexpr member
functions.
* class.c (finalize_literal_type_property): Validate them here.
* semantics.c (is_valid_constexpr_fn): Don't check completeness.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index adae51f..24b8a31 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -4549,6 +4549,8 @@ type_requires_array_cookie (tree type)
 static void
 finalize_literal_type_property (tree t)
 {
+  tree fn;
+
   if (cxx_dialect < cxx0x
   || TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t)
   /* FIXME These constraints seem unnecessary; remove from standard.
@@ -4559,18 +4561,10 @@ finalize_literal_type_property (tree t)
   && !TYPE_HAS_CONSTEXPR_CTOR (t))
 CLASSTYPE_LITERAL_P (t) = false;
 
-  if (!CLASSTYPE_LITERAL_P (t) && !CLASSTYPE_TEMPLATE_INSTANTIATION (t))
-{
-  tree fn;
-  for (fn = TYPE_METHODS (t); fn; fn = DECL_CHAIN (fn))
-   if (DECL_DECLARED_CONSTEXPR_P (fn)
-   && DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
-   && !DECL_CONSTRUCTOR_P (fn))
- {
-   error ("enclosing class of %q+D is not a literal type", fn);
-   DECL_DECLARED_CONSTEXPR_P (fn) = false;
- }
-}
+  for (fn = TYPE_METHODS (t); fn; fn = DECL_CHAIN (fn))
+if (DECL_DECLARED_CONSTEXPR_P (fn)
+   && TREE_CODE (fn) != TEMPLATE_DECL)
+  validate_constexpr_fundecl (fn);
 }
 
 /* Check the validity of the bases and members declared in T.  Add any
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 895527c..16ccfaf 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5794,7 +5794,10 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
}
 }
 
-  if (TREE_CODE (decl) == FUNCTION_DECL)
+  if (TREE_CODE (decl) == FUNCTION_DECL
+  /* For members, defer until finalize_literal_type_property.  */
+  && (!DECL_CLASS_SCOPE_P (decl)
+ || !TYPE_BEING_DEFINED (DECL_CONTEXT (decl
 validate_constexpr_fundecl (decl);
 
   else if (!ensure_literal_type_for_constexpr_object (decl))
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index da8c016..f1c3d9a 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5354,8 +5354,7 @@ is_valid_constexpr_fn (tree fun, bool complain)
}
 
   if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fun)
- && COMPLETE_TYPE_P (DECL_CONTEXT (fun))
- && !valid_type_in_constexpr_fundecl_p (DECL_CONTEXT (fun)))
+ && !CLASSTYPE_LITERAL_P (DECL_CONTEXT (fun)))
{
  ret = false;
  if (complain)
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-memfn1.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-memfn1.C
new file mode 100644
index 000..4646f82
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-memfn1.C
@@ -0,0 +1,18 @@
+// PR c++/48296
+// { dg-options -std=c++0x }
+
+struct X
+{
+  constexpr X() { }
+  constexpr X f(X x) { return x; }
+  constexpr X g(X x);
+};
+
+constexpr X X::g(X x) { return x; }
+
+struct Y
+{
+  Y() { }
+  constexpr Y f(Y y);  // { dg-error "constexpr" }
+  static constexpr Y g(Y y);   // { dg-error "constexpr" }
+};
commit 055a6dbed418d3ab63420309433d8d7a9ddf172c
Author: Jason Merrill 
Date:   Mon Mar 28 19:49:41 2011 -0400

* semantics.c (is_valid_constexpr_fn): Specify input location.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 6906c1b..da8c016 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5338,8 +5338,8 @@ is_valid_constexpr_fn (tree fun, bool complain)
   {
ret = false;
if (complain)
- error ("invalid type for parameter %q#D of constexpr function",
-parm);
+ error ("invalid type for parameter %d of constexpr "
+"function %q+#D", DECL_PARM_INDEX (parm), fun);
   }
 
   if (!DECL_CONSTRUCTOR_P (fun))
@@ -5349,7 +5349,7 @@ is_valid_constexpr_fn (tree fun, bool complain)
{
  ret = false;
  if (complain)
-   error ("invalid return type %qT of constexpr function %qD",
+   error ("invalid return type %qT of constexpr function %q+D",
   rettype, fun);
}
 
@@ -5359,7 +5359,7 @@ is_valid_constexpr_fn (tree fun, bool complain)
{
  ret = false;
  if (complain)
-   error ("enclosing class of %q#D is not a literal type", fun);
+   error ("enclosing class of %q+#D is not a literal type", fun);
   

[patch] Introduce -Wstack-usage

[Eric Botcazou]

Hi,

in the wake of the -fstack-usage switch that was introduced in GCC 4.6, I'm 
proposing the associated -Wstack-usage warning.  GCC already has had something 
related for quite some time:

`-Wframe-larger-than=LEN'
 Warn if the size of a function frame is larger than LEN bytes.
 The computation done to determine the stack frame size is
 approximate and not conservative.  The actual requirements may be
 somewhat greater than LEN even if you do not get a warning.  In
 addition, any space allocated via `alloca', variable-length
 arrays, or related constructs is not included by the compiler when
 determining whether or not to issue a warning.

but, as said above, the computation is approximate and doesn't take into 
account various constructs.  On the contrary, since the implementation 
of -fstack-usage was designed to be conservative, implementing -Wstack-usage 
on top of it also yields conservative results.

The warning messages are in keeping with the output of -fstack-usage.  If the 
stack usage is fully static but exceeds the specified amount, it's:

  warning: stack usage is 1120 bytes [-Wstack-usage=]

If the stack usage is (partly) dynamic but bounded, it's:

  warning: stack usage might be 1648 bytes [-Wstack-usage=]

If the stack usage is (partly) dynamic and not bounded, it's:

  warning: stack usage might be unbounded [-Wstack-usage=]

Tested on i586-suse-linux, OK for the mainline?


2011-03-29  Eric Botcazou  

* common.opt (flag_stack_usage_info): New variable.
(-Wstack-usage): New option.
* doc/invoke.texi (Warning options): Document -Wstack-usage.
* opts.c (common_handle_option) : New case.
: Likewise.
* toplev.c (output_stack_usage): Deal with -Wstack-usage.
* calls.c (expand_call): Test flag_stack_usage_info variable instead
of flag_stack_usage.
(emit_library_call_value_1): Likewise.
* explow.c (allocate_dynamic_stack_space): Likewise.
* function.c (instantiate_virtual_regs ): Likewise.
(prepare_function_start): Likewise.
(rest_of_handle_thread_prologue_and_epilogue): Likewise.
* config/alpha/alpha.c (alpha_expand_prologue): Likewise.
* config/arm/arm.c (arm_expand_prologue): Likewise.
(thumb1_expand_prologue): Likewise.
* config/avr/avr.c (expand_prologue): Likewise.
* config/i386/i386.c (ix86_expand_prologue): Likewise.
* config/ia64/ia64.c (ia64_expand_prologue): Likewise.
* config/mips/mips.c (mips_expand_prologue): Likewise.
* config/pa/pa.c (hppa_expand_prologue): Likewise.
* config/rs6000/rs6000.c (rs6000_emit_prologue): Likewise.
* config/s390/s390.c (s390_emit_prologue): Likewise.
* config/sh/sh.c (sh_expand_prologue): Likewise.
* config/sparc/sparc.c (sparc_expand_prologue): Likewise.
* config/spu/spu.c (spu_expand_prologue): Likewise.


2011-03-29  Eric Botcazou  

* gcc.dg/stack-usage-2.c: New test.


-- 
Eric Botcazou
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 171572)
+++ doc/invoke.texi	(working copy)
@@ -260,7 +260,7 @@ Objective-C and Objective-C++ Dialects}.
 -Wredundant-decls @gol
 -Wreturn-type  -Wsequence-point  -Wshadow @gol
 -Wsign-compare  -Wsign-conversion  -Wstack-protector @gol
--Wstrict-aliasing -Wstrict-aliasing=n @gol
+-Wstack-usage=@var{len} -Wstrict-aliasing -Wstrict-aliasing=n @gol
 -Wstrict-overflow -Wstrict-overflow=@var{n} @gol
 -Wsuggest-attribute=@r{[}pure@r{|}const@r{|}noreturn@r{]} @gol
 -Wswitch  -Wswitch-default  -Wswitch-enum -Wsync-nand @gol
@@ -3922,6 +3922,14 @@ via @code{alloca}, variable-length array
 is not included by the compiler when determining
 whether or not to issue a warning.
 
+@item -Wstack-usage=@var{len}
+@opindex Wstack-usage
+Warn if the stack usage of a function might be larger than @var{len} bytes.
+The computation done to determine the stack usage is conservative.
+Any space allocated via @code{alloca}, variable-length arrays, or related
+constructs is included by the compiler when determining whether or not to
+issue a warning.
+
 @item -Wunsafe-loop-optimizations
 @opindex Wunsafe-loop-optimizations
 @opindex Wno-unsafe-loop-optimizations
Index: toplev.c
===
--- toplev.c	(revision 171572)
+++ toplev.c	(working copy)
@@ -1048,14 +1048,12 @@ output_stack_usage (void)
   };
   HOST_WIDE_INT stack_usage = current_function_static_stack_size;
   enum stack_usage_kind_type stack_usage_kind;
-  expanded_location loc;
-  const char *raw_id, *id;
 
   if (stack_usage < 0)
 {
   if (!warning_issued)
 	{
-	  warning (0, "-fstack-usage not supported for this target");
+	  warning (0, "stack usage computation not supported for this target");
 	  warning_issued = true;
 	}
   return;
@@ -1082,24 +1080,44 @@ output_stack_usage (void)
   stack_u

Re: Cleaning up expand optabs code

[Mikael Pettersson]

Richard Sandiford writes:
 > Mikael Pettersson  writes:
 > > Richard Sandiford writes:
 > >  > Andreas Krebbel  writes:
 > >  > > On 03/22/2011 06:48 PM, Richard Henderson wrote:
 > >  > >
 > >  > >> Ok.  Watch out for other target problems this week.
 > >  > >
 > >  > > This unfortunately broke bootstrap on s390.
 > >  > 
 > >  > This is PR 48263.  Since it seems to be affecting several targets,
 > >  > and since my bootstrap seems to be taking a looong time, I'll post
 > >  > the patch here before testing has finished.
 > >  > 
 > >  > > Just copying the pre-patch behaviour fixes the problem for me:
 > >  > 
 > >  > I think we need to undo more of the patch, and leave the conversion
 > >  > outside of the new interface.
 > >  > 
 > >  > Sorry for the breakage.
 > >  > 
 > >  > Richard
 > >  > 
 > >  > 
 > >  > gcc/
 > >  > PR rtl-optimization/48263
 > >  > * optabs.c (expand_binop_directly): Reinstate convert_modes code
 > >  > and original commutative_p handling.  Use maybe_gen_insn.
 > >
 > > Unfortunately this fix (r171418) broke m68k-linux, see
 > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48332
 > 
 > Please try the attached
 > 
 > Richard
 > 
 > 
 > gcc/
 >  PR rtl-optimization/48332
 >  * optabs.c (expand_binop_directly): Set xmodeN to the target-mandated
 >  mode of input operand N and modeN to its actual mode.

Thanks, this allowed me to build gcc-4.7 as a cross to m68k-linux again.

I'm starting a native bootstrap of gcc-4.7 head + this fix on m68k, but
that will take about 5 days to complete...

/Mikael

 > 
 > Index: gcc/optabs.c
 > ===
 > --- gcc/optabs.c 2011-03-24 17:23:05.0 +
 > +++ gcc/optabs.c 2011-03-29 14:18:02.0 +0100
 > @@ -1243,9 +1243,9 @@ expand_binop_directly (enum machine_mode
 > rtx last)
 >  {
 >enum insn_code icode = optab_handler (binoptab, mode);
 > -  enum machine_mode mode0 = insn_data[(int) icode].operand[1].mode;
 > -  enum machine_mode mode1 = insn_data[(int) icode].operand[2].mode;
 > -  enum machine_mode tmp_mode;
 > +  enum machine_mode xmode0 = insn_data[(int) icode].operand[1].mode;
 > +  enum machine_mode xmode1 = insn_data[(int) icode].operand[2].mode;
 > +  enum machine_mode mode0, mode1, tmp_mode;
 >struct expand_operand ops[3];
 >bool commutative_p;
 >rtx pat;
 > @@ -1256,8 +1256,8 @@ expand_binop_directly (enum machine_mode
 >   if we would swap the operands, we can save the conversions.  */
 >commutative_p = commutative_optab_p (binoptab);
 >if (commutative_p
 > -  && GET_MODE (xop0) != mode0 && GET_MODE (xop1) != mode1
 > -  && GET_MODE (xop0) == mode1 && GET_MODE (xop1) == mode1)
 > +  && GET_MODE (xop0) != xmode0 && GET_MODE (xop1) != xmode1
 > +  && GET_MODE (xop0) == xmode1 && GET_MODE (xop1) == xmode1)
 >  {
 >swap = xop0;
 >xop0 = xop1;
 > @@ -1265,9 +1265,9 @@ expand_binop_directly (enum machine_mode
 >  }
 >  
 >/* If we are optimizing, force expensive constants into a register.  */
 > -  xop0 = avoid_expensive_constant (mode0, binoptab, xop0, unsignedp);
 > +  xop0 = avoid_expensive_constant (xmode0, binoptab, xop0, unsignedp);
 >if (!shift_optab_p (binoptab))
 > -xop1 = avoid_expensive_constant (mode1, binoptab, xop1, unsignedp);
 > +xop1 = avoid_expensive_constant (xmode1, binoptab, xop1, unsignedp);
 >  
 >/* In case the insn wants input operands in modes different from
 >   those of the actual operands, convert the operands.  It would
 > @@ -1275,19 +1275,19 @@ expand_binop_directly (enum machine_mode
 >   that they're properly zero-extended, sign-extended or truncated
 >   for their mode.  */
 >  
 > -  if (GET_MODE (xop0) != mode0 && mode0 != VOIDmode)
 > -xop0 = convert_modes (mode0,
 > -  GET_MODE (xop0) != VOIDmode
 > -  ? GET_MODE (xop0)
 > -  : mode,
 > -  xop0, unsignedp);
 > -
 > -  if (GET_MODE (xop1) != mode1 && mode1 != VOIDmode)
 > -xop1 = convert_modes (mode1,
 > -  GET_MODE (xop1) != VOIDmode
 > -  ? GET_MODE (xop1)
 > -  : mode,
 > -  xop1, unsignedp);
 > +  mode0 = GET_MODE (xop0) != VOIDmode ? GET_MODE (xop0) : mode;
 > +  if (xmode0 != VOIDmode && xmode0 != mode0)
 > +{
 > +  xop0 = convert_modes (xmode0, mode0, xop0, unsignedp);
 > +  mode0 = xmode0;
 > +}
 > +
 > +  mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
 > +  if (xmode1 != VOIDmode && xmode1 != mode1)
 > +{
 > +  xop1 = convert_modes (xmode1, mode1, xop1, unsignedp);
 > +  mode1 = xmode1;
 > +}
 >  
 >/* If operation is commutative,
 >   try to make the first operand a register.
 > 

Re: [patch, ARM] Fix PR48250, adjust DImode reload address legitimizing

[Richard Earnshaw]

On Tue, 2011-03-29 at 18:25 +0800, Chung-Lin Tang wrote:
> On 2011/3/24 06:51 PM, Richard Earnshaw wrote:
> > 
> > On Thu, 2011-03-24 at 12:56 +0900, Chung-Lin Tang wrote:
> >> Hi,
> >> PR48250 happens under TARGET_NEON, where DImode is included within the
> >> valid NEON modes. This turns the range of legitimate constant indexes to
> >> step-4 (coproc load/store), thus arm_legitimize_reload_address() when
> >> trying to decompose the [reg+index] reload address into
> >> [(reg+index_high)+index_low], can cause an ICE later when 'index_low'
> >> part is not aligned to 4.
> >>
> >> I'm not sure why the current DImode index is computed as:
> >> low = ((val & 0xf) ^ 0x8) - 0x8;  the sign-extending into negative
> >> values, then subtracting back, actually creates further off indexes.
> >> e.g. in the supplied testcase, [sp+13] was turned into [(sp+16)-3].
> >>
> > 
> > Hysterical Raisins... the code there was clearly written for the days
> > before we had LDRD in the architecture.  At that time the most efficient
> > way to load a 64-bit object was to use the LDM{ia,ib,da,db}
> > instructions.  The computation here was (I think), intended to try and
> > make the most efficient use of an add/sub instruction followed by
> > LDM/STM offsetting.  At that time the architecture had no unaligned
> > access either, so dealing with 64-bit that were less than 32-bit aligned
> > (in those days 32-bit was the maximum alignment) probably wasn't
> > considered, or couldn't even get through to reload.
> >
> 
> I see it now. The code in output_move_double() returning assembly for
> ldm/stm(db/da/ib) for offsets -8/-4/+4 seems to confirm this.
> 
> I have changed the patch to let the new code handle the TARGET_LDRD case
> only.  The pre-LDRD case is still handled by the original code, with an
> additional & ~0x3 for aligning the offset to 4.
> 
> I've also added a comment for the pre-TARGET_LDRD case. Please see if
> the description is accurate enough.
> 
> >> My patch changes the index decomposing to a more straightforward way; it
> >> also sort of outlines the way the other reload address indexes are
> >> broken by using and-masks, is not the most effective.  The address is
> >> computed by addition, subtracting away the parts to obtain low+high
> >> should be the optimal way of giving the largest computable index range.
> >>
> >> I have included a few Thumb-2 bits in the patch; I know currently
> >> arm_legitimize_reload_address() is only used under TARGET_ARM, but I
> >> guess it might eventually be turned into TARGET_32BIT.
> >>
> > 
> > I think this needs to be looked at carefully on ARMv4/ARMv4T to check
> > that it doesn't cause regressions there when we don't have LDRD in the
> > instruction set.
> 
> I'll be testing the modified patch under an ARMv4/ARMv4T configuration.
> Okay for trunk if no regressions?
> 
> Thanks,
> Chung-Lin
> 
>   PR target/48250
>   * config/arm/arm.c (arm_legitimize_reload_address): Adjust
>   DImode constant index decomposing under TARGET_LDRD. Clear
>   lower two bits for NEON, Thumb-2, and !TARGET_LDRD. Add
>   comment for !TARGET_LDRD case.

This looks technically correct, but I can't help feeling that trying to
deal with the bottom two bits being non-zero is not really worthwhile.
This hook is an optimization that's intended to generate better code
than the default mechanisms that reload provides.  It is allowed to
fail, but it must say so if it does (by returning false).

What this hook is trying to do for DImode is to take an address of the
form (reg + TOO_BIG_CONST) and turn it into two instructions that are
legitimate:

tmp = (REG + LEGAL_BIG_CONST)
some_use_of (mem (tmp + SMALL_LEGAL_CONST))

The idea behind the optimization is that LEGAL_BIG_CONST will need fewer
instructions to generate than TOO_BIG_CONST.  It's unlikely (probably
impossible in ARM state) that pushing the bottom two bits of the address
into LEGAL_BIG_CONST part of the offset is going to lead to a better
code sequence.  

So I think it would be more sensible to just return false if we have a
DImode address with the bottom 2 bits non-zero and then let the normal
reload recovery mechanism take over.

Re: PING^3: PR 47551: ARM patch for Neon-related spill failure

[Nick Clifton]

Hi Richard,


Third ping for this ARM-specific reload fix:

 http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02266.html




Tested on arm-linux-gnueabi (-marm and -mthumb).  I don't think this
is a regression, so: OK to install once 4.7 is open?


Yes.


gcc/
PR target/47551
* config/arm/arm.c (coproc_secondary_reload_class): Handle
structure modes.  Don't check neon_vector_mem_operand for
vector or structure modes.

gcc/testsuite/
PR target/47551
* gcc.target/arm/neon-modes-2.c: New test.


Approved - please apply.

Cheers
  Nick

Some remodelling of the ARM vld and vst patterns

[Richard Sandiford]

The patterns for the Neon vld and vst intrinsics use the following sort
of construct to refer to memory:

(mem:FOO (match_operand:SI X "register_operand" "r"))

This patch changes them to use:

(match_operand:FOO' X "neon_struct_operand" "(=)Um")

instead.  This has some performance benefits:

- It allows the loads to use post-increment addresses as well
  as bare registers.

- If:

  /* FIXME: vld1 allows register post-modify.  */

  were fixed, it would allow register post-modify addresses too.

- It allows alignment hints to be generated.

It also more closely matches the form that future autovectorisation
optabs would have.

There are a couple of correctness fixes too:

- The old v{ld,st}{3,4}q patterns generated two individual instructions,
  each post-incrementing the address.  The problem is the expander passed
  the original register input operand to both patterns, instead of passing
  a temporary register.  We could therefore end up post-incrementing a live
  register variable.  E.g. for:

void __attribute__((noinline))
foo (uint32_t *a)
{
  uint32x4x3_t x;

  x = vld3q_u32 (a);
  x.val[0] = vaddq_u32 (x.val[0], x.val[1]);
  vst3q_u32 (a, x);
}

  the vld3q_u32 moves "a" forward 12 elements, so the vst3q_u32 stores
  to the wrong address.

  After the above change, we don't need to encode the post-increment
  directly.  We can just leave the auto-inc-dec pass to figure out
  a good sequence (which it does seem to do in practice).

  [tested by neon-vld3-1.c]

- At the moment, we use this mode attribute to set the modes of
  three-element loads and stores:

;; Similar, for three elements.
;; ??? Should we define extra modes so that sizes of all three-element
;; accesses can be accurately represented?
(define_mode_attr V_three_elem [(V8QI "SI")   (V16QI "SI")
(V4HI "V4HI") (V8HI "V4HI")
(V2SI "V4SI") (V4SI "V4SI")
(V2SF "V4SF") (V4SF "V4SF")
(DI "EI") (V2DI "EI")])

  The ??? is saying that the V8QI-derived MEM is really a 3-byte access,
  not a 4-byte (SI) access, and so on.  The comment makes the mode sound
  like a representational niceity, but really, there's no such thing as
  a "conservatively wrong" memory size here.  If a store's mode is too
  small, dependent loads could be deleted as dead.  If it's too big,
  unrelated live loads could be deleted as dead.

  The approach taken in the patch means that we can use BLKmode here,
  and rely on MEM_SIZE to specify the size of the access.

  One problem with using BLKmode is that it stops pre- and
  post-modifications being used.  Seeing as that wasn't possible
  before the patch either, I'd like to leave it as future work.

  [tested by neon-vst3-1.c]

At the moment, it isn't safe to use the natural alias set, because
arm_neon.h uses the same built-in function for both signed and
unsigned operations.  If this patch is OK, we could in principle
go further and add separate signed and unsigned built-in functions.
It all depends on whether uses of the API implemented by arm_neon.h
are expected to be alias-safe or not.

The patch applies on top of:

  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01634.html

(unreviewed).

Tested on arm-linux-gnueabi.  OK to install?

Richard


gcc/
* config/arm/arm.c (arm_print_operand): Use MEM_SIZE to get the
size of a '%A' memory reference.
(T_DREG, T_QREG): New neon_builtin_type_bits.
(arm_init_neon_builtins): Assert that the load and store operands
are neon_struct_operands.
(locate_neon_builtin_icode): Provide the neon_builtin_type_bits.
(NEON_ARG_MEMORY): New builtin_arg.
(neon_dereference_pointer): New function.
(arm_expand_neon_args): Add a neon_builtin_type_bits argument.
Handle NEON_ARG_MEMORY.
(arm_expand_neon_builtin): Update after above interface changes.
Use NEON_ARG_MEMORY for loads and stores.
* config/arm/predicates.md (neon_struct_operand): New predicate.
* config/arm/iterators.md (V_two_elem): Tweak formatting.
(V_three_elem): Use BLKmode for accesses that have no associated mode.
(V_four_elem): Tweak formatting.
* config/arm/neon.md (neon_vld1, neon_vld1_dup)
(neon_vst1_lane, neon_vst1, neon_vld2)
(neon_vld2_lane, neon_vld2_dup, neon_vst2)
(neon_vst2_lane, neon_vld3, neon_vld3_lane)
(neon_vld3_dup, neon_vst3, neon_vst3_lane)
(neon_vld4, neon_vld4_lane, neon_vld4_dup)
(neon_vst4): Replace pointer operand with a memory operand.
Use %A in the output template.
(neon_vld3qa, neon_vld3qb, neon_vst3qa)
(neon_vst3qb, neon_vld4qa, neon_vld4qb)
(neon_vst4qa, neon_vst4qb): Likewise, but halve
the width of the memory access.  Remove post-increment.
* config/arm/neon-testgen.ml: Allow addresses

[ARM] Define unspecs using define_c_enum

[Richard Sandiford]

This ARM patch allows *UNSPEC_* constants to be printed in dump files.
It's very much a target decision whether this is worth doing, but just
in case...

...tested on arm-linux-gnueabi.  OK to install?

Richard


gcc/
* config/arm/neon.md: Use define_c_enum to define UNSPEC* and
VUNSPEC* constants.
* config/arm/arm.md: Likewise.  Move the synchronization ones to...
* config/arm/sync.md: ...here.

Index: gcc/config/arm/neon.md
===
--- gcc/config/arm/neon.md  2011-03-29 09:46:11.0 +0100
+++ gcc/config/arm/neon.md  2011-03-29 09:57:52.0 +0100
@@ -19,131 +19,131 @@
 ;; .
 
 ;; Constants for unspecs.
-(define_constants
-  [(UNSPEC_ASHIFT_SIGNED   65)
-   (UNSPEC_ASHIFT_UNSIGNED 66)
-   (UNSPEC_VABD69)
-   (UNSPEC_VABDL   70)
-   (UNSPEC_VADD72)
-   (UNSPEC_VADDHN  73)
-   (UNSPEC_VADDL   74)
-   (UNSPEC_VADDW   75)
-   (UNSPEC_VBSL78)
-   (UNSPEC_VCAGE   79)
-   (UNSPEC_VCAGT   80)
-   (UNSPEC_VCEQ81)
-   (UNSPEC_VCGE82)
-   (UNSPEC_VCGT83)
-   (UNSPEC_VCLS84)
-   (UNSPEC_VCVT88)
-   (UNSPEC_VCVT_N  89)
-   (UNSPEC_VEXT93)
-   (UNSPEC_VHADD   97)
-   (UNSPEC_VHSUB   98)
-   (UNSPEC_VLD199)
-   (UNSPEC_VLD1_DUP100)
-   (UNSPEC_VLD1_LANE   101)
-   (UNSPEC_VLD2102)
-   (UNSPEC_VLD2_DUP103)
-   (UNSPEC_VLD2_LANE   104)
-   (UNSPEC_VLD3105)
-   (UNSPEC_VLD3A   106)
-   (UNSPEC_VLD3B   107)
-   (UNSPEC_VLD3_DUP108)
-   (UNSPEC_VLD3_LANE   109)
-   (UNSPEC_VLD4110)
-   (UNSPEC_VLD4A   111)
-   (UNSPEC_VLD4B   112)
-   (UNSPEC_VLD4_DUP113)
-   (UNSPEC_VLD4_LANE   114)
-   (UNSPEC_VMAX115)
-   (UNSPEC_VMIN116)
-   (UNSPEC_VMLA117)
-   (UNSPEC_VMLAL   118)
-   (UNSPEC_VMLA_LANE   119)
-   (UNSPEC_VMLAL_LANE  120)
-   (UNSPEC_VMLS121)
-   (UNSPEC_VMLSL   122)
-   (UNSPEC_VMLS_LANE   123)
-   (UNSPEC_VMLSL_LANE  124)
-   (UNSPEC_VMOVL   125)
-   (UNSPEC_VMOVN   126)
-   (UNSPEC_VMUL127)
-   (UNSPEC_VMULL   128)
-   (UNSPEC_VMUL_LANE   129)
-   (UNSPEC_VMULL_LANE  130)
-   (UNSPEC_VPADAL  135)
-   (UNSPEC_VPADD   136)
-   (UNSPEC_VPADDL  137)
-   (UNSPEC_VPMAX   138)
-   (UNSPEC_VPMIN   139)
-   (UNSPEC_VPSMAX  140)
-   (UNSPEC_VPSMIN  141)
-   (UNSPEC_VPUMAX  142)
-   (UNSPEC_VPUMIN  143)
-   (UNSPEC_VQABS   144)
-   (UNSPEC_VQADD   145)
-   (UNSPEC_VQDMLAL 146)
-   (UNSPEC_VQDMLAL_LANE147)
-   (UNSPEC_VQDMLSL 148)
-   (UNSPEC_VQDMLSL_LANE149)
-   (UNSPEC_VQDMULH 150)
-   (UNSPEC_VQDMULH_LANE151)
-   (UNSPEC_VQDMULL 152)
-   (UNSPEC_VQDMULL_LANE153)
-   (UNSPEC_VQMOVN  154)
-   (UNSPEC_VQMOVUN 155)
-   (UNSPEC_VQNEG   156)
-   (UNSPEC_VQSHL   157)
-   (UNSPEC_VQSHL_N 158)
-   (UNSPEC_VQSHLU_N159)
-   (UNSPEC_VQSHRN_N160)
-   (UNSPEC_VQSHRUN_N   161)
-   (UNSPEC_VQSUB   162)
-   (UNSPEC_VRECPE  163)
-   (UNSPEC_VRECPS  164)
-   (UNSPEC_VREV16  165)
-   (UNSPEC_VREV32  166)
-   (UNSPEC_VREV64  167)
-   (UNSPEC_VRSQRTE 168)
-   (UNSPEC_VRSQRTS 169)
-   (UNSPEC_VSHL171)
-   (UNSPEC_VSHLL_N 172)
-   (UNSPEC_VSHL_N  173)
-   (UNSPEC_VSHR_N  174)
-   (UNSPEC_VSHRN_N 175)
-   (UNSPEC_VSLI176)
-   (UNSPEC_VSRA_N  177)
-   (UNSPEC_VSRI178)
-   (UNSPEC_VST1179)
-   (UNSPEC_VST1_LANE   180)
-   (UNSPEC_VST2181)
-   (UNSPEC_VST2_LANE   182)
-   (UNSPEC_VST3183)
-   (UNSPEC_VST3A   184)
-   (UNSPEC_VST3B   185)
-   (UNSPEC_VST3_LANE   186)
-   (UNSPEC_VST4187)
-   (UNSPEC_VST4A   188)
-   (UNSPEC_VST4B   189)
-   (UNSPEC_VST4_LANE   190)
-   (UNSPEC_VSTRUCTDUMMY191)
-   (UNSPEC_

Re: [patch, ARM] Fix PR48250, adjust DImode reload address legitimizing

[Chung-Lin Tang]

On 2011/3/29 下午 10:26, Richard Earnshaw wrote:
> On Tue, 2011-03-29 at 18:25 +0800, Chung-Lin Tang wrote:
>> On 2011/3/24 06:51 PM, Richard Earnshaw wrote:
>>>
>>> On Thu, 2011-03-24 at 12:56 +0900, Chung-Lin Tang wrote:
 Hi,
 PR48250 happens under TARGET_NEON, where DImode is included within the
 valid NEON modes. This turns the range of legitimate constant indexes to
 step-4 (coproc load/store), thus arm_legitimize_reload_address() when
 trying to decompose the [reg+index] reload address into
 [(reg+index_high)+index_low], can cause an ICE later when 'index_low'
 part is not aligned to 4.

 I'm not sure why the current DImode index is computed as:
 low = ((val & 0xf) ^ 0x8) - 0x8;  the sign-extending into negative
 values, then subtracting back, actually creates further off indexes.
 e.g. in the supplied testcase, [sp+13] was turned into [(sp+16)-3].

>>>
>>> Hysterical Raisins... the code there was clearly written for the days
>>> before we had LDRD in the architecture.  At that time the most efficient
>>> way to load a 64-bit object was to use the LDM{ia,ib,da,db}
>>> instructions.  The computation here was (I think), intended to try and
>>> make the most efficient use of an add/sub instruction followed by
>>> LDM/STM offsetting.  At that time the architecture had no unaligned
>>> access either, so dealing with 64-bit that were less than 32-bit aligned
>>> (in those days 32-bit was the maximum alignment) probably wasn't
>>> considered, or couldn't even get through to reload.
>>>
>>
>> I see it now. The code in output_move_double() returning assembly for
>> ldm/stm(db/da/ib) for offsets -8/-4/+4 seems to confirm this.
>>
>> I have changed the patch to let the new code handle the TARGET_LDRD case
>> only.  The pre-LDRD case is still handled by the original code, with an
>> additional & ~0x3 for aligning the offset to 4.
>>
>> I've also added a comment for the pre-TARGET_LDRD case. Please see if
>> the description is accurate enough.
>>
 My patch changes the index decomposing to a more straightforward way; it
 also sort of outlines the way the other reload address indexes are
 broken by using and-masks, is not the most effective.  The address is
 computed by addition, subtracting away the parts to obtain low+high
 should be the optimal way of giving the largest computable index range.

 I have included a few Thumb-2 bits in the patch; I know currently
 arm_legitimize_reload_address() is only used under TARGET_ARM, but I
 guess it might eventually be turned into TARGET_32BIT.

>>>
>>> I think this needs to be looked at carefully on ARMv4/ARMv4T to check
>>> that it doesn't cause regressions there when we don't have LDRD in the
>>> instruction set.
>>
>> I'll be testing the modified patch under an ARMv4/ARMv4T configuration.
>> Okay for trunk if no regressions?
>>
>> Thanks,
>> Chung-Lin
>>
>>  PR target/48250
>>  * config/arm/arm.c (arm_legitimize_reload_address): Adjust
>>  DImode constant index decomposing under TARGET_LDRD. Clear
>>  lower two bits for NEON, Thumb-2, and !TARGET_LDRD. Add
>>  comment for !TARGET_LDRD case.
> 
> This looks technically correct, but I can't help feeling that trying to
> deal with the bottom two bits being non-zero is not really worthwhile.
> This hook is an optimization that's intended to generate better code
> than the default mechanisms that reload provides.  It is allowed to
> fail, but it must say so if it does (by returning false).
> 
> What this hook is trying to do for DImode is to take an address of the
> form (reg + TOO_BIG_CONST) and turn it into two instructions that are
> legitimate:
> 
>   tmp = (REG + LEGAL_BIG_CONST)
>   some_use_of (mem (tmp + SMALL_LEGAL_CONST))
> 
> The idea behind the optimization is that LEGAL_BIG_CONST will need fewer
> instructions to generate than TOO_BIG_CONST.  It's unlikely (probably
> impossible in ARM state) that pushing the bottom two bits of the address
> into LEGAL_BIG_CONST part of the offset is going to lead to a better
> code sequence.  
> 
> So I think it would be more sensible to just return false if we have a
> DImode address with the bottom 2 bits non-zero and then let the normal
> reload recovery mechanism take over.

It is supposed to provide better utilization of the full range of
LEGAL_BIG_CONST+SMALL_LEGAL_CONST.  I am not sure, but I guess reload
will resolve it with the reg+LEGAL_BIG_CONST part only, using only (mem
(reg)) for the load/store (correct me if I'm wrong).

Also, the new code slighty improves the reloading, for example currently
[reg+64] is broken into [(reg+72)-8], creating an additional unneeded
reload, which is certainly not good when we have ldrd/strd available.

Thanks,
Chung-Lin

Restore SPARC bootstrap (PR bootstrap/48337)

[Rainer Orth]

As described in the PR, SPARC bootstrap is currently broken.  This
patch, derived from Joseph's hint, fixes this.

I'm now into stage 3 on sparc-sun-solaris2.11, ok for mainline once that
is completed?  I don't expect problems for the target libraries and would
like to restore bootstrap ASAP.

Thanks.
Rainer


2011-03-29  Joseph Myers  
Rainer Orth  

PR bootstrap/48337
* config/sparc/sparc.opt (sparc_cpu_and_features): Add
Init(PROCESSOR_V7).
(sparc_cpu): Likewise.
* config/sparc/sparc.c (sparc_option_override): Replace 0 by
PROCESSOR_V7.

diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -695,7 +695,7 @@ sparc_option_override (void)
 { TARGET_CPU_ultrasparc3, PROCESSOR_ULTRASPARC3 },
 { TARGET_CPU_niagara, PROCESSOR_NIAGARA },
 { TARGET_CPU_niagara2, PROCESSOR_NIAGARA2 },
-{ -1, 0 }
+{ -1, PROCESSOR_V7 }
   };
   const struct cpu_default *def;
   /* Table of values for -m{cpu,tune}=.  This must match the order of
diff --git a/gcc/config/sparc/sparc.opt b/gcc/config/sparc/sparc.opt
--- a/gcc/config/sparc/sparc.opt
+++ b/gcc/config/sparc/sparc.opt
@@ -86,11 +86,11 @@ Target
 Optimize tail call instructions in assembler and linker
 
 mcpu=
-Target RejectNegative Joined Var(sparc_cpu_and_features) 
Enum(sparc_processor_type)
+Target RejectNegative Joined Var(sparc_cpu_and_features) 
Enum(sparc_processor_type) Init(PROCESSOR_V7)
 Use features of and schedule code for given CPU
 
 mtune=
-Target RejectNegative Joined Var(sparc_cpu) Enum(sparc_processor_type)
+Target RejectNegative Joined Var(sparc_cpu) Enum(sparc_processor_type) 
Init(PROCESSOR_V7)
 Schedule code for given CPU
 
 Enum

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

Re: [C++0x] Range-based for statements and ADL

[Gabriel Dos Reis]

On Tue, Mar 29, 2011 at 4:38 AM, Rodrigo Rivas
 wrote:
> On Tue, Mar 29, 2011 at 10:12 AM, Jonathan Wakely  
> wrote:
>> Should we consistently refer to % so the keyword is highlighted?
> Now that you say... I've not been quite consistent. We could say
> "range-based %", with only a dash between 'range' and 'based'.
>

or "new-style for loop"?

[Patch] Bfin: Ensure rotrsi and rotlsi don't accept non-const INTVALS

[Henderson, Stuart]

The attached patch ensures rotrsi and rotlsi don't accept non-const INTVALS.


2011-03-29  Stuart Henderson  

From Bernd Schmidt
* config/bfin/bfin.md (rotrsi, rotlsi): Don't take INTVAL of anything
that's not CONST_INT.



Thanks,
Stu


upstream.patch
Description: upstream.patch

[PATCH] Another EQ/NE folder type fix (PR c/48305)

[Jakub Jelinek]

Hi!

I've left these 4 out because I thought they should be fine given
that the other operands are equal.  But the testcase shows I was wrong.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?

2011-03-29  Jakub Jelinek  

PR c/48305
* fold-const.c (fold_binary_loc) : Make sure
arg10/arg11 in (X ^ Y) == (Z ^ W) are always fold converted to
matching arg00/arg01 types.

* gcc.c-torture/compile/pr48305.c: New test.

--- gcc/fold-const.c.jj 2011-03-25 07:56:32.0 +0100
+++ gcc/fold-const.c2011-03-28 12:45:58.0 +0200
@@ -12625,13 +12625,21 @@ fold_binary_loc (location_t loc,
 operand_equal_p guarantees no side-effects so we don't need
 to use omit_one_operand on Z.  */
  if (operand_equal_p (arg01, arg11, 0))
-   return fold_build2_loc (loc, code, type, arg00, arg10);
+   return fold_build2_loc (loc, code, type, arg00,
+   fold_convert_loc (loc, TREE_TYPE (arg00),
+ arg10));
  if (operand_equal_p (arg01, arg10, 0))
-   return fold_build2_loc (loc, code, type, arg00, arg11);
+   return fold_build2_loc (loc, code, type, arg00,
+   fold_convert_loc (loc, TREE_TYPE (arg00),
+ arg11));
  if (operand_equal_p (arg00, arg11, 0))
-   return fold_build2_loc (loc, code, type, arg01, arg10);
+   return fold_build2_loc (loc, code, type, arg01,
+   fold_convert_loc (loc, TREE_TYPE (arg01),
+ arg10));
  if (operand_equal_p (arg00, arg10, 0))
-   return fold_build2_loc (loc, code, type, arg01, arg11);
+   return fold_build2_loc (loc, code, type, arg01,
+   fold_convert_loc (loc, TREE_TYPE (arg01),
+ arg11));
 
  /* Optimize (X ^ C1) op (Y ^ C2) as (X ^ (C1 ^ C2)) op Y.  */
  if (TREE_CODE (arg01) == INTEGER_CST
--- gcc/testsuite/gcc.c-torture/compile/pr48305.c.jj2011-03-28 
12:48:02.0 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr48305.c   2011-03-28 
12:47:49.0 +0200
@@ -0,0 +1,7 @@
+/* PR c/48305 */
+
+int
+foo (int x)
+{
+  return (x ^ 1) == (x ^ 1U);
+}

Jakub

[PATCH] -E/-save-temps locus fix (PR preprocessor/48248)

[Jakub Jelinek]

Hi!

My PR41445 fix apparently sometimes results in wrong locus.
The problem is if we switch temporarily to a locus of some token
from a header file (PR41445 was fixing a problem where -save-temps
behaved differently then normal compilation as locuses were different)
and the line in the header file is within 8 lines of the line in the
current source file, maybe_print_line optimizes and will emit
newlines instead of emitting # X "file"... line.
The optimization should be done only if it is the same file though.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.6?

2011-03-29  Jakub Jelinek  

PR preprocessor/48248
* c-ppoutput.c (print): Add src_file field.
(init_pp_output): Initialize it.
(maybe_print_line): Don't optimize by adding up to 8 newlines
if map->to_file and print.src_file are different file.
(print_line): Update print.src_file.

--- gcc/c-family/c-ppoutput.c.jj2011-01-06 10:21:28.0 +0100
+++ gcc/c-family/c-ppoutput.c   2011-03-28 20:36:29.0 +0200
@@ -36,6 +36,7 @@ static struct
   int src_line;/* Line number currently being written. 
 */
   unsigned char printed;   /* Nonzero if something output at line.  */
   bool first_time; /* pp_file_change hasn't been called yet.  */
+  const char *src_file;/* Current source file.  */
 } print;
 
 /* Defined and undefined macros being queued for output with -dU at
@@ -153,6 +154,7 @@ init_pp_output (FILE *out_stream)
   print.prev = 0;
   print.outf = out_stream;
   print.first_time = 1;
+  print.src_file = "";
 }
 
 /* Writes out the preprocessed file, handling spacing and paste
@@ -312,7 +314,9 @@ maybe_print_line (source_location src_lo
   print.printed = 0;
 }
 
-  if (src_line >= print.src_line && src_line < print.src_line + 8)
+  if (src_line >= print.src_line
+  && src_line < print.src_line + 8
+  && strcmp (map->to_file, print.src_file) == 0)
 {
   while (src_line > print.src_line)
{
@@ -344,6 +348,7 @@ print_line (source_location src_loc, con
   unsigned char *p;
 
   print.src_line = SOURCE_LINE (map, src_loc);
+  print.src_file = map->to_file;
 
   /* cpp_quote_string does not nul-terminate, so we have to do it
 ourselves.  */

Jakub

Re: [PATCH, alpha]: Fix ICE in mems_in_disjoint_alias_sets_p

[Richard Henderson]

On 03/29/2011 04:26 AM, Uros Bizjak wrote:
> 2011-03-29  Uros Bizjak  
> 
>   * config/alpha/alpha.c (alpha_sr_alias_set): Don't define.
>   (alpha_option_override): Don't set alpha_sr_alias_set.
>   (emit_frame_store_1): Use gen_frame_mem rather than calling
>   set_mem_alias_set.
>   (alpha_expand_epilogue): Ditto.

Ok.


r~

Re: [patch, ARM] Fix PR48250, adjust DImode reload address legitimizing

[Richard Earnshaw]

On Tue, 2011-03-29 at 22:53 +0800, Chung-Lin Tang wrote:
> On 2011/3/29 下午 10:26, Richard Earnshaw wrote:
> > On Tue, 2011-03-29 at 18:25 +0800, Chung-Lin Tang wrote:
> >> On 2011/3/24 06:51 PM, Richard Earnshaw wrote:
> >>>
> >>> On Thu, 2011-03-24 at 12:56 +0900, Chung-Lin Tang wrote:
>  Hi,
>  PR48250 happens under TARGET_NEON, where DImode is included within the
>  valid NEON modes. This turns the range of legitimate constant indexes to
>  step-4 (coproc load/store), thus arm_legitimize_reload_address() when
>  trying to decompose the [reg+index] reload address into
>  [(reg+index_high)+index_low], can cause an ICE later when 'index_low'
>  part is not aligned to 4.
> 
>  I'm not sure why the current DImode index is computed as:
>  low = ((val & 0xf) ^ 0x8) - 0x8;  the sign-extending into negative
>  values, then subtracting back, actually creates further off indexes.
>  e.g. in the supplied testcase, [sp+13] was turned into [(sp+16)-3].
> 
> >>>
> >>> Hysterical Raisins... the code there was clearly written for the days
> >>> before we had LDRD in the architecture.  At that time the most efficient
> >>> way to load a 64-bit object was to use the LDM{ia,ib,da,db}
> >>> instructions.  The computation here was (I think), intended to try and
> >>> make the most efficient use of an add/sub instruction followed by
> >>> LDM/STM offsetting.  At that time the architecture had no unaligned
> >>> access either, so dealing with 64-bit that were less than 32-bit aligned
> >>> (in those days 32-bit was the maximum alignment) probably wasn't
> >>> considered, or couldn't even get through to reload.
> >>>
> >>
> >> I see it now. The code in output_move_double() returning assembly for
> >> ldm/stm(db/da/ib) for offsets -8/-4/+4 seems to confirm this.
> >>
> >> I have changed the patch to let the new code handle the TARGET_LDRD case
> >> only.  The pre-LDRD case is still handled by the original code, with an
> >> additional & ~0x3 for aligning the offset to 4.
> >>
> >> I've also added a comment for the pre-TARGET_LDRD case. Please see if
> >> the description is accurate enough.
> >>
>  My patch changes the index decomposing to a more straightforward way; it
>  also sort of outlines the way the other reload address indexes are
>  broken by using and-masks, is not the most effective.  The address is
>  computed by addition, subtracting away the parts to obtain low+high
>  should be the optimal way of giving the largest computable index range.
> 
>  I have included a few Thumb-2 bits in the patch; I know currently
>  arm_legitimize_reload_address() is only used under TARGET_ARM, but I
>  guess it might eventually be turned into TARGET_32BIT.
> 
> >>>
> >>> I think this needs to be looked at carefully on ARMv4/ARMv4T to check
> >>> that it doesn't cause regressions there when we don't have LDRD in the
> >>> instruction set.
> >>
> >> I'll be testing the modified patch under an ARMv4/ARMv4T configuration.
> >> Okay for trunk if no regressions?
> >>
> >> Thanks,
> >> Chung-Lin
> >>
> >>PR target/48250
> >>* config/arm/arm.c (arm_legitimize_reload_address): Adjust
> >>DImode constant index decomposing under TARGET_LDRD. Clear
> >>lower two bits for NEON, Thumb-2, and !TARGET_LDRD. Add
> >>comment for !TARGET_LDRD case.
> > 
> > This looks technically correct, but I can't help feeling that trying to
> > deal with the bottom two bits being non-zero is not really worthwhile.
> > This hook is an optimization that's intended to generate better code
> > than the default mechanisms that reload provides.  It is allowed to
> > fail, but it must say so if it does (by returning false).
> > 
> > What this hook is trying to do for DImode is to take an address of the
> > form (reg + TOO_BIG_CONST) and turn it into two instructions that are
> > legitimate:
> > 
> > tmp = (REG + LEGAL_BIG_CONST)
> > some_use_of (mem (tmp + SMALL_LEGAL_CONST))
> > 
> > The idea behind the optimization is that LEGAL_BIG_CONST will need fewer
> > instructions to generate than TOO_BIG_CONST.  It's unlikely (probably
> > impossible in ARM state) that pushing the bottom two bits of the address
> > into LEGAL_BIG_CONST part of the offset is going to lead to a better
> > code sequence.  
> > 
> > So I think it would be more sensible to just return false if we have a
> > DImode address with the bottom 2 bits non-zero and then let the normal
> > reload recovery mechanism take over.
> 
> It is supposed to provide better utilization of the full range of
> LEGAL_BIG_CONST+SMALL_LEGAL_CONST.  I am not sure, but I guess reload
> will resolve it with the reg+LEGAL_BIG_CONST part only, using only (mem
> (reg)) for the load/store (correct me if I'm wrong).
> 
> Also, the new code slighty improves the reloading, for example currently
> [reg+64] is broken into [(reg+72)-8], creating an additional unneeded
> reload, which is certainly not good when we have l

Re: [cxx-mem-model] disallow load data races (1 of some)

[Aldy Hernandez]

On 03/25/11 10:39, Richard Guenther wrote:

On Fri, Mar 25, 2011 at 4:33 PM, Jakub Jelinek  wrote:

On Fri, Mar 25, 2011 at 09:30:22AM -0600, Jeff Law wrote:

I'm not going to chime in on this specific problem; however, it is worth
noting that many of the issues raised by the C++0x memory model also
affect the linux kernel.


But what they are seeing are certainly store data races, not load races,
because no hw they care about (or no hw at all?) detects the latter.
Having options to avoid store data races is useful not just for C++0x memory
model compliance and Linux kernel, but e.g. for OpenMP too.


And we have in the past removed code that created store data races
anyway.  There is nothing new here.

As stated multiple times in the past things get "interesting" when you
look at non-x86 hardware.


Agreed on all counts, with everyone :).  I will desist from trying to 
disable speculative loads and load data races which affect no one.


Below is a patch I am committing to remove all tests checking for load 
races.


As Richi has mentioned, there are some interesting store data races on 
non-x86 hardware.  I will be looking into those, particularly non 
contiguous bitfield issues on ppc, s390, and possibly alpha: stay tuned.


Thanks for the comments.
* gcc.dg/memmodel/d2.c: Remove.
* gcc.dg/memmodel/d3.c: Remove.
* gcc.dg/memmodel/global-hoist.c: Remove.

Index: gcc.dg/memmodel/global-hoist.c
===
--- gcc.dg/memmodel/global-hoist.c  (revision 170745)
+++ gcc.dg/memmodel/global-hoist.c  (working copy)
@@ -1,73 +0,0 @@
-/* { dg-do link } */
-/* { dg-options "-O2 --param allow-load-data-races=0" } */
-/* { dg-final { memmodel-gdb-test } } */
-
-/* Verify that a load of a global is not hoisted out of a loop.  This
-   can introduce a data race, and is dissallowed if
-   --param allow-load-data-races is 0. */
-
-#include 
-#include 
-#include "memmodel.h"
-
-int global = 0;
-int sum[5];
-
-
-/* The other thread in the system increments the value of global by
-   one each time it is executed.  By accessing 'global' in a loop, we can
-   check if the load has been hoisted out of the loop by seeing if
-   iterations of the loop get the same or different values of
-   global.  */
-void
-memmodel_other_threads() 
-{
-  global++;
-}
-
-/* Nothing to verify at each step. */
-int
-memmodel_step_verify()
-{
-  return 0;
-}
-
-/* Every element of the array should have a different value of global if the 
- * load is left in the loop like it is supposed to.  */
-int
-memmodel_final_verify()
-{
-  int ret = 0;
-  int x, y;
-
-  for (x = 0; x < 4; x++)
-for (y = x + 1; y < 5; y++)
-  {
-   if (sum[x] == sum[y])
- {
-   printf("FAIL: sum[%d] and sum[%d] have the same value : %d\n",
-  x, y, sum[x]);
-   ret = 1;
- }
-  }
-  return ret;
-}
-
-/* 'global' is bumped by "the other thread" every insn.  Test that all
-   elements of 'sum' are different, otherwise load of 'global' has
-   been hoisted.  */
-void
-test()
-{
-  int x;
-
-  for (x=0; x< 5; x++)
-sum[x] =  global;
-}
-
-int
-main()
-{
-  test();
-  memmodel_done();
-}
Index: gcc.dg/memmodel/d2.c
===
--- gcc.dg/memmodel/d2.c(revision 170745)
+++ gcc.dg/memmodel/d2.c(working copy)
@@ -1,60 +0,0 @@
-/* { dg-do link } */
-/* { dg-options "-O2 --param allow-load-data-races=0" } */
-/* { dg-final { memmodel-gdb-test } } */
-
-#include 
-#include "memmodel.h"
-
-/* This is a variation on global-hoist.c where instead of a loop, we
-   store global into different elements of an array in straightline
-   code with an if condition.  This will catch cases where commoning
-   should be disabled when --param allow-load-data-races is 0.  */
-
-/* Test the FALSE path in test.  */
-
-int global = 0;
-int sum[4] = { 0, 0, 0, 0 };
-
-void memmodel_other_threads() 
-{
-  global++;
-}
-
-int memmodel_step_verify()
-{
-  return 0;
-}
-
-int memmodel_final_verify()
-{
-  int ret = 0;
-  int x, y;
-  for (x = 0; x < 3; x++)
-for (y = x + 1; y < 4; y++)
-  {
-   if (sum[x] == sum[y])
- {
-   printf("FAIL: sum[%d] and sum[%d] have the same value : %d\n",
-  x, y, sum[x]);
-   ret = 1;
- }
-  }
-}
-
-/* Since global is always being increased by the 'other' thread, all
-   elements of sum should be different.  (no cse) */
-int test (int y)
-{
-  sum[0] = global;
-  if (y)
-sum[1] = global;
-  else
-sum[2] = global;
-  sum[3] = global;
-}
-
-int main()
-{
-  test(0);
-  memmodel_done();
-}
Index: gcc.dg/memmodel/d3.c
===
--- gcc.dg/memmodel/d3.c(revision 170745)
+++ gcc.dg/memmodel/d3.c(working copy)
@@ -1,61 +0,0 @@
-/* { dg-do link } */
-/* { dg-options "-O2 --param allow-load-data-races=0" } */
-/* { dg-fi

Re: [C++0x] Range-based for statements and ADL

[Rodrigo Rivas]

On Tue, Mar 29, 2011 at 5:46 PM, Gabriel Dos Reis
 wrote:
> or "new-style for loop"?
Well, that is what they are called in Java, isn't it? And the syntax
is just the same, so it would make kind of sense.
But in the C++0x draft and the GCC docs it is almost always called
"range-based for loops, so I think it is preferred.


Talking of this... I tried the simplest wrong range-based for, with my
latest patch:

int main()
{
for (int x : 0)
;
}

And that is what I got:

test.cpp: In function ‘int main()’:
test.cpp:3:18: error: ‘begin’ was not declared in this scope
test.cpp:3:18: error: ‘end’ was not declared in this scope

That's ok. But now, if I add #include  I get:

test.cpp: In function ‘int main()’:
test.cpp:4:18: error: no matching function for call to ‘begin(int&)’
test.cpp:4:18: note: candidates are:
/home/rodrigo/local/gcc/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/range_access.h:87:5:
note: template _Tp* std::begin(_Tp
(&)[_Nm])
/home/rodrigo/local/gcc/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/range_access.h:58:63:
note: template decltype (__cont->begin())
std::begin(const _Container&)
/home/rodrigo/local/gcc/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/range_access.h:48:57:
note: template decltype (__cont->begin())
std::begin(_Container&)
/home/rodrigo/local/gcc/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/initializer_list:86:38:
note: template constexpr const _Tp*
std::begin(std::initializer_list<_Tp>)
test.cpp:4:18: error: no matching function for call to ‘end(int&)’
test.cpp:4:18: note: candidates are:
/home/rodrigo/local/gcc/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/range_access.h:97:5:
note: template _Tp* std::end(_Tp
(&)[_Nm])
/home/rodrigo/local/gcc/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/range_access.h:78:59:
note: template decltype (__cont->end())
std::end(const _Container&)
/home/rodrigo/local/gcc/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/range_access.h:68:53:
note: template decltype (__cont->end())
std::end(_Container&)
/home/rodrigo/local/gcc/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/initializer_list:96:36:
note: template constexpr const _Tp*
std::end(std::initializer_list<_Tp>)

Although the error messages are technically correct, I find them too
verbose and probably misleading to the novice: "'begin' not declared?
I'm not using 'begin', I'm using 'for').
Note also that the error could be corrected adding member functions
begin/end (if the range were of class type), but that is not suggested
in the error message.

Maybe a simpler error is better. such as:
"expression is not valid as range in a range-based % loop
because it lacks begin/end members or begin(int&) and end(int&)
overloads." (I leave the wording to someone more skilled with
English).

Regards.
--
Rodrigo

a tiny patch for IRA

[Vladimir Makarov]

I found that parent_max variable can be not used by code in macro 
SET_MINMAX_SET_BIT if release mode is used.  That results in generation 
of an unnecessary warning.


The following patch removes the warning and is committed as obvious.

2011-03-29  Vladimir Makarov 

* ira-conflicts.c (build_object_conflicts): Add unused attribute
to parent_max.

Index: ira-conflicts.c
===
--- ira-conflicts.c (revision 171682)
+++ ira-conflicts.c (working copy)
@@ -612,7 +612,7 @@ build_object_conflicts (ira_object_t obj)
   ira_allocno_t a = OBJECT_ALLOCNO (obj);
   IRA_INT_TYPE *object_conflicts;
   minmax_set_iterator asi;
-  int parent_min, parent_max;
+  int parent_min, parent_max ATTRIBUTE_UNUSED;
 
   object_conflicts = conflicts[OBJECT_CONFLICT_ID (obj)];
   px = 0;

Re: [PATCH] -E/-save-temps locus fix (PR preprocessor/48248)

[Joseph S. Myers]

On Tue, 29 Mar 2011, Jakub Jelinek wrote:

> Hi!
> 
> My PR41445 fix apparently sometimes results in wrong locus.
> The problem is if we switch temporarily to a locus of some token
> from a header file (PR41445 was fixing a problem where -save-temps
> behaved differently then normal compilation as locuses were different)
> and the line in the header file is within 8 lines of the line in the
> current source file, maybe_print_line optimizes and will emit
> newlines instead of emitting # X "file"... line.
> The optimization should be done only if it is the same file though.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk/4.6?

OK.

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

[cxx-mem-model] bitfield tests

[Aldy Hernandez]

[Language lawyers, please correct me if I have mis-interpreted the 
upcoming standard in any way.]


In the C++ memory model, contiguous bitfields comprise a single memory 
location, so it's fair game to bit twiddle them when setting them.  For 
example:


struct {
unsigned int a : 4;
unsigned int b : 4;
unsigned int c : 4;
};

In the above example, you can touch  and  while setting .  No 
race there.


However, non contiguous bitfields are a different story:

struct {
unsigned int a : 4;
char b;
unsigned int c : 6;
};

Here we have 3 distinct memory locations, so you can't touch  or  
while setting .  No bit twiddling allowed.


Similarly for bitfields separated by a zero-length bitfield:

struct {
unsigned int a : 4;
int : 0;
unsigned int c : 6;
};

In the above example,  and  are distinct memory locations.

Also, a structure/union boundary will also separate previously 
contiguous bit sequences:


struct {
unsigned int a : 4;
struct { unsigned int b : 4 } BBB;
unsigned int c : 4;
};

Here we have 3 distinct memory locations, so again, we can't clobber  
or  while setting .


The patch below adds a non-contiguous bit test (bitfields-2.C) which 
passes on x86, but upon assembly inspection, fails on PPC64, s390, and 
Alpha.  These 3 architectures bit-twiddle their way out of the problem.


There is also a similar test already in the testsuite (bitfields.C) 
which is similar except one field is a volatile.  This test fails on 
x86-64 as well and is the subject of PR48128 which Jakub is currently 
tackling.


As soon as Jakub finishes with PR48128, I will be working on getting 
these bitfield tests working in a C++ memory model fashion.


Committing to branch.
* gcc.dg/memmodel/subfields.c (set_a): Set noinline attribute.
* g++.dg/memmodel/bitfields.C (set_a): Same.
* g++.dg/memmodel/bitfields-2.C: New.

Index: gcc.dg/memmodel/subfields.c
===
--- gcc.dg/memmodel/subfields.c (revision 170937)
+++ gcc.dg/memmodel/subfields.c (working copy)
@@ -20,6 +20,7 @@ struct test_struct {
not affect any of the other fields in the structure.  An improper
implementation may load an entire word, change the 8 bits for field
'a' and write the entire word back out. */
+__attribute__((noinline))
 void set_a(char x)
 {
   var.a = x;
Index: g++.dg/memmodel/bitfields-2.C
===
--- g++.dg/memmodel/bitfields-2.C   (revision 0)
+++ g++.dg/memmodel/bitfields-2.C   (revision 0)
@@ -0,0 +1,71 @@
+/* { dg-do link } */
+/* { dg-options "-O2 --param allow-load-data-races=0 --param 
allow-store-data-races=0" } */
+/* { dg-final { memmodel-gdb-test } } */
+
+/* Test that setting  does not touch either  or .
+   In the C++ memory model, non contiguous bitfields ("a" and "c"
+   here) should be considered as distinct memory locations, so we
+   can't use bit twiddling to set either one.  */
+
+#include 
+#include "memmodel.h"
+
+#define CONSTA 12
+
+static int global;
+struct S
+{
+  unsigned int a : 4;
+  unsigned char b;
+  unsigned int c : 6;
+} var;
+
+__attribute__((noinline))
+void set_a()
+{
+  var.a = CONSTA;
+}
+
+void memmodel_other_threads()
+{
+  ++global;
+  var.b = global;
+  var.c = global;
+}
+
+int memmodel_step_verify()
+{
+  int ret = 0;
+  if (var.b != global)
+{
+  printf ("FAIL: Unexpected value: var.b is %d, should be %d\n",
+ var.b, global);
+  ret = 1;
+}
+  if (var.c != global)
+{
+  printf ("FAIL: Unexpected value: var.c is %d, should be %d\n",
+ var.c, global);
+  ret = 1;
+}
+  return ret;
+}
+
+int memmodel_final_verify()
+{
+  int ret = memmodel_step_verify();
+  if (var.a != CONSTA)
+{
+  printf ("FAIL: Unexpected value: var.a is %d, should be %d\n",
+ var.a, CONSTA);
+  ret = 1;
+}
+  return ret;
+}
+
+int main()
+{
+  set_a();
+  memmodel_done();
+  return 0;
+}
Index: g++.dg/memmodel/bitfields.C
===
--- g++.dg/memmodel/bitfields.C (revision 171248)
+++ g++.dg/memmodel/bitfields.C (working copy)
@@ -23,6 +23,7 @@ struct S
   unsigned int c : 6;
 } var;
 
+__attribute__((noinline))
 void set_a()
 {
   var.a = CONSTA;

Re: [x32] PATCH: PR middle-end/47725: [x32] error: unable to find a register to spill in class DIREG

[H.J. Lu]

On Thu, Mar 24, 2011 at 8:51 AM, Eric Botcazou  wrote:
>> Pointer is promoted to Pmode from ptr_mode.
>
> Indeed.  However the problem is the 2 in assign_parm_setup_reg:
>
>  /* Store the parm in a pseudoregister during the function, but we may
>     need to do it in a wider mode.  Using 2 here makes the result
>     consistent with promote_decl_mode and thus expand_expr_real_1.  */
>  promoted_nominal_mode
>   = promote_function_mode (data->nominal_type, data->nominal_mode, &unsignedp,
>                             TREE_TYPE (current_function_decl), 2);
>
> which is supposed to match the 2 in promote_decl_mode:
>
>  if (TREE_CODE (decl) == RESULT_DECL
>      || TREE_CODE (decl) == PARM_DECL)
>    pmode = promote_function_mode (type, mode, &unsignedp,
>                                   TREE_TYPE (current_function_decl), 2);
>  else
>    pmode = promote_mode (type, mode, &unsignedp);
>
> but doesn't match the 0 in assign_parm_find_data_types:
>
>  promoted_mode = promote_function_mode (passed_type, passed_mode, &unsignedp,
>                                         TREE_TYPE (current_function_decl), 0);
>
> so you get the redundant extension in the callee.  The solution is to define
> the promote_function_mode hook for x86 to something like:
>
> static enum machine_mode
> ix86_promote_function_mode (const_tree type,
>                            enum machine_mode mode,
>                            int *punsignedp,
>                            const_tree fntype ATTRIBUTE_UNUSED,
>                            int for_return ATTRIBUTE_UNUSED)
> {
>  if (POINTER_TYPE_P (type))
>    {
>      *punsignedp = POINTERS_EXTEND_UNSIGNED;
>      return Pmode;
>    }
>
>  return mode;
> }
>

Here is the patch.  precompute_register_parameters change is needed for

---
extern __thread int ttt;
extern void bar (void *);
void
foo1 ()
{
  bar (&ttt);
}
---

I used

/* Pointer function arguments and return values are promoted to
   Pmode.  */

static enum machine_mode
ix86_promote_function_mode (const_tree type, enum machine_mode mode,
int *punsignedp, const_tree fntype,
int for_return)
{
  if (for_return != 1 && POINTER_TYPE_P (type))
{
  *punsignedp = POINTERS_EXTEND_UNSIGNED;
  return Pmode;
}
  return default_promote_function_mode (type, mode, punsignedp, fntype,
for_return);
}

since for_return == 1 has to match function_value, which I want to keep
as is.  default_promote_function_mode handles i386 PROMOTE_MODE.
Tested it on Linux/ia32 and Linux/x86-64.  OK for trunk?

Thanks.

-- 
H.J.
--
2011-03-29  H.J. Lu  

PR middle-end/47725
PR target/48085
* calls.c (precompute_register_parameters): Convert pointer to
TLS symbol if needed.

* config/i386/i386.c (ix86_promote_function_mode): New.
(TARGET_PROMOTE_FUNCTION_MODE): Likewise.
diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
index 303acd8..a7ff7e3 100644
--- a/gcc/ChangeLog.x32
+++ b/gcc/ChangeLog.x32
@@ -1,6 +1,16 @@
 2011-03-29  H.J. Lu  
 
PR middle-end/47725
+   PR target/48085
+   * calls.c (precompute_register_parameters): Convert pointer to
+   TLS symbol if needed.
+
+   * config/i386/i386.c (ix86_promote_function_mode): New.
+   (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
+
+2011-03-29  H.J. Lu  
+
+   PR middle-end/47725
* combine.c (cant_combine_insn_p): Don't check zero/sign extended
hard registers.
 
diff --git a/gcc/calls.c b/gcc/calls.c
index 2e79777..7357241 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -691,7 +691,13 @@ precompute_register_parameters (int num_actuals, struct 
arg_data *args,
   pseudo now.  TLS symbols sometimes need a call to resolve.  */
if (CONSTANT_P (args[i].value)
&& !LEGITIMATE_CONSTANT_P (args[i].value))
- args[i].value = force_reg (args[i].mode, args[i].value);
+ {
+   if (GET_MODE (args[i].value) != args[i].mode)
+ args[i].value = convert_to_mode (args[i].mode,
+  args[i].value,
+  args[i].unsignedp);
+   args[i].value = force_reg (args[i].mode, args[i].value);
+ }
 
/* If we are to promote the function arg to a wider mode,
   do it now.  */
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index d7a5c02..6cffab2 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7636,6 +7636,23 @@ ix86_function_value (const_tree valtype, const_tree 
fntype_or_decl,
   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
 }
 
+/* Pointer function arguments and return values are promoted to
+   Pmode.  */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+   int *punsignedp, const_tree fntype,
+   int for_return)
+{
+  i

Re: [testsuite] Fix gcc.dg/torture/pr47917.c on IRIX 6.5

[Steve Ellcey]

On Fri, Mar 25, 2011 at 4:27 PM, Rainer Orth wrote:
> The new gcc.dg/torture/pr47917.c test currently fails the execution test
> on IRIX 6.5.  To get a C99-conformant snprintf, one needs to include
>  with _XOPEN_SOURCE defined as 500.  The following patch does
> this.

Rainer,

This patch re-broke pr47917.c on HP-UX because it doesn't see the
snprintf prototype in stdio.h when using -std=c99.  I do see it if I use
-std=gnu99 instead and that is what I probably should have used in the
first place.  I was wondering if using -std=gnu99 would also work for
mips-sgi-irix6.5 in place of "-std=c99 -D_XOPEN_SOURCE=500".

If so I would propose this patch to just use -std=gnu99 for all
platforms:

$ svn diff gcc.dg/torture/pr47917.c
Index: gcc.dg/torture/pr47917.c
===
--- gcc.dg/torture/pr47917.c(revision 171649)
+++ gcc.dg/torture/pr47917.c(working copy)
@@ -1,6 +1,5 @@
 /* { dg-do run } */
-/* { dg-options "-std=c99" } */
-/* { dg-options "-std=c99 -D_XOPEN_SOURCE=500" { target mips-sgi-irix6.5 } } */
+/* { dg-options "-std=gnu99" } */
 /* { dg-xfail-if "no C99 snprintf function" { *-*-hpux10* } } */
 /* { dg-xfail-run-if "non-conforming C99 snprintf" { *-*-hpux11.[012]* } } */


Steve Ellcey
s...@cup.hp.com

Re: [testsuite] Fix gcc.dg/torture/pr47917.c on IRIX 6.5

[Rainer Orth]

Steve,

> This patch re-broke pr47917.c on HP-UX because it doesn't see the
> snprintf prototype in stdio.h when using -std=c99.  I do see it if I use

sorry for that.  I noticed later that this standards-conformant snprintf
business is a total mess on several platforms (e.g. it also fails on
Tru64 UNIX, but there needs _ISO_C_SOURCE=19990L to enable ;-)

> -std=gnu99 instead and that is what I probably should have used in the
> first place.  I was wondering if using -std=gnu99 would also work for
> mips-sgi-irix6.5 in place of "-std=c99 -D_XOPEN_SOURCE=500".

No, unfortunately not: only the XPG5 version of snprintf works on IRIX 6.5.

> If so I would propose this patch to just use -std=gnu99 for all
> platforms:
>
> $ svn diff gcc.dg/torture/pr47917.c
> Index: gcc.dg/torture/pr47917.c
> ===
> --- gcc.dg/torture/pr47917.c(revision 171649)
> +++ gcc.dg/torture/pr47917.c(working copy)
> @@ -1,6 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-std=c99" } */
> -/* { dg-options "-std=c99 -D_XOPEN_SOURCE=500" { target mips-sgi-irix6.5 } } 
> */
> +/* { dg-options "-std=gnu99" } */
>  /* { dg-xfail-if "no C99 snprintf function" { *-*-hpux10* } } */
>  /* { dg-xfail-run-if "non-conforming C99 snprintf" { *-*-hpux11.[012]* } } */

Sorry, this won't work.  I fear we'll have to add another dg-options
clause for HP-UX here:

/* { dg-options "-std=gnu99" { target *-*-hpux* } } */

Alternatively, the mips-sgi-irix6.5 variant might work, too.  Either
patch is preapproved if this works for you.

Thanks.
Rainer

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

Re: [debug] Introduce -fno-debug-types-section flag

[Cary Coutant]

> Some dwarf consumers (dwarves, systemtap and dwarflint) grok Dwarf V4,
> but not yet the new .debug_types section. To make it easier to use these
> tools with -gdwarf-4 this patch introduces a new
> -fno-debug-types-section flag and guards all code that is type unit
> specific with use_debug_types instead of a generic dwarf_version >= 4
> flag. IMHO this makes the code also slightly more readable. And it
> re-enables the usage of -feliminate-dwarf2-dups with -gdwarf-4. Although
> admittedly the value of that is probably pretty low. I found it helpful
> in debugging some issues with dwarf consumers and DW_FORM_ref_addr
> usage.

I can't approve the patch, but I think it's a good option to have and
the patch looks good to me.

-cary

Re: [C++0x] Range-based for statements and ADL

[Jonathan Wakely]

On 29 March 2011 17:41, Rodrigo Rivas wrote:
>
> Maybe a simpler error is better. such as:
> "expression is not valid as range in a range-based % loop
> because it lacks begin/end members or begin(int&) and end(int&)
> overloads." (I leave the wording to someone more skilled with
> English).

If you can prevent the full lookup error and print something different
I think users would be very grateful indeed.

How about "No suitable % and % functions found for range
expression of type %qT in % statement" ?

That

Go patch committed: Fix select setting map index

[Ian Lance Taylor]

This patch to the Go frontend fixes the case where a select clause sets
a map index.  For a map index we need to know whether it is an lvalue or
not, and the code forgot to set that.  This patch also fixes the parsing
of a select clause for a case like
case v := <- r
when there are no statements.

Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian

diff -r e26f717e0ff5 go/parse.cc
--- a/go/parse.cc	Mon Mar 28 16:52:26 2011 -0700
+++ b/go/parse.cc	Tue Mar 29 11:51:29 2011 -0700
@@ -4274,41 +4274,43 @@
   bool got_case = this->comm_case(&is_send, &channel, &val, &closed,
   &varname, &closedname, &is_default);
 
+  if (!is_send
+  && varname.empty()
+  && closedname.empty()
+  && val != NULL
+  && val->index_expression() != NULL)
+val->index_expression()->set_is_lvalue();
+
   if (this->peek_token()->is_op(OPERATOR_COLON))
 this->advance_token();
   else
 error_at(this->location(), "expected colon");
 
-  Block* statements = NULL;
+  this->gogo_->start_block(this->location());
+
   Named_object* var = NULL;
+  if (!varname.empty())
+{
+  // FIXME: LOCATION is slightly wrong here.
+  Variable* v = new Variable(NULL, channel, false, false, false,
+ location);
+  v->set_type_from_chan_element();
+  var = this->gogo_->add_variable(varname, v);
+}
+
   Named_object* closedvar = NULL;
-  if (this->peek_token()->is_op(OPERATOR_SEMICOLON))
-this->advance_token();
-  else if (this->statement_list_may_start_here())
+  if (!closedname.empty())
 {
-  this->gogo_->start_block(this->location());
-
-  if (!varname.empty())
-	{
-	  // FIXME: LOCATION is slightly wrong here.
-	  Variable* v = new Variable(NULL, channel, false, false, false,
- location);
-	  v->set_type_from_chan_element();
-	  var = this->gogo_->add_variable(varname, v);
-	}
-
-  if (!closedname.empty())
-	{
-	  // FIXME: LOCATION is slightly wrong here.
-	  Variable* v = new Variable(Type::lookup_bool_type(), NULL,
- false, false, false, location);
-	  closedvar = this->gogo_->add_variable(closedname, v);
-	}
-
-  this->statement_list();
-  statements = this->gogo_->finish_block(this->location());
+  // FIXME: LOCATION is slightly wrong here.
+  Variable* v = new Variable(Type::lookup_bool_type(), NULL,
+ false, false, false, location);
+  closedvar = this->gogo_->add_variable(closedname, v);
 }
 
+  this->statement_list();
+
+  Block* statements = this->gogo_->finish_block(this->location());
+
   if (is_default)
 {
   if (*saw_default)

C++ PATCH for c++/48319 (ICE with value-dependent call)

[Jason Merrill]

In this testcase, we were failing to consider declval<_Args1> as 
value-dependent, even though it is due to the use of a type parameter. 
We previously just handled TEMPLATE_ID_EXPR as a normal binary 
expression and assumed that a TREE_VEC was always non-dependent.


Tested x86_64-pc-linux-gnu, applied to trunk and 4.6.
commit 877698d7630d958bfbe1e7a7a69c8a4290c486a2
Author: Jason Merrill 
Date:   Tue Mar 29 13:05:08 2011 -0400

PR c++/48319
* pt.c (value_dependent_expression_p): Handle TEMPLATE_ID_EXPR.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dfc726a..aa0901b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18218,6 +18218,11 @@ value_dependent_expression_p (tree expression)
return false;
   }
 
+case TEMPLATE_ID_EXPR:
+  /* If a TEMPLATE_ID_EXPR involves a dependent name, it will be
+type-dependent.  */
+  return type_dependent_expression_p (expression);
+
 default:
   /* A constant expression is value-dependent if any subexpression is
 value-dependent.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/dependent1.C 
b/gcc/testsuite/g++.dg/cpp0x/dependent1.C
new file mode 100644
index 000..1ceeeaf
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/dependent1.C
@@ -0,0 +1,25 @@
+// PR c++/48319
+// { dg-options -std=c++0x }
+// We were failing to recognize declval<_Args1> as dependent.
+
+template Tp declval() noexcept;
+
+template
+class __is_constructible_helper
+{
+  typedef char __one;
+  typedef struct { char __arr[2]; } __two;
+
+  template
+  static decltype(_Tp1(declval<_Args1>()...), __one()) __test(int);
+
+  template
+  static __two __test(...);
+
+public:
+  static const bool __value = sizeof(__test<_Tp>(0)) == 1;
+};
+
+int main() {
+  return __is_constructible_helper::__value;
+}

Re: Prune empty cases from toplevel configure.ac

[Nathanael Nerode (GCC)]

On 03/21/2011 06:41 AM, Joseph S. Myers wrote:
> This patch, relative to a tree with my deprecated targets removal patch 
>  applied, further 
> cleans up the toplevel configure.ac by removing empty cases from a case 
> statement.  The original patch still needs review by someone able to 
> approve the patch as a whole, but as the only apparent controversy so far 
> concerned empty cases I hope this patch can resolve the concerns over that 
> bit of the original patch.

I'd just like to say thanks for doing this (removing dead and empty
cases).  I wanted to do a lot more of this when I cleaned up the
toplevel several years back, but people were extremely uncertain at that
time as to what other projects were using the top level and how they
would react to the change.  I'm glad this can be done now, as I guess
it's clear now that the top level is only being used by a short, known
list of projects.

Nathanael Nerode

Re: More toplevel configure.ac pruning

[Nathanael Nerode (GCC)]

On 03/25/2011 07:33 AM, Joseph S. Myers wrote:

> -# Some tools are only suitable for building in a "native" situation.
> -# Remove these if host!=target.  
> -native_only="autoconf automake libtool fileutils find gawk gettext gzip 
> hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff guile 
> perl time ash bash bzip2 prms gnuserv target-gperf"

So target-gperf works when host != target now?  Good to know.

I remember when the native_only list was invented there were a lot more
things in it, many of which were actually part of GCC or binutils.  I'm
glad to see this has changed.

RFA: patch to solve PR 48331 and PR 48334 in IRA

[Vladimir Makarov]

The following patch solves PR 48331 and PR 48334.  The problem was in 
that allocno profitable hard regs were not set up for priority colouring 
and function assign_hard_reg used a garbage in its decisions generating 
wrong code or code of awful quality.


Is it ok to commit?

2011-03-29  Vladimir Makarov 

PR rtl-optimization/48331
PR rtl-optimization/48334
* ira-color.c (color_allocnos): Call setup_profitable_hard_regs
for any used algorithm.

Index: ira-color.c
===
--- ira-color.c (revision 171682)
+++ ira-color.c (working copy)
@@ -2590,6 +2590,7 @@ color_allocnos (void)
   bitmap_iterator bi;
   ira_allocno_t a;
 
+  setup_profitable_hard_regs ();
   if (flag_ira_algorithm == IRA_ALGORITHM_PRIORITY)
 {
   n = 0;
@@ -2642,7 +2643,6 @@ color_allocnos (void)
 }
   else
 {
-  setup_profitable_hard_regs ();
   form_object_hard_regs_nodes_forest ();
   if (internal_flag_ira_verbose > 2 && ira_dump_file != NULL)
print_hard_regs_forest (ira_dump_file);

Re: [PING][PATCH, testsuite] Update gcc.dg/stack-usage-1.c SIZE values for powerpc

[Mike Stump]

On Mar 29, 2011, at 5:14 AM, Peter Bergner wrote:
> Mike and David, I assume the updated patch below is ok for mainline?

Ok.  I applied it for you...  I'm assuming you don't have write after yet...  
Thanks for all the work.

2011-03-29  Peter Bergner 
Dominique d'Humieres

* gcc.dg/stack-usage-1.c (SIZE): Provide proper values for __ppc64__
and __APPLE__ && __PPC__ && __ALTIVEC__.

Index: gcc.dg/stack-usage-1.c
===
--- gcc.dg/stack-usage-1.c  (revision 171691)
+++ gcc.dg/stack-usage-1.c  (working copy)
@@ -30,12 +30,17 @@
 #  else
 #define SIZE 248
 #  endif
-#elif defined (__powerpc64__) || defined (__PPC64__)
+#elif defined (__powerpc64__) || defined (__ppc64__) || defined 
(__POWERPC64__) \
+  || defined (__PPC64__)
 #  define SIZE 180
 #elif defined (__powerpc__) || defined (__PPC__) || defined (__ppc__) \
   || defined (__POWERPC__) || defined (PPC) || defined (_IBMR2)
 #  if defined (__ALTIVEC__)
-#define SIZE 220
+#if defined (__APPLE__)
+#  define SIZE 204
+#else
+#  define SIZE 220
+#endif
 #  else
 #define SIZE 240
 #  endif

go patch committed: Recognize new tests in go-test.exp

[Ian Lance Taylor]

This patch updates go-test.exp to recognize various new tests I am about
to commit.  Ran Go testsuite on x86_64-unknown-linux-gnu.  Committed to
mainline.

Ian


2011-03-29  Ian Lance Taylor  

* go.test/go-test.exp: Handle the test lines used in several new
tests.
(errchk): Add opts parameter.  Change all callers.  Handle parens
in regexps.


Index: go.test/go-test.exp
===
--- go.test/go-test.exp	(revision 171520)
+++ go.test/go-test.exp	(working copy)
@@ -35,7 +35,7 @@ load_lib go-dg.exp
 load_lib go-torture.exp
 
 # Implement errchk
-proc errchk { test } {
+proc errchk { test opts } {
 global dg-do-what-default
 global DEFAULT_GOCFLAGS
 global runtests
@@ -69,6 +69,14 @@ proc errchk { test } {
 	set index [string first "dg-error" $out_line]
 	regsub -start $index -all "\}\(.\)" $out_line "\[\\\}\]\\1" out_line
 	}
+	if [string match "*dg-error*\(*" $out_line] {
+	set index [string first "dg-error" $out_line]
+	regsub -start $index -all "\\\(" $out_line "\[\\\(\]" out_line
+	}
+	if [string match "*dg-error*\)*\}" $out_line] {
+	set index [string first "dg-error" $out_line]
+	regsub -start $index -all "\\\)\(.\)" $out_line "\[\\\)\]\\1" out_line
+	}
 	if [string match "*dg-error*\[.\]*" $out_line] {
 	set index [string first "dg-error" $out_line]
 	regsub -all "\\\[\\.\\\]" $out_line "\[.\]" out_line
@@ -80,7 +88,7 @@ proc errchk { test } {
 
 set hold_runtests $runtests
 set runtests "go-test.exp"
-go-dg-runtest $filename "-fno-show-column $DEFAULT_GOCFLAGS"
+go-dg-runtest $filename "-fno-show-column $DEFAULT_GOCFLAGS $opts"
 set runtests $hold_runtests
 
 file delete $filename
@@ -340,7 +348,8 @@ proc go-gc-tests { } {
 			"// \$G \$D/\$F.go && \$L \$F.\$A || echo BUG*" \
 			$test_line] \
 		   || [string match "// \$G \$F.go && \$L \$F.\$A  #*" \
-			   $test_line] } {
+			   $test_line]
+		   || $test_line == "// \$G \$D/\$F.go && \$L \$F.\$A" } {
 	# This is a vanilla compile and link test.
 	set dg-do-what-default "link"
 	go-dg-runtest $test "-w $DEFAULT_GOCFLAGS"
@@ -391,7 +400,7 @@ proc go-gc-tests { } {
 			$test_line] \
 		|| [string match "// errchk \$G \$D/\$F.go || echo BUG*" \
 			$test_line] } {
-	errchk $test
+	errchk $test ""
 	} elseif { [string match \
 			"// \$G \$D/\$F.dir/bug0.go && \$G \$D/\$F.dir/bug1.go || echo BUG*" \
 			$test_line] } {
@@ -425,7 +434,7 @@ proc go-gc-tests { } {
 	regsub "\\.go$" $test ".dir/$name1" file1
 	dg-test -keep-output $file1 "-O" "-w $DEFAULT_GOCFLAGS"
 	regsub "\\.go$" $test ".dir/$name2" file2
-	errchk $file2
+	errchk $file2 ""
 	file delete "[file rootname [file tail $file1]].o"
 	set runtests $hold_runtests
 	} elseif { [string match \
@@ -468,7 +477,7 @@ proc go-gc-tests { } {
 	regsub "\\.go$" $test ".dir/bug1.go" file2
 	dg-test -keep-output $file2 "-O" "-w $DEFAULT_GOCFLAGS"
 	regsub "\\.go$" $test ".dir/bug2.go" file3
-	errchk $file3
+	errchk $file3 ""
 	file delete "[file rootname [file tail $file1]].o"
 	file delete "[file rootname [file tail $file2]].o"
 	set runtests $hold_runtests
@@ -548,6 +557,33 @@ proc go-gc-tests { } {
 	file delete $ofile1 $ofile2 $output_file
 	set runtests $hold_runtests
 	} elseif { [string match \
+			"// \$G \$D/\$F.dir/lib.go && \$G \$D/\$F.dir/main.go && \$L main.\$A && ./\$A.out || echo BUG*" \
+			$test_line ] } {
+	set hold_runtests $runtests
+	set runtests "go-test.exp"
+	set dg-do-what-default "assemble"
+	regsub "\\.go$" $test ".dir/lib.go" file1
+	dg-test -keep-output $file1 "-O" "-w $DEFAULT_GOCFLAGS"
+	set ofile1 "[file rootname [file tail $file1]].o"
+	regsub "\\.go$" $test ".dir/main.go" file2
+	dg-test -keep-output $file2 "-O" "-w $DEFAULT_GOCFLAGS"
+	set ofile2 "[file rootname [file tail $file2]].o"
+	set dg-do-what-default "link"
+	set output_file "./[file rootname [file tail $file2]].exe"
+	set comp_output [go_target_compile "$ofile1 $ofile2" \
+ $output_file "executable" "$DEFAULT_GOCFLAGS"]
+	set comp_output [go-dg-prune $target_triplet $comp_output]
+	if [string match "" $comp_output] {
+		set result [go_load "$output_file" "" ""]
+		set status [lindex $result 0]
+		$status $name
+	} else {
+		verbose -log $comp_output
+		fail $name
+	}
+	file delete $ofile1 $ofile2 $output_file
+	set runtests $hold_runtests
+	} elseif { [string match \
 			"// \$G \$D/\$F.dir/chanbug.go && \$G -I. \$D/\$F.dir/chanbug2.go" \
 			$test_line] } {
 	set hold_runtests $runtests
@@ -574,7 +610,7 @@ proc go-gc-tests { } {
 	regsub "\\.go$" $test ".dir/x.go" file1
 	dg-test -keep-output $file1 "-O" "-w $DEFAULT_GOCFLAGS"
 	regsub "\\.go$" $test ".dir/y.go" file2
-	errchk $file2
+	errchk $file2 ""
 	file delete "

Go patch committed: Update testsuite

[Ian Lance Taylor]

I committed a patch to update the Go testsuite to the master sources.
Ran Go testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian



foo.patch.bz2
Description: patch

Re: [C++0x] Range-based for statements and ADL

[Rodrigo Rivas]

On Tue, Mar 29, 2011 at 8:22 PM, Jonathan Wakely  wrote:
> How about "No suitable % and % functions found for range
> expression of type %qT in % statement" ?

Nice.
But the problem here is that there are a lot of different error conditions:
1. begin member but not end member.
2. end member but not begin member.
3. begin and end member but one or both are not callable/accesible/whatever.
3. no begin/end members, a begin global function but not end.
4. no begin/end members, an end global function but not begin.
5. no begin/end members, begin and end functions but one or both not
callable/wrong overload/etc.
6. no begin/end members, no begin/end global functions. Since the
standard headers have the std::begin/std::end templates, this will not
happen when you include (most) STL headers.

What is the best message for each? Does it make sense to have up to 6
different messages? Too many?
I just can't tell.
--
Rodrigo

Re: RFA: patch to solve PR 48331 and PR 48334 in IRA

[Bernd Schmidt]

On 03/29/2011 09:54 PM, Vladimir Makarov wrote:
> The following patch solves PR 48331 and PR 48334.  The problem was in
> that allocno profitable hard regs were not set up for priority colouring
> and function assign_hard_reg used a garbage in its decisions generating
> wrong code or code of awful quality.
> 
> Is it ok to commit?

Ok.


Bernd

Re: Tweak ARM vld3q and vld4q patterns

[Ramana Radhakrishnan]

Tested on arm-linux-gnueabi.  OK to install?


Thanks for this - yes , this is ok for trunk. It fixes PR43590 as well.

cheers
Ramana



Richard


gcc/
* config/arm/neon.md (neon_vld3qa, neon_vld4qa): Remove
operand 1 and reshuffle the operands to match.
(neon_vld3, neon_vld4): Update accordingly.

Index: gcc/config/arm/neon.md
===
--- gcc/config/arm/neon.md  2011-03-24 13:47:13.0 +
+++ gcc/config/arm/neon.md  2011-03-24 15:51:59.0 +
@@ -4605,8 +4605,7 @@ (define_expand "neon_vld3"
 (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
"TARGET_NEON"
  {
-  emit_insn (gen_neon_vld3qa  (operands[0], operands[0],
-operands[1], operands[1]));
+  emit_insn (gen_neon_vld3qa  (operands[0], operands[1], operands[1]));
emit_insn (gen_neon_vld3qb  (operands[0], operands[0],
  operands[1], operands[1]));
DONE;
@@ -4614,12 +4613,11 @@ (define_expand "neon_vld3"

  (define_insn "neon_vld3qa"
[(set (match_operand:CI 0 "s_register_operand" "=w")
-(unspec:CI [(mem:CI (match_operand:SI 3 "s_register_operand" "2"))
-(match_operand:CI 1 "s_register_operand" "0")
+(unspec:CI [(mem:CI (match_operand:SI 2 "s_register_operand" "1"))
  (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
 UNSPEC_VLD3A))
-   (set (match_operand:SI 2 "s_register_operand" "=r")
-(plus:SI (match_dup 3)
+   (set (match_operand:SI 1 "s_register_operand" "=r")
+(plus:SI (match_dup 2)
 (const_int 24)))]
"TARGET_NEON"
  {
@@ -4628,7 +4626,7 @@ (define_insn "neon_vld3qa"
ops[0] = gen_rtx_REG (DImode, regno);
ops[1] = gen_rtx_REG (DImode, regno + 4);
ops[2] = gen_rtx_REG (DImode, regno + 8);
-  ops[3] = operands[2];
+  ops[3] = operands[1];
output_asm_insn ("vld3.\t{%P0, %P1, %P2}, [%3]!", ops);
return "";
  }
@@ -4897,8 +4895,7 @@ (define_expand "neon_vld4"
 (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
"TARGET_NEON"
  {
-  emit_insn (gen_neon_vld4qa  (operands[0], operands[0],
-operands[1], operands[1]));
+  emit_insn (gen_neon_vld4qa  (operands[0], operands[1], operands[1]));
emit_insn (gen_neon_vld4qb  (operands[0], operands[0],
  operands[1], operands[1]));
DONE;
@@ -4906,12 +4903,11 @@ (define_expand "neon_vld4"

  (define_insn "neon_vld4qa"
[(set (match_operand:XI 0 "s_register_operand" "=w")
-(unspec:XI [(mem:XI (match_operand:SI 3 "s_register_operand" "2"))
-(match_operand:XI 1 "s_register_operand" "0")
+(unspec:XI [(mem:XI (match_operand:SI 2 "s_register_operand" "1"))
  (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
 UNSPEC_VLD4A))
-   (set (match_operand:SI 2 "s_register_operand" "=r")
-(plus:SI (match_dup 3)
+   (set (match_operand:SI 1 "s_register_operand" "=r")
+(plus:SI (match_dup 2)
 (const_int 32)))]
"TARGET_NEON"
  {
@@ -4921,7 +4917,7 @@ (define_insn "neon_vld4qa"
ops[1] = gen_rtx_REG (DImode, regno + 4);
ops[2] = gen_rtx_REG (DImode, regno + 8);
ops[3] = gen_rtx_REG (DImode, regno + 12);
-  ops[4] = operands[2];
+  ops[4] = operands[1];
output_asm_insn ("vld4.\t{%P0, %P1, %P2, %P3}, [%4]!", ops);
return "";
  }

Continue toplevel cleanup (GCC library handling for unsupported targets etc.)

[Joseph S. Myers]

This patch continues cleaning up the toplevel configure.ac, in particular 
as regards cases handling GCC libraries for targets where GCC is no longer 
(or never was) supported.

The principle there, as discussed for the original deprecated targets 
removal patch, is that in the absence of GCC support for a target it 
doesn't matter exactly how toplevel is configured to build GCC libraries 
(or other GCC-related directories) for that target - builds will and 
should fail if GCC is included in the source tree - so toplevel 
configure.ac should be set up for maximal simplicity.  In most cases that 
means no explicit mention of GCC libraries for such a target; in some 
cases it means removing the target entry altogether so that another case 
becomes active instead (possibly the *-*-* case that disables libgcj 
only).

In general cases just disabling libgcj are redundant with the *-*-* case 
unless they prevent some other case being active for the target, and so 
are removed.  There were also a couple of removed cases for targets with 
no support in GCC or src at all (romp-*-*, vax-*-vms) - if there's no 
support in GCC or src, it's right that a build should fail trying to build 
whatever sources you have there, and silly for toplevel to try disabling 
everything because nothing is supported.

Other cleanups here: noconfigdirs="$noconfigdirs" is completely useless 
and was removed; c54x*-*-* is always mapped to tic54x-*-* by config.sub so 
that case can be simplified; cris*-*-none acts just like cris*-*-elf in 
config.gcc so it's appropriate to make the "*" subcase of cris*-*-* act 
like the -elf case; mmix-*-* disabled "libgloss", i.e. libgloss for the 
host, which is never built anyway.

OK to commit?

2011-03-29  Joseph Myers  

* configure.ac (*-*-chorusos): Don't disable libgcj.
(*-*-freebsd[[12]] | *-*-freebsd[[12]].* | *-*-freebsd*aout*):
Remove case.
(*-*-kaos*): Don't disable GCC libraries, zlib or fastjar.
(arm-*-coff): Don't disable libgcj.
(arm*-*-linux-gnueabi): Remove useless assignment.
(arm-*-riscix*): Don't disable libgcj.
(bfin-*-*): Don't enable target-bsp and target-cygmon depending on
configuration.
(c4x-*-* | tic4x-*-*): Don't disable GCC libraries.
(c54x*-*-*): Remove case.
(tic54x-*-*): Don't disable GCC or GCC libraries.
(cris-*-* | crisv32-*-*): Don't handle *-*-aout.  Change *-*-elf
to *.
(d10v-*-*): Don't disable GCC libraries.
(d30v-*-*): Don't disable libgcj.
(h8500-*-*): Don't disable GCC libraries.
(i960-*-*): Don't disable libgcj.
(i[[3456789]]86-*-linux*): Don't handle *-*-*libc1*.
(i[[3456789]]86-*-sco3.2v5*, i[[3456789]]86-*-sco*,
i[[3456789]]86-*-sysv4*, i[[3456789]]86-*-beos*): Don't disable
libgcj.
(m68k-*-coff*): Remove case.
(mmix-*-*): Don't disable libgloss on host.
(mn10200-*-*, mn10300-*-*): Remove cases.
(powerpc*-*-winnt* | powerpc*-*-pe*, powerpcle-*-solaris*,
powerpc-*-beos*, m68k-apollo-*, mips*-*-irix5*, mips*-*-bsd*):
Don't disable libgcj.
(romp-*-*): Remove case.
(sparclite-*-*, sparc-*-sunos4*): Don't disable libgcj.
(sparc-*-solaris2.[[0-6]] | sparc-*-solaris2.[[0-6]].*): Remove
case.
(v810-*-*): Don't disable GCC libraries.
(v850*-*-*, vax-*-vms, xtensa*-*-*): Remove cases.
(ip2k-*-*): Don't disable GCC libraries.
* configure: Regenerate.

Index: configure.ac
===
--- configure.ac(revision 171675)
+++ configure.ac(working copy)
@@ -521,7 +521,7 @@
 
 case "${target}" in
   *-*-chorusos)
-noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj}"
+noconfigdirs="$noconfigdirs target-newlib target-libgloss"
 ;;
   powerpc-*-darwin*)
 noconfigdirs="$noconfigdirs ld gas gdb gprof"
@@ -543,9 +543,6 @@
   *-*-dragonfly*)
 noconfigdirs="$noconfigdirs target-newlib target-libgloss"
 ;;
-  *-*-freebsd[[12]] | *-*-freebsd[[12]].* | *-*-freebsd*aout*)
-noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj}"
-;;
   *-*-freebsd*)
 noconfigdirs="$noconfigdirs target-newlib target-libgloss"
 if test "x$with_gmp" = x && test "x$with_gmp_dir" = x \
@@ -565,9 +562,7 @@
 ;;
   *-*-kaos*)
 # Remove unsupported stuff on all kaOS configurations.
-skipdirs="target-libiberty ${libgcj} target-libstdc++-v3"
-skipdirs="$skipdirs target-libobjc"
-skipdirs="$skipdirs zlib fastjar target-libjava target-boehm-gc 
target-zlib"
+skipdirs="target-libiberty"
 noconfigdirs="$noconfigdirs target-libgloss"
 ;;
   *-*-netbsd*)
@@ -636,7 +631,6 @@
 noconfigdirs="$noconfigdirs target-libgloss"
 ;;
   arm-*-coff)
-noconfigdirs="$noconfigdirs ${libgcj}"
 libgloss_dir=arm
 ;;
   arm-*-elf* | arm*-*-eabi* )
@@ -644,7 +638,6 @@
 

Re: [testsuite] Fix gcc.dg/torture/pr47917.c on IRIX 6.5

[Steve Ellcey]

On Tue, 2011-03-29 at 19:50 +0200, Rainer Orth wrote:

> /* { dg-options "-std=gnu99" { target *-*-hpux* } } */
> 
> Alternatively, the mips-sgi-irix6.5 variant might work, too.  Either
> patch is preapproved if this works for you.
> 
> Thanks.
>   Rainer

I went with the -std=gnu99 option.  Here is the final patch that I
tested and checked in:


2011-03-29  Steve Ellcey  

* gcc.dg/torture/pr47917.c: Use -std=gnu99 on HP-UX.


Index: gcc.dg/torture/pr47917.c
===
--- gcc.dg/torture/pr47917.c(revision 171649)
+++ gcc.dg/torture/pr47917.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-options "-std=c99" } */
 /* { dg-options "-std=c99 -D_XOPEN_SOURCE=500" { target mips-sgi-irix6.5 } } */
+/* { dg-options "-std=gnu99" { target *-*-hpux* } } */
 /* { dg-xfail-if "no C99 snprintf function" { *-*-hpux10* } } */
 /* { dg-xfail-run-if "non-conforming C99 snprintf" { *-*-hpux11.[012]* } } */



Steve Ellcey
s...@cup.hp.com

Re: [PING][PATCH, testsuite] Update gcc.dg/stack-usage-1.c SIZE values for powerpc

[Peter Bergner]

On Tue, 2011-03-29 at 13:20 -0700, Mike Stump wrote:
> On Mar 29, 2011, at 5:14 AM, Peter Bergner wrote:
> > Mike and David, I assume the updated patch below is ok for mainline?
> 
> Ok.  I applied it for you...  I'm assuming you don't have write after yet...  
> Thanks for all the work.

I do have svn write privs (for years now), but thanks! :)

Peter

Re: Continue toplevel cleanup (GCC library handling for unsupported targets etc.)

[Joseph S. Myers]

On Tue, 29 Mar 2011, Joseph S. Myers wrote:

> Other cleanups here:

Also: bfin-*-* had code relating to target-bsp and target-cygmon, but 
there is no actual Makefile.* support for building those, so the code 
relating to them in configure.ac is removed.

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

Re: [C++0x] Range-based for statements and ADL

[Jonathan Wakely]

On 29 March 2011 21:33, Rodrigo Rivas wrote:
> On Tue, Mar 29, 2011 at 8:22 PM, Jonathan Wakely  
> wrote:
>> How about "No suitable % and % functions found for range
>> expression of type %qT in % statement" ?
>
> Nice.
> But the problem here is that there are a lot of different error conditions:
> 1. begin member but not end member.
> 2. end member but not begin member.

I think these cases should say something like "invalid lookup results,
member 'begin' and non-member 'end'" (or vice versa) as we had in last
week's patch.

Or maybe it would be better to say "lookup for 'for' found member
'begin' but no member 'end'"

> 3. begin and end member but one or both are not callable/accesible/whatever.

I would definitely want to get an "access denied", "deleted function"
etc. error for that case.

> 3. no begin/end members, a begin global function but not end.
> 4. no begin/end members, an end global function but not begin.

Maybe something similar to the text I suggested above, but only
mentioning the lookup that failed, "no suitable 'begin' found for
range expression ..."

> 5. no begin/end members, begin and end functions but one or both not
> callable/wrong overload/etc.

In some cases I would probably want to know the actual error, not just
"cannot use range-based for"

If a begin() is found but can't be called, showing the "candidates
are..." list might be helpful to see the problem e.g. if
my::begin(my::type&) can't be called for const my::type.

> 6. no begin/end members, no begin/end global functions. Since the
> standard headers have the std::begin/std::end templates, this will not
> happen when you include (most) STL headers.

Maybe this is the only case where the text I suggested is useful, I
think a special "can't use range-based for" makes sense in this case,
instead of "begin not declared in this scope"

> What is the best message for each? Does it make sense to have up to 6
> different messages? Too many?

It would be nice for users, but it's certainly more work, and
potentially more places for bugs to creep in.

Re: Cleaning up expand optabs code

[Richard Sandiford]

Mikael Pettersson  writes:
>  > gcc/
>  >PR rtl-optimization/48332
>  >* optabs.c (expand_binop_directly): Set xmodeN to the target-mandated
>  >mode of input operand N and modeN to its actual mode.
>
> Thanks, this allowed me to build gcc-4.7 as a cross to m68k-linux again.

Good to hear, thanks for testing.

> I'm starting a native bootstrap of gcc-4.7 head + this fix on m68k, but
> that will take about 5 days to complete...

Ouch.

Hopefully this time I've finally got it right.  Bootstrapped &
regression-tested on x86_64-linux-gnu.  OK to install?

Richard

>  > 
>  > Index: gcc/optabs.c
>  > ===
>  > --- gcc/optabs.c   2011-03-24 17:23:05.0 +
>  > +++ gcc/optabs.c   2011-03-29 14:18:02.0 +0100
>  > @@ -1243,9 +1243,9 @@ expand_binop_directly (enum machine_mode
>  >   rtx last)
>  >  {
>  >enum insn_code icode = optab_handler (binoptab, mode);
>  > -  enum machine_mode mode0 = insn_data[(int) icode].operand[1].mode;
>  > -  enum machine_mode mode1 = insn_data[(int) icode].operand[2].mode;
>  > -  enum machine_mode tmp_mode;
>  > +  enum machine_mode xmode0 = insn_data[(int) icode].operand[1].mode;
>  > +  enum machine_mode xmode1 = insn_data[(int) icode].operand[2].mode;
>  > +  enum machine_mode mode0, mode1, tmp_mode;
>  >struct expand_operand ops[3];
>  >bool commutative_p;
>  >rtx pat;
>  > @@ -1256,8 +1256,8 @@ expand_binop_directly (enum machine_mode
>  >   if we would swap the operands, we can save the conversions.  */
>  >commutative_p = commutative_optab_p (binoptab);
>  >if (commutative_p
>  > -  && GET_MODE (xop0) != mode0 && GET_MODE (xop1) != mode1
>  > -  && GET_MODE (xop0) == mode1 && GET_MODE (xop1) == mode1)
>  > +  && GET_MODE (xop0) != xmode0 && GET_MODE (xop1) != xmode1
>  > +  && GET_MODE (xop0) == xmode1 && GET_MODE (xop1) == xmode1)
>  >  {
>  >swap = xop0;
>  >xop0 = xop1;
>  > @@ -1265,9 +1265,9 @@ expand_binop_directly (enum machine_mode
>  >  }
>  >  
>  >/* If we are optimizing, force expensive constants into a register.  */
>  > -  xop0 = avoid_expensive_constant (mode0, binoptab, xop0, unsignedp);
>  > +  xop0 = avoid_expensive_constant (xmode0, binoptab, xop0, unsignedp);
>  >if (!shift_optab_p (binoptab))
>  > -xop1 = avoid_expensive_constant (mode1, binoptab, xop1, unsignedp);
>  > +xop1 = avoid_expensive_constant (xmode1, binoptab, xop1, unsignedp);
>  >  
>  >/* In case the insn wants input operands in modes different from
>  >   those of the actual operands, convert the operands.  It would
>  > @@ -1275,19 +1275,19 @@ expand_binop_directly (enum machine_mode
>  >   that they're properly zero-extended, sign-extended or truncated
>  >   for their mode.  */
>  >  
>  > -  if (GET_MODE (xop0) != mode0 && mode0 != VOIDmode)
>  > -xop0 = convert_modes (mode0,
>  > -GET_MODE (xop0) != VOIDmode
>  > -? GET_MODE (xop0)
>  > -: mode,
>  > -xop0, unsignedp);
>  > -
>  > -  if (GET_MODE (xop1) != mode1 && mode1 != VOIDmode)
>  > -xop1 = convert_modes (mode1,
>  > -GET_MODE (xop1) != VOIDmode
>  > -? GET_MODE (xop1)
>  > -: mode,
>  > -xop1, unsignedp);
>  > +  mode0 = GET_MODE (xop0) != VOIDmode ? GET_MODE (xop0) : mode;
>  > +  if (xmode0 != VOIDmode && xmode0 != mode0)
>  > +{
>  > +  xop0 = convert_modes (xmode0, mode0, xop0, unsignedp);
>  > +  mode0 = xmode0;
>  > +}
>  > +
>  > +  mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
>  > +  if (xmode1 != VOIDmode && xmode1 != mode1)
>  > +{
>  > +  xop1 = convert_modes (xmode1, mode1, xop1, unsignedp);
>  > +  mode1 = xmode1;
>  > +}
>  >  
>  >/* If operation is commutative,
>  >   try to make the first operand a register.
>  > 

Re: Cleaning up expand optabs code

[Richard Henderson]

On 03/29/2011 06:21 AM, Richard Sandiford wrote:
> -  enum machine_mode mode0 = insn_data[(int) icode].operand[1].mode;
> -  enum machine_mode mode1 = insn_data[(int) icode].operand[2].mode;
> -  enum machine_mode tmp_mode;
> +  enum machine_mode xmode0 = insn_data[(int) icode].operand[1].mode;
> +  enum machine_mode xmode1 = insn_data[(int) icode].operand[2].mode;
> +  enum machine_mode mode0, mode1, tmp_mode;
...
> -  if (GET_MODE (xop0) != mode0 && mode0 != VOIDmode)
> -xop0 = convert_modes (mode0,
> -   GET_MODE (xop0) != VOIDmode
> -   ? GET_MODE (xop0)
> -   : mode,
> -   xop0, unsignedp);
> -
> -  if (GET_MODE (xop1) != mode1 && mode1 != VOIDmode)
> -xop1 = convert_modes (mode1,
> -   GET_MODE (xop1) != VOIDmode
> -   ? GET_MODE (xop1)
> -   : mode,
> -   xop1, unsignedp);
> +  mode0 = GET_MODE (xop0) != VOIDmode ? GET_MODE (xop0) : mode;
> +  if (xmode0 != VOIDmode && xmode0 != mode0)
> +{
> +  xop0 = convert_modes (xmode0, mode0, xop0, unsignedp);
> +  mode0 = xmode0;
> +}
> +
> +  mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
> +  if (xmode1 != VOIDmode && xmode1 != mode1)
> +{
> +  xop1 = convert_modes (xmode1, mode1, xop1, unsignedp);
> +  mode1 = xmode1;
> +}

This smells like a target bug, but I can't quite put my finger
on exactly what's wrong, and I haven't debugged the original.

The backend has said xmode[01] is what it expects.  The only
reason you wouldn't write xmode[01] in the create_input_operand
line is if xmode[01] are VOIDmode.

That seems like mistake number one, particularly for a binop,
but I'll accept that for the nonce.  Which pattern triggered
the problem in the target?

Then we've got the conditionalization in the init of mode[01],
which is presumably to handle CONST_INT as an input.

What about something like

xmode0 = insn_data...
if (xmode0 == VOIDmode)
  xmode0 = mode;

mode0 = GET_MODE (xop0);
if (mode0 == VOIDmode)
  mode0 = mode;

if (xmode0 != mode0)
  convert_modes

create_input_operand(..., xmode0)

?  That seems more obvious than what you have.  And I *think*
it should produce the same results.  If it doesn't, then this
whole block of code needs a lot more explanation.


r~

Make option flags consistently unsigned

[Joseph S. Myers]

This patch makes variables, fields, parameters and macros used for
command-line option flags consistently unsigned.  In most places they
were already unsigned, but the CL_* values themselves were signed and
some other places used signed int for flags.

As noted in 
this makes bit 31 available for use for another flag (1U << 31 is more
appropriate than 1 << 31, which is not defined in ISO C).  It is
logically right for such a collection of flags to be unsigned, but it
will be necessary soon to follow up by splitting this field.  (I have
two uses of flag bits I expect to add soon: one to say that an
option's argument is case-insensitive, one to indicate that an option
is an alias for the negative form of another option.)

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  Applied
to mainline.

2011-03-29  Joseph Myers  

* lto-opts.c (register_user_option_p, lto_register_user_option):
Make type argument unsigned.
* lto-streamer.h (lto_register_user_option): Make type argument
unsigned.
* opth-gen.awk: Make CL_* macros unsigned.
* opts-common.c (find_opt): Make lang_mask argument unsigned.
* opts.h (CL_PARAMS, CL_WARNING, CL_OPTIMIZATION, CL_DRIVER,
CL_TARGET, CL_COMMON, CL_SEPARATE_NARGS_MASK, CL_SEPARATE_ALIAS,
CL_NO_DRIVER_ARG, CL_REJECT_DRIVER, CL_SAVE, CL_DISABLED,
CL_REPORT, CL_JOINED, CL_SEPARATE, CL_REJECT_NEGATIVE,
CL_MISSING_OK, CL_UINTEGER, CL_UNDOCUMENTED): Make unsigned.
(find_opt): Make lang_mask argument unsigned.

Index: opts-common.c
===
--- opts-common.c   (revision 171675)
+++ opts-common.c   (working copy)
@@ -1,5 +1,5 @@
 /* Command line option handling.
-   Copyright (C) 2006, 2007, 2008, 2010 Free Software Foundation, Inc.
+   Copyright (C) 2006, 2007, 2008, 2010, 2011 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -52,7 +52,7 @@ static void prune_options (struct cl_dec
front end, the longest match for a different front end is returned
(or N_OPTS if none) and the caller emits an error message.  */
 size_t
-find_opt (const char *input, int lang_mask)
+find_opt (const char *input, unsigned int lang_mask)
 {
   size_t mn, mn_orig, mx, md, opt_len;
   size_t match_wrong_lang;
Index: opts.h
===
--- opts.h  (revision 171675)
+++ opts.h  (working copy)
@@ -1,5 +1,5 @@
 /* Command line option handling.
-   Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010
+   Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010, 2011
Free Software Foundation, Inc.
 
 This file is part of GCC.
@@ -83,12 +83,12 @@ extern const unsigned int cl_options_cou
 extern const char *const lang_names[];
 extern const unsigned int cl_lang_count;
 
-#define CL_PARAMS   (1 << 11) /* Fake entry.  Used to display 
--param info with --help.  */
-#define CL_WARNING (1 << 12) /* Enables an (optional) warning 
message.  */
-#define CL_OPTIMIZATION(1 << 13) /* Enables an (optional) 
optimization.  */
-#define CL_DRIVER  (1 << 14) /* Driver option.  */
-#define CL_TARGET  (1 << 15) /* Target-specific option.  */
-#define CL_COMMON  (1 << 16) /* Language-independent.  */
+#define CL_PARAMS   (1U << 11) /* Fake entry.  Used to display 
--param info with --help.  */
+#define CL_WARNING (1U << 12) /* Enables an (optional) warning 
message.  */
+#define CL_OPTIMIZATION(1U << 13) /* Enables an (optional) 
optimization.  */
+#define CL_DRIVER  (1U << 14) /* Driver option.  */
+#define CL_TARGET  (1U << 15) /* Target-specific option.  */
+#define CL_COMMON  (1U << 16) /* Language-independent.  */
 
 #define CL_MIN_OPTION_CLASSCL_PARAMS
 #define CL_MAX_OPTION_CLASSCL_COMMON
@@ -101,20 +101,20 @@ extern const unsigned int cl_lang_count;
 /* Options marked with CL_SEPARATE take a number of separate arguments
(1 to 4) that is one more than the number in this bit-field.  */
 #define CL_SEPARATE_NARGS_SHIFT17
-#define CL_SEPARATE_NARGS_MASK (3 << CL_SEPARATE_NARGS_SHIFT)
+#define CL_SEPARATE_NARGS_MASK (3U << CL_SEPARATE_NARGS_SHIFT)
 
-#define CL_SEPARATE_ALIAS  (1 << 19) /* Option is an alias when used with 
separate argument.  */
-#define CL_NO_DRIVER_ARG   (1 << 20) /* Option takes no argument in the 
driver.  */
-#define CL_REJECT_DRIVER   (1 << 21) /* Reject this option in the driver.  
*/
-#define CL_SAVE(1 << 22) /* Target-specific option for 
attribute.  */
-#define CL_DISABLED(1 << 23) /* Disabled in this configuration.  */
-#define CL_REPORT  (1 << 24) /* Report argument with -fverbose-asm 
 */
-#define CL_JOINED  (1 << 25) /* If takes joined arg

Re: Restore SPARC bootstrap (PR bootstrap/48337)

[Eric Botcazou]

> I'm now into stage 3 on sparc-sun-solaris2.11, ok for mainline once that
> is completed?  I don't expect problems for the target libraries and would
> like to restore bootstrap ASAP.

IMO this was on the obvious side, but...

> 2011-03-29  Joseph Myers  
>   Rainer Orth  
>
>   PR bootstrap/48337
>   * config/sparc/sparc.opt (sparc_cpu_and_features): Add
>   Init(PROCESSOR_V7).
>   (sparc_cpu): Likewise.
>   * config/sparc/sparc.c (sparc_option_override): Replace 0 by
>   PROCESSOR_V7.

...OK, thanks.

-- 
Eric Botcazou

Re: [C++0x] Range-based for statements and ADL

[Rodrigo Rivas]

On Tue, Mar 29, 2011 at 11:13 PM, Jonathan Wakely  wrote:
Thank you for your suggestions!
IMO, error cases 3 (hey, two 3s!), 4 and 6 are not so likely, as
including any STL container header will make a begin and an end
functions declared, though maybe not usabe. In these cases the most
probable error case would be 5.

> It would be nice for users, but it's certainly more work, and
> potentially more places for bugs to creep in.
Yeah, you're right. I think I'll leave that for a future patch...

Rodrigo

Re: [PATCH, ARM] PR47855 Compute attr "length" for some thumb2 insns

[Ramana Radhakrishnan]

Hi Carrot,

On 26/03/11 15:14, Carrot Wei wrote:

Index: arm.md
===
--- arm.md  (revision 171337)
+++ arm.md  (working copy)
@@ -7115,7 +7115,18 @@
"@
 cmp%?\\t%0, %1
 cmn%?\\t%0, #%n1"
-  [(set_attr "conds" "set")]
+  [(set_attr "conds" "set")
+   (set (attr "length")
+ (if_then_else
+   (and (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
+(eq (symbol_ref "which_alternative") (const_int 0)))
+   (ior (ne (symbol_ref "REG_P (operands[1])") (const_int 0))
+   (and (ne (symbol_ref "CONST_INT_P (operands[1])") (const_int 0))
+(and (ge (symbol_ref "INTVAL (operands[1])") (const_int 0))
+ (le (symbol_ref "INTVAL (operands[1])")
+ (const_int 255))
+   (const_int 2)
+   (const_int 4)))]
  )


	How about adding an alternative only enabled for T2 that uses the `l' 
constraint and inventing new constraints for some of the constant values 
that are valid for 16 bit instructions since the `I' and `L' constraints 
have different meanings depending on whether TARGET_32BIT is valid or 
not ? We could then set the value of the length attribute accordingly. I 
don't think we can change the meaning of the I and L constraints very 
easily given the amount of churn that might be needed





  (define_insn "*cmpsi_shiftsi"
@@ -7286,7 +7297,14 @@
return \"b%d1\\t%l0\";
"
[(set_attr "conds" "use")
-   (set_attr "type" "branch")]
+   (set_attr "type" "branch")
+   (set (attr "length")
+   (if_then_else
+  (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
+   (and (ge (minus (match_dup 0) (pc)) (const_int -250))
+(le (minus (match_dup 0) (pc)) (const_int 256
+  (const_int 2)
+  (const_int 4)))]
  )


	I don't think this and the other conditional branch instruction changes 
are correct. This could end up being the last instruction in an IT block 
and will automatically end up getting the 32 bit encoding and end up 
causing trouble with the length calculations. Remember the 16 bit 
encoding for the conditional instruction can't be used as the last 
instruction in an IT block.




@@ -10256,7 +10288,26 @@

  return \"\";
}"
-  [(set_attr "type" "store4")]
+  [(set_attr "type" "store4")
+   (set (attr "length")
+   (if_then_else
+  (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
+   (ne (symbol_ref "{
+   int i, regno, hi_reg;
+   int num_saves = XVECLEN (operands[2], 0);
+   regno = REGNO (operands[1]);
+   hi_reg = (REGNO_REG_CLASS (regno) == HI_REGS)
+   &&  (regno != LR_REGNUM);
+   for (i = 1; i<  num_saves; i++)



	(i < num_saves && (hi_reg == 0)) - what's the point of going through 
the register list when hi_reg != 0 in this case ? A comment to explain 
that the length calculation *must* be kept in sync with the template 
above might be useful.


cheers
Ramana

PR bootstrap/48327

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


The underlying problem here is a botched update of a PHI argument when
we thread all incoming edges for a particular block.

In that case we used to use the original block as the template block
which saved a little bit of memory at the expense of slightly more
complex SSA updating.

However, after looking a some of the changes over the last few years to
tree-ssa-threadupdate.c, I'm not sure that's safe anymore.  Furthermore,
the SSA graph updating code was going to need another hack to deal with
the case where we thread deeper into the CFG.

Rather than try to make those two things work, it's easier to just
delete all the code which tried to reuse the soon-to-be-unreachable
block.  I like it when removing code fixes bugs.

Installed after a bootstrap and regression test cycle (including Ada
bootstrapping which triggered the bug report).


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNkmNNAAoJEBRtltQi2kC7d8EH/0XN0oGPYrRFwnuHjD3TjaT8
361rgDyakOGwD3JVRYE2xte/aDXAJQYTk46DazoCZtL1Q5H4R7HIH0nsy380Qvg6
amJmCBGDItGdYOCVwny0cRQJf3QgDfCn69GNAaDuE2myM8cUz0H9Mr5uuB+chCFY
1EUyDVRk9hWY72FxZ1drADXD4ROtxhEwipcCXj6a67jGd0WnWMgLyxMVdYiJ5oRw
ezoL1rxwMABTJKM1blG38Osl8xU1SZuIzpctR7RTcdXYc6ZTe39bY9ysHmRHHDGi
M35mZMEw6DtAjKnYBSjDzw513fHUip/qkqeH4rIjSAwCSW4XIemJ3eEQPF7Kb84=
=vXqW
-END PGP SIGNATURE-
* tree-ssa-threadupdate.c (struct redirection_data): Remove
do_not_duplicate field.
(lookup_redirection_data): Corresponding changes.
(create_duplicates): Always create a template block.
(redirect_edges): Remove code which reused the original block
when it was going to become unreachable code.
(thread_block): Don't set do_not_duplicate field.

Index: tree-ssa-threadupdate.c
===
*** tree-ssa-threadupdate.c (revision 171692)
--- tree-ssa-threadupdate.c (working copy)
*** along with GCC; see the file COPYING3.  
*** 69,77 
  
 Note that block duplication can be minimized by first collecting the
 set of unique destination blocks that the incoming edges should
!be threaded to.  Block duplication can be further minimized by using
!B instead of creating B' for one destination if all edges into B are
!going to be threaded to a successor of B.
  
 We further reduce the number of edges and statements we create by
 not copying all the outgoing edges and the control statement in
--- 69,84 
  
 Note that block duplication can be minimized by first collecting the
 set of unique destination blocks that the incoming edges should
!be threaded to.
! 
!Block duplication can be further minimized by using B instead of 
!creating B' for one destination if all edges into B are going to be
!threaded to a successor of B.  We had code to do this at one time, but
!I'm not convinced it is correct with the changes to avoid mucking up
!the loop structure (which may cancel threading requests, thus a block
!which we thought was going to become unreachable may still be reachable).
!This code was also going to get ugly with the introduction of the ability
!for a single jump thread request to bypass multiple blocks. 
  
 We further reduce the number of edges and statements we create by
 not copying all the outgoing edges and the control statement in
*** struct redirection_data
*** 117,127 
/* A list of incoming edges which we want to thread to
   OUTGOING_EDGE->dest.  */
struct el *incoming_edges;
- 
-   /* Flag indicating whether or not we should create a duplicate block
-  for this thread destination.  This is only true if we are threading
-  all incoming edges and thus are using BB itself as a duplicate block.  */
-   bool do_not_duplicate;
  };
  
  /* Main data structure to hold information for duplicates of BB.  */
--- 124,129 
*** lookup_redirection_data (edge e, edge in
*** 249,255 
elt = XNEW (struct redirection_data);
elt->outgoing_edge = e;
elt->dup_block = NULL;
-   elt->do_not_duplicate = false;
elt->incoming_edges = NULL;
  
slot = htab_find_slot (redirection_data, elt, insert);
--- 251,256 
*** create_duplicates (void **slot, void *da
*** 338,348 
struct redirection_data *rd = (struct redirection_data *) *slot;
struct local_info *local_info = (struct local_info *)data;
  
-   /* If this entry should not have a duplicate created, then there's
-  nothing to do.  */
-   if (rd->do_not_duplicate)
- return 1;
- 
/* Create a template block if we have not done so already.  Otherwise
   use the template to create a new block.  */
if (local_info->template_block == NULL)
--- 339,344 
*** redirect_edges (void **slot, void *data)
*** 433,463 
  

RFA: patch to solve IRA PR48336, PR48342, PR48345

[Vladimir Makarov]

The following patch is to solve PR48336, PR48342, PR48345.  The 
profitable hard regs exclude hard regs which are prohibited for the 
corresponding allocno mode. It is true for primary allocation and it is 
important for better colorability criteria.  Function assign_hard_reg is 
also based on this assumption.  Unfortunately, it is not true for 
secondary allocation (after IRA IR flattening or during reload).  The 
following patch solves this problem.


The patch should be very safe but I am still testing it on x86/x86-64 
bootstrap.


Is it ok to commit the patch after successful bootsrapping?

2011-03-29  Vladimir Makarov 

PR target/48336
PR middle-end/4834
PR rtl-optimization/48345
* ira-color.c (setup_conflict_profitable_regs): Exclude prohibited
hard regs for given mode from profitable regs when doing secondary
allocation.

Index: ira-color.c
===
--- ira-color.c (revision 171699)
+++ ira-color.c (working copy)
@@ -1447,7 +1447,9 @@ update_conflict_hard_regno_costs (int *c
 }
 
 /* Set up conflicting and profitable regs (through CONFLICT_REGS and
-   PROFITABLE_REGS) for each object of allocno A.  */
+   PROFITABLE_REGS) for each object of allocno A.  Remember that the
+   profitable regs exclude hard regs which can not hold value of mode
+   of allocno A.  */
 static inline void
 setup_conflict_profitable_regs (ira_allocno_t a, bool retry_p,
HARD_REG_SET *conflict_regs,
@@ -1463,8 +1465,13 @@ setup_conflict_profitable_regs (ira_allo
   COPY_HARD_REG_SET (conflict_regs[i],
 OBJECT_TOTAL_CONFLICT_HARD_REGS (obj));
   if (retry_p)
-   COPY_HARD_REG_SET (profitable_regs[i],
-  reg_class_contents[ALLOCNO_CLASS (a)]);
+   {
+ COPY_HARD_REG_SET (profitable_regs[i],
+reg_class_contents[ALLOCNO_CLASS (a)]);
+ AND_COMPL_HARD_REG_SET (profitable_regs[i],
+ ira_prohibited_class_mode_regs
+ [ALLOCNO_CLASS (a)][ALLOCNO_MODE (a)]);
+   }
   else
COPY_HARD_REG_SET (profitable_regs[i],
   OBJECT_COLOR_DATA (obj)->profitable_hard_regs);

Re: RFA: patch to solve IRA PR48336, PR48342, PR48345

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/29/11 19:28, Vladimir Makarov wrote:
> The following patch is to solve PR48336, PR48342, PR48345.  The
> profitable hard regs exclude hard regs which are prohibited for the
> corresponding allocno mode. It is true for primary allocation and it is
> important for better colorability criteria.  Function assign_hard_reg is
> also based on this assumption.  Unfortunately, it is not true for
> secondary allocation (after IRA IR flattening or during reload).  The
> following patch solves this problem.
> 
> The patch should be very safe but I am still testing it on x86/x86-64
> bootstrap.
> 
> Is it ok to commit the patch after successful bootsrapping?
> 
> 2011-03-29  Vladimir Makarov 
> 
> PR target/48336
> PR middle-end/4834
> PR rtl-optimization/48345
> * ira-color.c (setup_conflict_profitable_regs): Exclude prohibited
> hard regs for given mode from profitable regs when doing secondary
> allocation.
This is OK.  Note the PR# in the ChangeLog (4834) should be (48342).

jeff

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNkomDAAoJEBRtltQi2kC7njQH/1GxaAuxFEZkYx8YdcYj//+c
XyfW2qV0wC91w2GIlpX45zzZnINo5dySAIRerWxkv1dI4ycaxTcYyoWyZRWWUWHQ
mKMYUZM8hmEdnNG/fur481cYo3lP45NmGzGFS5/lxyBJZXBaPk2gUJvYzLPFz/as
4ZJg3c5d05rw/1MdPOFwnKdzxk1TPciF7RP8uhFrEe1Uu8QyRf8ebtnpNyk93uF7
Z4/GafUBaSvYt/usRH4mijICE2cdMNrLq2S4A/RtQBhlOPvwSppIl3rT0kQnjAmw
EUAXXGuKuHLEblzk1dVWpWvwMBXnw93qxSD+vkEbDFtcwzJqh5rqFJbVw4S/TQk=
=Mkxi
-END PGP SIGNATURE-

Re: RFA: patch to solve IRA PR48336, PR48342, PR48345

[Hans-Peter Nilsson]

On Tue, 29 Mar 2011, Vladimir Makarov wrote:
> 2011-03-29  Vladimir Makarov 
>
> PR target/48336
> PR middle-end/4834

(A typo here, 48342.  Or maybe also needed for 48334?)

> PR rtl-optimization/48345
> * ira-color.c (setup_conflict_profitable_regs): Exclude prohibited
> hard regs for given mode from profitable regs when doing secondary
> allocation.

FWIW, I have a five regressions for cris-elf too appearing at
that RA change, but as they're wrong-code and noticed only at
execution, I'm going to wait analyzing further until this is
committed and caught by my autotester.  Just a heads-up.

brgds, H-P
PS. thanks for sticking to such a high-bug-profile task. ;)

C++ PATCH for c++/48265 (ICE with variable used in its own initializer)

[Jason Merrill]

We were infinitely recursing in value_dependent_expression_p.  As it 
happens, we're already doing the heavy lifting for determining whether 
or not a potentially constant variable has a constant initializer, so we 
can just use decl_constant_var_p here.


Tested x86_64-pc-linux-gnu, applied to trunk and 4.6.
commit 5f044d8e087ad43de99c062fea1ed58398f6f977
Author: Jason Merrill 
Date:   Tue Mar 29 15:05:27 2011 -0400

PR c++/48265
* pt.c (value_dependent_expression_p) [VAR_DECL]: Make sure
the variable is constant before looking at its initializer.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index da9365f..e716ca6 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18085,10 +18085,10 @@ value_dependent_expression_p (tree expression)
   return value_dependent_expression_p (DECL_INITIAL (expression));
 
 case VAR_DECL:
-   /* A constant with integral or enumeration type and is initialized
+   /* A constant with literal type and is initialized
  with an expression that is value-dependent.  */
   if (DECL_INITIAL (expression)
- && INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (expression))
+ && decl_constant_var_p (expression)
  && value_dependent_expression_p (DECL_INITIAL (expression)))
return true;
   return false;
diff --git a/gcc/testsuite/g++.dg/cpp0x/regress/value-dep1.C 
b/gcc/testsuite/g++.dg/cpp0x/regress/value-dep1.C
new file mode 100644
index 000..112389d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/regress/value-dep1.C
@@ -0,0 +1,7 @@
+// PR c++/48265
+// { dg-options -std=c++0x }
+
+template < int > struct S
+{
+  S () { const int i = i; i; };
+};

Merged mainline to gccgo branch

[Ian Lance Taylor]

I merged revsion mainline revision 171700 to the gccgo branch.

Ian

Re: [PATCH, ARM] PR47855 Compute attr "length" for some thumb2 insns

[Chung-Lin Tang]

On 2011/3/30 06:35 AM, Ramana Radhakrishnan wrote:
> Hi Carrot,
> 
> On 26/03/11 15:14, Carrot Wei wrote:
>> Index: arm.md
>> ===
>> --- arm.md(revision 171337)
>> +++ arm.md(working copy)
>> @@ -7115,7 +7115,18 @@
>> "@
>>  cmp%?\\t%0, %1
>>  cmn%?\\t%0, #%n1"
>> -  [(set_attr "conds" "set")]
>> +  [(set_attr "conds" "set")
>> +   (set (attr "length")
>> + (if_then_else
>> +   (and (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
>> + (eq (symbol_ref "which_alternative") (const_int 0)))
>> +(ior (ne (symbol_ref "REG_P (operands[1])") (const_int 0))
>> +(and (ne (symbol_ref "CONST_INT_P (operands[1])") (const_int 0))
>> + (and (ge (symbol_ref "INTVAL (operands[1])") (const_int 0))
>> +  (le (symbol_ref "INTVAL (operands[1])")
>> +  (const_int 255))
>> +   (const_int 2)
>> +   (const_int 4)))]
>>   )
> 
> How about adding an alternative only enabled for T2 that uses the
> `l' constraint and inventing new constraints for some of the constant
> values that are valid for 16 bit instructions since the `I' and `L'
> constraints have different meanings depending on whether TARGET_32BIT is
> valid or not ? We could then set the value of the length attribute
> accordingly. I don't think we can change the meaning of the I and L
> constraints very easily given the amount of churn that might be needed
> 
> 
>>
>>   (define_insn "*cmpsi_shiftsi"
>> @@ -7286,7 +7297,14 @@
>> return \"b%d1\\t%l0\";
>> "
>> [(set_attr "conds" "use")
>> -   (set_attr "type" "branch")]
>> +   (set_attr "type" "branch")
>> +   (set (attr "length")
>> +(if_then_else
>> +   (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
>> +(and (ge (minus (match_dup 0) (pc)) (const_int -250))
>> + (le (minus (match_dup 0) (pc)) (const_int 256
>> +   (const_int 2)
>> +   (const_int 4)))]
>>   )
> 
> I don't think this and the other conditional branch instruction
> changes are correct. This could end up being the last instruction in an
> IT block and will automatically end up getting the 32 bit encoding and
> end up causing trouble with the length calculations. Remember the 16 bit
> encoding for the conditional instruction can't be used as the last
> instruction in an IT block.
> 
> 
>> @@ -10256,7 +10288,26 @@
>>
>>   return \"\";
>> }"
>> -  [(set_attr "type" "store4")]
>> +  [(set_attr "type" "store4")
>> +   (set (attr "length")
>> +(if_then_else
>> +   (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
>> +(ne (symbol_ref "{
>> +int i, regno, hi_reg;
>> +int num_saves = XVECLEN (operands[2], 0);
>> +regno = REGNO (operands[1]);
>> +hi_reg = (REGNO_REG_CLASS (regno) == HI_REGS)
>> +&&  (regno != LR_REGNUM);
>> +for (i = 1; i<  num_saves; i++)
> 
> 
> (i < num_saves && (hi_reg == 0)) - what's the point of going through
> the register list when hi_reg != 0 in this case ? A comment to explain
> that the length calculation *must* be kept in sync with the template
> above might be useful.

I suggest abstracting all of this Thumb-2 insn length knowledge into a
arm.c function, say "thumb2_16bit_insn_p()" to test for 2-byte patterns.
 Adding more of these quite large pieces of logic into arm.md does not
look very pretty to me, and centralizing it into a C function will also
make it easier to manage the cases.

Chung-Lin

Re: Continue toplevel cleanup (GCC library handling for unsupported targets etc.)

[Ralf Wildenhues]

* Joseph S. Myers wrote on Tue, Mar 29, 2011 at 10:55:41PM CEST:
> --- configure.ac  (revision 171675)
> +++ configure.ac  (working copy)

> @@ -565,9 +562,7 @@
>  ;;
>*-*-kaos*)
>  # Remove unsupported stuff on all kaOS configurations.
> -skipdirs="target-libiberty ${libgcj} target-libstdc++-v3"
> -skipdirs="$skipdirs target-libobjc"
> -skipdirs="$skipdirs zlib fastjar target-libjava target-boehm-gc 
> target-zlib"
> +skipdirs="target-libiberty"

This error existed before your patch, but it might be a good idea to fix
it while at it: skipdirs should only be appended to here, not
overridden.

>  noconfigdirs="$noconfigdirs target-libgloss"
>  ;;
>*-*-netbsd*)

Other than that, I don't see issues with the patch; but again, I'm not
really qualified to judge CPU portability issues.

Thanks,
Ralf