Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

2012-03-27 Thread Eric Botcazou
> Btw, I put things in stor-layout.c exactly to allow a langhook
> eventually controlling things for the bitfield representative.
> Mind adding one that simply disables them completely for Ada?
> Or maybe, for selected record types, so that we do
>
>   if (lang_hooks.types.lower_bitfield_layout (rli->t))
> finish_bitfield_layout (rli->t);
>
> ?  Letting the FE decide when to punt is certainly better than
> trying to figure it out from stor-layout.c code.  I suppose
> for types that are supposed to interoperate with C / C++ using
> the C / C++ rules makes sense (I suppose there is sth like
> C/C++ interoperability with Ada).

Yes, there is C/C++ interoperability in Ada.  But GNAT's policy is to be 
compatible with C/C++ by default, so I'd rather not deviate from the common 
code for such a central thing as record layout if we can avoid it.

-- 
Eric Botcazo


Re: [patch][RFC] bail out after front-end errors

2012-03-27 Thread Richard Guenther
On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher  wrote:
> Hello,
>
> This patch is one way to address PR44982. I see no good reason to
> cgraph_finalize_compilation_unit if there were parse errors. As Richi
> already pointed out, GCC traditionally has proceeded after parse
> errors to preserve warnings and errors we generate from the middle-end
> and during semantic analysis. But it seems to me that those warnings
> are not very meaningful after parse errors (-Wuninitialized after a
> parse error??), and errors from the middle end are mostly for exotic
> code (involving asm()s and the like). Bailing out after parse errors
> is therefore IMHO the right thing to do for the common case.
>
> Thoughts? Comments?

Conceptually it makes sense.  Did you check whether allowing the
FE too proceed to final_write_globals but stop before
cgraph_finalize_compilation_unit
preserves any errors?  I would expect that maybe FE global variable
diagostics are defered until that?  It would be nice to finally move
the call to cgraph_finalize_compilation_unit to the middle-end ...
(warning, if you try that you run into an issue with the Java frontend ... :/)

Richard.

> If the consensus is that this patch goes in, I'll also have to do some
> work on the test suite, because some warnings and errors disappear.
> List attached below. A lot of errors and warnings from g++ disappear.
> I suspect this is because they are only issued during gimplification.
> That is something I'll have to address before this patch could go in.
> Before I spend the effort, I'd like to know if there is consensus on
> the general direction proposed here... ;-)
>
> Ciao!
> Steven
>
>
>
> Index: toplev.c
> ===
> --- toplev.c    (revision 185813)
> +++ toplev.c    (working copy)
> @@ -561,9 +561,14 @@ compile_file (void)
>   /* Compilation is now finished except for writing
>      what's left of the symbol table output.  */
>
> -  if (flag_syntax_only || flag_wpa)
> +  /* If all we have to do is syntax checking, or if there were parse
> +     errors, stop here.  */
> +  if (flag_syntax_only || seen_error ())
>     return;
>
> +  if (flag_wpa)
> +    return;
> +
>   timevar_start (TV_PHASE_GENERATE);
>
>   ggc_protect_identifiers = false;
> @@ -571,12 +576,6 @@ compile_file (void)
>   /* This must also call cgraph_finalize_compilation_unit.  */
>   lang_hooks.decls.final_write_globals ();
>
> -  if (seen_error ())
> -    {
> -      timevar_stop (TV_PHASE_GENERATE);
> -      return;
> -    }
> -
>   /* Compilation unit is finalized.  When producing non-fat LTO object, we are
>      basically finished.  */
>   if (in_lto_p || !flag_lto || flag_fat_lto_objects)
>
>
> New failing tests:
>> FAIL: gcc.dg/asm-7.c  (test for errors, line 15)
>> FAIL: gcc.dg/asm-7.c  (test for errors, line 16)
>> FAIL: gcc.dg/declspec-10.c  (test for warnings, line 19)
>> FAIL: gcc.dg/declspec-11.c  (test for warnings, line 19)
>> FAIL: gcc.dg/declspec-9.c  (test for errors, line 20)
>> FAIL: gcc.dg/gnu99-static-1.c  (test for errors, line 21)
>> FAIL: gcc.dg/gnu99-static-1.c  (test for errors, line 25)
>> FAIL: gcc.dg/pr48552-1.c  (test for errors, line 16)
>> FAIL: gcc.dg/pr48552-1.c  (test for errors, line 40)
>> FAIL: gcc.dg/pr48552-1.c  (test for errors, line 52)
>> FAIL: gcc.dg/pr48552-2.c  (test for errors, line 16)
>> FAIL: gcc.dg/pr48552-2.c  (test for errors, line 40)
>> FAIL: gcc.dg/pr48552-2.c  (test for errors, line 52)
>> FAIL: gcc.dg/redecl-10.c  (test for warnings, line 15)
>> FAIL: gcc.dg/redecl-10.c  (test for warnings, line 29)
>> FAIL: gcc.dg/gomp/block-2.c  (test for errors, line 14)
>> FAIL: gcc.dg/gomp/block-2.c  (test for errors, line 16)
>> FAIL: gcc.dg/gomp/block-7.c  (test for errors, line 9)
>> FAIL: gcc.dg/gomp/block-7.c  (test for errors, line 10)
>> FAIL: gcc.dg/gomp/block-7.c  (test for errors, line 11)
>> FAIL: gcc.dg/gomp/block-7.c  (test for errors, line 15)
>> FAIL: gcc.dg/gomp/block-7.c  (test for errors, line 16)
>> FAIL: gcc.dg/gomp/block-7.c  (test for errors, line 17)
>> FAIL: gcc.dg/gomp/pr27415.c  (test for errors, line 9)
>> FAIL: gcc.dg/gomp/pr27415.c  (test for errors, line 28)
>> FAIL: gcc.dg/gomp/pr27415.c  (test for errors, line 37)
>> FAIL: c-c++-common/tm/safe-3.c (internal compiler error)
>> FAIL: c-c++-common/tm/safe-3.c (test for excess errors)
>> FAIL: gcc.dg/tm/pr52141.c (internal compiler error)
>> FAIL: gcc.dg/tm/pr52141.c (test for excess errors)
>> FAIL: g++.dg/cpp0x/constexpr-ex1.C  (test for warnings, line 17)
>> FAIL: g++.dg/cpp0x/constexpr-function2.C  (test for warnings, line 46)
>> FAIL: g++.dg/cpp0x/constexpr-neg1.C  (test for warnings, line 5)
>> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C  (test for warnings, line 15)
>> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C not an aggregate (test for 
>> errors, line 16)
>> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C deleted default ctor (test for 
>> errors, line 17)
>> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg

Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

2012-03-27 Thread Richard Guenther
On Tue, 27 Mar 2012, Eric Botcazou wrote:

> > Btw, I put things in stor-layout.c exactly to allow a langhook
> > eventually controlling things for the bitfield representative.
> > Mind adding one that simply disables them completely for Ada?
> > Or maybe, for selected record types, so that we do
> >
> >   if (lang_hooks.types.lower_bitfield_layout (rli->t))
> > finish_bitfield_layout (rli->t);
> >
> > ?  Letting the FE decide when to punt is certainly better than
> > trying to figure it out from stor-layout.c code.  I suppose
> > for types that are supposed to interoperate with C / C++ using
> > the C / C++ rules makes sense (I suppose there is sth like
> > C/C++ interoperability with Ada).
> 
> Yes, there is C/C++ interoperability in Ada.  But GNAT's policy is to be 
> compatible with C/C++ by default, so I'd rather not deviate from the common 
> code for such a central thing as record layout if we can avoid it.

I see.  Though the code does not affect layout but only access "layout"
for bitfields.  I'm fine with fixing the issues we run into elsewhere,
just the langhook is a possibility I had in mind from the start, in
case frontends differ in their memory model for bitfields.

Richard.


Re: [Patch V2] libgfortran: do not assume libm

2012-03-27 Thread Tristan Gingold

On Mar 26, 2012, at 11:43 PM, Janne Blomqvist wrote:
[...]

> On x86_64-unknown-linux-gnu bootstrap I see the following:
> 
> 
> make[1]: Entering directory
> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
> make  check-am
> make[2]: Entering directory
> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
> (CDPATH="${ZSH_VERSION+.}:" && cd ../../../trunk-git/libgfortran &&
> /bin/bash /home/janne/src/gfortran/trunk/trunk-git/missing --run
> autoheader)
> true  DO=all multi-do # make
> make[1]: Entering directory `/home/janne/src/gfortran/trunk/objdir-git/gcc'
> Making a new config file...
> echo "set tmpdir
> /home/janne/src/gfortran/trunk/objdir-git/gcc/testsuite" >> ./site.tmp
> autoheader: warning: missing template: HAVE_ACOS
> autoheader: Use AC_DEFINE([HAVE_ACOS], [], [Description])
> autoheader: warning: missing template: HAVE_ACOSF

...

> autoheader: warning: missing template: HAVE_YNF
> autoheader: warning: missing template: HAVE_YNL
> make[2]: *** [../../../trunk-git/libgfortran/config.h.in] Error 1
> make[2]: Leaving directory
> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
> make[1]: *** [check] Error 2
> make[1]: Leaving directory
> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
> make: *** [check-target-libgfortran] Error 2
> make: *** Waiting for unfinished jobs
> 
> 
> Anybody else seeing something similar? The strange thing is that even
> though there is an error the bootstrapping continues just fine. Though
> I haven't had time to look into it deeper.

Yes, I can reproduce that.  Autoheader returns 1 as exit status even for 
warnings.
I am investigating (I suppose that adding a description will fix the issue).

Tristan.



rs6000 toc reference rtl again

2012-03-27 Thread Alan Modra
Now that we are back in stage1, I'd like to apply
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to
toc reference rtl in order to properly specify r2 dependencies.  More
commentary in that url.  I'm reposting the patch here since the old
one no longer applies cleanly, and I've added some ENABLE_CHECKING
code in rs6000_delegitimize_address.

Bootstrapped and regression tested powerpc64-linux.  OK for mainline?

* cselib.c (preserve_only_constants): Remove HIGH rtx containing
value references.
* cprop.c (cprop_constant_p): Return false for HIGH rtx containing
value references.
* config/rs6000/predicates.md (input_operand): Match unspec.  Remove
redundant tests.
* rs6000-protos.h (toc_relative_expr_p): Update prototype.
* const/rs6000/rs6000.c (tocrel_base, tocrel_offset): Make const.
(legitimate_constant_pool_address_p): Move TARGET_TOC test and
register checks to..
(toc_relative_expr_p): ..here.  Add "strict" param.  Match new rtl
generated by create_TOC_reference.
(rs6000_delegitimize_address): Handle new rtl for toc refs.
(rs6000_cannot_force_const_mem, rs6000_find_base_term): Likewise.
(use_toc_relative_ref): New function, split out from..
(rs6000_emit_move): ..here.  Remove redundant tests.
(rs6000_legitimize_reload_address): Formatting.  Remove redundant
code.  Use use_toc_relative_ref.
(print_operand): Formatting, style.  Adjust for toc changes.
(print_operand_address): Likewise.
(rs6000_output_addr_const_extra): Likewise.
(create_TOC_reference): Put TOC_REGISTER in UNSPEC_TOCREL rather
than a PLUS.  Use this formulation for both high and low part
of -mcmodel=medium/large toc reference too.
* config/rs6000/rs6000.md (tls_gd, tls_gd_high): Similarly avoid
a PLUS in high part of addresses here.
(tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high): Likewise.
(tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewise.
(largetoc_high, largetoc_low): Move earlier.  Cope when no
base reg available.

Index: gcc/cselib.c
===
--- gcc/cselib.c(revision 185830)
+++ gcc/cselib.c(working copy)
@@ -404,8 +404,9 @@ invariant_or_equiv_p (cselib_val *v)
   && v->locs->next == NULL)
 {
   if (CONSTANT_P (v->locs->loc)
- && (GET_CODE (v->locs->loc) != CONST
- || !references_value_p (v->locs->loc, 0)))
+ && !((GET_CODE (v->locs->loc) == CONST
+   || GET_CODE (v->locs->loc) == HIGH)
+  && references_value_p (v->locs->loc, 0)))
return true;
   /* Although a debug expr may be bound to different expressions,
 we can preserve it as if it was constant, to get unification
Index: gcc/cprop.c
===
--- gcc/cprop.c (revision 185830)
+++ gcc/cprop.c (working copy)
@@ -263,7 +263,13 @@ insert_set_in_table (rtx dest, rtx src, rtx insn,
 static bool
 cprop_constant_p (const_rtx x)
 {
-  return CONSTANT_P (x) && (GET_CODE (x) != CONST || shared_const_p (x));
+  if (!CONSTANT_P (x))
+return false;
+  if (GET_CODE (x) == CONST)
+return shared_const_p (x);
+  if (GET_CODE (x) == HIGH)
+return !references_value_p (x, false);
+  return true;
 }
 
 /* Scan SET present in INSN and add an entry to the hash TABLE.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 185830)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5285,15 +5285,33 @@ constant_pool_expr_p (rtx op)
  && ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (base), Pmode));
 }
 
-static rtx tocrel_base, tocrel_offset;
+static const_rtx tocrel_base, tocrel_offset;
 
 bool
-toc_relative_expr_p (rtx op)
+toc_relative_expr_p (const_rtx op, bool strict)
 {
-  if (GET_CODE (op) != CONST)
+  if (!TARGET_TOC)
 return false;
 
-  split_const (op, &tocrel_base, &tocrel_offset);
+  if (TARGET_CMODEL != CMODEL_SMALL)
+{
+  /* Only match the low part.  */
+  if (GET_CODE (op) == LO_SUM
+ && REG_P (XEXP (op, 0))
+ && INT_REG_OK_FOR_BASE_P (XEXP (op, 0), strict))
+   op = XEXP (op, 1);
+  else
+   return false;
+}
+
+  tocrel_base = op;
+  tocrel_offset = const0_rtx;
+  if (GET_CODE (op) == PLUS && CONST_INT_P (XEXP (op, 1)))
+{
+  tocrel_base = XEXP (op, 0);
+  tocrel_offset = XEXP (op, 1);
+}
+
   return (GET_CODE (tocrel_base) == UNSPEC
  && XINT (tocrel_base, 1) == UNSPEC_TOCREL);
 }
@@ -5305,14 +5323,7 @@ bool
 legitimate_constant_pool_address_p (const_rtx x, enum machine_mode mode,
bool strict)
 {
-  return (TARGET_TOC
- && (GET_CODE (x) == PLUS || GET_CODE (x) == LO_SUM)
-

Re: [Patch V2] libgfortran: do not assume libm

2012-03-27 Thread Tristan Gingold

On Mar 27, 2012, at 9:51 AM, Tristan Gingold wrote:

> 
> On Mar 26, 2012, at 11:43 PM, Janne Blomqvist wrote:
> [...]
> 
>> On x86_64-unknown-linux-gnu bootstrap I see the following:
>> 
>> 
>> make[1]: Entering directory
>> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
>> make  check-am
>> make[2]: Entering directory
>> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
>> (CDPATH="${ZSH_VERSION+.}:" && cd ../../../trunk-git/libgfortran &&
>> /bin/bash /home/janne/src/gfortran/trunk/trunk-git/missing --run
>> autoheader)
>> true  DO=all multi-do # make
>> make[1]: Entering directory `/home/janne/src/gfortran/trunk/objdir-git/gcc'
>> Making a new config file...
>> echo "set tmpdir
>> /home/janne/src/gfortran/trunk/objdir-git/gcc/testsuite" >> ./site.tmp
>> autoheader: warning: missing template: HAVE_ACOS
>> autoheader: Use AC_DEFINE([HAVE_ACOS], [], [Description])
>> autoheader: warning: missing template: HAVE_ACOSF
> 
> ...
> 
>> autoheader: warning: missing template: HAVE_YNF
>> autoheader: warning: missing template: HAVE_YNL
>> make[2]: *** [../../../trunk-git/libgfortran/config.h.in] Error 1
>> make[2]: Leaving directory
>> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
>> make[1]: *** [check] Error 2
>> make[1]: Leaving directory
>> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
>> make: *** [check-target-libgfortran] Error 2
>> make: *** Waiting for unfinished jobs
>> 
>> 
>> Anybody else seeing something similar? The strange thing is that even
>> though there is an error the bootstrapping continues just fine. Though
>> I haven't had time to look into it deeper.
> 
> Yes, I can reproduce that.  Autoheader returns 1 as exit status even for 
> warnings.
> I am investigating (I suppose that adding a description will fix the issue).

Hi,

this patch fixes this issue.  Is it OK ?

Maybe we should include the AC_DEFINE action within GCC_CHECK_MATH_FUNC.  Will 
try to do that.

Sorry for not having noticed this issue before.

Tristan.

libgfortran/
2012-03-27  Tristan Gingold  

* configure.ac: Add description to AC_DEFINE in
GCC_CHECK_MATH_FUNC.
* configure: Regenerate
* config.h.in: Regenerate.


diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 0f29804..08eb789 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -269,191 +269,191 @@ getcwd localtime_r gmtime_r strerror_r getpwuid_r 
ttyname_r clock_gettime \
 readlink getgid getpid getppid getuid geteuid umask)
 
 # Check for C99 (and other IEEE) math functions
-GCC_CHECK_MATH_FUNC([acosf],[AC_DEFINE([HAVE_ACOSF],[1])])
-GCC_CHECK_MATH_FUNC([acos],[AC_DEFINE([HAVE_ACOS],[1])])
-GCC_CHECK_MATH_FUNC([acosl],[AC_DEFINE([HAVE_ACOSL],[1])])
-GCC_CHECK_MATH_FUNC([acoshf],[AC_DEFINE([HAVE_ACOSHF],[1])])
-GCC_CHECK_MATH_FUNC([acosh],[AC_DEFINE([HAVE_ACOSH],[1])])
-GCC_CHECK_MATH_FUNC([acoshl],[AC_DEFINE([HAVE_ACOSHL],[1])])
-GCC_CHECK_MATH_FUNC([asinf],[AC_DEFINE([HAVE_ASINF],[1])])
-GCC_CHECK_MATH_FUNC([asin],[AC_DEFINE([HAVE_ASIN],[1])])
-GCC_CHECK_MATH_FUNC([asinl],[AC_DEFINE([HAVE_ASINL],[1])])
-GCC_CHECK_MATH_FUNC([asinhf],[AC_DEFINE([HAVE_ASINHF],[1])])
-GCC_CHECK_MATH_FUNC([asinh],[AC_DEFINE([HAVE_ASINH],[1])])
-GCC_CHECK_MATH_FUNC([asinhl],[AC_DEFINE([HAVE_ASINHL],[1])])
-GCC_CHECK_MATH_FUNC([atan2f],[AC_DEFINE([HAVE_ATAN2F],[1])])
-GCC_CHECK_MATH_FUNC([atan2],[AC_DEFINE([HAVE_ATAN2],[1])])
-GCC_CHECK_MATH_FUNC([atan2l],[AC_DEFINE([HAVE_ATAN2L],[1])])
-GCC_CHECK_MATH_FUNC([atanf],[AC_DEFINE([HAVE_ATANF],[1])])
-GCC_CHECK_MATH_FUNC([atan],[AC_DEFINE([HAVE_ATAN],[1])])
-GCC_CHECK_MATH_FUNC([atanl],[AC_DEFINE([HAVE_ATANL],[1])])
-GCC_CHECK_MATH_FUNC([atanhf],[AC_DEFINE([HAVE_ATANHF],[1])])
-GCC_CHECK_MATH_FUNC([atanh],[AC_DEFINE([HAVE_ATANH],[1])])
-GCC_CHECK_MATH_FUNC([atanhl],[AC_DEFINE([HAVE_ATANHL],[1])])
-GCC_CHECK_MATH_FUNC([cargf],[AC_DEFINE([HAVE_CARGF],[1])])
-GCC_CHECK_MATH_FUNC([carg],[AC_DEFINE([HAVE_CARG],[1])])
-GCC_CHECK_MATH_FUNC([cargl],[AC_DEFINE([HAVE_CARGL],[1])])
-GCC_CHECK_MATH_FUNC([ceilf],[AC_DEFINE([HAVE_CEILF],[1])])
-GCC_CHECK_MATH_FUNC([ceil],[AC_DEFINE([HAVE_CEIL],[1])])
-GCC_CHECK_MATH_FUNC([ceill],[AC_DEFINE([HAVE_CEILL],[1])])
-GCC_CHECK_MATH_FUNC([copysignf],[AC_DEFINE([HAVE_COPYSIGNF],[1])])
-GCC_CHECK_MATH_FUNC([copysign],[AC_DEFINE([HAVE_COPYSIGN],[1])])
-GCC_CHECK_MATH_FUNC([copysignl],[AC_DEFINE([HAVE_COPYSIGNL],[1])])
-GCC_CHECK_MATH_FUNC([cosf],[AC_DEFINE([HAVE_COSF],[1])])
-GCC_CHECK_MATH_FUNC([cos],[AC_DEFINE([HAVE_COS],[1])])
-GCC_CHECK_MATH_FUNC([cosl],[AC_DEFINE([HAVE_COSL],[1])])
-GCC_CHECK_MATH_FUNC([ccosf],[AC_DEFINE([HAVE_CCOSF],[1])])
-GCC_CHECK_MATH_FUNC([ccos],[AC_DEFINE([HAVE_CCOS],[1])])
-GCC_CHECK_MATH_FUNC([ccosl],[AC_DEFINE([HAVE_CCOSL],[1])])
-GCC_CHECK_MATH_FUNC([coshf],[AC_DEFINE([HAVE_COSHF],[1])])
-GCC_CHECK_MATH_FUNC([cosh],[AC_DEFINE([HAVE_COSH],[1])])
-GCC_CHECK_MATH_FUNC([coshl],[AC_D

Re: struct siginfo vs. siginfo_t

2012-03-27 Thread Thomas Schwinge
Hi!

Ping.

On Wed, 21 Mar 2012 15:56:04 +0100, I wrote:
> On Thu, 15 Mar 2012 11:57:00 -0400, Carlos O'Donell  
> wrote:
> > On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge
> >  wrote:
> > > On 26 Feb 2012 18:17:52 -, drep...@sourceware.org wrote:
> > >> http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4efeffc1d583597e4f52985b9747269e47b754e2
> > >>
> > >> commit 4efeffc1d583597e4f52985b9747269e47b754e2
> > >> Author: Ulrich Drepper 
> > >> Date:   Sun Feb 26 13:17:27 2012 -0500
> > >>
> > >>     Fix up POSIX testing in conformtest
> > >
> > >> [...]
> > >> +     * sysdeps/unix/sysv/linux/bits/siginfo.h: Don't name siginfo_t
> > >> +     struct.  [...]
> > >> [...]
> > >
> > >> diff --git a/sysdeps/unix/sysv/linux/bits/siginfo.h 
> > >> b/sysdeps/unix/sysv/linux/bits/siginfo.h
> > >> index ecef39d..0635e2f 100644
> > >> --- a/sysdeps/unix/sysv/linux/bits/siginfo.h
> > >> +++ b/sysdeps/unix/sysv/linux/bits/siginfo.h
> > >> [...]
> > >> @@ -47,7 +47,7 @@ typedef union sigval
> > >>  #  define __SI_PAD_SIZE     ((__SI_MAX_SIZE / sizeof (int)) - 3)
> > >>  # endif
> > >>
> > >> -typedef struct siginfo
> > >> +typedef struct
> > >>    {
> > >>      int si_signo;            /* Signal number.  */
> > >>      int si_errno;            /* If non-zero, an errno value associated 
> > >> with
> > >> [...]
> > >
> > > This change breaks GCC:
> > >
> > >    In file included from 
> > > /scratch/tschwing/FM_sh-linux-gnu-mk2/src/gcc-mainline/libgcc/unwind-dw2.c:377:0:
> > >    ./md-unwind-support.h: In function 'sh_fallback_frame_state':
> > >    ./md-unwind-support.h:182:17: error: field 'info' has incomplete type
> > >
> > > In my case, this is really libgcc/config/sh/linux-unwind.h:
> > >
> > >    [...]
> > >       181            struct rt_sigframe {
> > >       182              struct siginfo info;
> > >       183              struct ucontext uc;
> > >       184            } *rt_ = context->cfa;
> > >    [...]
> > 
> > POSIX says you get "siginto_t" *not* "struct siginfo," please fix the code.
> 
> There is one usage in boehm-gc/os_dep.c, but it is only used if
> SUNOS5SIGS is defined, which it is only if one of SUNOS5, DRSNX, HPUX, or
> FREEBSD is defined, which are all not using Linux-based glibc ports.
> 
> Likewise, gcc/ada/init.c has a struct __siginfo occurence, but only for
> __FreeBSD__.
> 
> config/rs6000/linux-unwind.h uses ``char siginfo[128]'', and
> config/s390/linux-unwind.h also uses a constant.
> 
> I tested the following patch for sh-linux-gnu.  This only covers one
> configuration, but the change is pretty mechanic anyway and every place
> that used to refer to struct siginfo already must have had  in
> its include path, which is the same file that declares siginfo_t.
> 
> OK to commit?  This should probably also go into any active release
> branches, to keep them buildable once this glibc change ripples through?
> 
> libgcc/
>   * config/alpha/linux-unwind.h (alpha_fallback_frame_state): Use
>   siginfo_t instead of struct siginfo.
>   * config/bfin/linux-unwind.h (bfin_fallback_frame_state): Likewise.
>   * config/i386/linux-unwind.h (x86_fallback_frame_state): Likewise.
>   * config/ia64/linux-unwind.h (ia64_fallback_frame_state)
>   (ia64_handle_unwabi): Likewise.
>   * config/mips/linux-unwind.h (mips_fallback_frame_state): Likewise.
>   * config/pa/linux-unwind.h (pa32_fallback_frame_state): Likewise.
>   * config/sh/linux-unwind.h (shmedia_fallback_frame_state)
>   (sh_fallback_frame_state): Likewise.
>   * config/tilepro/linux-unwind.h (tile_fallback_frame_state): Likewise.
>   * config/xtensa/linux-unwind.h (xtensa_fallback_frame_state): Likewise.
> 
> diff --git a/libgcc/config/alpha/linux-unwind.h 
> b/libgcc/config/alpha/linux-unwind.h
> index 4c811dc..f747053 100644
> --- a/libgcc/config/alpha/linux-unwind.h
> +++ b/libgcc/config/alpha/linux-unwind.h
> @@ -49,7 +49,7 @@ alpha_fallback_frame_state (struct _Unwind_Context *context,
>else if (pc[1] == 0x201f015f)  /* lda $0,NR_rt_sigreturn */
>  {
>struct rt_sigframe {
> - struct siginfo info;
> + siginfo_t info;
>   struct ucontext uc;
>} *rt_ = context->cfa;
>sc = &rt_->uc.uc_mcontext;
> diff --git a/libgcc/config/bfin/linux-unwind.h 
> b/libgcc/config/bfin/linux-unwind.h
> index 88c8285..6e8f1ad 100644
> --- a/libgcc/config/bfin/linux-unwind.h
> +++ b/libgcc/config/bfin/linux-unwind.h
> @@ -48,10 +48,10 @@ bfin_fallback_frame_state (struct _Unwind_Context 
> *context,
>  {
>struct rt_sigframe {
>   int sig;
> - struct siginfo *pinfo;
> + siginfo_t *pinfo;
>   void *puc;
>   char retcode[8];
> - struct siginfo info;
> + siginfo_t info;
>   struct ucontext uc;
>} *rt_ = context->cfa;
>  
> diff --git a/libgcc/config/i386/linux-unwind.h 
> b/libgcc/config/i386/linux-unwind.h
> index f17a46c..33810c5 100644
> --- a/libgcc/config/i386/linux-unwind.h
> +++ b/libgcc/

Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

2012-03-27 Thread Eric Botcazou
> I see.  Though the code does not affect layout but only access "layout"
> for bitfields.  I'm fine with fixing the issues we run into elsewhere,
> just the langhook is a possibility I had in mind from the start, in
> case frontends differ in their memory model for bitfields.

Understood.  According to our internal testing, the issue we're discussing was 
the last problem introduced by the bitfield change, and I think that using the 
C/C++ model for C/C++-compatible bit fields is fine for GNAT.

May I apply the patch I posted?  It boostrapped/regtested fine on x86-64/Linux.

-- 
Eric Botcazou


Re: [Patch V2] libgfortran: do not assume libm

2012-03-27 Thread Janne Blomqvist
On Tue, Mar 27, 2012 at 11:01, Tristan Gingold  wrote:
> Hi,
>
> this patch fixes this issue.  Is it OK ?

Ok.

> Maybe we should include the AC_DEFINE action within GCC_CHECK_MATH_FUNC.  
> Will try to do that.

That looks like a cleaner solution, yes, and less chance for typos to sneak in.

> Sorry for not having noticed this issue before.

No problem. Thanks for fixing it quickly.

-- 
Janne Blomqvist


Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

2012-03-27 Thread Richard Guenther
On Tue, 27 Mar 2012, Eric Botcazou wrote:

> > I see.  Though the code does not affect layout but only access "layout"
> > for bitfields.  I'm fine with fixing the issues we run into elsewhere,
> > just the langhook is a possibility I had in mind from the start, in
> > case frontends differ in their memory model for bitfields.
> 
> Understood.  According to our internal testing, the issue we're discussing 
> was 
> the last problem introduced by the bitfield change, and I think that using 
> the 
> C/C++ model for C/C++-compatible bit fields is fine for GNAT.
> 
> May I apply the patch I posted?  It boostrapped/regtested fine on 
> x86-64/Linux.

Yes.

Thanks,
Richard.


[PATCH, PR 52693] Do not construct memory accesses to unscalarizable regions

2012-03-27 Thread Martin Jambor
Hi,

this fixes a thinko that leads to wrong-code generation that is in the
"new" SRA since the beginning.  When there are two unscalarizable
regions in an access tree, one within another, the aggregate
assignment modification code may use them as basis of new memory
accesses, which means it very likely ignores an array reference along
the way.  Using such a region in the code path is useless anyway since
by its nature there cannot be any replacements there.

This is a patch for trunk (on which it has passed bootstrap and
testing on x86_64-linux) and the 4.7 branch, I'm in the process of
testing equivalents for the 4.5 and 4.6 branches (the diff contexts
differ slightly).  OK for everywhere if all tests pass?

Thanks,

Martin


2012-03-24  Martin Jambor  

PR middle-end/52693
* tree-sra.c (sra_modify_assign): Do not call
load_assign_lhs_subreplacements when working with an unscalarizable
region.

* testsuite/gcc.dg/torture/pr52693.c: New test.


Index: src/gcc/tree-sra.c
===
--- src.orig/gcc/tree-sra.c
+++ src/gcc/tree-sra.c
@@ -3071,7 +3071,13 @@ sra_modify_assign (gimple *stmt, gimple_
 }
   else
 {
-  if (access_has_children_p (lacc) && access_has_children_p (racc))
+  if (access_has_children_p (lacc)
+ && access_has_children_p (racc)
+ /* When an access represents an unscalarizable region, it usually
+represents accesses with variable offset and thus must not be used
+to generate new memory accesses.  */
+ && !lacc->grp_unscalarizable_region
+ && !racc->grp_unscalarizable_region)
{
  gimple_stmt_iterator orig_gsi = *gsi;
  enum unscalarized_data_handling refreshed;
Index: src/gcc/testsuite/gcc.dg/torture/pr52693.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/torture/pr52693.c
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+
+struct pair
+{
+  int x;
+  int y;
+};
+
+struct array
+{
+  struct pair elems[ 2 ];
+  unsigned index;
+};
+
+extern void abort ();
+
+void __attribute__ ((noinline,noclone))
+test_results (int x1, int y1, int x2, int y2)
+{
+  if (x1 != x2 || y1 != y2)
+abort ();
+}
+
+int
+main (void)
+{
+  struct array arr = {{{1,2}, {3,4}}, 1};
+  struct pair last = arr.elems[arr.index];
+
+  test_results ( last.x, last.y, arr.elems[1].x, arr.elems[1].y);
+
+  return 0;
+}


[v3] fix std::result_of support for cv-quals

2012-03-27 Thread Jonathan Wakely
This fixes a couple of bugs I noticed in std::result_of, the first new
test covers those bugs, the second new test is just taken from the
standard to test result_of a little more thoroughly.

* include/std/type_traits (result_of): Fix handling of cv-quals.
* testsuite/20_util/result_of/1.cc: New.
* testsuite/20_util/result_of/2.cc: New.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line numbers.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

Tested x86_64-linux, committed to trunk.
commit 49b07e4ef78b549dcca253c276af2b2ba8d41f88
Author: Jonathan Wakely 
Date:   Tue Mar 27 02:58:51 2012 +0100

* include/std/type_traits (result_of): Fix handling of cv-quals.
* testsuite/20_util/result_of/1.cc: New.
* testsuite/20_util/result_of/2.cc: New.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line numbers.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index e3ec7ad..4102263 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1,6 +1,7 @@
 // C++11 type_traits -*- C++ -*-
 
-// Copyright (C) 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
+// Copyright (C) 2007, 2008, 2009, 2010, 2011, 2012
+// Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -1794,6 +1795,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
static _Tp _S_get(const _Class&);
   template
+   static _Tp _S_get(const volatile _Class&);
+  template
static decltype(*std::declval<_Tp>()) _S_get(...);
 
 public:
@@ -1814,6 +1817,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
static _Tp _S_get(const _Class&);
   template
+   static _Tp _S_get(const volatile _Class&);
+  template
static decltype(*std::declval<_Tp>()) _S_get(...);
 
 public:
@@ -1836,22 +1841,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 struct _Result_of_impl
-: _Result_of_memobj::type, _Arg>
-{
-  typedef typename _Result_of_memobj<
-   typename remove_reference<_MemPtr>::type, _Arg>::__type
-   __type;
-};
+: _Result_of_memobj::type, _Arg>
+{ };
 
   template
 struct _Result_of_impl
-: _Result_of_memfun::type, _Arg,
-_ArgTypes...>
-{
-  typedef typename _Result_of_memfun<
-   typename remove_reference<_MemPtr>::type, _Arg, _ArgTypes...>::__type
-   __type;
-};
+: _Result_of_memfun::type, _Arg, _ArgTypes...>
+{ };
 
   template
 struct result_of<_Functor(_ArgTypes...)>
diff --git a/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc 
b/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
index 298e93e..eafbe5f 100644
--- a/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
@@ -19,7 +19,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-error "static assertion failed" "" { target *-*-* } 1776 }
+// { dg-error "static assertion failed" "" { target *-*-* } 1777 }
 
 #include 
 
diff --git 
a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc 
b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
index d2ebf16..6358d72 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
@@ -48,5 +48,5 @@ void test01()
 // { dg-error "required from here" "" { target *-*-* } 40 }
 // { dg-error "required from here" "" { target *-*-* } 42 }
 
-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1565 }
-// { dg-error "declaration of" "" { target *-*-* } 1529 }
+// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1566 }
+// { dg-error "declaration of" "" { target *-*-* } 1530 }
diff --git 
a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc 
b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
index c0ef55b..d9a0f17 100644
--- a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
@@ -48,5 +48,5 @@ void test01()
 // { dg-error "required from here" "" { target *-*-* } 40 }
 // { dg-error "required from here" "" { target *-*-* } 42 }
 
-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1483 

Re: [PATCH, PR 52693] Do not construct memory accesses to unscalarizable regions

2012-03-27 Thread Richard Guenther
On Tue, 27 Mar 2012, Martin Jambor wrote:

> Hi,
> 
> this fixes a thinko that leads to wrong-code generation that is in the
> "new" SRA since the beginning.  When there are two unscalarizable
> regions in an access tree, one within another, the aggregate
> assignment modification code may use them as basis of new memory
> accesses, which means it very likely ignores an array reference along
> the way.  Using such a region in the code path is useless anyway since
> by its nature there cannot be any replacements there.
> 
> This is a patch for trunk (on which it has passed bootstrap and
> testing on x86_64-linux) and the 4.7 branch, I'm in the process of
> testing equivalents for the 4.5 and 4.6 branches (the diff contexts
> differ slightly).  OK for everywhere if all tests pass?

Ok.

Thanks,
Richard.

> Thanks,
> 
> Martin
> 
> 
> 2012-03-24  Martin Jambor  
> 
>   PR middle-end/52693
>   * tree-sra.c (sra_modify_assign): Do not call
>   load_assign_lhs_subreplacements when working with an unscalarizable
>   region.
> 
>   * testsuite/gcc.dg/torture/pr52693.c: New test.
> 
> 
> Index: src/gcc/tree-sra.c
> ===
> --- src.orig/gcc/tree-sra.c
> +++ src/gcc/tree-sra.c
> @@ -3071,7 +3071,13 @@ sra_modify_assign (gimple *stmt, gimple_
>  }
>else
>  {
> -  if (access_has_children_p (lacc) && access_has_children_p (racc))
> +  if (access_has_children_p (lacc)
> +   && access_has_children_p (racc)
> +   /* When an access represents an unscalarizable region, it usually
> +  represents accesses with variable offset and thus must not be used
> +  to generate new memory accesses.  */
> +   && !lacc->grp_unscalarizable_region
> +   && !racc->grp_unscalarizable_region)
>   {
> gimple_stmt_iterator orig_gsi = *gsi;
> enum unscalarized_data_handling refreshed;
> Index: src/gcc/testsuite/gcc.dg/torture/pr52693.c
> ===
> --- /dev/null
> +++ src/gcc/testsuite/gcc.dg/torture/pr52693.c
> @@ -0,0 +1,33 @@
> +/* { dg-do run } */
> +
> +struct pair
> +{
> +  int x;
> +  int y;
> +};
> +
> +struct array
> +{
> +  struct pair elems[ 2 ];
> +  unsigned index;
> +};
> +
> +extern void abort ();
> +
> +void __attribute__ ((noinline,noclone))
> +test_results (int x1, int y1, int x2, int y2)
> +{
> +  if (x1 != x2 || y1 != y2)
> +abort ();
> +}
> +
> +int
> +main (void)
> +{
> +  struct array arr = {{{1,2}, {3,4}}, 1};
> +  struct pair last = arr.elems[arr.index];
> +
> +  test_results ( last.x, last.y, arr.elems[1].x, arr.elems[1].y);
> +
> +  return 0;
> +}
> 
> 

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

Re: [Patch V2] libgfortran: do not assume libm

2012-03-27 Thread Tristan Gingold

On Mar 27, 2012, at 10:38 AM, Janne Blomqvist wrote:

> On Tue, Mar 27, 2012 at 11:01, Tristan Gingold  wrote:
>> Hi,
>> 
>> this patch fixes this issue.  Is it OK ?
> 
> Ok.

No check-gfortran regressions on x86_64-darwin, committed.

>> Maybe we should include the AC_DEFINE action within GCC_CHECK_MATH_FUNC.  
>> Will try to do that.
> 
> That looks like a cleaner solution, yes, and less chance for typos to sneak 
> in.
> 
>> Sorry for not having noticed this issue before.
> 
> No problem. Thanks for fixing it quickly.

You're welcome!

Tristan.



Re: [Patch IA64]: Fix 32 bits tablejump

2012-03-27 Thread Tristan Gingold

On Mar 16, 2012, at 4:14 PM, Richard Henderson wrote:

> On 03/16/12 04:56, Tristan Gingold wrote:
>> 2012-03-16  Tristan Gingold  
>> 
>>  * config/ia64/vms.h (CASE_VECTOR_MODE): Define.
>>  * config/ia64/ia64.md: Remove mode in template.
>>  Sign extend operand in expand_simple_binop.
>>  * config/ia64/ia64.h (ASM_OUTPUT_ADDR_DIFF_ELT): Use
>>  CASE_VECTOR_MODE instead of TARGET_ILP32.
>>  (ADDR_VEC_ALIGN): Make it depends on CASE_VECTOR_MODE.
> 
> Ok.
> 

Thanks.  Committed after bootstrapping on ia64-linux (and check-gnat).

Tristan.



Re: [patch][RFC] bail out after front-end errors

2012-03-27 Thread Paolo Carlini

Hi,

On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher  wrote:

Hello,

This patch is one way to address PR44982. I see no good reason to
cgraph_finalize_compilation_unit if there were parse errors. As Richi
already pointed out, GCC traditionally has proceeded after parse
errors to preserve warnings and errors we generate from the middle-end
and during semantic analysis. But it seems to me that those warnings
are not very meaningful after parse errors (-Wuninitialized after a
parse error??), and errors from the middle end are mostly for exotic
code (involving asm()s and the like). Bailing out after parse errors
is therefore IMHO the right thing to do for the common case.

Thoughts? Comments?

Conceptually it makes sense.  Did you check whether allowing the
FE too proceed to final_write_globals but stop before
cgraph_finalize_compilation_unit
preserves any errors?  I would expect that maybe FE global variable
diagostics are defered until that?  It would be nice to finally move
the call to cgraph_finalize_compilation_unit to the middle-end ...
(warning, if you try that you run into an issue with the Java frontend ... :/)
I bet it does preserve some errors. I noticed that when I analyzed a bit 
PR40405, see Comment #3 in particular.


Thanks,
Paolo.


Re: [Patch]: unwind-ia64: avoid long type

2012-03-27 Thread Tristan Gingold

On Mar 22, 2012, at 6:34 PM, Richard Henderson wrote:

> On 03/22/12 07:55, Tristan Gingold wrote:
>> 2012-03-22  Tristan Gingold  
>> 
>>  * config/ia64/unwind-ia64.h: Declare unw_word and unw_sword.
>>  (unw_table_entry): Use unw_word instead of unsigned long.
>>  (_Unwind_FindTableEntry): Likewise.
>>  * config/ia64/fde-glibc.c (_Unwind_FindTableEntry): Likewise.
>>  * config/ia64/fde-vms.c (vms_unwtable_entry): Likewise.
>>  (_Unwind_FindTableEntry): Likewise.
>>  * config/ia64/unwind-ia64.c (unw_reg_info, unw_reg_state)
>>  (unw_labeled_state, unw_state_record, unw_stack, _Uwind_Context)
>>  (set_reg, alloc_spill_area, finish_prologue, ia64_rse_slot_num)
>>  (ia64_rse_is_rnat_slot, ia64_rse_rnat_addr, ia64_rse_num_regs)
>>  (ia64_rse_skip_regs, ia64_copy_rbs, unw_access_gr)
>>  (uw_frame_state_for, uw_update_reg_address, uw_update_context)
>>  (uw_init_context_1, uw_install_context): Likewise.
>>  (unw_word): Move to unwind-ia64.h
> 
> Ok.

Thanks, committed after bootstrapping on ia64-linux, and without regressions 
for check-gnat.

Tristan.



Re: [SH] PR 50751 - rework displacement calculations

2012-03-27 Thread Kaz Kojima
Oleg Endo  wrote:
> The attached patch generalizes the move insn displacement calculations a
> little bit.  Before, the same address rebasing code was present in
> sh_legitimize_address as well as sh_legitimize_reload_address.  I've
> pulled those out into a separate function as a preparation step for
> adding HImode displacement addressing support.
> 
> Tested by doing 'make all' (c,c++), compiling newlib and by making sure
> that for the following variants the CSiBE set code size did not change:
> 
> -m2a-single -mb -O2, -m2a-single -mb -Os,
> -m4a-single -mb -O2, -m4a-single -mb -Os,
> -m4a-single -ml -O2, -m4a-single -ml -Os,
> -m4-single -mb -O2, -m4-single -mb -Os,
> -m4-single -ml -O2, -m4-single -ml -Os
> 
> I'm now also running the usual reg tests on sh-sim, just in case.
> Other than that, OK?

OK with removing the first hunk

> @@ -9663,10 +9663,12 @@
>  {
>if (MAYBE_BASE_REGISTER_RTX_P (x, strict))
>  return true;
> +
>else if ((GET_CODE (x) == POST_INC || GET_CODE (x) == PRE_DEC)
>  && ! TARGET_SHMEDIA
>  && MAYBE_BASE_REGISTER_RTX_P (XEXP (x, 0), strict))
>  return true;
> +
>else if (GET_CODE (x) == PLUS
>  && (mode != PSImode || reload_completed))
>  {

which adds extra empty lines.

Regards,
kaz


Re: [PATCH][SH] PR52667, Fix for barrier insertion

2012-03-27 Thread Kaz Kojima
Chung-Lin Tang  wrote:
> This patch fixes a case in sh.c:find_barrier(), triggered by a testcase
> in glibc. The scanning starts from a GOT move instruction, records
> itself in 'last_got', but does not find a second GOT move (to reset
> last_got to NULL).
> 
> It finishes by trying to insert a new barrier in the insn stream, sees
> last_got != NULL, and tries to insert at PREV_INSN(last_got), which goes
> above the original start insn.
> 
> The caller, sh_reorg(), then gets the barrier scan target above the orig
> insn, tries (in vain) to find it using a forward scan, and segfaults
> when it goes past the insn stream...
> 
> The attached patch adds an additional equality check, plus some comment
> updates. Cross-tested without regressions, is this okay for trunk?

OK.  Thanks for catching this!

Regards,
kaz


[Patch ARM] Cleanup test runs -

2012-03-27 Thread Ramana Radhakrishnan
Hi,

I noticed that the tests were failing in ARM mode. Fixed thusly as
these tests are only meant to be run for Thumb state.

Committed to trunk.

regards.
Ramana

2012-03-27  Ramana Radhakrishnan  

* gcc.target/arm/thumb-ifcvt.c: Only run for -mthumb.
* gcc.target/arm/thumb-16bit-ops.c: Likewise.
Index: gcc/testsuite/gcc.target/arm/thumb-16bit-ops.c
===
--- gcc/testsuite/gcc.target/arm/thumb-16bit-ops.c  (revision 185854)
+++ gcc/testsuite/gcc.target/arm/thumb-16bit-ops.c  (working copy)
@@ -1,7 +1,7 @@
 /* Check that the compiler properly uses 16-bit encodings where available.  */
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_thumb2_ok } */
-/* { dg-options "-Os -fno-builtin" } */
+/* { dg-options "-Os -fno-builtin -mthumb" } */
 
 int
 f (int a, int b )
Index: gcc/testsuite/gcc.target/arm/thumb-ifcvt.c
===
--- gcc/testsuite/gcc.target/arm/thumb-ifcvt.c  (revision 185854)
+++ gcc/testsuite/gcc.target/arm/thumb-ifcvt.c  (working copy)
@@ -1,7 +1,7 @@
 /* Check that Thumb 16-bit shifts can be if-converted.  */
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_thumb2_ok } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -mthumb" } */
 
 int
 foo (int a, int b)


[Patch,avr] PR51345: Restore -mtiny-stack semantics

2012-03-27 Thread Georg-Johann Lay
This patch fixes a problem with the -mtiny-stack option:

Architectures avr2 and avr25 mix targets with 8-bit SP and 16-bit SP so that
-mtiny-stack is no good for multilib selection:

If a frame pointer has to be set up from an 8-bit SP it is a difference if
there is no SP_H or of the SP is just treated as if it was 8 bits wide.

In the first case the high byte must be set to 0. In the second case SP_H can
be read.

That is: The patch uses the size of hard SP for multilib selection and
generation. The user-settable -mtiny-stack is used for size of soft SP for
optimization purposes, but does not influence multilib selection or generation
or how FP is deduced from SP.

Notable changes are:

-mtiny-stack is no more a multilib option and its semantics restored as was
before PR51345 introduced multilibs for 8-bit SP targets.

Multilib selection is performed by a new undocumented option -msp8. This option
is only used internally and need not to be specified on the command line. -msp8
is injected by DRIVER_SELF_SPECS as needed.

There is no avr-specific multilib_raw[] needed any more. This turns
genmultilib.awk considerably more easy and better to maintain. Much code could
be kicked off.

-print-multi-lib results are clean now. With the prior approach,
-print-multi-lib printed phantom configurations like

tiny-stack;@mmcu=at90s2313
avr25/tiny-stack;@mmcu=attiny13

which could confuse libc implementations like newlib or AVR-Libc during their
configure stage as they evaluate -print-multilib-lib.

Now -print-multi-lib yields

.;
avr25;@mmcu=avr25
avr3;@mmcu=avr3
avr31;@mmcu=avr31
avr35;@mmcu=avr35
avr4;@mmcu=avr4
avr5;@mmcu=avr5
avr51;@mmcu=avr51
avr6;@mmcu=avr6
avrxmega2;@mmcu=avrxmega2
avrxmega4;@mmcu=avrxmega4
avrxmega5;@mmcu=avrxmega5
avrxmega6;@mmcu=avrxmega6
avrxmega7;@mmcu=avrxmega7
tiny-stack;@msp8
avr25/tiny-stack;@mmcu=avr25@msp8

which is perfect and clean. As you can see, the multilib directory structure is
/unchanged/ i.e. their names are still
./avr25/tiny-stack
etc.

Ok for trunk?

Johann

PR target/52737
* contrib/gcc_update (files_and_dependencies):
Remove gcc/config/avr/t-multilib from touch data.

gcc/
PR target/52737
* config.gcc (tm_file): Remove avr/multilib.h.

* doc/invoke.texi (AVR Options): Adjust
documentation of -mtiny-stack.

* config/avr/genmultilib.awk: Remove code to generate multilib.h.
(BEGIN): Use -msp8 as multilib option instead of -mtiny-stack.
* config/avr/t-avr: Remove generation of multilib.h.
* config/avr/t-multilib: Regenerate.
* config/avr/multilib.h: Remove.
* config/avr/avr.opt (-msp8): New option.
(avr_sp8): New variable.
* config/avr/driver-avr.c (avr_device_to_sp8): New function.
* config/avr/avr.h (AVR_HAVE_SPH): New define.
(AVR_HAVE_8BIT_SP): Also set by avr_sp8 i.e. -msp8.
(avr_device_to_sp8): New prototype.
(EXTRA_SPEC_FUNCTIONS): Add { "device_to_sp8", avr_device_to_sp8 }
(DRIVER_SELF_SPECS): New define.
* config/avr/avr-c.c (avr_cpu_cpp_builtins): New built-in defines:
__AVR_SP8__, __AVR_HAVE_SPH__.
* config/avr/avr.c (output_movhi): Use AVR_HAVE_SPH instead of
AVR_HAVE_8BIT_SP to decide if SP_H is present.
(avr_file_start): Ditto.

libgcc/
PR target/52737
* config/avr/lib1funcs.S: Use __AVR_HAVE_SPH__ for SP_H checks
instead of __AVR_HAVE_8BIT_SP__.



Index: contrib/gcc_update
===
--- contrib/gcc_update	(revision 185858)
+++ contrib/gcc_update	(working copy)
@@ -83,7 +83,6 @@ gcc/config/arm/arm-tune.md: gcc/config/a
 gcc/config/arm/arm-tables.opt: gcc/config/arm/arm-arches.def gcc/config/arm/arm-cores.def gcc/config/arm/arm-fpus.def gcc/config/arm/genopt.sh
 gcc/config/avr/avr-tables.opt: gcc/config/avr/avr-mcus.def gcc/config/avr/genopt.sh
 gcc/config/avr/t-multilib: gcc/config/avr/avr-mcus.def gcc/config/avr/genmultilib.awk
-gcc/config/avr/multilib.h: gcc/config/avr/avr-mcus.def gcc/config/avr/genmultilib.awk
 gcc/config/c6x/c6x-tables.opt: gcc/config/c6x/c6x-isas.def gcc/config/c6x/genopt.sh
 gcc/config/c6x/c6x-sched.md: gcc/config/c6x/c6x-sched.md.in gcc/config/c6x/gensched.sh
 gcc/config/c6x/c6x-mult.md: gcc/config/c6x/c6x-mult.md.in gcc/config/c6x/genmult.sh
Index: gcc/config.gcc
===
--- gcc/config.gcc	(revision 185858)
+++ gcc/config.gcc	(working copy)
@@ -898,13 +898,13 @@ arm*-wince-pe*)
 	extra_objs="pe.o"
 	;;
 avr-*-rtems*)
-	tm_file="elfos.h avr/elf.h avr/avr.h avr/multilib.h dbxelf.h avr/rtems.h rtems.h newlib-stdint.h"
+	tm_file="elfos.h avr/elf.h avr/avr.h dbxelf.h avr/rtems.h rtems.h newlib-stdint.h"
 	tmake_file="avr/t-avr avr/t-multilib t-rtems avr/t-rtems"
 	extra_gcc_objs="driver-avr.o avr-devices.o"
 	extra_objs="avr-devices.o avr-log.o"
 	;;
 avr-*-*)
-	tm_file="elfos.h av

Re: struct siginfo vs. siginfo_t

2012-03-27 Thread Ian Lance Taylor
Thomas Schwinge  writes:

> libgcc/
>   * config/alpha/linux-unwind.h (alpha_fallback_frame_state): Use
>   siginfo_t instead of struct siginfo.
>   * config/bfin/linux-unwind.h (bfin_fallback_frame_state): Likewise.
>   * config/i386/linux-unwind.h (x86_fallback_frame_state): Likewise.
>   * config/ia64/linux-unwind.h (ia64_fallback_frame_state)
>   (ia64_handle_unwabi): Likewise.
>   * config/mips/linux-unwind.h (mips_fallback_frame_state): Likewise.
>   * config/pa/linux-unwind.h (pa32_fallback_frame_state): Likewise.
>   * config/sh/linux-unwind.h (shmedia_fallback_frame_state)
>   (sh_fallback_frame_state): Likewise.
>   * config/tilepro/linux-unwind.h (tile_fallback_frame_state): Likewise.
>   * config/xtensa/linux-unwind.h (xtensa_fallback_frame_state): Likewise.

This is OK for mainline and release branches.

Thanks.

Ian


[PATCH] Fix PR52720

2012-03-27 Thread Richard Guenther

This fixes PR52720.

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

Richard.

2012-03-27  Richard Guenther  

PR middle-end/52720
* fold-const.c (try_move_mult_to_index): Handle &x.array more
explicitely.

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

Index: gcc/fold-const.c
===
*** gcc/fold-const.c(revision 185725)
--- gcc/fold-const.c(working copy)
*** try_move_mult_to_index (location_t loc,
*** 6850,6913 
s = integer_one_node;
  }
  
!   for (;; ref = TREE_OPERAND (ref, 0))
  {
!   if (TREE_CODE (ref) == ARRAY_REF)
!   {
! tree domain;
  
! /* Remember if this was a multi-dimensional array.  */
! if (TREE_CODE (TREE_OPERAND (ref, 0)) == ARRAY_REF)
!   mdim = true;
  
! domain = TYPE_DOMAIN (TREE_TYPE (TREE_OPERAND (ref, 0)));
! if (! domain)
!   continue;
! itype = TREE_TYPE (domain);
  
! step = array_ref_element_size (ref);
! if (TREE_CODE (step) != INTEGER_CST)
!   continue;
  
! if (s)
!   {
! if (! tree_int_cst_equal (step, s))
! continue;
!   }
! else
!   {
! /* Try if delta is a multiple of step.  */
! tree tmp = div_if_zero_remainder (EXACT_DIV_EXPR, op1, step);
! if (! tmp)
!   continue;
! delta = tmp;
!   }
  
! /* Only fold here if we can verify we do not overflow one
!dimension of a multi-dimensional array.  */
! if (mdim)
!   {
! tree tmp;
  
! if (TREE_CODE (TREE_OPERAND (ref, 1)) != INTEGER_CST
! || !TYPE_MAX_VALUE (domain)
! || TREE_CODE (TYPE_MAX_VALUE (domain)) != INTEGER_CST)
!   continue;
  
! tmp = fold_binary_loc (loc, PLUS_EXPR, itype,
!fold_convert_loc (loc, itype,
!  TREE_OPERAND (ref, 1)),
!fold_convert_loc (loc, itype, delta));
! if (!tmp
! || TREE_CODE (tmp) != INTEGER_CST
! || tree_int_cst_lt (TYPE_MAX_VALUE (domain), tmp))
!   continue;
!   }
  
! break;
!   }
!   else if (TREE_CODE (ref) == COMPONENT_REF
!  && TREE_CODE (TREE_TYPE (ref)) == ARRAY_TYPE)
{
  tree domain;
  
--- 6850,6930 
s = integer_one_node;
  }
  
!   /* Handle &x.array the same as we would handle &x.array[0].  */
!   if (TREE_CODE (ref) == COMPONENT_REF
!   && TREE_CODE (TREE_TYPE (ref)) == ARRAY_TYPE)
  {
!   tree domain;
  
!   /* Remember if this was a multi-dimensional array.  */
!   if (TREE_CODE (TREE_OPERAND (ref, 0)) == ARRAY_REF)
!   mdim = true;
! 
!   domain = TYPE_DOMAIN (TREE_TYPE (ref));
!   if (! domain)
!   goto cont;
!   itype = TREE_TYPE (domain);
! 
!   step = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (ref)));
!   if (TREE_CODE (step) != INTEGER_CST)
!   goto cont;
  
!   if (s)
!   {
! if (! tree_int_cst_equal (step, s))
!   goto cont;
!   }
!   else
!   {
! /* Try if delta is a multiple of step.  */
! tree tmp = div_if_zero_remainder (EXACT_DIV_EXPR, op1, step);
! if (! tmp)
!   goto cont;
! delta = tmp;
!   }
  
!   /* Only fold here if we can verify we do not overflow one
!dimension of a multi-dimensional array.  */
!   if (mdim)
!   {
! tree tmp;
  
! if (!TYPE_MIN_VALUE (domain)
! || !TYPE_MAX_VALUE (domain)
! || TREE_CODE (TYPE_MAX_VALUE (domain)) != INTEGER_CST)
!   goto cont;
! 
! tmp = fold_binary_loc (loc, PLUS_EXPR, itype,
!fold_convert_loc (loc, itype,
!  TYPE_MIN_VALUE (domain)),
!fold_convert_loc (loc, itype, delta));
! if (TREE_CODE (tmp) != INTEGER_CST
! || tree_int_cst_lt (TYPE_MAX_VALUE (domain), tmp))
!   goto cont;
!   }
  
!   /* We found a suitable component reference.  */
  
!   pref = TREE_OPERAND (addr, 0);
!   ret = copy_node (pref);
!   SET_EXPR_LOCATION (ret, loc);
  
!   ret = build4_loc (loc, ARRAY_REF, TREE_TYPE (TREE_TYPE (ref)), ret,
!   fold_build2_loc
! (loc, PLUS_EXPR, itype,
!  fold_convert_loc (loc, itype,
!TYPE_MIN_VALUE
!  (TYPE_DOMAIN (TREE_TYPE (ref,
!  fold_convert_loc (loc, itype, delta)),
!   NULL_TREE, NULL_TREE);
! 

[RFC ivopts] ARM - Make ivopts take into account whether pre and post increments are actually supported on targets.

2012-03-27 Thread Ramana Radhakrishnan
Hi,

One of the problems with ivopts is that the auto-increment modelling
just takes into account whether HAVE_PRE_INC and friends are defined
for the architecture. However on ARM the VFP addressing modes don't
really support PRE_INCREMENT and POST_DECREMENT forms and hence there
is a bias in ivopts to prefer pre-increment forms over all-else. The
attached patch attempts to fix this - in general it makes things
better on ARM where a large number of cases where we have rather
embarassing code generation around array accesses of floating point
values where to honor this choice of auto-increment forms the compiler
is forced to move things back and forth between floating point and
integer registers and all other such cases.

The canonical example for this is

 void foo (float *x , float *y, float *z, float *m, int l)
   {
  int i;
  for (i = 0; i < l ; i++)
  {
z[i] = x[i] * y[i] + m[i];
  }
   }

 sub r0, r0, #4
 sub r1, r1, #4
 sub r3, r3, #4
 add ip, r2, ip, asl #2
.L3:
 add r3, r3, #4
 add r0, r0, #4
 flds s15, [r3, #0]
 flds s13, [r0, #0]
 add r1, r1, #4
 flds s14, [r1, #0]
 fmacs s15, s13, s14
 mov r4, r3
 fstmias r2!, {s15}
 cmp r2, ip
 bne .L3
.L1:
 ldmfd sp!, {r4}
 bx lr

and after we generate :

foo:
 @ args = 4, pretend = 0, frame = 0
 @ frame_needed = 0, uses_anonymous_args = 0
 @ link register save eliminated.
 ldr ip, [sp, #0]
 cmp ip, #0
 bxle lr
 add ip, r0, ip, asl #2
.L3:
 fldmias r0!, {s13}
 fldmias r1!, {s14}
 fldmias r3!, {s15}
 fmacs s15, s13, s14
 cmp r0, ip
 fstmias r2!, {s15}
 bne .L3
 bx lr


In general , ivopts could do with some TLC in this area - looking at
the code generated for most of SPEC2k, I see a general improvement in
performance on an A9 board with a large number of cases of transfers
back and forth between VFP and integer registers much reduced (in one
case mgrid I saw up to a 6% improvement in performance in mgrid , 3%
in facerec) and overall upto a 1% improvement when this patch was
applied to the Linaro 4.6 tree - looking at object files with the same
patch applied on FSF trunk I see similar transformations as the 4.6
tree. I see some funny behaviour with twolf where there is noise in
the results and I'm not confident of that particular result -

In the interest of full disclosure here while looking at mgrid I
noticed a few cases where we were moving values more from integer to
the VFP side but overall I think this patch benefits more than harms .
These appeared to be around the areas where a floating point array was
being zero initialized. Given the VFP instruction set doesn't really
have a zero initializer form we were moving the value 0 into integer
registers, moving the value into a VFP register rather than just
choosing the integer side register store - I am not yet sure why that
is happening and that's somethiing I'm investigating. Before that , I
wanted some feedback on this patch as it stands today as I believe
it's reached a stage where it appears to be performing reasonably
well.

I did experiment with costs and in general trying to turn off these
auto-increment forms for the FP modes when we are not in soft-float
mode but nothing appeared to behave as well as this attached patch.

Thoughts and comments would be welcome. I don't know of any other
architectures where this will be applicable.

Regards,
Ramana


gcc/

* tree-ssa-loop-ivopts.c (add_autoinc_candidates, get_address_cost):
Replace use of HAVE_{POST/PRE}_{INCREMENT/DECREMENT} with
USE_{LOAD/STORE}_{PRE/POST}_{INCREMENT/DECREMENT} appropriately.
* config/arm/arm.h (ARM_AUTOINC_VALID_FOR_MODE_P): New.
(USE_LOAD_POST_INCREMENT): Define.
(USE_LOAD_PRE_INCREMENT): Define.
(USE_LOAD_POST_DECREMENT): Define.
(USE_LOAD_PRE_DECREMENT): Define.
(USE_STORE_PRE_DECREMENT): Define.
(USE_STORE_PRE_INCREMENT): Define.
(USE_STORE_POST_DECREMENT): Define.
(USE_STORE_POST_INCREMENT): Define.
(ARM_POST_INC): Define.
(ARM_PRE_INC): Define.
(ARM_PRE_DEC): Define.
(ARM_POST_DEC): Define.
* config/arm/arm-protos.h (arm_autoinc_modes_ok_p): Declare.
* config/arm/arm.c (arm_autoinc_modes_ok_p): Define.


Re: [RFC ivopts] ARM - Make ivopts take into account whether pre and post increments are actually supported on targets.

2012-03-27 Thread Ramana Radhakrishnan
And the patch is now attached 

Ramana
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 900d09a..6e82fb0 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -247,5 +247,5 @@ extern int vfp3_const_double_for_fract_bits (rtx);
 
 extern void arm_expand_vec_perm (rtx target, rtx op0, rtx op1, rtx sel);
 extern bool arm_expand_vec_perm_const (rtx target, rtx op0, rtx op1, rtx sel);
-
+extern bool arm_autoinc_modes_ok_p (enum machine_mode, int);
 #endif /* ! GCC_ARM_PROTOS_H */
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 9af66dd..31d6d9f 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -25652,5 +25652,40 @@ arm_vectorize_vec_perm_const_ok (enum machine_mode 
vmode,
   return ret;
 }
 
+bool
+arm_autoinc_modes_ok_p (enum machine_mode mode, int code)
+{
+  if (TARGET_SOFT_FLOAT)
+return true;
+
+  switch (code)
+{
+case ARM_POST_INC:
+case ARM_PRE_DEC:
+  if (VECTOR_MODE_P (mode))
+   {
+ if (code != PRE_DEC)
+   return true;
+ else 
+   return false;
+   }
+  
+  return true;
+
+case ARM_POST_DEC:
+case ARM_PRE_INC:
+  if (FLOAT_MODE_P (mode) || VECTOR_MODE_P (mode))
+   return false;
+  else
+   return true;
+ 
+default:
+  return false;
+  
+}
+
+  return false;
+}
+
 
 #include "gt-arm.h"
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 443d2ed..2e4f3a0 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1623,6 +1623,27 @@ typedef struct
 #define HAVE_PRE_MODIFY_REG   TARGET_32BIT
 #define HAVE_POST_MODIFY_REG  TARGET_32BIT
 
+#define ARM_POST_INC 0
+#define ARM_PRE_INC  1
+#define ARM_POST_DEC 2
+#define ARM_PRE_DEC  3
+
+#define ARM_AUTOINC_VALID_FOR_MODE_P(mode, code) \
+  (TARGET_32BIT && arm_autoinc_modes_ok_p (mode, code))
+#define USE_LOAD_POST_INCREMENT(mode) \
+  ARM_AUTOINC_VALID_FOR_MODE_P(mode, ARM_POST_INC)
+#define USE_LOAD_PRE_INCREMENT(mode)  \
+  ARM_AUTOINC_VALID_FOR_MODE_P(mode, ARM_PRE_INC)
+#define USE_LOAD_POST_DECREMENT(mode) \
+  ARM_AUTOINC_VALID_FOR_MODE_P(mode, ARM_POST_DEC)
+#define USE_LOAD_PRE_DECREMENT(mode)  \
+  ARM_AUTOINC_VALID_FOR_MODE_P(mode, ARM_PRE_DEC)
+
+#define USE_STORE_PRE_DECREMENT(mode) USE_LOAD_PRE_DECREMENT(mode)
+#define USE_STORE_PRE_INCREMENT(mode) USE_LOAD_PRE_INCREMENT(mode)
+#define USE_STORE_POST_DECREMENT(mode) USE_LOAD_POST_DECREMENT(mode)
+#define USE_STORE_POST_INCREMENT(mode) USE_LOAD_POST_INCREMENT(mode)
+
 /* Macros to check register numbers against specific register classes.  */
 
 /* These assume that REGNO is a hard or pseudo reg number.
diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 527c911..ac37608 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -2361,8 +2361,12 @@ add_autoinc_candidates (struct ivopts_data *data, tree 
base, tree step,
   cstepi = int_cst_value (step);
 
   mem_mode = TYPE_MODE (TREE_TYPE (*use->op_p));
-  if ((HAVE_PRE_INCREMENT && GET_MODE_SIZE (mem_mode) == cstepi)
-  || (HAVE_PRE_DECREMENT && GET_MODE_SIZE (mem_mode) == -cstepi))
+  if (((USE_LOAD_PRE_INCREMENT (mem_mode)
+   || USE_STORE_PRE_INCREMENT (mem_mode))
+   && GET_MODE_SIZE (mem_mode) == cstepi)
+  || ((USE_LOAD_PRE_DECREMENT (mem_mode)
+  || USE_STORE_PRE_DECREMENT (mem_mode))
+ && GET_MODE_SIZE (mem_mode) == -cstepi))
 {
   enum tree_code code = MINUS_EXPR;
   tree new_base;
@@ -2379,8 +2383,12 @@ add_autoinc_candidates (struct ivopts_data *data, tree 
base, tree step,
   add_candidate_1 (data, new_base, step, important, IP_BEFORE_USE, use,
   use->stmt);
 }
-  if ((HAVE_POST_INCREMENT && GET_MODE_SIZE (mem_mode) == cstepi)
-  || (HAVE_POST_DECREMENT && GET_MODE_SIZE (mem_mode) == -cstepi))
+  if (((USE_LOAD_POST_INCREMENT (mem_mode)
+   || USE_STORE_POST_INCREMENT (mem_mode))
+   && GET_MODE_SIZE (mem_mode) == cstepi)
+  || ((USE_LOAD_POST_DECREMENT (mem_mode)
+  || USE_STORE_POST_DECREMENT (mem_mode))
+ && GET_MODE_SIZE (mem_mode) == -cstepi))
 {
   add_candidate_1 (data, base, step, important, IP_AFTER_USE, use,
   use->stmt);
@@ -3314,25 +3322,29 @@ get_address_cost (bool symbol_present, bool var_present,
   reg0 = gen_raw_REG (address_mode, LAST_VIRTUAL_REGISTER + 1);
   reg1 = gen_raw_REG (address_mode, LAST_VIRTUAL_REGISTER + 2);
 
-  if (HAVE_PRE_DECREMENT)
+  if (USE_LOAD_PRE_DECREMENT (mem_mode) 
+ || USE_STORE_PRE_DECREMENT (mem_mode))
{
  addr = gen_rtx_PRE_DEC (address_mode, reg0);
  has_predec[mem_mode]
= memory_address_addr_space_p (mem_mode, addr, as);
}
-  if (HAVE_POST_DECREMENT)
+  if (USE_LOAD_POST_DECREMENT (mem_mode) 
+ || USE_STORE_POST_DECREMENT (mem_mode))
{
  addr = gen_rtx_POST_DEC (address_mode, reg0);
  has_postd

New Swedish PO file for 'gcc' (version 4.7.0)

2012-03-27 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-4.7.0.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.




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

2012-03-27 Thread Ilya Enkovich
Ping

13 марта 2012 г. 15:13 пользователь Ilya Enkovich
 написал:
> Ping
>
> 27 февраля 2012 г. 6:41 пользователь Ilya Enkovich
>  написал:
>>> You should keep those *_SPEC and define them with new
>>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
>>> by other non-linux targets.  In linux.h, you undef *_SPEC
>>> before defining them.
>>>
>>>
>>> --
>>> H.J.
>>
>> Thanks for the note. Here is fixed version. Is it OK now?
>>
>> Thanks,
>> Ilya
>> --
>> 2012-02-27  Enkovich Ilya  
>>
>>        * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New.
>>        (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC.
>>        (GNU_USER_TARGET_LINK_SPEC): New.
>>        (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
>>        (GNU_USER_TARGET_MATHFILE_SPEC): New.
>>        (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC.
>>
>>        * gcc/config/i386/linux.h (CC1_SPEC): New.
>>        (LINK_SPEC): New.
>>        (LIB_SPEC): New.
>>        (STARTFILE_SPEC): New.
>>        (ENDFILE_SPEC): New.
>>
>>
>> diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
>> index 98d0a25..33ceab7 100644
>> --- a/gcc/config/i386/gnu-user.h
>> +++ b/gcc/config/i386/gnu-user.h
>> @@ -77,8 +77,11 @@ along with GCC; see the file COPYING3.  If not see
>>  #undef CPP_SPEC
>>  #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
>>
>> +#undef GNU_USER_TARGET_CC1_SPEC
>> +#define GNU_USER_TARGET_CC1_SPEC "%(cc1_cpu) %{profile:-p}"
>> +
>>  #undef CC1_SPEC
>> -#define CC1_SPEC "%(cc1_cpu) %{profile:-p}"
>> +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC
>>
>>  /* Provide a LINK_SPEC appropriate for GNU userspace.  Here we provide 
>> support
>>    for the special GCC options -static and -shared, which allow us to
>> @@ -97,22 +100,28 @@ along with GCC; see the file COPYING3.  If not see
>>   { "link_emulation", GNU_USER_LINK_EMULATION },\
>>   { "dynamic_linker", GNU_USER_DYNAMIC_LINKER }
>>
>> -#undef LINK_SPEC
>> -#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \
>> +#define GNU_USER_TARGET_LINK_SPEC \
>> +  "-m %(link_emulation) %{shared:-shared} \
>>   %{!shared: \
>>     %{!static: \
>>       %{rdynamic:-export-dynamic} \
>>       -dynamic-linker %(dynamic_linker)} \
>>       %{static:-static}}"
>>
>> +#undef LINK_SPEC
>> +#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC
>> +
>>  /* Similar to standard GNU userspace, but adding -ffast-math support.  */
>> -#undef  ENDFILE_SPEC
>> -#define ENDFILE_SPEC \
>> +#define GNU_USER_TARGET_MATHFILE_SPEC \
>>   "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
>>    %{mpc32:crtprec32.o%s} \
>>    %{mpc64:crtprec64.o%s} \
>> -   %{mpc80:crtprec80.o%s} \
>> -   %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
>> +   %{mpc80:crtprec80.o%s}"
>> +
>> +#undef  ENDFILE_SPEC
>> +#define ENDFILE_SPEC \
>> +  GNU_USER_TARGET_MATHFILE_SPEC " " \
>> +  GNU_USER_TARGET_ENDFILE_SPEC
>>
>>  /* A C statement (sans semicolon) to output to the stdio stream
>>    FILE the assembler definition of uninitialized global DECL named
>> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
>> index 73681fe..a832ddc 100644
>> --- a/gcc/config/i386/linux.h
>> +++ b/gcc/config/i386/linux.h
>> @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3.  If not see
>>
>>  #define GNU_USER_LINK_EMULATION "elf_i386"
>>  #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>> +
>> +#undef CC1_SPEC
>> +#define CC1_SPEC \
>> +  LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \
>> +                      GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC)
>> +
>> +#undef LINK_SPEC
>> +#define LINK_SPEC \
>> +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \
>> +                      GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC)
>> +
>> +#undef  LIB_SPEC
>> +#define LIB_SPEC \
>> +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \
>> +                      GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC)
>> +
>> +#undef  STARTFILE_SPEC
>> +#define STARTFILE_SPEC \
>> +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \
>> +                      ANDROID_STARTFILE_SPEC)
>> +
>> +#undef  ENDFILE_SPEC
>> +#define ENDFILE_SPEC \
>> +  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \
>> +                      GNU_USER_TARGET_ENDFILE_SPEC,     \
>> +                      GNU_USER_TARGET_MATHFILE_SPEC " " \
>> +                      ANDROID_ENDFILE_SPEC)


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

2012-03-27 Thread Ilya Enkovich
Ping

13 марта 2012 г. 15:12 пользователь Ilya Enkovich
 написал:
> Ping
>
> 27 февраля 2012 г. 6:39 пользователь Ilya Enkovich
>  написал:
>>>
>>> Undef TARGET_OS_CPP_BUILTINS and define TARGET_OS_CPP_BUILTINS
>>> in linux.h with GNU_USER_TARGET_OS_CPP_BUILTINS and
>>> ANDROID_TARGET_OS_CPP_BUILTINS.
>>>
>>>
>>> --
>>> H.J.
>>
>> Hello,
>>
>> Here is a variant with linux.h modification. Does it look fine?
>>
>> Thanks,
>> Ilya
>> --
>> 2012-02-27  Enkovich Ilya  
>>
>>        * gcc/config/i386/linux.h (TARGET_OS_CPP_BUILTINS): New.
>>
>>
>> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
>> index 73681fe..03c7b29 100644
>> --- a/gcc/config/i386/linux.h
>> +++ b/gcc/config/i386/linux.h
>> @@ -22,3 +22,12 @@ along with GCC; see the file COPYING3.  If not see
>>
>>  #define GNU_USER_LINK_EMULATION "elf_i386"
>>  #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>> +
>> +#undef TARGET_OS_CPP_BUILTINS
>> +#define TARGET_OS_CPP_BUILTINS()               \
>> +  do                                           \
>> +    {                                          \
>> +       GNU_USER_TARGET_OS_CPP_BUILTINS();      \
>> +       ANDROID_TARGET_OS_CPP_BUILTINS();       \
>> +    }                                          \
>> +  while (0)


Re: PATCH: Remove MaskExists property from option handling

2012-03-27 Thread Joseph S. Myers
On Mon, 26 Mar 2012, H.J. Lu wrote:

> The same set of macros are provided.  The only differences are the
> order of bits used and macro definitions.  I am doing a full bootstrap and
> test on Linux/x86-64.  OK for trunk if there are no regressions?

OK.

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


Re: [PATCH] GCC 4.7 and 4.8 PowerPC RTEMS

2012-03-27 Thread Sebastian Huber

On 03/09/2012 10:01 AM, Sebastian Huber wrote:

Hi,

please have a look at the attached patch. Test suite results for GCC 4.7

http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00986.html



I get the same test suite results with:

powerpc-*-eabi* | powerpc-*-rtems*)
	tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr 
rs6000/t-crtstuff t-crtstuff-pic t-fdpbit"
	extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o crtendS.o 
crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"


I have absolutely no idea what the difference is between

extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o 
ecrti.o ecrtn.o ncrti.o ncrtn.o"


and

extra_parts="$extra_parts crtbeginS.o crtendS.o crtbeginT.o ecrti.o ecrtn.o 
ncrti.o ncrtn.o"


What is the purpose of the ctrbegin.o and crtend.o?

--
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread Uros Bizjak
On Mon, Mar 26, 2012 at 9:03 PM, H.J. Lu  wrote:

>>> Attached patch fixes this situation by (partially) reloading only
>>> remaining pseudo(s), leaving UNSPEC in the address RTX.
>>>
>>> 2012-03-26  Uros Bizjak  
>>>
>>>        PR target/52698
>>>        * config/i386/i386-protos.h (ix86_legitimize_reload_address):
>>>        New prototype.
>>>        * config/i386/i386.h (LEGITIMIZE_RELOAD_ADDRESS): New define.
>>>        * config/i386/i386.c: Include reload.h.
>>>        (ix86_legitimize_reload_address): New function.
>>>
>>> testsuite/ChangeLog:
>>>
>>> 2012-03-26  Uros Bizjak  
>>>            H.J. Lu  
>>>
>>>        PR target/52698
>>>        * gcc.target/i386/pr52698.c: New test.
>>>
>>> The patch was bootstrapped and regression tested on x86_64-pc-linux-gnu 
>>> {,-m32}.
>>>
>>> Since fixing reload issues is some kind of black magic, I'd like to
>>> ask Ulrich and Richard for their opinion on this approach.
>>>
>>> H.J., can you please test this fix on x32 testsuite for both address modes?
>>>
>>
>> I am on it.
>
> There are no regressions in gcc x32 testsuite nor glibc tests for
> both address modes. But I didn't check code quality nor SPEC CPU
> performance.

This fixup should not trigger often (if at all), so there should be no
effect on performance.

So, committed.

Uros.


Re: [PATCH] GCC 4.7 and 4.8 PowerPC RTEMS

2012-03-27 Thread Andreas Schwab
Sebastian Huber  writes:

> What is the purpose of the ctrbegin.o and crtend.o?

The same as crtbeginS.o and crtendS.o, except for non-shared linking.

Andreas.

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


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread Ulrich Weigand
Uros Bizjak wrote:

> In a corner case of a reload, reload pass can generate partially
> reloaded address, where not all registers get allocated to a hard reg.
> When this address is checked with ix86_legitimate_address, it is
> rejected, since in strict mode, pseudos are not valid address
> registers. So, reload tries to legitimize following (partially
> invalid) address:
> 
>  (plus:DI (plus:DI (unspec:DI [(const_int 0 [0])] UNSPEC_TP)
>  (reg:DI 97))
> (reg:DI 2 cx))
> 
> via generic way by pushing all components into a register, forming
> (even more invalid) address that involves three registers (r8, r9 and
> rcx):
[snip]

> Since fixing reload issues is some kind of black magic, I'd like to
> ask Ulrich and Richard for their opinion on this approach.

Well, generally speaking, reload makes a lot of assumptions on how
addresses can look like; it needs to, since if a target rejects an
address as invalid as-is, reload must fix it up -- and it can do
so only by making assumptions ...

Allowing a random UNSPEC as part of valid (non-strict) addresses
makes it really impossible for reload to understand what's going
on.  Given that, I'd tend to agree that *if* you do that, you
then also have to help reload how to deal with such addresses
by providing a legitimize_reload_address hook as you did.

Now, in this particular case, there might be another option to
avoid this hassle completely:  I understand that this UNSPEC is
simply a magic marker to make the address use the fs: or gs:
segment override, right?   Now that GCC supports address spaces,
it might be possible to model fs:/gs: relative addresses instead
by using a non-standard address space ...

Bye,
Ulrich

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



Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread Uros Bizjak
On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand  wrote:

>> Since fixing reload issues is some kind of black magic, I'd like to
>> ask Ulrich and Richard for their opinion on this approach.
>
> Well, generally speaking, reload makes a lot of assumptions on how
> addresses can look like; it needs to, since if a target rejects an
> address as invalid as-is, reload must fix it up -- and it can do
> so only by making assumptions ...
>
> Allowing a random UNSPEC as part of valid (non-strict) addresses
> makes it really impossible for reload to understand what's going
> on.  Given that, I'd tend to agree that *if* you do that, you
> then also have to help reload how to deal with such addresses
> by providing a legitimize_reload_address hook as you did.
>
> Now, in this particular case, there might be another option to
> avoid this hassle completely:  I understand that this UNSPEC is
> simply a magic marker to make the address use the fs: or gs:
> segment override, right?   Now that GCC supports address spaces,
> it might be possible to model fs:/gs: relative addresses instead
> by using a non-standard address space ...

This is an interesting idea, I will look into it.

(BTW: For now, I have just committed the proposed fixup).

Thanks,
Uros.


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread H.J. Lu
On Tue, Mar 27, 2012 at 9:37 AM, Uros Bizjak  wrote:
> On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand  wrote:
>
>>> Since fixing reload issues is some kind of black magic, I'd like to
>>> ask Ulrich and Richard for their opinion on this approach.
>>
>> Well, generally speaking, reload makes a lot of assumptions on how
>> addresses can look like; it needs to, since if a target rejects an
>> address as invalid as-is, reload must fix it up -- and it can do
>> so only by making assumptions ...
>>
>> Allowing a random UNSPEC as part of valid (non-strict) addresses
>> makes it really impossible for reload to understand what's going
>> on.  Given that, I'd tend to agree that *if* you do that, you
>> then also have to help reload how to deal with such addresses
>> by providing a legitimize_reload_address hook as you did.
>>
>> Now, in this particular case, there might be another option to
>> avoid this hassle completely:  I understand that this UNSPEC is
>> simply a magic marker to make the address use the fs: or gs:
>> segment override, right?   Now that GCC supports address spaces,
>> it might be possible to model fs:/gs: relative addresses instead
>> by using a non-standard address space ...
>
> This is an interesting idea, I will look into it.

As I explained in:

http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01590.html

we can remove *load_tp_x32_zext and use

(define_insn "*load_tp_x32_"
  [(set (match_operand:SWI48x 0 "register_operand" "=r")
(unspec:SWI48x [(const_int 0)] UNSPEC_TP))]
  "TARGET_X32"
  "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
  [(set_attr "type" "imov")
   (set_attr "modrm" "0")
   (set_attr "length" "7")
   (set_attr "memory" "load")
   (set_attr "imm_disp" "false")])

to load %fs directly into %r32 or %r64.


-- 
H.J.


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread Uros Bizjak
On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu  wrote:

>>> Well, generally speaking, reload makes a lot of assumptions on how
>>> addresses can look like; it needs to, since if a target rejects an
>>> address as invalid as-is, reload must fix it up -- and it can do
>>> so only by making assumptions ...
>>>
>>> Allowing a random UNSPEC as part of valid (non-strict) addresses
>>> makes it really impossible for reload to understand what's going
>>> on.  Given that, I'd tend to agree that *if* you do that, you
>>> then also have to help reload how to deal with such addresses
>>> by providing a legitimize_reload_address hook as you did.
>>>
>>> Now, in this particular case, there might be another option to
>>> avoid this hassle completely:  I understand that this UNSPEC is
>>> simply a magic marker to make the address use the fs: or gs:
>>> segment override, right?   Now that GCC supports address spaces,
>>> it might be possible to model fs:/gs: relative addresses instead
>>> by using a non-standard address space ...
>>
>> This is an interesting idea, I will look into it.
>
> As I explained in:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01590.html
>
> we can remove *load_tp_x32_zext and use
>
> (define_insn "*load_tp_x32_"
>  [(set (match_operand:SWI48x 0 "register_operand" "=r")
>        (unspec:SWI48x [(const_int 0)] UNSPEC_TP))]
>  "TARGET_X32"
>  "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>  [(set_attr "type" "imov")
>   (set_attr "modrm" "0")
>   (set_attr "length" "7")
>   (set_attr "memory" "load")
>   (set_attr "imm_disp" "false")])
>
> to load %fs directly into %r32 or %r64.

No, we can't.

Uros.


[pph] Add stats on PPH processing (issue5933044)

2012-03-27 Thread Diego Novillo
Adds a new flag -fpph-statistics.  When used, it shows various collected
stats at the end of PPH processing.

2012-03-27   Diego Novillo  

c-family/ChangeLog.pph
* c.opt (fpph-stats): Add flag.

cp/ChangeLog.pph
* pph-core.c (pph_stats): Declare.
(pph_init): Initialize.
(pph_cache_lookup): Update pph_stats.cache_lookups and
pph_stats.cache_hits.
(pph_dump_stats): New.
(pph_streamer_finish): Call it.
* pph-in.c (pph_in_record_marker): Update
pph_stats.num_records_by_marker and
pph_stats.num_records_by_tag.
* pph.h (enum pph_record_marker): Add value
PPH_NUM_RECORD_MARKERS.
(struct pph_stats_s): Declare.
(pph_stats_t): Declare.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/pph@185886 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/c-family/ChangeLog.pph |4 ++
 gcc/c-family/c.opt |4 ++
 gcc/cp/ChangeLog.pph   |   16 
 gcc/cp/Make-lang.in|2 +-
 gcc/cp/pph-core.c  |   85 
 gcc/cp/pph-in.c|   39 
 gcc/cp/pph-out.c   |   43 +-
 gcc/cp/pph.h   |   42 +++--
 gcc/cp/pt.c|   16 
 gcc/timevar.def|   30 
 10 files changed, 220 insertions(+), 61 deletions(-)

diff --git a/gcc/c-family/ChangeLog.pph b/gcc/c-family/ChangeLog.pph
index eb99f26..4d26a36 100644
--- a/gcc/c-family/ChangeLog.pph
+++ b/gcc/c-family/ChangeLog.pph
@@ -1,3 +1,7 @@
+2012-03-27   Diego Novillo  
+
+   * c.opt (fpph-stats): Add flag.
+
 2012-03-15   Lawrence Crowl  
 
* c.opt (-fpph-check): New.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 10a3150..e4eb696 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1013,6 +1013,10 @@ fpph-include-tree
 C++ Var(flag_pph_include_tree)
 -fpph-include-tree Print the include tree for the current TU to stderr
 
+fpph-stats
+C++ Var(flag_pph_stats)
+-fpph-statsPrint statistics on PPH data structures
+
 fpph-tracer=
 C++ Joined RejectNegative UInteger Var(flag_pph_tracer)
 -fpph-tracer   Enable tracing of PPH streaming operations
diff --git a/gcc/cp/ChangeLog.pph b/gcc/cp/ChangeLog.pph
index 3f6f5bb..f1b23f8 100644
--- a/gcc/cp/ChangeLog.pph
+++ b/gcc/cp/ChangeLog.pph
@@ -1,3 +1,19 @@
+2012-03-27   Diego Novillo  
+
+   * pph-core.c (pph_stats): Declare.
+   (pph_init): Initialize.
+   (pph_cache_lookup): Update pph_stats.cache_lookups and
+   pph_stats.cache_hits.
+   (pph_dump_stats): New.
+   (pph_streamer_finish): Call it.
+   * pph-in.c (pph_in_record_marker): Update
+   pph_stats.num_records_by_marker and
+   pph_stats.num_records_by_tag.
+   * pph.h (enum pph_record_marker): Add value
+   PPH_NUM_RECORD_MARKERS.
+   (struct pph_stats_s): Declare.
+   (pph_stats_t): Declare.
+
 2012-03-26   Diego Novillo  
 
* pph-core.c (pph_include_handler): Use timer TV_PPH.
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 78328f9..426c3b8 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -353,6 +353,6 @@ cp/cxx-pretty-print.o: cp/cxx-pretty-print.c 
$(CXX_PRETTY_PRINT_H) \
   $(CONFIG_H) $(SYSTEM_H) $(TM_H) coretypes.h $(CXX_TREE_H) tree-pretty-print.h
 cp/pph-core.o: cp/pph-core.c $(CXX_PPH_COMMON_H) $(CPPLIB_H) $(TIMEVAR_H) \
$(TREE_INLINE_H) tree-pretty-print.h fixed-value.h pointer-set.h \
-toplev.h
+toplev.h $(TIMEVAR_H)
 cp/pph-out.o: cp/pph-out.c $(CXX_PPH_COMMON_H) $(CGRAPH_H)
 cp/pph-in.o: cp/pph-in.c $(CXX_PPH_COMMON_H) pointer-set.h toplev.h
diff --git a/gcc/cp/pph-core.c b/gcc/cp/pph-core.c
index 2a16f86..f16675c 100644
--- a/gcc/cp/pph-core.c
+++ b/gcc/cp/pph-core.c
@@ -48,7 +48,10 @@ along with GCC; see the file COPYING3.  If not see
 #include "version.h"
 #include "cppbuiltin.h"
 #include "streamer-hooks.h"
+#include "timevar.h"
 
+/* PPH statistics.  */
+pph_stats_t pph_stats;
 
 /* Mapping between a name string and the registry index for the
corresponding PPH image.  */
@@ -690,6 +693,8 @@ pph_cache_lookup (pph_cache *cache, void *data, unsigned 
*ix_p,
   unsigned ix;
   pph_cache_entry *e;
 
+  pph_stats.cache_lookups++;
+
   if (cache == NULL)
 cache = pph_preloaded_cache;
 
@@ -710,6 +715,8 @@ pph_cache_lookup (pph_cache *cache, void *data, unsigned 
*ix_p,
  it matches the tag we pulled from the cache.  */
   if (tag != PPH_null)
gcc_assert (tag == e->tag);
+
+  pph_stats.cache_hits++;
 }
 
   if (ix_p)
@@ -1517,12 +1524,86 @@ pph_init (void)
 
   pph_reader_init ();
 
+  /* Initialize statistics collection.  */
+  memset (&pph_stats, 0, sizeof (pph_stats));
+
   timevar_stop (TV_PPH);
 }
 
 
 /** pph finalization */
 
+#define PERCENT(x,y) ((float)(x) * 100.0 / (float)(y))
+
+static const char *replay_strings[] = {
+  

[lra] spilling general class pseudos into SSE regs instead of memory (a target hooks driven implementation)

2012-03-27 Thread Vladimir Makarov

  The following patch implements general spilling one class pseudos
into another class hard registers *instead of memory* in LRA.

  Currently, the patch implements spilling of general reg pseudos into
SSE regs for Intel Core architecture as it is recommended by Intel
optimization guide.  Such optimization improves performance and size
of the generated code with LRA.  The size is improved because movd
insn (moving general regs to/from SSE regs) has smaller size that x86
load/store from stack with address offset bigger than 128).  There is
also a steady improvement in code performance with usage of such
optimization for Intel core processors.

  The optimization worsens code performance for AMD processors (Phenom
and Bulldozer) because usage of movd insn is less profitable than
st/ld and it is obvious why X86_TUNE_INTER_UNIT_MOVES is off for such
processors.

  The optimization worsens code performance for Intel Atom although
one could think the opposite as X86_TUNE_INTER_UNIT_MOVES is on for
this processor.  Interesting enough that switching
X86_TUNE_INTER_UNIT_MOVES off for Atom practically does not change the
code performance whithout the optimization.

  The optimization might be useful for some other processors which
have direct move insns for the two considered classes and when IRA for
some reasons did not use the class union.  At least I see
that we could try this for ARM (spilling general regs into VF regs)
and for extended powerpc architecture (spilling general regs into fp
regs).  What is only necessary is just to define two macros.  I am
going to do it for ARM and see is this optimization beneficial for
OMAP4.  Although I think it is not as fp units with VF regs in ARM
implementations I know are too separate from integer units.

The patch was successfully bootstrapped on x86/x86-64 with additional
options -mtune=corei7 -march=corei7.

Committed as rev. 185884.

2012-03-27  Vladimir Makarov 

* common.opt (flra-reg-spill): New option.

* doc/tm.texi (TARGET_SPILL_CLASS, TARGET_SPILL_CLASS_MODE): New
hooks.

* target.def (spill_class, spill_class_mode): New hooks.

* target.h: Include tm.h.

* lra-int.h (lra_reg_spill_p): New external.

* lra.c (lra_reg_spill_p): New global var.
(setup_reg_spill_flag): New function.
(lra): Call setup_reg_spill_flag.  Use lra_reg_spill_p as an
argument for lra_create_live_ranges before spill sub-pass.

* lra-spills.c: Include ira.h.
(spill_hard_reg): New array.
(struct slot): Add new memebr hard_regno.
(assign_slot): Rename to assign_mem_slot.
(assign_spill_hard_regs): New function.
(add_pseudo_to_slot): Ditto.
(assign_stack_slot_num_and_sort_pseudos): Rewrite using
add_pseudo_to_slot.
(remove_pseudos): Use spill_hard_reg.
(lra_spill): Allocate, initialize, and free spill_hard_reg.
Sort pseudo_regnos and call assign_spill_hard_regs.

* lra-assign.c (assign_hard_regno): Use the biggest mode instead
of the pseudo mode.

* Makefile.in (lra-spills.c): Add dependence on ira.h.

* config/i386/i386.h (enum ix86_tune_indices): Add
X86_TUNE_GENERAL_REGS_SSE_SPILL.
(TARGET_GENERAL_REGS_SSE_SPILL): New macro.

* config/i386/i386.c (initial_ix86_tune_features): Add entry for
X86_TUNE_GENERAL_REGS_SSE_SPILL.
(ix86_spill_class): New function.
(ix86_spill_class_mode): Ditto.
(TARGET_SPILL_CLASS, TARGET_SPILL_CLASS_MODE): Define macros.



Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread Richard Henderson
On 03/27/12 09:37, Uros Bizjak wrote:
>> > Now, in this particular case, there might be another option to
>> > avoid this hassle completely:  I understand that this UNSPEC is
>> > simply a magic marker to make the address use the fs: or gs:
>> > segment override, right?   Now that GCC supports address spaces,
>> > it might be possible to model fs:/gs: relative addresses instead
>> > by using a non-standard address space ...
> This is an interesting idea, I will look into it.

Generallized segment overrides via non-standard address spaces
has been on my to-do list for quite a while...


r~


[lra] spilling general class pseudos into SSE regs instead of memory (a target hooks driven implementation)

2012-03-27 Thread Ramana Radhakrishnan
>  The optimization might be useful for some other processors which
> have direct move insns for the two considered classes and when IRA for
> some reasons did not use the class union.  At least I see
> that we could try this for ARM (spilling general regs into VF regs)
> and for extended powerpc architecture (spilling general regs into fp
> regs).  What is only necessary is just to define two macros.  I am
> going to do it for ARM and see is this optimization beneficial for
> OMAP4.  Although I think it is not as fp units with VF regs in ARM
> implementations I know are too separate from integer units.

There is a cost associated with using the VFP register bank and on
older cores like the A8,
there is a penalty associated with moving values from the VFP register
bank to the integer register bank, so it needs to be carefully looked
at on a per core basis.

If you are benchmarking this on an A9 (which is an OMAP4),
I would suggest turning on Neon in your builds to see the full effect of this
rather than just defaulting to the standard vfpv3-d16 configuration just
because this then also brings in the SIMD unit into play.


Thanks,
Ramana


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread H.J. Lu
On Tue, Mar 27, 2012 at 9:57 AM, Uros Bizjak  wrote:
> On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu  wrote:
>
 Well, generally speaking, reload makes a lot of assumptions on how
 addresses can look like; it needs to, since if a target rejects an
 address as invalid as-is, reload must fix it up -- and it can do
 so only by making assumptions ...

 Allowing a random UNSPEC as part of valid (non-strict) addresses
 makes it really impossible for reload to understand what's going
 on.  Given that, I'd tend to agree that *if* you do that, you
 then also have to help reload how to deal with such addresses
 by providing a legitimize_reload_address hook as you did.

 Now, in this particular case, there might be another option to
 avoid this hassle completely:  I understand that this UNSPEC is
 simply a magic marker to make the address use the fs: or gs:
 segment override, right?   Now that GCC supports address spaces,
 it might be possible to model fs:/gs: relative addresses instead
 by using a non-standard address space ...
>>>
>>> This is an interesting idea, I will look into it.
>>
>> As I explained in:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01590.html
>>
>> we can remove *load_tp_x32_zext and use
>>
>> (define_insn "*load_tp_x32_"
>>  [(set (match_operand:SWI48x 0 "register_operand" "=r")
>>        (unspec:SWI48x [(const_int 0)] UNSPEC_TP))]
>>  "TARGET_X32"
>>  "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>>  [(set_attr "type" "imov")
>>   (set_attr "modrm" "0")
>>   (set_attr "length" "7")
>>   (set_attr "memory" "load")
>>   (set_attr "imm_disp" "false")])
>>
>> to load %fs directly into %r32 or %r64.
>
> No, we can't.
>

GCC needs to move the value in the %fs segment
register into %r32 or %r64.  This instruction

"mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"

does exactly what GCC wants.

-- 
H.J.


PATCH: Remove MaskExists property from config/*/*.opt files

2012-03-27 Thread H.J. Lu
Hi,

This patch removes MaskExists property from config/*/*.opt files
since MaskExists handling has been removed.  Tested on Linux/x86-64.
There is no difference between options.h before and after the patch.
OK for trunk?

Thanks.


H.J.
---
2012-03-27  H.J. Lu  

* config/arm/arm.opt (mapcs): Remove MaskExists.
* config/cris/linux.opt (mno-gotplt): Likewise.
* config/i386/i386.opt (mhard-float): Likewise.
(msse4): Likewise.
(mno-sse4): Likewise.
* config/m68k/m68k.opt (mhard-float): Likewise.
* config/mep/mep.op (mcop32): Likewise.
* config/pa/pa-hpux.opt (msio): Likewise.
* config/pa/pa64-hpux.opt (mgnu-ld): Likewise.
* config/picochip/picochip.opt (mlittle): Likewise.
* config/sh/sh.opt (mrenesas): Likewise.
* config/sparc/long-double-switch.opt (mlong-double-128): Likewise.
* config/sparc/sparc.opt (mhard-float): Likewise.
* config/v850/v850.opt (mv850es): Likewise.
* config/vax/vax.opt (mg-float): Likewise.

diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt
index 934aa35..e03a163 100644
--- a/gcc/config/arm/arm.opt
+++ b/gcc/config/arm/arm.opt
@@ -59,7 +59,7 @@ Target Report Mask(ABORT_NORETURN)
 Generate a call to abort if a noreturn function returns
 
 mapcs
-Target RejectNegative Mask(APCS_FRAME) MaskExists Undocumented
+Target RejectNegative Mask(APCS_FRAME) Undocumented
 
 mapcs-float
 Target Report Mask(APCS_FLOAT)
diff --git a/gcc/config/cris/linux.opt b/gcc/config/cris/linux.opt
index a57c48d..e93bb53 100644
--- a/gcc/config/cris/linux.opt
+++ b/gcc/config/cris/linux.opt
@@ -23,7 +23,7 @@ mlinux
 Target Report RejectNegative Undocumented
 
 mno-gotplt
-Target Report RejectNegative Mask(AVOID_GOTPLT) MaskExists
+Target Report RejectNegative Mask(AVOID_GOTPLT)
 Together with -fpic and -fPIC, do not use GOTPLT references
 
 ; There's a small added setup cost with using GOTPLT references
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index 29f1082..965bef6 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -218,7 +218,7 @@ EnumValue
 Enum(fpmath_unit) String(both) Value({(enum fpmath_unit) (FPMATH_SSE | 
FPMATH_387)})
 
 mhard-float
-Target RejectNegative Mask(80387) MaskExists Save
+Target RejectNegative Mask(80387) Save
 Use hardware fp
 
 mieee-fp
@@ -469,11 +469,11 @@ Target Report Mask(ISA_SSE4_2) Var(ix86_isa_flags) Save
 Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 built-in functions and 
code generation
 
 msse4
-Target RejectNegative Report Mask(ISA_SSE4_2) MaskExists Var(ix86_isa_flags) 
Save
+Target RejectNegative Report Mask(ISA_SSE4_2) Var(ix86_isa_flags) Save
 Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 built-in functions and 
code generation
 
 mno-sse4
-Target RejectNegative Report InverseMask(ISA_SSE4_1) MaskExists 
Var(ix86_isa_flags) Save
+Target RejectNegative Report InverseMask(ISA_SSE4_1) Var(ix86_isa_flags) Save
 Do not support SSE4.1 and SSE4.2 built-in functions and code generation
 
 msse5
diff --git a/gcc/config/m68k/m68k.opt b/gcc/config/m68k/m68k.opt
index 14428fc..00bc2d5 100644
--- a/gcc/config/m68k/m68k.opt
+++ b/gcc/config/m68k/m68k.opt
@@ -136,7 +136,7 @@ Target RejectNegative
 Generate code for a Fido A
 
 mhard-float
-Target RejectNegative Mask(HARD_FLOAT) MaskExists
+Target RejectNegative Mask(HARD_FLOAT)
 Generate code which uses hardware floating point instructions
 
 mid-shared-library
diff --git a/gcc/config/mep/mep.opt b/gcc/config/mep/mep.opt
index 38b8f80..0ea19e6 100644
--- a/gcc/config/mep/mep.opt
+++ b/gcc/config/mep/mep.opt
@@ -55,7 +55,7 @@ Target Mask(COP)
 Enable MeP Coprocessor
 
 mcop32
-Target Mask(COP) MaskExists RejectNegative
+Target Mask(COP) RejectNegative
 Enable MeP Coprocessor with 32-bit registers
 
 mcop64
diff --git a/gcc/config/pa/pa-hpux.opt b/gcc/config/pa/pa-hpux.opt
index ed5d6a4..b709b83 100644
--- a/gcc/config/pa/pa-hpux.opt
+++ b/gcc/config/pa/pa-hpux.opt
@@ -23,7 +23,7 @@ Variable
 int flag_pa_unix = TARGET_HPUX_11_31 ? 2003 : TARGET_HPUX_11_11 ? 1998 : 
TARGET_HPUX_10_10 ? 1995 : 1993
 
 msio
-Target RejectNegative Mask(SIO) MaskExists
+Target RejectNegative Mask(SIO)
 Generate cpp defines for server IO
 
 munix=93
diff --git a/gcc/config/pa/pa64-hpux.opt b/gcc/config/pa/pa64-hpux.opt
index 36b1c61..56ca35e 100644
--- a/gcc/config/pa/pa64-hpux.opt
+++ b/gcc/config/pa/pa64-hpux.opt
@@ -19,7 +19,7 @@
 ; .
 
 mgnu-ld
-Target RejectNegative Mask(GNU_LD) MaskExists
+Target RejectNegative Mask(GNU_LD)
 Assume code will be linked by GNU ld
 
 mhp-ld
diff --git a/gcc/config/picochip/picochip.opt b/gcc/config/picochip/picochip.opt
index 4726f49..a4b25e5 100644
--- a/gcc/config/picochip/picochip.opt
+++ b/gcc/config/picochip/picochip.opt
@@ -43,4 +43,4 @@ Target Mask(INEFFICIENT_WARNINGS)
 Generate warnings when inefficient code is known to be generated.
 
 minefficient
-Target Mask(INEFFICIENT_WARNINGS) MaskExists U

Re: PATCH: Add OPTION_MASK_ISA_X86_64 and support TARGET_BI_ARCH == 2

2012-03-27 Thread H.J. Lu
On Sat, Mar 24, 2012 at 03:42:29PM -0700, H.J. Lu wrote:
> Hi,
> 
> In i386 option mask, there is OPTION_MASK_ISA_64BIT for -m64 or -mx32
> code generations and OPTION_MASK_ISA_X32 for -mx32 code generation. We
> support
> 
> -m64: OPTION_MASK_ISA_64BIT && !OPTION_MASK_ISA_X32
> -mx32: OPTION_MASK_ISA_64BIT && OPTION_MASK_ISA_X32
> -m32: !OPTION_MASK_ISA_64BIT
> 
> i386.opt has
> 
> -m64: Turn on OPTION_MASK_ISA_64BIT
> -mx32: Turn on OPTION_MASK_ISA_X32
> -m32: Turn off OPTION_MASK_ISA_64BIT
> 
> So it isn't possible to make -mx32 as default -m64 just turns on
> OPTION_MASK_ISA_64BIT and doesn't change anything.  This option adds
> OPTION_MASK_ISA_X86_64 so that we can have
> 
> OPTION_MASK_ISA_64BIT 32bit x86-64 code or 64bit x86-64 code
> OPTION_MASK_ISA_X86_6464bit x86-64 code
> OPTION_MASK_ISA_X32   32bit x86-64 code
> 
> and i386.opt becomes
> 
> -m64: Turn on OPTION_MASK_ISA_X86_64 
> -mx32: Turn on OPTION_MASK_ISA_X32
> -m32: Turn off OPTION_MASK_ISA_64BIT
> 
> Both OPTION_MASK_ISA_X32 and OPTION_MASK_ISA_X86_64 imply
> OPTION_MASK_ISA_64BIT. OPTION_MASK_ISA_X32 clears OPTION_MASK_ISA_X86_64
> and vice versa.
> 
> I added a dummy command line option, -mx86-64, since we don't support
> ISA_64BIT in
> 
> m32
> Target RejectNegative Negative(m64) Report InverseMask(ISA_64BIT) 
> Var(ix86_isa_flags) Save
> Generate 32bit i386 code
> 
> without a place holder for Mask(ISA_64BIT).
> 
> Currectly when TARGET_BI_ARCH is defined, i386 backend will set the
> OPTION_MASK_ISA_64BIT bit by default to make -m64 as the default.  This
> patch extends TARGET_BI_ARCH to support:
> 
> 1. TARGET_BI_ARCH == 1: -m64 is the default by setting the
> OPTION_MASK_ISA_64BIT and OPTION_MASK_ISA_X86_64 bits.
> 2. TARGET_BI_ARCH == 2: -mx32 is the default by setting the
> OPTION_MASK_ISA_64BIT and OPTION_MASK_ISA_X32 bits.
> 
> I will send a sparate patch to define TARGET_BI_ARCH to 2.  Tested on
> Linux/x86-64.  OK to install?
> 

Here is the updated patch without the undocumented -mx86-64 option.
Tested on Linux/x86-64.  OK to install?

Thanks.

H.J.
---
2012-03-27  H.J. Lu  

* config/i386/biarch64.h (TARGET_64BIT_DEFAULT): Add
OPTION_MASK_ISA_X86_64.

* config/i386/gnu-user64.h (SPEC_64): Support TARGET_BI_ARCH == 2.
(SPEC_X32): Likewise.
(MULTILIB_DEFAULTS): Likewise.

* config/i386/i386.c (ix86_option_override_internal): Properly
set OPTION_MASK_ISA_64BIT and OPTION_MASK_ISA_X32 as well as
handle -m32, -m64 and -mx32.

* config/i386/i386.h (TARGET_X86_64): New.
(TARGET_LP64): Changed to TARGET_X86_64.

* config/i386/i386.opt (m64): Replace ISA_64BIT with ISA_X86_64.

diff --git a/gcc/config/i386/biarch64.h b/gcc/config/i386/biarch64.h
index 629ec98..3dc9889 100644
--- a/gcc/config/i386/biarch64.h
+++ b/gcc/config/i386/biarch64.h
@@ -25,5 +25,5 @@ a copy of the GCC Runtime Library Exception along with this 
program;
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
-#define TARGET_64BIT_DEFAULT OPTION_MASK_ISA_64BIT
+#define TARGET_64BIT_DEFAULT (OPTION_MASK_ISA_64BIT | OPTION_MASK_ISA_X86_64)
 #define TARGET_BI_ARCH 1
diff --git a/gcc/config/i386/gnu-user64.h b/gcc/config/i386/gnu-user64.h
index 954f3b2..6f7b5de 100644
--- a/gcc/config/i386/gnu-user64.h
+++ b/gcc/config/i386/gnu-user64.h
@@ -58,8 +58,13 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 
 #if TARGET_64BIT_DEFAULT
 #define SPEC_32 "m32"
+#if TARGET_BI_ARCH == 2
+#define SPEC_64 "m64"
+#define SPEC_X32 "m32|m64:;"
+#else
 #define SPEC_64 "m32|mx32:;"
 #define SPEC_X32 "mx32"
+#endif
 #else
 #define SPEC_32 "m64|mx32:;"
 #define SPEC_64 "m64"
@@ -95,7 +100,11 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
 
 #if TARGET_64BIT_DEFAULT
+#if TARGET_BI_ARCH == 2
+#define MULTILIB_DEFAULTS { "mx32" }
+#else
 #define MULTILIB_DEFAULTS { "m64" }
+#endif
 #else
 #define MULTILIB_DEFAULTS { "m32" }
 #endif
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 18172a1..4e29b06 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3102,8 +3102,45 @@ ix86_option_override_internal (bool main_args_p)
   SUBSUBTARGET_OVERRIDE_OPTIONS;
 #endif
 
+  /* Turn off both OPTION_MASK_ISA_X86_64 and OPTION_MASK_ISA_X32 if
+ TARGET_64BIT is false.  */
+  if (!TARGET_64BIT)
+ix86_isa_flags &= ~(OPTION_MASK_ISA_X86_64 | OPTION_MASK_ISA_X32);
+#ifdef TARGET_BI_ARCH
+  else
+{
+#if TARGET_BI_ARCH == 1
+  /* When TARGET_BI_ARCH == 1, by default, OPTION_MASK_ISA_X86_64
+is on and OPTION_MASK_ISA_X32 is off.  We turn off
+OPTION_MASK_ISA_X86_64 if OPTION_MASK_ISA_X32 is turned on by
+-mx32.  */
+  if (TARGET_X32)
+   ix86_isa_flags &= ~OPTION_MASK_ISA_X86_64;
+#else
+  /* When TARGET_BI_ARCH == 2, by default, OPTION_MASK_ISA_X

Re: [Patch,avr] PR51345: Restore -mtiny-stack semantics

2012-03-27 Thread Denis Chertykov
2012/3/27 Georg-Johann Lay :
> This patch fixes a problem with the -mtiny-stack option:
>
> Architectures avr2 and avr25 mix targets with 8-bit SP and 16-bit SP so that
> -mtiny-stack is no good for multilib selection:
>
> If a frame pointer has to be set up from an 8-bit SP it is a difference if
> there is no SP_H or of the SP is just treated as if it was 8 bits wide.
>
> In the first case the high byte must be set to 0. In the second case SP_H can
> be read.
>
> That is: The patch uses the size of hard SP for multilib selection and
> generation. The user-settable -mtiny-stack is used for size of soft SP for
> optimization purposes, but does not influence multilib selection or generation
> or how FP is deduced from SP.
>
> Notable changes are:
>
> -mtiny-stack is no more a multilib option and its semantics restored as was
> before PR51345 introduced multilibs for 8-bit SP targets.
>
> Multilib selection is performed by a new undocumented option -msp8. This 
> option
> is only used internally and need not to be specified on the command line. 
> -msp8
> is injected by DRIVER_SELF_SPECS as needed.
>
> There is no avr-specific multilib_raw[] needed any more. This turns
> genmultilib.awk considerably more easy and better to maintain. Much code could
> be kicked off.
>
> -print-multi-lib results are clean now. With the prior approach,
> -print-multi-lib printed phantom configurations like
>
>    tiny-stack;@mmcu=at90s2313
>    avr25/tiny-stack;@mmcu=attiny13
>
> which could confuse libc implementations like newlib or AVR-Libc during their
> configure stage as they evaluate -print-multilib-lib.
>
> Now -print-multi-lib yields
>
> .;
> avr25;@mmcu=avr25
> avr3;@mmcu=avr3
> avr31;@mmcu=avr31
> avr35;@mmcu=avr35
> avr4;@mmcu=avr4
> avr5;@mmcu=avr5
> avr51;@mmcu=avr51
> avr6;@mmcu=avr6
> avrxmega2;@mmcu=avrxmega2
> avrxmega4;@mmcu=avrxmega4
> avrxmega5;@mmcu=avrxmega5
> avrxmega6;@mmcu=avrxmega6
> avrxmega7;@mmcu=avrxmega7
> tiny-stack;@msp8
> avr25/tiny-stack;@mmcu=avr25@msp8
>
> which is perfect and clean. As you can see, the multilib directory structure 
> is
> /unchanged/ i.e. their names are still
>    ./avr25/tiny-stack
> etc.
>
> Ok for trunk?
>
> Johann
>
>        PR target/52737
>        * contrib/gcc_update (files_and_dependencies):
>        Remove gcc/config/avr/t-multilib from touch data.
>
> gcc/
>        PR target/52737
>        * config.gcc (tm_file): Remove avr/multilib.h.
>
>        * doc/invoke.texi (AVR Options): Adjust
>        documentation of -mtiny-stack.
>
>        * config/avr/genmultilib.awk: Remove code to generate multilib.h.
>        (BEGIN): Use -msp8 as multilib option instead of -mtiny-stack.
>        * config/avr/t-avr: Remove generation of multilib.h.
>        * config/avr/t-multilib: Regenerate.
>        * config/avr/multilib.h: Remove.
>        * config/avr/avr.opt (-msp8): New option.
>        (avr_sp8): New variable.
>        * config/avr/driver-avr.c (avr_device_to_sp8): New function.
>        * config/avr/avr.h (AVR_HAVE_SPH): New define.
>        (AVR_HAVE_8BIT_SP): Also set by avr_sp8 i.e. -msp8.
>        (avr_device_to_sp8): New prototype.
>        (EXTRA_SPEC_FUNCTIONS): Add { "device_to_sp8", avr_device_to_sp8 }
>        (DRIVER_SELF_SPECS): New define.
>        * config/avr/avr-c.c (avr_cpu_cpp_builtins): New built-in defines:
>        __AVR_SP8__, __AVR_HAVE_SPH__.
>        * config/avr/avr.c (output_movhi): Use AVR_HAVE_SPH instead of
>        AVR_HAVE_8BIT_SP to decide if SP_H is present.
>        (avr_file_start): Ditto.
>
> libgcc/
>        PR target/52737
>        * config/avr/lib1funcs.S: Use __AVR_HAVE_SPH__ for SP_H checks
>        instead of __AVR_HAVE_8BIT_SP__.
>
>
>

Approved.

Denis.


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread Uros Bizjak
On Tue, Mar 27, 2012 at 7:28 PM, H.J. Lu  wrote:

> GCC needs to move the value in the %fs segment
> register into %r32 or %r64.  This instruction
>
> "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>
> does exactly what GCC wants.

Sorry, I really don't understand what you are trying to say.

You are loading ptrmode (so, void *) pointer from %fs:0 to a DImode
register. If you use movl, you can say that this instruction zero
extends the value (void *, ptrmode, SImode) from a memory location
pointed by %fs:0 to a DImode register. Please note the difference
between:

movl %fs:0, %eax

and

movl %fs, %eax.

BTW: %fs is a 16bit register.

Uros.


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread H.J. Lu
On Tue, Mar 27, 2012 at 10:53 AM, Uros Bizjak  wrote:
> On Tue, Mar 27, 2012 at 7:28 PM, H.J. Lu  wrote:
>
>> GCC needs to move the value in the %fs segment
>> register into %r32 or %r64.  This instruction
>>
>> "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>>
>> does exactly what GCC wants.
>
> Sorry, I really don't understand what you are trying to say.
>
> You are loading ptrmode (so, void *) pointer from %fs:0 to a DImode
> register. If you use movl, you can say that this instruction zero
> extends the value (void *, ptrmode, SImode) from a memory location
> pointed by %fs:0 to a DImode register. Please note the difference
> between:
>
> movl %fs:0, %eax
>
> and
>
> movl %fs, %eax.
>
> BTW: %fs is a 16bit register.
>

%fs and %gs are special in 64bit mode.  For a memory operand
"%fs:address", its effective address is base address of %fs + address.
The base address of %fs and %fs are hidden. "mov %fs, %eax"
will only access the visible part of %fs, which is the 16bit segment
selector.  In 64bit mode, UNSPEC_TP is the base address of %fs.
To access the base address of %fs, we can use system call:

int arch_prctl(int code, unsigned long addr);
int arch_prctl(int code, unsigned long *addr);

   ARCH_SET_FS
  Set the 64-bit base for the FS register to addr.

   ARCH_GET_FS
  Return the 64-bit base value for the FS register of the
  current thread in the unsigned long pointed to by addr.

BTW, 4 new instructions are added to read/write base address of
%fs/%gs directly.  For now, we have to use the system call to
update base address of %fs,  To read the base address of %fs,
OS arranges that the base address of %fs points to a struct:

typedef struct
{
  void *tcb;/* Pointer to the TCB.  Not necessarily the
   thread descriptor used by libpthread.  */
  ...
}

and sets up tcb == the base address of %fs. Then we can use

"mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"

to move the base address of %fs into %r32 and %r64 directly.
I hope this answers your questions.

Thanks.


-- 
H.J.


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread Uros Bizjak
On Tue, Mar 27, 2012 at 8:34 PM, H.J. Lu  wrote:

> %fs and %gs are special in 64bit mode.  For a memory operand
> "%fs:address", its effective address is base address of %fs + address.
> The base address of %fs and %fs are hidden. "mov %fs, %eax"
> will only access the visible part of %fs, which is the 16bit segment
> selector.  In 64bit mode, UNSPEC_TP is the base address of %fs.
> To access the base address of %fs, we can use system call:
>
>        int arch_prctl(int code, unsigned long addr);
>        int arch_prctl(int code, unsigned long *addr);
>
>       ARCH_SET_FS
>              Set the 64-bit base for the FS register to addr.
>
>       ARCH_GET_FS
>              Return the 64-bit base value for the FS register of the
>              current thread in the unsigned long pointed to by addr.
>
> BTW, 4 new instructions are added to read/write base address of
> %fs/%gs directly.  For now, we have to use the system call to
> update base address of %fs,  To read the base address of %fs,
> OS arranges that the base address of %fs points to a struct:
>
> typedef struct
> {
>  void *tcb;            /* Pointer to the TCB.  Not necessarily the
>                           thread descriptor used by libpthread.  */
>  ...
> }
>
> and sets up tcb == the base address of %fs. Then we can use
>
> "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>
> to move the base address of %fs into %r32 and %r64 directly.
> I hope this answers your questions.

Let me say this way: please propose the patch that implements your
suggestions. I will leave the approval of the patch to someone else.

Uros.


Re: [patch][RFC] bail out after front-end errors

2012-03-27 Thread Mike Stump
On Mar 26, 2012, at 1:56 PM, Steven Bosscher wrote:
> This patch is one way to address PR44982.

That's a great idea, I like it.  There is only one problem that I know of that 
prevents it from going in now.  We emit errors/warnings from below finalize and 
there is a feature in which we emit all the reasonable error and warning 
messages that we can with one compile.  There is a certain class of power user 
that actually wants to see all the errors or warnings in a given compile, for 
them, this is a feature.  If you want to move the analysis for those to before 
finalize, then I think this is a good way to fix the problem, until then I 
think we should fix this in the normal way.  The usual way to fix this would be 
to find the bit that had the error_mark_node in it, and then do as much as you 
can, but, then to bubble up error_mark_node or otherwise end processing.

> I see no good reason to cgraph_finalize_compilation_unit if there were parse 
> errors.

It is actually a feature people use, even if you don't have any users or your 
user base is too small to have ever met one.  I have.  The time the feature 
allows to be saved, can be measured in days and weeks.

> it seems to me that those warnings are not very meaningful after parse errors 
> (-Wuninitialized after a
> parse error??),

But you're wrong.

int f = &sdf;

main() {
  int i;
  printf("%d", i);
}

is a program that has parse errors and certainly, any and all the errors after 
the first line that don't involve f in any meaningful way, are meaningful and 
valuable to some people.  I understand you don't see the value in them, that's 
all right.  They aren't valuable or meaningful to you, I get it.  But, are you 
willing to accept it when I assert that there is a class of people for which 
this is a feature, they are meaningful and valuable?

> and errors from the middle end are mostly for exotic
> code (involving asm()s and the like). Bailing out after parse errors
> is therefore IMHO the right thing to do for the common case.

Some are for very exotic things, yes, but not all of them.  Actually, I started 
reviewing them, none of them seem that exotic to me.  Take for example:

int f() { return this->i; }   // { dg-error "" "no member named i" } 

Really, exotic?

register int y; /* { dg-warning "file-scope declaration of 'y' specifies 
'register'" } */

Again, I don't see the value in not giving the warning.

static int f2(void); /* { dg-error "used but never defined" } */

No exactly unheard of.

int x[]; /* { dg-warning "array 'x' assumed to have one element" } */

Gosh, seems reasonable.

hash_unique_table (size_t n, hasher, key_equal,
   value_allocator & a):table (n, a)// { dg-error 
"is not a direct base" }   

This one I can see being nice to get with certain refactoring operations on 
large code bases.

  static_assert( I % 2 == 1, "I must be an odd number"); // { dg-error "odd 
number" }

What, you mean my static_asserts are gonna go away, but we _liked_ them.

case low ... high : return i + 1;  // { dg-error "previously" } 
 
case 5 : return i + 2; // { dg-error "duplicate" }  
 

duplicate case statements, awe...  What's next?

  void Look(W& w) { w.x = 3; }  // { dg-error "private within this 
context" }

Bye bye access control, I guess it was overrated.

I was going to go through them all, but I have to stop now, my stomach doesn't 
feel well.  I was only 38% of the way though them.  Did you actually review 
them, all of them?

What is so very wrong with fixing this in the normal way?  I can envision 
beefier analysis and code checking that runs very late in the compilation 
process in order to get the most accurate analysis out of it.  It seems 
reasonable to permit that, even in the presence of parse errors, for all  the 
same reasons we want to see that a case statement was a duplicate, or that 
something was never defined.



Re: [patch][RFC] bail out after front-end errors

2012-03-27 Thread Steven Bosscher
On Tue, Mar 27, 2012 at 8:59 PM, Mike Stump  wrote:
>> and errors from the middle end are mostly for exotic
>> code (involving asm()s and the like). Bailing out after parse errors
>> is therefore IMHO the right thing to do for the common case.
>
> Some are for very exotic things, yes, but not all of them.  Actually, I 
> started reviewing them, none of them seem that exotic to me.  Take for 
> example:
>
> int f() { return this->i; }   // { dg-error "" "no member named i" }
>
> Really, exotic?

I expect it is not difficult to retain almost all of these C++ errors
by lowering (i.e. gimplifying) in the front end, or by having some
intermediate stage. It certainly wouldn't be acceptable to loose all
those diagnostics, just like that. I'm trying to figure out how to
avoid that! But it seemed prudent to ask what other people think of
this kind of change before spending loads of time on it  :-)
Thanks for your comments!

Ciao!
Steven


Re: PATCH: Remove MaskExists property from config/*/*.opt files

2012-03-27 Thread Joseph S. Myers
On Tue, 27 Mar 2012, H.J. Lu wrote:

> Hi,
> 
> This patch removes MaskExists property from config/*/*.opt files
> since MaskExists handling has been removed.  Tested on Linux/x86-64.
> There is no difference between options.h before and after the patch.
> OK for trunk?

OK.

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


[pph] Add more PPH timers and stats. (issue5937045)

2012-03-27 Thread Diego Novillo
Add more PPH timers and stats.

We are spending too much time inside the reading of template bodies.
This patch adds more timers that pinpoint the problem to be the
hashing of specialization tables.  We spend roughly 50% of PPH reading
inside the hashing code.


2012-03-27   Diego Novillo  

cp/ChangeLog.pph
* pph-core.c (pph_dump_stats): Print pph_stats.num_spec_entry_elems.
* pph.h (struct pph_stats_s): Add field num_spec_entry_elems.
* pt.c (pph_out_spec_entry_htab): Update pph_stats.num_spec_entry_elems.
(pph_in_bodies_spec_entry_htab): Likewise.
Add timer TV_PPH_SPECIALIZATION_HASH around hashing operations.

ChangeLog.pph
* timevar.def (TV_PPH_SPECIALIZATION_HASH): New timer.
(TV_PPH_OUT_MERGE_KEYS, TV_PPH_OUT_MERGE_BODIES, TV_PPH_IN_MERGE_KEYS,
TV_PPH_IN_MERGE_BODIES): Remove.
(TV_PPH_OUT_BL_K): New.  Update previous users of TV_PPH_OUT_MERGE_KEYS.
(TV_PPH_OUT_BL_B): New.  Update previous users of
TV_PPH_OUT_MERGE_BODIES.
(TV_PPH_OUT_TMPL_K): New.  Update previous users of
TV_PPH_OUT_MERGE_KEYS.
(TV_PPH_OUT_TMPL_B): New.  Update previous users of
TV_PPH_OUT_MERGE_BODIES.
(TV_PPH_IN_BL_K): New.  Update previous users of TV_PPH_OUT_MERGE_KEYS.
(TV_PPH_IN_BL_B): New.  Update previous users of
TV_PPH_OUT_MERGE_BODIES.
(TV_PPH_IN_TMPL_K): New.  Update previous users of
TV_PPH_OUT_MERGE_KEYS.
(TV_PPH_IN_TMPL_B): New.  Update previous users of
TV_PPH_OUT_MERGE_BODIES.

diff --git a/gcc/cp/pph-core.c b/gcc/cp/pph-core.c
index f16675c..da91524 100644
--- a/gcc/cp/pph-core.c
+++ b/gcc/cp/pph-core.c
@@ -1601,6 +1601,10 @@ pph_dump_stats (FILE *f)
   PERCENT (pph_stats.cache_hits, pph_stats.cache_lookups));
 
   fprintf (f, "\n");
+  fprintf (f, "Number of elements in all spec_entry tables: %lu",
+  pph_stats.num_spec_entry_elems);
+
+  fprintf (f, "\n");
   timevar_print (f);
 }
 
diff --git a/gcc/cp/pph-in.c b/gcc/cp/pph-in.c
index d50581e..546a591 100644
--- a/gcc/cp/pph-in.c
+++ b/gcc/cp/pph-in.c
@@ -3121,7 +3121,7 @@ pph_in_global_binding_keys (pph_stream *stream)
   cp_binding_level *bl, *other_bl;
   bool existed_p;
 
-  timevar_start (TV_PPH_IN_MERGE_KEYS);
+  timevar_start (TV_PPH_IN_BL_K);
 
   bl = scope_chain->bindings;
   other_bl = pph_in_binding_level_start (stream, bl, &existed_p);
@@ -3138,7 +3138,7 @@ pph_in_global_binding_keys (pph_stream *stream)
  bound to scope_chain->bindings.  */
   pph_in_merge_key_binding_level (stream, &bl);
 
-  timevar_stop (TV_PPH_IN_MERGE_KEYS);
+  timevar_stop (TV_PPH_IN_BL_K);
 }
 
 
@@ -3151,14 +3151,14 @@ pph_in_global_binding_bodies (pph_stream *stream)
 {
   cp_binding_level *bl = scope_chain->bindings;
 
-  timevar_start (TV_PPH_IN_MERGE_BODIES);
+  timevar_start (TV_PPH_IN_BL_B);
 
   /* Once all the symbols and types at every binding level have been
  merged to the corresponding binding levels in the current
  compilation, read all the bodies.  */
   pph_in_merge_body_binding_level (stream, bl);
 
-  timevar_stop (TV_PPH_IN_MERGE_BODIES);
+  timevar_stop (TV_PPH_IN_BL_B);
 }
 
 
diff --git a/gcc/cp/pph-out.c b/gcc/cp/pph-out.c
index 018a5f0..7b4cf01 100644
--- a/gcc/cp/pph-out.c
+++ b/gcc/cp/pph-out.c
@@ -2610,7 +2610,7 @@ pph_out_global_binding_keys (pph_stream *stream)
 {
   cp_binding_level *bl;
 
-  timevar_start (TV_PPH_OUT_MERGE_KEYS);
+  timevar_start (TV_PPH_OUT_BL_K);
 
   /* We only need to write out the scope_chain->bindings, everything
  else should be NULL or be some temporary disposable state.
@@ -2643,7 +2643,7 @@ pph_out_global_binding_keys (pph_stream *stream)
  reading multiple PPH images.  */
   pph_out_merge_key_binding_level (stream, bl);
 
-  timevar_stop (TV_PPH_OUT_MERGE_KEYS);
+  timevar_stop (TV_PPH_OUT_BL_K);
 }
 
 
@@ -2654,12 +2654,12 @@ pph_out_global_binding_bodies (pph_stream *stream)
 {
   cp_binding_level *bl = scope_chain->bindings;
 
-  timevar_start (TV_PPH_OUT_MERGE_BODIES);
+  timevar_start (TV_PPH_OUT_BL_B);
 
   /* Now emit all the bodies.  */
   pph_out_merge_body_binding_level (stream, bl);
 
-  timevar_stop (TV_PPH_OUT_MERGE_BODIES);
+  timevar_stop (TV_PPH_OUT_BL_B);
 }
 
 
diff --git a/gcc/cp/pph.h b/gcc/cp/pph.h
index 74860be..b28b3cc 100644
--- a/gcc/cp/pph.h
+++ b/gcc/cp/pph.h
@@ -164,6 +164,9 @@ typedef struct pph_stats_s {
 
   /* Total number of replay actions in the replay table.  */
   unsigned long num_replay_actions;
+
+  /* Total number of entries in a spec_entry template table.  */
+  unsigned long num_spec_entry_elems;
 } pph_stats_t;
 
 extern pph_stats_t pph_stats;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2cd3835..6a4c634 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -20803,6 +20803,7 @@ pph_out_spec_entry_htab (pph_stream *stream, htab_t 
*table,
   unsigned count = htab_elements (*table);
   /*FIXME pph: This write may be unstable.  */
   pph_out_uint (stream, count);
+

[wwwdocs] fix broken link to libstdc++ manual

2012-03-27 Thread Jonathan Wakely
Applied.
Index: htdocs/gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.105
diff -u -r1.105 changes.html
--- htdocs/gcc-4.7/changes.html 26 Mar 2012 13:04:45 -  1.105
+++ htdocs/gcc-4.7/changes.html 27 Mar 2012 20:19:05 -
@@ -482,7 +482,7 @@
   Runtime Library (libstdc++)
 
   
-http://gcc.gnu.org/onlinedocs/gcc-4.7.0/libstdc++/manual/status.html#status.iso.200x";>
+http://gcc.gnu.org/onlinedocs/gcc-4.7.0/libstdc++/manual/manual/status.html#status.iso.2011";>
Improved experimental support for the new ISO C++ standard, C++11,
including:



Re: [PATCH][ARM] NEON DImode not

2012-03-27 Thread Andrew Stubbs

On 08/03/12 18:03, Richard Henderson wrote:

On 03/08/12 08:19, Andrew Stubbs wrote:

+   (set_attr "arch" "nota8,*,*,onlya8")
+   (set_attr_alternative "insn_enabled"
+   [(if_then_else (match_test "TARGET_NEON")
+  (const_string "yes") (const_string "no"))
+(const_string "yes")
+(const_string "yes")
+(if_then_else (match_test "TARGET_NEON")
+  (const_string "yes") (const_string "no"))])]
  )


While this works, it might be better to add neon/neon_na8/neon_oa8
alternatives to the arch attribute, and adjust arch_enabled to match.

Obviously this opinion is non-binding; Richard E might have other plans...


No reply from Richard so far ... so here's an update.

OK now?

Andrew
2012-03-27  Andrew Stubbs  

	gcc/
	* config/arm/arm.md (arch): Add neon_onlya8 and neon_nota8.
	(arch_enabled): Handle new arch types.
	(one_cmpldi2): Add NEON support.

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 751997f..6669329 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -207,7 +207,7 @@
 ; for ARM or Thumb-2 with arm_arch6, and nov6 for ARM without
 ; arm_arch6.  This attribute is used to compute attribute "enabled",
 ; use type "any" to enable an alternative in all cases.
-(define_attr "arch" "any,a,t,32,t1,t2,v6,nov6,onlya8,nota8"
+(define_attr "arch" "any,a,t,32,t1,t2,v6,nov6,onlya8,neon_onlya8,nota8,neon_nota8"
   (const_string "any"))
 
 (define_attr "arch_enabled" "no,yes"
@@ -246,8 +246,18 @@
 	  (eq_attr "tune" "cortexa8"))
 	 (const_string "yes")
 
+	 (and (eq_attr "arch" "neon_onlya8")
+	  (eq_attr "tune" "cortexa8")
+	  (match_test "TARGET_NEON"))
+	 (const_string "yes")
+
 	 (and (eq_attr "arch" "nota8")
 	  (not (eq_attr "tune" "cortexa8")))
+	 (const_string "yes")
+
+	 (and (eq_attr "arch" "neon_nota8")
+	  (not (eq_attr "tune" "cortexa8"))
+	  (match_test "TARGET_NEON"))
 	 (const_string "yes")]
 	(const_string "no")))
 
@@ -4207,11 +4217,16 @@
   "")
 
 (define_insn_and_split "one_cmpldi2"
-  [(set (match_operand:DI 0 "s_register_operand" "=&r,&r")
-	(not:DI (match_operand:DI 1 "s_register_operand" "0,r")))]
+  [(set (match_operand:DI 0 "s_register_operand"	 "=w,&r,&r,?w")
+	(not:DI (match_operand:DI 1 "s_register_operand" " w, 0, r, w")))]
   "TARGET_32BIT"
-  "#"
-  "TARGET_32BIT && reload_completed"
+  "@
+   vmvn\t%P0, %P1
+   #
+   #
+   vmvn\t%P0, %P1"
+  "TARGET_32BIT && reload_completed
+   && arm_general_register_operand (operands[0], DImode)"
   [(set (match_dup 0) (not:SI (match_dup 1)))
(set (match_dup 2) (not:SI (match_dup 3)))]
   "
@@ -4221,8 +4236,10 @@
 operands[3] = gen_highpart (SImode, operands[1]);
 operands[1] = gen_lowpart (SImode, operands[1]);
   }"
-  [(set_attr "length" "8")
-   (set_attr "predicable" "yes")]
+  [(set_attr "length" "*,8,8,*")
+   (set_attr "predicable" "yes")
+   (set_attr "neon_type" "neon_int_1,*,*,neon_int_1")
+   (set_attr "arch" "neon_nota8,*,*,neon_onlya8")]
 )
 
 (define_expand "one_cmplsi2"


[v3] fix ADL bugs in

2012-03-27 Thread Jonathan Wakely
   * include/std/functional (mem_fn): Qualify to prevent ADL.
   * testsuite/20_util/function_objects/mem_fn/adl.cc: New.

Tested x86_64-linux, committed to trunk.  Not a regression but should
be safe for all branches.
commit be288d23ed09bfabb8d1bc736e236c5b9e80beb3
Author: Jonathan Wakely 
Date:   Tue Mar 27 20:19:20 2012 +0100

* include/std/functional (mem_fn): Qualify to prevent ADL.
* testsuite/20_util/function_objects/mem_fn/adl.cc: New.

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index 4be1bc7..14785dd 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1,7 +1,7 @@
 //  -*- C++ -*-
 
 // Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-// 2011 Free Software Foundation, Inc.
+// 2011, 2012 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -245,7 +245,7 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
>::type
 __invoke(_Functor& __f, _Args&&... __args)
 {
-  return mem_fn(__f)(std::forward<_Args>(__args)...);
+  return std::mem_fn(__f)(std::forward<_Args>(__args)...);
 }
 
   // To pick up function references (that will become function pointers)
@@ -1709,12 +1709,12 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
   template
 inline _Mem_fn<_Member _Class::*>
 __callable_functor(_Member _Class::* &__p)
-{ return mem_fn(__p); }
+{ return std::mem_fn(__p); }
 
   template
 inline _Mem_fn<_Member _Class::*>
 __callable_functor(_Member _Class::* const &__p)
-{ return mem_fn(__p); }
+{ return std::mem_fn(__p); }
 
   template
 class function;
@@ -1970,7 +1970,7 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
   static _Res
   _M_invoke(const _Any_data& __functor, _ArgTypes... __args)
   {
-   return mem_fn(_Base::_M_get_pointer(__functor)->__value)(
+   return std::mem_fn(_Base::_M_get_pointer(__functor)->__value)(
std::forward<_ArgTypes>(__args)...);
   }
 };
@@ -2010,7 +2010,7 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
   static void
   _M_invoke(const _Any_data& __functor, _ArgTypes... __args)
   {
-   mem_fn(_Base::_M_get_pointer(__functor)->__value)(
+   std::mem_fn(_Base::_M_get_pointer(__functor)->__value)(
std::forward<_ArgTypes>(__args)...);
   }
 };
diff --git a/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/adl.cc 
b/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/adl.cc
new file mode 100644
index 000..907db84
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/adl.cc
@@ -0,0 +1,44 @@
+// { dg-options "-std=gnu++0x" }
+// { dg-do compile }
+
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+
+namespace n {
+  struct X { int i; };
+  void mem_fn(int X::*);
+}
+
+using n::X;
+
+X x{};
+int X::* p = &X::i;
+
+int test01()
+{
+  auto ref = std::ref(p);
+  return ref(x);
+}
+
+int test02()
+{
+  std::function fun(p);
+  return fun(x);
+}
+


[patch] Do not call output_constant from the front end

2012-03-27 Thread Steven Bosscher
Hello,

The Java front end emits assembly from class.c:emit_register_classes()
to fill the .jcr section. This is not something a front end ought to
be doing. Things to write out to the assembler output file should go
through the varpool/varasm mechanism. The attached patch makes
emit_register_classes build a constructor for the .jcr section, and
stops it calling output_constant.

The patch passes build+testing on powerpc64-unknown-linux-gnu.

With this patch a variable named "_Jv_CLS" is written out. The
assembly before and after the patch is the same, except for the
variable name. I want to write out a nameless variable but I don't
know how. Help welcome.

Ciao!
Steven


java/
PR java/52730
* class.c (emit_register_classes_in_jcr_section): New function.
(emit_Jv_RegisterClass_calls): New function, split out from ...
(emit_register_classes): ... here.  Reorganize.  Do not call
output_constant.
java/
	* class.c (emit_register_classes_in_jcr_section): New function.
	(emit_Jv_RegisterClass_calls): New function, split out from ...
	(emit_register_classes): ... here.  Reorganize.  Do not call
	output_constant.

Index: class.c
===
--- class.c	(revision 185813)
+++ class.c	(working copy)
@@ -2786,10 +2786,75 @@ emit_indirect_register_classes (tree *list_p)
   append_to_statement_list (t, list_p);
 }
 
+/* Emit a list of pointers to all classes we have emitted to JCR_SECTION.  */
 
+static void
+emit_register_classes_in_jcr_section (void)
+{
+  tree klass, cdecl, class_array_type;
+  int i;
+  int size = VEC_length (tree, registered_class);
+  VEC(constructor_elt,gc) *init = VEC_alloc (constructor_elt, gc, size);
+
+#ifndef JCR_SECTION_NAME
+  /* A target has defined TARGET_USE_JCR_SECTION,
+ but doesn't have a JCR_SECTION_NAME.  */
+  gcc_unreachable ();
+#endif
+
+  FOR_EACH_VEC_ELT (tree, registered_class, i, klass)
+CONSTRUCTOR_APPEND_ELT (init, NULL_TREE, build_fold_addr_expr (klass));
+
+  class_array_type = build_prim_array_type (ptr_type_node, size);
+  cdecl = build_decl (UNKNOWN_LOCATION,
+		  VAR_DECL, get_identifier ("_Jv_CLS"),
+		  class_array_type);
+  DECL_SECTION_NAME (cdecl) = build_string (strlen (JCR_SECTION_NAME),
+	JCR_SECTION_NAME);
+  DECL_ALIGN (cdecl) = POINTER_SIZE;
+  DECL_INITIAL (cdecl) = build_constructor (class_array_type, init);
+  TREE_CONSTANT (DECL_INITIAL (cdecl)) = 1;
+  TREE_STATIC (cdecl) = 1;
+  DECL_ARTIFICIAL (cdecl) = 1;
+  DECL_IGNORED_P (cdecl) = 1;
+  TREE_READONLY (cdecl) = 1;
+  TREE_CONSTANT (cdecl) = 1;
+  pushdecl_top_level (cdecl);
+  relayout_decl (cdecl);
+  rest_of_decl_compilation (cdecl, 1, 0);
+  mark_decl_referenced (cdecl);
+}
+
+
+/* Emit a series of calls to _Jv_RegisterClass for every class we emitted.
+   A series of calls is added to LIST_P.  */
+
+static void
+emit_Jv_RegisterClass_calls (tree *list_p)
+{
+  tree klass, t, register_class_fn;
+  int i;
+
+  t = build_function_type_list (void_type_node, class_ptr_type, NULL);
+  t = build_decl (input_location,
+		  FUNCTION_DECL, get_identifier ("_Jv_RegisterClass"), t);
+  TREE_PUBLIC (t) = 1;
+  DECL_EXTERNAL (t) = 1;
+  register_class_fn = t;
+
+  FOR_EACH_VEC_ELT (tree, registered_class, i, klass)
+{
+  t = build_fold_addr_expr (klass);
+  t = build_call_expr (register_class_fn, 1, t);
+  append_to_statement_list (t, list_p);
+}
+}
+
 /* Emit something to register classes at start-up time.
 
-   The preferred mechanism is through the .jcr section, which contain
+   The default mechanism is to generate instances at run-time.
+
+   An alternative mechanism is through the .jcr section, which contain
a list of pointers to classes which get registered during constructor
invocation time.
 
@@ -2803,55 +2868,18 @@ emit_register_classes (tree *list_p)
   if (registered_class == NULL)
 return;
 
+  /* By default, generate instances of Class at runtime.  */
   if (flag_indirect_classes)
-{
-  emit_indirect_register_classes (list_p);
-  return;
-}
-
+emit_indirect_register_classes (list_p);
   /* TARGET_USE_JCR_SECTION defaults to 1 if SUPPORTS_WEAK and
  TARGET_ASM_NAMED_SECTION, else 0.  Some targets meet those conditions
  but lack suitable crtbegin/end objects or linker support.  These
  targets can override the default in tm.h to use the fallback mechanism.  */
-  if (TARGET_USE_JCR_SECTION)
-{
-  tree klass, t;
-  int i;
-
-#ifdef JCR_SECTION_NAME
-  switch_to_section (get_section (JCR_SECTION_NAME, SECTION_WRITE, NULL));
-#else
-  /* A target has defined TARGET_USE_JCR_SECTION,
-	 but doesn't have a JCR_SECTION_NAME.  */
-  gcc_unreachable ();
-#endif
-  assemble_align (POINTER_SIZE);
-
-  FOR_EACH_VEC_ELT (tree, registered_class, i, klass)
-	{
-	  t = build_fold_addr_expr (klass);
-	  output_constant (t, POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE);
-	}
-}
+  else if (TARGET_U

[PATCH] Fix sse2_loadlpd splitter (PR target/52736)

2012-03-27 Thread Jakub Jelinek
Hi!

As the following testcase shows, the sse2_loadlpd splitter when
the destination (and at the same operand from which the second
DFmode element is taken) is a MEM and the other DFmode operand
is a register stores into wrong part of memory, it does what
the sse2_loadhpd splitter does, while it should overwrite the
first half of the vector and keep the second half preserved.

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

2012-03-27  Jakub Jelinek  

PR target/52736
* config/i386/sse.md (sse2_loadlpd splitter): Use offset 0
instead of 8 in adjust_address.

* gcc.target/i386/pr52736.c: New test.

--- gcc/config/i386/sse.md.jj   2012-03-26 11:53:19.0 +0200
+++ gcc/config/i386/sse.md  2012-03-27 16:09:52.764828996 +0200
@@ -4901,7 +4901,7 @@ (define_split
  (vec_select:DF (match_dup 0) (parallel [(const_int 1)]]
   "TARGET_SSE2 && reload_completed"
   [(set (match_dup 0) (match_dup 1))]
-  "operands[0] = adjust_address (operands[0], DFmode, 8);")
+  "operands[0] = adjust_address (operands[0], DFmode, 0);")
 
 (define_insn "sse2_movsd"
   [(set (match_operand:V2DF 0 "nonimmediate_operand"   "=x,x,x,x,m,x,x,x,o")
--- gcc/testsuite/gcc.target/i386/pr52736.c.jj  2012-03-27 16:40:37.924944611 
+0200
+++ gcc/testsuite/gcc.target/i386/pr52736.c 2012-03-27 16:40:30.0 
+0200
@@ -0,0 +1,29 @@
+/* PR target/52736 */
+/* { dg-do run } */
+/* { dg-options "-O1 -msse2" } */
+/* { dg-require-effective-target sse2_runtime } */
+
+#include 
+
+typedef double D __attribute__((may_alias));
+__attribute__((aligned(16))) static const double r[4] = { 1., 5., 1., 3. };
+
+__attribute__((noinline, noclone))
+void
+foo (int x)
+{
+  asm volatile ("" : "+g" (x) : : "memory");
+  if (x != 3)
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  __m128d t = _mm_set1_pd (5.);
+  ((D *)(&t))[0] = 1.;
+  foo (_mm_movemask_pd (_mm_cmpeq_pd (t, _mm_load_pd (&r[0];
+  ((D *)(&t))[1] = 3.;
+  foo (_mm_movemask_pd (_mm_cmpeq_pd (t, _mm_load_pd (&r[2];
+  return 0;
+}

Jakub


Re: [PATCH][ARM] NEON DImode not

2012-03-27 Thread Richard Henderson
On 03/27/12 13:23, Andrew Stubbs wrote:
>   gcc/
>   * config/arm/arm.md (arch): Add neon_onlya8 and neon_nota8.
>   (arch_enabled): Handle new arch types.
>   (one_cmpldi2): Add NEON support.

Looks good to me.


r~


Re: [PATCH] Bug fix in store_bit_field_1 for big endian targets (issue 51893)

2012-03-27 Thread Eric Botcazou
> Changelog:
> * expmed.c (store_bit_field_1): Fix wordnum value for big endian targets

The author line was missing so I put:

2012-03-27  Aurelien Buhrig  

PR middle-end/51893
* expmed.c (store_bit_field_1): Fix wordnum value for big-endian
targets.

> Will this fix be backported to 4.6 branch for next release?

The policy is to put only fixes for regressions on release branches, and this 
is obviously not a regression.  I think we might want to put it on the 4.7 
branch though, because it's early in the release cycle and we fixed a twin bug 
on that branch (PR middle-end/50325).  But it's up to the RMs, now CCed.

-- 
Eric Botcazou


Re: Fix PR rtl-optimization/52629

2012-03-27 Thread Eric Botcazou
> Bootstrapped/regtested on x86_64-suse-linux, applied on mainline.  Should
> it be applied to the release branches as well?
>
>
> 2012-03-26  Eric Botcazou  
>
>   PR rtl-optimization/52629
>   * reload1.c (count_pseudo): Short-circuit common case.
>   (count_spilled_pseudo): Return early for pseudos without hard regs.
>   Assert that the pseudo has got a hard reg before manipulating it.

RMs, what's your decision?

-- 
Eric Botcazou


Re: [patch] Do not call output_constant from the front end

2012-03-27 Thread Eric Botcazou
> With this patch a variable named "_Jv_CLS" is written out. The
> assembly before and after the patch is the same, except for the
> variable name. I want to write out a nameless variable but I don't
> know how.

Try tree_output_constant_def.

-- 
Eric Botcazou


[PATCH] rs6000: Extend TARGET_NO_LWSYNC to cover more processors

2012-03-27 Thread Meador Inge
Hi All,

This patch fixes an issue reported by one of our customers where an instruction
exception gets raised when using '__sync_fetch_and_add' on a PowerPC 440
processor.  The instruction causing the exception is 'lwsync'.  Luckily Joseph
laid the groundwork when solving a similar issue for e500 cores [1] by adding a
new macro ('TARGET_NO_LWSYNC') for controlling whether 'lwsync' is available .

This patch extends the 'TARGET_NO_LWSYNC' macro to include the PowerPC 440
and 603 processors.  The 440 because that is what the problem was reported
against and the 603 because problems have been reported elsewhere [4] about
that.  It doesn't seem like 'lwsync' is supported on 603 processors anyway.  I
looked at the IBM [2] and Freescale [3] manuals and both use the heavyweight
implementation of 'sync' (i.e. the 'sync' bit L=0).

FWIW, I also took a look at the Linux kernel code and 'lwsync' is only used
on 64-bit PowerPC processors and e500 processors that can support it.  This
can be seen in 'arch/powerpc/include/asm/synch.h':

   #if defined(__powerpc64__)
   #define LWSYNC   lwsync
   #elif defined(CONFIG_E500)
   #define LWSYNC   \
START_LWSYNC_SECTION(96);   \
sync;   \
MAKE_LWSYNC_SECTION_ENTRY(96, __lwsync_fixup);
   #else
   #define LWSYNC   sync
   #endif

Support for the e500 processors is determined at runtime and the kernel is
dynamically patched.

Regression tested with powerpc-none-eabi.

OK?

P.S.  If it is OK can some please commit for me?  I don't have write access.

[1] http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01238.html
[2]
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996006F9795/$file/603e_um.pdf
[3] http://cache.freescale.com/files/32bit/doc/ref_manual/MPC603EUM.pdf
[4] http://gcc.gnu.org/ml/gcc/2008-06/msg00449.html

-- 
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
2012-03-27  Meador Inge  

	* config/rs6000/rs6000.h (TARGET_NO_LWSYNC): Extended to cover PPC
	440 and 603 processors.
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h	(revision 185881)
+++ gcc/config/rs6000/rs6000.h	(working copy)
@@ -501,8 +501,10 @@ extern int rs6000_vector_align[];
 
 
 
-/* E500 processors only support plain "sync", not lwsync.  */
-#define TARGET_NO_LWSYNC TARGET_E500
+/* Some processors only support plain "sync", not lwsync.  */
+#define TARGET_NO_LWSYNC (TARGET_E500 \
+			  || rs6000_cpu == PROCESSOR_PPC440 \
+			  || rs6000_cpu == PROCESSOR_PPC603)
 
 /* Which machine supports the various reciprocal estimate instructions.  */
 #define TARGET_FRES	(TARGET_HARD_FLOAT && TARGET_PPC_GFXOPT \


Re: [patch] Do not call output_constant from the front end

2012-03-27 Thread Steven Bosscher
On Tue, Mar 27, 2012 at 11:07 PM, Eric Botcazou  wrote:
>> With this patch a variable named "_Jv_CLS" is written out. The
>> assembly before and after the patch is the same, except for the
>> variable name. I want to write out a nameless variable but I don't
>> know how.
>
> Try tree_output_constant_def.

I didn't know about this function. But as far as I can tell, there is
no way to instruct that function to put the data in a specific
section. In the Java case, the data must be put in the .jcr section. I
suppose that can be achieved with a bit more re-working of varasm, but
not with the code as-is. Thanks for the pointer, though!

Ciao!
Steven


PATCH: Remove *load_tp_x32 from i386.md

2012-03-27 Thread H.J. Lu
Hi Richard,

Segment registers %fs and %gs are special in 64bit mode.  For a memory
operand "%fs:address", its effective address is the base address of %fs +
address.  The base address of %fs are hidden and "mov %fs, %ax" will only
access the visible part of %fs, which is the 16bit segment selector.

In 64bit mode, UNSPEC_TP refers to the base address of %fs.  To access the
base address of %fs, we can use system call:

int arch_prctl(int code, unsigned long addr);
int arch_prctl(int code, unsigned long *addr);

   ARCH_SET_FS
  Set the 64-bit base for the FS register to addr.

   ARCH_GET_FS
  Return the 64-bit base value for the FS register of the
  current thread in the unsigned long pointed to by addr.

we must use the system call to update the base address of %fs,  To read
the base address of %fs, OS arranges that the base address of %fs points
to a struct:

typedef struct
{
  void *tcb;/* Pointer to the TCB.  Not necessarily the
   thread descriptor used by libpthread.  */
  ...
}

and sets up "tcb" == the base address of %fs so that the address of "%fs:0"
is the address of the tcb field.  For x32, the base address of %fs is
between 0 and 0x.  We can use

"mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"

to move the base address of %fs into %r32 and %r64 directly.  In case
of %r32, we are loading "tcb", which is a 32bit memory.  For %r64, we
are loading "tcb" and zero-extend it to 64bit.  This patch is tested on
Linux/x32 with GCC and glibc with both -maddress-mode=long and
-maddress-mode=short.  OK for trunk?

Thanks.


H.J.
---
2012-03-27  H.J. Lu  

* config/i386/i386.c (legitimize_pic_address): Load UNSPEC_TP
into tp_mode register directly.

* config/i386/i386.md (*load_tp_x32): Removed.
(*load_tp_x32_zext): Likewise.
(*load_tp_x32_): New.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a21f2da..14c4056 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -12491,15 +12485,7 @@ legitimize_pic_address (rtx orig, rtx reg)
 static rtx
 get_thread_pointer (enum machine_mode tp_mode, bool to_reg)
 {
-  rtx tp = gen_rtx_UNSPEC (ptr_mode, gen_rtvec (1, const0_rtx), UNSPEC_TP);
-
-  if (GET_MODE (tp) != tp_mode)
-{
-  gcc_assert (GET_MODE (tp) == SImode);
-  gcc_assert (tp_mode == DImode);
-
-  tp = gen_rtx_ZERO_EXTEND (tp_mode, tp);
-}
+  rtx tp = gen_rtx_UNSPEC (tp_mode, gen_rtvec (1, const0_rtx), UNSPEC_TP);
 
   if (to_reg)
 tp = copy_to_mode_reg (tp_mode, tp);
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 2d20a52..ac6124e 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -12748,20 +12748,9 @@
 (define_mode_attr tp_seg [(SI "gs") (DI "fs")])
 
 ;; Load and add the thread base pointer from %:0.
-(define_insn "*load_tp_x32"
-  [(set (match_operand:SI 0 "register_operand" "=r")
-   (unspec:SI [(const_int 0)] UNSPEC_TP))]
-  "TARGET_X32"
-  "mov{l}\t{%%fs:0, %0|%0, DWORD PTR fs:0}"
-  [(set_attr "type" "imov")
-   (set_attr "modrm" "0")
-   (set_attr "length" "7")
-   (set_attr "memory" "load")
-   (set_attr "imm_disp" "false")])
-
-(define_insn "*load_tp_x32_zext"
-  [(set (match_operand:DI 0 "register_operand" "=r")
-   (zero_extend:DI (unspec:SI [(const_int 0)] UNSPEC_TP)))]
+(define_insn "*load_tp_x32_"
+  [(set (match_operand:SWI48x 0 "register_operand" "=r")
+   (unspec:SWI48x [(const_int 0)] UNSPEC_TP))]
   "TARGET_X32"
   "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
   [(set_attr "type" "imov")


[patch][rfa] Do not call output_constant from the front end

2012-03-27 Thread Steven Bosscher
On Tue, Mar 27, 2012 at 11:51 PM, Steven Bosscher  wrote:
> On Tue, Mar 27, 2012 at 11:07 PM, Eric Botcazou  wrote:
>>> With this patch a variable named "_Jv_CLS" is written out. The
>>> assembly before and after the patch is the same, except for the
>>> variable name. I want to write out a nameless variable but I don't
>>> know how.
>>
>> Try tree_output_constant_def.
>
> I didn't know about this function. But as far as I can tell, there is
> no way to instruct that function to put the data in a specific
> section. In the Java case, the data must be put in the .jcr section. I
> suppose that can be achieved with a bit more re-working of varasm, but
> not with the code as-is. Thanks for the pointer, though!

It also doesn't appear to be possible to adjust the alignment via
tree_output_constant_def(), so going down that path seems more trouble
than it's worth.

Therefore, an RFA for the attached patch. Bootstrapped&tested on
powerpc64-unknown-linux-gnu. OK?

Ciao!
Steven
java/
	PR java/52730
	* class.c (emit_register_classes_in_jcr_section): New function.
	(emit_Jv_RegisterClass_calls): New function, split out from ...
	(emit_register_classes): ... here.  Reorganize.  Do not call
	output_constant.

Index: class.c
===
--- class.c	(revision 185813)
+++ class.c	(working copy)
@@ -2786,10 +2786,78 @@ emit_indirect_register_classes (tree *list_p)
   append_to_statement_list (t, list_p);
 }
 
+/* Emit a list of pointers to all classes we have emitted to JCR_SECTION.  */
 
+static void
+emit_register_classes_in_jcr_section (void)
+{
+  tree klass, cdecl, class_array_type;
+  int i;
+  int size = VEC_length (tree, registered_class);
+  VEC(constructor_elt,gc) *init = VEC_alloc (constructor_elt, gc, size);
+
+#ifndef JCR_SECTION_NAME
+  /* A target has defined TARGET_USE_JCR_SECTION,
+ but doesn't have a JCR_SECTION_NAME.  */
+  gcc_unreachable ();
+#endif
+
+  FOR_EACH_VEC_ELT (tree, registered_class, i, klass)
+CONSTRUCTOR_APPEND_ELT (init, NULL_TREE, build_fold_addr_expr (klass));
+
+  /* ??? I would like to use tree_output_constant_def() but there is no way
+	 to put the data in a named section name, or to set the alignment,
+	 via that function.  So do everything manually here.  */
+  class_array_type = build_prim_array_type (ptr_type_node, size);
+  cdecl = build_decl (UNKNOWN_LOCATION,
+		  VAR_DECL, get_identifier ("_Jv_JCR_SECTION_data"),
+		  class_array_type);
+  DECL_SECTION_NAME (cdecl) = build_string (strlen (JCR_SECTION_NAME),
+	JCR_SECTION_NAME);
+  DECL_ALIGN (cdecl) = POINTER_SIZE;
+  DECL_INITIAL (cdecl) = build_constructor (class_array_type, init);
+  TREE_CONSTANT (DECL_INITIAL (cdecl)) = 1;
+  TREE_STATIC (cdecl) = 1;
+  TREE_READONLY (cdecl) = 1;
+  TREE_CONSTANT (cdecl) = 1;
+  DECL_ARTIFICIAL (cdecl) = 1;
+  DECL_IGNORED_P (cdecl) = 1;
+  pushdecl_top_level (cdecl);
+  relayout_decl (cdecl);
+  rest_of_decl_compilation (cdecl, 1, 0);
+  mark_decl_referenced (cdecl);
+}
+
+
+/* Emit a series of calls to _Jv_RegisterClass for every class we emitted.
+   A series of calls is added to LIST_P.  */
+
+static void
+emit_Jv_RegisterClass_calls (tree *list_p)
+{
+  tree klass, t, register_class_fn;
+  int i;
+
+  t = build_function_type_list (void_type_node, class_ptr_type, NULL);
+  t = build_decl (input_location,
+		  FUNCTION_DECL, get_identifier ("_Jv_RegisterClass"), t);
+  TREE_PUBLIC (t) = 1;
+  DECL_EXTERNAL (t) = 1;
+  register_class_fn = t;
+
+  FOR_EACH_VEC_ELT (tree, registered_class, i, klass)
+{
+  t = build_fold_addr_expr (klass);
+  t = build_call_expr (register_class_fn, 1, t);
+  append_to_statement_list (t, list_p);
+}
+}
+
 /* Emit something to register classes at start-up time.
 
-   The preferred mechanism is through the .jcr section, which contain
+   The default mechanism is to generate instances at run-time.
+
+   An alternative mechanism is through the .jcr section, which contain
a list of pointers to classes which get registered during constructor
invocation time.
 
@@ -2803,55 +2871,18 @@ emit_register_classes (tree *list_p)
   if (registered_class == NULL)
 return;
 
+  /* By default, generate instances of Class at runtime.  */
   if (flag_indirect_classes)
-{
-  emit_indirect_register_classes (list_p);
-  return;
-}
-
+emit_indirect_register_classes (list_p);
   /* TARGET_USE_JCR_SECTION defaults to 1 if SUPPORTS_WEAK and
  TARGET_ASM_NAMED_SECTION, else 0.  Some targets meet those conditions
  but lack suitable crtbegin/end objects or linker support.  These
  targets can override the default in tm.h to use the fallback mechanism.  */
-  if (TARGET_USE_JCR_SECTION)
-{
-  tree klass, t;
-  int i;
-
-#ifdef JCR_SECTION_NAME
-  switch_to_section (get_section (JCR_SECTION_NAME, SECTION_WRITE, NULL));
-#else
-  /* A target has defined TARGET_USE_JCR_SECTION,
-	 but doesn't have a JCR_SECTION_NAME.  */
- 

Re: [Ping][PATCH, libstdc++-v3] Enable to cross-test libstdc++ on simulator

2012-03-27 Thread Terry Guo
Hello,

Thanks Paolo Carlini for pointing out that I should put code changes in
Makefile.am. This updated patch addresses this issue. Is it OK to trunk?

BR,
Terry

2012-03-26  Terry Guo  

* testsuite/Makefile.am (TEST_GCC_EXEC_PREFIX): New.
* testsuite/Makefile.in: Regenerated.

diff --git a/libstdc++-v3/testsuite/Makefile.am
b/libstdc++-v3/testsuite/Makefile.am
index 166bd16..7094ad5 100644
--- a/libstdc++-v3/testsuite/Makefile.am
+++ b/libstdc++-v3/testsuite/Makefile.am
@@ -60,6 +60,7 @@ site.exp: Makefile
@echo 'set libiconv "$(LIBICONV)"' >>site.tmp
@echo 'set baseline_dir "$(baseline_dir)"' >> site.tmp
@echo 'set baseline_subdir_switch "$(baseline_subdir_switch)"' >>
site.tmp
+   @echo 'set TEST_GCC_EXEC_PREFIX "$(libdir)/gcc/"' >> site.tmp
@echo '## All variables above are generated by configure. Do Not
Edit ##' >>site.tmp
@test ! -f site.exp || \
  sed '1,/^## All variables above are.*##/ d' site.exp >> site.tmp
diff --git a/libstdc++-v3/testsuite/Makefile.in
b/libstdc++-v3/testsuite/Makefile.in
index 8c91fd0..e433bb9 100644
--- a/libstdc++-v3/testsuite/Makefile.in
+++ b/libstdc++-v3/testsuite/Makefile.in
@@ -505,6 +505,7 @@ site.exp: Makefile
@echo 'set libiconv "$(LIBICONV)"' >>site.tmp
@echo 'set baseline_dir "$(baseline_dir)"' >> site.tmp
@echo 'set baseline_subdir_switch "$(baseline_subdir_switch)"' >>
site.tmp
+   @echo 'set TEST_GCC_EXEC_PREFIX "$(libdir)/gcc/"' >> site.tmp
@echo '## All variables above are generated by configure. Do Not
Edit ##' >>site.tmp
@test ! -f site.exp || \
  sed '1,/^## All variables above are.*##/ d' site.exp >> site.tmp

 




Re: [Ping][PATCH, libstdc++-v3] Enable to cross-test libstdc++ on simulator

2012-03-27 Thread Paolo Carlini

On 03/28/2012 03:15 AM, Terry Guo wrote:

Hello,

Thanks Paolo Carlini for pointing out that I should put code changes in
Makefile.am. This updated patch addresses this issue. Is it OK to trunk?

Sure, thanks.

Paolo.


Re: [PATCH] Fix sse2_loadlpd splitter (PR target/52736)

2012-03-27 Thread Uros Bizjak
On Tue, Mar 27, 2012 at 10:36 PM, Jakub Jelinek  wrote:

> As the following testcase shows, the sse2_loadlpd splitter when
> the destination (and at the same operand from which the second
> DFmode element is taken) is a MEM and the other DFmode operand
> is a register stores into wrong part of memory, it does what
> the sse2_loadhpd splitter does, while it should overwrite the
> first half of the vector and keep the second half preserved.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk/4.7/4.6?
>
> 2012-03-27  Jakub Jelinek  
>
>        PR target/52736
>        * config/i386/sse.md (sse2_loadlpd splitter): Use offset 0
>        instead of 8 in adjust_address.
>
>        * gcc.target/i386/pr52736.c: New test.

OK everywhere.

Thanks,
Uros.


Re: [lra] spilling general class pseudos into SSE regs instead of memory (a target hooks driven implementation)

2012-03-27 Thread Ye Joey
On Wed, Mar 28, 2012 at 1:07 AM, Vladimir Makarov  wrote:
>  The following patch implements general spilling one class pseudos
> into another class hard registers *instead of memory* in LRA.
Can't find the patch itself

- Joey


Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

2012-03-27 Thread Uros Bizjak
On Tue, Mar 27, 2012 at 7:20 PM, Richard Henderson  wrote:
> On 03/27/12 09:37, Uros Bizjak wrote:
>>> > Now, in this particular case, there might be another option to
>>> > avoid this hassle completely:  I understand that this UNSPEC is
>>> > simply a magic marker to make the address use the fs: or gs:
>>> > segment override, right?   Now that GCC supports address spaces,
>>> > it might be possible to model fs:/gs: relative addresses instead
>>> > by using a non-standard address space ...
>> This is an interesting idea, I will look into it.
>
> Generallized segment overrides via non-standard address spaces
> has been on my to-do list for quite a while...

What about release branches? While this issue didn't trigger there
yet, it can be triggered by some bad RA decision, and the fixup is
missing.

Uros.