Re: [PATCH] Fix up copy_decls_walk (PR debug/52260)
OK. Jason
Re: [PATCH, 4.6 regression]. New error: case label does not reduce
On 02/15/2012 06:03 PM, Joseph S. Myers wrote:
On Wed, 15 Feb 2012, Christian Bruel wrote:
Removal of this NOP_EXPR if !CAN_HAVE_LOCATION_P fixes the problem.
looks safe from my testing, because the loc is inserted using
'protected_set_expr_location', whereas no loc for a constant case
doesn't seem to introduce new problems with the debugging information.
But in case I also added a few paranoid gcc_assert.
Is it safe to set TREE_NO_WARNING without that check? I'd have thought
the check was to avoid setting TREE_NO_WARNING on a shared node when
warnings are to be disabled in only one context where that node is used.
OK, I see, we can still keep the check, like with :
Index: c-common.c
===
--- c-common.c (revision 184301)
+++ c-common.c (working copy)
@@ -1435,12 +1435,9 @@
have been done by this point, so remove them again. */
nowarning |= TREE_NO_WARNING (ret);
STRIP_TYPE_NOPS (ret);
- if (nowarning !TREE_NO_WARNING (ret))
-{
- if (!CAN_HAVE_LOCATION_P (ret))
- ret = build1 (NOP_EXPR, TREE_TYPE (ret), ret);
- TREE_NO_WARNING (ret) = 1;
-}
+ if (nowarning CAN_HAVE_LOCATION_P (ret))
+TREE_NO_WARNING (ret) = 1;
+
if (ret != expr)
protected_set_expr_location (ret, loc);
return ret;
We propagate the flag to the new node for non-constant folded
expressions, or for a converted constant (so NOT_EXPR is not stripped),
Does it make sense to set TREE_NO_WARNING for a not-converted folded
constant ? it seems that in the proposal, a warning before the fold is
OK, and a warning after the fold on the new expression is still to be
honored. The NO_WARNING flag on an non-converted constant that is folded
looks unnecessary. I tried to forge different scenarios, were the result
of the folded constant would force a duplicate warning, but no success
to find a regression case.
Thanks
Christian
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
On Wed, Feb 15, 2012 at 6:09 PM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Paolo Bonzini bonz...@gnu.org writes:
This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
gcc_AC_INITFINI_ARRAY.
Here's an updated patch that does so. During testing, I found one
additional complication, though. With the Sun as/GNU ld combination on
Solaris 11/x86, after the bootstrap had completed, all programs linked
against libgcc_s.so.1 SEGVed with a stacktrace like this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x2000 in ?? ()
(gdb) where
#0 0x2000 in ?? ()
#1 0xfefcd73f in call_array () from /usr/lib/ld.so.1
#2 0xfefcd8bd in call_init () from /usr/lib/ld.so.1
#3 0xfefcc8e1 in setup () from /usr/lib/ld.so.1
#4 0xfefdcfd8 in _setup () from /usr/lib/ld.so.1
#5 0xfefc0674 in _rt_boot () from /usr/lib/ld.so.1
#6 0x0804796c in ?? ()
#7 0x08047ab0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The problem turned out to be that with
.section .init_array
as generates
Section Header[5]: sh_name: .init_array
sh_addr: 0 sh_flags: 0
sh_size: 0x4 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x344 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x4
i.e. empty sh_flags. gld seems to mishandle this, since the
corresponding .initarray entry is bad, as can be seen with runtime
linker debugging:
$ LD_DEBUG=init LD_PRELOAD=./libgcc_s.so.1 ls
[...]
02032: 1: calling .initarray[0]:0xfed77100: ./libgcc_s.so.1
02032: 1: calling .initarray[1]:0x2000: ./libgcc_s.so.1
Segmentation Fault
If I change the above to
.section .init_array,aw,@progbits
everything works fine with as/gld, but breaks again with gas/gld since
gas warns about @progbits here. It turned out that
.section .init_array,aw
is fine with both assemblers, while as doesn't understand @init_array.
That's what the patch below uses.
Can you test Linux too? The change of -e0 looks good, but I'd rather check
on the actual system.
This patch has been bootstrapped on i386-pc-solaris2.{8, 9, 10, 11} with
as/ld, gas/ld and gas/gld, i386-pc-solaris2.11 with as/gld, as well as
x86_64-unknown-linux-gnu, correctly detecting .init_array etc. support
on the gld configurations. It was also included with
sparc-sun-solaris2.* bootstraps, but even with gas/gld the configure
test fails. I've got to investigate that separately.
I'm not sure about the varasm.c change - it's definitely not a no-op
(callback will be not set, and the flags will be different). Certainly
the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY
case, not sure why, but you don't make it consistent either because
you don't change that case to SECTION_NOTYPE either. I'd be fine
with it with both calls using SECTION_NOTYPE, but would like to
know what the callback difference is about.
HJ, can you shed some light on this?
Thx,
Richard.
Ok for mainline now?
Thanks.
Rainer
2012-01-20 Rainer Orth r...@cebitec.uni-bielefeld.de
PR target/50166
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Require gcc_SUN_LD_VERSION.
Define _start.
Remove -e 0 from $gcc_cv_ld invocation.
Only use __GLIBC_PREREQ if defined.
Enable on Solaris since Solaris 8 patch.
(gcc_SUN_LD_VERSION): New macro.
* configure.ac (ld_ver) *-*-solaris2*: Refer to
gcc_SUN_LD_VERSION for version number format.
* configure: Regenerate.
* varasm.c (get_elf_initfini_array_priority_section): Use
get_section instead of get_unnamed_section to emit
.init_array/.fini_array with default priority.
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [libitm, darwin] PR52220 move dummy functions definition
Hi Patrick,
On 16 Feb 2012, at 02:17, Patrick Marlier wrote:
Index: libgcc/config/darwin-crt-tm.c
===
--- libgcc/config/darwin-crt-tm.c (revision 184293)
+++ libgcc/config/darwin-crt-tm.c (working copy)
@@ -103,8 +103,6 @@ void __doTMdeRegistrations (void)
_ITM_deregisterTMCloneTable (tmct);
}
-#endif
-
/* Provide dummy functions to satisfy linkage for versions of the
Darwin
tool-chain that that can't handle undefined weak refs at the link
stage.
??? Define these dummy functions only when !
HAVE_ELF_STYLE_WEAKREF. */
@@ -147,3 +145,5 @@ void *_ZnaXRKSt9nothrow_t (size_t s UNUSED, c_noth
{ return NULL; }
void _ZdaPvRKSt9nothrow_t (void * a UNUSED, c_nothrow_p b UNUSED)
{ return; }
+#endif
I've applied this, hopefully we're good to go with TM on Darwin for 4.7.
BTW, you should add yourself to the MAINTAINERS file as per:
http://gcc.gnu.org/svnwrite.html
thanks,
Iain
Re: [PATCH] Fix up slpeel_tree_peel_loop_to_edge (PR tree-optimization/52255)
On Thu, 16 Feb 2012, Jakub Jelinek wrote:
Hi!
On this testcase we ICE, because slpeel_tree_peel_loop_to_edge is first
called with a loop that has a virtual PHI and no virtual PHI in the loop
exit bb and this function doesn't update the vop properly after inserting
second loop and adding all the conditional guards, then vect_loop_versioning
calls loop_version which deep inside of it performs
verify_loop_closed_ssa (true)
which ICEs on the invalid SSA. If that check is commented out, we proceed
with optionally doing another slpeel_tree_peel_loop_to_edge and finally
when all loops are vectorized, mark the vop for renaming and update ssa,
which fixes it up.
Here is an attempt to ensure the vop is updated properly, because calling
update_ssa in each slpeel_tree_peel_loop_to_edge would be IMHO too
expensive. The slpeel_tree_peel_loop_to_edge and its helpers already
DTRT for all other PHIs, the problem with virtual PHIs is that the loop
closed SSA form for other PHIs requires a dummy PHI on the exit bb if
it is used after the loop, but for virtual PHIs it doesn't have this
requirement. The simplest patch below just adds an extra PHI even
for the vop if there isn't any and the loop has it, then the routines in
multiple places just DTRT.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-02-16 Jakub Jelinek ja...@redhat.com
PR tree-optimization/52255
* tree-vect-loop-manip.c (slpeel_tree_peel_loop_to_edge): If
loop-header has virtual PHI, but exit_e-dest doesn't, add
virtual PHI to exit_e-dest and adjust all uses after the loop.
* gcc.c-torture/compile/pr52255.c: New test.
--- gcc/tree-vect-loop-manip.c.jj 2012-01-03 16:22:48.0 +0100
+++ gcc/tree-vect-loop-manip.c2012-02-15 20:15:27.816120830 +0100
@@ -1171,6 +1171,7 @@ slpeel_tree_peel_loop_to_edge (struct lo
basic_block bb_before_first_loop;
basic_block bb_between_loops;
basic_block new_exit_bb;
+ gimple_stmt_iterator gsi;
edge exit_e = single_exit (loop);
LOC loop_loc;
tree cost_pre_condition = NULL_TREE;
@@ -1184,6 +1185,43 @@ slpeel_tree_peel_loop_to_edge (struct lo
the function tree_duplicate_bb is called. */
gimple_register_cfg_hooks ();
+ /* If the loop has a virtual PHI, but exit bb doesn't, create a virtual PHI
+ in the exit bb and rename all the uses after the loop. This simplifies
+ the *guard[12] routines, which assume loop closed SSA form for all PHIs
+ (but normally loop closed SSA form doesn't require virtual PHIs to be
+ in the same form). Doing this early simplifies the checking what
+ uses should be renamed. */
+ for (gsi = gsi_start_phis (loop-header); !gsi_end_p (gsi); gsi_next
(gsi))
+if (!is_gimple_reg (gimple_phi_result (gsi_stmt (gsi
+ {
+ gimple phi = gsi_stmt (gsi);
+ for (gsi = gsi_start_phis (exit_e-dest);
+ !gsi_end_p (gsi); gsi_next (gsi))
+ if (!is_gimple_reg (gimple_phi_result (gsi_stmt (gsi
+ break;
+ if (gsi_end_p (gsi))
+ {
+ gimple new_phi = create_phi_node (SSA_NAME_VAR (PHI_RESULT (phi)),
+ exit_e-dest);
+ tree vop = PHI_ARG_DEF_FROM_EDGE (phi, EDGE_SUCC (loop-latch, 0));
+ source_location loc
+ = gimple_phi_arg_location_from_edge (phi, EDGE_SUCC (loop-latch,
+0));
I suppose UNKNOWN_LOCATION for virtual PHIs is good enough.
I've put down a note add a 'gimple virtual_phi_node (basic_block)'
helper - if we canonicalize the PHI seq to make the single virtual
PHI node come first we can even speed that up. Feel free to add
that helper now.
Ok as-is or with either or both suggested changes.
Thanks,
Richard.
+ imm_use_iterator imm_iter;
+ gimple stmt;
+ tree new_vop = make_ssa_name (SSA_NAME_VAR (PHI_RESULT (phi)),
+ new_phi);
+ use_operand_p use_p;
+
+ add_phi_arg (new_phi, vop, exit_e, loc);
+ gimple_phi_set_result (new_phi, new_vop);
+ FOR_EACH_IMM_USE_STMT (stmt, imm_iter, vop)
+ if (stmt != new_phi gimple_bb (stmt) != loop-header)
+ FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
+ SET_USE (use_p, new_vop);
+ }
+ break;
+ }
/* 1. Generate a copy of LOOP and put it on E (E is the entry/exit of
LOOP).
Resulting CFG would be:
--- gcc/testsuite/gcc.c-torture/compile/pr52255.c.jj 2012-02-15
20:16:23.060799290 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr52255.c 2012-02-15
20:16:05.0 +0100
@@ -0,0 +1,12 @@
+/* PR tree-optimization/52255 */
+
+int a, b, c[10], d[10] = { 0, 0 };
+
+void
+foo (void)
+{
+ for (a = 1; a = 4; a += 1)
+d[a] = d[1];
+ for (; b; ++b)
+c[0] |= 1;
+}
Jakub
--
Richard
Re: [PATCH, 4.6 regression]. New error: case label does not reduce
On 02/15/2012 06:03 PM, Joseph S. Myers wrote:
On Wed, 15 Feb 2012, Christian Bruel wrote:
Removal of this NOP_EXPR if !CAN_HAVE_LOCATION_P fixes the problem.
looks safe from my testing, because the loc is inserted using
'protected_set_expr_location', whereas no loc for a constant case
doesn't seem to introduce new problems with the debugging information.
But in case I also added a few paranoid gcc_assert.
Is it safe to set TREE_NO_WARNING without that check? I'd have thought
the check was to avoid setting TREE_NO_WARNING on a shared node when
warnings are to be disabled in only one context where that node is used.
In fact, we can't omit the TREE_NO_WARNING is !CAN_HAVE_LOCATION_P, the
tentative bellow causes a regression on middle-end/13325.
What I'm unsure is why we couldn't have a TREE_NO_WARNING on a
!CAN_HAVE_LOCATION_P. This seems necessary on some cases without using a
NOP_EXPR.
OK, I see, we can still keep the check, like with :
Index: c-common.c
===
--- c-common.c (revision 184301)
+++ c-common.c (working copy)
@@ -1435,12 +1435,9 @@
have been done by this point, so remove them again. */
nowarning |= TREE_NO_WARNING (ret);
STRIP_TYPE_NOPS (ret);
- if (nowarning !TREE_NO_WARNING (ret))
-{
- if (!CAN_HAVE_LOCATION_P (ret))
- ret = build1 (NOP_EXPR, TREE_TYPE (ret), ret);
- TREE_NO_WARNING (ret) = 1;
-}
+ if (nowarning CAN_HAVE_LOCATION_P (ret))
+TREE_NO_WARNING (ret) = 1;
+
if (ret != expr)
protected_set_expr_location (ret, loc);
return ret;
We propagate the flag to the new node for non-constant folded
expressions, or for a converted constant (so NOT_EXPR is not stripped),
Does it make sense to set TREE_NO_WARNING for a not-converted folded
constant ? it seems that in the proposal, a warning before the fold is
OK, and a warning after the fold on the new expression is still to be
honored. The NO_WARNING flag on an non-converted constant that is folded
looks unnecessary. I tried to forge different scenarios, were the result
of the folded constant would force a duplicate warning, but no success
to find a regression case.
Thanks
Christian
[patch i386]: Fix for x64 windows targets the split of PCREL unspecs
Hi,
Due recent regression test-runs for x86_64-w64-mingw32, I noticed that
some tests actual were failing
due internal-compiler error for code-paths using split_double
functions on PCREL symbols.
The cause for this is that this unspec didn't allowed
constant-interger displacements. This patch fixes
that.
One of the testcases failing was
'testsuite/c-c++-common/dfp/convert-bfp-fold.c -O2'.
ChangeLog
2012-02-16 Kai Tietz kti...@redhat.com
* config/i386/predicates.md (x86_64_immediate_operand):
Allow offset memory references for UNSPEC_PCREL.
* config/i386/i386.c (legitimate_pic_address_disp_p): Allow
interger-constant displacement for UNSPEC_PCREL.
Tested for x86_64-w64-mingw32, and x86_64-unkown-linux-gnu for all
languages. Ok for apply?
Regards,
Kai
Index: config/i386/predicates.md
===
--- config/i386/predicates.md (revision 184304)
+++ config/i386/predicates.md (working copy)
@@ -165,6 +165,7 @@
switch (XINT (XEXP (op, 0), 1))
{
case UNSPEC_GOTPCREL:
+ case UNSPEC_PCREL:
case UNSPEC_DTPOFF:
case UNSPEC_GOTNTPOFF:
case UNSPEC_NTPOFF:
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 184304)
+++ config/i386/i386.c (working copy)
@@ -11823,6 +11823,13 @@
break;
if (GET_CODE (op0) == LABEL_REF)
return true;
+ if (GET_CODE (op0) == CONST
+ GET_CODE (XEXP (op0, 0)) == UNSPEC
+ XINT (XEXP (op0, 0), 1) == UNSPEC_PCREL)
+ return true;
+ if (GET_CODE (op0) == UNSPEC
+ XINT (op0, 1) == UNSPEC_PCREL)
+ return true;
if (GET_CODE (op0) != SYMBOL_REF)
break;
/* FALLTHRU */
Re: [patch i386]: Fix for x64 windows targets the split of PCREL unspecs
The hunk about config/i386/predicates.md (x86_64_immediate_operand) I recet here, actual it would lead to none-PIC code. So updated patch: 2012-02-16 Kai Tietz kti...@redhat.com * config/i386/i386.c (legitimate_pic_address_disp_p): Allow interger-constant displacement for UNSPEC_PCREL. Tested for x86_64-w64-mingw32, and x86_64-unkown-linux-gnu for all languages. Ok for apply? Regards, Kai Index: config/i386/i386.c === --- config/i386/i386.c (revision 184304) +++ config/i386/i386.c (working copy) @@ -11823,6 +11823,13 @@ break; if (GET_CODE (op0) == LABEL_REF) return true; + if (GET_CODE (op0) == CONST + GET_CODE (XEXP (op0, 0)) == UNSPEC + XINT (XEXP (op0, 0), 1) == UNSPEC_PCREL) + return true; + if (GET_CODE (op0) == UNSPEC + XINT (op0, 1) == UNSPEC_PCREL) + return true; if (GET_CODE (op0) != SYMBOL_REF) break; /* FALLTHRU */
Re: [PATCH, 4.6 regression]. New error: case label does not reduce
On Thu, Feb 16, 2012 at 12:49 PM, Christian Bruel christian.br...@st.com wrote: On 02/15/2012 06:03 PM, Joseph S. Myers wrote: On Wed, 15 Feb 2012, Christian Bruel wrote: Removal of this NOP_EXPR if !CAN_HAVE_LOCATION_P fixes the problem. looks safe from my testing, because the loc is inserted using 'protected_set_expr_location', whereas no loc for a constant case doesn't seem to introduce new problems with the debugging information. But in case I also added a few paranoid gcc_assert. Is it safe to set TREE_NO_WARNING without that check? I'd have thought the check was to avoid setting TREE_NO_WARNING on a shared node when warnings are to be disabled in only one context where that node is used. In fact, we can't omit the TREE_NO_WARNING is !CAN_HAVE_LOCATION_P, the tentative bellow causes a regression on middle-end/13325. What I'm unsure is why we couldn't have a TREE_NO_WARNING on a !CAN_HAVE_LOCATION_P. This seems necessary on some cases without using a NOP_EXPR. You cannot have it on possibly shared tree nodes. CAN_HAVE_LOCATION_P tree nodes are not shared (the reverse is not true). Richard.
[Patch,AVR]: Tweak neghi2, add some peephole
neghi2's r,0 alternative reads
com %B0
neg %A0
sbc %B0,__zero_reg__
inc %B0
The INC commutates with the NEG+SBC and can be moved 2 instructions up:
com %B0
inc %B0
neg %A0
sbc %B0,__zero_reg__
COM+INC can be fused to NEG:
neg %B0
neg %A0
sbc %B0,__zero_reg__
with the additional benefit that cc0 is always set_czn now.
The *dec-and-branchhi!=-1 text peephole just coverd vanilla addhi3 without
clobber register. As addhi3 now has a clobber added in many cases,
that peephole don't match them any more. The patch adds peephole alternatives
for clobber variants of addhi3.
Passed without regressions.
Ok to apply?
Johann
* config/avr/avr.md (neghi2): Remove !d,0 alternative. Tweak r,0.
(*dec-and-branchhi!=-1.d.clobber): New text peephole.
(*dec-and-branchhi!=-1.l.clobber): New text peephole.
Index: config/avr/avr.md
===
--- config/avr/avr.md (revision 184269)
+++ config/avr/avr.md (working copy)
@@ -3807,15 +3807,14 @@ (define_insn *negqihi2
(set_attr cc set_n)])
(define_insn neghi2
- [(set (match_operand:HI 0 register_operand =!d,r,r)
- (neg:HI (match_operand:HI 1 register_operand 0,0,r)))]
+ [(set (match_operand:HI 0 register_operand=r,r)
+(neg:HI (match_operand:HI 1 register_operand 0,r)))]
@
- com %B0\;neg %A0\;sbci %B0,lo8(-1)
- com %B0\;neg %A0\;sbc %B0,__zero_reg__\;inc %B0
+ neg %B0\;neg %A0\;sbc %B0,__zero_reg__
clr %A0\;clr %B0\;sub %A0,%A1\;sbc %B0,%B1
- [(set_attr length 3,4,4)
- (set_attr cc set_czn,set_n,set_czn)])
+ [(set_attr length 3,4)
+ (set_attr cc set_czn)])
(define_insn negpsi2
[(set (match_operand:PSI 0 register_operand=!d,r,r)
@@ -4919,7 +4918,7 @@ (define_insn *sbix_branch_tmp_bit7
;; * Peepholes
-(define_peephole
+(define_peephole ; *dec-and-branchsi!=-1.d.clobber
[(parallel [(set (match_operand:SI 0 d_register_operand )
(plus:SI (match_dup 0)
(const_int -1)))
@@ -4960,7 +4959,7 @@ (define_peephole
return ;
})
-(define_peephole
+(define_peephole ; *dec-and-branchhi!=-1
[(set (match_operand:HI 0 d_register_operand )
(plus:HI (match_dup 0)
(const_int -1)))
@@ -4996,7 +4995,81 @@ (define_peephole
return ;
})
-(define_peephole
+;; Same as above but with clobber flavour of addhi3
+(define_peephole ; *dec-and-branchhi!=-1.d.clobber
+ [(parallel [(set (match_operand:HI 0 d_register_operand )
+ (plus:HI (match_dup 0)
+(const_int -1)))
+ (clobber (scratch:QI))])
+ (parallel [(set (cc0)
+ (compare (match_dup 0)
+(const_int -1)))
+ (clobber (match_operand:QI 1 d_register_operand ))])
+ (set (pc)
+(if_then_else (ne (cc0)
+ (const_int 0))
+ (label_ref (match_operand 2 ))
+ (pc)))]
+
+ {
+CC_STATUS_INIT;
+if (test_hard_reg_class (ADDW_REGS, operands[0]))
+ output_asm_insn (sbiw %0,1, operands);
+else
+ output_asm_insn (subi %A0,1 CR_TAB
+ sbc %B0,__zero_reg__, operands);
+
+switch (avr_jump_mode (operands[2], insn))
+ {
+ case 1:
+return brcc %2;
+ case 2:
+return brcs .+2\;rjmp %2;
+ case 3:
+return brcs .+4\;jmp %2;
+ }
+
+gcc_unreachable();
+return ;
+ })
+
+;; Same as above but with clobber flavour of addhi3
+(define_peephole ; *dec-and-branchhi!=-1.l.clobber
+ [(parallel [(set (match_operand:HI 0 l_register_operand )
+ (plus:HI (match_dup 0)
+(const_int -1)))
+ (clobber (match_operand:QI 3 d_register_operand ))])
+ (parallel [(set (cc0)
+ (compare (match_dup 0)
+(const_int -1)))
+ (clobber (match_operand:QI 1 d_register_operand ))])
+ (set (pc)
+(if_then_else (ne (cc0)
+ (const_int 0))
+ (label_ref (match_operand 2 ))
+ (pc)))]
+
+ {
+CC_STATUS_INIT;
+ output_asm_insn (ldi %3,1 CR_TAB
+ sub %A0,%3 CR_TAB
+ sbc %B0,__zero_reg__, operands);
+
+switch (avr_jump_mode (operands[2], insn))
+ {
+ case 1:
+return brcc %2;
+ case 2:
+return brcs .+2\;rjmp %2;
+ case 3:
+return brcs .+4\;jmp %2;
+ }
+
+gcc_unreachable();
+return ;
+ })
+
+(define_peephole ; *dec-and-branchqi!=-1
[(set (match_operand:QI 0 d_register_operand )
(plus:QI (match_dup 0)
(const_int -1)))
Re: [PATCH, 4.6 regression]. New error: case label does not reduce
First, if there isn't a bug in Bugzilla for this problem please file one so it's properly tracked if it takes a while to work out how to solve it. As I understand it from your testcases, it's a matter of certain code that is not valid ISO C but you would like to be accepted unless -pedantic, by analogy with other such code that is accepted. On Thu, 16 Feb 2012, Christian Bruel wrote: What I'm unsure is why we couldn't have a TREE_NO_WARNING on a !CAN_HAVE_LOCATION_P. This seems necessary on some cases without using a NOP_EXPR. Richard explained this. What is the code adding TREE_NO_WARNING in the first place (before folding) for your testcase? It may sometimes be safe to copy constants with copy_node to put TREE_NO_WARNING on the copies. But you'd still need to be careful because there are some tree-node-equality comparisons for constants, against truthvalue_true_node and truthvalue_false_node at least, so those might need to be relaxed a bit to allow any non-overflowed integer-type integer constant with the right value. -- Joseph S. Myers jos...@codesourcery.com
Ping: [PATCH, 4.6] Backport fixes for PR50031, PR50969
Greetings,
Given the recent discussion on getting 4.6 cleaned up, I thought I'd
check back on this one. Thanks!
Bill
On Fri, 2012-02-10 at 14:58 -0600, William J. Schmidt wrote:
This patch backports the two recent trunk fixes for powerpc64
vectorization degradations. The fixes are largely identical to their
4.7 counterparts except that (a) the logic for
STMT_VINFO_PATTERN_DEF_SEQ does not apply in 4.6, and (b) the changes to
vectorizable_conversion in 4.7 correspond to changes in
vectorizable_type_demotion and vectorizable_type_promotion in 4.6.
Bootstrapped and tested for regressions and performance for
powerpc64-linux. OK to commit after the trunk patch has a few days of
burn-in?
Thanks,
Bill
2012-02-10 Bill Schmidt wschm...@linux.vnet.ibm.com
Ira Rosen i...@il.ibm.com
PR tree-optimization/50031
PR tree-optimization/50969
* targhooks.c (default_builtin_vectorization_cost): Handle
vec_promote_demote.
* target.h (enum vect_cost_for_stmt): Add vec_promote_demote.
* tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
all types of reduction and pattern statements.
(vect_estimate_min_profitable_iters): Likewise.
* tree-vect-stmts.c (vect_model_promotion_demotion_cost): New function.
(vect_model_store_cost): Use vec_perm rather than vector_stmt for
statement cost.
(vect_model_load_cost): Likewise.
(vect_get_load_cost): Likewise; add dump logic for explicit realigns.
(vectorizable_type_demotion): Call vect_model_promotion_demotion_cost.
(vectorizable_type_promotion): Likewise.
* config/spu/spu.c (spu_builtin_vectorization_cost): Handle
vec_promote_demote.
* config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
vec_perm for VSX and handle vec_promote_demote.
Index: gcc/targhooks.c
===
--- gcc/targhooks.c (revision 184047)
+++ gcc/targhooks.c (working copy)
@@ -529,6 +529,7 @@ default_builtin_vectorization_cost (enum vect_cost
case scalar_to_vec:
case cond_branch_not_taken:
case vec_perm:
+ case vec_promote_demote:
return 1;
case unaligned_load:
Index: gcc/target.h
===
--- gcc/target.h (revision 184047)
+++ gcc/target.h (working copy)
@@ -128,7 +128,8 @@ enum vect_cost_for_stmt
scalar_to_vec,
cond_branch_not_taken,
cond_branch_taken,
- vec_perm
+ vec_perm,
+ vec_promote_demote
};
/* Sets of optimization levels at which an option may be enabled by
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c (revision 184047)
+++ gcc/tree-vect-loop.c (working copy)
@@ -2104,7 +2104,8 @@ vect_get_single_scalar_iteraion_cost (loop_vec_inf
if (stmt_info
!STMT_VINFO_RELEVANT_P (stmt_info)
(!STMT_VINFO_LIVE_P (stmt_info)
- || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
+ || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE
(stmt_info)))
+!STMT_VINFO_IN_PATTERN_P (stmt_info))
continue;
if (STMT_VINFO_DATA_REF (vinfo_for_stmt (stmt)))
@@ -2251,11 +2252,19 @@ vect_estimate_min_profitable_iters (loop_vec_info
{
gimple stmt = gsi_stmt (si);
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
+
+ if (STMT_VINFO_IN_PATTERN_P (stmt_info))
+ {
+ stmt = STMT_VINFO_RELATED_STMT (stmt_info);
+ stmt_info = vinfo_for_stmt (stmt);
+ }
+
/* Skip stmts that are not vectorized inside the loop. */
if (!STMT_VINFO_RELEVANT_P (stmt_info)
(!STMT_VINFO_LIVE_P (stmt_info)
- || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
+ || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_info
continue;
+
vec_inside_cost += STMT_VINFO_INSIDE_OF_LOOP_COST (stmt_info) *
factor;
/* FIXME: for stmts in the inner-loop in outer-loop vectorization,
some of the outside costs are generated inside the outer-loop.
*/
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 184047)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -623,6 +623,46 @@ vect_model_simple_cost (stmt_vec_info stmt_info, i
}
+/* Model cost for type demotion and promotion operations. PWR is normally
+ zero for single-step promotions and demotions. It will be one if
+ two-step promotion/demotion is required, and so on. Each additional
+ step doubles the number of instructions required. */
+
+static
Re: PATCH: Add capability to contrib/compare_tests to handle directories
On Thu, Feb 16, 2012 at 8:18 AM, Quentin Neill
quentin.neill@gmail.com wrote:
On Tue, Feb 14, 2012 at 9:01 PM, Mike Stump mikest...@comcast.net wrote:
On Feb 14, 2012, at 8:39 AM, Quentin Neill wrote:
Thanks for the fix. This seemed familiar, and upon review it looks
like I never committed this fix:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01194.html
Ah, ok, let's go with your version, it is much better. Thanks.
Committed.
--
Quentin
While working on this, I realized errors detected in directories with
more than one sum file don't show the sum file with the problem
(instead they show the sum1/sum2 files). Patch below iterates over
sum files instead of concatenating. Okay to commit?
(output before the patch)
$ compare_tests -strict /d/qneill/tst.w[io].zeroshift.*
# Comparing directories
## Dir1=/d/qneill/tst.wi.zeroshift.192188f71c30: 2 sum files
## Dir2=/d/qneill/tst.wo.zeroshift.bdcd46972d7d: 2 sum files
# Comparing 2 common sum files
## /bin/sh /d/paqa/gcc/compare_tests -strict /tmp/gxx-sum1.4434
/tmp/gxx-sum2.4434
Old tests that passed, that have disappeared: (Eeek!)
gcc.target/x86_64/abi/callabi/vaarg-5b.c (test for excess errors)
Strict test fails
(output after the patch)
$ ./compare_tests -strict /d/qneill/tst.w[io].zeroshift.*
# Comparing directories
## Dir1=/d/qneill/tst.wi.zeroshift.192188f71c30: 2 sum files
## Dir2=/d/qneill/tst.wo.zeroshift.bdcd46972d7d: 2 sum files
# Comparing 2 common sum files
## /bin/sh ./compare_tests -strict
/d/qneill/tst.wi.zeroshift.192188f71c30/bld/gcc/testsuite/gcc/gcc.sum
/d/qneill/tst.wo.zeroshift.bdcd46972d7d/bld/gcc/testsuite/gcc/gcc.sum
Old tests that passed, that have disappeared: (Eeek!)
gcc.target/x86_64/abi/callabi/vaarg-5b.c (test for excess errors)
Strict test fails
## Differences found: bld/gcc/testsuite/gcc/gcc.sum
## /bin/sh ./compare_tests -strict
/d/qneill/tst.wi.zeroshift.192188f71c30/bld/gcc/testsuite/gcc/g++.sum
/d/qneill/tst.wo.zeroshift.bdcd46972d7d/bld/gcc/testsuite/gcc/g++.sum
# 1 differences in 2 common sum files found
diff --git a/contrib/compare_tests b/contrib/compare_tests
index 2fc6e05..611faab 100755
--- a/contrib/compare_tests
+++ b/contrib/compare_tests
@@ -43,9 +43,7 @@ lst2=/tmp/$tool-lst2.$$
lst3=/tmp/$tool-lst3.$$
lst4=/tmp/$tool-lst4.$$
lst5=/tmp/$tool-lst5.$$
-sum1=/tmp/$tool-sum1.$$
-sum2=/tmp/$tool-sum2.$$
-tmps=$tmp1 $tmp2 $now_s $before_s $lst1 $lst2 $lst3 $lst4 $lst5 $sum1 $sum2
+tmps=$tmp1 $tmp2 $now_s $before_s $lst1 $lst2 $lst3 $lst4 $lst5
[ $1 = -strict ] strict=$1 shift
[ $1 = -? ] usage
@@ -86,15 +84,16 @@ if [ -d $1 -a -d $2 ] ; then
fi
cmnsums=`cat $lst5 | wc -l`
echo # Comparing $cmnsums common sum files
- ( for fname in `cat $lst5`; do cat $1/$fname; done ) $sum1
- ( for fname in `cat $lst5`; do cat $2/$fname; done ) $sum2
- echo ## ${CONFIG_SHELL-/bin/sh} $0 $strict $sum1 $sum2
- ${CONFIG_SHELL-/bin/sh} $0 $strict $sum1 $sum2
- ret=$?
- if [ $ret -ne 0 ]; then
- exit_status=`expr $exit_status + 1`
- echo ## Differences found: $fname
- fi
+ for fname in `cat $lst5`
+ do
+ echo ## ${CONFIG_SHELL-/bin/sh} $0 $strict $1/$fname $2/$fname
+ ${CONFIG_SHELL-/bin/sh} $0 $strict $1/$fname $2/$fname
+ ret=$?
+ if [ $ret -ne 0 ]; then
+ exit_status=`expr $exit_status + 1`
+ echo ## Differences found: $fname
+ fi
+ done
if [ $exit_status -ne 0 ]; then
echo # $exit_status differences in $cmnsums common
sum files found
else
--
Quentin
Re: [PATCH] Don't decrease mem_cost for special MEMs, even with REG_EQUIV (PR rtl-optimization/52208)
On 02/16/2012 01:56 AM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, if SET_SRC MEM (with REG_EQUIV note) isn't a MEM
that can be used in general operations, but requires some specialized
instruction to load it, decreasing its mem_cost results sometimes in
worse code, the MEM is loaded with a specialized insn, then stored into
a stack slot because e.g. a negative memory cost has been chosen as
cheapest, then loaded back from the stack slot.
This patch gives up if the MEM isn't general_operand.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok. Thanks, Jakub.
2012-02-16 Jakub Jelinekja...@redhat.com
PR rtl-optimization/52208
* ira-costs.c (scan_one_insn): Don't decrease mem_cost
for MEMs with REG_EQUIV, if the MEM isn't general_operand.
--- gcc/ira-costs.c.jj 2012-02-15 07:34:54.0 +0100
+++ gcc/ira-costs.c 2012-02-15 20:57:49.239393641 +0100
@@ -1306,14 +1306,21 @@ scan_one_insn (rtx insn)
Similarly if we're loading other constants from memory (constant
pool, TOC references, small data areas, etc) and this is the only
- assignment to the destination pseudo. */
+ assignment to the destination pseudo.
+
+ Don't do this if SET_SRC (set) isn't a general operand, if it is
+ a memory requiring special instructions to load it, decreasing
+ mem_cost might result in it being loaded using the specialized
+ instruction into a register, then stored into stack and loaded
+ again from the stack. See PR52208. */
if (set != 0 REG_P (SET_DEST (set)) MEM_P (SET_SRC (set))
(note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != NULL_RTX
((MEM_P (XEXP (note, 0)))
|| (CONSTANT_P (XEXP (note, 0))
targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
XEXP (note, 0))
- REG_N_SETS (REGNO (SET_DEST (set))) == 1)))
+ REG_N_SETS (REGNO (SET_DEST (set))) == 1))
+ general_operand (SET_SRC (set), GET_MODE (SET_SRC (set
{
enum reg_class cl = GENERAL_REGS;
rtx reg = SET_DEST (set);
Jakub
Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)
On 11/02/12 01:11, Richard Henderson wrote:
On 02/08/2012 08:28 AM, Andrew Stubbs wrote:
Unfortunately, these don't work in Thumb mode (no IT block), and I'd have to
add arith-shift variants, I think, for ARM mode to work.
H ... I'll try again.
Does it work to simply use branches initially, and rely on post-reload
ifcvt to transform to cond_exec when possible?
It did work in ARM mode, but did not work in Thumb2 mode. My recent
patch has fixed that:
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00734.html
With that patch applied, the attached patch has almost the right effect.
The only problem now is that the scheduling gives multiple IT blocks,
but that's a different problem.
Here's the new thumb code for ashiftrt:
ldrdr2, [r0]
push{r4, r5, r6}
mov r4, r1
rsb r5, r1, #32
subsr6, r4, #32
lsr r0, r2, r4
lsl r5, r3, r5
it ge
asrge r6, r3, r6
asr r1, r3, r4
orr r0, r0, r5
it ge
orrge r0, r0, r6
pop {r4, r5, r6}
bx lr
OK for 4.8?
Andrew
2012-02-16 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm-protos.h (arm_emit_coreregs_64bit_shift): New
prototype.
* config/arm/arm.c (arm_emit_coreregs_64bit_shift): New function.
* config/arm/arm.md (ashldi3): Use arm_emit_coreregs_64bit_shift.
(ashrdi3,lshrdi3): Likewise.
(arm_cond_branch): Remove '*' to enable gen_arm_cond_branch.
---
gcc/config/arm/arm-protos.h |3 +
gcc/config/arm/arm.c| 201 +++
gcc/config/arm/arm.md | 104 --
3 files changed, 280 insertions(+), 28 deletions(-)
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 296550a..df8d7a9 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -242,6 +242,9 @@ struct tune_params
extern const struct tune_params *current_tune;
extern int vfp3_const_double_for_fract_bits (rtx);
+
+extern void arm_emit_coreregs_64bit_shift (enum rtx_code, rtx, rtx, rtx, rtx,
+ rtx);
#endif /* RTX_CODE */
#endif /* ! GCC_ARM_PROTOS_H */
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 0bded8d..f3accc8 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -25139,5 +25139,206 @@ vfp3_const_double_for_fract_bits (rtx operand)
return 0;
}
+/* The default expansion of general 64-bit shifts in core-regs is suboptimal
+ on ARM, since we know that shifts by negative amounts are no-ops.
+
+ It's safe for the input and output to be the same register, but
+ early-clobber rules apply for the shift amount and scratch registers.
+
+ Shift by register requires both scratch registers. Shift by a constant
+ less than 32 in Thumb2 mode requires SCRATCH1 only. In all other cases
+ the scratch registers may be NULL.
+
+ Additionally, ashiftrt by a register also clobbers the CC register. */
+void
+arm_emit_coreregs_64bit_shift (enum rtx_code code, rtx out, rtx in,
+ rtx amount, rtx scratch1, rtx scratch2)
+{
+ rtx out_high = gen_highpart (SImode, out);
+ rtx out_low = gen_lowpart (SImode, out);
+ rtx in_high = gen_highpart (SImode, in);
+ rtx in_low = gen_lowpart (SImode, in);
+
+ /* Bits flow from up-stream to down-stream. */
+ rtx out_up = code == ASHIFT ? out_low : out_high;
+ rtx out_down = code == ASHIFT ? out_high : out_low;
+ rtx in_up = code == ASHIFT ? in_low : in_high;
+ rtx in_down = code == ASHIFT ? in_high : in_low;
+
+ gcc_assert (code == ASHIFT || code == ASHIFTRT || code == LSHIFTRT);
+ gcc_assert (out
+ (REG_P (out) || GET_CODE (out) == SUBREG)
+ GET_MODE (out) == DImode);
+ gcc_assert (in
+ (REG_P (in) || GET_CODE (in) == SUBREG)
+ GET_MODE (in) == DImode);
+ gcc_assert (amount
+ (((REG_P (amount) || GET_CODE (amount) == SUBREG)
+ GET_MODE (amount) == SImode)
+ || CONST_INT_P (amount)));
+ gcc_assert (scratch1 == NULL
+ || (GET_CODE (scratch1) == SCRATCH)
+ || (GET_MODE (scratch1) == SImode
+ REG_P (scratch1)));
+ gcc_assert (scratch2 == NULL
+ || (GET_CODE (scratch2) == SCRATCH)
+ || (GET_MODE (scratch2) == SImode
+ REG_P (scratch2)));
+ gcc_assert (!REG_P (out) || !REG_P (amount)
+ || !HARD_REGISTER_P (out)
+ || (REGNO (out) != REGNO (amount)
+ REGNO (out) + 1 != REGNO (amount)));
+
+ /* Macros to make following code more readable. */
+ #define SUB_32(DEST,SRC) \
+ gen_addsi3 ((DEST), (SRC), gen_rtx_CONST_INT (VOIDmode, -32))
+ #define RSB_32(DEST,SRC) \
+ gen_subsi3 ((DEST), gen_rtx_CONST_INT (VOIDmode, 32), (SRC))
+ #define SUB_S_32(DEST,SRC) \
+ gen_addsi3_compare0 ((DEST), (SRC), \
+ gen_rtx_CONST_INT (VOIDmode, -32))
+ #define SET(DEST,SRC) \
+ gen_rtx_SET (SImode, (DEST), (SRC))
+ #define SHIFT(CODE,SRC,AMOUNT) \
+ gen_rtx_fmt_ee ((CODE), SImode, (SRC), (AMOUNT))
+ #define
[PATCH, i386] RTM support
Hello guys, Here is a patch which adds support of first part of Intel TSX extensions. Could you please have a look? ChangeLog entry: 2012-02-16 Kirill Yukhin kirill.yuk...@intel.com * common/config/i386/i386-common.c (OPTION_MASK_ISA_RTM_SET): New. (OPTION_MASK_ISA_RTM_UNSET): Ditto. (ix86_handle_option): Handle OPT_mrtm. * config.gcc (i[34567]86-*-*): Add rtmintrin.h and xtestintrin.h. (x86_64-*-*): Ditto. * i386-builtin-types.def (CHAR_FTYPE_VOID, INT_FTYPE_VOID): New. * config/i386/i386-c.c (ix86_target_macros_internal): Define __RTM__ if needed. (ix86_target_string): Define -mrtm option. (PTA_RTM): New. (ix86_option_override_internal): Extend cirei7-avx with RTM option. Handle new option. (ix86_valid_target_attribute_inner_p): Add OPT_mrtm. (ix86_builtins): Add IX86_BUILTIN_XBEGIN, IX86_BUILTIN_XEND, IX86_BUILTIN_XTEST. (bdesc_special_args): Ditto. (ix86_init_mmx_sse_builtins): Add IX86_BUILTIN_XABORT. (ix86_expand_special_args_builtin): Handle new built-in types. (ix86_expand_builtin): Handle XABORT instruction. * config/i386/i386.h (TARGET_RTM): New. * config/i386/i386.md (UNSPECV_XBEGIN): New. (UNSPECV_XEND): Ditto. (UNSPECV_XABORT): Ditto. (UNSPECV_XTEST): Ditto. (xbegin): Ditto. (xbegin_1): Ditto. (xend): Ditto. (xabort): Ditto (xtest): Ditto. (xtest_1): Ditto. * config/i386/i386.opt (mrtm): New. * config/i386/immintrin.h: Include rtmintrin.h and xtestintrin.h. * config/i386/rtmintrin.h: New header. * config/i386/xtestintrin.h: Ditto. testsuite/ChangeLog entry: 2012-02-16 Kirill Yukhin kirill.yuk...@intel.com * gcc.target/i386/rtm-xabort-1.c: New. * gcc.target/i386/rtm-xbegin-1.c: Ditto. * gcc.target/i386/rtm-xend-1.c: Ditto. * gcc.target/i386/rtm-xtest-1.c: Ditto. Testing passed, bootstrap passed on trunk. BTW, I have no idea, where we can commit that? Seems, 4.7.0 is closed for such features... Thanks, K rtm.gcc.patch Description: Binary data
Re: [PATCH, i386] RTM support
Here is link to the description of TSX: http://software.intel.com/en-us/blogs/2012/02/07/transactional-synchronization-in-haswell/ K On Thu, Feb 16, 2012 at 8:06 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Hello guys, Here is a patch which adds support of first part of Intel TSX extensions. Could you please have a look? ChangeLog entry: 2012-02-16 Kirill Yukhin kirill.yuk...@intel.com * common/config/i386/i386-common.c (OPTION_MASK_ISA_RTM_SET): New. (OPTION_MASK_ISA_RTM_UNSET): Ditto. (ix86_handle_option): Handle OPT_mrtm. * config.gcc (i[34567]86-*-*): Add rtmintrin.h and xtestintrin.h. (x86_64-*-*): Ditto. * i386-builtin-types.def (CHAR_FTYPE_VOID, INT_FTYPE_VOID): New. * config/i386/i386-c.c (ix86_target_macros_internal): Define __RTM__ if needed. (ix86_target_string): Define -mrtm option. (PTA_RTM): New. (ix86_option_override_internal): Extend cirei7-avx with RTM option. Handle new option. (ix86_valid_target_attribute_inner_p): Add OPT_mrtm. (ix86_builtins): Add IX86_BUILTIN_XBEGIN, IX86_BUILTIN_XEND, IX86_BUILTIN_XTEST. (bdesc_special_args): Ditto. (ix86_init_mmx_sse_builtins): Add IX86_BUILTIN_XABORT. (ix86_expand_special_args_builtin): Handle new built-in types. (ix86_expand_builtin): Handle XABORT instruction. * config/i386/i386.h (TARGET_RTM): New. * config/i386/i386.md (UNSPECV_XBEGIN): New. (UNSPECV_XEND): Ditto. (UNSPECV_XABORT): Ditto. (UNSPECV_XTEST): Ditto. (xbegin): Ditto. (xbegin_1): Ditto. (xend): Ditto. (xabort): Ditto (xtest): Ditto. (xtest_1): Ditto. * config/i386/i386.opt (mrtm): New. * config/i386/immintrin.h: Include rtmintrin.h and xtestintrin.h. * config/i386/rtmintrin.h: New header. * config/i386/xtestintrin.h: Ditto. testsuite/ChangeLog entry: 2012-02-16 Kirill Yukhin kirill.yuk...@intel.com * gcc.target/i386/rtm-xabort-1.c: New. * gcc.target/i386/rtm-xbegin-1.c: Ditto. * gcc.target/i386/rtm-xend-1.c: Ditto. * gcc.target/i386/rtm-xtest-1.c: Ditto. Testing passed, bootstrap passed on trunk. BTW, I have no idea, where we can commit that? Seems, 4.7.0 is closed for such features... Thanks, K
Re: [patch] Poison SMALL_REGISTER_CLASSES
Hi Mike, Hi Steve, * config/rx/rx.h: Remove SMALL_REGISTER_CLASSES. I wasn't sure if these are obvious, because I already removed the definition from rx.h before, see ChangeLog-2010. Maybe someone put it back intentionally. Nick did it (intentionally) with: Sorry about that - sanfu - please consider the RX remove SMALL_REGISTER_CLASS (re)patch as obvious/approved. Cheers Nick
Re: [PATCH, i386] RTM support
Hi, On 02/16/2012 11:06 AM, Kirill Yukhin wrote: +(define_insn xbegin_1 + [(set (match_operand:SI 0 register_operand =a) +(unspec_volatile:SI [(match_dup 0)] UNSPECV_XBEGIN)) + (set (match_operand:BLK 1 ) +(unspec_volatile:BLK [(match_dup 1)] UNSPECV_XBEGIN))] + TARGET_RTM + xbegin\t.+6 + [(set_attr type other) + (set_attr length 3)]) + Here you cannot specify your fallback instruction address. Since those primitives provide high performance speculative code, I would prefer to move my fallback code far away from the speculative code path to improve the code locality. Thanks for working on this. -- Patrick
Re: [PATCH, i386] RTM support
On Thu, Feb 16, 2012 at 11:26:53AM -0500, Patrick Marlier wrote:
On 02/16/2012 11:06 AM, Kirill Yukhin wrote:
+(define_insn xbegin_1
+ [(set (match_operand:SI 0 register_operand =a)
+(unspec_volatile:SI [(match_dup 0)] UNSPECV_XBEGIN))
+ (set (match_operand:BLK 1 )
+(unspec_volatile:BLK [(match_dup 1)] UNSPECV_XBEGIN))]
+ TARGET_RTM
+ xbegin\t.+6
+ [(set_attr type other)
+ (set_attr length 3)])
+
Here you cannot specify your fallback instruction address. Since
those primitives provide high performance speculative code, I would
prefer to move my fallback code far away from the speculative code
path to improve the code locality.
The intrinsic/builtin just returns a value, so I think you need to
write
if (_xbegin () == ~0)
{
transaction;
_xend ();
}
else
{
fallback;
}
if you want to use different fallback code from the transaction code.
So the above is right and needed, though perhaps we might want
a combine pattern or peephole to turn the
movl $-1, %eax
xbegin .+6
cmpl %eax, $-1
jne 1f
sequence into
movl $-1, %eax
xbegin 1f
if flags register is dead at that point, and perhaps also remove the
movl $-1, %eax if %eax is not live when not jumping.
This is about the intrinsics anyway, the TM code is free to use something
else internally.
Jakub
Re: [PATCH, 4.6 regression]. New error: case label does not reduce
On 02/16/2012 02:14 PM, Joseph S. Myers wrote: First, if there isn't a bug in Bugzilla for this problem please file one so it's properly tracked if it takes a while to work out how to solve it. OK, tracked with PR52283 As I understand it from your testcases, it's a matter of certain code that is not valid ISO C but you would like to be accepted unless -pedantic, by analogy with other such code that is accepted. On Thu, 16 Feb 2012, Christian Bruel wrote: What I'm unsure is why we couldn't have a TREE_NO_WARNING on a !CAN_HAVE_LOCATION_P. This seems necessary on some cases without using a NOP_EXPR. Richard explained this. thanks for the explanation, Christian
Re: [committed] Fix a typo (PR translation/52264)
On Feb 15, 2012, at 10:32 PM, Jakub Jelinek wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious:
2012-02-16 Jakub Jelinek ja...@redhat.com
PR translation/52264
* cgraphunit.c (verify_cgraph_node): Fix a typo.
--- gcc/cgraphunit.c.jj 2012-02-12 15:46:32.0 +0100
+++ gcc/cgraphunit.c 2012-02-15 21:29:25.927382754 +0100
@@ -667,7 +667,7 @@ verify_cgraph_node (struct cgraph_node *
for (i = 0; ipa_ref_list_reference_iterate (node-ref_list, i, ref);
i++)
if (ref-use != IPA_REF_ALIAS)
{
- error (Alias has non-alias refernece);
+ error (Alias has non-alias reference);
Unless Alias means something very specific, the english word should be lower
case. Since this is the middle end, it should not refer to anything terribly
specific, so, is should be lower case.
Re: [committed] Fix a typo (PR translation/52264)
On Feb 16, 2012, at 8:59 AM, Mike Stump wrote: -error (Alias has non-alias refernece); +error (Alias has non-alias reference); Unless Alias means something very specific, the english word should be lower case. Since this is the middle end, it should not refer to anything terribly specific, so, is should be lower case. Likewise: cgraphunit.c: error (An indirect edge from %s is not marked as indirect or has cgraphunit.c: error (Alias has call edges); cgraphunit.c: error (Alias has non-alias refernece); cgraphunit.c: error (Alias has more than one alias reference); cgraphunit.c: error (Analyzed alias has no reference); cgraphunit.c: error (No edge out of thunk node); cgraphunit.c: error (More than one edge out of thunk node); cgraphunit.c: error (Thunk is not supposed to have body); coverage.c: error (Profile data for function %u is corrupted, fn_ident); coverage.c: error (Profile data for function %u is corrupted, fn_ident); genautomata.c: error (Name `%s' contains quotes, name); genautomata.c:error (The following units do not satisfy units-automata distribution rule); genautomata.c:error (Reserv %s:, insn_reserv_name); genautomata.c: error (Automaton `%s': Insn `%s' will never be issued, genautomata.c: error (Insn `%s' will never be issued, genpreds.c: error (Multi-letter constraints with first letter '%c' lto-cgraph.c: fatal_error (Profile information in %s corrupted, passes.c: error (Invalid range %s in option %s, passes.c: error (Invalid range %s in option %s, tree-eh.c: error (Incorrect EH edge %i-%i, bb-index, eh_edge-dest-index); value-prof.c: error (Histogram value statement does not correspond to value-prof.c:error (Inconsistent profile: indirect call target (%d) does not exist, func_id); and for the front-ends and friends: ada/terminals.c: report_file_error (Could not open exe: , Qnil); ada/terminals.c: report_file_error (Missing NT signature. Unknown file type.\n, Qnil); ada/terminals.c: report_file_error (Creation of child's IN handle, Qnil); ada/terminals.c: report_file_error (Creation of child's OUT handle, Qnil); ada/terminals.c: report_file_error (Creation of child's OUT handle, Qnil); ada/terminals.c:report_file_error (Spawning child process, Qnil); cp/semantics.c: error (Parameter pack __bases only valid in template declaration); java/jcf-dump.c: perror (Could not find class); java/jcf-io.c:perror (Could not figure length of .class file); java/jcf-io.c:perror (Failed to read .class file); java/resource.c: perror (Failed to read resource file); java/resource.c: perror (Could not figure length of resource file); lto/lto.c:fatal_error (Cannot open %s, file_data-file_name); lto/lto.c: fatal_error (Cannot map %s, file_data-file_name); lto/lto.c: fatal_error (Cannot read %s, file_data-file_name); except fortran, which seems to not follow the general rule.
Re: [PATCH, i386] RTM support
On Thu, Feb 16, 2012 at 11:26:53AM -0500, Patrick Marlier wrote: Here you cannot specify your fallback instruction address. Since those primitives provide high performance speculative code, I would prefer to move my fallback code far away from the speculative code path to improve the code locality. This is just how the intrinsic is defined. You can do something else of course for other code. For macros asm goto maps well to XBEGIN today. -Andi
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
On Thu, Feb 16, 2012 at 1:32 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Feb 15, 2012 at 6:09 PM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Paolo Bonzini bonz...@gnu.org writes:
This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
gcc_AC_INITFINI_ARRAY.
Here's an updated patch that does so. During testing, I found one
additional complication, though. With the Sun as/GNU ld combination on
Solaris 11/x86, after the bootstrap had completed, all programs linked
against libgcc_s.so.1 SEGVed with a stacktrace like this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x2000 in ?? ()
(gdb) where
#0 0x2000 in ?? ()
#1 0xfefcd73f in call_array () from /usr/lib/ld.so.1
#2 0xfefcd8bd in call_init () from /usr/lib/ld.so.1
#3 0xfefcc8e1 in setup () from /usr/lib/ld.so.1
#4 0xfefdcfd8 in _setup () from /usr/lib/ld.so.1
#5 0xfefc0674 in _rt_boot () from /usr/lib/ld.so.1
#6 0x0804796c in ?? ()
#7 0x08047ab0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The problem turned out to be that with
.section .init_array
as generates
Section Header[5]: sh_name: .init_array
sh_addr: 0 sh_flags: 0
sh_size: 0x4 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x344 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x4
i.e. empty sh_flags. gld seems to mishandle this, since the
corresponding .initarray entry is bad, as can be seen with runtime
linker debugging:
$ LD_DEBUG=init LD_PRELOAD=./libgcc_s.so.1 ls
[...]
02032: 1: calling .initarray[0]:0xfed77100: ./libgcc_s.so.1
02032: 1: calling .initarray[1]:0x2000: ./libgcc_s.so.1
Segmentation Fault
If I change the above to
.section .init_array,aw,@progbits
everything works fine with as/gld, but breaks again with gas/gld since
gas warns about @progbits here. It turned out that
.section .init_array,aw
is fine with both assemblers, while as doesn't understand @init_array.
That's what the patch below uses.
Can you test Linux too? The change of -e0 looks good, but I'd rather check
on the actual system.
This patch has been bootstrapped on i386-pc-solaris2.{8, 9, 10, 11} with
as/ld, gas/ld and gas/gld, i386-pc-solaris2.11 with as/gld, as well as
x86_64-unknown-linux-gnu, correctly detecting .init_array etc. support
on the gld configurations. It was also included with
sparc-sun-solaris2.* bootstraps, but even with gas/gld the configure
test fails. I've got to investigate that separately.
I'm not sure about the varasm.c change - it's definitely not a no-op
(callback will be not set, and the flags will be different). Certainly
the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY
case, not sure why, but you don't make it consistent either because
you don't change that case to SECTION_NOTYPE either. I'd be fine
with it with both calls using SECTION_NOTYPE, but would like to
know what the callback difference is about.
HJ, can you shed some light on this?
GNU assembler understands:
.section.init_array*
If Solaris assembler doesn't, I don't know how it will work
with .init_array with priority.
--
H.J.
RE: [patch] clean up pdp11.md a bit
These look fine. I'll defer to others on whether it should wait to Phase 1. I had tried to make divmod work but never figured out the reason why it did not. Thanks for answering that question. As for the subregs that Richard commented on -- I will gladly admit that this target isn't all clean yet. So that goes onto the list of things to work on, too. paul -Original Message- From: Steven Bosscher [mailto:stevenb@gmail.com] Sent: Tuesday, February 14, 2012 5:09 PM To: Koning, Paul; GCC Patches Subject: [patch] clean up pdp11.md a bit Hello, Just a few cleanups for things I noticed last weekend. * Constraints on define_expand are never used, remove them (most other ports do not have constraints on define_expands either) * Some patterns have no name, makes debugging a bit harder * The divmodhi4 expander has been commented out since Day 1 of egcs. Explain why. Tested by building the compiler. For pdp11-elf, which is not a supported target according to backends.html, but it's not rejected. Not sure what the right target is to compile for. In any case, I obviously have no PDP-11 to test on. But the patch has no changes that impact code generation (the constraints were already ignored). OK for trunk? Ciao! Steven
Re: [PATCH, i386] RTM support
On 02/16/2012 11:47 AM, Jakub Jelinek wrote: if you want to use different fallback code from the transaction code. So the above is right and needed, though perhaps we might want a combine pattern or peephole to turn the movl $-1, %eax xbegin .+6 cmpl %eax, $-1 jne 1f sequence into movl $-1, %eax xbegin 1f if flags register is dead at that point, and perhaps also remove the movl $-1, %eax if %eax is not live when not jumping. Yes this is what I meant. In fact, I was expecting that to be implemented directly with the RTM support otherwise as Andi said, asm macros is enough to use RTM. I think the goal of Intel was to avoid this cmp/jne but at least this a first step to implement RTM intrinsics in GCC. (It was just a note that it could be improved, no more). On 02/16/2012 12:11 PM, Andi Kleen wrote: For macros asm goto maps well to XBEGIN today. Yes, I tried it when HJ committed it in binutils but thanks for the info. -- Patrick.
Re: PR middle-end/52141: ICE due to asm statement
On 02/15/12 12:07, Jakub Jelinek wrote:
On Wed, Feb 15, 2012 at 11:59:15AM -0600, Aldy Hernandez wrote:
Hmmm, isn't %K for trees? We're talking gimple, and FUNCTION_DECLs,
which don't have a TREE_BLOCK, here.
Gimple stmts have gimple_block, I guess you'd need to create some tree
and set its TREE_BLOCK and EXPR_LOCATION from gimple_block/gimple_location.
Or add something similar to %K that would take the same info from gimple
stmt and pass a stmt instead of a tree.
Jakub
This may not actually work. I am getting a different backtrace
depending on whether I use -O0 or -O[123]. With the attached patch I
get a proper backtrace with -O0, but none whatsoever with -O1:
#GOOD
houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O0 -quiet -w
In function 'asmfunc',
inlined from 'f' at a.c:13:10:
a.c:7:3: error: asm not allowed in 'transaction_safe' function
#BAD
houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O1 -quiet -w
a.c: In function 'f':
a.c:7:3: error: asm not allowed in 'transaction_safe' function
houston:/build/t2/gcc$
With -O1, the TREE_BLOCK looks like this:
(gdb) ptg block
BLOCK #3
SUPERCONTEXT: BLOCK #0
ABSTRACT_ORIGIN: BLOCK #0
and the BLOCK_SUPERCONTEXT looks like this:
(gdb) ptg block
BLOCK #0
SUPERCONTEXT: f
SUBBLOCKS: BLOCK #3
Notice there is no BLOCK_ABSTRACT_ORIGIN in this last one, so we don't
print any context.
I would rather have a consistent error message (though possibly
confusing), than have an error message that sometimes makes sense.
To make matters worse, I have just noticed that at -O2 and -O3 we
inlined all the functions into main, so the GIMPLE_ASM ends up in the
transaction itself (see test), not in f(), so the compiler is able to
determine we have a GIMPLE_ASM inside a transaction and issues a
different error:
houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O2 -quiet -w
a.c:7:3: error: asm not allowed in atomic transaction
Here also we could've used the %K format modifier, if indeed we had full
backtrace information. But, like -O1, we don't.
I think I'm back to learning towards rth's suggestion of disabling early
inlining.
Thoughts?
Index: testsuite/gcc.dg/tm/pr52141.c
===
--- testsuite/gcc.dg/tm/pr52141.c (revision 0)
+++ testsuite/gcc.dg/tm/pr52141.c (revision 0)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options -fgnu-tm -O0 -w } */
+
+__attribute__((always_inline))
+static void asmfunc(void)
+{
+ __asm__ (); /* { dg-error asm not allowed in .transaction_safe } */
+}
+
+__attribute__((transaction_safe))
+static void f(void)
+{
+ asmfunc();
+}
+
+int main()
+{
+ __transaction_atomic {
+f();
+ }
+ return 0;
+}
+
+/* { dg-message inlined from \'f\' { target *-*-* } 0 } */
Index: trans-mem.c
===
--- trans-mem.c (revision 184272)
+++ trans-mem.c (working copy)
@@ -3736,6 +3736,13 @@ ipa_tm_scan_irr_block (basic_block bb)
assembly statement is not relevant to the transaction
is to wrap it in a __tm_waiver block. This is not
yet implemented, so we can't check for it. */
+ if (is_tm_safe (current_function_decl))
+ {
+ tree t = build1 (NOP_EXPR, void_type_node, size_zero_node);
+ SET_EXPR_LOCATION (t, gimple_location (stmt));
+ TREE_BLOCK (t) = gimple_block (stmt);
+ error (%Kasm not allowed in %transaction_safe% function, t);
+ }
return true;
default:
Re: [patch i386]: Fix for x64 windows targets the split of PCREL unspecs
On 02/16/2012 04:23 AM, Kai Tietz wrote: 2012-02-16 Kai Tietz kti...@redhat.com * config/i386/i386.c (legitimate_pic_address_disp_p): Allow interger-constant displacement for UNSPEC_PCREL. Ok. r~
Re: Go patch committed: Drop log2 and trunk
Ian Lance Taylor i...@google.com writes: Rainer Orth r...@cebitec.uni-bielefeld.de writes: The patch allowed the bootstrap to complete successfully, but since libgo.so now has undefined references to log2 and trunc, all Go execution still fail. I went ahead and removed the uses of the libc log2 and trunc functions, on the basis that although they are in C99 they are not in C89. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Thanks, that worked wonders for Solaris 9/SPARC results :-) (Solaris 8/SPARC bootstrap is currently broken for unrelated reasons.) We're now down to four testsuite failures in libgo: --- FAIL: math_test.TestLdexp (0.00 seconds) ???:1: Ldexp(-1, -1075) = 0, want -0 FAIL FAIL: math FAIL: time No hint why. --- FAIL: rand.TestRead (0.00 seconds) ???:1: Read(buf) = 1040, %!s(nil) FAIL FAIL: crypto/rand Before Solaris 11, reads from /dev/urandom are restricted to 1040 bytes. This always holds for /dev/random, but isn't documented in the Solaris 10 random(7D) manpage. On Solaris 11, I find: The limitation per read for /dev/random is 1040 bytes. The limit for /dev/urandom is (128 * 1040). and the change could be confirmed in the OpenSolaris sources. FAIL: net/http Again, no hint what's wrong. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[wwwdocs] Patch to svn.html describing new branch
Hello, I just created a new branch (and announced it on the gcc mailing list). This patch updates the web page docs to briefly describe the new branch. -- Caroline Tice cmt...@google.com ? my-patch.txt ? htdocs/svn.html.~1.168.~ Index: htdocs/svn.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v retrieving revision 1.168 diff -r1.168 svn.html 571a572,578 dtgoogle/gcc-emx_y[_z]/em-mobile/vtable-security/dt ddGoogle compilers based on GCC emx.y.z/em releases. These are used to build Android and ChromeOS. This branch is for work on function pointer and vtable security. It is maintained by Caroline Tice a href=mailto:cmt...@google.com;cmt...@google.com/a. /dd
Re: [wwwdocs] Patch to svn.html describing new branch
On 16/02/12 14:04 , Caroline Tice wrote: Hello, I just created a new branch (and announced it on the gcc mailing list). This patch updates the web page docs to briefly describe the new branch. The patch looks fine. When you have a more complete description for the project, could you add a link to it? Thanks. Diego.
Re: PR middle-end/52141: ICE due to asm statement
On 02/16/12 12:04, Jakub Jelinek wrote: On Thu, Feb 16, 2012 at 11:46:33AM -0600, Aldy Hernandez wrote: #GOOD houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O0 -quiet -w In function 'asmfunc', inlined from 'f' at a.c:13:10: a.c:7:3: error: asm not allowed in 'transaction_safe' function #BAD houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O1 -quiet -w a.c: In function 'f': a.c:7:3: error: asm not allowed in 'transaction_safe' function houston:/build/t2/gcc$ Even with -O1 -g ? With -g0 we prune BLOCKs, so the backtraces don't work well. Well with -O1 -g the backtrace works for this particular error. But with -O2 -g, we trigger another error asm not allowed in atomic transaction, and no amount of %K fiddling will get me a backtrace. But even so, it doesn't seem right to expect users to get a correct error message only with -g, does it?
Re: PR middle-end/52141: ICE due to asm statement
On Thu, Feb 16, 2012 at 11:46:33AM -0600, Aldy Hernandez wrote: #GOOD houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O0 -quiet -w In function 'asmfunc', inlined from 'f' at a.c:13:10: a.c:7:3: error: asm not allowed in 'transaction_safe' function #BAD houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O1 -quiet -w a.c: In function 'f': a.c:7:3: error: asm not allowed in 'transaction_safe' function houston:/build/t2/gcc$ Even with -O1 -g ? With -g0 we prune BLOCKs, so the backtraces don't work well. Jakub
Re: [v3] Disable gthreads on Solaris 8/9 (PR libstdc++/52189)
Hi Jon, On 15 February 2012 17:44, Rainer Orth wrote: Ok for mainline? Yes, although I would prefer the config option to be --enable-libstdcxx-gthreads or --enable-libstdcxx-threads, since I I'll go for the latter since the use of gthreads is just an implementation detail. prefer it to be clear that a config option relates just to libstdc++, and this only seems to affect libstdc++ not other libs such as libobjc which make use of gthreads. Agreed: I didn't really like the name anyway, since it didn't suggest much to the user. It might also be useful to improve the configure.xml description. Btw., the ChangeLog lies at one point: I didn't include the configure.html update since I lack the required tools. I'd appreciate it if some of the libstdc++ maintainers could handle this for me after checking. Sure, I can do that. Great, thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
C++ PATCH for c++/51415 (vec_init_expr not handled by dump_expr)
Lambda closure object initialization uses VEC_INIT_EXPR to express array
copy, which confused dump_expr. But there's no reason to print out the
details of that initialization at all; we should just say closure
object and be done with it.
Of course, this is another instance of problems with printing the
internal expression representation rather than the source form...
Tested x86_64-pc-linux-gnu, applied to trunk
commit 25a7d8c9be6a926081d2a0460984366fa49bbe22
Author: Jason Merrill ja...@redhat.com
Date: Thu Feb 16 10:28:57 2012 -0800
PR c++/51415
* error.c (dump_expr): Handle lambda closures specifically.
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 09c6cae..4ec263b 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -2189,6 +2189,8 @@ dump_expr (tree t, int flags)
}
}
}
+ if (TREE_TYPE (t) LAMBDA_TYPE_P (TREE_TYPE (t)))
+ pp_string (cxx_pp, lambda closure object);
if (TREE_TYPE (t) EMPTY_CONSTRUCTOR_P (t))
{
dump_type (TREE_TYPE (t), 0);
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-err1.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-err1.C
new file mode 100644
index 000..ebf0cbd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-err1.C
@@ -0,0 +1,8 @@
+// PR c++/51415
+// { dg-do compile { target c++11 } }
+
+void foo()
+{
+ int x[1];
+ [x]{} = 0; // { dg-error lambda closure }
+}
Re: Go patch committed: Drop log2 and trunk
Rainer Orth r...@cebitec.uni-bielefeld.de writes: FAIL: time No hint why. FAIL: net/http Again, no hint what's wrong. Sometimes it helps to run make GOTESTFLAGS=--keep time/check and then run LD_LIBRARY_PATH=.libs gotestN/a.out That will sometimes print something useful. It seems that some times test output is not captured in the log, but I haven't taken the time to figure out why. Ian
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
H.J. Lu hjl.to...@gmail.com writes: GNU assembler understands: .section.init_array* If Solaris assembler doesn't, I don't know how it will work with .init_array with priority. That's not the issue: merging .init_array* sections is handled all right by gld irrespective of sh_type; there's nothing required from the assembler here. My problem is different: consider $ cat ia-no-sht.s .section .init_array $ cat ia-no-sht-f.s .section .init_array,aw If I assemble this with gas 2.22, I get the same section header for both inputs: gas/ia-no-sht.o: Section Header[4]: sh_name: .init_array sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ] sh_size: 0 sh_type:[ SHT_INIT_ARRAY ] sh_offset:0x34sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 gas/ia-no-sht-f.o: Section Header[4]: sh_name: .init_array sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ] sh_size: 0 sh_type:[ SHT_INIT_ARRAY ] sh_offset:0x34sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 With as instead, I get as/ia-no-sht.o: Section Header[3]: sh_name: .init_array sh_addr: 0 sh_flags: 0 sh_size: 0 sh_type:[ SHT_PROGBITS ] sh_offset:0x59sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 as/ia-no-sht-f.o: Section Header[3]: sh_name: .init_array sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ] sh_size: 0 sh_type:[ SHT_PROGBITS ] sh_offset:0x59sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 The problem is not the wrong sh_type (SHT_PROGBITS instead of SHT_INIT_ARRAY): gld handles both input sections alike and doesn't care. Rather, the 0 sh_flags when no section flags are specified seem to cause gld to mishandle the resulting objects. So for gas, my patch makes no difference, but fixes/works around the problematic as/gld combo. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Go patch committed: Drop log2 and trunk
Ian Lance Taylor i...@google.com writes: Rainer Orth r...@cebitec.uni-bielefeld.de writes: FAIL: time No hint why. FAIL: net/http Again, no hint what's wrong. Sometimes it helps to run make GOTESTFLAGS=--keep time/check and then run LD_LIBRARY_PATH=.libs gotestN/a.out I know, and that would be my next step. I'm just juggling too many issues at the same time right now, so I'll postpone closer investigation a bit. That will sometimes print something useful. It seems that some times test output is not captured in the log, but I haven't taken the time to figure out why. True: this is even more of a problem for go.test testsuite. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[lra] add most common case to choose reg class for split pseudo
I found there are too many rejecting pseudo splits because I excluded
most common case of choosing register class for split pseudo.
The following patch fixes this.
Committed as rev. 184315.
2012-02-16 Vladimir Makarov vmaka...@redhat.com
* lra-constraints.c (choose_split_class): Check allocno_class too.
(split_pseudo): Print more debug info about split rejecting
because of reg class.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 184215)
+++ lra-constraints.c (working copy)
@@ -3810,6 +3810,9 @@ choose_split_class (enum reg_class alloc
enum reg_class cl, best_cl = NO_REGS;
enum reg_class hard_reg_class = REGNO_REG_CLASS (hard_regno);
+ if (! SECONDARY_MEMORY_NEEDED (allocno_class, allocno_class, mode)
+ TEST_HARD_REG_BIT (reg_class_contents[allocno_class], hard_regno))
+return allocno_class;
for (i = 0;
(cl = reg_class_subclasses[allocno_class][i]) != LIM_REG_CLASSES;
i++)
@@ -3881,8 +3884,13 @@ split_pseudo (bool before_p, int origina
if (lra_dump_file != NULL)
{
fprintf (lra_dump_file,
- Rejecting split of %d: no good reg class\n,
- original_regno);
+ Rejecting split of %d(%s):
+ no good reg class for %d(%s)\n,
+ original_regno,
+ reg_class_names[lra_get_allocno_class (original_regno)],
+ reg_renumber[original_regno],
+ reg_class_names[REGNO_REG_CLASS
+ (reg_renumber[original_regno])]);
fprintf (lra_dump_file,
\n);
}
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
Richard Guenther richard.guent...@gmail.com writes: I'm not sure about the varasm.c change - it's definitely not a no-op (callback will be not set, and the flags will be different). Certainly As I've demonstrated in my response to H.J., the effect with gas is none. the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY case, not sure why, but you don't make it consistent either because you don't change that case to SECTION_NOTYPE either. I'd be fine I didn't find a need for that, but agree that the inconsistency is disturbing. default_section_type_flags suggests that SECTION_NOTYPE should be set for .init_array and friends, but it's only used by get_named_section. with it with both calls using SECTION_NOTYPE, but would like to know what the callback difference is about. I don't think the callback is needed, which is effectively a printf (\t.section\t.init_array); Looking at it, this is e.g. wrong for Sun as on SPARC, which requires the section name to be in double quotes. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] increase timeout in simulate-thread gdb test
Andrew MacLeod amacl...@redhat.com writes:
On 02/09/2012 09:38 AM, Uros Bizjak wrote:
On Thu, Feb 9, 2012 at 3:12 PM, Aldy Hernandezal...@redhat.com wrote:
It was me, and the sole reason was that timeout didn't worked and the
log filled the file system. After timeout functionality was fixed, the
timeout was forced to 10 seconds. It is an arbitrary number.
I suspected as much. Long term I think we should remove the line by line
log info as the default.
Even with the 20-second timeout, I was seeing lots of failures on slower
machines, like sparc, alpha, or mips. I've had good success with the
following patch which uses the default dejagnu timeout instead of some
arbitrary value. It even takes into account users doubling the default
timeout (as I have to do on IRIX).
With this patch, all those FAILs on Solaris are gone, on IRIX only
FAIL: gcc.dg/simulate-thread/atomic-other-int.c -O0 -g thread simulation test
FAIL: gcc.dg/simulate-thread/atomic-other-int.c -O2 -g thread simulation test
FAIL: gcc.dg/simulate-thread/atomic-other-int.c -O3 -g thread simulation test
FAIL: gcc.dg/simulate-thread/atomic-other-short.c -O0 -g thread simulation
test
FAIL: gcc.dg/simulate-thread/atomic-other-short.c -O2 -g thread simulation
test
FAIL: gcc.dg/simulate-thread/atomic-other-short.c -O3 -g thread simulation
test
are left. Only on Tru64 UNIX do I still see lots of failures. I've to
investigate whether or not they are timeout-related.
Admittedly, it has the disadvantage of potentially filling the log files
if things go badly wrong.
What do you think?
Rainer
2012-02-10 Rainer Orth r...@cebitec.uni-bielefeld.de
PR target/51753
* lib/gcc-simulate-thread.exp: Load timeout.exp.
(simulate-thread): Use default timeout.
# HG changeset patch
# Parent 20c4f5db4968654fb36aa38d0800fbee28457be3
Increase simulate-thread timeout (PR target/51753)
diff --git a/gcc/testsuite/lib/gcc-simulate-thread.exp b/gcc/testsuite/lib/gcc-simulate-thread.exp
--- a/gcc/testsuite/lib/gcc-simulate-thread.exp
+++ b/gcc/testsuite/lib/gcc-simulate-thread.exp
@@ -1,4 +1,4 @@
-# Copyright (C) 2011 Free Software Foundation, Inc.
+# Copyright (C) 2011, 2012 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -14,6 +14,8 @@
# along with GCC; see the file COPYING3. If not see
# http://www.gnu.org/licenses/.
+load_lib timeout.exp
+
# Utility for running a given test through the simulate-thread harness
# using gdb. This is invoked via dg-final.
#
@@ -56,8 +58,7 @@ proc simulate-thread { args } {
set gdb_worked 0
-# Set timeout to 20 seconds due to huge amount of generated log.
-remote_expect target 20 {
+remote_expect target [timeout_value] {
# Too old GDB
-re Unhandled dwarf expression|Error in sourced command file {
unsupported $testcase $message
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] increase timeout in simulate-thread gdb test
On Feb 16, 2012, at 12:47 PM, Rainer Orth wrote: Even with the 20-second timeout, I was seeing lots of failures on slower machines, like sparc, alpha, or mips. I've had good success with the following patch which uses the default dejagnu timeout instead of some arbitrary value. It even takes into account users doubling the default timeout (as I have to do on IRIX). Ah, I like this version better than the 20... Let's give the simulate threads people a chance to veto this, if they want. If they don't want to, Ok.
[PATCH] Ignore gimple_clobber_p stmts in tail[cr] passes (PR tree-optimization/52285)
Hi!
We should IMHO ignore the clobber stmts when deciding if we can tail
call optimize or tail recurse.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-02-16 Jakub Jelinek ja...@redhat.com
PR tree-optimization/52285
* tree-tailcall.c (find_tail_calls): Ignore gimple_clobber_p stmts
when deciding if a call is a tail call or tail recursion.
--- gcc/tree-tailcall.c.jj 2011-06-17 11:02:19.0 +0200
+++ gcc/tree-tailcall.c 2012-02-16 19:33:49.468926680 +0100
@@ -400,9 +400,10 @@ find_tail_calls (basic_block bb, struct
{
stmt = gsi_stmt (gsi);
- /* Ignore labels, returns and debug stmts. */
+ /* Ignore labels, returns, clobbers and debug stmts. */
if (gimple_code (stmt) == GIMPLE_LABEL
|| gimple_code (stmt) == GIMPLE_RETURN
+ || gimple_clobber_p (stmt)
|| is_gimple_debug (stmt))
continue;
@@ -523,6 +524,9 @@ find_tail_calls (basic_block bb, struct
if (gimple_code (stmt) == GIMPLE_RETURN)
break;
+ if (gimple_clobber_p (stmt))
+ continue;
+
if (is_gimple_debug (stmt))
continue;
Jakub
[C++ Patch] for c++/52126
Hi,
templatetypename Tstruct A
{
int foo;
struct B : A { using A::foo; }; // (1)
struct C : AT { using A::foo; }; // (2)
};
There are two problems in this PR. Firstly, for (1) it seems to work,
but in reality the lookup for foo is not performed. Hence, I have
modified dfs_lookup_base so that (1) and (2) be treated equivalently.
For (2), the lookup was failing because the flag
BINFO_DEPENDENT_BASE_P was set. It think it should not be set for this
special case, however, I'm not sure I have unset it at the right
place. A slight tweak was also needed in lookup_field_r so that (1)
work correctly.
Tested x86_64-unknown-linux-gnu without regressions.
gcc/testsuite/ChangeLog
2012-02-16 Fabien Chêne fab...@gcc.gnu.org
* g++.dg/template/using21.C: New.
* g++.dg/template/using22.C: Likewise.
gcc/cp/ChangeLog
2012-02-16 Fabien Chêne fab...@gcc.gnu.org
* search.c (dfs_lookup_base): call TYPE_MAIN_VARIANT.
(lookup_field_r): Likewise.
* name-lookup.c (do_class_using_decl): Reset the flag
BINFO_DEPENDENT_BASE_P so that the call to lookup_member succeed.
--
Fabien
52126.patch
Description: Binary data
Re: [C++ Patch] for c++/52126
On 02/16/2012 01:47 PM, Fabien Chêne wrote: + tree binfo_type = TYPE_MAIN_VARIANT (BINFO_TYPE (binfo)); BINFO_TYPE should already be its TYPE_MAIN_VARIANT. Why isn't it here? For (2), the lookup was failing because the flag BINFO_DEPENDENT_BASE_P was set. It think it should not be set for this special case, however, I'm not sure I have unset it at the right place. I think we should avoid setting it in the first place, perhaps by changing dependent_type_p to dependent_scope_p in xref_basetypes. Jason
Re: [PATCH] increase timeout in simulate-thread gdb test
On 02/16/2012 04:32 PM, Mike Stump wrote: On Feb 16, 2012, at 12:47 PM, Rainer Orth wrote: Even with the 20-second timeout, I was seeing lots of failures on slower machines, like sparc, alpha, or mips. I've had good success with the following patch which uses the default dejagnu timeout instead of some arbitrary value. It even takes into account users doubling the default timeout (as I have to do on IRIX). Ah, I like this version better than the 20... Let's give the simulate threads people a chance to veto this, if they want. If they don't want to, Ok. Im fine with it, that was in fact the original intention. I'll look at what options may reduce the log size Andrew
Go patch committed: Lower constant string comparisons
This patch to the Go compiler lowers constant string comparisons at
compile time rather than runtime. Not doing this led to a compiler
crash on code like
var V = a b
because the compiler thinks that expressions involving only constants do
not require any runtime initialization, but string comparison requires a
function call. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 67d188db0c17 go/expressions.cc
--- a/go/expressions.cc Wed Feb 15 23:15:01 2012 -0800
+++ b/go/expressions.cc Thu Feb 16 13:50:38 2012 -0800
@@ -5824,15 +5824,46 @@
}
// String constant expressions.
- if (op == OPERATOR_PLUS
- left-type()-is_string_type()
- right-type()-is_string_type())
+ if (left-type()-is_string_type() right-type()-is_string_type())
{
std::string left_string;
std::string right_string;
if (left-string_constant_value(left_string)
right-string_constant_value(right_string))
- return Expression::make_string(left_string + right_string, location);
+ {
+ if (op == OPERATOR_PLUS)
+ return Expression::make_string(left_string + right_string,
+ location);
+ else if (is_comparison)
+ {
+ int cmp = left_string.compare(right_string);
+ bool r;
+ switch (op)
+ {
+ case OPERATOR_EQEQ:
+ r = cmp == 0;
+ break;
+ case OPERATOR_NOTEQ:
+ r = cmp != 0;
+ break;
+ case OPERATOR_LT:
+ r = cmp 0;
+ break;
+ case OPERATOR_LE:
+ r = cmp = 0;
+ break;
+ case OPERATOR_GT:
+ r = cmp 0;
+ break;
+ case OPERATOR_GE:
+ r = cmp = 0;
+ break;
+ default:
+ go_unreachable();
+ }
+ return Expression::make_boolean(r, location);
+ }
+ }
}
// Special case for shift of a floating point constant.
[RFC 4.8] use ip+cfa to identify unwind frames, if possible
On 02/16/2012 11:54 AM, Richard Henderson wrote:
I'll work on a proper fix to the unwinder; we can then decide
whether and when to apply it...
Something like this. Not the best of solutions, but we've run out
of bits in the exception structure, and thus we can't use this
solution universally.
It shouldn't matter for most CISC targets, like x86, which always
push the return address onto the stack; one never winds up with
the situation you saw on mips where the return address is held
only in a (special) register.
r~
diff --git a/gcc/config/alpha/alpha.h b/gcc/config/alpha/alpha.h
index 07ffa9f..77e1ee5 100644
--- a/gcc/config/alpha/alpha.h
+++ b/gcc/config/alpha/alpha.h
@@ -1290,3 +1290,8 @@ do {
\
/* The system headers under Alpha systems are generally C++-aware. */
#define NO_IMPLICIT_EXTERN_C
+
+/* Bits 0 and 1 are always zero in jump targets. */
+#ifdef IN_LIBGCC2
+# define UNWIND_FORCE_UNWIND_MASK 1
+#endif
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 1c19f8b..59d4560 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -2920,3 +2920,15 @@ extern GTY(()) struct target_globals *mips16_globals;
with arguments ARGS. */
#define PMODE_INSN(NAME, ARGS) \
(Pmode == SImode ? NAME ## _si ARGS : NAME ## _di ARGS)
+
+/* For mips32 mode we have bits 0 and 1 zero free, but for mips16 mode,
+ bit 0 indicates mips16 mode, and bit 1 is thence meaningful. Thus
+ the only free bits would be at the top of the address space.
+ Can we trust that we'll never try to unwind in kernel mode? */
+#ifdef IN_LIBGCC2
+# if TARGET_64BIT
+# define UNWIND_FORCE_UNWIND_MASK 0x8000ull
+# else
+# define UNWIND_FORCE_UNWIND_MASK 0x8000u
+# endif
+#endif
diff --git a/libgcc/unwind-sjlj.c b/libgcc/unwind-sjlj.c
index 1fc1c5d..4b32328 100644
--- a/libgcc/unwind-sjlj.c
+++ b/libgcc/unwind-sjlj.c
@@ -322,6 +322,9 @@ uw_identify_context (struct _Unwind_Context *context)
#define _Unwind_Resume _Unwind_SjLj_Resume
#define _Unwind_Resume_or_Rethrow _Unwind_SjLj_Resume_or_Rethrow
+/* Always use uw_identify_context to identify frames. */
+#undef UNWIND_FORCE_UNWIND_MASK
+
#include unwind.inc
#endif /* USING_SJLJ_EXCEPTIONS */
diff --git a/libgcc/unwind.inc b/libgcc/unwind.inc
index 5e2ec29..1374f9d 100644
--- a/libgcc/unwind.inc
+++ b/libgcc/unwind.inc
@@ -1,5 +1,5 @@
/* Exception handling and frame unwind runtime interface routines. -*- C -*-
- Copyright (C) 2001, 2003, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2001, 2003, 2008, 2009, 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -27,6 +27,64 @@
This file is included from unwind-dw2.c, unwind-sjlj.c or
unwind-ia64.c. */
+/* This is a bit value within a function pointer or function return address
+ that is never set. E.g. most RISC targets have instructions aligned to
+ four bytes, meaning bits 0 and 1 are free and thus either 1 or 2 would
+ be appropriate values to use here.
+
+ If non-zero, we will use this bit to distinguish forced unwind from normal
+ unwind, and in addition use both the IP+CFA to identify the target context
+ during unwinding.
+
+ If zero, i.e. there is no free bit, then we will only be able to use the
+ CFA to identify the target context during unwinding. The consequence of
+ this is that we cannot reliably propagate an exception through a sequence
+ of functions that do not have a stack frame. Normally this is not a
+ problem, in that most functions that do not have stack frames are leaf
+ functions, and thus do not throw exceptions. */
+
+#include stdbool.h
+
+#ifndef UNWIND_FORCE_UNWIND_MASK
+# define UNWIND_FORCE_UNWIND_MASK 0
+#endif
+
+static inline bool
+is_forced_unwind (struct _Unwind_Exception *exc)
+{
+ if (UNWIND_FORCE_UNWIND_MASK != 0)
+return (exc-private_1 UNWIND_FORCE_UNWIND_MASK) != 0;
+ else
+return exc-private_1 != 0;
+}
+
+static inline bool
+is_handler_match (struct _Unwind_Exception *exc,
+ struct _Unwind_Context *context)
+{
+ if (UNWIND_FORCE_UNWIND_MASK != 0)
+return (_Unwind_GetIP (context) == exc-private_1
+_Unwind_GetCFA (context) == exc-private_2);
+ else
+return uw_identify_context (context) == exc-private_2;
+}
+
+static inline void
+record_handler_match (struct _Unwind_Exception *exc,
+ struct _Unwind_Context *context)
+{
+ if (UNWIND_FORCE_UNWIND_MASK != 0)
+{
+ exc-private_1 = _Unwind_GetIP (context);
+ exc-private_2 = _Unwind_GetCFA (context);
+}
+ else
+{
+ exc-private_1 = 0;
+ exc-private_2 = uw_identify_context (context);
+}
+}
+
/* Subroutine of _Unwind_RaiseException also invoked from _Unwind_Resume.
Unwind the stack calling the personality routine to find both the
@@ -48,8 +106,7 @@ _Unwind_RaiseException_Phase2(struct _Unwind_Exception *exc,
code =
Re: [pph] Merge inline function definitions. (issue5677058)
With this patch, I'm getting: gcc/cp/pph-in.c: In function 'tree_node* pph_in_tree(pph_stream*)': gcc/cp/pph-in.c:1694:70: error: 'decl_declared_inline' may be used uninitialized in this function [-Werror=maybe-uninitialized]gcc/cp/pph-in.c:1644:8: note: 'decl_declared_inline' was declared here gcc/cp/pph-in.c:1683:75: error: 'decl_comdat_group' may be used uninitialized in this function [-Werror=maybe-uninitialized]gcc/cp/pph-in.c:1643:8: note: 'decl_comdat_group' was declared here gcc/cp/pph-in.c:1682:50: error: 'decl_comdat' may be used uninitialized in this function [-Werror=maybe-uninitialized]gcc/cp/pph-in.c:1642:8: note: 'decl_comdat' was declared here cc1plus: all warnings being treated as errors make: *** [cp/pph-in.o] Error 1 Could you take a look? Thanks. Diego.
Re: [PATCH] Ignore gimple_clobber_p stmts in tail[cr] passes (PR tree-optimization/52285)
On 02/16/2012 01:45 PM, Jakub Jelinek wrote: 2012-02-16 Jakub Jelinek ja...@redhat.com PR tree-optimization/52285 * tree-tailcall.c (find_tail_calls): Ignore gimple_clobber_p stmts when deciding if a call is a tail call or tail recursion. Ok. r~
Re: [C++ Patch] for c++/52126
2012/2/16 Jason Merrill ja...@redhat.com: On 02/16/2012 01:47 PM, Fabien Chêne wrote: + tree binfo_type = TYPE_MAIN_VARIANT (BINFO_TYPE (binfo)); BINFO_TYPE should already be its TYPE_MAIN_VARIANT. Why isn't it here? For (2), the lookup was failing because the flag BINFO_DEPENDENT_BASE_P was set. It think it should not be set for this special case, however, I'm not sure I have unset it at the right place. I think we should avoid setting it in the first place, perhaps by changing dependent_type_p to dependent_scope_p in xref_basetypes. Well, where it takes me ages to figure out what goes wrong and to fix it in the wrong way, it only takes you a few seconds... Never mind ;-) Your suggestion fixes the problem above with BINFOs as well, thank you ! complete regtest is running... OK to commit if it succeeds ? gcc/testsuite/ChangeLog 2012-02-16 Fabien Chêne fab...@gcc.gnu.org * g++.dg/template/using21.C: New. * g++.dg/template/using22.C: Likewise. gcc/cp/ChangeLog 2012-02-16 Fabien Chêne fab...@gcc.gnu.org * decl.c (xref_basetypes): call dependent_scope_p instead of dependent_type_p. -- Fabien 52126_2.patch Description: Binary data
Go patch committed: Don't crash on bad type descriptor
This patch to the Go frontend avoids crashing the compiler when an
erroneous program causes it to attempt to build a type descriptor for an
unnamed integer type, or other types that should never be unnamed.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 4b6a3ed61b80 go/types.cc
--- a/go/types.cc Thu Feb 16 14:08:43 2012 -0800
+++ b/go/types.cc Thu Feb 16 14:17:36 2012 -0800
@@ -2595,7 +2595,7 @@
Expression*
Integer_type::do_type_descriptor(Gogo* gogo, Named_type* name)
{
- go_assert(name != NULL);
+ go_assert(name != NULL || saw_errors());
return this-plain_type_descriptor(gogo, this-runtime_type_kind_, name);
}
@@ -2730,7 +2730,7 @@
Expression*
Float_type::do_type_descriptor(Gogo* gogo, Named_type* name)
{
- go_assert(name != NULL);
+ go_assert(name != NULL || saw_errors());
return this-plain_type_descriptor(gogo, this-runtime_type_kind_, name);
}
@@ -2857,7 +2857,7 @@
Expression*
Complex_type::do_type_descriptor(Gogo* gogo, Named_type* name)
{
- go_assert(name != NULL);
+ go_assert(name != NULL || saw_errors());
return this-plain_type_descriptor(gogo, this-runtime_type_kind_, name);
}
Re: [RFC 4.8] use ip+cfa to identify unwind frames, if possible
On 02/16/2012 02:12 PM, Richard Henderson wrote: [...] index 1c19f8b..59d4560 100644 --- a/gcc/config/mips/mips.h +++ b/gcc/config/mips/mips.h @@ -2920,3 +2920,15 @@ extern GTY(()) struct target_globals *mips16_globals; with arguments ARGS. */ #define PMODE_INSN(NAME, ARGS) \ (Pmode == SImode ? NAME ## _si ARGS : NAME ## _di ARGS) + +/* For mips32 mode we have bits 0 and 1 zero free, but for mips16 mode, + bit 0 indicates mips16 mode, and bit 1 is thence meaningful. Thus + the only free bits would be at the top of the address space. + Can we trust that we'll never try to unwind in kernel mode? */ That's too bad. I guess if we ever want to unwind in kernel mode, we can say no mips16 and switch it to a low-order bit for that application. Or write our own unwinder. David Daney
Re: [RFC 4.8] use ip+cfa to identify unwind frames, if possible
David Daney david.da...@cavium.com writes: On 02/16/2012 02:12 PM, Richard Henderson wrote: [...] Thanks for the patch. index 1c19f8b..59d4560 100644 --- a/gcc/config/mips/mips.h +++ b/gcc/config/mips/mips.h @@ -2920,3 +2920,15 @@ extern GTY(()) struct target_globals *mips16_globals; with arguments ARGS. */ #define PMODE_INSN(NAME, ARGS) \ (Pmode == SImode ? NAME ## _si ARGS : NAME ## _di ARGS) + +/* For mips32 mode we have bits 0 and 1 zero free, but for mips16 mode, + bit 0 indicates mips16 mode, and bit 1 is thence meaningful. Thus + the only free bits would be at the top of the address space. + Can we trust that we'll never try to unwind in kernel mode? */ That's too bad. I guess if we ever want to unwind in kernel mode, we can say no mips16 and switch it to a low-order bit for that application. Or write our own unwinder. I suppose the problem is that baremetal often runs in kernel mode. (Normal mips*-elf gdbsim testing works that way.) But I think we'd be fine if we restrict the IP matching to non-MIPS16 mode. GCC doesn't have any other special RA save registers, and now's a good time to say that such a thing won't be allowed in MIPS16 or microMIPS code (or in anything, probably). So maybe we could set private_1 to (IP | 2) when (IP 3) == 0, and leave it at 0 otherwise. It's then a forced unwind unless (IP 3) == 2. Not as elegant as the single bit though. Richard
Re: [pph] Merge inline function definitions. (issue5677058)
On 2/16/12, Diego Novillo dnovi...@google.com wrote:
With this patch, I'm getting:
gcc/cp/pph-in.c: In function 'tree_node* pph_in_tree(pph_stream*)':
gcc/cp/pph-in.c:1694:70: error: 'decl_declared_inline' may be used
uninitialized in this function
[-Werror=maybe-uninitialized]gcc/cp/pph-in.c:1644:8: note:
'decl_declared_inline' was declared here
gcc/cp/pph-in.c:1683:75: error: 'decl_comdat_group' may be used
uninitialized in this function
[-Werror=maybe-uninitialized]gcc/cp/pph-in.c:1643:8: note:
'decl_comdat_group' was declared here
gcc/cp/pph-in.c:1682:50: error: 'decl_comdat' may be used
uninitialized in this function
[-Werror=maybe-uninitialized]gcc/cp/pph-in.c:1642:8: note:
'decl_comdat' was declared here
cc1plus: all warnings being treated as errors
make: *** [cp/pph-in.o] Error 1
Could you take a look?
This patch avoids a false used unititalized error by assigning
values soon to be overwritten.
Tested on x64.
Index: gcc/cp/ChangeLog.pph
2012-02-16 Lawrence Crowl cr...@google.com
* pph-in.c (pph_in_merge_lang_indep_tree_body): Avoid a false used
uninitialized error message.
Index: gcc/cp/pph-in.c
===
--- gcc/cp/pph-in.c (revision 184290)
+++ gcc/cp/pph-in.c (working copy)
@@ -1639,10 +1639,10 @@ static void
pph_in_merge_lang_indep_tree_body (pph_stream *stream, tree expr)
{
enum tree_code code = TREE_CODE (expr);
- bool decl_comdat;
- tree decl_comdat_group;
- bool decl_declared_inline;
- tree decl_result;
+ bool decl_comdat = false;
+ tree decl_comdat_group = NULL;
+ bool decl_declared_inline = false;
+ tree decl_result = NULL;
if (CODE_CONTAINS_STRUCT (code, TS_DECL_WITH_VIS))
{
--
Lawrence Crowl
New German PO file for 'gcc' (version 4.7-b20120128)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/gcc/de.po (This file, 'gcc-4.7-b20120128.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [RFC 4.8] use ip+cfa to identify unwind frames, if possible
On Thu, 16 Feb 2012, Richard Henderson wrote: On 02/16/2012 11:54 AM, Richard Henderson wrote: I'll work on a proper fix to the unwinder; we can then decide whether and when to apply it... Something like this. Not the best of solutions, but we've run out of bits in the exception structure, and thus we can't use this solution universally. The new target macro UNWIND_FORCE_UNWIND_MASK in this patch * needs to be documented; * is only used in code in libgcc so should be in libgcc_tm.h via libgcc/config.host, not in the host-side gcc/config/ headers. (http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration lists existing target macros that have yet to be transitioned to libgcc_tm.h, though various parts of that page describe projects Rainer has now done.) -- Joseph S. Myers jos...@codesourcery.com
Re: [v3] Disable gthreads on Solaris 8/9 (PR libstdc++/52189)
On 16 February 2012 19:10, Rainer Orth wrote: Btw., the ChangeLog lies at one point: I didn't include the configure.html update since I lack the required tools. I'd appreciate it if some of the libstdc++ maintainers could handle this for me after checking. Sure, I can do that. Great, thanks. For the HTML docs, just check in without that bit in the ChangeLog. Regenerating the HTML changes almost every page because links between sections get randomly-generated anchor names, so I'll just do an update for doc/html/* once your change is checked in. (I've considered assigning a name to every section and sub-section in the docs so that the link anchors are fixed and repeatable and regenerating the html doesn't produce a huge diff ... but it's a lot of very tedious work so I haven't done it.)
Re: [C++ Patch] for c++/52126
OK. Jason
Re: [google/integration] Add support for powerpc64-grtev2-linux-gnu (issue5659050)
Hi Diego Ollie,
Could you guys take a look?
-Doug
On Mon, Feb 13, 2012 at 6:41 PM, Doug Kwan dougk...@google.com wrote:
Hi,
This patch adds support for powerpc*-grtev2-linux-gnu. The changes
include:
1. Relocating the dynamic linker using a run-time root prefix.
2. Using different library setting in static linking.
This is tested by building PowerPC64 and PowerPC toolchains and ran
some tests with the resulting toolchain.
This is used by Google and is not meant to be sent to trunk.
-Doug
2012-02-13 Doug Kwan dougk...@google.com
* gcc/config.gcc (powerpc*-*-linux): Pull in GRTEv2 spec changes if
target matches *-grtev2-*.
* gcc/config/rs6000/linux64.h (GLIB_DYNAMIC_LINKER{32,64}): Add
runtime root prefix to glibc's dynamic linker.
* gcc/config/rs6000/linux-grtev2.h: New file.
* gcc/config/rs6000/sysv4.h (GLIB_DYNAMIC_LINKER): Add
runtime root prefix to glibc's dynamic linker.
(LINUX_GRTE_EXTRA_SPECS): Define to be empty if no definition found.
(SUBTARGET_EXTRA_SPECS): Include LINUX_GRTE_EXTRA_SPECS.
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 184150)
+++ gcc/config.gcc (working copy)
@@ -2040,6 +2040,12 @@ powerpc-*-linux* | powerpc64-*-linux*)
if test x${enable_secureplt} = xyes; then
tm_file=rs6000/secureplt.h ${tm_file}
fi
+ # Pull in spec changes for GRTEv2 configurations.
+ case ${target} in
+ *-grtev2-*)
+ tm_file=${tm_file} rs6000/linux-grtev2.h
+ ;;
+ esac
;;
powerpc-wrs-vxworks|powerpc-wrs-vxworksae)
tm_file=${tm_file} elfos.h freebsd-spec.h rs6000/sysv4.h
Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 184150)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -367,8 +367,8 @@ extern int dot_symbols;
#undef LINK_OS_DEFAULT_SPEC
#define LINK_OS_DEFAULT_SPEC %(link_os_linux)
-#define GLIBC_DYNAMIC_LINKER32 /lib/ld.so.1
-#define GLIBC_DYNAMIC_LINKER64 /lib64/ld64.so.1
+#define GLIBC_DYNAMIC_LINKER32 RUNTIME_ROOT_PREFIX /lib/ld.so.1
+#define GLIBC_DYNAMIC_LINKER64 RUNTIME_ROOT_PREFIX /lib64/ld64.so.1
#define UCLIBC_DYNAMIC_LINKER32 /lib/ld-uClibc.so.0
#define UCLIBC_DYNAMIC_LINKER64 /lib/ld64-uClibc.so.0
#if DEFAULT_LIBC == LIBC_UCLIBC
Index: gcc/config/rs6000/linux-grtev2.h
===
--- gcc/config/rs6000/linux-grtev2.h (revision 0)
+++ gcc/config/rs6000/linux-grtev2.h (revision 0)
@@ -0,0 +1,43 @@
+/* Definitions for Linux-based GRTE (Google RunTime Environment) version 2.
+ Copyright (C) 2009,2010,2011,2012 Free Software Foundation, Inc.
+ Contributed by Chris Demetriou and Ollie Wild.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+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/. */
+
+/* Overrides LIB_LINUX_SPEC from sysv4.h. */
+#undef LIB_LINUX_SPEC
+#define LIB_LINUX_SPEC \
+ %{pthread:-lpthread} \
+ %{shared:-lc} \
+ %{!shared:%{mieee-fp:-lieee} %{profile:%(libc_p)}%{!profile:%(libc)}}
+
+/* When GRTE links statically, it needs its NSS and resolver libraries
+ linked in as well. Note that when linking statically, these are
+ enclosed in a group by LINK_GCC_C_SEQUENCE_SPEC. */
+#undef LINUX_GRTE_EXTRA_SPECS
+#define LINUX_GRTE_EXTRA_SPECS \
+ { libc, %{static:%(libc_static);:-lc} }, \
+ { libc_p, %{static:%(libc_p_static);:-lc_p} }, \
+ { libc_static, \
+ -lc -lnss_borg -lnss_cache -lnss_dns -lnss_files -lresolv }, \
+ { libc_p_static, \
+ -lc_p -lnss_borg_p -lnss_cache_p -lnss_dns_p -lnss_files_p -lresolv_p
},
Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h (revision 184150)
+++ gcc/config/rs6000/sysv4.h (working copy)
@@ -803,7 +803,10 @@ extern int fixuplabelno;
#define LINK_START_LINUX_SPEC
-#define GLIBC_DYNAMIC_LINKER /lib/ld.so.1
+#ifndef
Re: [PR52001] too many cse reverse equiv exprs (take2)
On Feb 15, 2012, Richard Sandiford rdsandif...@googlemail.com wrote:
I'm fine with putting it in and seeing what breaks. But I'd really
prefer if we knew in theory. :-)
Ok, I dove into the problem without a testcase, and I managed to trigger
it on other platforms after tweaking get_addr a bit so as use loc lists
form canonical values, and to avoid returning other VALUEs if other
alternatives exist.
Like I say, my understanding before this patch series went in was that
cselib values weren't supposed to be cyclic. Now that they are, what
should consumers like memrefs_conflict_p do to avoid getting stuck?
I'm now testing the following heuristic: only use an expr instead of a
value if the expr doesn't reference any value whose uid is greater than
that of the value. This worked for libgcc so far; regstrapping now.
Here's the revised patch that addresses Jakub's and your comments, that
regstrapped on x86_64-linux-gnu and i686-linux-gnu, followed by the
patch I'm testing now on both platforms.
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/52001
* cselib.c (preserve_only_constants): Rename to...
(preserve_constants_and_equivs): ... this. Split out...
(invariant_or_equiv_p): ... this. Preserve plus expressions
of other preserved expressions too.
(cselib_reset_table): Adjust.
* var-tracking.c (reverse_op): Use canonical value to build
reverse operation.
Index: gcc/cselib.c
===
--- gcc/cselib.c.orig 2012-02-12 06:13:40.676385499 -0200
+++ gcc/cselib.c 2012-02-15 00:40:46.0 -0200
@@ -383,22 +383,29 @@ cselib_clear_table (void)
cselib_reset_table (1);
}
-/* Remove from hash table all VALUEs except constants
- and function invariants. */
+/* Return TRUE if V is a constant, a function invariant or a VALUE
+ equivalence; FALSE otherwise. */
-static int
-preserve_only_constants (void **x, void *info ATTRIBUTE_UNUSED)
+static bool
+invariant_or_equiv_p (cselib_val *v)
{
- cselib_val *v = (cselib_val *)*x;
struct elt_loc_list *l;
+ if (v == cfa_base_preserved_val)
+return true;
+
+ /* Keep VALUE equivalences around. */
+ for (l = v-locs; l; l = l-next)
+if (GET_CODE (l-loc) == VALUE)
+ return true;
+
if (v-locs != NULL
v-locs-next == NULL)
{
if (CONSTANT_P (v-locs-loc)
(GET_CODE (v-locs-loc) != CONST
|| !references_value_p (v-locs-loc, 0)))
- return 1;
+ return true;
/* Although a debug expr may be bound to different expressions,
we can preserve it as if it was constant, to get unification
and proper merging within var-tracking. */
@@ -406,24 +413,29 @@ preserve_only_constants (void **x, void
|| GET_CODE (v-locs-loc) == DEBUG_IMPLICIT_PTR
|| GET_CODE (v-locs-loc) == ENTRY_VALUE
|| GET_CODE (v-locs-loc) == DEBUG_PARAMETER_REF)
- return 1;
- if (cfa_base_preserved_val)
- {
- if (v == cfa_base_preserved_val)
- return 1;
- if (GET_CODE (v-locs-loc) == PLUS
- CONST_INT_P (XEXP (v-locs-loc, 1))
- XEXP (v-locs-loc, 0) == cfa_base_preserved_val-val_rtx)
- return 1;
- }
+ return true;
+
+ /* (plus (value V) (const_int C)) is invariant iff V is invariant. */
+ if (GET_CODE (v-locs-loc) == PLUS
+ CONST_INT_P (XEXP (v-locs-loc, 1))
+ GET_CODE (XEXP (v-locs-loc, 0)) == VALUE
+ invariant_or_equiv_p (CSELIB_VAL_PTR (XEXP (v-locs-loc, 0
+ return true;
}
- /* Keep VALUE equivalences around. */
- for (l = v-locs; l; l = l-next)
-if (GET_CODE (l-loc) == VALUE)
- return 1;
+ return false;
+}
+
+/* Remove from hash table all VALUEs except constants, function
+ invariants and VALUE equivalences. */
+
+static int
+preserve_constants_and_equivs (void **x, void *info ATTRIBUTE_UNUSED)
+{
+ cselib_val *v = (cselib_val *)*x;
- htab_clear_slot (cselib_hash_table, x);
+ if (!invariant_or_equiv_p (v))
+htab_clear_slot (cselib_hash_table, x);
return 1;
}
@@ -463,7 +475,7 @@ cselib_reset_table (unsigned int num)
}
if (cselib_preserve_constants)
-htab_traverse (cselib_hash_table, preserve_only_constants, NULL);
+htab_traverse (cselib_hash_table, preserve_constants_and_equivs, NULL);
else
htab_empty (cselib_hash_table);
Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c.orig 2012-02-12 06:13:38.633412886 -0200
+++ gcc/var-tracking.c 2012-02-14 23:56:52.0 -0200
@@ -5334,6 +5334,10 @@ reverse_op (rtx val, const_rtx expr, rtx
if (!v || !cselib_preserved_value_p (v))
return;
+ /* Use canonical V to avoid creating multiple redundant expressions
+ for different VALUES equivalent to V. */
+ v = canonical_cselib_val (v);
+
/* Adding a reverse op isn't useful if V already has an always valid
location. Ignore ENTRY_VALUE, while it is always constant, we should
prefer non-ENTRY_VALUE locations whenever possible. */
for
