[Bug tree-optimization/92715] [10 Regression] error: position plus size exceeds size of referenced object in ‘bit_field_ref’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715 Martin Liška changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/92704] [8/9/10 Regression] ICE: Segmentation fault (in process_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92704 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri Nov 29 08:05:03 2019 New Revision: 278828 URL: https://gcc.gnu.org/viewcvs?rev=278828&root=gcc&view=rev Log: 2019-11-29 Richard Biener PR tree-optimization/92704 * tree-if-conv.c (combine_blocks): Deal with virtual PHIs in loops performing only loads. * gcc.dg/torture/pr92704.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr92704.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/92704] [8/9 Regression] ICE: Segmentation fault (in process_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92704 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] ICE:|[8/9 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |process_bb) |process_bb) Known to fail|10.0| --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/92721] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92721 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-29 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r278624.
[Bug middle-end/92723] New: ICE in expand_shift_1, at expmed.c:2635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92723 Bug ID: 92723 Summary: ICE in expand_shift_1, at expmed.c:2635 Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Created attachment 47395 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47395&action=edit unreduced testcase > ./cc1plus -quiet bitRotateRight.ii -I include -std=c++17 -O3 during RTL pass: expand In file included from ../dbms/src/Functions/bitRotateRight.cpp:2: ../dbms/src/Functions/FunctionBinaryArithmetic.h: In static member function ?static void DB::BinaryOperationImplBase::vector_constant(DB::PaddedPODArray&, B, DB::PaddedPODArray&) [with A = unsigned char; B = long unsigned int; Op = DB::BitRotateRightImpl; ResultType_ = long unsigned int]?: ../dbms/src/Functions/FunctionBinaryArithmetic.h:73:13: internal compiler error: in expand_shift_1, at expmed.c:2635 0xca68f6 expand_shift_1 /space/rguenther/src/svn/gcc-9-branch/gcc/expmed.c:2635 0xca6a20 expand_variable_shift(tree_code, machine_mode, rtx_def*, tree_node*, rtx_def*, int) /space/rguenther/src/svn/gcc-9-branch/gcc/expmed.c:2677 0xcd4f9e expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /space/rguenther/src/svn/gcc-9-branch/gcc/expr.c:9368
[Bug c++/92654] [8/9/10 Regression] internal compiler error: in lookup_template_class_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654 Martin Liška changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #8 from Martin Liška --- Ok, GCC newly received a support for __has_builtin, so one needs to '#define a 0' always. The ICE started with r259043, before that the code was rejected.
[Bug target/92723] ICE in expand_shift_1, at expmed.c:2635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92723 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code, ||needs-reduction Target||aarch64-linux-gnu CC||rsandifo at gcc dot gnu.org Component|middle-end |target --- Comment #1 from Richard Biener --- #1 0x00ca68f7 in expand_shift_1 (code=RSHIFT_EXPR, mode=E_V2DImode, shifted=0x7fffe01b2060, amount=0x7fffe01b34c8, target=0x0, unsignedp=1, may_fail=false) at /space/rguenther/src/svn/gcc-9-branch/gcc/expmed.c:2635 2635 gcc_assert (temp != NULL_RTX || may_fail); (gdb) p debug_rtx (shifted) (reg:V2DI 135 [ vect__17.8770 ]) $1 = void (gdb) p debug_rtx (amount) (reg/v:DI 262 [ b ]) $2 = void so there's a variable vector shift expanded from vect_patt_26.8773_85 = vect__17.8770_77 >> b_8(D) either a vectorizer or a target issue.
[Bug c++/92654] [8/9/10 Regression] internal compiler error: in lookup_template_class_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654 --- Comment #9 from fiesh at zefix dot tv --- (In reply to Martin Liška from comment #8) > Ok, GCC newly received a support for __has_builtin, so one needs to > '#define a 0' always. > The ICE started with r259043, before that the code was rejected. Or I guess just change it to `#ifdef __clang__`.
[Bug c++/92717] precompiled headers non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717 --- Comment #8 from Markus Dreseler --- Interesting. Is this implementation documented somewhere? I can confirm that disabling ASLR results in reproducible gchs: # setarch $(uname -m) -R /usr/bin/c++ -x c++-header -include test.hxx -o test.hxx.gch -c test.hxx.cxx && md5sum test.hxx.gch 54486c6ffc08db87d4b58792dcb46091 test.hxx.gch # setarch $(uname -m) -R /usr/bin/c++ -x c++-header -include test.hxx -o test.hxx.gch -c test.hxx.cxx && md5sum test.hxx.gch 54486c6ffc08db87d4b58792dcb46091 test.hxx.gch For CI builds of trusted files, this might be an option, but generally setting the ADDR_NO_RANDOMIZE personality for gcc when gchs are build does not sound like a good approach.
[Bug target/92047] [10 regression] aarch64 regressions after r276645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92047 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Christophe Lyon --- Looks like it's fixed: the last failure I saw was in r278272, and OK since at least r278282. Thanks.
[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91975 Bug 91975 depends on bug 92047, which changed state. Bug 92047 Summary: [10 regression] aarch64 regressions after r276645 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92047 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
The Trophex Show - Attendees Info List
Hi Hope you are doing well. We are following up to if you would be interested in the Attendees/Visitors List of The Trophex Show 12 - 13 Jan 2020 NEC, Birmingham, UK Counts = 7,640 our company provides the following details regarding your attendees: Title, Client Name, Email and Website, address, Phone number, Zip code & Cities. If you are interested in the attendees list, let us know your thoughts so we will send you the discounted cost and additional information. Regards, Emily
[Bug middle-end/92714] [missed-optimization] aggregate initialization of an array fills the whole array with zeros first, including leading non-zero elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92714
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Or in theory store-merging could do this, although it can handle only the = {}
and not memset right now. That said, just unconditionally adjusting the
clearing store not to cover the boundaries which are overwritten is not a good
idea, it is much faster to start with an 8 or 16 byte aligned address over
skipping 3 or 7 bytes there.
[Bug lto/91574] [10 Regression] ICE in types_same_for_odr at gcc/ipa-devirt.c:355 since r272037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91574 --- Comment #2 from Martin Liška --- Author: marxin Date: Fri Nov 29 09:03:25 2019 New Revision: 278829 URL: https://gcc.gnu.org/viewcvs?rev=278829&root=gcc&view=rev Log: Check for TYPE_NAME in type_with_linkage_p. 2019-11-29 Martin Liska PR lto/91574 * ipa-devirt.c (types_same_for_odr): Check for existence of TYPE_NAMEs first. 2019-11-29 Martin Liska PR lto/91574 * g++.dg/lto/pr91574_0.C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr91574_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/ChangeLog
[Bug ada/92489] [9 regression] internal error on Invalid_Value Attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92489 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Fri Nov 29 09:07:53 2019 New Revision: 278830 URL: https://gcc.gnu.org/viewcvs?rev=278830&root=gcc&view=rev Log: PR ada/92489 Backport from mainline 2019-07-01 Ed Schonberg * exp_attr.adb (Expand_Attribute_Reference, case Invalid_Value): Resolve result of call to Get_Simple_Init_Val, which may be a conversion of a literal. Modified: branches/gcc-9-branch/gcc/ada/ChangeLog branches/gcc-9-branch/gcc/ada/exp_attr.adb
[Bug ada/92489] [9 regression] internal error on Invalid_Value Attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92489 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- Thanks for reporting the problem.
[Bug c++/60228] ICE using lambda in #pragma omp declare reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60228 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Nov 29 09:08:46 2019 New Revision: 278831 URL: https://gcc.gnu.org/viewcvs?rev=278831&root=gcc&view=rev Log: PR c++/60228 * parser.c (cp_parser_omp_declare_reduction_exprs): If processing_template_decl, wrap the combiner or initializer into EXPR_STMT. * decl.c (start_preparsed_function): Don't start a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions. (finish_function): Don't finish a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions, nor cp_fold_function them nor cp_genericize them. * mangle.c (decl_mangling_context): Look through DECL_OMP_DECLARE_REDUCTION_P functions. * semantics.c (expand_or_defer_fn_1): For DECL_OMP_DECLARE_REDUCTION_P functions, use tentative linkage, don't keep their bodies with -fkeep-inline-functions and return false at the end. * g++.dg/gomp/openmp-simd-2.C: Don't expect bodies for DECL_OMP_DECLARE_REDUCTION_P functions. * testsuite/libgomp.c++/udr-20.C: New test. * testsuite/libgomp.c++/udr-21.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/udr-20.C trunk/libgomp/testsuite/libgomp.c++/udr-21.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/gomp/openmp-simd-2.C trunk/libgomp/ChangeLog
[Bug c++/60228] ICE using lambda in #pragma omp declare reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60228 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Nov 29 09:10:44 2019 New Revision: 278832 URL: https://gcc.gnu.org/viewcvs?rev=278832&root=gcc&view=rev Log: PR c++/60228 * parser.c (cp_parser_omp_declare_reduction_exprs): If processing_template_decl, wrap the combiner or initializer into EXPR_STMT. * decl.c (start_preparsed_function): Don't start a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions. (finish_function): Don't finish a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions, nor cp_fold_function them nor cp_genericize them. * mangle.c (decl_mangling_context): Look through DECL_OMP_DECLARE_REDUCTION_P functions. * semantics.c (expand_or_defer_fn_1): For DECL_OMP_DECLARE_REDUCTION_P functions, use tentative linkage, don't keep their bodies with -fkeep-inline-functions and return false at the end. * g++.dg/gomp/openmp-simd-2.C: Don't expect bodies for DECL_OMP_DECLARE_REDUCTION_P functions. * testsuite/libgomp.c++/udr-20.C: New test. * testsuite/libgomp.c++/udr-21.C: New test. Modified: trunk/libgomp/testsuite/libgomp.c++/udr-20.C trunk/libgomp/testsuite/libgomp.c++/udr-21.C
[Bug tree-optimization/92715] [10 Regression] error: position plus size exceeds size of referenced object in ‘bit_field_ref’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715
--- Comment #5 from David Binderman ---
Reduced C++ code:
typedef double a __attribute__((__vector_size__(32)));
double b;
a c;
enum { d, e };
template struct h;
template class i;
template class aa;
template class j;
template class ab;
template struct ae;
template struct w;
template struct x { typedef typename ae::k k; };
template struct y { typedef j k; };
template ai aj(const typename w::k &);
template <> struct ae { typedef a k; };
template <> struct w { typedef double k; };
template <> a aj(const double &ak) {
c = a{ak, ak, ak, ak};
return c;
}
struct z {
z(double am) : an(am) {}
template void ao() { aj(an); }
double an;
};
struct ap {
template void aq(double *, ai);
};
template class ar {
public:
typedef typename h::al al;
typedef aa::as, h::at, e, h::au, h::av> aw;
typedef ab ax;
const ax ay(const al &);
template const ab ba(const az &);
ah &operator/=(const al &);
};
template class j : public ar {};
template struct ac { typename ah::al &bb(long); };
template
struct ac> : ac>> {
typedef aa bh;
ac(bh);
};
struct bi {
template void ao(z bk, bj) { bk.ao(); }
};
template struct ac> {
ac(ab l) : bn(l.bo()) {}
template ag bp(bj bq) { br.ao(bn, bq); }
bl bn;
bi br;
};
template struct bt {
typedef typename bs::bh bu;
typedef typename x::k ag;
};
template struct bw {
static void bx(bv by) {
enum { bz, ca, cb };
by.template aq(bz);
}
};
template class cf {
public:
typedef cc cg;
typedef cd ch;
typedef typename bt::ag ag;
cf(cg ci, ch cj, ce, cc) : ck(ci), cl(cj) {}
template void aq(long bq) {
bn.template aq(&ck.bb(bq), cl.template bp(bq));
}
cg ck;
ch cl;
ce bn;
};
template void cp(cn ci, co cj, ce cq) {
typedef ac cg;
typedef ac ch;
ch a(cj);
cg d(ci);
typedef cf bv;
bv e(d, a, cq, ci);
bw::bx(e);
}
template void m(bu ci, cr cj, cs cq) {
ab> n = cj;
cp(ci, n, cq);
}
template class i : public y::k {};
template
struct h> {
typedef o al;
enum { as, at, au, av };
};
template
class aa : public i> {};
template class ab {
public:
ab(long, long, z cq) : bn(cq) {}
z bo() { return bn; }
z bn;
};
template
template
const ab::aw> ar::ba(const az &cq) {
return ab(0, 0, cq);
}
template const typename ar::ax ar::ay(const al &p) {
return ba(z(p));
}
template ah &ar::operator/=(const al &am) {
ah s;
ab> t = ay(am);
m(s, t, ap());
}
void v() {
aa f;
__attribute__((__vector_size__(2 * sizeof(double double g;
b = g[0];
f /= b;
}
[Bug tree-optimization/92715] [10 Regression] error: position plus size exceeds size of referenced object in ‘bit_field_ref’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715 Richard Biener changed: What|Removed |Added Priority|P1 |P3 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/92715] [10 Regression] error: position plus size exceeds size of referenced object in ‘bit_field_ref’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Nov 29 09:18:48 2019 New Revision: 278833 URL: https://gcc.gnu.org/viewcvs?rev=278833&root=gcc&view=rev Log: 2019-11-29 Richard Biener PR tree-optimization/92715 * tree-ssa-forwprop.c (simplify_vector_constructor): Bail out for uniform vectors and source vectors with less elements than the destination. * gcc.dg/torture/pr92715.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr92715.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug c++/92722] gcc considers "padding" byte of empty lambda to be uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722 Avi Kivity changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #2 from Avi Kivity --- Maybe those 1-byte elements generated for empty structs should be considered padding. They certainly don't correspond to any member.
[Bug c++/92722] gcc considers "padding" byte of empty lambda to be uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- During expansion we avoid the moves when an empty struct is being copied. But this testcase explicitly copies the underlying bytes rather than copying the empty struct, I don't see what the compiler could do in that case.
[Bug rtl-optimization/92510] ICE in native_encode_rtx, at simplify-rtx.c:6272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot gnu.org Summary|[10 Regression] ICE in |ICE in native_encode_rtx, |native_encode_rtx, at |at simplify-rtx.c:6272 |simplify-rtx.c:6272 | --- Comment #9 from Jakub Jelinek --- The regression is fixed. Keeping open if Segher wants to do some further fixes.
[Bug c++/92705] [10 Regression] ICE: Segmentation fault (in build_new_op_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92705
Jakub Jelinek changed:
What|Removed |Added
Keywords|error-recovery |
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-29
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r277864. This isn't error-recovery, there is no error printed
before it ICEs.
Slightly shortened:
struct A {};
struct B {};
struct C { operator B*(); };
struct D { operator B*(); };
struct E : C, D { operator A*(); };
void foo(E e, int B::* pmf) { int i = e->*pmf; }
[Bug ipa/92685] In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92685 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Martin Liška --- Hello. Yes, for usage of create_version_clone_with_body one needs to load GIMPLE body of both caller and callee function. Anyway, can you please rather write to https://gcc.gnu.org/ml/gcc/ mailing list? Note that we use create_version_clone_with_body mainly in IPA passes that are not part of INSERT_PASSES_AFTER (all_regular_ipa_passes). Can you please describe what kind of IPA pass you're intending to write? Please write to the mailing list.
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #2 from Jonathan Wakely --- (In reply to Dennis Clarke from comment #0) > This may require a bit of a dive into the specifications however > an inline include of /dev/stdin seems wrong for some definition > of wrong. There's no such thing as an "inline include", the preprocessor just substitutes the content of the named file wherever a #include directive appears. If that file happens to be /dev/stdin then it happens to be /dev/stdin.
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #3 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > GCC does not check the files. > > >echo '\042hello botfelk\\n\042' > This one fails for me too: > In file included from t8.c:5:0: > /dev/stdin: In function ‘main’: > /dev/stdin:1:1: error: stray ‘\’ in program > /dev/stdin:1:2: error: invalid suffix "hello" on integer constant > /dev/stdin:1:11: error: expected ‘)’ before ‘botfelk’ > /dev/stdin:1:18: error: stray ‘\’ in program > /dev/stdin:1:19: error: stray ‘\’ in program > /dev/stdin:1:21: error: stray ‘\’ in program You need to use -e for GNU echo to interpret the \042 characters.
[Bug c++/92705] [10 Regression] ICE: Segmentation fault (in build_new_op_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92705
--- Comment #2 from Jakub Jelinek ---
The ICE is because conv is ck_ambig with user_conv_p set.
Looking at other conv->user_conv_p tests, e.g. reference_binding does:
if (conv->user_conv_p)
{
...
for (conversion *t = conv; t; t = next_conversion (t))
if (t->kind == ck_user
&& DECL_CONV_FN_P (t->cand->fn))
{
and doesn't expect that user_conv_p implies that ck_user will appear.
The following patch restores the previous diagnostics on the testcase, but I'm
afraid I have no idea what is right. If ck_ambig with user_conv_p set is
right, then it itself isn't ck_user and next_conversion on it is NULL.
--- gcc/cp/call.c.jj2019-11-28 18:58:55.671297387 +0100
+++ gcc/cp/call.c 2019-11-29 12:33:04.033386816 +0100
@@ -6370,8 +6370,12 @@ build_new_op_1 (const op_location_t &loc
conv = cand->convs[0];
if (conv->user_conv_p)
{
- while (conv->kind != ck_user)
- conv = next_conversion (conv);
+ for (conversion *t = conv; t; t = next_conversion (t))
+ if (t->kind == ck_user)
+ {
+ conv = t;
+ break;
+ }
arg1 = convert_like (conv, arg1, complain);
}
@@ -6380,8 +6384,12 @@ build_new_op_1 (const op_location_t &loc
conv = cand->convs[1];
if (conv->user_conv_p)
{
- while (conv->kind != ck_user)
- conv = next_conversion (conv);
+ for (conversion *t = conv; t; t = next_conversion (t))
+ if (t->kind == ck_user)
+ {
+ conv = t;
+ break;
+ }
arg2 = convert_like (conv, arg2, complain);
}
}
@@ -6391,8 +6399,12 @@ build_new_op_1 (const op_location_t &loc
conv = cand->convs[2];
if (conv->user_conv_p)
{
- while (conv->kind != ck_user)
- conv = next_conversion (conv);
+ for (conversion *t = conv; t; t = next_conversion (t))
+ if (t->kind == ck_user)
+ {
+ conv = t;
+ break;
+ }
arg3 = convert_like (conv, arg3, complain);
}
}
[Bug lto/91574] [10 Regression] ICE in types_same_for_odr at gcc/ipa-devirt.c:355 since r272037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91574 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug bootstrap/92719] MacOS 10.15 Catalina build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92719 Iain Sandoe changed: What|Removed |Added Target||x86_64-apple-darwin19.0.0 CC||iains at gcc dot gnu.org Target Milestone|--- |10.0 Build||x86_64-apple-darwin19.0.0 --- Comment #1 from Iain Sandoe --- please could you identify the version of Xcode and the SDK in use? (anything less than 11.3beta is known to have problems). you have some configuration options that don't apply to 10.15: --enable-multilib (this would just break later) and some that are unnecessary: --enable-bootstrap (default) lto in the languages (default) It is likely the --enable-host-shared option that is causing some difficulty here, it is rarely used/tested. (I will try to repeat that locally) It seems that your GMP installation is in /usr/local (or somehow found automatically)? This could also be a problem when using a sysroot (/usr/local is not added at present) see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834#c13 could you check --- ../configure --prefix=$PWD/usr --with-sysroot=$OSX_SDK_PATH --enable-languages=c,c++,fortran --with-gmp=/path/to/gmp/prefix
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > (In reply to Dennis Clarke from comment #0) > > This may require a bit of a dive into the specifications however > > an inline include of /dev/stdin seems wrong for some definition > > of wrong. > > There's no such thing as an "inline include", the preprocessor just > substitutes the content of the named file wherever a #include directive > appears. > > If that file happens to be /dev/stdin then it happens to be /dev/stdin. The actual mapping from a #include directive to a physical file is implementation defined, so it seems OK for one compiler to refuse to do include certain paths, and OK for another to do so.
[Bug c++/92705] [10 Regression] ICE: Segmentation fault (in build_new_op_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92705 --- Comment #3 from Jakub Jelinek --- Though, previously the convert_like calls were done no matter what the conversion is, so with the above patch maybe after the if (conv->user_conv_p) ... stmts, with whatever the conv is. Not sure if it makes a difference for anything.
[Bug ada/92724] New: Can't link 9.2.0 ada with latest GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92724 Bug ID: 92724 Summary: Can't link 9.2.0 ada with latest GCC Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Using latest GCC master, I can't build gcc-9 branch with it. It's very likely caused by switch to -fno-common: $ g++ -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o gnatbind ada/b_gnatb.o ada/libgnat/a-elchha.o ada/libgnat/a-except.o ada/libgnat/ada.o ada/adaint.o ada/ali-util.o ada/ali.o ada/alloc.o ada/argv.o ada/aspects.o ada/atree.o ada/bcheck.o ada/binde.o ada/binderr.o ada/bindgen.o ada/bindusg.o ada/butil.o ada/casing.o ada/cio.o ada/csets.o ada/cstreams.o ada/debug.o ada/einfo.o ada/elists.o ada/env.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/exit.o ada/final.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/libgnat/g-byorma.o ada/libgnat/g-hesora.o ada/libgnat/g-htable.o ada/libgnat/gnat.o ada/gnatbind.o ada/gnatvsn.o ada/hostparm.o ada/init.o ada/initialize.o ada/libgnat/interfac.o ada/krunch.o ada/lib.o ada/link.o ada/namet.o ada/nlists.o ada/opt.o ada/osint-b.o ada/osint.o ada/output.o ada/raise.o ada/raise-gcc.o ada/restrict.o ada/rident.o ada/rtfinal.o ada/rtinit.o ada/libgnat/s-addope.o ada/libgnat/s-assert.o ada/libgnat/s-carun8.o ada/libgnat/s-casuti.o ada/libgnat/s-conca2.o ada/libgnat/s-conca3.o ada/libgnat/s-conca4.o ada/libgnat/s-conca5.o ada/libgnat/s-conca6.o ada/libgnat/s-conca7.o ada/libgnat/s-conca8.o ada/libgnat/s-conca9.o ada/libgnat/s-crc32.o ada/libgnat/s-crtl.o ada/libgnat/s-excdeb.o ada/libgnat/s-except.o ada/libgnat/s-excmac.o ada/libgnat/s-exctab.o ada/libgnat/s-htable.o ada/libgnat/s-imenne.o ada/libgnat/s-imgenu.o ada/libgnat/s-imgint.o ada/libgnat/s-mastop.o ada/libgnat/s-memory.o ada/libgnat/s-os_lib.o ada/libgnat/s-parame.o ada/libgnat/s-resfil.o ada/libgnat/s-restri.o ada/libgnat/s-secsta.o ada/libgnat/s-soflin.o ada/libgnat/s-soliin.o ada/libgnat/s-sopco3.o ada/libgnat/s-sopco4.o ada/libgnat/s-sopco5.o ada/libgnat/s-stache.o ada/libgnat/s-stalib.o ada/libgnat/s-stoele.o ada/libgnat/s-strhas.o ada/libgnat/s-string.o ada/libgnat/s-strops.o ada/libgnat/s-traent.o ada/libgnat/s-traceb.o ada/libgnat/s-unstyp.o ada/libgnat/s-utf_32.o ada/libgnat/s-wchcnv.o ada/libgnat/s-wchcon.o ada/libgnat/s-wchjis.o ada/libgnat/s-wchstw.o ada/scans.o ada/scil_ll.o ada/scng.o ada/sdefault.o ada/seh_init.o ada/sem_aux.o ada/sinfo.o ada/sinput-c.o ada/sinput.o ada/snames.o ada/stand.o ada/stringt.o ada/style.o ada/styleg.o ada/stylesw.o ada/switch-b.o ada/switch.o ada/libgnat/system.o ada/table.o ada/targext.o ada/targparm.o ada/tree_io.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o ada/widechar.o ggc-none.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -g mv -f Tlto-wrapper lto-wrapper /usr/bin/ld: ada/ali.o: in function `ali__scan_ali': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2767: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2767: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1587: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1587: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2805: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2805: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1416: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1416: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1552: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1552: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2767: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/gnatbind.o: in function `_ada_gnatbind': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/gnatbind.adb:899: undefined reference to `__gnat_begi
[Bug fortran/84963] [8 Regression] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84963 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Fri Nov 29 12:18:50 2019 New Revision: 278836 URL: https://gcc.gnu.org/viewcvs?rev=278836&root=gcc&view=rev Log: Fix testcase - was missing -fopenacc PR ipa/84963 * gfortran.dg/goacc/pr84963.f90: Use dg-additional-options not dg-options as otherwise -fopenacc is not used. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/goacc/pr84963.f90
[Bug tree-optimization/91825] [10 regression] Bogus -Wmaybe-uninitialized with r275744 breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91825
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek ---
Slightly tweaked, so that no other warnings are reported on it with -O2 -Wall,
except this -Wmaybe-uninitialized starting with the r277864 change and nothing
before:
typedef struct rtx_def *rtx;
enum machine_mode {
E_VOIDmode, E_BLKmode, E_CCmode, E_CCFPmode, E_CCFPEmode, E_CC_SWPmode,
E_CC_NZCmode, E_CC_NZmode,
E_CC_Zmode, E_CC_Cmode, E_CC_ADCmode, E_CC_Vmode, E_BImode, E_QImode,
E_HImode, E_SImode, E_DImode,
E_TImode, E_OImode, E_CImode, E_XImode, E_QQmode, E_HQmode, E_SQmode,
E_DQmode, E_TQmode, E_UQQmode,
E_UHQmode, E_USQmode, E_UDQmode, E_UTQmode, E_HAmode, E_SAmode, E_DAmode,
E_TAmode, E_UHAmode, E_USAmode,
E_UDAmode, E_UTAmode, E_HFmode, E_SFmode, E_DFmode, E_TFmode, E_SDmode,
E_DDmode, E_TDmode, E_CQImode,
E_CHImode, E_CSImode, E_CDImode, E_CTImode, E_COImode, E_CCImode, E_CXImode,
E_HCmode, E_SCmode, E_DCmode,
E_TCmode, E_V8QImode, E_V4HImode, E_V2SImode, E_V16QImode, E_V8HImode,
E_V4SImode, E_V2DImode, E_VNx2TImode,
E_VNx3TImode, E_VNx4TImode, E_VNx2OImode, E_V2HFmode, E_V4HFmode, E_V2SFmode,
E_V2DFmode, NUM_MACHINE_MODES
};
template struct A { int coeffs[N]; };
template class C : public A {
public:
template C(const C0 &);
};
machine_mode mode_size_inline_mode, emit_store_flag_1_target_mode;
A<2> mode_size[1];
struct B {
enum from_int {};
};
extern const char mode_class[NUM_MACHINE_MODES];
template T as_a(machine_mode);
class scalar_int_mode {
public:
scalar_int_mode() {}
scalar_int_mode(B::from_int p1) : m_mode(machine_mode(p1)) {}
operator machine_mode() { return m_mode; }
machine_mode m_mode;
} mode_to_bytes_mode;
scalar_int_mode word_mode;
template bool is_int_mode(machine_mode p1, T p2) {
if (mode_class[p1]) {
*p2 = B::from_int(p1);
return true;
}
return false;
}
enum insn_code {};
enum rtx_code { GE, LE, LT };
struct rtx_def {
rtx_code code;
machine_mode mode;
};
rtx const_int_rtx_63, const_int_rtx_64, emit_store_flag_1_subtarget,
emit_store_flag_1_tem, emit_store_flag_1_op00, emit_store_flag_1_op01,
emit_store_flag_1_op0h, emit_store_flag_1_target, emit_store_flag_1_op0,
emit_store_flag_1_op1;
enum tree_code { RSHIFT_EXPR };
enum optab_tag { and_optab, ior_optab, one_cmpl_optab };
enum optab_methods { OPTAB_DIRECT };
insn_code emit_store_flag_1_icode;
rtx_code emit_store_flag_1_code;
int emit_store_flag_1_unsignedp, emit_store_flag_1_normalizep;
short emit_store_flag_1___trans_tmp_24, emit_store_flag_1___trans_tmp_23;
bool iterate_p();
inline __attribute__((__always_inline__)) C<2> mode_size_inline() {
A<2> mode_size;
switch (mode_size_inline_mode) {
case E_VOIDmode: return 0;
case E_BLKmode: return 0;
case E_CCmode: return 4;
case E_CCFPmode: return 4;
case E_CCFPEmode: return 4;
case E_CC_SWPmode: return 4;
case E_CC_NZCmode: return 4;
case E_CC_NZmode: return 4;
case E_CC_Zmode: return 4;
case E_CC_Cmode: return 4;
case E_CC_ADCmode: return 4;
case E_CC_Vmode: return 4;
case E_BImode: return 1;
case E_QImode: return 1;
case E_HImode: return 2;
case E_SImode: return 4;
case E_DImode: return 8;
case E_TImode: return 6;
case E_OImode: return 2;
case E_CImode: return 8;
case E_XImode: return 4;
case E_QQmode: return 1;
case E_HQmode: return 2;
case E_SQmode: return 4;
case E_DQmode: return 8;
case E_TQmode: return 6;
case E_UQQmode: return 1;
case E_UHQmode: return 2;
case E_USQmode: return 4;
case E_UDQmode: return 8;
case E_UTQmode: return 6;
case E_HAmode: return 2;
case E_SAmode: return 4;
case E_DAmode: return 8;
case E_TAmode: return 6;
case E_UHAmode: return 2;
case E_USAmode: return 4;
case E_UDAmode: return 8;
case E_UTAmode: return 6;
case E_HFmode: return 2;
case E_SFmode: return 4;
case E_DFmode: return 8;
case E_TFmode: return 6;
case E_SDmode: return 4;
case E_DDmode: return 8;
case E_TDmode: return 6;
case E_CQImode: return 2;
case E_CHImode: return 4;
case E_CSImode: return 8;
case E_CDImode: return 6;
case E_CTImode: return 2;
case E_COImode: return 4;
case E_CCImode: return 6;
case E_CXImode: return 8;
case E_HCmode: return 4;
case E_SCmode: return 8;
case E_DCmode: return 6;
case E_TCmode: return 2;
case E_V8QImode: return 8;
case E_V4HImode: return 8;
case E_V2SImode: return 8;
case E_V16QImode: return 6;
case E_V8HImode: return 6;
case E_V4SImode: return 6;
case E_V2DImode: return 6;
case E_VNx2TImode: return 2;
case E_VNx3TImode: return 8;
case E_VNx4TImode: return 4;
case E_VNx2OImode: return 4;
case E_V2HFmode: return 4;
case E_V4HFmode: return 8;
case E_V2SFmode: return 8;
case E_V2DFmode: return 6;
default: return mode_size;
}
}
inlin
[Bug fortran/84963] [8 Regression] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84963 --- Comment #7 from Tobias Burnus --- Author: burnus Date: Fri Nov 29 12:27:34 2019 New Revision: 278838 URL: https://gcc.gnu.org/viewcvs?rev=278838&root=gcc&view=rev Log: Fix testcase - was missing -fopenacc Backport from mainline 2019-11-29 Tobias Burnus PR ipa/84963 * gfortran.dg/goacc/pr84963.f90: Use dg-additional-options not dg-options as otherwise -fopenacc is not used. Modified: branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/goacc/pr84963.f90
[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 --- Comment #6 from Jonathan Wakely --- The problem is not missing debuginfo, it's a GDB bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25234 I have a workaround for libstdc++ though.
[Bug middle-end/92725] New: ICE: Segmentation fault during GIMPLE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92725
Bug ID: 92725
Summary: ICE: Segmentation fault during GIMPLE pass
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat 0.c
int global ;
void foo() ;
__attribute__((returns_twice)) int bar() ;
void baz(int, int);
void main ( )
{
int x;
for ( ; ; )
foo();
baz(bar(), global);
}
$ gcc-snapshot8 --version
gcc (GCC) 8.3.1 20191122
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-snapshot8 0.c
during GIMPLE pass: *build_cgraph_edges
0.c: In function ‘main’:
0.c:10:6: internal compiler error: Segmentation fault
void main ( )
^~~~
0xa654af crash_signal
../../gcc-8-20191122/gcc/toplev.c:325
0x8275a0 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc-8-20191122/gcc/gimple-expr.c:70
0x70606d types_compatible_p
../../gcc-8-20191122/gcc/gimple-expr.h:66
0x70606d gimple_check_call_args
../../gcc-8-20191122/gcc/cgraph.c:3798
0x70606d gimple_check_call_matching_types(gimple*, tree_node*, bool)
../../gcc-8-20191122/gcc/cgraph.c:3848
0x708346 symbol_table::create_edge(cgraph_node*, cgraph_node*, gcall*,
profile_count, bool)
../../gcc-8-20191122/gcc/cgraph.c:879
0x708544 cgraph_node::create_edge(cgraph_node*, gcall*, profile_count)
../../gcc-8-20191122/gcc/cgraph.c:914
0x70df6e execute
../../gcc-8-20191122/gcc/cgraphbuild.c:322
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/92713] ICE in libsupc++ building an offload compiler targeting amdgcn-unknown-amdhsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92713 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- Notes from the #gcc IRC: * Workaround: --enable-languages=c,lto,fortran – i.e. do not build the C++ compiler for AMD GCN * Note: the offload compiler doesn't need any frontends (but lto) * Only (offloaded) code which does not need libstc++ will work. * For C++ support on GCN itself: a few features are currently missing such as exceptions
[Bug ada/92724] Can't link 9.2.0 ada with latest GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92724 Arnaud Charlet changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||charlet at gcc dot gnu.org Resolution|--- |INVALID Target Milestone|--- |10.0 --- Comment #1 from Arnaud Charlet --- You cannot build GNAT with a more recent version of GNAT in general, as explained in https://gcc.gnu.org/install/prerequisites.html. This PR is an occurrence of such incompatibility.
[Bug tree-optimization/91825] [10 regression] Bogus -Wmaybe-uninitialized with r275744 breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91825 --- Comment #10 from Jakub Jelinek --- Though, I'm afraid the reduced testcases are bad, because it doesn't reproduce without the incorrect __trans_tmp_10 that uses int_mode even outside of code where it is initialized.
[Bug middle-end/92725] ICE: Segmentation fault during GIMPLE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92725 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-29 Known to work||10.0, 9.1.0 Ever confirmed|0 |1 Known to fail||7.1.0, 8.1.0, 8.3.1 --- Comment #1 from Richard Biener --- Confirmed. I think we have a duplicate for this, it works on the GCC 9 branch.
[Bug tree-optimization/92710] [9/10 Regression] Vectoriser generates invalid simd call for bool arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92710 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Nov 29 13:04:56 2019 New Revision: 278839 URL: https://gcc.gnu.org/viewcvs?rev=278839&root=gcc&view=rev Log: Don't pass booleans as mask types to simd clones (PR 92710) In this PR we assigned a vector mask type to the result of a comparison and then tried to pass that mask type to a simd clone, which expected a normal (non-mask) type instead. This patch simply punts on call arguments that have a mask type. A better fix would be to pattern-match the comparison to a COND_EXPR, like we would if the comparison was stored to memory, but doing that isn't gcc 9 or 10 material. Note that this doesn't affect x86_64-linux-gnu because the ABI promotes bool arguments to ints. 2019-11-29 Richard Sandiford gcc/ PR tree-optimization/92710 * tree-vect-stmts.c (vectorizable_simd_clone_call): Reject vector mask arguments. gcc/testsuite/ PR tree-optimization/92710 * gcc.dg/vect/pr92710.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr92710.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug fortran/84963] [8 Regression] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84963 --- Comment #8 from Tobias Burnus --- Author: burnus Date: Fri Nov 29 13:16:31 2019 New Revision: 278840 URL: https://gcc.gnu.org/viewcvs?rev=278840&root=gcc&view=rev Log: Fix testcase - was missing -fopenacc Backport from mainline 2019-11-29 Tobias Burnus PR ipa/84963 * gfortran.dg/goacc/pr84963.f90: Use dg-additional-options not dg-options as otherwise -fopenacc is not used. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/goacc/pr84963.f90
[Bug libgomp/92726] New: OpenACC: 'NULL'-in -> no-op, and/or 'NULL'-out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92726 Bug ID: 92726 Summary: OpenACC: 'NULL'-in -> no-op, and/or 'NULL'-out Product: gcc Version: unknown Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- OpenACC is being clarified that when you pass 'NULL' into data clauses, or runtime API functions, that means no-op, and/or a 'NULL' return value.
[Bug c++/92727] New: Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
Bug ID: 92727
Summary: Idea for better error messages
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Consider this code:
#include
#include
class Y {int i;};
class X {
std::unique_ptr sp;
int i;
};
int main() {
std::vector v;
X x;
v.push_back(x);// Line A
// v.push_back(std::move(x)); // Line B
}
It is a simple mistake - class X has a unique_ptr and can't be copied, but the
push_back tries to copy it.
The errors generated, however, contain a lot of unhelpful information about
allocators for the vector. They hide the useful part of the messages, which
is:
note: 'X::X(const X&)' is implicitly deleted because the default definition
would be ill-formed
It is an extra note, rather than the error message, but is key for the user to
identify the problem.
Would it be possible to hide the messages concerning the allocator here? In
general, would it be possible to hide the messages that deal with template
parameters that are unchanged from the default? That would let the user see
messages that are relevant to the code /they/ have written, rather than
implementation details in the libraries and headers.
Even better, in this case, would be a hint that the user needs a std::move, as
shown in line B.
(Yes, I know I may be asking for the impossible here, or at least for the very
difficult. But it is the kind of thing that makes C++ development harder than
it should be.)
[Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92476 --- Comment #5 from Martin Jambor --- Author: jamborm Date: Fri Nov 29 13:29:35 2019 New Revision: 278841 URL: https://gcc.gnu.org/viewcvs?rev=278841&root=gcc&view=rev Log: ipa-cp: Avoid ICEs when looking at expanded thunks and unoptimized functions 2019-11-29 Martin Jambor PR ipa/92476 * ipa-cp.c (set_single_call_flag): Set node_calling_single_call in the summary only if the summary exists. (find_more_scalar_values_for_callers_subset): Check node_dead in the summary only if the summary exists. (ipcp_store_bits_results): Ignore nodes without lattices. (ipcp_store_vr_results): Likewise. * cgraphclones.c: Include ipa-fnsummary.h and ipa-prop.h and the header files required by them. (cgraph_node::expand_all_artificial_thunks): Analyze expanded thunks. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphclones.c trunk/gcc/ipa-cp.c
[Bug fortran/91003] [10 Regression] ICE when compiling LAPACK (CGEGV) with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91003 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #6 from Richard Biener --- So this is another "boolean" case. In vect_get_constant_vectors we run into /* ??? SLP analysis should compute the vector type for the constant / invariant and store it in the SLP node. */ tree op = op_node->ops[0]; /* Check if vector type is a boolean vector. */ tree stmt_vectype = STMT_VINFO_VECTYPE (stmt_vinfo); if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op)) && vect_mask_constant_operand_p (stmt_vinfo)) vector_type = truth_type_for (stmt_vectype); else vector_type = get_vectype_for_scalar_type (vinfo, TREE_TYPE (op), op_node); for h_18 = _129 ? 1 : 0; with unsigned boolean (kind==4) typed result/then/else values (SImode). IIRC I couldn't simply remove this and rely on get_vectype_for_scalar_type to do the right thing (TM) in general. Plus we don't have a stmt-info for the constant operands (but we do now have an SLP node for them). I hope Richards patches improve things here but I don't remember them touching this particular place.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||law at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
I don't think the testcase is actually very good, because it uses volatile that
asks the compiler not to optimize that part.
But it can be reproduced with:
static int func_base(int t, const int v) {
int x = 0;
for (int i = 0; i < t; ++i) x += v;
return x;
}
int func_default(int t, const int v) {
return func_base(t, v);
}
int func_assumed(int t, const int v) {
if (t < 0) __builtin_unreachable();
return func_base(t, v);
}
too. The first change in func_assumed was r233207 and the -1;mul;add instead
of mul appeared with r263652.
[Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92476 --- Comment #6 from Martin Jambor --- Author: jamborm Date: Fri Nov 29 13:36:47 2019 New Revision: 278842 URL: https://gcc.gnu.org/viewcvs?rev=278842&root=gcc&view=rev Log: Add an x86_64 test for PR 92476 2019-11-29 Martin Jambor PR ipa/92476 * g++.dg/lto/pr92476_[01].C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr92476_0.C trunk/gcc/testsuite/g++.dg/lto/pr92476_1.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711 --- Comment #5 from Martin Liška --- One particular change that has happened in the GCC 10 devel cycle is that we started using TOP N counters for indirect calls and value profiling. Right now, we track 4 key:value pairs for each counter plus one counter for total number of executions.
[Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92476 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jamborm at gcc dot gnu.org Resolution|--- |FIXED Assignee|mjambor at suse dot cz |jamborm at gcc dot gnu.org --- Comment #7 from Martin Jambor --- Fixed.
[Bug fortran/91003] [10 Regression] ICE when compiling LAPACK (CGEGV) with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91003 --- Comment #7 from Richard Biener --- Created attachment 47396 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47396&action=edit untested patch The following fixes the testcase but possibly makes the issue just harder to trigger.
[Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711 --- Comment #6 from Jan Hubicka --- With GCC9 like inliner parameters I get 308MB binary, so it is still somehwat bigger. Honza
[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391 --- Comment #13 from Joel Hutton --- This appears to no longer be failing in the latest 'gcc-testresults' can this be closed?
[Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711 --- Comment #7 from Martin Liška --- (In reply to Jan Hubicka from comment #6) > With GCC9 like inliner parameters I get 308MB binary, so it is still > somehwat bigger. > > Honza I would try to set: #define GCOV_TOPN_VALUES 1 then you should see the different of TOP N counters.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #3 from Jakub Jelinek ---
Before the first revision mentioned above *.optimized dump contained just t *
v, the second one doesn't change anything in *.optimized and is a RTL costing
matter.
_4 = (unsigned int) t_1(D);
_10 = _4 + 4294967295;
_8 = (int) _10;
_13 = v_3(D) * _8;
x_5 = v_3(D) + _13;
and can be seen even on simpler:
int
foo (int t, int v)
{
t = t - 1U;
v *= t;
return v + t;
}
which we don't optimize at GIMPLE level. We don't optimize even:
int
bar (int t, int v)
{
t = t - 1;
v *= t;
return v + t;
}
Rather than hoping it is optimized during combine (the change there was that
while combining b=a-1 into c=b*d we attempted c=a*d-d we now attempt c=(a-1)*d
and similarly for the 3 insn combination with e=c+d, where we attempted and
succeeded to combine that into e=a*d while now we attempt and fail e=(a-1)*d+d:
-Successfully matched this instruction:
+Failed to match this instruction:
(parallel [
(set (reg/v:SI 91 [ ])
-(mult:SI (reg/v:SI 92 [ t ])
+(plus:SI (mult:SI (plus:SI (reg/v:SI 92 [ t ])
+(const_int -1 [0x]))
+(reg/v:SI 93 [ v ]))
(reg/v:SI 93 [ v ])))
(clobber (reg:CC 17 flags))
])
), I think it would be useful to optimize this in match.pd, plus maybe teach
simplify-rtx.c to handle this.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #4 from rguenther at suse dot de ---
On Fri, 29 Nov 2019, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
>
> --- Comment #3 from Jakub Jelinek ---
> Before the first revision mentioned above *.optimized dump contained just t *
> v, the second one doesn't change anything in *.optimized and is a RTL costing
> matter.
> _4 = (unsigned int) t_1(D);
> _10 = _4 + 4294967295;
> _8 = (int) _10;
> _13 = v_3(D) * _8;
> x_5 = v_3(D) + _13;
> and can be seen even on simpler:
> int
> foo (int t, int v)
> {
> t = t - 1U;
> v *= t;
> return v + t;
> }
> which we don't optimize at GIMPLE level. We don't optimize even:
> int
> bar (int t, int v)
> {
> t = t - 1;
> v *= t;
> return v + t;
> }
> Rather than hoping it is optimized during combine (the change there was that
> while combining b=a-1 into c=b*d we attempted c=a*d-d we now attempt c=(a-1)*d
> and similarly for the 3 insn combination with e=c+d, where we attempted and
> succeeded to combine that into e=a*d while now we attempt and fail
> e=(a-1)*d+d:
> -Successfully matched this instruction:
> +Failed to match this instruction:
> (parallel [
> (set (reg/v:SI 91 [ ])
> -(mult:SI (reg/v:SI 92 [ t ])
> +(plus:SI (mult:SI (plus:SI (reg/v:SI 92 [ t ])
> +(const_int -1 [0x]))
> +(reg/v:SI 93 [ v ]))
> (reg/v:SI 93 [ v ])))
> (clobber (reg:CC 17 flags))
> ])
> ), I think it would be useful to optimize this in match.pd, plus maybe teach
> simplify-rtx.c to handle this.
I think fold_plusminus_mult_expr does this on GENERIC, but it was dumbed
down at some point because of undefined overflow issues. Because
for (t - 1) * v + v, (t - 1) might be zero and with large v t * v
might overflow (or so, need to track down history of that function).
Richard.
[Bug fortran/92728] New: [OpenMP][OpenACC] Common-block name clause matching issues: common block needs to be defined before + blank common not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92728
Bug ID: 92728
Summary: [OpenMP][OpenACC] Common-block name clause matching
issues: common block needs to be defined before +
blank common not supported
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openacc, openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Based on the discussion at
https://gcc.gnu.org/ml/gcc-patches/2019-11/threads.html#00717
The current clause matching code in openmp.c's gfc_match_omp_variable_list
does:
m = gfc_match (" / %n /", n);
…
st = gfc_find_symtree (gfc_current_ns->common_root, n);
if (st == NULL)
{
gfc_error ("COMMON block /%s/ not found at %C", n);
Hence:
(1) This code requires the ordering
common /name/ …
!$omp … (/name/)
!$acc … (/name/)
while it would be (also) natural to use
!$omp … (/name/)
!$acc … (/name/)
common /name/ …
The Fortran standard usually permits this and at least part of the OpenXXX
specs talk only about the specification section, not imposing any ordering.
* Blank commons (i.e. common blocks without a name) cannot be matched.
Regarding blank commons: neither OpenMP nor OpenACC are clear whether they are
permitted and where. – However, in some clauses, OpenMP explicitly mentions
that blank commons are not permitted, implying that they are permitted
elsewhere. (See linked emails in the thread.)
[Bug c++/79592] incomplete diagnostic "is not usable as a constexpr function because:"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592 Jonathan Wakely changed: What|Removed |Added Keywords|accepts-invalid | Last reconfirmed|2017-08-21 00:00:00 |2019-11-29 --- Comment #3 from Jonathan Wakely --- (In reply to Eric Gallager from comment #1) > On a 32-bit target, it is always incorrectly accepted; adding -m64 is > necessary to get the incomplete diagnostic: That was a separate problem, fixed by r257161 for PR 68810.
[Bug ipa/92697] IPA-SRA modifies ifunc_resolvers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92697 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Jambor --- Fixed.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 --- Comment #5 from Marc Glisse --- a*x+x -> (a+1)*x is unsafe (a=INT_MAX, x=0), but there are cases where we could prove that it is safe, in particular when a is actually b-1 (more generally for a*x+b*x when we can prove (with VRP?) that a+b cannot overflow). Also, enabling -fwrapv for the last few gimple passes would help.
[Bug c++/79592] incomplete diagnostic "is not usable as a constexpr function because:"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > If the expression is (void*)1 rather than (void*)1LL then it is incorrectly > accepted. And that was the same problem, fixed by r257161.
[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Rainer Orth --- Sure.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 --- Comment #6 from Jakub Jelinek --- At least from the comments it seems fold_plusminus_mult_expr only handles (A * C) +- (B * C) -> (A +- B) * C (A * C) +- A -> A * (C +- 1) so for the testcases in question that is the latter and we punt because it is not wrapping arithmetics and it doesn't match one of the special cases in there. The suggestion I'll try to work on is to check if C isn't a plus/minus expr with constant second operand that doesn't go in the other direction and thus where the transformation isn't introducing UB. I guess it should be enough to do this in match.pd though.
[Bug rtl-optimization/92510] ICE in native_encode_rtx, at simplify-rtx.c:6272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Segher Boessenkool --- This is a bad PR to track all improvements that could be made to combine (and RTL in general). Closing as fixed.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug target/92729] New: [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 Bug ID: 92729 Summary: [avr] Convert the backend to MODE_CC so it can be kept in future releases Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- Target: avr-*-* This is a tracker bug for the convert the avr backend from CC0 to MODE_CC so it can be kept in future releases. See: https://gcc.gnu.org/wiki/CC0Transition I will be using this bug report to create a bounty on BountySource.com. We have already successfully funded such a conversion for the m68k backend, see #91851.
[Bug c++/92727] Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- (In reply to David Brown from comment #0) > Would it be possible to hide the messages concerning the allocator here? I don't see how. It's the allocator that tries to use the X(const X&) copy constructor. Why would you want to hide it? > In > general, would it be possible to hide the messages that deal with template > parameters that are unchanged from the default? Can you clarify what you mean? Nothing in this error has anything to do with default template arguments. You'll get exactly the same error with std::vector>. > That would let the user see > messages that are relevant to the code /they/ have written, rather than > implementation details in the libraries and headers. While that seems a noble goal, I don't think "hide the messages concerning the allocator" or "hide the messages that deal with template parameters that are unchanged from the default" get anywhere near that goal. > Even better, in this case, would be a hint that the user needs a std::move, > as shown in line B. Where should the compiler suggest that move? How does it know whether the missing std::move should be in main(), or inside std::vector::push_back, or inside allocator::construct? A reasonable heuristic would be to assume code inside system headers is correct, and that the code using those system headers is at fault, but it's still going to suggest the wrong place often. A better one would be to assume system headers are correct, and not suggest adding it anywhere that already uses std::forward, because that's probably generic code dealing with perfect forwarding, and the move should have been in the caller of *that* code. And you don't want to suggest adding std::move to a const value, because that won't help. The general problem is that inserting a std::move at some point in the call graph can completely change everything after that point, and so won't necessarily even reach the code that gave an error. Is that a "fix"? It's impossible to know without grokking the code.
[Bug c++/92727] Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727 --- Comment #2 from Jonathan Wakely --- Are you suggesting that everything inside libstdc++ code should be treated as a black box for the purposes of diagnostics, so that the location of the actual problem: error: use of deleted function ‘X::X(const X&)’ is shown as the "entry point" into the library code, i.e. the call to push_back in the user's code? That would be novel, and very unpopular with some people (who do want to be able to examine the library headers and see how/why they got to that point and what didn't compile).
[Bug tree-optimization/89280] [8 Regression] ICE: Segmentation fault (in is_gimple_reg_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89280 --- Comment #15 from Martin Liška --- *** Bug 92725 has been marked as a duplicate of this bug. ***
[Bug middle-end/92725] ICE: Segmentation fault during GIMPLE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92725 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 89280 ***
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 --- Comment #4 from Martin Liška --- Any update about this Segher?
[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Fri Nov 29 14:47:03 2019 New Revision: 278846 URL: https://gcc.gnu.org/viewcvs?rev=278846&root=gcc&view=rev Log: libstdc++:: improve how pretty printers find node types (PR 91997) This fixes two related problems. The iterators for node-based containers use nested typedefs such as std::list::iterator::_Node to denote their node types. As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1053438 those typedefs are not always present in the debug info. That means the pretty printers cannot find them using gdb.lookup_type (via the find_type helper). Instead of looking up the nested typedefs this patch makes the printers look up the actual class templates directly. A related problem (and the original topic of PR 91997) is that GDB fails to find types via gdb.lookup_type when printing a backtrace from a non-C++ functiion: https://sourceware.org/bugzilla/show_bug.cgi?id=25234 That is also solved by not looking up the nested typedef. PR libstdc++/91997 * python/libstdcxx/v6/printers.py (find_type): Fail more gracefully if we run out of base classes to look at. (llokup_templ_spec, lookup_node_type): New utilities to find node types for node-based containers. (StdListPrinter.children, NodeIteratorPrinter.__init__) (NodeIteratorPrinter.to_string, StdSlistPrinter.children) (StdSlistIteratorPrinter.to_string, StdRbtreeIteratorPrinter.__init__) (StdMapPrinter.children, StdSetPrinter.children) (StdForwardListPrinter.children): Use lookup_node_type instead of find_type. (StdListIteratorPrinter.__init__, StdFwdListIteratorPrinter.__init__): Pass name of node type to NodeIteratorPrinter constructor. (Tr1HashtableIterator.__init__): Rename argument. (StdHashtableIterator.__init__): Likewise. Use lookup_templ_spec instead of find_type. * testsuite/libstdc++-prettyprinters/59161.cc: Remove workaround for _Node typedef not being present in debuginfo. * testsuite/libstdc++-prettyprinters/91997.cc: New test. Added: trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/91997.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/59161.cc
[Bug tree-optimization/92710] [9/10 Regression] Vectoriser generates invalid simd call for bool arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92710 --- Comment #3 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Nov 29 14:47:44 2019 New Revision: 278851 URL: https://gcc.gnu.org/viewcvs?rev=278851&root=gcc&view=rev Log: Don't defer choice of vector type for bools (PR 92596) Now that stmt_vec_info records the choice between vector mask types and normal nonmask types, we can use that information in vect_get_vector_types_for_stmt instead of deferring the choice of vector type till later. vect_get_mask_type_for_stmt used to check whether the boolean inputs to an operation: (a) consistently used mask types or consistently used nonmask types; and (b) agreed on the number of elements. (b) shouldn't be a problem when (a) is met. If the operation consistently uses mask types, tree-vect-patterns.c will have corrected any mismatches in mask precision. (This is because we only use mask types for a small well-known set of operations and tree-vect-patterns.c knows how to handle any that could have different mask precisions.) And if the operation consistently uses normal nonmask types, there's no reason why booleans should need extra vector compatibility checks compared to ordinary integers. So the potential difficulties all seem to come from (a). Now that we've chosen the result type ahead of time, we also have to consider whether the outputs and inputs consistently use mask types. Taking each vectorizable_* routine in turn: - vectorizable_call vect_get_vector_types_for_stmt only handled booleans specially for gassigns, so vect_get_mask_type_for_stmt never had chance to handle calls. I'm not sure we support any calls that operate on booleans, but as things stand, a boolean result would always have a nonmask type. Presumably any vector argument would also need to use nonmask types, unless it corresponds to internal_fn_mask_index (which is already a special case). For safety, I've added a check for mask/nonmask combinations here even though we didn't check this previously. - vectorizable_simd_clone_call Again, vect_get_mask_type_for_stmt never had chance to handle calls. The result of the call will always be a nonmask type and the patch for PR 92710 rejects mask arguments. So all booleans should consistently use nonmask types here. - vectorizable_conversion The function already rejects any conversion between booleans in which one type isn't a mask type. - vectorizable_operation This function definitely needs a consistency check, e.g. to handle & and | in which one operand is loaded from memory and the other is a comparison result. Ideally we'd handle this via pattern stmts instead (like we do for the all-mask case), but that's future work. - vectorizable_assignment VECT_SCALAR_BOOLEAN_TYPE_P requires single-bit precision, so the current code already rejects problematic cases. - vectorizable_load Loads always produce nonmask types and there are no relevant inputs to check against. - vectorizable_store vect_check_store_rhs already rejects mask/nonmask combinations via useless_type_conversion_p. - vectorizable_reduction - vectorizable_lc_phi PHIs always have nonmask types. After the change above, attempts to combine the PHI result with a mask type would be rejected by vectorizable_operation. (Again, it would be better to handle this using pattern stmts.) - vectorizable_induction We don't generate inductions for booleans. - vectorizable_shift The function already rejects boolean shifts via type_has_mode_precision_p. - vectorizable_condition The function already rejects mismatches via useless_type_conversion_p. - vectorizable_comparison The function already rejects comparisons between mask and nonmask types. The result is always a mask type. 2019-11-29 Richard Sandiford gcc/ PR tree-optimization/92596 * tree-vect-stmts.c (vectorizable_call): Punt on hybrid mask/nonmask operations. (vectorizable_operation): Likewise, instead of relying on vect_get_mask_type_for_stmt to do this. (vect_get_vector_types_for_stmt): Always return a vector type immediately, rather than deferring the choice for boolean results. Use a vector mask type instead of a normal vector if vect_use_mask_type_p. (vect_get_mask_type_for_stmt): Delete. * tree-vect-loop.c (vect_determine_vf_for_stmt_1): Remove mask_producers argument and special boolean_type_node handling. (vect_determine_vf_for_stmt): Remove mask_producers argument and update calls to vect_determine_vf_for_stmt_1. Remove doubled call. (vect_determine_vectorization_factor): Update call accordingly. * tree-vect-slp.c (vect_build_slp_tree_1): Remove special boolean_type_node handling. (vect_slp_analyze_node_operations_1): Likewise. gcc/testsuite/ PR
[Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596 --- Comment #11 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Nov 29 14:47:44 2019 New Revision: 278851 URL: https://gcc.gnu.org/viewcvs?rev=278851&root=gcc&view=rev Log: Don't defer choice of vector type for bools (PR 92596) Now that stmt_vec_info records the choice between vector mask types and normal nonmask types, we can use that information in vect_get_vector_types_for_stmt instead of deferring the choice of vector type till later. vect_get_mask_type_for_stmt used to check whether the boolean inputs to an operation: (a) consistently used mask types or consistently used nonmask types; and (b) agreed on the number of elements. (b) shouldn't be a problem when (a) is met. If the operation consistently uses mask types, tree-vect-patterns.c will have corrected any mismatches in mask precision. (This is because we only use mask types for a small well-known set of operations and tree-vect-patterns.c knows how to handle any that could have different mask precisions.) And if the operation consistently uses normal nonmask types, there's no reason why booleans should need extra vector compatibility checks compared to ordinary integers. So the potential difficulties all seem to come from (a). Now that we've chosen the result type ahead of time, we also have to consider whether the outputs and inputs consistently use mask types. Taking each vectorizable_* routine in turn: - vectorizable_call vect_get_vector_types_for_stmt only handled booleans specially for gassigns, so vect_get_mask_type_for_stmt never had chance to handle calls. I'm not sure we support any calls that operate on booleans, but as things stand, a boolean result would always have a nonmask type. Presumably any vector argument would also need to use nonmask types, unless it corresponds to internal_fn_mask_index (which is already a special case). For safety, I've added a check for mask/nonmask combinations here even though we didn't check this previously. - vectorizable_simd_clone_call Again, vect_get_mask_type_for_stmt never had chance to handle calls. The result of the call will always be a nonmask type and the patch for PR 92710 rejects mask arguments. So all booleans should consistently use nonmask types here. - vectorizable_conversion The function already rejects any conversion between booleans in which one type isn't a mask type. - vectorizable_operation This function definitely needs a consistency check, e.g. to handle & and | in which one operand is loaded from memory and the other is a comparison result. Ideally we'd handle this via pattern stmts instead (like we do for the all-mask case), but that's future work. - vectorizable_assignment VECT_SCALAR_BOOLEAN_TYPE_P requires single-bit precision, so the current code already rejects problematic cases. - vectorizable_load Loads always produce nonmask types and there are no relevant inputs to check against. - vectorizable_store vect_check_store_rhs already rejects mask/nonmask combinations via useless_type_conversion_p. - vectorizable_reduction - vectorizable_lc_phi PHIs always have nonmask types. After the change above, attempts to combine the PHI result with a mask type would be rejected by vectorizable_operation. (Again, it would be better to handle this using pattern stmts.) - vectorizable_induction We don't generate inductions for booleans. - vectorizable_shift The function already rejects boolean shifts via type_has_mode_precision_p. - vectorizable_condition The function already rejects mismatches via useless_type_conversion_p. - vectorizable_comparison The function already rejects comparisons between mask and nonmask types. The result is always a mask type. 2019-11-29 Richard Sandiford gcc/ PR tree-optimization/92596 * tree-vect-stmts.c (vectorizable_call): Punt on hybrid mask/nonmask operations. (vectorizable_operation): Likewise, instead of relying on vect_get_mask_type_for_stmt to do this. (vect_get_vector_types_for_stmt): Always return a vector type immediately, rather than deferring the choice for boolean results. Use a vector mask type instead of a normal vector if vect_use_mask_type_p. (vect_get_mask_type_for_stmt): Delete. * tree-vect-loop.c (vect_determine_vf_for_stmt_1): Remove mask_producers argument and special boolean_type_node handling. (vect_determine_vf_for_stmt): Remove mask_producers argument and update calls to vect_determine_vf_for_stmt_1. Remove doubled call. (vect_determine_vectorization_factor): Update call accordingly. * tree-vect-slp.c (vect_build_slp_tree_1): Remove special boolean_type_node handling. (vect_slp_analyze_node_operations_1): Likewise. gcc/testsuite/ PR
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 --- Comment #7 from Marc Glisse --- The first question could be why SCCP produces (const int) ((unsigned int) t_2(D) + 4294967295) * v_3(D) + v_3(D) and not directly t*v. Several loop passes do have this tendency to split out the last (or first) iteration and produce strange expressions that we have trouble cleaning up afterwards. Anyway, in VRP2, I see _10: int [0, 2147483646] _14 = v_3(D) * _10; x_6 = v_3(D) + _14; so range info would allow to prove that _10 + 1 cannot overflow, and thus to factor out v_3(D). I have long wanted a op_cannot_overflow(tree_code,tree,tree) utility...
[Bug tree-optimization/92677] [10 Regression] ICE in get_group_load_store_type, at tree-vect-stmts.c:2261 since r271704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92677 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Nov 29 14:48:30 2019 New Revision: 278852 URL: https://gcc.gnu.org/viewcvs?rev=278852&root=gcc&view=rev Log: Fix DR_GROUP_GAP for strided accesses (PR 92677) When dissolving an SLP-only group of accesses, we should only set the gap to group_size - 1 for normal non-strided groups. 2019-11-29 Richard Sandiford gcc/ PR tree-optimization/92677 * tree-vect-loop.c (vect_dissolve_slp_only_groups): Set the gap to zero when dissolving a group of strided accesses. gcc/testsuite/ PR tree-optimization/92677 * gcc.dg/vect/pr92677.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr92677.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 --- Comment #5 from Segher Boessenkool --- It's not top priority; it is fine for stage 4, too. Patches welcome.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 --- Comment #8 from Marc Glisse --- (In reply to Jakub Jelinek from comment #6) > The suggestion I'll try to work on is to check if C isn't a plus/minus expr > with constant second operand that doesn't go in the other direction and thus > where the transformation isn't introducing UB. In the testcase, t-1 is computed in some unsigned type and then cast back to signed, so I don't think it will work. > I guess it should be enough to do this in match.pd though. Yes.
[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 Jonathan Wakely changed: What|Removed |Added Target Milestone|10.0|8.4 --- Comment #8 from Jonathan Wakely --- Fixed on trunk, backports to follow.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 --- Comment #9 from rguenther at suse dot de --- On November 29, 2019 3:25:45 PM GMT+01:00, "glisse at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 > >--- Comment #5 from Marc Glisse --- >a*x+x -> (a+1)*x is unsafe (a=INT_MAX, x=0), but there are cases where >we could >prove that it is safe, in particular when a is actually b-1 (more >generally for >a*x+b*x when we can prove (with VRP?) that a+b cannot overflow). > >Also, enabling -fwrapv for the last few gimple passes would help. I had a patch for that, RTL is also wrapv.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 --- Comment #10 from Jakub Jelinek --- (In reply to Marc Glisse from comment #8) > (In reply to Jakub Jelinek from comment #6) > > The suggestion I'll try to work on is to check if C isn't a plus/minus expr > > with constant second operand that doesn't go in the other direction and thus > > where the transformation isn't introducing UB. > > In the testcase, t-1 is computed in some unsigned type and then cast back to > signed, so I don't think it will work. I know, it will be a small complication, sure, but it can be handled. Using range info is certainly useful, but e.g. for this case with -1U it will not be able to do anything, as the range of (int)(t-1U) will be varying. So I think we want both.
[Bug c/92286] Possible improvement for -Wduplicated-cond warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92286 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Martin Liška --- Based on Eric wrote, I tend to close it as won't fix.
[Bug rtl-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #26 from Vladimir Makarov ---
I think I find the problem root. We have
** Local #2: **
Choosing alt 0 in insn 1804: (0) =v (1) %0 (2) vm (3) v
{*fma_fmadd_df}
Creating newreg=4707 from oldreg=1801, assigning class ALL_SSE_REGS to
r4707
Creating newreg=4708 from oldreg=1801, assigning class ALL_SSE_REGS to
r4708
Making reload reg 4708 for reg 1801 optional
1804: r4707:DF={r4707:DF*r4708:DF+r984:DF}
! REG_DEAD r1801:DF
REG_DEAD r984:DF
Inserting insn reload before:
10917: r4707:DF=r1801:DF
10919: r4708:DF=r1801:DF
Inserting insn reload after:
10918: r238:DF=r4707:DF
.
Choosing alt 2 in insn 1814: (0) v (1) v (2) vm (3) 0
{*fma_fmadd_df}
Creating newreg=4709 from oldreg=1801, assigning class ALL_SSE_REGS to
r4709
Making reload reg 4709 for reg 1801 optional
1814: r244:DF={r1795:DF*r4709:DF+r1803:DF}
REG_DEAD r1801:DF
REG_DEAD r1803:DF
Inserting insn reload before:
10920: r4709:DF=r1801:DF
** Inheritance #2: **
<<
Use smallest class of ALL_SSE_REGS and SSE_REGS
Creating newreg=4778 from oldreg=1801, assigning class ALL_SSE_REGS to
inheritance r4778
Original reg change 1801->4778 (bb177):
10920: r4709:DF=r4778:DF
Add inheritance<-original before:
10995: r4778:DF=r1801:DF
Inheritance reuse change 1801->4778 (bb177):
10019: r3911:DF=r4778:DF
REG_DEAD r4778:DF
<<
Use smallest class of ALL_SSE_REGS and SSE_REGS
Creating newreg=4779 from oldreg=1801, assigning class ALL_SSE_REGS to
inheritance r4779
Original reg change 1801->4779 (bb177):
! 10919: r4708:DF=r4779:DF
Add inheritance<-original before:
10996: r4779:DF=r1801:DF
Inheritance reuse change 1801->4779 (bb177):
10995: r4778:DF=r4779:DF
** Assignment #2: **
Assigning to 4779 (cl=ALL_SSE_REGS, orig=1801, freq=18, tfirst=4707,
tfreq=36)...
Assigning to 4778 (cl=ALL_SSE_REGS, orig=1801, freq=18, tfirst=4707,
tfreq=36)...
Assigning to 4780 (cl=ALL_SSE_REGS, orig=1801, freq=18, tfirst=4707,
tfreq=36)...
Assign 26 to inheritance r4780 (freq=18)
Reassigning non-reload pseudos
Assign 4 to r237 (freq=26)
Assign 26 to inheritance r4778 (freq=18)
!Hard reg 26 is preferable by r4779 with profit 24
Assign 26 to inheritance r4779 (freq=18)
We assigned 26 for conflicting 4779 and 4707 because they have the same value
1802 (from r1801).
4707 got the same value as 1801 because LRA sees wrong (REG_DEAD r1801:DF) in
insn 1804. In most cases LRA uses live-ranges but in constraint sub-pass it
can use reg notes too.
Live ranges and reg notes should be synchronized but in this case we did not
update notes after
first inheritance sub-pass although there were some changes there too.
I working on a patch. If the tests are ok, I commit the patch today.
[Bug tree-optimization/92710] [9 Regression] Vectoriser generates invalid simd call for bool arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92710 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[9/10 Regression] |[9 Regression] Vectoriser |Vectoriser generates|generates invalid simd call |invalid simd call for bool |for bool arguments |arguments | --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed on trunk so far.
[Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/92677] [10 Regression] ICE in get_group_load_store_type, at tree-vect-stmts.c:2261 since r271704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92677 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug c++/92727] Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727 --- Comment #3 from David Brown --- I may not have been very clear here. Let me try and take a step back here. >From the user's viewpoint, the problem is that they have made a class that can't be copied, and they have written code that tries to copy it. With the current error messages, point comes across - but it is hidden amongst a lot of messages about "allocators" that will be unfamiliar to many users, and unhelpful to most users. I fully appreciate the problem occurs when the allocator that tries to use the copy constructor. But the user has not specified an allocator, or picked an allocator, or mentioned allocators in their code - and perhaps does not even know what they are. Most users are happy to accept "it goes in memory somewhere", or "it is on the heap", without worrying about the details. What I am hoping for here is some way to help the user get the part of the error information that is important to them, and will help them fix their code, without unnecessary detail. What I meant about default template parameters is that - as you say - some people /do/ want all the details of the messages about the allocator. These are mostly in two groups - people using non-default allocators, and people who want to deal with the details of the standard library. The first group can be identified by their use of explicit allocators in the template instantiation rather than using the defaults, and the second could perhaps use an additional compiler switch (a little like the current "-Wsystem-headers" switch). So yes, I /am/ suggesting that the error location should be given as the "v.push_back(x);" line. And yes, I am aware that it would not be ideal for experts - but I think it would be clearer to a majority of users. And that would be novel! Part of the job of a compiler is to help people write correct code, and clear error and warning messages are essential for that. (Let me also say that gcc does a fine job here, and has improved enormously over the years that I have used it - though it could still be better.) Perhaps this could be better handled using concepts? Maybe "push_back" could be declared to take a parameter with a concept requiring either a type that could be copied into the vector or a type that is a compatible rvalue reference? Or perhaps concepts and "if constexpr" in C++17 would make it practical to make the "push_back(const T&)" overload unavailable if T is not copyable? That would get you straight to a "no matching function call for std::vector::push_back(X&)" message on the offending line.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 --- Comment #11 from Marc Glisse --- (In reply to Jakub Jelinek from comment #10) > I know, it will be a small complication, sure, but it can be handled. Ah, I think I understand now. But still x=-1 a=INT_MAX a*x+x gives INT_MIN without overflow. Now a could be (int)((unsigned)b-1) where b is INT_MIN. But we don't want to generate b*x for that (INT_MIN*-1), since it overflows. So we would need to do the multiplication in some unsigned type. If we go there (do everything unsigned), we could do the transformation always, and restricting it is just a heuristic for when the signed type information might be more useful than the factorized form. > Using range info is certainly useful, but e.g. for this case with -1U it > will not be able to do anything, as the range of (int)(t-1U) will be > varying. So I think we want both. In this very particular case, it happens that we have if(t>0) dominating this stuff, which helps VRP.
[Bug c++/92727] Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #4 from Jonathan Wakely ---
(In reply to David Brown from comment #3)
> Perhaps this could be better handled using concepts?
Yes, ideally. That stops compilation as soon as you try to call something that
fails to satisfy the constraints (in this case, that the vector's value type is
constructible from the argument to push_back).
> Maybe "push_back"
> could be declared to take a parameter with a concept requiring either a type
> that could be copied into the vector or a type that is a compatible rvalue
> reference?
We can't change the parameter type of push_back, that would not be conforming.
> Or perhaps concepts and "if constexpr" in C++17 would make it
> practical to make the "push_back(const T&)" overload unavailable if T is not
> copyable? That would get you straight to a "no matching function call for
> std::vector::push_back(X&)" message on the offending line.
if-constexpr can't help, that can only be used inside the function, by which
point it's too late.
I don't think concepts are really practical either, because we're limited where
we can reasonably use them. std::vector has to be usable in C++98 still, and
implementing the whole thing twice (with and without concepts in the API) would
be a maintenance nightmare.
Also, altering the overload set as you suggest needs to be done *very*
carefuly, or what happens is you end up removing one bad function and so a
different function gets called instead. You need to consider the entire
overload set at once.
I think a much more maintainable approach is something like:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -1183,6 +1183,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
void
push_back(const value_type& __x)
{
+#if __cplusplus >= 201703L
+ if constexpr (is_same_v>)
+ static_assert(is_copy_constructible_v);
+#endif
if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
{
_GLIBCXX_ASAN_ANNOTATE_GROW(1);
With that change your example prints:
In file included from /home/jwakely/gcc/10/include/c++/10.0.0/vector:67,
from up.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h: In instantiation of
'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = X;
_Alloc = std::allocator; std::vector<_Tp, _Alloc>::value_type = X]':
up.cc:14:18: required from here
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1188:18: error:
static assertion failed
1188 |static_assert(is_copy_constructible_v);
| ^~~
I think trying to do this via "smart" diagnostics would be doomed to failure.
Enforcing preconditions via static_assert is much more reliable, and easier to
tweak to improve it. Somebody just needs to add those assertions.
[Bug c++/92727] Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727 --- Comment #5 from Jonathan Wakely --- The downside of this (and your suggestion to remove push_back from the overload set) is that you no longer get told the copy constructor is deleted and why. That note is only printed when the copy constructor is needed, but this approach means it never gets used, because the assertions stops it getting that far.
[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712 --- Comment #12 from Jakub Jelinek --- (In reply to Marc Glisse from comment #11) > (In reply to Jakub Jelinek from comment #10) > > I know, it will be a small complication, sure, but it can be handled. > > Ah, I think I understand now. But still > > x=-1 > a=INT_MAX > a*x+x gives INT_MIN without overflow. > Now a could be (int)((unsigned)b-1) where b is INT_MIN. But we don't want to > generate b*x for that (INT_MIN*-1), since it overflows. So we would need to > do the multiplication in some unsigned type. If we go there (do everything > unsigned), we could do the transformation always, and restricting it is just > a heuristic for when the signed type information might be more useful than > the factorized form. The comments at least in fold-const.c say clearly that we do not want to perform unsigned multiplication. I was talking about the int a, b; ((int)(a-1U))*b+b transformation into a*b. Even for a=0, it is -1*b+b into 0, there could be UB before, but there is none after. a=INT_MIN used to be INT_MAX*b+b and newly INT_MIN*b, well defined for b=0, UB for b > 0, UB for b < -1, but it is true that INT_MAX*-1+-1 is well defined INT_MIN, but INT_MIN*-1 is UB. So guess we need to use range info only then.
[Bug c++/92193] Poor diagnostics when a constexpr function call follows a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92193
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-29
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
This results in a far worse experience for users in C++20, where lots more
things become constexpr.
With the patch I suggested in Bug 92727 comment 4 the diagnostic in C++17 mode
would be:
In file included from /home/jwakely/gcc/10/include/c++/10.0.0/vector:67,
from up.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h: In instantiation of
'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = X;
_Alloc = std::allocator; std::vector<_Tp, _Alloc>::value_type = X]':
up.cc:14:18: required from here
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1188:18: error:
static assertion failed
1188 |static_assert(is_copy_constructible_v);
| ^~~
But compiling the exact same code with -std=gnu++2a gives:
In file included from /home/jwakely/gcc/10/include/c++/10.0.0/vector:67,
from up.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h: In instantiation of
'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = X;
_Alloc = std::allocator; std::vector<_Tp, _Alloc>::value_type = X]':
up.cc:14:18: required from here
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1188:18: error:
static assertion failed
1188 |static_assert(is_copy_constructible_v);
| ^~~
In file included from
/home/jwakely/gcc/10/include/c++/10.0.0/ext/alloc_traits.h:34,
from
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_uninitialized.h:67,
from /home/jwakely/gcc/10/include/c++/10.0.0/vector:66,
from up.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h: In instantiation
of 'static constexpr void std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&,
_Up*, _Args&& ...) [with _Up = X; _Args = {const X&}; _Tp = X;
std::allocator_traits >::allocator_type =
std::allocator]':
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1193:30: required
from 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp =
X; _Alloc = std::allocator; std::vector<_Tp, _Alloc>::value_type = X]'
up.cc:14:18: required from here
/home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h:504:20: error: use
of deleted function 'X::X(const X&)'
504 | noexcept(noexcept(::new((void*)__p) _Up(std::declval<_Args>()...)))
|^~~
up.cc:6:7: note: 'X::X(const X&)' is implicitly deleted because the default
definition would be ill-formed:
6 | class X {
| ^
up.cc:6:7: error: use of deleted function 'std::unique_ptr<_Tp,
_Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = Y; _Dp =
std::default_delete]'
In file included from /home/jwakely/gcc/10/include/c++/10.0.0/memory:82,
from up.cc:2:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/unique_ptr.h:456:7: note: declared
here
456 | unique_ptr(const unique_ptr&) = delete;
| ^~
In file included from
/home/jwakely/gcc/10/include/c++/10.0.0/ext/alloc_traits.h:34,
from
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_uninitialized.h:67,
from /home/jwakely/gcc/10/include/c++/10.0.0/vector:66,
from up.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h: In instantiation
of 'static constexpr void std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&,
_Up*, _Args&& ...) [with _Up = X; _Args = {const X&}; _Tp = X;
std::allocator_traits >::allocator_type =
std::allocator]':
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1193:30: required
from 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp =
X; _Alloc = std::allocator; std::vector<_Tp, _Alloc>::value_type = X]'
up.cc:14:18: required from here
/home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h:509:21: error: no
matching function for call to 'construct_at(X*&, const X&)'
509 |std::construct_at(__p, std::forward<_Args>(__args)...);
|~^
In file included from
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_tempbuf.h:60,
from
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_algo.h:62,
from /home/jwakely/gcc/10/include/c++/10.0.0/vector:62,
from up.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_construct.h:94:5: note:
candidate: 'template constexpr decltype
[Bug c++/92727] Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727 --- Comment #6 from David Brown --- I can see it is a challenge to get enough detail in the messages to be good for the more advanced users, and still simple enough and clear enough for more casual or inexperienced users. The static assertion looks good to me, and is clearly the easiest way to implement such a feature. But I appreciate that it would not be ideal for some people, and would hide useful messages from them. Perhaps the a better place to focus would be on IDE's, maybe especially with parsing of the new JSON format, to help people see exactly where the problem lies in their code.
[Bug fortran/92730] New: [OpenMP] Common blocks in map() clause not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92730 Bug ID: 92730 Summary: [OpenMP] Common blocks in map() clause not accepted Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- See also PR 92728 and the thread at https://gcc.gnu.org/ml/gcc-patches/2019-11/threads.html#00717 Pre-remark, as remembered just now: "Named common blocks of the same name shall be of the same size in all scoping units of a program in which they appear, but blank common blocks may be of different sizes." (Fortran 2018, 8.10.2.5) From the thread: > In OpenMP 5, common blocks appear twice – once [2.1, p.39, ll.11ff.] as > general rule in the definition of "list item" (which are inherited by > "extended list item" and "locator-list item"). [There are also some > constraints and notes regarding common blocks)]. It does not really tell > whether blank commons are permitted or not; some description is > explicitly for named-common variables, leaving blank-common ones out > (and undefined). But later sections explicitly make reference to blank > commons, hence, one can assume they are permitted unless explicitly > stated that they are not. > > And then very selectively for some items: > * allocate – only with default allocator. > * declare target – some restrictions and no blank commons > * depend clause – no common permitted > * threadprivate – some notes and explanation of the syntax (why?) >also only here requirement regarding common blocks with bind(c) >(why not also for declare target?) > * linear clause – no common permitted > * copyin – some notes > * copyprivate – some notes > > As target test cases were suspiciously left out, I tries '!$omp target > map(/name/)' which was rejected.
[Bug c++/92727] Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727 --- Comment #7 from Jonathan Wakely --- (In reply to David Brown from comment #6) > I can see it is a challenge to get enough detail in the messages to be good > for the more advanced users, and still simple enough and clear enough for > more casual or inexperienced users. > > The static assertion looks good to me, and is clearly the easiest way to > implement such a feature. But I appreciate that it would not be ideal for > some people, and would hide useful messages from them. I disagree. The static assert contains all you need to know, expert or not. The benefit of seeing all the gory details is to figure out why something didn't compile, and what (possibly implicit) requirement your code failed to meet. If the maintainer of the library explicitly spelled out that requirement with a static_assert, then there's no need to see any more detail, because there's no need to infer the requirement from the code. Unfortunately that nice diagnostic from the static_assert turns into a total mess in C++20 mode, see Bug 92193 comment 2. My preference for this bug would be to reassign it to libstdc++ and hope that people pick up the baton and submit patches to add static_assert in places where it improves the user experience. That can be done piecemeal, and improved over time.
[Bug fortran/92728] [OpenMP][OpenACC] Common-block name clause matching issues: common block needs to be defined before + blank common not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92728 --- Comment #1 from Tobias Burnus --- See also PR 92730 for a related issue (OpenMP's map() does not handle /common/) Remark, as I only just remembered: "Named common blocks of the same name shall be of the same size in all scoping units of a program in which they appear, but blank common blocks may be of different sizes." (Fortran 2018, 8.10.2.5) If the common block is only on the host – and uses map(/block/), mapping single variables is fine. If it is only on the device, it is also fine – it only becomes interesting if the same-named common block is on both device and host. In this case, they have to be named (= same size) and a copy(/map/) should really copy the whole block and not only the (directly) used common-block variables. For OpenACC, device_resident seems to be about this feature, OpenMP seems to be silent on this topic.
[Bug c++/92727] Idea for better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727 --- Comment #8 from David Brown --- I don't think there is anything more I can add at the moment. Thank you for your efforts.
