Re: testsuite patches (7/14): gcc.dg/pr46647.c: xfail for avr*-*-*
Joern Rennecke wrote: > xfail for avr*-*-* Hi, the target machine is avr-*-* because, say, avr32 (a 32-bit MCU not officially supported) is a quite different architecture than avr. Similar for your other testsuite patches with avr*-*-* Johann
Re: [ubsan] Add libcall arguments
On Sun, Jul 21, 2013 at 10:41:15PM -0400, Jason Merrill wrote:
> On 07/21/2013 02:26 PM, Marek Polacek wrote:
> > (pointer_sized_type_node): Define.
>
> Let's call it pointer_sized_int_node.
Sure. Here it is.
2013-07-21 Marek Polacek
* tree.h (enum tree_index): Add TI_POINTER_SIZED_TYPE.
(pointer_sized_int_node): Define.
* tree.c (build_common_tree_nodes): Initialize
pointer_sized_int_node.
* ubsan.c (ubsan_encode_value): Use pointer_sized_int_node instead
calling uptr_type.
(uptr_type): Remove function.
* asan.c (asan_global_struct): Use pointer_sized_int_node instead
calling build_nonstandard_integer_type.
(initialize_sanitizer_builtins): Likewise.
(asan_finish_file): Likewise.
--- gcc/tree.c.mp 2013-07-21 19:54:35.416986756 +0200
+++ gcc/tree.c 2013-07-21 19:56:58.347562787 +0200
@@ -9638,6 +9638,8 @@ build_common_tree_nodes (bool signed_cha
= build_pointer_type (build_type_variant (void_type_node, 1, 0));
fileptr_type_node = ptr_type_node;
+ pointer_sized_int_node = build_nonstandard_integer_type (POINTER_SIZE, 1);
+
float_type_node = make_node (REAL_TYPE);
TYPE_PRECISION (float_type_node) = FLOAT_TYPE_SIZE;
layout_type (float_type_node);
--- gcc/ubsan.c.mp 2013-07-21 20:04:59.469653493 +0200
+++ gcc/ubsan.c 2013-07-21 20:07:00.227178083 +0200
@@ -123,14 +123,6 @@ ubsan_typedesc_new (tree type, tree decl
return desc;
}
-/* Build the ubsan uptr type. */
-
-static tree
-uptr_type (void)
-{
- return build_nonstandard_integer_type (POINTER_SIZE, 1);
-}
-
/* Helper routine, which encodes a value in the uptr type.
Arguments with precision <= POINTER_SIZE are passed directly,
the rest is passed by reference. T is a value we are to encode. */
@@ -143,7 +135,7 @@ ubsan_encode_value (tree t)
{
case INTEGER_TYPE:
if (TYPE_PRECISION (type) <= POINTER_SIZE)
- return fold_build1 (NOP_EXPR, uptr_type (), t);
+ return fold_build1 (NOP_EXPR, pointer_sized_int_node, t);
else
return build_fold_addr_expr (t);
case REAL_TYPE:
@@ -153,7 +145,7 @@ ubsan_encode_value (tree t)
{
tree itype = build_nonstandard_integer_type (bitsize, true);
t = fold_build1 (VIEW_CONVERT_EXPR, itype, t);
- return fold_convert (uptr_type (), t);
+ return fold_convert (pointer_sized_int_node, t);
}
else
{
--- gcc/tree.h.mp 2013-07-21 19:54:35.441986868 +0200
+++ gcc/tree.h 2013-07-21 19:56:05.128353854 +0200
@@ -4227,6 +4227,7 @@ enum tree_index
TI_VA_LIST_FPR_COUNTER_FIELD,
TI_BOOLEAN_TYPE,
TI_FILEPTR_TYPE,
+ TI_POINTER_SIZED_TYPE,
TI_DFLOAT32_TYPE,
TI_DFLOAT64_TYPE,
@@ -4383,6 +4384,7 @@ extern GTY(()) tree global_trees[TI_MAX]
#define va_list_fpr_counter_field
global_trees[TI_VA_LIST_FPR_COUNTER_FIELD]
/* The C type `FILE *'. */
#define fileptr_type_node global_trees[TI_FILEPTR_TYPE]
+#define pointer_sized_int_node global_trees[TI_POINTER_SIZED_TYPE]
#define boolean_type_node global_trees[TI_BOOLEAN_TYPE]
#define boolean_false_node global_trees[TI_BOOLEAN_FALSE]
--- gcc/asan.c.mp 2013-07-21 20:07:15.013237456 +0200
+++ gcc/asan.c 2013-07-21 20:16:10.929376734 +0200
@@ -1954,7 +1954,7 @@ asan_global_struct (void)
= build_decl (UNKNOWN_LOCATION, FIELD_DECL,
get_identifier (field_names[i]),
(i == 0 || i == 3) ? const_ptr_type_node
- : build_nonstandard_integer_type (POINTER_SIZE, 1));
+ : pointer_sized_int_node);
DECL_CONTEXT (fields[i]) = ret;
if (i)
DECL_CHAIN (fields[i - 1]) = fields[i];
@@ -2039,8 +2039,7 @@ initialize_sanitizer_builtins (void)
ptr_type_node, ptr_type_node, NULL_TREE);
tree BT_FN_VOID_PTR_PTRMODE
= build_function_type_list (void_type_node, ptr_type_node,
- build_nonstandard_integer_type (POINTER_SIZE,
- 1), NULL_TREE);
+ pointer_sized_int_node, NULL_TREE);
tree BT_FN_VOID_INT
= build_function_type_list (void_type_node, integer_type_node, NULL_TREE);
tree BT_FN_BOOL_VPTR_PTR_IX_INT_INT[5];
@@ -2197,7 +2196,6 @@ asan_finish_file (void)
if (gcount)
{
tree type = asan_global_struct (), var, ctor;
- tree uptr = build_nonstandard_integer_type (POINTER_SIZE, 1);
tree dtor_statements = NULL_TREE;
vec *v;
char buf[20];
@@ -2226,15 +2224,16 @@ asan_finish_file (void)
varpool_assemble_decl (varpool_node_for_decl (var));
fn = builtin_decl_implicit (BUILT_IN_ASAN_REGISTER_GLOBALS);
+ tree gcount_tree = build_int_cst (pointer_sized_int_node, gcount);
append_to_statement_list (build_call_expr (fn, 2,
Re: RFC: Gimple combine/folding interface
Andrew Pinski wrote:
>On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski
>wrote:
>> I was creating a new gimple/folding interface and wanted some
>opinions
>> on the interface.
>>
>> typedef double_int (*nonzerobits_t)(tree var);
>> typedef tree (*valueizer_t)(tree var);
>>
>> class gimple_combine
>> {
>> public:
>> gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
>> valueizerv(b), allow_full_reassiocation(false) {}
>> gimple_combine() : nonzerobitsf(NULL), valueizerv(NULL),
>> allow_full_reassiocation(false) {}
>> gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
>> allow_full_reassiocation(reas) {}
>> tree build2 (location_t, enum tree_code, tree, tree, tree);
>> tree build1 (location_t, enum tree_code, tree, tree);
>> tree build3 (location_t, enum tree_code, tree, tree, tree, tree);
>> tree combine (gimple);
>> private:
>> nonzerobits_t nonzerobitsf;
>> valueizer_t valueizerv;
>> bool allow_full_reassiocation;
>> tree binary (location_t, enum tree_code, tree, tree, tree);
>> tree unary (location_t, enum tree_code, tree, tree);
>> tree ternary (location_t, enum tree_code, tree, tree, tree, tree);
>> };
Just a few comments before I return to work late in August. I like the way of
using a c++ object to store combiner flags as opposed to extra arguments. For
the optimizers I want to retain the ability to specify the desired result
(constant, single op, arbitrary) which also allows shortcutting some transforms.
I also want to retain the ability to return the combining result piecewise
without building trees, at least for results that fit a single gimple stmt.
>> bool replace_rhs_after_ssa_combine (gimple_stmt_iterator *, tree);
... Precisely to avoid this.
I'm not sure if you want to replace the fold-const.c workers with this
infrastructure?
Richard.
>> This is what I have so far and wonder if there is anything else I
>> should include.
>>
>> This will be used to replace the folding code in fold-const.c and
>gimple-fold.c.
>
>I placed what I decided in a branch in git:
>
>http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gimple-ssa-combine.h;h=3d597291c1756cdf6e3318fd190ac70911ceb702;hb=d32468a31ab5e50fabab3a04303f6892ad890fd5
>
>Note I won't have time to work on this again until the middle of August
>or so.
>
>The status of the current patch is that it is able to build libgcc but
>there are some addition ICEs due to checking to make sure all of the
>forwprop optimizations are pushed over to gimple_combine (since I
>started this work on an older code base).
>
>Thanks,
>Andrew Pinski
>
>>
>> Thanks,
>> Andrew Pinski
Re: [Patch x86/darwin] fix PR51784 'PIC register not correctly preserved...'
Hi Uros, On 21 Jul 2013, at 09:15, Uros Bizjak wrote: > On Sun, Jul 21, 2013 at 9:42 AM, Iain Sandoe wrote: > >>> >> >> Sure, I can test that - do you want me to apply it assuming it reg-tests OK >> on darwin & linux? >> (also I can amend the back ports - since I didn't have time to get to them >> yesterday) > > Yes, please test it on darwin. The build test on linux went OK. > However, the change is not effective on linux, so I have no means to > properly test it by myself. > > If everything is OK, please also use this change in backports. Thanks, that checked out fine, so I've applied it to mainline and the combined version to 4.8. I'm travelling this week with limited access to my Darwin boxen, so the 4.7 version might be a bit delayed - similarly, I might take more time than usual to respond to emails. thanks, Iain
Re: [ARM][Insn classification refactoring 6/N] Delete "insn" attribute and update MOV classification
On 07/19/13 15:10, Sofiane Naci wrote: Hi, This patch is part of the ongoing work of ARM instruction classification cleanup. This patch deletes the "insn" attribute and moves the MOV/MVN instruction classification to the "type" attribute, where it is split into several types for a finer-grained classification. This has been tested with a full arm-none-eabi toolchain build and regression run, as well as using random code generation tests to compare the output versus a baseline compiler. OK for trunk? ENOPATCH . Ramana Thanks Sofiane - ChangeLog: * config/arm/arm.md (attribute "insn"): Delete. (attribute "type"): Add "mov_imm", "mov_reg", "mov_shift", "mov_shift_reg", "mvn_imm", "mvn_reg", "mvn_shift" and "mvn_shift_reg". (not_shiftsi): Update for attribute change. (not_shiftsi_compare0): Likewise. (not_shiftsi_compare0_scratch): Likewise. (arm_one_cmplsi2): Likewise. (thumb1_one_cmplsi2): Likewise. (notsi_compare0): Likewise. (notsi_compare0_scratch): Likewise. (thumb1_movdi_insn): Likewise. (arm_movsi_insn): Likewise. (movhi_insn_arch4): Likewise. (movhi_bytes): Likewise. (arm_movqi_insn): Likewise. (thumb1_movqi_insn): Likewise. (arm32_movhf): Likewise. (thumb1_movhf): Likewise. (arm_movsf_soft_insn): Likewise. (thumb1_movsf_insn): Likewise. (thumb_movdf_insn): Likewise. (movsicc_insn): Likewise. (movsfcc_soft_insn): Likewise. (and_scc): Likewise. (cond_move): Likewise. (if_move_not): Likewise. (if_not_move): Likewise. (if_shift_move): Likewise. (if_move_shift): Likewise. (if_shift_shift): Likewise. (if_not_arith): Likewise. (if_arith_not): Likewise. (cond_move_not): Likewise. * config/arm/neon.md (neon_mov): Update for attribute change. (neon_mov): Likewise. * config/arm/vfp.md (arm_movsi_vfp): Update for attribute change. (thumb2_movsi_vfp): Likewise. (movsf_vfp): Likewise. (thumb2_movsf_vfp): Likewise. * config/arm/arm.c (xscale_sched_adjust_cost): Update for attribute change. (cortexa7_older_only): Likewise. (cortexa7_younger): Likewise. * config/arm/arm1020e.md (1020alu_op): Update for attribute change. (1020alu_shift_op): Likewise. (1020alu_shift_reg_op): Likewise. * config/arm/arm1026ejs.md (alu_op): Update for attribute change. (alu_shift_op): Likewise. (alu_shift_reg_op): Likewise. * config/arm/arm1136jfs.md (11_alu_op): Update for attribute change. (11_alu_shift_op): Likewise. (11_alu_shift_reg_op): Likewise. * config/arm/arm926ejs.md (9_alu_op): Update for attribute change. (9_alu_shift_reg_op): Likewise. * config/arm/cortex-a15.md (cortex_a15_alu): Update for attribute change. (cortex_a15_alu_shift): Likewise. (cortex_a15_alu_shift_reg): Likewise. * config/arm/cortex-a5.md (cortex_a5_alu): Update for attribute change. (cortex_a5_alu_shift): Likewise. * config/arm/cortex-a53.md (cortex_a53_alu): Update for attribute change. (cortex_a53_alu_shift): Likewise. * config/arm/cortex-a7.md (cortex_a7_alu_imm): Update for attribute change. (cortex_a7_alu_reg): Likewise. (cortex_a7_alu_shift): Likewise. * config/arm/cortex-a8.md (cortex_a8_alu): Update for attribute change. (cortex_a8_alu_shift): Likewise. (cortex_a8_alu_shift_reg): Likewise. (cortex_a8_mov): Likewise. * config/arm/cortex-a9.md (cortex_a9_dp): Update for attribute change. (cortex_a9_dp_shift): Likewise. * config/arm/cortex-m4.md (cortex_m4_alu): Update for attribute change. * config/arm/cortex-r4.md (cortex_r4_alu): Update for attribute change. (cortex_r4_mov): Likewise. (cortex_r4_alu_shift): Likewise. (cortex_r4_alu_shift_reg): Likewise. * config/arm/fa526.md (526_alu_op): Update for attribute change. (526_alu_shift_op): Likewise. * config/arm/fa606te.md (606te_alu_op): Update for attribute change. * config/arm/fa626te.md (626te_alu_op): Update for attribute change. (626te_alu_shift_op): Likewise. * config/arm/fa726te.md (726te_shift_op): Update for attribute change. (726te_alu_op): Likewise. (726te_alu_shift_op): Likewise. (726te_alu_shift_reg_op): Likewise. * config/arm/fmp626.md (mp626_alu_op): Update for attribute change. (mp626_alu_shift_op): Likewise. * config/arm/marvell-pj4.md (pj4_alu_e1): Update for attribute change. (pj4_alu_e1_conds): Likewise. (pj4_alu): Likewise. (pj4_alu_conds): Likewise. (pj4_shift): Likewise. (pj4_shift_conds): Likewise. (pj4_alu_shift): Likewise. (pj
RFA: Use -gdwarf in gcc.dg/debug/dwarf (Was: Re: testsuite patches (1/14): Request dwarf-2 output where needed)
Quoting Jakub Jelinek :
On Mon, Jul 22, 2013 at 10:31:03AM +0530, Senthil Kumar Selvaraj wrote:
..
I ran into this problem a while ago, and after discussion on the
mailing list, added a -gdwarf option to emit DWARF with the default
version (http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00592.html). Might
be better than hardcoding dwarf-2 IMO.
Yeah, definitely.
Jakub
All right, then we should start by changing the existing -gdwarf-2 options in
the gcc.dg/debug/dwarf2 directory to -gdwarf.
Tested on i686-pc-linux-gnu .
2013-07-22 Joern Rennecke
* gcc.dg/debug/dwarf2/dwarf2.exp: Replace -gdwarf-2 with -gdwarf.
* gcc.dg/debug/dwarf2/dwarf-die7.c: Likewise.
* gcc.dg/debug/dwarf2/static1.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-dfp.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-any.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-uninit.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-die1.c: Likewise.
* gcc.dg/debug/dwarf2/var1.c: Likewise.
* gcc.dg/debug/dwarf2/pr29609-2.c: Likewise.
* gcc.dg/debug/dwarf2/aranges-fnsec-1.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-die3.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-merge.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-char1.c: Likewise.
* gcc.dg/debug/dwarf2/discriminator.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-char2.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-baseonly.c: Likewise.
* gcc.dg/debug/dwarf2/pr36690-3.c: Likewise.
* gcc.dg/debug/dwarf2/const-2.c: Likewise.
* gcc.dg/debug/dwarf2/ipa-cp1.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-char3.c: Likewise.
* gcc.dg/debug/dwarf2/var2.c: Likewise.
* gcc.dg/debug/dwarf2/pr36690-2.c: Likewise.
* gcc.dg/debug/dwarf2/pr31230.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-float.c: Likewise.
* gcc.dg/debug/dwarf2/short-circuit.c: Likewise.
* gcc.dg/debug/dwarf2/pr36690-1.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-reduced.c: Likewise.
* gcc.dg/debug/dwarf2/pr37616.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-die2.c: Likewise.
* gcc.dg/debug/dwarf2/inline1.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-sys.c: Likewise.
* gcc.dg/debug/dwarf2/pr29609-1.c: Likewise.
* gcc.dg/debug/dwarf2/asm-line1.c: Likewise.
* gcc.dg/debug/dwarf2/c99-typedef1.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf2-macro.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-none.c: Likewise.
* gcc.dg/debug/dwarf2/pr51410.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-file1.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-die6.c: Likewise.
* gcc.dg/debug/dwarf2/const-2b.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-die5.c: Likewise.
Index: gcc.dg/debug/dwarf2/dwarf2.exp
===
--- gcc.dg/debug/dwarf2/dwarf2.exp (revision 201032)
+++ gcc.dg/debug/dwarf2/dwarf2.exp (working copy)
@@ -22,7 +22,7 @@
# If a testcase doesn't have special options, use these.
global DEFAULT_CFLAGS
if ![info exists DEFAULT_CFLAGS] then {
-set DEFAULT_CFLAGS " -ansi -pedantic-errors -gdwarf-2"
+set DEFAULT_CFLAGS " -ansi -pedantic-errors -gdwarf"
}
# Initialize `dg'.
@@ -31,7 +31,7 @@
# Main loop.
set comp_output [gcc_target_compile \
"$srcdir/$subdir/../trivial.c" "trivial.S" assembly \
-"additional_flags=-gdwarf-2"]
+"additional_flags=-gdwarf"]
if { ! [string match "*: target system does not support the * debug format*" \
$comp_output] } {
remove-build-file "trivial.S"
Index: gcc.dg/debug/dwarf2/dwarf-die7.c
===
--- gcc.dg/debug/dwarf2/dwarf-die7.c(revision 201032)
+++ gcc.dg/debug/dwarf2/dwarf-die7.c(working copy)
@@ -1,6 +1,6 @@
/* Inlined non-inline function must have abstract DIE */
/* { dg-do compile } */
-/* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */
+/* { dg-options "-O2 -gdwarf -dA -fpreprocessed" } */
/* { dg-final { scan-assembler "1.*DW_AT_inline" } } */
#1 "test.h"
void f(void);
Index: gcc.dg/debug/dwarf2/static1.c
===
--- gcc.dg/debug/dwarf2/static1.c (revision 201032)
+++ gcc.dg/debug/dwarf2/static1.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -gdwarf-2" } */
+/* { dg-options "-O2 -gdwarf" } */
void
main(void)
{
Index: gcc.dg/debug/dwarf2/dwarf-dfp.c
===
--- gcc.dg/debug/dwarf2/dwarf-dfp.c (revision 201032)
+++ gcc.dg/debug/dwarf2/dwarf-dfp.c (working copy)
@@ -2,7 +2,7 @@
/* { dg-do compile */
/* { dg-require-effective-target dfp } */
-/* { dg-options "-O0 -gdwarf-2 -dA" } */
+/* { dg-options "-O0 -gdwarf -dA" } */
/* { dg-final { scan-assembler "0x10.*DW_AT_encoding" } } */
/* { dg-final { scan-assembler "0x4.*DW_AT_byte_size"
Re: [PATCH] Fix pr57637
> The patch is updated based the comments: it will check GEN set of LIVE > if df_live exists. Otherwise, just give up. The patch is missing a ChangeLog. Otherwise it looks good, modulo: + /* DF_LR_BB_INFO (bb)->def does not kill the DF_REF_PARTIAL and +DF_REF_CONDITIONAL defs. So if DF_LIVE doesn't exist, i.e. "does not comprise" + at -O1, just give up to search NEXT_BLOCK "just give up searching" I'm not sure this matters in practice, but don't we need to set the appropriate bit in the GEN set of BB at the end of the function if df_live is non-zero, at least for the sake of consistency? > And a testcase is included in the attached patch. Thanks. We generally try to make the testcases self-contained, i.e. remove the #include's as much as possible. It seems that stdlib.h is included for abort; if so, remove it and use __builtin_abort instead. Would it be possible to remove stdio.h as well? -- Eric Botcazou
Re: [patch] [python libstdc++ printers] Fix gdb/15195
On 03/07/13 08:33, Phil Muldoon wrote: > This new patch replaces and obsoletes the previous. On further > inspection of some other pretty printer related bugs, it seems that > all of the printers need to fetch the referenced value where the value > type is a reference. This patch applies that change, and adds a > number of reference based tests. ping Cheers, Phil
Re: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside)
Hello Zoran, I may be wrong, but what you are trying to do is very similar to what's in fold-const.c optimize_bit_field_compare(). There was a discussion in April 2012 on this thread: "Continue strict-volatile-bitfields fixes" http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01094.html The result was that this optimization seems to break other possible optimizations later on, when -fstrict-volatile-bitfields was enabled on the SH target. Even when the bit fields are NOT volatile. (Of course you should not touch volatile bit fields at all) And this was added to optimize_bit_field_compare as a result: /* In the strict volatile bitfields case, doing code changes here may prevent other optimizations, in particular in a SLOW_BYTE_ACCESS setting. */ if (flag_strict_volatile_bitfields> 0) return 0; Regards Bernd.
Re: [PATCH][ARM][10/n] Partial IT block deprecation in ARMv8 AArch32 - thumb2.md changes
On 11/07/13 13:31, Kyrylo Tkachov wrote: Hi Richard, (define_insn_and_split "*thumb2_smaxsi3" - [(set (match_operand:SI 0 "s_register_operand" "=r,r,r") - (smax:SI (match_operand:SI 1 "s_register_operand" "0,r,?r") -(match_operand:SI 2 "arm_rhs_operand""rI,0,rI"))) + [(set (match_operand:SI 0 "s_register_operand" "=r,r,r ,r,l") + (smax:SI (match_operand:SI 1 "s_register_operand" "0,r,?r,0,0") +(match_operand:SI 2 "arm_rhs_operand""rI,0,rI,r,Py"))) (clobber (reg:CC CC_REGNUM))] min/max operations are commutative. Marking this pattern as such would make the second alternative redundant. Furthermore, splitting the first pattern into a register only variant and an immediate variant would mean you don't then need one of your additional alternatives later on. I think you want constraints of the form op0: "=r,l,r,r" op1: "%0,0,0,r" op2: "r,Py,I,r" This has the added advantage that you can now get a more accurate length calculation for the first two cases. Similarly for the other min/max operations. Done, I've also converted the splitters to generate cond_execs instead of if_then_else to make it more explicit that we expect one conditional move from this pattern. (define_insn_and_split "*thumb2_abssi2" - [(set (match_operand:SI 0 "s_register_operand" "=r,&r") + [(set (match_operand:SI 0 "s_register_operand" "=Ts,&r") (abs:SI (match_operand:SI 1 "s_register_operand" "0,r"))) I think this pattern should be reworked to put the second alternative first. In thumb state that will be more efficient (two instructions rather than three). There's also now an argument for splitting out the 'l' and 'r' alteratives of the current 'it' variant and giving more accurate length costs for the two. Likewise for thumb2_neg_abssi2. Done. (define_insn_and_split "*thumb2_mov_scc" - [(set (match_operand:SI 0 "s_register_operand" "=r") + [(set (match_operand:SI 0 "s_register_operand" "=r, =l") '=' applies to all the alternatives. Only put it at the start of the constraint string. Also applies to thumb2_mov_negscc. Done. (define_insn_and_split "*thumb2_mov_notscc" [(set (match_operand:SI 0 "s_register_operand" "=r") (not:SI (match_operator:SI 1 "arm_comparison_operator" [(match_operand 2 "cc_register" "") (const_int 0)])))] - "TARGET_THUMB2" + "TARGET_THUMB2 && !arm_restrict_it" For restricted IT and low regs, this could be reworked as mvn rd, #0 it lsl rd, rd, #1 Reworked splitter. +(define_insn "*thumb2_ior_scc_strict_it" + [(set (match_operand:SI 0 "s_register_operand" "=l,=l") Repeated '=' Fixed. Is this better? Tested on model --with-arch=armv8-a with and without -mthumb. Bootstrapped on a Cortex-A15. Thanks, Kyrill 2013-07-11 Kyrylo Tkachov * config/arm/predicates.md (shiftable_operator_strict_it): New predicate. * config/arm/thumb2.md (thumb_andsi_not_shiftsi_si): Disable cond_exec version for arm_restrict_it. (thumb2_smaxsi3): Convert to generate cond_exec. (thumb2_sminsi3): Likewise. (thumb32_umaxsi3): Likewise. (thumb2_uminsi3): Likewise. (thumb2_abssi2): Adjust constraints for arm_restrict_it. (thumb2_neg_abssi2): Likewise. (thumb2_mov_scc): Add alternative for 16-bit encoding. (thumb2_movsicc_insn): Adjust alternatives. (thumb2_mov_negscc): Disable for arm_restrict_it. (thumb2_mov_negscc_strict_it): New pattern. (thumb2_mov_notscc_strict_it): New pattern. (thumb2_mov_notscc): Disable for arm_restrict_it. (thumb2_ior_scc): Likewise. (thumb2_ior_scc_strict_it): New pattern. (thumb2_cond_move): Adjust for arm_restrict_it. (thumb2_cond_arith): Disable for arm_restrict_it. (thumb2_cond_arith_strict_it): New pattern. (thumb2_cond_sub): Adjust for arm_restrict_it. (thumb2_movcond): Likewise. (thumb2_extendqisi_v6): Disable cond_exec variant for arm_restrict_it. (thumb2_zero_extendhisi2_v6): Likewise. (thumb2_zero_extendqisi2_v6): Likewise. (orsi_notsi_si): Likewise. (orsi_not_shiftsi_si): Likewise. OK. R.
RE: [PATCH][ARM][10/n] Partial IT block deprecation in ARMv8 AArch32 - thumb2.md changes
Ping? Thanks, Kyrill > > Hi Richard, > > > (define_insn_and_split "*thumb2_smaxsi3" > > - [(set (match_operand:SI 0 "s_register_operand" "=r,r,r") > > - (smax:SI (match_operand:SI 1 "s_register_operand" "0,r,?r") > > -(match_operand:SI 2 "arm_rhs_operand""rI,0,rI"))) > > + [(set (match_operand:SI 0 "s_register_operand" "=r,r,r > ,r,l") > > + (smax:SI (match_operand:SI 1 "s_register_operand" "0,r,?r,0,0") > > +(match_operand:SI 2 "arm_rhs_operand""rI,0,rI,r,Py"))) > > (clobber (reg:CC CC_REGNUM))] > > > > min/max operations are commutative. Marking this pattern as such would > > make the second alternative redundant. Furthermore, splitting the > first > > pattern into a register only variant and an immediate variant would > mean > > you don't then need one of your additional alternatives later on. I > > think you want constraints of the form > > > > op0: "=r,l,r,r" > > op1: "%0,0,0,r" > > op2: "r,Py,I,r" > > > > This has the added advantage that you can now get a more accurate > length > > calculation for the first two cases. > > > > Similarly for the other min/max operations. > > Done, I've also converted the splitters to generate cond_execs instead of > if_then_else to make it more explicit that we expect one conditional move > from > this pattern. > > > > > (define_insn_and_split "*thumb2_abssi2" > > - [(set (match_operand:SI 0 "s_register_operand" "=r,&r") > > + [(set (match_operand:SI 0 "s_register_operand" "=Ts,&r") > > (abs:SI (match_operand:SI 1 "s_register_operand" "0,r"))) > > > > I think this pattern should be reworked to put the second alternative > > first. In thumb state that will be more efficient (two instructions > > rather than three). There's also now an argument for splitting out the > > 'l' and 'r' alteratives of the current 'it' variant and giving more > > accurate length costs for the two. > > > > Likewise for thumb2_neg_abssi2. > > Done. > > > > > (define_insn_and_split "*thumb2_mov_scc" > > - [(set (match_operand:SI 0 "s_register_operand" "=r") > > + [(set (match_operand:SI 0 "s_register_operand" "=r, =l") > > > > '=' applies to all the alternatives. Only put it at the start of the > > constraint string. > > > > Also applies to thumb2_mov_negscc. > > Done. > > > > > (define_insn_and_split "*thumb2_mov_notscc" > > [(set (match_operand:SI 0 "s_register_operand" "=r") > > (not:SI (match_operator:SI 1 "arm_comparison_operator" > > [(match_operand 2 "cc_register" "") (const_int 0)])))] > > - "TARGET_THUMB2" > > + "TARGET_THUMB2 && !arm_restrict_it" > > > > For restricted IT and low regs, this could be reworked as > > > > mvn rd, #0 > > it > > lsl rd, rd, #1 > > > > Reworked splitter. > > > +(define_insn "*thumb2_ior_scc_strict_it" > > + [(set (match_operand:SI 0 "s_register_operand" "=l,=l") > > > > Repeated '=' > > Fixed. > > Is this better? > Tested on model --with-arch=armv8-a with and without -mthumb. > Bootstrapped on > a Cortex-A15. > > Thanks, > Kyrill > > > > 2013-07-11 Kyrylo Tkachov > > * config/arm/predicates.md (shiftable_operator_strict_it): New > predicate. > * config/arm/thumb2.md (thumb_andsi_not_shiftsi_si): Disable > cond_exec > version > for arm_restrict_it. > (thumb2_smaxsi3): Convert to generate cond_exec. > (thumb2_sminsi3): Likewise. > (thumb32_umaxsi3): Likewise. > (thumb2_uminsi3): Likewise. > (thumb2_abssi2): Adjust constraints for arm_restrict_it. > (thumb2_neg_abssi2): Likewise. > (thumb2_mov_scc): Add alternative for 16-bit encoding. > (thumb2_movsicc_insn): Adjust alternatives. > (thumb2_mov_negscc): Disable for arm_restrict_it. > (thumb2_mov_negscc_strict_it): New pattern. > (thumb2_mov_notscc_strict_it): New pattern. > (thumb2_mov_notscc): Disable for arm_restrict_it. > (thumb2_ior_scc): Likewise. > (thumb2_ior_scc_strict_it): New pattern. > (thumb2_cond_move): Adjust for arm_restrict_it. > (thumb2_cond_arith): Disable for arm_restrict_it. > (thumb2_cond_arith_strict_it): New pattern. > (thumb2_cond_sub): Adjust for arm_restrict_it. > (thumb2_movcond): Likewise. > (thumb2_extendqisi_v6): Disable cond_exec variant for > arm_restrict_it. > (thumb2_zero_extendhisi2_v6): Likewise. > (thumb2_zero_extendqisi2_v6): Likewise. > (orsi_notsi_si): Likewise. > (orsi_not_shiftsi_si): Likewise.
Re: [Patch] regex_iterator and regex_token_iterator implementation
On 22 July 2013 06:13, Tim Shen wrote: > > Actually, in code before this patch, private members in class > regex_iterator are indeed start without double or single underscore. > It's because the standard (28.12, n3376) specifies them, though they > are private. IMHO, they are part of standard, so I use names in it. They're not specified by the standard, it says // these members are shown for exposition only: Which means the names are used only for the purposes of describing the semantics of the class, they are not normative requirements. See 17.5.2.3 [objects.within.classes].
RE: [PATCH][ARM][10/n] Partial IT block deprecation in ARMv8 AArch32 - thumb2.md changes
> Ping? Ah, just received your ok not even a second after I clicked send on the ping :) Thanks, Kyrill
[avr,committed] Make 1-byte loads from MEMX one byte shorted.
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=201121
Applied this obvious improvement of the sequence to load one byte from address
space memx (provided no ELPM is need).
The old sequence was
SBRC msb
LD reg, Z ; read from RAM
SBRS msp
LPM reg, Z ; read from flash
and the new one is
LPM reg, Z ; read from flash
SBRC msb
LD reg, Z ; read from RAM
This is legal because LPM never causes side effects.
Johann
* config/avr/avr.c (avr_out_xload): No SBIS around LPM so that
instruction sequence is 1 byte shorter.
Index: config/avr/avr.c
===
--- config/avr/avr.c(revision 201119)
+++ config/avr/avr.c(working copy)
@@ -3079,14 +3079,10 @@ avr_out_xload (rtx insn ATTRIBUTE_UNUSED
xop[2] = lpm_addr_reg_rtx;
xop[3] = AVR_HAVE_LPMX ? op[0] : lpm_reg_rtx;
- if (plen)
-*plen = 0;
+ avr_asm_len (AVR_HAVE_LPMX ? "lpm %3,%a2" : "lpm", xop, plen, -1);
avr_asm_len ("sbrc %1,7" CR_TAB
- "ld %3,%a2" CR_TAB
- "sbrs %1,7", xop, plen, 3);
-
- avr_asm_len (AVR_HAVE_LPMX ? "lpm %3,%a2" : "lpm", xop, plen, 1);
+ "ld %3,%a2", xop, plen, 2);
if (REGNO (xop[0]) != REGNO (xop[3]))
avr_asm_len ("mov %0,%3", xop, plen, 1);
Re: [PATCH] Fix pr57637
On 22 July 2013 17:56, Eric Botcazou wrote: >> The patch is updated based the comments: it will check GEN set of LIVE >> if df_live exists. Otherwise, just give up. > > The patch is missing a ChangeLog. Otherwise it looks good, modulo: > > + /* DF_LR_BB_INFO (bb)->def does not kill the DF_REF_PARTIAL and > +DF_REF_CONDITIONAL defs. So if DF_LIVE doesn't exist, i.e. > > "does not comprise" > > + at -O1, just give up to search NEXT_BLOCK > > "just give up searching" Updated. > I'm not sure this matters in practice, but don't we need to set the > appropriate > bit in the GEN set of BB at the end of the function if df_live is non-zero, at > least for the sake of consistency? And if df_live is non-zero, do we need update df_lr's IN and OUT? I think we need another patch to make all these consistency. >> And a testcase is included in the attached patch. > > Thanks. We generally try to make the testcases self-contained, i.e. remove > the > #include's as much as possible. It seems that stdlib.h is included for abort; > if so, remove it and use __builtin_abort instead. Would it be possible to > remove stdio.h as well? Update abort to __builtin_abort and malloc to __builtin_malloc. And remove all the include. ChangeLog 2013-07-22 Zhenqiang Chen * function.c (move_insn_for_shrink_wrap): check gen of df_live if it exists, otherwise (-O1) give up searching. gcc/testsuite/ChangeLog 2013-07-22 Zhenqiang Chen * gcc.target/arm/pr57637.c: New added. Is it OK? Thanks! -Zhenqiang pr57637-updated2.patch Description: Binary data
Re: testsuite patches (7/14): gcc.dg/pr46647.c: xfail for avr*-*-*
Quoting Georg-Johann Lay :
Joern Rennecke wrote:
xfail for avr*-*-*
Hi,
the target machine is avr-*-* because, say, avr32 (a 32-bit MCU not
officially
supported) is a quite different architecture than avr.
Similar for your other testsuite patches with avr*-*-*
I have attached amended versions of the patches 7/8/9/14.
tested for avr using --target_board=atmega128-sim .
2013-07-22 Joern Rennecke
* gcc.dg/pr46647.c: xfail for avr-*-*.
Index: gcc.dg/pr46647.c
===
--- gcc.dg/pr46647.c(revision 201032)
+++ gcc.dg/pr46647.c(working copy)
@@ -25,6 +25,6 @@ func3 (void)
return 0;
}
-/* The xfail for cris-* and crisv32-* is due to PR53535. */
-/* { dg-final { scan-tree-dump-not "memset" "optimized" { xfail cris-*-*
crisv32-*-* } } } */
+/* The xfail for avr, cris-* and crisv32-* is due to PR53535. */
+/* { dg-final { scan-tree-dump-not "memset" "optimized" { xfail avr-*-*
cris-*-* crisv32-*-* } } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */
2013-07-22 Joern Rennecke
* gcc.dg/pr53265.c: Disable test for avr-*-*.
Index: gcc.dg/pr53265.c
===
--- gcc.dg/pr53265.c(revision 201032)
+++ gcc.dg/pr53265.c(working copy)
@@ -1,5 +1,5 @@
/* PR tree-optimization/53265 */
-/* { dg-do compile } */
+/* { dg-do compile { target { ! avr-*-* } } } */ /* Don't run if arrays are
too large. */
/* { dg-options "-O2 -Wall" } */
void bar (void *);
2013-07-22 Joern Rennecke
* gcc.dg/strlenopt-10.c [avr-*-*]: Reduce number of expected
memcpy by one.
* gcc.dg/strlenopt-11.c [avr-*-*]: Likewise.
Expect l to be optimized away.
* gcc.dg/strlenopt-13.c [avr-*-*]: Likewise.
Index: gcc.dg/strlenopt-10.c
===
--- gcc.dg/strlenopt-10.c (revision 201032)
+++ gcc.dg/strlenopt-10.c (working copy)
@@ -70,7 +70,10 @@ main ()
}
/* { dg-final { scan-tree-dump-times "strlen \\(" 2 "strlen" } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen" } } */
+/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
+ to expand the memcpy call at the end of fn2. */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen" { target { !
avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen" { target {
avr-*-* } } } } */
/* { dg-final { scan-tree-dump-times "strcpy \\(" 0 "strlen" } } */
/* { dg-final { scan-tree-dump-times "strcat \\(" 0 "strlen" } } */
/* { dg-final { scan-tree-dump-times "strchr \\(" 0 "strlen" } } */
Index: gcc.dg/strlenopt-11.c
===
--- gcc.dg/strlenopt-11.c (revision 201032)
+++ gcc.dg/strlenopt-11.c (working copy)
@@ -59,12 +59,18 @@ main ()
}
/* { dg-final { scan-tree-dump-times "strlen \\(" 3 "strlen" } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen" } } */
+/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
+ to expand the memcpy call at the end of fn1. */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen" { target { !
avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 6 "strlen" { target {
avr-*-* } } } } */
/* { dg-final { scan-tree-dump-times "strcpy \\(" 0 "strlen" } } */
/* { dg-final { scan-tree-dump-times "strcat \\(" 0 "strlen" } } */
/* { dg-final { scan-tree-dump-times "strchr \\(" 0 "strlen" } } */
/* { dg-final { scan-tree-dump-times "stpcpy \\(" 0 "strlen" } } */
-/* { dg-final { scan-tree-dump-times " _\[0-9\]* = strlen
\\(\[^\n\r\]*;\[\n\r\]* l.0. = " 1 "strlen" } } */
-/* { dg-final { scan-tree-dump-times " _\[0-9\]* = strlen
\\(\[^\n\r\]*;\[\n\r\]* l.6. = " 1 "strlen" } } */
-/* { dg-final { scan-tree-dump-times " _\[0-9\]* = strlen
\\(\[^\n\r\]*;\[\n\r\]* l.9. = " 1 "strlen" } } */
+/* Where the memcpy is expanded, the assignemts to elements of l are
+ propagated. */
+/* { dg-final { scan-tree-dump-times " _\[0-9\]* = strlen
\\(\[^\n\r\]*;\[\n\r\]* l.0. = " 1 "strlen" { target { ! avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times " _\[0-9\]* = strlen
\\(\[^\n\r\]*;\[\n\r\]* l.6. = " 1 "strlen" { target { ! avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times " _\[0-9\]* = strlen
\\(\[^\n\r\]*;\[\n\r\]* l.9. = " 1 "strlen" { target { ! avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times " _\[0-9\]* = strlen \\(\[^\n\r\]*;" 3
"strlen" { target { avr-*-* } } } } */
/* { dg-final { cleanup-tree-dump "strlen" } } */
Index: gcc.dg/strlenopt-13.c
===
--- gcc.dg/strlenopt-13.c (revision 201032)
+++ gcc.dg/strlenopt-13.c (working copy)
@@ -56,13 +56,19 @@ main ()
}
/* { dg-final { scan-tree-dump-times "strlen \\(" 4 "strlen" } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\("
[testsuite,committed] ad PR52641 skip more tests on int16
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=201123
Applied this skip for int16 platforms that will obviously fail there.
Johann
PR testsuite/52641
* gcc.c-torture/execute/pr57124.x: Skip int16 platforms.
* gcc.c-torture/execute/pr53366-1.x: New: Skip int16 platforms.
Index: gcc.c-torture/execute/pr57124.x
===
--- gcc.c-torture/execute/pr57124.x (revision 201119)
+++ gcc.c-torture/execute/pr57124.x (working copy)
@@ -1,2 +1,9 @@
+load_lib target-supports.exp
+
set additional_flags "-fno-strict-overflow"
+
+if { [check_effective_target_int16] } {
+ return 1
+}
+
return 0
Index: gcc.c-torture/execute/pr53366-1.x
===
--- gcc.c-torture/execute/pr53366-1.x (revision 0)
+++ gcc.c-torture/execute/pr53366-1.x (revision 0)
@@ -0,0 +1,7 @@
+load_lib target-supports.exp
+
+if { [check_effective_target_int16] } {
+ return 1
+}
+
+return 0
[ubsan] Add more testing
This adds more testing to the ubsan testsuite. It still doesn't
test everything, but it's better than nothing and I've already found
one bug (already fixed).
Tested with RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}.
Commited to ubsan branch.
2013-07-22 Marek Polacek
* c-c++-common/ubsan/div-by-zero-3.c: Add more testing.
* c-c++-common/ubsan/div-by-zero-1.c: Likewise.
* c-c++-common/ubsan/shift-1.c: Likewise.
* c-c++-common/ubsan/shift-2.c: Likewise.
* c-c++-common/ubsan/div-by-zero-2.c: Likewise.
--- gcc/testsuite/c-c++-common/ubsan/div-by-zero-3.c.mp 2013-07-22
13:41:13.375402476 +0200
+++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-3.c2013-07-22
13:41:45.031527627 +0200
@@ -6,7 +6,16 @@
int
main (void)
{
+ volatile int min = INT_MIN;
+ volatile int zero = 0;
+
INT_MIN / -1;
+ min / -1;
+ min / (10 * zero - (2 - 1));
+
return 0;
}
- /* { dg-output "division of -2147483648 by -1 cannot be represented in type
int" } */
+
+/* { dg-output "division of -2147483648 by -1 cannot be represented in type
int(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division of -2147483648 by -1 cannot be represented
in type int(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division of -2147483648 by -1 cannot be represented
in type int(\n|\r\n|\r)" } */
--- gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c.mp 2013-07-22
13:41:13.370402454 +0200
+++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c2013-07-22
13:41:45.030527622 +0200
@@ -4,7 +4,21 @@
int
main (void)
{
+ volatile int a = 0;
+ volatile long long int b = 0;
+ volatile unsigned int c = 1;
+
+ a / b;
0 / 0;
+ a / 0;
+ 0 / b;
+ 2 / --c;
+
return 0;
}
- /* { dg-output "division by zero" } */
+
+/* { dg-output "division by zero(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division by zero(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division by zero(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division by zero(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division by zero(\n|\r\n|\r)" } */
--- gcc/testsuite/c-c++-common/ubsan/shift-1.c.mp 2013-07-22
13:41:13.377402486 +0200
+++ gcc/testsuite/c-c++-common/ubsan/shift-1.c 2013-07-22 13:41:45.032527632
+0200
@@ -1,11 +1,31 @@
/* { dg-do run } */
/* { dg-options "-fsanitize=shift -w" } */
+typedef const unsigned long long int CULLI;
+typedef volatile int VI;
+struct s { signed long int a; };
+
int
main (void)
{
int a = 1;
+ struct s s = { .a = 400 };
+ CULLI culli = 42;
+ VI vi = 370;
+ volatile int shiftcount = 153;
+
a <<= 152;
+ 1 << shiftcount;
+ 1 << 154;
+ culli << 524;
+ 1 << vi++;
+ (long) 1 << (s.a + 2);
+
return 0;
}
-/* { dg-output "shift exponent 152 is too large for \[^\n\r]*-bit type int" }
*/
+/* { dg-output "shift exponent 152 is too large for \[^\n\r]*-bit type
int(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent 153 is too large for \[^\n\r]*-bit
type int(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent 154 is too large for \[^\n\r]*-bit
type int(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent 524 is too large for \[^\n\r]*-bit
type long long unsigned int(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent 370 is too large for \[^\n\r]*-bit
type int(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent 402 is too large for \[^\n\r]*-bit
type long int(\n|\r\n|\r)" } */
--- gcc/testsuite/c-c++-common/ubsan/shift-2.c.mp 2013-07-22
13:41:13.378402491 +0200
+++ gcc/testsuite/c-c++-common/ubsan/shift-2.c 2013-07-22 13:41:45.033527637
+0200
@@ -5,7 +5,19 @@ int
main (void)
{
int a = 1;
- a <<= -3;
+ volatile int b = -5;
+ long long int c = -6;
+
+ a << -3;
+ 1 << -4;
+ 1 << b;
+ a << c;
+ a << (b + c);
+
return 0;
}
-/* { dg-output "shift exponent -3 is negative" } */
+/* { dg-output "shift exponent -3 is negative(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent -4 is negative(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent -5 is negative(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent -6 is negative(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*shift exponent -11 is negative(\n|\r\n|\r)" } */
--- gcc/testsuite/c-c++-common/ubsan/div-by-zero-2.c.mp 2013-07-22
13:41:13.374402471 +0200
+++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-2.c2013-07-22
13:41:45.031527627 +0200
@@ -4,7 +4,20 @@
int
main (void)
{
+ volatile const unsigned long int o = 1UL;
+ int zero = 0;
+
+ o / 0;
1UL / 0;
+ 1UL / zero;
+ o / zero;
+ o / (++zero - 1);
+
return 0;
}
- /* { dg-output "division by zero" } */
+
+/* { dg-output "division by zero(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division by zero(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division by zero(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division by zero(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*division by zero(\n|\r\n|\r)" } */
Marek
Re: [ARM][Insn classification refactoring 6/N] Delete "insn" attribute and update MOV classification
On 07/22/13 10:52, Sofiane Naci wrote: Oops sorry. Patch attached now. Ok Thanks, Ramana -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Ramana Radhakrishnan Sent: 22 July 2013 10:26 To: gcc-patches@gcc.gnu.org Subject: Re: [ARM][Insn classification refactoring 6/N] Delete "insn" attribute and update MOV classification On 07/19/13 15:10, Sofiane Naci wrote: Hi, This patch is part of the ongoing work of ARM instruction classification cleanup. This patch deletes the "insn" attribute and moves the MOV/MVN instruction classification to the "type" attribute, where it is split into several types for a finer-grained classification. This has been tested with a full arm-none-eabi toolchain build and regression run, as well as using random code generation tests to compare the output versus a baseline compiler. OK for trunk? ENOPATCH . Ramana Thanks Sofiane - ChangeLog: * config/arm/arm.md (attribute "insn"): Delete. (attribute "type"): Add "mov_imm", "mov_reg", "mov_shift", "mov_shift_reg", "mvn_imm", "mvn_reg", "mvn_shift" and "mvn_shift_reg". (not_shiftsi): Update for attribute change. (not_shiftsi_compare0): Likewise. (not_shiftsi_compare0_scratch): Likewise. (arm_one_cmplsi2): Likewise. (thumb1_one_cmplsi2): Likewise. (notsi_compare0): Likewise. (notsi_compare0_scratch): Likewise. (thumb1_movdi_insn): Likewise. (arm_movsi_insn): Likewise. (movhi_insn_arch4): Likewise. (movhi_bytes): Likewise. (arm_movqi_insn): Likewise. (thumb1_movqi_insn): Likewise. (arm32_movhf): Likewise. (thumb1_movhf): Likewise. (arm_movsf_soft_insn): Likewise. (thumb1_movsf_insn): Likewise. (thumb_movdf_insn): Likewise. (movsicc_insn): Likewise. (movsfcc_soft_insn): Likewise. (and_scc): Likewise. (cond_move): Likewise. (if_move_not): Likewise. (if_not_move): Likewise. (if_shift_move): Likewise. (if_move_shift): Likewise. (if_shift_shift): Likewise. (if_not_arith): Likewise. (if_arith_not): Likewise. (cond_move_not): Likewise. * config/arm/neon.md (neon_mov): Update for attribute change. (neon_mov): Likewise. * config/arm/vfp.md (arm_movsi_vfp): Update for attribute change. (thumb2_movsi_vfp): Likewise. (movsf_vfp): Likewise. (thumb2_movsf_vfp): Likewise. * config/arm/arm.c (xscale_sched_adjust_cost): Update for attribute change. (cortexa7_older_only): Likewise. (cortexa7_younger): Likewise. * config/arm/arm1020e.md (1020alu_op): Update for attribute change. (1020alu_shift_op): Likewise. (1020alu_shift_reg_op): Likewise. * config/arm/arm1026ejs.md (alu_op): Update for attribute change. (alu_shift_op): Likewise. (alu_shift_reg_op): Likewise. * config/arm/arm1136jfs.md (11_alu_op): Update for attribute change. (11_alu_shift_op): Likewise. (11_alu_shift_reg_op): Likewise. * config/arm/arm926ejs.md (9_alu_op): Update for attribute change. (9_alu_shift_reg_op): Likewise. * config/arm/cortex-a15.md (cortex_a15_alu): Update for attribute change. (cortex_a15_alu_shift): Likewise. (cortex_a15_alu_shift_reg): Likewise. * config/arm/cortex-a5.md (cortex_a5_alu): Update for attribute change. (cortex_a5_alu_shift): Likewise. * config/arm/cortex-a53.md (cortex_a53_alu): Update for attribute change. (cortex_a53_alu_shift): Likewise. * config/arm/cortex-a7.md (cortex_a7_alu_imm): Update for attribute change. (cortex_a7_alu_reg): Likewise. (cortex_a7_alu_shift): Likewise. * config/arm/cortex-a8.md (cortex_a8_alu): Update for attribute change. (cortex_a8_alu_shift): Likewise. (cortex_a8_alu_shift_reg): Likewise. (cortex_a8_mov): Likewise. * config/arm/cortex-a9.md (cortex_a9_dp): Update for attribute change. (cortex_a9_dp_shift): Likewise. * config/arm/cortex-m4.md (cortex_m4_alu): Update for attribute change. * config/arm/cortex-r4.md (cortex_r4_alu): Update for attribute change. (cortex_r4_mov): Likewise. (cortex_r4_alu_shift): Likewise. (cortex_r4_alu_shift_reg): Likewise. * config/arm/fa526.md (526_alu_op): Update for attribute change. (526_alu_shift_op): Likewise. * config/arm/fa606te.md (606te_alu_op): Update for attribute change. * config/arm/fa626te.md (626te_alu_op): Update for attribute change. (626te_alu_shift_op): Likewise. * config/arm/fa726te.md (726te_shift_op): Update for attribute change. (726te_alu_op): Likewise. (726te_alu_shift_op): Likewise. (726te_alu_shift_reg_op)
[v3] libstdc++/57920
Hi,
see audit trail for details. I tested on x86_64-linux (with/without
_GLIBCXX_X86_RDRAND artificially undefined) the below straightforward
patch and checked by hand the strace. I'm going to apply it soon.
Thanks,
Paolo.
///
2013-07-22 Paolo Carlini
PR c++/57920
* src/c++11/random.cc (random_device::_M_getval): If possible, use
read instead of std::fread.
* include/std/random: Do not include unnecessarily.
Index: include/std/random
===
--- include/std/random (revision 201122)
+++ include/std/random (working copy)
@@ -36,7 +36,6 @@
#else
#include
-#include
#include
#include
#include
Index: src/c++11/random.cc
===
--- src/c++11/random.cc (revision 201122)
+++ src/c++11/random.cc (working copy)
@@ -30,7 +30,12 @@
# include
#endif
+#include
+#ifdef _GLIBCXX_HAVE_UNISTD_H
+# include
+#endif
+
namespace std _GLIBCXX_VISIBILITY(default)
{
@@ -126,8 +131,12 @@
#endif
result_type __ret;
+#ifdef _GLIBCXX_HAVE_UNISTD_H
+read(fileno(_M_file), reinterpret_cast(&__ret),
sizeof(result_type));
+#else
std::fread(reinterpret_cast(&__ret), sizeof(result_type),
1, _M_file);
+#endif
return __ret;
}
[Patch, Fortran, committed] Plug two memory leaks
Found by Coverity. In the first case, "error" gets overridden if status
is not NULL_TREE. The second case is rather obvious.
Committed as Rev. 201125 after built on x86-64-gnu-linux.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 201124)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2013-07-21 Tobias Burnus
+
+ * trans-array.c (gfc_array_allocate,
+ gfc_trans_deferred_array): Plug memory leak.
+
2013-07-21 OndÅej BÃlka
* trans-decl.c: Fix comment typos.
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (Revision 201124)
+++ gcc/fortran/trans-array.c (Arbeitskopie)
@@ -5209,7 +5209,7 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr,
&se->pre, &set_descriptor_block, &overflow,
expr3_elem_size, nelems, expr3, ts);
- if (dimension)
+ if (status == NULL_TREE && dimension)
{
var_overflow = gfc_create_var (integer_type_node, "overflow");
@@ -5223,8 +5223,7 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr,
error = build_call_expr_loc (input_location, gfor_fndecl_runtime_error,
1, msg);
}
-
- if (status != NULL_TREE)
+ else if (status != NULL_TREE)
{
tree status_type = TREE_TYPE (status);
stmtblock_t set_status_block;
@@ -8525,10 +8524,12 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wr
&& !sym->attr.save && !sym->attr.result
&& !sym->ns->proc_name->attr.is_main_program)
{
+ gfc_expr *e;
+ e = has_finalizer ? gfc_lval_expr_from_sym (sym) : NULL;
tmp = gfc_trans_dealloc_allocated (sym->backend_decl,
- sym->attr.codimension,
- has_finalizer
- ? gfc_lval_expr_from_sym (sym) : NULL);
+ sym->attr.codimension, e);
+ if (e)
+ gfc_free_expr (e);
gfc_add_expr_to_block (&cleanup, tmp);
}
Re: RFC: Gimple combine/folding interface
On 07/20/2013 02:09 AM, Andrew Pinski wrote:
gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
allow_full_reassiocation(reas) {}
I think this constructor should be marked "explicit".
--
Florian Weimer / Red Hat Product Security Team
Re: [PATCH] Fix pr57637
> And if df_live is non-zero, do we need update df_lr's IN and OUT? I think > we need another patch to make all these consistency. Possibly, but this would belong to another patch. I nevertheless think that we should set the bit in the GEN set because we'll be testing the GEN set now. The patch is OK with this change if it passes the usual testing. > ChangeLog > 2013-07-22 Zhenqiang Chen > > * function.c (move_insn_for_shrink_wrap): check gen of df_live if > it exists, otherwise (-O1) give up searching. Capital letter at the beginning, and I'd expand a little on it, something like: * function.c (move_insn_for_shrink_wrap): Also check the GEN set of the LIVE problem for the liveness analysis if it exists, otherwise give up. > gcc/testsuite/ChangeLog > 2013-07-22 Zhenqiang Chen > > * gcc.target/arm/pr57637.c: New added. "New testcase" -- Eric Botcazou
[google] Fix target specifier for testsuite/g++.dg/pr57878.C
This test was failing with -m64 because it was forcing -m32
instead of asking for ilp32.
Committed to google/gcc-4_8 and trunk.
Diego.
Index: gcc/testsuite/g++.dg/pr57878.C
===
--- gcc/testsuite/g++.dg/pr57878.C (revision 201124)
+++ gcc/testsuite/g++.dg/pr57878.C (working copy)
@@ -1,5 +1,5 @@
-/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
-/* { dg-options "-m32 -O2 -fno-omit-frame-pointer -fPIC -std=gnu++11" } */
+/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
+/* { dg-options "-O2 -fno-omit-frame-pointer -fPIC -std=gnu++11" } */
typedef int int32;
typedef long long int64;
libbacktrace: walk the elf_syminfo_data chain in elf_syminfo
Hello,
this fixes a bug (found by inspection) that would prevent elf_syminfo from
looking up symbols defined in modules other than the executable.
Bootstrapped and regtested together with the next patch on x86_64-linux
(excluding Java, including Go), OK for trunk?
libbacktrace/Changelog:
2013-07-22 Alexander Monakov
* elf.c (elf_syminfo): Loop over the elf_syminfo_data chain.
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index ef9bcdf..a90afaa 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -454,12 +454,15 @@ elf_syminfo (struct backtrace_state *state, uintptr_t pc,
void *data)
{
struct elf_syminfo_data *edata;
- struct elf_symbol *sym;
+ struct elf_symbol *sym = NULL;
+
+ for (edata = (struct elf_syminfo_data *) state->syminfo_data;
+ edata && sym == NULL;
+ edata = edata->next)
+sym = ((struct elf_symbol *)
+ bsearch (&pc, edata->symbols, edata->count,
+ sizeof (struct elf_symbol), elf_symbol_search));
- edata = (struct elf_syminfo_data *) state->syminfo_data;
- sym = ((struct elf_symbol *)
-bsearch (&pc, edata->symbols, edata->count,
- sizeof (struct elf_symbol), elf_symbol_search));
if (sym == NULL)
callback (data, pc, NULL, 0);
else
[PATCH] Don't include gimple.h twice
I don't think there's a reason to include gimple.h twice... Regtested/bootstrapped on x86_64-linux, will commit as obvious soon. 2013-07-22 Marek Polacek * gimplify.c: Don't include gimple.h twice. --- gcc/gimplify.c.mp 2013-07-22 15:29:17.202468003 +0200 +++ gcc/gimplify.c 2013-07-22 15:29:25.891502560 +0200 @@ -42,7 +42,6 @@ along with GCC; see the file COPYING3. #include "pointer-set.h" #include "splay-tree.h" #include "vec.h" -#include "gimple.h" #include "langhooks-def.h" /* FIXME: for lhd_set_decl_assembler_name */ #include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ Marek
Re: [Patch, Fortran, committed] Plug two memory leaks
Tobias Burnus wrote:
Found by Coverity. In the first case, "error" gets overridden if
status is not NULL_TREE. The second case is rather obvious.
I managed to commit an early draft of the patch - I meant to apply the
one attached (relative diff) instead.
Committed follow-up fix as Rev. 201129 after building and regtesting on
x86-64-gnu-linux.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 201125)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,5 +1,9 @@
2013-07-22 Tobias Burnus
+ * trans-array.c (gfc_array_allocate): Correct memory-leak patch.
+
+2013-07-22 Tobias Burnus
+
* trans-array.c (gfc_array_allocate,
gfc_trans_deferred_array): Plug memory leak.
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (Revision 201125)
+++ gcc/fortran/trans-array.c (Arbeitskopie)
@@ -5209,29 +5209,31 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr,
&se->pre, &set_descriptor_block, &overflow,
expr3_elem_size, nelems, expr3, ts);
- if (status == NULL_TREE && dimension)
+ if (dimension)
{
-
var_overflow = gfc_create_var (integer_type_node, "overflow");
gfc_add_modify (&se->pre, var_overflow, overflow);
- /* Generate the block of code handling overflow. */
- msg = gfc_build_addr_expr (pchar_type_node,
- gfc_build_localized_cstring_const
+ if (status == NULL_TREE)
+ {
+ /* Generate the block of code handling overflow. */
+ msg = gfc_build_addr_expr (pchar_type_node,
+ gfc_build_localized_cstring_const
("Integer overflow when calculating the amount of "
"memory to allocate"));
- error = build_call_expr_loc (input_location, gfor_fndecl_runtime_error,
- 1, msg);
-}
- else if (status != NULL_TREE)
-{
- tree status_type = TREE_TYPE (status);
- stmtblock_t set_status_block;
+ error = build_call_expr_loc (input_location,
+ gfor_fndecl_runtime_error, 1, msg);
+ }
+ else
+ {
+ tree status_type = TREE_TYPE (status);
+ stmtblock_t set_status_block;
- gfc_start_block (&set_status_block);
- gfc_add_modify (&set_status_block, status,
- build_int_cst (status_type, LIBERROR_ALLOCATION));
- error = gfc_finish_block (&set_status_block);
+ gfc_start_block (&set_status_block);
+ gfc_add_modify (&set_status_block, status,
+ build_int_cst (status_type, LIBERROR_ALLOCATION));
+ error = gfc_finish_block (&set_status_block);
+ }
}
gfc_start_block (&elseblock);
libbacktrace: allow using DWARF if the main executable lacks it
This fixes a bug that would prevent using DWARF debug info available in dynamically linked libraries when the main executable did not have DWARF debug info. pd.fileline_fn is not examined after dl_iterate_phdr in backtrace_initialize, so updating *fileline_fn in dl_iterate_phdr is useless as later it is overwritten from elf_fileline_fn. OK for trunk? 2013-07-22 Alexander Monakov * elf.c (backtrace_initialize): Pass elf_fileline_fn to dl_iterate_phdr callbacks. diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c index a90afaa..fde884a 100644 --- a/libbacktrace/elf.c +++ b/libbacktrace/elf.c @@ -865,7 +865,7 @@ backtrace_initialize (struct backtrace_state *state, int descriptor, pd.state = state; pd.error_callback = error_callback; pd.data = data; - pd.fileline_fn = fileline_fn; + pd.fileline_fn = &elf_fileline_fn; pd.found_sym = &found_sym; pd.found_dwarf = &found_dwarf;
Re: Go patch committed: Update libgo to 1.1.1
Hello! > I have committed a large patch to update libgo to the library that was > part of the Go 1.1.1 release. As usual, I'm not including the entire > patch in this e-mail message, because it is too large. I'm only > including the changes to the files that are partially gccgo-specific. > Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. > Committed to mainline and 4.8 branch. I have hit following build failure on non-USING_SPLIT_STACK target (alpha-linux-gnu): >>> >>> Thanks. Fixed like so. Committed to mainline and 4.8 branch. >> >> Thanks, with your patch, I was able to compile libgo without problems. >> The testsuite run exposes a timeout in net/http, I am looking into it. I have also managed to trigger the timeout on x86_64-pc-linux-gnu. The test was re-run with GOTESTFLAGS=--keep. When running the resulting a.out with "strace -f -o strace-x86_64 ./a.out" from the saved test directory, the test behaved in the same way as on alpha - it hever finished. I have attached the resulting trace (the test was killed with ctrl-c after some time). Uros. strace-x86_64.bz2 Description: BZip2 compressed data
Re: [Patch, PR 57790] Waste work in can_move_insns_across()
On 07/21/2013 07:45 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790 I bootstrapped and ran the regression tests for this patch on x86_64-linux and all tests pass. In method "can_move_insns_across()" in df-problems.c, the loop on line 4038 should break immediately after "fail" is set to 1. All the iterations after "fail" set to 1 do not perform any useful work, at best they just set "fail" again to 1. Thanks. I'll install shortly. In the future if you could also include a ChangeLog entry it would be appreciated. It's format is pretty simple. Here's the one I'll use for this change: 2013-07-22 Chang * df-problems.c (can_move_insns_across): Exit loop once we find a non-fixed, non-global register.
Re: [ubsan] Add libcall arguments
On 07/19/2013 02:45 PM, Marek Polacek wrote:
/* This type represents an entry in the hash table. */
struct ubsan_typedesc
{
+ /* This represents the type of a variable. */
tree type;
+
+ /* This is the VAR_DECL of the type. */
tree decl;
};
What I was looking for was something along the lines of "this hash table
maps from a TYPE to a ubsan type descriptor VAR_DECL for that type".
Jason
Re: [PATCH] Don't include gimple.h twice
On 07/22/2013 07:31 AM, Marek Polacek wrote: I don't think there's a reason to include gimple.h twice... Regtested/bootstrapped on x86_64-linux, will commit as obvious soon. 2013-07-22 Marek Polacek * gimplify.c: Don't include gimple.h twice. OK. jeff
Re: libbacktrace: walk the elf_syminfo_data chain in elf_syminfo
On Mon, Jul 22, 2013 at 6:26 AM, Alexander Monakov wrote: > > this fixes a bug (found by inspection) that would prevent elf_syminfo from > looking up symbols defined in modules other than the executable. > > Bootstrapped and regtested together with the next patch on x86_64-linux > (excluding Java, including Go), OK for trunk? > > libbacktrace/Changelog: > 2013-07-22 Alexander Monakov > > * elf.c (elf_syminfo): Loop over the elf_syminfo_data chain. Thanks for noticing the problem. This patch isn't enough by itself. The code has to protect itself against the list changing in mid-stream. See dwarf_fileline in dwarf.c. Ian
Re: libbacktrace: allow using DWARF if the main executable lacks it
On Mon, Jul 22, 2013 at 6:34 AM, Alexander Monakov wrote: > > 2013-07-22 Alexander Monakov > > * elf.c (backtrace_initialize): Pass elf_fileline_fn to > dl_iterate_phdr callbacks. This is OK. Thanks. Ian
Re: [Patch, PR57803] Wasted work in gfc_build_dummy_array_decl()
On 07/19/2013 04:59 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57803 I bootstrapped and ran the regression tests for this patch on x86_64-linux and all tests pass. In method "gfc_build_dummy_array_decl()" in gcc/fortran/trans-decl.c, the loop on line 978 should break immediately after "packed" is set to "PACKED_PARTIAL". All the iterations after "packed" set to "PACKED_PARTIAL" do not perform any useful work, at best they just set "packed" again to "PACKED_PARTIAL". Thanks. I've installed the patches from all of your emails which address these issues. I'm a bit curious, are you finding these by inspection of the sources or via some kind of analysis code? Thanks again, Jeff
[PATCH][committed] Fix FAIL: gcc.dg/pr53265.c (test for warnings, line 88)
Hi all, r201119 adds an extra line to the testcase that confuses the dg-message which explicitly hardocdes a line number. This patch updates the testcase. Committed as obvious as r201135. Thanks, Kyrill 2013-07-22 Kyrylo Tkachov * gcc.dg/pr53265.c: Correct line number in dg-message. pr53265-fix.patch Description: Binary data
[C++ testcase, committed] PR 52816
Hi,
testcase committed to mainline.
Thanks,
Paolo.
///
2013-07-22 Paolo Carlini
PR c++/52816
* g++.dg/cpp0x/decltype56.C: New.
Index: g++.dg/cpp0x/decltype56.C
===
--- g++.dg/cpp0x/decltype56.C (revision 0)
+++ g++.dg/cpp0x/decltype56.C (working copy)
@@ -0,0 +1,11 @@
+// PR c++/52816
+// { dg-do compile { target c++11 } }
+
+class c {
+ int f;
+ public:
+ template
+ decltype(f) m(A) const;
+};
+
+decltype(c{}.m(0)) i;
[Patch, PR 57811] Wasted work in find_reloads()
Hi,
The problem appears in revision 201034 in version 4.9. I attached
one-line patches that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811
Bootstrap and regression-tested on x86_64-linux.
In method "find_reloads()" in gcc/reload.c, the loop on line 3324 should
break immediately after "badop" is set to "1". Also, the loop on line 4641
should break after "ok" is set to "0".
2013-07-22 Chang
* reload.c (find_reloads): Exit loop once we find this operand
cannot be reloaded somehow for this alternative.
* reload.c (find_reloads): Exit loop once we find a
hard register.
Index: gcc/reload.c
===
--- gcc/reload.c(revision 201034)
+++ gcc/reload.c(working copy)
@@ -3324,7 +3324,10 @@
for (j = 0; j < i; j++)
if (this_alternative_matches[j]
== this_alternative_matches[i])
- badop = 1;
+ {
+ badop = 1;
+ break;
+ }
break;
case 'p':
Index: gcc/reload.c
===
--- gcc/reload.c(revision 201034)
+++ gcc/reload.c(working copy)
@@ -4640,7 +4640,10 @@
for (nri = 1; nri < nr; nri ++)
if (! TEST_HARD_REG_BIT (reg_class_contents[rld[i].rclass], regno
+ nri))
- ok = 0;
+ {
+ ok = 0;
+ break;
+ }
if (ok)
rld[i].reg_rtx = dest;
-Chang
Index: gcc/reload.c
===
--- gcc/reload.c(revision 201034)
+++ gcc/reload.c(working copy)
@@ -3324,7 +3324,10 @@
for (j = 0; j < i; j++)
if (this_alternative_matches[j]
== this_alternative_matches[i])
- badop = 1;
+ {
+ badop = 1;
+ break;
+ }
break;
case 'p':Index: gcc/reload.c
===
--- gcc/reload.c(revision 201034)
+++ gcc/reload.c(working copy)
@@ -4640,7 +4640,10 @@
for (nri = 1; nri < nr; nri ++)
if (! TEST_HARD_REG_BIT (reg_class_contents[rld[i].rclass], regno
+ nri))
- ok = 0;
+ {
+ ok = 0;
+ break;
+ }
if (ok)
rld[i].reg_rtx = dest;
[Patch, PR 57812] Wasted work in computed_jump_p()
Hi,
The problem appears in revision 201034 in version 4.9. I also reported
this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57812.
Bootstrap and regression-tested on x86_64-linux.
In method "computed_jump_p()" in gcc/rtlanal.c, the loop on line 2801
should break immediately after "has_use_labelref" is set to "1".
2013-07-22 Chang
* rtlanal.c (computed_jump_p): Exit loop once we find label
reference is used.
Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c (revision 201034)
+++ gcc/rtlanal.c (working copy)
@@ -2802,7 +2802,10 @@
if (GET_CODE (XVECEXP (pat, 0, i)) == USE
&& (GET_CODE (XEXP (XVECEXP (pat, 0, i), 0))
== LABEL_REF))
- has_use_labelref = 1;
+ {
+ has_use_labelref = 1;
+ break;
+ }
if (! has_use_labelref)
for (i = len - 1; i >= 0; i--)
-Chang
Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c (revision 201034)
+++ gcc/rtlanal.c (working copy)
@@ -2802,7 +2802,10 @@
if (GET_CODE (XVECEXP (pat, 0, i)) == USE
&& (GET_CODE (XEXP (XVECEXP (pat, 0, i), 0))
== LABEL_REF))
- has_use_labelref = 1;
+ {
+ has_use_labelref = 1;
+ break;
+ }
if (! has_use_labelref)
for (i = len - 1; i >= 0; i--)
Re: [Patch, PR 57811] Wasted work in find_reloads()
On Mon, Jul 22, 2013 at 11:39:38AM -0500, pcha...@cs.wisc.edu wrote: > Hi, > > The problem appears in revision 201034 in version 4.9. I attached > one-line patches that fixes it. I also reported this problem > at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 > > Bootstrap and regression-tested on x86_64-linux. > > In method "find_reloads()" in gcc/reload.c, the loop on line 3324 should > break immediately after "badop" is set to "1". Also, the loop on line 4641 > should break after "ok" is set to "0". > > > 2013-07-22 Chang > > * reload.c (find_reloads): Exit loop once we find this operand > cannot be reloaded somehow for this alternative. > > * reload.c (find_reloads): Exit loop once we find a > hard register. Perhaps just 2013-07-22 Chang * reload.c (find_reloads): Exit loop after setting badop. Exit loop after setting ok. Otherwise looks ok, just note that your MTA mangled the second patch. Marek
[Patch, Fortran, committed] PR57762 - Fix memleak in gfortran.dg/class_array_7.f03
That's a patch of the category: Make the testers happy (here: Dominque).
gfortran (in GCC 4.9) no longer frees allocatable at the end of the main
program as they get implicitly the SAVE attribute (cf. Fortran 2008) -
and that's now detectable due to finalizers.
Result: gfortran.dg/class_array_7.f03 now leaks memory, which clutters
the valgrind output of the test suite. As the test itself is agnostic to
a tailing deallocate, I added one.
Committed as Rev. 201137.
Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 201136)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2013-07-22 Tobias Burnus
+
+ PR fortran/57762
+ * gfortran.dg/class_array_7.f03: Fix memory leak.
+
2013-07-22 Paolo Carlini
PR c++/52816
Index: gcc/testsuite/gfortran.dg/class_array_7.f03
===
--- gcc/testsuite/gfortran.dg/class_array_7.f03 (Revision 201136)
+++ gcc/testsuite/gfortran.dg/class_array_7.f03 (Arbeitskopie)
@@ -54,4 +54,5 @@ program main
if (trim (print_type ("a", a)) .ne. "a is extended_type") call abort
call reallocate (a)
if (trim (print_type ("a", a)) .ne. "a is base_type") call abort
+ deallocate (a)
end program main
module VEC_REAL_MODULE
contains
pure function VEC_REAL_norm(self) result(res)
real, dimension(:), intent(in) :: self
res = self(1)
end function
function MAT_REAL_row_norms(self) result(res)
real, dimension(:,:) :: self
real, dimension(size(self,1)) :: res
do i = 1,size(self,1)
res(i) = VEC_REAL_norm(self(i,:))
end do
end function
pure subroutine MAT_REAL_zero_small_values(self,eps)
real(8), dimension(:,:) :: self
intent(inout) :: self
real(8), intent(in) :: eps
where (abs(self)
[PATCH][4.8 backport] Fix PR57735
Hi all, The fix for PR57735 is in current trunk (for a different issue I think), just needs a backport to 4.8. It is r198462 by Richard Sandiford: 2013-04-30 Richard Sandiford * explow.c (plus_constant): Pass "mode" to immed_double_int_const. Use gen_int_mode rather than GEN_INT. Ok to backport to the 4.8 branch? I've attached the testcase that exposed the ICE. I think the ChangeLog would look like this: 2013-07-22 Kyrylo Tkachov PR target/57735 Backport from mainline 2013-04-30 Richard Sandiford * explow.c (plus_constant): Pass "mode" to immed_double_int_const. Use gen_int_mode rather than GEN_INT. 2013-07-22 Kyrylo Tkachov PR target/57735 * g++.dg/ext/pr57735.C: New test. Thanks, Kyrill pr57735-test.patch Description: Binary data
Re: [ubsan] Add libcall arguments
On Mon, Jul 22, 2013 at 10:09:00AM -0400, Jason Merrill wrote:
> On 07/19/2013 02:45 PM, Marek Polacek wrote:
> > /* This type represents an entry in the hash table. */
> > struct ubsan_typedesc
> > {
> >+ /* This represents the type of a variable. */
> > tree type;
> >+
> >+ /* This is the VAR_DECL of the type. */
> > tree decl;
> > };
>
> What I was looking for was something along the lines of "this hash
> table maps from a TYPE to a ubsan type descriptor VAR_DECL for that
> type".
Ah. Hopefully it's ok this time around; I already commited previous
patch, thus this patchlet.
2013-07-22 Marek Polacek
* ubsan.c (struct ubsan_typedesc): Improve comment.
--- gcc/ubsan.c.mp 2013-07-22 16:14:16.266199381 +0200
+++ gcc/ubsan.c 2013-07-22 16:19:48.335517383 +0200
@@ -31,7 +31,8 @@ along with GCC; see the file COPYING3.
#include "ubsan.h"
#include "c-family/c-common.h"
-/* This type represents an entry in the hash table. */
+/* This type represents an entry in the hash table; this hash table
+ maps from a TYPE to a ubsan type descriptor VAR_DECL for that type. */
struct ubsan_typedesc
{
/* This represents the type of a variable. */
Marek
[PATCH, PowerPC] rs6000_expand_vector_init selects wrong field for splat in LE mode
In little-endian mode, the field selected for use in a vector splat is
numbered differently than in big-endian mode. This patch corrects the
code generated for little-endian. This addresses 45 test failures when
running the test-suite in little-endian mode.
Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
regressions. Ok for trunk?
Patch by Anton Blanchard.
Thanks,
Bill
2013-07-22 Bill Schmidt
for Anton Blanchard
* config/rs6000/rs6000.c (rs6000_expand_vector_init): Fix
endianness when selecting field to splat.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 201131)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -5177,6 +5177,7 @@ rs6000_expand_vector_init (rtx target, rtx vals)
of 64-bit items is not supported on Altivec. */
if (all_same && GET_MODE_SIZE (inner_mode) <= 4)
{
+ rtx field;
mem = assign_stack_temp (mode, GET_MODE_SIZE (inner_mode));
emit_move_insn (adjust_address_nv (mem, inner_mode, 0),
XVECEXP (vals, 0, 0));
@@ -5187,9 +5188,11 @@ rs6000_expand_vector_init (rtx target, rtx vals)
gen_rtx_SET (VOIDmode,
target, mem),
x)));
+ field = (BYTES_BIG_ENDIAN ? const0_rtx
+ : GEN_INT (GET_MODE_NUNITS (mode) - 1));
x = gen_rtx_VEC_SELECT (inner_mode, target,
gen_rtx_PARALLEL (VOIDmode,
- gen_rtvec (1, const0_rtx)));
+ gen_rtvec (1, field)));
emit_insn (gen_rtx_SET (VOIDmode, target,
gen_rtx_VEC_DUPLICATE (mode, x)));
return;
Re: [PATCH 1/*] Fix common typos.
On Jul 21, 2013, at 2:21 PM, Joseph S. Myers wrote:
> On Sun, 21 Jul 2013, Mike Stump wrote:
>>
>>> - /* Now we have to go throught the whole table
>>> + /* Now we have to go thought the whole table
>>>
>>> Again, throught -> through.
>>
>> Fixed.
>
> Again, the checked-in change is incorrect ("though").
Fixed.
Index: libiberty/regex.c
===
--- libiberty/regex.c (revision 201138)
+++ libiberty/regex.c (revision 201139)
@@ -3396,7 +3396,7 @@ PREFIX(regex_compile) (const char *ARG_P
class. */
PATFETCH (c);
- /* Now we have to go though the whole table
+ /* Now we have to go through the whole table
and find all characters which have the same
first level weight.
Re: [PATCH 1/*] Fix common typos.
On Jul 21, 2013, at 2:18 PM, Joseph S. Myers wrote: > On Sun, 21 Jul 2013, Mike Stump wrote: > >>> diff --git a/gcc/testsuite/c-c++-common/pr41779.c >>> b/gcc/testsuite/c-c++-common/pr41779.c >>> index 80c8e6b..f80412c 100644 >>> --- a/gcc/testsuite/c-c++-common/pr41779.c >>> +++ b/gcc/testsuite/c-c++-common/pr41779.c >>> @@ -1,4 +1,4 @@ >>> -/* PR41779: Wconversion cannot see throught real*integer promotions. */ >>> +/* PR41779: Wconversion cannot see thought real*integer promotions. */ >>> >>> This change is not ok (eh, OK), it should've been "through". > > The checked-in version of this file is still wrong, it now has "though" > which should be "through". Fixed, thanks.
Re: [Patch, Fortran] PR57906 - fix issue with coarray component assignment
On Mon, Jul 22, 2013 at 07:17:50PM +0200, Tobias Burnus wrote: > For coarrays, an assignment does not affect the allocation status. That > also implies that the type parameters, shape and effective types between > the LHS and RHS have to match. > > For coarrays components, that's handled (since Rev. 200955) by > re-assigning the saved data after the assignment: > > tmp = LHS; > LHS = RHS; > LHS.caf = RHS.caf; > > However, as the PR shows, the middle end for some reasons optimizes the > latter assignment away. My impression is that that's due to the > "restrict" issue (PR45586). The patch now only assigns the data > component, which seems to work: > > tmp = LHS; > LHS = RHS; > LHS.caf.data = RHS.caf.data; > > Other changes: > - Change space+tab to tab > - Add a test case, which I seemingly forgot to include in r200955 > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? > OK. -- Steve
[Patch, Fortran] PR57906 - fix issue with coarray component assignment
For coarrays, an assignment does not affect the allocation status. That
also implies that the type parameters, shape and effective types between
the LHS and RHS have to match.
For coarrays components, that's handled (since Rev. 200955) by
re-assigning the saved data after the assignment:
tmp = LHS;
LHS = RHS;
LHS.caf = RHS.caf;
However, as the PR shows, the middle end for some reasons optimizes the
latter assignment away. My impression is that that's due to the
"restrict" issue (PR45586). The patch now only assigns the data
component, which seems to work:
tmp = LHS;
LHS = RHS;
LHS.caf.data = RHS.caf.data;
Other changes:
- Change space+tab to tab
- Add a test case, which I seemingly forgot to include in r200955
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-07-22 Tobias Burnus
PR fortran/57906
PR fortran/52052
* class.c (gfc_build_class_symbol): Set coarray_comp.
* trans-array.c (structure_alloc_comps): For coarrays,
directly use the data pointer address.
2013-07-22 Tobias Burnus
PR fortran/57906
PR fortran/52052
* coarray/lib_realloc_1.f90: Permit optimization.
* gfortran.dg/coarray_31.f90: New.
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index ba8efa9..51bfd56 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -666,6 +666,7 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
fclass->attr.extension = ts->u.derived->attr.extension + 1;
fclass->attr.alloc_comp = ts->u.derived->attr.alloc_comp;
+ fclass->attr.coarray_comp = ts->u.derived->attr.coarray_comp;
}
fclass->attr.is_class = 1;
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 3fdd8d9..0aac678 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7589,9 +7589,9 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
if ((c->ts.type == BT_DERIVED && !c->attr.pointer)
|| (c->ts.type == BT_CLASS && !CLASS_DATA (c)->attr.class_pointer))
- {
- comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
- decl, cdecl, NULL_TREE);
+ {
+ comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
+ decl, cdecl, NULL_TREE);
/* The finalizer frees allocatable components. */
called_dealloc_with_status
@@ -7737,8 +7737,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
cdecl, NULL_TREE);
dcmp = fold_build3_loc (input_location, COMPONENT_REF, ctype, dest,
cdecl, NULL_TREE);
+
if (c->attr.codimension)
- gfc_add_modify (&fnblock, dcmp, comp);
+ {
+ if (c->ts.type == BT_CLASS)
+ {
+ comp = gfc_class_data_get (comp);
+ dcmp = gfc_class_data_get (dcmp);
+ }
+ gfc_conv_descriptor_data_set (&fnblock, dcmp,
+ gfc_conv_descriptor_data_get (comp));
+ }
else
{
tmp = structure_alloc_comps (c->ts.u.derived, comp, dcmp,
diff --git a/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90 b/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
index ed906f5..f3d7f35 100644
--- a/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
+++ b/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
@@ -1,5 +1,4 @@
! { dg-do run }
-! { dg-options "-O0" }
!
! Test that for CAF components _gfortran_caf_deregister is called
! Test that norealloc happens for CAF components during assignment
--- /dev/null 2013-07-22 10:09:57.614189406 +0200
+++ gcc/gcc/testsuite/gfortran.dg/coarray_31.f90 2013-07-22 19:13:40.460945010 +0200
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original -fcoarray=single" }
+!
+! PR fortran/57906
+! PR fortran/52052
+!
+type t
+ integer, allocatable :: x(:)[:]
+ class(*), allocatable :: z(:)[:]
+ class(*), allocatable :: d[:]
+end type t
+type t2
+ type(t) :: y
+end type t2
+type(t2) :: a, b
+a = b
+end
+
+! { dg-final { scan-tree-dump "a.y.x.data = D.\[0-9\]+.y.x.data;" "original" } }
+! { dg-final { scan-tree-dump "a.y.z._data.data = D.\[0-9\]+.y.z._data.data;" "original" } }
+! { dg-final { scan-tree-dump "a.y.d._data.data = D.\[0-9\]+.y.d._data.data;" "original" } }
+! { dg-final { cleanup-tree-dump "original" } }
Re: [PATCH 1/*] Fix common typos.
On Jul 21, 2013, at 2:09 PM, Joseph S. Myers wrote:
> On Sun, 21 Jul 2013, Mike Stump wrote:
>
>> I've reviewed and applied the gcc/doc changes that were trivial. The
>> only patches not applied were the ok->OK patches.
>
> *For formal documentation* such as gcc/doc, I think changing ok->OK is
> appropriate;
I agree. Formal prose is different, so here are the instances that I found in
doc/*. Thanks for the review.
Index: doc/tm.texi
===
--- doc/tm.texi (revision 201137)
+++ doc/tm.texi (working copy)
@@ -4959,7 +4959,7 @@ the function prologue. Normally, the pr
@cindex tail calls
@deftypefn {Target Hook} bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree @var{decl},
tree @var{exp})
-True if it is ok to do sibling call optimization for the specified
+True if it is OK to do sibling call optimization for the specified
call expression @var{exp}. @var{decl} will be the called function,
or @code{NULL} if this is an indirect call.
@@ -9861,7 +9861,7 @@ needed.
@deftypefn {Target Hook} bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P
(const_tree @var{fndecl})
@cindex inlining
-This target hook returns @code{true} if it is ok to inline @var{fndecl}
+This target hook returns @code{true} if it is OK to inline @var{fndecl}
into the current function, despite its having target-specific
attributes, @code{false} otherwise. By default, if a function has a
target specific attribute attached to it, it will not be inlined.
Index: target.def
===
--- target.def (revision 201137)
+++ target.def (working copy)
@@ -1880,7 +1880,7 @@ needed.",
DEFHOOK
(function_attribute_inlinable_p,
"@cindex inlining\n\
-This target hook returns @code{true} if it is ok to inline @var{fndecl}\n\
+This target hook returns @code{true} if it is OK to inline @var{fndecl}\n\
into the current function, despite its having target-specific\n\
attributes, @code{false} otherwise. By default, if a function has a\n\
target specific attribute attached to it, it will not be inlined.",
@@ -2529,7 +2529,7 @@ The default value of this hook is based
this is an indirect call. */
DEFHOOK
(function_ok_for_sibcall,
- "True if it is ok to do sibling call optimization for the specified\n\
+ "True if it is OK to do sibling call optimization for the specified\n\
call expression @var{exp}. @var{decl} will be the called function,\n\
or @code{NULL} if this is an indirect call.\n\
\n\
[C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?
Hi all, Jason,
while looking a bit into c++/57942, I noticed (again) that in the
definition of the predicate DERIVED_FROM_P we use tf_warning_or_error,
not tf_none, which seems weird for a predicate, being in general able to
produce hard errors (*). I tested the below with no regressions.
Thanks,
Paolo.
(*) Note that, depending on how it's called, the predicate can currently
produce errors anyway, for example because it calls complete_type. This
may or may not be all there is to c++/57942.
Index: cp-tree.h
===
--- cp-tree.h (revision 201122)
+++ cp-tree.h (working copy)
@@ -1320,8 +1320,7 @@ enum languages { lang_c, lang_cplusplus, lang_java
/* Nonzero iff TYPE is derived from PARENT. Ignores accessibility and
ambiguity issues. */
#define DERIVED_FROM_P(PARENT, TYPE) \
- (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_warning_or_error)\
- != NULL_TREE)
+ (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_none) != NULL_TREE)
/* Gives the visibility specification for a class type. */
#define CLASSTYPE_VISIBILITY(TYPE) \
[Patch, PR 57787] Wasted work in ix86_pad_returns()
Hi,
The problem appears in revision 201034 in version 4.9. I also reported
this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787.
Bootstrap and regression-tested on x86_64-linux.
In method "ix86_pad_returns()" in i386.c, the loop on line 35723 should
break immediately after "replace" is set to "true".
2013-07-22 Chang
* i386.c (ix86_pad_returns): Exit loop after setting replace.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 201034)
+++ gcc/config/i386/i386.c (working copy)
@@ -35723,7 +35723,10 @@
FOR_EACH_EDGE (e, ei, bb->preds)
if (EDGE_FREQUENCY (e) && e->src->index >= 0
&& !(e->flags & EDGE_FALLTHRU))
- replace = true;
+ {
+ replace = true;
+ break;
+ }
}
if (!replace)
{
-Chang
Re: [PATCH 1/*] Fix common typos.
On Sun, 2013-07-21 at 09:35 -0700, Mike Stump wrote: > On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote: > > This is series of typo fixing patches. They are generated with stylepp > > https://github.com/neleai/stylepp > > which makes patch generation very effective. > > I've checked in most changes to Objective-C things and test suite things > after reviewing all those changes. I agreed with most of the work, except ok > -> OK. We don't need to scream in the source, and ok I feel is a fine > english word, despite what an expert might think (they would burn us (me) at > the grammar stake. They merely trail us in language adoption. :-) > > One part I will throw out here, in gcc/testsuite/gcc.target/sh/pr54760-4.c: > > - and its use when a function call is inbetween, when GBR is a call used > + and its use when a function call is between, when GBR is a call used > > I think this should be: > > - and its use when a function call is inbetween, when GBR is a call used > + and its use when a function call is in-between, when GBR is a call used > > If someone wants to try and counter this, please, I'd favor an expert that > can clarify why it would be preferable. If I remember correctly, it was me who wrote it in the first place. It should be 'a function call in between, when'. Thanks for catching it. Cheers, Oleg
Re: libbacktrace: walk the elf_syminfo_data chain in elf_syminfo
On Mon, 22 Jul 2013, Ian Lance Taylor wrote:
> Thanks for noticing the problem. This patch isn't enough by itself.
> The code has to protect itself against the list changing in
> mid-stream. See dwarf_fileline in dwarf.c.
Thank you. Here's the updated patch, however I have to admit it's not
entirely clear to me what __sync_bool_compare_and_swap should achieve. Is it
only to ensure that we do not use a partially updated pointer (which shouldn't
happen with a naturally aligned pointer on hardware that updates cache lines
atomically)?
2013-07-22 Alexander Monakov
* elf.c (elf_syminfo): Loop over the elf_syminfo_data chain.
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index ef9bcdf..1d64a1f 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -454,12 +454,46 @@ elf_syminfo (struct backtrace_state *state, uintptr_t pc,
void *data)
{
struct elf_syminfo_data *edata;
- struct elf_symbol *sym;
+ struct elf_symbol *sym = NULL;
+
+ if (!state->threaded)
+{
+ for (edata = (struct elf_syminfo_data *) state->syminfo_data;
+ edata;
+ edata = edata->next)
+ {
+ sym = ((struct elf_symbol *)
+bsearch (&pc, edata->symbols, edata->count,
+ sizeof (struct elf_symbol), elf_symbol_search));
+ if (sym != NULL)
+ break;
+ }
+}
+ else
+{
+ struct elf_syminfo_data **pp;
+
+ pp = (struct elf_syminfo_data **) (void *) &state->syminfo_data;
+ while (1)
+ {
+ edata = *pp;
+ /* Atomic load. */
+ while (!__sync_bool_compare_and_swap (pp, edata, edata))
+ edata = *pp;
+
+ if (edata == NULL)
+ break;
+
+ sym = ((struct elf_symbol *)
+bsearch (&pc, edata->symbols, edata->count,
+ sizeof (struct elf_symbol), elf_symbol_search));
+ if (sym != NULL)
+ break;
+
+ pp = &edata->next;
+ }
+}
- edata = (struct elf_syminfo_data *) state->syminfo_data;
- sym = ((struct elf_symbol *)
-bsearch (&pc, edata->symbols, edata->count,
- sizeof (struct elf_symbol), elf_symbol_search));
if (sym == NULL)
callback (data, pc, NULL, 0);
else
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
Hi, On Wed, Jul 17, 2013 at 09:18:22PM -0400, David Malcolm wrote: > gcc/ > > Explicitly number the instances of passes within passes.def. > > This is needed by a subsequent patch so that we can create > fields within the pipeline class for each pass instance (to help > locate pass instances when debugging). > I don't really understand what you want to achieve. Are you sure the benefits are worth the work necessary to implement the processing of passes.def.in? Especially given that we already initialize static_pass_number at run time and copy stuff around in make_pass_instance when it is already set. I assume this would somehow allow us to directly dump data of say forwprop3 as apposed to forwprop2 to but that would require constant awareness of the sequence number of the currently running pass, which I think is also unpleasant and error-prone. I mean, you may have perfectly legitimate reasons for doing this, I'm just wondering whether we are perhaps over-engineering this a bit. Thanks, Martin
Re: [PATCH][4.8 backport] Fix PR57735
"Kyrylo Tkachov" writes: > Hi all, > > The fix for PR57735 is in current trunk (for a different issue I think), just > needs a backport to 4.8. > It is r198462 by Richard Sandiford: > > 2013-04-30 Richard Sandiford > > * explow.c (plus_constant): Pass "mode" to immed_double_int_const. > Use gen_int_mode rather than GEN_INT. > > Ok to backport to the 4.8 branch? Sorry for dropping the ball. It's already been approved for 4.8, and I think I even remembered to test it ready for commit. I just never actually hit commit afterwards :-( Thanks, Richard
Re: [PATCH][4.8 backport] Fix PR57735
Richard Sandiford writes: > "Kyrylo Tkachov" writes: >> Hi all, >> >> The fix for PR57735 is in current trunk (for a different issue I think), just >> needs a backport to 4.8. >> It is r198462 by Richard Sandiford: >> >> 2013-04-30 Richard Sandiford >> >> * explow.c (plus_constant): Pass "mode" to immed_double_int_const. >> Use gen_int_mode rather than GEN_INT. >> >> Ok to backport to the 4.8 branch? > > Sorry for dropping the ball. It's already been approved for 4.8, > and I think I even remembered to test it ready for commit. I just > never actually hit commit afterwards :-( *sigh*. Scratch that. I'd confused it with: 2013-05-22 Richard Sandiford * recog.c (offsettable_address_addr_space_p): Fix calculation of address mode. Move pointer mode initialization to the same place. which I _did_ apply to 4.8. Sorry about the confusion instead... Richard
Re: [PATCH] FPU IEEE 754 for MIPS r5900
Hi Jürgen,
Thanks for the update, looks good.
"Jürgen Urban" writes:
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc(Revision 200583)
> +++ gcc/config.gcc(Arbeitskopie)
> @@ -3080,7 +3080,7 @@
>esac
> fi
>
> -# Infer a default setting for --with-float.
> +# Infer a default setting for --with-float and --with-fpu.
> if test x$with_float = x; then
>case ${target} in
> mips64r5900-*-* | mips64r5900el-*-* | mipsr5900-*-* | mipsr5900el-*-*)
> @@ -3089,6 +3089,17 @@
>with_float=soft
>;;
>esac
> +else
> + case ${target} in
> +mips64r5900-*-* | mips64r5900el-*-* | mipsr5900-*-* | mipsr5900el-*-*)
> + if test $with_float = hard; then
> +if test x$with_fpu = x; then
> + # The FPU of the R5900 is 32 bit.
> + with_fpu=single
> +fi
> + fi
> + ;;
> + esac
> fi
I think the --with-fpu default should be independent of the --with-float
default. Passing -mhard-float to the default soft-float configuration
should produce the same code as configuring with --with-float=hard.
> Index: gcc/config/mips/mips.c
> ===
> --- gcc/config/mips/mips.c(Revision 200583)
> +++ gcc/config/mips/mips.c(Arbeitskopie)
> @@ -16830,6 +16830,19 @@
> target_flags &= ~MASK_FLOAT64;
> }
>
> + if (TARGET_HARD_FLOAT_ABI && TARGET_FLOAT64 && TARGET_MIPS5900)
> +{
> + /* FPU of r5900 only supports 32 bit. */
> + error ("unsupported combination: %s", "-march=r5900 -mfp64
> -mhard-float");
> +}
> +
> + if (TARGET_HARD_FLOAT_ABI && TARGET_DOUBLE_FLOAT && TARGET_MIPS5900)
> +{
> + /* FPU of r5900 only supports 32 bit. */
> + error ("unsupported combination: %s",
> + "-march=r5900 -mdouble-float -mhard-float");
> +}
Only one of these should be needed, since we complain about -mfp64
-msingle-float earlier in the function. Also, the coding conventions
say that there should be no braces for single-statement if blocks.
Here's what I installed. Please let me know if I managed to mangle
things somehow.
Thanks,
Richard
gcc/
2013-07-26 Jürgen Urban
* config.gcc (mips*-*-*): Add --with-fpu support. Make single the
default for R5900 targets.
* config/mips/mips.h (OPTION_DEFAULT_SPECS): Handle --with-fpu.
(ISA_HAS_LDC1_SDC1): Set to false for TARGET_MIPS5900.
* config/mips/mips.c (mips_option_override): Report an error for
-march=r5900 -mhard-float -mdouble-float. Use spu_single_format
for -march=r5900 -mhard-float.
Index: gcc/config.gcc
===
--- gcc/config.gcc 2013-07-17 08:36:01.712940987 +0100
+++ gcc/config.gcc 2013-07-22 19:09:28.435708983 +0100
@@ -3091,6 +3091,16 @@ if test x$with_float = x; then
esac
fi
+# Infer a default setting for --with-fpu.
+if test x$with_fpu = x; then
+ case ${target} in
+mips64r5900-*-* | mips64r5900el-*-* | mipsr5900-*-* | mipsr5900el-*-*)
+ # The R5900 FPU only supports single precision.
+ with_fpu=single
+ ;;
+ esac
+fi
+
# Support --with-fpmath.
if test x$with_fpmath != x; then
case ${target} in
@@ -3469,7 +3479,7 @@ case "${target}" in
;;
mips*-*-*)
- supported_defaults="abi arch arch_32 arch_64 float tune tune_32
tune_64 divide llsc mips-plt synci"
+ supported_defaults="abi arch arch_32 arch_64 float fpu tune
tune_32 tune_64 divide llsc mips-plt synci"
case ${with_float} in
"" | soft | hard)
@@ -3480,6 +3490,16 @@ case "${target}" in
exit 1
;;
esac
+
+ case ${with_fpu} in
+ "" | single | double)
+ # OK
+ ;;
+ *)
+ echo "Unknown fpu type used in --with-fpu=$with_fpu"
1>&2
+ exit 1
+ ;;
+ esac
case ${with_abi} in
"" | 32 | o64 | n32 | 64 | eabi)
Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h 2013-07-17 08:36:01.756941409 +0100
+++ gcc/config/mips/mips.h 2013-07-22 09:19:36.822510281 +0100
@@ -754,6 +754,7 @@ #define OPTION_DEFAULT_SPECS \
{"tune_64", "%{" OPT_ARCH64 ":%{!mtune=*:-mtune=%(VALUE)}}" }, \
{"abi", "%{!mabi=*:-mabi=%(VALUE)}" }, \
{"float", "%{!msoft-float:%{!mhard-float:-m%(VALUE)-float}}" }, \
+ {"fpu", "%{!msingle-float:%{!mdouble-float:-m%(VALUE)-float}}" }, \
{"divide", "%{!mdivide-traps:%{!mdivide-breaks:-mdivide-%(VALUE)}}" }, \
{"llsc", "%{!mllsc:%{!mno-llsc:-m%(VALUE)}}" }, \
{"mips-plt", "%{!mplt:%{!mno-plt:-m%(VALUE)}}" }, \
@@ -859,7 +860,9 @@ #define ISA_HAS_CONDMOVE(ISA_HAS
Re: [PATCH 1/*] Fix common typos.
On Jul 22, 2013, at 11:20 AM, Oleg Endo wrote:
> On Sun, 2013-07-21 at 09:35 -0700, Mike Stump wrote:
>> On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
>>> This is series of typo fixing patches. They are generated with stylepp
>>> https://github.com/neleai/stylepp
>>> which makes patch generation very effective.
>>
>> I've checked in most changes to Objective-C things and test suite things
>> after reviewing all those changes. I agreed with most of the work, except
>> ok -> OK. We don't need to scream in the source, and ok I feel is a fine
>> english word, despite what an expert might think (they would burn us (me) at
>> the grammar stake. They merely trail us in language adoption. :-)
>>
>> One part I will throw out here, in gcc/testsuite/gcc.target/sh/pr54760-4.c:
>>
>> - and its use when a function call is inbetween, when GBR is a call used
>> + and its use when a function call is between, when GBR is a call used
>>
>> I think this should be:
>>
>> - and its use when a function call is inbetween, when GBR is a call used
>> + and its use when a function call is in-between, when GBR is a call used
>>
>> If someone wants to try and counter this, please, I'd favor an expert that
>> can clarify why it would be preferable.
>
> If I remember correctly, it was me who wrote it in the first place.
> It should be 'a function call in between, when'.
Thanks.
Index: testsuite/gcc.target/sh/pr54760-4.c
===
--- testsuite/gcc.target/sh/pr54760-4.c (revision 201137)
+++ testsuite/gcc.target/sh/pr54760-4.c (working copy)
@@ -1,5 +1,5 @@
/* Check that the GBR address optimization does not combine a gbr store
- and its use when a function call is in-between, when GBR is a call used
+ and its use when a function call is in between, when GBR is a call used
register, i.e. it is invalidated by function calls. */
/* { dg-do compile { target "sh*-*-*" } } */
/* { dg-options "-O1 -fcall-used-gbr" } */
Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?
OK. (*) Note that, depending on how it's called, the predicate can currently produce errors anyway, for example because it calls complete_type. This may or may not be all there is to c++/57942. It looks like lookup_base seems to deliberately avoid trying to complete the base, so the call to complete_type is coming from elsewhere. Jason
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
On Mon, 2013-07-22 at 20:25 +0200, Martin Jambor wrote:
> Hi,
>
> On Wed, Jul 17, 2013 at 09:18:22PM -0400, David Malcolm wrote:
> > gcc/
> >
> > Explicitly number the instances of passes within passes.def.
> >
> > This is needed by a subsequent patch so that we can create
> > fields within the pipeline class for each pass instance (to help
> > locate pass instances when debugging).
> >
>
> I don't really understand what you want to achieve. Are you sure the
> benefits are worth the work necessary to implement the processing of
> passes.def.in? Especially given that we already initialize
> static_pass_number at run time and copy stuff around in
> make_pass_instance when it is already set. I assume this would
> somehow allow us to directly dump data of say forwprop3 as apposed to
> forwprop2 to but that would require constant awareness of the sequence
> number of the currently running pass, which I think is also unpleasant
> and error-prone.
>
> I mean, you may have perfectly legitimate reasons for doing this, I'm
> just wondering whether we are perhaps over-engineering this a bit.
The main goal here is part of eliminating global variables from gcc [1],
to be able to create:
class pipeline
{
/* omitting various other fields for clarity */
opt_pass *pass_warn_unused_result;
opt_pass *pass_diagnose_omp_blocks;
opt_pass *pass_diagnose_tm_blocks;
opt_pass *pass_mudflap_1;
opt_pass *pass_lower_omp;
opt_pass *pass_lower_cf;
opt_pass *pass_lower_tm;
opt_pass *pass_refactor_eh;
opt_pass *pass_lower_eh;
opt_pass *pass_build_cfg;
opt_pass *pass_warn_function_return;
opt_pass *pass_expand_omp;
opt_pass *pass_build_cgraph_edges;
opt_pass *pass_ipa_free_lang_data;
opt_pass *pass_ipa_function_and_variable_visibility;
opt_pass *pass_early_local_passes;
opt_pass *pass_fixup_cfg;
opt_pass *pass_init_datastructures;
/* etc */
opt_pass *pass_clean_state;
};
without having to list all of the pass kinds again, thus reusing the
pass description from passes.def. Without the numbering, I couldn't see
a good way to avoid duplicate field names in the class. So the
numbering gives us uniqueness of field names in that class (and also
makes debugging slightly easier, but that's a minor side-benefit).
Hope that makes sense
[BTW I've just spent much of the day fighting awk trying to write a
script to generate a pass-instances.def from passes.def, but have given
up in frustration for now (how hard can it be to capture a group from a
regex, track it in a dictionary, and print a substitution with a key and
dict lookup? hard for me in awk, it seems); am working on fixing the
bad interaction of PCH with GTY-marking of per-pass data in the
meantime].
[1] http://dmalcolm.fedorapeople.org/gcc/global-state/
Re: RFC: Gimple combine/folding interface
On 07/21/2013 08:14 PM, Andrew Pinski wrote:
On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski wrote:
I was creating a new gimple/folding interface and wanted some opinions
on the interface.
typedef double_int (*nonzerobits_t)(tree var);
typedef tree (*valueizer_t)(tree var);
class gimple_combine
{
public:
gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
IIRC, the zero/nonzero bits stuff in combine is mostly good at pruning
sign/zero extensions, eliminating bit masking in the low bits for alphas
and for cleaning up addressing of varargs arguments that were on the
stack. Yea, there are times when it can do other stuff, but that's my
recollection for what it was actually good at.
Before designing an interface which inherently includes that information
we should think hard about if it's valuable and if a tree combiner is
the right place.
I have high hopes that we can get the zero/sign extension elimination we
want by carrying VRP information and querying it.
As Richi has mentioned, we really want a folder we can call
independently of whatever pass we're in. Though I'd also like a folder
that can query for pass specific information if it's handy and useful.
One of the interesting things we're going to need to figure out is when
walking the use-def chains do we want to build the more complex
expression, then fold it, keeping the result if it's gimple. Or do we
want to work strictly with an exploded operator/operands represenation.
Jeff
Re: RFC: Gimple combine/folding interface
On Mon, Jul 22, 2013 at 01:36:17PM -0600, Jeff Law wrote:
> Before designing an interface which inherently includes that
> information we should think hard about if it's valuable and if a
> tree combiner is the right place.
>
> I have high hopes that we can get the zero/sign extension
> elimination we want by carrying VRP information and querying it.
>
> As Richi has mentioned, we really want a folder we can call
> independently of whatever pass we're in. Though I'd also like a
> folder that can query for pass specific information if it's handy
> and useful.
For the preservation of VRP info we already have patch in process of review:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00121.html
As for zero bits info, I've recently run into a case where having the zero
bits information preserved alongside of the VRP info could be helpful,
for optimizing away the vectorizer scalar loop for bound. If non-zero bits
computation proves or e.g. user asserts through if (val % 32)
__builtin_unreachable () or similar, even when the bounds of the loop aren't
constant, we could figure out that the number of iterations is a multiply of
vectorization factor and avoid computing that
So, perhaps let vrp{1,2} compute the vrp info and preserve (plus if not
specified just set nonzero bits to all ones), and this pass or other compute
the nonzero bits? Sign bit copies is just an int, perhaps also track that.
Jakub
Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?
On 07/22/2013 09:22 PM, Jason Merrill wrote: OK. Thanks, applied. (*) Note that, depending on how it's called, the predicate can currently produce errors anyway, for example because it calls complete_type. This may or may not be all there is to c++/57942. It looks like lookup_base seems to deliberately avoid trying to complete the base, so the call to complete_type is coming from elsewhere. I see, indeed the comment in lookup_base: /* If BASE is incomplete, it can't be a base of T--and instantiating it might cause an error. */ is very clear. Now, I tell you briefly what is going on: standard_conversion calls ptr_reasonably_similar, which, in turn calls comptypes. The latter, via structural_comptypes, does: if ((strict & COMPARE_BASE) && DERIVED_FROM_P (t1, t2)) break; else if ((strict & COMPARE_DERIVED) && DERIVED_FROM_P (t2, t1)) break; you see, DERIVED_FROM_P, thus lookup_base, handles *both* the pair (base, derived) and the swapped pair (derived, base), thus for sure in one case the above comment / code doesn't help, because it protects vs the instantiation of the base argument not vs the instantiation of the t argument... bummer. I guess fixing the issue must be rather doable but at the moment I'm not clear about where to act... Thanks! Paolo.
[PATCH] Use CHECKSUM_ macros and ULEB128 checksum for DIE tag
Hi Cary,
This patch changes the ODR checker to use the CHECKSUM_ macros and
instead of depending on size of int to use the ULEB128 of the tag
(similar to the deep hash) to compute the values.
Thoughts?
-eric
2013-07-22 Eric Christopher
* dwarf2out.c (die_odr_checksum): New function to use
CHECKSUM_ macros and ULEB128 for DIE tag.
(generate_type_signature): Use.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 198904)
+++ gcc/dwarf2out.c (working copy)
@@ -6097,6 +6097,13 @@
CHECKSUM_ULEB128 (0);
}
+static void
+die_odr_checksum (dw_die_ref die, md5_ctx *ctx)
+{
+ CHECKSUM_ULEB128(die->die_tag);
+ CHECKSUM_STRING(get_AT_string(die, DW_AT_name));
+}
+
#undef CHECKSUM
#undef CHECKSUM_STRING
#undef CHECKSUM_ATTR
@@ -6128,7 +6135,6 @@
/* First, compute a signature for just the type name (and its surrounding
context, if any. This is stored in the type unit DIE for link-time
ODR (one-definition rule) checking. */
-
if (is_cxx() && name != NULL)
{
md5_init_ctx (&ctx);
@@ -6137,8 +6143,8 @@
if (parent != NULL)
checksum_die_context (parent, &ctx);
- md5_process_bytes (&die->die_tag, sizeof (die->die_tag), &ctx);
- md5_process_bytes (name, strlen (name) + 1, &ctx);
+ /* Checksum the current DIE. */
+ die_odr_checksum(die, &ctx);
md5_finish_ctx (&ctx, checksum);
add_AT_data8 (type_node->root_die, DW_AT_GNU_odr_signature,
&checksum[8]);
Re: [PATCH] Use CHECKSUM_ macros and ULEB128 checksum for DIE tag
On Mon, Jul 22, 2013 at 01:15:15PM -0700, Eric Christopher wrote:
> --- gcc/dwarf2out.c (revision 198904)
> +++ gcc/dwarf2out.c (working copy)
> @@ -6097,6 +6097,13 @@
>CHECKSUM_ULEB128 (0);
> }
>
I guess you should add a function comment, plus spaces before ( everywhere
(and while you're at it, you can change also the is_cxx() ). Will leave the
rest to Cary.
> +static void
> +die_odr_checksum (dw_die_ref die, md5_ctx *ctx)
> +{
> + CHECKSUM_ULEB128(die->die_tag);
> + CHECKSUM_STRING(get_AT_string(die, DW_AT_name));
> +}
> +
> #undef CHECKSUM
> #undef CHECKSUM_STRING
> #undef CHECKSUM_ATTR
> @@ -6128,7 +6135,6 @@
>/* First, compute a signature for just the type name (and its surrounding
> context, if any. This is stored in the type unit DIE for link-time
> ODR (one-definition rule) checking. */
> -
>if (is_cxx() && name != NULL)
> {
>md5_init_ctx (&ctx);
> @@ -6137,8 +6143,8 @@
>if (parent != NULL)
> checksum_die_context (parent, &ctx);
>
> - md5_process_bytes (&die->die_tag, sizeof (die->die_tag), &ctx);
> - md5_process_bytes (name, strlen (name) + 1, &ctx);
> + /* Checksum the current DIE. */
> + die_odr_checksum(die, &ctx);
>md5_finish_ctx (&ctx, checksum);
>
>add_AT_data8 (type_node->root_die, DW_AT_GNU_odr_signature,
> &checksum[8]);
Jakub
Re: libbacktrace: walk the elf_syminfo_data chain in elf_syminfo
On Mon, Jul 22, 2013 at 11:20 AM, Alexander Monakov wrote: > On Mon, 22 Jul 2013, Ian Lance Taylor wrote: >> Thanks for noticing the problem. This patch isn't enough by itself. >> The code has to protect itself against the list changing in >> mid-stream. See dwarf_fileline in dwarf.c. > > Thank you. Here's the updated patch, however I have to admit it's not > entirely clear to me what __sync_bool_compare_and_swap should achieve. Is it > only to ensure that we do not use a partially updated pointer (which shouldn't > happen with a naturally aligned pointer on hardware that updates cache lines > atomically)? We not only need to get a valid pointer, we need to ensure when thread T1 creates the pointer and thread T2 loads the pointer, thread T2 sees all the global stores that thread T1 made before T1 set the pointer. That is, we need an acquire-load. The hope here is that any sane implementation of __sync_bool_compare_and_swap would ensure sequential consistency between T1 and T2, implying an acquire-load. On x86 every load is an acquire-load, but that is not true on other processors. If we added some configure tests, or didn't worry about letting people use this library with older versions of GCC, we could use __atomic_load_n (pp, __ATOMIC_ACQUIRE) here, and use something like __atomic_compare_exchange_n (pp, NULL, edata, true, __ATOMIC_RELEASE, __ATOMIC_RELAXED) in elf_add_syminfo_data. I don't think it would make any difference on x86, though. > 2013-07-22 Alexander Monakov > > * elf.c (elf_syminfo): Loop over the elf_syminfo_data chain. > + for (edata = (struct elf_syminfo_data *) state->syminfo_data; > + edata; Please explicitly write edata != NULL. This is OK with that change. Thanks. Ian
Re: [PATCH] Use CHECKSUM_ macros and ULEB128 checksum for DIE tag
- md5_process_bytes (&die->die_tag, sizeof (die->die_tag), &ctx); - md5_process_bytes (name, strlen (name) + 1, &ctx); + /* Checksum the current DIE. */ + die_odr_checksum(die, &ctx); Since we've already gone to the trouble of getting the name of this DIE, it seems wasteful to have die_odr_checksum call get_AT_string again. Why not just pass name as a parameter? > I guess you should add a function comment, plus spaces before ( everywhere > (and while you're at it, you can change also the is_cxx() ). Will leave the > rest to Cary. Agree with the function comment and the spaces. > 2013-07-22 Eric Christopher > > * dwarf2out.c (die_odr_checksum): New function to use > CHECKSUM_ macros and ULEB128 for DIE tag. > (generate_type_signature): Use. This is OK with those changes. Thanks! -cary
Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?
I guess ptr_reasonably_similar should return false if one of the target types is incomplete. Jason
[SPARC] Work around data cache nullify issues on LEON3
This enhances -mfix-ut699 to work around the data cache nullify issues recently
uncovered on the LEON3 processor, as documented in the relevant errata sheet.
Tested on SPARC/Solaris, applied on the mainline.
2013-07-22 Eric Botcazou
* config.gcc (sparc*-*-*): Accept leon3 processor.
(sparc-leon*-*): Merge with sparc*-*-* and add leon3 support.
* doc/invoke.texi (SPARC Options): Adjust -mfix-ut699 entry.
* config/sparc/sparc-opts.h (enum processor_type): Add PROCESSOR_LEON3.
* config/sparc/sparc.opt (enum processor_type): Add leon3.
(mfix-ut699): Adjust comment.
* config/sparc/sparc.h (TARGET_CPU_leon3): New define.
(CPP_CPU32_DEFAULT_SPEC): Add leon3 support.
(CPP_CPU_SPEC): Likewise.
(ASM_CPU_SPEC): Likewise.
* config/sparc/sparc.c (leon3_cost): New constant.
(sparc_option_override): Add leon3 support.
(mem_ref): New function.
(sparc_gate_work_around_errata): Return true if -mfix-ut699 is enabled.
(sparc_do_work_around_errata): Look into the instruction in the delay
slot and adjust accordingly. Add fix for the data cache nullify issues
of the UT699. Change insertion position for the NOP.
* config/sparc/leon.md (leon_fpalu, leon_fpmds, write_buf): Delete.
(leon3_load): New reservation.
(leon_store): Bump latency to 2.
(grfpu): New automaton.
(grfpu_alu): New unit.
(grfpu_ds): Likewise.
(leon_fp_alu): Adjust.
(leon_fp_mult): Delete.
(leon_fp_div): Split into leon_fp_divs and leon_fp_divd.
(leon_fp_sqrt): Split into leon_fp_sqrts and leon_fp_sqrtd.
* config/sparc/sparc.md (cpu): Add leon3.
* config/sparc/sync.md (atomic_exchangesi): Disable if -mfix-ut699.
(swapsi): Likewise.
(atomic_test_and_set): Likewise.
(ldstub): Likewise.
--
Eric Botcazou
Index: config.gcc
===
--- config.gcc (revision 201053)
+++ config.gcc (working copy)
@@ -3642,7 +3642,7 @@ case "${target}" in
case ${val} in
"" | sparc | sparcv9 | sparc64 \
| v7 | cypress \
- | v8 | supersparc | hypersparc | leon \
+ | v8 | supersparc | hypersparc | leon | leon3 \
| sparclite | f930 | f934 | sparclite86x \
| sparclet | tsc701 \
| v9 | ultrasparc | ultrasparc3 | niagara | niagara2 \
@@ -3799,15 +3799,6 @@ case ${target} in
cxx_target_objs="${cxx_target_objs} sh-c.o"
;;
- sparc-leon*-*)
- if test x$with_tune = x ; then
- with_tune=leon;
- fi
-
- # The SPARC port checks this value at compile-time.
- target_cpu_default2="TARGET_CPU_$with_cpu"
- ;;
-
sparc*-*-*)
# Some standard aliases.
case x$with_cpu in
@@ -3819,6 +3810,17 @@ case ${target} in
;;
esac
+ if test x$with_tune = x ; then
+ case ${target} in
+ *-leon-*)
+ with_tune=leon
+ ;;
+ *-leon[3-9]*)
+ with_tune=leon3
+ ;;
+ esac
+ fi
+
# The SPARC port checks this value at compile-time.
target_cpu_default2="TARGET_CPU_$with_cpu"
;;
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 201053)
+++ doc/invoke.texi (working copy)
@@ -19491,8 +19491,8 @@ processor (which corresponds to erratum
@item -mfix-ut699
@opindex mfix-ut699
-Enable the documented workarounds for the floating-point errata of the UT699
-processor.
+Enable the documented workarounds for the floating-point errata and the data
+cache nullify errata of the UT699 processor.
@end table
These @samp{-m} options are supported in addition to the above
Index: config/sparc/sparc.md
===
--- config/sparc/sparc.md (revision 201053)
+++ config/sparc/sparc.md (working copy)
@@ -206,7 +206,7 @@ (define_mode_iterator F [SF DF TF])
;; 'f' for all DF/TFmode values, including those that are specific to the v8.
;; Attribute for cpu type.
-;; These must match the values for enum processor_type in sparc.h.
+;; These must match the values of the enum processor_type in sparc-opts.h.
(define_attr "cpu"
"v7,
cypress,
@@ -214,6 +214,7 @@ (define_attr "cpu"
supersparc,
hypersparc,
leon,
+ leon3,
sparclite,
f930,
f934,
Index: config/sparc/sparc.opt
===
--- config/sparc/sparc.opt (revision 201053)
+++ config/sparc/sparc.opt (working copy)
@@ -146,6 +146,9 @@ EnumValue
Enum(sparc_processor_type) String(leon) Value(PROCESSOR_LEON)
EnumValue
+Enum(sparc_processor_type) String(leon3) Value(PROCESSOR_LEON3)
+
+EnumValue
Enum(sparc_processor_type) String(sparclite) Value(PROCESSOR_SPARCLITE)
EnumValue
@@ -203,7 +206,7 @@ Enable workaround for single erratum of
mfix-ut699
Target Report RejectNegative Var(sparc_fix_ut699)
-Enable workarounds for the FP errata of the UT699 processor
+
Re: [SPARC] Work around data cache nullify issues on LEON3
From: Eric Botcazou Date: Mon, 22 Jul 2013 23:34:29 +0200 > This enhances -mfix-ut699 to work around the data cache nullify issues > recently > uncovered on the LEON3 processor, as documented in the relevant errata sheet. > > Tested on SPARC/Solaris, applied on the mainline. Looks good, nice work Eric.
Re: [PATCH] Use CHECKSUM_ macros and ULEB128 checksum for DIE tag
On Mon, Jul 22, 2013 at 1:30 PM, Cary Coutant wrote: > - md5_process_bytes (&die->die_tag, sizeof (die->die_tag), &ctx); > - md5_process_bytes (name, strlen (name) + 1, &ctx); > + /* Checksum the current DIE. */ > + die_odr_checksum(die, &ctx); > > Since we've already gone to the trouble of getting the name of this > DIE, it seems wasteful to have die_odr_checksum call get_AT_string > again. Why not just pass name as a parameter? > Was mostly being cute and assuming it'd get removed. I'll just pass both of them down into the function for now. If we decide later that we want to change what's hashed we can change the function. >> I guess you should add a function comment, plus spaces before ( everywhere >> (and while you're at it, you can change also the is_cxx() ). Will leave the >> rest to Cary. > > Agree with the function comment and the spaces. Oh yeah, thanks. Sorry, it's been a while. > >> 2013-07-22 Eric Christopher >> >> * dwarf2out.c (die_odr_checksum): New function to use >> CHECKSUM_ macros and ULEB128 for DIE tag. >> (generate_type_signature): Use. > > This is OK with those changes. Thanks! > Committed thusly: ghostwheel:~/sources/gcc> svn ci Sendinggcc/ChangeLog Sendinggcc/dwarf2out.c Transmitting file data .. Committed revision 201148. Thanks! -eric
[Patch, PR 57782] Wasted work in remove_path()
Hi,
The problem appears in revision 200945 in version 4.9. I attached
a one-line patch that fixes it. I also reported this problem at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57782
In method "remove_path()" in cfgloopmanip.c, the loop on line 343
should break immediately after "irred_invalidated" is set to "true".
2013-07-22 Chang
* cfgloopmanip.c (remove_path): Exit loop after
setting irred_invalidated.
Index: gcc/cfgloopmanip.c
===
--- gcc/cfgloopmanip.c (revision 201034)
+++ gcc/cfgloopmanip.c (working copy)
@@ -343,7 +343,11 @@
FOR_EACH_EDGE (ae, ei, e->src->succs)
if (ae != e && ae->dest != EXIT_BLOCK_PTR && !bitmap_bit_p (seen,
ae->dest->index)
&& ae->flags & EDGE_IRREDUCIBLE_LOOP)
- irred_invalidated = true;
+ {
+ irred_invalidated = true;
+ break;
+ }
+
for (i = 0; i < nrem; i++)
{
bb = rem_bbs[i];
-ChangIndex: gcc/cfgloopmanip.c
===
--- gcc/cfgloopmanip.c (revision 201034)
+++ gcc/cfgloopmanip.c (working copy)
@@ -343,7 +343,11 @@
FOR_EACH_EDGE (ae, ei, e->src->succs)
if (ae != e && ae->dest != EXIT_BLOCK_PTR && !bitmap_bit_p (seen,
ae->dest->index)
&& ae->flags & EDGE_IRREDUCIBLE_LOOP)
- irred_invalidated = true;
+ {
+ irred_invalidated = true;
+ break;
+ }
+
for (i = 0; i < nrem; i++)
{
bb = rem_bbs[i];
Re: [PATCH, PowerPC] rs6000_expand_vector_init selects wrong field for splat in LE mode
On Mon, Jul 22, 2013 at 1:12 PM, Bill Schmidt wrote: > In little-endian mode, the field selected for use in a vector splat is > numbered differently than in big-endian mode. This patch corrects the > code generated for little-endian. This addresses 45 test failures when > running the test-suite in little-endian mode. > > Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new > regressions. Ok for trunk? > > Patch by Anton Blanchard. > > Thanks, > Bill > > > 2013-07-22 Bill Schmidt > for Anton Blanchard > > * config/rs6000/rs6000.c (rs6000_expand_vector_init): Fix > endianness when selecting field to splat. Okay. But please either only list Anton in the ChangeLog or list both you and Anton, but not "for Anton". Thanks, David
[PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode
This patch is another fix for vector handling in little endian mode. The first two operands for a pack pattern are two vector registers that form a contiguous array of inputs. In LE mode the order of the operands must be reversed so that the array remains contiguous in the reverse order. This fixes a failure in the testsuite when run little-endian (gcc.dg/vect/no-scevccp-outer-18.c). Bootstrapped and tested big-endian on powerpc64-unknown-linux-gnu with no new regressions. Ok for trunk? Patch by Anton Blanchard. Thanks, Bill 2013-07-22 Bill Schmidt Anton Blanchard * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse two operands for little-endian. Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 201131) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -28526,7 +28529,12 @@ altivec_expand_vec_perm_const (rtx operands[4]) x = target; else x = gen_reg_rtx (omode); - emit_insn (GEN_FCN (icode) (x, op0, op1)); + /* For little-endian, the two input operands must be swapped +to ensure proper right-to-left numbering from 0 to 2N-1. */ + if (BYTES_BIG_ENDIAN) + emit_insn (GEN_FCN (icode) (x, op0, op1)); + else + emit_insn (GEN_FCN (icode) (x, op1, op0)); if (omode != V16QImode) emit_move_insn (target, gen_lowpart (V16QImode, x)); return true;
RE: [ping] Re: [patch 0/4] reimplement -fstrict-volatile-bitfields, v3
Hello Hans-Peter, > On Sat, 13 Jul 2013, Bernd Edlinger wrote: >> Hi Sandra, >> >> On Fri, 5 Jul 2013, Hans-Peter Nilsson wrote >>> Or - maybe more acceptable - an optional warning, say >>> -Wportable-volatility, to warn about code for which separate >>> incompatbile definitions on different platforms (or between C >>> and C++) exist even within gcc. It would be usable for driver >>> code you want to be usable on different architectures, say, in >>> an OS commonly compiled with gcc, if you can think of some. :) >> >> >> I like this idea, and this warning would add some real value for everyone. >> Therefore I added that option as part 5 of this patch series, I hope you >> don't mind :) > > Definitely not. Thanks for picking up the ball! > >> I really hope that the GCC maintainers can accept this patch now, as the >> current state of -fstrict-volatile-bitfields is very painful to all of us. > > I guess I should offer a first-hand review of the warnings part. > > I've got nothing on the code, however the documentation ties the > warning only to -fstrict-volatile-bitfields, which it shouldn't; > it should be stated generic, but perhaps with > -fstrict-volatile-bitfields as an *example*. (And for those who > now feel the need to say "but volatile behavior is undefined" > without reading the rest of the thread, remember that this is > intended to cover cases where some definition actually *exist* > whether in some language standard or some target-specific ABI > document.) > > It also needs test-cases, both for some positive cases (warning > hits) and some case where it doesn't (and shouldn't). > > ...and ChangeLog entries. > > Thanks again! > > brgds, H-P thanks a lot for your Feedback, I created a change log entry, revised the documentation as you suggested, and added two new almost identical test cases: One with -fstrict-volatile-bitfields and one without. This warning should only be emitted if the code is significantly different when -fstrict-volatile-bitfields is used or not. It should not be emitted for the code which is not affected by this option. In other words, it should be emitted on all bit-fields when the definition or the context is volatile, except when the whole structure is not AAPCS ABI compliant, i.e. packed or unaligned. On the other hand you should always get the same warnings if you combine -Wportable-volatility with -fstrict-volatile-bitfields or not. And of course it should not depend on the specific target that is used to compile. However when I tried to write simple test cases, I realized that my initial code was emitting almost no warnings when -fno-strict-volatile-bitfields is used. I analyzed that and came to the conclusion, that the function strict_volatile_bitfield_p() is not the best place to emit this warning, even if is is always executed with -fstrict-volatile-bitfields. But with -fno-strict-volatile-bitfields the program flow in store_expr() may divert to emit_move_insn(), especially in trivial cases. Well, I decided that the best place to emit that warning would be the function expand_assignment() and expand_expr_real_1(), because here we have a rtx and the tree object plus the bitsize and bitnum all together. However the first time when the flag_strict_volatile_bitfields is used, is in stor_layout.c: Here a bit-field int a:8 is replaced by char a if that is possible. Therefore I decided that this optimization is in the way of -Wportable-volatility, and has to be disabled for the same reasons as with -fstrict-volatle-bitfields. The next problem was in fold-const.c: optimize_bit_field_compare() can replace the COMPONENT_REF with a BIT_FIELD_REF, even for volatile objects. But that conversion looses too much information to recover the bit-field's DECL_BIT_FIELD_TYPE. Therefore this warning has to be skipped at least for volatile lhs or rhs arguments if -Wportable-volatility is used. I boot-strapped this on a i686-pc-linux-gnu and all Wportable-volatility test cases are passed for C and C++. I used a cross-compiler for arm-eabi to manually cross-check that the warnings are independent of the target platform. Sandra's test case pr23623 does emit exactly 4 warnings if compiled with -Wportable-volatilty, which is correct. All other test cases from part 3 use unaligned or packed structures which are not AAPCS compliant at all. Therefore they do not emit any warnings, which is also correct, because they emit exactly the same code, regardless of the -fstrict-volatile-bitfield setting. This may however deserve a warning on it's own. H-P: I hope you can approve my little patch for trunk now, although it turned out to be less trivial than I'd have expected. Of course it is dependent on Sandra's patch part 1 and part 2, which must be applied first. As far as I can see, the part 2 is still missing a formal approval of one of the global reviewers. Could some one please do that now? Sandra, regarding Part 3, I have a small recommendation on it: The test programs pr56997-
Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode
On Mon, Jul 22, 2013 at 7:05 PM, Bill Schmidt wrote: > This patch is another fix for vector handling in little endian mode. > The first two operands for a pack pattern are two vector registers that > form a contiguous array of inputs. In LE mode the order of the operands > must be reversed so that the array remains contiguous in the reverse > order. > > This fixes a failure in the testsuite when run little-endian > (gcc.dg/vect/no-scevccp-outer-18.c). Bootstrapped and tested big-endian > on powerpc64-unknown-linux-gnu with no new regressions. Ok for trunk? > > Patch by Anton Blanchard. > > Thanks, > Bill > > > 2013-07-22 Bill Schmidt > Anton Blanchard > > * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse > two operands for little-endian. Wouldn't it be better to handle this where the code is performing a swap a few lines above? Thanks, David
Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode
On Mon, 2013-07-22 at 19:49 -0400, David Edelsohn wrote: > On Mon, Jul 22, 2013 at 7:05 PM, Bill Schmidt > wrote: > > This patch is another fix for vector handling in little endian mode. > > The first two operands for a pack pattern are two vector registers that > > form a contiguous array of inputs. In LE mode the order of the operands > > must be reversed so that the array remains contiguous in the reverse > > order. > > > > This fixes a failure in the testsuite when run little-endian > > (gcc.dg/vect/no-scevccp-outer-18.c). Bootstrapped and tested big-endian > > on powerpc64-unknown-linux-gnu with no new regressions. Ok for trunk? > > > > Patch by Anton Blanchard. > > > > Thanks, > > Bill > > > > > > 2013-07-22 Bill Schmidt > > Anton Blanchard > > > > * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse > > two operands for little-endian. > > Wouldn't it be better to handle this where the code is performing a > swap a few lines above? Hm, I don't think so. The reason for that swap has nothing to do with endianness, so I think it would just confuse matters. Also there's a three-way swap going on with x, op0, and op1 there, and we just want to swap op0 and op1. I think the patch as it stands is probably easier to grok. Thanks, Bill > > Thanks, David >
Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode
On Mon, 2013-07-22 at 19:56 -0500, Bill Schmidt wrote: > > On Mon, 2013-07-22 at 19:49 -0400, David Edelsohn wrote: > > On Mon, Jul 22, 2013 at 7:05 PM, Bill Schmidt > > wrote: > > > This patch is another fix for vector handling in little endian mode. > > > The first two operands for a pack pattern are two vector registers that > > > form a contiguous array of inputs. In LE mode the order of the operands > > > must be reversed so that the array remains contiguous in the reverse > > > order. > > > > > > This fixes a failure in the testsuite when run little-endian > > > (gcc.dg/vect/no-scevccp-outer-18.c). Bootstrapped and tested big-endian > > > on powerpc64-unknown-linux-gnu with no new regressions. Ok for trunk? > > > > > > Patch by Anton Blanchard. > > > > > > Thanks, > > > Bill > > > > > > > > > 2013-07-22 Bill Schmidt > > > Anton Blanchard > > > > > > * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse > > > two operands for little-endian. > > > > Wouldn't it be better to handle this where the code is performing a > > swap a few lines above? > > Hm, I don't think so. The reason for that swap has nothing to do with > endianness, so I think it would just confuse matters. Also there's a > three-way swap going on with x, op0, and op1 there, and we just want to > swap op0 and op1. I think the patch as it stands is probably easier to > grok. Bleah, sorry, wasn't paying enough attention. Didn't notice x was being reused as an intermediate there instead of its regular use. It still seems a bit confusing to mix the two reasons for swapping, but I'll look at it. Thanks, Bill > > Thanks, > Bill > > > > Thanks, David > >
Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode
On Mon, 2013-07-22 at 19:49 -0400, David Edelsohn wrote: > On Mon, Jul 22, 2013 at 7:05 PM, Bill Schmidt > wrote: > > This patch is another fix for vector handling in little endian mode. > > The first two operands for a pack pattern are two vector registers that > > form a contiguous array of inputs. In LE mode the order of the operands > > must be reversed so that the array remains contiguous in the reverse > > order. > > > > This fixes a failure in the testsuite when run little-endian > > (gcc.dg/vect/no-scevccp-outer-18.c). Bootstrapped and tested big-endian > > on powerpc64-unknown-linux-gnu with no new regressions. Ok for trunk? > > > > Patch by Anton Blanchard. > > > > Thanks, > > Bill > > > > > > 2013-07-22 Bill Schmidt > > Anton Blanchard > > > > * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse > > two operands for little-endian. > > Wouldn't it be better to handle this where the code is performing a > swap a few lines above? OK, currently testing the following. OK if it passes? Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 201149) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -28518,6 +28518,11 @@ altivec_expand_vec_perm_const (rtx operands[4]) enum machine_mode omode = insn_data[icode].operand[0].mode; enum machine_mode imode = insn_data[icode].operand[1].mode; + /* For little-endian, the two input operands must be swapped +(or swapped back) to ensure proper right-to-left numbering +from 0 to 2N-1. */ + if (!BYTES_BIG_ENDIAN) +swapped = !swapped; if (swapped) x = op0, op0 = op1, op1 = x; if (imode != V16QImode) Thanks, Bill > > Thanks, David >
[Patch, PR 57780] Waste work in subst_dup()
Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57780 Bootstrap and regression-tested on x86_64-linux. In method "subst_dup()" in gensupport.c, the loop on line 2181 should not be executed when "code" equals to "MATCH_DUP" or "MATCH_OP_DUP". 2013-07-22 Chang * gensupport.c (subst_dup): Avoid loop if code is not MATCH_DUP nor MATCH_OP_DUP. Index: gcc/gensupport.c === --- gcc/gensupport.c(revision 201034) +++ gcc/gensupport.c(working copy) @@ -2178,8 +2178,8 @@ if (XVEC (pattern, i) == NULL) break; case 'E': - for (j = XVECLEN (pattern, i) - 1; j >= 0; --j) - if (code != MATCH_DUP && code != MATCH_OP_DUP) + if (code != MATCH_DUP && code != MATCH_OP_DUP) + for (j = XVECLEN (pattern, i) - 1; j >= 0; --j) XVECEXP (pattern, i, j) = subst_dup (XVECEXP (pattern, i, j), n_alt, n_subst_alt); break; -ChangIndex: gcc/gensupport.c === --- gcc/gensupport.c(revision 201034) +++ gcc/gensupport.c(working copy) @@ -2178,8 +2178,8 @@ if (XVEC (pattern, i) == NULL) break; case 'E': - for (j = XVECLEN (pattern, i) - 1; j >= 0; --j) - if (code != MATCH_DUP && code != MATCH_OP_DUP) + if (code != MATCH_DUP && code != MATCH_OP_DUP) + for (j = XVECLEN (pattern, i) - 1; j >= 0; --j) XVECEXP (pattern, i, j) = subst_dup (XVECEXP (pattern, i, j), n_alt, n_subst_alt); break;
Re: RFA: implement C11 _Generic
I have now revised this patch from a year ago in line with my
understanding of how _Generic ought to handle the various special
cases (selector undergoes lvalue-to-rvalue conversion, and decay of
functions and arrays to pointers, because nothing says it doesn't -
"The controlling expression of a generic selection was very carefully
not added to the list of contexts in which lvalue conversion is not
done and type qualification is discarded", the minutes say - and no
rvalues can have qualified type), which seems to accord with the
committee discussion in the Delft minutes, added corresponding
testcases, and committed this patch. Bootstrapped with no regressions
on x86_64-unknown-linux-gnu.
The committee discussion includes a further point to ensure rvalues
can have qualified type: treating qualified function return types the
same as unqualified, like the way qualified function parameter types
are treated. If that gets adopted, some further changes will be
needed elsewhere (but all those will do is cause some code to be
accepted that's currently rejected).
c-family:
2013-07-23 Tom Tromey
* c-common.h (enum rid) : New constant.
* c-common.c (c_common_reswords): Add _Generic.
c:
2013-07-23 Tom Tromey
Joseph Myers
* c-parser.c (struct c_generic_association): New.
(c_generic_association_d): New typedef.
(c_parser_generic_selection): New function.
(c_parser_postfix_expression): Handle RID_GENERIC.
testsuite:
2013-07-23 Tom Tromey
Joseph Myers
* gcc.dg/c11-generic-1.c: New file.
* gcc.dg/c11-generic-2.c: New file.
Index: c/c-parser.c
===
--- c/c-parser.c(revision 201131)
+++ c/c-parser.c(working copy)
@@ -6232,7 +6232,226 @@ c_parser_get_builtin_args (c_parser *parser, const
return true;
}
+/* This represents a single generic-association. */
+struct c_generic_association
+{
+ /* The location of the starting token of the type. */
+ location_t type_location;
+ /* The association's type, or NULL_TREE for 'default'.. */
+ tree type;
+ /* The association's expression. */
+ struct c_expr expression;
+};
+
+/* Parse a generic-selection. (C11 6.5.1.1).
+
+ generic-selection:
+ _Generic ( assignment-expression , generic-assoc-list )
+
+ generic-assoc-list:
+ generic-association
+ generic-assoc-list , generic-association
+
+ generic-association:
+ type-name : assignment-expression
+ default : assignment-expression
+*/
+
+static struct c_expr
+c_parser_generic_selection (c_parser *parser)
+{
+ vec associations = vNULL;
+ struct c_expr selector, error_expr;
+ tree selector_type;
+ struct c_generic_association matched_assoc;
+ bool match_found = false;
+ location_t generic_loc, selector_loc;
+
+ error_expr.original_code = ERROR_MARK;
+ error_expr.original_type = NULL;
+ error_expr.value = error_mark_node;
+ matched_assoc.type_location = UNKNOWN_LOCATION;
+ matched_assoc.type = NULL_TREE;
+ matched_assoc.expression = error_expr;
+
+ gcc_assert (c_parser_next_token_is_keyword (parser, RID_GENERIC));
+ generic_loc = c_parser_peek_token (parser)->location;
+ c_parser_consume_token (parser);
+ if (!flag_isoc11)
+{
+ if (flag_isoc99)
+ pedwarn (generic_loc, OPT_Wpedantic,
+"ISO C99 does not support %<_Generic%>");
+ else
+ pedwarn (generic_loc, OPT_Wpedantic,
+"ISO C90 does not support %<_Generic%>");
+}
+
+ if (!c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
+return error_expr;
+
+ c_inhibit_evaluation_warnings++;
+ selector_loc = c_parser_peek_token (parser)->location;
+ selector = c_parser_expr_no_commas (parser, NULL);
+ selector = default_function_array_conversion (selector_loc, selector);
+ c_inhibit_evaluation_warnings--;
+
+ if (selector.value == error_mark_node)
+{
+ c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, NULL);
+ return selector;
+}
+ selector_type = TREE_TYPE (selector.value);
+ /* In ISO C terms, rvalues (including the controlling expression of
+ _Generic) do not have qualified types. */
+ if (TREE_CODE (selector_type) != ARRAY_TYPE)
+selector_type = TYPE_MAIN_VARIANT (selector_type);
+ /* In ISO C terms, _Noreturn is not part of the type of expressions
+ such as &abort, but in GCC it is represented internally as a type
+ qualifier. */
+ if (FUNCTION_POINTER_TYPE_P (selector_type)
+ && TYPE_QUALS (TREE_TYPE (selector_type)) != TYPE_UNQUALIFIED)
+selector_type
+ = build_pointer_type (TYPE_MAIN_VARIANT (TREE_TYPE (selector_type)));
+
+ if (!c_parser_require (parser, CPP_COMMA, "expected %<,%>"))
+{
+ c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, NULL);
+ return error_expr;
+}
+
+ while (1)
+{
+ struct c_generic_association assoc, *iter;
+ unsigned int ix;
+ c_token *tok
Re: RFA: implement C11 _Generic
On Tue, 23 Jul 2013, Joseph S. Myers wrote: > The committee discussion includes a further point to ensure rvalues > can have qualified type: treating qualified function return types the (to ensure they *can't* have qualified type, that is) -- Joseph S. Myers jos...@codesourcery.com
libgo patch committed: Ignore SIGPROF on non-Go thread
This patch to libgo ignores a SIGPROF signal if it is received on a
non-Go thread. This permits the Go library profiling support to work in
a program that calls C/C++ code that starts threads. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and
4.8 branch.
Ian
diff -r f1650653ba7d libgo/runtime/go-signal.c
--- a/libgo/runtime/go-signal.c Tue Jul 16 15:42:30 2013 -0700
+++ b/libgo/runtime/go-signal.c Mon Jul 22 21:39:43 2013 -0700
@@ -166,21 +166,22 @@
int i;
m = runtime_m ();
+
+#ifdef SIGPROF
+ if (sig == SIGPROF)
+{
+ if (m != NULL && gp != m->g0 && gp != m->gsignal)
+ runtime_sigprof ();
+ return;
+}
+#endif
+
if (m == NULL)
{
runtime_badsignal (sig);
return;
}
-#ifdef SIGPROF
- if (sig == SIGPROF)
-{
- if (gp != runtime_m ()->g0 && gp != runtime_m ()->gsignal)
- runtime_sigprof ();
- return;
-}
-#endif
-
for (i = 0; runtime_sigtab[i].sig != -1; ++i)
{
SigTab *t;
Re: [Patch, PR 57812] Wasted work in computed_jump_p()
2013/7/23 : > > 2013-07-22 Chang > > * rtlanal.c (computed_jump_p): Exit loop once we find label > reference is used. > The second line is supposed to be aligned with '*' character at first line. Like this: * rtlanal.c (computed_jump_p): Exit loop once we find label reference is used. Best regards, jasonwucj
Add more info to google/gcc-4_8 powerpc64 xfails file.
Diego - The attached patch adds a little more analysis info to the powerpc64 xfails file. Ok to commit? Thanks, - Brooks 2013-07-22_xfail-more-info.diff Description: Binary data
Re: [Patch, microblaze]: Add -fstack-usage support
Hi Eric / Chung-Ju, On 21 July 2013 01:33, Chung-Ju Wu wrote: > On 7/20/13 4:14 PM, Eric Botcazou wrote: 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c (microblaze_expand_prologue): Add check for flag_stack_usage to handle -fstack-usage support Signed-off-by: David Holsgrove >>> >>> >>> Patch remains the same, please apply when ready. >> >> >> The patch is incorrect, please adjust it to match the other architectures. >> > > Hi, David, > > Specifically speaking, what Eric meant is to check > flag_stack_usage_info rather than flag_stack_usage > due to the changes after gcc-4.7. > Ah, thanks for the catch - patch had been sitting in my tree for quite a while, hadn't realised the variable name had changed on trunk. Patch attached which adjusts microblaze's usage to align with other archs. thanks, David > > Best regards, > jasonwucj > 0001-Patch-microblaze-Update-flag_stack_usage-variable-na.patch Description: Binary data
