Re: [C++ PATCH] PR c++/35878
On 21 March 2017 at 08:55, Ville Voutilainen
wrote:
>>> +// { dg-options "-O2 --std=gnu++11" }
>>
>> -O2 -std=gnu++11 is enough, no need for double dash --std=gnu++11.
>>
>>> +// { dg-do compile }
>>> +// { dg-final { scan-assembler "test.*%rdi, %rdi" { target i?86-*-*
>>> x86_64-*-* } } }
>>
>> This will surely fail on 32-bit or with -mx32. So either you need to use it
>> on { target { { i?86-*-* x86_64-*-* } && lp64 } } only, or perhaps instead
>> of scanning assembler add -fdump-tree-optimized to dg-options and
>> scan-tree-dump for the NULL? pointer comparison there.
>
> I weakly vote for the former, since that's less intrusive. I managed
> to commit the patch before
> I saw these remarks, so we need to patch that fix in as a separate tweak.
So, shall I just push in the attached?
diff --git a/gcc/testsuite/g++.dg/init/pr35878_1.C
b/gcc/testsuite/g++.dg/init/pr35878_1.C
index b45c009..d4cad74 100644
--- a/gcc/testsuite/g++.dg/init/pr35878_1.C
+++ b/gcc/testsuite/g++.dg/init/pr35878_1.C
@@ -1,6 +1,6 @@
-// { dg-options "-O2 --std=gnu++11" }
+// { dg-options "-O2 -std=gnu++11" }
// { dg-do compile }
-// { dg-final { scan-assembler "test.*%rdi, %rdi" { target i?86-*-* x86_64-*-*
} } }
+// { dg-final { scan-assembler "test.*%rdi, %rdi" { target { { i?86-*-*
x86_64-*-* } && lp64 } } } }
#include
#include
diff --git a/gcc/testsuite/g++.dg/init/pr35878_2.C
b/gcc/testsuite/g++.dg/init/pr35878_2.C
index 0664494..ef55463 100644
--- a/gcc/testsuite/g++.dg/init/pr35878_2.C
+++ b/gcc/testsuite/g++.dg/init/pr35878_2.C
@@ -1,6 +1,6 @@
-// { dg-options "-O2 --std=gnu++17 -fcheck-new" }
+// { dg-options "-O2 -std=gnu++17 -fcheck-new" }
// { dg-do compile }
-// { dg-final { scan-assembler "test.*%rdi, %rdi" { target i?86-*-* x86_64-*-*
} } }
+// { dg-final { scan-assembler "test.*%rdi, %rdi" { target { { i?86-*-*
x86_64-*-* } && lp64 } } } }
#include
#include
diff --git a/gcc/testsuite/g++.dg/init/pr35878_3.C
b/gcc/testsuite/g++.dg/init/pr35878_3.C
index 8a5614f..9a2efa2 100644
--- a/gcc/testsuite/g++.dg/init/pr35878_3.C
+++ b/gcc/testsuite/g++.dg/init/pr35878_3.C
@@ -1,6 +1,6 @@
-// { dg-options "-O2 --std=gnu++17" }
+// { dg-options "-O2 -std=gnu++17" }
// { dg-do compile }
-// { dg-final { scan-assembler-not "test.*%rdi, %rdi" { target i?86-*-*
x86_64-*-* } } }
+// { dg-final { scan-assembler-not "test.*%rdi, %rdi" { target { { i?86-*-*
x86_64-*-* } && lp64 } } } }
#include
#include
Re: [C++ PATCH] PR c++/35878
On Tue, Mar 21, 2017 at 09:03:54AM +0200, Ville Voutilainen wrote:
> On 21 March 2017 at 08:55, Ville Voutilainen
> wrote:
> >>> +// { dg-options "-O2 --std=gnu++11" }
> >>
> >> -O2 -std=gnu++11 is enough, no need for double dash --std=gnu++11.
> >>
> >>> +// { dg-do compile }
> >>> +// { dg-final { scan-assembler "test.*%rdi, %rdi" { target i?86-*-*
> >>> x86_64-*-* } } }
> >>
> >> This will surely fail on 32-bit or with -mx32. So either you need to use
> >> it
> >> on { target { { i?86-*-* x86_64-*-* } && lp64 } } only, or perhaps instead
> >> of scanning assembler add -fdump-tree-optimized to dg-options and
> >> scan-tree-dump for the NULL? pointer comparison there.
> >
> > I weakly vote for the former, since that's less intrusive. I managed
> > to commit the patch before
> > I saw these remarks, so we need to patch that fix in as a separate tweak.
>
> So, shall I just push in the attached?
I've tested in the mean time the following patch with both gcc from yesterday
where
pr35878_3.C fails as expected, and with the latest cc1plus where
it succeeds both with -m32 and -m64. Scanning the tree dump has the
advantage that you test it everywhere, it works even with -masm=intel etc.
--- gcc/cp/ChangeLog.jj 2017-03-21 07:57:00.0 +0100
+++ gcc/cp/ChangeLog2017-03-21 08:03:41.427958947 +0100
@@ -1,7 +1,7 @@
2017-03-21 Ville Voutilainen
PR c++/35878
- * cp/init.c (std_placement_new_fn_p): New.
+ * init.c (std_placement_new_fn_p): New.
(build_new_1): Call it.
2017-03-20 Jason Merrill
--- gcc/cp/init.c.jj2017-03-21 07:57:00.0 +0100
+++ gcc/cp/init.c 2017-03-21 08:04:13.226549930 +0100
@@ -2710,7 +2710,8 @@ malloc_alignment ()
/* Determine whether an allocation function is a namespace-scope
non-replaceable placement new function. See DR 1748.
TODO: Enable in all standard modes. */
-static bool std_placement_new_fn_p (tree alloc_fn)
+static bool
+std_placement_new_fn_p (tree alloc_fn)
{
if ((cxx_dialect > cxx14) && DECL_NAMESPACE_SCOPE_P (alloc_fn))
{
@@ -3200,8 +3201,8 @@ build_new_1 (vec **placemen
So check for a null exception spec on the op new we just called. */
nothrow = TYPE_NOTHROW_P (TREE_TYPE (alloc_fn));
- check_new = flag_check_new
-|| (nothrow && !std_placement_new_fn_p (alloc_fn));
+ check_new
+= flag_check_new || (nothrow && !std_placement_new_fn_p (alloc_fn));
if (cookie_size)
{
--- gcc/testsuite/g++.dg/init/pr35878_1.C.jj2017-03-21 07:56:59.0
+0100
+++ gcc/testsuite/g++.dg/init/pr35878_1.C 2017-03-21 08:10:07.020008447
+0100
@@ -1,6 +1,8 @@
-// { dg-options "-O2 --std=gnu++11" }
+// PR c++/35878
// { dg-do compile }
-// { dg-final { scan-assembler "test.*%rdi, %rdi" { target i?86-*-* x86_64-*-*
} } }
+// { dg-options "-O2 -std=gnu++11 -fdump-tree-optimized" }
+// { dg-final { scan-tree-dump-times "v_\[0-9]+\\(D\\) \[=!]= 0" 1 "optimized"
} }
+
#include
#include
--- gcc/testsuite/g++.dg/init/pr35878_2.C.jj2017-03-21 07:56:59.0
+0100
+++ gcc/testsuite/g++.dg/init/pr35878_2.C 2017-03-21 08:10:35.021649003
+0100
@@ -1,6 +1,8 @@
-// { dg-options "-O2 --std=gnu++17 -fcheck-new" }
+// PR c++/35878
// { dg-do compile }
-// { dg-final { scan-assembler "test.*%rdi, %rdi" { target i?86-*-* x86_64-*-*
} } }
+// { dg-options "-O2 -std=gnu++17 -fcheck-new -fdump-tree-optimized" }
+// { dg-final { scan-tree-dump-times "v_\[0-9]+\\(D\\) \[=!]= 0" 1 "optimized"
} }
+
#include
#include
--- gcc/testsuite/g++.dg/init/pr35878_3.C.jj2017-03-21 07:56:59.0
+0100
+++ gcc/testsuite/g++.dg/init/pr35878_3.C 2017-03-21 08:11:02.182300354
+0100
@@ -1,6 +1,8 @@
-// { dg-options "-O2 --std=gnu++17" }
+// PR c++/35878
// { dg-do compile }
-// { dg-final { scan-assembler-not "test.*%rdi, %rdi" { target i?86-*-*
x86_64-*-* } } }
+// { dg-options "-O2 -std=gnu++17 -fdump-tree-optimized" }
+// { dg-final { scan-tree-dump-not "v_\[0-9]+\\(D\\) \[=!]= 0" "optimized" } }
+
#include
#include
Jakub
Re: [C++ PATCH] PR c++/35878
On 21 March 2017 at 09:17, Jakub Jelinek wrote: > I've tested in the mean time the following patch with both gcc from yesterday > where > pr35878_3.C fails as expected, and with the latest cc1plus where > it succeeds both with -m32 and -m64. Scanning the tree dump has the > advantage that you test it everywhere, it works even with -masm=intel etc. Works for me. I can't write a tree scan to save my life, hence the scan-assembler approach taken in my patch. Not that I can really grok assembler either much.
[PATCH] Don't cross-jump in between frame related and non-frame related insns (PR target/80102, take 2)
On Tue, Mar 21, 2017 at 08:38:20AM +1000, Richard Henderson wrote:
> On 03/21/2017 07:15 AM, Jakub Jelinek wrote:
> > Not really sure what we should do if both i1 and i2 are frame related, shall
> > we check for each of the CFA reg notes if they are available and equal?
> > Or punt if either of the insns is frame related?
>
> I would punt if either is frame related.
Ok, I'll test then the following patch and gather some statistic on how
often we trigger this.
> As an aside, if the length of "blockage" is corrected to 0, does
> cross-jumping skip this case? Because replacing a simple_return with a
> direct branch to a simple_return is not a win. But of course at the moment
> cross-jumping thinks it is eliminating the second blockage as well...
I don't think cross-jumping counts anything but the number of active_insn_p,
at least I can't find any get_attr_length uses outside of final.c in the
generic code (and just very few (shrink-wrap and bb-reorder)
get_attr_min_length calls). So shall cross-jumping only count
ifdef HAVE_attr_length insns with get_attr_length > 0?
2017-03-21 Jakub Jelinek
PR target/80102
* cfgcleanup.c (old_insns_match_p): Don't cross-jump frame related
insns.
* g++.dg/opt/pr80102.C: New test.
--- gcc/cfgcleanup.c.jj 2017-01-09 22:46:03.0 +0100
+++ gcc/cfgcleanup.c2017-03-20 13:55:58.823983848 +0100
@@ -1149,6 +1149,10 @@ old_insns_match_p (int mode ATTRIBUTE_UN
else if (p1 || p2)
return dir_none;
+ /* Do not allow cross-jumping frame related insns. */
+ if (RTX_FRAME_RELATED_P (i1) || RTX_FRAME_RELATED_P (i2))
+return dir_none;
+
p1 = PATTERN (i1);
p2 = PATTERN (i2);
--- gcc/testsuite/g++.dg/opt/pr80102.C.jj 2017-03-20 14:34:01.223434828
+0100
+++ gcc/testsuite/g++.dg/opt/pr80102.C 2017-03-20 14:33:36.0 +0100
@@ -0,0 +1,14 @@
+// PR target/80102
+// { dg-do compile }
+// { dg-options "-fnon-call-exceptions -Os" }
+// { dg-additional-options "-mminimal-toc" { target { powerpc*-*-* && lp64 } }
}
+
+struct B { float a; B (float c) { for (int g; g < c;) ++a; } };
+struct D { D (B); };
+
+int
+main ()
+{
+ B (1.0);
+ D e (0.0), f (1.0);
+}
Jakub
Re: [PATCH v2] Fix PR79908
On Mon, Mar 20, 2017 at 8:15 PM, Bill Schmidt
wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 shows a case where
> pass_stdarg ICEs attempting to gimplify a COMPLEX_EXPR with side
> effects as an lvalue. This occurs when the LHS of a VA_ARG has been
> cast away. This patch, credit to Richard Biener, uses
> force_gimple_operand to instantiate the necessary side effects rather
> than gimplify_expr using is_gimple_lvalue. The test case is taken
> wholesale from the bug report.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions. Is this ok for trunk?
Ok!
Thanks,
Richard.
> Thanks,
> Bill
>
>
> [gcc]
>
> 2017-03-20 Bill Schmidt
> Richard Biener
>
> PR tree-optimization/79908
> * tree-stdarg.c (expand_ifn_va_arg_1): For a VA_ARG whose LHS has
> been cast away, use force_gimple_operand to construct the side
> effects.
>
> [gcc/testsuite]
>
> 2017-03-20 Bill Schmidt
> Richard Biener
>
> PR tree-optimization/79908
> * gcc.dg/torture/pr79908.c: New file.
>
>
> Index: gcc/testsuite/gcc.dg/torture/pr79908.c
> ===
> --- gcc/testsuite/gcc.dg/torture/pr79908.c (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/pr79908.c (working copy)
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +
> +/* Used to fail in the stdarg pass before fix for PR79908. */
> +
> +typedef __builtin_va_list __gnuc_va_list;
> +typedef __gnuc_va_list va_list;
> +
> +void testva (int n, ...)
> +{
> + va_list ap;
> + _Complex int i = __builtin_va_arg (ap, _Complex int);
> +}
> Index: gcc/tree-stdarg.c
> ===
> --- gcc/tree-stdarg.c (revision 246286)
> +++ gcc/tree-stdarg.c (working copy)
> @@ -33,6 +33,7 @@ along with GCC; see the file COPYING3. If not see
> #include "gimple-iterator.h"
> #include "gimple-walk.h"
> #include "gimplify.h"
> +#include "gimplify-me.h"
> #include "tree-into-ssa.h"
> #include "tree-cfg.h"
> #include "tree-stdarg.h"
> @@ -1058,12 +1059,16 @@ expand_ifn_va_arg_1 (function *fun)
> gimplify_assign (lhs, expr, &pre);
> }
> else
> - gimplify_expr (&expr, &pre, &post, is_gimple_lvalue, fb_lvalue);
> + {
> + gimple_seq tmp_seq;
> + force_gimple_operand (expr, &tmp_seq, false, NULL_TREE);
> + gimple_seq_add_seq_without_update (&pre, tmp_seq);
> + }
>
> input_location = saved_location;
> pop_gimplify_context (NULL);
>
> - gimple_seq_add_seq (&pre, post);
> + gimple_seq_add_seq_without_update (&pre, post);
> update_modified_stmts (pre);
>
> /* Add the sequence after IFN_VA_ARG. This splits the bb right
> @@ -1072,11 +1077,10 @@ expand_ifn_va_arg_1 (function *fun)
> gimple_find_sub_bbs (pre, &i);
>
> /* Remove the IFN_VA_ARG gimple_call. It's the last stmt in the
> - bb. */
> + bb if we added any stmts. */
> unlink_stmt_vdef (stmt);
> release_ssa_name_fn (fun, gimple_vdef (stmt));
> gsi_remove (&i, true);
> - gcc_assert (gsi_end_p (i));
>
> /* We're walking here into the bbs which contain the expansion of
>IFN_VA_ARG, and will not contain another IFN_VA_ARG that needs
>
Re: [PATCH] Fix UB in round_up_loc (PR c/67338)
On Mon, 20 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> divisor is unsigned int parameter, if it is 0x8000, we invoke UB.
> val is wide_int, so (int) -divisor achieves the same result without UB.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2017-03-20 Jakub Jelinek
>
> PR c/67338
> * fold-const.c (round_up_loc): Negate divisor in unsigned type to
> avoid UB.
>
> * gcc.dg/pr67338.c: New test.
>
> --- gcc/fold-const.c.jj 2017-03-16 17:18:25.0 +0100
> +++ gcc/fold-const.c 2017-03-20 07:53:53.680953740 +0100
> @@ -14250,7 +14250,7 @@ round_up_loc (location_t loc, tree value
>
> overflow_p = TREE_OVERFLOW (value);
> val += divisor - 1;
> - val &= - (int) divisor;
> + val &= (int) -divisor;
> if (val == 0)
> overflow_p = true;
>
> --- gcc/testsuite/gcc.dg/pr67338.c.jj 2017-03-20 09:09:05.489002468 +0100
> +++ gcc/testsuite/gcc.dg/pr67338.c2017-03-20 09:08:54.0 +0100
> @@ -0,0 +1,4 @@
> +/* PR c/67338 */
> +/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
> +
> +struct S { __attribute__((aligned (1 << 28))) double a; };
>
> Jakub
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
Re: [PATCH] Fix -fsanitize=thread -O0 handling of atomics (PR sanitizer/78158)
On Mon, 20 Mar 2017, Jakub Jelinek wrote: > Hi! > > libtsan only handles the standard memory model values, so I've added > just in case some new unknown memory model is used bail outs (keeping > the __atomic_* builtins instead of transforming them to __tsan_atomic*). > Except that at -O0 (or if unlucky enough otherwise) if the memory model > is variable, that means we never use __tsan_atomic*, which means libtsan > reports false positive races. We could do those checks at runtime by > performing if ((last_arg & 0x7fff) >= 6) __atomic_* else __tsan_atomic_*, > but as there are no such values yet I think it isn't worth it (the > sync/hle acq/hle rel bits which are ored are 0x8000, 0x1 and 0x2 > and memmodel_base strips them off). > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Ok. Richard. > 2017-03-20 Jakub Jelinek > > PR sanitizer/78158 > * tsan.c (instrument_builtin_call): If the memory model argument > is not a constant, assume it is valid. > > --- gcc/tsan.c.jj 2017-01-01 12:45:38.0 +0100 > +++ gcc/tsan.c2017-03-20 17:55:25.509294018 +0100 > @@ -499,8 +499,8 @@ instrument_builtin_call (gimple_stmt_ite > case check_last: > case fetch_op: > last_arg = gimple_call_arg (stmt, num - 1); > - if (!tree_fits_uhwi_p (last_arg) > - || memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST) > + if (tree_fits_uhwi_p (last_arg) > + && memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST) > return; > gimple_call_set_fndecl (stmt, decl); > update_stmt (stmt); > @@ -564,11 +564,11 @@ instrument_builtin_call (gimple_stmt_ite > gcc_assert (num == 6); > for (j = 0; j < 6; j++) > args[j] = gimple_call_arg (stmt, j); > - if (!tree_fits_uhwi_p (args[4]) > - || memmodel_base (tree_to_uhwi (args[4])) >= MEMMODEL_LAST) > + if (tree_fits_uhwi_p (args[4]) > + && memmodel_base (tree_to_uhwi (args[4])) >= MEMMODEL_LAST) > return; > - if (!tree_fits_uhwi_p (args[5]) > - || memmodel_base (tree_to_uhwi (args[5])) >= MEMMODEL_LAST) > + if (tree_fits_uhwi_p (args[5]) > + && memmodel_base (tree_to_uhwi (args[5])) >= MEMMODEL_LAST) > return; > update_gimple_call (gsi, decl, 5, args[0], args[1], args[2], > args[4], args[5]); > @@ -642,8 +642,8 @@ instrument_builtin_call (gimple_stmt_ite > return; > } > last_arg = gimple_call_arg (stmt, num - 1); > - if (!tree_fits_uhwi_p (last_arg) > - || memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST) > + if (tree_fits_uhwi_p (last_arg) > + && memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST) > return; > t = TYPE_ARG_TYPES (TREE_TYPE (decl)); > t = TREE_VALUE (TREE_CHAIN (t)); > > Jakub > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Re: [PATCH] Fix -fsanitize=thread with -fnon-call-exceptions (PR sanitizer/80110)
On Mon, 20 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> libtsan atomics aren't throwing, so if we transform atomics which
> are throwing with -fnon-call-exceptions, we need to clean up EH stuff.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Huh, but this means with TSAN we create wrong-code with
-fnon-call-exceptions and programs will crash instead of properly
catching things like null-pointer accesses?
We should at least document this or reject sanitize=thread with
-fnon-call-exceptions.
Richard.
> 2017-03-20 Jakub Jelinek
>
> PR sanitizer/80110
> * tsan.c: Include tree-eh.h.
> (instrument_builtin_call): Call maybe_clean_eh_stmt or
> maybe_clean_or_replace_eh_stmt where needed.
> (instrument_memory_accesses): Add cfg_changed argument.
> Call gimple_purge_dead_eh_edges on each block and set *cfg_changed
> if it returned true.
> (tsan_pass): Adjust caller. Return TODO_cleanup_cfg if cfg_changed.
>
> * g++.dg/tsan/pr80110.C: New test.
>
> --- gcc/tsan.c.jj 2017-03-20 17:55:25.0 +0100
> +++ gcc/tsan.c2017-03-20 19:43:34.715321105 +0100
> @@ -38,6 +38,7 @@ along with GCC; see the file COPYING3.
> #include "tree-iterator.h"
> #include "tree-ssa-propagate.h"
> #include "tree-ssa-loop-ivopts.h"
> +#include "tree-eh.h"
> #include "tsan.h"
> #include "asan.h"
> #include "builtins.h"
> @@ -504,6 +505,7 @@ instrument_builtin_call (gimple_stmt_ite
> return;
> gimple_call_set_fndecl (stmt, decl);
> update_stmt (stmt);
> + maybe_clean_eh_stmt (stmt);
> if (tsan_atomic_table[i].action == fetch_op)
> {
> args[1] = gimple_call_arg (stmt, 1);
> @@ -524,6 +526,7 @@ instrument_builtin_call (gimple_stmt_ite
> ? MEMMODEL_SEQ_CST
> : MEMMODEL_ACQUIRE);
> update_gimple_call (gsi, decl, num + 1, args[0], args[1], args[2]);
> + maybe_clean_or_replace_eh_stmt (stmt, gsi_stmt (*gsi));
> stmt = gsi_stmt (*gsi);
> if (tsan_atomic_table[i].action == fetch_op_seq_cst)
> {
> @@ -572,6 +575,7 @@ instrument_builtin_call (gimple_stmt_ite
> return;
> update_gimple_call (gsi, decl, 5, args[0], args[1], args[2],
> args[4], args[5]);
> + maybe_clean_or_replace_eh_stmt (stmt, gsi_stmt (*gsi));
> return;
> case bool_cas:
> case val_cas:
> @@ -599,6 +603,7 @@ instrument_builtin_call (gimple_stmt_ite
> MEMMODEL_SEQ_CST),
> build_int_cst (NULL_TREE,
> MEMMODEL_SEQ_CST));
> + maybe_clean_or_replace_eh_stmt (stmt, gsi_stmt (*gsi));
> if (tsan_atomic_table[i].action == val_cas && lhs)
> {
> tree cond;
> @@ -623,6 +628,7 @@ instrument_builtin_call (gimple_stmt_ite
> build_int_cst (t, 0),
> build_int_cst (NULL_TREE,
> MEMMODEL_RELEASE));
> + maybe_clean_or_replace_eh_stmt (stmt, gsi_stmt (*gsi));
> return;
> case bool_clear:
> case bool_test_and_set:
> @@ -651,11 +657,13 @@ instrument_builtin_call (gimple_stmt_ite
> {
> update_gimple_call (gsi, decl, 3, gimple_call_arg (stmt, 0),
> build_int_cst (t, 0), last_arg);
> + maybe_clean_or_replace_eh_stmt (stmt, gsi_stmt (*gsi));
> return;
> }
> t = build_int_cst (t, targetm.atomic_test_and_set_trueval);
> update_gimple_call (gsi, decl, 3, gimple_call_arg (stmt, 0),
> t, last_arg);
> + maybe_clean_or_replace_eh_stmt (stmt, gsi_stmt (*gsi));
> stmt = gsi_stmt (*gsi);
> lhs = gimple_call_lhs (stmt);
> if (lhs == NULL_TREE)
> @@ -766,7 +774,7 @@ instrument_func_exit (void)
> Return true if func entry/exit should be instrumented. */
>
> static bool
> -instrument_memory_accesses (void)
> +instrument_memory_accesses (bool *cfg_changed)
> {
>basic_block bb;
>gimple_stmt_iterator gsi;
> @@ -775,20 +783,24 @@ instrument_memory_accesses (void)
>auto_vec tsan_func_exits;
>
>FOR_EACH_BB_FN (bb, cfun)
> -for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> - {
> - gimple *stmt = gsi_stmt (gsi);
> - if (gimple_call_internal_p (stmt, IFN_TSAN_FUNC_EXIT))
> - {
> - if (fentry_exit_instrument)
> - replace_func_exit (stmt);
> - else
> - tsan_func_exits.safe_push (stmt);
> - func_exit_seen = true;
> - }
> - else
> - fentry_exit_instrument |= instrument_gimple (&gsi);
> - }
> +{
> + for (gsi = gsi_start_bb (bb); !gsi_end
Re: [PATCH] Fix -fsanitize=thread with -fnon-call-exceptions (PR sanitizer/80110)
On Tue, Mar 21, 2017 at 09:12:51AM +0100, Richard Biener wrote: > > libtsan atomics aren't throwing, so if we transform atomics which > > are throwing with -fnon-call-exceptions, we need to clean up EH stuff. > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > Huh, but this means with TSAN we create wrong-code with > -fnon-call-exceptions and programs will crash instead of properly > catching things like null-pointer accesses? True. I think it is only about atomics, normal loads/stores are done inline with extra calls before/after that just tell the library about those loads/stores (though not sure what the library code will do with invalid or NULL pointers, if it won't crash on them). The question is what we could do about it and if it is worth bothering, I guess we'd need to build tsan_interface_atomics.cc with -fnon-call-exceptions and the question would be if it doesn't slow it down for the common case where -fnon-call-exceptions isn't used. Another option would be to add another set of __tsan_atomic* entrypoints for -fnon-call-exceptions. > We should at least document this or reject sanitize=thread with > -fnon-call-exceptions. Rejecting would mean that even code that doesn't use the atomics or doesn't use atomics on invalid pointers would not be allowed. Jakub
Re: [PATCH] Fix PR80032 - handle CLOBBER gimplification differently
On Mon, 20 Mar 2017, Jakub Jelinek wrote:
> On Fri, Mar 17, 2017 at 02:42:27PM +0100, Richard Biener wrote:
> > 2017-03-17 Richard Biener
> >
> > PR tree-optimization/80032
> > * gimplify.c (gimple_push_cleanup): Add force_uncond parameter,
> > if set force the cleanup to happen unconditionally.
> > (gimplify_target_expr): Push inserted clobbers with force_uncond
> > to avoid them being removed by control-dependent DCE.
> >
> > * g++.dg/opt/pr80032.C: New testcase.
> >
> > ! if (gimple_conditional_context ()
> > ! && ! force_uncond)
>
> This ought to fit on one line.
>
> Otherwise it looks good to me. Does the
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80032#c8
> regression happen with this patch or the earlier version of the patch?
With the DCE patch only.
> > --- gcc/testsuite/g++.dg/opt/pr80032.C (nonexistent)
> > +++ gcc/testsuite/g++.dg/opt/pr80032.C (working copy)
> > @@ -0,0 +1,121 @@
> > +// PR tree-optimization/80032
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target c++11 } */
> > +/* { dg-options "-O2" } */
>
> It is weird to mix // and /* */ comments, better just pick one style.
> Also, // { dg-do compile { target c++11 } } is perhaps simpler.
>
> > +/* If DCE removes too many CLOBBERs then stack usage goes through the
> > + roof as stack slots can no longer be shared. */
> > +/* { dg-additional-options "-Wstack-usage=200" { target x86_64-*-*
> > i?86-*-* } } */
I'll adjust and commit.
Thanks,
Richard.
Re: [PATCH] Fix -fsanitize=thread with -fnon-call-exceptions (PR sanitizer/80110)
On Tue, 21 Mar 2017, Jakub Jelinek wrote: > On Tue, Mar 21, 2017 at 09:12:51AM +0100, Richard Biener wrote: > > > libtsan atomics aren't throwing, so if we transform atomics which > > > are throwing with -fnon-call-exceptions, we need to clean up EH stuff. > > > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > Huh, but this means with TSAN we create wrong-code with > > -fnon-call-exceptions and programs will crash instead of properly > > catching things like null-pointer accesses? > > True. I think it is only about atomics, normal loads/stores are done > inline with extra calls before/after that just tell the library about > those loads/stores (though not sure what the library code will do with > invalid or NULL pointers, if it won't crash on them). > The question is what we could do about it and if it is worth bothering, > I guess we'd need to build tsan_interface_atomics.cc with > -fnon-call-exceptions and the question would be if it doesn't slow it > down for the common case where -fnon-call-exceptions isn't used. > Another option would be to add another set of __tsan_atomic* entrypoints > for -fnon-call-exceptions. > > > We should at least document this or reject sanitize=thread with > > -fnon-call-exceptions. > > Rejecting would mean that even code that doesn't use the atomics or doesn't > use atomics on invalid pointers would not be allowed. Indeed. So maybe just document it then. I suppose sanitizing in general has the issue that its events are not properly raising exceptions (of whatever kind), so documenting that programs relying on async EH to be reliably delivered may not work as expected with sanitization would be good. Richard.
Re: [PATCH 1/3] Error message on target attribute on power target (PR target/79906)
PING^ + adding power maintainer. Thanks, Martin
Re: [PATCH 2/3] Error message on target attribute on aarch64 target (PR target/79889).
PING^ + adding aarch64 maintainer. Thanks, Martin
Re: [PATCH 2/3] Error message on target attribute on aarch64 target (PR target/79889).
Hi Martin,
On 13/03/17 08:25, marxin wrote:
gcc/testsuite/ChangeLog:
2017-03-13 Martin Liska
* g++.dg/ext/mv8.C: Add aarch64* targets.
gcc/ChangeLog:
2017-03-13 Martin Liska
* config/aarch64/aarch64.c (aarch64_process_target_attr):
Show error message instead of an ICE.
You should mention PR target/79889 in your ChangeLog
---
gcc/config/aarch64/aarch64.c | 8 ++--
gcc/testsuite/g++.dg/ext/mv8.C | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index a069427f576..3107d6b84bf 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -9533,8 +9533,12 @@ aarch64_process_target_attr (tree args, const char*
pragma_or_attr)
return true;
}
- /* We expect to find a string to parse. */
- gcc_assert (TREE_CODE (args) == STRING_CST);
+
+ if (TREE_CODE (args) != STRING_CST)
+{
+ error ("attribute % argument not a string");
+ return false;
+}
Looks reasonable to me, but you'll need approval from the folks CC-ed.
Thanks,
Kyrill
size_t len = strlen (TREE_STRING_POINTER (args));
char *str_to_check = (char *) alloca (len + 1);
diff --git a/gcc/testsuite/g++.dg/ext/mv8.C b/gcc/testsuite/g++.dg/ext/mv8.C
index bbf90b5a328..b49ef84f392 100644
--- a/gcc/testsuite/g++.dg/ext/mv8.C
+++ b/gcc/testsuite/g++.dg/ext/mv8.C
@@ -1,4 +1,4 @@
-// { dg-do compile { target i?86-*-* x86_64-*-* powerpc*-*-* } }
+// { dg-do compile { target i?86-*-* x86_64-*-* powerpc*-*-* aarch64*-*-* } }
// { dg-options "" }
__attribute__((target (11,12)))
Re: Patch for GCC plugin hash table corruption bug (ID 80094)
On Tue, Mar 21, 2017 at 12:05 AM, Brad Spengler wrote: > Hi, > > As requested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80094 > i'm attaching a patch for the issue described. > > Specifically: > when the plugin_name_args_tab hash table has its 11th entry inserted, it > trigers a hash table resize. This resize performs the hash_f against > each slot's value. Though the code was looking for matches in the hash > table via simple strings, the value of each slot was a pointer to a > plugin_name_args struct. The resize would thus effectively treat the > plugin_name_args struct as a string, producing incorrect hashes that result > in subsequent lookups for previously inserted items generally failing. > > To solve this, we use the correct hash function that operates on the > base_name field of the plugin_name_args struct and to minimize the changes > required, act in a similar way to tlink.c and other files by using the > _with_hash variants of lookup and removal functions, which allow us to > search based on just the names provided (which will match with the hash > formed from the base_name field). > > The patch is untested, but can be tested via the reproducer provided > at the link above. I have verified that it passes check_GNU_style.sh. > > All versions of GCC that support plugins (4.5+) are affected by this bug, > and users of grsecurity (who enable all the GCC plugins we provide) can > potentially hit this bug today (we have over 11 plugins, though some require > specific steps to enable) and definitely will hit it in the near future > as we add more GCC plugins. Since the bug results in a compile failure with > a deceptive error message (about arguments being out of order which aren't > in fact out of order), it's important to backport this to all affected > versions. > > Let me know if you have any questions or need anything else. I've picked it up for my current test run on trunk and will commit it. It's a minor enough change to not need a copyright assignment but if you're going to do further contributions getting one is appreciated. Thanks, Richard. > Very Respectfully, > -Brad
Re: [PATCH][AArch64] Optimized implementation of search_line_fast for the CPP lexer
On 20/03/17 17:27, Andreas Schwab wrote: > On Mär 20 2017, "Richard Earnshaw (lists)" wrote: > >> I don't have access to an ILP32 run-time environment, so I'm not sure >> how I'll be able to check this out. There are some pointer checks in >> the code so it's possible something is going awry. Can you compare the >> assembly output for ILP32 and LP64 to see if there's anything obvious? > > The problem is here: > > if (__builtin_expect (vpaddd_u64 ((uint64x2_t)t), 0)) > > vpaddd_u64 returns a uint64_t value, but __builtin_expect takes a long > (32-bit in ILP32 mode). > Yikes! I'm a bit surprised __builtin_expect doesn't take a bool, but I guess that's due to needing to support old versions of C that lacked that data type. Either way, a silent truncation is very undesirable. > Andreas. > > * lex.c (search_line_fast) [__ARM_NEON && __ARM_64BIT_STATE]: > Convert 64-bit value to boolean before passing to > __builtin_expect. OK. R. > > diff --git a/libcpp/lex.c b/libcpp/lex.c > index 8a8c79cde7..a431ac8e05 100644 > --- a/libcpp/lex.c > +++ b/libcpp/lex.c > @@ -821,7 +821,7 @@ search_line_fast (const uchar *s, const uchar *end > ATTRIBUTE_UNUSED) >v = vorrq_u8 (t, vceqq_u8 (data, repl_bs)); >w = vorrq_u8 (u, vceqq_u8 (data, repl_qm)); >t = vorrq_u8 (v, w); > - if (__builtin_expect (vpaddd_u64 ((uint64x2_t)t), 0)) > + if (__builtin_expect (vpaddd_u64 ((uint64x2_t)t) != 0, 0)) > goto done; > } > >
[PATCH][DOC] Document gcov-dump and fix installation of gcov-tool (PR gcov-profile/80081).
Hello.
Apart from introduction of gcov-dump.texi file, I also fixed installation of
gcov-tool.1 man page.
Patch can also build PDF documentation. I'm attaching the new man page.
Thanks,
Martin
>From f86849be31029555efee8f5f7b8157ae7d468519 Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 21 Mar 2017 11:48:40 +0100
Subject: [PATCH] Document gcov-dump and fix installation of gcov-tool (PR
gcov-profile/80081).
gcc/ChangeLog:
2017-03-21 Martin Liska
PR gcov-profile/80081
* Makefile.in: Add gcov-dump and fix installation of gcov-tool.
* doc/gcc.texi: Include gcov-dump stuff.
* doc/gcov-dump.texi: New file.
---
gcc/Makefile.in| 11 --
gcc/doc/gcc.texi | 3 ++
gcc/doc/gcov-dump.texi | 93 ++
3 files changed, 105 insertions(+), 2 deletions(-)
create mode 100644 gcc/doc/gcov-dump.texi
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e54fac4ec1c..50d84bfdc46 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3082,7 +3082,7 @@ TEXI_GCC_FILES = gcc.texi gcc-common.texi gcc-vers.texi frontends.texi \
gcov.texi trouble.texi bugreport.texi service.texi \
contribute.texi compat.texi funding.texi gnu.texi gpl_v3.texi \
fdl.texi contrib.texi cppenv.texi cppopts.texi avr-mmcu.texi \
- implement-c.texi implement-cxx.texi gcov-tool.texi
+ implement-c.texi implement-cxx.texi gcov-tool.texi gcov-dump.texi
# we explicitly use $(srcdir)/doc/tm.texi here to avoid confusion with
# the generated tm.texi; the latter might have a more recent timestamp,
@@ -3205,7 +3205,7 @@ $(build_htmldir)/gccinstall/index.html: $(TEXI_GCCINSTALL_FILES)
$(SHELL) $(srcdir)/doc/install.texi2html
MANFILES = doc/gcov.1 doc/cpp.1 doc/gcc.1 doc/gfdl.7 doc/gpl.7 \
- doc/fsf-funding.7 doc/gcov-tool.1
+ doc/fsf-funding.7 doc/gcov-tool.1 doc/gcov-dump.1
generated-manpages: man
@@ -3613,6 +3613,8 @@ install-man: lang.install-man \
$(DESTDIR)$(man1dir)/$(GCC_INSTALL_NAME)$(man1ext) \
$(DESTDIR)$(man1dir)/$(CPP_INSTALL_NAME)$(man1ext) \
$(DESTDIR)$(man1dir)/$(GCOV_INSTALL_NAME)$(man1ext) \
+ $(DESTDIR)$(man1dir)/$(GCOV_TOOL_INSTALL_NAME)$(man1ext) \
+ $(DESTDIR)$(man1dir)/$(GCOV_DUMP_INSTALL_NAME)$(man1ext) \
$(DESTDIR)$(man7dir)/fsf-funding$(man7ext) \
$(DESTDIR)$(man7dir)/gfdl$(man7ext) \
$(DESTDIR)$(man7dir)/gpl$(man7ext)
@@ -3642,6 +3644,11 @@ $(DESTDIR)$(man1dir)/$(GCOV_TOOL_INSTALL_NAME)$(man1ext): doc/gcov-tool.1 instal
-$(INSTALL_DATA) $< $@
-chmod a-x $@
+$(DESTDIR)$(man1dir)/$(GCOV_DUMP_INSTALL_NAME)$(man1ext): doc/gcov-dump.1 installdirs
+ -rm -f $@
+ -$(INSTALL_DATA) $< $@
+ -chmod a-x $@
+
# Install all the header files built in the include subdirectory.
install-headers: $(INSTALL_HEADERS_DIR)
# Fix symlinks to absolute paths in the installed include directory to
diff --git a/gcc/doc/gcc.texi b/gcc/doc/gcc.texi
index c97528803fe..87df83f0131 100644
--- a/gcc/doc/gcc.texi
+++ b/gcc/doc/gcc.texi
@@ -67,6 +67,7 @@ Texts being (a) (see below), and with the Back-Cover Texts being (b)
* g++: (gcc). The GNU C++ compiler.
* gcov: (gcc) Gcov.@command{gcov}---a test coverage program.
* gcov-tool: (gcc) Gcov-tool. @command{gcov-tool}---an offline gcda profile processing program.
+* gcov-dump: (gcc) Gcov-dump. @command{gcov-dump}---an offline gcda and gcno profile dump tool.
@end direntry
This file documents the use of the GNU compilers.
@sp 1
@@ -140,6 +141,7 @@ Introduction, gccint, GNU Compiler Collection (GCC) Internals}.
* Compatibility:: Binary Compatibility
* Gcov::@command{gcov}---a test coverage program.
* Gcov-tool:: @command{gcov-tool}---an offline gcda profile processing program.
+* Gcov-dump:: @command{gcov-dump}---an offline gcda and gcno profile dump tool.
* Trouble:: If you have trouble using GCC.
* Bugs::How, why and where to report bugs.
* Service:: How To Get Help with GCC
@@ -167,6 +169,7 @@ Introduction, gccint, GNU Compiler Collection (GCC) Internals}.
@include compat.texi
@include gcov.texi
@include gcov-tool.texi
+@include gcov-dump.texi
@include trouble.texi
@include bugreport.texi
@include service.texi
diff --git a/gcc/doc/gcov-dump.texi b/gcc/doc/gcov-dump.texi
new file mode 100644
index 000..d7931fd3a19
--- /dev/null
+++ b/gcc/doc/gcov-dump.texi
@@ -0,0 +1,93 @@
+@c Copyright (C) 2017 Free Software Foundation, Inc.
+@c This is part of the GCC manual.
+@c For copying conditions, see the file gcc.texi.
+
+@ignore
+@c man begin COPYRIGHT
+Copyright @copyright{} 2017 Free Software Foundation, Inc.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being ``GNU General Public License'' and ``Funding
+Free Software'', the Front-Cover texts being (a) (see below), and with
+the Back-Cover Texts bei
[PATCH] Fix another profiledbootstrap warning (PR libfortran/79956).
Hello. Currently running tests and as the patch is pre-approved by Richi, I'm going to install it afterwards. Martin >From 78af53942b50d6bb47959d263336072f1d7ff6ed Mon Sep 17 00:00:00 2001 From: marxin Date: Tue, 21 Mar 2017 11:57:27 +0100 Subject: [PATCH] Fix another profiledbootstrap warning (PR libfortran/79956). gcc/ChangeLog: 2017-03-21 Martin Liska PR libfortran/79956 * simplify-rtx.c (simplify_immed_subreg): Initialize a variable to NULL. --- gcc/simplify-rtx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c index fb04cd002ac..640ccb7cb95 100644 --- a/gcc/simplify-rtx.c +++ b/gcc/simplify-rtx.c @@ -5711,7 +5711,7 @@ simplify_immed_subreg (machine_mode outermode, rtx op, int num_elem; rtx * elems; int elem_bitsize; - rtx result_s; + rtx result_s = NULL; rtvec result_v = NULL; enum mode_class outer_class; machine_mode outer_submode; -- 2.12.0
RE: [PATCH,testsuite] Skip gcc.dg/pic-2.c and gcc.dg/pie-2.c for MIPS.
> > From: Matthew Fortune > > > > I think the skip is OK here. I'd like to get Catherine's opinion on > > this though too. I don't think we should change the definition of __PIC__ > > for -fPIC on MIPS as multi-got solves 'most' issues. If we start trying to > > figure out what __PIC__ should mean on MIPS then we will get into a big > > mess with -mxgot as that is arguably __PIC__==2 but I expect there will > > be several differing opinions. > > > From: Catherine Moore > > I think the skip is the right way to go as well. The patch is OK with me. > Catherine > Committed as r246311. Thanks, Toma
Re: [PATCH] MPX: Fix option handling.
On 03/17/2017 01:17 PM, Rainer Orth wrote:
> Jakub Jelinek writes:
>
>> On Fri, Mar 10, 2017 at 02:09:20PM +0100, Martin Liška wrote:
>>> Hello.
>>>
>>> This is follow-up patch which I agreed on with Jakub.
>>> It enables CHKP with LSAN and majority of UBSAN options.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> Ready to be installed?
>>> Martin
>>
>>> >From a410d5e4e028d34dc00b4aa637cdcd3986b971d8 Mon Sep 17 00:00:00 2001
>>> From: marxin
>>> Date: Fri, 10 Mar 2017 11:05:27 +0100
>>> Subject: [PATCH] MPX: Fix option handling.
>>>
>>> gcc/ChangeLog:
>>>
>>> 2017-03-10 Martin Liska
>>>
>>> PR target/65705
>>> PR target/69804
>>> * toplev.c (process_options): Enable MPX with LSAN and UBSAN
>>> (except -fsanitize=bounds and -fsanitize=bounds-strict).
>>
>> Please avoid the ()s, that is confusing with ()s used to surround
>> function etc. names. Just use UBSAN,
>> except ... strict.
>>
>>> * tree-chkp.c (chkp_walk_pointer_assignments): Verify that
>>> FIELD != NULL.
>>
>>> + error_at (UNKNOWN_LOCATION,
>>> + "-fcheck-pointer-bounds is not supported with "
>>> + "-fsanitize=bounds-strict");
>>> + flag_check_pointer_bounds = 0;
>>
>> Given the recent i18n discussions, perhaps this ought to be
>> %<-fcheck-pointer-bounds%> and %<-fsanitize=bounds-strict%> and similarly
>> elsewhere (of course not for Address/Thread Sanitizer words).
>>
>> Ok for trunk either way.
>
> Unfortunately, that last change broke gcc.target/i386/pr65044.c:
>
> FAIL: gcc.target/i386/pr65044.c (test for errors, line )
> FAIL: gcc.target/i386/pr65044.c (test for excess errors)
>
> seen e.g. on Linux/x86_64 and Solaris/x86.
>
> We have
>
> Excess errors:
> cc1: error: '-fcheck-pointer-bounds' is not supported with Address Sanitizer
>
> while the test expects
>
> /* { dg-error "-fcheck-pointer-bounds is not supported with Address
> Sanitizer" "" { target *-*-* } 0 } */
>
> I guess that, given gcc-dg.exp hardcodes LANG=C, changing the dg-error
> to just include the single quotes should be enough.
>
> Rainer
>
Will be fixed with following patch.
Similar to what we do in gcc/testsuite/objc.dg/fobjc-exceptions-1.m.
Martin
>From cb4916381ee03cfb6c147a61e85ab1b6c7c634e9 Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 21 Mar 2017 12:19:49 +0100
Subject: [PATCH] Fix dg-error for a test
gcc/testsuite/ChangeLog:
2017-03-21 Martin Liska
* gcc.target/i386/pr65044.c: Add '.' in order to catch
apostrophes.
---
gcc/testsuite/gcc.target/i386/pr65044.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr65044.c b/gcc/testsuite/gcc.target/i386/pr65044.c
index 9b0636339e5..d5cfecd15a9 100644
--- a/gcc/testsuite/gcc.target/i386/pr65044.c
+++ b/gcc/testsuite/gcc.target/i386/pr65044.c
@@ -1,6 +1,6 @@
/* { dg-do compile { target { ! x32 } } } */
/* { dg-options "-fcheck-pointer-bounds -mmpx -fsanitize=address" } */
-/* { dg-error "-fcheck-pointer-bounds is not supported with Address Sanitizer" "" { target *-*-* } 0 } */
+/* { dg-error ".-fcheck-pointer-bounds. is not supported with Address Sanitizer" "" { target *-*-* } 0 } */
extern int x[];
--
2.12.0
[PATCH] Fix PR80122
Only now we get a testcase using __builtin_va_arg_pack() and friends
two levels deep which doesn't work since we (reliably) perform inlining
bottom-up.
The following fixes the bug by simply not replacing the builtins
with garbage in case the caller wasn't passing args but an argument
pack itself.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2017-03-21 Richard Biener
PR tree-optimization/80122
* tree-inline.c (copy_bb): Do not expans va-arg packs or
va_arg_pack_len when the inlined call stmt requires pack
expansion itself.
* tree-inline.h (struct copy_body_data): Make call_stmt a gcall *.
* gcc.dg/torture/pr80122.c: New testcase.
Index: gcc/tree-inline.c
===
*** gcc/tree-inline.c (revision 246277)
--- gcc/tree-inline.c (working copy)
*** copy_bb (copy_body_data *id, basic_block
*** 1860,1866
call_stmt = dyn_cast (stmt);
if (call_stmt
&& gimple_call_va_arg_pack_p (call_stmt)
! && id->call_stmt)
{
/* __builtin_va_arg_pack () should be replaced by
all arguments corresponding to ... in the caller. */
--- 1860,1867
call_stmt = dyn_cast (stmt);
if (call_stmt
&& gimple_call_va_arg_pack_p (call_stmt)
! && id->call_stmt
! && ! gimple_call_va_arg_pack_p (id->call_stmt))
{
/* __builtin_va_arg_pack () should be replaced by
all arguments corresponding to ... in the caller. */
*** copy_bb (copy_body_data *id, basic_block
*** 1940,1946
&& id->call_stmt
&& (decl = gimple_call_fndecl (stmt))
&& DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL
! && DECL_FUNCTION_CODE (decl) == BUILT_IN_VA_ARG_PACK_LEN)
{
/* __builtin_va_arg_pack_len () should be replaced by
the number of anonymous arguments. */
--- 1941,1948
&& id->call_stmt
&& (decl = gimple_call_fndecl (stmt))
&& DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL
! && DECL_FUNCTION_CODE (decl) == BUILT_IN_VA_ARG_PACK_LEN
! && ! gimple_call_va_arg_pack_p (id->call_stmt))
{
/* __builtin_va_arg_pack_len () should be replaced by
the number of anonymous arguments. */
*** expand_call_inline (basic_block bb, gimp
*** 4584,4590
/* Record the function we are about to inline. */
id->src_fn = fn;
id->src_cfun = DECL_STRUCT_FUNCTION (fn);
! id->call_stmt = stmt;
/* If the src function contains an IFN_VA_ARG, then so will the dst
function after inlining. Likewise for IFN_GOMP_USE_SIMT. */
--- 4586,4592
/* Record the function we are about to inline. */
id->src_fn = fn;
id->src_cfun = DECL_STRUCT_FUNCTION (fn);
! id->call_stmt = call_stmt;
/* If the src function contains an IFN_VA_ARG, then so will the dst
function after inlining. Likewise for IFN_GOMP_USE_SIMT. */
Index: gcc/tree-inline.h
===
*** gcc/tree-inline.h (revision 246277)
--- gcc/tree-inline.h (working copy)
*** struct copy_body_data
*** 81,87
/* GIMPLE_CALL if va arg parameter packs should be expanded or NULL
is not. */
! gimple *call_stmt;
/* Exception landing pad the inlined call lies in. */
int eh_lp_nr;
--- 81,87
/* GIMPLE_CALL if va arg parameter packs should be expanded or NULL
is not. */
! gcall *call_stmt;
/* Exception landing pad the inlined call lies in. */
int eh_lp_nr;
Index: gcc/testsuite/gcc.dg/torture/pr80122.c
===
*** gcc/testsuite/gcc.dg/torture/pr80122.c (nonexistent)
--- gcc/testsuite/gcc.dg/torture/pr80122.c (working copy)
***
*** 0
--- 1,52
+ /* { dg-do run } */
+
+ #define __GNU_ALWAYS_INLINE inline __attribute__(( __always_inline__))
+
+ #define DEVT_ALL0
+
+ #define CMD_ABI_DEVICES 100
+
+ static __GNU_ALWAYS_INLINE int
+ send_msg_to_gm_w_dev_t(int msg_type, unsigned int dev_msg_type,
+ int devt, ...)
+ {
+ char s[256];
+ int nArgs = __builtin_va_arg_pack_len();
+ if (nArgs != 2)
+ __builtin_abort ();
+ __builtin_sprintf (s, "%d", __builtin_va_arg_pack ());
+ if (__builtin_strcmp (s, "99") != 0)
+ __builtin_abort ();
+ /* do something with nArgs and ... */
+ return 0;
+ }
+
+ static __GNU_ALWAYS_INLINE int
+ send_msg_to_gm(int msg_type, unsigned int dev_msg_type,
+ ...)
+ {
+ int nArgs = __builtin_va_arg_pack_len();
+ if (nArgs != 2)
+ __builtin_abort ();
+ return send_msg_
[Patch, testsuite] Fix failing overflow-1.c for avr
Hi,
The test assumes 32 bit ints, and expects a constant in the
dump that is only valid for 32 bit ints. This trivial patch
fixes that by explicitly specifying __UINT32_TYPE__ as the type.
Committed as obvious.
Regards
Senthil
gcc/testsuite/ChangeLog
2017-03-21 Senthil Kumar Selvaraj
* gcc.dg/tree-ssa/overflow-1.c: Use __UINT32_TYPE__ for targets
with sizeof(int) < 4.
diff --git gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
index e126609c53d9..b664d0f120aa 100644
--- gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
+++ gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
@@ -1,14 +1,20 @@
/* { dg-do compile } */
/* { dg-options "-O -fdump-tree-optimized" } */
-int f(unsigned a){
-unsigned b=5;
-unsigned c=a-b;
+#if __SIZEOF_INT__ < 4
+ __extension__ typedef __UINT32_TYPE__ uint32_t;
+#else
+ typedef unsigned uint32_t;
+#endif
+
+int f(uint32_t a){
+uint32_t b=5;
+uint32_t c=a-b;
return c>a;
}
-int g(unsigned a){
-unsigned b=32;
-unsigned c=a+b;
+int g(uint32_t a){
+uint32_t b=32;
+uint32_t c=a+b;
return c
Re: [PATCH][DOC] Document gcov-dump and fix installation of gcov-tool (PR gcov-profile/80081).
On Tue, Mar 21, 2017 at 11:55 AM, Martin Liška wrote: > Hello. > > Apart from introduction of gcov-dump.texi file, I also fixed installation of > gcov-tool.1 man page. > Patch can also build PDF documentation. I'm attaching the new man page. Ok. Thanks, Richard. > Thanks, > Martin
Re: [Patch, testsuite] Fix failing overflow-1.c for avr
On 21.03.2017 13:07, Senthil Kumar Selvaraj wrote:
Hi,
The test assumes 32 bit ints, and expects a constant in the
dump that is only valid for 32 bit ints. This trivial patch
fixes that by explicitly specifying __UINT32_TYPE__ as the type.
Committed as obvious.
Regards
Senthil
gcc/testsuite/ChangeLog
2017-03-21 Senthil Kumar Selvaraj
* gcc.dg/tree-ssa/overflow-1.c: Use __UINT32_TYPE__ for targets
with sizeof(int) < 4.
diff --git gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
index e126609c53d9..b664d0f120aa 100644
--- gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
+++ gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
@@ -1,14 +1,20 @@
/* { dg-do compile } */
/* { dg-options "-O -fdump-tree-optimized" } */
-int f(unsigned a){
-unsigned b=5;
-unsigned c=a-b;
+#if __SIZEOF_INT__ < 4
+ __extension__ typedef __UINT32_TYPE__ uint32_t;
+#else
+ typedef unsigned uint32_t;
Dunno if this matters, but it changes the test for 64-bit int.
Johann
+#endif
+
+int f(uint32_t a){
+uint32_t b=5;
+uint32_t c=a-b;
return c>a;
}
-int g(unsigned a){
-unsigned b=32;
-unsigned c=a+b;
+int g(uint32_t a){
+uint32_t b=32;
+uint32_t c=a+b;
return c
Re: [Patch, testsuite] Fix failing overflow-1.c for avr
On 21.03.2017 13:31, Georg-Johann Lay wrote:
On 21.03.2017 13:07, Senthil Kumar Selvaraj wrote:
Hi,
The test assumes 32 bit ints, and expects a constant in the
dump that is only valid for 32 bit ints. This trivial patch
fixes that by explicitly specifying __UINT32_TYPE__ as the type.
Committed as obvious.
Regards
Senthil
gcc/testsuite/ChangeLog
2017-03-21 Senthil Kumar Selvaraj
* gcc.dg/tree-ssa/overflow-1.c: Use __UINT32_TYPE__ for targets
with sizeof(int) < 4.
diff --git gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
index e126609c53d9..b664d0f120aa 100644
--- gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
+++ gcc/testsuite/gcc.dg/tree-ssa/overflow-1.c
@@ -1,14 +1,20 @@
/* { dg-do compile } */
/* { dg-options "-O -fdump-tree-optimized" } */
-int f(unsigned a){
-unsigned b=5;
-unsigned c=a-b;
+#if __SIZEOF_INT__ < 4
+ __extension__ typedef __UINT32_TYPE__ uint32_t;
+#else
+ typedef unsigned uint32_t;
Dunno if this matters, but it changes the test for 64-bit int.
argh, forget my comment :-)
Johann
+#endif
+
+int f(uint32_t a){
+uint32_t b=5;
+uint32_t c=a-b;
return c>a;
}
-int g(unsigned a){
-unsigned b=32;
-unsigned c=a+b;
+int g(uint32_t a){
+uint32_t b=32;
+uint32_t c=a+b;
return c
RE: [PATCH] Fix MIPS-specific ICE in gcc.dg/pr77834.c (PR rtl-optimization/79150).
Hi, > From: Segher Boessenkool > On Mon, Mar 20, 2017 at 10:08:25PM +, Moore, Catherine wrote: > > I'm okay with the workaround for stage 4, but would like to see the pr > > remain > open until a proper fix is installed on trunk. > > Yeah. > Sure, I'll keep it open. > > Toma, would you be able to pursue the original patch that you attached to > > the > bug report? Yes, I intend to work on it after stage 4 ends. The temporary fix was committed as r246320. Thanks, Toma
Re: Document PR79806 as a non-bug
On 03/15/2017 02:29 PM, Bernd Schmidt wrote: I suggest we apply the following and close the PR as INVALID (not a bug). Ok? Agreed. I've already taken care of BZ. So just apply the patch to the trunk. Jeff
[committed] Fix can_combine_p (PR target/80125)
Hi!
As mentioned in the PR, combiner sometimes artificially splits a parallel
into two instructions, the first one not really in the insn stream, both
with the same uid and PREV_INSN (i1) == 0 and NEXT_INSN (i1) == i2.
In that case, calling reg_used_between_p (x, y, i1) crashes the compiler,
because it doesn't find i1 by walking from y forward.
Furthermore, the (succ2 && reg_used_between_p (dest, succ, succ2))
test has been already present, so no need to duplicate it.
Bootstrapped/regtested on powerpc64le-linux, approved on IRC by Segher,
committed to trunk.
2017-03-21 Jakub Jelinek
Segher Boessenkool
PR target/80125
* combine.c (can_combine_p): Revert the 2017-03-20 change, only
check reg_used_between_p between insn and one of succ or succ2
depending on if succ is artificial insn not inserted into insn
stream.
* gcc.target/powerpc/pr80125.c: New test.
--- gcc/combine.c.jj2017-03-21 07:57:01.0 +0100
+++ gcc/combine.c 2017-03-21 11:02:51.170746744 +0100
@@ -1954,15 +1954,20 @@ can_combine_p (rtx_insn *insn, rtx_insn
/* Don't substitute into a non-local goto, this confuses CFG. */
|| (JUMP_P (i3) && find_reg_note (i3, REG_NON_LOCAL_GOTO, NULL_RTX))
/* Make sure that DEST is not used after INSN but before SUCC, or
-between SUCC and SUCC2. */
- || (succ && reg_used_between_p (dest, insn, succ))
- || (succ2 && reg_used_between_p (dest, succ, succ2))
- /* Make sure that DEST is not used after SUCC but before I3. */
+after SUCC and before SUCC2, or after SUCC2 but before I3. */
|| (!all_adjacent
&& ((succ2
&& (reg_used_between_p (dest, succ2, i3)
|| reg_used_between_p (dest, succ, succ2)))
- || (!succ2 && succ && reg_used_between_p (dest, succ, i3
+ || (!succ2 && succ && reg_used_between_p (dest, succ, i3))
+ || (succ
+ /* SUCC and SUCC2 can be split halves from a PARALLEL; in
+that case SUCC is not in the insn stream, so use SUCC2
+instead for this test. */
+ && reg_used_between_p (dest, insn,
+succ2
+&& INSN_UID (succ) == INSN_UID (succ2)
+? succ2 : succ
/* Make sure that the value that is to be substituted for the register
does not use any registers whose values alter in between. However,
If the insns are adjacent, a use can't cross a set even though we
--- gcc/testsuite/gcc.target/powerpc/pr80125.c.jj 2017-03-21
10:23:31.409808224 +0100
+++ gcc/testsuite/gcc.target/powerpc/pr80125.c 2017-03-21 10:22:23.0
+0100
@@ -0,0 +1,23 @@
+/* PR target/80125 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -maltivec" } */
+
+#include
+
+int a[1];
+
+void
+foo ()
+{
+ vector int b, e, f, g, h, j, n;
+ vector unsigned c, d;
+ f = vec_sums (h, b);
+ vector int i = vec_mergel (f, g);
+ vector int k = vec_mergel (i, j);
+ vector int l = vec_sl (k, c);
+ vector int m = vec_sl (l, d);
+ vector char o;
+ vector int p = vec_perm (m, n, o);
+ e = vec_sra (p, c);
+ vec_st (e, 0, a);
+}
Jakub
Re: [PATCH] have chkp skip flexible member arrays (PR #79986)
On 03/20/2017 10:27 PM, Jason Merrill wrote:
On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor wrote:
On 03/20/2017 05:51 PM, Jason Merrill wrote:
On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
Attached is a minimal patch to avoid an ICE in CHKP upon
encountering one form of an initializer for a flexible array
member, specifically the empty string:
int f ()
{
struct B { int n; char a[]; };
return ((struct B){ 1, "" }).a[0];
}
Although GCC accepts (and doesn't ICE on) non-empty initializers
for flexible array members, such as
(struct B){ 1, "123" }
How do you mean? When I compile this with the C front end, I get
error: non-static initialization of a flexible array member
I meant that G++ accepts it, doesn't ICE, but emits wrong code.
(it's consistently rejected by the C front end). Sorry for not
being clear about it.
Ah, OK. It seems to me that the wrong code bug is worth addressing;
why does rejecting the code seem risky to you?
I have a few reasons: First, it's not a regression (I raised
bug 69696 for it in early 2016) so strictly it's out of scope
for this stage. Second, there are a number of bugs related
to the initialization of flexible array members so the fixes
are probably not going to be contained to a single function
or file. Third, the flexible member array changes I made in
the past were not trivial, took time to develop, and the two
of us iterated over some of them for weeks. Despite your
careful review and my extensive testing some of them
introduced regressions that are still being patched up.
Fourth, making a change to reject code this close to a release
runs the risk of breaking code that has successfully compiled
in mass rebuilds and others' tests with the new compiler.
While that could be viewed as a good change for invalid code
that's exercised at run time, it could also break programs
where the bad code is never exercised.
As I understand the schedule, the release is expected sometime
in early April. I leave on April 2 for a week, so I have only
until then. I don't think that leaves enough time. I'd be
uncomfortable taking on a project this late in the cycle that
could put the release in jeopardy, or that I might have to
rely on others to finish up.
Martin
[PATCH] Fix doloop ICE (PR rtl-optimization/80112)
Hi!
doloop_condition_get computes cmp in several places, and in one of them
wants to fail if the condition inside of it isn't NE against const0_rtx.
The problem with that is that nothing checked what cmp is yet,
/* Check for (set (pc) (if_then_else (condition)
(label_ref (label))
(pc))). */
if (GET_CODE (cmp) != SET
|| SET_DEST (cmp) != pc_rtx
|| GET_CODE (SET_SRC (cmp)) != IF_THEN_ELSE
|| GET_CODE (XEXP (SET_SRC (cmp), 1)) != LABEL_REF
|| XEXP (SET_SRC (cmp), 2) != pc_rtx)
return 0;
is checked only a couple of lines later.
To fix this, either we can use the following patch which guards the
early check with the necessary subset of the later check, or we could
for
if (GET_CODE (cmp) != SET || GET_CODE (SET_SRC (cmp)) != IF_THEN_ELSE)
return 0;
before cond = XEXP (SET_SRC (cmp), 0);,
or set some bool flag and only verify this requirement if the bool flag
is true after the later check.
Any preferences? The following has been successfully bootstrapped/regtested
on powerpc64le-linux.
2017-03-21 Jakub Jelinek
PR rtl-optimization/80112
* loop-doloop.c (doloop_condition_get): Don't check condition
if cmp isn't SET with IF_THEN_ELSE src.
* gcc.dg/pr80112.c: New test.
--- gcc/loop-doloop.c.jj2017-01-16 22:34:03.0 +0100
+++ gcc/loop-doloop.c 2017-03-21 11:57:58.0 +0100
@@ -153,10 +153,13 @@ doloop_condition_get (rtx_insn *doloop_p
}
else
inc = PATTERN (prev_insn);
- /* We expect the condition to be of the form (reg != 0) */
- cond = XEXP (SET_SRC (cmp), 0);
- if (GET_CODE (cond) != NE || XEXP (cond, 1) != const0_rtx)
-return 0;
+ if (GET_CODE (cmp) == SET && GET_CODE (SET_SRC (cmp)) == IF_THEN_ELSE)
+ {
+ /* We expect the condition to be of the form (reg != 0) */
+ cond = XEXP (SET_SRC (cmp), 0);
+ if (GET_CODE (cond) != NE || XEXP (cond, 1) != const0_rtx)
+ return 0;
+ }
}
else
{
--- gcc/testsuite/gcc.dg/pr80112.c.jj 2017-03-21 12:12:23.382509916 +0100
+++ gcc/testsuite/gcc.dg/pr80112.c 2017-03-21 12:11:18.0 +0100
@@ -0,0 +1,21 @@
+/* PR rtl-optimization/80112 */
+/* { dg-do compile } */
+/* { dg-options "-Os -fmodulo-sched" } */
+
+void **a;
+
+void
+foo (int c)
+{
+ void *d[] = {&&e, &&f};
+ a = d;
+ switch (c)
+{
+f:
+ c = 9;
+ /* FALLTHRU */
+case 9:
+ goto *a++;
+e:;
+}
+}
Jakub
Re: [PATCH] have chkp skip flexible member arrays (PR #79986)
On Tue, Mar 21, 2017 at 09:08:49AM -0600, Martin Sebor wrote: > As I understand the schedule, the release is expected sometime > in early April. I leave on April 2 for a week, so I have only > until then. I don't think that leaves enough time. I'd be > uncomfortable taking on a project this late in the cycle that > could put the release in jeopardy, or that I might have to > rely on others to finish up. The release is expected when it is ready. We still have 8 P1s, so we don't meet the release criteria, and have way too many P2-P3s, early April is very unlikely, late April is much more likely than that. Jakub
Re: [PATCH v2] Fix PR79908
Hi On 21 March 2017 at 09:03, Richard Biener wrote: > On Mon, Mar 20, 2017 at 8:15 PM, Bill Schmidt > wrote: >> Hi, >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 shows a case where >> pass_stdarg ICEs attempting to gimplify a COMPLEX_EXPR with side >> effects as an lvalue. This occurs when the LHS of a VA_ARG has been >> cast away. This patch, credit to Richard Biener, uses >> force_gimple_operand to instantiate the necessary side effects rather >> than gimplify_expr using is_gimple_lvalue. The test case is taken >> wholesale from the bug report. >> >> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no >> regressions. Is this ok for trunk? > > Ok! > Since this was committed (r246319), I've noticed that GCC cross-compiler fails to build glibc for target aarch64-linux-gnu. I'm seeing: In function '_IO_vfscanf_internal': cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:5627 0x8ae5bf gimplify_modify_expr /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:5627 0x8902b4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11198 0x8963c8 gimplify_stmt(tree_node**, gimple**) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 0x89bf55 gimplify_cond_expr /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3971 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /tmp/1882393_6.tmpdir/aci-In function '_IO_vfscanf_internal': cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:5627 0x8ae5bf gimplify_modify_expr /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:5627 0x8902b4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11198 0x8963c8 gimplify_stmt(tree_node**, gimple**) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 0x89bf55 gimplify_cond_expr /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3971 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 0x8963c8 gimplify_stmt(tree_node**, gimple**) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 0x89b803 gimplify_cond_expr /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3864 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 0x89328f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11356 0x8b49f9 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*), tree_node*) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify-me.c:78 0xda0f16 expand_ifn_va_arg_1 /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1064 0xda0f16 expand_ifn_va_arg /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1105 0xda494b execute /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1158 gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 0x8963c8 gimplify_stmt(tree_node**, gimple**) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 0x89b803 gimplify_cond_expr /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3864 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 0x89328f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11356 0x8b49f9 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*), tree_node*) /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify-me.c:78 0xda0f16 expand_ifn_va_arg_1 /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1064 0xda0f16 expand_ifn_va_arg /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1105 0xda494b execute /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1158 I can start a manual build if you need a .i file. Thanks, Christophe > Thanks, > Richard. > >> Thanks, >> Bill >> >> >> [gcc] >> >> 2017-03-20 Bill Schmidt >> Richard Biener >> >> PR tree-optimization/79908 >> * tree-stdarg.c (expand_ifn_va_arg_1): For a VA_ARG whose LHS has >> been cast away, use f
Re: [PATCH] have chkp skip flexible member arrays (PR #79986)
On 03/21/2017 09:15 AM, Jakub Jelinek wrote: On Tue, Mar 21, 2017 at 09:08:49AM -0600, Martin Sebor wrote: As I understand the schedule, the release is expected sometime in early April. I leave on April 2 for a week, so I have only until then. I don't think that leaves enough time. I'd be uncomfortable taking on a project this late in the cycle that could put the release in jeopardy, or that I might have to rely on others to finish up. The release is expected when it is ready. We still have 8 P1s, so we don't meet the release criteria, and have way too many P2-P3s, early April is very unlikely, late April is much more likely than that. Late April is consistent with my estimate of when the release will be ready as well. jeff
C++ PATCH to fix bogus maybe-uninitialized warning (PR c++/80119)
This patch fixes a bogus maybe-uninitialized warning reported in the PR.
The issue is that we're not able to fold away useless CLEANUP_POINT_EXPRs,
as e.g. in
if (<>)
// bogus warning
Here, the cleanup_point was built as <>,
which cp_fold_r reduces to <>, but leaves it as that and
passes it to the gimplifier.
Jakub suggested handling this in cp_fold. fold_build_cleanup_point_expr says
that "if the expression does not have side effects then we don't have to wrap
it with a cleanup point expression", so I think the following should be safe.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2017-03-21 Marek Polacek
PR c++/80119
* cp-gimplify.c (cp_fold): Strip CLEANUP_POINT_EXPR if the expression
doesn't have side effects.
* g++.dg/warn/Wuninitialized-9.C: New test.
diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
index ebb5da9..b4319ca 100644
--- gcc/cp/cp-gimplify.c
+++ gcc/cp/cp-gimplify.c
@@ -2056,6 +2056,14 @@ cp_fold (tree x)
code = TREE_CODE (x);
switch (code)
{
+case CLEANUP_POINT_EXPR:
+ /* Strip CLEANUP_POINT_EXPR if the expression doesn't have side
+effects. */
+ r = cp_fold (TREE_OPERAND (x, 0));
+ if (!TREE_SIDE_EFFECTS (r))
+ x = r;
+ break;
+
case SIZEOF_EXPR:
x = fold_sizeof_expr (x);
break;
diff --git gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
index e69de29..3432b4f 100644
--- gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
+++ gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
@@ -0,0 +1,19 @@
+// PR c++/80119
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wuninitialized" }
+
+#include
+
+template
+void failing_function(std::integral_constant)
+{
+ int i;
+ if (b && (i = 4)) {
+ ++i; // { dg-bogus "may be used uninitialized" }
+ }
+}
+
+int main (void)
+{
+ failing_function(std::false_type());
+}
Marek
Re: [PATCH] Fix ICE on invalid with -Walloca-larger-than (PR tree-optimization/80109)
On 03/20/2017 12:51 PM, Marek Polacek wrote: We crash with this invalid testcase because we aren't properly checking what we are passing down to get_range_info, i.e., we can't pass a pointer. So fixed by checking the argument first, and calling alloca_type_and_limit if it is of a wrong type. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2017-03-20 Marek Polacek Martin Sebor PR tree-optimization/80109 * gimple-ssa-warn-alloca.c (alloca_call_type): Only call get_range_info on INTEGRAL_TYPE_P. * gcc.dg/Walloca-14.c: New test. OK. jeff
Re: [PATCH] avoid relying on getcwd extensions (PR 80047)
On 03/15/2017 02:29 PM, Martin Sebor wrote: PR 80047 - fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401) points out that the fixincludes program calls getcwd with the first argument set to NULL, apparently a Glibc extension, to have the function allocate the memory to which it then returns a pointer. The attached patch avoids this and also avoids assuming the function cannot fail. This is not a regression so I assume it's not suitable for GCC 7 but rather for GCC 8 when stage 1 opens. OK for gcc-8. jeff
Re: [PATCH] have chkp skip flexible member arrays (PR #79986)
On Tue, Mar 21, 2017 at 09:08:49AM -0600, Martin Sebor wrote:
> On 03/20/2017 10:27 PM, Jason Merrill wrote:
> > On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor wrote:
> > > On 03/20/2017 05:51 PM, Jason Merrill wrote:
> > > > On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
> > > > >
> > > > > Attached is a minimal patch to avoid an ICE in CHKP upon
> > > > > encountering one form of an initializer for a flexible array
> > > > > member, specifically the empty string:
> > > > >
> > > > > int f ()
> > > > > {
> > > > > struct B { int n; char a[]; };
> > > > >
> > > > > return ((struct B){ 1, "" }).a[0];
> > > > > }
> > > > >
> > > > > Although GCC accepts (and doesn't ICE on) non-empty initializers
> > > > > for flexible array members, such as
> > > > >
> > > > > (struct B){ 1, "123" }
> > > >
> > > >
> > > > How do you mean? When I compile this with the C front end, I get
> > > >
> > > > error: non-static initialization of a flexible array member
> > >
> > > I meant that G++ accepts it, doesn't ICE, but emits wrong code.
> > > (it's consistently rejected by the C front end). Sorry for not
> > > being clear about it.
> >
> > Ah, OK. It seems to me that the wrong code bug is worth addressing;
> > why does rejecting the code seem risky to you?
>
> I have a few reasons: First, it's not a regression (I raised
> bug 69696 for it in early 2016) so strictly it's out of scope
> for this stage. Second, there are a number of bugs related
> to the initialization of flexible array members so the fixes
> are probably not going to be contained to a single function
> or file. Third, the flexible member array changes I made in
> the past were not trivial, took time to develop, and the two
> of us iterated over some of them for weeks. Despite your
> careful review and my extensive testing some of them
> introduced regressions that are still being patched up.
> Fourth, making a change to reject code this close to a release
> runs the risk of breaking code that has successfully compiled
> in mass rebuilds and others' tests with the new compiler.
> While that could be viewed as a good change for invalid code
> that's exercised at run time, it could also break programs
> where the bad code is never exercised.
>
> As I understand the schedule, the release is expected sometime
> in early April. I leave on April 2 for a week, so I have only
> until then. I don't think that leaves enough time. I'd be
> uncomfortable taking on a project this late in the cycle that
> could put the release in jeopardy, or that I might have to
> rely on others to finish up.
Since I've also spent some time on this: my take on this is that the C++ FE
should just follow C FE's suit and reject such initializations where
possible; it seems they've never worked reliably anyway, and bring more
harm than good. I don't see that rejecting such code would cause too much
trouble, if any, although the timing could be better.
Marek
Re: [PATCH] omp-offload.c: translation fixes (PR translation/80001)
On 03/14/2017 07:04 PM, David Malcolm wrote: Successfully bootstrapped®rtested on x86_64-pc-linux-gnu. OK for trunk? (either now in stage 4, or for next stage1?) gcc/ChangeLog: PR translation/80001 * omp-offload.c (oacc_loop_fixed_partitions): Make diagnostics more amenable to translation. (oacc_loop_auto_partitions): Likewise. I'm going to mentally classify this as a doc fix, even though it slightly twiddles code. OK for the trunk. jeff
Re: [PATCH v2] Fix PR79908
On Mar 21, 2017, at 10:18 AM, Christophe Lyon wrote: > > Since this was committed (r246319), I've noticed that > GCC cross-compiler fails to build glibc for target aarch64-linux-gnu. > > I'm seeing: > In function '_IO_vfscanf_internal': > cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:5627 > 0x8ae5bf gimplify_modify_expr > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:5627 > 0x8902b4 gimplify_expr(tree_node**, gimple**, gimple**, bool > (*)(tree_node*), int) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11198 > 0x8963c8 gimplify_stmt(tree_node**, gimple**) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 > 0x89bf55 gimplify_cond_expr > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3971 > 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool > (*)(tree_node*), int) >/tmp/1882393_6.tmpdir/aci-In function '_IO_vfscanf_internal': > cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:5627 > 0x8ae5bf gimplify_modify_expr > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:5627 > 0x8902b4 gimplify_expr(tree_node**, gimple**, gimple**, bool > (*)(tree_node*), int) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11198 > 0x8963c8 gimplify_stmt(tree_node**, gimple**) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 > 0x89bf55 gimplify_cond_expr > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3971 > 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool > (*)(tree_node*), int) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 > 0x8963c8 gimplify_stmt(tree_node**, gimple**) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 > 0x89b803 gimplify_cond_expr > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3864 > 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool > (*)(tree_node*), int) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 > 0x89328f gimplify_expr(tree_node**, gimple**, gimple**, bool > (*)(tree_node*), int) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11356 > 0x8b49f9 force_gimple_operand_1(tree_node*, gimple**, bool > (*)(tree_node*), tree_node*) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify-me.c:78 > 0xda0f16 expand_ifn_va_arg_1 > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1064 > 0xda0f16 expand_ifn_va_arg > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1105 > 0xda494b execute > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1158 > gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 > 0x8963c8 gimplify_stmt(tree_node**, gimple**) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 > 0x89b803 gimplify_cond_expr > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3864 > 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool > (*)(tree_node*), int) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 > 0x89328f gimplify_expr(tree_node**, gimple**, gimple**, bool > (*)(tree_node*), int) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11356 > 0x8b49f9 force_gimple_operand_1(tree_node*, gimple**, bool > (*)(tree_node*), tree_node*) > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify-me.c:78 > 0xda0f16 expand_ifn_va_arg_1 > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1064 > 0xda0f16 expand_ifn_va_arg > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1105 > 0xda494b execute > > /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1158 > > > I can start a manual build if you need a .i file. Yes, please! Please open a PR for tracking and CC me (wschm...@gcc.gnu.org); I'll investigate. Bill > > Thanks, > > Christophe > >> Thanks, >> Richard. >> >>> Thanks, >>> Bill >>> >>> >>> [gcc] >>> >>> 2017-03-20 Bill Schmidt >>>Richard Biener >>> >>>PR tree-optimization/79908 >>>* tree-stdarg.c (expand_ifn_va_arg_1): For a VA_ARG whose LHS has >>>been cast away, use force_gimple_operand to construct the side >>>effects. >>> >>> [gcc/testsuite] >>> >>> 2017-03-20 Bill Schmidt >>>Richard Biener >>> >>>PR tree-optimization/79908 >>>* gcc.dg/torture/pr79908.c: New file. >>> >>> >>> Index: gcc/testsuite/gcc.dg/torture/pr79908.c >>> =
Re: [PATCH 1/3] Error message on target attribute on power target (PR target/79906)
On Mon, Mar 13, 2017 at 09:23:51AM +0100, marxin wrote: > gcc/ChangeLog: > > 2017-03-13 Martin Liska > > PR target/79906 > * config/rs6000/rs6000.c (rs6000_inner_target_options): Show > error message instead of an ICE. > > gcc/testsuite/ChangeLog: > > 2017-03-13 Martin Liska > > PR target/79906 > * g++.dg/ext/mv8.C: Add power* targets. Okay, thanks! Segher
Re: [PATCH v2] Fix PR79908
On 21 March 2017 at 16:54, Bill Schmidt wrote: > On Mar 21, 2017, at 10:18 AM, Christophe Lyon > wrote: >> >> Since this was committed (r246319), I've noticed that >> GCC cross-compiler fails to build glibc for target aarch64-linux-gnu. >> >> I'm seeing: >> In function '_IO_vfscanf_internal': >> cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:5627 >> 0x8ae5bf gimplify_modify_expr >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:5627 >> 0x8902b4 gimplify_expr(tree_node**, gimple**, gimple**, bool >> (*)(tree_node*), int) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11198 >> 0x8963c8 gimplify_stmt(tree_node**, gimple**) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 >> 0x89bf55 gimplify_cond_expr >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3971 >> 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool >> (*)(tree_node*), int) >>/tmp/1882393_6.tmpdir/aci-In function '_IO_vfscanf_internal': >> cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:5627 >> 0x8ae5bf gimplify_modify_expr >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:5627 >> 0x8902b4 gimplify_expr(tree_node**, gimple**, gimple**, bool >> (*)(tree_node*), int) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11198 >> 0x8963c8 gimplify_stmt(tree_node**, gimple**) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 >> 0x89bf55 gimplify_cond_expr >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3971 >> 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool >> (*)(tree_node*), int) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 >> 0x8963c8 gimplify_stmt(tree_node**, gimple**) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 >> 0x89b803 gimplify_cond_expr >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3864 >> 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool >> (*)(tree_node*), int) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 >> 0x89328f gimplify_expr(tree_node**, gimple**, gimple**, bool >> (*)(tree_node*), int) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11356 >> 0x8b49f9 force_gimple_operand_1(tree_node*, gimple**, bool >> (*)(tree_node*), tree_node*) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify-me.c:78 >> 0xda0f16 expand_ifn_va_arg_1 >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1064 >> 0xda0f16 expand_ifn_va_arg >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1105 >> 0xda494b execute >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1158 >> gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 >> 0x8963c8 gimplify_stmt(tree_node**, gimple**) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:6477 >> 0x89b803 gimplify_cond_expr >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:3864 >> 0x890273 gimplify_expr(tree_node**, gimple**, gimple**, bool >> (*)(tree_node*), int) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11154 >> 0x89328f gimplify_expr(tree_node**, gimple**, gimple**, bool >> (*)(tree_node*), int) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify.c:11356 >> 0x8b49f9 force_gimple_operand_1(tree_node*, gimple**, bool >> (*)(tree_node*), tree_node*) >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gimplify-me.c:78 >> 0xda0f16 expand_ifn_va_arg_1 >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1064 >> 0xda0f16 expand_ifn_va_arg >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1105 >> 0xda494b execute >> >> /tmp/1882393_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1158 >> >> >> I can start a manual build if you need a .i file. > > Yes, please! Please open a PR for tracking and CC me (wschm...@gcc.gnu.org); > I'll investigate. > OK, I've filed PR 80136. Thanks, Christophe > Bill > >> >> Thanks, >> >> Christophe >> >>> Thanks, >>> Richard. >>> Thanks, Bill [gcc] 2017-03-20 Bill Schmidt Richard Biener PR tree-optimization/79908 * tree-stdarg.c (expand_ifn_va_arg_1): For a VA_ARG whose LHS has been cast away, use force_gimple_operand to construct the side effects. [gcc/testsuite] 2017-03-20 Bill S
Re: [PATCH v3, doc] Revise GCC manual section 6.11, Additional Floating Types
On Sun, 19 Mar 2017, Bill Schmidt wrote: > On Fri, 2017-03-17 at 21:44 +, Joseph Myers wrote: > > On Fri, 17 Mar 2017, Bill Schmidt wrote: > > > > > Joseph, any further comments, or may I commit this? > > > > Is there a current patch version somewhere reflecting all comments so far? > > > The previous version had one comment against it, to remove "64-bit" from > the discussion of PowerPC Linux targets. > > Here's a new patch with that resolved. > > Thanks, > Bill > > 2017-03-19 Bill Schmidt > > * doc/extend.texi (6.11 Additional Floating Types): Revise. This patch is OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Don't cross-jump in between frame related and non-frame related insns (PR target/80102, take 2)
On Tue, Mar 21, 2017 at 08:41:43AM +0100, Jakub Jelinek wrote: > On Tue, Mar 21, 2017 at 08:38:20AM +1000, Richard Henderson wrote: > > On 03/21/2017 07:15 AM, Jakub Jelinek wrote: > > > Not really sure what we should do if both i1 and i2 are frame related, > > > shall > > > we check for each of the CFA reg notes if they are available and equal? > > > Or punt if either of the insns is frame related? > > > > I would punt if either is frame related. > > Ok, I'll test then the following patch and gather some statistic on how > often we trigger this. The statistics I've gathered unfortunately shows that at least on powerpc64le-linux it is very important to not give up if both i1 and i2 are frame related and have rtx_equal_p notes. I've set on unpatched old_insns_match_p flags when returning non-dir_none and checked those flags in the various callers of these when about to successfully perform cross-jumping, head-merging etc. With /f vs. non-/f, the only 3 hits were on the new pr80102.C testcase during powerpc64le-linux bootstrap/regtest, but /f vs. /f there were 167601 hits. Jakub
[PR c++/80091] GCC 6 ICE with generic lambda
This patch fixes a gcc 6. In gcc 6 we see an IDENTIFIER for functions
(some) member fns that really resolve at parse time. We resolve them to
the same thing at instantiation time, so users don't see a problem.
Current GCC is cleaned up, so we see the actual decls when we need to.
(and if we do defer to instantiation time we can't then find a member
fn, which could change what we thought at parse time).
This fix is applied to gcc 6, and causes this capture when we see a raw
identifier in this case.
trunk requires no such patch, but I'll put the testcase there.
nathan
--
Nathan Sidwell
2017-03-20 Nathan Sidwell
PR c++/80091
* lambda.c (maybe_generic_this_capture): Capture when fn
is an identifier node.
Index: cp/lambda.c
===
--- cp/lambda.c (revision 246279)
+++ cp/lambda.c (working copy)
@@ -809,8 +809,9 @@ maybe_generic_this_capture (tree object,
{
tree fn = OVL_CURRENT (fns);
- if ((!id_expr || TREE_CODE (fn) == TEMPLATE_DECL)
- && DECL_NONSTATIC_MEMBER_FUNCTION_P (fn))
+ if (identifier_p (fns)
+ || ((!id_expr || TREE_CODE (fn) == TEMPLATE_DECL)
+ && DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)))
{
/* Found a non-static member. Capture this. */
lambda_expr_this_capture (lam, true);
Index: testsuite/g++.dg/cpp0x/pr80091.C
===
--- testsuite/g++.dg/cpp0x/pr80091.C (nonexistent)
+++ testsuite/g++.dg/cpp0x/pr80091.C (working copy)
@@ -0,0 +1,12 @@
+// { dg-do compile { target c++11 } }
+
+// PR 80091 ICE with member fn call from lambda in template
+
+struct A {
+ void m_fn1();
+};
+template struct B : A {
+ void m_fn2() {
+[&] { m_fn1(); };
+ }
+};
[PATCH][PR target/80123][7 regression] new constraint wA to prevent r0 use in mtvsrdd
Both the fails in 80123 are a situation where vsx_splat_ for V2DI
generates rtl for a mtvsrdd but constraint wr doesn't prevent
allocation of r0 for the input. So new constraint wA combines the
attributes of wr and b -- it is BASE_REGS if 64-bit and NO_REGS
otherwise.
Currently doing bootstrap/regtest on 64-bit LE and BE, and also BE 32-
bit. OK for trunk if everything passes?
2017-03-21 Aaron Sawdey
PR target/80123
* doc/md.texi (Constraints): Document wA constraint.
* config/rs6000/constraints.md (wA): New.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Add wA reg_class.
(rs6000_init_hard_regno_mode_ok): Init wA constraint.
* config/rs6000/rs6000.h (RS6000_CONSTRAINT_wA): New.
* config/rs6000/vsx.md (vsx_splat_): Use wA constraint.
--
Aaron Sawdey, Ph.D. acsaw...@linux.vnet.ibm.com
050-2/C113 (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC ToolchainIndex: gcc/config/rs6000/constraints.md
===
--- gcc/config/rs6000/constraints.md (revision 246295)
+++ gcc/config/rs6000/constraints.md (working copy)
@@ -133,6 +133,9 @@
(define_register_constraint "wz" "rs6000_constraints[RS6000_CONSTRAINT_wz]"
"Floating point register if the LFIWZX instruction is enabled or NO_REGS.")
+(define_register_constraint "wA" "rs6000_constraints[RS6000_CONSTRAINT_wA]"
+ "BASE_REGS if 64-bit instructions are enabled or NO_REGS.")
+
;; wB needs ISA 2.07 VUPKHSW
(define_constraint "wB"
"Signed 5-bit constant integer that can be loaded into an altivec register."
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 246295)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -2468,6 +2468,7 @@
"wx reg_class = %s\n"
"wy reg_class = %s\n"
"wz reg_class = %s\n"
+ "wA reg_class = %s\n"
"wH reg_class = %s\n"
"wI reg_class = %s\n"
"wJ reg_class = %s\n"
@@ -2500,6 +2501,7 @@
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wx]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wy]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wz]],
+ reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wA]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wH]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wI]],
reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wJ]],
@@ -3210,7 +3212,10 @@
}
if (TARGET_POWERPC64)
-rs6000_constraints[RS6000_CONSTRAINT_wr] = GENERAL_REGS;
+{
+ rs6000_constraints[RS6000_CONSTRAINT_wr] = GENERAL_REGS;
+ rs6000_constraints[RS6000_CONSTRAINT_wA] = BASE_REGS;
+}
if (TARGET_P8_VECTOR && TARGET_UPPER_REGS_SF) /* SFmode */
{
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h (revision 246295)
+++ gcc/config/rs6000/rs6000.h (working copy)
@@ -1612,6 +1612,7 @@
RS6000_CONSTRAINT_wx, /* FPR register for STFIWX */
RS6000_CONSTRAINT_wy, /* VSX register for SF */
RS6000_CONSTRAINT_wz, /* FPR register for LFIWZX */
+ RS6000_CONSTRAINT_wA, /* BASE_REGS if 64-bit. */
RS6000_CONSTRAINT_wH, /* Altivec register for 32-bit integers. */
RS6000_CONSTRAINT_wI, /* VSX register for 32-bit integers. */
RS6000_CONSTRAINT_wJ, /* VSX register for 8/16-bit integers. */
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md (revision 246295)
+++ gcc/config/rs6000/vsx.md (working copy)
@@ -3072,7 +3072,7 @@
"=,,we,")
(vec_duplicate:VSX_D
(match_operand: 1 "splat_input_operand"
- ",Z,b, wr")))]
+ ",Z,b, wA")))]
"VECTOR_MEM_VSX_P (mode)"
"@
xxpermdi %x0,%x1,%x1,0
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 246295)
+++ gcc/doc/md.texi (working copy)
@@ -3122,6 +3122,9 @@
@item wz
Floating point register if the LFIWZX instruction is enabled or NO_REGS.
+@item wA
+Address base register if 64-bit instructions are enabled or NO_REGS.
+
@item wB
Signed 5-bit constant integer that can be loaded into an altivec register.
Trunk patches required for gcc-6-branch to build for msp430
r244727 and r243310 from the gcc trunk are needed in the gcc-6-branch to build gcc for the msp430 target with C and C++ support. Would it be possible for these patches to be backported to the gcc-6-branch? The gcc-5-branch builds for msp430 with C and C++ support, so isn't this technically a regression?
Re: [PATCH][PR target/80123][7 regression] new constraint wA to prevent r0 use in mtvsrdd
On Tue, Mar 21, 2017 at 12:57:43PM -0500, Aaron Sawdey wrote: > Both the fails in 80123 are a situation where vsx_splat_ for V2DI > generates rtl for a mtvsrdd but constraint wr doesn't prevent > allocation of r0 for the input. So new constraint wA combines the > attributes of wr and b -- it is BASE_REGS if 64-bit and NO_REGS > otherwise. > > Currently doing bootstrap/regtest on 64-bit LE and BE, and also BE 32- > bit. OK for trunk if everything passes? Okay. Thanks, Segher > PR target/80123 > * doc/md.texi (Constraints): Document wA constraint. > * config/rs6000/constraints.md (wA): New. > * config/rs6000/rs6000.c (rs6000_debug_reg_global): Add wA reg_class. > (rs6000_init_hard_regno_mode_ok): Init wA constraint. > * config/rs6000/rs6000.h (RS6000_CONSTRAINT_wA): New. > * config/rs6000/vsx.md (vsx_splat_): Use wA constraint.
Re: install.texi and sparc-*-linux*
On Mär 21 2017, Gerald Pfeifer wrote:
> On Sun, 19 Mar 2017, Andreas Schwab wrote:
>>> @anchor{sparc-x-linux}
>>> @heading sparc-*-linux*
>> The section is now empty. Should it be removed at all?
>
> I considered that, but then figured we do want to keep this as
> an indicator this is a supported platform (and also placeholder
> if/when any new items worth documenting appear).
There should probably at least be a short description of the target,
like it is present for all other targets without specific instructions.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [PR59319] output friends in debug info
On Jan 27, 2017, Alexandre Oliva wrote: > On Oct 19, 2016, Alexandre Oliva wrote: >> On Sep 23, 2016, Alexandre Oliva wrote: >>> On Aug 30, 2016, Alexandre Oliva wrote: Handling non-template friends is kind of easy, [...] >>> Regstrapped on x86_64-linux-gnu and i686-linux-gnu, I'd failed to >>> mention. >>> Ping? >> Ping? (conflicts resolved, patch refreshed and retested) > Ping? (trivial conflicts resolved) Ping? https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02112.html > Handling non-template friends is kind of easy, but it required a bit > of infrastructure in dwarf2out to avoid (i) forcing debug info for > unused types or functions: DW_TAG_friend DIEs are only emitted if > their DW_AT_friend DIE is emitted, and (ii) creating DIEs for such > types or functions just to have them discarded at the end. To this > end, I introduced a list (vec, actually) of types with friends, > processed at the end of the translation unit, and a list of > DW_TAG_friend DIEs that, when we're pruning unused types, reference > DIEs that are still not known to be used, revisited after we finish > deciding all other DIEs, so that we prune DIEs that would have > referenced pruned types or functions. > Handling template friends turned out to be trickier: there's no > representation in DWARF for templates. I decided to give debuggers as > much information as possible, enumerating all specializations of > friend templates and outputting DW_TAG_friend DIEs referencing them as > well. I considered marking those as DW_AT_artificial, to indicate > they're not explicitly stated in the source code, but in the end we > decided that was not useful. The greatest challenge was to enumerate > all specializations of a template. It looked trivial at first, given > DECL_TEMPLATE_INSTANTIATIONS, but it won't list specializations of > class-scoped functions and of nested templates. For other templates, > I ended up writing code to look for specializations in the hashtables > of decl or type specializations. That's not exactly efficient, but it > gets the job done. > for gcc/ChangeLog > PR debug/59319 > * dwarf2out.c (class_types_with_friends): New. > (gen_friend_tags_for_type, gen_friend_tags): New. > (gen_member_die): Record class types with friends. > (deferred_marks): New. > (prune_unused_types_defer_undecided_mark_p): New. > (prune_unused_types_defer_mark): New. > (prune_unused_types_deferred_walk): New. > (prune_unused_types_walk): Defer DW_TAG_friend. > (prune_unused_types): Check deferred marks is empty on entry, > empty it after processing. > (dwarf2out_finish): Generate friend tags. > (dwarf2out_early_finish): Likewise. > * langhooks-def.h (LANG_HOOKS_GET_FRIENDS): New. > (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add it. > * langhooks.h (lang_hooks_for_types): Add get_friends. > * hooks.c (hook_tree_const_tree_int_null): New. > * hooks.h (hook_tree_const_tree_int_null): Declare. > for gcc/cp/ChangeLog > PR debug/59319 > * cp-objcp-common.c (cp_get_friends): New. > * cp-objcp-common.h (cp_get_friends): Declare. > (LANG_HOOKS_GET_FRIENDS): Override. > * cp-tree.h (enumerate_friend_specializations): Declare. > * pt.c (optimize_friend_specialization_lookup_p): New. > (retrieve_friend_specialization): New. > (enumerate_friend_specializations): New. > (register_specialization): Update DECL_TEMPLATE_INSTANTIATIONS > for functions, even after definition, if we are emitting debug > info. > for gcc/testsuite/ChangeLog > PR debug/59319 > * g++.dg/debug/dwarf2/friend-1.C: New. > * g++.dg/debug/dwarf2/friend-2.C: New. > * g++.dg/debug/dwarf2/friend-3.C: New. > * g++.dg/debug/dwarf2/friend-4.C: New. > * g++.dg/debug/dwarf2/friend-5.C: New. > * g++.dg/debug/dwarf2/friend-6.C: New. > * g++.dg/debug/dwarf2/friend-7.C: New. > * g++.dg/debug/dwarf2/friend-8.C: New. > * g++.dg/debug/dwarf2/friend-9.C: New. > * g++.dg/debug/dwarf2/friend-10.C: New. > * g++.dg/debug/dwarf2/friend-11.C: New. > * g++.dg/debug/dwarf2/friend-12.C: New. > * g++.dg/debug/dwarf2/friend-13.C: New. > * g++.dg/debug/dwarf2/friend-14.C: New. > * g++.dg/debug/dwarf2/friend-15.C: New. > * g++.dg/debug/dwarf2/friend-16.C: New. > * g++.dg/debug/dwarf2/friend-17.C: New. > * g++.dg/debug/dwarf2/friend-18.C: New. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).
Martin, Richard, I've read up on the thread, but I'm not sure where you guys are with an actual patch. From what I Richard nailed it in BZ with the comment that the BB should not be associated with any source line. That's a new thing, so I think the gcov format needs extending (at least). gcov must associate every BB with source line, so that it can present data to users. That's a conflict with the above observation. I don't understand why gcov does NOT think the line is executed when -a is not used: -: 29: /* Following line falsely marked as covered when parameter "--rc lcov_branch_coverage=1" is set */ #: 30:ReturnStatus_t = 0; At least one block associated with line 30 is executed. Why's it not being counted? But that does seem to be the right output -- we shouldn't count this 'artificial' block. So then the question morphs into the -a case: 1: 30:ReturnStatus_t = 0; $: 30-block 0 1: 30-block 1 We do count the artificial block. Which is inconsistent. Sorry, at this point I'm lost as to what is being suggested as a solution. nathan -- Nathan Sidwell
Re: [PATCH] restore -Wunused-variable on a typedef'd variable in a function template (PR 79548)
On 03/20/2017 03:11 PM, Jason Merrill wrote:
On Thu, Feb 23, 2017 at 6:33 PM, Jason Merrill wrote:
On Thu, Feb 23, 2017 at 12:56 PM, Martin Sebor wrote:
On 02/22/2017 05:43 PM, Jason Merrill wrote:
On Wed, Feb 22, 2017 at 3:44 PM, Martin Sebor wrote:
On 02/22/2017 11:02 AM, Jason Merrill wrote:
The TREE_USED bit on the type (i.e., on
TREE_TYPE(decl) where decl is the u in the test case above) is
set when the function template is instantiated, in
set_underlying_type called from tsubst_decl.
Aha! That seems like the problem. Does removing that copy of
TREE_USED from the decl to the type break anything?
As far as I can see it breaks just gcc.dg/unused-3.c which is:
typedef short unused_type __attribute__ ((unused));
void f (void)
{
unused_type y;
}
Ah. So the problem here is that we're using TREE_USED on a TYPE_DECL
for two things: to track whether the typedef has been used, and to
determine whether to treat a variable of that type as already used.
Normally this isn't too much of a problem because we copy the
TREE_USED flag from decl to type before there could be any uses, but
in a template I guess we mark the typedef within the template when it
is used, and then when we instantiate the typedef we incorrectly pass
that mark along to the type.
Your patch deals with this by ignoring TREE_USED on the type, so it
doesn't matter that it's wrong. Another approach would be to correct
the setting of TREE_USED by setting it based on looking up the unused
attribute, rather than copying it from the TYPE_DECL. So also going
back to the attribute, but in set_underlying_type rather than
poplevel.
Thoughts?
I'm not 100% sure I understand what changes you're suggesting
but the attached patch does what I think you're after. Is that
what you had in mind?
Martin
PR c++/79548 - missing -Wunused-variable on a typedef'd variable in a function template
gcc/c-family/ChangeLog:
PR c++/79548
* c-common.c (set_underlying_type): Mark type used only when
original del is declared unused.
gcc/testsuite/ChangeLog:
PR c++/79548
* g++.dg/warn/Wunused-var-26.C: New test.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 885ea6d..65ffd8c 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -7476,7 +7476,12 @@ set_underlying_type (tree x)
tt = build_variant_type_copy (tt);
TYPE_STUB_DECL (tt) = TYPE_STUB_DECL (DECL_ORIGINAL_TYPE (x));
TYPE_NAME (tt) = x;
- TREE_USED (tt) = TREE_USED (x);
+
+ /* Mark the type as used only when its type decl is decorated
+ with attribute unused. */
+ if (lookup_attribute ("unused", DECL_ATTRIBUTES (x)))
+ TREE_USED (tt) = 1;
+
TREE_TYPE (x) = tt;
}
}
diff --git a/gcc/testsuite/g++.dg/warn/Wunused-var-26.C b/gcc/testsuite/g++.dg/warn/Wunused-var-26.C
new file mode 100644
index 000..b3e020b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wunused-var-26.C
@@ -0,0 +1,147 @@
+// PR c++/79548 - missing -Wunused-variable on a typedef'd variable
+// in a function template
+// { dg-do compile }
+// { dg-options "-Wunused" }
+
+
+#define UNUSED __attribute__ ((unused))
+
+template
+void f_int ()
+{
+ T t;// { dg-warning "unused variable" }
+
+ typedef T U;
+ U u;// { dg-warning "unused variable" }
+}
+
+template void f_int();
+
+
+template
+void f_intptr ()
+{
+ T *t = 0; // { dg-warning "unused variable" }
+
+ typedef T U;
+ U *u = 0; // { dg-warning "unused variable" }
+}
+
+template void f_intptr();
+
+
+template
+void f_var_unused ()
+{
+ // The variable is marked unused.
+ T t UNUSED;
+
+ typedef T U;
+ U u UNUSED;
+}
+
+template void f_var_unused();
+
+
+template
+void f_var_type_unused ()
+{
+ // The variable's type is marked unused.
+ T* UNUSED t = new T; // { dg-bogus "unused variable" "bug 79585" { xfail *-*-* } }
+
+ typedef T U;
+ U* UNUSED u = new U; // { dg-bogus "unused variable" "bug 79585" { xfail *-*-* } }
+
+ typedef T UNUSED U;
+ U v = U (); // { dg-bogus "unused variable" "bug 79585" }
+}
+
+template void f_var_type_unused();
+
+
+struct A { int i; };
+
+template
+void f_A ()
+{
+ T t;// { dg-warning "unused variable" }
+
+ typedef T U;
+ U u;// { dg-warning "unused variable" }
+}
+
+template void f_A();
+
+
+template
+void f_A_unused ()
+{
+ T t UNUSED;
+
+ typedef T U;
+ U u UNUSED;
+}
+
+template void f_A_unused();
+
+
+struct B { B (); };
+
+template
+void f_B ()
+{
+ T t;
+
+ typedef T U;
+ U u;
+}
+
+template void f_B();
+
+
+struct NonTrivialDtor { ~NonTrivialDtor (); };
+
+template
+void f_with_NonTrivialDtor ()
+{
+ // Expect no warnings when instantiated on a type with a non-trivial
+ // destructor.
+ T t;
+
+ typedef T U;
+ U u;
+}
+
+template void f_with_NonTrivialDtor();
+
+
+struct D { NonTrivialDtor b; };
+
+template
+void f_D ()
+{
+ // Same as f_with_NonTrivialDtor but wi
C++ PATCH for c++/77563, missing ambiguous conversion error
This conversion is ambiguous because of its implicit context; when we
try to give the error, we need to preserve that context; a conversion
in the context of direct-initialization shouldn't get here anyway.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d7be189d5b2761f10f9c9a8de4c17d3e4d761abf
Author: Jason Merrill
Date: Tue Mar 21 12:26:51 2017 -0400
PR c++/77563 - missing ambiguous conversion error.
* call.c (convert_like_real): Use LOOKUP_IMPLICIT.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 86c7647..803fbd4 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6764,7 +6764,7 @@ convert_like_real (conversion *convs, tree expr, tree fn,
int argnum,
if (complain & tf_error)
{
/* Call build_user_type_conversion again for the error. */
- build_user_type_conversion (totype, convs->u.expr, LOOKUP_NORMAL,
+ build_user_type_conversion (totype, convs->u.expr, LOOKUP_IMPLICIT,
complain);
if (fn)
inform (DECL_SOURCE_LOCATION (fn),
diff --git a/gcc/testsuite/g++.dg/overload/ambig3.C
b/gcc/testsuite/g++.dg/overload/ambig3.C
new file mode 100644
index 000..01d4cc6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/overload/ambig3.C
@@ -0,0 +1,15 @@
+// PR c++/77563
+
+struct A {
+ A(int) {}
+ A(unsigned) {} // Comment to make it work
+
+ explicit A(long) {} // Comment to make it work
+};
+
+void f(A) { }
+
+int main() {
+ f(2);
+ f(3l); // { dg-error "ambiguous" }
+}
Re: C++ PATCH to fix bogus maybe-uninitialized warning (PR c++/80119)
OK.
On Tue, Mar 21, 2017 at 11:38 AM, Marek Polacek wrote:
> This patch fixes a bogus maybe-uninitialized warning reported in the PR.
> The issue is that we're not able to fold away useless CLEANUP_POINT_EXPRs,
> as e.g. in
> if (<>)
>// bogus warning
> Here, the cleanup_point was built as <>,
> which cp_fold_r reduces to <>, but leaves it as that and
> passes it to the gimplifier.
>
> Jakub suggested handling this in cp_fold. fold_build_cleanup_point_expr says
> that "if the expression does not have side effects then we don't have to wrap
> it with a cleanup point expression", so I think the following should be safe.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2017-03-21 Marek Polacek
>
> PR c++/80119
> * cp-gimplify.c (cp_fold): Strip CLEANUP_POINT_EXPR if the expression
> doesn't have side effects.
>
> * g++.dg/warn/Wuninitialized-9.C: New test.
>
> diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
> index ebb5da9..b4319ca 100644
> --- gcc/cp/cp-gimplify.c
> +++ gcc/cp/cp-gimplify.c
> @@ -2056,6 +2056,14 @@ cp_fold (tree x)
>code = TREE_CODE (x);
>switch (code)
> {
> +case CLEANUP_POINT_EXPR:
> + /* Strip CLEANUP_POINT_EXPR if the expression doesn't have side
> +effects. */
> + r = cp_fold (TREE_OPERAND (x, 0));
> + if (!TREE_SIDE_EFFECTS (r))
> + x = r;
> + break;
> +
> case SIZEOF_EXPR:
>x = fold_sizeof_expr (x);
>break;
> diff --git gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
> gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
> index e69de29..3432b4f 100644
> --- gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
> +++ gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
> @@ -0,0 +1,19 @@
> +// PR c++/80119
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-Wuninitialized" }
> +
> +#include
> +
> +template
> +void failing_function(std::integral_constant)
> +{
> + int i;
> + if (b && (i = 4)) {
> + ++i; // { dg-bogus "may be used uninitialized" }
> + }
> +}
> +
> +int main (void)
> +{
> + failing_function(std::false_type());
> +}
>
> Marek
Re: [PATCH] restore -Wunused-variable on a typedef'd variable in a function template (PR 79548)
On Tue, Mar 21, 2017 at 2:40 PM, Martin Sebor wrote:
> On 03/20/2017 03:11 PM, Jason Merrill wrote:
>>
>> On Thu, Feb 23, 2017 at 6:33 PM, Jason Merrill wrote:
>>>
>>> On Thu, Feb 23, 2017 at 12:56 PM, Martin Sebor wrote:
On 02/22/2017 05:43 PM, Jason Merrill wrote:
>
> On Wed, Feb 22, 2017 at 3:44 PM, Martin Sebor wrote:
>>
>> On 02/22/2017 11:02 AM, Jason Merrill wrote:
>>>
>>>
>> The TREE_USED bit on the type (i.e., on
>> TREE_TYPE(decl) where decl is the u in the test case above) is
>> set when the function template is instantiated, in
>> set_underlying_type called from tsubst_decl.
>
>
> Aha! That seems like the problem. Does removing that copy of
> TREE_USED from the decl to the type break anything?
As far as I can see it breaks just gcc.dg/unused-3.c which is:
typedef short unused_type __attribute__ ((unused));
void f (void)
{
unused_type y;
}
>>>
>>>
>>> Ah. So the problem here is that we're using TREE_USED on a TYPE_DECL
>>> for two things: to track whether the typedef has been used, and to
>>> determine whether to treat a variable of that type as already used.
>>> Normally this isn't too much of a problem because we copy the
>>> TREE_USED flag from decl to type before there could be any uses, but
>>> in a template I guess we mark the typedef within the template when it
>>> is used, and then when we instantiate the typedef we incorrectly pass
>>> that mark along to the type.
>>>
>>> Your patch deals with this by ignoring TREE_USED on the type, so it
>>> doesn't matter that it's wrong. Another approach would be to correct
>>> the setting of TREE_USED by setting it based on looking up the unused
>>> attribute, rather than copying it from the TYPE_DECL. So also going
>>> back to the attribute, but in set_underlying_type rather than
>>> poplevel.
>>
>> Thoughts?
>
> I'm not 100% sure I understand what changes you're suggesting
> but the attached patch does what I think you're after. Is that
> what you had in mind?
Looks good.
Jason
Re: [PATCH] have chkp skip flexible member arrays (PR #79986)
On Tue, Mar 21, 2017 at 11:08 AM, Martin Sebor wrote:
> On 03/20/2017 10:27 PM, Jason Merrill wrote:
>>
>> On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor wrote:
>>>
>>> On 03/20/2017 05:51 PM, Jason Merrill wrote:
On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
>
>
> Attached is a minimal patch to avoid an ICE in CHKP upon
> encountering one form of an initializer for a flexible array
> member, specifically the empty string:
>
> int f ()
> {
> struct B { int n; char a[]; };
>
> return ((struct B){ 1, "" }).a[0];
> }
>
> Although GCC accepts (and doesn't ICE on) non-empty initializers
> for flexible array members, such as
>
> (struct B){ 1, "123" }
How do you mean? When I compile this with the C front end, I get
error: non-static initialization of a flexible array member
>>>
>>> I meant that G++ accepts it, doesn't ICE, but emits wrong code.
>>> (it's consistently rejected by the C front end). Sorry for not
>>> being clear about it.
>>
>> Ah, OK. It seems to me that the wrong code bug is worth addressing;
>> why does rejecting the code seem risky to you?
>
> I have a few reasons: First, it's not a regression (I raised
> bug 69696 for it in early 2016) so strictly it's out of scope
> for this stage. Second, there are a number of bugs related
> to the initialization of flexible array members so the fixes
> are probably not going to be contained to a single function
> or file. Third, the flexible member array changes I made in
> the past were not trivial, took time to develop, and the two
> of us iterated over some of them for weeks. Despite your
> careful review and my extensive testing some of them
> introduced regressions that are still being patched up.
> Fourth, making a change to reject code this close to a release
> runs the risk of breaking code that has successfully compiled
> in mass rebuilds and others' tests with the new compiler.
> While that could be viewed as a good change for invalid code
> that's exercised at run time, it could also break programs
> where the bad code is never exercised.
Fair enough. But I think the ICE is preferable to wrong code.
Jason
Re: C++ PATCH to fix bogus maybe-uninitialized warning (PR c++/80119)
On Tue, Mar 21, 2017 at 03:27:02PM -0400, Jason Merrill wrote:
> OK.
>
> On Tue, Mar 21, 2017 at 11:38 AM, Marek Polacek wrote:
> > This patch fixes a bogus maybe-uninitialized warning reported in the PR.
> > The issue is that we're not able to fold away useless CLEANUP_POINT_EXPRs,
> > as e.g. in
> > if (<>)
> >// bogus warning
> > Here, the cleanup_point was built as <>,
> > which cp_fold_r reduces to <>, but leaves it as that and
> > passes it to the gimplifier.
> >
> > Jakub suggested handling this in cp_fold. fold_build_cleanup_point_expr
> > says
> > that "if the expression does not have side effects then we don't have to
> > wrap
> > it with a cleanup point expression", so I think the following should be
> > safe.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > 2017-03-21 Marek Polacek
> >
> > PR c++/80119
> > * cp-gimplify.c (cp_fold): Strip CLEANUP_POINT_EXPR if the
> > expression
> > doesn't have side effects.
> >
> > * g++.dg/warn/Wuninitialized-9.C: New test.
> >
> > diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
> > index ebb5da9..b4319ca 100644
> > --- gcc/cp/cp-gimplify.c
> > +++ gcc/cp/cp-gimplify.c
> > @@ -2056,6 +2056,14 @@ cp_fold (tree x)
> >code = TREE_CODE (x);
> >switch (code)
> > {
> > +case CLEANUP_POINT_EXPR:
> > + /* Strip CLEANUP_POINT_EXPR if the expression doesn't have side
> > +effects. */
> > + r = cp_fold (TREE_OPERAND (x, 0));
Can CLEANUP_POINT_EXPR be an lvalue? If not, maybe cp_fold_rvalue instead?
> > + if (!TREE_SIDE_EFFECTS (r))
> > + x = r;
> > + break;
> > +
Jakub
[PATCH] Don't cross-jump in between frame related and non-frame related insns (PR target/80102, take 3)
On Tue, Mar 21, 2017 at 06:53:34PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 21, 2017 at 08:41:43AM +0100, Jakub Jelinek wrote:
> > On Tue, Mar 21, 2017 at 08:38:20AM +1000, Richard Henderson wrote:
> > > On 03/21/2017 07:15 AM, Jakub Jelinek wrote:
> > > > Not really sure what we should do if both i1 and i2 are frame related,
> > > > shall
> > > > we check for each of the CFA reg notes if they are available and equal?
> > > > Or punt if either of the insns is frame related?
> > >
> > > I would punt if either is frame related.
> >
> > Ok, I'll test then the following patch and gather some statistic on how
> > often we trigger this.
>
> The statistics I've gathered unfortunately shows that at least on
> powerpc64le-linux it is very important to not give up if both i1 and i2
> are frame related and have rtx_equal_p notes.
> I've set on unpatched old_insns_match_p flags when returning non-dir_none
> and checked those flags in the various callers of these when about to
> successfully perform cross-jumping, head-merging etc.
> With /f vs. non-/f, the only 3 hits were on the new pr80102.C testcase
> during powerpc64le-linux bootstrap/regtest, but /f vs. /f there were
> 167601 hits.
Here is updated patch which allows cross-jumping of RTX_FRAME_RELATED_P
insns, as long as they have the same CFA related notes on them (same order
if more than one).
Bootstrapped/regtested on powerpc64le-linux, ok for trunk?
2017-03-21 Jakub Jelinek
PR target/80102
* cfgcleanup.c (old_insns_match_p): Don't cross-jump in between /f
and non-/f instructions. If both i1 and i2 are frame related,
verify all CFA notes, their order and content.
* g++.dg/opt/pr80102.C: New test.
--- gcc/cfgcleanup.c.jj 2017-03-21 07:56:55.711233924 +0100
+++ gcc/cfgcleanup.c2017-03-21 19:20:40.517746664 +0100
@@ -1149,6 +1149,11 @@ old_insns_match_p (int mode ATTRIBUTE_UN
else if (p1 || p2)
return dir_none;
+ /* Do not allow cross-jumping between frame related insns and other
+ insns. */
+ if (RTX_FRAME_RELATED_P (i1) != RTX_FRAME_RELATED_P (i2))
+return dir_none;
+
p1 = PATTERN (i1);
p2 = PATTERN (i2);
@@ -1207,6 +1212,58 @@ old_insns_match_p (int mode ATTRIBUTE_UN
}
}
+ /* If both i1 and i2 are frame related, verify all the CFA notes
+ in the same order and with the same content. */
+ if (RTX_FRAME_RELATED_P (i1))
+{
+ static enum reg_note cfa_note_kinds[] = {
+ REG_FRAME_RELATED_EXPR, REG_CFA_DEF_CFA, REG_CFA_ADJUST_CFA,
+ REG_CFA_OFFSET, REG_CFA_REGISTER, REG_CFA_EXPRESSION,
+ REG_CFA_VAL_EXPRESSION, REG_CFA_RESTORE, REG_CFA_SET_VDRAP,
+ REG_CFA_TOGGLE_RA_MANGLE, REG_CFA_WINDOW_SAVE, REG_CFA_FLUSH_QUEUE
+ };
+ rtx n1 = REG_NOTES (i1);
+ rtx n2 = REG_NOTES (i2);
+ unsigned int i;
+ do
+ {
+ /* Skip over reg notes not related to CFI information. */
+ while (n1)
+ {
+ for (i = 0; i < ARRAY_SIZE (cfa_note_kinds); i++)
+ if (REG_NOTE_KIND (n1) == cfa_note_kinds[i])
+ break;
+ if (i != ARRAY_SIZE (cfa_note_kinds))
+ break;
+ n1 = XEXP (n1, 1);
+ }
+ while (n2)
+ {
+ for (i = 0; i < ARRAY_SIZE (cfa_note_kinds); i++)
+ if (REG_NOTE_KIND (n2) == cfa_note_kinds[i])
+ break;
+ if (i != ARRAY_SIZE (cfa_note_kinds))
+ break;
+ n2 = XEXP (n2, 1);
+ }
+ if (n1 == NULL_RTX && n2 == NULL_RTX)
+ break;
+ if (n1 == NULL_RTX || n2 == NULL_RTX)
+ return dir_none;
+ if (XEXP (n1, 0) == XEXP (n2, 0))
+ ;
+ else if (XEXP (n1, 0) == NULL_RTX || XEXP (n2, 0) == NULL_RTX)
+ return dir_none;
+ else if (!(reload_completed
+? rtx_renumbered_equal_p (XEXP (n1, 0), XEXP (n2, 0))
+: rtx_equal_p (XEXP (n1, 0), XEXP (n2, 0
+ return dir_none;
+ n1 = XEXP (n1, 1);
+ n2 = XEXP (n2, 1);
+ }
+ while (1);
+}
+
#ifdef STACK_REGS
/* If cross_jump_death_matters is not 0, the insn's mode
indicates whether or not the insn contains any stack-like
--- gcc/testsuite/g++.dg/opt/pr80102.C.jj 2017-03-21 18:56:30.256698365
+0100
+++ gcc/testsuite/g++.dg/opt/pr80102.C 2017-03-21 18:56:30.256698365 +0100
@@ -0,0 +1,14 @@
+// PR target/80102
+// { dg-do compile }
+// { dg-options "-fnon-call-exceptions -Os" }
+// { dg-additional-options "-mminimal-toc" { target { powerpc*-*-* && lp64 } }
}
+
+struct B { float a; B (float c) { for (int g; g < c;) ++a; } };
+struct D { D (B); };
+
+int
+main ()
+{
+ B (1.0);
+ D e (0.0), f (1.0);
+}
Jakub
[PATCH] Fix gimplification of const var initialization from COND_EXPR (PR c++/80129)
Hi!
For non-gimple reg types var = x ? y : z; is gimplified as
x ? (var = y) : (var = z);. The problem is that if var is TREE_READONLY,
we can gimplify one of those assignments by promoting them to TREE_STATIC
(if not addressable) and making the initializer into their DECL_INITIAL.
That doesn't work well, because then we conditionally store into that and
during optimizations, as it is a TREE_READONLY var with DECL_INITIAL, just
use that initializer for optimizations.
The following patch fixes that by clearing TREE_READONLY flag if we are
going to store it more than once.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-03-21 Jakub Jelinek
PR c++/80129
* gimplify.c (gimplify_modify_expr_rhs) : Clear
TREE_READONLY on result if writing it more than once.
* g++.dg/torture/pr80129.C: New test.
--- gcc/gimplify.c.jj 2017-03-21 07:56:55.0 +0100
+++ gcc/gimplify.c 2017-03-21 13:37:45.555612652 +0100
@@ -5098,6 +5098,13 @@ gimplify_modify_expr_rhs (tree *expr_p,
if (ret != GS_ERROR)
ret = GS_OK;
+ /* If we are going to write RESULT more than once, clear
+TREE_READONLY flag, otherwise we might gimplify it
+incorrectly. */
+ if (DECL_P (result)
+ && TREE_TYPE (TREE_OPERAND (cond, 1)) != void_type_node
+ && TREE_TYPE (TREE_OPERAND (cond, 2)) != void_type_node)
+ TREE_READONLY (result) = 0;
if (TREE_TYPE (TREE_OPERAND (cond, 1)) != void_type_node)
TREE_OPERAND (cond, 1)
= build2 (code, void_type_node, result,
--- gcc/testsuite/g++.dg/torture/pr80129.C.jj 2017-03-21 13:40:04.179852313
+0100
+++ gcc/testsuite/g++.dg/torture/pr80129.C 2017-03-21 13:41:32.121735570
+0100
@@ -0,0 +1,14 @@
+// PR c++/80129
+// { dg-do run }
+// { dg-options "-std=c++11" }
+
+struct A { bool a; int b; };
+
+int
+main ()
+{
+ bool c = false;
+ const A x = c ? A {true, 1} : A {false, 0};
+ if (x.a)
+__builtin_abort ();
+}
Jakub
Re: [PATCH] Implement LWG 2686, hash
2017-03-12 13:16 GMT+01:00 Daniel Krügler : > The following is an *untested* patch suggestion, please verify. > > Notes: My interpretation is that hash should be > defined outside of the _GLIBCXX_COMPATIBILITY_CXX0X block, please > double-check that course of action. > > I noticed that the preexisting hash did directly refer to > the private members of error_code albeit those have public access > functions. For consistency I mimicked that existing style when > implementing hash. > > - Daniel I would just point out that I'm on vacations from Friday on for two weeks, so if any changes to this patch are requested, I will work on them after my return. Thanks, - Daniel
Re: [Patch] Inline Variables for the Standard Library (p0607r0)
2017-03-12 1:04 GMT+01:00 Daniel Krügler : > 2017-03-11 23:14 GMT+01:00 Daniel Krügler : >> 2017-03-11 23:09 GMT+01:00 Tim Song : >>> On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler >>> wrote: 2017-03-11 21:23 GMT+01:00 Tim Song : > On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler > wrote: >> This patch applies inline to all namespace scope const variables >> according to options A and B2 voted in during the Kona meeting, see: >> >> http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html >> >> During that work it has been found that std::ignore was not declared >> constexpr (http://cplusplus.github.io/LWG/lwg-defects.html#2773), >> which was fixed as well. > > Just adding constexpr to std::ignore does ~nothing. The assignment > operator needs to be made constexpr too; there is really no other > reason to use std::ignore. There is nothing in the resolution of the issue (Nor in the discussion that argues for the change) that says so. Yes, I considered to make the assignment function template constexpr, but decided against it, because the wording of the issue doesn't have this requirement). I'm also aware of a test-case which would show the difference, but again: This was not what the issue said. In fact I'm in the process to open a new library issue that should impose that additional requirement. - Daniel >>> >>> Well, technically speaking, the issue resolution doesn't even >>> guarantee that the use case mentioned in the issue would compile since >>> the standard says nothing about whether the copy constructor of >>> decltype(std::ignore) is constexpr, or even whether it can be copied >>> at all. Yes, std::ignore is underspecified, but I'm not sure I see the >>> point in waiting; it's a completely conforming change and IMHO the >>> issue's intent is clearly to make std::ignore fully usable in >>> constexpr functions. >>> >>> Also, the only specification we have for std::ignore's semantics is >>> "when an argument in t is ignore, assigning any value to the >>> corresponding tuple element has no effect". I think one can argue that >>> "causes an expression to be non-constant" is an "effect". >>> >>> Re "new library issue", we already have issue 2933. >> >> Good point, it already exists ;-) > > Revised patch attached. I would just like to point out that I'm on vacation from Friday on for two weeks, so if any changes to this patch are requested, I will work on them after my return. Thanks, - Daniel
Re: C++ PATCH to fix bogus maybe-uninitialized warning (PR c++/80119)
On Tue, Mar 21, 2017 at 08:41:01PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 21, 2017 at 03:27:02PM -0400, Jason Merrill wrote:
> > OK.
> >
> > On Tue, Mar 21, 2017 at 11:38 AM, Marek Polacek wrote:
> > > This patch fixes a bogus maybe-uninitialized warning reported in the PR.
> > > The issue is that we're not able to fold away useless CLEANUP_POINT_EXPRs,
> > > as e.g. in
> > > if (<>)
> > >// bogus warning
> > > Here, the cleanup_point was built as <>,
> > > which cp_fold_r reduces to <>, but leaves it as that and
> > > passes it to the gimplifier.
> > >
> > > Jakub suggested handling this in cp_fold. fold_build_cleanup_point_expr
> > > says
> > > that "if the expression does not have side effects then we don't have to
> > > wrap
> > > it with a cleanup point expression", so I think the following should be
> > > safe.
> > >
> > > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > >
> > > 2017-03-21 Marek Polacek
> > >
> > > PR c++/80119
> > > * cp-gimplify.c (cp_fold): Strip CLEANUP_POINT_EXPR if the
> > > expression
> > > doesn't have side effects.
> > >
> > > * g++.dg/warn/Wuninitialized-9.C: New test.
> > >
> > > diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
> > > index ebb5da9..b4319ca 100644
> > > --- gcc/cp/cp-gimplify.c
> > > +++ gcc/cp/cp-gimplify.c
> > > @@ -2056,6 +2056,14 @@ cp_fold (tree x)
> > >code = TREE_CODE (x);
> > >switch (code)
> > > {
> > > +case CLEANUP_POINT_EXPR:
> > > + /* Strip CLEANUP_POINT_EXPR if the expression doesn't have side
> > > +effects. */
> > > + r = cp_fold (TREE_OPERAND (x, 0));
>
> Can CLEANUP_POINT_EXPR be an lvalue? If not, maybe cp_fold_rvalue instead?
I ran the testing with some lvalue_p checks added and it seems a
CLEANUP_POINT_EXPR
is never an lvalue, so I guess we can call cp_fold_rvalue. Jason, is this still
ok?
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2017-03-21 Marek Polacek
PR c++/80119
* cp-gimplify.c (cp_fold): Strip CLEANUP_POINT_EXPR if the expression
doesn't have side effects.
* g++.dg/warn/Wuninitialized-9.C: New test.
diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
index ebb5da9..b4319ca 100644
--- gcc/cp/cp-gimplify.c
+++ gcc/cp/cp-gimplify.c
@@ -2056,6 +2056,14 @@ cp_fold (tree x)
code = TREE_CODE (x);
switch (code)
{
+case CLEANUP_POINT_EXPR:
+ /* Strip CLEANUP_POINT_EXPR if the expression doesn't have side
+effects. */
+ r = cp_fold_rvalue (TREE_OPERAND (x, 0));
+ if (!TREE_SIDE_EFFECTS (r))
+ x = r;
+ break;
+
case SIZEOF_EXPR:
x = fold_sizeof_expr (x);
break;
diff --git gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
index e69de29..3432b4f 100644
--- gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
+++ gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
@@ -0,0 +1,19 @@
+// PR c++/80119
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wuninitialized" }
+
+#include
+
+template
+void failing_function(std::integral_constant)
+{
+ int i;
+ if (b && (i = 4)) {
+ ++i; // { dg-bogus "may be used uninitialized" }
+ }
+}
+
+int main (void)
+{
+ failing_function(std::false_type());
+}
Marek
Re: [PATCH] restore -Wunused-variable on a typedef'd variable in a function template (PR 79548)
I'm not 100% sure I understand what changes you're suggesting but the attached patch does what I think you're after. Is that what you had in mind? Looks good. Thanks. I just committed it to trunk but forgot to ask for approval to backport it to 6 and 5. Martin
[PR80025] avoid cselib rtx_equal infinite recursion on XOR
When two VALUEs are recorded in the cselib equivalence table such that
they are equivalent to each other XORed with the same expression, if
we started a cselib equivalence test between say the odd one and the
even one, we'd end up recursing to compare the even one with the odd
one, and then again, indefinitely.
This patch cuts off this infinite recursion by recognizing the XOR
special case (it's the only binary commutative operation in which
applying one of the operands of an operation to the result of that
operation brings you back to the other operand) and determining
whether we have an equivalence without recursing down the infinite
path.
I know Bernd and Jakub may look further into this issue, trying to stop
the cycle in cselib structures from forming to begin with, but I
unexpectedly managed to complete a test cycle of this before taking off
for a one-week trip (anyone else going to be at LibrePlanet?), so I'm
posting it for consideration, and so that there's at least a workaround
on the archives.
FWIW, I do believe the patch is the right fix, and that the cycle in the
data structures is not something to be avoided, since it reflects the
equivalences in the code. However, if there's a general agreement that
the presence of the cycle is not useful (or even that it's harmful), and
someone finds a good way to avoid it, I won't stand in the way ;-)
Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install?
for gcc/ChangeLog
* cselib.c (rtx_equal_for_cselib_1): Avoid infinite recursion
on XOR.
for gcc/testsuite/ChangeLog
* gcc.dg/torture/pr80025.c: New.
---
gcc/cselib.c | 24
gcc/testsuite/gcc.dg/torture/pr80025.c | 26 ++
2 files changed, 50 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/torture/pr80025.c
diff --git a/gcc/cselib.c b/gcc/cselib.c
index a621f0d..83c2e45 100644
--- a/gcc/cselib.c
+++ b/gcc/cselib.c
@@ -955,6 +955,30 @@ rtx_equal_for_cselib_1 (rtx x, rtx y, machine_mode memmode)
using this MEM's mode. */
return rtx_equal_for_cselib_1 (XEXP (x, 0), XEXP (y, 0), GET_MODE (x));
+case XOR:
+ /* Catch cases in which we might recurse indefinitely because
+two XORs with the same value cancel out, yielding the
+original value. In some circumstances, we might find
+ourselves attempting to expand one operand of both XORs and
+comparing again, which is just another way of commuting the
+compare, and if we were to then expand again, we'd be back at
+square one. It's safe to compare for equality here, because
+if this is the case we're interested in, we'll have taken the
+rtxes from equivalence lists. Besides, we couldn't use
+rtx_equal_for_cselib_1 instead: that might just turn a case
+in which the present call would yield an equality into an
+infinite recursion at this point! */
+ if (XEXP (x, 0) == y)
+ return rtx_equal_for_cselib_1 (XEXP (x, 1), const0_rtx, GET_MODE (x));
+ else if (XEXP (x, 1) == y)
+ return rtx_equal_for_cselib_1 (XEXP (x, 0), const0_rtx, GET_MODE (x));
+ else if (XEXP (y, 0) == x)
+ return rtx_equal_for_cselib_1 (XEXP (y, 1), const0_rtx, GET_MODE (x));
+ else if (XEXP (y, 1) == x)
+ return rtx_equal_for_cselib_1 (XEXP (y, 0), const0_rtx, GET_MODE (x));
+ else
+ break;
+
default:
break;
}
diff --git a/gcc/testsuite/gcc.dg/torture/pr80025.c
b/gcc/testsuite/gcc.dg/torture/pr80025.c
new file mode 100644
index 000..e6a3b04d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr80025.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-g -w -ftracer" } */
+
+int kq;
+long int cs, l3;
+
+long int
+gn (void)
+{
+}
+
+void
+yc (int un, short int z6, unsigned short int il)
+{
+ (void)un;
+ (void)z6;
+ (void)il;
+}
+
+int
+w6 (void)
+{
+ kq -= cs;
+ cs = !gn ();
+ yc (cs ^= (l3 ^ 1) ? (l3 ^ 1) : gn (), &yc, kq);
+}
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
[libcp1] handle anon aggregates linkage-named by typedefs
GDB has had a work-around that uses the typedef name as the name of an
anonymous class, struct or union, when introducing them through libcc1's
C++ API. It didn't do that for enums, that remained anonymous, and GCC
warned about using types without linkage as members of types with
linkage, which enabled us to catch the shortcoming in libcc1.
Now GDB can introduce all anonymous aggregate types without a name, and
then introduce their names through typedefs, so as to get the expected
language behavior for typedef-named anonymous types.
Ok to install? Regression-tested with GDB's gdb.compile tests in the
users/pmuldoon/c++compile branch.
Arrange for the first typedef to an anonymous type in the same context
to be used as the linkage name for the type.
for libcc1/ChangeLog
* libcp1plugin.cc (plugin_build_decl): Propagate typedef name to
anonymous aggregate target type.
---
libcc1/libcp1plugin.cc | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libcc1/libcp1plugin.cc b/libcc1/libcp1plugin.cc
index 545f28b9..bc448a7 100644
--- a/libcc1/libcp1plugin.cc
+++ b/libcc1/libcp1plugin.cc
@@ -1494,6 +1494,25 @@ plugin_build_decl (cc1_plugin::connection *self,
set_access_flags (decl, acc_flags);
+ /* If this is the typedef that names an otherwise anonymous type,
+ propagate the typedef name to the type. In normal compilation,
+ this is done in grokdeclarator. */
+ if (sym_kind == GCC_CP_SYMBOL_TYPEDEF
+ && !template_decl_p
+ && DECL_CONTEXT (decl) == TYPE_CONTEXT (sym_type)
+ && TYPE_UNNAMED_P (sym_type))
+{
+ for (tree t = TYPE_MAIN_VARIANT (sym_type); t; t = TYPE_NEXT_VARIANT (t))
+ if (anon_aggrname_p (TYPE_IDENTIFIER (t)))
+ TYPE_NAME (t) = decl;
+ if (TYPE_LANG_SPECIFIC (sym_type))
+ TYPE_WAS_UNNAMED (sym_type) = 1;
+ if (TYPE_LANG_SPECIFIC (sym_type) && CLASSTYPE_TEMPLATE_INFO (sym_type))
+ DECL_NAME (CLASSTYPE_TI_TEMPLATE (sym_type))
+ = TYPE_IDENTIFIER (sym_type);
+ reset_type_linkage (sym_type);
+}
+
if (sym_kind != GCC_CP_SYMBOL_TYPEDEF
&& sym_kind != GCC_CP_SYMBOL_CLASS
&& sym_kind != GCC_CP_SYMBOL_UNION
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [PATCH] have chkp skip flexible member arrays (PR #79986)
Since I've also spent some time on this: my take on this is that the C++ FE
should just follow C FE's suit and reject such initializations where
possible; it seems they've never worked reliably anyway, and bring more
harm than good. I don't see that rejecting such code would cause too much
trouble, if any, although the timing could be better.
Schedule concerns aside, and although I agree that rejecting such
code is far preferable to generating buggy programs, I'm not sure
that rejecting auto initialization of flexible array members will
ultimately lead to the best results. Users who want to initialize
local objects with flexible array members will find some other
(likely convoluted) way that GCC may not be able to find bugs in.
A possible solution for those who can't or don't want to use
std::array might be something like this:
void f ()
{
struct S { size_t n; int a[]; };
S *ps = (S*)alloca (sizeof (S) + 5);
ps->n = 5;
memcpy (ps->a, (const int[]){ 1, 2, 3, 4, 5 }, sizeof *ps->a * 5);
...
}
but that's clearly error-prone and hard to diagnose. GCC has
no mechanism to detect bugs in this code without optimization,
and because it folds the memcpy into a bunch of assignments,
-Wstringop-overflow doesn't detect buffer overflows in the
call to the function.
I think it would be better to get the initialization to work so
that users don't have to jump through hoops and can instead write
cleaner code that more readily lends itself to checking for bugs.
It might be even worth proposing local initialization as
an enhancement for C2X.
Martin
[patch, libgfortran] PR78881 [F03] reading from string with DTIO procedure does not work properly
Hi all,
The attached patch is part 1 of a 2 part patch. This part fixes a few problems
with handling of advance= and EOR conditions. This does not resolve the
original case in the PR but gets some issues out of the way so I can continue.
The most notable change is that per standard, child I/O is by definition
non-advancing and any advance= specifier is ignored. We still do the typical
error checks for on the advance= and give errors when not valid to specify it,
but where it is valid, we just ignore it as stated in the standard (set it to
non-advancing regardless).
"A formatted child input/output statement is a nonadvancing input/output
statement, and any ADVANCE= specifier is ignored." 9.6.2.4
Regarding the original test case, note that if I use a format specifier of
'(DT)' instead of *, the test case works as expected. So, evidently with list
directed I/O we are eating the first character for some reason. I will keep
working on this issue.
In the meantime, the attached patch and test cases, regression tested on
x86_64-linux.
OK for trunk?
Jerry
2017-03-21 Jerry DeLisle
PR libgfortran/78881
* io/transfer.c (read_sf_internal): Add a new check for EOR
condition. (data_transfer_init): If child dtio, set advance
status to nonadvancing. Move update of size and check for EOR
condition to before child dtio return.
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index fc22d802..30a8a0c4 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -226,7 +226,7 @@ static char *
read_sf_internal (st_parameter_dt *dtp, int * length)
{
static char *empty_string[0];
- char *base;
+ char *base = NULL;
int lorig;
/* Zero size array gives internal unit len of 0. Nothing to read. */
@@ -263,6 +263,12 @@ read_sf_internal (st_parameter_dt *dtp, int * length)
return NULL;
}
+ if (base && *base == 0)
+{
+ generate_error (&dtp->common, LIBERROR_EOR, NULL);
+ return NULL;
+}
+
dtp->u.p.current_unit->bytes_left -= *length;
if (((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0) ||
@@ -2856,6 +2862,11 @@ data_transfer_init (st_parameter_dt *dtp, int read_flag)
}
}
+ /* Child IO is non-advancing and any ADVANCE= specifier is ignored.
+ F2008 9.6.2.4 */
+ if (dtp->u.p.current_unit->child_dtio > 0)
+dtp->u.p.advance_status = ADVANCE_NO;
+
if (read_flag)
{
dtp->u.p.current_unit->previous_nonadvancing_write = 0;
@@ -3856,6 +3867,15 @@ finalize_transfer (st_parameter_dt *dtp)
namelist_write (dtp);
}
+ if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)
+*dtp->size = dtp->u.p.current_unit->size_used;
+
+ if (dtp->u.p.eor_condition)
+{
+ generate_error (&dtp->common, LIBERROR_EOR, NULL);
+ goto done;
+}
+
if (dtp->u.p.current_unit && (dtp->u.p.current_unit->child_dtio > 0))
{
if (cf & IOPARM_DT_HAS_FORMAT)
@@ -3866,15 +3886,6 @@ finalize_transfer (st_parameter_dt *dtp)
return;
}
- if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)
-*dtp->size = dtp->u.p.current_unit->size_used;
-
- if (dtp->u.p.eor_condition)
-{
- generate_error (&dtp->common, LIBERROR_EOR, NULL);
- goto done;
-}
-
if ((dtp->common.flags & IOPARM_LIBRETURN_MASK) != IOPARM_LIBRETURN_OK)
{
if (dtp->u.p.current_unit && current_mode (dtp) == UNFORMATTED_SEQUENTIAL)
! { dg-do run }
! PR78881 test for correct end ofrecord condition and ignoring advance=
module t_m
use, intrinsic :: iso_fortran_env, only : iostat_end, iostat_eor, output_unit
implicit none
type, public :: t
character(len=:), allocatable :: m_s
contains
procedure, pass(this) :: read_t
generic :: read(formatted) => read_t
end type t
contains
subroutine read_t(this, lun, iotype, vlist, istat, imsg)
class(t), intent(inout) :: this
integer, intent(in) :: lun
character(len=*), intent(in):: iotype
integer, intent(in) :: vlist(:)
integer, intent(out):: istat
character(len=*), intent(inout) :: imsg
character(len=1) :: c
integer :: i
i = 0 ; imsg=''
loop_read: do
i = i + 1
read( unit=lun, fmt='(a1)', iostat=istat, iomsg=imsg) c
select case ( istat )
case ( 0 )
if (i.eq.1 .and. c.ne.'h') exit loop_read
!write( output_unit, fmt=sfmt) "i = ", i, ", c = ", c
case ( iostat_end )
!write( output_unit, fmt=sfmt) "i = ", i, ", istat = iostat_end"
exit loop_read
case ( iostat_eor )
!write( output_unit, fmt=sfmt) "i = ", i, ", istat = iostat_eor"
exit loop_read
case default
!write( output_unit, fmt=sfmt) "i = ", i, ", istat = ", istat
exit loop_read
end select
if (i.gt.10) exit loop_read
end do loop_read
end subroutine read_t
end module t_m
program p
use t_m, only : t
implicit none
character(len=:), allocatable :: s
type(t) :: foo
character(len=25
