RE: [PATCH, libgcc] Make possible to disable JCR in crtstuff.c

2012-12-18 Thread Joey Ye


> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, December 18, 2012 12:10
> To: Joseph Prostko
> Cc: Joey Ye; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, libgcc] Make possible to disable JCR in crtstuff.c
> 
> On Mon, Dec 17, 2012 at 5:23 PM, Joseph Prostko 
> wrote:
> > On Mon, Dec 17, 2012 at 2:28 PM, H.J. Lu  wrote:
> >> On Mon, Dec 17, 2012 at 1:50 AM, Joey Ye  wrote:
> >
> >>>   * libgcc/Makefile.in: Include TARGET_USE_JCR_SECTION in CFLAGS.
> >>>   * libgcc/configure.ac (use_jcr_section): New variable.
> >>>   * libgcc/configure: Regenerated.
> >>>   * libgcc/crtstuff.c: Check TARGET_USE_JCR_SECTION.
> >>
> >>
> >> I would use JAVA_IS_ENABLED instead of TARGET_USE_JCR_SECTION.
> >> But it is only my personal preference.
> >
> > I believe Joey did that to be consistent with the
> > TARGET_USE_JCR_SECTION macro used in gcc/defaults.h that can be turned
> > on or off for targets that specify it .  If JAVA_IS_ENABLED is used
> > instead, should TARGET_USE_JCR_SECTION be deprecated?
> >
> 
> TARGET_USE_JCR_SECTION determines whether to use the JCR section
> to register Java classes. We don't need to do anything for Java if Java
> isn't enabled. The change can be as simple as
> 
> #ifndef JAVA_IS_ENABLED
> #undef JCR_SECTION_NAME
> #endif
> 
> in crtstuff.c.  Can you give it a try?
Tried and it simply worked. But undef JCR_SECTION_NAME here is very hacking.

> 
> 
> --
> H.J.






Re: [PATCH, wwwdocs] Add a note for performance improvements for MIPS/XLP

2012-12-18 Thread Gerald Pfeifer
On Wed, 19 Dec 2012, Maxim Kuvyrkov wrote:
> The attached patch adds a release note for performance improvements for 
> Broadcom XLP processors (MIPS architecture) that went into GCC 4.8.

The line's a "little" bit long, and I believe it's built-in (not
builtin).

Fine with those changes.

Thanks,
Gerald


Re: Patch to enable unlimited polymorphism to gfortran

2012-12-18 Thread Paul Richard Thomas
Thanks Tobias and Dominique,

I'll make the corrections that you have requested.  I believe that the
2*(GFC_MAX_SYMBOL_LEN+1) has a historic origin - I had not thought
about it until last night, when you pointed it out.

As for the segfault - that line should go.  The automatic nulling of
the _vptr of 'u1', on scope entry, has gone and so its value is
indeterminate.  same_type_as takes the _vptrs as arguments - hence the
segfault.

I'll commit tonight unless anybody has any objections.

Cheers

Paul

On 19 December 2012 00:18, Dominique Dhumieres  wrote:
> Dear Paul,
>
> With your patch applied on top of a clean revision 194590, the executable
> for unlimited_polymorphic_1.f03 gives a Segmentation fault -
> invalid memory reference at
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00011d1c in MAIN__ () at 
> /opt/gcc/p_work/gcc/testsuite/gfortran.dg/unlimited_polymorphic_1.f03:69
> 69if (SAME_TYPE_AS (obj1, u1) .neqv. .FALSE.) call abort
>
> This segmentation fault disappears if I compile the test with
> -fsanitize=address, while valgrind gives an endless
>
> ==14264== Signal 11 being dropped from thread 0's queue
>
> Indeed this is on x86_64-apple-darwin10.
>
> TIA
>
> Dominique
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
   --Hitchhikers Guide to the Galaxy


Re: [doc] extend.texi copy-editing, 3/N (hyphenated phrases)

2012-12-18 Thread Gerald Pfeifer
Hi Sandra,

On Sat, 10 Nov 2012, Sandra Loosemore wrote:
> 2012-11-10  Sandra Loosemore  
> 
>   gcc/
>   * doc/extend.texi: Copy-edit to fix incorrect hyphenation phrases
>   involving "bit", "byte", "word", "precision", and "floating"
>   modifiers.

Index: gcc/doc/extend.texi
===
-for targets having @code{long long} integer with less then 128 bit width.
+for targets having @code{long long} integer less than 128 bits wide.

Should this one read "long long integer_s_" (plural)?  

-causes the compiler to pass up to 3 floating point arguments in
+causes the compiler to pass up to 3 floating-point arguments in

While we are at it, should this be "three" instead of "3"?  It would
in my native Austrian/German, but perhaps English is different here?

-Generate code that uses (does not use) the popcount and double
-precision FP reciprocal estimate instruction implemented on the POWER5
+Generate code that uses (does not use) the popcount and double-precision
+FP reciprocal estimate instruction implemented on the POWER5

Should this one by "floating-point" instead of FP?

And @code{popcount} ?


I'll be happy to make all those changes, wanted to verify with you as
a native speaker, and one who cares about grammar, first though. ;-)

Gerald


[cxx-conversion] Change uses of htab_t in gcc/config to hash_table.

2012-12-18 Thread Lawrence Crowl
Update various config htab_t uses to hash_table.

Modify types and calls to match.

* config/arm/arm.c'arm_libcall_uses_aapcs_base::libcall_htab

Fold libcall_eq and libcall_hash into new struct libcall_hasher.

* config/ia64/ia64.c'bundle_state_table

Fold bundle_state_hash and bundle_state_eq_p into new struct
bundle_state_hasher.

* config/mips/mips.c'mips_offset_table

Fold mips_lo_sum_offset_hash and mips_lo_sum_offset_eq into new
struct mips_lo_sum_offset_hasher.

In mips_reorg_process_insns, change call to for_each_rtx to pass
a pointer to the hash_table rather than a htab_t.  This change
requires then dereferencing that pointer in mips_record_lo_sum to
obtain the hash_table.

* config/sol2.c'solaris_comdat_htab

Fold comdat_hash and comdat_eq into new struct comdat_entry_hasher.

* config/i386/winnt.c'i386_pe_section_type_flags::htab

* config/i386/winnt.c'i386_find_on_wrapper_list::wrappers

Fold wrapper_strcmp into new struct wrapped_symbol_hasher.


Tested on x86-64.
Tested with contrib/config-list.mk.


Okay for branch?


Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 194511)
+++ gcc/config/arm/arm.c(working copy)
@@ -25,6 +25,7 @@
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
+#include "hash-table.h"
 #include "tm.h"
 #include "rtl.h"
 #include "tree.h"
@@ -3716,36 +3717,48 @@ arm_function_value(const_tree type, cons
   return arm_libcall_value_1 (mode);
 }

-static int
-libcall_eq (const void *p1, const void *p2)
+/* libcall hashtable helpers.  */
+
+struct libcall_hasher : typed_noop_remove 
 {
-  return rtx_equal_p ((const_rtx) p1, (const_rtx) p2);
+  typedef rtx_def value_type;
+  typedef rtx_def compare_type;
+  static inline hashval_t hash (const value_type *);
+  static inline bool equal (const value_type *, const compare_type *);
+  static inline void remove (value_type *);
+};
+
+inline bool
+libcall_hasher::equal (const value_type *p1, const compare_type *p2)
+{
+  return rtx_equal_p (p1, p2);
 }

-static hashval_t
-libcall_hash (const void *p1)
+inline hashval_t
+libcall_hasher::hash (const value_type *p1)
 {
-  return hash_rtx ((const_rtx) p1, VOIDmode, NULL, NULL, FALSE);
+  return hash_rtx (p1, VOIDmode, NULL, NULL, FALSE);
 }

+typedef hash_table  libcall_table_type;
+
 static void
-add_libcall (htab_t htab, rtx libcall)
+add_libcall (libcall_table_type htab, rtx libcall)
 {
-  *htab_find_slot (htab, libcall, INSERT) = libcall;
+  *htab.find_slot (libcall, INSERT) = libcall;
 }

 static bool
 arm_libcall_uses_aapcs_base (const_rtx libcall)
 {
   static bool init_done = false;
-  static htab_t libcall_htab;
+  static libcall_table_type libcall_htab;

   if (!init_done)
 {
   init_done = true;

-  libcall_htab = htab_create (31, libcall_hash, libcall_eq,
- NULL);
+  libcall_htab.create (31);
   add_libcall (libcall_htab,
   convert_optab_libfunc (sfloat_optab, SFmode, SImode));
   add_libcall (libcall_htab,
@@ -3804,7 +3817,7 @@ arm_libcall_uses_aapcs_base (const_rtx l
DFmode));
 }

-  return libcall && htab_find (libcall_htab, libcall) != NULL;
+  return libcall && libcall_htab.find (libcall) != NULL;
 }

 static rtx
Index: gcc/config/arm/t-arm
===
--- gcc/config/arm/t-arm(revision 194511)
+++ gcc/config/arm/t-arm(working copy)
@@ -73,8 +73,8 @@ $(srcdir)/config/arm/arm-tables.opt: $(s
$(SHELL) $(srcdir)/config/arm/genopt.sh $(srcdir)/config/arm > \
$(srcdir)/config/arm/arm-tables.opt

-arm.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
-  $(RTL_H) $(TREE_H) $(OBSTACK_H) $(REGS_H) hard-reg-set.h \
+arm.o: $(srcdir)/config/arm/arm.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
+  $(RTL_H) $(TREE_H) $(HASH_TABLE_H) $(OBSTACK_H) $(REGS_H) hard-reg-set.h \
   insn-config.h conditions.h output.h dumpfile.h \
   $(INSN_ATTR_H) $(FLAGS_H) reload.h $(FUNCTION_H) \
   $(EXPR_H) $(OPTABS_H) $(RECOG_H) $(CGRAPH_H) \
Index: gcc/config/i386/winnt.c
===
--- gcc/config/i386/winnt.c (revision 194511)
+++ gcc/config/i386/winnt.c (working copy)
@@ -31,7 +31,7 @@ along with GCC; see the file COPYING3.
 #include "flags.h"
 #include "tm_p.h"
 #include "diagnostic-core.h"
-#include "hashtab.h"
+#include "hash-table.h"
 #include "langhooks.h"
 #include "ggc.h"
 #include "target.h"
@@ -449,7 +449,7 @@ i386_pe_reloc_rw_mask (void)
 unsigned int
 i386_pe_section_type_flags (tree decl, const char *name, int reloc)
 {
-  static htab_t htab;
+  static hash_table  > htab;
   unsigned int flags;
   unsigned int **slot;

@@ -460,8 +460,8 @@ i386_pe_section_type_flags (tree decl, c
   /* The names we put in the hashtable will always be the unique
  versions given to us by the stringtabl

[PATCH, wwwdocs] Add a note for performance improvements for MIPS/XLP

2012-12-18 Thread Maxim Kuvyrkov
The attached patch adds a release note for performance improvements for 
Broadcom XLP processors (MIPS architecture) that went into GCC 4.8.

OK to apply?

Thanks,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics




xlp-performance.patch
Description: Binary data


Re: PATCH RFA: PR go/55201: Create libatomic convenience library

2012-12-18 Thread Ian Lance Taylor
On Tue, Dec 18, 2012 at 3:15 PM, Richard Henderson  wrote:
> On 12/18/2012 02:52 PM, Ian Lance Taylor wrote:
>> Argh.  But why?  Wouldn't that only apply to cases where the lock was
>> sometimes locked by one library and sometimes locked by a different
>> one?
>
> Or did you really mean
>
>   "... only apply to cases where the memory protected by the lock
>was visible to more than one library."
>
> Yes, if libgo is attempting atomic accesses to its own data structures,
> which themselves are not exported from libgo, then a copy of libatomic
> ought to work.
>
> It would probably be better for the shared libgo to depend on the
> shared libatomic though.  That's simply more pedantically correct.

But according to Matthias's comment upthread, it would require
addressing some issue in libtool in order to get multilib working
correctly.

I'm not going to try to solve this today, but if somebody else wants
to that would be great.

Ian


Re: [PATCH] Function Multiversioning Bug, checking for function versions

2012-12-18 Thread Diego Novillo
On Tue, Dec 18, 2012 at 6:38 PM, Sriraman Tallam  wrote:

> The function versions are now determined purely based on the string
> value and not on DECL_FUNCTION_SPECIFIC_TARGET fields. So, this check
> is not necessary.

Ah, OK.  Thanks.

The patch is OK with that minor fix then.


Diego.


Re: [cxx-conversion] Convert statistics.c'statistics_hashes to hash_table.

2012-12-18 Thread Diego Novillo
On Mon, Dec 17, 2012 at 2:32 PM, Lawrence Crowl  wrote:
> Convert statistics.c'statistics_hashes from htab_t to hash_table.
>
> Fold hash_statistics_eq into new struct stats_counter_hasher.
>
> Update dependent calls and types.
>
> Tested on x86_64.
>
> Okay for branch?

OK.


Diego.


Re: [cxx-conversion] Convert remaining tree-parloops.c htab_t to hash_table.

2012-12-18 Thread Diego Novillo
On Mon, Dec 17, 2012 at 2:34 PM, Lawrence Crowl  wrote:
> Change tree-parloops.c reduction and name_to_copy hash tables from
> htab_t to hash_table.
>
> Fold reduction_info_hash and reduction_info_eq into new struct
> reduction_hasher.  Fold name_to_copy_elt_eq and name_to_copy_elt_hash
> into new struct name_to_copy_hasher.
>
> Update dependent types and calls.
>
> Tested on x86_64.
>
> Okay for branch?

OK.


Diego.


Re: [PATCH] Function Multiversioning Bug, checking for function versions

2012-12-18 Thread Sriraman Tallam
Hi Diego,

   Thanks for the review.

On Tue, Dec 18, 2012 at 8:04 AM, Diego Novillo  wrote:
> On 2012-11-16 14:55 , Sriraman Tallam wrote:
>>
>> Hi,
>>
>> The previous patch was incomplete because the front-end strips off
>> invalid target attributes which I did not consider. The attached
>> updated patch handles this with updated test cases.
>>
>> Thanks,
>> -Sri.
>>
>> On Thu, Nov 15, 2012 at 2:08 PM, Sriraman Tallam 
>> wrote:
>>>
>>> Hi,
>>>
>>> Currently, function multiversioning determines that two functions
>>> are different by comparing the arch type and isa flags that are set
>>> after the target string is processed. This leads to cases where  the
>>> versions become identical when the command-line target options are
>>> altered.
>>>
>>> For example, these two versions:
>>>
>>> __attribute__ target (("sse4.2")))
>>> int foo ()
>>> {
>>> }
>>>
>>> __attribute__ target (("popcnt")))
>>> int foo ()
>>> {
>>> }
>>>
>>> become identical when -mpopcnt and -msse4.2 are used while building,
>>> leading to build errors.
>>>
>>> To avoid this, I have modified the function version determination to
>>> just compare the target string.
>>> Patch attached. Is this alright to submit?
>>>
>>> Thanks,
>>> -Sri.
>>
>>
>> * doc/tm.texi.in (TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS):
>> Document
>> new target hook.
>> * doc/tm.texi: Regenerate.
>> * c-family/c-common.c (handle_target_attribute): Retain target
>> attribute
>> for targets that support versioning.
>> * target.def (supports_function_versions): New hook.
>> * config/i386/i386.c (ix86_function_versions): Use target string
>> to check for function versions instead of target flags.
>> * testsuite/g++.dg/mv1.C: Remove target options.
>> * testsuite/g++.dg/mv2.C: Ditto.
>> * testsuite/g++.dg/mv3.C: Ditto.
>> * testsuite/g++.dg/mv4.C: Ditto.
>> * testsuite/g++.dg/mv5.C: Ditto.
>> * cp/class.c (add_method): Remove calls
>> to DECL_FUNCTION_SPECIFIC_TARGET.
>> * config/i386/i386.c (ix86_function_versions): Use target string
>> to check for function versions instead of target flags.
>> * (ix86_supports_function_versions): New function.
>> * (is_function_default_version): Check target string.
>> * TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS: New macro.
>>
>
>
> Looks mostly OK.
>
>> Index: cp/class.c
>> ===
>> --- cp/class.c  (revision 193486)
>> +++ cp/class.c  (working copy)
>> @@ -1095,8 +1095,6 @@ add_method (tree type, tree method, tree using_dec
>>   && TREE_CODE (method) == FUNCTION_DECL
>>   && !DECL_EXTERN_C_P (fn)
>>   && !DECL_EXTERN_C_P (method)
>> - && (DECL_FUNCTION_SPECIFIC_TARGET (fn)
>> - || DECL_FUNCTION_SPECIFIC_TARGET (method))
>
>
> I don't follow.  Given the new hook, why do you need to remove this check?

The function versions are now determined purely based on the string
value and not on DECL_FUNCTION_SPECIFIC_TARGET fields. So, this check
is not necessary.


>
>> +/* This function returns true if FN1 and FN2 are versions of the same
>> function,
>> +   that is, the target strings of the function decls are different.  This
>> assumes
>> +   that FN1 and FN2 have the same signature.  */
>> +
>> +static bool
>> +ix86_function_versions (tree fn1, tree fn2)
>> +{
>
>
> Any particular reason why you moved this function down here?

Just refactoring, keeping functions that are related to
ix86_dispatch_versions together.

>
>> +  tree attr1, attr2;
>> +  const char *attr_str1, *attr_str2;
>> +  char *target1, *target2;
>> +  bool result;
>> +
>> +  if (TREE_CODE (fn1) != FUNCTION_DECL
>> +  || TREE_CODE (fn2) != FUNCTION_DECL)
>> +return false;
>> +
>> +  attr1 = lookup_attribute ("target", DECL_ATTRIBUTES (fn1));
>> +  attr2 = lookup_attribute ("target", DECL_ATTRIBUTES (fn2));
>> +
>> +  /* Atleast one function decl should have the target attribute
>> specified.  */
>
>
> s/Atleast/At least/

I will make this change.

Thanks,
-Sri.

>
>
> Diego.


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-18 Thread Jakub Jelinek
On Tue, Dec 18, 2012 at 10:38:06PM +0100, Tobias Burnus wrote:
> Updated patch attached. Build and regtested on x86-64-gnu-linux.
> OK for the trunk?

Looks ok to me, thanks.

> 2012-12-11  Tobias Burnus  
>   Jakub Jelinek  
>   Janus Weil  
> 
>   PR fortran/55636
>   PR fortran/55733
>   * gfortran.h (GFC_PREFIX): Define.
>   * trans-decl.c (gfc_create_string_length): For VAR_DECLs that
>   will be TREE_STATIC, use GFC_PREFIX to mangle the names. Handle
>   -fno-automatic
>   (gfc_trans_deferred_vars): Don't free variables SAVEd via
>   -fno-automatic.
> 
> 2012-12-11  Tobias Burnus  
> 
>   PR fortran/55733
>   * gfortran.dg/save_5.f90: New.

Jakub


Re: Patch to enable unlimited polymorphism to gfortran

2012-12-18 Thread Dominique Dhumieres
Dear Paul,

With your patch applied on top of a clean revision 194590, the executable
for unlimited_polymorphic_1.f03 gives a Segmentation fault - 
invalid memory reference at

Program received signal SIGSEGV, Segmentation fault.
0x00011d1c in MAIN__ () at 
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/unlimited_polymorphic_1.f03:69
69if (SAME_TYPE_AS (obj1, u1) .neqv. .FALSE.) call abort

This segmentation fault disappears if I compile the test with
-fsanitize=address, while valgrind gives an endless

==14264== Signal 11 being dropped from thread 0's queue

Indeed this is on x86_64-apple-darwin10.

TIA

Dominique



Re: PATCH RFA: PR go/55201: Create libatomic convenience library

2012-12-18 Thread Richard Henderson
On 12/18/2012 02:52 PM, Ian Lance Taylor wrote:
> Argh.  But why?  Wouldn't that only apply to cases where the lock was
> sometimes locked by one library and sometimes locked by a different
> one?

Or did you really mean

  "... only apply to cases where the memory protected by the lock
   was visible to more than one library."

Yes, if libgo is attempting atomic accesses to its own data structures,
which themselves are not exported from libgo, then a copy of libatomic
ought to work.

It would probably be better for the shared libgo to depend on the
shared libatomic though.  That's simply more pedantically correct.


r~


Re: PATCH RFA: PR go/55201: Create libatomic convenience library

2012-12-18 Thread Richard Henderson
On 12/18/2012 02:52 PM, Ian Lance Taylor wrote:
> Argh.  But why?  Wouldn't that only apply to cases where the lock was
> sometimes locked by one library and sometimes locked by a different
> one?

If two copies of the library aren't looking at the same lock object,
then the lock does no actual locking.

The lock object(s) themselves are not part of the public interface
of the libatomic library.


r~


Re: PATCH RFA: PR go/55201: Create libatomic convenience library

2012-12-18 Thread Ian Lance Taylor
On Tue, Dec 18, 2012 at 2:30 PM, Richard Henderson  wrote:
> On 12/18/2012 02:09 PM, Ian Lance Taylor wrote:
>> I have now committed this follow-on patch, to make libgo use the new
>> libatomic_convenience library.  This means that the changes to
>> explicitly link against -latomic are no longer necessary.
>
> Hang on, what are we doing here.  Are we linking libatomic statically
> into libgo?  That's only going to work so long as the target does not
> require the use of a mutex.  While that's most desktop targets, it's
> certainly not all of them.
>
> If the target requires a mutex for the atomic operation, then there
> must be exactly one copy of the atomic library.

Argh.  But why?  Wouldn't that only apply to cases where the lock was
sometimes locked by one library and sometimes locked by a different
one?

Ian


Re: [PATCH] Fix up convert_for_assignment warnings (PR c/39464)

2012-12-18 Thread Joseph S. Myers
On Fri, 7 Dec 2012, Jakub Jelinek wrote:

> 2012-12-07  Jakub Jelinek  
> 
>   PR c/39464
>   * c-typeck.c (convert_for_assignment): For -Wpointer-sign
>   warning require that both c_common_unsigned_type as well as
>   c_common_signed_type is the same for both mvl and mvr types.
> 
>   * gcc.dg/pr39464.c: New test.

OK.

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


Re: Patch to enable unlimited polymorphism to gfortran

2012-12-18 Thread Tobias Burnus

Paul Richard Thomas wrote:

Please find attached an updated version of the patch, which I believe
answers your comments/objections.


Thanks for the patch. They patch is OK from my side, if you address the 
issues below.



+ /* Assign a hash value for an intrinsic type. The algorithm is that of SDBM.  
*/
+
+ unsigned int
+ gfc_intrinsic_hash_value (gfc_typespec *ts)
+ {
+   unsigned int hash = 0;
+   char c[2*(GFC_MAX_SYMBOL_LEN+1)];
+   int i, len;
+
+   strcpy (&c[0], gfc_typename (ts));


I think you should simply use
   const char *c = gfc_typename (ts);
as you do not modify "c". That saves some memory on the stack and avoids 
a function call. Additionally, it prevents me from wondering why you 
need more than GFC_MAX_SYMBOL_LEN.




+ /* Find (or generate) the symbol for an intrinsic types's vtab.  This is
+need to support unlimited polymorphism.  */


types's -> type's



+   gfc_error ("Actual argument to '%s' at %L must be unlimited "
+  "polymorphic since the formal argument is %s, "
+  "unlimited polymorphic entity [F2008: 12.5.2.5]",
+  formal->name, &actual->where,
+  CLASS_DATA (formal)->attr.class_pointer ?
+  "a pointer" : "an allocatable");


I fear that translators will hate you for the "%s" with "a pointer" / 
"an allocatable". At least when "a pointer"/"an allocatable" occurs 
elsewhere, they cannot properly translate it as the translation might 
depend whether it is subject or object in the sentence. Even if not, 
translators will not (easily) see that those strings belong to this 
error message.



+ if (UNLIMITED_POLY (tail->expr))
+   gfc_error ("Unlimited polymorphic allocate-object at %L "
+  "requires either a type-spec or SOURCE tag",
+  &tail->expr->where);


That's not true. The standard also allows MOLD=. Thus, either add "or 
MOLD" or change "SOURCE tag" to "source-expr(ession)", which covers both.


I haven't checked the source code, but you might have to add an "&& 
!mold" as well.



Tobias


Re: PATCH RFA: PR go/55201: Create libatomic convenience library

2012-12-18 Thread Richard Henderson
On 12/18/2012 02:09 PM, Ian Lance Taylor wrote:
> I have now committed this follow-on patch, to make libgo use the new
> libatomic_convenience library.  This means that the changes to
> explicitly link against -latomic are no longer necessary.

Hang on, what are we doing here.  Are we linking libatomic statically
into libgo?  That's only going to work so long as the target does not
require the use of a mutex.  While that's most desktop targets, it's
certainly not all of them.

If the target requires a mutex for the atomic operation, then there
must be exactly one copy of the atomic library.


r~



Re: PATCH RFA: PR go/55201: Create libatomic convenience library

2012-12-18 Thread Ian Lance Taylor
On Tue, Dec 18, 2012 at 1:32 PM, Richard Henderson  wrote:
> On 12/18/2012 11:30 AM, Ian Lance Taylor wrote:
>> 2012-12-18  Ian Lance Taylor  
>>
>>   PR go/55201
>>   * Makefile.am (noinst_LTLIBRARIES): Define new make variable.
>>   (libatomic_convenience_la_SOURCES): Likewise.
>>   (libatomic_convenience_la_LIBADD): Likewise.
>>   * Makefile.in: Rebuild.
>>   * testsuite/Makefile.in: Rebuild.
>
> Ok.

Committed.

I have now committed this follow-on patch, to make libgo use the new
libatomic_convenience library.  This means that the changes to
explicitly link against -latomic are no longer necessary.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian

gcc/go:

2012-12-18  Ian Lance Taylor  

PR go/55201
* gospec.c: Revert last patch.

gcc/testsuite:

2012-12-18  Ian Lance Taylor  

PR go/55201
* lib/go.exp: Revert last patch.


foo.patch
Description: Binary data


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-18 Thread Tobias Burnus

Jakub Jelinek wrote:

As written, TREE_STATIC is currently not set (which is a bug, cf.
PR55733);


That's now fixed. I also add to remove a spurious free() call.


If that is changed, surely the name must be mangled too.
Perhaps best to set a bool variable to the condition and use it in both
places.
   bool static_length = sym->attr.save
  || sym->ns->proc_name->attr.flavor == FL_MODULE
  || gfc_option.flag_max_stack_var_size == 0;
   if (static_length)


I did so now.


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

Tobias
2012-12-11  Tobias Burnus  
	Jakub Jelinek  
	Janus Weil  

	PR fortran/55636
	PR fortran/55733
	* gfortran.h (GFC_PREFIX): Define.
	* trans-decl.c (gfc_create_string_length): For VAR_DECLs that
	will be TREE_STATIC, use GFC_PREFIX to mangle the names. Handle
	-fno-automatic
	(gfc_trans_deferred_vars): Don't free variables SAVEd via
	-fno-automatic.

2012-12-11  Tobias Burnus  

	PR fortran/55733
	* gfortran.dg/save_5.f90: New.

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index bf767b2..74162e7 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -63,6 +63,15 @@ along with GCC; see the file COPYING3.  If not see
 #define PREFIX(x) "_gfortran_" x
 #define PREFIX_LEN 10
 
+/* A prefix for internal variables, which are not user-visible.  */
+#if !defined (NO_DOT_IN_LABEL)
+# define GFC_PREFIX(x) "_F." x
+#elif !defined (NO_DOLLAR_IN_LABEL)
+# define GFC_PREFIX(x) "_F$" x
+#else
+# define GFC_PREFIX(x) "_F_" x
+#endif
+
 #define BLANK_COMMON_NAME "__BLNK__"
 
 /* Macro to initialize an mstring structure.  */
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index dbc5a10..3202840 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1089,8 +1089,22 @@ gfc_create_string_length (gfc_symbol * sym)
   tree length;
   const char *name;
 
-  /* Also prefix the mangled name.  */
-  if (sym->module)
+  bool static_length = sym->attr.save
+			   || sym->ns->proc_name->attr.flavor == FL_MODULE
+			   || gfc_option.flag_max_stack_var_size == 0;
+
+  /* Also prefix the mangled name. We need to call GFC_PREFIX for static
+	 variables as some systems do not support the "." in the assembler name.
+	 For nonstatic variables, the "." does not appear in assembler.  */
+  if (static_length)
+	{
+	  if (sym->module)
+	name = gfc_get_string (GFC_PREFIX ("%s_MOD_%s"), sym->module,
+   sym->name);
+	  else
+	name = gfc_get_string (GFC_PREFIX ("%s"), sym->name);
+	}
+  else if (sym->module)
 	name = gfc_get_string (".__%s_MOD_%s", sym->module, sym->name);
   else
 	name = gfc_get_string (".%s", sym->name);
@@ -1105,7 +1119,7 @@ gfc_create_string_length (gfc_symbol * sym)
 
   sym->ts.u.cl->backend_decl = length;
 
-  if (sym->attr.save || sym->ns->proc_name->attr.flavor == FL_MODULE)
+  if (static_length)
 	TREE_STATIC (length) = 1;
 
   if (sym->ns->proc_name->attr.flavor == FL_MODULE
@@ -3702,7 +3716,7 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gfc_wrapped_block * block)
 		|| (sym->ts.type == BT_CLASS
 			&& CLASS_DATA (sym)->attr.allocatable)))
 	{
-	  if (!sym->attr.save)
+	  if (!sym->attr.save && gfc_option.flag_max_stack_var_size != 0)
 	{
 	  tree descriptor = NULL_TREE;
 
diff --git a/gcc/testsuite/gfortran.dg/save_5.f90 b/gcc/testsuite/gfortran.dg/save_5.f90
new file mode 100644
index 000..20d3b7a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/save_5.f90
@@ -0,0 +1,52 @@
+! { dg-do run }
+! { dg-options "-fno-automatic" }
+!
+! PR fortran/55733
+!
+! Check that -fno-automatic makes the local variable SAVEd
+!
+
+! Scalar allocatable
+subroutine foo(i)
+  integer :: i
+  integer, allocatable :: j
+  if (i == 1) j = 42
+  if (.not. allocated (j)) call abort ()
+  if (j /= 42) call abort ()
+end
+
+! Deferred-length string scalar
+subroutine bar()
+  logical, save :: first = .true.
+  character(len=:), allocatable :: str
+  if (first) then
+first = .false.
+if (allocated (str)) call abort ()
+str = "ABCDEF"
+  end if
+  if (.not. allocated (str)) call abort ()
+  if (len (str) /= 6) call abort ()
+  if (str(1:6) /= "ABCDEF") call abort ()
+end subroutine bar
+
+! Deferred-length string array
+subroutine bar_array()
+  logical, save :: first = .true.
+  character(len=:), allocatable :: str
+  if (first) then
+first = .false.
+if (allocated (str)) call abort ()
+str = "ABCDEF"
+  end if
+  if (.not. allocated (str)) call abort ()
+  if (len (str) /= 6) call abort ()
+  if (str(1:6) /= "ABCDEF") call abort ()
+end subroutine bar_array
+
+call foo(1)
+call foo(2)
+call bar()
+call bar_array()
+call bar()
+call bar_array()
+end


Re: Patch ping

2012-12-18 Thread Paul Richard Thomas
Dear Jakub,

The fortran part looks fine to me.  The sooner that you commit the
better - I will update the unlimited polymorphic patch accordingly.

Thanks

Paul

On 18 December 2012 15:11, Jakub Jelinek  wrote:
> Hi!
>
> - PR c/39464 P2 -Wpointer-sign fix
>   http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00523.html
>
> - PR fortran/55636 P1 Fortran ABI (mangling) fix
>   http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00726.html
>
> - PR c++/55619 C FE changes corresponding to C++ FE changes for inline asm 
> "m" constrained inputs
>   http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00852.html
>
> - PR debug/54402 P1 --max-vartrack-reverse-op-size=N to speed up var-tracking
>   http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00891.html
>
> Jakub



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
   --Hitchhikers Guide to the Galaxy


Re: [PATCH] Fix up sbitmap bitmap_{and,ior,xor} (PR target/55562)

2012-12-18 Thread Richard Henderson
On 12/18/2012 08:47 AM, Jakub Jelinek wrote:
> 2012-12-18  Jakub Jelinek  
> 
>   PR target/55562
>   * sbitmap.c (bitmap_and, bitmap_xor, bitmap_ior): Return whether
>   dst sbitmap changed even if it doesn't have popcount.


Ok.


r~


Re: PATCH RFA: PR go/55201: Create libatomic convenience library

2012-12-18 Thread Richard Henderson
On 12/18/2012 11:30 AM, Ian Lance Taylor wrote:
> 2012-12-18  Ian Lance Taylor  
> 
>   PR go/55201
>   * Makefile.am (noinst_LTLIBRARIES): Define new make variable.
>   (libatomic_convenience_la_SOURCES): Likewise.
>   (libatomic_convenience_la_LIBADD): Likewise.
>   * Makefile.in: Rebuild.
>   * testsuite/Makefile.in: Rebuild.

Ok.


r~


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-18 Thread Jakub Jelinek
On Tue, Dec 18, 2012 at 08:45:49PM +0100, Tobias Burnus wrote:
> Or one of the examples from PR55733. The example above gives
> currently (w/o your patch):
> 
>   static character(kind=1)[1:.str] * str = 0B;
>   integer(kind=4) .str;

Yeah, that is not a problem for ABI.

> >Where would be TREE_STATIC set on the length variable with -fno-automatic,
> >and on which testcase?
> 
> As written, TREE_STATIC is currently not set (which is a bug, cf.
> PR55733); I think one needs a patch like:
> 
> --- a/gcc/fortran/trans-decl.c
> +++ b/gcc/fortran/trans-decl.c
> @@ -1107,3 +1107,4 @@ gfc_create_string_length (gfc_symbol * sym)
> 
> -  if (sym->attr.save || sym->ns->proc_name->attr.flavor == FL_MODULE)
> +  if (sym->attr.save || sym->ns->proc_name->attr.flavor == FL_MODULE
> + || gfc_option.flag_max_stack_var_size == 0)
> TREE_STATIC (length) = 1;

If that is changed, surely the name must be mangled too.
Perhaps best to set a bool variable to the condition and use it in both
places.
  bool static_length = sym->attr.save
  || sym->ns->proc_name->attr.flavor == FL_MODULE
  || gfc_option.flag_max_stack_var_size == 0;
  if (static_length)
{
  name mangling;
}
  else ...

...
  if (static_length)
TREE_STATIC (length) = 1;

Jakub


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-18 Thread Tobias Burnus

Jakub Jelinek wrote:

On Tue, Dec 18, 2012 at 04:40:10PM +0100, Tobias Burnus wrote:

Looks mostly okay, however, I fear that for

subroutine foo()
character(len=:), allocatable :: str
allocate(str, stat=istat)
end subroutine foo

compiled with "-fno-automatic", gfortran will still generate the
non-GFC_PREFIX-mangled string.

That doesn't compile:
Error: Allocate-object at (1) with a deferred type parameter requires either a 
type-spec or SOURCE tag or a MOLD tag


Sorry for the bad example. I added the allocate just to mark the 
variable as used (otherwise no decl is generated); but my cut-down 
example was wrong. Try:


subroutine foo()
  character(len=:), allocatable :: str
  print *, allocated(str)
end subroutine foo


Or one of the examples from PR55733. The example above gives currently 
(w/o your patch):


  static character(kind=1)[1:.str] * str = 0B;
  integer(kind=4) .str;



Where would be TREE_STATIC set on the length variable with -fno-automatic,
and on which testcase?


As written, TREE_STATIC is currently not set (which is a bug, cf. 
PR55733); I think one needs a patch like:


--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1107,3 +1107,4 @@ gfc_create_string_length (gfc_symbol * sym)

-  if (sym->attr.save || sym->ns->proc_name->attr.flavor == FL_MODULE)
+  if (sym->attr.save || sym->ns->proc_name->attr.flavor == FL_MODULE
+ || gfc_option.flag_max_stack_var_size == 0)
TREE_STATIC (length) = 1;


Tobias


PATCH RFA: PR go/55201: Create libatomic convenience library

2012-12-18 Thread Ian Lance Taylor
On Tue, Dec 18, 2012 at 9:57 AM, Ian Lance Taylor  wrote:
>
> This doesn't happen for me, and it's bizarre that libtool would turn a
> link against ../libatomic/libatomic.la into a link against -latomic.
> But in any case the fix is presumably going to be to add a convenience
> library for libatomic, as is done for libffi.  I'll prepare a patch
> for that.

Like so.

OK for mainline?

If this is approved, I will submit the changes to libgo to use it.

Ian


2012-12-18  Ian Lance Taylor  

PR go/55201
* Makefile.am (noinst_LTLIBRARIES): Define new make variable.
(libatomic_convenience_la_SOURCES): Likewise.
(libatomic_convenience_la_LIBADD): Likewise.
* Makefile.in: Rebuild.
* testsuite/Makefile.in: Rebuild.


foo.patch
Description: Binary data


Re: [PATCH] Fix up sbitmap bitmap_{and,ior,xor} (PR target/55562)

2012-12-18 Thread Lawrence Crowl
On 12/18/12, Jakub Jelinek  wrote:
> The bitmap unification changes apparently broke at least modulo
> scheduling, which used sbitmap_a_and_b_cg functions, which
> were replaced by bitmap_and.  But, sbitmap_a_and_b_cg asserted
> dst->popcount is NULL and returned whether dst sbitmap changed,
> but bitmap_and returns always false if dst->popcount is NULL
> (and only if it is non-NULL returns if the bitmap changed).
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?

The changes look okay to me.  (But I don't approve trunk.)

> Alternatively we could add back separate functions that would
> return whether dest changed for speed reasons (similarly to
> the old *_cg ones), and return void from the normal ones again.
> I bet most of the users don't check the return value of these
> functions and thus it is useless computation.

The discussion at the time was pretty conclusive to not have
separate functions.

>
> 2012-12-18  Jakub Jelinek  
>
>   PR target/55562
>   * sbitmap.c (bitmap_and, bitmap_xor, bitmap_ior): Return whether
>   dst sbitmap changed even if it doesn't have popcount.
>
> --- gcc/sbitmap.c.jj  2012-11-02 09:01:54.0 +0100
> +++ gcc/sbitmap.c 2012-12-18 14:29:13.695299294 +0100
> @@ -434,28 +434,26 @@ bitmap_and (sbitmap dst, const_sbitmap a
>const_sbitmap_ptr bp = b->elms;
>bool has_popcount = dst->popcount != NULL;
>unsigned char *popcountp = dst->popcount;
> -  bool anychange = false;
> +  SBITMAP_ELT_TYPE changed = 0;
>
>for (i = 0; i < n; i++)
>  {
>const SBITMAP_ELT_TYPE tmp = *ap++ & *bp++;
> +  SBITMAP_ELT_TYPE wordchanged = *dstp ^ tmp;
>if (has_popcount)
>   {
> -   bool wordchanged = (*dstp ^ tmp) != 0;
> if (wordchanged)
> - {
> -   *popcountp = do_popcount (tmp);
> -   anychange = true;
> - }
> + *popcountp = do_popcount (tmp);
> popcountp++;
>   }
>*dstp++ = tmp;
> +  changed |= wordchanged;
>  }
>  #ifdef BITMAP_DEBUGGING
>if (has_popcount)
>  sbitmap_verify_popcount (dst);
>  #endif
> -  return anychange;
> +  return changed != 0;
>  }
>
>  /* Set DST to be (A xor B)).
> @@ -470,28 +468,26 @@ bitmap_xor (sbitmap dst, const_sbitmap a
>const_sbitmap_ptr bp = b->elms;
>bool has_popcount = dst->popcount != NULL;
>unsigned char *popcountp = dst->popcount;
> -  bool anychange = false;
> +  SBITMAP_ELT_TYPE changed = 0;
>
>for (i = 0; i < n; i++)
>  {
>const SBITMAP_ELT_TYPE tmp = *ap++ ^ *bp++;
> +  SBITMAP_ELT_TYPE wordchanged = *dstp ^ tmp;
>if (has_popcount)
>   {
> -   bool wordchanged = (*dstp ^ tmp) != 0;
> if (wordchanged)
> - {
> -   *popcountp = do_popcount (tmp);
> -   anychange = true;
> - }
> + *popcountp = do_popcount (tmp);
> popcountp++;
>   }
>*dstp++ = tmp;
> +  changed |= wordchanged;
>  }
>  #ifdef BITMAP_DEBUGGING
>if (has_popcount)
>  sbitmap_verify_popcount (dst);
>  #endif
> -  return anychange;
> +  return changed != 0;
>  }
>
>  /* Set DST to be (A or B)).
> @@ -506,28 +502,26 @@ bitmap_ior (sbitmap dst, const_sbitmap a
>const_sbitmap_ptr bp = b->elms;
>bool has_popcount = dst->popcount != NULL;
>unsigned char *popcountp = dst->popcount;
> -  bool anychange = false;
> +  SBITMAP_ELT_TYPE changed = 0;
>
>for (i = 0; i < n; i++)
>  {
>const SBITMAP_ELT_TYPE tmp = *ap++ | *bp++;
> +  SBITMAP_ELT_TYPE wordchanged = *dstp ^ tmp;
>if (has_popcount)
>   {
> -   bool wordchanged = (*dstp ^ tmp) != 0;
> if (wordchanged)
> - {
> -   *popcountp = do_popcount (tmp);
> -   anychange = true;
> - }
> + *popcountp = do_popcount (tmp);
> popcountp++;
>   }
>*dstp++ = tmp;
> +  changed |= wordchanged;
>  }
>  #ifdef BITMAP_DEBUGGING
>if (has_popcount)
>  sbitmap_verify_popcount (dst);
>  #endif
> -  return anychange;
> +  return changed != 0;
>  }
>
>  /* Return nonzero if A is a subset of B.  */

-- 
Lawrence Crowl


[PATCH] Add gen_lowpart_for_debug (PR debug/55730)

2012-12-18 Thread Jakub Jelinek
Hi!

On Tue, Dec 18, 2012 at 09:25:14AM +0100, Paolo Bonzini wrote:
> Il 17/12/2012 22:33, Jakub Jelinek ha scritto:
> > If gen_lowpart_if_possible returns NULL, the default
> > rtl_hooks.gen_lowpart_no_emit hook returns the original value, which is not
> > of the desired mode.  I bet in most passes for real insns such rtx is then
> > meant to fail recog and thrown away, but for DEBUG_INSN modification that
> > doesn't work, since there is no verification (but also e.g. any kind of
> > SUBREG is fine).  So we can e.g. end up with a (plus:SI (mem:DI ...) 
> > (mem:SI ...))
> > or similar and then various passes (in this testcase on s390x reload) can be
> > very upset about that.
> 
> Makes sense, and it could even be a wrong-code bug for this simplification:

Richi reported another related failure today.  During combine,
rtl_hooks.gen_lowpart_no_emit is the combine version, which instead of
giving up creates (clobber:MODE (const_int 0)).  This is slightly less wrong
than what the general hook did, but still dwarf2out would ICE when seeing
that (with checking, without it just not provide location info).
We can easily emit the SUBREG though (e.g. var-tracking itself also calls
gen_rtx_raw_SUBREG as last resort) in the DEBUG_INSN operands.

Bootstrapped/regtested on x86_64-linux and i686-linux (and on the testcase
using -> powerpc64-linux cross), ok for trunk?

2012-12-18  Jakub Jelinek  

PR debug/55730
* dwarf2out.c (mem_loc_descriptor): Ignore CLOBBER.
* valtrack.c (gen_lowpart_for_debug): New function.
(propagate_for_debug): Temporarily set rtl_hooks.gen_lowpart_no_emit
to gen_lowpart_for_debug.

* gcc.dg/debug/pr55730.c: New test.

--- gcc/dwarf2out.c.jj  2012-12-18 11:41:30.0 +0100
+++ gcc/dwarf2out.c 2012-12-18 16:38:26.925380294 +0100
@@ -12714,6 +12714,7 @@ mem_loc_descriptor (rtx rtl, enum machin
 case CONST_VECTOR:
 case CONST_FIXED:
 case CLRSB:
+case CLOBBER:
   /* If delegitimize_address couldn't do anything with the UNSPEC, we
 can't express it in the debug info.  This can happen e.g. with some
 TLS UNSPECs.  */
--- gcc/valtrack.c.jj   2012-11-05 15:02:17.0 +0100
+++ gcc/valtrack.c  2012-12-18 17:15:18.499375776 +0100
@@ -29,6 +29,24 @@ along with GCC; see the file COPYING3.
 #include "regs.h"
 #include "emit-rtl.h"
 
+/* gen_lowpart_no_emit hook implementation for DEBUG_INSNs.  In DEBUG_INSNs,
+   all lowpart SUBREGs are valid, despite what the machine requires for
+   instructions.  */
+
+static rtx
+gen_lowpart_for_debug (enum machine_mode mode, rtx x)
+{
+  rtx result = gen_lowpart_if_possible (mode, x);
+  if (result)
+return result;
+
+  if (GET_MODE (x) != VOIDmode)
+return gen_rtx_raw_SUBREG (mode, x,
+  subreg_lowpart_offset (mode, GET_MODE (x)));
+
+  return NULL_RTX;
+}
+
 /* Replace auto-increment addressing modes with explicit operations to access
the same addresses without modifying the corresponding registers.  */
 
@@ -158,6 +176,7 @@ propagate_for_debug (rtx insn, rtx last,
 basic_block this_basic_block)
 {
   rtx next, loc, end = NEXT_INSN (BB_END (this_basic_block));
+  rtx (*saved_rtl_hook_no_emit) (enum machine_mode, rtx);
 
   struct rtx_subst_pair p;
   p.to = src;
@@ -165,6 +184,8 @@ propagate_for_debug (rtx insn, rtx last,
 
   next = NEXT_INSN (insn);
   last = NEXT_INSN (last);
+  saved_rtl_hook_no_emit = rtl_hooks.gen_lowpart_no_emit;
+  rtl_hooks.gen_lowpart_no_emit = gen_lowpart_for_debug;
   while (next != last && next != end)
 {
   insn = next;
@@ -179,6 +200,7 @@ propagate_for_debug (rtx insn, rtx last,
  df_insn_rescan (insn);
}
 }
+  rtl_hooks.gen_lowpart_no_emit = saved_rtl_hook_no_emit;
 }
 
 /* Initialize DEBUG to an empty list, and clear USED, if given.  */
--- gcc/testsuite/gcc.dg/debug/pr55730.c.jj 2012-12-18 17:08:29.649351676 
+0100
+++ gcc/testsuite/gcc.dg/debug/pr55730.c2012-12-18 17:08:04.0 
+0100
@@ -0,0 +1,24 @@
+/* PR debug/55730 */
+/* { dg-do compile } */
+/* { dg-options "-w" } */
+
+union U
+{
+  float f;
+  int i;
+};
+
+void
+foo (unsigned short *x, unsigned char y)
+{
+  unsigned char g;
+  union U u;
+  if (u.i < 0)
+g = 0;
+  else
+{
+  u.f = u.f * (255.0F / 256.0F) + 32768.0F;
+  g = (unsigned char) u.i;
+}
+  *x = (g << 8) | y;
+}

Jakub


Re: [PATCH][ARM][3/3] Add vectorization support for rounding functions

2012-12-18 Thread Mike Stump
On Dec 18, 2012, at 5:33 AM, Kyrylo Tkachov  wrote:
> This patch adds arm and v8 NEON to the effective target checks that are used
> in the rounding functions vectorisation tests.

For testsuite port follow ons that follow in the same exact footsteps of 
previous port work, I'm fine with you just committing as obvious if you'd like…

Since I looked at it, Ok.


RE: [PATCH][Cilkplus] Fix pragma simd info being lost

2012-12-18 Thread Iyer, Balaji V


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Friday, December 14, 2012 12:09 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH][Cilkplus] Fix pragma simd info being lost
> 
> On Fri, Dec 14, 2012 at 05:01:48PM +, Iyer, Balaji V wrote:
> > > Why do you think fatal_error is the right thing here?  Why doesn't
> > > normal error work?  Generally, if one function contains 10 #pragma
> > > simd loops that require vectorization and 5 out of them aren't
> > > vectorized, it is nicer for users to be told about all 5 of them, rather 
> > > than just
> the first one.
> > > fatal_error will exit immediately.
> >
> > The #pragma simd assert requires the compiler to halt compilation if
> > the loop is not vectorized.  This is why I used fatal_error.  The
> > default case is noassert.
> 
> The compilation is halted even with error, compiler will exit with non-zero 
> exit
> status, won't compile any further functions, etc.

Here is a patch where I have replaced all fatal_errors with error_at.

Thanks,

Balaji V. Iyer.

> 
>   Jakub
Index: gcc/ChangeLog.cilkplus
===
--- gcc/ChangeLog.cilkplus  (revision 194585)
+++ gcc/ChangeLog.cilkplus  (working copy)
@@ -1,3 +1,11 @@
+2012-12-18  Balaji V. Iyer  
+
+   * tree-vect-loop.c (vect_determine_vectorization_factor): Replaced all
+   occurances of "fatal_error" with error_at with vect_location.
+   (vect_analyze_loop_form): Likewise.
+   (vect_analyze_loop_operations): Likewise.
+   (vect_analyze_loop): Likewise.
+
 2012-12-16  Balaji V. Iyer  
 
* tree.h (GTY): Added new field in struct called "decl_auto."
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 194585)
+++ gcc/tree-vect-loop.c(working copy)
@@ -233,10 +233,8 @@
}
  if (flag_enable_cilk && pragma_simd_assert_requested_p
  (loop->pragma_simd_index))
-   {
- fatal_error ("Loop not vectorized. " 
-  "Exiting as requested by Pragma SIMD");
-   }
+   error_at (vect_location, "loop not vectorized. " 
+ "Exiting as requested by Pragma SIMD");
  return false;
}
  /* here we set the linear info */
@@ -411,10 +409,8 @@
}
  if (flag_enable_cilk && pragma_simd_assert_requested_p 
  (loop->pragma_simd_index))
-   {
- fatal_error ("Loop not vectorized. " 
-  "Exiting as requested by PRAGMA SIMD");
-   }
+   error_at (vect_location, "loop not vectorized. " 
+ "Exiting as requested by PRAGMA SIMD");
  return false;
}
 
@@ -428,10 +424,8 @@
}
  if (flag_enable_cilk && pragma_simd_assert_requested_p 
  (loop->pragma_simd_index))
-   {
- fatal_error ("Loop not vectorized. " 
-  "Exiting as requested by PRAGMA SIMD");
-   }
+   error_at (vect_location, "loop not vectorized. " 
+ "Exiting as requested by PRAGMA SIMD");
  return false;
}
 
@@ -468,11 +462,9 @@
  scalar_type);
}
  if (flag_enable_cilk && pragma_simd_assert_requested_p 
- (loop->pragma_simd_index))
-   {
- fatal_error ("Loop not vectorized. " 
-  "Exiting as requested by PRAGMA SIMD");
-   }
+ (loop->pragma_simd_index)) 
+   error_at (vect_location, "loop not vectorized. " 
+ "Exiting as requested by PRAGMA SIMD");   
  return false;
}
/* here we set the linear info */
@@ -517,10 +509,8 @@
}
  if (flag_enable_cilk && pragma_simd_assert_requested_p 
  (loop->pragma_simd_index))
-   {
- fatal_error ("Loop not vectorized. " 
-  "Exiting as requested by PRAGMA SIMD");
-   }
+   error_at (vect_location, "loop not vectorized. " 
+ "Exiting as requested by PRAGMA SIMD");
  return false;
}
 
@@ -540,10 +530,8 @@
}
  if (flag_enable_cilk && pragma_simd_assert_requested_p 
  (loop->pragma_simd_index))
-   {
- fatal_error ("Loop not vectorized. " 
-

Re: [PATCH] PR go/55201: Link libgo against libatomic

2012-12-18 Thread Ian Lance Taylor
On Tue, Dec 18, 2012 at 9:11 AM, Matthias Klose  wrote:
> Am 18.12.2012 15:28, schrieb Ian Lance Taylor:
>> On Mon, Dec 17, 2012 at 2:26 PM, Andreas Schwab  
>> wrote:
>>> Since libgo uses 8-byte atomic operations it needs to link against
>>> libatomic.  Tested on m68k-linux and powerpc-linux.
>>>
>>> Andreas.
>>>
>>> PR go/55201
>>> * Makefile.def (all-target-libgo): Depend on all-target-libatomic.
>>> * Makefile.in: Regenerate.
>>>
>>> testsuite/:
>>> * lib/go.exp (go_link_flags): Add libatomic location to flags and
>>> ld_library_path.
>>
>> Thanks.
>>
>> Committed to mainline.
>
> this seems to break make install, at least for a multilib enabled build.
>
> /usr/bin/ld: cannot find -latomic
> collect2: error: ld returned 1 exit status
> libtool: install: error: relink `libgo.la' with the above command before
> installing it
> make[10]: *** [install-toolexeclibLTLIBRARIES] Error 1
> make[10]: Leaving directory
> `/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/x86_64-linux-gnu/32/libgo'

This doesn't happen for me, and it's bizarre that libtool would turn a
link against ../libatomic/libatomic.la into a link against -latomic.
But in any case the fix is presumably going to be to add a convenience
library for libatomic, as is done for libffi.  I'll prepare a patch
for that.

Ian


Re: [PATCH] PR go/55201: Link libgo against libatomic

2012-12-18 Thread Matthias Klose
Am 18.12.2012 15:28, schrieb Ian Lance Taylor:
> On Mon, Dec 17, 2012 at 2:26 PM, Andreas Schwab  wrote:
>> Since libgo uses 8-byte atomic operations it needs to link against
>> libatomic.  Tested on m68k-linux and powerpc-linux.
>>
>> Andreas.
>>
>> PR go/55201
>> * Makefile.def (all-target-libgo): Depend on all-target-libatomic.
>> * Makefile.in: Regenerate.
>>
>> testsuite/:
>> * lib/go.exp (go_link_flags): Add libatomic location to flags and
>> ld_library_path.
> 
> Thanks.
> 
> Committed to mainline.

this seems to break make install, at least for a multilib enabled build.

/usr/bin/ld: cannot find -latomic
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libgo.la' with the above command before
installing it
make[10]: *** [install-toolexeclibLTLIBRARIES] Error 1
make[10]: Leaving directory
`/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/x86_64-linux-gnu/32/libgo'



test -z "/usr/lib/../lib32" || /bin/mkdir -p 
"/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32"
 /usr/bin/install -c -m 644  libgobegin.a 
'/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32'
 ( cd '/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32' 
&& ranlib libgobegin.a )
test -z "/usr/lib/../lib32" || /bin/mkdir -p 
"/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32"
 /bin/bash ./libtool   --mode=install /usr/bin/install -c   libgo.la 
'/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32'
libtool: install: warning: relinking `libgo.la'
libtool: install: (cd 
/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/x86_64-linux-gnu/32/libgo; 
/bin/bash 
/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/x86_64-linux-gnu/32/libgo/libtool
  --tag CC --mode=relink 
/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/./gcc/xgcc 
-B/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/./gcc/ 
-B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem 
/usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include 
-isystem /home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/sys-include -m32 
-fexceptions -fplan9-extensions -fsplit-stack -Wall -Wextra -Wwrite-strings 
-Wcast-qual -Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I ../../../../src/libgo/../libgcc -I 
../../../../src/libgo/../libbacktrace -I ../../../gcc/include -g -O2 -m32 
-version-info 3:1:0 -pthread -XCClinker -fsplit-stack -m32 -o libgo.la -rpath 
/usr/lib/../lib32 go-append.lo go-assert.lo go-assert-interface.lo 
go-byte-array-to-string.lo go-breakpoint.lo go-caller.lo go-callers.lo 
go-can-convert-interface.lo go-cgo.lo go-check-interface.lo go-construct-map.lo 
go-convert-interface.lo go-copy.lo go-defer.lo go-deferred-recover.lo 
go-eface-compare.lo go-eface-val-compare.lo go-fieldtrack.lo go-getgoroot.lo 
go-int-array-to-string.lo go-int-to-string.lo go-interface-compare.lo 
go-interface-eface-compare.lo go-interface-val-compare.lo go-make-slice.lo 
go-map-delete.lo go-map-index.lo go-map-len.lo go-map-range.lo go-matherr.lo 
go-memcmp.lo go-nanotime.lo go-now.lo go-new-map.lo go-new.lo go-nosys.lo 
go-panic.lo go-print.lo go-recover.lo go-reflect-call.lo go-reflect-map.lo 
go-rune.lo go-runtime-error.lo go-setenv.lo go-signal.lo go-strcmp.lo 
go-string-to-byte-array.lo go-string-to-int-array.lo go-strplus.lo 
go-strslice.lo go-traceback.lo go-trampoline.lo go-type-complex.lo 
go-type-eface.lo go-type-error.lo go-type-float.lo go-type-identity.lo 
go-type-interface.lo go-type-string.lo go-typedesc-equal.lo go-typestring.lo 
go-unsafe-new.lo go-unsafe-newarray.lo go-unsafe-pointer.lo go-unwind.lo 
chan.lo cpuprof.lo lfstack.lo lock_futex.lo thread-linux.lo mcache.lo 
mcentral.lo mem.lo mfinal.lo mfixalloc.lo mgc0.lo mheap.lo msize.lo panic.lo 
parfor.lo print.lo proc.lo runtime.lo signal_unix.lo thread.lo yield.lo 
iface.lo malloc.lo map.lo mprof.lo reflect.lo runtime1.lo sema.lo sigqueue.lo 
string.lo time.lo getncpu-linux.lo bufio.lo bytes.lo bytes/index.lo crypto.lo 
errors.lo expvar.lo flag.lo fmt.lo hash.lo html.lo image.lo io.lo log.lo 
math.lo mime.lo net.lo os.lo path.lo reflect-go.lo regexp.lo runtime-go.lo 
sort.lo strconv.lo strings.lo sync.lo syscall.lo syscall/errno.lo 
syscall/signame.lo syscall/wait.lo testing.lo time-go.lo unicode.lo 
archive/tar.lo archive/zip.lo compress/bzip2.lo compress/flate.lo 
compress/gzip.lo compress/lzw.lo compress/zlib.lo container/heap.lo 
container/list.lo container/ring.lo crypto/aes.lo crypto/cipher.lo 
crypto/des.lo crypto/dsa.lo crypto/ecdsa.lo crypto/elliptic.lo crypto/hmac.lo 
crypto/md5.lo crypto/rand.lo crypto/rc4.lo crypto/rsa.lo crypto/sha1.lo 
crypto/sha256.lo crypto/sha512.lo crypto/subtle.lo crypto/tls.lo cry

[PATCH] Fix up sbitmap bitmap_{and,ior,xor} (PR target/55562)

2012-12-18 Thread Jakub Jelinek
Hi!

The bitmap unification changes apparently broke at least modulo scheduling,
which used sbitmap_a_and_b_cg functions, which were replaced by bitmap_and.
But, sbitmap_a_and_b_cg asserted dst->popcount is NULL and returned whether
dst sbitmap changed, but bitmap_and returns always false if dst->popcount is
NULL (and only if it is non-NULL returns if the bitmap changed).

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

Alternatively we could add back separate functions that would return whether 
dest
changed for speed reasons (similarly to the old *_cg ones), and return void
from the normal ones again.  I bet most of the users don't check the return
value of these functions and thus it is useless computation.

2012-12-18  Jakub Jelinek  

PR target/55562
* sbitmap.c (bitmap_and, bitmap_xor, bitmap_ior): Return whether
dst sbitmap changed even if it doesn't have popcount.

--- gcc/sbitmap.c.jj2012-11-02 09:01:54.0 +0100
+++ gcc/sbitmap.c   2012-12-18 14:29:13.695299294 +0100
@@ -434,28 +434,26 @@ bitmap_and (sbitmap dst, const_sbitmap a
   const_sbitmap_ptr bp = b->elms;
   bool has_popcount = dst->popcount != NULL;
   unsigned char *popcountp = dst->popcount;
-  bool anychange = false;
+  SBITMAP_ELT_TYPE changed = 0;
 
   for (i = 0; i < n; i++)
 {
   const SBITMAP_ELT_TYPE tmp = *ap++ & *bp++;
+  SBITMAP_ELT_TYPE wordchanged = *dstp ^ tmp;
   if (has_popcount)
{
- bool wordchanged = (*dstp ^ tmp) != 0;
  if (wordchanged)
-   {
- *popcountp = do_popcount (tmp);
- anychange = true;
-   }
+   *popcountp = do_popcount (tmp);
  popcountp++;
}
   *dstp++ = tmp;
+  changed |= wordchanged;
 }
 #ifdef BITMAP_DEBUGGING
   if (has_popcount)
 sbitmap_verify_popcount (dst);
 #endif
-  return anychange;
+  return changed != 0;
 }
 
 /* Set DST to be (A xor B)).
@@ -470,28 +468,26 @@ bitmap_xor (sbitmap dst, const_sbitmap a
   const_sbitmap_ptr bp = b->elms;
   bool has_popcount = dst->popcount != NULL;
   unsigned char *popcountp = dst->popcount;
-  bool anychange = false;
+  SBITMAP_ELT_TYPE changed = 0;
 
   for (i = 0; i < n; i++)
 {
   const SBITMAP_ELT_TYPE tmp = *ap++ ^ *bp++;
+  SBITMAP_ELT_TYPE wordchanged = *dstp ^ tmp;
   if (has_popcount)
{
- bool wordchanged = (*dstp ^ tmp) != 0;
  if (wordchanged)
-   {
- *popcountp = do_popcount (tmp);
- anychange = true;
-   }
+   *popcountp = do_popcount (tmp);
  popcountp++;
}
   *dstp++ = tmp;
+  changed |= wordchanged;
 }
 #ifdef BITMAP_DEBUGGING
   if (has_popcount)
 sbitmap_verify_popcount (dst);
 #endif
-  return anychange;
+  return changed != 0;
 }
 
 /* Set DST to be (A or B)).
@@ -506,28 +502,26 @@ bitmap_ior (sbitmap dst, const_sbitmap a
   const_sbitmap_ptr bp = b->elms;
   bool has_popcount = dst->popcount != NULL;
   unsigned char *popcountp = dst->popcount;
-  bool anychange = false;
+  SBITMAP_ELT_TYPE changed = 0;
 
   for (i = 0; i < n; i++)
 {
   const SBITMAP_ELT_TYPE tmp = *ap++ | *bp++;
+  SBITMAP_ELT_TYPE wordchanged = *dstp ^ tmp;
   if (has_popcount)
{
- bool wordchanged = (*dstp ^ tmp) != 0;
  if (wordchanged)
-   {
- *popcountp = do_popcount (tmp);
- anychange = true;
-   }
+   *popcountp = do_popcount (tmp);
  popcountp++;
}
   *dstp++ = tmp;
+  changed |= wordchanged;
 }
 #ifdef BITMAP_DEBUGGING
   if (has_popcount)
 sbitmap_verify_popcount (dst);
 #endif
-  return anychange;
+  return changed != 0;
 }
 
 /* Return nonzero if A is a subset of B.  */

Jakub


Re: [PATCH][ARM] Add support for Cortex-A7 to GCC -mcpu=native option.

2012-12-18 Thread Richard Earnshaw

On 18/12/12 13:38, Kyrylo Tkachov wrote:

Hi all,
This one-line patch adds support for Cortex A-7 to the -mcpu=native option.

Ok for trunk?

No regressions on arm-none-eabi.

Thanks,
Kyrill

gcc/ChangeLog

2012-12-18  Kyrylo Tkachov  

* config/arm/driver-arm.c (arm_cpu_table):
 Add Cortex-A7.



OK.

R.




Re: [AARCH64] Fix warning in aarch64.md

2012-12-18 Thread Richard Earnshaw

On 18/12/12 14:07, James Greenhalgh wrote:


Hi,

This obvious patch fixes the following warnings I see when building for
AArch64.

gcc/config/aarch64/aarch64.md:840: warning: source missing a mode?
gcc/config/aarch64/aarch64.md:840: warning: source missing a mode?

I've tested on aarch64-none-elf with no regressions and the patch
clears the warnings.

Is this OK to commit?



OK.

R.




Re: [AArch64] Fix some warnings about unused variables.

2012-12-18 Thread Richard Earnshaw

On 18/12/12 14:02, James Greenhalgh wrote:

Hi,

This straightforward patch fixes the following warnings I see when building
for AArch64.

gcc/config/aarch64/aarch64.c:6385:7: warning: unused variable ‘reg’ 
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6385:12: warning: unused variable ‘mem’ 
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6385:17: warning: unused variable ‘addr’ 
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6386:7: warning: unused variable ‘load’ 
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6669:17: warning: variable ‘mod_s’ set but not 
used [-Wunused-but-set-variable]

Regression tested on aarch64-none-elf with no regressions and checked
to ensure that the warnings go away.

OK to commit?



OK.

R.


Thanks,
James Greenhalgh

---
gcc/

2012-12-18  James Greenhalgh  

* config/aarch64/aarch64.c (aarch64_simd_attr_length_move):
Remove unused variables.
(aarch64_split_compare_and_swap): Likewise.


0001-AArch64-Fix-some-warnings-about-unused-variables.patch


diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 09b1777..03b1361 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6382,8 +6382,6 @@ aarch64_simd_disambiguate_copy (rtx *operands, rtx *dest,
  int
  aarch64_simd_attr_length_move (rtx insn)
  {
-  rtx reg, mem, addr;
-  int load;
enum machine_mode mode;

extract_insn_cached (insn);
@@ -,7 +6664,6 @@ aarch64_split_compare_and_swap (rtx operands[])
  {
rtx rval, mem, oldval, newval, scratch;
enum machine_mode mode;
-  enum memmodel mod_s;
bool is_weak;
rtx label1, label2, x, cond;

@@ -6675,7 +6672,6 @@ aarch64_split_compare_and_swap (rtx operands[])
oldval = operands[2];
newval = operands[3];
is_weak = (operands[4] != const0_rtx);
-  mod_s = (enum memmodel) INTVAL (operands[5]);
scratch = operands[7];
mode = GET_MODE (mem);







Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-18 Thread Jakub Jelinek
On Tue, Dec 18, 2012 at 05:28:09PM +0100, Jakub Jelinek wrote:
> On Tue, Dec 18, 2012 at 04:40:10PM +0100, Tobias Burnus wrote:
> > Looks mostly okay, however, I fear that for
> > 
> > subroutine foo()
> > character(len=:), allocatable :: str
> > allocate(str, stat=istat)
> > end subroutine foo
> > 
> > compiled with "-fno-automatic", gfortran will still generate the
> > non-GFC_PREFIX-mangled string.
> 
> That doesn't compile:
> Error: Allocate-object at (1) with a deferred type parameter requires either 
> a type-spec or SOURCE tag or a MOLD tag
> 
> Where would be TREE_STATIC set on the length variable with -fno-automatic,
> and on which testcase?

subroutine foo(n)
integer :: n
character(len=n + 8), allocatable :: str
allocate(str, stat=istat)
end subroutine foo

compiles with -fno-automatic, but the length var (unlike str var) is clearly
not TREE_STATIC in that case:

.local  str.1877
.comm   str.1877,8,8
...
.uleb128 0x5# (DIE (0x71) DW_TAG_variable)
.ascii "str\0"  # DW_AT_name
.byte   0x1 # DW_AT_decl_file (x.f90)
.byte   0x3 # DW_AT_decl_line
.long   0xc2# DW_AT_type
.uleb128 0x9# DW_AT_location
.byte   0x3 # DW_OP_addr
.quad   str.1877
.uleb128 0x6# (DIE (0x86) DW_TAG_variable)
.long   .LASF5  # DW_AT_name: ".str"
.long   0xb6# DW_AT_type
# DW_AT_artificial
.uleb128 0x2# DW_AT_location
.byte   0x91# DW_OP_fbreg
.sleb128 -36

(and as can be seen, the dot name makes it through into debug info, but not
assembly outside of DW_AT_name).

Jakub


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-18 Thread Jakub Jelinek
On Tue, Dec 18, 2012 at 04:40:10PM +0100, Tobias Burnus wrote:
> Looks mostly okay, however, I fear that for
> 
> subroutine foo()
> character(len=:), allocatable :: str
> allocate(str, stat=istat)
> end subroutine foo
> 
> compiled with "-fno-automatic", gfortran will still generate the
> non-GFC_PREFIX-mangled string.

That doesn't compile:
Error: Allocate-object at (1) with a deferred type parameter requires either a 
type-spec or SOURCE tag or a MOLD tag

Where would be TREE_STATIC set on the length variable with -fno-automatic,
and on which testcase?

Jakub


Re: [PATCH] Function Multiversioning Bug, checking for function versions

2012-12-18 Thread Diego Novillo

On 2012-11-16 14:55 , Sriraman Tallam wrote:

Hi,

The previous patch was incomplete because the front-end strips off
invalid target attributes which I did not consider. The attached
updated patch handles this with updated test cases.

Thanks,
-Sri.

On Thu, Nov 15, 2012 at 2:08 PM, Sriraman Tallam  wrote:

Hi,

Currently, function multiversioning determines that two functions
are different by comparing the arch type and isa flags that are set
after the target string is processed. This leads to cases where  the
versions become identical when the command-line target options are
altered.

For example, these two versions:

__attribute__ target (("sse4.2")))
int foo ()
{
}

__attribute__ target (("popcnt")))
int foo ()
{
}

become identical when -mpopcnt and -msse4.2 are used while building,
leading to build errors.

To avoid this, I have modified the function version determination to
just compare the target string.
Patch attached. Is this alright to submit?

Thanks,
-Sri.


* doc/tm.texi.in (TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS): Document
new target hook.
* doc/tm.texi: Regenerate.
* c-family/c-common.c (handle_target_attribute): Retain target attribute
for targets that support versioning.
* target.def (supports_function_versions): New hook.
* config/i386/i386.c (ix86_function_versions): Use target string
to check for function versions instead of target flags.
* testsuite/g++.dg/mv1.C: Remove target options.
* testsuite/g++.dg/mv2.C: Ditto.
* testsuite/g++.dg/mv3.C: Ditto.
* testsuite/g++.dg/mv4.C: Ditto.
* testsuite/g++.dg/mv5.C: Ditto.
* cp/class.c (add_method): Remove calls
to DECL_FUNCTION_SPECIFIC_TARGET.
* config/i386/i386.c (ix86_function_versions): Use target string
to check for function versions instead of target flags.
* (ix86_supports_function_versions): New function.
* (is_function_default_version): Check target string.
* TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS: New macro.



Looks mostly OK.


Index: cp/class.c
===
--- cp/class.c  (revision 193486)
+++ cp/class.c  (working copy)
@@ -1095,8 +1095,6 @@ add_method (tree type, tree method, tree using_dec
  && TREE_CODE (method) == FUNCTION_DECL
  && !DECL_EXTERN_C_P (fn)
  && !DECL_EXTERN_C_P (method)
- && (DECL_FUNCTION_SPECIFIC_TARGET (fn)
- || DECL_FUNCTION_SPECIFIC_TARGET (method))


I don't follow.  Given the new hook, why do you need to remove this check?


+/* This function returns true if FN1 and FN2 are versions of the same function,
+   that is, the target strings of the function decls are different.  This 
assumes
+   that FN1 and FN2 have the same signature.  */
+
+static bool
+ix86_function_versions (tree fn1, tree fn2)
+{


Any particular reason why you moved this function down here?


+  tree attr1, attr2;
+  const char *attr_str1, *attr_str2;
+  char *target1, *target2;
+  bool result;
+
+  if (TREE_CODE (fn1) != FUNCTION_DECL
+  || TREE_CODE (fn2) != FUNCTION_DECL)
+return false;
+
+  attr1 = lookup_attribute ("target", DECL_ATTRIBUTES (fn1));
+  attr2 = lookup_attribute ("target", DECL_ATTRIBUTES (fn2));
+
+  /* Atleast one function decl should have the target attribute specified.  */


s/Atleast/At least/


Diego.


Re: PR other/54324: allow bootstrapping with older compilers

2012-12-18 Thread Richard Biener
On Tue, 18 Dec 2012, Aldy Hernandez wrote:

> On 12/12/12 03:33, Richard Biener wrote:
> > On Tue, 11 Dec 2012, Aldy Hernandez wrote:
> > > 4. Type checking as part of a `for' initializer segfaults on g++ 3.2:
> > > 
> > >   for (type = TYPE_MAIN_VARIANT (blah); )
> > > 
> > > The only reasonable thing I could think of, was disabling the tree
> > > checking code for older compilers.
> 
> > blocker anyway.  For 4. I think we should simply document that
> > you need to build with --disable-stage1-checking (it's one case that
> > hints at we don't want to support 3.2 - does 3.3 work here?  With
> > our SLE9 gcc 3.3 hammer branch based compiler I get even some more
> > ICEs).
> 
> Hi Richard.
> 
> Attached is a patch documenting --disable-stage1-checking for older GCC's with
> a suggested discouragement.
> 
> OK for trunk?

Ok.

Thanks,
Richard.


Re: PR other/54324: allow bootstrapping with older compilers

2012-12-18 Thread Aldy Hernandez

On 12/12/12 03:33, Richard Biener wrote:

On Tue, 11 Dec 2012, Aldy Hernandez wrote:

4. Type checking as part of a `for' initializer segfaults on g++ 3.2:

for (type = TYPE_MAIN_VARIANT (blah); )

The only reasonable thing I could think of, was disabling the tree
checking code for older compilers.



blocker anyway.  For 4. I think we should simply document that
you need to build with --disable-stage1-checking (it's one case that
hints at we don't want to support 3.2 - does 3.3 work here?  With
our SLE9 gcc 3.3 hammer branch based compiler I get even some more
ICEs).


Hi Richard.

Attached is a patch documenting --disable-stage1-checking for older 
GCC's with a suggested discouragement.


OK for trunk?

commit da7964f82e42499dde24e7029b4454637ae68e85
Author: Aldy Hernandez 
Date:   Tue Dec 18 09:55:39 2012 -0600

PR other/54324
* doc/install.texi (Tools/packages necessary for building GCC):
Suggest --disable-stage1-checking for older GCC's.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index e534216..8273a87 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -254,6 +254,11 @@ To build all languages in a cross-compiler or other 
configuration where
 GCC binary (version 3.4 or later) because source code for language
 frontends other than C might use GCC extensions.
 
+Note that to bootstrap GCC with versions of GCC earlier than 3.4, you
+may need to use @option{--disable-stage1-checking}, though
+bootstrapping the compiler with such earlier compilers is strongly
+discouraged.
+
 @item GNAT
 
 In order to build the Ada compiler (GNAT) you must already have GNAT


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-18 Thread Tobias Burnus

Jakub Jelinek wrote:

So, what about this version instead?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-12-11  Jakub Jelinek
Janus Weil

PR fortran/55636
* gfortran.h (GFC_PREFIX): Define.
* trans-decl.c (gfc_create_string_length): For VAR_DECLs that
will be TREE_STATIC, use GFC_PREFIX to mangle the names.

…

/* Also prefix the mangled name.  */
-  if (sym->module)
+  if (sym->attr.save || sym->ns->proc_name->attr.flavor == FL_MODULE)
+   {
+ if (sym->module)
+   name = gfc_get_string (GFC_PREFIX ("%s_MOD_%s"), sym->module,
+  sym->name);
+ else
+   name = gfc_get_string (GFC_PREFIX ("%s"), sym->name);
+   }
+  else if (sym->module)
name = gfc_get_string (".__%s_MOD_%s", sym->module, sym->name);
else
name = gfc_get_string (".%s", sym->name);


Looks mostly okay, however, I fear that for

subroutine foo()
character(len=:), allocatable :: str
allocate(str, stat=istat)
end subroutine foo

compiled with "-fno-automatic", gfortran will still generate the 
non-GFC_PREFIX-mangled string.


"-fno-automatic" implies SAVE / static memory and is required by some 
old code. Hence, it is unlikely to be used with new code; still, 
gfortran should get this right. (Actually, as PR55733 shows, there are 
issues beyond the mangling with -fno-automatic for deferred-length 
strings/scalar allocatables).


Thus, I wonder whether one should always use GFC_PREFIX. On the other 
hand, for scan-tree-dump, it is nice to have a single mangling instead 
of 3 different ones. (Though, currently, no scan-tree-dump seems to be 
used in this case.)


Hence:

OK with either always using GFC_PREFIX – or with an additional "&& 
gfc_option.flag_max_stack_var_size == 0" check and a comment why the 
mangling is done.


Tobias


Re: [RFA] .gitignore: Ignore *.pyc files.

2012-12-18 Thread Joel Brobecker
Ping. This patch seems fairly straightforward to the point of
being almost obvious, but so far, no review (beyond one email
expressing interest).

Thanks!


> The GDB sources contain some python files, and executing them
> causes these .pyc files to appear.  We could ignore them in GDB
> only, but I think this is the type of extension (compilation
> artifact) which can be shared amoung all projects.
> 
> ChangeLog:
> 
> * .gitignore: Ignore *.pyc file.
> 
> Ok to apply?
> Thanks,
> -- 
> Joel
> 
> ---
>  .gitignore |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.gitignore b/.gitignore
> index dc1bf3f..8e2e1e9 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -12,6 +12,7 @@
>  *.la
>  *.lo
>  *.o
> +*.pyc
>  *.tmp
>  
>  .deps
> -- 
> 1.7.10.4

-- 
Joel


PR other/54324: remove template parameter

2012-12-18 Thread Aldy Hernandez

As discussed earlier, removing the  brings happiness to older g++'s.

Committed as obvious, per your previous comment.
commit 5d215dbbe1c37aaf98307cb71d250222fb802114
Author: Aldy Hernandez 
Date:   Tue Dec 18 09:21:28 2012 -0600

PR other/54324
* tree-ssa-coalesce.c (struct ssa_name_var_hash): Remove "union"
from template parameter.

diff --git a/gcc/tree-ssa-coalesce.c b/gcc/tree-ssa-coalesce.c
index ce04fdf..47eba97 100644
--- a/gcc/tree-ssa-coalesce.c
+++ b/gcc/tree-ssa-coalesce.c
@@ -1259,7 +1259,7 @@ coalesce_partitions (var_map map, ssa_conflicts_p graph, 
coalesce_list_p cl,
 
 /* Hashtable support for storing SSA names hashed by their SSA_NAME_VAR.  */
 
-struct ssa_name_var_hash : typed_noop_remove 
+struct ssa_name_var_hash : typed_noop_remove 
 {
   typedef union tree_node value_type;
   typedef union tree_node compare_type;


PR other/54324: Do not set __attribute__ for GCC < 3.4

2012-12-18 Thread Aldy Hernandez
As discussed in the thread entitled "allow bootstrapping with older 
compilers", this patch disallows __attribute__ for GCC < 3.4.


Applied as obvious, as you mentioned in the other thread.

Thanks.
commit 370a6a8ddc628924c1deedf752ea9fc9a058d5cc
Author: Aldy Hernandez 
Date:   Tue Dec 18 09:13:48 2012 -0600

PR other/54324
* ansidecl.h (ATTRIBUTE_UNUSED): Do not set __attribute__ for GCC
< 3.4.

diff --git a/include/ansidecl.h b/include/ansidecl.h
index 23d85bf..40f4a5f 100644
--- a/include/ansidecl.h
+++ b/include/ansidecl.h
@@ -279,8 +279,15 @@ So instead we use the macro below and test it against 
specific values.  */
 # endif
 #endif
 
+/* Similarly to ARG_UNUSED below.  Prior to GCC 3.4, the C++ frontend
+   couldn't parse attributes placed after the identifier name, and now
+   the entire compiler is built with C++.  */
 #ifndef ATTRIBUTE_UNUSED
-#define ATTRIBUTE_UNUSED __attribute__ ((__unused__))
+#if GCC_VERSION >= 3004
+#  define ATTRIBUTE_UNUSED __attribute__ ((__unused__))
+#else
+#define ATTRIBUTE_UNUSED
+#endif
 #endif /* ATTRIBUTE_UNUSED */
 
 /* Before GCC 3.4, the C++ frontend couldn't parse attributes placed after the


Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2012-12-18 Thread Christian Bruel


On 12/18/2012 03:47 PM, Jakub Jelinek wrote:
> On Tue, Dec 18, 2012 at 03:41:58PM +0100, Christian Bruel wrote:
>> Canadian Cross Builds fail to build libgcc/unwind-dw2.c
>>
>> ...
>> ../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
>> file or directory
>> ...
>>
>> when the build machine has sys/sdt.h installed (systemtap-sdt-devel),
>> but not the target's, because of this:
>>
>> #ifdef HAVE_SYS_SDT_H
>> #include 
>> #endif
>>
>> This appears to be because auto-host.h unconditionally defines
>> HAVE_SYS_SDT_H from config.in, that should be guarded with #ifndef
>> USED_FOR_TARGET
>>
>> This patch changes the sys/sdt.h detection to the standard macro to
>> correctly generate it. And need to regenerate configure and config.in.
>>
>> Checked for x86 native boostrap OK and SH4-linux Cross and Native builds
>> on host (with and without systemtap host header installed)
>>
>> OK for trunk ?
> 
> That doesn't look like a correct fix.  If HAVE_SYS_SDT_H define is always
> guarded with #ifndef USED_FOR_TARGET, then it will never be used in the
> target unwind-dw2.c where it is supposed to be used if available.
> The configury snippet was clearly looking for target sys/sdt.h header:
> if test -f $target_header_dir/sys/sdt.h; then
>   have_sys_sdt_h=yes
> 

Well, it should be used by unwind-dw2.c, because we have

#include "tconfig.h"

that includes it:

#ifndef GCC_TCONFIG_H
#define GCC_TCONFIG_H
#ifndef USED_FOR_TARGET
# define USED_FOR_TARGET
#endif
#include "auto-host.h"

in which there is :

#ifndef USED_FOR_TARGET
#define HAVE_SYS_SDT_H 1
#endif

So HAVE_SYS_SDT will be defined in unwind-dw2.c on system that need it.

> so the question is why it found a host header instead in your case.

This is for everyone. The auto-host.h is used commonly for the target,
unded the definition of 'USED_FOR_TARGET'

Cheers

Christian

> 
>   Jakub
> 


Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2012-12-18 Thread Jakub Jelinek
On Tue, Dec 18, 2012 at 03:41:58PM +0100, Christian Bruel wrote:
> Canadian Cross Builds fail to build libgcc/unwind-dw2.c
> 
> ...
> ../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
> file or directory
> ...
> 
> when the build machine has sys/sdt.h installed (systemtap-sdt-devel),
> but not the target's, because of this:
> 
> #ifdef HAVE_SYS_SDT_H
> #include 
> #endif
> 
> This appears to be because auto-host.h unconditionally defines
> HAVE_SYS_SDT_H from config.in, that should be guarded with #ifndef
> USED_FOR_TARGET
> 
> This patch changes the sys/sdt.h detection to the standard macro to
> correctly generate it. And need to regenerate configure and config.in.
> 
> Checked for x86 native boostrap OK and SH4-linux Cross and Native builds
> on host (with and without systemtap host header installed)
> 
> OK for trunk ?

That doesn't look like a correct fix.  If HAVE_SYS_SDT_H define is always
guarded with #ifndef USED_FOR_TARGET, then it will never be used in the
target unwind-dw2.c where it is supposed to be used if available.
The configury snippet was clearly looking for target sys/sdt.h header:
if test -f $target_header_dir/sys/sdt.h; then
  have_sys_sdt_h=yes

so the question is why it found a host header instead in your case.

Jakub


[PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2012-12-18 Thread Christian Bruel
Hello,

Canadian Cross Builds fail to build libgcc/unwind-dw2.c

...
../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
file or directory
...

when the build machine has sys/sdt.h installed (systemtap-sdt-devel),
but not the target's, because of this:

#ifdef HAVE_SYS_SDT_H
#include 
#endif

This appears to be because auto-host.h unconditionally defines
HAVE_SYS_SDT_H from config.in, that should be guarded with #ifndef
USED_FOR_TARGET

This patch changes the sys/sdt.h detection to the standard macro to
correctly generate it. And need to regenerate configure and config.in.

Checked for x86 native boostrap OK and SH4-linux Cross and Native builds
on host (with and without systemtap host header installed)

OK for trunk ?

Thanks,

Christian
2012-12-18  Christian Bruel  

	* configure.ac: Check sys/sdt.h with AC_CHECK_HEADERS.
	* configure: Regenerate.
	* config.in: Regenerat.e

Index: gcc/configure
===
--- gcc/configure	(revision 194574)
+++ gcc/configure	(working copy)
@@ -8286,7 +8286,7 @@ fi
 
 for ac_header in limits.h stddef.h string.h strings.h stdlib.h time.h iconv.h \
 		 fcntl.h unistd.h sys/file.h sys/time.h sys/mman.h \
-		 sys/resource.h sys/param.h sys/times.h sys/stat.h \
+		 sys/resource.h sys/param.h sys/times.h sys/sdt.h sys/stat.h \
 		 direct.h malloc.h langinfo.h ldfcn.h locale.h wchar.h libintl.h
 do :
   as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
@@ -26716,20 +26716,6 @@ $as_echo "#define TARGET_LIBC_PROVIDES_SSP 1" >>co
 
 fi
 
-# Test for  on the target.
-
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking sys/sdt.h in the target C library" >&5
-$as_echo_n "checking sys/sdt.h in the target C library... " >&6; }
-have_sys_sdt_h=no
-if test -f $target_header_dir/sys/sdt.h; then
-  have_sys_sdt_h=yes
-
-$as_echo "#define HAVE_SYS_SDT_H 1" >>confdefs.h
-
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $have_sys_sdt_h" >&5
-$as_echo "$have_sys_sdt_h" >&6; }
-
 # Check if TFmode long double should be used by default or not.
 # Some glibc targets used DFmode long double, but with glibc 2.4
 # and later they can use TFmode.
Index: gcc/config.in
===
--- gcc/config.in	(revision 194574)
+++ gcc/config.in	(working copy)
@@ -266,12 +266,6 @@
 #endif
 
 
-/* Define if your assembler supports SPARC4 instructions. */
-#ifndef USED_FOR_TARGET
-#undef HAVE_AS_SPARC4
-#endif
-
-
 /* Define if your assembler supports fprnd. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_FPRND
@@ -477,6 +471,12 @@
 #endif
 
 
+/* Define if your assembler supports SPARC4 instructions. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_SPARC4
+#endif
+
+
 /* Define if your assembler and linker support GOTDATA_OP relocs. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_SPARC_GOTDATA_OP
@@ -1228,7 +1228,7 @@
 #endif
 
 
-/* Define if your PowerPC64 linker supports a large TOC. */
+/* Define if your AIX linker supports a large TOC. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_LD_LARGE_TOC
 #endif
@@ -1470,9 +1470,12 @@
 #endif
 
 
-/* Define if your target C library provides sys/sdt.h */
+/* Define to 1 if you have the  header file. */
+#ifndef USED_FOR_TARGET
 #undef HAVE_SYS_SDT_H
+#endif
 
+
 /* Define to 1 if you have the  header file. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_SYS_STAT_H
Index: gcc/configure.ac
===
--- gcc/configure.ac	(revision 194574)
+++ gcc/configure.ac	(working copy)
@@ -940,7 +940,7 @@ ACX_HEADER_STRING
 AC_HEADER_SYS_WAIT
 AC_CHECK_HEADERS(limits.h stddef.h string.h strings.h stdlib.h time.h iconv.h \
 		 fcntl.h unistd.h sys/file.h sys/time.h sys/mman.h \
-		 sys/resource.h sys/param.h sys/times.h sys/stat.h \
+		 sys/resource.h sys/param.h sys/times.h sys/sdt.h sys/stat.h \
 		 direct.h malloc.h langinfo.h ldfcn.h locale.h wchar.h libintl.h)
 
 # Check for thread headers.
@@ -4718,17 +4718,6 @@ if test x$gcc_cv_libc_provides_ssp = xyes; then
 	[Define if your target C library provides stack protector support])
 fi
 
-# Test for  on the target.
-GCC_TARGET_TEMPLATE([HAVE_SYS_SDT_H])
-AC_MSG_CHECKING(sys/sdt.h in the target C library)
-have_sys_sdt_h=no
-if test -f $target_header_dir/sys/sdt.h; then
-  have_sys_sdt_h=yes
-  AC_DEFINE(HAVE_SYS_SDT_H, 1,
-[Define if your target C library provides sys/sdt.h])
-fi
-AC_MSG_RESULT($have_sys_sdt_h)
-
 # Check if TFmode long double should be used by default or not.
 # Some glibc targets used DFmode long double, but with glibc 2.4
 # and later they can use TFmode.


Re: [cxx-conversion] Change tree-ssa-coalesce.c'coalesce_list_d.list to hash_table

2012-12-18 Thread Diego Novillo
On Tue, Dec 18, 2012 at 5:23 AM, Richard Biener
 wrote:

> But of course we agreed to not to translation to C++ just because it's 
> possible
> but to make the code better (in my sense better is equal to easier to
> maintain and/or understand).

This is not what this set of changes is doing.  These are the
mechanical side-effects of the new hash table design.  We are not
going to start re-writing the whole compiler by ourselves.  We have
set out to make very specific API changes and we are hoping that other
maintainers will start contributing in their own areas.

Easier to use hash tables make code easier to maintain and understand.


Diego.


[PATCH] Fix PR54838

2012-12-18 Thread Richard Biener

This fixes PR54838 by teaching fix_loop_structure to discover
that all latch edges disappeared and thus a loop is gone.
Conveniently we re-discover latch edges already, so simply move
that earlier and extend it.

The patch also properly honors LOOPS_HAVE_FALLTHRU_PREHEADERS
in fix_loop_structure and sets LOOPS_MAY_HAVE_MULTIPLE_LATCHES
in loop_optimizer_finalize to avoid excessive CFG manipulations
from fix_loop_structure calls.

Bootstrapped and tested on x86_64-unknown-linux-gnu,
profilebootstrapped with release checking on x86_64-unknown-linux-gnu.

Applied to trunk.

Richard.

2012-12-18  Richard Biener  

PR middle-end/54838
* cfgloopmanip.c (fix_loop_structure): Re-discover latch
edges first and mark loops for removal if no latch edges remain.
Properly re-create LOOPS_HAVE_FALLTHRU_PREHEADERS.
* loop-init.c (loop_optimizer_finalize): Set
LOOPS_MAY_HAVE_MULTIPLE_LATCHES.

* g++.dg/torture/pr54838.C: New testcase.

Index: gcc/cfgloopmanip.c
===
*** gcc/cfgloopmanip.c  (revision 194552)
--- gcc/cfgloopmanip.c  (working copy)
*** fix_loop_structure (bitmap changed_bbs)
*** 1793,1798 
--- 1793,1832 
record_exits = true;
  }
  
+   /* First re-compute loop latches.  */
+   FOR_EACH_LOOP (li, loop, 0)
+ {
+   edge_iterator ei;
+   edge e, first_latch = NULL, latch = NULL;
+ 
+   if (!loop->header)
+   continue;
+ 
+   FOR_EACH_EDGE (e, ei, loop->header->preds)
+   if (dominated_by_p (CDI_DOMINATORS, e->src, loop->header))
+ {
+   if (!first_latch)
+ first_latch = latch = e;
+   else
+ {
+   latch = NULL;
+   break;
+ }
+ }
+   /* If there was no latch, schedule the loop for removal.  */
+   if (!first_latch)
+   loop->header = NULL;
+   /* If there was a single latch and it belongs to the loop of the
+header, record it.  */
+   else if (latch
+  && latch->src->loop_father == loop)
+   loop->latch = latch->src;
+   /* Otherwise there are multiple latches which are eventually
+  disambiguated below.  */
+   else
+   loop->latch = NULL;
+ }
+ 
/* Remove the dead loops from structures.  We start from the innermost
   loops, so that when we remove the loops, we know that the loops inside
   are preserved, and do not waste time relinking loops that will be
*** fix_loop_structure (bitmap changed_bbs)
*** 1849,1882 
}
  }
  
-   /* Then re-compute the single latch if there is one.  */
-   FOR_EACH_LOOP (li, loop, 0)
- {
-   edge_iterator ei;
-   edge e, latch = NULL;
-   FOR_EACH_EDGE (e, ei, loop->header->preds)
-   if (dominated_by_p (CDI_DOMINATORS, e->src, loop->header))
- {
-   if (!latch)
- latch = e;
-   else
- {
-   latch = NULL;
-   break;
- }
- }
-   if (latch
- && latch->src->loop_father == loop)
-   loop->latch = latch->src;
-   else
-   loop->latch = NULL;
- }
- 
if (!loops_state_satisfies_p (LOOPS_MAY_HAVE_MULTIPLE_LATCHES))
  disambiguate_loops_with_multiple_latches ();
  
if (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS))
! create_preheaders (CP_SIMPLE_PREHEADERS);
  
if (loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES))
  force_single_succ_latches ();
--- 1883,1900 
}
  }
  
if (!loops_state_satisfies_p (LOOPS_MAY_HAVE_MULTIPLE_LATCHES))
  disambiguate_loops_with_multiple_latches ();
  
if (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS))
! {
!   int cp_flags = CP_SIMPLE_PREHEADERS;
! 
!   if (loops_state_satisfies_p (LOOPS_HAVE_FALLTHRU_PREHEADERS))
!   cp_flags |= CP_FALLTHRU_PREHEADERS;
! 
!   create_preheaders (cp_flags);
! }
  
if (loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES))
  force_single_succ_latches ();
Index: gcc/loop-init.c
===
*** gcc/loop-init.c (revision 194552)
--- gcc/loop-init.c (working copy)
*** loop_optimizer_finalize (void)
*** 133,138 
--- 133,139 
 | LOOPS_HAVE_PREHEADERS
 | LOOPS_HAVE_SIMPLE_LATCHES
 | LOOPS_HAVE_FALLTHRU_PREHEADERS);
+   loops_state_set (LOOPS_MAY_HAVE_MULTIPLE_LATCHES);
goto loop_fini_done;
  }
  
Index: gcc/testsuite/g++.dg/torture/pr54838.C
===
*** gcc/testsuite/g++.dg/torture/pr54838.C  (revision 0)
--- gcc/testsuite/g++.dg/torture/pr54838.C  (working copy)
***
*** 0 
--- 1,102 
+ // { dg-do compile }
+ // { dg-options "-ftracer -fno-tree-dce -fno-tree-sra" }
+ 
+ struct bidirecti

Re: [PATCH] PR go/55201: Link libgo against libatomic

2012-12-18 Thread Ian Lance Taylor
On Mon, Dec 17, 2012 at 2:26 PM, Andreas Schwab  wrote:
> Since libgo uses 8-byte atomic operations it needs to link against
> libatomic.  Tested on m68k-linux and powerpc-linux.
>
> Andreas.
>
> PR go/55201
> * Makefile.def (all-target-libgo): Depend on all-target-libatomic.
> * Makefile.in: Regenerate.
>
> testsuite/:
> * lib/go.exp (go_link_flags): Add libatomic location to flags and
> ld_library_path.

Thanks.

Committed to mainline.

Ian


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-18 Thread Jakub Jelinek
On Tue, Dec 11, 2012 at 09:16:53PM -0500, David Edelsohn wrote:
> > @@ -1090,7 +1090,15 @@ gfc_create_string_length (gfc_symbol * s
> >const char *name;
> >
> >/* Also prefix the mangled name.  */
> > -  if (sym->module)
> > +  if (sym->attr.save || sym->ns->proc_name->attr.flavor == FL_MODULE)
> > +   {
> > + if (sym->module)
> > +   name = gfc_get_string (GFC_PREFIX ("%s_MOD_%s"), sym->module,
> > +  sym->name);
> > + else
> > +   name = gfc_get_string (GFC_PREFIX ("%s"), sym->name);
> > +   }
> > +  else if (sym->module)
> > name = gfc_get_string (".__%s_MOD_%s", sym->module, sym->name);
> >else
> > name = gfc_get_string (".%s", sym->name);
> 
> Why are you only correcting the prefix for attr.save or FL_MODULE?
> Why leave the dot name in the other cases?

Because otherwise it is just an automatic variable, i.e. doesn't make it
into assembly in any way appart from possibly debug info DW_AT_name (where it is
desirable to have shorter names).
It could have similarly just name = NULL for those (just would make dumps
slightly less readable).

Jakub


Patch ping

2012-12-18 Thread Jakub Jelinek
Hi!

- PR c/39464 P2 -Wpointer-sign fix
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00523.html

- PR fortran/55636 P1 Fortran ABI (mangling) fix
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00726.html

- PR c++/55619 C FE changes corresponding to C++ FE changes for inline asm "m" 
constrained inputs
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00852.html

- PR debug/54402 P1 --max-vartrack-reverse-op-size=N to speed up var-tracking
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00891.html

Jakub


[AARCH64] Fix warning in aarch64.md

2012-12-18 Thread James Greenhalgh

Hi,

This obvious patch fixes the following warnings I see when building for
AArch64.

gcc/config/aarch64/aarch64.md:840: warning: source missing a mode?
gcc/config/aarch64/aarch64.md:840: warning: source missing a mode?

I've tested on aarch64-none-elf with no regressions and the patch
clears the warnings.

Is this OK to commit?

Thanks,
James Greenhalgh

---
gcc/
2012-12-18  James Greenhalgh  

* config/aarch64/aarch64.md (insv_imm): Add modes
for source operands.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index b59d53d..28f32da 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -840,8 +840,8 @@
 (define_insn "insv_imm"
   [(set (zero_extract:GPI (match_operand:GPI 0 "register_operand" "+r")
 			  (const_int 16)
-			  (match_operand 1 "const_int_operand" "n"))
-	(match_operand 2 "const_int_operand" "n"))]
+			  (match_operand:GPI 1 "const_int_operand" "n"))
+	(match_operand:GPI 2 "const_int_operand" "n"))]
   "INTVAL (operands[1]) < GET_MODE_BITSIZE (mode)
&& INTVAL (operands[1]) % 16 == 0
&& INTVAL (operands[2]) <= 0x"

[AArch64] Fix some warnings about unused variables.

2012-12-18 Thread James Greenhalgh
Hi,

This straightforward patch fixes the following warnings I see when building
for AArch64.

gcc/config/aarch64/aarch64.c:6385:7: warning: unused variable ‘reg’ 
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6385:12: warning: unused variable ‘mem’ 
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6385:17: warning: unused variable ‘addr’ 
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6386:7: warning: unused variable ‘load’ 
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6669:17: warning: variable ‘mod_s’ set but not 
used [-Wunused-but-set-variable]

Regression tested on aarch64-none-elf with no regressions and checked
to ensure that the warnings go away.

OK to commit?

Thanks,
James Greenhalgh

---
gcc/

2012-12-18  James Greenhalgh  

* config/aarch64/aarch64.c (aarch64_simd_attr_length_move):
Remove unused variables.
(aarch64_split_compare_and_swap): Likewise.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 09b1777..03b1361 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6382,8 +6382,6 @@ aarch64_simd_disambiguate_copy (rtx *operands, rtx *dest,
 int
 aarch64_simd_attr_length_move (rtx insn)
 {
-  rtx reg, mem, addr;
-  int load;
   enum machine_mode mode;
 
   extract_insn_cached (insn);
@@ -,7 +6664,6 @@ aarch64_split_compare_and_swap (rtx operands[])
 {
   rtx rval, mem, oldval, newval, scratch;
   enum machine_mode mode;
-  enum memmodel mod_s;
   bool is_weak;
   rtx label1, label2, x, cond;
 
@@ -6675,7 +6672,6 @@ aarch64_split_compare_and_swap (rtx operands[])
   oldval = operands[2];
   newval = operands[3];
   is_weak = (operands[4] != const0_rtx);
-  mod_s = (enum memmodel) INTVAL (operands[5]);
   scratch = operands[7];
   mode = GET_MODE (mem);
 

[PATCH][ARM] Add support for Cortex-A7 to GCC -mcpu=native option.

2012-12-18 Thread Kyrylo Tkachov
Hi all,
This one-line patch adds support for Cortex A-7 to the -mcpu=native option.

Ok for trunk?

No regressions on arm-none-eabi.

Thanks,
Kyrill

gcc/ChangeLog

2012-12-18  Kyrylo Tkachov  

* config/arm/driver-arm.c (arm_cpu_table):
Add Cortex-A7.diff --git a/gcc/config/arm/driver-arm.c b/gcc/config/arm/driver-arm.c
index 3e14b14..3a17e10 100644
--- a/gcc/config/arm/driver-arm.c
+++ b/gcc/config/arm/driver-arm.c
@@ -37,6 +37,7 @@ static struct vendor_cpu arm_cpu_table[] = {
 {"0xb56", "armv6t2", "arm1156t2-s"},
 {"0xb76", "armv6zk", "arm1176jz-s"},
 {"0xc05", "armv7-a", "cortex-a5"},
+{"0xc07", "armv7-a", "cortex-a7"},
 {"0xc08", "armv7-a", "cortex-a8"},
 {"0xc09", "armv7-a", "cortex-a9"},
 {"0xc0f", "armv7-a", "cortex-a15"},


[PATCH][ARM][3/3] Add vectorization support for rounding functions

2012-12-18 Thread Kyrylo Tkachov
Hi all,
This patch adds arm and v8 NEON to the effective target checks that are used
in the rounding functions vectorisation tests.
A new effective target check for NEON hardware is added This check is used
to determine
whether to do runtime tests or just compilation.

With these changes the following tests now PASS on arm instead of being
UNSUPPORTED:
* gcc.dg/vect/vect-rounding-btrunc.c
* gcc.dg/vect/vect-rounding-ceilf.c
* gcc.dg/vect/vect-rounding-floorf.c
* gcc.dg/vect/vect-rounding-roundf.c

Tested on arm-none-eabi with model and softfp float ABI.

Ok for trunk?

Thanks,
Kyrill

gcc/testuite/ChangeLog

2012-12-18  Kyrylo Tkachov  

* lib/target-supports.exp (check_effective_target_arm_v8_neon_hw):
  New procedure.
  (check_effective_target_vect_call_btruncf):
  Add check for arm and ARMv8 NEON.
  (check_effective_target_vect_call_ceilf): Likewise.
  (check_effective_target_vect_call_floorf): Likewise.
  (check_effective_target_vect_call_roundf): Likewise.
  (check_vect_support_and_set_flags): Handle ARMv8 NEON effective
target.diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index c3151ac..6789428 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2469,6 +2469,24 @@ proc check_effective_target_arm_neonv2_hw { } {
 } [add_options_for_arm_neonv2 ""]]
 }
 
+# Return 1 if the target supports executing ARMv8 NEON instructions, 0
+# otherwise.
+
+proc check_effective_target_arm_v8_neon_hw { } {
+return [check_runtime arm_v8_neon_hw_available {
+#include "arm_neon.h"
+   int
+   main (void)
+   {
+ float32x2_t a;
+ asm ("vrinta.f32 %P0, %P1"
+  : "=w" (a)
+  : "0" (a));
+ return 0;
+   }
+} [add_options_for_arm_v8_neon ""]]
+}
+
 # Return 1 if this is a ARM target with NEON enabled.
 
 proc check_effective_target_arm_neon { } {
@@ -3975,7 +3993,9 @@ proc check_effective_target_vect_call_btruncf { } {
verbose "check_effective_target_vect_call_btruncf: using cached result" 
2
 } else {
set et_vect_call_btruncf_saved 0
-   if { [istarget aarch64*-*-*] } {
+   if { [istarget aarch64*-*-*]
+|| ([istarget arm*-*-*]
+&& [check_effective_target_arm_v8_neon_ok]) } {
  set et_vect_call_btruncf_saved 1
}
 }
@@ -4011,7 +4031,9 @@ proc check_effective_target_vect_call_ceilf { } {
verbose "check_effective_target_vect_call_ceilf: using cached result" 2
 } else {
set et_vect_call_ceilf_saved 0
-   if { [istarget aarch64*-*-*] } {
+   if { [istarget aarch64*-*-*]
+|| ([istarget arm*-*-*]
+&& [check_effective_target_arm_v8_neon_ok]) } {
  set et_vect_call_ceilf_saved 1
}
 }
@@ -4047,7 +4069,9 @@ proc check_effective_target_vect_call_floorf { } {
verbose "check_effective_target_vect_call_floorf: using cached result" 2
 } else {
set et_vect_call_floorf_saved 0
-   if { [istarget aarch64*-*-*] } {
+   if { [istarget aarch64*-*-*]
+|| ([istarget arm*-*-*]
+&& [check_effective_target_arm_v8_neon_ok]) } {
  set et_vect_call_floorf_saved 1
}
 }
@@ -4155,7 +4179,9 @@ proc check_effective_target_vect_call_roundf { } {
verbose "check_effective_target_vect_call_roundf: using cached result" 2
 } else {
set et_vect_call_roundf_saved 0
-   if { [istarget aarch64*-*-*] } {
+   if { [istarget aarch64*-*-*]
+|| ([istarget arm*-*-*]
+&& [check_effective_target_arm_v8_neon_ok]) } {
  set et_vect_call_roundf_saved 1
}
 }
@@ -5057,6 +5083,14 @@ proc check_vect_support_and_set_flags { } {
 }
 } elseif [istarget ia64-*-*] {
 set dg-do-what-default run
+} elseif [is-effective-target arm_v8_neon_ok] {
+eval lappend DEFAULT_VECTCFLAGS [add_options_for_arm_v8_neon ""]
+lappend DEFAULT_VECTCFLAGS "-ffast-math"
+if [is-effective-target arm_v8_neon_hw] {
+set dg-do-what-default run
+} else {
+set dg-do-what-default compile
+}
 } elseif [is-effective-target arm_neon_ok] {
 eval lappend DEFAULT_VECTCFLAGS [add_options_for_arm_neon ""]
 # NEON does not support denormals, so is not used for vectorization by


[PATCH][ARM][2/3] Add vectorization support for rounding functions

2012-12-18 Thread Kyrylo Tkachov
Hi all,

This patch adds support for the vectorisation of the rounding functions:
floorf, ceilf, truncf, roundf. These can be implemented using the ARMv8 NEON
instructions: vrintm, vrintp, vrintz, vrinta.
This is done by defining the TARGET_VECTORIZE_BUILTINS and
TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION macros and the function
arm_builtin_vectorized_function that returns the decl of the vector form
of a builtin function, or NULL_TREE if no vector variant exists.

No regressions on arm-none-eabi with AEM.

Ok for trunk?

gcc/ChangeLog

2012-12-18  Kyrylo Tkachov  

* config/arm/arm-protos.h (arm_builtin_vectorized_function):
  New function prototype.
* config/arm/arm.c (TARGET_VECTORIZE_BUILTINS): Define.
  (TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION): Likewise.
  (arm_builtin_vectorized_function): New function.diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index d942c5b..0754066 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -80,6 +80,7 @@ extern char *neon_output_shift_immediate (const char *, char, 
rtx *,
 extern void neon_pairwise_reduce (rtx, rtx, enum machine_mode,
  rtx (*) (rtx, rtx, rtx));
 extern rtx neon_make_constant (rtx);
+extern tree arm_builtin_vectorized_function (tree, tree, tree);
 extern void neon_expand_vector_init (rtx, rtx);
 extern void neon_lane_bounds (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
 extern void neon_const_bounds (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 84ce56f..8193e4f 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -607,6 +607,13 @@ static const struct attribute_spec arm_attribute_table[] =
 #undef TARGET_CLASS_LIKELY_SPILLED_P
 #define TARGET_CLASS_LIKELY_SPILLED_P arm_class_likely_spilled_p
 
+#undef TARGET_VECTORIZE_BUILTINS
+#define TARGET_VECTORIZE_BUILTINS
+
+#undef TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
+#define TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION \
+  arm_builtin_vectorized_function
+
 #undef TARGET_VECTOR_ALIGNMENT
 #define TARGET_VECTOR_ALIGNMENT arm_vector_alignment
 
@@ -25593,6 +25600,60 @@ arm_have_conditional_execution (void)
   return !TARGET_THUMB1;
 }
 
+tree
+arm_builtin_vectorized_function (tree fndecl, tree type_out, tree type_in)
+{
+  enum machine_mode in_mode, out_mode;
+  int in_n, out_n;
+
+  if (TREE_CODE (type_out) != VECTOR_TYPE
+  || TREE_CODE (type_in) != VECTOR_TYPE
+  || !(TARGET_NEON && TARGET_FPU_ARMV8 && flag_unsafe_math_optimizations))
+return NULL_TREE;
+
+  out_mode = TYPE_MODE (TREE_TYPE (type_out));
+  out_n = TYPE_VECTOR_SUBPARTS (type_out);
+  in_mode = TYPE_MODE (TREE_TYPE (type_in));
+  in_n = TYPE_VECTOR_SUBPARTS (type_in);
+
+/* ARM_CHECK_BUILTIN_MODE and ARM_FIND_VRINT_VARIANT are used to find the
+   decl of the vectorized builtin for the appropriate vector mode.
+   NULL_TREE is returned if no such builtin is available.  */
+#undef ARM_CHECK_BUILTIN_MODE
+#define ARM_CHECK_BUILTIN_MODE(C) \
+  (out_mode == SFmode && out_n == C \
+   && in_mode == SFmode && in_n == C)
+
+#undef ARM_FIND_VRINT_VARIANT
+#define ARM_FIND_VRINT_VARIANT(N) \
+  (ARM_CHECK_BUILTIN_MODE (2) \
+? arm_builtin_decl(ARM_BUILTIN_NEON_##N##v2sf, false) \
+: (ARM_CHECK_BUILTIN_MODE (4) \
+  ? arm_builtin_decl(ARM_BUILTIN_NEON_##N##v4sf, false) \
+  : NULL_TREE))
+
+  if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
+{
+  enum built_in_function fn = DECL_FUNCTION_CODE (fndecl);
+  switch (fn)
+{
+  case BUILT_IN_FLOORF:
+return ARM_FIND_VRINT_VARIANT (vrintm);
+  case BUILT_IN_CEILF:
+return ARM_FIND_VRINT_VARIANT (vrintp);
+  case BUILT_IN_TRUNCF:
+return ARM_FIND_VRINT_VARIANT (vrintz);
+  case BUILT_IN_ROUNDF:
+return ARM_FIND_VRINT_VARIANT (vrinta);
+  default:
+return NULL_TREE;
+}
+}
+  return NULL_TREE;
+}
+#undef ARM_CHECK_BUILTIN_MODE
+#undef ARM_FIND_VRINT_VARIANT
+
 /* The AAPCS sets the maximum alignment of a vector to 64 bits.  */
 static HOST_WIDE_INT
 arm_vector_alignment (const_tree type)


[PATCH][ARM][1/3] Add vectorization support for rounding functions

2012-12-18 Thread Kyrylo Tkachov
Hi all,

This patch does some refactoring by moving the definitions of the NEON
builtins to a separate file (arm_neon_builtins.def) and includes that when
initialising the neon_builtin_data array and also during
the definition of enum arm_builtins (with appropriate redefinitions of the
VAR* macros). This allows us to have symbolic names for the neon builtins
that allows us to look up their declaration in
arm_builtin_decls. This is needed for vectorisation support in the next
patch. The ARM_BUILTIN_NEON_BASE constant which was defined as part of the
arm_builtins enum is now defined as a macro, since
various functions that deal with the initialisation and expansion of
builtins use it.

No regressions on arm-none-eabi with model.

Ok for trunk?

Thanks,
Kyrill


gcc/ChangeLog

2012-12-18  Kyrylo Tkachov  

* config/arm/arm_neon_builtins.def: New file.
* config/arm/arm.c (neon_builtin_data): Move contents to
  arm_neon_builtins.def.
  (enum arm_builtins): Include neon builtin definitions.
  (ARM_BUILTIN_NEON_BASE): Move from enum to macro.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 84ce56f..ba0fdd2 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -19134,7 +19134,8 @@ typedef struct {
   VAR9 (T, N, A, B, C, D, E, F, G, H, I), \
   {#N, NEON_##T, UP (J), CF (N, J), 0}
 
-/* The mode entries in the following table correspond to the "key" type of the
+/* The NEON builtin data can be found in arm_neon_builtins.def.
+   The mode entries in the following table correspond to the "key" type of the
instruction variant, i.e. equivalent to that which would be specified after
the assembler mnemonic, which usually refers to the last vector operand.
(Signed/unsigned/polynomial types are not differentiated between though, and
@@ -19144,196 +19145,7 @@ typedef struct {
 
 static neon_builtin_datum neon_builtin_data[] =
 {
-  VAR10 (BINOP, vadd,
-v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di),
-  VAR3 (BINOP, vaddl, v8qi, v4hi, v2si),
-  VAR3 (BINOP, vaddw, v8qi, v4hi, v2si),
-  VAR6 (BINOP, vhadd, v8qi, v4hi, v2si, v16qi, v8hi, v4si),
-  VAR8 (BINOP, vqadd, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR3 (BINOP, vaddhn, v8hi, v4si, v2di),
-  VAR8 (BINOP, vmul, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
-  VAR8 (TERNOP, vmla, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
-  VAR3 (TERNOP, vmlal, v8qi, v4hi, v2si),
-  VAR2 (TERNOP, vfma, v2sf, v4sf),
-  VAR2 (TERNOP, vfms, v2sf, v4sf),
-  VAR8 (TERNOP, vmls, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
-  VAR3 (TERNOP, vmlsl, v8qi, v4hi, v2si),
-  VAR4 (BINOP, vqdmulh, v4hi, v2si, v8hi, v4si),
-  VAR2 (TERNOP, vqdmlal, v4hi, v2si),
-  VAR2 (TERNOP, vqdmlsl, v4hi, v2si),
-  VAR3 (BINOP, vmull, v8qi, v4hi, v2si),
-  VAR2 (SCALARMULL, vmull_n, v4hi, v2si),
-  VAR2 (LANEMULL, vmull_lane, v4hi, v2si),
-  VAR2 (SCALARMULL, vqdmull_n, v4hi, v2si),
-  VAR2 (LANEMULL, vqdmull_lane, v4hi, v2si),
-  VAR4 (SCALARMULH, vqdmulh_n, v4hi, v2si, v8hi, v4si),
-  VAR4 (LANEMULH, vqdmulh_lane, v4hi, v2si, v8hi, v4si),
-  VAR2 (BINOP, vqdmull, v4hi, v2si),
-  VAR8 (BINOP, vshl, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR8 (BINOP, vqshl, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR8 (SHIFTIMM, vshr_n, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR3 (SHIFTIMM, vshrn_n, v8hi, v4si, v2di),
-  VAR3 (SHIFTIMM, vqshrn_n, v8hi, v4si, v2di),
-  VAR3 (SHIFTIMM, vqshrun_n, v8hi, v4si, v2di),
-  VAR8 (SHIFTIMM, vshl_n, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR8 (SHIFTIMM, vqshl_n, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR8 (SHIFTIMM, vqshlu_n, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR3 (SHIFTIMM, vshll_n, v8qi, v4hi, v2si),
-  VAR8 (SHIFTACC, vsra_n, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR10 (BINOP, vsub,
-v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di),
-  VAR3 (BINOP, vsubl, v8qi, v4hi, v2si),
-  VAR3 (BINOP, vsubw, v8qi, v4hi, v2si),
-  VAR8 (BINOP, vqsub, v8qi, v4hi, v2si, di, v16qi, v8hi, v4si, v2di),
-  VAR6 (BINOP, vhsub, v8qi, v4hi, v2si, v16qi, v8hi, v4si),
-  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),
-  VAR8 (BINOP, vabd, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
-  VAR3 (BINOP, vabdl, v8qi, v4hi, v2si),
-  VAR6 (TERNOP, vaba, v8qi, v4hi, v2si, v16qi, v8hi, v4si),
-  VAR3 (TERNOP, vabal, v8qi, v4hi, v2si),
-  VAR8 (BINOP, vmax, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
-  VAR8 (BINOP, vmin, v8qi, v4

[PATCH][ARM][0/3] Add vectorization support for rounding functions

2012-12-18 Thread Kyrylo Tkachov
Hi all,

The three following patches add support for the vectorisation of the
rounding functions: floorf, ceilf, truncf, roundf.
The first patch does some refactoring of the NEON builtins, allowing us to
give them symbolic names and thus paving the way for the definition of
TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION in the second patch.

The third patch adds arm to the effective target checks for these functions
in the testsuite when v8 NEON capability is present, thus adding support for
the rounding function vectorisation tests in
gcc.dg/vect/

No regressions on arm-none-eabi with qemu and model.

Thanks,
Kyrill





[PATCH] Fix gcc.dg/tree-ssa/reassoc-19.c testcase

2012-12-18 Thread Richard Biener

Revisiting PR40815, in particular the attached supposedly bad dump
shows:

  D.2021_14 = (unsigned int) rite_2;
  D.2022_9 = (unsigned int) element_5(D);
  D.2023_15 = -D.2022_9;
  D.2024_16 = D.2021_14 + D.2023_15;
  rite_17 = (char *) D.2024_16;

while now we have

  _7 = (sizetype) element_6(D);
  _8 = -_7;
  rite_9 = rite_1 + _8;

which TER will happily forward into the POINTER_PLUS_EXPR.

Thus the following adjusts the dump-scanning to expect exactly
that simplified form.

Tested on x86_64-unknown-linux-gnu, applied.

Richard.

2012-12-18  Richard Biener  

* gcc.dg/tree-ssa/reassoc-19.c: Adjust.

Index: gcc/testsuite/gcc.dg/tree-ssa/reassoc-19.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/reassoc-19.c  (revision 194578)
+++ gcc/testsuite/gcc.dg/tree-ssa/reassoc-19.c  (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-Os -fdump-tree-reassoc2" } */
+/* { dg-options "-Os -fdump-tree-optimized" } */
 
 /* Slightly changed testcase from PR middle-end/40815.  */
 void bar(char*, char*, int);
@@ -8,14 +8,15 @@ void foo(char* left, char* rite, int ele
   while (left <= rite)
   {
 /* This should expand into
-   D. = D. - D.;
-   and NOT to
-   D.D. = -D.; D. = D. + D.;  */
+   _7 = (sizetype) element_6(D);
+   _8 = -_7;
+   rite_9 = rite_1 + _8;  */
 rite -= element;
 bar(left, rite, element);
   }
 }
 
-/* There should be no " + " in the dump.  */
-/* { dg-final { scan-tree-dump-times " \\\+ " 0 "reassoc2" } } */
-/* { dg-final { cleanup-tree-dump "reassoc2" } } */
+/* { dg-final { scan-tree-dump-times "= \\\(sizetype\\\) element" 1 
"optimized" } } */
+/* { dg-final { scan-tree-dump-times "= -" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " \\\+ " 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */


Re: [PATCH] Update loop docs

2012-12-18 Thread Richard Biener
On Tue, 18 Dec 2012, Steven Bosscher wrote:

> On Tue, Dec 18, 2012 at 1:42 PM, Richard Biener wrote:
> > Thus I'd welcome hints at what information you are currently
> > missing
> 
> I think the documentation for the loops maintenance should document
> those things that are different from before. Before loops were
> maintained, the world was easy: Everything was refreshed every time
> loops were re-discovered. With maintained loops, you're implicitly
> making a guarantee of sorts that some information remains valid, and
> that should be documented. For example:

Well, loops were already preserved throughout the GIMPLE loop
optimizer passes.

> * What information is supposed to be transferable from GIMPLE loops to
> RTL loops (e.g. number of iterations, ddg)?

Transferable is everything cfgexpand.c arranges to transfer.  Which
is the absolute minimum as documented by "Loop querying".

> * What's supposed to remain valid and what might need updating (e.g.
> state of loop_father, number of latches, ...)?

See above - it's already documented.  All information that is
valid according to the loop_state_satisfies_p () predicates.

> * How are newly discovered loops handled (e.g. after node splitting of
> an irreducible region, or a sting builtin expanded as a loop)?

They are not handled.  New loops need to be explicitely introduced
(as happens with SESE region copying).  What is not handled right
now is if a previously irreducible region becomes reducible.

> * If a pass might change loops, who is responsible for updating the
> loop tree? If it's the pass itself, what parts should be updated and
> what's the API for it, and what can be left to fix_loop_structure?

In general the pass is responsible for high-level transforms
(like loop versioning).  CFG hooks maintain loops for "simple"
CFG modifications.  fix_loop_structure is something that shouldn't
be documented as interface - it should really work behind the scenes
(I am still pondering on whether to make loop_optimizer_finalize
or maybe instead loop_optimizer_init call it if LOOPS_NEED_FIXUP
is set - an internal implementation detail flag - same as PROP_loops).

Richard.


Re: [PATCH] Fix PR55555

2012-12-18 Thread Richard Biener
On Mon, 17 Dec 2012, Richard Biener wrote:

> On Mon, 17 Dec 2012, Richard Biener wrote:
> 
> > 
> > The following patch fixes a miscompilation due to bogus loop iteration
> > bound derived from array accesses in an inner loop.  idx_infer_loop_bounds
> > analyzes the evoultion of an SSA name with respect to a loop it is not
> > defined in - which seems to lead to random weird behavior.  The correct
> > thing to do (as documented) is to analyze the evolution with respect
> > to the loop the stmt we are interested in is in.
> > 
> > Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.
> 
> Which shows that the very old fix for PR40281 isn't complete
> (the patch regresses PR55687 again).  So the following extends
> that fix.  I wonder whether we instead want to pass down
> CHREC_VARIABLE and avoid doing the instantiation in the first
> place ...

So I revisited this and reworked it so that it avoids doing the
instantiation in the first place.  Which makes SCEV stronger
so I need to fixup gcc.dg/vect/vect-iv-11.c (now two vectorized
locations, one in the inlined copy in main).  Also with this
patch I see

FAIL: gcc.dg/tree-ssa/reassoc-19.c scan-tree-dump-times reassoc2 " + " 
0

as we now have

  :
  goto ;

  :
  _7 = (sizetype) element_6(D);
  _8 = -_7;
  rite_9 = rite_1 + _8;
  bar (left_5(D), rite_9, element_6(D));

  :
  # rite_1 = PHI 
  if (left_5(D) <= rite_1)
goto ;
  else
goto ;

while before we had

:
  goto ;

:
  D.1716_5 = (long unsigned int) element_4(D);
  D.1717_6 = -D.1716_5;
  D.1733_12 = (sizetype) rite_1;
  D.1734_11 = (long unsigned int) element_4(D);
  D.1735_13 = -D.1734_11;
  D.1736_14 = D.1733_12 - D.1734_11;
  D.1737_15 = (char *) D.1736_14;
  rite_7 = D.1737_15;
  bar (left_3(D), rite_7, element_4(D));

:
  # rite_1 = PHI 
  if (left_3(D) <= rite_1)
goto ;
  else
goto ;

I will investigate what the original bug was about and come up
with a fix (likely to the testcase) as a followup.

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

Richard.

2012-12-18  Richard Biener  

PR tree-optimization/5
* tree-ssa-loop-niter.c (idx_infer_loop_bounds): Properly
analyze evolution of the index for the loop it is used in.
* tree-scalar-evolution.c (instantiate_scev_name): Take
inner loop we will be creating a chrec for.  Generalize
fix for PR40281 and prune invalid SCEVs.
(instantiate_scev_poly): Likewise - pass down inner loop
we will be creating a chrec for.
(instantiate_scev_binary): Take and pass through inner loop.
(instantiate_array_ref): Likewise.
(instantiate_scev_convert): Likewise.
(instantiate_scev_not): Likewise.
(instantiate_scev_3): Likewise.
(instantiate_scev_2): Likewise.
(instantiate_scev_1): Likewise.
(instantiate_scev_r): Likewise.
(resolve_mixers): Adjust.
(instantiate_scev): Likewise.

* gcc.dg/torture/pr5.c: New testcase.
* gcc.dg/vect/vect-iv-11.c: Adjust.

Index: gcc/tree-ssa-loop-niter.c
===
*** gcc/tree-ssa-loop-niter.c   (revision 194552)
--- gcc/tree-ssa-loop-niter.c   (working copy)
*** idx_infer_loop_bounds (tree base, tree *
*** 2671,2677 
upper = false;
  }
  
!   ev = instantiate_parameters (loop, analyze_scalar_evolution (loop, *idx));
init = initial_condition (ev);
step = evolution_part_in_loop_num (ev, loop->num);
  
--- 2671,2682 
upper = false;
  }
  
!   struct loop *dloop = loop_containing_stmt (data->stmt);
!   if (!dloop)
! return true;
! 
!   ev = analyze_scalar_evolution (dloop, *idx);
!   ev = instantiate_parameters (loop, ev);
init = initial_condition (ev);
step = evolution_part_in_loop_num (ev, loop->num);
  
Index: gcc/tree-scalar-evolution.c
===
*** gcc/tree-scalar-evolution.c (revision 194552)
--- gcc/tree-scalar-evolution.c (working copy)
*** loop_closed_phi_def (tree var)
*** 2147,2154 
return NULL_TREE;
  }
  
! static tree instantiate_scev_r (basic_block, struct loop *, tree, bool,
!   htab_t, int);
  
  /* Analyze all the parameters of the chrec, between INSTANTIATE_BELOW
 and EVOLUTION_LOOP, that were left under a symbolic form.
--- 2147,2154 
return NULL_TREE;
  }
  
! static tree instantiate_scev_r (basic_block, struct loop *, struct loop *,
!   tree, bool, htab_t, int);
  
  /* Analyze all the parameters of the chrec, between INSTANTIATE_BELOW
 and EVOLUTION_LOOP, that were left under a symbolic form.
*** static tree instantiate_scev_r (basic_bl
*** 2166,2172 
  
  static tree
  instantiate_scev_name (basic_block instantiate_below,
!  struct loop *evolution_loop, tree chrec,
   bool fold_con

Re: [PATCH] Update loop docs

2012-12-18 Thread Steven Bosscher
On Tue, Dec 18, 2012 at 1:42 PM, Richard Biener wrote:
> Thus I'd welcome hints at what information you are currently
> missing

I think the documentation for the loops maintenance should document
those things that are different from before. Before loops were
maintained, the world was easy: Everything was refreshed every time
loops were re-discovered. With maintained loops, you're implicitly
making a guarantee of sorts that some information remains valid, and
that should be documented. For example:

* What information is supposed to be transferable from GIMPLE loops to
RTL loops (e.g. number of iterations, ddg)?

* What's supposed to remain valid and what might need updating (e.g.
state of loop_father, number of latches, ...)?

* How are newly discovered loops handled (e.g. after node splitting of
an irreducible region, or a sting builtin expanded as a loop)?

* If a pass might change loops, who is responsible for updating the
loop tree? If it's the pass itself, what parts should be updated and
what's the API for it, and what can be left to fix_loop_structure?

Ciao!
Steven


[PATCH] Update loop docs

2012-12-18 Thread Richard Biener

This updates loop docs to reflect changes I did for 4.8, which is
mostly that loop structures are now preserved from the start of
GIMPLE loop optimizations until the end of RTL loop optimizations.
Apart from the stale 'Lambda' chapter (and the missing GRAPHITE
chapter ...) things are surprisingly up-to-date.

Thus I'd welcome hints at what information you are currently
missing and I'll promise to fill in bits as I can (which means
_not_ GRAPHITE).  In particular the docs very well state what
information can be relied on in what cases.

Thanks,
Richard.

2012-12-18  Richard Biener  

* doc/loop.texi (Lambda): Remove section.
(Loop representation): Update with respect to us now preserving
loop structures througout most of the compilation.

Index: gcc/doc/loop.texi
===
*** gcc/doc/loop.texi   (revision 194552)
--- gcc/doc/loop.texi   (working copy)
*** variable analysis and number of iteratio
*** 25,31 
  * loop-iv:: Induction variables on RTL.
  * Number of iterations::Number of iterations analysis.
  * Dependency analysis:: Data dependency analysis.
- * Lambda::  Linear loop transformations framework.
  * Omega::   A solver for linear programming problems.
  @end menu
  
--- 25,30 
*** variable analysis and number of iteratio
*** 37,46 
  This chapter describes the representation of loops in GCC, and functions
  that can be used to build, modify and analyze this representation.  Most
  of the interfaces and data structures are declared in @file{cfgloop.h}.
! At the moment, loop structures are analyzed and this information is
! updated only by the optimization passes that deal with loops, but some
! efforts are being made to make it available throughout most of the
! optimization passes.
  
  In general, a natural loop has one entry block (header) and possibly
  several back edges (latches) leading to the header from the inside of
--- 36,48 
  This chapter describes the representation of loops in GCC, and functions
  that can be used to build, modify and analyze this representation.  Most
  of the interfaces and data structures are declared in @file{cfgloop.h}.
! Loop structures are analyzed and this information disposed or updated
! at the discretion of individual passes.  Still most of the generic
! CFG manipulation routines are aware of loop structures and try to
! keep them up-to-date.  By this means an increasing part of the
! compilation pipeline is setup to maintain loop structure across
! passes to allow attaching meta information to individual loops
! for consumption by later passes.
  
  In general, a natural loop has one entry block (header) and possibly
  several back edges (latches) leading to the header from the inside of
*** recorded.
*** 139,147 
  These properties may also be computed/enforced later, using functions
  @code{create_preheaders}, @code{force_single_succ_latches},
  @code{mark_irreducible_loops} and @code{record_loop_exits}.
  
  The memory occupied by the loops structures should be freed with
! @code{loop_optimizer_finalize} function.
  
  The CFG manipulation functions in general do not update loop structures.
  Specialized versions that additionally do so are provided for the most
--- 141,153 
  These properties may also be computed/enforced later, using functions
  @code{create_preheaders}, @code{force_single_succ_latches},
  @code{mark_irreducible_loops} and @code{record_loop_exits}.
+ The properties can be queried using @code{loops_state_satisfies_p}.
  
  The memory occupied by the loops structures should be freed with
! @code{loop_optimizer_finalize} function.  When loop structures are
! setup to be preserved across passes this function reduces the
! information to be kept up-to-date to a minimum (only
! @code{LOOPS_MAY_HAVE_MULTIPLE_LATCHES} set).
  
  The CFG manipulation functions in general do not update loop structures.
  Specialized versions that additionally do so are provided for the most
*** common tasks.  On GIMPLE, @code{cleanup_
*** 149,154 
--- 155,164 
  used to cleanup CFG while updating the loops structures if
  @code{current_loops} is set.
  
+ At the moment loop structure is preserved from the start of GIMPLE
+ loop optimizations until the end of RTL loop optimizations.  During
+ this time a loop can be tracked by its @code{struct loop} and number.
+ 
  @node Loop querying
  @section Loop querying
  @cindex Loop querying
*** direction vectors for a data dependence
*** 593,629 
  @code{dump_data_references} prints the details of the data references
  contained in a data reference array.
  
- @node Lambda
- @section Linear loop transformations framework
- @cindex Linear loop transformations framework
- 
- Lambda is a framework that allows transformations of loops using
- non-singular matrix based tr

Re: [patch] PR debug/53948

2012-12-18 Thread Richard Biener
On Wed, Jul 18, 2012 at 7:46 PM, Steven Bosscher  wrote:
> Hello,
>
> This is my proposed fix for PR53948. We don't want to put user
> variables in callee-clobbered registers, but obviously function
> arguments are OK there. REG_USERVAR_P is set on PARM_DECLs and on user
> variables, so it can't be used to distinguish between the two.
>
> As it turns out, I can hi-jack a bit for that: 'unchanging' (currently
> incorrectly documented as used on REG) for a new macro
> REG_FUNCTION_PARM_P. I found one obvious place where this bit can be
> used instead of REG_USERVAR_P, and probably there are a few more
> places where this is useful (TBD, I'm going to look at all places
> where RTL code looks at tree's PARM_DECL later).
>
> Bootstrapped&tested on powerpc64-unknown-linux-gnu.
> OK for trunk?

Just being pointed back to this patch ... I wonder if simply looking
at REG_EXPR of a REG_USERVAR_P reg and checking whether
it's a PARM_DECL isn't good enough (and simpler)?

I suppose the optabs.c change was the "real" fix, thus sth like

Index: gcc/optabs.c
===
--- gcc/optabs.c(revision 194552)
+++ gcc/optabs.c(working copy)
@@ -3848,9 +3848,13 @@ emit_libcall_block_1 (rtx insns, rtx tar
   rtx final_dest = target;
   rtx next, last, insn;

-  /* If this is a reg with REG_USERVAR_P set, then it could possibly turn
- into a MEM later.  Protect the libcall block from this change.  */
-  if (! REG_P (target) || REG_USERVAR_P (target))
+  /* If this is a parameter with REG_USERVAR_P set, then it could possibly turn
+ into a MEM later (e.g. if a REG_EQUIV note is attached to the insns that
+ sets the reg).  Protect the libcall block from this change.  */
+  if (! REG_P (target)
+  || (REG_USERVAR_P (target)
+ && REG_EXPR (target) != NULL_TREE
+ && TREE_CODE (REG_EXPR (target)) == PARM_DECL))
 target = gen_reg_rtx (GET_MODE (target));

   /* If we're using non-call exceptions, a libcall corresponding to an

(untested)

Thanks,
Richard.

> Ciao!
> Steven
>
> PR debug/53948
> * rtl.h (REG_FUNCTION_PARM_P): New flag on a REG.  Re-use 'unchaning'.
> * emit-rtl.c (mark_function_parm_reg): New function.
> * function.c (assign_parm_setup_reg): Use mark_function_parm_reg
> instead of mark_user_reg.
> * combine.c (can_change_dest_mode): Preserve REG_FUNCTION_PARM_P.
> * web.c (entry_register): Likewise.
> * reload1.c (reload): Likewise.
> * ira-emit.c (ira_create_new_reg): Likewise.
> * reginfo.c (reg_scan_mark_refs): Likewise.
> * optabs.c (emit_libcall_block_1): Use REG_FUNCTION_PARM_P instead
> of REG_USERVAR_P.
> * regstat.c (dump_reg_info): Print REG_FUNCTION_PARM_P.
> * doc/rtl.texi (REG_FUNCTION_PARM_P): Document it.
> ('unchanging' flag): Fix documentation.


Re: [v3] docbook vs. texlive > 2007

2012-12-18 Thread Jonathan Wakely
On 11 December 2012 02:14, Benjamin De Kosnik wrote:
>
> The recent change in Fedora's documentation stack, from texlive-2007 to
> texlive-2013 caused some havoc in the libstdc++ "make pdf" rules.
>
> This patch fixes the previously unknown issues so that the pdf docs for
> libstdc++ can be built on texlive-2007 and texlive-2013.

This patch broke html generation for me. The new file containing the
bibliography didn't have an xmlns attribute on the root node, so the
 element wasn't processed correctly.

This fixes it, however the Bibliography still appears after the first
section in the Policy Based Data Structures chapter, rather than the
last, because the  element doesn't start a new chunk so
is in the same file as the first section. Adding a  PI
doesn't have seem to have any effect on a .

This patch also adds  PIs to several sections so the HTML
pages get stable names, rather than something like
bk01pt03ch20s05.html

* doc/xml/manual/abi.xml: Update URLs for C++ ABI.
* doc/xml/manual/policy_data_structures_biblio.xml: Add xmlns
attribute.
* doc/xml/manual/debug_mode.xml: Give filenames to chunks.
* doc/xml/manual/diagnostics.xml: Likewise.
* doc/xml/manual/extensions.xml: Likewise.
* doc/xml/manual/bitmap_allocator.xml: Likewise.
* doc/xml/manual/mt_allocator.xml: Likewise.
* doc/xml/manual/policy_data_structures.xml: Likewise.
* doc/xml/manual/parallel_mode.xml: Likewise.
* doc/xml/manual/profile_mode.xml: Likewise.
* doc/xml/manual/spine.xml: Likewise. Update copyright years.
* doc/html/*: Regenerate.

Committed to trunk.  I'll fix the ABI URLs and check the html gen on
the 4.7 branch too.
commit b5e4659a8addd90789ca648277a99ad643a45ff7
Author: Jonathan Wakely 
Date:   Sat Dec 15 00:06:11 2012 +

* doc/xml/manual/abi.xml: Update URLs for C++ ABI.
* doc/xml/manual/policy_data_structures_biblio.xml: Add xmlns
attribute.
* doc/xml/manual/debug_mode.xml: Give filenames to chunks.
* doc/xml/manual/diagnostics.xml: Likewise.
* doc/xml/manual/extensions.xml: Likewise.
* doc/xml/manual/bitmap_allocator.xml: Likewise.
* doc/xml/manual/mt_allocator.xml: Likewise.
* doc/xml/manual/policy_data_structures.xml: Likewise.
* doc/xml/manual/parallel_mode.xml: Likewise.
* doc/xml/manual/profile_mode.xml: Likewise.
* doc/xml/manual/spine.xml: Likewise. Update copyright years.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/abi.xml 
b/libstdc++-v3/doc/xml/manual/abi.xml
index 23c6355..9d7395e 100644
--- a/libstdc++-v3/doc/xml/manual/abi.xml
+++ b/libstdc++-v3/doc/xml/manual/abi.xml
@@ -42,7 +42,7 @@
   virtual functions, etc. These details are defined as the compiler
   Application Binary Interface, or ABI. The GNU C++ compiler uses an
   industry-standard C++ ABI starting with version 3. Details can be
-  found in the http://www.w3.org/1999/xlink"; 
xlink:href="http://www.codesourcery.com/public/cxx-abi/abi.html";>ABI
+  found in the http://www.w3.org/1999/xlink"; 
xlink:href="http://mentorembedded.github.com/cxx-abi/abi.html";>ABI
   specification.
 
 
@@ -717,7 +717,7 @@ class that would otherwise have implicit versions. This 
will change
 the way the compiler deals with this class in by-value return
 statements or parameters: instead of passing instances of this
 class in registers, the compiler will be forced to use memory. See the
-section on http://www.w3.org/1999/xlink"; 
xlink:href="http://www.codesourcery.com/public/cxx-abi/abi.html#calls";>Function
+section on http://www.w3.org/1999/xlink"; 
xlink:href="http://mentorembedded.github.com/cxx-abi/abi.html#calls";>Function
 Calling Conventions and APIs
  of the C++ ABI documentation for further details.
 
@@ -1075,7 +1075,7 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 
/usr/lib/libstdc++.so.
 
   
http://www.w3.org/1999/xlink";
- xlink:href="http://www.codesourcery.com/public/cxx-abi";>
+ xlink:href="http://www.codesourcery.com/cxx-abi/";>
  C++ ABI Summary

   
diff --git a/libstdc++-v3/doc/xml/manual/bitmap_allocator.xml 
b/libstdc++-v3/doc/xml/manual/bitmap_allocator.xml
index 3bc489a..1450162 100644
--- a/libstdc++-v3/doc/xml/manual/bitmap_allocator.xml
+++ b/libstdc++-v3/doc/xml/manual/bitmap_allocator.xml
@@ -53,6 +53,7 @@
 
 
 Implementation
+
 
 
 Free List Store
diff --git a/libstdc++-v3/doc/xml/manual/concurrency_extensions.xml 
b/libstdc++-v3/doc/xml/manual/concurrency_extensions.xml
index 0d0e1b9..aef588d 100644
--- a/libstdc++-v3/doc/xml/manual/concurrency_extensions.xml
+++ b/libstdc++-v3/doc/xml/manual/concurrency_extensions.xml
@@ -185,6 +185,7 @@ host hardware and operating system.
 
 
 Implementation
+  
   
   Using Builtin Atomic Functions
 
@@ -290,8 +291,8 @@ etc.
 
 
 Use
+
 
-  
 
 Typical usage of the last two constructs is demonstr

Re: [cxx-conversion] Change tree-ssa-coalesce.c'coalesce_list_d.list to hash_table

2012-12-18 Thread Richard Biener
On Mon, Dec 17, 2012 at 9:01 PM, Lawrence Crowl  wrote:
> On 12/17/12, Richard Biener  wrote:
>> On Mon, Dec 17, 2012 at 8:36 PM, Lawrence Crowl  wrote:
>>> Change tree-ssa-coalesce.c'coalesce_list_d.list from htab_t to
>>> hash_table.
>>>
>>> Fold coalesce_pair_map_hash and coalesce_pair_map_eq into new
>>> struct coalesce_pair_hasher.
>>>
>>> Removed struct coalesce_pair_iterator, as did not meet the hash_table
>>> iterator interface and it provided no significant code reduction.
>>>
>>> Tested on x86-64.
>>>
>>> Okay for branch?
>>>
>>>
>>> Index: gcc/tree-ssa-coalesce.c
>>> ===
>>> --- gcc/tree-ssa-coalesce.c (revision 194549)
>>> +++ gcc/tree-ssa-coalesce.c (working copy)
>>> @@ -50,6 +50,41 @@ typedef struct coalesce_pair
>>>  } * coalesce_pair_p;
>>>  typedef const struct coalesce_pair *const_coalesce_pair_p;
>>>
>>> +/* Coalesce pair hashtable helpers.  */
>>> +
>>> +struct coalesce_pair_hasher : typed_noop_remove 
>>> +{
>>> +  typedef coalesce_pair value_type;
>>> +  typedef coalesce_pair compare_type;
>>> +  static inline hashval_t hash (const value_type *);
>>> +  static inline bool equal (const value_type *, const compare_type *);
>>> +};
>>> +
>>> +/* Hash function for coalesce list.  Calculate hash for PAIR.   */
>>> +
>>> +inline hashval_t
>>> +coalesce_pair_hasher::hash (const value_type *pair)
>>> +{
>>> +  hashval_t a = (hashval_t)(pair->first_element);
>>> +  hashval_t b = (hashval_t)(pair->second_element);
>>> +
>>> +  return b * (b - 1) / 2 + a;
>>> +}
>>> +
>>> +/* Equality function for coalesce list hash table.  Compare PAIR1 and
>>> PAIR2,
>>> +   returning TRUE if the two pairs are equivalent.  */
>>> +
>>> +inline bool
>>> +coalesce_pair_hasher::equal (const value_type *p1, const compare_type
>>> *p2)
>>> +{
>>> +  return (p1->first_element == p2->first_element
>>> + && p1->second_element == p2->second_element);
>>> +}
>>> +
>>> +typedef hash_table  coalesce_table_type;
>>> +typedef coalesce_table_type::iterator coalesce_iterator_type;
>>> +
>>> +
>>>  typedef struct cost_one_pair_d
>>>  {
>>>int first_element;
>>> @@ -61,7 +96,7 @@ typedef struct cost_one_pair_d
>>>
>>>  typedef struct coalesce_list_d
>>>  {
>>> -  htab_t list; /* Hash table.  */
>>> +  coalesce_table_type list;/* Hash table.  */
>>>coalesce_pair_p *sorted; /* List when sorted.  */
>>>int num_sorted;  /* Number in the sorted list.  */
>>>cost_one_pair_p cost_one_list;/* Single use coalesces with cost 1.  */
>>> @@ -186,34 +221,6 @@ pop_best_coalesce (coalesce_list_p cl, i
>>>  }
>>>
>>>
>>> -#define COALESCE_HASH_FN(R1, R2) ((R2) * ((R2) - 1) / 2 + (R1))
>>> -
>>> -/* Hash function for coalesce list.  Calculate hash for PAIR.   */
>>> -
>>> -static unsigned int
>>> -coalesce_pair_map_hash (const void *pair)
>>> -{
>>> -  hashval_t a =
>>> (hashval_t)(((const_coalesce_pair_p)pair)->first_element);
>>> -  hashval_t b =
>>> (hashval_t)(((const_coalesce_pair_p)pair)->second_element);
>>> -
>>> -  return COALESCE_HASH_FN (a,b);
>>> -}
>>> -
>>> -
>>> -/* Equality function for coalesce list hash table.  Compare PAIR1 and
>>> PAIR2,
>>> -   returning TRUE if the two pairs are equivalent.  */
>>> -
>>> -static int
>>> -coalesce_pair_map_eq (const void *pair1, const void *pair2)
>>> -{
>>> -  const_coalesce_pair_p const p1 = (const_coalesce_pair_p) pair1;
>>> -  const_coalesce_pair_p const p2 = (const_coalesce_pair_p) pair2;
>>> -
>>> -  return (p1->first_element == p2->first_element
>>> - && p1->second_element == p2->second_element);
>>> -}
>>> -
>>> -
>>>  /* Create a new empty coalesce list object and return it.  */
>>>
>>>  static inline coalesce_list_p
>>> @@ -226,8 +233,7 @@ create_coalesce_list (void)
>>>  size = 40;
>>>
>>>list = (coalesce_list_p) xmalloc (sizeof (struct coalesce_list_d));
>>> -  list->list = htab_create (size, coalesce_pair_map_hash,
>>> -   coalesce_pair_map_eq, NULL);
>>> +  list->list.create (size);
>>>list->sorted = NULL;
>>>list->num_sorted = 0;
>>>list->cost_one_list = NULL;
>>> @@ -241,7 +247,7 @@ static inline void
>>>  delete_coalesce_list (coalesce_list_p cl)
>>>  {
>>>gcc_assert (cl->cost_one_list == NULL);
>>> -  htab_delete (cl->list);
>>> +  cl->list.dispose ();
>>>free (cl->sorted);
>>>gcc_assert (cl->num_sorted == 0);
>>>free (cl);
>>> @@ -256,7 +262,7 @@ static coalesce_pair_p
>>>  find_coalesce_pair (coalesce_list_p cl, int p1, int p2, bool create)
>>>  {
>>>struct coalesce_pair p;
>>> -  void **slot;
>>> +  coalesce_pair **slot;
>>>unsigned int hash;
>>>
>>>/* Normalize so that p1 is the smaller value.  */
>>> @@ -271,9 +277,8 @@ find_coalesce_pair (coalesce_list_p cl,
>>>p.second_element = p2;
>>>  }
>>>
>>> -  hash = coalesce_pair_map_hash (&p);
>>> -  slot = htab_find_slot_with_hash (cl->list, &p, hash,
>>> -  create ? INS

Re: [PATCH] Don't return original value from gen_lowpart_no_emit rtl hook (PR debug/55717)

2012-12-18 Thread Paolo Bonzini
Il 17/12/2012 22:33, Jakub Jelinek ha scritto:
> Hi!
> 
> If gen_lowpart_if_possible returns NULL, the default
> rtl_hooks.gen_lowpart_no_emit hook returns the original value, which is not
> of the desired mode.  I bet in most passes for real insns such rtx is then
> meant to fail recog and thrown away, but for DEBUG_INSN modification that
> doesn't work, since there is no verification (but also e.g. any kind of
> SUBREG is fine).  So we can e.g. end up with a (plus:SI (mem:DI ...) (mem:SI 
> ...))
> or similar and then various passes (in this testcase on s390x reload) can be
> very upset about that.

Makes sense, and it could even be a wrong-code bug for this simplification:

  /* (sign_extend:M (ashiftrt:N (ashift  (const_int I)) (const_int I)))
 is (sign_extend:M (subreg:O )) if there is mode with
 GET_MODE_BITSIZE (N) - I bits.
 (sign_extend:M (lshiftrt:N (ashift  (const_int I)) (const_int I)))
 is similarly (zero_extend:M (subreg:O )).  */
  if ((GET_CODE (op) == ASHIFTRT || GET_CODE (op) == LSHIFTRT)
  && GET_CODE (XEXP (op, 0)) == ASHIFT
  && CONST_INT_P (XEXP (op, 1))
  && XEXP (XEXP (op, 0), 1) == XEXP (op, 1)
  && GET_MODE_BITSIZE (GET_MODE (op)) > INTVAL (XEXP (op, 1)))
{
  enum machine_mode tmode
= mode_for_size (GET_MODE_BITSIZE (GET_MODE (op))
 - INTVAL (XEXP (op, 1)), MODE_INT, 1);
  gcc_assert (GET_MODE_BITSIZE (mode)
  > GET_MODE_BITSIZE (GET_MODE (op)));
  if (tmode != BLKmode)
{
  rtx inner =
rtl_hooks.gen_lowpart_no_emit (tmode, XEXP (XEXP (op, 0), 0));
  if (!inner)
return NULL_RTX;
  return simplify_gen_unary (GET_CODE (op) == ASHIFTRT
 ? SIGN_EXTEND : ZERO_EXTEND,
 mode, inner, tmode);
}
}

So perhaps we want it on stable branches too, after some time in trunk.

Paolo

> Fixed by making the hook instead return NULL_RTX if it wasn't possible to
> generate the lowpart, and adjusting all the hook uses to cope with that.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2012-12-17  Jakub Jelinek  
> 
>   PR debug/55717
>   * rtlhooks-def.h (RTL_HOOKS_GEN_LOWPART_NO_EMIT): Define to
>   gen_lowpart_if_possible.
>   (gen_lowpart_no_emit_general): Remove prototype.
>   * rtlhooks.c (gen_lowpart_no_emit_general): Removed.
>   * simplify-rtx.c (simplify_unary_operation_1, 
>   simplify_binary_operation_1): Continue simplifying if
>   rtl_hooks.gen_lowpart_no_emit returns NULL_RTX.
>   * dwarf2out.c (mem_loc_descriptor) : Handle
>   truncation like lowpart SUBREG.
> 
>   * testsuite/g++.dg/opt/pr55717.C: New test.
> 
> --- gcc/rtlhooks-def.h.jj 2009-02-20 15:40:11.0 +0100
> +++ gcc/rtlhooks-def.h2012-12-17 19:34:38.852895461 +0100
> @@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.
>  #include "rtl.h"
>  
>  #define RTL_HOOKS_GEN_LOWPART gen_lowpart_general
> -#define RTL_HOOKS_GEN_LOWPART_NO_EMIT gen_lowpart_no_emit_general
> +#define RTL_HOOKS_GEN_LOWPART_NO_EMIT gen_lowpart_if_possible
>  #define RTL_HOOKS_REG_NONZERO_REG_BITS reg_nonzero_bits_general
>  #define RTL_HOOKS_REG_NUM_SIGN_BIT_COPIES reg_num_sign_bit_copies_general
>  #define RTL_HOOKS_REG_TRUNCATED_TO_MODE reg_truncated_to_mode_general
> @@ -38,7 +38,6 @@ along with GCC; see the file COPYING3.
>  }
>  
>  extern rtx gen_lowpart_general (enum machine_mode, rtx);
> -extern rtx gen_lowpart_no_emit_general (enum machine_mode, rtx);
>  extern rtx reg_nonzero_bits_general (const_rtx, enum machine_mode, const_rtx,
>enum machine_mode,
>unsigned HOST_WIDE_INT,
> --- gcc/rtlhooks.c.jj 2011-07-07 13:24:05.0 +0200
> +++ gcc/rtlhooks.c2012-12-17 19:34:08.634071165 +0100
> @@ -79,18 +79,6 @@ gen_lowpart_general (enum machine_mode m
>  }
>  }
>  
> -/* Similar to gen_lowpart, but cannot emit any instruction via
> -   copy_to_reg or force_reg.  Mainly used in simplify-rtx.c.  */
> -rtx
> -gen_lowpart_no_emit_general (enum machine_mode mode, rtx x)
> -{
> -  rtx result = gen_lowpart_if_possible (mode, x);
> -  if (result)
> -return result;
> -  else
> -return x;
> -}
> -
>  rtx
>  reg_num_sign_bit_copies_general (const_rtx x ATTRIBUTE_UNUSED,
>enum machine_mode mode ATTRIBUTE_UNUSED,
> --- gcc/simplify-rtx.c.jj 2012-11-28 23:57:47.0 +0100
> +++ gcc/simplify-rtx.c2012-12-17 18:10:48.873398378 +0100
> @@ -873,7 +873,9 @@ simplify_unary_operation_1 (enum rtx_cod
> simplify_gen_unary (NOT, inner_mode, const1_rtx,
> inner_mode),
> XEXP (SUBREG_REG (op), 1));
> -