Re: extend fwprop optimization
On Tue, Apr 2, 2013 at 7:43 AM, Wei Mi w...@google.com wrote: I attached the patch.4 based on r197308. r197308 changes shift-and type truncation from define_insn_and_split to define_insn. patch.4 changes ix86_rtx_costs for shift-and type rtx to get the correct cost for the result after the shift-and truncation. With the patch.1 ~ patch.4, fwprop extension could handle the motivational case 1.c attached by removing all the redundent x 63 operations. patch.1~patch.4 regression and bootstrap ok on x86_64-unknown-linux-gnu. Is it ok for trunk? 2013-04-01 Wei Mi w...@google.com * config/i386/i386.c (ix86_rtx_costs): Set proper rtx cost for ashlmode3_mask, *shift_insnmode3_mask and *rotate_insnmode3_mask in i386.md. Patch 4 is OK for mainline and also for release branches that were changed by your previous i386.md patch. Thanks, Uros.
RE: [AArch64] Bitwise adds and subs instructions with shift
Hi Marcus,
Thanks for reviewing the patch and your comments.
I'm not sure how good the coverage is from these test cases
The shift instructions are not generated with the test case since
multiply patterns are generated for the same. Its the same case with
other add and sub instructions which supports both shift and multiply
patterns.The zero extend versions were not generated even though
test cases were implemented for them.
Please find attached the modified patch that implements adds and subs
instructions with multiply for aarch64 target.
Please review the same and let me know if there should be any
modifications in the patch.
Build and tested on aarch64-thunder-elf (using Cavium's internal
simulator). No new regressions.
Thanks,
Naveen
gcc/
2013-04-02 Naveen H.S naveen.hurugalaw...@caviumnetworks.com
* config/aarch64/aarch64.md (*adds_mul_imm_mode): New pattern.
(*subs_mul_imm_mode): New pattern.
gcc/testsuite/
2013-04-02 Naveen H.S naveen.hurugalaw...@caviumnetworks.com
* gcc.target/aarch64/adds1.c: New.
* gcc.target/aarch64/adds2.c: New.
* gcc.target/aarch64/subs1.c: New.
* gcc.target/aarch64/subs2.c: New.--- gcc/config/aarch64/aarch64.md 2013-03-26 12:51:12.180448029 +0530
+++ gcc/config/aarch64/aarch64.md 2013-04-02 11:26:33.008898964 +0530
@@ -1286,6 +1286,40 @@
(set_attr mode SI)]
)
+(define_insn *adds_mul_imm_mode
+ [(set (reg:CC_NZ CC_REGNUM)
+ (compare:CC_NZ
+ (plus:GPI (mult:GPI
+ (match_operand:GPI 1 register_operand r)
+ (match_operand:QI 2 aarch64_pwr_2_mode n))
+ (match_operand:GPI 3 register_operand rk))
+ (const_int 0)))
+ (set (match_operand:GPI 0 register_operand =r)
+ (plus:GPI (mult:GPI (match_dup 1) (match_dup 2))
+ (match_dup 3)))]
+
+ adds\\t%w0, %w3, %w1, lsl %p2
+ [(set_attr v8type alus_shift)
+ (set_attr mode MODE)]
+)
+
+(define_insn *subs_mul_imm_mode
+ [(set (reg:CC_NZ CC_REGNUM)
+ (compare:CC_NZ
+ (minus:GPI (match_operand:GPI 1 register_operand rk)
+ (mult:GPI
+ (match_operand:GPI 2 register_operand r)
+ (match_operand:QI 3 aarch64_pwr_2_mode n)))
+ (const_int 0)))
+ (set (match_operand:GPI 0 register_operand =r)
+ (minus:GPI (match_dup 1)
+ (mult:GPI (match_dup 2) (match_dup 3]
+
+ subs\\t%w0, %w1, %w2, lsl %p3
+ [(set_attr v8type alus_shift)
+ (set_attr mode MODE)]
+)
+
(define_insn *addmode3nr_compare0
[(set (reg:CC_NZ CC_REGNUM)
(compare:CC_NZ
--- gcc/testsuite/gcc.target/aarch64/adds1.c 1970-01-01 05:30:00.0 +0530
+++ gcc/testsuite/gcc.target/aarch64/adds1.c 2013-04-01 13:40:48.189390503 +0530
@@ -0,0 +1,149 @@
+/* { dg-do run } */
+/* { dg-options -O2 --save-temps } */
+
+extern void abort (void);
+
+int
+adds_si_test1 (int a, int b, int c)
+{
+ int d = a + b;
+
+ /* { dg-final { scan-assembler adds\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+ } } */
+ if (d == 0)
+return a + c;
+ else
+return b + d + c;
+}
+
+int
+adds_si_test2 (int a, int b, int c)
+{
+ int d = a + 0xff;
+
+ /* { dg-final { scan-assembler adds\tw\[0-9\]+, w\[0-9\]+, 255 } } */
+ if (d == 0)
+return a + c;
+ else
+return b + d + c;
+}
+
+int
+adds_si_test3 (int a, int b, int c)
+{
+ int d = a + (b 3);
+
+ /* { dg-final { scan-assembler adds\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+, lsl 3 } } */
+ if (d == 0)
+return a + c;
+ else
+return b + d + c;
+}
+
+typedef long long s64;
+
+s64
+adds_di_test1 (s64 a, s64 b, s64 c)
+{
+ s64 d = a + b;
+
+ /* { dg-final { scan-assembler adds\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+ } } */
+ if (d == 0)
+return a + c;
+ else
+return b + d + c;
+}
+
+s64
+adds_di_test2 (s64 a, s64 b, s64 c)
+{
+ s64 d = a + 0xff;
+
+ /* { dg-final { scan-assembler adds\tx\[0-9\]+, x\[0-9\]+, 255 } } */
+ if (d == 0)
+return a + c;
+ else
+return b + d + c;
+}
+
+s64
+adds_di_test3 (s64 a, s64 b, s64 c)
+{
+ s64 d = a + (b 3);
+
+ /* { dg-final { scan-assembler adds\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+, lsl 3 } } */
+ if (d == 0)
+return a + c;
+ else
+return b + d + c;
+}
+
+int main ()
+{
+ int x;
+ s64 y;
+
+ x = adds_si_test1 (29, 4, 5);
+ if (x != 42)
+abort ();
+
+ x = adds_si_test1 (5, 2, 20);
+ if (x != 29)
+abort ();
+
+ x = adds_si_test2 (29, 4, 5);
+ if (x != 293)
+abort ();
+
+ x = adds_si_test2 (1024, 2, 20);
+ if (x != 1301)
+abort ();
+
+ x = adds_si_test3 (35, 4, 5);
+ if (x != 76)
+abort ();
+
+ x = adds_si_test3 (5, 2, 20);
+ if (x != 43)
+abort ();
+
+ y = adds_di_test1 (0x13029ll,
+ 0x32004ll,
+ 0x505050505ll);
+
+ if (y != 0xc75050536)
+abort ();
+
+ y = adds_di_test1 (0x5000500050005ll,
+ 0x2111211121112ll,
+ 0x02020ll);
+ if (y != 0x9222922294249)
+abort ();
+
+ y = adds_di_test2 (0x13029ll,
+ 0x32004ll,
+ 0x505050505ll);
+ if (y != 0x955050631)
+abort ();
+
+ y = adds_di_test2 (0x130002900ll,
+ 0x32004ll,
+ 0x505050505ll);
+ if (y !=
Re: [rtl, i386] vec_merge simplification
Thanks, here is a version taking into account all your comments, and which still passes bootstrap+testsuite on x86_64-linux-gnu. I am not completely sure if there is a point checking !side_effects_p (op1) after rtx_equal_p (op0, op1), but I am still doing it as it seems safe. It's also done in other cases (IOR, XOR, AND, etc) where we return the first operand after having found out that the second operand is equal to it. If the semantics of VEC_MERGE is to evaluate its operands, then they always need to be evaluated, whatever the result. gcc/ * simplify-rtx.c (simplify_binary_operation_1) VEC_SELECT: Handle VEC_MERGE. (simplify_ternary_operation) VEC_MERGE: Use unsigned HOST_WIDE_INT for masks. Test for side effects. Handle nested VEC_MERGE. Handle equal arguments. OK for mainline, thanks. -- Eric Botcazou
Re: [rtl, i386] vec_merge simplification
On Tue, 2 Apr 2013, Eric Botcazou wrote: Thanks, here is a version taking into account all your comments, and which still passes bootstrap+testsuite on x86_64-linux-gnu. I am not completely sure if there is a point checking !side_effects_p (op1) after rtx_equal_p (op0, op1), but I am still doing it as it seems safe. It's also done in other cases (IOR, XOR, AND, etc) where we return the first operand after having found out that the second operand is equal to it. If the semantics of VEC_MERGE is to evaluate its operands, then they always need to be evaluated, whatever the result. Thanks, I should have checked the other uses indeed... I got confused because at tree level, operand_equal_p implies that there are no side effects. -- Marc Glisse
Re: [rtl, i386] vec_merge simplification
By the way, shouldn't this be: unsigned HOST_WIDE_INT mask = ((unsigned HOST_WIDE_INT) 2 (n_elts - 1)) - 1; so it doesn't cause undefined behavior for V64QI? You're right, but I think that we'd rather write: if (n_elts == HOST_BITS_PER_WIDE_INT) mask = -1; else mask = ((unsigned HOST_WIDE_INT) 1 n_elts) - 1; in that case. -- Eric Botcazou
Re: [RTL] Canonicalize commutative operations more
Well, the goal was to have arbitrary canonicalization for all cases where precise rules are not already provided. In (a8)|(b24), there is no obvious reason why lshift should have higher or lower priority than rshift, but we don't want to have to write patterns with both orders in the target .md files. In v[0]+v[1] (v is a V2DF), it is likewise preferable if we know in which order the operands will appear, but I don't care what that order is (note that ordering this one requires a refinement that I didn't include in this first version of the patch). And this way we don't have to refine the order all the time, we just check what order this arbitrary rule generates and write the pattern accordingly. The question is: do we really need to canonicalize everything? The more you canonicalize, the more internal shuffling you will get in the middle-end for a practical benefit that might be elusive in most cases. I am not sure about adding just a few rules. If I just say that lshift is stronger than rshift, the relation is not an order (transitive) anymore. Why? Can't you give them precedences in commutative_operand_precedence that preserve the transitivity? And it might already have some of the drawbacks you and Jakub fear (I don't have a good understanding of those, I may be wrong). The fear (at least mine) is that, by canonicalizing everything, you will make changes behind the back of back-ends that could disable some of their patterns silently. This is also a concern for new canonicalization rules, but at least you can reasonably audit the back-ends for every new rule. If there is a nice way to instead try permutations (note that for a pattern involving k commutative operations, there are 2^k versions), I am just as happy with that. No, of course, canonicalization is desirable. By the way, even if we don't take the canonicalization (just ignore the line comparing GET_CODEs), do we still want the refactoring that this patch brings, or is the current interface better? I think that the current interface makes it clear that you need to tweak the precedence in order to change the canonicalization (thus preserving the transitivity). Btw, there is something to fix in the head comment of commutative_operand_precedence because I cannot make sense of it. -- Eric Botcazou
Re: RFC: color diagnostics markers
On Sun, Mar 31, 2013 at 10:01:21PM +0200, Manuel López-Ibáñez wrote: The following patch implements an option that allows printing the diagnostics markers (error:, warning:, note:) in different colors (red, magenta, and green, respectively). Thanks for working on that. I followed the implementation of GNU grep but we cannot directly use their code, since they only care about printing to stdout, while we need to create strings on the fly. This patch only supports POSIX terminals, but grep has code for Windows, so I can implement that if wished. Grep also supports configuring the colors via an environment variable, so I can extend the patch in that way if wished. Yeah, IMHO we definitely want to support GCC_COLORS env var or similar, with same syntax as e.g. GREP_COLORS, but with different names of the (two letter?) color names. This patch only allows two options enable/disable colors (and defaults to disabled), but grep has auto/never/always, and I can easily extend the patch in that way. IMO we also want that autodetection and default to auto. I think we should do more than what your patch does, in particular I'd say we should add some syntax to request colors in the warning*/error*/sorry* etc. format strings (%c, %C, %o, %O seem to be taken, perhaps %rXY where XY would be the two letter name of the color that GCC_COLORS accepts as the lhs in the : separated list), then the diagnostics markers could be just the format string to process to switch to that color %rer for DK_ERROR, %rwa for DK_WARNING, %rno for DK_NOTE, then have another color for the caret stuff, another that could be used on immediately after % or after the quote starting %qD etc. and we'd return back to normal color right before the closing quote (% or implicit). Perhaps in the future without too much effort we could add some colors e.g. to the expression printers, when printing some expression we could highligh keywords in it, var names etc. But for the start I'd hope highlighting error:/warning:/note:, quoted text, caret lines and perhaps also the introductory lines (In file included from, In macro ..., etc.), it could be enough. Also, please watch the GCC indentation rules in your code. Jakub
Re: [patch] trivial replacements for SET_INSN_DELETED and BLOCK_FOR_INSN as lhs
Using set_block_for_insn instead of using BLOCK_FOR_INSN is the proper way. Yes, but BLOCK_FOR_INSN as accessor around INSN_BASIC_BLOCK is ugly and a bit misleading. Either keep BLOCK_FOR_INSN or make the full change (the number of occurrences of BLOCK_FOR_INSN in the back-ends is surprisingly very small). -- Eric Botcazou
Re: [patch] PR56729
On Fri, Mar 29, 2013 at 1:05 PM, Steven Bosscher stevenb@gmail.com wrote: Hello, It looks like there are places in the middle end that use remove_insn on insns that are not actually emitted. This breaks the assert I added in df_insn_delete. The patch disables the assert for now. The comment before the assert is now even messier than before but I think it's better to explain why the assert cannot work than to remove the comment and the assert altogether. Bootstrappedtested on powerpc64-unknown-linux-gnu (also tested 32bits ppc). OK for trunk? Ok. Thanks, Richard. Ciao! Steven PR middle-end/56729 * df-scan.c (df_insn_delete): Disable failing assert. Index: df-scan.c === --- df-scan.c (revision 197180) +++ df-scan.c (working copy) @@ -1158,8 +1158,17 @@ df_insn_delete (rtx insn) In any case, we expect BB to be non-NULL at least up to register allocation, so disallow a non-NULL BB up to there. Not perfect but better than nothing... */ - + /* ??? bb can also be NULL if lower-subreg.c:resolve_simple_mov emits + an insn into a sequence and then does delete_insn on it. Not sure + if that makes sense, but for now it means this assert cannot work. + See PR56738. + Disable for now but revisit before the end of GCC 4.9 stage1. */ +#if 0 gcc_checking_assert (bb != NULL || reload_completed); +#else + if (bb == NULL) +return; +#endif df_grow_bb_info (df_scan); df_grow_reg_info ();
Re: C++ PATCH: Use VAR_P instead of direct TREE_CODE (t) == VAR_DECL
On Fri, Mar 29, 2013 at 6:02 PM, Gabriel Dos Reis g...@axiomatics.org wrote: Paolo Carlini paolo.carl...@oracle.com writes: | Hi, | | On 03/29/2013 04:59 PM, Gabriel Dos Reis wrote: | This patch introduces the predicate VAR_P and use it in place of direct | | TREE_CODE (t) == VAR_DECL | | It improves readability and makes predicates easier to follow. | Tested on an x86_64-suse-linux. Applying to trunk. | Thanks. | | Do you think it would also make sense to consistently use in C++ | front-end TYPE_PTR_P instead of TREE_CODE (t) == POINTER_TYPE? It's | something I noticed a while ago when I cleaned-up predicated related | to pointers and occurred to me again now that you are doing some of | this kind of work. If you like I can do this bit. | | Thanks, | Paolo. Yes, you are absolutely right. Thanks for volunteering. Sorry for chiming in late - but VAR_P loses the fact that we are checking for a decl ... VAR_DECL_P would be more like following existing practice (otherwise we can shorten VAR_OR_FUNCTION_DECL_P to VAR_OR_FUNCTION_P for example). As for further cleanups we seem to have a few IS_... macros as well (one even IS_..._P). Richard. -- Gaby
Re: RFC: color diagnostics markers
On Tue, Apr 2, 2013 at 4:14 AM, Jakub Jelinek ja...@redhat.com wrote: Yeah, IMHO we definitely want to support GCC_COLORS env var or similar, with same syntax as e.g. GREP_COLORS, but with different names of the (two letter?) color names. Agreed. This patch only allows two options enable/disable colors (and defaults to disabled), but grep has auto/never/always, and I can easily extend the patch in that way. IMO we also want that autodetection and default to auto. I disagree. For this release, I think the default should be off. We need more at least one major release in the wild before we decide on what colors should be the default. (there is no reason why the default should be biased towards light background as opposed to dark background.) Diagnostics have become unreadable largely because we have succumbed to the idea that everything new should be on by default. These days, when I may a simple mistakes where an argument isn't of the right type, I get drawn under a deluge of explanatory notes supposed to help me understand why a function and an implicit conversion to a type I never heard off was not appropriate. -- Gaby
Re: C++ PATCH: Use VAR_P instead of direct TREE_CODE (t) == VAR_DECL
On Tue, Apr 2, 2013 at 4:26 AM, Richard Biener richard.guent...@gmail.com wrote: On Fri, Mar 29, 2013 at 6:02 PM, Gabriel Dos Reis g...@axiomatics.org wrote: Paolo Carlini paolo.carl...@oracle.com writes: | Hi, | | On 03/29/2013 04:59 PM, Gabriel Dos Reis wrote: | This patch introduces the predicate VAR_P and use it in place of direct | | TREE_CODE (t) == VAR_DECL | | It improves readability and makes predicates easier to follow. | Tested on an x86_64-suse-linux. Applying to trunk. | Thanks. | | Do you think it would also make sense to consistently use in C++ | front-end TYPE_PTR_P instead of TREE_CODE (t) == POINTER_TYPE? It's | something I noticed a while ago when I cleaned-up predicated related | to pointers and occurred to me again now that you are doing some of | this kind of work. If you like I can do this bit. | | Thanks, | Paolo. Yes, you are absolutely right. Thanks for volunteering. Sorry for chiming in late - but VAR_P loses the fact that we are checking for a decl ... VAR_DECL_P would be more like following existing practice (otherwise we can shorten VAR_OR_FUNCTION_DECL_P to VAR_OR_FUNCTION_P for example). As for further cleanups we seem to have a few IS_... macros as well (one even IS_..._P). Richard. If we are checking for a VAR, we necessarily checking for a VAR decl.. The purpose of the macro is make the predicates more readable. I would not mind having VAR_OR_FUNCTION_P instead. Yes, we should get rid of the IS_. -- Gaby
Re: [patch] trivial replacements for SET_INSN_DELETED and BLOCK_FOR_INSN as lhs
On Tue, Apr 2, 2013 at 11:17 AM, Eric Botcazou wrote: Using set_block_for_insn instead of using BLOCK_FOR_INSN is the proper way. Yes, but BLOCK_FOR_INSN as accessor around INSN_BASIC_BLOCK is ugly and a bit misleading. True, I don't like that bit very much myself, either. But I expected more resistance for the full change ;-) Either keep BLOCK_FOR_INSN or make the full change (the number of occurrences of BLOCK_FOR_INSN in the back-ends is surprisingly very small). Right. OK if I call it get_block_for_insn() and make the replacements? Ciao! Steven
Re: RFC: color diagnostics markers
On Tue, Apr 02, 2013 at 04:26:37AM -0500, Gabriel Dos Reis wrote: IMO we also want that autodetection and default to auto. I disagree. For this release, I think the default should be off. We need more I think a year is plenty of time to agree on the default color scheme (and yes, the default certainly has to be usable/readable both on black-on-white and white-on-black terminals), but at least having an auto/never/always option allows one to choose, we can discuss what will be the default later on. The default could very well also be never if GCC_COLORS isn't in environment and auto if it is, or similar. Jakub
Re: Constant folding of VEC_COND_EXPR
On Sun, Mar 31, 2013 at 7:20 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 31 Mar 2013, Andrew Pinski wrote:
On Sun, Mar 31, 2013 at 6:31 AM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
this adds constant folding of VEC_COND_EXPR at the tree level by
forwarding
to the VEC_PERM_EXPR code (a merge is a special case of a permutation).
The
CONSTRUCTOR case may be unreachable for now (it will probably need an
extra
piece of code in tree-ssa-forwprop.c), but it seems better to add it at
the
same time.
bootstrap+testsuite on x86_64-linux-gnu.
2013-03-31 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/56790
* fold-const.c (fold_ternary_loc) VEC_COND_EXPR: Add constant
folding.
testsuite/
* g++.dg/ext/pr56790-1.C: New testcase.
--
Marc Glisse
Index: gcc/testsuite/g++.dg/ext/pr56790-1.C
===
--- gcc/testsuite/g++.dg/ext/pr56790-1.C(revision 0)
+++ gcc/testsuite/g++.dg/ext/pr56790-1.C(revision 0)
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-ccp1 } */
+
+typedef long vec __attribute__ ((vector_size (2 * sizeof (long;
+
+vec f (void)
+{
+ vec a = { 5, 7 };
+ vec b = { 11, 13 };
+ vec m = { -1, 0 };
+ return m ? a : b;
+}
+
+/* { dg-final { scan-tree-dump { 5, 13 } ccp1 } } */
+/* { dg-final { scan-tree-dump-not VEC_COND_EXPR ccp1 } } */
+/* { dg-final { cleanup-tree-dump ccp1 } } */
Property changes on: gcc/testsuite/g++.dg/ext/pr56790-1.C
___
Added: svn:keywords
+ Author Date Id Revision URL
Added: svn:eol-style
+ native
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 197284)
+++ gcc/fold-const.c(working copy)
@@ -13917,20 +13917,43 @@ fold_ternary_loc (location_t loc, enum t
|| VOID_TYPE_P (type)))
return pedantic_non_lvalue_loc (loc, tem);
return NULL_TREE;
}
else if (TREE_CODE (arg0) == VECTOR_CST)
{
if (integer_all_onesp (arg0))
return pedantic_omit_one_operand_loc (loc, type, arg1, arg2);
if (integer_zerop (arg0))
return pedantic_omit_one_operand_loc (loc, type, arg2, arg1);
+
+ if ((TREE_CODE (arg1) == VECTOR_CST
+ || TREE_CODE (arg1) == CONSTRUCTOR)
+ (TREE_CODE (arg2) == VECTOR_CST
+ || TREE_CODE (arg2) == CONSTRUCTOR))
+ {
+ unsigned int nelts = TYPE_VECTOR_SUBPARTS (type), i;
+ unsigned char *sel = XALLOCAVEC (unsigned char, nelts);
+ gcc_assert (nelts == VECTOR_CST_NELTS (arg0));
+ for (i = 0; i nelts; i++)
+ {
+ tree val = VECTOR_CST_ELT (arg0, i);
+ if (integer_all_onesp (val))
+ sel[i] = i;
+ else if (integer_zerop (val))
+ sel[i] = nelts + i;
+ else
+ gcc_unreachable ();
I think this gcc_unreachable here is incorrect as it could cause an
internal compiler error for target dependent code
Try for:
typedef long vec __attribute__ ((vector_size (2 * sizeof (long;
vec f (void)
{
vec a = { 5, 7 };
vec b = { 11, 13 };
vec m = { 3, 2 };
return m ? a : b;
}
I think for the above case we don't want to do any constant folding.
For vectors, we decided in 4.8 that x ? y : z would mean vec_cond_expr x !=
0, y, z, and that is what the C++ front-end generates, so your testcase
works fine and returns a.
Re-reading doc/generic.texi, I see:
If an element of the first operand evaluates to a zero value, the
corresponding element of the result is taken from the third operand. If it
evaluates to a minus one value, it is taken from the second operand. It
should never evaluate to any other value currently, but optimizations should
not rely on that property.
Well, at least I am not silently relying on that property, but it looks like
you are right and I am supposed to leave those (impossible) values alone.
Yes, in general just don't fold if you hit unexpected things (return NULL_TREE).
Ok with that change.
Thanks,
Richard.
--
Marc Glisse
Re: patch to fix constant math - first small patch - patch ping for the next stage 1
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richard,
I was able to add everything except for the checking asserts.While I
think that this is a reasonable idea, it is difficult to add that to a
function that is defined in hwint.h because of circular includes. I could
move this another file (though this appears to be the logical correct place
for it), or we can do without the asserts.
The context is that [sz]ext_hwi is that are used are over the compiler but
are generally written out long. The wide-int class uses them also, but
wide-int did not see like the right place for them to live and i believe
that you suggested that i move them.
ok to commit, or do you have a suggested resolution to the assert issue?
Yes, do
#ifdef ENABLE_CHECKING
extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
#else
+/* Sign extend SRC starting from PREC. */
+
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+{
int shift = HOST_BITS_PER_WIDE_INT - prec;
+ return (src shift) shift;
+}
+}
#endif
and for ENABLE_CHECKING only provide an out-of-line implementation
in hwint.c. That's how we did it with abs_hwi (well, we just do not provide
an inline variant there - that's another possibility).
Note that hwint.h is always included after config.h so the ENABLE_CHECKING
definition should be available.
Richard.
kenny
On 03/27/2013 10:13 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the first of my wide int patches with joseph's comments and the
patch rot removed.
I would like to get these pre approved for the next stage 1.
+ int shift = HOST_BITS_PER_WIDE_INT - (prec
(HOST_BITS_PER_WIDE_INT - 1));
I think this should gcc_checking_assert that prec is not out of range
(any reason why prec is signed int and not unsigned int?) rather than
ignore bits in prec.
+static inline HOST_WIDE_INT
+zext_hwi (HOST_WIDE_INT src, int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+return src (((HOST_WIDE_INT)1
+ (prec (HOST_BITS_PER_WIDE_INT - 1))) - 1);
+}
likewise. Also I'm not sure I agree about the signedness of the result /
src.
zext_hwi (-1, HOST_BITS_PER_WIDE_INT) 0 is true which is odd.
The patch misses context of uses, so I'm not sure what the above functions
are intended to do.
Richard.
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT h
This may cause problems on hosts not supporting %hd (MinGW?), and
there's
no real need for using h here given the promotion of short to int; you
can just use (rather than e.g. needing special handling in
xm-mingw32.h
like is done for HOST_LONG_LONG_FORMAT).
Re: [patch] Remove unused ivtype_map symbols from sese.[hc]
On Mon, Apr 1, 2013 at 12:19 AM, Lawrence Crowl cr...@googlers.com wrote:
Remove unused symbols related to ivtype_map. This map does not appear to
exist and I see no evidence of its removal in the ChangeLog.
Tested on x86_64.
Okay for trunk?
Ok.
Thanks,
Richard.
Index: gcc/ChangeLog
2013-03-31 Lawrence Crowl cr...@google.com
* sese.h (struct ivtype_map_elt_s): Remove unused.
(extern debug_ivtype_map): Remove unused.
(extern eq_ivtype_map_elts): Remove unused.
* sese.c (debug_ivtype_map): Removed unused.
(debug_ivtype_map_1): Removed unused.
(debug_ivtype_elt): Remove unused.
(eq_ivtype_map_elts): Remove unused.
Index: gcc/sese.c
===
--- gcc/sese.c (revision 197272)
+++ gcc/sese.c (working copy)
@@ -83,47 +83,6 @@ eq_rename_map_elts (const void *e1, cons
-/* Print to stderr the element ELT. */
-
-static void
-debug_ivtype_elt (ivtype_map_elt elt)
-{
- fprintf (stderr, (%s, , elt-cloog_iv);
- print_generic_expr (stderr, elt-type, 0);
- fprintf (stderr, )\n);
-}
-
-/* Helper function for debug_ivtype_map. */
-
-static int
-debug_ivtype_map_1 (void **slot, void *s ATTRIBUTE_UNUSED)
-{
- struct ivtype_map_elt_s *entry = (struct ivtype_map_elt_s *) *slot;
- debug_ivtype_elt (entry);
- return 1;
-}
-
-/* Print to stderr all the elements of MAP. */
-
-DEBUG_FUNCTION void
-debug_ivtype_map (htab_t map)
-{
- htab_traverse (map, debug_ivtype_map_1, NULL);
-}
-
-/* Compares database elements E1 and E2. */
-
-int
-eq_ivtype_map_elts (const void *e1, const void *e2)
-{
- const struct ivtype_map_elt_s *elt1 = (const struct ivtype_map_elt_s *) e1;
- const struct ivtype_map_elt_s *elt2 = (const struct ivtype_map_elt_s *) e2;
-
- return (elt1-cloog_iv == elt2-cloog_iv);
-}
-
-
-
/* Record LOOP as occurring in REGION. */
static void
Index: gcc/sese.h
===
--- gcc/sese.h (revision 197272)
+++ gcc/sese.h (working copy)
@@ -275,17 +275,6 @@ new_rename_map_elt (tree old_name, tree
return res;
}
-/* Structure containing the mapping between the CLooG's induction
- variable and the type of the old induction variable. */
-typedef struct ivtype_map_elt_s
-{
- tree type;
- const char *cloog_iv;
-} *ivtype_map_elt;
-
-extern void debug_ivtype_map (htab_t);
-extern int eq_ivtype_map_elts (const void *, const void *);
-
/* Free and compute again all the dominators information. */
static inline void
--
Lawrence Crowl
Re: C++ PATCH: Use VAR_P instead of direct TREE_CODE (t) == VAR_DECL
Hi,
On 04/02/2013 11:30 AM, Gabriel Dos Reis wrote:
[]
Sorry for chiming in late - but VAR_P loses the fact that we are checking
for a decl ... VAR_DECL_P would be more like following existing practice
(otherwise we can shorten VAR_OR_FUNCTION_DECL_P to
VAR_OR_FUNCTION_P for example). As for further cleanups we seem
to have a few IS_... macros as well (one even IS_..._P).
Richard.
If we are checking for a VAR, we necessarily checking for a VAR decl..
The purpose of the macro is make the predicates more readable.
I would not mind having VAR_OR_FUNCTION_P instead.
Yes, we should get rid of the IS_.
For example we have:
#define IS_OVERLOAD_TYPE(T) TAGGED_TYPE_P (T)
shall we keep only one? The below - untested - gets rid of the latter
and renames the former to OVERLOAD_TYPE_P.
Paolo.
/
Index: call.c
===
--- call.c (revision 197341)
+++ call.c (working copy)
@@ -5097,8 +5097,8 @@ build_new_op_1 (location_t loc, enum tree_code cod
if (code == COND_EXPR)
/* Use build_conditional_expr instead. */
gcc_unreachable ();
- else if (! IS_OVERLOAD_TYPE (TREE_TYPE (arg1))
- (! arg2 || ! IS_OVERLOAD_TYPE (TREE_TYPE (arg2
+ else if (! OVERLOAD_TYPE_P (TREE_TYPE (arg1))
+ (! arg2 || ! OVERLOAD_TYPE_P (TREE_TYPE (arg2
goto builtin;
if (code == POSTINCREMENT_EXPR || code == POSTDECREMENT_EXPR)
Index: class.c
===
--- class.c (revision 197341)
+++ class.c (working copy)
@@ -1319,7 +1319,7 @@ struct abi_tag_data
static tree
find_abi_tags_r (tree *tp, int */*walk_subtrees*/, void *data)
{
- if (!TAGGED_TYPE_P (*tp))
+ if (!OVERLOAD_TYPE_P (*tp))
return NULL_TREE;
if (tree attributes = lookup_attribute (abi_tag, TYPE_ATTRIBUTES (*tp)))
Index: cp-tree.h
===
--- cp-tree.h (revision 197341)
+++ cp-tree.h (working copy)
@@ -1233,7 +1233,7 @@ enum languages { lang_c, lang_cplusplus, lang_java
/* Nonzero if NODE has no name for linkage purposes. */
#define TYPE_ANONYMOUS_P(NODE) \
- (TAGGED_TYPE_P (NODE) ANON_AGGRNAME_P (TYPE_LINKAGE_IDENTIFIER (NODE)))
+ (OVERLOAD_TYPE_P (NODE) ANON_AGGRNAME_P (TYPE_LINKAGE_IDENTIFIER (NODE)))
/* The _DECL for this _TYPE. */
#define TYPE_MAIN_DECL(NODE) (TYPE_STUB_DECL (TYPE_MAIN_VARIANT (NODE)))
@@ -1270,9 +1270,8 @@ enum languages { lang_c, lang_cplusplus, lang_java
/* Keep these checks in ascending code order. */
#define RECORD_OR_UNION_CODE_P(T) \
((T) == RECORD_TYPE || (T) == UNION_TYPE)
-#define TAGGED_TYPE_P(T) \
+#define OVERLOAD_TYPE_P(T) \
(CLASS_TYPE_P (T) || TREE_CODE (T) == ENUMERAL_TYPE)
-#define IS_OVERLOAD_TYPE(T) TAGGED_TYPE_P (T)
/* True if this a Java type, defined in 'extern Java'. */
#define TYPE_FOR_JAVA(NODE) TYPE_LANG_FLAG_3 (NODE)
Index: decl.c
===
--- decl.c (revision 197341)
+++ decl.c (working copy)
@@ -4182,7 +4182,7 @@ void
warn_misplaced_attr_for_class_type (source_location location,
tree class_type)
{
- gcc_assert (TAGGED_TYPE_P (class_type));
+ gcc_assert (OVERLOAD_TYPE_P (class_type));
warning_at (location, OPT_Wattributes,
attribute ignored in declaration
@@ -4497,7 +4497,7 @@ start_decl (const cp_declarator *declarator,
/* If this is a typedef that names the class for linkage purposes
(7.1.3p8), apply any attributes directly to the type. */
if (TREE_CODE (decl) == TYPE_DECL
- TAGGED_TYPE_P (TREE_TYPE (decl))
+ OVERLOAD_TYPE_P (TREE_TYPE (decl))
decl == TYPE_NAME (TYPE_MAIN_VARIANT (TREE_TYPE (decl
flags = ATTR_FLAG_TYPE_IN_PLACE;
else
@@ -10938,7 +10938,7 @@ type_is_deprecated (tree type)
return type;
/* Do warn about using typedefs to a deprecated class. */
- if (TAGGED_TYPE_P (type) type != TYPE_MAIN_VARIANT (type))
+ if (OVERLOAD_TYPE_P (type) type != TYPE_MAIN_VARIANT (type))
return type_is_deprecated (TYPE_MAIN_VARIANT (type));
code = TREE_CODE (type);
Index: decl2.c
===
--- decl2.c (revision 197341)
+++ decl2.c (working copy)
@@ -868,7 +868,7 @@ grokfield (const cp_declarator *declarator,
/* If this is a typedef that names the class for linkage purposes
(7.1.3p8), apply any attributes directly to the type. */
- if (TAGGED_TYPE_P (TREE_TYPE (value))
+ if (OVERLOAD_TYPE_P (TREE_TYPE (value))
value == TYPE_NAME (TYPE_MAIN_VARIANT (TREE_TYPE (value
attrflags = ATTR_FLAG_TYPE_IN_PLACE;
@@ -1934,7 +1934,7 @@ min_vis_r (tree *tp, int *walk_subtrees, void *dat
{
*walk_subtrees = 0;
}
- else if (TAGGED_TYPE_P (*tp)
+ else if (OVERLOAD_TYPE_P (*tp)
Re: [patch] trivial replacements for SET_INSN_DELETED and BLOCK_FOR_INSN as lhs
True, I don't like that bit very much myself, either. But I expected more resistance for the full change ;-) Possibly. You might really want to wait until the end of the week. :-) Right. OK if I call it get_block_for_insn() and make the replacements? get_block_for_insn will break formatting... just block_for_insn I'd say. -- Eric Botcazou
[PATCH, ARM, iWMMXT] PR target/54338 - Include IWMMXT_GR_REGS in ALL_REGS
Hi, According to Vladimir Makarov's analysis, the root cause of PR target/54338 is that ALL_REGS doesn't contain IWMMXT_GR_REGS in REG_CLASS_CONTENTS. It seems there is no reason to exclude the IWMMXT_GR_REGS from ALL_REGS as IWMMXT_GR_REGS are the real registers. This patch simply makes ALL_REGS include IWMMXT_GR_REGS to fix this PR. Since the test case gcc.target/arm/mmx-2.c would fail for the same reason and become pass with this fix, no extra test case need to be add. Pass arm.exp test. Patch attached. ChangeLog 2013-04-02 Xinyu Qi x...@marvell.com * config/arm/arm.h (REG_CLASS_CONTENTS): Include IWMMXT_GR_REGS in ALL_REGS. OK? Thanks, Xinyu IWMMXT_GR_REGS.diff Description: IWMMXT_GR_REGS.diff
Re: [PATCH, ARM, iWMMXT] PR target/54338 - Include IWMMXT_GR_REGS in ALL_REGS
On 04/02/13 10:40, Xinyu Qi wrote: Hi, According to Vladimir Makarov's analysis, the root cause of PR target/54338 is that ALL_REGS doesn't contain IWMMXT_GR_REGS in REG_CLASS_CONTENTS. It seems there is no reason to exclude the IWMMXT_GR_REGS from ALL_REGS as IWMMXT_GR_REGS are the real registers. This patch simply makes ALL_REGS include IWMMXT_GR_REGS to fix this PR. Since the test case gcc.target/arm/mmx-2.c would fail for the same reason and become pass with this fix, no extra test case need to be add. Pass arm.exp test. Patch attached. Testing just with arm.exp is not enough. Ok if no regressions running the entire regression testsuite for C and C++ for arm*-*-*eabi with an iwmmxt configuration. Thanks Ramana
Re: C++ PATCH: Use VAR_P instead of direct TREE_CODE (t) == VAR_DECL
On Tue, Apr 2, 2013 at 4:44 AM, Paolo Carlini paolo.carl...@oracle.com wrote: Hi, On 04/02/2013 11:30 AM, Gabriel Dos Reis wrote: [] Sorry for chiming in late - but VAR_P loses the fact that we are checking for a decl ... VAR_DECL_P would be more like following existing practice (otherwise we can shorten VAR_OR_FUNCTION_DECL_P to VAR_OR_FUNCTION_P for example). As for further cleanups we seem to have a few IS_... macros as well (one even IS_..._P). Richard. If we are checking for a VAR, we necessarily checking for a VAR decl.. The purpose of the macro is make the predicates more readable. I would not mind having VAR_OR_FUNCTION_P instead. Yes, we should get rid of the IS_. For example we have: #define IS_OVERLOAD_TYPE(T) TAGGED_TYPE_P (T) shall we keep only one? The below - untested - gets rid of the latter and renames the former to OVERLOAD_TYPE_P. Paolo. / That is a sensible choice. OK, it passes testing.
Ping: [PATCH, ARM][1 of 2] Add epilogue dwarf info for shrink-wrap
Ping. On 21 March 2013 14:58, Zhenqiang Chen zhenqiang.c...@linaro.org wrote: Hi, When shrink-wrap is enabled, the returns from simple-return path and normal return path can be merged. The code is like: tst ... / \ | push ... | ... | pop ... \ / bx lr If the dwarf info after pop ... is incorrect, the dwarf checks will fail at dwarf2cfi.c: function maybe_record_trace_start. /* We ought to have the same state incoming to a given trace no matter how we arrive at the trace. Anything else means we've got some kind of optimization error. */ gcc_checking_assert (cfi_row_equal_p (cur_row, ti-beg_row)); The patch is to add epilogue dwarf info to make sure: Before bx lr, * All registers saved in stack had been restored. * .cfi_def_cfa_offset 0 * .cfi_def_cfa_register is sp even if frame_pointer_needed Boot strapped and no make check regression. Is it OK? Thanks! -Zhenqiang ChangeLog: 2013-03-21 Zhenqiang Chen zhenqiang.c...@linaro.org * config/arm/arm.c (arm_add_cfa_adjust_cfa_note): New added. (arm_emit_multi_reg_pop): Add REG_CFA_ADJUST_CFA notes. (arm_emit_vfp_multi_reg_pop): Likewise. (thumb2_emit_ldrd_pop): Likewise. (arm_expand_epilogue): Add misc REG_CFA notes. (arm_unwind_emit): Skip REG_CFA_ADJUST_CFA and REG_CFA_RESTORE.
Re: [PATCH, ARM][2 of 2] Enable shrink-wrap for ARM
On Thu, Mar 21, 2013 at 7:03 AM, Zhenqiang Chen zhenqiang.c...@linaro.org wrote: Hi, The patch is to enable shrink-wrap for TARGET_ARM and TARGET_THUMB2. Bootstrapped and no make check regression. All previous Linaro shrink-wrap bugs (http://goo.gl/6fGg5) are verified. Is it OK? The tests should be part of the patch attached and not just added as separate files in your patch submission. regards Ramana Thanks! -Zhenqiang ChangeLog: 2013-03-21 Bernd Schmidt ber...@codesourcery.com Zhenqiang Chen zhenqiang.c...@linaro.org * config/arm/arm-protos.h: Add and update function protos. * config/arm/arm.c (use_simple_return_p): New added. (thumb2_expand_return): Check simple_return flag. * config/arm/arm.md: Add simple_return and conditional simple_return. * config/arm/iterators.md: Add iterator for return and simple_return. testsuite/ChangeLog: 2013-03-21 Zhenqiang Chen zhenqiang.c...@linaro.org * gcc.dg/shrink-wrap-alloca.c: New added. * gcc.dg/shrink-wrap-pretend.c: New added. * gcc.dg/shrink-wrap-sibcall.c: New added.
[PATCH] Redesign pthread in LIB_SPEC for systems without libpthread (was: [PATCH, libgomp, libatomic] Fix configure for systems without libpthread)
On Mon, Apr 1, 2013 at 7:07 PM, Pavel Chupin pavel.v.chu...@gmail.com wrote: On Android pthread is integrated into libc. Attached patch fixes configures for this case by trying to build test without -pthread -lpthread. 2013-04-01 Pavel Chupin pavel.v.chu...@intel.com Fix libatomic and libgomp configure for systems without libpthread * libatomic/configure.ac: Add test without -pthread -lpthread. * libgomp/configure.ac: Ditto. * libatomic/configure: Regenerate. * libgomp/configure: Regenerate. OK for trunk? I think I made a better fix: 2013-04-02 Pavel Chupin pavel.v.chu...@intel.com Redesign pthread in LIB_SPEC for systems without libpthread * gcc/config/gnu-user.h: Remove pthread from GNU_USER_TARGET_LIB_SPEC but keep in default LIB_SPEC * gcc/config/linux-android.h: Add pthread to ANDROID_LIB_SPEC Is it OK for trunk? -- Pavel Chupin Intel Corporation 0001-Redesign-pthread-in-LIB_SPEC-for-systems-without-lib.patch Description: Binary data
[patch] replace a bunch of equivalent checks for asm operands with a new function
Hello,
This idiom: if (GET_CODE (body) == ASM_INPUT || asm_noperands (body)
= 0) appears in multiple places. There's even one place where the
idiom above is used in reverse (making the GET_CODE... check
redundant). A few more places to the equivalent by checking
extract_asm_operands != NULL.
It made sense to me, at least, to replace those equivalent checks with
a new function: insn_with_asm_operands_p().
Bootstrappedtested on ia64-unknown-linux-gnu and powerpc64-unknown-linux-gnu.
OK for trunk?
Ciao!
Steven
* rtl.h (insn_with_asm_operands_p): New prototype.
* rtlanal.c (insn_with_asm_operands_p): New function.
* cfgrtl.c (rtl_split_edge): Use it instead of extract_asm_operands.
(fixup_reorder_chain): Likewise.
* compare-elim.c (arithmetic_flags_clobber_p): Likewise.
* dwarf2out.c (dwarf2out_var_location): Use it instead of open-coded
equivalent checks.
* final.c (get_attr_length_1, shorten_branches): Likewise.
* haifa-sched.c (prune_ready_list, schedule_block): Likewise.
* hw-doloop.c (scan_loop): Likewise.
* reorg.c (stop_search_p): Likewise.
(fill_slots_from_thread): Likewise.
* sel-sched-ir.c (init_global_and_expr_for_insn): Likewise.
* config/bfin/bfin.c (hwloop_optimize, workaround_rts_anomaly,
workaround_speculation, add_sched_insns_for_speculation): Likewise.
* config/c6x/c6x.c (c6x_sched_reorder_1): Likewise.
* config/i386/i386.c (ix86_i387_mode_needed, min_insn_size): Likewise.
* config/ia64/ia64.c (rtx_needs_barrier): Use it instead of
extract_asm_operands.
(ia64_dfa_sched_reorder): Use it instead of open-coded checks.
* config/m68k/m68k.c (m68k_sched_variable_issue): Likewise.
* config/mips/mips.c (mips_avoid_hazard): Likewise.
* config/pa/pa.c (branch_to_delay_slot_p, branch_needs_nop_p,
use_skip_p): Likewise.
* config/spu/spu.c (get_branch_target): Use it instead of
extract_asm_operands.
Index: rtl.h
===
--- rtl.h (revision 197307)
+++ rtl.h (working copy)
@@ -2058,6 +2058,7 @@ extern void remove_reg_equal_equiv_notes_for_regno
extern int side_effects_p (const_rtx);
extern int volatile_refs_p (const_rtx);
extern int volatile_insn_p (const_rtx);
+extern bool insn_with_asm_operands_p (const_rtx);
extern int may_trap_p_1 (const_rtx, unsigned);
extern int may_trap_p (const_rtx);
extern int may_trap_or_fault_p (const_rtx);
Index: rtlanal.c
===
--- rtlanal.c (revision 197307)
+++ rtlanal.c (working copy)
@@ -2273,6 +2273,18 @@ side_effects_p (const_rtx x)
}
return 0;
}
+
+/* Return true if INSN has asm operands. */
+
+bool
+insn_with_asm_operands_p (const_rtx insn)
+{
+ if (!INSN_P (insn))
+return false;
+ return (GET_CODE (PATTERN (insn)) == ASM_INPUT
+ || asm_noperands (PATTERN (insn)) = 0);
+}
+
/* Return nonzero if evaluating rtx X might cause a trap.
FLAGS controls how to consider MEMs. A nonzero means the context
Index: cfgrtl.c
===
--- cfgrtl.c(revision 197307)
+++ cfgrtl.c(working copy)
@@ -1718,7 +1718,7 @@ rtl_split_edge (edge edge_in)
if (last
JUMP_P (last)
edge_in-dest != EXIT_BLOCK_PTR
- extract_asm_operands (PATTERN (last)) != NULL_RTX
+ insn_with_asm_operands_p (last)
patch_jump_insn (last, before, bb))
df_set_bb_dirty (edge_in-src);
}
@@ -3308,7 +3308,7 @@ fixup_reorder_chain (void)
continue;
}
}
- else if (extract_asm_operands (PATTERN (bb_end_insn)) != NULL)
+ else if (insn_with_asm_operands_p (bb_end_insn))
{
/* If the old fallthru is still next or if
asm goto doesn't have a fallthru (e.g. when followed by
Index: compare-elim.c
===
--- compare-elim.c (revision 197307)
+++ compare-elim.c (working copy)
@@ -162,10 +162,10 @@ arithmetic_flags_clobber_p (rtx insn)
if (!NONJUMP_INSN_P (insn))
return false;
- pat = PATTERN (insn);
- if (extract_asm_operands (pat))
+ if (insn_with_asm_operands_p (insn))
return false;
+ pat = PATTERN (insn);
if (GET_CODE (pat) == PARALLEL XVECLEN (pat, 0) == 2)
{
x = XVECEXP (pat, 0, 0);
Index: dwarf2out.c
===
--- dwarf2out.c (revision 197307)
+++ dwarf2out.c (working copy)
@@ -20798,8 +20798,7 @@ dwarf2out_var_location (rtx loc_note)
if (GET_CODE (body) == USE || GET_CODE (body) == CLOBBER)
continue;
/* Inline asm could occupy zero bytes. */
- else if
Re: [C++ Patch] PR 56725
On Thu, Mar 28, 2013 at 03:55:38PM +0100, Paolo Carlini wrote: .. oops, the patch I attached has a typo. This is the right one. This regressed FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (test for errors, line 12) Can you please adjust that testcase too? Jakub
Re: [PATCH][ARM] minmax_arithsi for non-canonical operand order with MINUS operator
On Thu, Mar 21, 2013 at 6:09 PM, Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This patch adds a splitter variant of the minmax_arithsi pattern for when
the operator
is non-commutative (MINUS) and the ordering of the operands is not
canonical.
That is, it will trigger for:
#define MAX(a, b) (a b ? a : b)
int
foo (int a, int b, int c)
{
return c - MAX (a,b);
}
and will generate:
cmp r1, r0
rsbge r0, r1, r2
rsblt r0, r0, r2
instead of the current:
cmp r0, r1
movlt r0, r1
rsb r0, r0, r2
No regressions on arm-none-eabi.
Ok for trunk?
Split after reload please into cond-exec or use if_then_else instead
if you are splitting before reload - I originally thought it to be
safe when you asked me, but then have gone back and corrected myself.
Read this thread . http://patches.linaro.org/6469/ .
regards
Ramana
Thanks,
Kyrill
gcc/
2013-03-21 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/arm.md (minmax_arithsi_non_canon): New pattern.
gcc/testsuite
2013-03-21 Kyrylo Tkachov kyrylo.tkac...@arm.com
* gcc.target/arm/minmax_minus.c: New test.
Re: [C++ Patch] PR 56725
On 04/02/2013 12:03 PM, Jakub Jelinek wrote:
On Thu, Mar 28, 2013 at 03:55:38PM +0100, Paolo Carlini wrote:
.. oops, the patch I attached has a typo. This is the right one.
This regressed
FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (test for errors, line 12)
Can you please adjust that testcase too?
Sorry about that. Done with the below.
Paolo.
///
2013-04-02 Paolo Carlini paolo.carl...@oracle.com
* obj-c++.dg/try-catch-13.mm: Update per PR56725.
Index: obj-c++.dg/try-catch-13.mm
===
--- obj-c++.dg/try-catch-13.mm (revision 197344)
+++ obj-c++.dg/try-catch-13.mm (working copy)
@@ -22,7 +22,7 @@ extern void some_func (int *);
typeof(q) k = 66;
some_func (j);
/* { dg-error invalid conversion { target *-*-* } 23 } */
-/* { dg-error initializing argument { target *-*-* } 12 } */
+/* { dg-message initializing argument { target *-*-* } 12 } */
some_func (k);
}
@catch (id exc) {
@@ -39,7 +39,7 @@ extern void some_func (int *);
/* { dg-error invalid conversion { target *-*-* } 38 } */
/* The following is disabled as it is already checked above and the testsuites
seems
to count multiple different identical errors on the same line only once */
-/* dg-error initializing argument { target *-*-* } 12 */
+/* dg-message initializing argument { target *-*-* } 12 */
}
@catch (id exc) {
@throw;
@@ -54,7 +54,7 @@ extern void some_func (int *);
/* { dg-error invalid conversion { target *-*-* } 53 } */
/* The following is disabled as it is already checked above and the testsuites
seems
to count multiple different identical errors on the same line only once */
-/* dg-error initializing argument { target *-*-* } 12 */
+/* dg-message initializing argument { target *-*-* } 12 */
some_func (k);
}
@catch (id exc) {
Re: [C++ Patch] PR 56725
Hello! .. oops, the patch I attached has a typo. This is the right one. This regressed FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (test for errors, line 12) Can you please adjust that testcase too? Tested patch is at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00013.html Uros.
Re: [RTL] Canonicalize commutative operations more
On Tue, 2 Apr 2013, Eric Botcazou wrote: I am not sure about adding just a few rules. If I just say that lshift is stronger than rshift, the relation is not an order (transitive) anymore. Why? Can't you give them precedences in commutative_operand_precedence that preserve the transitivity? I can, but then I am giving lshift higher priority than every other operation, not just rshift. And if I want to give (vec_select x 0) a higher precedence than (vec_select x 1) but lower than (vec_select (vec_concat a b) 1), the weights may become complicated, whereas the comparison function could just recurse. But I understand that it has advantages over an arbitrary order, so if I ever feel the need again I will try to play with precedence values. I might also experiment with the new transformation feature of .md files to write a pattern once and have it expand to 2 patterns for the 2 orders. The fear (at least mine) is that, by canonicalizing everything, you will make changes behind the back of back-ends that could disable some of their patterns silently. I wonder if those issues might in most cases be bugs in the back-ends (optimizations missed depending on the order), that the canonicalization would make more noticable (and thus easier to fix). -- Marc Glisse
Re: [patch] replace a bunch of equivalent checks for asm operands with a new function
This idiom: if (GET_CODE (body) == ASM_INPUT || asm_noperands (body) = 0) appears in multiple places. There's even one place where the idiom above is used in reverse (making the GET_CODE... check redundant). A few more places to the equivalent by checking extract_asm_operands != NULL. I think that the last point is not clear: asm_noperands can return -1 and yet extract_asm_operands has returned non-NULL. And, at least in some cases, I think that the right predicate is extract_asm_operands. In fact, I wonder whether in most cases the right combined predicate would be: GET_CODE (body) == ASM_INPUT || extract_asm_operands (body) != NULL and asm_noperands only used when you really care about the operands. It made sense to me, at least, to replace those equivalent checks with a new function: insn_with_asm_operands_p(). The first hunk for config/ia64/ia64.c looks incorrect. -- Eric Botcazou
Re: [PATCH, boehm-gc, AArch64] Add AArch64 support
Ping (second try) Sorry if you received it twice, it seems that my gmail account switched in text/html mode :( Many thanks, Yvan On 2 April 2013 11:21, Yvan Roux yvan.r...@linaro.org wrote: Ping On 17 March 2013 21:34, Yvan Roux yvan.r...@linaro.org wrote: Hi, this is a backport from gc mainline of the basic AArch64 support (it covers the Linux and bare machine mode). I tested it on the Foundation model with enabling the objc frontend, and passing the testsuite manually (maybe I miss-configured it, but it seems that the boehm-gc testsuite is not cross-environment friendly, as the gctest script looks for the host gcc build tree), and everything is fine, except the thread_leak_test which has a different output than the x86 one: x86 thread_leak_test output Leaked composite object at 0x2ab05fe0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at start: 0x2ab03fa0, appr. length: 40 Leaked composite object at 0x2ab05ec0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x2ab05f20 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at start: 0x2ab03f50, appr. length: 40 Leaked composite object at start: 0x2ab03f78, appr. length: 40 Leaked composite object at 0x2ab05ef0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at start: 0x2ab03fa0, appr. length: 40 Leaked composite object at 0x2ab05e00 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at start: 0x2ab03f78, appr. length: 40 AArch64 thread_leak_test output: Leaked composite object at 0x7f91e14ef0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x7f91e14fe0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x7f91e14e00 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x7f91e14e30 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x7f91e14fe0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Regards, Yvan 2013-03-16 Yvan Roux yvan.r...@linaro.org * include/private/gcconfig.h (AARCH64): New macro (defined only if __aarch64__). * include/private/gcconfig.h (mach_type_known): Update comment adding ARM AArch64 target. * include/private/gcconfig.h (NOSYS, mach_type_known, CPP_WORDSZ, MACH_TYPE, ALIGNMENT, HBLKSIZE, OS_TYPE, LINUX_STACKBOTTOM, USE_GENERIC_PUSH_REGS, DYNAMIC_LOADING, DATASTART, DATAEND, STACKBOTTOM): Define for AArch64.
Re: [RTL] Canonicalize commutative operations more
I can, but then I am giving lshift higher priority than every other operation, not just rshift. And if I want to give (vec_select x 0) a higher precedence than (vec_select x 1) but lower than (vec_select (vec_concat a b) 1), the weights may become complicated, whereas the comparison function could just recurse. You cannot have both transitivity and fast-tracks in the comparison function. However it isn't clear (at least to me) if transitivity is really required. (vec_select x 0) and (vec_select x 1) are the same pattern so they shouldn't be distinguished here. I wonder if those issues might in most cases be bugs in the back-ends (optimizations missed depending on the order), that the canonicalization would make more noticable (and thus easier to fix). There are certainly such issues in the back-ends (and even ??? comments about it) so sensible canonicalization is desirable. -- Eric Botcazou
[PATCH] Allow MEM_REF lhs on gimple_clobber_p stmts (PR c++/34949)
Hi!
Jason's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949#c12
patch attempts to emit a clobber for *this at the end of the destructor,
so that we can DSE stores into the object when the object is dead, but
so far only VAR_DECLs have been allowed on the lhs of gimple_clobber_p
stmts.
This incremental patch allows there either a VAR_DECL, or MEM_REF.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
(Jason's patch can be just committed as the last thing in the series).
2013-04-02 Jakub Jelinek ja...@redhat.com
PR c++/34949
* tree-cfg.c (verify_gimple_assign_single): Allow lhs
of gimple_clobber_p to be MEM_REF.
* gimplify.c (gimplify_modify_expr): Gimplify *to_p of
an assignment from TREE_CLOBBER_P. Allow it to be MEM_REF
after gimplification.
* asan.c (get_mem_ref_of_assignment): Don't instrument
gimple_clobber_p stmts.
* tree-ssa-dse.c (dse_optimize_stmt): Allow DSE of
gimple_clobber_p stmt if they have MEM_REF lhs and
are dead because of another gimple_clobber_p stmt.
* tree-ssa-live.c (clear_unused_block_pointer): Treat
gimple_clobber_p stmts like debug stmts.
(remove_unused_locals): Remove clobbers with MEM_REF lhs
that refer to unused VAR_DECLs or uninitialized values.
* tree-sra.c (sra_ipa_reset_debug_stmts): Also remove
gimple_clobber_p stmts if they refer to removed parameters.
(get_repl_default_def_ssa_name, sra_ipa_modify_expr): Fix up
formatting.
--- gcc/tree-cfg.c.jj 2013-03-21 18:34:11.0 +0100
+++ gcc/tree-cfg.c 2013-03-27 13:44:59.475007635 +0100
@@ -3812,9 +3812,9 @@ verify_gimple_assign_single (gimple stmt
}
if (gimple_clobber_p (stmt)
- !DECL_P (lhs))
+ !(DECL_P (lhs) || TREE_CODE (lhs) == MEM_REF))
{
- error (non-decl LHS in clobber statement);
+ error (non-decl/MEM_REF LHS in clobber statement);
debug_generic_expr (lhs);
return true;
}
--- gcc/gimplify.c.jj 2013-03-21 18:34:11.0 +0100
+++ gcc/gimplify.c 2013-03-27 13:38:30.988181267 +0100
@@ -4840,7 +4840,12 @@ gimplify_modify_expr (tree *expr_p, gimp
so handle it here. */
if (TREE_CLOBBER_P (*from_p))
{
- gcc_assert (!want_value TREE_CODE (*to_p) == VAR_DECL);
+ ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
+ if (ret == GS_ERROR)
+ return ret;
+ gcc_assert (!want_value
+ (TREE_CODE (*to_p) == VAR_DECL
+ || TREE_CODE (*to_p) == MEM_REF));
gimplify_seq_add_stmt (pre_p, gimple_build_assign (*to_p, *from_p));
*expr_p = NULL;
return GS_ALL_DONE;
--- gcc/asan.c.jj 2013-02-28 22:22:03.0 +0100
+++ gcc/asan.c 2013-03-27 14:29:54.531785577 +0100
@@ -412,7 +412,8 @@ get_mem_ref_of_assignment (const gimple
{
gcc_assert (gimple_assign_single_p (assignment));
- if (gimple_store_p (assignment))
+ if (gimple_store_p (assignment)
+ !gimple_clobber_p (assignment))
{
ref-start = gimple_assign_lhs (assignment);
*ref_is_store = true;
--- gcc/tree-ssa-dse.c.jj 2013-01-11 09:02:37.0 +0100
+++ gcc/tree-ssa-dse.c 2013-03-27 17:14:27.424466023 +0100
@@ -218,7 +218,10 @@ dse_optimize_stmt (gimple_stmt_iterator
if (is_gimple_call (stmt) gimple_call_fndecl (stmt))
return;
- if (gimple_has_volatile_ops (stmt))
+ /* Don't return early on *this_2(D) ={v} {CLOBBER}. */
+ if (gimple_has_volatile_ops (stmt)
+ (!gimple_clobber_p (stmt)
+ || TREE_CODE (gimple_assign_lhs (stmt)) != MEM_REF))
return;
if (is_gimple_assign (stmt))
@@ -228,6 +231,12 @@ dse_optimize_stmt (gimple_stmt_iterator
if (!dse_possible_dead_store_p (stmt, use_stmt))
return;
+ /* But only remove *this_2(D) ={v} {CLOBBER} if killed by
+another clobber stmt. */
+ if (gimple_clobber_p (stmt)
+ !gimple_clobber_p (use_stmt))
+ return;
+
/* If we have precisely one immediate use at this point and the
stores are to the same memory location or there is a chain of
virtual uses from stmt and the stmt which stores to that same
--- gcc/tree-ssa-live.c.jj 2013-03-21 18:34:11.0 +0100
+++ gcc/tree-ssa-live.c 2013-03-28 11:10:15.889669796 +0100
@@ -623,8 +623,8 @@ clear_unused_block_pointer_1 (tree *tp,
return NULL_TREE;
}
-/* Set all block pointer in debug stmt to NULL if the block is unused,
- so that they will not be streamed out. */
+/* Set all block pointer in debug or clobber stmt to NULL if the block
+ is unused, so that they will not be streamed out. */
static void
clear_unused_block_pointer (void)
@@ -639,7 +639,7 @@ clear_unused_block_pointer (void)
tree b;
gimple stmt = gsi_stmt (gsi);
- if (!is_gimple_debug (stmt))
+ if (!is_gimple_debug (stmt) !gimple_clobber_p (stmt))
[PATCH] Improve stmt_kills_ref_p_1 (PR c++/34949)
Hi!
The patch I've just posted wasn't enough, because stmt_kills_ref_p_1
only did something if base == ref-base, but in the case of the dtors
base and ref-base are often MEM_REFs, which aren't equal, but they
just operand_equal_p. And, for MEM_REFs, we don't even need to require
that the two MEM_REFs operand_equal_p, it is enough if the first operand
of both is the same, we don't need to care about either of the two types
(TBAA and MEM_REF's type), nor sizes, and can even handle different offset
arguments. On IRC we've been talking with Richard about adding a predicate
function whether addresses are the same, but as that predicate would
necessarily require that the MEM_REF offset is the same constant (ignoring
the TBAA type on it), that would disallow handling different offsets,
so the function now performs all the checking inline.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-04-02 Jakub Jelinek ja...@redhat.com
PR c++/34949
* tree-ssa-alias.c (stmt_kills_ref_p_1): If base != ref-base,
call operand_equal_p on them or for MEM_REFs just compare
first argument for equality and attempt to deal even with differing
offsets.
--- gcc/tree-ssa-alias.c.jj 2013-03-18 12:16:59.0 +0100
+++ gcc/tree-ssa-alias.c2013-03-27 17:09:28.230216081 +0100
@@ -1870,20 +1870,51 @@ stmt_kills_ref_p_1 (gimple stmt, ao_ref
!stmt_can_throw_internal (stmt))
{
tree base, lhs = gimple_get_lhs (stmt);
- HOST_WIDE_INT size, offset, max_size;
+ HOST_WIDE_INT size, offset, max_size, ref_offset = ref-offset;
base = get_ref_base_and_extent (lhs, offset, size, max_size);
/* We can get MEM[symbol: sZ, index: D.8862_1] here,
so base == ref-base does not always hold. */
- if (base == ref-base)
+ if (base != ref-base)
{
- /* For a must-alias check we need to be able to constrain
-the access properly. */
- if (size != -1 size == max_size)
+ /* If both base and ref-base are MEM_REFs, only compare the
+first operand, and if the second operand isn't equal constant,
+try to add the offsets into offset and ref_offset. */
+ if (TREE_CODE (base) == MEM_REF TREE_CODE (ref-base) == MEM_REF
+ operand_equal_p (TREE_OPERAND (base, 0),
+ TREE_OPERAND (ref-base, 0), 0))
{
- if (offset = ref-offset
- offset + size = ref-offset + ref-max_size)
- return true;
+ if (!tree_int_cst_equal (TREE_OPERAND (base, 0),
+ TREE_OPERAND (ref-base, 0)))
+ {
+ double_int off1 = mem_ref_offset (base);
+ off1 = off1.alshift (BITS_PER_UNIT == 8
+ ? 3 : exact_log2 (BITS_PER_UNIT),
+ HOST_BITS_PER_DOUBLE_INT);
+ off1 = off1 + double_int::from_shwi (offset);
+ double_int off2 = mem_ref_offset (ref-base);
+ off2 = off2.alshift (BITS_PER_UNIT == 8
+ ? 3 : exact_log2 (BITS_PER_UNIT),
+ HOST_BITS_PER_DOUBLE_INT);
+ off2 = off2 + double_int::from_shwi (ref_offset);
+ if (off1.fits_shwi () off2.fits_shwi ())
+ {
+ offset = off1.to_shwi ();
+ ref_offset = off2.to_shwi ();
+ }
+ else
+ size = -1;
+ }
}
+ else if (!operand_equal_p (base, ref-base, 0))
+ size = -1;
+ }
+ /* For a must-alias check we need to be able to constrain
+the access properly. */
+ if (size != -1 size == max_size)
+ {
+ if (offset = ref_offset
+ offset + size = ref_offset + ref-max_size)
+ return true;
}
}
Jakub
[PATCH] Fold __builtin_constant_p immediately when in the first argument of __builtin_choose_expr (PR c/19449)
Hi!
As discussed in the PR, when __builtin_constant_p is used in the first
argument of __builtin_choose_expr, as we require a constant value
immediately, we'd better force folding of __builtin_constant_p immediately,
as if we don't, and it isn't 1 known immediately, we won't end up with a
constant expression. For -O0 we accept code using __builtin_constant_p
in __builtin_choose_expr (as we fold it there immediately always), but not
for -O1 and above.
The following patch folds it there immediately too. Bootstrapped/regtested
on x86_64-linux and i686-linux, ok for trunk?
BTW, in the PR I've also mentioned what has been reported to the Red Hat
bugzilla about __builtin_constant_p in array bounds of static (or extern)
arrays in block contexts. Those can't be VLAs, so we want to know the
constant bound, but if __builtin_constant_p is used there, we error on it
(while at file scope it compiles fine, because if cfun is NULL, we fold
__builtin_constant_p immediately). Any suggestions how to fix that?
2013-04-02 Jakub Jelinek ja...@redhat.com
PR c/19449
* tree.h (force_folding_builtin_constant_p): New decl.
* builtins.c (force_folding_builtin_constant_p): New variable.
(fold_builtin_constant_p): Fold immediately also if
force_folding_builtin_constant_p.
* c-parser.c (c_parser_get_builtin_args): Add choose_expr_p
argument. If set, or it temporarily for parsing of the first
argument into force_folding_builtin_constant_p.
(c_parser_postfix_expression): Adjust callers.
* gcc.c-torture/execute/pr19449.c: New test.
--- gcc/tree.h.jj 2013-03-21 18:34:09.0 +0100
+++ gcc/tree.h 2013-03-21 18:34:09.0 +0100
@@ -5851,6 +5851,10 @@ fold_build_pointer_plus_hwi_loc (locatio
fold_build_pointer_plus_hwi_loc (UNKNOWN_LOCATION, p, o)
/* In builtins.c */
+
+/* Non-zero if __builtin_constant_p should be folded right away. */
+extern bool force_folding_builtin_constant_p;
+
extern bool avoid_folding_inline_builtin (tree);
extern tree fold_call_expr (location_t, tree, bool);
extern tree fold_builtin_fputs (location_t, tree, tree, bool, bool, tree);
--- gcc/builtins.c.jj 2013-01-11 09:02:35.0 +0100
+++ gcc/builtins.c 2013-03-28 09:26:51.700817655 +0100
@@ -75,6 +75,9 @@ const char * built_in_names[(int) END_BU
initialized to NULL_TREE. */
builtin_info_type builtin_info;
+/* Non-zero if __builtin_constant_p should be folded right away. */
+bool force_folding_builtin_constant_p;
+
static const char *c_getstr (tree);
static rtx c_readstr (const char *, enum machine_mode);
static int target_char_cast (tree, char *);
@@ -6974,7 +6977,8 @@ fold_builtin_constant_p (tree arg)
|| AGGREGATE_TYPE_P (TREE_TYPE (arg))
|| POINTER_TYPE_P (TREE_TYPE (arg))
|| cfun == 0
- || folding_initializer)
+ || folding_initializer
+ || force_folding_builtin_constant_p)
return integer_zero_node;
return NULL_TREE;
--- gcc/c/c-parser.c.jj 2013-03-19 18:42:48.0 +0100
+++ gcc/c/c-parser.c2013-03-28 09:30:17.609546890 +0100
@@ -6114,11 +6114,13 @@ c_parser_alignof_expression (c_parser *p
stores the arguments in CEXPR_LIST. */
static bool
c_parser_get_builtin_args (c_parser *parser, const char *bname,
- vecc_expr_t, va_gc **ret_cexpr_list)
+ vecc_expr_t, va_gc **ret_cexpr_list,
+ bool choose_expr_p)
{
location_t loc = c_parser_peek_token (parser)-location;
vecc_expr_t, va_gc *cexpr_list;
c_expr_t expr;
+ bool saved_force_folding_builtin_constant_p;
*ret_cexpr_list = NULL;
if (c_parser_next_token_is_not (parser, CPP_OPEN_PAREN))
@@ -6135,7 +6137,12 @@ c_parser_get_builtin_args (c_parser *par
return true;
}
+ saved_force_folding_builtin_constant_p
+= force_folding_builtin_constant_p;
+ force_folding_builtin_constant_p |= choose_expr_p;
expr = c_parser_expr_no_commas (parser, NULL);
+ force_folding_builtin_constant_p
+= saved_force_folding_builtin_constant_p;
vec_alloc (cexpr_list, 1);
C_EXPR_APPEND (cexpr_list, expr);
while (c_parser_next_token_is (parser, CPP_COMMA))
@@ -6509,7 +6516,7 @@ c_parser_postfix_expression (c_parser *p
c_parser_consume_token (parser);
if (!c_parser_get_builtin_args (parser,
__builtin_choose_expr,
- cexpr_list))
+ cexpr_list, true))
{
expr.value = error_mark_node;
break;
@@ -6591,7 +6598,7 @@ c_parser_postfix_expression (c_parser *p
c_parser_consume_token (parser);
if (!c_parser_get_builtin_args (parser,
__builtin_complex,
- cexpr_list))
+ cexpr_list,
[Patch ARM] Add support for Cortex-A53.
Hi, This patch adds support for the Cortex-A53. Tested with a simple build of arm-none-eabi for no regressions on a version before the builds broke with PR56809. We have been carrying this internally for quite some time now - so I'm ok with it's stability. The default tuning for -march=armv8-a is now the Cortex-A53 rather than the A15. Applied to trunk. regards Ramana 2013-04-02 Ian Caulfield ian.caulfi...@arm.com Ramana Radhakrishnan ramana.radhakrish...@arm.com * config/arm/arm-arches.def (armv8-a): Default to cortex-a53. * config/arm/t-arm (MD_INCLUDES): Depend on cortex-a53.md. * config/arm/cortex-a53.md: New file. * config/arm/bpabi.h (BE8_LINK_SPEC): Handle cortex-a53. * config/arm/arm.md (generic_sched, generic_vfp): Handle cortex-a53. * config/arm/arm.c (arm_issue_rate): Likewise. * config/arm/arm-tune.md: Regenerate * config/arm/arm-tables.opt: Regenerate. * config/arm/arm-cores.def: Add cortex-a53. Index: gcc/config/arm/arm-tables.opt === --- gcc/config/arm/arm-tables.opt (revision 197345) +++ gcc/config/arm/arm-tables.opt (working copy) @@ -250,6 +250,9 @@ Enum(processor_type) String(cortex-a15) Value(cortexa15) EnumValue +Enum(processor_type) String(cortex-a53) Value(cortexa53) + +EnumValue Enum(processor_type) String(cortex-r4) Value(cortexr4) EnumValue Index: gcc/config/arm/arm-arches.def === --- gcc/config/arm/arm-arches.def (revision 197345) +++ gcc/config/arm/arm-arches.def (working copy) @@ -53,6 +53,6 @@ ARM_ARCH(armv7-r, cortexr4, 7R, FL_CO_PROC | FL_FOR_ARCH7R) ARM_ARCH(armv7-m, cortexm3, 7M, FL_CO_PROC | FL_FOR_ARCH7M) ARM_ARCH(armv7e-m, cortexm4, 7EM, FL_CO_PROC |FL_FOR_ARCH7EM) -ARM_ARCH(armv8-a, cortexa15, 8A, FL_CO_PROC | FL_FOR_ARCH8A) +ARM_ARCH(armv8-a, cortexa53, 8A, FL_CO_PROC | FL_FOR_ARCH8A) ARM_ARCH(iwmmxt, iwmmxt, 5TE, FL_LDSCHED | FL_STRONG | FL_FOR_ARCH5TE | FL_XSCALE | FL_IWMMXT) ARM_ARCH(iwmmxt2, iwmmxt2,5TE, FL_LDSCHED | FL_STRONG | FL_FOR_ARCH5TE | FL_XSCALE | FL_IWMMXT | FL_IWMMXT2) Index: gcc/config/arm/arm-tune.md === --- gcc/config/arm/arm-tune.md (revision 197345) +++ gcc/config/arm/arm-tune.md (working copy) @@ -1,5 +1,5 @@ ;; -*- buffer-read-only: t -*- ;; Generated automatically by gentune.sh from arm-cores.def (define_attr tune - arm2,arm250,arm3,arm6,arm60,arm600,arm610,arm620,arm7,arm7d,arm7di,arm70,arm700,arm700i,arm710,arm720,arm710c,arm7100,arm7500,arm7500fe,arm7m,arm7dm,arm7dmi,arm8,arm810,strongarm,strongarm110,strongarm1100,strongarm1110,fa526,fa626,arm7tdmi,arm7tdmis,arm710t,arm720t,arm740t,arm9,arm9tdmi,arm920,arm920t,arm922t,arm940t,ep9312,arm10tdmi,arm1020t,arm9e,arm946es,arm966es,arm968es,arm10e,arm1020e,arm1022e,xscale,iwmmxt,iwmmxt2,fa606te,fa626te,fmp626,fa726te,arm926ejs,arm1026ejs,arm1136js,arm1136jfs,arm1176jzs,arm1176jzfs,mpcorenovfp,mpcore,arm1156t2s,arm1156t2fs,genericv7a,cortexa5,cortexa7,cortexa8,cortexa9,cortexa15,cortexr4,cortexr4f,cortexr5,cortexr7,cortexm4,cortexm3,cortexm1,cortexm0,cortexm0plus,marvell_pj4 + arm2,arm250,arm3,arm6,arm60,arm600,arm610,arm620,arm7,arm7d,arm7di,arm70,arm700,arm700i,arm710,arm720,arm710c,arm7100,arm7500,arm7500fe,arm7m,arm7dm,arm7dmi,arm8,arm810,strongarm,strongarm110,strongarm1100,strongarm1110,fa526,fa626,arm7tdmi,arm7tdmis,arm710t,arm720t,arm740t,arm9,arm9tdmi,arm920,arm920t,arm922t,arm940t,ep9312,arm10tdmi,arm1020t,arm9e,arm946es,arm966es,arm968es,arm10e,arm1020e,arm1022e,xscale,iwmmxt,iwmmxt2,fa606te,fa626te,fmp626,fa726te,arm926ejs,arm1026ejs,arm1136js,arm1136jfs,arm1176jzs,arm1176jzfs,mpcorenovfp,mpcore,arm1156t2s,arm1156t2fs,genericv7a,cortexa5,cortexa7,cortexa8,cortexa9,cortexa15,cortexa53,cortexr4,cortexr4f,cortexr5,cortexr7,cortexm4,cortexm3,cortexm1,cortexm0,cortexm0plus,marvell_pj4 (const (symbol_ref ((enum attr_tune) arm_tune Index: gcc/config/arm/cortex-a53.md === --- gcc/config/arm/cortex-a53.md(revision 0) +++ gcc/config/arm/cortex-a53.md(working copy) @@ -0,0 +1,296 @@ +;; ARM Cortex-A53 pipeline description +;; Copyright (C) 2013 Free Software Foundation, Inc. +;; +;; Contributed by ARM Ltd. +;; +;; This file is part of GCC. +;; +;; GCC is free software; you can redistribute it and/or modify it +;; under the terms of the GNU General Public License as published by +;; the Free Software Foundation; either version 3, or (at your option) +;; any later version. +;; +;; GCC is distributed in the hope that it will be useful, but +;; WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;; General
Re: [PATCH] Allow MEM_REF lhs on gimple_clobber_p stmts (PR c++/34949)
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
Hi!
Jason's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949#c12
patch attempts to emit a clobber for *this at the end of the destructor,
so that we can DSE stores into the object when the object is dead, but
so far only VAR_DECLs have been allowed on the lhs of gimple_clobber_p
stmts.
This incremental patch allows there either a VAR_DECL, or MEM_REF.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Few comments below
(Jason's patch can be just committed as the last thing in the series).
2013-04-02 Jakub Jelinek ja...@redhat.com
PR c++/34949
* tree-cfg.c (verify_gimple_assign_single): Allow lhs
of gimple_clobber_p to be MEM_REF.
* gimplify.c (gimplify_modify_expr): Gimplify *to_p of
an assignment from TREE_CLOBBER_P. Allow it to be MEM_REF
after gimplification.
* asan.c (get_mem_ref_of_assignment): Don't instrument
gimple_clobber_p stmts.
* tree-ssa-dse.c (dse_optimize_stmt): Allow DSE of
gimple_clobber_p stmt if they have MEM_REF lhs and
are dead because of another gimple_clobber_p stmt.
* tree-ssa-live.c (clear_unused_block_pointer): Treat
gimple_clobber_p stmts like debug stmts.
(remove_unused_locals): Remove clobbers with MEM_REF lhs
that refer to unused VAR_DECLs or uninitialized values.
* tree-sra.c (sra_ipa_reset_debug_stmts): Also remove
gimple_clobber_p stmts if they refer to removed parameters.
(get_repl_default_def_ssa_name, sra_ipa_modify_expr): Fix up
formatting.
--- gcc/tree-cfg.c.jj 2013-03-21 18:34:11.0 +0100
+++ gcc/tree-cfg.c2013-03-27 13:44:59.475007635 +0100
@@ -3812,9 +3812,9 @@ verify_gimple_assign_single (gimple stmt
}
if (gimple_clobber_p (stmt)
- !DECL_P (lhs))
+ !(DECL_P (lhs) || TREE_CODE (lhs) == MEM_REF))
{
- error (non-decl LHS in clobber statement);
+ error (non-decl/MEM_REF LHS in clobber statement);
debug_generic_expr (lhs);
return true;
}
--- gcc/gimplify.c.jj 2013-03-21 18:34:11.0 +0100
+++ gcc/gimplify.c2013-03-27 13:38:30.988181267 +0100
@@ -4840,7 +4840,12 @@ gimplify_modify_expr (tree *expr_p, gimp
so handle it here. */
if (TREE_CLOBBER_P (*from_p))
{
- gcc_assert (!want_value TREE_CODE (*to_p) == VAR_DECL);
+ ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
+ if (ret == GS_ERROR)
+ return ret;
+ gcc_assert (!want_value
+(TREE_CODE (*to_p) == VAR_DECL
+ || TREE_CODE (*to_p) == MEM_REF));
gimplify_seq_add_stmt (pre_p, gimple_build_assign (*to_p, *from_p));
*expr_p = NULL;
return GS_ALL_DONE;
--- gcc/asan.c.jj 2013-02-28 22:22:03.0 +0100
+++ gcc/asan.c2013-03-27 14:29:54.531785577 +0100
@@ -412,7 +412,8 @@ get_mem_ref_of_assignment (const gimple
{
gcc_assert (gimple_assign_single_p (assignment));
- if (gimple_store_p (assignment))
+ if (gimple_store_p (assignment)
+ !gimple_clobber_p (assignment))
hmm, maybe gimple_store_p should not consider a clobber a store?
{
ref-start = gimple_assign_lhs (assignment);
*ref_is_store = true;
--- gcc/tree-ssa-dse.c.jj 2013-01-11 09:02:37.0 +0100
+++ gcc/tree-ssa-dse.c2013-03-27 17:14:27.424466023 +0100
@@ -218,7 +218,10 @@ dse_optimize_stmt (gimple_stmt_iterator
if (is_gimple_call (stmt) gimple_call_fndecl (stmt))
return;
- if (gimple_has_volatile_ops (stmt))
+ /* Don't return early on *this_2(D) ={v} {CLOBBER}. */
+ if (gimple_has_volatile_ops (stmt)
+ (!gimple_clobber_p (stmt)
+ || TREE_CODE (gimple_assign_lhs (stmt)) != MEM_REF))
return;
But this only means the clobber was not considered as dead
if there was a later store to the same location. So, why would
that change be needed?
if (is_gimple_assign (stmt))
@@ -228,6 +231,12 @@ dse_optimize_stmt (gimple_stmt_iterator
if (!dse_possible_dead_store_p (stmt, use_stmt))
return;
+ /* But only remove *this_2(D) ={v} {CLOBBER} if killed by
+ another clobber stmt. */
+ if (gimple_clobber_p (stmt)
+!gimple_clobber_p (use_stmt))
+ return;
Ah. Hmm, can that ever happen? I presume the issue with non-decl
clobbers is that we will never remove them, even if the storage
becomes dead?
/* If we have precisely one immediate use at this point and the
stores are to the same memory location or there is a chain of
virtual uses from stmt and the stmt which stores to that same
--- gcc/tree-ssa-live.c.jj2013-03-21 18:34:11.0 +0100
+++ gcc/tree-ssa-live.c 2013-03-28 11:10:15.889669796 +0100
@@ -623,8 +623,8 @@ clear_unused_block_pointer_1 (tree *tp,
return NULL_TREE;
}
-/* Set all block pointer in debug stmt to NULL if
[PATCH] Fix cond_exec_find_if_block (PR rtl-optimization/56745)
Hi!
On the (undefined behavior) testcase below, we end up with
then_bb ending with __builtin_unreachable () at the tree level, therefore
no successor at the RTL level, and else_bb being EXIT_BLOCK_PTR (i.e.
conditional return before a bb with undefined behavior at the end).
Trying to optimize that into a conditional execution of the then_bb insns
doesn't work, we can't merge the else_bb with then_bb and test_bb in this
case, plus it doesn't look like something that would be desirable to do
(conditional return is surely better).
Fixed thusly, ok for trunk/4.8?
2013-04-02 Jakub Jelinek ja...@redhat.com
PR rtl-optimization/56745
* ifcvt.c (cond_exec_find_if_block): Don't try to optimize
if then_bb has no successors and else_bb is EXIT_BLOCK_PTR.
* gcc.c-torture/compile/pr56745.c: New test.
--- gcc/ifcvt.c.jj 2013-03-05 23:25:15.0 +0100
+++ gcc/ifcvt.c 2013-04-02 12:31:19.476859094 +0200
@@ -3473,7 +3473,7 @@ cond_exec_find_if_block (struct ce_if_bl
code processing. ??? we should fix this in the future. */
if (EDGE_COUNT (then_bb-succs) == 0)
{
- if (single_pred_p (else_bb))
+ if (single_pred_p (else_bb) else_bb != EXIT_BLOCK_PTR)
{
rtx last_insn = BB_END (then_bb);
--- gcc/testsuite/gcc.c-torture/compile/pr56745.c.jj2013-04-02
12:38:54.718258527 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr56745.c 2013-04-02
12:33:22.0 +0200
@@ -0,0 +1,15 @@
+/* PR rtl-optimization/56745 */
+
+unsigned char a[6];
+
+void
+foo ()
+{
+ int i;
+ for (i = 5; i = 0; i++)
+{
+ if (++a[i] != 0)
+ break;
+ ++a[i];
+}
+}
Jakub
Re: [PATCH] Improve stmt_kills_ref_p_1 (PR c++/34949)
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
Hi!
The patch I've just posted wasn't enough, because stmt_kills_ref_p_1
only did something if base == ref-base, but in the case of the dtors
base and ref-base are often MEM_REFs, which aren't equal, but they
just operand_equal_p. And, for MEM_REFs, we don't even need to require
that the two MEM_REFs operand_equal_p, it is enough if the first operand
of both is the same, we don't need to care about either of the two types
(TBAA and MEM_REF's type), nor sizes, and can even handle different offset
arguments. On IRC we've been talking with Richard about adding a predicate
function whether addresses are the same, but as that predicate would
necessarily require that the MEM_REF offset is the same constant (ignoring
the TBAA type on it), that would disallow handling different offsets,
so the function now performs all the checking inline.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-04-02 Jakub Jelinek ja...@redhat.com
PR c++/34949
* tree-ssa-alias.c (stmt_kills_ref_p_1): If base != ref-base,
call operand_equal_p on them or for MEM_REFs just compare
first argument for equality and attempt to deal even with differing
offsets.
--- gcc/tree-ssa-alias.c.jj 2013-03-18 12:16:59.0 +0100
+++ gcc/tree-ssa-alias.c 2013-03-27 17:09:28.230216081 +0100
@@ -1870,20 +1870,51 @@ stmt_kills_ref_p_1 (gimple stmt, ao_ref
!stmt_can_throw_internal (stmt))
{
tree base, lhs = gimple_get_lhs (stmt);
- HOST_WIDE_INT size, offset, max_size;
+ HOST_WIDE_INT size, offset, max_size, ref_offset = ref-offset;
base = get_ref_base_and_extent (lhs, offset, size, max_size);
/* We can get MEM[symbol: sZ, index: D.8862_1] here,
so base == ref-base does not always hold. */
- if (base == ref-base)
+ if (base != ref-base)
{
- /* For a must-alias check we need to be able to constrain
- the access properly. */
- if (size != -1 size == max_size)
+ /* If both base and ref-base are MEM_REFs, only compare the
+ first operand, and if the second operand isn't equal constant,
+ try to add the offsets into offset and ref_offset. */
+ if (TREE_CODE (base) == MEM_REF TREE_CODE (ref-base) == MEM_REF
+operand_equal_p (TREE_OPERAND (base, 0),
+ TREE_OPERAND (ref-base, 0), 0))
in all relevant cases operand zero of the MEM_REFs are SSA names
and thus can be compared for equality using == (exception are
integer constant pointers where the type could be theoretically
different).
{
- if (offset = ref-offset
-offset + size = ref-offset + ref-max_size)
- return true;
+ if (!tree_int_cst_equal (TREE_OPERAND (base, 0),
+TREE_OPERAND (ref-base, 0)))
+ {
+ double_int off1 = mem_ref_offset (base);
+ off1 = off1.alshift (BITS_PER_UNIT == 8
+? 3 : exact_log2 (BITS_PER_UNIT),
+HOST_BITS_PER_DOUBLE_INT);
+ off1 = off1 + double_int::from_shwi (offset);
+ double_int off2 = mem_ref_offset (ref-base);
+ off2 = off2.alshift (BITS_PER_UNIT == 8
+? 3 : exact_log2 (BITS_PER_UNIT),
+HOST_BITS_PER_DOUBLE_INT);
+ off2 = off2 + double_int::from_shwi (ref_offset);
+ if (off1.fits_shwi () off2.fits_shwi ())
+ {
+ offset = off1.to_shwi ();
+ ref_offset = off2.to_shwi ();
+ }
+ else
+ size = -1;
+ }
}
+ else if (!operand_equal_p (base, ref-base, 0))
+ size = -1;
This does a redundant operand_equal_p check if both are MEM_REF
but with unequal pointers. Did you get any case where the
2nd operand_equal_p would return true? I can't think of any.
Thus, ok with
else
size = -1;
here.
Thanks,
Richard.
[PATCH] Fix PR56768
This backports a fix to fix PR56768.
Bootstrapped on the 4.7 branch, testing in progress.
Richard.
2013-04-02 Richard Biener rguent...@suse.de
PR middle-end/56768
Backport from mainline
2012-05-16 Richard Guenther rguent...@suse.de
* tree-inline.c (declare_return_variable): Properly handle
DECL_BY_REFERENCE return vars in SSA form.
* g++.dg/torture/pr56768.C: New testcase.
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 196818)
+++ gcc/tree-inline.c (working copy)
@@ -2983,10 +2983,15 @@ declare_return_variable (copy_body_data
if (gimple_in_ssa_p (id-src_cfun))
add_referenced_var (temp);
insert_decl_map (id, result, temp);
- /* When RESULT_DECL is in SSA form, we need to use it's default_def
-SSA_NAME. */
- if (gimple_in_ssa_p (id-src_cfun) gimple_default_def (id-src_cfun,
result))
-temp = remap_ssa_name (gimple_default_def (id-src_cfun, result), id);
+ /* When RESULT_DECL is in SSA form, we need to remap and initialize
+it's default_def SSA_NAME. */
+ if (gimple_in_ssa_p (id-src_cfun)
+ is_gimple_reg (result))
+ {
+ temp = make_ssa_name (temp, NULL);
+ insert_decl_map (id, gimple_default_def (id-src_cfun, result),
+ temp);
+ }
insert_init_stmt (id, entry_bb, gimple_build_assign (temp, var));
}
else
Index: gcc/testsuite/g++.dg/torture/pr56768.C
===
--- gcc/testsuite/g++.dg/torture/pr56768.C (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr56768.C (working copy)
@@ -0,0 +1,40 @@
+// { dg-do compile }
+
+struct Iter
+{
+ int operator* ();
+ void operator++ ();
+};
+
+bool operator!= (Iter , Iter ) { }
+
+struct Container
+{
+ Iter begin () const;
+ Iter end () const;
+};
+
+struct J
+{
+ virtual J *mutable_child ();
+};
+
+struct M
+{
+ M (const Container );
+ J ns_;
+};
+namespace
+{
+ J MakeNamespace (const Container src)
+{
+ J a;
+ J *b = 0;
+ for (const int c: src)
+ b = b ? b-mutable_child () : a;
+ return a;
+}
+}
+M::M (const Container ns):ns_ (MakeNamespace (ns))
+{
+}
Re: [PATCH] Allow MEM_REF lhs on gimple_clobber_p stmts (PR c++/34949)
On Tue, Apr 02, 2013 at 01:44:46PM +0200, Richard Biener wrote:
@@ -412,7 +412,8 @@ get_mem_ref_of_assignment (const gimple
{
gcc_assert (gimple_assign_single_p (assignment));
- if (gimple_store_p (assignment))
+ if (gimple_store_p (assignment)
+ !gimple_clobber_p (assignment))
hmm, maybe gimple_store_p should not consider a clobber a store?
gimple_store_p is young, so perhaps we can tweak its meaning.
By changing gimple_store_p, we could drop this hunk, but perhaps
would want to add early return for gimple_clobber_p
into will_be_nonconstant_predicate? Your call.
{
ref-start = gimple_assign_lhs (assignment);
*ref_is_store = true;
--- gcc/tree-ssa-dse.c.jj 2013-01-11 09:02:37.0 +0100
+++ gcc/tree-ssa-dse.c 2013-03-27 17:14:27.424466023 +0100
@@ -218,7 +218,10 @@ dse_optimize_stmt (gimple_stmt_iterator
if (is_gimple_call (stmt) gimple_call_fndecl (stmt))
return;
- if (gimple_has_volatile_ops (stmt))
+ /* Don't return early on *this_2(D) ={v} {CLOBBER}. */
+ if (gimple_has_volatile_ops (stmt)
+ (!gimple_clobber_p (stmt)
+ || TREE_CODE (gimple_assign_lhs (stmt)) != MEM_REF))
return;
But this only means the clobber was not considered as dead
if there was a later store to the same location. So, why would
that change be needed?
Say with -O2:
struct A { virtual ~A (); char a[10]; };
struct B : public A { virtual ~B (); char b[10]; };
A::~A () { a[5] = 7; }
B::~B () { b[5] = 8; }
B b;
we end up in ~B with:
this_3(D)-D.2229._vptr.A = MEM[(void *)_ZTV1B + 16B];
this_3(D)-b[5] = 8;
_6 = this_3(D)-D.2229;
MEM[(struct A *)this_3(D)]._vptr.A = MEM[(void *)_ZTV1A + 16B];
MEM[(struct A *)this_3(D)].a[5] = 7;
MEM[(struct A *)this_3(D)] ={v} {CLOBBER};
*this_3(D) ={v} {CLOBBER};
and the intent of the above hunk (and the one immediately below this)
is that we DSE the first clobber (with smaller clobbered size), something
that IMHO happens very frequently in C++ code, and allows us to better
DSEthe other stores. There is no point in keeping the smaller clobbers
around, on the other side, without the second hunk we'd remove pretty much
all the MEM_REF clobbers at the end of functions, which is undesriable.
if (is_gimple_assign (stmt))
@@ -228,6 +231,12 @@ dse_optimize_stmt (gimple_stmt_iterator
if (!dse_possible_dead_store_p (stmt, use_stmt))
return;
+ /* But only remove *this_2(D) ={v} {CLOBBER} if killed by
+another clobber stmt. */
+ if (gimple_clobber_p (stmt)
+ !gimple_clobber_p (use_stmt))
+ return;
Ah. Hmm, can that ever happen? I presume the issue with non-decl
clobbers is that we will never remove them, even if the storage
becomes dead?
See above.
@@ -827,7 +827,26 @@ remove_unused_locals (void)
if (gimple_clobber_p (stmt))
{
tree lhs = gimple_assign_lhs (stmt);
+ bool remove = false;
+ /* Remove clobbers referencing unused vars, or clobbers
+ with MEM_REF lhs referencing unused vars or uninitialized
+ pointers. */
if (TREE_CODE (lhs) == VAR_DECL !is_used_p (lhs))
+ remove = true;
+ else if (TREE_CODE (lhs) == MEM_REF)
+ {
+ ssa_op_iter iter;
+ tree op;
+ FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_USE)
The only SSA use on a clobber stmt can possibly be TREE_OPERAND (lhs, 0)
when lhs is a MEM_REF, no need to use FOR_EACH_SSA_TREE_OPERAND.
So just
+ else if (TREE_CODE (lhs) == MEM_REF
TREE_CODE (TREE_OPERAND (lhs, 0)) == SSA_NAME)
...
If MEM_REF[MEM_REF[...], 0] and similar won't ever get through, perhaps.
+ if (SSA_NAME_VAR (op)
+ TREE_CODE (SSA_NAME_VAR (op)) == VAR_DECL
+ !is_used_p (SSA_NAME_VAR (op)))
+ remove = true;
I'm not sure this is really desired ... isn't a better check to do
has_single_use (op)? (which means it would be better suited to
be handled in DCE?)
The above change fixed tons of ICEs, fnsplit pass ignored clobber stmts
(desirable) when deciding what to split, and end up copying the clobber
into the *.part.0 function, but because nothing but the clobber used
the this parameter, it wasn't passed. So, we ended up first referencing
a default definition of a local this variable (just useless stmt), and later
on when tree-ssa-live.c run we've ignored the clobber again for decisions,
so that local this variable became !is_used_p and we've ended up referencing
in-free-list SSA_NAME, which triggered assertion failure. See a few lines
above this where we similarly remove !is_used_p VAR_DECLs.
So, IMHO the !is_used_p code belongs to this spot, we can do the clobber
with
SSA_NAME_IS_DEFAULT_DEF (op) TREE_CODE (SSA_NAME_VAR (op)) != PARM_DECL)
MEM_REF
[PATCH] PR56771: Fix arm-rtems target for 32-bit hosts
This patch is for GCC 4.8 and 4.9. libcpp/ChangeLog 2013-04-02 Sebastian Huber sebastian.hu...@embedded-brains.de * configure.ac: Require 64-bit int for arm*-*-rtems*. * configure: Regenerate. --- libcpp/configure|1 + libcpp/configure.ac |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libcpp/configure b/libcpp/configure index f21b361..7158186 100755 --- a/libcpp/configure +++ b/libcpp/configure @@ -7153,6 +7153,7 @@ case $target in aarch64*-*-* | \ alpha*-*-* | \ arm*-*-*eabi* | \ + arm*-*-rtems* | \ arm*-*-symbianelf* | \ x86_64-*-* | \ ia64-*-* | \ diff --git a/libcpp/configure.ac b/libcpp/configure.ac index e0c4ae6..43ac9ba 100644 --- a/libcpp/configure.ac +++ b/libcpp/configure.ac @@ -185,6 +185,7 @@ case $target in aarch64*-*-* | \ alpha*-*-* | \ arm*-*-*eabi* | \ + arm*-*-rtems* | \ arm*-*-symbianelf* | \ x86_64-*-* | \ ia64-*-* | \ -- 1.7.7
Re: [PATCH] Allow MEM_REF lhs on gimple_clobber_p stmts (PR c++/34949)
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
On Tue, Apr 02, 2013 at 01:44:46PM +0200, Richard Biener wrote:
@@ -412,7 +412,8 @@ get_mem_ref_of_assignment (const gimple
{
gcc_assert (gimple_assign_single_p (assignment));
- if (gimple_store_p (assignment))
+ if (gimple_store_p (assignment)
+ !gimple_clobber_p (assignment))
hmm, maybe gimple_store_p should not consider a clobber a store?
gimple_store_p is young, so perhaps we can tweak its meaning.
By changing gimple_store_p, we could drop this hunk, but perhaps
would want to add early return for gimple_clobber_p
into will_be_nonconstant_predicate? Your call.
I've just come along 56787 and decided that not collecting
CLOBBERs during data-reference gathering would be wrong.
Thus changing gimple_store_p would be wrong, too. So in the
end the above hunk looks ok and we shouldn't change gimple_store_p.
(well, for now at least)
{
ref-start = gimple_assign_lhs (assignment);
*ref_is_store = true;
--- gcc/tree-ssa-dse.c.jj 2013-01-11 09:02:37.0 +0100
+++ gcc/tree-ssa-dse.c2013-03-27 17:14:27.424466023 +0100
@@ -218,7 +218,10 @@ dse_optimize_stmt (gimple_stmt_iterator
if (is_gimple_call (stmt) gimple_call_fndecl (stmt))
return;
- if (gimple_has_volatile_ops (stmt))
+ /* Don't return early on *this_2(D) ={v} {CLOBBER}. */
+ if (gimple_has_volatile_ops (stmt)
+ (!gimple_clobber_p (stmt)
+ || TREE_CODE (gimple_assign_lhs (stmt)) != MEM_REF))
return;
But this only means the clobber was not considered as dead
if there was a later store to the same location. So, why would
that change be needed?
Say with -O2:
struct A { virtual ~A (); char a[10]; };
struct B : public A { virtual ~B (); char b[10]; };
A::~A () { a[5] = 7; }
B::~B () { b[5] = 8; }
B b;
we end up in ~B with:
this_3(D)-D.2229._vptr.A = MEM[(void *)_ZTV1B + 16B];
this_3(D)-b[5] = 8;
_6 = this_3(D)-D.2229;
MEM[(struct A *)this_3(D)]._vptr.A = MEM[(void *)_ZTV1A + 16B];
MEM[(struct A *)this_3(D)].a[5] = 7;
MEM[(struct A *)this_3(D)] ={v} {CLOBBER};
*this_3(D) ={v} {CLOBBER};
and the intent of the above hunk (and the one immediately below this)
is that we DSE the first clobber (with smaller clobbered size), something
that IMHO happens very frequently in C++ code, and allows us to better
DSEthe other stores. There is no point in keeping the smaller clobbers
around, on the other side, without the second hunk we'd remove pretty much
all the MEM_REF clobbers at the end of functions, which is undesriable.
Ah, ok.
if (is_gimple_assign (stmt))
@@ -228,6 +231,12 @@ dse_optimize_stmt (gimple_stmt_iterator
if (!dse_possible_dead_store_p (stmt, use_stmt))
return;
+ /* But only remove *this_2(D) ={v} {CLOBBER} if killed by
+ another clobber stmt. */
+ if (gimple_clobber_p (stmt)
+!gimple_clobber_p (use_stmt))
+ return;
Ah. Hmm, can that ever happen? I presume the issue with non-decl
clobbers is that we will never remove them, even if the storage
becomes dead?
See above.
@@ -827,7 +827,26 @@ remove_unused_locals (void)
if (gimple_clobber_p (stmt))
{
tree lhs = gimple_assign_lhs (stmt);
+ bool remove = false;
+ /* Remove clobbers referencing unused vars, or clobbers
+with MEM_REF lhs referencing unused vars or uninitialized
+pointers. */
if (TREE_CODE (lhs) == VAR_DECL !is_used_p (lhs))
+ remove = true;
+ else if (TREE_CODE (lhs) == MEM_REF)
+ {
+ ssa_op_iter iter;
+ tree op;
+ FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_USE)
The only SSA use on a clobber stmt can possibly be TREE_OPERAND (lhs, 0)
when lhs is a MEM_REF, no need to use FOR_EACH_SSA_TREE_OPERAND.
So just
+ else if (TREE_CODE (lhs) == MEM_REF
TREE_CODE (TREE_OPERAND (lhs, 0)) == SSA_NAME)
...
If MEM_REF[MEM_REF[...], 0] and similar won't ever get through, perhaps.
It won't, that's not valid GIMPLE. See is_gimple_mem_ref_addr ().
+ if (SSA_NAME_VAR (op)
+TREE_CODE (SSA_NAME_VAR (op)) == VAR_DECL
+!is_used_p (SSA_NAME_VAR (op)))
+ remove = true;
I'm not sure this is really desired ... isn't a better check to do
has_single_use (op)? (which means it would be better suited to
be handled in DCE?)
The above change fixed tons of ICEs, fnsplit pass ignored clobber stmts
(desirable) when deciding what to split, and end up copying the clobber
into the *.part.0 function, but because nothing but the clobber used
the this parameter, it wasn't passed. So, we ended up first referencing
a default definition of a local this variable (just useless stmt),
Re: SLP for vectors
On Mon, Apr 1, 2013 at 5:52 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sat, 30 Mar 2013, Marc Glisse wrote:
* tree-flow-inline.h (get_addr_base_and_unit_offset_1): Handle
BIT_FIELD_REF.
I wrote a safer version of this for PR52436:
That variant is ok - please test and commit separately.
Thanks,
Richard.
case BIT_FIELD_REF:
- return NULL_TREE;
+ {
+ HOST_WIDE_INT this_off = TREE_INT_CST_LOW (TREE_OPERAND (exp,
2));
+ if (this_off % BITS_PER_UNIT)
+ return NULL_TREE;
+ byte_offset += this_off / BITS_PER_UNIT;
+ }
+ break;
Re: SLP for vectors
On Sat, Mar 30, 2013 at 5:14 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Tue, 29 Jan 2013, Richard Biener wrote:
So yes, handling BIT_FIELD_REF in the vectorizer looks like the correct
way to do - but mind that you should constrain the BIT_FIELD_REFs you
allow (I suppose in the end that's properly done by other part of the
analysis).
Does that mean adding something like this to vectorizable_store? (and
similarly to *_load)
if (VECTOR_TYPE_P (TREE_TYPE (scalar_dest)))
return false;
Or maybe this?
if (TREE_CODE (scalar_dest) == BIT_FIELD_REF
!VECTOR_TYPE_P (TREE_TYPE (TREE_OPERAND (scalar_dest, 0)))
return false;
Or checking that the type of the BIT_FIELD_REF is the element type of the
vector type it accesses?
I am not sure what restrictions are needed.
I suppose the data-ref analysis parts are not strictly required,
I removed the dr_analyze_indices part, which was indeed not necessary. The
tree-vect-data-refs.c part is useless (the base object is not computed for
SLP) but shouldn't hurt.
The current patch is attached (passed bootstrap+testsuite a week ago).
Are there some parts of this that could go in?
The patch is ok apart from the tree-flow-inline.h parts where you have posted
a correct variant in a followup.
Thanks,
Richard.
2013-03-30 Marc Glisse marc.gli...@inria.fr
* tree-vect-stmts.c (vectorizable_store): Accept BIT_FIELD_REF.
(vectorizable_load): Likewise.
* tree-vect-slp.c (vect_build_slp_tree): Likewise.
* tree-vect-data-refs.c (vect_create_data_ref_ptr): Handle
VECTOR_TYPE.
* tree-flow-inline.h (get_addr_base_and_unit_offset_1): Handle
BIT_FIELD_REF.
testsuite/
* gcc.dg/vect/bb-slp-31.c: New file.
--
Marc Glisse
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 197265)
+++ tree-vect-data-refs.c (working copy)
@@ -3565,20 +3565,22 @@ vect_create_data_ref_ptr (gimple stmt, t
if (dump_enabled_p ())
{
tree dr_base_type = TREE_TYPE (DR_BASE_OBJECT (dr));
dump_printf_loc (MSG_NOTE, vect_location,
create %s-pointer variable to type: ,
tree_code_name[(int) TREE_CODE (aggr_type)]);
dump_generic_expr (MSG_NOTE, TDF_SLIM, aggr_type);
if (TREE_CODE (dr_base_type) == ARRAY_TYPE)
dump_printf (MSG_NOTE, vectorizing an array ref: );
+ else if (TREE_CODE (dr_base_type) == VECTOR_TYPE)
+dump_printf (MSG_NOTE, vectorizing a vector ref: );
else if (TREE_CODE (dr_base_type) == RECORD_TYPE)
dump_printf (MSG_NOTE, vectorizing a record based array ref: );
else
dump_printf (MSG_NOTE, vectorizing a pointer ref: );
dump_generic_expr (MSG_NOTE, TDF_SLIM, DR_BASE_OBJECT (dr));
}
/* (1) Create the new aggregate-pointer variable.
Vector and array types inherit the alias set of their component
type by default so we need to use a ref-all pointer if the data
Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c (revision 197265)
+++ tree-vect-stmts.c (working copy)
@@ -3844,20 +3844,21 @@ vectorizable_store (gimple stmt, gimple_
/* Is vectorizable store? */
if (!is_gimple_assign (stmt))
return false;
scalar_dest = gimple_assign_lhs (stmt);
if (TREE_CODE (scalar_dest) == VIEW_CONVERT_EXPR
is_pattern_stmt_p (stmt_info))
scalar_dest = TREE_OPERAND (scalar_dest, 0);
if (TREE_CODE (scalar_dest) != ARRAY_REF
+ TREE_CODE (scalar_dest) != BIT_FIELD_REF
TREE_CODE (scalar_dest) != INDIRECT_REF
TREE_CODE (scalar_dest) != COMPONENT_REF
TREE_CODE (scalar_dest) != IMAGPART_EXPR
TREE_CODE (scalar_dest) != REALPART_EXPR
TREE_CODE (scalar_dest) != MEM_REF)
return false;
gcc_assert (gimple_assign_single_p (stmt));
op = gimple_assign_rhs1 (stmt);
if (!vect_is_simple_use (op, stmt, loop_vinfo, bb_vinfo, def_stmt,
@@ -4378,20 +4379,21 @@ vectorizable_load (gimple stmt, gimple_s
/* Is vectorizable load? */
if (!is_gimple_assign (stmt))
return false;
scalar_dest = gimple_assign_lhs (stmt);
if (TREE_CODE (scalar_dest) != SSA_NAME)
return false;
code = gimple_assign_rhs_code (stmt);
if (code != ARRAY_REF
+ code != BIT_FIELD_REF
code != INDIRECT_REF
code != COMPONENT_REF
code != IMAGPART_EXPR
code != REALPART_EXPR
code != MEM_REF
TREE_CODE_CLASS (code) != tcc_declaration)
return false;
if (!STMT_VINFO_DATA_REF (stmt_info))
return false;
Index: tree-vect-slp.c
===
--- tree-vect-slp.c (revision 197265)
+++ tree-vect-slp.c (working copy)
@@ -660,20 +660,21 @@
Re: [PATCH] Fix cond_exec_find_if_block (PR rtl-optimization/56745)
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
Hi!
On the (undefined behavior) testcase below, we end up with
then_bb ending with __builtin_unreachable () at the tree level, therefore
no successor at the RTL level, and else_bb being EXIT_BLOCK_PTR (i.e.
conditional return before a bb with undefined behavior at the end).
Trying to optimize that into a conditional execution of the then_bb insns
doesn't work, we can't merge the else_bb with then_bb and test_bb in this
case, plus it doesn't look like something that would be desirable to do
(conditional return is surely better).
Fixed thusly, ok for trunk/4.8?
I wonder if
/* Make sure IF, THEN, and ELSE, blocks are adjacent. Actually, we get
the
first condition for free, since we've already asserted that there's a
fallthru edge from IF to THEN. Likewise for the and || blocks,
since
we checked the FALLTHRU flag, those are already adjacent to the last
IF
block. */
/* ??? As an enhancement, move the ELSE block. Have to deal with
BLOCK notes, if by no other means than backing out the merge if they
exist. Sticky enough I don't want to think about it now. */
next = then_bb;
if (else_bb (next = next-next_bb) != else_bb)
return FALSE;
if ((next = next-next_bb) != join_bb join_bb != EXIT_BLOCK_PTR)
{
if (else_bb)
join_bb = NULL;
else
return FALSE;
}
somehow tries to guard against join_bb == EXIT_BLOCK_PTR but fails.
Thus, why not do that explicitely here instead of just in the
single case you cover? (I can't see why join_bb could not be
set to EXIT_BLOCK_PTR in some weird case)
Richard.
2013-04-02 Jakub Jelinek ja...@redhat.com
PR rtl-optimization/56745
* ifcvt.c (cond_exec_find_if_block): Don't try to optimize
if then_bb has no successors and else_bb is EXIT_BLOCK_PTR.
* gcc.c-torture/compile/pr56745.c: New test.
--- gcc/ifcvt.c.jj2013-03-05 23:25:15.0 +0100
+++ gcc/ifcvt.c 2013-04-02 12:31:19.476859094 +0200
@@ -3473,7 +3473,7 @@ cond_exec_find_if_block (struct ce_if_bl
code processing. ??? we should fix this in the future. */
if (EDGE_COUNT (then_bb-succs) == 0)
{
- if (single_pred_p (else_bb))
+ if (single_pred_p (else_bb) else_bb != EXIT_BLOCK_PTR)
{
rtx last_insn = BB_END (then_bb);
--- gcc/testsuite/gcc.c-torture/compile/pr56745.c.jj 2013-04-02
12:38:54.718258527 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr56745.c 2013-04-02
12:33:22.0 +0200
@@ -0,0 +1,15 @@
+/* PR rtl-optimization/56745 */
+
+unsigned char a[6];
+
+void
+foo ()
+{
+ int i;
+ for (i = 5; i = 0; i++)
+{
+ if (++a[i] != 0)
+ break;
+ ++a[i];
+}
+}
Jakub
--
Richard Biener rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend
Re: [Patch, testsuite] Fix sra-13.c for 16 bit int
could someone please review and commit if it is OK? I don't have commit access. Regards, Pitchumani On 4/1/2013 4:30 PM, Pitchumani Sivanupandi wrote: Fix test case sra-13.c that assumed int is always 4 bytes. Regards, Pitchumani 2013-04-01 Pitchumani Sivanupandi pitchuman...@atmel.com testsuite * gcc.dg/tree-ssa/sra-13.c: Fix for 16 bit int --- gcc/testsuite/gcc.dg/tree-ssa/sra-13.c (revision 197081) +++ gcc/testsuite/gcc.dg/tree-ssa/sra-13.c (working copy) @@ -95,7 +95,7 @@ b = 0; gu1.b.l = 2000; s = bar (); - if (s != 2000) + if (s != (int)2000) __builtin_abort (); if (gu2.b.l != 2000) __builtin_abort ();
Re: [RFC PATCH] Implementing ifunc target hook
On Wed, Mar 27, 2013 at 01:56:48PM +0400, Kirill Yukhin wrote: Otherwise OK. Thanks, Hi, chacked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00785.html This leads to: ../../gcc/config/t-linux-android:22: warning: overriding recipe for target `linux-android.o' ../../gcc/config/t-linux-android:22: warning: ignoring old recipe for target `linux-android.o' for arm*-linux* target (cross in my case). t-linux-android is listed twice. Jakub
Re: [patch i386 windows]: Fix PR/52790 also required for workig upcoming cygwin x64 target
Ping ^2 - Original Message - From: Kai Tietz ktiet...@googlemail.com To: GCC Patches gcc-patches@gcc.gnu.org Cc: Richard Henderson r...@redhat.com Sent: Thursday, March 28, 2013 2:35:15 PM Subject: Re: [patch i386 windows]: Fix PR/52790 also required for workig upcoming cygwin x64 target Ping
Re: [PATCH] Fix cond_exec_find_if_block (PR rtl-optimization/56745)
On Tue, Apr 02, 2013 at 02:57:13PM +0200, Richard Biener wrote:
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
On the (undefined behavior) testcase below, we end up with
then_bb ending with __builtin_unreachable () at the tree level, therefore
no successor at the RTL level, and else_bb being EXIT_BLOCK_PTR (i.e.
conditional return before a bb with undefined behavior at the end).
Trying to optimize that into a conditional execution of the then_bb insns
doesn't work, we can't merge the else_bb with then_bb and test_bb in this
case, plus it doesn't look like something that would be desirable to do
(conditional return is surely better).
Fixed thusly, ok for trunk/4.8?
I wonder if
/* Make sure IF, THEN, and ELSE, blocks are adjacent. Actually, we get
the
first condition for free, since we've already asserted that there's a
fallthru edge from IF to THEN. Likewise for the and || blocks,
since
we checked the FALLTHRU flag, those are already adjacent to the last
IF
block. */
/* ??? As an enhancement, move the ELSE block. Have to deal with
BLOCK notes, if by no other means than backing out the merge if they
exist. Sticky enough I don't want to think about it now. */
next = then_bb;
if (else_bb (next = next-next_bb) != else_bb)
return FALSE;
if ((next = next-next_bb) != join_bb join_bb != EXIT_BLOCK_PTR)
{
if (else_bb)
join_bb = NULL;
else
return FALSE;
}
somehow tries to guard against join_bb == EXIT_BLOCK_PTR but fails.
Thus, why not do that explicitely here instead of just in the
single case you cover? (I can't see why join_bb could not be
set to EXIT_BLOCK_PTR in some weird case)
From my reading of the code, it can handle the normal case where
join_bb is EXIT_BLOCK_PTR just fine, provided that single_succ (then_bb)
== join_bb and !else_bb || single_succ (else_bb) == join_bb.
The ICE is there only because of the extra optimization I've tweaked,
the problem is there that then_bb has no successors and join_bb is
EXIT_BLOCK_PTR, so while then_bb can be successfully merged together with
test_bb, it has no successor and as join_bb is EXIT_BLOCK_PTR, we just give
up. If then_bb has no successor and join_bb isn't EXIT_BLOCK_PTR, we'd
normally do:
else if (EDGE_COUNT (join_bb-preds) 2
join_bb != EXIT_BLOCK_PTR)
{
/* We can merge the JOIN cleanly and update the dataflow try
again on this pass.*/
merge_blocks (combo_bb, join_bb);
num_true_changes++;
}
and all is fine, and if then_bb (and else_bb if it exists) has a single
successor of join_bb, all is fine too.
Jakub
[C++ Patch] Use TYPE_ALIAS_P, COMPLETE_OR_OPEN_TYPE_P, TYPE_TI_ARGS
Hi,
I think this is my last obvious clean-up for now. I'm going to commit it
when testing on x86_64-linux completes.
Thanks,
Paolo.
//
2013-04-02 Paolo Carlini paolo.carl...@oracle.com
* friend.c (do_friend): Use COMPLETE_OR_OPEN_TYPE_P.
* pt.c (find_parameter_packs_r): Use TYPE_ALIAS_P and TYPE_TI_ARGS.
(for_each_template_parm_r): Use TYPE_TI_ARGS.
Index: friend.c
===
--- friend.c(revision 197346)
+++ friend.c(working copy)
@@ -485,8 +485,7 @@ do_friend (tree ctype, tree declarator, tree decl,
to be a friend, so we do lookup here even if CTYPE is in
the process of being defined. */
if (class_template_depth
- || COMPLETE_TYPE_P (ctype)
- || (CLASS_TYPE_P (ctype) TYPE_BEING_DEFINED (ctype)))
+ || COMPLETE_OR_OPEN_TYPE_P (ctype))
{
if (DECL_TEMPLATE_INFO (decl))
/* DECL is a template specialization. No need to
Index: pt.c
===
--- pt.c(revision 197347)
+++ pt.c(working copy)
@@ -3058,10 +3058,7 @@ find_parameter_packs_r (tree *tp, int *walk_subtre
bool parameter_pack_p = false;
/* Handle type aliases/typedefs. */
- if (TYPE_P (t)
- TYPE_NAME (t)
- TREE_CODE (TYPE_NAME (t)) == TYPE_DECL
- TYPE_DECL_ALIAS_P (TYPE_NAME (t)))
+ if (TYPE_ALIAS_P (t))
{
if (TYPE_TEMPLATE_INFO (t))
cp_walk_tree (TYPE_TI_ARGS (t),
@@ -3146,7 +3143,7 @@ find_parameter_packs_r (tree *tp, int *walk_subtre
case UNION_TYPE:
case ENUMERAL_TYPE:
if (TYPE_TEMPLATE_INFO (t))
- cp_walk_tree (TI_ARGS (TYPE_TEMPLATE_INFO (t)),
+ cp_walk_tree (TYPE_TI_ARGS (t),
find_parameter_packs_r, ppd, ppd-visited);
*walk_subtrees = 0;
@@ -7619,7 +7616,7 @@ for_each_template_parm_r (tree *tp, int *walk_subt
case ENUMERAL_TYPE:
if (!TYPE_TEMPLATE_INFO (t))
*walk_subtrees = 0;
- else if (for_each_template_parm (TI_ARGS (TYPE_TEMPLATE_INFO (t)),
+ else if (for_each_template_parm (TYPE_TI_ARGS (t),
fn, data, pfd-visited,
pfd-include_nondeduced_p))
return error_mark_node;
Re: [PATCH] Fix cond_exec_find_if_block (PR rtl-optimization/56745)
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
On Tue, Apr 02, 2013 at 02:57:13PM +0200, Richard Biener wrote:
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
On the (undefined behavior) testcase below, we end up with
then_bb ending with __builtin_unreachable () at the tree level, therefore
no successor at the RTL level, and else_bb being EXIT_BLOCK_PTR (i.e.
conditional return before a bb with undefined behavior at the end).
Trying to optimize that into a conditional execution of the then_bb insns
doesn't work, we can't merge the else_bb with then_bb and test_bb in this
case, plus it doesn't look like something that would be desirable to do
(conditional return is surely better).
Fixed thusly, ok for trunk/4.8?
I wonder if
/* Make sure IF, THEN, and ELSE, blocks are adjacent. Actually, we get
the
first condition for free, since we've already asserted that there's a
fallthru edge from IF to THEN. Likewise for the and || blocks,
since
we checked the FALLTHRU flag, those are already adjacent to the last
IF
block. */
/* ??? As an enhancement, move the ELSE block. Have to deal with
BLOCK notes, if by no other means than backing out the merge if they
exist. Sticky enough I don't want to think about it now. */
next = then_bb;
if (else_bb (next = next-next_bb) != else_bb)
return FALSE;
if ((next = next-next_bb) != join_bb join_bb != EXIT_BLOCK_PTR)
{
if (else_bb)
join_bb = NULL;
else
return FALSE;
}
somehow tries to guard against join_bb == EXIT_BLOCK_PTR but fails.
Thus, why not do that explicitely here instead of just in the
single case you cover? (I can't see why join_bb could not be
set to EXIT_BLOCK_PTR in some weird case)
From my reading of the code, it can handle the normal case where
join_bb is EXIT_BLOCK_PTR just fine, provided that single_succ (then_bb)
== join_bb and !else_bb || single_succ (else_bb) == join_bb.
The ICE is there only because of the extra optimization I've tweaked,
the problem is there that then_bb has no successors and join_bb is
EXIT_BLOCK_PTR, so while then_bb can be successfully merged together with
test_bb, it has no successor and as join_bb is EXIT_BLOCK_PTR, we just give
up. If then_bb has no successor and join_bb isn't EXIT_BLOCK_PTR, we'd
normally do:
else if (EDGE_COUNT (join_bb-preds) 2
join_bb != EXIT_BLOCK_PTR)
{
/* We can merge the JOIN cleanly and update the dataflow try
again on this pass.*/
merge_blocks (combo_bb, join_bb);
num_true_changes++;
}
and all is fine, and if then_bb (and else_bb if it exists) has a single
successor of join_bb, all is fine too.
Ah, I see. The patch is ok then.
Thanks,
Richard.
Re: patch to fix constant math - first small patch - patch ping for the next stage 1
Richard,
did everything that you asked here. bootstrapped and regtested on
x86-64. ok to commit?
kenny
On 04/02/2013 05:38 AM, Richard Biener wrote:
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richard,
I was able to add everything except for the checking asserts.While I
think that this is a reasonable idea, it is difficult to add that to a
function that is defined in hwint.h because of circular includes. I could
move this another file (though this appears to be the logical correct place
for it), or we can do without the asserts.
The context is that [sz]ext_hwi is that are used are over the compiler but
are generally written out long. The wide-int class uses them also, but
wide-int did not see like the right place for them to live and i believe
that you suggested that i move them.
ok to commit, or do you have a suggested resolution to the assert issue?
Yes, do
#ifdef ENABLE_CHECKING
extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
#else
+/* Sign extend SRC starting from PREC. */
+
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+{
int shift = HOST_BITS_PER_WIDE_INT - prec;
+ return (src shift) shift;
+}
+}
#endif
and for ENABLE_CHECKING only provide an out-of-line implementation
in hwint.c. That's how we did it with abs_hwi (well, we just do not provide
an inline variant there - that's another possibility).
Note that hwint.h is always included after config.h so the ENABLE_CHECKING
definition should be available.
Richard.
kenny
On 03/27/2013 10:13 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the first of my wide int patches with joseph's comments and the
patch rot removed.
I would like to get these pre approved for the next stage 1.
+ int shift = HOST_BITS_PER_WIDE_INT - (prec
(HOST_BITS_PER_WIDE_INT - 1));
I think this should gcc_checking_assert that prec is not out of range
(any reason why prec is signed int and not unsigned int?) rather than
ignore bits in prec.
+static inline HOST_WIDE_INT
+zext_hwi (HOST_WIDE_INT src, int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+return src (((HOST_WIDE_INT)1
+ (prec (HOST_BITS_PER_WIDE_INT - 1))) - 1);
+}
likewise. Also I'm not sure I agree about the signedness of the result /
src.
zext_hwi (-1, HOST_BITS_PER_WIDE_INT) 0 is true which is odd.
The patch misses context of uses, so I'm not sure what the above functions
are intended to do.
Richard.
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT h
This may cause problems on hosts not supporting %hd (MinGW?), and
there's
no real need for using h here given the promotion of short to int; you
can just use (rather than e.g. needing special handling in
xm-mingw32.h
like is done for HOST_LONG_LONG_FORMAT).
2013-4-02 Kenneth Zadeck zad...@naturalbridge.com
* hwint.c (sext_hwi, zext_hwi): New functions.
* hwint.h (HOST_BITS_PER_HALF_WIDE_INT, HOST_HALF_WIDE_INT,
HOST_HALF_WIDE_INT_PRINT, HOST_HALF_WIDE_INT_PRINT_C,
HOST_HALF_WIDE_INT_PRINT_DEC, HOST_HALF_WIDE_INT_PRINT_DEC_C,
HOST_HALF_WIDE_INT_PRINT_UNSIGNED, HOST_HALF_WIDE_INT_PRINT_HEX,
HOST_HALF_WIDE_INT_PRINT_HEX_PURE): New symbols.
(sext_hwi, zext_hwi): New functions.
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,33 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT b)
{
return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
}
+
+#ifndef ENABLE_CHECKING
+/* Sign extend SRC starting from PREC. */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+{
+ int shift = HOST_BITS_PER_WIDE_INT -
+ (prec (HOST_BITS_PER_WIDE_INT - 1));
+ return (src shift) shift;
+}
+}
+
+/* Zero extend SRC starting from PREC. */
+
+unsigned HOST_WIDE_INT
+zext_hwi (unsigned HOST_WIDE_INT src, unsigned int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+return src (((HOST_WIDE_INT)1
+ (prec (HOST_BITS_PER_WIDE_INT - 1))) - 1);
+}
+
+#endif
diff --git a/gcc/hwint.h b/gcc/hwint.h
index da62fad..9dddf05 100644
--- a/gcc/hwint.h
+++ b/gcc/hwint.h
@@ -76,6 +76,40 @@ extern char sizeof_long_long_must_be_8[sizeof(long long) == 8 ? 1 : -1];
# endif
#endif
+/* Print support for half a host wide int. */
+#define HOST_BITS_PER_HALF_WIDE_INT (HOST_BITS_PER_WIDE_INT / 2)
+#if HOST_BITS_PER_HALF_WIDE_INT == HOST_BITS_PER_LONG
+# define HOST_HALF_WIDE_INT long
+# define HOST_HALF_WIDE_INT_PRINT HOST_LONG_FORMAT
+# define HOST_HALF_WIDE_INT_PRINT_C L
+# define HOST_HALF_WIDE_INT_PRINT_DEC %
Re: [RFC PATCH] Implementing ifunc target hook
Yep.. we missed that:
t-linux-android was added here:
# Add Android userspace support to Linux targets.
case $target in
*linux*)
tm_p_file=${tm_p_file} linux-protos.h
tmake_file=${tmake_file} t-linux-android
tm_file=$tm_file linux-android.h
extra_options=$extra_options linux-android.opt
extra_objs=$extra_objs linux-android.o
;;
esac
and here:
arm*-*-linux-*) # ARM GNU/Linux with ELF
tm_file=dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h
case $target in
arm*b-*-linux*)
tm_defines=${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1
;;
esac
tmake_file=${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi
arm/t-linux-eabi t-linux-android
tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h arm/arm.h
extra_objs=$extra_objs linux-android.o
# Define multilib configuration for arm-linux-androideabi.
case ${target} in
*-androideabi)
tmake_file=$tmake_file arm/t-linux-androideabi
;;
esac
I deleted the second encounter:
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d18c6e9..0e1d5e4 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2013-04-02 Alexander Ivchenko alexander.ivche...@intel.com
+
+ * config.gcc (arm*-*-linux-*): Remove duplicate t-linux-android.
+
2013-04-02 Richard Biener rguent...@suse.de
PR tree-optimization/56778
diff --git a/gcc/config.gcc b/gcc/config.gcc
index e51db91..44ed190 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -878,7 +878,7 @@ arm*-*-linux-*) # ARM GNU/Linux with ELF
tm_defines=${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1
;;
esac
- tmake_file=${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi
arm/t-linux-eabi t-linux-android
+ tmake_file=${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi
arm/t-linux-eabi
tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h arm/arm.h
extra_objs=$extra_objs linux-android.o
# Define multilib configuration for arm-linux-androideabi.
is it ok?
thanks,
Alexander
2013/4/2 Jakub Jelinek ja...@redhat.com:
On Wed, Mar 27, 2013 at 01:56:48PM +0400, Kirill Yukhin wrote:
Otherwise OK.
Thanks,
Hi, chacked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00785.html
This leads to:
../../gcc/config/t-linux-android:22: warning: overriding recipe for target
`linux-android.o'
../../gcc/config/t-linux-android:22: warning: ignoring old recipe for target
`linux-android.o'
for arm*-linux* target (cross in my case). t-linux-android is listed twice.
Jakub
Re: [RFC PATCH] Implementing ifunc target hook
On Tue, Apr 02, 2013 at 06:24:06PM +0400, Alexander Ivchenko wrote:
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2013-04-02 Alexander Ivchenko alexander.ivche...@intel.com
+
+ * config.gcc (arm*-*-linux-*): Remove duplicate t-linux-android.
+
2013-04-02 Richard Biener rguent...@suse.de
PR tree-optimization/56778
diff --git a/gcc/config.gcc b/gcc/config.gcc
index e51db91..44ed190 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -878,7 +878,7 @@ arm*-*-linux-*) # ARM GNU/Linux with
ELF
tm_defines=${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1
;;
esac
- tmake_file=${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi
arm/t-linux-eabi t-linux-android
+ tmake_file=${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi
arm/t-linux-eabi
tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h arm/arm.h
extra_objs=$extra_objs linux-android.o
# Define multilib configuration for arm-linux-androideabi.
is it ok?
Yes.
Jakub
Re: [RFC PATCH] Implementing ifunc target hook
Hi, is it ok? Yes. Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-04/msg00066.html Thanks, K
Results for 4.9.0 20130401 (experimental) [trunk revision 197313] (GCC) testsuite on powerpc-ibm-aix7.1.0.0
LAST_UPDATED: Mon Apr 1 18:01:32 UTC 2013 (revision 197313) Native configuration is powerpc-ibm-aix7.1.0.0 === g++ tests === Running target unix FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_x_tst.o-cp_compat_y_tst.o execute XPASS: g++.dg/debug/pr56294.C -gxcoff1 (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff3 (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff+1 (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff+ (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff+3 (test for excess errors) FAIL: g++.dg/abi/anon1.C -std=c++98 scan-assembler-not globl FAIL: g++.dg/abi/anon1.C -std=c++11 scan-assembler-not globl FAIL: g++.dg/abi/vtt1.C -std=c++98 scan-assembler _ZTT1B FAIL: g++.dg/abi/vtt1.C -std=c++11 scan-assembler _ZTT1B FAIL: g++.dg/cpp/ucn-1.C (test for excess errors) FAIL: g++.dg/ext/alignof2.C -std=c++98 execution test FAIL: g++.dg/ext/alignof2.C -std=c++11 execution test FAIL: g++.dg/ext/visibility/anon1.C -std=c++98 scan-assembler-not globl.*_ZN.*1fEv FAIL: g++.dg/ext/visibility/anon1.C -std=c++11 scan-assembler-not globl.*_ZN.*1fEv FAIL: g++.dg/ext/visibility/anon2.C -std=c++98 scan-assembler-not globl.*_Z1fv FAIL: g++.dg/ext/visibility/anon2.C -std=c++11 scan-assembler-not globl.*_Z1fv FAIL: g++.dg/init/new40.C -std=c++98 execution test FAIL: g++.dg/init/new40.C -std=c++11 execution test FAIL: g++.dg/init/ref15.C -std=c++98 execution test FAIL: g++.dg/init/ref15.C -std=c++11 execution test FAIL: g++.dg/template/linkage1.C -std=c++11 scan-assembler-not (weak|glob)[^\\n]*_Z3fooIXadL_ZL11static_funcvEEEvv FAIL: g++.dg/warn/pr31246.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/warn/pr31246.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/gomp/tls-5.C -std=c++11 scan-assembler-not .data FAIL: g++.dg/tls/thread_local-order1.C execution test FAIL: g++.dg/tls/thread_local1.C scan-assembler-not .comm FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local3g.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local4g.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local5g.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local6.C execution test FAIL: g++.dg/tls/thread_local6g.C execution test FAIL: g++.dg/tls/thread_local7.C scan-assembler-not .data FAIL: g++.dg/tls/thread_local7g.C scan-assembler-not .data FAIL: c-c++-common/torture/vshuf-v2di.c -O1 (internal compiler error) FAIL: c-c++-common/torture/vshuf-v2di.c -O1 (test for excess errors) FAIL: g++.dg/torture/vshuf-v2di.C -O1 (internal compiler error) FAIL: g++.dg/torture/vshuf-v2di.C -O1 (test for excess errors) WARNING: g++.dg/torture/vshuf-v2di.C -O1 compilation failed to produce executable FAIL: g++.old-deja/g++.other/init18.C -std=c++98 execution test FAIL: g++.old-deja/g++.other/init18.C -std=c++11 execution test FAIL: g++.old-deja/g++.other/init19.C -std=c++98 execution test FAIL: g++.old-deja/g++.other/init19.C -std=c++11 execution test FAIL: g++.old-deja/g++.pt/static11.C -std=c++98 execution test FAIL: g++.old-deja/g++.pt/static11.C -std=c++11 execution test === g++ Summary === # of expected passes45838 # of unexpected failures45 # of unexpected successes6 # of expected failures326 # of unsupported tests1042 /tmp/20130401/gcc/testsuite/g++/../../xg++ version 4.9.0 20130401 (experimental) [trunk revision 197313] (GCC) === gcc tests === Running target unix FAIL: gcc.c-torture/compile/930421-1.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/930421-1.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/execute/eeprof-1.c execution, -O0 FAIL: gcc.c-torture/execute/eeprof-1.c execution, -O1 FAIL: gcc.c-torture/execute/eeprof-1.c execution, -O2 FAIL: gcc.c-torture/execute/eeprof-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/eeprof-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/eeprof-1.c execution, -Os FAIL: gcc.c-torture/execute/eeprof-1.c execution, -Og -g FAIL: gcc.dg/cpp/assert4.c (test for excess errors) FAIL: gcc.dg/cpp/trad/include.c (test for excess errors) FAIL: gcc.dg/alias-7.c execution test FAIL: gcc.dg/asm-names.c scan-assembler-not frob14 FAIL: c-c++-common/torture/vshuf-v2di.c -O1 (internal compiler error) FAIL: c-c++-common/torture/vshuf-v2di.c -O1 (test for excess errors) FAIL: gcc.dg/tree-ssa/sra-12.c scan-tree-dump-times release_ssa l; 0 FAIL:
Re: [C++ Patch] Use TYPE_ALIAS_P, COMPLETE_OR_OPEN_TYPE_P, TYPE_TI_ARGS
On Tue, Apr 2, 2013 at 8:34 AM, Paolo Carlini paolo.carl...@oracle.com wrote: Hi, I think this is my last obvious clean-up for now. I'm going to commit it when testing on x86_64-linux completes. thanks. -- Gaby
Re: patch to fix constant math - first small patch - patch ping for the next stage 1
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
Richard,
did everything that you asked here. bootstrapped and regtested on x86-64.
ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,33 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT b)
{
return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
}
+
+#ifndef ENABLE_CHECKING
+/* Sign extend SRC starting from PREC. */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
this should go to hwint.h, and without the masking of prec.
while ...
diff --git a/gcc/hwint.h b/gcc/hwint.h
index da62fad..9dddf05 100644
--- a/gcc/hwint.h
+++ b/gcc/hwint.h
@@ -276,4 +316,42 @@ extern HOST_WIDE_INT pos_mul_hwi (HOST_WIDE_INT,
HOST_WIDE_INT);
extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
extern HOST_WIDE_INT least_common_multiple (HOST_WIDE_INT, HOST_WIDE_INT);
+/* Sign extend SRC starting from PREC. */
+
+#ifdef ENABLE_CHECKING
+extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
+#else
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+ gcc_checking_assert (prec = HOST_BITS_PER_WIDE_INT);
this should go to hwint.c (also without masking prec).
Richard.
kenny
On 04/02/2013 05:38 AM, Richard Biener wrote:
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richard,
I was able to add everything except for the checking asserts.While I
think that this is a reasonable idea, it is difficult to add that to a
function that is defined in hwint.h because of circular includes. I
could
move this another file (though this appears to be the logical correct
place
for it), or we can do without the asserts.
The context is that [sz]ext_hwi is that are used are over the compiler
but
are generally written out long. The wide-int class uses them also, but
wide-int did not see like the right place for them to live and i believe
that you suggested that i move them.
ok to commit, or do you have a suggested resolution to the assert issue?
Yes, do
#ifdef ENABLE_CHECKING
extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
#else
+/* Sign extend SRC starting from PREC. */
+
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+{
int shift = HOST_BITS_PER_WIDE_INT - prec;
+ return (src shift) shift;
+}
+}
#endif
and for ENABLE_CHECKING only provide an out-of-line implementation
in hwint.c. That's how we did it with abs_hwi (well, we just do not
provide
an inline variant there - that's another possibility).
Note that hwint.h is always included after config.h so the ENABLE_CHECKING
definition should be available.
Richard.
kenny
On 03/27/2013 10:13 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the first of my wide int patches with joseph's comments and the
patch rot removed.
I would like to get these pre approved for the next stage 1.
+ int shift = HOST_BITS_PER_WIDE_INT - (prec
(HOST_BITS_PER_WIDE_INT - 1));
I think this should gcc_checking_assert that prec is not out of range
(any reason why prec is signed int and not unsigned int?) rather than
ignore bits in prec.
+static inline HOST_WIDE_INT
+zext_hwi (HOST_WIDE_INT src, int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+return src (((HOST_WIDE_INT)1
+ (prec (HOST_BITS_PER_WIDE_INT - 1))) - 1);
+}
likewise. Also I'm not sure I agree about the signedness of the result
/
src.
zext_hwi (-1, HOST_BITS_PER_WIDE_INT) 0 is true which is odd.
The patch misses context of uses, so I'm not sure what the above
functions
are intended to do.
Richard.
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT h
This may cause problems on hosts not supporting %hd (MinGW?), and
there's
no real need for using h here given the promotion of short to int;
you
can just use (rather than e.g. needing special handling in
xm-mingw32.h
like is done for HOST_LONG_LONG_FORMAT).
Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch contains a large number of the changes requested by Richi. It
does not contain any of the changes that he requested to abstract the
storage layer. That suggestion appears to be quite unworkable.
I of course took this claim as a challenge ... with the following result. It is
of course quite workable ;)
The attached patch implements the core wide-int class and three storage
models (fixed size for things like plain HWI and double-int, variable size
similar to how your wide-int works and an adaptor for the double-int as
contained in trees). With that you can now do
HOST_WIDE_INT
wi_test (tree x)
{
// template argument deduction doesn't do the magic we want it to do
// to make this kind of implicit conversions work
// overload resolution considers this kind of conversions so we
// need some magic that combines both ... but seeding the overload
// set with some instantiations doesn't seem to be possible :/
// wide_int w = x + 1;
wide_int w;
w += x;
w += 1;
// template argument deduction doesn't deduce the return value type,
// not considering the template default argument either ...
// w = wi (x) + 1;
// we could support this by providing rvalue-to-lvalue promotion
// via a traits class?
// otoh it would lead to sub-optimal code anyway so we should
// make the result available as reference parameter and only support
// wide_int res; add (res, x, 1); ?
w = wi (x).operator+wide_int (1);
wide_int::add(w, x, 1);
return w.to_hwi ();
}
we are somewhat limited with C++ unless we want to get really fancy.
Eventually providing operator+ just doesn't make much sense for
generic wide-int combinations (though then the issue is its operands
are no longer commutative which I think is the case with your wide-int
or double-int as well - they don't suport 1 + wide_int for obvious reasons).
So there are implementation design choices left undecided.
Oh, and the operation implementations are crap (they compute nonsense).
But you should get the idea.
Richard.
#include config.h
#include system.h
#include coretypes.h
#include hwint.h
#include tree.h
/* ??? wide-int should probably use HOST_WIDEST_FAST_INT as storage,
not HOST_WIDE_INT. Yeah, we could even template on that ... */
/* Fixed-length embedded storage. wi_embed2 is double-int,
wi_embed1 is a plain HOST_WIDE_INT. Can be used for
small fixed-(minimum)-size calculations on hosts that have
no suitable integer type. */
template unsigned sz
class wi_embed
{
private:
HOST_WIDE_INT s[sz];
public:
void construct () {}
HOST_WIDE_INT* storage() { return s; }
const HOST_WIDE_INT* storage() const { return s; }
unsigned len() const { return sz; }
void set_len(unsigned l) { gcc_checking_assert (l = sz); }
};
/* Fixed maximum-length embedded storage but variable dynamic size. */
//#define MAXSZ (4 * (MAX_MODE_INT_SIZE / HOST_BITS_PER_WIDE_INT))
#define MAXSZ 8
template unsigned max_sz
class wi_embed_var
{
private:
unsigned len_;
HOST_WIDE_INT s[max_sz];
public:
void construct () { len_ = 0; }
HOST_WIDE_INT* storage() { return s; }
const HOST_WIDE_INT* storage() const { return s; }
unsigned len() const { return len_; }
void set_len(unsigned l) { len_ = l; }
};
/* The wide-int class. Defaults to variable-length storage
(alternatively use a typedef to avoid the need to use wide_int ). */
template class S = wi_embed_varMAXSZ
class wide_int;
/* Avoid constructors / destructors to make sure this is a C++04 POD. */
/* Basic wide_int class. The storage model allows for rvalue
storage abstraction avoiding copying from for example tree
or RTX and to avoid the need of explicit construction for
integral arguments of up to HWI size.
A storage model needs to provide the following methods:
- construct (), default-initialize the storage
- unsigned len () const, the size of the storage in HWI quantities
- const HOST_WIDE_INT *storage () const, return a pointer
to read-only HOST_WIDE_INT storage of size len ().
- HOST_WIDE_INT *storage (), return a pointer to writable
HOST_WIDE_INT storage of size len (). This method is optional.
- void set_len (unsigned l), adjust the size of the storage
to at least l HWI words.
Conversions of wide_int _to_ tree or RTX or HWI are explicit.
Conversions to wide_int happen with overloads to the global
function template wi () or via wide_int_traits specializations. */
/* ??? With mixed length operations there are encoding issues
for signed vs. unsigned numbers. The easiest encoding is to
say wide-ints are always signed which means that -1U needs
the MSB of the wide-int storage as zero which means an extra
word with zeros. The sign-bit of a wide-int is then always
storage()[len() (1 (HOST_BITS_PER_WIDE_INT - 1))]. */
template class S
class wide_int : private S
{
/* Allow
[PATCH] PR56771: Fix arm-rtems target for 32-bit hosts
This patch is for GCC 4.6 and 4.7. libcpp/ChangeLog 2013-04-02 Sebastian Huber sebastian.hu...@embedded-brains.de PR target/56771 * configure.ac: Require 64-bit int for arm*-*-rtems[.0-9]*. * configure: Regenerate. --- libcpp/configure|1 + libcpp/configure.ac |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libcpp/configure b/libcpp/configure index fb5654d..1e351fa 100755 --- a/libcpp/configure +++ b/libcpp/configure @@ -7370,6 +7370,7 @@ fi case $target in alpha*-*-* | \ arm*-*-*eabi* | \ + arm*-*-rtems[.0-9]* | \ arm*-*-symbianelf* | \ x86_64-*-* | \ ia64-*-* | \ diff --git a/libcpp/configure.ac b/libcpp/configure.ac index 070ab63..6d525ec 100644 --- a/libcpp/configure.ac +++ b/libcpp/configure.ac @@ -150,6 +150,7 @@ m4_changequote(,) case $target in alpha*-*-* | \ arm*-*-*eabi* | \ + arm*-*-rtems[.0-9]* | \ arm*-*-symbianelf* | \ x86_64-*-* | \ ia64-*-* | \ -- 1.7.7
[PATCH v2] PR56771: Fix arm-rtems target for 32-bit hosts
This patch is for GCC 4.8 and 4.9. v2: Fix ChangeLog. libcpp/ChangeLog 2013-04-02 Sebastian Huber sebastian.hu...@embedded-brains.de PR target/56771 * configure.ac: Require 64-bit int for arm*-*-rtems*. * configure: Regenerate. --- libcpp/configure|1 + libcpp/configure.ac |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libcpp/configure b/libcpp/configure index f21b361..7158186 100755 --- a/libcpp/configure +++ b/libcpp/configure @@ -7153,6 +7153,7 @@ case $target in aarch64*-*-* | \ alpha*-*-* | \ arm*-*-*eabi* | \ + arm*-*-rtems* | \ arm*-*-symbianelf* | \ x86_64-*-* | \ ia64-*-* | \ diff --git a/libcpp/configure.ac b/libcpp/configure.ac index e0c4ae6..43ac9ba 100644 --- a/libcpp/configure.ac +++ b/libcpp/configure.ac @@ -185,6 +185,7 @@ case $target in aarch64*-*-* | \ alpha*-*-* | \ arm*-*-*eabi* | \ + arm*-*-rtems* | \ arm*-*-symbianelf* | \ x86_64-*-* | \ ia64-*-* | \ -- 1.7.7
Re: RFC: add some static probes to libstdc++
On 15 March 2013 08:55, Jakub Jelinek ja...@redhat.com wrote: On Thu, Feb 28, 2013 at 08:32:02AM -0700, Tom Tromey wrote: 2013-02-27 Tom Tromey tro...@redhat.com * libsupc++/unwind-cxx.h: Include sys/sdt.h if detected. (PROBE2): New macro. * libsupc++/eh_throw.cc (__cxa_throw, __cxa_rethrow): Add probe. * libsupc++/eh_catch.cc (__cxa_begin_catch): Add probe. * configure.ac: Check for sys/sdt.h. * configure, config.h.in: Rebuild. This is ok. As we are close to 4.8.0-rc1, I went ahead and committed it for you. Jakub This change is causing a few problems, it looks as though older versions of Systemtap headers are incompatible with C++11 due to the UDL/whitespace issues described at http://gcc.gnu.org/gcc-4.7/porting_to.html e.g. http://gcc.gnu.org/ml/gcc-help/2013-04/msg00011.html Should we update the prerequisites documentation to say that if Systemtap is installed it needs to be at least version X?
Re: [RTL] Canonicalize commutative operations more
On 04/02/2013 04:54 AM, Eric Botcazou wrote: I wonder if those issues might in most cases be bugs in the back-ends (optimizations missed depending on the order), that the canonicalization would make more noticable (and thus easier to fix). There are certainly such issues in the back-ends (and even ??? comments about it) so sensible canonicalization is desirable. Right. The choice between canonicalization and code bloat to support multiple RTL forms computing the same value is a never-ending problem. Where it's clearly made sense we have canonicalized, where it doesn't, we haven't. There's a huge no-mans land in the middle. Jeff
Re: RFC: add some static probes to libstdc++
On Tue, 2 Apr 2013, Jonathan Wakely wrote: On 15 March 2013 08:55, Jakub Jelinek ja...@redhat.com wrote: On Thu, Feb 28, 2013 at 08:32:02AM -0700, Tom Tromey wrote: 2013-02-27 Tom Tromey tro...@redhat.com * libsupc++/unwind-cxx.h: Include sys/sdt.h if detected. (PROBE2): New macro. * libsupc++/eh_throw.cc (__cxa_throw, __cxa_rethrow): Add probe. * libsupc++/eh_catch.cc (__cxa_begin_catch): Add probe. * configure.ac: Check for sys/sdt.h. * configure, config.h.in: Rebuild. This is ok. As we are close to 4.8.0-rc1, I went ahead and committed it for you. Jakub This change is causing a few problems, it looks as though older versions of Systemtap headers are incompatible with C++11 due to the UDL/whitespace issues described at http://gcc.gnu.org/gcc-4.7/porting_to.html e.g. http://gcc.gnu.org/ml/gcc-help/2013-04/msg00011.html Should we update the prerequisites documentation to say that if Systemtap is installed it needs to be at least version X? I thought you were going to suggest enhancing the configure test so it fails on old systemtap (detects it as absent). -- Marc Glisse
RE: [PATCH][ARM] minmax_arithsi for non-canonical operand order with MINUS operator
From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
Sent: 02 April 2013 11:10
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw; Ramana Radhakrishnan
Subject: Re: [PATCH][ARM] minmax_arithsi for non-canonical operand
order with MINUS operator
On Thu, Mar 21, 2013 at 6:09 PM, Kyrylo Tkachov
kyrylo.tkac...@arm.com wrote:
Hi all,
This patch adds a splitter variant of the minmax_arithsi pattern for
when
the operator
is non-commutative (MINUS) and the ordering of the operands is not
canonical.
That is, it will trigger for:
#define MAX(a, b) (a b ? a : b)
int
foo (int a, int b, int c)
{
return c - MAX (a,b);
}
and will generate:
cmp r1, r0
rsbge r0, r1, r2
rsblt r0, r0, r2
instead of the current:
cmp r0, r1
movlt r0, r1
rsb r0, r0, r2
No regressions on arm-none-eabi.
Ok for trunk?
Split after reload please into cond-exec or use if_then_else instead
if you are splitting before reload - I originally thought it to be
safe when you asked me, but then have gone back and corrected myself.
Read this thread . http://patches.linaro.org/6469/ .
Hi Ramana, thanks for the review.
How about this? We split after reload now.
Using if_then_else got me a lot of unrecognisable instruction ICEs and
delaying the split till after reload seemed like a cleaner approach.
Tested arm-none-eabi on qemu.
gcc/
2013-04-02 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/arm.md (minmax_arithsi_non_canon): New pattern.
gcc/testsuite
2013-04-02 Kyrylo Tkachov kyrylo.tkac...@arm.com
* gcc.target/arm/minmax_minus.c: New test.
regards
Ramana
Thanks,
Kyrilldiff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 8895080..7ff066e 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -3417,6 +3417,50 @@
(const_int 12)))]
)
+; Reject the frame pointer in operand[1], since reloading this after
+; it has been eliminated can cause carnage.
+(define_insn_and_split *minmax_arithsi_non_canon
+ [(set (match_operand:SI 0 s_register_operand =r,r)
+ (minus:SI
+(match_operand:SI 1 s_register_operand 0,?r)
+ (match_operator:SI 4 minmax_operator
+ [(match_operand:SI 2 s_register_operand r,r)
+ (match_operand:SI 3 arm_rhs_operand rI,rI)])))
+ (clobber (reg:CC CC_REGNUM))]
+ TARGET_32BIT !arm_eliminable_register (operands[1])
+ #
+ TARGET_32BIT !arm_eliminable_register (operands[1]) reload_completed
+ [(set (reg:CC CC_REGNUM)
+(compare:CC (match_dup 2) (match_dup 3)))
+
+ (cond_exec (match_op_dup 4 [(reg:CC CC_REGNUM) (const_int 0)])
+ (set (match_dup 0)
+ (minus:SI (match_dup 1)
+ (match_dup 2
+ (cond_exec (match_op_dup 5 [(reg:CC CC_REGNUM) (const_int 0)])
+ (set (match_dup 0)
+ (minus:SI (match_dup 1)
+ (match_dup 3]
+ {
+ enum machine_mode mode = SELECT_CC_MODE (GET_CODE (operands[1]),
+ operands[2], operands[3]);
+ enum rtx_code rc = minmax_code (operands[4]);
+ operands[4] = gen_rtx_fmt_ee (rc, VOIDmode,
+operands[2], operands[3]);
+
+ if (mode == CCFPmode || mode == CCFPEmode)
+rc = reverse_condition_maybe_unordered (rc);
+ else
+rc = reverse_condition (rc);
+ operands[5] = gen_rtx_fmt_ee (rc, SImode, operands[2], operands[3]);
+ }
+ [(set_attr conds clob)
+ (set (attr length)
+ (if_then_else (eq_attr is_thumb yes)
+ (const_int 14)
+ (const_int 12)))]
+)
+
(define_code_iterator SAT [smin smax])
(define_code_iterator SATrev [smin smax])
(define_code_attr SATlo [(smin 1) (smax 2)])
diff --git a/gcc/testsuite/gcc.target/arm/minmax_minus.c
b/gcc/testsuite/gcc.target/arm/minmax_minus.c
new file mode 100644
index 000..050c847
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/minmax_minus.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+#define MAX(a, b) (a b ? a : b)
+int
+foo (int a, int b, int c)
+{
+ return c - MAX (a, b);
+}
+
+/* { dg-final { scan-assembler rsbge } } */
+/* { dg-final { scan-assembler rsblt } } */
RE: [Patch] Add microMIPS jraddiusp support
Hi Richard, I've now updated this patch. How does this version look? Catherine 2013-04-02 Catherine Moore c...@codesourcery.com * config/mips/micromips.md (jraddiusp): New pattern. * config/mips/mips.c (mips_expand_epilogue): Use the JRADDIUSP instruction if possible. -Original Message- From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Sent: Thursday, March 14, 2013 5:38 PM To: Moore, Catherine Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej Subject: Re: [Patch] Add microMIPS jraddiusp support Moore, Catherine catherine_mo...@mentor.com writes: Hi Richard, I updated this patch using your suggestions. I'm having a problem though, that I'm having trouble nailing. Building libstdc++ for microMIPS is failing trying to generate dwarf2 CFI info: _Unwind_Ptr base_of_encoded_value(unsigned char, _Unwind_Context*) Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups *free_inline_summary whole-program profile_estimate cp inline pure-const static-varAssembling functions: _Unwind_Ptr base_of_encoded_value(unsigned char, _Unwind_Context*) mm.cc: In function '_Unwind_Ptr base_of_encoded_value(unsigned char, _Unwind_Context*)': mm.cc:34:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2209 0x8570656 maybe_record_trace_start /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2209 0x857113f create_trace_edges /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2301 0x8572505 scan_trace /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2514 0x85726b3 create_cfi_notes /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2540 0x8572703 execute_dwarf2_frame /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2897 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See https://support.codesourcery.com/GNUToolchain/ for instructions. I've attached a testcase hoping that you might have some ideas. I plan to keep debugging in the meanwhile. I was able to reproduce with ./cc1plus -mmicromips -Os mm.ii. Ah, sorry, I expect it should be: mips_epilogue_set_cfa (stack_pointer_rtx, 0); instead of: mips_epilogue_emit_cfa_restores (); It would probably be better to call mips_epilogue_set_cfa immediately after emitting the jraddiusp, if that works (in which case making the assert conditional is OK). Richard jraddiusp.patch Description: jraddiusp.patch
[Patch, Fortran] PR50269 - Add some checking fixes for C_LOC
This patch updates the C_LOC checking fixes for array. In particular:
Fortran 2003 allows:
(1) have interoperable type and type parameters and be
(a) a variable that has the TARGET attribute and is interoperable,
(b) an allocated allocatable variable that has the TARGET attribute
and is not an array of zero size, or
For arrays: If the type/kind is okay, either it can be an allocatable
array (i.e. contiguous) or interoperable (i.e.
assumed-size/explicit-size array).
Fortran 2008 has:
It shall either be a variable with interoperable type and kind type
parameters, or be a scalar, nonpolymorphic variable ... If it is an
array, it shall be contiguous ...
Thus, it allows also other arrays types - and also array sections. (They
must be noncontiguous but that that's in general not testable; for one
of the examples, it would be testable but the gfc_simply_noncontiguous
function does not yet exist.)
Build + regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-04-02 Tobias Burnus bur...@net-b.de
PR fortran/50269
* gcc/fortran/check.c (is_c_interoperable,
gfc_check_c_loc): Correct c_loc array checking
for Fortran 2003 and Fortran 2008.
2013-04-02 Tobias Burnus bur...@net-b.de
PR fortran/50269
* gfortran.dg/c_loc_test_21.f90: New.
* gfortran.dg/c_loc_test_19.f90: Update dg-error.
* gfortran.dg/c_loc_tests_10.f03: Update dg-error.
* gfortran.dg/c_loc_tests_11.f03: Update dg-error.
* gfortran.dg/c_loc_tests_4.f03: Update dg-error.
* gfortran.dg/c_loc_tests_16.f90: Update dg-error.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 99174bc..b0c831e 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3649,11 +3649,12 @@ gfc_check_sizeof (gfc_expr *arg)
/* Check whether an expression is interoperable. When returning false,
msg is set to a string telling why the expression is not interoperable,
otherwise, it is set to NULL. The msg string can be used in diagnostics.
- If all_len_okay is true, all length-type parameters (for character) are
- allowed. Required for C_LOC (cf. Fortran 2003corr5 or Fortran 2008). */
+ If c_len is true, character with len 1 are allowed (cf. Fortran
+ 2003corr5); additionally, assumed-shape/assumed-rank/deferred-shape
+ arrays are permitted. */
static bool
-is_c_interoperable (gfc_expr *expr, const char **msg, bool all_len_okay)
+is_c_interoperable (gfc_expr *expr, const char **msg, bool c_loc)
{
*msg = NULL;
@@ -3706,7 +3707,7 @@ is_c_interoperable (gfc_expr *expr, const char **msg, bool all_len_okay)
gfc_simplify_expr (expr, 0) == FAILURE)
gfc_internal_error (is_c_interoperable(): gfc_simplify_expr failed);
-if (!all_len_okay expr-ts.u.cl
+if (!c_loc expr-ts.u.cl
(!expr-ts.u.cl-length
|| expr-ts.u.cl-length-expr_type != EXPR_CONSTANT
|| mpz_cmp_si (expr-ts.u.cl-length-value.integer, 1) != 0))
@@ -3726,7 +3727,7 @@ is_c_interoperable (gfc_expr *expr, const char **msg, bool all_len_okay)
return false;
}
- if (expr-rank 0 expr-expr_type != EXPR_ARRAY)
+ if (!c_loc expr-rank 0 expr-expr_type != EXPR_ARRAY)
{
gfc_array_ref *ar = gfc_find_array_ref (expr);
if (ar-type != AR_FULL)
@@ -4043,6 +4044,22 @@ gfc_check_c_loc (gfc_expr *x)
argument to C_LOC: %s, x-where, msg) == FAILURE)
return FAILURE;
}
+ else if (x-rank 0 gfc_notification_std (GFC_STD_F2008))
+{
+ gfc_array_ref *ar = gfc_find_array_ref (x);
+
+ if (ar-as-type != AS_EXPLICIT ar-as-type != AS_ASSUMED_SIZE
+ !attr.allocatable
+ gfc_notify_std (GFC_STD_F2008, Array of interoperable type at %L
+ to C_LOC which is nonallocatable and neither
+ assumed size nor explicit size, x-where)
+ == FAILURE)
+ return FAILURE;
+ else if (ar-type != AR_FULL
+ gfc_notify_std (GFC_STD_F2008, Array section at %L
+ to C_LOC, x-where) == FAILURE)
+ return FAILURE;
+}
return SUCCESS;
}
diff --git a/gcc/testsuite/gfortran.dg/c_loc_test_19.f90 b/gcc/testsuite/gfortran.dg/c_loc_test_19.f90
index a667eaf..ea62715 100644
--- a/gcc/testsuite/gfortran.dg/c_loc_test_19.f90
+++ b/gcc/testsuite/gfortran.dg/c_loc_test_19.f90
@@ -12,6 +12,6 @@ Contains
Real( c_double ), Dimension( : ), Target :: aa
Type( c_ptr ), Pointer :: b
b = c_loc( aa( 1 ) ) ! was rejected before.
- b = c_loc( aa ) ! { dg-error TS 29113: Noninteroperable array at .1. as argument to C_LOC: Only explicit-size and assumed-size arrays are interoperable }
+ b = c_loc( aa ) ! { dg-error Fortran 2008: Array of interoperable type at .1. to C_LOC which is nonallocatable and neither assumed size nor explicit size }
End Subroutine test
End Program gf
diff --git a/gcc/testsuite/gfortran.dg/c_loc_test_21.f90 b/gcc/testsuite/gfortran.dg/c_loc_test_21.f90
new file mode 100644
index 000..a31ca03
--- /dev/null
+++
Re: Fill more delay slots in conditional returns
On Tue, Apr 2, 2013 at 5:00 AM, Jeff Law wrote:
On 04/01/2013 01:47 PM, Eric Botcazou wrote:
I'm not sure what this is supposed to do. How is pat == target ever
going to be true when ANY_RETURN_P (pat) is true? Isn't target supposed
to be a CODE_LABEL or NULL? What am I missing?
The simple_return change from Bernd. The JUMP_LABEL of a JUMP_INSN is now
either a CODE_LABEL or a RETURN or a SIMPLE_RETURN.
Ah, OK, yea, it makes perfect sense now. Approved.
If you wanted to get ambitious, rewriting reorg.c to compute and use
dependency links to drive its candidate selection instead of the insane
tracking code it uses would be a huge step forward, both in terms of
cleanliness. It'd also help compile-time performance; we do a lot of work
to track resources that would be totally unnecessary.
I don't work on targets with delay slots anymore, so it's not something I'm
likely to ever tackle myself.
For the last few, my new development cycle resolutions list has
included an item do something about reorg.c but every time the task
is just too daunting.
The following problems (at least these anyway) make it a difficult job:
* There is no CFG, and sched-deps.c doesn't workout one. Extending the
life of the CFG at least up to just before dbr_schedule() is a
chicken-and-egg problem. Some machine_reorg passes wreck the CFG
beyond repair. The MIPS back end has to run dbr_schedule() as part of
its machine_reorg pass before mips_reorg_process_insns. The SPARC back
end also calls dbr_schedule() in its machine_reorg pass to work around
errata in Atmel AT697F chips (LEON2-like, i.e. fairly new, see
r179921).
Ironically, there are also a few machine_reorgs *need* the CFG and
restore it just after pass_free_cfg...
* Even if there'd be a CFG, sched-deps.c doesn't handle sequences,
which may appear after the MIPS and SPARC machine_reorg passes, which
pass the delayed-branch scheduled insn stream through the rest of the
compiler passes pipeline, also through pass_delay_slots.
* sched-deps uses the DF machinery (DF_INSN_USES, DF_INSN_DEFS) but DF
doesn't look through SEQUENCEs so DF caches are invalid after, and
probably during, dbr_schedule().
* Generally the reorg.c code doesn't look inviting to someone willing
to spend some time editing it. A few functions are huge
(fill_slots_from_thread and relax_delay_slots ~500 each, 25% of
reorg.c). There are many recurring idioms that make the code somewhat
harder to read than necessary (e.g. NONJUMP_INSN_P GET_CODE ==
SEQUENCE). And some conditionals look too complex to touch and apply
transformations in the middle of a condition, e.g. try_split in this
one:
/* If there are slots left to fill and our search was stopped by an
unconditional branch, try the insn at the branch target. We can
redirect the branch if it works.
Don't do this if the insn at the branch target is a branch. */
if (slots_to_fill != slots_filled
trial
jump_to_label_p (trial)
simplejump_p (trial)
(target == 0 || JUMP_LABEL (trial) == target)
(next_trial = next_active_insn (JUMP_LABEL (trial))) != 0
! (NONJUMP_INSN_P (next_trial)
GET_CODE (PATTERN (next_trial)) == SEQUENCE)
!JUMP_P (next_trial)
! insn_references_resource_p (next_trial, set, true)
! insn_sets_resource_p (next_trial, set, true)
! insn_sets_resource_p (next_trial, needed, true)
#ifdef HAVE_cc0
! reg_mentioned_p (cc0_rtx, PATTERN (next_trial))
#endif
! (maybe_never may_trap_or_fault_p (PATTERN (next_trial)))
(next_trial = try_split (PATTERN (next_trial), next_trial, 0))
eligible_for_delay (insn, slots_filled, next_trial, flags)
! can_throw_internal (trial))
{
* reorg.c is doing things itself that it should be using existing APIs
for, e.g. emit_delay_sequence should use
add_insn_before/add_insn_after instead of splicing seq_insn into the
chain manually.
If only there'd be a better way to model delayed insn (better than
SEQUENCE) then it is probably easier to pick Muchnick off the shelf
and re-implement delayed-branch scheduling from scratch, rather than
modernizing reorg.c.
Ciao!
Steven
Re: [patch i386 windows]: Fix PR/52790 also required for workig upcoming cygwin x64 target
On 2013-03-22 02:27, Kai Tietz wrote: Hi, this patch fixes PR/52790 and supports for x64 Windows targets the use of large and medium code-model. This feature is required for upcoming new cygwin x64 target, which uses full 48-bit available address-space of x64 Windows. The cygwin-target depends on pseudo-relocation-feature, which operates on instruction relocations. This can lead for x86_64 to issues, due instructions are in general signed-32bit-pc-relative relocated. So distances can become too wide for pseudo-relocation. Due for functions we generate anyway on pe-coff targets jump-stubs, we just need to make sure that variables are accessed via reference-pointer-variables. So we add for them in medium model .refptr-variables. In large model we using for external (therefore possibly pseudo-relocated) symbols also indirect-addressing via refptr-stubs. To avoid same issues as we noticed on cygwin64, I want to change code-model default to medium also for native-windows x64 target. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com PR target/52790 * config/i386/cygming.h (SUB_TARGET_RECORD_STUB): New sub-target macro. * config/i386/i386-protos.h (i386_pe_record_stub): Add new prototype. * config/i386/i386.c (legitimize_pe_coff_extern_decl): New static function. (legitimize_pe_coff_symbol): Likewise. (is_imported_p): New helper-function. (ix86_option_override_internal): Make MEDIUM_PIC the default code-model for Windows x64 targets. (ix86_expand_prologue): Optimize for pe-coff targets. (ix86_expand_split_stack_prologue): Adjust for pe-coff targets. (legitimate_pic_address_disp_p): Adjust for x64 pe-coff to support medium/large code-model. (legitimize_pic_address): Likewise. (legitimize_tls_address): Likewise. (ix86_expand_call): Likewise. (x86_output_mi_thunk): Likewise. (get_dllimport_decl): Add new beimport argument. (construct_plt_address): Don't assert for x64 pe-coff targets. * config/i386/i386.h (PIC_OFFSET_TABLE_REGNUM): Adjust for x64 pe-coff targets. (SYMBOL_FLAG_STUBVAR): New macro. (SYMBOL_REF_STUBVAR_P): Likewise. * config/i386/winnt.c (stub_list): New structure. (stub_head): New local variable. (i386_pe_record_stub): New function. (i386_pe_file_end): Emit refptr-stubs. Ok. r~
[PATCH, i386]: Merge *testqi_ext_3_rex64 and *testqi_ext_3
Hello!
2013-04-02 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.md (*testqi_ext_3): Merge with *testqi_ext_3_rex64
using SWI48 mode attribute.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 197339)
+++ config/i386/i386.md (working copy)
@@ -7134,43 +7134,26 @@
[(set_attr type test)
(set_attr mode QI)])
-(define_insn *testqi_ext_3_rex64
- [(set (reg FLAGS_REG)
-(compare (zero_extract:DI
- (match_operand 0 nonimmediate_operand rm)
- (match_operand:DI 1 const_int_operand)
- (match_operand:DI 2 const_int_operand))
-(const_int 0)))]
- TARGET_64BIT
-ix86_match_ccmode (insn, CCNOmode)
-INTVAL (operands[1]) 0
-INTVAL (operands[2]) = 0
- /* Ensure that resulting mask is zero or sign extended operand. */
-(INTVAL (operands[1]) + INTVAL (operands[2]) = 32
- || (INTVAL (operands[1]) + INTVAL (operands[2]) == 64
- INTVAL (operands[1]) 32))
-(GET_MODE (operands[0]) == SImode
- || GET_MODE (operands[0]) == DImode
- || GET_MODE (operands[0]) == HImode
- || GET_MODE (operands[0]) == QImode)
- #)
-
;; Combine likes to form bit extractions for some tests. Humor it.
(define_insn *testqi_ext_3
[(set (reg FLAGS_REG)
-(compare (zero_extract:SI
+ (compare (zero_extract:SWI48
(match_operand 0 nonimmediate_operand rm)
- (match_operand:SI 1 const_int_operand)
- (match_operand:SI 2 const_int_operand))
+ (match_operand:SWI48 1 const_int_operand)
+ (match_operand:SWI48 2 const_int_operand))
(const_int 0)))]
ix86_match_ccmode (insn, CCNOmode)
-INTVAL (operands[1]) 0
-INTVAL (operands[2]) = 0
-INTVAL (operands[1]) + INTVAL (operands[2]) = 32
-(GET_MODE (operands[0]) == SImode
- || (TARGET_64BIT GET_MODE (operands[0]) == DImode)
+((TARGET_64BIT GET_MODE (operands[0]) == DImode)
+ || GET_MODE (operands[0]) == SImode
|| GET_MODE (operands[0]) == HImode
- || GET_MODE (operands[0]) == QImode)
+ || GET_MODE (operands[0]) == QImode)
+ /* Ensure that resulting mask is zero or sign extended operand. */
+INTVAL (operands[2]) = 0
+((INTVAL (operands[1]) 0
+INTVAL (operands[1]) + INTVAL (operands[2]) = 32)
+ || (MODEmode == DImode
+ INTVAL (operands[1]) 32
+ INTVAL (operands[1]) + INTVAL (operands[2]) == 64))
#)
(define_split
Re: [Patch, testsuite] Fix sra-13.c for 16 bit int
On Apr 2, 2013, at 5:59 AM, Pitchumani Sivanupandi pitchuman...@atmel.com wrote: could someone please review Ok. and commit if it is OK? Committed revision 197366.
Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1
Yes, I agree that you win the challenge that it can be done.What you
have always failed to address is why anyone would want to do this. Or
how this would at all be desirable.But I completely agree that from
a purely abstract point of view you can add a storage model.
Now here is why we REALLY do not want to go down this road:
1) The following comment from your earlier mail is completely wrong
+#ifdef NEW_REP_FOR_INT_CST
+ /* This is the code once the tree level is converted. */
+ wide_int result;
+ int i;
+
+ tree type = TREE_TYPE (tcst);
+
+ result.bitsize = GET_MODE_BITSIZE (TYPE_MODE (type));
+ result.precision = TYPE_PRECISION (type);
+ result.len = TREE_INT_CST_LEN (tcst);
+ for (i = 0; i result.len; i++)
+result.val[i] = TREE_INT_CST_ELT (tcst, i);
+
+ return result;
+#else
this also shows the main reason I was asking for storage abstraction.
The initialization from tree is way too expensive.
In almost all cases, constants will fit in a single HWI. Thus, the only
thing that you are copying is the length and a single HWI. So you are
dragging in a lot of machinery just to save these two copies?
Certainly there has to be more to it than that.
2) You present this as if the implementor actually should care about
the implementation and you give 3 alternatives: the double_int, the
current one, and HWI. We have tried to make it so that the client
should not care. Certainly in my experience here, I have not found a
place to care.
In my opinion double_int needs to go away. That is the main thrust of
my patches. There is no place in a compiler for an abi that depends on
constants fitting into 2 two words whose size is defined by the host.
This is not a beauty contest argument, we have public ports are
beginning to use modes that are larger than two x86-64 HWIs and i have a
private port that has such modes and it is my experience that any pass
that uses this interface has one of three behaviors: it silently gets
the wrong answer, it ices, or it fails to do the transformation. If we
leave double_int as an available option, then any use of it potentially
will have one of these three behaviors. And so one of my strong
objections to this direction is that i do not want to fight this kind of
bug for the rest of my life.Having a single storage model that just
always works is in my opinion a highly desirable option. What you have
never answered in a concrete manner is, if we decide to provide this
generality, what it would be used for.There is no place in a
portable compiler where the right answer for every target is two HOST
wide integers.
However, i will admit that the HWI option has some merits. We try to
address this in our implementation by dividing what is done inline in
wide-int.h to the cases that fit in an HWI and then only drop into the
heavy code in wide-int.c if mode is larger (which it rarely will be).
However, a case could be made that for certain kinds of things like
string lengths and such, we could use another interface or as you argue,
a different storage model with the same interface. I just do not see
that the cost of the conversion code is really going to show up on
anyone's radar.
3) your trick will work at the tree level, but not at the rtl level.
The wide-int code cannot share storage with the CONST_INTs.We tried
this, and there are a million bugs that would have to be fixed to make
it work.It could have worked if CONST_INTs had carried a mode
around, but since they do not, you end up with the same CONST_INT
sharing the rep for several different types and that just did not work
unless you are willing to do substantial cleanups.
On 04/02/2013 11:04 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch contains a large number of the changes requested by Richi. It
does not contain any of the changes that he requested to abstract the
storage layer. That suggestion appears to be quite unworkable.
I of course took this claim as a challenge ... with the following result. It is
of course quite workable ;)
The attached patch implements the core wide-int class and three storage
models (fixed size for things like plain HWI and double-int, variable size
similar to how your wide-int works and an adaptor for the double-int as
contained in trees). With that you can now do
HOST_WIDE_INT
wi_test (tree x)
{
// template argument deduction doesn't do the magic we want it to do
// to make this kind of implicit conversions work
// overload resolution considers this kind of conversions so we
// need some magic that combines both ... but seeding the overload
// set with some instantiations doesn't seem to be possible :/
// wide_int w = x + 1;
wide_int w;
w += x;
w += 1;
// template argument deduction doesn't deduce the return value type,
// not considering the template default argument
Re: [PATCH] Allow MEM_REF lhs on gimple_clobber_p stmts (PR c++/34949)
On Tue, Apr 02, 2013 at 02:41:07PM +0200, Richard Biener wrote:
I've just come along 56787 and decided that not collecting
CLOBBERs during data-reference gathering would be wrong.
Thus changing gimple_store_p would be wrong, too. So in the
end the above hunk looks ok and we shouldn't change gimple_store_p.
(well, for now at least)
...
Here is what I've committed to trunk after another bootstrap/regtest:
2013-04-02 Jakub Jelinek ja...@redhat.com
PR c++/34949
* tree-cfg.c (verify_gimple_assign_single): Allow lhs
of gimple_clobber_p to be MEM_REF.
* gimplify.c (gimplify_modify_expr): Gimplify *to_p of
an assignment from TREE_CLOBBER_P. Allow it to be MEM_REF
after gimplification.
* asan.c (get_mem_ref_of_assignment): Don't instrument
gimple_clobber_p stmts.
* tree-ssa-dse.c (dse_optimize_stmt): Allow DSE of
gimple_clobber_p stmt if they have MEM_REF lhs and
are dead because of another gimple_clobber_p stmt.
* tree-ssa-live.c (clear_unused_block_pointer): Treat
gimple_clobber_p stmts like debug stmts.
(remove_unused_locals): Remove clobbers with MEM_REF lhs
that refer to unused VAR_DECLs or uninitialized values.
* tree-sra.c (sra_ipa_reset_debug_stmts): Also remove
gimple_clobber_p stmts if they refer to removed parameters.
(get_repl_default_def_ssa_name, sra_ipa_modify_expr): Fix up
formatting.
--- gcc/tree-cfg.c.jj 2013-03-21 18:34:11.0 +0100
+++ gcc/tree-cfg.c 2013-03-27 13:44:59.475007635 +0100
@@ -3812,9 +3812,9 @@ verify_gimple_assign_single (gimple stmt
}
if (gimple_clobber_p (stmt)
- !DECL_P (lhs))
+ !(DECL_P (lhs) || TREE_CODE (lhs) == MEM_REF))
{
- error (non-decl LHS in clobber statement);
+ error (non-decl/MEM_REF LHS in clobber statement);
debug_generic_expr (lhs);
return true;
}
--- gcc/gimplify.c.jj 2013-03-21 18:34:11.0 +0100
+++ gcc/gimplify.c 2013-03-27 13:38:30.988181267 +0100
@@ -4840,7 +4840,12 @@ gimplify_modify_expr (tree *expr_p, gimp
so handle it here. */
if (TREE_CLOBBER_P (*from_p))
{
- gcc_assert (!want_value TREE_CODE (*to_p) == VAR_DECL);
+ ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
+ if (ret == GS_ERROR)
+ return ret;
+ gcc_assert (!want_value
+ (TREE_CODE (*to_p) == VAR_DECL
+ || TREE_CODE (*to_p) == MEM_REF));
gimplify_seq_add_stmt (pre_p, gimple_build_assign (*to_p, *from_p));
*expr_p = NULL;
return GS_ALL_DONE;
--- gcc/asan.c.jj 2013-02-28 22:22:03.0 +0100
+++ gcc/asan.c 2013-03-27 14:29:54.531785577 +0100
@@ -412,7 +412,8 @@ get_mem_ref_of_assignment (const gimple
{
gcc_assert (gimple_assign_single_p (assignment));
- if (gimple_store_p (assignment))
+ if (gimple_store_p (assignment)
+ !gimple_clobber_p (assignment))
{
ref-start = gimple_assign_lhs (assignment);
*ref_is_store = true;
--- gcc/tree-ssa-dse.c.jj 2013-01-11 09:02:37.0 +0100
+++ gcc/tree-ssa-dse.c 2013-03-27 17:14:27.424466023 +0100
@@ -218,7 +218,10 @@ dse_optimize_stmt (gimple_stmt_iterator
if (is_gimple_call (stmt) gimple_call_fndecl (stmt))
return;
- if (gimple_has_volatile_ops (stmt))
+ /* Don't return early on *this_2(D) ={v} {CLOBBER}. */
+ if (gimple_has_volatile_ops (stmt)
+ (!gimple_clobber_p (stmt)
+ || TREE_CODE (gimple_assign_lhs (stmt)) != MEM_REF))
return;
if (is_gimple_assign (stmt))
@@ -228,6 +231,12 @@ dse_optimize_stmt (gimple_stmt_iterator
if (!dse_possible_dead_store_p (stmt, use_stmt))
return;
+ /* But only remove *this_2(D) ={v} {CLOBBER} if killed by
+another clobber stmt. */
+ if (gimple_clobber_p (stmt)
+ !gimple_clobber_p (use_stmt))
+ return;
+
/* If we have precisely one immediate use at this point and the
stores are to the same memory location or there is a chain of
virtual uses from stmt and the stmt which stores to that same
--- gcc/tree-ssa-live.c.jj 2013-03-21 18:34:11.0 +0100
+++ gcc/tree-ssa-live.c 2013-03-28 11:10:15.889669796 +0100
@@ -623,8 +623,8 @@ clear_unused_block_pointer_1 (tree *tp,
return NULL_TREE;
}
-/* Set all block pointer in debug stmt to NULL if the block is unused,
- so that they will not be streamed out. */
+/* Set all block pointer in debug or clobber stmt to NULL if the block
+ is unused, so that they will not be streamed out. */
static void
clear_unused_block_pointer (void)
@@ -639,7 +639,7 @@ clear_unused_block_pointer (void)
tree b;
gimple stmt = gsi_stmt (gsi);
- if (!is_gimple_debug (stmt))
+ if (!is_gimple_debug (stmt) !gimple_clobber_p (stmt))
continue;
b = gimple_block (stmt);
if (b !TREE_USED (b))
@@ -827,7 +827,15
Re: [PATCH] Improve stmt_kills_ref_p_1 (PR c++/34949)
On Tue, Apr 02, 2013 at 01:52:16PM +0200, Richard Biener wrote:
in all relevant cases operand zero of the MEM_REFs are SSA names
and thus can be compared for equality using == (exception are
integer constant pointers where the type could be theoretically
different).
...
Here is what I've committed to trunk after another bootstrap/regtest:
2013-04-02 Jakub Jelinek ja...@redhat.com
PR c++/34949
* tree-ssa-alias.c (stmt_kills_ref_p_1): If base != ref-base
and both of them are MEM_REFs, just compare first argument for
equality and attempt to deal even with differing offsets.
--- gcc/tree-ssa-alias.c.jj 2013-03-18 12:16:59.0 +0100
+++ gcc/tree-ssa-alias.c2013-03-27 17:09:28.230216081 +0100
@@ -1870,20 +1870,50 @@ stmt_kills_ref_p_1 (gimple stmt, ao_ref
!stmt_can_throw_internal (stmt))
{
tree base, lhs = gimple_get_lhs (stmt);
- HOST_WIDE_INT size, offset, max_size;
+ HOST_WIDE_INT size, offset, max_size, ref_offset = ref-offset;
base = get_ref_base_and_extent (lhs, offset, size, max_size);
/* We can get MEM[symbol: sZ, index: D.8862_1] here,
so base == ref-base does not always hold. */
- if (base == ref-base)
+ if (base != ref-base)
{
- /* For a must-alias check we need to be able to constrain
-the access properly. */
- if (size != -1 size == max_size)
+ /* If both base and ref-base are MEM_REFs, only compare the
+first operand, and if the second operand isn't equal constant,
+try to add the offsets into offset and ref_offset. */
+ if (TREE_CODE (base) == MEM_REF TREE_CODE (ref-base) == MEM_REF
+ TREE_OPERAND (base, 0) == TREE_OPERAND (ref-base, 0))
{
- if (offset = ref-offset
- offset + size = ref-offset + ref-max_size)
- return true;
+ if (!tree_int_cst_equal (TREE_OPERAND (base, 0),
+ TREE_OPERAND (ref-base, 0)))
+ {
+ double_int off1 = mem_ref_offset (base);
+ off1 = off1.alshift (BITS_PER_UNIT == 8
+ ? 3 : exact_log2 (BITS_PER_UNIT),
+ HOST_BITS_PER_DOUBLE_INT);
+ off1 = off1 + double_int::from_shwi (offset);
+ double_int off2 = mem_ref_offset (ref-base);
+ off2 = off2.alshift (BITS_PER_UNIT == 8
+ ? 3 : exact_log2 (BITS_PER_UNIT),
+ HOST_BITS_PER_DOUBLE_INT);
+ off2 = off2 + double_int::from_shwi (ref_offset);
+ if (off1.fits_shwi () off2.fits_shwi ())
+ {
+ offset = off1.to_shwi ();
+ ref_offset = off2.to_shwi ();
+ }
+ else
+ size = -1;
+ }
}
+ else
+ size = -1;
+ }
+ /* For a must-alias check we need to be able to constrain
+the access properly. */
+ if (size != -1 size == max_size)
+ {
+ if (offset = ref_offset
+ offset + size = ref_offset + ref-max_size)
+ return true;
}
}
Jakub
[Patch, Fortran] PR56810 - fix I/O READ of COMPLEX with repeat count
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-04-02 Tobias Burnus bur...@net-b.de
PR fortran/56810
* io/list_read.c (check_type): Fix kind checking for COMPLEX.
2013-04-02 Tobias Burnus bur...@net-b.de
PR fortran/56810
* gfortran.dg/read_repeat_2.f90: New.
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 0693e50..da92ad3 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -1784,7 +1784,7 @@ read_real (st_parameter_dt *dtp, void * dest, int length)
compatible. Returns nonzero if incompatible. */
static int
-check_type (st_parameter_dt *dtp, bt type, int len)
+check_type (st_parameter_dt *dtp, bt type, int kind)
{
char message[MSGLEN];
@@ -1801,11 +1801,14 @@ check_type (st_parameter_dt *dtp, bt type, int len)
if (dtp-u.p.saved_type == BT_UNKNOWN || dtp-u.p.saved_type == BT_CHARACTER)
return 0;
- if (dtp-u.p.saved_length != len)
+ if ((type != BT_COMPLEX dtp-u.p.saved_length != kind)
+ || (type == BT_COMPLEX dtp-u.p.saved_length != kind*2))
{
snprintf (message, MSGLEN,
Read kind %d %s where kind %d is required for item %d,
- dtp-u.p.saved_length, type_name (dtp-u.p.saved_type), len,
+ type == BT_COMPLEX ? dtp-u.p.saved_length / 2
+ : type == BT_COMPLEX,
+ type_name (dtp-u.p.saved_type), kind,
dtp-u.p.item_count);
generate_error (dtp-common, LIBERROR_READ_VALUE, message);
return 1;
--- /dev/null 2013-04-02 09:26:12.399063163 +0200
+++ gcc/gcc/testsuite/gfortran.dg/read_repeat_2.f90 2013-04-02 19:01:36.254797196 +0200
@@ -0,0 +1,19 @@
+! { dg-do run }
+!
+! PR fortran/56810
+!
+! Contributed by Jonathan Hogg
+!
+program test
+ implicit none
+
+ integer :: i
+ complex :: a(4)
+
+ open (99, status='scratch')
+ write (99, *) '4*(1.0,2.0)'
+ rewind (99)
+ read (99,*) a(:)
+ close (99)
+ if (any (a /= cmplx (1.0,2.0))) call abort()
+end program test
Re: patch to fix constant math - first small patch - patch ping for the next stage 1
this time for sure.
kenny
On 04/02/2013 10:54 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
Richard,
did everything that you asked here. bootstrapped and regtested on x86-64.
ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,33 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT b)
{
return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
}
+
+#ifndef ENABLE_CHECKING
+/* Sign extend SRC starting from PREC. */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
this should go to hwint.h, and without the masking of prec.
while ...
diff --git a/gcc/hwint.h b/gcc/hwint.h
index da62fad..9dddf05 100644
--- a/gcc/hwint.h
+++ b/gcc/hwint.h
@@ -276,4 +316,42 @@ extern HOST_WIDE_INT pos_mul_hwi (HOST_WIDE_INT,
HOST_WIDE_INT);
extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
extern HOST_WIDE_INT least_common_multiple (HOST_WIDE_INT, HOST_WIDE_INT);
+/* Sign extend SRC starting from PREC. */
+
+#ifdef ENABLE_CHECKING
+extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
+#else
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+ gcc_checking_assert (prec = HOST_BITS_PER_WIDE_INT);
this should go to hwint.c (also without masking prec).
Richard.
kenny
On 04/02/2013 05:38 AM, Richard Biener wrote:
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richard,
I was able to add everything except for the checking asserts.While I
think that this is a reasonable idea, it is difficult to add that to a
function that is defined in hwint.h because of circular includes. I
could
move this another file (though this appears to be the logical correct
place
for it), or we can do without the asserts.
The context is that [sz]ext_hwi is that are used are over the compiler
but
are generally written out long. The wide-int class uses them also, but
wide-int did not see like the right place for them to live and i believe
that you suggested that i move them.
ok to commit, or do you have a suggested resolution to the assert issue?
Yes, do
#ifdef ENABLE_CHECKING
extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
#else
+/* Sign extend SRC starting from PREC. */
+
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+{
int shift = HOST_BITS_PER_WIDE_INT - prec;
+ return (src shift) shift;
+}
+}
#endif
and for ENABLE_CHECKING only provide an out-of-line implementation
in hwint.c. That's how we did it with abs_hwi (well, we just do not
provide
an inline variant there - that's another possibility).
Note that hwint.h is always included after config.h so the ENABLE_CHECKING
definition should be available.
Richard.
kenny
On 03/27/2013 10:13 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the first of my wide int patches with joseph's comments and the
patch rot removed.
I would like to get these pre approved for the next stage 1.
+ int shift = HOST_BITS_PER_WIDE_INT - (prec
(HOST_BITS_PER_WIDE_INT - 1));
I think this should gcc_checking_assert that prec is not out of range
(any reason why prec is signed int and not unsigned int?) rather than
ignore bits in prec.
+static inline HOST_WIDE_INT
+zext_hwi (HOST_WIDE_INT src, int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+return src (((HOST_WIDE_INT)1
+ (prec (HOST_BITS_PER_WIDE_INT - 1))) - 1);
+}
likewise. Also I'm not sure I agree about the signedness of the result
/
src.
zext_hwi (-1, HOST_BITS_PER_WIDE_INT) 0 is true which is odd.
The patch misses context of uses, so I'm not sure what the above
functions
are intended to do.
Richard.
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT h
This may cause problems on hosts not supporting %hd (MinGW?), and
there's
no real need for using h here given the promotion of short to int;
you
can just use (rather than e.g. needing special handling in
xm-mingw32.h
like is done for HOST_LONG_LONG_FORMAT).
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..92d54a3 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,35 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT b)
{
return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
}
+
+#ifndef ENABLE_CHECKING
+/* Sign extend SRC starting from PREC. */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+ gcc_checking_assert (prec = HOST_BITS_PER_WIDE_INT);
+
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+{
+ int shift = HOST_BITS_PER_WIDE_INT - prec;
+ return (src shift) shift;
+}
+}
+
+/* Zero extend SRC starting
[wwwdocs] Buildstat update for 4.8
First round of results for gcc 4.8.x. -tgc Testresults for 4.8.0 arm-unknown-linux-gnueabi hppa2.0w-hp-hpux11.00 hppa2.0w-hp-hpux11.11 hppa64-hp-hpux11.11 i386-apple-darwin10.8.0 i386-pc-solaris2.9 i386-pc-solaris2.10 i386-pc-solaris2.11 mipsel-unknown-linux-gnu powerpc-apple-darwin9.8.0 powerpc-unknown-linux-gnu sparc-sun-solaris2.9 (2) sparc-sun-solaris2.11 sparc64-sun-solaris2.10 sparc-unknown-linux-gnu x86_64-apple-darwin10.8.0 x86_64-apple-darwin11.4.2 x86_64-apple-darwin12.3.0 x86_64-unknown-linux-gnu (2) Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v retrieving revision 1.1 diff -u -r1.1 buildstat.html --- buildstat.html 15 Mar 2013 16:39:45 - 1.1 +++ buildstat.html 2 Apr 2013 19:17:48 - @@ -20,5 +20,163 @@ a href=http://gcc.gnu.org/install/finalinstall.html; Installing GCC: Final Installation/a./p +table + +tr +tdarm-unknown-linux-gnueabi/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02658.html;4.8.0/a +/td +/tr + +tr +tdhppa2.0w-hp-hpux11.00/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg03149.html;4.8.0/a +/td +/tr + +tr +tdhppa2.0w-hp-hpux11.11/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02538.html;4.8.0/a +/td +/tr + +tr +tdhppa64-hp-hpux11.11/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02679.html;4.8.0/a +/td +/tr + +tr +tdi386-apple-darwin10.8.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02347.html;4.8.0/a +/td +/tr + +tr +tdi386-pc-solaris2.9/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02715.html;4.8.0/a +/td +/tr + +tr +tdi386-pc-solaris2.10/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02626.html;4.8.0/a +/td +/tr + +tr +tdi386-pc-solaris2.11/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02714.html;4.8.0/a +/td +/tr + +tr +tdmipsel-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02562.html;4.8.0/a +/td +/tr + +tr +tdpowerpc-apple-darwin9.8.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg00028.html;4.8.0/a +/td +/tr + +tr +tdpowerpc-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02452.html;4.8.0/a +/td +/tr + +tr +tdsparc-sun-solaris2.9/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02774.html;4.8.0/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02717.html;4.8.0/a +/td +/tr + +tr +tdsparc-sun-solaris2.11/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02718.html;4.8.0/a +/td +/tr + +tr +tdsparc64-sun-solaris2.10/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02413.html;4.8.0/a +/td +/tr + +tr +tdsparc-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02660.html;4.8.0/a +/td +/tr + +tr +tdx86_64-apple-darwin10.8.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02414.html;4.8.0/a +/td +/tr + +tr +tdx86_64-apple-darwin11.4.2/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02415.html;4.8.0/a +/td +/tr + +tr +tdx86_64-apple-darwin12.3.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02348.html;4.8.0/a +/td +/tr + +tr +tdx86_64-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02881.html;4.8.0/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02623.html;4.8.0/a +/td +/tr + +/table + /body /html Missing: 4.8.0#x86_64-winnix-linux-gnu (arch/tune amdfam10/amdfam10)#http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg03331.html Missing: 4.8.0#x86_64-winnix-linux-gnu (arch/tune amdfam10/bdver2)#http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg03334.html Missing: 4.8.0#x86_64-winnix-linux-gnu (arch/tune bdver2/bdver2)#http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg03332.html Missing: 4.8.0#x86_64-winnix-linux-gnu (arch/tune none/none)#http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg0.html
Re: [patch] replace a bunch of equivalent checks for asm operands with a new function
On Tue, Apr 2, 2013 at 12:34 PM, Eric Botcazou wrote: This idiom: if (GET_CODE (body) == ASM_INPUT || asm_noperands (body) = 0) appears in multiple places. There's even one place where the idiom above is used in reverse (making the GET_CODE... check redundant). A few more places to the equivalent by checking extract_asm_operands != NULL. I think that the last point is not clear: asm_noperands can return -1 and yet extract_asm_operands has returned non-NULL. Hmm, what do you have in mind for such a situation? If extract_asm_operands returns NULL then asm_noperands will return -1. If extract_asm_operands returns non-NULL then asm_noperands deep-dives the PATTERN of the insn (just like extract_asm_operands) and returns = 0 unless the insn is invalid. Also, lots of places check only asm_noperands to see if an insn is an asm, see cse.c, reload1.c, cprop.c, etc. Am I missing something? Ciao! Steven
Re: RFC: add some static probes to libstdc++
On 2 April 2013 16:39, Marc Glisse wrote: On Tue, 2 Apr 2013, Jonathan Wakely wrote: Should we update the prerequisites documentation to say that if Systemtap is installed it needs to be at least version X? I thought you were going to suggest enhancing the configure test so it fails on old systemtap (detects it as absent). Ah yes, that's a much better idea!
Re: [patch] Remove unused ivtype_map symbols from sese.[hc]
On 4/2/13, Richard Biener richard.guent...@gmail.com wrote: On Mon, Apr 1, 2013 at 12:19 AM, Lawrence Crowl cr...@googlers.com wrote: Remove unused symbols related to ivtype_map. This map does not appear to exist and I see no evidence of its removal in the ChangeLog. Tested on x86_64. Okay for trunk? Ok. Committed. -- Lawrence Crowl
C++ PATCH for c++/34949 (destructor clobbers object)
Now that Jakub has checked in support for MEM_REF clobbers, we can use
that to let the front end tell the back end that nothing in an object is
interesting after the destructor is complete. This should allow us to
optimize away assignments to vtable pointers if the destructor doesn't
use them, and so on.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit dcad5dc2a92840dee3bf153448ed2ccb4ace3b46
Author: Jason Merrill ja...@redhat.com
Date: Tue Apr 2 17:05:34 2013 -0400
PR c++/34949
* decl.c (begin_destructor_body): Clobber the object in a cleanup.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 40200b0..70137f4 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13555,6 +13555,14 @@ begin_destructor_body (void)
initialize_vtbl_ptrs (current_class_ptr);
finish_compound_stmt (compound_stmt);
+ /* Insert a cleanup to let the back end know that the object is dead
+ when we exit the destructor, either normally or via exception. */
+ tree clobber = build_constructor (current_class_type, NULL);
+ TREE_THIS_VOLATILE (clobber) = true;
+ tree exprstmt = build2 (MODIFY_EXPR, current_class_type,
+ current_class_ref, clobber);
+ finish_decl_cleanup (NULL_TREE, exprstmt);
+
/* And insert cleanups for our bases and members so that they
will be properly destroyed if we throw. */
push_base_cleanups ();
diff --git a/gcc/testsuite/g++.dg/opt/vt2.C b/gcc/testsuite/g++.dg/opt/vt2.C
new file mode 100644
index 000..a77db38
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/vt2.C
@@ -0,0 +1,24 @@
+// PR c++/34949
+// { dg-options -O3 }
+// { dg-final { scan-assembler-not mov\[^\n\]*_ZTV { target i?86-*-* x86_64-*-* } } }
+
+class Foo
+{
+public:
+ virtual ~Foo();
+};
+
+Foo::~Foo()
+{
+}
+
+
+class Bar : public Foo
+{
+public:
+ virtual ~Bar();
+};
+
+Bar::~Bar()
+{
+}
Re: [PATCH] Fold __builtin_constant_p immediately when in the first argument of __builtin_choose_expr (PR c/19449)
On Tue, 2 Apr 2013, Jakub Jelinek wrote: The following patch folds it there immediately too. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. BTW, in the PR I've also mentioned what has been reported to the Red Hat bugzilla about __builtin_constant_p in array bounds of static (or extern) arrays in block contexts. Those can't be VLAs, so we want to know the constant bound, but if __builtin_constant_p is used there, we error on it (while at file scope it compiles fine, because if cfun is NULL, we fold __builtin_constant_p immediately). Any suggestions how to fix that? It's not going to be as simple as using information about the declaration specifiers when parsing array declarators, because a static pointer to VLA is valid, so it would also be necessary to distinguish whether the declaration in question is actually going to be of a static array itself. -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch ARM] Add support for Cortex-A53.
On Tue, 2 Apr 2013, Ramana Radhakrishnan wrote: 2013-04-02 Ian Caulfield ian.caulfi...@arm.com Ramana Radhakrishnan ramana.radhakrish...@arm.com * config/arm/arm-arches.def (armv8-a): Default to cortex-a53. * config/arm/t-arm (MD_INCLUDES): Depend on cortex-a53.md. * config/arm/cortex-a53.md: New file. * config/arm/bpabi.h (BE8_LINK_SPEC): Handle cortex-a53. * config/arm/arm.md (generic_sched, generic_vfp): Handle cortex-a53. * config/arm/arm.c (arm_issue_rate): Likewise. * config/arm/arm-tune.md: Regenerate * config/arm/arm-tables.opt: Regenerate. * config/arm/arm-cores.def: Add cortex-a53. This patch is missing an update to the list of valid ARM -mcpu= arguments in invoke.texi. -- Joseph S. Myers jos...@codesourcery.com
[patch] C++11: Observers for the three 'handler functions'
This patch implements
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm
The function pointer holding the current new handler was exposed as an
extern variable, which is unnecessary now there's an accessor for it.
Atomic operations are used to set and retrieve the handlers to avoid
data races, as required by the standard.
* libsupc++/exception (get_terminate(), get_unexpected()): Declare.
* libsupc++/eh_terminate.cc (get_terminate() , set_unexpected()):
Define.
(set_terminate(terminate_handler)): Set atomically.
(set_unexpected(terminate_handler)): Likewise.
* libsupc++/new (get_new_handler()): Declare.
* libsupc++/new_handler.cc (get_new_handler()): Define.
(set_new_handler(new_handler)): Set atomically.
(__new_handler): Use internal linkage.
* libsupc++/new_op.cc (operator new): Use get_new_handler().
* libsupc++/new_opnt.cc (operator new): Likewise.
* acinclude.m4: Bump libtool_VERSION to 6:19:0.
* configure: Regenerate.
* libsupc++/Makefile.am: Compile above files with -std=gnu++11.
* libsupc++/Makefile.in: Regenerate.
* config/abi/pre/gnu.ver: Add new exports.
* doc/xml/manual/status_cxx2011.xml: Update.
* testsuite/18_support/headers/exception/synopsis.cc: Check accessors
for handlers.
* testsuite/18_support/headers/new/synopsis.cc: Likewise.
* testsuite/18_support/new_handler.cc: New.
* testsuite/18_support/terminate_handler.cc: New.
* testsuite/18_support/unexpected_handler.cc: New.
Tested x86_64-linux, committed to trunk.
commit d4f5cdbeae653bf4fa2dcf29a6e3d02a2752ef20
Author: Jonathan Wakely jwakely@gmail.com
Date: Tue Jan 8 19:50:13 2013 +
* libsupc++/exception (get_terminate(), get_unexpected()): Declare.
* libsupc++/eh_terminate.cc (get_terminate() , set_unexpected()):
Define.
(set_terminate(terminate_handler)): Set atomically.
(set_unexpected(terminate_handler)): Likewise.
* libsupc++/new (get_new_handler()): Declare.
* libsupc++/new_handler.cc (get_new_handler()): Define.
(set_new_handler(new_handler)): Set atomically.
(__new_handler): Use internal linkage.
* libsupc++/new_op.cc (operator new): Use get_new_handler().
* libsupc++/new_opnt.cc (operator new): Likewise.
* acinclude.m4: Bump libtool_VERSION to 6:19:0.
* configure: Regenerate.
* libsupc++/Makefile.am: Compile above files with -std=gnu++11.
* libsupc++/Makefile.in: Regenerate.
* config/abi/pre/gnu.ver: Add new exports.
* doc/xml/manual/status_cxx2011.xml: Update.
* testsuite/18_support/headers/exception/synopsis.cc: Check accessors
for handlers.
* testsuite/18_support/headers/new/synopsis.cc: Likewise.
* testsuite/18_support/new_handler.cc: New.
* testsuite/18_support/terminate_handler.cc: New.
* testsuite/18_support/unexpected_handler.cc: New.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 0871a6a..4d06b20 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3241,7 +3241,7 @@ changequote([,])dnl
fi
# For libtool versioning info, format is CURRENT:REVISION:AGE
-libtool_VERSION=6:18:0
+libtool_VERSION=6:19:0
# Everything parsed; figure out what files and settings to use.
case $enable_symvers in
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
b/libstdc++-v3/config/abi/pre/gnu.ver
index 2a9d582..978641f 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1344,6 +1344,19 @@ GLIBCXX_3.4.18 {
} GLIBCXX_3.4.17;
+GLIBCXX_3.4.19 {
+
+# std::get_new_handler()
+_ZSt15get_new_handlerv;
+
+# std::get_terminate()
+_ZSt13get_terminatev;
+
+# std::get_unexpected()
+_ZSt14get_unexpectedv;
+
+} GLIBCXX_3.4.18;
+
# Symbols in the support library (libsupc++) have their own tag.
CXXABI_1.3 {
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 5693bfd..d8caf0f 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -154,13 +154,10 @@ particular release.
entryC library dependency for quick_exit, at_quick_exit/entry
/row
row
- ?dbhtml bgcolor=#B0B0B0 ?
entry18.6/entry
entryDynamic memory management/entry
- entryPartial/entry
- entryMissing codeget_new_handler/code.
- codeset_new_handler/code is not thread-safe.
- /entry
+ entryY/entry
+ entry/
/row
row
entry18.7/entry
@@ -205,13 +202,10 @@ particular release.
entry/
/row
row
- ?dbhtml bgcolor=#B0B0B0 ?
entry18.8.3/entry
entryAbnormal termination/entry
- entryPartial/entry
- entryMissing codeget_terminate/code.
-
[PATCH GCC]Fix typo in definition of macro AUTO_INC_DEC in rtl.h
Hi, When I look into code of auto-inc-dec.c in GCC, I found this typo in rtl.h, as #if (defined (HAVE_PRE_INCREMENT) || defined (HAVE_PRE_DECREMENT) \ || defined (HAVE_POST_INCREMENT) || defined (HAVE_POST_DECREMENT) \ || defined (HAVE_PRE_MODIFY_DISP) || defined (HAVE_PRE_MODIFY_DISP) \ || defined (HAVE_PRE_MODIFY_REG) || defined (HAVE_POST_MODIFY_REG)) #define AUTO_INC_DEC #endif The 2nd HAVE_PRE_MODIFY_DISP should be HAVE_POST_MODIFY_DISP. Tested on Thumb2(cortex-m3), no failure introduced. Since the pass is disabled on x86/x86_64, so I did not run regression test on it. Thanks. 2013-04-03 Bin Cheng bin.ch...@arm.com * rtl.h (AUTO_INC_DEC): Fix typo of HAVE_POST_MODIFY_DISP.
RE: [PATCH GCC]Fix typo in definition of macro AUTO_INC_DEC in rtl.h
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
Behalf Of Bin Cheng
Sent: Wednesday, April 03, 2013 9:38 AM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH GCC]Fix typo in definition of macro AUTO_INC_DEC in rtl.h
Hi,
When I look into code of auto-inc-dec.c in GCC, I found this typo in
rtl.h, as
#if (defined (HAVE_PRE_INCREMENT) || defined (HAVE_PRE_DECREMENT) \
|| defined (HAVE_POST_INCREMENT) || defined (HAVE_POST_DECREMENT) \
|| defined (HAVE_PRE_MODIFY_DISP) || defined (HAVE_PRE_MODIFY_DISP) \
|| defined (HAVE_PRE_MODIFY_REG) || defined (HAVE_POST_MODIFY_REG))
#define AUTO_INC_DEC #endif
The 2nd HAVE_PRE_MODIFY_DISP should be HAVE_POST_MODIFY_DISP.
Tested on Thumb2(cortex-m3), no failure introduced. Since the pass is
disabled
on x86/x86_64, so I did not run regression test on it.
Thanks.
2013-04-03 Bin Cheng bin.ch...@arm.com
* rtl.h (AUTO_INC_DEC): Fix typo of HAVE_POST_MODIFY_DISP.
Patch attached.Index: gcc/rtl.h
===
--- gcc/rtl.h (revision 197231)
+++ gcc/rtl.h (working copy)
@@ -1658,7 +1658,7 @@ do {
\
#if (defined (HAVE_PRE_INCREMENT) || defined (HAVE_PRE_DECREMENT) \
|| defined (HAVE_POST_INCREMENT) || defined (HAVE_POST_DECREMENT) \
- || defined (HAVE_PRE_MODIFY_DISP) || defined (HAVE_PRE_MODIFY_DISP) \
+ || defined (HAVE_PRE_MODIFY_DISP) || defined (HAVE_POST_MODIFY_DISP) \
|| defined (HAVE_PRE_MODIFY_REG) || defined (HAVE_POST_MODIFY_REG))
#define AUTO_INC_DEC
#endif
C++ PATCH for c++/56821 (ref-qualifier mangling)
I remember thinking that I'd need to deal with mangling for
ref-qualifiers, but somehow it slipped my mind. This patch implements
it. Having to mess with re-adding the ref-qualifier after
TYPE_MAIN_VARIANT makes me more determined to deal with giving
ref-qualified types their own TYPE_MAIN_VARIANT, but this patch fixes
the issue relatively non-invasively; the better fix for 4.9 can come later.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 9231fd034c771ca295590e69381001e759f9e3ae
Author: Jason Merrill ja...@redhat.com
Date: Tue Apr 2 20:50:21 2013 -0400
PR c++/56821
* mangle.c (write_function_type): Mangle ref-qualifier.
(write_nested_name): Likewise.
(canonicalize_for_substitution): Preserve ref-qualifier.
(write_type): Likewise.
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index a48d476..10c2e2b 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -350,6 +350,7 @@ canonicalize_for_substitution (tree node)
TYPE_CANONICAL (node) != node
TYPE_MAIN_VARIANT (node) != node)
{
+ tree orig = node;
/* Here we want to strip the topmost typedef only.
We need to do that so is_std_substitution can do proper
name matching. */
@@ -361,6 +362,9 @@ canonicalize_for_substitution (tree node)
else
node = cp_build_qualified_type (TYPE_MAIN_VARIANT (node),
cp_type_quals (node));
+ if (TREE_CODE (node) == FUNCTION_TYPE
+ || TREE_CODE (node) == METHOD_TYPE)
+ node = build_ref_qualified_type (node, type_memfn_rqual (orig));
}
return node;
}
@@ -904,9 +908,11 @@ write_unscoped_template_name (const tree decl)
/* Write the nested name, including CV-qualifiers, of DECL.
- nested-name ::= N [CV-qualifiers] prefix unqualified-name E
- ::= N [CV-qualifiers] template-prefix template-args E
+ nested-name ::= N [CV-qualifiers] [ref-qualifier] prefix unqualified-name E
+ ::= N [CV-qualifiers] [ref-qualifier] template-prefix template-args E
+ ref-qualifier ::= R # ref-qualifier
+ ::= O # ref-qualifier
CV-qualifiers ::= [r] [V] [K] */
static void
@@ -926,6 +932,13 @@ write_nested_name (const tree decl)
write_char ('V');
if (DECL_CONST_MEMFUNC_P (decl))
write_char ('K');
+ if (FUNCTION_REF_QUALIFIED (TREE_TYPE (decl)))
+ {
+ if (FUNCTION_RVALUE_QUALIFIED (TREE_TYPE (decl)))
+ write_char ('O');
+ else
+ write_char ('R');
+ }
}
/* Is this a template instance? */
@@ -1880,7 +1893,13 @@ write_type (tree type)
mangle the unqualified type. The recursive call is needed here
since both the qualified and unqualified types are substitution
candidates. */
-write_type (TYPE_MAIN_VARIANT (type));
+{
+ tree t = TYPE_MAIN_VARIANT (type);
+ if (TREE_CODE (t) == FUNCTION_TYPE
+ || TREE_CODE (t) == METHOD_TYPE)
+ t = build_ref_qualified_type (t, type_memfn_rqual (type));
+ write_type (t);
+}
else if (TREE_CODE (type) == ARRAY_TYPE)
/* It is important not to use the TYPE_MAIN_VARIANT of TYPE here
so that the cv-qualification of the element type is available
@@ -1892,6 +1911,9 @@ write_type (tree type)
/* See through any typedefs. */
type = TYPE_MAIN_VARIANT (type);
+ if (TREE_CODE (type) == FUNCTION_TYPE
+ || TREE_CODE (type) == METHOD_TYPE)
+ type = build_ref_qualified_type (type, type_memfn_rqual (type_orig));
/* According to the C++ ABI, some library classes are passed the
same as the scalar type of their single member and use the same
@@ -2327,7 +2349,7 @@ write_builtin_type (tree type)
METHOD_TYPE. The return type is mangled before the parameter
types.
- function-type ::= F [Y] bare-function-type E */
+ function-type ::= F [Y] bare-function-type [ref-qualifier] E */
static void
write_function_type (const tree type)
@@ -2360,6 +2382,13 @@ write_function_type (const tree type)
See [dcl.link]. */
write_bare_function_type (type, /*include_return_type_p=*/1,
/*decl=*/NULL);
+ if (FUNCTION_REF_QUALIFIED (type))
+{
+ if (FUNCTION_RVALUE_QUALIFIED (type))
+ write_char ('O');
+ else
+ write_char ('R');
+}
write_char ('E');
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/ref-qual-mangle1.C b/gcc/testsuite/g++.dg/cpp0x/ref-qual-mangle1.C
new file mode 100644
index 000..c6ef079
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/ref-qual-mangle1.C
@@ -0,0 +1,37 @@
+// PR c++/56821
+// { dg-require-effective-target c++11 }
+
+struct A {
+ // { dg-final { scan-assembler _ZNR1A1fEv } }
+ void f() {}
+ // { dg-final { scan-assembler _ZNO1A1gEv } }
+ void g() {}
+ // { dg-final { scan-assembler _ZNKR1A1hEv } }
+ void h() const {}
+};
+
+// { dg-final { scan-assembler _Z1jM1AFvvRE } }
+void j(void (A::*)() ) { }
+// { dg-final { scan-assembler _Z1kM1AFvvOE } }
+void k(void (A::*)() ) { }
+// { dg-final { scan-assembler _Z1lM1AKFvvRE } }
+void l(void (A::*)() const ) { }
+
+//
