[Patch, libgomp, committed] F2015 fix for testsuite/libgomp.fortran/pr34020.f90 (was: [Patch, Fortran] Add library support for coarray's atomic intrinsics)
Dominique Dhumieres wrote: This probably caused /opt/gcc/work/libgomp/testsuite/libgomp.fortran/pr34020.f90:16.24: call atomic_add(lhs, rhs) 1 Error: ATOM argument at (1) to intrinsic function atomic_add shall be an integer of ATOMIC_INT_KIND I have fixed the issue by using external - alternatively, one could compile it with -std=f2008 as it is new in the post-Fortran-2008 Technical Specification (TS) 18508 (and will be in Fortran 2015). Committed as Rev. 212490. Tobias Index: libgomp/ChangeLog === --- libgomp/ChangeLog (Revision 212489) +++ libgomp/ChangeLog (Arbeitskopie) @@ -1,3 +1,8 @@ +2014-07-13 Tobias Burnus bur...@net-b.de + + * testsuite/libgomp.fortran/pr34020.f90: Make compile + with TS 18508/Fortran 2015 + 2014-07-06 Marek Polacek pola...@redhat.com PR c/6940 Index: libgomp/testsuite/libgomp.fortran/pr34020.f90 === --- libgomp/testsuite/libgomp.fortran/pr34020.f90 (Revision 212489) +++ libgomp/testsuite/libgomp.fortran/pr34020.f90 (Arbeitskopie) @@ -7,6 +7,7 @@ lhs = rhs + lhs end + external atomic_add real lhs, rhs integer i lhs = 0
Re: [PATCH] offline gcda profile processing tool
Rong Xu x...@google.com writes: In my test, I used gcc-4.6 as the host compiler. I got warning like this: In file included from ../../gcc/gcc/../libgcc/libgcov-util.c:30:0: ../../gcc/gcc/../libgcc/libgcov.h:184:30: warning: ISO C++ forbids zero-size array ‘ctrs’ [-pedantic] With gcc 4.3 this is an error, so -Wno-error has no effect. 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: [Patch, Fortran] Update atomics support for TS18508
The test gfortran.dg/coarray_atomic_4.f90 fails in 32 bit mode: /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray_atomic_4.f90:40.32: call atomic_fetch_and(caf, 22_16, var, stat=stat) 1 Error: Integer kind 16 at (1) not available Dominique
Re: [Patch, Fortran] Update atomics support for TS18508
call atomic_fetch_and(caf, 22_16, var, stat=stat) 1 Error: Integer kind 16 at (1) not available FAIL: gfortran.dg/coarray_atomic_4.f90 -O (test for excess errors) 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.
[committed] Fix testcase (was: Re: [Patch, Fortran] Update atomics support for TS18508)
Dominique Dhumieres wrote: The test gfortran.dg/coarray_atomic_4.f90 fails in 32 bit mode: /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray_atomic_4.f90:40.32: call atomic_fetch_and(caf, 22_16, var, stat=stat) 1 Error: Integer kind 16 at (1) not available As I just want to test whether values of a different kind work, hence, any value but _4 would work. I've now changed it to a kind=1 integer. Committed as Rev. 212491. Tobias Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (Revision 212490) +++ gcc/testsuite/ChangeLog (Arbeitskopie) @@ -1,3 +1,8 @@ +2014-07-13 Tobias Burnus bur...@net-b.de + + * gfortran.dg/coarray_atomic_4.f90: Avoid using a kind=16 + integer. + 2014-07-12 Paul Thomas pa...@gcc.gnu.org PR fortran/61780 Index: gcc/testsuite/gfortran.dg/coarray_atomic_4.f90 === --- gcc/testsuite/gfortran.dg/coarray_atomic_4.f90 (Revision 212490) +++ gcc/testsuite/gfortran.dg/coarray_atomic_4.f90 (Arbeitskopie) @@ -37,7 +37,7 @@ call atomic_or(caf, 101, stat=stat) call atomic_xor(caf, 105_2, stat=stat) call atomic_fetch_add(caf, var3, var, stat=stat) -call atomic_fetch_and(caf, 22_16, var, stat=stat) +call atomic_fetch_and(caf, 22_1, var, stat=stat) call atomic_fetch_or(caf, var3, var, stat=stat) call atomic_fetch_xor(caf, 47_2, var, stat=stat)
Re: [PATCH] libstdc++: add uniform on sphere distribution
Hi,
On 07/13/2014 04:00 AM, Ulrich Drepper wrote:
+ templatestd::size_t _Dimen, typename _RealType, typename _CharT,
+ typename _Traits
+std::basic_ostream_CharT, _Traits
+operator(std::basic_ostream_CharT, _Traits __os,
+ const __gnu_cxx::uniform_on_sphere_distribution_Dimen,
+ _RealType __x)
+{
+ return __os;
+}
+
+ templatestd::size_t _Dimen, typename _RealType, typename _CharT,
+ typename _Traits
+std::basic_istream_CharT, _Traits
+operator(std::basic_istream_CharT, _Traits __is,
+ __gnu_cxx::uniform_on_sphere_distribution_Dimen,
+_RealType __x)
+{
+ return __is;
+}
are these dummy implementations intended?
Thanks,
Paolo.
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sun, Jul 13, 2014 at 5:24 AM, Paolo Carlini paolo.carl...@oracle.com wrote: are these dummy implementations intended? Yes. There is no state. The only parameter is the dimensionality which is a template parameter.
Re: [GSoC] generation of Gimple loops with empty bodies
Hi Dominique, thank you for the message! I've attached a patch, that may fix the issue. Please report back if it fixes the problem. -- Cheers, Roman Gareev. Index: gcc/graphite-isl-ast-to-gimple.c === --- gcc/graphite-isl-ast-to-gimple.c(revision 212491) +++ gcc/graphite-isl-ast-to-gimple.c(working copy) @@ -65,7 +65,9 @@ /* We always use signed 128, until isl is able to give information about types */ -static tree *graphite_expression_size_type = int128_integer_type_node; +static tree *graphite_expression_size_type = int128_integer_type_node ? +int128_integer_type_node : +long_long_integer_type_node; /* Converts a GMP constant VAL to a tree and returns it. */
Re: [PATCH] libstdc++: add uniform on sphere distribution
Hi, On 07/13/2014 12:04 PM, Ulrich Drepper wrote: On Sun, Jul 13, 2014 at 5:24 AM, Paolo Carlini paolo.carl...@oracle.com wrote: are these dummy implementations intended? Yes. There is no state. The only parameter is the dimensionality which is a template parameter. Ah, interesting, didn't look close enough, sorry. Maybe add a one line comment in the bodies? Patch is Ok. Thanks! Paolo.
Re: -fuse-caller-save - Collect register usage information
On 19-06-14 21:45, Richard Henderson wrote:
On 06/19/2014 12:36 PM, Jan Hubicka wrote:
On 06/19/2014 09:06 AM, Tom de Vries wrote:
2014-06-19 Tom de Vries t...@codesourcery.com
* final.c (collect_fn_hard_reg_usage): Don't save function_used_regs if
it contains all call_used_regs.
Ok.
When we now have way to represent different reg usages for functions, what
would be best
way to make local functions to default into saving some SSE registers on
x86/x86-64?
I wouldn't do that at all. Leave all sse registers call-clobbered. This way
you don't need to have different entry points (or one possibly less efficient
entry point) when a function is used both locally and globally.
What I would investigate is how to use this hard reg usage data in the register
allocator. If we know that the callee only uses xmm0-xmm4, then we can keep
xmm5-xmm15 live across the call.
AFAIU, what you describe here already works. This patch contains a version of
the fuse-caller-save test with xmm registers. The callee bar only uses xmm0, and
caller foo keeps xmm1 live across the call.
OK for trunk?
Thanks,
- Tom
2014-07-13 Tom de Vries t...@codesourcery.com
* gcc.target/i386/fuse-caller-save-xmm-run.c: New test.
* gcc.target/i386/fuse-caller-save-xmm.c: New test.
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm-run.c b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm-run.c
new file mode 100644
index 000..17385fa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm-run.c
@@ -0,0 +1,34 @@
+/* { dg-do run } */
+/* { dg-options -O2 -msse -fuse-caller-save } */
+
+typedef double v2df __attribute__((vector_size (16)));
+
+static v2df __attribute__((noinline))
+bar (v2df a)
+{
+ return a + (v2df){ 3.0, 3.0 };
+}
+
+v2df __attribute__((noinline))
+foo (v2df y)
+{
+ return y + bar (y);
+}
+
+int
+main (void)
+{
+ int success;
+ union {
+v2df v;
+double d[2];
+ } u;
+
+ u.v = foo ((v2df){ 5.0, 5.0});
+ success = (u.d[0] == 13.0
+ u.d[1] == 13.0);
+
+ return !success;
+}
+
+
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
new file mode 100644
index 000..de1ca63
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -msse -fuse-caller-save } */
+
+typedef double v2df __attribute__((vector_size (16)));
+
+static v2df __attribute__((noinline))
+bar (v2df a)
+{
+ return a + (v2df){ 3.0, 3.0 };
+}
+
+v2df __attribute__((noinline))
+foo (v2df y)
+{
+ return y + bar (y);
+}
+
+int
+main (void)
+{
+ int success;
+ union {
+v2df v;
+double d[2];
+ } u;
+
+ u.v = foo ((v2df){ 5.0, 5.0});
+ success = (u.d[0] == 13.0
+ u.d[1] == 13.0);
+
+ return !success;
+}
+
+/* { dg-final { scan-assembler-not movaps\t%xmm1, \\(%rsp\\) } } */
+/* { dg-final { scan-assembler-not movapd\t\\(%rsp\\), %xmm1 } } */
+/* { dg-final { scan-assembler-times .cfi_def_cfa_offset 16 1 } } */
+/* { dg-final { scan-assembler-times .cfi_def_cfa_offset 32 1 } } */
+
Re: [GSoC] generation of Gimple code from isl_ast_node_user
On 12/07/2014 14:18, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_user.
I think that it would be better to add motivation for the following
line from the original source:
if (GBB_BB (gbb) == ENTRY_BLOCK_PTR_FOR_FN (cfun))
{
isl_ast_expr_free (user_expr);
return next_e;
}
Do you know anything about this?
No, no idea. To my understanding the entry block should not even appear
within a scop (see build_scops, where we only start detecting scops at
the successor of the entry_block). Maybe we replace this with an assert
to get a good error message in case I have missed something.
-/* IVS_PARAMS maps ISL's scattering and parameter identifiers
+/* TREE_FROM_ISL_ID maps ISL's scattering and parameter identifiers
to corresponding trees. */
-typedef std::mapisl_id *, tree ivs_params;
+typedef struct ivs_params {
+ std::mapisl_id *, tree tree_from_isl_id;
+ sese region;
I think this region is actually not needed. At the place where you need
it, you have a pbb available, from which you can obtain a pointer to the
surrounding scop and from this you can obtain this region itself.
+} *ivs_params_p;
case isl_ast_op_lt:
{
// (iterator ub) = (iterator = ub - 1)
-isl_val *one = isl_val_int_from_si (isl_ast_expr_get_ctx (for_cond),
1);
+isl_val *one =
+ isl_val_int_from_si (isl_ast_expr_get_ctx (for_cond), 1);
This is a pure style change which seems unrelated. Also, is the original
line really too long? I may have miscounted, but it seems to fit
exactly.
+/* Inserts in iv_map a tuple (OLD_LOOP-num, NEW_NAME) for the
+ induction variables of the loops around GBB in SESE. */
In polly we just create an iv_map from [0, max-loop-depth-within-scop], so
it contains at most as many elements as the maximal loop depth. Your map
is unnecessarily large, as it contains all loops in the function.
If we can avoid this immediately, e.g. by indexing according to the
loop-depths that would be great. On the other side, if the existing
functions require this, I propose to not touch this area, but to add a
fixme that documents this issue. We can solve it after having removed
the CLooG codegen.
+/* Mark BB with it's relevant PBB via hashing table BB_PBB_MAPPING. */
+
+static void
+mark_bb_with_pbb (poly_bb_p pbb, basic_block bb,
+ bb_pbb_htab_type *bb_pbb_mapping)
+{
+ bool existed;
+ poly_bb_p e = bb_pbb_mapping-get_or_insert (bb, existed);
+ if (!existed)
+e = pbb;
+}
I was just briefly looking the code to remind me what this
bb_pbb_mapping hash table is about, but could not find the reason it is
needed. Do you know why it is needed?
Is it necessary for this patch? Or did you just copy it from the
previous code generation?
+/* Translates an isl_ast_node_user to Gimple. */
+
+static edge
+translate_isl_ast_node_user (__isl_keep isl_ast_node *node,
+edge next_e, bb_pbb_htab_type *bb_pbb_mapping,
+ivs_params_p ip)
+{
+ gcc_assert (isl_ast_node_get_type (node) == isl_ast_node_user);
+ int i, nb_loops;
+ basic_block new_bb;
+ isl_ast_expr *user_expr = isl_ast_node_user_get_expr (node);
+ isl_ast_expr *name_expr = isl_ast_expr_get_op_arg (user_expr, 0);
+ gcc_assert (isl_ast_expr_get_type (name_expr) == isl_ast_expr_id);
+ isl_id *name_id = isl_ast_expr_get_id (name_expr);
+ poly_bb_p pbb = (poly_bb_p) isl_id_get_user (name_id);
+ gcc_assert (pbb);
+ gimple_bb_p gbb = PBB_BLACK_BOX (pbb);
+ vectree iv_map;
+ isl_ast_expr_free (name_expr);
+ isl_id_free (name_id);
+
+ if (GBB_BB (gbb) == ENTRY_BLOCK_PTR_FOR_FN (cfun))
+{
+ isl_ast_expr_free (user_expr);
+ return next_e;
+}
+
+ nb_loops = number_of_loops (cfun);
+ iv_map.create (nb_loops);
+ for (i = 0; i nb_loops; i++)
+iv_map.quick_push (NULL_TREE);
Why do you need to first push NULL_TREEs into this vec, which will be
overwritten right after?
+ build_iv_mapping (iv_map, gbb, user_expr, ip);
+ isl_ast_expr_free (user_expr);
+ next_e = copy_bb_and_scalar_dependences (GBB_BB (gbb), ip-region,
+ next_e, iv_map,
+ graphite_regenerate_error);
+ iv_map.release ();
+ new_bb = next_e-src;
+ mark_bb_with_pbb (pbb, new_bb, bb_pbb_mapping);
+ mark_virtual_operands_for_renaming (cfun);
+ update_ssa (TODO_update_ssa);
+ return next_e;
+}
+
It is unclear how this patches have been tested. Can you elaborate?
Also, we need to find a way to test this in gcc itself, possibly by
running test cases that already work with both the cloog and the isl ast
generator.
Cheers,
Tobias
[GSoC][match-and-simplify] Add DEBUG_FUNCTION attribute
This patch adds DEBUG_FUNCTION attribute to print_* functions
in genmatch.c
* genmatch.c (print_operand): Add attribute DEBUG_FUNCTION.
(print_matches): Likewise.
(decision_tree::print_node): Likewise.
(decision_tree::print): Likewise.
Thanks and Regards,
Prathamesh
Index: genmatch.c
===
--- genmatch.c (revision 212366)
+++ genmatch.c (working copy)
@@ -407,7 +407,7 @@ struct decision_tree
static void print_node (dt_node *, FILE *f = stderr, unsigned = 0);
};
-void
+DEBUG_FUNCTION void
print_operand (operand *o, FILE *f = stderr, bool flattened = false)
{
if (o-type == operand::OP_CAPTURE)
@@ -449,7 +449,7 @@ print_operand (operand *o, FILE *f = std
gcc_unreachable ();
}
-void
+DEBUG_FUNCTION void
print_matches (struct simplify *s, FILE *f = stderr)
{
if (s-matchers.length () == 1)
@@ -841,7 +841,7 @@ decision_tree::insert (struct simplify *
}
}
-void
+DEBUG_FUNCTION void
decision_tree::print_node (dt_node *p, FILE *f, unsigned indent)
{
if (p-type == dt_node::DT_NODE)
@@ -878,7 +878,7 @@ decision_tree::print_node (dt_node *p, F
}
-void
+DEBUG_FUNCTION void
decision_tree::print (FILE *f)
{
return decision_tree::print_node (root, f);
Re: [GSoC] generation of Gimple loops with empty bodies
Hi Roman, Thanks for the quick answer. Please report back if it fixes the problem. I have not yet done a full regtest, but a manual testing suggest that the patch fixes the problem. Dominique
Re: [GSoC] generation of Gimple loops with empty bodies
I have regtested graphite.exp for gcc/g++/gfortran/libgomp without regression. So your patch seems a safe fix. Dominique
Re: -fuse-caller-save - Collect register usage information
When we now have way to represent different reg usages for functions, what
would be best
way to make local functions to default into saving some SSE registers on
x86/x86-64?
I wouldn't do that at all. Leave all sse registers call-clobbered. This way
you don't need to have different entry points (or one possibly less efficient
entry point) when a function is used both locally and globally.
What I would investigate is how to use this hard reg usage data in the
register
allocator. If we know that the callee only uses xmm0-xmm4, then we can keep
xmm5-xmm15 live across the call.
What I was shooting for whas to
1) make it possible to declare by attribute that some registers are not call
clobbered
2) have more sane default when the call usage data are not available - either
because of LTO partitioning
or because the callee was not copmiled yet.
AFAIU, what you describe here already works. This patch contains a
version of the fuse-caller-save test with xmm registers. The callee
bar only uses xmm0, and caller foo keeps xmm1 live across the call.
OK for trunk?
Thanks,
- Tom
2014-07-13 Tom de Vries t...@codesourcery.com
* gcc.target/i386/fuse-caller-save-xmm-run.c: New test.
* gcc.target/i386/fuse-caller-save-xmm.c: New test.
OK
Honza
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm-run.c
b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm-run.c
new file mode 100644
index 000..17385fa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm-run.c
@@ -0,0 +1,34 @@
+/* { dg-do run } */
+/* { dg-options -O2 -msse -fuse-caller-save } */
+
+typedef double v2df __attribute__((vector_size (16)));
+
+static v2df __attribute__((noinline))
+bar (v2df a)
+{
+ return a + (v2df){ 3.0, 3.0 };
+}
+
+v2df __attribute__((noinline))
+foo (v2df y)
+{
+ return y + bar (y);
+}
+
+int
+main (void)
+{
+ int success;
+ union {
+v2df v;
+double d[2];
+ } u;
+
+ u.v = foo ((v2df){ 5.0, 5.0});
+ success = (u.d[0] == 13.0
+ u.d[1] == 13.0);
+
+ return !success;
+}
+
+
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
new file mode 100644
index 000..de1ca63
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -msse -fuse-caller-save } */
+
+typedef double v2df __attribute__((vector_size (16)));
+
+static v2df __attribute__((noinline))
+bar (v2df a)
+{
+ return a + (v2df){ 3.0, 3.0 };
+}
+
+v2df __attribute__((noinline))
+foo (v2df y)
+{
+ return y + bar (y);
+}
+
+int
+main (void)
+{
+ int success;
+ union {
+v2df v;
+double d[2];
+ } u;
+
+ u.v = foo ((v2df){ 5.0, 5.0});
+ success = (u.d[0] == 13.0
+ u.d[1] == 13.0);
+
+ return !success;
+}
+
+/* { dg-final { scan-assembler-not movaps\t%xmm1, \\(%rsp\\) } } */
+/* { dg-final { scan-assembler-not movapd\t\\(%rsp\\), %xmm1 } } */
+/* { dg-final { scan-assembler-times .cfi_def_cfa_offset 16 1 } } */
+/* { dg-final { scan-assembler-times .cfi_def_cfa_offset 32 1 } } */
+
Re: [PATCH] libstdc++: add uniform on sphere distribution
are these dummy implementations intended? Yes. There is no state. The only parameter is the dimensionality which is a template parameter. We do often serialize underlying helper distributions, in your case the normal distribution _M_n. While the normal distribution mean and stddev are trivial for your case (not actually needing serialization) the normal distribution has these _M_saved, etc. shat we should store. So I would just serialize _M_n here. This is a great distribution. Thanks! Are you looking at the normal distribution equivalent of these?
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland 3dw...@verizon.net wrote: So I would just serialize _M_n here. It has fixed parameters. This would mean unnecessary work. When you try to use the parameter of the sphere distribution the normal distribution will be reset. So there really is no need here. The only problem would be if code couldn't handle the operators not writing/reading anything But I haven't seen anything like that.
Re: [PATCH] libstdc++: add uniform on sphere distribution
On 07/13/2014 10:11 AM, Ulrich Drepper wrote: On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland 3dw...@verizon.net wrote: So I would just serialize _M_n here. It has fixed parameters. This would mean unnecessary work. When you try to use the parameter of the sphere distribution the normal distribution will be reset. So there really is no need here. The only problem would be if code couldn't handle the operators not writing/reading anything But I haven't seen anything like that. OK. I see it. Thanks.
Re: [GSoC] generation of Gimple loops with empty bodies
On 13/07/2014 12:34, Roman Gareev wrote: Hi Dominique, thank you for the message! I've attached a patch, that may fix the issue. Please report back if it fixes the problem. Roman, this patch is OK to commit, but please include a correct changelog file. Tobias
Re: [PATCH] libstdc++: add uniform on sphere distribution
Hi, On 07/13/2014 04:11 PM, Ulrich Drepper wrote: On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland 3dw...@verizon.net wrote: So I would just serialize _M_n here. It has fixed parameters. This would mean unnecessary work. When you try to use the parameter of the sphere distribution the normal distribution will be reset. So there really is no need here. At the cost of appearing a little dumb (and admittedly lately I'm not spending much time on random, anyway), I'd like to make sure I *really* understand your reasoning... Thus I read this (26.5.1.6/6): If a textual representation is written using os x and that representation is restored into the same or a different object y of the same type using is y, repeated invocations of y(g) shall produce the same sequence of numbers as would repeated invocations of x(g). and I think: the normal distributions in x and y do have a non-trivial state (_M_saved, _M_saved_available) which, at any given moment, is different in x and y. Then the trivial inserter of x is called and the trivial extractor of y is called, nothing changes in y. I don't see how the following invocations of y(g) can produce the same sequence of numbers that would be produced by invocations of x(g). Paolo.
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sun, Jul 13, 2014 at 11:43 AM, Paolo Carlini paolo.carl...@oracle.com wrote: and I think: the normal distributions in x and y do have a non-trivial state (_M_saved, _M_saved_available) which, at any given moment, is different in x and y. Then the trivial inserter of x is called and the trivial extractor of y is called, nothing changes in y. I don't see how the following invocations of y(g) can produce the same sequence of numbers that would be produced by invocations of x(g). Remember: we are talking about distributions, not RNGs. The distribution has no parameters so given the same input (i.e., random byte sequences) it will create the same output all the time.
Re: [PATCH] libstdc++: add uniform on sphere distribution
Hi, On 07/13/2014 06:03 PM, Ulrich Drepper wrote: On Sun, Jul 13, 2014 at 11:43 AM, Paolo Carlini paolo.carl...@oracle.com wrote: and I think: the normal distributions in x and y do have a non-trivial state (_M_saved, _M_saved_available) which, at any given moment, is different in x and y. Then the trivial inserter of x is called and the trivial extractor of y is called, nothing changes in y. I don't see how the following invocations of y(g) can produce the same sequence of numbers that would be produced by invocations of x(g). Remember: we are talking about distributions, not RNGs. The distribution has no parameters so given the same input (i.e., random byte sequences) it will create the same output all the time. Sorry, I still don't get it. When operator() of x and y, two uniform_on_sphere_distribution, call _M_n(__urng) and those _M_n have a different state, the numbers produced are in general different. For example, suppose _M_saved_available is true in both _M_n, everything is already decided, no RNGs are involved. Paolo.
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sun, Jul 13, 2014 at 12:07 PM, Paolo Carlini paolo.carl...@oracle.com wrote: Sorry, I still don't get it. When operator() of x and y, two uniform_on_sphere_distribution, call _M_n(__urng) and those _M_n have a different state, the numbers produced are in general different. Correct. But in the case of this distribution once you have the random numbers the remainder of the work is done by a fixed formula: v = (N(0,1), ..., N(0,1)) result = v / ||v||_2 That's it, nothing else to be done. If you have two calls of operator() of two different uniform_on_sphere objects and you pass to each an RNG object in exactly the same state you will get the same result.
Re: [PATCH] libstdc++: add uniform on sphere distribution
Hi, On 07/13/2014 06:18 PM, Ulrich Drepper wrote: On Sun, Jul 13, 2014 at 12:07 PM, Paolo Carlini paolo.carl...@oracle.com wrote: Sorry, I still don't get it. When operator() of x and y, two uniform_on_sphere_distribution, call _M_n(__urng) and those _M_n have a different state, the numbers produced are in general different. Correct. But in the case of this distribution once you have the random numbers the remainder of the work is done by a fixed formula: v = (N(0,1), ..., N(0,1)) result = v / ||v||_2 That's it, nothing else to be done. If you have two calls of operator() of two different uniform_on_sphere objects and you pass to each an RNG object in exactly the same state you will get the same result. I don't think so. It depends on the past of the two different uniform_on_sphere: each time each uniform_on_sphere calls _M_n(__urng) the state of *its own* _M_n changes, evolves from the initial state. For instance, you call it 4 times on one and 7 times on another. The states of the two _M_n are different, and from that point the next numbers will be different. This is exactly what happens when you call os x and is y, no object is destroyed, no object is constructed, and x has called _M_n(__urng) 4 times, and y has called it 7 times. Your inserters and extractors are trivial. The next numbers will be different. Note that, if I understand the standard correctly, we are comparing the numbers *from that point on*, not the whole story, whatever that may mean. In other terms, I'm saying the sequence of numbers produced after the 4th number isn't in general the same sequence of numbers produced after the 7th number. Paolo.
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sun, Jul 13, 2014 at 12:25 PM, Paolo Carlini paolo.carl...@oracle.com wrote: I don't think so. It depends on the past of the two different uniform_on_sphere: each time each uniform_on_sphere calls _M_n(__urng) the state of *its own* _M_n changes, evolves from the initial state. I indeed should use the normal_distribution operator and operator but I think for a different reason than you think. The way the normal_distribution is implemented produces two values at a time and saves the second for a latter call. So, yes, that implicit state has to be preserved and I should have followed what Ed said. But your 4th and 7th call example by itself is not a reason. Again, the input exclusively determined by the random numbers. Here, of course, the 4th and 7th use will produce different results. But this is not what the state of the distribution is supposed to capture. For that you'll have to save the state of the RNG as well. I've checked in a patch to save the _M_n state. Thanks.
Re: [PATCH] libstdc++: add uniform on sphere distribution
Hi, On 07/13/2014 06:44 PM, Ulrich Drepper wrote: But your 4th and 7th call example by itself is not a reason. Again, the input exclusively determined by the random numbers. Here, of course, the 4th and 7th use will produce different results. But this is not what the state of the distribution is supposed to capture. For that you'll have to save the state of the RNG as well. Yes, you are right. Saving the full state of the distribution solves only half of my hypothetical problem, but certainly you have to save it if you want to, say, reset the RNGs to a common state and get the same sequences of numbers after the os x and is y pair. Paolo.
[GSoC][match-and-simplify] use integral_op_p
Hi,
This patch uses integral_op_p instead of
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
* match.pd: Remove INTEGRAL_TYPE_P (TREE_TYPE (@0)) in bitwise
patterns and use integral_op_p@0
Thanks and Regards,
Prathamesh
Index: match.pd
===
--- match.pd (revision 212366)
+++ match.pd (working copy)
@@ -175,8 +175,7 @@ along with GCC; see the file COPYING3.
/* ~A + 1 - -A */
(match_and_simplify
- (plus (bit_not @0) integer_onep)
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (plus (bit_not integral_op_p@0) integer_onep)
(negate @0))
/* A - (A +- B) - -+ B */
@@ -220,8 +219,7 @@ along with GCC; see the file COPYING3.
/* fold_negate_exprs convert - (~A) to A + 1. */
(match_and_simplify
- (negate (bit_not @0))
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (negate (bit_not integral_op_p@0))
(plus @0 { build_int_cst (TREE_TYPE (@0), 1); } ))
/* One ternary pattern. */
@@ -283,38 +281,32 @@ along with GCC; see the file COPYING3.
/* x x - x */
(match_and_simplify
- (bit_and @0 @0)
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_and integral_op_p@0 @0)
@0)
/* x ~x - 0 */
(match_and_simplify
- (bit_and:c @0 (bit_not @0))
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_and:c integral_op_p@0 (bit_not @0))
{ build_int_cst (type, 0); })
/* ~x ~y - ~(x | y) */
(match_and_simplify
- (bit_and (bit_not @0) (bit_not @1))
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_and (bit_not integral_op_p@0) (bit_not @1))
(bit_not (bit_ior @0 @1)))
/* ~x | ~y - ~(x y) */
(match_and_simplify
- (bit_ior (bit_not @0) (bit_not @1))
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_ior (bit_not integral_op_p@0) (bit_not @1))
(bit_not (bit_and @0 @1)))
/* x (~x | y) - y x */
(match_and_simplify
- (bit_and:c @0 (bit_ior:c (bit_not @0) @1))
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1))
(bit_and @1 @0))
/* (x | CST1) CST2 - (x CST2) | (CST1 CST2) */
(match_and_simplify
- (bit_and (bit_ior @0 INTEGER_CST_P@1) INTEGER_CST_P@2)
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_and (bit_ior integral_op_p@0 INTEGER_CST_P@1) INTEGER_CST_P@2)
(bit_ior (bit_and @0 @2) (bit_and @1 @2)))
/* x ^ ~0 - ~x */
@@ -324,38 +316,32 @@ along with GCC; see the file COPYING3.
/* (x | y) x - x */
(match_and_simplify
- (bit_and:c (bit_ior @0 @1) @0)
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_and:c (bit_ior integral_op_p@0 @1) @0)
@0)
/* (x y) | x - x */
(match_and_simplify
- (bit_ior:c (bit_and @0 @1) @0)
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_ior:c (bit_and integral_op_p@0 @1) @0)
@0)
/* (~x | y) x - x y */
(match_and_simplify
- (bit_and:c (bit_ior:c (bit_not @0) @1) @0)
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_and:c (bit_ior:c (bit_not integral_op_p@0) @1) @0)
(bit_and @0 @1))
/* (~x y) | x - x | y */
(match_and_simplify
- (bit_ior:c (bit_and:c (bit_not @0) @1) @0)
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_ior:c (bit_and:c (bit_not integral_op_p@0) @1) @0)
(bit_ior @0 @1))
/* ~~x - x */
(match_and_simplify
- (bit_not (bit_not @0))
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_not (bit_not integral_op_p@0))
@0)
/* ((a b) ~a) - 0 */
(match_and_simplify
- (bit_and:c (bit_and @0 @1) (bit_not @0))
- if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ (bit_and:c (bit_and integral_op_p@0 @1) (bit_not @0))
{ build_int_cst (type, 0); })
/* s
Re: More informative ODR warnings
Hi,
this is version after taking into account all the feedback. I reformulated the
warnings on fields and methods to show the type first and then inform about
mismatching elements. On mainline (without ODR type merging) there are no
warnings on libxul, but there are few others during Firefox build.
One interesting is in breakpad where there are types compiled with signed and
unsigned char. I suppose it is ODR violation to use two variants of char in one
program, but I am not 100% sure.
Bootstrapped/regtested x86_64-linux and comitted
Honza
* tree.c (type_in_anonymous_namespace_p): Ignore TREE_PUBLIC
on builtin types.
* ipa-devirt.c: Include stor-layout.h and intl.h
(odr_subtypes_equivalent_p): New function.
(warn_odr): New function.
(warn_type_mismatch): New function.
(odr_types_equivalent_p): New function.
(add_type_duplicate): Use it.
* common.opt (Wodr): New flag.
* doc/invoke.texi (Wodr): Document new warning.
Index: tree.c
===
--- tree.c (revision 212477)
+++ tree.c (working copy)
@@ -11864,6 +11864,10 @@ obj_type_ref_class (tree ref)
bool
type_in_anonymous_namespace_p (const_tree t)
{
+ /* TREE_PUBLIC of TYPE_STUB_DECL may not be properly set for
+ bulitin types; those have CONTEXT NULL. */
+ if (!TYPE_CONTEXT (t))
+return false;
return (TYPE_STUB_DECL (t) !TREE_PUBLIC (TYPE_STUB_DECL (t)));
}
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 212477)
+++ doc/invoke.texi (working copy)
@@ -260,7 +260,7 @@ Objective-C and Objective-C++ Dialects}.
-Wlogical-op -Wlogical-not-parentheses -Wlong-long @gol
-Wmain -Wmaybe-uninitialized -Wmissing-braces -Wmissing-field-initializers
@gol
-Wmissing-include-dirs @gol
--Wno-multichar -Wnonnull -Wno-overflow -Wopenmp-simd @gol
+-Wno-multichar -Wnonnull -Wodr -Wno-overflow -Wopenmp-simd @gol
-Woverlength-strings -Wpacked -Wpacked-bitfield-compat -Wpadded @gol
-Wparentheses -Wpedantic-ms-format -Wno-pedantic-ms-format @gol
-Wpointer-arith -Wno-pointer-to-int-cast @gol
@@ -4915,6 +4915,12 @@ attribute.
@opindex Woverflow
Do not warn about compile-time overflow in constant expressions.
+@opindex Wodr
+@opindex Wno-odr
+@opindex Wodr
+Warn about One Definition Rule violations during link time optimization.
+Require @option{-flto-odr-type-merging} to be enabled. Enabled by default
+
@item -Wopenmp-simd
@opindex Wopenm-simd
Warn if the vectorizer cost model overrides the OpenMP or the Cilk Plus
Index: common.opt
===
--- common.opt (revision 212477)
+++ common.opt (working copy)
@@ -587,6 +587,10 @@ Warn if the loop cannot be optimized due
Wmissing-noreturn
Common Alias(Wsuggest-attribute=noreturn)
+Wodr
+Common Warning
+Warn about some C++ One Definition Rule violations during link time
optimization
+
Woverflow
Common Var(warn_overflow) Init(1) Warning
Warn about overflow in arithmetic expressions
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 212477)
+++ ipa-devirt.c(working copy)
@@ -130,6 +130,10 @@ along with GCC; see the file COPYING3.
#include tree-dfa.h
#include demangle.h
#include dbgcnt.h
+#include stor-layout.h
+#include intl.h
+
+static bool odr_types_equivalent_p (tree, tree, bool, bool *, pointer_set_t *);
static bool odr_violation_reported = false;
@@ -431,6 +435,498 @@ set_type_binfo (tree type, tree binfo)
gcc_assert (!TYPE_BINFO (type));
}
+/* Compare T2 and T2 based on name or structure. */
+
+static bool
+odr_subtypes_equivalent_p (tree t1, tree t2, pointer_set_t *visited)
+{
+ bool an1, an2;
+
+ /* This can happen in incomplete types that should be handled earlier. */
+ gcc_assert (t1 t2);
+
+ t1 = main_odr_variant (t1);
+ t2 = main_odr_variant (t2);
+ if (t1 == t2)
+return true;
+ if (TREE_CODE (t1) != TREE_CODE (t2))
+return false;
+ if ((TYPE_NAME (t1) == NULL_TREE) != (TYPE_NAME (t2) == NULL_TREE))
+return false;
+ if (TYPE_NAME (t1) DECL_NAME (TYPE_NAME (t1)) != DECL_NAME (TYPE_NAME
(t2)))
+return false;
+
+ /* Anonymous namespace types must match exactly. */
+ an1 = type_in_anonymous_namespace_p (t1);
+ an2 = type_in_anonymous_namespace_p (t2);
+ if (an1 != an2 || an1)
+return false;
+
+ /* For types where we can not establish ODR equivalency, recurse and deeply
+ compare. */
+ if (TREE_CODE (t1) != RECORD_TYPE
+ || !TYPE_BINFO (t1) || !TYPE_BINFO (t2)
+ || !polymorphic_type_binfo_p (TYPE_BINFO (t1))
+ || !polymorphic_type_binfo_p (TYPE_BINFO (t2)))
+{
+ /* This should really be a pair hash, but for the moment we do not need
+100% reliability and it would be better to compare all ODR types so
+recursion here
[PATCH] Implement -fsanitize=object-size
The following is an attempt to implement -fsanitize=object-size.
When it sees a MEM_REF, it goes through the definition statements
and stops on sth like ptr = sth. Then it tries to determine the
object size using __builtin_object_size and generates an internal
call (in .ubsan pass). The .sanopt pass then expands this internal
call, and if the pointer points outside of the object, it issues
a runtime error.
Bootstrapped(-ubsan)/regtested on x86_64-linux, ok for trunk?
2014-07-13 Marek Polacek pola...@redhat.com
* ubsan.h (struct ubsan_mismatch_data):
* asan.c (pass_sanopt::execute): Handle IFN_UBSAN_OBJECT_SIZE.
* doc/invoke.texi: Document -fsanitize=object-size.
* flag-types.h (enum sanitize_code): Add SANITIZE_OBJECT_SIZE and
or it into SANITIZE_UNDEFINED.
* internal-fn.c (expand_UBSAN_OBJECT_SIZE): New function.
* internal-fn.def (UBSAN_OBJECT_SIZE): Define.
* opts.c (common_handle_option): Handle -fsanitize=object-size.
* ubsan.c: Include tree-object-size.h.
(ubsan_expand_objsize_ifn): New function.
(instrument_object_size): New function.
(pass_ubsan::execute): Add object size instrumentation.
* ubsan.h (ubsan_expand_objsize_ifn): Declare.
testsuite/
* c-c++-common/ubsan/object-size-1.c: New test.
* c-c++-common/ubsan/object-size-2.c: New test.
* c-c++-common/ubsan/object-size-3.c: New test.
* c-c++-common/ubsan/object-size-4.c: New test.
* c-c++-common/ubsan/object-size-5.c: New test.
* c-c++-common/ubsan/object-size-6.c: New test.
* c-c++-common/ubsan/object-size-7.c: New test.
diff --git gcc/asan.c gcc/asan.c
index b9a4a91..5954f95 100644
--- gcc/asan.c
+++ gcc/asan.c
@@ -2764,6 +2764,9 @@ pass_sanopt::execute (function *fun)
case IFN_UBSAN_BOUNDS:
ubsan_expand_bounds_ifn (gsi);
break;
+ case IFN_UBSAN_OBJECT_SIZE:
+ ubsan_expand_objsize_ifn (gsi);
+ break;
default:
break;
}
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 4807ffc..fbaac9d 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -5477,6 +5477,12 @@ This option enables instrumentation of array bounds.
Various out of bounds
accesses are detected. Flexible array members and initializers of variables
with static storage are not instrumented.
+@item -fsanitize=object-size
+@opindex fsanitize=object-size
+This option enables instrumentation of memory references using the
+@code{__builtin_object_size} function. Various out of bounds pointer
+accesses are detected.
+
@item -fsanitize=float-divide-by-zero
@opindex fsanitize=float-divide-by-zero
Detect floating-point division by zero. Unlike other similar options,
diff --git gcc/flag-types.h gcc/flag-types.h
index 2849455..63d199c 100644
--- gcc/flag-types.h
+++ gcc/flag-types.h
@@ -231,10 +231,11 @@ enum sanitize_code {
SANITIZE_FLOAT_DIVIDE = 1 12,
SANITIZE_FLOAT_CAST = 1 13,
SANITIZE_BOUNDS = 1 14,
+ SANITIZE_OBJECT_SIZE = 1 15,
SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
| SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
| SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
- | SANITIZE_BOUNDS,
+ | SANITIZE_BOUNDS | SANITIZE_OBJECT_SIZE,
SANITIZE_NONDEFAULT = SANITIZE_FLOAT_DIVIDE | SANITIZE_FLOAT_CAST
};
diff --git gcc/internal-fn.c gcc/internal-fn.c
index 78f59d6..eee3e85 100644
--- gcc/internal-fn.c
+++ gcc/internal-fn.c
@@ -167,6 +167,14 @@ expand_UBSAN_BOUNDS (gimple stmt ATTRIBUTE_UNUSED)
gcc_unreachable ();
}
+/* This should get expanded in the sanopt pass. */
+
+static void
+expand_UBSAN_OBJECT_SIZE (gimple stmt ATTRIBUTE_UNUSED)
+{
+ gcc_unreachable ();
+}
+
/* Add sub/add overflow checking to the statement STMT.
CODE says whether the operation is +, or -. */
diff --git gcc/internal-fn.def gcc/internal-fn.def
index f0766bc..a2caf94 100644
--- gcc/internal-fn.def
+++ gcc/internal-fn.def
@@ -49,6 +49,7 @@ DEF_INTERNAL_FN (MASK_STORE, ECF_LEAF)
DEF_INTERNAL_FN (ANNOTATE, ECF_CONST | ECF_LEAF | ECF_NOTHROW)
DEF_INTERNAL_FN (UBSAN_NULL, ECF_LEAF | ECF_NOTHROW)
DEF_INTERNAL_FN (UBSAN_BOUNDS, ECF_LEAF | ECF_NOTHROW)
+DEF_INTERNAL_FN (UBSAN_OBJECT_SIZE, ECF_LEAF | ECF_NOTHROW)
DEF_INTERNAL_FN (UBSAN_CHECK_ADD, ECF_CONST | ECF_LEAF | ECF_NOTHROW)
DEF_INTERNAL_FN (UBSAN_CHECK_SUB, ECF_CONST | ECF_LEAF | ECF_NOTHROW)
DEF_INTERNAL_FN (UBSAN_CHECK_MUL, ECF_CONST | ECF_LEAF | ECF_NOTHROW)
diff --git gcc/opts.c gcc/opts.c
index 419a074..00ec76f 100644
--- gcc/opts.c
+++ gcc/opts.c
@@ -1475,6 +1475,8 @@ common_handle_option (struct gcc_options *opts,
{ float-cast-overflow, SANITIZE_FLOAT_CAST,
sizeof float-cast-overflow - 1 },
{ bounds, SANITIZE_BOUNDS, sizeof bounds - 1 },
+
Re: More informative ODR warnings
Hi Honzo,
On Sun, 13 Jul 2014, Jan Hubicka wrote:
+@opindex Wodr
+@opindex Wno-odr
+@opindex Wodr
+Warn about One Definition Rule violations during link time optimization.
+Require @option{-flto-odr-type-merging} to be enabled. Enabled by default
here in invoke.texi you talk about One Definition Rule violations
(which might imply all) whereas...
+Wodr
+Common Warning
+Warn about some C++ One Definition Rule violations during link time
optimization
...here you note that it's some and add C++.
Should these two restrictions be noted in invoke.texi as well?
Gerald
Re: [PATCH] Implement -fsanitize=object-size
Hi Marek,
On Sun, 13 Jul 2014, Marek Polacek wrote:
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -5477,6 +5477,12 @@ This option enables instrumentation of array bounds.
Various out of bounds
accesses are detected. Flexible array members and initializers of variables
with static storage are not instrumented.
+@item -fsanitize=object-size
+@opindex fsanitize=object-size
+This option enables instrumentation of memory references using the
+@code{__builtin_object_size} function. Various out of bounds pointer
+accesses are detected.
I believe this should be out-of-bounds and, yes, there is a variant
without the dashes just above your patch already which would be good
to adjust as well.
(Best let's see what a native speaker suggests.)
Thanks,
Gerald
[patch,libgfortran] Bug 61632 - memory corruption when writing formatted data
Hi all,
This bug was caused by an access to an invalid pointer offset to the format
string. This was only a problem on the second error using the same format
string. I suspect it has to do with caching the format strings. Regardless,
the patch fixes this by using the fortran style string lengths to calculate the
position in the string where the error occurs.
Test case attached.
Regression tested on x86-64.
OK for trunk?
2014-07-12 Jerry DeLisle jvdeli...@gcc.gnu.org
PR libgfortran/61632
* io/format.c (format_error): Avoid invalid string pointer by
using the fortran string length values to generate error string.
Index: format.c
===
--- format.c (revision 212420)
+++ format.c (working copy)
@@ -1117,7 +1117,7 @@ parse_format_list (st_parameter_dt *dtp, bool *see
void
format_error (st_parameter_dt *dtp, const fnode *f, const char *message)
{
- int width, i, j, offset;
+ int width, i, offset;
#define BUFLEN 300
char *p, buffer[BUFLEN];
format_data *fmt = dtp-u.p.fmt;
@@ -1130,13 +1130,10 @@ format_error (st_parameter_dt *dtp, const fnode *f
else
snprintf (buffer, BUFLEN, %s\n, message);
- j = fmt-format_string - dtp-format;
+ offset = dtp-format_len - fmt-format_string_len;
- offset = (j 60) ? j - 40 : 0;
+ width = dtp-format_len;
- j -= offset;
- width = dtp-format_len - offset;
-
if (width 80)
width = 80;
@@ -1144,14 +1141,14 @@ format_error (st_parameter_dt *dtp, const fnode *f
p = strchr (buffer, '\0');
- memcpy (p, dtp-format + offset, width);
+ memcpy (p, dtp-format, width);
p += width;
*p++ = '\n';
/* Show where the problem is */
- for (i = 1; i j; i++)
+ for (i = 1; i offset; i++)
*p++ = ' ';
*p++ = '^';
! { dg-do run }
! Bug 61632 - memory corruption writing formatted data in error
program p
CHARACTER(3), save :: ZTYP(3)
DATA ZTYP /'XXX','YYY','ZZZ'/
write(10,600,IOSTAT=iosta) 0.0,ZTYP
write(10,600,IOSTAT=iosta) 0.0,ZTYP
close(10, status='delete')
600 FORMAT(1PE13.5,4X,A3)
end program p
Re: More informative ODR warnings
Hi Honzo,
Nazdar Geralde,
On Sun, 13 Jul 2014, Jan Hubicka wrote:
+@opindex Wodr
+@opindex Wno-odr
+@opindex Wodr
+Warn about One Definition Rule violations during link time optimization.
+Require @option{-flto-odr-type-merging} to be enabled. Enabled by default
here in invoke.texi you talk about One Definition Rule violations
(which might imply all) whereas...
+Wodr
+Common Warning
+Warn about some C++ One Definition Rule violations during link time
optimization
...here you note that it's some and add C++.
Should these two restrictions be noted in invoke.texi as well?
Actually the first hunk (in invoke.texi) is a version that is correct only with
my
ODR streaming patch that may or may not land mainline. I will update it to the
simplified
version from common.opt. Basically we now warn only on ODR violations within
polymorphic
types.
Honza
Re: [RFC] Making fold-const sane WRT symbol visibilities
Hi,
this is variant of patch I comitted (the change is only testsuite compensation
for pr36902 and 44024) and updated predicate name to nonzero_address
Honza
* cgraph.h (symtab_node): Add nonzero_address.
(decl_in_symtab_p): Break out from ...
(symtab_get_node): ... here.
* fold-const.c: Include cgraph.h
(tree_single_nonzero_warnv_p): Use symtab to determine
if symbol is non-zero.
* symtab.c (symtab_node::nonzero_address): New method.
* gcc.dg/pr36901.h: Simplify because non-zero symbol folding no
longer happens during parsing.
* gcc.dg/pr44024.c: Update template.
* g++.dg/tree-ssa/nonzero-2.C: New testcase.
* g++.dg/tree-ssa/nonzero-1.C: New testcase.
* gcc.dg/tree-ssa/nonzero-1.c: New testcase.
Index: cgraph.h
===
--- cgraph.h(revision 212495)
+++ cgraph.h(working copy)
@@ -282,6 +282,9 @@ public:
void set_init_priority (priority_type priority);
priority_type get_init_priority ();
+
+ /* Return true if symbol is known to be nonzero. */
+ bool nonzero_address ();
};
/* Walk all aliases for NODE. */
@@ -1148,6 +1151,17 @@ tree varpool_get_constructor (struct var
/* In cgraph.c */
extern void change_decl_assembler_name (tree, tree);
+/* Return true if DECL should have entry in symbol table if used.
+ Those are functions and static external veriables*/
+
+static bool
+decl_in_symtab_p (const_tree decl)
+{
+ return (TREE_CODE (decl) == FUNCTION_DECL
+ || (TREE_CODE (decl) == VAR_DECL
+ (TREE_STATIC (decl) || DECL_EXTERNAL (decl;
+}
+
/* Return symbol table node associated with DECL, if any,
and NULL otherwise. */
@@ -1155,12 +1169,7 @@ static inline symtab_node *
symtab_get_node (const_tree decl)
{
#ifdef ENABLE_CHECKING
- /* Check that we are called for sane type of object - functions
- and static or external variables. */
- gcc_checking_assert (TREE_CODE (decl) == FUNCTION_DECL
- || (TREE_CODE (decl) == VAR_DECL
- (TREE_STATIC (decl) || DECL_EXTERNAL (decl)
- || in_lto_p)));
+ gcc_checking_assert (decl_in_symtab_p (decl));
/* Check that the mapping is sane - perhaps this check can go away,
but at the moment frontends tends to corrupt the mapping by calling
memcpy/memset on the tree nodes. */
Index: fold-const.c
===
--- fold-const.c(revision 212495)
+++ fold-const.c(working copy)
@@ -69,6 +69,7 @@ along with GCC; see the file COPYING3.
#include tree-dfa.h
#include hash-table.h /* Required for ENABLE_FOLD_CHECKING. */
#include builtins.h
+#include cgraph.h
/* Nonzero if we are folding constants inside an initializer; zero
otherwise. */
@@ -16020,21 +16021,33 @@ tree_single_nonzero_warnv_p (tree t, boo
case ADDR_EXPR:
{
tree base = TREE_OPERAND (t, 0);
+
if (!DECL_P (base))
base = get_base_address (base);
if (!base)
return false;
- /* Weak declarations may link to NULL. Other things may also be NULL
- so protect with -fdelete-null-pointer-checks; but not variables
- allocated on the stack. */
+ /* For objects in symbol table check if we know they are non-zero.
+ Don't do anything for variables and functions before symtab is built;
+ it is quite possible that they will be declared weak later. */
+ if (DECL_P (base) decl_in_symtab_p (base))
+ {
+ struct symtab_node *symbol;
+
+ symbol = symtab_get_node (base);
+ if (symbol)
+ return symbol-nonzero_address ();
+ else
+ return false;
+ }
+
+ /* Function local objects are never NULL. */
if (DECL_P (base)
-(flag_delete_null_pointer_checks
- || (DECL_CONTEXT (base)
-TREE_CODE (DECL_CONTEXT (base)) == FUNCTION_DECL
-auto_var_in_fn_p (base, DECL_CONTEXT (base)
- return !VAR_OR_FUNCTION_DECL_P (base) || !DECL_WEAK (base);
+(DECL_CONTEXT (base)
+TREE_CODE (DECL_CONTEXT (base)) == FUNCTION_DECL
+auto_var_in_fn_p (base, DECL_CONTEXT (base
+ return true;
/* Constants are never weak. */
if (CONSTANT_CLASS_P (base))
Index: testsuite/gcc.dg/pr36901.h
===
--- testsuite/gcc.dg/pr36901.h (revision 212495)
+++ testsuite/gcc.dg/pr36901.h (working copy)
@@ -1,6 +1,2 @@
-#if defined(AVR) /* flag_delete_null_pointer_checks = 0 */
int sc = (sc = 0);
-#else
-int sc = (sc 0);
-#endif
Index: testsuite/gcc.dg/pr44024.c
===
--- testsuite/gcc.dg/pr44024.c (revision
Fix Firefox LTO ICE
Hi,
I updated my firefox tree and now I get ICE at:
/aux/hubicka/firefox2/firefox/intl/icu/source/i18n/ucol_bld.cpp:1274:51: note:
in statement
el.prefix = el.prefixChars;
^
# .MEM_339 = VDEF .MEM_338
el.prefix = el.prefixChars;
lto1: error: address taken, but ADDRESSABLE bit not set
The variable have correctly set TREE_ADDRESSABLE bit in the LTO stream, but the
bit is cleared
when doing TODO after inlining into completely different function. This is
becuase the
variable appears incorreclty in local_decls in that function. It is added there
by inliner
by:
static tree
remap_decls (tree decls, vectree, va_gc **nonlocalized_list,
copy_body_data *id)
{
tree old_var;
tree new_decls = NULL_TREE;
/* Remap its variables. */
for (old_var = decls; old_var; old_var = DECL_CHAIN (old_var))
{
tree new_var;
if (can_be_nonlocal (old_var, id))
{
/* We need to add this variable to the local decls as otherwise
nothing else will do so. */
if (TREE_CODE (old_var) == VAR_DECL
! DECL_EXTERNAL (old_var))
add_local_decl (cfun, old_var);
(while remapping BLOCK of the function being inlined that is yet another
function).
This reason is that old_var appears incorrectly in the BLOCK_VARS list because
that
list starts by IMPORT_DECL that is streamed into global stream and then inserted
into multiple lists resulting in a bad soup.
The following patch seems to fix it. I think we can safely duplicate this beast
into
each function that use it.
Bootstrap/regtested in progress, tested with firefox.
Honza
* lto-streamer-out.c (tree_is_indexable): Imported_decl is not
indexable.
Index: lto-streamer-out.c
===
--- lto-streamer-out.c (revision 212479)
+++ lto-streamer-out.c (working copy)
@@ -139,6 +139,9 @@ tree_is_indexable (tree t)
definition. */
if (TREE_CODE (t) == PARM_DECL || TREE_CODE (t) == RESULT_DECL)
return variably_modified_type_p (TREE_TYPE (DECL_CONTEXT (t)), NULL_TREE);
+ /* IMPORTED_DECL is put into BLOCK and thus it never can be shared. */
+ else if (TREE_CODE (t) == IMPORTED_DECL)
+return false;
else if (((TREE_CODE (t) == VAR_DECL !TREE_STATIC (t))
|| TREE_CODE (t) == TYPE_DECL
|| TREE_CODE (t) == CONST_DECL
Re: [PATCH 2/2] Enable elimination of zext/sext
On 11/07/14 22:47, Richard Biener wrote:
On Fri, Jul 11, 2014 at 1:52 PM, Kugan
kugan.vivekanandara...@linaro.org wrote:
Thanks foe the review and suggestions.
On 10/07/14 22:15, Richard Biener wrote:
On Mon, Jul 7, 2014 at 8:55 AM, Kugan kugan.vivekanandara...@linaro.org
wrote:
[...]
For -fwrapv, it is due to how PROMOTE_MODE is defined in arm back-end.
In the test-case, a function (which has signed char return type) returns
-1 in one of the paths. ARM PROMOTE_MODE changes that to 255 and relies
on zero/sign extension generated by RTL again for the correct value. I
saw some other targets also defining similar think. I am therefore
skipping removing zero/sign extension if the ssa variable can be set to
negative integer constants.
Hm? I think you should rather check that you are removing a
sign-/zero-extension - PROMOTE_MODE tells you if it will sign- or
zero-extend. Definitely
+ /* In some architectures, negative integer constants are truncated and
+ sign changed with target defined PROMOTE_MODE macro. This will impact
+ the value range seen here and produce wrong code if zero/sign
extensions
+ are eliminated. Therefore, return false if this SSA can have negative
+ integers. */
+ if (is_gimple_assign (stmt)
+ (TREE_CODE_CLASS (gimple_assign_rhs_code (stmt)) == tcc_unary))
+{
+ tree rhs1 = gimple_assign_rhs1 (stmt);
+ if (TREE_CODE (rhs1) == INTEGER_CST
+ !TYPE_UNSIGNED (TREE_TYPE (ssa))
+ tree_int_cst_compare (rhs1, integer_zero_node) == -1)
+ return false;
looks completely bogus ... (an unary op with a constant operand?)
instead you want to do sth like
I see that unary op with a constant operand is not possible in gimple.
What I wanted to check here is any sort of constant loads; but seems
that will not happen in gimple. Is PHI statements the only possible
statements where we will end up with such constants.
No, in theory you can have
ssa_1 = -1;
but that's not unary but a GIMPLE_SINGLE_RHS and thus
gimple_assign_rhs_code (stmt) == INTEGER_CST.
mode = TYPE_MODE (TREE_TYPE (ssa));
rhs_uns = TYPE_UNSIGNED (TREE_TYPE (ssa));
PROMOTE_MODE (mode, rhs_uns, TREE_TYPE (ssa));
instead of initializing rhs_uns from ssas type. That is, if
PROMOTE_MODE tells you to promote _not_ according to ssas sign then
honor that.
This is triggered in pr43017.c in function foo for arm-none-linux-gnueabi.
where, the gimple statement that cause this looks like:
.
# _3 = PHI _17(7), -1(2)
bb43:
return _3;
ARM PROMOTE_MODE changes the sign for integer constants only and hence
looking at the variable with PROMOTE_MODE is not changing the sign in
this case.
#define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \
if (GET_MODE_CLASS (MODE) == MODE_INT \
GET_MODE_SIZE (MODE) 4) \
{ \
if (MODE == QImode) \
UNSIGNEDP = 1; \
else if (MODE == HImode) \
UNSIGNEDP = 1; \
(MODE) = SImode; \
}
Where does it only apply for constants? It applies to all QImode and
HImode entities.
oops, sorry. I don’t know what I was thinking or looking at when I wrote
that :( It indeed fixes my problems. Thanks for that.
Here is the modified patch. Bootstrapped and regression tested for
86_64-unknown-linux-gnu and arm-none-linux-gnueabi with no new regressions.
Is this OK?
Thanks,
Kugan
gcc/
2014-07-14 Kugan Vivekanandarajah kug...@linaro.org
* calls.c (precompute_arguments): Check is_promoted_for_type
and set the promoted mode.
(is_promoted_for_type): New function.
(expand_expr_real_1): Check is_promoted_for_type
and set the promoted mode.
* expr.h (is_promoted_for_type): New function definition.
* cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.
gcc/testsuite
2014-07-14 Kugan Vivekanandarajah kug...@linaro.org
* gcc.dg/zero_sign_ext_test.c: New test.
diff --git a/gcc/calls.c b/gcc/calls.c
index a3e6faa..eac512f 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1484,7 +1484,10 @@ precompute_arguments (int num_actuals, struct arg_data
*args)
args[i].initial_value
= gen_lowpart_SUBREG (mode, args[i].value);
SUBREG_PROMOTED_VAR_P (args[i].initial_value) = 1;
- SUBREG_PROMOTED_SET (args[i].initial_value, args[i].unsignedp);
+ if (is_promoted_for_type (args[i].tree_value, mode,
!args[i].unsignedp))
+ SUBREG_PROMOTED_SET (args[i].initial_value,
SRP_SIGNED_AND_UNSIGNED);
+ else
+ SUBREG_PROMOTED_SET (args[i].initial_value, args[i].unsignedp);
}
}
}
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index
[PATCH] Fix INSN_TICK heuristic for SCHED_PRESSURE
Hi,
This patch fixes 2 of the [several] problems in rank_for_schedule heuristics
for SCHED_PRESSURE_MODEL. SCHED_PRESSURE_MODEL is used for first scheduling
pass in ARM backend by default.
The first one is when INSN_TICK of both instructions are equal, and
rank_for_schedule returns a tie result, even though there are more heuristics
down the path to break the tie.
The second one is to account for the fact that model_index() of two
instructions is meaningful only when both instructions are in the current basic
block.
Bootstrapped and tested on {x86_64,arm,aarch64}-linux.
OK to apply?
More fixes to SCHED_PRESSURE_MODEL coming soon.
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
0001-Fix-INSN_TICK-heuristic-for-SCHED_PRESSURE.patch
Description: Binary data
[PATCH] Add statistical printout of rank_for_schedule decisions
Hi, This patch adds dump printouts for scheduling heuristics in rank_for_schedule. Rank_for_schedule is one of the cornerstones of haifa scheduler, yet its decisions are hard to track and debug. This patch adds statistical gathering for each branch of rank_for_schedule, and prints them out according to sched verbosity. This patch helped me track down several bugs in rank_for_schedule that result is stupid scheduling decisions. Bootstrapped and tested on x86_64-linux-gnu. OK to apply? Thank you, -- Maxim Kuvyrkov www.linaro.org 0002-Add-statistical-printout-of-rank_for_schedule-decisi.patch Description: Binary data
C++ PATCH for c++/58511 (inherited ctor/constexpr diagnostic)
synthesized_method_walk doesn't recognize that the default argument
prevents B(int) from producing a constant expression; instead, we should
use require_potential_rvalue_constant_expression to get diagnostics for
functions that are marked constexpr. And we should keep the
DECL_SAVED_TREE for a defaulted constexpr function around long enough to
pass it in.
The explain_implicit_non_constexpr change may be unnecessary, but is
correct in any case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 57669c237723c6d109badb660440675fd2aab883
Author: Jason Merrill ja...@redhat.com
Date: Sun Jul 13 14:20:24 2014 -0400
PR c++/58511
* semantics.c (is_instantiation_of_constexpr): Return true for
defaulted functions, too.
(explain_invalid_constexpr_fn): Only use
explain_implicit_non_constexpr if !DECL_DECLARED_CONSTEXPR_P.
* method.c (explain_implicit_non_constexpr): Pass
DECL_INHERITED_CTOR_BASE to explain_implicit_non_constexpr.
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 4d8aac1..1fa4be8 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1575,7 +1575,8 @@ explain_implicit_non_constexpr (tree decl)
synthesized_method_walk (DECL_CLASS_CONTEXT (decl),
special_function_p (decl), const_p,
NULL, NULL, NULL, dummy, true,
- NULL_TREE, NULL_TREE);
+ DECL_INHERITED_CTOR_BASE (decl),
+ FUNCTION_FIRST_USER_PARMTYPE (decl));
}
/* DECL is an instantiation of an inheriting constructor template. Deduce
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index a6d941b..c87764d 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3949,13 +3949,16 @@ emit_associated_thunks (tree fn)
}
/* Returns true iff FUN is an instantiation of a constexpr function
- template. */
+ template or a defaulted constexpr function. */
static inline bool
is_instantiation_of_constexpr (tree fun)
{
- return (DECL_TEMPLOID_INSTANTIATION (fun)
- DECL_DECLARED_CONSTEXPR_P (DECL_TI_TEMPLATE (fun)));
+ return ((DECL_TEMPLOID_INSTANTIATION (fun)
+ DECL_DECLARED_CONSTEXPR_P (DECL_TI_TEMPLATE (fun)))
+ || (DECL_DEFAULTED_FN (fun)
+ DECL_DECLARED_CONSTEXPR_P (fun)));
+
}
/* Generate RTL for FN. */
@@ -8048,7 +8051,7 @@ explain_invalid_constexpr_fn (tree fun)
if (is_valid_constexpr_fn (fun, true))
{
/* Then if it's OK, the body. */
- if (DECL_DEFAULTED_FN (fun))
+ if (!DECL_DECLARED_CONSTEXPR_P (fun))
explain_implicit_non_constexpr (fun);
else
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-inhctor1.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-inhctor1.C
new file mode 100644
index 000..ee8757f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-inhctor1.C
@@ -0,0 +1,15 @@
+// PR c++/58511
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+ constexpr A(int, int = i) {}
+ static const int i;
+};
+
+struct B : A
+{
+ using A::A; // { dg-error A::i }
+};
+
+constexpr B b(0); // { dg-error B::B }
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C b/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C
index a8e8cdf..6ac414b 100644
--- a/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C
@@ -10,9 +10,9 @@ struct B
{
A a1 = 1; // { dg-error }
A a2 { 2 };
- A a3 = { 3 }; // { dg-error }
+ A a3 = { 3 }; // { dg-error explicit }
};
constexpr B b; // { dg-error B::B }
-// { dg-message a1. is invalid { target *-*-* } 11 }
+// { dg-prune-output uninitialized member }
C++ PATCH for c++/58611 (ICE with invalid constexpr array)
Calling finish_compound_literal in this case ends up trying to reshape
an initializer that has already been digested, and removing the call
doesn't seem to break anything.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6f94e657ce04fd32cac5e616e9ca675c40e3fab5
Author: Jason Merrill ja...@redhat.com
Date: Sun Jul 13 13:53:24 2014 -0400
PR c++/58611
* decl.c (check_initializer): Don't finish_compound_literal
on erroneous constexpr init.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 8f829d0..9d3fbb2 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5812,11 +5812,8 @@ check_initializer (tree decl, tree init, int flags, vectree, va_gc **cleanups)
/* Declared constexpr, but no suitable initializer; massage
init appropriately so we can pass it into store_init_value
for the error. */
- if (init BRACE_ENCLOSED_INITIALIZER_P (init))
- init = finish_compound_literal (type, init,
- tf_warning_or_error);
- else if (CLASS_TYPE_P (type)
- (!init || TREE_CODE (init) == TREE_LIST))
+ if (CLASS_TYPE_P (type)
+ (!init || TREE_CODE (init) == TREE_LIST))
{
init = build_functional_cast (type, init, tf_none);
if (TREE_CODE (init) == TARGET_EXPR)
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-array6.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-array6.C
new file mode 100644
index 000..16eacdd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-array6.C
@@ -0,0 +1,15 @@
+// PR c++/58611
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+ int i;
+ constexpr A() {} // { dg-error A::i }
+};
+
+struct B
+{
+ A a;
+};
+
+constexpr B b[] = { {} }; // { dg-error A::A }
C++ PATCH for c++/58612 (constexpr ICE)
When we call break_out_target_exprs in the middle of
explain_invalid_constexpr_fn, we don't want to replace 'this' with
whatever current_class_ptr is at that point.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b520b30e2e4bf0174eea966cdccac36eefc5a544
Author: Jason Merrill ja...@redhat.com
Date: Sun Jul 13 12:52:54 2014 -0400
PR c++/58612
* tree.c (bot_replace): Only replace a dummy 'this' parm.
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 7ff5935..e782366 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -2353,7 +2353,8 @@ bot_replace (tree* t, int* /*walk_subtrees*/, void* data)
*t = (tree) n-value;
}
else if (TREE_CODE (*t) == PARM_DECL
- DECL_NAME (*t) == this_identifier)
+ DECL_NAME (*t) == this_identifier
+ !DECL_CONTEXT (*t))
{
/* In an NSDMI we need to replace the 'this' parameter we used for
parsing with the real one for this function. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-neg3.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-neg3.C
new file mode 100644
index 000..55bb838
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-neg3.C
@@ -0,0 +1,15 @@
+// PR c++/58612
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+ int foo() const { return 0; }
+};
+
+templatetypename struct B
+{
+ A a;
+ constexpr int bar() { return a.foo(); } // { dg-error foo }
+};
+
+constexpr int i = Bvoid().bar(); // { dg-error bar }
Re: C++ PATCH for c++/60628 (auto array)
On 03/25/2014 01:43 PM, Jason Merrill wrote:
We got confused tsubsting the VLA type because tsubst doesn't expect to
see a SAVE_EXPR. Simple to fix by enforcing the rule against auto arrays.
Oops, we already had a diagnostic for this, we just needed to make it an
unconditional error.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3915e30387d23d3ec46b6793d619f73f35fe5289
Author: Jason Merrill ja...@redhat.com
Date: Sun Jul 13 11:56:48 2014 -0400
PR c++/60628
* decl.c (create_array_type_for_decl): Only check for auto once.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index dae85c2..8f829d0 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -8540,9 +8540,11 @@ create_array_type_for_decl (tree name, tree type, tree size)
/* 8.3.4/1: If the type of the identifier of D contains the auto
type-specifier, the program is ill-formed. */
- if (pedantic type_uses_auto (type))
-pedwarn (input_location, OPT_Wpedantic,
- declaration of %qD as array of %auto%, name);
+ if (type_uses_auto (type))
+{
+ error (%qD declared as array of %qT, name, type);
+ return error_mark_node;
+}
/* If there are some types which cannot be array elements,
issue an error-message and return. */
@@ -8601,14 +8603,6 @@ create_array_type_for_decl (tree name, tree type, tree size)
(flag_iso || warn_vla 0))
pedwarn (input_location, OPT_Wvla, array of array of runtime bound);
- /* 8.3.4p1: ...if the type of the identifier of D contains the auto
- type-specifier, the program is ill-formed. */
- if (type_uses_auto (type))
-{
- error (%qD declared as array of %qT, name, type);
- return error_mark_node;
-}
-
/* Figure out the index type for the array. */
if (size)
itype = compute_array_index_type (name, size, tf_warning_or_error);
C++ PATCH for c++/58636 (ICE with std::initializer_listint)
You can't form an array of references in C++, so we shouldn't consider a
conversion to an initializer_list of references either.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.9.
commit 97303858558a5024b357e8ec6f4ffcf4f1c043fe
Author: Jason Merrill ja...@redhat.com
Date: Sun Jul 13 11:53:10 2014 -0400
PR c++/58636
* call.c (build_list_conv): Don't try to build a list of references.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 4ca6be5..b16c6e4 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -806,6 +806,12 @@ build_list_conv (tree type, tree ctor, int flags, tsubst_flags_t complain)
/* But no narrowing conversions. */
flags |= LOOKUP_NO_NARROWING;
+ /* Can't make an array of these types. */
+ if (TREE_CODE (elttype) == REFERENCE_TYPE
+ || TREE_CODE (elttype) == FUNCTION_TYPE
+ || VOID_TYPE_P (elttype))
+return NULL;
+
FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (ctor), i, val)
{
conversion *sub
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array4.C b/gcc/testsuite/g++.dg/cpp0x/initlist-array4.C
new file mode 100644
index 000..af2045d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array4.C
@@ -0,0 +1,9 @@
+// PR c++/58636
+// { dg-do compile { target c++11 } }
+
+#include initializer_list
+
+// { dg-error pointer to reference { target *-*-* } 0 }
+int foo(std::initializer_listint);
+
+int i = foo({ 0 }); // { dg-error std::initializer_list }
