Re: RFA: New pass to delete unexecutable paths in the CFG
On 11/08/2011 09:24 PM, Jeff Law wrote: We don't have access to those assertions as they're removed well prior to this pass running. However, if we did, or if we had redundant PHIs in the stream which were propagated we'd be presented with something like BB0 if (p_1) goto BB1 else goto BB2 BB1: ... goto BB3 BB2: BB3: p_2 = phi (p_1 (BB1), 0(BB2)) *p_2 = 2; We'd recognize that the edge bb2->bb3 is unexecutable as doing so leads to a NULL pointer dereference. Since the edge bb2->bb3 is not a critical edge, we know that bb2 as a whole is unexecutable. bb2 is control dependent on the edge bb0->bb2. (Side note regarding critical edges: have you tried splitting them before your pass?) We would remove the edge bb0->bb2 and the control statement if (p_1) That makes BB2 unreachable resulting in BB0 goto BB1 BB1 ... BB3 p_2 = phi (p_1) *p_2 = 2; Which would then be optimized into BB0: ... *p_1 = 2; Which is exactly what I would expect the code to do with the knowledge that passing 0 to f results in undefined behaviour. Ok, so that's exactly what I was thinking about. In this case the optimization is obviously allowed by the C standard; you have if (p) something; *p = 0; and the "*p = 0" has been in some sense translated to if (!p) something; *p = 0; which is only different on undefined paths. But I'm not sure that more complicated cases, where there are other instructions between the "if" and "*p = 0", would also be allowed by the C standard. For example, I think a function call in the "else" branch, or between the PHI and the dereference should prevent the optimization, because the function call might never return for what we know. Probably a volatile asm too. Does your patch do that? (Testcases! :)). In general, this is quite different from all other existing GCC optimizations based on undefined behavior. Whenever you trigger undefined behavior, right now the effects do not extend *before* the undefined operation. The proposed pass would change that, so that its effects are a bit more surprising when debugging. If your bug is that you forgot a "return;" in the else branch, you surely wouldn't expect the compiler to swallow the entire branch. Unfortunately debugging at -O0 is not always an option. Paolo
Re: unordered associative containers are non-copyable in profile mode
On 9 November 2011 01:05, Jonathan Wakely wrote:
> On 9 November 2011 00:56, Paolo Carlini wrote:
>> On 11/09/2011 12:51 AM, Jonathan Wakely wrote:
>>>
>>> The obvious fix is simply to change the argument type, but is there a
>>> reason it's defined that way?
>>
>> Is there any reason for not having, for the time being at least, the same
>> set of constructors we have in debug-mode, thus add a proper
>> copy-constructor too?
>
> Ah, I didn't notice that's what the debug mode ones have. I think
> that makes sense.
Fixed like so:
* include/profile/unordered_map: Add missing copy constructors.
* include/profile/unordered_set: Likewise.
Tested x86_64-linux, committed to trunk
Index: include/profile/unordered_map
===
--- include/profile/unordered_map (revision 181195)
+++ include/profile/unordered_map (revision 181196)
@@ -96,6 +96,13 @@ namespace __profile
__profcxx_hashtable_construct2(this);
}
+ unordered_map(const unordered_map& __x)
+ : _Base(__x)
+ {
+__profcxx_hashtable_construct(this, _Base::bucket_count());
+__profcxx_hashtable_construct2(this);
+ }
+
unordered_map(const _Base& __x)
: _Base(__x)
{
@@ -365,6 +372,12 @@ namespace __profile
__profcxx_hashtable_construct(this, _Base::bucket_count());
}
+ unordered_multimap(const unordered_multimap& __x)
+ : _Base(__x)
+ {
+__profcxx_hashtable_construct(this, _Base::bucket_count());
+ }
+
unordered_multimap(const _Base& __x)
: _Base(__x)
{
Index: include/profile/unordered_set
===
--- include/profile/unordered_set (revision 181195)
+++ include/profile/unordered_set (revision 181196)
@@ -95,6 +95,13 @@ namespace __profile
__profcxx_hashtable_construct2(this);
}
+ unordered_set(const unordered_set& __x)
+ : _Base(__x)
+ {
+__profcxx_hashtable_construct(this, _Base::bucket_count());
+__profcxx_hashtable_construct2(this);
+ }
+
unordered_set(const _Base& __x)
: _Base(__x)
{
@@ -339,6 +346,12 @@ namespace __profile
__profcxx_hashtable_construct(this, _Base::bucket_count());
}
+ unordered_multiset(const unordered_multiset& __x)
+ : _Base(__x)
+ {
+__profcxx_hashtable_construct(this, _Base::bucket_count());
+ }
+
unordered_multiset(const _Base& __x)
: _Base(__x)
{
[PATCH] Fixup canonicalize_constructor_val some more
Make sure to mark decl addresses coming from constructors
as addressable (otherwise early folding fails for all java testcases).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-11-09 Richard Guenther
* gimple-fold.c (canonicalize_constructor_val): Mark
address-taken variables addressable.
Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c (revision 181173)
+++ gcc/gimple-fold.c (working copy)
@@ -137,9 +137,12 @@ canonicalize_constructor_val (tree cval)
|| TREE_CODE (base) == FUNCTION_DECL)
&& !can_refer_decl_in_current_unit_p (base))
return NULL_TREE;
- if (cfun && gimple_referenced_vars (cfun)
- && base && TREE_CODE (base) == VAR_DECL)
- add_referenced_var (base);
+ if (base && TREE_CODE (base) == VAR_DECL)
+ {
+ TREE_ADDRESSABLE (base) = 1;
+ if (cfun && gimple_referenced_vars (cfun))
+ add_referenced_var (base);
+ }
/* Fixup types in global initializers. */
if (TREE_TYPE (TREE_TYPE (cval)) != TREE_TYPE (TREE_OPERAND (cval, 0)))
cval = build_fold_addr_expr (TREE_OPERAND (cval, 0));
Re: vector garbaged collected while still in use
On Tue, Nov 8, 2011 at 6:10 PM, Xinliang David Li wrote: > Here is the revised patch. Bootstrap and regression tested on linux/x86-64. > > Honza, can you comment on the implication of this change? Jason also seems to have touched this again, so maybe it's already fixed? > thanks, > > David > > On Mon, Nov 7, 2011 at 2:09 PM, Richard Guenther > wrote: >> On Mon, Nov 7, 2011 at 5:41 PM, Xinliang David Li wrote: >>> Here is the stack trace when the watch point is hit (the watch point >>> is on address &cleanups->base.prefix.num >>> >>> David >>> >>> #0 memset () at ../sysdeps/x86_64/memset.S:336 >>> #1 0x00d1528d in poison_pages () at >>> /usr/local/google/davidxl/dev/gcc/tot/gcc/ggc-page.c:1983 >>> #2 0x00d15424 in ggc_collect () at >>> /usr/local/google/davidxl/dev/gcc/tot/gcc/ggc-page.c:2076 >>> #3 0x01028d7f in cgraph_finalize_function >>> (decl=0x7577d600, nested=0 '\000') at >>> /usr/local/google/davidxl/dev/gcc/tot/gcc/cgraphunit.c:376 >> >> Hm. We already conditionally arrange for cgraph_finalize_function to not >> call ggc_collect - so it seems that doing so is even less safe than >> originally >> thought. >> >> Which means I think we should push calling ggc_collect to the callers, >> which for the C++ frontend means ... >> >>> #4 0x00988010 in expand_or_defer_fn (fn=0x7577d600) at >>> /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/semantics.c:3797 >>> #5 0x00a678a7 in maybe_clone_body (fn=0x75770700) at >>> /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/optimize.c:426 >>> #6 0x00987aa3 in expand_or_defer_fn_1 (fn=0x75770700) at >>> /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/semantics.c:3722 >>> #7 0x00987fe0 in expand_or_defer_fn (fn=0x75770700) at >>> /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/semantics.c:3792 >>> #8 0x0091c5f5 in synthesize_method (fndecl=0x75770700) at >>> /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/method.c:773 >>> #9 0x00551fa0 in cp_finish_decl (decl=0x75770700, >>> init=0x76d8f898, init_const_expr_p=0 '\000', asmspec_tree=0x0, >>> flags=11) at /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/decl.c:6286 >> >> ... probably here. Though I'd also approve a patch that simply removes >> the ggc_collect call (and the nested parameter). Honza - you probably >> added the ggc_collect - what's the reason to do it in this lowlevel place? >> >> Thanks, >> Richard. >> >
Re: [Patch, Fortran, OOP] PR 50960: vtables not marked as constant
2011/11/8 Tobias Burnus : >> I am asking the question :-) Are the two equivalent? To my mind, it >> is a matter of taste, if they are. > > I think in practice they are the same. Alright, since no one seems to have any strong preference, I'll just go ahead and commit my version of the patch (as approved by Paul). Cheers, Janus
Re: [PATCH] Improve VEC_BASE
On Tue, Nov 8, 2011 at 8:35 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/07/11 15:53, Richard Guenther wrote: >> On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek >> wrote: >>> Hi! >>> >>> This patch attempts to optimize VEC_BASE if we know that offsetof >>> of base is 0 (unless the compiler is doing something strange, it >>> is true). It doesn't have a clear code size effect, some .text >>> sections grew, supposedly because of more inlining, some .text >>> sections shrunk. >>> >>> Bootstrapped/regtested on x86_64-linux and i686-linux. >> >> I wonder why the compiler doesn't optimize this ... certainly it >> looks backward to, in >> >> : if (c_2(D) != 0B) goto ; else goto ; >> >> : D.2948_3 = &c_2(D)->fld; goto ; >> >> : D.2948_4 = 0B; >> >> : # D.2948_1 = PHI return D.2948_1; >> >> see that D.2948_4 is equal to D.2948_3 for c_2 == 0, so I'm not >> sure which pass would be able to detect this (but the optimziation >> opportunity would be on the PHI node, so maybe it should be done in >> phiopt). > Right, I see that now. > > But D2948_3 doesn't flow through block #4, thus we can't use its value > for the PHI arg associated with the edge 4->5. So even with the > equivalency I think to optimize this we'd have to detect the > construct as a whole and collapse it into &c_2->fld. > > Presumably that's what your patch in a later message does. Yes. It collapses it into c_2. As pointer type differences are no longer important in the GIMPLE IL we can represent &c_2->fld simply as c_2 and thus with copy propagation we'd present phiopt with something it already handles. Unfortunately rewriting all &c_2->fld style expressions simply as c_2 plays foul with _FORTIFY_SOURCE and object size computation (where it makes a difference which field at offset zero you access ...). So instead of canonicalizing address computations using ADDR_EXPR to POINTER_PLUS_EXPR in general for 4.7 the only thing we can do is special case the above case in phiopt (which is probably worthwhile - that pattern ought to be quite common). Richard. > jeff > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOuYRuAAoJEBRtltQi2kC7E2YH/1ayeLWX3GoOnq5u+JxpyWkx > Fh/Dnar+Ad2jJJMrbx7vUUhAH54OEUDTWKYMQOn8ThUTnMmQtgb4uNqdyO78RfyM > BIVzzpTjD3Ud1+xxlzg8YCjvBw/NekRp9l4HiZpwwRIfTQRpKhWZ+oWe3bBgs+4B > LCVQWA9I5cGBhv09u7OOsYhicuAUa1Tj/XNF4NWE1GVsjilj+ESvZUj5Zd7dvxft > QzGh0fNn+RB9LVu6kktvU5CCX/sVBjVDnTaOP14zYGAEMFrWYjanE0n9+b6cVf9W > degmRowfMzOLvphsWEPFVZCTJPuDfkLlc5k6X3MkgpEFwQu6uo2S/k8vd98PAr8= > =vcgh > -END PGP SIGNATURE- >
Re: PowerPC shrink-wrap support 3 of 3
> From: Alan Modra
> Date: Tue, 1 Nov 2011 16:33:40 +0100
> On Tue, Nov 01, 2011 at 12:57:22AM +1030, Alan Modra wrote:
> * function.c (bb_active_p): Delete.
> (dup_block_and_redirect, active_insn_between): New functions.
> (convert_jumps_to_returns, emit_return_for_exit): New functions,
> split out from..
> (thread_prologue_and_epilogue_insns): ..here. Delete
> shadowing variables. Don't do prologue register clobber tests
> when shrink wrapping already failed. Delete all last_bb_active
> code. Instead compute tail block candidates for duplicating
> exit path. Remove these from antic set. Duplicate tails when
> reached from both blocks needing a prologue/epilogue and
> blocks not needing such.
> * ifcvt.c (dead_or_predicable): Test both flag_shrink_wrap and
> HAVE_simple_return.
> * bb-reorder.c (get_uncond_jump_length): Make global.
> * bb-reorder.h (get_uncond_jump_length): Declare.
> * cfgrtl.c (rtl_create_basic_block): Comment typo fix.
> (rtl_split_edge): Likewise. Warning fix.
> (rtl_duplicate_bb): New function.
> (rtl_cfg_hooks): Enable can_duplicate_block_p and duplicate_block.
This (a revision in the range 181187:181189) broke build for
cris-elf like so:
libtool: compile: /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-shared-libgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc -nostdinc++
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/src
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/src/.libs
-nostdinc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include
-I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/../libgcc
-I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf
-I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include
-I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=new_opv.lo -g -O2 -c
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/new_opv.cc -o new_opv.o
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/new_opv.cc: In function 'void*
operator new [](std::size_t)':
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/new_opv.cc:34:1: error: missing
REG_EH_REGION note in the end of bb 2
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/new_opv.cc:34:1: error: call
edges for non-call insn in bb 2
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/new_opv.cc:34:1: error: in
basic block 2:
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/new_opv.cc:34:1: error: flow
control insn inside a basic block
(call_insn 8 6 50 2 (parallel [
(set (reg:SI 10 r10)
(call (mem:QI (symbol_ref:SI ("_Znwm") [flags 0x41]
) [0 operator new S1 A8])
(const_int 0 [0])))
(clobber (reg:SI 16 srp))
]) /tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/new_opv.cc:33 222
{*expanded_call_value_non_v32}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil))
(expr_list:REG_UNUSED (use (reg:SI 10 r10))
(nil)))
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/new_opv.cc:34:1: internal
compiler error: in rtl_verify_flow_info_1, at cfgrtl.c:2001
See PR51051.
brgds, H-P
Re: RFA: New pass to delete unexecutable paths in the CFG
On Tue, Nov 8, 2011 at 8:47 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/07/11 15:25, Richard Guenther wrote: >> >> Indeed. We'd have to tell people that they cannot catch *(void *)0 >> = 0 with a SIGSEGV signal handler unless they compile with some >> magic flag. Thus, the question is whether we want to optimize >> things in a way that are non-obvious to people viewing things from >> a POSIX point of view rather than a C standard conforming issue. > Agreed. The path I'd started going down was a flag like > "-fassume-null-dereference-faults-and-is-uncatchable" or something > like that. -fdelete-null-pointer-checks would be subsumed by the new > flag. > > >> >> >> But what we could do by default is transform such stores to a trap >> representation, or at least making the feeding stmts dead by >> changing the stored value and the address to a constant (thus, even >> preserve the trap kind). fold_stmt could change the stored value >> if the address is literal zero, and all passes that know it is zero >> should propagate it anyway. That wouldn't remove the outgoing edge >> from the store of course, cfgcleanup could be teached to do that >> though (and we could invent a trap kind argument to >> __builtin_trap). > More correctly, we'd wipe the path from the control edge to the *0 > statement and remove the out edges from the block with the *0. Then > just leave the *0 or a __builtin_trap. > > We'd leave the control edge itself leading to the *0/trap. That > allows us to get most of the space savings optimization as well as > most of the secondary benefits. The programmer could still catch the > trapping signal. > > That doesn't work in the case of the implied dereference via NULL PHI > arg. For that case we'd have to copy the block with the PHI, the > incoming edges would be partitioned into those implying a null > dereference vs those not implying a null dereference. Effectively > this isolates the path with the implied NULL dereference and turns it > into an explicit NULL dereference and we could optimize as noted above. Hm, indeed. > So the question is do we want to proceed with any of this work? If so > I can update the patch, if not I'll go back to my warning work :-) I think we do want to continue with this work - probably not removing the faulting dereference though. I'd say we add a noreturn __builtin_nullptr_deref () in place of it (eventually doing the path isolation you mentioned above) and warn about the ones that survive until RTL expansion (where we'd just expand it as *0 = 0). In fact, the warning part of it might be the most useful piece for our users ;) Thanks, Richard.
Re: [fortran, patch] Add DREAL simplification (last remaining elemental required for initialization expressions)
> PS: Any chance of wrapping the long line to less than 80 characters? Committed as rev. 181198, with the long line in intrinsic.c wrapped. Thanks for reviewing, FX
Re: [Patch, Fortran, OOP] PR 50960: vtables not marked as constant
> Alright, since no one seems to have any strong preference, I'll just > go ahead and commit my version of the patch (as approved by Paul). Committed as r181199. Thanks for the comments, everyone! Cheers, Janus
Re: PING 1 [Patch Ada RFA] make sure that multilibs are built with correct s-oscons.ads
* Iain Sandoe, 2011-11-07 : > Subject: PING 1 [Patch Ada RFA] make sure that multilibs are built with > correct s-oscons.ads Patch looks fine to me. -- Thomas Quinot, Ph.D. ** qui...@adacore.com ** Senior Software Engineer AdaCore -- Paris, France -- New York, USA
Re: [fortran, patches] Two short patches to review
> Although I suspect you've been lurking in the background, > welcome back to the land of gfortran hacking. Your first > screw up is free, additional screw ups require you to > fix your screw up and fix an additional bug as your reward. Attached patch committed as revision 181200. FX convert.diff Description: Binary data
Re: PING 1 [Patch Ada RFA] make sure that multilibs are built with correct s-oscons.ads
> * Iain Sandoe, 2011-11-07 : > > > Subject: PING 1 [Patch Ada RFA] make sure that multilibs are built with > > correct s-oscons.ads > > Patch looks fine to me. It's an official 'OK' then.
[PATCH][RFC] Inline functions even with mismatching argument/return types
When we transform an indirect to a direct call or when, with LTO,
two incompatible function declarations are merged, we can end up
with call statements that use calling conventions according to
a different function type than the type of the actual function
being called. Currently we try to make sure not to inline the
call in such cases (because we'd ICE when trying to match up
types for the GIMPLE checkers) - but given the recent amount of
(ice-on-invalid) bugs I wonder whether this isn't too fragile
(one original idea was of course that maybe details of the ABI
make the code work in practice if not inlined, for example
passing a double instead of a v2df in an xmm register on x86_64,
but when inlined the program (with undefined behavior) would
behave erratically).
Thus, the following patch simply makes sure to always create
something that is valid GIMPLE. For return type mismatches
we can simply fallback to a ref-all memory read, for parameters
(which are not always lvalues) we expand the existing handling
to avoid generating invalid register VIEW_CONVERT_EXPRs by
using a literal zero arg.
In both cases we apply promotion/demotion as we do not have
properly matched up types between caller/callee in GIMPLE
(ugh, yeah ...).
So, I'm going to bootstrap and test this, which will also
fix PR51039 (but I have another fix for that in testing as well).
Any comments? A final patch would remove all callers of
the now pointless gimple_check_call_matching_types function
and eventually remove gimple_call_cannot_inline_p and friends
if it turns out to be unused.
Thanks,
Richard.
2011-11-09 Richard Guenther
PR tree-optimization/51039
* gimple-low.c (gimple_check_call_args): Remove.
(gimple_check_call_matching_types): Always return true.
* tree-inline.c (setup_one_parameter): Always perform a
valid gimple type change.
(declare_return_variable): Likewise.
Index: gcc/gimple-low.c
===
*** gcc/gimple-low.c(revision 181196)
--- gcc/gimple-low.c(working copy)
*** struct gimple_opt_pass pass_lower_cf =
*** 208,298
};
-
- /* Verify if the type of the argument matches that of the function
-declaration. If we cannot verify this or there is a mismatch,
-return false. */
-
- static bool
- gimple_check_call_args (gimple stmt, tree fndecl)
- {
- tree parms, p;
- unsigned int i, nargs;
-
- /* Calls to internal functions always match their signature. */
- if (gimple_call_internal_p (stmt))
- return true;
-
- nargs = gimple_call_num_args (stmt);
-
- /* Get argument types for verification. */
- if (fndecl)
- parms = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
- else
- parms = TYPE_ARG_TYPES (gimple_call_fntype (stmt));
-
- /* Verify if the type of the argument matches that of the function
- declaration. If we cannot verify this or there is a mismatch,
- return false. */
- if (fndecl && DECL_ARGUMENTS (fndecl))
- {
- for (i = 0, p = DECL_ARGUMENTS (fndecl);
- i < nargs;
- i++, p = DECL_CHAIN (p))
- {
- /* We cannot distinguish a varargs function from the case
-of excess parameters, still deferring the inlining decision
-to the callee is possible. */
- if (!p)
- break;
- if (p == error_mark_node
- || gimple_call_arg (stmt, i) == error_mark_node
- || !fold_convertible_p (DECL_ARG_TYPE (p),
- gimple_call_arg (stmt, i)))
- return false;
- }
- }
- else if (parms)
- {
- for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
- {
- /* If this is a varargs function defer inlining decision
-to callee. */
- if (!p)
- break;
- if (TREE_VALUE (p) == error_mark_node
- || gimple_call_arg (stmt, i) == error_mark_node
- || TREE_CODE (TREE_VALUE (p)) == VOID_TYPE
- || !fold_convertible_p (TREE_VALUE (p),
- gimple_call_arg (stmt, i)))
- return false;
- }
- }
- else
- {
- if (nargs != 0)
- return false;
- }
- return true;
- }
-
/* Verify if the type of the argument and lhs of CALL_STMT matches
that of the function declaration CALLEE.
If we cannot verify this or there is a mismatch, return false. */
bool
! gimple_check_call_matching_types (gimple call_stmt, tree callee)
{
- tree lhs;
-
- if ((DECL_RESULT (callee)
-&& !DECL_BY_REFERENCE (DECL_RESULT (callee))
-&& (lhs = gimple_call_lhs (call_stmt)) != NULL_TREE
-&& !useless_type_conversion_p (TREE_TYPE (DECL_RESULT (callee)),
- TREE_TYPE (lhs))
-&& !fold_convertible_p (TREE_TYPE (DECL_RESULT (callee)), lhs))
- || !gimple_check_call_args (call_st
[PATCH] Fix PR51039
This fixes PR51039 - another case of mismatches with respect to
gimple_call_cannot_inline_p and gimple_check_call_matching_types.
The code in ipa-inline-analysis.c looks out-of-place and it doesn't
check for a conservative setting - thus the patch removes the
code and instead adds verification code to the gimple checker.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Thanks,
Richard.
2011-11-09 Richard Guenther
PR tree-optimization/51039
* tree-cfg.c (verify_gimple_call): Verify that
gimple_call_cannot_inline_p is returning a conservative
correct result according to gimple_check_call_matching_types.
* ipa-inline-analysis.c (estimate_function_body_sizes): Remove
code dealing with un-inlinablility.
* gcc.dg/pr51039.c: New testcase.
Index: gcc/tree-cfg.c
===
*** gcc/tree-cfg.c (revision 181196)
--- gcc/tree-cfg.c (working copy)
*** verify_gimple_call (gimple stmt)
*** 3227,3232
--- 3300,3315
}
}
+ /* Verify that if we have a direct call and the argument/return
+ types have mismatches the call is properly marked as noninlinable. */
+ if (fndecl
+ && !gimple_call_cannot_inline_p (stmt)
+ && !gimple_check_call_matching_types (stmt, fndecl))
+ {
+ error ("gimple call cannot be inlined but is not marked so");
+ return true;
+ }
+
return false;
}
Index: gcc/ipa-inline-analysis.c
===
*** gcc/ipa-inline-analysis.c (revision 181196)
--- gcc/ipa-inline-analysis.c (working copy)
*** estimate_function_body_sizes (struct cgr
*** 1961,1980
es->call_stmt_time = this_time;
es->loop_depth = bb->loop_depth;
edge_set_predicate (edge, &bb_predicate);
-
- /* Do not inline calls where we cannot triviall work around
-mismatches in argument or return types. */
- if (edge->callee
- && cgraph_function_or_thunk_node (edge->callee, NULL)
- && !gimple_check_call_matching_types
- (stmt, cgraph_function_or_thunk_node (edge->callee,
- NULL)->decl))
- {
- edge->call_stmt_cannot_inline_p = true;
- gimple_call_set_cannot_inline (stmt, true);
- }
- else
- gcc_assert (!gimple_call_cannot_inline_p (stmt));
}
/* TODO: When conditional jump or swithc is known to be constant, but
--- 1961,1966
Index: gcc/testsuite/gcc.dg/pr51039.c
===
*** gcc/testsuite/gcc.dg/pr51039.c (revision 0)
--- gcc/testsuite/gcc.dg/pr51039.c (revision 0)
***
*** 0
--- 1,17
+ /* { dg-do compile } */
+ /* { dg-options "-O -finline-small-functions -fno-ipa-pure-const" } */
+
+ float baz (void)
+ {
+ return 0;
+ }
+
+ static inline int bar (int (*ibaz) (void))
+ {
+ return ibaz ();
+ }
+
+ void foo (void)
+ {
+ bar((int (*)(void))baz);
+ }
Re: ifcvt cond_exec support rewrite
Ping^2. Better support for nested if-then-else structures: > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01935.html > > > Bernd >
[C++ Patch] PR 51045
Hi,
apparently, in my -Wzero-as-null-pointer-constant I forgot to check the
NE_EXPR we are synthesizing upon new and delete, thus these spurious
warnings (I beefed up the original testcase to exercise the vector case
too). The fix seems largely obvious, just use nullptr_node more, but I
would ask you the courtesy to pay a particular attention to the second
hunk below: close to the integer_zero_node I'm touching, there are a
couple of other integer_zero_node...
Tested x86_64-linux.
Thanks,
Paolo.
PS: I'm taking the occasion to also add the new warning to the C++
summary in the docs. PPS: I think Jon has a similar patch already posted
on the ml.
//
/cp
2011-11-09 Paolo Carlini
PR c++/51045
* init.c (build_new_1, build_vec_delete_1, build_delete):
Use nullptr_node.
/testsuite
2011-11-09 Paolo Carlini
PR c++/51045
* g++.dg/warn/Wzero-as-null-pointer-constant-2.C: New.
2011-11-09 Paolo Carlini
* doc/invoke.texi ([Option Summary, C++ Language Options]):
Add -Wzero-as-null-pointer-constant.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 181201)
+++ doc/invoke.texi (working copy)
@@ -200,7 +200,7 @@ in the following sections.
-Weffc++ -Wstrict-null-sentinel @gol
-Wno-non-template-friend -Wold-style-cast @gol
-Woverloaded-virtual -Wno-pmf-conversions @gol
--Wsign-promo}
+-Wsign-promo -Wzero-as-null-pointer-constant}
@item Objective-C and Objective-C++ Language Options
@xref{Objective-C and Objective-C++ Dialect Options,,Options Controlling
Index: testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-2.C
===
--- testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-2.C(revision 0)
+++ testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-2.C(revision 0)
@@ -0,0 +1,49 @@
+// PR c++/51045
+// { dg-options "-Wzero-as-null-pointer-constant" }
+
+template
+struct A
+{
+ A() { t = new T; }
+
+ ~A()
+ {
+delete t;
+ }
+ T* t;
+};
+
+template
+struct B
+{
+ B() { t = new T[1]; }
+
+ ~B()
+ {
+delete [] t;
+ }
+ T* t;
+};
+
+template
+class Variant
+{
+ Type t;
+};
+
+class Op;
+
+typedef Variant > vara;
+typedef Variant > varb;
+
+class Op
+{
+ vara x;
+ varb y;
+};
+
+int main()
+{
+ vara a;
+ varb b;
+}
Index: cp/init.c
===
--- cp/init.c (revision 181201)
+++ cp/init.c (working copy)
@@ -2646,7 +2646,7 @@ build_new_1 (VEC(tree,gc) **placement, tree type,
{
tree ifexp = cp_build_binary_op (input_location,
NE_EXPR, alloc_node,
- integer_zero_node,
+ nullptr_node,
complain);
rval = build_conditional_expr (ifexp, rval, alloc_node,
complain);
@@ -2958,7 +2958,7 @@ build_vec_delete_1 (tree base, tree maxindex, tree
fold_build2_loc (input_location,
NE_EXPR, boolean_type_node, base,
convert (TREE_TYPE (base),
- integer_zero_node)),
+ nullptr_node)),
body, integer_zero_node);
body = build1 (NOP_EXPR, void_type_node, body);
@@ -3685,7 +3685,7 @@ build_delete (tree type, tree addr, special_functi
{
/* Handle deleting a null pointer. */
ifexp = fold (cp_build_binary_op (input_location,
- NE_EXPR, addr, integer_zero_node,
+ NE_EXPR, addr, nullptr_node,
complain));
if (ifexp == error_mark_node)
return error_mark_node;
Re: [PATCH][RFC] Inline functions even with mismatching argument/return types
On Wed, 9 Nov 2011, Richard Guenther wrote:
>
> When we transform an indirect to a direct call or when, with LTO,
> two incompatible function declarations are merged, we can end up
> with call statements that use calling conventions according to
> a different function type than the type of the actual function
> being called. Currently we try to make sure not to inline the
> call in such cases (because we'd ICE when trying to match up
> types for the GIMPLE checkers) - but given the recent amount of
> (ice-on-invalid) bugs I wonder whether this isn't too fragile
> (one original idea was of course that maybe details of the ABI
> make the code work in practice if not inlined, for example
> passing a double instead of a v2df in an xmm register on x86_64,
> but when inlined the program (with undefined behavior) would
> behave erratically).
>
> Thus, the following patch simply makes sure to always create
> something that is valid GIMPLE. For return type mismatches
> we can simply fallback to a ref-all memory read, for parameters
> (which are not always lvalues) we expand the existing handling
> to avoid generating invalid register VIEW_CONVERT_EXPRs by
> using a literal zero arg.
>
> In both cases we apply promotion/demotion as we do not have
> properly matched up types between caller/callee in GIMPLE
> (ugh, yeah ...).
>
> So, I'm going to bootstrap and test this, which will also
> fix PR51039 (but I have another fix for that in testing as well).
>
> Any comments? A final patch would remove all callers of
> the now pointless gimple_check_call_matching_types function
> and eventually remove gimple_call_cannot_inline_p and friends
> if it turns out to be unused.
I have bootstrapped and tested the patch successfully but will hold
the gimple_check_call_args change for now. I have applied the
tree-inline.c changes as those will make sure we do not ICE when
we fail to properly not inline mismatching calls.
Richard.
> Thanks,
> Richard.
>
> 2011-11-09 Richard Guenther
>
> PR tree-optimization/51039
> * gimple-low.c (gimple_check_call_args): Remove.
> (gimple_check_call_matching_types): Always return true.
> * tree-inline.c (setup_one_parameter): Always perform a
> valid gimple type change.
> (declare_return_variable): Likewise.
>
> Index: gcc/gimple-low.c
> ===
> *** gcc/gimple-low.c (revision 181196)
> --- gcc/gimple-low.c (working copy)
> *** struct gimple_opt_pass pass_lower_cf =
> *** 208,298
> };
>
>
> -
> - /* Verify if the type of the argument matches that of the function
> -declaration. If we cannot verify this or there is a mismatch,
> -return false. */
> -
> - static bool
> - gimple_check_call_args (gimple stmt, tree fndecl)
> - {
> - tree parms, p;
> - unsigned int i, nargs;
> -
> - /* Calls to internal functions always match their signature. */
> - if (gimple_call_internal_p (stmt))
> - return true;
> -
> - nargs = gimple_call_num_args (stmt);
> -
> - /* Get argument types for verification. */
> - if (fndecl)
> - parms = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
> - else
> - parms = TYPE_ARG_TYPES (gimple_call_fntype (stmt));
> -
> - /* Verify if the type of the argument matches that of the function
> - declaration. If we cannot verify this or there is a mismatch,
> - return false. */
> - if (fndecl && DECL_ARGUMENTS (fndecl))
> - {
> - for (i = 0, p = DECL_ARGUMENTS (fndecl);
> -i < nargs;
> -i++, p = DECL_CHAIN (p))
> - {
> - /* We cannot distinguish a varargs function from the case
> - of excess parameters, still deferring the inlining decision
> - to the callee is possible. */
> - if (!p)
> - break;
> - if (p == error_mark_node
> - || gimple_call_arg (stmt, i) == error_mark_node
> - || !fold_convertible_p (DECL_ARG_TYPE (p),
> - gimple_call_arg (stmt, i)))
> - return false;
> - }
> - }
> - else if (parms)
> - {
> - for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
> - {
> - /* If this is a varargs function defer inlining decision
> - to callee. */
> - if (!p)
> - break;
> - if (TREE_VALUE (p) == error_mark_node
> - || gimple_call_arg (stmt, i) == error_mark_node
> - || TREE_CODE (TREE_VALUE (p)) == VOID_TYPE
> - || !fold_convertible_p (TREE_VALUE (p),
> - gimple_call_arg (stmt, i)))
> - return false;
> - }
> - }
> - else
> - {
> - if (nargs != 0)
> - return false;
> - }
> - return true;
> - }
> -
> /* Verify if the type of the argument and lhs of CALL_STMT matches
> that of the function declaration CALLEE.
> If we cannot verify this or there is a mismatch, return false. */
>
Re: [PATCH] Fix PR51039
On Wed, 9 Nov 2011, Richard Guenther wrote:
>
> This fixes PR51039 - another case of mismatches with respect to
> gimple_call_cannot_inline_p and gimple_check_call_matching_types.
> The code in ipa-inline-analysis.c looks out-of-place and it doesn't
> check for a conservative setting - thus the patch removes the
> code and instead adds verification code to the gimple checker.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
This is what I ended up applying.
Richard.
2011-11-09 Richard Guenther
PR tree-optimization/51039
* tree-cfg.c (verify_gimple_call): Verify that
gimple_call_cannot_inline_p is returning a conservative
correct result according to gimple_check_call_matching_types.
* ipa-inline-analysis.c (estimate_function_body_sizes): Remove
code dealing with un-inlinablility.
* gimple-streamer-in.c (input_gimple_stmt): Update the
non-inlinable flag.
* gcc.dg/pr51039.c: New testcase.
Index: gcc/tree-cfg.c
===
*** gcc/tree-cfg.c (revision 181196)
--- gcc/tree-cfg.c (working copy)
*** verify_gimple_call (gimple stmt)
*** 3227,3232
--- 3300,3315
}
}
+ /* Verify that if we have a direct call and the argument/return
+ types have mismatches the call is properly marked as noninlinable. */
+ if (fndecl
+ && !gimple_call_cannot_inline_p (stmt)
+ && !gimple_check_call_matching_types (stmt, fndecl))
+ {
+ error ("gimple call cannot be inlined but is not marked so");
+ return true;
+ }
+
return false;
}
Index: gcc/ipa-inline-analysis.c
===
*** gcc/ipa-inline-analysis.c (revision 181196)
--- gcc/ipa-inline-analysis.c (working copy)
*** estimate_function_body_sizes (struct cgr
*** 1961,1980
es->call_stmt_time = this_time;
es->loop_depth = bb->loop_depth;
edge_set_predicate (edge, &bb_predicate);
-
- /* Do not inline calls where we cannot triviall work around
-mismatches in argument or return types. */
- if (edge->callee
- && cgraph_function_or_thunk_node (edge->callee, NULL)
- && !gimple_check_call_matching_types
- (stmt, cgraph_function_or_thunk_node (edge->callee,
- NULL)->decl))
- {
- edge->call_stmt_cannot_inline_p = true;
- gimple_call_set_cannot_inline (stmt, true);
- }
- else
- gcc_assert (!gimple_call_cannot_inline_p (stmt));
}
/* TODO: When conditional jump or swithc is known to be constant, but
--- 1961,1966
Index: gcc/testsuite/gcc.dg/pr51039.c
===
*** gcc/testsuite/gcc.dg/pr51039.c (revision 0)
--- gcc/testsuite/gcc.dg/pr51039.c (revision 0)
***
*** 0
--- 1,17
+ /* { dg-do compile } */
+ /* { dg-options "-O -finline-small-functions -fno-ipa-pure-const" } */
+
+ float baz (void)
+ {
+ return 0;
+ }
+
+ static inline int bar (int (*ibaz) (void))
+ {
+ return ibaz ();
+ }
+
+ void foo (void)
+ {
+ bar((int (*)(void))baz);
+ }
Index: gcc/gimple-streamer-in.c
===
*** gcc/gimple-streamer-in.c(revision 181196)
--- gcc/gimple-streamer-in.c(working copy)
*** input_gimple_stmt (struct lto_input_bloc
*** 219,229
--- 219,236
}
if (is_gimple_call (stmt))
{
+ tree fndecl;
if (gimple_call_internal_p (stmt))
gimple_call_set_internal_fn
(stmt, streamer_read_enum (ib, internal_fn, IFN_LAST));
else
gimple_call_set_fntype (stmt, stream_read_tree (ib, data_in));
+ /* Update the non-inlinable flag conservatively. */
+ fndecl = gimple_call_fndecl (stmt);
+ if (fndecl
+ && !gimple_call_cannot_inline_p (stmt)
+ && !gimple_check_call_matching_types (stmt, fndecl))
+ gimple_call_set_cannot_inline (stmt, true);
}
break;
Re: RFT: Fix PR middle/end-40154
> I'm regtesting the patch on SH, though currently many C++ tests fail > on SH with > > undefined reference to `std::atomic_thread_fence(std::memory_order)'. There are no new failures with the patch + reverting 148018 workaround on sh4-unknown-linux-gnu. Regards, kaz
[C++ Patch] PR 51047
Hi,
looks like one of the usual cases of 'complain' not propagated enough,
in this case, from finish_class_member_access_expr to lookup_member.
Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2011-11-09 Paolo Carlini
PR c++/51047
* search.c (lookup_member): Change to take also a tsubst_flags_t
parameter.
(lookup_field, lookup_fnfields): Adjust calls.
* typeck.c (lookup_destructor, finish_class_member_access_expr,
build_ptrmemfunc_access_expr): Likewise.
* class.c (handle_using_decl, maybe_note_name_used_in_class):
Likewise.
* pt.c (resolve_typename_type): Likewise.
* semantics.c (lambda_function): Likewise.
* parser.c (cp_parser_perform_range_for_lookup,
cp_parser_lookup_name): Likewise.
* friend.c (make_friend_class): Likewise.
* name-lookup.c (pushdecl_maybe_friend_1, get_class_binding,
do_class_using_decl, lookup_qualified_name): Likewise.
* cp-tree.h (lookup_member): Adjust declaration.
/testsuite
2011-11-09 Paolo Carlini
PR c++/51047
* g++.dg/cpp0x/sfinae29.C: New.
Index: testsuite/g++.dg/cpp0x/sfinae29.C
===
--- testsuite/g++.dg/cpp0x/sfinae29.C (revision 0)
+++ testsuite/g++.dg/cpp0x/sfinae29.C (revision 0)
@@ -0,0 +1,17 @@
+// PR c++/51047
+// { dg-options -std=c++0x }
+
+template T &&declval();
+template decltype(declval().x) f(T *);
+template char f(T);
+struct B1{ int x; };
+struct B2{ int x; };
+struct D : public B1, B2{};
+struct S { int x; };
+int main()
+{
+ S *p = nullptr;
+ static_assert(sizeof(f(p)) == sizeof(int), "");
+ D *q = nullptr;
+ static_assert(sizeof(f(q)) == 1u, "");
+}
Index: cp/typeck.c
===
--- cp/typeck.c (revision 181205)
+++ cp/typeck.c (working copy)
@@ -2397,7 +2397,8 @@ lookup_destructor (tree object, tree scope, tree d
return error_mark_node;
}
expr = lookup_member (dtor_type, complete_dtor_identifier,
- /*protect=*/1, /*want_type=*/false);
+ /*protect=*/1, /*want_type=*/false,
+ tf_warning_or_error);
expr = (adjust_result_of_qualified_name_lookup
(expr, dtor_type, object_type));
return expr;
@@ -2607,7 +2608,7 @@ finish_class_member_access_expr (tree object, tree
{
/* Look up the member. */
member = lookup_member (access_path, name, /*protect=*/1,
- /*want_type=*/false);
+ /*want_type=*/false, complain);
if (member == NULL_TREE)
{
if (complain & tf_error)
@@ -2681,7 +2682,7 @@ build_ptrmemfunc_access_expr (tree ptrmem, tree me
ptrmem_type = TREE_TYPE (ptrmem);
gcc_assert (TYPE_PTRMEMFUNC_P (ptrmem_type));
member = lookup_member (ptrmem_type, member_name, /*protect=*/0,
- /*want_type=*/false);
+ /*want_type=*/false, tf_warning_or_error);
member_type = cp_build_qualified_type (TREE_TYPE (member),
cp_type_quals (ptrmem_type));
return fold_build3_loc (input_location,
Index: cp/class.c
===
--- cp/class.c (revision 181205)
+++ cp/class.c (working copy)
@@ -1167,7 +1167,8 @@ handle_using_decl (tree using_decl, tree t)
gcc_assert (!processing_template_decl && decl);
- old_value = lookup_member (t, name, /*protect=*/0, /*want_type=*/false);
+ old_value = lookup_member (t, name, /*protect=*/0, /*want_type=*/false,
+tf_warning_or_error);
if (old_value)
{
if (is_overloaded_fn (old_value))
@@ -7290,7 +7291,7 @@ maybe_note_name_used_in_class (tree name, tree dec
/* If there's already a binding for this NAME, then we don't have
anything to worry about. */
if (lookup_member (current_class_type, name,
-/*protect=*/0, /*want_type=*/false))
+/*protect=*/0, /*want_type=*/false, tf_warning_or_error))
return;
if (!current_class_stack[current_class_depth - 1].names_used)
Index: cp/pt.c
===
--- cp/pt.c (revision 181205)
+++ cp/pt.c (working copy)
@@ -19861,7 +19861,8 @@ resolve_typename_type (tree type, bool only_curren
longer be considered a dependent type. */
pushed_scope = push_scope (scope);
/* Look up the declaration. */
- decl = lookup_member (scope, name, /*protect=*/0, /*want_type=*/true);
+ decl = lookup_member (scope, name, /*protect=*/0, /*want_type=*/true,
+ tf_warning_or_error);
result = NULL_TREE;
Index: cp/semantics.c
===
--- cp/semantics.c (revision 181205)
+++ cp/semantics.c (w
Re: [trans-mem] fix memopt-1.c for 32bits
On 11/08/2011 05:25 PM, Richard Henderson wrote:
On 11/08/2011 02:08 PM, Patrick Marlier wrote:
- change the match for g to _ITM_RU[48]
Change the match to [248].
I have never seen a "long" type to have a size of 2 bytes but I am
probably wrong. (I did not find the C specification but I found on many
website that long should be at least 4 bytes (32 bits)).
Patrick.
(Please commit if ok)
* gcc.dg/tm/memopt-1.c: Adjust regexp.
Index: gcc/testsuite/gcc.dg/tm/memopt-1.c
===
--- gcc/testsuite/gcc.dg/tm/memopt-1.c (revision 181178)
+++ gcc/testsuite/gcc.dg/tm/memopt-1.c (working copy)
@@ -22,7 +22,7 @@
}
}
-/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_RaWU8 \\(&g\\);" 1
"tmmemopt" } } */
+/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_RaWU[248]
\\(&g\\);" 1 "tmmemopt" } } */
/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_WaRU4 \\(&i," 1
"tmmemopt" } } */
/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_RaWU4 \\(&i\\);" 1
"tmmemopt" } } */
/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_WaWU4 \\(&i," 1
"tmmemopt" } } */
Re: [PATCH] Fix PR51039
On Wed, 9 Nov 2011, Richard Guenther wrote: > On Wed, 9 Nov 2011, Richard Guenther wrote: > > > > > This fixes PR51039 - another case of mismatches with respect to > > gimple_call_cannot_inline_p and gimple_check_call_matching_types. > > The code in ipa-inline-analysis.c looks out-of-place and it doesn't > > check for a conservative setting - thus the patch removes the > > code and instead adds verification code to the gimple checker. > > > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > This is what I ended up applying. > > Richard. > > 2011-11-09 Richard Guenther > > PR tree-optimization/51039 > * tree-cfg.c (verify_gimple_call): Verify that > gimple_call_cannot_inline_p is returning a conservative > correct result according to gimple_check_call_matching_types. I have reverted the tree-cfg.c pieces - they seem to break bootstrap with Ada for me (no idea how I didn't notice that when testing the patch - I'm suspecting an unreverted patch that folded all statements during gimplification). Richard.
[PATCH] Fix combine's simplify_comparison (PR rtl-optimization/51023)
Hi!
This patch essentially reverts part of Bernd's 2011-07-06 changes,
which was IMHO wrong. As const_op here is a constant in wider mode than
MODE (which is the inner mode of the SIGN_EXTEND), the old code
(and what this patch is restoring) didn't check just that the sign bit
is clear, but also that all bits above the sign bit of MODE are clear too.
I've used GET_MODE_PRECISION instead of GET_MODE_BITSIZE (as changed
in many other places around that date) and HWI_COMPUTABLE_MODE_P macro.
Additionally, if GET_MODE_CLASS (mode) == MODE_INT, we know
mode != VOIDmode, there is no point testing it (but the compiler will
likely not know it, as GET_MODE_CLASS is reading from an array).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
BTW, the
@@ -6546,10 +6551,8 @@ simplify_set (rtx x)
enum machine_mode inner_mode = GET_MODE (inner);
/* Here we make sure that we don't have a sign bit on. */
- if (GET_MODE_BITSIZE (inner_mode) <= HOST_BITS_PER_WIDE_INT
- && (nonzero_bits (inner, inner_mode)
- < ((unsigned HOST_WIDE_INT) 1
-<< (GET_MODE_BITSIZE (GET_MODE (src)) - 1
+ if (val_signbit_known_clear_p (GET_MODE (src),
+nonzero_bits (inner, inner_mode)))
{
SUBST (SET_SRC (x), inner);
src = SET_SRC (x);
hunk from the same patch might have the same problem (can't nonzero_bits
be wider than the mode of src there?), but I don't have a testcase for that.
Can you please double check that?
2011-11-09 Jakub Jelinek
PR rtl-optimization/51023
* combine.c (simplify_comparison) : Don't use
val_signbit_known_clear_p for signed comparison narrowing
optimization. Don't check for non-VOIDmode, use
HWI_COMPUTABLE_MODE_P macro.
: Don't check for non-VOIDmode.
* gcc.c-torture/execute/pr51023.c: New test.
--- gcc/combine.c.jj2011-11-08 23:35:12.0 +0100
+++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
@@ -11397,9 +11397,12 @@ simplify_comparison (enum rtx_code code,
later on, and then we wouldn't know whether to sign- or
zero-extend. */
mode = GET_MODE (XEXP (op0, 0));
- if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
+ if (GET_MODE_CLASS (mode) == MODE_INT
&& ! unsigned_comparison_p
- && val_signbit_known_clear_p (mode, const_op)
+ && HWI_COMPUTABLE_MODE_P (mode)
+ && ((unsigned HOST_WIDE_INT) const_op
+ < (((unsigned HOST_WIDE_INT) 1
+ << (GET_MODE_PRECISION (mode) - 1
&& have_insn_for (COMPARE, mode))
{
op0 = XEXP (op0, 0);
@@ -11477,7 +11480,7 @@ simplify_comparison (enum rtx_code code,
case ZERO_EXTEND:
mode = GET_MODE (XEXP (op0, 0));
- if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
+ if (GET_MODE_CLASS (mode) == MODE_INT
&& (unsigned_comparison_p || equality_comparison_p)
&& HWI_COMPUTABLE_MODE_P (mode)
&& ((unsigned HOST_WIDE_INT) const_op < GET_MODE_MASK (mode))
--- gcc/testsuite/gcc.c-torture/execute/pr51023.c.jj2011-11-09
10:17:31.133406427 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr51023.c 2011-11-09
10:17:13.0 +0100
@@ -0,0 +1,18 @@
+/* PR rtl-optimization/51023 */
+
+extern void abort (void);
+
+short int
+foo (long int x)
+{
+ return x;
+}
+
+int
+main ()
+{
+ long int a = 0x4272AL;
+ if (foo (a) == a)
+abort ();
+ return 0;
+}
Jakub
[Patch] PR 51061
Hi,
reportedly, the patchlet which plugged the memory leak reported in
PR36819 can cause problems when heads[QUOTE] or tails[QUOTE]. Thus I'm
finishing testing the below. Really, if we have reasons to believe that
the issue is much more complex than this, I guess we can also revert
PR36819, -I- itself is deprecated, so..
Thanks,
Paolo.
/
2011-11-09 Paolo Carlini
PR preprocessor/51061
* incpath.c (merge_include_chains): Make sure to not pass null
pointers to free_path.
Index: incpath.c
===
--- incpath.c (revision 181201)
+++ incpath.c (working copy)
@@ -362,8 +362,10 @@ merge_include_chains (const char *sysroot, cpp_rea
void
split_quote_chain (void)
{
- free_path (heads[QUOTE], REASON_QUIET);
- free_path (tails[QUOTE], REASON_QUIET);
+ if (heads[QUOTE])
+free_path (heads[QUOTE], REASON_QUIET);
+ if (tails[QUOTE])
+free_path (tails[QUOTE], REASON_QUIET);
heads[QUOTE] = heads[BRACKET];
tails[QUOTE] = tails[BRACKET];
heads[BRACKET] = NULL;
Re: [PATCH] Fix combine's simplify_comparison (PR rtl-optimization/51023)
On 11/09/11 16:32, Jakub Jelinek wrote:
> --- gcc/combine.c.jj 2011-11-08 23:35:12.0 +0100
> +++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
> @@ -11397,9 +11397,12 @@ simplify_comparison (enum rtx_code code,
>later on, and then we wouldn't know whether to sign- or
>zero-extend. */
> mode = GET_MODE (XEXP (op0, 0));
> - if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
> + if (GET_MODE_CLASS (mode) == MODE_INT
> && ! unsigned_comparison_p
> - && val_signbit_known_clear_p (mode, const_op)
> + && HWI_COMPUTABLE_MODE_P (mode)
> + && ((unsigned HOST_WIDE_INT) const_op
> + < (((unsigned HOST_WIDE_INT) 1
> + << (GET_MODE_PRECISION (mode) - 1
> && have_insn_for (COMPARE, mode))
> {
> op0 = XEXP (op0, 0);
I guess this is OK, although it would still be nicer to use something
with a descriptive name rather than bit-fiddling, to avoid this kind of
confusion. Maybe check whether trunc_int_for_mode doesn't change the
constant? Or we could make val_signbit_known_clear_p do more extensive
checking.
Bernd
Re: Disable libitm if unsupported
Hi Richard,
On 8 Nov 2011, at 21:29, Richard Henderson wrote:
On 11/08/2011 01:20 PM, Iain Sandoe wrote:
is it expected for libitm to work on x86 darwin?
Yes.
hmmm...
powerpc-darwin is not affected (doesn't auto configure because there's
no powerpc directory under libitm/config).
However ...
On i686-darwin9 it fails with "target only supports weak alias"
(I need to understand better where that comes from - but the machine
is tied up right now).
On x86_64-darwin10 it fails to build sjlj.S because that file makes
use of assembler constructs not available on the system as
(I think Rainer perhaps already observed this for some solaris
versions).
I had a quick look at config/x86/target.h and observe that the jmpbuf
layout in that header is different from the system definition...
.. so I'm thinking that maybe some porting work is needed ...
Unless I've missed sth ...
/bin/sh ./libtool --tag=CXX --mode=compile -B/GCC/gcc-4-7-
install/i686-apple-darwin9/bin/ -B/GCC/gcc-4-7-install/i686-apple-
darwin9/lib/ -isystem /GCC/gcc-4-7-install/i686-apple-darwin9/
include -isystem /GCC/gcc-4-7-install/i686-apple-darwin9/sys-
include-DHAVE_CONFIG_H -I. -I/GCC/gcc-live-trunk/libitm -I/GCC/
gcc-live-trunk/libitm/config/posix -I/GCC/gcc-live-trunk/libitm/
config/generic -I/GCC/gcc-live-trunk/libitm -std=gnu++0x -funwind-
tables -fno-exceptions -fno-rtti -march=i486 -mtune=i686 -fomit-
frame-pointer -Wall -Werror -Wc,-pthread -fabi-version=4 -g -O2 -
MT cacheline.lo -MD -MP -MF .deps/cacheline.Tpo -c -o cacheline.lo /
GCC/gcc-live-trunk/libitm/config/generic/cacheline.cc
libtool: compile: unrecognized option `-B/GCC/gcc-4-7-install/i686-
apple-darwin9/bin/'
libtool: compile: Try `libtool --help' for more information.
make[3]: *** [barrier.lo] Error 1
That's ... odd.
Top-level makefile has passed down the empty string instead of the g+
+ executable.
I have zero idea how to fix this. It sounds similar to the horror
that I eventually
bypassed wrt the include paths.
this happens when, in an attempt to debug things, one deletes the
failed build and tries to do
make all-target-libitm.
so .. perhaps we should disable darwin for now so that at least it
bootstraps ... unless this is only affecting me :-)
cheers
Iain
Index: libitm/configure.tgt
===
--- libitm/configure.tgt(revision 181206)
+++ libitm/configure.tgt(working copy)
@@ -93,10 +93,14 @@ case "${target}" in
*-*-gnu* | *-*-k*bsd*-gnu \
| *-*-netbsd* | *-*-freebsd* | *-*-openbsd* \
| *-*-solaris2* | *-*-sysv4* | *-*-irix6* | *-*-osf* | *-*-hpux11* \
- | *-*-darwin* | *-*-aix*)
+ | *-*-aix*)
# POSIX system. The OS is supported.
;;
+ *-*-darwin*) # POSIX, but needs some work.
+ UNSUPPORTED=1
+ ;;
+
*) # Non-POSIX, or embedded system
UNSUPPORTED=1
;;
Re: [PATCH] Fix combine's simplify_comparison (PR rtl-optimization/51023)
On Wed, Nov 09, 2011 at 04:44:55PM +0100, Bernd Schmidt wrote:
> On 11/09/11 16:32, Jakub Jelinek wrote:
> > --- gcc/combine.c.jj2011-11-08 23:35:12.0 +0100
> > +++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
> > @@ -11397,9 +11397,12 @@ simplify_comparison (enum rtx_code code,
> > later on, and then we wouldn't know whether to sign- or
> > zero-extend. */
> > mode = GET_MODE (XEXP (op0, 0));
> > - if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
> > + if (GET_MODE_CLASS (mode) == MODE_INT
> > && ! unsigned_comparison_p
> > - && val_signbit_known_clear_p (mode, const_op)
> > + && HWI_COMPUTABLE_MODE_P (mode)
> > + && ((unsigned HOST_WIDE_INT) const_op
> > + < (((unsigned HOST_WIDE_INT) 1
> > + << (GET_MODE_PRECISION (mode) - 1
> > && have_insn_for (COMPARE, mode))
> > {
> > op0 = XEXP (op0, 0);
>
> I guess this is OK, although it would still be nicer to use something
> with a descriptive name rather than bit-fiddling, to avoid this kind of
> confusion. Maybe check whether trunc_int_for_mode doesn't change the
> constant? Or we could make val_signbit_known_clear_p do more extensive
> checking.
Do you think this is more readable?
That matches what the old code did, though I wonder if the c >= 0
test is needed there at all and if simply
&& trunc_int_for_mode (const_op, mode) == const_op
couldn't be used and handle also negative constants - the comparison
is signed and the other operand is sign extended...
2011-11-09 Jakub Jelinek
PR rtl-optimization/51023
* combine.c (simplify_comparison) : Don't use
val_signbit_known_clear_p for signed comparison narrowing
optimization. Don't check for non-VOIDmode, use
HWI_COMPUTABLE_MODE_P macro.
: Don't check for non-VOIDmode.
* gcc.c-torture/execute/pr51023.c: New test.
--- gcc/combine.c.jj2011-11-08 23:35:12.0 +0100
+++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
@@ -11397,13 +11397,20 @@ simplify_comparison (enum rtx_code code,
later on, and then we wouldn't know whether to sign- or
zero-extend. */
mode = GET_MODE (XEXP (op0, 0));
- if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
+ if (GET_MODE_CLASS (mode) == MODE_INT
&& ! unsigned_comparison_p
- && val_signbit_known_clear_p (mode, const_op)
- && have_insn_for (COMPARE, mode))
+ && HWI_COMPUTABLE_MODE_P (mode))
{
- op0 = XEXP (op0, 0);
- continue;
+ HOST_WIDE_INT c = trunc_int_for_mode (const_op, mode);
+ /* Don't do this if the sign bit of MODE or any
+higher bit is set in CONST_OP. */
+ if (c == const_op
+ && c >= 0
+ && have_insn_for (COMPARE, mode))
+ {
+ op0 = XEXP (op0, 0);
+ continue;
+ }
}
break;
@@ -11477,7 +11484,7 @@ simplify_comparison (enum rtx_code code,
case ZERO_EXTEND:
mode = GET_MODE (XEXP (op0, 0));
- if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
+ if (GET_MODE_CLASS (mode) == MODE_INT
&& (unsigned_comparison_p || equality_comparison_p)
&& HWI_COMPUTABLE_MODE_P (mode)
&& ((unsigned HOST_WIDE_INT) const_op < GET_MODE_MASK (mode))
--- gcc/testsuite/gcc.c-torture/execute/pr51023.c.jj2011-11-09
10:17:31.133406427 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr51023.c 2011-11-09
10:17:13.0 +0100
@@ -0,0 +1,18 @@
+/* PR rtl-optimization/51023 */
+
+extern void abort (void);
+
+short int
+foo (long int x)
+{
+ return x;
+}
+
+int
+main ()
+{
+ long int a = 0x4272AL;
+ if (foo (a) == a)
+abort ();
+ return 0;
+}
Jakub
Re: [PATCH] More improvements to sparc VIS vec_init code generation.
> Eric, the testsuite target tests for vis2 and vi3 capable hardware > work well in my own testing but if you find some problem with how > it's done just let me know and I'll try to fix it up. There are many failures in 64-bit mode with VIS1 because of the use of the high part to expand vec_init, both in vector_init_move_words: case V2SImode: emit_move_insn (gen_highpart (SImode, target), XVECEXP (vals, 0, 0)); emit_move_insn (gen_lowpart (SImode, target), XVECEXP (vals, 0, 1)); return true; and in sparc_expand_vector_init_vis1: if (tmp != target) emit_move_insn (target, gen_highpart (mode, tmp)); Taking the high part is valid only if it is at least as large as a word (in the middle-end sense). Otherwise, the compiler stops. So, in 64-bit mode, this breaks for V2SImode in vector_init_move_words and for V2HImode and V4QImode in sparc_expand_vector_init_vis1. I tried to think about some solutions, for example using a paradoxical subreg in sparc_expand_vector_init_vis1, but this pessimizes. > Support for the short floating point loads starts to show up here as > well, and I intend to flesh these out, support the short float stores, > and add VIS intrinsic access to them. There isn't an equivalent for 32-bit, is it? That is, you can load 8, 16 and 64 bits in the upper FP regs, but not 32 bits? While trying to debug the failures, I've made some cosmetic changes left and right. Tested on SPARC/Solaris, applied on the mainline. 2011-11-09 Eric Botcazou * config/sparc/sparc.c (output_v8plus_shift): Take INSN parameter first and adjust head comment. (output_v8plus_mult): Change NAME into OPCODE and adjust throughout. (vector_init_bshuffle): Add head comment. (vector_init_move_words): Likewise. (vector_init_prepare_elts): Likewise. Take LOCS parameter first. (sparc_expand_vector_init): Likewise. Adjust call to above function. (sparc_expand_vector_init_vis2): Likewise. (sparc_expand_vector_init_vis1): Likewise. (sparc_expand_conditional_move): Likewise. (sparc_expand_vcond): Likewise. * config/sparc/sparc-protos.h (output_v8plus_shift): Adjust. * config/sparc/sparc.md (ashldi3_v8plus): Adjust call to output_v8plus_shift. (ashrdi3_v8plus): Likewise. (lshrdi3_v8plus): Likewise. -- Eric Botcazou Index: config/sparc/sparc.md === --- config/sparc/sparc.md (revision 181149) +++ config/sparc/sparc.md (working copy) @@ -5649,7 +5649,7 @@ (define_insn "ashldi3_v8plus" (match_operand:SI 2 "arith_operand" "rI,rI,rI"))) (clobber (match_scratch:SI 3 "=X,X,&h"))] "TARGET_V8PLUS" - "* return output_v8plus_shift (operands, insn, \"sllx\");" + "* return output_v8plus_shift (insn ,operands, \"sllx\");" [(set_attr "type" "multi") (set_attr "length" "5,5,6")]) @@ -5759,7 +5759,7 @@ (define_insn "ashrdi3_v8plus" (match_operand:SI 2 "arith_operand" "rI,rI,rI"))) (clobber (match_scratch:SI 3 "=X,X,&h"))] "TARGET_V8PLUS" - "* return output_v8plus_shift (operands, insn, \"srax\");" + "* return output_v8plus_shift (insn, operands, \"srax\");" [(set_attr "type" "multi") (set_attr "length" "5,5,6")]) @@ -5849,7 +5849,7 @@ (define_insn "lshrdi3_v8plus" (match_operand:SI 2 "arith_operand" "rI,rI,rI"))) (clobber (match_scratch:SI 3 "=X,X,&h"))] "TARGET_V8PLUS" - "* return output_v8plus_shift (operands, insn, \"srlx\");" + "* return output_v8plus_shift (insn, operands, \"srlx\");" [(set_attr "type" "multi") (set_attr "length" "5,5,6")]) Index: config/sparc/sparc-protos.h === --- config/sparc/sparc-protos.h (revision 181149) +++ config/sparc/sparc-protos.h (working copy) @@ -74,7 +74,8 @@ extern const char *output_ubranch (rtx, extern const char *output_cbranch (rtx, rtx, int, int, int, rtx); extern const char *output_return (rtx); extern const char *output_sibcall (rtx, rtx); -extern const char *output_v8plus_shift (rtx *, rtx, const char *); +extern const char *output_v8plus_shift (rtx, rtx *, const char *); +extern const char *output_v8plus_mult (rtx, rtx *, const char *); extern const char *output_v9branch (rtx, rtx, int, int, int, int, rtx); extern const char *output_probe_stack_range (rtx, rtx); extern bool emit_scc_insn (rtx []); @@ -104,7 +105,6 @@ extern int v9_regcmp_p (enum rtx_code); extern int sparc_check_64 (rtx, rtx); extern rtx gen_df_reg (rtx, int); extern void sparc_expand_compare_and_swap_12 (rtx, rtx, rtx, rtx); -extern const char *output_v8plus_mult (rtx, rtx *, const char *); extern void sparc_expand_vector_init (rtx, rtx); extern void sparc_expand_vec_perm_bmask(enum machine_mode, rtx); extern bool sparc_expand_conditional_move (enum machine_mode, rtx *); Index: config/sparc/sparc.c
Re: [PATCH] Fix combine's simplify_comparison (PR rtl-optimization/51023)
On 11/09/11 17:24, Jakub Jelinek wrote:
> --- gcc/combine.c.jj 2011-11-08 23:35:12.0 +0100
> +++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
> @@ -11397,13 +11397,20 @@ simplify_comparison (enum rtx_code code,
>later on, and then we wouldn't know whether to sign- or
>zero-extend. */
> mode = GET_MODE (XEXP (op0, 0));
> - if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
> + if (GET_MODE_CLASS (mode) == MODE_INT
> && ! unsigned_comparison_p
> - && val_signbit_known_clear_p (mode, const_op)
> - && have_insn_for (COMPARE, mode))
> + && HWI_COMPUTABLE_MODE_P (mode))
> {
> - op0 = XEXP (op0, 0);
> - continue;
> + HOST_WIDE_INT c = trunc_int_for_mode (const_op, mode);
> + /* Don't do this if the sign bit of MODE or any
> + higher bit is set in CONST_OP. */
> + if (c == const_op
> + && c >= 0
> + && have_insn_for (COMPARE, mode))
> + {
> + op0 = XEXP (op0, 0);
> + continue;
> + }
> }
Yes, I think I prefer this.
Bernd
Re: Disable libitm if unsupported
On 11/09/2011 08:14 AM, Iain Sandoe wrote:
> On i686-darwin9 it fails with "target only supports weak alias"
> (I need to understand better where that comes from - but the machine is tied
> up right now).
This is fixed. I removed the alias in favor of a plain function for
portability.
I also added PR 51065 to track the automatic optimization possibility.
> On x86_64-darwin10 it fails to build sjlj.S because that file makes
> use of assembler constructs not available on the system as (I think
> Rainer perhaps already observed this for some solaris versions).
Testing a fix for the cfi pseudos now.
That won't totally fix darwin, because there are also elf-specific pseudos as
well (e.g. ".type"). I'll crib a patch together for that from cross-compiled
examples for you to test later.
> I had a quick look at config/x86/target.h and observe that the jmpbuf
> layout in that header is different from the system definition...
Irrelevant. It's a local jmpbuf for the local definition in sjlj.S. Which is
Special because we're actually recording the state for an outer frame. One
can NOT use the system setjmp/longjmp to implement libitm.
> Index: libitm/configure.tgt
> ===
> --- libitm/configure.tgt(revision 181206)
> +++ libitm/configure.tgt(working copy)
> @@ -93,10 +93,14 @@ case "${target}" in
>*-*-gnu* | *-*-k*bsd*-gnu \
>| *-*-netbsd* | *-*-freebsd* | *-*-openbsd* \
>| *-*-solaris2* | *-*-sysv4* | *-*-irix6* | *-*-osf* | *-*-hpux11* \
> - | *-*-darwin* | *-*-aix*)
> + | *-*-aix*)
> # POSIX system. The OS is supported.
> ;;
>
> + *-*-darwin*)# POSIX, but needs some work.
> +UNSUPPORTED=1
> +;;
> +
>*)# Non-POSIX, or embedded system
> UNSUPPORTED=1
If you want to commit that right away, that's fine by me.
r~
Re: [C++ Patch] PR 51047
On 11/09/2011 09:17 AM, Paolo Carlini wrote: looks like one of the usual cases of 'complain' not propagated enough, in this case, from finish_class_member_access_expr to lookup_member. Hmm, the function already has a "protect" parameter that overlaps somewhat with the functionality we're looking for. But it isn't a perfect fit, and I'm not going to ask you to rewrite that code to remove the duplication. OK. Jason
Re: [C++ Patch] PR 51045
OK. Jason
[PATCH] Fix combine's simplify_comparison (PR rtl-optimization/51023, take 3)
On Wed, Nov 09, 2011 at 05:47:02PM +0100, Bernd Schmidt wrote:
> Yes, I think I prefer this.
So here is hopefully last iteration of that.
Negative constants that trunc_int_for_mode to the same value
are IMHO just fine too, similarly for ZERO_EXTEND 0x for HImode
should be fine too. On the other side, if mode is DImode and
outer mode of ZERO_EXTEND is TImode, if const_op had the highest bit
set, it would mean it is considered to be 65 1s followed by 63 other
bits. It is hard to construct testcases for these (except for
the failure), because apparently the FE is already narrowing the comparisons
if the constant is in range.
Ok for trunk if this bootstraps/regtests?
Can you please look at the simplify_set hunk? Thanks.
2011-11-09 Jakub Jelinek
PR rtl-optimization/51023
* combine.c (simplify_comparison) : Don't use
val_signbit_known_clear_p for signed comparison narrowing
optimization. Don't check for non-VOIDmode, use
HWI_COMPUTABLE_MODE_P macro.
: Don't check for non-VOIDmode.
Optimize even when const_op is equal to GET_MODE_MASK (mode),
don't optimize if const_op is negative.
* gcc.c-torture/execute/pr51023.c: New test.
--- gcc/combine.c.jj2011-11-08 23:35:12.0 +0100
+++ gcc/combine.c 2011-11-09 18:03:54.185527804 +0100
@@ -11397,9 +11397,10 @@ simplify_comparison (enum rtx_code code,
later on, and then we wouldn't know whether to sign- or
zero-extend. */
mode = GET_MODE (XEXP (op0, 0));
- if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
+ if (GET_MODE_CLASS (mode) == MODE_INT
&& ! unsigned_comparison_p
- && val_signbit_known_clear_p (mode, const_op)
+ && HWI_COMPUTABLE_MODE_P (mode)
+ && trunc_int_for_mode (const_op, mode) == const_op
&& have_insn_for (COMPARE, mode))
{
op0 = XEXP (op0, 0);
@@ -11477,10 +11478,11 @@ simplify_comparison (enum rtx_code code,
case ZERO_EXTEND:
mode = GET_MODE (XEXP (op0, 0));
- if (mode != VOIDmode && GET_MODE_CLASS (mode) == MODE_INT
+ if (GET_MODE_CLASS (mode) == MODE_INT
&& (unsigned_comparison_p || equality_comparison_p)
&& HWI_COMPUTABLE_MODE_P (mode)
- && ((unsigned HOST_WIDE_INT) const_op < GET_MODE_MASK (mode))
+ && (unsigned HOST_WIDE_INT) const_op <= GET_MODE_MASK (mode)
+ && const_op >= 0
&& have_insn_for (COMPARE, mode))
{
op0 = XEXP (op0, 0);
--- gcc/testsuite/gcc.c-torture/execute/pr51023.c.jj2011-11-09
10:17:31.133406427 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr51023.c 2011-11-09
10:17:13.0 +0100
@@ -0,0 +1,18 @@
+/* PR rtl-optimization/51023 */
+
+extern void abort (void);
+
+short int
+foo (long int x)
+{
+ return x;
+}
+
+int
+main ()
+{
+ long int a = 0x4272AL;
+ if (foo (a) == a)
+abort ();
+ return 0;
+}
Jakub
Re: [C++ Patch] PR 51047
On 11/09/2011 06:09 PM, Jason Merrill wrote: On 11/09/2011 09:17 AM, Paolo Carlini wrote: looks like one of the usual cases of 'complain' not propagated enough, in this case, from finish_class_member_access_expr to lookup_member. Hmm, the function already has a "protect" parameter that overlaps somewhat with the functionality we're looking for. But it isn't a perfect fit, and I'm not going to ask you to rewrite that code to remove the duplication. OK. Indeed, after I sent the patch I noticed something, but in fact the rework didn't seem trivial to me. I promise to have a look when the time allows. Thanks, Paolo.
Re: Disable libitm if unsupported
On 9 Nov 2011, at 17:01, Richard Henderson wrote:
On 11/09/2011 08:14 AM, Iain Sandoe wrote:
On i686-darwin9 it fails with "target only supports weak alias"
(I need to understand better where that comes from - but the
machine is tied up right now).
This is fixed. I removed the alias in favor of a plain function for
portability.
I also added PR 51065 to track the automatic optimization possibility.
On x86_64-darwin10 it fails to build sjlj.S because that file makes
use of assembler constructs not available on the system as (I think
Rainer perhaps already observed this for some solaris versions).
Testing a fix for the cfi pseudos now.
That won't totally fix darwin, because there are also elf-specific
pseudos as well (e.g. ".type"). I'll crib a patch together for that
from cross-compiled examples for you to test later.
I had a quick look at config/x86/target.h and observe that the jmpbuf
layout in that header is different from the system definition...
Irrelevant. It's a local jmpbuf for the local definition in
sjlj.S. Which is Special because we're actually recording the
state for an outer frame. One can NOT use the system setjmp/longjmp
to implement libitm.
Index: libitm/configure.tgt
===
--- libitm/configure.tgt(revision 181206)
+++ libitm/configure.tgt(working copy)
@@ -93,10 +93,14 @@ case "${target}" in
*-*-gnu* | *-*-k*bsd*-gnu \
| *-*-netbsd* | *-*-freebsd* | *-*-openbsd* \
| *-*-solaris2* | *-*-sysv4* | *-*-irix6* | *-*-osf* | *-*-
hpux11* \
- | *-*-darwin* | *-*-aix*)
+ | *-*-aix*)
# POSIX system. The OS is supported.
;;
+ *-*-darwin*)# POSIX, but needs some work.
+UNSUPPORTED=1
+;;
+
*)# Non-POSIX, or embedded system
UNSUPPORTED=1
If you want to commit that right away, that's fine by me.
I'll hang on .. and test stuff ;-)
cheers
Iain
Re: [rs6000] Fix PR 50906, eh_frame and other woes
On Nov 8, 2011, at 2:40 PM, Alan Modra wrote: > On Tue, Nov 08, 2011 at 11:37:57AM +0100, Olivier Hainque wrote: >> Joseph resorted to mem:scratch to impose a strong barrier. That's certainly >> safe and I don't think the performance impact can be significant, so this >> looks like a good way out. > > I agree. Our fancy powerpc stack deallocation barriers rely too much > on alias analysis, which as you've shown (thanks!) isn't reliable in > this instance. Other targets just use the mem:scratch barrier. Right. While the instance we have at hand here involves a bug I think (r11 perceived as a base reg to symbol), I don't see that we have strong guarantees that the current assumptions hold for sure in absence of such a bug. >> I tried an approach in between here: replace the stack_tie insn by a >> frame_tie insn with frame_base_rtx as the second base. In the case above, >> with frame_base_rtx==r11, this is something like >> >> (set (mem/c:BLK (reg:SI 11 11) [0 A8]) >>(unspec:BLK [ >>(mem/c:BLK (reg:SI 11 11) [0 A8]) >>(mem/c:BLK (reg/f:SI 1 1) [0 A8]) > > Looks similar to > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282#c15 Exactly. The idea here is to use the same mechanism in the other places where emit_epilogue emits a tie, making sure that the tie mem access will conflict with the frame accesses by issuing a write from the same base register. Now, if we can indeed have frame accesses using different base registers and a tie is needed after that (needs double checking), well, we'll need several of them. We could probably abstract this away and "just" keep track of a set of base registers used before a tie gets emitted. I'm not convinced that the potential gain is worth the extra complexity and potential risk of running into another subtle subcase, with hard to track sporadic runtime failures for starters. I don't have numbers though. That's a port maintainer call, I guess ? Olivier
Re: [Patch] PR 51061
On Wed, 9 Nov 2011, Paolo Carlini wrote: > Hi, > > reportedly, the patchlet which plugged the memory leak reported in PR36819 can > cause problems when heads[QUOTE] or tails[QUOTE]. Thus I'm finishing testing > the below. Really, if we have reasons to believe that the issue is much more > complex than this, I guess we can also revert PR36819, -I- itself is > deprecated, so.. This patch is OK. There have been various arguments against the -I- deprecation (see PR 19541); I haven't really followed them, but my impression is that the deprecation has probably proved to be a bad idea in practice. -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch] PR 51061
On 11/09/2011 06:21 PM, Joseph S. Myers wrote: On Wed, 9 Nov 2011, Paolo Carlini wrote: Hi, reportedly, the patchlet which plugged the memory leak reported in PR36819 can cause problems when heads[QUOTE] or tails[QUOTE]. Thus I'm finishing testing the below. Really, if we have reasons to believe that the issue is much more complex than this, I guess we can also revert PR36819, -I- itself is deprecated, so.. This patch is OK. There have been various arguments against the -I- deprecation (see PR 19541); I haven't really followed them, but my impression is that the deprecation has probably proved to be a bad idea in practice. I see. I committed the patch. Thanks, Paolo.
Re: RFA: New pass to delete unexecutable paths in the CFG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/11 02:00, Richard Guenther wrote: > >> So the question is do we want to proceed with any of this work? >> If so I can update the patch, if not I'll go back to my warning >> work :-) > > I think we do want to continue with this work - probably not > removing the faulting dereference though. I'd say we add a > noreturn __builtin_nullptr_deref () in place of it (eventually > doing the path isolation you mentioned above) and warn about the > ones that survive until RTL expansion (where we'd just expand it as > *0 = 0). Seems reasonable. Interestingly enough the path isolation part would be a special case of the path isolation code I want to build anyway. FWIW, there's other things which we probably want to handle in a similar fashion. For example, out of range array references, particularly those implied by PHIs with out of range indices. > > In fact, the warning part of it might be the most useful piece for > our users ;) Most definitely. Optimizing this stuff was merely a sideshow; I believe the warning bits are far more useful. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOurocAAoJEBRtltQi2kC7J3AIAJXwvQdfkXJGDtOvajvnbONy EHH0SQPObDRW97CTNhS2Ky270SRzfZoF0dFAFEwnfoaHISkHxcWnJB6GIjYQZEG0 WJiY2QEJSeXvbX517S2AZLlvVA1Lzq/NFyPtw8I+Z4D23dqFWMF/OIQhBBMqanAN GOmhsTFgn0njv6PR3ksD8Rvlf2GgfpKfrt2b8LFv2eEl1wIGf0uBEMFXgJJVBjcL tWibKpxT9roreEwzoKtPV1Gn+vZ9grclNhQ501l9exzoonIvg+EY9amhUQgtSPFA JeZUOgj3XHI1cWpCHeTMLnkar0w0XtWoqQd//+6RhFmdKFBQA9pV5XdVPJ2A8GA= =vqbV -END PGP SIGNATURE-
[PATCH] PR c++/51043 - ICE in LTO
Hello, LTO crashes during debug info generation while seamlessly trying to see if an anonymous union type has template info, using the TYPE_TEMPLATE_INFO accessor. That type's TYPE_NAME is NULL and we TYPE_TEMPLATE_INFO shouldn't crash on that. The first hunk (the change to TYPE_ALIAS_P) is what's strictly necessary to fix this. I went on to make the other part of TYPE_TEMPLATE_INFO that uses TYPE_NAME to be robust as well, in the second hunk. No test is needed because this was regressing g++.dg/lto/20100423-3.C. Bootstrapped and tested on powerpc64-unknown-linux-gnu against trunk. From: Dodji Seketeli Date: Wed, 9 Nov 2011 15:58:08 +0100 Subject: [PATCH] PR c++/51043 - ICE in LTO * cp-tree.h (TYPE_ALIAS_P, TYPE_TEMPLATE_INFO): Don't crash on NULL TYPE_NAME. --- gcc/cp/cp-tree.h | 23 --- 1 files changed, 12 insertions(+), 11 deletions(-) diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index 32d08ca..9410e54 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -2550,8 +2550,9 @@ extern void decl_shadowed_for_var_insert (tree, tree); /* Nonzero for a type which is an alias for another type; i.e, a type which declaration was written 'using name-of-type = another-type'. */ -#define TYPE_ALIAS_P(NODE) \ - (TYPE_P (NODE) \ +#define TYPE_ALIAS_P(NODE) \ + (TYPE_P (NODE) \ + && TYPE_NAME (NODE) \ && TYPE_DECL_ALIAS_P (TYPE_NAME (NODE))) /* For a class type: if this structure has many fields, we'll sort them @@ -2605,15 +2606,15 @@ extern void decl_shadowed_for_var_insert (tree, tree); ->template_info) /* Template information for an ENUMERAL_, RECORD_, or UNION_TYPE. */ -#define TYPE_TEMPLATE_INFO(NODE) \ - (TREE_CODE (NODE) == ENUMERAL_TYPE \ - ? ENUM_TEMPLATE_INFO (NODE) : \ - (TREE_CODE (NODE) == BOUND_TEMPLATE_TEMPLATE_PARM \ -? TEMPLATE_TEMPLATE_PARM_TEMPLATE_INFO (NODE) :\ -((CLASS_TYPE_P (NODE) && !TYPE_ALIAS_P (NODE)) \ - ? CLASSTYPE_TEMPLATE_INFO (NODE) \ - : (DECL_LANG_SPECIFIC (TYPE_NAME (NODE)) \ - ? (DECL_TEMPLATE_INFO (TYPE_NAME (NODE))) \ +#define TYPE_TEMPLATE_INFO(NODE) \ + (TREE_CODE (NODE) == ENUMERAL_TYPE \ + ? ENUM_TEMPLATE_INFO (NODE) : \ + (TREE_CODE (NODE) == BOUND_TEMPLATE_TEMPLATE_PARM \ +? TEMPLATE_TEMPLATE_PARM_TEMPLATE_INFO (NODE) :\ +((CLASS_TYPE_P (NODE) && !TYPE_ALIAS_P (NODE)) \ + ? CLASSTYPE_TEMPLATE_INFO (NODE) \ + : ((TYPE_NAME (NODE) && DECL_LANG_SPECIFIC (TYPE_NAME (NODE)))\ + ? (DECL_TEMPLATE_INFO (TYPE_NAME (NODE))) \ : NULL_TREE /* Set the template information for an ENUMERAL_, RECORD_, or -- 1.7.6.4 -- Dodji
C++ PATCH to improve C++11 diagnostic on inherit/using5.C
I've been working on improving the running of the testsuite in C++11 mode; one of the failures it found was an odd error on g++.dg/inherit/using5.C due to the compiler trying to parse 'using B::f' as an alias-declaration. Fixed by bailing out early if parsing fails. Tested x86_64-pc-linux-gnu, applying to trunk. commit a918a6931a1badcf8496d70041b1b3bf1e682cc3 Author: Jason Merrill Date: Tue Nov 8 20:18:35 2011 -0500 * parser.c (cp_parser_alias_declaration): Don't do semantic processing if parsing failed. diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 1376a3a..9034344 100644 --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -14944,6 +14944,9 @@ cp_parser_alias_declaration (cp_parser* parser) type = cp_parser_type_id (parser); cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON); + if (cp_parser_error_occurred (parser)) +return error_mark_node; + /* A typedef-name can also be introduced by an alias-declaration. The identifier following the using keyword becomes a typedef-name. It has the same semantics as if it were introduced by the typedef
C++ PATCH for various template non-type argument tests in C++11 mode
I'm improving the C++11 coverage of the testsuite, which resulted in
several failures on non-type argument tests in the current testsuite.
Fixed by folding constant expressions in fewer cases.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b1ec006abd6e4dbf45fca99160b09dab0827a10c
Author: Jason Merrill
Date: Tue Nov 8 20:36:49 2011 -0500
* pt.c (convert_nontype_argument): Only integral arguments
get early folding.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 8c91a9e..38c26a7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -5681,10 +5681,24 @@ convert_nontype_argument (tree type, tree expr, tsubst_flags_t complain)
&& (TYPE_PTR_P (type) || TYPE_PTR_TO_MEMBER_P (type)))
expr = convert (type, expr);
- /* In C++11, non-type template arguments can be arbitrary constant
- expressions. But don't fold a PTRMEM_CST to a CONSTRUCTOR yet. */
- if (cxx_dialect >= cxx0x && TREE_CODE (expr) != PTRMEM_CST)
-expr = maybe_constant_value (expr);
+ /* In C++11, integral or enumeration non-type template arguments can be
+ arbitrary constant expressions. Pointer and pointer to
+ member arguments can be general constant expressions that evaluate
+ to a null value, but otherwise still need to be of a specific form. */
+ if (cxx_dialect >= cxx0x)
+{
+ if (INTEGRAL_OR_ENUMERATION_TYPE_P (type))
+ expr = maybe_constant_value (expr);
+ else if (TYPE_PTR_P (type)
+ || (TYPE_PTR_TO_MEMBER_P (type)
+ && TREE_CODE (expr) != PTRMEM_CST))
+ {
+ tree folded = maybe_constant_value (expr);
+ if (TYPE_PTR_P (type) ? integer_zerop (folded)
+ : null_member_pointer_value_p (folded))
+ expr = folded;
+ }
+}
/* HACK: Due to double coercion, we can get a
NOP_EXPR(ADDR_EXPR (arg)) here,
Re: [PATCH] PR c++/51043 - ICE in LTO
OK. Jason
Re: [Patch - vms]: Add support of pragma __extern_prefix
On Mon, 7 Nov 2011, Tristan Gingold wrote: > Hi, > > DEC-C for vms has '#pragma __extern_prefix' which is not unlike '#pragma > extern_prefix' supported by DEC-C for Tru64. > > This patch adds supports for the VMS version (which can save and restore > the current prefix). It reuses most of the current infrastructure, but > to do so c-pragma.c:pragma_extern_prefix had to be public. > > Manually tested by cross-building for ia64-vms and alpha-vms. > > Ok for trunk ? The c-family changes are OK. -- Joseph S. Myers jos...@codesourcery.com
C++ testsuite PATCH to overhaul running of tests in C++11 mode
While working on an earlier PR I noticed that make check-c++0x wasn't
actually running a lot of tests in C++11 mode because the -std=c++11
that it added came before the default arguments, so any test without a {
dg-options } line would still be run in C++98 mode. So I've reworked
the C++ testsuite to run in both modes: If a test specifies a -std,
then we use that, otherwise we do both.
I've also added c++98 and c++11 as effective target keywords, so a test
line can say e.g.
// { dg-error "foo" "bar" { target c++98 } }
if it's only ill-formed in C++98.
The check-c++0x target is now obsolete, so the toplevel check-c++
doesn't use it anymore.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b714f79ddd8bec09cd3758e93d7315207dfd02e3
Author: Jason Merrill
Date: Tue Nov 8 11:48:26 2011 -0500
Run most tests in both C++98 and C++11 modes.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_c++11): New.
(check_effective_target_c++98): New.
* lib/g++-dg.exp (g++-dg-runtest): New.
* [various.exp]: Use g++-dg-runtest.
* [various.C]: Fix for C++11 mode.
gcc/cp/
* Make-lang.in (check_g++_parallelize): Add dg-torture.exp.
(check-c++0x): Obsolete.
/
* Makefile.def (language=c++): Remove check-c++0x.
* Makefile.in (check-gcc-c++): Regenerate.
diff --git a/Makefile.def b/Makefile.def
index b94dabf..b4236ba 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -513,7 +513,7 @@ dependencies = { module=configure-target-newlib; on=all-ld; };
dependencies = { module=configure-target-libgfortran; on=all-target-libquadmath; };
languages = { language=c; gcc-check-target=check-gcc; };
-languages = { language=c++; gcc-check-target="check-c++ check-c++0x";
+languages = { language=c++; gcc-check-target=check-c++;
lib-check-target=check-target-libstdc++-v3;
lib-check-target=check-target-libmudflap-c++; };
languages = { language=fortran; gcc-check-target=check-fortran;
diff --git a/Makefile.in b/Makefile.in
index 900c325..c377f57 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -40661,7 +40661,7 @@ check-gcc-c++:
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS) \
- (cd gcc && $(MAKE) $(GCC_FLAGS_TO_PASS) check-c++ check-c++0x);
+ (cd gcc && $(MAKE) $(GCC_FLAGS_TO_PASS) check-c++);
check-c++: check-gcc-c++ check-target-libstdc++-v3 check-target-libmudflap-c++
.PHONY: check-gcc-fortran check-fortran
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 650fc38..0ce01ac 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -152,8 +152,7 @@ c++.srcman: doc/g++.1
check-c++ : check-g++
# Run the testsute in C++0x mode.
check-c++0x:
- $(MAKE) RUNTESTFLAGS="$(RUNTESTFLAGS) --extra_opts,-std=gnu++0x" \
- TESTSUITEDIR="$(TESTSUITEDIR).c++0x" check-g++
+ @echo Normal 'make check' now runs the testsuite in C++11 mode as well as C++98.
# Run the testsuite with garbage collection at every opportunity.
check-g++-strict-gc:
$(MAKE) RUNTESTFLAGS="$(RUNTESTFLAGS) --extra_opts,--param,ggc-min-heapsize=0,--param,ggc-min-expand=0" \
@@ -163,7 +162,7 @@ check-c++-subtargets : check-g++-subtargets
lang_checks += check-g++
lang_checks_parallelized += check-g++
# For description see comment above check_gcc_parallelize in gcc/Makefile.in.
-check_g++_parallelize = old-deja.exp dg.exp
+check_g++_parallelize = old-deja.exp dg.exp dg-torture.exp
#
# Install hooks:
diff --git a/gcc/testsuite/g++.dg/abi/mangle4.C b/gcc/testsuite/g++.dg/abi/mangle4.C
deleted file mode 100644
index 3ce2247..000
--- a/gcc/testsuite/g++.dg/abi/mangle4.C
+++ /dev/null
@@ -1,24 +0,0 @@
-// Test mangling of type casts
-// { dg-do compile }
-
-class A {};
-class B : public A {};
-
-template class C {};
-template class D {};
-template class E {};
-
-template void f(D &, C(b)> &) {} // { dg-error "" }
-template void g(D &, E(b)> &) {} // { dg-error "" }
-
-B b;
-
-int main()
-{
- C(&b)> c; // { dg-error "" }
- D<&b> d;
- E(&b)> e; // { dg-error "" }
- f(d, c);
- g(d, e);
-}
-
diff --git a/gcc/testsuite/g++.dg/charset/charset.exp b/gcc/testsuite/g++.dg/charset/charset.exp
index 7d409d3..fe35f6a 100644
--- a/gcc/testsuite/g++.dg/charset/charset.exp
+++ b/gcc/testsuite/g++.dg/charset/charset.exp
@@ -37,8 +37,8 @@ if ![info exists DEFAULT_CHARSETCFLAGS] then {
dg-init
# Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.{c,cc,S} ]] \
-"" $DEFAULT_CHARSETCFLAGS
+g++-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.{c,cc,S} ]] \
+$DEFAULT_CHARSETCFLAGS
# All done.
dg-finish
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic60.C b/gcc/testsuite/g++.dg/cpp0x/variadic60.C
index b86711f..8e1681e 100644
--- a/gcc/testsuite/g++.dg/cpp0x/variadic60.C
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic60.C
@@ -1 +1 @@
-template class tuple; // { dg-error "variadic templates" }
+template class tuple; // { dg-error "variadic templates" "" { target c++98 } }
diff --git a/gcc/testsu
Re: RFA: New pass to delete unexecutable paths in the CFG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/11 01:09, Paolo Bonzini wrote: > On 11/08/2011 09:24 PM, Jeff Law wrote: >> We don't have access to those assertions as they're removed well >> prior to this pass running. However, if we did, or if we had >> redundant PHIs in the stream which were propagated we'd be >> presented with something like >> >> BB0 if (p_1) goto BB1 else goto BB2 >> >> BB1: ... goto BB3 BB2: BB3: p_2 = phi (p_1 (BB1), 0(BB2)) *p_2 = >> 2; >> >> >> We'd recognize that the edge bb2->bb3 is unexecutable as doing >> so leads to a NULL pointer dereference. Since the edge bb2->bb3 >> is not a critical edge, we know that bb2 as a whole is >> unexecutable. bb2 is control dependent on the edge bb0->bb2. > > (Side note regarding critical edges: have you tried splitting them > before your pass?) No. The pass really came about at the last minute when I realized I could take the warning work (which was not ready), twiddle it slightly and get an optimization. Critical edges don't really inhibit this optimizer. They allow us to trivially distinguish between the case where the whole block is unexecutable vs just one of its outgoing edges being unexecutable. If we were to split the critical edge, we would ultimately get the same results in the end. > > Ok, so that's exactly what I was thinking about. In this case the > optimization is obviously allowed by the C standard; you have > > if (p) something; *p = 0; > > and the "*p = 0" has been in some sense translated to > > if (!p) something; *p = 0; > > which is only different on undefined paths. But I'm not sure that > more complicated cases, where there are other instructions between > the "if" and "*p = 0", would also be allowed by the C standard. > For example, I think a function call in the "else" branch, or > between the PHI and the dereference should prevent the > optimization, because the function call might never return for what > we know. Probably a volatile asm too. Does your patch do that? > (Testcases! :)). My patch totally ignores the other code on the unexecutable path. So we can miss externally visible side effects, if we were to somehow get on the unexecutable path. But that's the whole point, in a conforming program we can't ever get on the unexecutable path. > In general, this is quite different from all other existing GCC > optimizations based on undefined behavior. Whenever you trigger > undefined behavior, right now the effects do not extend *before* > the undefined operation. The proposed pass would change that, so > that its effects are a bit more surprising when debugging. If your > bug is that you forgot a "return;" in the else branch, you surely > wouldn't expect the compiler to swallow the entire branch. > Unfortunately debugging at -O0 is not always an option. Most certainly, it's controversial. I'm still debating with myself over whether or not this is a wise direction to take. As I've mentioned elsewhere, this is something that fell into my lap as I was working on a closely related warning. The warning is, to me at least, ultimately far more interesting than the optimization. Triggering the warning tells us to look at the code for a few things. 1. Truly incorrect code which leads to a NULL pointer dereference. 2. Correct, but inefficient source, like we've seen for VEC_BASE. 3. Missed optimizations, again like we've seen for VEC_BASE Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOur4eAAoJEBRtltQi2kC7t+MH/R2asrStW6dOOEOxuQWmKLIR uYGkknGsv36KJOD+rnzulv3iNZW2ubYvYNBCkJAJn6/PjRDvV9T9/82ZHY9m2+Cb SvWFOnP/gU8yEzksiS5fRB6rRzYOXUMX1/nXqmMDAfprRg9vYOBo34zQU93KonMT k2GBtXSD5vFXX3VL6ffGSnQk9i59A0eSPMs+0q6n3pGztd9AjvgPkJAMDP3qep9m jgCM0x+5gQwGzGCIVF65JqowAoqOaT3ZIGRajTvOZSa7N5gc+fvI3Czizb6lFr6R Xls4Q/G3M2T5uXENvAN6SiN0Sv24WTEWxIoyKS0X1KTSC78gyG2QVAMFaYwRj6A= =DOjd -END PGP SIGNATURE-
Re: C++ testsuite PATCH to overhaul running of tests in C++11 mode
On Wed, 9 Nov 2011, Jason Merrill wrote:
> While working on an earlier PR I noticed that make check-c++0x wasn't actually
> running a lot of tests in C++11 mode because the -std=c++11 that it added came
> before the default arguments, so any test without a { dg-options } line would
> still be run in C++98 mode. So I've reworked the C++ testsuite to run in both
> modes: If a test specifies a -std, then we use that, otherwise we do both.
To confirm: what do the PASS or FAIL lines look like? They need to be
different for the two modes; it's bad to have
PASS: g++.dg/whatever
PASS: g++.dg/whatever
as that breaks automatic comparisons; you need
PASS: g++.dg/whatever
PASS: g++.dg/whatever -std=c++11
or something similar with unique names for the two versions of each test.
--
Joseph S. Myers
jos...@codesourcery.com
Re: RFA: New pass to delete unexecutable paths in the CFG
On Wed, Nov 09, 2011 at 10:53:34AM -0700, Jeff Law wrote: > > which is only different on undefined paths. But I'm not sure that > > more complicated cases, where there are other instructions between > > the "if" and "*p = 0", would also be allowed by the C standard. > > For example, I think a function call in the "else" branch, or > > between the PHI and the dereference should prevent the > > optimization, because the function call might never return for what > > we know. Probably a volatile asm too. Does your patch do that? > > (Testcases! :)). > My patch totally ignores the other code on the unexecutable path. So > we can miss externally visible side effects, if we were to somehow get > on the unexecutable path. But that's the whole point, in a conforming > program we can't ever get on the unexecutable path. Well, side-effects that could be validly scheduled after the NULL pointer dereference are just fine to be omitted. But if there is a function call that might call exit (0); in it, or throw an exception and thus never reach the trap point, then omitting those would be an invalid optimization. Jakub
Re: C++ testsuite PATCH to overhaul running of tests in C++11 mode
On 11/09/2011 01:02 PM, Joseph S. Myers wrote: To confirm: what do the PASS or FAIL lines look like? For tests run in both modes, they look like PASS: g++.dg/whatever -std=c++98 PASS: g++.dg/whatever -std=c++11 Jason
[libitm] Configure for gas cfi pseudos
Tested on x86_64-linux. This *ought* to fix RO's Solaris problem.
Committed.
r~
commit 67ba1f57ef6bafdcc0d5e43dbe5793367622977b
Author: rth
Date: Wed Nov 9 18:09:53 2011 +
libitm: Configure for gas cfi pseudo ops.
* asmcfi.m4: New file.
* configure.ac (GCC_AS_CFI_PSEUDO_OP): Test it.
* configure, aclocal.m4, config.h.in: Rebuild.
* config/generic/asmcfi.h: New file.
* config/x86/sjlj.S: Use it.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181224
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/config/ChangeLog b/config/ChangeLog
index 7737f99..4f202ff 100644
--- a/config/ChangeLog
+++ b/config/ChangeLog
@@ -1,3 +1,7 @@
+2011-11-09 Richard Henderson
+
+ * asmcfi.m4: New file.
+
2011-11-02 Rainer Orth
* mh-interix (LIBGCC2_DEBUG_CFLAGS): Remove.
diff --git a/config/asmcfi.m4 b/config/asmcfi.m4
new file mode 100644
index 000..a725aa1
--- /dev/null
+++ b/config/asmcfi.m4
@@ -0,0 +1,15 @@
+;; Cribbed from libffi
+
+AC_DEFUN([GCC_AS_CFI_PSEUDO_OP],
+[AC_CACHE_CHECK([assembler .cfi pseudo-op support],
+gcc_cv_as_cfi_pseudo_op, [
+gcc_cv_as_cfi_pseudo_op=unknown
+AC_TRY_COMPILE([asm (".cfi_startproc\n\t.cfi_endproc");],,
+ [gcc_cv_as_cfi_pseudo_op=yes],
+ [gcc_cv_as_cfi_pseudo_op=no])
+ ])
+ if test "x$gcc_cv_as_cfi_pseudo_op" = xyes; then
+AC_DEFINE(HAVE_AS_CFI_PSEUDO_OP, 1,
+ [Define if your assembler supports .cfi_* directives.])
+ fi
+])
diff --git a/libitm/ChangeLog b/libitm/ChangeLog
index fe1d7d0..e91f91e 100644
--- a/libitm/ChangeLog
+++ b/libitm/ChangeLog
@@ -1,3 +1,10 @@
+2011-11-09 Richard Henderson
+
+ * configure.ac (GCC_AS_CFI_PSEUDO_OP): Test it.
+ * configure, aclocal.m4, config.h.in: Rebuild.
+ * config/generic/asmcfi.h: New file.
+ * config/x86/sjlj.S: Use it.
+
2011-11-08 Richard Henderson
* local.cc (_ITM_LB): Use a normal call, not a function alias.
diff --git a/libitm/aclocal.m4 b/libitm/aclocal.m4
index 6dcccdf..96617e6 100644
--- a/libitm/aclocal.m4
+++ b/libitm/aclocal.m4
@@ -991,6 +991,7 @@ AC_SUBST([am__untar])
]) # _AM_PROG_TAR
m4_include([../config/acx.m4])
+m4_include([../config/asmcfi.m4])
m4_include([../config/depstand.m4])
m4_include([../config/enable.m4])
m4_include([../config/futex.m4])
diff --git a/libitm/config.h.in b/libitm/config.h.in
index af13264..369f6c6 100644
--- a/libitm/config.h.in
+++ b/libitm/config.h.in
@@ -6,6 +6,9 @@
/* Define to 1 if the target supports 64-bit __sync_*_compare_and_swap */
#undef HAVE_64BIT_SYNC_BUILTINS
+/* Define if your assembler supports .cfi_* directives. */
+#undef HAVE_AS_CFI_PSEUDO_OP
+
/* Define to 1 if the target supports __attribute__((alias(...))). */
#undef HAVE_ATTRIBUTE_ALIAS
diff --git a/libitm/config/generic/asmcfi.h b/libitm/config/generic/asmcfi.h
new file mode 100644
index 000..fcb45c5
--- /dev/null
+++ b/libitm/config/generic/asmcfi.h
@@ -0,0 +1,44 @@
+
+/* Copyright (C) 2011 Free Software Foundation, Inc.
+ Contributed by Richard Henderson .
+
+ This file is part of the GNU Transactional Memory Library (libitm).
+
+ Libitm 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 of the License, or
+ (at your option) any later version.
+
+ Libitm 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
+
[Patch] Move Objective-C runtime flags to modern options system.
As discussed in: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00927.html This puts "flag_next_runtime" into the global options structure -- hopefully this will pave the way for extracting the information from objects when doing LTO and making sure that it is (a) consistent - and (b) that the correct values are set for the backend - - this does affect Darwin where the ObjC meta-data are put into different sections depending on the choice of runtime - thus it would be good to be able to verify things when doing LTO. -- In order to do this I had to address a number of bits & pieces to do with dependencies on the flag when setting other defaults. Essentially we have: * runtime (gnu/next) * abi-version * exceptions model. which must be consistent - the determination of this has been moved to ObjC init --- I am probably missing something - but there doesn't seem to be a ready way to set the Init() value of a flag depending on the target - the flag_next_runtime value is used on Darwin very early during building the includes lists - which happens before the options_override is called () so it would be nice to be able to do that (although I've worked around it for now). --- I needed to deal with '-fobjc-sjlj-exceptions' and elected to remove it - - this is because there is only one valid exception model for each permutation of runtime and ABI - thus the User flag is just clutter. It is now ignored as a User flag - and the relevant selection actions are all local to Objective C. (yay! got rid of one exceptions-related flag :-)) --- tested on i686-darwin9 (Objective-C and Objective-C++) with : -m32/-fobjc-abi-version=0,-m32/-fobjc-abi-version=1,-m64 which exercises both GNU and NeXT runtimes for all current ABIs. no regressions, OK for trunk? Iain gcc: * flags.h (flag_next_runtime): Remove. * toplev.c (flag_next_runtime): Remove. * config/darwin-c.c (darwin_register_objc_includes): Check if the GNU runtime is explicitly selected. * config/darwin.c (darwin_override_options): Set defaults for Objective C runtime and ABI dependent on the target. Check for incompatible ABI/target pairs. * config/darwin.h (SUBTARGET_C_COMMON_OVERRIDE_OPTIONS): Remove Objective-C flags checks. gcc/c-family: * c.opt (fgnu-runtime) Fill in information required to generate. (fnext-runtime): Likewise. (fobjc-sjlj-exceptions): Ignore and warn that it has no effect. * c-opts.c (c_common_handle_option): Remove references to Objective-C runtime flags. (c_common_post_options): Remove Objective-C code adjusting Objective-C exceptions models. gcc/objc: * objc-next-runtime-abi-01.c (objc_next_runtime_abi_01_init): Handle checking and setting the exception model. * objc-next-runtime-abi-02.c (objc_next_runtime_abi_02_init): Likewise. * objc-gnu-runtime-abi-01.c (objc_gnu_runtime_abi_01_init): Likewise. * objc-act.h (flag_objc_sjlj_exceptions): Declare. * objc-act.c (flag_objc_sjlj_exceptions): Define default. Index: gcc/flags.h === --- gcc/flags.h (revision 181206) +++ gcc/flags.h (working copy) @@ -56,10 +56,6 @@ extern bool final_insns_dump_p; /* Nonzero means make permerror produce warnings instead of errors. */ extern int flag_permissive; - -/* Generate code for GNU or NeXT Objective-C runtime environment. */ - -extern int flag_next_runtime; /* Other basic status info about current function. */ Index: gcc/c-family/c.opt === --- gcc/c-family/c.opt (revision 181206) +++ gcc/c-family/c.opt (working copy) @@ -810,7 +810,7 @@ C++ ObjC++ Var(flag_no_gnu_keywords, 0) Recognize GNU-defined keywords fgnu-runtime -ObjC ObjC++ +ObjC ObjC++ Report RejectNegative Var(flag_next_runtime,0) Generate code for GNU runtime environment fgnu89-inline @@ -872,7 +872,7 @@ fnew-abi C++ ObjC++ Ignore Warn(switch %qs is no longer supported) fnext-runtime -ObjC ObjC++ +ObjC ObjC++ Report RejectNegative Var(flag_next_runtime) Generate code for NeXT (Apple Mac OS X) runtime environment fnil-receivers @@ -919,8 +919,8 @@ Enable inline checks for nil receivers with the Ne ; Nonzero means that we generate NeXT setjmp based exceptions. fobjc-sjlj-exceptions -ObjC ObjC++ Var(flag_objc_sjlj_exceptions) Init(-1) -Enable Objective-C setjmp exception handling runtime +ObjC ObjC++ Ignore Warn(switch %qs has been removed and is set automaticaly where required) +Option removed fobjc-std=objc1 ObjC ObjC++ Var(flag_objc1_only) Index: gcc/c-family/c-opts.c === --- gcc/c-family/c-opts.c (revision 181206) +++ gcc/c-family/c-opts.c (working copy) @@ -604,14 +604,6 @@ c_common_handle_option (size_t scode
C++ PATCH for c++/51029 (C++11 ICE with virtual base)
With this test, build_base_path was crashing because it (reasonably)
assumed that if we're in a constructor with virtual bases, we can look
at current_in_charge_parm. But we can't in a template, even when we've
cleared processing_template_decl for the sake of
fold_non_dependent_expr. So don't try.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b27a03c5dcd721810269a876fd7f91e0d5a068ba
Author: Jason Merrill
Date: Tue Nov 8 13:09:24 2011 -0500
PR c++/51029
* class.c (build_base_path): Don't ICE in fold_non_dependent_expr.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index f10a749..d2cf63c 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -359,6 +359,11 @@ build_base_path (enum tree_code code,
V_BINFO. That offset is an entry in D_BINFO's vtable. */
tree v_offset;
+ /* In a constructor template, current_in_charge_parm isn't set,
+ and we might end up here via fold_non_dependent_expr. */
+ if (fixed_type_p < 0 && !(cfun && current_in_charge_parm))
+ fixed_type_p = 0;
+
if (fixed_type_p < 0 && in_base_initializer)
{
/* In a base member initializer, we cannot rely on the
diff --git a/gcc/testsuite/g++.dg/template/virtual1.C b/gcc/testsuite/g++.dg/template/virtual1.C
new file mode 100644
index 000..ee86bf3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/virtual1.C
@@ -0,0 +1,14 @@
+// PR c++/51029
+
+struct A
+{
+ void foo();
+};
+
+struct B : virtual A
+{
+ template B()
+ {
+foo();
+ }
+};
Re: [libitm] Configure for gas cfi pseudos
Richard Henderson writes: > Tested on x86_64-linux. This *ought* to fix RO's Solaris problem. Right, that's equivalent to, though cleaner than, what I've done. There are a few outstanding issues on Solaris/x86 with Sun as: * as doesn't grok the GNU-stack note in config/x86/sjlj.S (likewise osf as in config/alpha/sjlj.S): +#if defined __ELF__ && defined __linux__ .section .note.GNU-stack, "", @progbits +#endif * Sun as apparently cannot handle the branch hints in config/x86/cacheline.h (jnz,pn): I've just removed them to get further along fof now, but there needs to be a cleaner way, perhaps an autoconf test. * Even if libitm builds now, all execution tests fail like this: ld.so.1: simple-1.exe: fatal: /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libitm/.libs/libitm.so.0: hardware capability (CA_SUNW_HW_1) unsupported: 0x2000 [ AVX ] If the code ensures at runtime that AVX insns (or SSE for that matter) are only used if hardware and OS are capable of executing them, one can deal with this with the equivalent of gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so. Besides, we need to make sure that the assembler used is able to assemble SSE and/or AVX insns before using them. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[Patch, libfortran] Trivial cleanup committed
Hi, I committed the trivial patch below as obvious to trunk: 2011-11-09 Janne Blomqvist * intrinsics/time_1.h (gf_gettime): Simplify time() usage. Index: libgfortran/intrinsics/time_1.h === --- libgfortran/intrinsics/time_1.h (revision 181227) +++ libgfortran/intrinsics/time_1.h (working copy) @@ -213,9 +213,8 @@ gf_gettime (time_t * secs, long * usecs) *usecs = tv.tv_usec; return err; #else - time_t t, t2; - t = time (&t2); - *secs = t2; + time_t t = time (NULL); + *secs = t; *usecs = 0; if (t == ((time_t)-1)) return -1; -- Janne Blomqvist
Re: [libitm] Configure for gas cfi pseudos
On 11/09/2011 10:23 AM, Rainer Orth wrote: > * as doesn't grok the GNU-stack note in config/x86/sjlj.S (likewise osf > as in config/alpha/sjlj.S): > > +#if defined __ELF__ && defined __linux__ > .section .note.GNU-stack, "", @progbits > +#endif I'll include that in another __ELF__ patch I'm preparing for darwin. > * Sun as apparently cannot handle the branch hints in > config/x86/cacheline.h (jnz,pn): I've just removed them to get further > along fof now, but there needs to be a cleaner way, perhaps an > autoconf test. I should just re-write that in __atomic builtins. > * Even if libitm builds now, all execution tests fail like this: > > ld.so.1: simple-1.exe: fatal: > /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libitm/.libs/libitm.so.0: > hardware capability (CA_SUNW_HW_1) unsupported: 0x2000 [ AVX ] > > If the code ensures at runtime that AVX insns (or SSE for that matter) > are only used if hardware and OS are capable of executing them, one > can deal with this with the equivalent of > gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so. Yes, the _M256 entry points will only be used when AVX is used in the compiler. > Besides, we need to make sure that the assembler used is able to > assemble SSE and/or AVX insns before using them. I do worry about building a library version missing symbols though... I suppose we could put them in a different symbol version. If the user's program uses them, they'll include that symbol version and immediately get an ld.so error when moving it to a system that was built incorrectly. That's slightly better than a delayed error at the point that the _M256 gets called and the symbol lookup fails. r~
Re: [patch tree-optimization 1/2]: Branch-cost optimizations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/07/11 15:36, Richard Guenther wrote: > > Yes. tree-affine does this for a sum of expressions of the form a > + b * c. It collects such sum, optimizes it (and you can > add/subtract or scale these things) and re-emit the new simplified > form. Kai, what what were the concerns with this kind of approach? Richard's suggestion seems sound to me. From a maintenance standpoint reusing/extending the tree-affine code seems like a better route. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOusfNAAoJEBRtltQi2kC7qjYH/35nH85/+mgZNQiKTSfh2QMp eC9XUDScOzzIbCiN0kZZiedHarIlZL7LJ9285t5PGJP0oTzCpFuHOKrdp7+CC1e4 bNJSXlZpVKhJfvd5NCoJVts/CR/AlwA2P4hOGMHs2jn939fbIokxjknGsevG8udm W/SCS2B65IysJFNCQLjz7/CiZNq36Keuw2BC6c6dn1bXXDxAcvGuR8dgr3CEBbE1 fkR2WRzucOxnoy3/d05kJuG+GRXjQBLCVtFDl1SKK/moK3Zck2MDleI4oguCj+Gp B1zCA2BjEcdDQOoQjip8XhYqhoL1hFGJXoz7KU9nwl6utVG4SGeYw1V7Wr+i3u0= =3e/j -END PGP SIGNATURE-
Re: [top-level patch] Do proper target tool checks for readelf
On Thu, Nov 3, 2011 at 11:05 AM, Roland McGrath wrote: > On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie wrote: >> The patch looks OK to me. > > Thanks! As I'm still not a GCC committer, someone please check it in for me. > If people would like me to handle the merge over to src/ myself, I'd be > glad to do that step. Ping. Anybody going to do this commit for me? (If insteaed someone would like to add me to the gcc group so I can do "write after approval", that would be fine too.) Thanks, Roland
Re: Disable libitm if unsupported
> I'll hang on .. and test stuff ;-) Try now. I've committed the following. r~ commit f29a2041f32773464e226a83f41762c2e9cf658e Author: rth Date: Wed Nov 9 18:38:21 2011 + libitm: de-ELF-ize x86/sjlj.S. * config/x86/sjlj.S: Protect elf directives with __ELF__. Protect .note.GNU-stack with __linux__. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181229 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/libitm/ChangeLog b/libitm/ChangeLog index e91f91e..e78716d 100644 --- a/libitm/ChangeLog +++ b/libitm/ChangeLog @@ -1,5 +1,8 @@ 2011-11-09 Richard Henderson + * config/x86/sjlj.S: Protect elf directives with __ELF__. + Protect .note.GNU-stack with __linux__. + * configure.ac (GCC_AS_CFI_PSEUDO_OP): Test it. * configure, aclocal.m4, config.h.in: Rebuild. * config/generic/asmcfi.h: New file. diff --git a/libitm/config/x86/sjlj.S b/libitm/config/x86/sjlj.S index 6169499..32572d9 100644 --- a/libitm/config/x86/sjlj.S +++ b/libitm/config/x86/sjlj.S @@ -26,9 +26,9 @@ #include "asmcfi.h" .text - .p2align 4 + + .align 4 .globl _ITM_beginTransaction - .type _ITM_beginTransaction, @function _ITM_beginTransaction: cfi_startproc @@ -66,12 +66,14 @@ _ITM_beginTransaction: ret #endif cfi_endproc + +#ifdef __ELF__ + .type _ITM_beginTransaction, @function .size _ITM_beginTransaction, .-_ITM_beginTransaction +#endif - .p2align 4 + .align 4 .globl GTM_longjmp - .type GTM_longjmp, @function - .hidden GTM_longjmp GTM_longjmp: cfi_startproc @@ -103,6 +105,13 @@ GTM_longjmp: jmp *%edx #endif cfi_endproc + +#ifdef __ELF__ + .type GTM_longjmp, @function + .hidden GTM_longjmp .size GTM_longjmp, .-GTM_longjmp +#endif +#ifdef __linux__ .section .note.GNU-stack, "", @progbits +#endif
Re: Disable libitm if unsupported
On 9 Nov 2011, at 18:39, Richard Henderson wrote: I'll hang on .. and test stuff ;-) Try now. I've committed the following. sjlj.S now builds ... ... similar issues are showing in x86_sse.S (I will try and look at those, if you have not already started). Iain
Re: [libitm] Configure for gas cfi pseudos
On Wed, Nov 09, 2011 at 10:33:12AM -0800, Richard Henderson wrote: > > If the code ensures at runtime that AVX insns (or SSE for that matter) > > are only used if hardware and OS are capable of executing them, one > > can deal with this with the equivalent of > > gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so. > > Yes, the _M256 entry points will only be used when AVX is used in the > compiler. > > > Besides, we need to make sure that the assembler used is able to > > assemble SSE and/or AVX insns before using them. > > I do worry about building a library version missing symbols though... Aren't the symbol versions part of the ABI discussed with Intel and others though? Jakub
Re: [PATCH] More improvements to sparc VIS vec_init code generation.
From: Eric Botcazou Date: Wed, 9 Nov 2011 17:41:36 +0100 > There isn't an equivalent for 32-bit, is it? That is, you can load 8, 16 and > 64 bits in the upper FP regs, but not 32 bits? Indeed, you need to use normal 32-bit loads and thus the lower 32 float regs. BTW, I suspect the paradoxical subreg trick will work without pessimizing as long as you emit a clobber first. Thanks for looking into the 64-bit failures, and actually if you want I can work on fixing them myself this afternoon.
Re: [libitm] Configure for gas cfi pseudos
On 11/09/2011 10:50 AM, Jakub Jelinek wrote: > Aren't the symbol versions part of the ABI discussed with Intel and others > though? Ug. Probably. Though they never actually responded wrt the symbol versions when we talked; none of the guys on the conference call undersood that bit about how ELF works. Other options for building a library with missing symbols? r~
Re: [top-level patch] Do proper target tool checks for readelf
> Ping. Anybody going to do this commit for me? (If insteaed someone would > like to add me to the gcc group so I can do "write after approval", that > would be fine too.) Done.
Re: [libitm] Configure for gas cfi pseudos
On Wed, 2011-11-09 at 19:50 +0100, Jakub Jelinek wrote: > On Wed, Nov 09, 2011 at 10:33:12AM -0800, Richard Henderson wrote: > > > If the code ensures at runtime that AVX insns (or SSE for that matter) > > > are only used if hardware and OS are capable of executing them, one > > > can deal with this with the equivalent of > > > gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so. > > > > Yes, the _M256 entry points will only be used when AVX is used in the > > compiler. > > > > > Besides, we need to make sure that the assembler used is able to > > > assemble SSE and/or AVX insns before using them. > > > > I do worry about building a library version missing symbols though... > > Aren't the symbol versions part of the ABI discussed with Intel and others > though? This ABI is explicitly for x86 on Linux (we've ignored the Windows version of it so far). We thus can define it differently (or just offer a subset of the symbols) on other architectures/platforms.
Re: [libitm] Configure for gas cfi pseudos
On 11/09/2011 10:58 AM, Torvald Riegel wrote: > This ABI is explicitly for x86 on Linux (we've ignored the Windows > version of it so far). We thus can define it differently (or just offer > a subset of the symbols) on other architectures/platforms. Subsets are dangerous. For any platform that has any kind of support for AVX, we should simply require it. For platforms where AVX will never be present (e.g. old OS versions), I suppose we can add some configury to omit the symbols. r~
Re: [libitm] Configure for gas cfi pseudos
On Wed, Nov 09, 2011 at 10:55:53AM -0800, Richard Henderson wrote: > On 11/09/2011 10:50 AM, Jakub Jelinek wrote: > > Aren't the symbol versions part of the ABI discussed with Intel and others > > though? > > Ug. Probably. Though they never actually responded wrt the symbol versions > when we talked; none of the guys on the conference call undersood that bit > about how ELF works. > > Other options for building a library with missing symbols? What exactly are AVX instructions needed for? Is it just that the entry points get their arguments in %ymm0/%ymm1 etc. and/or return results in %ymm0? If so, the poor man's/not very capable target hack could be to have assembly wrappers for those that would just vextractf128 the high parts either into some other %xmm registers, or into memory (using .byte ...) and then call some less optimized C version of those. Jakub
Re: [Patch,Fortran] Fix tree-walking issue
On Wed, Nov 2, 2011 at 09:33, Tobias Burnus wrote: > Dear all, > > attached is an updated version of Patch 2. The change is that I removed the > global variable for fill_st_vector and updated the comment for > do_traverse_symtree to make assumptions clearer. > > This version of the patch was build and regtested (gfortran + libgomp). > OK? Ok. It seems a bit unclear whether marking helps or not, but at least it doesn't seem to make anything worse.. > > > Dear Tobias S., > > Tobias Schlüter wrote: >> >> I don't remember all this very clearly, but I think that the >> gfc_symbol::tlink field is intended for something like this > > I think that's a rather different issue: It relates to undoing a symbol, > which I do not want to do. Additionally, a tlink symbol is already added to > a symtree (which is hence rebalanced). One possibility is to delay the > inclusion of symbols into the symtree - and do only so after the traversal - > but that might cause issues if one later searches in called function for > that symtree. Thus, I think my current patch should be sufficiently simple, > fast and solid. > > Tobias > -- Janne Blomqvist
Re: [libitm] Configure for gas cfi pseudos
On 11/09/2011 11:03 AM, Jakub Jelinek wrote: > On Wed, Nov 09, 2011 at 10:55:53AM -0800, Richard Henderson wrote: >> On 11/09/2011 10:50 AM, Jakub Jelinek wrote: >>> Aren't the symbol versions part of the ABI discussed with Intel and others >>> though? >> >> Ug. Probably. Though they never actually responded wrt the symbol versions >> when we talked; none of the guys on the conference call undersood that bit >> about how ELF works. >> >> Other options for building a library with missing symbols? > > What exactly are AVX instructions needed for? > > Is it just that the entry points get their arguments in %ymm0/%ymm1 etc. > and/or return results in %ymm0? Yes. > If so, the poor man's/not very capable > target hack could be to have assembly wrappers for those that would > just vextractf128 the high parts either into some other %xmm registers, > or into memory (using .byte ...) and then call some less optimized C > version of those. Ug. I'm not keen on .byte, but I suppose it's not the worst possibility. I'll think about that. r~
[Bug rtl-optimization/51040] atomic_fetch_nand issue
NAND patchup arithmetic was missing the 2 stage AND then NOT operation.
Instead it was falling into the same sequence as every other operation and
trying to perform a binary operation on a NOT.
I managed to modify and existing testcase to trigger the bug without requiring
a configuration with RTL checking enabled.
Bootstrapped on x86_64-unknown-linux-gnu with no new regressions (pending
completetion of test run)
OK for mainline?
PR rtl-optimization/51040
* optabs.c (expand_atomic_fetch_op): Patchup code for NAND should be AND
followed by NOT.
* builtins.c (expand_builtin_atomic_fetch_op): Patchup code for NAND
should be AND followed by NOT.
* testsuite/gcc.dg/atomic-noinline[-aux].c: Test no-inline NAND and
patchup code.
Index: optabs.c
===
*** optabs.c(revision 181206)
--- optabs.c(working copy)
*** expand_atomic_fetch_op (rtx target, rtx
*** 7875,7882
Fetch_before == after REVERSE_OP val. */
if (!after)
code = optab.reverse_code;
! result = expand_simple_binop (mode, code, result, val, target, true,
! OPTAB_LIB_WIDEN);
return result;
}
}
--- 7875,7889
Fetch_before == after REVERSE_OP val. */
if (!after)
code = optab.reverse_code;
! if (code != NOT)
! result = expand_simple_binop (mode, code, result, val, target,
! true, OPTAB_LIB_WIDEN);
! else
! {
! result = expand_simple_binop (mode, AND, result, val, NULL_RTX,
! true, OPTAB_LIB_WIDEN);
! result = expand_simple_unop (mode, NOT, result, target, true);
! }
return result;
}
}
Index: builtins.c
===
*** builtins.c (revision 181206)
--- builtins.c (working copy)
*** expand_builtin_atomic_fetch_op (enum mac
*** 5460,5467
/* Then issue the arithmetic correction to return the right result. */
if (!ignore)
! ret = expand_simple_binop (mode, code, ret, val, NULL_RTX, true,
! OPTAB_LIB_WIDEN);
return ret;
}
--- 5460,5476
/* Then issue the arithmetic correction to return the right result. */
if (!ignore)
! {
! if (code != NOT)
! ret = expand_simple_binop (mode, code, ret, val, target, true,
! OPTAB_LIB_WIDEN);
! else
! {
! ret = expand_simple_binop (mode, AND, ret, val, NULL_RTX, true,
!OPTAB_LIB_WIDEN);
! ret = expand_simple_unop (mode, NOT, ret, target, true);
! }
! }
return ret;
}
Index: testsuite/gcc.dg/atomic-noinline.c
===
*** testsuite/gcc.dg/atomic-noinline.c (revision 181206)
--- testsuite/gcc.dg/atomic-noinline.c (working copy)
*** main ()
*** 49,54
--- 49,61
if (__atomic_is_lock_free (4, 0) != 10)
abort ();
+ /* PR 51040 was caused by arithmetic code not patching up nand_fetch
properly
+ when used an an external function. Look for proper return value here.
*/
+ ac = 0x3C;
+ bc = __atomic_nand_fetch (&ac, 0x0f, __ATOMIC_RELAXED);
+ if (bc != ac)
+ abort ();
+
return 0;
}
Index: testsuite/gcc.dg/atomic-noinline-aux.c
===
*** testsuite/gcc.dg/atomic-noinline-aux.c (revision 181206)
--- testsuite/gcc.dg/atomic-noinline-aux.c (working copy)
*** char __atomic_fetch_add_1 (char *p, char
*** 40,50
*p = 1;
}
! short __atomic_fetch_add_2 (short *p, short v, short i)
{
*p = 1;
}
int __atomic_is_lock_free (int i, void *p)
{
return 10;
--- 40,63
*p = 1;
}
! short __atomic_fetch_add_2 (short *p, short v, int i)
{
*p = 1;
}
+ /* Really perform a NAND. PR51040 showed incorrect calculation of a
+non-inlined fetch_nand. */
+ unsigned char
+ __atomic_fetch_nand_1 (unsigned char *p, unsigned char v, int i)
+ {
+ unsigned char ret;
+
+ ret = *p;
+ *p = ~(*p & v);
+
+ return ret;
+ }
+
int __atomic_is_lock_free (int i, void *p)
{
return 10;
Re: [PATCH] Avoid frame pointer and stack realignment in AVX/AVX2 using fns if they don't touch sp/fp
On 11/07/2011 01:14 PM, Jakub Jelinek wrote: > * function.h (requires_stack_frame_p): New prototype. > * function.c (requires_stack_frame_p): No longer static. > * config/i386/i386.c (ix86_finalize_stack_realign_flags): If > stack_realign_fp was just a conservative guess for a function > which doesn't use sp/fp/argp at all, clear frame_pointer_needed > and stack realignment. Ok. r~
Re: [Build, libgfortran, Patch] Make libgfortran's configure more cross-compile friendly
On 02 Nov 2011 21:52, Janne Blomqvist wrote:
On Wed, Nov 2, 2011 at 22:25, Tobias Burnus wrote:
at the GSoC Mentor summit, I had a chat with Joel, who asked me whether he
should try to crosscompile also Fortran. Well, at the end I created the
attached patch (based on what one had to do for libquadmath) and he
successfully build fortran to target RTEMS for i386, sparc64, powerpc, mips,
and m68k.
Additionally, I have bootstrapped it on x86-64-linux.
OK for the trunk?
I have now committed the attached patch after approval by Janne on IRC.
The patch consists of the upper part of previous patch and leaves out
the more disputed second part. I think Janne is right that that part is
better as it is now.
Tobias
Looks good otherwise, however, I'm confused why you want to replace
AC_TRY_LINK with AC_LINK_IFELSE, since the former is deprecated and
the suggested replacement is, well, AC_LINK_IFELSE. In fact, this
issue was fixed not that long ago, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47883
Committed as Rev. 181212
2011-11-09 Tobias Burnus
* configure.ac: Make more cross-compile friendly.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
ChangeLog| 26 ++
Makefile.in |1
aclocal.m4 | 35 ++
config.h.in |3 +
configure| 144 ++-
configure.ac |8 +++
6 files changed, 206 insertions(+), 11 deletions(-)
Index: libgfortran/configure
===
--- libgfortran/configure (revision 181211)
+++ libgfortran/configure (revision 181212)
@@ -691,6 +691,7 @@
INSTALL_DATA
INSTALL_SCRIPT
INSTALL_PROGRAM
+target_noncanonical
target_os
target_vendor
target_cpu
@@ -2840,8 +2841,12 @@
NONENONEs,x,x, &&
program_prefix=${target_alias}-
+
+
+
target_alias=${target_alias-$host_alias}
+
# Sets up automake. Must come after AC_CANONICAL_SYSTEM. Each of the
# following is magically included in AUTOMAKE_OPTIONS in each Makefile.am.
# 1.9.6: minimum required version
@@ -4874,6 +4879,12 @@
# Create a spec file, so that compile/link tests don't fail
test -f libgfortran.spec || touch libgfortran.spec
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
# Check the compiler.
# The same as in boehm-gc and libstdc++. Have to borrow it from there.
# We must force CC to /not/ be precious variables; otherwise
@@ -5551,6 +5562,135 @@
+
+
+if test "x$CC" != xcc; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC and cc understand -c and -o together" >&5
+$as_echo_n "checking whether $CC and cc understand -c and -o together... " >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether cc understands -c and -o together" >&5
+$as_echo_n "checking whether cc understands -c and -o together... " >&6; }
+fi
+set dummy $CC; ac_cc=`$as_echo "$2" |
+ sed 's/[^a-zA-Z0-9_]/_/g;s/^[0-9]/_/'`
+if { as_var=ac_cv_prog_cc_${ac_cc}_c_o; eval "test \"\${$as_var+set}\" = set"; }; then :
+ $as_echo_n "(cached) " >&6
+else
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+# Make sure it works both with $CC and with simple cc.
+# We do the test twice because some compilers refuse to overwrite an
+# existing .o file with -o, though they will create one.
+ac_try='$CC -c conftest.$ac_ext -o conftest2.$ac_objext >&5'
+rm -f conftest2.*
+if { { case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
+$as_echo "$ac_try_echo"; } >&5
+ (eval "$ac_try") 2>&5
+ ac_status=$?
+ $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; } &&
+ test -f conftest2.$ac_objext && { { case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
+$as_echo "$ac_try_echo"; } >&5
+ (eval "$ac_try") 2>&5
+ ac_status=$?
+ $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; };
+then
+ eval ac_cv_prog_cc_${ac_cc}_c_o=yes
+ if test "x$CC" != xcc; then
+# Test first that cc exists at all.
+if { ac_try='cc -c conftest.$ac_ext >&5'
+ { { case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
+$as_echo "$ac_try_echo"; } >&5
+ (eval "$ac_try") 2>&5
+ ac_status=$?
+ $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; }; }; then
+ ac_try='cc -c conftest.$ac_ext -o conft
Re: [Patch] Move Objective-C runtime flags to modern options system.
On Wed, 9 Nov 2011, Iain Sandoe wrote: > I am probably missing something > - but there doesn't seem to be a ready way to set the Init() value of a flag > depending on the target The way that is done is to use an expression inside Init() that uses a target macro (it needs to be a macro, not a hook, at present). So change NEXT_OBJC_RUNTIME to be a macro defined to either 1 or 0, instead of defined or undefined, and use that in Init(). -- Joseph S. Myers jos...@codesourcery.com
[libitm] avoid non-portable branch mnemonics
I said elsewhere that I would convert this to __atomic, but then I re-read my commentary about using cmpxchg *without* a lock prefix. What we're looking for here is more or less non-interruptible, rather than atomic. And apparently I benchmarked this a while back as a 10x performance improvement. Seems like the easiest thing is simply to use .byte instead of ,pn. Committed. r~ commit f3210a53394de39a8aa74ec9dcb23f2cc0551322 Author: rth Date: Wed Nov 9 19:51:49 2011 + libitm: Avoid non-portable x86 branch prediction mnemonic. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181233 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/libitm/ChangeLog b/libitm/ChangeLog index e78716d..0501d16 100644 --- a/libitm/ChangeLog +++ b/libitm/ChangeLog @@ -1,5 +1,8 @@ 2011-11-09 Richard Henderson + * config/x86/cacheline.h (gtm_cacheline::store_mask): Use .byte + to emit branch prediction hint. + * config/x86/sjlj.S: Protect elf directives with __ELF__. Protect .note.GNU-stack with __linux__. diff --git a/libitm/config/x86/cacheline.h b/libitm/config/x86/cacheline.h index 15a95b0..f91d7cc 100644 --- a/libitm/config/x86/cacheline.h +++ b/libitm/config/x86/cacheline.h @@ -144,7 +144,7 @@ gtm_cacheline::operator= (const gtm_cacheline & __restrict s) } #endif -// ??? Support masked integer stores more efficiently with an unlocked cmpxchg +// Support masked integer stores more efficiently with an unlocked cmpxchg // insn. My reasoning is that while we write to locations that we do not wish // to modify, we do it in an uninterruptable insn, and so we either truely // write back the original data or the insn fails -- unlike with a @@ -171,7 +171,8 @@ gtm_cacheline::store_mask (uint32_t *d, uint32_t s, uint8_t m) "and%[m], %[n]\n\t" "or %[s], %[n]\n\t" "cmpxchg %[n], %[d]\n\t" - "jnz,pn 0b" + ".byte 0x2e\n\t" // predict not-taken, aka jnz,pn + "jnz0b" : [d] "+m"(*d), [n] "=&r" (n), [o] "+a"(o) : [s] "r" (s & bm), [m] "r" (~bm)); } @@ -198,7 +199,8 @@ gtm_cacheline::store_mask (uint64_t *d, uint64_t s, uint8_t m) "and%[m], %[n]\n\t" "or %[s], %[n]\n\t" "cmpxchg %[n], %[d]\n\t" - "jnz,pn 0b" + ".byte 0x2e\n\t" // predict not-taken, aka jnz,pn + "jnz0b" : [d] "+m"(*d), [n] "=&r" (n), [o] "+a"(o) : [s] "r" (s & bm), [m] "r" (~bm)); #else
Re: [patch]: support of VMS module include files
On Mon, 7 Nov 2011, Tristan Gingold wrote: > With this patch, these two directories are search in the include path > and added if found. This is mostly a VMS specific patch, except I > needed to add a function to get include pathes. > > Tested by cross compiling for alpha-vms and ia64-vms. > > Ok for trunk ? The incpath.[ch] changes are OK. -- Joseph S. Myers jos...@codesourcery.com
Re: Patch RFA: Add context switching splitstack routines
Ian Lance Taylor writes: > libgcc/ChangeLog: > > 2011-11-07 Ian Lance Taylor > > * generic-morestack.c: Include . > (uintptr_type): Define. > (struct initial_sp): Add dont_block_signals field. Reduce size of > extra array by 1. > (allocate_segment): Set prev field to NULL. Don't set > __morestack_current_segment or __morestack_segments. > (__generic_morestack): Update current->prev and *pp after calling > allocate_segment. > (__morestack_block_signals): Don't do anything if > dont_block_signals is set. > (__morestack_unblock_signals): Likewise. > (__generic_findstack): Check for initial_sp == NULL. Add casts to > uintptr_type. > (__splitstack_block_signals): New function. > (enum __splitstack_content_offsets): Define. > (__splitstack_getcontext, __splitstack_setcontext): New functions. > (__splitstack_makecontext): New function. > (__splitstack_block_signals_context): New function. > (__splitstack_find_context): New function. > * config/i386/morestack.S (__morestack_get_guard): New function. > (__morestack_set_guard, __morestack_make_guard): New functions. > * libgcc-std.ver.in: Add new functions to GCC_4.7.0. > > gcc/testsuite/ChangeLog: > > 2011-11-07 Ian Lance Taylor > > * lib/target-supports.exp (check_effective_target_ucontext_h): New > procedure. > * gcc.dg/split-5.c: New test. Jakub approved the change to target-supports.exp off-line. I committed the patch. Ian
Re: [trans-mem] fix memopt-1.c for 32bits
On Wed, Nov 09, 2011 at 09:32:28AM -0500, Patrick Marlier wrote:
>
> * gcc.dg/tm/memopt-1.c: Adjust regexp.
This results in
ERROR: (DejaGnu) proc "248" does not exist.
- [] is tcl procedure invocation.
Testing following, will commit soon if it succeeds:
2011-11-09 Jakub Jelinek
* gcc.dg/tm/memopt-1.c: Fix up regexp.
--- gcc/testsuite/gcc.dg/tm/memopt-1.c.jj 2011-11-09 19:34:04.642647773
+0100
+++ gcc/testsuite/gcc.dg/tm/memopt-1.c 2011-11-09 21:19:55.579803957 +0100
@@ -22,7 +22,7 @@ f()
}
}
-/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_RaWU[248]
\\(&g\\);" 1 "tmmemopt" } } */
+/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_RaWU\[248\]
\\(&g\\);" 1 "tmmemopt" } } */
/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_WaRU4 \\(&i," 1
"tmmemopt" } } */
/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_RaWU4 \\(&i\\);" 1
"tmmemopt" } } */
/* { dg-final { scan-tree-dump-times "transforming: .*_ITM_WaWU4 \\(&i," 1
"tmmemopt" } } */
Jakub
Re: [trans-mem] fix memopt-1.c for 32bits
On 11/09/2011 03:23 PM, Jakub Jelinek wrote: On Wed, Nov 09, 2011 at 09:32:28AM -0500, Patrick Marlier wrote: * gcc.dg/tm/memopt-1.c: Adjust regexp. This results in ERROR: (DejaGnu) proc "248" does not exist. - [] is tcl procedure invocation. Testing following, will commit soon if it succeeds: 2011-11-09 Jakub Jelinek * gcc.dg/tm/memopt-1.c: Fix up regexp. Good grief. Thanks Jakub! Patrick.
Re: C++ testsuite PATCH to overhaul running of tests in C++11 mode
Hi, 2011/11/9 Jason Merrill : > On 11/09/2011 01:02 PM, Joseph S. Myers wrote: >> >> To confirm: what do the PASS or FAIL lines look like? > > For tests run in both modes, they look like > > PASS: g++.dg/whatever -std=c++98 > PASS: g++.dg/whatever -std=c++11 Nice, but ... is there a way to launch the testsuite with only one mode at a time ? Thanks, -- Fabien
Re: [patch tree-optimization 1/2]: Branch-cost optimizations
2011/11/9 Jeff Law : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/07/11 15:36, Richard Guenther wrote: > >> >> Yes. tree-affine does this for a sum of expressions of the form a >> + b * c. It collects such sum, optimizes it (and you can >> add/subtract or scale these things) and re-emit the new simplified >> form. > Kai, what what were the concerns with this kind of approach? > Richard's suggestion seems sound to me. From a maintenance standpoint > reusing/extending the tree-affine code seems like a better route. > jeff Well, such a comparison-logic-folder helper - like affine-tree for add/subtract/scale) - is for sure something good for inner gimple passes building up new logic-truth expressions, but such a pass doesn't meet requirements need to fold for BC optimization AFAICS. The difference is that for BC we don't want to fold at all. Also it isn't necessarily "simplified" statement we want. For example 'if ((a | b) == 0 & ...) ...'. If the costs of such pattern '(a | b) == 0' are too high, we want to representation it instead as 'if (a == 0) if (b == 0) ...'. So for BC optimization we need to have a fully compare-expanded sequence of bitwise-operations including for sub-sequences. For normal folding we don't need sub-sequence expansion in most cases. The cause why we need for BC fully compare-expanded sequence I try to demonstrate on the following example. We have an condition 'if ((A | B) == 0 && C == 0) ...' where the joining of A == 0 and C == 0 would be profitable by BC-optimization, but the join of A != 0 and B != 0 isn't. So we do - as my patch does - first an expand to element comparison-sequence view. So we get for it the transformed form 'if (A == 0 && B == 0 && C == 0)'. Now we can begin to search for valid patterns in the condition for joining by searching from left-to-right for a profitable pattern. So we end-up with final statement 'if ((A | C) == 0 && C)' So as conclusion to answer your question about tree-affine implementation. Sure we can move the BC-optimization into a separate pass. As you and Richard already have explained, this would be indeed in some cases better, as there is more freedom in operating on gimple-statements. This makes for sure sense. But the logic itself we need in normal sequence-representation for folding seems not to be that what we need for BC. For general gimple passes we want to have compact form on linear-sequence without sub-sequences and we want compact final-representation in output. In BC we have slightly different requirements. We need a comparison-expanded form and of course with sub-sequences to do split-up right dependent on the actual branch-costs. Regards, Kai PS: There are several patch pending here about tree-reassoc (which does folding on truth-bitwise operations pretty well, if it gets an expanded view), about exactly the same subject, but here optimized for simplest form for folding with compacted output.
Re: [v3] C++11 allocator reqs for vector in debug & profile mode
On 9 November 2011 10:19, Paolo Carlini wrote:
> Hi
>>
>> I checked, and it's currently broken :)
>>
>> We do the wrong thing for allocators with
>> propagate_on_container_swap==true.
>>
>> I think the fix might be as simple as constructing the new container
>> with a copy of the old one's allocator, so even if it gets swapped
>> it's equal.
Like so:
* include/bits/allocator.h (__shrink_to_fit_aux::_S_do_it): Create
the new object with the same allocator.
* testsuite/23_containers/vector/capacity/shrink_to_fit2.cc: New.
Tested x86_64-linux, committed to trunk.
Thanks for reminding me about it.
>> I'll deal with it asap.
>
> Thanks a lot!
>
> Paolo.
>
Index: include/bits/allocator.h
===
--- include/bits/allocator.h (revision 181234)
+++ include/bits/allocator.h (revision 181235)
@@ -198,7 +198,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__try
{
_Tp(__make_move_if_noexcept_iterator(__c.begin()),
- __make_move_if_noexcept_iterator(__c.end())).swap(__c);
+ __make_move_if_noexcept_iterator(__c.end()),
+ __c.get_allocator()).swap(__c);
return true;
}
__catch(...)
Index: testsuite/23_containers/vector/capacity/shrink_to_fit2.cc
===
--- testsuite/23_containers/vector/capacity/shrink_to_fit2.cc (revision 0)
+++ testsuite/23_containers/vector/capacity/shrink_to_fit2.cc (revision 181235)
@@ -0,0 +1,61 @@
+// { dg-options "-std=gnu++0x" }
+
+// Copyright (C) 2011 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without Pred the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [PATCH] More improvements to sparc VIS vec_init code generation.
> Thanks for looking into the 64-bit failures, and actually if you want > I can work on fixing them myself this afternoon. Yes, you probably have a better grasp on the code than me. -- Eric Botcazou
[PATCH] Fix fallout from bool store pattern recognition (PR tree-optimization/51000)
Hi!
When a bool store gets a pattern stmt, we need to update
DR_STMT (otherwise the original rather than replaced stmts
are used e.g. for interleaving etc.).
Bootstrapped/regtested on x86_64-linux and i686-linux, testcase
tested on powerpc64-linux, ok for trunk?
2011-11-09 Jakub Jelinek
PR tree-optimization/51000
* tree-vect-patterns.c (vect_recog_bool_pattern): If adding
a pattern stmt for a bool store, adjust DR_STMT too.
Don't handle bool conversions to single bit precision lhs.
* tree-vect-stmts.c (vect_remove_stores): If next is a pattern
stmt, remove its related stmt and free its stmt_vinfo.
(free_stmt_vec_info): Free also pattern stmt's vinfo and
pattern def stmt's vinfo.
* tree-vect-loop.c (destroy_loop_vec_info): Don't try to
free pattern stmt's vinfo here.
(vect_transform_loop): When calling vect_remove_stores,
do gsi_next first and don't call gsi_remove. If not strided
store, free stmt vinfo for gsi_stmt (si) rather than stmt.
* gcc.dg/vect/pr51000.c: New test.
--- gcc/tree-vect-patterns.c.jj 2011-10-31 20:44:14.0 +0100
+++ gcc/tree-vect-patterns.c2011-11-09 13:15:22.117748929 +0100
@@ -2041,7 +2041,8 @@ vect_recog_bool_pattern (VEC (gimple, he
rhs_code = gimple_assign_rhs_code (last_stmt);
if (CONVERT_EXPR_CODE_P (rhs_code))
{
- if (TREE_CODE (TREE_TYPE (lhs)) != INTEGER_TYPE)
+ if (TREE_CODE (TREE_TYPE (lhs)) != INTEGER_TYPE
+ || TYPE_PRECISION (TREE_TYPE (lhs)) == 1)
return NULL;
vectype = get_vectype_for_scalar_type (TREE_TYPE (lhs));
if (vectype == NULL_TREE)
@@ -2096,6 +2097,7 @@ vect_recog_bool_pattern (VEC (gimple, he
STMT_VINFO_DR_STEP (pattern_stmt_info) = STMT_VINFO_DR_STEP (stmt_vinfo);
STMT_VINFO_DR_ALIGNED_TO (pattern_stmt_info)
= STMT_VINFO_DR_ALIGNED_TO (stmt_vinfo);
+ DR_STMT (STMT_VINFO_DATA_REF (stmt_vinfo)) = pattern_stmt;
*type_out = vectype;
*type_in = vectype;
VEC_safe_push (gimple, heap, *stmts, last_stmt);
--- gcc/tree-vect-stmts.c.jj2011-11-08 23:35:12.0 +0100
+++ gcc/tree-vect-stmts.c 2011-11-09 15:53:51.558120065 +0100
@@ -5567,10 +5567,14 @@ vect_remove_stores (gimple first_stmt)
while (next)
{
+ stmt_vec_info stmt_info = vinfo_for_stmt (next);
+
+ tmp = GROUP_NEXT_ELEMENT (stmt_info);
+ if (is_pattern_stmt_p (stmt_info))
+ next = STMT_VINFO_RELATED_STMT (stmt_info);
/* Free the attached stmt_vec_info and remove the stmt. */
next_si = gsi_for_stmt (next);
gsi_remove (&next_si, true);
- tmp = GROUP_NEXT_ELEMENT (vinfo_for_stmt (next));
free_stmt_vec_info (next);
next = tmp;
}
@@ -5660,6 +5664,22 @@ free_stmt_vec_info (gimple stmt)
if (!stmt_info)
return;
+ /* Check if this statement has a related "pattern stmt"
+ (introduced by the vectorizer during the pattern recognition
+ pass). Free pattern's stmt_vec_info and def stmt's stmt_vec_info
+ too. */
+ if (STMT_VINFO_IN_PATTERN_P (stmt_info))
+{
+ stmt_vec_info patt_info
+ = vinfo_for_stmt (STMT_VINFO_RELATED_STMT (stmt_info));
+ if (patt_info)
+ {
+ if (STMT_VINFO_PATTERN_DEF_STMT (patt_info))
+ free_stmt_vec_info (STMT_VINFO_PATTERN_DEF_STMT (patt_info));
+ free_stmt_vec_info (STMT_VINFO_RELATED_STMT (stmt_info));
+ }
+}
+
VEC_free (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmt_info));
set_vinfo_for_stmt (stmt, NULL);
free (stmt_info);
--- gcc/tree-vect-loop.c.jj 2011-11-07 12:40:56.0 +0100
+++ gcc/tree-vect-loop.c2011-11-09 16:05:47.979550141 +0100
@@ -870,21 +870,8 @@ destroy_loop_vec_info (loop_vec_info loo
for (si = gsi_start_bb (bb); !gsi_end_p (si); )
{
gimple stmt = gsi_stmt (si);
- stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
-
- if (stmt_info)
-{
- /* Check if this statement has a related "pattern stmt"
- (introduced by the vectorizer during the pattern recognition
- pass). Free pattern's stmt_vec_info. */
- if (STMT_VINFO_IN_PATTERN_P (stmt_info)
- && vinfo_for_stmt (STMT_VINFO_RELATED_STMT (stmt_info)))
-free_stmt_vec_info (STMT_VINFO_RELATED_STMT (stmt_info));
-
- /* Free stmt_vec_info. */
- free_stmt_vec_info (stmt);
-}
-
+ /* Free stmt_vec_info. */
+ free_stmt_vec_info (stmt);
gsi_next (&si);
}
}
@@ -5347,14 +5334,14 @@ vect_transform_loop (loop_vec_info loop_
/* Interleaving. If IS_STORE is TRUE, the vectorization of the
interleaving chain was completed - free all the stores in
the chain. */
+ gsi_next (&si);
vect_remove_stores (GROUP_FIRST_ELE
[PATCH] Handle -msse -mno-sse2 in expand_vec_perm_interleave2 (PR target/50911)
Hi!
We don't have a V4SImode vec_interleave_{low,high}v4si patterns
for TARGET_SSE, the following patch works around that by using
what TARGET_SSE has (vec_interleave_{low,high}v4sf) instead of
ICEing.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-11-09 Jakub Jelinek
PR target/50911
* config/i386/i386.c (expand_vec_perm_interleave2): If d->vmode is
V4SImode, !TARGET_SSE2 and punpck[lh]* is needed, change dremap.vmode
to V4SFmode.
* gcc.dg/torture/vshuf-16.inc: Add interleave low and high
permutations.
* gcc.dg/torture/vshuf-32.inc: Likewise.
* gcc.dg/torture/vshuf-4.inc: Likewise.
* gcc.dg/torture/vshuf-8.inc: Likewise.
--- gcc/config/i386/i386.c.jj 2011-11-08 23:35:12.0 +0100
+++ gcc/config/i386/i386.c 2011-11-09 19:13:25.309557798 +0100
@@ -35821,6 +35821,8 @@ expand_vec_perm_interleave2 (struct expa
dremap.perm[i * 2] = i;
dremap.perm[i * 2 + 1] = i + nelt;
}
+ if (!TARGET_SSE2 && d->vmode == V4SImode)
+ dremap.vmode = V4SFmode;
}
else if ((contents & (h2 | h4)) == contents)
{
@@ -35832,6 +35834,8 @@ expand_vec_perm_interleave2 (struct expa
dremap.perm[i * 2] = i + nelt2;
dremap.perm[i * 2 + 1] = i + nelt + nelt2;
}
+ if (!TARGET_SSE2 && d->vmode == V4SImode)
+ dremap.vmode = V4SFmode;
}
else if ((contents & (h1 | h4)) == contents)
{
--- gcc/testsuite/gcc.dg/torture/vshuf-16.inc.jj2011-10-24
12:21:08.0 +0200
+++ gcc/testsuite/gcc.dg/torture/vshuf-16.inc 2011-11-09 18:57:20.737490005
+0100
@@ -19,7 +19,9 @@ T (15,1, 30, 27, 31, 9, 18, 25, 12, 7,
T (16, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30) \
T (17, 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31) \
T (18, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3) \
-T (19, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
+T (19, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) \
+T (20, 0, 16, 1, 17, 2, 18, 3, 19, 4, 20, 5, 21, 6, 22, 7, 23) \
+T (21, 8, 24, 9, 25, 10, 26, 11, 27, 12, 28, 13, 29, 14, 30, 15, 31)
#define EXPTESTS \
T (116,28, 13, 27, 11, 21, 1, 5, 22, 29, 14, 15, 6, 3, 10, 16, 30) \
T (117,22, 26, 1, 13, 29, 3, 18, 18, 11, 21, 12, 28, 19, 5, 7, 4) \
--- gcc/testsuite/gcc.dg/torture/vshuf-32.inc.jj2011-10-24
12:21:08.0 +0200
+++ gcc/testsuite/gcc.dg/torture/vshuf-32.inc 2011-11-09 18:59:29.841686291
+0100
@@ -19,7 +19,9 @@ T (15,2, 43, 49, 34, 28, 35, 29, 36, 51
T (16, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36,
38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62) \
T (17, 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37,
39, 41, 43, 45, 47, 49, 51, 53, 55, 57, 59, 61, 63) \
T (18, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3) \
-T (19, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14,
13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
+T (19, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14,
13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) \
+T (20, 0, 32, 1, 33, 2, 34, 3, 35, 4, 36, 5, 37, 6, 38, 7, 39, 8, 40, 9, 41,
10, 42, 11, 43, 12, 44, 13, 45, 14, 46, 15, 47) \
+T (21, 16, 48, 17, 49, 18, 50, 19, 51, 20, 52, 21, 53, 22, 54, 23, 55, 24, 56,
25, 57, 26, 58, 27, 59, 28, 60, 29, 61, 30, 62, 31, 63)
#define EXPTESTS \
T (116,13, 38, 47, 3, 17, 8, 38, 20, 59, 61, 39, 26, 7, 49, 63, 43,
57, 16, 40, 19, 4, 32, 27, 7, 52, 19, 46, 55, 36, 41, 48, 6) \
T (117,39, 35, 59, 20, 56, 18, 58, 63, 57, 14, 2, 16, 5, 61, 35, 4,
53, 9, 52, 51, 27, 33, 61, 12, 3, 35, 36, 40, 37, 7, 45, 42) \
--- gcc/testsuite/gcc.dg/torture/vshuf-4.inc.jj 2011-10-24 12:21:08.0
+0200
+++ gcc/testsuite/gcc.dg/torture/vshuf-4.inc2011-11-09 18:54:28.554544049
+0100
@@ -19,7 +19,9 @@ T (15,6, 1, 3, 4) \
T (16, 0, 2, 4, 6) \
T (17, 1, 3, 5, 7) \
T (18, 3, 3, 3, 3) \
-T (19, 3, 2, 1, 0)
+T (19, 3, 2, 1, 0) \
+T (20, 0, 4, 1, 5) \
+T (21, 2, 6, 3, 7)
#define EXPTESTS \
T (116,1, 2, 4, 3) \
T (117,7, 3, 3, 0) \
--- gcc/testsuite/gcc.dg/torture/vshuf-8.inc.jj 2011-10-24 12:21:08.0
+0200
+++ gcc/testsuite/gcc.dg/torture/vshuf-8.inc2011-11-09 18:55:49.601039886
+0100
@@ -19,7 +19,9 @@ T (15,0, 5, 11, 7, 4, 6, 14, 1) \
T (16, 0, 2, 4, 6, 8, 10, 12, 14) \
T (17, 1, 3, 5, 7, 9, 11, 13, 15) \
T (18, 3, 3, 3, 3, 3, 3, 3, 3) \
-T (19, 7, 6, 5, 4, 3, 2, 1, 0)
+T (19, 7, 6, 5, 4, 3, 2, 1, 0) \
+T (20, 0, 8, 1, 9, 2, 10, 3, 11) \
+T (21, 4, 12, 5, 13, 6, 14, 7, 15)
#define EXPTESTS \
T (116,9, 3, 9, 4, 7, 0, 0, 6) \
T (117,4, 14, 12, 8, 9, 6, 0, 10) \
Jakub
Re: [PATCH] Handle -msse -mno-sse2 in expand_vec_perm_interleave2 (PR target/50911)
On 11/09/2011 01:34 PM, Jakub Jelinek wrote: > PR target/50911 > * config/i386/i386.c (expand_vec_perm_interleave2): If d->vmode is > V4SImode, !TARGET_SSE2 and punpck[lh]* is needed, change dremap.vmode > to V4SFmode. > > * gcc.dg/torture/vshuf-16.inc: Add interleave low and high > permutations. > * gcc.dg/torture/vshuf-32.inc: Likewise. > * gcc.dg/torture/vshuf-4.inc: Likewise. > * gcc.dg/torture/vshuf-8.inc: Likewise. Ok. r~
[CRIS] Hookize FUNCTION_VALUE_REGNO_P
Hello.
This patch removes obsolete FUNCTION_VALUE_REGNO_P macro from CRIS back end
in the GCC and introduces equivalent TARGET_FUNCTION_VALUE_REGNO_P target
hook.
Regression tested on cris-axis-elf.
OK to install?
* config/cris/cris.c (cris_function_value_regno_p): Make static.
(TARGET_FUNCTION_VALUE_REGNO_P): Define.
* config/cris/cris.h (FUNCTION_VALUE_REGNO_P): Remove.
* config/cris/cris-protos.h (cris_function_value_regno_p): Remove.
Index: gcc/config/cris/cris.c
===
--- gcc/config/cris/cris.c (revision 179723)
+++ gcc/config/cris/cris.c (working copy)
@@ -148,6 +148,7 @@
static rtx cris_function_value(const_tree, const_tree, bool);
static rtx cris_libcall_value (enum machine_mode, const_rtx);
+static bool cris_function_value_regno_p (const unsigned int);
/* This is the parsed result of the "-max-stack-stackframe=" option. If
it (still) is zero, then there was no such option given. */
@@ -241,6 +242,8 @@
#define TARGET_FUNCTION_VALUE cris_function_value
#undef TARGET_LIBCALL_VALUE
#define TARGET_LIBCALL_VALUE cris_libcall_value
+#undef TARGET_FUNCTION_VALUE_REGNO_P
+#define TARGET_FUNCTION_VALUE_REGNO_P cris_function_value_regno_p
struct gcc_target targetm = TARGET_INITIALIZER;
@@ -3763,7 +3768,7 @@
/* Let's assume all functions return in r[CRIS_FIRST_ARG_REG] for the
time being. */
-bool
+static bool
cris_function_value_regno_p (const unsigned int regno)
{
return (regno == CRIS_FIRST_ARG_REG);
Index: gcc/config/cris/cris.h
===
--- gcc/config/cris/cris.h (revision 179723)
+++ gcc/config/cris/cris.h (working copy)
@@ -854,12 +854,6 @@
&& (REGNO) < CRIS_FIRST_ARG_REG + (CRIS_MAX_ARGS_IN_REGS))
-/* Node: Scalar Return */
-
-#define FUNCTION_VALUE_REGNO_P(N) cris_function_value_regno_p (N)
-
-
-
/* Node: Aggregate Return */
#define CRIS_STRUCT_VALUE_REGNUM ((CRIS_FIRST_ARG_REG) - 1)
Index: gcc/config/cris/cris-protos.h
===
--- gcc/config/cris/cris-protos.h (revision 179723)
+++ gcc/config/cris/cris-protos.h (working copy)
@@ -60,5 +60,3 @@
extern int cris_initial_elimination_offset (int, int);
extern void cris_init_expanders (void);
-
-extern bool cris_function_value_regno_p (const unsigned int);
Anatoly.
Re: C++ testsuite PATCH to overhaul running of tests in C++11 mode
On 11/09/2011 04:01 PM, Fabien Chêne wrote: Nice, but ... is there a way to launch the testsuite with only one mode at a time ? Not currently. Jason
Re: [Patch] Move Objective-C runtime flags to modern options system.
On Nov 9, 2011, at 10:12 AM, Iain Sandoe wrote: > This puts "flag_next_runtime" into the global options structure > I needed to deal with '-fobjc-sjlj-exceptions' and elected to remove it - > - this is because there is only one valid exception model for each > permutation of runtime and ABI - thus the User flag is just clutter. > > It is now ignored as a User flag - and the relevant selection actions are all > local to Objective C. > > (yay! got rid of one exceptions-related flag :-)) Yeah, that sounds like a good idea. > +ObjC ObjC++ Ignore Warn(switch %qs has been removed and is set automaticaly > where required) Spelling, automatically. > +targetting Darwin. However, the flag overrides have not be called yet. > */ Spelling, targeting. > + if (flag_objc_exceptions) > +/* ??? Should we warn that this is incompatible, if the user has set it. > + For now, just force it it off. */ > +flag_exceptions = 0; Where was this in the previous code? In ObjC++, exceptions can be on for C++ and should not be turned off. Does this code ever turn off C++ exceptions? As a stylistic note, I'd rather have a literal translation into the new mechanism, no changes to behavior, and then a separate patch that then changes things you think are wrong or could be done better. The first is large and mechanical and it important to get right. The follow-on patches, when done one at a time, if any one proved wrong, it alone could then be reverted. If the flag_exceptions = 0 bit and Joseph's comments are fixed, I think we're done.
Re: building trunk fails due to C++
Steve Kargl wrote: With top of tree, I'm seeing % ../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran \ --disable-libmudflap --disable-bootstrap % gmake I think the issue is that by default the trunk is build (stage 1) by the system C compiler and the next stages (Stage 2 and 3) are build by the just-build C++ compiler. Thus, the C++ compiler supports the latest C++ features and also the latest options. If one now uses --disable-bootstrap, the system C++ compiler is used to compile the first and last stage - but if the system C++ compiler is slightly older, it might not support the newest compiler flags. I am not sure how to best solve this issues for --disable-bootstrap. Besides bootstrapping, you could use --disable-libitm or it might also work to specify --disable-build-poststage1-with-cxx which also saves you from building the C++ compiler if you don't want it. Tobias
Re: RFA: New pass to delete unexecutable paths in the CFG
On 11/09/2011 06:53 PM, Jeff Law wrote: My patch totally ignores the other code on the unexecutable path. So we can miss externally visible side effects, if we were to somehow get on the unexecutable path. But that's the whole point, in a conforming program we can't ever get on the unexecutable path. But if a subroutine call never returns, we wouldn't get to the undefined behavior in the first place. Paolo
C++ PATCH for c++/51046 (ICE with unexpanded parameter pack)
Missing a call to check_for_bare_parameter_packs.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3d2892d25a37984099611c02614fc9788e14d4c4
Author: Jason Merrill
Date: Wed Nov 9 14:25:21 2011 -0500
PR c++/51046
* parser.c (cp_parser_range_for): check_for_bare_parameter_packs.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3cb6dbf..fc8f3c8 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -9292,6 +9292,8 @@ cp_parser_range_for (cp_parser *parser, tree scope, tree init, tree range_decl)
at instantiation. If not, it is done just ahead. */
if (processing_template_decl)
{
+ if (check_for_bare_parameter_packs (range_expr))
+ range_expr = error_mark_node;
stmt = begin_range_for_stmt (scope, init);
finish_range_for_decl (stmt, range_decl, range_expr);
if (!type_dependent_expression_p (range_expr)
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic119.C b/gcc/testsuite/g++.dg/cpp0x/variadic119.C
new file mode 100644
index 000..78cd23e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic119.C
@@ -0,0 +1,13 @@
+// PR c++/51046
+// { dg-do compile { target c++11 } }
+
+template
+void f()
+{
+ for (int i : IS); // { dg-error "not expanded" }
+}
+
+int main()
+{
+ f<0, 1, 2>();
+}
Re: building trunk fails due to C++
On Wed, Nov 09, 2011 at 11:10:05PM +0100, Tobias Burnus wrote: > Steve Kargl wrote: > >With top of tree, I'm seeing > > > >% ../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran \ > >--disable-libmudflap --disable-bootstrap > >% gmake > > I think the issue is that by default the trunk is build (stage 1) by the > system C compiler and the next stages (Stage 2 and 3) are build by the > just-build C++ compiler. Thus, the C++ compiler supports the latest C++ > features and also the latest options. > > If one now uses --disable-bootstrap, the system C++ compiler is used to > compile the first and last stage - but if the system C++ compiler is > slightly older, it might not support the newest compiler flags. Yes, I understand that this is the problem. > > I am not sure how to best solve this issues for --disable-bootstrap. > Well, to start, whomever is responsible for libitm should remove the -std=gnu++0x option. Or, like, libgfortran, libitm should use the just built in-tree g++ to compile itself. > Besides bootstrapping, you could use --disable-libitm or it might also > work to specify --disable-build-poststage1-with-cxx which also saves you > from building the C++ compiler if you don't want it. Doing a full bootstrap adds 3+ hours on my laptop. Oh well, I guess this is the price of progress. -- Steve
C++ PATCH for c++/50972 (ice-on-invalid with noexcept)
In this testcase we weren't watching the return value of
push_tinst_level, so we crashed trying to pop the level we didn't push.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b7eabaa932f7f309630fc7163e64d61b1aba17c8
Author: Jason Merrill
Date: Wed Nov 9 16:39:25 2011 -0500
PR c++/50972
* pt.c (maybe_instantiate_noexcept): Check the return value of
push_tinst_level.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 71a98b0..55eba5a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18166,17 +18166,22 @@ maybe_instantiate_noexcept (tree fn)
if (TREE_CODE (noex) == DEFERRED_NOEXCEPT)
{
- push_tinst_level (fn);
- push_access_scope (fn);
- input_location = DECL_SOURCE_LOCATION (fn);
- noex = tsubst_copy_and_build (DEFERRED_NOEXCEPT_PATTERN (noex),
-DEFERRED_NOEXCEPT_ARGS (noex),
-tf_warning_or_error, fn, /*function_p=*/false,
-/*integral_constant_expression_p=*/true);
- pop_access_scope (fn);
- pop_tinst_level ();
- spec = build_noexcept_spec (noex, tf_warning_or_error);
- if (spec == error_mark_node)
+ if (push_tinst_level (fn))
+ {
+ push_access_scope (fn);
+ input_location = DECL_SOURCE_LOCATION (fn);
+ noex = tsubst_copy_and_build (DEFERRED_NOEXCEPT_PATTERN (noex),
+ DEFERRED_NOEXCEPT_ARGS (noex),
+ tf_warning_or_error, fn,
+ /*function_p=*/false,
+ /*integral_constant_expression_p=*/true);
+ pop_access_scope (fn);
+ pop_tinst_level ();
+ spec = build_noexcept_spec (noex, tf_warning_or_error);
+ if (spec == error_mark_node)
+ spec = noexcept_false_spec;
+ }
+ else
spec = noexcept_false_spec;
}
else
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept16.C b/gcc/testsuite/g++.dg/cpp0x/noexcept16.C
new file mode 100644
index 000..10e0be9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept16.C
@@ -0,0 +1,130 @@
+// PR c++/50972
+// { dg-do compile { target c++11 } }
+// Ignore all errors, we're just testing that this doesn't ICE
+// { dg-prune-output "error" }
+
+namespace std
+typedef long unsigned int size_t;
+template
+struct __and_;
+template
+struct is_nothrow_move_constructible
+{
+};
+template
+struct is_nothrow_move_assignable
+struct __add_rvalue_reference_helper<_Tp, true>
+{ typedef _Tp&& type; };
+template
+struct add_rvalue_reference
+ : public __add_rvalue_reference_helper<_Tp>
+{
+};
+template
+inline typename add_rvalue_reference<_Tp>::type
+declval() noexcept
+{
+}
+}
+namespace __gnu_cxx __attribute__ ((__visibility__ ("default")))
+template
+class new_allocator
+{
+};
+}
+namespace std __attribute__ ((__visibility__ ("default")))
+class allocator: public __gnu_cxx::new_allocator<_Tp>
+{
+ template
+ struct rebind
+ { typedef allocator<_Tp1> other; };
+};
+}
+namespace std __attribute__ ((__visibility__ ("default")))
+template
+struct __alloctr_rebind<_Alloc, _Tp, true>
+{
+ typedef typename _Alloc::template rebind<_Tp>::other __type;
+};
+template
+struct allocator_traits
+{
+ template
+ struct __rebind_alloc
+ {
+typedef typename __alloctr_rebind<_Alloc, _Tp>::__type __type;
+ };
+}
+ }
+namespace __gnu_cxx __attribute__ ((__visibility__ ("default")))
+template
+struct __alloc_traits
+{
+ typedef std::allocator_traits<_Alloc> _Base_type;
+ static constexpr bool _S_nothrow_swap()
+ {
+return !_S_propagate_on_swap()
+ || noexcept(swap(std::declval<_Alloc&>(), std::declval<_Alloc&>()));
+ }
+ template
+ struct rebind
+ { typedef typename _Base_type::template __rebind_alloc<_Tp>::__type other; };
+};
+}
+namespace std __attribute__ ((__visibility__ ("default")))
+template
+struct _Vector_base
+{
+ typedef typename __gnu_cxx::__alloc_traits<_Alloc>::template
+ rebind<_Tp>::other _Tp_alloc_type;
+};
+template >
+class vector : protected _Vector_base<_Tp, _Alloc>
+{
+ typedef _Vector_base<_Tp, _Alloc> _Base;
+ typedef typename _Base::_Tp_alloc_type _Tp_alloc_type;
+ typedef __gnu_cxx::__alloc_traits<_Tp_alloc_type> _Alloc_traits;
+ swap(vector& __x)
+ noexcept(_Alloc_traits::_S_nothrow_swap());
+};
+}
+namespace lexertl
+namespace detail
+}
+namespace detail
+template
+struct basic_internals
+{
+ typedef std::vector id_type_vector;
+};
+};
+template
+class basic_state_machine
+{
+ typedef detail::basic_internals internals;
+ void minimise ()
+ {
+minimise_dfa (dfa_alphabet_, *dfa_, size_);
+ }
+ typedef typename internals::id_type_vector id_type_vector;
+ void minimise_dfa (const id_type dfa_alphabet_,
+ id_type_vector &dfa_, std::size_t size_)
+ {
+id_type_vector new_dfa_ (front_, front_ + dfa_alphabet_);
+dfa_.swap (new_dfa_);
+ }
+}
+ }
+namespace std __attribute__ ((__visibility__ ("default")))
+template
+void
+swap(_Tp&, _Tp&)
+ noexcept(__and_,
+ is_nothrow_move_assignable<_Tp>>::value)
+ ;
+typedef lexertl::basic_state_machine lexstate;
+lexstate m_state_machine;
+GenerateLexer()
+{
+ m_state_machine.minimise();
+}
[RFC] PR 50837
Hi,
I'm trying to make progress on this issue which I find rather
embarrassing in terms of simple uses of constexpr functions and
static_assert. We reject, at instantiation time:
template
struct z
{
static constexpr bool test_constexpr()
{
return true;
}
static void test()
{
static_assert(test_constexpr(), "test1"); //error here
}
};
‘static constexpr bool z::test_constexpr() [with T = int]’ cannot
appear in a constant-expression
The same snippet is accepted if struct z isn't a template. The error
comes from:
/* Only certain kinds of names are allowed in constant
expression. Enumerators and template parameters have already
been handled above. */
if (! error_operand_p (decl)
&& integral_constant_expression_p
&& ! decl_constant_var_p (decl)
&& ! builtin_valid_in_constant_expr_p (decl))
{
if (!allow_non_integral_constant_expression_p)
{
error ("%qD cannot appear in a constant-expression", decl);
return error_mark_node;
}
in finish_id_expression, which is called by tsubst_copy_and_build, case
IDENTIFIER_NODE, with a false allow_non_integral_constant_expression_p.
What is puzzling me, is that, in the non-template struct z case,
finish_id_expression is called from cp_parser_primary_expression with a
true allow_non_integral_constant_expression_p and the error doesn't
occur. As a matter of fact, naively hacking the tsubst_copy_and_build
call to also pass true, mostly passes the testsuite, modulo a diagnostic
regression of template/nontype13.C.
Jason, basing on these few debugging notes, can you already see in which
direction I should further investigate?
Thanks,
Paolo.
[patch] Flag-controlled type conversions/promotions
Hi there,
please find attached the patch and the Changelog entry for our work on
the fortran bug #48426.
The attached patch implements the options
-finteger-4-integer-8
-freal-4-real-8
-freal-4-real-10
-freal-4-real-16
-freal-8-real-4
-freal-8-real-10
-freal-8-real-16
to implement a variety of automatic type promotions. (This is particularly
helpful if one wants to quickly check whether a certain code has a bug limiting
its precision away from full machine accuracy.)
A similar promotion feature is available in Fujitsu compilers, see here:
http://www.lahey.com/docs/fujitsu%20compiler%20option%20list.pdf
(e.g. -CcR8R16)
The implementation work on this was done by Zydrunas Gimbutas, not by me.
Zydrunas has authorized me to submit this for inclusion in gcc. Both he
and I have gone through the FSF's copyright assignment process and have
current papers for that on file.
We tested the change by running Kahan's Fortran paranoia tests using all
supported conversions, we ran the LINPACK tests (at all supported
conversions) as well as a number of manually-written conversion tests.
Zydrunas and Andreas
pgp97zRCLKEIX.pgp
Description: PGP signature
Changelog-PR48426
Description: Binary data
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 181224)
+++ gcc/fortran/decl.c (working copy)
@@ -2097,8 +2097,24 @@
return MATCH_ERROR;
}
ts->kind /= 2;
+
}
+ if (ts->type == BT_INTEGER)
+{
+ if( ts->kind == 4 && gfc_option.flag_integer4_kind == 8) ts->kind = 8;
+}
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 8) ts->kind = 8;
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10;
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 4) ts->kind = 4;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16;
+}
+
if (gfc_validate_kind (ts->type, ts->kind, true) < 0)
{
gfc_error ("Old-style type declaration %s*%d not supported at %C",
@@ -2243,6 +2259,22 @@
if(m == MATCH_ERROR)
gfc_current_locus = where;
+
+ if (ts->type == BT_INTEGER)
+{
+ if( ts->kind == 4 && gfc_option.flag_integer4_kind == 8) ts->kind = 8;
+}
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 8) ts->kind = 8;
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10;
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 4) ts->kind = 4;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16;
+}
+
/* Return what we know from the test(s). */
return m;
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h (revision 181224)
+++ gcc/fortran/gfortran.h (working copy)
@@ -2215,6 +2215,9 @@
int flag_default_double;
int flag_default_integer;
int flag_default_real;
+ int flag_integer4_kind;
+ int flag_real4_kind;
+ int flag_real8_kind;
int flag_dollar_ok;
int flag_underscoring;
int flag_second_underscore;
Index: gcc/fortran/lang.opt
===
--- gcc/fortran/lang.opt (revision 181224)
+++ gcc/fortran/lang.opt (working copy)
@@ -394,6 +394,10 @@
Fortran RejectNegative
Assume that the source file is fixed form
+finteger-4-integer-8
+Fortran RejectNegative
+Interpret any 4-byte integer as an 8-byte integer
+
fintrinsic-modules-path
Fortran RejectNegative Joined Separate
Specify where to find the compiled intrinsic modules
@@ -494,6 +498,30 @@
Fortran
Enable range checking during compilation
+freal-4-real-8
+Fortran RejectNegative
+Interpret any 4-byte real as an 8-byte real
+
+freal-4-real-10
+Fortran RejectNegative
+Interpret any 4-byte real as a 10-byte real
+
+freal-4-real-16
+Fortran RejectNegative
+Interpret any 4-byte real as a 16-byte real
+
+freal-8-real-4
+Fortran RejectNegative
+Interpret any 8-byte real as a 4-byte real
+
+freal-8-real-10
+Fortran RejectNegative
+Interpret any 8-byte real as a 10-byte real
+
+freal-8-real-16
+Fortran RejectNegative
+Interpret any 8-byte real as a 16-byte real
+
frealloc-lhs
Fortran
Reallocate the LHS in assignments
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 181224)
+++ gcc/fortran/trans-types.c (working copy)
@@ -362,7 +362,7 @@
unsigned int mode;
int i_index, r_index, kind;
bool saw_i4 = false, saw_i8 = false;
- bool saw_r4 = false, saw_r8
Re: building trunk fails due to C++
On Wed, 9 Nov 2011, Tobias Burnus wrote: > Steve Kargl wrote: > > With top of tree, I'm seeing > > > > % ../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran \ > > --disable-libmudflap --disable-bootstrap > > % gmake > > I think the issue is that by default the trunk is build (stage 1) by the > system C compiler and the next stages (Stage 2 and 3) are build by the > just-build C++ compiler. Thus, the C++ compiler supports the latest C++ > features and also the latest options. > > If one now uses --disable-bootstrap, the system C++ compiler is used to > compile the first and last stage - but if the system C++ compiler is slightly > older, it might not support the newest compiler flags. libitm is a target library, not a host library. Under no circumstances should it ever be built with a C++ compiler other than that newly built as part of GCC. If the C++ compiler is not being built then libitm should not be built. If the C++ compiler is being built, the newly built compiler should be what it used to build libitm. -- Joseph S. Myers jos...@codesourcery.com
[libitm] Work around missing AVX support
Not pretty at all. But given the corresponding irritation in writing assembler
wrapper functions, it seems like it's about a wash.
Tested with and without HAVE_AS_AVX on x86_64-linux.
r~
commit 856dd9f4777fbafce3038e889e9a9bf4815d
Author: Richard Henderson
Date: Wed Nov 9 16:28:45 2011 -0800
libitm: Work around assembler missing AVX insns.
diff --git a/libitm/ChangeLog b/libitm/ChangeLog
index b1629b1..8aeb589 100644
--- a/libitm/ChangeLog
+++ b/libitm/ChangeLog
@@ -1,5 +1,12 @@
2011-11-09 Richard Henderson
+ * acinclude.m4 (LIBITM_CHECK_AS_AVX): New.
+ * configure.ac: Use it.
+ * config.h.in, configure: Rebuild.
+ * config/x86/x86_avx.cc: Handle !HAVE_AS_AVX.
+
+2011-11-09 Richard Henderson
+
* barrier.tpl, memcpy.cc, memset.cc, method-wbetl.cc: Remove file.
* config/alpha/unaligned.h: Remove file.
* config/generic/unaligned.h: Remove file.
diff --git a/libitm/acinclude.m4 b/libitm/acinclude.m4
index 8fcde4b..58fbf42 100644
--- a/libitm/acinclude.m4
+++ b/libitm/acinclude.m4
@@ -95,6 +95,20 @@ AC_DEFUN([LIBITM_CHECK_SIZE_T_MANGLING], [
[Define to the letter to which size_t is mangled.])
])
+dnl Check if as supports AVX instructions.
+AC_DEFUN([LIBITM_CHECK_AS_AVX], [
+case "${target_cpu}" in
+i[3456]86 | x86_64)
+ AC_CACHE_CHECK([if the assembler supports AVX], libitm_cv_as_avx, [
+AC_TRY_COMPILE([], [asm("vzeroupper");],
+ [libitm_cv_as_avx=yes], [libitm_cv_as_avx=no])
+ ])
+ if test x$libitm_cv_as_avx = xyes; then
+AC_DEFINE(HAVE_AS_AVX, 1, [Define to 1 if the assembler supports AVX.])
+ fi
+ ;;
+esac])
+
sinclude(../libtool.m4)
dnl The lines below arrange for aclocal not to bring an installed
dnl libtool.m4 into aclocal.m4, while still arranging for automake to
diff --git a/libitm/config/x86/x86_avx.cc b/libitm/config/x86/x86_avx.cc
index 30420aa..cd20fe2 100644
--- a/libitm/config/x86/x86_avx.cc
+++ b/libitm/config/x86/x86_avx.cc
@@ -22,9 +22,66 @@
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
Re: [RFC] PR 50837
On 11/09/2011 05:45 PM, Paolo Carlini wrote: finish_id_expression is called from cp_parser_primary_expression with a true allow_non_integral_constant_expression_p and the error doesn't occur. Yes, allow_non_integral_constant_expression_p should always be true in C++11. Jason
Re: [RFC] PR 50837
On 11/10/2011 01:43 AM, Jason Merrill wrote: On 11/09/2011 05:45 PM, Paolo Carlini wrote: finish_id_expression is called from cp_parser_primary_expression with a true allow_non_integral_constant_expression_p and the error doesn't occur. Yes, allow_non_integral_constant_expression_p should always be true in C++11. Ah, good (sorry about the badly formatted code, by the way). Now, if I apply the patchlet below, I get this error for template/nontype13.C: nontype13.C:14:5: error: could not convert template argument ‘((Dummy*)this)->Dummy::evil’ to ‘bool’ compared to the current: nontype13.C:14:5: error: ‘void Dummy::evil() [with T = int]’ cannot appear in a constant-expression Seems some sort of diagnostic quality regression... By the way, before receiving your feedback, I was also wondering if the tsubst_expr calls for STATIC_ASSERT should really pass true as integral_constant_expression_p... Paolo. / Index: pt.c === --- pt.c(revision 181246) +++ pt.c(working copy) @@ -13233,7 +13233,7 @@ tsubst_copy_and_build (tree t, decl = finish_id_expression (t, decl, NULL_TREE, &idk, integral_constant_expression_p, - /*allow_non_integral_constant_expression_p=*/false, + /*allow_non_integral_constant_expression_p=*/true, &non_integral_constant_expression_p, /*template_p=*/false, /*done=*/true,
Re: [RFC] PR 50837
On 11/09/2011 07:56 PM, Paolo Carlini wrote: - /*allow_non_integral_constant_expression_p=*/false, + /*allow_non_integral_constant_expression_p=*/true, This should be (cxx_dialect >= cxx0x) rather than true. Jason
