RE: [PATCH, ARM] Backport fix for PR59593 (minipool of small values on big endian targets)
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Tuesday, January 20, 2015 1:06 PM
> To: gcc-patches@gcc.gnu.org; Richard Earnshaw; Ramana Radhakrishnan;
> Marcus Shawcroft
> Subject: [PATCH, ARM] Backport fix for PR59593 (minipool of small values
> on big endian targets)
>
> Currently on GCC 4.8 and 4.9, constant pool entries for QImode, HImode
> and SImode values are filled as 32-bit quantities. This works fine for little
> endian system but gives some incorrect results for big endian system
> when the value is accessed with a mode smaller than 32-bit in size.
> Suppose the case of the value 0x1234 that is accessed as an HImode
> value. It would be output as 0x0 0x0 0x12 0x34 in a constant pool entry
> and the 16-bit load that would be done would lead to the value 0x0 in
> register.
>
> This patch makes the consttable_1 and consttable_2 pattern available to
> ARM as well so that values are output according to their mode.
>
> This is a backport of commit r218118.
>
> *** gcc/ChangeLog ***
>
> 2015-01-14 Thomas Preud'homme
>
> Backport from mainline
> 2014-11-27 Thomas Preud'homme
>
> PR target/59593
> * config/arm/arm.c (dump_minipool): dispatch to consttable pattern
> based on mode size.
> * config/arm/arm.md (consttable_1): Make it TARGET_EITHER.
> (consttable_2): Make it TARGET_EITHER and move HFmode handling
> from
> consttable_4 to it.
> (consttable_4): Move HFmode handling to consttable_2 pattern.
>
>
> *** gcc/testsuite/ChangeLog ***
>
> 2015-01-14 Thomas Preud'homme
>
> Backport from mainline
> 2014-11-27 Thomas Preud'homme
>
> PR target/59593
> * gcc.target/arm/constant-pool.c: New test.
>
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 85372e5..eeaece8 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,16 @@
> +2015-01-14 Thomas Preud'homme
> +
> + Backport from mainline
> + 2014-11-27 Thomas Preud'homme
>
> +
> + PR target/59593
> + * config/arm/arm.c (dump_minipool): dispatch to consttable
> pattern
> + based on mode size.
> + * config/arm/arm.md (consttable_1): Make it TARGET_EITHER.
> + (consttable_2): Make it TARGET_EITHER and move HFmode
> handling from
> + consttable_4 to it.
> + (consttable_4): Move HFmode handling to consttable_2 pattern.
> +
> 2015-01-14 Marek Polacek
>
> Backport from mainline
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 5e2571c..67ef80b 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -16274,7 +16274,7 @@ dump_minipool (rtx scan)
> fputc ('\n', dump_file);
> }
>
> - switch (mp->fix_size)
> + switch (GET_MODE_SIZE (mp->mode))
> {
> #ifdef HAVE_consttable_1
> case 1:
> diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
> index 8119387..93b25e9 100644
> --- a/gcc/config/arm/arm.md
> +++ b/gcc/config/arm/arm.md
> @@ -12224,7 +12224,7 @@
>
> (define_insn "consttable_1"
>[(unspec_volatile [(match_operand 0 "" "")] VUNSPEC_POOL_1)]
> - "TARGET_THUMB1"
> + "TARGET_EITHER"
>"*
>making_const_table = TRUE;
>assemble_integer (operands[0], 1, BITS_PER_WORD, 1);
> @@ -12237,14 +12237,23 @@
>
> (define_insn "consttable_2"
>[(unspec_volatile [(match_operand 0 "" "")] VUNSPEC_POOL_2)]
> - "TARGET_THUMB1"
> + "TARGET_EITHER"
>"*
> - making_const_table = TRUE;
> - gcc_assert (GET_MODE_CLASS (GET_MODE (operands[0])) !=
> MODE_FLOAT);
> - assemble_integer (operands[0], 2, BITS_PER_WORD, 1);
> - assemble_zeros (2);
> - return \"\";
> - "
> + {
> +rtx x = operands[0];
> +making_const_table = TRUE;
> +switch (GET_MODE_CLASS (GET_MODE (x)))
> + {
> + case MODE_FLOAT:
> + arm_emit_fp16_const (x);
> + break;
> + default:
> + assemble_integer (operands[0], 2, BITS_PER_WORD, 1);
> + assemble_zeros (2);
> + break;
> + }
> +return \"\";
> + }"
>[(set_attr "length" "4")
> (set_attr "type" "no_insn")]
> )
> @@ -12259,15 +12268,12 @@
> switch (GET_MODE_CLASS (GET_MODE (x)))
>{
>case MODE_FLOAT:
> - if (GET_MODE (x) == HFmode)
> - arm_emit_fp16_const (x);
> - else
> - {
> - REAL_VALUE_TYPE r;
> - REAL_VALUE_FROM_CONST_DOUBLE (r, x);
> - assemble_real (r, GET_MODE (x), BITS_PER_WORD);
> - }
> - break;
> + {
> + REAL_VALUE_TYPE r;
> + REAL_VALUE_FROM_CONST_DOUBLE (r, x);
> + assemble_real (r, GET_MODE (x), BITS_PER_WORD);
> + break;
> + }
>default:
> /* XXX: Sometimes gcc does something really dumb and ends up
> with
> a HIGH in a constant pool entry, usually because it's trying to
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 222716d..49d1a73 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc
Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.
On 09/02/15 23:17, Hans-Peter Nilsson wrote:
On Mon, 9 Feb 2015, Matthew Wahab wrote:
Attached a patch to replace the test for macro __NEWLIB__ with a test for
macro NEWLINE_IN_CLASS_BLANK, defined by
{ dg-additional-options "-DNEWLINE_IN_CLASS_BLANK" { target newlib } }
Tested with check-target-libstdc++-v3, with the modified tests, for
arm-none-eabi and aarch64-none-linux-gnu.
Does this look ok to commit?
Not valid for approval, but that's what I meant!
Modulo the typo forgetting to
s/__NEWLIB__/NEWLINE_IN_CLASS_BLANK/ in the ifdef in
wchar_t/isctype.cc of course.
I'll redo the patch.
Matthew
libstdc++-v3/testsuite/
2015-02-09 Matthew Wahab
* 28_regex/traits/char/isctype.cc (test01): Replace test
for __NEWLIB__ macro with a dejagnu set macro.
* 28_regex/traits/wchar_t/isctype.cc (test01): Likewise.
Re: [PATCH][AArch64] Fix illegal assembly 'eon v1, v2, v3'
On Wed, Jan 28, 2015 at 02:04:04PM +, James Greenhalgh wrote: > On Wed, Jan 28, 2015 at 12:32:45PM +, Alan Lawrence wrote: > > Ok for stage 4? > > This is a regression from 4.9, so once we iron out some nits, it should > be. > > > gcc/ChangeLog: > > > > * config/aarch64/aarch64.md (*xor_one_cmpl3): Use FP_REGNUM_P > > as split condition. > > And a testcase, please! > > > diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md > > index > > bc49fbe68a978b3ca069c6d084f542773df84bcb..d4b3f7b03ba0ab570cec5ce862e8c5f38f417ed1 > > 100644 > > --- a/gcc/config/aarch64/aarch64.md > > +++ b/gcc/config/aarch64/aarch64.md > > @@ -3054,7 +3054,7 @@ > >(match_operand:GPI 2 "register_operand" > > "r,w"] > >"" > >"eon\\t%0, %1, %2" ;; For GPR registers (only). > > This should be: > "@ > eon\\t%0, %1, %2 > #" > > which would have forced a split. > > Your patch is useful regardless, as I guess we could have ended up > needlessly splitting if we got unlucky with whatever had been left > in which_alternative. Hi Alan, Do you have any plans to respin this patch? I'd like to see it fixed for GCC 5.0 if possible. Thanks, James
Re: [PATCH][ARM] PR target/64600 Fix another ICE with -mtune=xscale: properly sign-extend mask during constant splitting
Ping. https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00141.html Thanks, Kyrill On 03/02/15 15:18, Kyrill Tkachov wrote: Hi all, The ICE in this PR occurs when -mtune=xscale triggers a particular path through arm_gen_constant during expand that creates a 0xf00f mask but for a 64-bit HOST_WIDE_INT doesn't sign extend it into 0xf00f that signifies the required -4081. It leaves it as 0xf00f (4294963215) that breaks when later combine tries to perform an SImode bitwise AND using the wide-int machinery. I think the correct approach here is to use trunc_int_for_mode that correctly sign-extends the constant so that it is properly represented by a HOST_WIDE_INT for the required mode. Bootstrapped and tested arm-none-linux-gnueabihf with -mtune=xscale in BOOT_CFLAGS. The testcase triggers for -mcpu=xscale and all slowmul targets because they are the only ones that have the constant_limit tune parameter set to anything >1 which is required to follow this particular path through arm_split_constant. Also, the rtx costs can hide this ICE sometimes. Ok for trunk? Thanks, Kyrill 2015-02-03 Kyrylo Tkachov PR target/64600 * config/arm/arm.c (arm_gen_constant, AND case): Call trunc_int_for_mode when constructing AND mask. 2015-02-03 Kyrylo Tkachov PR target/64600 * gcc.target/arm/pr64600_1.c: New test.
[PATCH] Fix PR64909
The vectorizer cost model has a serious issue in not dealing well with
targets using scalar stmt cost != 1. This is because it passes
scalar iteration _cost_ to routines scaling that cost with the targets
scalar stmt cost again. This is for example visible on x86_64 for
all AMD archs which use high scalar stmt cost (6).
I am testing the following patch to fix that - for GCC 6 we might want
to avoid the roundoff errors that can appear.
Richard.
2015-02-10 Richard Biener
PR tree-optimization/64909
* tree-vect-loop.c (vect_estimate_min_profitable_iters): Properly
pass a scalar-stmt count estimate to the cost model.
* tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost): Likewise.
* gcc.dg/vect/costmodel/x86_64/costmodel-pr64909.c: New testcase.
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 220540)
+++ gcc/tree-vect-loop.c(working copy)
@@ -2834,6 +2834,11 @@ vect_estimate_min_profitable_iters (loop
statements. */
scalar_single_iter_cost = vect_get_single_scalar_iteration_cost (loop_vinfo);
+ /* ??? Below we use this cost as number of stmts with scalar_stmt cost,
+ thus divide by that. This introduces rounding errors, thus better
+ introduce a new cost kind (raw_cost? scalar_iter_cost?). */
+ int scalar_single_iter_stmts
+= scalar_single_iter_cost / vect_get_stmt_cost (scalar_stmt);
/* Add additional cost for the peeled instructions in prologue and epilogue
loop.
@@ -2868,10 +2873,10 @@ vect_estimate_min_profitable_iters (loop
/* FORNOW: Don't attempt to pass individual scalar instructions to
the model; just assume linear cost for scalar iterations. */
(void) add_stmt_cost (target_cost_data,
- peel_iters_prologue * scalar_single_iter_cost,
+ peel_iters_prologue * scalar_single_iter_stmts,
scalar_stmt, NULL, 0, vect_prologue);
(void) add_stmt_cost (target_cost_data,
- peel_iters_epilogue * scalar_single_iter_cost,
+ peel_iters_epilogue * scalar_single_iter_stmts,
scalar_stmt, NULL, 0, vect_epilogue);
}
else
@@ -2887,7 +2892,7 @@ vect_estimate_min_profitable_iters (loop
(void) vect_get_known_peeling_cost (loop_vinfo, peel_iters_prologue,
&peel_iters_epilogue,
- scalar_single_iter_cost,
+ scalar_single_iter_stmts,
&prologue_cost_vec,
&epilogue_cost_vec);
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 220540)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -1184,10 +1206,13 @@ vect_peeling_hash_get_lowest_cost (_vect
}
single_iter_cost = vect_get_single_scalar_iteration_cost (loop_vinfo);
- outside_cost += vect_get_known_peeling_cost (loop_vinfo, elem->npeel,
- &dummy, single_iter_cost,
- &prologue_cost_vec,
- &epilogue_cost_vec);
+ outside_cost += vect_get_known_peeling_cost
+(loop_vinfo, elem->npeel, &dummy,
+ /* ??? We use this cost as number of stmts with scalar_stmt cost,
+ thus divide by that. This introduces rounding errors, thus better
+ introduce a new cost kind (raw_cost? scalar_iter_cost?). */
+ single_iter_cost / vect_get_stmt_cost (scalar_stmt),
+ &prologue_cost_vec, &epilogue_cost_vec);
/* Prologue and epilogue costs are added to the target model later.
These costs depend only on the scalar iteration cost, the
Index: gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr64909.c
===
--- gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr64909.c
(revision 0)
+++ gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr64909.c
(working copy)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-mtune=bdver1" } */
+
+unsigned short a[32];
+unsigned int b[32];
+void t()
+{
+ int i;
+ for (i=0;i<12;i++)
+b[i]=a[i];
+}
+
+/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" } } */
+/* { dg-final { cleanup-tree-dump "vect" } } */
[PATCH] Remove unused return value of streamer_read_tree_bitfields
LTO bootstrapped on x86_64-unknown-linux-gnu, applied.
Richard.
2015-02-10 Richard Biener
* tree-streamer.h (streamer_read_tree_bitfields): Adjust.
* tree-streamer-in.c (streamer_read_tree_bitfields): Do not
return the bitpack.
Index: gcc/tree-streamer.h
===
--- gcc/tree-streamer.h (revision 220575)
+++ gcc/tree-streamer.h (working copy)
@@ -77,8 +77,8 @@ tree streamer_alloc_tree (struct lto_inp
void streamer_read_tree_body (struct lto_input_block *, struct data_in *,
tree);
tree streamer_get_pickled_tree (struct lto_input_block *, struct data_in *);
tree streamer_get_builtin_tree (struct lto_input_block *, struct data_in *);
-struct bitpack_d streamer_read_tree_bitfields (struct lto_input_block *,
- struct data_in *, tree);
+void streamer_read_tree_bitfields (struct lto_input_block *,
+ struct data_in *, tree);
/* In tree-streamer-out.c. */
void streamer_write_string_cst (struct output_block *,
Index: gcc/tree-streamer-in.c
===
--- gcc/tree-streamer-in.c (revision 220575)
+++ gcc/tree-streamer-in.c (working copy)
@@ -466,7 +466,7 @@ unpack_ts_omp_clause_value_fields (struc
Return the partially unpacked bitpack so the caller can unpack any other
bitfield values that the writer may have written. */
-struct bitpack_d
+void
streamer_read_tree_bitfields (struct lto_input_block *ib,
struct data_in *data_in, tree expr)
{
@@ -557,8 +557,6 @@ streamer_read_tree_bitfields (struct lto
if (code == OMP_CLAUSE)
unpack_ts_omp_clause_value_fields (data_in, &bp, expr);
-
- return bp;
}
Re: [SH] Allow reg+disp address modes for atomics
Oleg Endo wrote:
> The attached patch fixes the lost mem aliasing info for atomic ops on SH
> and allows the utilization of reg+disp address modes for atomic ops.
> Actually it was supposed to be a pretty straight forward patch that just
> replaces the open coded 'mem:QIHISI (match_operand:SI
> "arith_reg_operand")' operands with something like 'match_operand:QIHISI
> "atomic_mem_operand". For most of the patterns that's what it does and
> the changes are quite mechanical. However, the QIHImode LLCS patterns
> modify the address register of the mem operand and thus required some
> special care (additional insns / splits).
>
> I've briefly tested it with
> make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m2e/-ml,-m2e/-mb,-m3/-ml,-m3/-mb,-m3e/-ml,-m3e/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> to verify that the patterns work in isolation. However, one thing I'm
> not sure about is the fact that the predicate 'atomic_mem_operand_*' and
> the Sra,Sdd,Ara,Add mem constraints are not in sync, i.e. the
> constraints allow certain things which the predicates do not allow and
> vice versa.
>
> Kaz, could you please try the patch on sh4-linux?
No new failures on sh4-unknown-linux-gnu.
Regards,
kaz
Re: [PATCH PR64705]Don't aggressively expand induction variable's base
On Mon, Feb 9, 2015 at 11:33 AM, Bin Cheng wrote: > The second time I missed patch in one day, I hate myself. > Here it is. I think the patch is reasonable but I would have used a default = NULL arg for 'stop' to make the patch smaller. You don't constrain 'stop' to being an SSA name - any particular reason for that? It would make the comparison in expand_simple_operations simpler and it could be extended to be a bitmap of SSA name versions. So - I'd like you to constrain 'stop' and check it like if (TREE_CODE (expr) != SSA_NAME || expr == stop) return expr; and declare -extern tree expand_simple_operations (tree); +extern tree expand_simple_operations (tree, tree = NULL_TREE); Ok with that change. Thanks, Richard. >> -Original Message- >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- >> ow...@gcc.gnu.org] On Behalf Of Bin Cheng >> Sent: Monday, February 09, 2015 6:10 PM >> To: gcc-patches@gcc.gnu.org >> Subject: [PATCH PR64705]Don't aggressively expand induction variable's > base >> >> Hi, >> As comments in the PR, root cause is GCC aggressively expand induction >> variable's base. This patch avoids that by adding new parameter to >> expand_simple_operations thus we can stop expansion whenever ssa var >> referred by IV's step is encountered. As comments in patch, we could stop >> expanding at each ssa var referred by IV's step, but that's expensive and > not >> likely to happen, this patch only extracts the first ssa var and skips > expanding >> accordingly. >> For the new test case, currently the loop body is bloated as below after >> IVOPT: >> >> : >> # ci_28 = PHI >> # ivtmp.13_31 = PHI >> ci_17 = ci_28 + 1; >> _1 = (void *) ivtmp.13_31; >> MEM[base: _1, offset: 0B] = 0; >> ivtmp.13_27 = ivtmp.13_31 + _26; >> _34 = (unsigned long) _13; >> _35 = (unsigned long) flags_8(D); >> _36 = _34 - _35; >> _37 = (unsigned long) step_14; >> _38 = _36 - _37; >> _39 = ivtmp.13_27 + _38; >> _40 = _39 + 3; >> iter_33 = (long int) _40; >> if (len_16(D) >= iter_33) >> goto ; >> else >> goto ; >> >> : >> goto ; >> >> And it can be improved by this patch as below: >> >> : >> # steps_28 = PHI >> # iter_29 = PHI >> steps_17 = steps_28 + 1; >> _31 = (sizetype) iter_29; >> MEM[base: flags_8(D), index: _31, offset: 0B] = 0; >> iter_21 = step_14 + iter_29; >> if (len_16(D) >= iter_21) >> goto ; >> else >> goto ; >> >> : >> goto ; >> >> >> I think this is a corner case, it only changes several files' assembly > code >> slightly in spec2k6. Among these files, only one of them is regression. > I >> looked into the regression and thought it was because of passes after > IVOPT. >> The IVOPT dump is at least not worse than the original version. >> >> Bootstrap and test on x86_64 and AArch64, so is it OK? >> >> 2015-02-09 Bin Cheng >> >> PR tree-optimization/64705 >> * tree-ssa-loop-niter.h (expand_simple_operations): New >> parameter. >> * tree-ssa-loop-niter.c (expand_simple_operations): New parameter. >> (tree_simplify_using_condition_1, refine_bounds_using_guard) >> (number_of_iterations_exit): Pass new argument to >> expand_simple_operations. >> * tree-ssa-loop-ivopts.c (extract_single_var_from_expr): New. >> (find_bivs, find_givs_in_stmt_scev): Pass new argument to >> expand_simple_operations. Call extract_single_var_from_expr. >> (difference_cannot_overflow_p): Pass new argument to >> expand_simple_operations. >> >> gcc/testsuite/ChangeLog >> 2015-02-09 Bin Cheng >> >> PR tree-optimization/64705 >> * gcc.dg/tree-ssa/pr64705.c: New test. >> >> >> >>
Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions
Hi, On Mon, Jan 12, 2015 at 12:22:44AM +0300, Ilya Verbin wrote: > Hi! > > Currently if a target* pragma appears within a target region, GCC successfully > compiles such code (with a warning). But the binary fails at run-time, since > it > tries to call GOMP_target* functions on target. > > The spec says: "If a target, target update, or target data construct appears > within a target region then the behavior is unspecified." > > I see 2 options to make the behavior more user-friendly: > 1. To return an error at compile-time. > 2. To check at run-time in libgomp whether GOMP_target* is called on target, > and > perform target-fallback if so. > What actually happens when an accelerator calls a libgomp function? Is a target libgomp port invoked? If so, it should easily know it runs on a target even without a run-time check, I suppose. Or do you somehow bring that call back to the host? Thanks, Martin
Re: RFA: RL78: Fix gcc testsuite failures
Hi Jan-Benedict, Seems you accidentally committed quite some more code you're currently working on in that very commit, which is now breaking Doh! Yes, sorry about that. I have now reverted the DIV attribute part of the patch. (I am hoping that this work will be ready for contributing soon, but it is not quite there yet). Cheers Nick
Re: [PATCH PR64705]Don't aggressively expand induction variable's base
On Tue, Feb 10, 2015 at 6:02 PM, Richard Biener wrote: > On Mon, Feb 9, 2015 at 11:33 AM, Bin Cheng wrote: >> The second time I missed patch in one day, I hate myself. >> Here it is. > > I think the patch is reasonable but I would have used a default = NULL > arg for 'stop' to make the patch smaller. You don't constrain 'stop' > to being an SSA name - any particular reason for that? It would The check is from the first version patch, in which I just passed the whole IV's step to expand_simple_operations. Yes, it should be changed accordingly. > make the comparison in expand_simple_operations simpler > and it could be extended to be a bitmap of SSA name versions. Yes, that's exactly what I want to do. BTW, per for previous comment, I don't think GCC expands IV's step in either IVOPT or SCEV, right? As a result, it's unlikely to have an IV's step referring to multiple ssa names. And that's why I didn't extend it to a ssa name versions bitmap. > > So - I'd like you to constrain 'stop' and check it like > > if (TREE_CODE (expr) != SSA_NAME Hmm, won't this effectively disable the expansion? > || expr == stop) > return expr; > > and declare > > -extern tree expand_simple_operations (tree); > +extern tree expand_simple_operations (tree, tree = NULL_TREE); I am still living in the C world... > > Ok with that change. > > Thanks, > Richard. > >>> -Original Message- >>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- >>> ow...@gcc.gnu.org] On Behalf Of Bin Cheng >>> Sent: Monday, February 09, 2015 6:10 PM >>> To: gcc-patches@gcc.gnu.org >>> Subject: [PATCH PR64705]Don't aggressively expand induction variable's >> base >>> >>> Hi, >>> As comments in the PR, root cause is GCC aggressively expand induction >>> variable's base. This patch avoids that by adding new parameter to >>> expand_simple_operations thus we can stop expansion whenever ssa var >>> referred by IV's step is encountered. As comments in patch, we could stop >>> expanding at each ssa var referred by IV's step, but that's expensive and >> not >>> likely to happen, this patch only extracts the first ssa var and skips >> expanding >>> accordingly. >>> For the new test case, currently the loop body is bloated as below after >>> IVOPT: >>> >>> : >>> # ci_28 = PHI >>> # ivtmp.13_31 = PHI >>> ci_17 = ci_28 + 1; >>> _1 = (void *) ivtmp.13_31; >>> MEM[base: _1, offset: 0B] = 0; >>> ivtmp.13_27 = ivtmp.13_31 + _26; >>> _34 = (unsigned long) _13; >>> _35 = (unsigned long) flags_8(D); >>> _36 = _34 - _35; >>> _37 = (unsigned long) step_14; >>> _38 = _36 - _37; >>> _39 = ivtmp.13_27 + _38; >>> _40 = _39 + 3; >>> iter_33 = (long int) _40; >>> if (len_16(D) >= iter_33) >>> goto ; >>> else >>> goto ; >>> >>> : >>> goto ; >>> >>> And it can be improved by this patch as below: >>> >>> : >>> # steps_28 = PHI >>> # iter_29 = PHI >>> steps_17 = steps_28 + 1; >>> _31 = (sizetype) iter_29; >>> MEM[base: flags_8(D), index: _31, offset: 0B] = 0; >>> iter_21 = step_14 + iter_29; >>> if (len_16(D) >= iter_21) >>> goto ; >>> else >>> goto ; >>> >>> : >>> goto ; >>> >>> >>> I think this is a corner case, it only changes several files' assembly >> code >>> slightly in spec2k6. Among these files, only one of them is regression. >> I >>> looked into the regression and thought it was because of passes after >> IVOPT. >>> The IVOPT dump is at least not worse than the original version. >>> >>> Bootstrap and test on x86_64 and AArch64, so is it OK? >>> >>> 2015-02-09 Bin Cheng >>> >>> PR tree-optimization/64705 >>> * tree-ssa-loop-niter.h (expand_simple_operations): New >>> parameter. >>> * tree-ssa-loop-niter.c (expand_simple_operations): New parameter. >>> (tree_simplify_using_condition_1, refine_bounds_using_guard) >>> (number_of_iterations_exit): Pass new argument to >>> expand_simple_operations. >>> * tree-ssa-loop-ivopts.c (extract_single_var_from_expr): New. >>> (find_bivs, find_givs_in_stmt_scev): Pass new argument to >>> expand_simple_operations. Call extract_single_var_from_expr. >>> (difference_cannot_overflow_p): Pass new argument to >>> expand_simple_operations. >>> >>> gcc/testsuite/ChangeLog >>> 2015-02-09 Bin Cheng >>> >>> PR tree-optimization/64705 >>> * gcc.dg/tree-ssa/pr64705.c: New test. >>> >>> >>> >>>
Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions
On Tue, Feb 10, 2015 at 11:16:22AM +0100, Martin Jambor wrote:
> On Mon, Jan 12, 2015 at 12:22:44AM +0300, Ilya Verbin wrote:
> > Currently if a target* pragma appears within a target region, GCC
> > successfully
> > compiles such code (with a warning). But the binary fails at run-time,
> > since it
> > tries to call GOMP_target* functions on target.
> >
> > The spec says: "If a target, target update, or target data construct appears
> > within a target region then the behavior is unspecified."
> >
> > I see 2 options to make the behavior more user-friendly:
> > 1. To return an error at compile-time.
> > 2. To check at run-time in libgomp whether GOMP_target* is called on
> > target, and
> > perform target-fallback if so.
> >
>
> What actually happens when an accelerator calls a libgomp function?
> Is a target libgomp port invoked? If so, it should easily know it
> runs on a target even without a run-time check, I suppose. Or do you
> somehow bring that call back to the host?
The spec says that it is undefined behavior to invoke
#pragma omp target {,data,update} from within #pragma omp target region.
For intelmic, the offloading shared libraries are normally linked against
-lgomp and thus can call any functions from there.
For nvptx, libgomp still needs to be ported to that target.
So, what we can do is e.g. ignore the nested #pragma omp target* regions
inside of #pragma omp target, or turn them into __builtin_trap ().
Jakub
Re: Another ptx offloading patch
On Wed, Feb 4, 2015 at 11:38 AM, Jakub Jelinek wrote: > On Fri, Jan 16, 2015 at 11:45:40AM +0100, Richard Biener wrote: >> On Thu, Jan 15, 2015 at 7:35 PM, Jeff Law wrote: >> > On 11/20/14 05:33, Bernd Schmidt wrote: >> >> >> >> Now that I've managed to put together and test all the submitted OpenACC >> >> patches I found there was one piece missing. The problem is that omp-low >> >> on the host likes to generate function names like "_main._omp_fn". On >> >> ptx, the dot is not allowed in identifiers, so we have to rewrite this >> >> to use a dollar sign. >> >> >> >> The patch below does this at the lto-read stage. Bootstrapped on >> >> x86_64-linux, ok if testing is successful? >> > >> > Was expecting Richi or Honza to review this... They certainly know the LTO >> > bits far better than I. Or have you ultimately addressed this issue some >> > other way? >> >> I don't like the validize_symbol_for_target thing - you create proper >> symbols elsewhere from the start - what's left to fix? IMHO we should >> have a single helper somewhere for concatenating with some separator. > > The problem is that the host compiler does not and cannot know what > characters are valid or invalid on the offloading target (and, especially if > you have multiple of them, as we do now, where some of the .$_ characters > are valid and others are not). > The only universally available character is _ I assume, but that one has the > problem that users can type that in their code and clash with the internal > symbols. And, if we do not want to use _ from the beginning, what do you > suggest otherwise? Also note that normally the same functions are emitted > for both host and offloading target, you don't have different symbol names > for host and different for what you want to stream to the offloading LTO > sections. > > So I think something like Bernd's patch is the way to go. Another > alternative is to pick up some completely different character not valid > in any identifiers, and do two transformations of the names. When streaming > offloading LTO from the host compiler, mangle the $ and . characters in > names to some other character, say %, and then when streaming the offloading > LTO into the offloading compiler, remap the % (or whatever) character to > the best internal symbol character there - ., $ or _ (in that order?). > But Bernd's patch looks simpler than that. Bernds patch is ok with the unrelated gcc.c hunk removed. Thanks, Richard. > Jakub
Re: [PATCH PR64705]Don't aggressively expand induction variable's base
On Tue, Feb 10, 2015 at 6:18 PM, Bin.Cheng wrote: > On Tue, Feb 10, 2015 at 6:02 PM, Richard Biener > wrote: >> On Mon, Feb 9, 2015 at 11:33 AM, Bin Cheng wrote: >>> The second time I missed patch in one day, I hate myself. >>> Here it is. >> >> I think the patch is reasonable but I would have used a default = NULL >> arg for 'stop' to make the patch smaller. You don't constrain 'stop' >> to being an SSA name - any particular reason for that? It would > The check is from the first version patch, in which I just passed the > whole IV's step to expand_simple_operations. Yes, it should be > changed accordingly. > >> make the comparison in expand_simple_operations simpler >> and it could be extended to be a bitmap of SSA name versions. > Yes, that's exactly what I want to do. BTW, per for previous comment, > I don't think GCC expands IV's step in either IVOPT or SCEV, right? > As a result, it's unlikely to have an IV's step referring to multiple > ssa names. And that's why I didn't extend it to a ssa name versions > bitmap. > >> >> So - I'd like you to constrain 'stop' and check it like >> >> if (TREE_CODE (expr) != SSA_NAME > Hmm, won't this effectively disable the expansion? Understood, the check is below ssa expanding. I will go through the regression file before applying this. Thanks, bin > >> || expr == stop) >> return expr; >> >> and declare >> >> -extern tree expand_simple_operations (tree); >> +extern tree expand_simple_operations (tree, tree = NULL_TREE); > I am still living in the C world... > >> >> Ok with that change. >> >> Thanks, >> Richard. >> -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Monday, February 09, 2015 6:10 PM To: gcc-patches@gcc.gnu.org Subject: [PATCH PR64705]Don't aggressively expand induction variable's >>> base Hi, As comments in the PR, root cause is GCC aggressively expand induction variable's base. This patch avoids that by adding new parameter to expand_simple_operations thus we can stop expansion whenever ssa var referred by IV's step is encountered. As comments in patch, we could stop expanding at each ssa var referred by IV's step, but that's expensive and >>> not likely to happen, this patch only extracts the first ssa var and skips >>> expanding accordingly. For the new test case, currently the loop body is bloated as below after IVOPT: : # ci_28 = PHI # ivtmp.13_31 = PHI ci_17 = ci_28 + 1; _1 = (void *) ivtmp.13_31; MEM[base: _1, offset: 0B] = 0; ivtmp.13_27 = ivtmp.13_31 + _26; _34 = (unsigned long) _13; _35 = (unsigned long) flags_8(D); _36 = _34 - _35; _37 = (unsigned long) step_14; _38 = _36 - _37; _39 = ivtmp.13_27 + _38; _40 = _39 + 3; iter_33 = (long int) _40; if (len_16(D) >= iter_33) goto ; else goto ; : goto ; And it can be improved by this patch as below: : # steps_28 = PHI # iter_29 = PHI steps_17 = steps_28 + 1; _31 = (sizetype) iter_29; MEM[base: flags_8(D), index: _31, offset: 0B] = 0; iter_21 = step_14 + iter_29; if (len_16(D) >= iter_21) goto ; else goto ; : goto ; I think this is a corner case, it only changes several files' assembly >>> code slightly in spec2k6. Among these files, only one of them is regression. >>> I looked into the regression and thought it was because of passes after >>> IVOPT. The IVOPT dump is at least not worse than the original version. Bootstrap and test on x86_64 and AArch64, so is it OK? 2015-02-09 Bin Cheng PR tree-optimization/64705 * tree-ssa-loop-niter.h (expand_simple_operations): New parameter. * tree-ssa-loop-niter.c (expand_simple_operations): New parameter. (tree_simplify_using_condition_1, refine_bounds_using_guard) (number_of_iterations_exit): Pass new argument to expand_simple_operations. * tree-ssa-loop-ivopts.c (extract_single_var_from_expr): New. (find_bivs, find_givs_in_stmt_scev): Pass new argument to expand_simple_operations. Call extract_single_var_from_expr. (difference_cannot_overflow_p): Pass new argument to expand_simple_operations. gcc/testsuite/ChangeLog 2015-02-09 Bin Cheng PR tree-optimization/64705 * gcc.dg/tree-ssa/pr64705.c: New test.
Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions
Hi!
On Tue, 10 Feb 2015 11:20:24 +0100, Jakub Jelinek wrote:
> On Tue, Feb 10, 2015 at 11:16:22AM +0100, Martin Jambor wrote:
> > On Mon, Jan 12, 2015 at 12:22:44AM +0300, Ilya Verbin wrote:
> > > Currently if a target* pragma appears within a target region, GCC
> > > successfully
> > > compiles such code (with a warning). But the binary fails at run-time,
> > > since it
> > > tries to call GOMP_target* functions on target.
> > >
> > > The spec says: "If a target, target update, or target data construct
> > > appears
> > > within a target region then the behavior is unspecified."
> > >
> > > I see 2 options to make the behavior more user-friendly:
> > > 1. To return an error at compile-time.
> > > 2. To check at run-time in libgomp whether GOMP_target* is called on
> > > target, and
> > > perform target-fallback if so.
> > >
> >
> > What actually happens when an accelerator calls a libgomp function?
> > Is a target libgomp port invoked? If so, it should easily know it
> > runs on a target even without a run-time check, I suppose. Or do you
> > somehow bring that call back to the host?
>
> The spec says that it is undefined behavior to invoke
> #pragma omp target {,data,update} from within #pragma omp target region.
We're not currently implementing that, but let me mention that OpenACC
describes a concept of nested parallelism:
OpenACC 2.0a, 1.2 Execution Model:
[...]
On some devices, the accelerator may also create and launch parallel
kernels, allowing for
nested parallelism. In that case, the OpenACC directives may be executed by
a host thread or
an accelerator thread. [...]
OpenACC 2.0a, 2.6 Data Environment:
[...] When a
nested OpenACC construct is executed on the device, the default target
device for that
construct is the same device on which the encountering accelerator thread
is executing. In
that case, the target device shares memory with the encountering thread.
For PTX, this would use CUDA's Dynamic Parallelism,
RE: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Jeff Law Sent: Tuesday, February 10, 2015 5:03 AM To: Bin.Cheng Cc: Alex Velenko; Felix Yang; Yangfei (Felix); Marcus Shawcroft; GCC Patches; vmaka...@redhat.com Subject: Re: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition On 02/03/15 20:03, Bin.Cheng wrote: > I looked into the test and can confirm the previous compilation is correct. > The cover letter of this patch said IRA mis-handled REQ_EQUIV before, > but in this case it is REG_EQUAL that is lost. The full dump (without > this patch) after IRA is like: Right, but a REG_EQUIV is generated based on the incoming REG_EQUAL notes in the insn stream. Basically update_equiv_regs will scan insn stream and some REG_EQUAL notes will be promoted to REG_EQUIV notes. The REG_EQUIV is a function-wide equivalence, meaning that one could substitute the REG_EQUIV note for in any uses of the destination register and still have a valid representation of the program. REG_EQUAL's validity is limited to the point after the insn in which it appears and before the next insn. > > Before r216169 (with REG_EQUAL in insn9), jumps from basic block 6/7/8 > -> 9 can be merged because r110 equals to -1 afterwards. But with the > patch, the equal information of r110==-1 in basic block 8 is lost. As > a result, jump from 8->9 can't be merged and two additional > instructions are generated. > > I suppose the REG_EQUAL note is correct in insn9? According to > GCCint, it only means r110 set by insn9 will be equal to the value at > run time at the end of this insn but not necessarily elsewhere in the > function. >>If you previously got a REG_EQUIV note on any of those insns it was wrong and >>this is the precise kind of situation that the change was trying to fix. >>R110 can have the value -1 (BB6, BB7, BB8) or 0 (BB5). Thus there is no >>single value across the entire function that one can validly use for r110. Does the value of R110 should not change across all the callee path from the given caller functions. If the value is aliased, then how the call side affects should make sure the value remains same across all the callee chain path from the given caller function. I am curious to know how the value remain constant throughout the function is identified in case of aliasing and the interprocedural case. >>I think you could mark this as a missed optimization, but not a regresssion >>since the desired output was relying on a bug in the compiler. >> >>If I were to start looking at this, my first thought would be to look at why >>we have multiple sets of r110, particularly if there are lifetimes that are >>disjoint. > > I also found another problem (or mis-leading?) with the document: > "Thus, compiler passes prior to register allocation need only check > for REG_EQUAL notes and passes subsequent to register allocation need > only check for REG_EQUIV notes". This seems not true now as in this > example, passes after register allocation do take advantage of > REG_EQUAL in optimization and we can't achieve that by using > REG_EQUIV. >>I think that's a long standing (and incorrect) generalization. IIRC we can >>get a REG_EQUIV note earlier for certain argument setup situations. >>And I think it's been the case for a long time that a pass after reload could try to exploit REG_EQUAL notes. Thanks & Regards Ajit jeff
Re: [debug-early] C++ clones and limbo DIEs
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote:
>
>>> +&& DECL_CONTEXT (snode->decl)
>>> +&& TREE_CODE (DECL_CONTEXT (snode->decl)) != FUNCTION_DECL)
>>
>>
>> I think this should be !decl_function_context (snode->decl), in case
>> there's a class or BLOCK between the symbol and its enclosing function.
>
>
> Done, also for the iteration through reachable functions.
>
>>
>>> dwarf2out_type_decl (tree decl, int local)
>>> + /* ?? Technically, we shouldn't need this hook at all, as all
>>> + symbols (and by consequence their types) will be outputed from
>>> + finalize_compilation_unit.
>>
>>
>> Note that we also want to emit debug info about some types that are not
>> referenced by symbols, such as when a type is used in a cast.
>
>
> Fair enough. I've removed the comment.
>
>>> +/* Perform any cleanups needed after the early debug generation pass
>>> + has run. */
>>> +
>>> +static void
>>> +dwarf2out_early_finish (void)
>>
>>
>> Since this is also called from dwarf2out_finish, let's call it something
>> more descriptive, say, flush_limbo_dies?
>
>
> I was actually thinking of using dwarf2out_early_finish() to mop things up
> as we generate early (or stream out) other auxiliary tables (pubname_table,
> pubtype_table, file_table, etc). More details on that later. If so, can I
> leave it as is?
>
> How is this version? No regressions on guality. Target libraries build
> fine.
Finally having a look at the patch. And indeed - this is how I thought
it should work.
Of course I wonder why you need to separate handling of functions and
variables. What breaks if you emit debug info for functions before
the first analyze_functions () call?
I also wonder why you restrict it to functions with a GIMPLE body.
I'd have expected for a TU like
void foo (int, int);
int main()
{
return 0;
}
to be able to do
(gdb) start
(gdb) ptype foo
and get a prototype for foo? (ok, that may be -g3 stuff)
Likewise for
struct foo { int i; };
int main ()
{
return 0;
}
and I realize that this needs frontend support - the middle-end really
only gets "reachable" stuff reliably.
Thus for -g3 we may end up retaining (or adding) some FE calls
to early_global{_decl,_type}?
(not that I care about the above cases in practice, but in theory?)
Thanks for doing all this work!
Richard.
[PATCH] Fix PR ipa/64813
Hello.
Following patch is fix for PR ipa/64813. The patch was tested on a darwin target
by Dominique.
Ready for trunk?
Thanks,
Martin
>From ce1c7031e2616d840ce9c1bc45587d64134f Mon Sep 17 00:00:00 2001
From: mliska
Date: Fri, 30 Jan 2015 15:12:59 +0100
Subject: [PATCH] Handle noreturn function thunk creation.
gcc/ChangeLog:
2015-02-09 Martin Liska
PR ipa/64813
* cgraphunit.c (cgraph_node::expand_thunk): Do not create
a return value for call to a function that is noreturn.
---
gcc/cgraphunit.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 8280fc4..77c8dd8 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1572,6 +1572,7 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk)
gcall *call;
greturn *ret;
+ bool alias_is_noreturn = TREE_THIS_VOLATILE (alias);
if (in_lto_p)
get_untransformed_body ();
@@ -1608,7 +1609,7 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk)
bsi = gsi_start_bb (bb);
/* Build call to the function being thunked. */
- if (!VOID_TYPE_P (restype))
+ if (!VOID_TYPE_P (restype) && !alias_is_noreturn)
{
if (DECL_BY_REFERENCE (resdecl))
{
@@ -1667,14 +1668,14 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk)
callees->call_stmt = call;
gimple_call_set_from_thunk (call, true);
gimple_call_set_with_bounds (call, instrumentation_clone);
- if (restmp)
+ if (restmp && !alias_is_noreturn)
{
gimple_call_set_lhs (call, restmp);
gcc_assert (useless_type_conversion_p (TREE_TYPE (restmp),
TREE_TYPE (TREE_TYPE (alias;
}
gsi_insert_after (&bsi, call, GSI_NEW_STMT);
- if (!(gimple_call_flags (call) & ECF_NORETURN))
+ if (!alias_is_noreturn)
{
if (restmp && !this_adjusting
&& (fixed_offset || virtual_offset))
--
2.1.2
[wwwdocs] Add Links section to porting to
We've performed a mass rebuild for Fedora, so I'm updating the porting to document with the following. Index: porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v retrieving revision 1.2 diff -u -r1.2 porting_to.html --- porting_to.html 15 Jan 2015 10:39:34 - 1.2 +++ porting_to.html 10 Feb 2015 11:10:03 - @@ -251,5 +251,12 @@ ^ +Links + + +Marek Polacek and Jakub Jelinek, + https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html";>Fedora test rebuild on x86_64-linux-gnu with gcc-5.0.0-0.5.fc22 + + Marek
Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c
On 09-02-15 20:01, Dominique d'Humières wrote:
Le 9 févr. 2015 à 19:10, Tom de Vries mailto:tom_devr...@mentor.com>> a écrit :
On 09-02-15 18:23, Dominique Dhumieres wrote:
Tom,
After these changes I have the following regressions on
x86_64-apple-darwin1[04]*:
FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
FAIL: gcc.dg/uninit-19.c (test for excess errors)
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of
SCoPs: 0" 1
I can prepare and test a fix for darwin unless you beat me!
Dominique,
thanks for finding this.
I don't understand why this breaks. Why is fpic supposed to be different for
darwin?
I don’t either, but the tests succeeds on darwin with the following patch
--- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 11:38:40.0
+0100
+++ gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 19:52:26.0 +0100
@@ -22,5 +22,5 @@ fn2 ()
fn1 (l, &d, &e, &g, &i, &h, &k, n); /* 22. */
}
-/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
-/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 } */
+/* { dg-warning "may be used uninitialized" "" { target { nonpic ||
x86_64-apple-darwin1[0-9]* } } 13 } */
+/* { dg-warning "may be used uninitialized" "" { target { ! { nonpic ||
x86_64-apple-darwin1[0-9]* } } } 22 } */
--- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09
11:38:40.0 +0100
+++ gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09 19:55:38.0 +0100
@@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
if (need > dgs->alc)
d_growable_string_resize (dgs, need);
}
-/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target
nonpic } } } */
-/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target
{ ! nonpic } } } } */
+/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target
{ nonpic || x86_64-apple-darwin1[0-9]* } } } } */
+/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target
{ ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
/* { dg-final { cleanup-tree-dump "graphite" } } */
I think we need to understand first what's going on.
In both test-cases, on Linux with -fpic the inlining of one function into the
other is not done, because we cannot be sure the function call in one function
binds to the other function at runtime.
So, is the inlining happening with -fpic for Darwin? If so, is that correct?
Thanks,
- Tom
Re: [RFC testsuite] Fix PR64850, tweak acc_on_device* tests
Hi!
On Wed, 4 Feb 2015 10:40:40 +0100, I wrote:
> On Wed, 04 Feb 2015 08:41:28 +0900 (JST), Kaz Kojima
> wrote:
> > Several goacc/acc_on_device tests fail for a few targets:
> >
> > hppa2.0w-hp-hpux11.11 (PR testsuite/64850)
> > https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg02659.html
> >
> > m68k-unknown-linux-gnu
> > https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg02960.html
> >
> > sh4-unknown-linux-gnu
> > https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg02930.html
> >
> > Also they fail with special options
> > x86_64-unknown-linux-gnu -fpic -mcmodel=large
> > https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00198.html
>
> Thanks for looking into this -- incidentally, I also started looking into
> it yesterday... :-)
>
> > Those tests scan .expand rtl dumps to get the number of calls for
> > acc_on_device function. For almost targets, the call rtx looks
> > something like
> >
> > (call (mem:QI (symbol_ref:SI ("acc_on_device") [flags 0x41]
> > ) [0 acc_on_device S1 A8])
> >
> > and tests use the regular expression "\\\(call \[^\\n\]*\\\"acc_on_device"
> > to detect it.
> > This expression doesn't match with the corresponding call rtx
> >
> > (call (mem:SI (symbol_ref/v:SI ("@acc_on_device") [flags 0x41]
> > ) [0 acc_on_device S4 A32])
> >
> > for hppa and something like
> >
> > (call (mem:QI (reg/f:SI 33) [0 acc_on_device S1 A8])
> >
> > for m68k and sh. All call rtxes have the function name in
> > the alias set of its mem rtx and it seems that the regular
> > expression "\\\(call \[^\\n\]* acc_on_device" works for all
> > cases. The attached patch is tested on i686-pc-linux-gnu and
> > sh4-unknown-linux-gnu.
>
> > PR testsuite/64850
> > * gcc.dg/goacc/acc_on_device-1.c: Use a space instead of \\\" in
> > the expression to find calls.
> > * c-c++-common/goacc/acc_on_device-2.c: Likewise.
> > * c-c++-common/goacc/acc_on_device-2-off.c: Likewise.
> > * gfortran.dg/goacc/acc_on_device-1.f95: Likewise.
> > * gfortran.dg/goacc/acc_on_device-2.f95: Likewise.
> > * gfortran.dg/goacc/acc_on_device-2-off.f95: Likewise.
>
> The other idea that I had is to separately scan/count the symbol_ref and
> the call (or call_insn?), but I'm not sure if that is "better". So, your
> patch looks good to me, thanks!
To resolve the immediate problem: is my approval "enough" for Kaz to
commit the patch, or does that need a "more authoritative approval"?
Jakub then suggested on IRC:
tschwinge: I don't understand why do you want to scan rtl dumps at
all; if you want to verify the library function is not called, I'd say best
just scan-assembler-not acc_on_device
I think I copied this approach from some other test case (but don't
remember which). In the current set of tests, we need to verify that the
acc_on_device library function is called 0, 1, or 4 times (see below).
For example, for gcc.dg/goacc/acc_on_device-1.c we'Ve got:
$ build-gcc/gcc/xgcc -Bbuild-gcc/gcc/
source-gcc/gcc/testsuite/gcc.dg/goacc/acc_on_device-1.c -fopenacc -O -std=c89
-Wno-implicit-function-declaration -S -fpic -mcmodel=large -o acc_on_device-1.s
$ grep acc_on_device < acc_on_device-1.s
.file "acc_on_device-1.c"
movabsq $acc_on_device@PLTOFF, %rdx
movabsq $acc_on_device@PLTOFF, %rdx
movabsq $acc_on_device@PLTOFF, %rdx
movabsq $acc_on_device@PLTOFF, %rdx
Isn't it even more fragile to scan here for acc_on_device being called
four times compared to the -fdump-rtl-expand dump? Or should I split up
the four tests into four separate files? (I guess I lack knowledge of
the best approach for doing such a thing in the GCC testsuite.)
For reference:
> > diff --git a/c-c++-common/goacc/acc_on_device-2-off.c
> > b/c-c++-common/goacc/acc_on_device-2-off.c
> > index 25d21ad..ea31047 100644
> > --- a/c-c++-common/goacc/acc_on_device-2-off.c
> > +++ b/c-c++-common/goacc/acc_on_device-2-off.c
> > @@ -20,6 +20,6 @@ f (void)
> > }
> >
> > /* Without -fopenacc, we're expecting one call.
> > - { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]*\\\"acc_on_device"
> > 1 "expand" } } */
> > + { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 1
> > "expand" } } */
> >
> > /* { dg-final { cleanup-rtl-dump "expand" } } */
> > diff --git a/c-c++-common/goacc/acc_on_device-2.c
> > b/c-c++-common/goacc/acc_on_device-2.c
> > index d5389a9..2f4ee2b 100644
> > --- a/c-c++-common/goacc/acc_on_device-2.c
> > +++ b/c-c++-common/goacc/acc_on_device-2.c
> > @@ -24,6 +24,6 @@ f (void)
> > perturbs expansion as a builtin, which expects an int parameter. It's
> > fine
> > when changing acc_device_t to plain int, but that's not what we're
> > doing in
> > .
> > - { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]*\\\"acc_on_device"
> > 0 "expand" { xfail c++ } } } */
> > + { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 0
> > "expand" { xfail c++ } } } */
> >
>
Re: Another ptx offloading patch
On 02/10/2015 11:34 AM, Richard Biener wrote: Bernds patch is ok with the unrelated gcc.c hunk removed. Thanks. I'm assuming this is for the next stage 1? Bernd
Re: Another ptx offloading patch
On Tue, Feb 10, 2015 at 01:06:15PM +0100, Bernd Schmidt wrote: > On 02/10/2015 11:34 AM, Richard Biener wrote: > > >Bernds patch is ok with the unrelated gcc.c hunk removed. > > Thanks. I'm assuming this is for the next stage 1? No, for current trunk, we don't want to ship with offloading to nvptx completely broken, which is my understanding of the current state. There is another patch that has been approved already, nvptx offloading patches [1/n] (and I think hasn't been committed yet), then there is the va_list issue where I'm afraid your patch will break normal LTO badly, it would be nice to discuss that. And finally for the enum machine_mode translation, I've started working on some patch, but didn't get too far yet, interrupted by other tasks. Jakub
Re: [PATCH] Fix PR ipa/64813
On Tue, Feb 10, 2015 at 12:07 PM, Martin Liška wrote: > Hello. > > Following patch is fix for PR ipa/64813. The patch was tested on a darwin > target > by Dominique. > > Ready for trunk? - if (!(gimple_call_flags (call) & ECF_NORETURN)) + if (!alias_is_noreturn) that was technically unnecessary, right? The call flags properly return ECF_NORETURN already? Ok if that is the case. Thanks, Roichard. > Thanks, > Martin
[PATCH] Fix PR64995
The following fixes PR64955 where we forgot to valueize VOPs before
using them as value-number.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2015-10-10 Richard Biener
PR tree-optimization/64995
* tree-ssa-sccvn.c (set_ssa_val_to): Assert that the
value we use is final.
(visit_reference_op_store): Always valueize op.
(visit_use): Properly valueize vuses.
* g++.dg/torture/pr64995.C: New testcase.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 220578)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -1606,7 +1606,7 @@ vn_reference_lookup_or_insert_for_pieces
va_heap> operands,
tree value)
{
- struct vn_reference_s vr1;
+ vn_reference_s vr1;
vn_reference_t result;
unsigned value_id;
vr1.vuse = vuse;
@@ -2816,7 +2816,8 @@ set_ssa_val_to (tree from, tree to)
}
gcc_assert (to != NULL_TREE
- && (TREE_CODE (to) == SSA_NAME
+ && ((TREE_CODE (to) == SSA_NAME
+ && (to == from || SSA_VAL (to) == to))
|| is_gimple_min_invariant (to)));
if (from != to)
@@ -3122,6 +3123,9 @@ visit_reference_op_store (tree lhs, tree
tree vuse = gimple_vuse (stmt);
tree vdef = gimple_vdef (stmt);
+ if (TREE_CODE (op) == SSA_NAME)
+op = SSA_VAL (op);
+
/* First we want to lookup using the *vuses* from the store and see
if there the last store to this location with the same address
had the same value.
@@ -3144,8 +3148,6 @@ visit_reference_op_store (tree lhs, tree
{
if (TREE_CODE (result) == SSA_NAME)
result = SSA_VAL (result);
- if (TREE_CODE (op) == SSA_NAME)
- op = SSA_VAL (op);
resultsame = expressions_equal_p (result, op);
}
@@ -3722,7 +3724,7 @@ visit_use (tree use)
changed = set_ssa_val_to (lhs, simplified);
if (gimple_vdef (stmt))
changed |= set_ssa_val_to (gimple_vdef (stmt),
- gimple_vuse (stmt));
+ SSA_VAL (gimple_vuse (stmt)));
goto done;
}
else if (simplified
@@ -3731,7 +3733,7 @@ visit_use (tree use)
changed = visit_copy (lhs, simplified);
if (gimple_vdef (stmt))
changed |= set_ssa_val_to (gimple_vdef (stmt),
- gimple_vuse (stmt));
+ SSA_VAL (gimple_vuse (stmt)));
goto done;
}
else
Index: gcc/testsuite/g++.dg/torture/pr64995.C
===
--- gcc/testsuite/g++.dg/torture/pr64995.C (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr64995.C (working copy)
@@ -0,0 +1,28 @@
+// { dg-do compile }
+
+extern "C" double acos(double);
+class A {
+public:
+double mY, mZ;
+A(double, double);
+double m_fn1(A *);
+int *m_fn2();
+};
+double a;
+A *b;
+A::A(double, double) : mY(), mZ() {}
+
+double A::m_fn1(A *) { return mY * mZ; }
+
+inline int *A::m_fn2() {
+mZ = 0;
+double c = m_fn1(this);
+a = acos(c);
+double d = m_fn1(b);
+acos(d);
+}
+
+void passTime() {
+A e(0, 1);
+e.m_fn2();
+}
Re: [Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping
On Feb 10, 2015, at 7:16 AM, Jeff Law wrote: > On 02/06/15 05:24, James Greenhalgh wrote: >> >> --- >> 2015-02-06 James Greenhalgh >> >> * haifa-sched.c (recompute_todo_spec): After applying a >> replacement and cancelling a dependency, also clear the >> SCHED_GROUP_P flag. > My worry here would be that we might be clearing a SCHED_GROUP_P that had > been set for some reason other than macro-fusion. > > It makes me wonder if we really want another bit to carry the "these must > remain consecutive for correctness" vs "please keep these together so > something later can optimize better" characteristics. > > I'm also tracking a bug where we mis-handle SCHED_GROUP_P when there's a > hazard of some sort between the first and second in the group. In that case > we fire the first insn, then queue the second. If some other insn that had > been queued earlier becomes ready during the cycles between where the first > insn fired and 2nd insn is scheduled to fire, then we'll break the > SCHED_GROUP_P relationship. For the particular case I'm looking at, it's a > correctness issue (cc0 machine and we end up splitting the cc0-setter and > cc0-user). Scheduler is not supposed to look at either queue or ready list when scheduling instructions in the SCHED_GROUP. There used to be code in schedule_insn() (this function is refactored/gone now, I think), but the logic should have stayed their. I'm at a conference at the moment (Linaro Connect) and can look at this on Monday/Tuesday (Feb 16/17). -- Maxim Kuvyrkov www.linaro.org
[PATCH] cap frequency in make_forwarder_block PR64326
From: tbsaunde
In the testcase the block with problematic frequency has to incoming
edges. Each edge has probability 1. The first edge's source bb has
frequency 873/1, and the second has a frequency of 9409/1. So
at least one of those is slightly high probably from some sort of rounding
issue related to fixed point, but in any case make_forwarder_block
should not create basic blocks with frequency greater than BB_FREQ_MAX.
bootstrapped + regtested x86_64-linux-gnu, checked test only passes with patch.
pre approved by Honza on irc so committed.
Trev
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 72fbdd7..50fa380 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-02-10 Trevor Saunders
+
+ PR tree-optimization/64326
+ * cfghooks.c (make_forwarder_block): Cap frequency of created block.
+
2015-02-10 Rainer Emrich
PR gcov-profile/61889
diff --git a/gcc/cfghooks.c b/gcc/cfghooks.c
index 4b57280..abeab8c 100644
--- a/gcc/cfghooks.c
+++ b/gcc/cfghooks.c
@@ -863,6 +863,9 @@ make_forwarder_block (basic_block bb, bool
(*redirect_edge_p) (edge),
if (redirect_edge_p (e))
{
dummy->frequency += EDGE_FREQUENCY (e);
+ if (dummy->frequency > BB_FREQ_MAX)
+ dummy->frequency = BB_FREQ_MAX;
+
dummy->count += e->count;
fallthru->count += e->count;
ei_next (&ei);
diff --git a/gcc/testsuite/gcc.dg/torture/pr64326.c
b/gcc/testsuite/gcc.dg/torture/pr64326.c
new file mode 100644
index 000..88ebf35
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr64326.c
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+
+int a, b, c, d, e, f[5][2];
+char g;
+
+int
+fn1 ()
+{
+ return d && c ? 0 : 1;
+}
+
+int
+fn2 ()
+{
+ int h;
+ for (;;)
+ for (; e;)
+ {
+ int i, j;
+ h = a ? 1 : b;
+ if (h ||
fn1 () ^ g - 682)
+
{
+
for (i = 0; i < 5; i++)
+
for (j = 0; j < 2; j++)
+
f[i][j] = 0;
+
return 0;
+
}
+ }
+}
+
--
2.1.4
Re: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition
On 02/10/15 03:51, Ajit Kumar Agarwal wrote: R110 can have the value -1 (BB6, BB7, BB8) or 0 (BB5). Thus there is no single value across the entire function that one can validly use for r110. Does the value of R110 should not change across all the callee path from the given caller functions. If the value is aliased, then how the call side affects should make sure the value remains same across all the callee chain path from the given caller function. I am curious to know how the value remain constant throughout the function is identified in case of aliasing and the interprocedural case. Pseudo registers are allowed to have aliases. Jeff
Re: [PATCH] Fix PR ipa/64813
On 02/10/2015 01:50 PM, Richard Biener wrote: On Tue, Feb 10, 2015 at 12:07 PM, Martin Liška wrote: Hello. Following patch is fix for PR ipa/64813. The patch was tested on a darwin target by Dominique. Ready for trunk? - if (!(gimple_call_flags (call) & ECF_NORETURN)) + if (!alias_is_noreturn) that was technically unnecessary, right? The call flags properly return ECF_NORETURN already? Ok if that is the case. Hi. You are right, !(gimple_call_flags (call) & ECF_NORETURN) returns a correct value. Motivation for replacement is not to repeat the same condition, I hope the value of alias_is_noreturn is correct in all uses. Thanks, Martin Thanks, Roichard. Thanks, Martin
Re: [PATCH] Fix PR ipa/64813
On Tue, Feb 10, 2015 at 04:56:40PM +0100, Martin Liška wrote: > On 02/10/2015 01:50 PM, Richard Biener wrote: > >On Tue, Feb 10, 2015 at 12:07 PM, Martin Liška wrote: > >>Hello. > >> > >>Following patch is fix for PR ipa/64813. The patch was tested on a darwin > >>target > >>by Dominique. > >> > >>Ready for trunk? > > > >- if (!(gimple_call_flags (call) & ECF_NORETURN)) > >+ if (!alias_is_noreturn) > > > >that was technically unnecessary, right? The call flags properly > >return ECF_NORETURN already? > > > >Ok if that is the case. > > Hi. > > You are right, !(gimple_call_flags (call) & ECF_NORETURN) returns a correct > value. > Motivation for replacement is not to repeat the same condition, I hope the > value > of alias_is_noreturn is correct in all uses. And gimple_call_flags (call) & ECF_NORETURN doesn't? I mean, if you could initialize alias_is_noreturn to that, it would be nicer. Jakub
[Patch Testsuite] XFAIL gfortran.dg/pr45636.f90 on AArch64
Hi,
As is already done for mips and hppa, we should XFAIL this test on
AArch64 as we don't currently use the store_by_pieces infrastructure.
We may in future want to tweak this, but for GCC 5.0 the safe thing
to do is just to XFAIL the test.
Tested with aarch64-none-elf.
OK?
Thanks,
James
---
2015-02-10 James Greenhalgh
* gfortran.dg/pr45636.f90: XFAIL for aarch64* targets.
diff --git a/gcc/testsuite/gfortran.dg/pr45636.f90 b/gcc/testsuite/gfortran.dg/pr45636.f90
index c80dda4..e3d8ca6 100644
--- a/gcc/testsuite/gfortran.dg/pr45636.f90
+++ b/gcc/testsuite/gfortran.dg/pr45636.f90
@@ -10,5 +10,5 @@ program main
b = y
call sub(a, b)
end program main
-! { dg-final { scan-tree-dump-times "memset" 0 "forwprop2" { xfail { { hppa*-*-* && { ! lp64 } } || { mips*-*-* && { ! nomips16 } } } } } }
+! { dg-final { scan-tree-dump-times "memset" 0 "forwprop2" { xfail { { hppa*-*-* && { ! lp64 } } || { { mips*-*-* && { ! nomips16 } } || { aarch64*-*-* } } } } } }
! { dg-final { cleanup-tree-dump "forwprop2" } }
New Esperanto PO file for 'cpplib' (version 5.1-b20150208)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Esperanto team of translators. The file is available at: http://translationproject.org/latest/cpplib/eo.po (This file, 'cpplib-5.1-b20150208.eo.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Contents of PO file 'cpplib-5.1-b20150208.eo.po'
cpplib-5.1-b20150208.eo.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
Mark one forgotten optimization flag
Hi, this patch adds optimization attribute to fstack-reuse that is obviously per-function. Bootstrapped/regtested x86_64-linux, commited as obvious. Honza Index: common.opt === --- common.opt (revision 220586) +++ common.opt (working copy) @@ -1372,7 +1372,7 @@ Common Report Var(flag_if_conversion2) O Perform conversion of conditional jumps to conditional execution fstack-reuse= -Common Joined RejectNegative Enum(stack_reuse_level) Var(flag_stack_reuse) Init(SR_ALL) +Common Joined RejectNegative Enum(stack_reuse_level) Var(flag_stack_reuse) Init(SR_ALL) Optimization -fstack-reuse=[all|named_vars|none] Set stack reuse level for local variables. Enum
Re: [PATCH] PR64959: SFINAE in UDLs
On 02/09/2015 08:27 AM, Andrea Azzarone wrote:
Please note that this is my first gcc patch
Thanks, looks good! A couple of nits:
* gcc/cp/parser.c: Make sure lookup_literal_operator returns all
the possible candidates. Also improve the diagnostic messages.
A ChangeLog entry should be per function, e.g.
* parser.c (lookup_literal_operator): Return all candidates.
(cp_parser_userdef_numeric_literal): Pass tf_warning_or_error.
(cp_parser_userdef_string_literal): Likewise. Prefer the
non-template form.
@@ -4044,31 +4061,15 @@ cp_parser_userdef_string_literal (tree l
{
tree tmpl_args = make_string_pack (value);
decl = lookup_template_function (decl, tmpl_args);
- result = finish_call_expr (decl, &args, false, true, tf_none);
+ result = finish_call_expr (decl, &args, false, true,
tf_warning_or_error);
if (result != error_mark_node)
- {
- release_tree_vector (args);
- return result;
- }
+{
+ release_tree_vector (args);
+ return result;
+}
}
Why not remove the test against error_mark_node here like you did in
cp_parser_userdef_numeric_literal?
Jason
Re: [Patch Testsuite] XFAIL gfortran.dg/pr45636.f90 on AArch64
On Feb 10, 2015, at 8:06 AM, James Greenhalgh wrote: > As is already done for mips and hppa, we should XFAIL this test on > AArch64 as we don't currently use the store_by_pieces infrastructure. For this patch, either this is obvious or a target person should weigh in. I’d only step in if the target maintainers went MIA. My only comment would be, add a /* move_by_pieces */ or something above the xfail that would indicate to the next person doing a port that gets a fail, if they are in the same boat as all the others.
Re: [debug-early] C++ clones and limbo DIEs
On 02/10/2015 05:52 AM, Richard Biener wrote:
I also wonder why you restrict it to functions with a GIMPLE body.
Likewise for
struct foo { int i; };
I guess these should depend on -feliminate-unused-debug-symbols and
-feliminate-unused-debug-types.
Jason
[PATCH, alpha]: Fix reload_out_aligned insn pattern
Hello!
gfortran.dg/char_length_15.f90 FAILs on non-BWX alpha due to invalid
propagation of memory address into reload_out_aligned insn
pattern.
We start with:
*** char_length_15.f90.228r.reload:
(insn 577 456 460 14 (parallel [
(set (mem/c:QI (plus:DI (reg:DI 6 $6 [358])
(const_int 8 [0x8])) [0 S1 A32])
(reg:QI 8 $8))
(clobber (reg:SI 3 $3))
(clobber (reg:SI 4 $4))
])
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/char_length_15.f90:30
243 {reload_outqi_aligned}
(nil))
Postreload pass propagates address involving clobbered reg $4:
*** char_length_15.f90.229r.postreload:
(insn 577 456 460 14 (parallel [
(set (mem/c:QI (plus:DI (reg:DI 4 $4 [357])
(const_int 12 [0xc])) [0 S1 A32])
(reg:QI 8 $8))
(clobber (reg:SI 3 $3))
(clobber (reg:SI 4 $4))
])
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/char_length_15.f90:30
243 {reload_outqi_aligned}
(nil))
And this pattern is split in a post-reload splitter to:
*** char_length_15.f90.231r.split2:
(insn 578 456 579 14 (set (reg:SI 3 $3)
(mem/c:SI (plus:DI (reg:DI 4 $4 [357])
(const_int 12 [0xc])) [0 S4 A32]))
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/char_length_15.f90:30
229 {*movsi}
(nil))
(insn 579 578 580 14 (set (reg:DI 3 $3)
(and:DI (reg:DI 3 $3)
(const_int -256 [0xff00])))
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/char_length_15.f90:30
48 {anddi3}
(nil))
(insn 580 579 581 14 (set (reg:DI 4 $4)
(ashift:DI (zero_extend:DI (reg:QI 8 $8))
(const_int 0 [0])))
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/char_length_15.f90:30
86 {insbl_const}
(nil))
(insn 581 580 582 14 (set (reg:DI 4 $4)
(ior:DI (reg:DI 4 $4)
(reg:DI 3 $3)))
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/char_length_15.f90:30
58 {iordi3}
(nil))
(insn 582 581 460 14 (set (mem/c:SI (plus:DI (reg:DI 4 $4 [357])
(const_int 12 [0xc])) [0 S4 A32])
(reg:SI 4 $4))
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/char_length_15.f90:30
229 {*movsi}
(nil))
(insn 582) uses the address that involves the register $4, clobbered
in (insn 580) and (insn 581).
Declaring operands 2 and 3 in reload_out_aligned insn pattern as
earlyclobber operands solves this issue.
2015-02-10 Uros Bizjak
* config/alpha/alpha.md (reload_out_aligned): Make operands 2
and 3 earlyclobber operands.
Patch was bootstrapped and regression tested on alpha-linux-gnu. Patch
was committed to mainline and will be backported to release branches.
Uros.
Index: config/alpha/alpha.md
===
--- config/alpha/alpha.md (revision 220566)
+++ config/alpha/alpha.md (working copy)
@@ -4496,8 +4496,8 @@
(define_insn_and_split "reload_out_aligned"
[(set (match_operand:I12MODE 0 "memory_operand" "=m")
(match_operand:I12MODE 1 "register_operand" "r"))
- (clobber (match_operand:SI 2 "register_operand" "=r"))
- (clobber (match_operand:SI 3 "register_operand" "=r"))]
+ (clobber (match_operand:SI 2 "register_operand" "=&r"))
+ (clobber (match_operand:SI 3 "register_operand" "=&r"))]
"!TARGET_BWX && (reload_in_progress || reload_completed)"
"#"
"!TARGET_BWX && reload_completed"
[wwwdocs] Some stuff for porting to
The following adds a few new notes. Ok? --- porting_to.html 10 Feb 2015 11:12:20 - 1.3 +++ porting_to.html 10 Feb 2015 17:58:52 - @@ -251,6 +251,99 @@ ^ +__STDC_VERSION__ macro + +In the C11 mode, the __STDC_VERSION__ standard macro, +introduced in C95, is now defined to 201112L. Typically, +this macro is used as in the following: + + + #if !defined __STDC_VERSION__ || __STDC_VERSION__ < 199901L +/* ... */ + #else + # include+ #endif + + +You can check the macro using gcc -dM -E -std=gnu11 - < /dev/null | grep STDC_VER. + +Different meaning of the %a *scanf modifier + +The GNU C library supports dynamic allocation via the %a +modifier. But in C99, the %a modifier is a synonym for +%f (float), so the compiler expects an argument of type +float *. This in combination with the -Wformat +warning option may result in additional warnings: + + + #include + + int + main (void) + { +char *s; +scanf ("%as", &s); + } + + + +q.c:7:10: warning: format '%a' expects argument of type 'float *', but argument 2 has type 'char **' [-Wformat=] + scanf ("%as", &s); + ^ + + +The fix is to use the %m modifier instead, specified by +POSIX.1-2008. + +New warnings + +Several new warnings have been added to the C front end. One of the new +warnings is that GCC now warns about non-standard predefined macros with the +-Wpedantic option. For instance: + + + void + foo (void) + { +const char *s = __FUNCTION__; + } + + + +q.c:4:19: warning: ISO C does not support '__FUNCTION__' predefined identifier [-Wpedantic] + const char *s = __FUNCTION__; + ^ + + +The fix is either to use the standard predefined macro __func__ +(since C99), or to use the __extension__ keyword: + + + const char *s = __extension__ __FUNCTION__; + + +C++ language issues + +Converting std::nullptr_t to bool + +Converting std::nullptr_t to bool in the C++11 +mode now requires direct-initialization. This has been changed in +http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423";>DR 1423. +As a consequence, the following is invalid: + + + bool b = nullptr; + + +but the following is valid: + + + bool b(nullptr); + + +It is recommended to use true, resp. false keywords +in such cases. + Links Marek
Re: [PATCH] Fix PR64764 && Fix scan-tree-dump for scop-19.c
Tom,
At -m32 on x86_64-apple-darwin14, the failing test case executes...
% /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O
-Wuninitialized -S -m32 -o uninit-19.s
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:
In function ‘fn2’:
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:13:15:
warning: ‘n’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:19:10:
note: ‘n’ was declared here
which following the following preprocessed source.
# 1
"/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c"
# 1 ""
# 1 ""
# 1
"/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c"
int a, l, m;
float *b;
float c, d, e, g, h;
unsigned char i, k;
void
fn1 (int p1, float *f1, float *f2, float *f3, unsigned char *c1, float *f4,
unsigned char *c2, float *p10)
{
if (p1 & 8)
b[3] = p10[a];
}
void
fn2 ()
{
float *n;
if (l & 6)
n = &c + m;
fn1 (l, &d, &e, &g, &i, &h, &k, n);
}
Does that help?
Jack
On Tue, Feb 10, 2015 at 6:42 AM, Tom de Vries wrote:
> On 09-02-15 20:01, Dominique d'Humières wrote:
>>
>>
>>> Le 9 févr. 2015 à 19:10, Tom de Vries >> > a écrit :
>>>
>>>
>>> On 09-02-15 18:23, Dominique Dhumieres wrote:
Tom,
After these changes I have the following regressions on
x86_64-apple-darwin1[04]*:
FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
FAIL: gcc.dg/uninit-19.c (test for excess errors)
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of
SCoPs: 0" 1
I can prepare and test a fix for darwin unless you beat me!
>>>
>>> Dominique,
>>>
>>> thanks for finding this.
>>>
>>> I don't understand why this breaks. Why is fpic supposed to be different
>>> for
>>> darwin?
>>
>>
>> I don’t either, but the tests succeeds on darwin with the following patch
>>
>> --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c2015-02-09
>> 11:38:40.0 +0100
>> +++ gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 19:52:26.0 +0100
>> @@ -22,5 +22,5 @@ fn2 ()
>> fn1 (l, &d, &e, &g, &i, &h, &k, n); /* 22. */
>> }
>>
>>
>> -/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
>> -/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22
>> } */
>> +/* { dg-warning "may be used uninitialized" "" { target { nonpic ||
>> x86_64-apple-darwin1[0-9]* } } 13 } */
>> +/* { dg-warning "may be used uninitialized" "" { target { ! { nonpic ||
>> x86_64-apple-darwin1[0-9]* } } } 22 } */
>> --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09
>> 11:38:40.0 +0100
>> +++ gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09 19:55:38.0
>> +0100
>> @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
>> if (need > dgs->alc)
>> d_growable_string_resize (dgs, need);
>> }
>> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" {
>> target
>> nonpic } } } */
>> -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" {
>> target
>> { ! nonpic } } } } */
>> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" {
>> target
>> { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
>> +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" {
>> target
>> { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
>> /* { dg-final { cleanup-tree-dump "graphite" } } */
>
>
> I think we need to understand first what's going on.
>
> In both test-cases, on Linux with -fpic the inlining of one function into
> the other is not done, because we cannot be sure the function call in one
> function binds to the other function at runtime.
>
> So, is the inlining happening with -fpic for Darwin? If so, is that correct?
>
> Thanks,
> - Tom
>
Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking
Mike, Actually there aren't really any darwin bits in the current patch... https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00468.html short of the dg-skip-if adjustments for the unsupported targets. Jack ps I wonder if this final patch needs be reposted to gcc-patches as... [PATCH][Revised] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking to make sure it gets the visibility for a review. On Mon, Feb 9, 2015 at 12:25 PM, Mike Stump wrote: > On Feb 8, 2015, at 10:24 AM, Jack Howarth wrote: >> This last version of the patch bootstraps and passes the test suite >> without regressions on x86_64-apple-darwin14. > > Ok for the darwin bits.
Re: [PATCH] Implement libffi for AARCH64:ILP32
On 02/09/2015 12:40 AM, Andrew Pinski wrote: > #ifndef LIBFFI_ASM > +#ifdef __ILP32__ > +typedef unsigned long long ffi_arg; > +typedef signed long long ffi_sarg; > +#else You need to set FFI_SIZEOF_ARG too. Otherwise it looks ok. r~
Re: [PATCH] Implement libffi for AARCH64:ILP32
On 02/09/2015 12:51 AM, Andrew Haley wrote: > Would it make more sense to use int64_t rather than long long? Probably, but we should do that all over libffi, rather than just this one hunk. r~
Re: PR 63566 part 5
On Mon, Feb 9, 2015 at 12:50 PM, Jan Hubicka wrote: > Hi, > this patch finally disables the wroarkound in ipa-icf for local functions. > > Bootstrapped/regtested x86_64-linux, comitted. > > Honza > > 2015-02-08 Jan Hubicka > > PR ipa/63566 > * ipa-icf.c (set_local): New function. > (sem_function::merge): Use it. This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65005 -- H.J.
Re: [PATCH] Implement libffi for AARCH64:ILP32
On Tue, Feb 10, 2015 at 10:35 AM, Richard Henderson wrote: > On 02/09/2015 12:40 AM, Andrew Pinski wrote: >> #ifndef LIBFFI_ASM >> +#ifdef __ILP32__ >> +typedef unsigned long long ffi_arg; >> +typedef signed long long ffi_sarg; >> +#else > > You need to set FFI_SIZEOF_ARG too. > > Otherwise it looks ok. Thanks. I am testing the patch with the following added under the ILP32 check: +#define FFI_SIZEOF_ARG 8 +#define FFI_SIZEOF_JAVA_RAW 4 Thanks, Andrew Pinski > > > r~
[C++ PATCH] Don't ICE on internal calls in check_noexcept_r (PR sanitizer/64984)
Hi!
Internal calls never throw and as shown on the testcase, sometimes
they can make it all the way to check_noexcept_r which was ICEing on those.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-02-10 Jakub Jelinek
PR sanitizer/64984
* except.c (check_noexcept_r): Return NULL for internal
calls.
* g++.dg/ubsan/pr64984.C: New test.
--- gcc/cp/except.c.jj 2015-01-31 10:07:36.0 +0100
+++ gcc/cp/except.c 2015-02-10 09:06:44.712226554 +0100
@@ -1148,7 +1148,7 @@ check_noexcept_r (tree *tp, int * /*walk
{
tree t = *tp;
enum tree_code code = TREE_CODE (t);
- if (code == CALL_EXPR
+ if ((code == CALL_EXPR && CALL_EXPR_FN (t))
|| code == AGGR_INIT_EXPR)
{
/* We can only use the exception specification of the called function
--- gcc/testsuite/g++.dg/ubsan/pr64984.C.jj 2015-02-10 09:52:43.720720833
+0100
+++ gcc/testsuite/g++.dg/ubsan/pr64984.C2015-02-10 10:00:00.343370913
+0100
@@ -0,0 +1,76 @@
+// PR sanitizer/64984
+// { dg-do compile }
+// { dg-options "-fsanitize=vptr -std=gnu++11" }
+
+template struct K
+{
+ static constexpr X v = 0;
+ typedef K t;
+};
+template struct A;
+template
+struct A : Y
+{
+};
+template X M ();
+template struct B;
+template
+struct B : K(M()))>
+{
+};
+template
+struct G : A>::t
+{
+};
+template struct J : G
+{
+};
+template X&& foo (X&);
+template X&& bar (X&&);
+template struct P
+{
+ P (X& x) : q (x) {}
+ X q;
+};
+template struct Q;
+template
+struct Q : P
+{
+ typedef P r;
+ X& s (Q&);
+ Q (X& x) : r (x) {}
+ Q (Q&& x) noexcept (J::v) : r (foo(s (x)))
+ {
+ }
+};
+template struct I : Q
+{
+ I ();
+ I (X&... x) : Q(x...)
+ {
+ }
+};
+template
+I baz (X&&... x)
+{
+ return I (foo(x)...);
+}
+template struct F
+{
+ int p;
+ void operator[] (X&& x)
+ {
+baz (bar (x));
+ }
+};
+struct U
+{
+ virtual ~U ();
+};
+
+int
+main ()
+{
+ F m;
+ m[U ()];
+}
Jakub
[PATCH] Fix -fsanitize=vptr sanopt lowering (PR sanitizer/65004)
Hi!
As ubsan_expand_vptr_ifn points *gsip to the first stmt in the next bb,
we want to always return true as no_next, we never want to gsi_next on it
before processing it further, otherwise we could skip some important
statement (e.g. another UBSAN_* call).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2015-02-10 Jakub Jelinek
PR sanitizer/65004
* ubsan.c (ubsan_expand_vptr_ifn): Always return true.
* g++.dg/asan/pr65004.C: New test.
--- gcc/ubsan.c.jj 2015-01-28 08:39:53.0 +0100
+++ gcc/ubsan.c 2015-02-10 18:44:59.796872508 +0100
@@ -1148,7 +1148,7 @@ ubsan_expand_vptr_ifn (gimple_stmt_itera
/* Get rid of the UBSAN_VPTR call from the IR. */
unlink_stmt_vdef (stmt);
gsi_remove (&gsi, true);
- return gsi_end_p (*gsip);
+ return true;
}
/* Instrument a memory reference. BASE is the base of MEM, IS_LHS says
--- gcc/testsuite/g++.dg/asan/pr65004.C.jj 2015-02-10 18:49:48.521988574
+0100
+++ gcc/testsuite/g++.dg/asan/pr65004.C 2015-02-10 18:51:22.249407985 +0100
@@ -0,0 +1,48 @@
+// PR sanitizer/65004
+// { dg-do compile }
+// { dg-options "-fcompare-debug -fsanitize=address -fsanitize=undefined
-fno-sanitize-recover=all" }
+
+namespace N {
+ template struct function;
+ namespace detail {
+namespace function {
+ struct vtable_base { };
+}
+ }
+ struct function_base {
+detail::function::vtable_base * vtable;
+ };
+ template struct function1 : public function_base {
};
+ template struct function : public
function1 { };
+}
+namespace Bar {
+ typedef N::function WarningHandler;
+}
+namespace Foo {
+ struct FooRecord {
+virtual ~FooRecord ();
+ };
+ struct TestRecord : public FooRecord {
+long x;
+ };
+}
+namespace Foo {
+ using Bar::WarningHandler;
+ struct FooScanner {
+WarningHandler warnHandler;
+int readByte ();
+long readSignedInteger ();
+ };
+ struct FooRecordReader {
+FooScanner & scanner;
+long readSInt ();
+void readTestRecord (TestRecord * recp);
+ };
+ inline long FooRecordReader::readSInt () {
+return scanner.readSignedInteger ();
+ }
+ void FooRecordReader::readTestRecord (TestRecord * recp) {
+int infoByte = scanner.readByte ();
+recp->x = readSInt ();
+ }
+}
Jakub
Re: [PATCH] Fix PR ipa/64813
> Hello.
>
> Following patch is fix for PR ipa/64813. The patch was tested on a darwin
> target
> by Dominique.
>
> Ready for trunk?
OK,
Honza
> Thanks,
> Martin
> >From ce1c7031e2616d840ce9c1bc45587d64134f Mon Sep 17 00:00:00 2001
> From: mliska
> Date: Fri, 30 Jan 2015 15:12:59 +0100
> Subject: [PATCH] Handle noreturn function thunk creation.
>
> gcc/ChangeLog:
>
> 2015-02-09 Martin Liska
>
> PR ipa/64813
> * cgraphunit.c (cgraph_node::expand_thunk): Do not create
> a return value for call to a function that is noreturn.
> ---
> gcc/cgraphunit.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> index 8280fc4..77c8dd8 100644
> --- a/gcc/cgraphunit.c
> +++ b/gcc/cgraphunit.c
> @@ -1572,6 +1572,7 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool
> force_gimple_thunk)
>
>gcall *call;
>greturn *ret;
> + bool alias_is_noreturn = TREE_THIS_VOLATILE (alias);
>
>if (in_lto_p)
> get_untransformed_body ();
> @@ -1608,7 +1609,7 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool
> force_gimple_thunk)
>bsi = gsi_start_bb (bb);
>
>/* Build call to the function being thunked. */
> - if (!VOID_TYPE_P (restype))
> + if (!VOID_TYPE_P (restype) && !alias_is_noreturn)
> {
> if (DECL_BY_REFERENCE (resdecl))
> {
> @@ -1667,14 +1668,14 @@ cgraph_node::expand_thunk (bool output_asm_thunks,
> bool force_gimple_thunk)
>callees->call_stmt = call;
>gimple_call_set_from_thunk (call, true);
>gimple_call_set_with_bounds (call, instrumentation_clone);
> - if (restmp)
> + if (restmp && !alias_is_noreturn)
> {
>gimple_call_set_lhs (call, restmp);
> gcc_assert (useless_type_conversion_p (TREE_TYPE (restmp),
>TREE_TYPE (TREE_TYPE
> (alias;
> }
>gsi_insert_after (&bsi, call, GSI_NEW_STMT);
> - if (!(gimple_call_flags (call) & ECF_NORETURN))
> + if (!alias_is_noreturn)
> {
> if (restmp && !this_adjusting
> && (fixed_offset || virtual_offset))
> --
> 2.1.2
>
Re: Fix PR 63566 part 4
On Sun, Feb 8, 2015 at 1:10 PM, Jan Hubicka wrote: > Hi, > this patch finally enables local functions for functions with aliases and > thunks. > > Honza > > PR ipa/63566 > * ipa-visibility.c (cgraph_node::non_local_p): Accept aliases. > (cgraph_node::local_p): Remove thunk related FIXME. This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006 -- H.J.
Re: [SH] Allow reg+disp address modes for atomics
On Tue, 2015-02-10 at 18:35 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > The attached patch fixes the lost mem aliasing info for atomic ops on SH
> > and allows the utilization of reg+disp address modes for atomic ops.
> > Actually it was supposed to be a pretty straight forward patch that just
> > replaces the open coded 'mem:QIHISI (match_operand:SI
> > "arith_reg_operand")' operands with something like 'match_operand:QIHISI
> > "atomic_mem_operand". For most of the patterns that's what it does and
> > the changes are quite mechanical. However, the QIHImode LLCS patterns
> > modify the address register of the mem operand and thus required some
> > special care (additional insns / splits).
> >
> > I've briefly tested it with
> > make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim
> > \{-m2/-ml,-m2/-mb,-m2a/-mb,-m2e/-ml,-m2e/-mb,-m3/-ml,-m3/-mb,-m3e/-ml,-m3e/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
> >
> > to verify that the patterns work in isolation. However, one thing I'm
> > not sure about is the fact that the predicate 'atomic_mem_operand_*' and
> > the Sra,Sdd,Ara,Add mem constraints are not in sync, i.e. the
> > constraints allow certain things which the predicates do not allow and
> > vice versa.
> >
> > Kaz, could you please try the patch on sh4-linux?
>
> No new failures on sh4-unknown-linux-gnu.
Thanks. Committed as r220594.
Cheers,
Oleg
[RFA][PATCH][PR rtl-optimization/47477] Type narrowing in match.pd
This PR was originally minor issue where we regressed on this kind of
sequence:
typedef struct toto_s *toto_t;
toto_t add (toto_t a, toto_t b) {
int64_t tmp = (int64_t)(intptr_t)a + ((int64_t)(intptr_t)b&~1L);
return (toto_t)(intptr_t) tmp;
}
There was talk of trying to peephole this in the x86 backend. But later
Jakub speculated that if we had good type narrowing this could be done
in the tree optimizers...
S, here we go. I didn't do anything with logicals are those are
already handled elsewhere in match.pd. I didn't try to handle MULT as
in the early experiments I did, it was a lose because of the existing
mechanisms for widening multiplications.
Interestingly enough, this patch seems to help out libjava more than
anything else in a GCC build and it really only helps a few routines.
There weren't any routines I could see where the code regressed after
this patch. This is probably an indicator that these things aren't
*that* common, or the existing shortening code better than we thought,
or some important shortening case is missing.
I think we should pull the other tests from 47477 which are not
regressions out into their own bug for future work. Or alternately,
when this fix is checked in remove the regression marker in 47477.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. OK for
the trunk?
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7f3816c..7a95029 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-02-10 Jeff Law
+
+ * match.pd (convert (plus/minus (convert @0) (convert @1): New
+ simplifier to narrow arithmetic.
+
2015-02-10 Richard Biener
PR tree-optimization/64909
diff --git a/gcc/match.pd b/gcc/match.pd
index 81c4ee6..abc703e 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1018,3 +1018,21 @@ along with GCC; see the file COPYING3. If not see
(logs (pows @0 @1))
(mult @1 (logs @0)
+/* If we have a narrowing conversion of an arithmetic operation where
+ both operands are widening conversions from the same type as the outer
+ narrowing conversion. Then convert the innermost operands to a suitable
+ unsigned type (to avoid introducing undefined behaviour), perform the
+ operation and convert the result to the desired type.
+
+ This narrows the arithmetic operation. */
+(for op (plus minus)
+ (simplify
+(convert (op (convert@2 @0) (convert @1)))
+(if (TREE_TYPE (@0) == TREE_TYPE (@1)
+ && TREE_TYPE (@0) == type
+ && INTEGRAL_TYPE_P (type)
+ && TYPE_PRECISION (TREE_TYPE (@2)) > TYPE_PRECISION (TREE_TYPE (@0))
+/* This prevents infinite recursion. */
+&& unsigned_type_for (TREE_TYPE (@0)) != TREE_TYPE (@2))
+ (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
+(convert (op (convert:utype @0) (convert:utype @1)))
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 15d5e2d..76e5254 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2015-02-10 Jeff Law
+
+ PR rtl-optimization/47477
+ * gcc.dg/tree-ssa/narrow-arith-1.c: New test.
+
2015-02-10 Richard Biener
PR tree-optimization/64909
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/narrow-arith-1.c
b/gcc/testsuite/gcc.dg/tree-ssa/narrow-arith-1.c
new file mode 100644
index 000..104cb6f5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/narrow-arith-1.c
@@ -0,0 +1,22 @@
+/* PR tree-optimization/47477 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized -w" } */
+/* { dg-require-effective-target ilp32 } */
+
+typedef int int64_t __attribute__ ((__mode__ (__DI__)));
+typedef int * intptr_t;
+
+typedef struct toto_s *toto_t;
+toto_t add (toto_t a, toto_t b) {
+ int64_t tmp = (int64_t)(intptr_t)a + ((int64_t)(intptr_t)b&~1L);
+ return (toto_t)(intptr_t) tmp;
+}
+
+/* For an ILP32 target there'll be 6 casts when we start, but just 4
+ if the match.pd pattern is successfully matched. */
+/* { dg-final { scan-tree-dump-times "= \\(int\\)" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "= \\(unsigned int\\)" 2 "optimized" } }
*/
+/* { dg-final { scan-tree-dump-times "= \\(struct toto_s \\*\\)" 1 "optimized"
} } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
+
+
Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking
On 02/07/2015 08:45 AM, H.J. Lu wrote:
> Here is an updated patch.
This is an annoying comment to differentiate 3 different versions, FYI.
> @@ -6826,11 +6817,18 @@ default_binds_local_p_1 (const_tree exp, int shlib)
>&& (TREE_STATIC (exp) || DECL_EXTERNAL (exp)))
> {
>varpool_node *vnode = varpool_node::get (exp);
> - if (vnode && (resolution_local_p (vnode->resolution) ||
> vnode->in_other_partition))
> - resolved_locally = true;
> - if (vnode
> - && resolution_to_local_definition_p (vnode->resolution))
> - resolved_to_local_def = true;
> + /* If not building shared library, common or initialized symbols
> + are also resolved locally, regardless they are weak or not if
> + weak_dominate is true. */
> + if (vnode)
> + {
> + if ((weak_dominate && !shlib && vnode->definition)
> + || vnode->in_other_partition
> + || resolution_local_p (vnode->resolution))
> + resolved_locally = true;
> + if (resolution_to_local_definition_p (vnode->resolution))
> + resolved_to_local_def = true;
> + }
> }
>else if (TREE_CODE (exp) == FUNCTION_DECL && TREE_PUBLIC (exp))
> {
Not the same test for a function_decl? That's certainly a mistake.
Indeed, I believe we can now unify these two cases by using the base
symtab_node instead of varpool_node and cgraph_node.
I'm a bit confused about why we have both resolved_to_local_def vs
resolved_locally. At least within this function, which only cares about module
locality rather than object file locality. Honza?
> @@ -6859,9 +6857,15 @@ default_binds_local_p_1 (const_tree exp, int shlib)
>else if (! TREE_PUBLIC (exp))
> local_p = true;
>/* A variable is local if the user has said explicitly that it will
> - be. */
> + be and it is resolved or defined locally, not compiling for PIC,
> + not weak or weak_dominate is false. */
>else if ((DECL_VISIBILITY_SPECIFIED (exp)
> || resolved_to_local_def)
> +&& (!weak_dominate
> +|| resolved_locally
> +|| !flag_pic
> +|| !DECL_EXTERNAL (exp)
> +|| !DECL_WEAK (exp))
> && DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
> local_p = true;
I think this test is conflating several issues, and as such it's very confusing.
As an existing issue, I'm not sure why "specified" visibility is any different
from unspecified visibility. As far as I'm aware, the "specified" bit simply
means that the decl doesn't inherit inherit visibility from the class, or from
the command-line. But once we're this far, the visibility actually applied to
the symbol should be all that matters.
Unfortunately, this test is 11 years old, from r85167. It came in as part of
the implementation of the visibility attribute for the class.
I believe the next test should be
else if (DECL_WEAK (exp) && !resolved_locally)
local_p = false;
Given the change above, resolved_locally will now be true for (weak && defined
&& weak_dominate), and therefore we need not reiterate that test.
I believe the next test should be dictated by normal non-lto usage like
extern void bar(void) __attribute__((visibility("hidden")));
void foo(void) { ... bar(); ...)
where the user is expecting that the function call make use of a simpler
instruction sequence, probably avoiding an PLT. Therefore
else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
local_p = true;
Since we have already excluded undef-weak, we know that any symbol here is
either defined or strong, and non-default visibility must resolve it locally.
>/* Variables defined outside this object might not be local. */
> @@ -6881,8 +6885,9 @@ default_binds_local_p_1 (const_tree exp, int shlib)
>else if (shlib)
> local_p = false;
>/* Uninitialized COMMON variable may be unified with symbols
> - resolved from other modules. */
> + resolved from other modules unless weak_dominate is true. */
>else if (DECL_COMMON (exp)
> +&& !weak_dominate
> && !resolved_locally
Like the weak test, surely weak_dominate has already been accounted for.
> @@ -7445,9 +7465,10 @@ default_elf_asm_output_external (FILE *file
> ATTRIBUTE_UNUSED,
> {
>/* We output the name if and only if TREE_SYMBOL_REFERENCED is
> set in order to avoid putting out names that are never really
> - used. */
> + used. Always output visibility specified in the source. */
>if (TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))
> - && targetm.binds_local_p (decl))
> + && (DECL_VISIBILITY_SPECIFIED (decl)
> + || targetm.binds_local_p (decl)))
> maybe_assemble_visibility (decl);
Explain?
I'm testing the following in the meantime, in order to validate my hypotheses
above.
r~
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 48a4b35..a1ed927 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -803,8 +803,10 @@ varpool_node:
Re: [PATCH] Implement libffi for AARCH64:ILP32
On 02/10/2015 11:02 AM, Andrew Pinski wrote: > +#define FFI_SIZEOF_JAVA_RAW 4 Since aarch64 doesn't implement the raw java api, this is irrelevant. r~
Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking
On Tue, Feb 10, 2015 at 1:19 PM, Richard Henderson wrote:
>> @@ -7445,9 +7465,10 @@ default_elf_asm_output_external (FILE *file
>> ATTRIBUTE_UNUSED,
>> {
>>/* We output the name if and only if TREE_SYMBOL_REFERENCED is
>> set in order to avoid putting out names that are never really
>> - used. */
>> + used. Always output visibility specified in the source. */
>>if (TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))
>> - && targetm.binds_local_p (decl))
>> + && (DECL_VISIBILITY_SPECIFIED (decl)
>> + || targetm.binds_local_p (decl)))
>> maybe_assemble_visibility (decl);
>
> Explain?
>
This is for the new testcase in my patch:
[hjl@gnu-mic-2 testsuite]$ cat gcc.dg/visibility-23.c
/* PR target/32219 */
/* { dg-do compile } */
/* { dg-require-visibility "" } */
/* { dg-final { scan-hidden "foo" } } */
/* { dg-options "-O2 -fPIC" { target fpic } } */
/* { dg-skip-if "" { "hppa*-*-hpux*" "*-*-aix*" "*-*-darwin*" } "*" { "" } } */
extern void foo () __attribute__((weak,visibility("hidden")));
int
main()
{
if (foo)
foo ();
return 0;
}
[hjl@gnu-mic-2 testsuite]$
Here targetm.binds_local_p now returns false. But we must
emit ".hidden foo" even if foo isn't defined in the TU. Otherwise,
foo wont be hidden if it isn't defined in another TU.
--
H.J.
Re: [PATCH] Fix -fsanitize=vptr sanopt lowering (PR sanitizer/65004)
On February 10, 2015 9:08:33 PM CET, Jakub Jelinek wrote:
>Hi!
>
>As ubsan_expand_vptr_ifn points *gsip to the first stmt in the next bb,
>we want to always return true as no_next, we never want to gsi_next on
>it
>before processing it further, otherwise we could skip some important
>statement (e.g. another UBSAN_* call).
>
>Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
>for
>trunk?
Ok.
Thanks,
Richard.
>2015-02-10 Jakub Jelinek
>
> PR sanitizer/65004
> * ubsan.c (ubsan_expand_vptr_ifn): Always return true.
>
> * g++.dg/asan/pr65004.C: New test.
>
>--- gcc/ubsan.c.jj 2015-01-28 08:39:53.0 +0100
>+++ gcc/ubsan.c2015-02-10 18:44:59.796872508 +0100
>@@ -1148,7 +1148,7 @@ ubsan_expand_vptr_ifn (gimple_stmt_itera
> /* Get rid of the UBSAN_VPTR call from the IR. */
> unlink_stmt_vdef (stmt);
> gsi_remove (&gsi, true);
>- return gsi_end_p (*gsip);
>+ return true;
> }
>
>/* Instrument a memory reference. BASE is the base of MEM, IS_LHS says
>--- gcc/testsuite/g++.dg/asan/pr65004.C.jj 2015-02-10
>18:49:48.521988574 +0100
>+++ gcc/testsuite/g++.dg/asan/pr65004.C2015-02-10 18:51:22.249407985
>+0100
>@@ -0,0 +1,48 @@
>+// PR sanitizer/65004
>+// { dg-do compile }
>+// { dg-options "-fcompare-debug -fsanitize=address
>-fsanitize=undefined -fno-sanitize-recover=all" }
>+
>+namespace N {
>+ template struct function;
>+ namespace detail {
>+namespace function {
>+ struct vtable_base { };
>+}
>+ }
>+ struct function_base {
>+detail::function::vtable_base * vtable;
>+ };
>+ template struct function1 : public
>function_base { };
>+ template struct function : public
>function1 { };
>+}
>+namespace Bar {
>+ typedef N::function WarningHandler;
>+}
>+namespace Foo {
>+ struct FooRecord {
>+virtual ~FooRecord ();
>+ };
>+ struct TestRecord : public FooRecord {
>+long x;
>+ };
>+}
>+namespace Foo {
>+ using Bar::WarningHandler;
>+ struct FooScanner {
>+WarningHandler warnHandler;
>+int readByte ();
>+long readSignedInteger ();
>+ };
>+ struct FooRecordReader {
>+FooScanner & scanner;
>+long readSInt ();
>+void readTestRecord (TestRecord * recp);
>+ };
>+ inline long FooRecordReader::readSInt () {
>+return scanner.readSignedInteger ();
>+ }
>+ void FooRecordReader::readTestRecord (TestRecord * recp) {
>+int infoByte = scanner.readByte ();
>+recp->x = readSInt ();
>+ }
>+}
>
> Jakub
Re: patch to fix rtl documentation for new floating point comparisons
On Mon, 9 Feb 2015, Kenneth Zadeck wrote: > > I don't think it's useful to have the trapping semantics unspecified for a > > comparison operation like that. So the question is what's most useful for > > LTGT and LTGT_EXPR to do (presumably they should do the same thing). Lots > > of existing code in this area seems confused (for example, HONOR_SNANS > > should be irrelevant to reversing an equality comparison, as reversing it > > will change neither results nor exceptions raised, whether or not > > signaling NaNs are involved). But maybe more code treats LTGT as a > > signaling operation than otherwise, in accordance with the original > > intent, and so that's the most appropriate way to document it (with !UNEQ > > being the representation of the corresponding quiet operation). > section 7.12.14.4 in C99 seems pretty much to say that this is a quiet > operation. It says islessgreater is quiet. It says nothing about the LTGT RTL operation or the LTGT_EXPR GIMPLE/GENERIC operation. __builtin_islessgreater is implemented using UNEQ_EXPR not LTGT_EXPR. It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the choice of definition is a matter of what's convenient for the implementation (and which choice you make determines which existing code in GCC should be considered incorrect). Where back ends implement ltgt patterns, I don't know if they are consistently quiet or signaling. -- Joseph S. Myers jos...@codesourcery.com
Re: patch to fix rtl documentation for new floating point comparisons
> But maybe more code treats LTGT as a signaling operation than otherwise, in > accordance with the original intent, and so that's the most appropriate way > to document it (with !UNEQ being the representation of the corresponding > quiet operation). SPARC supports all codes and treats everything but LT/LE/GT/GE as quiet. -- Eric Botcazou
Re: [wwwdocs] Some stuff for porting to
On Tue, 10 Feb 2015, Marek Polacek wrote:
> +Several new warnings have been added to the C front end. One of the new
> +warnings is that GCC now warns about non-standard predefined macros with the
> +-Wpedantic option. For instance:
> +
> +
> + void
> + foo (void)
> + {
> +const char *s = __FUNCTION__;
> + }
> +
> +
> +
> +q.c:4:19: warning: ISO C does not
> support '__FUNCTION__' predefined identifier [-Wpedantic]
> + const char *s = __FUNCTION__;
> + ^
> +
> +
> +The fix is either to use the standard predefined macro
> __func__
> +(since C99), or to use the __extension__ keyword:
__FUNCTION__ and __func__ aren't macros (essentially they're built-in
variables).
--
Joseph S. Myers
jos...@codesourcery.com
Re: [Patch, fortran] PR64952 - Missing temporary in assignment from elemental function
Dear Mikael, dear all, Thank you for the previous review. I believe that the attached responds to all of your comments and correctly compiles the three testcases that you provided. Two of these have been included in the original testcase and the third appears separately. Bootstrapped and reg tested on FC21/x86_64 - OK for trunk? Cheers Paul 2015-02-10 Paul Thomas PR fortran/64952 * gfortran.h : Add 'array_outer_dependency' to symbol_attr. * trans.h : Add 'array_outer_dependency' to gfc_ss_info. * module.c : Add AB_ARRAY_OUTER_DEPENDENCY to ab_attribute. Add same to attr_bits. (mio_symbol_attribute): Handle 'array_outer_dependency' attr in module read and write. * resolve.c (resolve_function): If an elemental function is referenced that is marked as having an external array reference and the current namespace is that of an elemental function, mark the containing function likewise. (resolve_variable): Mark elemental function symbol as 'array_outer_dependency' if it has an array reference from outside its own namespace. * trans-array.c (gfc_conv_resolve_dependencies): If any ss is marked as 'array_outer_dependency' generate a temporary. (gfc_walk_function_expr): If the function is marked as 'array_outer_dependency', likewise mark the head gfc_ss. 2015-02-10 Paul Thomas PR fortran/64952 * gfortran.dg/elemental_dependency_4.f90: New test * gfortran.dg/elemental_dependency_5.f90: New test On 8 February 2015 at 19:16, Paul Richard Thomas wrote: > Dear Mikael, > > Thank you very much for the review. You raise some points that I had > thought about and others that I hadn't. I also realised that such > things as blocks, within the elemental function would through the fix > as well. I'll defer doing anything with it until tomorrow night. > > I reason that there is always going to be an 'ss', although I should > check that it is not gfc_ss_terminator, and that it does not matter > which one is flagged. I should add a comment to that effect; it's not > quite as hackish as it looks, methinks. > > I will be back! > > Paul > > On 8 February 2015 at 18:27, Mikael Morin wrote: >> Hello Paul, >> >> comments below >> >> Le 08/02/2015 16:24, Paul Richard Thomas a écrit : >>> >>> Index: gcc/fortran/gfortran.h >>> === >>> *** gcc/fortran/gfortran.h(revision 220482) >>> --- gcc/fortran/gfortran.h(working copy) >>> *** typedef struct >>> *** 789,794 >>> --- 789,798 >>>cannot alias. Note that this is zero for PURE procedures. */ >>> unsigned implicit_pure:1; >>> >>> + /* This set for an elemental function that contains expressions for >>> + arrays coming from outside its namespace. */ >>> + unsigned potentially_aliased:1; >>> + >> aliased is more something about pointers, so how about naming it >> something like array_outer_dependency? Anyway, that's minor. >> >> I wonder whether we should negate the meaning, that is set the flag if >> there is no external dependency. >> If we can get the conditions to set it exhaustively right, both are >> equivalent. Otherwise... maybe not. >> >>> /* This is set if the subroutine doesn't return. Currently, this >>>is only possible for intrinsic subroutines. */ >>> unsigned noreturn:1; >>> Index: gcc/fortran/trans.h >>> === >>> *** gcc/fortran/trans.h (revision 220481) >>> --- gcc/fortran/trans.h (working copy) >>> *** typedef struct gfc_ss_info >>> *** 226,231 >>> --- 226,235 >>> /* Suppresses precalculation of scalars in WHERE assignments. */ >>> unsigned where:1; >>> >>> + /* Signals that an array argument of an elemental function might be >>> aliased, >>> + thereby generating a temporary in assignments. */ >>> + unsigned potentially_aliased:1; >>> + >>> /* Tells whether the SS is for an actual argument which can be a NULL >>>reference. In other words, the associated dummy argument is >>> OPTIONAL. >>>Used to handle elemental procedures. */ >>> Index: gcc/fortran/resolve.c >>> === >>> *** gcc/fortran/resolve.c (revision 220481) >>> --- gcc/fortran/resolve.c (working copy) >>> *** resolve_variable (gfc_expr *e) >>> *** 5054,5059 >>> --- 5054,5067 >>> && gfc_current_ns->parent->parent == sym->ns))) >>> sym->attr.host_assoc = 1; >>> >>> + if (sym->attr.dimension >>> + && (sym->ns != gfc_current_ns >>> + || sym->attr.use_assoc >>> + || sym->attr.in_common) >>> + && gfc_elemental (NULL) >>> + && gfc_current_ns->proc_name->attr.function) >>> + gfc_current_ns->proc_name->attr.potentially_aliased = 1; >> I would expect the flag to also be copied between procedures in some >> c
Re: [C++ PATCH] Don't ICE on internal calls in check_noexcept_r (PR sanitizer/64984)
OK. Jason
Re: [PATCH] Implement libffi for AARCH64:ILP32
On Tue, Feb 10, 2015 at 1:20 PM, Richard Henderson wrote:
> On 02/10/2015 11:02 AM, Andrew Pinski wrote:
>> +#define FFI_SIZEOF_JAVA_RAW 4
>
> Since aarch64 doesn't implement the raw java api, this is irrelevant.
Ok. This is what I applied to GCC after testing it (I don't have
access to the libffi git repo).
2015-02-10 Andrew Pinski
* src/aarch64/ffitarget.h (ffi_arg): Use unsigned long long for ILP32.
(FFI_SIZEOF_ARG): Define to 64 for ILP32.
(ffi_sarg): Use signed long long for ILP32.
* src/aarch64/sysv.S (PTR_REG): New macro.
(PTR_SIZE): New macro.
(ffi_closure_SYSV): Load cif, fn and user_data using PTR_REG.
(ffi_go_closure_SYSV): Load cif and fn using PTR_REG.
Thanks,
Andrew Pinski
>
>
> r~
commit b3d4df7304dcbc56475f400837b47fc52143292e
Author: Andrew Pinski
Date: Mon Feb 9 08:41:09 2015 +
* src/aarch64/ffitarget.h (ffi_arg): Use unsigned long long for ILP32.
(FFI_SIZEOF_ARG): Define to 64 for ILP32.
(ffi_sarg): Use signed long long for ILP32.
* src/aarch64/sysv.S (PTR_REG): New macro.
(PTR_SIZE): New macro.
(ffi_closure_SYSV): Load cif, fn and user_data using PTR_REG.
(ffi_go_closure_SYSV): Load cif and fn using PTR_REG.
diff --git a/libffi/src/aarch64/ffitarget.h b/libffi/src/aarch64/ffitarget.h
index fca2811..2862ec7 100644
--- a/libffi/src/aarch64/ffitarget.h
+++ b/libffi/src/aarch64/ffitarget.h
@@ -27,8 +27,14 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
#endif
#ifndef LIBFFI_ASM
+#ifdef __ILP32__
+#define FFI_SIZEOF_ARG 8
+typedef unsigned long long ffi_arg;
+typedef signed long long ffi_sarg;
+#else
typedef unsigned long ffi_arg;
typedef signed long ffi_sarg;
+#endif
typedef enum ffi_abi
{
diff --git a/libffi/src/aarch64/sysv.S b/libffi/src/aarch64/sysv.S
index 46f50b9..c1bf9b9 100644
--- a/libffi/src/aarch64/sysv.S
+++ b/libffi/src/aarch64/sysv.S
@@ -45,6 +45,18 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
# define BE(X) 0
#endif
+#ifdef __ILP32__
+#define PTR_REG(n) w##n
+#else
+#define PTR_REG(n) x##n
+#endif
+
+#ifdef __ILP32__
+#define PTR_SIZE 4
+#else
+#define PTR_SIZE 8
+#endif
+
.text
.align 4
@@ -248,8 +260,8 @@ CNAME(ffi_closure_SYSV):
stp x6, x7, [sp, #16 + 16*N_V_ARG_REG + 48]
/* Load ffi_closure_inner arguments. */
- ldp x0, x1, [x17, #FFI_TRAMPOLINE_CLOSURE_OFFSET] /* load cif, fn
*/
- ldr x2, [x17, #FFI_TRAMPOLINE_CLOSURE_OFFSET+16]/* load
user_data */
+ ldp PTR_REG(0), PTR_REG(1), [x17, #FFI_TRAMPOLINE_CLOSURE_OFFSET]
/* load cif, fn */
+ ldr PTR_REG(2), [x17, #FFI_TRAMPOLINE_CLOSURE_OFFSET+PTR_SIZE*2]
/* load user_data */
.Ldo_closure:
add x3, sp, #16 /* load context */
add x4, sp, #ffi_closure_SYSV_FS/* load stack */
@@ -403,7 +415,7 @@ CNAME(ffi_go_closure_SYSV):
stp x6, x7, [sp, #16 + 16*N_V_ARG_REG + 48]
/* Load ffi_closure_inner arguments. */
- ldp x0, x1, [x18, #8] /* load cif, fn */
+ ldp PTR_REG(0), PTR_REG(1), [x18, #PTR_SIZE]/* load cif, fn */
mov x2, x18 /* load user_data */
b .Ldo_closure
cfi_endproc
Re: [testsuite] PATCH: Add check_effective_target_pie
Jeff Law writes: >> Subject: [PATCH 1/5] Add check_effective_target_pie >> >> Hi, >> >> This patch adds check_effective_target_pie to check if the current >> multilib generates PIE by default. >> >> Thanks. >> >> H.J. >> --- >> 2015-01-11 H.J. Lu >> >> * gcc.target/i386/pie.c: New test. >> >> * lib/target-supports.exp (check_effective_target_pie): New. > OK. The new proc is bogus, unfortunately: there's already an existing check_effective_target_pie that checks if a target can support PIE. The new one just overrides the previous one. On targets supporting PIE (like Darwin), but not defaulting to it, the PIE tests suddenly turn out UNSUPPORTED. You should rename the new one to e.g. check_effective_target_pie_default, update the single user, and document it in sourcebuild.texi. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] PR64959: SFINAE in UDLs
Hi,
Thanks for the review. I updated the patch.
2015-2-9 Andrea Azzarone
PR c++/64959
* parser.c (lookup_literal_operator): Return all candidates.
(cp_parser_userdef_char_literal): Simplify error handling.
(cp_parser_userdef_numeric_literal): Pass tf_warning_or_error.
(cp_parser_userdef_string_literal): Pass tf_warning_or_error.
Also give higher priority to standard string UDL operator.
* gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C: Added
test case to make sure gcc detects ambiguous UDL declarations.
* gcc/testsuite/g++.dg/cpp0x/udlit-namespace-using-directive.C:
Added test case to make sure gcc correctly handles using directive for
UDLs.
* gcc/testsuite/g++.dg/cpp0x/udlit-resolve.C: Removed a incorrect test case.
* gcc/testsuite/g++.dg/cpp0x/udlit-sfinae.C: Added a test case to
make sure that enable_if can be used to select between overloads of
UDLs.
* gcc/testsuite/g++.dg/cpp0x/udlit-sfinae-neg.C: Added a test case
to make sure gcc correctly detects substitution failures when all the
UDSL overloads are disabled by enable_if.
* gcc/testsuite/g++.dg/cpp1y/udlit-char-template-sfinae-neg.C:
Like cpp0x/udlit-sfinae-neg.C but for string template literals.
* gcc/testsuite/g++.dg/cpp1y/udlit-char-template-sfinae.C: Like
cpp0x/udlit-sfinae.C but for string template literals.
* gcc/testsuite/g++.dg/cpp1y/udlit-char-template-vs-std-literal-operator.C:
Added a test to make sure that string template literals have a smaller
priority than standard literal operators.
2015-02-10 18:18 GMT+01:00 Jason Merrill :
> On 02/09/2015 08:27 AM, Andrea Azzarone wrote:
>>
>> Please note that this is my first gcc patch
>
>
> Thanks, looks good! A couple of nits:
>
>> * gcc/cp/parser.c: Make sure lookup_literal_operator returns all
>> the possible candidates. Also improve the diagnostic messages.
>
>
> A ChangeLog entry should be per function, e.g.
>
> * parser.c (lookup_literal_operator): Return all candidates.
> (cp_parser_userdef_numeric_literal): Pass tf_warning_or_error.
> (cp_parser_userdef_string_literal): Likewise. Prefer the
> non-template form.
>
>> @@ -4044,31 +4061,15 @@ cp_parser_userdef_string_literal (tree l
>> {
>>tree tmpl_args = make_string_pack (value);
>>decl = lookup_template_function (decl, tmpl_args);
>> - result = finish_call_expr (decl, &args, false, true, tf_none);
>> + result = finish_call_expr (decl, &args, false, true,
>> tf_warning_or_error);
>>if (result != error_mark_node)
>> - {
>> - release_tree_vector (args);
>> - return result;
>> - }
>> +{
>> + release_tree_vector (args);
>> + return result;
>> +}
>> }
>
>
> Why not remove the test against error_mark_node here like you did in
> cp_parser_userdef_numeric_literal?
>
> Jason
>
--
Andrea Azzarone
http://launchpad.net/~andyrock
http://wiki.ubuntu.com/AndreaAzzarone
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 220454)
+++ gcc/cp/parser.c (working copy)
@@ -3828,7 +3828,7 @@ lookup_literal_operator (tree name, vec<
work in presence of default arguments on the literal
operator parameters. */
&& parmtypes == void_list_node)
- return fn;
+ return decl;
}
}
@@ -3862,12 +3862,7 @@ cp_parser_userdef_char_literal (cp_parse
}
result = finish_call_expr (decl, &args, false, true, tf_warning_or_error);
release_tree_vector (args);
- if (result != error_mark_node)
-return result;
-
- error ("unable to find character literal operator %qD with %qT argument",
-name, TREE_TYPE (value));
- return error_mark_node;
+ return result;
}
/* A subroutine of cp_parser_userdef_numeric_literal to
@@ -3955,26 +3950,27 @@ cp_parser_userdef_numeric_literal (cp_pa
decl = lookup_literal_operator (name, args);
if (decl && decl != error_mark_node)
{
- result = finish_call_expr (decl, &args, false, true, tf_none);
- if (result != error_mark_node)
+ result = finish_call_expr (decl, &args, false, true,
tf_warning_or_error);
+
+ if (TREE_CODE (TREE_TYPE (value)) == INTEGER_TYPE && overflow > 0)
{
- if (TREE_CODE (TREE_TYPE (value)) == INTEGER_TYPE && overflow > 0)
+ warning_at (token->location, OPT_Woverflow,
+ "integer literal exceeds range of %qT type",
+ long_long_unsigned_type_node);
+ }
+ else
+ {
+ if (overflow > 0)
+ warning_at (token->location, OPT_Woverflow,
+ "floating literal exceeds range of %qT type",
+ long_double_type_node);
+ else if (overflow < 0)
warning_at (token->location, OPT_Woverflow,
- "integer literal exceeds range of %qT type",
-
Add CFLAGS_FOR_TARGET to Ada OS Constant Extraction Process
Hi When building Ada for RTEMS, you need to pass in the CFLAGS_FOR_TARGET to see OS specific .h files. This was already done for the RTS but needed to be added to the process which extracts value settings from the .h files. This patch is against 4.9. OK to apply to 4.8, 4.9, and head assuming it applies cleanly? 2015-02-10 Joel Sherrill * gcc-interface/Makefile.in: Add CFLAGS_TO_TARGET to OSCONS_CPP and OSCONS_EXTRACT. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 2015-02-10 Joel Sherrill * gcc-interface/Makefile.in: Add CFLAGS_TO_TARGET to OSCONS_CPP and OSCONS_EXTRACT. Index: gcc/ada/gcc-interface/Makefile.in === --- gcc/ada/gcc-interface/Makefile.in (revision 220002) +++ gcc/ada/gcc-interface/Makefile.in (working copy) @@ -115,7 +115,7 @@ # Pretend that _Unwind_GetIPInfo is available for the target by default. This # should be autodetected during the configuration of libada and passed down to # here, but we need something for --disable-libada and hope for the best. -GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) \ +GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) \ -fexceptions -DIN_RTS -DHAVE_GETIPINFO ALL_ADAFLAGS = $(CFLAGS) $(ADA_CFLAGS) $(ADAFLAGS) THREAD_KIND = native @@ -2748,9 +2748,9 @@ # for running it from $(RTSDIR) OSCONS_CC=`echo "$(GCC_FOR_TARGET)" \ | sed -e 's^\./xgcc^../../xgcc^' -e 's^-B./^-B../../^'` -OSCONS_CPP=$(OSCONS_CC) $(GNATLIBCFLAGS) -E -C \ +OSCONS_CPP=$(OSCONS_CC) $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) -E -C \ -DTARGET=\"$(target)\" $(fsrcpfx)ada/s-oscons-tmplt.c > s-oscons-tmplt.i -OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS) -S s-oscons-tmplt.i +OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) -S s-oscons-tmplt.i endif ./bldtools/oscons/xoscons: xoscons.adb xutil.ads xutil.adb
[doc, committed] fix typos in extended asm section
I've checked in this patch to fix a couple more typos in the extended
asm documentation, as noted by David.
-Sandra
2015-02-10 Sandra Loosemore
gcc/
* doc/extend.texi (Extended Asm): Fix typos.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 220598)
+++ gcc/doc/extend.texi (working copy)
@@ -7063,7 +7063,7 @@ within the same @code{asm} statement can
When not using an @var{asmSymbolicName}, use the (zero-based) position
of the operand
in the list of operands in the assembler template. For example if there are
-two output opeerands and three inputs,
+two output operands and three inputs,
use @samp{%2} in the template to refer to the first input operand,
@samp{%3} for the second, and @samp{%4} for the third.
@@ -7099,7 +7099,7 @@ consecutive colons where the output oper
@example
__asm__ ("some instructions"
: /* No outputs. */
- : "r" (Offset / 8);
+ : "r" (Offset / 8));
@end example
@strong{Warning:} Do @emph{not} modify the contents of input-only operands
Re: [PATCH, rs6000, testsuite] Changes for unaligned vector load/store support on POWER8
Hi David,
Sorry I haven't gotten back to this sooner. I've tried to address your
comments about the previous patch. Please let me know if I'm off base.
Test results are the same as previously.
Thanks,
Bill
[gcc]
2015-02-10 Bill Schmidt
* config/rs6000/rs6000.c (rs6000_option_override_internal): For
VSX + POWER8, enable TARGET_ALLOW_MOVMISALIGN and
TARGET_EFFICIENT_UNALIGNED_VSX if not selected by command line
option.
(rs6000_builtin_mask_for_load): Return 0 for targets with
efficient unaligned VSX accesses so that the vectorizer will use
direct unaligned loads.
(rs6000_builtin_support_vector_misalignment): Always return true
for targets with efficient unaligned VSX accesses.
(rs6000_builtin_vectorization_cost): Cost of unaligned loads and
stores on targets with efficient unaligned VSX accesses is almost
always the same as the cost of an aligned load or store, so model
it that way.
* config/rs6000/rs6000.opt (mefficient-unaligned-vector): New
undocumented option.
[gcc/testsuite]
2015-02-10 Bill Schmidt
* gcc.dg/vect/bb-slp-24.c: Exclude test for POWER8.
* gcc.dg/vect/bb-slp-25.c: Likewise.
* gcc.dg/vect/bb-slp-29.c: Likewise.
* gcc.dg/vect/bb-slp-32.c: Replace vect_no_align with
vect_no_align && { ! vect_hw_misalign }.
* gcc.dg/vect/bb-slp-9.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-slp-33.c: Exclude test for
vect_hw_misalign.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: Adjust tests to
account for POWER8, where peeling for alignment is not needed.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c: Replace
vect_no_align with vect_no_align && { ! vect_hw_misalign }.
* gcc.dg.vect.if-cvt-stores-vect-ifcvt-18.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6-global.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6.c: Likewise.
* gcc.dg/vect/no-vfa-vect-43.c: Likewise.
* gcc.dg/vect/no-vfa-vect-57.c: Likewise.
* gcc.dg/vect/no-vfa-vect-61.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-1.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-2.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-3.c: Likewise.
* gcc.dg/vect/pr16105.c: Likewise.
* gcc.dg/vect/pr20122.c: Likewise.
* gcc.dg/vect/pr33804.c: Likewise.
* gcc.dg/vect/pr33953.c: Likewise.
* gcc.dg/vect/pr56787.c: Likewise.
* gcc.dg/vect/pr58508.c: Likewise.
* gcc.dg/vect/slp-25.c: Likewise.
* gcc.dg/vect/vect-105-bit-array.c: Likewise.
* gcc.dg/vect/vect-105.c: Likewise.
* gcc.dg/vect/vect-27.c: Likewise.
* gcc.dg/vect/vect-29.c: Likewise.
* gcc.dg/vect/vect-33.c: Exclude unaligned access test for
POWER8.
* gcc.dg/vect/vect-42.c: Replace vect_no_align with vect_no_align
&& { ! vect_hw_misalign }.
* gcc.dg/vect/vect-44.c: Likewise.
* gcc.dg/vect/vect-48.c: Likewise.
* gcc.dg/vect/vect-50.c: Likewise.
* gcc.dg/vect/vect-52.c: Likewise.
* gcc.dg/vect/vect-56.c: Likewise.
* gcc.dg/vect/vect-60.c: Likewise.
* gcc.dg/vect/vect-72.c: Likewise.
* gcc.dg/vect/vect-75-big-array.c: Likewise.
* gcc.dg/vect/vect-75.c: Likewise.
* gcc.dg/vect/vect-77-alignchecks.c: Likewise.
* gcc.dg/vect/vect-77-global.c: Likewise.
* gcc.dg/vect/vect-78-alignchecks.c: Likewise.
* gcc.dg/vect/vect-78-global.c: Likewise.
* gcc.dg/vect/vect-93.c: Likewise.
* gcc.dg/vect/vect-95.c: Likewise.
* gcc.dg/vect/vect-96.c: Likewise.
* gcc.dg/vect/vect-cond-1.c: Likewise.
* gcc.dg/vect/vect-cond-3.c: Likewise.
* gcc.dg/vect/vect-cond-4.c: Likewise.
* gcc.dg/vect/vect-cselim-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-3.c: Likewise.
* gcc.dg/vect/vect-multitypes-4.c: Likewise.
* gcc.dg/vect/vect-multitypes-6.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-1.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-2.c: Likewise.
* gcc.dg/vect/vect-outer-3a-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-3a.c: Likewise.
* gcc.dg/vect/vect-outer-5.c: Likewise.
* gcc.dg/vect/vect-outer-fir-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb.c: Likewise.
* gcc.dg/vect/vect-outer-fir.c: Likewise.
* gcc.dg/vect/vect-peel-3.c: Likewise.
* gcc.dg/vect/vect-peel-4.c: Likewise.
* gcc.dg/vect/vect-pre-interact.c: Likewise.
* gcc.target/powerpc/vsx-vectorize-2.c: Exclude test for POWER8.
* gcc.target/powerpc/vsx-vectorize-4.c: Likewise.
* g
[doc, committed] symbol rename pragmas
I've committed the attached patch on behalf of David Wohlferd, who has
no commit access. It was originally proposed here:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01365.html
After reviewing that thread, I think the change is conservatively
correct, and since it's a partial revert of one of David's own previous
patches no further approval should be needed to check it in.
-Sandra
2015-02-10 David Wohlferd
gcc/
* doc/extend.texi (Symbol-Renaming Pragmas): Restore (slightly
modified) reference to Solaris.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 220602)
+++ gcc/doc/extend.texi (working copy)
@@ -17604,8 +17604,10 @@ adding a call to the @code{.init} sectio
@subsection Symbol-Renaming Pragmas
GCC supports a @code{#pragma} directive that changes the name used in
-assembly for a given declaration. This effect can also be achieved
-using the asm labels extension (@pxref{Asm Labels}).
+assembly for a given declaration. While this pragma is supported on all
+platforms, it is intended primarily to provide compatibility with the
+Solaris system headers. This effect can also be achieved using the asm
+labels extension (@pxref{Asm Labels}).
@table @code
@item redefine_extname @var{oldname} @var{newname}
[doc, committed] small grammar error fix
This fix was suggested by David Wohlferd here: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00377.html I've checked it in as obvious. -Sandra 2015-02-10 David Wohlferd Sandra Loosemore gcc/ * doc/extend.texi (Loop-Specific Pragmas): Fix grammar error. 2015-02-10 David Wohlferd Sandra Loosemore gcc/ * doc/extend.texi (Loop-Specific Pragmas): Fix grammar error.
[doc, committed] tidy docs for -masm=dialect
This is another small documentation fix suggested by David Wohlferd here:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00377.html
I don't think adding cross-references is controversial, so I've checked
in this version.
-Sandra
2015-02-10 David Wohlferd
Sandra Loosemore
gcc/
* doc/invoke.texi (x86 Options [-masm=dialect]): Add cross-references
to inline asm. List dialects in proper order.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 220603)
+++ gcc/doc/invoke.texi (working copy)
@@ -21946,8 +21946,10 @@ functional units well, resulting in unst
@item -masm=@var{dialect}
@opindex masm=@var{dialect}
-Output assembly instructions using selected @var{dialect}. Supported
-choices are @samp{intel} or @samp{att} (the default). Darwin does
+Output assembly instructions using selected @var{dialect}. Also affects
+which dialect is used for basic @code{asm} (@pxref{Basic Asm}) and
+extended @code{asm} (@pxref{Extended Asm}). Supported choices (in dialect
+order) are @samp{att} or @samp{intel}. The default is @samp{att}. Darwin does
not support @samp{intel}.
@item -mieee-fp
RE: [PATCH, FT32] initial support
(Thanks to everyone for the review. I have reworked the submission as suggested. This does build cleanly with "--enable-werror-always") FT32 is a new high performance 32-bit RISC core developed by FTDI for embedded applications. Support for FT32 has already been added to binutils. This patch adds FT32 support to gcc. Please can someone review it, and if appropriate commit it, as I do not have write access to the tree. The FSF have acknowledged receipt of FTDI's copyright assignment papers. Thanks very much. ChangeLog entry: 2014-02-11 James Bowman * configure.ac: FT32 target added * libgcc/config.host: FT32 target added * gcc/config/ft32/: FT32 target added * libgcc/config/ft32/: FT32 target added * gcc/doc/install.texi, invoke.texi, md.texi: FT32 details added * gcc/doc/contrib.texi, MAINTAINERS: self added * contrib/config-list.mk: FT32 target added * configure: Regenerated -- James Bowman FTDI Open Source Liaison gcc-ft32.txt.gz Description: gcc-ft32.txt.gz
Re: [patch, libgfortran] Bug 57822 - I/O: "(g0)" wrongly prints "E+0000"
On 02/08/2015 05:10 PM, Jerry DeLisle wrote: The attached patch fixes this by checking for the case when we are doing g0 editing and the exponent is 0. Regression tested on X86-64. For the larger kinds, we are on a different code path out of necessity, so we need to address this corner case. I committed this followup to correct an omission I made. SendingChangeLog Sendingio/write_float.def Transmitting file data .. Committed revision 220606. 2015-02-10 Jerry DeLisle PR libgfortran/57822 * io/write_float.def (output_float): Apply fix of previous patch to correctly calculate the exponent number of digits and take care of wide character output.
[PATCH] Implement boehm-gc for AARCH64:ILP32
Hi, This is a simple patch which allows all of the boehm-gc testsuite that is included with GCC to pass for AARCH64:ILP32. Basically we need to set CPP_WORDSZ to 32 and the alignment to 4 so we detect pointers correctly. OK for GCC? Bootstrapped and tested for aarch64-linux-gnu with no regressions and many libjava testcases now pass. OK for boehm-gc upstream? I don't have write access to upstream sources though, if approved there please apply it also. Thanks, Andrew Pinski GCC ChangeLog: * include/private/gcconfig.h (CPP_WORDSZ): Correct for AARCH64:ILP32. (ALIGNMENT): Correct for AARCH64:ILP32. commit 7d15d08c61991c3f7fea822fb567106dde83a166 Author: Andrew Pinski Date: Wed Feb 11 02:35:45 2015 + Fix boehm-gc for AARCH64:ILP32 * include/private/gcconfig.h (CPP_WORDSZ): Correct for AARCH64:ILP32. (ALIGNMENT): Correct for AARCH64:ILP32. diff --git a/boehm-gc/include/private/gcconfig.h b/boehm-gc/include/private/gcconfig.h index 7e081d9..049e24c 100644 --- a/boehm-gc/include/private/gcconfig.h +++ b/boehm-gc/include/private/gcconfig.h @@ -1854,9 +1854,14 @@ # endif # ifdef AARCH64 -# define CPP_WORDSZ 64 # define MACH_TYPE "AARCH64" -# define ALIGNMENT 8 +# ifdef __ILP32__ +# define CPP_WORDSZ 32 +# define ALIGNMENT 4 +# else +# define CPP_WORDSZ 64 +# define ALIGNMENT 8 +# endif # ifndef HBLKSIZE # define HBLKSIZE 4096 # endif diff --git a/include/private/gcconfig.h b/include/private/gcconfig.h index aa80d53..989a734 100644 --- a/include/private/gcconfig.h +++ b/include/private/gcconfig.h @@ -2020,9 +2020,14 @@ # endif # ifdef AARCH64 -# define CPP_WORDSZ 64 # define MACH_TYPE "AARCH64" -# define ALIGNMENT 8 +# ifdef __ILP32__ +# define CPP_WORDSZ 32 +# define ALIGNMENT 4 +# else +# define CPP_WORDSZ 64 +# define ALIGNMENT 8 +# endif # ifndef HBLKSIZE # define HBLKSIZE 4096 # endif
Re: [PATCH 1/2, combine] Try REG_EQUAL for nonzero_bits
On 02/09/15 19:19, Thomas Preud'homme wrote: From: Andrew Pinski [mailto:pins...@gmail.com] Sent: Tuesday, February 10, 2015 9:57 AM +#ifdef SHORT_IMMEDIATES_SIGN_EXTEND +/* If MODE has a precision lower than PREC and SRC is a non-negative constant + that would appear negative in MODE, sign-extend SRC for use in nonzero_bits + because some machines (maybe most) will actually do the sign- extension and + this is the conservative approach. + + ??? For 2.5, try to tighten up the MD files in this regard instead of this + kludge. */ I don't know if this has been mentioned and even though you are just copying a comment from below but would it make sense to look fixing what the comment says we should look at after GCC 2.5 (which was over 20 years ago)? Or maybe just remove the comment if it no longer applies. Actually this bit seems unnecessary as there is already some logic in nonzero_bits1 for the CONST_INT case. So I guess the code can be removed and the comment be moved there at the very least but I'd prefer people from one of the affected target to test it. Looking for backend that define SHORT_IMMEDIATES_SIGN_EXTEND, that would be someone interested in alpha, frv, lm32, m32r, mep, mips, rs6000, rx, sh, tilegx or tilepro. FWIW, I went back into the old gcc development archives for 1993 and couldn't find any reference/justification for this patch. So no help in understanding the precise issue from the old archives. Given the rs6000 is affected, one could do before/after tests natively in the gcc farm to ensure that removing that code doesn't change the generated code across a bootstrap. That's probably how I'd approach gathering some data about whether or not the comment/code is still appropriate/needed. jeff
Fix i386 wrong code issues introduced by the local flag fix
Hi,
this segfault in c-c++-common/torture/builtin-arith-overflow-12.c is caused
by fact that we split ltrans units separating call to alias of local function
and its target. Because LTO partitioning turns aliases in boundaries into
normal symbols, we end up checking alias for can_change_signature_p that is
false.
This is just a manifestation of deeper problem that we do not represent aliases
between external symbols. Doing so is also needed to get address equality and
alias analysis right among other details. While I was aware of this issue, I
managed to delay proper fix until wrong code issues came.
This patch teaches middle-end about external aliases it
1) makes symbol_table::remove_unreachable_nodes to not remove aliases from
boundaries
2) teach lto-cgraph to do right thing about streaming: insert alias
targets to the boundary and stream the references
Same thing is also done for thunks as for good part of IPA optimizers these
are similar to aliases.
I also removed cgrpah_node::global_info that is unused and secured
cgraph_node::local_info and cgraph_node::rtl_info for aliases.
Bootstrapped/regtested x86_64-linux, will commit it after lto-bootstrapping.
Honza
PR ipa/65005
* ipa-visibility.c (cgraph_node::non_local_p): Turn into static
function.
* symtab.c (symtab_node::verify_base): Remove check that non-definitions
have no comdat group.
* lto-cgraph.c (lto_output_node): Always output thunk and alias info.
(lto_output_varpool_node): Always output alias info.
(output_refs): Output refs of boundary aliases, too.
(compute_ltrans_boundary): Add alias and thunk target into boundaries.
(output_symtab): Output call eges in thunks in boundary.
(get_alias_symbol): Remove.
(input_node, input_varpool_node): Do not special case weakrefs.
* ipa.c (symbol_table::remove_unreachable_nodes): Do not remove
alias and thunks targets in the boundary; do not take removed symbols
from their comdat groups.
* cgraph.c (cgraph_node::local_info): Look through aliases and thunks.
(cgraph_node::global_info): Remove.
(cgraph_node::rtl_info): Look through aliases and thunks.
* cgrpah.h (global_info): Remove.
(non_local_p): Remove.
Index: ipa-visibility.c
===
--- ipa-visibility.c(revision 220606)
+++ ipa-visibility.c(working copy)
@@ -101,8 +101,8 @@ along with GCC; see the file COPYING3.
/* Return true when NODE can not be local. Worker for cgraph_local_node_p. */
-bool
-cgraph_node::non_local_p (struct cgraph_node *node, void *data
ATTRIBUTE_UNUSED)
+static bool
+non_local_p (struct cgraph_node *node, void *data ATTRIBUTE_UNUSED)
{
return !(node->only_called_directly_or_aliased_p ()
/* i386 would need update to output thunk with locak calling
@@ -124,7 +124,7 @@ cgraph_node::local_p (void)
if (n->thunk.thunk_p)
return n->callees->callee->local_p ();
- return !n->call_for_symbol_thunks_and_aliases (cgraph_node::non_local_p,
+ return !n->call_for_symbol_thunks_and_aliases (non_local_p,
NULL, true);
}
Index: lto-cgraph.c
===
--- lto-cgraph.c(revision 220606)
+++ lto-cgraph.c(working copy)
@@ -432,14 +432,13 @@ lto_output_node (struct lto_simple_outpu
struct cgraph_node *clone_of, *ultimate_clone_of;
ipa_opt_pass_d *pass;
int i;
- bool alias_p;
const char *comdat;
const char *section;
tree group;
boundary_p = !lto_symtab_encoder_in_partition_p (encoder, node);
- if (node->analyzed && !boundary_p)
+ if (node->analyzed && (!boundary_p || node->alias || node->thunk.thunk_p))
tag = LTO_symtab_analyzed_node;
else
tag = LTO_symtab_unavail_node;
@@ -565,14 +564,7 @@ lto_output_node (struct lto_simple_outpu
|| referenced_from_other_partition_p (node, encoder)), 1);
bp_pack_value (&bp, node->lowered, 1);
bp_pack_value (&bp, in_other_partition, 1);
- /* Real aliases in a boundary become non-aliases. However we still stream
- alias info on weakrefs.
- TODO: We lose a bit of information here - when we know that variable is
- defined in other unit, we may use the info on aliases to resolve
- symbol1 != symbol2 type tests that we can do only for locally defined
objects
- otherwise. */
- alias_p = node->alias && (!boundary_p || node->weakref);
- bp_pack_value (&bp, alias_p, 1);
+ bp_pack_value (&bp, node->alias, 1);
bp_pack_value (&bp, node->weakref, 1);
bp_pack_value (&bp, node->frequency, 2);
bp_pack_value (&bp, node->only_called_at_startup, 1);
@@ -581,14 +573,14 @@ lto_output_node (struct lto_simple_outpu
bp_pack_value (&bp, node->calls_comdat_local, 1);
bp_pack_value (&bp, node->icf_mer
RE: [PATCH 1/2, combine] Try REG_EQUAL for nonzero_bits
> From: Jeff Law [mailto:l...@redhat.com] > Sent: Wednesday, February 11, 2015 2:04 PM > > Given the rs6000 is affected, one could do before/after tests natively > in the gcc farm to ensure that removing that code doesn't change the > generated code across a bootstrap. Wouldn't that only tell whether the macro can stay undefined for rs6000? MD files for rs6000 could have been tighten since then but not others backend's MD files. > > That's probably how I'd approach gathering some data about whether or > not the comment/code is still appropriate/needed. Do people with svn access automatically have access to the GCC farm or does one needs to request such access? Best regards, Thomas
Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing
On 02/03/15 05:23, Joseph Myers wrote: +&& TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1)) +&& TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE (@1)) +&& TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))) + (convert (bit_and (inner_op @0 @1) (convert @3)) I still don't think this is safe. Suppose @0 and @1 are -128 in type int8_t and @3 is 128 in a wider type and the operation is AND. Then the original expression has result 128. But if you convert @3 to int8_t you get -128 and this would result in -128 from the simplified expression. Looking at this again, @3 is being converted to the wrong type, plain and simple. I should never write code while heavily medicated. I suspect that combined with trying to work around the genmatch bug Richi just fixed sent me down a totally wrong path. I think the way to go is to always convert the inner operands to an unsigned type. In fact, everything except the outer convert should be using an unsigned type of the same size/precision as @0's type. The outer convert should, of course, be the final type. That avoids all the concerns about sign bit propagation from the narrow type into the wider final type. Application of this pattern (and the one I posted for 47477) is a concern for targets that don't do sub-word arithmetic/logicals. But I just did a sniff test of one such target (v850-elf because it was handy) and I couldn't spot a change in the end code using both the 47477 patch and my WIP patch for this BZ. jeff
Re: [PATCH 1/2, combine] Try REG_EQUAL for nonzero_bits
On 02/10/15 23:42, Thomas Preud'homme wrote: From: Jeff Law [mailto:l...@redhat.com] Sent: Wednesday, February 11, 2015 2:04 PM Given the rs6000 is affected, one could do before/after tests natively in the gcc farm to ensure that removing that code doesn't change the generated code across a bootstrap. Wouldn't that only tell whether the macro can stay undefined for rs6000? MD files for rs6000 could have been tighten since then but not others backend's MD files. It's certainly possible, but unlikely. I would virtually guarantee that lm32, rx, & mep, rx, tilegx, tilegxpro were never updated. So another approach would be to build some cross tools and verify that they generate the same code before/after ripping that code out. That's probably how I'd approach gathering some data about whether or not the comment/code is still appropriate/needed. Do people with svn access automatically have access to the GCC farm or does one needs to request such access? You have to request access. IIRC, there's a big ppc64 machine in there. https://gcc.gnu.org/wiki/CompileFarm Jeff
RE: [PATCH 1/2, combine] Try REG_EQUAL for nonzero_bits
> From: Jeff Law [mailto:l...@redhat.com] > Sent: Wednesday, February 11, 2015 2:49 PM > > > > Wouldn't that only tell whether the macro can stay undefined for > rs6000? > > MD files for rs6000 could have been tighten since then but not others > > backend's MD files. > It's certainly possible, but unlikely. > > I would virtually guarantee that lm32, rx, & mep, rx, tilegx, tilegxpro > were never updated. Perfect, I was hoping that one of these others might not have changed much. > > So another approach would be to build some cross tools and verify that > they generate the same code before/after ripping that code out. Of course both approaches are not exclusive. I'll try to test with *both* rs6000 bootstrap and with a cross-compiler for one of these targets. > You have to request access. IIRC, there's a big ppc64 machine in there. Will do. Best regards, Thomas
Re: Add CFLAGS_FOR_TARGET to Ada OS Constant Extraction Process
> When building Ada for RTEMS, you need to pass in the CFLAGS_FOR_TARGET > to see OS specific .h files. This was already done for the RTS but needed to > be added to the process which extracts value settings from the .h files. > > This patch is against 4.9. OK to apply to 4.8, 4.9, and head assuming it > applies cleanly? This patch won't apply cleanly for head I think, where I suspect at least part of your patch is OBE. It would be better to first have a patch for trunk (if still relevant) and then backport it to the other branches, since changes on trunk have already been done in a different way to address at least partly this issue (e.g. use of GNATLIBCFLAGS_FOR_C in OSCONS_CPP, different computation of OSCONS_CC). Arno
