Re: sparc bootstrap still broken

2012-11-20 Thread David Miller
From: Konstantin Serebryany 
Date: Tue, 20 Nov 2012 11:41:03 +0400

> Ok. Will this work?
> 
> // Are we using 32-bit or 64-bit syscalls?
> // x32 (which defines __x86_64__) has __WORDSIZE == 32
> // but it still needs to use 64-bit syscalls.
> #if defined(__x86_64__) || __WORDSIZE == 64
> # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
> #else
> # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 0
> #endif

Of course, as it matches the test H.J. Liu's patch used.

Please, at a bare minimum, give him some credit for this fix.


Re: [5/8] Tweak bitfield alignment handling

2012-11-20 Thread Mikael Pettersson
John David Anglin writes:
 > On Sun, 18 Nov 2012, Richard Sandiford wrote:
 > 
 > >HOST_WIDE_INT start = bitpos_ - (bitpos_ % unit);
 > >if (bitregion_start_ && start < bitregion_start_)
 > >break;
 > > -  if (bitregion_end_ && start + unit > bitregion_end_ + 1)
 > > +  if (start + unit > bitregion_end_ + 1)
 > 
 > This causes:
 > 
 > /home/dave/gnu/gcc/objdir/./prev-gcc/g++ 
 > -B/home/dave/gnu/gcc/objdir/./prev-gcc/ 
 > -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/bin/ -nostdinc++ 
 > -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs 
 > -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
 > -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
 >  -I/home/dave/gnu/gcc
 > /objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
 > -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ 
 > -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/sr
 > c/.libs 
 > -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
 > -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tabl
 > es -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
 > -Wmissing-format-attribut
 > e -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
 > -Werror 
 > -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
 > -I../../g
 > cc/gcc/../include -I../../gcc/gcc/../libcpp/include  
 > -I../../gcc/gcc/../libdecnu
 > mber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
 > -I../../gcc/gcc/../li
 > bbacktrace../../gcc/gcc/stor-layout.c -o 
 > stor-layout.o../../gcc/gcc/stor-layout.c: In member function 〘bool 
 > bit_field_mode_iterator::n
 > ext_mode(machine_mode*)〙:
 > ../../gcc/gcc/stor-layout.c:2690:43: error: comparison between signed and 
 > unsign
 > ed integer expressions [-Werror=sign-compare]
 >if (start + unit > bitregion_end_ + 1)
 > ^
 > cc1plus: all warnings being treated as errors

This error also breaks m68k-linux bootstrap.

HWI32 issue?


Re: sparc bootstrap still broken

2012-11-20 Thread Konstantin Serebryany
Done: http://llvm.org/viewvc/llvm-project?rev=168358&view=rev

On Tue, Nov 20, 2012 at 12:19 PM, David Miller  wrote:
> From: Konstantin Serebryany 
> Date: Tue, 20 Nov 2012 11:41:03 +0400
>
>> Ok. Will this work?
>>
>> // Are we using 32-bit or 64-bit syscalls?
>> // x32 (which defines __x86_64__) has __WORDSIZE == 32
>> // but it still needs to use 64-bit syscalls.
>> #if defined(__x86_64__) || __WORDSIZE == 64
>> # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
>> #else
>> # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 0
>> #endif
>
> Of course, as it matches the test H.J. Liu's patch used.
>
> Please, at a bare minimum, give him some credit for this fix.


Re: [PATCH][ARM] Define predicable attribute for arm_abssi2 and arm_neg_abssi2

2012-11-20 Thread Richard Earnshaw

On 19/11/12 17:51, Kyrylo Tkachov wrote:

Hi all,
This patch updates the arm_abssi2 and arm_neg_abssi2 patterns in the ARM
machine description.
We define the predicable attribute based on the alternative. When the
patterns were introduced it was not possible to do that.
Now the second alternative in each of the patterns that supports predication
is defined as predicable.

No regressions on arm-none-eabi with qemu.

Ok for trunk?

Thanks,
Kyrill


gcc/ChangeLog

2012-11-19  Kyrylo Tkachov  

* config/arm/arm.md (*arm_abssi2): Define predicable attribute.
(*arm_neg_abssi2): Define predicable attribute.




There are equivalent patterns in thumb2.md as well.  Could you fix those 
too, please.


R.


abssi_predicable.txt


--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -4263,7 +4263,7 @@ (define_insn "*arm_abssi2"
 eor%?\\t%0, %1, %1, asr #31\;sub%?\\t%0, %0, %1, asr #31"
[(set_attr "conds" "clob,*")
 (set_attr "shift" "1")
-   ;; predicable can't be set based on the variant, so left as no
+   (set_attr "predicable" "no, yes")
 (set_attr "length" "8")]
  )

@@ -4291,7 +4291,7 @@ (define_insn "*arm_neg_abssi2"
 eor%?\\t%0, %1, %1, asr #31\;rsb%?\\t%0, %0, %1, asr #31"
[(set_attr "conds" "clob,*")
 (set_attr "shift" "1")
-   ;; predicable can't be set based on the variant, so left as no
+   (set_attr "predicable" "no, yes")
 (set_attr "length" "8")]
  )







[patch i386 windows]: Fix regression about name-decoration

2012-11-20 Thread Kai Tietz
Hi,

This patch fixes a regression introduced by rev. 193204 for all 32-bit
Windows targets.
It corrects the wrong assumption in i386.c to be able to simply
undefine TARGET_MANGLE_DECL_ASSEMBLER_NAME
there without keeping care to call sub-target specific hook.  This
destroyed name-decoration for
stdcall and fastcall calling conventions.

ChangeLog

2012-11-20  Kai Tietz

PR target/55268
* i386.c (ix86_mangle_decl_assembler_name): Use
SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME if defined.
* cygming.h (TARGET_MANGLE_DECL_ASSEMBLER_NAME): Rename
to SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME.

Tested for i686-w64-mingw32, i686-pc-cygwin, and x86_64-w64-mingw32.
Ok for apply?

Regards,
Kai


Index: cygming.h
===
--- cygming.h   (Revision 193650)
+++ cygming.h   (Arbeitskopie)
@@ -471,7 +471,7 @@

 #define TARGET_VALID_DLLIMPORT_ATTRIBUTE_P i386_pe_valid_dllimport_attribute_p
 #define TARGET_CXX_ADJUST_CLASS_AT_DEFINITION
i386_pe_adjust_class_at_definition
-#define TARGET_MANGLE_DECL_ASSEMBLER_NAME i386_pe_mangle_decl_assembler_name
+#define SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME i386_pe_mangle_decl_assembler_name

 #undef TARGET_ASM_ASSEMBLE_VISIBILITY
 #define TARGET_ASM_ASSEMBLE_VISIBILITY i386_pe_assemble_visibility
Index: i386.c
===
--- i386.c  (Revision 193650)
+++ i386.c  (Arbeitskopie)
@@ -28981,7 +28981,10 @@
   /* For function version, add the target suffix to the assembler name.  */
   if (TREE_CODE (decl) == FUNCTION_DECL
   && DECL_FUNCTION_VERSIONED (decl))
-return ix86_mangle_function_version_assembler_name (decl, id);
+id = ix86_mangle_function_version_assembler_name (decl, id);
+#ifdef SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME
+  id = SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME (decl, id);
+#endif

   return id;
 }


RE: [PATCH][ARM] Define predicable attribute for arm_abssi2 and arm_neg_abssi2

2012-11-20 Thread Kyrylo Tkachov
Hi all,
This is the updated version of the patch. It defines the predicable
attribute for the equivalent abssi2 and neg_abssi2 patterns in thumb2.md.
The previous version (with the changes only to arm.md) has been okayed but
not applied and this patch supersedes it.
The previous version is:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01578.html

No regressions for arm-none-eabi for qemu.

Ok for trunk?

Thanks,
Kyrill

gcc/ChangeLog

2012-11-20  Kyrylo Tkachov  

* config/arm/arm.md (*arm_abssi2): Define predicable attribute.
(*arm_neg_abssi2): Likewise.
* config/arm/thumb2.md (*thumb2_abssi2): Likewise.
(*thumb2_neg_abssi2): Likewise.


-Original Message-
From: Ramana Radhakrishnan 
Sent: 19 November 2012 18:05
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
Subject: Re: [PATCH][ARM] Define predicable attribute for arm_abssi2 and
arm_neg_abssi2

On 11/19/12 17:51, Kyrylo Tkachov wrote:
> Hi all,
> This patch updates the arm_abssi2 and arm_neg_abssi2 patterns in the ARM
> machine description.
> We define the predicable attribute based on the alternative. When the
> patterns were introduced it was not possible to do that.
> Now the second alternative in each of the patterns that supports
predication
> is defined as predicable.
>
> No regressions on arm-none-eabi with qemu.
>
> Ok for trunk?

Ok, please apply.

Ramana
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -4263,7 +4263,7 @@ (define_insn "*arm_abssi2"
eor%?\\t%0, %1, %1, asr #31\;sub%?\\t%0, %0, %1, asr #31"
   [(set_attr "conds" "clob,*")
(set_attr "shift" "1")
-   ;; predicable can't be set based on the variant, so left as no
+   (set_attr "predicable" "no, yes")
(set_attr "length" "8")]
 )
 
@@ -4291,7 +4291,7 @@ (define_insn "*arm_neg_abssi2"
eor%?\\t%0, %1, %1, asr #31\;rsb%?\\t%0, %0, %1, asr #31"
   [(set_attr "conds" "clob,*")
(set_attr "shift" "1")
-   ;; predicable can't be set based on the variant, so left as no
+   (set_attr "predicable" "no, yes")
(set_attr "length" "8")]
 )
 
diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index 
a5302f479f5091d08f4bf1a9ee9b0423692372af..
 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -141,7 +141,7 @@ (define_insn "*thumb2_abssi2"
eor%?\\t%0, %1, %1, asr #31\;sub%?\\t%0, %0, %1, asr #31"
   [(set_attr "conds" "clob,*")
(set_attr "shift" "1")
-   ;; predicable can't be set based on the variant, so left as no
+   (set_attr "predicable" "no, yes")
(set_attr "length" "10,8")]
 )
 
@@ -155,7 +155,7 @@ (define_insn "*thumb2_neg_abssi2"
eor%?\\t%0, %1, %1, asr #31\;rsb%?\\t%0, %0, %1, asr #31"
   [(set_attr "conds" "clob,*")
(set_attr "shift" "1")
-   ;; predicable can't be set based on the variant, so left as no
+   (set_attr "predicable" "no, yes")
(set_attr "length" "10,8")]
 )
 


Re: [PATCH][ARM] Define predicable attribute for arm_abssi2 and arm_neg_abssi2

2012-11-20 Thread Richard Earnshaw

On 20/11/12 10:25, Kyrylo Tkachov wrote:

Hi all,
This is the updated version of the patch. It defines the predicable
attribute for the equivalent abssi2 and neg_abssi2 patterns in thumb2.md.
The previous version (with the changes only to arm.md) has been okayed but
not applied and this patch supersedes it.
The previous version is:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01578.html

No regressions for arm-none-eabi for qemu.

Ok for trunk?

Thanks,
Kyrill

gcc/ChangeLog

2012-11-20  Kyrylo Tkachov  

* config/arm/arm.md (*arm_abssi2): Define predicable attribute.
(*arm_neg_abssi2): Likewise.
* config/arm/thumb2.md (*thumb2_abssi2): Likewise.
(*thumb2_neg_abssi2): Likewise.


-Original Message-
From: Ramana Radhakrishnan
Sent: 19 November 2012 18:05
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
Subject: Re: [PATCH][ARM] Define predicable attribute for arm_abssi2 and
arm_neg_abssi2

On 11/19/12 17:51, Kyrylo Tkachov wrote:

Hi all,
This patch updates the arm_abssi2 and arm_neg_abssi2 patterns in the ARM
machine description.
We define the predicable attribute based on the alternative. When the
patterns were introduced it was not possible to do that.
Now the second alternative in each of the patterns that supports

predication

is defined as predicable.

No regressions on arm-none-eabi with qemu.

Ok for trunk?


Ok, please apply.

Ramana



OK.

Thanks.

R.




Re: [5/8] Tweak bitfield alignment handling

2012-11-20 Thread Richard Sandiford
Mikael Pettersson  writes:
> John David Anglin writes:
>  > On Sun, 18 Nov 2012, Richard Sandiford wrote:
>  > 
>  > >HOST_WIDE_INT start = bitpos_ - (bitpos_ % unit);
>  > >if (bitregion_start_ && start < bitregion_start_)
>  > >  break;
>  > > -  if (bitregion_end_ && start + unit > bitregion_end_ + 1)
>  > > +  if (start + unit > bitregion_end_ + 1)
>  > 
>  > This causes:
>  > 
>  > /home/dave/gnu/gcc/objdir/./prev-gcc/g++ 
> -B/home/dave/gnu/gcc/objdir/./prev-gcc/ 
> -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/bin/ -nostdinc++ 
> -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs 
> -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
> -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
>  -I/home/dave/gnu/gcc
>  > /objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
> -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ 
> -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/sr
>  > c/.libs 
> -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
> -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tabl
>  > es -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
> -Wmissing-format-attribut
>  > e -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
> -Werror 
>  > -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
> -I../../g
>  > cc/gcc/../include -I../../gcc/gcc/../libcpp/include  
> -I../../gcc/gcc/../libdecnu
>  > mber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../gcc/gcc/../li
>  > bbacktrace../../gcc/gcc/stor-layout.c -o 
> stor-layout.o../../gcc/gcc/stor-layout.c: In member function 〘bool 
> bit_field_mode_iterator::n
>  > ext_mode(machine_mode*)〙:
>  > ../../gcc/gcc/stor-layout.c:2690:43: error: comparison between signed and 
> unsign
>  > ed integer expressions [-Werror=sign-compare]
>  >if (start + unit > bitregion_end_ + 1)
>  >   ^
>  > cc1plus: all warnings being treated as errors
>
> This error also breaks m68k-linux bootstrap.
>
> HWI32 issue?

Yeah, I expect so, sorry.

Logically, everything here would be unsigned arithmetic, but as the
comment says:

  /* We use signed values here because the bit position can be negative
 for invalid input such as gcc.dg/pr48335-8.c.  */

This is the patch I'm testing.  There are three things being checked here:

- "unit", the size of the mode in isolation.  This really is an unsigned
  value, and is compared to unsigned values like GET_MODE_PRECISION.

- bitpos_ % unit (+ bitsize_), the start and end positions of the bitfield
  relative to the start of the mode.  The start position is supposed to be
  [0, unit), so the modulus and result should be unsigned.  (Using unsigned
  modulus doesn't cope with negative bit positions combined with
  non-power-of-2 units, but I don't think we support that.)

- bitregion_start_ and bitregion_end_.  bitpos_ is signed and can be
  negative, so the bitregion comparison should continue to be signed.

OK to commit if testing succeeds?

Richard


gcc/
* stor-layout.c (bit_field_mode_iterator::next_mode): Fix signedness.

Index: gcc/stor-layout.c
===
--- gcc/stor-layout.c   2012-11-20 10:15:39.0 +
+++ gcc/stor-layout.c   2012-11-20 10:15:39.464712715 +
@@ -2670,10 +2670,6 @@ bit_field_mode_iterator::next_mode (enum
   if (unit != GET_MODE_PRECISION (mode_))
continue;
 
-  /* Skip modes that are too small.  */
-  if ((bitpos_ % unit) + bitsize_ > unit)
-   continue;
-
   /* Stop if the mode is too wide to handle efficiently.  */
   if (unit > MAX_FIXED_MODE_SIZE)
break;
@@ -2683,11 +2679,18 @@ bit_field_mode_iterator::next_mode (enum
   if (count_ > 0 && unit > BITS_PER_WORD)
break;
 
+  /* Skip modes that are too small.  */
+  unsigned HOST_WIDE_INT substart = (unsigned HOST_WIDE_INT) bitpos_ % 
unit;
+  unsigned HOST_WIDE_INT subend = substart + bitsize_;
+  if (subend > unit)
+   continue;
+
   /* Stop if the mode goes outside the bitregion.  */
-  HOST_WIDE_INT start = bitpos_ - (bitpos_ % unit);
+  HOST_WIDE_INT start = bitpos_ - substart;
   if (bitregion_start_ && start < bitregion_start_)
break;
-  if (start + unit > bitregion_end_ + 1)
+  HOST_WIDE_INT end = start + unit;
+  if (end > bitregion_end_ + 1)
break;
 
   /* Stop if the mode requires too much alignment.  */


Re: [PATCH] Replace const_vector with match_operand in sse.md

2012-11-20 Thread Kirill Yukhin
Hi,
> OK for mainline SVN, if bootstrapped and regression tested appropriately.
Checked in: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00603.html

Thanks, K


Re: [RFC PATCH] Masked load/store vectorization

2012-11-20 Thread Jakub Jelinek
On Tue, Nov 20, 2012 at 02:14:43PM +0400, Yuri Rumyantsev wrote:
> As example of missed vectorization with chain of conditions I can
> propose to to look at 462.libquantum.

That is roughly:

struct T
{
  float __complex__ t1;
  unsigned long long t2;
};
struct S
{
  int s1;
  struct T *s2;
};

void
foo (struct S *s, int x, int y, int z)
{
  int i;
  for (i = 0; i < s->s1; i++)
{
  if (s->s2[i].t2 & (1ULL << x))
if(s->s2[i].t2 & (1ULL << y))
  s->s2[i].t2 ^= (1ULL << z);
}
}
isn't it?  There aren't after optimizations two conditions, but just one,
(1ULL << x) | (1ULL << y) (and also 1ULL << z) are hoisted before the loop
by PRE, so the loop just does if (s->s2[i].t2 & something) s->s2[i].t2 ^= 
somethingelse;

This isn't vectorized, but not because of the if-conv part which actually
puts there a masked store, but because of data refs analysis issues:
Creating dr for _10->t2
analyze_innermost: success.
base_address: pretmp_28
offset from base address: 0
constant offset from base address: 8
step: 16
aligned to: 256
base_object: *pretmp_28
Access function 0: 64
Access function 1: {0B, +, 16}_1
Creating dr for MEM[(struct T *)_23]
analyze_innermost: success.
base_address: pretmp_28
offset from base address: 0
constant offset from base address: 8
step: 16
aligned to: 256
base_object: MEM[(struct T *)(long long unsigned int *) pretmp_28]
Access function 0: {8B, +, 16}_1
(compute_affine_dependence
  stmt_a: _11 = _10->t2;
  stmt_b: MASK_STORE (_23, 0B, _ifc__25, _20);

(no idea why, _23 is _23 = &_10->t2; and so it should hopefully figure out
that the two do (if written at all) overlap, and then
16: === vect_analyze_data_ref_accesses ===
16: Detected single element interleaving _10->t2 step 16
16: Data access with gaps requires scalar epilogue loop
16: not consecutive access MASK_STORE (_23, 0B, _ifc__25, _20);

16: not vectorized: complicated access pattern.
16: bad data access.

The current masked load/store code isn't prepared to handle masked
loads/stores with gaps, but vectorize_masked_load_store isn't even called
in this case, it is shot down somewhere in tree-vect-data-refs.c.

That said, is vectorization actually a win on this loop?  I mean, pre-AVX
it can't be, it is working on every second DImode value, and with AVX (even
with that it could use vxorpd/vandpd) and with AVX2, it would mean vpmaskmov
with DImode for every second DImode, so vectorization factor 2, but with the
higher cost of conditional store.

Slightly adjusted testcase above (with the float __complex__ t1;
field removed) gets us further, it is actually vectorized, but with
versioning for alias:
15: versioning for alias required: can't determine dependence between _10->t2 
and MEM[(struct T *)_23]
15: mark for run-time aliasing test between _10->t2 and MEM[(struct T *)_23]
where obviously the two do alias (but it is access to the exact same memory
location and the (conditional) store comes after the load), thus while we
still emit the vectorized loop at expand time, it is optimized away later
on.

I'm attaching updated version of the patch, as the older one no longer
applied after Diego's vec.h changes.

2012-11-20  Jakub Jelinek  

* Makefile.in (tree-if-conv.o): Depend on $(TARGET_H), $(EXPR_H)
and $(OPTABS_H).
* config/i386/sse.md (maskload, maskstore): New expanders.
* tree-data-ref.c (struct data_ref_loc_d): Replace pos field with ref.
(get_references_in_stmt): Don't record operand addresses, but
operands themselves.  Handle MASK_LOAD and MASK_STORE.
(find_data_references_in_stmt, graphite_find_data_references_in_stmt,
create_rdg_vertices): Adjust users of pos field of data_ref_loc_d.
* internal-fn.def (MASK_LOAD, MASK_STORE): New internal fns.
* tree-if-conv.c: Add target.h, expr.h and optabs.h includes.
(if_convertible_phi_p, insert_gimplified_predicates): Add
any_mask_load_store argument, if true, handle it like
flag_tree_loop_if_convert_stores.
(ifcvt_can_use_mask_load_store): New function.
(if_convertible_gimple_assign_stmt_p): Add any_mask_load_store
argument, check if some conditional loads or stores can't be
converted into MASK_LOAD or MASK_STORE.
(if_convertible_stmt_p): Add any_mask_load_store argument,
pass it down to if_convertible_gimple_assign_stmt_p.
(if_convertible_loop_p_1): Add any_mask_load_store argument,
pass it down to if_convertible_stmt_p and if_convertible_phi_p,
call if_convertible_phi_p only after all if_convertible_stmt_p
calls.
(if_convertible_loop_p): Add any_mask_load_store argument,
pass it down to if_convertible_loop_p_1.
(predicate_mem_writes): Emit MASK_LOAD and/or MASK_STORE calls.
(combine_blocks): Add any_mask_load_store argument, pass

Re: [patch] escape sharp brackets to avoid doxygen warnings

2012-11-20 Thread Jonathan Wakely
On 18 November 2012 16:59, Matthias Klose wrote:
> currently doxygen complains about unknown xml/html tags. this patch 
> properly(?)
> escapes these. Maybe this is a change in doxygen 1.8, it didn't seem to be
> necessary in the past. Ok for the trunk?

(Added gcc-patches to the CC list)

OK, thanks.
2012-11-18  Matthias Klose  

	* doc/doxygen/user.cfg.in (ALIASES). Escape sharp braces.
	* include/bits/allocator.h: Escape sharp braces in comment.
	* include/profile/impl/profiler_algos.h: Likewise.

Index: doc/doxygen/user.cfg.in
===
--- doc/doxygen/user.cfg.in	(revision 193528)
+++ doc/doxygen/user.cfg.in	(working copy)
@@ -196,8 +196,8 @@
 # You can put \n's in the value part of an alias to insert newlines.
 
 ALIASES= "doctodo=@todo\nNeeds documentation! See http://gcc.gnu.org/onlinedocs/libstdc++/manual/documentation_style.html"; \
- "headername{1}=Instead, include <\1>." \
- "headername{2}=Instead, include <\1> or <\2>."
+ "headername{1}=Instead, include \<\1\>." \
+ "headername{2}=Instead, include \<\1\> or \<\2\>."
 
 # This tag can be used to specify a number of word-keyword mappings (TCL only).
 # A mapping has the form "name=value". For example adding
Index: include/profile/impl/profiler_algos.h
===
--- include/profile/impl/profiler_algos.h	(revision 193528)
+++ include/profile/impl/profiler_algos.h	(working copy)
@@ -24,7 +24,7 @@
 /** @file profile/impl/profiler_algos.h
  *  @brief Algorithms used by the profile extension.
  *
- *  This file is needed to avoid including  or .
+ *  This file is needed to avoid including \ or \.
  *  Including those files would result in recursive includes.
  *  These implementations are oversimplified.  In general, efficiency may be
  *  sacrificed to minimize maintenance overhead.
Index: include/bits/allocator.h
===
--- include/bits/allocator.h	(revision 193528)
+++ include/bits/allocator.h	(working copy)
@@ -136,7 +136,7 @@
 operator!=(const allocator<_Tp>&, const allocator<_Tp>&)
 { return false; }
 
-  /// Declare uses_allocator so it can be specialized in  etc.
+  /// Declare uses_allocator so it can be specialized in \ etc.
   template
 struct uses_allocator;
 


Re: [patch] [aarch64] add multiarch definitions for aarch64-linux-gnu

2012-11-20 Thread Marcus Shawcroft
Thanks Matthias,

> +ARM_EB = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),eb)
> +ifeq (,$(ARM_EB))
> +MULTIARCH_DIRNAME = $(call if_multiarch,aarch64-linux-gnu)
> +endif

Can we use the name of the architecture, ARM -> AARCH64

Please can we have big endian wired up?

+else
+MULTIARCH_DIRNAME = $(call if_multiarch,aarch64_be-linux-gnu)


Cheers
/Marcus


[PATCH, i386]: Emit CLOBBERs in VOIDmode

2012-11-20 Thread Uros Bizjak
Hello!

2012-11-20  Uros Bizjak  

* config/i386/i386.c (ix86_expand_call): Emit CLOBBERs in VOIDmode.

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

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 193657)
+++ config/i386/i386.c  (working copy)
@@ -23528,9 +23528,8 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx call
   UNSPEC_MS_TO_SYSV_CALL);
 
   for (i = 0; i < ARRAY_SIZE (clobbered_registers); i++)
-vec[vec_len++]
- = gen_rtx_CLOBBER (SSE_REGNO_P (clobbered_registers[i])
-? TImode : DImode,
+   vec[vec_len++]
+ = gen_rtx_CLOBBER (VOIDmode,
 gen_rtx_REG (SSE_REGNO_P (clobbered_registers[i])
  ? TImode : DImode,
  clobbered_registers[i]));


Commit: V850: Various backend fixes

2012-11-20 Thread Nick Clifton
Hi Guys,

  I am applying the patch below to fix various small problems with the
  V850 backend.  With this patch applied there are 454 fewer unexpected
  failures in the gcc testsuite for a v850-elf toolchain.

Cheers
  Nick

gcc/ChangeLog
2012-11-20  Nick Clifton  

* config/v850/v850.c (F): New function.  Mark the given insn as
being frame related.
(v850_all_frame_related): New function.  Mark the given push insn
as being frame related.
(v850_pass_by_reference): When using the RH850 ABI do not pass
arguments by reference.
(v850_strict_argument_naming): Delete function.
(v850_function_arg): Use word alignment with the RH850 ABI.
(v850_arg_partial_bytes): Likewise.
(v850_function_arg_advance): Likewise.
(v850_print_operand): Handle CONST_INT and CONST_DOUBLE.
(compute_register_save_size): Use df_regs_ever_live_p.
(increment_stack): Mark prologue adjustments as being frame
related.
(expand_prologue): Handle pretend args.  Mark insns generated as
being frame related.
(expand_epilogue): Likewise.
(v850_return_in_memory): When using the RH850 ABI return
aggregates in memory.
(v850_setup_incoming_varargs): Delete function.
(v850_option_override): New function.
(TARGET_DEBUG_UNWIND_INFO): Delete definition.
(TARGET_SETUP_INCOMING_VARARGS): Likewise.
(TARGET_STRICT_ARGUMENT_NAMING): Likewise.
(TARGET_OPTION_OVERRIDE): Define.
* config/v850/v850.h (ASM_SPEC): Pass 8byte-align and gcc-abi
options on to assembler.
(LINK_SPEC): Likewise.
(TARGET_CPU_CPP_BUILTINS): Define __V850_8BYTE_ALIGN__ and
__V850_GCC_ABI__.
(STACK_BOUNDARY): Set to BIGGEST_ALIGNMENT.
(FUNCTION_BOUNDARY): With the RH850 ABI always 32-bit alignment.
(BIGGEST_ALIGNMENT): With -8byte-align set to 64-bits.
(BIGGEST_FIELD_ALIGNMENT): Likewise.
(enum reg_class): Swap EVEN_REGS and GENERAL_REGS.
(REG_CLASS_NAMES): Likewise.
(REG_CLASS_CONTENTS): Likewise.
(struct cum_arg): Delete anonymous_args field.
(INIT_CUMULATIVE_ARGS): Update.
(PREFERRED_DEBUG): Set to DWARF2_DEBUG.
(DWARF2_FRAME_INFO): Define.
(DWARF2_UNWIND_INFO): Define.
(INCOMING_RETURN_ADDR_RTX): Define.
(DWARF_FRAME_RETURN_COLUMN): Define.
(TARGET_USE_FPU): Define.
* config/v850/v850.md: Replace TARGET_V850E2V3 in floating point
insns with TARGET_USE_FPU.
(fixuns_truncsfsi2): New pattern.
(fixuns_truncdfsi2): New pattern.
(fix_truncsfdi2): New pattern.
(fixuns_truncsfdi2): New pattern.
(fix_truncdfdi2): New pattern.
(fixuns_truncdfdi2): New pattern.
(unsfloatsisf2): New pattern.
(unsfloatsidf2): New pattern.
(floatdisf2): New pattern.
(unsfloatdisf2): New pattern.
(floatdidf2): New pattern.
(unsfloatdidf2): New pattern.
(fnmasf4): Fix RTl description.
(fnmssf4): Likewise.
* config/v850/v850.opt (mrelax): New option.
(mlong-jumps): Likewise.
(msoft-float): Likewise.
(mhard-float): Likewise.
(mrh850-abi): Likewise.
(mgcc-abi): Likewise.
(m8byte-align): Likewise.
* config/v850/t-v850 (MULTILIB_OPTIONS): Update multilib options.
(MULTILIB_DIRNAMES): Likewise.

Index: gcc/config/v850/t-v850
===
--- gcc/config/v850/t-v850  (revision 193658)
+++ gcc/config/v850/t-v850  (working copy)
@@ -1,5 +1,5 @@
 # Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2008, 2009, 2010,
-# 2011 Free Software Foundation, Inc.
+# 2011, 2012 Free Software Foundation, Inc.
 #
 # This file is part of GCC.
 #
@@ -18,9 +18,8 @@
 # .
 
 # Create target-specific versions of the libraries
-MULTILIB_OPTIONS  = mv850/mv850e/mv850e2/mv850e2v3
-MULTILIB_DIRNAMES = v850 v850e v850e2 v850e2v3
-MULTILIB_MATCHES  = mv850e=mv850e1 
+MULTILIB_OPTIONS  = m8byte-align mgcc-abi msoft-float
+MULTILIB_DIRNAMES =  8bytegcc-abi  soft-float
 
 TCFLAGS = -mno-app-regs -msmall-sld -Wa,-mwarn-signed-overflow 
-Wa,-mwarn-unsigned-overflow
 
Index: gcc/config/v850/v850.c
===
--- gcc/config/v850/v850.c  (revision 193658)
+++ gcc/config/v850/v850.c  (working copy)
@@ -72,6 +72,36 @@
 static GTY(()) section * zdata_section;
 static GTY(()) section * zbss_section;
 
+/* end-sanitize-redhat */
+/* We use this to wrap all emitted insns in the prologue.  */
+static rtx
+F (rtx x)
+{
+  if (GET_CODE (x) != CLOBBER)
+RTX_FRAME_RELATED_P (x) = 1;
+  return x;
+}
+
+/* Mark all the subexpressions of the PARALLEL rtx PAR as
+   frame-related.  Return PAR.
+
+   dwarf2out.c:dwarf2out_frame_debug_expr ignores sub-expressi

Commit: RX backend fixes

2012-11-20 Thread Nick Clifton
Hi Guys,

  I am applying this patch to fix up a few issues with the RX backend.
  With this patch applied there are 355 fewer gcc testsuite regressions.

Cheers
  Nick

gcc/ChangeLog
2012-11-20  Nick Clifton  

* config/rx/rx.c (rx_function_arg_boundary): When using the RX ABI
align stack arguments to their natural alignment.
(rx_narrow_volatile_bitfield): New function.  Allows narrow
volatile bitfields.
(rx_ok_to_inline): New function.  Do not inline functions with
local variables into a naked caller.
(TARGET_NARROW_VOLATILE_BITFIELD): Define.
(TARGET_CAN_INLINE_P): Define.
* config/rx/rx.c (TARGET_CPU_CPP_BUILTINS): Define __RX_ABI__ or
__RX_GC_ABI__.
(ASM_SPEC): Pass -mgcc-abi on to the assembler.
(STRICT_ALIGNMENT): Set to false.
(CTORS_SECTION_ASM_OP): Add executable attribute.
(DTORS_SECTION_ASM_OP): Add executable attribute.
(INIT_ARRAY_SECTION_ASM_OP): Add executable attribute.
(FINI_ARRAY_SECTION_ASM_OP): Add executable attribute.
* config/rx/rx.md (subdi3): Don't allow MEMs as the third operand,
as it causes too much reload pressure.
* config/rx/rx.opt (mgcc-abi): New option.
(mrx-abi): New option.
* config/rx/t-rx (MULTILIB_OPTIONS): Show how to add an ABI
multilib.
(MULTILIB_DIRNAMES): Likewise.

Index: gcc/config/rx/rx.c
===
--- gcc/config/rx/rx.c  (revision 193649)
+++ gcc/config/rx/rx.c  (working copy)
@@ -1086,7 +1086,20 @@
 rx_function_arg_boundary (enum machine_mode mode ATTRIBUTE_UNUSED,
  const_tree type ATTRIBUTE_UNUSED)
 {
-  return 32;
+  /* Older versions of the RX backend aligned all on-stack arguements
+ to 32-bits.  The RX C ABI however says that they should be
+ aligned to their natural alignment.  (See section 5.2.2 of the ABI).  */
+  if (TARGET_GCC_ABI)
+return STACK_BOUNDARY;
+
+  if (type)
+{
+  if (DECL_P (type))
+   return DECL_ALIGN (type);
+  return TYPE_ALIGN (type);
+}
+
+  return PARM_BOUNDARY;
 }
 
 /* Return an RTL describing where a function return value of type RET_TYPE
@@ -3202,7 +3215,39 @@
 
   return (zero && factor == 1) ? 4 : 5;
 }
+
+static bool
+rx_narrow_volatile_bitfield (void)
+{
+  return true;
+}
+
+static bool
+rx_ok_to_inline (tree caller, tree callee)
+{
+  /* Issue 2877983: Do not inline functions with local variables
+ into a naked CALLER - naked function have no stack frame and
+ locals need a frame in order to have somewhere to live.
+
+ Unfortunately we have no way to determine the presence of
+ local variables in CALLEE, so we have to be cautious and
+ assume that there might be some there.
+
+ We do allow inlining when CALLEE has the "inline" type
+ modifier or the "always_inline" or "gnu_inline" attributes.  */
+  return lookup_attribute ("naked", DECL_ATTRIBUTES (caller)) == NULL_TREE
+|| DECL_DECLARED_INLINE_P (callee)
+|| lookup_attribute ("always_inline", DECL_ATTRIBUTES (callee)) != 
NULL_TREE
+|| lookup_attribute ("gnu_inline", DECL_ATTRIBUTES (callee)) != NULL_TREE;
+}
+
 
+#undef  TARGET_NARROW_VOLATILE_BITFIELD
+#define TARGET_NARROW_VOLATILE_BITFIELD
rx_narrow_volatile_bitfield
+
+#undef  TARGET_CAN_INLINE_P
+#define TARGET_CAN_INLINE_Prx_ok_to_inline
+
 #undef  TARGET_ASM_JUMP_ALIGN_MAX_SKIP
 #define TARGET_ASM_JUMP_ALIGN_MAX_SKIP rx_max_skip_for_label
 #undef  TARGET_ASM_LOOP_ALIGN_MAX_SKIP
@@ -3344,8 +3389,8 @@
 #undef  TARGET_LEGITIMIZE_ADDRESS
 #define TARGET_LEGITIMIZE_ADDRESS  rx_legitimize_address
 
-#undef TARGET_WARN_FUNC_RETURN
-#define TARGET_WARN_FUNC_RETURN rx_warn_func_return
+#undef  TARGET_WARN_FUNC_RETURN
+#define TARGET_WARN_FUNC_RETURNrx_warn_func_return
 
 struct gcc_target targetm = TARGET_INITIALIZER;
 
Index: gcc/config/rx/rx.h
===
--- gcc/config/rx/rx.h  (revision 193649)
+++ gcc/config/rx/rx.h  (working copy)
@@ -1,5 +1,5 @@
 /* GCC backend definitions for the Renesas RX processor.
-   Copyright (C) 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
+   Copyright (C) 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
Contributed by Red Hat.
 
This file is part of GCC.
@@ -49,6 +49,11 @@
builtin_define ("__RX_AS100_SYNTAX__"); \
   else \
builtin_define ("__RX_GAS_SYNTAX__");   \
+   \
+  if (TARGET_GCC_ABI)  \
+   builtin_define ("__RX_GCC_ABI__");  \
+  else \
+   builtin_define ("__RX_ABI__");  \
 }   \
   while (0)
 
@@ -79,6 +84,7 @@
 %{mrelax:-relax} \
 %{mpid} \
 %{mint-regi

Re: [PR 55238] More careful pass-through handling in find_aggregate_values_for_callers_subset

2012-11-20 Thread Martin Jambor
Hi,

On Fri, Nov 16, 2012 at 08:42:46AM -0500, David Edelsohn wrote:
>   * testsuite/gcc.dg/torture/pr55238.c: New test.
> 
> Does this PR rely on hidden visibility?  The new testcase uses
> attribute visibility hidden, but does not check DejaGNU
> dg-require-visibility and fails on AIX.

No, at least on my i686 desktop it does not rely on it.  I will apply
the following patch in a few hours (after I add it to some testing run
on x86_64), unless someone objects.

Thanks,

Martin


2012-11-20  Martin Jambor  

* gcc.dg/torture/pr55238.c: Remove hidden attribute.

Index: src/gcc/testsuite/gcc.dg/torture/pr55238.c
===
--- src.orig/gcc/testsuite/gcc.dg/torture/pr55238.c
+++ src/gcc/testsuite/gcc.dg/torture/pr55238.c
@@ -31,7 +31,7 @@ gzbuffer (void *file, int size)
   gz_reset (state);
 }
 
-void __attribute__ ((visibility ("hidden"))) gz_error (gz_state *state, int 
err, char *msg)
+void gz_error (gz_state *state, int err, char *msg)
 {
   if (state->msg != 0)
 {


Re: [patch] [aarch64] add multiarch definitions for aarch64-linux-gnu

2012-11-20 Thread Matthias Klose
Am 20.11.2012 13:47, schrieb Marcus Shawcroft:
> Thanks Matthias,
> 
>> +ARM_EB = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),eb)
>> +ifeq (,$(ARM_EB))
>> +MULTIARCH_DIRNAME = $(call if_multiarch,aarch64-linux-gnu)
>> +endif
> 
> Can we use the name of the architecture, ARM -> AARCH64
> 
> Please can we have big endian wired up?
> 
> +else
> +MULTIARCH_DIRNAME = $(call if_multiarch,aarch64_be-linux-gnu)
> 
> 
> Cheers
> /Marcus
> 
--- config/aarch64/t-aarch64-linux  (revision 193639)
+++ config/aarch64/t-aarch64-linux  (working copy)
@@ -20,3 +20,6 @@

 LIB1ASMSRC   = aarch64/lib1funcs.asm
 LIB1ASMFUNCS = _aarch64_sync_cache_range
+
+AARCH_BE = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),_be)
+MULTIARCH_DIRNAME = $(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu)



Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Peter Bergner
On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
> I've applied your patch (with minor style and comment changes) upstream:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=168356
> I did not have any way to test it though. Also, gmail does something
> horrible with patches inlined in a message, so I might have missed
> something.

Doing a quick peruse through your LLVM commit, I see you grabbed the
PopStackFrames() addition, but the asan_linux.cc changes do not include
the call to PopStackFrames() after the _Unwind_Backtrace() call.
Specifically, the following patch hunk:

>  _Unwind_Backtrace(Unwind_Trace, stack);
> > +// Pop off the two ASAN functions from the backtrace.
> > +stack->PopStackFrames(2);

I'll scan the reset of your commit looking for anything else that
is missing.


> Soon I hope to learn how to pull the upstream changes to gcc tree and
> do it myself.
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376)
> In the meantime, you are welcome to apply the same patch to gcc manually.
> Same for the gcc-specific parts of you patch.

I'll grab your changes from the LLVM tree so as to pick up your
style changes and add anything you inadvertently dropped and
commit it.  Thanks.

Peter




Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Konstantin Serebryany
On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner  wrote:
> On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
>> I've applied your patch (with minor style and comment changes) upstream:
>> http://llvm.org/viewvc/llvm-project?view=rev&revision=168356
>> I did not have any way to test it though. Also, gmail does something
>> horrible with patches inlined in a message, so I might have missed
>> something.
>
> Doing a quick peruse through your LLVM commit, I see you grabbed the
> PopStackFrames() addition, but the asan_linux.cc changes do not include
> the call to PopStackFrames() after the _Unwind_Backtrace() call.
> Specifically, the following patch hunk:
>
>>  _Unwind_Backtrace(Unwind_Trace, stack);
>> > +// Pop off the two ASAN functions from the backtrace.
>> > +stack->PopStackFrames(2);

Ah, indeed, I missed that.
Since the patch also affects ARM, I'd like to hear from Evgeniy Stepanov
(or we may decouple powerpc from arm)

--kcc
>
> I'll scan the reset of your commit looking for anything else that
> is missing.
>
>
>> Soon I hope to learn how to pull the upstream changes to gcc tree and
>> do it myself.
>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376)
>> In the meantime, you are welcome to apply the same patch to gcc manually.
>> Same for the gcc-specific parts of you patch.
>
> I'll grab your changes from the LLVM tree so as to pick up your
> style changes and add anything you inadvertently dropped and
> commit it.  Thanks.
>
> Peter
>
>


Re: VEC re-write [patch 01/25]

2012-11-20 Thread Ulrich Weigand
Diego Novillo wrote:
> On Thu, Nov 15, 2012 at 4:53 PM, Diego Novillo  wrote:
> 
> > I have tested the patch pretty extensively:
> >
> > - Regular bootstraps on x86_64, ppc, ia64, sparc and hppa.
> > - Bootstraps with --enable-checking=release
> > - Bootstraps with --enable-checking=gc,gcac
> > - Basic builds on all targets (using contrib/config-list.mk).
> 
> I have now committed all 25 parts of this patch as rev 193595.  Please
> CC me on any problems that you think may be related to this rewrite.

This breaks an spu-elf cross-compiler built on a powerpc64-linux host
using a gcc 4.1.2 host compiler  (i.e. RHEL5.x, which is the latest RHEL
distro that still supports running on Cell/B.E.).

I'm getting errors along the lines of:

/home/uweigand/fsf/gcc-head/gcc/tree-data-ref.c: In function 
'conflict_function* conflict_fn(unsigned int, ...)':
/home/uweigand/fsf/gcc-head/gcc/tree-data-ref.c:1599: warning: cannot receive 
objects of non-POD type 'class affine_fn' through '...'; call will abort at 
runtime

And indeed it does then abort at runtime when building libgfortran
(with -ftree-vectorize enabled).

"affine_fn" is defined in tree-data-ref.h as:
typedef vec affine_fn;
which apparently is no longer a POD type?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com



Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Konstantin Serebryany
On Tue, Nov 20, 2012 at 6:18 PM, Evgeniy Stepanov
 wrote:
> On Tue, Nov 20, 2012 at 5:52 PM, Konstantin Serebryany
>  wrote:
>>
>> On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner 
>> wrote:
>> > On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
>> >> I've applied your patch (with minor style and comment changes)
>> >> upstream:
>> >> http://llvm.org/viewvc/llvm-project?view=rev&revision=168356
>> >> I did not have any way to test it though. Also, gmail does something
>> >> horrible with patches inlined in a message, so I might have missed
>> >> something.
>> >
>> > Doing a quick peruse through your LLVM commit, I see you grabbed the
>> > PopStackFrames() addition, but the asan_linux.cc changes do not include
>> > the call to PopStackFrames() after the _Unwind_Backtrace() call.
>> > Specifically, the following patch hunk:
>> >
>> >>  _Unwind_Backtrace(Unwind_Trace, stack);
>> >> > +// Pop off the two ASAN functions from the backtrace.
>> >> > +stack->PopStackFrames(2);
>
>
> I wonder if under some conditions we may get a different number of extra
> frames (inlining comes to mind). What do you think of removing any number of
> frames that belong to the runtime library - we have memory layout info for
> that?

Bad idea, imho.
Hard to implement, slower to run (remember, this *is* a hotspot).
The frames in question are in our run-time and we can fully control inlining.
What is the current number of redundant frames on ARM?

--kcc


>
>
>>
>>
>> Ah, indeed, I missed that.
>> Since the patch also affects ARM, I'd like to hear from Evgeniy Stepanov
>> (or we may decouple powerpc from arm)
>>
>> --kcc
>> >
>> > I'll scan the reset of your commit looking for anything else that
>> > is missing.
>> >
>> >
>> >> Soon I hope to learn how to pull the upstream changes to gcc tree and
>> >> do it myself.
>> >> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376)
>> >> In the meantime, you are welcome to apply the same patch to gcc
>> >> manually.
>> >> Same for the gcc-specific parts of you patch.
>> >
>> > I'll grab your changes from the LLVM tree so as to pick up your
>> > style changes and add anything you inadvertently dropped and
>> > commit it.  Thanks.
>> >
>> > Peter
>> >
>> >
>
>


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Dmitry Vyukov
On Tue, Nov 20, 2012 at 6:21 PM, Konstantin Serebryany
 wrote:
> On Tue, Nov 20, 2012 at 6:18 PM, Evgeniy Stepanov
>  wrote:
>> On Tue, Nov 20, 2012 at 5:52 PM, Konstantin Serebryany
>>  wrote:
>>>
>>> On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner 
>>> wrote:
>>> > On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
>>> >> I've applied your patch (with minor style and comment changes)
>>> >> upstream:
>>> >> http://llvm.org/viewvc/llvm-project?view=rev&revision=168356
>>> >> I did not have any way to test it though. Also, gmail does something
>>> >> horrible with patches inlined in a message, so I might have missed
>>> >> something.
>>> >
>>> > Doing a quick peruse through your LLVM commit, I see you grabbed the
>>> > PopStackFrames() addition, but the asan_linux.cc changes do not include
>>> > the call to PopStackFrames() after the _Unwind_Backtrace() call.
>>> > Specifically, the following patch hunk:
>>> >
>>> >>  _Unwind_Backtrace(Unwind_Trace, stack);
>>> >> > +// Pop off the two ASAN functions from the backtrace.
>>> >> > +stack->PopStackFrames(2);
>>
>>
>> I wonder if under some conditions we may get a different number of extra
>> frames (inlining comes to mind). What do you think of removing any number of
>> frames that belong to the runtime library - we have memory layout info for
>> that?
>
> Bad idea, imho.
> Hard to implement, slower to run (remember, this *is* a hotspot).
> The frames in question are in our run-time and we can fully control inlining.
> What is the current number of redundant frames on ARM?


And we can have output tests that verify that we remove the right
number of frames.


[v3] libstdc++/55413

2012-11-20 Thread Paolo Carlini

Hi,

tested x86_64-linux, committed mainline and 4_7-branch.

Thanks,
Paolo.


2012-11-20  Paolo Carlini  

PR libstdc++/55413
* include/bits/hashtable.h (_Hashtable<>::_M_rehash_aux): Initialize
__bbegin_bkt and __prev_bkt to avoid uninitialized warnings.
* testsuite/23_containers/unordered_set/instantiation_neg.cc: Adjust
dg-error line number.
Index: include/bits/hashtable.h
===
--- include/bits/hashtable.h(revision 193662)
+++ include/bits/hashtable.h(working copy)
@@ -1,7 +1,6 @@
 // hashtable.h header -*- C++ -*-
 
-// Copyright (C) 2007, 2008, 2009, 2010, 2011, 2012
-// Free Software Foundation, Inc.
+// Copyright (C) 2007-2012 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -1679,7 +1678,7 @@
   __bucket_type* __new_buckets = _M_allocate_buckets(__n);
   __node_type* __p = _M_begin();
   _M_before_begin()._M_nxt = nullptr;
-  std::size_t __bbegin_bkt;
+  std::size_t __bbegin_bkt = 0;
   while (__p)
{
  __node_type* __next = __p->_M_next();
@@ -1720,8 +1719,8 @@
 
   __node_type* __p = _M_begin();
   _M_before_begin()._M_nxt = nullptr;
-  std::size_t __bbegin_bkt;
-  std::size_t __prev_bkt;
+  std::size_t __bbegin_bkt = 0;
+  std::size_t __prev_bkt = 0;
   __node_type* __prev_p = nullptr;
   bool __check_bucket = false;
 
@@ -1749,8 +1748,8 @@
{
  if (__check_bucket)
{
- // Check if we shall update the next bucket because of 
insertions
- // into __prev_bkt bucket.
+ // Check if we shall update the next bucket because of
+ // insertions into __prev_bkt bucket.
  if (__prev_p->_M_nxt)
{
  std::size_t __next_bkt
Index: testsuite/23_containers/unordered_set/instantiation_neg.cc
===
--- testsuite/23_containers/unordered_set/instantiation_neg.cc  (revision 
193652)
+++ testsuite/23_containers/unordered_set/instantiation_neg.cc  (working copy)
@@ -19,7 +19,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-error "with noexcept" "" { target *-*-* } 248 }
+// { dg-error "with noexcept" "" { target *-*-* } 247 }
 
 #include 
 


[Cilkplus] Merged with trunk at revision 193607

2012-11-20 Thread Iyer, Balaji V
Cilk Plus branch was merged with trunk at revision 193607. Committed as 
revision 193665.

Thanks,

Balaji V. Iyer.


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Evgeniy Stepanov
Ok, fine.


On Tue, Nov 20, 2012 at 6:47 PM, Dmitry Vyukov  wrote:
> On Tue, Nov 20, 2012 at 6:21 PM, Konstantin Serebryany
>  wrote:
>> On Tue, Nov 20, 2012 at 6:18 PM, Evgeniy Stepanov
>>  wrote:
>>> On Tue, Nov 20, 2012 at 5:52 PM, Konstantin Serebryany
>>>  wrote:

 On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner 
 wrote:
 > On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
 >> I've applied your patch (with minor style and comment changes)
 >> upstream:
 >> http://llvm.org/viewvc/llvm-project?view=rev&revision=168356
 >> I did not have any way to test it though. Also, gmail does something
 >> horrible with patches inlined in a message, so I might have missed
 >> something.
 >
 > Doing a quick peruse through your LLVM commit, I see you grabbed the
 > PopStackFrames() addition, but the asan_linux.cc changes do not include
 > the call to PopStackFrames() after the _Unwind_Backtrace() call.
 > Specifically, the following patch hunk:
 >
 >>  _Unwind_Backtrace(Unwind_Trace, stack);
 >> > +// Pop off the two ASAN functions from the backtrace.
 >> > +stack->PopStackFrames(2);
>>>
>>>
>>> I wonder if under some conditions we may get a different number of extra
>>> frames (inlining comes to mind). What do you think of removing any number of
>>> frames that belong to the runtime library - we have memory layout info for
>>> that?
>>
>> Bad idea, imho.
>> Hard to implement, slower to run (remember, this *is* a hotspot).
>> The frames in question are in our run-time and we can fully control inlining.
>> What is the current number of redundant frames on ARM?
>
>
> And we can have output tests that verify that we remove the right
> number of frames.


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Konstantin Serebryany
http://llvm.org/viewvc/llvm-project?rev=168369&view=rev

On Tue, Nov 20, 2012 at 7:12 PM, Evgeniy Stepanov
 wrote:
> Ok, fine.
>
>
> On Tue, Nov 20, 2012 at 6:47 PM, Dmitry Vyukov  wrote:
>> On Tue, Nov 20, 2012 at 6:21 PM, Konstantin Serebryany
>>  wrote:
>>> On Tue, Nov 20, 2012 at 6:18 PM, Evgeniy Stepanov
>>>  wrote:
 On Tue, Nov 20, 2012 at 5:52 PM, Konstantin Serebryany
  wrote:
>
> On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner 
> wrote:
> > On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
> >> I've applied your patch (with minor style and comment changes)
> >> upstream:
> >> http://llvm.org/viewvc/llvm-project?view=rev&revision=168356
> >> I did not have any way to test it though. Also, gmail does something
> >> horrible with patches inlined in a message, so I might have missed
> >> something.
> >
> > Doing a quick peruse through your LLVM commit, I see you grabbed the
> > PopStackFrames() addition, but the asan_linux.cc changes do not include
> > the call to PopStackFrames() after the _Unwind_Backtrace() call.
> > Specifically, the following patch hunk:
> >
> >>  _Unwind_Backtrace(Unwind_Trace, stack);
> >> > +// Pop off the two ASAN functions from the backtrace.
> >> > +stack->PopStackFrames(2);


 I wonder if under some conditions we may get a different number of extra
 frames (inlining comes to mind). What do you think of removing any number 
 of
 frames that belong to the runtime library - we have memory layout info for
 that?
>>>
>>> Bad idea, imho.
>>> Hard to implement, slower to run (remember, this *is* a hotspot).
>>> The frames in question are in our run-time and we can fully control 
>>> inlining.
>>> What is the current number of redundant frames on ARM?
>>
>>
>> And we can have output tests that verify that we remove the right
>> number of frames.


Re: [patch i386 windows]: Fix regression about name-decoration

2012-11-20 Thread Richard Henderson
On 11/20/2012 02:25 AM, Kai Tietz wrote:
> 2012-11-20  Kai Tietz
> 
>   PR target/55268
>   * i386.c (ix86_mangle_decl_assembler_name): Use
>   SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME if defined.
>   * cygming.h (TARGET_MANGLE_DECL_ASSEMBLER_NAME): Rename
>   to SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME.

Ok.


r~


[PR middle-end/55398] Convert vec<> into a POD

2012-11-20 Thread Diego Novillo
This fixes PR 55398 by making vec<> a true POD.  I thought we could get
away with having private fields, but we can't.  We fail to pass vec<>
instances through varargs.

The patch makes every field public and mangles the field names in the
hope that no future patch will try to make use of them directly.  It's
horrible, but I could not think of anything better.

I also added two small changes to va_heap::release and
va_stack::release.  If the vector to free is NULL, they do
nothing.

Tested with clang++ as the host compiler on x86_64.


2012-11-20  Diego Novillo  

PR middle-end/55398
* vec.h (class vec_prefix): Make every field public.
Rename field alloc_ to alloc_PRIVATE_.
Rename field num_ to num_PRIVATE_.
Update all users.
(class vec): Make every field public.
Rename field pfx_ to pfx_PRIVATE_.
Rename field data_ to data_PRIVATE_.
Update all users.
(class vec): Make every field public.
Rename field vec_ to vec_PRIVATE_.
Update all users.
(va_heap::release): Do nothing if V is NULL.
(va_stack::release): Likewise.

---
 gcc/ChangeLog |   15 
 gcc/vec.c |   13 ++--
 gcc/vec.h |  203 ++---
 3 files changed, 130 insertions(+), 101 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7c07c32..21948b9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,18 @@
+2012-11-20  Diego Novillo  
+
+   PR middle-end/55398
+   * vec.h (class vec_prefix): Make every field public.
+   Rename field alloc_ to alloc_PRIVATE_.
+   Rename field num_ to num_PRIVATE_.
+   Update all users.
+   (class vec): Make every field public.
+   Rename field pfx_ to pfx_PRIVATE_.
+   Rename field data_ to data_PRIVATE_.
+   Update all users.
+   (class vec): Make every field public.
+   Rename field vec_ to vec_PRIVATE_.
+   Update all users.
+
 2012-11-20  Uros Bizjak  
 
* config/i386/i386.c (ix86_expand_call): Emit CLOBBERs in VOIDmode.
diff --git a/gcc/vec.c b/gcc/vec.c
index b213aba..3f8f550 100644
--- a/gcc/vec.c
+++ b/gcc/vec.c
@@ -121,8 +121,8 @@ vec_descriptor (const char *name, int line, const char 
*function)
 /* Account the overhead.  */
 
 void
-vec_prefix::register_overhead (size_t size, const char *name, int line,
-  const char *function)
+vec_prefix::register_overhead_PRIVATE_ (size_t size, const char *name, int 
line,
+   const char *function)
 {
   struct vec_descriptor *loc = vec_descriptor (name, line, function);
   struct ptr_hash_entry *p = XNEW (struct ptr_hash_entry);
@@ -148,7 +148,7 @@ vec_prefix::register_overhead (size_t size, const char 
*name, int line,
 /* Notice that the memory allocated for the vector has been freed.  */
 
 void
-vec_prefix::release_overhead (void)
+vec_prefix::release_overhead_PRIVATE_ (void)
 {
   PTR *slot = htab_find_slot_with_hash (ptr_hash, this,
htab_hash_pointer (this),
@@ -165,15 +165,16 @@ vec_prefix::release_overhead (void)
exponentially.  PFX is the control data for the vector.  */
 
 unsigned
-vec_prefix::calculate_allocation (vec_prefix *pfx, unsigned reserve, bool 
exact)
+vec_prefix::calculate_allocation_PRIVATE_ (vec_prefix *pfx, unsigned reserve,
+  bool exact)
 {
   unsigned alloc = 0;
   unsigned num = 0;
 
   if (pfx)
 {
-  alloc = pfx->alloc_;
-  num = pfx->num_;
+  alloc = pfx->alloc_PRIVATE_;
+  num = pfx->num_PRIVATE_;
 }
   else if (!reserve)
 /* If there's no vector, and we've not requested anything, then we
diff --git a/gcc/vec.h b/gcc/vec.h
index b9be85c..61ae9bf 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -216,11 +216,13 @@ extern void dump_vec_loc_statistics (void);
 
 class vec_prefix
 {
-protected:
+  /* FIXME - These fields should be private, but we need to cater to
+compilers that have stricter notions of PODness for types.  */
+public:
   /* Memory allocation support routines in vec.c.  */
-  void register_overhead (size_t, const char *, int, const char *);
-  void release_overhead (void);
-  static unsigned calculate_allocation (vec_prefix *, unsigned, bool);
+  void register_overhead_PRIVATE_ (size_t, const char *, int, const char *);
+  void release_overhead_PRIVATE_ (void);
+  static unsigned calculate_allocation_PRIVATE_ (vec_prefix *, unsigned, bool);
 
   /* Note that vec_prefix should be a base class for vec, but we use
  offsetof() on vector fields of tree structures (e.g.,
@@ -236,8 +238,8 @@ protected:
   friend struct va_heap;
   friend struct va_stack;
 
-  unsigned alloc_;
-  unsigned num_;
+  unsigned alloc_PRIVATE_;
+  unsigned num_PRIVATE_;
 };
 
 template class vec;
@@ -285,8 +287,8 @@ inline void
 va_heap::reserve (vec *&v, unsigned reserve, bool exact
  MEM_STAT_DECL)
 {
-  unsigned alloc = vec_prefix::calculate_allocation (v ? &v->pfx_ : 0, rese

Fix dependencies for tlink.o

2012-11-20 Thread Diego Novillo
Found while changing code in vec.h and doing incremental builds.

Committed.


2012-11-20  Diego Novillo  

* Makefile.in (tlink.o): Add dependency on VEC_H.
---
 gcc/ChangeLog   |4 
 gcc/Makefile.in |2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 21948b9..b1d1603 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,9 @@
 2012-11-20  Diego Novillo  
 
+   * Makefile.in (tlink.o): Add dependency on VEC_H.
+
+2012-11-20  Diego Novillo  
+
PR middle-end/55398
* vec.h (class vec_prefix): Make every field public.
Rename field alloc_ to alloc_PRIVATE_.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index d74e7b3..76a2ca6 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1908,7 +1908,7 @@ collect2-aix.o : collect2-aix.c $(CONFIG_H) $(SYSTEM_H) 
coretypes.h $(TM_H) \
 collect2-aix.h
 
 tlink.o: tlink.c $(DEMANGLE_H) $(HASHTAB_H) $(CONFIG_H) $(SYSTEM_H) 
coretypes.h $(TM_H) \
-$(OBSTACK_H) collect2.h intl.h $(DIAGNOSTIC_CORE_H)
+$(OBSTACK_H) collect2.h intl.h $(DIAGNOSTIC_CORE_H) $(VEC_H)
 
 lto-wrapper$(exeext): lto-wrapper.o ggc-none.o libcommon-target.a $(LIBDEPS)
+$(LINKER) $(ALL_COMPILERFLAGS) $(LDFLAGS) -o T$@ \
-- 
1.7.7.3



[PATCH,committed] AIX largetoc fixes

2012-11-20 Thread David Edelsohn
The AIX assembler prefers "la" mnemonic and syntax over "addi" for cmodel=large.

Bootstrapped on powerpc-ibm-aix7.1.0.0 and powerpc64-linux.

David

* config/rs6000/rs6000.md (largetoc_low): Revert.
(largetoc_low_aix): New.

Index: rs6000.md
===
--- rs6000.md   (revision 193665)
+++ rs6000.md   (working copy)
@@ -10354,15 +10354,22 @@
"TARGET_XCOFF && TARGET_CMODEL != CMODEL_SMALL"
"addis %0,%1+%3@u(%2)")

-(define_insn "*largetoc_low"
-  [(set (match_operand:P 0 "gpc_reg_operand" "=r,r")
-(lo_sum:P (match_operand:P 1 "gpc_reg_operand" "b,!*r")
-  (match_operand:P 2 "" "")))]
-   "TARGET_TOC && TARGET_CMODEL != CMODEL_SMALL"
+(define_insn "*largetoc_low"
+  [(set (match_operand:DI 0 "gpc_reg_operand" "=r,r")
+(lo_sum:DI (match_operand:DI 1 "gpc_reg_operand" "b,!*r")
+  (match_operand:DI 2 "" "")))]
+   "TARGET_ELF && TARGET_CMODEL != CMODEL_SMALL"
"@
 addi %0,%1,%2@l
 addic %0,%1,%2@l")

+(define_insn "*largetoc_low_aix"
+  [(set (match_operand:P 0 "gpc_reg_operand" "=r")
+(lo_sum:P (match_operand:P 1 "gpc_reg_operand" "b")
+  (match_operand:P 2 "" "")))]
+   "TARGET_XCOFF && TARGET_CMODEL != CMODEL_SMALL"
+   "la %0,%2@l(%1)")
+
 (define_insn_and_split "*tocref"
   [(set (match_operand:P 0 "gpc_reg_operand" "=b*r")
(match_operand:P 1 "small_toc_ref" "R"))]


Re: [PR middle-end/55398] Convert vec<> into a POD

2012-11-20 Thread Diego Novillo
On Tue, Nov 20, 2012 at 11:23 AM, Diego Novillo  wrote:

> 2012-11-20  Diego Novillo  
>
> PR middle-end/55398
> * vec.h (class vec_prefix): Make every field public.
> Rename field alloc_ to alloc_PRIVATE_.
> Rename field num_ to num_PRIVATE_.
> Update all users.
> (class vec): Make every field public.
> Rename field pfx_ to pfx_PRIVATE_.
> Rename field data_ to data_PRIVATE_.
> Update all users.
> (class vec): Make every field public.
> Rename field vec_ to vec_PRIVATE_.
> Update all users.
> (va_heap::release): Do nothing if V is NULL.
> (va_stack::release): Likewise.

Committed as rev 193667.


Diego.


[PATCH, RFC] PR 55403 + 55391

2012-11-20 Thread Richard Henderson
This assert looks to me like a "can this ever happen" sort of check.
It quite apparently can.

Although I'm a bit curious about the reasons we got to this point
in the 55403 instance (unaligned TCmode memory, extracting a TFmode
value), it's clear that one could intentionally write such a thing,
rather than have it happen by accident, and that it should work.

The following fills in what appears to be a blank.  I assume this
is the sort of thing you'd have intended?

I'm just doing another round of testing now...


r~
* emit-rtl.c (adjust_address_1): Handle adjust_object for size_known_p
instead of asserting it isn't set.


diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 27464da..dd3339c 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2177,7 +2177,11 @@ adjust_address_1 (rtx memref, enum machine_mode mode, 
HOST_WIDE_INT offset,
 }
   else if (attrs.size_known_p)
 {
-  gcc_assert (!adjust_object);
+  if (adjust_object)
+   {
+ attrs.expr = NULL_TREE;
+ attrs.alias = 0;
+   }
   attrs.size -= offset;
   /* ??? The store_by_pieces machinery generates negative sizes,
 so don't assert for that here.  */


[RFC] Parallel build broken on trunk.

2012-11-20 Thread Marcus Shawcroft
Folks, Parallel builds contain a race due to a missing dependency
between gengtype-lex.o and $(BCONFIG_H).

This was introduced by the commit:

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00926.html

.. which injects an include of bconfig.h into the top of
gengtype-lex.c but does not make both of the objects built from that
file dependent on bconfig.h

There is a simple fix, below, but I'm concerned that this is just
papering over the cracks, is it really correct that both the build and
host machine variants include the same config file?

Cheers
/Marcus




diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index d74e7b3..8e8f4d3 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3885,7 +3885,7 @@ build/gengenrtl.o : gengenrtl.c $(BCONFIG_H)
$(SYSTEM_H) rtl.def
 # the build-%: rule doesn't apply to them.

 gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H)
-gengtype-lex.o: $(CONFIG_H)
+gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H)
 CFLAGS-gengtype-lex.o += -DGENERATOR_FILE
 build/gengtype-lex.o: $(BCONFIG_H)


Re: [AARCH64] Update maintainers file

2012-11-20 Thread Richard Earnshaw

On 28/10/12 21:45, Gerald Pfeifer wrote:

On Tue, 23 Oct 2012, Richard Earnshaw wrote:

On 23/10/12 23:36, Steven Bosscher wrote:

Will you also add an announcement of this to the news page (home page)
and to gcc-4.8/changes.html?

I'm sure we can... :-)


You have to. :-)  Please.

Gerald


Sorry for the delay, I've been swamped with internal issues.

How does this look?

R.Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.866
diff -u -r1.866 index.html
--- index.html  8 Nov 2012 07:26:59 -   1.866
+++ index.html  20 Nov 2012 16:43:58 -
@@ -53,6 +53,11 @@
 
 
 
+ARM AArch64 support
+[2012-10-24]
+A port for AArch64, the 64-bit execution state in the ARMv8 architecture,
+has been contributed by ARM Ltd.
+
 IBM zEnterprise EC12 support
 [2012-10-10]
 Support for the latest release of the System z mainframe zEC12 has

Re: [PATCH, RFC] PR 55403 + 55391

2012-11-20 Thread Richard Sandiford
Richard Henderson  writes:
> This assert looks to me like a "can this ever happen" sort of check.
> It quite apparently can.
>
> Although I'm a bit curious about the reasons we got to this point
> in the 55403 instance (unaligned TCmode memory, extracting a TFmode
> value), it's clear that one could intentionally write such a thing,
> rather than have it happen by accident, and that it should work.
>
> The following fills in what appears to be a blank.  I assume this
> is the sort of thing you'd have intended?

Sorry, still haven't managed to reproduce this yet -- sparc bootstrap
still in slow progress, will try the alpha --with-long-double-128 thing
when I get home -- but what kind of bitfield memory were we trying to
create in the ICE case?  The idea was that "adjust_object" is only ever
true for bitfield adjustments.  We should then either be using an
integer or field mode whose size is picked up by:

  if (defattrs->size_known_p)
size = defattrs->size;

or a BLKmode whose value is passed in via adjust_bitfield_address_size.
It sounds like I missed a case where the latter was needed.

Richard


Re: [PATCH, RFC] PR 55403 + 55391

2012-11-20 Thread Richard Henderson
On 11/20/2012 08:55 AM, Richard Sandiford wrote:
> but what kind of bitfield memory were we trying to
> create in the ICE case?  The idea was that "adjust_object" is only ever
> true for bitfield adjustments.  We should then either be using an
> integer or field mode whose size is picked up by:
> 
>   if (defattrs->size_known_p)
> size = defattrs->size;
> 
> or a BLKmode whose value is passed in via adjust_bitfield_address_size.
> It sounds like I missed a case where the latter was needed.

A TFmode field of an unaligned TCmode original.  We do wind up with
a BLKmode extraction, without the _size passed in.


r~


[PATCH, RFC] PR 55415 : Pessimistic misalignment from eipa_sra pass

2012-11-20 Thread Richard Henderson
The get_pointer_alignment function can indicate that it does not know
what the alignment should be, and it always fills in worst-case values
for that case.  We should not use these worst-case values to "optimize"
the interface of a function.

At minimum I think something like the following would be good.  But
I'm unsure why we would *ever* want to lower the alignment at a function
interface.  It seems to me that we'd simply want the caller to handle
copying the data to an aligned location?

What was the use case of this code in the first place?



r~
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 3150bd6..d117389 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -2956,15 +2956,17 @@ ipa_modify_call_arguments (struct cgraph_edge *cs, 
gimple stmt,
  unsigned int align;
  unsigned HOST_WIDE_INT misalign;
 
- get_pointer_alignment_1 (base, &align, &misalign);
- misalign += (tree_to_double_int (off)
-  .sext (TYPE_PRECISION (TREE_TYPE (off))).low
-  * BITS_PER_UNIT);
- misalign = misalign & (align - 1);
- if (misalign != 0)
-   align = (misalign & -misalign);
- if (align < TYPE_ALIGN (type))
-   type = build_aligned_type (type, align);
+ if (get_pointer_alignment_1 (base, &align, &misalign))
+   {
+ misalign += (tree_to_double_int (off)
+  .sext (TYPE_PRECISION (TREE_TYPE (off))).low
+  * BITS_PER_UNIT);
+ misalign = misalign & (align - 1);
+ if (misalign != 0)
+   align = (misalign & -misalign);
+ if (align < TYPE_ALIGN (type))
+   type = build_aligned_type (type, align);
+   }
  expr = fold_build2_loc (loc, MEM_REF, type, base, off);
}
  else


libbacktrace patch committed: Always clear union in read_attribute

2012-11-20 Thread Ian Lance Taylor
http://gcc.gnu.org/ml/gcc-regression/2012-11/msg00279.html points out a
may-be-used-uninitialized warning, turned into an error, when building
libbacktrace.  The warning is incorrect: the value is initialized.  The
warning will no longer turn into an error.  But it is easy enough to
force an initialization to avoid the warning.  That is what this patch
does.  Bootstrapped and ran libbacktrace testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2012-11-20  Ian Lance Taylor  

* dwarf.c (read_attribute): Always clear val.


Index: dwarf.c
===
--- dwarf.c	(revision 193484)
+++ dwarf.c	(working copy)
@@ -654,6 +654,12 @@ read_attribute (enum dwarf_form form, st
 		const unsigned char *dwarf_str, size_t dwarf_str_size,
 		struct attr_val *val)
 {
+  /* Avoid warnings about val.u.FIELD may be used uninitialized if
+ this function is inlined.  The warnings aren't valid but can
+ occur because the different fields are set and used
+ conditionally.  */
+  memset (val, 0, sizeof *val);
+
   switch (form)
 {
 case DW_FORM_addr:


Re: [PATCH, RFC] PR 55403 + 55391

2012-11-20 Thread Richard Sandiford
Richard Henderson  writes:
> On 11/20/2012 08:55 AM, Richard Sandiford wrote:
>> but what kind of bitfield memory were we trying to
>> create in the ICE case?  The idea was that "adjust_object" is only ever
>> true for bitfield adjustments.  We should then either be using an
>> integer or field mode whose size is picked up by:
>> 
>>   if (defattrs->size_known_p)
>> size = defattrs->size;
>> 
>> or a BLKmode whose value is passed in via adjust_bitfield_address_size.
>> It sounds like I missed a case where the latter was needed.
>
> A TFmode field of an unaligned TCmode original.  We do wind up with
> a BLKmode extraction, without the _size passed in.

Gah.  How about this patch, currently bootstrapping on x86_64-linux-gnu
as a sanity check?  The last instance seems glaringly obvious in
hindsight :-(

Richard


gcc/
* expmed.c (store_bit_field_1): Use adjust_bitfield_address_size
rather than adjust_bitfield_address to change the mode of a reference.
(extract_bit_field_1): Likewise.

Index: gcc/expmed.c
===
--- gcc/expmed.c2012-11-20 09:55:26.0 +
+++ gcc/expmed.c2012-11-20 17:24:09.722871322 +
@@ -645,7 +645,7 @@ store_bit_field_1 (rtx str_rtx, unsigned
 if (imode != GET_MODE (op0))
   {
if (MEM_P (op0))
- op0 = adjust_bitfield_address (op0, imode, 0);
+ op0 = adjust_bitfield_address_size (op0, imode, 0, MEM_SIZE (op0));
else
  {
gcc_assert (imode != BLKmode);
@@ -1380,7 +1380,7 @@ extract_bit_field_1 (rtx str_rtx, unsign
 if (imode != GET_MODE (op0))
   {
if (MEM_P (op0))
- op0 = adjust_bitfield_address (op0, imode, 0);
+ op0 = adjust_bitfield_address_size (op0, imode, 0, MEM_SIZE (op0));
else if (imode != BLKmode)
  {
op0 = gen_lowpart (imode, op0);
@@ -1403,10 +1403,10 @@ extract_bit_field_1 (rtx str_rtx, unsign
  }
else
  {
-   rtx mem = assign_stack_temp (GET_MODE (op0),
-GET_MODE_SIZE (GET_MODE (op0)));
+   HOST_WIDE_INT size = GET_MODE_SIZE (GET_MODE (op0));
+   rtx mem = assign_stack_temp (GET_MODE (op0), size);
emit_move_insn (mem, op0);
-   op0 = adjust_bitfield_address (mem, BLKmode, 0);
+   op0 = adjust_bitfield_address_size (mem, BLKmode, 0, size);
  }
   }
   }


[patch] PR tree-optimization/55350: invalid pointer operand to PLUS_EXPR

2012-11-20 Thread Aldy Hernandez
The problem here is that the SLSR pass is promoting a POINTER_PLUS_EXPR 
to a PLUS_EXPR.  Since pointer arithmetic is invalid in 
{PLUS,MINUS}_EXPR's, the gimple verifier chokes on the invalid statement.


Fixed by maintaining the POINTER_PLUS_EXPR when appropriate.

OK for trunk?
commit ae7b615a11be6a0c5cc00f7ea0bf29c142931490
Author: Aldy Hernandez 
Date:   Tue Nov 20 11:20:58 2012 -0600

PR tree-optimization/55350
* gimple-ssa-strength-reduction.c (replace_dependent): Handle
POINTER_{PLUS,MINUS}_EXPR correctly.

diff --git a/gcc/gimple-ssa-strength-reduction.c 
b/gcc/gimple-ssa-strength-reduction.c
index 8e2a247..65fc6b1 100644
--- a/gcc/gimple-ssa-strength-reduction.c
+++ b/gcc/gimple-ssa-strength-reduction.c
@@ -1643,10 +1643,19 @@ replace_dependent (slsr_cand_t c, enum tree_code 
cand_code)
 
   basis = lookup_cand (c->basis);
   basis_name = gimple_assign_lhs (basis->cand_stmt);
-  incr_type = TREE_TYPE (gimple_assign_rhs1 (c->cand_stmt));
-  code = PLUS_EXPR;
+  if (cand_code == POINTER_PLUS_EXPR)
+{
+  incr_type = sizetype;
+  code = cand_code;
+}
+  else
+{
+  incr_type = TREE_TYPE (gimple_assign_rhs1 (c->cand_stmt));
+  code = PLUS_EXPR;
+}
 
-  if (bump.is_negative ())
+  if (bump.is_negative ()
+  && cand_code != POINTER_PLUS_EXPR)
 {
   code = MINUS_EXPR;
   bump = -bump;
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr55350.c 
b/gcc/testsuite/gcc.c-torture/compile/pr55350.c
new file mode 100644
index 000..f10daea
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr55350.c
@@ -0,0 +1,8 @@
+void
+foo (__INTPTR_TYPE__ x, __INTPTR_TYPE__ y)
+{
+  int i;
+  void **a = (void *)  (8UL * (x / 8UL));
+  for (i = 0; i < x; i++)
+a[i] = (void *) y;
+}


Re: [PR middle-end/55398] Convert vec<> into a POD

2012-11-20 Thread Andreas Tobler
On 20.11.12 17:27, Diego Novillo wrote:
> On Tue, Nov 20, 2012 at 11:23 AM, Diego Novillo  wrote:
> 
>> 2012-11-20  Diego Novillo  
>>
>> PR middle-end/55398
>> * vec.h (class vec_prefix): Make every field public.
>> Rename field alloc_ to alloc_PRIVATE_.
>> Rename field num_ to num_PRIVATE_.
>> Update all users.
>> (class vec): Make every field public.
>> Rename field pfx_ to pfx_PRIVATE_.
>> Rename field data_ to data_PRIVATE_.
>> Update all users.
>> (class vec): Make every field public.
>> Rename field vec_ to vec_PRIVATE_.
>> Update all users.
>> (va_heap::release): Do nothing if V is NULL.
>> (va_stack::release): Likewise.
> 
> Committed as rev 193667.

Completed bootstrap on x86_64-unknown-freebsd10.0 with a 4.2.1 gcc.
Which was failing before with a bus error in genautomata:

(gdb) bt
#0  0x0008010410f9 in ?? () from /lib/libc.so.7
#1  0x000801046ac9 in free () from /lib/libc.so.7
#2  0x0041db18 in va_heap::release (
v=@0x7fffd860: 0x641560 )
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/vec.h:317
#3  0x0041ddb1 in vec::release (
this=0x7fffd860)
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/vec.h:1485
#4  0x00407b29 in copy_equiv_class (to=0x7fffd860, from=...)
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/genautomata.c:6030
#5  0x00408406 in evaluate_equiv_classes (automaton=0x8032c1470,
equiv_classes=0x7fffd860)
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/genautomata.c:6118
#6  0x004114b2 in minimize_DFA (automaton=0x8032c1470)
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/genautomata.c:6260
#7  0x004185d0 in build_automaton (automaton=0x8032c1470)
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/genautomata.c:6350
#8  0x00418e07 in create_automata ()
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/genautomata.c:6779
#9  0x00418eb3 in generate ()
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/genautomata.c:9203
#10 0x0041b8d9 in expand_automata ()
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/genautomata.c:9465
---Type  to continue, or q  to quit---bt fullq
#11 0x0041c3fc in main (argc=3, argv=0x7fffda08)
at /home/andreast/devel/gcc/gcc-head/gcc/gcc/genautomata.c:9656


Thank you very much!

Andreas



Re: [patch] PR tree-optimization/55350: invalid pointer operand to PLUS_EXPR

2012-11-20 Thread Jakub Jelinek
On Tue, Nov 20, 2012 at 11:46:06AM -0600, Aldy Hernandez wrote:
> The problem here is that the SLSR pass is promoting a
> POINTER_PLUS_EXPR to a PLUS_EXPR.  Since pointer arithmetic is
> invalid in {PLUS,MINUS}_EXPR's, the gimple verifier chokes on the
> invalid statement.
> 
> Fixed by maintaining the POINTER_PLUS_EXPR when appropriate.
> 
> OK for trunk?

Ok, thanks.

> -  if (bump.is_negative ())
> +  if (bump.is_negative ()
> +  && cand_code != POINTER_PLUS_EXPR)
>  {
>code = MINUS_EXPR;
>bump = -bump;

I wonder if this isn't unsafe even when bump is the shwi minimum
(say LONG_MIN for LP64 target/64-bit HWI).  But sure, it is preexisting
code, so perhaps something for Bill to look at later.

Jakub


Re: sparc bootstrap still broken

2012-11-20 Thread Peter Bergner
On Tue, 2012-11-20 at 13:00 +0400, Konstantin Serebryany wrote:
> On Tue, Nov 20, 2012 at 12:19 PM, David Miller  wrote:
> > From: Konstantin Serebryany 
> > Date: Tue, 20 Nov 2012 11:41:03 +0400
> >
> >> Ok. Will this work?
> >>
> >> // Are we using 32-bit or 64-bit syscalls?
> >> // x32 (which defines __x86_64__) has __WORDSIZE == 32
> >> // but it still needs to use 64-bit syscalls.
> >> #if defined(__x86_64__) || __WORDSIZE == 64
> >> # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
> >> #else
> >> # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 0
> >> #endif
> >
> > Of course, as it matches the test H.J. Liu's patch used.
> >
> > Please, at a bare minimum, give him some credit for this fix.
> 
> Done: http://llvm.org/viewvc/llvm-project?rev=168358&view=rev

I assume we are just waiting for someone to commit this to the GCC src,
correct?  David (Miller), were you going to do that?  I'd like that
change committed before I commit our ppc asan changes.

Peter




Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Peter Bergner
On Tue, 2012-11-20 at 17:52 +0400, Konstantin Serebryany wrote:
> On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner  wrote:
> > Doing a quick peruse through your LLVM commit, I see you grabbed the
> > PopStackFrames() addition, but the asan_linux.cc changes do not include
> > the call to PopStackFrames() after the _Unwind_Backtrace() call.
> > Specifically, the following patch hunk:
> >
> >>  _Unwind_Backtrace(Unwind_Trace, stack);
> >> > +// Pop off the two ASAN functions from the backtrace.
> >> > +stack->PopStackFrames(2);
> 
> Ah, indeed, I missed that.
> Since the patch also affects ARM, I'd like to hear from Evgeniy Stepanov
> (or we may decouple powerpc from arm)

I specifically added that call for all architectures that use
_Unwind_Backtrace, since I believe they will all see the two
extra ASAN functions on the call stack since that is an artifact
of how _Unwind_Backtrace works.  That being said, it would be good
for someone to confirm that change works for ARM...or SPARC
once David gets the SPARC changes ready since he seems to me
not far behind us (ie, POWER).

Peter




Re: RFA: patch to fix PR19398

2012-11-20 Thread Uros Bizjak
On Mon, Nov 19, 2012 at 8:55 AM, Uros Bizjak  wrote:
>> The following patch fixes
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398
>>
>> Uros, there is i386.md part for which I need an approval.  Without this
>> change, GCC will still generate the same code even if LRA uses an
>> alternative with 'm' constraint.
>>
>> 2012-11-18  Vladimir Makarov  
>>
>> PR target/19398
>> * lra-constraints.c (process_alt_operands): Discourage reloads
>> through secodnary memory.
>> * config/i386/i386.md (fix_trunc?f?i_sse): Remove peephole2
>> patterns.
>
> Thanks!
>
> Please note that i386.md change is not correct, it is peephole2 with
> "Shorten x87->SSE reload sequences ..." comment that is not effective
> anymore with your patch and should now be removed. The peephole2s that
> your patch removes undo LRA transformation for targets that *do not*
> benefit from MEM->REG operation for this particular FIX RTX. (Also,
> please note that your patch includes movti_internal_rex64 change that
> was already reverted due to better fix).
>
> Please remove mentioned peephole2 instead. The test from the PR will
> show effects of LRA change for all targets, other than core2i7_64, k8
> and generic 64bit targets.
>
> The patch that removes mentioned peephole2 from i386.md is pre-approved.

I have merged my x86 target patch that removes correct peephole2 and
associated defines with Vlad's patch and committed everything
(including testcase) to mainline SVN.

Also, the patch includes macroization of a couple of RTXes in this area.

2012-11-20  Uros Bizjak  

* config/i386/i386.md (fix_trunc_sse): Macroize
insn from fix_trunc{si,di}_sse using SWI48 mode iterator.
(peephole2 to avoid vector decoded forms): Macroize peephole2
using MODEF mode iterator.  Use SWI48 mode iterator instead of SWI48x.

2012-11-20  Uros Bizjak  

PR target/19398
* config/i386/i386.md
(peephole2 to shorten x87->SSE reload sequences): Remove peephole2.
* config/i386/i386.h (enum ix86_tune_indices)
: Remove.
(TARGET_SHORTEN_X87_SSE): Remove.
* config/i386/i386.c (initial_ix86_tune_features): Update.

2012-11-20  Vladimir Makarov  

PR target/19398
* lra-constraints.c (process_alt_operands): Discourage reloads
through secodnary memory.

testsuite/ChangeLog:

2012-11-20  Uros Bizjak  

PR target/19398
* gcc.target/i386/pr19398.c: New test.

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

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 193625)
+++ config/i386/i386.c  (working copy)
@@ -1855,9 +1855,6 @@ static unsigned int initial_ix86_tune_features[X86
   /* X86_TUNE_EXT_80387_CONSTANTS */
   m_PPRO | m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_K6_GEODE | m_ATHLON_K8 | 
m_GENERIC,
 
-  /* X86_TUNE_SHORTEN_X87_SSE */
-  ~m_K8,
-
   /* X86_TUNE_AVOID_VECTOR_DECODE */
   m_CORE2I7_64 | m_K8 | m_GENERIC64,
 
Index: config/i386/i386.h
===
--- config/i386/i386.h  (revision 193625)
+++ config/i386/i386.h  (working copy)
@@ -314,7 +314,6 @@ enum ix86_tune_indices {
   X86_TUNE_PAD_RETURNS,
   X86_TUNE_PAD_SHORT_FUNCTION,
   X86_TUNE_EXT_80387_CONSTANTS,
-  X86_TUNE_SHORTEN_X87_SSE,
   X86_TUNE_AVOID_VECTOR_DECODE,
   X86_TUNE_PROMOTE_HIMODE_IMUL,
   X86_TUNE_SLOW_IMUL_IMM32_MEM,
@@ -408,7 +407,6 @@ extern unsigned char ix86_tune_features[X86_TUNE_L
ix86_tune_features[X86_TUNE_PAD_SHORT_FUNCTION]
 #define TARGET_EXT_80387_CONSTANTS \
ix86_tune_features[X86_TUNE_EXT_80387_CONSTANTS]
-#define TARGET_SHORTEN_X87_SSE ix86_tune_features[X86_TUNE_SHORTEN_X87_SSE]
 #define TARGET_AVOID_VECTOR_DECODE \
ix86_tune_features[X86_TUNE_AVOID_VECTOR_DECODE]
 #define TARGET_TUNE_PROMOTE_HIMODE_IMUL \
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 193625)
+++ config/i386/i386.md (working copy)
@@ -4465,61 +4465,35 @@
   "operands[2] = gen_reg_rtx (SImode);")
 
 ;; When SSE is available, it is always faster to use it!
-(define_insn "fix_truncdi_sse"
-  [(set (match_operand:DI 0 "register_operand" "=r,r")
-   (fix:DI (match_operand:MODEF 1 "nonimmediate_operand" "x,m")))]
-  "TARGET_64BIT && SSE_FLOAT_MODE_P (mode)
+(define_insn "fix_trunc_sse"
+  [(set (match_operand:SWI48 0 "register_operand" "=r,r")
+   (fix:SWI48 (match_operand:MODEF 1 "nonimmediate_operand" "x,m")))]
+  "SSE_FLOAT_MODE_P (mode)
&& (!TARGET_FISTTP || TARGET_SSE_MATH)"
-  "%vcvtt2si{q}\t{%1, %0|%0, %1}"
+  "%vcvtt2si\t{%1, %0|%0, %1}"
   [(set_attr "type" "sseicvt")
(set_attr "prefix" "maybe_vex")
-   (set_attr "prefix_rex" "1")
-   (set_attr "mode" "")
+   (set (attr "prefix_rex")
+   (if_then_else
+ (match_test "mode == DImode")
+  

Re: sparc bootstrap still broken

2012-11-20 Thread David Miller
From: Peter Bergner 
Date: Tue, 20 Nov 2012 12:08:00 -0600

> On Tue, 2012-11-20 at 13:00 +0400, Konstantin Serebryany wrote:
>> On Tue, Nov 20, 2012 at 12:19 PM, David Miller  wrote:
>> > From: Konstantin Serebryany 
>> > Date: Tue, 20 Nov 2012 11:41:03 +0400
>> >
>> >> Ok. Will this work?
>> >>
>> >> // Are we using 32-bit or 64-bit syscalls?
>> >> // x32 (which defines __x86_64__) has __WORDSIZE == 32
>> >> // but it still needs to use 64-bit syscalls.
>> >> #if defined(__x86_64__) || __WORDSIZE == 64
>> >> # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
>> >> #else
>> >> # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 0
>> >> #endif
>> >
>> > Of course, as it matches the test H.J. Liu's patch used.
>> >
>> > Please, at a bare minimum, give him some credit for this fix.
>> 
>> Done: http://llvm.org/viewvc/llvm-project?rev=168358&view=rev
> 
> I assume we are just waiting for someone to commit this to the GCC src,
> correct?  David (Miller), were you going to do that?  I'd like that
> change committed before I commit our ppc asan changes.

The problem is there are other dependencies in those two commits, the
change doesn't apply cleanly.

This situation is a very serious mess, and a merge burdon like this
really shouldn't fall upon the gcc community at large.


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Konstantin Serebryany
Evgeniy, my change broke the ARM Android runs:
sanitizer_common/sanitizer_stacktrace.cc:147 "((size > count)) != (0)"
(0x0, 0x0)

Could you please take a look?

On Tue, Nov 20, 2012 at 6:01 PM, Peter Bergner  wrote:
> On Tue, 2012-11-20 at 17:52 +0400, Konstantin Serebryany wrote:
>> On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner  wrote:
>> > Doing a quick peruse through your LLVM commit, I see you grabbed the
>> > PopStackFrames() addition, but the asan_linux.cc changes do not include
>> > the call to PopStackFrames() after the _Unwind_Backtrace() call.
>> > Specifically, the following patch hunk:
>> >
>> >>  _Unwind_Backtrace(Unwind_Trace, stack);
>> >> > +// Pop off the two ASAN functions from the backtrace.
>> >> > +stack->PopStackFrames(2);
>>
>> Ah, indeed, I missed that.
>> Since the patch also affects ARM, I'd like to hear from Evgeniy Stepanov
>> (or we may decouple powerpc from arm)
>
> I specifically added that call for all architectures that use
> _Unwind_Backtrace, since I believe they will all see the two
> extra ASAN functions on the call stack since that is an artifact
> of how _Unwind_Backtrace works.  That being said, it would be good
> for someone to confirm that change works for ARM...or SPARC
> once David gets the SPARC changes ready since he seems to me
> not far behind us (ie, POWER).
>
> Peter
>
>


Re: sparc bootstrap still broken

2012-11-20 Thread Konstantin Serebryany
>> I assume we are just waiting for someone to commit this to the GCC src,

One possible value of 'someone' is kcc (me), but I *may* not be able
to do it until ~ Monday.
Other possible values of 'someone' are wmi and dvyukov

>> correct?  David (Miller), were you going to do that?  I'd like that
>> change committed before I commit our ppc asan changes.
>
> The problem is there are other dependencies in those two commits, the
> change doesn't apply cleanly.
>
> This situation is a very serious mess,

Agree. I am sorry.

> and a merge burdon like this
> really shouldn't fall upon the gcc community at large.

I really need your help to resolve this mess.
Your comments on how to automate pullbacks from upstream are welcome
here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376

--kcc


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Peter Bergner
On Tue, 2012-11-20 at 18:18 +0400, Evgeniy Stepanov wrote:

> I wonder if under some conditions we may get a different number of
> extra frames (inlining comes to mind). What do you think of removing
> any number of frames that belong to the runtime library - we have
> memory layout info for that?

How about the following hack that needs to be cleaned up, but does
work for me.  It scans through the trace looking for the frame pointer
that is passed in and if it finds it, it pops the stack up to that
point.  If it doesn't find it (a bug?), it just leaves the trace
alone.

Maybe it fixes the ARM Android issue you just ran into?

Peter



diff -urpN -X /home/bergner/cvs/dontdiff 
gcc-fsf-mainline-kcc/libsanitizer/asan/asan_linux.cc 
gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc
--- gcc-fsf-mainline-kcc/libsanitizer/asan/asan_linux.cc2012-11-20 
12:52:33.961664485 -0600
+++ gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc   2012-11-20 
11:28:00.646245908 -0600
@@ -141,12 +141,19 @@ uptr Unwind_GetIP(struct _Unwind_Context
 #endif
 }
 
+uptr Unwind_GetBP(struct _Unwind_Context *ctx) {
+  return _Unwind_GetCFA(ctx);
+}
+
 _Unwind_Reason_Code Unwind_Trace(struct _Unwind_Context *ctx,
 void *param) {
   StackTrace *b = (StackTrace*)param;
   CHECK(b->size < b->max_size);
   uptr pc = Unwind_GetIP(ctx);
-  b->trace[b->size++] = pc;
+  uptr bp = Unwind_GetBP(ctx);
+  b->trace[b->size] = pc;
+  b->frame[b->size] = bp;
+  b->size++;
   if (b->size == b->max_size) return UNWIND_STOP;
   return UNWIND_CONTINUE;
 }
@@ -158,8 +165,13 @@ void GetStackTrace(StackTrace *stack, up
 stack->max_size = max_s;
 #if defined(__arm__) || defined(__powerpc__) || defined(__powerpc64__)
 _Unwind_Backtrace(Unwind_Trace, stack);
-// Pop off the two ASAN functions from the backtrace.
-stack->PopStackFrames(2);
+// Attempt to pop off the ASAN functions from the backtrace.
+uptr cnt;
+for (cnt = 0; cnt < stack->size; cnt++)
+  if (stack->frame[cnt] == bp) {
+   stack->PopStackFrames(cnt);
+   break;
+  }
 #else
 if (!asan_inited) return;
 if (AsanThread *t = asanThreadRegistry().GetCurrent())
diff -urpN -X /home/bergner/cvs/dontdiff 
gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc 
gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc
--- gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc  
2012-11-20 11:42:08.834439704 -0600
+++ gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc 
2012-11-20 12:59:29.896106625 -0600
@@ -144,7 +144,8 @@ void StackTrace::PopStackFrames(uptr cou
   CHECK(size > count);
   size -= count;
   for (uptr i = 0; i < size; i++) {
-trace[i] = trace[i + count];
+trace[i] = trace[i+count];
+frame[i] = frame[i+count];
   }
 }
 
diff -urpN -X /home/bergner/cvs/dontdiff 
gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h 
gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.h
--- gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h   
2012-11-20 11:42:08.821389243 -0600
+++ gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.h  
2012-11-20 11:12:44.551390980 -0600
@@ -23,6 +23,7 @@ struct StackTrace {
   uptr size;
   uptr max_size;
   uptr trace[kStackTraceMax];
+  uptr frame[kStackTraceMax];  // For use by _Unwind_Backtrace architectures.
   static void PrintStack(const uptr *addr, uptr size,
  bool symbolize, const char *strip_file_prefix,
  SymbolizeCallback symbolize_callback);




Re: sparc bootstrap still broken

2012-11-20 Thread David Miller
From: Konstantin Serebryany 
Date: Tue, 20 Nov 2012 23:02:36 +0400

> I really need your help to resolve this mess.

I thought it was abundantly clear that the burdon falls upon the ASAN
folks, since they are the ones who care about the external dependency.

Nobody else inside of the GCC community cares about that.

Other examples of identical situations were given, including libffi
and GO.  Where it is %100 up to the maintainer of those modules to
deal with the merge hassles created by the external dependency, and to
shield the GCC development process completely from any part of that.

Finally, a bugzilla entry with a very limited audience is absolutely
not the appropriate place to discuss this issue.  The GCC mailing
lists are.


Re: sparc bootstrap still broken

2012-11-20 Thread Konstantin Serebryany
On Tue, Nov 20, 2012 at 11:09 PM, David Miller  wrote:
> From: Konstantin Serebryany 
> Date: Tue, 20 Nov 2012 23:02:36 +0400
>
>> I really need your help to resolve this mess.
>
> I thought it was abundantly clear that the burdon falls upon the ASAN
> folks, since they are the ones who care about the external dependency.
>
> Nobody else inside of the GCC community cares about that.

If nobody else in the GCC community cares about ASAN, we should
disable the SPARC build and
let us handle the issue without rush.
We are interested in SPARC, but much less than in our own sanity.

--kcc

>
> Other examples of identical situations were given, including libffi
> and GO.  Where it is %100 up to the maintainer of those modules to
> deal with the merge hassles created by the external dependency, and to
> shield the GCC development process completely from any part of that.
>
> Finally, a bugzilla entry with a very limited audience is absolutely
> not the appropriate place to discuss this issue.  The GCC mailing
> lists are.


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Konstantin Serebryany
On Tue, Nov 20, 2012 at 11:08 PM, Peter Bergner  wrote:
> On Tue, 2012-11-20 at 18:18 +0400, Evgeniy Stepanov wrote:
>
>> I wonder if under some conditions we may get a different number of
>> extra frames (inlining comes to mind). What do you think of removing
>> any number of frames that belong to the runtime library - we have
>> memory layout info for that?
>
> How about the following hack that needs to be cleaned up, but does
> work for me.  It scans through the trace looking for the frame pointer
> that is passed in and if it finds it, it pops the stack up to that
> point.  If it doesn't find it (a bug?), it just leaves the trace
> alone.
>
> Maybe it fixes the ARM Android issue you just ran into?
>
> Peter
>
>
>
> diff -urpN -X /home/bergner/cvs/dontdiff 
> gcc-fsf-mainline-kcc/libsanitizer/asan/asan_linux.cc 
> gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc
> --- gcc-fsf-mainline-kcc/libsanitizer/asan/asan_linux.cc2012-11-20 
> 12:52:33.961664485 -0600
> +++ gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc   2012-11-20 
> 11:28:00.646245908 -0600
> @@ -141,12 +141,19 @@ uptr Unwind_GetIP(struct _Unwind_Context
>  #endif
>  }
>
> +uptr Unwind_GetBP(struct _Unwind_Context *ctx) {
> +  return _Unwind_GetCFA(ctx);
> +}
> +
>  _Unwind_Reason_Code Unwind_Trace(struct _Unwind_Context *ctx,
>  void *param) {
>StackTrace *b = (StackTrace*)param;
>CHECK(b->size < b->max_size);
>uptr pc = Unwind_GetIP(ctx);
> -  b->trace[b->size++] = pc;
> +  uptr bp = Unwind_GetBP(ctx);
> +  b->trace[b->size] = pc;
> +  b->frame[b->size] = bp;
> +  b->size++;
>if (b->size == b->max_size) return UNWIND_STOP;
>return UNWIND_CONTINUE;
>  }
> @@ -158,8 +165,13 @@ void GetStackTrace(StackTrace *stack, up
>  stack->max_size = max_s;
>  #if defined(__arm__) || defined(__powerpc__) || defined(__powerpc64__)
>  _Unwind_Backtrace(Unwind_Trace, stack);
> -// Pop off the two ASAN functions from the backtrace.
> -stack->PopStackFrames(2);
> +// Attempt to pop off the ASAN functions from the backtrace.
> +uptr cnt;
> +for (cnt = 0; cnt < stack->size; cnt++)
> +  if (stack->frame[cnt] == bp) {
> +   stack->PopStackFrames(cnt);
> +   break;
> +  }
>  #else
>  if (!asan_inited) return;
>  if (AsanThread *t = asanThreadRegistry().GetCurrent())
> diff -urpN -X /home/bergner/cvs/dontdiff 
> gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc 
> gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc
> --- 
> gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc  
> 2012-11-20 11:42:08.834439704 -0600
> +++ 
> gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc 
> 2012-11-20 12:59:29.896106625 -0600
> @@ -144,7 +144,8 @@ void StackTrace::PopStackFrames(uptr cou
>CHECK(size > count);
>size -= count;
>for (uptr i = 0; i < size; i++) {
> -trace[i] = trace[i + count];
> +trace[i] = trace[i+count];
> +frame[i] = frame[i+count];
>}
>  }
>
> diff -urpN -X /home/bergner/cvs/dontdiff 
> gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h 
> gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.h
> --- gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h 
>   2012-11-20 11:42:08.821389243 -0600
> +++ 
> gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.h  
> 2012-11-20 11:12:44.551390980 -0600
> @@ -23,6 +23,7 @@ struct StackTrace {
>uptr size;
>uptr max_size;
>uptr trace[kStackTraceMax];
> +  uptr frame[kStackTraceMax];  // For use by _Unwind_Backtrace architectures.

This is bad. The objects of this type are already too big, we should
not make them 2x larger.
Hopefully Evgeniy can handle this tomorrow.

--kcc


>static void PrintStack(const uptr *addr, uptr size,
>   bool symbolize, const char *strip_file_prefix,
>   SymbolizeCallback symbolize_callback);
>
>


Re: [PATCH, RFC] PR 55403 + 55391

2012-11-20 Thread Richard Henderson
On 11/20/2012 09:29 AM, Richard Sandiford wrote:
> Gah.  How about this patch, currently bootstrapping on x86_64-linux-gnu
> as a sanity check?  The last instance seems glaringly obvious in
> hindsight :-(
> 
> Richard
> 
> 
> gcc/
>   * expmed.c (store_bit_field_1): Use adjust_bitfield_address_size
>   rather than adjust_bitfield_address to change the mode of a reference.
>   (extract_bit_field_1): Likewise.

That patch does fix my ICE.

It looks all good, too.  As you say, glaringly obvious even.  ;-)


r~


Re: [PR middle-end/55398] Convert vec<> into a POD

2012-11-20 Thread Jakub Jelinek
On Tue, Nov 20, 2012 at 11:27:06AM -0500, Diego Novillo wrote:
> On Tue, Nov 20, 2012 at 11:23 AM, Diego Novillo  wrote:
> 
> > 2012-11-20  Diego Novillo  
> >
> > PR middle-end/55398
> > * vec.h (class vec_prefix): Make every field public.
> > Rename field alloc_ to alloc_PRIVATE_.
> > Rename field num_ to num_PRIVATE_.
> > Update all users.
> > (class vec): Make every field public.
> > Rename field pfx_ to pfx_PRIVATE_.
> > Rename field data_ to data_PRIVATE_.
> > Update all users.
> > (class vec): Make every field public.
> > Rename field vec_ to vec_PRIVATE_.
> > Update all users.
> > (va_heap::release): Do nothing if V is NULL.
> > (va_stack::release): Likewise.
> 
> Committed as rev 193667.

As discussed on IRC, the uglification unfortunately also affects day to day
use of gcc under gdb.  I don't see the point in uglifying vec_prefix fields,
from vec vec_prefix shouldn't be available except of direct use of the
uglified/poisoned fields, and the following patch also renames the vec<> fields,
so that they all have vec in their names and poisons them at the end of
vec.h.

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

2012-11-20  Jakub Jelinek  

* vec.h (class vec_prefix): Change into struct.
Rename field alloc_PRIVATE_ back to alloc_.
Rename field num_PRIVATE_ to num_.
Update all users.
(class vec): Rename field pfx_PRIVATE_ to vecpfx_.
Rename field data_PRIVATE_ to vecdata_.
Update all users.
(class vec): Make every field public.
Rename field vec_PRIVATE_ back to vec_.
Update all users.

--- gcc/vec.h.jj2012-11-20 18:29:44.0 +0100
+++ gcc/vec.h   2012-11-20 18:40:40.977290143 +0100
@@ -214,15 +214,15 @@ extern void dump_vec_loc_statistics (voi
 /* Control data for vectors.  This contains the number of allocated
and used slots inside a vector.  */
 
-class vec_prefix
+struct vec_prefix
 {
   /* FIXME - These fields should be private, but we need to cater to
 compilers that have stricter notions of PODness for types.  */
-public:
+
   /* Memory allocation support routines in vec.c.  */
-  void register_overhead_PRIVATE_ (size_t, const char *, int, const char *);
-  void release_overhead_PRIVATE_ (void);
-  static unsigned calculate_allocation_PRIVATE_ (vec_prefix *, unsigned, bool);
+  void register_overhead (size_t, const char *, int, const char *);
+  void release_overhead (void);
+  static unsigned calculate_allocation (vec_prefix *, unsigned, bool);
 
   /* Note that vec_prefix should be a base class for vec, but we use
  offsetof() on vector fields of tree structures (e.g.,
@@ -238,8 +238,8 @@ public:
   friend struct va_heap;
   friend struct va_stack;
 
-  unsigned alloc_PRIVATE_;
-  unsigned num_PRIVATE_;
+  unsigned alloc_;
+  unsigned num_;
 };
 
 template class vec;
@@ -287,8 +287,8 @@ inline void
 va_heap::reserve (vec *&v, unsigned reserve, bool exact
  MEM_STAT_DECL)
 {
-  unsigned alloc = vec_prefix::calculate_allocation_PRIVATE_ (
- v ? &v->pfx_PRIVATE_ : 0, reserve, exact);
+  unsigned alloc
+= vec_prefix::calculate_allocation (v ? &v->vecpfx_ : 0, reserve, exact);
   if (!alloc)
 {
   release (v);
@@ -296,7 +296,7 @@ va_heap::reserve (vecpfx_PRIVATE_.release_overhead_PRIVATE_ ();
+v->vecpfx_.release_overhead ();
 
   size_t size = vec::embedded_size (alloc);
   unsigned nelem = v ? v->length () : 0;
@@ -304,7 +304,7 @@ va_heap::reserve (vecembedded_init (alloc, nelem);
 
   if (GATHER_STATISTICS)
-v->pfx_PRIVATE_.register_overhead_PRIVATE_ (size FINAL_PASS_MEM_STAT);
+v->vecpfx_.register_overhead (size FINAL_PASS_MEM_STAT);
 }
 
 
@@ -318,7 +318,7 @@ va_heap::release (vecpfx_PRIVATE_.release_overhead_PRIVATE_ ();
+v->vecpfx_.release_overhead ();
   ::free (v);
   v = NULL;
 }
@@ -354,8 +354,8 @@ void
 va_gc::reserve (vec *&v, unsigned reserve, bool exact
MEM_STAT_DECL)
 {
-  unsigned alloc = vec_prefix::calculate_allocation_PRIVATE_ (
- v ? &v->pfx_PRIVATE_ : 0, reserve, exact);
+  unsigned alloc
+= vec_prefix::calculate_allocation (v ? &v->vecpfx_ : 0, reserve, exact);
   if (!alloc)
 {
   ::ggc_free (v);
@@ -423,9 +423,9 @@ void
 va_stack::alloc (vec &v, unsigned nelems,
 vec *space)
 {
-  v.vec_PRIVATE_ = space;
-  register_stack_vec (static_cast (v.vec_PRIVATE_));
-  v.vec_PRIVATE_->embedded_init (nelems, 0);
+  v.vec_ = space;
+  register_stack_vec (static_cast (v.vec_));
+  v.vec_->embedded_init (nelems, 0);
 }
 
 
@@ -452,16 +452,16 @@ va_stack::reserve (vecpfx_PRIVATE_.num_PRIVATE_;
+  nelems += v->vecpfx_.num_;
   vec *oldvec = v;
   v = NULL;
   va_heap::reserve (reinterpret_cast *&>(v), nelems,
exact);
   if (v && oldvec)
 {
-  v->pfx_PRIVATE_.num_PRIVATE_ = oldvec->length ();
-  memcpy (v->data_PRIVATE_,
- oldvec-

Re: sparc bootstrap still broken

2012-11-20 Thread David Miller
From: Konstantin Serebryany 
Date: Tue, 20 Nov 2012 23:19:51 +0400

> On Tue, Nov 20, 2012 at 11:09 PM, David Miller  wrote:
>> From: Konstantin Serebryany 
>> Date: Tue, 20 Nov 2012 23:02:36 +0400
>>
>>> I really need your help to resolve this mess.
>>
>> I thought it was abundantly clear that the burdon falls upon the ASAN
>> folks, since they are the ones who care about the external dependency.
>>
>> Nobody else inside of the GCC community cares about that.
> 
> If nobody else in the GCC community cares about ASAN, we should
> disable the SPARC build and
> let us handle the issue without rush.
> We are interested in SPARC, but much less than in our own sanity.

I am saying that nobody has a direct interest in the LLVM
dependencies, therefore they are entirely your responsibility.  Please
don't twist my words.

Everyone in the GCC community cares that core features are supported
on as many targets as possible.


Re: [PR middle-end/55398] Convert vec<> into a POD

2012-11-20 Thread Diego Novillo
On Tue, Nov 20, 2012 at 2:35 PM, Jakub Jelinek  wrote:

> 2012-11-20  Jakub Jelinek  
>
> * vec.h (class vec_prefix): Change into struct.
> Rename field alloc_PRIVATE_ back to alloc_.
> Rename field num_PRIVATE_ to num_.
> Update all users.
> (class vec): Rename field pfx_PRIVATE_ to vecpfx_.
> Rename field data_PRIVATE_ to vecdata_.
> Update all users.
> (class vec): Make every field public.
> Rename field vec_PRIVATE_ back to vec_.
> Update all users.

Much cleaner.  Thanks.  The patch is OK.


Diego.


Re: sparc bootstrap still broken

2012-11-20 Thread Konstantin Serebryany
On Tue, Nov 20, 2012 at 11:37 PM, David Miller  wrote:
> From: Konstantin Serebryany 
> Date: Tue, 20 Nov 2012 23:19:51 +0400
>
>> On Tue, Nov 20, 2012 at 11:09 PM, David Miller  wrote:
>>> From: Konstantin Serebryany 
>>> Date: Tue, 20 Nov 2012 23:02:36 +0400
>>>
 I really need your help to resolve this mess.
>>>
>>> I thought it was abundantly clear that the burdon falls upon the ASAN
>>> folks, since they are the ones who care about the external dependency.
>>>
>>> Nobody else inside of the GCC community cares about that.
>>
>> If nobody else in the GCC community cares about ASAN, we should
>> disable the SPARC build and
>> let us handle the issue without rush.
>> We are interested in SPARC, but much less than in our own sanity.
>
> I am saying that nobody has a direct interest in the LLVM
> dependencies,

We do. As long as we maintain libasan in GCC, so do you (by transitive
relation).

Let's stop this. Please apply whatever minimal patch required to
unbreak the SPARC build.
We will not be accepting any non-trivial patches until we set up
semi-automated way to pull the upstream sources.

--kcc

> therefore they are entirely your responsibility.  Please
> don't twist my words.
>
> Everyone in the GCC community cares that core features are supported
> on as many targets as possible.


Re: [5/8] Tweak bitfield alignment handling

2012-11-20 Thread Richard Sandiford
Richard Sandiford  writes:
> Mikael Pettersson  writes:
>> John David Anglin writes:
>>  > On Sun, 18 Nov 2012, Richard Sandiford wrote:
>>  > 
>>  > >HOST_WIDE_INT start = bitpos_ - (bitpos_ % unit);
>>  > >if (bitregion_start_ && start < bitregion_start_)
>>  > > break;
>>  > > -  if (bitregion_end_ && start + unit > bitregion_end_ + 1)
>>  > > +  if (start + unit > bitregion_end_ + 1)
>>  > 
>>  > This causes:
>>  > 
>>  > /home/dave/gnu/gcc/objdir/./prev-gcc/g++ 
>> -B/home/dave/gnu/gcc/objdir/./prev-gcc/ 
>> -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/bin/ -nostdinc++ 
>> -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs 
>> -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
>> -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
>>  -I/home/dave/gnu/gcc
>>  > /objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
>> -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ 
>> -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/sr
>>  > c/.libs 
>> -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
>> -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tabl
>>  > es -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
>> -Wmissing-format-attribut
>>  > e -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
>> -Werror 
>>  > -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
>> -I../../g
>>  > cc/gcc/../include -I../../gcc/gcc/../libcpp/include  
>> -I../../gcc/gcc/../libdecnu
>>  > mber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
>> -I../../gcc/gcc/../li
>>  > bbacktrace../../gcc/gcc/stor-layout.c -o 
>> stor-layout.o../../gcc/gcc/stor-layout.c: In member function 〘bool 
>> bit_field_mode_iterator::n
>>  > ext_mode(machine_mode*)〙:
>>  > ../../gcc/gcc/stor-layout.c:2690:43: error: comparison between signed and 
>> unsign
>>  > ed integer expressions [-Werror=sign-compare]
>>  >if (start + unit > bitregion_end_ + 1)
>>  >  ^
>>  > cc1plus: all warnings being treated as errors
>>
>> This error also breaks m68k-linux bootstrap.
>>
>> HWI32 issue?
>
> Yeah, I expect so, sorry.
>
> Logically, everything here would be unsigned arithmetic, but as the
> comment says:
>
>   /* We use signed values here because the bit position can be negative
>  for invalid input such as gcc.dg/pr48335-8.c.  */
>
> This is the patch I'm testing.  There are three things being checked here:
>
> - "unit", the size of the mode in isolation.  This really is an unsigned
>   value, and is compared to unsigned values like GET_MODE_PRECISION.
>
> - bitpos_ % unit (+ bitsize_), the start and end positions of the bitfield
>   relative to the start of the mode.  The start position is supposed to be
>   [0, unit), so the modulus and result should be unsigned.  (Using unsigned
>   modulus doesn't cope with negative bit positions combined with
>   non-power-of-2 units, but I don't think we support that.)
>
> - bitregion_start_ and bitregion_end_.  bitpos_ is signed and can be
>   negative, so the bitregion comparison should continue to be signed.
>
> OK to commit if testing succeeds?

Now bootstrapped & regression-tested on x86_64-linux-gnu.

>
> Richard
>
>
> gcc/
>   * stor-layout.c (bit_field_mode_iterator::next_mode): Fix signedness.
>
> Index: gcc/stor-layout.c
> ===
> --- gcc/stor-layout.c 2012-11-20 10:15:39.0 +
> +++ gcc/stor-layout.c 2012-11-20 10:15:39.464712715 +
> @@ -2670,10 +2670,6 @@ bit_field_mode_iterator::next_mode (enum
>if (unit != GET_MODE_PRECISION (mode_))
>   continue;
>  
> -  /* Skip modes that are too small.  */
> -  if ((bitpos_ % unit) + bitsize_ > unit)
> - continue;
> -
>/* Stop if the mode is too wide to handle efficiently.  */
>if (unit > MAX_FIXED_MODE_SIZE)
>   break;
> @@ -2683,11 +2679,18 @@ bit_field_mode_iterator::next_mode (enum
>if (count_ > 0 && unit > BITS_PER_WORD)
>   break;
>  
> +  /* Skip modes that are too small.  */
> +  unsigned HOST_WIDE_INT substart = (unsigned HOST_WIDE_INT) bitpos_ % 
> unit;
> +  unsigned HOST_WIDE_INT subend = substart + bitsize_;
> +  if (subend > unit)
> + continue;
> +
>/* Stop if the mode goes outside the bitregion.  */
> -  HOST_WIDE_INT start = bitpos_ - (bitpos_ % unit);
> +  HOST_WIDE_INT start = bitpos_ - substart;
>if (bitregion_start_ && start < bitregion_start_)
>   break;
> -  if (start + unit > bitregion_end_ + 1)
> +  HOST_WIDE_INT end = start + unit;
> +  if (end > bitregion_end_ + 1)
>   break;
>  
>/* Stop if the mode requires too much alignment.  */


Re: sparc bootstrap still broken

2012-11-20 Thread David Miller
From: Konstantin Serebryany 
Date: Tue, 20 Nov 2012 23:52:48 +0400

> Please apply whatever minimal patch required to unbreak the SPARC
> build.  We will not be accepting any non-trivial patches until we
> set up semi-automated way to pull the upstream sources.

Will do.


Re: [PATCH, RFC] PR 55403 + 55391

2012-11-20 Thread Richard Henderson
On 11/20/2012 11:24 AM, Richard Henderson wrote:
> On 11/20/2012 09:29 AM, Richard Sandiford wrote:
>> Gah.  How about this patch, currently bootstrapping on x86_64-linux-gnu
>> as a sanity check?  The last instance seems glaringly obvious in
>> hindsight :-(
>>
>> Richard
>>
>>
>> gcc/
>>  * expmed.c (store_bit_field_1): Use adjust_bitfield_address_size
>>  rather than adjust_bitfield_address to change the mode of a reference.
>>  (extract_bit_field_1): Likewise.
> 
> That patch does fix my ICE.
> 
> It looks all good, too.  As you say, glaringly obvious even.  ;-)

One further point -- get_best_mem_extraction_insn does not work for
the traditional 'extv' patterns that only accept memories.  In
particular, the QImode memory in the extv pattern never matches up
at the beginning of get_traditional_extraction_insn, so that first
"if (mode != struct_mode) return false;" always triggers.

I audited the existing extv patterns and the affected targets are
alpha, sh, and vax.  All of the others implement extv on registers,
which appears to work.  Test case:

struct S { long y __attribute__((packed)); };
long g(struct S *s) { return s->y; }

Before:

ldq_u $0,0($16)
ldq_u $1,7($16)
extql $0,$16,$0
extqh $1,$16,$16
bis $0,$16,$0

After:

ldbu $5,1($16)
ldbu $8,0($16)
ldbu $7,2($16)
ldbu $6,3($16)
ldbu $4,4($16)
ldbu $3,5($16)
sll $5,8,$5
ldbu $2,6($16)
ldbu $1,7($16)
sll $7,16,$7
sll $6,24,$6
bis $5,$8,$5
sll $4,32,$4
sll $3,40,$3
bis $7,$5,$5
sll $2,48,$2
sll $1,56,$1
bis $6,$5,$0
bis $4,$0,$0
bis $3,$0,$0
bis $2,$0,$0
bis $1,$0,$0

I suppose the question is: with only 3 affected targets, is it more
trouble fiddling the somewhat confused "traditional" path, or to
just go ahead and update the backends?


r~


Re: [PR middle-end/55398] Convert vec<> into a POD

2012-11-20 Thread Ulrich Weigand
Diego Novillo wrote:
> On Tue, Nov 20, 2012 at 11:23 AM, Diego Novillo  wrote:
> 
> > 2012-11-20  Diego Novillo  
> >
> > PR middle-end/55398
> > * vec.h (class vec_prefix): Make every field public.
> > Rename field alloc_ to alloc_PRIVATE_.
> > Rename field num_ to num_PRIVATE_.
> > Update all users.
> > (class vec): Make every field public.
> > Rename field pfx_ to pfx_PRIVATE_.
> > Rename field data_ to data_PRIVATE_.
> > Update all users.
> > (class vec): Make every field public.
> > Rename field vec_ to vec_PRIVATE_.
> > Update all users.
> > (va_heap::release): Do nothing if V is NULL.
> > (va_stack::release): Likewise.
> 
> Committed as rev 193667.

This fixed the spu-elf build failure.  Thanks!

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com



Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Peter Bergner
On Tue, 2012-11-20 at 23:24 +0400, Konstantin Serebryany wrote:
> On Tue, Nov 20, 2012 at 11:08 PM, Peter Bergner  wrote:
> > diff -urpN -X /home/bergner/cvs/dontdiff 
> > gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h 
> > gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.h
> > --- 
> > gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h   
> > 2012-11-20 11:42:08.821389243 -0600
> > +++ 
> > gcc-fsf-mainline-asan/libsanitizer/sanitizer_common/sanitizer_stacktrace.h  
> > 2012-11-20 11:12:44.551390980 -0600
> > @@ -23,6 +23,7 @@ struct StackTrace {
> >uptr size;
> >uptr max_size;
> >uptr trace[kStackTraceMax];
> > +  uptr frame[kStackTraceMax];  // For use by _Unwind_Backtrace 
> > architectures.
> 
> This is bad. The objects of this type are already too big, we should
> not make them 2x larger.
> Hopefully Evgeniy can handle this tomorrow.

Ok, here's another attempt that doesn't require storing the frame pointers.
In this case, we pass down the frame pointer we're looking for into the
unwind code and if we come across it while building up the trace, we immediately
empty the trace and start over, effectively popping the ASAN functions from
the trace.  If we never encounter the passed down frame pointer, then the code
will just behave as before.  Thoughts?

Peter


diff -urpN -X /home/bergner/cvs/dontdiff gcc-fsf-mainline-kcc/LAST_UPDATED 
gcc-fsf-mainline-asan/LAST_UPDATED
--- gcc-fsf-mainline-kcc/LAST_UPDATED   2012-11-20 11:40:17.232777673 -0600
+++ gcc-fsf-mainline-asan/LAST_UPDATED  2012-11-19 10:33:36.362778406 -0600
@@ -1,2 +1,2 @@
-Tue Nov 20 11:40:17 CST 2012
-Tue Nov 20 17:40:17 UTC 2012 (revision 193626)
+Mon Nov 19 10:33:36 CST 2012
+Mon Nov 19 16:33:36 UTC 2012 (revision 193626)
diff -urpN -X /home/bergner/cvs/dontdiff 
gcc-fsf-mainline-kcc/libsanitizer/asan/asan_linux.cc 
gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc
--- gcc-fsf-mainline-kcc/libsanitizer/asan/asan_linux.cc2012-11-20 
12:52:33.961664485 -0600
+++ gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc   2012-11-20 
14:12:31.231751746 -0600
@@ -141,11 +141,27 @@ uptr Unwind_GetIP(struct _Unwind_Context
 #endif
 }
 
+uptr Unwind_GetBP(struct _Unwind_Context *ctx) {
+  return _Unwind_GetCFA(ctx);
+}
+
+struct Unwind_Trace_Info {
+  StackTrace *stack;
+  uptr bp;
+};
+
 _Unwind_Reason_Code Unwind_Trace(struct _Unwind_Context *ctx,
 void *param) {
-  StackTrace *b = (StackTrace*)param;
-  CHECK(b->size < b->max_size);
+  Unwind_Trace_Info *p = (Unwind_Trace_Info *)param;
+  StackTrace *b = p->stack;
   uptr pc = Unwind_GetIP(ctx);
+  if (Unwind_GetBP(ctx) == p->bp) {
+// We just encountered the frame pointer we want to start
+// our backtrace with, so empty the backtrace before adding
+// this frame to the backtrace.
+b->size = 0;
+  }
+  CHECK(b->size < b->max_size);
   b->trace[b->size++] = pc;
   if (b->size == b->max_size) return UNWIND_STOP;
   return UNWIND_CONTINUE;
@@ -157,9 +173,10 @@ void GetStackTrace(StackTrace *stack, up
   if ((max_s) > 1) {
 stack->max_size = max_s;
 #if defined(__arm__) || defined(__powerpc__) || defined(__powerpc64__)
-_Unwind_Backtrace(Unwind_Trace, stack);
-// Pop off the two ASAN functions from the backtrace.
-stack->PopStackFrames(2);
+Unwind_Trace_Info param;
+param.stack = stack;
+param.bp = bp;
+_Unwind_Backtrace(Unwind_Trace, ¶m);
 #else
 if (!asan_inited) return;
 if (AsanThread *t = asanThreadRegistry().GetCurrent())




[PATCH] Avoid some further -Wreturn-type false positives (PR c++/54046)

2012-11-20 Thread Jakub Jelinek
Hi!

This is an attempt to avoid some further -Wreturn-type false positives,
by adding a langhook for block_may_fallthru and thus allowing it to handle
selected FE specific trees (like EXPR_STMT or THROW_EXPR) and handling also
TARGET_EXPR.  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2012-11-20  Jakub Jelinek  

PR c++/54046
* Makefile.in (gimple-low.o): Depend on langhooks.h.
* gimple-low.c: Include langhooks.c.
(block_may_fallthru): Handle TARGET_EXPR and ERROR_MARK,
by default call lang_hooks.block_may_fallthru.
* langhooks.h (struct lang_hooks): Add block_may_fallthru
langhook.
* langhooks-def.h (LANG_HOOKS_BLOCK_MAY_FALLTHRU): Define.
(LANG_HOOKS_INITIALIZER): Use it.

* cp-objcp-common.h (LANG_HOOKS_BLOCK_MAY_FALLTHRU): Redefine.
* cp-objcp-common.c (cxx_block_may_fallthru): New function.
* cp-tree.h (cxx_block_may_fallthru): New prototype.

* g++.dg/warn/Wreturn-type-8.C: New test.

--- gcc/Makefile.in.jj  2012-11-20 11:36:51.0 +0100
+++ gcc/Makefile.in 2012-11-20 17:28:58.601741316 +0100
@@ -2519,7 +2519,7 @@ gimple-low.o : gimple-low.c $(CONFIG_H)
$(DIAGNOSTIC_CORE_H) $(GIMPLE_H) $(TREE_INLINE_H) langhooks.h \
$(LANGHOOKS_DEF_H) $(TREE_FLOW_H) $(TM_H) coretypes.h \
$(EXCEPT_H) $(FLAGS_H) $(RTL_H) $(FUNCTION_H) $(TREE_PASS_H) \
-   $(HASHTAB_H) $(DIAGNOSTIC_CORE_H) tree-iterator.h
+   $(HASHTAB_H) $(DIAGNOSTIC_CORE_H) tree-iterator.h langhooks.h
 omp-low.o : omp-low.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
$(RTL_H) $(GIMPLE_H) $(TREE_INLINE_H) langhooks.h $(DIAGNOSTIC_CORE_H) \
$(TREE_FLOW_H) $(FLAGS_H) $(EXPR_H) $(DIAGNOSTIC_CORE_H) \
--- gcc/gimple-low.c.jj 2012-11-19 14:41:18.0 +0100
+++ gcc/gimple-low.c2012-11-20 17:28:33.518881995 +0100
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.
 #include "function.h"
 #include "diagnostic-core.h"
 #include "tree-pass.h"
+#include "langhooks.h"
 
 /* The differences between High GIMPLE and Low GIMPLE are the
following:
@@ -739,8 +740,14 @@ block_may_fallthru (const_tree block)
 case CLEANUP_POINT_EXPR:
   return block_may_fallthru (TREE_OPERAND (stmt, 0));
 
-default:
+case TARGET_EXPR:
+  return block_may_fallthru (TREE_OPERAND (stmt, 1));
+
+case ERROR_MARK:
   return true;
+
+default:
+  return lang_hooks.block_may_fallthru (stmt);
 }
 }
 
--- gcc/langhooks.h.jj  2012-07-16 14:38:34.0 +0200
+++ gcc/langhooks.h 2012-11-20 17:25:07.019061084 +0100
@@ -1,6 +1,6 @@
 /* The lang_hooks data structure.
Copyright 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-   2011 Free Software Foundation, Inc.
+   2011, 2012 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -456,6 +456,10 @@ struct lang_hooks
  FUNCTION_DECL for `std::terminate'.  */
   tree (*eh_protect_cleanup_actions) (void);
 
+  /* Return true if a stmt can fallthru.  Used by block_may_fallthru
+ to possibly handle language trees.  */
+  bool (*block_may_fallthru) (const_tree);
+
   /* True if this language uses __cxa_end_cleanup when the ARM EABI
  is enabled.  */
   bool eh_use_cxa_end_cleanup;
--- gcc/langhooks-def.h.jj  2012-04-30 08:06:18.0 +0200
+++ gcc/langhooks-def.h 2012-11-20 17:26:15.616672118 +0100
@@ -115,6 +115,7 @@ extern void lhd_omp_firstprivatize_type_
 #define LANG_HOOKS_EH_PERSONALITY  lhd_gcc_personality
 #define LANG_HOOKS_EH_RUNTIME_TYPE lhd_pass_through_t
 #define LANG_HOOKS_EH_PROTECT_CLEANUP_ACTIONS  NULL
+#define LANG_HOOKS_BLOCK_MAY_FALLTHRU  hook_bool_const_tree_true
 #define LANG_HOOKS_EH_USE_CXA_END_CLEANUP  false
 #define LANG_HOOKS_DEEP_UNSHARING  false
 
@@ -300,6 +301,7 @@ extern void lhd_end_section (void);
   LANG_HOOKS_EH_PERSONALITY, \
   LANG_HOOKS_EH_RUNTIME_TYPE, \
   LANG_HOOKS_EH_PROTECT_CLEANUP_ACTIONS, \
+  LANG_HOOKS_BLOCK_MAY_FALLTHRU, \
   LANG_HOOKS_EH_USE_CXA_END_CLEANUP, \
   LANG_HOOKS_DEEP_UNSHARING \
 }
--- gcc/cp/cp-objcp-common.h.jj 2012-04-23 11:11:19.0 +0200
+++ gcc/cp/cp-objcp-common.h2012-11-20 17:30:18.637283695 +0100
@@ -94,6 +94,8 @@ extern void cp_common_init_ts (void);
 #define LANG_HOOKS_TYPE_HASH_EQcxx_type_hash_eq
 #undef LANG_HOOKS_MISSING_NORETURN_OK_P
 #define LANG_HOOKS_MISSING_NORETURN_OK_P cp_missing_noreturn_ok_p
+#undef LANG_HOOKS_BLOCK_MAY_FALLTHRU
+#define LANG_HOOKS_BLOCK_MAY_FALLTHRU cxx_block_may_fallthru
 
 /* Attribute hooks.  */
 #undef LANG_HOOKS_COMMON_ATTRIBUTE_TABLE
--- gcc/cp/cp-tree.h.jj 2012-11-19 14:41:16.0 +0100
+++ gcc/cp/cp-tree.h2012-11-20 17:33:43.470104218 +0100
@@ -6019,6 +6019,7 @@ extern bool cp_var_mod_type_p (tree, t
 extern void cxx_initialize_diagnostics (diagnostic_context *);
 extern int cxx_types_compatible_p  (tree, tree);
 extern void init_shadowed_var_for_decl (void);
+extern bool cxx_bloc

[RFA/4.7/ARM] Backport arm-*-linux-gnueabihf triplet support to 4.7

2012-11-20 Thread Matthew Gretton-Dann
All,

This patch backports Matthais Klose's arm*-*-linux-gnueabihf triplet
support patch of 2012-10-15 to 4.7.

The backport was not clean as 4.8 has obsoleted various arm*-*-*
triplets which are valid in 4.7.

I have tested this cross with arm-none-linux-gnueabihf and
arm-none-linux-gnueabi.

One question I do have having done this work - is there a canonical way to 
test for the arm*-*-linux-gnueabi triplet (or variants)?  Various configure 
and testsuite files test for this, but there doesn't seem to be a consistent 
method.

OK for 4.7?

Thanks,

Matt

2012-11-08  Matthew Gretton-Dann  

Backport from mainline
2012-10-15  Matthias Klose  

* config.gcc: Match arm*-*-linux-* for ARM Linux/GNU.
* doc/install.texi: Use arm-*-*linux-* instead of arm-*-*linux-gnueabi.

gcc/ada/ChangeLog:
2012-11-08  Matthew Gretton-Dann  

Backport from mainline.
2012-10-15  Matthias Klose  

* gcc-interface/Makefile.in: Match arm*-*-linux-*eabi* for
ARM Linux/GNU.

gcc/testsuite/ChangeLog:
2012-11-08  Matthew Gretton-Dann  

Backport from mainline
2012-10-15  Matthias Klose  

* lib/target-supports.exp (check_profiling_available): Match
arm*-*-linux-* for ARM Linux/GNU.
* gfortran.dg/enum_10.f90: Likewise.
* gfortran.dg/enum_9.f90: Likewise.
* gcc.target/arm/synchronize.c: Likewise.
* g++.old-deja/g++.jason/enum6.C: Likewise.
* g++.old-deja/g++.law/enum9.C: Likewise.
* g++.old-deja/g++.other/enum4.C: Likewise.

libgcc/ChangeLog:
2012-11-08  Matthew Gretton-Dann  

* config.host: Match arm*-*-linux-* for ARM Linux/GNU.

libjava/ChangeLog:
2012-11-08  Matthew Gretton-Dann  

Backport from mainline.
2012-10-15  Matthias Klose  

* configure.ac: Match arm*-*-linux-* for ARM Linux/GNU.
* configure: Regenerate.

libstdc++-v3/ChangeLog:
2012-11-08  Matthew Gretton-Dann  

Backport from mainline
2012-10-15  Matthias Klose  

* configure.host: Match arm*-*-linux-* for ARM Linux/GNU.
* testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise.

-- 
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.orgdiff --git a/gcc/ada/gcc-interface/Makefile.in 
b/gcc/ada/gcc-interface/Makefile.in
index 9b5135e..9f20f07 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -1866,7 +1866,7 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(arch) 
$(osys))),)
   LIBRARY_VERSION := $(LIB_VERSION)
 endif
 
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 
4,$(targ,)
+ifeq ($(strip $(filter-out arm%-linux,$(arch)-$(osys)) $(if $(findstring 
eabi,$(word 4,$(targ))),,$(word 4,$(targ,)
   LIBGNAT_TARGET_PAIRS = \
   a-intnam.ads
 
diff --git a/gcc/testsuite/g++.old-deja/g++.law/enum9.C 
b/gcc/testsuite/g++.old-deja/g++.law/enum9.C
index 5a74b2f..0ecb87d 100644
--- a/gcc/testsuite/g++.old-deja/g++.law/enum9.C
+++ b/gcc/testsuite/g++.old-deja/g++.law/enum9.C
@@ -7,10 +7,10 @@
 // enum-size attributes should only be emitted if there are values of
 // enum type that can escape the compilation unit, gcc cannot currently
 // detect this; if this facility is added then this linker option should
-// not be needed.  arm-*-linux*eabi should be a good approximation to
+// not be needed.  arm-*-linux*eabi* should be a good approximation to
 // those platforms where the EABI supplement defines enum values to be
 // 32 bits wide.
-// { dg-options "-fshort-enums -Wl,--no-enum-size-warning" { target 
arm*-*-linux*eabi } }
+// { dg-options "-fshort-enums -Wl,--no-enum-size-warning" { target 
arm*-*-linux*eabi* } }
 
 // GROUPS passed enums
   extern "C" int printf (const char *, ...);
diff --git a/gcc/testsuite/g++.old-deja/g++.other/enum4.C 
b/gcc/testsuite/g++.old-deja/g++.other/enum4.C
index 429e812..509da6d 100644
--- a/gcc/testsuite/g++.old-deja/g++.other/enum4.C
+++ b/gcc/testsuite/g++.old-deja/g++.other/enum4.C
@@ -9,10 +9,10 @@
 // enum-size attributes should only be emitted if there are values of
 // enum type that can escape the compilation unit, gcc cannot currently
 // detect this; if this facility is added then this linker option should
-// not be needed.  arm-*-linux*eabi should be a good approximation to
+// not be needed.  arm-*-linux*eabi* should be a good approximation to
 // those platforms where the EABI supplement defines enum values to be
 // 32 bits wide.
-// { dg-options "-fshort-enums -Wl,--no-enum-size-warning" { target 
arm*-*-linux*eabi } }
+// { dg-options "-fshort-enums -Wl,--no-enum-size-warning" { target 
arm*-*-linux*eabi* } }
 
 enum E { 
   a = -312
diff --git a/gcc/testsuite/gcc.target/arm/synchronize.c 
b/gcc/testsuite/gcc.target/arm/synchronize.c
index 8626d8e..cf5dcdf 100644
--- a/gcc/testsuite/gcc.target/arm/synchronize.c
+++ b/gcc/testsuite/g

Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Richard Henderson
On 11/20/2012 12:16 PM, Peter Bergner wrote:
> +uptr Unwind_GetBP(struct _Unwind_Context *ctx) {
> +  return _Unwind_GetCFA(ctx);
> +}
> +
> +struct Unwind_Trace_Info {
> +  StackTrace *stack;
> +  uptr bp;
> +};
> +
>  _Unwind_Reason_Code Unwind_Trace(struct _Unwind_Context *ctx,
>  void *param) {
> -  StackTrace *b = (StackTrace*)param;
> -  CHECK(b->size < b->max_size);
> +  Unwind_Trace_Info *p = (Unwind_Trace_Info *)param;
> +  StackTrace *b = p->stack;
>uptr pc = Unwind_GetIP(ctx);
> +  if (Unwind_GetBP(ctx) == p->bp) {

BP will only equal the CFA on some targets.  It really depends on how the 
target sets up the stack frame.  It will also depend on the target actually 
using frame pointers.

On the other hand, CFA = SP on the next frame up.  And that's rather more 
reliable based on how we work with dwarf2 and define the CFA.  Only very 
unusual functions have CFA != the incoming SP -- asm versions of longjmp for 
example.


r~


Re: [PATCH, RFC] PR 55403 + 55391

2012-11-20 Thread Richard Sandiford
Richard Henderson  writes:
> On 11/20/2012 11:24 AM, Richard Henderson wrote:
>> On 11/20/2012 09:29 AM, Richard Sandiford wrote:
>>> Gah.  How about this patch, currently bootstrapping on x86_64-linux-gnu
>>> as a sanity check?  The last instance seems glaringly obvious in
>>> hindsight :-(
>>>
>>> Richard
>>>
>>>
>>> gcc/
>>> * expmed.c (store_bit_field_1): Use adjust_bitfield_address_size
>>> rather than adjust_bitfield_address to change the mode of a reference.
>>> (extract_bit_field_1): Likewise.
>> 
>> That patch does fix my ICE.
>> 
>> It looks all good, too.  As you say, glaringly obvious even.  ;-)
>
> One further point -- get_best_mem_extraction_insn does not work for
> the traditional 'extv' patterns that only accept memories.  In
> particular, the QImode memory in the extv pattern never matches up
> at the beginning of get_traditional_extraction_insn, so that first
> "if (mode != struct_mode) return false;" always triggers.

Sorry for all the mishaps.

> I audited the existing extv patterns and the affected targets are
> alpha, sh, and vax.  All of the others implement extv on registers,
> which appears to work.  Test case:
>
> struct S { long y __attribute__((packed)); };
> long g(struct S *s) { return s->y; }
>
> Before:
>
>   ldq_u $0,0($16)
>   ldq_u $1,7($16)
>   extql $0,$16,$0
>   extqh $1,$16,$16
>   bis $0,$16,$0
>
> After:
>
>   ldbu $5,1($16)
>   ldbu $8,0($16)
>   ldbu $7,2($16)
>   ldbu $6,3($16)
>   ldbu $4,4($16)
>   ldbu $3,5($16)
>   sll $5,8,$5
>   ldbu $2,6($16)
>   ldbu $1,7($16)
>   sll $7,16,$7
>   sll $6,24,$6
>   bis $5,$8,$5
>   sll $4,32,$4
>   sll $3,40,$3
>   bis $7,$5,$5
>   sll $2,48,$2
>   sll $1,56,$1
>   bis $6,$5,$0
>   bis $4,$0,$0
>   bis $3,$0,$0
>   bis $2,$0,$0
>   bis $1,$0,$0
>
> I suppose the question is: with only 3 affected targets, is it more
> trouble fiddling the somewhat confused "traditional" path, or to
> just go ahead and update the backends?

I suppose updating them would be the ideal eventually, but I'd still
like to fix the bug.

I belatedly did a similar audit and it looks there are no patterns that
use a mixture of field and structure modes for register operations.
They're either equal or not present.  So how about the patch below?
I checked that it fixes this testcase.

Richard


gcc/
* optabs.c (get_traditional_extraction_insn): Check the field mode
against the given mode.  Only check the structure mode for register
insertions and extractions.

Index: gcc/optabs.c
===
--- gcc/optabs.c2012-11-18 17:33:42.0 +
+++ gcc/optabs.c2012-11-20 20:46:16.893286686 +
@@ -8258,11 +8258,12 @@ #define CODE_FOR_extzv  CODE_FOR_nothing
 enum extraction_type { ET_unaligned_mem, ET_reg };
 
 /* Check whether insv, extv or extzv pattern ICODE can be used for an
-   insertion or extraction of type TYPE on a structure of mode MODE.
-   Return true if so and fill in *INSN accordingly.  STRUCT_OP is the
-   operand number of the structure (the first sign_extract or zero_extract
-   operand) and FIELD_OP is the operand number of the field (the other
-   side of the set from the sign_extract or zero_extract).  */
+   insertion or extraction of type TYPE on a structure and field of
+   mode MODE.  Return true if so and fill in *INSN accordingly.
+   STRUCT_OP is the operand number of the structure (the first
+   sign_extract or zero_extract operand) and FIELD_OP is the operand
+   number of the field (the other side of the set from the sign_extract
+   or zero_extract).  */
 
 static bool
 get_traditional_extraction_insn (extraction_insn *insn,
@@ -8273,15 +8274,23 @@ get_traditional_extraction_insn (extract
 {
   const struct insn_data_d *data = &insn_data[icode];
 
-  enum machine_mode struct_mode = data->operand[struct_op].mode;
-  if (struct_mode == VOIDmode)
-struct_mode = word_mode;
-  if (mode != struct_mode)
-return false;
-
   enum machine_mode field_mode = data->operand[field_op].mode;
   if (field_mode == VOIDmode)
 field_mode = word_mode;
+  if (mode != field_mode)
+return false;
+
+  enum machine_mode struct_mode;
+  if (type == ET_unaligned_mem)
+struct_mode = byte_mode;
+  else
+{
+  struct_mode = data->operand[struct_op].mode;
+  if (struct_mode == VOIDmode)
+   struct_mode = word_mode;
+  if (mode != struct_mode)
+   return false;
+}
 
   enum machine_mode pos_mode = data->operand[struct_op + 2].mode;
   if (pos_mode == VOIDmode)
@@ -8289,7 +8298,7 @@ get_traditional_extraction_insn (extract
 
   insn->icode = icode;
   insn->field_mode = field_mode;
-  insn->struct_mode = (type == ET_unaligned_mem ? byte_mode : struct_mode);
+  insn->struct_mode = struct_mode;
   insn->pos_mode = pos_mode;
   return true;
 }


[PATCH] Fix sanitizer build on sparc64.

2012-11-20 Thread David Miller

[ Sorry, flubbed the gcc-patches address the first time. ]

libsanitizer/

* sanitizer_common/sanitizer_linux.cc
(SANITIZER_LINUX_USES_64BIT_SYSCALLS): Define.
(internal_mmap): Use it.
(internal_filesize): Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@193676 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libsanitizer/ChangeLog   |  7 +++
 libsanitizer/sanitizer_common/sanitizer_linux.cc | 13 +++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
index 7aade50..22f65b2 100644
--- a/libsanitizer/ChangeLog
+++ b/libsanitizer/ChangeLog
@@ -1,3 +1,10 @@
+2012-11-20  Konstantin Serebryany  
+
+   * sanitizer_common/sanitizer_linux.cc
+   (SANITIZER_LINUX_USES_64BIT_SYSCALLS): Define.
+   (internal_mmap): Use it.
+   (internal_filesize): Likewise.
+
 2012-11-16  Tom Tromey  
 
* configure.ac: Invoke AM_MAINTAINER_MODE.
diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc 
b/libsanitizer/sanitizer_common/sanitizer_linux.cc
index e90a68c..f2a0d39 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
@@ -29,12 +29,21 @@
 #include 
 #include 
 
+// Are we using 32-bit or 64-bit syscalls?
+// x32 (which defines __x86_64__) has __WORDSIZE == 32
+// but it still needs to use 64-bit syscalls.
+#if defined(__x86_64__) || __WORDSIZE == 64
+# define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
+#else
+# define SANITIZER_LINUX_USES_64BIT_SYSCALLS 0
+#endif
+
 namespace __sanitizer {
 
 // --- sanitizer_libc.h
 void *internal_mmap(void *addr, uptr length, int prot, int flags,
 int fd, u64 offset) {
-#if defined __x86_64__
+#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
   return (void *)syscall(__NR_mmap, addr, length, prot, flags, fd, offset);
 #else
   return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
@@ -67,7 +76,7 @@ uptr internal_write(fd_t fd, const void *buf, uptr count) {
 }
 
 uptr internal_filesize(fd_t fd) {
-#if defined __x86_64__
+#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
   struct stat st;
   if (syscall(__NR_fstat, fd, &st))
 return -1;
-- 
1.7.12.2.dirty



Re: [PATCH, RFC] PR 55403 + 55391

2012-11-20 Thread Richard Henderson
On 11/20/2012 12:54 PM, Richard Sandiford wrote:
> gcc/
>   * optabs.c (get_traditional_extraction_insn): Check the field mode
>   against the given mode.  Only check the structure mode for register
>   insertions and extractions.

OK.

Thanks for the quick attention.


r~


Re: rfc NOP vs CONVERT (was: Simplifying Gimple Generation)

2012-11-20 Thread Diego Novillo
On Mon, Nov 19, 2012 at 10:35 AM, Michael Matz  wrote:

> I thought everybody can look into my head.  Well, if you can't
> due to my aluminium hat, here it is electronically :)

Thanks.  Looks fine with the appropriate ChangeLog entry.


Diego.


patch to fix PR55396

2012-11-20 Thread Vladimir Makarov

The following patch fixes

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55396

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

Committed as rev. 193678.

2012-11-20  Vladimir Makarov  

PR rtl-optimization/55396
* lra-constraints.c (get_reload_reg): Change class if it is
different from reg class.



Index: lra-constraints.c
===
--- lra-constraints.c	(revision 193677)
+++ lra-constraints.c	(working copy)
@@ -425,7 +425,7 @@ get_reload_reg (enum op_type type, enum
 	fprintf (lra_dump_file, "	 Reuse r%d for reload ", regno);
 	print_value_slim (lra_dump_file, original, 1);
 	  }
-	if (rclass != new_class)
+	if (new_class != lra_get_allocno_class (regno))
 	  change_class (regno, new_class, ", change", false);
 	if (lra_dump_file != NULL)
 	  fprintf (lra_dump_file, "\n");


Re: rfc NOP vs CONVERT (was: Simplifying Gimple Generation)

2012-11-20 Thread Martin Jambor
Hi,

On Mon, Nov 19, 2012 at 04:35:45PM +0100, Michael Matz wrote:
> Hi,
> 
> On Mon, 19 Nov 2012, Steven Bosscher wrote:
> 
> > On Mon, Nov 19, 2012 at 2:10 PM, Michael Matz wrote:
> > > Hi,
> > >
> > > On Fri, 16 Nov 2012, Andrew Pinski wrote:
> > >
> > >> >> Ah, yes.  This one was amusing.  When we were drafting the proposal,
> > >> >> Lawrence kept wondering what this NOP_EXPR thing is.  I've been
> > >> >> suffering this name for so long, that it no longer irritates me.
> > >> >> Had it been named CAST_EXPR, or even NOP_CAST_EXPR, he would have
> > >> >> probably kept it in the example code :)
> > >> >
> > >> > We have CONVERT_EXPR, but it currently doesn't do _quite_ the same as
> > >> > NOP_EXPR.  I once wanted to merge them (with CONVERT_EXPR surviving),
> > >> > but it stalled somewhere, couple years ago.
> > >>
> > >> I think the only difference now is in the front-ends IIRC.
> > >
> > > No, because my patch didn't go in.  There are still various cases in the
> > > middle end that explicitely check for equality with NOP_EXPR, instead of
> > > using CONVERT_EXPR_P or CONVERT_EXPR_CODE_P or CASE_CONVERT to work with
> > > both.
> > >
> > > See the patch below from three years ago.  Of course it doesn't apply
> > > anymore, but I can update it if there's some consensus that we want to go
> > > that route.
> > 
> > At this point, you probably wanted to attach a patch :-)
> 
> I thought everybody can look into my head.  Well, if you can't 
> due to my aluminium hat, here it is electronically :)
> 

thanks, this way it's certainly easier to quote :-)

...

> Index: gcc/ipa-cp.c
> ===
> --- gcc.orig/ipa-cp.c 2009-08-17 10:53:09.0 +0200
> +++ gcc/ipa-cp.c  2009-09-29 15:29:05.0 +0200
> @@ -298,7 +298,7 @@ ipcp_lattice_from_jfunc (struct ipa_node
>   return;
>cst = caller_lat->constant;
>  
> -  if (jfunc->value.pass_through.operation != NOP_EXPR)
> +  if (! CONVERT_EXPR_CODE_P (jfunc->value.pass_through.operation))
>   cst = fold_binary (jfunc->value.pass_through.operation,
>  TREE_TYPE (cst), cst,
>  jfunc->value.pass_through.operand);

This will of course work but it is a bit strange, jump functions do
not do any conversions, NOP_EXPR operation really means they do
nothing to the value they pass.  Similarly in ipa-prop.c.

Thanks,

Martin



Re: [patch] [arm] add multiarch definitions for arm-linux-gnueabi

2012-11-20 Thread Ramana Radhakrishnan
On Wed, Nov 14, 2012 at 10:30 PM, Matthias Klose  wrote:
> The following patch adds the multiarch definitions for arm-linux-gnu. Tested
> using a Debian/Ubuntu package build. Ok for the trunk?

Ok.

Ramana

>
>   Matthias
>


Re: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target

2012-11-20 Thread Ramana Radhakrishnan
On Fri, Nov 16, 2012 at 5:37 AM, Bin Cheng  wrote:
> Hi,
> This patch defines LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target and prefers
> short circuit for armv6-m and Thumb2+Os.
>
> I tested the patch on arm-none-eabi on armv6-m/Thumb2 for both Os/O2. The
> patch introduces new fails on ARMv6-m:
>
> gcc/testsuite/gcc.dg/pr19105.c
> gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
> gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
> These tests depends on non-short-circuit IR, which is not generated
> because we prefer short circuit on ARMv6-m now. I modified the tests to skip
> them on ARMv6-m.
>
> gcc/testsuite/gcc.dg/uninit-pred-8_b.c
> Root cause: tree-ssa-uninit.c computes control dependent chain for
> uses/def of variable and checks whether each use is guarded by def. It has a
> upper bound on the number of control dependent chains(MAX_NUM_CHAINS==8) and
> just retreat to false warning if the number of chains exceeds
> MAX_NUM_CHAINS. In our scenario, the number of chains exceeds MAX_NUM_CHAINS
> because we prefer short circuit now, resulting in false warning information.
> These false warning cannot be fully removed if the MAX_NUM_CHAINS exists,
> but we can improve it in following way: There are lots of invalid control
> dependent chains computed in tree-ssa-uninit.c now and should be pruned. I
> have already implemented a quick fix and it works for our scenario. I can
> take this problem once I get some time.

Please keep track of this in a separate bugzilla entry.

>
>
> This is an backend patch and not a bug fix, I am not sure whether it can go
> in trunk or I have to wait for GCC4.9?


OK for trunk.

Ramana

>
> Thanks
>
> 2012-11-16  Bin Cheng  
>
> * config/arm/arm-cores.def (cortex-m1, cortex-m0)
> (cortex-m0plus): Use v6m.
> * config/arm/arm-protos.h (tune_params): Add
> logical_op_non_short_circuit.
> * config/arm/arm.c (arm_slowmul_tune, arm_fastmul_tune)
> (arm_strongarm_tune, arm_xscale_tune, arm_9e_tune, arm_v6t2_tune)
> (arm_cortex_tune, arm_cortex_a15_tune, arm_cortex_a5_tune)
> (arm_cortex_a9_tune, arm_fa726te_tune): Set
> logical_op_non_short_circuit field.
> (arm_v6m_tune): New tune_params struct.
> * config/arm/arm.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Define.
>
> gcc/testsuite/ChangeLog
> 2012-11-16  Bin Cheng  
>
> * gcc.dg/pr19105.c: Skip on armv6-m.
> * gcc.dg/tree-ssa/ssa-dom-thread-4.c: Ditto.
> * gcc.dg/tree-ssa/vrp47.c: Ditto.


[PATCH, PR 55260] Fix cgraph_edge_brings_all_agg_vals_for_node

2012-11-20 Thread Martin Jambor
Hi,

when I tested aggregate IPA-CP on SCCs, I did not notice that IPA-CP
confused itself on the testcase and did not work as intended.  That
will be fixed by the next patch, this one fixes function
cgraph_edge_brings_all_agg_vals_for_node which did not work on edges
IPA-CP clones and ICEd when it saw them, which is a bit of a problem
given that it is there primarily for such edges.

The patch below re-uses a big part of function
find_aggregate_values_for_callers_subset rather than re-implementing
the propagation once more.  It means that aggregate replacement values
are traversed a few times in the process but the list should be
usually tiny and even in pathologic cases their size is limited by
PARAM_IPA_MAX_AGG_ITEMS * number of parameters, so I do not think it's
worth a bitmap.

Bootstrapped and tested on x86_64-linux.  OK for trunk?

Thanks,

Martin


2012-11-19  Martin Jambor  

PR tree-optimization/55260
* ipa-cp.c (intersect_aggregates_with_edge): New function.
(find_aggregate_values_for_callers_subset): Part moved to the function
above.  Call it.
(cgraph_edge_brings_all_agg_vals_for_node): Reimplemented using
intersect_aggregates_with_edge.

* testsuite/g++.dg/torture/pr55260-2.C: New test.

Index: src/gcc/testsuite/g++.dg/torture/pr55260-2.C
===
*** /dev/null
--- src/gcc/testsuite/g++.dg/torture/pr55260-2.C
***
*** 0 
--- 1,16 
+ /* { dg-do compile } */
+ /* { dg-add-options bind_pic_locally } */
+ 
+ struct B
+ {
+ virtual void test_suite_finish ();
+ };
+ void
+ fn1 (B & p2)
+ {
+ fn1 (p2);
+ B & a = p2;
+ a.test_suite_finish ();
+ B b;
+ fn1 (b);
+ }
Index: src/gcc/ipa-cp.c
===
*** src.orig/gcc/ipa-cp.c
--- src/gcc/ipa-cp.c
*** intersect_with_agg_replacements (struct
*** 2852,2857 
--- 2852,2978 
  }
  }
  
+ /* Intersect values in INTER with aggregate values that come along edge CS to
+parameter number INDEX and return it.  If INTER does not actually exist 
yet,
+copy all incoming values to it.  If we determine we ended up with no values
+whatsoever, return a released vector.  */
+ 
+ static vec
+ intersect_aggregates_with_edge (struct cgraph_edge *cs, int index,
+   vec inter)
+ {
+   struct ipa_jump_func *jfunc;
+   jfunc = ipa_get_ith_jump_func (IPA_EDGE_REF (cs), index);
+   if (jfunc->type == IPA_JF_PASS_THROUGH
+   && ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
+ {
+   struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
+   int src_idx = ipa_get_jf_pass_through_formal_id (jfunc);
+ 
+   if (caller_info->ipcp_orig_node)
+   {
+ struct cgraph_node *orig_node = caller_info->ipcp_orig_node;
+ struct ipcp_param_lattices *orig_plats;
+ orig_plats = ipa_get_parm_lattices (IPA_NODE_REF (orig_node),
+ src_idx);
+ if (agg_pass_through_permissible_p (orig_plats, jfunc))
+   {
+ if (!inter.exists ())
+   inter = agg_replacements_to_vector (cs->caller, 0);
+ else
+   intersect_with_agg_replacements (cs->caller, src_idx,
+&inter, 0);
+   }
+   }
+   else
+   {
+ struct ipcp_param_lattices *src_plats;
+ src_plats = ipa_get_parm_lattices (caller_info, src_idx);
+ if (agg_pass_through_permissible_p (src_plats, jfunc))
+   {
+ /* Currently we do not produce clobber aggregate jump
+functions, adjust when we do.  */
+ gcc_checking_assert (!jfunc->agg.items);
+ if (!inter.exists ())
+   inter = copy_plats_to_inter (src_plats, 0);
+ else
+   intersect_with_plats (src_plats, &inter, 0);
+   }
+   }
+ }
+   else if (jfunc->type == IPA_JF_ANCESTOR
+  && ipa_get_jf_ancestor_agg_preserved (jfunc))
+ {
+   struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
+   int src_idx = ipa_get_jf_ancestor_formal_id (jfunc);
+   struct ipcp_param_lattices *src_plats;
+   HOST_WIDE_INT delta = ipa_get_jf_ancestor_offset (jfunc);
+ 
+   if (caller_info->ipcp_orig_node)
+   {
+ if (!inter.exists ())
+   inter = agg_replacements_to_vector (cs->caller, delta);
+ else
+   intersect_with_agg_replacements (cs->caller, index, &inter,
+delta);
+   }
+   else
+   {
+ src_plats = ipa_get_parm_lattices (caller_info, src_idx);;
+ /* Currently we do not produce clobber aggregate jump
+functions, adjust when we do.  */
+ gcc_checking_assert (!src_plats->aggs || !jfunc->agg.items);
+ if (!inter.exists (

Re: [5/8] Tweak bitfield alignment handling

2012-11-20 Thread Eric Botcazou
> gcc/
>   * stor-layout.c (bit_field_mode_iterator::next_mode): Fix signedness.

This looks fine to me.

-- 
Eric Botcazou


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Peter Bergner
On Tue, 2012-11-20 at 12:36 -0800, Richard Henderson wrote:
> BP will only equal the CFA on some targets.  It really depends on how the
> target sets up the stack frame.

Are you talking about leaf routines like on ppc64 where we don't
decrement the stack pointer?  If so, that's not a concern here
because the ASAN tests insert a call so none of the instrumented
functions will be leaf routines.


> It will also depend on the target actually using frame pointers.

That is problematical, except for...


> On the other hand, CFA = SP on the next frame up.  And that's rather more
> reliable based on how we work with dwarf2 and define the CFA.  Only very
> unusual functions have CFA != the incoming SP -- asm versions of longjmp
> for example.

Doesn't this save us, since the bottom frame in the backtrace will always
be an ASAN functionand the frame we're interested in will always be higher
in the backtrace?

I guess I'm wondering, in this specific use case, do you think using
the CFA to compare against is safe or not?

Peter





Re: [patch] PR tree-optimization/55350: invalid pointer operand to PLUS_EXPR

2012-11-20 Thread Eric Botcazou
> The problem here is that the SLSR pass is promoting a POINTER_PLUS_EXPR
> to a PLUS_EXPR.  Since pointer arithmetic is invalid in
> {PLUS,MINUS}_EXPR's, the gimple verifier chokes on the invalid statement.
> 
> Fixed by maintaining the POINTER_PLUS_EXPR when appropriate.
> 
> OK for trunk?

The ChangeLog mentions POINTER_MINUS_EXPR, which doesn't exist.

-- 
Eric Botcazou


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-20 Thread Richard Henderson
On 11/20/2012 02:14 PM, Peter Bergner wrote:
> Doesn't this save us, since the bottom frame in the backtrace will always
> be an ASAN functionand the frame we're interested in will always be higher
> in the backtrace?
> 
> I guess I'm wondering, in this specific use case, do you think using
> the CFA to compare against is safe or not?

Yes it saves us.  I believe using the value of __builtin_dwarf_cfa from
the outermost ASAN function will reliably match the SP value of the
interesting user function outer of ASAN.


r~


Re: [patch] PR tree-optimization/55350: invalid pointer operand to PLUS_EXPR

2012-11-20 Thread Aldy Hernandez

On 11/20/12 16:23, Eric Botcazou wrote:

The problem here is that the SLSR pass is promoting a POINTER_PLUS_EXPR
to a PLUS_EXPR.  Since pointer arithmetic is invalid in
{PLUS,MINUS}_EXPR's, the gimple verifier chokes on the invalid statement.

Fixed by maintaining the POINTER_PLUS_EXPR when appropriate.

OK for trunk?


The ChangeLog mentions POINTER_MINUS_EXPR, which doesn't exist.



Actually the ChangeLog is correct, what was incorrect was the svn commit 
message.  Is there a way to change the commit message retroactively?


Re: [patch] [arm] add multiarch definitions for arm-linux-gnueabi

2012-11-20 Thread Ramana Radhakrishnan
Oh, and while you are there please add 2012 to the copyright years.


Ramana

On Wed, Nov 14, 2012 at 10:30 PM, Matthias Klose  wrote:
> The following patch adds the multiarch definitions for arm-linux-gnu. Tested
> using a Debian/Ubuntu package build. Ok for the trunk?
>
>   Matthias
>


Re: [PATCH] Fix sanitizer build on sparc64.

2012-11-20 Thread Andreas Schwab
David Miller  writes:

> +// Are we using 32-bit or 64-bit syscalls?
> +// x32 (which defines __x86_64__) has __WORDSIZE == 32
> +// but it still needs to use 64-bit syscalls.
> +#if defined(__x86_64__) || __WORDSIZE == 64

I don't think it is a good idea to use a glibc-internal macro.  How
about __LP64__?

Andreas.

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


Re: [patch] PR tree-optimization/55350: invalid pointer operand to PLUS_EXPR

2012-11-20 Thread Eric Botcazou
> Actually the ChangeLog is correct, what was incorrect was the svn commit
> message.  Is there a way to change the commit message retroactively?

Probably, but I wouldn't bother about that.

-- 
Eric Botcazou


Re: [RFC PATCH] Masked load/store vectorization

2012-11-20 Thread Hans-Peter Nilsson
On Tue, 20 Nov 2012, Jakub Jelinek wrote:
> 2012-11-20  Jakub Jelinek  
>
>   * Makefile.in (tree-if-conv.o): Depend on $(TARGET_H), $(EXPR_H)
>   and $(OPTABS_H).
>   * config/i386/sse.md (maskload, maskstore): New expanders.
(etc., new patterns, but nothing for md.texi)

Missing documentation?

brgds, H-P


Re: [RFA/4.7/ARM] Backport arm-*-linux-gnueabihf triplet support to 4.7

2012-11-20 Thread Matthias Klose
Am 20.11.2012 21:34, schrieb Matthew Gretton-Dann:
> All,
> 
> This patch backports Matthais Klose's arm*-*-linux-gnueabihf triplet
> support patch of 2012-10-15 to 4.7.
> 
> The backport was not clean as 4.8 has obsoleted various arm*-*-*
> triplets which are valid in 4.7.
> 
> I have tested this cross with arm-none-linux-gnueabihf and
> arm-none-linux-gnueabi.
> 
> One question I do have having done this work - is there a canonical way to 
> test for the arm*-*-linux-gnueabi triplet (or variants)?  Various configure 
> and testsuite files test for this, but there doesn't seem to be a consistent 
> method.
> 
> OK for 4.7?

looks fine, except one missing chunk from my original patch. maybe left out
intentionally.

  Matthias

Index: b/src/gcc/config.gcc
===
--- a/src/gcc/config.gcc
+++ b/src/gcc/config.gcc
@@ -934,7 +934,7 @@
tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h
arm/uclinux-elf.h glibc-stdint.h"
tmake_file="arm/t-arm arm/t-arm-elf"
case ${target} in
-   arm*-*-uclinux*eabi)
+   arm*-*-uclinux*eabi*)
tm_file="$tm_file arm/bpabi.h arm/uclinux-eabi.h"
tmake_file="$tmake_file arm/t-bpabi"
# The BPABI long long divmod functions return a 128-bit value in




Re: [ping] Re: [patch v2] support for multiarch systems

2012-11-20 Thread Matthias Klose
Am 14.11.2012 21:44, schrieb Ian Lance Taylor:
> On Sun, Nov 4, 2012 at 7:45 AM, Matthias Klose  wrote:
>>
>> now testing the attached patch.
> 
>> + when 1 is passed,
>> +   - the multiarch path specified with
>> + -imultiarch, when 2 is passed.  */
> 
> s/when 1 is passed/when set to 1/
> Same for 2.
> 
> This is OK with that change.
> 
> Thanks and sorry for the delay in review.

thanks for finishing the review. I'm checking in the following patch to move out
the multiarch paragraph out of the multilib documentation as obvious.

  Matthias

 2012-11-20  Matthias Klose  

+   * doc/install.texi: Move multiarch paragraph out of multilib
+   documentation.
+
+2012-11-20  Matthias Klose  
+
* config/arm/t-linux-eabi: Define MULTIARCH_DIRNAME for linux target.

 2012-11-20  Richard Sandiford  
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi(revision 193684)
+++ gcc/doc/install.texi(working copy)
@@ -1027,12 +1027,6 @@
 @code{gnu2}, which select between the original GNU dialect and the GNU TLS
 descriptor-based dialect.

-@item --disable-multilib
-Specify that multiple target
-libraries to support different target variants, calling
-conventions, etc.@: should not be built.  The default is to build a
-predefined set of them.
-
 @item --enable-multiarch
 Specify whether to enable or disable multiarch support.  The default is
 to check for glibc start files in a multiarch location, and enable it
@@ -1042,6 +1036,12 @@
 More documentation about multiarch can be found at
 @uref{http://wiki.debian.org/Multiarch}.

+@item --disable-multilib
+Specify that multiple target
+libraries to support different target variants, calling
+conventions, etc.@: should not be built.  The default is to build a
+predefined set of them.
+
 Some targets provide finer-grained control over which multilibs are built
 (e.g., @option{--disable-softfloat}):
 @table @code



Sparc ASAN (was Re: sparc bootstrap still broken)

2012-11-20 Thread David Miller
From: David Miller 
Date: Tue, 20 Nov 2012 14:59:10 -0500 (EST)

> From: Konstantin Serebryany 
> Date: Tue, 20 Nov 2012 23:52:48 +0400
> 
>> Please apply whatever minimal patch required to unbreak the SPARC
>> build.  We will not be accepting any non-trivial patches until we
>> set up semi-automated way to pull the upstream sources.
> 
> Will do.

I tossed together a quick sparc implementation and there seems to
be only two issues to fix:

1) As noticed by the powerpc people, you have to probe the page
   size of the system properly.  It's variable even within a
   target/OS.

   Probably a new hook, implemented in asan_linux.cc via:

#include 

uptr GetPageSize()
{
  return getpagesize();
}

   I would just get rid of kPageSizeBits, rather than compute it
   dynamically as well, as it's really not used as far as I can tell.

   The mmap of the shadow area won't work on sparc without this being
   resolved.

2) The current code emitted to set the shadow values results in
   unaligned stores.  For example, for the memcmp-1.c test on 32-bit
   we get:

   0x10488 :add  %fp, -160, %i5
 ...
   0x10490 :   sethi  %hi(0xf1f1f000), %g2
 ...
   0x104a0 :   srl  %i5, 3, %i5
 ...
   0x104a8 :   or  %g2, 0x1f1, %g2
   0x104ac :   sethi  %hi(0x2000), %g1
 ...
=> 0x104b4 :   st  %g2, [ %i5 + %g1 ]

   Here %fp is 0xd538, and this %i5 + %g1 is 0x3a93, which
   is not aligned properly for a 32-bit store.

   Therefore, this won't work for any STRICT_ALIGNMENT target.

Those seem to be the only problems that need to be resolved for this
feature to be fully working.


Re: [patch] [powerpc] add multiarch definitions for powerpc-linux-gnu

2012-11-20 Thread David Edelsohn
The following patch adds the multiarch definitions for -linux-gnu. Tested using
a Debian/Ubuntu package build. Ok for the trunk?

  Matthias

2012-11-14  Matthias Klose  

* config/rs6000/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/rs6000/t-linux: New file; define MULTIARCH_DIRNAME for hard
float configurations.
* config/rs6000/t-fprules (SOFT_FLOAT_CPUS): New macro.
(MULTILIB_MATCHES_FLOAT): Define in terms of SOFT_FLOAT_CPUS.
* config/rs6000/t-spe: Define MULTIARCH_DIRNAME for linux targets.
* config.gcc  (tmake_file):
Include rs6000/t-linux for 32bit non-biarch configurations.
* configure.ac (with_cpu): Substitute variable.
* configure: Regenerate.
* Makefile.in (with_cpu): New macro.

And add e300c2 to the list of soft-float configurations

Okay.

Thanks, David


ping - Re: [patch] [ia64] add multiarch definitions for ia64-linux-gnu

2012-11-20 Thread Matthias Klose
ping, re-sending to the port maintainers

Am 15.11.2012 11:57, schrieb Matthias Klose:
> Am 15.11.2012 09:51, schrieb Alexander Monakov:
>> The attached patch includes t-glibc instead of t-linux in config.gcc.
> 
> thanks for the pointer. updated patch attached below.



Re: [patch] [powerpc] add multiarch definitions for powerpc-linux-gnu

2012-11-20 Thread Matthias Klose
Am 21.11.2012 03:40, schrieb David Edelsohn:
> The following patch adds the multiarch definitions for -linux-gnu. Tested 
> using
> a Debian/Ubuntu package build. Ok for the trunk?
> 
>   Matthias
> 
> 2012-11-14  Matthias Klose  
> 
>   * config/rs6000/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
>   * config/rs6000/t-linux: New file; define MULTIARCH_DIRNAME for hard
>   float configurations.
>   * config/rs6000/t-fprules (SOFT_FLOAT_CPUS): New macro.
>   (MULTILIB_MATCHES_FLOAT): Define in terms of SOFT_FLOAT_CPUS.
>   * config/rs6000/t-spe: Define MULTIARCH_DIRNAME for linux targets.
>   * config.gcc  (tmake_file):
>   Include rs6000/t-linux for 32bit non-biarch configurations.
>   * configure.ac (with_cpu): Substitute variable.
>   * configure: Regenerate.
>   * Makefile.in (with_cpu): New macro.
> 
> And add e300c2 to the list of soft-float configurations
> 
> Okay.

thanks, committed.

  Matthias


2012-11-20  Matthias Klose  

	* configure.ac: Substitute `with_cpu'.
	* configure: Regenerate.
	* Makefile.in: Define `with_cpu'.
	* config/rs6000/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
	* config/rs6000/t-linux: New file; define MULTIARCH_DIRNAME.
	* config/rs6000/t-fprules (SOFT_FLOAT_CPUS): New macro. Add e300c2
	to the list.
	(MULTILIB_MATCHES_FLOAT): Define in terms of SOFT_FLOAT_CPUS.
	* config/rs6000/t-spe: Define MULTIARCH_DIRNAME.
	* config.gcc  (tmake_file):
	Include rs6000/t-linux for 32bit non-biarch configurations.

Index: config.gcc
===
--- config.gcc	(revision 193685)
+++ config.gcc	(working copy)
@@ -2059,6 +2059,7 @@
 		;;
 	*)
 		tm_file="${tm_file} rs6000/linux.h glibc-stdint.h"
+		tmake_file="$tmake_file rs6000/t-linux"
 		;;
 	esac
 	case ${target} in
Index: configure.ac
===
--- configure.ac	(revision 193685)
+++ configure.ac	(working copy)
@@ -636,6 +636,7 @@
 AC_MSG_RESULT($enable_multiarch$ma_msg_suffix)
 
 # needed for setting the multiarch name for soft-float/hard-float ABIs
+AC_SUBST(with_cpu)
 AC_SUBST(with_float)
 
 # Enable __cxa_atexit for C++.
Index: Makefile.in
===
--- Makefile.in	(revision 193685)
+++ Makefile.in	(working copy)
@@ -532,6 +532,7 @@
 
 # Multiarch support
 enable_multiarch = @enable_multiarch@
+with_cpu = @with_cpu@
 with_float = @with_float@
 ifeq ($(enable_multiarch),yes)
   if_multiarch = $(1)
Index: config/rs6000/t-linux
===
--- config/rs6000/t-linux	(revision 0)
+++ config/rs6000/t-linux	(revision 0)
@@ -0,0 +1,5 @@
+# do not define the multiarch name if configured for a soft-float cpu
+# or soft-float.
+ifeq (,$(filter $(with_cpu),$(SOFT_FLOAT_CPUS))$(findstring soft,$(with_float))
+MULTIARCH_DIRNAME = powerpc-linux-gnu
+endif
Index: config/rs6000/t-linux64
===
--- config/rs6000/t-linux64	(revision 193685)
+++ config/rs6000/t-linux64	(working copy)
@@ -29,4 +29,5 @@
 MULTILIB_OPTIONS= m64/m32
 MULTILIB_DIRNAMES   = 64 32
 MULTILIB_EXTRA_OPTS = fPIC
-MULTILIB_OSDIRNAMES	= ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)
+MULTILIB_OSDIRNAMES	= ../lib64$(call if_multiarch,:powerpc64-linux-gnu)
+MULTILIB_OSDIRNAMES+= $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:powerpc-linux-gnu)
Index: config/rs6000/t-fprules
===
--- config/rs6000/t-fprules	(revision 193685)
+++ config/rs6000/t-fprules	(working copy)
@@ -16,17 +16,8 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
-MULTILIB_MATCHES_FLOAT	= msoft-float=mcpu?401 \
-			  msoft-float=mcpu?403 \
-			  msoft-float=mcpu?405 \
-			  msoft-float=mcpu?440 \
-			  msoft-float=mcpu?464 \
-			  msoft-float=mcpu?476 \
-			  msoft-float=mcpu?ec603e \
-			  msoft-float=mcpu?801 \
-			  msoft-float=mcpu?821 \
-			  msoft-float=mcpu?823 \
-			  msoft-float=mcpu?860
+SOFT_FLOAT_CPUS = e300c2 401 403 405 440 464 476 ec603e 801 821 823 860
+MULTILIB_MATCHES_FLOAT = $(foreach cpu, $(SOFT_FLOAT_CPUS), msoft-float=mcpu?$(cpu))
 
 # Build the libraries for both hard and soft floating point by default
 
Index: config/rs6000/t-spe
===
--- config/rs6000/t-spe	(revision 193685)
+++ config/rs6000/t-spe	(working copy)
@@ -71,3 +71,7 @@
 			  mabi=altivec/mlittle \
 			  maltivec/mlittle \
 			  maltivec/mabi=altivec/mlittle
+
+ifneq (,$(findstring linux, $(target)))
+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file)),,v1)
+endif


[ping] - Re: [patch] [s390] add multiarch definitions for s390-linux-gnu

2012-11-20 Thread Matthias Klose
ping, adding the s390 port maintainers

Am 14.11.2012 23:35, schrieb Matthias Klose:
> The following patch adds the multiarch definitions for s390-linux-gnu. Tested
> using a Debian/Ubuntu package build. Ok for the trunk?
> 
>   Matthias
> 



ping - Re: [patch] [alpha] add multiarch definitions for alpha-linux-gnu

2012-11-20 Thread Matthias Klose
ping, adding the alpha port maintainer

Am 14.11.2012 23:29, schrieb Matthias Klose:
> The following patch adds the multiarch definitions for alpha-linux-gnu. Tested
> using a Debian/Ubuntu package build. Ok for the trunk?
> 
>   Matthias
> 



ping - Re: [patch] [m68k] add multiarch definitions for m68k-linux-gnu

2012-11-20 Thread Matthias Klose
ping, adding the m68k port maintainers

Am 15.11.2012 00:33, schrieb Matthias Klose:
> Am 14.11.2012 23:39, schrieb Joseph S. Myers:
>> On Wed, 14 Nov 2012, Matthias Klose wrote:
>>
>>> The following patch adds the multiarch definitions for m68k-linux-gnu. 
>>> Tested
>>> using a Debian/Ubuntu package build. Ok for the trunk?
>>>
>>> Here, I'm unsure if the definition needs to be further constrained.
>>
>> Classix m68k and ColdFire need different multiarch names; you need to 
>> avoid using a name for one on a compiler configured for the other.  (I 
>> think any configuration will always be --with-arch=m68k or --with-arch=cf 
>> so you should only need to consider M68K_ARCH rather than having 
>> per-multilib settings.)
> 
> thanks for the pointer. For now, I set it just for the classic m68k.
> 
>   Matthias
> 
> 



RE: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target

2012-11-20 Thread Bin Cheng


> -Original Message-
> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
> Sent: Wednesday, November 21, 2012 6:02 AM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target
> 
> On Fri, Nov 16, 2012 at 5:37 AM, Bin Cheng  wrote:
> > Hi,
> > This patch defines LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target and
> > prefers short circuit for armv6-m and Thumb2+Os.
> >
> > I tested the patch on arm-none-eabi on armv6-m/Thumb2 for both Os/O2.
> > The patch introduces new fails on ARMv6-m:
> >
> > gcc/testsuite/gcc.dg/pr19105.c
> > gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
> > gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
> > These tests depends on non-short-circuit IR, which is not
> > generated because we prefer short circuit on ARMv6-m now. I modified
> > the tests to skip them on ARMv6-m.
> >
> > gcc/testsuite/gcc.dg/uninit-pred-8_b.c
> > Root cause: tree-ssa-uninit.c computes control dependent chain
> > for uses/def of variable and checks whether each use is guarded by
> > def. It has a upper bound on the number of control dependent
> > chains(MAX_NUM_CHAINS==8) and just retreat to false warning if the
> > number of chains exceeds MAX_NUM_CHAINS. In our scenario, the number
> > of chains exceeds MAX_NUM_CHAINS because we prefer short circuit now,
> resulting in false warning information.
> > These false warning cannot be fully removed if the MAX_NUM_CHAINS
> > exists, but we can improve it in following way: There are lots of
> > invalid control dependent chains computed in tree-ssa-uninit.c now and
> > should be pruned. I have already implemented a quick fix and it works
> > for our scenario. I can take this problem once I get some time.
> 
> Please keep track of this in a separate bugzilla entry.
I will file a bug about this later.

> 
> >
> >
> > This is an backend patch and not a bug fix, I am not sure whether it
> > can go in trunk or I have to wait for GCC4.9?
> 
> 
> OK for trunk.
> 
> Ramana
> 
> >
> > Thanks
> >
> > 2012-11-16  Bin Cheng  
> >
> > * config/arm/arm-cores.def (cortex-m1, cortex-m0)
> > (cortex-m0plus): Use v6m.
> > * config/arm/arm-protos.h (tune_params): Add
> > logical_op_non_short_circuit.
> > * config/arm/arm.c (arm_slowmul_tune, arm_fastmul_tune)
> > (arm_strongarm_tune, arm_xscale_tune, arm_9e_tune,
arm_v6t2_tune)
> > (arm_cortex_tune, arm_cortex_a15_tune, arm_cortex_a5_tune)
> > (arm_cortex_a9_tune, arm_fa726te_tune): Set
> > logical_op_non_short_circuit field.
> > (arm_v6m_tune): New tune_params struct.
> > * config/arm/arm.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Define.
> >
> > gcc/testsuite/ChangeLog
> > 2012-11-16  Bin Cheng  
> >
> > * gcc.dg/pr19105.c: Skip on armv6-m.
> > * gcc.dg/tree-ssa/ssa-dom-thread-4.c: Ditto.
> > * gcc.dg/tree-ssa/vrp47.c: Ditto.

Committed as r193687 in TRUNK.
I did not change test case gcc.dg/pr19105.c because Jakub had a patch also
fixing this and already got approved/committed. See
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00361.html

Thanks





Re: [PATCH] Fix sanitizer build on sparc64.

2012-11-20 Thread Konstantin Serebryany
On Wed, Nov 21, 2012 at 2:50 AM, Andreas Schwab  wrote:
> David Miller  writes:
>
>> +// Are we using 32-bit or 64-bit syscalls?
>> +// x32 (which defines __x86_64__) has __WORDSIZE == 32
>> +// but it still needs to use 64-bit syscalls.
>> +#if defined(__x86_64__) || __WORDSIZE == 64
>
> I don't think it is a good idea to use a glibc-internal macro.  How
> about __LP64__?

__WORDSIZE is used throughout the library; it is also redefined
properly for the compilers which don't have it and may not have
__LP64__
The upstream fix for the problem David is solving here also uses __WORDSIZE.

--kcc

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


Re: Sparc ASAN

2012-11-20 Thread David Miller
From: David Miller 
Date: Tue, 20 Nov 2012 21:20:40 -0500 (EST)

> Those seem to be the only problems that need to be resolved for this
> feature to be fully working.

FWIW, here are the changes I am using which, besides the sparc backend
bits, has some temporary workarounds for the issues I brought up.

The address violation detection seems to work properly and the only
thing that seems to be left are some backtrace/unwind issues.  These
are perhaps similar to the unwind bits that the powerpc folks ran
into.

diff --git a/gcc/asan.c b/gcc/asan.c
index bd90e0a..d9b3f1b 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -321,7 +321,10 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT 
*offsets, tree *decls,
  NULL_RTX, 1, OPTAB_DIRECT);
   gcc_assert (asan_shadow_set != -1
  && (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
-  shadow_mem = gen_rtx_MEM (SImode, shadow_base);
+  if (STRICT_ALIGNMENT)
+shadow_mem = gen_rtx_MEM (QImode, shadow_base);
+  else
+shadow_mem = gen_rtx_MEM (SImode, shadow_base);
   set_mem_alias_set (shadow_mem, asan_shadow_set);
   prev_offset = base_offset;
   for (l = length; l; l -= 2)
@@ -349,7 +352,20 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT 
*offsets, tree *decls,
  }
else
  shadow_bytes[i] = ASAN_STACK_MAGIC_PARTIAL;
- emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
+ if (STRICT_ALIGNMENT)
+   {
+ for (i = 0; i < 4; i++)
+   {
+ rtx mem = adjust_address (shadow_mem, VOIDmode, i);
+ rtx val;
+
+ val = GEN_INT (trunc_int_for_mode (shadow_bytes[i],
+QImode));
+ emit_move_insn (mem, val);
+   }
+   }
+ else
+   emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
  offset = aoff;
}
   while (offset <= offsets[l - 2] - ASAN_RED_ZONE_SIZE)
@@ -359,7 +375,22 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT 
*offsets, tree *decls,
   >> ASAN_SHADOW_SHIFT);
  prev_offset = offset;
  memset (shadow_bytes, cur_shadow_byte, 4);
- emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
+ if (STRICT_ALIGNMENT)
+   {
+ int i;
+
+ for (i = 0; i < 4; i++)
+   {
+ rtx mem = adjust_address (shadow_mem, VOIDmode, i);
+ rtx val;
+
+ val = GEN_INT (trunc_int_for_mode (shadow_bytes[i],
+QImode));
+ emit_move_insn (mem, val);
+   }
+   }
+ else
+   emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
  offset += ASAN_RED_ZONE_SIZE;
}
   cur_shadow_byte = ASAN_STACK_MAGIC_MIDDLE;
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 4e9de98..7bcc815 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -600,6 +600,7 @@ static void sparc_print_operand_address (FILE *, rtx);
 static reg_class_t sparc_secondary_reload (bool, rtx, reg_class_t,
   enum machine_mode,
   secondary_reload_info *);
+static unsigned HOST_WIDE_INT sparc_asan_shadow_offset (void);
 
 #ifdef SUBTARGET_ATTRIBUTE_TABLE
 /* Table of valid machine attributes.  */
@@ -754,6 +755,9 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_OPTION_OVERRIDE
 #define TARGET_OPTION_OVERRIDE sparc_option_override
 
+#undef TARGET_ASAN_SHADOW_OFFSET
+#define TARGET_ASAN_SHADOW_OFFSET sparc_asan_shadow_offset
+
 #if TARGET_GNU_TLS && defined(HAVE_AS_SPARC_UA_PCREL)
 #undef TARGET_ASM_OUTPUT_DWARF_DTPREL
 #define TARGET_ASM_OUTPUT_DWARF_DTPREL sparc_output_dwarf_dtprel
@@ -11034,6 +11038,14 @@ get_some_local_dynamic_name_1 (rtx *px, void *data 
ATTRIBUTE_UNUSED)
   return 0;
 }
 
+/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
+
+static unsigned HOST_WIDE_INT
+sparc_asan_shadow_offset (void)
+{
+  return (unsigned HOST_WIDE_INT) 1 << (TARGET_ARCH64 ? 44 : 29);
+}
+
 /* This is called from dwarf2out.c via TARGET_ASM_OUTPUT_DWARF_DTPREL.
We need to emit DTP-relative relocations.  */
 
diff --git a/libsanitizer/sanitizer_common/sanitizer_common.h 
b/libsanitizer/sanitizer_common/sanitizer_common.h
index cddefd7..00628fc 100644
--- a/libsanitizer/sanitizer_common/sanitizer_common.h
+++ b/libsanitizer/sanitizer_common/sanitizer_common.h
@@ -21,7 +21,7 @@ namespace __sanitizer {
 // Constants.
 const uptr kWordSize = __WORDSIZE / 8;
 const uptr kWordSizeInBits = 8 * kWordSize;
-const uptr kPageSizeBits = 12;
+const uptr kPageSizeBits = 13;
 const uptr kPageSize = 1UL << kPageSizeBits;
 const uptr kCacheLineSize = 64;
 #ifndef _WIN32



Ping: [PATCH v2] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

2012-11-20 Thread Siddhesh Poyarekar
Hi,

Ping!


Siddhesh

On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:

> Hi,
> 
> Here's an updated version of the patch which warns the user if the
> removing of redundant exits results in an infinite loop.  I have added
> an additional flag in struct loop called external_exits to record if
> an exit edge is moved outside the loop body.  This currently happens
> in the loop-unswitch pass and was the root cause of the regression in
> torture/pr49518.c that I talked about earlier.  The patch now passes
> all regression tests except a mudflap case (fail37-frag).  The test is
> already broken due to removal of all exits so I haven't attempted to
> fix it as part of this patch.  How does this version look?
> 
> Regards,
> Siddhesh
> 
> gcc/ChangeLog:
> 
>   * cfgloop.h (struct loop): New member EXTERNAL_EXITS.
>   * tree-ssa-loop-ivcanon.c (remove_redundant_iv_tests) Warn
> when loop is left without any exits.
>   * tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Set
>   EXTERNAL_EXITS when moving a statement with an exit edge out
> of the loop body.



Ping: [PATCH] Disable libsanitizer if C++ is not being built

2012-11-20 Thread Siddhesh Poyarekar
Hi,

Ping!

Siddhesh

On Thu, 15 Nov 2012 19:52:21 +0530, Siddhesh wrote:

> Hi,
> 
> Current HEAD fails build when --enable-languages=c, i.e. C++ is not
> being built.  Attached patch fixes this.
> 
> Regards,
> Siddhesh
> 
> ChangeLog:
> 
> 2012-11-15  Siddhesh Poyarekar  
> 
>   * configure.ac: Disable libsanitizer if we're not building
> C++.
>   * configure: Regenerate.
> 



Re: [PATCH] Change -faddress-sanitizer to -fsanitize=address

2012-11-20 Thread Wei Mi
I rewrite the patch according to Jakub's suggestion -- add the
following option in common.opt and keep flag_asan. The patch is
attached. Ok to checkin?

fsanitize=address
Common Report Var(flag_asan)
Enable AddressSanitizer, a memory error detector

2012-11-21  Wei Mi  

* common.opt: Change faddress-sanitizer to fsanitize=address.
* toplev.c (process_options): Likewise.
* gcc.c (LINK_COMMAND_SPEC): Likewise.
* testsuite/lib/asan-dg.exp
(check_effective_target_faddress_sanitizer): Likewise.
(asan_init): Likewise.
* doc/invoke.texi (-fsanitize=[address|thread]): Document.

Thanks,
Wei.

On Mon, Nov 19, 2012 at 9:09 PM, Konstantin Serebryany
 wrote:
> On Mon, Nov 19, 2012 at 11:21 PM, Wei Mi  wrote:
>> I cannot remove RejectNegative and use -fno-sanitize=address, or else
>> I will break an assertion (opts-common.c:614).  The assertion requires
>> -fxxx=var options set RejectNegative if var is of enumerater type.  I
>> see that all the other -fxxx=xxx options in common.opt set
>> RejectNegative.
>>
>> Is it ok for me to checkin the current patch and submit another patch
>> if there is a better way to do it?
>
> I would prefer to have the current patch earlier, rather then a more
> comprehensive patch later.
> Otherwise we may end up with too many uses of the old flag.
>
>>
>> Thanks,
>> Wei.
>>
>> On Mon, Nov 19, 2012 at 10:31 AM, Xinliang David Li  
>> wrote:
>>> Questions: are -fsanitize=thread -fsanitize=address mutually exclusive
>>> here? If yes, that will be wrong.
>>>
>>> How about -fsanitize=all option?
>>>
>>> As kcc mentioned, the -fno-.. form is not handled.
>>>
>>> David
>>>
>>>
>>> On Mon, Nov 19, 2012 at 10:14 AM, Wei Mi  wrote:
 Hi,

 This patch is to change -faddress-sanitizer to -fsanitize=address. Ok for 
 trunk?

 2012-11-19  Wei Mi  

 * cfgexpand.c (partition_stack_vars): Change flag_asan to
 flag_sanitize.
 (expand_stack_vars): Likewise.
 (defer_stack_allocation): Likewise.
 (expand_used_vars): Likewise.
 * varasm.c (assemble_noswitch_variable): Likewise.
 (assemble_variable): Likewise.
 (place_block_symbol): Likewise.
 * asan.c (gate_asan): Likewise.
 (gate_asan_O0): Likewise.
 * toplev.c (compile_file): Likewise.
 (process_options): Likewise.
 * common.opt: Change faddress-sanitizer to fsanitize=address.
 * gcc.c (LINK_COMMAND_SPEC): Likewise.
 * testsuite/lib/asan-dg.exp
 (check_effective_target_faddress_sanitizer): Likewise.
 (asan_init): Likewise.
 * flag-types.h (sanitize_type): New enum type.
 * doc/invoke.texi (-fsanitize=[address|thread]): Document.

 Thanks,
 Wei.
Index: gcc/common.opt
===
--- gcc/common.opt  (revision 193687)
+++ gcc/common.opt  (working copy)
@@ -840,7 +840,7 @@ fargument-noalias-anything
 Common Ignore
 Does nothing. Preserved for backward compatibility.
 
-faddress-sanitizer
+fsanitize=address
 Common Report Var(flag_asan)
 Enable AddressSanitizer, a memory error detector
 
Index: gcc/testsuite/lib/asan-dg.exp
===
--- gcc/testsuite/lib/asan-dg.exp   (revision 193687)
+++ gcc/testsuite/lib/asan-dg.exp   (working copy)
@@ -14,13 +14,13 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
-# Return 1 if compilation with -faddress-sanitizer is error-free for trivial
+# Return 1 if compilation with -fsanitize=address is error-free for trivial
 # code, 0 otherwise.
 
 proc check_effective_target_faddress_sanitizer {} {
 return [check_no_compiler_messages faddress_sanitizer object {
void foo (void) { }
-} "-faddress-sanitizer"]
+} "-fsanitize=address"]
 }
 
 #
@@ -83,12 +83,12 @@ proc asan_init { args } {
 }
 if [info exists ALWAYS_CXXFLAGS] {
set ALWAYS_CXXFLAGS [concat "{ldflags=$link_flags}" $ALWAYS_CXXFLAGS]
-   set ALWAYS_CXXFLAGS [concat "{additional_flags=-faddress-sanitizer -g}" 
$ALWAYS_CXXFLAGS]
+   set ALWAYS_CXXFLAGS [concat "{additional_flags=-fsanitize=address -g}" 
$ALWAYS_CXXFLAGS]
 } else {
if [info exists TEST_ALWAYS_FLAGS] {
-   set TEST_ALWAYS_FLAGS "$link_flags -faddress-sanitizer -g 
$TEST_ALWAYS_FLAGS"
+   set TEST_ALWAYS_FLAGS "$link_flags -fsanitize=address -g 
$TEST_ALWAYS_FLAGS"
} else {
-   set TEST_ALWAYS_FLAGS "$link_flags -faddress-sanitizer -g"
+   set TEST_ALWAYS_FLAGS "$link_flags -fsanitize=address -g"
}
 }
 }
Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 193687)
+++ gcc/toplev.c(working copy)
@@ -1549,7 +1549,7 @@ process_options (void)

Re: [PATCH] Change -faddress-sanitizer to -fsanitize=address

2012-11-20 Thread Jakub Jelinek
On Tue, Nov 20, 2012 at 11:14:27PM -0800, Wei Mi wrote:
> 2012-11-21  Wei Mi  
> 
> * common.opt: Change faddress-sanitizer to fsanitize=address.
> * toplev.c (process_options): Likewise.
> * gcc.c (LINK_COMMAND_SPEC): Likewise.
> * testsuite/lib/asan-dg.exp
> (check_effective_target_faddress_sanitizer): Likewise.
> (asan_init): Likewise.

Ok, thanks.

> * doc/invoke.texi (-fsanitize=[address|thread]): Document.

Just change [address|thread] to address in the ChangeLog entry.

Jakub