[PATCH] Testcase for PR54000
The testcase in PR54000 appears to be fixed with GCC 5 thus the following
adds a testcase for it, improving IVOPTs dumping to make it more likely
stable.
Tested on x86_64/i686, applied.
Richard.
2015-02-09 Richard Biener rguent...@suse.de
PR tree-optimization/54000
* tree-ssa-looo-ivopts.c: Include tree-vectorizer.h.
(struct ivopts_data): Add loop_loc member.
(tree_ssa_iv_optimize_loop): Dump loop location.
(create_new_ivs): Likewise, also dump number of IVs generated.
* g++.dg/tree-ssa/ivopts-3.C: New testcase.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 220346)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -138,6 +138,7 @@ along with GCC; see the file COPYING3.
#include tree-ssa-propagate.h
#include tree-ssa-address.h
#include builtins.h
+#include tree-vectorizer.h
/* FIXME: Expressions are expanded to RTL in this pass to determine the
cost of different addressing modes. This should be moved to a TBD
@@ -318,6 +319,7 @@ struct ivopts_data
{
/* The currently optimized loop. */
struct loop *current_loop;
+ source_location loop_loc;
/* Numbers of iterations for all exits of the current loop. */
hash_mapedge, tree_niter_desc * *niters;
@@ -6336,7 +6338,12 @@ create_new_ivs (struct ivopts_data *data
if (dump_file (dump_flags TDF_DETAILS))
{
- fprintf (dump_file, \nSelected IV set: \n);
+ fprintf (dump_file, Selected IV set for loop %d,
+ data-current_loop-num);
+ if (data-loop_loc != UNKNOWN_LOCATION)
+ fprintf (dump_file, at %s:%d, LOCATION_FILE (data-loop_loc),
+LOCATION_LINE (data-loop_loc));
+ fprintf (dump_file, , %ld IVs:\n, bitmap_count_bits (set-cands));
EXECUTE_IF_SET_IN_BITMAP (set-cands, 0, i, bi)
{
cand = iv_cand (data, i);
@@ -6939,11 +6946,16 @@ tree_ssa_iv_optimize_loop (struct ivopts
gcc_assert (!data-niters);
data-current_loop = loop;
+ data-loop_loc = find_loop_location (loop);
data-speed = optimize_loop_for_speed_p (loop);
if (dump_file (dump_flags TDF_DETAILS))
{
- fprintf (dump_file, Processing loop %d\n, loop-num);
+ fprintf (dump_file, Processing loop %d, loop-num);
+ if (data-loop_loc != UNKNOWN_LOCATION)
+ fprintf (dump_file, at %s:%d, LOCATION_FILE (data-loop_loc),
+LOCATION_LINE (data-loop_loc));
+ fprintf (dump_file, \n);
if (exit)
{
Index: gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C
===
--- gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C(revision 0)
+++ gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C(working copy)
@@ -0,0 +1,76 @@
+// { dg-do compile }
+// { dg-options -O2 -fdump-tree-ivopts-details }
+
+class MinimalVec3
+{
+protected:
+ double coords[3];
+
+public:
+
+ MinimalVec3( ) {
+for ( int i = 0; i 3; ++i )
+ coords[i] = 0.;
+ }
+
+ inline const double operator[] ( int I ) const {
+return coords[I];
+ }
+};
+
+class MinimalVector
+{
+protected:
+ double *_pData;
+ double stuff;
+
+public:
+ explicit MinimalVector ( int length ) {
+_pData = new double[length];
+for (int i = 0; i length; ++i) _pData[i] = 0.;
+ }
+
+ inline double operator[] ( int I ) {
+return _pData[I];
+ }
+
+ inline const double operator[] ( int I ) const {
+return _pData[I];
+ }
+};
+
+
+int main ( int , char** ) {
+int w = ( 1 7 )+1;
+int wsqr = w*w;
+int wcub = w*w*w;
+
+MinimalVec3 * rows[9];
+for ( int i = 0; i 9; ++i ) {
+ rows[i] = new MinimalVec3[wcub];
+}
+
+MinimalVector img ( wcub ), res ( wcub );
+
+for ( int c = 0; c 1000; ++c ) {
+
+ for ( int i = 1; i w-1; ++i )
+for ( int j = 0; j 3; ++j ) {
+
+ for ( int k = 1; k w - 1; ++k )
+for ( int l = 0; l 3; ++l ) {
+
+ for ( int m = 1; m w - 1; ++m )
+for ( int n = 0; n 3; ++n )
+ res[i*wsqr + k*w + m] += img[( i + j - 1 ) *wsqr + ( k + l -
1 ) *w + m + n - 1] * rows[j*3 + l][i*wsqr + k*w + m][n];
+
+}
+}
+}
+return 0;
+}
+
+// Verify that on x86_64 and i?86 we use a single IV for the innermost loop
+
+// { dg-final { scan-tree-dump Selected IV set for loop \[0-9\]* at \[^
\]*:64, 1 IVs ivopts { target x86_64-*-* i?86-*-* } } }
+// { dg-final { cleanup-tree-dump ivopts } }
Re: [PATCH] Implement libffi for AARCH64:ILP32
On 09/02/15 08:40, Andrew Pinski wrote: For ILP32, we need to use long long types for ffi_arg and ffi_sarg. And then we need to fix up the closure code to load cif, fn, and user_data by 32bit instead of 64bits as they are stored as pointers in C code. Would it make more sense to use int64_t rather than long long? Andrew.
Re: [PATCH] Fix PR64764
On Thu, 5 Feb 2015, Tom de Vries wrote:
On 26-01-15 15:47, Richard Biener wrote:
Index: gcc/testsuite/gcc.dg/uninit-19.c
===
--- gcc/testsuite/gcc.dg/uninit-19.c(revision 0)
+++ gcc/testsuite/gcc.dg/uninit-19.c(working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options -O -Wuninitialized } */
+
+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]; /* { dg-warning may be used uninitialized } */
+}
+
+void
+fn2 ()
+{
+ float *n;
+ if (l 6)
+n = c + m;
+ fn1 (l, d, e, g, i, h, k, n);
+}
Hi Richard,
this new test fails with -fpic, because fn1 is not inlined.
Adding static to fn1 allows it to pass both with and without -fpic. But that
change might affect whether it still serves as a regression test for this PR,
I'm not sure.
Another way to fix this could be to use the warning line number 22 instead 13
for fpic.
Either way is fine with me.
Thanks,
Richard.
[PATCH] PR64979: S/390: Fix setup of overflow area pointer in va_start
Hi,
the attached patch fixes a critical problem in the va_start expansion
code in the S/390 backend. The problem exists since GCC 4.0.
Ok to commit to 4.9 branch and mainline?
Bye,
-Andreas-
2015-02-09 Andreas Krebbel andreas.kreb...@de.ibm.com
PR target/64979
* config/s390/s390.c (s390_va_start): Make set up of
__overflow_arg_area unconditional.
2015-02-09 Andreas Krebbel andreas.kreb...@de.ibm.com
PR target/64979
* gcc.dg/pr64979.c: New testcase.
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index bc6223e..ed22d35 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -9697,23 +9697,19 @@ s390_va_start (tree valist, rtx nextarg
ATTRIBUTE_UNUSED)
}
/* Find the overflow area. */
- if (n_gpr + cfun-va_list_gpr_size GP_ARG_NUM_REG
- || n_fpr + cfun-va_list_fpr_size FP_ARG_NUM_REG)
-{
- t = make_tree (TREE_TYPE (ovf), virtual_incoming_args_rtx);
+ t = make_tree (TREE_TYPE (ovf), virtual_incoming_args_rtx);
- off = INTVAL (crtl-args.arg_offset_rtx);
- off = off 0 ? 0 : off;
- if (TARGET_DEBUG_ARG)
- fprintf (stderr, va_start: n_gpr = %d, n_fpr = %d off %d\n,
-(int)n_gpr, (int)n_fpr, off);
+ off = INTVAL (crtl-args.arg_offset_rtx);
+ off = off 0 ? 0 : off;
+ if (TARGET_DEBUG_ARG)
+fprintf (stderr, va_start: n_gpr = %d, n_fpr = %d off %d\n,
+(int)n_gpr, (int)n_fpr, off);
- t = fold_build_pointer_plus_hwi (t, off);
+ t = fold_build_pointer_plus_hwi (t, off);
- t = build2 (MODIFY_EXPR, TREE_TYPE (ovf), ovf, t);
- TREE_SIDE_EFFECTS (t) = 1;
- expand_expr (t, const0_rtx, VOIDmode, EXPAND_NORMAL);
-}
+ t = build2 (MODIFY_EXPR, TREE_TYPE (ovf), ovf, t);
+ TREE_SIDE_EFFECTS (t) = 1;
+ expand_expr (t, const0_rtx, VOIDmode, EXPAND_NORMAL);
/* Find the register save area. */
if ((cfun-va_list_gpr_size n_gpr GP_ARG_NUM_REG)
diff --git a/gcc/testsuite/gcc.dg/pr64979.c b/gcc/testsuite/gcc.dg/pr64979.c
new file mode 100644
index 000..9c715c9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr64979.c
@@ -0,0 +1,40 @@
+/* PR target/64979 */
+
+/* { dg-do run } */
+/* { dg-options -O1 } */
+
+#include stdarg.h
+
+extern void abort (void);
+
+void __attribute__((noinline))
+bar(int msgno, va_list *args)
+{
+ int i;
+
+ for (i = 0; i 10; i++)
+if (i != va_arg(*args, int))
+ abort ();
+}
+
+
+void __attribute__((noinline))
+foo(int msgno, ...)
+{
+ va_list args;
+ int nargs;
+
+ va_start(args, msgno);
+ nargs = va_arg(args, int);
+ bar(msgno, (va_list *)((nargs == 0) ? ((void *)0) : args));
+}
+
+
+int main(void)
+{
+ foo(100 /* msgno */,
+ 1 /* nargs - part of vararg list */,
+ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9);
+
+ return 0;
+}
Re: [PATCH][TREE] Match.pd compare-and-not patterns.
On February 9, 2015 4:46:34 PM CET, Alex Velenko alex.vele...@arm.com wrote:
Hi,
This patch adds match.pd compare-and-not simplication patterns.
This is a generic transformation reducing variable accesses.
Done full regression run on arm-none-eabi, aarch64-none-elf,
aarch64_be-none-elf and bootstrapped on x86.
Is patch ok?
2015-02-09 Alex Velenko alex.vele...@arm.com
gcc/
* match.pd ((X Y) == X): New pattern.
((X Y) == Y): New pattern.
gcc/testsuite
* gcc.dg/match-and-not.c: New testcase.
diff --git a/gcc/match.pd b/gcc/match.pd
index 81c4ee6..b4fa6e9 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -377,6 +377,24 @@ along with GCC; see the file COPYING3. If not see
TYPE_PRECISION (TREE_TYPE (@1)) == 1)
(le @0 @1)))
+/* If arg1 and arg2 are integers
+ (X Y) == X - (X ~Y) == 0.
+ (X Y) == Y - (~X Y) == 0. */
+(simplify
+ (eq (bit_and @0 @1) @0)
+ (if ((INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ !(CONSTANT_CLASS_P (@0))
+ (INTEGRAL_TYPE_P (TREE_TYPE (@1)))
+ !(CONSTANT_CLASS_P (@1)))
+ (eq (bit_and @0 (bit_not @1)) { build_zero_cst (TREE_TYPE (@0));
})))
+(simplify
+ (eq (bit_and @0 @1) @1)
You should be able to combine both patterns with using bit_and:c. Also
Isn't it still profitable to do
CST X == X to CST ~X == 0? It
Still makes x single-use.
Note that we may have the reverse transforms somewhere (less operations).
So it's not at all clear to me that this is profitable gimple-wise.
Thoughts?
Richard.
+ (if ((INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ !(CONSTANT_CLASS_P (@0))
+ (INTEGRAL_TYPE_P (TREE_TYPE (@1)))
+ !(CONSTANT_CLASS_P (@1)))
+ (eq (bit_and (bit_not @0) @1) { build_zero_cst (TREE_TYPE (@1));
})))
+
/* ~~x - x */
(simplify
(bit_not (bit_not @0))
diff --git a/gcc/testsuite/gcc.dg/match-and-not.c
b/gcc/testsuite/gcc.dg/match-and-not.c
new file mode 100644
index 000..62d993e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/match-and-not.c
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+/* { dg-options -O1 -fdump-tree-original } */
+
+extern void abort (void);
+
+/* (x y) == x - (x ~y) == 0. */
+int __attribute__ ((noinline))
+f1 (int x, int y)
+{
+ return (x y) == x;
+}
+
+int __attribute__ ((noinline))
+f2 (int x, int y)
+{
+ return (x y) == y;
+}
+
+int
+main ()
+{
+ if (!f1 (21, 85))
+abort ();
+
+ if (!f2 (85, 84))
+abort ();
+
+ return 0;
+}
+
+/* { dg-final { scan-tree-dump-times \\(~y x\\) == 0 1 original
} } */
+/* { dg-final { scan-tree-dump-times \\(~x y\\) == 0 1 original
} } */
+/* { dg-final { cleanup-tree-dump original } } */
Re: [PATCH PR64705]Don't aggressively expand induction variable's base
On February 9, 2015 11:09:49 AM CET, Bin Cheng bin.ch...@arm.com wrote: 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: bb 5: # ci_28 = PHI ci_12(D)(4), ci_17(6) # ivtmp.13_31 = PHI ivtmp.13_25(4), ivtmp.13_27(6) 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 bb 6; else goto bb 7; bb 6: goto bb 5; And it can be improved by this patch as below: bb 5: # steps_28 = PHI steps_12(D)(4), steps_17(6) # iter_29 = PHI iter_15(4), iter_21(6) 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 bb 6; else goto bb 7; bb 6: goto bb 5; 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. Did you extract a testcase for it? Note that the IV step itself may be expanded Too much. 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. But different I presume. So how did you figure it regressed? Thanks, Richard. Bootstrap and test on x86_64 and AArch64, so is it OK? 2015-02-09 Bin Cheng bin.ch...@arm.com 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 bin.ch...@arm.com PR tree-optimization/64705 * gcc.dg/tree-ssa/pr64705.c: New test.
Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME
On Feb 9, 2015, at 7:11 AM, Alex Velenko alex.vele...@arm.com wrote: The following patch makes atomic-op-consume.c XFAIL Is this patch ok? Ok. I’d shorten the comment above the xfail to be exceedingly short: /* PR59448 consume not implemented yet */ The reason is the brain can process this about 8x faster. Also, one can cut and paste the PR part into a web browser directly, or, if you have an electric bugzilla mode for emacs, it will pop right up. */
[PATCH][TREE] Match.pd compare-and-not patterns.
Hi,
This patch adds match.pd compare-and-not simplication patterns.
This is a generic transformation reducing variable accesses.
Done full regression run on arm-none-eabi, aarch64-none-elf,
aarch64_be-none-elf and bootstrapped on x86.
Is patch ok?
2015-02-09 Alex Velenko alex.vele...@arm.com
gcc/
* match.pd ((X Y) == X): New pattern.
((X Y) == Y): New pattern.
gcc/testsuite
* gcc.dg/match-and-not.c: New testcase.
diff --git a/gcc/match.pd b/gcc/match.pd
index 81c4ee6..b4fa6e9 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -377,6 +377,24 @@ along with GCC; see the file COPYING3. If not see
TYPE_PRECISION (TREE_TYPE (@1)) == 1)
(le @0 @1)))
+/* If arg1 and arg2 are integers
+ (X Y) == X - (X ~Y) == 0.
+ (X Y) == Y - (~X Y) == 0. */
+(simplify
+ (eq (bit_and @0 @1) @0)
+ (if ((INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+!(CONSTANT_CLASS_P (@0))
+(INTEGRAL_TYPE_P (TREE_TYPE (@1)))
+!(CONSTANT_CLASS_P (@1)))
+ (eq (bit_and @0 (bit_not @1)) { build_zero_cst (TREE_TYPE (@0)); })))
+(simplify
+ (eq (bit_and @0 @1) @1)
+ (if ((INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+!(CONSTANT_CLASS_P (@0))
+(INTEGRAL_TYPE_P (TREE_TYPE (@1)))
+!(CONSTANT_CLASS_P (@1)))
+ (eq (bit_and (bit_not @0) @1) { build_zero_cst (TREE_TYPE (@1)); })))
+
/* ~~x - x */
(simplify
(bit_not (bit_not @0))
diff --git a/gcc/testsuite/gcc.dg/match-and-not.c
b/gcc/testsuite/gcc.dg/match-and-not.c
new file mode 100644
index 000..62d993e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/match-and-not.c
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+/* { dg-options -O1 -fdump-tree-original } */
+
+extern void abort (void);
+
+/* (x y) == x - (x ~y) == 0. */
+int __attribute__ ((noinline))
+f1 (int x, int y)
+{
+ return (x y) == x;
+}
+
+int __attribute__ ((noinline))
+f2 (int x, int y)
+{
+ return (x y) == y;
+}
+
+int
+main ()
+{
+ if (!f1 (21, 85))
+abort ();
+
+ if (!f2 (85, 84))
+abort ();
+
+ return 0;
+}
+
+/* { dg-final { scan-tree-dump-times \\(~y x\\) == 0 1 original } } */
+/* { dg-final { scan-tree-dump-times \\(~x y\\) == 0 1 original } } */
+/* { dg-final { cleanup-tree-dump original } } */
[SH] Allow reg+disp address modes for atomics
Hi,
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?
Cheers,
Oleg
gcc/ChangeLog:
PR target/64661
* config/sh/sh-protos.h (TARGET_ATOMIC_ANY, TARGET_ATOMIC_STRICT,
TARGET_ATOMIC_SOFT_GUSA, TARGET_ATOMIC_HARD_LLCS,
TARGET_ATOMIC_SOFT_TCB, TARGET_ATOMIC_SOFT_IMASK): Add parentheses.
* config/sh/constraints.md (Ara, Add): New constraints.
* config/sh/sync.md (atomic_mem_operand_0, atomic_mem_operand_1): New
predicates.
(atomic_compare_and_swapmode, atomic_exchangemode): Use
atomic_mem_operand_0. Don't use force_reg on the memory address.
(atomic_compare_and_swapsi_hard): Use atomic_mem_operand_0 predicate and
Sra constraint. Convert to insn_and_split. Add workaround for
PR 64974.
(atomic_compare_and_swapmode_hard): Copy to
atomic_compare_and_swapmode_hard_1. Convert to insn_and_split.
Use atomic_mem_operand_0 predicate.
(atomic_compare_and_swapmode_soft_gusa,
atomic_exchangemode_soft_gusa): Use atomic_mem_operand_0 predicate and
AraAdd constraints.
(atomic_compare_and_swapmode_soft_tcb,
atomic_compare_and_swapmode_soft_imask,
atomic_exchangemode_soft_tcb, atomic_exchangemode_soft_imask): Use
atomic_mem_operand_0 predicate and SraSdd constraints.
(atomic_exchangesi_hard) Use atomic_mem_operand_0 predicate and Sra
constraint.
(atomic_exchangemode_hard): Copy to atomic_exchangemode_hard_1.
Convert to insn_and_split. Use atomic_mem_operand_0 predicate.
(atomic_fetch_fetchop_namemode, atomic_fetch_nandmode,
atomic_fetchop_name_fetchmode):
Use atomic_mem_operand_1. Don't use force_reg on the memory address.
(atomic_fetch_fetchop_namesi_hard, atomic_fetch_notsi_hard,
atomic_fetch_nandsi_hard, atomic_fetchop_name_fetchsi_hard,
atomic_not_fetchsi_hard, atomic_nand_fetchsi_hard): Use
atomic_mem_operand_1 predicate and Sra constraint.
(atomic_fetch_fetchop_namemode_hard): Copy to
atomic_fetch_fetchop_namemode_hard_1. Convert to insn_and_split.
Use atomic_mem_operand_1 predicate.
(atomic_fetchop_namemode_hard): Copy to
atomic_fetchop_namemode_hard_1. Convert to insn_and_split.
Use atomic_mem_operand_1 predicate.
(atomic_fetch_nandmode_hard): Copy to atomic_fetch_nandmode_hard_1.
Convert to insn_and_split. Use atomic_mem_operand_1 predicate.
(atomic_nandmode_hard): Copy to atomic_nandmode_hard_1. Convert to
insn_and_split. Use atomic_mem_operand_1 predicate.
(atomic_fetchop_name_fetchmode_hard): Copy to
atomic_fetchop_name_fetchmode_hard_1. Convert to insn_and_split.
Use atomic_mem_operand_1 predicate.
(atomic_nand_fetchmode_hard): Copy to atomic_nand_fetchmode_hard_1.
Convert to insn_and_split. Use atomic_mem_operand_1 predicate.
(atomic_fetch_notmode_hard, atomic_not_fetchmode_hard): Replace mems
in generated insn with original mem operand before emitting the insn.
(atomic_fetch_fetchop_namemode_soft_gusa,
atomic_fetch_notmode_soft_gusa, atomic_fetch_nandmode_soft_gusa,
atomic_fetchop_name_fetchmode_soft_gusa,
atomic_not_fetchmode_soft_gusa, atomic_nand_fetchmode_soft_gusa):
Use atomic_mem_operand_1 predicate and AraAdd constraints.
(atomic_fetch_fetchop_namemode_soft_tcb,
atomic_fetchop_namemode_soft_tcb, atomic_fetch_notmode_soft_tcb,
atomic_notmode_soft_tcb, atomic_fetch_fetchop_namemode_soft_imask,
atomic_fetch_notmode_soft_imask, atomic_fetch_nandmode_soft_tcb,
atomic_nandmode_soft_tcb, atomic_fetch_nandmode_soft_imask,
atomic_fetchop_name_fetchmode_soft_tcb,
atomic_not_fetchmode_soft_tcb,
atomic_fetchop_name_fetchmode_soft_imask,
Re: Fix PR 63566 part 3
Jan,
This patch caused Bug 64982 - [5 Regression] Many g++ failures on
x86_64-apple-darwin14 with -m32.
Jack
On Sun, Feb 8, 2015 at 3:20 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this patch makes i386.c ready for presence of aliases of local functions, but
also fixes a wrong code issue where ix86_function_sseregparm
does use caller TARET_SSE_MATH flags instead of callees. If callee disagree
on this flag, it may get called with wrong calling convention.
I added error message on calling local function with SSE ABI from function
compiled with SSE disabled. We may work harder to simply disable SSE calling
convention but that requires whole compilation unit analysis that is hard
to do on ltrans. I hope it does not matter in practice. Otherwise we may want
to introduce some hook and disqualify such functions from being local
at WPA time.
Bootstrapped/regtested x86_64-linux (includin 32bit testing), will commit it
shortly.
Honza
PR ipa/63566
* i386.c (ix86_function_regparm): Look through aliases to see if
callee
is local and optimized.
(ix86_function_sseregparm): Likewise; also use target's SSE math
settings; error out instead of silently generating wrong code
on mismatches.
(init_cumulative_args): Look through aliases.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 220509)
+++ config/i386/i386.c (working copy)
@@ -5767,49 +5767,55 @@ ix86_function_regparm (const_tree type,
/* Use register calling convention for local functions when possible. */
if (decl
- TREE_CODE (decl) == FUNCTION_DECL
+ TREE_CODE (decl) == FUNCTION_DECL)
+{
+ cgraph_node *target = cgraph_node::get (decl);
+ if (target)
+ target = target-function_symbol ();
+
/* Caller and callee must agree on the calling convention, so
checking here just optimize means that with
__attribute__((optimize (...))) caller could use regparm convention
and callee not, or vice versa. Instead look at whether the callee
is optimized or not. */
- opt_for_fn (decl, optimize)
- !(profile_flag !flag_fentry))
-{
- /* FIXME: remove this CONST_CAST when cgraph.[ch] is constified. */
- cgraph_local_info *i = cgraph_node::local_info (CONST_CAST_TREE
(decl));
- if (i i-local i-can_change_signature)
+ if (target opt_for_fn (target-decl, optimize)
+ !(profile_flag !flag_fentry))
{
- int local_regparm, globals = 0, regno;
+ cgraph_local_info *i = target-local;
+ if (i i-local i-can_change_signature)
+ {
+ int local_regparm, globals = 0, regno;
- /* Make sure no regparm register is taken by a
-fixed register variable. */
- for (local_regparm = 0; local_regparm REGPARM_MAX;
local_regparm++)
- if (fixed_regs[local_regparm])
- break;
-
- /* We don't want to use regparm(3) for nested functions as
-these use a static chain pointer in the third argument. */
- if (local_regparm == 3 DECL_STATIC_CHAIN (decl))
- local_regparm = 2;
-
- /* In 32-bit mode save a register for the split stack. */
- if (!TARGET_64BIT local_regparm == 3 flag_split_stack)
- local_regparm = 2;
-
- /* Each fixed register usage increases register pressure,
-so less registers should be used for argument passing.
-This functionality can be overriden by an explicit
-regparm value. */
- for (regno = AX_REG; regno = DI_REG; regno++)
- if (fixed_regs[regno])
- globals++;
+ /* Make sure no regparm register is taken by a
+fixed register variable. */
+ for (local_regparm = 0; local_regparm REGPARM_MAX;
+ local_regparm++)
+ if (fixed_regs[local_regparm])
+ break;
+
+ /* We don't want to use regparm(3) for nested functions as
+these use a static chain pointer in the third argument. */
+ if (local_regparm == 3 DECL_STATIC_CHAIN (target-decl))
+ local_regparm = 2;
+
+ /* Save a register for the split stack. */
+ if (local_regparm == 3 flag_split_stack)
+ local_regparm = 2;
+
+ /* Each fixed register usage increases register pressure,
+so less registers should be used for argument passing.
+This functionality can be overriden by an explicit
+regparm value. */
+ for (regno = AX_REG; regno = DI_REG; regno++)
+ if (fixed_regs[regno])
+ globals++;
- local_regparm
- = globals
Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris
On Mon, Feb 9, 2015 at 3:30 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: That worked fine indeed and is considerably more readable than my previous version. Excellent! Thank you. It produced the identical fixincl.x, passed fixincludes make check and Solaris 10 and 11 bootstraps. Ok for mainline now, I guess? That's a really good guess. :)
[Obvious][Testsuite] Remove extraneous target from gcc.target/arm/macro_defs0.c
This was giving an UNRESOLVED after my first attempt to apply the patch ran into
trouble with line wrapping, and in diagnosing the problem I'd introduced an
extra 'target' vs. the original
(https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00215.html). Sorry! Pushed as
r220542.
--Alan
gcc/testsuite/ChangeLog:
* gcc.target/arm/macro_defs0.c: Remove extraneous target
-
Index: gcc/testsuite/gcc.target/arm/macro_defs0.c
===
--- gcc/testsuite/gcc.target/arm/macro_defs0.c (revision 220541)
+++ gcc/testsuite/gcc.target/arm/macro_defs0.c (working copy)
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-skip-if avoid conflicting multilib options { *-*-* } { -march=* }
{ -march=armv7-m } } */
-/* { dg-skip-if avoid conflicting multilib options { target *-*-* } {
-mfloat-abi=* } { -mfloat-abi=soft } } */
+/* { dg-skip-if avoid conflicting multilib options { *-*-* } {
-mfloat-abi=* } { -mfloat-abi=soft } } */
/* { dg-options -march=armv7-m -mcpu=cortex-m3 -mfloat-abi=soft -mthumb } */
#ifdef __ARM_FP
RE: [PATCH, combine] Try REG_EQUAL for nonzero_bits
And this is part 2.
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
Once this is done, the same thing needs to be applied to XEXP
(reg_equal, 0)
before it is sent to nonzero_bits.
- /* Don't call nonzero_bits if it cannot change anything. */
- if (rsp-nonzero_bits != ~(unsigned HOST_WIDE_INT) 0)
- rsp-nonzero_bits |= nonzero_bits (src, nonzero_bits_mode);
num = num_sign_bit_copies (SET_SRC (set), GET_MODE (x));
if (rsp-sign_bit_copies == 0
|| rsp-sign_bit_copies num)
rsp-sign_bit_copies = num;
+
+ /* Don't call nonzero_bits if it cannot change anything. */
+ if (rsp-nonzero_bits != ~(unsigned HOST_WIDE_INT) 0)
+ update_rsp_from_reg_equal (rsp, insn, src, x);
Can't we improve on this? rsp-sign_bit_copies is modified both here
and in
update_rsp_from_reg_equal, but rsp-nonzero_bits is modified only in
the
latter function. There is no reason for this discrepancy, so they ought to
be
handled the same way, either entirely here or entirely in the function.
So I moved all the handling inside the new function and also added a check
before calling num_sign_bit_copies about whether it would give any more
information to be consistent with what is done for nonzero_bits.
ChangeLog entry is as follows:
2015-02-09 Thomas Preud'homme thomas.preudho...@arm.com
* combine.c i(set_nonzero_bits_and_sign_copies): Split code updating
rsp-sign_bit_copies and rsp-nonzero_bits into ...
(update_rsp_from_reg_equal): This. Also use REG_EQUAL note on src if
present to get more accurate information about the number of sign bit
copies and non zero bits.
diff --git a/gcc/combine.c b/gcc/combine.c
index f2b26c2..622279e 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1660,6 +1660,51 @@ sign_extend_short_imm (rtx src, machine_mode mode,
unsigned int prec)
}
#endif
+/* Update RSP for pseudo-register X from INSN's REG_EQUAL note (if one exists)
+ and SET. */
+
+static void
+update_rsp_from_reg_equal (reg_stat_type *rsp, rtx_insn *insn, const_rtx set,
+ rtx x)
+{
+ rtx reg_equal_note = insn ? find_reg_equal_equiv_note (insn) : NULL_RTX;
+ unsigned HOST_WIDE_INT bits = 0;
+ rtx reg_equal = NULL, src = SET_SRC (set);
+ unsigned int num = 0;
+
+ if (reg_equal_note)
+reg_equal = XEXP (reg_equal_note, 0);
+
+#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
+ src = sign_extend_short_imm (src, GET_MODE (x), BITS_PER_WORD);
+ if (reg_equal)
+reg_equal = sign_extend_short_imm (reg_equal, GET_MODE (x), BITS_PER_WORD);
+#endif
+
+ /* Don't call nonzero_bits if it cannot change anything. */
+ if (rsp-nonzero_bits != ~(unsigned HOST_WIDE_INT) 0)
+{
+ bits = nonzero_bits (src, nonzero_bits_mode);
+ if (reg_equal bits)
+ bits = nonzero_bits (reg_equal, nonzero_bits_mode);
+ rsp-nonzero_bits |= bits;
+}
+
+ /* Don't call num_sign_bit_copies if it cannot change anything. */
+ if (rsp-sign_bit_copies != 1)
+{
+ num = num_sign_bit_copies (SET_SRC (set), GET_MODE (x));
+ if (reg_equal num != GET_MODE_PRECISION (GET_MODE (x)))
+ {
+ unsigned int numeq = num_sign_bit_copies (reg_equal, GET_MODE (x));
+ if (num == 0 || numeq num)
+ num = numeq;
+ }
+ if (rsp-sign_bit_copies == 0 || num rsp-sign_bit_copies)
+ rsp-sign_bit_copies = num;
+}
+}
+
/* Called via note_stores. If X is a pseudo that is narrower than
HOST_BITS_PER_WIDE_INT and is being set, record what bits are known zero.
@@ -1675,7 +1720,6 @@ static void
set_nonzero_bits_and_sign_copies (rtx x, const_rtx set, void *data)
{
rtx_insn *insn = (rtx_insn *) data;
- unsigned int num;
if (REG_P (x)
REGNO (x) = FIRST_PSEUDO_REGISTER
@@ -1735,21 +1779,7 @@ set_nonzero_bits_and_sign_copies (rtx x, const_rtx set,
void *data)
if (SET_DEST (set) == x
|| (paradoxical_subreg_p (SET_DEST (set))
SUBREG_REG (SET_DEST (set)) == x))
- {
- rtx src = SET_SRC (set);
-
-#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
- src = sign_extend_short_imm (src, GET_MODE (x), BITS_PER_WORD);
-#endif
-
- /* Don't call nonzero_bits if it cannot change anything. */
- if (rsp-nonzero_bits != ~(unsigned HOST_WIDE_INT) 0)
- rsp-nonzero_bits |= nonzero_bits (src, nonzero_bits_mode);
- num = num_sign_bit_copies (SET_SRC (set), GET_MODE (x));
- if (rsp-sign_bit_copies == 0
- || rsp-sign_bit_copies num)
- rsp-sign_bit_copies = num;
- }
+ update_rsp_from_reg_equal (rsp, insn, set, x);
else
{
rsp-nonzero_bits = GET_MODE_MASK (GET_MODE (x));
Is this ok for stage 1?
Best regards,
Thomas
New Ukrainian 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 Ukrainian team of translators. The file is available at: http://translationproject.org/latest/cpplib/uk.po (This file, 'cpplib-5.1-b20150208.uk.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. coordina...@translationproject.org
RE: [PATCH 1/2, combine] Try REG_EQUAL for nonzero_bits
Hi Eric,
I'm taking over Zhenqiang's work on this. Comments and updated patch
below.
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
+ rtx reg_equal = insn ? find_reg_equal_equiv_note (insn) : NULL_RTX;
+ unsigned HOST_WIDE_INT bits = nonzero_bits (src,
nonzero_bits_mode);
Note that src has taken the SHORT_IMMEDIATES_SIGN_EXTEND path
here.
+ if (reg_equal)
+{
+ unsigned int num = num_sign_bit_copies (XEXP (reg_equal, 0),
+ GET_MODE (x));
+ bits = nonzero_bits (XEXP (reg_equal, 0), nonzero_bits_mode);
But XEXP (reg_equal, 0) hasn't here. If we want to treat the datum of
the
REG_EQUAL or REG_EQUIV note as equivalent to the SET_SRC (set), and
I think we
should (see for example combine.c:9650), there is a problem.
So I think we should create a new function, something along of:
/* 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. */
rtx
sign_extend_short_imm (rtx src, machine_mode mode, unsigned int
prec)
{
if (GET_MODE_PRECISION (mode) prec
CONST_INT_P (src)
INTVAL (src) 0
val_signbit_known_set_p (mode, INTVAL (src)))
src = GEN_INT (INTVAL (src) | ~GET_MODE_MASK (mode));
return src;
}
and calls it from combine.c:1702
#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
src = sign_extend_short_imm (src, GET_MODE (x), BITS_PER_WORD);
#endif
and from combine.c:9650
#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
tem = sign_extend_short_imm (tem, GET_MODE (x),
GET_MODE_PRECISION (mode));
#endif
Once this is done, the same thing needs to be applied to XEXP
(reg_equal, 0)
before it is sent to nonzero_bits.
I did this as you suggested and decided to split the patch in 2 to make it
easier
to review. Part 1 does this reorganization while part 2 concern the REG_EQUAL
matter.
ChangeLog entry for part 1 is as follows:
*** gcc/ChangeLog ***
2015-02-09 Thomas Preud'homme thomas.preudho...@arm.com
* combine.c (sign_extend_short_imm): New.
(set_nonzero_bits_and_sign_copies): Use above new function for sign
extension of src short immediate.
(reg_nonzero_bits_for_combine): Likewise for tem.
diff --git a/gcc/combine.c b/gcc/combine.c
index ad3bed0..f2b26c2 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1640,6 +1640,26 @@ setup_incoming_promotions (rtx_insn *first)
}
}
+#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. */
+
+static rtx
+sign_extend_short_imm (rtx src, machine_mode mode, unsigned int prec)
+{
+ if (GET_MODE_PRECISION (mode) prec CONST_INT_P (src)
+ INTVAL (src) 0 val_signbit_known_set_p (mode, INTVAL (src)))
+src = GEN_INT (INTVAL (src) | ~GET_MODE_MASK (mode));
+
+ return src;
+}
+#endif
+
/* Called via note_stores. If X is a pseudo that is narrower than
HOST_BITS_PER_WIDE_INT and is being set, record what bits are known zero.
@@ -1719,20 +1739,7 @@ set_nonzero_bits_and_sign_copies (rtx x, const_rtx set,
void *data)
rtx src = SET_SRC (set);
#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
- /* If X is narrower than a word and SRC is a non-negative
-constant that would appear negative in the mode of X,
-sign-extend it for use in reg_stat[].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. */
-
- if (GET_MODE_PRECISION (GET_MODE (x)) BITS_PER_WORD
- CONST_INT_P (src)
- INTVAL (src) 0
- val_signbit_known_set_p (GET_MODE (x), INTVAL (src)))
- src = GEN_INT (INTVAL (src) | ~GET_MODE_MASK (GET_MODE (x)));
+ src = sign_extend_short_imm (src, GET_MODE (x), BITS_PER_WORD);
#endif
/* Don't call nonzero_bits if it cannot change anything. */
@@ -9770,20 +9777,8 @@ reg_nonzero_bits_for_combine (const_rtx x, machine_mode
mode,
if (tem)
{
#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
- /* If X is narrower than MODE and TEM is a non-negative
-constant that would appear negative in the mode of X,
-sign-extend it for use in reg_nonzero_bits because some
-
Re: [PATCH 1/2, combine] Try REG_EQUAL for nonzero_bits
On Mon, Feb 9, 2015 at 5:51 PM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
Hi Eric,
I'm taking over Zhenqiang's work on this. Comments and updated patch
below.
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
+ rtx reg_equal = insn ? find_reg_equal_equiv_note (insn) : NULL_RTX;
+ unsigned HOST_WIDE_INT bits = nonzero_bits (src,
nonzero_bits_mode);
Note that src has taken the SHORT_IMMEDIATES_SIGN_EXTEND path
here.
+ if (reg_equal)
+{
+ unsigned int num = num_sign_bit_copies (XEXP (reg_equal, 0),
+ GET_MODE (x));
+ bits = nonzero_bits (XEXP (reg_equal, 0), nonzero_bits_mode);
But XEXP (reg_equal, 0) hasn't here. If we want to treat the datum of
the
REG_EQUAL or REG_EQUIV note as equivalent to the SET_SRC (set), and
I think we
should (see for example combine.c:9650), there is a problem.
So I think we should create a new function, something along of:
/* 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. */
rtx
sign_extend_short_imm (rtx src, machine_mode mode, unsigned int
prec)
{
if (GET_MODE_PRECISION (mode) prec
CONST_INT_P (src)
INTVAL (src) 0
val_signbit_known_set_p (mode, INTVAL (src)))
src = GEN_INT (INTVAL (src) | ~GET_MODE_MASK (mode));
return src;
}
and calls it from combine.c:1702
#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
src = sign_extend_short_imm (src, GET_MODE (x), BITS_PER_WORD);
#endif
and from combine.c:9650
#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
tem = sign_extend_short_imm (tem, GET_MODE (x),
GET_MODE_PRECISION (mode));
#endif
Once this is done, the same thing needs to be applied to XEXP
(reg_equal, 0)
before it is sent to nonzero_bits.
I did this as you suggested and decided to split the patch in 2 to make it
easier
to review. Part 1 does this reorganization while part 2 concern the REG_EQUAL
matter.
ChangeLog entry for part 1 is as follows:
*** gcc/ChangeLog ***
2015-02-09 Thomas Preud'homme thomas.preudho...@arm.com
* combine.c (sign_extend_short_imm): New.
(set_nonzero_bits_and_sign_copies): Use above new function for sign
extension of src short immediate.
(reg_nonzero_bits_for_combine): Likewise for tem.
diff --git a/gcc/combine.c b/gcc/combine.c
index ad3bed0..f2b26c2 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1640,6 +1640,26 @@ setup_incoming_promotions (rtx_insn *first)
}
}
+#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.
Thanks,
Andrew
+
+static rtx
+sign_extend_short_imm (rtx src, machine_mode mode, unsigned int prec)
+{
+ if (GET_MODE_PRECISION (mode) prec CONST_INT_P (src)
+ INTVAL (src) 0 val_signbit_known_set_p (mode, INTVAL (src)))
+src = GEN_INT (INTVAL (src) | ~GET_MODE_MASK (mode));
+
+ return src;
+}
+#endif
+
/* Called via note_stores. If X is a pseudo that is narrower than
HOST_BITS_PER_WIDE_INT and is being set, record what bits are known zero.
@@ -1719,20 +1739,7 @@ set_nonzero_bits_and_sign_copies (rtx x, const_rtx
set, void *data)
rtx src = SET_SRC (set);
#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
- /* If X is narrower than a word and SRC is a non-negative
-constant that would appear negative in the mode of X,
-sign-extend it for use in reg_stat[].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. */
-
- if (GET_MODE_PRECISION (GET_MODE (x)) BITS_PER_WORD
- CONST_INT_P (src)
- INTVAL (src) 0
- val_signbit_known_set_p (GET_MODE (x), INTVAL (src)))
- src = GEN_INT (INTVAL (src) | ~GET_MODE_MASK (GET_MODE (x)));
+ src = sign_extend_short_imm (src, GET_MODE (x),
Re: [PATCH] gcc/ira-color.c: save a init statement
On 02/09/15 00:57, Zhouyi Zhou wrote: +2015-02-09 Zhouyi Zhouyizhouz...@ict.ac.cn + * ira-color.c (setup_left_conflict_sizes_p): save a init statement. THanks. I improve the ChangeLog a bit fixed the indention, bootstrapped and regression tested your change. Installed on the trunk. Thanks, Jeff
Re: [PATCH] libssp should not use /dev/random on Windows
On 02/06/15 02:34, Georg Koppen wrote: Hi, inline is a patch to avoid using /dev/random on Windows in ssp.c. If it is getting used there might be a local malicious process supplying fake random values (e.g. via C:\dev\random) rendering SSP useless. Comments/review are much appreciated. The patch is against the 4.9 branch: From 372698ef051b776cc30e9ebd2aac7291c19ff506 Mon Sep 17 00:00:00 2001 From: Erinn Clark er...@torproject.org Date: Wed, 12 Mar 2014 16:09:10 +0100 Subject: [PATCH] Don't use /dev/random on Windows, because it is not a thing. Apart from that some process might be able to supply fake random data with e.g. c:\dev\urandom rendering SSP useless. This patch was written by skruffy, thanks! Thanks. I've written a ChangeLog for this change and installed it on the trunk. Jeff
Re: patch to fix rtl documentation for new floating point comparisons
On 02/09/2015 06:24 PM, Joseph Myers wrote:
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
@findex ge
@cindex greater than
@@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
@item (ge:@var{m} @var{x} @var{y})
@itemx (geu:@var{m} @var{x} @var{y})
Like @code{gt} and @code{gtu} but test for ``greater than or equal''.
+If the operands are floating point, @code{ge} is a signaling
+comparison and corresponds to the IEC 60559
+@code{compareSignalingGreater} operation. @code{geu} is undefined for
+floating point numbers.
No, compareSignalingGreaterEqual.
oops
@findex le
@cindex less than or equal
@@ -2610,7 +2629,64 @@ Like @code{gt} and @code{gtu} but test f
@cindex unsigned less than
@item (le:@var{m} @var{x} @var{y})
@itemx (leu:@var{m} @var{x} @var{y})
-Like @code{gt} and @code{gtu} but test for ``less than or equal''.
+Like @code{gt} and @code{gtu} but test for ``less than or equal''. If
+the operands are floating point, @code{le} is a signaling comparison
+and corresponds to the IEC 60559 @code{compareSignalingLess}
+operation. @code{leu} is undefined for floating point numbers.
compareSignalingLessEqual.
oops again
+@table @code
+@findex ltgt
+@cindex less than or greater than
+@item (ltgt:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are less, or greater, otherwise 0. This is a quiet operation
+that applies only to floating point operands and does not have a
+corresponding IEC 60559 operation.
On GENERIC, the documentation describes some ambiguity: With the possible
exception of @code{LTGT_EXPR}, all of these operations are guaranteed
not to generate a floating point exception..
LTGT (RTL code) was added by RTH in
https://gcc.gnu.org/ml/gcc-patches/2000-01/msg00974.html. LTGT_EXPR was
added in the thread starting at
https://gcc.gnu.org/ml/gcc-patches/2004-05/msg01674.html, wherein RTH
stated the LTGT rtl code is assumed to trap. The documentation was soon
thereafter changed to have the possible exception wording (r82467, which
I can't find any sign of having been posted to gcc-patches so don't know
the rationale).
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.
The islessgreater macro determines whether its first argument is less
than or
greater than its second argument. The islessgreater(x, y) macro is
similar to
(x) (y) || (x) (y); howev er, islessgreater(x, y) does not raise
the ‘‘invalid’’ floating-point exception when x and y are unordered
(nor does it evaluate x
and y twice).
So i think that it seems that we should be pretty safe saying it is quiet.
It's not clear to me that ad hoc logic around particular operations is the
best way of handling optimizations in this area, instead of generic logic
using four bits to track which conditions ( = unordered) a comparison
is true for and one bit to track whether it raises an exception for
unordered operands. Even if you keep using particular sets of tree / RTL
codes for a subset of operations, maybe transformations that map into and
out of such five-bit form would be more likely to be correct.
I will work on the tree version tomorrow and resubmit.
Kenny
RE: [PATCH 1/2, combine] Try REG_EQUAL for nonzero_bits
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. Best regards, Thomas
Re: Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME
On 28/01/15 18:50, Mike Stump wrote:
On Jan 28, 2015, at 9:51 AM, Marcus Shawcroft marcus.shawcr...@gmail.com
wrote:
Going forward we can [ … ] xfail the test case pending a proper solution to
59448 ?
Mike do you prefer one of the other two approaches ?
I’d xfail the test case and mark with the fix consume PR. If we don’t have an
unambiguous, fix consume PR, I’d file that. It should be listed as failing on
aarch, and the fix for that PR should then make the aarch test case pass. This
way no one can run off with the PR and do anything else with it.
Hi, Mike!
Sorry for the delay.
The following patch makes atomic-op-consume.c XFAIL for both
gcc.target/arm and gcc.target/aarch64 tests. XFAIL was chosen as
prefered approach for handling __ATOMIC_CONSUME to __ATOMIC_ACQUIRE
promotion workaround.
This patch was tested by running the modified tests on aarch64-none-elf
and arm-none-eabi compilers.
Is this patch ok?
Alex
2015-02-09 Alex Velenko alex.vele...@arm.com
gcc/testsuite/
* gcc.target/aarch64/atomic-op-consume.c (scan-assember-times):
Directive adjusted to XFAIL.
* gcc.target/arm/atomic-op-consume.c (scan-assember-times): Directive
adjusted to XFAIL.
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
b/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
index 38d6c2c..8150af6 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
@@ -3,5 +3,9 @@
#include atomic-op-consume.x
-/* { dg-final { scan-assembler-times ldxr\tw\[0-9\]+,
\\\[x\[0-9\]+\\\] 6 } } */
+/* To workaround Bugzilla 59448 issue, a request for __ATOMIC_CONSUME
is always
+ promoted to __ATOMIC_ACQUIRE, implemented as MEMMODEL_ACQUIRE. This
causes
+ LDAXR to be generated instead of LDXR. Therefore, LDXR test is
+ expected to fail. */
+/* { dg-final { scan-assembler-times ldxr\tw\[0-9\]+,
\\\[x\[0-9\]+\\\] 6 { xfail *-*-* } } } */
/* { dg-final { scan-assembler-times stxr\tw\[0-9\]+, w\[0-9\]+,
\\\[x\[0-9\]+\\\] 6 } } */
diff --git a/gcc/testsuite/gcc.target/arm/atomic-op-consume.c
b/gcc/testsuite/gcc.target/arm/atomic-op-consume.c
index cc6c028..060655c 100644
--- a/gcc/testsuite/gcc.target/arm/atomic-op-consume.c
+++ b/gcc/testsuite/gcc.target/arm/atomic-op-consume.c
@@ -7,7 +7,8 @@
/* To workaround Bugzilla 59448 issue, a request for __ATOMIC_CONSUME
is always
promoted to __ATOMIC_ACQUIRE, implemented as MEMMODEL_ACQUIRE.
This causes
- LDAEX to be generated instead of LDREX. */
-/* { dg-final { scan-assembler-times ldaex\tr\[0-9\]+,
\\\[r\[0-9\]+\\\] 6 } } */
+ LDAEX to be generated instead of LDREX. Therefore, LDREX test is
+ expected to fail. */
+/* { dg-final { scan-assembler-times ldrex\tr\[0-9\]+,
\\\[r\[0-9\]+\\\] 6 { xfail *-*-* } } } */
/* { dg-final { scan-assembler-times strex\t...?, r\[0-9\]+,
\\\[r\[0-9\]+\\\] 6 } } */
/* { dg-final { scan-assembler-not dmb } } */
--1.8.1.2--
patch to fix rtl documentation for new floating point comparisons
Before I commit this, or do the corresponding tree level patch, I would
like this to be looked at by the FP people. I am guessing at some of
this, other parts i gleaned from various standards docs and an irc
conversation with Joseph. This should have been documented when it was
put into the compiler. This is certainly not obvious.
Kenny
Index: gcc/doc/rtl.texi
===
--- gcc/doc/rtl.texi (revision 220541)
+++ gcc/doc/rtl.texi (working copy)
@@ -2553,40 +2553,52 @@ of comparisons is supported on a particu
pass will try to merge the operations to produce the @code{eq} shown
in case it exists in the context of the particular insn involved.
-Inequality comparisons come in two flavors, signed and unsigned. Thus,
-there are distinct expression codes @code{gt} and @code{gtu} for signed and
-unsigned greater-than. These can produce different results for the same
-pair of integer values: for example, 1 is signed greater-than @minus{}1 but not
-unsigned greater-than, because @minus{}1 when regarded as unsigned is actually
+Fixed point inequality comparisons come in two flavors, signed and
+unsigned. Thus, there are distinct expression codes @code{gt} and
+@code{gtu} for signed and unsigned greater-than. These can produce
+different results for the same pair of integer values: for example, 1
+is signed greater-than @minus{}1 but not unsigned greater-than,
+because @minus{}1 when regarded as unsigned is actually
@code{0x} which is greater than 1.
-The signed comparisons are also used for floating point values. Floating
-point comparisons are distinguished by the machine modes of the operands.
+Floating point comparisons come in two flavors, signaling and quiet,
+though these are not always paired. The fixed point signed
+comparisons are also used for floating point comparisons. Floating
+point comparisons are distinguished by the machine modes of the
+operands.
@table @code
@findex eq
@cindex equal
@item (eq:@var{m} @var{x} @var{y})
-@code{STORE_FLAG_VALUE} if the values represented by @var{x} and @var{y}
-are equal, otherwise 0.
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are equal, otherwise 0. If the operands are floating point,
+this is a quiet comparison and corresponds to the IEC 60559
+@code{compareQuietEqual} operation.
@findex ne
@cindex not equal
@item (ne:@var{m} @var{x} @var{y})
-@code{STORE_FLAG_VALUE} if the values represented by @var{x} and @var{y}
-are not equal, otherwise 0.
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are not equal, otherwise 0. If the operands are floating
+point, this is a quiet comparison and corresponds to the IEC 60559
+@code{compareQuietNotEqual} operation.
@findex gt
@cindex greater than
@item (gt:@var{m} @var{x} @var{y})
-@code{STORE_FLAG_VALUE} if the @var{x} is greater than @var{y}. If they
-are fixed-point, the comparison is done in a signed sense.
+@code{STORE_FLAG_VALUE} if the @var{x} is greater than @var{y}. If
+the operands are fixed-point, the comparison is done in a signed
+sense. If the operands are floating point, this is a signaling
+comparison and corresponds to the IEC 60559
+@code{compareSignalingGreater} operation.
@findex gtu
@cindex greater than
@cindex unsigned greater than
@item (gtu:@var{m} @var{x} @var{y})
-Like @code{gt} but does unsigned comparison, on fixed-point numbers only.
+Like @code{gt} but does unsigned comparison, on fixed-point numbers
+only. This is undefined for floating point numbers.
@findex lt
@cindex less than
@@ -2594,7 +2606,10 @@ Like @code{gt} but does unsigned compari
@cindex unsigned less than
@item (lt:@var{m} @var{x} @var{y})
@itemx (ltu:@var{m} @var{x} @var{y})
-Like @code{gt} and @code{gtu} but test for ``less than''.
+Like @code{gt} and @code{gtu} but test for ``less than''. If the
+operands are floating point, @code{gt} is a signaling comparison and
+corresponds to the IEC 60559 @code{compareSignalingLess} operation.
+@code{gtu} is undefined for floating point numbers.
@findex ge
@cindex greater than
@@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
@item (ge:@var{m} @var{x} @var{y})
@itemx (geu:@var{m} @var{x} @var{y})
Like @code{gt} and @code{gtu} but test for ``greater than or equal''.
+If the operands are floating point, @code{ge} is a signaling
+comparison and corresponds to the IEC 60559
+@code{compareSignalingGreater} operation. @code{geu} is undefined for
+floating point numbers.
@findex le
@cindex less than or equal
@@ -2610,7 +2629,64 @@ Like @code{gt} and @code{gtu} but test f
@cindex unsigned less than
@item (le:@var{m} @var{x} @var{y})
@itemx (leu:@var{m} @var{x} @var{y})
-Like @code{gt} and @code{gtu} but test for ``less than or equal''.
+Like @code{gt} and @code{gtu} but test for ``less than or equal''. If
+the operands are floating point, @code{le} is a signaling comparison
+and corresponds
C++ PATCH for c++/64899 (constexpr default-initialized array)
build_vec_init works to evaluate constant values for elements of a
vector initializer, but it wasn't working properly for a
default-initialized array with a constexpr default constructor. First I
needed to add that case to the try_const condition; then I needed to
change tho form of the initialization because when building the
constructor call to refer to *iterator, constexpr evaluation saw that
'iterator' isn't constant and gave up. To completely solve this for
cases where we refer to the address of the object or the value of a
previous element we should hand the whole initialization loop to
constexpr evaluation, but just using the value-init path fixes this
testcase.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5d38d5961241cdca385f95199c3c77a9aa5778a4
Author: Jason Merrill ja...@redhat.com
Date: Wed Feb 4 07:45:02 2015 -0500
PR c++/64899
* init.c (build_vec_init): Handle default-initialized array with
constexpr default constructor.
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index e600472..0274663 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -3539,7 +3539,9 @@ build_vec_init (tree base, tree maxindex, tree init,
/* Should we try to create a constant initializer? */
bool try_const = (TREE_CODE (atype) == ARRAY_TYPE
TREE_CONSTANT (maxindex)
- init TREE_CODE (init) == CONSTRUCTOR
+ (init ? TREE_CODE (init) == CONSTRUCTOR
+ : (type_has_constexpr_default_constructor
+ (inner_elt_type)))
(literal_type_p (inner_elt_type)
|| TYPE_HAS_CONSTEXPR_CTOR (inner_elt_type)));
vecconstructor_elt, va_gc *const_vec = NULL;
@@ -3677,6 +3679,12 @@ build_vec_init (tree base, tree maxindex, tree init,
We do need to keep going if we're copying an array. */
+ if (try_const !init)
+/* With a constexpr default constructor, which we checked for when
+ setting try_const above, default-initialization is equivalent to
+ value-initialization, and build_value_init gives us something more
+ friendly to maybe_constant_init. */
+explicit_value_init_p = true;
if (from_array
|| ((type_build_ctor_call (type) || init || explicit_value_init_p)
! (tree_fits_shwi_p (maxindex)
@@ -3781,6 +3789,7 @@ build_vec_init (tree base, tree maxindex, tree init,
if (try_const)
{
+ /* FIXME refs to earlier elts */
tree e = maybe_constant_init (elt_init);
if (reduced_constant_expression_p (e))
{
@@ -3795,6 +3804,8 @@ build_vec_init (tree base, tree maxindex, tree init,
saw_non_const = true;
if (do_static_init)
e = build_zero_init (TREE_TYPE (e), NULL_TREE, true);
+ else
+ e = NULL_TREE;
}
if (e)
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-array10.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-array10.C
new file mode 100644
index 000..f7aaa4b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-array10.C
@@ -0,0 +1,12 @@
+// PR c++/64899
+// { dg-do compile { target c++11 } }
+
+struct S
+{
+ int i;
+ constexpr S (): i(42) {}
+};
+
+constexpr S sa[2];
+#define SA(X) static_assert((X),#X)
+SA(sa[1].i == 42);
Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c
Le 9 févr. 2015 à 20:01, Dominique d'Humières domi...@lps.ens.fr a écrit :
Le 9 févr. 2015 à 19:10, Tom de Vries 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.c 2015-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.c 2015-02-09
11:38:40.0 +0100
+++ gcc/testsuite/gcc.dg/graphite/scop-19.c 2015-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 } } */
Cheers,
Dominique
Thanks,
- Tom
C PATCH for PR64856 (initializing range of elements in C99)
We reject the following testcase in C99 mode, because in C99 we always
wrap COMPOUND_LITERAL_EXPR in a SAVE_EXPR when initializing a range of
elements, even though the expression is required to be constant. As a
consequence, we error out with initializer element is not constant.
It's been like this since Roger's fold changes in 2003. Since the default
is now gnu11, I think we should accept the code even in C99. So this patch
makes the C FE treat the expression the same in both C90/C99 modes. There
is no need to add any pedwarns at this spot.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-02-09 Marek Polacek pola...@redhat.com
PR c/64856
* c-typeck.c (process_init_element): Don't always wrap
COMPOUND_LITERAL_EXPR in a SAVE_EXPR in C99 mode when
initializing a range of elements.
* gcc.dg/pr64856.c: New test.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 65c6f7f..a3a9c77 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -8785,8 +8785,7 @@ process_init_element (location_t loc, struct c_expr
value, bool implicit,
/* If value is a compound literal and we'll be just using its
content, don't put it into a SAVE_EXPR. */
if (TREE_CODE (value.value) != COMPOUND_LITERAL_EXPR
- || !require_constant_value
- || flag_isoc99)
+ || !require_constant_value)
{
tree semantic_type = NULL_TREE;
if (TREE_CODE (value.value) == EXCESS_PRECISION_EXPR)
diff --git gcc/testsuite/gcc.dg/pr64856.c gcc/testsuite/gcc.dg/pr64856.c
index e69de29..c21d95a 100644
--- gcc/testsuite/gcc.dg/pr64856.c
+++ gcc/testsuite/gcc.dg/pr64856.c
@@ -0,0 +1,13 @@
+/* PR c/64856 */
+/* { dg-do compile } */
+/* { dg-options } */
+
+struct A {
+ unsigned long b;
+};
+
+struct B {
+ struct A c[5];
+};
+
+struct B d = { .c = { [0 ... 4] = (struct A){ .b = 2 } } };
Marek
New template for 'cpplib' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to coordina...@translationproject.org.) A new POT file for textual domain 'cpplib' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/cpplib-5.1-b20150208.pot 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. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150208/gcc-5-20150208.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
[PATCH] Implement libffi for AARCH64:ILP32
Hi,
The following GCC patch (I don't have the libffi code git checked
out) implements libffi for AARCH64:ILP32. The majority of the AARCH64
code works correctly for ILP32.
For ILP32, we need to use long long types for ffi_arg and ffi_sarg.
And then we need to fix up the closure code to load cif, fn, and
user_data by 32bit instead of 64bits as they are stored as pointers in
C code.
With this patch, I got no failures in the libffi testsuite that is
included with GCC.
OK? Built and tested on aarch64 with no regressions.
Thanks,
Andrew Pinski
ChangeLog:
* src/aarch64/ffitarget.h (ffi_arg): Use unsigned long long 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..c134fe3 100644
--- a/libffi/src/aarch64/ffitarget.h
+++ b/libffi/src/aarch64/ffitarget.h
@@ -27,8 +27,13 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
#endif
#ifndef LIBFFI_ASM
+#ifdef __ILP32__
+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: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking
On Feb 8, 2015, at 10:24 AM, Jack Howarth howarth.at@gmail.com 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] Fix PR64764 Fix scan-tree-dump for scop-19.c
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! Cheers, Dominique
Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.
On 09/02/15 13:18, Hans-Peter Nilsson wrote:
On Mon, 9 Feb 2015, Matthew Wahab wrote:
On 07/02/15 00:11, Jonathan Wakely wrote:
Any idea why HP still sees the tests fail? See comment 8 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8
It looks like he's found the problem: that _NEWLIB_ is a recent addition that
isn't in the version he's using. I'll try replacing _NEWLIB_ with
_NEWLIB_VERSION_ as suggested.
(Careful with that macro spelling, if nothing else.)
Better to use existing mechanisms and stop playing with
target-related macros. Add this at the top (see other
placements of dg-options) and replace #if defined (__NEWLIB__)
with #ifdef NEWLINE_IN_CLASS_BLANK:
// { dg-options -DNEWLINE_IN_CLASS_BLANK { target newlib } }
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?
Matthew
libstdc++-v3/testsuite/
2015-02-09 Matthew Wahab matthew.wa...@arm.com
* 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.
diff --git a/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc b/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
index 7c47045..b6fd6ff 100644
--- a/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
+++ b/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
@@ -1,5 +1,6 @@
// { dg-do run }
// { dg-options -std=gnu++11 }
+// { dg-additional-options -DNEWLINE_IN_CLASS_BLANK { target newlib } }
//
// 2010-06-23 Stephen M. Webb stephen.w...@bregmasoft.ca
@@ -53,8 +54,8 @@ test01()
VERIFY(!t.isctype('_', t.lookup_classname(range(digit;
VERIFY( t.isctype(' ', t.lookup_classname(range(blank;
VERIFY( t.isctype('\t', t.lookup_classname(range(blank;
-#if defined (__NEWLIB__)
- /* newlib includes '\n' in class 'blank'.
+#if defined (NEWLINE_IN_CLASS_BLANK)
+ /* On some targets, '\n' is in class 'blank'.
See https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00059.html. */
VERIFY( t.isctype('\n', t.lookup_classname(range(blank;
#else
diff --git a/libstdc++-v3/testsuite/28_regex/traits/wchar_t/isctype.cc b/libstdc++-v3/testsuite/28_regex/traits/wchar_t/isctype.cc
index 1b3d69a..9ba609c 100644
--- a/libstdc++-v3/testsuite/28_regex/traits/wchar_t/isctype.cc
+++ b/libstdc++-v3/testsuite/28_regex/traits/wchar_t/isctype.cc
@@ -1,5 +1,6 @@
// { dg-do run }
// { dg-options -std=gnu++11 }
+// { dg-additional-options -DNEWLINE_IN_CLASS_BLANK { target newlib } }
// Copyright (C) 2010-2015 Free Software Foundation, Inc.
//
@@ -51,7 +52,7 @@ test01()
VERIFY( t.isctype(L' ', t.lookup_classname(range(blank;
VERIFY( t.isctype(L'\t', t.lookup_classname(range(blank;
#if defined (__NEWLIB__)
- /* newlib includes '\n' in class 'blank'.
+ /* On some targets, '\n' is in class 'blank'.
See https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00059.html. */
VERIFY( t.isctype(L'\n', t.lookup_classname(range(blank;
#else
Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing
On 02/09/15 06:42, Richard Biener wrote:
On Mon, Feb 9, 2015 at 8:15 AM, Jeff Law l...@redhat.com wrote:
On 02/03/15 04:39, Richard Biener wrote:
I found that explicit types were ignored in some cases. It was
frustrating to say the least.
Huh, that would be a bug. Do you have a pattern where that happens?
I'll have to recreate them. In the mean time consider something else I'm
playing with that causes an odd error from genmatch...
/* If we have a narrowing conversion of an arithmetic or logical
operation where both are operands 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. */
(simplify
(convert (plus (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)))
(with { tree utype = unsigned_type_for (TREE_TYPE (@0));}
(convert (plus (convert:utype @0) (convert:utype @1)))
So given two narrow operands that get widened, added, and the final result
narrowed back down to the original operand types. Replace with convert the
operands to an unsigned type (of same size as the operand), operate on them
and convert to the final desired type.
This happens to fix 47477 (P2 regression). Works perfectly for the
testcase.
Of course we'd like to extend that to other operators... So, adding the
obvious for iterator...
(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)))
(with { tree utype = unsigned_type_for (TREE_TYPE (@0));}
(convert (op (convert:utype @0) (convert:utype @1)))
Which causes genmatch to barf:
build/genmatch --gimple /home/gcc/GIT-2/gcc/gcc/match.pd \
tmp-gimple-match.c
genmatch: two conversions in a row
Not only does genmatch barf, it doesn't give any indication what part of the
.pd file it found objectionable.
Yeah, I'll have to assign locations to more places at some point.
But the following fixes your testcase, committed to trunk as obvious.
Richard.
2015-02-09 Richard Biener rguent...@suse.de
* genmatch.c (replace_id): Copy expr_type.
Cool, thanks!
jeff
Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c
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? Thanks, - Tom
Re: patch to fix rtl documentation for new floating point comparisons
On 02/09/2015 06:26 PM, Richard Henderson wrote:
On 02/09/2015 11:10 AM, Kenneth Zadeck wrote:
+@table @code
+@findex ltgt
+@cindex less than or greater than
+@item (ltgt:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are less, or greater, otherwise 0. This is a quiet operation
+that applies only to floating point operands and does not have a
+corresponding IEC 60559 operation.
This is intended to match c99 7.12.14.5 islessgreater, which I believe is the
compareQuietNotEqual operation.
I think that the description that I have is correct. According to IEEE
754-2008, table 5.1, page 29, compareQuietNotEqual is defined to have
the true relations of LT GT UN.What appears to be described in c99
7.12.14.5 is a quiet version with relations LT GT and so returns false
if either operand is a nan. This does not have a defined name in IEEE
754-2008, but if it did would have the name compareQuietLessGreater
according to their naming conventions.
+@table @code
+@findex uneq
+@cindex unordered or equal
+@item (uneq:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are unordered or equal, otherwise 0. This is a quiet
+operation that applies only to floating point operands and does not
+have a corresponding IEC 60559 operation.
This is the strict inverse to LTGT, i.e. !compareQuietNotEqual, and you of
course note this is not the same as compareQuietEqual.
I believe that when the c99 math.h comparison builtins were added, treating
EQ+NE as quiet comparisons was common but not universal. It's possible this
could be simplified now.
I agree that this is the strict inverse of LTGT, but as the name of this
implies, if either operand is a nan, this returns true. As such, the
relations are UN and EQ which matches the name.
r~
Fix ipa-polymorphic-call ICE
Hi, this patch fixes ICE seen when compiling firefox with large unit growths. The problem is that the speculative part of analysis trips over VOID pointer and gets lost. Bootstrapped/regtsted x86_64-linux, commited. * ipa-polymorphic-call.c (ipa_polymorphic_call_context): Avoid ICE on getting VOID pointer. Index: ipa-polymorphic-call.c === --- ipa-polymorphic-call.c (revision 220509) +++ ipa-polymorphic-call.c (working copy) @@ -1078,7 +1078,7 @@ ipa_polymorphic_call_context::ipa_polymo base_type = TREE_TYPE (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (base_pointer))); - if (POINTER_TYPE_P (base_type)) + if (base_type POINTER_TYPE_P (base_type)) combine_speculation_with (TYPE_MAIN_VARIANT (TREE_TYPE (base_type)), offset, true, NULL /* Do not change type here */);
PR 63566 part 5
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 hubi...@ucw.cz
PR ipa/63566
* ipa-icf.c (set_local): New function.
(sem_function::merge): Use it.
Index: ipa-icf.c
===
--- ipa-icf.c (revision 220509)
+++ ipa-icf.c (working copy)
@@ -584,6 +584,16 @@ sem_function::equals_private (sem_item *
return result;
}
+/* Set LOCAL_P of NODE to true if DATA is non-NULL.
+ Helper for call_for_symbol_thunks_and_aliases. */
+
+static bool
+set_local (cgraph_node *node, void *data)
+{
+ node-local.local = data != NULL;
+ return false;
+}
+
/* Merges instance with an ALIAS_ITEM, where alias, thunk or redirection can
be applied. */
bool
@@ -743,10 +753,8 @@ sem_function::merge (sem_item *alias_ite
cgraph_node::create_alias (alias_func-decl, decl);
alias-resolve_alias (original);
- /* Workaround for PR63566 that forces equal calling convention
- to be used. */
- alias-local.local = false;
- original-local.local = false;
+ original-call_for_symbol_thunks_and_aliases
+(set_local, (void *)(size_t) original-local_p (), true);
if (dump_file)
fprintf (dump_file, Callgraph alias has been created.\n\n);
Re: Fix PR 63566 part 3
Jan,
This patch caused Bug 64982 - [5 Regression] Many g++ failures on
x86_64-apple-darwin14 with -m32.
Jack
Hi,
I think best way would be to move the warning to middle-end when the thunk is
being
expanded (other alternative is just to force analysis before doing the sanity
check
in cp/method.c.
I had to dro # in the error message, I am not quite sure what it means.
Jason, what do you think?
Honza
Index: cp/method.c
===
--- cp/method.c (revision 220547)
+++ cp/method.c (working copy)
@@ -418,20 +418,6 @@ use_thunk (tree thunk_fndecl, bool emit_
if (DECL_ONE_ONLY (function))
thunk_node-add_to_same_comdat_group (funcn);
- if (!this_adjusting
- || !targetm.asm_out.can_output_mi_thunk (thunk_fndecl, fixed_offset,
- virtual_value, alias))
-{
- /* If this is a covariant thunk, or we don't have the necessary
-code for efficient thunks, generate a thunk function that
-just makes a call to the real function. Unfortunately, this
-doesn't work for varargs. */
-
- if (varargs_function_p (function))
- error (generic thunk code fails for method %q#D which uses %...%,
- function);
-}
-
pop_from_top_level ();
}
Index: cgraphunit.c
===
--- cgraphunit.c(revision 220547)
+++ cgraphunit.c(working copy)
@@ -1559,6 +1559,14 @@ cgraph_node::expand_thunk (bool output_a
thunk.thunk_p = false;
analyzed = false;
}
+ else if (stdarg_p (TREE_TYPE (thunk_fndecl)))
+{
+ error (generic thunk code fails for method %qD which uses %...%,
+thunk_fndecl);
+ TREE_ASM_WRITTEN (thunk_fndecl) = 1;
+ analyzed = true;
+ return false;
+}
else
{
tree restype;
New template for 'gcc' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to coordina...@translationproject.org.) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/gcc-5.1-b20150208.pot 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. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150208/gcc-5-20150208.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Fix false positive on ODR violation warning
Hi,
this patch fixes one false positive seen while building Firefox with FDO.
There are case when we try to compare bases of a type that was not analyzed
yet. I rewrot ethe comparsion loop to walk BINFO_BASE_BINFO array instead
of comparing with the ODR_type representation. This is more precise becuase
it records non-polymorphic type, too, and turned the original loop into
a sanity check.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-devirt.c (odr_types_equivalent_p): Fix formating.
(add_type_duplicate): Fix comparison of BINFOs.
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 220509)
+++ ipa-devirt.c(working copy)
@@ -807,7 +807,8 @@ warn_types_mismatch (tree t1, tree t2)
gimple_canonical_types_compatible_p. */
static bool
-odr_types_equivalent_p (tree t1, tree t2, bool warn, bool *warned,
hash_settype_pair,pair_traits *visited)
+odr_types_equivalent_p (tree t1, tree t2, bool warn, bool *warned,
+ hash_settype_pair,pair_traits *visited)
{
/* Check first for the obvious case of pointer identity. */
if (t1 == t2)
@@ -1206,8 +1207,8 @@ add_type_duplicate (odr_type val, tree t
val-types_set = new hash_settree;
/* Always prefer complete type to be the leader. */
- if (!COMPLETE_TYPE_P (val-type)
- COMPLETE_TYPE_P (type))
+ if ((!COMPLETE_TYPE_P (val-type) || !TYPE_BINFO (val-type))
+ (COMPLETE_TYPE_P (type) TYPE_BINFO (val-type)))
{
tree tmp = type;
@@ -1229,7 +1230,8 @@ add_type_duplicate (odr_type val, tree t
vec_safe_push (val-types, type);
/* First we compare memory layout. */
- if (!odr_types_equivalent_p (val-type, type, !flag_ltrans
!val-odr_violated,
+ if (!odr_types_equivalent_p (val-type, type,
+ !flag_ltrans !val-odr_violated,
warned, visited))
{
merge = false;
@@ -1253,31 +1255,105 @@ add_type_duplicate (odr_type val, tree t
TREE_CODE (type) == RECORD_TYPE
TYPE_BINFO (val-type) TYPE_BINFO (type))
{
- for (j = 0, i = 0; i BINFO_N_BASE_BINFOS (TYPE_BINFO (type)); i++)
- if (polymorphic_type_binfo_p (BINFO_BASE_BINFO (TYPE_BINFO (type),
i)))
+ if (BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
+ != BINFO_N_BASE_BINFOS (TYPE_BINFO (val-type)))
+ {
+ if (!warned !val-odr_violated)
+ {
+ tree extra_base;
+ warn_odr (type, val-type, NULL, NULL, !warned, warned,
+ a type with the same name but different
+ number of polymorphic bases is
+ defined in another translation unit);
+ if (BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
+ BINFO_N_BASE_BINFOS (TYPE_BINFO (val-type)))
+ extra_base = BINFO_BASE_BINFO
+(TYPE_BINFO (type),
+ BINFO_N_BASE_BINFOS (TYPE_BINFO (val-type)));
+ else
+ extra_base = BINFO_BASE_BINFO
+(TYPE_BINFO (val-type),
+ BINFO_N_BASE_BINFOS (TYPE_BINFO (type)));
+ inform (DECL_SOURCE_LOCATION
+ (TYPE_NAME (DECL_CONTEXT (extra_base))),
+ the extra base is defined here );
+ }
+ base_mismatch = true;
+ }
+ else
+ for (i = 0; i BINFO_N_BASE_BINFOS (TYPE_BINFO (type)); i++)
{
- odr_type base = get_odr_type
- (BINFO_TYPE
- (BINFO_BASE_BINFO (TYPE_BINFO (type),
-i)),
- true);
- if (val-bases.length () = j || val-bases[j] != base)
- base_mismatch = true;
- j++;
+ tree base1 = BINFO_BASE_BINFO (TYPE_BINFO (type), i);
+ tree base2 = BINFO_BASE_BINFO (TYPE_BINFO (val-type), i);
+ tree type1 = BINFO_TYPE (base1);
+ tree type2 = BINFO_TYPE (base2);
+
+ if (types_odr_comparable (type1, type2))
+ {
+ if (!types_same_for_odr (type1, type2))
+ base_mismatch = true;
+ }
+ else
+ {
+ hash_settype_pair,pair_traits visited;
+ if (!odr_types_equivalent_p (type1, type2, false, NULL,
+visited))
+ base_mismatch = true;
+ }
+ if (base_mismatch)
+ {
+ if (!warned !val-odr_violated)
+ warn_odr (type,
Re: C PATCH for PR64856 (initializing range of elements in C99)
On 02/09/2015 11:51 AM, Marek Polacek wrote: We reject the following testcase in C99 mode, because in C99 we always wrap COMPOUND_LITERAL_EXPR in a SAVE_EXPR when initializing a range of elements, even though the expression is required to be constant. As a consequence, we error out with initializer element is not constant. It's been like this since Roger's fold changes in 2003. Since the default is now gnu11, I think we should accept the code even in C99. So this patch makes the C FE treat the expression the same in both C90/C99 modes. There is no need to add any pedwarns at this spot. Ah, I see, the pedwarn already exists elsewhere. That threw me for a bit. The patch is ok. r~
Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c
This appears to be the first instance where 'target' and 'nonpic' have
been used in a dg-warning.
On Mon, Feb 9, 2015 at 2:40 PM, Dominique d'Humières domi...@lps.ens.fr wrote:
Le 9 févr. 2015 à 20:01, Dominique d'Humières domi...@lps.ens.fr a écrit :
Le 9 févr. 2015 à 19:10, Tom de Vries 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.c 2015-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.c 2015-02-09
11:38:40.0 +0100
+++ gcc/testsuite/gcc.dg/graphite/scop-19.c 2015-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 } } */
Cheers,
Dominique
Thanks,
- Tom
Avoid duplicate symbols produced by emutls
Hi,
this patch fixes issue with emutls outputting duplicate ddeifnitions of the vars
it creates becuase it sometimes inserts variable twice (once as alias target and
once as real var).
Bootstrapped/regtested x86_64-linux and HP regtested at at cris-elf.
PR ipa/61548
* tree-emutls.c (ipa_lower_emutls): Avoid duplicates in TLS_VARS.
Index: tree-emutls.c
===
--- tree-emutls.c (revision 220547)
+++ tree-emutls.c (working copy)
@@ -753,17 +753,19 @@ ipa_lower_emutls (void)
cgraph_node *func;
bool any_aliases = false;
tree ctor_body = NULL;
-
+ hash_set varpool_node * visited;
auto_vec varpool_node * tls_vars;
/* Examine all global variables for TLS variables. */
FOR_EACH_VARIABLE (var)
-if (DECL_THREAD_LOCAL_P (var-decl))
+if (DECL_THREAD_LOCAL_P (var-decl)
+!visited.add (var))
{
gcc_checking_assert (TREE_STATIC (var-decl)
|| DECL_EXTERNAL (var-decl));
tls_vars.safe_push (var);
- if (var-alias var-definition)
+ if (var-alias var-definition
+!visited.add (var-ultimate_alias_target ()))
tls_vars.safe_push (var-ultimate_alias_target ());
}
Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c
Also, aren't we pretty much the only target to default to PIC? So if
the 'target' and 'nonpic' testing is failing when used in the context
of dg-warning, wouldn't that appear functional on the nonpic targets?
That is, since the nonpic test is to check for __PIC__, if that fails
in dg-warning, wouldn't it 'appear' functional on nonpic targets, no?
On Mon, Feb 9, 2015 at 3:51 PM, Jack Howarth howarth.at@gmail.com wrote:
This appears to be the first instance where 'target' and 'nonpic' have
been used in a dg-warning.
On Mon, Feb 9, 2015 at 2:40 PM, Dominique d'Humières domi...@lps.ens.fr
wrote:
Le 9 févr. 2015 à 20:01, Dominique d'Humières domi...@lps.ens.fr a écrit :
Le 9 févr. 2015 à 19:10, Tom de Vries 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.c 2015-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.c 2015-02-09
11:38:40.0 +0100
+++ gcc/testsuite/gcc.dg/graphite/scop-19.c 2015-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 } } */
Cheers,
Dominique
Thanks,
- Tom
RE: [PATCH PR64705]Don't aggressively expand induction variable's base
The second time I missed patch in one day, I hate myself.
Here it is.
-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:
bb 5:
# ci_28 = PHI ci_12(D)(4), ci_17(6)
# ivtmp.13_31 = PHI ivtmp.13_25(4), ivtmp.13_27(6)
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 bb 6;
else
goto bb 7;
bb 6:
goto bb 5;
And it can be improved by this patch as below:
bb 5:
# steps_28 = PHI steps_12(D)(4), steps_17(6)
# iter_29 = PHI iter_15(4), iter_21(6)
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 bb 6;
else
goto bb 7;
bb 6:
goto bb 5;
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 bin.ch...@arm.com
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 bin.ch...@arm.com
PR tree-optimization/64705
* gcc.dg/tree-ssa/pr64705.c: New test.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 219574)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -1070,13 +1070,40 @@ determine_biv_step (gphi *phi)
return integer_zerop (iv.step) ? NULL_TREE : iv.step;
}
+/* Return the first non-invariant ssa var found in EXPR. */
+
+static tree
+extract_single_var_from_expr (tree expr)
+{
+ int i, n;
+ tree tmp;
+ enum tree_code code;
+
+ if (!expr || is_gimple_min_invariant (expr))
+return NULL;
+
+ code = TREE_CODE (expr);
+ if (IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (code)))
+{
+ n = TREE_OPERAND_LENGTH (expr);
+ for (i = 0; i n; i++)
+ {
+ tmp = extract_single_var_from_expr (TREE_OPERAND (expr, i));
+
+ if (tmp)
+ return tmp;
+ }
+}
+ return (TREE_CODE (expr) == SSA_NAME) ? expr : NULL;
+}
+
/* Finds basic ivs. */
static bool
find_bivs (struct ivopts_data *data)
{
gphi *phi;
- tree step, type, base;
+ tree step, type, base, stop;
bool found = false;
struct loop *loop = data-current_loop;
gphi_iterator psi;
@@ -1093,7 +1120,13 @@ find_bivs (struct ivopts_data *data)
continue;
base = PHI_ARG_DEF_FROM_EDGE (phi, loop_preheader_edge (loop));
- base = expand_simple_operations (base);
+ /* Stop expanding iv base at the first ssa var referred by iv step.
+Ideally we should stop at any ssa var, because that's expensive
+and unusual to happen, we just do it on the first one.
+
+See PR64705 for the rationale. */
+ stop = extract_single_var_from_expr (step);
+ base = expand_simple_operations (base, stop);
if (contains_abnormal_ssa_name_p (base)
|| contains_abnormal_ssa_name_p (step))
continue;
@@ -1165,7 +1198,7 @@ mark_bivs (struct ivopts_data *data)
static bool
find_givs_in_stmt_scev (struct ivopts_data *data, gimple stmt, affine_iv *iv)
{
[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: bb 5: # ci_28 = PHI ci_12(D)(4), ci_17(6) # ivtmp.13_31 = PHI ivtmp.13_25(4), ivtmp.13_27(6) 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 bb 6; else goto bb 7; bb 6: goto bb 5; And it can be improved by this patch as below: bb 5: # steps_28 = PHI steps_12(D)(4), steps_17(6) # iter_29 = PHI iter_15(4), iter_21(6) 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 bb 6; else goto bb 7; bb 6: goto bb 5; 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 bin.ch...@arm.com 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 bin.ch...@arm.com PR tree-optimization/64705 * gcc.dg/tree-ssa/pr64705.c: New test.
Re: [PATCH] PR64979: S/390: Fix setup of overflow area pointer in va_start
On Mon, Feb 09, 2015 at 10:50:34AM +0100, Andreas Krebbel wrote: Hi, the attached patch fixes a critical problem in the va_start expansion code in the S/390 backend. The problem exists since GCC 4.0. Ok to commit to 4.9 branch and mainline? No. This isn't a backend problem, but a bug in the tree-stdarg.c pass, so should be fixed there, for all targets, rather than just worked around by pessimizing unnecessarily one target. Jakub
Re: [PATCH] PR64979: S/390: Fix setup of overflow area pointer in va_start
On Mon, Feb 09, 2015 at 12:40:05PM +0100, Andreas Krebbel wrote:
On 02/09/2015 12:29 PM, Jakub Jelinek wrote:
On Mon, Feb 09, 2015 at 10:50:34AM +0100, Andreas Krebbel wrote:
Hi,
the attached patch fixes a critical problem in the va_start expansion
code in the S/390 backend. The problem exists since GCC 4.0.
Ok to commit to 4.9 branch and mainline?
No. This isn't a backend problem, but a bug in the tree-stdarg.c pass,
so should be fixed there, for all targets, rather than just worked around by
pessimizing unnecessarily one target.
I think for the overflow area pointer we would need a different flag
indicating whether a pointer to
the va_list structure escapes or not. To my understanding it is not correct
to only use the
va_list_gpr_size/va_list_fpr_size fields for that purpose. These only refer
to the va_arg expansions
in the current function.
No. The flag for the escapes is
if (va_list_escapes)
{
fun-va_list_gpr_size = VA_LIST_MAX_GPR_SIZE;
fun-va_list_fpr_size = VA_LIST_MAX_FPR_SIZE;
}
and has been that way since forever. Escape case is like no stdarg pass run
at all (-O0), it is a case where you don't know anything about it.
What I mean as a fix is something like untested following patch, though that
only fixes the case on the !va_list_simple_ptr targets like x86_64 or s390*,
but not say on i?86. Even on i?86 it should say that it escapes, because it
does, thus something is still wrong in the stdarg pass.
As you can see, the updated testcase fails even on x86_64-linux.
--- gcc/tree-stdarg.c.jj2015-01-09 21:59:44.0 +0100
+++ gcc/tree-stdarg.c 2015-02-09 12:47:12.020789728 +0100
@@ -856,22 +856,23 @@ pass_stdarg::execute (function *fun)
/* For va_list_simple_ptr, we have to check PHI nodes too. We treat
them as assignments for the purpose of escape analysis. This is
not needed for non-simple va_list because virtual phis don't perform
-any real data movement. */
- if (va_list_simple_ptr)
- {
- tree lhs, rhs;
- use_operand_p uop;
- ssa_op_iter soi;
+any real data movement. For !va_list_simple_ptr, check PHI nodes for
+taking address of the va_list vars. */
+ tree lhs, rhs;
+ use_operand_p uop;
+ ssa_op_iter soi;
- for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
- gsi_next (i))
- {
- gphi *phi = i.phi ();
- lhs = PHI_RESULT (phi);
+ for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
+ gsi_next (i))
+ {
+ gphi *phi = i.phi ();
+ lhs = PHI_RESULT (phi);
- if (virtual_operand_p (lhs))
- continue;
+ if (virtual_operand_p (lhs))
+ continue;
+ if (va_list_simple_ptr)
+ {
FOR_EACH_PHI_ARG (uop, phi, soi, SSA_OP_USE)
{
rhs = USE_FROM_PTR (uop);
@@ -894,6 +895,22 @@ pass_stdarg::execute (function *fun)
}
}
}
+ else
+ {
+ for (unsigned j = 0; !va_list_escapes
+ j gimple_phi_num_args (phi); ++j)
+ if (walk_tree (gimple_phi_arg_def_ptr (phi, j),
+ find_va_list_reference, wi, NULL))
+ {
+ if (dump_file (dump_flags TDF_DETAILS))
+ {
+ fputs (va_list escapes in , dump_file);
+ print_gimple_stmt (dump_file, phi, 0, dump_flags);
+ fputc ('\n', dump_file);
+ }
+ va_list_escapes = true;
+ }
+ }
}
for (gimple_stmt_iterator i = gsi_start_bb (bb);
@@ -916,8 +933,8 @@ pass_stdarg::execute (function *fun)
if (is_gimple_assign (stmt))
{
- tree lhs = gimple_assign_lhs (stmt);
- tree rhs = gimple_assign_rhs1 (stmt);
+ lhs = gimple_assign_lhs (stmt);
+ rhs = gimple_assign_rhs1 (stmt);
if (va_list_simple_ptr)
{
--- gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c.jj 2015-02-09 12:54:44.84401
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c2015-02-09 12:58:10.406875647
+0100
@@ -0,0 +1,22 @@
+/* PR target/64979 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-stdarg } */
+
+#include stdarg.h
+
+void bar (int x, va_list *ap);
+
+void
+foo (int x, ...)
+{
+ va_list ap;
+ int n;
+
+ va_start (ap, x);
+ n = va_arg (ap, int);
+ bar (x, (va_list *) ((n == 0) ? ((void *) 0) : ap));
+ va_end (ap);
+}
+
+/* { dg-final { scan-tree-dump foo: va_list escapes 1, needs to save all GPR
units and all FPR units stdarg } } */
+/* { dg-final { cleanup-tree-dump stdarg } } */
--- gcc/testsuite/gcc.c-torture/execute/pr64979.c.jj2015-02-09
12:54:01.867984625 +0100
+++
Re: Fix scan-tree-dump for scop-19.c
On Wed, Feb 4, 2015 at 10:45 AM, Tom de Vries tom_devr...@mentor.com wrote: Hi, I've observed a FAILURE for gcc.dg/graphite/scop-19.c with fpic: ... FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite number of SCoPs: 0 2 ... In the nonpic case, d_growable_string_resize is inlined into d_growable_string_append_buffer, and we have 2 functions with a loop, wich results in two 'number of SCoPs' entries. In the pic case, d_growable_string_resize is not inlined into d_growable_string_append_buffer (since it's not inlinable), and we have only one function with a loop, wich results in one 'number of SCoPs' entry. This patch updates the scan-tree-dump to match the pic/nonpic behaviour. OK for trunk? Ok. Thanks, RIchard. Thanks, - Tom
Re: [PATCH] Fix PR64764
On 09-02-15 09:59, Richard Biener wrote:
On Thu, 5 Feb 2015, Tom de Vries wrote:
On 26-01-15 15:47, Richard Biener wrote:
Index: gcc/testsuite/gcc.dg/uninit-19.c
===
--- gcc/testsuite/gcc.dg/uninit-19.c(revision 0)
+++ gcc/testsuite/gcc.dg/uninit-19.c(working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options -O -Wuninitialized } */
+
+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]; /* { dg-warning may be used uninitialized } */
+}
+
+void
+fn2 ()
+{
+ float *n;
+ if (l 6)
+n = c + m;
+ fn1 (l, d, e, g, i, h, k, n);
+}
Hi Richard,
this new test fails with -fpic, because fn1 is not inlined.
Adding static to fn1 allows it to pass both with and without -fpic. But that
change might affect whether it still serves as a regression test for this PR,
I'm not sure.
Another way to fix this could be to use the warning line number 22 instead 13
for fpic.
Either way is fine with me.
Committed using the method of different line number for -fpic.
Thanks,
- Tom
2015-02-09 Tom de Vries t...@codesourcery.com
* gcc.dg/uninit-19.c: Fix warning line for fpic.
---
gcc/testsuite/gcc.dg/uninit-19.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/uninit-19.c b/gcc/testsuite/gcc.dg/uninit-19.c
index 3113cab..fc7acea 100644
--- a/gcc/testsuite/gcc.dg/uninit-19.c
+++ b/gcc/testsuite/gcc.dg/uninit-19.c
@@ -10,7 +10,7 @@ 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]; /* { dg-warning may be used uninitialized } */
+b[3] = p10[a]; /* 13. */
}
void
@@ -19,5 +19,8 @@ fn2 ()
float *n;
if (l 6)
n = c + m;
- fn1 (l, d, e, g, i, h, k, n);
+ 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 } */
--
1.9.1
[PATCH PR64820] Fix ASan UAR detection fails on 32-bit targets if SSP is enabled.
Hi,
when testing I noticed, that if compile with both -fsanitize=address and
-fstack-protector for 32-bit architectures and run with
ASAN_OPTIONS=detect_stack_use_after_return=1, libsanitizer fails with:
==7299==AddressSanitizer CHECK failed:
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_poisoning.cc:25
((AddrIsAlignedByGranularity(addr + size))) != (0) (0x0, 0x0)
#0 0xf72d8afc in AsanCheckFailed
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_rtl.cc:68
#1 0xf72dda89 in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_common.cc:72
This happens because ssp inserts a stack guard into a function, that
confuses asan_emit_stack_protection to calculate right size parameter
for asan_stack_malloc.
This tiny patch resolves the issue.
Regtested with make -j12 -k check
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}' on x86_64-unknown-linux-gnu.
Bootstrapped, ASan-bootstrapped on x86_64-unknown-linux-gnu.
Ok to commit?
-Maxim
gcc/ChangeLog:
2015-02-09 Max Ostapenko m.ostape...@partner.samsung.com
PR sanitizer/64820
* cfgexpand.c (align_base): New function.
(alloc_stack_frame_space): Call it.
(expand_stack_vars): Align prev_frame to be sure
data-asan_vec elements aligned properly.
gcc/testsuite/ChangeLog:
2015-02-09 Max Ostapenko m.ostape...@partner.samsung.com
PR sanitizer/64820
* c-c++-common/asan/pr64820.c: New test.
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 7dfe1f6..7845a17 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -282,6 +282,15 @@ align_local_variable (tree decl)
return align / BITS_PER_UNIT;
}
+/* Align given offset BASE with ALIGN. Truncate up if ALIGN_UP is true,
+ down otherwise. Return truncated BASE value. */
+
+static inline unsigned HOST_WIDE_INT
+align_base (HOST_WIDE_INT base, unsigned HOST_WIDE_INT align, bool align_up)
+{
+ return align_up ? (base + align - 1) -align : base -align;
+}
+
/* Allocate SIZE bytes at byte alignment ALIGN from the stack frame.
Return the frame offset. */
@@ -293,17 +302,15 @@ alloc_stack_frame_space (HOST_WIDE_INT size, unsigned HOST_WIDE_INT align)
new_frame_offset = frame_offset;
if (FRAME_GROWS_DOWNWARD)
{
- new_frame_offset -= size + frame_phase;
- new_frame_offset = -align;
- new_frame_offset += frame_phase;
+ new_frame_offset
+ = align_base (frame_offset - frame_phase - size,
+ align, false) + frame_phase;
offset = new_frame_offset;
}
else
{
- new_frame_offset -= frame_phase;
- new_frame_offset += align - 1;
- new_frame_offset = -align;
- new_frame_offset += frame_phase;
+ new_frame_offset
+ = align_base (frame_offset - frame_phase, align, true) + frame_phase;
offset = new_frame_offset;
new_frame_offset += size;
}
@@ -1031,13 +1038,16 @@ expand_stack_vars (bool (*pred) (size_t), struct stack_vars_data *data)
base = virtual_stack_vars_rtx;
if ((flag_sanitize SANITIZE_ADDRESS) ASAN_STACK pred)
{
- HOST_WIDE_INT prev_offset = frame_offset;
+ HOST_WIDE_INT prev_offset
+ = align_base (frame_offset,
+ MAX (alignb, ASAN_RED_ZONE_SIZE),
+ FRAME_GROWS_DOWNWARD);
tree repr_decl = NULL_TREE;
-
offset
= alloc_stack_frame_space (stack_vars[i].size
+ ASAN_RED_ZONE_SIZE,
MAX (alignb, ASAN_RED_ZONE_SIZE));
+
data-asan_vec.safe_push (prev_offset);
data-asan_vec.safe_push (offset + stack_vars[i].size);
/* Find best representative of the partition.
diff --git a/gcc/testsuite/c-c++-common/asan/pr64820.c b/gcc/testsuite/c-c++-common/asan/pr64820.c
new file mode 100644
index 000..885a662
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/pr64820.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-require-effective-target fstack_protector } */
+/* { dg-options -fstack-protector-strong } */
+/* { dg-set-target-env-var ASAN_OPTIONS detect_stack_use_after_return=1 } */
+/* { dg-shouldfail asan } */
+
+__attribute__((noinline))
+char *Ident(char *x) {
+ return x;
+}
+
+__attribute__((noinline))
+char *Func1() {
+ char local[1 12];
+ return Ident(local);
+}
+
+__attribute__((noinline))
+void Func2(char *x) {
+ *x = 1;
+}
+int main(int argc, char **argv) {
+ Func2(Func1());
+ return 0;
+}
+
+/* { dg-output AddressSanitizer: stack-use-after-return on address 0x\[0-9a-f\]+\[^\n\r]*(\n|\r\n|\r) } */
+/* { dg-output WRITE of size 1 at .* thread T0.* } */
+/* { dg-output #0.*(Func2)?.*pr64820.(c:21)?.* } */
+/* { dg-output is located in stack of thread T0 at offset.* } */
Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris
Bruce Korb bk...@gnu.org writes:
On 01/29/15 05:38, Rainer Orth wrote:
So I saw. If all else fails, we can still commit the (ugly/hard to
read) initial version, otherwise libgo won't build on Solaris before
some (quite recent) Solaris 11.2 patch, breaking bootstrap.
Having it work at all seems like a nice feature.
I think that:
test-text = _EOF_
[[]]
_EOF_;
is likely still better than the quoted string, though.
Without the little hyphen (-), the leading tabs are
not stripped. At this point, whatever is easiest for you. :)
That worked fine indeed and is considerably more readable than my
previous version.
It produced the identical fixincl.x, passed fixincludes make check and
Solaris 10 and 11 bootstraps.
Ok for mainline now, I guess?
Thanks
Rainer
2014-06-25 Rainer Orth r...@cebitec.uni-bielefeld.de
fixincludes:
* inclhack.def (solaris_math_11): New fix.
* fixincl.x: Regenerate.
* tests/base/iso/math_c99.h [SOLARIS_MATH_11_CHECK]: New test.
gcc/testsuite:
* gcc.dg/signbit-sa.c: New test.
# HG changeset patch
# Parent 0cdc6d5a3025bfda451a6a0e6c304b36eaf39d8f
Fix iso/math_c99.h signbit on Solaris
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -3549,6 +3549,58 @@ fix = {
};
/*
+ * Newer Solaris 10/11 GCC signbit implementations cause strict-aliasing
+ * warnings.
+ */
+fix = {
+hackname = solaris_math_11;
+select = '@\(#\)math_c99\.h' [ \t]+1\\.[0-9]+[ \t]+[0-9/]+ ;
+files = iso/math_c99.h;
+c_fix = format;
+c_fix_arg = _EOArg_
+#undef signbit
+#define signbit(x) (sizeof(x) == sizeof(float) \
+ ? __builtin_signbitf(x) \
+ : sizeof(x) == sizeof(long double) \
+ ? __builtin_signbitl(x) \
+ : __builtin_signbit(x))
+_EOArg_;
+c_fix_arg = _EOArg_
+^#undef[ ]+signbit
+#if defined\(__sparc\)
+#define[ ]+signbit\(x\)[ ]+__extension__\( \\
+[ ]+\{[ ]*__typeof\(x\)[ ]*__x_s[ ]*=[ ]*\(x\);[ ]*\\
+[ ]+\(int\)[ ]*\(\*\(unsigned[ ]*\*\)[ ]*\__x_s[ ]*[ ]*31\);[ ]*\}\)
+#elif defined\(__i386\) \|\| defined\(__amd64\)
+#define[ ]+signbit\(x\)[ ]+__extension__\( \\
+[ ]+\{ __typeof\(x\) __x_s = \(x\); \\
+[ ]+\(sizeof \(__x_s\) == sizeof \(float\) \? \\
+[ ]+\(int\) \(\*\(unsigned \*\) \__x_s 31\) : \\
+[ ]+sizeof \(__x_s\) == sizeof \(double\) \? \\
+[ ]+\(int\) \(\(\(unsigned \*\) \__x_s\)\[1\] 31\) : \\
+[ ]+\(int\) \(\(\(unsigned short \*\) \__x_s\)\[4\] 15\)\); \}\)
+#endif
+_EOArg_;
+test_text = _EOText_
+/* @(#)math_c99.h 1.14 13/03/27 */
+#undef signbit
+#if defined(__sparc)
+#define signbit(x) __extension__( \\
+{ __typeof(x) __x_s = (x); \\
+(int) (*(unsigned *) __x_s 31); })
+#elif defined(__i386) || defined(__amd64)
+#define signbit(x) __extension__( \\
+ { __typeof(x) __x_s = (x); \\
+ (sizeof (__x_s) == sizeof (float) ? \\
+ (int) (*(unsigned *) __x_s 31) : \\
+ sizeof (__x_s) == sizeof (double) ? \\
+ (int) (((unsigned *) __x_s)[1] 31) : \\
+ (int) (((unsigned short *) __x_s)[4] 15)); })
+#endif
+_EOText_;
+};
+
+/*
* Sun Solaris defines PTHREAD_ONCE_INIT as an array containing a
* structure. As such, it need two levels of brackets, but only
* contains one. Wrap the macro definition in an extra layer.
diff --git a/fixincludes/tests/base/iso/math_c99.h b/fixincludes/tests/base/iso/math_c99.h
--- a/fixincludes/tests/base/iso/math_c99.h
+++ b/fixincludes/tests/base/iso/math_c99.h
@@ -75,3 +75,14 @@
#undef isunordered
#define isunordered(x, y) __builtin_isunordered(x, y)
#endif /* SOLARIS_MATH_9_CHECK */
+
+
+#if defined( SOLARIS_MATH_11_CHECK )
+/* @(#)math_c99.h 1.14 13/03/27 */
+#undef signbit
+#define signbit(x) (sizeof(x) == sizeof(float) \
+ ? __builtin_signbitf(x) \
+ : sizeof(x) == sizeof(long double) \
+ ? __builtin_signbitl(x) \
+ : __builtin_signbit(x))
+#endif /* SOLARIS_MATH_11_CHECK */
diff --git a/gcc/testsuite/gcc.dg/signbit-sa.c b/gcc/testsuite/gcc.dg/signbit-sa.c
new file mode 100644
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/signbit-sa.c
@@ -0,0 +1,11 @@
+/* Some versions of Solaris math.h give strict-aliasing warnings for
+ signbit. */
+/* { dg-options -std=c99 -O2 -Wstrict-aliasing } */
+
+#include math.h
+
+int
+main (void)
+{
+ return signbit (1.0f) | signbit (1.0) | signbit (1.0l);;
+}
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH, testsuite]: Xfail gcc.dg/c11-true_min-1.c execution for alpha*-*-*
Hello!
Attached patch xfails gcc.dg/c11-true_min-1.c execution for
alpha*-*-*. Without -mieee, it is not possible to compare a subnormal
number with zero on alpha targets, since any operation with subnormal
values will trigger a FPE.
2015-02-08 Uros Bizjak ubiz...@gmail.com
PR target/58757
* gcc.dg/c11-true_min-1.c: Xfail execution for alpha*-*-*.
Tested on alphaev68-linux-gnu and committed to mainline SVN.
Uros.
Index: gcc.dg/c11-true_min-1.c
===
--- gcc.dg/c11-true_min-1.c (revision 220527)
+++ gcc.dg/c11-true_min-1.c (working copy)
@@ -1,9 +1,10 @@
/* { dg-do run } */
/* { dg-options -std=c11 } */
+/* { dg-xfail-run-if PR58757 -mieee is required to compare denormals {
alpha*-*-* } { * } { } } */
/* Test that the smallest positive value is not 0. This needs to be true
even when denormals are not supported, so we do not pass any flag
- like -mieee. If it fails on alpha, see PR 58757. */
+ like -mieee. */
#include float.h
Re: nvptx offloading patches [2/n]
On Wed, Feb 4, 2015 at 11:55 AM, Jakub Jelinek ja...@redhat.com wrote: On Sat, Nov 01, 2014 at 12:51:32PM +0100, Bernd Schmidt wrote: LTO has a mechanism not to stream out common nodes that are expected to be identical on each run. When using LTO to communicate between compilers for different targets, the va_list_type_node and related ones must be excluded from this. Richard B mentioned in a recent mail that the i386 backend uses direct comparisons to va_list_type_node. After investigating a bit it seems to me that this is not actually a problem: what's being compared is the return value of ix86_canonical_va_list_type, which always chooses one of va_list_type_node or its ABI variants, so the comparison should hold even with this patch. Bootstrapped and tested on x86_64-linux, ok? How can the offloading of functions using va_start/va_end/va_arg work, until we apply (in GCC 6?) Michael's patches and extend them - make all those 3 internal functions lowered only after IPA? I mean, nvptx supposedly contains different va_list type (from quick glance it uses void *, while e.g. x86_64 uses a struct [1]), and we gimplify it early, so for GCC 5 the only option is IMHO to refuse to compile (sorry?) when streaming functions that use the host va_list type. For GCC 6, presumably if it is lowered late, if the host va_list would be at least as big as target va_list, we could stick stuff in there, or rewrite to the target va_list. Still, if e.g. va_list is embedded in structures, or used in global vars, we'd need to pad the structures or something. In principle I am always happy these days to preload less nodes. Thus, if your patch survives LTO bootstrap and you can still LTO a TU with ms_abi valist functions successfully (not sure if that's exercised in the testsuite) then it is fine. Note that I _did_ run into issues with excempting nodes from preloading because of pointer comparisons. The issue is that types created by the backends and the middle-end do not participate in the type merging done by LTO. Thus the actual issue may be not on x86 (because it implements the canonical_va_list_type hook) but on other targets that end up using std_canonical_va_list_type. Thanks, Richard. Jakub
Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.
On 07/02/15 00:11, Jonathan Wakely wrote: Any idea why HP still sees the tests fail? See comment 8 at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8 It looks like he's found the problem: that _NEWLIB_ is a recent addition that isn't in the version he's using. I'll try replacing _NEWLIB_ with _NEWLIB_VERSION_ as suggested. Matthew
Re: [PATCH] PR64979: S/390: Fix setup of overflow area pointer in va_start
On 02/09/2015 12:29 PM, Jakub Jelinek wrote: On Mon, Feb 09, 2015 at 10:50:34AM +0100, Andreas Krebbel wrote: Hi, the attached patch fixes a critical problem in the va_start expansion code in the S/390 backend. The problem exists since GCC 4.0. Ok to commit to 4.9 branch and mainline? No. This isn't a backend problem, but a bug in the tree-stdarg.c pass, so should be fixed there, for all targets, rather than just worked around by pessimizing unnecessarily one target. I think for the overflow area pointer we would need a different flag indicating whether a pointer to the va_list structure escapes or not. To my understanding it is not correct to only use the va_list_gpr_size/va_list_fpr_size fields for that purpose. These only refer to the va_arg expansions in the current function. Other backends rs6000/i386 unconditionally set up the overflow area pointer. -Andreas-
[gomp4] Merge trunk r219682 (2015-01-15) into gomp-4_0-branch
Hi!
In r220529, I have committed a merge from trunk r219682 (2015-01-15) into
gomp-4_0-branch. This is the trunk »Merge current set of OpenACC changes
From gomp-4_0-branch« commit, which -- obviously -- mostly has been
present on gomp-4_0-branch already; here's the additional cleanup that I
merged in:
contrib/ChangeLog | 5 +
gcc/ChangeLog | 180 +++
gcc/ada/ChangeLog | 5 +
gcc/builtin-types.def | 5 +-
gcc/c-family/ChangeLog | 38 +++
gcc/c-family/c-omp.c | 1 -
gcc/c/ChangeLog| 51 +++
gcc/c/c-parser.c | 9 +-
gcc/cp/ChangeLog | 45 +++
gcc/cp/parser.c| 9 +-
gcc/doc/invoke.texi| 4 +
gcc/fortran/ChangeLog | 196
gcc/fortran/gfortran.texi | 75 +++--
gcc/fortran/intrinsic.texi | 56 ++--
gcc/fortran/invoke.texi| 4 +
gcc/fortran/types.def | 5 +-
gcc/lto/ChangeLog | 7 +
gcc/testsuite/ChangeLog| 130
gcc/testsuite/c-c++-common/goacc/asyncwait-1.c | 97 +-
gcc/testsuite/c-c++-common/goacc/clauses-fail.c| 8 +-
gcc/testsuite/c-c++-common/goacc/data-2.c | 2 +-
include/ChangeLog | 6 +
libgomp/ChangeLog | 351 +
libgomp/Makefile.am| 6 +-
libgomp/Makefile.in| 12 +-
libgomp/env.c | 14 +-
libgomp/error.c| 2 +-
libgomp/libgomp-plugin.c | 9 +-
libgomp/libgomp-plugin.h | 10 +-
libgomp/libgomp.h | 67 ++--
libgomp/libgomp.map| 8 +-
libgomp/libgomp.texi | 5 +
libgomp/oacc-cuda.c| 2 +-
libgomp/oacc-host.c| 23 +-
libgomp/oacc-init.c| 18 +-
libgomp/oacc-int.h | 14 +-
libgomp/oacc-mem.c | 34 +-
libgomp/oacc-parallel.c| 1 -
libgomp/oacc-plugin.c | 2 +-
libgomp/oacc-plugin.h | 6 +-
libgomp/openacc.h | 131
libgomp/plugin/plugin-host.c | 66 ++--
libgomp/plugin/plugin-nvptx.c | 16 +-
libgomp/splay-tree.c | 9 +-
libgomp/splay-tree.h | 21 --
libgomp/target.c | 32 +-
libgomp/testsuite/lib/libgomp.exp | 9 +-
.../{abort.c = abort-1.c} | 0
.../testsuite/libgomp.oacc-c-c++-common/data-3.c | 2 +-
libgomp/testsuite/libgomp.oacc-c-c++-common/if-1.c | 71 -
.../testsuite/libgomp.oacc-c-c++-common/nested-2.c | 142 +++--
libgomp/testsuite/libgomp.oacc-fortran/lib-11.f90 | 82 -
libgomp/testsuite/libgomp.oacc-fortran/lib-9.f90 | 83 -
liboffloadmic/ChangeLog| 5 +
54 files changed, 1565 insertions(+), 626 deletions(-)
diff --git contrib/ChangeLog contrib/ChangeLog
index 1f02d95..f062ea9 100644
--- contrib/ChangeLog
+++ contrib/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-15 Thomas Schwinge tho...@codesourcery.com
+
+ * gcc_update (files_and_dependencies): Update rules for new
+ libgomp/plugin/Makefrag.am and libgomp/plugin/configfrag.ac files.
+
2015-01-12 Yury Gribov y.gri...@samsung.com
* check_GNU_style.sh: Support patches coming from stdin.
diff --git gcc/ChangeLog gcc/ChangeLog
index d40a3f0..3a27df9 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,183 @@
+2015-01-15 Thomas Schwinge tho...@codesourcery.com
+ Bernd Schmidt ber...@codesourcery.com
+ Cesar Philippidis ce...@codesourcery.com
+ James Norris jnor...@codesourcery.com
+ Tom de Vries t...@codesourcery.com
+ Ilmir Usmanov i.usma...@samsung.com
+ Dmitry Bocharnikov dmitr...@samsung.com
+ Evgeny Gavrin e.gav...@samsung.com
+ Jakub Jelinek ja...@redhat.com
+
+ * builtin-types.def (BT_FN_VOID_INT_INT_VAR)
+ (BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_PTR_INT_INT_VAR)
+ (BT_FN_VOID_INT_OMPFN_PTR_SIZE_PTR_PTR_PTR_INT_INT_INT_INT_INT_VAR):
+ New function types.
+ * builtins.c:
Re: nvptx offloading patches [3/n], RFD
On Wed, Feb 4, 2015 at 12:38 PM, Jakub Jelinek ja...@redhat.com wrote: On Sat, Nov 01, 2014 at 12:57:45PM +0100, Bernd Schmidt wrote: This is not against current trunk; it applies to gomp-4_0-branch where it is one of the necessary parts to make offloading x86-nvptx work. The issue is that the LTO file format depends on the machine_modes enum, it needs to match between host and offload target. The easiest way to do this is to just use the host-modes.def when compiling an offload compiler. Ports that want to be hosts for offloading may need to modify their modes.def. The patch below contains changes to i386-modes.def which modifies XFmode depending on a target switch. I'm not actually entirely sure what to do about this. Do we want to make this flag an error when offloading is enabled? Or maybe add float format support to the -foffload-abi option? Thoughts? Ok for the first part of the patch once the other offloading patches have gone in (bootstrapped and tested on x86_64-linux)? I don't like this at all. IMHO instead we should stream in the offloading LTO sections some kind of mode description table (perhaps limited to the modes actually ever streamed), and when reading back the offloading LTO sections, let the offloading compiler remap the modes to its own modes where there is a mapping in between the two, choose some other mapping (e.g. map various vector modes the host has but offloading target does not to say BLKmode), or give up otherwise with offloading (say if you attempt to stream floating point modes the offloading target doesn't support etc.). So perhaps stream for each used mode the mode value, corresponding mode class, size, precision, inner mode, nunits, and for floating point modes supposedly somehow encode the real_format (perhaps just add a name - struct real_format mapping for the real.c modes, and map anything else to unknown). I think (also communicated that on IRC) we should instead try not streaming machine-modes at all but generating them at stream-in time via layout_type or layout_decl. Richard. Jakub
[committed] Fix -fsanitize=address md builtin expansion (PR sanitizer/64981)
Hi!
asan_intercepted_p only looks at fcode and obviously means only
BUILT_IN_NORMAL builtins, so we should ignore it for BUILT_IN_MD builtins.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2015-02-09 Jakub Jelinek ja...@redhat.com
PR sanitizer/64981
* builtins.c (expand_builtin): Call targetm.expand_builtin
for BUILT_IN_MD builtins regardless of asan_intercepted_p.
* gcc.dg/asan/pr64981.c: New test.
--- gcc/builtins.c.jj 2015-01-21 10:29:52.0 +0100
+++ gcc/builtins.c 2015-02-09 14:02:35.814716664 +0100
@@ -5960,6 +5960,9 @@ expand_builtin (tree exp, rtx target, rt
machine_mode target_mode = TYPE_MODE (TREE_TYPE (exp));
int flags;
+ if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD)
+return targetm.expand_builtin (exp, target, subtarget, mode, ignore);
+
/* When ASan is enabled, we don't want to expand some memory/string
builtins and rely on libsanitizer's hooks. This allows us to avoid
redundant checks and be sure, that possible overflow will be detected
@@ -5968,9 +5971,6 @@ expand_builtin (tree exp, rtx target, rt
if ((flag_sanitize SANITIZE_ADDRESS) asan_intercepted_p (fcode))
return expand_call (exp, target, ignore);
- if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD)
-return targetm.expand_builtin (exp, target, subtarget, mode, ignore);
-
/* When not optimizing, generate calls to library functions for a certain
set of builtins. */
if (!optimize
--- gcc/testsuite/gcc.dg/asan/pr64981.c.jj 2015-02-09 14:05:50.252487512
+0100
+++ gcc/testsuite/gcc.dg/asan/pr64981.c 2015-02-09 14:05:34.0 +0100
@@ -0,0 +1,12 @@
+/* PR sanitizer/64981 */
+/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-options -fsanitize=address -march=x86-64 } */
+
+int
+main ()
+{
+ __builtin_ia32_rdtsc ();
+ return 0;
+}
+
+/* { dg-final { scan-assembler-not __builtin_ia32_rdtsc } } */
Jakub
New Finnish 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 Finnish team of translators. The file is available at: http://translationproject.org/latest/cpplib/fi.po (This file, 'cpplib-5.1-b20150208.fi.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. coordina...@translationproject.org
Re: Fix PR 63566 part 3
On 02/09/2015 04:01 PM, Jan Hubicka wrote: I had to dro # in the error message, I am not quite sure what it means. It just means more verbose. Jason, what do you think? Looks fine to me. Jason
Contents of PO file 'cpplib-5.1-b20150208.fi.po'
cpplib-5.1-b20150208.fi.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [PATCH] PR64979: S/390: Fix setup of overflow area pointer in va_start
On Mon, Feb 09, 2015 at 01:05:23PM +0100, Jakub Jelinek wrote:
As you can see, the updated testcase fails even on x86_64-linux.
Here is an updated patch that succeeds even on i686-linux.
2015-02-09 Jakub Jelinek ja...@redhat.com
PR target/64979
* tree-stdarg.c (pass_stdarg::execute): Scan phi node args for
va_list escapes.
* gcc.dg/tree-ssa/stdarg-7.c: New test.
* gcc.c-torture/execute/pr64979.c: New test.
--- gcc/tree-stdarg.c.jj2015-01-09 21:59:44.0 +0100
+++ gcc/tree-stdarg.c 2015-02-09 13:14:43.880406573 +0100
@@ -856,22 +856,23 @@ pass_stdarg::execute (function *fun)
/* For va_list_simple_ptr, we have to check PHI nodes too. We treat
them as assignments for the purpose of escape analysis. This is
not needed for non-simple va_list because virtual phis don't perform
-any real data movement. */
- if (va_list_simple_ptr)
+any real data movement. Also, check PHI nodes for taking address of
+the va_list vars. */
+ tree lhs, rhs;
+ use_operand_p uop;
+ ssa_op_iter soi;
+
+ for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
+ gsi_next (i))
{
- tree lhs, rhs;
- use_operand_p uop;
- ssa_op_iter soi;
+ gphi *phi = i.phi ();
+ lhs = PHI_RESULT (phi);
- for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
- gsi_next (i))
- {
- gphi *phi = i.phi ();
- lhs = PHI_RESULT (phi);
-
- if (virtual_operand_p (lhs))
- continue;
+ if (virtual_operand_p (lhs))
+ continue;
+ if (va_list_simple_ptr)
+ {
FOR_EACH_PHI_ARG (uop, phi, soi, SSA_OP_USE)
{
rhs = USE_FROM_PTR (uop);
@@ -894,6 +895,22 @@ pass_stdarg::execute (function *fun)
}
}
}
+
+ for (unsigned j = 0; !va_list_escapes
+ j gimple_phi_num_args (phi); ++j)
+ if ((!va_list_simple_ptr
+|| TREE_CODE (gimple_phi_arg_def (phi, j)) != SSA_NAME)
+walk_tree (gimple_phi_arg_def_ptr (phi, j),
+ find_va_list_reference, wi, NULL))
+ {
+ if (dump_file (dump_flags TDF_DETAILS))
+ {
+ fputs (va_list escapes in , dump_file);
+ print_gimple_stmt (dump_file, phi, 0, dump_flags);
+ fputc ('\n', dump_file);
+ }
+ va_list_escapes = true;
+ }
}
for (gimple_stmt_iterator i = gsi_start_bb (bb);
@@ -916,8 +933,8 @@ pass_stdarg::execute (function *fun)
if (is_gimple_assign (stmt))
{
- tree lhs = gimple_assign_lhs (stmt);
- tree rhs = gimple_assign_rhs1 (stmt);
+ lhs = gimple_assign_lhs (stmt);
+ rhs = gimple_assign_rhs1 (stmt);
if (va_list_simple_ptr)
{
--- gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c.jj 2015-02-09 12:54:44.84401
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c2015-02-09 12:58:10.406875647
+0100
@@ -0,0 +1,22 @@
+/* PR target/64979 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-stdarg } */
+
+#include stdarg.h
+
+void bar (int x, va_list *ap);
+
+void
+foo (int x, ...)
+{
+ va_list ap;
+ int n;
+
+ va_start (ap, x);
+ n = va_arg (ap, int);
+ bar (x, (va_list *) ((n == 0) ? ((void *) 0) : ap));
+ va_end (ap);
+}
+
+/* { dg-final { scan-tree-dump foo: va_list escapes 1, needs to save all GPR
units and all FPR units stdarg } } */
+/* { dg-final { cleanup-tree-dump stdarg } } */
--- gcc/testsuite/gcc.c-torture/execute/pr64979.c.jj2015-02-09
12:54:01.867984625 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr64979.c 2015-02-09
13:08:17.458818847 +0100
@@ -0,0 +1,36 @@
+/* PR target/64979 */
+
+#include stdarg.h
+
+void __attribute__((noinline, noclone))
+bar (int x, va_list *ap)
+{
+ if (ap)
+{
+ int i;
+ for (i = 0; i 10; i++)
+ if (i != va_arg (*ap, int))
+ __builtin_abort ();
+ if (va_arg (*ap, double) != 0.5)
+ __builtin_abort ();
+}
+}
+
+void __attribute__((noinline, noclone))
+foo (int x, ...)
+{
+ va_list ap;
+ int n;
+
+ va_start (ap, x);
+ n = va_arg (ap, int);
+ bar (x, (va_list *) ((n == 0) ? ((void *) 0) : ap));
+ va_end (ap);
+}
+
+int
+main ()
+{
+ foo (100, 1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0.5);
+ return 0;
+}
Jakub
Re: [Ping] Port of VTV for Cygwin and MinGW
Hi! On Wed, 28 Jan 2015 14:58:04 -0800, Caroline Tice cmt...@google.com wrote: Since all the pieces of this patch have been approved, I will commit it later today (since Patrick does not have commit privileges). (This happened in r220232 and r220254.) I'm seeing: [...] checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate /scratch/tschwing/nvidiak20-2/gcc/trunk-big/source-gcc/libvtv/configure: line 15491: ACX_LT_HOST_FLAGS: command not found configure: updating cache ./config.cache configure: creating ./config.status [...] As obvious, I committed the following in r220535: commit a9983ab2160733f677d3d0e78b60d1a1659addd0 Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Feb 9 11:41:22 2015 + libvtv: autoreconf. libvtv/ * Makefile.in: Regenerate. * aclocal.m4: Likewise. * configure: Likewise. * testsuite/Makefile.in: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@220535 138bc75d-0d04-0410-961f-82ee72b054a4 --- libvtv/ChangeLog |7 +++ libvtv/Makefile.in |2 ++ libvtv/aclocal.m4|1 + libvtv/configure | 28 +--- libvtv/testsuite/Makefile.in |2 ++ 5 files changed, 37 insertions(+), 3 deletions(-) diff --git libvtv/ChangeLog libvtv/ChangeLog index 7dd9f09..dd8d2a4 100644 --- libvtv/ChangeLog +++ libvtv/ChangeLog @@ -1,3 +1,10 @@ +2015-02-09 Thomas Schwinge tho...@codesourcery.com + + * Makefile.in: Regenerate. + * aclocal.m4: Likewise. + * configure: Likewise. + * testsuite/Makefile.in: Likewise. + 2015-01-29 Caroline Tice cmt...@google.com Committing VTV Cywin/Ming patch for Patrick Wollgast diff --git libvtv/Makefile.in libvtv/Makefile.in index 098ee88..bc472fd 100644 --- libvtv/Makefile.in +++ libvtv/Makefile.in @@ -46,6 +46,7 @@ am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ $(top_srcdir)/../config/depstand.m4 \ $(top_srcdir)/../config/lead-dot.m4 \ $(top_srcdir)/../config/libstdc++-raw-cxx.m4 \ + $(top_srcdir)/../config/lthostflags.m4 \ $(top_srcdir)/../config/multi.m4 \ $(top_srcdir)/../config/override.m4 \ $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \ @@ -257,6 +258,7 @@ libvtv_builddir = @libvtv_builddir@ libvtv_srcdir = @libvtv_srcdir@ localedir = @localedir@ localstatedir = @localstatedir@ +lt_host_flags = @lt_host_flags@ mandir = @mandir@ mkdir_p = @mkdir_p@ multi_basedir = @multi_basedir@ diff --git libvtv/aclocal.m4 libvtv/aclocal.m4 index 5478f2b..cb5eb67 100644 --- libvtv/aclocal.m4 +++ libvtv/aclocal.m4 @@ -1007,6 +1007,7 @@ m4_include([../config/acx.m4]) m4_include([../config/depstand.m4]) m4_include([../config/lead-dot.m4]) m4_include([../config/libstdc++-raw-cxx.m4]) +m4_include([../config/lthostflags.m4]) m4_include([../config/multi.m4]) m4_include([../config/override.m4]) m4_include([../ltoptions.m4]) diff --git libvtv/configure libvtv/configure index 64b6f75..a7211b8 100755 --- libvtv/configure +++ libvtv/configure @@ -608,6 +608,7 @@ XCFLAGS libtool_VERSION enable_static enable_shared +lt_host_flags CXXCPP OTOOL64 OTOOL @@ -12129,7 +12130,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat conftest.$ac_ext _LT_EOF -#line 12132 configure +#line 12133 configure #include confdefs.h #if HAVE_DLFCN_H @@ -12235,7 +12236,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat conftest.$ac_ext _LT_EOF -#line 12238 configure +#line 12239 configure #include confdefs.h #if HAVE_DLFCN_H @@ -15488,7 +15489,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu # Only expand once: -ACX_LT_HOST_FLAGS + + + +case $host in + *-cygwin* | *-mingw*) +# 'host' will be top-level target in the case of a target lib, +# we must compare to with_cross_host to decide if this is a native +# or cross-compiler and select where to install dlls appropriately. +if test -n $with_cross_host + test x$with_cross_host != xno; then + lt_host_flags='-no-undefined -bindir $(toolexeclibdir)'; +else + lt_host_flags='-no-undefined -bindir $(bindir)'; +fi +;; + *) +lt_host_flags= +;; +esac + + + diff --git libvtv/testsuite/Makefile.in libvtv/testsuite/Makefile.in index ba28e74..c8fd48c 100644 --- libvtv/testsuite/Makefile.in +++ libvtv/testsuite/Makefile.in @@ -41,6 +41,7 @@ am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ $(top_srcdir)/../config/depstand.m4 \ $(top_srcdir)/../config/lead-dot.m4 \ $(top_srcdir)/../config/libstdc++-raw-cxx.m4 \ + $(top_srcdir)/../config/lthostflags.m4 \ $(top_srcdir)/../config/multi.m4 \ $(top_srcdir)/../config/override.m4 \
Re: [Patch, fortran] PR61138 Wrong code with pointer-bounds remapping
Dear Mikael, I have the patch in my working tree since May 2014. It works as advertised without any visible side effect. Thanks, Dominique
Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing
On Mon, Feb 9, 2015 at 8:15 AM, Jeff Law l...@redhat.com wrote:
On 02/03/15 04:39, Richard Biener wrote:
I found that explicit types were ignored in some cases. It was
frustrating to say the least.
Huh, that would be a bug. Do you have a pattern where that happens?
I'll have to recreate them. In the mean time consider something else I'm
playing with that causes an odd error from genmatch...
/* If we have a narrowing conversion of an arithmetic or logical
operation where both are operands 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. */
(simplify
(convert (plus (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)))
(with { tree utype = unsigned_type_for (TREE_TYPE (@0));}
(convert (plus (convert:utype @0) (convert:utype @1)))
So given two narrow operands that get widened, added, and the final result
narrowed back down to the original operand types. Replace with convert the
operands to an unsigned type (of same size as the operand), operate on them
and convert to the final desired type.
This happens to fix 47477 (P2 regression). Works perfectly for the
testcase.
Of course we'd like to extend that to other operators... So, adding the
obvious for iterator...
(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)))
(with { tree utype = unsigned_type_for (TREE_TYPE (@0));}
(convert (op (convert:utype @0) (convert:utype @1)))
Which causes genmatch to barf:
build/genmatch --gimple /home/gcc/GIT-2/gcc/gcc/match.pd \
tmp-gimple-match.c
genmatch: two conversions in a row
Not only does genmatch barf, it doesn't give any indication what part of the
.pd file it found objectionable.
Yeah, I'll have to assign locations to more places at some point.
But the following fixes your testcase, committed to trunk as obvious.
Richard.
2015-02-09 Richard Biener rguent...@suse.de
* genmatch.c (replace_id): Copy expr_type.
Index: gcc/genmatch.c
===
--- gcc/genmatch.c (revision 220540)
+++ gcc/genmatch.c (working copy)
@@ -982,6 +982,7 @@ replace_id (operand *o, user_id *id, id_
{
expr *ne = new expr (e-operation == id ? with : e-operation,
e-is_commutative);
+ ne-expr_type = e-expr_type;
for (unsigned i = 0; i e-ops.length (); ++i)
ne-append_op (replace_id (e-ops[i], id, with));
return ne;
Re: [PATCH] PR64979: S/390: Fix setup of overflow area pointer in va_start
On Mon, Feb 9, 2015 at 1:17 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Feb 09, 2015 at 01:05:23PM +0100, Jakub Jelinek wrote:
As you can see, the updated testcase fails even on x86_64-linux.
Here is an updated patch that succeeds even on i686-linux.
Ok if it fixes s390.
Thanks,
Richard.
2015-02-09 Jakub Jelinek ja...@redhat.com
PR target/64979
* tree-stdarg.c (pass_stdarg::execute): Scan phi node args for
va_list escapes.
* gcc.dg/tree-ssa/stdarg-7.c: New test.
* gcc.c-torture/execute/pr64979.c: New test.
--- gcc/tree-stdarg.c.jj2015-01-09 21:59:44.0 +0100
+++ gcc/tree-stdarg.c 2015-02-09 13:14:43.880406573 +0100
@@ -856,22 +856,23 @@ pass_stdarg::execute (function *fun)
/* For va_list_simple_ptr, we have to check PHI nodes too. We treat
them as assignments for the purpose of escape analysis. This is
not needed for non-simple va_list because virtual phis don't perform
-any real data movement. */
- if (va_list_simple_ptr)
+any real data movement. Also, check PHI nodes for taking address of
+the va_list vars. */
+ tree lhs, rhs;
+ use_operand_p uop;
+ ssa_op_iter soi;
+
+ for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
+ gsi_next (i))
{
- tree lhs, rhs;
- use_operand_p uop;
- ssa_op_iter soi;
+ gphi *phi = i.phi ();
+ lhs = PHI_RESULT (phi);
- for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
- gsi_next (i))
- {
- gphi *phi = i.phi ();
- lhs = PHI_RESULT (phi);
-
- if (virtual_operand_p (lhs))
- continue;
+ if (virtual_operand_p (lhs))
+ continue;
+ if (va_list_simple_ptr)
+ {
FOR_EACH_PHI_ARG (uop, phi, soi, SSA_OP_USE)
{
rhs = USE_FROM_PTR (uop);
@@ -894,6 +895,22 @@ pass_stdarg::execute (function *fun)
}
}
}
+
+ for (unsigned j = 0; !va_list_escapes
+ j gimple_phi_num_args (phi); ++j)
+ if ((!va_list_simple_ptr
+|| TREE_CODE (gimple_phi_arg_def (phi, j)) != SSA_NAME)
+walk_tree (gimple_phi_arg_def_ptr (phi, j),
+ find_va_list_reference, wi, NULL))
+ {
+ if (dump_file (dump_flags TDF_DETAILS))
+ {
+ fputs (va_list escapes in , dump_file);
+ print_gimple_stmt (dump_file, phi, 0, dump_flags);
+ fputc ('\n', dump_file);
+ }
+ va_list_escapes = true;
+ }
}
for (gimple_stmt_iterator i = gsi_start_bb (bb);
@@ -916,8 +933,8 @@ pass_stdarg::execute (function *fun)
if (is_gimple_assign (stmt))
{
- tree lhs = gimple_assign_lhs (stmt);
- tree rhs = gimple_assign_rhs1 (stmt);
+ lhs = gimple_assign_lhs (stmt);
+ rhs = gimple_assign_rhs1 (stmt);
if (va_list_simple_ptr)
{
--- gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c.jj 2015-02-09 12:54:44.84401
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c2015-02-09 12:58:10.406875647
+0100
@@ -0,0 +1,22 @@
+/* PR target/64979 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-stdarg } */
+
+#include stdarg.h
+
+void bar (int x, va_list *ap);
+
+void
+foo (int x, ...)
+{
+ va_list ap;
+ int n;
+
+ va_start (ap, x);
+ n = va_arg (ap, int);
+ bar (x, (va_list *) ((n == 0) ? ((void *) 0) : ap));
+ va_end (ap);
+}
+
+/* { dg-final { scan-tree-dump foo: va_list escapes 1, needs to save all
GPR units and all FPR units stdarg } } */
+/* { dg-final { cleanup-tree-dump stdarg } } */
--- gcc/testsuite/gcc.c-torture/execute/pr64979.c.jj2015-02-09
12:54:01.867984625 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr64979.c 2015-02-09
13:08:17.458818847 +0100
@@ -0,0 +1,36 @@
+/* PR target/64979 */
+
+#include stdarg.h
+
+void __attribute__((noinline, noclone))
+bar (int x, va_list *ap)
+{
+ if (ap)
+{
+ int i;
+ for (i = 0; i 10; i++)
+ if (i != va_arg (*ap, int))
+ __builtin_abort ();
+ if (va_arg (*ap, double) != 0.5)
+ __builtin_abort ();
+}
+}
+
+void __attribute__((noinline, noclone))
+foo (int x, ...)
+{
+ va_list ap;
+ int n;
+
+ va_start (ap, x);
+ n = va_arg (ap, int);
+ bar (x, (va_list *) ((n == 0) ? ((void *) 0) : ap));
+ va_end (ap);
+}
+
+int
+main ()
+{
+ foo (100, 1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0.5);
+ return 0;
+}
Jakub
Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions
On 02 Feb 13:15, Jakub Jelinek 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.
If we will select option #1, the patch is ready.
Option #1 is just wrong. There is nothing wrong with such constructs
appearing in #pragma omp declare target functions etc., the problem is
if you hit them at runtime. You can very well have say #pragma omp declare
target function, that optionally invokes #pragma omp target region e.g.
based on its parameters, state of global variables, what other functions
return etc. - and the program can be written so that that condition just
never happens if the function is already offloaded.
I thought that If a target, target update, or target data construct appears
within a target region then the behavior is unspecified. applies to '#pragma
omp declare target' functions as well, but evidently this applies only to
'#pragma omp target' regions.
But there is another issue, I forgot to mention it in the first mail.
Here is a testcase:
int main ()
{
#pragma omp target
{
int x;
#pragma omp target map(to: x)
x;
}
}
This causes an ICE in the offload compiler, since .omp_data_sizes.3 and
.omp_data_kinds.4 are used in main._omp_fn.0, which should be compiled for
target, but these variables are static without 'declare target' attribute.
main ()
{
struct .omp_data_t.1 .omp_data_arr.2;
static long unsigned int .omp_data_sizes.3[1] = {4};
static unsigned char .omp_data_kinds.4[1] = {17};
GOMP_target (-1, main._omp_fn.0, 0B, 0, 0B, 0B, 0B);
}
main._omp_fn.0 (void * .omp_data_i)
{
struct .omp_data_t.1 .omp_data_arr.2;
int x;
.omp_data_arr.2.x = x;
GOMP_target (-1, main._omp_fn.1, 0B, 1, .omp_data_arr.2,
.omp_data_sizes.3, .omp_data_kinds.4);
}
main._omp_fn.1 (struct .omp_data_t.1 restrict .omp_data_i)
{
int x [value-expr: *.omp_data_i-x];
}
Therefore I wanted just to forbid nested target regions. Or should we make
omp_data_sizes and omp_data_kinds non-static?
-- Ilya
Re: patch to fix rtl documentation for new floating point comparisons
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
@findex ge
@cindex greater than
@@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
@item (ge:@var{m} @var{x} @var{y})
@itemx (geu:@var{m} @var{x} @var{y})
Like @code{gt} and @code{gtu} but test for ``greater than or equal''.
+If the operands are floating point, @code{ge} is a signaling
+comparison and corresponds to the IEC 60559
+@code{compareSignalingGreater} operation. @code{geu} is undefined for
+floating point numbers.
No, compareSignalingGreaterEqual.
@findex le
@cindex less than or equal
@@ -2610,7 +2629,64 @@ Like @code{gt} and @code{gtu} but test f
@cindex unsigned less than
@item (le:@var{m} @var{x} @var{y})
@itemx (leu:@var{m} @var{x} @var{y})
-Like @code{gt} and @code{gtu} but test for ``less than or equal''.
+Like @code{gt} and @code{gtu} but test for ``less than or equal''. If
+the operands are floating point, @code{le} is a signaling comparison
+and corresponds to the IEC 60559 @code{compareSignalingLess}
+operation. @code{leu} is undefined for floating point numbers.
compareSignalingLessEqual.
+@table @code
+@findex ltgt
+@cindex less than or greater than
+@item (ltgt:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are less, or greater, otherwise 0. This is a quiet operation
+that applies only to floating point operands and does not have a
+corresponding IEC 60559 operation.
On GENERIC, the documentation describes some ambiguity: With the possible
exception of @code{LTGT_EXPR}, all of these operations are guaranteed
not to generate a floating point exception..
LTGT (RTL code) was added by RTH in
https://gcc.gnu.org/ml/gcc-patches/2000-01/msg00974.html. LTGT_EXPR was
added in the thread starting at
https://gcc.gnu.org/ml/gcc-patches/2004-05/msg01674.html, wherein RTH
stated the LTGT rtl code is assumed to trap. The documentation was soon
thereafter changed to have the possible exception wording (r82467, which
I can't find any sign of having been posted to gcc-patches so don't know
the rationale).
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).
It's not clear to me that ad hoc logic around particular operations is the
best way of handling optimizations in this area, instead of generic logic
using four bits to track which conditions ( = unordered) a comparison
is true for and one bit to track whether it raises an exception for
unordered operands. Even if you keep using particular sets of tree / RTL
codes for a subset of operations, maybe transformations that map into and
out of such five-bit form would be more likely to be correct.
--
Joseph S. Myers
jos...@codesourcery.com
Re: patch to fix rtl documentation for new floating point comparisons
On 02/09/2015 11:10 AM, Kenneth Zadeck wrote:
+@table @code
+@findex ltgt
+@cindex less than or greater than
+@item (ltgt:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are less, or greater, otherwise 0. This is a quiet operation
+that applies only to floating point operands and does not have a
+corresponding IEC 60559 operation.
This is intended to match c99 7.12.14.5 islessgreater, which I believe is the
compareQuietNotEqual operation.
+@table @code
+@findex uneq
+@cindex unordered or equal
+@item (uneq:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are unordered or equal, otherwise 0. This is a quiet
+operation that applies only to floating point operands and does not
+have a corresponding IEC 60559 operation.
This is the strict inverse to LTGT, i.e. !compareQuietNotEqual, and you of
course note this is not the same as compareQuietEqual.
I believe that when the c99 math.h comparison builtins were added, treating
EQ+NE as quiet comparisons was common but not universal. It's possible this
could be simplified now.
r~
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. 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. jeff
Re: [PATCH 01/36] Create libiberty/libiberty.m4, have GDB and GDBserver use it
Bah, looks like I dropped gdb-patches@ by accident, adding it back (patch here: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00580.html). For the gcc folks, this is part of this series: https://sourceware.org/ml/gdb-patches/2015-02/msg00202.html Thanks, Pedro Alves On 02/09/2015 11:20 PM, Pedro Alves wrote: Converting GDB to be a C++ program, I stumbled on 'basename' issues, like: src/gdb/../include/ansidecl.h:169:64: error: new declaration ‘char* basename(const char*)’ /usr/include/string.h:597:26: error: ambiguates old declaration ‘const char* basename(const char*)’ which I believe led to this bit in gold's configure.ac: dnl We have to check these in C, not C++, because autoconf generates dnl tests which have no type information, and current glibc provides dnl multiple declarations of functions like basename when compiling dnl with C++. AC_CHECK_DECLS([basename, ffs, asprintf, vasprintf, snprintf, vsnprintf, strverscmp]) These checks IIUC intend to generate all the HAVE_DECL_FOO symbols that libiberty.h and ansidecl.h check. GDB is missing these checks currently, which results in the conflict shown above. I could just copy gold's bits over to GDB. But, since libiberty's ansidecl.h and libiberty.h check HAVE_DECL_XXX symbols, ISTM that all programs that use these headers should be doing the exact same corresponding AC_CHECK_DECLS autoconf checks, and that there's good potential for bit rot here. So I thought of adding a m4 file that projects that use libiberty can source to pull in the autoconf checks that libiberty needs done in order to use its public headers. Turns out that this has already happened. Since I first wrote this a few months back, libiberty gained more HAVE_DECL_FOO checks even, for the strtol friends replacements. Are the libiberty changes OK? libiberty/ChangeLog: 2015-02-09 Pedro Alves pal...@redhat.com * libiberty.m4: New file. gdb/ChangeLog: 2015-02-09 Pedro Alves pal...@redhat.com * acinclude.m4: Include libiberty.m4. * config.in, configure: Regenerate. * configure.ac: Call libiberty_INIT. gdb/gdbserver/ 2015-02-09 Pedro Alves pal...@redhat.com * acinclude.m4: Include libiberty.m4. * config.in, configure: Regenerate. * configure.ac: Call libiberty_INIT. --- gdb/acinclude.m4 | 3 + gdb/config.in | 45 ++ gdb/configure | 266 +++ gdb/configure.ac | 2 + gdb/gdbserver/acinclude.m4 | 3 + gdb/gdbserver/config.in| 41 ++ gdb/gdbserver/configure| 338 + gdb/gdbserver/configure.ac | 2 + libiberty/libiberty.m4 | 33 + 9 files changed, 679 insertions(+), 54 deletions(-) create mode 100644 libiberty/libiberty.m4 diff --git a/gdb/acinclude.m4 b/gdb/acinclude.m4 index 6f71486..ff4aff0 100644 --- a/gdb/acinclude.m4 +++ b/gdb/acinclude.m4 @@ -54,6 +54,9 @@ sinclude([../config/zlib.m4]) m4_include([common/common.m4]) +dnl For libiberty_INIT. +m4_include(../libiberty/libiberty.m4) + ## - ## ## ANSIfy the C compiler whenever possible. ## ## From Franc,ois Pinard ## diff --git a/gdb/config.in b/gdb/config.in index 806cbac..6a8df15 100644 --- a/gdb/config.in +++ b/gdb/config.in @@ -85,6 +85,17 @@ you don't. */ #undef HAVE_DECL_ADDR_NO_RANDOMIZE +/* Define to 1 if you have the declaration of `asprintf', and to 0 if you + don't. */ +#undef HAVE_DECL_ASPRINTF + +/* Define to 1 if you have the declaration of `basename(char *)', and to 0 if + you don't. */ +#undef HAVE_DECL_BASENAME + +/* Define to 1 if you have the declaration of `ffs', and to 0 if you don't. */ +#undef HAVE_DECL_FFS + /* Define to 1 if you have the declaration of `free', and to 0 if you don't. */ #undef HAVE_DECL_FREE @@ -117,6 +128,34 @@ */ #undef HAVE_DECL_STRSTR +/* Define to 1 if you have the declaration of `strtol', and to 0 if you don't. + */ +#undef HAVE_DECL_STRTOL + +/* Define to 1 if you have the declaration of `strtoll', and to 0 if you + don't. */ +#undef HAVE_DECL_STRTOLL + +/* Define to 1 if you have the declaration of `strtoul', and to 0 if you + don't. */ +#undef HAVE_DECL_STRTOUL + +/* Define to 1 if you have the declaration of `strtoull', and to 0 if you + don't. */ +#undef HAVE_DECL_STRTOULL + +/* Define to 1 if you have the declaration of `strverscmp', and to 0 if you + don't. */ +#undef HAVE_DECL_STRVERSCMP + +/* Define to 1 if you have the declaration of `vasprintf', and to 0 if you + don't. */ +#undef HAVE_DECL_VASPRINTF + +/* Define to 1 if you have the declaration of `vsnprintf', and to 0 if you + don't. */ +#undef HAVE_DECL_VSNPRINTF + /* Define to 1 if you have the dlfcn.h header file. */ #undef HAVE_DLFCN_H @@ -225,6
Re: [PATCH 09/36] floatformat.h: Wrap in extern C.
On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves pal...@redhat.com wrote:
Just like libiberty.h. So that C++ programs, such as GDB when built
as a C++ program, can use it.
Why is not needed for GCC building with C++ compiler?
Thanks,
Andrew
include/ChangeLog:
2015-02-09 Pedro Alves pal...@redhat.com
* floatformat.h [__cplusplus]: Wrap in extern C.
---
include/floatformat.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/floatformat.h b/include/floatformat.h
index 6b559864..71d332b 100644
--- a/include/floatformat.h
+++ b/include/floatformat.h
@@ -20,6 +20,10 @@ Foundation, Inc., 51 Franklin Street - Fifth Floor,
Boston, MA 02110-1301, USA.
#if !defined (FLOATFORMAT_H)
#define FLOATFORMAT_H 1
+#ifdef __cplusplus
+extern C {
+#endif
+
#include ansidecl.h
/* A floatformat consists of a sign bit, an exponent and a mantissa. Once
the
@@ -148,4 +152,8 @@ floatformat_from_double (const struct floatformat *,
const double *, void *);
extern int
floatformat_is_valid (const struct floatformat *fmt, const void *from);
+#ifdef __cplusplus
+}
+#endif
+
#endif /* defined (FLOATFORMAT_H) */
--
1.9.3
Re: [PATCH 09/36] floatformat.h: Wrap in extern C.
On 02/09/2015 11:35 PM, Andrew Pinski wrote: On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves pal...@redhat.com wrote: Just like libiberty.h. So that C++ programs, such as GDB when built as a C++ program, can use it. Why is not needed for GCC building with C++ compiler? Because it doesn't include it. The header of the file claims it is part of GDB, though MAINTAINERS nowadays says that everything under include/ is owned by GCC. Thanks, Pedro Alves
Re: [Ping] Re: [PATCH 1/3] Replace MD_REDIRECT_BRANCH with TARGET_CAN_FOLLOW_JUMP
Jeff Law l...@redhat.com wrote: Ping? https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02345.html Presumably you're pinging due to the reorg/doc changes? Those are fine :-) Thanks! I've committed it as revision 220552. Regards, kaz
Re: [PATCH 2/3] [SH] Add jump insn for -freorder-blocks-and-partition
This patch adds a new jump insn for the jump crossing between hot/cold pertitions and reenables -freorder-blocks-and-partition on SH in some cases. -- PR target/64761 * config/sh/sh.c (sh_option_override): Don't change -freorder-blocks-and-partition to -freorder-blocks even when unwinding is enabled. (sh_can_follow_jump): Return false if the followee jump is a crossing jump when -freorder-blocks-and-partition is specified. * config/sh/sh.md (*jump_compact_crossing): New insn. For the record, I've committed this SH specific patch https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02347.html which is the last piece of the fix for PR target/64761. Regards, kaz
Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.
On Mon, 9 Feb 2015, Matthew Wahab wrote:
On 07/02/15 00:11, Jonathan Wakely wrote:
Any idea why HP still sees the tests fail? See comment 8 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8
It looks like he's found the problem: that _NEWLIB_ is a recent addition that
isn't in the version he's using. I'll try replacing _NEWLIB_ with
_NEWLIB_VERSION_ as suggested.
(Careful with that macro spelling, if nothing else.)
Better to use existing mechanisms and stop playing with
target-related macros. Add this at the top (see other
placements of dg-options) and replace #if defined (__NEWLIB__)
with #ifdef NEWLINE_IN_CLASS_BLANK:
// { dg-options -DNEWLINE_IN_CLASS_BLANK { target newlib } }
brgds, H-P
Re: [PATCH PR43378]Add test case for the issue
On Mon, Feb 9, 2015 at 7:20 AM, Bin Cheng bin.ch...@arm.com wrote: And the missed patch. Thanks, bin -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 2:07 PM To: gcc-patches@gcc.gnu.org Subject: [PATCH PR43378]Add test case for the issue Hi, I crossed to PR43378 and found it had already been fixed on trunk long before. I am adding a test case and going to close it after this patch. The case is tested, Is it OK? Ok. Thanks, Richard. 2015-02-09 Bin Cheng bin.ch...@arm.com PR tree-optimization/43378 * gcc.dg/tree-ssa/pr43378.c: New test.
[PATCH, testsuite]: XFAIL ssa-dom-cse-2.c and pr42585.c for alpha*-*-*
Hello!
alpha defines MOVE_RATIO that doesn't fit these tests.
2015-02-09 Uros Bizjak ubiz...@gmail.com
* gcc.dg/tree-ssa/ssa-dom-cse-2.c: Xfail scan-tree-dump for alpha*-*-*.
* gcc.dg/tree-ssa/pr42585.c: Xfail scan-tree-dump-times for alpha*-*-*.
Tested on alpha-linux-gnu and committed to mainline SVN.
Uros.
Index: gcc.dg/tree-ssa/pr42585.c
===
--- gcc.dg/tree-ssa/pr42585.c (revision 220537)
+++ gcc.dg/tree-ssa/pr42585.c (working copy)
@@ -35,6 +35,6 @@
/* Whether the structs are totally scalarized or not depends on the
MOVE_RATIO macro definition in the back end. The scalarization will
not take place when using small values for MOVE_RATIO. */
-/* { dg-final { scan-tree-dump-times struct _fat_ptr _ans 0 optimized {
target { ! aarch64*-*-* arm*-*-* avr-*-* nds32*-*-* powerpc*-*-* s390*-*-*
sh*-*-* } } } } */
-/* { dg-final { scan-tree-dump-times struct _fat_ptr _T2 0 optimized {
target { ! aarch64*-*-* arm*-*-* avr-*-* nds32*-*-* powerpc*-*-* s390*-*-*
sh*-*-* } } } } */
+/* { dg-final { scan-tree-dump-times struct _fat_ptr _ans 0 optimized {
target { ! aarch64*-*-* alpha*-*-* arm*-*-* avr-*-* nds32*-*-* powerpc*-*-*
s390*-*-* sh*-*-* } } } } */
+/* { dg-final { scan-tree-dump-times struct _fat_ptr _T2 0 optimized {
target { ! aarch64*-*-* alpha*-*-* arm*-*-* avr-*-* nds32*-*-* powerpc*-*-*
s390*-*-* sh*-*-* } } } } */
/* { dg-final { cleanup-tree-dump optimized } } */
Index: gcc.dg/tree-ssa/ssa-dom-cse-2.c
===
--- gcc.dg/tree-ssa/ssa-dom-cse-2.c (revision 220537)
+++ gcc.dg/tree-ssa/ssa-dom-cse-2.c (working copy)
@@ -20,5 +20,5 @@
/* See PR63679 and PR64159, if the target forces the initializer to memory then
DOM is not able to perform this optimization. */
-/* { dg-final { scan-tree-dump return 28; optimized { xfail hppa*-*-*
powerpc*-*-* sparc*-*-* aarch64*-*-* } } } */
+/* { dg-final { scan-tree-dump return 28; optimized { xfail aarch64*-*-*
alpha*-*-* hppa*-*-* powerpc*-*-* sparc*-*-* } } } */
/* { dg-final { cleanup-tree-dump optimized } } */
ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
Hello,
I'd like to ping with a respin of the 7 patches for
the attribute target (thumb,arm) [0-6] :
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02461.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02463.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02467.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02468.html
In order to fix the various conflicts that have happened since, please
find attached the re-based patches to trunk rev #220529 (respectively
from above p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch,
p6,patch).
I understand the difficulty of reviewing those due to the code
reorganization, but maintaining them are really a pain since a conflict
happens at almost every update in the ARM back-end :-(
Comments, questions are welcome,
Many thanks
Christian
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 220436)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2015-02-06 Christian Bruel christian.br...@st.com
+
+ PR target/64835
+ * config/i386/i386.c (ix86_default_align): New function.
+ (ix86_override_options_after_change): Call ix86_default_align.
+ (TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): New hook.
+ (ix86_override_options_after_change): New function.
+
2015-02-04 Jan Hubicka hubi...@ucw.cz
Trevor Saunders tsaund...@mozilla.com
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 220436)
+++ gcc/config/i386/i386.c (working copy)
@@ -3105,6 +3105,35 @@
}
+/* Default align_* from the processor table. */
+
+static void
+ix86_default_align (struct gcc_options *opts)
+{
+ if (opts-x_align_loops == 0)
+{
+ opts-x_align_loops = processor_target_table[ix86_tune].align_loop;
+ align_loops_max_skip = processor_target_table[ix86_tune].align_loop_max_skip;
+}
+ if (opts-x_align_jumps == 0)
+{
+ opts-x_align_jumps = processor_target_table[ix86_tune].align_jump;
+ align_jumps_max_skip = processor_target_table[ix86_tune].align_jump_max_skip;
+}
+ if (opts-x_align_functions == 0)
+{
+ opts-x_align_functions = processor_target_table[ix86_tune].align_func;
+}
+}
+
+/* Implement TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE hook. */
+
+static void
+ix86_override_options_after_change (void)
+{
+ ix86_default_align (global_options);
+}
+
/* Override various settings based on options. If MAIN_ARGS_P, the
options are from the command line, otherwise they are from
attributes. */
@@ -3902,20 +3931,7 @@
opts-x_ix86_regparm = REGPARM_MAX;
/* Default align_* from the processor table. */
- if (opts-x_align_loops == 0)
-{
- opts-x_align_loops = processor_target_table[ix86_tune].align_loop;
- align_loops_max_skip = processor_target_table[ix86_tune].align_loop_max_skip;
-}
- if (opts-x_align_jumps == 0)
-{
- opts-x_align_jumps = processor_target_table[ix86_tune].align_jump;
- align_jumps_max_skip = processor_target_table[ix86_tune].align_jump_max_skip;
-}
- if (opts-x_align_functions == 0)
-{
- opts-x_align_functions = processor_target_table[ix86_tune].align_func;
-}
+ ix86_default_align (opts);
/* Provide default for -mbranch-cost= value. */
if (!opts_set-x_ix86_branch_cost)
@@ -51928,6 +51944,9 @@
#undef TARGET_PROMOTE_FUNCTION_MODE
#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
+#undef TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
+#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE ix86_override_options_after_change
+
#undef TARGET_MEMBER_TYPE_FORCES_BLK
#define TARGET_MEMBER_TYPE_FORCES_BLK ix86_member_type_forces_blk
Index: gcc/dwarf2cfi.c
===
--- gcc/dwarf2cfi.c (revision 220436)
+++ gcc/dwarf2cfi.c (working copy)
@@ -2941,7 +2941,6 @@
dw_trace_info cie_trace;
dw_stack_pointer_regnum = DWARF_FRAME_REGNUM (STACK_POINTER_REGNUM);
- dw_frame_pointer_regnum = DWARF_FRAME_REGNUM (HARD_FRAME_POINTER_REGNUM);
memset (cie_trace, 0, sizeof (cie_trace));
cur_trace = cie_trace;
@@ -2994,6 +2993,9 @@
static unsigned int
execute_dwarf2_frame (void)
{
+ /* Different HARD_FRAME_POINTER_REGNUM might coexist in the same file. */
+ dw_frame_pointer_regnum = DWARF_FRAME_REGNUM (HARD_FRAME_POINTER_REGNUM);
+
/* The first time we're called, compute the incoming frame state. */
if (cie_cfi_vec == NULL)
create_cie_data ();
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c (revision 220436)
+++ gcc/ipa-inline.c (working copy)
@@ -489,7 +489,7 @@
else if (opt_for_fn (callee-decl, optimize_size)
opt_for_fn (caller-decl, optimize_size)
||
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
In order to fix the various conflicts that have happened since, please find attached the re-based patches to trunk rev #220529 (respectively from above p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch, p6,patch). oops, please don't review p0.patch here. This last one will be reviewed separately by the i386 and middle-end maintainers. It was posted now accidentally and is useful only for testing. Thanks Christian
[Patch, fortran] PR61138 Wrong code with pointer-bounds remapping
Hello,
this is about a pointer bounds remapping regression introduced at
http://gcc.gnu.org/r190641
That revision introduced support for se.descriptor_only in
gfc_conv_expr_descriptor with this hunk:
Index: trans-array.c
===
--- trans-array.c (révision 220514)
+++ trans-array.c (copie de travail)
@@ -6574,7 +6574,7 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *ex
/* Create a new descriptor if the array doesn't have one. */
full = 0;
}
- else if (info-ref-u.ar.type == AR_FULL)
+ else if (info-ref-u.ar.type == AR_FULL || se-descriptor_only)
full = 1;
else if (se-direct_byref)
full = 0;
The problem comes from gfc_trans_pointer_assign, which uses several
times the same gfc_se struct, the first time with descriptor_only set,
the other times without clearing it.
This was not a problem before the above change, because the flag wasn't
looked at.
After the change however, one should make sure that descriptor_only is
not inherited from a previous use.
The fix proposed clears the flag upon reuse, which should match exactly
the original behaviour, making it rather safe, and suitable also for the
branches.
I have to admit that I'm not completely satisfied with it however.
I would prefer no GFC_SE reuse at all, namely collect every piece of
code in a separate struct, and merge them later explicitly into a block.
Alas, the code is not exactly straightforward to my eyes, and my
attempt in that direction to sneak some orthogonality in that madness
failed.
Anyway, regression tested on x86_64-linux, OK for trunk/4.9/4.8 ?
Mikael
2015-02-09 Mikael Morin mik...@gcc.gnu.org
PR fortran/61138
* trans-expr.c (gfc_trans_pointer_assignment): Clear DESCRIPTOR_ONLY
field before reusing LSE.
2015-02-09 Mikael Morin mik...@gcc.gnu.org
PR fortran/61138
gfortran.dg/pointer_remapping_9.f90: New.
Index: trans-expr.c
===
--- trans-expr.c (révision 220514)
+++ trans-expr.c (copie de travail)
@@ -7339,6 +7339,7 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gf
bound, bound, 0,
GFC_ARRAY_POINTER_CONT, false);
tmp = gfc_create_var (tmp, ptrtemp);
+ lse.descriptor_only = 0;
lse.expr = tmp;
lse.direct_byref = 1;
gfc_conv_expr_descriptor (lse, expr2);
@@ -7354,6 +7355,7 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gf
else if (expr2-expr_type == EXPR_VARIABLE)
{
/* Assign directly to the LHS's descriptor. */
+ lse.descriptor_only = 0;
lse.direct_byref = 1;
gfc_conv_expr_descriptor (lse, expr2);
strlen_rhs = lse.string_length;
@@ -7405,6 +7407,7 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gf
/* Assign to a temporary descriptor and then copy that
temporary to the pointer. */
tmp = gfc_create_var (TREE_TYPE (desc), ptrtemp);
+ lse.descriptor_only = 0;
lse.expr = tmp;
lse.direct_byref = 1;
gfc_conv_expr_descriptor (lse, expr2);
! { dg-do run }
!
! PR fortran/61138
! Wrong code with pointer-bounds remapping
!
! Contributed by Tobias Burnus bur...@net-b.de
implicit none
integer, target :: tgt(10)
integer, target, allocatable :: tgt2(:)
integer, pointer :: ptr(:)
tgt = [1,2,3,4,5,6,7,8,9,10]
tgt2 = [1,2,3,4,5,6,7,8,9,10]
ptr(-5:) = tgt(5:) ! Okay
if (size(ptr) /= 6 .or. lbound(ptr,1) /= -5) call abort()
if (any (ptr /= [5,6,7,8,9,10])) call abort()
ptr(-5:) = tgt2(5:) ! wrongly associates the whole array
print '(*(i4))', size(ptr), lbound(ptr)
print '(*(i4))', ptr
if (size(ptr) /= 6 .or. lbound(ptr,1) /= -5) call abort()
if (any (ptr /= [5,6,7,8,9,10])) call abort()
end
[PATCH] Fix LTO bitpack streaming
This re-arranges things so that we have a chance to optimize
the bitpacking to a series of shifts and bit operations with
constant operands. We still fail to fully optimize this due
to various reasons but the head of streamer_write_tree_bitfields
and streamer_read_tree_bitfields now looks sane.
LTO bootstrapped on x86_64-unknown-linux-gnu, applied.
It should give us a few % back in streaming performance.
Not sure if we want to expose our tree-struct hierarchy more
in this function - we do a quite non-sensical if-cascade in
streamer_read_tree_bitfields (but keeping a better one in-sync
with tree_node_structure_for_code and tree_contains_struct
is one more thing to remember when updating things there...).
Richard.
2015-02-09 Richard Biener rguent...@suse.de
* tree-streamer.h (streamer_pack_tree_bitfields): Remove.
(streamer_write_tree_bitfields): Declare.
* tree-streamer-in.c (unpack_ts_base_value_fields): Inline,
properly unpack padding.
(unpack_value_fields): Inline ...
(streamer_read_tree_bitfields): ... here.
* tree-streamer-out.c (pack_ts_base_value_fields): Inline
and properly add padding bits.
(streamer_pack_tree_bitfields): Fold into ...
(streamer_write_tree_bitfields): ... this new function,
exposing the bitpack object.
* lto-streamer-out.c (lto_write_tree_1): Call
streamer_write_tree_bitfields.
Index: gcc/tree-streamer.h
===
--- gcc/tree-streamer.h (revision 220535)
+++ gcc/tree-streamer.h (working copy)
@@ -85,8 +85,7 @@ void streamer_write_string_cst (struct o
struct lto_output_stream *, tree);
void streamer_write_chain (struct output_block *, tree, bool);
void streamer_write_tree_header (struct output_block *, tree);
-void streamer_pack_tree_bitfields (struct output_block *, struct bitpack_d *,
- tree);
+void streamer_write_tree_bitfields (struct output_block *, tree);
void streamer_write_tree_body (struct output_block *, tree, bool);
void streamer_write_integer_cst (struct output_block *, tree, bool);
void streamer_write_builtin (struct output_block *, tree);
Index: gcc/tree-streamer-in.c
===
--- gcc/tree-streamer-in.c (revision 220535)
+++ gcc/tree-streamer-in.c (working copy)
@@ -123,7 +123,7 @@ streamer_read_chain (struct lto_input_bl
/* Unpack all the non-pointer fields of the TS_BASE structure of
expression EXPR from bitpack BP. */
-static void
+static inline void
unpack_ts_base_value_fields (struct bitpack_d *bp, tree expr)
{
/* Note that the code for EXPR has already been unpacked to create EXPR in
@@ -158,6 +158,8 @@ unpack_ts_base_value_fields (struct bitp
TREE_STATIC (expr) = (unsigned) bp_unpack_value (bp, 1);
if (TREE_CODE (expr) != TREE_BINFO)
TREE_PRIVATE (expr) = (unsigned) bp_unpack_value (bp, 1);
+ else
+bp_unpack_value (bp, 1);
TREE_PROTECTED (expr) = (unsigned) bp_unpack_value (bp, 1);
TREE_DEPRECATED (expr) = (unsigned) bp_unpack_value (bp, 1);
if (TYPE_P (expr))
@@ -166,9 +168,12 @@ unpack_ts_base_value_fields (struct bitp
TYPE_ADDR_SPACE (expr) = (unsigned) bp_unpack_value (bp, 8);
}
else if (TREE_CODE (expr) == SSA_NAME)
-SSA_NAME_IS_DEFAULT_DEF (expr) = (unsigned) bp_unpack_value (bp, 1);
+{
+ SSA_NAME_IS_DEFAULT_DEF (expr) = (unsigned) bp_unpack_value (bp, 1);
+ bp_unpack_value (bp, 8);
+}
else
-bp_unpack_value (bp, 1);
+bp_unpack_value (bp, 9);
}
@@ -456,115 +461,102 @@ unpack_ts_omp_clause_value_fields (struc
}
}
-/* Unpack all the non-pointer fields in EXPR into a bit pack. */
-static void
-unpack_value_fields (struct data_in *data_in, struct bitpack_d *bp, tree expr)
+/* Read all the language-independent bitfield values for EXPR from IB.
+ Return the partially unpacked bitpack so the caller can unpack any other
+ bitfield values that the writer may have written. */
+
+struct bitpack_d
+streamer_read_tree_bitfields (struct lto_input_block *ib,
+ struct data_in *data_in, tree expr)
{
enum tree_code code;
+ struct bitpack_d bp;
+
+ /* Read the bitpack of non-pointer values from IB. */
+ bp = streamer_read_bitpack (ib);
- code = TREE_CODE (expr);
+ /* The first word in BP contains the code of the tree that we
+ are about to read. */
+ code = (enum tree_code) bp_unpack_value (bp, 16);
+ lto_tag_check (lto_tree_code_to_tag (code),
+lto_tree_code_to_tag (TREE_CODE (expr)));
/* Note that all these functions are highly sensitive to changes in
the types and sizes of each of the fields being packed. */
- unpack_ts_base_value_fields (bp, expr);
+ unpack_ts_base_value_fields (bp, expr);
if (CODE_CONTAINS_STRUCT (code, TS_INT_CST))
-unpack_ts_int_cst_value_fields (bp,
[PATCH] PR64959: SFINAE in UDLs
Hi all,
atm enable_if cannot be used to select between overload of UDLs. E.g.
https://gcc.gnu.org/bugzilla/attachment.cgi?id=34684 will not compile.
This can be easily fixed making sure that lookup_literal_operator
returns all the possible candidates and not just the first match. I
made some more changes in parser.c to improve diagnostic in case of
failures. Four testcases added:
* udlit-sfinae.C
* udlit-sfinae.neg.C
* udlit-char-template-sfinae.C
* udlit-char-template-sfinae-neg.C
The first make check showed a failures in udlit-resolve.C. Actually
the failures was a false positive, because UDLs lookup is a normal
unqualified name lookup. I added two tests:
* udlit-namespace-ambiguous.C
* udlit-namespace-ambiguous-neg.C
At the end I also noticed a bug in string template literals. As per
N3599 the lookup should give precedence to operator_t(const char*,
unsigned long). I updated the code in parser.C and added a test.
Please note that this is my first gcc patch :)
2015-2-9 Andrea Azzarone azzaro...@gmail.com
PR c++/64959
* gcc/cp/parser.c: Make sure lookup_literal_operator returns all
the possible candidates. Also improve the diagnostic messages.
* gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C: Add test
case to make sure gcc detects ambiguous UDL declarations.
* gcc/testsuite/g++.dg/cpp0x/udlit-namespace-using-directive.C:
Add test case to make sure gcc correctly handles using directive for
UDLs.
* gcc/testsuite/g++.dg/cpp0x/udlit-resolve.C: Remove a incorrect test case.
* gcc/testsuite/g++.dg/cpp0x/udlit-sfinae.C: Add 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: Add 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:
Add a test to make sure that string template literals have a smaller
priority than standard literal operators.
--
Andrea Azzarone
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;
}
}
@@ -3955,7 +3955,7 @@ 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);
+ result = finish_call_expr (decl, args, false, true,
tf_warning_or_error);
if (result != error_mark_node)
{
if (TREE_CODE (TREE_TYPE (value)) == INTEGER_TYPE overflow 0)
@@ -3986,7 +3986,7 @@ 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);
+ result = finish_call_expr (decl, args, false, true,
tf_warning_or_error);
if (result != error_mark_node)
{
release_tree_vector (args);
@@ -4004,13 +4004,12 @@ cp_parser_userdef_numeric_literal (cp_pa
{
tree tmpl_args = make_char_string_pack (num_string);
decl = lookup_template_function (decl, tmpl_args);
- result = finish_call_expr (decl, args, false, true, tf_none);
- if (result != error_mark_node)
- {
- release_tree_vector (args);
- return result;
- }
+ result = finish_call_expr (decl, args, false, true,
tf_warning_or_error);
+
+ release_tree_vector (args);
+ return result;
}
+
release_tree_vector (args);
error (unable to find numeric literal operator %qD, name);
@@ -4035,6 +4034,24 @@ cp_parser_userdef_string_literal (tree l
tree decl, result;
vectree, va_gc *args;
+ /* Build up a call to the user-defined operator */
+ /* Lookup the name we got back from the id-expression. */
+ args = make_tree_vector ();
+ vec_safe_push (args, value);
+ vec_safe_push (args, build_int_cst (size_type_node, len));
+ decl = lookup_literal_operator (name, args);
+
+ if (decl decl != error_mark_node)
+{
+ 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);
+
/* Look for a template function with typename parameter
Re: [PATCH] doc/invoke.texi: clarify default setting of VTA
On 02/06/15 05:12, Alexander Monakov wrote: Ping? On Fri, 30 Jan 2015, Alexander Monakov wrote: Hello, Recently on gcc-help@ one of the users asked whether they need to set -fvar-tracking-assignments on the command line by hand. The documentation may be clearer in that this flag has a useful value by default, like -fvar-tracking (i.e. GCC's behavior is to take the value of flag_var_tracking, unless there's an override on the command line). OK to commit? I also see that introductory text says that the option list mentions negated forms when they are supposed to be usually used on the command line, which means that var-tracking paragraphs should in fact use -fno-var-tracking[-assignments], because normally users will only need the negative forms? 2015-01-30 Alexander Monakov amona...@ispras.ru * doc/invoke.texi (-fvar-tracking-assignments): Clarify that VTA is enabled by default together with var-tracking. This is fine. Jeff
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On 02/01/15 09:42, Iain Sandoe wrote: This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a PR if that is considered necessary). Has this been addressed or is it still pending? In fact it is not libcc1, but libiberty that is the cause - On 26 Jan 2015, at 14:13, Rainer Orth wrote: FX fxcoud...@gmail.com writes: The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] This means that the PIC library is being built with non-pic relocs. config/mh-darwin says that -mdynamic-no-pic is there because it “speeds compiles by 3-5%”. I don’t think we care about speed when the bootstrap fails, so can we remove it altogether? Darwin/i686 still doesn't bootstrap without this patch, I believe. Shouldn't it be applied to trunk before GCC 5 ships, rather than leaving that target broken? The PIC variant of libiberty, has never (since it was added, AFAICT) catered for the possibility that non-PIC and PIC options might conflict (and/or that it might not be possible to override non-PIC options simply by appending PIC ones). This has gone un-noticed until the libcc1 plugin started linking with the pic version of libiberty. Darwin uses -mdynamic-no-pic as a default flag during bootstrap for 32bit targets, since that gives a stated ~ 3-5% improvement in performance. It is not possible to override this non-pic option by appending -fPIC (that simply results in a warning that mdynamic-no-pic takes precedence). I'd rather not pretend that there's no problem and simply penalise performance on m32 darwin by removing the option from the bootflags. So here's a patch that allows a target to declare incompatible non-pic options (in the same way that we have PIC options already declared as distinct). The patch is largely mechanical (each of the targets adjusted to use the NONPIC flag for the relevant case). As an aside, is there a portability reason that we don't make this repeated operation into a make function? bootstapped on x86_64-linux, x86_64-darwin12, i686-darwin10, powerpc-darwin9, cross-compiled x86-64-darwin12 X i686-darwin10 , native X i686-darwin10 (x86_64-darwin12 build). all languages including Ada (note that there's a local patch needed to work-around an Ada bootstrap issue - pr64349) OK for trunk? Iain libiberty: * Makefile.in (NONPICFLAG, NEWCFLAGS, NEWCPPFLAGS): New. (COMPILE.c): Adjust to use new flags. (all non-pic targets): Adjust to use NONPIC flag. * configure.ac (NOPICFLAG): New. * configure: Regenerate.
patch ping
Hi, I'd like to ping these patches http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02716.html pr 61889 - p1 don't require ftw.h in gcov-tool.c http://gcc.gnu.org/ml/gcc-patches/2015-01/msg01869.html pr 64076 - p2 - don't ICE on invalid code that has ironly and not ironly thunks thanks! Trev
Re: patch ping
Hi, I'd like to ping these patches http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02716.html pr 61889 - p1 don't require ftw.h in gcov-tool.c Looks good enough. Hopefully eventually someone will write mingw implementation. OK http://gcc.gnu.org/ml/gcc-patches/2015-01/msg01869.html pr 64076 - p2 - don't ICE on invalid code that has ironly and not ironly thunks OK. Please add me to CC for patches that I can aprove. Honza thanks! Trev
Re: [Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping
On 02/06/15 05:24, James Greenhalgh wrote: --- 2015-02-06 James Greenhalgh james.greenha...@arm.com * 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). Jeff
[PATCH 01/36] Create libiberty/libiberty.m4, have GDB and GDBserver use it
Converting GDB to be a C++ program, I stumbled on 'basename' issues, like: src/gdb/../include/ansidecl.h:169:64: error: new declaration ‘char* basename(const char*)’ /usr/include/string.h:597:26: error: ambiguates old declaration ‘const char* basename(const char*)’ which I believe led to this bit in gold's configure.ac: dnl We have to check these in C, not C++, because autoconf generates dnl tests which have no type information, and current glibc provides dnl multiple declarations of functions like basename when compiling dnl with C++. AC_CHECK_DECLS([basename, ffs, asprintf, vasprintf, snprintf, vsnprintf, strverscmp]) These checks IIUC intend to generate all the HAVE_DECL_FOO symbols that libiberty.h and ansidecl.h check. GDB is missing these checks currently, which results in the conflict shown above. I could just copy gold's bits over to GDB. But, since libiberty's ansidecl.h and libiberty.h check HAVE_DECL_XXX symbols, ISTM that all programs that use these headers should be doing the exact same corresponding AC_CHECK_DECLS autoconf checks, and that there's good potential for bit rot here. So I thought of adding a m4 file that projects that use libiberty can source to pull in the autoconf checks that libiberty needs done in order to use its public headers. Turns out that this has already happened. Since I first wrote this a few months back, libiberty gained more HAVE_DECL_FOO checks even, for the strtol friends replacements. Are the libiberty changes OK? libiberty/ChangeLog: 2015-02-09 Pedro Alves pal...@redhat.com * libiberty.m4: New file. gdb/ChangeLog: 2015-02-09 Pedro Alves pal...@redhat.com * acinclude.m4: Include libiberty.m4. * config.in, configure: Regenerate. * configure.ac: Call libiberty_INIT. gdb/gdbserver/ 2015-02-09 Pedro Alves pal...@redhat.com * acinclude.m4: Include libiberty.m4. * config.in, configure: Regenerate. * configure.ac: Call libiberty_INIT. --- gdb/acinclude.m4 | 3 + gdb/config.in | 45 ++ gdb/configure | 266 +++ gdb/configure.ac | 2 + gdb/gdbserver/acinclude.m4 | 3 + gdb/gdbserver/config.in| 41 ++ gdb/gdbserver/configure| 338 + gdb/gdbserver/configure.ac | 2 + libiberty/libiberty.m4 | 33 + 9 files changed, 679 insertions(+), 54 deletions(-) create mode 100644 libiberty/libiberty.m4 diff --git a/gdb/acinclude.m4 b/gdb/acinclude.m4 index 6f71486..ff4aff0 100644 --- a/gdb/acinclude.m4 +++ b/gdb/acinclude.m4 @@ -54,6 +54,9 @@ sinclude([../config/zlib.m4]) m4_include([common/common.m4]) +dnl For libiberty_INIT. +m4_include(../libiberty/libiberty.m4) + ## - ## ## ANSIfy the C compiler whenever possible. ## ## From Franc,ois Pinard ## diff --git a/gdb/config.in b/gdb/config.in index 806cbac..6a8df15 100644 --- a/gdb/config.in +++ b/gdb/config.in @@ -85,6 +85,17 @@ you don't. */ #undef HAVE_DECL_ADDR_NO_RANDOMIZE +/* Define to 1 if you have the declaration of `asprintf', and to 0 if you + don't. */ +#undef HAVE_DECL_ASPRINTF + +/* Define to 1 if you have the declaration of `basename(char *)', and to 0 if + you don't. */ +#undef HAVE_DECL_BASENAME + +/* Define to 1 if you have the declaration of `ffs', and to 0 if you don't. */ +#undef HAVE_DECL_FFS + /* Define to 1 if you have the declaration of `free', and to 0 if you don't. */ #undef HAVE_DECL_FREE @@ -117,6 +128,34 @@ */ #undef HAVE_DECL_STRSTR +/* Define to 1 if you have the declaration of `strtol', and to 0 if you don't. + */ +#undef HAVE_DECL_STRTOL + +/* Define to 1 if you have the declaration of `strtoll', and to 0 if you + don't. */ +#undef HAVE_DECL_STRTOLL + +/* Define to 1 if you have the declaration of `strtoul', and to 0 if you + don't. */ +#undef HAVE_DECL_STRTOUL + +/* Define to 1 if you have the declaration of `strtoull', and to 0 if you + don't. */ +#undef HAVE_DECL_STRTOULL + +/* Define to 1 if you have the declaration of `strverscmp', and to 0 if you + don't. */ +#undef HAVE_DECL_STRVERSCMP + +/* Define to 1 if you have the declaration of `vasprintf', and to 0 if you + don't. */ +#undef HAVE_DECL_VASPRINTF + +/* Define to 1 if you have the declaration of `vsnprintf', and to 0 if you + don't. */ +#undef HAVE_DECL_VSNPRINTF + /* Define to 1 if you have the dlfcn.h header file. */ #undef HAVE_DLFCN_H @@ -225,6 +264,9 @@ /* Define to 1 if the compiler supports long double. */ #undef HAVE_LONG_DOUBLE +/* Define if you have the `long long' type. */ +#undef HAVE_LONG_LONG + /* Define if sys/procfs.h has lwpid_t. */ #undef HAVE_LWPID_T @@ -635,6 +677,9 @@ /* The size of `long', as computed by sizeof. */ #undef SIZEOF_LONG +/* The size of `long long', as computed by sizeof. */ +#undef SIZEOF_LONG_LONG + /* The size of `unsigned long', as
[PATCH 09/36] floatformat.h: Wrap in extern C.
Just like libiberty.h. So that C++ programs, such as GDB when built
as a C++ program, can use it.
include/ChangeLog:
2015-02-09 Pedro Alves pal...@redhat.com
* floatformat.h [__cplusplus]: Wrap in extern C.
---
include/floatformat.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/floatformat.h b/include/floatformat.h
index 6b559864..71d332b 100644
--- a/include/floatformat.h
+++ b/include/floatformat.h
@@ -20,6 +20,10 @@ Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
MA 02110-1301, USA.
#if !defined (FLOATFORMAT_H)
#define FLOATFORMAT_H 1
+#ifdef __cplusplus
+extern C {
+#endif
+
#include ansidecl.h
/* A floatformat consists of a sign bit, an exponent and a mantissa. Once the
@@ -148,4 +152,8 @@ floatformat_from_double (const struct floatformat *, const
double *, void *);
extern int
floatformat_is_valid (const struct floatformat *fmt, const void *from);
+#ifdef __cplusplus
+}
+#endif
+
#endif /* defined (FLOATFORMAT_H) */
--
1.9.3
Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}
On Wed, 2015-02-04 at 23:19 +0100, Jakub Jelinek wrote: On Wed, Feb 04, 2015@01:58:32PM -0800, Cary Coutant wrote: DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently accepted into DWARF5. This patch changes GCC to handle those similarly to how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled. As it will take some time for consumers to catch up, I'm enabling that only if -gdwarf-5 is used for now. My concern with enabling -gdwarf-5 at this point is that all we're really doing with it is enabling a subset of DWARF-5 features (as we Yeah, sure, at this point -gdwarf-5 is highly experimental, mainly meant for coordination with consumers. We'll incrementally add bits to it, until DWARF5 will be released and we implement everything we'll want to from the new standard. Then we need to wait for consumers to catch up and only then we can switch to -gdwarf-5 by default (perhaps GCC 7.0 timeframe?). I documented the new GCC/GNU DWARF[5] extensions at: https://fedorahosted.org/elfutils/wiki/DwarfExtensions And submitted patches to support the new DW_LANG_Fortran(03,08} to elfutils, valgrind, gdb, binutils and gold. Cheers, Mark
Re: [PATCH] PR64979: S/390: Fix setup of overflow area pointer in va_start
On 02/09/2015 01:05 PM, Jakub Jelinek wrote:
On Mon, Feb 09, 2015 at 12:40:05PM +0100, Andreas Krebbel wrote:
On 02/09/2015 12:29 PM, Jakub Jelinek wrote:
On Mon, Feb 09, 2015 at 10:50:34AM +0100, Andreas Krebbel wrote:
Hi,
the attached patch fixes a critical problem in the va_start expansion
code in the S/390 backend. The problem exists since GCC 4.0.
Ok to commit to 4.9 branch and mainline?
No. This isn't a backend problem, but a bug in the tree-stdarg.c pass,
so should be fixed there, for all targets, rather than just worked around by
pessimizing unnecessarily one target.
I think for the overflow area pointer we would need a different flag
indicating whether a pointer to
the va_list structure escapes or not. To my understanding it is not correct
to only use the
va_list_gpr_size/va_list_fpr_size fields for that purpose. These only refer
to the va_arg expansions
in the current function.
No. The flag for the escapes is
if (va_list_escapes)
{
fun-va_list_gpr_size = VA_LIST_MAX_GPR_SIZE;
fun-va_list_fpr_size = VA_LIST_MAX_FPR_SIZE;
}
and has been that way since forever. Escape case is like no stdarg pass run
at all (-O0), it is a case where you don't know anything about it.
Ok. I missed that. Thanks!
-Andreas-
What I mean as a fix is something like untested following patch, though that
only fixes the case on the !va_list_simple_ptr targets like x86_64 or s390*,
but not say on i?86. Even on i?86 it should say that it escapes, because it
does, thus something is still wrong in the stdarg pass.
As you can see, the updated testcase fails even on x86_64-linux.
--- gcc/tree-stdarg.c.jj 2015-01-09 21:59:44.0 +0100
+++ gcc/tree-stdarg.c 2015-02-09 12:47:12.020789728 +0100
@@ -856,22 +856,23 @@ pass_stdarg::execute (function *fun)
/* For va_list_simple_ptr, we have to check PHI nodes too. We treat
them as assignments for the purpose of escape analysis. This is
not needed for non-simple va_list because virtual phis don't perform
- any real data movement. */
- if (va_list_simple_ptr)
- {
- tree lhs, rhs;
- use_operand_p uop;
- ssa_op_iter soi;
+ any real data movement. For !va_list_simple_ptr, check PHI nodes for
+ taking address of the va_list vars. */
+ tree lhs, rhs;
+ use_operand_p uop;
+ ssa_op_iter soi;
- for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
-gsi_next (i))
- {
- gphi *phi = i.phi ();
- lhs = PHI_RESULT (phi);
+ for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
+gsi_next (i))
+ {
+ gphi *phi = i.phi ();
+ lhs = PHI_RESULT (phi);
- if (virtual_operand_p (lhs))
- continue;
+ if (virtual_operand_p (lhs))
+ continue;
+ if (va_list_simple_ptr)
+ {
FOR_EACH_PHI_ARG (uop, phi, soi, SSA_OP_USE)
{
rhs = USE_FROM_PTR (uop);
@@ -894,6 +895,22 @@ pass_stdarg::execute (function *fun)
}
}
}
+ else
+ {
+ for (unsigned j = 0; !va_list_escapes
+ j gimple_phi_num_args (phi); ++j)
+ if (walk_tree (gimple_phi_arg_def_ptr (phi, j),
+find_va_list_reference, wi, NULL))
+ {
+ if (dump_file (dump_flags TDF_DETAILS))
+ {
+ fputs (va_list escapes in , dump_file);
+ print_gimple_stmt (dump_file, phi, 0, dump_flags);
+ fputc ('\n', dump_file);
+ }
+ va_list_escapes = true;
+ }
+ }
}
for (gimple_stmt_iterator i = gsi_start_bb (bb);
@@ -916,8 +933,8 @@ pass_stdarg::execute (function *fun)
if (is_gimple_assign (stmt))
{
- tree lhs = gimple_assign_lhs (stmt);
- tree rhs = gimple_assign_rhs1 (stmt);
+ lhs = gimple_assign_lhs (stmt);
+ rhs = gimple_assign_rhs1 (stmt);
if (va_list_simple_ptr)
{
--- gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c.jj 2015-02-09
12:54:44.84401 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c 2015-02-09 12:58:10.406875647
+0100
@@ -0,0 +1,22 @@
+/* PR target/64979 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-stdarg } */
+
+#include stdarg.h
+
+void bar (int x, va_list *ap);
+
+void
+foo (int x, ...)
+{
+ va_list ap;
+ int n;
+
+ va_start (ap, x);
+ n = va_arg (ap, int);
+ bar (x, (va_list *) ((n == 0) ? ((void *) 0) : ap));
+ va_end (ap);
+}
+
+/* { dg-final { scan-tree-dump foo: va_list escapes 1, needs to save all
GPR units and all FPR units stdarg } } */
+/* { dg-final { cleanup-tree-dump stdarg } } */
---
Re: [PATCH] PR64979: S/390: Fix setup of overflow area pointer in va_start
On 02/09/2015 01:17 PM, Jakub Jelinek wrote:
On Mon, Feb 09, 2015 at 01:05:23PM +0100, Jakub Jelinek wrote:
As you can see, the updated testcase fails even on x86_64-linux.
Here is an updated patch that succeeds even on i686-linux.
Your patch fixes my testcase on s390x. Thanks!
-Andreas-
2015-02-09 Jakub Jelinek ja...@redhat.com
PR target/64979
* tree-stdarg.c (pass_stdarg::execute): Scan phi node args for
va_list escapes.
* gcc.dg/tree-ssa/stdarg-7.c: New test.
* gcc.c-torture/execute/pr64979.c: New test.
--- gcc/tree-stdarg.c.jj 2015-01-09 21:59:44.0 +0100
+++ gcc/tree-stdarg.c 2015-02-09 13:14:43.880406573 +0100
@@ -856,22 +856,23 @@ pass_stdarg::execute (function *fun)
/* For va_list_simple_ptr, we have to check PHI nodes too. We treat
them as assignments for the purpose of escape analysis. This is
not needed for non-simple va_list because virtual phis don't perform
- any real data movement. */
- if (va_list_simple_ptr)
+ any real data movement. Also, check PHI nodes for taking address of
+ the va_list vars. */
+ tree lhs, rhs;
+ use_operand_p uop;
+ ssa_op_iter soi;
+
+ for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
+gsi_next (i))
{
- tree lhs, rhs;
- use_operand_p uop;
- ssa_op_iter soi;
+ gphi *phi = i.phi ();
+ lhs = PHI_RESULT (phi);
- for (gphi_iterator i = gsi_start_phis (bb); !gsi_end_p (i);
-gsi_next (i))
- {
- gphi *phi = i.phi ();
- lhs = PHI_RESULT (phi);
-
- if (virtual_operand_p (lhs))
- continue;
+ if (virtual_operand_p (lhs))
+ continue;
+ if (va_list_simple_ptr)
+ {
FOR_EACH_PHI_ARG (uop, phi, soi, SSA_OP_USE)
{
rhs = USE_FROM_PTR (uop);
@@ -894,6 +895,22 @@ pass_stdarg::execute (function *fun)
}
}
}
+
+ for (unsigned j = 0; !va_list_escapes
+ j gimple_phi_num_args (phi); ++j)
+ if ((!va_list_simple_ptr
+ || TREE_CODE (gimple_phi_arg_def (phi, j)) != SSA_NAME)
+ walk_tree (gimple_phi_arg_def_ptr (phi, j),
+ find_va_list_reference, wi, NULL))
+ {
+ if (dump_file (dump_flags TDF_DETAILS))
+ {
+ fputs (va_list escapes in , dump_file);
+ print_gimple_stmt (dump_file, phi, 0, dump_flags);
+ fputc ('\n', dump_file);
+ }
+ va_list_escapes = true;
+ }
}
for (gimple_stmt_iterator i = gsi_start_bb (bb);
@@ -916,8 +933,8 @@ pass_stdarg::execute (function *fun)
if (is_gimple_assign (stmt))
{
- tree lhs = gimple_assign_lhs (stmt);
- tree rhs = gimple_assign_rhs1 (stmt);
+ lhs = gimple_assign_lhs (stmt);
+ rhs = gimple_assign_rhs1 (stmt);
if (va_list_simple_ptr)
{
--- gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c.jj 2015-02-09
12:54:44.84401 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c 2015-02-09 12:58:10.406875647
+0100
@@ -0,0 +1,22 @@
+/* PR target/64979 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-stdarg } */
+
+#include stdarg.h
+
+void bar (int x, va_list *ap);
+
+void
+foo (int x, ...)
+{
+ va_list ap;
+ int n;
+
+ va_start (ap, x);
+ n = va_arg (ap, int);
+ bar (x, (va_list *) ((n == 0) ? ((void *) 0) : ap));
+ va_end (ap);
+}
+
+/* { dg-final { scan-tree-dump foo: va_list escapes 1, needs to save all
GPR units and all FPR units stdarg } } */
+/* { dg-final { cleanup-tree-dump stdarg } } */
--- gcc/testsuite/gcc.c-torture/execute/pr64979.c.jj 2015-02-09
12:54:01.867984625 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr64979.c 2015-02-09
13:08:17.458818847 +0100
@@ -0,0 +1,36 @@
+/* PR target/64979 */
+
+#include stdarg.h
+
+void __attribute__((noinline, noclone))
+bar (int x, va_list *ap)
+{
+ if (ap)
+{
+ int i;
+ for (i = 0; i 10; i++)
+ if (i != va_arg (*ap, int))
+ __builtin_abort ();
+ if (va_arg (*ap, double) != 0.5)
+ __builtin_abort ();
+}
+}
+
+void __attribute__((noinline, noclone))
+foo (int x, ...)
+{
+ va_list ap;
+ int n;
+
+ va_start (ap, x);
+ n = va_arg (ap, int);
+ bar (x, (va_list *) ((n == 0) ? ((void *) 0) : ap));
+ va_end (ap);
+}
+
+int
+main ()
+{
+ foo (100, 1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0.5);
+ return 0;
+}
Jakub
Contents of PO file 'cpplib-5.1-b20150208.uk.po'
cpplib-5.1-b20150208.uk.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
