Re: [PATCH, i386] RTM support

[Andi Kleen]

> BTW: Looking a bit more to the spec, we can simply write
> 
> xbegin $0
> 
> as the spec says that offset is relative to the _NEXT_ instruction

Yes that's true. I'm not sure the .+6 even results in 0. Kirill?

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: [PATCH] PR target/52137 - bdver2 scheduler needs to be added to bdver1 insn reservations

[Jakub Jelinek]

On Tue, Feb 21, 2012 at 08:49:13AM +0100, Uros Bizjak wrote:
> > 2012-02-20  Quentin Neill  
> >
> > PR target/52137
> > * gcc/config/i386/bdver1.md (bdver1_call, bdver1_push,

Please leave out gcc/ prefix from the ChangeLog entry though.

Jakub

Re: [PATCH] Fix up gimplify_and_update_call_from_tree (PR tree-optimization/52318)

[Richard Guenther]

On Tue, 21 Feb 2012, Jakub Jelinek wrote:

> Hi!
> 
> This function spends significant amount of code to update the virtual
> uses/defs in the new sequence, but only handles that way stores, not
> non-pure/const calls, so we ICE during tree DSE on this testcase, because
> vop has been marked for renaming.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
> for trunk?

Ok.

Thanks,
Richard.

> 2012-02-20  Jakub Jelinek  
> 
>   PR tree-optimization/52318
>   * gimple-fold.c (gimplify_and_update_call_from_tree): Add
>   vdef also to non-pure/const call stmts in the sequence.
> 
>   * gcc.dg/pr52318.c: New test.
> 
> --- gcc/gimple-fold.c.jj  2011-12-16 08:37:45.0 +0100
> +++ gcc/gimple-fold.c 2012-02-20 21:51:20.853133362 +0100
> @@ -591,8 +591,11 @@ gimplify_and_update_call_from_tree (gimp
>for (i = gsi_last (stmts); !gsi_end_p (i); gsi_prev (&i))
>  {
>new_stmt = gsi_stmt (i);
> -  if (gimple_assign_single_p (new_stmt)
> -   && !is_gimple_reg (gimple_assign_lhs (new_stmt)))
> +  if ((gimple_assign_single_p (new_stmt)
> +&& !is_gimple_reg (gimple_assign_lhs (new_stmt)))
> +   || (is_gimple_call (new_stmt)
> +   && (gimple_call_flags (new_stmt)
> +   & (ECF_NOVOPS | ECF_PURE | ECF_CONST | ECF_NORETURN)) == 0))
>   {
> tree vdef;
> if (!laststore)
> --- gcc/testsuite/gcc.dg/pr52318.c.jj 2012-02-20 22:10:09.211778710 +0100
> +++ gcc/testsuite/gcc.dg/pr52318.c2012-02-20 22:09:10.0 +0100
> @@ -0,0 +1,17 @@
> +/* PR tree-optimization/52318 */
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -ftracer -fno-tree-ccp -fno-tree-copy-prop 
> -fno-tree-dce" } */
> +
> +int c;
> +char *p;
> +
> +void
> +foo (int i)
> +{
> +  char a[2];
> +  char b[20];
> +  p = __builtin___stpcpy_chk (a, "", 2);
> +  p = __builtin___stpcpy_chk (&b[16], i ? "e" : "jkl", 4);
> +  if (c)
> +foo (i);
> +}
> 
>   Jakub
> 
> 

-- 
Richard Guenther 
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

[VMS] Fix IDENTIFICATION padding

[Tristan Gingold]

Hi,

tiny patch to fix the padding of the identification string.  Now left padded, 
which is more natural for humans.

Committed on trunk.
Tristan.

2012-02-21  Tristan Gingold  

* config/vms/vms-ld.c (main): Fix IDENTIFICATION padding.

Index: gcc/config/vms/vms-ld.c
===
--- gcc/config/vms/vms-ld.c (revision 184425)
+++ gcc/config/vms/vms-ld.c (working copy)
@@ -640,7 +640,7 @@
{
  /* Comes from pragma Ident ().  */
   fprintf (optfile, "case_sensitive=yes\n");
-  fprintf (optfile, "IDENTIFICATION=\"%15.15s\"\n", &argv[i][17]);
+  fprintf (optfile, "IDENTIFICATION=\"%-.15s\"\n", &argv[i][17]);
   fprintf (optfile, "case_sensitive=NO\n");
}
 }

Re: [PATCH] Adjust 'malloc' attribute documentation to match implementation

[Richard Guenther]

On Mon, Feb 20, 2012 at 8:55 PM, Tijl Coosemans  wrote:
> On Monday 9 January 2012 10:05:08 Richard Guenther wrote:
>> Since GCC 4.4 applying the malloc attribute to realloc-like
>> functions does not work under the documented constraints because
>> the contents of the memory pointed to are not properly transfered
>> from the realloc argument (or treated as pointing to anything,
>> like 4.3 behaved).
>>
>> The following adjusts documentation to reflect implementation
>> reality (we do have an implementation detail that treats the
>> memory blob returned for non-builtins as pointing to any global
>> variable, but that is neither documented nor do I plan to do
>> so - I presume it is to allow allocation + initialization
>> routines to be marked with malloc, but even that area looks
>> susceptible to misinterpretation to me).
>>
>> Any comments?
>
> The new text says the memory must be undefined, but gives calloc as an
> example for which the memory is defined to be zero. Also, GCC has
> built-ins for strdup and strndup with the malloc attribute and GLIBC
> further adds it to wcsdup (wchar_t version of strdup) and tempnam. In
> all of these cases the memory is defined.
>
> Isn't the reason the attribute doesn't apply to realloc simply because
> the returned pointer may alias the one given as argument, rather than
> having defined memory content?

The question is really what the alias-analysis code can derive from a
function that is declared with the malloc attribute.  The most useful
property for alias analysis would be that te non-aliasing holds
transitively, thus reading (with any level of indirection) from the returned
pointer does not produce memory that is aliased by any other pointer.
That's what happens for 'malloc' (also for 'calloc' - you can't do any
further indirections through the NULL pointers the memory holds).  It
does not happen for realloc.  Currently the alias-analysis code does
assume exactly this properly (only very slightly weakened, possibly
because we broke some code I guess).

Internally, all builtins with interesting allocation properties are handled
explicitely, so we probably should not rely on the malloc attribute present
on those (and maybe simply drop it there).

The question is really what is useful for users, and what's the most natural
behavior?  For example

int **my_initialized_malloc (int *p)
{
  int **q = malloc (sizeof (int *));
  *q = p;
  return q;
}

would not qualify for the 'malloc' attribute (but we've taken measures to not
miscompile this kind of code, it seems to be a very common misconception
to place annotate these with 'malloc').

I'm not sure how to exactly constrain the documentation for 'malloc' better.
Maybe

The @code{malloc} attribute is used to tell the compiler that a function
may be treated as if any non-@code{NULL} pointer it returns cannot
alias any other pointer valid when the function returns and that the memory
does not contain any pointer value.

?  Because that is what is relevant.  That you can in no way extract
a pointer value from the memory pointed to by the return value.  Because
alias analysis will assume any such extracted pointer value points
nowhere (so, extracting a NULL pointer is ok).

The reasoning why the string functions have the malloc attribute was
probably that strings do not contain pointer values.  Of course they
can, you can store a character encoding of a pointer, copy the
string and decode it from the copy again.  We'd miscompile then

 int i = 1;
 int *p = &i;
 char ptr[16];
 ... inline encode p into ptr ...
 char *x = strdup (ptr);
 int *q = ... inline decode x to q
 *q = 2;
 return i;

to return 1 because we do not see that q may point to i.  Of course
we properly handle the transfer of pointers for str[n]dup, so the
'malloc' attribute on it is a lie...

Richard.

>> 2012-01-09  Richard Guenther  
>>
>>         * doc/extend.texi (malloc attribute): Adjust according to
>>         implementation.
>>
>> Index: gcc/doc/extend.texi
>> ===
>> --- gcc/doc/extend.texi (revision 183001)
>> +++ gcc/doc/extend.texi (working copy)
>> @@ -2771,13 +2771,12 @@ efficient @code{jal} instruction.
>>  @cindex @code{malloc} attribute
>>  The @code{malloc} attribute is used to tell the compiler that a function
>>  may be treated as if any non-@code{NULL} pointer it returns cannot
>> -alias any other pointer valid when the function returns.
>> +alias any other pointer valid when the function returns and that the memory
>> +has undefined content.
>>  This will often improve optimization.
>>  Standard functions with this property include @code{malloc} and
>> -@code{calloc}.  @code{realloc}-like functions have this property as
>> -long as the old pointer is never referred to (including comparing it
>> -to the new pointer) after the function returns a non-@code{NULL}
>> -value.
>> +@code{calloc}.  @code{realloc}-like functions do not have this
>> +property as the memory pointed to d

Re: [patch gthr.h]: Fix PR libstdc++/52300 Gthreads functions linking error at dynamic linking with libstdc++ when using MinGW.

[Richard Guenther]

On Mon, Feb 20, 2012 at 9:59 PM, Richard Henderson  wrote:
> On 02/20/12 12:14, Kai Tietz wrote:
>> 2012-02-20  Kai Tietz  
>>
>>         PR libstdc++/52300
>>        * gthr.h (GTHREAD_USE_WEAK): Define as zero for mingw.
>
> Ok.

It looks like this belongs in some config/gthr-mingw.h file instead, see
confit/gthr-lynx.h.

Richard.

>
> r~

Re: [patch lto-plugin]: Fix pr 50616

[Richard Guenther]

On Mon, Feb 20, 2012 at 11:59 PM, Kai Tietz  wrote:
> Hi,
>
> this patch replaces use of "llx" for printf/scanf by inttypes.h
> PRIxMAX/SCNxMAX macros.  If those macros aren't present it defines
> them as default to "llx".

Bootstrapped and tested on ... ?

Ok.

Thanks,
Richard.

> ChangeLog
>
> 2012-02-20  Kai Tietz  
>
>        PR lto/50616
>        * lto-plugin.c (PRIxMAX,SCNxMAX): Use inttypes.h header if
> present, otherwise define them
>        as "llx".
>
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-linux-gnu.  Ok for apply?
>
> Regards,
> Kai
>
> Index: lto-plugin.c
> ===
> --- lto-plugin.c        (revision 184414)
> +++ lto-plugin.c        (working copy)
> @@ -38,6 +38,9 @@
>  #if HAVE_STDINT_H
>  #include 
>  #endif
> +#if HAVE_INTTYPES_H
> +#include 
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -62,6 +65,14 @@
>  #include "simple-object.h"
>  #include "plugin-api.h"
>
> +#ifndef PRIxMAX
> +#define PRIxMAX "llx"
> +#endif
> +
> +#ifndef SCNxMAX
> +#define SCNxMAX "llx"
> +#endif
> +
>  /* Handle opening elf files on hosts, such as Windows, that may use
>    text file handling that will break binary access.  */
>  #ifndef O_BINARY
> @@ -360,7 +371,7 @@
>
>       assert (resolution != LDPR_UNKNOWN);
>
> -      fprintf (f, "%u %llx %s %s\n",
> +      fprintf (f, "%u %" PRIxMAX " %s %s\n",
>                (unsigned int) slot, symtab->aux[j].id,
>               lto_resolution_str[resolution],
>               symtab->syms[j].name);
> @@ -816,7 +827,7 @@
>
>   s = strrchr (name, '.');
>   if (s)
> -    sscanf (s, ".%llx", &obj->out->id);
> +    sscanf (s, ".%" SCNxMAX, &obj->out->id);
>   secdata = xmalloc (length);
>   offset += obj->file->offset;
>   if (offset != lseek (obj->file->fd, offset, SEEK_SET)

[google/gcc-4_6_2-mobile, PATCH] Add -mandroid support to x86 target.

[Ilya Enkovich]

Hello,

Here is a patch which adds -mandroid option support to x86 target. OK
for google/gcc-4_6_2-mobile branch?

Thanks,
Ilya
--
2012-02-21  Enkovich Ilya  

* config/i386/linux.h (LINUX_TARGET_CC1_SPEC): New.
(CC1_SPEC): Use LINUX_OR_ANDROID_CC.
(CC1PLUS_SPEC): Likewise.
(LINUX_TARGET_LINK_SPEC): New.
(LINK_SPEC): Support LINUX_OR_ANDROID_LD.
(LIB_SPEC): New.
(STARTFILE_SPEC): New.
(LINUX_TARGET_ENDFILE_SPEC): New.
(ENDFILE_SPEC): Support LINUX_OR_ANDROID_LD.

* config/linux-android.h (ANDROID_STARTFILE_SPEC): Use
crtbegin_so%O%s for -shared.
(ANDROID_ENDFILE_SPEC): Use crtend_so%O%s for -shared.


Add-mandroid-support-for-x86.patch
Description: Binary data

Re: Continue strict-volatile-bitfields fixes

[Richard Earnshaw]

On 20/02/12 17:51, Bernd Schmidt wrote:
> On 02/20/2012 06:39 PM, Richard Earnshaw wrote:
>> I'm not sure why it should be.  Can't a user write
>>
>> #ifdef __cplusplus
>> #define BOOL bool
>> #else
>> #define bool _Bool
>> #endif
>>
>> struct x {
>>   volatile BOOL a : 1;
>>   volatile BOOL b : 1;
>>   volatile unsigned char c : 6;
>>   volatile BOOL d : 1;
>> } y;
>>
>> ?
>>
>> If you've got strict volatile bitfields, then the concept here is that
>> the access uses the declared type for accessing the member.  Since in
>> the ABI bool has a defined size, then it should access the member using
>> that size.
>>
>> On ARM, sizeof bool is 1, so I'd take the above to mean that accessing
>> y.a to mean a read of a, b and c, but not d.
> 
> What are your thoughts on the argument about enums?
> 
> 
> Bernd
> 

Similar.  A particular enumeration type has a defined size, so accesses
should use that size.

R.

Re: [PATCH] Fix PR52298

[Richard Guenther]

On Mon, 20 Feb 2012, Jakub Jelinek wrote:

> On Mon, Feb 20, 2012 at 04:11:13PM +0100, Richard Guenther wrote:
> > This fixes PR52298, we need to use the proper DR step for outer
> > loop vectorization.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> 
> Thanks.
> 
> > *** vectorizable_load (gimple stmt, gimple_s
> > *** 4266,4272 
> > if (!STMT_VINFO_DATA_REF (stmt_info))
> >   return false;
> >   
> > !   negative = tree_int_cst_compare (DR_STEP (dr), size_zero_node) < 0;
> > if (negative && ncopies > 1)
> >   {
> > if (vect_print_dump_info (REPORT_DETAILS))
> > --- 4268,4277 
> > if (!STMT_VINFO_DATA_REF (stmt_info))
> >   return false;
> >   
> > !   negative = tree_int_cst_compare (loop && nested_in_vect_loop_p (loop, 
> > stmt)
> > !  ? STMT_VINFO_DR_STEP (stmt_info)
> > !  : DR_STEP (dr),
> > !  size_zero_node) < 0;
> 
> vectorizable_loop, unlike vectorizable_store, has nested_in_vect_loop
> bool flag, so you could just test that instead of
> loop && nested_in_vect_loop_p (loop, stmt) above and below.

Fixed as follows.

Richard.

2012-02-21  Richard Guenther  

* tree-vect-stmts.c (vectorizable_load): Use pre-computed
nested_in_vect_loop.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 184396)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -4268,7 +4268,7 @@ vectorizable_load (gimple stmt, gimple_s
   if (!STMT_VINFO_DATA_REF (stmt_info))
 return false;
 
-  negative = tree_int_cst_compare (loop && nested_in_vect_loop_p (loop, stmt)
+  negative = tree_int_cst_compare (nested_in_vect_loop
   ? STMT_VINFO_DR_STEP (stmt_info)
   : DR_STEP (dr),
   size_zero_node) < 0;
@@ -4658,7 +4658,7 @@ vectorizable_load (gimple stmt, gimple_s
  This can only occur when vectorizing memory accesses in the inner-loop
  nested within an outer-loop that is being vectorized.  */
 
-  if (loop && nested_in_vect_loop_p (loop, stmt)
+  if (nested_in_vect_loop
   && (TREE_INT_CST_LOW (STMT_VINFO_DR_STEP (stmt_info))
  % GET_MODE_SIZE (TYPE_MODE (vectype)) != 0))
 {

[google/gcc-4_6_2-mobile, PATCH] Enable stack protector for Android target

[Ilya Enkovich]

Hello,

Here is a patch which enables stack protector feature for Android
targets. OK for google/gcc-4_6_2-mobile branch?

Thanks,
Ilya
--

2012-02-21  Enkovich Ilya  

* gcc/configure.ac : Enable stack protector for
Android target.
* gcc/configure : Regenerated.


Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 184395)
+++ gcc/configure.ac(working copy)
@@ -4389,6 +4389,8 @@
   gcc_cv_libc_provides_ssp,
   [gcc_cv_libc_provides_ssp=no
 case "$target" in
+   *-android-*)
+ gcc_cv_libc_provides_ssp=yes;;
*-*-linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu)
   [# glibc 2.4 and later provides __stack_chk_fail and
   # either __stack_chk_guard, or TLS access to stack guard canary.

[google/gcc-4_6_2-mobile, PATCH] Enable exceptions and RTTI by default for Android

[Ilya Enkovich]

Hello,

Here is a ptch which enables exceptions and RTTI by default for
android targets like it is done in current NDK GCC 4.4.3 compiler. OK
for google/gcc-4_6_2-mobile branch.

Thanks,
Ilya
--

2012-02-21  Enkovich Ilya  

* gcc/config/linux-android.h (ANDROID_CC1PLUS_SPEC): Enable
exceptions and rtti by default.


Index: gcc/config/linux-android.h
===
--- gcc/config/linux-android.h  (revision 184395)
+++ gcc/config/linux-android.h  (working copy)
@@ -46,8 +46,8 @@
   "%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC"

 #define ANDROID_CC1PLUS_SPEC   \
-  "%{!fexceptions:%{!fno-exceptions: -fno-exceptions}} "   \
-  "%{!frtti:%{!fno-rtti: -fno-rtti}}"
+  "%{!fexceptions:%{!fno-exceptions: -fexceptions}} "  \
+  "%{!frtti:%{!fno-rtti: -frtti}}"

 #define ANDROID_LIB_SPEC \
   "%{!static: -ldl}"

[google/gcc-4_6_2-mobile, PATCH] Enable __ANDROID__ macro for Android x86 target

[Ilya Enkovich]

Hello,

Here is a patch to enable __ANDROID__ macro on x86 Android targets.
Currently it is enabled for ARM only. OK for google/gcc-4_6_2-mobile
branch?

Thanks
Ilya
--

2012-02-21  Enkovich Ilya  

* gcc/config/i386/linux.h (TARGET_OS_CPP_BUILTINS): Add
ANDROID_TARGET_OS_CPP_BUILTINS.


Index: gcc/config/i386/linux.h
===
--- gcc/config/i386/linux.h (revision 184395)
+++ gcc/config/i386/linux.h (working copy)
@@ -73,6 +73,7 @@
   do   \
 {  \
LINUX_TARGET_OS_CPP_BUILTINS(); \
+   ANDROID_TARGET_OS_CPP_BUILTINS();   \
 }  \
   while (0)

Re: [patch lto-plugin]: Fix pr 50616

[Kai Tietz]

2012/2/21 Richard Guenther :
> On Mon, Feb 20, 2012 at 11:59 PM, Kai Tietz  wrote:
>> Hi,
>>
>> this patch replaces use of "llx" for printf/scanf by inttypes.h
>> PRIxMAX/SCNxMAX macros.  If those macros aren't present it defines
>> them as default to "llx".
>
> Bootstrapped and tested on ... ?
>
> Ok.
>
> Thanks,
> Richard.
>
>> ChangeLog
>>
>> 2012-02-20  Kai Tietz  
>>
>>        PR lto/50616
>>        * lto-plugin.c (PRIxMAX,SCNxMAX): Use inttypes.h header if
>> present, otherwise define them
>>        as "llx".
>>
>> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
>> x86_64-unknown-linux-gnu.  Ok for apply?
>>
>> Regards,
>> Kai
>>
>> Index: lto-plugin.c
>> ===
>> --- lto-plugin.c        (revision 184414)
>> +++ lto-plugin.c        (working copy)
>> @@ -38,6 +38,9 @@
>>  #if HAVE_STDINT_H
>>  #include 
>>  #endif
>> +#if HAVE_INTTYPES_H
>> +#include 
>> +#endif
>>  #include 
>>  #include 
>>  #include 
>> @@ -62,6 +65,14 @@
>>  #include "simple-object.h"
>>  #include "plugin-api.h"
>>
>> +#ifndef PRIxMAX
>> +#define PRIxMAX "llx"
>> +#endif
>> +
>> +#ifndef SCNxMAX
>> +#define SCNxMAX "llx"
>> +#endif
>> +
>>  /* Handle opening elf files on hosts, such as Windows, that may use
>>    text file handling that will break binary access.  */
>>  #ifndef O_BINARY
>> @@ -360,7 +371,7 @@
>>
>>       assert (resolution != LDPR_UNKNOWN);
>>
>> -      fprintf (f, "%u %llx %s %s\n",
>> +      fprintf (f, "%u %" PRIxMAX " %s %s\n",
>>                (unsigned int) slot, symtab->aux[j].id,
>>               lto_resolution_str[resolution],
>>               symtab->syms[j].name);
>> @@ -816,7 +827,7 @@
>>
>>   s = strrchr (name, '.');
>>   if (s)
>> -    sscanf (s, ".%llx", &obj->out->id);
>> +    sscanf (s, ".%" SCNxMAX, &obj->out->id);
>>   secdata = xmalloc (length);
>>   offset += obj->file->offset;
>>   if (offset != lseek (obj->file->fd, offset, SEEK_SET)

Hmm, no.  On x86_64 linux PRIxMAX is still defined as "lx", which
would lead to printf-failures.  So inttypes.h is no good approach.  I
will come up with an alternative patch for this.

Regards,
Kai

[v3] Fix libstdc++/52317

[Paolo Carlini]

Hi,

committed mainline and 4_6-branch.

Thanks,
Paolo.

///
2012-02-21  Paolo Carlini  

PR libstdc++/52317
* python/Makefile.am: Update boilerplate license text to GPLv3.
* include/profile/unordered_map: Likewise.
* include/profile/set: Likewise.
* include/profile/base.h: Likewise.
* include/profile/impl/profiler_list_to_slist.h: Likewise.
* include/profile/impl/profiler_container_size.h: Likewise.
* include/profile/impl/profiler_vector_size.h: Likewise.
* include/profile/impl/profiler_hash_func.h: Likewise.
* include/profile/impl/profiler_trace.h: Likewise.
* include/profile/impl/profiler_list_to_vector.h: Likewise.
* include/profile/impl/profiler_vector_to_list.h: Likewise.
* include/profile/impl/profiler.h: Likewise.
* include/profile/impl/profiler_state.h: Likewise.
* include/profile/impl/profiler_map_to_unordered_map.h: Likewise.
* include/profile/impl/profiler_algos.h: Likewise.
* include/profile/impl/profiler_hashtable_size.h: Likewise.
* include/profile/impl/profiler_node.h: Likewise.
* include/profile/vector: Likewise.
* include/profile/unordered_set: Likewise.
* include/profile/map.h: Likewise.
* include/profile/map: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/
wchar_t/dr1261.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/
char/dr1261.cc: Likewise.
* testsuite/20_util/reference_wrapper/invoke-2.cc: Likewise.
Index: python/Makefile.am
===
--- python/Makefile.am  (revision 184429)
+++ python/Makefile.am  (working copy)
@@ -8,18 +8,17 @@
 ## This file is part of the GNU ISO C++ Library.  This library is free
 ## software; you can redistribute it and/or modify it under the
 ## terms of the GNU General Public License as published by the
-## Free Software Foundation; either version 2, or (at your option)
+## Free Software Foundation; either version 3, or (at your option)
 ## any later version.
-
+##
 ## This library is distributed in the hope that it will be useful,
 ## but WITHOUT ANY WARRANTY; without even the implied warranty of
 ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 ## GNU General Public License for more details.
-
+##
 ## You should have received a copy of the GNU General Public License along
-## with this library; see the file COPYING.  If not, write to the Free
-## Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-## USA.
+## with this library; see the file COPYING3.  If not see
+## .
 
 include $(top_srcdir)/fragment.am
 
Index: include/profile/unordered_map
===
--- include/profile/unordered_map   (revision 184429)
+++ include/profile/unordered_map   (working copy)
@@ -5,28 +5,18 @@
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
 // terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
+// Free Software Foundation; either version 3, or (at your option)
 // any later version.
-
+//
 // This library is distributed in the hope that it will be useful,
 // but WITHOUT ANY WARRANTY; without even the implied warranty of
 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 // GNU General Public License for more details.
-
+//
 // You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING.  If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
+// with this library; see the file COPYING3.  If not see
+// .
 
-// As a special exception, you may use this file as part of a free software
-// library without restriction.  Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License.  This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
 /** @file profile/unordered_map
  *  This file is a GNU profile extension to the Standard C++ Library.
  */
Index: include/profile/set
===
--- include/profile/set (revision 184429)
+++ include/profile/set (working copy)
@@ -5,28 +5,18 @@
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under 

[Committed] S/390: Fix some DFP testsuite fails

[Andreas Krebbel]

Hi,

the attached patch fixes several dfp testsuite fails with -march=z196
-m31:

Running target unix
FAIL: c-c++-common/dfp/convert-int-max.c -std=gnu++98 (internal compiler error)
FAIL: c-c++-common/dfp/convert-int-max.c -std=gnu++98 (test for excess errors)
WARNING: c-c++-common/dfp/convert-int-max.c -std=gnu++98 compilation failed to 
produce executable
FAIL: c-c++-common/dfp/convert-int-max.c -std=gnu++11 (internal compiler error)
FAIL: c-c++-common/dfp/convert-int-max.c -std=gnu++11 (test for excess errors)
WARNING: c-c++-common/dfp/convert-int-max.c -std=gnu++11 compilation failed to 
produce executable
FAIL: c-c++-common/dfp/convert-int.c -std=gnu++98 (internal compiler error)
FAIL: c-c++-common/dfp/convert-int.c -std=gnu++98 (test for excess errors)
WARNING: c-c++-common/dfp/convert-int.c -std=gnu++98 compilation failed to 
produce executable
FAIL: c-c++-common/dfp/convert-int.c -std=gnu++11 (internal compiler error)
FAIL: c-c++-common/dfp/convert-int.c -std=gnu++11 (test for excess errors)
WARNING: c-c++-common/dfp/convert-int.c -std=gnu++11 compilation failed to 
produce executable

Applied to 4.6 and mainline.

Bye,

-Andreas-


2012-02-21  Andreas Krebbel  

* config/s390/s390.md ("fixuns_truncsi2"): Replace
TARGET_HARD_FLOAT with TARGET_HARD_DFP.


---
 gcc/config/s390/s390.md |2 !!
 1 file changed, 2 modifications(!)

Index: gcc/config/s390/s390.md
===
*** gcc/config/s390/s390.md.orig
--- gcc/config/s390/s390.md
***
*** 4012,4018 
  (unsigned_fix:SI (match_operand:DFP 1 "register_operand" "")))
   (unspec:SI [(const_int 5)] UNSPEC_ROUND)
   (clobber (reg:CC CC_REGNUM))])]
!   "TARGET_Z196 && TARGET_HARD_FLOAT"
"")
  
  ; fixuns_trunc(tf|df|sf|td|dd)(di|si)2 instruction patterns.
--- 4012,4018 
  (unsigned_fix:SI (match_operand:DFP 1 "register_operand" "")))
   (unspec:SI [(const_int 5)] UNSPEC_ROUND)
   (clobber (reg:CC CC_REGNUM))])]
!   "TARGET_Z196 && TARGET_HARD_DFP"
"")
  
  ; fixuns_trunc(tf|df|sf|td|dd)(di|si)2 instruction patterns.

[Patch,AVR]: Fix PR50063 GCC does not support FP = SP

[Georg-Johann Lay]

This is a tentative patch to the PR. As Jakub explained, GCC does not support
configurations with FP = SP and DSE optimizer generates wrong code for AVR.

This patch implements Jakub's proposal to hack around by hiding the action of
setting/moving between SP and SP into UNSPEC[_VOLATILE]s.

All works fine with respect to code generation.
But what I cannot manage getting debug information right.

Without RTX_FRAME_RELATED_P at most insns, I just get one new dwarf-ICE:

dwarf2out_frame_debug_adjust_cfa[test2:dwarf2(233)]: pat = (set (reg/f:HI 28 
r28)
(plus:HI (reg/f:HI 32 __SP_L__)
(const_int -40 [0xffd8])))
dwf_regno (XEXP (src, 0)) = 32
cur_cfa->reg = 28
./gcc/testsuite/gcc.c-torture/execute/builtins/snprintf-chk.c: In function
'test2':
./gcc/testsuite/gcc.c-torture/execute/builtins/snprintf-chk.c:159:1: internal
compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1098

However, if all insns that are involved in SP/FP manipulation get the
RTX_FRAME_RELATED_P, almost every test case that has -g crashes with this
dwarf-ICE.

I am stuck now and don't know how to proceed with this.

Many thanks, Richard, for your help with the CFA notes.
Unfortunately, adding the RTX_FRAME_RELATED_P markers shreds every...

Attached the patch as-is and a plain work-copy of
avr.c:avr_prologue_setup_frame

Johann

PR other/50063
* config/avr/avr.md (UNSPEC_READ_SP): New define_c_enum "unspec".
(read_sp): New insn.
(movhi_sp_r): Handle -1 (unknown IRQ state) and 2 (8-bit SP) in
operand 2.
* config/avr/avr.c (avr_prologue_setup_frame): Adjust prologue
setup to use read_sp instead of vanilla move.
Adjust REG_CFA notes to superseed unspec.
(expand_epilogue):  Adjust epilogue setup to use read_sp instead
of vanilla move.
As function body might contain CLI or SEI: Use irq_state 0 (IRQ
known to be off) only with TARGET_NO_INTERRUPTS. Never use
irq_state 1 (IRQ known to be on) here.

static void
emit_push_byte (unsigned regno, bool frame_related_p)
{
  rtx mem, reg, insn;

  mem = gen_rtx_POST_DEC (HImode, stack_pointer_rtx);
  mem = gen_frame_mem (QImode, mem);
  reg = gen_rtx_REG (QImode, regno);

  insn = emit_insn (gen_rtx_SET (VOIDmode, mem, reg));
  if (frame_related_p)
RTX_FRAME_RELATED_P (insn) = 1;

  cfun->machine->stack_usage++;
}


/*  Helper for expand_prologue.  Emit a push of a SFR via tmp_reg.
SFR is a MEM representing the memory location of the SFR.
If CLR_P then clear the SFR after the push using zero_reg.  */

static void
emit_push_sfr (rtx sfr, bool frame_related_p, bool clr_p)
{
  rtx insn;
  
  gcc_assert (MEM_P (sfr));

  /* IN __tmp_reg__, IO(SFR) */
  insn = emit_move_insn (tmp_reg_rtx, sfr);
  if (frame_related_p)
RTX_FRAME_RELATED_P (insn) = 1;
  
  /* PUSH __tmp_reg__ */
  emit_push_byte (TMP_REGNO, frame_related_p);

  if (clr_p)
{
  /* OUT IO(SFR), __zero_reg__ */
  insn = emit_move_insn (sfr, const0_rtx);
  if (frame_related_p)
RTX_FRAME_RELATED_P (insn) = 1;
}
}

static void
avr_prologue_setup_frame (HOST_WIDE_INT size, HARD_REG_SET set)
{
  rtx insn;
  bool isr_p = cfun->machine->is_interrupt || cfun->machine->is_signal;
  int live_seq = sequent_regs_live ();

  bool minimize = (TARGET_CALL_PROLOGUES
   && live_seq
   && !isr_p
   && !cfun->machine->is_OS_task
   && !cfun->machine->is_OS_main);
  
  if (minimize
  && (frame_pointer_needed
  || avr_outgoing_args_size() > 8
  || (AVR_2_BYTE_PC && live_seq > 6)
  || live_seq > 7)) 
{
  rtx pattern;
  int first_reg, reg, offset;

  emit_move_insn (gen_rtx_REG (HImode, REG_X), 
  gen_int_mode (size, HImode));

  pattern = gen_call_prologue_saves (gen_int_mode (live_seq, HImode),
 gen_int_mode (live_seq+size, HImode));
  insn = emit_insn (pattern);
  RTX_FRAME_RELATED_P (insn) = 1;

  /* Describe the effect of the unspec_volatile call to prologue_saves.
 Note that this formulation assumes that add_reg_note pushes the
 notes to the front.  Thus we build them in the reverse order of
 how we want dwarf2out to process them.  */

  /* The function does always set frame_pointer_rtx, but whether that
 is going to be permanent in the function is frame_pointer_needed.  */

  add_reg_note (insn, REG_CFA_ADJUST_CFA,
gen_rtx_SET (VOIDmode, (frame_pointer_needed
? frame_pointer_rtx
: stack_pointer_rtx),
 plus_constant (stack_pointer_rtx,
-(size + live_seq;

  /* Note that live_seq always contains r28+r29, but the other
 registers to be saved are all below 18.  */

  first

Re: [Patch,AVR]: Fix PR50063 GCC does not support FP = SP

[Jakub Jelinek]

On Tue, Feb 21, 2012 at 12:38:48PM +0100, Georg-Johann Lay wrote:
> However, if all insns that are involved in SP/FP manipulation get the
> RTX_FRAME_RELATED_P, almost every test case that has -g crashes with this
> dwarf-ICE.

My suggestion actually wasn't to use unspec for reading from sp, but instead
to use it on the insn which sets sp from hfp, i.e. instead of that
   (insn 47 46 48 2 (set (reg/f:HI 32 __SP_L__)
   (reg/f:HI 28 r28)) pr50063.c:9 -1
(nil))
in the testcase use:
   (insn 47 46 48 2 (set (reg/f:HI 32 __SP_L__)
   (unspec [(reg/f:HI 28 r28)] UNSPEC_SET_SP_FROM_FP)) pr50063.c:9 -1
(nil))
or so.  You should be able to use REG_FRAME_RELATED_EXPR with the old set
if needed (though, the insn strangely isn't RTX_FRAME_RELATED_P, preexisting
bug?).  Just to hide from cselib/alias code that you are setting hfp from
sp, then adjusting hfp and then setting sp back from it.  With the unspec
it will just not know what value sp has there.

Jakub

[testsuite,AVR,committed]: Add test case for PR middle-end/51782

[Georg-Johann Lay]

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

testsuite/

PR middle-end/51782
* gcc.target/avr/torture/pr51782-1.c: New test.

Re: [PATCH, i386] RTM support

[Kirill Yukhin]

Hi guys,

I've played ".+6" and it seems to be working, although I'd rather
prefer "$0" much better, since it is not deal with insn+ops length.
Will prepare updated patch later today

K

On Tue, Feb 21, 2012 at 12:02 PM, Andi Kleen  wrote:
>> BTW: Looking a bit more to the spec, we can simply write
>>
>> xbegin $0
>>
>> as the spec says that offset is relative to the _NEXT_ instruction
>
> Yes that's true. I'm not sure the .+6 even results in 0. Kirill?
>
> -Andi
>
> --
> a...@linux.intel.com -- Speaking for myself only.

[PATCH] Avoid setting TREE_ADDRESSABLE during MEM_REF gimplification

[Richard Guenther]

When PRE inserts stmts it re-gimplifies them.  This causes spurious
TREE_ADDRESSABLE bits to be set on decls as the testcase shows.
It's not easy to fix with the recursive nature of the gimplifier,
and generally we cannot rely on the gimplifier predicates to
properly tell us whether we need to do anything (at least not without
changing them, which would be a good thing, but not at this time).

The following patch places a workaround at the point we gimplify
the MEM_REF address instead.

Ideally gimplify_addr_expr would not mark things addressable (but
the frontends should, and mostly do, already do that), and
gimplify_expr would have an early out,
if (gimple_test_f (*expr_p)) return GS_ALL_DONE;

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

Richard.

2012-02-21  Richard Guenther  

PR tree-optimization/52324
* gimplify.c (gimplify_expr): When re-gimplifying expressions
do not gimplify a MEM_REF address operand if it is already
in suitable form.

* gcc.dg/tree-ssa/ssa-lim-10.c: New testcase.

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 184428)
+++ gcc/gimplify.c  (working copy)
@@ -7061,15 +7061,23 @@ gimplify_expr (tree *expr_p, gimple_seq
  ret = GS_OK;
  break;
}
- ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p, post_p,
-  is_gimple_mem_ref_addr, fb_rvalue);
- if (ret == GS_ERROR)
-   break;
+ /* Avoid re-gimplifying the address operand if it is already
+in suitable form.  Re-gimplifying would mark the address
+operand addressable.  Always gimplify when not in SSA form
+as we still may have to gimplify decls with value-exprs.  */
+ if (!gimplify_ctxp || !gimplify_ctxp->into_ssa
+ || !is_gimple_mem_ref_addr (TREE_OPERAND (*expr_p, 0)))
+   {
+ ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p, post_p,
+  is_gimple_mem_ref_addr, fb_rvalue);
+ if (ret == GS_ERROR)
+   break;
+   }
  recalculate_side_effects (*expr_p);
  ret = GS_ALL_DONE;
  break;
 
- /* Constants need not be gimplified.  */
+   /* Constants need not be gimplified.  */
case INTEGER_CST:
case REAL_CST:
case FIXED_CST:
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-10.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-10.c  (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-10.c  (revision 0)
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-lim1-details" } */
+
+int *l, *r;
+int test_func(void)
+{
+  int i;
+  int direction;
+  static int pos;
+
+  pos = 0;
+  direction = 1;
+
+  for ( i = 0; i <= 400; i++ )
+{
+  if ( direction == 0 )
+   pos = l[pos];
+  else
+   pos = r[pos];
+
+  if ( pos == -1 )
+   {
+ pos = 0;
+ direction = !direction;
+   }
+}
+  return i;
+}
+
+/* { dg-final { scan-tree-dump "Executing store motion of pos" "lim1" } } */
+/* { dg-final { cleanup-tree-dump "lim1" } } */

Re: [PATCH, i386] RTM support

[Jakub Jelinek]

On Tue, Feb 21, 2012 at 04:30:01PM +0400, Kirill Yukhin wrote:
> I've played ".+6" and it seems to be working, although I'd rather
> prefer "$0" much better, since it is not deal with insn+ops length.
> Will prepare updated patch later today

xbegin $0
seems to work only for Intel syntax, not AT&T.  xbegin .+6 works with both.
Error: operand type mismatch for `xbegin'
is the error I get from gas trunk.

Jakub

[PATCH, PR 51782] Derive rtx address space from base object

[Martin Jambor]

Hi,

PR 51782 showed that COMPONENT_REFs created by SRA got expanded with a
wrong address space because the address space was not specified in the
type of the whole tree.  This is however inconsistent with how we
encode address spaces in MEM_REFs where they are supposed to be stored
in the type of its address operand (as opposed to the type of the
reference).  Therefore the following patch changes the expansion to
always look at the base address and look through MEM_REFs if
necessary.

It fixes the issue for me on a cross compiler, a bootstrap and
testsuite run on x86_64-linux showed only regressions described in PR
52297 so I consider it successful.  My understanding is that Richi
approved it in bugzilla.  Georg-Johann Lay said he would test it on HW
or simulator that actually uses address spaces and he has also already
committed a testcase for this bug.  Therefore I intend to commit the
patch if his tests pass too.

Thanks,

Martin


2012-02-20  Martin Jambor  

PR tree-optimizaion/51782
* emit-rtl.c (set_mem_attributes_minus_bitpos): Set address space
according to the base object.

Index: src/gcc/emit-rtl.c
===
--- src.orig/gcc/emit-rtl.c 2012-02-13 14:52:28.0 +0100
+++ src/gcc/emit-rtl.c  2012-02-20 18:35:03.0 +0100
@@ -1548,6 +1548,7 @@ set_mem_attributes_minus_bitpos (rtx ref
   HOST_WIDE_INT apply_bitpos = 0;
   tree type;
   struct mem_attrs attrs, *defattrs, *refattrs;
+  addr_space_t as;
 
   /* It can happen that type_for_mode was given a mode for which there
  is no language-level type.  In which case it returns NULL, which
@@ -1681,17 +1682,29 @@ set_mem_attributes_minus_bitpos (rtx ref
   MEM_NOTRAP_P (ref) = !tree_could_trap_p (t);
 
   base = get_base_address (t);
-  if (base && DECL_P (base)
- && TREE_READONLY (base)
- && (TREE_STATIC (base) || DECL_EXTERNAL (base))
- && !TREE_THIS_VOLATILE (base))
-   MEM_READONLY_P (ref) = 1;
-
-  /* Mark static const strings readonly as well.  */
-  if (base && TREE_CODE (base) == STRING_CST
- && TREE_READONLY (base)
- && TREE_STATIC (base))
-   MEM_READONLY_P (ref) = 1;
+  if (base)
+   {
+ if (DECL_P (base)
+ && TREE_READONLY (base)
+ && (TREE_STATIC (base) || DECL_EXTERNAL (base))
+ && !TREE_THIS_VOLATILE (base))
+   MEM_READONLY_P (ref) = 1;
+
+ /* Mark static const strings readonly as well.  */
+ if (TREE_CODE (base) == STRING_CST
+ && TREE_READONLY (base)
+ && TREE_STATIC (base))
+   MEM_READONLY_P (ref) = 1;
+
+ if (TREE_CODE (base) == MEM_REF
+ || TREE_CODE (base) == TARGET_MEM_REF)
+   as = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (base,
+ 0;
+ else
+   as = TYPE_ADDR_SPACE (TREE_TYPE (base));
+   }
+  else
+   as = TYPE_ADDR_SPACE (type);
 
   /* If this expression uses it's parent's alias set, mark it such
 that we won't change it.  */
@@ -1830,6 +1843,8 @@ set_mem_attributes_minus_bitpos (rtx ref
  attrs.align = MAX (attrs.align, obj_align);
}
 }
+  else
+as = TYPE_ADDR_SPACE (type);
 
   /* If we modified OFFSET based on T, then subtract the outstanding
  bit position offset.  Similarly, increase the size of the accessed
@@ -1843,7 +1858,7 @@ set_mem_attributes_minus_bitpos (rtx ref
 }
 
   /* Now set the attributes we computed above.  */
-  attrs.addrspace = TYPE_ADDR_SPACE (type);
+  attrs.addrspace = as;
   set_mem_attrs (ref, &attrs);
 }
 

[PATCH] Fix PR52314

[Richard Guenther]

The gimplifier, when forcing a value to a temporary, uses the
type of the value for that temporary variable, making it for
example volatile or const, or puts it in a different address-space
even.  That's odd and not required, we can decay to the main-variant type.

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

Richard.

2012-02-21  Richard Guenther  

PR middle-end/52314
* gimplify.c (create_tmp_from_val): Use the main variant type
for the type of the temporary we create.

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 184435)
+++ gcc/gimplify.c  (working copy)
@@ -504,7 +504,8 @@ create_tmp_reg (tree type, const char *p
 static inline tree
 create_tmp_from_val (tree val)
 {
-  return create_tmp_var (TREE_TYPE (val), get_name (val));
+  /* Drop all qualifiers and address-space information from the value type.  */
+  return create_tmp_var (TYPE_MAIN_VARIANT (TREE_TYPE (val)), get_name (val));
 }
 
 /* Create a temporary to hold the value of VAL.  If IS_FORMAL, try to reuse

Re: [PATCH] Fix PR52314

[Jakub Jelinek]

On Tue, Feb 21, 2012 at 03:06:40PM +0100, Richard Guenther wrote:
> 
> The gimplifier, when forcing a value to a temporary, uses the
> type of the value for that temporary variable, making it for
> example volatile or const, or puts it in a different address-space
> even.  That's odd and not required, we can decay to the main-variant type.

Shouldn't restrict be preserved though?

> 2012-02-21  Richard Guenther  
> 
>   PR middle-end/52314
>   * gimplify.c (create_tmp_from_val): Use the main variant type
>   for the type of the temporary we create.
> 
> Index: gcc/gimplify.c
> ===
> --- gcc/gimplify.c(revision 184435)
> +++ gcc/gimplify.c(working copy)
> @@ -504,7 +504,8 @@ create_tmp_reg (tree type, const char *p
>  static inline tree
>  create_tmp_from_val (tree val)
>  {
> -  return create_tmp_var (TREE_TYPE (val), get_name (val));
> +  /* Drop all qualifiers and address-space information from the value type.  
> */
> +  return create_tmp_var (TYPE_MAIN_VARIANT (TREE_TYPE (val)), get_name 
> (val));
>  }
>  
>  /* Create a temporary to hold the value of VAL.  If IS_FORMAL, try to reuse

Jakub

Re: [PATCH] Fix PR52314

[Richard Guenther]

On Tue, 21 Feb 2012, Jakub Jelinek wrote:

> On Tue, Feb 21, 2012 at 03:06:40PM +0100, Richard Guenther wrote:
> > 
> > The gimplifier, when forcing a value to a temporary, uses the
> > type of the value for that temporary variable, making it for
> > example volatile or const, or puts it in a different address-space
> > even.  That's odd and not required, we can decay to the main-variant type.
> 
> Shouldn't restrict be preserved though?

No, we don't preserve restrict casts anymore.

Richard.

Re: [PATCH, i386] RTM support

[Kirill Yukhin]

As far as I undersand, correct one seems like that:
.intel_syntax
xbegin $0
nop

.att_syntax
xbegin ($0)
nop

Which disassembles into:
 <.text>:
   0:   c7 f8 00 00 00 00   xbeginq 0x6
   6:   90  nop
   7:   c7 f8 00 00 00 00   xbeginq 0xd
   d:   90  nop

K

On Tue, Feb 21, 2012 at 4:37 PM, Jakub Jelinek  wrote:
> On Tue, Feb 21, 2012 at 04:30:01PM +0400, Kirill Yukhin wrote:
>> I've played ".+6" and it seems to be working, although I'd rather
>> prefer "$0" much better, since it is not deal with insn+ops length.
>> Will prepare updated patch later today
>
> xbegin $0
> seems to work only for Intel syntax, not AT&T.  xbegin .+6 works with both.
> Error: operand type mismatch for `xbegin'
> is the error I get from gas trunk.
>
>        Jakub

Re: Implementation of swi attribute for ARM

[Richard Earnshaw]

On 21/02/12 05:39, Barracuda wrote:
> Hello!
> I'm new to GCC internals, but I'm using GCC for couple of years.
> Yesterday I found that GCC does not support calling SWI routines from C/C++
> code.
> For example, in other ARM-targeted compiliers developer can use such syntax
> for function prototype:
> In ARM IAR:
> #pragma swi_number=0x15
> int some_call(int, int);
> In RVDS:
> __swi(0x15) int some_call(int, int);
> And then just call function as usual:
> a = some_call(5, 8);
> GCC lacks this feauture, so I've decided to go on Free Software way - if your
> need something, implement it yourself =)
> I can't write any testsuite, because I don't know how to do it, sorry. I
> tested some programs written for IAR, they compiled and launched successfully.
> I've also tested some programs with functions that don't use this attribute -
> they was unaffected by this patch. So I decided to send it to this mailing
> list.
> Changelog and patch included in attachment.
> I tested cross-compiling, host=i686-pc-linux-gnu and host=x86_64-pc-linux-gnu,
> target=arm-linux-gnueabi. Works stable and fine.
> 
> Barracuda
> 
> 
> Chlog.txt
> 
> 
> 2012-02-21  Labutin Ivan  
> 
>   * gcc/config/arm/arm.c: Added support for __attribute__ ((swi(x))).
>   With this, you can write function prototype:
> int some_sys_call (int, char*) __attribute__ ((swi(0x15)));
>   Now, if you call it:
> a = some_sys_call (5, "test");
>   it will produce following assembler output:
> ...
> MOV R1, #test_adr 
> MOV R0, #5
> SWI 0x15
> ...
>   This is an analogue of 
> #pragma swi_number=0x15 int some_sys_call (int, char *);
>   or
> __swi(0x15) int some_sys_call (int, char*);
>   in other ARM-targeted compiliers.
> * gcc/config/arm.md: Likewise.
> * gcc/config/arm-protos.h: Likewise. 

Thanks for the patch, I think it should be a useful addition.  However,
before this can go in, there are a number of things that need addressing.

1) Do you have a copyright assignment in place with the FSF?  A
contribution of this size cannot go in without one.

2) We need some tests.  Changes of this nature without tests are likely
to get broken over time unless there's some way of checking that this
doesn't happen.

3) We need some documentation for users.  Things you need to cover
include: how to use the attribute, how this interacts with the procedure
call standard (incidentally, you just seem to take the default rules for
the PCS, is this what you intended?).  Furthermore, you need to explain
that this feature cannot be used if the SWI call number is not passed
either in the SWI instruction itself, or as a normal argument.  Linux is
a special example of this where the call number is passed in R7.

4) Have you tested this to ensure that it works with tail-calls?  I
can't see any evidence you've handled that, so

void f(int a)
{
  myswicall(a);
}

may well end up doing the wrong thing.

5) There are some coding standard issues to sort out.  Use
}
  else
{

Not

  } else {

6) No comments, not one... :-(

7) When you don't use an argument formal in the body of a function, you
need to mark it as unused, or you'll break native bootstraps.

8) Although you've added support for both ARM and Thumb, I don't see any
value range checking for the SWI call number.  The thumb instruction set
only supports SWI calls in the range 0-255, while ARM supports 0-0xff.

9) The patch suggests to me that it's been prepared against gcc-4.5.  We
need patch submissions against gcc-trunk.  Please can you rebase.

10) Finally, the name SWI is now deprecated in assembly syntax, I think
the attribute should use the new (actually it's not really that new now)
name, SVC.

For extra brownie points, you could even extend it to support the SMC
and HVC instructions.

R.

Re: [PATCH, i386] RTM support

[Jakub Jelinek]

On Tue, Feb 21, 2012 at 06:11:54PM +0400, Kirill Yukhin wrote:
> As far as I undersand, correct one seems like that:
> .intel_syntax
> xbegin $0
> nop
> 
> .att_syntax
> xbegin ($0)
> nop
> 
> Which disassembles into:
>  <.text>:
>0:   c7 f8 00 00 00 00   xbeginq 0x6
>6:   90  nop
>7:   c7 f8 00 00 00 00   xbeginq 0xd
>d:   90  nop

Doesn't seem to do what you expect (nor xbegin $0 in Intel syntax):
$ /usr/src/binutils/obj/gas/as-new -o /tmp/a.o /tmp/a.s
$ cat /tmp/a.s
#.intel_syntax noprefix
nop
xbegin ($0)
nop
xbegin .+6
nop
$ /usr/src/binutils/obj/binutils/objdump -dr /tmp/a.o

/tmp/a.o: file format elf64-x86-64


Disassembly of section .text:

 <.text>:
   0:   90  nop
   1:   c7 f8 00 00 00 00   xbeginq 0x7
   3: R_X86_64_PC32 $0+0xfffc
   7:   90  nop
   8:   c7 f8 00 00 00 00   xbeginq 0xe
   e:   90  nop

Note the relocation in there, you don't want there any.

Jakub

Re: [PATCH, i386] RTM support

[Uros Bizjak]

On Tue, Feb 21, 2012 at 3:21 PM, Jakub Jelinek  wrote:

>> As far as I undersand, correct one seems like that:
>> .intel_syntax
>>         xbegin $0
>>         nop
>>
>> .att_syntax
>>         xbegin ($0)
>>         nop
>>
>> Which disassembles into:
>>  <.text>:
>>    0:   c7 f8 00 00 00 00       xbeginq 0x6
>>    6:   90                      nop
>>    7:   c7 f8 00 00 00 00       xbeginq 0xd
>>    d:   90                      nop
>
> Doesn't seem to do what you expect (nor xbegin $0 in Intel syntax):
> $ /usr/src/binutils/obj/gas/as-new -o /tmp/a.o /tmp/a.s
> $ cat /tmp/a.s
> #.intel_syntax noprefix
> nop
> xbegin ($0)
> nop
> xbegin .+6
> nop
> $ /usr/src/binutils/obj/binutils/objdump -dr /tmp/a.o
>
> /tmp/a.o:     file format elf64-x86-64
>
>
> Disassembly of section .text:
>
>  <.text>:
>   0:   90                      nop
>   1:   c7 f8 00 00 00 00       xbeginq 0x7
>   3: R_X86_64_PC32     $0+0xfffc
>   7:   90                      nop
>   8:   c7 f8 00 00 00 00       xbeginq 0xe
>   e:   90                      nop
>
> Note the relocation in there, you don't want there any.

OK, need to install the latest SVN binutils to try this out.

Ultimatelly, we can generate the label and pass it to xbegin_1. This
will definitelly avoid all confusion where +6 comes from.

Uros.

[Committed] S/390: Make -mhard-dfp the default whenever possible

[Andreas Krebbel]

Hi,

with the attached patch -mhard-dfp is used whenever possible. So far
it was disabled by default for -m31 although hardware dfp is available
when also -mzarch is given.

Committed to mainline.

Bye,

-Andreas-

2012-02-21  Andreas Krebbel  

* config/s390/s390.c (s390_option_override): Make -mhard-dfp the
default if possible and not specified otherwise.

---
 gcc/config/s390/s390.c |5 +
 1 file changed, 5 insertions(+)

Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** s390_option_override (void)
*** 1540,1545 
--- 1540,1550 
if (TARGET_64BIT && !TARGET_ZARCH)
  error ("64-bit ABI not supported in ESA/390 mode");
  
+   /* Use hardware DFP if available and not explicitly disabled by
+  user. E.g. with -m31 -march=z10 -mzarch   */
+   if (!(target_flags_explicit & MASK_HARD_DFP) && TARGET_DFP)
+ target_flags |= MASK_HARD_DFP;
+ 
if (TARGET_HARD_DFP && !TARGET_DFP)
  {
if (target_flags_explicit & MASK_HARD_DFP)

Re: [PATCH] Adjust 'malloc' attribute documentation to match implementation

[Tijl Coosemans]

On Tuesday 21 February 2012 10:19:15 Richard Guenther wrote:
> On Mon, Feb 20, 2012 at 8:55 PM, Tijl Coosemans  wrote:
>> On Monday 9 January 2012 10:05:08 Richard Guenther wrote:
>>> Since GCC 4.4 applying the malloc attribute to realloc-like
>>> functions does not work under the documented constraints because
>>> the contents of the memory pointed to are not properly transfered
>>> from the realloc argument (or treated as pointing to anything,
>>> like 4.3 behaved).
>>>
>>> The following adjusts documentation to reflect implementation
>>> reality (we do have an implementation detail that treats the
>>> memory blob returned for non-builtins as pointing to any global
>>> variable, but that is neither documented nor do I plan to do
>>> so - I presume it is to allow allocation + initialization
>>> routines to be marked with malloc, but even that area looks
>>> susceptible to misinterpretation to me).
>>>
>>> Any comments?
>>
>> The new text says the memory must be undefined, but gives calloc as an
>> example for which the memory is defined to be zero. Also, GCC has
>> built-ins for strdup and strndup with the malloc attribute and GLIBC
>> further adds it to wcsdup (wchar_t version of strdup) and tempnam. In
>> all of these cases the memory is defined.
>>
>> Isn't the reason the attribute doesn't apply to realloc simply because
>> the returned pointer may alias the one given as argument, rather than
>> having defined memory content?
> 
> The question is really what the alias-analysis code can derive from a
> function that is declared with the malloc attribute.  The most useful
> property for alias analysis would be that te non-aliasing holds
> transitively, thus reading (with any level of indirection) from the returned
> pointer does not produce memory that is aliased by any other pointer.
> That's what happens for 'malloc' (also for 'calloc' - you can't do any
> further indirections through the NULL pointers the memory holds).  It
> does not happen for realloc.  Currently the alias-analysis code does
> assume exactly this properly (only very slightly weakened, possibly
> because we broke some code I guess).
> 
> Internally, all builtins with interesting allocation properties are handled
> explicitely, so we probably should not rely on the malloc attribute present
> on those (and maybe simply drop it there).
> 
> The question is really what is useful for users, and what's the most natural
> behavior?  For example
> 
> int **my_initialized_malloc (int *p)
> {
>   int **q = malloc (sizeof (int *));
>   *q = p;
>   return q;
> }
> 
> would not qualify for the 'malloc' attribute (but we've taken measures to not
> miscompile this kind of code, it seems to be a very common misconception
> to place annotate these with 'malloc').
> 
> I'm not sure how to exactly constrain the documentation for 'malloc' better.
> Maybe
> 
> The @code{malloc} attribute is used to tell the compiler that a function
> may be treated as if any non-@code{NULL} pointer it returns cannot
> alias any other pointer valid when the function returns and that the memory
> does not contain any pointer value.
> 
> ?  Because that is what is relevant.  That you can in no way extract
> a pointer value from the memory pointed to by the return value.  Because
> alias analysis will assume any such extracted pointer value points
> nowhere (so, extracting a NULL pointer is ok).
> 
> The reasoning why the string functions have the malloc attribute was
> probably that strings do not contain pointer values.  Of course they
> can, you can store a character encoding of a pointer, copy the
> string and decode it from the copy again.  We'd miscompile then
> 
>  int i = 1;
>  int *p = &i;
>  char ptr[16];
>  ... inline encode p into ptr ...
>  char *x = strdup (ptr);
>  int *q = ... inline decode x to q
>  *q = 2;
>  return i;
> 
> to return 1 because we do not see that q may point to i.  Of course
> we properly handle the transfer of pointers for str[n]dup, so the
> 'malloc' attribute on it is a lie...

Thanks, that was very informative.

Is it correct to say that the attribute applies to deep copies, but not to
shallow ones?

How about the following text:

@item malloc
@cindex @code{malloc} attribute
The @code{malloc} attribute is used to tell the compiler that a pointer
returned by a function is either @code{NULL} or points to a newly
allocated object and that any pointer within that object is either
uninitialised, @code{NULL} or pointing to a newly allocated object for
which the same conditions hold recursively.  The compiler assumes that
existing variables and memory cannot be accessed through the returned
pointer which will often improve optimization.
Standard functions with this property include @code{malloc} and
@code{calloc}.  @code{realloc}-like functions do not have this
property as the returned pointer may alias the one given as argument
or the memory pointed to may contain initialised pointers.
@code{strdup}-like functions have this property as long as

Re: [PATCH, i386] RTM support

[Patrick Marlier]

On 02/21/2012 02:52 AM, Uros Bizjak wrote:

On Tue, Feb 21, 2012 at 12:26 AM, Andi Kleen  wrote:

IIUC the documentation, the fallback label is a parameter to xbegin
insn, but the insn itself doesn't jump anywhere - it just records the


 From the point of view of the program XBEGIN behaves like a conditional
jump (with a very complicated and unpredictable condition)


Yes, but as it is written ATM, it conditionally jumps to the next insn.

BTW: Looking a bit more to the spec, we can simply write

xbegin $0

as the spec says that offset is relative to the _NEXT_ instruction.


AFAIU, the current binutils 'as' expects a label not an offset. So 
"xbegin 0" means fallback at label 0.

--
Patrick

Re: [PATCH] PR target/52137 - bdver2 scheduler needs to be added to bdver1 insn reservations

[Quentin Neill]

On Tue, Feb 21, 2012 at 2:46 AM, Jakub Jelinek  wrote:
> On Tue, Feb 21, 2012 at 08:49:13AM +0100, Uros Bizjak wrote:
>> > 2012-02-20  Quentin Neill  
>> >
>> >     PR target/52137
>> >     * gcc/config/i386/bdver1.md (bdver1_call, bdver1_push,
>
> Please leave out gcc/ prefix from the ChangeLog entry though.
>
>        Jakub

Hi,

Committed with update to ChangeLog entry.  Thanks for your
consideration for this patch.
-- 
Quentin

Re: [PATCH, i386] RTM support

[Kirill Yukhin]

Yes,
Patrick, you were faster :)
Seems, we just need to pass 0 as IMM value

On Tue, Feb 21, 2012 at 7:14 PM, Patrick Marlier
 wrote:
> On 02/21/2012 02:52 AM, Uros Bizjak wrote:
>>
>> On Tue, Feb 21, 2012 at 12:26 AM, Andi Kleen  wrote:

 IIUC the documentation, the fallback label is a parameter to xbegin
 insn, but the insn itself doesn't jump anywhere - it just records the
>>>
>>>
>>>  From the point of view of the program XBEGIN behaves like a conditional
>>> jump (with a very complicated and unpredictable condition)
>>
>>
>> Yes, but as it is written ATM, it conditionally jumps to the next insn.
>>
>> BTW: Looking a bit more to the spec, we can simply write
>>
>> xbegin $0
>>
>> as the spec says that offset is relative to the _NEXT_ instruction.
>
>
> AFAIU, the current binutils 'as' expects a label not an offset. So "xbegin
> 0" means fallback at label 0.
> --
> Patrick
>
>

[PATCH] testsuite: Turn -fgnu-tm test into link test

[Andreas Krebbel]

Hi,

using the -fgnu-tm option fails for targets not supporting libitm with
a *link* failure.  So the compile test wasn't sufficient.

With the attached patch the following failures disappear on s390 and
s390x:

FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, 
-flto -fgnu-tm
UNRESOLVED: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o 
execute -flto -fgnu-tm
FAIL: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o link, 
-flto -fgnu-tm
UNRESOLVED: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o 
execute -flto -fgnu-tm
FAIL: gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o link, 
-flto -fgnu-tm
UNRESOLVED: gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o 
execute -flto -fgnu-tm
XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times optimized "link_error" 0

Ok for mainline?

Bye,

-Andreas-


2012-02-21  Andreas Krebbel  

* lib/target-supports.exp (check_effective_target_fgnu_tm): Make
it an "executable" test in order to check whether linking against
libitm works.

---
 gcc/testsuite/lib/target-supports.exp |4 
 1 file changed, 4 modifications(!)

Index: gcc/testsuite/lib/target-supports.exp
===
*** gcc/testsuite/lib/target-supports.exp.orig
--- gcc/testsuite/lib/target-supports.exp
*** proc check_effective_target_fopenmp {} {
*** 720,727 
  # code, 0 otherwise.
  
  proc check_effective_target_fgnu_tm {} {
! return [check_no_compiler_messages fgnu_tm object {
!   void foo (void) { }
  } "-fgnu-tm"]
  }
  
--- 720,727 
  # code, 0 otherwise.
  
  proc check_effective_target_fgnu_tm {} {
! return [check_no_compiler_messages fgnu_tm executable {
!   int main (void) { return 0; }
  } "-fgnu-tm"]
  }
  

Re: [PATCH][ARM] 64-bit shifts in NEON.

[Andrew Stubbs]

On 06/02/12 13:13, Andrew Stubbs wrote:

This patch adds DImode shift support in NEON registers/instructions.

The patch causes delays any lowering until the split2 pass, after the
register allocator has chosen whether to do the shift in NEON (VFP)
registers, or in core-registers.

The core-registers case depends on the patch I previously posted here:
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01472.html

The NEON right-shifts make life more interesting by using a left-shift
instruction with a negative offset. This means that the amount has to be
negated. Ideally you'd want to do this at expand time, but the delayed
NEON/core decision makes this impossible, so I've chosen to expand this
in the post-reload split pass. Unfortunately, NEON does not provide a
suitable instruction for negating the shift amount, so that ends up
happening in core-registers.

Another complication is that the NEON shift instructions use a 64-bit
register for the shift amount, but they only pay attention to the bottom
8 bits. I did experiment with using a DImode shift amount, but that
didn't work out well; there were unnecessary extends and the
core-registers fall back was less efficient.

Therefore, I've chosen to create a new register class, VFP_LO_REGS_EVEN,
which includes only the 32-bit low-part of the DImode NEON registers so
the shift amount can be loaded into VFP regs without extending them.
This required a new print format 'E' that converts the low-part name to
the full register name the instructions need. Unfortunately, this does
artificially limit the shift amount to the bottom half of the register
set, but hopefully that's not going to be a big problem.

The register allocator is causing me trouble though. The problem is that
the compiler just refused to use the NEON variant in all of my toy
examples. It turns out to be simply that the IRA & reload passes do not
change hard-registers already present in the RTL (function parameters,
return values, etc.) unless there is absolutely no alternative that
works with that register. I'm not sure if there's anything that can be
done about this, or not. I'm not even sure if it isn't the right choice
much of the time, cost wise.


I've now updated the patch to take into account size optimization.

Currently, if optimizing for size the compiler prefers to call the 
libgcc function, rather that do the shift inline.


With my old patch, when NEON is enabled it always used the inline code 
(either in NEON or core-registers) no matter which optimization flags 
were set. This is more-or-less correct if the register allocator chooses 
to do the operation in NEON, but much less space efficient otherwise.


The update simply disables the core-registers fall-back option when 
optimizing for size. Transferring the values to NEON registers and back 
should be roughly the same size as calling a function, so there 
shouldn't be a big loss.


I'm in two minds about the shift-by-constant cases though, since they 
expand to fewer instructions. Any thoughts?


OK for 4.8?

Andrew
2012-02-21  Andrew Stubbs  

	gcc/
	* config/arm/arm.c (arm_print_operand): Add new 'E' format code.
	* config/arm/arm.h (enum reg_class): Add VFP_LO_REGS_EVEN.
	(REG_CLASS_NAMES, REG_CLASS_CONTENTS, IS_VFP_CLASS): Likewise.
	* config/arm/arm.md (ashldi3): Add TARGET_NEON case.
	(ashrdi3, lshrdi3): Likewise.
	* config/arm/constraints.md (T): New register constraint.
	(Pe, P1, Pf, Pg): New constraints.
	* config/arm/neon.md (signed_shift_di3_neon): New pattern.
	(unsigned_shift_di3_neon, ashldi3_neon): New patterns.
	(ashrdi3_neon_imm, ashrdi3_neon_reg): New patterns.
	(ashrdi3_neon, lshrdi3_neon_imm, ashrdi3_neon): New patterns.
	(lshrdi3_neon_imm, lshrdi3_neon_reg, lshrdi3_neon): New patterns.
	* config/arm/predicates.md (int_0_to_63): New predicate.
	(shift_amount_64): New predicate.

---
 gcc/config/arm/arm.c  |   18 +++
 gcc/config/arm/arm.h  |5 +
 gcc/config/arm/arm.md |   33 -
 gcc/config/arm/constraints.md |   30 -
 gcc/config/arm/neon.md|  271 +
 gcc/config/arm/predicates.md  |8 +
 6 files changed, 355 insertions(+), 10 deletions(-)

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 386231a..65ccd91 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -17661,6 +17661,24 @@ arm_print_operand (FILE *stream, rtx x, int code)
   }
   return;
 
+/* Print the VFP/Neon double precision register name that overlaps the
+   given single-precision register.  */
+case 'E':
+  {
+	int mode = GET_MODE (x);
+
+	if (GET_MODE_SIZE (mode) != 4
+	|| GET_CODE (x) != REG
+	|| !IS_VFP_REGNUM (REGNO (x)))
+	  {
+	output_operand_lossage ("invalid operand for code '%c'", code);
+	return;
+	  }
+
+	fprintf (stream, "d%d", (REGNO (x) - FIRST_VFP_REGNUM) >> 1);
+  }
+  return;
+
 /* These two codes print the low/high doubleword register of a Neon quad
register, respectivel

Re: [PATCH] testsuite: Turn -fgnu-tm test into link test

[Jakub Jelinek]

On Tue, Feb 21, 2012 at 04:23:16PM +0100, Andreas Krebbel wrote:
> using the -fgnu-tm option fails for targets not supporting libitm with
> a *link* failure.  So the compile test wasn't sufficient.
> 
> With the attached patch the following failures disappear on s390 and
> s390x:
> 
> FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o 
> link, -flto -fgnu-tm
> UNRESOLVED: gcc.dg/lto/trans-mem-1 
> c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o execute -flto -fgnu-tm
> FAIL: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o 
> link, -flto -fgnu-tm
> UNRESOLVED: gcc.dg/lto/trans-mem-2 
> c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o execute -flto -fgnu-tm
> FAIL: gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o 
> link, -flto -fgnu-tm
> UNRESOLVED: gcc.dg/lto/trans-mem-4 
> c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o execute -flto -fgnu-tm
> XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times optimized 
> "link_error" 0
> 
> Ok for mainline?

Won't that just disable tm testing on all targets?
As noted in bugzilla, libitm.spec is in the libitm tree, so runtime
tm testcases should probably be in libitm like e.g. libgomp has them.

Jakub

Re: [PATCH] testsuite: Turn -fgnu-tm test into link test

[Rainer Orth]

"Andreas Krebbel"  writes:

> Ok for mainline?

No, this is wrong.  How would gcc be able to find the uninstalled libitm.so
and libitm.spec on targets that do support it?

I'm undecided how (and where) best to fix this.  One might either handle
it via something like dg-add-options tm_runtime, or could simply move
the tests to libitm/testsuite/libitm.c (if LTO tests work there).

I've not yet tried either of those solutions, though.

Rainer

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

[PATCH, ARM] Fix for PR52294: Out-of-range branch in Thumb2 code

[Richard Earnshaw]

PR52294 is a case where we generate a cbz instruction that ends up
trying to reach too far.  The reason for this is that we calculate the
size of some instructions as being 2 bytes when in reality they take 4.

The problem in this instance is that a peephole to shorten

lsl reg, reg, reg

into

lsls reg, reg, reg

Failed to observe that the first two registers have to be identical
(unlike lsls reg, reg, #const) or the result will be no shorter than the
original.

Fixed thusly:

PR target/52294
* thumb2.md (thumb2_shiftsi3_short): Split register and 
immediate shifts.  For register shifts tie operands 0 and 1.
(peephole2 for above): Check that register-controlled shifts
have suitably tied operands.

R.diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index ad05feb..39a2138 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -686,6 +686,7 @@
  (match_operand:SI 2 "low_reg_or_int_operand" "")]))]
   "TARGET_THUMB2
&& peep2_regno_dead_p(0, CC_REGNUM)
+   && (CONST_INT_P (operands[2]) || operands[1] == operands[0])
&& ((GET_CODE(operands[3]) != ROTATE && GET_CODE(operands[3]) != ROTATERT)
|| REG_P(operands[2]))"
   [(parallel
@@ -698,10 +699,10 @@
 )
 
 (define_insn "*thumb2_shiftsi3_short"
-  [(set (match_operand:SI   0 "low_register_operand" "=l")
+  [(set (match_operand:SI   0 "low_register_operand" "=l,l")
(match_operator:SI  3 "shift_operator"
-[(match_operand:SI 1 "low_register_operand"  "l")
- (match_operand:SI 2 "low_reg_or_int_operand" "lM")]))
+[(match_operand:SI 1 "low_register_operand"  "0,l")
+ (match_operand:SI 2 "low_reg_or_int_operand" "l,M")]))
(clobber (reg:CC CC_REGNUM))]
   "TARGET_THUMB2 && reload_completed
&& ((GET_CODE(operands[3]) != ROTATE && GET_CODE(operands[3]) != ROTATERT)

Re: [PATCH] testsuite: Turn -fgnu-tm test into link test

[Andreas Krebbel]

On 02/21/2012 04:27 PM, Jakub Jelinek wrote:
> On Tue, Feb 21, 2012 at 04:23:16PM +0100, Andreas Krebbel wrote:
>> using the -fgnu-tm option fails for targets not supporting libitm with
>> a *link* failure.  So the compile test wasn't sufficient.
>>
>> With the attached patch the following failures disappear on s390 and
>> s390x:
>>
>> FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o 
>> link, -flto -fgnu-tm
>> UNRESOLVED: gcc.dg/lto/trans-mem-1 
>> c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o execute -flto -fgnu-tm
>> FAIL: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o 
>> link, -flto -fgnu-tm
>> UNRESOLVED: gcc.dg/lto/trans-mem-2 
>> c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o execute -flto -fgnu-tm
>> FAIL: gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o 
>> link, -flto -fgnu-tm
>> UNRESOLVED: gcc.dg/lto/trans-mem-4 
>> c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o execute -flto -fgnu-tm
>> XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times optimized 
>> "link_error" 0
>>
>> Ok for mainline?
> 
> Won't that just disable tm testing on all targets?
> As noted in bugzilla, libitm.spec is in the libitm tree, so runtime
> tm testcases should probably be in libitm like e.g. libgomp has them.

Ok I see. I wasn't aware that the files would be missing even on targets 
supporting libtim.

Thanks for the explanation.

-Andreas-

[Patch, Fortran] PR 52325 - Better diagnostic for %component

[Tobias Burnus]

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

Tobias
2012-02-21  Tobias Burnus  

	PR fortran/52325
	* primary.c (gfc_match_varspec): Add diagnostic for % with
	nonderived types.

2012-02-21  Tobias Burnus  

	PR fortran/52325
	* gfortran.dg/derived_comp_array_ref_8.f90: New.
	* gfortran.dg/nullify_2.f90: Update dg-error.
	* gfortran.dg/nullify_4.f90: Ditto.
	* gfortran.dg/pointer_init_6.f90: Ditto.

Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c	(revision 184439)
+++ gcc/fortran/primary.c	(working copy)
@@ -1910,6 +1910,19 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
   && gfc_get_default_type (sym->name, sym->ns)->type == BT_DERIVED)
 gfc_set_default_type (sym, 0, sym->ns);
 
+  if (sym->ts.type == BT_UNKNOWN && gfc_match_char ('%') == MATCH_YES)
+{
+  gfc_error ("Symbol '%s' at %C has no IMPLICIT type", sym->name);
+  return MATCH_ERROR;
+}
+  else if ((sym->ts.type != BT_DERIVED && sym->ts.type != BT_CLASS)
+	   && gfc_match_char ('%') == MATCH_YES)
+{
+  gfc_error ("Unexpected '%%' for nonderived-type variable '%s' at %C",
+		 sym->name)
+  return MATCH_ERROR;
+}
+
   if ((sym->ts.type != BT_DERIVED && sym->ts.type != BT_CLASS)
   || gfc_match_char ('%') != MATCH_YES)
 goto check_substring;
Index: gcc/testsuite/gfortran.dg/derived_comp_array_ref_8.f90
===
--- gcc/testsuite/gfortran.dg/derived_comp_array_ref_8.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/derived_comp_array_ref_8.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+!
+! PR fortran/52325
+!
+real :: f
+cc%a = 5 ! { dg-error "Symbol 'cc' at .1. has no IMPLICIT type" }
+f%a = 5  ! { dg-error "Unexpected '%' for nonderived-type variable 'f' at" }
+end
Index: gcc/testsuite/gfortran.dg/nullify_2.f90
===
--- gcc/testsuite/gfortran.dg/nullify_2.f90	(revision 184439)
+++ gcc/testsuite/gfortran.dg/nullify_2.f90	(working copy)
@@ -3,5 +3,5 @@
 program i
implicit none
TYPE (a) t1 ! { dg-error "is being used before" }
-   nullify(t1%x)   ! { dg-error "error in NULLIFY" }
+   nullify(t1%x)   ! { dg-error "Symbol 't1' at .1. has no IMPLICIT type" }
 end program
Index: gcc/testsuite/gfortran.dg/nullify_4.f90
===
--- gcc/testsuite/gfortran.dg/nullify_4.f90	(revision 184439)
+++ gcc/testsuite/gfortran.dg/nullify_4.f90	(working copy)
@@ -4,5 +4,5 @@
 ! Check error recovery; was crashing before.
 !
 real, pointer :: ptr
-nullify(ptr, mesh%coarser) ! { dg-error "Syntax error in NULLIFY statement" }
+nullify(ptr, mesh%coarser) ! { dg-error "Symbol 'mesh' at .1. has no IMPLICIT type" }
 end
Index: gcc/testsuite/gfortran.dg/pointer_init_6.f90
===
--- gcc/testsuite/gfortran.dg/pointer_init_6.f90	(revision 184439)
+++ gcc/testsuite/gfortran.dg/pointer_init_6.f90	(working copy)
@@ -27,7 +27,7 @@ module m2
  type(t) :: x
  procedure(s), pointer :: pp1 => s
  procedure(s), pointer :: pp2 => pp1! { dg-error "may not be a procedure pointer" }
- procedure(s), pointer :: pp3 => t%ppc  ! { dg-error "Syntax error" }
+ procedure(s), pointer :: pp3 => t%ppc  ! { dg-error "Symbol 't' at .1. has no IMPLICIT type" }
 
 contains
 

RE: [patch] clean up pdp11.md a bit

[Paul_Koning]

By the way, the "compile" subset of the testsuite works for pdp11; it has some 
errors which still need cleanup but a large fraction works.

paul

-Original Message-
From: Steven Bosscher [mailto:stevenb@gmail.com] 
Sent: Tuesday, February 14, 2012 5:09 PM
To: Koning, Paul; GCC Patches
Subject: [patch] clean up pdp11.md a bit

Hello,

Just a few cleanups for things I noticed last weekend.

* Constraints on define_expand are never used, remove them (most other ports do 
not have constraints on define_expands either)
* Some patterns have no name, makes debugging a bit harder
* The divmodhi4 expander has been commented out since Day 1 of egcs.
Explain why.

Tested by building the compiler. For pdp11-elf, which is not a supported target 
according to backends.html, but it's not rejected.
Not sure what the right target is to compile for. In any case, I obviously have 
no PDP-11 to test on. But the patch has no changes that impact code generation 
(the constraints were already ignored).

OK for trunk?

Ciao!
Steven

[RFA/ARM] target/51534 Fix unsigned vector comparisons

[Matthew Gretton-Dann]

The attached patch fixes instruction generation for unsigned vector
comparisons against a known-zero vector.

ARM's Neon extensions only allow unsigned equality comparison against
unsigned zero, not less than or greater than comparisons.

This patch fixes code generation - there are further changes that could be
made which would improve the code generated which will come in a
separate patch.

This issue does not affect the auto-vectorizer.

OK?

Matt

gcc/ChangeLog:

2012-02-21  Matthew Gretton-Dann  

PR target/51534
* config/arm/arm.c (neon_builtin_data): Add entries for vcgeu
and vcgtu.
* config/arm/arm_neon.h: Regenerate.
* config/arm/neon.md (unspec): Add UNSPEC_VCGEU, and UNSPEC_VCGTU.
(neon_vcgeu): New insn.
(neon_vcgtu): Likewise.
* config/arm/neon.ml (s_8_32, u_8_32): New lists.
(ops): Unsigned comparison intrinsics call a different
builtin.

gcc/testsuite/ChangeLog:

2012-02-21  Matthew Gretton-Dann  

PR target/51534
gcc.target/arm/neon/pr51534.c: New testcase.

-- 
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 7f0dc6b..4a173ac 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -19108,7 +19108,9 @@ static neon_builtin_datum neon_builtin_data[] =
   VAR3 (BINOP, vsubhn, v8hi, v4si, v2di),
   VAR8 (BINOP, vceq, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
   VAR8 (BINOP, vcge, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
+  VAR6 (BINOP, vcgeu, v8qi, v4hi, v2si, v16qi, v8hi, v4si),
   VAR8 (BINOP, vcgt, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
+  VAR6 (BINOP, vcgtu, v8qi, v4hi, v2si, v16qi, v8hi, v4si),
   VAR2 (BINOP, vcage, v2sf, v4sf),
   VAR2 (BINOP, vcagt, v2sf, v4sf),
   VAR6 (BINOP, vtst, v8qi, v4hi, v2si, v16qi, v8hi, v4si),
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 9cba0a9..0567895 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -1893,19 +1893,19 @@ vcge_f32 (float32x2_t __a, float32x2_t __b)
 __extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
 vcge_u8 (uint8x8_t __a, uint8x8_t __b)
 {
-  return (uint8x8_t)__builtin_neon_vcgev8qi ((int8x8_t) __a, (int8x8_t) __b, 
0);
+  return (uint8x8_t)__builtin_neon_vcgeuv8qi ((int8x8_t) __a, (int8x8_t) __b, 
0);
 }
 
 __extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
 vcge_u16 (uint16x4_t __a, uint16x4_t __b)
 {
-  return (uint16x4_t)__builtin_neon_vcgev4hi ((int16x4_t) __a, (int16x4_t) 
__b, 0);
+  return (uint16x4_t)__builtin_neon_vcgeuv4hi ((int16x4_t) __a, (int16x4_t) 
__b, 0);
 }
 
 __extension__ static __inline uint32x2_t __attribute__ ((__always_inline__))
 vcge_u32 (uint32x2_t __a, uint32x2_t __b)
 {
-  return (uint32x2_t)__builtin_neon_vcgev2si ((int32x2_t) __a, (int32x2_t) 
__b, 0);
+  return (uint32x2_t)__builtin_neon_vcgeuv2si ((int32x2_t) __a, (int32x2_t) 
__b, 0);
 }
 
 __extension__ static __inline uint8x16_t __attribute__ ((__always_inline__))
@@ -1935,19 +1935,19 @@ vcgeq_f32 (float32x4_t __a, float32x4_t __b)
 __extension__ static __inline uint8x16_t __attribute__ ((__always_inline__))
 vcgeq_u8 (uint8x16_t __a, uint8x16_t __b)
 {
-  return (uint8x16_t)__builtin_neon_vcgev16qi ((int8x16_t) __a, (int8x16_t) 
__b, 0);
+  return (uint8x16_t)__builtin_neon_vcgeuv16qi ((int8x16_t) __a, (int8x16_t) 
__b, 0);
 }
 
 __extension__ static __inline uint16x8_t __attribute__ ((__always_inline__))
 vcgeq_u16 (uint16x8_t __a, uint16x8_t __b)
 {
-  return (uint16x8_t)__builtin_neon_vcgev8hi ((int16x8_t) __a, (int16x8_t) 
__b, 0);
+  return (uint16x8_t)__builtin_neon_vcgeuv8hi ((int16x8_t) __a, (int16x8_t) 
__b, 0);
 }
 
 __extension__ static __inline uint32x4_t __attribute__ ((__always_inline__))
 vcgeq_u32 (uint32x4_t __a, uint32x4_t __b)
 {
-  return (uint32x4_t)__builtin_neon_vcgev4si ((int32x4_t) __a, (int32x4_t) 
__b, 0);
+  return (uint32x4_t)__builtin_neon_vcgeuv4si ((int32x4_t) __a, (int32x4_t) 
__b, 0);
 }
 
 __extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
@@ -1977,19 +1977,19 @@ vcle_f32 (float32x2_t __a, float32x2_t __b)
 __extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
 vcle_u8 (uint8x8_t __a, uint8x8_t __b)
 {
-  return (uint8x8_t)__builtin_neon_vcgev8qi ((int8x8_t) __b, (int8x8_t) __a, 
0);
+  return (uint8x8_t)__builtin_neon_vcgeuv8qi ((int8x8_t) __b, (int8x8_t) __a, 
0);
 }
 
 __extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
 vcle_u16 (uint16x4_t __a, uint16x4_t __b)
 {
-  return (uint16x4_t)__builtin_neon_vcgev4hi ((int16x4_t) __b, (int16x4_t) 
__a, 0);
+  return (uint16x4_t)__builtin_neon_vcgeuv4hi ((int16x4_t) __b, (int16x4_t) 
__a, 0);
 }
 
 __extension__ static __inline uint32x2_t __attribute__ ((__always_inline__))
 vcle_u32 (uint32x2_t __a, uint32x2_t __b)
 {
-  return (uint32x2_t)__builtin_neon_vcgev2si ((int32x2_t) __b, (int32x2_t) 
_

Re: [Patch,AVR]: Tweak neghi2, add some peephole

[Denis Chertykov]

2012/2/16 Georg-Johann Lay :
> neghi2's "r,0" alternative reads
>
> com %B0
> neg %A0
> sbc %B0,__zero_reg__
> inc %B0
>
> The INC commutates with the NEG+SBC and can be moved 2 instructions up:
>
> com %B0
> inc %B0
> neg %A0
> sbc %B0,__zero_reg__
>
> COM+INC can be fused to NEG:
>
> neg %B0
> neg %A0
> sbc %B0,__zero_reg__
>
> with the additional benefit that cc0 is always set_czn now.
>
> The *dec-and-branchhi!=-1 text peephole just coverd vanilla addhi3 without
> clobber register.  As addhi3 now has a clobber added in many cases,
> that peephole don't match them any more.  The patch adds peephole alternatives
> for clobber variants of addhi3.
>
> Passed without regressions.
>
> Ok to apply?
>
> Johann
>
>        * config/avr/avr.md (neghi2): Remove "!d,0" alternative. Tweak "r,0".
>        (*dec-and-branchhi!=-1.d.clobber): New text peephole.
>        (*dec-and-branchhi!=-1.l.clobber): New text peephole.
>

Approved.

Denis.

[RFA/ARM] Revert r183011: Cortex-A15 branch costs

[Matthew Gretton-Dann]

The attached patch reverts revision 183011, which changed the branch
cost heuristics for Cortex-A15.

This is because further benchmarking shows that there are significant
regressions on some benchmarks which outweigh other performance gains.

OK?

Thanks,

Matt

gcc/ChangeLog:

2012-02-21  Matthew Gretton-Dann  

Revert r183011
* config/arm/arm-cores.def (cortex-a15): Use generic Cortex tuning
parameters.
* config/arm/arm.c (arm_cortex_a15_tune): Remove.
-- 
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
index b0bd172..80609e0 100644
--- a/gcc/config/arm/arm-cores.def
+++ b/gcc/config/arm/arm-cores.def
@@ -129,7 +129,7 @@ ARM_CORE("cortex-a5", cortexa5, 7A, 
 FL_LDSCHED, cortex_a5)
 ARM_CORE("cortex-a7",cortexa7, 7A,  
FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex)
 ARM_CORE("cortex-a8",cortexa8, 7A,  
FL_LDSCHED, cortex)
 ARM_CORE("cortex-a9",cortexa9, 7A,  
FL_LDSCHED, cortex_a9)
-ARM_CORE("cortex-a15",   cortexa15,7A,  
FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex_a15)
+ARM_CORE("cortex-a15",   cortexa15,7A,  
FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex)
 ARM_CORE("cortex-r4",cortexr4, 7R,  
FL_LDSCHED, cortex)
 ARM_CORE("cortex-r4f",   cortexr4f,7R,  
FL_LDSCHED, cortex)
 ARM_CORE("cortex-r5",cortexr5, 7R,  
FL_LDSCHED | FL_ARM_DIV, cortex)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 4a94145..3ef3d19 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -968,17 +968,6 @@ const struct tune_params arm_cortex_a9_tune =
   arm_default_branch_cost
 };
 
-const struct tune_params arm_cortex_a15_tune =
-{
-  arm_9e_rtx_costs,
-  NULL,
-  1,   /* Constant limit.  */
-  1,   /* Max cond insns.  */
-  ARM_PREFETCH_NOT_BENEFICIAL, /* TODO: Calculate correct 
values.  */
-  false,   /* Prefer constant pool.  */
-  arm_cortex_a5_branch_cost
-};
-
 const struct tune_params arm_fa726te_tune =
 {
   arm_9e_rtx_costs,

Re: [Patch,AVR]: Fix missing prototype warning for ACCUMULATE_OUTGOING_ARGS

[Denis Chertykov]

2012/2/15 Georg-Johann Lay :
> Some parts outside the backend use ACCUMULATE_OUTGOING_ARGS without including
> tm_p.h which lead to a build warning because avr.h does
>
> #define ACCUMULATE_OUTGOING_ARGS avr_accumulate_outgoing_args()
>
> This patcs moved the prototype from avr-protos.h to avr.h:
>
>        * config/avr/avr-protos.h (avr_accumulate_outgoing_args): Move
>        prototype from here to...
>        * config/avr/avr.h: ...here.
>
> Ok for trunk?
>

Approved.

Denis.

Re: [PATCH, PR 51782] Derive rtx address space from base object

[Georg-Johann Lay]

Martin Jambor wrote:
> Hi,
> 
> PR 51782 showed that COMPONENT_REFs created by SRA got expanded with a
> wrong address space because the address space was not specified in the
> type of the whole tree.  This is however inconsistent with how we
> encode address spaces in MEM_REFs where they are supposed to be stored
> in the type of its address operand (as opposed to the type of the
> reference).  Therefore the following patch changes the expansion to
> always look at the base address and look through MEM_REFs if
> necessary.
> 
> It fixes the issue for me on a cross compiler, a bootstrap and
> testsuite run on x86_64-linux showed only regressions described in PR
> 52297 so I consider it successful.  My understanding is that Richi
> approved it in bugzilla.  Georg-Johann Lay said he would test it on HW
> or simulator that actually uses address spaces and he has also already
> committed a testcase for this bug.  Therefore I intend to commit the
> patch if his tests pass too.
> 
> Thanks,
> 
> Martin

The avr test suite has passed now, okay from that side.

Johann

Re: [Patch,AVR]: Fix PR50063 GCC does not support FP = SP

[Georg-Johann Lay]

Jakub Jelinek wrote:
> On Tue, Feb 21, 2012 at 12:38:48PM +0100, Georg-Johann Lay wrote:
>> However, if all insns that are involved in SP/FP manipulation get the
>> RTX_FRAME_RELATED_P, almost every test case that has -g crashes with this
>> dwarf-ICE.
> 
> My suggestion actually wasn't to use unspec for reading from sp, but instead
> to use it on the insn which sets sp from hfp, i.e. instead of that
>(insn 47 46 48 2 (set (reg/f:HI 32 __SP_L__)
>(reg/f:HI 28 r28)) pr50063.c:9 -1
> (nil))
> in the testcase use:
>(insn 47 46 48 2 (set (reg/f:HI 32 __SP_L__)
>(unspec [(reg/f:HI 28 r28)] UNSPEC_SET_SP_FROM_FP)) pr50063.c:9 -1
> (nil))
> or so.  You should be able to use REG_FRAME_RELATED_EXPR with the old set
> if needed (though, the insn strangely isn't RTX_FRAME_RELATED_P, preexisting
> bug?).  Just to hide from cselib/alias code that you are setting hfp from
> sp, then adjusting hfp and then setting sp back from it.  With the unspec
> it will just not know what value sp has there.
> 
>   Jakub


Thanks, it works now :-)) Here is the patch for review now.

It passes the testsuite and fixed several execution fails because of
assumptions in DSE.  Besides the normal testsuite run, it passes also a run
with -maccumulate-args.

Ok for trunk?

Johann

PR rtl-optimization/50063
* config/avr/avr.md (movhi_sp_r): Handle -1 (unknown IRQ state)
and 2 (8-bit SP) in operand 2.
* config/avr/avr.c (avr_prologue_setup_frame): Adjust prologue
setup to use movhi_sp_r instead of vanilla move to write SP.
Adjust REG_CFA notes to superseed unspec.
(expand_epilogue): Adjust epilogue setup to use read_sp instead
of vanilla move.
As function body might contain CLI or SEI: Use irq_state 0 (IRQ
known to be off) only with TARGET_NO_INTERRUPTS. Never use
irq_state 1 (IRQ known to be on) here.
Index: config/avr/avr.md
===
--- config/avr/avr.md	(revision 184386)
+++ config/avr/avr.md	(working copy)
@@ -583,23 +583,26 @@ (define_peephole2
 
 ;; Move register $1 to the Stack Pointer register SP.
 ;; This insn is emit during function prologue/epilogue generation.
-;;$2 = 0: We know that IRQs are off
-;;$2 = 1: We know that IRQs are on
-;; Remaining cases when the state of the I-Flag is unknown are
-;; handled by generic movhi insn.
+;;$2 =  0: We know that IRQs are off
+;;$2 =  1: We know that IRQs are on
+;;$2 =  2: SP has 8 bits only, IRQ state does not matter
+;;$2 = -1: We don't know anything about IRQ on/off
+;; Always write SP via unspec, see PR50063
 
 (define_insn "movhi_sp_r"
-  [(set (match_operand:HI 0 "stack_register_operand""=q,q,q")
-(unspec_volatile:HI [(match_operand:HI 1 "register_operand"  "r,r,r")
- (match_operand:HI 2 "const_int_operand" "L,P,LP")]
+  [(set (match_operand:HI 0 "stack_register_operand""=q,q,q,q,q")
+(unspec_volatile:HI [(match_operand:HI 1 "register_operand"  "r,r,r,r,r")
+ (match_operand:HI 2 "const_int_operand" "L,P,N,K,LPN")]
 UNSPECV_WRITE_SP))]
-  "!AVR_HAVE_8BIT_SP"
+  ""
   "@
-	out __SP_H__,%B1\;out __SP_L__,%A1
-	cli\;out __SP_H__,%B1\;sei\;out __SP_L__,%A1
-	out __SP_L__,%A1\;out __SP_H__,%B1"
-  [(set_attr "length" "2,4,2")
-   (set_attr "isa" "no_xmega,no_xmega,xmega")
+	out %B0,%B1\;out %A0,%A1
+	cli\;out %B0,%B1\;sei\;out %A0,%A1
+	in __tmp_reg__,__SREG__\;cli\;out %B0,%B1\;out __SREG__,__tmp_reg__\;out %A0,%A1
+	out %A0,%A1
+	out %A0,%A1\;out %B0,%B1"
+  [(set_attr "length" "2,4,5,1,2")
+   (set_attr "isa" "no_xmega,no_xmega,no_xmega,*,xmega")
(set_attr "cc" "none")])
 
 (define_peephole2
Index: config/avr/avr.c
===
--- config/avr/avr.c	(revision 184386)
+++ config/avr/avr.c	(working copy)
@@ -1062,8 +1062,8 @@ avr_prologue_setup_frame (HOST_WIDE_INT
   !frame_pointer_needed can only occur if the function is not a
   leaf function and thus X has already been saved.  */
   
+  int irq_state = -1;
   rtx fp_plus_insns, fp, my_fp;
-  rtx sp_minus_size = plus_constant (stack_pointer_rtx, -size);
 
   gcc_assert (frame_pointer_needed
   || !isr_p
@@ -1076,7 +1076,7 @@ avr_prologue_setup_frame (HOST_WIDE_INT
   if (AVR_HAVE_8BIT_SP)
 {
   /* The high byte (r29) does not change:
- Prefer SUBI (1 cycle) over ABIW (2 cycles, same size).  */
+ Prefer SUBI (1 cycle) over SBIW (2 cycles, same size).  */
 
   my_fp = all_regs_rtx[FRAME_POINTER_REGNUM];
 }
@@ -1092,43 +1092,50 @@ avr_prologue_setup_frame (HOST_WIDE_INT
  the frame pointer subtraction is done.  */
   
   insn = emit_m

Re: [PATCH] MIPS16 TLS support for GCC

[Maciej W. Rozycki]

On Sun, 19 Feb 2012, Richard Sandiford wrote:

> > The i386 target does it all the time for its __x86.get_pc_thunk.?x thingys.
> 
> Thanks for the pointer.  Here's a patch that takes the same approach.
> There's no problem relying on comdat groups here, since MIPS16 TLS
> requires 2.22 gas and ld anyway.
> 
> Tested on mips64-linux-gnu, mips-sde-elf and various other mips*-elf targets.
> Applied.

 Excellent!  Thanks for working on this and insisting on the most 
reasonable solution.

  Maciej

Re: [RFA/ARM] Revert r183011: Cortex-A15 branch costs

[Richard Earnshaw]

On 21/02/12 16:28, Matthew Gretton-Dann wrote:
> The attached patch reverts revision 183011, which changed the branch
> cost heuristics for Cortex-A15.
> 
> This is because further benchmarking shows that there are significant
> regressions on some benchmarks which outweigh other performance gains.
> 
> OK?
> 

OK.

We really need to sort out some of the f/e cost calculations to get this
right... :-(

R.

> Thanks,
> 
> Matt
> 
> gcc/ChangeLog:
> 
> 2012-02-21  Matthew Gretton-Dann  
> 
>   Revert r183011
>   * config/arm/arm-cores.def (cortex-a15): Use generic Cortex tuning
>   parameters.
>   * config/arm/arm.c (arm_cortex_a15_tune): Remove.
> 
> 
> 1-RFA-ARM-Revert-r183011-Cortex-A15-branch-costs.txt
> 
> 
> diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
> index b0bd172..80609e0 100644
> --- a/gcc/config/arm/arm-cores.def
> +++ b/gcc/config/arm/arm-cores.def
> @@ -129,7 +129,7 @@ ARM_CORE("cortex-a5",   cortexa5, 7A, 
>  FL_LDSCHED, cortex_a5)
>  ARM_CORE("cortex-a7",  cortexa7, 7A, 
>  FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex)
>  ARM_CORE("cortex-a8",  cortexa8, 7A, 
>  FL_LDSCHED, cortex)
>  ARM_CORE("cortex-a9",  cortexa9, 7A, 
>  FL_LDSCHED, cortex_a9)
> -ARM_CORE("cortex-a15", cortexa15,7A, 
>  FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex_a15)
> +ARM_CORE("cortex-a15", cortexa15,7A, 
>  FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex)
>  ARM_CORE("cortex-r4",  cortexr4, 7R, 
>  FL_LDSCHED, cortex)
>  ARM_CORE("cortex-r4f", cortexr4f,7R, 
>  FL_LDSCHED, cortex)
>  ARM_CORE("cortex-r5",  cortexr5, 7R, 
>  FL_LDSCHED | FL_ARM_DIV, cortex)
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 4a94145..3ef3d19 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -968,17 +968,6 @@ const struct tune_params arm_cortex_a9_tune =
>arm_default_branch_cost
>  };
>  
> -const struct tune_params arm_cortex_a15_tune =
> -{
> -  arm_9e_rtx_costs,
> -  NULL,
> -  1, /* Constant limit.  */
> -  1, /* Max cond insns.  */
> -  ARM_PREFETCH_NOT_BENEFICIAL,   /* TODO: Calculate 
> correct values.  */
> -  false, /* Prefer constant pool.  */
> -  arm_cortex_a5_branch_cost
> -};
> -
>  const struct tune_params arm_fa726te_tune =
>  {
>arm_9e_rtx_costs,

Re: [Patch,AVR]: Fix PR50063 GCC does not support FP = SP

[Richard Henderson]

On 02/21/12 09:08, Georg-Johann Lay wrote:
>   PR rtl-optimization/50063
>   * config/avr/avr.md (movhi_sp_r): Handle -1 (unknown IRQ state)
>   and 2 (8-bit SP) in operand 2.
>   * config/avr/avr.c (avr_prologue_setup_frame): Adjust prologue
>   setup to use movhi_sp_r instead of vanilla move to write SP.
>   Adjust REG_CFA notes to superseed unspec.
>   (expand_epilogue): Adjust epilogue setup to use read_sp instead
>   of vanilla move.
>   As function body might contain CLI or SEI: Use irq_state 0 (IRQ
>   known to be off) only with TARGET_NO_INTERRUPTS. Never use
>   irq_state 1 (IRQ known to be on) here.

The CFA bits in avr_prologue_setup_frame look good.
I'll let Denis or Eric review the movhi_sp_r change.


r~

Re: [google/gcc-4_6_2-mobile] PATCH: PR other/46770: Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[H.J. Lu]

On Mon, Feb 20, 2012 at 11:31 PM, Jing Yu  wrote:
> Hi H.J.,
>
> I think the patch itself is not enough.
> I compared "AC_DEFUN([gcc_AC_INITFINI_ARRAY]" part (in acinclude.m4)
> of gcc trunk and google/gcc-4_6_2-mobile, and found how
> enable_initfini_array is
> configured is different.
>
> The patch breaks some of our tests. enable_initfini_array should be
> disabled for cross compile by default. But it is not true in our
> branch. Could you please point us all related patches?
>

I missed this backport. There are some additional changes needed for
non-Linux systems:

http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg00978.html
http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg01132.html
http://gcc.gnu.org/ml/gcc-cvs/2012-01/msg00544.html



-- 
H.J.
commit e3986f56287eccd6249cd08b7b27006d8fba5ecf
Author: hjl 
Date:   Sat Jun 18 14:48:14 2011 +

Properly check if .init_array can be used with .ctors on targets.

2011-06-18  H.J. Lu  

PR other/49325
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if
.init_array can be used with .ctors on targets.
* configure: Regenerated.

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

Conflicts:

gcc/ChangeLog
gcc/configure

2012-02-21  H.J. Lu  

Backport from mainline
PR other/49325
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if
.init_array can be used with .ctors on targets.
* configure: Regenerated.

diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
index 3eec559..ff38682 100644
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -375,13 +375,115 @@ AC_DEFUN([gcc_AC_INITFINI_ARRAY],
[], [
 AC_CACHE_CHECK(for .preinit_array/.init_array/.fini_array support,
 gcc_cv_initfini_array, [dnl
-  AC_RUN_IFELSE([AC_LANG_SOURCE([
+  if test "x${build}" = "x${target}" && test "x${build}" = "x${host}"; then
+AC_RUN_IFELSE([AC_LANG_SOURCE([
+#ifdef __ia64__
+/* We turn on .preinit_array/.init_array/.fini_array support for ia64
+   if it can be used.  */
 static int x = -1;
 int main (void) { return x; }
 int foo (void) { x = 0; }
-int (*fp) (void) __attribute__ ((section (".init_array"))) = foo;])],
+int (*fp) (void) __attribute__ ((section (".init_array"))) = foo;
+#else
+extern void abort ();
+static int count;
+
+static void
+init1005 ()
+{
+  if (count != 0)
+abort ();
+  count = 1005;
+}
+void (*const init_array1005[]) ()
+  __attribute__ ((section (".init_array.01005"), aligned (sizeof (void *
+  = { init1005 };
+static void
+fini1005 ()
+{
+  if (count != 1005)
+abort ();
+}
+void (*const fini_array1005[]) ()
+  __attribute__ ((section (".fini_array.01005"), aligned (sizeof (void *
+  = { fini1005 };
+
+static void
+ctor1007 ()
+{
+  if (count != 1005)
+abort ();
+  count = 1007;
+}
+void (*const ctors1007[]) ()
+  __attribute__ ((section (".ctors.64528"), aligned (sizeof (void *
+  = { ctor1007 };
+static void
+dtor1007 ()
+{
+  if (count != 1007)
+abort ();
+  count = 1005;
+}
+void (*const dtors1007[]) ()
+  __attribute__ ((section (".dtors.64528"), aligned (sizeof (void *
+  = { dtor1007 };
+
+static void
+init65530 ()
+{
+  if (count != 1007)
+abort ();
+  count = 65530;
+}
+void (*const init_array65530[]) ()
+  __attribute__ ((section (".init_array.65530"), aligned (sizeof (void *
+  = { init65530 };
+static void
+fini65530 ()
+{
+  if (count != 65530)
+abort ();
+  count = 1007;
+}
+void (*const fini_array65530[]) ()
+  __attribute__ ((section (".fini_array.65530"), aligned (sizeof (void *
+  = { fini65530 };
+
+static void
+ctor65535 ()
+{
+  if (count != 65530)
+abort ();
+  count = 65535;
+}
+void (*const ctors65535[]) ()
+  __attribute__ ((section (".ctors"), aligned (sizeof (void *
+  = { ctor65535 };
+static void
+dtor65535 ()
+{
+  if (count != 65535)
+abort ();
+  count = 65530;
+}
+void (*const dtors65535[]) ()
+  __attribute__ ((section (".dtors"), aligned (sizeof (void *
+  = { dtor65535 };
+
+int
+main ()
+{
+  return 0;
+}
+#endif
+])],
 [gcc_cv_initfini_array=yes], [gcc_cv_initfini_array=no],
-[gcc_cv_initfini_array=no])])
+[gcc_cv_initfini_array=no])
+   else
+ AC_MSG_CHECKING(cross compile... guessing)
+ gcc_cv_initfini_array=no
+   fi])
   enable_initfini_array=$gcc_cv_initfini_array
 ])
 if test $enable_initfini_array = yes; then
diff --git a/gcc/configure b/gcc/configure
index 1438b94..329d3e0 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -4861,7 +4861,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $acx_cv_cc_gcc_supports_ada" 
>&5
 $as_echo "$acx_cv_cc_gcc_supports_ada" >&6; }
 
-if test x$GNATBIND != xno && test x$GNATMAKE != xno && test 
x$acx_cv_cc_gcc_supports_ada != xno; then
+if test "x$GNATBIND" != xno && test "x$GNATMAKE" != xno && test 
x$acx_cv_cc_gcc_supports_ada != xno; then
   have_gnat=yes
 else
   have_gnat=no
@@ -1050

[ARM, patch, testsuite] Enable vect_condition tests for ARM/NEON

[Ulrich Weigand]

Hello,

I just noticed that check_effective_target_vect_condition returns false
for ARM/NEON, even though the platforms in fact supports vectorized
conditional expressions.  This causes a number of tests to be skipped
unnecessarily.

Fixed by the following patch.   Tested on arm-linux-gnueabi with no
regressions, adds about 130 PASSes.

OK for mainline?

Bye,
Ulrich


testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_vect_condition):
Return true for NEON.


Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 184398)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -3430,7 +3430,8 @@
 || [istarget ia64-*-*]
 || [istarget i?86-*-*]
 || [istarget spu-*-*]
-|| [istarget x86_64-*-*] } {
+|| [istarget x86_64-*-*]
+|| ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) } 
{
   set et_vect_cond_saved 1
}
 }
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

[lra] patch to fix a bootstrap failure on SPARC64

[Vladimir Makarov]

The SPARC bootstrap started to fail after recent addition of live range 
splitting and trunk merge. The following patch fixes a crash of GCC on 
SPARC64 bootstrap.  Unfortunately, it is still not enough to fix the 
bootstrap failure but I am working on it.


The patch was successfully bootstrapped on x86/x86-64.

Committed as rev. 18.

2012-02-21  Vladimir Makarov 

* lra-constraints.c (inherit_in_ebb): Put split save before jump
using the pseudo.

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 184315)
+++ lra-constraints.c   (working copy)
@@ -4407,8 +4407,11 @@ inherit_in_ebb (rtx head, rtx tail)
  }
else if (reg_renumber[src_regno] >= 0)
  {
+   bool before_p;
rtx use_insn = curr_insn;
 
+   before_p = (JUMP_P (curr_insn)
+   || (CALL_P (curr_insn) && reg->type == OP_IN));
if (usage_insns[src_regno].check == curr_usage_insns_check
&& (next_usage_insns
= usage_insns[src_regno].insns) != NULL_RTX
@@ -4422,8 +4425,7 @@ inherit_in_ebb (rtx head, rtx tail)
&& need_for_split_p (potential_reload_hard_regs,
 src_regno)
&& NONDEBUG_INSN_P (curr_insn)
-   && split_pseudo (CALL_P (curr_insn) && reg->type == 
OP_IN,
-src_regno, curr_insn,
+   && split_pseudo (before_p, src_regno, curr_insn,
 next_usage_insns))
  {
if (reg->subreg_p)
@@ -4431,7 +4433,7 @@ inherit_in_ebb (rtx head, rtx tail)
change_p = true;
/* Invalidate.  */
usage_insns[src_regno].check = 0;
-   if (CALL_P (curr_insn) && reg->type == OP_IN)
+   if (before_p)
  use_insn = PREV_INSN (curr_insn);
  }
if (NONDEBUG_INSN_P (curr_insn))

Re: [Patch,AVR]: Fix PR50063 GCC does not support FP = SP

[Denis Chertykov]

2012/2/21 Richard Henderson :
> On 02/21/12 09:08, Georg-Johann Lay wrote:
>>       PR rtl-optimization/50063
>>       * config/avr/avr.md (movhi_sp_r): Handle -1 (unknown IRQ state)
>>       and 2 (8-bit SP) in operand 2.
>>       * config/avr/avr.c (avr_prologue_setup_frame): Adjust prologue
>>       setup to use movhi_sp_r instead of vanilla move to write SP.
>>       Adjust REG_CFA notes to superseed unspec.
>>       (expand_epilogue): Adjust epilogue setup to use read_sp instead
>>       of vanilla move.
>>       As function body might contain CLI or SEI: Use irq_state 0 (IRQ
>>       known to be off) only with TARGET_NO_INTERRUPTS. Never use
>>       irq_state 1 (IRQ known to be on) here.
>
> The CFA bits in avr_prologue_setup_frame look good.
> I'll let Denis or Eric review the movhi_sp_r change.
>

Approved.

Denis.

Re[2]: Implementation of swi attribute for ARM

[Barracuda]

1) No, I don't. I think I should read FAQ about this then work will be 
completed =) I'm not interested in "copyrighting" this, just want to share it 
with other people.
2) Probably most hard part for me, but I'll try to do this.
I've never used testsuites before, but now it's time to begin.
3) What type of documentation I must provide? Brief annotation (as for other 
attributes)? Yes, I've just use standart calling convention - first 4 args 
resides in r0-r3, others in stack.
4,5,6,7,8,10 - thanks for help, I made some corrections and improvements - 
wrote comments, tidy up the style, add more range and null-pointer checks. 
Also, as you suggested, in addition to "svc" I've implemented "smc" attribute 
and dummy "hvc" attribute - can't find documentation for hvc, I've just noted 
it's Hypervisor Call. Then code will be completed, I'll made patch for trunk, 
for now I can't checkout it, sorry.
And, of course, thanks for reply

Re: [ARM, patch, testsuite] Enable vect_condition tests for ARM/NEON

[Mike Stump]

On Feb 21, 2012, at 10:26 AM, Ulrich Weigand wrote:
> I just noticed that check_effective_target_vect_condition returns false
> for ARM/NEON, even though the platforms in fact supports vectorized
> conditional expressions.  This causes a number of tests to be skipped
> unnecessarily.
> 
> Fixed by the following patch.   Tested on arm-linux-gnueabi with no
> regressions, adds about 130 PASSes.
> 
> OK for mainline?

Ok.  I'm sure someone will scream soon if it is a bad idea.  :-)

Re: IRA: Fix WORDS_BIG_ENDIAN usage

[Vladimir Makarov]

On 02/20/2012 04:10 PM, Bernd Schmidt wrote:

For C6X, I added a patch to separate out a REG_WORDS_BIG_ENDIAN macro
from WORDS_BIG_ENDIAN. Since the patch was originally for 4.5, it missed
a few new instances in IRA where we need to change which macro we use.
The following patch makes big-endian kernels boot.

Bootstrapped and regression tested on i686-linux; can't affect any
target other than C6X. Normally I'd check it in as obvious, but given
that we're in stage4 I'll ask for an OK.


Ok, Bernd.  Thanks.

Re: [wwwdocs] Janitor stuff

[Segher Boessenkool]

This is DJ's baby, let's see whether he has an alternate site?
(Google did not find me an immediate candidate.)


There is http://www.semicon.toshiba.co.jp/docs/catalog/en/mepum05005- 
e_catalog.pdf

("MeP Core (MeP-c4) User’s Manual (Architecture)") but no HTML
page pointing to it, it seems.


Segher


One more: MeP is also gone...

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.217
diff -u -r1.217 readings.html
--- readings.html   17 Feb 2012 18:44:55 -  1.217
+++ readings.html   20 Feb 2012 22:28:29 -
@@ -181,7 +177,6 @@

  MeP
Manufacturer: Toshiba
-   http://www.semicon.toshiba.co.jp/eng/product/ 
micro/selection/mep/">Toshiba

MeP Site
SID includes a MeP simulator.
  

[google/integration] Add missing test failure. (issue5687075)

[Ollie Wild]

The latest Crosstool builds reveal one new test failure (and fix several
others).  This patch adds the missing failure to x86_64-unknown-linux-gnu.xfail.

2012-02-21  Ollie Wild  

* testsuite-management/x86_64-unknown-linux-gnu.xfail: Add
gcc.c-torture/execute/vshuf-v16qi.c failure.

diff --git a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail 
b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
index 2a5e01b..1c7196d 100644
--- a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
+++ b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
@@ -20,6 +20,7 @@ XPASS: gcc.dg/unroll_4.c (test for excess errors)
 FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test
 FAIL: gcc.c-torture/execute/vshuf-v2di.c execution,  -Os
 FAIL: gcc.c-torture/execute/vshuf-v8hi.c execution,  -Os
+FAIL: gcc.c-torture/execute/vshuf-v16qi.c execution,  -Os
 FAIL: gcc.target/i386/pr27827.c scan-assembler fmul[ \t]*%st
 
 # Failures in libitm.

--
This patch is available for review at http://codereview.appspot.com/5687075

Re: [google/integration] Add missing test failure. (issue 5687075)

[aaw]

To be integrated to google/main as well.

http://codereview.appspot.com/5687075/

Re: [google/integration] Add missing test failure. (issue5687075)

[Xinliang David Li]

ok. thanks,

David

On Tue, Feb 21, 2012 at 8:25 PM, Ollie Wild  wrote:
> The latest Crosstool builds reveal one new test failure (and fix several
> others).  This patch adds the missing failure to 
> x86_64-unknown-linux-gnu.xfail.
>
> 2012-02-21  Ollie Wild  
>
>        * testsuite-management/x86_64-unknown-linux-gnu.xfail: Add
>        gcc.c-torture/execute/vshuf-v16qi.c failure.
>
> diff --git a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail 
> b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
> index 2a5e01b..1c7196d 100644
> --- a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
> +++ b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
> @@ -20,6 +20,7 @@ XPASS: gcc.dg/unroll_4.c (test for excess errors)
>  FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test
>  FAIL: gcc.c-torture/execute/vshuf-v2di.c execution,  -Os
>  FAIL: gcc.c-torture/execute/vshuf-v8hi.c execution,  -Os
> +FAIL: gcc.c-torture/execute/vshuf-v16qi.c execution,  -Os
>  FAIL: gcc.target/i386/pr27827.c scan-assembler fmul[ \t]*%st
>
>  # Failures in libitm.
>
> --
> This patch is available for review at http://codereview.appspot.com/5687075