Re: Go testsuite patch committed: Load timeout.exp

[Matthias Klose]

Am 18.02.2013 20:07, schrieb Ian Lance Taylor:
>> the libgo testsuite unfortunately works not as all other testsuite for the
>> > libraries do work. Usually if you do want to test a multilib build, you 
>> > call
>> >
>> >   RUNTESTFLAGS="--target_board=unix\{,-m32,-mx32\}" make -k check
>> >
>> > and only the check target for the default multilib is called. libgo however
>> > descends into the non-default multilib targets and calls check there too. 
>> > And
>> > then with the above RUNTESTFLAGS, every go test is called nine times 
>> > instead of
>> > three times, and apparently fails the other six times.
>> >
>> > Please let libgo behave the same as the other target libraries for the 
>> > check
>> > target, even it does introduce some delta.
> I can't remember if there is a bug report open for this or not.

this is now PR go/56432.

Re: [lra] merged with trunk

[Andrew Pinski]

On Fri, Feb 22, 2013 at 2:50 PM, Steven Bosscher  wrote:
> On Fri, Feb 22, 2013 at 11:26 PM, Vladimir Makarov wrote:
>>> I still have a large number of FAILs on mipsisa64 that weren't there
>>> before. Compare these two results to see what I mean:
>>>
>>> http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00123.html
>>> http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg02535.html
>>>
>>> Unfortunately I can't tell quickly whether this is due to LRA changes
>>> or due to other changes merged from trunk.
>>>
>> Steven, thanks for reporting this.  I'll look at this on next week.
>
> No need, these failures are also present on trunk. Probably some patch
> broke this on trunk and that patch got merged into the LRA branch.
> I'll see if I can identify the problematic commit.

Actually it is already been talked about in
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01078.html and it looks
like Jakub actually provided a patch.

Thanks,
Andrew Pinski

Re: [lra] merged with trunk

[Steven Bosscher]

On Fri, Feb 22, 2013 at 11:26 PM, Vladimir Makarov wrote:
>> I still have a large number of FAILs on mipsisa64 that weren't there
>> before. Compare these two results to see what I mean:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00123.html
>> http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg02535.html
>>
>> Unfortunately I can't tell quickly whether this is due to LRA changes
>> or due to other changes merged from trunk.
>>
> Steven, thanks for reporting this.  I'll look at this on next week.

No need, these failures are also present on trunk. Probably some patch
broke this on trunk and that patch got merged into the LRA branch.
I'll see if I can identify the problematic commit.

Ciao!
Steven

Re: r196201 - in /trunk: gcc/ChangeLog gcc/config/i...

[H.J. Lu]

On Fri, Feb 22, 2013 at 4:58 AM, Jakub Jelinek  wrote:
> On Fri, Feb 22, 2013 at 11:53:39AM +0400, Konstantin Serebryany wrote:
>> Jakub, thanks again for cleaning up my mess.
>>
>> Here is a question regarding your fix:
>> > -#if ASAN_USE_PREINIT_ARRAY
>> > +#if ASAN_USE_PREINIT_ARRAY && !defined (PIC)
>>
>> The PIC macro is an artifact of the GCC build system and is not
>> directly related the the -fPIC flag?
>> As I can see, in the gcc build we compile all of asan sources twice:
>> w/ and w/o "-fPIC -DPIC".
>> If I move the preinit_array to a separate file (asan_preinit.cc), will
>> we need to have two builds?
>> I think we can just build all objects once with -fPIC and then not
>> link asan_preinit.o into libasan.so
>> In clang we build the static libasan with -fPIC, it doesn't hurt.
>> Anyway, I've just committed
>> http://llvm.org/viewvc/llvm-project?rev=175871&view=rev with
>> asan_preinit.cc
>
> Here is corresponding gcc patch to use it.
> libasan_preinit.o is installed alongside with libasan.a and libasan.so*,
> and linked into executables (but not shared libraries).
>
> Additionally, I've added __attribute__((constructor)) to __asan_init,
> to make it more likely that asan will be initialized properly even when
> the executable isn't instrumented.  Shared libraries linked with
> -fsanitize=address will depend on libasan.so.0, and the dynamic linker first
> runs constructors of dependencies before running constructors of the
> libraries that have those dependencies (unless there are dependency cycles, 
> but that
> is a user bug).
>
> 2013-02-22  Jakub Jelinek  
>
> PR sanitizer/56393
> * config/gnu-user.h (LIBASAN_EARLY_SPEC): Link in libasan_preinit.o
> if not linking a shared library.
>
> * lib/asan-dg.exp (asan_link_flags): Add
> -B${gccpath}/libsanitizer/asan/ to flags.
>
> * asan/Makefile.am (nodist_toolexeclib_HEADERS): Set to
> libasan_preinit.o.
> (libasan_preinit.o): Depend on asan_preinit.o.
> * asan/Makefile.in: Regenerated.
> * asan/asan_preinit.cc: New file, synced from upstream.
> * asan/asan_rtl.cc: Remove preinit stuff, synced from upstream.
> Add __attribute__((constructor)) to __asan_init.
>

We also need this patch.  OK to install?

Thanks.

H.J.
--
2013-02-22  H.J. Lu  

* bootstrap-asan.mk (POSTSTAGE1_LDFLAGS): Add
-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.
diff --git a/config/bootstrap-asan.mk b/config/bootstrap-asan.mk
index d37a9da..e3f34f5 100644
--- a/config/bootstrap-asan.mk
+++ b/config/bootstrap-asan.mk
@@ -3,4 +3,5 @@
 STAGE2_CFLAGS += -fsanitize=address
 STAGE3_CFLAGS += -fsanitize=address
 POSTSTAGE1_LDFLAGS += -fsanitize=address -static-libasan \
+ -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/ \
  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs

Re: [lra] merged with trunk

[Vladimir Makarov]

On 13-02-22 4:42 PM, Steven Bosscher wrote:

On Fri, Feb 22, 2013 at 9:15 PM, Vladimir Makarov wrote:

LRA branch was merged with trunk @ 196224.

The branch was successfully bootstrapped on x86/x86-64, ppc64, and ia64.

Hello Vlad,

Thanks for the fix and merge.

I still have a large number of FAILs on mipsisa64 that weren't there
before. Compare these two results to see what I mean:

http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00123.html
http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg02535.html

Unfortunately I can't tell quickly whether this is due to LRA changes
or due to other changes merged from trunk.


Steven, thanks for reporting this.  I'll look at this on next week.

C++ PATCH for c++/56359 (wrong access error with function template)

[Jason Merrill]

We need to be careful not to do any access checking on the actual 
arguments to the function when we're pushed into the context of the 
function being instantiated.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7498f299d97da75ce3ab30d0626818a143fbaab9
Author: Jason Merrill 
Date:   Fri Feb 22 10:44:03 2013 -0500

	PR c++/56359
	* call.c (can_convert_arg): Discard access checks.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 25dfd51..7c41421 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8765,11 +8765,18 @@ can_convert_arg (tree to, tree from, tree arg, int flags,
 
   /* Get the high-water mark for the CONVERSION_OBSTACK.  */
   p = conversion_obstack_alloc (0);
+  /* We want to discard any access checks done for this test,
+ as we might not be in the appropriate access context and
+ we'll do the check again when we actually perform the
+ conversion.  */
+  push_deferring_access_checks (dk_deferred);
 
   t  = implicit_conversion (to, from, arg, /*c_cast_p=*/false,
 			flags, complain);
   ok_p = (t && !t->bad_p);
 
+  /* Discard the access checks now.  */
+  pop_deferring_access_checks ();
   /* Free all the conversions we allocated.  */
   obstack_free (&conversion_obstack, p);
 
diff --git a/gcc/testsuite/g++.dg/template/access25.C b/gcc/testsuite/g++.dg/template/access25.C
new file mode 100644
index 000..e882a70
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/access25.C
@@ -0,0 +1,20 @@
+// PR c++/56359
+
+typedef int (*InvocationCallback) (const int &);
+
+template < typename target_t >
+void SetPrototypeMethod (target_t, const char *, InvocationCallback);
+
+class A
+{
+void Initialize ();
+protected:
+static int Stop (const int &);
+void Stop ();  // comment out to make the bug disappear.
+};
+
+void
+A::Initialize ()
+{
+SetPrototypeMethod (0, "stop", A::Stop);
+}

C++ PATCH for c++/56395 (ICE with template typename)

[Jason Merrill]

When we're stripping typedefs from a TYPENAME_TYPE, we need to handle 
any template arguments it might have.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit db3871b6aed11204a7e3336c27bd565e61000bce
Author: Jason Merrill 
Date:   Fri Feb 22 10:20:00 2013 -0500

	PR c++/56395
	* tree.c (strip_typedefs): Strip typedefs from TYPENAME_TYPE template
	args.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 41c8759..75b4d51 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1220,9 +1220,34 @@ strip_typedefs (tree t)
   }
   break;
 case TYPENAME_TYPE:
-  result = make_typename_type (strip_typedefs (TYPE_CONTEXT (t)),
-   TYPENAME_TYPE_FULLNAME (t),
-   typename_type, tf_none);
+  {
+	tree fullname = TYPENAME_TYPE_FULLNAME (t);
+	if (TREE_CODE (fullname) == TEMPLATE_ID_EXPR)
+	  {
+	tree args = TREE_OPERAND (fullname, 1);
+	tree new_args = copy_node (args);
+	bool changed = false;
+	for (int i = 0; i < TREE_VEC_LENGTH (args); ++i)
+	  {
+		tree arg = TREE_VEC_ELT (args, i);
+		tree strip_arg;
+		if (TYPE_P (arg))
+		  strip_arg = strip_typedefs (arg);
+		else
+		  strip_arg = strip_typedefs_expr (arg);
+		TREE_VEC_ELT (new_args, i) = strip_arg;
+		if (strip_arg != arg)
+		  changed = true;
+	  }
+	if (changed)
+	  fullname = lookup_template_function (TREE_OPERAND (fullname, 0),
+		   new_args);
+	else
+	  ggc_free (new_args);
+	  }
+	result = make_typename_type (strip_typedefs (TYPE_CONTEXT (t)),
+ fullname, typename_type, tf_none);
+  }
   break;
 case DECLTYPE_TYPE:
   result = strip_typedefs_expr (DECLTYPE_TYPE_EXPR (t));
diff --git a/gcc/testsuite/g++.dg/template/typename19.C b/gcc/testsuite/g++.dg/template/typename19.C
new file mode 100644
index 000..735deb2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/typename19.C
@@ -0,0 +1,24 @@
+// PR c++/56395
+
+struct A
+{
+  template  struct B { };
+};
+
+template  struct D { };
+
+template  struct C
+{
+  typedef T _Type;
+  typedef typename T::template B<_Type> _BType;
+  D<_BType> d;
+};
+
+template  struct C
+{
+  typedef T _Type;
+  typedef typename T::template B<_Type> _BType;
+  D<_BType> d;
+};
+
+C c;

C++ PATCH for c++/56377 (missing template binding in diagnostic context)

[Jason Merrill]

When we go to tsubst with explicit_args, we should put them in the tinst 
level.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2eb09da9c9e09ce1e08b024b60594ed4acf02d00
Author: Jason Merrill 
Date:   Fri Feb 22 10:58:47 2013 -0500

	PR c++/56377
	* pt.c (fn_type_unification): Use explicit args in template
	instantiation context.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 440df1e..a39d114 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -15008,8 +15008,10 @@ fn_type_unification (tree fn,
 
   processing_template_decl += incomplete;
   input_location = DECL_SOURCE_LOCATION (fn);
+  TREE_VALUE (tinst) = explicit_targs;
   fntype = tsubst (TREE_TYPE (fn), explicit_targs,
 		   complain | tf_partial, NULL_TREE);
+  TREE_VALUE (tinst) = targs;
   input_location = loc;
   processing_template_decl -= incomplete;
 

C++ PATCH for c++/40405 (ICE with invalid template)

[Jason Merrill]

Another place in push_template_decl_real already uses this technique to 
avoid crashing in import_export_decl.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit f9e38d8e08b8602fe0264fd381d97bff495acc32
Author: Jason Merrill 
Date:   Fri Feb 22 12:52:04 2013 -0500

	PR c++/40405
	* pt.c (push_template_decl_real): Set DECL_INTERFACE_KNOWN
	if we got the wrong number of template parms.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a39d114..5ff0821 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -4782,6 +4782,8 @@ push_template_decl_real (tree decl, bool is_friend)
 		  error ("got %d template parameters for %q#T",
 			 TREE_VEC_LENGTH (a), current);
 		error ("  but %d required", TREE_VEC_LENGTH (t));
+		/* Avoid crash in import_export_decl.  */
+		DECL_INTERFACE_KNOWN (decl) = 1;
 		return error_mark_node;
 	  }
 
diff --git a/gcc/testsuite/g++.dg/template/error49.C b/gcc/testsuite/g++.dg/template/error49.C
new file mode 100644
index 000..57789a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/error49.C
@@ -0,0 +1,10 @@
+// PR c++/40405
+
+template struct A
+{
+  static int i;
+};
+
+template int A<0,0>::i = 0; // { dg-error "" }
+
+int j = A<0,0>::i;

Re: [v3] correct doxygen parse

[Jonathan Wakely]

On 20 February 2013 02:07, Benjamin De Kosnik wrote:
>
> Fixups for doxygen. Since 2012-11-20, most of C++11 has been ignored by
> doxygen, resulting in some missing modules documentation even in HTML
> output.
>
> Jakub, this fixes the libstdc++.tag validation errors.
>
> I've regenerated the gcc.gnu.org docs for 4.8.0. They look equivalent or
> better than 4.7.2 to me now.

Parts of the libstdc++ manual are still severely out of date, and
misleading people e.g. the status page (which is probably the most
important part to keep up to date!) refers to monotonic_clock,
http://stackoverflow.com/a/15032749/981959

I fixed that in the status page on February 8th 2012, over a year ago,
but the page hasn't been regenerated since Jan 2012.

Re: [lra] merged with trunk

[Steven Bosscher]

On Fri, Feb 22, 2013 at 9:15 PM, Vladimir Makarov wrote:
> LRA branch was merged with trunk @ 196224.
>
> The branch was successfully bootstrapped on x86/x86-64, ppc64, and ia64.

Hello Vlad,

Thanks for the fix and merge.

I still have a large number of FAILs on mipsisa64 that weren't there
before. Compare these two results to see what I mean:

http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00123.html
http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg02535.html

Unfortunately I can't tell quickly whether this is due to LRA changes
or due to other changes merged from trunk.

Ciao!
Steven

[PATCH] mips: Document r4700

[Matt Turner]

2013-02-22  Matt Turner  

gcc/
* doc/invoke.texi: Document r4700.
---
 gcc/doc/invoke.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7d96467..63eb6a6 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15867,7 +15867,7 @@ The processor names are:
 @samp{octeon}, @samp{octeon+}, @samp{octeon2},
 @samp{orion},
 @samp{r2000}, @samp{r3000}, @samp{r3900}, @samp{r4000}, @samp{r4400},
-@samp{r4600}, @samp{r4650}, @samp{r6000}, @samp{r8000},
+@samp{r4600}, @samp{r4650}, @samp{r4700}, @samp{r6000}, @samp{r8000},
 @samp{rm7000}, @samp{rm9000},
 @samp{r1}, @samp{r12000}, @samp{r14000}, @samp{r16000},
 @samp{sb1},
-- 
1.7.12.4

[lra] merged with trunk

[Vladimir Makarov]

LRA branch was merged with trunk @ 196224.

The branch was successfully bootstrapped on x86/x86-64, ppc64, and ia64.

Committed as rev. 196226.

Re: PR target/52555: attribute optimize is overriding command line options

[Richard Sandiford]

Jakub Jelinek  writes:
> On Fri, Feb 22, 2013 at 09:31:54AM -0800, Steve Ellcey wrote:
>> On Fri, 2013-02-22 at 11:03 +0100, Jakub Jelinek wrote:
>> 
>> > The problem I believe is that Aldy has changed init_optabs and 
>> > insn-opinit.c
>> > to use this_fn_optabs instead of this_target_optabs, but it is only set in
>> > invoke_set_current_function_hook.  During save_target_globals we want to
>> > init this_target_optabs, so we need to temporarily switch this_fn_optabs to
>> > make that happen.
>> > 
>> > 2013-02-22  Jakub Jelinek  
>> > 
>> >PR target/52555
>> >* target-globals.c (save_target_globals): For init_reg_sets and
>> >target_reinit remporarily set this_fn_optabs to this_target_optabs.
>> > 
>> 
>> I built with this patch and ran the GCC testsuite (using the target
>> mips-mti-linux-gnu), it fixed the problem and caused no regressions for
>> me.
>
> Richard, is that ok for trunk then?

Looks good to me.  Thanks for fixing it.

Richard

Re: PR target/52555: attribute optimize is overriding command line options

[Jakub Jelinek]

On Fri, Feb 22, 2013 at 09:31:54AM -0800, Steve Ellcey wrote:
> On Fri, 2013-02-22 at 11:03 +0100, Jakub Jelinek wrote:
> 
> > The problem I believe is that Aldy has changed init_optabs and insn-opinit.c
> > to use this_fn_optabs instead of this_target_optabs, but it is only set in
> > invoke_set_current_function_hook.  During save_target_globals we want to
> > init this_target_optabs, so we need to temporarily switch this_fn_optabs to
> > make that happen.
> > 
> > 2013-02-22  Jakub Jelinek  
> > 
> > PR target/52555
> > * target-globals.c (save_target_globals): For init_reg_sets and
> > target_reinit remporarily set this_fn_optabs to this_target_optabs.
> > 
> 
> I built with this patch and ran the GCC testsuite (using the target
> mips-mti-linux-gnu), it fixed the problem and caused no regressions for
> me.

Richard, is that ok for trunk then?

Jakub

Re: PR target/52555: attribute optimize is overriding command line options

[Steve Ellcey]

On Fri, 2013-02-22 at 11:03 +0100, Jakub Jelinek wrote:

> The problem I believe is that Aldy has changed init_optabs and insn-opinit.c
> to use this_fn_optabs instead of this_target_optabs, but it is only set in
> invoke_set_current_function_hook.  During save_target_globals we want to
> init this_target_optabs, so we need to temporarily switch this_fn_optabs to
> make that happen.
> 
> 2013-02-22  Jakub Jelinek  
> 
>   PR target/52555
>   * target-globals.c (save_target_globals): For init_reg_sets and
>   target_reinit remporarily set this_fn_optabs to this_target_optabs.
> 

Jakub,

I built with this patch and ran the GCC testsuite (using the target
mips-mti-linux-gnu), it fixed the problem and caused no regressions for
me.

Steve Ellcey
sell...@imgtec.com

Re: do not pass PR_INSTRUMENTEDCODE if there is no instrumentation

[Richard Henderson]

On 02/21/2013 02:14 PM, Aldy Hernandez wrote:
> I suppose we could cheat and avoid passing PR_INSTRUMENTEDCODE if we
> ever enter expand_block_tm(), but perhaps we could do a little better as
> with the attached patch.

I assume you meant "never enter" there.

Yes, you don't need to "accumulate" GTMA_INSTRUMENTED_CODE.

Probably what should happen is that either

>   /* If we're sure to go irrevocable, there won't be
>  anything to expand, since the run-time will go
>  irrevocable right away.  */
>   if (sub & GTMA_DOES_GO_IRREVOCABLE
>   && sub & GTMA_MAY_ENTER_IRREVOCABLE)
> continue;

should in fact set EDGE_TM_UNINSTRUMENTED, or we should set that bit
even earlier

>   /* If we're sure to go irrevocable, don't transform anything.  */
>   if (d->irrevocable_blocks_normal
>   && bitmap_bit_p (d->irrevocable_blocks_normal,
>region->entry_block->index))
> {
>   transaction_subcode_ior (region, GTMA_DOES_GO_IRREVOCABLE);
>   transaction_subcode_ior (region, GTMA_MAY_ENTER_IRREVOCABLE);
>   continue;
> }

And while we're at it, ipa_tm_scan_calls_transaction should probably add
a check to skip doing ipa_uninstrument_transaction on transactions that
have already been so marked.


r~

Re: Fix PR 56077

[Jakub Jelinek]

On Fri, Feb 22, 2013 at 09:55:39AM -0700, Jeff Law wrote:
> On 02/22/13 09:52, abel wrote:
> >
> >Thanks. You are right, I forgot to fix the comment before submitting.
> >
> >Is the patch also fine for 4.7/4.6? The problem is also present there.
> It's up to the release managers for 4.7/4.6.  It certainly would
> have my blessing.

It is ok, but please give it a week or two on the trunk first.

Jakub

Re: Fix PR 56077

[Jeff Law]

On 02/22/13 09:52, abel wrote:


Thanks. You are right, I forgot to fix the comment before submitting.

Is the patch also fine for 4.7/4.6? The problem is also present there.
It's up to the release managers for 4.7/4.6.  It certainly would have my 
blessing.


jeff

Re: Fix PR 56077

[abel]

On 2013-02-22 18:21, Jeff Law wrote:

On 02/22/13 07:16, Alexander Monakov wrote:



You must be referring to the PR audit trail, right?  I'm sure the bug 
reporter
is mistaken that the stores are coalesced.  What happens is that two 
of the
three stores are moved up above the first asm, but because of how the 
awk

script cuts the generated code, that is not observed.

Thanks.  That makes a lot more sense.



Also, if we go forward with your patch, the comment related to this
conditional needs to be fixed -- it still says "Flush pending lists 
on jumps,

...", but you've removed the jump check.


Yeah, I'd say the comment is confusing both before and after the 
patch.
Perhaps something like "Don't flush pending lists on speculation 
checks during

selective scheduling" would be better.

Sounds good.  Approved with that comment change.


Thanks. You are right, I forgot to fix the comment before submitting.

Is the patch also fine for 4.7/4.6? The problem is also present there.

Andrey



Thanks,
jeff

Convert arm-rtems to EABI on 4.6 and 4.7 branches

[Joel Sherrill]

Hi

The RTEMS Community has realized we allowed something to occur
that should not have happened. As arm-elf was deprecated and removed,
we should have moved to EABI as our base.  The gcc head and 4.8 have
this situation corrected. Unfortunately, we let the arm-rtems target
get marked obsolete in 4.7 and 4.6 still is based on arm-elf.

All of the RTEMS preferred object format targets follow the
pattern CPU-rtems. Sebastian Huber has posted patches multiple
times with test results which we are happy with. These do not
touch any other target or the test suite. He updated them and
posted them again.

http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01063.html
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01064.html


All of our documentation, howto's, scripts, and users etc. have built up
the expectation that the preferred tool target is CPU-rtems. Having to
use arm-rtemseabi is an aberration from that pattern and is confusing
to our community.

We would like to get the 4.7 patch applied so arm-rtems is not obsolete.

If there are any hints of a plan to release another 4.6 version, we would
like to apply a patch to that branch to switch from arm-elf to arm-eabi
as our foundation.

As RTEMS GCC target maintainer, I can approve these changes but I would
like concurrence with the branch release managers.

Thanks.

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

patch for PR56148

[Vladimir Makarov]

The following patch fixes ppc64/ia64 bootstrap problem occurred after 
submitting patch for PR56148.  The problem might occur for x86/x86-64 
therefore I am submitting this patch for trunk too.


The patch was successfully bootstrapped on x86/x86-64, ppc64, ia64.

Committed as rev. 196223.

2013-02-22  Vladimir Makarov  

PR inline-asm/56148
* lra-constraints.c (process_alt_operands): Reload operand
conflicting with earlier clobber only if no more other conflicting
operands.

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 196081)
+++ lra-constraints.c   (working copy)
@@ -2052,7 +2052,7 @@ process_alt_operands (int only_alternati
   curr_alt_dont_inherit_ops_num = 0;
   for (nop = 0; nop < early_clobbered_regs_num; nop++)
{
- int i, j, clobbered_hard_regno;
+ int i, j, clobbered_hard_regno, first_conflict_j, last_conflict_j;
  HARD_REG_SET temp_set;
 
  i = early_clobbered_nops[nop];
@@ -2063,6 +2063,7 @@ process_alt_operands (int only_alternati
  clobbered_hard_regno = hard_regno[i];
  CLEAR_HARD_REG_SET (temp_set);
  add_to_hard_reg_set (&temp_set, biggest_mode[i], 
clobbered_hard_regno);
+ first_conflict_j = last_conflict_j = -1;
  for (j = 0; j < n_operands; j++)
if (j == i
/* We don't want process insides of match_operator and
@@ -2077,19 +2078,26 @@ process_alt_operands (int only_alternati
/* If we don't reload j-th operand, check conflicts.  */
else if ((curr_alt_win[j] || curr_alt_match_win[j])
 && uses_hard_regs_p (*curr_id->operand_loc[j], temp_set))
- break;
- if (j >= n_operands)
+ {
+   if (first_conflict_j < 0)
+ first_conflict_j = j;
+   last_conflict_j = j;
+ }
+ if (last_conflict_j < 0)
continue;
  /* If earlyclobber operand conflicts with another
 non-matching operand which is actually the same register
 as the earlyclobber operand, it is better to reload the
 another operand as an operand matching the earlyclobber
 operand can be also the same.  */
- if (operand_reg[j] != NULL_RTX && ! curr_alt_match_win[j]
- && REGNO (operand_reg[i]) == REGNO (operand_reg[j]))
+ if (first_conflict_j == last_conflict_j
+ && operand_reg[last_conflict_j]
+ != NULL_RTX && ! curr_alt_match_win[last_conflict_j]
+ && REGNO (operand_reg[i]) == REGNO (operand_reg[last_conflict_j]))
{
- curr_alt_win[j] = false;
- curr_alt_dont_inherit_ops[curr_alt_dont_inherit_ops_num++] = j;
+ curr_alt_win[last_conflict_j] = false;
+ curr_alt_dont_inherit_ops[curr_alt_dont_inherit_ops_num++]
+   = last_conflict_j;
  losers++;
  overall += LRA_LOSER_COST_FACTOR;
}

Re: [PATCH,ARM][2/n] Split subdi patterns

[Richard Earnshaw]

On 18/02/13 18:36, Greta Yorsh wrote:

Convert define_insn into define_insn_and_split for various subdi patterns
that output multiple assembly instructions.

2013-02-14  Greta Yorsh  

   * config/arm/arm.md (arm_subdi3): Convert define_insn into
   define_insn_and_split.
   (subdi_di_zesidi,subdi_di_sesidi): Likewise.
   (subdi_zesidi_di,subdi_sesidi_di,subdi_zesidi_zesidi): Likewise.


2-split-subdi.patch.txt



OK for stage 1.

R.

Re: libsanitizer merge from upstream r175042

[Jakub Jelinek]

On Fri, Feb 15, 2013 at 12:47:30PM +0400, Konstantin Serebryany wrote:
> Sure. ASAN_FIXED_MAPPING should be used for performance measurements
> only -- this is not a release option.
> (Added a more precise comment).

BTW, today I think I've discovered what looks like a prelink bug,
but perhaps we need to bump kMidMemEnd a little bit.
With prelink -R, the libraries are randomized in the selected range of 
addresses,
by picking a random number in between the boundaries of the address range and 
first
assigning addresses to libraries above that random offset and when there is no 
longer any room
above it, starting from the beginning of the range.  Unfortunately the code 
seems to have
some issues if the random address is chosen close to the end of the range, then 
in some
cases some libraries could start before the range, but end after the range.

On one of my boxes there is (only 4 libraries out of 822 have this problem,
only discovered it because gdb is linked against one of them and I've tried to
LD_PRELOAD=libasan.so.0 to gdb so that the debugged program would inherit that):

prelink -pv 2>&1 | grep 0x003.*-.*0x004
/usr/lib64/libgmlib.so.1.0.7 [0x1ea5b3cf] 0x003fffe0-0x00408460:
/usr/lib64/libiec61883.so.0.1.1 [0x56363ffc] 
0x003fffe0-0x0040c3e0:
/usr/lib64/libncurses.so.5.9 [0x120e1b8a] 0x003fffe0-0x00423860:
/usr/lib64/libsoup-2.4.so.1.5.0 [0x99ff4d51] 
0x003fffe0-0x0046a258:

while on others none.

So, can kMidMemEnd be slightly incremented above this?  Either 0x4fULL,
or 0x40ULL (or replace that 0f with 1f, 2f, etc.).
Small model shared libraries can be only up to 2GB in size, so even
0x40ULL should be big enough for most cases, but 0x4fULL
could be even safer.  I've justed tested and 0x4fULL results in
|| `[0x10007fff8000, 0x7fff]` || HighMem||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x0050, 0x02008fff6fff]` || ShadowGap3 ||
|| `[0x0030, 0x004f]` || MidMem ||
|| `[0x000a7fff8000, 0x002f]` || ShadowGap2 ||
|| `[0x00067fff8000, 0x000a7fff7fff]` || MidShadow  ||
|| `[0x8fff7000, 0x00067fff7fff]` || ShadowGap  ||
|| `[0x7fff8000, 0x8fff6fff]` || LowShadow  ||
|| `[0x, 0x7fff7fff]` || LowMem ||
MemToShadow(shadow): 0x8fff7000 0x91ff6dff 0x004091ff6e00 
0x02008fff6fff 0x00014fff7000 0x0001cfff6fff
and seems to work just fine.

Jakub

Re: [PATCH,ARM][1/n] New patterns for subtract with carry

[Richard Earnshaw]

On 18/02/13 18:35, Greta Yorsh wrote:

Add patterns to handle various subtract with carry operations.

These patterns match RTL insns emitted by splitters
for DImode operations such as subdi, negdi, and cmpdi.

gcc/

2013-02-14  Greta Yorsh  

 * config/arm/arm.md (subsi3_carryin, subsi3_carryin_const): New
patterns.
 (subsi3_carryin_compare,subsi3_carryin_compare_const): Likewise.
 (subsi3_carryin_shift,rsbsi3_carryin_shift): Likewise.




Not ok.  RSC does not exist in Thumb state.

R.


1-patterns-subtract-with-carry.patch.txt


diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 
35294dd6560ac63279d95eca6cf774257e06bd93..
 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -1019,3 +1019,86 @@ (define_insn "*addsi3_carryin_clobercc_<
 [(set_attr "conds" "set")]
  )

+(define_insn "*subsi3_carryin"
+  [(set (match_operand:SI 0 "s_register_operand" "=r,r")
+(minus:SI (minus:SI (match_operand:SI 1 "reg_or_int_operand" "r,I")
+(match_operand:SI 2 "s_register_operand" "r,r"))
+  (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+  "TARGET_32BIT"
+  "@
+   sbc%?\\t%0, %1, %2
+   rsc%?\\t%0, %2, %1"
+  [(set_attr "conds" "use")
+   (set_attr "predicable" "yes")]
+)
+
+(define_insn "*subsi3_carryin_const"
+  [(set (match_operand:SI 0 "s_register_operand" "=r")
+(minus:SI (plus:SI (match_operand:SI 1 "reg_or_int_operand" "r")
+   (match_operand:SI 2 "arm_not_operand" "K"))
+  (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+  "TARGET_32BIT"
+  "sbc\\t%0, %1, #%B2"
+  [(set_attr "conds" "use")]
+)
+
+(define_insn "*subsi3_carryin_compare"
+  [(set (reg:CC CC_REGNUM)
+(compare:CC (match_operand:SI 1 "s_register_operand" "r")
+(match_operand:SI 2 "s_register_operand" "r")))
+   (set (match_operand:SI 0 "s_register_operand" "=r")
+(minus:SI (minus:SI (match_dup 1)
+(match_dup 2))
+  (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+  "TARGET_32BIT"
+  "sbcs\\t%0, %1, %2"
+  [(set_attr "conds" "set")]
+)
+
+(define_insn "*subsi3_carryin_compare_const"
+  [(set (reg:CC CC_REGNUM)
+(compare:CC (match_operand:SI 1 "reg_or_int_operand" "r")
+(match_operand:SI 2 "arm_not_operand" "K")))
+   (set (match_operand:SI 0 "s_register_operand" "=r")
+(minus:SI (plus:SI (match_dup 1)
+   (match_dup 2))
+  (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+  "TARGET_32BIT"
+  "sbcs\\t%0, %1, #%B2"
+  [(set_attr "conds" "set")]
+)
+
+(define_insn "*subsi3_carryin_shift"
+  [(set (match_operand:SI 0 "s_register_operand" "=r")
+   (minus:SI (minus:SI
+ (match_operand:SI 1 "s_register_operand" "r")
+  (match_operator:SI 2 "shift_operator"
+   [(match_operand:SI 3 "s_register_operand" "r")
+(match_operand:SI 4 "reg_or_int_operand" "rM")]))
+ (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+  "TARGET_32BIT"
+  "sbc%?\\t%0, %1, %3%S2"
+  [(set_attr "conds" "use")
+   (set_attr "predicable" "yes")
+   (set (attr "type") (if_then_else (match_operand 4 "const_int_operand" "")
+ (const_string "alu_shift")
+ (const_string "alu_shift_reg")))]
+)
+
+(define_insn "*rsbsi3_carryin_shift"
+  [(set (match_operand:SI 0 "s_register_operand" "=r")
+   (minus:SI (minus:SI
+  (match_operator:SI 2 "shift_operator"
+   [(match_operand:SI 3 "s_register_operand" "r")
+(match_operand:SI 4 "reg_or_int_operand" "rM")])
+  (match_operand:SI 1 "s_register_operand" "r"))
+ (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+  "TARGET_32BIT"
+  "rsc%?\\t%0, %1, %3%S2"
+  [(set_attr "conds" "use")
+   (set_attr "predicable" "yes")
+   (set (attr "type") (if_then_else (match_operand 4 "const_int_operand" "")
+ (const_string "alu_shift")
+ (const_string "alu_shift_reg")))]
+)
+

Re: [PATCH] ARM RTEMS changes for GCC 4.7

[Richard Earnshaw]

On 22/02/13 15:41, Sebastian Huber wrote:

Testsuite results:

http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg02508.html

2013-02-22  Sebastian Huber 

 * config.gcc (arm*-*-rtemself*): New.
 (arm*-*-rtems*): Removed.
 (arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename
 "arm*-*-rtemseabi*" to "arm*-*-rtems*".

2013-02-22  Sebastian Huber 

 * config.host (arm*-*-rtemself*): New.
 (arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename
 "arm*-*-rtemseabi*" to "arm*-*-rtems*".


I have no objections to this if the release managers agree.

R.

Re: [PATCH] ARM RTEMS changes for GCC 4.6

[Richard Earnshaw]

I have no objections to this if the release managers agree.

R.

On 22/02/13 15:40, Sebastian Huber wrote:

2013-02-22  Sebastian Huber 

 * config.gcc (arm*-*-rtemself*): New.
 (arm*-*-rtems*): Removed.
 (arm*-*-eabi* | arm*-*-symbianelf*): Add (arm*-*-rtems*).
 * config/arm/rtems-eabi.h: New file.
 * config/arm/t-rtems-eabi: New file.
---
  gcc/config.gcc  |   16 ++--
  gcc/config/arm/rtems-eabi.h |   29 +
  gcc/config/arm/t-rtems-eabi |8 
  3 files changed, 47 insertions(+), 6 deletions(-)
  create mode 100644 gcc/config/arm/rtems-eabi.h
  create mode 100644 gcc/config/arm/t-rtems-eabi

diff --git a/gcc/config.gcc b/gcc/config.gcc
index fdbe321..35d502b 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -870,7 +870,12 @@ arm*-*-ecos-elf)
tmake_file="arm/t-arm arm/t-arm-elf"
tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
;;
-arm*-*-eabi* | arm*-*-symbianelf* )
+arm*-*-rtemself*)
+   tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h 
arm/rtems-elf.h rtems.h newlib-stdint.h"
+   tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
+   tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
+   ;;
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3.  Correctly modeling that requires the use of
# TImode.
@@ -885,6 +890,10 @@ arm*-*-eabi* | arm*-*-symbianelf* )
  tmake_file="${tmake_file} arm/t-bpabi"
  use_gcc_stdint=wrap
  ;;
+   arm*-*-rtems*)
+ tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h"
+ tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi"
+ ;;
arm*-*-symbianelf*)
  tm_file="${tm_file} arm/symbian.h"
  # We do not include t-bpabi for Symbian OS because the system
@@ -895,11 +904,6 @@ arm*-*-eabi* | arm*-*-symbianelf* )
tm_file="${tm_file} arm/aout.h arm/arm.h"
tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
;;
-arm*-*-rtems*)
-   tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h 
arm/rtems-elf.h rtems.h newlib-stdint.h"
-   tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
-   tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
-   ;;
  arm*-*-elf)
tm_file="dbxelf.h elfos.h newlib-stdint.h arm/unknown-elf.h arm/elf.h 
arm/aout.h arm/arm.h"
tmake_file="arm/t-arm arm/t-arm-elf"
diff --git a/gcc/config/arm/rtems-eabi.h b/gcc/config/arm/rtems-eabi.h
new file mode 100644
index 000..ced98a9
--- /dev/null
+++ b/gcc/config/arm/rtems-eabi.h
@@ -0,0 +1,29 @@
+/* Definitions for RTEMS based ARM systems using EABI.
+   Copyright (C) 2011 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#define HAS_INIT_SECTION
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+do {   \
+   builtin_define ("__rtems__"); \
+   builtin_define ("__USE_INIT_FINI__"); \
+   builtin_assert ("system=rtems");  \
+   TARGET_BPABI_CPP_BUILTINS();\
+} while (0)
diff --git a/gcc/config/arm/t-rtems-eabi b/gcc/config/arm/t-rtems-eabi
new file mode 100644
index 000..f0e714a
--- /dev/null
+++ b/gcc/config/arm/t-rtems-eabi
@@ -0,0 +1,8 @@
+# Custom RTEMS EABI multilibs
+
+MULTILIB_OPTIONS= mthumb march=armv6-m/march=armv7/march=armv7-m
+MULTILIB_DIRNAMES   = thumb armv6-m armv7 armv7-m
+MULTILIB_EXCEPTIONS = march=armv6-m march=armv7 march=armv7-m
+MULTILIB_MATCHES=
+MULTILIB_EXCLUSIONS =
+MULTILIB_OSDIRNAMES =

Re: PATCH: Correctly configure all big-endian ARM archs, not just arm*-*-linux-*.

[Richard Earnshaw]

On 20/02/13 23:21, Seth LaForge wrote:

On Fri, Feb 15, 2013 at 3:29 PM, Mike Stump  wrote:

No.  Counter proposal, let's handle the cases that don't work.  So, you said in 
your original email that armeb-unknown-eabi doesn't work.

So, in the existing case statement for:

arm*-*-eabi*)

let's just add:

 case ${target} in
 armeb-*-eabi*)
   tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
 esac

Is this not exactly what you want?  Doesn't this solve exactly what you stated 
was the problem?


OK, attached patch
0001-Add-TARGET_BIG_ENDIAN_DEFAULT-1-for-all-armeb-eabi-a.patch does
as you describe, and works for my particular use-case.


I could inline the test into all
of the ARM cases below, but I don't like that approach since it's what
caused this problem in the first place (somebody adding BE support to
one ARM arch without adding it to the others).


And does it work on uclinux?  Does it work on rtems?  Does it work on every arm 
that every existed and will exist?  If the answer is no, then it is less ideal 
than putting this in the config for eabi*).


Well, the current config is certainly broken when giving a big-endian
spec for uclinux, rtems, and every other arm that ever existed or will
exist.  It's possible there are other issues with using a big-endian
processor for uclinux, rtems, etc, but adding
TARGET_BIG_ENDIAN_DEFAULT=1 certainly gets those targets closer to
working.


If it always works, then moving the existing on up to the existing:

case ${target} in
i[34567]86-*-*)

would be the right approach.  x86 uses this location already to set 
tm_defines="${tm_defines} USE_IX86_FRAME_POINTER=1" for example.  The 
documentation above that group can state that this is the location for things that are 
cpu specific and os and vendor neutral.


I like that solution better.  Following your suggested list of
big-endian architectures, attached patch
0001-Add-TARGET_BIG_ENDIAN_DEFAULT-1-for-all-arm-big-endi.patch adds
TARGET_BIG_ENDIAN_DEFAULT=1 for $target matching "armeb-* | armbe-* |
armv[3-8]b-*".  I left out xscaleeb, since config.sub canonicalizes
xscaleeb-* to armeb-*.

Please, pick whichever patch pleases you most.  I prefer
0001-Add-TARGET_BIG_ENDIAN_DEFAULT-1-for-all-arm-big-endi.patch.

Changelog entry for
0001-Add-TARGET_BIG_ENDIAN_DEFAULT-1-for-all-arm-big-endi.patch:

gcc/
* config.gcc: Add TARGET_BIG_ENDIAN_DEFAULT=1 for all arm big-endian 
archs.

Changelog entry for
0001-Add-TARGET_BIG_ENDIAN_DEFAULT-1-for-all-armeb-eabi-a.patch:

gcc/
* config.gcc: Add TARGET_BIG_ENDIAN_DEFAULT=1 for all armeb-*-eabi* 
archs.



This is what I've put in.  Which is a slight relaxation on your second 
version.


R.
Index: ChangeLog
===
--- ChangeLog   (revision 196220)
+++ ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2013-02-22  Seth LaForge  
+
+   * config.gcc (arm*-*-eabi*): Treat arm*eb as big-endian.
+
 2013-02-22  Greta Yorsh  
 
 * config/arm/arm.md (split for extendsidi): Update condition.
Index: config.gcc
===
--- config.gcc  (revision 196220)
+++ config.gcc  (working copy)
@@ -900,6 +900,10 @@ arm*-*-uclinux*eabi*)  # ARM ucLinux
default_use_cxa_atexit=yes
;;
 arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
+   case ${target} in
+   arm*eb-*-eabi*)
+ tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
+   esac
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3.  Correctly modeling that requires the use of
# TImode.

Re: [AArch64] Add missing copyright and build dependency for aarch64-simd-builtins.def

[Marcus Shawcroft]

On 22/02/13 14:44, James Greenhalgh wrote:


Hi,

gcc/config/aarch64/aarch64-simd-builtins.def is missing a copyright header
and is not listed in build dependencies for aarch64-builtins.c.

This patch fixes that.

Is this OK to commit to trunk and aarch64-4.7-branch.

Thanks,
James Greenhalgh

---
gcc/

2013-02-22  James Greenhalgh  

* config/aarch64/aarch64-simd-builtins.def: Add copyright header.
* config/aarch64/t-aarch64
(aarch64-builtins.o): Depend on aarch64-simd-builtins.def.




OK

/Marcus

[PATCH] ARM RTEMS changes for GCC 4.7

[Sebastian Huber]

Testsuite results:

http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg02508.html

2013-02-22  Sebastian Huber 

* config.gcc (arm*-*-rtemself*): New.
(arm*-*-rtems*): Removed.
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename
"arm*-*-rtemseabi*" to "arm*-*-rtems*".

2013-02-22  Sebastian Huber 

* config.host (arm*-*-rtemself*): New.
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename
"arm*-*-rtemseabi*" to "arm*-*-rtems*".
---
 gcc/config.gcc |   14 +++---
 libgcc/config.host |   12 ++--
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index a188133..3ca322d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -257,7 +257,7 @@ case ${target} in
  | arm*-*-elf  \
  | arm*-*-freebsd* \
  | arm*-*-linux*   \
- | arm*-*-rtems*   \
+ | arm*-*-rtemself*\
  | arm*-*-uclinux* \
  | arm*-wince-pe*  \
  | mips-sgi-irix6.5\
@@ -899,7 +899,11 @@ arm*-*-ecos-elf)
tm_file="dbxelf.h elfos.h newlib-stdint.h arm/unknown-elf.h arm/elf.h 
arm/aout.h arm/arm.h arm/ecos-elf.h"
tmake_file="arm/t-arm arm/t-arm-elf"
;;
-arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
+arm*-*-rtemself*)
+   tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h"
+   tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
+   ;;
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3.  Correctly modeling that requires the use of
# TImode.
@@ -913,7 +917,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
  tmake_file="${tmake_file} arm/t-bpabi"
  use_gcc_stdint=wrap
  ;;
-   arm*-*-rtemseabi*)
+   arm*-*-rtems*)
  tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h"
  tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi"
  ;;
@@ -926,10 +930,6 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
esac
tm_file="${tm_file} arm/aout.h arm/arm.h"
;;
-arm*-*-rtems*)
-   tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h"
-   tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
-   ;;
 arm*-*-elf)
tm_file="dbxelf.h elfos.h newlib-stdint.h arm/unknown-elf.h arm/elf.h 
arm/aout.h arm/arm.h"
tmake_file="arm/t-arm arm/t-arm-elf"
diff --git a/libgcc/config.host b/libgcc/config.host
index 51aec66..66b4724 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -354,11 +354,15 @@ arm*-*-ecos-elf)
tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl 
arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
;;
-arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
+arm*-*-rtemself*)
+   tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl 
arm/t-softfp t-softfp"
+   extra_parts="$extra_parts crti.o crtn.o"
+   ;;
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
tmake_file="${tmake_file} arm/t-arm arm/t-elf t-fixedpoint-gnu-prefix"
tm_file="$tm_file arm/bpabi-lib.h"
case ${host} in
-   arm*-*-eabi* | arm*-*-rtemseabi*)
+   arm*-*-eabi* | arm*-*-rtems*)
  tmake_file="${tmake_file} arm/t-bpabi"
  extra_parts="crtbegin.o crtend.o crti.o crtn.o"
  ;;
@@ -371,10 +375,6 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl arm/t-softfp 
t-softfp"
unwind_header=config/arm/unwind-arm.h
;;
-arm*-*-rtems*)
-   tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl 
arm/t-softfp t-softfp"
-   extra_parts="$extra_parts crti.o crtn.o"
-   ;;
 arm*-*-elf)
tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl 
arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
-- 
1.6.4.2

[PATCH] ARM RTEMS changes for GCC 4.6

[Sebastian Huber]

2013-02-22  Sebastian Huber 

* config.gcc (arm*-*-rtemself*): New.
(arm*-*-rtems*): Removed.
(arm*-*-eabi* | arm*-*-symbianelf*): Add (arm*-*-rtems*).
* config/arm/rtems-eabi.h: New file.
* config/arm/t-rtems-eabi: New file.
---
 gcc/config.gcc  |   16 ++--
 gcc/config/arm/rtems-eabi.h |   29 +
 gcc/config/arm/t-rtems-eabi |8 
 3 files changed, 47 insertions(+), 6 deletions(-)
 create mode 100644 gcc/config/arm/rtems-eabi.h
 create mode 100644 gcc/config/arm/t-rtems-eabi

diff --git a/gcc/config.gcc b/gcc/config.gcc
index fdbe321..35d502b 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -870,7 +870,12 @@ arm*-*-ecos-elf)
tmake_file="arm/t-arm arm/t-arm-elf"
tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
;;
-arm*-*-eabi* | arm*-*-symbianelf* )
+arm*-*-rtemself*)
+   tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h"
+   tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
+   tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
+   ;;
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3.  Correctly modeling that requires the use of
# TImode.
@@ -885,6 +890,10 @@ arm*-*-eabi* | arm*-*-symbianelf* )
  tmake_file="${tmake_file} arm/t-bpabi"
  use_gcc_stdint=wrap
  ;;
+   arm*-*-rtems*)
+ tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h"
+ tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi"
+ ;;
arm*-*-symbianelf*)
  tm_file="${tm_file} arm/symbian.h"
  # We do not include t-bpabi for Symbian OS because the system
@@ -895,11 +904,6 @@ arm*-*-eabi* | arm*-*-symbianelf* )
tm_file="${tm_file} arm/aout.h arm/arm.h"
tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
;;
-arm*-*-rtems*)
-   tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h"
-   tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
-   tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
-   ;;
 arm*-*-elf)
tm_file="dbxelf.h elfos.h newlib-stdint.h arm/unknown-elf.h arm/elf.h 
arm/aout.h arm/arm.h"
tmake_file="arm/t-arm arm/t-arm-elf"
diff --git a/gcc/config/arm/rtems-eabi.h b/gcc/config/arm/rtems-eabi.h
new file mode 100644
index 000..ced98a9
--- /dev/null
+++ b/gcc/config/arm/rtems-eabi.h
@@ -0,0 +1,29 @@
+/* Definitions for RTEMS based ARM systems using EABI.
+   Copyright (C) 2011 Free Software Foundation, Inc.
+ 
+   This file is part of GCC.
+ 
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+ 
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+ 
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#define HAS_INIT_SECTION
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+do {   \
+   builtin_define ("__rtems__");   \
+   builtin_define ("__USE_INIT_FINI__");   \
+   builtin_assert ("system=rtems");\
+   TARGET_BPABI_CPP_BUILTINS();\
+} while (0)
diff --git a/gcc/config/arm/t-rtems-eabi b/gcc/config/arm/t-rtems-eabi
new file mode 100644
index 000..f0e714a
--- /dev/null
+++ b/gcc/config/arm/t-rtems-eabi
@@ -0,0 +1,8 @@
+# Custom RTEMS EABI multilibs
+
+MULTILIB_OPTIONS= mthumb march=armv6-m/march=armv7/march=armv7-m
+MULTILIB_DIRNAMES   = thumb armv6-m armv7 armv7-m
+MULTILIB_EXCEPTIONS = march=armv6-m march=armv7 march=armv7-m
+MULTILIB_MATCHES=
+MULTILIB_EXCLUSIONS =
+MULTILIB_OSDIRNAMES =
-- 
1.6.4.2

Re: r196201 - in /trunk: gcc/ChangeLog gcc/config/i...

[Jakub Jelinek]

On Fri, Feb 22, 2013 at 05:56:34PM +0400, Konstantin Serebryany wrote:
> Is there a use case where __attribute__((constructor)) in asan_rtl.cc
> will improve our chances to run early?

I was thinking about something like:
cat > libab.C <<\EOF
static int a[10], b;
extern "C" void bar (void) __attribute__((noinline, noclone));

extern "C" void
bar (void)
{
  asm volatile ("" : : : "memory");
  a[b]++;
  asm volatile ("" : : : "memory");
  __builtin_printf ("libab bar\n");
}

static struct B
{
  B ();
} c;

B::B ()
{
  asm volatile ("" : : : "memory");
  a[b]++;
  asm volatile ("" : : : "memory");
  __builtin_printf ("B::B ()\n");
  bar ();
}
EOF
cat > libaa.C <<\EOF
static int a[10], b;
extern "C" void bar (void) __attribute__((noinline, noclone));

extern "C" void
bar (void)
{
  asm volatile ("" : : : "memory");
  a[b]++;
  asm volatile ("" : : : "memory");
  __builtin_printf ("libaa bar\n");
}

static struct A
{
  A ();
} c;

A::A ()
{
  asm volatile ("" : : : "memory");
  a[b]++;
  asm volatile ("" : : : "memory");
  __builtin_printf ("A::A ()\n");
  bar ();
}
EOF
cat > a.c <<\EOF
int a[10];

int
main ()
{
  int i = 11;
  asm volatile ("" : "+r" (i));
  a[i] = 1;
  return 0;
}
EOF
g++ -shared -fpic -o libab.so libab.C
g++ -shared -fsanitize=address -fpic -o libaa.so libaa.C ./libab.so
gcc -g -o a a.c -B ./ -Wl,-rpath-link,.,-rpath,. -laa
./a

With the constructor attribute, you can at least fix this by
LD_PRELOAD=libasan.so.0 ./a

Without it it will just crash.

So it serves at least as a workaround for the cases where you don't want or
can't for some reason instrument the executable, and e.g. libc, libpthread
otherwise are found earlier in the search scope (then generally libasan
doesn't really work) or some constructor of a non-instrumented library calls
into a symbol earlier in the search scope in a library which has been
instrumented.

Also note that this isn't a libasan.a vs. libasan.so debate, but rather
a debate about whether we can only support instrumented binaries, or also
(with some limitations) just instrumented shared libraries and
non-instrumented binaries.

Jakub

Re: [Patch, fortran] [0/5] PR54730 ICE: confused by type-like fonctions

[Tobias Burnus]

Mikael Morin wrote:

Hello, this is a fix for cases like:

program main
   implicit none
   intrinsic :: real
   print *,(/ real(a = 1) /)
end

where `real(a = 1)' is initially parsed as a typespec, creating
a symbol for 'a' along the way.  The match fails, and then it is parsed
as a constructor element and accepted that way.  However, accepting the
statement implies accepting all the symbols created so far including 'a',
which is wrong and leads to the ICE.
[...]
This makes backporting a bit more difficult unfortunately; I will submit the 
(yet nonexisting) backport
patches separately.


I know that this PR is a 4.6/4.7/4.8 regression and that it presumably 
comes from a real-world code; still, given that one can relatively 
simple work around the issue and that the patch is not tiny (though not 
very complicated either), I wonder whether one should only fix it on the 
4.8 trunk.



Bootstrap-asan'ed and regression tested on x86_64-unknown-linux-gnu.
OK for trunk?


It looks mostly okay.

However, I somehow do not like some of names of the new 
procedures/global vars. I find the new "single_undo_checkpoint_p" clear, 
but, without the context of this patch, I presumably had no idea what a 
"checkpoint" means when reading gfortran.h:


+void gfc_new_checkpoint (gfc_change_set &);
+void gfc_drop_last_checkpoint (void);
+void gfc_restore_last_checkpoint (void);

Similarly:

+static gfc_change_set change_set_var = { vNULL, vNULL, NULL };
+static gfc_change_set *changes = &change_set_var;

"changes" is a bit too vague for me (though it is not bad) – and 
"change_set_var" doesn't make it clear enough that it is simply a 
variable, which matches the empty default status.


BTW: Can you also change "static  = {vNULL ...};" into "static const 
 = {vNULL ...};" to make sure the value is not accidentally changed?



Regarding the naming, can you use a bit more speaking names? For 
instance – without claiming that the naming choice is best: 
"undo_changes" instead of "changes", "emtpy_undo_change_set_var" instead 
of "change_set_var", "gfc_new_undo_checkpoint" instead of 
"gfc_new_checkpoint". It can be also something different, but it should 
imply what they a good for.



To sum up: The patch is okay with the "const" added. I'd prefer some 
"speaking names", but if you cannot come up with one, the patch is also 
acceptable as is.


Tobias

[PATCH] Fix remainder of PR bootstrap/56258 on gcc-4_6-branch

[Jack Howarth]

   Current gcc-4_6-branch still fails to bootstrap when texinfo 5.0 is 
installed.
The attached patch fixes the remaining instances where @itemx need to be 
replaced
with @item. An additional instance of misplaced brackets was fixed to match 
current
gcc-4_7-branch. Bootstrap tested on x86_64-apple-darwin11. Okay for 
gcc-4_6-branch?
  Jack
gcc/

2013-02-22  Jack Howarth  

PR bootstrap/56258
* doc/generic.texi (POINTER_PLUS_EXPR): Use @item instead of @itemx.
(PLUS_EXPR): Likewise.
* doc/cppopts.texi (--help): Likewise.
* doc/invoke.texi (-fenable-@var{kind}-@var{pass}): Likewise
(-fdump-rtl-cprop_hardreg): Likewise.
(-fdump-rtl-csa): Likewise.
(-fdump-rtl-dce): Likewise.
(-fdump-rtl-dbr): Likewise.
(-fdump-rtl-into_cfglayout): Likewise.
(-fdump-rtl-outof_cfglayout): Likewise.
(@gccoptlist): Move misplaced bracket.

Index: gcc/doc/generic.texi
===
--- gcc/doc/generic.texi(revision 196218)
+++ gcc/doc/generic.texi(working copy)
@@ -1415,13 +1415,13 @@ generate these expressions anyhow, if it
 not matter.  The type of the operands and that of the result are
 always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
 
-@itemx POINTER_PLUS_EXPR
+@item POINTER_PLUS_EXPR
 This node represents pointer arithmetic.  The first operand is always
 a pointer/reference type.  The second operand is always an unsigned
 integer type compatible with sizetype.  This is the only binary
 arithmetic operand that can operate on pointer types.
 
-@itemx PLUS_EXPR
+@item PLUS_EXPR
 @itemx MINUS_EXPR
 @itemx MULT_EXPR
 These nodes represent various binary arithmetic operations.
Index: gcc/doc/cppopts.texi
===
--- gcc/doc/cppopts.texi(revision 196218)
+++ gcc/doc/cppopts.texi(working copy)
@@ -769,7 +769,7 @@ Replacement:  []@{@}
 Enable special code to work around file systems which only permit very
 short file names, such as MS-DOS@.
 
-@itemx --help
+@item --help
 @itemx --target-help
 @opindex help
 @opindex target-help
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 196218)
+++ gcc/doc/invoke.texi (working copy)
@@ -165,7 +165,7 @@ in the following sections.
 -pipe  -pass-exit-codes  @gol
 -x @var{language}  -v  -###  --help@r{[}=@var{class}@r{[},@dots{}@r{]]}  
--target-help  @gol
 --version -wrapper @@@var{file} -fplugin=@var{file} 
-fplugin-arg-@var{name}=@var{arg}  @gol
--fdump-ada-spec@r{[}-slim@r{]}} -fdump-go-spec=@var{file}
+-fdump-ada-spec@r{[}-slim@r{]} -fdump-go-spec=@var{file}}
 
 @item C Language Options
 @xref{C Dialect Options,,Options Controlling C Dialect}.
@@ -5086,11 +5086,11 @@ Dump after duplicating the computed goto
 @option{-fdump-rtl-ce3} enable dumping after the three
 if conversion passes.
 
-@itemx -fdump-rtl-cprop_hardreg
+@item -fdump-rtl-cprop_hardreg
 @opindex fdump-rtl-cprop_hardreg
 Dump after hard register copy propagation.
 
-@itemx -fdump-rtl-csa
+@item -fdump-rtl-csa
 @opindex fdump-rtl-csa
 Dump after combining stack adjustments.
 
@@ -5101,11 +5101,11 @@ Dump after combining stack adjustments.
 @option{-fdump-rtl-cse1} and @option{-fdump-rtl-cse2} enable dumping after
 the two common sub-expression elimination passes.
 
-@itemx -fdump-rtl-dce
+@item -fdump-rtl-dce
 @opindex fdump-rtl-dce
 Dump after the standalone dead code elimination passes.
 
-@itemx -fdump-rtl-dbr
+@item -fdump-rtl-dbr
 @opindex fdump-rtl-dbr
 Dump after delayed branch scheduling.
 
@@ -5150,7 +5150,7 @@ Dump after the initialization of the reg
 @opindex fdump-rtl-initvals
 Dump after the computation of the initial value sets.
 
-@itemx -fdump-rtl-into_cfglayout
+@item -fdump-rtl-into_cfglayout
 @opindex fdump-rtl-into_cfglayout
 Dump after converting to cfglayout mode.
 
@@ -5180,7 +5180,7 @@ Dump after removing redundant mode switc
 @opindex fdump-rtl-rnreg
 Dump after register renumbering.
 
-@itemx -fdump-rtl-outof_cfglayout
+@item -fdump-rtl-outof_cfglayout
 @opindex fdump-rtl-outof_cfglayout
 Dump after converting from cfglayout mode.
 

[PATCH] Fix remainder of PR bootstrap/56258 on gcc-4_7-branch

[Jack Howarth]

   Current gcc-4_7-branch still fails to bootstrap when texinfo 5.0 is 
installed.
The attached patch fixes the remaining instances where @itemx need to be 
replaced
with @item. Bootstrap tested on x86_64-apple-darwin12. Okay for gcc-4_7-branch?
  Jack
gcc/

2013-02-22  Jack Howarth  

PR bootstrap/56258
* doc/generic.texi (POINTER_PLUS_EXPR): Use @item instead of @itemx.
(PLUS_EXPR): Likewise.
* doc/cppopts.texi (--help): Likewise.
* doc/invoke.texi (-fenable-@var{kind}-@var{pass}): Likewise.
(-fdump-rtl-cprop_hardreg): Likewise.
(-fdump-rtl-csa): Likewise.
(-fdump-rtl-dce): Likewise.
(-fdump-rtl-dbr): Likewise.
(-fdump-rtl-into_cfglayout): Likewise.
(-fdump-rtl-outof_cfglayout): Likewise.

Index: gcc/doc/generic.texi
===
--- gcc/doc/generic.texi(revision 196215)
+++ gcc/doc/generic.texi(working copy)
@@ -1415,13 +1415,13 @@ generate these expressions anyhow, if it
 not matter.  The type of the operands and that of the result are
 always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
 
-@itemx POINTER_PLUS_EXPR
+@item POINTER_PLUS_EXPR
 This node represents pointer arithmetic.  The first operand is always
 a pointer/reference type.  The second operand is always an unsigned
 integer type compatible with sizetype.  This is the only binary
 arithmetic operand that can operate on pointer types.
 
-@itemx PLUS_EXPR
+@item PLUS_EXPR
 @itemx MINUS_EXPR
 @itemx MULT_EXPR
 These nodes represent various binary arithmetic operations.
Index: gcc/doc/cppopts.texi
===
--- gcc/doc/cppopts.texi(revision 196215)
+++ gcc/doc/cppopts.texi(working copy)
@@ -803,7 +803,7 @@ Replacement:  []@{@}
 Enable special code to work around file systems which only permit very
 short file names, such as MS-DOS@.
 
-@itemx --help
+@item --help
 @itemx --target-help
 @opindex help
 @opindex target-help
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 196215)
+++ gcc/doc/invoke.texi (working copy)
@@ -5179,7 +5179,7 @@ thus dbg_cnt() returns true always unles
 e.g. With -fdbg-cnt=dce:10,tail_call:0
 dbg_cnt(dce) will return true only for first 10 invocations
 
-@itemx -fenable-@var{kind}-@var{pass}
+@item -fenable-@var{kind}-@var{pass}
 @itemx -fdisable-@var{kind}-@var{pass}=@var{range-list}
 @opindex fdisable-
 @opindex fenable-
@@ -5327,11 +5327,11 @@ Dump after duplicating the computed goto
 @option{-fdump-rtl-ce3} enable dumping after the three
 if conversion passes.
 
-@itemx -fdump-rtl-cprop_hardreg
+@item -fdump-rtl-cprop_hardreg
 @opindex fdump-rtl-cprop_hardreg
 Dump after hard register copy propagation.
 
-@itemx -fdump-rtl-csa
+@item -fdump-rtl-csa
 @opindex fdump-rtl-csa
 Dump after combining stack adjustments.
 
@@ -5342,11 +5342,11 @@ Dump after combining stack adjustments.
 @option{-fdump-rtl-cse1} and @option{-fdump-rtl-cse2} enable dumping after
 the two common sub-expression elimination passes.
 
-@itemx -fdump-rtl-dce
+@item -fdump-rtl-dce
 @opindex fdump-rtl-dce
 Dump after the standalone dead code elimination passes.
 
-@itemx -fdump-rtl-dbr
+@item -fdump-rtl-dbr
 @opindex fdump-rtl-dbr
 Dump after delayed branch scheduling.
 
@@ -5391,7 +5391,7 @@ Dump after the initialization of the reg
 @opindex fdump-rtl-initvals
 Dump after the computation of the initial value sets.
 
-@itemx -fdump-rtl-into_cfglayout
+@item -fdump-rtl-into_cfglayout
 @opindex fdump-rtl-into_cfglayout
 Dump after converting to cfglayout mode.
 
@@ -5421,7 +5421,7 @@ Dump after removing redundant mode switc
 @opindex fdump-rtl-rnreg
 Dump after register renumbering.
 
-@itemx -fdump-rtl-outof_cfglayout
+@item -fdump-rtl-outof_cfglayout
 @opindex fdump-rtl-outof_cfglayout
 Dump after converting from cfglayout mode.
 

[PR 56419/c++]: C++ front end silently drops transactions

[Aldy Hernandez]

In the following snippet, the C++ front-end drops the transaction 
altogether:


+int x = 0;
+int inc_func(int i) {
+ for (int j = 0; j < i; ++j)
+ {
+ __transaction_atomic { x+=1; }
+ }
+ return 0;

This was caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186546

The problem here is that genericize_cp_loop() calls 
append_to_statement_list() to add the TRANSACTION_EXPR, but in this 
case, TREE_SIDE_EFFECTS is not set, so it is silently ignored.


Frankly, I don't understand finish_transaction_stmt(), and why it sets 
TREE_SIDE_EFFECTS only if the [noexcept] clause is set.  I'm C++ 
ignorant, but I would've thought the opposite to be true.


Anyways, I've fixed the problem by setting TREE_SIDE_EFFECTS if the 
transaction body has side effects.  Perhaps we should do this for 
build_transaction_expr() as well?


What do y'all prefer?
commit 01704e6a117846458dbc11cb76284504673f2d3c
Author: Aldy Hernandez 
Date:   Fri Feb 22 08:28:14 2013 -0600

PR c++/56419
* semantics.c (finish_transaction_stmt): Set TREE_SIDE_EFFECTS if
the body has side effects.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 458ed26..c446cd6 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5135,6 +5135,9 @@ finish_transaction_stmt (tree stmt, tree compound_stmt, 
int flags, tree noex)
   TRANSACTION_EXPR_BODY (stmt) = body;
 }
 
+  if (TREE_SIDE_EFFECTS (TRANSACTION_EXPR_BODY (stmt)))
+TREE_SIDE_EFFECTS (stmt) = 1;
+
   if (compound_stmt)
 finish_compound_stmt (compound_stmt);
   finish_stmt ();
diff --git a/gcc/testsuite/g++.dg/tm/pr56419.C 
b/gcc/testsuite/g++.dg/tm/pr56419.C
new file mode 100644
index 000..c9a33a8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tm/pr56419.C
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "-fgnu-tm" }
+
+int x = 0;
+int inc_func(int i) {
+ for (int j = 0; j < i; ++j)
+ {
+ __transaction_atomic { x+=1; }
+ }
+ return 0;
+}
+
+// { dg-final { scan-assembler "ITM_commitTransaction" } }

[AArch64] Add missing copyright and build dependency for aarch64-simd-builtins.def

[James Greenhalgh]

Hi,

gcc/config/aarch64/aarch64-simd-builtins.def is missing a copyright header
and is not listed in build dependencies for aarch64-builtins.c.

This patch fixes that.

Is this OK to commit to trunk and aarch64-4.7-branch.

Thanks,
James Greenhalgh

---
gcc/

2013-02-22  James Greenhalgh  

* config/aarch64/aarch64-simd-builtins.def: Add copyright header.
* config/aarch64/t-aarch64
(aarch64-builtins.o): Depend on aarch64-simd-builtins.def.
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def b/gcc/config/aarch64/aarch64-simd-builtins.def
index 40d8d93..b940ec8 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -1,3 +1,22 @@
+/* Machine description for AArch64 architecture.
+   Copyright (C) 2012-2013 Free Software Foundation, Inc.
+   Contributed by ARM Ltd.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
 
 /* In the list below, the BUILTIN_ macros should
correspond to the iterator used to construct the instruction's
diff --git a/gcc/config/aarch64/t-aarch64 b/gcc/config/aarch64/t-aarch64
index ece7e47..61adc29 100644
--- a/gcc/config/aarch64/t-aarch64
+++ b/gcc/config/aarch64/t-aarch64
@@ -27,6 +27,7 @@ $(srcdir)/config/aarch64/aarch64-tune.md: $(srcdir)/config/aarch64/gentune.sh \
 aarch64-builtins.o: $(srcdir)/config/aarch64/aarch64-builtins.c $(CONFIG_H) \
   $(SYSTEM_H) coretypes.h $(TM_H) \
   $(RTL_H) $(TREE_H) expr.h $(TM_P_H) $(RECOG_H) langhooks.h \
-  $(DIAGNOSTIC_CORE_H) $(OPTABS_H)
+  $(DIAGNOSTIC_CORE_H) $(OPTABS_H) \
+  $(srcdir)/config/aarch64/aarch64-simd-builtins.def
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
 		$(srcdir)/config/aarch64/aarch64-builtins.c

Re: Fix PR 56077

[Jeff Law]

On 02/22/13 07:16, Alexander Monakov wrote:



You must be referring to the PR audit trail, right?  I'm sure the bug reporter
is mistaken that the stores are coalesced.  What happens is that two of the
three stores are moved up above the first asm, but because of how the awk
script cuts the generated code, that is not observed.

Thanks.  That makes a lot more sense.



Also, if we go forward with your patch, the comment related to this
conditional needs to be fixed -- it still says "Flush pending lists on jumps,
...", but you've removed the jump check.


Yeah, I'd say the comment is confusing both before and after the patch.
Perhaps something like "Don't flush pending lists on speculation checks during
selective scheduling" would be better.

Sounds good.  Approved with that comment change.

Thanks,
jeff

Re: Fix PR 56077

[Alexander Monakov]

On Fri, 22 Feb 2013, Jeff Law wrote:

> On 02/22/13 06:30, Andrey Belevantsev wrote:
> > Hello,
> >
> > As found by Jakub and explained in the PR audit trail by Alexander, this
> > patch fixes the selective scheduler merge glitch of 2008 that added the
> > unnecessary JUMP_P check to the flush_pending_lists call.  I have
> > removed the check and expanded the binary negation for clarity.

> Can you explain how avoiding pushing the pending lists in this situation
> avoids coalescing the volatile stores?

You must be referring to the PR audit trail, right?  I'm sure the bug reporter
is mistaken that the stores are coalesced.  What happens is that two of the
three stores are moved up above the first asm, but because of how the awk
script cuts the generated code, that is not observed.

> Also, if we go forward with your patch, the comment related to this
> conditional needs to be fixed -- it still says "Flush pending lists on jumps,
> ...", but you've removed the jump check.

Yeah, I'd say the comment is confusing both before and after the patch.
Perhaps something like "Don't flush pending lists on speculation checks during
selective scheduling" would be better.

Alexander

Re: [PATCH,ARM] Improve extendsidi without neon

[Richard Earnshaw]

On 22/02/13 13:54, Greta Yorsh wrote:

This patch improves code generated for extension from SI to DI mode for core
registers when neon is not enabled.

Currently, if neon is enabled, extendsidi for core registers benefits from
the patch described here (r194558 from 17 Dec 2012):
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00984.html

Before r194558, the compiler used to split extendsidi before register
allocation (at split1 pass), which resulted in some cases in an extra
register being used and an extra register move. After r194558, if neon is
enabled, extendsidi is split after reload, generating better code.
Unfortunately, when neon is not enabled, the splitter is still triggered
before reload.

For example,

$ cat negdi-1.c

signed long long extendsidi_negsi (signed int x)
{
   return -x;
}

$ arm-none-eabi-gcc negdi-1.c -S -O2 -o- -mfpu=vfpv4

extendsidi_negsi:
 rsb r3, r0, #0  @ 6 *arm_negsi2 [length = 4]
 mov r0, r3  @ 19*arm_movsi_vfp/1[length = 4]
 mov r1, r3, asr #31 @ 20*arm_shiftsi3   [length = 4]
 bx  lr  @ 25*arm_return [length = 12]

$ arm-none-eabi-gcc negdi-1.c -S -O2 -o- -mfpu=neon

extendsidi_negsi:
 rsb r0, r0, #0  @ 6 *arm_negsi2 [length = 4]
 mov r1, r0, asr #31 @ 20*arm_shiftsi3   [length = 4]
 bx  lr  @ 23*arm_return [length = 12]

This patch changes the condition of splitters for extendsidi to trigger only
after reload.

In addition, this patch fixes a bug in zero_extenddi2 and
extenddi2 patterns. One of the alternatives in these patterns has a
constraint 'w' which is not valid when neon is disabled, but the patterns
don't have attributes to guard these alternatives by neon availability. This
might cause an ICE when neon is not available. Currently, it seems that the
patterns are only matched by RTL insns that are generated by splitters with
conditions on neon being enabled. However, it may be a latent bug. In any
case, the change in conditions of these splitters made by this patch
triggers the bug and causes an ICE.

No regression on qemu for arm-none-eabi cortex-a15 arm/thumb neon/vfpv4
softfp/soft.

Bootstrap successful on Cortex-A15.

I haven't added a test case because tests that scan assembly for 'mov' are
very unstable.

Ok for trunk?
Thanks,
Greta

gcc/

2013-02-21  Greta Yorsh  

 * config/arm/arm.md (split for extendsidi): Update condition.
 (zero_extenddi2,extenddi2): Add an alternative.
 * config/arm/iterators.md (qhs_extenddi_cstr): Likewise.
 (qhs_zextenddi_cstr): Likewise.




OK.

R.

Re: r196201 - in /trunk: gcc/ChangeLog gcc/config/i...

[Konstantin Serebryany]

On Fri, Feb 22, 2013 at 4:58 PM, Jakub Jelinek  wrote:
> On Fri, Feb 22, 2013 at 11:53:39AM +0400, Konstantin Serebryany wrote:
>> Jakub, thanks again for cleaning up my mess.
>>
>> Here is a question regarding your fix:
>> > -#if ASAN_USE_PREINIT_ARRAY
>> > +#if ASAN_USE_PREINIT_ARRAY && !defined (PIC)
>>
>> The PIC macro is an artifact of the GCC build system and is not
>> directly related the the -fPIC flag?
>> As I can see, in the gcc build we compile all of asan sources twice:
>> w/ and w/o "-fPIC -DPIC".
>> If I move the preinit_array to a separate file (asan_preinit.cc), will
>> we need to have two builds?
>> I think we can just build all objects once with -fPIC and then not
>> link asan_preinit.o into libasan.so
>> In clang we build the static libasan with -fPIC, it doesn't hurt.
>> Anyway, I've just committed
>> http://llvm.org/viewvc/llvm-project?rev=175871&view=rev with
>> asan_preinit.cc
>
> Here is corresponding gcc patch to use it.
> libasan_preinit.o is installed alongside with libasan.a and libasan.so*,
> and linked into executables (but not shared libraries).
>
> Additionally, I've added __attribute__((constructor)) to __asan_init,
> to make it more likely that asan will be initialized properly even when
> the executable isn't instrumented.  Shared libraries linked with
> -fsanitize=address will depend on libasan.so.0, and the dynamic linker first
> runs constructors of dependencies before running constructors of the
> libraries that have those dependencies (unless there are dependency cycles, 
> but that
> is a user bug).

Is there a use case where __attribute__((constructor)) in asan_rtl.cc
will improve our chances to run early?
the compiler module already inserts the call to __asan_init into a
constructor of every module it instruments.

Feel free to commit the rest, thanks!

--kcc


>
> 2013-02-22  Jakub Jelinek  
>
> PR sanitizer/56393
> * config/gnu-user.h (LIBASAN_EARLY_SPEC): Link in libasan_preinit.o
> if not linking a shared library.
>
> * lib/asan-dg.exp (asan_link_flags): Add
> -B${gccpath}/libsanitizer/asan/ to flags.
>
> * asan/Makefile.am (nodist_toolexeclib_HEADERS): Set to
> libasan_preinit.o.
> (libasan_preinit.o): Depend on asan_preinit.o.
> * asan/Makefile.in: Regenerated.
> * asan/asan_preinit.cc: New file, synced from upstream.
> * asan/asan_rtl.cc: Remove preinit stuff, synced from upstream.
> Add __attribute__((constructor)) to __asan_init.
>
> --- gcc/config/gnu-user.h.jj2013-02-05 16:55:01.0 +0100
> +++ gcc/config/gnu-user.h   2013-02-22 13:02:11.0 +0100
> @@ -104,11 +104,13 @@ see the files COPYING3 and COPYING.RUNTI
> it to force everything into the executable.  And similarly for -ltsan.  */
>  #if defined(HAVE_LD_STATIC_DYNAMIC)
>  #undef LIBASAN_EARLY_SPEC
> -#define LIBASAN_EARLY_SPEC "%{static-libasan:%{!shared:" \
> +#define LIBASAN_EARLY_SPEC "%{!shared:libasan_preinit%O%s} " \
> +  "%{static-libasan:%{!shared:" \
>LD_STATIC_OPTION " --whole-archive -lasan --no-whole-archive " \
>LD_DYNAMIC_OPTION "}}%{!static-libasan:-lasan}"
>  #undef LIBTSAN_EARLY_SPEC
> -#define LIBTSAN_EARLY_SPEC "%{static-libtsan:%{!shared:" \
> +#define LIBTSAN_EARLY_SPEC "%{!shared:libasan_preinit%O%s} " \
> +  "%{static-libtsan:%{!shared:" \
>LD_STATIC_OPTION " --whole-archive -ltsan --no-whole-archive " \
>LD_DYNAMIC_OPTION "}}%{!static-libtsan:-ltsan}"
>  #endif
> --- gcc/testsuite/lib/asan-dg.exp.jj2013-01-11 09:02:39.0 +0100
> +++ gcc/testsuite/lib/asan-dg.exp   2013-02-22 13:06:59.437483035 +0100
> @@ -41,6 +41,7 @@ proc asan_link_flags { paths } {
>  if { $gccpath != "" } {
>if { [file exists "${gccpath}/libsanitizer/asan/.libs/libasan.a"]
>|| [file exists 
> "${gccpath}/libsanitizer/asan/.libs/libasan.${shlib_ext}"] } {
> + append flags " -B${gccpath}/libsanitizer/asan/ "
>   append flags " -L${gccpath}/libsanitizer/asan/.libs "
>   append ld_library_path ":${gccpath}/libsanitizer/asan/.libs"
>}
> --- libsanitizer/asan/Makefile.am.jj2013-02-21 20:10:41.0 +0100
> +++ libsanitizer/asan/Makefile.am   2013-02-22 12:36:30.746317422 +0100
> @@ -12,6 +12,7 @@ AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFL
>  ACLOCAL_AMFLAGS = -I $(top_srcdir) -I $(top_srcdir)/config
>
>  toolexeclib_LTLIBRARIES = libasan.la
> +nodist_toolexeclib_HEADERS = libasan_preinit.o
>
>  asan_files = \
> asan_allocator.cc \
> @@ -45,6 +46,9 @@ libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX
>
>  libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` 
> -lpthread -ldl
>
> +libasan_preinit.o: asan_preinit.o
> +   cp $< $@
> +
>  # Work around what appears to be a GNU make bug handling MAKEFLAGS
>  # values defined in terms of make variables, as is the case for CC and
>  # friends when we are called from the top level Makefile.
> --- libsanitizer/asan/asan_preinit.c

Re: Fix PR 56077

[Jeff Law]

On 02/22/13 06:30, Andrey Belevantsev wrote:

Hello,

As found by Jakub and explained in the PR audit trail by Alexander, this
patch fixes the selective scheduler merge glitch of 2008 that added the
unnecessary JUMP_P check to the flush_pending_lists call.  I have
removed the check and expanded the binary negation for clarity.

The patch was tested on x86-64, ia64, and ppc64 to be safe.  The patch
should be conservatively safe at this stage as it adds more flushes and
thus more dependencies to the scheduler.  The original test is fixed,
but I don't know how to add the test checking assembly insns order to
the testsuite.

OK for trunk?

Andrey

2012-02-22  Alexander Monakov  
 Andrey Belevantsev  

 PR middle-end/56077
 * sched-deps.c (sched_analyze_insn): When reg_pending_barrier,
 flush pending lists also on non-jumps.
Can you explain how avoiding pushing the pending lists in this situation 
avoids coalescing the volatile stores?


Also, if we go forward with your patch, the comment related to this 
conditional needs to be fixed -- it still says "Flush pending lists on 
jumps, ...", but you've removed the jump check.


Jeff

[PATCH,ARM] Improve extendsidi without neon

[Greta Yorsh]

This patch improves code generated for extension from SI to DI mode for core
registers when neon is not enabled.

Currently, if neon is enabled, extendsidi for core registers benefits from
the patch described here (r194558 from 17 Dec 2012):
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00984.html

Before r194558, the compiler used to split extendsidi before register
allocation (at split1 pass), which resulted in some cases in an extra
register being used and an extra register move. After r194558, if neon is
enabled, extendsidi is split after reload, generating better code.
Unfortunately, when neon is not enabled, the splitter is still triggered
before reload.

For example, 

$ cat negdi-1.c

signed long long extendsidi_negsi (signed int x)
{
  return -x;
}

$ arm-none-eabi-gcc negdi-1.c -S -O2 -o- -mfpu=vfpv4

extendsidi_negsi:
rsb r3, r0, #0  @ 6 *arm_negsi2 [length = 4]
mov r0, r3  @ 19*arm_movsi_vfp/1[length = 4]
mov r1, r3, asr #31 @ 20*arm_shiftsi3   [length = 4]
bx  lr  @ 25*arm_return [length = 12]

$ arm-none-eabi-gcc negdi-1.c -S -O2 -o- -mfpu=neon

extendsidi_negsi:
rsb r0, r0, #0  @ 6 *arm_negsi2 [length = 4]
mov r1, r0, asr #31 @ 20*arm_shiftsi3   [length = 4]
bx  lr  @ 23*arm_return [length = 12]

This patch changes the condition of splitters for extendsidi to trigger only
after reload.

In addition, this patch fixes a bug in zero_extenddi2 and
extenddi2 patterns. One of the alternatives in these patterns has a
constraint 'w' which is not valid when neon is disabled, but the patterns
don't have attributes to guard these alternatives by neon availability. This
might cause an ICE when neon is not available. Currently, it seems that the
patterns are only matched by RTL insns that are generated by splitters with
conditions on neon being enabled. However, it may be a latent bug. In any
case, the change in conditions of these splitters made by this patch
triggers the bug and causes an ICE. 

No regression on qemu for arm-none-eabi cortex-a15 arm/thumb neon/vfpv4
softfp/soft.

Bootstrap successful on Cortex-A15.

I haven't added a test case because tests that scan assembly for 'mov' are
very unstable.

Ok for trunk?
Thanks,
Greta

gcc/

2013-02-21  Greta Yorsh  

* config/arm/arm.md (split for extendsidi): Update condition.
(zero_extenddi2,extenddi2): Add an alternative.
* config/arm/iterators.md (qhs_extenddi_cstr): Likewise.
(qhs_zextenddi_cstr): Likewise.diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 
1cb1515b1fa57c6052b68eb8701616c1b80e7416..
 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -4491,36 +4491,35 @@ (define_expand "truncdfhf2"
 ;; Zero and sign extension instructions.
 
 (define_insn "zero_extenddi2"
-  [(set (match_operand:DI 0 "s_register_operand" "=w,r,?r")
+  [(set (match_operand:DI 0 "s_register_operand" "=w,r,?r,w")
 (zero_extend:DI (match_operand:QHSI 1 ""
"")))]
   "TARGET_32BIT "
   "#"
-  [(set_attr "length" "8,4,8")
+  [(set_attr "length" "8,4,8,8")
+   (set_attr "arch" "neon_nota8,*,*,neon_onlya8")
(set_attr "ce_count" "2")
(set_attr "predicable" "yes")]
 )
 
 (define_insn "extenddi2"
-  [(set (match_operand:DI 0 "s_register_operand" "=w,r,?r,?r")
+  [(set (match_operand:DI 0 "s_register_operand" "=w,r,?r,?r,w")
 (sign_extend:DI (match_operand:QHSI 1 ""
"")))]
   "TARGET_32BIT "
   "#"
-  [(set_attr "length" "8,4,8,8")
+  [(set_attr "length" "8,4,8,8,8")
(set_attr "ce_count" "2")
(set_attr "shift" "1")
(set_attr "predicable" "yes")
-   (set_attr "arch" "*,*,a,t")]
+   (set_attr "arch" "neon_nota8,*,a,t,neon_onlya8")]
 )
 
 ;; Splits for all extensions to DImode
 (define_split
   [(set (match_operand:DI 0 "s_register_operand" "")
 (zero_extend:DI (match_operand 1 "nonimmediate_operand" "")))]
-  "TARGET_32BIT && (!TARGET_NEON
-   || (reload_completed
-   && !(IS_VFP_REGNUM (REGNO (operands[0])"
+  "TARGET_32BIT && reload_completed && !IS_VFP_REGNUM (REGNO (operands[0]))"
   [(set (match_dup 0) (match_dup 1))]
 {
   rtx lo_part = gen_lowpart (SImode, operands[0]);
@@ -4546,9 +4545,7 @@ (define_split
 (define_split
   [(set (match_operand:DI 0 "s_register_operand" "")
 (sign_extend:DI (match_operand 1 "nonimmediate_operand" "")))]
-  "TARGET_32BIT && (!TARGET_NEON
-   || (reload_completed
-   && !(IS_VFP_REGNUM (REGNO (operands[0])"
+  "TARGET_32BIT && reload_completed && !IS_VFP_REGNUM (REGNO (operands[0]))"
   [(set (match_dup 0) (ashiftrt:SI (match_dup 1) (const_int 31)))]
 {
   rtx lo_part = gen_lowpart (SImode, operands[0]);
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index

Fix PR 56077

[Andrey Belevantsev]

Hello,

As found by Jakub and explained in the PR audit trail by Alexander, this 
patch fixes the selective scheduler merge glitch of 2008 that added the 
unnecessary JUMP_P check to the flush_pending_lists call.  I have removed 
the check and expanded the binary negation for clarity.


The patch was tested on x86-64, ia64, and ppc64 to be safe.  The patch 
should be conservatively safe at this stage as it adds more flushes and 
thus more dependencies to the scheduler.  The original test is fixed, but I 
don't know how to add the test checking assembly insns order to the testsuite.


OK for trunk?

Andrey

2012-02-22  Alexander Monakov  
Andrey Belevantsev  

PR middle-end/56077
* sched-deps.c (sched_analyze_insn): When reg_pending_barrier,
flush pending lists also on non-jumps.
Index: gcc/sched-deps.c
===
*** gcc/sched-deps.c	(revision 196136)
--- gcc/sched-deps.c	(working copy)
*** sched_analyze_insn (struct deps_desc *de
*** 3318,3325 
}
  
/* Flush pending lists on jumps, but not on speculative checks.  */
!   if (JUMP_P (insn) && !(sel_sched_p ()
!  && sel_insn_is_speculation_check (insn)))
  	flush_pending_lists (deps, insn, true, true);
  
reg_pending_barrier = NOT_A_BARRIER;
--- 3318,3324 
}
  
/* Flush pending lists on jumps, but not on speculative checks.  */
!   if (!sel_sched_p () || !sel_insn_is_speculation_check (insn))
  	flush_pending_lists (deps, insn, true, true);
  
reg_pending_barrier = NOT_A_BARRIER;

Re: [LIBFFI] Re: Re: [PATCH] Add support for PaX enable kernels (MPROTECT)

[Dave Korn]

On 21/02/2013 19:35, Anthony Green wrote:
> On Thu, Feb 21, 2013 at 2:22 PM, Dave Korn wrote:
>>   Gcc-patches: Assuming AG approves, can we commit this without waiting for 
>> an
>> upstream libffi release and doing a full merge?  Currently GCC HEAD won't
>> build libffi (and hence libjava) without it.
> 
> This patch looks fine, thanks.  I don't plan to merge back into GCC
> for at least a week or two, so I think you should commit it to the GCC
> tree independently.
> 
> This means that 3.0.12 is broken for Cygwin.  Are you able to produce
> test results once you apply this change?  I should probably issue a
> quick 3.0.13 if the results are decent.

  Yes, the tests run fine (using libffi git HEAD from yesterday):

> Native configuration is i686-pc-cygwin
> 
> === libffi tests ===
> 
> 
> Running target unix
> FAIL: libffi.call/closure_thiscall.c (test for excess errors)
> WARNING: libffi.call/closure_thiscall.c compilation failed to produce 
> executable
> 
> FAIL: libffi.call/closure_thiscall.c (test for excess errors)
> WARNING: libffi.call/closure_thiscall.c compilation failed to produce 
> executable
> 
> FAIL: libffi.call/closure_thiscall.c (test for excess errors)
> WARNING: libffi.call/closure_thiscall.c compilation failed to produce 
> executable
> 
> FAIL: libffi.call/closure_thiscall.c (test for excess errors)
> WARNING: libffi.call/closure_thiscall.c compilation failed to produce 
> executable
> 
> FAIL: libffi.call/closure_thiscall.c (test for excess errors)
> WARNING: libffi.call/closure_thiscall.c compilation failed to produce 
> executable
> 
> 
> === libffi Summary ===
> 
> # of expected passes1924
> # of unexpected failures5

  I was using gcc-4.5.3, which is from before thiscall support was added, so
those compile failures are unremarkable and expected.  Given that, we have a
clean sweep.

cheers,
  DaveK

Re: r196201 - in /trunk: gcc/ChangeLog gcc/config/i...

[Jakub Jelinek]

On Fri, Feb 22, 2013 at 11:53:39AM +0400, Konstantin Serebryany wrote:
> Jakub, thanks again for cleaning up my mess.
> 
> Here is a question regarding your fix:
> > -#if ASAN_USE_PREINIT_ARRAY
> > +#if ASAN_USE_PREINIT_ARRAY && !defined (PIC)
> 
> The PIC macro is an artifact of the GCC build system and is not
> directly related the the -fPIC flag?
> As I can see, in the gcc build we compile all of asan sources twice:
> w/ and w/o "-fPIC -DPIC".
> If I move the preinit_array to a separate file (asan_preinit.cc), will
> we need to have two builds?
> I think we can just build all objects once with -fPIC and then not
> link asan_preinit.o into libasan.so
> In clang we build the static libasan with -fPIC, it doesn't hurt.
> Anyway, I've just committed
> http://llvm.org/viewvc/llvm-project?rev=175871&view=rev with
> asan_preinit.cc

Here is corresponding gcc patch to use it.
libasan_preinit.o is installed alongside with libasan.a and libasan.so*,
and linked into executables (but not shared libraries).

Additionally, I've added __attribute__((constructor)) to __asan_init,
to make it more likely that asan will be initialized properly even when
the executable isn't instrumented.  Shared libraries linked with
-fsanitize=address will depend on libasan.so.0, and the dynamic linker first
runs constructors of dependencies before running constructors of the
libraries that have those dependencies (unless there are dependency cycles, but 
that
is a user bug).

2013-02-22  Jakub Jelinek  

PR sanitizer/56393
* config/gnu-user.h (LIBASAN_EARLY_SPEC): Link in libasan_preinit.o
if not linking a shared library.

* lib/asan-dg.exp (asan_link_flags): Add
-B${gccpath}/libsanitizer/asan/ to flags.

* asan/Makefile.am (nodist_toolexeclib_HEADERS): Set to
libasan_preinit.o.
(libasan_preinit.o): Depend on asan_preinit.o.
* asan/Makefile.in: Regenerated.
* asan/asan_preinit.cc: New file, synced from upstream.
* asan/asan_rtl.cc: Remove preinit stuff, synced from upstream.
Add __attribute__((constructor)) to __asan_init.

--- gcc/config/gnu-user.h.jj2013-02-05 16:55:01.0 +0100
+++ gcc/config/gnu-user.h   2013-02-22 13:02:11.0 +0100
@@ -104,11 +104,13 @@ see the files COPYING3 and COPYING.RUNTI
it to force everything into the executable.  And similarly for -ltsan.  */
 #if defined(HAVE_LD_STATIC_DYNAMIC)
 #undef LIBASAN_EARLY_SPEC
-#define LIBASAN_EARLY_SPEC "%{static-libasan:%{!shared:" \
+#define LIBASAN_EARLY_SPEC "%{!shared:libasan_preinit%O%s} " \
+  "%{static-libasan:%{!shared:" \
   LD_STATIC_OPTION " --whole-archive -lasan --no-whole-archive " \
   LD_DYNAMIC_OPTION "}}%{!static-libasan:-lasan}"
 #undef LIBTSAN_EARLY_SPEC
-#define LIBTSAN_EARLY_SPEC "%{static-libtsan:%{!shared:" \
+#define LIBTSAN_EARLY_SPEC "%{!shared:libasan_preinit%O%s} " \
+  "%{static-libtsan:%{!shared:" \
   LD_STATIC_OPTION " --whole-archive -ltsan --no-whole-archive " \
   LD_DYNAMIC_OPTION "}}%{!static-libtsan:-ltsan}"
 #endif
--- gcc/testsuite/lib/asan-dg.exp.jj2013-01-11 09:02:39.0 +0100
+++ gcc/testsuite/lib/asan-dg.exp   2013-02-22 13:06:59.437483035 +0100
@@ -41,6 +41,7 @@ proc asan_link_flags { paths } {
 if { $gccpath != "" } {
   if { [file exists "${gccpath}/libsanitizer/asan/.libs/libasan.a"]
   || [file exists 
"${gccpath}/libsanitizer/asan/.libs/libasan.${shlib_ext}"] } {
+ append flags " -B${gccpath}/libsanitizer/asan/ "
  append flags " -L${gccpath}/libsanitizer/asan/.libs "
  append ld_library_path ":${gccpath}/libsanitizer/asan/.libs"
   }
--- libsanitizer/asan/Makefile.am.jj2013-02-21 20:10:41.0 +0100
+++ libsanitizer/asan/Makefile.am   2013-02-22 12:36:30.746317422 +0100
@@ -12,6 +12,7 @@ AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFL
 ACLOCAL_AMFLAGS = -I $(top_srcdir) -I $(top_srcdir)/config
 
 toolexeclib_LTLIBRARIES = libasan.la
+nodist_toolexeclib_HEADERS = libasan_preinit.o
 
 asan_files = \
asan_allocator.cc \
@@ -45,6 +46,9 @@ libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX
 
 libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` 
-lpthread -ldl
 
+libasan_preinit.o: asan_preinit.o
+   cp $< $@
+
 # Work around what appears to be a GNU make bug handling MAKEFLAGS
 # values defined in terms of make variables, as is the case for CC and
 # friends when we are called from the top level Makefile.
--- libsanitizer/asan/asan_preinit.cc.jj2013-02-22 12:12:11.387674830 
+0100
+++ libsanitizer/asan/asan_preinit.cc   2013-02-22 12:12:11.387674830 +0100
@@ -0,0 +1,27 @@
+//===-- asan_preinit.cc 
---===//
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This file is a part of AddressSanitizer, an address 

Re: closing PR's (was Re: [PATCH ARM iWMMXt 0/5] Improve iWMMXt support)

[nick clifton]

Hi Hans-Peter,

Sorry if I misinterpret, but it seems a reminder is in order:
magic powers are attached to whome...@gcc.gnu.org accounts in
bugzilla, so when people use them instead of their
whome...@employer.example.com, they are able to close PR's they
haven't created.


Ah - thank you, I did not know that.  I have now logged in using that 
address and closed the requested PR.


Cheers
  Nick

Re: Re: [PING][PATCH][RFC] Bug handling SUBREG (MEM) - MEM having side-effects?

[Tejas Belagod]

Hi,

Could you please let me know if this is OK for 4.7 as this bug shows up on 4.7 
but seems to be latent on trunk? I'd like to get this in before the release.


Thanks,
Tejas Belagod
ARM.

Tejas Belagod wrote:

PING.

Tejas Belagod wrote:

Richard Sandiford wrote:

After the discussions Richard Earnshaw had on IRC with Andrew Pinski, it was
felt that it was best to fix the standard predicate
'general_operand' to not allow SUBREG (MEM) with side-effects as it has known
issues associated with it - particularly reload not being able to deal with such
cases. 'general_operand' currently outlaws cases like paradoxical SUBREG (MEM)
on targets with insn scheduling and SUBREG (MEM) with non-zero SUBREG_BYTE. This
is another case it should not allow. Here is a patch that tightens
general_operands to not allow SUBREG (MEM) with MEM having side-effects.

I would like to hear some thoughts on this.

LGTM.

It would be good to get rid of subreg mem operands altogether at some point,
but that's a little too drastic for stage 3.  This patch looks like a strict
improvement.


Thanks for looking at this. Is this OK for 4.7 as well?

Tejas Belagod
ARM.

Re: PR target/52555: attribute optimize is overriding command line options

[Jakub Jelinek]

On Thu, Feb 21, 2013 at 11:02:56PM +, Steve Ellcey wrote:
> Have you gotten any reports of problems with this patch?  It seems to be 
> sending cc1 into an infinite
> loop during the GCC testsuite for me.  I am testing the mips-mti-linux-gnu 
> target and tests like
> gcc.target/mips/call-saved-1.c are causing cc1 to suck up all my memory and 
> swap space before the
> test times out.
> 
> I will keep digging and see if I can figure out what is going on but I wanted 
> to see if anyone else has
> reported this problem.

I think this should fix this (but totally untested except for
call-saved-1.c, and it doesn't make any sense to test on non-mips).

The problem I believe is that Aldy has changed init_optabs and insn-opinit.c
to use this_fn_optabs instead of this_target_optabs, but it is only set in
invoke_set_current_function_hook.  During save_target_globals we want to
init this_target_optabs, so we need to temporarily switch this_fn_optabs to
make that happen.

2013-02-22  Jakub Jelinek  

PR target/52555
* target-globals.c (save_target_globals): For init_reg_sets and
target_reinit remporarily set this_fn_optabs to this_target_optabs.

--- gcc/target-globals.c.jj 2013-02-19 07:40:03.0 +0100
+++ gcc/target-globals.c2013-02-22 10:55:36.725435859 +0100
@@ -67,6 +67,7 @@ struct target_globals *
 save_target_globals (void)
 {
   struct target_globals *g;
+  struct target_optabs *saved_this_fn_optabs = this_fn_optabs;
 
   g = ggc_alloc_target_globals ();
   g->flag_state = XCNEW (struct target_flag_state);
@@ -86,8 +87,10 @@ save_target_globals (void)
   g->bb_reorder = XCNEW (struct target_bb_reorder);
   g->lower_subreg = XCNEW (struct target_lower_subreg);
   restore_target_globals (g);
+  this_fn_optabs = this_target_optabs;
   init_reg_sets ();
   target_reinit ();
+  this_fn_optabs = saved_this_fn_optabs;
   return g;
 }
 

Jakub

Re: r196201 - in /trunk: gcc/ChangeLog gcc/config/i...

[Jakub Jelinek]

On Fri, Feb 22, 2013 at 11:53:39AM +0400, Konstantin Serebryany wrote:
> Jakub, thanks again for cleaning up my mess.
> 
> Here is a question regarding your fix:
> > -#if ASAN_USE_PREINIT_ARRAY
> > +#if ASAN_USE_PREINIT_ARRAY && !defined (PIC)
> 
> The PIC macro is an artifact of the GCC build system and is not
> directly related the the -fPIC flag?

The PIC macro is an artifact of using libtool, which takes care of building
everything twice, once with -fPIC -DPIC, once without.
If we set up our Makefiles so that asan_preinit.cc isn't build as part of
libasan.la (the libtool library), but just as an object, then the PIC guard
isn't needed.

Jakub