[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- Moving to the non-traditional C preprocessor will cause havoc with the // operator in Fortran. c = 'a' // 'b' would then be turned into c = 'a', probably not intended :-)
[Bug c++/95242] [10/11 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #3 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #2)
> Another way to implement the __unspec constructor would be:
>
> consteval __unspec(int __n) { if (__n != 0) throw __n; }
>
> But I think I discussed this with Richard Smith in Prague and we realised
> there was a problem with it, but I might be misremembering.
Remember that we need to ensure that this __unspec constructor needs to be
noexcept (See bug 94565), so this function could only do a terminate-like
action.
[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252 --- Comment #2 from Kito Cheng --- Hi Jim: Not sure which way you will try first, maybe Monk or me can try to fix this by add bunch of pattern of gpr_save/gpr_restore to model set/use register correctly?
[Bug target/95355] New: [11 Regression] Assembler messages: Error: operand size mismatch for `vpmovzxbd' with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355 Bug ID: 95355 Summary: [11 Regression] Assembler messages: Error: operand size mismatch for `vpmovzxbd' with -masm=intel Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: assemble-failure Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 48614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48614=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -fno-tree-dominator-opts -fno-tree-fre -ftree-slp-vectorize -fno-tree-ter -mavx512dq -masm=intel testcase.c /tmp/cc4ZYLWX.s: Assembler messages: /tmp/cc4ZYLWX.s:27: Error: operand size mismatch for `vpmovzxbd' $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-648-20200526221715-gbc48456d085-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-648-20200526221715-gbc48456d085-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20200526 (experimental) (GCC) The offending instruction is: vpmovzxbd zmm0, QWORD PTR [rsp+32]
[Bug middle-end/95353] [10/11 Regression] GCC can't build binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW
[Bug c++/95354] GCC misuse "nonnull-attribute" option and can not detect it as UB as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- No, The place where nonnull attribute is not on the argument itself but rather on the function. See the document at: https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Common-Function-Attributes.html#index-nonnull-function-attribute THIS IS WHY GCC Is warning on that pointer and all.
[Bug c++/95354] New: GCC misuse "nonnull-attribute" option and can not detect it as UB as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
Bug ID: 95354
Summary: GCC misuse "nonnull-attribute" option and can not
detect it as UB as well
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This case test.cc
#include
#include
void has_nonnull_argument(__attribute__((nonnull)) int *p) {
;
}
int main () {
has_nonnull_argument(NULL);
std::cout << "ok" << std::endl;
return 0;
}
in GCC-trunk
$./g++ -fsanitize=undefined test.cc ; ./a.out
test.cc:3:57: warning: ‘nonnull’ attribute only applies to function types
[-Wattributes]
3 | void has_nonnull_argument(__attribute__((nonnull)) int *p) {
| ^
ok
$./g++ -fsanitize=nonull-attribute test.cc ; ./a.out
test.cc:3:57: warning: ‘nonnull’ attribute only applies to function types
[-Wattributes]
3 | void has_nonnull_argument(__attribute__((nonnull)) int *p) {
| ^
ok
in Clang-trunk
$clang++ -fsanitize=nonnull-attribute test.cc ; ./a.out
est.cc:7:30: warning: null passed to a callee that requires a non-null argument
[-Wnonnull]
has_nonnull_argument(NULL);
^
1 warning generated.
test.cc:7:26: runtime error: null pointer passed as argument 1, which is
declared to never be null
test.cc:3:42: note: nonnull attribute specified here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.cc:7:26 in
ok
According to the description in
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#Instrumentation-Options
for "-fsanitize=nonull-attribute", it says "This option enables instrumentation
of calls, checking whether null values are not passed to arguments marked as
requiring a non-null value by the nonnull function attribute."
I guess the warning message by GCC may also incorrect, the correct one should
look like in Clang produced.
I have tested them in recent GCC versions including GCC-8, GCC-9, and GCC-10,
they have the same symptom as well.
My GCC version is
$g++ --version
g++ (GCC) 11.0.0 20200526 (experimental)
Copyright (C) 2020 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.
[Bug gcov-profile/95332] gcov-tool merge："not a gcov data file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95332 --- Comment #3 from John Dong --- Created attachment 48613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48613=edit a patch for gcov-tool modified.
[Bug middle-end/95353] [10/11 Regression] GCC can't build binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353 --- Comment #2 from H.J. Lu --- Created attachment 48612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48612=edit a testcase $ gcc -O2 x.i -S /export/gnu/import/git/sources/binutils-gdb-release/gas/config/tc-csky.c: In function ‘md_convert_frag’: /export/gnu/import/git/sources/binutils-gdb-release/gas/config/tc-csky.c:4507:9: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 4507 | buf[1] = BYTE_1 (CSKYV1_INST_SUBI | (7 << 4)); | ~~~^~~ /export/gnu/import/git/sources/binutils-gdb-release/gas/config/tc-csky.c:4508:9: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 4508 | buf[2] = BYTE_0 (CSKYV1_INST_STW | (15 << 8));/* stw r15, r0. */ | ~~~^~~ /export/gnu/import/git/sources/binutils-gdb-release/gas/config/tc-csky.c:4509:9: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 4509 | buf[3] = BYTE_1 (CSKYV1_INST_STW | (15 << 8)); | ~~~^~~~ ...
[Bug middle-end/95353] [10/11 Regression] GCC can't build binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from Andrew Pinski --- Can you provide the full preprocessed source?
[Bug middle-end/95353] [10/11 Regression] GCC can't build binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-27 Ever confirmed|0 |1
[Bug middle-end/95353] New: [10/11 Regression] GCC can't build binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353
Bug ID: 95353
Summary: [10/11 Regression] GCC can't build binutils
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Assembler in binutils has
struct frag {
...
/* Data begins here. */
char fr_literal[1];
};
and fr_literal is accessed as
char *buf = fragp->fr_fix + fragp->fr_literal;
GCC 10 gave
gas/config/tc-csky.c: In function ‘md_convert_frag’:
gas/config/tc-csky.c:4507:9: error: writing 1 byte into a region of size 0
[-Wer
ror=stringop-overflow=]
4507 | buf[1] = BYTE_1 (CSKYV1_INST_SUBI | (7 << 4));
| ^
I checked in this:
char *buf = fragp->fr_fix + >fr_literal[0];
as a workaround. But it doesn't solve the problem in existing binutils
sources and some future version of gcc might see through the obfuscation
of the source, rendering this work-around ineffective. is there a solution
which is future proof?
[Bug gcov-profile/95332] gcov-tool merge："not a gcov data file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95332 --- Comment #2 from John Dong --- (In reply to Martin Liška from comment #1) > Hello. > > I support the patch, do you have a copyright agreement and can you send the > patch to the GCC patches mailing list? > > One small nit I noticed: > /home/marxin/Programming/gcc/gcc/../libgcc/libgcov-util.c: In function > ‘gcov_info* read_gcda_file(const char*)’: > /home/marxin/Programming/gcc/gcc/../libgcc/libgcov-util.c:264:12: warning: > unused variable ‘magic’ [-Wunused-variable] > 264 | unsigned magic, version; > |^ Hi, thank you for your reply, I will the patch to the GCC patches mailing list. thanks.
[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295
--- Comment #6 from Vsevolod Livinskiy ---
Thank you for such a quick fix!
Sorry about duplicates, I saw different assert messages and thought that they
were different bugs.
I still can see ICE in hoist_memory_references (bug 95283) on trunk. I've
attached the reproducer below.
Please let me know if it is a different bug, and I'll create another bug
report.
Error:
>$ g++ -c -O3 func.cpp
during GIMPLE pass: lim
func.cpp: In function ‘void test()’:
func.cpp:5:6: internal compiler error: in hoist_memory_references, at
tree-ssa-loop-im.c:2615
5 | void test() {
| ^~~~
0x82318c hoist_memory_references
gcc_src/gcc/tree-ssa-loop-im.c:2615
0x82318c store_motion_loop
gcc_src/gcc/tree-ssa-loop-im.c:2912
0x123853a do_store_motion
gcc_src/gcc/tree-ssa-loop-im.c:2937
0x123853a tree_ssa_lim
gcc_src/gcc/tree-ssa-loop-im.c:3156
0x123853a execute
gcc_src/gcc/tree-ssa-loop-im.c:3206
Reproducer:
extern short var_15, var_20;
extern int var_18, var_21, var_23;
extern bool arr_2[];
extern long arr_3[];
void test() {
var_20 = 1;
for (int a = 0; a < 12; a += 2)
for (short b = 0; b < 8; b += 2) {
arr_2[b] = var_21 = var_18 ? var_15 : 0;
arr_3[b] = 8569;
}
var_23 = -1096835496;
}
GCC version:
11.0.0 (adad99eb906164af7d2b398ad7e430aebe3adeb4)
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to José Rui Faustino de Sousa from comment #1)
> On further investigation the ICE is not generated by the extra parenthesis,
> but by the use of the lbound intrinsic.
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 280157)
+++ gcc/fortran/simplify.c (working copy)
@@ -4019,7 +4023,7 @@ simplify_bound_dim (gfc_expr *array, gfc_expr *kind, i
|| (coarray && d == as->rank + as->corank
&& (!upper || flag_coarray == GFC_FCOARRAY_SINGLE)))
{
- if (as->lower[d-1]->expr_type == EXPR_CONSTANT)
+ if (as->lower[d-1] && as->lower[d-1]->expr_type == EXPR_CONSTANT)
{
gfc_free_expr (result);
return gfc_copy_expr (as->lower[d-1]);
[Bug c++/95334] GCC detect missing signed-integer-overflow when add "const"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95334
--- Comment #2 from Haoxin Tu ---
I also find these cases
test1.cc
#include
bool g_bool = 0;
long g_long = -4075183478711827874L;
const long l_long = 7122990940771016367L;
int main () {
g_bool = g_long * l_long;
std::cout << g_bool << std::endl;
return 0;
}
GCC detects nothing.
$g++ -w -fsanitize=signed-integer-overflow test1.cc
1
But when remove "const"
test2.cc
#include
bool g_bool = 0;
long g_long = -4075183478711827874L;
const long l_long = 7122990940771016367L;
int main () {
g_bool = g_long * l_long;
std::cout << g_bool << std::endl;
return 0;
}
GCC can dectect the signed-integer-overflow.
$g++ -w -fsanitize=signed-integer-overflow test2.cc
test2.cc:7:21: runtime error: signed integer overflow: -4075183478711827874 *
7122990940771016367 cannot be represented in type 'long int'
1
[Bug c++/95344] [9/10/11 Regression] Wparentheses (assignment used as truth value) on parenthesized ternary conditional E2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95344 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #2 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546574.html
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 --- Comment #1 from José Rui Faustino de Sousa --- On further investigation the ICE is not generated by the extra parenthesis, but by the use of the lbound intrinsic.
[Bug fortran/95352] New: ICE on extra parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 Bug ID: 95352 Summary: ICE on extra parenthesis Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48611=edit Fortran code demonstrating problems. Hi All! An extra parenthesis generates an ICE with: GNU Fortran (GCC) 10.1.1 20200525 GNU Fortran (GCC) 11.0.0 20200525 (experimental) Thank you very much. Best regards, José Rui
[Bug c++/95242] [10/11 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #2 from Jonathan Wakely ---
Another way to implement the __unspec constructor would be:
consteval __unspec(int __n) { if (__n != 0) throw __n; }
But I think I discussed this with Richard Smith in Prague and we realised there
was a problem with it, but I might be misremembering.
[Bug c++/95344] [9/10/11 Regression] Wparentheses (assignment used as truth value) on parenthesized ternary conditional E2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95344 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.4 Keywords||diagnostic Summary|Wparentheses (assignment|[9/10/11 Regression] |used as truth value) on |Wparentheses (assignment |parenthesized ternary |used as truth value) on |conditional E2 |parenthesized ternary ||conditional E2
[Bug c++/95344] Wparentheses (assignment used as truth value) on parenthesized ternary conditional E2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95344 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/95351] Comparison with NAN optimizes incorrectly with -ffast-math disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351 --- Comment #2 from Marc Glisse --- It might not be the issue, but merge_truthop_with_opposite_arm has a suspicious HONOR_NANS (type) where type is bool: the result of the comparison instead of one of the arguments.
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit. Note that not all builtins can supported (or, at least, it would be a lot of extra work); see the commit message.
[Bug c++/95351] Comparison with NAN optimizes incorrectly with -ffast-math disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2020-05-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, this is transformed before the optimizations happen. Oh this works with the C front-end ...
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:bf40f0ba95037f235b007a55a7682646a0578b26 commit r11-647-gbf40f0ba95037f235b007a55a7682646a0578b26 Author: David Malcolm Date: Tue May 26 09:28:16 2020 -0400 jit: fix missing types for builtins [PR 95306] PR jit/95306 reports that attempts to use builtins __builtin_sadd_overflow" and "__builtin_memcpy" via gcc_jit_context_get_builtin_function lead to inscrutable error messages of the form: unimplemented primitive type for builtin: 42 and: unimplemented primitive type for builtin: 38 The root cause is that jit-builtins.c only implements a subset of the types defined via DEF_PRIMITIVE_TYPE in builtin-types.def. This patch: - implements enough types to enable the above two builtins to be referenced - documents gcc_jit_context_get_builtin_function, and notes the limitation that not all types are supported (supporting some of them would take a lot of extra work) - improves the error message for the unsupported cases - adds a testcase for __builtin_memcpy. This required jit_langhook_global_bindings_p to be implemented (otherwise the assertion there failed deep inside "expand" on the builtin) - adds test coverage for the above gcc/jit/ChangeLog: PR jit/95306 * docs/topics/functions.rst (gcc_jit_context_get_builtin_function): Document. * docs/_build/texinfo/libgccjit.texi: Regenerate. * dummy-frontend.c (jit_langhook_global_bindings_p): Remove gcc_unreachable. * jit-builtins.c (type_names): New array. (get_string_for_type_id): New function. (gcc::jit::builtins_manager::make_primitive_type): Show name of type in error messages. Update cases to reflect the order in builtin-types.def. Implement cases for BT_INT8, BT_INT16, BT_UINT8, BT_CONST_PTR, BT_VOLATILE_PTR, BT_INT_PTR, BT_FLOAT_PTR, BT_CONST_DOUBLE_PTR, BT_SIZE, BT_CONST_SIZE. gcc/testsuite/ChangeLog: PR jit/95306 * jit.dg/all-non-failing-tests.h: Add test-builtin-memcpy.c and test-pr95306-builtin-types.c. * jit.dg/test-builtin-memcpy.c: New test. * jit.dg/test-error-gcc_jit_context_get_builtin_function-unimplemented-type.c: New test. * jit.dg/test-pr95306-builtin-types.c: New test.
[Bug c++/95344] Wparentheses (assignment used as truth value) on parenthesized ternary conditional E2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95344 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-05-26 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Chagned in r267272.
[Bug c++/95158] [10/11 Regression] Templates + Diamond Inheritance + Final = Pure Virtual Function Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95158 Jason Merrill changed: What|Removed |Added Priority|P3 |P1
[Bug c++/95319] [10/11 Regression] Regression from gcc9.3 when inserting into a vector with an initializer list. Error: a GNU-style designated initializer for class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95319 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-05-26
[Bug c++/95158] [10/11 Regression] Templates + Diamond Inheritance + Final = Pure Virtual Function Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95158 Jason Merrill changed: What|Removed |Added CC||paolo.carlini at oracle dot com Status|ASSIGNED|NEW Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org Depends on||67184 --- Comment #1 from Jason Merrill --- Much like PR 90909, this was introduced by Paolo's patch for PR 67184 in r10-1665-g26f8363d85fd386430ddb612a2e70624715c2ac3 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184 [Bug 67184] Missed optimization with C++11 final specifier
[Bug c++/95158] [10/11 Regression] Templates + Diamond Inheritance + Final = Pure Virtual Function Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95158 Jason Merrill changed: What|Removed |Added Last reconfirmed||2020-05-26 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #18 from joe.harvell at netscout dot com --- Sorry for the chatter...but I noticed the link command line had the same .o/.a files multiple times (to satisfy order dependencies between them). When I removed the duplicates and enclosed them in -Wl,--start-group / -Wl,--end-group everything linked fine with bfd 2.34. Note that bfd >= 2.27 also works fine if not using LTO.
[Bug c++/95351] New: Comparison with NAN optimizes incorrectly with -ffast-math disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351
Bug ID: 95351
Summary: Comparison with NAN optimizes incorrectly with
-ffast-math disabled
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris.dahlberg at cytovale dot com
Target Milestone: ---
Created attachment 48610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48610=edit
nan_bug.ii: preprocessed output from --save-temps
The function
bool Foo(double possiblyNAN, double b, double c)
{
return (possiblyNAN <= 2.0) || ((possiblyNAN > 2.0) && (b > c));
}
is optimized incorrectly with -O1. It gets reduced to just '(b > c)', ignoring
the possibility that 'possiblyNAN' is NAN and both comparisons vs 2.0 are
false. -ffinite-math-only is off (both by default and explicitly, no
difference)
The command line I'm using is:
"g++ -Wall -Wextra -O -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -fno-finite-math-only nan_bug.cpp"
No warnings are output
Looking at the assembly, 'possiblyNAN' is never accessed at all
Tried this on these gcc versions and all have the same behavior:
- gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC)
- gcc version 8.4.0 (Ubuntu 8.4.0-1ubuntu1~18.04)
- gcc version 10.1.0 (Compiler-Explorer-Build)
- gcc version 11.0.0 20200525 (experimental) (Compiler-Explorer-Build)
[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] Segfault |Segfault on a legal WAIT|on a legal WAIT statement |statement | Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11. Backports pending.
[Bug libfortran/95104] [9/10/11 Regression] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 --- Comment #8 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:56f03cd12be26828788a27f6f3c250041a958e45 commit r11-646-g56f03cd12be26828788a27f6f3c250041a958e45 Author: Harald Anlauf Date: Tue May 26 23:29:52 2020 +0200 PR fortran/95104 - Segfault on a legal WAIT statement Referencing a unit in a WAIT statement that has not been opened before resulted in a NULL pointer dereference. Check for this condition. 2020-05-26 Harald Anlauf libgfortran/ PR libfortran/95104 * io/transfer.c (st_wait_async): Do not dereference NULL pointer. gcc/testsuite/ PR libfortran/95104 * gfortran.dg/pr95104.f90: New test. Co-Authored-By: Steven G. Kargl
[Bug c/95157] Missing -Wtautological-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95157 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-26 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Confirmed.
[Bug c++/95242] [10/11 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org, ||jwakely.gcc at gmail dot com Last reconfirmed||2020-05-26 --- Comment #1 from Jason Merrill --- Yes, in C++20 mode the < comparison uses operator<=> to produce a std::strong_ordering, and then compares that to literal 0 to produce a boolean value. The operator< has an rhs type of 'std::__cmp_cat::__unspec', which has a single constructor taking a pointer to itself, which is designed to only accept null pointer constants, but this causes problems with this warning.
[Bug c++/95350] New: [coroutines] coroutines with move-only by-value parameters attempt to copy parameter instead of move it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95350
Bug ID: 95350
Summary: [coroutines] coroutines with move-only by-value
parameters attempt to copy parameter instead of move
it
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lewissbaker.opensource at gmail dot com
Target Milestone: ---
The following code fails to compile under GCC 10.0 and GCC trunk.
Compile with -fcoroutines -std=c++2a
See https://godbolt.org/z/zB_RVC
This code compiles successfully under both Clang and MSVC coroutines
implementations.
-
#include
struct task {
struct promise_type {
task get_return_object();
void return_void();
void unhandled_exception();
std::suspend_always initial_suspend() noexcept;
std::suspend_always final_suspend() noexcept;
};
};
struct move_only {
move_only();
move_only(const move_only&) = delete;
move_only(move_only&) = delete;
move_only(move_only&&) = default;
};
task f(move_only x) {
co_return;
}
-
Fails with compile-error:
: In function 'task f(move_only)':
:30:1: error: use of deleted function 'move_only::move_only(const
move_only&)'
30 | }
| ^
:24:5: note: declared here
24 | move_only(move_only&) = delete;
| ^
When copying parameters into the coroutine frame which are passed by value
it should be initialising the parameter copy using an xvalue referring to the
original function parameter. Whereas it seems like GCC is attempting to
initialise the parameter-copy with an lvalue-reference to the original
parameter, which ends up calling the copy-constructor.
See http://eel.is/c++draft/dcl.fct.def.coroutine#13
> ... the copy is a variable of type cv T with automatic storage duration
> that is direct-initialized from an xvalue of type T referring to the
> parameter ...
[Bug c++/95307] Compiler accepts reinterpret_cast in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307
--- Comment #5 from Jakub Jelinek ---
I've tried:
--- gcc/cp/constexpr.c.jj 2020-05-25 10:06:59.886175941 +0200
+++ gcc/cp/constexpr.c 2020-05-26 22:02:23.661355854 +0200
@@ -6196,6 +6196,18 @@ cxx_eval_constant_expression (const cons
if (VOID_TYPE_P (type))
return void_node;
+ if (CONVERT_EXPR_CODE_P (TREE_CODE (t))
+ && ARITHMETIC_TYPE_P (type)
+ && INDIRECT_TYPE_P (TREE_TYPE (op)))
+ {
+ if (!ctx->quiet)
+ error ("conversion from pointer type %qT "
+"to arithmetic type %qT in a constant expression",
+TREE_TYPE (op), type);
+ *non_constant_p = true;
+ return t;
+ }
+
if (TREE_CODE (op) == PTRMEM_CST && !TYPE_PTRMEM_P (type))
op = cplus_expand_constant (op);
@@ -6797,19 +6809,6 @@ cxx_eval_outermost_constant_expr (tree t
non_constant_p = true;
}
- /* Technically we should check this for all subexpressions, but that
- runs into problems with our internal representation of pointer
- subtraction and the 5.19 rules are still in flux. */
- if (CONVERT_EXPR_CODE_P (TREE_CODE (r))
- && ARITHMETIC_TYPE_P (TREE_TYPE (r))
- && TREE_CODE (TREE_OPERAND (r, 0)) == ADDR_EXPR)
-{
- if (!allow_non_constant)
- error ("conversion from pointer type %qT "
- "to arithmetic type %qT in a constant expression",
- TREE_TYPE (TREE_OPERAND (r, 0)), TREE_TYPE (r));
- non_constant_p = true;
-}
if (!non_constant_p && overflow_p)
non_constant_p = true;
but will need to look through testsuite regressions and find out which tests
just need adjustments and if there isn't something really broken by that.
[Bug libfortran/95104] [9/10/11 Regression] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 --- Comment #7 from Steve Kargl --- On Tue, May 26, 2020 at 08:30:36PM +, anlauf at gcc dot gnu.org wrote: > > --- Comment #6 from anlauf at gcc dot gnu.org --- > Steve, do you want me to commit it for you, including backports? > I no longer commit, because I do not use git and have no day-job reason to learn it. As trunk advances from the last available svn revision, I'll simply stop submitting patches.
[Bug c++/95288] Poor error message with function-scope enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95288 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-26 Ever confirmed|0 |1 Keywords||diagnostic --- Comment #1 from Marek Polacek --- Confirmed.
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-05-26
CC||anlauf at gcc dot gnu.org
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Priority|P3 |P4
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
The fix is to provide a sufficiently large buffer:
diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index 7ecb6595f59..df4f2265c58 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -47,7 +47,8 @@ along with GCC; see the file COPYING3. If not see
const char *
gfc_get_string (const char *format, ...)
{
- char temp_name[128];
+ /* Provide sufficient space to hold "_F.caf_token__symbol_MOD_symbol". */
+ char temp_name[14 + GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
const char *str;
va_list ap;
tree ident;
[Bug c++/95307] Compiler accepts reinterpret_cast in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307 --- Comment #4 from Marek Polacek --- And related to bug 93955.
[Bug c++/95301] excessive error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95301 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-05-26 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/95349] New: Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 Bug ID: 95349 Summary: Using std::launder(p) produces unexpected behavior where (p) produces expected behavior Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andrew2085 at gmail dot com Target Milestone: --- Created attachment 48609 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48609=edit preprocessed ii file All of these f1/f2/f3 functions should do the same thing, essentially the same thing as std::start_lifetime_as. Since the return value of placement new is used, std::launder is not necessary here, but using it anyway produces unexpected behavior when it should do nothing at all. Every version of gcc and every system I've tried has produced the same result. Here's the original source for reference: https://godbolt.org/z/zdQsfV gcc version: 10.1.0 (All other versions tested produce same behavior) system: Arch Linux x86_64 compile command: g++ -save-temps -std=c++17 -O2 -fno-stack-protector -fstrict-aliasing main.cpp && ./a.out configure options: g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.1.0 (GCC)
[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:3bf5e7657b752cc2352778e8c20ac9cdddca4f93 commit r11-645-g3bf5e7657b752cc2352778e8c20ac9cdddca4f93 Author: Patrick Palka Date: Tue May 26 16:17:34 2020 -0400 libstdc++: Fix common_iterator::operator-> [PR95322] This patch fixes the definition of common_iterator::operator-> when the underlying iterator's operator* returns a non-reference. The first problem is that the class __detail::_Common_iter_proxy is used unqualified. Fixing that revealed another problem: the class's template friend declaration of common_iterator doesn't match up with the definition of common_iterator, because the friend declaration isn't constrained. If we try to make the friend declaration match up by adding constraints, we run into frontend bug PR93467. So we currently can't correctly express this friend relation between __detail::_Common_iter_proxy and common_iterator. As a workaround to this frontend bug, this patch moves the definition of _Common_iter_proxy into the class template of common_iterator so that we could instead express the friend relation via the injected-class-name. (This bug was found when attempting to use views::common to work around the compile failure with the testcase in PR95322.) libstdc++-v3/ChangeLog: PR libstdc++/95322 * include/bits/stl_iterator.h (__detail::_Common_iter_proxy): Remove and instead define it ... (common_iterator::_Proxy): ... here. (common_iterator::operator->): Use it. * testsuite/24_iterators/common_iterator/2.cc: New test. * testsuite/std/ranges/adaptors/95322.cc: New test.
[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Basically a dup of bug 95159, I think.
[Bug gcov-profile/95348] New: GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
Bug ID: 95348
Summary: GCC records zero functions and modules in the
profiling data file, ICC does NOT
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
when using GCC and ICC to build a big parallel application with profiling
feedback, the size of the profiling feedback data of GCC is over 20x times
larger than that of ICC.
As we studied, one of the major reason for this size difference is:
GCC records all functions and modules that execute 0 times, but ICC does NOT.
since I cannot expose the details of the real application that has the
profiling data size issue. I come up with a small testing case to show this
problem.
**testing case:
[]$ cat lib.h
void five (int);
void ten (int);
[]$ cat lib.c
#include
void five(int n) {
if (n > 5) {
printf("%d is greater than five\n", n);
} else {
printf("%d is not greater than five\n", n);
}
}
void ten(int n) {
if (n > 10) {
printf("%d is greater than ten\n", n);
} else {
printf("%d is not greater than ten\n", n);
}
}
[]$ cat ten.c
#include
#include "lib.h"
int main(int argc, char *argv[]) {
if (argc != 2) {
return 2;
}
int n = atoi(argv[1]);
ten(n);
return 0;
}
[]$ cat five.c
#include "lib.h"
void foo(int n) {
if (n > 0)
five(n);
return;
}
**ICC :
[]$ cat build_it_icc
#!/bin/bash
ICC=/ICC-install-dir/bin/icc
opt="-O0 "
opt_gen="-prof_gen"
opt_gen="$opt_gen -prof_dir ./icc_prof_dir"
tf1="five.c"
tf2="ten.c"
libf="lib.c"
rm *.o ten
rm -rf icc_prof_dir
mkdir icc_prof_dir
echo $ICC $opt $opt_gen -c $tf1 -o five.o
$ICC $opt $opt_gen -c $tf1 -o five.o
echo $ICC $opt $opt_gen -c $libf -o lib.o
$ICC $opt $opt_gen -c $libf -o lib.o
echo $ICC $opt $opt_gen -c $tf2 -o ten.o
$ICC $opt $opt_gen -c $tf2 -o ten.o
echo $ICC $opt $opt_gen ten.o five.o lib.o -o ten
$ICC $opt $opt_gen ten.o five.o lib.o -o ten
./ten 12
echo "Done"
[]$ sh build_it_icc
then we got the profiling data under
./icc_prof_dir/5ec6e83f_78751.dyn
using
/ICC-install-dir/bin/profmerge -dump 5ec6e83f_78751.dyn > data
we can see, only two functions, "main" in ten.c, and "ten" in lib.c have
records in this profiling data file.
**GCC: with latest upstream gcc11:
[]$ cat build_it_gcc
#!/bin/bash
GCC=/GCC-install-dir/bin/gcc
opt="-O0 "
opt="$opt -fno-inline"
opt_gen="-fprofile-generate"
opt_gen="$opt_gen -fprofile-dir=gcc_prof_dir/%p"
tf1="five.c"
tf2="ten.c"
libf="lib.c"
rm -rf gcc_prof_dir
echo $GCC $opt $opt_gen -c $libf
$GCC $opt $opt_gen -c $libf -o lib.o
echo $GCC $opt $opt_gen $tf1
$GCC $opt $opt_gen -c $tf1 -o five.o
echo $GCC $opt $opt_gen $tf2
$GCC $opt $opt_gen -c $tf2 -o ten.o
echo $GCC $opt $opt_gen ten.o five.o lib.o -o ten
$GCC $opt $opt_gen ten.o five.o lib.o -o ten
./ten 12
echo "Done"
[]$ build_it_gcc
then the profiling data are under
./gcc_prof_dir/16856
under ~/Bugs/profile/small_gcc/gcc_prof_dir/16856
[]$ ls -l
total 12
-rw-r--r-- 1 qinzhao qinzhao 100 May 26 19:18
#home#qinzhao#Bugs#profile#small_gcc#five.gcda
-rw-r--r-- 1 qinzhao qinzhao 184 May 26 19:18
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda
-rw-r--r-- 1 qinzhao qinzhao 100 May 26 19:18
#home#qinzhao#Bugs#profile#small_gcc#ten.gcda
[]$ /home/qinzhao/Install/latest/bin/gcov-dump *.gcda
#home#qinzhao#Bugs#profile#small_gcc#five.gcda:data:magic `gcda':version
`B10e'
#home#qinzhao#Bugs#profile#small_gcc#five.gcda:stamp 1375590637
#home#qinzhao#Bugs#profile#small_gcc#five.gcda: a100: 2:OBJECT_SUMMARY
runs=1, sum_max=1
#home#qinzhao#Bugs#profile#small_gcc#five.gcda: 0100: 3:FUNCTION
ident=1636255671, lineno_checksum=0x13fda123, cfg_checksum=0xc7b3f828
#home#qinzhao#Bugs#profile#small_gcc#five.gcda:01a1: 6:COUNTERS
arcs 3 counts
#home#qinzhao#Bugs#profile#small_gcc#five.gcda:01af: 2:COUNTERS
time_profiler 1 counts
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda:data:magic `gcda':version
`B10e'
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda:stamp 1375590591
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda: a100: 2:OBJECT_SUMMARY
runs=1, sum_max=1
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda: 0100: 3:FUNCTION
ident=1977925159, lineno_checksum=0x5bf41dc5, cfg_checksum=0xf9e50e8f
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda:01a1: 8:COUNTERS arcs
4 counts
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda:01af: 2:COUNTERS
time_profiler 1 counts
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda:
[Bug target/95347] New: rs6000 mcpu=future generating stfs instead of pstfs for pc-relative references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95347 Bug ID: 95347 Summary: rs6000 mcpu=future generating stfs instead of pstfs for pc-relative references Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: acsawdey at gcc dot gnu.org Target Milestone: --- Problem exists in r11-639. /home2/sawdey/work/gcc/mamboCI/build-mambo/gcc/xgcc -B/home2/sawdey/work/gcc/mamboCI/build-mambo/gcc/ /home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/testsuite/gcc.c-torture/execute/pr79354.c -mcpu=future -mpcrel -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O1 -w -lm -o ./pr79354.exe --save-temps ./pr79354.s: Assembler messages: ./pr79354.s:31: Error: missing operand The relevant piece of the asm output: xscvuxdsp 0,32 pstfs 0,.LANCHOR0+16@pcrel stfs 0,.LANCHOR0+20@pcrel lwa 10,0(3) pstw 10,.LANCHOR0+20@pcrel The extended mnemonic "pstfs Fx,value" is equivalent to "pstfs Fx,value(0),1" and is only valid for pstfs not stfs.
[Bug libfortran/95104] [9/10/11 Regression] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #6 from anlauf at gcc dot gnu.org ---
Steve, do you want me to commit it for you, including backports?
Testcase:
! { dg-do run }
! PR libfortran/95104 - Segfault on a legal WAIT statement
program test
wait (10, iostat=ios)
if (ios /= 0) stop 1
close (10)
end program test
[Bug c++/95346] New: [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95346
Bug ID: 95346
Summary: [coroutines] coroutine return-type should be
initialised with rvalue if different from
get_return_object() return-type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lewissbaker.opensource at gmail dot com
Target Milestone: ---
If I have the following code:
--
#include
struct task {
struct promise_type {
task get_return_object();
void return_void();
void unhandled_exception();
std::suspend_always initial_suspend() noexcept;
std::suspend_always final_suspend() noexcept;
};
};
struct wrapper {
using promise_type = task::promise_type;
wrapper(task&&);
};
wrapper f() {
co_return;
}
--
Then building with GCC 10.0 and GCC trunk with -std=c++20 -fcoroutines fails
with the following compile-error:
x86-64 gcc (trunk)
-O3 -std=c++2a -Wall -fcoroutines
1
x86-64 gcc (trunk) - 368ms
: In function 'wrapper f()':
error: cannot bind rvalue reference of type 'task&&' to lvalue of type 'task'
30 | }
| ^
note: initializing argument 1 of 'wrapper::wrapper(task&&)'
25 | wrapper(task&&);
I think the return-value of a coroutine should be initialised with an
rvalue-reference to the object returned from get_return_object() if the
two objects have different types. GCC seems to be trying to initialise
the return-value using an lvalue-reference to the object returned from
get_return_object().
Both Clang and MSVC accept this code, while GCC does not.
See https://godbolt.org/z/4RRtaL
[Bug c++/68628] [concepts] ICE: segmentation fault in crash_signal, toplev.c:334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68628 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Invalid code that no longer ICEs, so let's close this.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 68628, which changed state. Bug 68628 Summary: [concepts] ICE: segmentation fault in crash_signal, toplev.c:334 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68628 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/95345] New: Fold expressions don't work properly when pack expression has co_await
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95345
Bug ID: 95345
Summary: Fold expressions don't work properly when pack
expression has co_await
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kacper.slominski72 at gmail dot com
Target Milestone: ---
When compiling the following code with GCC 10.1.0 (and the trunk option on
Compiler Explorer but I don't know what commit that is) and these flags:
"-std=c++2a -fcoroutines -Wall -Wextra"
#include
struct dummy_coro {
using promise_type = dummy_coro;
bool await_ready() { return false; }
void await_suspend(std::coroutine_handle<>) { }
void await_resume() { }
dummy_coro get_return_object() { return {}; }
dummy_coro initial_suspend() { return {}; }
dummy_coro final_suspend() { return {}; }
void return_void() { }
void unhandled_exception() { }
};
template
dummy_coro foo() {
((co_await [](int){ return std::suspend_never{}; }(I)), ...);
co_return;
}
void bar() {
foo<1>();
}
The compiler reports the following error:
: In function 'dummy_coro foo()':
:17:52: error: parameter packs not expanded with '...':
17 | ((co_await [](int){ return std::suspend_never{}; }(I)), ...);
| ~~~^~~
:17:52: note: 'I'
:17:58: error: operand of fold expression has no unexpanded parameter
packs
17 | ((co_await [](int){ return std::suspend_never{}; }(I)), ...);
| ^~~
The same code compiles without any issues with Clang 10.
Note that switching the order of the pack expression and ..., the error becomes
only:
: In function 'dummy_coro foo()':
:17:57: error: parameter packs not expanded with '...':
17 | (..., (co_await [](int){ return std::suspend_never{}; }(I)));
| ~~~^~~
:17:57: note: 'I'
Also note that the dummy_coro type doesn't matter and is only shown for
completeness, and that the return type of the lambda in the pack expression
(which can also be a function call) also doesn't matter.
[Bug target/95336] Bad code gen omnetpp_r aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336 --- Comment #7 from Erick Ochoa --- I have ran revision 4945b4c2c8628bdd61b348ea5bd1f9b72537a36e with -O3 but all -O2 and -O3 optimizations disabled except > -finline-functions [enabled] > -finline-small-functions[enabled] And the bug was triggered. (In reply to Martin Jambor from comment #6) > Can you please try the previous revision (6889a3acfee) but with option > -fno-ipa-sra ? If it fails, it means that the previous implementation > of IPA-SRA hid some other error (we have already had an aliasing bug > like that) - in that case it would be great if you could bisect again, > this time with this option. I ran revision 6889a3acfee * (with) -fno-ipa-sra:fails * (without) -fno-ipa-sra: fails This was weird to me because the bisection should show that without -fno-ipa-sra it should succeed. But then I used the same flags I used during bisection which included fprofile-generate... * (with) -fno-ipa-sra -fprofile-generate: fails * (with) -fprofile-generate: succeeds Maybe using -fprofile-generate to bisect was not the correct decision? The bug may have hidden due to the indirection provided by the profiling functions. But at least there's evidence of different behaviour. So: yes, I'll bisect again with minimal flags to trigger the error and let's see what happens.
[Bug c++/68395] [concepts] segfault in valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68395 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- I still see 68395.ii:96:11: error: ‘cpt_MappableElement’ does not constrain a type with -std=gnu++17 -fconcepts but with -std=gnu++20 I see another error too, so it's unclear to me if we should try to fix this one.
[Bug libfortran/95104] [9/10/11 Regression] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Summary|Segfault on a legal WAIT|[9/10/11 Regression] |statement |Segfault on a legal WAIT ||statement Target Milestone|--- |9.4 Component|fortran |libfortran --- Comment #5 from anlauf at gcc dot gnu.org --- So a 9/10/11 regression.
[Bug c++/68395] [concepts] segfault in valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68395 --- Comment #3 from Marek Polacek --- *** Bug 68394 has been marked as a duplicate of this bug. ***
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 68394, which changed state. Bug 68394 Summary: [concepts] segfault in valid code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68394 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/68394] [concepts] segfault in valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68394 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Dup. *** This bug has been marked as a duplicate of bug 68395 ***
[Bug c/12245] [8/9/10/11 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 Trass3r changed: What|Removed |Added CC||trass3r at gmail dot com --- Comment #77 from Trass3r --- This kind of code is also heavily used by Qt's resource system so any compile time improvements are welcome.
[Bug libfortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95195 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11. Thanks for the report!
[Bug c++/95344] New: Wparentheses (assignment used as truth value) on parenthesized ternary conditional E2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95344
Bug ID: 95344
Summary: Wparentheses (assignment used as truth value) on
parenthesized ternary conditional E2
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
void f(int i) {
bool b = false;
if (i == 99 ? (b = true) : false)
;
}
warning: suggest parentheses around assignment used as truth value
[-Wparentheses]
3 | if (i == 99 ? (b = true) : false)
| ~~~^~~
Per Godbolt, issue exists from 9.1 through current trunk (11.0).
[Bug libfortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95195 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8d8a25b0a7c3400c724e04e1d775d9f377216c04 commit r11-644-g8d8a25b0a7c3400c724e04e1d775d9f377216c04 Author: Harald Anlauf Date: Tue May 26 21:21:19 2020 +0200 PR libfortran/95195 - improve runtime error for namelist i/o to unformatted file Namelist input/output to unformatted files is prohibited. Generate useful runtime errors instead instead of misleading ones. 2020-05-26 Harald Anlauf libgfortran/ PR fortran/95195 * io/transfer.c (finalize_transfer): Generate runtime error for namelist input/output to unformatted file. gcc/testsuite/ PR fortran/95195 * gfortran.dg/namelist_97.f90: New test.
[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95089 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11. Thanks for the report!
[Bug bootstrap/95333] [11 Regression] error: number of counters in profile data for function ‘exp_attr__find_stream_subprogram’ does not match its profile data since r11-200-gdb4062a0cbe00ce4075a4d7f6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95333 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Eric Botcazou --- Presumably.
[Bug bootstrap/95333] [11 Regression] error: number of counters in profile data for function ‘exp_attr__find_stream_subprogram’ does not match its profile data since r11-200-gdb4062a0cbe00ce4075a4d7f6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95333 --- Comment #1 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:73655feb9d44829ce2153f4f5eacc37a6268ce73 commit r11-643-g73655feb9d44829ce2153f4f5eacc37a6268ce73 Author: Eric Botcazou Date: Tue May 26 21:21:08 2020 +0200 Fix issue with LTO bootstrap gcc/ada/ChangeLog PR ada/95333 * gcc-interface/decl.c (gnat_to_gnu_param): Never make a variant of the type.
[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95089 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:48d526613961f410a87855ba2fef8909e925d9fa commit r11-642-g48d526613961f410a87855ba2fef8909e925d9fa Author: Harald Anlauf Date: Tue May 26 21:19:19 2020 +0200 PR fortran/95089 - ICE in gfc_get_derived_type, at fortran/trans-types.c:2843 For long module name, derive type and component name, the generated name-mangled symbol did not fit into a buffer when coarrays were enabled. Provide sufficiently large temporary. 2020-05-26 Harald Anlauf gcc/fortran/ PR fortran/95089 * trans-types.c (gfc_get_derived_type): Enlarge temporary to hold mangled name "_caf_symbol". gcc/testsuite/ PR fortran/95089 * gfortran.dg/pr95089.f90: New test.
[Bug c++/93467] [concepts] getting "type constraint differs in template redeclaration" error after friend declaration in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93467
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Known to fail||10.0, 11.0
Last reconfirmed|2020-01-28 00:00:00 |2020-5-26
--- Comment #1 from Patrick Palka ---
Reconfirmed on trunk. I ran into this when writing a fix for PR
libstdc++/95322..
Here is another valid testcase which we reject:
template requires B
class C;
template
class S
{
template requires B
friend class ::C;
};
testcase.C:8:20: error: ‘C’ does not match original declaration
8 | friend class ::C;
|^
testcase.C:2:9: note: original template declaration here
2 | class C;
| ^
[Bug debug/95343] IPA-SRA can result in wrong debug info about removed function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95343 --- Comment #2 from Martin Jambor --- (In reply to Martin Jambor from comment #1) > ...I am testing a patch which can make gdb actually show > the correct 4. I meant the correct value 2, of course.
[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> (In reply to G. Steinmetz from comment #1)
> > Related :
> >
> >
> > $ cat z2.f90
> > module m
> >interface
> > module function f()
> > end
> >end interface
> >interface
> > function f() bind(c)
> > end
> >end interface
> > end
> >
> >
> > $ gfortran-11-20200524 -c z2.f90
> > f951: internal compiler error: Segmentation fault
> > 0xbc0f6f crash_signal
> > ../../gcc/toplev.c:328
> > 0x643eeb gfc_match_function_decl()
> > ../../gcc/fortran/decl.c:7398
> > 0x6a82ca decode_statement
> > ../../gcc/fortran/parse.c:343
> > 0x6a9e1a next_free
> > ../../gcc/fortran/parse.c:1279
> > 0x6a9e1a next_statement
> > ../../gcc/fortran/parse.c:1511
> > 0x6aba5c parse_interface
> > ../../gcc/fortran/parse.c:3519
> > 0x6aba5c parse_spec
> > ../../gcc/fortran/parse.c:3875
> > 0x6af43e parse_module
> > ../../gcc/fortran/parse.c:6115
> > 0x6af787 gfc_parse_file()
> > ../../gcc/fortran/parse.c:6428
> > 0x6fb9af gfc_be_parse_file
> > ../../gcc/fortran/f95-lang.c:210
>
> Index: gcc/fortran/decl.c
> ===
> --- gcc/fortran/decl.c(revision 280157)
> +++ gcc/fortran/decl.c(working copy)
> @@ -7325,7 +7325,8 @@ gfc_match_function_decl (void)
> procedure interface body. */
> if (sym->attr.is_bind_c && sym->attr.module_procedure && sym->old_symbol
> && strcmp (sym->name, sym->old_symbol->name) == 0
> - && strcmp (sym->binding_label, sym->old_symbol->binding_label) != 0)
> + && (!sym->old_symbol->binding_label
> + || strcmp (sym->binding_label, sym->old_symbol->binding_label) !=
> 0))
>{
> const char *null = "NULL", *s1, *s2;
> s1 = sym->binding_label;
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -7325,7 +7325,8 @@ gfc_match_function_decl (void)
procedure interface body. */
if (sym->attr.is_bind_c && sym->attr.module_procedure && sym->old_symbol
&& strcmp (sym->name, sym->old_symbol->name) == 0
- && strcmp (sym->binding_label, sym->old_symbol->binding_label) != 0)
+ && (!sym->old_symbol->binding_label
+ || strcmp (sym->binding_label, sym->old_symbol->binding_label) !=
0))
{
const char *null = "NULL", *s1, *s2;
s1 = sym->binding_label;
@@ -7840,7 +7841,8 @@ gfc_match_subroutine (void)
procedure interface body. */
if (sym->attr.module_procedure && sym->old_symbol
&& strcmp (sym->name, sym->old_symbol->name) == 0
- && strcmp (sym->binding_label, sym->old_symbol->binding_label) != 0)
+ && (!sym->old_symbol->binding_label
+ || strcmp (sym->binding_label, sym->old_symbol->binding_label) !=
0))
{
const char *null = "NULL", *s1, *s2;
s1 = sym->binding_label;
[Bug debug/95343] IPA-SRA can result in wrong debug info about removed function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95343
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
Summary|IPA-SRA can result in bad |IPA-SRA can result in wrong
|debug info about removed|debug info about removed
|function arguments |function arguments
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-05-26
Ever confirmed|0 |1
--- Comment #1 from Martin Jambor ---
The simplest fix which will make i reported as "optimized out" is the
following. But I am testing a patch which can make gdb actually show
the correct 4. Still, the following is usable for gcc 10 if the full
patch is deemed too risky:
diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
index 978916057f0..2a04f7b3ce5 100644
--- a/gcc/ipa-param-manipulation.c
+++ b/gcc/ipa-param-manipulation.c
@@ -787,7 +787,12 @@ ipa_param_adjustments::modify_call (gcall *stmt,
if (!is_gimple_reg (old_parm) || kept[i])
continue;
tree origin = DECL_ORIGIN (old_parm);
- tree arg = gimple_call_arg (stmt, i);
+ int index;
+ if (transitive_remapping)
+ index = index_map[i];
+ else
+ index = i;
+ tree arg = gimple_call_arg (stmt, index);
if (!useless_type_conversion_p (TREE_TYPE (origin), TREE_TYPE (arg)))
{
[Bug debug/95343] New: IPA-SRA can result in bad debug info about removed function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95343 Bug ID: 95343 Summary: IPA-SRA can result in bad debug info about removed function arguments Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux Target: x86_64-linux Created attachment 48608 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48608=edit Testcase ipa_param_adjustments::modify_call does not properly account for extra arguments left over from clone materialization when recording debug info. Therefore, when the attached testcase is compiled with -O2 or higher and run in gdb with a breakpoint is set at line 20 where we examine the value of parameter i, it incorrectly reports 4, even though it should be 2.
[Bug target/95336] Bad code gen omnetpp_r aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336 --- Comment #6 from Martin Jambor --- (In reply to Erick Ochoa from comment #0) [...] > I did a bisection from > > commit f47f687a97260b1a1305cbf2d7ee3d74b2916a74 > Author: Richard Biener > Date: Thu Apr 25 17:58:56 2019 + > > to: > > commit 4945b4c2c8628bdd61b348ea5bd1f9b72537a36e (HEAD) > Author: Martin Liska > Date: Tue May 26 09:01:41 2020 +0200 > > and I found that the following commit may have introduced the error: > > commit ff6686d2e5f797d6c6a36ad14a7084bc1dc350e4 > Author: Martin Jambor > Date: Fri Sep 20 00:25:04 2019 +0200 > Can you please try the previous revision (6889a3acfee) but with option -fno-ipa-sra ? If it fails, it means that the previous implementation of IPA-SRA hid some other error (we have already had an aliasing bug like that) - in that case it would be great if you could bisect again, this time with this option.
[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)
> Related :
>
>
> $ cat z2.f90
> module m
>interface
> module function f()
> end
>end interface
>interface
> function f() bind(c)
> end
>end interface
> end
>
>
> $ gfortran-11-20200524 -c z2.f90
> f951: internal compiler error: Segmentation fault
> 0xbc0f6f crash_signal
> ../../gcc/toplev.c:328
> 0x643eeb gfc_match_function_decl()
> ../../gcc/fortran/decl.c:7398
> 0x6a82ca decode_statement
> ../../gcc/fortran/parse.c:343
> 0x6a9e1a next_free
> ../../gcc/fortran/parse.c:1279
> 0x6a9e1a next_statement
> ../../gcc/fortran/parse.c:1511
> 0x6aba5c parse_interface
> ../../gcc/fortran/parse.c:3519
> 0x6aba5c parse_spec
> ../../gcc/fortran/parse.c:3875
> 0x6af43e parse_module
> ../../gcc/fortran/parse.c:6115
> 0x6af787 gfc_parse_file()
> ../../gcc/fortran/parse.c:6428
> 0x6fb9af gfc_be_parse_file
> ../../gcc/fortran/f95-lang.c:210
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -7325,7 +7325,8 @@ gfc_match_function_decl (void)
procedure interface body. */
if (sym->attr.is_bind_c && sym->attr.module_procedure && sym->old_symbol
&& strcmp (sym->name, sym->old_symbol->name) == 0
- && strcmp (sym->binding_label, sym->old_symbol->binding_label) != 0)
+ && (!sym->old_symbol->binding_label
+ || strcmp (sym->binding_label, sym->old_symbol->binding_label) !=
0))
{
const char *null = "NULL", *s1, *s2;
s1 = sym->binding_label;
[Bug target/95261] [11 regression] gcc.target/powerpc/pr80695-p8.c and gcc.target/powerpc/pr80695-p9.c fail starting with r11-478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95261 --- Comment #3 from Bill Seurer --- I just tried on current trunk and these have cleared up now.
[Bug target/95341] Poor vector_size decomposition when SVE is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95341 --- Comment #3 from rsandifo at gcc dot gnu.org --- (In reply to ktkachov from comment #2) > Interestingly, -msve-vector-bits gives good codegen for 128, 256, 512 but > bad for 1024, 2048 and VLA code That's because addition is the one operation that we currently support on unpacked vectors. For subtraction it's a different story (just 128-bit and 256-bit is good, as expected). But the surprising thing for me was that we didn't fall back to Advanced SIMD in VLA mode...
[Bug target/95341] Poor vector_size decomposition when SVE is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95341 --- Comment #2 from ktkachov at gcc dot gnu.org --- Interestingly, -msve-vector-bits gives good codegen for 128, 256, 512 but bad for 1024, 2048 and VLA code
[Bug c++/95263] [11 Regression] ICE in lookup_template_class_1 since r11-504-g74744bb1f2847b5b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95263
--- Comment #1 from Nathan Sidwell ---
Reduced:
template class TPL {
template using INT = int;
};
template class Klass
{
public:
template using ALIAS = typename TPL::INT;
template static void FUNC (); // OK
template static ALIAS FUNC (); // SFINAE error
};
void Fn ()
{
Klass::FUNC<0> ();
}
[Bug fortran/95191] [9/10 Regression] Hang in WAIT with a bad ID= value if threading specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95191 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:3633bc27f5925394ccc5dd56bb1c65b4d88b42c0 commit r10-8187-g3633bc27f5925394ccc5dd56bb1c65b4d88b42c0 Author: Thomas Koenig Date: Sat May 23 19:01:43 2020 +0200 Fixes a hang on an invalid ID in a WAIT statement. gcc/fortran/ChangeLog: 2020-05-23 Thomas Koenig PR libfortran/95191 * libgfortran.h (libgfortran_error_codes): Add LIBERROR_BAD_WAIT_ID. libgfortran/ChangeLog: 2020-05-23 Thomas Koenig PR libfortran/95191 * io/async.c (async_wait_id): Generate error if ID is higher than the highest current ID. * runtime/error.c (translate_error): Handle LIBERROR_BAD_WAIT_ID. libgomp/ChangeLog: 2020-05-23 Thomas Koenig PR libfortran/95191 * testsuite/libgomp.fortran/async_io_9.f90: New test. (cherry picked from commit 8df7ee67f6fdc780e9453f2baa8d1bf62c000761)
[Bug target/95341] Poor vector_size decomposition when SVE is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95341 ktkachov at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC||ktkachov at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-26 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #17 from joe.harvell at netscout dot com --- It looks like this function is never called, by the way.
[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Related : $ cat z2.f90 module m interface module function f() end end interface interface function f() bind(c) end end interface end $ gfortran-11-20200524 -c z2.f90 f951: internal compiler error: Segmentation fault 0xbc0f6f crash_signal ../../gcc/toplev.c:328 0x643eeb gfc_match_function_decl() ../../gcc/fortran/decl.c:7398 0x6a82ca decode_statement ../../gcc/fortran/parse.c:343 0x6a9e1a next_free ../../gcc/fortran/parse.c:1279 0x6a9e1a next_statement ../../gcc/fortran/parse.c:1511 0x6aba5c parse_interface ../../gcc/fortran/parse.c:3519 0x6aba5c parse_spec ../../gcc/fortran/parse.c:3875 0x6af43e parse_module ../../gcc/fortran/parse.c:6115 0x6af787 gfc_parse_file() ../../gcc/fortran/parse.c:6428 0x6fb9af gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug fortran/95342] New: [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342 Bug ID: 95342 Summary: [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20191013 and 20191020, with a name conflict : $ cat z1.f90 module m interface module subroutine s() end subroutine s() bind(c) end end interface end $ gfortran-11-20200524 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbc0f6f crash_signal ../../gcc/toplev.c:328 0x644307 gfc_match_subroutine() ../../gcc/fortran/decl.c:7913 0x6a8427 decode_statement ../../gcc/fortran/parse.c:382 0x6a9e1a next_free ../../gcc/fortran/parse.c:1279 0x6a9e1a next_statement ../../gcc/fortran/parse.c:1511 0x6aba5c parse_interface ../../gcc/fortran/parse.c:3519 0x6aba5c parse_spec ../../gcc/fortran/parse.c:3875 0x6af43e parse_module ../../gcc/fortran/parse.c:6115 0x6af787 gfc_parse_file() ../../gcc/fortran/parse.c:6428 0x6fb9af gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug target/95341] New: Poor vector_size decomposition when SVE is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95341
Bug ID: 95341
Summary: Poor vector_size decomposition when SVE is enabled
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling the following with -O2 -march=armv8-a:
typedef unsigned int uint_vec __attribute__((vector_size(32)));
uint_vec f1(uint_vec x, uint_vec y) { return x + y; }
generates nice Advanced SIMD code:
ld1 {v4.16b - v5.16b}, [x0]
ld1 {v2.16b - v3.16b}, [x1]
add v0.4s, v4.4s, v2.4s
add v1.4s, v5.4s, v3.4s
st1 {v0.16b - v1.16b}, [x8]
ret
But compiling with -march=armv8.2-a+sve generates extremely bad
scalar code, so bad that I'll spare people's eyes by not quoting
it here.
I haven't yet analysed this or checked whether it's a regression.
[Bug fortran/95340] New: [10/11 Regression] ICE in gfc_match_select_rank, at fortran/match.c:6690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95340 Bug ID: 95340 Summary: [10/11 Regression] ICE in gfc_match_select_rank, at fortran/match.c:6690 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With a missing attribute allocatable or pointer; occurred between 20190825 (error) and 20190901 (ICE) : $ cat z1.f90 program p type t end type class(t) :: z select rank (z) end select end $ gfortran-11-20200524 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbc0f6f crash_signal ../../gcc/toplev.c:328 0x689bef gfc_match_select_rank() ../../gcc/fortran/match.c:6690 0x6a860e match_word ../../gcc/fortran/parse.c:65 0x6a860e decode_statement ../../gcc/fortran/parse.c:429 0x6a9e1a next_free ../../gcc/fortran/parse.c:1279 0x6a9e1a next_statement ../../gcc/fortran/parse.c:1511 0x6ab46b parse_spec ../../gcc/fortran/parse.c:3922 0x6ae23c parse_progunit ../../gcc/fortran/parse.c:5851 0x6af919 gfc_parse_file() ../../gcc/fortran/parse.c:6392 0x6fb9af gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug fortran/95339] New: ICE in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:8002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95339 Bug ID: 95339 Summary: ICE in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:8002 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p type t character(:), allocatable :: a end type type(t) :: x[*] data x /t(1)/ end $ gfortran-11-20200524 -c z1.f90 -fcoarray=single # accepted $ $ gfortran-11-20200524 -c z1.f90 -fcoarray=lib z1.f90:1:0: 1 | program p | internal compiler error: in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:8002 0x73618f alloc_scalar_allocatable_for_subcomponent_assignment ../../gcc/fortran/trans-expr.c:8002 0x73618f gfc_trans_subcomponent_assign ../../gcc/fortran/trans-expr.c:8190 0x7362bb gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool) ../../gcc/fortran/trans-expr.c:8467 0x72f860 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.c:8534 0x72fa9c gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8702 0x73f1aa gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:10884 0x71cf48 generate_coarray_sym_init ../../gcc/fortran/trans-decl.c:5688 0x6e6e32 do_traverse_symtree ../../gcc/fortran/symbol.c:4150 0x71c385 generate_coarray_init ../../gcc/fortran/trans-decl.c:5738 0x728aa4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6773 0x6affe6 translate_all_program_units ../../gcc/fortran/parse.c:6306 0x6affe6 gfc_parse_file() ../../gcc/fortran/parse.c:6545 0x6fb9af gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug fortran/95338] New: [9/10/11 Regression] ICE in eliminate_stmt, at tree-ssa-sccvn.c:5974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95338 Bug ID: 95338 Summary: [9/10/11 Regression] ICE in eliminate_stmt, at tree-ssa-sccvn.c:5974 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20181202 and 20181209, with option -O1 : $ cat z1.f90 module m contains function f(x) integer :: x integer :: f real :: g f = x return entry g(x) g = x end end program p use m print *, f(1) print *, g(1) end $ gfortran-11-20200524 -c z1.f90 -O2 -ff2c $ $ gfortran-11-20200524 -c z1.f90 -O1 -ff2c during GIMPLE pass: fre z1.f90:6:0: 6 | real :: g | internal compiler error: in eliminate_stmt, at tree-ssa-sccvn.c:5974 0xd40f45 eliminate_dom_walker::eliminate_stmt(basic_block_def*, gimple_stmt_iterator*) ../../gcc/tree-ssa-sccvn.c:5974 0xd45a90 process_bb ../../gcc/tree-ssa-sccvn.c:7173 0xd46fe1 do_rpo_vn ../../gcc/tree-ssa-sccvn.c:7657 0xd47f8a execute ../../gcc/tree-ssa-sccvn.c:7811 Configured with --enable-checking=yes : $ gfortran-11-20200524 -c z1.f90 -O1 -ff2c z1.f90:6:0: 6 | real :: g | Error: non-trivial conversion in 'component_ref' real(kind=8) real(kind=4) D.3943 = __result.g; z1.f90:6:0: internal compiler error: 'verify_gimple' failed 0xd9b27d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:5113 0xa526b1 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:14919 0xa52967 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:14990 0x88d9e7 cgraph_node::analyze() ../../gcc/cgraphunit.c:671 0x890e21 analyze_functions ../../gcc/cgraphunit.c:1231 0x892042 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2975
[Bug fortran/93482] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93482 --- Comment #2 from G. Steinmetz --- Another test case : $ cat z3.f90 program p character(2), parameter :: a(3) = ['a1', 'b2', 'c3'] print *, [(a(2:1))] print *, size([(a(2:1))]) end Works without parameter attribute : $ cat z4.f90 program p character(2) :: a(3) = ['a1', 'b2', 'c3'] print *, [(a(2:1))] print *, size([(a(2:1))]) end $ gfortran-11-20200524 z4.f90 && ./a.out 0 $
[Bug target/94995] gcc/config/aarch64/cortex-a57-fma-steering.c: 5 * member function could be const ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94995 Richard Earnshaw changed: What|Removed |Added Priority|P3 |P5 Target||aarch64 Severity|normal |enhancement
[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493 --- Comment #11 from Segher Boessenkool --- Why does our unpack expander use UNSPEC_UNPACK_128BIT at all, why can it not simply generate simple code (without unspecs) directly? (Same goes for "pack").
[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Tobias Burnus --- FIXED.
[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c5ab336ba106a407a67e84d8faac5b0ea6f18310 commit r11-640-gc5ab336ba106a407a67e84d8faac5b0ea6f18310 Author: Tobias Burnus Date: Tue May 26 18:24:28 2020 +0200 [LTO/offloading] Fix offloading-compilation ICE without -flto (PR84320) gcc/ChangeLog: PR ipa/95320 * ipa-utils.h (odr_type_p): Also permit calls with only flag_generate_offload set.
[Bug target/95336] Bad code gen omnetpp_r aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336 --- Comment #5 from Erick Ochoa --- (In reply to Andrew Pinski from comment #4) > Does -O2 -flto -ftree-vectorize fail also? It does not fail. I will try to narrow down the problem to an optimization later today.
[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159 --- Comment #6 from Jonathan Wakely --- Hmm, my patch doesn't actually fix the bogus warning, it just makes it possible to disable it. A front end wizard will need to fix the real bug.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #16 from joe.harvell at netscout dot com --- Correction on the previous comment. I said This function is defined in one .c file and declared with the extern keyword in another .c file. But in fact the extern declaration in the second .c file is removed by the pre-processor. So the symbol only occurs in one .c file.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 joe.harvell at netscout dot com changed: What|Removed |Added CC||joe.harvell at netscout dot com --- Comment #15 from joe.harvell at netscout dot com --- I get the following error on on gcc 8.3.0 using the default bfd linker with LTO, but only with binutils 2.27 and 2.34. This error does not occur with binutils 2.25. I also get this error with gcc 10.1.0 and binutils 2.34. (It's not possible to build gcc 10.1.0 correctly with binutils 2.25, so this is not tested). In all cases, there is no error when using the gold linker. lto1: fatal error: multiple prevailing defs for ‘actual_function_name_redacted’ This function is defined in one .c file and declared with the extern keyword in another .c file. For the gcc 10.1.0 / binutils 2.34 case, here is what I see using lto-dump: jharvell@grays obj$ /opt/gcc10.1/bin/lto-dump -symbol=actual_function_name_redacted actual_c_filename_redacted_v1.o Symbol: actual_function_name_redacted actual_function_name_redacted/259 (actual_function_name_redacted) @0x7fedffb7c168 Type: function definition analyzed Visibility: externally_visible public References: Referring: Read from file: actual_c_filename_redacted_v1.o Availability: available Unit id: 1 Function flags: count:1073741824 (estimated locally) Called by: Calls: memcpy/260 (354334800 (estimated locally),0.33 per call) jharvell@grays obj$ /opt/gcc10.1/bin/lto-dump -symbol=actual_function_name_redacted actual_c_filename_redacted.o Symbol: actual_function_name_redacted
[Bug c++/95307] Compiler accepts reinterpret_cast in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Blocks||55004 --- Comment #3 from Martin Sebor --- This looks like a duplicate of pr82304. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues
[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |11.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug target/95336] Bad code gen omnetpp_r aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336 Andrew Pinski changed: What|Removed |Added Target||aarch64-linux-gnu Component|ipa |target --- Comment #4 from Andrew Pinski --- Does -O2 -flto -ftree-vectorize fail also?
