Re: [PATCH, i386, Android] Enable exceptions and RTTI by default for Android

[Ilya Enkovich]

> My comment is(was) not on the format of the patch. Instead, I am
> thinking whether Android toolchain customer, which is Android AOSP,
> wants this patch.
>
> I don't know the scenario behind this patch. I think the question
> behind this patch is, if RTTI and exceptions are enabled by default,
> who is supposed to handle RTTI and exceptions by default? The answer
> is no answer, for now.
>
> Android AOSP tree provides very limited C++ support. Android NDK
> provides four options for C++ support. Some of the options support
> both exceptions and rttit, some options only support rtti.
>
> Therefore I guess Android AOSP probably would not like to enable
> exceptions and RTTI by default.

Actually when you rebuild Android NDK similar patch (named
0001-Enable-C-exceptions-and-RTTI-by-default.patch) is applied to GCC
sources before toolchain rebuild.

Ilya

>
> Questions/complaints/requests on Android limited C++ support, should
> go to Android forum.
> Questions about license concerns, should go to Android AOSP lawyer.
>
> Thanks,
> Jing
>
> On Fri, Feb 24, 2012 at 2:36 AM, Richard Guenther
>  wrote:
>> On Fri, Feb 24, 2012 at 11:22 AM, Ilya Enkovich  
>> wrote:
 On Wed, Feb 22, 2012 at 3:57 PM, Ilya Enkovich  
 wrote:
> Hello,
>
> Here is a simple patch which enables exceptions and RTTI by default
> for Android target. OK for trunk?

 Err - isn't that the default?  Thus, simply delete the bogus spec?

 Richard.


>>> Hi,
>>>
>>> Is following patch OK or it's better to remove whole macro and its usages?
>>
>> The latter.
>>
>> Richard.
>>
>>> Thanks,
>>> Ilya
>>> --
>>> 2012-02-22  Enkovich Ilya  
>>>
>>>        * gcc/config/linux-android.h (ANDROID_CC1PLUS_SPEC): Enable
>>>        exceptions and rtti by default.
>>>
>>>
>>> diff --git a/gcc/config/linux-android.h b/gcc/config/linux-android.h
>>> index 94c5274..180b62b 100644
>>> --- a/gcc/config/linux-android.h
>>> +++ b/gcc/config/linux-android.h
>>> @@ -45,9 +45,7 @@
>>>   "%{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}} "                      \
>>>   "%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC"
>>>
>>> -#define ANDROID_CC1PLUS_SPEC                                           \
>>> -  "%{!fexceptions:%{!fno-exceptions: -fno-exceptions}} "               \
>>> -  "%{!frtti:%{!fno-rtti: -fno-rtti}}"
>>> +#define ANDROID_CC1PLUS_SPEC ""
>>>
>>>  #define ANDROID_LIB_SPEC \
>>>   "%{!static: -ldl}"

Re: [PR51752] publication safety violations in loop invariant motion pass

[Torvald Riegel]

On Fri, 2012-02-24 at 10:34 -0600, Aldy Hernandez wrote:
> On 02/24/12 07:10, Torvald Riegel wrote:
> > safety.  I didn't have time to look at Aldy's patch yet, but a first
> > safe and conservative way would be to treat transactions as full
> > transformation barriers, and prevent publication-safety-violating
> > transformations _within_ transactions.  Which I would prefer until we're
> > confident that we understood all of it.
> 
> Do you mean disallow hoisting of *any* loads that happen inside of a 
> transaction (regardless of whether a subsequent load happens on every 
> path out of the loop)?  This would definitely be safe and quite easily 
> doable, simply by checking if loads to be hoisted are within a transaction.

If we cannot get the less conservative approach in on time (the one
you've been working on), then we could also use this big hammer.  I
don't quite know how high performance degradation would be (we could
measure number of loads/stores at runtime with STAMP, for example, and I
could build the libitm code for that if you want), but having
publication-safety work correctly in 4.7 might be more important.

> 
> >
> > For hoisting out of or across transactions, we have to reason about more
> > than just publication safety.
> 
> Again, __transactions being barriers and all, I don't think we should 
> complicate things unnecessarily at this point, since it doesn't happen.

Yes.  Based on Richard Guenther's examples, my question was whether your
code (without having actually looked at it ;) ) would also allow
post-dominating loads in nontransactional code to enable hoisting (as in
the __transaction_atomic { if (foo) load; } load case.  I believe only
loads within the same transaction should count, and I wasn't sure
whether you were ensuring that (and/or whether a barrier would enforce
this either).

Torvald

Re: [libitm] Add SPARC bits

[Eric Botcazou]

> We probably want to do some nop'ish thing here which will yield the
> cpu thread on Niagara cpus, I'd recommend something along the lines of
> "rd %ccr, %g0" or "rd %y, %g0"

libgomp has its own idea about cpu_relax:

static inline void
cpu_relax (void)
{
#if defined __arch64__ || defined  __sparc_v9__
  __asm volatile ("membar #LoadLoad" : : : "memory");
#else
  __asm volatile ("" : : : "memory");
#endif
}

Maybe we can come up with a single implementation for libgomp and libitm?

And defined(__sparc_v9__) doesn't work on Solaris so we should drop the 
condition altogether in libgomp.

-- 
Eric Botcazou

Re: [PR51752] publication safety violations in loop invariant motion pass

[Richard Guenther]

On Mon, Feb 27, 2012 at 10:24 AM, Torvald Riegel  wrote:
> On Fri, 2012-02-24 at 10:34 -0600, Aldy Hernandez wrote:
>> On 02/24/12 07:10, Torvald Riegel wrote:
>> > safety.  I didn't have time to look at Aldy's patch yet, but a first
>> > safe and conservative way would be to treat transactions as full
>> > transformation barriers, and prevent publication-safety-violating
>> > transformations _within_ transactions.  Which I would prefer until we're
>> > confident that we understood all of it.
>>
>> Do you mean disallow hoisting of *any* loads that happen inside of a
>> transaction (regardless of whether a subsequent load happens on every
>> path out of the loop)?  This would definitely be safe and quite easily
>> doable, simply by checking if loads to be hoisted are within a transaction.
>
> If we cannot get the less conservative approach in on time (the one
> you've been working on), then we could also use this big hammer.  I
> don't quite know how high performance degradation would be (we could
> measure number of loads/stores at runtime with STAMP, for example, and I
> could build the libitm code for that if you want), but having
> publication-safety work correctly in 4.7 might be more important.
>
>>
>> >
>> > For hoisting out of or across transactions, we have to reason about more
>> > than just publication safety.
>>
>> Again, __transactions being barriers and all, I don't think we should
>> complicate things unnecessarily at this point, since it doesn't happen.
>
> Yes.  Based on Richard Guenther's examples, my question was whether your
> code (without having actually looked at it ;) ) would also allow
> post-dominating loads in nontransactional code to enable hoisting (as in
> the __transaction_atomic { if (foo) load; } load case.  I believe only
> loads within the same transaction should count, and I wasn't sure
> whether you were ensuring that (and/or whether a barrier would enforce
> this either).

We should at this point not disrupt the tree by complex changes to optimizers.
You can try patching tree_could_trap_p, though I am not sure there is enough
context provided, or add a few TM checks in selected places (loop IM and PRE).
We are close to a release.

Richard.

> Torvald
>

Re: [PATCH] PR libffi/52223: Define FLAGS_TO_PASS for libffi

[Jakub Jelinek]

On Thu, Feb 23, 2012 at 01:33:08PM +0100, Mikael Pettersson wrote:
> This problem affects trunk and the 4.6 and 4.5 branches.  4.4 is not
> affected since it doesn't have these man pages.
> 
> See  for a
> similar problem in libquadmath that Joseph Myers fixed last year.
> 
> OK for trunk and affected branches?

Ok for trunk (and checked it in for you).  On older branches please wait a
few days (especially on 4.6 after 4.6.3 is released).

> 2012-02-23  Mikael Pettersson  
> 
>   PR libffi/52223
>   * Makefile.am (FLAGS_TO_PASS): Define.
>   * Makefile.in: Regenerate.

Jakub

Re: [Ada] Small tweak to help GDB to display aliased dynamic array

[Eric Botcazou]

> 2012-01-27  Eric Botcazou  
>
>   * gcc-interface/decl.c (gnat_to_gnu_entity) : For an aliased
>   object with an unconstrained nominal subtype and if optimization isn't
>   enabled, create a special VAR_DECL for debugging purposes.

Unfortunately this isn't robust, so the attached patch is needed instead.

Tested on i586-suse-linux, applied on the mainline.


2012-02-27  Eric Botcazou  

* gcc-interface/decl.c (gnat_to_gnu_entity) : Revert previous
change that creates a special VAR_DECL for debugging purposes.  For an
aliased object with an unconstrained nominal subtype, make its type a
thin reference to the underlying object.
* gcc-interface/utils2.c (build_unary_op) : Deal with
expressions built for the initialization of above objects.


-- 
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 184585)
+++ gcc-interface/decl.c	(working copy)
@@ -1379,6 +1379,49 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	const_flag = true;
 	  }
 
+	/* If this is an aliased object with an unconstrained nominal subtype,
+	   we make its type a thin reference, i.e. the reference counterpart
+	   of a thin pointer, so that it points to the array part.  This is
+	   aimed at making it easier for the debugger to decode the object.
+	   Note that we have to do that this late because of the couple of
+	   allocation adjustments that might be made just above.  */
+	if (Is_Constr_Subt_For_UN_Aliased (Etype (gnat_entity))
+	&& Is_Array_Type (Etype (gnat_entity))
+	&& !type_annotate_only)
+	  {
+	tree gnu_array
+	  = gnat_to_gnu_type (Base_Type (Etype (gnat_entity)));
+
+	/* In case the object with the template has already been allocated
+	   just above, we have nothing to do here.  */
+	if (!TYPE_IS_THIN_POINTER_P (gnu_type))
+	  {
+	gnu_size = NULL_TREE;
+		used_by_ref = true;
+
+		if (definition && !imported_p)
+		  {
+		tree gnu_unc_var
+		  = create_var_decl (concat_name (gnu_entity_name, "UNC"),
+	 NULL_TREE, gnu_type, gnu_expr,
+	 const_flag, Is_Public (gnat_entity),
+	 false, static_p, NULL, gnat_entity);
+		gnu_expr
+		  = build_unary_op (ADDR_EXPR, NULL_TREE, gnu_unc_var);
+		TREE_CONSTANT (gnu_expr) = 1;
+		const_flag = true;
+		  }
+		else
+		  {
+		gnu_expr = NULL_TREE;
+		const_flag = false;
+		  }
+	  }
+
+	gnu_type
+	  = build_reference_type (TYPE_OBJECT_RECORD_TYPE (gnu_array));
+	  }
+
 	if (const_flag)
 	  gnu_type = build_qualified_type (gnu_type, (TYPE_QUALS (gnu_type)
 		  | TYPE_QUAL_CONST));
@@ -1469,41 +1512,6 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	  }
 	  }
 
-	/* If this is an aliased object with an unconstrained nominal subtype
-	   and optimization isn't enabled, create a VAR_DECL for debugging
-	   purposes whose type is a thin reference (the reference counterpart
-	   of a thin pointer), so that it will be directly initialized to the
-	   address of the array part.  */
-	else if (Is_Constr_Subt_For_UN_Aliased (Etype (gnat_entity))
-		 && Is_Array_Type (Etype (gnat_entity))
-		 && !type_annotate_only
-		 && !optimize
-		 && debug_info_p)
-	  {
-	tree gnu_array
-	  = gnat_to_gnu_type (Base_Type (Etype (gnat_entity)));
-	tree gnu_thin_type
-	  = build_reference_type (TYPE_OBJECT_RECORD_TYPE (gnu_array));
-	tree gnu_ref, gnu_debug_decl;
-
-	/* In case the object with the template has already been indirectly
-	   allocated, we have nothing to do here.  */
-	if (TYPE_IS_THIN_POINTER_P (gnu_type))
-	  gnu_ref = gnu_decl;
-	else
-	  gnu_ref = build_unary_op (ADDR_EXPR, NULL_TREE, gnu_decl);
-	gnu_ref = convert (gnu_thin_type, gnu_ref);
-
-	gnu_debug_decl
-	  = create_var_decl (gnu_entity_name, gnu_ext_name,
- gnu_thin_type, NULL_TREE, const_flag,
- Is_Public (gnat_entity), !definition,
- static_p, attr_list, gnat_entity);
-	SET_DECL_VALUE_EXPR (gnu_debug_decl, gnu_ref);
-	DECL_HAS_VALUE_EXPR_P (gnu_debug_decl) = 1;
-	DECL_IGNORED_P (gnu_decl) = 1;
-	  }
-
 	/* If this is a constant and we are defining it or it generates a real
 	   symbol at the object level and we are referencing it, we may want
 	   or need to have a true variable to represent it:
Index: gcc-interface/utils2.c
===
--- gcc-interface/utils2.c	(revision 184585)
+++ gcc-interface/utils2.c	(working copy)
@@ -1365,8 +1365,8 @@ build_unary_op (enum tree_code op_code,
 	default:
 	common:
 
-	  /* If we are taking the address of a padded record whose field is
-	 contains a template, take the address of the template.  */
+	  /* If we are taking the address of a padded record whose field
+	 contains a template, take the address of the field.  */
 	  if (TYPE_IS_PADDING_P (type)
 	  && TREE_CODE (TREE_TYPE (TYPE_FIELDS (type))) 

[Ada] Fix wrong code for assignment from overlapping aggregate

[Eric Botcazou]

This is a regression present on the mainline.  The compiler generates wrong 
code for the assignment to an object of an aggregate that contains a component 
which overlaps with the object, if the object's type is a record type which 
contains at least two nested levels of discriminated record type with default 
discriminant and a component with controlled or tagged type.

Tested on i586-suse-linux, applied on the mainline.


2012-02-27  Eric Botcazou  

* gcc-interface/ada-tree.h (TYPE_PACKED_ARRAY_TYPE_P): Add checking.
(TYPE_BY_REFERENCE_P): New flag.
(TYPE_IS_BY_REFERENCE_P): New macro.
(TYPE_DUMMY_P): Add checking and remove VOID_TYPE.
(TYPE_IS_DUMMY_P): Adjust for above change.
* gcc-interface/decl.c (gnat_to_gnu_entity): Use TYPE_BY_REFERENCE_P
and TYPE_IS_BY_REFERENCE_P instead of TREE_ADDRESSABLE.
(gnat_to_gnu_param): Likewise.
(maybe_pad_type): Likewise.
(make_type_from_size): Use TYPE_IS_PACKED_ARRAY_TYPE_P.
* gcc-interface/misc.c (must_pass_by_ref): Use TYPE_IS_BY_REFERENCE_P
instead of TREE_ADDRESSABLE.
* gcc-interface/trans.c (finalize_nrv): Likewise.
(call_to_gnu): Likewise.  Do not create a temporary for return values
with by-reference type here.
(gnat_to_gnu): Test TYPE_IS_DUMMY_P instead of TYPE_DUMMY_P.
(gnat_gimplify_expr) : Don't do anything for non-constant
CONSTRUCTORs and calls.
* gcc-interface/utils.c (make_dummy_type): Get the equivalent type of
the underlying type and use it throughout.  Use TYPE_IS_BY_REFERENCE_P
instead of TREE_ADDRESSABLE.
* gcc-interface/utils2.c (build_cond_expr): Deal with by-reference
types explicitly.


2012-02-27  Eric Botcazou  

* gnat.dg/aggr19.adb: New test.
* gnat.dg/aggr19_pkg.ad[sb]: New helper.


-- 
Eric Botcazou
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c	(revision 184585)
+++ gcc-interface/utils.c	(working copy)
@@ -291,7 +291,7 @@ make_dummy_type (Entity_Id gnat_type)
 
   /* If there is an equivalent type, get its underlying type.  */
   if (Present (gnat_underlying))
-gnat_underlying = Underlying_Type (gnat_underlying);
+gnat_underlying = Gigi_Equivalent_Type (Underlying_Type (gnat_underlying));
 
   /* If there was no equivalent type (can only happen when just annotating
  types) or underlying type, go back to the original type.  */
@@ -311,8 +311,8 @@ make_dummy_type (Entity_Id gnat_type)
   TYPE_DUMMY_P (gnu_type) = 1;
   TYPE_STUB_DECL (gnu_type)
 = create_type_stub_decl (TYPE_NAME (gnu_type), gnu_type);
-  if (Is_By_Reference_Type (gnat_type))
-TREE_ADDRESSABLE (gnu_type) = 1;
+  if (Is_By_Reference_Type (gnat_underlying))
+TYPE_BY_REFERENCE_P (gnu_type) = 1;
 
   SET_DUMMY_NODE (gnat_underlying, gnu_type);
 
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 184593)
+++ gcc-interface/decl.c	(working copy)
@@ -4144,7 +4144,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	  return_by_invisi_ref_p = true;
 
 	/* Likewise, if the return type is itself By_Reference.  */
-	else if (TREE_ADDRESSABLE (gnu_return_type))
+	else if (TYPE_IS_BY_REFERENCE_P (gnu_return_type))
 	  return_by_invisi_ref_p = true;
 
 	/* If the type is a padded type and the underlying type would not
@@ -4673,10 +4673,9 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	  || Is_Class_Wide_Equivalent_Type (gnat_entity))
 	TYPE_ALIGN_OK (gnu_type) = 1;
 
-  /* If the type is passed by reference, objects of this type must be
-	 fully addressable and cannot be copied.  */
-  if (Is_By_Reference_Type (gnat_entity))
-	TREE_ADDRESSABLE (gnu_type) = 1;
+  /* Record whether the type is passed by reference.  */
+  if (!VOID_TYPE_P (gnu_type) && Is_By_Reference_Type (gnat_entity))
+	TYPE_BY_REFERENCE_P (gnu_type) = 1;
 
   /* ??? Don't set the size for a String_Literal since it is either
 	 confirming or we don't handle it properly (if the low bound is
@@ -5621,7 +5620,7 @@ gnat_to_gnu_param (Entity_Id gnat_param,
 	 parameters whose type isn't by-ref and for which the mechanism hasn't
 	 been forced to by-ref are restrict-qualified in the C sense.  */
   bool restrict_p
-	= !TREE_ADDRESSABLE (gnu_param_type) && mech != By_Reference;
+	= !TYPE_IS_BY_REFERENCE_P (gnu_param_type) && mech != By_Reference;
   gnu_param_type = build_reference_type (gnu_param_type);
   if (restrict_p)
 	gnu_param_type
@@ -6653,7 +6652,7 @@ maybe_pad_type (tree type, tree size, un
   if (align != 0
   && RECORD_OR_UNION_TYPE_P (type)
   && TYPE_MODE (type) == BLKmode
-  && !TREE_ADDRESSABLE (type)
+  && !TYPE_BY_REFERENCE_P (type)
   && TREE_CODE (orig_size) == INTEGER_CST
   && !TREE_OVERFLOW (orig_size)
   && compare_tree_int (orig_size, MAX_FIXED_MO

GCC 4.7.0 Status Report (2012-02-27)

[Richard Guenther]

Status
==

The trunk is still in regression and documentation fixes only state
(so-called stage4).

We have reached a point where it is sufficiently stable for a first
release candidate.  If there appear no serious release blockers in
the next few days expect a release candidate this week.  As soon
as the release candidate is made all further changes to trunk will
require explicit release-manager approval.  This means it is a good
idea to stabilize your non-primary/secondary targets now, otherwise
you will be left behind with a release that is broken for your target.

We do have still P1 classified bugs, but easy workarounds are possible
for them or they have a patch already.


Quality Data


Priority  #   Change from Last Report
---   ---
P12   -  3 
P2   70   +  6 
P32   -  9 
---   ---
Total74   -  6


Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-01/msg00337.html

The next report will be sent by Jakub.

Re: Unreviewed libstdc++/libgomp patch

[Rainer Orth]

Jakub Jelinek  writes:

> On Wed, Feb 22, 2012 at 12:07:39PM +0100, Rainer Orth wrote:
>> The following patch has remained unreviewed for a week:
>> 
>>  [v3, libgomp, build] Fix Solaris symbol versioning (PR libstdc++/52188)
>> http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00819.html
>> 
>> It is critical to avoid breaking libstdc++.so symbol versioning on
>> Solaris and requires libstdc++ and libgomp maintainers.
>
> The libgomp changes are ok if the libstdc++ changes are approved.

Thanks.  Unfortunately, none of the libstdc++ maintainers hasn't
commented in almost two weeks.  It would be a pity to release 4.7.0 with
this bug unfixed.

Rainer

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

Re: Unreviewed libstdc++/libgomp patch

[Paolo Carlini]

Hi,

Jakub Jelinek  writes:


On Wed, Feb 22, 2012 at 12:07:39PM +0100, Rainer Orth wrote:

The following patch has remained unreviewed for a week:

[v3, libgomp, build] Fix Solaris symbol versioning (PR libstdc++/52188)
 http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00819.html

It is critical to avoid breaking libstdc++.so symbol versioning on
Solaris and requires libstdc++ and libgomp maintainers.

The libgomp changes are ok if the libstdc++ changes are approved.

Thanks.  Unfortunately, none of the libstdc++ maintainers hasn't
commented in almost two weeks.  It would be a pity to release 4.7.0 with
this bug unfixed.
I cannot say to understand in detail the issue, but if it affects 
Solaris only, likewise the fix (I think so), and you double checked it 
on, say, x86_64-Linux, the patch is Ok with me.


Thanks!
Paolo.

Re: Unreviewed libstdc++/libgomp patch

[Rainer Orth]

Paolo Carlini  writes:

>> Jakub Jelinek  writes:
>>
>>> On Wed, Feb 22, 2012 at 12:07:39PM +0100, Rainer Orth wrote:
 The following patch has remained unreviewed for a week:

[v3, libgomp, build] Fix Solaris symbol versioning (PR libstdc++/52188)
  http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00819.html

 It is critical to avoid breaking libstdc++.so symbol versioning on
 Solaris and requires libstdc++ and libgomp maintainers.
>>> The libgomp changes are ok if the libstdc++ changes are approved.
>> Thanks.  Unfortunately, none of the libstdc++ maintainers hasn't
>> commented in almost two weeks.  It would be a pity to release 4.7.0 with
>> this bug unfixed.
> I cannot say to understand in detail the issue, but if it affects Solaris
> only, likewise the fix (I think so), and you double checked it on, say,
> x86_64-Linux, the patch is Ok with me.

While the mechanism introduced is generic, it currently affects Solaris
only.  And yes, I've compared versioning in libstdc++.so and libgomp.so
on x86_64-unknown-linux-gnu without and with the patch as described in
the submission: no change.

Thanks.
Rainer

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

[PATCH, i386]: Fix *movabs_1 constraints

[Uros Bizjak]

Hello!

We should not use "e" constraint for QI/HImode immediates. Fixed by
using correct mode attribute.

2012-02-27  Uros Bizjak  

* config/i386/i386.md (*movabs_1): Fix operand 1 constraints.

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

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 184591)
+++ config/i386/i386.md (working copy)
@@ -2361,7 +2361,7 @@
 ;; into register when rax is not available
 (define_insn "*movabs_1"
   [(set (mem:SWI1248x (match_operand:DI 0 "x86_64_movabs_operand" "i,r"))
-   (match_operand:SWI1248x 1 "nonmemory_operand" "a,er"))]
+   (match_operand:SWI1248x 1 "nonmemory_operand" "a,r"))]
   "TARGET_64BIT && ix86_check_movabs (insn, 0)"
   "@
movabs{}\t{%1, %P0|%P0, %1}

Re: Unreviewed libstdc++/libgomp patch

[Paolo Carlini]

On 02/27/2012 02:38 PM, Rainer Orth wrote:
While the mechanism introduced is generic, it currently affects 
Solaris only. And yes, I've compared versioning in libstdc++.so and 
libgomp.so on x86_64-unknown-linux-gnu without and with the patch as 
described in the submission: no change.

Excellent.

Thanks again,
Paolo.

Re: [PATCH, i386, Android] Enable __ANDROID__ macro for Android i386 target

[Ilya Enkovich]

>
> Undef TARGET_OS_CPP_BUILTINS and define TARGET_OS_CPP_BUILTINS
> in linux.h with GNU_USER_TARGET_OS_CPP_BUILTINS and
> ANDROID_TARGET_OS_CPP_BUILTINS.
>
>
> --
> H.J.

Hello,

Here is a variant with linux.h modification. Does it look fine?

Thanks,
Ilya
--
2012-02-27  Enkovich Ilya  

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


diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
index 73681fe..03c7b29 100644
--- a/gcc/config/i386/linux.h
+++ b/gcc/config/i386/linux.h
@@ -22,3 +22,12 @@ along with GCC; see the file COPYING3.  If not see

 #define GNU_USER_LINK_EMULATION "elf_i386"
 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   GNU_USER_TARGET_OS_CPP_BUILTINS();  \
+   ANDROID_TARGET_OS_CPP_BUILTINS();   \
+}  \
+  while (0)

Re: [PATCH, i386, Android] -mandroid support for i386 target

[Ilya Enkovich]

> You should keep those *_SPEC and define them with new
> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
> by other non-linux targets.  In linux.h, you undef *_SPEC
> before defining them.
>
>
> --
> H.J.

Thanks for the note. Here is fixed version. Is it OK now?

Thanks,
Ilya
--
2012-02-27  Enkovich Ilya  

* gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New.
(CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC.
(GNU_USER_TARGET_LINK_SPEC): New.
(LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
(GNU_USER_TARGET_MATHFILE_SPEC): New.
(ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC.

* gcc/config/i386/linux.h (CC1_SPEC): New.
(LINK_SPEC): New.
(LIB_SPEC): New.
(STARTFILE_SPEC): New.
(ENDFILE_SPEC): New.


diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
index 98d0a25..33ceab7 100644
--- a/gcc/config/i386/gnu-user.h
+++ b/gcc/config/i386/gnu-user.h
@@ -77,8 +77,11 @@ along with GCC; see the file COPYING3.  If not see
 #undef CPP_SPEC
 #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"

+#undef GNU_USER_TARGET_CC1_SPEC
+#define GNU_USER_TARGET_CC1_SPEC "%(cc1_cpu) %{profile:-p}"
+
 #undef CC1_SPEC
-#define CC1_SPEC "%(cc1_cpu) %{profile:-p}"
+#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC

 /* Provide a LINK_SPEC appropriate for GNU userspace.  Here we provide support
for the special GCC options -static and -shared, which allow us to
@@ -97,22 +100,28 @@ along with GCC; see the file COPYING3.  If not see
   { "link_emulation", GNU_USER_LINK_EMULATION },\
   { "dynamic_linker", GNU_USER_DYNAMIC_LINKER }

-#undef LINK_SPEC
-#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \
+#define GNU_USER_TARGET_LINK_SPEC \
+  "-m %(link_emulation) %{shared:-shared} \
   %{!shared: \
 %{!static: \
   %{rdynamic:-export-dynamic} \
   -dynamic-linker %(dynamic_linker)} \
   %{static:-static}}"

+#undef LINK_SPEC
+#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC
+
 /* Similar to standard GNU userspace, but adding -ffast-math support.  */
-#undef  ENDFILE_SPEC
-#define ENDFILE_SPEC \
+#define GNU_USER_TARGET_MATHFILE_SPEC \
   "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
%{mpc32:crtprec32.o%s} \
%{mpc64:crtprec64.o%s} \
-   %{mpc80:crtprec80.o%s} \
-   %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+   %{mpc80:crtprec80.o%s}"
+
+#undef  ENDFILE_SPEC
+#define ENDFILE_SPEC \
+  GNU_USER_TARGET_MATHFILE_SPEC " " \
+  GNU_USER_TARGET_ENDFILE_SPEC

 /* A C statement (sans semicolon) to output to the stdio stream
FILE the assembler definition of uninitialized global DECL named
diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
index 73681fe..a832ddc 100644
--- a/gcc/config/i386/linux.h
+++ b/gcc/config/i386/linux.h
@@ -22,3 +22,30 @@ along with GCC; see the file COPYING3.  If not see

 #define GNU_USER_LINK_EMULATION "elf_i386"
 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+
+#undef CC1_SPEC
+#define CC1_SPEC \
+  LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \
+  GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC)
+
+#undef LINK_SPEC
+#define LINK_SPEC \
+  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \
+  GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC)
+
+#undef  LIB_SPEC
+#define LIB_SPEC \
+  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \
+  GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC)
+
+#undef  STARTFILE_SPEC
+#define STARTFILE_SPEC \
+  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \
+  ANDROID_STARTFILE_SPEC)
+
+#undef  ENDFILE_SPEC
+#define ENDFILE_SPEC \
+  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \
+  GNU_USER_TARGET_ENDFILE_SPEC, \
+  GNU_USER_TARGET_MATHFILE_SPEC " " \
+  ANDROID_ENDFILE_SPEC)

[PATCH] Fix a fallout from my recent ipa-split change (PR tree-optimization/52376)

[Jakub Jelinek]

Hi!

One missing spot where clobber stmts need to be ignored.
Testcase needs profile feedback and is quite large, so not
adding it to testsuite; bootstrapped/regtested on x86_64-linux
and i686-linux, approved by richi in the PR, committed to trunk.

2012-02-27  Jakub Jelinek  

PR tree-optimization/52376
* ipa-split.c (split_function): Ignore CLOBBER stmts.

--- gcc/ipa-split.c.jj  2012-02-27 10:00:29.0 +0100
+++ gcc/ipa-split.c 2012-02-27 10:33:03.909581822 +0100
@@ -1300,7 +1300,8 @@ split_function (struct split_point *spli
gimple_return_set_retval (gsi_stmt (bsi), retval);
break;
  }
-   else if (gimple_code (gsi_stmt (bsi)) == GIMPLE_ASSIGN)
+   else if (gimple_code (gsi_stmt (bsi)) == GIMPLE_ASSIGN
+&& !gimple_clobber_p (gsi_stmt (bsi)))
  {
gimple_assign_set_rhs1 (gsi_stmt (bsi), retval);
break;

Jakub

[PATCH] Fix ARM neon vashr3 and vlshr3 expanders (PR target/52375)

[Jakub Jelinek]

Hi!

We ICE shortly after expansion on this testcase, because
vlshrv4si3 expander is called with a SUBREG as operands[2],
but we were testing just for REG_P, and in the other branch
we assume that it is an immediate.  But there is no right shift
with register shift count.

Fixed thusly, additionally moved the neg initialization down into
the scope in which it is used to avoid creating a pseudo needlessly.
Ok for trunk?

2012-02-27  Jakub Jelinek  

PR target/52375
* config/arm/neon.md (vashr3, vlshr3): Use
s_register_operand in the test instead of REG_P.  Don't call
gen_reg_rtx if it won't be used.

* gcc.target/arm/pr52375.c: New test.
* gcc.c-torture/compile/pr52375.c: New test.

--- gcc/config/arm/neon.md.jj   2012-01-20 12:35:15.0 +0100
+++ gcc/config/arm/neon.md  2012-02-27 13:03:42.981798700 +0100
@@ -1064,9 +1064,9 @@ (define_expand "vashr3"
(match_operand:VDQIW 2 "imm_rshift_or_reg_neon" "")))]
   "TARGET_NEON"
 {
-  rtx neg = gen_reg_rtx (mode);
-  if (REG_P (operands[2]))
+  if (s_register_operand (operands[2], mode))
 {
+  rtx neg = gen_reg_rtx (mode);
   emit_insn (gen_neg2 (neg, operands[2]));
   emit_insn (gen_ashl3_signed (operands[0], operands[1], neg));
 }
@@ -1081,9 +1081,9 @@ (define_expand "vlshr3"
(match_operand:VDQIW 2 "imm_rshift_or_reg_neon" "")))]
   "TARGET_NEON"
 {
-  rtx neg = gen_reg_rtx (mode);
-  if (REG_P (operands[2]))
+  if (s_register_operand (operands[2], mode))
 {
+  rtx neg = gen_reg_rtx (mode);
   emit_insn (gen_neg2 (neg, operands[2]));
   emit_insn (gen_ashl3_unsigned (operands[0], operands[1], neg));
 }
--- gcc/testsuite/gcc.target/arm/pr52375.c.jj   2012-02-27 13:16:27.679449171 
+0100
+++ gcc/testsuite/gcc.target/arm/pr52375.c  2012-02-27 13:01:04.0 
+0100
@@ -0,0 +1,15 @@
+/* PR target/52375 */
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_neon_ok } */
+/* { dg-options "-march=armv7-a -mfloat-abi=hard -mfpu=neon -O 
-ftree-vectorize" } */
+
+struct C { int c, d; };
+
+unsigned
+foo (struct C *p)
+{
+  unsigned int b = 0, i;
+  for (i = 0; i < 64; i++)
+b |= 0x8000U >> p[i].c;
+  return b;
+}
--- gcc/testsuite/gcc.c-torture/compile/pr52375.c.jj2012-02-27 
13:16:46.263345654 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr52375.c   2012-02-27 
13:16:50.221320554 +0100
@@ -0,0 +1,12 @@
+/* PR target/52375 */
+
+struct C { int c, d; };
+
+unsigned
+foo (struct C *p)
+{
+  unsigned int b = 0, i;
+  for (i = 0; i < 64; i++)
+b |= 0x8000U >> p[i].c;
+  return b;
+}

Jakub

[PATCH] Further update baseline_symbols.txt

[Jakub Jelinek]

Hi!

Apparently after I've updated baseline_symbols.txt
files for a couple of targets Jonathan added some extra
exported symbols.  This patch adds them.
Ok for trunk?

2012-02-27  Jakub Jelinek  

* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt:
Likewise.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/s390-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Likewise.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Likewise.

--- libstdc++-v3/config/abi/post/s390x-linux-gnu/baseline_symbols.txt.jj
2012-02-03 12:56:06.592929540 +0100
+++ libstdc++-v3/config/abi/post/s390x-linux-gnu/baseline_symbols.txt   
2012-02-27 15:55:04.769584801 +0100
@@ -1441,6 +1441,9 @@ FUNC:_ZNSt13__future_base12_Result_baseC
 FUNC:_ZNSt13__future_base12_Result_baseD0Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt13__future_base12_Result_baseD1Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt13__future_base12_Result_baseD2Ev@@GLIBCXX_3.4.15
+FUNC:_ZNSt13__future_base19_Async_state_commonD0Ev@@GLIBCXX_3.4.17
+FUNC:_ZNSt13__future_base19_Async_state_commonD1Ev@@GLIBCXX_3.4.17
+FUNC:_ZNSt13__future_base19_Async_state_commonD2Ev@@GLIBCXX_3.4.17
 FUNC:_ZNSt13bad_exceptionD0Ev@@GLIBCXX_3.4
 FUNC:_ZNSt13bad_exceptionD1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt13bad_exceptionD2Ev@@GLIBCXX_3.4
@@ -3225,6 +3228,7 @@ OBJECT:24:_ZTIN9__gnu_cxx13stdio_filebuf
 OBJECT:24:_ZTIN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4
 
OBJECT:24:_ZTIN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE@@GLIBCXX_3.4
 
OBJECT:24:_ZTIN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4
+OBJECT:24:_ZTINSt13__future_base19_Async_state_commonE@@GLIBCXX_3.4.17
 
OBJECT:24:_ZTINSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIc@@GLIBCXX_LDBL_3.4
 
OBJECT:24:_ZTINSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIw@@GLIBCXX_LDBL_3.4
 
OBJECT:24:_ZTINSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIc@@GLIBCXX_LDBL_3.4
@@ -3479,6 +3483,7 @@ OBJECT:40:_ZTSSt14basic_ofstreamIcSt11ch
 OBJECT:40:_ZTSSt14basic_ofstreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
 OBJECT:40:_ZTVNSt13__future_base11_State_baseE@@GLIBCXX_3.4.15
 OBJECT:40:_ZTVNSt13__future_base12_Result_baseE@@GLIBCXX_3.4.15
+OBJECT:40:_ZTVNSt13__future_base19_Async_state_commonE@@GLIBCXX_3.4.17
 OBJECT:40:_ZTVNSt8ios_base7failureE@@GLIBCXX_3.4
 OBJECT:40:_ZTVSt10bad_typeid@@GLIBCXX_3.4
 OBJECT:40:_ZTVSt10lock_error@@GLIBCXX_3.4.11
@@ -3504,6 +3509,7 @@ OBJECT:40:_ZTVSt8time_putIcSt19ostreambu
 
OBJECT:40:_ZTVSt8time_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE@@GLIBCXX_3.4
 OBJECT:40:_ZTVSt9bad_alloc@@GLIBCXX_3.4
 OBJECT:40:_ZTVSt9exception@@GLIBCXX_3.4
+OBJECT:41:_ZTSNSt13__future_base19_Async_state_commonE@@GLIBCXX_3.4.17
 OBJECT:41:_ZTSSt15basic_streambufIcSt11char_traitsIcEE@@GLIBCXX_3.4
 OBJECT:41:_ZTSSt15basic_streambufIwSt11char_traitsIwEE@@GLIBCXX_3.4
 OBJECT:45:_ZTSSt23__codecvt_abstract_baseIcc11__mbstate_tE@@GLIBCXX_3.4
--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj   
2012-02-03 12:56:06.595929520 +0100
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
2012-02-27 15:55:14.846585202 +0100
@@ -1295,6 +1295,9 @@ FUNC:_ZNSt13__future_base12_Result_baseC
 FUNC:_ZNSt13__future_base12_Result_baseD0Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt13__future_base12_Result_baseD1Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt13__future_base12_Result_baseD2Ev@@GLIBCXX_3.4.15
+FUNC:_ZNSt13__future_base19_Async_state_commonD0Ev@@GLIBCXX_3.4.17
+FUNC:_ZNSt13__future_base19_Async_state_commonD1Ev@@GLIBCXX_3.4.17
+FUNC:_ZNSt13__future_base19_Async_state_commonD2Ev@@GLIBCXX_3.4.17
 FUNC:_ZNSt13bad_exceptionD0Ev@@GLIBCXX_3.4
 FUNC:_ZNSt13bad_exceptionD1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt13bad_exceptionD2Ev@@GLIBCXX_3.4
@@ -2970,6 +2973,7 @@ OBJECT:24:_ZTIN9__gnu_cxx13stdio_filebuf
 OBJECT:24:_ZTIN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4
 
OBJECT:24:_ZTIN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE@@GLIBCXX_3.4
 
OBJECT:24:_ZTIN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4
+OBJECT:24:_ZTINSt13__future_base19_Async_state_commonE@@GLIBCXX_3.4.17
 OBJECT:24:_ZTINSt8ios_base7failureE@@GLIBCXX_3.4
 OBJECT:24:_ZTISt10bad_typeid@@GLIBCXX_3.4
 OBJECT:24:_ZTISt10istrstream@@GLIBCXX_3.4
@@ -3212,6 +3216,7 @@ OBJECT:40:_ZTSSt14basic_ofstreamIcSt11ch
 OBJECT:40:_ZTSSt14basic_ofstreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
 OBJECT:40:_ZTVNSt13__future_base11_State_baseE@@GLIBCXX_3.4.15
 OBJECT:40:_ZTVNSt13__future_base12_Result_baseE@@GLIBCXX_3.4.15
+OBJECT:40:_ZTVNSt13

Re: [PATCH] Further update baseline_symbols.txt

[Jonathan Wakely]

On 27 February 2012 15:18, Jakub Jelinek wrote:
> Hi!
>
> Apparently after I've updated baseline_symbols.txt
> files for a couple of targets Jonathan added some extra
> exported symbols.  This patch adds them.
> Ok for trunk?

OK - thanks.

Re: [PATCH] Fix ARM neon vashr3 and vlshr3 expanders (PR target/52375)

[Richard Earnshaw]

On 27/02/12 15:12, Jakub Jelinek wrote:
> Hi!
> 
> We ICE shortly after expansion on this testcase, because
> vlshrv4si3 expander is called with a SUBREG as operands[2],
> but we were testing just for REG_P, and in the other branch
> we assume that it is an immediate.  But there is no right shift
> with register shift count.
> 
> Fixed thusly, additionally moved the neg initialization down into
> the scope in which it is used to avoid creating a pseudo needlessly.
> Ok for trunk?
> 
> 2012-02-27  Jakub Jelinek  
> 
>   PR target/52375
>   * config/arm/neon.md (vashr3, vlshr3): Use
>   s_register_operand in the test instead of REG_P.  Don't call
>   gen_reg_rtx if it won't be used.
> 
>   * gcc.target/arm/pr52375.c: New test.
>   * gcc.c-torture/compile/pr52375.c: New test.
> 

OK.

R.

[commit, testsuite, spu] Two obvious testsuite fixes for SPU

[Ulrich Weigand]

Hello,

two new testcases were failing on SPU for the "usual" reasons:

- gfortran.dg/typebound_operator_9.f03 tries to allocate too much memory
- gcc.dg/torture/builtin-complex-1.c assumes IEEE semantics (Inf/Nan),
  which isn't supported for single-precision float on SPU

The following patch fixes those by skipping the test (or the parts of
the test that use "float") in the same way these problems were handled
before in other test cases.

Tested on spu-elf, committed to mainline as obvious.

Bye,
Ulrich


ChangeLog:

* gfortran.dg/typebound_operator_9.f03: Skip on SPU.
* gcc.dg/torture/builtin-complex-1.c: Skip "float" tests on SPU.

Index: gcc/testsuite/gfortran.dg/typebound_operator_9.f03
===
*** gcc/testsuite/gfortran.dg/typebound_operator_9.f03  (revision 184503)
--- gcc/testsuite/gfortran.dg/typebound_operator_9.f03  (working copy)
***
*** 1,5 
--- 1,6 
  ! { dg-do run }
  ! { dg-add-options ieee }
+ ! { dg-skip-if "Too big for local store" { spu-*-* } { "*" } { "" } }
  !
  ! Solve a diffusion problem using an object-oriented approach
  !
Index: gcc/testsuite/gcc.dg/torture/builtin-complex-1.c
===
*** gcc/testsuite/gcc.dg/torture/builtin-complex-1.c(revision 184503)
--- gcc/testsuite/gcc.dg/torture/builtin-complex-1.c(working copy)
*** extern void abort (void);
*** 18,28 
--- 18,30 
abort ();   
\
} while (0)
  
+ #ifndef __SPU__
  void
  comparef (float a, float b)
  {
COMPARE_BODY (a, b, float, __builtin_copysignf);
  }
+ #endif
  
  void
  compare (double a, double b)
*** comparel (long double a, long double b)
*** 36,47 
--- 38,51 
COMPARE_BODY (a, b, long double, __builtin_copysignl);
  }
  
+ #ifndef __SPU__
  void
  comparecf (_Complex float a, float r, float i)
  {
comparef (__real__ a, r);
comparef (__imag__ a, i);
  }
+ #endif
  
  void
  comparec (_Complex double a, double r, double i)
*** comparecl (_Complex long double a, long 
*** 90,97 
--- 94,103 
  void
  check_float (void)
  {
+ #ifndef __SPU__
ALL_CHECKS (0.0f, -0.0f, __builtin_nanf(""), __builtin_inff(),
  float, comparecf);
+ #endif
  }
  
  void
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

[PATCH] Fix PR52395

[Richard Guenther]

This makes the patch for PR50444 less conservative by also looking
at TYPE_ALIGN of the base we offset.  I guess we do not need to
worry about the '???' as IPA SRA uses sth different (see PR52402)
and the only case I definitely see only creates an address of the
generated access.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

I'm leaving this one for comments until tomorrow.

Richard.

2012-02-27  Richard Guenther  

PR tree-optimization/52395
* tree-sra.c (build_ref_for_offset): Also look at the base
TYPE_ALIGN when figuring out the alignment of the replacement.

Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c  (revision 184591)
+++ gcc/tree-sra.c  (working copy)
@@ -1526,10 +1526,12 @@ build_ref_for_offset (location_t loc, tr
  we can extract more optimistic alignment information
  by looking at the access mode.  That would constrain the
  alignment of base + base_offset which we would need to
- adjust according to offset.
- ???  But it is not at all clear that prev_base is an access
- that was in the IL that way, so be conservative for now.  */
+ adjust according to offset.  */
   align = get_pointer_alignment_1 (base, &misalign);
+  if (misalign == 0
+  && (TREE_CODE (prev_base) == MEM_REF
+ || TREE_CODE (prev_base) == TARGET_MEM_REF))
+align = MAX (align, TYPE_ALIGN (TREE_TYPE (prev_base)));
   misalign += (double_int_sext (tree_to_double_int (off),
TYPE_PRECISION (TREE_TYPE (off))).low
   * BITS_PER_UNIT);

[PATCH] Fix PR52402

[Richard Guenther]

This fixes PR52402 in a similar way as PR50444.  IPA SRA needs to be
careful about alignment when constructing accesses.

Bootstrap and regtest pending on x86_64, any comments?

Thanks,
Richard.

2012-02-27  Richard Guenther  

PR tree-optimization/52402
* ipa-prop.c (ipa_modify_call_arguments): Properly use
mis-aligned types when creating the accesses at the call site.

* gcc.dg/torture/pr52402.c: New testcase.

Index: gcc/ipa-prop.c
===
*** gcc/ipa-prop.c  (revision 184591)
--- gcc/ipa-prop.c  (working copy)
*** ipa_modify_call_arguments (struct cgraph
*** 2508,2516 
}
}
  
! expr = fold_build2_loc (loc, MEM_REF, adj->type, base, off);
! if (adj->by_ref)
!   expr = build_fold_addr_expr (expr);
  
  expr = force_gimple_operand_gsi (&gsi, expr,
   adj->by_ref
--- 2508,2534 
}
}
  
! if (!adj->by_ref)
!   {
! tree type = adj->type;
! unsigned int align;
! unsigned HOST_WIDE_INT misalign;
! align = get_pointer_alignment_1 (base, &misalign);
! misalign += (double_int_sext (tree_to_double_int (off),
!   TYPE_PRECISION (TREE_TYPE 
(off))).low
!  * BITS_PER_UNIT);
! misalign = misalign & (align - 1);
! if (misalign != 0)
!   align = (misalign & -misalign);
! if (align < TYPE_ALIGN (type))
!   type = build_aligned_type (type, align);
! expr = fold_build2_loc (loc, MEM_REF, type, base, off);
!   }
! else
!   {
! expr = fold_build2_loc (loc, MEM_REF, adj->type, base, off);
! expr = build_fold_addr_expr (expr);
!   }
  
  expr = force_gimple_operand_gsi (&gsi, expr,
   adj->by_ref
Index: gcc/testsuite/gcc.dg/torture/pr52402.c
===
*** gcc/testsuite/gcc.dg/torture/pr52402.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr52402.c  (revision 0)
***
*** 0 
--- 1,28 
+ /* { dg-do run } */
+ 
+ typedef int v4si __attribute__((vector_size(16)));
+ struct T { v4si i[2]; int j; } __attribute__((packed));
+ 
+ static v4si __attribute__((noinline))
+ foo (struct T t)
+ {
+   return t.i[0];
+ }
+ 
+ static struct T *__attribute__((noinline))
+ init ()
+ {
+   char *p = __builtin_malloc (sizeof (struct T) + 1);
+   p++;
+   __builtin_memset (p, 1, sizeof (struct T));
+   return (struct T *)p;
+ }
+ 
+ int main()
+ {
+   struct T *p;
+   p = init ();
+   if (foo (*p)[0] != 0x01010101)
+ __builtin_abort ();
+   return 0;
+ }

[PATCH] Fix PR52400

[Richard Guenther]

This fixes PR52400 - we cannot register renamed decl mappings when
we can have name duplicates.  Which we trivially can have with
local fn decls.  At least the reverse mapping should no longer be
necessary as the alias pair handling has been rewritten to work
on the cgraph level.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2012-02-27  Richard Guenther  

PR lto/52400
* lto.c (lto_register_function_decl_in_symtab): Do not register
a reverse renamed decl mapping.

* g++.dg/lto/pr52400_0.C: New testcase.

Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c   (revision 184591)
+++ gcc/lto/lto.c   (working copy)
@@ -689,13 +689,6 @@ lto_register_function_decl_in_symtab (st
  lto_record_renamed_decl (data_in->file_data,
   IDENTIFIER_POINTER (old_assembler_name),
   IDENTIFIER_POINTER (new_assembler_name));
-
- /* Also register the reverse mapping so that we can find the
-new name given to an existing assembler name (used when
-restoring alias pairs in input_constructors_or_inits.  */
- lto_record_renamed_decl (data_in->file_data,
-  IDENTIFIER_POINTER (new_assembler_name),
-  IDENTIFIER_POINTER (old_assembler_name));
}
 }
 
Index: gcc/testsuite/g++.dg/lto/pr52400_0.C
===
--- gcc/testsuite/g++.dg/lto/pr52400_0.C(revision 0)
+++ gcc/testsuite/g++.dg/lto/pr52400_0.C(revision 0)
@@ -0,0 +1,18 @@
+// { dg-lto-do run }
+
+extern "C" {
+  static int f4(int);
+
+int f5(int a) {
+  extern int f4(int);
+  return f4(a);
+}
+}
+
+int f4(int a) { return 4+a; }
+
+int main(int argc, char *argv[])
+{
+  int a = f4(1);
+  return !(a == 5);
+}

Re: [patch libgcc]: Fix float128 soft-float for mingw targets

[Joseph S. Myers]

On Mon, 27 Feb 2012, Kai Tietz wrote:

> 2012-02-27  Kai Tietz  
> 
>   * soft-fp/quad.h: Mark bitfield-structures as gcc_struct.
> 
> Regression tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-linux-gnu for all languages (including Ada + Obj-C++).
> Ok for apply?

As explained in codingconventions.html, soft-fp is imported from glibc.  
For files that come from glibc, you can only copy in the glibc versions, 
unchanged.

Thus, you should submit this fix to libc-alpha.  You'll need to explain 
what the differences in struct layout actually are.  In my view, rather 
than adding any __MINGW32__ conditionals in the header, you should instead 
have an _FP_STRUCT_LAYOUT macro that sfp-machine.h can define, and that 
soft-fp.h defines to empty if not defined in sfp-machine.h.  That way 
quad.h can use _FP_STRUCT_LAYOUT and you avoid any conditionals on 
__MINGW32__ in any of the core soft-fp code.

I would have expected any struct layout issue to apply to the other 
headers (single.h, double.h, extended.h) just as to quad.h, so if you're 
only changing one header you'll need to explain why the issue doesn't 
affect the others.

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

Re: [PR51752] publication safety violations in loop invariant motion pass

[Aldy Hernandez]

Again, __transactions being barriers and all, I don't think we should
complicate things unnecessarily at this point, since it doesn't happen.


Yes.  Based on Richard Guenther's examples, my question was whether your
code (without having actually looked at it ;) ) would also allow
post-dominating loads in nontransactional code to enable hoisting (as in
the __transaction_atomic { if (foo) load; } load case.  I believe only
loads within the same transaction should count, and I wasn't sure
whether you were ensuring that (and/or whether a barrier would enforce
this either).


In my patch, post-dominating loads in nontransactional code is fair game 
for hoisting, and will get hoisted out.  However, tweaking it to make 
sure this post-dominating load occurs in a transaction is trivial since 
we have a bitmap of all BBs in transactions.

Re: [patch libgcc]: Fix float128 soft-float for mingw targets

[Kai Tietz]

2012/2/27 Joseph S. Myers :
> As explained in codingconventions.html, soft-fp is imported from glibc.
> For files that come from glibc, you can only copy in the glibc versions,
> unchanged.

Ok, thanks for explaination.

> Thus, you should submit this fix to libc-alpha.  You'll need to explain
> what the differences in struct layout actually are.  In my view, rather
> than adding any __MINGW32__ conditionals in the header, you should instead
> have an _FP_STRUCT_LAYOUT macro that sfp-machine.h can define, and that
> soft-fp.h defines to empty if not defined in sfp-machine.h.  That way
> quad.h can use _FP_STRUCT_LAYOUT and you avoid any conditionals on
> __MINGW32__ in any of the core soft-fp code.

Ok, I adjusted patch according to your suggestion.  The need for
marking bitfield struct/union definitions by a struct-layout-attribute
for mingw targets is that for those targets the default is ms_struct
layout.  This is in some points about bitfields different.

For gcc_struct variant bitfields with different types get merged
together, but for ms_struct  bitfields are getting merged together
only, if they have same type.  As in those structures - I modified in
this patch - we have varying types for bitfields, this struct-layout
attribute is required.

> I would have expected any struct layout issue to apply to the other
> headers (single.h, double.h, extended.h) just as to quad.h, so if you're
> only changing one header you'll need to explain why the issue doesn't
> affect the others.

Yes, I noticed the issue only for quad.h, and other routines seems not
to be used on IA mingw hosts.  Nevertheless I revised my patch to mark
also bitfield-structures in extended.h
by _FP_STRUCT_LAYOUT macro.

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


ChangeLog

2012-02-28  Kai Tietz  

* config/i386/sfp-machine.h (_FP_STRUCT_LAYOUT): Define it
for mingw-targets as attribute gcc_struct.
* soft-fp/soft-fp.h (_FP_STRUCT_LAYOUT): If not defined,
define it as empty macro.
* soft-fp/quad.h: Mark bitfield-structures by _FP_STRUCT_LAYOUT.
* soft-fp/extended.h: Mark bitfield-structures by _FP_STRUCT_LAYOUT.

Patch tested for i686-w64-mingw32, x86_64-w64-mingw32, and for
x86_64-unknown-linux-gnu (with full regression-testing for all
languages including Ada and Obj-c++).

Ok for apply?

Regards,
Kai

Index: config/i386/sfp-machine.h
===
--- config/i386/sfp-machine.h   (revision 184486)
+++ config/i386/sfp-machine.h   (working copy)
@@ -1,3 +1,8 @@
+#ifdef __MINGW32__
+  /* Make sure we are using gnu-style bitfield handling.  */
+#define _FP_STRUCT_LAYOUT  __attribute__ ((gcc_struct))
+#endif
+
 #ifdef __x86_64__
 #include "config/i386/64/sfp-machine.h"
 #else
Index: soft-fp/extended.h
===
--- soft-fp/extended.h  (revision 184486)
+++ soft-fp/extended.h  (working copy)
@@ -64,7 +64,7 @@
 union _FP_UNION_E
 {
XFtype flt;
-   struct
+   struct _FP_STRUCT_LAYOUT
{
 #if __BYTE_ORDER == __BIG_ENDIAN
   unsigned long pad1 : _FP_W_TYPE_SIZE;
@@ -263,7 +263,7 @@
 union _FP_UNION_E
 {
   XFtype flt;
-  struct {
+  struct _FP_STRUCT_LAYOUT {
 #if __BYTE_ORDER == __BIG_ENDIAN
 _FP_W_TYPE pad  : (_FP_W_TYPE_SIZE - 1 - _FP_EXPBITS_E);
 unsigned sign   : 1;
Index: soft-fp/quad.h
===
--- soft-fp/quad.h  (revision 184486)
+++ soft-fp/quad.h  (working copy)
@@ -67,7 +67,7 @@
 union _FP_UNION_Q
 {
TFtype flt;
-   struct
+   struct _FP_STRUCT_LAYOUT
{
 #if __BYTE_ORDER == __BIG_ENDIAN
   unsigned sign : 1;
@@ -174,7 +174,8 @@
   struct {
 _FP_W_TYPE a, b;
   } longs;
-  struct {
+  struct _FP_STRUCT_LAYOUT
+  {
 #if __BYTE_ORDER == __BIG_ENDIAN
 unsigned sign: 1;
 unsigned exp : _FP_EXPBITS_Q;
Index: soft-fp/soft-fp.h
===
--- soft-fp/soft-fp.h   (revision 184486)
+++ soft-fp/soft-fp.h   (working copy)
@@ -210,4 +210,8 @@
 extern void abort (void);
 #endif

+#ifndef _FP_STRUCT_LAYOUT
+#define _FP_STRUCT_LAYOUT
 #endif
+
+#endif

Re: [PR51752] publication safety violations in loop invariant motion pass

[Aldy Hernandez]

Ok. I see.  So, I think what would be best is to have a way to check whether
a store/load is part of a transaction - do we have a way to do that right now?
(For example a flag on a gimple stmt?)  Then we can simply avoid the LIM


We do not (*).  My patch accumulates that information on demand.  I can 
certainly add a gimple bit for this, but can't the optimizations 
change/rewrite the stores/loads so we lose this information?



transform by making transaction load/store stmts behave the same as
potentially trapping stmts (thus, only optimize if the memory is accessed
unconditional somewhere else).  That would work for PRE as well.
[easiest would be to make *_could_trap_p return true for memory ops
inside a transaction]


Provided the gimple bit works, this seems reasonable, though quite a big 
hammer.  But given that we are nearing a release, I would be in favor of it.


Richard Henderson, what do you think?

Aldy

(*) Well technically we do, but much later in the tmmark pass, when we 
instrument the loads, but this is useless since all the tree optimizers 
have been run (loop IM, etc).

Re: [PR51752] publication safety violations in loop invariant motion pass

[Aldy Hernandez]

For that matter, didn't rth add a memory barrier at the beginning of
transactions last week?  That would mean that we can't hoist anything
outside of a transaction anyhow.  Or was it not a full memory barrier?


It's now a full memory barrier for all global memory and for local statics
if their address is taken (and for automatic vars with their address taken).
Do we need to be concerned about non-address-taken local statics?


It is my understanding that non-address-taken local statics are not 
visible to other threads, so we don't have to worry about these.


A

[PATCH] fix PR48299 by merging changes for thread_leak_test.c from upstream

[Jack Howarth]

   Currently the testsuite/boehm-gc.c/thread_leak_test.c executation test
will hang on several targets including x86_64-apple-darwin10/11 for -m32/-m64.
The attached patch eliminates this issue, PR48299, by merging in the
upstream changes for this testcase from...

https://raw.github.com/ivmai/bdwgc/master/tests/thread_leak_test.c

The only changes made to the upstram test case was retaining the use of...

GC_find_leak = 1;

rather than...

GC_set_find_leak(1);

and formatting style changes. Tested on x86_64-apple-darwin10 and
x86_64-apple-darwin11. Okay for gcc trunk for gcc 4.7 (as the
timeouts in the testsuite are very annoying)?
 Jack
ps I was uncertain how much detail we need in the changelog as the
upstream commit logs aren't very informative...

https://github.com/ivmai/bdwgc/commits/master/tests/thread_leak_test.c

2012-02-27  Jack Howarth  
Patrick Marlier  

PR boehm-gc/48299
testsuite/boehm-gc.c/thread_leak_test.c: Merge upstream changes.

boehm-gc/

Index: testsuite/boehm-gc.c/thread_leak_test.c
===
--- testsuite/boehm-gc.c/thread_leak_test.c (revision 184602)
+++ testsuite/boehm-gc.c/thread_leak_test.c (working copy)
@@ -1,13 +1,22 @@
-#define GC_LINUX_THREADS
+#ifndef GC_THREADS
+# define GC_THREADS
+#endif
 #include "leak_detector.h"
-#include 
+#ifdef GC_PTHREADS
+# include 
+#else
+# include 
+#endif
 #include 
 
-void * test(void * arg) {
+#ifdef GC_PTHREADS
+  void * test(void * arg)
+#else
+  DWORD WINAPI test(LPVOID arg)
+#endif
+{
 int *p[10];
 int i;
-GC_find_leak = 1; /* for new collect versions not compiled  */
-/* with -DFIND_LEAK.*/
 for (i = 0; i < 10; ++i) {
 p[i] = malloc(sizeof(int)+i);
 }
@@ -15,23 +24,47 @@
 for (i = 1; i < 10; ++i) {
 free(p[i]);
 }
-}   
+#ifdef GC_PTHREADS
+return arg;
+#else
+return (DWORD)(GC_word)arg;
+#endif
+}
 
 #define NTHREADS 5
 
-int main() {
+int main(void) {
 int i;
+#ifdef GC_PTHREADS
 pthread_t t[NTHREADS];
+#else
+HANDLE t[NTHREADS];
+DWORD thread_id;
+#endif
 int code;
 
+GC_find_leak = 1;/* for new collect versions not compiled   */
+GC_INIT();
 for (i = 0; i < NTHREADS; ++i) {
-   if ((code = pthread_create(t + i, 0, test, 0)) != 0) {
-   printf("Thread creation failed %d\n", code);
+#ifdef GC_PTHREADS
+   code = pthread_create(t + i, 0, test, 0);
+#else
+   t[i] = CreateThread(NULL, 0, test, 0, 0, &thread_id);
+   code = t[i] != NULL ? 0 : (int)GetLastError();
+#endif
+   if (code != 0) {
+  printf("Thread creation failed %d\n", code);
 }
 }
 for (i = 0; i < NTHREADS; ++i) {
-   if ((code = pthread_join(t[i], 0)) != 0) {
-printf("Thread join failed %lu\n", code);
+#ifdef GC_PTHREADS
+   code = pthread_join(t[i], 0);
+#else
+   code = WaitForSingleObject(t[i], INFINITE) == WAIT_OBJECT_0 ? 0 :
+(int)GetLastError();
+#endif
+   if (code != 0) {
+  printf("Thread join failed %d\n", code);
 }
 }
 CHECK_LEAKS();

Re: [PR51752] publication safety violations in loop invariant motion pass

[Andrew MacLeod]

On 02/27/2012 11:22 AM, Aldy Hernandez wrote:


Ok. I see.  So, I think what would be best is to have a way to check 
whether
a store/load is part of a transaction - do we have a way to do that 
right now?

(For example a flag on a gimple stmt?)  Then we can simply avoid the LIM


We do not (*).  My patch accumulates that information on demand.  I 
can certainly add a gimple bit for this, but can't the optimizations 
change/rewrite the stores/loads so we lose this information?


I t would seem appropriate to me that in the future, perhaps the CFG 
could have a flag set for any basic block which is in a transaction...  
This would make it pretty trivial at all times to tell if a statement is 
part of a transaction or not.  It seems like the process of CFG 
construction/updating should be able to maintain that info for little 
cost. (ie, I'd guess it's already making the traversals requires to 
collect that info)


It would certainly be convenient :-)

Andrew

Re: [patch libgcc]: Fix float128 soft-float for mingw targets

[Joseph S. Myers]

On Mon, 27 Feb 2012, Kai Tietz wrote:

> For gcc_struct variant bitfields with different types get merged
> together, but for ms_struct  bitfields are getting merged together
> only, if they have same type.  As in those structures - I modified in
> this patch - we have varying types for bitfields, this struct-layout
> attribute is required.

I think you need a comment in soft-fp.h explaining the issue (and in 
particular that it is about structures with consecutive (?) bit-fields 
with different declared types).  Though I presume the attribute is 
harmless on other structures - so it might make sense to put it in 
single.h and double.h as well to make it clear that those structures too 
are expected to follow the same layout rules as those in extended.h and 
quad.h.

> 2012-02-28  Kai Tietz  
> 
>   * config/i386/sfp-machine.h (_FP_STRUCT_LAYOUT): Define it
>   for mingw-targets as attribute gcc_struct.
>   * soft-fp/soft-fp.h (_FP_STRUCT_LAYOUT): If not defined,
>   define it as empty macro.
>   * soft-fp/quad.h: Mark bitfield-structures by _FP_STRUCT_LAYOUT.
>   * soft-fp/extended.h: Mark bitfield-structures by _FP_STRUCT_LAYOUT.

Please send patches to libc-alpha that apply cleanly to current git glibc.  
That means only patching files present in glibc (not GCC's sfp-machine.h) 
and having ChangeLog entries only for the files in glibc.

> Index: soft-fp/soft-fp.h
> ===
> --- soft-fp/soft-fp.h (revision 184486)
> +++ soft-fp/soft-fp.h (working copy)
> @@ -210,4 +210,8 @@
>  extern void abort (void);
>  #endif
> 
> +#ifndef _FP_STRUCT_LAYOUT
> +#define _FP_STRUCT_LAYOUT
>  #endif

I think this belongs at the bottom of the sequence of #ifndef default 
definitions of various macros, not at the bottom of the whole file, and is 
where the comment should go explaining why there is such a macro.

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

Re: [PR51752] publication safety violations in loop invariant motion pass

[Michael Matz]

Hi,

On Mon, 27 Feb 2012, Aldy Hernandez wrote:

> 
> > > For that matter, didn't rth add a memory barrier at the beginning of
> > > transactions last week?  That would mean that we can't hoist anything
> > > outside of a transaction anyhow.  Or was it not a full memory barrier?
> >
> > It's now a full memory barrier for all global memory and for local statics
> > if their address is taken (and for automatic vars with their address taken).
> > Do we need to be concerned about non-address-taken local statics?
> 
> It is my understanding that non-address-taken local statics are not 
> visible to other threads,

void f () { static int i; i++; }

Running 'f' in different threads will expose the storage to 'i' to each of 
them without taking its address :-/


Ciao,
Michael.

Re: [patch libgcc]: Fix float128 soft-float for mingw targets

[Kai Tietz]

2012/2/27 Joseph S. Myers :
> On Mon, 27 Feb 2012, Kai Tietz wrote:
>
>> For gcc_struct variant bitfields with different types get merged
>> together, but for ms_struct  bitfields are getting merged together
>> only, if they have same type.  As in those structures - I modified in
>> this patch - we have varying types for bitfields, this struct-layout
>> attribute is required.
>
> I think you need a comment in soft-fp.h explaining the issue (and in
> particular that it is about structures with consecutive (?) bit-fields
> with different declared types).  Though I presume the attribute is
> harmless on other structures - so it might make sense to put it in
> single.h and double.h as well to make it clear that those structures too
> are expected to follow the same layout rules as those in extended.h and
> quad.h.

Ok. Done. Here is the patch for glibc only

ChangeLog glibc

2012-02-28  Kai Tietz  

* soft-fp/soft-fp.h (_FP_STRUCT_LAYOUT): If not defined,
define it as empty macro.
* soft-fp/quad.h: Mark bitfield-structures by _FP_STRUCT_LAYOUT.
* soft-fp/extended.h: Likewise.
* soft-fp/single.h: Likewise.
* soft-fp/double.h: Likewise.

Ok for apply?

Regards,
Kai

Index: soft-fp/extended.h
===
--- soft-fp/extended.h  (revision 184486)
+++ soft-fp/extended.h  (working copy)
@@ -64,7 +64,7 @@
 union _FP_UNION_E
 {
XFtype flt;
-   struct
+   struct _FP_STRUCT_LAYOUT
{
 #if __BYTE_ORDER == __BIG_ENDIAN
   unsigned long pad1 : _FP_W_TYPE_SIZE;
@@ -263,7 +263,7 @@
 union _FP_UNION_E
 {
   XFtype flt;
-  struct {
+  struct _FP_STRUCT_LAYOUT {
 #if __BYTE_ORDER == __BIG_ENDIAN
 _FP_W_TYPE pad  : (_FP_W_TYPE_SIZE - 1 - _FP_EXPBITS_E);
 unsigned sign   : 1;
Index: soft-fp/single.h
===
--- soft-fp/single.h(revision 184486)
+++ soft-fp/single.h(working copy)
@@ -58,7 +58,7 @@
 union _FP_UNION_S
 {
   SFtype flt;
-  struct {
+  struct _FP_STRUCT_LAYOUT {
 #if __BYTE_ORDER == __BIG_ENDIAN
 unsigned sign : 1;
 unsigned exp  : _FP_EXPBITS_S;
Index: soft-fp/double.h
===
--- soft-fp/double.h(revision 184486)
+++ soft-fp/double.h(working copy)
@@ -68,7 +68,7 @@
 union _FP_UNION_D
 {
   DFtype flt;
-  struct {
+  struct _FP_STRUCT_LAYOUT {
 #if __BYTE_ORDER == __BIG_ENDIAN
 unsigned sign  : 1;
 unsigned exp   : _FP_EXPBITS_D;
@@ -167,7 +167,7 @@
 union _FP_UNION_D
 {
   DFtype flt;
-  struct {
+  struct _FP_STRUCT_LAYOUT {
 #if __BYTE_ORDER == __BIG_ENDIAN
 unsigned sign   : 1;
 unsigned exp: _FP_EXPBITS_D;
Index: soft-fp/quad.h
===
--- soft-fp/quad.h  (revision 184486)
+++ soft-fp/quad.h  (working copy)
@@ -67,7 +67,7 @@
 union _FP_UNION_Q
 {
TFtype flt;
-   struct
+   struct _FP_STRUCT_LAYOUT
{
 #if __BYTE_ORDER == __BIG_ENDIAN
   unsigned sign : 1;
@@ -171,10 +171,11 @@
 union _FP_UNION_Q
 {
   TFtype flt /* __attribute__((mode(TF))) */ ;
-  struct {
+  struct _FP_STRUCT_LAYOUT {
 _FP_W_TYPE a, b;
   } longs;
-  struct {
+  struct _FP_STRUCT_LAYOUT
+  {
 #if __BYTE_ORDER == __BIG_ENDIAN
 unsigned sign: 1;
 unsigned exp : _FP_EXPBITS_Q;
Index: soft-fp/soft-fp.h
===
--- soft-fp/soft-fp.h   (revision 184486)
+++ soft-fp/soft-fp.h   (working copy)
@@ -85,6 +85,14 @@
 #define FP_EX_DENORM   0
 #endif

+/* For native windows targets struct-layout follows the ms-bitfields
+   layout.  For unix-targets instead the gcc-struct-layout is used.
+   The difference between ms/gcc struct-layout is in consecutive bit-fields
+   with different declared types, which are getting packed different.  */
+#ifndef _FP_STRUCT_LAYOUT
+#define _FP_STRUCT_LAYOUT
+#endif
+
 #ifdef _FP_DECL_EX
 #define FP_DECL_EX \
   int _fex = 0;\

Re: [patch libgcc]: Fix float128 soft-float for mingw targets

[Kai Tietz]

So here is the libgcc patch only.

ChangeLog gcc's libgcc

2012-02-28  Kai Tietz  

* config/i386/sfp-machine.h (_FP_STRUCT_LAYOUT): Define it
for mingw-targets as attribute gcc_struct.

Ok for apply?

Regards,
Kai

Index: config/i386/sfp-machine.h
===
--- config/i386/sfp-machine.h   (revision 184486)
+++ config/i386/sfp-machine.h   (working copy)
@@ -1,3 +1,8 @@
+#ifdef __MINGW32__
+  /* Make sure we are using gnu-style bitfield handling.  */
+#define _FP_STRUCT_LAYOUT  __attribute__ ((gcc_struct))
+#endif
+
 #ifdef __x86_64__
 #include "config/i386/64/sfp-machine.h"
 #else

[Ada] Fix wrong code for null pointer constant

[Eric Botcazou]

This is a regression present on the mainline.  The compiler generates very 
large data if a variable whose type is an access to an unconstrained array is 
initialized with a constant object declaration whose expression is null.  The 
assembler may issue a warning on the construct.

Tested on i586-suse-linux, applied on the mainline.


2012-02-27  Tristan Gingold  

* gcc-interface/decl.c (gnat_to_gnu_entity) [E_String_Type,
E_Array_Type]: Reuse dummy fat type for gnu_ptr_template and
gnu_template_type.


2012-02-27  Tristan Gingold  

* gnat.dg/array20.ad[sb]: New test.


-- 
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 184594)
+++ gcc-interface/decl.c	(working copy)
@@ -2003,8 +2003,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	const bool convention_fortran_p
 	  = (Convention (gnat_entity) == Convention_Fortran);
 	const int ndim = Number_Dimensions (gnat_entity);
-	tree gnu_template_type = make_node (RECORD_TYPE);
-	tree gnu_ptr_template = build_pointer_type (gnu_template_type);
+	tree gnu_template_type;
+	tree gnu_ptr_template;
 	tree gnu_template_reference, gnu_template_fields, gnu_fat_type;
 	tree *gnu_index_types = XALLOCAVEC (tree, ndim);
 	tree *gnu_temp_fields = XALLOCAVEC (tree, ndim);
@@ -2035,9 +2035,16 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	TYPE_NAME (gnu_fat_type) = NULL_TREE;
 	/* Save the contents of the dummy type for update_pointer_to.  */
 	TYPE_POINTER_TO (gnu_type) = copy_type (gnu_fat_type);
+	gnu_ptr_template =
+	  TREE_TYPE (TREE_CHAIN (TYPE_FIELDS (gnu_fat_type)));
+	gnu_template_type = TREE_TYPE (gnu_ptr_template);
 	  }
 	else
-	  gnu_fat_type = make_node (RECORD_TYPE);
+	  {
+	gnu_fat_type = make_node (RECORD_TYPE);
+	gnu_template_type = make_node (RECORD_TYPE);
+	gnu_ptr_template = build_pointer_type (gnu_template_type);
+	  }
 
 	/* Make a node for the array.  If we are not defining the array
 	   suppress expanding incomplete types.  */
-- { dg-do assemble }

package body Array20 is

   type Arr is array (Positive range <>) of Integer;

   type P_Arr is access Arr;

   N : constant P_Arr := null;

   Table : P_Arr := N;

end Array20;
package Array20 is

   pragma Elaborate_Body;

end array20;

Re: [PR51752] publication safety violations in loop invariant motion pass

[Aldy Hernandez]

On 02/27/12 11:02, Michael Matz wrote:

Hi,

On Mon, 27 Feb 2012, Aldy Hernandez wrote:




For that matter, didn't rth add a memory barrier at the beginning of
transactions last week?  That would mean that we can't hoist anything
outside of a transaction anyhow.  Or was it not a full memory barrier?


It's now a full memory barrier for all global memory and for local statics
if their address is taken (and for automatic vars with their address taken).
Do we need to be concerned about non-address-taken local statics?


It is my understanding that non-address-taken local statics are not
visible to other threads,


void f () { static int i; i++; }

Running 'f' in different threads will expose the storage to 'i' to each of
them without taking its address :-/


In that case, shouldn't we make transactions barriers for local statics 
as well, regardless of if their address was taken or not?

Tweak generation of DW_AT_GNAT_descriptive_type

[Eric Botcazou]

The 4.7 compiler introduces the DW_AT_GNAT_descriptive_type attribute for Ada:
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01194.html
We just realized that the way it is current generated may lead to incomplete 
debug info because it is generated before the children of the DIE, for example 
the fields in a structure.  Now, under certain circumstances, this breaks the 
handling of recursive types.

I added a kludge some time ago to mitigate this:
  http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02320.html
but it proved to be short-sighted.

The attached patch makes it so that the attribute is generated only after the 
complete DIE is.  There are 2 chunks, one for the Ada FE and one for the DWARF 
back-end, but this only affects the Ada compiler.  And it moves the generation 
of the DW_AT_artificial attribute for types as well (also used only by the Ada 
compiler) for the sake of consistency.

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


2012-02-27  Eric Botcazou  

* dwarf2out.c (modified_type_die): Set DW_AT_GNAT_descriptive_type and
DW_AT_artificial attributes at the end of the processing.
(gen_array_type_die): Likewise.
(gen_enumeration_type_die): Likewise.
(gen_struct_or_union_type_die): Likewise.
(add_gnat_descriptive_type_attribute): Do not suppress debug info for
the parent type.


2012-02-27  Eric Botcazou  

* gcc-interface/decl.c (components_to_record): Add ARTIFICIAL parameter
and set TYPE_ARTIFICIAL according to it.  Adjust recursive call.
(gnat_to_gnu_entity) : Adjust call to above function.
* gcc-interface/utils.c (rest_of_record_type_compilation): Do not
invoke rest_of_type_decl_compilation on the parallel type, if any.


-- 
Eric Botcazou
Index: dwarf2out.c
===
--- dwarf2out.c	(revision 184585)
+++ dwarf2out.c	(working copy)
@@ -9929,9 +9929,6 @@ modified_type_die (tree type, int is_con
 	   useful source coordinates anyway.  */
 	name = DECL_NAME (name);
   add_name_attribute (mod_type_die, IDENTIFIER_POINTER (name));
-  add_gnat_descriptive_type_attribute (mod_type_die, type, context_die);
-  if (TYPE_ARTIFICIAL (type))
-	add_AT_flag (mod_type_die, DW_AT_artificial, 1);
 }
   /* This probably indicates a bug.  */
   else if (mod_type_die && mod_type_die->die_tag == DW_TAG_base_type)
@@ -9960,6 +9957,10 @@ modified_type_die (tree type, int is_con
   if (sub_die != NULL)
 add_AT_die_ref (mod_type_die, DW_AT_type, sub_die);
 
+  add_gnat_descriptive_type_attribute (mod_type_die, type, context_die);
+  if (TYPE_ARTIFICIAL (type))
+add_AT_flag (mod_type_die, DW_AT_artificial, 1);
+
   return mod_type_die;
 }
 
@@ -15493,11 +15494,7 @@ add_gnat_descriptive_type_attribute (dw_
   dtype_die = lookup_type_die (dtype);
   if (!dtype_die)
 {
-  /* The descriptive type indirectly references TYPE if this is also the
-	 case for TYPE itself.  Do not deal with the circularity here.  */
-  TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type)) = 1;
   gen_type_die (dtype, context_die);
-  TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type)) = 0;
   dtype_die = lookup_type_die (dtype);
   gcc_assert (dtype_die);
 }
@@ -16384,9 +16381,6 @@ gen_array_type_die (tree type, dw_die_re
 
   array_die = new_die (DW_TAG_array_type, scope_die, type);
   add_name_attribute (array_die, type_tag (type));
-  add_gnat_descriptive_type_attribute (array_die, type, context_die);
-  if (TYPE_ARTIFICIAL (type))
-add_AT_flag (array_die, DW_AT_artificial, 1);
   equate_type_number_to_die (type, array_die);
 
   if (TREE_CODE (type) == VECTOR_TYPE)
@@ -16446,6 +16440,10 @@ gen_array_type_die (tree type, dw_die_re
 
   add_type_attribute (array_die, element_type, 0, 0, context_die);
 
+  add_gnat_descriptive_type_attribute (array_die, type, context_die);
+  if (TYPE_ARTIFICIAL (type))
+add_AT_flag (array_die, DW_AT_artificial, 1);
+
   if (get_AT (array_die, DW_AT_name))
 add_pubtype (type, array_die);
 }
@@ -16689,9 +16687,6 @@ gen_enumeration_type_die (tree type, dw_
 			  scope_die_for (type, context_die), type);
   equate_type_number_to_die (type, type_die);
   add_name_attribute (type_die, type_tag (type));
-  add_gnat_descriptive_type_attribute (type_die, type, context_die);
-  if (TYPE_ARTIFICIAL (type))
-	add_AT_flag (type_die, DW_AT_artificial, 1);
   if (dwarf_version >= 4 || !dwarf_strict)
 	{
 	  if (ENUM_IS_SCOPED (type))
@@ -16747,6 +16742,10 @@ gen_enumeration_type_die (tree type, dw_
 	add_AT_int (enum_die, DW_AT_const_value,
 			tree_low_cst (value, tree_int_cst_sgn (value) > 0));
 	}
+
+  add_gnat_descriptive_type_attribute (type_die, type, context_die);
+  if (TYPE_ARTIFICIAL (type))
+	add_AT_flag (type_die, DW_AT_artificial, 1);
 }
   else
 add_AT_flag (type_die, DW_AT_declaration, 1);
@@ -18659,12 +18658,7 @@ gen_struct_or_union_type_die (tre

Re: [patch testsuite]: Fix various testsuite failures in gcc.target/i386

[Mike Stump]

On Feb 26, 2012, at 11:21 PM, Kai Tietz wrote:
> this patch fixes various testsuite failures in gcc.target/i386 for
> mingw targets.

> Ok for apply?

Ok.  [ any extra eyes that can spot any small detail I miss are always welcome ]

Re: [PATCH] fix PR48299 by merging changes for thread_leak_test.c from upstream

[Mike Stump]

On Feb 27, 2012, at 8:41 AM, Jack Howarth wrote:
> Currently the testsuite/boehm-gc.c/thread_leak_test.c executation test
> will hang on several targets including x86_64-apple-darwin10/11 for -m32/-m64.
> The attached patch eliminates this issue, PR48299, by merging in the
> upstream changes for this testcase from...

> Index: testsuite/boehm-gc.c/thread_leak_test.c

So, ideally, I'd like to have Bryce or Tom review this change or at least the 
methodology, if they are still working in this area.

Re: [PATCH, i386, Android] Enable exceptions and RTTI by default for Android

[Jing Yu]

On Mon, Feb 27, 2012 at 12:28 AM, Ilya Enkovich  wrote:
>> My comment is(was) not on the format of the patch. Instead, I am
>> thinking whether Android toolchain customer, which is Android AOSP,
>> wants this patch.
>>
>> I don't know the scenario behind this patch. I think the question
>> behind this patch is, if RTTI and exceptions are enabled by default,
>> who is supposed to handle RTTI and exceptions by default? The answer
>> is no answer, for now.
>>
>> Android AOSP tree provides very limited C++ support. Android NDK
>> provides four options for C++ support. Some of the options support
>> both exceptions and rttit, some options only support rtti.
>>
>> Therefore I guess Android AOSP probably would not like to enable
>> exceptions and RTTI by default.
>
> Actually when you rebuild Android NDK similar patch (named
> 0001-Enable-C-exceptions-and-RTTI-by-default.patch) is applied to GCC
> sources before toolchain rebuild.

Right. The patch is used to build NDK toolchain which is to build NDK
applications, and NDK offers several options for RTTI and exception
support. But Android AOSP platform does not support exception, and the
toolchain to build Android AOSP platform does not use this patch.
That's why the patch exists in NDK package, not in AOSP toolchain
source repository.

Thanks,
Jing

>
> Ilya
>
>>
>> Questions/complaints/requests on Android limited C++ support, should
>> go to Android forum.
>> Questions about license concerns, should go to Android AOSP lawyer.
>>
>> Thanks,
>> Jing
>>
>> On Fri, Feb 24, 2012 at 2:36 AM, Richard Guenther
>>  wrote:
>>> On Fri, Feb 24, 2012 at 11:22 AM, Ilya Enkovich  
>>> wrote:
> On Wed, Feb 22, 2012 at 3:57 PM, Ilya Enkovich  
> wrote:
>> Hello,
>>
>> Here is a simple patch which enables exceptions and RTTI by default
>> for Android target. OK for trunk?
>
> Err - isn't that the default?  Thus, simply delete the bogus spec?
>
> Richard.
>
>
 Hi,

 Is following patch OK or it's better to remove whole macro and its usages?
>>>
>>> The latter.
>>>
>>> Richard.
>>>
 Thanks,
 Ilya
 --
 2012-02-22  Enkovich Ilya  

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


 diff --git a/gcc/config/linux-android.h b/gcc/config/linux-android.h
 index 94c5274..180b62b 100644
 --- a/gcc/config/linux-android.h
 +++ b/gcc/config/linux-android.h
 @@ -45,9 +45,7 @@
   "%{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}} "                      \
   "%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC"

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

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

[PATCH 2/2] document gcc --help=common

[Bernhard Reutner-Fischer]

From: Bernhard Reutner-Fischer 

gcc/ChangeLog:
2010-01-03  Bernhard Reutner-Fischer  

* gcc.c (display_help): Document --help=common and sort entries
alphabetically.

Signed-off-by: Bernhard Reutner-Fischer 
---
 gcc/gcc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 2fc3b21..1c408a4 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -2976,7 +2976,7 @@ display_help (void)
   fputs (_("  -pass-exit-codes Exit with highest error code from a 
phase\n"), stdout);
   fputs (_("  --help   Display this information\n"), stdout);
   fputs (_("  --target-helpDisplay target specific command line 
options\n"), stdout);
-  fputs (_("  
--help={target|optimizers|warnings|params|[^]{joined|separate|undocumented}}[,...]\n"),
 stdout);
+  fputs (_("  
--help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...]\n"),
 stdout);
   fputs (_("   Display specific types of command line 
options\n"), stdout);
   if (! verbose_flag)
 fputs (_("  (Use '-v --help' to display command line options of 
sub-processes)\n"), stdout);
-- 
1.7.9

[PATCH 0/2] documentation tweaks

[Bernhard Reutner-Fischer]

From: Bernhard Reutner-Fischer 

Ok for trunk?

Bernhard Reutner-Fischer (2):
  install.texi: document language-specific check- shortcuts
  document gcc --help=common

 gcc/doc/install.texi |5 -
 gcc/gcc.c|2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

-- 
1.7.9

[PATCH 1/2] install.texi: document language-specific check- shortcuts

[Bernhard Reutner-Fischer]

From: Bernhard Reutner-Fischer 

gcc/ChangeLog:

2009-07-29  Bernhard Reutner-Fischer  

* gcc/doc/install.texi: Document check-$LANG specific shortcuts

Signed-off-by: Bernhard Reutner-Fischer 
---
 gcc/doc/install.texi |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 8a83d9b..334ba1f 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2530,7 +2530,10 @@ on a simulator as described at 
@uref{http://gcc.gnu.org/simtest-howto.html}.
 @section How can you run the testsuite on selected tests?
 
 In order to run sets of tests selectively, there are targets
-@samp{make check-gcc} and @samp{make check-g++}
+@samp{make check-gcc} and language specific @samp{make check-c},
+@samp{make check-c++}, @samp{make check-fortran}, @samp{make check-java},
+@samp{make check-ada}, @samp{make check-objc}, @samp{make check-obj-c++},
+@samp{make check-lto}
 in the @file{gcc} subdirectory of the object directory.  You can also
 just run @samp{make check} in a subdirectory of the object directory.
 
-- 
1.7.9

Re: [PATCH 1/2] install.texi: document language-specific check- shortcuts

[Mike Stump]

On Feb 27, 2012, at 10:22 AM, Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer 
> 
> gcc/ChangeLog:
> 
> 2009-07-29  Bernhard Reutner-Fischer  
> 
>   * gcc/doc/install.texi: Document check-$LANG specific shortcuts

Ok, thanks.

libgcc patch committed: Add test for __linux__

[Ian Lance Taylor]

PR 52390 complains that the libgcc morestack support tests for __glibc__
for code that can only happen on GNU/Linux systems.  This patch adds a
test for __linux__ as well.  This will presumably improve matters when
using glibc on a non-Linux system.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2012-02-27  Samuel Thibault  

PR target/52390
* generic-morestack.c (__generic_morestack_set_initial_sp): Test
for __linux__ when removing signals from __morestack_fullmask.


Index: generic-morestack.c
===
--- generic-morestack.c	(revision 184605)
+++ generic-morestack.c	(working copy)
@@ -507,7 +507,7 @@ __generic_morestack_set_initial_sp (void
   sigemptyset (&__morestack_initial_sp.mask);
 
   sigfillset (&__morestack_fullmask);
-#ifdef __GLIBC__
+#if defined(__GLIBC__) && defined(__linux__)
   /* In glibc, the first two real time signals are used by the NPTL
  threading library.  By taking them out of the set of signals, we
  avoiding copying the signal mask in pthread_sigmask.  More

Re: [libitm] Add SPARC bits

[David Miller]

From: Eric Botcazou 
Date: Mon, 27 Feb 2012 10:42:17 +0100

>> We probably want to do some nop'ish thing here which will yield the
>> cpu thread on Niagara cpus, I'd recommend something along the lines of
>> "rd %ccr, %g0" or "rd %y, %g0"
> 
> libgomp has its own idea about cpu_relax:
> 
> static inline void
> cpu_relax (void)
> {
> #if defined __arch64__ || defined  __sparc_v9__
>   __asm volatile ("membar #LoadLoad" : : : "memory");
> #else
>   __asm volatile ("" : : : "memory");
> #endif
> }
> 
> Maybe we can come up with a single implementation for libgomp and libitm?

I think that's a great idea.

We need a reliable way to test for v9/v8plus/whatever properly because
nobody is testing current gcc with real 32-bit pre-v9 sparc hardware and
not providing atomics and proper cpu_relax implementations is just silly.

Re: [Patch, fortran] PR50981 absent polymorphic scalar actual arguments

[Mikael Morin]

Hello, 

On Monday 13 February 2012 23:38:57 Paul Richard Thomas wrote:
> Mikael,
> 
> This is OK for trunk with one proviso; could you move
> is_class_container_ref to gfc_is_class_container_ref in class.c?
> 
> Thanks for the patch
> 
I have a small hardware issue (overheating) preventing me from bootstrapping 
and committing. I hoped to fix the problem within the next three days or so, 
but as the release candidate seems to come in that time frame, would someone 
mind doing it for me? Or should we delay to 4.8 now?

Thanks.

Mikael

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

[Mikael Morin]

On Tuesday 21 February 2012 16:55:09 Tobias Burnus wrote:
> Build and regtested on x86-64-linux.
> OK for the 4.8 trunk?
> 
OK.

Mikael

PS: I think that, in general, we should _accept_ statements on MATCH_ERROR to 
avoid issues of this kind.

Re: [Patch, Fortran] PR 52270 - OOP - pointer check in vardef context, passing to intent-in ptr

[Mikael Morin]

On Saturday 18 February 2012 14:33:09 Tobias Burnus wrote:
> The patch consists of two parts:
> 
> * The pointer check in gfc_check_vardef_context didn't honour
> polymorphic variables
> 
> * Passing a TYPE to a CLASS is not allowed if CLASS is a pointer or
> allocatable as the actual argument cannot change its effective type.
> However, if the dummy is an intent(in)-pointer, there is no risk of
> doing so. Thus, one can allow this.
> 
> The latter is an interpretation request (F08/0073), which passed the J3
> meeting. It is in line of the Fortran 2008 feature, where one can pass a
> TARGET variable (i.e. nonpointer) to an intent-in pointer dummy argument.
> 
> Build and regtested on x86-64-linux
> OK for the (4.8) trunk?
> 
OK. Thanks.

Mikael

PR middle-end/52373: two pc_rtxs, etc.

[Richard Sandiford]

This patch fixed PR 52373, which is a segfault or rtl checking failure
(depending on how lucky you are) on mips-sgi-irix6.5.  I can't reproduce
it on *-elf or *-linux-gnu, probably because we use .cfi_* there.

The problem is that, although pc_rtx is expected to be unique, it is
recreated by each call to target_reinit, so we can end up with different
values through the runtime of the compiler.  This confused dwarf2cfi.c,
which sets up cie_return_save with a pc_rtx reference when first called,
and reuses it for all later functions (by which time we might have
created a new pc_rtx).  Pointer equality can then fail.

The first four global_rtxs aren't target-dependent, so I think
we should treat them in the same way as constants.  It'll also
make debugging slightly easier.

The problem is a bit deeper than that really.  Having only one CIE
isn't fully general, since things like the frame pointer are allowed
to change between subtargets (and do on MIPS).  But it happens that
the CIE we create for MIPS works for both modes, so I think this
patch is good enough in practice.

Tested on mips-sde-elf with rtl checking enabled.  There were no
differences.  Also tested with a mips-sgi-irix6.5 cc1 cross to verify
that it fixes the bug.  OK to install?

Richard


gcc/
* rtl.h (pc_rtx, ret_rtx, simple_return_rtx, cc0_rtx): Redefine as
variables.
(GR_PC, GR_CC0, GR_RETURN, GR_SIMPLE_RETURN): Delete.
* emit-rtl.c (pc_rtx, ret_rtx, simple_return_rtx, cc0_rtx): New
variables.
(init_emit_regs): Move associated initialization to...
(init_emit_once): ...here.

Index: gcc/rtl.h
===
--- gcc/rtl.h   2012-02-26 10:30:27.817985876 +
+++ gcc/rtl.h   2012-02-26 11:21:47.372978342 +
@@ -2089,6 +2089,11 @@ #define CONST1_RTX(MODE) (const_tiny_rtx
 #define CONST2_RTX(MODE) (const_tiny_rtx[2][(int) (MODE)])
 #define CONSTM1_RTX(MODE) (const_tiny_rtx[3][(int) (MODE)])
 
+extern rtx pc_rtx;
+extern rtx cc0_rtx;
+extern rtx ret_rtx;
+extern rtx simple_return_rtx;
+
 /* If HARD_FRAME_POINTER_REGNUM is defined, then a special dummy reg
is used to represent the frame pointer.  This is because the
hard frame pointer and the automatic variables are separated by an amount
@@ -2112,10 +2117,6 @@ #define HARD_FRAME_POINTER_IS_ARG_POINTE
 /* Index labels for global_rtl.  */
 enum global_rtl_index
 {
-  GR_PC,
-  GR_CC0,
-  GR_RETURN,
-  GR_SIMPLE_RETURN,
   GR_STACK_POINTER,
   GR_FRAME_POINTER,
 /* For register elimination to work properly these hard_frame_pointer_rtx,
@@ -2208,12 +2209,6 @@ #define top_of_stack \
 #define mode_mem_attrs \
   (this_target_rtl->x_mode_mem_attrs)
 
-/* Standard pieces of rtx, to be substituted directly into things.  */
-#define pc_rtx  (global_rtl[GR_PC])
-#define ret_rtx (global_rtl[GR_RETURN])
-#define simple_return_rtx   (global_rtl[GR_SIMPLE_RETURN])
-#define cc0_rtx (global_rtl[GR_CC0])
-
 /* All references to certain hard regs, except those created
by allocating pseudo regs into them (when that's possible),
go through these unique rtx objects.  */
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c  2012-02-26 10:30:27.817985876 +
+++ gcc/emit-rtl.c  2012-02-26 11:21:47.369978342 +
@@ -117,6 +117,12 @@ rtx const_tiny_rtx[4][(int) MAX_MACHINE_
 
 rtx const_int_rtx[MAX_SAVED_CONST_INT * 2 + 1];
 
+/* Standard pieces of rtx, to be substituted directly into things.  */
+rtx pc_rtx;
+rtx ret_rtx;
+rtx simple_return_rtx;
+rtx cc0_rtx;
+
 /* A hash table storing CONST_INTs whose absolute value is greater
than MAX_SAVED_CONST_INT.  */
 
@@ -5536,10 +5542,6 @@ init_emit_regs (void)
   init_reg_modes_target ();
 
   /* Assign register numbers to the globally defined register rtx.  */
-  pc_rtx = gen_rtx_fmt_ (PC, VOIDmode);
-  ret_rtx = gen_rtx_fmt_ (RETURN, VOIDmode);
-  simple_return_rtx = gen_rtx_fmt_ (SIMPLE_RETURN, VOIDmode);
-  cc0_rtx = gen_rtx_fmt_ (CC0, VOIDmode);
   stack_pointer_rtx = gen_raw_REG (Pmode, STACK_POINTER_REGNUM);
   frame_pointer_rtx = gen_raw_REG (Pmode, FRAME_POINTER_REGNUM);
   hard_frame_pointer_rtx = gen_raw_REG (Pmode, HARD_FRAME_POINTER_REGNUM);
@@ -5855,6 +5857,11 @@ init_emit_once (void)
   const_tiny_rtx[0][(int) BImode] = const0_rtx;
   if (STORE_FLAG_VALUE == 1)
 const_tiny_rtx[1][(int) BImode] = const1_rtx;
+
+  pc_rtx = gen_rtx_fmt_ (PC, VOIDmode);
+  ret_rtx = gen_rtx_fmt_ (RETURN, VOIDmode);
+  simple_return_rtx = gen_rtx_fmt_ (SIMPLE_RETURN, VOIDmode);
+  cc0_rtx = gen_rtx_fmt_ (CC0, VOIDmode);
 }
 
 /* Produce exact duplicate of insn INSN after AFTER.

Re: [patch libgcc]: Fix float128 soft-float for mingw targets

[Joseph S. Myers]

On Mon, 27 Feb 2012, Kai Tietz wrote:

> 2012-02-28  Kai Tietz  
> 
>   * soft-fp/soft-fp.h (_FP_STRUCT_LAYOUT): If not defined,
>   define it as empty macro.
>   * soft-fp/quad.h: Mark bitfield-structures by _FP_STRUCT_LAYOUT.
>   * soft-fp/extended.h: Likewise.
>   * soft-fp/single.h: Likewise.
>   * soft-fp/double.h: Likewise.

Thanks.  This looks fine to me, modulo ChangeLog and comment wording and 
copyright year updates.  I'd propose to commit it in a few days' time with 
those fixed unless anyone sees any problems with it.

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

Re: [libitm] Add SPARC bits

[Eric Botcazou]

> We need a reliable way to test for v9/v8plus/whatever properly because
> nobody is testing current gcc with real 32-bit pre-v9 sparc hardware and
> not providing atomics and proper cpu_relax implementations is just silly.

Both libgomp and libitm already force -mcpu=v9 though (and simply aren't built 
if it cannot be forced) so I don't think we should care about pre-v9 here.

I think the issue is just how we unify the two cpu_relax implementations:

static inline void
cpu_relax (void)
{
#if defined __arch64__ || defined  __sparc_v9__
  __asm volatile ("membar #LoadLoad" : : : "memory");
#else
  __asm volatile ("" : : : "memory");
#endif
}

for libgomp and:

static inline void
cpu_relax (void)
{
  __asm volatile ("rd %%ccr, %%g0" : : : "memory");
}

for libitm.


Would

static inline void
cpu_relax (void)
{
  __asm volatile ("membar #LoadLoad" : : : "memory");
}

be good enough?

-- 
Eric Botcazou

Re: [libitm] Add SPARC bits

[David Miller]

From: Eric Botcazou 
Date: Mon, 27 Feb 2012 21:41:23 +0100

> I think the issue is just how we unify the two cpu_relax implementations:
> 
> static inline void
> cpu_relax (void)
> {
> #if defined __arch64__ || defined  __sparc_v9__
>   __asm volatile ("membar #LoadLoad" : : : "memory");
> #else
>   __asm volatile ("" : : : "memory");
> #endif
> }
> 
> for libgomp and:
> 
> static inline void
> cpu_relax (void)
> {
>   __asm volatile ("rd %%ccr, %%g0" : : : "memory");
> }
> 
> for libitm.
> 
> 
> Would
> 
> static inline void
> cpu_relax (void)
> {
>   __asm volatile ("membar #LoadLoad" : : : "memory");
> }
> 
> be good enough?

I'm not sure, because I'm pretty sure this type of membar acts as a
NOP on basically every sparc v9 chip ever made.

I would prefer to see the rd %%ccr used in both places if possible,
as we know that forces a cpu thread yield.

Re: PR middle-end/52373: two pc_rtxs, etc.

[Mike Stump]

On Feb 27, 2012, at 11:58 AM, Richard Sandiford wrote:
> This patch fixed PR 52373,

This 52373:

Bug 52373 - template usage drops some checks on the accessibility of a member

?

Re: [libitm] Add SPARC bits

[Eric Botcazou]

> I'm not sure, because I'm pretty sure this type of membar acts as a
> NOP on basically every sparc v9 chip ever made.

OK, I was inferring from the libgomp implementation that the #LoadLoad variant
might also have yielding properties.

> I would prefer to see the rd %%ccr used in both places if possible,
> as we know that forces a cpu thread yield.

Fine with me.  I'll do some testing and then change libgomp, thanks.

-- 
Eric Botcazou

Re: [Patch, Fortran] PR 52196 add -Wrealloc-lhs(-all)

[Mikael Morin]

Hello, 

On Tuesday 14 February 2012 12:42:21 Tobias Burnus wrote:
> Fortunately, -O0 is often sufficient to remove the reallocation code. 
>
I guess you mean -O1 here...

> In turn, the warning might be printed even if at the end no realloc code is
> generated or present with -O1. 
> 
Can it be caused by the frontend not going in the realloc-lhs functions in 
some cases? Especially, it seems that there is a missing codimension/coindexed 
condition guarding the warning if I compare to the flag_realloc_lhs conditions 
in trans-expr.c
I would rather move the warnings to a function and call it in the places where 
we really generate the extra code, like it's done for -Warray-temporaries.

Mikael

Re: [PATCH] fix PR48299 by merging changes for thread_leak_test.c from upstream

[Jack Howarth]

On Mon, Feb 27, 2012 at 10:07:20AM -0800, Mike Stump wrote:
> On Feb 27, 2012, at 8:41 AM, Jack Howarth wrote:
> > Currently the testsuite/boehm-gc.c/thread_leak_test.c executation test
> > will hang on several targets including x86_64-apple-darwin10/11 for 
> > -m32/-m64.
> > The attached patch eliminates this issue, PR48299, by merging in the
> > upstream changes for this testcase from...
> 
> > Index: testsuite/boehm-gc.c/thread_leak_test.c
> 
> So, ideally, I'd like to have Bryce or Tom review this change or at least the 
> methodology, if they are still working in this area.

Mike,
   Since this is just a testsuite issue in boehm-gc, wouldn't this be Hans' 
call? I would definitely
like to get this fixed in gcc 4.7 so that the boehm-gc testsuite doesn't suffer 
timeouts. Also note
that gcc 4.7 is the first release which seems to report boehm-gc testresults.

http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02427.html

vs

http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg01854.html

  Jack

[lra] patch to fix some testsuite regressions on s390

[Vladimir Makarov]

The following patch fixes a few GCC testsuite regressions on s390x (the 
bootstrap on s390x is still broken).


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

Committed as rev. 184608.

2012-02-27  Vladimir Makarov 

* lra-eliminations.c (eliminate_regs_in_insn): Rewrite by
separating case with REPLACE_P for insn setting
FRAME_POINTER_REGNUM.


Index: lra-eliminations.c
===
--- lra-eliminations.c	(revision 184512)
+++ lra-eliminations.c	(working copy)
@@ -789,6 +789,8 @@ eliminate_regs_in_insn (rtx insn, bool r
   /* Check for setting an eliminable register.  */
   if ((ep = get_elimination (regno)) != NULL)
 	{
+	  bool delete_p = replace_p;
+
 #ifdef HARD_FRAME_POINTER_REGNUM
 	  /* If this is setting the frame pointer register to the
 	 hardware frame pointer register and this is an
@@ -799,67 +801,72 @@ eliminate_regs_in_insn (rtx insn, bool r
 	  if (ep->from == FRAME_POINTER_REGNUM
 	  && ep->to == HARD_FRAME_POINTER_REGNUM)
 	{
-	  rtx base = SET_SRC (old_set);
-	  rtx base_insn = insn;
-	  HOST_WIDE_INT offset = 0;
-	  
-	  while (base != ep->to_rtx)
+	  if (replace_p)
 		{
-		  rtx prev_insn, prev_set;
-		  
-		  if (GET_CODE (base) == PLUS && CONST_INT_P (XEXP (base, 1)))
-		{
-		  offset += INTVAL (XEXP (base, 1));
-		  base = XEXP (base, 0);
-		}
-		  else if ((prev_insn = prev_nonnote_insn (base_insn)) != 0
-			   && (prev_set = single_set (prev_insn)) != 0
-			   && rtx_equal_p (SET_DEST (prev_set), base))
-		{
-		  base = SET_SRC (prev_set);
-		  base_insn = prev_insn;
-		}
-		  else
-		break;
+		  SET_DEST (old_set) = ep->to_rtx;
+		  lra_update_insn_recog_data (insn);
+		  return;
 		}
-	  
-	  if (base == ep->to_rtx)
+	  else
 		{
-		  rtx src;
-		  
-		  offset = (! replace_p
-			? offset - (ep->offset - ep->previous_offset)
-			: offset);
-		  src = plus_constant (ep->to_rtx, offset);
-		  
-		  old_set = single_set (insn);
-		  
-		  /* First see if this insn remains valid when we make
-		 the change.  If not, keep the INSN_CODE the same
-		 and let reload fit it up.  */
-		  validate_change (insn, &SET_SRC (old_set), src, 1);
-		  validate_change (insn, &SET_DEST (old_set),
-   replace_p ? ep->to_rtx : ep->from_rtx, 1);
-		  if (! apply_change_group ())
+		  rtx base = SET_SRC (old_set);
+		  HOST_WIDE_INT offset = 0;
+		  rtx base_insn = insn;
+
+		  while (base != ep->to_rtx)
 		{
-		  SET_SRC (old_set) = src;
-		  SET_DEST (old_set)
-			= replace_p ? ep->to_rtx : ep->from_rtx;
+		  rtx prev_insn, prev_set;
+		  
+		  if (GET_CODE (base) == PLUS
+			  && CONST_INT_P (XEXP (base, 1)))
+			{
+			  offset += INTVAL (XEXP (base, 1));
+			  base = XEXP (base, 0);
+			}
+		  else if ((prev_insn = prev_nonnote_insn (base_insn)) != 0
+			   && (prev_set = single_set (prev_insn)) != 0
+			   && rtx_equal_p (SET_DEST (prev_set), base))
+			{
+			  base = SET_SRC (prev_set);
+			  base_insn = prev_insn;
+			}
+		  else
+			break;
 		}
 
-		  lra_update_insn_recog_data (insn);
-		  return;
+		  if (base == ep->to_rtx)
+		{
+		  rtx src;
+		  
+		  offset -= (ep->offset - ep->previous_offset);
+		  src = plus_constant (ep->to_rtx, offset);
+		  
+		  /* First see if this insn remains valid when we
+			 make the change.  If not, keep the INSN_CODE
+			 the same and let reload fit it up.  */
+		  validate_change (insn, &SET_SRC (old_set), src, 1);
+		  validate_change (insn, &SET_DEST (old_set),
+   ep->from_rtx, 1);
+		  if (! apply_change_group ())
+			{
+			  SET_SRC (old_set) = src;
+			  SET_DEST (old_set) = ep->from_rtx;
+			}
+		  lra_update_insn_recog_data (insn);
+		  return;
+		}
 		}
+
+	 
+	  /* We can't delete this insn, but needn't process it
+		 since it won't be used unless something changes. */
+	  delete_p = false;
 	}
 #endif
 	  
-	  /* In this case this insn isn't serving a useful purpose.
-	 We delete it.
-	 
-	 If REPLACE_P isn't set, we can't delete this insn, but
-	 needn't process it since it won't be used unless
-	 something changes.  */
-	  if (replace_p)
+	  /* This insn isn't serving a useful purpose.  We delete it
+	 when REPLACE is set.  */
+	  if (delete_p)
 	lra_delete_dead_insn (insn);
 	  return;
 	}

Re: [PATCH] fix PR48299 by merging changes for thread_leak_test.c from upstream

[Mike Stump]

On Feb 27, 2012, at 1:01 PM, Jack Howarth wrote:
>   Since this is just a testsuite issue in boehm-gc, wouldn't this be Hans' 
> call? I would definitely
> like to get this fixed in gcc 4.7 so that the boehm-gc testsuite doesn't 
> suffer timeouts. Also note
> that gcc 4.7 is the first release which seems to report boehm-gc testresults.

If you check the changelogs, the java people usually do the pulling.  Since 
they have a history doing it, they are the best to know about any problems 
associated with imports.  If they abdicate, I'll approve it, though, late 
timing might push it past the .0 release.

Re: PR middle-end/52373: two pc_rtxs, etc.

[Richard Sandiford]

Mike Stump  writes:
> On Feb 27, 2012, at 11:58 AM, Richard Sandiford wrote:
>> This patch fixed PR 52373,
>
> This 52373:
>
> Bug 52373 - template usage drops some checks on the accessibility of a member

Let's pretend I said 52372...

(Now also added to the changelog)

Richard

Re: Unreviewed libstdc++/libgomp patch

[Jakub Jelinek]

On Mon, Feb 27, 2012 at 02:38:14PM +0100, Rainer Orth wrote:
> Paolo Carlini  writes:
> 
> >> Jakub Jelinek  writes:
> >>
> >>> On Wed, Feb 22, 2012 at 12:07:39PM +0100, Rainer Orth wrote:
>  The following patch has remained unreviewed for a week:
> 
>   [v3, libgomp, build] Fix Solaris symbol versioning (PR libstdc++/52188)
>   http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00819.html
> 
>  It is critical to avoid breaking libstdc++.so symbol versioning on
>  Solaris and requires libstdc++ and libgomp maintainers.
> >>> The libgomp changes are ok if the libstdc++ changes are approved.
> >> Thanks.  Unfortunately, none of the libstdc++ maintainers hasn't
> >> commented in almost two weeks.  It would be a pity to release 4.7.0 with
> >> this bug unfixed.
> > I cannot say to understand in detail the issue, but if it affects Solaris
> > only, likewise the fix (I think so), and you double checked it on, say,
> > x86_64-Linux, the patch is Ok with me.
> 
> While the mechanism introduced is generic, it currently affects Solaris
> only.  And yes, I've compared versioning in libstdc++.so and libgomp.so
> on x86_64-unknown-linux-gnu without and with the patch as described in
> the submission: no change.

Unfortunately this broke build on powerpc{,64}-linux and likely all other
GLIBCXX_LDBL* targets.

The problem is that config/abi/pre/gnu.ver doesn't end with a newline,
so we end up with:

# Symbols in the support library (libsupc++) supporting transactional memory.
CXXABI_TM_1 {

  global:
__cxa_tm_cleanup;

};# Appended to version file.

GLIBCXX_LDBL_3.4 {   
  _ZNSt14numeric_limitsIgE*;

and $(EGREP) -v '#(#| |$$)' just throws away the whole
};# Appended to version file.
line.  I wonder if
sed -e 's/#[# $].*$//'
wouldn't be better, or alternative add ^ before the first #
in the egrep regex.  Of course we can add a newline to gnu.ver, but the
next time somebody forgots to add a newline at the end of the file
we'll have the same problem again.

Benjamin, what do you prefer?

Jakub

Re: Unreviewed libstdc++/libgomp patch

[Benjamin Kosnik]

On Tue, 28 Feb 2012 00:12:33 +0100
Jakub Jelinek  wrote:

> and $(EGREP) -v '#(#| |$$)' just throws away the whole
> };# Appended to version file.
> line.  I wonder if
> sed -e 's/#[# $].*$//'
> wouldn't be better, or alternative add ^ before the first #
> in the egrep regex.  Of course we can add a newline to gnu.ver, but
> the next time somebody forgots to add a newline at the end of the file
> we'll have the same problem again.
> 
> Benjamin, what do you prefer?

I would prefer not having gnu.ver have to end in a newline. Slight
preference for ^ before first # but I don't really care.

-benjamin

[RFC PATCH 1/3] Misaligned top level MEM_REFs on LHS of assignments

[Martin Jambor]

Hi,

the first patch in the series deals with plain MEM_REFs on LHS of
assignments to handle situations such as the testcase which currently
fails on strict alignment platforms (the array and the loop are there
to cross a cache line on ia64 so that it fails there too).

This patch piggy-backs on already existing code for generating
movmisalign operation if available, and deals with the store by
calling store_bit_field if it is not but it would be a
SLOW_UNALIGNED_ACCESS.

I have added !mem_ref_refers_to_non_mem_p (to) to the condition
guarding both of these paths because without it I encountered
testsuite failures within expand_expr when the MEM_REF address
argument was expanded into something else than memory.  This call is
common for both movmisalign_optab and store_bit_field paths so I
believe it is necessary on both but so far I did not come up with a
testcase in which it would fail with movmisalign.

Thanks,

Martin



2012-02-28  Martin Jambor  

* expr.c (expand_assignment): Handle misaligned scalar writes to
memory through top-level MEM_REFs by calling store_bit_field.

* testsuite/gcc.dg/misaligned-expand-2.c: New test.


Index: src/gcc/expr.c
===
--- src.orig/gcc/expr.c
+++ src/gcc/expr.c
@@ -4593,10 +4593,12 @@ expand_assignment (tree to, tree from, b
   if ((TREE_CODE (to) == MEM_REF
|| TREE_CODE (to) == TARGET_MEM_REF)
   && mode != BLKmode
+  && !mem_ref_refers_to_non_mem_p (to)
   && ((align = get_object_or_type_alignment (to))
  < GET_MODE_ALIGNMENT (mode))
-  && ((icode = optab_handler (movmisalign_optab, mode))
- != CODE_FOR_nothing))
+  && (((icode = optab_handler (movmisalign_optab, mode))
+  != CODE_FOR_nothing)
+ || SLOW_UNALIGNED_ACCESS (mode, align)))
 {
   addr_space_t as
= TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 0;
@@ -4639,11 +4641,17 @@ expand_assignment (tree to, tree from, b
   if (TREE_THIS_VOLATILE (to))
MEM_VOLATILE_P (mem) = 1;
 
-  create_fixed_operand (&ops[0], mem);
-  create_input_operand (&ops[1], reg, mode);
-  /* The movmisalign pattern cannot fail, else the assignment would
-silently be omitted.  */
-  expand_insn (icode, 2, ops);
+  if (icode != CODE_FOR_nothing)
+   {
+ create_fixed_operand (&ops[0], mem);
+ create_input_operand (&ops[1], reg, mode);
+ /* The movmisalign pattern cannot fail, else the assignment 
would
+silently be omitted.  */
+ expand_insn (icode, 2, ops);
+   }
+  else
+   store_bit_field (mem, GET_MODE_BITSIZE (mode),
+0, 0, 0, mode, reg);
   return;
 }
 
Index: src/gcc/testsuite/gcc.dg/misaligned-expand-2.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/misaligned-expand-2.c
@@ -0,0 +1,42 @@
+/* Test that expand can generate correct stores to misaligned data even on
+   strict alignment platforms.  */
+
+/* { dg-do run } */
+/* { dg-options "-O0" } */
+
+extern void abort ();
+
+typedef unsigned int myint __attribute__((aligned(1)));
+
+void
+foo (myint *p, unsigned int i)
+{
+  *p = i;
+}
+
+#define cst 0xdeadbeef
+#define NUM 8
+
+struct blah
+{
+  char c;
+  myint i[NUM];
+};
+
+struct blah g;
+
+#define cst 0xdeadbeef
+
+int
+main (int argc, char **argv)
+{
+  int k;
+
+  for (k = 0; k < NUM; k++)
+{
+  foo (&g.i[k], cst);
+  if (g.i[k] != cst)
+   abort ();
+}
+  return 0;
+}

[RFC PATCH 0/3] Fixing expansion of misaligned MEM_REFs on strict-alignment targets

[Martin Jambor]

Hi,

this is another iteration of my attempts to fix expansion of
misaligned memory accesses on strict-alignment platforms (which was
suggested by Richi in
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00931.html and my first
attempt was posted as
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00319.html).

This time I got further, to big extent thanks to parts of Richi's
fixes of PR 50444 which cleaned up expr.c considerably.  I have
successfully bootstrapped the combined patch on x86_64-linux,
i686-linux, ia64-linux (without Ada) and sparc64-linux (without Java).
I have run the c and c++ testsuites on individual patches on sparc64
and ia64 too.

Nevertheless, since I still lack experience in this area, there will
almost certainly be comments and suggestions and therefore I have
divided the three main changes to three different patches, so that
they are easier to comment on by both me and anybody reviewing them.

Thanks in advance for any comments,

Martin

[RFC PATCH 2/3] Misaligned MEM_REFs within handled_components on LHS of assignments

[Martin Jambor]

Hi,

the second patch in the series handles MEM_REFs on LHS which are parts
of a handled_component, usually a COMPONENT_REF.  The failing testcase
which requires it is not actually the one in the patch but it is
gcc.c-torture/execute/mayalias-3.c which fails at -O1 without this
change but with the third patch applied.

The mechanism is the same as in the previous patch, it also
piggy-backs a store_bit_field call onto generation of movmisalign
operation, if that is not available but the access would be
SLOW_UNALIGNED_ACCESS.  I also needed to add
!mem_ref_refers_to_non_mem_p condition for the same reasons.
Additionally, complex numbers and accesses to their components are
already handled by the existing code (the new testcase passes on all
platforms I tried and so I added it to make sure it continues to) and
actually messing with it further leads to failures (of
g++.dg/torture/pr34099.C at -O1).  Therefore I added a condition to
punt on complex modes.

Thanks,

Martin


2012-02-28  Martin Jambor  

* expr.c (expand_assignment): Handle misaligned scalar writes to
memory through MEM_REFs within handled_components by calling
store_bit_field.

* testsuite/gcc.dg/misaligned-expand-3.c: New test.


Index: src/gcc/expr.c
===
--- src.orig/gcc/expr.c
+++ src/gcc/expr.c
@@ -4575,7 +4575,7 @@ expand_assignment (tree to, tree from, b
   rtx result;
   enum machine_mode mode;
   unsigned int align;
-  enum insn_code icode;
+  enum insn_code icode = (enum insn_code) 0;
 
   /* Don't crash if the lhs of the assignment was erroneous.  */
   if (TREE_CODE (to) == ERROR_MARK)
@@ -4689,10 +4689,13 @@ expand_assignment (tree to, tree from, b
   mode = TYPE_MODE (TREE_TYPE (tem));
   if (TREE_CODE (tem) == MEM_REF
  && mode != BLKmode
+ && !COMPLEX_MODE_P (mode)
+ && !mem_ref_refers_to_non_mem_p (tem)
  && ((align = get_object_or_type_alignment (tem))
  < GET_MODE_ALIGNMENT (mode))
- && ((icode = optab_handler (movmisalign_optab, mode))
- != CODE_FOR_nothing))
+ && (((icode = optab_handler (movmisalign_optab, mode))
+  != CODE_FOR_nothing)
+ || SLOW_UNALIGNED_ACCESS (mode, align)))
{
  misalignp = true;
  to_rtx = gen_reg_rtx (mode);
@@ -4871,13 +4874,18 @@ expand_assignment (tree to, tree from, b
  if (TREE_THIS_VOLATILE (tem))
MEM_VOLATILE_P (mem) = 1;
 
- create_fixed_operand (&ops[0], mem);
- create_input_operand (&ops[1], to_rtx, mode);
- /* The movmisalign pattern cannot fail, else the assignment
-would silently be omitted.  */
- expand_insn (icode, 2, ops);
+ if (icode != CODE_FOR_nothing)
+   {
+ create_fixed_operand (&ops[0], mem);
+ create_input_operand (&ops[1], to_rtx, mode);
+ /* The movmisalign pattern cannot fail, else the assignment
+would silently be omitted.  */
+ expand_insn (icode, 2, ops);
+   }
+ else
+   store_bit_field (mem, GET_MODE_BITSIZE (mode),
+0, 0, 0, mode, to_rtx);
}
-
   if (result)
preserve_temp_slots (result);
   free_temp_slots ();
Index: src/gcc/testsuite/gcc.dg/misaligned-expand-3.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/misaligned-expand-3.c
@@ -0,0 +1,43 @@
+/* Test that expand can generate correct stores to misaligned data of complex
+   type even on strict alignment platforms.  */
+
+/* { dg-do run } */
+/* { dg-options "-O0" } */
+
+extern void abort ();
+
+typedef _Complex float mycmplx __attribute__((aligned(1)));
+
+void
+foo (mycmplx *p, float r, float i)
+{
+  __real__ *p = r;
+  __imag__ *p = i;
+}
+
+#define cvr 3.2f
+#define cvi 2.5f
+#define NUM 8
+
+struct blah
+{
+  char c;
+  mycmplx x[NUM];
+} __attribute__((packed));
+
+struct blah g;
+
+int
+main (int argc, char **argv)
+{
+  int k;
+
+  for (k = 0; k < NUM; k++)
+{
+  foo (&g.x[k], cvr, cvi);
+  if (__real__ g.x[k] != cvr
+ || __imag__ g.x[k] != cvi)
+   abort ();
+}
+  return 0;
+}

[RFC PATCH 3/3] Misaligned MEM_REF reads

[Martin Jambor]

Hi,

this patch fixes misaligned reads through MEM_REFs such as the one in
the testcase which currently fails on both sparc64 and ia64 (again,
the array and the loop are there to cross ia64 cache line and fail
there too).  The patch has to be applied last in the series so that
the current LHS expansion does not attempt to use the new code.

The mechanism is again very similar, except that we call
extract_bit_field instead now.  We do not need to care about the
mem_ref_refers_to_non_mem_p case because that is already handled at
this stage.  On the other hand, messing with complex types actually
breaks currently working testcases such as the one from the previous
patch (I have not really fully investigated what goes on so far but it
genuinely seems to work) so again I punt for complex modes.

There are two more movmisalign_optab generations in this function.
There is the TARGET_MEM_REF case which I intend to piggy-back on in
the same way like MEM_REF is handled in this patch once it leaves the
RFC stage.  Finally, movmisalign_optab is also generated in
VIEW_CONVERT_EXPR case but as far as I understand the code, misaligned
loads are already handled there (only perhaps we should use
SLOW_UNALIGNED_ACCESS instead of STRICT_ALIGNMENT there?).

Thanks,

Martin


2012-02-28  Martin Jambor  

* expr.c (expand_expr_real_1): handle misaligned scalar reads from
memory through MEM_REFs by calling extract_bit_field.

* testsuite/gcc.dg/misaligned-expand-1.c: New test.


Index: src/gcc/expr.c
===
--- src.orig/gcc/expr.c
+++ src/gcc/expr.c
@@ -9453,21 +9453,29 @@ expand_expr_real_1 (tree exp, rtx target
if (TREE_THIS_VOLATILE (exp))
  MEM_VOLATILE_P (temp) = 1;
if (mode != BLKmode
-   && align < GET_MODE_ALIGNMENT (mode)
-   /* If the target does not have special handling for unaligned
-  loads of mode then it can use regular moves for them.  */
-   && ((icode = optab_handler (movmisalign_optab, mode))
-   != CODE_FOR_nothing))
+   && !COMPLEX_MODE_P (mode)
+   && align < GET_MODE_ALIGNMENT (mode))
  {
-   struct expand_operand ops[2];
+   if ((icode = optab_handler (movmisalign_optab, mode))
+   != CODE_FOR_nothing)
+ {
+   struct expand_operand ops[2];
 
-   /* We've already validated the memory, and we're creating a
-  new pseudo destination.  The predicates really can't fail,
-  nor can the generator.  */
-   create_output_operand (&ops[0], NULL_RTX, mode);
-   create_fixed_operand (&ops[1], temp);
-   expand_insn (icode, 2, ops);
-   return ops[0].value;
+   /* We've already validated the memory, and we're creating a
+  new pseudo destination.  The predicates really can't fail,
+  nor can the generator.  */
+   create_output_operand (&ops[0], NULL_RTX, mode);
+   create_fixed_operand (&ops[1], temp);
+   expand_insn (icode, 2, ops);
+   return ops[0].value;
+ }
+   else if (!COMPLEX_MODE_P (mode)
+&& SLOW_UNALIGNED_ACCESS (mode, align))
+ temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
+   0, TYPE_UNSIGNED (TREE_TYPE (exp)), 
true,
+   (modifier == EXPAND_STACK_PARM
+? NULL_RTX : target),
+   mode, mode);
  }
return temp;
   }
Index: src/gcc/testsuite/gcc.dg/misaligned-expand-1.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/misaligned-expand-1.c
@@ -0,0 +1,41 @@
+/* Test that expand can generate correct loads of misaligned data even on
+   strict alignment platforms.  */
+
+/* { dg-do run } */
+/* { dg-options "-O0" } */
+
+extern void abort ();
+
+typedef unsigned int myint __attribute__((aligned(1)));
+
+unsigned int
+foo (myint *p)
+{
+  return *p;
+}
+
+#define cst 0xdeadbeef
+#define NUM 8
+
+struct blah
+{
+  char c;
+  myint i[NUM];
+};
+
+struct blah g;
+
+int
+main (int argc, char **argv)
+{
+  int i, k;
+  for (k = 0; k < NUM; k++)
+{
+  g.i[k] = cst;
+  i = foo (&g.i[k]);
+
+  if (i != cst)
+   abort ();
+}
+  return 0;
+}

Re: Unreviewed libstdc++/libgomp patch

[Marc Glisse]

On Tue, 28 Feb 2012, Jakub Jelinek wrote:


The problem is that config/abi/pre/gnu.ver doesn't end with a newline,

[...]

Of course we can add a newline to gnu.ver, but the
next time somebody forgots to add a newline at the end of the file
we'll have the same problem again.


I seem to remember someone proposing (some years ago) a commit hook to 
prevent such bugs on all "text" files. I can't remember if there were 
arguments against it or just a lack of interest.


--
Marc Glisse