[Bug c++/88368] [7/8/9 Regression] Improper ``use of deleted function''
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88368 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #5 from Jason Merrill --- Created attachment 45759 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45759=edit patch Like so.
[Bug other/89395] libiberty: heap buffer overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89395 --- Comment #1 from Peng Chen --- the code is from binutils: https://github.com/bminor/binutils-gdb/tree/master/libiberty git commit: 388a192d73df7439bf375d8b8042bb53a6be9c60
[Bug other/89394] libiberty :stack overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394 --- Comment #1 from Peng Chen --- the code is from binutils: https://github.com/bminor/binutils-gdb/tree/master/libiberty git commit: 388a192d73df7439bf375d8b8042bb53a6be9c60
[Bug other/89395] New: libiberty: heap buffer overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89395 Bug ID: 89395 Summary: libiberty: heap buffer overflow in nm Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: spinpx at gmail dot com Target Milestone: --- Created attachment 45758 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45758=edit inputs trigger bugs reference: https://sourceware.org/bugzilla/show_bug.cgi?id=24229 - Intel Xeon Gold 5118 processors and 256 GB memory - Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux - clang version 4.0.0 (tags/RELEASE_400/final) - version: commit commit 388a192d73df7439bf375d8b8042bb53a6be9c60 (2019 Jan 24) - run: nm -C input_file (We attached the inputs that trigger the bug) - asan report: ==2003322==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e000d8 at pc 0x008957c6 bp 0x7ffdf2e36340 sp 0x7ffdf2e36338 READ of size 1 at 0x60e000d8 thread T0 #0 0x8957c5 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3356:12 #1 0x896370 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3449:16 #2 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #3 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #4 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #5 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #6 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #7 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #8 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #9 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #10 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #11 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #12 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #13 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #14 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #15 0x896370 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3449:16 #16 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #17 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #18 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #19 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #20 0x896370 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3449:16 #21 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #22 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #23 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #24 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #25 0x89610c in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3416:18 #26 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #27 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #28 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #29 0x896210 in d_expression_1 /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:3438:15 #30 0x896210 in d_expression_1
[Bug other/89394] New: libiberty :stack overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394 Bug ID: 89394 Summary: libiberty :stack overflow in nm Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: spinpx at gmail dot com Target Milestone: --- Created attachment 45757 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45757=edit inputs trigger bugs reference from: https://sourceware.org/bugzilla/show_bug.cgi?id=24227 - Intel Xeon Gold 5118 processors and 256 GB memory - Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux - clang version 4.0.0 (tags/RELEASE_400/final) - version: commit commit 388a192d73df7439bf375d8b8042bb53a6be9c60 - run: nm -C input_file (We attached the inputs that trigger the bug) - asan report: ==1992137==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc986fff68 (pc 0x008975c5 bp 0x7ffc987000a0 sp 0x7ffc986fff70 T0) #0 0x8975c4 in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4149:7 #1 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #2 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #3 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #4 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #5 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #6 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #7 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #8 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #9 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #10 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #11 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #12 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #13 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #14 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #15 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #16 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #17 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #18 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #19 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #20 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #21 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #22 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #23 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #24 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #25 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #26 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #27 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #28 0x89762f in d_count_templates_scopes /mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/cp-demangle.c:4151:7 #29 0x89762f in
[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 --- Comment #5 from urbanjost at comcast dot net --- That was fast. Thanks!
[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337
--- Comment #12 from Martin Sebor ---
One of the approaches we have been discussing is replacing these invalid calls
with __builtin_trap or __builtin_unreachable, perhaps optionally preceded by
__builtin_warning ("specified size exceeds maximum object size") which would be
issued if the code wasn't eliminated. Command line options controlling the
choices would be provided. This would work in some cases but probably not
those where the invalid value ends up constant-propagated after the new
statement has been introduced. It's something to investigate/prototype for GCC
10.
[Bug c++/89336] internal compiler error when compiling a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336 --- Comment #7 from Jason Merrill --- Author: jason Date: Tue Feb 19 01:01:50 2019 New Revision: 269003 URL: https://gcc.gnu.org/viewcvs?rev=269003=gcc=rev Log: PR c++/89336 - multiple stores in constexpr stmt. If we evaluate the RHS in the context of the LHS, that evaluation might change the LHS in ways that mess with being able to store the value later. So for assignment or scalar values, evaluate the RHS first. * constexpr.c (cxx_eval_store_expression): Preevaluate scalar or assigned value. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89336-1.C trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89336-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761 --- Comment #12 from Jeffrey A. Law --- octeon-exts-3 can be fixed with a relatively simple pattern in mips.md or with a bit of code in combine.c. fix-r4000-10.c is more interesting. Hard register propagation does its thing and exposes a bit of dead code. Removing that dead code in turn exposes additional hard register propagation opportunities, which then exposes more dead code. But running those passes in their entirety seems horribly heavyweight for this issue. Particularly since the test goes out of its way to disable lower-subreg. We had another BZ in this cycle where post-reload splitting exposed dead code. So we might be able to make a case for RTL DCE after splitting (or have some gross mips.md patterns to avoid the dead code). That would help some. But to really fix this hard register cprop would have to discover at least the trivial cases where its actions expose dead code, remove the dead code and reprocess the block. I'm still not sure how wise such hacks to hard register cprop would be. I haven't dug into fpr-moves-5.c yet.
[Bug c++/89389] inlining failed in call to always_inline -- removing attribute leaves function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89389 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-19 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Waiting on the preprocessed source because it is hard debug without it.
[Bug d/88127] Many gdc.dg testsuite failures due to undefined reference to qsort_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88127 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- This should be fixed now.
[Bug d/88127] Many gdc.dg testsuite failures due to undefined reference to qsort_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88127 --- Comment #3 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Mon Feb 18 23:29:39 2019 New Revision: 268999 URL: https://gcc.gnu.org/viewcvs?rev=268999=gcc=rev Log: libphobos: Detect if qsort_r is available Merges upstream druntime bbfb58e8. libphobos/ChangeLog: 2019-02-19 Johannes Pfau PR d/88127 * m4/druntime/libraries.m4 (DRUNTIME_LIBRARIES_CLIB): Add new macro. * configure.ac: Use DRUNTIME_LIBRARIES_CLIB. * configure: Regenerate * Makefile.in: Regenerate * libdruntime/gcc/config.d.in: Add Have_Qsort_R. * libdruntime/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. Modified: trunk/libphobos/ChangeLog trunk/libphobos/Makefile.in trunk/libphobos/configure trunk/libphobos/configure.ac trunk/libphobos/libdruntime/MERGE trunk/libphobos/libdruntime/Makefile.in trunk/libphobos/libdruntime/gcc/config.d.in trunk/libphobos/libdruntime/rt/qsort.d trunk/libphobos/m4/druntime/libraries.m4 trunk/libphobos/src/Makefile.in trunk/libphobos/testsuite/Makefile.in
[Bug c++/89357] alignas for automatic variables with alignment greater than 16 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89357 Joseph S. Myers changed: What|Removed |Added Component|c |c++ --- Comment #1 from Joseph S. Myers --- The given test is C++, not C. I can't reproduce this issue with a C test; my expectation is that both _Alignas and __attribute__ ((aligned ())) should accept arbitrarily high alignments for automatic storage duration, which appears to be the case for C (if there were a bug I'd expect it to be rejects-valid not accepts-invalid). If you (Richard) think this is a C bug, please give a specific C testcase, target and options used to compile it.
[Bug fortran/89384] [9 Regression] CONTIGUOUS dummy argument in BIND(C) interface incorrect when actual is non-contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384
--- Comment #3 from Thomas Koenig ---
This simple (too simple?) patch seems to fix things:
Index: trans-expr.c
===
--- trans-expr.c(Revision 268992)
+++ trans-expr.c(Arbeitskopie)
@@ -4944,7 +4944,12 @@ gfc_conv_gfc_desc_to_cfi_desc (gfc_se *parmse, gfc
if (e->rank != 0)
{
- gfc_conv_expr_descriptor (parmse, e);
+ if (fsym->attr.contiguous
+ && !gfc_is_simply_contiguous (e, false, true))
+ gfc_conv_subref_array_arg (parmse, e, false, fsym->attr.intent,
+ fsym->attr.pointer);
+ else
+ gfc_conv_expr_descriptor (parmse, e);
if (POINTER_TYPE_P (TREE_TYPE (parmse->expr)))
parmse->expr = build_fold_indirect_ref_loc (input_location,
[Bug c++/89393] New: [9 Regression] FAIL: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ZGR1bIvE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89393 Bug ID: 89393 Summary: [9 Regression] FAIL: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ZGR1bIvE Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Created attachment 45756 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45756=edit .s file spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu/gcc/objdir/g cc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/ref-temp1.C - fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-colo r=never -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in clude/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc ++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/lib stdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmes sage-length=0 -std=c++14 -pedantic-errors -Wno-long-long --save-temps -fno-ident -S -o ref-temp1.s PASS: g++.dg/abi/ref-temp1.C -std=c++14 (test for excess errors) FAIL: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ZGR1bIvE_ FAIL: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ZGR1bIvE0_ FAIL: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ZGR1bIvE1_ FAIL: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ZGR1bIvE2_ PASS: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler _ZGR1bIvE_:\n[^\n]+_ZGR1bIvE0_ PASS: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler _ZGR1bIvE0_:\n[^\n]+_ZGR1bIvE1_ PASS: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler _ZGR1bIvE1_:\n[^\n]+[ \t]1 PASS: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler _ZGR1bIvE2_:\n[^\n]+[ \t]4 Revision 268241 was okay. Similar fails: FAIL: g++.dg/abi/ref-temp1.C -std=c++17 scan-assembler .weak(_definition)?[ \\t]_?_ZGR1bIvE_ FAIL: g++.dg/abi/ref-temp1.C -std=c++17 scan-assembler .weak(_definition)?[ \\t]_?_ZGR1bIvE0_ FAIL: g++.dg/abi/ref-temp1.C -std=c++17 scan-assembler .weak(_definition)?[ \\t]_?_ZGR1bIvE1_ FAIL: g++.dg/abi/ref-temp1.C -std=c++17 scan-assembler .weak(_definition)?[ \\t]_?_ZGR1bIvE2_
[Bug c++/89387] [9 Regression] ICE in maybe_generic_this_capture at gcc/cp/lambda.c:945 since r268851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89387 --- Comment #2 from Jakub Jelinek --- Created attachment 45755 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45755=edit gcc9-pr89387.patch Untested fix.
[Bug fortran/89384] [9 Regression] CONTIGUOUS dummy argument in BIND(C) interface incorrect when actual is non-contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384
Thomas Koenig changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
I did a bit more of bisecting, and it seems that r267881 is the one.
With that revision, the tree dump shows
ctg (struct array01_real(kind=4) & restrict x)
{
integer(kind=8) ubound.0;
integer(kind=8) stride.1;
integer(kind=8) offset.2;
integer(kind=8) size.3;
real(kind=4)[0:D.2275] * restrict x.0;
[...]
_gfortran_gfc_desc_to_cfi_desc (, );
ctg (cfi.11);
_gfortran_cfi_desc_to_gfc_desc (, );
whereas at r267880 we get
ctg (struct array01_real(kind=4) & restrict x)
{
integer(kind=8) ubound.0;
integer(kind=8) stride.1;
[...]
D.2290 = _gfortran_internal_pack ();
parm.10.data = D.2290;
ctg ();
parm.10.data = origptr.11;
if ((real(kind=4)[0:] *) parm.10.data != (real(kind=4)[0:] *) D.2290)
{
_gfortran_internal_unpack (, D.2290);
__builtin_free (D.2290);
}
}
so it seems the pack/unpack is missing. I'm also fairly
sure that the previous code would not have worked together with C
in the absence of ISO_Fortran_binding.h :-)
[Bug c++/89391] [9 Regression] ICE in build_target_expr_with_type, at cp/tree.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89391 --- Comment #2 from Jakub Jelinek --- Created attachment 45754 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45754=edit gcc9-pr89391.patch Untested fix.
[Bug c++/89392] [7/8/9 Regression] ICE in bitmap_bit_p, at bitmap.c:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89392 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |7.5
[Bug c++/89391] [9 Regression] ICE in build_target_expr_with_type, at cp/tree.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89391 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-18 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r260622.
[Bug c++/89390] [9 Regression] ICE in get_string, at spellcheck-tree.h:46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89390 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.0 --- Comment #2 from Jakub Jelinek --- Started with r266644.
[Bug c++/89390] [9 Regression] ICE in get_string, at spellcheck-tree.h:46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89390 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-18 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 45753 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45753=edit gcc9-pr89390.patch Untested fix.
[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 --- Comment #26 from Thomas Koenig --- Fixed on gcc 9 so far. I will backport this to the other open branches, but only after the release of the next version of gcc 8.3.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #14 from Jakub Jelinek --- Created attachment 45752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45752=edit gcc9-pr89285.patch Updated untested patch for the constexpr evaluation on pre-folding trees.
[Bug c++/89392] New: [7/8/9 Regression] ICE in bitmap_bit_p, at bitmap.c:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89392
Bug ID: 89392
Summary: [7/8/9 Regression] ICE in bitmap_bit_p, at
bitmap.c:978
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-7 :
$ cat z1.cc
typedef struct {
virtual void f () {}
} s;
s t;
$ g++-6 -c z1.cc -O1 -flto -fvtable-verify=std
$
$ g++-9-20190217 -c z1.cc -O0 -flto -fvtable-verify=std
$
$ g++-9-20190217 -c z1.cc -O1 -flto -fvtable-verify=std
during GIMPLE pass: ealias
z1.cc: In function '_GLOBAL__sub_I.00099_t':
z1.cc:4:4: internal compiler error: Segmentation fault
4 | s t;
|^
0xba166f crash_signal
../../gcc/toplev.c:326
0x7bdb4e bitmap_bit_p(bitmap_head*, int)
../../gcc/bitmap.c:978
0xd2c858 do_ds_constraint
../../gcc/tree-ssa-structalias.c:1713
0xd2c858 do_complex_constraint
../../gcc/tree-ssa-structalias.c:1811
0xd2c858 solve_graph
../../gcc/tree-ssa-structalias.c:2757
0xd34fba solve_constraints
../../gcc/tree-ssa-structalias.c:7218
0xd37263 compute_points_to_sets
../../gcc/tree-ssa-structalias.c:7275
0xd37263 compute_may_aliases()
../../gcc/tree-ssa-structalias.c:7638
0xadb711 execute_function_todo
../../gcc/passes.c:1949
0xadc7f2 execute_todo
../../gcc/passes.c:2031
[Bug c++/89391] New: [9 Regression] ICE in build_target_expr_with_type, at cp/tree.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89391
Bug ID: 89391
Summary: [9 Regression] ICE in build_target_expr_with_type, at
cp/tree.c:795
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20180513 and 20180527 :
$ cat z1.cc
struct S { };
void f ()
{
auto a = reinterpret_cast(f());
}
$ g++-9-20180513 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:4:37: error: invalid cast of an rvalue expression of type 'void' to type
'S&&'
auto a = reinterpret_cast(f());
^
$ g++-9-20190217 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:4:37: internal compiler error: in build_target_expr_with_type, at
cp/tree.c:795
4 | auto a = reinterpret_cast(f());
| ^
0x735f8e build_target_expr_with_type(tree_node*, tree_node*, int)
../../gcc/cp/tree.c:795
0x745452 build_reinterpret_cast_1
../../gcc/cp/typeck.c:7484
0x745863 build_reinterpret_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:7676
0x6c035c cp_parser_postfix_expression
../../gcc/cp/parser.c:6876
0x6cc015 cp_parser_unary_expression
../../gcc/cp/parser.c:8459
0x6a9fef cp_parser_cast_expression
../../gcc/cp/parser.c:9345
0x6aa7c2 cp_parser_binary_expression
../../gcc/cp/parser.c:9446
0x6ab559 cp_parser_assignment_expression
../../gcc/cp/parser.c:9742
0x6aaf4d cp_parser_constant_expression
../../gcc/cp/parser.c:10026
0x6ab501 cp_parser_initializer_clause
../../gcc/cp/parser.c:22702
0x6aeabf cp_parser_initializer
../../gcc/cp/parser.c:22642
0x6d18ad cp_parser_init_declarator
../../gcc/cp/parser.c:20378
0x6b70be cp_parser_simple_declaration
../../gcc/cp/parser.c:13476
0x6b8be9 cp_parser_declaration_statement
../../gcc/cp/parser.c:12906
0x6b962f cp_parser_statement
../../gcc/cp/parser.c:11230
0x6ba490 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11592
0x6ba53f cp_parser_compound_statement
../../gcc/cp/parser.c:11546
0x6d0d00 cp_parser_function_body
../../gcc/cp/parser.c:22562
0x6d0d00 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:22599
0x6d0fe0 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:27666
[Bug c++/89390] New: [9 Regression] ICE in get_string, at spellcheck-tree.h:46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89390
Bug ID: 89390
Summary: [9 Regression] ICE in get_string, at
spellcheck-tree.h:46
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20181125 and 20181202 :
$ cat z1.cc
enum class a { };
void f ()
{
a::~a()
}
$ g++-9-20181125 -c z1.cc
In function 'void f()':
cc1plus: error: '~a' is not a member of 'a'
$ g++-9-20190217 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:4:7: internal compiler error: in get_string, at spellcheck-tree.h:46
4 | a::~a()
| ^
0x69446a edit_distance_traits::get_string(tree_node*)
../../gcc/spellcheck-tree.h:46
0x69446a best_match::best_match(tree_node*, unsigned
int)
../../gcc/spellcheck.h:95
0x69446a suggest_alternative_in_scoped_enum(tree_node*, tree_node*)
../../gcc/cp/name-lookup.c:5945
0x662bac qualified_name_lookup_error(tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/error.c:4280
0x71e2ab finish_id_expression_1
../../gcc/cp/semantics.c:3609
0x71e2ab finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc/cp/semantics.c:3906
0x6bae49 cp_parser_primary_expression
../../gcc/cp/parser.c:5712
0x6bfcf1 cp_parser_postfix_expression
../../gcc/cp/parser.c:7162
0x6cc015 cp_parser_unary_expression
../../gcc/cp/parser.c:8459
0x6a9fef cp_parser_cast_expression
../../gcc/cp/parser.c:9345
0x6aa7c2 cp_parser_binary_expression
../../gcc/cp/parser.c:9446
0x6ab559 cp_parser_assignment_expression
../../gcc/cp/parser.c:9742
0x6ab7e2 cp_parser_expression
../../gcc/cp/parser.c:9911
0x6ae544 cp_parser_expression_statement
../../gcc/cp/parser.c:11449
0x6b9669 cp_parser_statement
../../gcc/cp/parser.c:11245
0x6ba490 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11592
0x6ba53f cp_parser_compound_statement
../../gcc/cp/parser.c:11546
0x6d0d00 cp_parser_function_body
../../gcc/cp/parser.c:22562
0x6d0d00 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:22599
0x6d0fe0 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:27666
[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 --- Comment #25 from Thomas Koenig --- Author: tkoenig Date: Mon Feb 18 18:28:58 2019 New Revision: 268992 URL: https://gcc.gnu.org/viewcvs?rev=268992=gcc=rev Log: 2019-02-18 Thomas Koenig PR fortran/87689 * trans-decl.c (gfc_get_extern_function_decl): Add argument actual_args and pass it through to gfc_get_function_type. * trans-expr.c (conv_function_val): Add argument actual_args and pass it on to gfc_get_extern_function_decl. (conv_procedure_call): Pass actual arguments to conv_function_val. * trans-types.c (get_formal_from_actual_arglist): New function. (gfc_get_function_type): Add argument actual_args. Generate formal args from actual args if necessary. * trans-types.h (gfc_get_function_type): Add optional argument. * trans.h (gfc_get_extern_function_decl): Add optional argument. 2019-02-18 Thomas Koenig PR fortran/87689 * gfortran.dg/lto/20091028-1_0.f90: Add -Wno-lto-type-mismatch to options. * gfortran.dg/lto/20091028-2_0.f90: Likewise. * gfortran.dg/lto/pr87689_0.f: New file. * gfortran.dg/lto/pr87689_1.f: New file. Added: trunk/gcc/testsuite/gfortran.dg/lto/pr87689_0.f trunk/gcc/testsuite/gfortran.dg/lto/pr87689_1.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans-types.h trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/lto/20091028-1_0.f90 trunk/gcc/testsuite/gfortran.dg/lto/20091028-2_0.f90
[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761 --- Comment #11 from Jeffrey A. Law --- Note configuring for mips-linux will show the octeon-exts failures.
[Bug c++/82380] [concepts] Error when using requires constraint with attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82380 --- Comment #2 from Casey Carter --- You can work around this bug by using a trailing requires-clause instead of putting the requires-clause in the template-head.
[Bug libbacktrace/89362] [8/9 regression] zlib support breaks libbacktrace on strict-alignment platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89362 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Eric Botcazou --- > The problem is that most debug sections have alignment 1 so you cannot do: > > chdr = (const b_elf_chdr *) compressed; > > and expect to have a valid b_elf_chdr on strict-alignment platforms. It's a binutils issue (PR binutils/23919) fixed in 2.32 and later.
[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367 --- Comment #7 from Jakub Jelinek --- If the compiler can prove the addresses are the same or are different, then sure, it will evaluate to constant 0 or 1. The question is if the compiler must be able to prove it in all cases (which is impossible, in some cases it needs to do runtime checks and then it can't be a constant expression), and if the problematic cases include the above ones.
[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367 --- Comment #6 from Frank Secilia --- I can't find anything in the standard under `constant expressions` or `converted constant expressions` that explicitly allows non-null pointer-to-member-functions in constexpr contexts, but I also can't find anything since N4268 that explicitly forbids them. It looks like icc and msvc accept this as well. Here are some godbolt results for x86_64: clang 7.0 - https://godbolt.org/z/sg-da1 icc 19.0.1 - https://godbolt.org/z/X8eqy1 msvc 19.16 - https://godbolt.org/z/5gbv83
[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- Fixed with r268990.
[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294 --- Comment #6 from Martin Sebor --- Author: msebor Date: Mon Feb 18 16:31:17 2019 New Revision: 268990 URL: https://gcc.gnu.org/viewcvs?rev=268990=gcc=rev Log: PR middle-end/89294 - ICE in valid_constant_size_p gcc/c-family/ChangeLog: PR middle-end/89294 * c-common.c (invalid_array_size_error): Handle cst_size_not_constant. gcc/ChangeLog: PR middle-end/89294 * tree.c (valid_constant_size_p): Avoid assuming size is a constant expression. * tree.h (cst_size_error): Add the cst_size_not_constant enumerator. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug c++/89389] New: inlining failed in call to always_inline -- removing attribute leaves function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89389 Bug ID: 89389 Summary: inlining failed in call to always_inline -- removing attribute leaves function inlined Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: peter_foelsche at mentor dot com Target Milestone: --- Some member function is labeled __attribute__((always_inline)) inline as are many others. This is generated code and has been working for many cases. Today I had the first error of this kind. When removing the attribute the code compiles fine AND does not generate a function call. The function itself is trivial (there are many functions for which always_inline is successful, which are more complicated. The same error happens with g++ 5.3.0 g++ 5.5.0 g++ 7.3.0 g++ 8.2.0 compiler options are -fPIC -I include -O3 -DNDEBUG -funroll-loops -march=native -ffast-math -fwhole-program -ftemplate-depth=16384 -march=native -shared -std=c++11 -Wno-attributes -I $BOOST_DIR I'm not certain if I can provide the source code (or any preprocessed file) -- I'll have to ask.
[Bug preprocessor/89373] macro expansion not counting braces correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89373 --- Comment #4 from mdblack98 at yahoo dot com --- FYI...the variadic macro __VA_ARGS__ did solve the braced items problem on array initialization in nested macros. Just have to move the argument to the end of the macro... Thanks Mike
[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #11 from Andrey Drobyshev ---
(In reply to Martin Liška from comment #9)
> (In reply to Andrey Drobyshev from comment #8)
>
> Great you've been working on that Andrey.
>
> > I recently started to work on this issue as well. I managed to put a dummy
> > global variable into .data, .rodata and .bss as follows:
> >
> > static void
> > emit_globals_protector(void)
> > {
> > tree decl, id, init;
> >
> > id = get_identifier ("__asan_dummy_global");
> > decl = build_decl (BUILTINS_LOCATION, VAR_DECL, id, integer_type_node);
> > init = build_one_cst(integer_type_node);
> >
> > SET_DECL_ASSEMBLER_NAME (decl, id);
> > TREE_ADDRESSABLE (decl) = 1;
> > DECL_ARTIFICIAL (decl) = 1;
> > TREE_STATIC (decl) = 1;
> > TREE_PUBLIC (decl) = 1;
> > TREE_USED (decl) = 1;
> >
> > TREE_READONLY (init) = 1; // controls whether variable goes to
> > .rodata or .data
> > TREE_STATIC (init) = 1;
> > DECL_INITIAL (decl) = init;// controls whether variable gets
> > initialized or goes to .bss
> >
> > varpool_node::add(decl);
> > }
> >
> > Calling varpool_node::add() makes sure that created dummy global goes first
> > into the target section, as it leads to call to assemble_variable():
> >
> > #0 categorize_decl_for_section (decl=0x77ff4e10, reloc=0) at
> > ../../gcc/varasm.c:6378
> > #1 0x01096112 in default_elf_select_section (decl=0x77ff4e10,
> > reloc=0, align=256) at ../../gcc/varasm.c:6499
> > #2 0x010b6ce3 in x86_64_elf_select_section (decl=0x77ff4e10,
> > reloc=0, align=256) at ../../gcc/config/i386/i386.c:6549
> > #3 0x0108afd3 in get_variable_section (decl=0x77ff4e10,
> > prefer_noswitch_p=false) at ../../gcc/varasm.c:1170
> > #4 0x0108d70b in assemble_variable (decl=0x77ff4e10,
> > top_level=0, at_end=1, dont_output_data=0) at ../../gcc/varasm.c:2206
> > #5 0x0109fd8a in varpool_node::assemble_decl (this=0x77281100)
> > at ../../gcc/varpool.c:582
> > #6 0x00917f92 in varpool_node::finalize_decl (decl=0x77ff4e10)
> > at ../../gcc/cgraphunit.c:823
> > #7 0x0109f9c0 in varpool_node::add (decl=0x77ff4e10) at
> > ../../gcc/varpool.c:473
> > #8 0x0091ba93 in emit_globals_protector () at
> > ../../gcc/cgraphunit.c:2187
> > #9 0x0091bab6 in output_in_order (no_reorder=false) at
> > ../../gcc/cgraphunit.c:2218
> > #10 0x0091c4f4 in symbol_table::compile (this=0x771280a8) at
> > ../../gcc/cgraphunit.c:2524
> > #11 0x0091c73f in symbol_table::finalize_compilation_unit
> > (this=0x771280a8) at ../../gcc/cgraphunit.c:2620
> > #12 0x00d90fbf in compile_file () at ../../gcc/toplev.c:496
> > #13 0x00d93448 in do_compile () at ../../gcc/toplev.c:1998
> > #14 0x00d936d2 in toplev::main (this=0x7fffdbb0, argc=27,
> > argv=0x7fffdcb8) at ../../gcc/toplev.c:2106
> > #15 0x016e11d1 in main (argc=27, argv=0x7fffdcb8) at
> > ../../gcc/main.c:39
>
> Can you please provide work-in-progress patch so that I can play with that?
> Is your patch also handling the comment:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c4
>
I guess it's not. I was only able to test this thing on x86_64 and armv7l.
> >
> > However, there're questions:
> > 1. I wonder is it really possible to emit zero-sized dummies and initialize
> > them as well (i.e. emit them into .data/.rodata)? For now I emit variables
> > of integer types, but that leads to the presence of couple addressable bytes
> > in the beginning of the section.
>
> I can investigate once I have a patch candidate.
>
Please see attachment above.
> > 2. What should we do with sections like .data.rel.ro, .data.rel.ro.local?
> > They suffer from this bug too, but it's not that easy to put globals there,
> > as you must set various attributes onto decl to ensure it will receive the
> > right reloc value.
>
> @Jakub: Can you advise please about the question #2?
>
These questions remain unanswered...
[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501 --- Comment #10 from Andrey Drobyshev --- Created attachment 45751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45751=edit Work-in-progress fix This patch is pretty raw. It only handles .data, .rodata and .bss. It does not handle reallocation sections and multi-TU case (though the latter apparently needs linker support). I suppose we should introduce a separate flag for this kind of protection (ideas are welcome). Also I have to pass the whole list of varpool nodes one extra time to detect sections which need protection; maybe it could be optimized. Comments?
[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- So fix-r4000-10.c is the only one that's still failing for me on the trunk.
[Bug fortran/89388] Component selection for assumed-size DT array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89388 --- Comment #1 from Bader at lrz dot de --- Actually, C1002 applies for expressions, which is not relevant for this case ... the only (non-constraint) restriction that one could (indirectly) argue to apply is 9.5.2 para2, inasmuch as the shape is needed to create the contiguous element sequence.
[Bug c++/80871] Template partial ordering considered non-ambiguous with deduced and non-deduced parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80871 Ed Catmur changed: What|Removed |Added CC||ed at catmur dot uk --- Comment #2 from Ed Catmur --- See also #80438
[Bug c++/80871] Template partial ordering considered non-ambiguous with deduced and non-deduced parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80871 --- Comment #3 from Ed Catmur --- Sorry. See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80438
[Bug target/89324] [9 Regression] ICE in extract_constrain_insn, at recog.c:2211 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324 --- Comment #4 from Matthew Malcomson --- There were similar problems in handling the stack pointer with subs/adds instructions elsewhere in the aarch64 backend. Patch proposed & being worked on here: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01458.html
[Bug c++/89387] [9 Regression] ICE in maybe_generic_this_capture at gcc/cp/lambda.c:945 since r268851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89387
--- Comment #1 from Martin Liška ---
Reduced test-case:
$ cat ice.ii
template class a> class b {
using c = int;
using f = a;
f::d;
void e() {
[&] { d(); };
}
void d();
};
[Bug fortran/89388] New: Component selection for assumed-size DT array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89388 Bug ID: 89388 Summary: Component selection for assumed-size DT array Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45750=edit test code The attached test case, which is non-conforming (because it requires copy-in/out of an assumed-size object) compiles and creates an executable that crashes with a SIGSEGV. It would be good if a compile-time error could be created for this case. E.g. ifort says: The upper bound shall not be omitted in the last dimension of a reference to an assumed size array. nagfor says: dt_ass_neg_03.f90, line 10: Invalid appearance of assumed-size array name Y The Fortran 2018 constraint that applies is C1002 (10.1.2.2) Regards
[Bug c++/82380] [concepts] Error when using requires constraint with attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82380 Avi Kivity changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #1 from Avi Kivity --- Suffering from the same problem (but with [[deprecated]] instead).
[Bug tree-optimization/89296] [7/8 Regression] tree copy-header masking uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] tree |[7/8 Regression] tree |copy-header masking |copy-header masking |uninitialized warning |uninitialized warning Known to fail|9.0 | --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/89296] [7/8/9 Regression] tree copy-header masking uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Feb 18 12:56:15 2019 New Revision: 268986 URL: https://gcc.gnu.org/viewcvs?rev=268986=gcc=rev Log: 2019-02-18 Richard Biener PR tree-optimization/89296 * tree-ssa-loop-ch.c (ch_base::copy_headers): Restrict setting of no-warning flag to cases that might emit the bogus warning. * gcc.dg/uninit-pr89296.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/uninit-pr89296.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ch.c
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #45 from Jakub Jelinek --- Author: jakub Date: Mon Feb 18 12:52:36 2019 New Revision: 268985 URL: https://gcc.gnu.org/viewcvs?rev=268985=gcc=rev Log: PR bootstrap/88714 * config/arm/arm.md (*arm_movdi, *movdf_soft_insn): Use "r" instead of "q" constraint. * config/arm/vfp.md (*movdi_vfp): Likewise. * config/arm/ldrdstrd.md (*arm_ldrd, *arm_strd): Use "r" instead of "q" constraint for operands[0]. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/ldrdstrd.md trunk/gcc/config/arm/vfp.md
[Bug c++/89387] [9 Regression] ICE in maybe_generic_this_capture at gcc/cp/lambda.c:945 since r268851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89387 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Known to work||8.2.0 Keywords||ice-on-valid-code Last reconfirmed||2019-02-18 CC||aoliva at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |9.0 Known to fail||9.0
[Bug c++/89387] New: [9 Regression] ICE in maybe_generic_this_capture at gcc/cp/lambda.c:945 since r268851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89387 Bug ID: 89387 Summary: [9 Regression] ICE in maybe_generic_this_capture at gcc/cp/lambda.c:945 since r268851 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 45749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45749=edit Unreduced test-case I see following ICE: $ c++ ice.ii -c ... 0xf2d19f crash_signal /home/marxin/Programming/gcc/gcc/toplev.c:326 0x77b79e0f ??? /usr/src/debug/glibc-2.29-1.3.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x9141f1 maybe_generic_this_capture(tree_node*, tree_node*) /home/marxin/Programming/gcc/gcc/cp/lambda.c:945 0x968904 cp_parser_postfix_expression /home/marxin/Programming/gcc/gcc/cp/parser.c:7331 0x975766 cp_parser_unary_expression /home/marxin/Programming/gcc/gcc/cp/parser.c:8459 0x951402 cp_parser_cast_expression /home/marxin/Programming/gcc/gcc/cp/parser.c:9345 0x951bea cp_parser_binary_expression /home/marxin/Programming/gcc/gcc/cp/parser.c:9447 0x952b29 cp_parser_assignment_expression /home/marxin/Programming/gcc/gcc/cp/parser.c:9744 0x952e92 cp_parser_expression /home/marxin/Programming/gcc/gcc/cp/parser.c:9911 0x956374 cp_parser_expression_statement /home/marxin/Programming/gcc/gcc/cp/parser.c:11449 0x961003 cp_parser_statement /home/marxin/Programming/gcc/gcc/cp/parser.c:11245 0x962550 cp_parser_statement_seq_opt /home/marxin/Programming/gcc/gcc/cp/parser.c:11592 0x962627 cp_parser_compound_statement /home/marxin/Programming/gcc/gcc/cp/parser.c:11546 0x97cb85 cp_parser_implicitly_scoped_statement /home/marxin/Programming/gcc/gcc/cp/parser.c:12961 0x961f3b cp_parser_selection_statement /home/marxin/Programming/gcc/gcc/cp/parser.c:11766 0x961f3b cp_parser_statement /home/marxin/Programming/gcc/gcc/cp/parser.c:1 0x962550 cp_parser_statement_seq_opt /home/marxin/Programming/gcc/gcc/cp/parser.c:11592 0x963a8e cp_parser_lambda_body /home/marxin/Programming/gcc/gcc/cp/parser.c:10978 0x963a8e cp_parser_lambda_expression /home/marxin/Programming/gcc/gcc/cp/parser.c:10454 0x963a8e cp_parser_primary_expression /home/marxin/Programming/gcc/gcc/cp/parser.c:5379 I'm reducing that..
[Bug debug/86964] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #7 from Richard Biener ---
Created attachment 45748
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45748=edit
patch
Thanks for working on this. For
extern float x;
void foo()
{
}
I still see the basetype DIE for float emitted. When using
struct S { int i; };
extern struct S x;
the DIE for S disappears (good) but the one for int remains. That looks like
a pre-exisiting issue with unused debug-types elimination though.
I have attached a patch variant that applies to trunk and maintained branches
that fixes some coding-style issues, adds a testcase and a ChangeLog entry.
Can you see if it looks fine to you and propose the patch on
gcc-patc...@gcc.gnu.org ?
[Bug target/89369] [9 Regression] pseudo-RNG miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r266203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89369 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/89361] [7/8 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] s390 |[7/8 Regression] s390 |broken without |broken without |S390_USE_TARGET_ATTRIBUTE, |S390_USE_TARGET_ATTRIBUTE, |likely since r257489|likely since r257489 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/89369] [9 Regression] pseudo-RNG miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r266203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89369 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Mon Feb 18 11:20:43 2019 New Revision: 268984 URL: https://gcc.gnu.org/viewcvs?rev=268984=gcc=rev Log: PR target/89369 * config/s390/s390.md (*rsbg__srl_bitmask, *rsbg__sll, *rsbg__srl): Don't construct pattern in a temporary buffer. (*rsbg_sidi_srl): Likewise. Always use 32 as I3 rather than 64-operands[2]. * gcc.c-torture/execute/pr89369.c: New test. * gcc.target/s390/md/rXsbg_mode_sXl.c (rosbg_si_srl, rxsbg_si_srl): Expect last 3 operands 32,63,62 rather than 34,63,62. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr89369.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/s390/md/rXsbg_mode_sXl.c
[Bug target/89361] [7/8/9 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Mon Feb 18 11:16:33 2019 New Revision: 268983 URL: https://gcc.gnu.org/viewcvs?rev=268983=gcc=rev Log: PR target/89361 * config/s390/s390.c (s390_indirect_branch_attrvalue, s390_indirect_branch_settings): Define unconditionally. (s390_set_current_function): Likewise, but guard the whole body except the s390_indirect_branch_settings call with #if S390_USE_TARGET_ATTRIBUTE. (TARGET_SET_CURRENT_FUNCTION): Redefine unconditionally. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c
[Bug c++/88680] [9 Regression] bogus -Wtype-limits for constant expressions after r267272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88680 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from Christophe Lyon --- (In reply to David Malcolm from comment #4) > Should be fixed by r268961. The new test fails on arm-eabi (works on arm-linux-gnueabi), probably because it defaults to short enum: FAIL: g++.dg/wrappers/pr88680.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/wrappers/pr88680.C -std=gnu++17 (test for excess errors) The logs say: Excess errors: /gcc/testsuite/g++.dg/wrappers/pr88680.C:10:20: warning: comparison is always true due to limited range of data type [-Wtype-limits] /gcc/testsuite/g++.dg/wrappers/pr88680.C:20:11: warning: comparison is always true due to limited range of data type [-Wtype-limits] /gcc/testsuite/g++.dg/wrappers/pr88680.C:46:9: warning: comparison is always true due to limited range of data type [-Wtype-limits]
[Bug tree-optimization/89386] New: Generation of vectorized MULHRS (Multiply High with Round and Scale) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89386
Bug ID: 89386
Summary: Generation of vectorized MULHRS (Multiply High with
Round and Scale) instruction
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
This PR is similar to PR85693 and PR85694, where missing generation of
vectorized SAD (Sum of Absolute Difference) and AVG (Average) instruction was
reported.
Following code:
--cut here--
#define N 1024
unsigned short as[N], bs[N], cs[N];
void
foo_short (void)
{
int i;
for (i = 0; i < N; i++)
as[i] = int)bs[i] * (int)cs[i]) >> 14) + 1) >> 1;
}
--cut here--
should vectorize with pmulhrsw SSSE3 instruction.
[Bug c++/80438] Variadic template class argument deduction failure from variadic constructor deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80438 Ed Catmur changed: What|Removed |Added CC||ed at catmur dot uk --- Comment #2 from Ed Catmur --- Workaround: add an N=1+ deduction guide: // existing template foo(Us...) -> foo; // additional, for g++ template foo(U, Us...) -> foo;
[Bug d/89177] unaligned memory access in libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89177 --- Comment #3 from Bernd Edlinger --- Have started a test on my ARM hardware, it will take a few days to run the complete test suite. BTW: I also have an issue with the install script of libphobos: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01322.html how can this be resolved ?
[Bug c++/89381] [7/8/9 Regression] Implicit copy constructor cannot be generated after unrelated class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89381 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.5
[Bug c++/89383] [9 Regression] libcpp/line-map.c:748:15: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89383 Richard Biener changed: What|Removed |Added Version|unknown |9.0 Target Milestone|--- |9.0
[Bug rtl-optimization/89378] [9 regression][MIPS] FAIL: gcc.dg/vect/pr88598-3.c -mmsa (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89378 Richard Biener changed: What|Removed |Added Target||mips Target Milestone|--- |9.0 --- Comment #1 from Richard Biener --- MSA is new, so not sure if it is a regression. Please fill out known-to-work.
[Bug c++/89370] Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89370 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-18 Ever confirmed|0 |1
[Bug libbacktrace/89362] [8/9 regression] zlib support breaks libbacktrace on strict-alignment platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89362 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug target/89361] [7/8/9 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361 Richard Biener changed: What|Removed |Added Target||s390*-*-* Priority|P3 |P2
[Bug c++/89383] [9 Regression] libcpp/line-map.c:748:15: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89383 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug c++/89383] [9 Regression] libcpp/line-map.c:748:15: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89383 --- Comment #2 from Martin Liška --- Author: marxin Date: Mon Feb 18 09:46:19 2019 New Revision: 268981 URL: https://gcc.gnu.org/viewcvs?rev=268981=gcc=rev Log: Use 1UL constant in order to not overflow (PR c++/89383). 2019-02-18 Martin Liska PR c++/89383 * line-map.c (linemap_line_start): Use 1UL in order to not overflow. Modified: trunk/libcpp/ChangeLog trunk/libcpp/line-map.c
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.5
[Bug rtl-optimization/89354] [7 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Priority|P3 |P2 Known to work||8.2.1, 9.0 Known to fail||7.4.0
[Bug middle-end/89351] internal compiler error: in exact_div, at poly-int.h:2139 with -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89351 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-18 Summary|internal compiler error: in |internal compiler error: in |exact_div, at |exact_div, at |poly-int.h:2139 |poly-int.h:2139 with ||-fgnu-tm Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- IIRC seeing dups with bitfield handling of TM.
[Bug ipa/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid Priority|P3 |P2
[Bug c/89340] [7/8 Regression] ICE in function_and_variable_visibility, at ipa-visibility.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89340 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 --- Comment #11 from Richard Biener --- (In reply to Rafael Avila de Espindola from comment #10) > Maybe we should have a general flag that disables all warnings where gcc > cannot prove that there is a path from a function entry to the broken > statement? But what about proving there is a path from program entry to the function? And now reason why those two are different.
[Bug lto/89335] [9 Regression] ICE with LTO -Wsuggest-final-methods: ICE during IPA pass devirt in types_same_for_odr, at ipa-devirt.c:391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89335 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug inline-asm/89334] unsupported size for integer register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-18 Ever confirmed|0 |1 --- Comment #8 from Richard Biener --- Confirmed for diagnostic improvement.
[Bug tree-optimization/89332] Missed detection of dead stores to array in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89332 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-18 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- In general we lack sth like (sub-)array liveness analysis to guide loop opts that would help here. Yes, aggressive unrolling makes scalar opts do the job but that's hardly the solution we should strive for. These kind of testcases also look quite artificial.
[Bug fortran/89384] [9 Regression] CONTIGUOUS dummy argument in BIND(C) interface incorrect when actual is non-contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||7.4.0, 8.2.0 Keywords||wrong-code Last reconfirmed||2019-02-18 Ever confirmed|0 |1 Summary|CONTIGUOUS dummy argument |[9 Regression] CONTIGUOUS |in BIND(C) interface|dummy argument in BIND(C) |incorrect when actual is|interface incorrect when |non-contiguous |actual is non-contiguous Target Milestone|--- |9.0 Known to fail||9.0 --- Comment #1 from Dominique d'Humieres --- Confirmed between revisions r267817 (2019-01-10, OK) and r268015 (2019-01-17, FAIL), likely r267905 (pr57992).
[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331 Richard Biener changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P2
[Bug other/89327] Joined options without RejectsNegative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89327 --- Comment #1 from Richard Biener --- Yeah, all of them look to miss RejectNegative
[Bug ipa/89009] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Martin Liška --- Fixed.
[Bug fortran/89385] Incorrect members of C descriptor for an allocatable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385 --- Comment #1 from Bader at lrz dot de --- Further comment: Analogous failures also happen for descriptors of assumed-shape or POINTER objects. I suggest that I re-test these when this bug is fixed and submit a separate report if still necessary. Regards Reinhold
[Bug c++/89325] [7/8/9 Regression] False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325 Richard Biener changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P2 Target Milestone|--- |7.5 Summary|False warnings about|[7/8/9 Regression] False |"optimization attribute" on |warnings about |operators when |"optimization attribute" on |-fno-ipa-cp-clone |operators when ||-fno-ipa-cp-clone
[Bug target/89324] [9 Regression] ICE in extract_constrain_insn, at recog.c:2211 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Version|unknown |9.0
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-18 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/89385] New: Incorrect members of C descriptor for an allocatable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385 Bug ID: 89385 Summary: Incorrect members of C descriptor for an allocatable object Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45747=edit test code The attached test case provides a C and a Fortran file. If built with gcc -c alloc_01_pos.c gfortran alloc_01_pos.f90 alloc_01_pos.o the resulting executable prints failure messages with respect to many members of the C descriptor (elem_len, type, rank, attribute, dim[]). Regards
[Bug tree-optimization/89314] [7 Regression] ICE in wide_int_to_tree_1, at tree.c:1561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89314 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/89313] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug gcov-profile/89307] -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307 --- Comment #7 from Richard Biener --- Btw, use of TLS has * size of counters overhead (one could use char sized TLS counters and update the global ones with locking on overflow) * tear-down/build-up cost at thread termination/creation the advantage is of course it's simple implementation-wise.
[Bug tree-optimization/89209] [9 Regression] ICE in build_ref_for_model, at tree-sra.c:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89209 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor --- Fixed.
[Bug tree-optimization/89209] [9 Regression] ICE in build_ref_for_model, at tree-sra.c:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89209 --- Comment #7 from Martin Jambor --- Author: jamborm Date: Mon Feb 18 08:59:04 2019 New Revision: 268980 URL: https://gcc.gnu.org/viewcvs?rev=268980=gcc=rev Log: [PR 89209] Avoid segfault in a peculiar corner case in SRA 2019-02-18 Martin Jambor PR tree-optimization/89209 * tree-sra.c (create_access_replacement): New optional parameter reg_tree. Use it as a type if non-NULL and access type is not of a register type. (get_repl_default_def_ssa_name): New parameter REG_TYPE, pass it to create_access_replacement. (sra_modify_assign): Pass LHS type to get_repl_default_def_ssa_name. Check lacc is non-NULL before attempting to re-create it on the RHS. testsuite/ * gcc.dg/tree-ssa/pr89209.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr89209.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug fortran/89364] Assumed rank object with incorrect values for shape and bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW CC||tkoenig at gcc dot gnu.org
[Bug tree-optimization/89296] [7/8/9 Regression] tree copy-header masking uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|NEW |ASSIGNED
Assignee|kugan at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |7.5
--- Comment #2 from Richard Biener ---
This gimple_set_no_warning is guarded by
/* If the loop has the form "for (i = j; i < j + 10; i++)" then
this copying can introduce a case where we rely on undefined
signed overflow to eliminate the preheader condition, because
we assume that "j < j + 10" is true. We don't want to warn
about that case for -Wstrict-overflow, because in general we
don't warn about overflow involving loops. Prevent the
warning by setting the no_warning flag in the condition. */
if (warn_strict_overflow > 0)
{
so it only shows that the _no_warning stuff is too coarse (we know about that).
We can improve the above to non-equality compares, catching the case in
question.
[Bug fortran/89384] New: CONTIGUOUS dummy argument in BIND(C) interface incorrect when actual is non-contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384 Bug ID: 89384 Summary: CONTIGUOUS dummy argument in BIND(C) interface incorrect when actual is non-contiguous Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45746=edit test code Fortran 2018 permits CONTIGUOUS dummy arguments also in BIND(C) interfaces. However, currently the passing of a compactified copy required for non-contiguous actual arguments does not work correctly in this context. A test case is attached. Note that the problem does not arise if BIND(C) is removed from the procedure definition.
[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/89292] [9 regression] test case gcc.target/powerpc/rs6000-fpint.c fails after r268705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89292 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/89288] [9 Regression] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288 Richard Biener changed: What|Removed |Added Priority|P3 |P1
