[PATCH][SH] PR52667, Fix for barrier insertion
Hi Kaz, 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? Thanks, Chung-Lin 2012-03-27 Chung-Lin Tang clt...@codesourcery.com PR target/52667 * config/sh/sh.c (find_barrier): Add equality check of last_got to avoid going above orig insn. Update comments. Index: config/sh/sh.c === --- config/sh/sh.c (revision 185837) +++ config/sh/sh.c (working copy) @@ -4751,8 +4751,12 @@ find_barrier (int num_mova, rtx mova, rtx from) /* Don't emit a constant table int the middle of global pointer setting, since that that would move the addressing base GOT into another table. We need the first mov instruction before the _GLOBAL_OFFSET_TABLE_ -in the pool anyway, so just move up the whole constant pool. */ - if (last_got) +in the pool anyway, so just move up the whole constant pool. + +However, avoid doing so when the last single GOT mov is the starting +insn itself. Going past above the start insn would create a negative +offset, causing errors. */ + if (last_got last_got != orig) from = PREV_INSN (last_got); /* Don't insert the constant pool table at the position which
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
On Mon, 26 Mar 2012, Eric Botcazou wrote: Uh. When is a field a bit field though? At least stor-layout.c resets DECL_BIT_FIELD when local relative alignment is proper and the filed has an integer mode. That's overly optimistic if the record is placed at a bit position. Of course we still have DECL_BIT_FIELD_TYPE, but I wonder what the DECL_BIT_FIELD flag is for if we cannot really know whether the field in the end is a bitfield anyway... (what value do the various field-decls in a component-ref chain have anyway if the real interpretation is subject to the containing object, which might be even only specified by the type used for an indirect ref ...) We're talking about a bit field with record type here, so anything calculated within the record type in isolation is essentially invalidated for the bit field in question. Fortunately this only occurs in Ada, which doesn't use the very questionable C++ memory model (fingers crossed for the future. :-) ;) 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). Richard.
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
On Mon, 26 Mar 2012, Eric Botcazou wrote: The patch looks reasonable - can we compute this backward from the result of the outer get_inner_reference call and the outermost field-decl though? Or make get_inner_reference compute that while analyzing the full reference and return a flag? OTOH it shouldn't be too expensive. There are a lot of calls to get_inner_reference throughout the compiler though. And it is cheap if you compare it with the 4.7 code, which essentially does the same processing for _every_ field in the record (and even if the record object isn't a handled_component_p). Yes, indeed. One of the main motivation was to get rid of that quadratic complexity ... Richard.
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
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
On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher stevenb@gmail.com 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.C deleted assignment op (test for
errors, line 18)
FAIL: g++.dg/cpp0x/lambda/lambda-field-names.C no member named
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
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
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
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)
- GET_CODE (XEXP (x, 0)) == REG
-
Re: [Patch V2] libgfortran: do not assume libm
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 ging...@adacore.com
* 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_DEFINE([HAVE_COSHL],[1])])
Re: struct siginfo vs. siginfo_t
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 car...@systemhalted.org
wrote:
On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge
tho...@codesourcery.com 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 drep...@gmail.com
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 signal.h 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/config/i386/linux-unwind.h
@@ -139,9 +139,9 @@ x86_fallback_frame_state (struct _Unwind_Context *context,
{
struct rt_sigframe {
int sig;
- struct siginfo
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
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
On Tue, Mar 27, 2012 at 11:01, Tristan Gingold ging...@adacore.com 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
[PATCH, PR 52693] Do not construct memory accesses to unscalarizable regions
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 mjam...@suse.cz
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
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 jwakely@gmail.com
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
templatetypename _Tp
static _Tp _S_get(const _Class);
templatetypename _Tp
+ static _Tp _S_get(const volatile _Class);
+ templatetypename _Tp
static decltype(*std::declval_Tp()) _S_get(...);
public:
@@ -1814,6 +1817,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
templatetypename _Tp
static _Tp _S_get(const _Class);
templatetypename _Tp
+ static _Tp _S_get(const volatile _Class);
+ templatetypename _Tp
static decltype(*std::declval_Tp()) _S_get(...);
public:
@@ -1836,22 +1841,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
templatetypename _MemPtr, typename _Arg
struct _Result_of_impltrue, false, _MemPtr, _Arg
-: _Result_of_memobjtypename remove_reference_MemPtr::type, _Arg
-{
- typedef typename _Result_of_memobj
- typename remove_reference_MemPtr::type, _Arg::__type
- __type;
-};
+: _Result_of_memobjtypename decay_MemPtr::type, _Arg
+{ };
templatetypename _MemPtr, typename _Arg, typename... _ArgTypes
struct _Result_of_implfalse, true, _MemPtr, _Arg, _ArgTypes...
-: _Result_of_memfuntypename remove_reference_MemPtr::type, _Arg,
-_ArgTypes...
-{
- typedef typename _Result_of_memfun
- typename remove_reference_MemPtr::type, _Arg, _ArgTypes...::__type
- __type;
-};
+: _Result_of_memfuntypename decay_MemPtr::type, _Arg, _ArgTypes...
+{ };
templatetypename _Functor, typename... _ArgTypes
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
// http://www.gnu.org/licenses/.
-// { dg-error static assertion failed { target *-*-* } 1776 }
+// { dg-error static assertion failed { target *-*-* } 1777 }
#include utility
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
---
Re: [PATCH, PR 52693] Do not construct memory accesses to unscalarizable regions
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 mjam...@suse.cz
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 rguent...@suse.de
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
On Mar 27, 2012, at 10:38 AM, Janne Blomqvist wrote: On Tue, Mar 27, 2012 at 11:01, Tristan Gingold ging...@adacore.com 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][RFC] bail out after front-end errors
Hi, On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscherstevenb@gmail.com 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
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 ging...@adacore.com * 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
Oleg Endo oleg.e...@t-online.de 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
Chung-Lin Tang clt...@codesourcery.com 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 -
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 ramana.radhakrish...@linaro.org
* 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
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 avr/elf.h
Re: struct siginfo vs. siginfo_t
Thomas Schwinge tho...@codesourcery.com 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
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 rguent...@suse.de
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,
[RFC ivopts] ARM - Make ivopts take into account whether pre and post increments are actually supported on targets.
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: [PATCH, i386, Android] -mandroid support for i386 target
Ping
13 марта 2012 г. 15:13 пользователь Ilya Enkovich
enkovich@gmail.com написал:
Ping
27 февраля 2012 г. 6:41 пользователь Ilya Enkovich
enkovich@gmail.com написал:
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 ilya.enkov...@intel.com
* 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
Ping
13 марта 2012 г. 15:12 пользователь Ilya Enkovich
enkovich@gmail.com написал:
Ping
27 февраля 2012 г. 6:39 пользователь Ilya Enkovich
enkovich@gmail.com написал:
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 ilya.enkov...@intel.com
* 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
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
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
On Mon, Mar 26, 2012 at 9:03 PM, H.J. Lu hjl.to...@gmail.com wrote:
Attached patch fixes this situation by (partially) reloading only
remaining pseudo(s), leaving UNSPEC in the address RTX.
2012-03-26 Uros Bizjak ubiz...@gmail.com
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 ubiz...@gmail.com
H.J. Lu hongjiu...@intel.com
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
Sebastian Huber sebastian.hu...@embedded-brains.de 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
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
On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand uweig...@de.ibm.com 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
On Tue, Mar 27, 2012 at 9:37 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand uweig...@de.ibm.com 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_mode
[(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
On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu hjl.to...@gmail.com 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_mode
[(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)
Adds a new flag -fpph-statistics. When used, it shows various collected stats at the end of PPH processing. 2012-03-27 Diego Novillo dnovi...@google.com 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 dnovi...@google.com + + * c.opt (fpph-stats): Add flag. + 2012-03-15 Lawrence Crowl cr...@google.com * 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 dnovi...@google.com + + * 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 dnovi...@google.com * 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
[lra] spilling general class pseudos into SSE regs instead of memory (a target hooks driven implementation)
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 vmaka...@redhat.com * 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
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)
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
On Tue, Mar 27, 2012 at 9:57 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu hjl.to...@gmail.com 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_mode
[(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
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 hongjiu...@intel.com
* 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 @@
; http://www.gnu.org/licenses/.
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
Re: PATCH: Add OPTION_MASK_ISA_X86_64 and support TARGET_BI_ARCH == 2
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 hongjiu...@intel.com
* 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
http://www.gnu.org/licenses/. */
-#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_X32 is
+on and OPTION_MASK_ISA_X86_64 is off. We turn
Re: [Patch,avr] PR51345: Restore -mtiny-stack semantics
2012/3/27 Georg-Johann Lay a...@gjlay.de:
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
On Tue, Mar 27, 2012 at 7:28 PM, H.J. Lu hjl.to...@gmail.com 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
On Tue, Mar 27, 2012 at 10:53 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Mar 27, 2012 at 7:28 PM, H.J. Lu hjl.to...@gmail.com 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
On Tue, Mar 27, 2012 at 8:34 PM, H.J. Lu hjl.to...@gmail.com 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
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
On Tue, Mar 27, 2012 at 8:59 PM, Mike Stump mikest...@comcast.net 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
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)
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 dnovi...@google.com
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,
[wwwdocs] fix broken link to libstdc++ manual
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 @@ h4Runtime Library (libstdc++)/h4 ul -lia href=http://gcc.gnu.org/onlinedocs/gcc-4.7.0/libstdc++/manual/status.html#status.iso.200x; +lia href=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/a, including: ul
Re: [PATCH][ARM] NEON DImode not
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 a...@codesourcery.com 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 functional
* 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 jwakely@gmail.com
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 @@
// functional -*- 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)
templatetypename _Member, typename _Class
inline _Mem_fn_Member _Class::*
__callable_functor(_Member _Class::* __p)
-{ return mem_fn(__p); }
+{ return std::mem_fn(__p); }
templatetypename _Member, typename _Class
inline _Mem_fn_Member _Class::*
__callable_functor(_Member _Class::* const __p)
-{ return mem_fn(__p); }
+{ return std::mem_fn(__p); }
templatetypename _Signature
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
+// http://www.gnu.org/licenses/.
+
+#include functional
+
+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::functionint(X) fun(p);
+ return fun(x);
+}
+
[patch] Do not call output_constant from the front end
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
[PATCH] Fix sse2_loadlpd splitter (PR target/52736)
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 ja...@redhat.com
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 x86intrin.h
+
+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
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)
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 aurelien.buhrig@gmail.com 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
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 ebotca...@adacore.com 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
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
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 mead...@codesourcery.com
* 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
On Tue, Mar 27, 2012 at 11:07 PM, Eric Botcazou ebotca...@adacore.com 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
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 hongjiu...@intel.com
* 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_mode): 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 %tp_seg: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_mode
+ [(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
On Tue, Mar 27, 2012 at 11:51 PM, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Mar 27, 2012 at 11:07 PM, Eric Botcazou ebotca...@adacore.com 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. Bootstrappedtested 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
Re: [Ping][PATCH, libstdc++-v3] Enable to cross-test libstdc++ on simulator
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.
