[Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704 Bug ID: 94704 Summary: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ABI, wrong-code Severity: blocker Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: jakub at gcc dot gnu.org, ktkachov at gcc dot gnu.org, matmal01 at gcc dot gnu.org, mpolacek at gcc dot gnu.org, rearnsha at gcc dot gnu.org, redi at gcc dot gnu.org, rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org Depends on: 94383 Target Milestone: --- Target: aarch64-*-linux +++ This bug was initially created as a clone of Bug #94383 +++ In https://gcc.gnu.org/pipermail/gcc-testresults/2020-April/559424.html I see FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o execute That suggests similar ABI bug as on aarch64 (PR94383), where the presence or absence of C++17 empty base artificial FIELD_DECL affects the argument passing (or return?). One should be able to do make check-g++ RUNTESTFLAGS='--target_board=unix/-DDBG struct-layout-1.exp' to get more information into the log file which exact tests fail, from that number one can look up in gcc/testsuite/g++/g++.dg-struct-layout-1 subdir of the build directory t032_test.h etc. the T(...) line with the reported number(s), and one should be able to remove all but the chosen one T(...) line from the file to see a minimized testcase (+ preprocess to better see how exactly the structure looks like). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 [Bug 94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
[Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |10.0 CC||krebbel at gcc dot gnu.org
[Bug c/94705] New: [10 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705
Bug ID: 94705
Summary: [10 Regression] internal compiler error: tree check:
expected class ‘type’, have ‘exceptional’ (error_mark)
in diag_attr_exclusions, at attribs.c:396
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (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.
$ cat test.c
void sub_0 (void * arg_0){}
int sub_1 ( unsigned arg_0 ) {
if ( sub_0 ( sub_2 ) )
{
;
}
void __attribute__ ( ( noinline ) ) sub_2 ( int arg_0 );
}
$ gcc-10 test.c
test.c: In function ‘sub_1’:
test.c:4:15: error: ‘sub_2’ undeclared (first use in this function); did you
mean ‘sub_1’?
4 | if ( sub_0 ( sub_2 ) )
| ^
| sub_1
test.c:4:15: note: each undeclared identifier is reported only once for each
function it appears in
test.c:9:2: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396
9 | void __attribute__ ( ( noinline ) ) sub_2 ( int arg_0 );
| ^~~~
0x731f2f tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-10-20200419/gcc/tree.c:9777
0x5eaf44 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-10-20200419/gcc/tree.h:3410
0x5eaf44 diag_attr_exclusions
../../gcc-10-20200419/gcc/attribs.c:396
0x7d4fda diag_attr_exclusions
../../gcc-10-20200419/gcc/attribs.c:379
0x7d6fb5 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc-10-20200419/gcc/attribs.c:694
0x7f2554 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
../../gcc-10-20200419/gcc/c/c-decl.c:5117
0x84cdd5 c_parser_declaration_or_fndef
../../gcc-10-20200419/gcc/c/c-parser.c:2271
0x8302bf c_parser_compound_statement_nostart
../../gcc-10-20200419/gcc/c/c-parser.c:5718
0x84c8c4 c_parser_compound_statement
../../gcc-10-20200419/gcc/c/c-parser.c:5617
0x84e381 c_parser_declaration_or_fndef
../../gcc-10-20200419/gcc/c/c-parser.c:2505
0x8566e3 c_parser_external_declaration
../../gcc-10-20200419/gcc/c/c-parser.c:1745
0x8571e1 c_parser_translation_unit
../../gcc-10-20200419/gcc/c/c-parser.c:1618
0x8571e1 c_parse_file()
../../gcc-10-20200419/gcc/c/c-parser.c:21745
0x8ae2cb c_common_parse_file()
../../gcc-10-20200419/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 Jakub Jelinek changed: What|Removed |Added CC||schwab at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Andreas, do you think you could find out which struct (at least one) FAILs? See above...
[Bug target/94706] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 Bug ID: 94706 Summary: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ABI, wrong-code Severity: blocker Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: jakub at gcc dot gnu.org, ktkachov at gcc dot gnu.org, matmal01 at gcc dot gnu.org, mpolacek at gcc dot gnu.org, rearnsha at gcc dot gnu.org, redi at gcc dot gnu.org, rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org Depends on: 94383 Blocks: 94704 Target Milestone: --- Target: aarch64-*-linux +++ This bug was initially created as a clone of Bug #94383 +++ In https://gcc.gnu.org/pipermail/gcc-testresults/2020-April/559430.html I see FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t033 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o execute That suggests similar ABI bug as on aarch64 (PR94383), where the presence or absence of C++17 empty base artificial FIELD_DECL affects the argument passing (or return?). One should be able to do make check-g++ RUNTESTFLAGS='--target_board=unix/-DDBG struct-layout-1.exp' to get more information into the log file which exact tests fail, from that number one can look up in gcc/testsuite/g++/g++.dg-struct-layout-1 subdir of the build directory t032_test.h etc. the T(...) line with the reported number(s), and one should be able to remove all but the chosen one T(...) line from the file to see a minimized testcase (+ preprocess to better see how exactly the structure looks like). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 [Bug 94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704 [Bug 94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #8 from Richard Biener ---
So I did some more experiments. With
int foo (int x)
{
if (x != 0)
return 1;
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
return 0;
}
int main()
{
int i = foo (0);
return i;
}
IPA split splits foo. Arranging things (unpatched) to not inline anything
after splitting does
Temporary breakpoint 1, main () at x.c:16
16 {
(gdb) s
17int i = foo (0);
(gdb) s
foo (x=0) at x.c:3
3 if (x != 0)
(gdb) s
foo (x=) at x.c:5
5 __builtin_printf ("%d\n", x);
(gdb) fin
Run till exit from #0 foo (x=) at x.c:5
0
0
0
0
0
0
0
0x00400522 in main () at x.c:17
17int i = foo (0);
Value returned is $1 = 0
arranging the head to be inlined into main
Temporary breakpoint 1, main () at x.c:17
17int i = foo (0);
(gdb) s
foo (x=0) at x.c:17
17int i = foo (0);
(gdb) s
foo (x=) at x.c:5
5 __builtin_printf ("%d\n", x);
(gdb) fin
Run till exit from #0 foo (x=) at x.c:5
0
0
0
0
0
0
0
__libc_start_main (main=0x400430 , argc=1, argv=0x7fffde98,
init=, fini=, rtld_fini=,
stack_end=0x7fffde88) at libc-start.c:323
323 libc-start.c: No such file or directory.
Value returned is $1 = 0
arranging the tail to be re-inlined into the head:
Temporary breakpoint 1, main () at x.c:16
16 {
(gdb) s
17int i = foo (0);
(gdb)
foo (x=0) at x.c:3
3 if (x != 0)
(gdb)
5 __builtin_printf ("%d\n", x);
(gdb) fin
Run till exit from #0 foo (x=0) at x.c:5
0
0
0
0
0
0
0
0x00400522 in main () at x.c:17
17int i = foo (0);
now with the proposed patch:
Temporary breakpoint 1, main () at x.c:16
16 {
(gdb) s
17int i = foo (0);
(gdb)
foo (x=0) at x.c:3
3 if (x != 0)
(gdb)
__printf (format=0x400644 "%d\n") at printf.c:28
28 printf.c: No such file or directory.
(gdb) fin
Run till exit from #0 __printf (format=0x400644 "%d\n") at printf.c:28
0
0x00400542 in foo.part () at x.c:18
18return i;
Value returned is $1 = 2
(gdb) fin
Run till exit from #0 0x00400542 in foo.part () at x.c:18
0
0
0
0
0
0
0x00400522 in main () at x.c:17
17int i = foo (0);
and
Temporary breakpoint 1, main () at x.c:17
17int i = foo (0);
(gdb) s
foo (x=0) at x.c:17
17int i = foo (0);
(gdb)
0x00400520 in foo.part ()
(gdb)
Single stepping until exit from function foo.part.0,
which has no line number information.
__printf (format=0x400634 "%d\n") at printf.c:28
28 printf.c: No such file or directory.
(gdb) fin
Run till exit from #0 __printf (format=0x400634 "%d\n") at printf.c:28
0
0x00400532 in foo.part ()
Value returned is $1 = 2
(gdb) fin
Run till exit from #0 0x00400532 in foo.part ()
0
0
0
0
0
0
__libc_start_main (main=0x400430 , argc=1, argv=0x7fffde98,
init=, fini=, rtld_fini=,
stack_end=0x7fffde88) at libc-start.c:323
323 libc-start.c: No such file or directory.
and finally
Temporary breakpoint 1, main () at x.c:16
16 {
(gdb) s
17int i = foo (0);
(gdb)
foo (x=0) at x.c:3
3 if (x != 0)
(gdb)
1 int foo (int x)
(gdb)
__printf (format=format@entry=0x400634 "%d\n") at printf.c:28
28 printf.c: No such file or directory.
(gdb) fin
Run till exit from #0 __printf (format=format@entry=0x400634 "%d\n")
at printf.c:28
0
0x00400552 in foo (x=) at x.c:1
1 int foo (int x)
Value returned is $1 = 2
(gdb) fin
Run till exit from #0 0x00400552 in foo (x=) at x.c:1
0
0
0
0
0
0
0x00400522 in main () at x.c:17
17int i = foo (0);
Value returned is $2 = 0
to me that clearly isn't an improvement :/
I guess gdb doesn't like the DW_TAG_inlined_subroutine for DECL_INGORED_P
entities - in this case we end up with
<2><18e>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
<18f> DW_AT_entry_pc: 0x400540
<197> DW_AT_GNU_entry_view: 1
<198> DW_AT_ranges : 0x40
<19c> DW_AT_call_file : 1
<19d> DW_AT_call_line : 1
<19e> DW_AT_call_column : 5
<19f> DW_AT_sibling : <0x1b1>
but there's no abstract origin here. Of course the whole point of the
patch was to avoid the "inline" as that would appear as a breakpoint
location.
I suppose in dwarf2out we should elide the use of DW_TAG_inlined_subroutine
for DECL_IGNORED (or even DECL_ARTIFICIAL?) functions and instead just
emit a lexical block (w/o abstract origin)?
That said, as usual it's difficult to say what is an appropriate DWARF
representation for the issue at hand and what's the opti
[Bug target/94707] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 Bug ID: 94707 Summary: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ABI, wrong-code Severity: blocker Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Depends on: 94383 Target Milestone: --- Target: powerpc64le-*-linux +++ This bug was initially created as a clone of Bug #94383 +++ I see these failures for Jakub's new test for PR 94383: fail 50.30 fail 116.55 fail 116.56 fail 116.74 fail 116.74 fail 116.74 fail 116.74 fail 116.72 fail 116.74 fail 116.74 fail 120.10 fail 120.11 fail 120.17 fail 120.55 fail 120.56 fail 120.18 fail 124.30 fail 127.30 fail 140.30 fail 187.10 fail 187.11 fail 187.12 fail 187.17 fail 187.50 fail 187.55 fail 187.56 fail 187.18 FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o execute fail 2613.30 fail 2638.30 FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o execute fail 2854.30 FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o execute I've only checked powerpc64le but it's probably wrong on powerpc64 too. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 [Bug 94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0
[Bug rtl-optimization/94708] New: rtl combine should consider NaNs when generate fp min/max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708 Bug ID: 94708 Summary: rtl combine should consider NaNs when generate fp min/max Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: z.zhanghaijian at huawei dot com Target Milestone: --- Rtl combine should consider NaNs when generate fp min/max. There is detailed discussion information here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 Proposed patch: diff --git a/gcc/combine.c b/gcc/combine.c index cff76cd3303..eaf93a05235 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -6643,7 +6643,8 @@ simplify_if_then_else (rtx x) /* Look for MIN or MAX. */ - if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations) + if ((! FLOAT_MODE_P (mode) + || (flag_unsafe_math_optimizations && flag_finite_math_only)) && comparison_p && rtx_equal_p (XEXP (cond, 0), true_rtx) && rtx_equal_p (XEXP (cond, 1), false_rtx)
[Bug c/94705] [8/9/10 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396 since r8-5161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705 Jakub Jelinek changed: What|Removed |Added Summary|[10 Regression] internal|[8/9/10 Regression] |compiler error: tree check: |internal compiler error: |expected class ‘type’, have |tree check: expected class |‘exceptional’ (error_mark) |‘type’, have ‘exceptional’ |in diag_attr_exclusions, at |(error_mark) in |attribs.c:396 |diag_attr_exclusions, at ||attribs.c:396 since r8-5161 Keywords||error-recovery Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |8.5 Last reconfirmed||2020-04-22 CC||jakub at gcc dot gnu.org Priority|P3 |P4 --- Comment #1 from Jakub Jelinek --- Started with r8-5161-g5d9ae53d70c72991e26648d915e7fb8e00b8e811
[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Version|unknown |10.0
Last reconfirmed||2020-04-22
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Target||x86_64-*-*
--- Comment #1 from Richard Biener ---
Confirmed. We end up with
get4_1 (const void * X)
{
uint64_t r;
unsigned int _4;
uint64_t _6;
[local count: 1073741824]:
r = 0;
_4 = MEM [(char * {ref-all})X_3(D)];
MEM [(char * {ref-all})&r] = _4;
_6 = r;
r ={v} {CLOBBER};
return _6;
and
get4_nospill (const void * X)
{
union
{
uint64_t u64;
} u;
unsigned int _4;
uint64_t _6;
[local count: 1073741824]:
u.u64 = 0;
_4 = MEM [(char * {ref-all})X_3(D)];
MEM [(char * {ref-all})&u] = _4;
_6 = u.u64;
u ={v} {CLOBBER};
return _6;
so it's the same on the GIMPLE level but somehow RTL expansion likes
the latter more, expanding 'u' to a register but not 'r'. Ah,
that's because we have to keep TREE_ADDRESSABLE to prevent 'r' from
being rewritten into SSA but not 'u' ...
Extending DECL_GIMPLE_REG_P to non-vector/comples vars would likely
fix this.
We can also rewrite 'r' into SSA when we use BIT_INSERT_EXPR more
aggressively (not sure if we want that).
[Bug c/94705] [8/9/10 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396 since r8-5161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705
--- Comment #2 from Jakub Jelinek ---
Slightly reduced:
void foo ();
int
bar (void)
{
foo (baz);
void __attribute__ ((noinline)) baz (void);
}
[Bug fortran/94709] New: [OpenMP][OpenACC][!GCC$ attributes] No line truncation warning printed for directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94709 Bug ID: 94709 Summary: [OpenMP][OpenACC][!GCC$ attributes] No line truncation warning printed for directives Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: diagnostic, openacc, openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Created attachment 48333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48333&action=edit Draft patch – fixes the problem but now wrongly warns for some too-long comments Came up in PR 94690 comment 2 Namely, if an OpenMP directive gets truncated after maxlen = 132 (for free-form source code), it is simply truncated without showing an error – and one is surprised about the parser failure. Expected: With free form an error, with fixed form a warning with -Wall. The reason that this does not happen is that commented lines are silently truncated – and this includes !$omp and !$acc directives and !GCC$ attributes. The attached patch fixes this issue, but now causes an error for: a = b ! very, very long comment This happens commonly with "! dg-error" lines (e.g. gfortran.dg/bind_c_bool_1.f90 to pick one). Namely: * If the comment starts after maxlen, it is fine with the current patch. * If the comment starts at the beginning of the line, it is also fine – the gfc_next_char_literal function takes care of this. (Which has a complicated check for OpenMP/OpenACC/!GCC$.) * Only if the comment starts within the permitted range but is too long, now a warning/Werror is printed.
[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690 --- Comment #4 from Tobias Burnus --- (In reply to Tobias Burnus from comment #3) > (In reply to Tobias Burnus from comment #2) > > EXPECTED: There is some diagnostic for free-form Fortran and for > > -Wline-truncation also for fixed-form Fortran source form. That's now tracked in PR 94709. The simple patch is incomplete (see new PR).
[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703 Richard Biener changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Richard Biener --- Implementation plan extending DECL_GIMPLE_REG_P: a) invert it, DECL_GIMPLE_REG_P -> DECL_NOT_GIMPLE_REG_P b) honor DECL_NOT_GIMPLE_REG_P for all types (just grep, most importantly in is_gimple_reg), eventually some tests for TREE_ADDRESSABLE need adjusting to DECL_NOT_GIMPLE_REG_P c) in update_address_taken always clear TREE_ADDRESSABLE when possible but set DECL_NOT_GIMPLE_REG_P appropriately; audit other setters of TREE_ADDRESSABLE if they could do similar CCing Martin who's always eager to jump onto new tasks ;)
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.5
[Bug rtl-optimization/94708] rtl combine should consider NaNs when generate fp min/max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708 --- Comment #1 from Richard Biener --- fold guards it with !HONOR_SIGNED_ZEROS && !HONOR_NANS (fold_cond_expr_with_comparison). I think the flag_unsafe_math_optmizations check is bogus. Note we now have fmax/fmin named patterns that can be used unconditionally but I guess using expanders during RTL simplification can be tricky. Note also we as of today generally avoid doing "much" with FP math on the RTL side and IMHO we should continue to do so. IMHO the transform belongs on the GIMPLE side where we already do it.
[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- ACtually I'll give it a quick try.
[Bug c/94705] [8/9/10 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396 since r8-5161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 48334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48334&action=edit gcc10-pr94705.patch Untested fix.
[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703 --- Comment #4 from Richard Biener --- Created attachment 48335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48335&action=edit untested patch Patch, easier than expected. Possibly needs some adjustment to the gimplifier, we'll see.
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-04-22
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Jakub Jelinek ---
E.g. the 120.* failures can be seen on
struct empty_base {};
struct S : public empty_base { float a[5]; };
S s;
int i;
void foo (S, int *);
int
bar ()
{
foo (s, &i);
return 0;
}
compile with -O2 -std=c++14 and then with -O2 -std=c++17 and see it generating
different code.
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 --- Comment #2 from Jakub Jelinek --- With -std=c++14, the structure is passed in floating point registers 1, 2, 3, 4, 5 (SFmode each elt), with -std=c++17 the structure is passed in gprs 3, 4, 5 (where the first two contain 64-bits each, the last one contains 32 bits zero extended to 64 bits).
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #2 from Andreas Schwab --- Created attachment 48336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48336&action=edit Preprocessed t032_x.C with reduced t032_test.h fail 116.55 fail 116.56 fail 116.30 fail 120.55 fail 142.55 fail 142.56 fail 142.30 fail 144.55 fail 144.56 fail 144.30 fail 145.55 fail 145.56 fail 145.30 fail 178.55 fail 178.56 fail 178.30 fail 187.10 fail 187.11 fail 187.12 fail 187.50 fail 187.55 fail 187.56 fail 187.18 fail 187.30
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #3 from Andreas Schwab --- Created attachment 48337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48337&action=edit Preprocessed t032_y.C with reduced t032_test.h
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 --- Comment #3 from Jakub Jelinek --- --- gcc/config/rs6000/rs6000-call.c.jj 2020-03-30 22:53:40.746640328 +0200 +++ gcc/config/rs6000/rs6000-call.c 2020-04-22 11:07:05.507723606 +0200 @@ -5636,6 +5636,16 @@ rs6000_aggregate_candidate (const_tree t if (TREE_CODE (field) != FIELD_DECL) continue; + /* Ignore C++17 empty base fields, while their type indicates + they do contain padding, they have zero size and thus don't + contain any padding. */ + if (DECL_ARTIFICIAL (field) + && DECL_NAME (field) == NULL_TREE + && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field)) + && DECL_SIZE (field) + && integer_zerop (DECL_SIZE (field))) + continue; + sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep); if (sub_count < 0) return -1; fixes the ABI difference, but more work will be needed to actually do the -Wpsabi diagnostics, bet similarly to the aarch64 patch it needs to tell the callers that the empty base field has been seen and ignored; now if the type turns out to be a homogenous aggregate and whatever calls that function would make a different decision based on whether it is homogenous or not, and the c++17 empty base has been seen in it, then it should perform -Wpsabi diagnostics.
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #4 from Andreas Schwab --- Created attachment 48338 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48338&action=edit Preprocessed t033_x.C with reduced t033_test.h fail 545.55
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #5 from Andreas Schwab --- Created attachment 48339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48339&action=edit Preprocessed t033_y.C with reduced t033_test.h
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #6 from Andreas Schwab --- Created attachment 48340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48340&action=edit Preprocessed t055_x.C with reduced t055_test.h fail 2006.55 fail 2006.56 fail 2006.30
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #7 from Andreas Schwab --- Created attachment 48341 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48341&action=edit Preprocessed t055_y.C with reduced t055_test.h
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #8 from Andreas Schwab --- Created attachment 48342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48342&action=edit Preprocessed t056_x.C with reduced t056_test.h fail 2215.55 fail 2215.56 fail 2215.30
[Bug c++/94682] coroutines: Promise param preview should get a reference to *this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94682 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:38644f81babd04820daa9d622ea75eb68c066c86 commit r10-7868-g38644f81babd04820daa9d622ea75eb68c066c86 Author: Iain Sandoe Date: Wed Apr 22 09:49:20 2020 +0100 coroutines: Pass class reference to promise param preview [PR94682] As reported in the PR, per [dcl.fct.def.coroutine]/4 we should be passing a reference to the object to the promise parameter preview, and we are currently passing a pointer (this). Amend to pass the reference. gcc/cp/ChangeLog: 2020-04-22 Iain Sandoe PR c++/94682 * coroutines.cc (struct param_info): Add a field to note that the param is 'this'. (morph_fn_to_coro): Convert this to a reference before using it in the promise parameter preview. gcc/testsuite/ChangeLog: 2020-04-22 Iain Sandoe PR c++/94682 * g++.dg/coroutines/pr94682-preview-this.C: New test.
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #9 from Andreas Schwab --- Created attachment 48343 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48343&action=edit Preprocessed t056_y.C with reduced t056_test.h
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #10 from Andreas Schwab --- Created attachment 48344 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48344&action=edit Preprocessed t057_x.C with reduced t057_test.h fail 2411.55 fail 2411.56 fail 2411.30
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #11 from Andreas Schwab --- Created attachment 48345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48345&action=edit Preprocessed t057_y.C with reduced t057_test.h
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #12 from Andreas Schwab --- Created attachment 48346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48346&action=edit Preprocessed t058_x.C with reduced t058_test.h fail 2613.30 fail 2638.30
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #13 from Andreas Schwab --- Created attachment 48347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48347&action=edit Preprocessed t058_y.C with reduced t058_test.h
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #14 from Andreas Schwab --- Created attachment 48348 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48348&action=edit Preprocessed t059_x.C with reduced t059_test.h fail 2854.30
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #15 from Andreas Schwab --- Created attachment 48349 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48349&action=edit Preprocessed t059_y.C with reduced t059_test.h
[Bug c++/94682] coroutines: Promise param preview should get a reference to *this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94682 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- fixed.
[Bug target/94248] [amdgcn] Doesn't build with RTL checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94248
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed|2020-04-21 00:00:00 |2020-4-22
--- Comment #6 from Thomas Schwinge ---
(In reply to Andrew Stubbs from comment #5)
> Yes, the REG_P can still ICE with the additional checking enabled.
So are you fine with me installing Jakub's patch?
(In reply to Thomas Schwinge from comment #4)
> Thus, again:
>
> (In reply to Thomas Schwinge from comment #2)
> > (In reply to Jakub Jelinek from comment #1)
> > > --- gcc/config/gcn/gcn.md.jj 2020-03-03 07:57:42.363827602 +0100
> > > +++ gcc/config/gcn/gcn.md 2020-03-21 15:37:45.337552515 +0100
> > > @@ -625,7 +625,7 @@ (define_insn_and_split "*mov_insn"
> > > rtx outhi = gen_highpart_mode (SImode, mode, operands[0]);
> > >
> > > /* Ensure that overlapping registers aren't corrupted. */
> > > -if (REGNO (outlo) == REGNO (inhi))
> > > +if (reg_overlap_mentioned_p (outlo, inhi))
> > >{
> > > operands[0] = outhi;
> > > operands[1] = inhi;
> > > ought to fix this
> >
> > I've tested that one; no more ICE, and bit-identical code for all target
> > libraries, so I suppose this is good to commit (Andrew, Julian)? If
> > approving this patch, please respond with "Reviewed-by: NAME " so
> > that your effort will be recorded in the commit log, see
> > .
[Bug target/94697] aarch64: bti j at function start instead of bti c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697 Richard Earnshaw changed: What|Removed |Added Last reconfirmed||2020-04-22 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Earnshaw --- Jumping to the label is not the same as calling the function indirectly. But yes, the code here is clearly incorrect.
[Bug tree-optimization/94700] ICE in forwprop when folding to a VEC_PERM_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94700 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:413232a55b960c9b207abf14eea4a8dd247c3e90 commit r10-7870-g413232a55b960c9b207abf14eea4a8dd247c3e90 Author: Richard Sandiford Date: Wed Apr 22 11:05:59 2020 +0100 forwprop: Fix ICE when building an identity constructor [PR94700] This is really PR94683 part 2, handling the case in which the vector is an identity and so doesn't need a VEC_PERM_EXPR. I should have realised at the time that the other arm of the "if" would need the same fix. 2020-04-22 Richard Sandiford gcc/ PR tree-optimization/94700 * tree-ssa-forwprop.c (simplify_vector_constructor): When processing an identity constructor, use a VIEW_CONVERT_EXPR to handle mixtures of similarly-structured but distinct vector types. gcc/testsuite/ PR tree-optimization/94700 * gcc.target/aarch64/sve/acle/general/pr94700.c: New test.
[Bug tree-optimization/94700] ICE in forwprop when folding to a VEC_PERM_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94700 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed on master.
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
--- Comment #4 from Jakub Jelinek ---
Updated incomplete patch on top of
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544276.html
I've handled one rs6000_discover_homogeneous_aggregate caller where it wasn't
that hard to figure out
how to report different decisions based on if GCC 7/8/9 with -std=c++17 would
make the aggregate
non-homogeneous because of the C++17 empty base artificial FIELD_DECL and we'd
return true because of that, while
in -std=c++14 and in patched GCC trunk we'd return false.
But I'm getting lost in all the other spots, figuring out if we made different
decisions is harder.
--- gcc/config/rs6000/rs6000-internal.h.jj 2020-03-20 09:11:36.229903622
+0100
+++ gcc/config/rs6000/rs6000-internal.h 2020-04-22 11:31:23.943522525 +0200
@@ -129,7 +129,8 @@ extern int rs6000_darwin64_struct_check_
extern bool rs6000_discover_homogeneous_aggregate (machine_mode mode,
const_tree type,
machine_mode *elt_mode,
- int *n_elts);
+ int *n_elts,
+ bool
*cxx17_empty_base_seen);
extern void rs6000_output_mi_thunk (FILE *file,
tree thunk_fndecl ATTRIBUTE_UNUSED,
HOST_WIDE_INT delta,
--- gcc/config/rs6000/rs6000-call.c.jj 2020-03-30 22:53:40.746640328 +0200
+++ gcc/config/rs6000/rs6000-call.c 2020-04-22 12:06:00.066843119 +0200
@@ -5528,7 +5528,8 @@ const struct altivec_builtin_types altiv
sub-tree. */
static int
-rs6000_aggregate_candidate (const_tree type, machine_mode *modep)
+rs6000_aggregate_candidate (const_tree type, machine_mode *modep,
+ bool *cxx17_empty_base_seen)
{
machine_mode mode;
HOST_WIDE_INT size;
@@ -5598,7 +5599,8 @@ rs6000_aggregate_candidate (const_tree t
|| TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST)
return -1;
- count = rs6000_aggregate_candidate (TREE_TYPE (type), modep);
+ count = rs6000_aggregate_candidate (TREE_TYPE (type), modep,
+ cxx17_empty_base_seen);
if (count == -1
|| !index
|| !TYPE_MAX_VALUE (index)
@@ -5636,7 +5638,15 @@ rs6000_aggregate_candidate (const_tree t
if (TREE_CODE (field) != FIELD_DECL)
continue;
- sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep);
+ if (cxx17_empty_base_field_p (field))
+ {
+ if (cxx17_empty_base_seen)
+ *cxx17_empty_base_seen = true;
+ continue;
+ }
+
+ sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep,
+ cxx17_empty_base_seen);
if (sub_count < 0)
return -1;
count += sub_count;
@@ -5669,7 +5679,8 @@ rs6000_aggregate_candidate (const_tree t
if (TREE_CODE (field) != FIELD_DECL)
continue;
- sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep);
+ sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep,
+ cxx17_empty_base_seen);
if (sub_count < 0)
return -1;
count = count > sub_count ? count : sub_count;
@@ -5700,7 +5711,8 @@ rs6000_aggregate_candidate (const_tree t
bool
rs6000_discover_homogeneous_aggregate (machine_mode mode, const_tree type,
machine_mode *elt_mode,
- int *n_elts)
+ int *n_elts,
+ bool *cxx17_empty_base_seen)
{
/* Note that we do not accept complex types at the top level as
homogeneous aggregates; these types are handled via the
@@ -5710,7 +5722,8 @@ rs6000_discover_homogeneous_aggregate (m
&& AGGREGATE_TYPE_P (type))
{
machine_mode field_mode = VOIDmode;
- int field_count = rs6000_aggregate_candidate (type, &field_mode);
+ int field_count = rs6000_aggregate_candidate (type, &field_mode,
+ cxx17_empty_base_seen);
if (field_count > 0)
{
@@ -5734,6 +5747,8 @@ rs6000_discover_homogeneous_aggregate (m
*elt_mode = mode;
if (n_elts)
*n_elts = 1;
+ if (cxx17_empty_base_seen)
+*cxx17_empty_base_seen = false;
return false;
}
@@ -5790,9 +5805,14 @@ rs6000_return_in_memory (const_tree type
}
/* The ELFv2 ABI returns homogeneous VFP aggregates in registers */
+ bool cxx17_empty_base_seen = false;
if (rs6000_discover_homogeneous_aggregate (TYPE_MODE (type), type,
-NULL, NULL))
-re
[Bug target/94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94278
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed|2020-04-21 00:00:00 |2020-4-22
--- Comment #3 from Thomas Schwinge ---
(In reply to Andrew Stubbs from comment #2)
> Well, it works for me:
>
> PASS: libgomp.c/examples-4/async_target-2.c (test for excess errors)
> PASS: libgomp.c/examples-4/async_target-2.c execution test
Strange.
> That's with an unmodified LLVM 9 we built ourselves.
By the way, I see the same problem when using LLVM 10.
Most certainly there is some problem in the LLVM assembler (because that tool
certainly should SIGSEGV even when presented possibly "strange" input), and
maybe that depends on the optimization level that LLVM has been compiled with,
or something like that...
But, I found at least something. From a quick search through my email
archives, I see that there's a huge (maybe even complete?, not verified)
overlap compared to the test FAILs reported in PR81430 "nvptx acceleration
compilation broken because of running pass_partition_blocks". And indeed the
same '-freorder-blocks-and-partition' ('flag_reorder_blocks_and_partition')
nvptx force-disable hack that once got installed in r250421 "Add
nvptx_override_options_after_change" (later reverted after proper fix for that
issue, r250852 "Apply finish_options on DECL_FUNCTION_SPECIFIC_OPTIMIZATION for
ACCEL_COMPILER") also does cure (or rather, avoid?) this problem reported here
for GCN offloading compilation, where assumed-correct GCC GCN code is generated
that the LLVM assembler fails to understand.
Would the following be OK to commit as a workaround? If approving this patch,
please respond with "Reviewed-by: NAME " so that your effort will be
recorded in the commit log, see . The
GCN code generated in 'build-gcc-offload-amdgcn-amdhsa/amdgcn-amdhsa/' doesn't
change at all, and it doesn't cause any libgomp offloading compilation
regressions, but I have not yet otherwise assessed whether this breaks
anything.
+static void
+gcn_override_options_after_change (void)
+{
+ flag_reorder_blocks_and_partition = 0;
+}
+#undef TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
+#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
gcn_override_options_after_change
At the very least, this gives a clue about where to further look for what the
actual problem is.
[Bug target/94710] New: [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 Bug ID: 94710 Summary: [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4) Product: gcc Version: 10.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: powerpc64le-unknown-linux-gnu Created attachment 48350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48350&action=edit reduced testcase Compiler output: $ powerpc64le-unknown-linux-gnu-gcc testcase.c /tmp/ccL15VfZ.s: Assembler messages: /tmp/ccL15VfZ.s:19: Error: operand out of range (4 is not between 0 and 3) $ powerpc64le-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r10-7838-20200420212053-g8e841bd419f-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/10.0.1/lto-wrapper Target: powerpc64le-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu --with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld --with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r10-7838-20200420212053-g8e841bd419f-checking-yes-rtl-df-extra-powerpc64le Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.1 20200421 (experimental) (GCC)
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706
--- Comment #16 from Jakub Jelinek ---
Would:
--- gcc/config/ia64/ia64.c.jj 2020-01-12 11:54:36.338414540 +0100
+++ gcc/config/ia64/ia64.c 2020-04-22 12:49:59.627563114 +0200
@@ -4665,7 +4665,7 @@ hfa_element_mode (const_tree type, bool
case QUAL_UNION_TYPE:
for (t = TYPE_FIELDS (type); t; t = DECL_CHAIN (t))
{
- if (TREE_CODE (t) != FIELD_DECL)
+ if (TREE_CODE (t) != FIELD_DECL || cxx17_empty_base_field_p (t))
continue;
mode = hfa_element_mode (TREE_TYPE (t), 1);
on top of https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544276.html fix
that?
ia64 doesn't have any -Wpsabi warnings, so I think it isn't worth bothering
with that.
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.5
[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694 --- Comment #23 from Andrea Corallo --- "foreese at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694 > > --- Comment #21 from Fritz Reese --- > Created attachment 48332 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48332&action=edit > Patch to protect trigd functions based on system availability > > Patch for trigd include pieces to check for HAVE_XXX[*]. If a required piece > is > not defined, the function is replaced with simply a runtime_error(). > > @akrl and @ktkachov, please combine this with Jakub's patch and see how the > build goes. Like Jakub I am also on x86_64-linux and it is difficult to > exercise all the conditions. Hi, I confirm that combining the two patches works for me for building aarch64-none-elf now. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
[Bug target/94279] [amdgcn] internal compiler error: RTL check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at rtl.h:2379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94279
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed||2020-04-22
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Thomas Schwinge ---
With '#pragma GCC optimize "-O0"' added to the top of 'gcc/recog.c',
'gcc/rtlanal.c', and courtesy of GDB, here is a better backtrace of
'build-gcc-offload-amdgcn-amdhsa/gcc/lto1', and more information:
during RTL pass: split2
[...]/libgomp.c-c++-common/for-2.h: In function
‘f4_tpf_simd_guided32._omp_fn.1’:
[...]/libgomp.c-c++-common/for-2.h:69:9: internal compiler error: RTL
check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at
rtl.h:2380
(gdb) bt
#0 internal_error (gmsgid=0x15dcf70 "RTL check: expected code '%s', have
'%s' in %s, at %s:%d") at [...]/gcc/diagnostic.c:1706
#1 0x00553aa6 in rtl_check_failed_code1 (r=0x764960a8,
code=, file=, line=,
func=) at [...]/gcc/rtl.c:881
#2 0x00b4500c in rtx_to_poly_int64 (x=0x764960a8) at
[...]/gcc/rtl.h:2380
#3 0x00b252b4 in set_noop_p (set=0x76496120) at
[...]/gcc/rtlanal.c:1635
#4 0x00ad741b in split_all_insns () at [...]/gcc/recog.c:2975
#5 0x00adac0e in (anonymous
namespace)::pass_split_before_regstack::execute (this=0x1d95fe0) at
[...]/gcc/recog.c:4027
#6 0x00a7f090 in execute_one_pass (pass=pass@entry=0x1d95fe0) at
[...]/gcc/passes.c:2502
#7 0x00a7f9e8 in execute_pass_list_1 (pass=0x1d95fe0) at
[...]/gcc/passes.c:2590
#8 0x00a7f9fa in execute_pass_list_1 (pass=0x1d95ec0) at
[...]/gcc/passes.c:2591
#9 0x00a7f9fa in execute_pass_list_1 (pass=0x1d94cc0) at
[...]/gcc/passes.c:2591
#10 0x00a7fa45 in execute_pass_list (fn=,
pass=) at [...]/gcc/passes.c:2601
#11 0x00682413 in cgraph_node::expand (this=0x76642ca8) at
[...]/gcc/cgraphunit.c:2300
#12 0x00683b74 in expand_all_functions () at
[...]/gcc/cgraphunit.c:2471
#13 symbol_table::compile (this=0x767a9000) at
[...]/gcc/cgraphunit.c:2822
#14 0x00684246 in symbol_table::compile (this=) at
[...]/gcc/cgraphunit.c:2856
#15 0x005b79f6 in lto_main () at [...]/gcc/lto/lto.c:653
#16 0x00b91abf in compile_file () at [...]/gcc/toplev.c:458
#17 0x0059035d in do_compile () at [...]/gcc/toplev.c:2273
#18 toplev::main (this=this@entry=0x7fffd220, argc=argc@entry=19,
argv=0x1d616e0, argv@entry=0x7fffd328) at [...]/gcc/toplev.c:2412
#19 0x00592f37 in main (argc=19, argv=0x7fffd328) at
[...]/gcc/main.c:39
(gdb) frame 4
#4 0x00ad741b in split_all_insns () at [...]/gcc/recog.c:2975
2975 if (set && set_noop_p (set))
(gdb) list
2970 rtx set = single_set (insn);
2971
2972 /* Don't split no-op move insns. These should
silently
2973 disappear later in final. Splitting such insns
would
2974 break the code that handles LIBCALL blocks. */
2975 if (set && set_noop_p (set))
2976{
2977 /* Nops get in the way while scheduling, so
delete them
2978 now if register allocation has already been
done. It
2979 is too risky to try to do this before register
(gdb) call debug_rtx(insn)
(insn 109 108 182 13 (set (reg/v:SI 2 s2 [orig:434 i ] [434])
(vec_select:SI (reg:V64SI 163 v3 [orig:450 vect_i_22.2317 ] [450])
(parallel [
(reg:SI 2 s2 [503])
]))) 140 {vec_extractv64sisi}
(nil))
(gdb) call debug_rtx(set)
(set (reg/v:SI 2 s2 [orig:434 i ] [434])
(vec_select:SI (reg:V64SI 163 v3 [orig:450 vect_i_22.2317 ] [450])
(parallel [
(reg:SI 2 s2 [503])
])))
(gdb) down
#3 0x00b252b4 in set_noop_p (set=0x76496120) at
[...]/gcc/rtlanal.c:1635
1635 poly_int64 c0 = rtx_to_poly_int64 (XVECEXP (par, 0, 0));
(gdb) list 1598
1593^L
1594/* Return nonzero if the destination of SET equals the source
1595 and there are no side effects. */
1596
1597int
1598set_noop_p (const_rtx set)
1599{
1600 rtx src = SET_SRC (set);
1601 rtx dst = SET_DEST (set);
1602
(gdb) call debug_rtx(src)
(vec_select:SI (reg:V64SI 163 v3 [orig:450 vect_i_22.2317 ] [450])
(parallel [
(reg:SI 2 s2 [503])
]))
(gdb) call debug_rtx(dst)
(reg/v:SI 2 s2 [orig:434 i ] [434])
(gdb) list 1635
1630 && HARD_REGISTER_P (dst))
1
[Bug fortran/94709] [OpenMP][OpenACC][!GCC$ attributes] No line truncation warning printed for directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94709 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:4ea769a91dfa9142235c457b9db6ecc4e55072c4 commit r10-7872-g4ea769a91dfa9142235c457b9db6ecc4e55072c4 Author: Tobias Burnus Date: Wed Apr 22 14:07:55 2020 +0200 [Fortran] Truncate warn with OpenMP/OpenACC/!GCC$ (PR94709) While '!$' with -fopenmp unsets too often load_line's seen_comment flag, this only affects warnings; for trunction warnings, gfc_next_char_literal re-handles the directives correctly. In terms of missed warnings, a directive that is completely in the truncated part is not diagnosted (as it starts with a '!'). PR fortran/94709 * scanner.c (load_line): In fixed form, also treat 'C' as comment and 'D'/'d' only with -fd-lines-as-comments. Treat '!$' with -fopenmp, '!$acc' with -fopenacc and '!GCC$' as non-comment to permit and truncation warnings. PR fortran/94709 * gfortran.dg/gomp/warn_truncated.f: New. * gfortran.dg/gomp/warn_truncated.f90: New.
[Bug fortran/94709] [OpenMP][OpenACC][!GCC$ attributes] No line truncation warning printed for directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94709 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tobias Burnus --- FIXED for GCC 10 / trunk.
[Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.5 |10.0 Priority|P3 |P4
[Bug target/94248] [amdgcn] Doesn't build with RTL checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94248 --- Comment #7 from Andrew Stubbs --- I'd rather remove the whole if branch, but given you've tested this already then it's probably the best short term fix. Please go ahead.
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 Jakub Jelinek changed: What|Removed |Added Priority|P2 |P1 Target Milestone|8.5 |10.0
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug target/94711] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711 Bug ID: 94711 Summary: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ABI, wrong-code Severity: blocker Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: jakub at gcc dot gnu.org, ktkachov at gcc dot gnu.org, matmal01 at gcc dot gnu.org, mpolacek at gcc dot gnu.org, rearnsha at gcc dot gnu.org, redi at gcc dot gnu.org, rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org Depends on: 94383 Blocks: 94704, 94706, 94707 Target Milestone: --- Target: aarch64-*-linux +++ This bug was initially created as a clone of Bug #94383 +++ The same issue applies to 32-bit ARM too. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 [Bug 94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704 [Bug 94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 [Bug 94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 [Bug 94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Blocks|94704, 94706, 94707 | Target|aarch64-*-linux |arm-*-linux Target Milestone|--- |10.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704 [Bug 94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 [Bug 94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 [Bug 94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-04-22 CC||krebbel at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed with: $ ~/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc pr94710.c --save-temps pr94710.s: Assembler messages: pr94710.s:17: Error: operand out of range (4 is not between 0 and 3) .LCFI1: vspltisw 1,0 vspltisw 0,0 xxsldwi 0,32,33,4 < THIS IS THE INSTRUCTION xxlor 34,0,0 addi 1,31,48 $ /usr/bin/powerpc64le-suse-linux-as --version GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.34.0.20200325-1
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #17 from Andreas Schwab --- With that patch all struct-layout-1.exp tests pass.
[Bug target/94279] [amdgcn] internal compiler error: RTL check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at rtl.h:2379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94279
--- Comment #2 from Richard Biener ---
set_noop_p is clearly buggy here, expecting a constant selector
/* It is a NOOP if destination overlaps with selected src vector
elements. */
if (GET_CODE (src) == VEC_SELECT
&& REG_P (XEXP (src, 0)) && REG_P (dst)
&& HARD_REGISTER_P (XEXP (src, 0))
&& HARD_REGISTER_P (dst))
{
int i;
rtx par = XEXP (src, 1);
rtx src0 = XEXP (src, 0);
poly_int64 c0 = rtx_to_poly_int64 (XVECEXP (par, 0, 0));
poly_int64 offset = GET_MODE_UNIT_SIZE (GET_MODE (src0)) * c0;
for (i = 1; i < XVECLEN (par, 0); i++)
if (maybe_ne (rtx_to_poly_int64 (XVECEXP (par, 0, i)), c0 + i))
return 0;
return
REG_CAN_CHANGE_MODE_P (REGNO (dst), GET_MODE (src0), GET_MODE (dst))
&& simplify_subreg_regno (REGNO (src0), GET_MODE (src0),
offset, GET_MODE (dst)) == (int) REGNO (dst);
}
both for c0 and the XVECEXP in the loop it needs to check whether it actually
is a constant. Like via poly_int_rtx_p. A patch like along that line
is pre-approved. Broken since introduction of that code
in commit 8c8952918b75
[Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #1 from Jakub Jelinek ---
Completely untested guess:
--- gcc/config/s390/s390.c.jj 2020-03-14 08:14:47.097741411 +0100
+++ gcc/config/s390/s390.c 2020-04-22 14:24:17.980091105 +0200
@@ -11917,7 +11917,8 @@ s390_function_arg_vector (machine_mode m
for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
{
- if (TREE_CODE (field) != FIELD_DECL)
+ if (TREE_CODE (field) != FIELD_DECL
+ || cxx17_empty_base_field_p (field))
continue;
if (single == NULL_TREE)
@@ -11967,7 +11968,8 @@ s390_function_arg_float (machine_mode mo
for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
{
- if (TREE_CODE (field) != FIELD_DECL)
+ if (TREE_CODE (field) != FIELD_DECL
+ || cxx17_empty_base_field_p (field))
continue;
if (single == NULL_TREE)
(on top of the today posted cxx17_empty_base_field_p patch).
Though, of course that doesn't handle the -Wpsabi part if s390{,x} wants to
emit such diagnostics; for that the functions or their caller should determine
if they would make a different ABI decisions if the field wouldn't be skipped.
[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690 --- Comment #5 from Tobias Burnus --- (In reply to Tobias Burnus from comment #0) > * pr66199-9.f90 – gives an ICE in omp_add_variable > (if 'lastprivate' is permitted, otherwise, it is rejected.) Reduced test case (needs patch to permit lastprivate in OMP_DISTRIBUTE_CLAUSES): internal compiler error: in omp_add_variable, at gimplify.c:6958 integer function f2 () implicit none integer :: d, a ! !$omp teams shared(d) shared(a) !$omp distribute lastprivate(d) do d = 1, 2 a = d * 5 end do ! !$omp end teams f2 = d end ["omp teams" is not needed for the ICE, but without the C testcase fails with: "lastprivate variable ‘d’ is private in outer context"] The problem is (original dump): #pragma omp distribute private(d) lastprivate(d) Mixing 'private' + 'lastprivate' is bad. * * * The private is added in gfc_trans_omp_do, as dovar_found == 0. We have: * clauses->lists[OMP_LIST_LASTPRIVATE]->sym->name $41 = 0x778c0128 "d" * clauses->lists[OMP_LIST_PRIVATE] == NULL And the code (in gfc_trans_omp_do): if (op != EXEC_OMP_DISTRIBUTE) for (n = clauses->lists[(op == EXEC_OMP_SIMD && collapse == 1) ? OMP_LIST_LINEAR : OMP_LIST_LASTPRIVATE]; ... else if (n == NULL && op != EXEC_OMP_SIMD) for (n = clauses->lists[OMP_LIST_PRIVATE]; n != NULL; n = n->next)
[Bug c/94712] New: aarch64：Adjust some testcases for ilp32 option conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94712 Bug ID: 94712 Summary: aarch64：Adjust some testcases for ilp32 option conflict Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: duanbo3 at huawei dot com Target Milestone: --- Target: aarch64 After patch aarch64：Add an error message in large code model for ilp32 https://gcc.gnu.org/g:6c0ab626113ef20ee2986cb8a102b5394aeb888a a few tests are failing when running the testsuite with -mabi=ilp32: gcc.target/aarch64/pr63304_1.c (test for excess errors) gcc.target/aarch64/pr63304_1.c scan-assembler-times adrp 6 gcc.target/aarch64/pr70120-2.c (test for excess errors) gcc.target/aarch64/pr94530.c (test for excess errors) gcc.target/aarch64/reload-valid-spoff.c (test for excess errors) should adjust some testcases for the option conflict.
[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690 --- Comment #6 from Tobias Burnus --- (In reply to Tobias Burnus from comment #5) > The problem is (original dump): > #pragma omp distribute private(d) lastprivate(d) If one does not add the 'private(d)', it works: 'private(d)' is added by the ME only if 'lastprivate(d)' is not present. Namely, the following patch works – but the question is, whence to add a clause. (There is more such code.) --- a/gcc/fortran/trans-openmp.c +++ b/gcc/fortran/trans-openmp.c @@ -4312,7 +4312,5 @@ gfc_trans_omp_do (gfc_code *code, gfc_exec_op op, stmtblock_t *pblock, dovar_found = 2; - } - else - tmp = build_omp_clause (input_location, OMP_CLAUSE_PRIVATE); OMP_CLAUSE_DECL (tmp) = dovar_decl; omp_clauses = gfc_trans_add_clause (tmp, omp_clauses); + } }
[Bug analyzer/94713] New: Analyzer is buggy on uninitialized pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713
Bug ID: 94713
Summary: Analyzer is buggy on uninitialized pointer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Test with: gcc-10 (Debian 10-20200418-1) 10.0.1 20200418 (experimental) [master
revision 27c171775ab:4c277008be0:c5bac7d127f288fd2f8a1f15c3f30da5903141c6]
Consider:
void f1 (int *);
void f2 (int);
int foo (void)
{
int *p;
f1 (p);
f2 (p[0]);
return 0;
}
zira% gcc-10 -Wall tst2.c -O3 -c -fanalyzer
tst2.c: In function ‘foo’:
tst2.c:8:3: warning: ‘p’ is used uninitialized in this function
[-Wuninitialize]
8 | f1 (p);
| ^~
tst2.c:9:3: warning: use of uninitialized value ‘p’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
9 | f2 (p[0]);
| ^
‘foo’: event 1
|
|
-Wuninitialize works as expected, but -Wanalyzer-use-of-uninitialized-value
outputs the warning message on p[0], though the ‘p’ in the warning message is
correct.
If I comment out the "f2 (p[0]);" line, I no longer get the warning from the
analyzer, which means that it is the p[0] that triggers the warning instead of
p.
[Bug analyzer/94714] New: Analyzer: no warning on access of an uninitialized variable of automatic storage duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714
Bug ID: 94714
Summary: Analyzer: no warning on access of an uninitialized
variable of automatic storage duration
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Test with: gcc-10 (Debian 10-20200418-1) 10.0.1 20200418 (experimental) [master
revision 27c171775ab:4c277008be0:c5bac7d127f288fd2f8a1f15c3f30da5903141c6]
Consider:
#include
int main (void)
{
int *p;
int i;
p = &i;
printf ("%d\n", p[0]);
return 0;
}
With "gcc-10 tst.c -o tst -O3 -fanalyzer", I do not get any warning from the
analyzer, though p[0] is uninitialized. Ditto without optimizations (in which
case, running the program really shows that i is uninitialized).
[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690 --- Comment #7 from Tobias Burnus --- If no lastprivate is available, it is added in gimplify.c's gimplify_omp_for, line 11759: for (i = 0; i < TREE_VEC_LENGTH (OMP_FOR_INIT (for_stmt)); i++) ... if (is_doacross) ... else if (ort == ORT_SIMD) ... else if (omp_is_private (gimplify_omp_ctxp, decl, 0)) ... else omp_add_variable (gimplify_omp_ctxp, decl, GOVD_PRIVATE | GOVD_SEEN);
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544305.html
[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694 --- Comment #24 from Jakub Jelinek --- The dec_math.f90 FAILs are at all opt levels: ( ) qsind( 60.00) 0.866025403784438646763723170753 0.866025403784438596588302061718 Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG STOP 1 If I preprocess trigd.c before/after the #c21 patch, the difference (appart from lines/whitespace) are: - (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f))); + (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06)); - (x = 8.66025388e-01f); + (x = 8.66025388e-01); - (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f))); + (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06)); - (x = 8.66025388e-01f); + (x = 8.66025388e-01); ... - static const volatile GFC_REAL_10 tiny = 0x1.p-16400L; + static const volatile GFC_REAL_10 tiny = 0x1.p-16400l; ... - (x = 8.66025403784438646787e-01L); + (x = 8.66025403784438646787e-01); ... - (x = fmal(((x)), (1.74532925229868851602e-02L), ((x) * -3.04358939097084072823e-12L))); + (x = fmal((x), 1.74532925229868851602e-02, (x) * -3.04358939097084072823e-12)); ... - (x = 8.66025403784438646763723170752936183e-01q); + (x = 8.66025403784438646763723170752936183e-01); etc., so all that matters is that some float suffixes (f, , L, q) are gone from the constants (and the L -> l change on tiny and a few others), which of course matters a lot.
[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694 --- Comment #25 from Fritz Reese --- (In reply to Jakub Jelinek from comment #24) > The dec_math.f90 FAILs are at all opt levels: > ( ) qsind( 60.00) > 0.866025403784438646763723170753 0.866025403784438596588302061718 > Note: The following floating-point exceptions are signalling: > IEEE_INVALID_FLAG > STOP 1 > > If I preprocess trigd.c before/after the #c21 patch, the difference (appart > from lines/whitespace) are: > - (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f))); > + (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06)); > > - (x = 8.66025388e-01f); > + (x = 8.66025388e-01); > > - (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f))); > + (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06)); > > - (x = 8.66025388e-01f); > + (x = 8.66025388e-01); > > ... > - static const volatile GFC_REAL_10 tiny = 0x1.p-16400L; > + static const volatile GFC_REAL_10 tiny = 0x1.p-16400l; > ... > - (x = 8.66025403784438646787e-01L); > + (x = 8.66025403784438646787e-01); > ... > - (x = fmal(((x)), (1.74532925229868851602e-02L), ((x) * > -3.04358939097084072823e-12L))); > + (x = fmal((x), 1.74532925229868851602e-02, (x) * > -3.04358939097084072823e-12)); > ... > - (x = 8.66025403784438646763723170752936183e-01q); > + (x = 8.66025403784438646763723170752936183e-01); > > etc., so all that matters is that some float suffixes (f, , L, q) are gone > from the constants (and the L -> l change on tiny and a few others), which > of course matters a lot. Ah, yes, I missed some LITERAL(x) wrappings. Will fix and post an updated patch shortly.
[Bug target/93053] [9 Regression] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #15 from CVS Commits --- The releases/gcc-9 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:bfe912a35c0c39a623ba6e0066b6010e0ade0f5e commit r9-8525-gbfe912a35c0c39a623ba6e0066b6010e0ade0f5e Author: Andre Vieira Date: Wed Apr 22 15:16:20 2020 +0100 aarch64: Fix bootstrap with old binutils [PR93053] As reported in the PR, GCC 10 (and also 9.3.1 but not 9.3.0) fails to build when using older binutils which lack LSE support, because those instructions are used in libgcc. Thanks to Kyrylo's hint, the following patches (hopefully) allow it to build even with older binutils by using .inst directive if LSE support isn't available in the assembler. 2020-04-22 Andre Vieira Backport from mainline. 2020-04-15 Jakub Jelinek PR target/93053 * configure.ac (LIBGCC_CHECK_AS_LSE): Add HAVE_AS_LSE checking. * config/aarch64/lse.S: Include auto-target.h, if HAVE_AS_LSE is not defined, use just .arch armv8-a. (B, M, N, OPN): Define. (COMMENT): New .macro. (CAS, CASP, SWP, LDOP): Use .inst directive if HAVE_AS_LSE is not defined. Otherwise, move the operands right after the glue? and comment out operands where the macros are used. * configure: Regenerated. * config.in: Regenerated.
[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694 Fritz Reese changed: What|Removed |Added Attachment #48332|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #26 from Fritz Reese --- Created attachment 48351 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48351&action=edit Patch to protect trigd functions based on system availability (v2) I've attached a new patch for trigd. Below is the delta on top of the old patch. I'm building and testing now. Jakub, if you concur, I will commit these patches and close the PR after successful testing. diff --git a/libgfortran/intrinsics/trigd_lib.inc b/libgfortran/intrinsics/trigd_lib.inc index 66e22c3845e..e90f9deaa5a 100644 --- a/libgfortran/intrinsics/trigd_lib.inc +++ b/libgfortran/intrinsics/trigd_lib.inc @@ -128,9 +128,9 @@ PIO180L -- lower bits of pi/180 for FMA #define mpz_cmp_ui(x, y) ((x) - (y)) #define mpz_divisible_ui_p(n, d) ((n) % (d) == 0) -#define D2R(x) (x = FMA((x), PIO180H, (x) * PIO180L)) +#define D2R(x) (x = FMA((x), PIO180H_LITERAL, (x) * PIO180L_LITERAL)) -#define SET_COSD30(x) (x = COSD30) +#define SET_COSD30(x) (x = COSD30_LITERAL) #ifdef SIND extern FTYPE SIND (FTYPE);
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c3a34659036b55fa36a5355fdd67133f427eeb2d
commit r10-7881-gc3a34659036b55fa36a5355fdd67133f427eeb2d
Author: Jakub Jelinek
Date: Wed Apr 22 16:44:42 2020 +0200
calls: Introduce cxx17_empty_base_field_p [PR94383]
As multiple targets are affected apparently, I believe at least
aarch64, arm, powerpc64le, s390{,x} and ia64,
I think we should have a middle-end predicate for this, so that if we need
to tweak it, we can do it in one spot.
2020-04-22 Jakub Jelinek
PR target/94383
* calls.h (cxx17_empty_base_field_p): Declare.
* calls.c (cxx17_empty_base_field_p): Define.
[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706 --- Comment #18 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1be62528078aef241fef6d2fe1cbc8e8e5379115 commit r10-7882-g1be62528078aef241fef6d2fe1cbc8e8e5379115 Author: Jakub Jelinek Date: Wed Apr 22 16:47:58 2020 +0200 ia64: Fix C++14 vs. C++17 ABI issue on ia64 [PR94706] ia64 seems to be affected too, but the backend doesn't have any -Wpsabi warnings and I'm not sure if we really need them for an (almost?) dead target. 2020-04-22 Jakub Jelinek PR target/94706 * config/ia64/ia64.c (hfa_element_mode): Ignore cxx17_empty_base_field_p fields.
[Bug middle-end/91512] [10 Regression] Fortran compile time regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512 --- Comment #30 from Bill Seurer --- I tried -fno-inline-arg-packing and with that the time to build all of spec2017 is 28m43 versus 63m to 65m without. For my purposes this is fine BUT will using this option have some sort of performance effect when the tests are run?
[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694 --- Comment #27 from Jakub Jelinek --- (In reply to Fritz Reese from comment #26) > Created attachment 48351 [details] > Patch to protect trigd functions based on system availability (v2) > > I've attached a new patch for trigd. Below is the delta on top of the old > patch. With that incremental change, trigd.i differences look good to me during brief skimming. > I'm building and testing now. Jakub, if you concur, I will commit > these patches and close the PR after successful testing. I've already posted my patch to the mailing list, if somebody approves it, I'll check it in. I think we don't urgently need another round of aarch64-none-elf testing with the incremental patch, because for a target that doesn't have those cosl etc. functions in newlib ENABLE_SIND etc. will not be defined and so the incremental patch shouldn't change anything.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 Fritz Reese changed: What|Removed |Added CC||foreese at gcc dot gnu.org --- Comment #29 from Fritz Reese --- John, I wonder could you output your generated kinds.h? It will be in $GCCBUILD/stageN-/libgfortran/kinds.h if your build has made it far enough. If you have a functional gfortran you can also generate it with "$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to expose the core type which gfortran uses for REAL(16) according to the target. I'd also like to know the results of building with the two patches in pr94694. I think you should keep the target-specific portions of your patch, including mods to gcc/fortran/trans-types.c, but I think you should then be able to drop the changes to libgfortran/intrinsics/trigd.c and libgfortran/kinds-override.h.
[Bug c++/90448] [8/9/10 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 --- Comment #3 from Paolo Carlini --- This is already fixed in trunk: I'm adding the testcase and removingg the 10 Regression marker.
[Bug middle-end/94647] [10 Regression] bogus -Warray-bounds on strncpy into a larger member array from a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94647 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- I see on i686-linux and powerpc64-linux (latter with -m32): +FAIL: c-c++-common/Warray-bounds-2.c -Wc++-compat (test for warnings, line 192) +FAIL: c-c++-common/Warray-bounds-2.c -Wc++-compat (test for excess errors) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++11 (test for warnings, line 192) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++11 (test for excess errors) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++14 (test for warnings, line 192) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++14 (test for excess errors) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++17 (test for warnings, line 192) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++17 (test for excess errors) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++2a (test for warnings, line 192) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++2a (test for excess errors) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++98 (test for warnings, line 192) +FAIL: c-c++-common/Warray-bounds-2.c -std=gnu++98 (test for excess errors)
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 John David Anglin changed: What|Removed |Added Attachment #48331|0 |1 is obsolete|| --- Comment #30 from John David Anglin --- Created attachment 48352 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48352&action=edit Patch to fix float128 node selection on hpux Restore change to fix float128 builtins. Handle iround specially.
[Bug middle-end/94715] New: Squared multiplies are incorrectly signextended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94715
Bug ID: 94715
Summary: Squared multiplies are incorrectly signextended
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following example generates incorrect code with -O2:
unsigned long long f (int x)
{
unsigned int t = x * x;
return t;
}
On AArch64 I get:
mul w0, w0, w0
sxtw x0, w0
ret
It's correct if you do x * y or x * 100.
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r8-5623-gf151c9e1414c00e300c9385bc9512c3d9a481296
[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 #31 from dave.anglin at bell dot net --- Fritz, I have a build going with the patch which I just attached. I realized last night that the change I made to address the problem with iroundq was wrong. I should be able to answer your questions shortly. I haven't looked at the patches in pr94694 but I believe that configure should be able to detect the core type used for REAL(16) from gfortran. kinds-override.h seems like a hack to me.
[Bug middle-end/94647] [10 Regression] bogus -Warray-bounds on strncpy into a larger member array from a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94647 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:203f2b73e256c779a3ab73c5dc5efafd3d46f8e1 commit r10-7884-g203f2b73e256c779a3ab73c5dc5efafd3d46f8e1 Author: Martin Sebor Date: Wed Apr 22 09:30:37 2020 -0600 Fix an ILP32 failure. gcc/testsuite/ChangeLog: PR middle-end/94647 * c-c++-common/Warray-bounds-2.c: Replace a large value harcoded in an expected warning with a pattern.
[Bug c++/94716] New: Address of constexpr variable not usable in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94716
Bug ID: 94716
Summary: Address of constexpr variable not usable in constant
expression
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bluescarni at gmail dot com
Target Milestone: ---
The following code does not compile in GCC trunk:
-
template
inline constexpr char test_impl = 0;
template
inline constexpr auto *id = &test_impl;
int main() {
static_assert(id != id, "should not be equal");
}
-
The error message:
-
: In function 'int main()':
:8:27: error: non-constant condition for static assertion
8 | static_assert(id != id, "should not be equal");
| ^~~~
:8:27: error: '((& test_impl) != (& test_impl))' is not a
constant expression
Compiler returned: 1
-
See on godbolt:
https://godbolt.org/z/CS4D8B
Clang and MSVC accept the code.
[Bug c++/94691] ICE resolving deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94691 --- Comment #2 from Nathan Sidwell --- Created attachment 48353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48353&action=edit another case Attached another example of the same assert triggering
[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 #32 from John David Anglin --- Created attachment 48354 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48354&action=edit Header file This is kinds.h generated with gcc-8. Note we have "typedef long double GFC_REAL_16;". I'm attempting to change this to float128 so that we use libquadmath instead of the non existent support for long double.
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #3 from Jakub Jelinek ---
The first arg doesn't have to be constant:
typedef int __attribute__ ((__vector_size__ (16))) V;
typedef long __attribute__ ((__vector_size__ (16))) W;
void
foo (W *x)
{
*x = __builtin_shuffle (*x, (W){}, (W)(V){0, 0, -15, 0});
}
__builtin_shuffle is documented:
"The elements of MASK are considered modulo N in the single-operand case and
modulo 2*N in the two-operand case."
and as there are two operands, that means modulo 4, so the result should be
the same as
*x = __builtin_shuffle (*x, (W){}, (W){0, 1});
I think and thus a nop.
[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 #33 from dave.anglin at bell dot net --- On 2020-04-22 10:54 a.m., foreese at gcc dot gnu.org wrote: > If you have a functional gfortran you can also generate it with > "$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to > expose the core type which gfortran uses for REAL(16) according to the target. Looking at script, I see it has same logic to disambiguate long double and float128: 16) if [ $long_double_kind -eq 10 ]; then ctype="__float128" cplxtype="_Complex float __attribute__((mode(TC)))" suffix="q" else ctype="long double" cplxtype="complex long double" suffix="l" fi ;; It always selects long double when both are REAL(16).
[Bug c++/90448] [8/9/10 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 --- Comment #4 from CVS Commits --- The master branch has been updated by Paolo Carlini : https://gcc.gnu.org/g:183e9006cc0300257d6f74d573514ef86f78cb4e commit r10-7885-g183e9006cc0300257d6f74d573514ef86f78cb4e Author: Paolo Carlini Date: Wed Apr 22 18:05:18 2020 +0200 Add testcase of PR c++/90448, already fixed in trunk. PR c++/90448 * g++.dg/cpp1y/lambda-generic-variadic20.C: New.
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 --- Comment #6 from Bill Schmidt --- The ELFv2 ABI has a prominent note specifying: "Floating-point and vector aggregates that contain padding words and integer fields with a width of 0 should not be treated as homogeneous aggregates."
[Bug target/94707] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707 --- Comment #7 from Bill Schmidt --- ELF V1 does not have a concept of homogeneous aggregates.
[Bug target/92692] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692 --- Comment #25 from CVS Commits --- The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:0b65e477890b7fe7f47a3dd85975ab7ee09b0609 commit r8-10205-g0b65e477890b7fe7f47a3dd85975ab7ee09b0609 Author: Andre Vieira Date: Thu Apr 16 10:16:15 2020 +0100 Aarch64: Fix shrinkwrapping interactions with atomics (PR92692) 2020-04-16 Andre Vieira Backport from mainline 2020-01-17 Wilco Dijkstra PR target/92692 * config/aarch64/atomics.md (aarch64_compare_and_swap) Use epilogue_completed rather than reload_completed.
[Bug target/94368] [9 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:163e0d03f2cdc80de4968c4be4694cdaeaf47fcd commit r8-10212-g163e0d03f2cdc80de4968c4be4694cdaeaf47fcd Author: Andre Vieira Date: Thu Apr 16 10:16:17 2020 +0100 aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368] 2020-04-16 Andre Vieira Backport from mainline 2020-03-31 Jakub Jelinek PR target/94368 * config/aarch64/constraints.md (Uph): New constraint. * config/aarch64/atomics.md (cas_short_expected_imm): New mode attr. (aarch64_compare_and_swap): Use it instead of n in operand 2's constraint. * gcc.dg/pr94368.c: New test.
[Bug target/91833] [10 Regression] [AArch64] LSE atomics depends on glibc specific sys/auxv.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:5d44ad1e0a66651495ed964058cdd6db0d99d876 commit r8-10211-g5d44ad1e0a66651495ed964058cdd6db0d99d876 Author: Andre Vieira Date: Thu Apr 16 10:16:17 2020 +0100 aarch64: Configure for sys/auxv.h in libgcc for lse-init.c 2020-04-16 Andre Vieira Backport from mainline 2019-09-25 Richard Henderson PR target/91833 * config/aarch64/lse-init.c: Include auto-target.h. Disable initialization if !HAVE_SYS_AUXV_H. * configure.ac (AC_CHECK_HEADERS): Add sys/auxv.h. * config.in, configure: Rebuild.
[Bug target/90724] ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90724 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:69472d76d2456a447f61bc539bd6fe262c167bcf commit r8-10215-g69472d76d2456a447f61bc539bd6fe262c167bcf Author: Andre Vieira Date: Thu Apr 16 10:16:19 2020 +0100 re PR target/90724 (ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve) 2020-04-16 Andre Vieira Backport from mainline 2019-08-21 Prathamesh Kulkarni PR target/90724 * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): Force y in reg if it fails aarch64_plus_operand predicate.
[Bug target/93053] [9 Regression] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #16 from CVS Commits --- The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:a69a60c4969cea06c1d44b5e3e4970595041e510 commit r8-10213-ga69a60c4969cea06c1d44b5e3e4970595041e510 Author: Andre Vieira Date: Thu Apr 16 10:16:18 2020 +0100 aarch64: Fix bootstrap with old binutils [PR93053] As reported in the PR, GCC 10 (and also 9.3.1 but not 9.3.0) fails to build when using older binutils which lack LSE support, because those instructions are used in libgcc. Thanks to Kyrylo's hint, the following patches (hopefully) allow it to build even with older binutils by using .inst directive if LSE support isn't available in the assembler. 2020-04-16 Andre Vieira Backport from mainline 2020-04-15 Jakub Jelinek PR target/93053 * configure.ac (LIBGCC_CHECK_AS_LSE): Add HAVE_AS_LSE checking. * config/aarch64/lse.S: Include auto-target.h, if HAVE_AS_LSE is not defined, use just .arch armv8-a. (B, M, N, OPN): Define. (COMMENT): New .macro. (CAS, CASP, SWP, LDOP): Use .inst directive if HAVE_AS_LSE is not defined. Otherwise, move the operands right after the glue? and comment out operands where the macros are used. * configure: Regenerated. * config.in: Regenerated.
[Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94435 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:1dbd821ee74e6c234e61e25b0801a0b0949bcc67 commit r8-10214-g1dbd821ee74e6c234e61e25b0801a0b0949bcc67 Author: Andre Vieira Date: Thu Apr 16 10:16:18 2020 +0100 aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435] The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits invalid RTL. For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that fits into that mode) and x being SImode; for non-CONST_INT y it zero extends y into SImode and compares that against x, for CONST_INT y it zero extends y into SImode. The problem is that when the zero extended constant isn't usable directly, it forces it into a REG, but with y_mode mode, and then compares against y. That is wrong, because it should force it into a SImode REG and compare that way. 2020-04-16 Andre Vieira Backport from mainline 2020-04-02 Jakub Jelinek PR target/94435 * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to SImode. * gcc.target/aarch64/pr94435.c: New test.
