[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495 Martin Liška changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #15 from Martin Liška --- Just for the record, I believe the same revision improved rapidly mcf benchmark in various configurations: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=232.347.0=18.347.0=287.347.0
[Bug c++/94597] [10 Regression] ICE while using a concept checking for user defined conversion operator since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94597
Martin Liška changed:
What|Removed |Added
Known to fail||10.0
CC||jason at gcc dot gnu.org,
||marxin at gcc dot gnu.org
Keywords||ice-on-valid-code
Ever confirmed|0 |1
Summary|ICE while using a concept |[10 Regression] ICE while
|checking for user defined |using a concept checking
|conversion operator |for user defined conversion
||operator since
||r10-3735-gcb57504a55015891
Known to work||9.3.0
Target Milestone|--- |10.0
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-04-15
--- Comment #1 from Martin Liška ---
Confirmed, started with r10-3735-gcb57504a55015891.
Reduced test-case:
$ cat pr94597.ii
template concept d = requires(b e) { e.operator c; };
template requires(d) bool equal(f, g);
template struct i {
i(h);
operator h();
};
bool fun() {
i a(2.0f);
return equal(a, 3.0f);
}
$ g++ -std=c++2a -fconcepts pr94597.ii -c
pr94597.ii: In instantiation of ‘bool equal(f, g) [with f = i; g =
float]’:
pr94597.ii:9:23: required from here
pr94597.ii:1:74: internal compiler error: tree check: accessed elt 2 of
‘tree_vec’ with 1 elts in tsubst, at cp/pt.c:15175
1 | template concept d = requires(b e) {
e.operator c; };
|
~~~^
0x84239d tree_vec_elt_check_failed(int, int, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9928
0x6a6a8b tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3508
0x6a6a8b tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:15175
0xab6c3b tsubst_copy
/home/marxin/Programming/gcc/gcc/cp/pt.c:16821
0xabd7e4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:20125
0xab0677 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18690
0x982f25 tsubst_valid_expression_requirement
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:1867
0x982f25 tsubst_simple_requirement
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:1880
0x982f25 tsubst_requirement
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2032
0x982f25 tsubst_requirement_body
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2054
0x982f25 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2170
0xabd8da tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:20440
0xab0677 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18690
0x9829d8 satisfy_atom
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2595
0x9829d8 satisfy_constraint_r
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2657
0x982dd8 satisfy_constraint
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2677
0x983f42 satisfy_declaration_constraints
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2776
0x983f42 constraint_satisfaction_value
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2812
0x9843fa constraints_satisfied_p(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2846
0x933368 add_function_candidate
/home/marxin/Programming/gcc/gcc/cp/call.c:2288
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/94598] [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2360 with -O1 or higher since r10-6321-g636e80eea24b780f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598 Martin Liška changed: What|Removed |Added Known to work||9.3.0 Target Milestone|--- |10.0 CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Keywords||ice-on-valid-code Last reconfirmed||2020-04-15 Priority|P3 |P1 Known to fail||10.0 Target|aarch64-none-elf|aarch64-none-elf, ||x86_64-linux-gnu Summary|ICE in |[10 Regression] ICE in |verify_sra_access_forest, |verify_sra_access_forest, |at tree-sra.c:2360 with -O1 |at tree-sra.c:2360 with -O1 |or higher |or higher since ||r10-6321-g636e80eea24b780f Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed on x86_64-linux-gnu, started with r10-6321-g636e80eea24b780f.
[Bug analyzer/94596] possible false positive when analyze OVS macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Target Milestone|--- |10.0
[Bug bootstrap/92008] Build failure on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008 --- Comment #8 from Andrew Pinski --- (In reply to fdlbxtqi from comment #7) > (In reply to Andrew Pinski from comment #6) > > https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff > > > > is more the correct fix. > > Or use an older version of Bison. > > But I am using windows. So?? I should contact MSYS2 for fixing it? No, the fix is to include a similar fix to gcc sources. The new intl sources need to pick up to gcc sources.
[Bug bootstrap/92008] Build failure on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008 --- Comment #7 from fdlbxtqi --- (In reply to Andrew Pinski from comment #6) > https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff > > is more the correct fix. > Or use an older version of Bison. But I am using windows. So?? I should contact MSYS2 for fixing it?
[Bug bootstrap/94601] Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601 --- Comment #5 from Andrew Pinski --- (In reply to fdlbxtqi from comment #4) > Created attachment 48276 [details] > Let me try whether this patch works. That is wrong. See the duplicated bug.
[Bug bootstrap/92008] Build failure on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008 --- Comment #6 from Andrew Pinski --- https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff is more the correct fix. Or use an older version of Bison.
[Bug bootstrap/94601] Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601 --- Comment #4 from fdlbxtqi --- Created attachment 48276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48276=edit Let me try whether this patch works.
[Bug bootstrap/92008] Build failure on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008 --- Comment #5 from Andrew Pinski --- Looks like the problem is with Bison 3.0 and above with the internal intl BASH has/had the same issue: https://savannah.gnu.org/support/?109469
[Bug target/92008] Build failure on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008 Andrew Pinski changed: What|Removed |Added CC||euloanty at live dot com --- Comment #4 from Andrew Pinski --- *** Bug 94601 has been marked as a duplicate of this bug. ***
[Bug bootstrap/94601] Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 92008. *** This bug has been marked as a duplicate of bug 92008 ***
[Bug preprocessor/94601] Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601 --- Comment #2 from Andrew Pinski --- (In reply to fdlbxtqi from comment #1) > Can you guys stop using macros and migrate to namespace? This is C code . Plus this code has not changed and is really pulled in from upstream (libintl).
[Bug preprocessor/94601] Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601 --- Comment #1 from fdlbxtqi --- Can you guys stop using macros and migrate to namespace?
[Bug bootstrap/94601] New: Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601 Bug ID: 94601 Summary: Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: euloanty at live dot com Target Milestone: --- In file included from ../../gcc-git/intl/plural.y:35: ../../gcc-git/intl/plural-exp.h:102:23: error: conflicting types for 'libintl_gettextparse' 102 | # define PLURAL_PARSE libintl_gettextparse | ^~~~ ../../gcc-git/intl/plural.y:40:25: note: x86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS -DHAVE_CONFIG_H -I. -I../../gcc-git/intl ../../gcc-git/intl/relocatex.c in expansion of macro 'no PLURAL_PARSEx86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS - DHAVE_CONFIG ' 40 | # define __gettextparse PLURAL_PARSE | ^~~~ x86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS -DHAVE_CONFIG _H -I. -I../../gcc-git/intl ../../gcc-git/intl/localename.c plural.c:199:5: note: in expansion of macro '__gettextparse' 199 | int x86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS - DHAVE_CONFIG_H -I. -I../../gcc-git/intl ../../gcc-git/intl/log.c __gettextparse (void); | x86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS - DHAVE_CONFIG_H -I. -I../../gcc-git/intl ../../gcc-git/intl/osdep.c^~ ../../gcc-git/intl/plural-exp.h:102:23: note: previous declaration of 'libintl_gettextparse' was here 102 | # define PLURAL_PARSE libintl_gettextparsex86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -march=x86-64 -mtune=ge neric -O2 -pipe -D__USE_MINGW_ACCESS -DHAVE_CONFIG_H -I. -I../../gcc-git/intl ../../gcc-git/intl/intl-compat.c | ^~~~ ../../gcc-git/intl/plural-exp.h:114:12: note: in expansion of macro 'PLURAL_PARSE' 114 | extern int PLURAL_PARSE PARAMS ((void *arg)); |^~~~ ../../gcc-git/intl/plural-exp.h:102:23: error: conflicting types for 'libintl_gettextparse' 102 | # define PLURAL_PARSE no libintl_gettextparse | ^~~~ ../../gcc-git/intl/plural.y:40:25: no note: in expansion of macro 'PLURAL_PARSE' 40 | # define __gettextparse PLURAL_PARSE | ^~~~ plural.c:67:25: note: in expansion of macro '__gettextparse' 67 | #define yyparse __gettextparse | ^~ plural.c:1220:1: note: in expansion of macro 'yyparse' 1220 | yyparse (void) | ^~~ ../../gcc-git/intl/plural-exp.h:102:23: note: previous declaration of 'libintl_gettextparse' was here 102 | # define PLURAL_PARSE libintl_gettextparseconfig.status: creating Makefile | ^~~~ ../../gcc-git/intl/plural-exp.h:114:12: note: in expansion of macro 'PLURAL_PARSE' 114 | extern int PLURAL_PARSE PARAMS ((void *arg)); |^~~~ plural.c: In function 'libintl_gettextparse': plural.c:68:25: error: too few arguments to function '__gettextlex' 68 | #define yylex __gettextlex | ^~~~ checking for stpncpy... plural.c:1398:16: note: in expansion of macro 'checking for stpncpy... yylex' 1398 | yychar = yylex (); |^ plural.c:68:25: note: declared here 68 | #define yylex __gettextlex | ^~~~ ../../gcc-git/intl/plural.y:69:12: note: in expansion of macro 'yylex' 69 | static int yylex PARAMS ((YYSTYPE *lval, const char **pexp)); |^ ../../gcc-git/intl/plural.y:178:29: error: 'arg' undeclared (first use in this function) 178 | ((struct parse_args *) arg)->res = $1; | ^~~ ../../gcc-git/intl/plural.y:178:29: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [Makefile:139: plural.o] Error 1 make[2]: *** Waiting for unfinished jobs config.status: creating backtrace-supported.h no checking whether putchar_unlocked is declared... config.status: creating install-debuginfo-for-buildid.sh no no make[2]: Leaving directory '/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/intl'
[Bug driver/19856] GCC_EXEC_PREFIX used wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19856 --- Comment #5 from Bryan Henderson --- A quick check of the latest manual shows the same description, and a quick strace of GCC 6.3 shows the same behavior, so my guess is no one has touched this area.
[Bug target/94584] memw is missing before u8/u16 volatile loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94584 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- Fixed in the master.
[Bug c++/92777] ICE on concept containing lambda with auto variable declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92777 Jason Cobb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Cobb --- Fixed in trunk.
[Bug target/93847] Nios II ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- Your "test cases" are not useful. Please provide something self-contained (e.g., preprocessed source code for the file that GCC ICEs on), that does not depend on all of some version of buildroot. Also please provide the complete set of command-line options used for building that file.
[Bug c++/89743] [concepts] ICE when using decltype(requires-expr) as type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89743 Jason Cobb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Cobb --- Fixed in trunk.
[Bug c++/89657] [concepts] ICE when calling lambda returning requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657 Jason Cobb changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Cobb --- Fixed at some point.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 89657, which changed state. Bug 89657 Summary: [concepts] ICE when calling lambda returning requires-expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/94475] [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94475 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug target/94584] memw is missing before u8/u16 volatile loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94584 --- Comment #1 from CVS Commits --- The master branch has been updated by Max Filippov : https://gcc.gnu.org/g:a288e202c5e50704968685fc2922d159335be2cb commit r10-7728-ga288e202c5e50704968685fc2922d159335be2cb Author: Max Filippov Date: Mon Apr 13 13:26:04 2020 -0700 xtensa: fix PR target/94584 Patterns zero_extendhisi2, zero_extendqisi2 and extendhisi2_internal can load value from memory, but they don't treat volatile memory correctly. Add %v1 before load instructions to emit 'memw' instruction when -mserialize-volatile is in effect. 2020-04-14 Max Filippov gcc/ * config/xtensa/xtensa.md (zero_extendhisi2, zero_extendqisi2) (extendhisi2_internal): Add %v1 before the load instructions. gcc/testsuite/ * gcc.target/xtensa/pr94584.c: New test.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #10 from dave.anglin at bell dot net --- On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote: > So, hppa64 has REAL(16), but it does not use __float128 or > GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead > of the above kludge you can do something like It appears GFC_REAL_16_IS_FLOAT128 is not getting set. Will investigate. There's a similar problem with the test dec_math.f90 which has started to fail We have when the hpux long double library is available: /* Under HPUX, the __float128 type is a synonym for "long double". */ (*lang_hooks.types.register_builtin_type) (long_double_type_node, "__float128"); We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and __builtin_huge_valq. I suppose I could add "l" versions. #ifndef HAVE_COSL #define cosl cosq /* Use libquadmath for hppa64. */ #endif Yes, that seems an option.
[Bug c++/59673] wrong specialization used when a partial specialization of a member template is explicitly specialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59673
Cameron changed:
What|Removed |Added
CC||dacamara.cameron at gmail dot
com
--- Comment #1 from Cameron ---
I also observe the breakage with gcc10:
struct A {
class B { };
template
class C { };
};
template
struct U {
template
static constexpr bool tvalue = false;
};
template <>
template
constexpr bool U::tvalue> = true;
static_assert(U::tvalue>); // fails on gcc10. clang10 compiles
successfully.
[Bug middle-end/94600] Ignored volatile specifier on loop unrolling and bitfield misoptimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600 --- Comment #2 from Hans-Peter Nilsson --- For various targets and gcc versions I've noticed this bug as far back as gcc-4.7.
[Bug middle-end/94600] Ignored volatile specifier on loop unrolling and bitfield misoptimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600 Hans-Peter Nilsson changed: What|Removed |Added Last reconfirmed||2020-04-14 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson --- Confirmed for arm-eabi at a615ea71bc8:dda9278f192:bb87d5cc77db1 and cris-elf at fa9a57ed91d:b46f6c8e2e8:a126a1577ffcbf.
[Bug middle-end/94600] New: Ignored volatile specifier on loop unrolling and bitfield misoptimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600 Bug ID: 94600 Summary: Ignored volatile specifier on loop unrolling and bitfield misoptimization Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: arm-eabi, cris-elf, aarch64-linux Created attachment 48275 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48275=edit test-case in need of decoration for the gcc test-suite. Compile e.g. at -O2 or -Os. Observe the unwieldy code in function foo compiled at -O2 or -Os for any of the listed targets (and likely many more, except curiously not x86_64 and i386). Compare this to the compiled bar; nice as expected. Note in particular the reads in the generated code from the LHS specified as volatile and which is only stored into in the source code. Note also the smaller-than-struct-sized stores. The latter may be target-dependent but the reads should not happen anywhere.
[Bug libstdc++/94562] C++20: std::shared_ptr{} <=> nullptr ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94562 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jonathan Wakely --- <=> for shared_ptr has now been implemented.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #9 from Steve Kargl --- On Tue, Apr 14, 2020 at 08:48:47PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #8 from dave.anglin at bell dot net --- > On 2020-04-14 2:12 p.m., sgk at troutmask dot apl.washington.edu wrote: > > #ifdef HAVE_GFC_REAL_16 > > #endif > This one. > > > > Is hppa64 claiming support for a REAL type that it actually > > doesn't support? > Support is a fuzzy word. There's enough support to build libquadmath. So, you have REAL(4), REAL(8), and REAL(16). Is REAL(16) a software implementaton of IEEE 128-bit floating point, which uses libquadmath? If yes, then this suggests the logic to select the suffix 'q' or 'l' needs tweaking as you should be getting, e.g., cosq() from libquadmath instead of cosl(). > > In any event, you can extend the kludge > > > > #if (__STDC_VERSION__ < 199901L) > > #define fmaf(a,b,c) ((a)*(b)+(c)) > > #define fma(a,b,c) ((a)*(b)+(c)) > > #define fmal(a,b,c) ((a)*(b)+(c)) > > #define cosl(a) cos((double)(a)) > > #define sinl(a) sin((double)(a)) > > #define tanl(a) tan((double)(a)) > > #define fabsl(a) ((a) < 0 ? -(a) : (a)) > > #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) > > #endif > I have something that builds now. Need to test. > > I think we need to use _POSIX_VERSION as __STDC_VERSION__ is set by cpp. Looking at trigd.c, one finds #ifdef GFC_REAL_16_IS_FLOAT128 /* libquadmath. */ #define SUFFIX(x) x ## q #else #define SUFFIX(x) x ## l #endif /* GFC_REAL_16_IS_FLOAT128 */ So, hppa64 has REAL(16), but it does not use __float128 or GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead of the above kludge you can do something like #ifndef HAVE_COSL #define cosl cosq /* Use libquadmath for hppa64. */ #endif HAVE_COSL, HAVE_SINL, HAVE_TANL are definitely available. I don't recall if fabsl and copysignl have similar macros.
[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554
--- Comment #3 from Daniel Krügler ---
(In reply to Melissa from comment #0)
> Clang errors on this case, so it's possible that my code is invalid: Is it
> legal to compare a function pointer against null in a constant-expression?
The example is ill-formed because the condition of 'if constexpr' is more
restricted than that of normal 'if': It expects "a contextually converted
constant expression of type bool" and [expr.const] p10 lists the allowed
conversions in this case. This list omits the boolean conversions
([conv.bool]).
But the example would become valid when rewritten as follows:
int meow() { return 1; }
void kitty(int);
template
void test() {
if constexpr (bool(F)) {
kitty(F());
} else {
kitty(2);
}
}
template void test();
template void test();
[Bug target/94587] Intrinsics optimization bug with -O2 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587 --- Comment #8 from Patrick J. LoPresti --- (In reply to Andrew Pinski from comment #6) > (In reply to Patrick J. LoPresti from comment #5) > > I did not use -ffp-contract=fast nor -funsafe-math-optimizations nor > > -ffast-math. Yet the statements were contracted. So the documentation has a > > bug. > > Not exactly because the defualt for -std=c11 is different from -std=gnu11 > (which is the default, or is the default -std=gnu17 well it depends on the > compiler version). Yes, I know. So the floating-point implementation chapter can only be understood if you also search the rest of the 1000-page documentation to learn what the defaults are. And then repeat for every release because "This is subject to change." (In reply to Jakub Jelinek from comment #7) > Note, clang defaults to -ffp-contract=on which is like =fast (except when > you use FP_CONTRACT pragma). No, it is not like "fast". At least, not according to my experience and this StackOverflow answer: https://stackoverflow.com/a/43357638 Note the link to the live example on gcc.godbolt.org.
[Bug ipa/69075] ICE when setting early-inlining-insns to other than default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075 --- Comment #8 from Charles --- It is not for me as I explained in Comment 6.
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #53 from Peter Cordes ---
I think we can close this as fixed at some point. The last activity on this
bug was some patches that sound like they were supposed to fix, and the MCVEs
from comments I tested no longer has a problem.
GCC9.3 -O3 -march=core2 -fomit-frame-pointer only uses a `.p2align` to align
the top of the loop, not between leave and ret or between cmp/jcc.
void wait_for_enter()
{
volatile int foo = 0; // to get a LEAVE instruction emitted at all
int u = getchar();
while (!u)
u = getchar()-13;
}
https://godbolt.org/z/RvxzZv
(Note that Godbolt normally filters .p2align so you have to either compile to
binary or not filter directives in the asm source. Otherwise you'll never see
NOPs except in the unusual case where GCC actually emits a nop mnemonic.)
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #19 from Jakub Jelinek --- Since Richard's change, assign_parm_data_one has the arg member with function_arg_info type, and that class has a user-provided default constructor. Perhaps for old GCC we could instead of *data = assign_parm_data_one (); do static assign_parm_data_one zeroed_arg; *data = zeroed_arg; or whatever else actually works. I'll try tomorrow to cook up a short testcase with the function_arg_info default ctor and assign_parm_data_one containing it and see what GCC 4.2 does with it.
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #18 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #17) > So, what exactly happens? Does GCC 4.2 e.g. fail to initialize all members > to zeros in the > - memset (data, 0, sizeof (*data)); > + *data = assign_parm_data_one (); > change? > Would it work to > memset (data, 0, sizeof (*data)); > data->arg = function_arg_info (); > for old GCC, or add for old GCC an explicit default constructor to > struct assign_parm_data_one, or > #if GCC_VERSION < 4300 > memset (data, 0, sizeof (*data)); > #endif > *data = assign_parm_data_one (); > ? > Most of the other changes seem to be just about using different member names > and thus shouldn't really matter much. hmm I don't see a CTOR specified for assign_parm_data_one. So I guess it's using an implicit default, which is perhaps trivial (assuming that the struct assign_parm_data_one is POD, which seems possible). Will poke at this when I have a spare machine supporting that bootstrap compiler.
[Bug libstdc++/94562] C++20: std::shared_ptr{} <=> nullptr ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94562 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f5fa62ed19a1c85cda920bbe05eb075d8f2a0b42 commit r10-7725-gf5fa62ed19a1c85cda920bbe05eb075d8f2a0b42 Author: Jonathan Wakely Date: Tue Apr 14 21:54:55 2020 +0100 libstdc++: Add comparison operators to std::shared_ptr (PR 94562) This also implements the proposed resolution to LWG issue 3247, so that the ill-formed <=> expression with nullptr is not used. PR libstdc++/94562 * include/bits/shared_ptr.h (operator<=>): Define for C++20. * include/bits/shared_ptr_base.h (operator<=>): Likewise. * include/bits/unique_ptr.h (operator<=>): Add inline specifier. * testsuite/20_util/shared_ptr/comparison/cmp_c++20.cc: New test. * testsuite/20_util/shared_ptr/comparison/less.cc: Do not expect std::less to be used when comparing std::shared_ptr objects in C++20.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #8 from dave.anglin at bell dot net --- On 2020-04-14 2:12 p.m., sgk at troutmask dot apl.washington.edu wrote: > #ifdef HAVE_GFC_REAL_16 > #endif This one. > > Is hppa64 claiming support for a REAL type that it actually > doesn't support? Support is a fuzzy word. There's enough support to build libquadmath. > > In any event, you can extend the kludge > > #if (__STDC_VERSION__ < 199901L) > #define fmaf(a,b,c) ((a)*(b)+(c)) > #define fma(a,b,c) ((a)*(b)+(c)) > #define fmal(a,b,c) ((a)*(b)+(c)) > #define cosl(a) cos((double)(a)) > #define sinl(a) sin((double)(a)) > #define tanl(a) tan((double)(a)) > #define fabsl(a) ((a) < 0 ? -(a) : (a)) > #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) > #endif I have something that builds now. Need to test. I think we need to use _POSIX_VERSION as __STDC_VERSION__ is set by cpp. Dave
[Bug target/94587] Intrinsics optimization bug with -O2 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587 --- Comment #7 from Jakub Jelinek --- Note, clang defaults to -ffp-contract=on which is like =fast (except when you use FP_CONTRACT pragma).
[Bug target/94587] Intrinsics optimization bug with -O2 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587 --- Comment #6 from Andrew Pinski --- (In reply to Patrick J. LoPresti from comment #5) > I did not use -ffp-contract=fast nor -funsafe-math-optimizations nor > -ffast-math. Yet the statements were contracted. So the documentation has a > bug. Not exactly because the defualt for -std=c11 is different from -std=gnu11 (which is the default, or is the default -std=gnu17 well it depends on the compiler version). Plus: https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Optimize-Options.html#index-ffp-contract
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #17 from Jakub Jelinek --- So, what exactly happens? Does GCC 4.2 e.g. fail to initialize all members to zeros in the - memset (data, 0, sizeof (*data)); + *data = assign_parm_data_one (); change? Would it work to memset (data, 0, sizeof (*data)); data->arg = function_arg_info (); for old GCC, or add for old GCC an explicit default constructor to struct assign_parm_data_one, or #if GCC_VERSION < 4300 memset (data, 0, sizeof (*data)); #endif *data = assign_parm_data_one (); ? Most of the other changes seem to be just about using different member names and thus shouldn't really matter much.
[Bug c++/94025] Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
In my opinion, this issue does not demonstrate a bug, but is based on an
incomplete analysis of what is going on here.
1) It is correct, that the lambda function call operator is non-const in this
case. The result is that the function call operator of the lambda expression
will *not* be called in the shown example.
2) We have here a lambda expression without any capture. This means that the
standard requires the existence of an *additional* conversion function to a
pointer to function ([expr.prim.lambda.closure] p7 quoted from N4849). And
[expr.prim.lambda.closure] p11 says:
"The conversion function [..] is public, constexpr, non-virtual, non-explicit,
const, and has a non-throwing exception specification (14.5)."
So effectively a second function call resolution is in affect here, selecting
the conversion function (which is a const member function as specified above)
to function pointer as the only viable candidate (If both were viable, the
conversion function would be less preferred) via the surrogate call function
([over.call.object]). That explains IMO why the code is well-formed.
If you would try to mimic that with a user-defined class type, it would look
similar to the following one:
struct Lambda
{
using f_t = void();
f_t operator(); // "mutable"
using fptr_t = f_t*;
operator fptr_t() const;
};
Note that I use here the very rarely used syntax to declare (but not define) a
member function using a typedef for a function type to show the involved
function types more precisely.
The example would become invalid once you introduce a capture, because in this
case there would be no conversion function anymore.
I'm surprised that the Visual Studio compiler (I tested 2019) rejects the
original example, this looks like a bug to me, especially since that compiler
also handles the call resolution for the above defined Lambda type correctly. I
plan to report an issue for that compiler.
[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #13 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a126a1577ffcbf62d97723b35d343bdff014bb40 commit r10-7724-ga126a1577ffcbf62d97723b35d343bdff014bb40 Author: Iain Sandoe Date: Tue Apr 14 20:37:12 2020 +0100 coroutines: Fix compile error with symmetric transfers [PR94359] For symmetric transfers to work with C++20 coroutines, it is currently necessary to tail call the callee coroutine from resume method of the caller coroutine. The current codegen marks these resume calls as "MUST_TAIL_CALL" to indicate that the tail call is required for correctness. Unfortunately, several targets have ABI constraints that prevent an indirect tail-call, which results in the PRs compile error. The change here tests the target sibcall hook for the resume expression and only marks it as requiring a tail call if that's supported. This doesn't fix the underlying problem; that really a solution is needed to allow the tail-calls (or equivalent) to take place - but that will be deferred until next stage 1. gcc/cp/ChangeLog: 2020-04-14 Iain Sandoe PR c++/94359 * coroutines.cc (build_actor_fn): Check that the target can support the resume tailcall before mandating it. gcc/testsuite/ChangeLog: 2020-04-14 Iain Sandoe PR c++/94359 * g++.dg/coroutines/torture/symmetric-transfer-00-basic.C: Expect a run fail for targets without arbitrary indirect tail-calls.
[Bug fortran/94048] ICE and other problems using rank intrinsic to set array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94048 --- Comment #2 from José Rui Faustino de Sousa --- Please ignore the last attachment I mixed up the bug report...
[Bug fortran/94022] Array slices of assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022 --- Comment #3 from José Rui Faustino de Sousa --- Created attachment 48274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48274=edit The cleaned-up version with pointer and bind(c) tests
[Bug fortran/94048] ICE and other problems using rank intrinsic to set array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94048 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 48273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48273=edit The cleaned-up version with pointer and bind(c) tests
[Bug target/94542] test gcc/testsuite/gcc.dg/tls/pr24428-2.c generates incorrect code on ppc64le with -mpcrel -mcpu=future -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94542 --- Comment #1 from CVS Commits --- The master branch has been updated by Aaron Sawdey : https://gcc.gnu.org/g:aba6453890ce1754b7d1c01a67612766690ff15e commit r10-7722-gaba6453890ce1754b7d1c01a67612766690ff15e Author: Aaron Sawdey Date: Tue Apr 14 14:38:47 2020 -0500 Fix for PR/94542, do not make TLS refs PC-relative For rs6000 target, it is not valid to make PC-relative references to TLS symbols. So addr_to_insn_form() needs to check if things are TLS before returning PC-rel forms. 2020-04-14 Aaron Sawdey PR target/94542 * config/rs6000/rs6000.c (address_to_insn_form): Do not attempt to use PC-relative addressing for TLS references.
[Bug fortran/94022] Array slices of assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022 --- Comment #2 from José Rui Faustino de Sousa --- Hi Thomas! The fix to this problem seems to be simple: diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index fdca9cc..9ad885b 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -6237,6 +6241,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, || gfc_expr_attr (e).allocatable) set_dtype_for_unallocated (, e); else if (e->expr_type == EXPR_VARIABLE + && e->ref + && e->ref->u.ar.type == AR_FULL && e->symtree->n.sym->attr.dummy && e->symtree->n.sym->as && e->symtree->n.sym->as->type == AS_ASSUMED_SIZE) If you look at the output of -fdump-tree-original of the example using pointers and bind(c) it becomes clear that setting the last dimension upper bound to -1 to mark the array as assumed-size is the problem. (That way to signal assumed-size arrays is also problematic) But that change breaks the OpenMP tests and I did not look into it any further at the time. Best regards, José Rui
[Bug target/94587] Intrinsics optimization bug with -O2 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587 --- Comment #5 from Patrick J. LoPresti --- (In reply to Andrew Pinski from comment #4) > > Note this is true even without using intrinsics really. You can get the > same behavior you are seeing with using standard C code. Yes, which is one reason I am using intrinsics: They provide deterministic behavior on literally every compiler at every optimization level by default. Except GCC when AVX512 is enabled, that is. > > > > Wouldn't fp-contract be more appropriate as part of "-ffast-math"? > > No. This has been discussed many times and decided no. A ridiculous but not surprising decision. > https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Floating-point-implementation. > html#Floating-point-implementation Well, that page is wrong. "Expressions are currently only contracted if -ffp-contract=fast, -funsafe-math-optimizations or -ffast-math are used." I did not use -ffp-contract=fast nor -funsafe-math-optimizations nor -ffast-math. Yet the statements were contracted. So the documentation has a bug. More to the point, it does not answer the question I asked, which is what options are required to get deterministic behavior from intrinsics. So I suppose I have to re-read that chapter on every release, then search the rest of the documentation to learn what the defaults are, to figure out whether and how you broke something further? OK thanks
[Bug c++/83138] ICE: Segfault expanding function parameter pack in subsequent sibling pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83138 Hubert Tong changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hubert Tong --- Seems fixed in some GCC 8.x release.
[Bug c++/94571] Error: Expected comma or semicolon, comma found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571 --- Comment #5 from Jakub Jelinek --- (In reply to Marek Polacek from comment #4) > I think that won't handle > > auto x(1), [e,f] = test2; > > where we should also say what clang says (or at least give inform()). That gives error: expected unqualified-id before ‘[’ token right now. It would be quite a different spot that would need to handle that, and the question is if we should do it whenever seeing just [ or if we should in that case e.g. try to parse tentatively the structured binding or at least part of it and only give that diagnostics if it looks like an otherwise valid structured binding.
[Bug c++/93207] [concepts] Variadic concepts refuse to compile when function definition is not inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #4 from Patrick Palka --- This seems to be already fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 93207, which changed state. Bug 93207 Summary: [concepts] Variadic concepts refuse to compile when function definition is not inline https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/93207] [concepts] Variadic concepts refuse to compile when function definition is not inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:52d4ed1d96d48e2ceafc89a8734e14de3d5de3fe commit r10-7721-g52d4ed1d96d48e2ceafc89a8734e14de3d5de3fe Author: Patrick Palka Date: Tue Apr 14 15:02:22 2020 -0400 c++: Add testcase for PR c++/93207 gcc/testsuite/ChangeLog: PR c++/93207 * g++.dg/concepts/variadic5.C: New test.
[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 Iain Sandoe changed: What|Removed |Added Component|target |c++ --- Comment #12 from Iain Sandoe --- reclassifying as a c++ issue.
[Bug c/94593] [OpenMP] c-c++-common/gomp/requires-1.c: Missing diagnostic, test-case issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94593 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-04-14 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 48272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48272=edit gcc10-pr94593.patch Untested fix.
[Bug c++/83138] ICE: Segfault expanding function parameter pack in subsequent sibling pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83138 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #2 from Arseny Solokha --- Is it still an issue?
[Bug target/94587] Intrinsics optimization bug with -O2 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED --- Comment #4 from Andrew Pinski --- (In reply to Patrick J. LoPresti from comment #3) > That works; thank you. However... > > I realize there is no formal spec for intrinsics. But when I use them, I > expect deterministic behavior by default. This has been true on every > compiler with every set of optimization and architecture flags I have ever > used (GCC before AVX, many versions of Clang, many versions of the Intel > compiler). > > Also, the "-DHEISENBUG" example shows that simply adding a side-effect-free > assert() changes the behavior. This seems... unfriendly... as a default. Note this is true even without using intrinsics really. You can get the same behavior you are seeing with using standard C code. > > Wouldn't fp-contract be more appropriate as part of "-ffast-math"? No. This has been discussed many times and decided no. > > To my knowledge, no other compiler behaves this way. Are there any other > options I need to ensure deterministic behavior for SSE intrinsics on GCC? > Will there be more in the future? I do apologize if I missed the answer in > the 1000-page GCC manual. https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Floating-point-implementation.html#Floating-point-implementation
[Bug ipa/69075] ICE when setting early-inlining-insns to other than default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075 --- Comment #7 from Arseny Solokha --- Is it still an issue? I cannot reproduce it from g++ 6.4 onwards.
[Bug c++/85278] [concepts] Garbled diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.0 Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 85278, which changed state. Bug 85278 Summary: [concepts] Garbled diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/85278] [concepts] Garbled diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:58a29af8ef14bfa2d595deed5144891bff821eff commit r10-7720-g58a29af8ef14bfa2d595deed5144891bff821eff Author: Patrick Palka Date: Tue Apr 14 14:22:31 2020 -0400 c++: "'decltype_type' not supported" in diagnostic [PR85278] This fixes a garbled concepts diagnostic by moving the handling of DECLTYPE_TYPE from pp_cxx_type_specifier_seq to cxx_pretty_printer::simple_type_specifier, a move which also seems to be more consistent with the language grammar. This patch also fixes pretty printing of rvalue reference types via cxx_pretty_printer::type_id, which eventually calls pp_c_pointer which currently doesn't distinguish between lvalue and rvalue references. gcc/c-family/ChangeLog: PR c++/85278 * c-pretty-print.c (pp_c_pointer) : Print a double ampersand if it's an rvalue reference type. gcc/cp/ChangeLog: PR c++/85278 * cxx-pretty-print.c (cxx_pretty_printer:simple_type_specifier) : Handle DECLTYPE_TYPE here instead of ... (pp_cxx_type_specifier_seq) : ... here. (cxx_pretty_printer::direct_abstract_declarator) : New no-op case. gcc/testsuite/ChangeLog: PR c++/85278 * g++.dg/concepts/diagnostic9.C: New test.
[Bug fortran/94599] New: Invalid constructor for derived types with recursive allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94599 Bug ID: 94599 Summary: Invalid constructor for derived types with recursive allocatable components Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Created attachment 48271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48271=edit A kludge to fix the problem module m type :: stack_t integer :: index type(stack_t), allocatable :: payload type(stack_t), allocatable :: next end type stack_t end module use m type (stack_t) :: start print *, allocated(start%payload), allocated(start%next) start = stack_t(index=42) ! Should provide NULL for both 'payload' and 'next' print *, allocated(start%payload), allocated(start%next) end should output F F F F but, instead, outputs F F F T The reason for this is apparent on compilation with the option -fdump-parse-tree. start = stack_t(index=42) generates ASSIGN MAIN__:start stack_t(42 , () , stack_t(() , NULL())) The appearance of the constructor for the 'next' component is wrong. It should be NULL(), since this is a missing component in the constructor. (F2018: 7.5.10 Construction of derived-type values) Note that 'payload' is correct. Any number of subsequent components of the parent type are incorrect. I cannot see, at present, what the problem is caused by. Evidently, somewhere, the default_initializer is applied. The attached is a kludge that fixes the problem and regtests OK but is incorrect. Paul
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #7 from Steve Kargl --- On Tue, Apr 14, 2020 at 05:24:51PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #6 from dave.anglin at bell dot net --- > On 2020-04-14 11:40 a.m., sgk at troutmask dot apl.washington.edu wrote: > > After '#include ' in trigd.c, add > > > > #if (__STDC_VERSION__ < 199901L) > > #define fmaf(a,b,c) ((a)*(b)+(c)) > > #define fma(a,b,c) ((a)*(b)+(c)) > > #define fmal(a,b,c) ((a)*(b)+(c)) > > #endif > > > Unfortunately, we also need copysignl, fabsl, cosl, sinl and tanl. > How are you getting to these? These are protected by #ifdef HAVE_GFC_REAL_10 #endif or #ifdef HAVE_GFC_REAL_16 #endif Is hppa64 claiming support for a REAL type that it actually doesn't support? In any event, you can extend the kludge #if (__STDC_VERSION__ < 199901L) #define fmaf(a,b,c) ((a)*(b)+(c)) #define fma(a,b,c) ((a)*(b)+(c)) #define fmal(a,b,c) ((a)*(b)+(c)) #define cosl(a) cos((double)(a)) #define sinl(a) sin((double)(a)) #define tanl(a) tan((double)(a)) #define fabsl(a) ((a) < 0 ? -(a) : (a)) #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) #endif
[Bug fortran/48655] "False positive" with -Warray-temporaries or missing warning with -fcheck=array-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48655 Nick changed: What|Removed |Added CC||nickpapior at gmail dot com --- Comment #9 from Nick --- I really think this needs fixing. A user (me) is unaware of the implications and differences between -Warray-temporaries and -fcheck=array-temps. E.g. from this discussion it seems that -Warray-temporaries only pin-points where there _could_ be problems of creating temporaries. -fcheck=array-temps will reveal true temporary copies created. However, I have found that our code (+100.000 LOC) can greatly benefit closing -Warray-temporaries even if -fcheck=array-temps did not show any temporaries created. Why is this? So some follow up questions to clarify the flags: 1) Is there any compiled code difference in places where -Warray-temporaries show up, e.g. can we assume that IFF -Warray-temporaries gives a warning it is equivalent to the compiler inserting something like: if (is_contiguous(A) ) then call with no temp else temp = A(...) call with_temp deallocate(temp) end if ? And if not, then there is nothing to worry about? 2) Can we be sure that -fcheck=array-temps actually shows all true positives related to temporary array creation? What I would really like is the following changes to the documentation: -Warray-temporaries: Warn about possible array temporaries generated by the compiler. The information generated by this warning is sometimes useful in optimization, in order to avoid such temporaries. If this warning is issued it is equivalent to extra code checking for contiguous arrays before determining whether a temporary is created. To assert a temporary array was created, use -fcheck=array-temps. If extra code is not generated when a warning is issued then the 2nd last line should be omitted. Additionally the Warning message should be clarified, currently it looks like: Warning: Creating array temporary at (1) [-Warray-temporaries] However, I think it should look like this: Warning: Creating array temporary at (1) if non-contiguous [-Warray-temporaries] Thanks!
[Bug tree-optimization/94598] New: ICE in verify_sra_access_forest, at tree-sra.c:2360 with -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
Bug ID: 94598
Summary: ICE in verify_sra_access_forest, at tree-sra.c:2360
with -O1 or higher
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: delia.burduv at arm dot com
Target Milestone: ---
$ cat test.c
struct a {
int b;
short c;
};
int d;
void e() {
struct a f[1];
f[d] = f[d];
}
$ ./aarch64-none-elf-gcc -O1 -c test.c
during GIMPLE pass: esra
test.c: In function 'e':
test.c:9:1: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2360
9 | }
| ^
0xea37a2 verify_sra_access_forest(access*)
/home/delbur01/gnu-work/src/gcc/gcc/tree-sra.c:2359
0xea609b verify_all_sra_access_forests()
/home/delbur01/gnu-work/src/gcc/gcc/tree-sra.c:2407
0xea9b7a analyze_all_variable_accesses
/home/delbur01/gnu-work/src/gcc/gcc/tree-sra.c:3448
0xeaaa44 perform_intra_sra
/home/delbur01/gnu-work/src/gcc/gcc/tree-sra.c:4502
0xeac2c2 early_intra_sra
/home/delbur01/gnu-work/src/gcc/gcc/tree-sra.c:4532
0xeac2c2 execute
/home/delbur01/gnu-work/src/gcc/gcc/tree-sra.c:4575
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/94597] New: ICE while using a concept checking for user defined conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94597
Bug ID: 94597
Summary: ICE while using a concept checking for user defined
conversion operator
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barolek at gmail dot com
Target Milestone: ---
Hello,
I found this ICE when playing with Godbolt compiler explorer. I don't have
access to system with installed GCC, I can't get preprocessed file (as in
instruction), I will give the source code, that caused the error.
Following snipped caused ICE on GCC, it compiles with Clang, I think (concepts
are new feature and I'm not expert) that this is a valid code which should
accept types with defined user defined conversion operator.
GCC INFO:
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20200414/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200413 (experimental) (Compiler-Explorer-Build)
COMPILER FLAGS: -std=c++2a
SOURCE CODE: (https://godbolt.org/z/33LD8M) (It compiles with clang trunk with
-stdlib=libc++ flag)
#include
template
concept has_user_defined_conversion = requires (From f)
{
f.operator To();
};
template
requires (has_user_defined_conversion)
bool equal(w const& x, w2 const& y)
{
return x == y;
}
template
struct wrapper
{
T f;
wrapper(T a) : f(a) {}
operator T() const
{
return f;
}
};
bool fun()
{
wrapper a(2.0f);
wrapper b(3.0f);
return equal(a, 3.0f);
}
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
PR 94454, ICE in template machinery
Richard, I think 94454 is a P1. We have an inconsistency between specialization hasher and equality. arguments may compare equal but hash differently. nathan -- Nathan Sidwell
[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 since r10-5567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621 --- Comment #18 from Martin Jambor --- I posted a patch to fix this for review to the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543659.html
[Bug fortran/93500] ICE in gfc_numeric_ts, at fortran/expr.c:891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93500 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Thomas Koenig --- Steve, I'll give your patch a spin and commit as obvious if it survives regression-testing.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #12 from Nathan Sidwell --- Created attachment 48270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48270=edit asserts to trigger it I have found the cause, but not the underlying reason. We have template arguments that compare equal but hash differently. So the earlier attempts to cause hash collisions by neutering the hasher, made the bug go away. This patch neuters the hasher, but adds an assert into the argyment comparator -- if the args compare equal, they better hash equal. This triggers on the testcase with a pair of template_id_exprs.
[Bug ipa/94434] [AArch64][SVE] ICE caused by incompatibility of SRA and svst3 builtin-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Jambor --- Fixed.
[Bug ipa/94434] [AArch64][SVE] ICE caused by incompatibility of SRA and svst3 builtin-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:9707b593f88041e74e5cf5640ec64fea13a0387c commit r10-7719-g9707b593f88041e74e5cf5640ec64fea13a0387c Author: Martin Jambor Date: Tue Apr 14 19:26:04 2020 +0200 ipa-sra: Fix treatment of internal functions (PR 94434) IPA-SRA can segfault when processing a call to an internal function because such calls do not have corresponding call graphs and should be treated like memory accesses anyway, which what the patch below does. The patch makes an attempt to differentiate between reads and writes, although for things passed by value it does not make any difference. It treats all arguments of functions denoted with internal_store_fn_p as written to, even though in practice only some are, but for IPA-SRA purposes, actions needed to be taken when processing a read are also always performed when analyzing a write, so the code is just slightly pessimistic. But not as pessimistic as bailing out on any internal call immediately. I have LTO bootstrapped and tested the patch on x86_64-linux and normally bootstrapped and tested it on aarch64-linux, although one which is not SVE capable. I would appreciate testing on such machine too - as well as a small testcase that would follow all relevant conventions in gcc.target/aarch64/sve. 2020-04-14 Martin Jambor PR ipa/94434 * ipa-sra.c: Include internal-fn.h. (enum isra_scan_context): Update comment. (scan_function): Treat calls to internal_functions like loads or stores.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #6 from dave.anglin at bell dot net --- On 2020-04-14 11:40 a.m., sgk at troutmask dot apl.washington.edu wrote: > After '#include ' in trigd.c, add > > #if (__STDC_VERSION__ < 199901L) > #define fmaf(a,b,c) ((a)*(b)+(c)) > #define fma(a,b,c) ((a)*(b)+(c)) > #define fmal(a,b,c) ((a)*(b)+(c)) > #endif > Unfortunately, we also need copysignl, fabsl, cosl, sinl and tanl.
[Bug fortran/93948] Surprising option processing of -fdec and -fdec-math in combination with -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- Hm, maybe a better thing to do would be just to issue a hard error when combining any of the -dec options with any -std= option.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 CC||pault at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Last reconfirmed||2020-04-14 Status|UNCONFIRMED |NEW --- Comment #2 from Thomas Koenig --- (In reply to martin from comment #0) > The following code (compiled without any options) prints "15000, 1" for > the second call to foo, instead of the expected "2, 1". The first > call to foo gives the expected result. This is also reproducible with > gfortran-10 branch. > > This code is a variation of the one reported in bug 93918 to further > understand temporary array creation. > > program array_temps > implicit none > > type :: tt >integer :: u = 1 >integer :: v = 2 > end type tt > > type(tt), dimension(:), pointer :: r > integer :: n > integer, dimension(:), pointer :: p > > allocate(r(1:n)) This test case does not define n. Assuming you want to write n=1 in there, I concur that the output should be as you describe. I assume that the span is not used correctly in the function. The test case works if you do p => r(:)%v instead of the call to get().
[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #11 from Christophe Lyon ---
(In reply to Wilco from comment #10)
>
> For example:
>
> int x;
> int f1 (void) { return x; }
>
> with eg. -O2 -mcpu=cortex-m0 -mpure-code I get:
>
> movsr3, #:upper8_15:#.LC1
> lslsr3, #8
> addsr3, #:upper0_7:#.LC1
> lslsr3, #8
> addsr3, #:lower8_15:#.LC1
> lslsr3, #8
> addsr3, #:lower0_7:#.LC1
> @ sp needed
> ldr r3, [r3]
> ldr r0, [r3, #40]
> bx lr
>
> That's an extra indirection through a literal... There should only be
> one ldr to read x.
Right, but the code is functional. I mentioned that problem when I submitted
the patch. I thought it was good to provide functionality and improve the
generated code later.
I wrote: "I haven't found yet how to make code for cortex-m0 apply upper/lower
relocations to "p" instead of .LC2. The current code looks functional, but
could be improved."
>
> Big switch tables are produced for any Thumb-1 core, however I would expect
> Cortex-m0/m23 versions to look almost identical to the Cortex-m3 one, and
> use a sequence of comparisons instead of tables.
>
> int f2 (int x, int y)
> {
> switch (x)
> {
> case 0: return y + 0;
> case 1: return y + 1;
> case 2: return y + 2;
> case 3: return y + 3;
> case 4: return y + 4;
> case 5: return y + 5;
> }
> return y;
> }
>
I believe this is expected: as I wrote in my commit message
"CASE_VECTOR_PC_RELATIVE is now false with -mpure-code, to avoid generating
invalid assembly code with differences from symbols from two different sections
(the difference cannot be computed by the assembler)."
Maybe there's a possibility to tune this to detect cases where we can do
better?
> Immediate generation for common cases seems to be screwed up:
>
> int f3 (void) { return 0x1100; }
>
> -O2 -mcpu=cortex-m0 -mpure-code:
>
> movsr0, #17
> lslsr0, r0, #8
> lslsr0, r0, #8
> lslsr0, r0, #8
> bx lr
This is not optimal, but functional, right?
> This also regressed Cortex-m23 which previously generated:
>
> movsr0, #136
> lslsr0, r0, #21
> bx lr
> Similar regressions happen with other immediates:
>
> int f3 (void) { return 0x12345678; }
>
> -O2 -mcpu=cortex-m23 -mpure-code:
>
> movsr0, #86
> lslsr0, r0, #8
> addsr0, r0, #120
> movtr0, 4660
> bx lr
>
> Previously it was:
>
> movwr0, #22136
> movtr0, 4660
> bx lr
OK, I'll check how to fix that.
> Also relocations with a small offset should be handled within the
> relocation. I'd expect this to never generate an extra addition, let alone
> an extra literal pool entry:
>
> int arr[10];
> int *f4 (void) { return [1]; }
>
> -O2 -mcpu=cortex-m3 -mpure-code generates the expected:
>
> movwr0, #:lower16:.LANCHOR0+4
> movtr0, #:upper16:.LANCHOR0+4
> bx lr
>
> -O2 -mcpu=cortex-m23 -mpure-code generates this:
>
> movwr0, #:lower16:.LANCHOR0
> movtr0, #:upper16:.LANCHOR0
> addsr0, r0, #4
> bx lr
For cortex-m23, I get the same code with and without -mpure-code.
>
> And cortex-m0 again inserts an extra literal load:
>
> movsr3, #:upper8_15:#.LC0
> lslsr3, #8
> addsr3, #:upper0_7:#.LC0
> lslsr3, #8
> addsr3, #:lower8_15:#.LC0
> lslsr3, #8
> addsr3, #:lower0_7:#.LC0
> ldr r0, [r3]
> addsr0, r0, #4
> bx lr
Yes, same problem as in f1()
So I think -mpure-code for v6m is not broken, but yes the generated code can be
improved. So this may not be relevant to this PR?
[Bug fortran/94022] Array slices of assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2020-04-14 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Thomas Koenig --- Can you simplify this somewhat, and not use assumed shape in your test case? This adds a complication that could well be the real bug, or hide a bug.
[Bug fortran/94110] Passing an assumed-size to an assumed-shape argument should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110 Thomas Koenig changed: What|Removed |Added Severity|normal |enhancement Summary|Erroneous code compiling|Passing an assumed-size to ||an assumed-shape argument ||should be rejected Keywords|accepts-invalid |diagnostic Status|WAITING |NEW --- Comment #3 from Thomas Koenig --- So, as far as I can see, not something that the compiler is required to diagnose. Confirming as an enhancement.
[Bug fortran/94270] [8/9 Regression] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Thomas Koenig --- Well, should be fixed now. Onto new shores...
[Bug fortran/94270] [8/9 Regression] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:5e67ee3aa084a54f59c0848c32c17faddbb04c4c commit r8-10179-g5e67ee3aa084a54f59c0848c32c17faddbb04c4c Author: Thomas König Date: Tue Apr 14 18:45:59 2020 +0200 Backport from trunk of the fix for PR 94270. 2020-04-14 Thomas Koenig Backport from trunk. PR fortran/94270 * trans-decl.c (generate_local_decl): Do not warn if the symbol is artifical. 2020-04-14 Thomas Koenig Backport from trunk PR fortran/94270 * gfortran.dg/warn_unused_dummy_argument_6.f90: New test.
[Bug c++/94592] ICE in non-type template parameter with constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592 --- Comment #6 from Paco Arjonilla --- Thanks for supporting this feature. I think it is one of the core features that modern C++ should have.
[Bug c++/94592] ICE in non-type template parameter with constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
--- Comment #5 from Marek Polacek ---
{} as a template argument is currently only supported by GCC as an extension,
but I raised this on the core C++ list and it seems that the the conclusion is
that we want this to work, though there's no CWG for it yet.
[Bug analyzer/94596] New: possible false positive when analyze OVS macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596
Bug ID: 94596
Summary: possible false positive when analyze OVS macro
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: u9012063 at gmail dot com
Target Milestone: ---
Hi,
Below is my system info:
$ uname -a
Linux osboxes 5.5.0-rc1+ #112 SMP Fri Feb 21 10:28:49 PST 2020 x86_64 x86_64
x86_64 GNU/L
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200405 (experimental) (GCC)
$ git clone https://github.com/openvswitch/ovs.git
$ cd ovs
$ ./boot.sh; ./configure; make CFLAGS+=-fanalyzer
A use-after-free warning is shown, but I think it's a false positive.
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I ./include -I ./include -I ./lib
-I ./lib -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith
-Wformat -Wformat-security -Wswitch-enum -Wunused-parameter -Wbad-function-cast
-Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes
-Wmissing-field-initializers -fno-strict-aliasing -Wswitch-bool
-Wlogical-not-parentheses -Wsizeof-array-argument -Wbool-compare
-Wshift-negative-value -Wduplicated-cond -Wshadow -Wmultistatement-macros
-Wcast-align=strict -fanalyzer -MT lib/conntrack.lo -MD -MP -MF
lib/.deps/conntrack.Tpo -c lib/conntrack.c -o lib/conntrack.o
In file included from lib/conntrack.h:25,
from lib/conntrack.c:26:
./include/openvswitch/hmap.h: In function ‘hmap_remove’:
./include/openvswitch/hmap.h:292:52: warning: use after ‘free’ of ‘node’
[]8;;https://cwe.mitre.org/data/definitions/416.htmlCWE-416]8;;]
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wanalyzer-use-after-free-Wanalyzer-use-after-free]8;;]
292 | struct hmap_node **bucket = >buckets[node->hash &
hmap->mask];
|^~
‘conntrack_destroy’: event 1
|
|lib/conntrack.c:486:1:
| 486 | conntrack_destroy(struct conntrack *ct)
| | ^
| | |
| | (1) entry to ‘conntrack_destroy’
|
‘conntrack_destroy’: event 2
|
|lib/cmap.h:222:5:
| 222 | ((CURSOR)->node \
| | ^
| | |
| | (2) following ‘false’ branch...
lib/cmap.h:253:10: note: in expansion of macro ‘CMAP_CURSOR_FOR_EACH__’
| 253 | CMAP_CURSOR_FOR_EACH__(NODE, _NAME, MEMBER);
\
| | ^~
lib/cmap.h:257:11: note: in expansion of macro ‘CMAP_FOR_EACH__’
| 257 | CMAP_FOR_EACH__(NODE, MEMBER, CMAP, \
| | ^~~
lib/conntrack.c:494:5: note: in expansion of macro ‘CMAP_FOR_EACH’
| 494 | CMAP_FOR_EACH (conn, cm_node, >conns) {
| | ^
|
‘conntrack_destroy’: event 3
|
|lib/cmap.h:222:5:
| 222 | ((CURSOR)->node \
| | ^
| | |
| | (3) ...to here
lib/cmap.h:253:10: note: in expansion of macro ‘CMAP_CURSOR_FOR_EACH__’
| 253 | CMAP_CURSOR_FOR_EACH__(NODE, _NAME, MEMBER);
\
| | ^~
lib/cmap.h:257:11: note: in expansion of macro ‘CMAP_FOR_EACH__’
| 257 | CMAP_FOR_EACH__(NODE, MEMBER, CMAP, \
| | ^~~
lib/conntrack.c:494:5: note: in expansion of macro ‘CMAP_FOR_EACH’
| 494 | CMAP_FOR_EACH (conn, cm_node, >conns) {
| | ^
|
‘conntrack_destroy’: event 4
|
|lib/cmap.h:252:5:
| 252 | for (struct cmap_cursor CURSOR_NAME = cmap_cursor_start(CMAP);
\
| | ^~~
| | |
| | (4) following ‘false’ branch...
lib/cmap.h:257:11: note: in expansion of macro ‘CMAP_FOR_EACH__’
| 257 | CMAP_FOR_EACH__(NODE, MEMBER, CMAP, \
| | ^~~
lib/conntrack.c:494:5: note: in expansion of macro ‘CMAP_FOR_EACH’
| 494 | CMAP_FOR_EACH (conn, cm_node, >conns) {
| | ^
|
‘conntrack_destroy’: event 5
|
| 497 | cmap_destroy(>conns);
| | ^~~~
| | |
| | (5) ...to here
|
‘conntrack_destroy’: event 6
|
|./include/openvswitch/hmap.h:218:31:
| 218 | INIT_CONTAINER(NODE, hmap_pop_helper__(HMAP, __),
MEMBER), \
./include/openvswitch/util.h:131:17: note: in definition of macro
‘OBJECT_CONTAINING’
| 131 | ((char *) (POINTER) - OBJECT_OFFSETOF(OBJECT, MEMBER)))
| | ^~~
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #5 from Steve Kargl --- On Tue, Apr 14, 2020 at 12:55:45PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #4 from dave.anglin at bell dot net --- > On 2020-04-13 11:02 p.m., kargl at gcc dot gnu.org wrote: > > Does math.h define fmaf? If yes, this this is bogus bug report. > > If no, please disable building gfortran on hppa64. > No, math.h does not define fmaf. > After '#include ' in trigd.c, add #if (__STDC_VERSION__ < 199901L) #define fmaf(a,b,c) ((a)*(b)+(c)) #define fma(a,b,c) ((a)*(b)+(c)) #define fmal(a,b,c) ((a)*(b)+(c)) #endif
[Bug fortran/94110] Erroneous code compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110 --- Comment #2 from José Rui Faustino de Sousa --- Hi Thomas! IIRC assumed-size arrays are implemented has packaged descriptor less arrays. In order to point to them or to pass them to a procedure expecting an assumed or deferred-shape array one has to create an array descriptor. To create such descriptor one must know the array bounds, which one does not for assumed-size arrays. Fortran pointers, unlike their C brethren, also carry bound information and AFAIK one can not have an array, or a pointer to an array, which has undefined bounds (what would the intrinsics like shape, ubound and size return?). So in order to point to, or pass, an assumed-size array to a procedure expecting an assumed or deferred-shape array the user must provide the missing bound information, which can be done by specifying an array section effectively creating an explicit-shape array (see PR94022). So if one has an assumed-size array “arr”, rank 3, and a procedure “sub”, with either an assumed or deferred-shape array dummy argument, one can do: a = arr(:,:,1:n) p => arr(:,:,1:n) call sub(arr(:,:,1:n)) Assuming appropriate declarations of both “a” and “p”. But one can not address the whole assumed-size array: a = arr ! already generates error p=> arr ! already generates error call sub(arr) ! The case here What IMHO might be relevant and that I could find in the standard: 8.5.8.3 Assumed-shape array (par 1): “An assumed-shape array is a nonallocatable nonpointer dummy argument array that takes its shape from its effective argument.” 8.5.8.5 Assumed-size array: C835: “An object whose array bounds are specified by an implied-shape-or-assumed-size-spec shall be a dummy data object or a named constant.” (par. 4): “An assumed-size array shall not appear in a context that requires its shape.” 9.5.2 Whole arrays (par. 2): “An assumed-size array (8.5.8.5) is permitted to appear as a whole array in an executable construct or specification expression only as an actual argument in a procedure reference that does not require the shape.” 10.1.2.2 Primary: C1002 (R1001) The designator shall not be a whole assumed-size array. 10.2.2.2 Syntax of the pointer assignment statement C1025: “The expr shall be a designator that designates a variable with either the TARGET or POINTER attribute and is not an array section with a vector subscript, or it shall be a reference to a function that returns a data pointer.” 15.5.2.4 Ordinary dummy variables (par. 16): “If a dummy argument is an assumed-shape array [...] the actual argument shall not be an assumed-size array.” 15.5.2.7 Pointer dummy variables (par. 2): “If the dummy argument does not have INTENT (IN) [...]. Otherwise, the actual argument shall be a pointer or a valid target for the dummy pointer in a pointer assignment statement. If the actual argument is not a pointer, the dummy pointer becomes pointer associated with the actual argument.” Should the compiler diagnose the error? Well it seems possible to do it and error reports are always better than surprising results... Is it required to? I would believe so... But I am interested on having the compiler hand hold me as much as possible... ;-) Best regards, José Rui
[Bug target/94587] Intrinsics optimization bug with -O2 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587 Patrick J. LoPresti changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from Patrick J. LoPresti --- That works; thank you. However... I realize there is no formal spec for intrinsics. But when I use them, I expect deterministic behavior by default. This has been true on every compiler with every set of optimization and architecture flags I have ever used (GCC before AVX, many versions of Clang, many versions of the Intel compiler). Also, the "-DHEISENBUG" example shows that simply adding a side-effect-free assert() changes the behavior. This seems... unfriendly... as a default. Wouldn't fp-contract be more appropriate as part of "-ffast-math"? To my knowledge, no other compiler behaves this way. Are there any other options I need to ensure deterministic behavior for SSE intrinsics on GCC? Will there be more in the future? I do apologize if I missed the answer in the 1000-page GCC manual.
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
--- Comment #8 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:b256222910cfa4a9b2b477dff8954e51fdc36bb9
commit r10-7718-gb256222910cfa4a9b2b477dff8954e51fdc36bb9
Author: Patrick Palka
Date: Wed Apr 8 13:14:42 2020 -0400
c++: Stray RESULT_DECLs in result of constexpr call [PR94034]
When evaluating the initializer of 'a' in the following example
struct A {
A() = default; A(const A&);
A *p = this;
};
constexpr A foo() { return {}; }
constexpr A a = foo();
the PLACEHOLDER_EXPR for 'this' in the aggregate initializer returned by
foo
gets resolved to the RESULT_DECL of foo. But due to guaranteed RVO, the
'this'
should really be resolved to ''.
Fixing this properly by immediately resolving 'this' and PLACEHOLDER_EXPRs
to
the ultimate object under construction would in general mean that we would
no
longer be able to cache constexpr calls for which RVO possibly applies,
because
the result of the call may now depend on the ultimate object under
construction.
So as a mostly correct stopgap solution that retains cachability of RVO'd
constexpr calls, this patch fixes this issue by rewriting all occurrences
of the
RESULT_DECL in the result of a constexpr function call with the current
object
under construction, after the call returns. This means the 'this' pointer
during construction of the temporary will still point to the temporary
object
instead of the ultimate object, but besides that this approach seems
functionally equivalent to the proper approach.
gcc/cp/ChangeLog:
PR c++/94034
* constexpr.c (replace_result_decl_data): New struct.
(replace_result_decl_data_r): New function.
(replace_result_decl): New function.
(cxx_eval_call_expression): Use it.
* tree.c (build_aggr_init_expr): Set the location of the
AGGR_INIT_EXPR
to that of its initializer.
gcc/testsuite/ChangeLog:
PR c++/94034
* g++.dg/cpp0x/constexpr-empty15.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi6a.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi6b.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi7a.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi7b.C: New test.
[Bug middle-end/94593] [OpenMP] c-c++-common/gomp/requires-1.c: Missing diagnostic, test-case issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94593 --- Comment #2 from Jakub Jelinek --- error: Only one unified_shared_memory clause can appear on a requires directive in a single translation unit is incorrect, dunno where they took it from. The same clause can't appear multiple times on the same directive and only one atomic_default_mem_order can appear in a TU etc., but nothing says you can't have #pragma omp requires unified_shared_memory #pragma omp requires unified_shared_memory #pragma omp requires unified_shared_memory #pragma omp requires unified_shared_memory #pragma omp requires unified_shared_memory Though, there is a restriction which we don't diagnose, namely that #pragma omp requires can only appear at file or namespace scope (in C/C++).
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 --- Comment #4 from Thomas Koenig --- Looks like span is not handled in reshape (at all). It will be interesting to see how other intrinsics such as maxloc and just about everything else handles this.
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||pault at gcc dot gnu.org Last reconfirmed||2020-04-14 --- Comment #3 from Thomas Koenig --- The span field is either not set correctly, or it is ignored during the RESHAPE. I'll look a little further...
[Bug middle-end/94593] [OpenMP] c-c++-common/gomp/requires-1.c: Missing diagnostic, test-case issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94593 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I'll fix up the testcase. gcc diagnoses the #pragma omp requries too, but only with -Wall or -Wunknown-pragmas (intentionally, because it wants to ignore unknown pragmas).
[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #10 from Wilco ---
(In reply to Christophe Lyon from comment #8)
> > Adding Christophe. I'm thinking the best approach right now is to revert
> > given -mpure-code doesn't work at all on Thumb-1 targets - it still emits
> > literal pools, switch tables etc. That's not pure code!
>
> Do you have testcases that show these failures?
>
> I did check some of the problematic testcases in the GCC testsuite when I
> committed that patch. Did I miss some of them?
>
> Can you point me to offending testcases and compiler options so that I can
> reproduce them?
For example:
int x;
int f1 (void) { return x; }
with eg. -O2 -mcpu=cortex-m0 -mpure-code I get:
movsr3, #:upper8_15:#.LC1
lslsr3, #8
addsr3, #:upper0_7:#.LC1
lslsr3, #8
addsr3, #:lower8_15:#.LC1
lslsr3, #8
addsr3, #:lower0_7:#.LC1
@ sp needed
ldr r3, [r3]
ldr r0, [r3, #40]
bx lr
That's an extra indirection through a literal... There should only be one ldr
to read x.
Big switch tables are produced for any Thumb-1 core, however I would expect
Cortex-m0/m23 versions to look almost identical to the Cortex-m3 one, and use a
sequence of comparisons instead of tables.
int f2 (int x, int y)
{
switch (x)
{
case 0: return y + 0;
case 1: return y + 1;
case 2: return y + 2;
case 3: return y + 3;
case 4: return y + 4;
case 5: return y + 5;
}
return y;
}
Immediate generation for common cases seems to be screwed up:
int f3 (void) { return 0x1100; }
-O2 -mcpu=cortex-m0 -mpure-code:
movsr0, #17
lslsr0, r0, #8
lslsr0, r0, #8
lslsr0, r0, #8
bx lr
This also regressed Cortex-m23 which previously generated:
movsr0, #136
lslsr0, r0, #21
bx lr
Similar regressions happen with other immediates:
int f3 (void) { return 0x12345678; }
-O2 -mcpu=cortex-m23 -mpure-code:
movsr0, #86
lslsr0, r0, #8
addsr0, r0, #120
movtr0, 4660
bx lr
Previously it was:
movwr0, #22136
movtr0, 4660
bx lr
Also relocations with a small offset should be handled within the relocation.
I'd expect this to never generate an extra addition, let alone an extra literal
pool entry:
int arr[10];
int *f4 (void) { return [1]; }
-O2 -mcpu=cortex-m3 -mpure-code generates the expected:
movwr0, #:lower16:.LANCHOR0+4
movtr0, #:upper16:.LANCHOR0+4
bx lr
-O2 -mcpu=cortex-m23 -mpure-code generates this:
movwr0, #:lower16:.LANCHOR0
movtr0, #:upper16:.LANCHOR0
addsr0, r0, #4
bx lr
And cortex-m0 again inserts an extra literal load:
movsr3, #:upper8_15:#.LC0
lslsr3, #8
addsr3, #:upper0_7:#.LC0
lslsr3, #8
addsr3, #:lower8_15:#.LC0
lslsr3, #8
addsr3, #:lower0_7:#.LC0
ldr r0, [r3]
addsr0, r0, #4
bx lr
[Bug target/93053] [9/10 Regression] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 Richard Biener changed: What|Removed |Added Target Milestone|10.0|9.4 Known to work||9.3.0 Known to fail||9.3.1 --- Comment #12 from Richard Biener --- This was now backported, retargeting as P1 on the branch. Please do not backport further until this issue is resolved.
[Bug fortran/94270] [8/9 Regression] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 --- Comment #7 from Thomas Koenig --- (In reply to Ignacio Fernández Galván from comment #6) > Will the fix be backported to gcc7? I noticed this when Ubuntu updated the > gcc7 version, so I would like to have the chance of seeing it fixed > eventually too. I'm afraid not, gcc 7 is no longer maintained. I will backport to gcc 8, so when the final release of gcc 8 occurs (in about a year), it will be included. Alternatively, Ubuntu might decide to package gcc 9 earlier than that.
[Bug c++/94592] ICE in non-type template parameter with constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-04-14 Ever confirmed|0 |1 Target Milestone|--- |10.0 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Started with r10-7096-gd417b4f5414d9076300ab41974a14424f722688c so mine.
[Bug c++/94571] Error: Expected comma or semicolon, comma found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571 --- Comment #4 from Marek Polacek --- I think that won't handle auto x(1), [e,f] = test2; where we should also say what clang says (or at least give inform()).
