[Bug target/91823] [10 regression] r275959 breaks gcc.target/powerpc/altivec-32.c with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91823 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828 --- Comment #3 from Richard Biener --- Requiring 3.1.x is OK by now. SLES 12 has 3.1.2, only SLES 11 and older cannot fulfil this requirement.
[Bug tree-optimization/91830] New: Bogus -Warray-bounds warning compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830 Bug ID: 91830 Summary: Bogus -Warray-bounds warning compiling binutils Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- x86_64-linux, gcc r275988. /home/alan/src/binutils-gdb/bfd/mach-o.c: In function ‘bfd_mach_o_init_segment’: /home/alan/src/binutils-gdb/bfd/mach-o.c:3137:3: error: ‘strcpy’ offset 24 from the object at ‘cmd’ is out of the bounds of referenced subobject ‘segname’ with type ‘char[17]’ at offset 0 [-Werror=array-bounds] 3137 | strcpy (seg->segname, segname); | ^~ In file included from /home/alan/src/binutils-gdb/bfd/mach-o.c:26: /home/alan/src/binutils-gdb/bfd/mach-o.h:94:8: note: subobject ‘segname’ declared here 94 | char segname[BFD_MACH_O_SEGNAME_SIZE + 1]; |^~~
[Bug ipa/91831] New: [10 Regression] ICE in expand_expr_real_1, at expr.c:10062 after r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91831
Bug ID: 91831
Summary: [10 Regression] ICE in expand_expr_real_1, at
expr.c:10062 after r275982
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org, mjambor at suse dot cz
Target Milestone: ---
After the revision I see the following issue:
$ cat ice.C
struct A {
virtual void m_fn1();
};
struct B {
virtual void *m_fn2(int, int) = 0;
};
struct C : A, B {
void *m_fn2(int, int) { return this; }
};
void *fn1(B &p1) { return p1.m_fn2(0, 0); }
int main() {
C c;
fn1(c);
return 0;
}
$ gcc ice.C -O2 --param uninlined-thunk-insns=1000 -c
during RTL pass: expand
ice.C: In function ‘_ZThn8_N1C5m_fn2Eii.artificial_thunk.0’:
ice.C:8:9: internal compiler error: in expand_expr_real_1, at expr.c:10062
8 | void *m_fn2(int, int) { return this; }
| ^
0x6f5e79 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10062
0xcaace4 expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:281
0xcaace4 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/home/marxin/Programming/gcc/gcc/expr.c:7887
0xcb2627 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/marxin/Programming/gcc/gcc/expr.c:8783
0xca1c41 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:9993
0xb88fed expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:281
0xb88fed expand_return
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3639
0xb88fed expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3748
0xb88fed expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3875
0xb8e6d1 expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5915
0xb903d7 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6555
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug ipa/91831] [10 Regression] ICE in expand_expr_real_1, at expr.c:10062 after r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91831 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-20 CC||jamborm at gcc dot gnu.org Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug ipa/91832] New: [10 Regression] ICE in scan_expr_access, at ipa-sra.c:1695 since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91832
Bug ID: 91832
Summary: [10 Regression] ICE in scan_expr_access, at
ipa-sra.c:1695 since r275982
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Following is causing ICE:
$ cat ice.i
struct A1 {
char a1[1];
};
void fn2(char a);
void fn1(struct A1 *p1) {
fn2(p1->a1[-1]);
}
$ ./xgcc -B. -O2 ice.i -c
during IPA pass: sra
ice.i: In function ‘fn1’:
ice.i:9:1: internal compiler error: in scan_expr_access, at ipa-sra.c:1695
9 | }
| ^
0xb97f9e scan_expr_access
/home/marxin/Programming/gcc/gcc/ipa-sra.c:1695
0xb98787 scan_function
/home/marxin/Programming/gcc/gcc/ipa-sra.c:1859
0xb9a2a9 ipa_sra_summarize_function
/home/marxin/Programming/gcc/gcc/ipa-sra.c:2499
0xb9a532 ipa_sra_generate_summary
/home/marxin/Programming/gcc/gcc/ipa-sra.c:2549
0xcf8034 execute_ipa_summary_passes(ipa_opt_pass_d*)
/home/marxin/Programming/gcc/gcc/passes.c:2189
0x99b765 ipa_passes
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2505
0x99b765 symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2618
0x99d82c symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2595
0x99d82c symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2868
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug ipa/91832] [10 Regression] ICE in scan_expr_access, at ipa-sra.c:1695 since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91832 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-20 Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug fortran/78260] ICE in gimplify_expr, at gimplify.c:11939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78260 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- (In reply to Gerhard Steinmetz from comment #1) > Another name clash : This one is fixed with GCC 9: 5 | !$acc declare present(s) |1 Error: Object ‘s’ is not a variable at (1) (In reply to Gerhard Steinmetz from comment #0) > With invalid code and option -fopenacc, affects version 6 and 7 : This one still crashes with the trunk and on the openacc-gcc-9 branch.
[Bug testsuite/91821] [10 regression] r275928 breaks gcc.target/powerpc/sad-vectorize-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91821 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #2 from Richard Biener --- I have a patch.
[Bug bootstrap/91833] New: [AArch64] LSE atomics depends on glibc specific sys/auxv.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833 Bug ID: 91833 Summary: [AArch64] LSE atomics depends on glibc specific sys/auxv.h Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: x86_64-linux-gnu Target: aarch64-none-elf Build: x86_64-linux-gnu Hi. libgcc/config/aarch64/lse-init.c includes (in order to determine hardware features). As that is a glibc specific header, its presence should be checked. If the header is not provided by the used (target) libc implementation, bootstrapping will fail.
[Bug tree-optimization/91822] [10 Regression] FAIL: gcc.dg/pr88031.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91822 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Sep 20 08:35:59 2019 New Revision: 275990 URL: https://gcc.gnu.org/viewcvs?rev=275990&root=gcc&view=rev Log: 2019-09-20 Richard Biener PR tree-optimization/91822 * tree-vectorizer.h (vectorizable_condition): Restore for_reduction parameter. * tree-vect-loop.c (vectorizable_reduction): Adjust asserts for reduc_index in nested cycles, adjust vectorizable_condition calls. * tree-vect-stmts.c (vectorizable_condition): Restore for_reduction parameter. (vect_analyze_stmt): Adjust. (vect_transform_stmt): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug bootstrap/91834] New: [AArch64] LSE atomics, ILP32 warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834 Bug ID: 91834 Summary: [AArch64] LSE atomics, ILP32 warnings Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: x86_64-linux-gnu Target: aarch64-none-elf Build: x86_64-linux-gnu Hi. libgcc/config/aarch64/lse.S produces the following warning when doing an ILP32 build, which is then repeated multiple times. This is because w(tmp1) and s(tmp1) point to the same register. I presume the warning itself is not bogus. libgcc/config/aarch64/lse.S:230: Warning: unpredictable: identical transfer and status registers --`stlxr w17,w17,[x1] 101 #define w(N)glue2(w, N) 102 #if SIZE < 8 103 # define s(N) w(N) 104 #else 105 # define s(N) x(N) 106 #endif ... 230 STXRw(tmp1), s(tmp1), [x1] I did not study the LSE code further, as I don't know if this feature is expected to work with ILP32 (as in perhaps not scheduled for release).
[Bug tree-optimization/91822] [10 Regression] FAIL: gcc.dg/pr88031.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91822 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug rtl-optimization/88751] Performance regression reload vs lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88751 --- Comment #7 from Andreas Krebbel --- Author: krebbel Date: Fri Sep 20 09:03:44 2019 New Revision: 275991 URL: https://gcc.gnu.org/viewcvs?rev=275991&root=gcc&view=rev Log: Fix PR88751 This patch implements a small improvement for the heuristic in lra which decides when it has to activate the simpler register allocation algorithm. gcc/ChangeLog: 2019-09-20 Andreas Krebbel Backport from mainline 2019-06-06 Andreas Krebbel PR rtl-optimization/88751 * ira.c (ira): Use the number of the actually referenced registers when calculating the threshold. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/ira.c
[Bug c/91815] questionable error on type definition at file scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91815 --- Comment #6 from Eric Botcazou --- Author: ebotcazou Date: Fri Sep 20 09:11:20 2019 New Revision: 275992 URL: https://gcc.gnu.org/viewcvs?rev=275992&root=gcc&view=rev Log: PR c/91815 * c-decl.c (pushdecl): In C detect duplicate declarations across scopes of identifiers in the external scope only for variables and functions. Added: trunk/gcc/testsuite/gcc.dg/typedef-var-1.c trunk/gcc/testsuite/gcc.dg/typedef-var-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/91815] questionable error on type definition at file scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91815 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #7 from Eric Botcazou --- Thanks, patch applied.
[Bug bootstrap/91834] [AArch64] LSE atomics, ILP32 warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834 --- Comment #1 from Andrew Pinski --- >libgcc/config/aarch64/lse.S:230: Warning: unpredictable: identical transfer >and status registers --`stlxr w17,w17,[x1] It is unpredictable even in the LP64 case of w17, x17 too.
[Bug bootstrap/91834] [AArch64] LSE atomics, ILP32 warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834 --- Comment #2 from Andrew Pinski --- >I presume the warning itself is not bogus. The warning is correct. According to the ARM ARM. This patch should fix the issue but it is untested: diff --git a/libgcc/config/aarch64/lse.S b/libgcc/config/aarch64/lse.S index a5f6673596c..c7979382ad7 100644 --- a/libgcc/config/aarch64/lse.S +++ b/libgcc/config/aarch64/lse.S @@ -227,8 +227,8 @@ STARTFN NAME(LDNM) 8: mov s(tmp0), s(0) 0: LDXRs(0), [x1] OP s(tmp1), s(0), s(tmp0) - STXRw(tmp1), s(tmp1), [x1] - cbnzw(tmp1), 0b + STXRw(tmp2), s(tmp1), [x1] + cbnzw(tmp2), 0b ret ENDFN NAME(LDNM) Thanks, Andrew Pinski
[Bug target/91834] [10 Regression ] [AArch64] LSE atomics, warnings due to unpredictable behavior with strx and the same register for s and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-20 CC||pinskia at gcc dot gnu.org Component|bootstrap |target Target Milestone|--- |10.0 Summary|[AArch64] LSE atomics, |[10 Regression ] [AArch64] |ILP32 warnings |LSE atomics, warnings due ||to unpredictable behavior ||with strx and the same ||register for s and t Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug rtl-optimization/88751] Performance regression reload vs lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88751 --- Comment #8 from Andreas Krebbel --- Author: krebbel Date: Fri Sep 20 09:23:50 2019 New Revision: 275993 URL: https://gcc.gnu.org/viewcvs?rev=275993&root=gcc&view=rev Log: Fix PR88751 This patch implements a small improvement for the heuristic in lra which decides when it has to activate the simpler register allocation algorithm. gcc/ChangeLog: 2019-09-20 Andreas Krebbel Backport from mainline 2019-06-06 Andreas Krebbel PR rtl-optimization/88751 * ira.c (ira): Use the number of the actually referenced registers when calculating the threshold. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/ira.c
[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 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0
[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 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-20 CC||rth at gcc dot gnu.org Component|bootstrap |target Summary|[AArch64] LSE atomics |[10 Regression] [AArch64] |depends on glibc specific |LSE atomics depends on |sys/auxv.h |glibc specific sys/auxv.h Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Yes auxv.h only exists in glibc and maybe some other libcs but not in newlib.
[Bug fortran/89103] Allow blank format items in format strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89103 MarkEggleston changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from MarkEggleston --- Patch committed by Jerry DeLisle
[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #12 from Eric Botcazou --- Author: ebotcazou Date: Fri Sep 20 09:42:40 2019 New Revision: 275994 URL: https://gcc.gnu.org/viewcvs?rev=275994&root=gcc&view=rev Log: PR target/91269 * config/sparc/sparc.h (HARD_REGNO_CALLER_SAVE_MODE): Define. Added: trunk/gcc/testsuite/gcc.dg/pr91269.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.h trunk/gcc/testsuite/ChangeLog
[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #13 from Eric Botcazou --- Author: ebotcazou Date: Fri Sep 20 09:45:26 2019 New Revision: 275995 URL: https://gcc.gnu.org/viewcvs?rev=275995&root=gcc&view=rev Log: PR target/91269 * config/sparc/sparc.h (HARD_REGNO_CALLER_SAVE_MODE): Define. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr91269.c - copied unchanged from r275994, trunk/gcc/testsuite/gcc.dg/pr91269.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/sparc/sparc.h branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 MarkEggleston changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from MarkEggleston --- https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=274744
[Bug fortran/89078] [meta-bug] Improve the gfortran manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078 Bug 89078 depends on bug 89236, which changed state. Bug 89236 Summary: Intrinsic documentation changes for intrinsics affected by GNU extension https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/63944] [DR413] Partial overriding of nonconstant struct/union initializers with designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63944 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #8 from Eric Botcazou --- What about at least detecting the problematic pattern and issuing a warning that the DR is not implemented in the compiler yet?
[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Eric Botcazou --- This should compile again.
[Bug testsuite/91821] [10 regression] r275928 breaks gcc.target/powerpc/sad-vectorize-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91821 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug testsuite/91821] [10 regression] r275928 breaks gcc.target/powerpc/sad-vectorize-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91821 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Sep 20 09:54:54 2019 New Revision: 275996 URL: https://gcc.gnu.org/viewcvs?rev=275996&root=gcc&view=rev Log: 2019-09-20 Richard Biener PR tree-optimization/91821 * tree-vect-loop.c (check_reduction_path): Check we can compute reduc_idx. (vect_is_simple_reduction): Set STMT_VINFO_REDUC_IDX. * tree-vect-patterns.c (vect_reassociating_reduction_p): Return operands in canonical order. * tree-vectorizer.c (vec_info::new_stmt_vec_info): Initialize STMT_VINFO_REDUC_IDX. * tree-vectorizer.h (_stmt_vec_info::reduc_idx): New. (STMT_VINFO_REDUC_IDX): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-patterns.c trunk/gcc/tree-vectorizer.c trunk/gcc/tree-vectorizer.h
[Bug fortran/89240] Discrepancy in the return kind of MAX and MIN between all literal input parameters and input parameters that are variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89240 MarkEggleston changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from MarkEggleston --- Behaviour matches documentation. Withdrawn as it extends non-standard behaviour which is undesirable.
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 MarkEggleston changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from MarkEggleston --- Expanding the scope of GNU extensions is undesirable.
[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683 --- Comment #21 from Kito Cheng --- Author: kito Date: Fri Sep 20 10:41:51 2019 New Revision: 275997 URL: https://gcc.gnu.org/viewcvs?rev=275997&root=gcc&view=rev Log: RISC-V: Fix more splitters accidentally calling gen_reg_rtx. PR target/91683 * config/riscv/riscv-protos.h (riscv_split_symbol): New bool parameter. (riscv_move_integer): Likewise. * config/riscv/riscv.c (riscv_split_integer): Pass FALSE for new riscv_move_integer arg. (riscv_legitimize_move): Likewise. (riscv_force_temporary): New parameter in_splitter. Don't call force_reg if true. (riscv_unspec_offset_high): Pass FALSE for new riscv_force_temporary arg. (riscv_add_offset): Likewise. (riscv_split_symbol): New parameter in_splitter. Pass to riscv_force_temporary. (riscv_legitimize_address): Pass FALSE for new riscv_split_symbol arg. (riscv_move_integer): New parameter in_splitter. New local can_create_psuedo. Don't call riscv_split_integer or force_reg when in_splitter TRUE. (riscv_legitimize_const_move): Pass FALSE for new riscv_move_integer, riscv_split_symbol, and riscv_force_temporary args. * config/riscv/riscv.md (low+1): Pass TRUE for new riscv_move_integer arg. (low+2): Pass TRUE for new riscv_split_symbol arg. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/riscv/riscv-protos.h branches/gcc-9-branch/gcc/config/riscv/riscv.c branches/gcc-9-branch/gcc/config/riscv/riscv.md
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
FeRD changed:
What|Removed |Added
CC||ferdnyc at gmail dot com
--- Comment #7 from FeRD ---
(In reply to Eric Gallager from comment #5)
> We should probably
> choose one of the bugs in this web of related bugs and choose one to use as
> the base bug and mark the rest as duplicates, but idk which one...
If you're taking votes from the "peanut gallery", I vote this one, as it's the
only one that even hints at a poorly-disseminated fact: That -no-integrated-cpp
serves as an easy workaround for this issue on affected versions, at the slight
expense of some additional compile time.
In our own CMake project, we've added the following config, to great effect:
Work around a GCC < 9 bug with handling of _Pragma() in macros
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
if ((${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU") AND
(${CMAKE_CXX_COMPILER_VERSION} VERSION_LESS "9.0.0"))
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -no-integrated-cpp")
endif()
[Bug fortran/89348] Fortran Command Options documentation fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89348 MarkEggleston changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from MarkEggleston --- Committed. https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=274958
[Bug target/91814] [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91814 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Sep 20 11:14:34 2019 New Revision: 275998 URL: https://gcc.gnu.org/viewcvs?rev=275998&root=gcc&view=rev Log: 2019-09-20 Richard Biener Uros Bizjak PR target/91814 * config/i386/i386-features.c (gen_gpr_to_xmm_move_src): Revert previous change. (general_scalar_chain::convert_op): Force not suitable memory operands to a register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-features.c
[Bug ipa/91835] New: [10 regression] ipa-sra in section names breaks with Solaris/x86 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91835 Bug ID: 91835 Summary: [10 regression] ipa-sra in section names breaks with Solaris/x86 as Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11 The introduction of the IPA-SRA patch (r275982) badly broke LTO when using the Solaris/x86 as. Many (all?) LTO tests FAIL like this: FAIL: gcc.c-torture/compile/2105-1.c -O2 -flto -flto-partition=none (test for excess errors) Excess errors: Assembler: 2105-1.c "/var/tmp//ccaW7VHa.s", line 35 : Syntax error Near line: ".section .gnu.lto_.ipa-sra.e03463101918c5a8,#exclude" Section names can only consist of letters and digits, where '_' and '.' are also considered as letters. I'm currently trying a patch that changes gcc/lto-section-in.c (lto_section_name) to use "ipa_sra" instead of "ipa-sra", following all other LTO section names that use the '_' form.
[Bug ipa/91835] [10 regression] ipa-sra in section names breaks with Solaris/x86 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91835 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug ipa/91835] [10 regression] ipa-sra in section names breaks with Solaris/x86 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91835 --- Comment #1 from Richard Biener --- If that works it's a pre-approved change.
[Bug ipa/91832] [10 Regression] ICE in scan_expr_access, at ipa-sra.c:1695 since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91832 --- Comment #1 from Richard Biener --- negative offset can indeed happen. Valid cases would be hidden inside pointer-based MEM_REFs though, from code like p = p - 4; ... = *p; which we'd represent as MEM[p, -4]
[Bug tree-optimization/91830] Bogus -Warray-bounds warning compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830 Richard Biener changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Richard Biener --- Can you provide at least preprocessed source?
[Bug ipa/91836] New: [10 Regression] Speed regression of 525.x264_r with -Ofast -march=native since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91836 Bug ID: 91836 Summary: [10 Regression] Speed regression of 525.x264_r with -Ofast -march=native since r275982 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Seen on the graphs and I verified that locally with train run on znver1: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=35.407.0&plot.1=32.377.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug ipa/91836] [10 Regression] Speed regression of 525.x264_r with -Ofast -march=native since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91836 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-9-20 Known to work||9.2.0 Target Milestone|--- |10.0 Known to fail||10.0
[Bug rtl-optimization/88751] Performance regression reload vs lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88751 --- Comment #9 from Andreas Krebbel --- Author: krebbel Date: Fri Sep 20 12:18:26 2019 New Revision: 276000 URL: https://gcc.gnu.org/viewcvs?rev=276000&root=gcc&view=rev Log: Fix PR88751 This patch implements a small improvement for the heuristic in lra which decides when it has to activate the simpler register allocation algorithm. gcc/ChangeLog: 2019-09-20 Andreas Krebbel Backport from mainline 2019-06-06 Andreas Krebbel PR rtl-optimization/88751 * ira.c (ira): Use the number of the actually referenced registers when calculating the threshold. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/ira.c
[Bug c++/91837] New: Wrong code with -ftree-loop-vectorize and -march=skylake-avx512 on some Intel machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91837 Bug ID: 91837 Summary: Wrong code with -ftree-loop-vectorize and -march=skylake-avx512 on some Intel machines Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dan.cooke89 at gmail dot com Target Milestone: --- See my question on StackOverflow: https://stackoverflow.com/questions/58026153/why-does-march-native-corrupt-my-program?noredirect=1#comment102457501_58026153
[Bug ipa/91836] [10 Regression] Speed regression of 525.x264_r with -Ofast -march=native since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91836 --- Comment #1 from Richard Biener --- It's likely been one of the vectorizer changes and fixed by 2019-09-20 Richard Biener PR tree-optimization/91821 * tree-vect-loop.c (check_reduction_path): Check we can compute reduc_idx. (vect_is_simple_reduction): Set STMT_VINFO_REDUC_IDX. * tree-vect-patterns.c (vect_reassociating_reduction_p): Return operands in canonical order. * tree-vectorizer.c (vec_info::new_stmt_vec_info): Initialize STMT_VINFO_REDUC_IDX. * tree-vectorizer.h (_stmt_vec_info::reduc_idx): New. (STMT_VINFO_REDUC_IDX): Likewise.
[Bug c++/91837] Wrong code with -ftree-loop-vectorize and -march=skylake-avx512 on some Intel machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91837
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
--- Comment #1 from Richard Biener ---
For reference:
#include
#include
#include
#include
struct Model
{
int open, extend;
};
struct Cell
{
int a, b;
};
typedef std::vector> DPMatrix;
void print(const DPMatrix& matrix)
{
for (std::size_t i = 0; i < matrix.size(); ++i) {
for (std::size_t j = 0; j < matrix[i].size(); ++j) {
std::cout << '{' << matrix[i][j].a << ' ' << matrix[i][j].b << "}
";
}
std::cout << std::endl;
}
}
DPMatrix init_dp_matrix(const std::size_t num_cols, const std::size_t num_rows,
const Model& model)
{
DPMatrix result(num_cols, DPMatrix::value_type(num_rows, Cell()));
const int inf = model.open * std::max(num_cols, num_rows);
for (int i = 1; i < num_cols; ++i) {
result[i][0].b = model.open + (i - 1) * model.extend;
}
for (int j = 1; j < num_rows; ++j) {
result[0][j].a = model.open + (j - 1) * model.extend;
}
return result;
}
int main()
{
const Model model = {-8, -1};
const DPMatrix matrix = init_dp_matrix(10, 2, model);
print(matrix);
}
[Bug ipa/91836] [10 Regression] Speed regression of 525.x264_r with -Ofast -march=native since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91836 --- Comment #2 from Martin Liška --- Ah, ok, let's wait for periodic testers over the weekend.
[Bug tree-optimization/91837] Wrong code with -ftree-loop-vectorize and -march=skylake-avx512 on some Intel machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91837 Richard Biener changed: What|Removed |Added Keywords||wrong-code Component|c++ |tree-optimization --- Comment #2 from Richard Biener --- gcc-9-branch revision 275330 works fine for me, likewise the GCC 9.2 release. Note I have to use -mprefer-vector-width=512 to get AVX512 instructions used. > g++-9 t.C -O3 -march=native -mprefer-vector-width=512 -fopt-info-vec t.C:35:23: optimized: loop vectorized using 64 byte vectors t.C:32:23: optimized: loop vectorized using 64 byte vectors /usr/include/c++/9/bits/stl_algobase.h:759:13: optimized: loop vectorized using 64 byte vectors vs. > g++-9 t.C -O3 -march=native -fopt-info-vec t.C:35:23: optimized: loop vectorized using 32 byte vectors t.C:32:23: optimized: loop vectorized using 32 byte vectors /usr/include/c++/9/bits/stl_algobase.h:759:13: optimized: loop vectorized using 32 byte vectors so, not confirmed.
[Bug target/91838] New: incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
Bug ID: 91838
Summary: incorrect use of shr and shrx to shift by 64, missed
optimization of vector shift
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: x86_64-*-*
Test case:
using T = unsigned char; // or ushort, or uint
using V [[gnu::vector_size(8)]] = T;
V f(V x) { return x >> 8 * sizeof(T); }
GCC 10 compiles to either xor or shift (which should better be xor, as well)
GCC 9.2 compiles to:
vmovq rax, xmm0
mov ecx, 64
shr rax, cl
sal rax, (64 - 8*sizeof(T))
vmovq xmm0, rax
The `shr rax, cl`, where cl == 64 is a nop, because shr (and shrx, which is
used when BMI2 is enabled) mask the count with 0x3f. Consequently the last
element of the input vector is unchanged in the output.
In any case, the use of shr/shrx with shifts > 64 (or 32 in case of the 32-bit
variant) should not occur.
[Bug target/91838] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 --- Comment #1 from Matthias Kretz --- https://godbolt.org/z/zxmCTz
[Bug ipa/91836] [10 Regression] Speed regression of 525.x264_r with -Ofast -march=native since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91836 --- Comment #3 from Martin Liška --- One additional related can be: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=35.407.0
[Bug c/91839] New: missing error diagnosis for undeclared identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91839
Bug ID: 91839
Summary: missing error diagnosis for undeclared identifier
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
GCC-trunk omits the error dignosis about "l_2" in the following error code:
$ cat s.c
static long a//error
static int func_1(void; //error
static int func_1(void)
{
int l_24[4] = {{9L},{(-1L)},{9L},{(-1L)}};
return l_2[2]; //error
}
int main()
{
func_1();
return 0;
}
$ ../gcc-trunk/gcc s.c
gcc version 10.0.0 20190913 (experimental) (GCC)
target: Ubuntu 4.8.5-4ubuntu8~14.04.2
s.c:1:14: error: expected ‘;’ before ‘static’
static long a
^
;
static int func_1(void;
~~
s.c:3:13: error: storage class specified for parameter ‘func_1’
static int func_1(void)
^~
s.c:4:1: error: expected ‘;’, ‘,’ or ‘)’ before ‘{’ token
{
^
However, when compiled with clang:
$ clang-8.0 -w -ferror-limit=0 s.c
s.c:1:14: error: expected ';' after top level declarator
static long a
^
;
s.c:2:24: error: expected ')'
static int func_1(void;
^
s.c:6:12: error: use of undeclared identifier 'l_2'; did you mean 'l_24'?
return l_2[2];
^~~
l_24
3 errors generated.
[Bug middle-end/91490] [9 Regression] bogus argument missing terminating nul warning on strlen of a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91490
programmer at posteo dot de changed:
What|Removed |Added
CC||programmer at posteo dot de
--- Comment #6 from programmer at posteo dot de ---
The same bogus warning ist produced by "g++ -Wall" with the C++ code below.
Note that flexible array members are not involved there.
GCC 9.2 is affected: https://godbolt.org/z/j9m4XS
GCC 10 seems fixed: https://godbolt.org/z/DPrR1Z
//
struct two_chars_t {// std::array
char data_[2];
constexpr const char* data() const { return data_; }
};
constexpr two_chars_t global_x0 = two_chars_t{'x', '\0'};
int main() {
constexpr const char* pointer = global_x0.data();
static_assert(pointer[0] == 'x');
static_assert(pointer[1] == '\0');
return __builtin_strlen(pointer);
}
//
[Bug c++/91840] New: Support for #pragma unroll (N)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91840
Bug ID: 91840
Summary: Support for #pragma unroll (N)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Clang/ICC supports #pragma unroll (N) and it would be good if GCC too, so we
don't have to write macros to workaround it and to keep the code buildable by
all tree compilers.
This should not be so hard, since GCC already has #pragma GCC unroll (N).
void unroll(int a[], int b[], int c[], int d[]) {
#pragma unroll(4)
for (int i = 1; i < 100; i++) {
b[i] = a[i] + 1;
d[i] = c[i] + 1;
}
}
[Bug target/91841] New: vector_size(8) passes MMX register without emms cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841
Bug ID: 91841
Summary: vector_size(8) passes MMX register without emms
cleanup
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: i?86-*-*
Test case `g++ -O2 -m32` (cf. https://godbolt.org/z/RDUZo9):
#include
using T = unsigned short;
using V [[gnu::vector_size(8)]] = T;
[[gnu::noinline]] V f(V x) { return x; }
int main() {
volatile float a = 1.f;
auto x = f(~V{});
asm("" :: "X"(x));
std::cout << a + 2.f;
}
The V parameter is passed via mm0 which leads to 1.f+2.f becoming -nan.
If GCC cannot reliably insert emms, it should not (never!) transparently emit
MMX code. Nowhere in this code did I ask for MMX... I understand that this
would be an ABI break. But at least clang does not implement this ABI either.
Why is this relevant?
namespace std {
template
class simd {
using V [[gnu::vector_size(sizeof(T) * N)]] = T;
V d;
public:
...
};
}
Subsequently interleaving `std::simd` and any FPU code (forced e.g.
with long double) would lead to disaster.
[Bug target/91823] [10 regression] r275959 breaks gcc.target/powerpc/altivec-32.c with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91823 --- Comment #4 from seurer at gcc dot gnu.org --- The full test showed no new problems.
[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91364 --- Comment #1 from Marek Polacek --- Sort of depends on CWG 2352 Similar types and reference binding which changed the definition of "reference-related".
[Bug target/91841] vector_size(8) passes MMX register without emms cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Uroš Bizjak ---
(In reply to Matthias Kretz from comment #0)
> Test case `g++ -O2 -m32` (cf. https://godbolt.org/z/RDUZo9):
>
> #include
>
> using T = unsigned short;
> using V [[gnu::vector_size(8)]] = T;
>
> [[gnu::noinline]] V f(V x) { return x; }
>
> int main() {
> volatile float a = 1.f;
> auto x = f(~V{});
> asm("" :: "X"(x));
> std::cout << a + 2.f;
> }
>
> The V parameter is passed via mm0 which leads to 1.f+2.f becoming -nan.
>
> If GCC cannot reliably insert emms, it should not (never!) transparently
> emit MMX code. Nowhere in this code did I ask for MMX... I understand that
> this would be an ABI break. But at least clang does not implement this ABI
> either.
Clang is wrong here. Please see [1], section 2.2.3, Parameter Passing and
Returning Values.
> Why is this relevant?
Because of [1]. GCC implements published ABI.
[1] https://www.uclibc.org/docs/psABI-i386.pdf
[Bug tree-optimization/91825] [10 regression] Bogus -Wmaybe-uninitialized with r275744 breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91825 Jason Merrill changed: What|Removed |Added Component|bootstrap |tree-optimization Summary|Top-of-tree GCC does not|[10 regression] Bogus |bootstrap (uninitialized|-Wmaybe-uninitialized with |warning)|r275744 breaks bootstrap --- Comment #7 from Jason Merrill --- OK, I'm confident now that this is not a problem with the front-end output. The only difference from r275744 is that some indexing expressions are represented in gimple as ar[idx] rather than *(&ar+idx), e.g. _119 = scalar_int_mode::operator machine_mode (&int_mode_to); - _120 = (sizetype) _119; - _121 = &mode_class + _120; - _122 = *_121; - if (_122 == 2) goto ; else goto ; + _120 = (long int) _119; + _121 = mode_class[_120]; + if (_121 == 2) goto ; else goto ; By the time we get to the uninit pass I see some differences in the gimple, such as references to 'cstore' + # cstore_2229 = PHI ... + # cstore_2844 = PHI ... - mode.96_671 = (int) mode_69; + mode.96_671 = (int) cstore_2844; It's not clear to me how this affects uninit. I can wait to reapply r275744 until I'm ready to commit the operator<=> patch, but it would be good if someone could fix the tree-ssa issue before then.
[Bug rtl-optimization/82803] Wildly excessive calls to __tls_get_addr with optimizations enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #8 from Yann Droneaud ---
Created attachment 46903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46903&action=edit
An artificial test case for gcc to emit 17 calls to __tls_get_addr()
Using Thread Local Storage (TLS) is a pain: the issue reported here still apply
on latest GCC.
I've code such as
static struct state *state(void) __attribute__((pure));
static struct state *state(void)
{
static __thread struct state s;
return &s;
}
int do(void)
{
struct state * const s = state();
int res;
/* do something */
return res;
}
Once compiled, code for my real function contains 6 calls to __tls_get_addr().
Which is far more than expected. And far more than necessary.
Clang compile the same code and emit a single call to __tls_get_addr(). Both on
Linux amd64, -O3 -fPIC.
The attached testcase is an example which is designed to trigger 17 calls to
__tls_get_addr(). As you will see, there's about one per conditional + function
call pair.
Once again, clang is able to emit code with a single call to __tls_get_addr().
You can check for yourself: https://godbolt.org/z/QVGjka
[Bug rtl-optimization/81501] Unneccessary calls to __tls_get_addr() in simple thread-singleton pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #3 from Yann Droneaud --- See also bug #82803.
[Bug rtl-optimization/82803] Wildly excessive calls to __tls_get_addr with optimizations enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803 --- Comment #9 from Yann Droneaud --- This issue is also reported as bug #81501
[Bug testsuite/91842] New: new test case gcc.dg/ipa/ipa-sra-19.c in r275982 has compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91842 Bug ID: 91842 Summary: new test case gcc.dg/ipa/ipa-sra-19.c in r275982 has compilation error Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -S -o ipa-sra-19.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -S -o ipa-sra-19.s /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c: In function 'c': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c:19:3: error: AltiVec argument passed to unprototyped function compiler exited with status 1 FAIL: gcc.dg/ipa/ipa-sra-19.c (test for excess errors) Excess errors: /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c:19:3: error: AltiVec argument passed to unprototyped function testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa.exp completed in 0 seconds === gcc Summary === # of unexpected failures1
[Bug target/91841] vector_size(8) passes MMX register without emms cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841 --- Comment #2 from Matthias Kretz --- Ah, because of: typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__)); ? Too be pedantic only `int [[gnu::vector_size(8)]]` equals __m64. But I see your point. I guess clang interprets the optional nature of __m64 to mean that they can pass vector_size(8) objects on the stack? (aka, there's no __m64 here) But then 2.2.1 says "Therefore, every function that uses the MMX registers is required to issue an emms or femms instruction after using MMX registers, before returning or calling another function." This is in contradiction to Table 2.4 which requires __m64 to be returned via %mm0. Calling emms before ret would invalidate the return value. I.e. the ABI must require callers of functions that return via %mm0 to call emms. Am I reading this wrong, or is the ABI broken here? Note, I am fine with a wontfix. Just want to be extra clear about the design decision here.
[Bug target/91841] vector_size(8) passes MMX register without emms cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841 --- Comment #3 from Uroš Bizjak --- (In reply to Matthias Kretz from comment #2) > But then 2.2.1 says "Therefore, every function that uses the MMX registers > is required to issue an emms or femms instruction after using MMX registers, > before returning or calling another function." > This is in contradiction to Table 2.4 which requires __m64 to be returned > via %mm0. Calling emms before ret would invalidate the return value. I.e. > the ABI must require callers of functions that return via %mm0 to call emms. > > Am I reading this wrong, or is the ABI broken here? [f]emms should be emitted by an intrinsic (_mm_empty), inserted by the programmer. The programmer can mix FP and MMX instructions in the same function, so there is no way for compiler to automatically emit emms. Obviously, when the function returns value in %mm0 register (or in %fp), emms should not be inserted at function exit.
[Bug tree-optimization/91830] Bogus -Warray-bounds warning compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-09-20 Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- The warning is most likely the result of the patch for pr91631 that I committed just yesterday. I don't see it with the top of binutils-gdb on x86_64-linux and I haven't had luck with any test cases derived from the Mach code. I don't know how to configure it for Mach so a translation unit that reproduces it would help. Alternatively, if you can show me how to configure it for Mach I can try to reproduce it myself (knowing how to do that would be useful in any case).
[Bug target/91796] Sub-optimal YMM register allocation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796 --- Comment #1 from Maxim Egorushkin --- In addition, the code tries to generate avx_signbit using 2 instructions: comparision vpcmpeqq and shift vpsllq to avoid loading anything from memory. However, the compiler replaces the code with loading a 64-byte constant from memory, which may cause otherwise unnecessary TLB and cache misses in the worst case scenario. Is there a way to make the compiler not replace the instructions with a load?
[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683 Jim Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Jim Wilson --- Fixed on mainline and gcc-9 branch.
[Bug tree-optimization/91830] Bogus -Warray-bounds warning compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830 --- Comment #3 from Alan Modra --- Created attachment 46904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46904&action=edit reduced testcase -O2 -Wall
[Bug c/91843] New: pretty printer mangles extended characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843
Bug ID: 91843
Summary: pretty printer mangles extended characters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lhyatt at gmail dot com
Target Milestone: ---
There seem to be some issues with identifiers containing extended characters
going through pretty-printer.c. For example, this test:
=
int int_π = 3;
int π() {
return itn_π;
}
=
(note: if testing older trunk that doesn't have extended identifier support,
the same behavior is seen using UCNs).
In either C or C++ mode, the output is wrong:
t8.cpp: In function ‘int\xcf\x80()’:
t8.cpp:3:12: error: ‘itn_π’ was not declared in this scope; did you mean
‘int\xcf\x80’?
3 | return itn_π;
|^
|int_π
(in C it's the same except for minor changes in the text.)
So extended characters are printed 5 times, and 2 of them get mangled with hex
escape codes and 3 come out OK. Of the 3 that work, 2 from
diagnostic-show-locus.c are just output directly from the source, and the other
one (the error: 'itn_π') is printed using %qD, which ends up in
pp_c_identifier, which ends up calling pp_identifier in pretty-print.h, which
calls pp_string, which does not do any hex escaping.
For the two wrong ones, the code path is different for C and C++, but they end
up in pretty-printer.c being processed as a %qs directive either way.
(BTW, incidental to this bug report, the "did you mean" part is missing a call
to identifier_to_locale(). But that isn't the reason it gets misprinted.)
It seems there are lots of code paths that may end up printing an identifier
via %qs, so I tried to look at this common element, and the situation seems
straightforward enough, but I don't understand why it is the way it is, so I'm
not sure what's the correct fix. The source of the issue is that the %qs seems
to apply quoting in two unrelated senses... It surrounds the string with
quotation marks, and it also prints the string with pp_quoted_string() instead
of pp_string(). The pp_quoted_string() then applies the hex escape to all
non-printable bytes it comes across. Seems there would be a few options:
-Change %qs to only surround with quotes, not also do hex escapes. This is a
simple one-line fix but I am not sure why it does this hex escaping or if it's
still necessary for other use cases.
-Maybe there is some alternative to %qs that is already there that's supposed
to be used for this, and needs to be added in various places? This test case
reveals two of them, but there must be others among 2000 different uses of %qs,
so not sure about this...
-Change pp_quoted_string() to check if the bytes it would escape form a valid
UTF-8 sequence, in which case, don't escape them. That also seems relatively
simple and would handle all uses cases of %qs wherever they may be.
I am happy to work on it but not sure how to decide on the best path. Thanks!
-Lewis
[Bug tree-optimization/91830] Bogus -Warray-bounds warning compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830 Alan Modra changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Alan Modra --- Configuring binutils with --enable-targets=all on a 64-bit host will get all the bfd files built. Or in this case, --target=i686-darwin will compile bfd/mach-o.c.
[Bug tree-optimization/91830] Bogus -Warray-bounds warning compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830 --- Comment #5 from Martin Sebor --- Thanks. I also just noticed I missed the "x86_64-linux" at the beginning on comment #0. The way I configure gdb-binutils, bfd/mach-o.c doesn't get compiled (I didn't use --enable-targets=all), but I was able to reproduce the warning by compiling it by hand so I can confirm the warning. Let me see where the problem is.
[Bug fortran/78260] ICE in gimplify_expr, at gimplify.c:11939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78260 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Fri Sep 20 16:05:06 2019 New Revision: 276002 URL: https://gcc.gnu.org/viewcvs?rev=276002&root=gcc&view=rev Log: 2019-09-20 Tobias Burnus PR fortran/78260 * openmp.c (gfc_resolve_oacc_declare): Reject all non variables but accept function result variables. * trans-openmp.c (gfc_trans_omp_clauses): Handle function-result variables for remaing cases. 2019-09-20 Tobias Burnus PR fortran/78260 * gfortran.dg/goacc/parameter.f95: Change dg-error as it is now detected earlier. * gfortran.dg/goacc/pr85701.f90: Modify to use a separate result variable. * gfortran.dg/goacc/pr78260.f90: New. * gfortran.dg/goacc/pr78260-2.f90: New. * gfortran.dg/gomp/pr78260.f90: New. * gfortran.dg/gomp/pr78260-2.f90: New. * gfortran.dg/gomp/pr78260-3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/goacc/pr78260-2.f90 trunk/gcc/testsuite/gfortran.dg/goacc/pr78260.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr78260-2.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr78260-3.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr78260.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/goacc/parameter.f95 trunk/gcc/testsuite/gfortran.dg/goacc/pr85701.f90
[Bug fortran/78260] ICE in gimplify_expr, at gimplify.c:11939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78260 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus --- FIXED on the trunk (GCC 10). Thanks for the report! Turned out that a tad more was requires as it also wrongly rejected function f() !$acc declare present(f) where "f" is both the function name and the result-variable name.
[Bug c++/91844] New: Implement CWG 2352, Similar types and reference binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91844
Bug ID: 91844
Summary: Implement CWG 2352, Similar types and reference
binding
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
int *ptr;
const int *const &
f()
{
return ptr;
}
Here, a reference to a temporary is returned, because under the old wording,
"int *" and "const int * const" are not reference-related, because they're not
the same types. But this CWG changed the definition of "reference-related" to
say
“cv1 T1” is reference-related to “cv2 T2” if T1 is similar ([conv.qual]) to T2,
or T1 is a base class of T2.
http://eel.is/c++draft/dcl.init#def:reference-related
So it seems we need to tweak reference_related_p, and then we will bind
directly to ptr.
[Bug tree-optimization/91830] [10 Regression] Bogus -Warray-bounds on strcpy into a member of a subobject compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Target Milestone|--- |10.0
Summary|Bogus -Warray-bounds|[10 Regression] Bogus
|warning compiling binutils |-Warray-bounds on strcpy
||into a member of a
||subobject compiling
||binutils
--- Comment #6 from Martin Sebor ---
Reduced test case. The warning code uses the MEM_REF type, or struct A here,
to validate the access to B::A::a at offset 4, without adjusting the offset by
that of B::a (or rather, the offset of B::A::a from B).
$ cat pr91830.c && gcc -O2 -S -Wall -fdump-tree-wrestrict=/dev/stdout pr91830.c
struct A { char a[3]; int i; };
struct B { int j; struct A a; };
void g (struct B *p, const char *s)
{
struct A *q = &p->a;
__builtin_strcpy (q->a, s);
}
;; Function g (g, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=0)
pr91830.c: In function ‘g’:
pr91830.c:7:3: warning: ‘__builtin_strcpy’ offset 4 from the object at ‘p’ is
out of the bounds of referenced subobject ‘a’ with type ‘char[3]’ at offset 0
[-Warray-bounds]
7 | __builtin_strcpy (q->a, s);
| ^~
pr91830.c:1:17: note: subobject ‘a’ declared here
1 | struct A { char a[3]; int i; };
| ^
g (struct B * p, const char * s)
{
char[3] * _1;
[local count: 1073741824]:
_1 = &MEM[(struct A *)p_2(D) + 4B].a;
__builtin_strcpy (_1, s_4(D));
return;
}
[Bug c++/91845] New: [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91845
Bug ID: 91845
Summary: [10 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
build_m_component_ref, at cp/typeck2.c:2086
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-10.0.0-alpha20190915 snapshot (r275736) ICEs when compiling the following
testcase reduced from test/CXX/drs/dr20xx.cpp from the clang 9.0.0 testsuite:
void non_const_mem_ptr() {
struct A {
};
constexpr A a = {1, 2};
struct B {
int A::*p;
constexpr int g() const {
return a.*p;
};
};
}
% g++-10.0.0-alpha20190915 -c ecqppima.cpp
ecqppima.cpp: In function 'void non_const_mem_ptr()':
ecqppima.cpp:5:24: error: too many initializers for 'const
non_const_mem_ptr()::A'
5 | constexpr A a = {1, 2};
|^
ecqppima.cpp: In member function 'constexpr int non_const_mem_ptr()::B::g()
const':
ecqppima.cpp:9:14: error: use of local variable with automatic storage from
containing function
9 | return a.*p;
| ^
ecqppima.cpp:5:15: note: 'constexpr const non_const_mem_ptr()::A a' declared
here
5 | constexpr A a = {1, 2};
| ^
ecqppima.cpp:9:17: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086
9 | return a.*p;
| ^
0x7d6093 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree.c:9972
0x6846b7 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree.h:3390
0x6846b7 build_m_component_ref(tree_node*, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/typeck2.c:2086
0xa627b2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/typeck.c:4183
0x99e924 cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:9645
0x99f689 cp_parser_assignment_expression
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:9780
0x99f90c cp_parser_expression
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:9948
0x9afd2a cp_parser_jump_statement
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:12951
0x9afd2a cp_parser_statement
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:11233
0x9b03b5 cp_parser_statement_seq_opt
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:11699
0x9b0485 cp_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:11653
0x9c906c cp_parser_function_body
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:22702
0x9c906c cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:22753
0x9c995d cp_parser_function_definition_after_declarator
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:28074
0x9cab51 cp_parser_late_parsing_for_member
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:28959
0x9aa355 cp_parser_class_specifier_1
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:23784
0x9ab394 cp_parser_class_specifier
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:23810
0x9ab394 cp_parser_type_specifier
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:17475
0x9ac199 cp_parser_decl_specifier_seq
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:14174
0x9acb0a cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:13460
[Bug c++/91845] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91845 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r253266.
[Bug c++/91845] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91845 Marek Polacek changed: What|Removed |Added Target Milestone|--- |8.4 Summary|[10 Regression] ICE: tree |[8/9/10 Regression] ICE: |check: expected class |tree check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |build_m_component_ref, at |build_m_component_ref, at |cp/typeck2.c:2086 |cp/typeck2.c:2086
[Bug c++/91846] New: [9/10 Regression] ICE in use_thunk, at cp/method.c:316
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91846
Bug ID: 91846
Summary: [9/10 Regression] ICE in use_thunk, at cp/method.c:316
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-10.0.0-alpha20190915 snapshot (r275736) ICEs when compiling the following
testcase reduced from test/SemaCXX/constant-expression-cxx2a.cpp from the clang
9.0.0 test suite:
struct B {
virtual constexpr char f() const { return 'B'; }
char b = f();
};
struct C {
virtual constexpr char f() const { return 'C'; }
B *pba;
char c = ((B*)this)->f();
char ba = pba->f();
};
struct D : B, C {
char d = ' ';
};
template
struct Covariant2 {
virtual const T *f() const;
};
template
struct Covariant3 : Covariant2 {
constexpr virtual const D *f() const { return nullptr; }
};
constexpr Covariant3 cc;
static_assert(cc.f()->d == 'D');
% g++-10.0.0-alpha20190915 -c wkzgbhd7.cpp
wkzgbhd7.cpp: In instantiation of 'constexpr const D* Covariant3::f() const
[with T = C]':
wkzgbhd7.cpp:29:19: required from here
wkzgbhd7.cpp:24:58: internal compiler error: in use_thunk, at cp/method.c:316
24 | constexpr virtual const D *f() const { return nullptr; }
| ^
0x616688 use_thunk(tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/method.c:316
0xa38119 emit_associated_thunks(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/semantics.c:4341
0xa3845b expand_or_defer_fn(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/semantics.c:4443
0x9ee958 instantiate_decl(tree_node*, bool, bool)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/pt.c:24802
0x8d46bc instantiate_cx_fn_r
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/constexpr.c:5495
0x123b246 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree.c:12259
0x123bab0 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree.c:12589
0x123bab0 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree.c:12589
0x123e343 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/tree.c:12615
0x8dfa3f instantiate_constexpr_fns
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/constexpr.c:5514
0x8dfa3f cxx_eval_outermost_constant_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/constexpr.c:5576
0x8e3cdd maybe_constant_value(tree_node*, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/constexpr.c:5790
0x8f8c85 cp_fully_fold(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/cp-gimplify.c:2197
0xa6db26 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/typeck.c:5561
0x8b654e build_new_op_1
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/call.c:6231
0x8b6faa build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/call.c:6275
0xa62611 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/typeck.c:4185
0x99e924 cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915/work/gcc-10-20190915/gcc/cp/parser.c:9645
0x99f689 cp_parser_assignment_expression
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190915
[Bug c++/91845] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91845
--- Comment #2 from Marek Polacek ---
I suggest:
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -2068,12 +2068,12 @@ build_m_component_ref (tree datum, tree component,
tsubst_flags_t complain)
tree binfo;
tree ctype;
- if (error_operand_p (datum) || error_operand_p (component))
-return error_mark_node;
-
datum = mark_lvalue_use (datum);
component = mark_rvalue_use (component);
+ if (error_operand_p (datum) || error_operand_p (component))
+return error_mark_node;
+
ptrmem_type = TREE_TYPE (component);
if (!TYPE_PTRMEM_P (ptrmem_type))
{
because mark_[lr]value_use can cope with error_mark_node.
[Bug c++/91845] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91845 --- Comment #3 from Marek Polacek --- Though probably not if only the TREE_TYPE is error_mark_node.
[Bug testsuite/65364] FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65364 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Iain Sandoe --- fixed on open branches.
[Bug c++/91846] [9/10 Regression] ICE in use_thunk, at cp/method.c:316
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91846 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug testsuite/81058] FAIL: gcc.target/i386/avx512bw-vpmovu?swb-1.c scan-assembler-times vpmovu?swb.*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81058 --- Comment #10 from Iain Sandoe --- Author: iains Date: Fri Sep 20 18:29:16 2019 New Revision: 276003 URL: https://gcc.gnu.org/viewcvs?rev=276003&root=gcc&view=rev Log: [Darwin, X86, testsuite] Fix PR81058. The tests fail because Darwin indirects common accesses which causes different codegen and the mismatch in output. Placing the vars in regular .data section fixes that. gcc/testsuite/ 2019-09-20 Iain Sandoe Backport from mainline. 2019-05-11 Iain Sandoe PR testsuite/81058 * gcc.target/i386/avx512bw-vpmovswb-1.c: Use regular data section for variables on Darwin, rather than common. * gcc.target/i386/avx512bw-vpmovuswb-1.c: Likewise. * gcc.target/i386/avx512bw-vpmovwb-1.c: Likewise. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/avx512bw-vpmovswb-1.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/avx512bw-vpmovuswb-1.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/avx512bw-vpmovwb-1.c
[Bug c/91843] pretty printer mangles extended characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843 --- Comment #1 from Lewis Hyatt --- Created attachment 46905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46905&action=edit Patch to implement the 3rd option The last option from my previous message seems, at least, unlikely to break anything. Attached patch resolves this issue. It also fixes a small unrelated bug that prevents the first byte prior to any hex-escaped byte from being output, which was revealed by new self-test cases that I have added.
[Bug target/91841] vector_size(8) passes MMX register without emms cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841 --- Comment #4 from Matthias Kretz --- (In reply to Uroš Bizjak from comment #3) > [f]emms should be emitted by an intrinsic (_mm_empty), inserted by the > programmer. The programmer can mix FP and MMX instructions in the same > function, so there is no way for compiler to automatically emit emms. But that was my original point. In #0 the programmer did not mix FP and MMX instructions, only float and ushort [[gnu::vector_size(8)]] (which isn't even the same type as __m64) operations. The compiler did it. ;-) In that case, I understand 2.2.1 p3 as a requirement on the compiler. I sure agree that the use of MMX intrinsics puts the responsibility with the developer, but use of vector_size(8)? > Obviously, when the function returns value in %mm0 register (or in %fp), > emms should not be inserted at function exit. Right. Does that mean you agree the ABI document is contradicting itself?
[Bug c++/91826] Unexpected behavior when class defined with namespace alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91826
--- Comment #1 from Michał ---
Previous code compiles fine with clang, but failed with gcc 8.x.
I check similar code that is invalid and should fail with this error:
namespace N1 {
namespace N { class C; }
}
namespace N2
{
namespace A = N1::N;
class A::C {};
}
This one fail as expected in 9.x & 9.2, but segment fault with 'internal
compiler error' when compiled with gcc 6.3. It is possible that change was made
to correct this problem.
I found that error is printed inside gcc/cp/parser.c when function
'is_ancestor' is used to check if current scope is ancestor of declared class.
This check failed. This function is used at three different location to check
correctness of class/enum scope.
The problem is that namespace alias is not resolved to original namespace
during check and 'is_nested_namespace' function used inside 'is_ancestor' does
not handle namespace aliases. I made change in file gcc/cp/name-lookup.c to
resolve original namespace before calling this function.
Compiler now work for valid code while still print error for invalid above. I
can also build original commercial code that had problem. Change diff is below.
diff gcc/cp/name-lookup.c ../gcc-9.2.0/gcc/cp/name-lookup.c
4149,4152c4149
< {
< child = ORIGINAL_NAMESPACE (child);
< return is_nested_namespace (root, child);
< }
---
> return is_nested_namespace (root, child);
[Bug tree-optimization/91699] [10 Regression] Bogus warnings with -O3 -flto after revision r274997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91699 Iain Sandoe changed: What|Removed |Added Last reconfirmed|2019-09-07 00:00:00 |2019-9-20 --- Comment #1 from Iain Sandoe --- similar effects are repeatable on x86_64-linux-gnu and powerpc64-linux-gnu. e.g. on x86-64-linux-gnu: In function 'copy2', inlined from 'MAIN__' at /home/iains/gcc-trunk/src/gcc/testsuite/gfortran.dg/argument_checking_1.f90:13:0, inlined from 'main' at /home/iains/gcc-trunk/src/gcc/testsuite/gfortran.dg/argument_checking_1.f90:18:0: /home/iains/gcc-trunk/src/gcc/testsuite/gfortran.dg/argument_checking_1.f90:28: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] FAIL: gfortran.dg/argument_checking_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) Excess errors: /home/iains/gcc-trunk/src/gcc/testsuite/gfortran.dg/argument_checking_1.f90:28:0: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
[Bug tree-optimization/91699] [10 Regression] Bogus warnings with -O3 -flto after revision r274997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91699 --- Comment #2 from Iain Sandoe --- NOTE: the test passes without -flto, but fails with (although it's not shown in the options summary)
[Bug tree-optimization/91837] Wrong code with -ftree-loop-vectorize and -march=skylake-avx512 on some Intel machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91837 --- Comment #3 from Daniel Cooke --- I tried replicating the issue on a CentOS machine (AWS EC2) with the exact same CPU and got the correct output. However, I just fired up a fresh AWS EC2 instance running Ubuntu and I can replicate the bug again. Is it possible that the bug is CPU *and* OS specific?
[Bug target/86811] Vax port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811 --- Comment #2 from Jeffrey A. Law --- Author: law Date: Fri Sep 20 20:23:29 2019 New Revision: 276006 URL: https://gcc.gnu.org/viewcvs?rev=276006&root=gcc&view=rev Log: PR target/86811 * config/vax/vax.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/vax/vax.c
[Bug tree-optimization/91699] [10 Regression] Bogus warnings with -O3 -flto after revision r274997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91699 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80545 --- Comment #3 from Martin Sebor --- -Wstringop-overflow is only enabled for the C family plus LTO and with pr80545 resolved should now be disabled for Fortran, so something in the command line option handling is still not working right. My guess is the LTO setting in the warning entry in gcc/c-family/c.opt is behind it: Wstringop-overflow= C ObjC C++ LTO ObjC++ Joined RejectNegative UInteger Var(warn_stringop_overflow) Init(2) Warning LangEnabledBy(C ObjC C++ LTO ObjC++, Wall, 2, 0) IntegerRange(0, 4) The LTO handling of late warning options aside, I also suspect the warning code itself isn't dealing with the "special" MEM_REFs emitted for Fortran arrays quite right. I recently fixed a -Warray-bounds false positive for Fortran (pr91584) and it wouldn't surprise me if the code -Wstringop-overflow had a similar bug.
[Bug tree-optimization/91699] [10 Regression] Bogus Wstringop-overflow in Fotran with -flto after revision r274997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91699 --- Comment #4 from Iain Sandoe --- hmm that seems quite tricky, as if we are missing a more selective infrastructure for deciding whether a warning applies. Or do you expect to make it work for Fortran too?
[Bug fortran/91426] Different colors for errors with multiple locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01269.html
[Bug fortran/91714] Accepts type statement without delimiter in free form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91714
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-09-20
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from kargl at gcc dot gnu.org ---
Fixes the problem with "typea"
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 275969)
+++ gcc/fortran/decl.c (working copy)
@@ -10231,6 +10240,17 @@ gfc_match_derived_decl (void)
return MATCH_ERROR;
}
+ /* In free source form, need to check for TYPE XXX as oppose to TYPEXXX. */
+ if (m == MATCH_NO && gfc_current_form == FORM_FREE)
+{
+ char c = gfc_peek_ascii_char ();
+ if (!gfc_is_whitespace (c))
+ {
+ gfc_error ("Mangled derived type definition at %C");
+ return MATCH_NO;
+ }
+}
+
m = gfc_match (" %n ", name);
if (m != MATCH_YES)
return m;
@@ -10238,7 +10258,7 @@ gfc_match_derived_decl (void)
/* Make sure that we don't identify TYPE IS (...) as a parameterized
derived type named 'is'.
TODO Expand the check, when 'name' = "is" by matching " (tname) "
- and checking if this is a(n intrinsic) typename. his picks up
+ and checking if this is a(n intrinsic) typename. This picks up
misplaced TYPE IS statements such as in select_type_1.f03. */
if (gfc_peek_ascii_char () == '(')
{
[Bug tree-optimization/91699] [10 Regression] Bogus Wstringop-overflow in Fotran with -flto after revision r274997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91699 --- Comment #5 from Martin Sebor --- I don't yet fully understand the interplay between LTO and the late warning (or other middle-end) options to tell how difficult that problem might be to fix. At Cauldron Jeff mentioned other problems in this area, such as LTO suppressing -Wall even when it's on the command line during compilation, or different translation units (or even functions via #pragma GCC diagnostic) being compiled with different warning options that LTO is expected to somehow merge when inlining. It does sound tricky. But -Wstringop-truncation shouldn't be any more noisy for Fotran code than it is for C, so the most expedient "fix"for this bug will probably be to correct the warning to handle the Fortran MEM_REFs (if it's wrong). This shouldn't be too hard if I can reproduce the problem without LTO (even without the warning itself). The checker still runs, it just doesn't emit any warnings (without LTO), so I can work with that. The general issue of the interaction between middle-end warning options and LTO can be dealt with separately.
[Bug fortran/91714] Accepts type statement without delimiter in free form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91714 --- Comment #3 from Steve Kargl --- On Fri, Sep 20, 2019 at 08:58:19PM +, kargl at gcc dot gnu.org wrote: > --- Comment #2 from kargl at gcc dot gnu.org --- > Fixes the problem with "typea" > > Index: gcc/fortran/decl.c > === > --- gcc/fortran/decl.c (revision 275969) > +++ gcc/fortran/decl.c (working copy) Patch needs some minor tuning.
