[PATCH] testsuite tcl portability fix - avoid lreverse
Hi!
I've noticed
ERROR: (DejaGnu) proc "lreverse {{ASAN_OPTIONS 0}}" does not exist.
errors when regtesting gcc 4.8 on RHEL 5, it seems lreverse has been added
to tcl only in version 8.5.
Fixed thusly, ok for trunk?
2013-01-30 Jakub Jelinek
* lib/gcc-dg.exp (restore-target-env-var): Avoid using lreverse.
--- gcc/testsuite/lib/gcc-dg.exp.jj 2013-01-11 09:02:39.0 +0100
+++ gcc/testsuite/lib/gcc-dg.exp2013-01-30 09:04:02.540243886 +0100
@@ -305,7 +305,9 @@ proc set-target-env-var { } {
proc restore-target-env-var { } {
upvar 1 saved_target_env_var saved_target_env_var
-foreach env_var [lreverse $saved_target_env_var] {
+for { set env_vari [llength $saved_target_env_var] } {
+ [incr env_vari -1] >= 0 } {} {
+ set env_var [lindex $saved_target_env_var $env_vari]
set var [lindex $env_var 0]
if [lindex $env_var 1] {
setenv $var [lindex $env_var 2]
Jakub
Re: testsuite] clean up convoluted dg-final directive in vect-multitypes-12.c
On Thu, Jan 24, 2013 at 10:16:21AM +0100, Andreas Schwab wrote:
> Eric Botcazou writes:
>
> > ERROR: gcc.dg/vect/vect-multitypes-12.c: error executing dg-final: bad
> > index
> > "18-1": must be integer or end?-integer?
>
> Does that help? Perhaps the M-N feature isn't supported by your version
> of tcl.
>
> * lib/target-supports-dg.exp (dg-process-target): Use expr to
> evaluate the end index in string range.
Yes, this seems to help for tcl 8.4.13 and works also with 8.5.11 (where it
worked before too).
So, ok for trunk, thanks.
> --- a/gcc/testsuite/lib/target-supports-dg.exp
> +++ b/gcc/testsuite/lib/target-supports-dg.exp
> @@ -586,7 +586,7 @@ if { [info procs saved-dg-process-target] == [list] } {
> if [regexp "^target .* xfail .*" $selector] {
> set xfail_index [string first "xfail" $selector]
> set xfail_selector [string range $selector $xfail_index end]
> - set target_selector [string range $selector 0 $xfail_index-1]
> + set target_selector [string range $selector 0 [expr $xfail_index-1]]
> set target_selector [string trim $target_selector]
> if { [dg-process-target-1 $target_selector] == "N" } {
> return "N"
Jakub
[PATCH][ARM] use vsel instruction for floating point conditional moves in ARMv8
Hi all,
This patch uses the new ARMv8 AArch32 vsel instruction to implement
conditional moves of floating point numbers.
For example, an instruction of the form:
vsel.f32 s0, s1, s2
means
s0 := cond ? s1 : s2
This can be useful, among other places, in Thumb2 because it doesn't require
an enclosing IT block.
A small catch: The condition code used in vsel can only be one of {GE, GT,
EQ, VS}. If we want to use their negations {LT, LE, NE, VC} we just flip the
source operands.
A new predicate is introduced that checks that the comparison yields an ARM
condition code in the set {GE, GT, EQ, VS, LT, LE, NE, VC}.
New compilation tests are added. They pass on a model and no new regressions
on arm-none-eabi with qemu.
Ok for trunk?
Thanks,
Kyrill
gcc/ChangeLog
2013-01-30 Kyrylo Tkachov
* config/arm/arm.md (f_sels, f_seld): New types.
(*cmov): New pattern.
* config/arm/predicates.md (arm_vsel_comparison_operator): New
predicate.
gcc/testsuite/ChangeLog
2013-01-30 Kyrylo Tkachov
* gcc.target/arm/vseleqdf.c: New test.
* gcc.target/arm/vseleqsf.c: Likewise.
* gcc.target/arm/vselgedf.c: Likewise.
* gcc.target/arm/vselgesf.c: Likewise.
* gcc.target/arm/vselgtdf.c: Likewise.
* gcc.target/arm/vselgtsf.c: Likewise.
* gcc.target/arm/vselledf.c: Likewise.
* gcc.target/arm/vsellesf.c: Likewise.
* gcc.target/arm/vselltdf.c: Likewise.
* gcc.target/arm/vselltsf.c: Likewise.
* gcc.target/arm/vselnedf.c: Likewise.
* gcc.target/arm/vselnesf.c: Likewise.
* gcc.target/arm/vselvcdf.c: Likewise.
* gcc.target/arm/vselvcsf.c: Likewise.
* gcc.target/arm/vselvsdf.c: Likewise.
* gcc.target/arm/vselvssf.c: Likewise.diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index ac507ef..a6bd8bc 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -388,6 +388,8 @@
f_2_r,\
r_2_f,\
f_cvt,\
+ f_sels,\
+ f_seld,\
branch,\
call,\
load_byte,\
@@ -8140,6 +8142,39 @@
}"
)
+(define_insn "*cmov"
+[(set (match_operand:SDF 0 "s_register_operand" "=")
+ (if_then_else:SDF (match_operator 1 "arm_vsel_comparison_operator"
+ [(match_operand 2 "cc_register" "") (const_int 0)])
+ (match_operand:SDF 3 "s_register_operand"
+ "")
+ (match_operand:SDF 4 "s_register_operand"
+ "")))]
+ "TARGET_HARD_FLOAT && TARGET_FPU_ARMV8 "
+ "*
+ {
+enum arm_cond_code code = maybe_get_arm_condition_code (operands[1]);
+switch (code)
+ {
+ case ARM_GE:
+ case ARM_GT:
+ case ARM_EQ:
+ case ARM_VS:
+return \"vsel%d1.\\t%0, %3, %4\";
+ case ARM_LT:
+ case ARM_LE:
+ case ARM_NE:
+ case ARM_VC:
+return \"vsel%D1.\\t%0, %4, %3\";
+ default:
+gcc_unreachable ();
+ }
+return \"\";
+ }"
+ [(set_attr "conds" "use")
+ (set_attr "type" "f_sel")]
+)
+
(define_insn "*movsicc_insn"
[(set (match_operand:SI 0 "s_register_operand" "=r,r,r,r,r,r,r,r")
(if_then_else:SI
diff --git a/gcc/config/arm/predicates.md b/gcc/config/arm/predicates.md
index 8f49450..898f558 100644
--- a/gcc/config/arm/predicates.md
+++ b/gcc/config/arm/predicates.md
@@ -270,6 +270,18 @@
(define_special_predicate "lt_ge_comparison_operator"
(match_code "lt,ge"))
+;; The vsel instruction only accepts the ARM condition codes listed below.
+(define_special_predicate "arm_vsel_comparison_operator"
+ (and (match_operand 0 "expandable_comparison_operator")
+ (match_test "maybe_get_arm_condition_code (op) == ARM_GE
+|| maybe_get_arm_condition_code (op) == ARM_GT
+|| maybe_get_arm_condition_code (op) == ARM_EQ
+|| maybe_get_arm_condition_code (op) == ARM_VS
+|| maybe_get_arm_condition_code (op) == ARM_LT
+|| maybe_get_arm_condition_code (op) == ARM_LE
+|| maybe_get_arm_condition_code (op) == ARM_NE
+|| maybe_get_arm_condition_code (op) == ARM_VC")))
+
(define_special_predicate "noov_comparison_operator"
(match_code "lt,ge,eq,ne"))
diff --git a/gcc/testsuite/gcc.target/arm/vseleqdf.c
b/gcc/testsuite/gcc.target/arm/vseleqdf.c
new file mode 100644
index 000..86e147b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vseleqdf.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_v8_vfp } */
+
+double
+foo (double x, double y)
+{
+ volatile int i = 0;
+ return i == 0 ? x : y;
+}
+
+/* { dg-final { scan-assembler-times "vseleq.f64\td\[0-9\]+" 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/vseleqsf.c
b/gcc/testsuite/gcc.target/arm/vseleqsf.c
new file mode 100644
index 000..120f4
Re: [PATCH] Vtable pointer verification (corruption/attach detection -- new feature
On 11/01/2012 09:07 PM, Caroline Tice wrote: We have been developing a new security hardening feature for GCC that is designed to detect and handle (during program execution) when a vtable pointer that is about to be used for a virtual function call is not a valid vtable pointer for that call (i.e. it has become corrupted, possibly due to a hacker attack). We gave a presentation on this work at the Gnu Tools Cauldron in Prague last July. We now have the implementation fully working and are submitting this patch for review. We would like to get this into the next release of GCC if possible. Thanks for posting this collection of interesting patches. As far as I understand it, this changes ABI in the sense that every object file needs to contain the constructors that register the vtables, otherwise verification will later fail. If this data could be emitted in a declarative fashion, it might be possible to emit it by default, in a separate ELF section. This way, it is always there when needed, and it wouldn't have any performance impact if not used. I didn't look at the actual permitted-vtable set lookup in detail. How expensive is it? C++ virtual method calls are efficient, but they have their problems. The vtable needs relocation (contributing to startup cost), and we have the fragile base class problem (which severely constrains the evolution of separately-compiled base classes). Assuming that we need the vtable check and it has non-trivial cost, it might make sense to revamp C++ virtual method dispatch altogether, addressing both security and modularity issues. (Yes, I understand these two paragraphs go off in entirely different directions. 8-) -- Florian Weimer / Red Hat Product Security Team
Patch ping
Hi! http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01056.html PR55742 - P1 - fix multiversioning (i386 backend) http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01105.html PR55374 - put -lasan early on the command line with -fsanitize=address Jakub
Re: [Patch] PR56064: Fold VIEW_CONVERT_EXPR with FIXED_CST, Take #2
On Tue, Jan 29, 2013 at 9:00 PM, Georg-Johann Lay wrote: > Richard Biener wrote: >> Georg-Johann Lay wrote: >>> This is tentative patch as discussed in >>> >>> http://gcc.gnu.org/ml/gcc/2013-01/msg00187.html >>> >>> fold-const.c gets 2 new function native_encode_fixed and >>> native_interpret_fixed. Code common with the integer case is factored out >>> and >>> moved to the new constructor-like function double_int::from_buffer. >>> >>> The code bootstraps fine on x86-linux-gnu and I have test coverage from >>> avr-unknown-none. >>> >>> Ok to apply? >> >> Ok. >> >> Thanks, >> Richard. > > Let me drop this, I don't like the name "const_fixed_from_double_int". It's > bad and I think "fixed_from_double_int" is better. Other constructor-like > functions for FIXED_VALUE_TYPE use fixed_from_* whereas const_fixed_* returns > a > CONST_FIXED rtx. > > This is less confusing and fits better the naming convention. > > The new patch also adds const_fixed_from_double_int that actually returns a > CONST_FIXED rtx. It's unused, but I would use it in the avr back. > > Okay with that rename? (Or, at your option, without > const_fixed_from_double_int). Ok. Thanks, Richard. > Johann > > > PR tree-optimization/56064 > * fixed-value.c (fixed_from_double_int): New function. > * fixed-value.h (fixed_from_double_int): New prototype. > (const_fixed_from_double_int): New static inline function. > * fold-const.c (native_interpret_fixed): New static function. > (native_interpret_expr) : Use it. > (can_native_interpret_type_p) : Return true. > (native_encode_fixed): New static function. > (native_encode_expr) : Use it. > (native_interpret_int): Move double_int worker code to... > * double-int.c (double_int::from_buffer): ...this new static method. > * double-int.h (double_int::from_buffer): Prototype it. > > testsuite/ > PR tree-optimization/56064 > * gcc.dg/fixed-point/view-convert.c: New test. > > > >> >>> There are less intrusive solutions that only handle the int <-> fixed cases, >>> for example fold-const.c:fold_view_convert_expr() could test for these cases >>> and use double_int directly without serializing / deserializing through a >>> memory buffer. >>> >>> Johann >>> >>> >>> PR tree-optimization/56064 >>> * fixed-value.c (const_fixed_from_double_int): New function. >>> * fixed-value.h (const_fixed_from_double_int): New prototype. >>> * fold-const.c (native_interpret_fixed): New static function. >>> (native_interpret_expr) : Use it. >>> (can_native_interpret_type_p) : Return true. >>> (native_encode_fixed): New static function. >>> (native_encode_expr) : Use it. >>> (native_interpret_int): Move double_int worker code to... >>> * double-int.c (double_int::from_buffer): ...this new static method. >>> * double-int.h (double_int::from_buffer): Prototype it. >>> >>> testsuite/ >>> PR tree-optimization/56064 >>> * gcc.dg/fixed-point/view-convert.c: New test. >> >
[patch libiberty's include]: Fixes PR 39064 and partial PR 54620
Hi, this patch fixes for targets with sys/types.h the issue that wrong assumptions about pointer-sizes are used. Instead it uses uintptr_t/intptr_t. ChangeLog /include 2013-01-30 Kai Tietz PR other/54620 PR target/39064 * md5.h: Include sys/types.h if HAVE_SYS_TYPES_H is defined. * sha1.h: Likewise. Tested for x86_64-unknown-linux-gnu, x86_64-w64-mingw32, and i686-w64-mingw32. Ok for apply? Regards, Kai Index: md5.h === --- md5.h (Revision 195288) +++ md5.h (Arbeitskopie) @@ -36,7 +36,7 @@ the resulting executable. Locally running cross-compiled executables is usually not possible. */ -#ifdef _LIBC +#if defined (_LIBC) || defined (HAVE_SYS_TYPES_H) # include typedef u_int32_t md5_uint32; typedef uintptr_t md5_uintptr; Index: sha1.h === --- sha1.h (Revision 195288) +++ sha1.h (Arbeitskopie) @@ -35,7 +35,7 @@ the resulting executable. Locally running cross-compiled executables is usually not possible. */ -#ifdef _LIBC +#if defined (_LIBC) || defined (HAVE_SYS_TYPES_H) # include typedef u_int32_t sha1_uint32; typedef uintptr_t sha1_uintptr;
Re: [PATCH] Small cleanup in cleanup_cfg
On Tue, Jan 29, 2013 at 4:49 PM, Marek Polacek wrote:
> I don't see any reason why we'd want to mark BBs in this case,
> changed_bbs are thrown away right after fix_loop_structure
> marks them.
>
> Regtested/bootstrapped on x86_64-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2013-01-29 Marek Polacek
>
> * cfgcleanup.c (cleanup_cfg): Don't mark affected BBs.
>
> --- gcc/cfgcleanup.c.mp 2013-01-29 13:53:21.740473075 +0100
> +++ gcc/cfgcleanup.c2013-01-29 13:53:27.942491341 +0100
> @@ -3017,14 +3017,11 @@ cleanup_cfg (int mode)
>&& (changed
> || (mode & CLEANUP_CFG_CHANGED)))
> {
> - bitmap changed_bbs;
>timevar_push (TV_REPAIR_LOOPS);
>/* The above doesn't preserve dominance info if available. */
>gcc_assert (!dom_info_available_p (CDI_DOMINATORS));
>calculate_dominance_info (CDI_DOMINATORS);
> - changed_bbs = BITMAP_ALLOC (NULL);
> - fix_loop_structure (changed_bbs);
> - BITMAP_FREE (changed_bbs);
> + fix_loop_structure (NULL);
>free_dominance_info (CDI_DOMINATORS);
>timevar_pop (TV_REPAIR_LOOPS);
> }
>
> Marek
Re: [PATCH] Fix RTL fwprop compile-time for PR56113
On Wed, 30 Jan 2013, Steven Bosscher wrote:
> On Wed, Jan 30, 2013 at 12:01 AM, Steven Bosscher wrote:
> > To prevent that mistake in the future, I've add an assert in dominance.c.
>
> Hmm, that worked with my release-checking compiler of course, but
> fails in at least tree-ssa-dom.c (same as for fwprop.c,
> loop_optimizer_init destroys fast queries) and tree-ssa-loop-im.c (not
> sure yet why).
>
> NB, the fwprop.c change is independent and should go in. The domwalk.c
> thing is something to maybe postpone to gcc 4.9.
The fwprop.c change is ok - fwprop.c doesn't seem to care about
identified latches or preheaders.
Now, I wonder what part of loop_optimizer_init wrecks dominance
info - I _suppose_ it's disambiguate_loops_with_multiple_latches (),
but that only ends up calling make_forwarder_block which looks like
it has code to fix dominators via iterate_fix_dominators ().
Hmm, it seems to be
make_forwarder_block (basic_block bb, bool (*redirect_edge_p) (edge),
void (*new_bb_cbk) (basic_block))
{
...
fallthru = split_block_after_labels (bb);
that sets DOM_NO_FAST_QUERY via add_to_dominance_info () via
create_basic_block. Then split_block () does
482 if (dom_info_available_p (CDI_DOMINATORS))
483 {
484 redirect_immediate_dominators (CDI_DOMINATORS, bb, new_bb);
485 set_immediate_dominator (CDI_DOMINATORS, new_bb, bb);
486 }
but that doesn't set dominance info to DOM_OK again. The
iterate_fix_dominators doesn't do that either.
IMHO at least split_block () should be able to preserve fast queries?
Thanks,
Richard.
> Testing this patch now:
>
> Index: domwalk.c
> ===
> --- domwalk.c (revision 195559)
> +++ domwalk.c (working copy)
> @@ -147,8 +147,17 @@ walk_dominator_tree (struct dom_walk_dat
>bitmap_clear (visited);
>bitmap_set_bit (visited, ENTRY_BLOCK_PTR->index);
>
> + /* Make sure dominance information is available, and compute fast queries
> + if necessary. */
> + gcc_assert (dom_info_state (walk_data->dom_direction) >=
> DOM_NO_FAST_QUERY);
> + calculate_dominance_info (walk_data->dom_direction);
> +
>while (true)
> {
> + /* Thou shall not modify the dominator tree while walking it
> + (nor present it without fast queries available). */
> + gcc_assert (dom_info_state (walk_data->dom_direction) == DOM_OK);
> +
>/* Don't worry about unreachable blocks. */
>if (EDGE_COUNT (bb->preds) > 0
> || bb == ENTRY_BLOCK_PTR
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend
Re: [PATCH] Add faster HTM fastpath for libitm TSX v2
On Tue, 2013-01-29 at 20:19 +0100, Andi Kleen wrote:
> > next time please reply to the points raised in a review if you disagree
> > with them, and don't just ignore them. That speeds up the review.
>
> It was all in the previous email on the topic.
This v2 patch did not incorporate all the changes that I requested, nor
did you explicitly object to those you didn't incorporate. Maybe you
don't care what's in libitm's comments, but I do.
> > > // See gtm_thread::begin_transaction.
> > > -uint32_t GTM::htm_fastpath = 0;
> > > +uint32_t GTM::htm_fastpath asm("__gtm_htm_fastpath") = 0;
> > > +
> > > +uint32_t *GTM::global_lock asm("__gtm_global_lock");
> >
> > Rearrange the serial lock's fields (see below).
>
> To my knowledge C++ classes have no guaranteed layout,
> so that's not safe because there is no guarantee where
> the vtable pointers are. it would be only with plain old structs.
And gtm_rwlock doesn't have any virtual members, right? So it's like a
plain old struct (ie, it's a POD type).
> + // pr_tryHTM can be set by an assembler fast path when it already
> tried
> + // a hardware transaction once. In this case we do one retry less.
>
> pr_tryHTM is already documented.
And I asked you to simply reference this in a comment. What's the
problem with that? I do not want people working on libitm to have to
grep through the code for uses of pr_tryHTM and look for comments that
might be related to it just because you don't want to put a simple
reference into the comment at the declaration of pr_tryHTM. Can't you
see that adding the reference is just plain useful for everybody else?
Torvald
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On 01/28/13 16:07, David Edelsohn wrote: > On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner > wrote: > >> But still curious if you've been able to reproduce the problem, >> and why you didn't encounter this problem beforehand. > > As I mentioned before, because of --boot-ld-flags, with earlier libgcc > and libstdc++ installed in that directory. But why didn't the RPATH_ENVVAR=LD_LIBRARY_PATH break for you when libatomic is configured (in stage3) for ppc64 because of this workflow I can see there: 1: gcc/xgcc is linked by prev-gcc/xg++ 1.1: against *dynamic* libstdc++.a 1.2: from prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/, 1.3: which is stored as runpath. 2: For a target-library (libstdc++, libatomic, ...), and for each multilib-variant (32/64, pthread yes/no) 2.1: LD_LIBRARY_PATH is set to that multilib variant's libstdc++.a dir 3: So LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using 32bit gcc/xgcc to build 64bit libstdc++.a. => This does /not/ break, as that libstdc++.a is not there yet. 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using 32bit gcc/xgcc to build libatomic.a. => This is the one that /does/ break, as that 64bit libstdc++.a is there now. The only situation of wich I can think of not breaking here would be: * --boot-ldflags are first on the linkline, and * libstdc++.a found there is static only. Or what important thing I could have missed? Thanks! /haubi/
[PATCH] Fix PR56147
This fixes PR56147 - we have to care for mismatched symbol kinds
during merging.
Committed as obvious. (lto.exp doesn't understand dg-error for
link-time issues, so no testcase)
Richard.
2013-01-30 Richard Biener
PR lto/56147
* lto-symtab.c (lto_symtab_merge_decls_1): Guard DECL_BUILT_IN
check.
Index: gcc/lto-symtab.c
===
*** gcc/lto-symtab.c(revision 195574)
--- gcc/lto-symtab.c(working copy)
*** lto_symtab_merge_decls_1 (symtab_node fi
*** 443,449
else if (TREE_CODE (prevailing->symbol.decl) == FUNCTION_DECL)
{
for (e = first; e; e = e->symbol.next_sharing_asm_name)
! if (DECL_BUILT_IN (e->symbol.decl))
{
prevailing = e;
break;
--- 443,450
else if (TREE_CODE (prevailing->symbol.decl) == FUNCTION_DECL)
{
for (e = first; e; e = e->symbol.next_sharing_asm_name)
! if (TREE_CODE (e->symbol.decl) == FUNCTION_DECL
! && DECL_BUILT_IN (e->symbol.decl))
{
prevailing = e;
break;
Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)
OK. Sriraman, are you working on documentation and more tests? Jason
[PATCH] Speed up IDF compute a tiny bit
While looking into speeding up incremental SSA update for PR56113
(it's IDF compute slowness) I played with optimizing IDF compute
itself. One obvious thing that speeds it up by 5% is to use
quick_push in the innermost loop. When experimenting with using
a sparseset for the worklist to avoid iterating multiple times
I noticed its workers have embedded gcc_assert()s which prevents
them from being inlined. Thus, fixed as well.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
As for the IDF slowness - I suppose a different PHI insertion
strategy that is not quadratic would be nice.
Richard.
2013-01-30 Richard Biener
* sparseset.h (sparseset_bit_p): Use gcc_checking_assert.
(sparseset_pop): Likewise.
* cfganal.c (compute_idf): Likewise. Increase work-stack size
to be able to use quick_push in the worker loop.
Index: gcc/sparseset.h
===
*** gcc/sparseset.h (revision 195574)
--- gcc/sparseset.h (working copy)
*** sparseset_bit_p (sparseset s, SPARSESET_
*** 140,146
{
SPARSESET_ELT_TYPE idx;
! gcc_assert (e < s->size);
idx = s->sparse[e];
--- 140,146
{
SPARSESET_ELT_TYPE idx;
! gcc_checking_assert (e < s->size);
idx = s->sparse[e];
*** sparseset_pop (sparseset s)
*** 174,180
{
SPARSESET_ELT_TYPE mem = s->members;
! gcc_assert (mem != 0);
s->members = mem - 1;
return s->dense[mem];
--- 174,180
{
SPARSESET_ELT_TYPE mem = s->members;
! gcc_checking_assert (mem != 0);
s->members = mem - 1;
return s->dense[mem];
Index: gcc/cfganal.c
===
*** gcc/cfganal.c (revision 195574)
--- gcc/cfganal.c (working copy)
*** compute_idf (bitmap def_blocks, bitmap_h
*** 1141,1147
vec work_stack;
bitmap phi_insertion_points;
! work_stack.create (n_basic_blocks);
phi_insertion_points = BITMAP_ALLOC (NULL);
/* Seed the work list with all the blocks in DEF_BLOCKS. We use
--- 1141,1148
vec work_stack;
bitmap phi_insertion_points;
! /* Each block can appear at most twice on the work-stack. */
! work_stack.create (2 * n_basic_blocks);
phi_insertion_points = BITMAP_ALLOC (NULL);
/* Seed the work list with all the blocks in DEF_BLOCKS. We use
*** compute_idf (bitmap def_blocks, bitmap_h
*** 1165,1179
form, the basic blocks where new and/or old names are defined
may have disappeared by CFG cleanup calls. In this case,
we may pull a non-existing block from the work stack. */
! gcc_assert (bb_index < (unsigned) last_basic_block);
EXECUTE_IF_AND_COMPL_IN_BITMAP (&dfs[bb_index], phi_insertion_points,
0, i, bi)
{
! /* Use a safe push because if there is a definition of VAR
!in every basic block, then WORK_STACK may eventually have
!more than N_BASIC_BLOCK entries. */
! work_stack.safe_push (i);
bitmap_set_bit (phi_insertion_points, i);
}
}
--- 1166,1177
form, the basic blocks where new and/or old names are defined
may have disappeared by CFG cleanup calls. In this case,
we may pull a non-existing block from the work stack. */
! gcc_checking_assert (bb_index < (unsigned) last_basic_block);
EXECUTE_IF_AND_COMPL_IN_BITMAP (&dfs[bb_index], phi_insertion_points,
0, i, bi)
{
! work_stack.quick_push (i);
bitmap_set_bit (phi_insertion_points, i);
}
}
Re: [PATCH] Fix RTL fwprop compile-time for PR56113
Hi,
On Wed, 30 Jan 2013, Richard Biener wrote:
> 483 {
> 484 redirect_immediate_dominators (CDI_DOMINATORS, bb, new_bb);
> 485 set_immediate_dominator (CDI_DOMINATORS, new_bb, bb);
> 486 }
>
> but that doesn't set dominance info to DOM_OK again. The
> iterate_fix_dominators doesn't do that either.
>
> IMHO at least split_block () should be able to preserve fast queries?
I don't see how. Fast queries rely on DFS in and out numbers of the
dominance tree being correct. If you insert a node in a tree the
DFS numbers of all nodes after it need to change, i.e. updating fast
queries for a single-block change is O(n_basic_blocks).
Ciao,
Michael.
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On Wed, Jan 30, 2013 at 6:35 AM, Michael Haubenwallner wrote: > But why didn't the RPATH_ENVVAR=LD_LIBRARY_PATH break for you when libatomic > is configured (in stage3) for ppc64 because of this workflow I can see there: > > 1: gcc/xgcc is linked by prev-gcc/xg++ > 1.1: against *dynamic* libstdc++.a > 1.2: from prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/, > 1.3: which is stored as runpath. > > 2: For a target-library (libstdc++, libatomic, ...), >and for each multilib-variant (32/64, pthread yes/no) > 2.1: LD_LIBRARY_PATH is set to that multilib variant's libstdc++.a dir > > 3: So LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using >32bit gcc/xgcc to build 64bit libstdc++.a. > => This does /not/ break, as that libstdc++.a is not there yet. > > 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using >32bit gcc/xgcc to build libatomic.a. > => This is the one that /does/ break, as that 64bit libstdc++.a is there now. > > The only situation of wich I can think of not breaking here would be: > * --boot-ldflags are first on the linkline, and > * libstdc++.a found there is static only. > > Or what important thing I could have missed? Originally, I was using --boot-ld-flags which included /usr/gnu/lib first in the path, so an older version of libstdc++ was found. Now, after your patch, cc1plus is statically linked with libstdc++.a. - David
Re: [patch libiberty's include]: Fixes PR 39064 and partial PR 54620
On Wed, Jan 30, 2013 at 2:53 AM, Kai Tietz wrote: > > this patch fixes for targets with sys/types.h the issue that wrong > assumptions about pointer-sizes are used. > Instead it uses uintptr_t/intptr_t. > > ChangeLog /include > > 2013-01-30 Kai Tietz > > PR other/54620 > PR target/39064 > * md5.h: Include sys/types.h if HAVE_SYS_TYPES_H > is defined. > * sha1.h: Likewise. > > Tested for x86_64-unknown-linux-gnu, x86_64-w64-mingw32, and > i686-w64-mingw32. Ok for apply? > > Regards, > Kai > > Index: md5.h > === > --- md5.h (Revision 195288) > +++ md5.h (Arbeitskopie) > @@ -36,7 +36,7 @@ > the resulting executable. Locally running cross-compiled executables > is usually not possible. */ > > -#ifdef _LIBC > +#if defined (_LIBC) || defined (HAVE_SYS_TYPES_H) > # include > typedef u_int32_t md5_uint32; > typedef uintptr_t md5_uintptr; > Index: sha1.h > === > --- sha1.h (Revision 195288) > +++ sha1.h (Arbeitskopie) > @@ -35,7 +35,7 @@ > the resulting executable. Locally running cross-compiled executables > is usually not possible. */ > > -#ifdef _LIBC > +#if defined (_LIBC) || defined (HAVE_SYS_TYPES_H) > # include > typedef u_int32_t sha1_uint32; > typedef uintptr_t sha1_uintptr; This code is intended to be highly portable. I don't have a problem with uintptr_t, but I'm not certain that on all systems defines u_int32_t. Ian
Re: [patch libiberty's include]: Fixes PR 39064 and partial PR 54620
2013/1/30 Ian Lance Taylor : > On Wed, Jan 30, 2013 at 2:53 AM, Kai Tietz wrote: >> >> this patch fixes for targets with sys/types.h the issue that wrong >> assumptions about pointer-sizes are used. >> Instead it uses uintptr_t/intptr_t. >> >> ChangeLog /include >> >> 2013-01-30 Kai Tietz >> >> PR other/54620 >> PR target/39064 >> * md5.h: Include sys/types.h if HAVE_SYS_TYPES_H >> is defined. >> * sha1.h: Likewise. >> >> Tested for x86_64-unknown-linux-gnu, x86_64-w64-mingw32, and >> i686-w64-mingw32. Ok for apply? >> >> Regards, >> Kai >> >> Index: md5.h >> === >> --- md5.h (Revision 195288) >> +++ md5.h (Arbeitskopie) >> @@ -36,7 +36,7 @@ >> the resulting executable. Locally running cross-compiled executables >> is usually not possible. */ >> >> -#ifdef _LIBC >> +#if defined (_LIBC) || defined (HAVE_SYS_TYPES_H) >> # include >> typedef u_int32_t md5_uint32; >> typedef uintptr_t md5_uintptr; >> Index: sha1.h >> === >> --- sha1.h (Revision 195288) >> +++ sha1.h (Arbeitskopie) >> @@ -35,7 +35,7 @@ >> the resulting executable. Locally running cross-compiled executables >> is usually not possible. */ >> >> -#ifdef _LIBC >> +#if defined (_LIBC) || defined (HAVE_SYS_TYPES_H) >> # include >> typedef u_int32_t sha1_uint32; >> typedef uintptr_t sha1_uintptr; > > > > This code is intended to be highly portable. I don't have a problem > with uintptr_t, but I'm not certain that on all systems > defines u_int32_t. > > Ian Yes, this is a valid point. The (u)int??_t types aren't necessarily declared by including sys/types.h. So what's about the following patch. If stdint.h header is present, then we should include it and then we can assume that the (u)int??_t types are present. Index: md5.h === --- md5.h (Revision 195572) +++ md5.h (Arbeitskopie) @@ -36,7 +36,11 @@ the resulting executable. Locally running cross-compiled executables is usually not possible. */ -#ifdef _LIBC +#ifdef HAVE_STDINT_H +#include +#endif + +#if defined (_LIBC) || (defined (HAVE_SYS_TYPES_H) && defined (HAVE_STDINT_H)) # include typedef u_int32_t md5_uint32; typedef uintptr_t md5_uintptr; Index: sha1.h === --- sha1.h (Revision 195572) +++ sha1.h (Arbeitskopie) @@ -35,7 +35,11 @@ the resulting executable. Locally running cross-compiled executables is usually not possible. */ -#ifdef _LIBC +#ifdef HAVE_STDINT_H +#include +#endif + +#if defined (_LIBC) || (defined (HAVE_SYS_TYPES_H) && defined (HAVE_STDINT_H)) # include typedef u_int32_t sha1_uint32; typedef uintptr_t sha1_uintptr;
Re: [PATCH] Put -lasan always very early on the ld command line (PR sanitizer/55374)
Looks good to me. OK if nobody else responds today. Jason
Re: [patch libiberty's include]: Fixes PR 39064 and partial PR 54620
Kai Tietz writes: > Yes, this is a valid point. The (u)int??_t types aren't necessarily > declared by including sys/types.h. So what's about the following > patch. If stdint.h header is present, then we should include it and > then we can assume that the (u)int??_t types are present. This is wrong: provides e.g. uint32_t, but not u_int32_t. The latter is a BSDism. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch libiberty's include]: Fixes PR 39064 and partial PR 54620
Hmm, I see ... so we need an new condition. Is it ok to apply? Thanks, Kai Index: md5.h === --- md5.h (Revision 195572) +++ md5.h (Arbeitskopie) @@ -40,6 +40,11 @@ # include typedef u_int32_t md5_uint32; typedef uintptr_t md5_uintptr; +#elif defined (HAVE_SYS_TYPES_H) && defined (HAVE_STDINT_H) +#include +#include +typedef uint32_t md5_uint32; +typedef uintptr_t md5_uintptr; #else # define INT_MAX_32_BITS 2147483647 Index: sha1.h === --- sha1.h (Revision 195572) +++ sha1.h (Arbeitskopie) @@ -39,6 +39,11 @@ # include typedef u_int32_t sha1_uint32; typedef uintptr_t sha1_uintptr; +#elif defined (HAVE_SYS_TYPES_H) && defined (HAVE_STDINT_H) +#include +#include +typedef uint32_t sha1_uint32; +typedef uintptr_t sha1_uintptr; #else # define INT_MAX_32_BITS 2147483647
Re: [PATCH] Put -lasan always very early on the ld command line (PR sanitizer/55374)
Jakub Jelinek writes:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2013-01-22 Jakub Jelinek
>
> PR sanitizer/55374
> * gcc.c (LIBASAN_SPEC): Define just to ADD_STATIC_LIBASAN_LIBS if
> LIBASAN_EARLY_SPEC is defined.
> (LIBASAN_EARLY_SPEC): Define to empty string if not already defined.
> (LINK_COMMAND_SPEC): Add LIBASAN_EARLY_SPEC for -fsanitize=address,
> before %o.
> * config/gnu-user.h (LIBASAN_EARLY_SPEC): Define.
>
> * g++.dg/asan/large-func-test-1.C: Allow both _Zna[jm] in addition
> to _Znw[jm] in the backtrace. Allow _Zna[jm] to be the first frame
> printed in backtrace.
> * g++.dg/asan/deep-stack-uaf-1.C: Use malloc instead of operator new
> to avoid errors about mismatched allocation vs. deallocation.
This looks okay for me. Sorry for the delay.
As an aside, I am curious why about ...
> --- gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C.jj 2012-12-14
> 16:24:38.0 +0100
> +++ gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C 2013-01-22
> 16:43:03.337091101 +0100
> @@ -27,7 +27,7 @@ struct DeepFree<0> {
> };
>
> int main() {
> - char *x = new char[10];
> + char *x = (char*)malloc(10);
>// deep_free(x);
>DeepFree<200>::free(x);
>return x[5];
... why/how this is falling when -lasan comes before -lstdc++?
--
Dodji
Re: [PATCH] Put -lasan always very early on the ld command line (PR sanitizer/55374)
On Wed, Jan 30, 2013 at 04:04:55PM +0100, Dodji Seketeli wrote:
> As an aside, I am curious why about ...
>
> > --- gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C.jj 2012-12-14
> > 16:24:38.0 +0100
> > +++ gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C2013-01-22
> > 16:43:03.337091101 +0100
> > @@ -27,7 +27,7 @@ struct DeepFree<0> {
> > };
> >
> > int main() {
> > - char *x = new char[10];
> > + char *x = (char*)malloc(10);
> >// deep_free(x);
> >DeepFree<200>::free(x);
> >return x[5];
>
> ... why/how this is falling when -lasan comes before -lstdc++?
libasan has added recently support for operator new and operator new[]
checking, which checks that there is not a mismatch between the way
how object is allocated (malloc/calloc/realloc vs. operator new vs. operator
new[]) and how it is deallocated (free vs. delete vs. delete[]). The
deep-stack-uaf-1.C testcase has been violating this (new char[10]
allocation, free (x) deallocation) and has been changed upstream
when those changes landed into libasan. When -lstdc++ came first,
the -lasan operator new interceptor wasn't called (because libstdc++'s
operator new was earlier in search scope) and thus it appeared as calling
malloc and doing free to -lasan.
Jakub
Re: [patch libiberty's include]: Fixes PR 39064 and partial PR 54620
On Wed, Jan 30, 2013 at 7:03 AM, Kai Tietz wrote: > Hmm, I see ... so we need an new condition. > > Is it ok to apply? This version is OK if it bootstraps. Thanks. Ian
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On 01/30/2013 03:16 PM, David Edelsohn wrote: > wrote: >> 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using >>32bit gcc/xgcc to build libatomic.a. >> => This is the one that /does/ break, as that 64bit libstdc++.a is there now. > Originally, I was using --boot-ld-flags which included /usr/gnu/lib > first in the path, so an older version of libstdc++ was found. Yes, but - sorry for being nit-picky - could you find out if your /usr/gnu/lib/libstdc++.a was a static-only archive? > Now, after your patch, cc1plus is statically linked with libstdc++.a. Yes, although the problem was with xgcc already (before cc1plus is executed). /haubi/
[PATCH][ARM][1/2] Load-acquire, store-release atomics in AArch32 ARMv8
Hi all,
This patch implements the atomic built-ins using the new ARMv8 load-acquire
and store-release instructions.
They allow us to generate barrier-free code for a variety of atomic
operations such as: atomic load, atomic store, atomic compare and swap,
atomic {or, and, add, sub, xor}.
Tests will come in a separate patch soon.
No regressions on arm-none-eabi. Bootstrap on armv7l-unknown-linux-gnueabihf
successful.
Ok for trunk (now or when stage 1 reopens)?
Thanks,
Kyrill
gcc/ChangeLog
2013-01-23 Kyrylo Tkachov
* config/arm/arm.c (arm_emit_load_exclusive): Add acq parameter.
Emit load-acquire versions when acq is true.
(arm_emit_store_exclusive): Add rel parameter.
Emit store-release versions when rel is true.
(arm_split_compare_and_swap): Use acquire-release instructions
instead
of barriers when appropriate.
(arm_split_atomic_op): Likewise.
* config/arm/arm.h (TARGET_HAVE_LDACQ): New macro.
* config/arm/unspecs.md (VUNSPEC_LAX): New unspec.
(VUNSPEC_SLX): Likewise.
(VUNSPEC_LDA): Likewise.
(VUNSPEC_STL): Likewise.
* config/arm/sync.md (atomic_load): New pattern.
(atomic_store): Likewise.
(arm_load_acquire_exclusive): Likewise.
(arm_load_acquire_exclusivesi): Likewise.
(arm_load_acquire_exclusivedi): Likewise.
(arm_store_release_exclusive): Likewise.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 9d3981d..f989f54 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -25999,39 +25999,71 @@ arm_post_atomic_barrier (enum memmodel model)
emit_insn (gen_memory_barrier ());
}
-/* Emit the load-exclusive and store-exclusive instructions. */
+/* Emit the load-exclusive and store-exclusive instructions.
+ Use acquire and release versions if necessary. */
static void
-arm_emit_load_exclusive (enum machine_mode mode, rtx rval, rtx mem)
+arm_emit_load_exclusive (enum machine_mode mode, rtx rval, rtx mem, bool acq)
{
rtx (*gen) (rtx, rtx);
- switch (mode)
+ if (acq)
{
-case QImode: gen = gen_arm_load_exclusiveqi; break;
-case HImode: gen = gen_arm_load_exclusivehi; break;
-case SImode: gen = gen_arm_load_exclusivesi; break;
-case DImode: gen = gen_arm_load_exclusivedi; break;
-default:
- gcc_unreachable ();
+ switch (mode)
+{
+case QImode: gen = gen_arm_load_acquire_exclusiveqi; break;
+case HImode: gen = gen_arm_load_acquire_exclusivehi; break;
+case SImode: gen = gen_arm_load_acquire_exclusivesi; break;
+case DImode: gen = gen_arm_load_acquire_exclusivedi; break;
+default:
+ gcc_unreachable ();
+}
+}
+ else
+{
+ switch (mode)
+{
+case QImode: gen = gen_arm_load_exclusiveqi; break;
+case HImode: gen = gen_arm_load_exclusivehi; break;
+case SImode: gen = gen_arm_load_exclusivesi; break;
+case DImode: gen = gen_arm_load_exclusivedi; break;
+default:
+ gcc_unreachable ();
+}
}
emit_insn (gen (rval, mem));
}
static void
-arm_emit_store_exclusive (enum machine_mode mode, rtx bval, rtx rval, rtx mem)
+arm_emit_store_exclusive (enum machine_mode mode, rtx bval, rtx rval,
+ rtx mem, bool rel)
{
rtx (*gen) (rtx, rtx, rtx);
- switch (mode)
+ if (rel)
{
-case QImode: gen = gen_arm_store_exclusiveqi; break;
-case HImode: gen = gen_arm_store_exclusivehi; break;
-case SImode: gen = gen_arm_store_exclusivesi; break;
-case DImode: gen = gen_arm_store_exclusivedi; break;
-default:
- gcc_unreachable ();
+ switch (mode)
+{
+case QImode: gen = gen_arm_store_release_exclusiveqi; break;
+case HImode: gen = gen_arm_store_release_exclusivehi; break;
+case SImode: gen = gen_arm_store_release_exclusivesi; break;
+case DImode: gen = gen_arm_store_release_exclusivedi; break;
+default:
+ gcc_unreachable ();
+}
+}
+ else
+{
+ switch (mode)
+{
+case QImode: gen = gen_arm_store_exclusiveqi; break;
+case HImode: gen = gen_arm_store_exclusivehi; break;
+case SImode: gen = gen_arm_store_exclusivesi; break;
+case DImode: gen = gen_arm_store_exclusivedi; break;
+default:
+ gcc_unreachable ();
+}
}
emit_insn (gen (bval, rval, mem));
@@ -26067,6 +26099,15 @@ arm_expand_compare_and_swap (rtx operands[])
mod_f = operands[7];
mode = GET_MODE (mem);
+ /* Normally the succ memory model must be stronger than fail, but in the
+ unlikely event of fail being ACQUIRE and succ being RELEASE we need to
+ promote succ to ACQ_REL so that we don't lose the acquire semantics. */
+
+ if (TARGET_HAVE_LDACQ
+ && INTVAL (mod_f) == MEMMODEL_ACQUIRE
+ && INTVAL (mod_s) == MEMMODEL_RELEASE)
+mod_s = GEN_INT (MEMMODEL_ACQ_REL);
+
switch (mod
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On Wed, Jan 30, 2013 at 10:44 AM, Michael Haubenwallner wrote: > > On 01/30/2013 03:16 PM, David Edelsohn wrote: >> wrote: >>> 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using >>>32bit gcc/xgcc to build libatomic.a. >>> => This is the one that /does/ break, as that 64bit libstdc++.a is there >>> now. > >> Originally, I was using --boot-ld-flags which included /usr/gnu/lib >> first in the path, so an older version of libstdc++ was found. > > Yes, but - sorry for being nit-picky - could you find out if your > /usr/gnu/lib/libstdc++.a was a static-only archive? libstdc++.a is a shared library. 32 bit version. But it was first in the path, so satisfying GCC cc1, cc1plus, etc. built as a 32 bit executable. The libstdc++ ABI has not changed, so the library provide all of the necessary functions. Thanks, David
[Patch, Fortran] PR54339 - Update gfortran.texi's standard refs, status and TS29113 sections
As promised: A patch for the "regression" PR54339. I am sure there is
room for improvement :-)
Everyone: Please feel free to comment on the current documentation,
http://gcc.gnu.org/onlinedocs/gfortran/ , and on the attached patch.
OK for the trunk?
Tobias
2013-01-30 Tobias Burnus
PR fortran/54339
* gfortran.texi (Standards): Mention TS29113.
(Varying Length Character): Mention deferred-length
strings.
(Fortran 2003 Status): Add unlimited polymorphic.
(TS 29113 Status): Add TYPE(*) and DIMENSION(..).
(C Interop): Update the section about TS29113.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index eff12d7..c80855c 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -522,12 +522,13 @@ ISO/IEC 1539:1997 (Fortran 95). As such, it can also compile essentially all
standard-compliant Fortran 90 and Fortran 77 programs. It also supports
the ISO/IEC TR-15581 enhancements to allocatable arrays.
-In the future, the GNU Fortran compiler will also support ISO/IEC
-1539-1:2004 (Fortran 2003), ISO/IEC 1539-1:2010 (Fortran 2008) and
-future Fortran standards. Partial support of the Fortran 2003 and
-Fortran 2008 standard is already provided; the current status of the
-support is reported in the @ref{Fortran 2003 status} and
-@ref{Fortran 2008 status} sections of the documentation.
+GNU Fortran also have a partial support for ISO/IEC 1539-1:2004 (Fortran
+2003), ISO/IEC 1539-1:2010 (Fortran 2008), the Technical Specification
+@code{Further Interoperability of Fortran with C} (ISO/IEC TS 29113:2012).
+Full support of those standards and future Fortran standards is planned.
+The current status of the support is can be found in the
+@ref{Fortran 2003 status}, @ref{Fortran 2008 status} and
+@ref{TS 29113 status} sections of the documentation.
Additionally, the GNU Fortran compilers supports the OpenMP specification
(version 3.1, @url{http://openmp.org/@/wp/@/openmp-specifications/}).
@@ -545,6 +546,10 @@ for them, which work with GNU Fortran. They can be found at
@uref{http://www.fortran.com/@/iso_varying_string.f95} and at
@uref{ftp://ftp.nag.co.uk/@/sc22wg5/@/ISO_VARYING_STRING/}.
+Deferred-length character strings of Fortran 2003 support part of
+the features of @code{ISO_VARYING_STRING} and should be considered as
+replacement. (Namely, allocatable or pointers of the type
+@code{character(len=:)}.)
@c =
@@ -807,8 +812,8 @@ operators bound to a type.
override type-bound procedures or to have deferred binding.
@item Polymorphic entities (``@code{CLASS}'') for derived types -- including
-@code{SAME_TYPE_AS}, @code{EXTENDS_TYPE_OF} and @code{SELECT TYPE}.
-Note that unlimited polymorphism is currently not supported.
+@code{SAME_TYPE_AS}, @code{EXTENDS_TYPE_OF} and @code{SELECT TYPE} for
+scalars and arrays, including unlimited polymorphism.
@item Generic interface names, which have the same name as derived types,
are now supported. This allows one to write constructor functions. Note
@@ -1079,16 +1084,23 @@ The @uref{http://gcc.gnu.org/wiki/TS29113Status, wiki} has some information
about the current TS 29113 implementation status. In particular, the
following is implemented.
+See also @ref{Further Interoperability of Fortran with C}.
+
@itemize
@item The @option{-std=f2008ts} option.
@item The @code{OPTIONAL} attribute is allowed for dummy arguments
of @code{BIND(C) procedures.}
-@item The RANK intrinsic is supported.
+@item The @code{RANK} intrinsic is supported.
@item GNU Fortran's implementation for variables with @code{ASYNCHRONOUS}
attribute is compatible with TS 29113.
+
+@item Assumed types (@code{TYPE(*)}.
+
+@item Assumed-rank (@code{DIMENSION(..)}). However, the array descriptor
+of the TS is not yet supported.
@end itemize
@@ -2264,7 +2276,7 @@ Derived types with the C binding attribute shall not have the @code{sequence}
attribute, type parameters, the @code{extends} attribute, nor type-bound
procedures. Every component must be of interoperable type and kind and may not
have the @code{pointer} or @code{allocatable} attribute. The names of the
-variables are irrelevant for interoperability.
+components are irrelevant for interoperability.
As there exist no direct Fortran equivalents, neither unions nor structs
with bit field or variable-length array members are interoperable.
@@ -2304,11 +2316,14 @@ be compatible with C. The dummy argument declaration is relatively
straightforward. However, one needs to be careful because C uses
call-by-value by default while Fortran behaves usually similar to
call-by-reference. Furthermore, strings and pointers are handled
-differently. Note that only explicit size and assumed-size arrays are
-supported but not assumed-shape or allocatable arrays.
+differently. Note that in Fortran 2003 and 2008 only explicit size
+and assumed-size arrays are supported but not assumed-shape or
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On 01/30/2013 04:56 PM, David Edelsohn wrote: > On Wed, Jan 30, 2013 at 10:44 AM, Michael Haubenwallner > wrote: >> >> On 01/30/2013 03:16 PM, David Edelsohn wrote: >>> wrote: 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using 32bit gcc/xgcc to build libatomic.a. => This is the one that /does/ break, as that 64bit libstdc++.a is there now. >> >>> Originally, I was using --boot-ld-flags which included /usr/gnu/lib >>> first in the path, so an older version of libstdc++ was found. >> >> Yes, but - sorry for being nit-picky - could you find out if your >> /usr/gnu/lib/libstdc++.a was a static-only archive? > > libstdc++.a is a shared library. 32 bit version. But it was first in > the path, so satisfying GCC cc1, cc1plus, etc. built as a 32 bit > executable. The libstdc++ ABI has not changed, so the library provide > all of the necessary functions. Erm - the question is why the 64bit libstdc++ found via LD_LIBRARY_PATH (set during libatomic build) didn't break these 32bit executables in your case. /haubi/
Re: [Patch, Fortran] PR54339 - Update gfortran.texi's standard refs, status and TS29113 sections
Tobias,
AFAICT, the links in
Additionally, the GNU Fortran compilers supports the OpenMP specification
(version 3.1, @url{http://openmp.org/@/wp/@/openmp-specifications/}).
@@ -545,6 +546,10 @@ for them, which work with GNU Fortran. They can be found
at
@uref{http://www.fortran.com/@/iso_varying_string.f95} and at
@uref{ftp://ftp.nag.co.uk/@/sc22wg5/@/ISO_VARYING_STRING/}.
are all broken.
TIA
Dominique
Re: [Patch, Fortran] PR54339 - Update gfortran.texi's standard refs, status and TS29113 sections
Dominique,
Dominique Dhumieres:
AFAICT, the links in
(version 3.1, @url{http://openmp.org/@/wp/@/openmp-specifications/}).
@uref{http://www.fortran.com/@/iso_varying_string.f95} and at
@uref{ftp://ftp.nag.co.uk/@/sc22wg5/@/ISO_VARYING_STRING/}.
are all broken.
Might be in the PDF version (untested), but they do work in the HTML
version at http://gcc.gnu.org/onlinedocs/gfortran/Standards.html
Tobias
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On Wed, Jan 30, 2013 at 11:03 AM, Michael Haubenwallner wrote: > Erm - the question is why the 64bit libstdc++ found via LD_LIBRARY_PATH (set > during libatomic build) didn't break these 32bit executables in your case. I do not have the build any more, but --boot-ld-flags affects the build logic in subtle ways because of the way that it overrides the link arguments. - David
Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations
I just finished a clean bootstrap of r195576 with your patch.
I have used it to clean the XPASS of gfortran.dg/do_1.f90 for -O0
and -O1 with the following patch:
--- /opt/gcc/_clean/gcc/testsuite/gfortran.dg/do_1.f90 2012-10-18
20:35:25.0 +0200
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/do_1.f902013-01-30
17:00:30.0 +0100
@@ -1,4 +1,5 @@
-! { dg-do run { xfail *-*-* } }
+! { dg-do run }
+! { dg-additional-options "-fno-aggressive-loop-optimizations" }
! XFAIL is tracked in PR 54932
! Program to check corner cases for DO statements.
program do_1
Cheers,
Dominique
Re: [Patch, Fortran] PR54339 - Update gfortran.texi's standard refs, status and TS29113 sections
Tobias, > Might be in the PDF version (untested), but they do work in the HTML > version at http://gcc.gnu.org/onlinedocs/gfortran/Standards.html I think my mistake was to use the links as they appear at http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01446.html I was biased because I have found that the link for OpenMP Application Program Interface v3.1. at http://gcc.gnu.org/onlinedocs/gfortran/OpenMP-Modules-OMP_005fLIB-and-OMP_005fLIB_005fKINDS.html#OpenMP-Modules-OMP_005fLIB-and-OMP_005fLIB_005fKINDS does not work. Sorry for the noise, Dominique
patch to fix PR56144
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56144
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 195582.
2013-01-30 Vladimir Makarov
PR rtl-optimization/56144
* lra-constraints.c (get_reload_reg): Don't reuse reload pseudo
for values with side effects.
2013-01-30 Vladimir Makarov
PR rtl-optimization/56144
* gcc.dg/pr56144.c: New.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 195581)
+++ lra-constraints.c (working copy)
@@ -414,24 +414,26 @@ get_reload_reg (enum op_type type, enum
= lra_create_new_reg_with_unique_value (mode, original, rclass, title);
return true;
}
- for (i = 0; i < curr_insn_input_reloads_num; i++)
-if (rtx_equal_p (curr_insn_input_reloads[i].input, original)
- && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))
- {
- lra_assert (! side_effects_p (original));
- *result_reg = curr_insn_input_reloads[i].reg;
- regno = REGNO (*result_reg);
- if (lra_dump_file != NULL)
- {
- fprintf (lra_dump_file, "Reuse r%d for reload ", regno);
- dump_value_slim (lra_dump_file, original, 1);
- }
- if (new_class != lra_get_allocno_class (regno))
- change_class (regno, new_class, ", change", false);
- if (lra_dump_file != NULL)
- fprintf (lra_dump_file, "\n");
- return false;
- }
+ /* Prevent reuse value of expression with side effects,
+ e.g. volatile memory. */
+ if (! side_effects_p (original))
+for (i = 0; i < curr_insn_input_reloads_num; i++)
+ if (rtx_equal_p (curr_insn_input_reloads[i].input, original)
+ && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))
+ {
+ *result_reg = curr_insn_input_reloads[i].reg;
+ regno = REGNO (*result_reg);
+ if (lra_dump_file != NULL)
+ {
+ fprintf (lra_dump_file, " Reuse r%d for reload ", regno);
+ dump_value_slim (lra_dump_file, original, 1);
+ }
+ if (new_class != lra_get_allocno_class (regno))
+ change_class (regno, new_class, ", change", false);
+ if (lra_dump_file != NULL)
+ fprintf (lra_dump_file, "\n");
+ return false;
+ }
*result_reg = lra_create_new_reg (mode, original, rclass, title);
lra_assert (curr_insn_input_reloads_num < LRA_MAX_INSN_RELOADS);
curr_insn_input_reloads[curr_insn_input_reloads_num].input = original;
Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations
On 01/29/2013 04:53 AM, Richard Biener wrote: I'm curious about the affect of -fno-aggressive-loop-optimizations on SPEC CPU 2006 numbers (not curious enough to try for myself though). Both on extra PASSes for official latest sources (I have no access to those) and on performance. The patch/option result in both 464.h264ref and 416.gamess passing (as opposed to infinite loop). As for performance, I didn't see any difference outside of noise range for both 32-bit and 64-bit runs on PowerPC. -Pat
Re: [PATCH] Vtable pointer verification, C++ front end changes (patch 1 of 3)
I'm also touching on the middle-end and library changes, but would
appreciate a more thorough review from others in those areas.
On 01/23/2013 05:25 PM, Caroline Tice wrote:
Index: gcc/cp/g++spec.c
Changes to g++spec.c only affect the g++ driver, not the gcc driver. Are
you sure this is what you want? Can't you handle this stuff directly in
the specs like address sanitizer does?
@@ -17954,6 +17954,10 @@ mark_class_instantiated (tree t, int ext
if (! extern_p)
{
CLASSTYPE_DEBUG_REQUESTED (t) = 1;
+
+ if (flag_vtable_verify)
+vtv_save_class_info (t);
Why do you need this here as well as in finish_struct_1?
-static tree
+tree
get_mangled_id (tree decl)
It doesn't look like you call get_mangled_id anywhere, so I think you
don't need this change anymore.
finalize_compilation_unit ();
+ if (flag_vtable_verify)
+{
+ /* Generate the special constructor initialization function that
+ calls __VLTRegisterPairs, and give it a very high initialization
+ priority. */
+ vtv_generate_init_routine ();
+}
Why do you want to do this after cgraph finalization? Is it so that you
know which vtables are really being emitted? Please explain in the comment.
+ if (flag_vtable_verify
+ && strstr (IDENTIFIER_POINTER (DECL_NAME (fn)), ".vtable"))
+return fn;
How would this function end up with .vtable at the end of its name?
+ if (TREE_CHAIN (base_class))
+class_type_decl = TREE_CHAIN (base_class);
+ else
+class_type_decl = TYPE_NAME (base_class);
+
+ /* Temporarily remove any qualifiers on type. */
+ type_decl_type = TREE_TYPE (class_type_decl);
+ save_quals = TYPE_QUALS (type_decl_type);
+ reset_type_qualifiers (null_quals, type_decl_type);
+
+ base_id = DECL_ASSEMBLER_NAME (TREE_CHAIN (base_class));
I think you want TYPE_LINKAGE_IDENTIFIER here.
I don't understand what the qualifier business is trying to accomplish,
especially since you never use type_decl_type. You do this in several
places, but it should never be necessary; classes don't have any
qualifiers.
+ if (vtbl_map_node_registration_find (base_vtable_map_node, vtable_decl,
+ offset))
+return true;
+
+ vtbl_map_node_registration_insert (base_vtable_map_node, vtable_decl,
+offset);
Here you're doing two hash table lookups when one would be enough.
+ vtbl_var_decl = get_vtbl_decl_for_binfo (TYPE_BINFO (record_type));
Here you could use CLASSTYPE_VTABLES (record_type).
+ /* Check to see if we have found a constructor vtable. Add its
+ data if appropriate. */
_ZTT indicates a VTT (vtable table,
http://mentorembedded.github.com/cxx-abi/abi.html#vtable-ctor), which
points to construction vtables, but is not itself a construction vtable.
In register_vptr_fields it seems that given a base B and derived D, you
are adding all the elements of D's VTT to the list of valid vtables for
a B, but this isn't correct; elements of D's VTT may be vtables for
other bases, or other VTTs. I think this might even miss some
potential B vtables by not walking into sub-VTTs.
Since this function is just trying to register construction vtables, I
think calling it "register_construction_vtables" would be clearer.
+ && (strncmp (IDENTIFIER_POINTER (DECL_NAME (ztt_decl)),
+ "_ZTT", 4) == 0))
I think relying on the mangled name like this is going to be fragile;
for instance, some targets use two underscores at the beginning of the
mangled name. Probably better to assume that if CLASSTYPE_VBASECLASSES
(record_type), it's the VTT; that's what build_special_member_call does.
Or better yet, encapsulate that logic in a get_vtt function.
+ && TREE_CODE (TREE_OPERAND (val_vtbl_decl, 0))
+ == VAR_DECL)
Odd indentation.
+ len1 = strlen (IDENTIFIER_POINTER
+(DECL_NAME
+ (TREE_OPERAND
+(base_class_decl_arg, 0;
+ len2 = strlen (IDENTIFIER_POINTER
+(DECL_NAME (val_vtbl_decl)));
+ arg1 = build_string_literal (len1 + 1,
+ IDENTIFIER_POINTER
+ (DECL_NAME
+(TREE_OPERAND
+ (base_class_decl_arg, 0;
+ arg2 = build_string_literal (len2 + 1,
+ IDENTIFIER_POINTER
+ (DECL_NAME (val_vtbl_decl)));
Since these are only used when debugging, let's only initialize them
when debugging, too. And instead of strlen (IDENTIFIER_POINTER
[patch libiberty]: Fix PR 543413
Hi, this patch fixes wrong handling of cases that bitness of size_t is wider as 32-bit. ChangeLog 2013-01-30 Kai Tietz PR other/543413 * md5.c (md5_process_block): Handle case that size_t is a wider-integer-scalar a 32-bit unsigned integer. Tested for x86_64-unknown-linux-gnu, i686-pc-cygwin, and x86_64-w64-mingw32. Ok for apply? Regards, Kai Index: md5.c === --- md5.c (Revision 195578) +++ md5.c (Arbeitskopie) @@ -293,8 +293,7 @@ md5_process_block (const void *buffer, size_t len, length of the file up to 2^64 bits. Here we only compute the number of bytes. Do a double word increment. */ ctx->total[0] += len; - if (ctx->total[0] < len) -++ctx->total[1]; + ctx->total[1] += ((len >> 31) >> 1) + (ctx->total[0] < len); /* Process all bytes in the buffer with 64 bytes in each round of the loop. */
[patch libiberty]: Fix PR 54620
Hi, this patch fixes wrong handling of cases that bitness of size_t is wider as 32-bit. ChangeLog 2013-01-30 Kai Tietz PR other/54620 * sha1.c (sha1_process_block): Handle case that size_t is a wider-integer-scalar as a 32-bit unsigned integer. Tested for x86_64-unknown-linux-gnu, i686-pc-cygwin, and x86_64-w64-mingw32. Ok for apply? Regards, Kai Index: sha1.c === --- sha1.c (Revision 195578) +++ sha1.c (Arbeitskopie) @@ -300,8 +300,7 @@ sha1_process_block (const void *buffer, size_t len length of the file up to 2^64 bits. Here we only compute the number of bytes. Do a double word increment. */ ctx->total[0] += len; - if (ctx->total[0] < len) -++ctx->total[1]; + ctx->total[1] += ((len >> 31) >> 1) + (ctx->total[0] < len); #define rol(x, n) (((x) << (n)) | ((sha1_uint32) (x) >> (32 - (n
[4.8.[01]] PowerPC di->ti widening multiplication
For gcc 4.9, I intend to ensure that optabs.c can make automatic use of
[us]mul_highpart. There are plenty of targets that only implement
_highpart but not the widening pattern. But that's not something that
would be appropriate at this stage in the 4.8 cycle.
Whether this patch is appropriate for 4.8.0 is someone else's call, but
it's probably safe to queue it for 4.8.1.
r~
* config/rs6000/rs6000.md (smulditi3): New.
(umulditi3): New.
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index a4af648..b3db681 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -6326,6 +6326,34 @@
"mulhdu %0,%1,%2"
[(set_attr "type" "lmul")])
+(define_expand "mulditi3"
+ [(set (match_operand:TI 0 "gpc_reg_operand")
+ (mult:TI (sign_extend:TI (match_operand:DI 1 "gpc_reg_operand"))
+(sign_extend:TI (match_operand:DI 2 "gpc_reg_operand"]
+ "TARGET_POWERPC64"
+{
+ rtx l = gen_reg_rtx (DImode), h = gen_reg_rtx (DImode);
+ emit_insn (gen_muldi3 (l, operands[1], operands[2]));
+ emit_insn (gen_smuldi3_highpart (h, operands[1], operands[2]));
+ emit_move_insn (gen_lowpart (DImode, operands[0]), l);
+ emit_move_insn (gen_highpart (DImode, operands[0]), h);
+ DONE;
+})
+
+(define_expand "umulditi3"
+ [(set (match_operand:TI 0 "gpc_reg_operand")
+ (mult:TI (zero_extend:TI (match_operand:DI 1 "gpc_reg_operand"))
+(zero_extend:TI (match_operand:DI 2 "gpc_reg_operand"]
+ "TARGET_POWERPC64"
+{
+ rtx l = gen_reg_rtx (DImode), h = gen_reg_rtx (DImode);
+ emit_insn (gen_muldi3 (l, operands[1], operands[2]));
+ emit_insn (gen_umuldi3_highpart (h, operands[1], operands[2]));
+ emit_move_insn (gen_lowpart (DImode, operands[0]), l);
+ emit_move_insn (gen_highpart (DImode, operands[0]), h);
+ DONE;
+})
+
(define_insn "rotldi3"
[(set (match_operand:DI 0 "gpc_reg_operand" "=r,r")
(rotate:DI (match_operand:DI 1 "gpc_reg_operand" "r,r")
[patch libiberty]: Fix PR 53285 on 4.7 branch
Hi,
this patch backports a fix from trunk
ChangeLog
2013-01-30 Kai Tietz
2012-07-31 Mike Frysinger
Merged from trunk.
PR other/53285
* md5.c (md5_finish_ctx): Declare swap_bytes. Assign SWAP() output
to swap_bytes, and then call memcpy to move it to ctx->buffer.
Tested for x86_64-unknown-linux-gnu, i686-w64-mingw32, and
i686-pc-cygwin. Ok for apply?
Regards,
Kai
Index: md5.c
===
--- md5.c (Revision 194858)
+++ md5.c (Arbeitskopie)
@@ -103,6 +103,7 @@ md5_finish_ctx (struct md5_ctx *ctx, void *resbuf)
{
/* Take yet unprocessed bytes into account. */
md5_uint32 bytes = ctx->buflen;
+ md5_uint32 swap_bytes;
size_t pad;
/* Now count remaining bytes. */
@@ -113,10 +114,13 @@ md5_finish_ctx (struct md5_ctx *ctx, void *resbuf)
pad = bytes >= 56 ? 64 + 56 - bytes : 56 - bytes;
memcpy (&ctx->buffer[bytes], fillbuf, pad);
- /* Put the 64-bit file length in *bits* at the end of the buffer. */
- *(md5_uint32 *) &ctx->buffer[bytes + pad] = SWAP (ctx->total[0] << 3);
- *(md5_uint32 *) &ctx->buffer[bytes + pad + 4] = SWAP ((ctx->total[1] << 3) |
- (ctx->total[0] >> 29));
+ /* Put the 64-bit file length in *bits* at the end of the buffer.
+ Use memcpy to avoid aliasing problems. On most systems, this
+ will be optimized away to the same code. */
+ swap_bytes = SWAP (ctx->total[0] << 3);
+ memcpy (&ctx->buffer[bytes + pad], &swap_bytes, sizeof (swap_bytes));
+ swap_bytes = SWAP ((ctx->total[1] << 3) | (ctx->total[0] >> 29));
+ memcpy (&ctx->buffer[bytes + pad + 4], &swap_bytes, sizeof (swap_bytes));
/* Process last bytes. */
md5_process_block (ctx->buffer, bytes + pad + 8, ctx);
[PATCH] GCC 4.9 powerpc, merge SF/SD moves
This is a series of patches taken from my power8 work meant for inclusion against GCC 4.9 when 4.8 is branched, and stage1 of 4.9 opens up again. They could be installed in 4.8 at the discretion of David. This patch merges together the movsd/movsf patterns, so that when I make changes to the basic move patterns, I don't have to remember to do the same work in two places. Along with combining the moves, I added support to use the LFIWZX (power7) and STFIWX (power6) instructions to store SDmode variables directly. Before this, we needed to create a wider buffer on the stack, and move the values from a register to the buffer, and use a wider load on the floating point side to load them up. Now under power7, it no longer uses this buffer. A minor other change is that now the compiler will use the VSX XXLXOR instruction to clear a single precision floating point value, instead of loading the zero value from memory. I have bootstraped, and there are no regressions with these patches. Are these patches acceptible, so that I can check them in directly when the GCC 4.9 tree opens up? [gcc] 2013-01-30 Michael Meissner * config/rs6000/vector.md (VEC_R): Add 32-bit integer, binary floating point, and decimal floating point to reload iterator. * config/rs6000/constraints.md (wl constraint): New constraints to return FLOAT_REGS if certain options are used to reduce the number of separate patterns that exist in the file. (wx constraint): Likewise. (wz constraint): Likewise. * config/rs6000/rs6000.c (rs6000_debug_reg_global): If -mdebug=reg, print wg, wl, wx, and wz constraints. (rs6000_init_hard_regno_mode_ok): Initialize new constraints. Initialize the reload functions for 64-bit binary/decimal floating point types. (reg_offset_addressing_ok_p): If we are on a power7 or later, use LFIWZX and STFIWX to load/store 32-bit decimal types, and don't create the buffer on the stack to overcome not having a 32-bit load and store. (rs6000_emit_move): Likewise. (rs6000_secondary_memory_needed_rtx): Likewise. (rs6000_alloc_sdmode_stack_slot): Likewise. (rs6000_preferred_reload_class): On VSX, we can create SFmode 0.0f via xxlxor, just like DFmode 0.0. * config/rs6000/rs6000.h (TARGET_NO_SDMODE_STACK): New macro, define as 1 if we are running on a power7 or newer. (enum r6000_reg_class_enum): Add new constraints. * config/rs6000/dfp.md (movsd): Delete, combine with binary floating point moves in rs6000.md. Combine power6x (mfpgpr) moves with other moves by using conditional constraits (wg). Use LFIWZX and STFIWX for loading SDmode on power7. Use xxlxor to create 0.0f. (movsd splitter): Likewise. (movsd_hardfloat): Likewise. (movsd_softfloat): Likewise. * config/rs6000/rs6000.md (FMOVE32): New iterators to combine binary and decimal floating point moves. (fmove_ok): New attributes to combine binary and decimal floating point moves, and to combine power6x (mfpgpr) moves along normal floating moves. (real_value_to_target): Likewise. (f32_lr): Likewise. (f32_lm): Likewise. (f32_li): Likewise. (f32_sr): Likewise. (f32_sm): Likewise. (f32_si): Likewise. (movsf): Combine binary and decimal floating point moves. Combine power6x (mfpgpr) moves with other moves by using conditional constraits (wg). Use LFIWZX and STFIWX for loading SDmode on power7. (mov for SFmode/SDmode); Likewise. (SFmode/SDmode splitters): Likewise. (movsf_hardfloat): Likewise. (mov_hardfloat for SFmode/SDmode): Likewise. (movsf_softfloat): Likewise. (mov_softfloat for SFmode/SDmode): Likewise. * doc/md.texi (PowerPC and IBM RS6000 constraints): Document wl, wx and wz constraints. [gcc/testsuite] 2013-01-30 Michael Meissner * gcc.target/powerpc/vsx-float0.c: New testcase. * gcc.target/powerpc/sd-vsx.c: Likewise. * gcc.target/powerpc/sd-pwr6.c: Likewise. -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899 Index: gcc/config/rs6000/vector.md === --- gcc/config/rs6000/vector.md (revision 195557) +++ gcc/config/rs6000/vector.md (working copy) @@ -54,7 +54,7 @@ (define_mode_iterator VEC_E [V16QI V8HI (define_mode_iterator VEC_64 [V2DI V2DF]) ;; Vector reload iterator -(define_mode_iterator VEC_R [V16QI V8HI V4SI V2DI V4SF V2DF DF TI]) +(define_mode_iterator VEC_R [V16QI V8HI V4SI V2DI V4SF V2DF SF SD SI DF DD DI TI]) ;; Base type from vector mode (define_mode_attr VEC_base [(V16QI "QI") Index: gcc/config/rs6000/constraint
Re: SLP for vectors
On Tue, 29 Jan 2013, Richard Biener wrote: On Sun, Jan 27, 2013 at 4:28 PM, Marc Glisse wrote: Hello, this message is to check that I am not doing something absurd and ask for a bit of advice. In the attached patch, I let SLP recognize vector loads/stores just like it recognizes those in an array. It has a few issues: the cost of the vectorized version is overestimated, the base object is wrong (doesn't strip the bit_field_ref, but since the base address is right and the base object is almost unused...), but most importantly it only works if the vectors have their address taken, otherwise (after asking gimple_vuse?) SLP doesn't detect their use as loads or stores at all. Yes, if they have not their address taken they are not loads. Also, it only works if you write result[0]=..., result[1]=... and does not recognize a constructor as a series of stores. Is slowly extending SLP the right way to go? Should get_references_in_stmt report vector element accesses? It does if it is a memory access. You didn't provide a new testcase so it's hard for me to guess what you are trying to do. I suppose you want to vectorize w[0] = v[0] + v[0]; w[1] = v[1] + v[1]; into w = v + v; As it would work if w and v are array accesses instead of vector subscripts? Yes, sorry for not being more precise. Vectorization that works for an array should work (even better) for a vector. Note that similar issues (and bugreports) exist for complex component accesses. One extension at a time :-) As of handling non-memory BIT_FIELD_REFs - I suggest to split out the test of whether a stmt is considered a "load" for the purpose of vectorization and simply special-case this therein, not requiring a VUSE. Ok. The hardest part will be preventing the pass from creating ADDR_EXPR of those vectors, or at least folding them before the pass is done. I suppose the data-ref analysis parts are not strictly required, nor the get_addr_base_and_unit_offset_1 parts? Actually it is necessary (at least the get_addr_base_and_unit_offset_1 part is) otherwise I get a gimple verification failure because we have an ADDR_EXPR of a BIT_FIELD_REF. They should be split out and separately tested anyway. The data-ref part at least will confuse analysis of 'a[0]' or 'a[1]' vs. 'a', but I suppose independent of the patch. Ah... Could you be more specific? Are you thinking about arrays of vectors? Thanks for the help, -- Marc Glisse
[PATCH] GCC 4.9 powerpc, merge DF/DD moves
This patch builds upon the patch in:
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01457.html
It merges the DFmode and DDmode moves into one pattern. In addition, it merges
the -mmfpgpr code with the normal floating point moves, using a new conditional
constraint (wg) that only returns FLOAT_REGS for the power6x.
I have tested this via bootstrap, and there were no regressions. Is patch
acceptable to check in when the 4.9 tree opens up?
2013-01-30 Michael Meissner
* config/rs6000/constraints.md (wg constraint): New constraint to
return FLOAT_REGS if -mmfpgpr (power6x) was used.
* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Add wg
constraint.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): If
-mdebug=reg, print wg, wl, wx, and wz constraints.
(rs6000_init_hard_regno_mode_ok): Initialize new constraints.
Initialize the reload functions for 64-bit binary/decimal floating
point types.
(reg_offset_addressing_ok_p): If we are on a power7 or later, use
LFIWZX and STFIWX to load/store 32-bit decimal types, and don't
create the buffer on the stack to overcome not having a 32-bit
load and store.
(rs6000_emit_move): Likewise.
(rs6000_secondary_memory_needed_rtx): Likewise.
(rs6000_alloc_sdmode_stack_slot): Likewise.
(rs6000_preferred_reload_class): On VSX, we can create SFmode 0.0f
via xxlxor, just like DFmode 0.0.
* config/rs6000/dfp.md (movdd): Delete, combine with binary
floating point moves in rs6000.md. Combine power6x (mfpgpr) moves
with other moves by using conditional constraits (wg). Use LFIWZX
and STFIWX for loading SDmode on power7.
(movdd splitters): Likewise.
(movdd_hardfloat32): Likewise.
(movdd_softfloat32): Likewise.
(movdd_hardfloat64_mfpgpr): Likewise.
(movdd_hardfloat64): Likewise.
(movdd_softfloat64): Likewise.
* config/rs6000/rs6000.md (FMOVE64): New iterators to combine
64-bit binary and decimal floating point moves.
(FMOVE64X): Likewise.
(movdf): Combine 64-bit binary and decimal floating point moves.
Combine power6x (mfpgpr) moves with other moves by using
conditional constraits (wg).
(mov for DFmode/DDmode): Likewise.
(DFmode/DDmode splitters): Likewise.
(movdf_hardfloat32): Likewise.
(mov_hardfloat32 for DFmode/DDmode): Likewise.
(movdf_softfloat32): Likewise.
(movdf_hardfloat64_mfpgpr): Likewise.
(movdf_hardfloat64): Likewise.
(mov_hardfloat64 for DFmode/DDmode): Likewise.
(movdf_softfloat64): Likewise.
(mov_softfloat64 for DFmode/DDmode): Likewise.
(reload__load): Move to later in the file so they aren't in
the middle of the floating point move insns.
(reload__store): Likewise.
* doc/md.texi (PowerPC and IBM RS6000 constraints): Document wg
constraint.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/config/rs6000/constraints.md
===
--- gcc/config/rs6000/constraints.md(revision 195586)
+++ gcc/config/rs6000/constraints.md(working copy)
@@ -69,6 +69,9 @@ (define_register_constraint "wa" "rs6000
"@internal")
;; Register constraints to simplify move patterns
+(define_register_constraint "wg" "rs6000_constraints[RS6000_CONSTRAINT_wg]"
+ "Floating point register if -mmfpgpr is used, or NO_REGS.")
+
(define_register_constraint "wl" "rs6000_constraints[RS6000_CONSTRAINT_wl]"
"Floating point register if the LFIWAX instruction is enabled or NO_REGS.")
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h (revision 195586)
+++ gcc/config/rs6000/rs6000.h (working copy)
@@ -1324,6 +1324,7 @@ enum r6000_reg_class_enum {
RS6000_CONSTRAINT_v, /* Altivec registers */
RS6000_CONSTRAINT_wa,/* Any VSX register */
RS6000_CONSTRAINT_wd,/* VSX register for V2DF */
+ RS6000_CONSTRAINT_wg,/* FPR register for -mmfpgpr */
RS6000_CONSTRAINT_wf,/* VSX register for V4SF */
RS6000_CONSTRAINT_wl,/* FPR register for LFIWAX */
RS6000_CONSTRAINT_ws,/* VSX register for DF */
Index: gcc/config/rs6000/dfp.md
===
--- gcc/config/rs6000/dfp.md(revision 195586)
+++ gcc/config/rs6000/dfp.md(working copy)
@@ -111,211 +111,6 @@ (define_insn "*nabsdd2_fpr"
"fnabs %0,%1"
[(set_attr "type" "fp")])
-(define_expand "movdd"
- [(set (match_operand:DD 0 "nonimmediate_operand" "")
- (match_operand:DD 1 "any_operand" ""))]
- ""
- "{ rs6000_emit_move (oper
Re: [4.8.[01]] PowerPC di->ti widening multiplication
On Wed, Jan 30, 2013 at 1:17 PM, Richard Henderson wrote: > For gcc 4.9, I intend to ensure that optabs.c can make automatic use of > [us]mul_highpart. There are plenty of targets that only implement > _highpart but not the widening pattern. But that's not something that would > be appropriate at this stage in the 4.8 cycle. > > Whether this patch is appropriate for 4.8.0 is someone else's call, but it's > probably safe to queue it for 4.8.1. > * config/rs6000/rs6000.md (smulditi3): New. > (umulditi3): New. This patch is fine. I don't have a problem with committing if for 4.8.0, unless the RMs object. In fact, I would rather add a new instruction and deal with any fallout for 4.8.0 instead of 4.8.1. Thanks, David
Re: [4.8.[01]] PowerPC di->ti widening multiplication
On Wed, Jan 30, 2013 at 04:27:57PM -0500, David Edelsohn wrote: > On Wed, Jan 30, 2013 at 1:17 PM, Richard Henderson wrote: > > For gcc 4.9, I intend to ensure that optabs.c can make automatic use of > > [us]mul_highpart. There are plenty of targets that only implement > > _highpart but not the widening pattern. But that's not something that would > > be appropriate at this stage in the 4.8 cycle. > > > > Whether this patch is appropriate for 4.8.0 is someone else's call, but it's > > probably safe to queue it for 4.8.1. > > > * config/rs6000/rs6000.md (smulditi3): New. > > (umulditi3): New. > > This patch is fine. I don't have a problem with committing if for > 4.8.0, unless the RMs object. In fact, I would rather add a new > instruction and deal with any fallout for 4.8.0 instead of 4.8.1. I agree it is better to put it in now than after 4.8.0 is released. Jakub
Re: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86
This change seems to have broken bootstrap with -march=pentium{2,3,-m} on
the 4.6 branch.
http://gcc.gnu.org/PR53728
--
gcc-porting
toolchain, wxwidgetslearn a language baby, it's that kind of place
@ gentoo.org where low card is hunger and high card is taste
signature.asc
Description: PGP signature
libgo patch committed: Better backtraces
This patch to libgo fixes backtrace information when optimizing.
Previously the backtraces just collected PC values and then converted
them into file/line information. This of course works poorly when
functions are inlined. This version uses the facilities of libbacktrace
to get good backtraces in the presence of inlined functions. It also
skips the split-stack functions, which are not of interest when getting
a Go backtrace. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 6edf35ba05b2 libgo/runtime/go-caller.c
--- a/libgo/runtime/go-caller.c Tue Jan 29 17:30:28 2013 -0800
+++ b/libgo/runtime/go-caller.c Wed Jan 30 13:53:47 2013 -0800
@@ -166,16 +166,16 @@
Caller (int skip)
{
struct caller_ret ret;
- uintptr pc;
+ Location loc;
int32 n;
- String fn;
runtime_memclr (&ret, sizeof ret);
- n = runtime_callers (skip + 1, &pc, 1);
+ n = runtime_callers (skip + 1, &loc, 1);
if (n < 1)
return ret;
- ret.pc = pc;
- __go_file_line (pc, &fn, &ret.file, &ret.line);
+ ret.pc = loc.pc;
+ ret.file = loc.filename;
+ ret.line = loc.lineno;
ret.ok = 1;
return ret;
}
diff -r 6edf35ba05b2 libgo/runtime/go-callers.c
--- a/libgo/runtime/go-callers.c Tue Jan 29 17:30:28 2013 -0800
+++ b/libgo/runtime/go-callers.c Wed Jan 30 13:53:47 2013 -0800
@@ -15,20 +15,37 @@
struct callers_data
{
- uintptr *pcbuf;
+ Location *locbuf;
int index;
int max;
};
-/* Callback function for backtrace_simple. Just collect the PC
- values. Return zero to continue, non-zero to stop. */
+/* Callback function for backtrace_full. Just collect the locations.
+ Return zero to continue, non-zero to stop. */
static int
-callback (void *data, uintptr_t pc)
+callback (void *data, uintptr_t pc, const char *filename, int lineno,
+ const char *function)
{
struct callers_data *arg = (struct callers_data *) data;
+ Location *loc;
- arg->pcbuf[arg->index] = pc;
+ /* Skip split stack functions. */
+ if (function != NULL)
+{
+ const char *p = function;
+
+ if (__builtin_strncmp (p, "___", 3) == 0)
+ ++p;
+ if (__builtin_strncmp (p, "__morestack_", 12) == 0)
+ return 0;
+}
+
+ loc = &arg->locbuf[arg->index];
+ loc->pc = pc;
+ loc->filename = runtime_gostring ((const byte *) filename);
+ loc->function = runtime_gostring ((const byte *) function);
+ loc->lineno = lineno;
++arg->index;
return arg->index >= arg->max;
}
@@ -47,15 +64,15 @@
/* Gather caller PC's. */
int32
-runtime_callers (int32 skip, uintptr *pcbuf, int32 m)
+runtime_callers (int32 skip, Location *locbuf, int32 m)
{
struct callers_data data;
- data.pcbuf = pcbuf;
+ data.locbuf = locbuf;
data.index = 0;
data.max = m;
- backtrace_simple (__go_get_backtrace_state (), skip + 1, callback,
- error_callback, &data);
+ backtrace_full (__go_get_backtrace_state (), skip + 1, callback,
+ error_callback, &data);
return data.index;
}
@@ -65,8 +82,19 @@
int
Callers (int skip, struct __go_open_array pc)
{
+ Location *locbuf;
+ int ret;
+ int i;
+
+ locbuf = (Location *) runtime_mal (pc.__count * sizeof (Location));
+
/* In the Go 1 release runtime.Callers has an off-by-one error,
which we can not correct because it would break backward
compatibility. Adjust SKIP here to be compatible. */
- return runtime_callers (skip - 1, (uintptr *) pc.__values, pc.__count);
+ ret = runtime_callers (skip - 1, locbuf, pc.__count);
+
+ for (i = 0; i < ret; i++)
+((uintptr *) pc.__values)[i] = locbuf[i].pc;
+
+ return ret;
}
diff -r 6edf35ba05b2 libgo/runtime/go-traceback.c
--- a/libgo/runtime/go-traceback.c Tue Jan 29 17:30:28 2013 -0800
+++ b/libgo/runtime/go-traceback.c Wed Jan 30 13:53:47 2013 -0800
@@ -13,29 +13,25 @@
void
runtime_traceback ()
{
- uintptr pcbuf[100];
+ Location locbuf[100];
int32 c;
- c = runtime_callers (1, pcbuf, sizeof pcbuf / sizeof pcbuf[0]);
- runtime_printtrace (pcbuf, c, true);
+ c = runtime_callers (1, locbuf, nelem (locbuf));
+ runtime_printtrace (locbuf, c, true);
}
void
-runtime_printtrace (uintptr *pcbuf, int32 c, bool current)
+runtime_printtrace (Location *locbuf, int32 c, bool current)
{
int32 i;
for (i = 0; i < c; ++i)
{
- String fn;
- String file;
- intgo line;
-
- if (__go_file_line (pcbuf[i], &fn, &file, &line)
- && runtime_showframe (fn, current))
+ if (runtime_showframe (locbuf[i].function, current))
{
- runtime_printf ("%S\n", fn);
- runtime_printf ("\t%S:%D\n", file, (int64) line);
+ runtime_printf ("%S\n", locbuf[i].function);
+ runtime_printf ("\t%S:%D\n", locbuf[i].filename,
+ (int64) locbuf[i].lineno);
}
}
}
diff -r 6edf35ba05b2 libgo/runtime/mprof.goc
--- a/libgo/runtime/mprof.goc Tue Jan 29 17:30:28 2013 -0800
+++ b/libgo/runtime/mprof.goc Wed Jan 30 13:53:47 2013 -0800
@@ -11,6 +11,7 @@
#include "malloc.h"
#include "defs.h"
#include "go-type.h"
+#include "go-string.h"
/
[PATCH] PowerPC merge TD/TF moves
This patch like the previous 2 pages combines the decimal and binary floating
point moves, this time for 128-bit floating point.
In doing this patch, I discovered that I left out the code in the previous
patch to enable the wg constraint to enable -mcpu=power6x to utilize the direct
move instructions. So, I added the code in this patch, and also created a test
to make sure that direct moves are generated in the future.
I also added the reload helper for DDmode to rs6000_vector_reload that was
missed in the last patch. This was harmless, since that is only used with an
undocumented debug switch. Hopefully sometime in the future, I will scalar
floating point to be able to be loaded in the upper 32 VSX registers that are
overlaid over the Altivec registers.
Like the previous 2 patches, I've bootstrapped this, and ran make check with no
regressions. Is it ok to apply when GCC 4.9 opens up?
I have one more patch in the insn combination to post, combining movdi on
systems with normal floating point and with the power6 direct move
instructions.
[gcc]
2013-01-30 Michael Meissner
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Print out wg
constraint if -mdebug=reg.
(rs6000_initi_hard_regno_mode_ok): Enable wg constraint if
-mfpgpr. Enable using dd reload support if needed.
* config/rs6000/dfp.md (movtd): Delete, combine with 128-bit
binary and decimal floating point moves in rs6000.md.
(movtd_internal): Likewise.
* config/rs6000/rs6000.md (FMOVE128): Combine 128-bit binary and
decimal floating point moves.
(movtf): Likewise.
(movtf_internal): Likewise.
(mov_internal, TDmode/TFmode): Likewise.
(movtf_softfloat): Likewise.
(mov_softfloat, TDmode/TFmode): Likewise.
[gcc/testsuite]
2013-01-30 Michael Meissner
* gcc.target/powerpc/mmfpgpr.c: New test.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 195586)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -1737,6 +1737,7 @@ rs6000_debug_reg_global (void)
"wa reg_class = %s\n"
"wd reg_class = %s\n"
"wf reg_class = %s\n"
+ "wg reg_class = %s\n"
"wl reg_class = %s\n"
"ws reg_class = %s\n"
"wx reg_class = %s\n"
@@ -1748,6 +1749,7 @@ rs6000_debug_reg_global (void)
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wa]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wd]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wf]],
+ reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wg]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wl]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_ws]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wx]],
@@ -2120,6 +2122,9 @@ rs6000_init_hard_regno_mode_ok (bool glo
if (TARGET_ALTIVEC)
rs6000_constraints[RS6000_CONSTRAINT_v] = ALTIVEC_REGS;
+ if (TARGET_MFPGPR)
+rs6000_constraints[RS6000_CONSTRAINT_wg] = FLOAT_REGS;
+
if (TARGET_LFIWAX)
rs6000_constraints[RS6000_CONSTRAINT_wl] = FLOAT_REGS;
@@ -2150,6 +2155,8 @@ rs6000_init_hard_regno_mode_ok (bool glo
{
rs6000_vector_reload[DFmode][0] = CODE_FOR_reload_df_di_store;
rs6000_vector_reload[DFmode][1] = CODE_FOR_reload_df_di_load;
+ rs6000_vector_reload[DDmode][0] = CODE_FOR_reload_dd_di_store;
+ rs6000_vector_reload[DDmode][1] = CODE_FOR_reload_dd_di_load;
}
}
else
@@ -2170,6 +2177,8 @@ rs6000_init_hard_regno_mode_ok (bool glo
{
rs6000_vector_reload[DFmode][0] = CODE_FOR_reload_df_si_store;
rs6000_vector_reload[DFmode][1] = CODE_FOR_reload_df_si_load;
+ rs6000_vector_reload[DDmode][0] = CODE_FOR_reload_dd_si_store;
+ rs6000_vector_reload[DDmode][1] = CODE_FOR_reload_dd_si_load;
}
}
}
Index: gcc/config/rs6000/dfp.md
===
--- gcc/config/rs6000/dfp.md(revision 195590)
+++ gcc/config/rs6000/dfp.md(working copy)
@@ -144,27 +144,6 @@ (define_insn "*nabstd2_fpr"
"fnabs %0,%1"
[(set_attr "type" "fp")])
-(define_expand "movtd"
- [(set (match_operand:TD 0 "general_operand" "")
- (match_operand:TD 1 "any_operand" ""))]
- "TARGET_HARD_FLOAT && TARGET_FPRS"
- "{ rs6000_emit_move (operands[0], operands[1], TDmode); DONE; }")
-
-; It's important to list the Y->r and r->Y moves before r->r because
-; otherwise reload, given m->r, will try to pick r->r and reload it,
-; which doesn't make progress.
-(define_insn_and_split "*movtd_internal"
- [(set (match
Re: [patch libiberty]: Fix PR 54620
On Wed, Jan 30, 2013 at 9:45 AM, Kai Tietz wrote: > > 2013-01-30 Kai Tietz > > PR other/54620 > * sha1.c (sha1_process_block): Handle case that size_t is > a wider-integer-scalar as a 32-bit unsigned integer. This is OK. Thanks. Ian
Re: [patch libiberty]: Fix PR 543413
On Wed, Jan 30, 2013 at 9:44 AM, Kai Tietz wrote: > > 2013-01-30 Kai Tietz > > PR other/543413 > * md5.c (md5_process_block): Handle case that size_t is > a wider-integer-scalar a 32-bit unsigned integer. This is OK. Thanks. Ian
Merge from trunk to gccgo branch
I've merged trunk revision 195591 to the gccgo branch. Ian
[PATCH], GCC 4.9 powerpc, merge movdi insns
This is the last of the merge insn patches. It merges the power6x movdi with
the normal floating point movdi.
2013-01-30 Michael Meissner
* config/rs6000/rs6000.md (movdi_mfpgpr): Delete, combine with
movdi_internal64, using wg constraint for move direct operations.
Like the other patches, I have bootstrapped with it, and had no regression
changes. Once 4.9 opens up, is this acceptable to be checked in?
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 195592)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -8542,10 +8542,10 @@ (define_split
[(pc)]
{ rs6000_split_multireg_move (operands[0], operands[1]); DONE; })
-(define_insn "*movdi_mfpgpr"
- [(set (match_operand:DI 0 "nonimmediate_operand"
"=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*d")
- (match_operand:DI 1 "input_operand" "r,Y,r,I,L,nF,d,m,d,*h,r,0,*d,r"))]
- "TARGET_POWERPC64 && TARGET_MFPGPR && TARGET_HARD_FLOAT && TARGET_FPRS
+(define_insn "*movdi_internal64"
+ [(set (match_operand:DI 0 "nonimmediate_operand"
"=Y,r,r,r,r,r,?m,?*d,?*d,?Z,?wa,?wa,r,*h,*h,?wa,r,?*wg")
+ (match_operand:DI 1 "input_operand"
"r,Y,r,I,L,nF,d,m,d,wa,Z,wa,*h,r,0,O,*wg,r"))]
+ "TARGET_POWERPC64
&& (gpc_reg_operand (operands[0], DImode)
|| gpc_reg_operand (operands[1], DImode))"
"@
@@ -8558,36 +8558,17 @@ (define_insn "*movdi_mfpgpr"
stfd%U0%X0 %1,%0
lfd%U1%X1 %0,%1
fmr %0,%1
+ stxsd%U0x %x1,%y0
+ lxsd%U1x %x0,%y1
+ xxlor %x0,%x1,%x1
mf%1 %0
mt%0 %1
nop
+ xxlxor %x0,%x0,%x0
mftgpr %0,%1
mffgpr %0,%1"
- [(set_attr "type"
"store,load,*,*,*,*,fpstore,fpload,fp,mfjmpr,mtjmpr,*,mftgpr,mffgpr")
- (set_attr "length" "4,4,4,4,4,20,4,4,4,4,4,4,4,4")])
-
-(define_insn "*movdi_internal64"
- [(set (match_operand:DI 0 "nonimmediate_operand"
"=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,?wa")
- (match_operand:DI 1 "input_operand" "r,Y,r,I,L,nF,d,m,d,*h,r,0,O"))]
- "TARGET_POWERPC64 && (!TARGET_MFPGPR || !TARGET_HARD_FLOAT || !TARGET_FPRS)
- && (gpc_reg_operand (operands[0], DImode)
- || gpc_reg_operand (operands[1], DImode))"
- "@
- std%U0%X0 %1,%0
- ld%U1%X1 %0,%1
- mr %0,%1
- li %0,%1
- lis %0,%v1
- #
- stfd%U0%X0 %1,%0
- lfd%U1%X1 %0,%1
- fmr %0,%1
- mf%1 %0
- mt%0 %1
- nop
- xxlxor %x0,%x0,%x0"
- [(set_attr "type"
"store,load,*,*,*,*,fpstore,fpload,fp,mfjmpr,mtjmpr,*,vecsimple")
- (set_attr "length" "4,4,4,4,4,20,4,4,4,4,4,4,4")])
+ [(set_attr "type"
"store,load,*,*,*,*,fpstore,fpload,fp,fpstore,fpload,vecsimple,mfjmpr,mtjmpr,*,vecsimple,mftgpr,mffgpr")
+ (set_attr "length" "4,4,4,4,4,20,4,4,4,4,4,4,4,4,4,4,4,4")])
;; immediate value valid for a single instruction hiding in a const_double
(define_insn ""
RE: [PATCH, ARM, iWMMXT] Fix define_constants for WCGR
At 2013-01-22 19:58:43,"Ramana Radhakrishnan" wrote:> > On 01/22/13 09:21, Xinyu Qi wrote: > > Ping, > > > > Fix ChangeLog > > The ChangeLog format includes . > > > > If you want a patch accepted in the future, please help by creating the > Changelog entry in the correct format, i.e. fill in the author's name as well > as > email address as below. I've created an entry as below. Please remember to do > so for every patch you submit - thanks. > > Xinyu Qi > > * config/arm/arm.h (FIRST_IWMMXT_GR_REGNUM): Add comment. > * config/arm/iwmmxt.md (WCGR0): Update. > (WCGR1, WCGR2, WCGR3): Likewise. > > The patch by itself is OK but surprisingly I never saw this earlier. > Your ping has removed the date from the original post so I couldn't track it > down. > > Anyway, please apply. > > > regards, > Ramana > > Hi Nick, Since I have no write access, would you mind to help to check in this patch which has already been approved? The patch is attached. ChangeLog 2013-01-31 Xinyu Qi * config/arm/arm.h (FIRST_IWMMXT_GR_REGNUM): Add comment. * config/arm/iwmmxt.md (WCGR0): Update. (WCGR1, WCGR2, WCGR3): Likewise. Thanks, Xinyu WCGR.diff Description: WCGR.diff
