[PATCH, i386]: Preserve precision bits when changing rounding bits in x87 control word
Hello!
When x87 rounding bits are changed in x87 control word, the
calculation clears precision bits in the new control word in certain
cases. While precision bits are not used for frndint and fist[p]
instructions, let's play safe and change only rounding bits. Also
note, that for !TARGET_PARTIAL_REG_STALL, 16bit logic operations are
later changed to 8bit operations on high register parts by generic x86
code.
2018-04-03 Uros Bizjak
* config/i386/i386.c (emit_i387_cw_initialization): Always use logic
instructions when changing rounding bits to preserve precision bits
in the x87 control word.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
I'll commit the patch to mainline SVN later today.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 259017)
+++ config/i386/i386.c (working copy)
@@ -19678,74 +19678,38 @@ emit_i387_cw_initialization (int mode)
emit_insn (gen_x86_fnstcw_1 (stored_mode));
emit_move_insn (reg, copy_rtx (stored_mode));
- if (TARGET_64BIT || TARGET_PARTIAL_REG_STALL
- || optimize_insn_for_size_p ())
+ switch (mode)
{
- switch (mode)
- {
- case I387_CW_TRUNC:
- /* round toward zero (truncate) */
- emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0c00)));
- slot = SLOT_CW_TRUNC;
- break;
+case I387_CW_TRUNC:
+ /* round toward zero (truncate) */
+ emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0c00)));
+ slot = SLOT_CW_TRUNC;
+ break;
- case I387_CW_FLOOR:
- /* round down toward -oo */
- emit_insn (gen_andhi3 (reg, reg, GEN_INT (~0x0c00)));
- emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0400)));
- slot = SLOT_CW_FLOOR;
- break;
+case I387_CW_FLOOR:
+ /* round down toward -oo */
+ emit_insn (gen_andhi3 (reg, reg, GEN_INT (~0x0c00)));
+ emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0400)));
+ slot = SLOT_CW_FLOOR;
+ break;
- case I387_CW_CEIL:
- /* round up toward +oo */
- emit_insn (gen_andhi3 (reg, reg, GEN_INT (~0x0c00)));
- emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0800)));
- slot = SLOT_CW_CEIL;
- break;
+case I387_CW_CEIL:
+ /* round up toward +oo */
+ emit_insn (gen_andhi3 (reg, reg, GEN_INT (~0x0c00)));
+ emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0800)));
+ slot = SLOT_CW_CEIL;
+ break;
- case I387_CW_MASK_PM:
- /* mask precision exception for nearbyint() */
- emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0020)));
- slot = SLOT_CW_MASK_PM;
- break;
+case I387_CW_MASK_PM:
+ /* mask precision exception for nearbyint() */
+ emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0020)));
+ slot = SLOT_CW_MASK_PM;
+ break;
- default:
- gcc_unreachable ();
- }
+default:
+ gcc_unreachable ();
}
- else
-{
- switch (mode)
- {
- case I387_CW_TRUNC:
- /* round toward zero (truncate) */
- emit_insn (gen_insvsi_1 (reg, GEN_INT (0xc)));
- slot = SLOT_CW_TRUNC;
- break;
- case I387_CW_FLOOR:
- /* round down toward -oo */
- emit_insn (gen_insvsi_1 (reg, GEN_INT (0x4)));
- slot = SLOT_CW_FLOOR;
- break;
-
- case I387_CW_CEIL:
- /* round up toward +oo */
- emit_insn (gen_insvsi_1 (reg, GEN_INT (0x8)));
- slot = SLOT_CW_CEIL;
- break;
-
- case I387_CW_MASK_PM:
- /* mask precision exception for nearbyint() */
- emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0020)));
- slot = SLOT_CW_MASK_PM;
- break;
-
- default:
- gcc_unreachable ();
- }
-}
-
gcc_assert (slot < MAX_386_STACK_LOCALS);
new_mode = assign_386_stack_local (HImode, slot);
Re: [PATCH] [PR c++/84943] allow folding of array indexing indirect_ref
On Apr 2, 2018, Jason Merrill wrote:
> On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva wrote:
>> On Mar 30, 2018, Jason Merrill wrote:
>>
>>> I don't think we need this; if arg is overloaded, we take the
>>> type_unknown_p early exit, so the code lower down is always dealing
>>> with a single function.
>>
>> Aah, that's why it seemed to me that we had already resolved overloads
>> when we got there.
>>
>> As a bonus, I added the tf_conv test before another mark_used call I'd
>> missed in the previous patch.
> What if we check tf_conv in mark_used itself rather than at all the call
> sites?
There are other uses of mark_used, but presumably we want them all to
be more conservative under tf_conv, so... Here's what I'm testing. Ok
if it passes?
[PR c++/84943] mark function as used when taking its address
fn[0]() ICEd because we would fold the INDIRECT_REF used for the
array indexing while building the address for the call, after not
finding the decl hiding there at first. But the decl would be exposed
by the folding, and then lower layers would complain we had the decl,
after all, but it wasn't one of the artificial or special functions
that could be called without being marked as used.
This patch arranges for a FUNCTION_DECL to be marked as used when
taking its address, just like we already did when taking the address
of a static function to call it as a member function (i.e. using the
obj.fn() notation). However, we shouldn't mark functions as used when
just performing overload resolution, lest we might instantiate
templates we shouldn't, as in g++.dg/overload/template1.C, so we
adjust mark_used to return early when testing conversions.
for gcc/cp/ChangeLog
PR c++/84943
* typeck.c (cp_build_addr_expr_1): Mark FUNCTION_DECL as
used.
* decl2.c (mark_used): Return without effects if tf_conv.
for gcc/testsuite/ChangeLog
PR c++/84943
* g++.dg/pr84943.C: New.
* g++.dg/pr84943-2.C: New.
---
gcc/cp/decl2.c |6
gcc/cp/typeck.c |3 ++
gcc/testsuite/g++.dg/pr84943-2.C | 64 ++
gcc/testsuite/g++.dg/pr84943.C |8 +
4 files changed, 81 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/pr84943-2.C
create mode 100644 gcc/testsuite/g++.dg/pr84943.C
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index fa753749e1a6..740e85b35617 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -5201,6 +5201,12 @@ maybe_instantiate_decl (tree decl)
bool
mark_used (tree decl, tsubst_flags_t complain)
{
+ /* If we're just testing conversions or resolving overloads, we
+ don't want any permanent effects like forcing functions to be
+ output or instantiating templates. */
+ if ((complain & tf_conv))
+return false;
+
/* If DECL is a BASELINK for a single function, then treat it just
like the DECL for the function. Otherwise, if the BASELINK is
for an overloaded function, we don't know which function was
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index d454c6c5a295..bd67b82fcc65 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5971,6 +5971,9 @@ cp_build_addr_expr_1 (tree arg, bool strict_lvalue,
tsubst_flags_t complain)
so we can just form an ADDR_EXPR with the correct type. */
if (processing_template_decl || TREE_CODE (arg) != COMPONENT_REF)
{
+ if (TREE_CODE (arg) == FUNCTION_DECL
+ && !mark_used (arg, complain) && !(complain & tf_error))
+ return error_mark_node;
val = build_address (arg);
if (TREE_CODE (arg) == OFFSET_REF)
PTRMEM_OK_P (val) = PTRMEM_OK_P (arg);
diff --git a/gcc/testsuite/g++.dg/pr84943-2.C b/gcc/testsuite/g++.dg/pr84943-2.C
new file mode 100644
index ..d1ef012b9155
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr84943-2.C
@@ -0,0 +1,64 @@
+// { dg-do run }
+
+// Avoid -pedantic-error default
+// { dg-options "" }
+
+// Make sure the functions referenced by various forms of
+// address-taking are marked as used and compiled in.
+
+static void ac() {}
+void a() {
+ ac[0](); // { dg-warning "arithmetic" }
+}
+
+static void bc() {}
+void b() {
+ (&*&*&*&bc)();
+}
+
+template U cc() {}
+void (*c())() {
+ return cc;
+}
+
+template
+struct x {
+ void a(int);
+ template static U a(x*) {}
+ static void a(long) {}
+ static void a(void *) {}
+ static void a() {
+void (*p0)(void*) = x().a;
+p0(0);
+void (*p1)(long) = a;
+p1(0);
+void (*p2)() = a;
+p2();
+void (*p3)(x*) = a;
+p3(0);
+ }
+};
+
+struct z {
+ void a(int);
+ template static U a(z*) {}
+ static void a(long) {}
+ static void a(void *) {}
+ static void a() {
+void (*p0)(void*) = z().a;
+p0(0);
+void (*p1)(long) = a;
+p1(0);
+void (*p2)() = a;
+p2();
+void (*p3)(z*) = a;
+p3(0);
+ }
+};
+
+int main(int argc, char *argv[]) {
+ if (argc > 1) {
+x().a();
+z().a();
+ }
+}
diff --git a/gcc/testsuite/g++.dg/
Re: [PATCH] [PR c++/84979] improve auto handling in explicit tmpl args for concepts
On Apr 2, 2018, Jason Merrill wrote:
> On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
>> On Mar 30, 2018, Jason Merrill wrote:
>> template
>> void foo(T t) {
>> typename T::template C u = t;
>> T::template C (t);
>> T::template C::f (t, u);
>> }
> We should be able to distinguish those cases based on tag_type.
Uhh... I don't see how.
I mean, yeah, if we see typename or any other tag first, tag_type will
tell us we must find types for anything template-like, be it an
intermediate scope or the final typename.
However, if we see 'T::template C (t)', we can't tell whether T::C
is a template class and we're "calling a constructor" to create a
temporary out of t, or T::C is a static member template function that's
being called with t as an argument. (ok, we know from the typename line
that C is a type, but nevermind that, it could be a different name in
the testcase, and then we wouldn't; heck, couldn't it even be a template
function hiding the template class of the same name?)
And then, while we're parsing "template C", we haven't yet reached
the '::' after the closing angle bracket that would tell us to regard
the id necessarily as a typename, so I don't see how we'd get a
scope_type in tag_type for the third case.
--
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] [PR c++/85039] no type definitions in builtin offsetof
On Apr 2, 2018, Jason Merrill wrote:
> On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva wrote:
>> struct a {
>> static int const z, i = __builtin_offsetof(struct b { int j; }, j);
>> b c;
>> };
>> int const a::z = __builtin_offsetof(struct d { int k; }, k);
>> d e;
>> Since d is visible, I suppose the most conservative solution would be to
>> name the global namespace as the context for type d, rather than
>> defining it as a member of a. Right?
> The global namespace would be a rather arbitrary choice; it seems to
> me that using the current scope is a natural interpretation.
> About d in the example, I'm not sure how you mean the global namespace
> is the current scope; we should be pushed into a when parsing the
> initializer for a::z.
I was just describing observed behavior. The code above compiles.
The explanation is in do_pushtag. It starts with a loop that, among
other things, skips COMPLETE_TYPE_P class scopes. we then record the
new type in the namespace named by the resulting scope. As the comment
says, this is meant to allow for types to be introduced in initializers
of static data members in spite of the class being already complete.
The problem, as I see it, is that we don't adjust the context to match,
so we introduce the type in one scope, but claim it to belong to
another. Which sort of works for named types, but comes down in flames
(err, reenters like Tiangong-1? ;-) if the type is anonymous.
> But I would think we should reject the definition of d because a is
> already complete, so it's too late to add members to it.
The existing code in GCC sort of disagrees with your proposal, so, for
the sake of avoiding breaking code that we used to compile (like the
definition 'd e' above), I'll insist on something along the lines of the
following patch:
[PR c++/85039] adjust context of new types in member initializers
Types defined in data member initializers of completed classes are
defined inconsistently: the context of the type and decl are set up so
that they seem to be members of the class containing the data member,
but the type decl is recorded in the enclosing namespace.
This is not a problem for named types, but anonymous types that have a
classtype as their context need to be able to find themselves in the
field list of the context type to be assigned an anon type count for
its mangled name.
This patch arranges for the context recorded in the type to match the
context in which its definition is introduced. This preserves
intentional preexisting behavior for named types introduced in data
member initializers.
for gcc/cp/ChangeLog
PR c++/85039
* name-lookup.c (do_pushtag): Make context match scope for
types introduced in data member initializers of completed
classes.
for gcc/testsuite/ChangeLog
PR c++/85039
* g++.dg/pr85039-1.C: New.
* g++.dg/pr85039-2.C: New.
* g++.dg/pr85039-3.C: New.
---
gcc/cp/name-lookup.c | 17 ++---
gcc/testsuite/g++.dg/pr85039-1.C | 17 +
gcc/testsuite/g++.dg/pr85039-2.C | 10 ++
gcc/testsuite/g++.dg/pr85039-3.C | 13 +
4 files changed, 54 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/pr85039-1.C
create mode 100644 gcc/testsuite/g++.dg/pr85039-2.C
create mode 100644 gcc/testsuite/g++.dg/pr85039-3.C
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 061729a989b6..97618d414edd 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -6394,9 +6394,10 @@ do_pushtag (tree name, tree type, tag_scope scope)
|| (b->kind == sk_class
&& (scope != ts_current
/* We may be defining a new type in the initializer
- of a static member variable. We allow this when
- not pedantic, and it is particularly useful for
- type punning via an anonymous union. */
+ of a static member variable. We allow this for
+ __builtin_offsetof, and when not pedantic, and it
+ is particularly useful for type punning via an
+ anonymous union. */
|| COMPLETE_TYPE_P (b->this_entity
b = b->level_chain;
@@ -6422,6 +6423,16 @@ do_pushtag (tree name, tree type, tag_scope scope)
containing the local class, not the namespace
scope. */
context = decl_function_context (get_type_decl (cs));
+
+ /* We may be defining a new type in the initializer of a
+static member variable. We allow this for
+__builtin_offsetof, and also when not pedantic, and it is
+particularly useful for type punning via an anonymous
+union. */
+ while (context && TYPE_P (context)
+&& scope == ts_current
+&& COMPLETE_TYPE_P (context))
+ context = TYPE_CONTEXT (context);
}
if (!c
Re: [patch, libgomp testsuite] Replace non-standard call abort by STOP n
On 03/25/2018 04:30 PM, Thomas Koenig wrote: [This is take two, the first one was rejected due to size]. Hello world, the does what the ChangeLog and the Subject say. Regression-tested on x86_64-pc-linux-gnu. FTR, this caused PR85166 - "[nvptx, libgfortran] Libgomp fortran tests using stop in offloaded fns fail to compile" ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85166 ) Thanks, - Tom OK for trunk? Regards Thomas 2018-03-25 Thomas Koenig PR fortran/84381 * testsuite/libgomp.fortran/aligned1.f03: Replace non-standard call abort by STOP n. * testsuite/libgomp.fortran/alloc-comp-1.f90: Likewise. * testsuite/libgomp.fortran/alloc-comp-2.f90: Likewise. * testsuite/libgomp.fortran/alloc-comp-3.f90: Likewise. * testsuite/libgomp.fortran/allocatable1.f90: Likewise. * testsuite/libgomp.fortran/allocatable10.f90: Likewise. * testsuite/libgomp.fortran/allocatable11.f90: Likewise. * testsuite/libgomp.fortran/allocatable12.f90: Likewise. * testsuite/libgomp.fortran/allocatable2.f90: Likewise. * testsuite/libgomp.fortran/allocatable3.f90: Likewise. * testsuite/libgomp.fortran/allocatable4.f90: Likewise. * testsuite/libgomp.fortran/allocatable5.f90: Likewise. * testsuite/libgomp.fortran/allocatable6.f90: Likewise. * testsuite/libgomp.fortran/allocatable7.f90: Likewise. * testsuite/libgomp.fortran/allocatable8.f90: Likewise. * testsuite/libgomp.fortran/allocatable9.f90: Likewise. * testsuite/libgomp.fortran/appendix-a/a.18.1.f90: Likewise. * testsuite/libgomp.fortran/appendix-a/a.19.1.f90: Likewise. * testsuite/libgomp.fortran/associate1.f90: Likewise. * testsuite/libgomp.fortran/associate2.f90: Likewise. * testsuite/libgomp.fortran/associate3.f90: Likewise. * testsuite/libgomp.fortran/cancel-do-1.f90: Likewise. * testsuite/libgomp.fortran/cancel-do-2.f90: Likewise. * testsuite/libgomp.fortran/cancel-parallel-1.f90: Likewise. * testsuite/libgomp.fortran/cancel-sections-1.f90: Likewise. * testsuite/libgomp.fortran/cancel-taskgroup-2.f90: Likewise. * testsuite/libgomp.fortran/character1.f90: Likewise. * testsuite/libgomp.fortran/character2.f90: Likewise. * testsuite/libgomp.fortran/collapse1.f90: Likewise. * testsuite/libgomp.fortran/collapse2.f90: Likewise. * testsuite/libgomp.fortran/collapse3.f90: Likewise. * testsuite/libgomp.fortran/collapse4.f90: Likewise. * testsuite/libgomp.fortran/crayptr1.f90: Likewise. * testsuite/libgomp.fortran/crayptr2.f90: Likewise. * testsuite/libgomp.fortran/crayptr3.f90: Likewise. * testsuite/libgomp.fortran/declare-simd-1.f90: Likewise. * testsuite/libgomp.fortran/declare-simd-3.f90: Likewise. * testsuite/libgomp.fortran/declare-target-2.f90: Likewise. * testsuite/libgomp.fortran/depend-1.f90: Likewise. * testsuite/libgomp.fortran/depend-2.f90: Likewise. * testsuite/libgomp.fortran/depend-3.f90: Likewise. * testsuite/libgomp.fortran/do1.f90: Likewise. * testsuite/libgomp.fortran/do2.f90: Likewise. * testsuite/libgomp.fortran/doacross1.f90: Likewise. * testsuite/libgomp.fortran/doacross2.f90: Likewise. * testsuite/libgomp.fortran/doacross3.f90: Likewise. * testsuite/libgomp.fortran/examples-4/array_sections-3.f90: Likewise. * testsuite/libgomp.fortran/examples-4/array_sections-4.f90: Likewise. * testsuite/libgomp.fortran/examples-4/async_target-1.f90: Likewise. * testsuite/libgomp.fortran/examples-4/async_target-2.f90: Likewise. * testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Likewise. * testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Likewise. * testsuite/libgomp.fortran/examples-4/declare_target-3.f90: Likewise. * testsuite/libgomp.fortran/examples-4/declare_target-4.f90: Likewise. * testsuite/libgomp.fortran/examples-4/declare_target-5.f90: Likewise. * testsuite/libgomp.fortran/examples-4/device-1.f90: Likewise. * testsuite/libgomp.fortran/examples-4/device-2.f90: Likewise. * testsuite/libgomp.fortran/examples-4/device-3.f90: Likewise. * testsuite/libgomp.fortran/examples-4/simd-1.f90: Likewise. * testsuite/libgomp.fortran/examples-4/simd-2.f90: Likewise. * testsuite/libgomp.fortran/examples-4/simd-3.f90: Likewise. * testsuite/libgomp.fortran/examples-4/simd-4.f90: Likewise. * testsuite/libgomp.fortran/examples-4/simd-5.f90: Likewise. * testsuite/libgomp.fortran/examples-4/simd-6.f90: Likewise. * testsuite/libgomp.fortran/examples-4/simd-7.f90: Likewise. * testsuite/libgomp.fortran/examples-4/simd-8.f90: Likewise. * testsuite/libgomp.fortran/examples-4/target-1.f90: Likewise. * testsuite/libgomp.fortran/examples-4/target-2.f90: Likewise. * testsuite/libgomp.fortran/examples-4/target-3.f90: Likewise. * testsuite/libgomp.fortran/examples-4/target-4.f90: Likewise. * testsuit
[C++ Patch] ("[7/8 Regression] ICE with failed class template argument deduction because of invalid template parameter")
Hi,
the reason why we ICE here is very simple: we pass an error_mark_node
generated in cp_parser_template_parameter_list to rewrite_template_parm
which ICEs (via get_template_parm_index). I believe it makes sense to
robustify the latter like all the other functions involved in
build_deduction_guide. The next, error recovery quality, issue is
whether or not we still want to produce diagnostic about class template
argument deduction failing: today I noticed - somewhat surprisingly -
that some compilers still do that (however the diagnostic is more terse:
eg, one additional error and two notes, not two errors and five notes!).
I had tested the below which suppresses those additional errors by
returning error_mark_node from build_deduction_guide if one of those
parsing-time error_mark_nodes is encountered in the
build_deduction_guide loop - and lays out a bit of infrastructure.
Tested x86_64-linux.
Thanks, Paolo.
/cp
2018-04-03 Paolo Carlini
PR c++/84768
* pt.c (rewrite_template_parm): If the first argument is
error_mark_node return it immediately.
(build_deduction_guide): Check the return value of the
latter for error_mark_node.
(do_class_deduction): Check the return value of the latter.
/testsuite
2018-04-03 Paolo Carlini
PR c++/84768
* g++.dg/cpp1z/class-deduction52.C: New.
Index: cp/pt.c
===
--- cp/pt.c (revision 258972)
+++ cp/pt.c (working copy)
@@ -25800,6 +25800,9 @@ static tree
rewrite_template_parm (tree olddecl, unsigned index, unsigned level,
tree tsubst_args, tsubst_flags_t complain)
{
+ if (olddecl == error_mark_node)
+return error_mark_node;
+
tree oldidx = get_template_parm_index (olddecl);
tree newtype;
@@ -25935,6 +25938,7 @@ build_deduction_guide (tree ctor, tree outer_args,
else
{
++processing_template_decl;
+ bool ok = true;
fn_tmpl
= (TREE_CODE (ctor) == TEMPLATE_DECL ? ctor
@@ -26005,6 +26009,8 @@ build_deduction_guide (tree ctor, tree outer_args,
tree olddecl = TREE_VALUE (oldelt);
tree newdecl = rewrite_template_parm (olddecl, index, level,
tsubst_args, complain);
+ if (newdecl == error_mark_node)
+ ok = false;
tree newdef = tsubst_template_arg (TREE_PURPOSE (oldelt),
tsubst_args, complain, ctor);
tree list = build_tree_list (newdef, newdecl);
@@ -26026,7 +26032,10 @@ build_deduction_guide (tree ctor, tree outer_args,
current_template_parms = save_parms;
}
+
--processing_template_decl;
+ if (!ok)
+ return error_mark_node;
}
if (!memtmpl)
@@ -26153,6 +26162,8 @@ do_class_deduction (tree ptype, tree tmpl, tree in
for (ovl_iterator iter (CLASSTYPE_CONSTRUCTORS (type)); iter; ++iter)
{
tree guide = build_deduction_guide (*iter, outer_args, complain);
+ if (guide == error_mark_node)
+ return error_mark_node;
if ((flags & LOOKUP_ONLYCONVERTING)
&& DECL_NONCONVERTING_P (STRIP_TEMPLATE (guide)))
elided = true;
@@ -26204,6 +26215,8 @@ do_class_deduction (tree ptype, tree tmpl, tree in
if (gtype)
{
tree guide = build_deduction_guide (gtype, outer_args, complain);
+ if (guide == error_mark_node)
+ return error_mark_node;
cands = lookup_add (guide, cands);
}
}
Index: testsuite/g++.dg/cpp1z/class-deduction52.C
===
--- testsuite/g++.dg/cpp1z/class-deduction52.C (nonexistent)
+++ testsuite/g++.dg/cpp1z/class-deduction52.C (working copy)
@@ -0,0 +1,11 @@
+// PR c++/84768
+// { dg-additional-options -std=c++17 }
+
+template struct A {};
+
+template struct B
+{
+ template B(A); // { dg-error "declared" }
+};
+
+B b = A();
Re: [documentation patch] add detail to const and pure attributes
On 04/02/2018 11:34 PM, Martin Sebor wrote:
> On 04/02/2018 12:09 AM, Sandra Loosemore wrote:
>> On 03/27/2018 03:21 PM, Pedro Alves wrote:
>>> On 03/27/2018 09:19 PM, Martin Sebor wrote:
On 03/27/2018 01:38 PM, Pedro Alves wrote:
> On 03/27/2018 07:18 PM, Martin Sebor wrote:
>> +Because a @code{pure} function can have no side-effects it does not
>
> FWIW, I'd suggest rephrasing as:
>
> Because a @code{pure} function cannot have side effects
>
> because "can have no side-effects" can be read as
> "is allowed to have no side effects", which gave me pause
> when I read it the first time, and is the opposite of
> what you mean.
That is what I meant: that const and pure functions are not allowed
to have any side-effects. If they did, they could be unexpectedly
eliminated (i.e., the behavior is undefined when such a function
does have a side-effect).
>>>
>>> I know, but that's not what I read the first time (and found it
>>> odd so I had to re-read). You can either assume that I'm the
>>> only one that will misunderstand it on first read, or you can
>>> swap a couple words and be sure no one will misunderstand it.
>>>
>>> Up to you.
>>
>> I'm chiming in a little late here, but I agree with Pedro that "can have
>> no side-effects" is confusing. I'd say "cannot have side effects" or
>> "must have no side effects" instead.
>
> There's nothing confusing about it. It's an established phrase
> with millions of uses and only one meaning. According to Google
> Books Ngram Viewer it's also more pervasive than either of
> the two suggested alternatives:
>
> http://goo.gl/FgXgwi
Sorry, but no. The different phrases have slightly different
meanings. The fact that one is used more often than than the other
does not imply that they have the same meaning, any more than this:
http://goo.gl/U64uDZ
shows that people nowadays say "red" more often when then
mean "blue".
Compare:
#1. The red pill can have no side effects. (If you're lucky. It's
not guaranteed. Buyer beware.)
#2. The blue pill cannot have side effects. (That's a guarantee.)
Those are different statements. #1 implies possibility, while #2
leaves no margin for error.
When you say that "a pure function can have no side effects",
that can be reasonably read as
a pure function may have no side effects if it chooses to,
i.e., it's not required to have side effects.
But, a pure function _must_ have no side effects. If a function has
side effects, then it no longer is a pure function, by definition.
That's what reads confusingly.
Your url actually proves the point. Follow the url at the bottom
of that page:
https://www.google.pt/search?q=%22can+have+no+effect%22&tbm=bks&lr=lang_en&gws_rd=cr&dcr=0&ei=NUPDWqqoPInxUqP8jPgN
And that leads to uses like:
"In many cases, a treatment can have no effect or can have the effect"
"the new grant can have no effect whatever, unless it have the effect"
etc., etc.
>
>> Also note that non-hyphenated "side effects" seems to be preferred usage
>> as a noun phrase (at least it's the only form listed by m-w.com).
>
> I'm all for using the preferred form. I've made the change here
> and submitted a separate patch to remove the hyphen from the rest
> of the occurrences.
>
> Attached is a changed patch that uses "cannot have side effects"
> instead of "can have no side effects."
Thank you. LGTM, FWIW.
Pedro Alves
[PR 84947] Bits propagation only for int and ptr types
Hi,
PR 84947 shows that when we LTO calls with type-mismatches, we can end
up doing undefined shifts because we try to work with precision of types
which do not have any.
Fixed basically in the same way as Martin proposed in Bugzilla, the patch
below also updates the comment and dump message to reflect that there is
another reason to bail out early.
LTO-bootstrapped and tested on x86_64-linux, OK for trunk?
Thanks,
Martin
2018-03-29 Martin Liska
Martin Jambor
PR ipa/84947
* ipa-cp.c (propagate_bits_across_jump_function): Bail out if
param_type is not an integral or pointer type.
---
gcc/ipa-cp.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index ee41a8d55b7..ec216010f2f 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1811,14 +1811,16 @@ propagate_bits_across_jump_function (cgraph_edge *cs,
int idx,
struct ipa_node_params *callee_info = IPA_NODE_REF (callee);
tree parm_type = ipa_get_type (callee_info, idx);
- /* For K&R C programs, ipa_get_type() could return NULL_TREE.
- Avoid the transform for these cases. */
- if (!parm_type)
+ /* For K&R C programs, ipa_get_type() could return NULL_TREE. Avoid the
+ transform for these cases. Similarly, we can have bad type mismatches
+ with LTO, avoid doing anything with those too. */
+ if (!parm_type
+ || (!INTEGRAL_TYPE_P (parm_type) && !POINTER_TYPE_P (parm_type)))
{
if (dump_file && (dump_flags & TDF_DETAILS))
- fprintf (dump_file, "Setting dest_lattice to bottom, because"
- " param %i type is NULL for %s\n", idx,
- cs->callee->name ());
+ fprintf (dump_file, "Setting dest_lattice to bottom, because type of "
+"param %i of %s is NULL or unsuitable for bits propagation\n",
+idx, cs->callee->name ());
return dest_lattice->set_to_bottom ();
}
--
2.16.2
Re: [PATCH, rs6000] Undefine vector, bool, pixel in xmmintrin.h
Hi Bill, On Sun, Apr 01, 2018 at 08:24:32PM -0500, Bill Schmidt wrote: > * gcc.target/powerpc/undef-bool.C: New file. > * gcc.target/powerpc/undef-bool.c: New file. I'm not sure two files with the same basename will not cause problems. In either case it is confusing. Please rename one? > --- gcc/config/rs6000/xmmintrin.h (revision 258958) > +++ gcc/config/rs6000/xmmintrin.h (working copy) > @@ -58,6 +58,18 @@ > #define _XMMINTRIN_H_INCLUDED > > #include > + > +/* Avoid collisions between altivec.h and strict adherence to C++ and > + C11 standards. This should eventually be done inside altivec.h itself, > + but only after testing a full distro build. */ > +#if defined(__STRICT_ANSI__) && (defined(__cplusplus) || \ > + (defined(__STDC_VERSION__) && \ > + __STDC_VERSION__ >= 201112L)) > +#undef vector > +#undef pixel > +#undef bool > +#endif This won't work if anything made a macro for bool (etc.) before including this header. I guess we can live with that for now (it will not work without your patch either). Okay for trunk (with the testcase name fix). Thanks! Segher
[PATCH] Fix PR85154
Committed.
Richard.
2018-04-03 Richard Biener
PR testsuite/85154
* gcc.dg/vect/vect-95.c: Remove scan for alignment peeling.
Index: gcc/testsuite/gcc.dg/vect/vect-95.c
===
--- gcc/testsuite/gcc.dg/vect/vect-95.c (revision 259024)
+++ gcc/testsuite/gcc.dg/vect/vect-95.c (working copy)
@@ -55,9 +55,6 @@ int main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
-/* { dg-final { scan-tree-dump-times "Alignment of access forced using
peeling" 0 "vect" } } */
-
/* For targets that support unaligned loads we version for the two unaligned
stores and generate misaligned accesses for the loads. For targets that
don't support unaligned loads we version for all four accesses. */
Re: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)]
On Fri, 30 Mar 2018, Peter Bergner wrote: > On 3/29/18 9:35 AM, Alan Modra wrote: > > On Thu, Nov 16, 2017 at 03:27:01PM +, Tamar Christina wrote: > >> --- a/gcc/expr.c > >> +++ b/gcc/expr.c > >> @@ -2769,7 +2769,9 @@ copy_blkmode_to_reg (machine_mode mode, tree src) > >> > >>n_regs = (bytes + UNITS_PER_WORD - 1) / UNITS_PER_WORD; > >>dst_words = XALLOCAVEC (rtx, n_regs); > >> - bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > >> + bitsize = BITS_PER_WORD; > >> + if (targetm.slow_unaligned_access (word_mode, TYPE_ALIGN (TREE_TYPE > >> (src > >> +bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > >> > >>/* Copy the structure BITSIZE bits at a time. */ > >>for (bitpos = 0, xbitpos = padding_correction; > > > > I believe this patch is wrong. Please revert. See the PR84762 testcase. > > > > There are two problems. Firstly, if padding_correction is non-zero, > > then xbitpos % BITS_PER_WORD is non-zero and in > > > > store_bit_field (dst_word, bitsize, xbitpos % BITS_PER_WORD, > >0, 0, word_mode, > >extract_bit_field (src_word, bitsize, > > bitpos % BITS_PER_WORD, 1, > > NULL_RTX, word_mode, word_mode, > > false, NULL), > >false); > > > > the stored bit-field exceeds the destination register size. You could > > fix that by making bitsize the gcd of bitsize and padding_correction. > > > > However, that doesn't fix the second problem which is that the > > extracted bit-field can exceed the source size. That will result in > > rubbish being read into a register. > > FYI, I received an automated response saying Tamar is away on vacation > with no return date specified. That means he won't be able to revert > the patch. What do we do now? The code before the change already looks fishy to me. x = expand_normal (src); so what do we expect this to expand to in general? Fortunately it seems there are exactly two callers so hopefully a gcc_assert (MEM_P (x)) would work? The fishy part is looking at TYPE_ALIGN (TREE_TYPE (src)). In case x is a MEM we should use MEM_ALIGN and if not then we shouldn't do anything but just use word_mode here.
Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof
On 04/02/2018 06:18 PM, Jason Merrill wrote: About d in the example, I'm not sure how you mean the global namespace is the current scope; we should be pushed into a when parsing the initializer for a::z. this may be related to the brokenness I encountered in 85046. We push member structs into the wrong binding level. And there's this in name-lookup.c: do_pushtag: && (scope != ts_current /* We may be defining a new type in the initializer of a static member variable. We allow this when not pedantic, and it is particularly useful for type punning via an anonymous union. */ || COMPLETE_TYPE_P (b->this_entity But I would think we should reject the definition of d because a is already complete, so it's too late to add members to it. Agreed. -- Nathan Sidwell
[wwwdocs] gcc-8/changes.html
Hello.
I would like to document features I prepared in time frame of GCC 8.
Martin
Index: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.51
diff --unified -r1.51 changes.html
--- htdocs/gcc-8/changes.html 3 Apr 2018 06:52:04 - 1.51
+++ htdocs/gcc-8/changes.html 3 Apr 2018 11:13:31 -
@@ -113,6 +113,93 @@
possible for the user to have a finer-grained control over the loop
unrolling optimization.
+
+GCOV tool can distinguish functions that begin on a same line in
+a source file. This can be a different template instantiation or
+a class constructor:
+
+File 'ins.C'
+Lines executed:100.00% of 8
+Creating 'ins.C.gcov'
+
+-:0:Source:ins.C
+-:0:Graph:ins.gcno
+-:0:Data:ins.gcda
+-:0:Runs:1
+-:0:Programs:1
+-:1:template
+-:2:class Foo
+-:3:{
+-:4: public:
+2:5: Foo(): b (1000) {}
+--
+Foo::Foo():
+1:5: Foo(): b (1000) {}
+--
+Foo::Foo():
+1:5: Foo(): b (1000) {}
+--
+2:6: void inc () { b++; }
+--
+Foo::inc():
+1:6: void inc () { b++; }
+--
+Foo::inc():
+1:6: void inc () { b++; }
+--
+-:7:
+-:8: private:
+-:9: int b;
+-: 10:};
+-: 11:
+1: 12:int main(int argc, char **argv)
+-: 13:{
+1: 14: Foo a;
+1: 15: Foo b;
+-: 16:
+1: 17: a.inc ();
+1: 18: b.inc ();
+1: 19:}
+
+
+ GCOV has more accurate numbers for execution of source line executions.
+ GCOV tool can use TERM colors to provide more readable output.
+ AddressSanitizer gained a new pair of sanitization options,
+ -fsanitize=pointer-compare and -fsanitize=pointer-subtract, which
+ warn about subtraction (or comparison) of pointers that point to
+ a different memory object:
+
+int
+main ()
+{
+ /* Heap allocated memory. */
+ char *heap1 = (char *)__builtin_malloc (42);
+ char *heap2 = (char *)__builtin_malloc (42);
+ if (heap1 > heap2)
+ return 1;
+
+ return 0;
+}
+
+==17465==ERROR: AddressSanitizer: invalid-pointer-pair: 0x60400010 0x60400050
+#0 0x40070f in main /tmp/pointer-compare.c:7
+#1 0x76a72a86 in __libc_start_main (/lib64/libc.so.6+0x21a86)
+#2 0x400629 in _start (/tmp/a.out+0x400629)
+
+0x60400010 is located 0 bytes inside of 42-byte region [0x60400010,0x6040003a)
+allocated by thread T0 here:
+#0 0x76efb390 in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cc:86
+#1 0x4006ea in main /tmp/pointer-compare.c:5
+#2 0x76a72a86 in __libc_start_main (/lib64/libc.so.6+0x21a86)
+
+0x60400050 is located 0 bytes inside of 42-byte region [0x60400050,0x6040007a)
+allocated by thread T0 here:
+#0 0x76efb390 in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cc:86
+#1 0x4006f8 in main /tmp/pointer-compare.c:6
+#2 0x76a72a86 in __libc_start_main (/lib64/libc.so.6+0x21a86)
+
+SUMMARY: AddressSanitizer: invalid-pointer-pair /tmp/pointer-compare.c:7 in main
+
@@ -187,7 +274,9 @@
C++
-
+ Having a non-void function that does not return a value is considered as
+undefined behavior. The compiler considers such code as unreachable and
+makes more aggressive optimizations based on that.
Fortran
[PATCH] Remove no longer used recompute_all_dominators
Committed.
Richard.
2018-04-03 Richard Biener
* sese.h (recompute_all_dominators): Remove.
Index: gcc/sese.h
===
--- gcc/sese.h (revision 259024)
+++ gcc/sese.h (working copy)
@@ -228,19 +228,6 @@ if_region_get_condition_block (ifsese if
return if_region_entry (if_region)->dest;
}
-/* Free and compute again all the dominators information. */
-
-static inline void
-recompute_all_dominators (void)
-{
- mark_irreducible_loops ();
- free_dominance_info (CDI_DOMINATORS);
- calculate_dominance_info (CDI_DOMINATORS);
-
- free_dominance_info (CDI_POST_DOMINATORS);
- calculate_dominance_info (CDI_POST_DOMINATORS);
-}
-
typedef std::pair scalar_use;
typedef struct gimple_poly_bb
Re: [PATCH, PR84660] Fix combine bug with SHIFT_COUNT_TRUNCATED.
On Tue, Apr 3, 2018 at 12:48 AM, Jim Wilson wrote: > On Fri, Mar 23, 2018 at 5:33 AM, Richard Biener > wrote: >> I'm leaving the "simple" combiner patch to review by others >> but for RISC-V you could simply #define SHIFT_COUNT_TRUNCATED to zero >> to fix the issue. Then add patterns if it turns out to be required >> to avoid regressions. For example x86 has > > I checked in a patch to do this. It took me quite a few iterations to > work out how to do it without regressions, but it looks OK in the end. > 6 additional patterns and changing the shift count mode to QImode in > all existing shift patterns and I get effectively the same code as > before with SHIFT_COUNT_TRUNCATED turned off. With DImode shift > counts, I ran into problems with unnecessary sign/zero extensions from > SImode for shift counts. With SImode shift counts, I ran into > problems with unnecessary truncations from DImode. Using QImode shift > counts avoided both of those problems. > > That leaves the other targets still using SHIFT_COUNT_TRUNCATED as > potentially broken. I count 16 of them. Though this particular > testcase might not be triggerable on most of them, since it requires > shift patterns for two different modes, and most 32-bit targets > probably only have one mode that shift is supported for. Thanks a lot for going this route for fixing. I only count the sparc as important platform unconditionally defining it to 1, the rest is weird embedded targets or targest with at least one mode where it is set to zero. OK, maybe add mips to the list of targets. So I'd be happy to just kill it off early during GCC 9 development... But I guess I proposed this before and people weren't entirely happy. Richard. > Jim
[PATCH] rs6000: Fix testcase pr82015.c
It used "vector" but that is not defined. Let's use __vector instead.
Committed.
Segher
2018-04-03 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/pr82015.c: Use __vector instead of vector.
---
gcc/testsuite/gcc.target/powerpc/pr82015.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr82015.c
b/gcc/testsuite/gcc.target/powerpc/pr82015.c
index c8b53b8..ec939e9 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr82015.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr82015.c
@@ -3,12 +3,12 @@
/* { dg-require-effective-target powerpc_vsx_ok } */
/* { dg-options "-O2 -mvsx" } */
-unsigned long foo_11(vector __int128_t *p)
+unsigned long foo_11(__vector __int128_t *p)
{
return __builtin_unpack_vector_int128(*p, 11); /* { dg-error "argument 2
must be a 1-bit unsigned literal" } */
}
-unsigned long foo_n(vector __int128_t *p, unsigned long n)
+unsigned long foo_n(__vector __int128_t *p, unsigned long n)
{
return __builtin_unpack_vector_int128(*p, n);/* { dg-error "argument
2 must be a 1-bit unsigned literal" } */
}
--
1.8.3.1
Re: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)]
On Tue, Apr 03, 2018 at 01:01:23PM +0200, Richard Biener wrote: > On Fri, 30 Mar 2018, Peter Bergner wrote: > > > On 3/29/18 9:35 AM, Alan Modra wrote: > > > On Thu, Nov 16, 2017 at 03:27:01PM +, Tamar Christina wrote: > > >> --- a/gcc/expr.c > > >> +++ b/gcc/expr.c > > >> @@ -2769,7 +2769,9 @@ copy_blkmode_to_reg (machine_mode mode, tree src) > > >> > > >>n_regs = (bytes + UNITS_PER_WORD - 1) / UNITS_PER_WORD; > > >>dst_words = XALLOCAVEC (rtx, n_regs); > > >> - bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > > >> + bitsize = BITS_PER_WORD; > > >> + if (targetm.slow_unaligned_access (word_mode, TYPE_ALIGN (TREE_TYPE > > >> (src > > >> +bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > > >> > > >>/* Copy the structure BITSIZE bits at a time. */ > > >>for (bitpos = 0, xbitpos = padding_correction; > > > > > > I believe this patch is wrong. Please revert. See the PR84762 testcase. > > > > > > There are two problems. Firstly, if padding_correction is non-zero, > > > then xbitpos % BITS_PER_WORD is non-zero and in > > > > > > store_bit_field (dst_word, bitsize, xbitpos % BITS_PER_WORD, > > > 0, 0, word_mode, > > > extract_bit_field (src_word, bitsize, > > > bitpos % BITS_PER_WORD, 1, > > > NULL_RTX, word_mode, word_mode, > > > false, NULL), > > > false); > > > > > > the stored bit-field exceeds the destination register size. You could > > > fix that by making bitsize the gcd of bitsize and padding_correction. > > > > > > However, that doesn't fix the second problem which is that the > > > extracted bit-field can exceed the source size. That will result in > > > rubbish being read into a register. > > > > FYI, I received an automated response saying Tamar is away on vacation > > with no return date specified. That means he won't be able to revert > > the patch. What do we do now? > > The code before the change already looks fishy to me. Yes, it is fishy so far as the code in the loop relies on alignment determining a small enough bitsize. Adding if (bytes % UNITS_PER_WORD != 0) bitsize = gcd (bitsize, (bytes % UNITS_PER_WORD) * BITS_PER_UNIT); after bitsize is calculated from alignment would make the code correct, I believe. But I think that will fail the testcase Tamar added. > x = expand_normal (src); > > so what do we expect this to expand to in general? Fortunately > it seems there are exactly two callers so hopefully a > gcc_assert (MEM_P (x)) would work? > > The fishy part is looking at TYPE_ALIGN (TREE_TYPE (src)). > > In case x is a MEM we should use MEM_ALIGN and if not then we > shouldn't do anything but just use word_mode here. No! You can't use a bitsize of BITS_PER_WORD here. See the code I quoted above. -- Alan Modra Australia Development Lab, IBM
[PATCH] Add -C when using -Wimplicit-fallthrough and --save-temps (PR preprocessor/78497).
Hi.
This helps the warning with --save-temps. Doing that one needs to preserve
comments
in preprocessed source file.
Ready for trunk?
Martin
gcc/ChangeLog:
2018-04-03 Martin Liska
PR preprocessor/78497
* gcc.c: Add -C when using -Wimplicit-fallthrough and --save-temps.
gcc/testsuite/ChangeLog:
2018-04-03 Martin Liska
PR preprocessor/78497
* c-c++-common/Wimplicit-fallthrough-37.c: New test.
---
gcc/gcc.c | 3 ++-
.../c-c++-common/Wimplicit-fallthrough-37.c| 22 ++
2 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
diff --git a/gcc/gcc.c b/gcc/gcc.c
index a716f708259..f641c249e27 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1131,7 +1131,8 @@ static const char *cpp_options =
"%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w}\
%{f*} %{g*:%{%:debug-level-gt(0):%{g*}\
%{!fno-working-directory:-fworking-directory}}} %{O*}\
- %{undef} %{save-temps*:-fpch-preprocess}";
+ %{undef} %{save-temps*:-fpch-preprocess}\
+ %{Wimplicit-fallthrough*|Werror=implicit-fallthrough*:%{save-temps*:-C}}";
/* This contains cpp options which are not passed when the preprocessor
output will be used by another program. */
diff --git a/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c b/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
new file mode 100644
index 000..ca9d21fc70e
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
@@ -0,0 +1,22 @@
+/* PR preprocessor/78497 */
+/* { dg-do compile } */
+/* { dg-options "-Wimplicit-fallthrough --save-temps" } */
+
+int main (int argc, char **argv)
+{
+ int a;
+ switch (argc)
+{
+case 1:
+ a = 1;
+ break;
+case 2:
+ a = 2;
+ /* FALLTHROUGH */
+case 3:
+ a = 3;
+ break;
+}
+
+ return a;
+}
Re: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)]
On Tue, 3 Apr 2018, Alan Modra wrote: > On Tue, Apr 03, 2018 at 01:01:23PM +0200, Richard Biener wrote: > > On Fri, 30 Mar 2018, Peter Bergner wrote: > > > > > On 3/29/18 9:35 AM, Alan Modra wrote: > > > > On Thu, Nov 16, 2017 at 03:27:01PM +, Tamar Christina wrote: > > > >> --- a/gcc/expr.c > > > >> +++ b/gcc/expr.c > > > >> @@ -2769,7 +2769,9 @@ copy_blkmode_to_reg (machine_mode mode, tree src) > > > >> > > > >>n_regs = (bytes + UNITS_PER_WORD - 1) / UNITS_PER_WORD; > > > >>dst_words = XALLOCAVEC (rtx, n_regs); > > > >> - bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > > > >> + bitsize = BITS_PER_WORD; > > > >> + if (targetm.slow_unaligned_access (word_mode, TYPE_ALIGN (TREE_TYPE > > > >> (src > > > >> +bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > > > >> > > > >>/* Copy the structure BITSIZE bits at a time. */ > > > >>for (bitpos = 0, xbitpos = padding_correction; > > > > > > > > I believe this patch is wrong. Please revert. See the PR84762 > > > > testcase. > > > > > > > > There are two problems. Firstly, if padding_correction is non-zero, > > > > then xbitpos % BITS_PER_WORD is non-zero and in > > > > > > > > store_bit_field (dst_word, bitsize, xbitpos % BITS_PER_WORD, > > > >0, 0, word_mode, > > > >extract_bit_field (src_word, bitsize, > > > > bitpos % BITS_PER_WORD, 1, > > > > NULL_RTX, word_mode, > > > > word_mode, > > > > false, NULL), > > > >false); > > > > > > > > the stored bit-field exceeds the destination register size. You could > > > > fix that by making bitsize the gcd of bitsize and padding_correction. > > > > > > > > However, that doesn't fix the second problem which is that the > > > > extracted bit-field can exceed the source size. That will result in > > > > rubbish being read into a register. > > > > > > FYI, I received an automated response saying Tamar is away on vacation > > > with no return date specified. That means he won't be able to revert > > > the patch. What do we do now? > > > > The code before the change already looks fishy to me. > > Yes, it is fishy so far as the code in the loop relies on alignment > determining a small enough bitsize. Adding > > if (bytes % UNITS_PER_WORD != 0) > bitsize = gcd (bitsize, (bytes % UNITS_PER_WORD) * BITS_PER_UNIT); > > after bitsize is calculated from alignment would make the code > correct, I believe. But I think that will fail the testcase Tamar > added. > > > x = expand_normal (src); > > > > so what do we expect this to expand to in general? Fortunately > > it seems there are exactly two callers so hopefully a > > gcc_assert (MEM_P (x)) would work? > > > > The fishy part is looking at TYPE_ALIGN (TREE_TYPE (src)). > > > > In case x is a MEM we should use MEM_ALIGN and if not then we > > shouldn't do anything but just use word_mode here. > > No! You can't use a bitsize of BITS_PER_WORD here. See the code I > quoted above. Ah, so it should possibly use TYPE_SIZE instead of TYPE_ALIGN, otherwise it will handle the over-aligned case (align to 8 bytes, size 4 bytes) incorrectly as well? Richard.
[PATCH] Remove UBSAN in dwarf2out.c (PR tree-optimization/82491).
Hi.
This is second part of the UBSAN. Richard Sandiford help me to wrap the offset
into poly_uint64. The offset is neither logically signed nor logically unsigned.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2018-04-03 Martin Liska
PR tree-optimization/82491
* rtl.h (strip_offset_and_add): Replace += suboffset with
poly_uint64 () + suboffset.
---
gcc/rtl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/rtl.h b/gcc/rtl.h
index f31b4ade9d3..0341ba01614 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -4339,7 +4339,7 @@ strip_offset_and_add (rtx x, poly_int64_pod *offset)
{
poly_int64 suboffset;
x = strip_offset (x, &suboffset);
- *offset += suboffset;
+ *offset = poly_uint64 (*offset) + suboffset;
}
return x;
}
Re: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)]
Hi all, > I believe this patch is wrong. Please revert. See the PR84762 testcase. > I'm happy to revert it given the regression and GCC 8 release being imminent, but looking at the code again it seems to me that the original code may also not be fully correct? Particularly I'm wondering what happens if you overalign the struct. > There are two problems. Firstly, if padding_correction is non-zero, > then xbitpos % BITS_PER_WORD is non-zero and in > > store_bit_field (dst_word, bitsize, xbitpos % BITS_PER_WORD, > 0, 0, word_mode, > extract_bit_field (src_word, bitsize, > bitpos % BITS_PER_WORD, 1, > NULL_RTX, word_mode, word_mode, > false, NULL), > false); > > the stored bit-field exceeds the destination register size. You could > fix that by making bitsize the gcd of bitsize and padding_correction. > > However, that doesn't fix the second problem which is that the > extracted bit-field can exceed the source size. That will result in > rubbish being read into a register. Yes, this is because I misunderstood how extract_bit_field works, I had though that the word_mode was the size of the load and that the bitsize, bitpos is just used to determine the mask & shift. But it seems to do the load based on bitsize and word_mode is just the mode you want the results in? In which case, wouldn't just adjusting bitsize to be the largest size smaller than the number of bits we want to copy in each loop iteration work? alignment permitted. Regards, Tamar From: Alan Modra Sent: Tuesday, April 3, 2018 1:25 PM To: Richard Biener Cc: Peter Bergner; Tamar Christina; gcc-patches@gcc.gnu.org; nd; l...@redhat.com; i...@airs.com Subject: Re: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)] On Tue, Apr 03, 2018 at 01:01:23PM +0200, Richard Biener wrote: > On Fri, 30 Mar 2018, Peter Bergner wrote: > > > On 3/29/18 9:35 AM, Alan Modra wrote: > > > On Thu, Nov 16, 2017 at 03:27:01PM +, Tamar Christina wrote: > > >> --- a/gcc/expr.c > > >> +++ b/gcc/expr.c > > >> @@ -2769,7 +2769,9 @@ copy_blkmode_to_reg (machine_mode mode, tree src) > > >> > > >>n_regs = (bytes + UNITS_PER_WORD - 1) / UNITS_PER_WORD; > > >>dst_words = XALLOCAVEC (rtx, n_regs); > > >> - bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > > >> + bitsize = BITS_PER_WORD; > > >> + if (targetm.slow_unaligned_access (word_mode, TYPE_ALIGN (TREE_TYPE > > >> (src > > >> +bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > > >> > > >>/* Copy the structure BITSIZE bits at a time. */ > > >>for (bitpos = 0, xbitpos = padding_correction; > > > > > > I believe this patch is wrong. Please revert. See the PR84762 testcase. > > > > > > There are two problems. Firstly, if padding_correction is non-zero, > > > then xbitpos % BITS_PER_WORD is non-zero and in > > > > > > store_bit_field (dst_word, bitsize, xbitpos % BITS_PER_WORD, > > > 0, 0, word_mode, > > > extract_bit_field (src_word, bitsize, > > > bitpos % BITS_PER_WORD, 1, > > > NULL_RTX, word_mode, word_mode, > > > false, NULL), > > > false); > > > > > > the stored bit-field exceeds the destination register size. You could > > > fix that by making bitsize the gcd of bitsize and padding_correction. > > > > > > However, that doesn't fix the second problem which is that the > > > extracted bit-field can exceed the source size. That will result in > > > rubbish being read into a register. > > > > FYI, I received an automated response saying Tamar is away on vacation > > with no return date specified. That means he won't be able to revert > > the patch. What do we do now? > > The code before the change already looks fishy to me. Yes, it is fishy so far as the code in the loop relies on alignment determining a small enough bitsize. Adding if (bytes % UNITS_PER_WORD != 0) bitsize = gcd (bitsize, (bytes % UNITS_PER_WORD) * BITS_PER_UNIT); after bitsize is calculated from alignment would make the code correct, I believe. But I think that will fail the testcase Tamar added. > x = expand_normal (src); > > so what do we expect this to expand to in general? Fortunately > it seems there are exactly two callers so hopefully a > gcc_assert (MEM_P (x)) would work? > > The fishy part is looking at TYPE_ALIGN (TREE_TYPE (src)). > > In case x is a MEM we should use MEM_ALIGN and if not then we > shouldn't do anything but just use word_mode here. No! You can't use a bitsize of BITS_PER_WORD here. See the code I quoted above. -- Alan Modra Australia Development Lab, IBM From: R
Re: [PATCH][WWWDOCS][AArch64][ARM] Update GCC 8 release notes
Hi Gerald, Yes the Arm trademark is now "Arm" so that should be used when referring to anything related to the trademark. (see https://www.arm.com/company/policies/trademarks/guidelines-trademarks) I left the ARM there in reference to the port in GCC as that seems to be what we've always called it the changelogs. But I do see how that can be confusing... Kind Regards, Tamar From: Gerald Pfeifer Sent: Sunday, April 1, 2018 9:57:45 PM To: Tamar Christina Cc: gcc-patches@gcc.gnu.org; James Greenhalgh; Kyrill Tkachov; nd; Richard Earnshaw; Marcus Shawcroft; Ramana Radhakrishnan; ni...@redhat.com Subject: Re: [PATCH][WWWDOCS][AArch64][ARM] Update GCC 8 release notes On Tue, 16 Jan 2018, Tamar Christina wrote: > I seem to have forgotten the patch :) Ah, one thing I noticed is that you've used the spelling of "Arm" as opposed to "ARM" and even changed some of the former to the latter. Is "Arm" now the new official spelling that we should use consistently? gcc-8/changes.html still has two references to "ARM". Gerald
Re: [PR 84947] Bits propagation only for int and ptr types
On Tue, Apr 3, 2018 at 11:39 AM, Martin Jambor wrote:
> Hi,
>
> PR 84947 shows that when we LTO calls with type-mismatches, we can end
> up doing undefined shifts because we try to work with precision of types
> which do not have any.
>
> Fixed basically in the same way as Martin proposed in Bugzilla, the patch
> below also updates the comment and dump message to reflect that there is
> another reason to bail out early.
>
> LTO-bootstrapped and tested on x86_64-linux, OK for trunk?
OK.
Richard.
> Thanks,
>
> Martin
>
>
> 2018-03-29 Martin Liska
> Martin Jambor
>
> PR ipa/84947
> * ipa-cp.c (propagate_bits_across_jump_function): Bail out if
> param_type is not an integral or pointer type.
> ---
> gcc/ipa-cp.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index ee41a8d55b7..ec216010f2f 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -1811,14 +1811,16 @@ propagate_bits_across_jump_function (cgraph_edge *cs,
> int idx,
>struct ipa_node_params *callee_info = IPA_NODE_REF (callee);
>tree parm_type = ipa_get_type (callee_info, idx);
>
> - /* For K&R C programs, ipa_get_type() could return NULL_TREE.
> - Avoid the transform for these cases. */
> - if (!parm_type)
> + /* For K&R C programs, ipa_get_type() could return NULL_TREE. Avoid the
> + transform for these cases. Similarly, we can have bad type mismatches
> + with LTO, avoid doing anything with those too. */
> + if (!parm_type
> + || (!INTEGRAL_TYPE_P (parm_type) && !POINTER_TYPE_P (parm_type)))
> {
>if (dump_file && (dump_flags & TDF_DETAILS))
> - fprintf (dump_file, "Setting dest_lattice to bottom, because"
> - " param %i type is NULL for %s\n", idx,
> - cs->callee->name ());
> + fprintf (dump_file, "Setting dest_lattice to bottom, because type of "
> +"param %i of %s is NULL or unsuitable for bits
> propagation\n",
> +idx, cs->callee->name ());
>
>return dest_lattice->set_to_bottom ();
> }
> --
> 2.16.2
>
Re: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)]
On Tue, Apr 03, 2018 at 02:30:23PM +0200, Richard Biener wrote: > On Tue, 3 Apr 2018, Alan Modra wrote: > > > On Tue, Apr 03, 2018 at 01:01:23PM +0200, Richard Biener wrote: > > > On Fri, 30 Mar 2018, Peter Bergner wrote: > > > > > > > On 3/29/18 9:35 AM, Alan Modra wrote: > > > > > On Thu, Nov 16, 2017 at 03:27:01PM +, Tamar Christina wrote: > > > > >> --- a/gcc/expr.c > > > > >> +++ b/gcc/expr.c > > > > >> @@ -2769,7 +2769,9 @@ copy_blkmode_to_reg (machine_mode mode, tree > > > > >> src) > > > > >> > > > > >>n_regs = (bytes + UNITS_PER_WORD - 1) / UNITS_PER_WORD; > > > > >>dst_words = XALLOCAVEC (rtx, n_regs); > > > > >> - bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > > > > >> + bitsize = BITS_PER_WORD; > > > > >> + if (targetm.slow_unaligned_access (word_mode, TYPE_ALIGN > > > > >> (TREE_TYPE (src > > > > >> +bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)), BITS_PER_WORD); > > > > >> > > > > >>/* Copy the structure BITSIZE bits at a time. */ > > > > >>for (bitpos = 0, xbitpos = padding_correction; > > > > > > > > > > I believe this patch is wrong. Please revert. See the PR84762 > > > > > testcase. > > > > > > > > > > There are two problems. Firstly, if padding_correction is non-zero, > > > > > then xbitpos % BITS_PER_WORD is non-zero and in > > > > > > > > > > store_bit_field (dst_word, bitsize, xbitpos % BITS_PER_WORD, > > > > > 0, 0, word_mode, > > > > > extract_bit_field (src_word, bitsize, > > > > > bitpos % BITS_PER_WORD, 1, > > > > > NULL_RTX, word_mode, > > > > > word_mode, > > > > > false, NULL), > > > > > false); > > > > > > > > > > the stored bit-field exceeds the destination register size. You could > > > > > fix that by making bitsize the gcd of bitsize and padding_correction. > > > > > > > > > > However, that doesn't fix the second problem which is that the > > > > > extracted bit-field can exceed the source size. That will result in > > > > > rubbish being read into a register. > > > > > > > > FYI, I received an automated response saying Tamar is away on vacation > > > > with no return date specified. That means he won't be able to revert > > > > the patch. What do we do now? > > > > > > The code before the change already looks fishy to me. > > > > Yes, it is fishy so far as the code in the loop relies on alignment > > determining a small enough bitsize. Adding > > > > if (bytes % UNITS_PER_WORD != 0) > > bitsize = gcd (bitsize, (bytes % UNITS_PER_WORD) * BITS_PER_UNIT); > > > > after bitsize is calculated from alignment would make the code > > correct, I believe. But I think that will fail the testcase Tamar > > added. > > > > > x = expand_normal (src); > > > > > > so what do we expect this to expand to in general? Fortunately > > > it seems there are exactly two callers so hopefully a > > > gcc_assert (MEM_P (x)) would work? > > > > > > The fishy part is looking at TYPE_ALIGN (TREE_TYPE (src)). > > > > > > In case x is a MEM we should use MEM_ALIGN and if not then we > > > shouldn't do anything but just use word_mode here. > > > > No! You can't use a bitsize of BITS_PER_WORD here. See the code I > > quoted above. > > Ah, so it should possibly use TYPE_SIZE instead of TYPE_ALIGN Not that either. We already have a byte count.. > otherwise > it will handle the over-aligned case (align to 8 bytes, size 4 bytes) > incorrectly as well? Yes, that case is mishandled too, even before Tamar's patch. Peter's pr85123 testcase with vfloat1 aligned(8) is an example. If we want correct code, then if (bytes % UNITS_PER_WORD != 0) bitsize = gcd (bitsize, (bytes % UNITS_PER_WORD) * BITS_PER_UNIT); will fix the algorithm inside the copy_blkmode_to_reg loop. Otherwise the loop itself needs changes. -- Alan Modra Australia Development Lab, IBM
Re: [PATCH] Remove UBSAN in dwarf2out.c (PR tree-optimization/82491).
On Tue, Apr 03, 2018 at 02:31:56PM +0200, Martin Liška wrote: > Hi. > > This is second part of the UBSAN. Richard Sandiford help me to wrap the offset > into poly_uint64. The offset is neither logically signed nor logically > unsigned. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Martin > > gcc/ChangeLog: > > 2018-04-03 Martin Liska > > PR tree-optimization/82491 > * rtl.h (strip_offset_and_add): Replace += suboffset with > poly_uint64 () + suboffset. Ok, thanks. Jakub
[ARM,testsuite] Force hard-float on armv8_2-fp16-move-1.c
Hi, I've noticed that armv8_2-fp16-move-1.c fails on arm-linux-gnueabi and arm-none-eabi targets because: dg-add-options arm_v8_2a_fp16_scalar adds -mfloat-abi=softfp but we also have dg-options "-O2 -mfloat-abi=hard which means the testcase is compiled with both -mfloat-abi=hard -mfloat-abi=softfp (in that order) -mfloat-abi=hard is required for the test to pass, so I propose the attached workaround to make it pass on arm-linux-gnueabi / arm-none-eabi targets: move -mfloat-abi=hard to dg-additional-options such that it appears after the other options. Is that OK? Thanks, Christophe 2018-04-03 Christophe Lyon * gcc.target/arm/armv8_2-fp16-move-1.c: Move -mfloat-abi=hard to dg-additional-options. armv8_2-fp16-move-1.patch3 Description: Binary data
Re: [ARM,testsuite] Force hard-float on armv8_2-fp16-move-1.c
On 03/04/18 14:40, Christophe Lyon wrote: Hi, I've noticed that armv8_2-fp16-move-1.c fails on arm-linux-gnueabi and arm-none-eabi targets because: dg-add-options arm_v8_2a_fp16_scalar adds -mfloat-abi=softfp but we also have dg-options "-O2 -mfloat-abi=hard which means the testcase is compiled with both -mfloat-abi=hard -mfloat-abi=softfp (in that order) -mfloat-abi=hard is required for the test to pass, so I propose the attached workaround to make it pass on arm-linux-gnueabi / arm-none-eabi targets: move -mfloat-abi=hard to dg-additional-options such that it appears after the other options. Is that OK? Ok. Thanks, Kyrill Thanks, Christophe 2018-04-03 Christophe Lyon * gcc.target/arm/armv8_2-fp16-move-1.c: Move -mfloat-abi=hard to dg-additional-options.
[C++ PATCH] PR c++/65923
Finishing testing with the full suite on Linux-PPC64, tested partially
on Linux-x64.
2018-04-03 Ville Voutilainen
gcc/cp
PR c++/65923
* parser.c (cp_parser_unqualified_id): Add a new parameter
and check it for the literal diagnostic.
(cp_parser_using_declaration): Adjust.
testsuite/
PR c++/65923
* g++.dg/diagnostic/pr65923.C: New.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d526a4e..677ad61 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -2033,7 +2033,7 @@ static cp_expr cp_parser_primary_expression
static cp_expr cp_parser_id_expression
(cp_parser *, bool, bool, bool *, bool, bool);
static cp_expr cp_parser_unqualified_id
- (cp_parser *, bool, bool, bool, bool);
+ (cp_parser *, bool, bool, bool, bool, bool = false);
static tree cp_parser_nested_name_specifier_opt
(cp_parser *, bool, bool, bool, bool, bool = false);
static tree cp_parser_nested_name_specifier
@@ -5822,7 +5822,8 @@ cp_parser_unqualified_id (cp_parser* parser,
bool template_keyword_p,
bool check_dependency_p,
bool declarator_p,
- bool optional_p)
+ bool optional_p,
+ bool using_decl_p)
{
cp_token *token;
@@ -6105,7 +6106,7 @@ cp_parser_unqualified_id (cp_parser* parser,
/* 17.6.3.3.5 */
const char *name = UDLIT_OP_SUFFIX (id);
if (name[0] != '_' && !in_system_header_at (input_location)
- && declarator_p)
+ && declarator_p && !using_decl_p)
warning (OPT_Wliteral_suffix,
"literal operator suffixes not preceded by %<_%>"
" are reserved for future standardization");
@@ -18775,7 +18776,8 @@ cp_parser_using_declaration (cp_parser* parser,
/*template_keyword_p=*/false,
/*check_dependency_p=*/true,
/*declarator_p=*/true,
- /*optional_p=*/false);
+ /*optional_p=*/false,
+ /*using_decl_p=*/true);
if (access_declaration_p)
{
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr65923.C b/gcc/testsuite/g++.dg/diagnostic/pr65923.C
new file mode 100644
index 000..b9584d0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/pr65923.C
@@ -0,0 +1,5 @@
+// { dg-do compile { target c++14 } }
+
+#include
+
+using std::literals::chrono_literals::operator""s; // warning here
Re: [documentation patch] add detail to const and pure attributes
On 04/03/2018 03:27 AM, Pedro Alves wrote:
On 04/02/2018 11:34 PM, Martin Sebor wrote:
On 04/02/2018 12:09 AM, Sandra Loosemore wrote:
On 03/27/2018 03:21 PM, Pedro Alves wrote:
On 03/27/2018 09:19 PM, Martin Sebor wrote:
On 03/27/2018 01:38 PM, Pedro Alves wrote:
On 03/27/2018 07:18 PM, Martin Sebor wrote:
+Because a @code{pure} function can have no side-effects it does not
FWIW, I'd suggest rephrasing as:
Because a @code{pure} function cannot have side effects
because "can have no side-effects" can be read as
"is allowed to have no side effects", which gave me pause
when I read it the first time, and is the opposite of
what you mean.
That is what I meant: that const and pure functions are not allowed
to have any side-effects. If they did, they could be unexpectedly
eliminated (i.e., the behavior is undefined when such a function
does have a side-effect).
I know, but that's not what I read the first time (and found it
odd so I had to re-read). You can either assume that I'm the
only one that will misunderstand it on first read, or you can
swap a couple words and be sure no one will misunderstand it.
Up to you.
I'm chiming in a little late here, but I agree with Pedro that "can have
no side-effects" is confusing. I'd say "cannot have side effects" or
"must have no side effects" instead.
There's nothing confusing about it. It's an established phrase
with millions of uses and only one meaning. According to Google
Books Ngram Viewer it's also more pervasive than either of
the two suggested alternatives:
http://goo.gl/FgXgwi
Sorry, but no.
Sorry, but this is ridiculous.
I have no desire to debate this further. (In case you find
it confusing, let me rephrase it: I do not have the desire
to debate this.)
Martin
[nvptx] Use MAX, MIN, ROUND_UP macros
[ was: [og7] vector_length extension part 2: Generalize state
propagation and synchronization ]
On 03/02/2018 05:55 PM, Cesar Philippidis wrote:
- if (oacc_bcast_size < data.offset)
- oacc_bcast_size = data.offset;
The current state of nvptx.c uses this construct a lot, which is harder
to read than:
...
oacc_bcast_size = MAX (oacc_bcast_size, data.offset);
...
This patch replaces all such occurrences with MIN or MAX.
+ psize = (psize + oacc_bcast_align - 1) & ~(oacc_bcast_align - 1);
Likewise, this pattern occurs a lot, which is equivalent to:
...
psize = ROUND_UP (psize, oacc_bcast_align);
...
This patch also replaces all such occurrences with ROUND_UP.
Build on x86_64 with nvptx accelerator and reg-tested libgomp.
Committed.
Thanks,
- Tom
[nvptx] Use MAX, MIN, ROUND_UP macros
2018-04-03 Tom de Vries
* config/nvptx/nvptx.c (nvptx_gen_shared_bcast, shared_prop_gen)
(nvptx_goacc_expand_accel_var): Use MAX and ROUND_UP.
(nvptx_assemble_value, nvptx_output_skip): Use MIN.
(nvptx_shared_propagate, nvptx_single, nvptx_expand_shared_addr): Use
MAX.
---
gcc/config/nvptx/nvptx.c | 35 +--
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 38f25ad..d4ff730 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -1808,9 +1808,8 @@ nvptx_gen_shared_bcast (rtx reg, propagate_mask pm, unsigned rep,
{
unsigned align = GET_MODE_ALIGNMENT (mode) / BITS_PER_UNIT;
- if (align > oacc_bcast_align)
- oacc_bcast_align = align;
- data->offset = (data->offset + align - 1) & ~(align - 1);
+ oacc_bcast_align = MAX (oacc_bcast_align, align);
+ data->offset = ROUND_UP (data->offset, align);
addr = data->base;
gcc_assert (data->base != NULL);
if (data->offset)
@@ -1932,8 +1931,7 @@ nvptx_assemble_value (unsigned HOST_WIDE_INT val, unsigned size)
{
val >>= part * BITS_PER_UNIT;
part = init_frag.size - init_frag.offset;
- if (part > size)
- part = size;
+ part = MIN (part, size);
unsigned HOST_WIDE_INT partial
= val << (init_frag.offset * BITS_PER_UNIT);
@@ -1996,8 +1994,7 @@ nvptx_output_skip (FILE *, unsigned HOST_WIDE_INT size)
if (init_frag.offset)
{
unsigned part = init_frag.size - init_frag.offset;
- if (part > size)
- part = (unsigned) size;
+ part = MIN (part, (unsigned)size);
size -= part;
nvptx_assemble_value (0, part);
}
@@ -3912,9 +3909,8 @@ shared_prop_gen (rtx reg, propagate_mask pm, unsigned rep, void *data_,
/* Starting a loop, initialize pointer.*/
unsigned align = GET_MODE_ALIGNMENT (GET_MODE (reg)) / BITS_PER_UNIT;
- if (align > oacc_bcast_align)
- oacc_bcast_align = align;
- data->offset = (data->offset + align - 1) & ~(align - 1);
+ oacc_bcast_align = MAX (oacc_bcast_align, align);
+ data->offset = ROUND_UP (data->offset, align);
data->ptr = gen_reg_rtx (Pmode);
@@ -3955,8 +3951,7 @@ nvptx_shared_propagate (bool pre_p, bool is_call, basic_block block,
rtx init = gen_rtx_SET (data.base, oacc_bcast_sym);
emit_insn_after (init, insn);
- if (oacc_bcast_size < data.offset)
- oacc_bcast_size = data.offset;
+ oacc_bcast_size = MAX (oacc_bcast_size, data.offset);
}
return empty;
}
@@ -4224,8 +4219,7 @@ nvptx_single (unsigned mask, basic_block from, basic_block to)
data.base = oacc_bcast_sym;
data.ptr = 0;
- if (oacc_bcast_size < GET_MODE_SIZE (SImode))
- oacc_bcast_size = GET_MODE_SIZE (SImode);
+ oacc_bcast_size = MAX (oacc_bcast_size, GET_MODE_SIZE (SImode));
data.offset = 0;
emit_insn_before (nvptx_gen_shared_bcast (pvar, PM_read, 0, &data,
@@ -4833,13 +4827,11 @@ nvptx_expand_shared_addr (tree exp, rtx target,
return target;
unsigned align = TREE_INT_CST_LOW (CALL_EXPR_ARG (exp, 2));
- if (align > worker_red_align)
-worker_red_align = align;
+ worker_red_align = MAX (worker_red_align, align);
unsigned offset = TREE_INT_CST_LOW (CALL_EXPR_ARG (exp, 0));
unsigned size = TREE_INT_CST_LOW (CALL_EXPR_ARG (exp, 1));
- if (size + offset > worker_red_size)
-worker_red_size = size + offset;
+ worker_red_size = MAX (worker_red_size, size + offset);
rtx addr = worker_red_sym;
if (offset)
@@ -5832,10 +5824,9 @@ nvptx_goacc_expand_accel_var (tree var)
else
{
unsigned HOST_WIDE_INT align = DECL_ALIGN (var);
- gangprivate_shared_size =
- (gangprivate_shared_size + align - 1) & ~(align - 1);
- if (gangprivate_shared_align < align)
- gangprivate_shared_align = align;
+ gangprivate_shared_size
+ = ROUND_UP (gangprivate_shared_size, align);
+ gangprivate_shared_align = MAX (gangprivate_shared_align, align);
offset = gangprivate_shared_size;
bool existed = gangprivate_shared_hmap.put (var, offset);
Re: [documentation patch] add detail to const and pure attributes
On Mon, Apr 2, 2018 at 6:34 PM, Martin Sebor wrote:
> Attached is a changed patch that uses "cannot have side effects"
> instead of "can have no side effects."
> +effects it does not make sense for such a function to return @code{void}.
> +Declaring such functions is diagnosed.
Let's make the last sentence singular ("such a function") as well. OK
with that change in both hunks.
Jason
Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization
On 03/02/2018 05:55 PM, Cesar Philippidis wrote:
* config/nvptx/nvptx.c (oacc_bcast_partition): Declare.
One last thing: this variable needs to be reset to zero for every function.
Without this reset, we can generated different code for a function
depending on whether there's another function in front or not.
(populate_offload_attrs): Handle the situation where the default
runtime geometry has not been initialized yet for reductions.
I've moved this bit to "vector_length extension part 4: target hooks and
automatic parallelism".
Build on x86_64 with nvptx accelerator and tested libgomp.
Committed.
Thanks,
- Tom
[nvptx] Generalize state propagation and synchronization
2018-04-03 Cesar Philippidis
Tom de Vries
* config/nvptx/nvptx.c (oacc_bcast_partition): Declare.
(nvptx_option_override): Init oacc_bcast_partition.
(nvptx_init_oacc_workers): New function.
(nvptx_declare_function_name): Call nvptx_init_oacc_workers.
(nvptx_needs_shared_bcast): New function.
(nvptx_find_par): Generalize to enable vectors to use shared-memory
to propagate state.
(nvptx_shared_propagate): Initialize vector bcast partition and
synchronization state.
(nvptx_single): Generalize to enable vectors to use shared-memory
to propagate state.
(nvptx_process_pars): Likewise.
* config/nvptx/nvptx.h (struct machine_function): Add
bcast_partition and sync_bar members.
---
gcc/config/nvptx/nvptx.c | 137 ++-
gcc/config/nvptx/nvptx.h | 4 ++
2 files changed, 129 insertions(+), 12 deletions(-)
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index d4ff730..0b46e13 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -133,6 +133,7 @@ static GTY((cache)) hash_table *needed_fndecls_htab;
memory. It'd be nice if PTX supported common blocks, because then
this could be shared across TUs (taking the largest size). */
static unsigned oacc_bcast_size;
+static unsigned oacc_bcast_partition;
static unsigned oacc_bcast_align;
static GTY(()) rtx oacc_bcast_sym;
@@ -157,6 +158,8 @@ static bool need_softstack_decl;
/* True if any function references __nvptx_uni. */
static bool need_unisimt_decl;
+static int nvptx_mach_max_workers ();
+
/* Allocate a new, cleared machine_function structure. */
static struct machine_function *
@@ -210,6 +213,7 @@ nvptx_option_override (void)
oacc_bcast_sym = gen_rtx_SYMBOL_REF (Pmode, "__oacc_bcast");
SET_SYMBOL_DATA_AREA (oacc_bcast_sym, DATA_AREA_SHARED);
oacc_bcast_align = GET_MODE_ALIGNMENT (SImode) / BITS_PER_UNIT;
+ oacc_bcast_partition = 0;
worker_red_sym = gen_rtx_SYMBOL_REF (Pmode, "__worker_red");
SET_SYMBOL_DATA_AREA (worker_red_sym, DATA_AREA_SHARED);
@@ -1097,6 +1101,40 @@ nvptx_init_axis_predicate (FILE *file, int regno, const char *name)
fprintf (file, "\t}\n");
}
+/* Emit code to initialize OpenACC worker broadcast and synchronization
+ registers. */
+
+static void
+nvptx_init_oacc_workers (FILE *file)
+{
+ fprintf (file, "\t{\n");
+ fprintf (file, "\t\t.reg.u32\t%%tidy;\n");
+ if (cfun->machine->bcast_partition)
+{
+ fprintf (file, "\t\t.reg.u64\t%%t_bcast;\n");
+ fprintf (file, "\t\t.reg.u64\t%%y64;\n");
+}
+ fprintf (file, "\t\tmov.u32\t\t%%tidy, %%tid.y;\n");
+ if (cfun->machine->bcast_partition)
+{
+ fprintf (file, "\t\tcvt.u64.u32\t%%y64, %%tidy;\n");
+ fprintf (file, "\t\tadd.u64\t\t%%y64, %%y64, 1; // vector ID\n");
+ fprintf (file, "\t\tcvta.shared.u64\t%%t_bcast, __oacc_bcast;\n");
+ fprintf (file, "\t\tmad.lo.u64\t%%r%d, %%y64, %d, %%t_bcast; "
+ "// vector broadcast offset\n",
+ REGNO (cfun->machine->bcast_partition),
+ oacc_bcast_partition);
+}
+ /* Verify oacc_bcast_size. */
+ gcc_assert (oacc_bcast_partition * (nvptx_mach_max_workers () + 1)
+ <= oacc_bcast_size);
+ if (cfun->machine->sync_bar)
+fprintf (file, "\t\tadd.u32\t\t%%r%d, %%tidy, 1; "
+ "// vector synchronization barrier\n",
+ REGNO (cfun->machine->sync_bar));
+ fprintf (file, "\t}\n");
+}
+
/* Emit code to initialize predicate and master lane index registers for
-muniform-simt code generation variant. */
@@ -1323,6 +1361,8 @@ nvptx_declare_function_name (FILE *file, const char *name, const_tree decl)
if (cfun->machine->unisimt_predicate
|| (cfun->machine->has_simtreg && !crtl->is_leaf))
nvptx_init_unisimt_predicate (file);
+ if (cfun->machine->bcast_partition || cfun->machine->sync_bar)
+nvptx_init_oacc_workers (file);
}
/* Output code for switching uniform-simt state. ENTERING indicates whether
@@ -3000,6 +3040,19 @@ nvptx_split_blocks (bb_insn_map_t *map)
}
}
+/* Return true if MASK contains parallelism that requires shared
+ memory to broadcast. */
+
+static bool
+nvptx_needs_shared_bcast (unsigned mask)
+{
+ bool worker = mask & GOMP_DIM_MASK (GOMP_DIM_WORKER);
+ bool large_vector = (mask &
Re: [patch, fortran] Simplify constants which come from parameter arrays
Hi Thomas, > Le 31 mars 2018 à 13:57, Thomas König a écrit : > > Hi Dominique, > > These have been resolved now - I have removed the invalid code > from substr_6.f90 (PR85130), and the error is now suppressed > in the attached patch. > > Re-regression-tested. OK for trunk? > > Regards The new patch regtest fine now. However as said on IRC this looks as a kludge made necessary by a questionable (invalid) test. IMO it would be more general (better) to call gfc_simplify_expr (e, 1); only when there is no pending error (warning?). I have also a question about "is out of bounds": it is a warning in resolve.c, but an error in expr.c and simplify.c. Should not it be an error everywhere? Cheers, Dominique
Selective scheduling fixes
Hello, I will post patches to various recent selective scheduling PRs as replies to this mail. The patches have been tested on x86-64 (default languages) and ia64 (c.c++), in case of ppc issues I've checked on the ppc cross compiler. I will also run the ia64 boostrap with enabled sel-sched but it will take more time. Best, Andrey
[PATCH] rs6000: Fix pr69946.c testcase (PR85126)
After middle-end changes combine now gets fed different input, from
which it makes different (but just as efficient) code. So remove the
test for particular asm output.
Tested, committing.
Segher
2018-04-03 Segher Boessenkool
gcc/testsuite/
PR target/85126
* gcc.target/powerpc/pr69946: Adjust comment. Remove
scan-assembler-times clause.
---
gcc/testsuite/gcc.target/powerpc/pr69946.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr69946.c
b/gcc/testsuite/gcc.target/powerpc/pr69946.c
index eb0c365..e0ff422 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr69946.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr69946.c
@@ -2,9 +2,9 @@
/* { dg-skip-if "" { powerpc_elfv2 } } */
/* { dg-options "-O2" } */
-/* This generates a rotate:DI by 44, with mask 0xf00, which is implemented
- using a rlwinm instruction. We used to write 44 for the shift count
- there; it should be 12. */
+/* This used to generate a rotate:DI by 44, with mask 0xf00, which is
+ implemented using a rlwinm instruction. We used to write 44 for the
+ shift count there; it should be 12. */
struct A
{
@@ -35,4 +35,3 @@ foo (void)
}
/* { dg-final { scan-assembler-not {(?n)rlwinm.*,44,20,23} } } */
-/* { dg-final { scan-assembler-times {(?n)rlwinm.*,12,20,23} 1 } } */
--
1.8.3.1
Re: [C++ Patch] ("[7/8 Regression] ICE with failed class template argument deduction because of invalid template parameter")
OK. On Tue, Apr 3, 2018 at 5:02 AM, Paolo Carlini wrote: > Hi, > > the reason why we ICE here is very simple: we pass an error_mark_node > generated in cp_parser_template_parameter_list to rewrite_template_parm > which ICEs (via get_template_parm_index). I believe it makes sense to > robustify the latter like all the other functions involved in > build_deduction_guide. The next, error recovery quality, issue is whether or > not we still want to produce diagnostic about class template argument > deduction failing: today I noticed - somewhat surprisingly - that some > compilers still do that (however the diagnostic is more terse: eg, one > additional error and two notes, not two errors and five notes!). I had > tested the below which suppresses those additional errors by returning > error_mark_node from build_deduction_guide if one of those parsing-time > error_mark_nodes is encountered in the build_deduction_guide loop - and lays > out a bit of infrastructure. > > Tested x86_64-linux. > > Thanks, Paolo. > > >
Fix PR 83530
Hello,
This issue is when we cannot correctly make insn tick data for the
unscheduled code (but processed by the modulo scheduler). Fixed by closely
following usual scheduling process as described in the PR.
Best,
Andrey
2018-04-03 Andrey Belevantsev
PR rtl-optimization/83530
* sel-sched.c (force_next_insn): New global variable.
(remove_insn_for_debug): When force_next_insn is true, also leave only
next insn
in the ready list.
(sel_sched_region): When the region wasn't scheduled, make another pass
over it
with force_next_insn set to 1.
* gcc.dg/pr8350.c: New test.
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 76092f9587a..fca2b69c5ee 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -5004,12 +5004,16 @@ remove_temp_moveop_nops (bool full_tidying)
distinguishing between bookkeeping copies and original insns. */
static int max_uid_before_move_op = 0;
+/* When true, we're always scheduling next insn on the already scheduled code
+ to get the right insn data for the following bundling or other passes. */
+static int force_next_insn = 0;
+
/* Remove from AV_VLIW_P all instructions but next when debug counter
tells us so. Next instruction is fetched from BNDS. */
static void
remove_insns_for_debug (blist_t bnds, av_set_t *av_vliw_p)
{
- if (! dbg_cnt (sel_sched_insn_cnt))
+ if (! dbg_cnt (sel_sched_insn_cnt) || force_next_insn)
/* Leave only the next insn in av_vliw. */
{
av_set_iterator av_it;
@@ -7642,7 +7646,13 @@ sel_sched_region (int rgn)
sel_sched_region_1 ();
else
/* Force initialization of INSN_SCHED_CYCLEs for correct bundling. */
-reset_sched_cycles_p = true;
+{
+ reset_sched_cycles_p = false;
+ pipelining_p = false;
+ force_next_insn = 1;
+ sel_sched_region_1 ();
+ force_next_insn = 0;
+}
sel_region_finish (reset_sched_cycles_p);
}
diff --git a/gcc/testsuite/gcc.dg/pr83530.c b/gcc/testsuite/gcc.dg/pr83530.c
new file mode 100644
index 000..f4d8927de92
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr83530.c
@@ -0,0 +1,15 @@
+/* { dg-do compile { target powerpc*-*-* ia64-*-* i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -fmodulo-sched -fselective-scheduling2" } */
+int vm, z0;
+short int mz;
+
+int
+ny (void)
+{
+ int ch;
+
+ for (ch = 0; ch < 6; ++ch)
+vm += ch / vm;
+
+ return z0 + mz;
+}
Re: [PATCH] [PR c++/84979] improve auto handling in explicit tmpl args for concepts
On Tue, Apr 3, 2018 at 3:54 AM, Alexandre Oliva wrote:
> On Apr 2, 2018, Jason Merrill wrote:
>
>> On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
>>> On Mar 30, 2018, Jason Merrill wrote:
>>> template
>>> void foo(T t) {
>>> typename T::template C u = t;
>>> T::template C (t);
>>> T::template C::f (t, u);
>>> }
>
>> We should be able to distinguish those cases based on tag_type.
>[...]
> And then, while we're parsing "template C", we haven't yet reached
> the '::' after the closing angle bracket that would tell us to regard
> the id necessarily as a typename, so I don't see how we'd get a
> scope_type in tag_type for the third case.
Ah, good point. Then perhaps put the new function in pt.c and also
call it from tsubst_copy_and_build?
Jason
Re: [PATCH] [PR c++/84943] allow folding of array indexing indirect_ref
On Tue, Apr 3, 2018 at 3:44 AM, Alexandre Oliva wrote:
> On Apr 2, 2018, Jason Merrill wrote:
>
>> On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva wrote:
>>> On Mar 30, 2018, Jason Merrill wrote:
>>>
I don't think we need this; if arg is overloaded, we take the
type_unknown_p early exit, so the code lower down is always dealing
with a single function.
>>>
>>> Aah, that's why it seemed to me that we had already resolved overloads
>>> when we got there.
>>>
>>> As a bonus, I added the tf_conv test before another mark_used call I'd
>>> missed in the previous patch.
>
>> What if we check tf_conv in mark_used itself rather than at all the call
>> sites?
>
> There are other uses of mark_used, but presumably we want them all to
> be more conservative under tf_conv, so... Here's what I'm testing. Ok
> if it passes?
>
>
> [PR c++/84943] mark function as used when taking its address
>
> fn[0]() ICEd because we would fold the INDIRECT_REF used for the
> array indexing while building the address for the call, after not
> finding the decl hiding there at first. But the decl would be exposed
> by the folding, and then lower layers would complain we had the decl,
> after all, but it wasn't one of the artificial or special functions
> that could be called without being marked as used.
>
> This patch arranges for a FUNCTION_DECL to be marked as used when
> taking its address, just like we already did when taking the address
> of a static function to call it as a member function (i.e. using the
> obj.fn() notation). However, we shouldn't mark functions as used when
> just performing overload resolution, lest we might instantiate
> templates we shouldn't, as in g++.dg/overload/template1.C, so we
> adjust mark_used to return early when testing conversions.
>
>
> for gcc/cp/ChangeLog
>
> PR c++/84943
> * typeck.c (cp_build_addr_expr_1): Mark FUNCTION_DECL as
> used.
> * decl2.c (mark_used): Return without effects if tf_conv.
>
> for gcc/testsuite/ChangeLog
>
> PR c++/84943
> * g++.dg/pr84943.C: New.
> * g++.dg/pr84943-2.C: New.
> ---
> gcc/cp/decl2.c |6
> gcc/cp/typeck.c |3 ++
> gcc/testsuite/g++.dg/pr84943-2.C | 64
> ++
> gcc/testsuite/g++.dg/pr84943.C |8 +
> 4 files changed, 81 insertions(+)
> create mode 100644 gcc/testsuite/g++.dg/pr84943-2.C
> create mode 100644 gcc/testsuite/g++.dg/pr84943.C
>
> diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
> index fa753749e1a6..740e85b35617 100644
> --- a/gcc/cp/decl2.c
> +++ b/gcc/cp/decl2.c
> @@ -5201,6 +5201,12 @@ maybe_instantiate_decl (tree decl)
> bool
> mark_used (tree decl, tsubst_flags_t complain)
> {
> + /* If we're just testing conversions or resolving overloads, we
> + don't want any permanent effects like forcing functions to be
> + output or instantiating templates. */
> + if ((complain & tf_conv))
> +return false;
I think we want to return true.
Jason
Fix PR 83962
Hello,
This issues is about the correct order in which we need to call the
routines that fix up the control flow for us.
Best,
Andrey
2018-04-03 Andrey Belevantsev
PR rtl-optimization/83962
* sel-sched-ir.c (tidy_control_flow): Correct the order in which we call
tidy_fallthru_edge
and tidy_control_flow.
* gcc.dg/pr83962.c: New test.
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index a965d2ec42f..f6de96a7f3d 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -3839,9 +3839,13 @@ tidy_control_flow (basic_block xbb, bool full_tidying)
&& INSN_SCHED_TIMES (BB_END (xbb)) == 0
&& !IN_CURRENT_FENCE_P (BB_END (xbb)))
{
- if (sel_remove_insn (BB_END (xbb), false, false))
-return true;
+ /* We used to call sel_remove_insn here that can trigger
tidy_control_flow
+ before we fix up the fallthru edge. Correct that ordering by
+explicitly doing the latter before the former. */
+ clear_expr (INSN_EXPR (BB_END (xbb)));
tidy_fallthru_edge (EDGE_SUCC (xbb, 0));
+ if (tidy_control_flow (xbb, false))
+ return true;
}
first = sel_bb_head (xbb);
diff --git a/gcc/testsuite/gcc.dg/pr83962.c b/gcc/testsuite/gcc.dg/pr83962.c
new file mode 100644
index 000..0547e218715
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr83962.c
@@ -0,0 +1,10 @@
+/* { dg-do compile { target powerpc*-*-* ia64-*-* i?86-*-* x86_64-*-* } } */
+/* { dg-options "-std=gnu99 -O1 -fselective-scheduling2 -fschedule-insns2
-fcse-follow-jumps -fno-ssa-phiopt -fno-guess-branch-probability" } */
+unsigned int ca;
+
+void
+v6 (long long unsigned int as, int p9)
+{
+ while (p9 < 1)
+as = (as != ca) || (as > 1);
+}
Re: [PATCH] [PR c++/84943] allow folding of array indexing indirect_ref
On Tue, Apr 3, 2018 at 11:47 AM, Jason Merrill wrote:
> On Tue, Apr 3, 2018 at 3:44 AM, Alexandre Oliva wrote:
>> On Apr 2, 2018, Jason Merrill wrote:
>>
>>> On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva wrote:
On Mar 30, 2018, Jason Merrill wrote:
> I don't think we need this; if arg is overloaded, we take the
> type_unknown_p early exit, so the code lower down is always dealing
> with a single function.
Aah, that's why it seemed to me that we had already resolved overloads
when we got there.
As a bonus, I added the tf_conv test before another mark_used call I'd
missed in the previous patch.
>>
>>> What if we check tf_conv in mark_used itself rather than at all the call
>>> sites?
>>
>> There are other uses of mark_used, but presumably we want them all to
>> be more conservative under tf_conv, so... Here's what I'm testing. Ok
>> if it passes?
>>
>>
>> [PR c++/84943] mark function as used when taking its address
>>
>> fn[0]() ICEd because we would fold the INDIRECT_REF used for the
>> array indexing while building the address for the call, after not
>> finding the decl hiding there at first. But the decl would be exposed
>> by the folding, and then lower layers would complain we had the decl,
>> after all, but it wasn't one of the artificial or special functions
>> that could be called without being marked as used.
>>
>> This patch arranges for a FUNCTION_DECL to be marked as used when
>> taking its address, just like we already did when taking the address
>> of a static function to call it as a member function (i.e. using the
>> obj.fn() notation). However, we shouldn't mark functions as used when
>> just performing overload resolution, lest we might instantiate
>> templates we shouldn't, as in g++.dg/overload/template1.C, so we
>> adjust mark_used to return early when testing conversions.
>>
>>
>> for gcc/cp/ChangeLog
>>
>> PR c++/84943
>> * typeck.c (cp_build_addr_expr_1): Mark FUNCTION_DECL as
>> used.
>> * decl2.c (mark_used): Return without effects if tf_conv.
>>
>> for gcc/testsuite/ChangeLog
>>
>> PR c++/84943
>> * g++.dg/pr84943.C: New.
>> * g++.dg/pr84943-2.C: New.
>> ---
>> gcc/cp/decl2.c |6
>> gcc/cp/typeck.c |3 ++
>> gcc/testsuite/g++.dg/pr84943-2.C | 64
>> ++
>> gcc/testsuite/g++.dg/pr84943.C |8 +
>> 4 files changed, 81 insertions(+)
>> create mode 100644 gcc/testsuite/g++.dg/pr84943-2.C
>> create mode 100644 gcc/testsuite/g++.dg/pr84943.C
>>
>> diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
>> index fa753749e1a6..740e85b35617 100644
>> --- a/gcc/cp/decl2.c
>> +++ b/gcc/cp/decl2.c
>> @@ -5201,6 +5201,12 @@ maybe_instantiate_decl (tree decl)
>> bool
>> mark_used (tree decl, tsubst_flags_t complain)
>> {
>> + /* If we're just testing conversions or resolving overloads, we
>> + don't want any permanent effects like forcing functions to be
>> + output or instantiating templates. */
>> + if ((complain & tf_conv))
>> +return false;
>
> I think we want to return true.
(OK with that change.)
Jason
[wwwdocs]Mention -ftree-loop-distribution
Hi, Option -ftree-loop-distribution is improved and enabled by default at -O3 for GCC8. This patch describes the change, is it OK? Thanks, binIndex: htdocs/gcc-8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v retrieving revision 1.51 diff -u -r1.51 changes.html --- htdocs/gcc-8/changes.html 3 Apr 2018 06:52:04 - 1.51 +++ htdocs/gcc-8/changes.html 3 Apr 2018 14:26:31 - @@ -101,6 +101,13 @@ are enabled by default at -O3 and above. +Classical loop nest optimization pass -ftree-loop-distribution +has been improved and enabled by default at -O3 and above. +It supports loop nest distribution in some restricted scenarios; it also +supports cancellable innermost loop distribution with loop versioning +under runtime alias checks. + + The new option -fstack-clash-protection causes the compiler to insert probes whenever stack space is allocated statically or dynamically to reliably detect stack overflows and
Fix PR 83913
Hello,
This issue ended up being fixed the way different from described in the PR.
We do not want to walk away from the invariant "zero SCHED_TIMES -- insn
is not scheduled" even for bookkeeping copies (testing showed it trips over
asserts designed to catch this). Rather we choose merging exprs in the way
the larger sched-times wins.
Best,
Andrey
2018-04-03 Andrey Belevantsev
PR rtl-optimization/83913
* sel-sched-ir.c (merge_expr_data): Choose the middle between two
different sched-times
when merging exprs.
* gcc.dg/pr83913.c: New test.
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index a965d2ec42f..f6de96a7f3d 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -1837,8 +1837,9 @@ merge_expr_data (expr_t to, expr_t from, insn_t
split_point)
if (EXPR_PRIORITY (to) < EXPR_PRIORITY (from))
EXPR_PRIORITY (to) = EXPR_PRIORITY (from);
- if (EXPR_SCHED_TIMES (to) > EXPR_SCHED_TIMES (from))
-EXPR_SCHED_TIMES (to) = EXPR_SCHED_TIMES (from);
+ if (EXPR_SCHED_TIMES (to) != EXPR_SCHED_TIMES (from))
+EXPR_SCHED_TIMES (to) = ((EXPR_SCHED_TIMES (from) + EXPR_SCHED_TIMES (to)
+ + 1) / 2);
if (EXPR_ORIG_BB_INDEX (to) != EXPR_ORIG_BB_INDEX (from))
EXPR_ORIG_BB_INDEX (to) = 0;
@@ -3293,11 +3294,22 @@ has_dependence_note_mem_dep (rtx mem ATTRIBUTE_UNUSED,
/* Note a dependence. */
static void
diff --git a/gcc/testsuite/gcc.dg/pr83913.c b/gcc/testsuite/gcc.dg/pr83913.c
new file mode 100644
index 000..c898d71a261
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr83913.c
@@ -0,0 +1,26 @@
+/* { dg-do compile { target powerpc*-*-* ia64-*-* i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -funroll-all-loops -fselective-scheduling
-fsel-sched-pipelining -fschedule-insns -fno-dce -fno-forward-propagate
-fno-rerun-cse-after-loop -fno-web" } */
+
+int jo, z4;
+
+int
+be (long unsigned int l7, int nt)
+{
+ int en;
+
+ jo = l7;
+ for (en = 0; en < 24; ++en)
+{
+ jo = (jo / z4) * (!!jo >= ((!!nt) & 2));
+ if (jo == 0)
+nt = 0;
+ else
+{
+ nt = z4;
+ ++z4;
+ nt = (long unsigned int) nt == (l7 + 1);
+}
+}
+
+ return nt;
+}
Re: Fix PR 83913
On Tue, 3 Apr 2018, Andrey Belevantsev wrote: > Hello, > > This issue ended up being fixed the way different from described in the PR. > We do not want to walk away from the invariant "zero SCHED_TIMES -- insn > is not scheduled" even for bookkeeping copies (testing showed it trips over > asserts designed to catch this). Rather we choose merging exprs in the way > the larger sched-times wins. ... but the Changelog and the actual patch take the average rather than the maximum sched-time? :) I believe either way would be acceptable, but please clarify the intent. Alexander
Fix PRs 80463, 83972, 83480
Hello,
In these PRs we deal with the dependencies we are forced to make between a
debug insn and its previous insn (unless bb head). In the latter case, if
such an insn has been moved, we fixup its movement so it aligns with the
sel-sched invariants. We also carefully adjust seqnos in the case we had a
single debug insn left in the block.
Best,
Andrey
2018-04-03 Andrey Belevantsev
PR rtl-optimization/80463
PR rtl-optimization/83972
PR rtl-optimization/83480
* sel-sched-ir.c (has_dependence_note_mem_dep): Take into account the
correct producer for the insn.
(tidy_control_flow): Fixup seqnos in case of debug insns.
* gcc.dg/pr80463.c: New test.
* g++.dg/pr80463.C: Likewise.
* gcc.dg/pr83972.c: Likewise.
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index a965d2ec42f..f6de96a7f3d 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -3293,11 +3293,22 @@ has_dependence_note_mem_dep (rtx mem ATTRIBUTE_UNUSED,
/* Note a dependence. */
static void
-has_dependence_note_dep (insn_t pro ATTRIBUTE_UNUSED,
+has_dependence_note_dep (insn_t pro,
ds_t ds ATTRIBUTE_UNUSED)
{
- if (!sched_insns_conditions_mutex_p (has_dependence_data.pro,
- VINSN_INSN_RTX
(has_dependence_data.con)))
+ insn_t real_pro = has_dependence_data.pro;
+ insn_t real_con = VINSN_INSN_RTX (has_dependence_data.con);
+
+ /* We do not allow for debug insns to move through others unless they
+ are at the start of bb. Such insns may create bookkeeping copies
+ that would not be able to move up breaking sel-sched invariants.
+ Detect that here and allow that movement if we allowed it before
+ in the first place. */
+ if (DEBUG_INSN_P (real_con)
+ && INSN_UID (NEXT_INSN (pro)) == INSN_UID (real_con))
+return;
+
+ if (!sched_insns_conditions_mutex_p (real_pro, real_con))
{
ds_t *dsp = &has_dependence_data.has_dep_p[has_dependence_data.where];
@@ -3890,6 +3905,19 @@ tidy_control_flow (basic_block xbb, bool full_tidying)
gcc_assert (EDGE_SUCC (xbb->prev_bb, 0)->flags & EDGE_FALLTHRU);
+ /* We could have skipped some debug insns which did not get removed
with the block,
+ and the seqnos could become incorrect. Fix them up here. */
+ if (MAY_HAVE_DEBUG_INSNS && (sel_bb_head (xbb) != first ||
sel_bb_end (xbb) != last))
+ {
+ if (!sel_bb_empty_p (xbb->prev_bb))
+ {
+ int prev_seqno = INSN_SEQNO (sel_bb_end (xbb->prev_bb));
+ if (prev_seqno > INSN_SEQNO (sel_bb_head (xbb)))
+ for (insn_t insn = sel_bb_head (xbb); insn != first; insn =
NEXT_INSN (insn))
+ INSN_SEQNO (insn) = prev_seqno + 1;
+ }
+ }
+
/* It can turn out that after removing unused jump, basic block
that contained that jump, becomes empty too. In such case
remove it too. */
diff --git a/gcc/testsuite/g++.dg/pr80463.C b/gcc/testsuite/g++.dg/pr80463.C
new file mode 100644
index 000..5614c28ca45
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr80463.C
@@ -0,0 +1,20 @@
+/* { dg-do compile { target powerpc*-*-* ia64-*-* i?86-*-* x86_64-*-* } } */
+/* { dg-options "-g -fselective-scheduling2 -O2
-fvar-tracking-assignments" } */
+
+int *a;
+int b, c;
+void
+d ()
+{
+ for (int e; c; e++)
+switch (e)
+ {
+ case 0:
+ a[e] = 1;
+ case 1:
+ b = 2;
+ break;
+ default:
+ a[e] = 3;
+ }
+}
diff --git a/gcc/testsuite/gcc.dg/pr80463.c b/gcc/testsuite/gcc.dg/pr80463.c
new file mode 100644
index 000..cebf2fef1f3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr80463.c
@@ -0,0 +1,54 @@
+/* { dg-do compile { target powerpc*-*-* ia64-*-* i?86-*-* x86_64-*-* } } */
+/* { dg-options "-g -O2 -fvar-tracking-assignments -fselective-scheduling2
-ftree-loop-vectorize -fnon-call-exceptions -fno-tree-vrp -fno-gcse-lm
-fno-tree-loop-im -fno-reorder-blocks-and-partition -fno-reorder-blocks
-fno-move-loop-invariants -w" } */
+
+short int t2;
+int cd, aa, ft;
+
+void
+dh (void)
+{
+ int qs = 0;
+
+ if (t2 < 1)
+{
+ int bq = 0;
+
+ while (bq < 1)
+{
+}
+
+ while (t2 < 1)
+{
+ if (t2 == 0)
+{
+ bq = 0;
+ cd = !!cd;
+}
+ else
+{
+ bq = 1;
+ cd = bq > qs;
+}
+
+ t2 += cd;
+ bq = (t2 / qs) == bq;
+
+ if (aa != ft)
+{
+ qs %= 0;
+ while (bq != 0)
+{
+ ro:
+ ;
+}
+}
+
+ ++t2;
+}
+
+ ia:
+ goto ro;
+}
+
+ goto ia;
+}
diff --git a/gcc/testsuite/gcc.dg/pr83972.c b/gcc/testsuite/gcc.dg/pr83972.c
new file mode 100644
index 000..b8de42cef0a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr83972.c
@@ -0,0 +1,26 @@
+/* { dg-do compile {
[C++ PATCH] Fix __direct_bases ICE (PR c++/85146)
Hi!
>From N2965 it is unclear to me what should the trait do on classes with
incomplete types, but given that __bases already returns an empty pack,
this patch does the same for __direct_bases.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-04-03 Jakub Jelinek
PR c++/85146
* semantics.c (calculate_direct_bases): Return empty vector if
TYPE_BINFO is NULL. Formatting fixes.
* g++.dg/ext/bases3.C: New test.
--- gcc/cp/semantics.c.jj 2018-03-30 20:38:03.370202169 +0200
+++ gcc/cp/semantics.c 2018-04-03 09:32:38.462091604 +0200
@@ -3898,36 +3898,26 @@ calculate_direct_bases (tree type)
complete_type (type);
- if (!NON_UNION_CLASS_TYPE_P (type))
+ if (!NON_UNION_CLASS_TYPE_P (type) || !TYPE_BINFO (type))
return make_tree_vec (0);
base_binfos = BINFO_BASE_BINFOS (TYPE_BINFO (type));
/* Virtual bases are initialized first */
for (i = 0; base_binfos->iterate (i, &binfo); i++)
-{
- if (BINFO_VIRTUAL_P (binfo))
- {
- vec_safe_push (vector, binfo);
- }
-}
+if (BINFO_VIRTUAL_P (binfo))
+ vec_safe_push (vector, binfo);
/* Now non-virtuals */
for (i = 0; base_binfos->iterate (i, &binfo); i++)
-{
- if (!BINFO_VIRTUAL_P (binfo))
- {
- vec_safe_push (vector, binfo);
- }
-}
-
+if (!BINFO_VIRTUAL_P (binfo))
+ vec_safe_push (vector, binfo);
bases_vec = make_tree_vec (vector->length ());
for (i = 0; i < vector->length (); ++i)
-{
- TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE ((*vector)[i]);
-}
+TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE ((*vector)[i]);
+
return bases_vec;
}
--- gcc/testsuite/g++.dg/ext/bases3.C.jj2018-04-03 09:39:49.547038799
+0200
+++ gcc/testsuite/g++.dg/ext/bases3.C 2018-04-03 09:39:28.301041301 +0200
@@ -0,0 +1,13 @@
+// PR c++/85146
+// { dg-do compile { target c++11 } }
+
+template struct A {};
+
+template struct B
+{
+ typedef A<__direct_bases(T)...> C;
+};
+
+struct X;
+
+B b;
Jakub
[C++ PATCH] Fix cp_finish_decl error recovery (PR c++/85134)
Hi!
When we clear DECL_DECLARED_CONSTEXPR_P because the decl doesn't have
literal type, we returned immediately, which unfortunately breaks e.g.
OpenMP gimplification, as required DECL_EXPR is not emitted for VLA vars.
This patch instead of returning immediately just clears it and so that
we don't ICE on constexpr-ice19.C also clears init and DECL_EXTERNAL for
static data members (or should we return immediately for the static data
members like we used to do and only fall through for other decls)?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-04-03 Jakub Jelinek
PR c++/85134
* decl.c (cp_finish_decl): If ensure_literal_type_for_constexpr_object
fails, after clearing DECL_DECLARED_CONSTEXPR_P don't return early,
instead for static data members clear init and set DECL_EXTERNAL.
* g++.dg/gomp/pr85134.C: New test.
* g++.dg/cpp0x/constexpr-ice19.C: Expect one further error.
--- gcc/cp/decl.c.jj2018-03-27 12:54:48.049242949 +0200
+++ gcc/cp/decl.c 2018-04-03 11:48:40.396539609 +0200
@@ -6923,11 +6923,14 @@ cp_finish_decl (tree decl, tree init, bo
cp_apply_type_quals_to_decl (cp_type_quals (type), decl);
}
- if (ensure_literal_type_for_constexpr_object (decl)
- == error_mark_node)
+ if (ensure_literal_type_for_constexpr_object (decl) == error_mark_node)
{
DECL_DECLARED_CONSTEXPR_P (decl) = 0;
- return;
+ if (VAR_P (decl) && DECL_CLASS_SCOPE_P (decl))
+ {
+ init = NULL_TREE;
+ DECL_EXTERNAL (decl) = 1;
+ }
}
if (VAR_P (decl)
--- gcc/testsuite/g++.dg/gomp/pr85134.C.jj 2018-04-03 11:06:22.533539818
+0200
+++ gcc/testsuite/g++.dg/gomp/pr85134.C 2018-04-03 11:06:13.333540153 +0200
@@ -0,0 +1,11 @@
+// PR c++/85134
+// { dg-do compile }
+// { dg-options "-std=c++14 -fopenmp" }
+
+void
+foo (int i)
+{
+ constexpr int x[i] = {}; // { dg-error "'constexpr' variable 'x' has
variably-modified type" }
+#pragma omp parallel shared(x)
+ ;
+}
--- gcc/testsuite/g++.dg/cpp0x/constexpr-ice19.C.jj 2018-01-17
22:00:11.747228288 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-ice19.C2018-04-03
11:50:28.203541642 +0200
@@ -9,5 +9,5 @@ struct A
struct B
{
- static constexpr A a {}; // { dg-error "not literal" }
+ static constexpr A a {}; // { dg-error "not literal|in-class
initialization" }
};
Jakub
[C++ PATCH] Fix namespace attribute error recovery (PR c++/85140)
Hi!
If at least one attribute is errorneous, we get error_mark_node instead
of the attributes list.
The following patch fixes error recovery for that. Bootstrapped/regtested
on x86_64-linux and i686-linux, ok for trunk?
2018-04-03 Jakub Jelinek
PR c++/85140
* name-lookup.c (handle_namespace_attrs): Return early if attributes
is error_mark_node.
* g++.dg/cpp0x/gen-attrs-64.C: New test.
--- gcc/cp/name-lookup.c.jj 2018-03-30 20:37:36.219184285 +0200
+++ gcc/cp/name-lookup.c2018-04-03 10:15:22.670803588 +0200
@@ -5044,6 +5044,9 @@ handle_namespace_attrs (tree ns, tree at
tree d;
bool saw_vis = false;
+ if (attributes == error_mark_node)
+return false;
+
for (d = attributes; d; d = TREE_CHAIN (d))
{
tree name = get_attribute_name (d);
--- gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C.jj2018-04-03
10:18:55.196780292 +0200
+++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C 2018-04-03 10:17:57.064786662
+0200
@@ -0,0 +1,4 @@
+// PR c++/85140
+// { dg-do compile { target c++11 } }
+
+namespace N alignas() {} // { dg-error "expected" }
Jakub
[PATCH] Fix __builtin_expect folding (PR tree-optimization/85156)
Hi!
As the following testcases show, fold_builtin_expect replaces
__builtin_expect (x && y, z) with
__builtin_expect (x, z) && __builtin_expect (y, z)
and similarly for || instead of &&. It does so without any kind of
copying of the z argument, which means if it is e.g. statement expression
without side-effects we try to destructively gimplify it multiple times
and ICE the second time we do so. Or, as the other testcase shows,
if there are any side-effects in that argument, we evaluate them multiple
times.
Fixed by doing save_expr on that argument first. arg2 doesn't need it,
as it is provided only internally from the compiler and is always
INTEGER_CST or NULL, nothing else.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-04-03 Jakub Jelinek
PR tree-optimization/85156
* builtins.c (fold_builtin_expect): Use save_expr on arg1 to avoid
evaluating the argument multiple times.
* c-c++-common/pr85156.c: New test.
* gcc.c-torture/execute/pr85156.c: New test.
--- gcc/builtins.c.jj 2018-04-01 08:03:09.786562444 +0200
+++ gcc/builtins.c 2018-04-03 12:03:53.673566330 +0200
@@ -7998,6 +7998,7 @@ fold_builtin_expect (location_t loc, tre
{
tree op0 = TREE_OPERAND (inner, 0);
tree op1 = TREE_OPERAND (inner, 1);
+ arg1 = save_expr (arg1);
op0 = build_builtin_expect_predicate (loc, op0, arg1, arg2);
op1 = build_builtin_expect_predicate (loc, op1, arg1, arg2);
--- gcc/testsuite/c-c++-common/pr85156.c.jj 2018-04-03 12:06:53.056572306
+0200
+++ gcc/testsuite/c-c++-common/pr85156.c2018-04-03 12:07:34.557573689
+0200
@@ -0,0 +1,11 @@
+/* PR tree-optimization/85156 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -g" } */
+
+int a, b;
+
+int
+foo (void)
+{
+ return __builtin_expect (a ? b != 0 : 0, ({ 1; }));
+}
--- gcc/testsuite/gcc.c-torture/execute/pr85156.c.jj2018-04-03
12:09:34.095577676 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr85156.c 2018-04-03
12:09:20.886577235 +0200
@@ -0,0 +1,21 @@
+/* PR tree-optimization/85156 */
+
+int x, y;
+
+__attribute__((noipa)) int
+foo (int z)
+{
+ if (__builtin_expect (x ? y != 0 : 0, z++))
+return 7;
+ return z;
+}
+
+int
+main ()
+{
+ x = 1;
+ asm volatile ("" : "+m" (x), "+m" (y));
+ if (foo (10) != 11)
+__builtin_abort ();
+ return 0;
+}
Jakub
[committed] Fix ix86_expand_vector_set for V64QImode (PR target/85169)
Hi!
For V64QImode, elt can be 0 to 63, so 1 << elt invokes UB in the compiler
and we get wrong masks.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2018-04-03 Jakub Jelinek
PR target/85169
* config/i386/i386.c (ix86_expand_vector_set): Use
HOST_WIDE_INT_1U << elt instead of 1 << elt. Formatting fix.
* gcc.c-torture/execute/pr85169.c: New test.
* gcc.target/i386/avx512f-pr85169.c: New test.
* gcc.target/i386/avx512bw-pr85169.c: New test.
--- gcc/config/i386/i386.c.jj 2018-04-01 08:03:37.938565056 +0200
+++ gcc/config/i386/i386.c 2018-04-03 12:40:43.181665150 +0200
@@ -44163,12 +44163,14 @@ quarter:
where the mask is clear and second input operand otherwise. */
emit_insn (gen_blendm (target, target, tmp,
force_reg (mmode,
- gen_int_mode (1 << elt, mmode;
+ gen_int_mode (HOST_WIDE_INT_1U << elt,
+ mmode;
}
else if (use_vec_merge)
{
tmp = gen_rtx_VEC_DUPLICATE (mode, val);
- tmp = gen_rtx_VEC_MERGE (mode, tmp, target, GEN_INT (1 << elt));
+ tmp = gen_rtx_VEC_MERGE (mode, tmp, target,
+ GEN_INT (HOST_WIDE_INT_1U << elt));
emit_insn (gen_rtx_SET (target, tmp));
}
else
@@ -44177,7 +44179,7 @@ quarter:
emit_move_insn (mem, target);
- tmp = adjust_address (mem, inner_mode, elt*GET_MODE_SIZE (inner_mode));
+ tmp = adjust_address (mem, inner_mode, elt * GET_MODE_SIZE (inner_mode));
emit_move_insn (tmp, val);
emit_move_insn (target, mem);
--- gcc/testsuite/gcc.c-torture/execute/pr85169.c.jj2018-04-03
12:46:25.167770124 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr85169.c 2018-04-03
12:45:23.637725937 +0200
@@ -0,0 +1,22 @@
+/* PR target/85169 */
+
+typedef char V __attribute__((vector_size (64)));
+
+static void __attribute__ ((noipa))
+foo (V *p)
+{
+ V v = *p;
+ v[63] = 1;
+ *p = v;
+}
+
+int
+main ()
+{
+ V v = (V) { };
+ foo (&v);
+ for (unsigned i = 0; i < 64; i++)
+if (v[i] != (i == 63))
+ __builtin_abort ();
+ return 0;
+}
--- gcc/testsuite/gcc.target/i386/avx512f-pr85169.c.jj 2018-04-03
12:47:03.686797782 +0200
+++ gcc/testsuite/gcc.target/i386/avx512f-pr85169.c 2018-04-03
12:47:36.075821048 +0200
@@ -0,0 +1,18 @@
+/* PR target/85169 */
+/* { dg-do run { target avx512f } } */
+/* { dg-options "-O2 -mavx512f" } */
+
+#include "avx512f-check.h"
+
+int do_main (void);
+
+static void
+avx512f_test (void)
+{
+ do_main ();
+}
+
+#undef main
+#define main() do_main ()
+
+#include "../../gcc.c-torture/execute/pr85169.c"
--- gcc/testsuite/gcc.target/i386/avx512bw-pr85169.c.jj 2018-04-03
12:47:59.394837794 +0200
+++ gcc/testsuite/gcc.target/i386/avx512bw-pr85169.c2018-04-03
12:48:09.441845006 +0200
@@ -0,0 +1,18 @@
+/* PR target/85169 */
+/* { dg-do run { target avx512bw } } */
+/* { dg-options "-O2 -mavx512bw" } */
+
+#include "avx512bw-check.h"
+
+int do_main (void);
+
+static void
+avx512bw_test (void)
+{
+ do_main ();
+}
+
+#undef main
+#define main() do_main ()
+
+#include "../../gcc.c-torture/execute/pr85169.c"
Jakub
[PATCH] Fix UB in shrink-wrapping (PR rtl-optimization/85167)
Hi!
The bb_uses and bb_defs bitmaps are never used if !*split_p, the comments
even describe why:
/* For the new created basic block, there is no dataflow info at all.
So skip the following dataflow update and check. */
On the new bb in that case DF_LR_BB_INFO is NULL, so &(NULL->field) is
UB.
Fixed thusly, the NULL init added there just in case uninit can't figure it
out in some bootstrap mode.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-04-03 Jakub Jelinek
PR rtl-optimization/85167
* shrink-wrap.c (move_insn_for_shrink_wrap): Don't set bb_uses and
bb_defs if *split_p, instead preinitialize it to NULL.
* gcc.dg/pr85167.c: New test.
--- gcc/shrink-wrap.c.jj2018-02-10 00:21:18.284975396 +0100
+++ gcc/shrink-wrap.c 2018-04-03 13:06:54.183464995 +0200
@@ -157,7 +157,7 @@ move_insn_for_shrink_wrap (basic_block b
struct dead_debug_local *debug)
{
rtx set, src, dest;
- bitmap live_out, live_in, bb_uses, bb_defs;
+ bitmap live_out, live_in, bb_uses = NULL, bb_defs = NULL;
unsigned int i, dregno, end_dregno;
unsigned int sregno = FIRST_PSEUDO_REGISTER;
unsigned int end_sregno = FIRST_PSEUDO_REGISTER;
@@ -330,8 +330,11 @@ move_insn_for_shrink_wrap (basic_block b
/* Check whether BB uses DEST or clobbers DEST. We need to add
INSN to BB if so. Either way, DEST is no longer live on entry,
except for any part that overlaps SRC (next loop). */
- bb_uses = &DF_LR_BB_INFO (bb)->use;
- bb_defs = &DF_LR_BB_INFO (bb)->def;
+ if (!*split_p)
+ {
+ bb_uses = &DF_LR_BB_INFO (bb)->use;
+ bb_defs = &DF_LR_BB_INFO (bb)->def;
+ }
if (df_live)
{
for (i = dregno; i < end_dregno; i++)
--- gcc/testsuite/gcc.dg/pr85167.c.jj 2018-04-03 13:14:13.532523126 +0200
+++ gcc/testsuite/gcc.dg/pr85167.c 2018-04-03 13:08:36.883478590 +0200
@@ -0,0 +1,16 @@
+/* PR rtl-optimization/85167 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -w" } */
+
+struct A { long b; };
+int c, d, e;
+int bar (void);
+
+int
+foo (void)
+{
+ long g;
+ for (; g == c ? 0 : (e = 1); g = ((struct A *)g)->b)
+if (bar ())
+ return d;
+}
Jakub
[PATCH] Fix libbacktrace zdebug decompression on big endian (PR other/85161)
Hi!
As mentioned in the PR, GCC (and clang) predefines
{__BYTE_ORDER__,__ORDER_{LITTLE,BIG,PDP}_ENDIAN__}
macros, and {,sys/,machine/}endian.h headers predefine
{,__}{BYTE_ORDER,{LITTLE,BIG,PDP}_ENDIAN}
macros (depending on which target and feature test macros).
elf.c in GCC 8 used __BYTE_ORDER, which is endian.h macro, but
didn't include that header and it on glibc just happened to be included
indirectly because of default feature test macros from stdlib.h,
and used non-existing __ORDER_BIG_ENDIAN macro; as __BYTE_ORDER is always
non-zero when defined (1234, 4321 etc.), that means __builtin_bswap32
was never used.
The following patch just uses the GCC/clang predefined macros if known to be
big or little endian, and otherwise just falls back to portable code (that
good compilers can still optimize).
Bootstrapped/regtested on x86_64-linux and i686-linux and tested on
powerpc64-linux, ok for trunk?
2018-04-03 Jakub Jelinek
PR other/85161
* elf.c (elf_zlib_fetch): Fix up predefined macro names in test for
big endian, only use 32-bit loads if endianity macros are predefined
and indicate big or little endian.
--- libbacktrace/elf.c.jj 2018-02-15 12:30:53.948579969 +0100
+++ libbacktrace/elf.c 2018-04-03 14:47:32.536550472 +0200
@@ -1086,12 +1086,19 @@ elf_zlib_fetch (const unsigned char **pp
return 0;
}
+#if defined(__BYTE_ORDER__) && defined(__ORDER_LITTLE_ENDIAN__) \
+&& defined(__ORDER_BIG_ENDIAN__) \
+&& (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ \
+|| __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
/* We've ensured that PIN is aligned. */
next = *(const uint32_t *)pin;
-#if __BYTE_ORDER == __ORDER_BIG_ENDIAN
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
next = __builtin_bswap32 (next);
#endif
+#else
+ next = pin[0] | (pin[1] << 8) | (pin[2] << 16) | (pin[3] << 24);
+#endif
val |= (uint64_t)next << bits;
bits += 32;
Jakub
Re: Fix PR 83913
On 03.04.2018 19:02, Alexander Monakov wrote: > On Tue, 3 Apr 2018, Andrey Belevantsev wrote: > >> Hello, >> >> This issue ended up being fixed the way different from described in the PR. >> We do not want to walk away from the invariant "zero SCHED_TIMES -- insn >> is not scheduled" even for bookkeeping copies (testing showed it trips over >> asserts designed to catch this). Rather we choose merging exprs in the way >> the larger sched-times wins. > > ... but the Changelog and the actual patch take the average rather than the > maximum sched-time? :) I believe either way would be acceptable, but please > clarify the intent. Sorry, the average is the intent. Just to have a bit more of pipelining chances. Andrey > > Alexander >
Re: [C++ PATCH] Fix cp_finish_decl error recovery (PR c++/85134)
OK.
On Tue, Apr 3, 2018 at 12:07 PM, Jakub Jelinek wrote:
> Hi!
>
> When we clear DECL_DECLARED_CONSTEXPR_P because the decl doesn't have
> literal type, we returned immediately, which unfortunately breaks e.g.
> OpenMP gimplification, as required DECL_EXPR is not emitted for VLA vars.
>
> This patch instead of returning immediately just clears it and so that
> we don't ICE on constexpr-ice19.C also clears init and DECL_EXTERNAL for
> static data members (or should we return immediately for the static data
> members like we used to do and only fall through for other decls)?
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-04-03 Jakub Jelinek
>
> PR c++/85134
> * decl.c (cp_finish_decl): If ensure_literal_type_for_
> constexpr_object
> fails, after clearing DECL_DECLARED_CONSTEXPR_P don't return early,
> instead for static data members clear init and set DECL_EXTERNAL.
>
> * g++.dg/gomp/pr85134.C: New test.
> * g++.dg/cpp0x/constexpr-ice19.C: Expect one further error.
>
> --- gcc/cp/decl.c.jj2018-03-27 12:54:48.049242949 +0200
> +++ gcc/cp/decl.c 2018-04-03 11:48:40.396539609 +0200
> @@ -6923,11 +6923,14 @@ cp_finish_decl (tree decl, tree init, bo
>cp_apply_type_quals_to_decl (cp_type_quals (type), decl);
> }
>
> - if (ensure_literal_type_for_constexpr_object (decl)
> - == error_mark_node)
> + if (ensure_literal_type_for_constexpr_object (decl) == error_mark_node)
> {
>DECL_DECLARED_CONSTEXPR_P (decl) = 0;
> - return;
> + if (VAR_P (decl) && DECL_CLASS_SCOPE_P (decl))
> + {
> + init = NULL_TREE;
> + DECL_EXTERNAL (decl) = 1;
> + }
> }
>
>if (VAR_P (decl)
> --- gcc/testsuite/g++.dg/gomp/pr85134.C.jj 2018-04-03
> 11:06:22.533539818 +0200
> +++ gcc/testsuite/g++.dg/gomp/pr85134.C 2018-04-03 11:06:13.333540153
> +0200
> @@ -0,0 +1,11 @@
> +// PR c++/85134
> +// { dg-do compile }
> +// { dg-options "-std=c++14 -fopenmp" }
> +
> +void
> +foo (int i)
> +{
> + constexpr int x[i] = {}; // { dg-error "'constexpr' variable 'x'
> has variably-modified type" }
> +#pragma omp parallel shared(x)
> + ;
> +}
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-ice19.C.jj 2018-01-17
> 22:00:11.747228288 +0100
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-ice19.C2018-04-03
> 11:50:28.203541642 +0200
> @@ -9,5 +9,5 @@ struct A
>
> struct B
> {
> - static constexpr A a {}; // { dg-error "not literal" }
> + static constexpr A a {}; // { dg-error "not literal|in-class
> initialization" }
> };
>
> Jakub
>
Re: [C++ PATCH] Fix namespace attribute error recovery (PR c++/85140)
OK.
On Tue, Apr 3, 2018 at 12:06 PM, Jakub Jelinek wrote:
> Hi!
>
> If at least one attribute is errorneous, we get error_mark_node instead
> of the attributes list.
>
> The following patch fixes error recovery for that. Bootstrapped/regtested
> on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-04-03 Jakub Jelinek
>
> PR c++/85140
> * name-lookup.c (handle_namespace_attrs): Return early if
> attributes
> is error_mark_node.
>
> * g++.dg/cpp0x/gen-attrs-64.C: New test.
>
> --- gcc/cp/name-lookup.c.jj 2018-03-30 20:37:36.219184285 +0200
> +++ gcc/cp/name-lookup.c2018-04-03 10:15:22.670803588 +0200
> @@ -5044,6 +5044,9 @@ handle_namespace_attrs (tree ns, tree at
>tree d;
>bool saw_vis = false;
>
> + if (attributes == error_mark_node)
> +return false;
> +
>for (d = attributes; d; d = TREE_CHAIN (d))
> {
>tree name = get_attribute_name (d);
> --- gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C.jj2018-04-03
> 10:18:55.196780292 +0200
> +++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C 2018-04-03
> 10:17:57.064786662 +0200
> @@ -0,0 +1,4 @@
> +// PR c++/85140
> +// { dg-do compile { target c++11 } }
> +
> +namespace N alignas() {} // { dg-error "expected" }
>
> Jakub
>
Re: [C++ PATCH] Fix error-recovery in fixed_parameter_pack_p_1 (PR c++/85147)
OK.
On Tue, Apr 3, 2018 at 12:06 PM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs in fixed_parameter_pack_p_1, because parm is
> error_mark_node and we assert it is one of the 3 TREE_CODEs we handle.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2018-04-03 Jakub Jelinek
>
> PR c++/85147
> * pt.c (fixed_parameter_pack_p_1): Punt if parm is error_mark_node.
>
> * g++.dg/cpp0x/pr85147.C: New test.
>
> --- gcc/cp/pt.c.jj 2018-03-30 20:37:36.0 +0200
> +++ gcc/cp/pt.c 2018-04-03 09:18:17.530206448 +0200
> @@ -5101,7 +5101,7 @@ static void
> fixed_parameter_pack_p_1 (tree parm, struct find_parameter_pack_data *ppd)
> {
>/* A type parm can't refer to another parm. */
> - if (TREE_CODE (parm) == TYPE_DECL)
> + if (TREE_CODE (parm) == TYPE_DECL || parm == error_mark_node)
> return;
>else if (TREE_CODE (parm) == PARM_DECL)
> {
> --- gcc/testsuite/g++.dg/cpp0x/pr85147.C.jj 2018-04-03
> 09:25:31.141148605 +0200
> +++ gcc/testsuite/g++.dg/cpp0x/pr85147.C2018-04-03
> 09:26:49.308138185 +0200
> @@ -0,0 +1,9 @@
> +// PR c++/85147
> +// { dg-do compile { target c++11 } }
> +
> +template struct A
> +{
> + template class...> struct B {}; // { dg-error
> "expected|mismatch" }
> +};
> +
> +A::B<> b; // { dg-error
> "does not name a template type" }
>
> Jakub
>
Re: [C++ PATCH] Fix __direct_bases ICE (PR c++/85146)
On Tue, Apr 3, 2018 at 12:06 PM, Jakub Jelinek wrote: > From N2965 it is unclear to me what should the trait do on classes with > incomplete types, but given that __bases already returns an empty pack, > this patch does the same for __direct_bases. > I think it should be ill-formed, i.e. call complete_type_or_maybe_complain from tsubst_pack_expansion. Jason
[PATCH] c/55976 -Werror=return-type should error on returning a value from a void function
This patch fixes handlng of -Werror=return-type. Currently, even with
the flag specified, return type errors remain warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976
Function c_finish_return (), when calling pedwarn, should specifiy
OPT_Wreturn_type as the diagnostic index if warn_return_type is set so
that the given diagnostic is generated as an error, not a warning.
Patch was successfully bootstrapped and tested on x86_64-linux.
--Dave
/c
2018-04-03 David Pagan
PR c/55976
* c-typeck.c (c_finish_return): If -Wreturn-type enabled
(warn_return_type), pass OPT_Wreturn_type to pedwarn so warning is
turned into an error when -Werror=return-type specified.
/testsuite
2018-04-03 David Pagan
PR c/55976
* gcc.dg/noncompile/pr55976.c: New test.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 259017)
+++ gcc/c/c-typeck.c(working copy)
@@ -10135,7 +10135,7 @@ c_finish_return (location_t loc, tree retval, tree
bool warned_here;
if (flag_isoc99)
warned_here = pedwarn
- (loc, 0,
+ (loc, warn_return_type ? OPT_Wreturn_type : 0,
"% with no value, in function returning non-void");
else
warned_here = warning_at
@@ -10153,7 +10153,7 @@ c_finish_return (location_t loc, tree retval, tree
bool warned_here;
if (TREE_CODE (TREE_TYPE (retval)) != VOID_TYPE)
warned_here = pedwarn
- (xloc, 0,
+ (xloc, warn_return_type ? OPT_Wreturn_type : 0,
"% with a value, in function returning void");
else
warned_here = pedwarn
Index: gcc/testsuite/gcc.dg/noncompile/pr55976.c
===
--- gcc/testsuite/gcc.dg/noncompile/pr55976.c (revision 0)
+++ gcc/testsuite/gcc.dg/noncompile/pr55976.c (working copy)
@@ -0,0 +1,12 @@
+/* PR c/55976 */
+/* { dg-do compile } */
+/* { dg-options "-Werror=return-type" } */
+
+void t () { return 1; } /* { dg-error "return" "function returning void" } */
+int b () { return; } /* { dg-error "return" "function returning non-void" } */
+
+int main()
+{
+ t(); b();
+ return 0;
+}
Re: [PATCH] Fix UB in shrink-wrapping (PR rtl-optimization/85167)
On April 3, 2018 6:07:17 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>The bb_uses and bb_defs bitmaps are never used if !*split_p, the
>comments
>even describe why:
> /* For the new created basic block, there is no dataflow info at all.
> So skip the following dataflow update and check. */
>On the new bb in that case DF_LR_BB_INFO is NULL, so &(NULL->field) is
>UB.
>Fixed thusly, the NULL init added there just in case uninit can't
>figure it
>out in some bootstrap mode.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>2018-04-03 Jakub Jelinek
>
> PR rtl-optimization/85167
> * shrink-wrap.c (move_insn_for_shrink_wrap): Don't set bb_uses and
> bb_defs if *split_p, instead preinitialize it to NULL.
>
> * gcc.dg/pr85167.c: New test.
>
>--- gcc/shrink-wrap.c.jj 2018-02-10 00:21:18.284975396 +0100
>+++ gcc/shrink-wrap.c 2018-04-03 13:06:54.183464995 +0200
>@@ -157,7 +157,7 @@ move_insn_for_shrink_wrap (basic_block b
> struct dead_debug_local *debug)
> {
> rtx set, src, dest;
>- bitmap live_out, live_in, bb_uses, bb_defs;
>+ bitmap live_out, live_in, bb_uses = NULL, bb_defs = NULL;
> unsigned int i, dregno, end_dregno;
> unsigned int sregno = FIRST_PSEUDO_REGISTER;
> unsigned int end_sregno = FIRST_PSEUDO_REGISTER;
>@@ -330,8 +330,11 @@ move_insn_for_shrink_wrap (basic_block b
> /* Check whether BB uses DEST or clobbers DEST. We need to add
>INSN to BB if so. Either way, DEST is no longer live on entry,
>except for any part that overlaps SRC (next loop). */
>- bb_uses = &DF_LR_BB_INFO (bb)->use;
>- bb_defs = &DF_LR_BB_INFO (bb)->def;
>+ if (!*split_p)
>+ {
>+bb_uses = &DF_LR_BB_INFO (bb)->use;
>+bb_defs = &DF_LR_BB_INFO (bb)->def;
>+ }
> if (df_live)
> {
> for (i = dregno; i < end_dregno; i++)
>--- gcc/testsuite/gcc.dg/pr85167.c.jj 2018-04-03 13:14:13.532523126
>+0200
>+++ gcc/testsuite/gcc.dg/pr85167.c 2018-04-03 13:08:36.883478590 +0200
>@@ -0,0 +1,16 @@
>+/* PR rtl-optimization/85167 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -w" } */
>+
>+struct A { long b; };
>+int c, d, e;
>+int bar (void);
>+
>+int
>+foo (void)
>+{
>+ long g;
>+ for (; g == c ? 0 : (e = 1); g = ((struct A *)g)->b)
>+if (bar ())
>+ return d;
>+}
>
> Jakub
Re: [PATCH] Fix __builtin_expect folding (PR tree-optimization/85156)
On April 3, 2018 6:07:06 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As the following testcases show, fold_builtin_expect replaces
>__builtin_expect (x && y, z) with
>__builtin_expect (x, z) && __builtin_expect (y, z)
>and similarly for || instead of &&. It does so without any kind of
>copying of the z argument, which means if it is e.g. statement
>expression
>without side-effects we try to destructively gimplify it multiple times
>and ICE the second time we do so. Or, as the other testcase shows,
>if there are any side-effects in that argument, we evaluate them
>multiple
>times.
>
>Fixed by doing save_expr on that argument first. arg2 doesn't need it,
>as it is provided only internally from the compiler and is always
>INTEGER_CST or NULL, nothing else.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>2018-04-03 Jakub Jelinek
>
> PR tree-optimization/85156
> * builtins.c (fold_builtin_expect): Use save_expr on arg1 to avoid
> evaluating the argument multiple times.
>
> * c-c++-common/pr85156.c: New test.
> * gcc.c-torture/execute/pr85156.c: New test.
>
>--- gcc/builtins.c.jj 2018-04-01 08:03:09.786562444 +0200
>+++ gcc/builtins.c 2018-04-03 12:03:53.673566330 +0200
>@@ -7998,6 +7998,7 @@ fold_builtin_expect (location_t loc, tre
> {
> tree op0 = TREE_OPERAND (inner, 0);
> tree op1 = TREE_OPERAND (inner, 1);
>+ arg1 = save_expr (arg1);
>
> op0 = build_builtin_expect_predicate (loc, op0, arg1, arg2);
> op1 = build_builtin_expect_predicate (loc, op1, arg1, arg2);
>--- gcc/testsuite/c-c++-common/pr85156.c.jj2018-04-03
>12:06:53.056572306 +0200
>+++ gcc/testsuite/c-c++-common/pr85156.c 2018-04-03 12:07:34.557573689
>+0200
>@@ -0,0 +1,11 @@
>+/* PR tree-optimization/85156 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -g" } */
>+
>+int a, b;
>+
>+int
>+foo (void)
>+{
>+ return __builtin_expect (a ? b != 0 : 0, ({ 1; }));
>+}
>--- gcc/testsuite/gcc.c-torture/execute/pr85156.c.jj 2018-04-03
>12:09:34.095577676 +0200
>+++ gcc/testsuite/gcc.c-torture/execute/pr85156.c 2018-04-03
>12:09:20.886577235 +0200
>@@ -0,0 +1,21 @@
>+/* PR tree-optimization/85156 */
>+
>+int x, y;
>+
>+__attribute__((noipa)) int
>+foo (int z)
>+{
>+ if (__builtin_expect (x ? y != 0 : 0, z++))
>+return 7;
>+ return z;
>+}
>+
>+int
>+main ()
>+{
>+ x = 1;
>+ asm volatile ("" : "+m" (x), "+m" (y));
>+ if (foo (10) != 11)
>+__builtin_abort ();
>+ return 0;
>+}
>
> Jakub
Re: [wwwdocs] gcc-8/changes.html
On 04/03/2018 05:16 AM, Martin Liška wrote: Hello. I would like to document features I prepared in time frame of GCC 8. Martin Just a few minor nits: @@ -113,6 +113,93 @@ possible for the user to have a finer-grained control over the loop unrolling optimization. + +GCOV tool can distinguish functions that begin on a same line in Suggest either "The GCOV tool" (or perhaps preferably utility), or just "GCOV." + GCOV has more accurate numbers for execution of source line executions. The duplication in "Number for executions of [...] executions" reads a little awkward. + Having a non-void function that does not return a value is considered as +undefined behavior. The compiler considers such code as unreachable and +makes more aggressive optimizations based on that. I think what we want to say might be something like: A return statement without an operand in a non-void function is considered unreachable and may be subject to optimization on that basis. It's not undefined to define such a function. What is undefined is reaching that statement. Martin
Re: RFC: Disable asan tests under ulimit -v
On Tue, Apr 3, 2018 at 12:56 PM, Jason Merrill wrote:
> On Mon, Mar 26, 2018 at 4:01 PM, Jason Merrill wrote:
>>
>> On Mon, Mar 26, 2018 at 2:55 PM, Andreas Schwab
>> wrote:
>> > On Mär 26 2018, Jakub Jelinek wrote:
>> >> On Mon, Mar 26, 2018 at 08:33:41PM +0200, Andreas Schwab wrote:
>> >>> On Mär 26 2018, Jason Merrill wrote:
>> >>>
>> >>> > if [catch {exec sh ulimit -v} ulimit_v] {
>> >>>
>> >>> expect1.1> exec sh ulimit -v
>> >>> sh: ulimit: No such file or directory
>> >>> while executing
>> >>> "exec sh ulimit -v"
>> >>
>> >> Perhaps
>> >> if [catch {exec sh -c ulimit -v} ulimit_v] {
>> >
>> > expect1.1> exec sh -c ulimit -v
>> > unlimited
>> > expect1.2> exec sh -c {ulimit -v}
>> > 4194304
>>
>> OK, so
>>
>> if ![is_remote target] {
>> if [catch {exec sh -c "ulimit -v"} ulimit_v] {
>> # failed to get ulimit
>> } elseif [regexp {^[0-9]+$} $ulimit_v] {
>> # ulimit -v gave a numeric limit
>> return
>> }
>> }
>
>
> This version adds a warning. OK for trunk?
commit 4ef44677627206e8ccc097a3dc3c411f6c4baece
Author: Jason Merrill
Date: Fri Mar 23 11:14:50 2018 -0400
* gcc.dg/asan/asan.exp: Don't run tests if ulimit -v is set.
* g++.dg/asan/asan.exp: Likewise.
diff --git a/gcc/testsuite/g++.dg/asan/asan.exp b/gcc/testsuite/g++.dg/asan/asan.exp
index 4ee8dd98697..5663ac6b635 100644
--- a/gcc/testsuite/g++.dg/asan/asan.exp
+++ b/gcc/testsuite/g++.dg/asan/asan.exp
@@ -24,6 +24,17 @@ load_lib asan-dg.exp
dg-init
asan_init
+# asan doesn't work if there's a ulimit on virtual memory.
+if ![is_remote target] {
+if [catch {exec sh -c "ulimit -v"} ulimit_v] {
+ # failed to get ulimit
+} elseif [regexp {^[0-9]+$} $ulimit_v] {
+ # ulimit -v gave a numeric limit
+ warning "skipping asan tests due to ulimit -v"
+ return
+}
+}
+
# Main loop.
if [check_effective_target_fsanitize_address] {
gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.C $srcdir/c-c++-common/asan/*.c]] "" ""
diff --git a/gcc/testsuite/gcc.dg/asan/asan.exp b/gcc/testsuite/gcc.dg/asan/asan.exp
index 7b669056a97..11135765911 100644
--- a/gcc/testsuite/gcc.dg/asan/asan.exp
+++ b/gcc/testsuite/gcc.dg/asan/asan.exp
@@ -26,6 +26,17 @@ load_lib asan-dg.exp
dg-init
asan_init
+# asan doesn't work if there's a ulimit on virtual memory.
+if ![is_remote target] {
+if [catch {exec sh -c "ulimit -v"} ulimit_v] {
+ # failed to get ulimit
+} elseif [regexp {^[0-9]+$} $ulimit_v] {
+ # ulimit -v gave a numeric limit
+ warning "skipping asan tests due to ulimit -v"
+ return
+}
+}
+
# Main loop.
if [check_effective_target_fsanitize_address] {
gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c $srcdir/c-c++-common/asan/*.c]] "" ""
Re: C++ PATCH to fix an ICE on invalid with OVERLOADs (PR c++/84854)
On Wed, Mar 21, 2018 at 4:14 PM, Marek Polacek wrote:
> On Wed, Mar 21, 2018 at 02:55:36PM -0400, Jason Merrill wrote:
>> On Wed, Mar 21, 2018 at 2:37 PM, Marek Polacek wrote:
>> > On Thu, Mar 15, 2018 at 08:55:59AM -0400, Jason Merrill wrote:
>> >> On Thu, Mar 15, 2018 at 7:49 AM, Marek Polacek wrote:
>> >> > On Wed, Mar 14, 2018 at 02:06:36PM -0400, Jason Merrill wrote:
>> >> >> On Wed, Mar 14, 2018 at 11:59 AM, Marek Polacek
>> >> >> wrote:
>> >> >> > cxx_constant_value doesn't understand template codes, and neither it
>> >> >> > understands OVERLOADs, so if we pass an OVERLOAD to it, we crash.
>> >> >> > Here
>> >> >> > instantiate_non_dependent_expr got an OVERLOAD, but since it calls
>> >> >> > is_nondependent_constant_expression which checks type_unknown_p, it
>> >> >> > left the
>> >> >> > expression as it was. We can't use
>> >> >> > is_nondependent_constant_expression in
>> >> >> > finish_if_stmt_cond because i_n_c_e checks is_constant_expression
>> >> >> > and that is
>> >> >> > not suitable here; we'd miss diagnostics. So I did the following; I
>> >> >> > think we
>> >> >> > should reject the testcase with an error.
>> >> >> >
>> >> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> >> >> >
>> >> >> > 2018-03-14 Marek Polacek
>> >> >> >
>> >> >> > PR c++/84854
>> >> >> > * semantics.c (finish_if_stmt_cond): Give error if the
>> >> >> > condition
>> >> >> > is an overloaded function with no contextual type
>> >> >> > information.
>> >> >> >
>> >> >> > * g++.dg/cpp1z/constexpr-if15.C: New test.
>> >> >> >
>> >> >> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
>> >> >> > index fdf37bea770..a056e9445e9 100644
>> >> >> > --- gcc/cp/semantics.c
>> >> >> > +++ gcc/cp/semantics.c
>> >> >> > @@ -735,8 +735,16 @@ finish_if_stmt_cond (tree cond, tree if_stmt)
>> >> >> >&& require_constant_expression (cond)
>> >> >> >&& !value_dependent_expression_p (cond))
>> >> >> > {
>> >> >> > - cond = instantiate_non_dependent_expr (cond);
>> >> >> > - cond = cxx_constant_value (cond, NULL_TREE);
>> >> >> > + if (type_unknown_p (cond))
>> >> >> > + {
>> >> >> > + cxx_incomplete_type_error (cond, TREE_TYPE (cond));
>> >> >> > + cond = error_mark_node;
>> >> >>
>> >> >> I think I'd prefer to skip this block when type_unknown_p, and leave
>> >> >> error handling up to the code shared with regular if.
>> >> >
>> >> > Like this?
>> >>
>> >> Yes, thanks.
>> >>
>> >> > It was my first version, but I thought we wanted the error;
>> >>
>> >> Getting an error is an improvement, but it should apply to
>> >> non-constexpr if as well, so checking in maybe_convert_cond would be
>> >> better. Actually, if we deal with unknown type there, we shouldn't
>> >> need this patch at all.
>> >>
>> >> ...except I also notice that since maybe_convert_cond doesn't do any
>> >> conversion in a template, we're trying to extract the constant value
>> >> without first converting to bool, which breaks this testcase:
>> >>
>> >> struct A
>> >> {
>> >> constexpr operator bool () { return true; }
>> >> int i;
>> >> };
>> >>
>> >> A a;
>> >>
>> >> template void f()
>> >> {
>> >> constexpr bool b = a; // works
>> >> if constexpr (a) { } // breaks
>> >> }
>> >>
>> >> int main()
>> >> {
>> >> f();
>> >> }
>> >>
>> >> A simple fix would be to replace your type_unknown_p check here with a
>> >> comparison to boolean_type_node, so we wait until instantiation time
>> >> to require a constant value.
>> >
>> > Ok, that works.
>> >
>> > We should also make g++ accept the testcase with "static_assert(a)"
>> > instead of
>> > "if constexpr (a) { }" probably.
>>
>> > I guess the cxx_constant_value call in
>> > finish_static_assert should happen earlier?
>>
>> fold_non_dependent_expr should already have gotten the constant value,
>> the call to cxx_constant_value is just for giving an error.
>
> Oop, right.
>
>> The bug seems to be that is_nondependent_constant_expression doesn't
>> realize that the conversion to bool is OK because it uses a constexpr
>> member function.
>
> OK, I can look into this separately.
>
>> >> Better would be to actually do the conversion. Perhaps this could
>> >> share code (for converting and getting a constant value) with
>> >> finish_static_assert.
>> >
>> > But this I didn't manage to make to work. If I call
>> > perform_implicit_conversion_flags
>> > in maybe_convert_cond, I get
>> > error: cannot resolve overloaded function ‘foo’ based on conversion to
>> > type ‘bool’
>> > so I'm not sure how the conversion would help.
>>
>> That looks like a good diagnostic to me, what's the problem?
>
> Ugh, I got this wrong. That diagnostic is fine, because we can reject
> constexpr-if15.C, but with perform_implicit_conversion_flags we then
> can't evaluate constexpr-if16.C:
> error: the value of ‘a’ is not usable in a constant expression
>
>> > Anyway, here's at least the boolean_type_node version.
>> >
[C++ PATCH] Fix error-recovery in fixed_parameter_pack_p_1 (PR c++/85147)
Hi!
The following testcase ICEs in fixed_parameter_pack_p_1, because parm is
error_mark_node and we assert it is one of the 3 TREE_CODEs we handle.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2018-04-03 Jakub Jelinek
PR c++/85147
* pt.c (fixed_parameter_pack_p_1): Punt if parm is error_mark_node.
* g++.dg/cpp0x/pr85147.C: New test.
--- gcc/cp/pt.c.jj 2018-03-30 20:37:36.0 +0200
+++ gcc/cp/pt.c 2018-04-03 09:18:17.530206448 +0200
@@ -5101,7 +5101,7 @@ static void
fixed_parameter_pack_p_1 (tree parm, struct find_parameter_pack_data *ppd)
{
/* A type parm can't refer to another parm. */
- if (TREE_CODE (parm) == TYPE_DECL)
+ if (TREE_CODE (parm) == TYPE_DECL || parm == error_mark_node)
return;
else if (TREE_CODE (parm) == PARM_DECL)
{
--- gcc/testsuite/g++.dg/cpp0x/pr85147.C.jj 2018-04-03 09:25:31.141148605
+0200
+++ gcc/testsuite/g++.dg/cpp0x/pr85147.C2018-04-03 09:26:49.308138185
+0200
@@ -0,0 +1,9 @@
+// PR c++/85147
+// { dg-do compile { target c++11 } }
+
+template struct A
+{
+ template class...> struct B {}; // { dg-error
"expected|mismatch" }
+};
+
+A::B<> b; // { dg-error "does not
name a template type" }
Jakub
C++ PATCH for c++/85149, generic lambda and constexpr if
Now that we partially instantiate generic lambdas, we run into an
issue with C++17 constexpr if: in the testcase, the branches of the
constexpr if become non-dependent when partially instantiated, but the
condition remains dependent. In that situation, we mustn't substitute
into the branches, so with this patch I use the
PACK_EXPANSION_EXTRA_ARGS mechanism for constexpr if as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9b3662644031b30cae50f802abd410d2eabd81fa
Author: Jason Merrill
Date: Mon Apr 2 16:51:19 2018 -0400
PR c++/85149 - generic lambda and constexpr if.
* pt.c (build_extra_args, add_extra_args): Split from
tsubst_pack_expansion.
(tsubst_expr) [IF_STMT]: Use them.
* cp-tree.h (IF_STMT_EXTRA_ARGS): New.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index db79338035d..f7bacd08c8f 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -4866,6 +4866,10 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)
#define IF_SCOPE(NODE) TREE_OPERAND (IF_STMT_CHECK (NODE), 3)
#define IF_STMT_CONSTEXPR_P(NODE) TREE_LANG_FLAG_0 (IF_STMT_CHECK (NODE))
+/* Like PACK_EXPANSION_EXTRA_ARGS, for constexpr if. IF_SCOPE is used while
+ building an IF_STMT; IF_STMT_EXTRA_ARGS is used after it is complete. */
+#define IF_STMT_EXTRA_ARGS(NODE) IF_SCOPE (NODE)
+
/* WHILE_STMT accessors. These give access to the condition of the
while statement and the body of the while statement, respectively. */
#define WHILE_COND(NODE) TREE_OPERAND (WHILE_STMT_CHECK (NODE), 0)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 284eaf3cab6..54d06fee09b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11663,6 +11663,46 @@ extract_local_specs (tree pattern, tsubst_flags_t complain)
return data.extra;
}
+/* Extract any uses of local_specializations from PATTERN and add them to ARGS
+ for use in PACK_EXPANSION_EXTRA_ARGS. */
+
+tree
+build_extra_args (tree pattern, tree args, tsubst_flags_t complain)
+{
+ tree extra = args;
+ if (local_specializations)
+if (tree locals = extract_local_specs (pattern, complain))
+ extra = tree_cons (NULL_TREE, extra, locals);
+ return extra;
+}
+
+/* Apply any local specializations from PACK_EXPANSION_EXTRA_ARGS and add the
+ normal template args to ARGS. */
+
+tree
+add_extra_args (tree extra, tree args)
+{
+ if (extra && TREE_CODE (extra) == TREE_LIST)
+{
+ for (tree elt = TREE_CHAIN (extra); elt; elt = TREE_CHAIN (elt))
+ {
+ /* The partial instantiation involved local declarations collected in
+ extract_local_specs; map from the general template to our local
+ context. */
+ tree gen = TREE_PURPOSE (elt);
+ tree inst = TREE_VALUE (elt);
+ if (DECL_P (inst))
+ if (tree local = retrieve_local_specialization (inst))
+ inst = local;
+ /* else inst is already a full instantiation of the pack. */
+ register_local_specialization (inst, gen);
+ }
+ gcc_assert (!TREE_PURPOSE (extra));
+ extra = TREE_VALUE (extra);
+}
+ return add_to_template_args (extra, args);
+}
+
/* Substitute ARGS into T, which is an pack expansion
(i.e. TYPE_PACK_EXPANSION or EXPR_PACK_EXPANSION). Returns a
TREE_VEC with the substituted arguments, a PACK_EXPANSION_* node
@@ -11686,26 +11726,7 @@ tsubst_pack_expansion (tree t, tree args, tsubst_flags_t complain,
pattern = PACK_EXPANSION_PATTERN (t);
/* Add in any args remembered from an earlier partial instantiation. */
- tree extra = PACK_EXPANSION_EXTRA_ARGS (t);
- if (extra && TREE_CODE (extra) == TREE_LIST)
-{
- for (tree elt = TREE_CHAIN (extra); elt; elt = TREE_CHAIN (elt))
- {
- /* The partial instantiation involved local declarations collected in
- extract_local_specs; map from the general template to our local
- context. */
- tree gen = TREE_PURPOSE (elt);
- tree inst = TREE_VALUE (elt);
- if (DECL_P (inst))
- if (tree local = retrieve_local_specialization (inst))
- inst = local;
- /* else inst is already a full instantiation of the pack. */
- register_local_specialization (inst, gen);
- }
- gcc_assert (!TREE_PURPOSE (extra));
- extra = TREE_VALUE (extra);
-}
- args = add_to_template_args (extra, args);
+ args = add_extra_args (PACK_EXPANSION_EXTRA_ARGS (t), args);
levels = TMPL_ARGS_DEPTH (args);
@@ -11881,11 +11902,8 @@ tsubst_pack_expansion (tree t, tree args, tsubst_flags_t complain,
have values for all the packs. So remember these until then. */
t = make_pack_expansion (pattern, complain);
- tree extra = args;
- if (local_specializations)
- if (tree locals = extract_local_specs (pattern, complain))
- extra = tree_cons (NULL_TREE, extra, locals);
- PACK_EXPANSION_EXTRA_ARGS (t) = extra;
+ PACK_EXPANSION_EXTRA_ARGS (t)
+ = build_extra_args (pattern, args, complain);
return t;
}
else if (unsubstituted_packs)
@@ -16485,8 +16503,24 @@ tsubst_expr (tree t, t
C++ PATCH to merge_types for malloc redeclaration
In this testcase, we have multiple declarations of malloc. The one in
the "system header" has a non-throwing exception specification, while
the one in user code has none. By default we allow this mismatch when
the old declaration is in a system header, but we mean to prefer the
type of the user declaration. In this testcase that was breaking
because the old declaration had attributes added by the compiler, and
the code at the bottom of merge_types decided to throw away the work
earlier in the function to build up a new FUNCTION_TYPE in t1 because
t2 had the right attributes. This is a C++17 regression.
Fixed by limiting the attribute checking code to the case where we
aren't building up a new type in t1.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0249b02abba1c309eaf118a0ef158a32f6833cb3
Author: Jason Merrill
Date: Mon Apr 2 17:49:06 2018 -0400
Fix noexcept merging with system headers.
* typeck.c (merge_types): Limit matching attribute shortcut to
the default case.
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index d454c6c5a29..e33f2c34c7f 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -899,14 +899,14 @@ merge_types (tree t1, tree t2)
return t1;
default:;
+ if (attribute_list_equal (TYPE_ATTRIBUTES (t1), attributes))
+ return t1;
+ else if (attribute_list_equal (TYPE_ATTRIBUTES (t2), attributes))
+ return t2;
+ break;
}
- if (attribute_list_equal (TYPE_ATTRIBUTES (t1), attributes))
-return t1;
- else if (attribute_list_equal (TYPE_ATTRIBUTES (t2), attributes))
-return t2;
- else
-return cp_build_type_attribute_variant (t1, attributes);
+ return cp_build_type_attribute_variant (t1, attributes);
}
/* Return the ARRAY_TYPE type without its domain. */
diff --git a/gcc/testsuite/g++.dg/cpp1z/noexcept-type19.C b/gcc/testsuite/g++.dg/cpp1z/noexcept-type19.C
new file mode 100644
index 000..571c426aa67
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/noexcept-type19.C
@@ -0,0 +1,14 @@
+// { dg-do compile { target c++11 } }
+
+#include "noexcept-type19.h"
+
+extern "C" void *malloc (size_t);
+
+template void f(T*);
+
+void *g(size_t);
+
+int main()
+{
+ f(g);
+}
diff --git a/gcc/testsuite/g++.dg/cpp1z/noexcept-type19.h b/gcc/testsuite/g++.dg/cpp1z/noexcept-type19.h
new file mode 100644
index 000..33a29357e7f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/noexcept-type19.h
@@ -0,0 +1,4 @@
+#pragma GCC system_header
+
+typedef decltype(sizeof(0)) size_t;
+extern "C" void *malloc (size_t) throw();
Re: [PATCH, testsuite, 2/2] Add scan-ltrans-tree-dump
>This patch adds scan-ltrans-tree-dump. Please check all error calls to talk about the correct function -- at least scan-ltrans-tree-dump-times is wrong. thanks, > >Bootstrapped and reg-tested on x86_64. > >OK for stage4/stage1 trunk? > >Thanks, >- Tom
Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps
On 4/2/18 9:21 AM, Alexander Monakov wrote:
> On Tue, 27 Mar 2018, Richard Biener wrote:
>> If they only appear in the exit/entry block ignoring them should be safe.
>>
>> But who knows...
>
> Roman and I discussed a related problem a few weeks ago, so here's my 2c.
> As I don't have any special DF knowledge, this is merely my understanding.
>
> (apropos i: SMS uses sched-deps for intra-loop deps, and then separately uses
> DF for cross-iteration deps, which means that it should be ready for surprises
> when the two scanners are not 100% in sync)
>
> (apropos ii: given the flexibility of RTL, it would have been really nice
> if there were no implicit cc0-like uses that need to be special-cased in DF,
> sched-deps and other scanners)
>
> In this case I believe it's fine to skip processing of r_use when the
> associated
> BB is not the loop BB (i.e. 'if (DF_REF_BB (r_use->ref) != g->bb)' as Richard
> suggested), but I'm concerned that skipping it when the artificial's use BB
> corresponds to loop BB goes from ICE to wrong-code. It should be detected
> earlier, in sms_schedule (see the comment starting with "Don't handle BBs with
> calls or barriers").
Ok, getting back to this, I see the r_use->ref for the global reg that
is exposed all the way to the exit block is marked as artificial, so
DF_REF_IS_ARTIFICIAL (r_use->ref) is true. So using richi and Alexander's
suggestion of DF_REF_BB(), I cobbled the change below. I added an assert
to catch any cases where the artificial use is the same as g->bb or where
we still might have no insn info. I never hit the assert in either my
bootstrap or in my testsuite runs. Is something like the following what
we want?
This did pass bootstrap and regtesting with no regressions on powerpc64-linux
running the testsuite in both 32-bit and 64-bit modes.
Peter
gcc/
PR rtl-optimization/84878
* ddg.c (add_cross_iteration_register_deps): Use DF_REF_BB to determine
the basic block. Assert the use reference is not artificial and that
it has an associated insn.
gcc/testsuite/
PR rtl-optimization/84878
* gcc.dg/pr84878.c: New test.
Index: gcc/ddg.c
===
--- gcc/ddg.c (revision 258802)
+++ gcc/ddg.c (working copy)
@@ -295,11 +295,14 @@ add_cross_iteration_register_deps (ddg_p
/* Create inter-loop true dependences and anti dependences. */
for (r_use = DF_REF_CHAIN (last_def); r_use != NULL; r_use = r_use->next)
{
- rtx_insn *use_insn = DF_REF_INSN (r_use->ref);
-
- if (BLOCK_FOR_INSN (use_insn) != g->bb)
+ if (DF_REF_BB (r_use->ref) != g->bb)
continue;
+ gcc_assert (!DF_REF_IS_ARTIFICIAL (r_use->ref)
+ && DF_REF_INSN_INFO (r_use->ref) != NULL);
+
+ rtx_insn *use_insn = DF_REF_INSN (r_use->ref);
+
/* ??? Do not handle uses with DF_REF_IN_NOTE notes. */
use_node = get_node_of_insn (g, use_insn);
gcc_assert (use_node);
Index: gcc/testsuite/gcc.target/powerpc/pr84878.c
===
--- gcc/testsuite/gcc.target/powerpc/pr84878.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr84878.c (working copy)
@@ -0,0 +1,18 @@
+/* PR target/84878 */
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-O2 -maltivec -mno-vsx -fmodulo-sched -ftree-vectorize
-funroll-loops -fassociative-math -fno-signed-zeros -fno-trapping-math" } */
+
+int ek;
+float zu;
+
+int
+k5 (int ks)
+{
+ while (ek < 1)
+{
+ ks += (int)(0x100 + zu + !ek);
+ ++ek;
+}
+ return ks;
+}
Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps
On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner wrote:
> On 4/2/18 9:21 AM, Alexander Monakov wrote:
>> On Tue, 27 Mar 2018, Richard Biener wrote:
>>> If they only appear in the exit/entry block ignoring them should be safe.
>>>
>>> But who knows...
>>
>> Roman and I discussed a related problem a few weeks ago, so here's my 2c.
>> As I don't have any special DF knowledge, this is merely my understanding.
>>
>> (apropos i: SMS uses sched-deps for intra-loop deps, and then separately uses
>> DF for cross-iteration deps, which means that it should be ready for
>> surprises
>> when the two scanners are not 100% in sync)
>>
>> (apropos ii: given the flexibility of RTL, it would have been really nice
>> if there were no implicit cc0-like uses that need to be special-cased in DF,
>> sched-deps and other scanners)
>>
>> In this case I believe it's fine to skip processing of r_use when the
>> associated
>> BB is not the loop BB (i.e. 'if (DF_REF_BB (r_use->ref) != g->bb)' as Richard
>> suggested), but I'm concerned that skipping it when the artificial's use BB
>> corresponds to loop BB goes from ICE to wrong-code. It should be detected
>> earlier, in sms_schedule (see the comment starting with "Don't handle BBs
>> with
>> calls or barriers").
>
> Ok, getting back to this, I see the r_use->ref for the global reg that
> is exposed all the way to the exit block is marked as artificial, so
> DF_REF_IS_ARTIFICIAL (r_use->ref) is true. So using richi and Alexander's
> suggestion of DF_REF_BB(), I cobbled the change below. I added an assert
> to catch any cases where the artificial use is the same as g->bb or where
> we still might have no insn info. I never hit the assert in either my
> bootstrap or in my testsuite runs. Is something like the following what
> we want?
>
> This did pass bootstrap and regtesting with no regressions on powerpc64-linux
> running the testsuite in both 32-bit and 64-bit modes.
>
> Peter
>
>
> gcc/
> PR rtl-optimization/84878
> * ddg.c (add_cross_iteration_register_deps): Use DF_REF_BB to
> determine
> the basic block. Assert the use reference is not artificial and that
> it has an associated insn.
>
> gcc/testsuite/
> PR rtl-optimization/84878
> * gcc.dg/pr84878.c: New test.
Wrong test filename.
>
> Index: gcc/ddg.c
> ===
> --- gcc/ddg.c (revision 258802)
> +++ gcc/ddg.c (working copy)
> @@ -295,11 +295,14 @@ add_cross_iteration_register_deps (ddg_p
>/* Create inter-loop true dependences and anti dependences. */
>for (r_use = DF_REF_CHAIN (last_def); r_use != NULL; r_use = r_use->next)
> {
> - rtx_insn *use_insn = DF_REF_INSN (r_use->ref);
> -
> - if (BLOCK_FOR_INSN (use_insn) != g->bb)
> + if (DF_REF_BB (r_use->ref) != g->bb)
> continue;
>
> + gcc_assert (!DF_REF_IS_ARTIFICIAL (r_use->ref)
> + && DF_REF_INSN_INFO (r_use->ref) != NULL);
> +
> + rtx_insn *use_insn = DF_REF_INSN (r_use->ref);
> +
>/* ??? Do not handle uses with DF_REF_IN_NOTE notes. */
>use_node = get_node_of_insn (g, use_insn);
>gcc_assert (use_node);
> Index: gcc/testsuite/gcc.target/powerpc/pr84878.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/pr84878.c (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/pr84878.c (working copy)
> @@ -0,0 +1,18 @@
> +/* PR target/84878 */
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-options "-O2 -maltivec -mno-vsx -fmodulo-sched -ftree-vectorize
> -funroll-loops -fassociative-math -fno-signed-zeros -fno-trapping-math" } */
> +
> +int ek;
> +float zu;
> +
> +int
> +k5 (int ks)
> +{
> + while (ek < 1)
> +{
> + ks += (int)(0x100 + zu + !ek);
> + ++ek;
> +}
> + return ks;
> +}
>
--
H.J.
PING^4: [PATCH] Use dlsym to check if libdl is needed for plugin
On Mon, Mar 26, 2018 at 4:10 AM, H.J. Lu wrote: > On Wed, Mar 14, 2018 at 4:41 AM, H.J. Lu wrote: >> On Wed, Feb 21, 2018 at 3:02 AM, H.J. Lu wrote: >>> On Wed, Oct 18, 2017 at 5:25 PM, H.J. Lu wrote: config/plugins.m4 has if test "$plugins" = "yes"; then AC_SEARCH_LIBS([dlopen], [dl]) fi Plugin uses dlsym, but libasan.so only intercepts dlopen, not dlsym: [hjl@gnu-tools-1 binutils-text]$ nm -D /lib64/libasan.so.4| grep " dl" 00038580 W dlclose U dl_iterate_phdr 0004dc50 W dlopen U dlsym U dlvsym [hjl@gnu-tools-1 binutils-text]$ Testing dlopen for libdl leads to false negative when -fsanitize=address is used. It results in link failure: ../bfd/.libs/libbfd.a(plugin.o): undefined reference to symbol 'dlsym@@GLIBC_2.16' dlsym should be used to check if libdl is needed for plugin. OK for master? H.J. --- config/ * plugins.m4 (AC_PLUGINS): Use dlsym to check if libdl is needed. >> >> >> PING. >> > > PING. > PING. -- H.J.
Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps
On 4/3/18 1:40 PM, H.J. Lu wrote: > On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner wrote: >> gcc/testsuite/ >> PR rtl-optimization/84878 >> * gcc.dg/pr84878.c: New test. > > Wrong test filename. Ooops, thanks for spotting that! Will fix. Peter
C++ PATCH for c++/85092, C++17 ICE with unused list constructor
Here, because the class has a list constructor, we avoid the shortcut
in build_special_member_call, so we need to use the new backup path
for C++17 copy elision in build_over_call, which means teaching
conv_binds_ref_to_prvalue about this case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 053b17904db3de54265a6cda7dcd90390b0753b1
Author: Jason Merrill
Date: Tue Apr 3 14:10:44 2018 -0400
PR c++/85092 - C++17 ICE with unused list constructor.
* call.c (conv_binds_ref_to_prvalue): Also count ck_identity
from a TARGET_EXPR.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 9351918b23a..901f18c43e6 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7611,6 +7611,9 @@ conv_binds_ref_to_prvalue (conversion *c)
return true;
if (c->kind == ck_user && TREE_CODE (c->type) != REFERENCE_TYPE)
return true;
+ if (c->kind == ck_identity && c->u.expr
+ && TREE_CODE (c->u.expr) == TARGET_EXPR)
+return true;
return false;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist99.C b/gcc/testsuite/g++.dg/cpp0x/initlist99.C
new file mode 100644
index 000..d96f793d398
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist99.C
@@ -0,0 +1,13 @@
+// PR c++/85092
+// { dg-do compile { target c++11 } }
+
+#include
+
+struct A
+{
+ A (std::initializer_list);
+};
+
+A f ();
+
+A a { f () };
C++ PATCH for c++/85113, ICE with constexpr and __builtin_constant_p.
My recent patch to make sure that we've given an error for failed
template argument conversion caught this latent bug: when we evaluate
__builtin_constant_p within a constexpr function, we don't fold it
until later, at constexpr evaluation time when we have values for the
arguments. Which makes sense for the maybe_constant_value case. But
here we require a constant value, but are silently calling it
non-constant. So only do the deferral if we're being quiet about
non-constant expressions.
Tested x86_64-pc-linux-gnu, applying to trunk and 7.
commit be9bfa78348d2f5aec7209e126cf77ec89d60fc3
Author: Jason Merrill
Date: Tue Apr 3 13:59:29 2018 -0400
PR c++/85113 - ICE with constexpr and __builtin_constant_p.
* constexpr.c (cxx_eval_builtin_function_call): Only defer
__builtin_constant_p if ctx->quiet.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index bebd9f5b5d0..201f27d8e66 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1171,7 +1171,10 @@ cxx_eval_builtin_function_call (const constexpr_ctx *ctx, tree t, tree fun,
/* Don't fold __builtin_constant_p within a constexpr function. */
bool bi_const_p = (DECL_FUNCTION_CODE (fun) == BUILT_IN_CONSTANT_P);
+ /* If we aren't requiring a constant expression, defer __builtin_constant_p
+ in a constexpr function until we have values for the parameters. */
if (bi_const_p
+ && ctx->quiet
&& current_function_decl
&& DECL_DECLARED_CONSTEXPR_P (current_function_decl))
{
diff --git a/gcc/testsuite/g++.dg/ext/builtin12.C b/gcc/testsuite/g++.dg/ext/builtin12.C
new file mode 100644
index 000..1d6bb75cd77
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/builtin12.C
@@ -0,0 +1,10 @@
+// PR c++/85113
+// { dg-do compile { target c++14 } }
+
+template struct A {};
+
+constexpr int foo()
+{
+ A<__builtin_constant_p(0)> a{};
+ return 0;
+}
Re: [PATCH] c/55976 -Werror=return-type should error on returning a value from a void function
On 04/03/2018 10:26 AM, dave.pa...@oracle.com wrote: This patch fixes handlng of -Werror=return-type. Currently, even with the flag specified, return type errors remain warnings. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976 Function c_finish_return (), when calling pedwarn, should specifiy OPT_Wreturn_type as the diagnostic index if warn_return_type is set so that the given diagnostic is generated as an error, not a warning. Patch was successfully bootstrapped and tested on x86_64-linux. I would expect the option to control the warning consistently so that when the test case is compiled with just -Wno-return-type (and no other options) the warning is not issued. But that's not what happens because pedwarn() is called with a zero argument as the option. Martin
Re: New template for 'gcc' made available
On Mon, 2 Apr 2018, Translation Project Robot wrote: > Hello, gentle maintainer. > > This is a message from the Translation Project robot. (If you have > any questions, send them to .) > > A new POT file for textual domain 'gcc' has been made available > to the language teams for translation. It is archived as: > > http://translationproject.org/POT-files/gcc-8-b20180401.pot I'm concerned that http://translationproject.org/domain/gcc.html is still listing the 20180128 .pot file as current (and thus translators may still wrongly be working on that old version without subsequent message fixes), although the 20180401 tarball is listed as the corresponding sources. -- Joseph S. Myers jos...@codesourcery.com
[wwwdocs] document new options in gcc-8/changes.html
The attached changes add documentation of some of the options
I worked on for GCC 8.
The links to the GCC 8 manual don't work because there is no
gcc-8 documentation directory. I have checked them by hand
by substituting the GCC 7 directory. (I wonder: would it be
possible to populate the GCC 8 documentation directory ahead
of the release to make the checking easier?)
I fixed all the errors for the document pointed out by
the Markup Validator at https://validator.w3.org/check.
Martin
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.50
diff -u -r1.50 changes.html
--- changes.html 1 Apr 2018 22:19:57 - 1.50
+++ changes.html 3 Apr 2018 20:47:33 -
@@ -1,3 +1,4 @@
+
@@ -9,7 +10,7 @@
-->
-GCC 8 Release SeriesChanges, New Features, and Fixes
+GCC 8 Release SeriesChanges, New Features, and Fixes
This page is a "brief" summary of some of the huge number of improvements
@@ -108,6 +109,20 @@
thus mitigate the attack vector that relies on jumping over
a stack guard page as provided by the operating system.
+
+GCC has been enhanced to detect more instances of meaningless or
+mutually exclusive attribute specifications and hande such conflicts
+more consistently. Mutually excclusive attribute specifications are
+ignored with a warning regardless of whether they appear on the same
+declaration or on distinct declarations of the same entitiy. For
+example, because the noreturn attribute on the second
+declaration below is mutually exclusive with the malloc
+attribute on the first, it is ignored and a warning is issued.
+
+ void* __attribute__ ((malloc)) f (unsigned);
+ void* __attribute__ ((noreturn)) f (unsigned);
+
+ warning: ignoring attribute 'noreturn' because it conflicts with attribute 'malloc' [-Wattributes]
@@ -163,10 +178,41 @@
New command-line options have been added for the C and C++ compilers:
- -Wmultistatement-macros warns about unsafe macros
- expanding to multiple statements used as a body of a clause such
- as if, else, while,
- switch, or for.
+ https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wmultistatement-macros";>-Wmultistatement-macros
+ warns about unsafe macros expanding to multiple statements used
+ as a body of a statement such as if, else,
+ while, switch, or for.
+ https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wstringop-truncation";>-Wstringop-truncation
+ warns for calls to bounded string manipulation functions such as
+ strncat, strncpy, and stpncpy
+ that might either truncate the copied string or leave the destination
+ unchanged. For example, the following call to strncat
+ is diagnosed because it appends just three of the four characters
+ from the source string.
+ void append (char *buf, size_t bufsize)
+ {
+ strncat (buf, ".txt", 3);
+ }
+ warning: 'strncat' output truncated copying 3 bytes from a string of length 4 [-Wstringop-truncation]
+ Similarly, in the following example, the call to strncpy
+ specifies the size of the destination buffer as the bound. If the
+ length of the source string is equal to or greater than this size
+ the result of the copy will not be NUL-terminated. Therefore,
+ the call is also diagnosed. To avoid the warning, specify
+ sizeof buf - 1 as the bound and set the last element of
+ the buffer to NUL.
+ void copy (const char *s)
+ {
+ char buf[80];
+ strncpy (buf, s, sizeof buf);
+ …
+ }
+ warning: 'strncpy' specified bound 80 equals destination size [-Wstringop-truncation]
+ The -Wstringop-truncation option is included in
+ -Wall.
+ Note that due to GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82944"; title="missing -Wstringop-truncation on strncpy due to system header macro">82944, defining strncat, strncpy,
+ or stpncpy as a macro in a system header as some
+ implementations do suppresses the warning.
-fno-strict-overflow is now mapped to
@@ -174,11 +220,57 @@
is now undefined by default at all optimization levels. Using
-fsanitize=signed-integer-overflow is now the preferred
way to audit code, -Wstrict-overflow is deprecated.
+The https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Warray-bounds";>-Warray-bounds option has been
+ improved to detect more instances of out-of-bounds array indices and
+ pointer offsets. For example, negative or excessive indices into
+ flexible array members and string literals are detected.
+The https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wrestrict";>-Wrestrict option introduced in
+ GCC 7 has been enhanced to detect many more instances of overlapping
+ accesses to objects via restrict-qualified arguments to
Re: [patch, fortran] Simplify constants which come from parameter arrays
Am 03.04.2018 um 17:21 schrieb Dominique d'Humières: Hi Dominique, The new patch regtest fine now. However as said on IRC this looks as a kludge made necessary by a questionable (invalid) test. What I want to avoid is to have first an error and then a warning for the same thing. If we say that doesn't matter, I am also fine with that. IMO it would be more general (better) to call gfc_simplify_expr (e, 1); only when there is no pending error (warning?). That makes less sense than the current approach. We do not want to grow the size of an executable because the code has, let's say, a conversion warning somewhere. I have also a question about "is out of bounds": it is a warning in > resolve.c, but an error in expr.c and simplify.c. Should not it be> an error everywhere? It is inconsistent now. We had this general discussion last year, when adding the -Wdo-subsript code, and I think we should fix this, but not in time for gcc 8. Suggested way forward: Apply the patch as is and open an PR to sort out the warning/error stuff for out-of-bounds access to be resolved consistently for gcc-9. OK? Regards Thomas
[PATCH] Fix x86 vinsert[if]{32x4,64x2} patterns (PR target/85177)
Hi!
The following testcase is miscompiled, because for vinserti32x4 the expander
creates an incorrect VEC_MERGE selector; it matches what the define_insn
later does, so often it works properly, but when the middle-end sees the
RTL, it can try to simplify it (in this case fwprop1, but in theory also
e.g. combiner when using simplify-rtx etc.).
The bits in the VEC_MERGE selector are ordered lowest bit determines lowest
vector element (from which of the first two VEC_MERGE operand it is taken),
but the define_expand and define_insn were instead counting them from
highest bit.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2018-04-03 Jakub Jelinek
PR target/85177
* config/i386/sse.md
(_vinsert_mask): Fix
computation of the VEC_MERGE selector from mask.
(_vinsert_1):
Fix decoding of the VEC_MERGE selector into mask.
* gcc.target/i386/avx512f-pr85177.c: New test.
--- gcc/config/i386/sse.md.jj 2018-04-01 08:03:37.771565040 +0200
+++ gcc/config/i386/sse.md 2018-04-03 16:41:23.001090852 +0200
@@ -12627,11 +12627,11 @@ (define_expand "_vinsert 5 "register_operand")]
"TARGET_AVX512F"
{
- int mask,selector;
+ int mask, selector;
mask = INTVAL (operands[3]);
- selector = GET_MODE_UNIT_SIZE (mode) == 4 ?
-0x ^ (0xF000 >> mask * 4)
-: 0xFF ^ (0xC0 >> mask * 2);
+ selector = (GET_MODE_UNIT_SIZE (mode) == 4
+ ? 0x ^ (0x000F << mask * 4)
+ : 0xFF ^ (0x03 << mask * 2));
emit_insn (gen__vinsert_1_mask
(operands[0], operands[1], operands[2], GEN_INT (selector),
operands[4], operands[5]));
@@ -12650,16 +12650,16 @@ (define_insn "mode) == 4 ? 0xFFF0 : 0xFC))
mask = 0;
- else if ( selector == 0xF0FF || selector == 0xCF)
+ else if (selector == (GET_MODE_UNIT_SIZE (mode) == 4 ? 0xFF0F : 0xF3))
mask = 1;
- else if ( selector == 0xFF0F || selector == 0xF3)
+ else if (selector == (GET_MODE_UNIT_SIZE (mode) == 4 ? 0xF0FF : 0xCF))
mask = 2;
- else if ( selector == 0xFFF0 || selector == 0xFC)
+ else if (selector == (GET_MODE_UNIT_SIZE (mode) == 4 ? 0x0FFF : 0x3F))
mask = 3;
else
- gcc_unreachable ();
+gcc_unreachable ();
operands[3] = GEN_INT (mask);
--- gcc/testsuite/gcc.target/i386/avx512f-pr85177.c.jj 2018-04-03
17:05:54.166498062 +0200
+++ gcc/testsuite/gcc.target/i386/avx512f-pr85177.c 2018-04-03
17:06:16.695503852 +0200
@@ -0,0 +1,30 @@
+/* PR target/85177 */
+/* { dg-do run { target { avx512f && int128 } } } */
+/* { dg-options "-O -fno-tree-ccp -fno-tree-sra -mavx512f -mno-avx512bw" } */
+
+#include "avx512f-check.h"
+
+typedef short U __attribute__ ((vector_size (64)));
+typedef __int128 V __attribute__ ((vector_size (64)));
+
+static inline __attribute__((always_inline)) U
+foo (int i, U u)
+{
+ u[i & 1] = 1;
+ return u;
+}
+
+__attribute__((noipa)) int
+bar ()
+{
+ V x = (V) foo (0, (U) { });
+ for (unsigned i = 0; i < 4; i++)
+if (x[i] != (i == 0)) __builtin_abort ();
+ return 0;
+}
+
+static void
+avx512f_test (void)
+{
+ bar ();
+}
Jakub
Re: [wwwdocs] document new options in gcc-8/changes.html
Oh my, On 03/04/2018 22:54, Martin Sebor wrote: +declaration or on distinct declarations of the same entitiy. For entity It's getting late here in Italy, I would recommend a systematic check of the typos. Paolo.
Re: [wwwdocs] document new options in gcc-8/changes.html
Hi, On 03/04/2018 22:54, Martin Sebor wrote: +mutually exclusive attribute specifications and hande such conflicts handle Thanks, Paolo.
Re: [wwwdocs] document new options in gcc-8/changes.html
Hi again ;) On 03/04/2018 22:54, Martin Sebor wrote: +more consistently. Mutually excclusive attribute specifications are exclusive Paolo.
Re: [PATCH] PR libstdc++/85183 fix std::variant move-assignment
PR libstdc++/85183
* include/std/variant (_Move_assign_base::operator=): Fix incorrect
value categories.
* testsuite/20_util/variant/85183.cc: New.
Tested powerp64le-linux, committed to trunk.
commit eda33cf5c2399e0f25fae17df46efa0b534c778a
Author: Jonathan Wakely
Date: Tue Apr 3 23:56:33 2018 +0100
PR libstdc++/85183 fix std::variant move-assignment
PR libstdc++/85183
* include/std/variant (_Move_assign_base::operator=): Fix incorrect
value categories.
* testsuite/20_util/variant/85183.cc: New.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index e4ae6573ed4..028d3064272 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -605,13 +605,14 @@ namespace __variant
if (__rhs._M_valid())
{
static constexpr void (*_S_vtable[])(void*, void*) =
- { &__erased_assign<_Types&, const _Types&>... };
- _S_vtable[__rhs._M_index](this->_M_storage(),
__rhs._M_storage());
+ { &__erased_assign<_Types&, _Types&&>... };
+ _S_vtable[__rhs._M_index]
+ (this->_M_storage(), __rhs._M_storage());
}
}
else
{
- _Move_assign_base __tmp(__rhs);
+ _Move_assign_base __tmp(std::move(__rhs));
this->~_Move_assign_base();
__try
{
diff --git a/libstdc++-v3/testsuite/20_util/variant/85183.cc
b/libstdc++-v3/testsuite/20_util/variant/85183.cc
new file mode 100644
index 000..b122c6357ad
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/variant/85183.cc
@@ -0,0 +1,35 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [PATCH] [PR c++/84979] improve auto handling in explicit tmpl args for concepts
On Apr 3, 2018, Jason Merrill wrote:
> On Tue, Apr 3, 2018 at 3:54 AM, Alexandre Oliva wrote:
>> On Apr 2, 2018, Jason Merrill wrote:
>>
>>> On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
On Mar 30, 2018, Jason Merrill wrote:
template
void foo(T t) {
typename T::template C u = t;
T::template C (t);
T::template C::f (t, u);
}
>>
>>> We should be able to distinguish those cases based on tag_type.
>> [...]
>> And then, while we're parsing "template C", we haven't yet reached
>> the '::' after the closing angle bracket that would tell us to regard
>> the id necessarily as a typename, so I don't see how we'd get a
>> scope_type in tag_type for the third case.
> Ah, good point. Then perhaps put the new function in pt.c and also
> call it from tsubst_copy_and_build?
I couldn't figure out how to trigger checks in tsubst_copy_and_build;
the testcases I threw at it all went through tsubst_qualified_id. I
think we can only get an identifier_p in a TEMPLATE_ID_EXPR when it's a
qualified id naming a member of another template; unqualified names that
could possibly take explicit template arguments would have to have
visible declarations, and then we'd get (an overload of) the
declarations in the TEMPLATE_ID_EXPR. I see evidence in pt.c that some
cases of Koenig lookup may involve identifier_p template substitution,
and I see evidence in the standard that the unqualified template-id
could have explicit template args, but... we won't regard as
a template arg list if it's not preceded by an id that names a template,
be it a template-dependent qualified id preceded by the 'template'
keyword, be a template found by name lookup. If we find an unrelated
template function (as in the snippet below), we'll stick to it. So it
seems to me that the patch below is all we need. Am I missing anything?
struct foo { template friend void bar(T& t); };
template void bar();
template void f(T& x) { bar (x); }
void g(foo& x) { f (x); }
Regstrapping on i686- and x86_64-linux-gnu. Ok to install if it passes?
[PR c++/84979] reject auto in explicit tmpl args for tmpl-fn
With concepts, we accept auto in explicit template arguments, but we
should only accept them for template classes. Passing them to
template functions or variables is not allowed. So, reject it, at
parse time if possible, at specialization time otherwise.
for gcc/cp/ChangeLog
PR c++/84979
* pt.c (check_auto_in_tmpl_args): New.
(tsubst_qualified_id): Use it to reject template args
referencing auto for non-type templates.
* parser.c (cp_parser_template_id): Likewise.
* cp-tree.h (check_auto_in_tmpl_args): Declare.
* typeck2.c (build_functional_cast): Report correct location
for invalid use of auto.
for gcc/testsuite/ChangeLog
PR c++/84979
* g++.dg/concepts/pr84979.C: New.
* g++.dg/concepts/pr84979-2.C: New.
* g++.dg/concepts/pr84979-3.C: New.
---
gcc/cp/cp-tree.h |1 +
gcc/cp/parser.c | 10 +-
gcc/cp/pt.c | 52 +
gcc/cp/typeck2.c |3 +-
gcc/testsuite/g++.dg/concepts/pr84979-2.C | 41 +++
gcc/testsuite/g++.dg/concepts/pr84979-3.C | 45 +
gcc/testsuite/g++.dg/concepts/pr84979.C |9 +
7 files changed, 159 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979-2.C
create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979-3.C
create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index db79338035da..4777aa34cdbe 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6496,6 +6496,7 @@ extern void maybe_show_extern_c_location (void);
/* in pt.c */
extern bool check_template_shadow (tree);
+extern bool check_auto_in_tmpl_args (tree, tree);
extern tree get_innermost_template_args(tree, int);
extern void maybe_begin_member_template_processing (tree);
extern void maybe_end_member_template_processing (void);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e946d0b72292..40a1e5549f02 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15831,8 +15831,16 @@ cp_parser_template_id (cp_parser *parser,
location_t combined_loc
= make_location (token->location, token->location, finish_loc);
+ /* Check for concepts autos where they don't belong. We could
+ identify types in some cases of idnetifier TEMPL, looking ahead
+ for a CPP_SCOPE, but that would buy us nothing: we accept auto in
+ types. We reject them in functions, but if what we have is an
+ identifier, even with none_type we can't conclude it's NOT a
+ type, we have to wait for template substitution. */
+ if (flag_concepts && check_auto_in_tmpl_args (templ, arguments))
+template_id
Re: [PATCH] [PR c++/84943] allow folding of array indexing indirect_ref
On Apr 3, 2018, Jason Merrill wrote:
> On Tue, Apr 3, 2018 at 11:47 AM, Jason Merrill wrote:
>> On Tue, Apr 3, 2018 at 3:44 AM, Alexandre Oliva wrote:
>>> + if ((complain & tf_conv))
>>> +return false;
>> I think we want to return true.
Yeah, it doesn't work at all returning false.
> (OK with that change.)
Thanks, here's what I'm installing.
[PR c++/84943] mark function as used when taking its address
fn[0]() ICEd because we would fold the INDIRECT_REF used for the
array indexing while building the address for the call, after not
finding the decl hiding there at first. But the decl would be exposed
by the folding, and then lower layers would complain we had the decl,
after all, but it wasn't one of the artificial or special functions
that could be called without being marked as used.
This patch arranges for a FUNCTION_DECL to be marked as used when
taking its address, just like we already did when taking the address
of a static function to call it as a member function (i.e. using the
obj.fn() notation). However, we shouldn't mark functions as used when
just performing overload resolution, lest we might instantiate
templates we shouldn't, as in g++.dg/overload/template1.C, so we
adjust mark_used to return early when testing conversions.
for gcc/cp/ChangeLog
PR c++/84943
* typeck.c (cp_build_addr_expr_1): Mark FUNCTION_DECL as
used.
* decl2.c (mark_used): Return without effects if tf_conv.
for gcc/testsuite/ChangeLog
PR c++/84943
* g++.dg/pr84943.C: New.
* g++.dg/pr84943-2.C: New.
---
gcc/cp/decl2.c |6
gcc/cp/typeck.c |3 ++
gcc/testsuite/g++.dg/pr84943-2.C | 64 ++
gcc/testsuite/g++.dg/pr84943.C |8 +
4 files changed, 81 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/pr84943-2.C
create mode 100644 gcc/testsuite/g++.dg/pr84943.C
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index fa753749e1a6..6ae6cef78dda 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -5201,6 +5201,12 @@ maybe_instantiate_decl (tree decl)
bool
mark_used (tree decl, tsubst_flags_t complain)
{
+ /* If we're just testing conversions or resolving overloads, we
+ don't want any permanent effects like forcing functions to be
+ output or instantiating templates. */
+ if ((complain & tf_conv))
+return true;
+
/* If DECL is a BASELINK for a single function, then treat it just
like the DECL for the function. Otherwise, if the BASELINK is
for an overloaded function, we don't know which function was
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index d454c6c5a295..bd67b82fcc65 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5971,6 +5971,9 @@ cp_build_addr_expr_1 (tree arg, bool strict_lvalue,
tsubst_flags_t complain)
so we can just form an ADDR_EXPR with the correct type. */
if (processing_template_decl || TREE_CODE (arg) != COMPONENT_REF)
{
+ if (TREE_CODE (arg) == FUNCTION_DECL
+ && !mark_used (arg, complain) && !(complain & tf_error))
+ return error_mark_node;
val = build_address (arg);
if (TREE_CODE (arg) == OFFSET_REF)
PTRMEM_OK_P (val) = PTRMEM_OK_P (arg);
diff --git a/gcc/testsuite/g++.dg/pr84943-2.C b/gcc/testsuite/g++.dg/pr84943-2.C
new file mode 100644
index ..d1ef012b9155
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr84943-2.C
@@ -0,0 +1,64 @@
+// { dg-do run }
+
+// Avoid -pedantic-error default
+// { dg-options "" }
+
+// Make sure the functions referenced by various forms of
+// address-taking are marked as used and compiled in.
+
+static void ac() {}
+void a() {
+ ac[0](); // { dg-warning "arithmetic" }
+}
+
+static void bc() {}
+void b() {
+ (&*&*&*&bc)();
+}
+
+template U cc() {}
+void (*c())() {
+ return cc;
+}
+
+template
+struct x {
+ void a(int);
+ template static U a(x*) {}
+ static void a(long) {}
+ static void a(void *) {}
+ static void a() {
+void (*p0)(void*) = x().a;
+p0(0);
+void (*p1)(long) = a;
+p1(0);
+void (*p2)() = a;
+p2();
+void (*p3)(x*) = a;
+p3(0);
+ }
+};
+
+struct z {
+ void a(int);
+ template static U a(z*) {}
+ static void a(long) {}
+ static void a(void *) {}
+ static void a() {
+void (*p0)(void*) = z().a;
+p0(0);
+void (*p1)(long) = a;
+p1(0);
+void (*p2)() = a;
+p2();
+void (*p3)(z*) = a;
+p3(0);
+ }
+};
+
+int main(int argc, char *argv[]) {
+ if (argc > 1) {
+x().a();
+z().a();
+ }
+}
diff --git a/gcc/testsuite/g++.dg/pr84943.C b/gcc/testsuite/g++.dg/pr84943.C
new file mode 100644
index ..36f75a164119
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr84943.C
@@ -0,0 +1,8 @@
+// { dg-do compile }
+
+// Avoid -pedantic-error default
+// { dg-options "" }
+
+void a() {
+ a[0](); // { dg-warning "arithmetic" }
+}
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to s
Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof
On Apr 3, 2018, Alexandre Oliva wrote:
> On Apr 2, 2018, Jason Merrill wrote:
>> On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva wrote:
>>> struct a {
>>> static int const z, i = __builtin_offsetof(struct b { int j; }, j);
>>> b c;
>>> };
>>> int const a::z = __builtin_offsetof(struct d { int k; }, k);
>>> d e;
>>> Since d is visible, I suppose the most conservative solution would be to
>>> name the global namespace as the context for type d, rather than
>>> defining it as a member of a. Right?
>> The global namespace would be a rather arbitrary choice; it seems to
>> me that using the current scope is a natural interpretation.
>> About d in the example, I'm not sure how you mean the global namespace
>> is the current scope; we should be pushed into a when parsing the
>> initializer for a::z.
> I was just describing observed behavior. The code above compiles.
> The explanation is in do_pushtag. It starts with a loop that, among
> other things, skips COMPLETE_TYPE_P class scopes. we then record the
> new type in the namespace named by the resulting scope. As the comment
> says, this is meant to allow for types to be introduced in initializers
> of static data members in spite of the class being already complete.
> The problem, as I see it, is that we don't adjust the context to match,
> so we introduce the type in one scope, but claim it to belong to
> another. Which sort of works for named types, but comes down in flames
> (err, reenters like Tiangong-1? ;-) if the type is anonymous.
>> But I would think we should reject the definition of d because a is
>> already complete, so it's too late to add members to it.
> The existing code in GCC sort of disagrees with your proposal, so, for
> the sake of avoiding breaking code that we used to compile (like the
> definition 'd e' above), I'll insist on something along the lines of the
> following patch:
That patch breaks various cases of lambdas in data member initializers
that reference members of the class containing the data member.
This suggested to me that we already have infrastructure for and
expectations of introducing types within a class after the class is
complete. Using similar infrastructure to make types introduced within
__builtin_offsetof, or even in type-casts under the extension I
attempted to adjust in the proposed patch (the extension that Nathan
mentioned he also ran into).
I still think we could attempt to retain the extension as it is, parsing
types introduced in data member initializers within the scope of the
class containing the data member, like we do, but, when the class is
already complete, recording it if not in TYPE_FIELDS, in some additional
field consulted for name mangling purposes and, in order to retain
compatibility, if the type is not a closure or anonymous, also recording
it in the enclosing namespace, so that it is found by lookup as in the
quoted snippet.
Is that a terrible idea?
--
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: [wwwdocs] gcc-8/changes.html
On Tue, 3 Apr 2018, Martin Liška wrote: > I would like to document features I prepared in time frame of GCC 8. A few observations in addition what Martin (S.) provided (Thanks!): Index: htdocs/gcc-8/changes.html === + GCOV tool can use TERM colors to provide more readable output. Similar to Martin's note. "GCOV" or the "The GCOV tool", though in the latter case probably "The gcov tool"? + AddressSanitizer gained a new pair of sanitization options, + -fsanitize=pointer-compare and -fsanitize=pointer-subtract, which -fsanitize..., twice. This looks fine with those changes and the others pointed out, thanks! Gerald
