[Bug c++/98750] does not detect dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98750 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING CC||marxin at gcc dot gnu.org Last reconfirmed||2021-01-20 Ever confirmed|0 |1
[Bug c++/98761] [modules] use of a module causes SIGSEGV at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98761 --- Comment #1 from Boris Kolpackov --- Created attachment 50011 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50011=edit Reproducer
[Bug c++/98761] New: [modules] use of a module causes SIGSEGV at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98761 Bug ID: 98761 Summary: [modules] use of a module causes SIGSEGV at runtime Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- The attached executable catches SIGSEGV when built with a module: $ g++ -std=c++2a -fmodules-ts -x c++ -c format.mxx $ g++ -std=c++2a -fmodules-ts -x c++ -c driver.cxx $ g++ -std=c++2a -fmodules-ts -o test driver.o format.o $ ./test Segmentation fault (core dumped) $ gdb test core (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:148 #1 0x00402cc7 in std::char_traits::copy(char*, char const*, unsigned long) () #2 0x0040405c in std::__cxx11::basic_string, std::allocator >::_S_copy(char*, char const*, unsigned long) () #3 0x00403f72 in std::__cxx11::basic_string, std::allocator >::_S_copy_chars(char*, char const*, char const*) () #4 0x004039b0 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*, std::forward_iterator_tag) () #5 0x00403635 in void std::__cxx11::basic_string, std::allocator >::_M_construct_aux(char const*, char const*, std::__false_type) () #6 0x00403337 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*) () #7 0x00403072 in std::__cxx11::basic_string, std::allocator >::basic_string(char const*, unsigned long, std::allocator const&) () #8 0x004033fc in std::__cxx11::basic_string, std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator >::__sv_wrapper, std::allocator const&) () #9 0x004030ef in std::__cxx11::basic_string, std::allocator >::basic_string >, void>(std::basic_string_view > const&, std::allocator const&) () #10 0x0040266b in hello::format_hello[abi:cxx11](std::basic_string_view > const&) () #11 0x004020be in main () The same code works fine if I get rid of the module. Re-ordering the object files during linking also helps: $ g++ -std=c++2a -fmodules-ts -o test format.o driver.o
[Bug c++/98753] -Wfree-nonheap-object on Bison generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 --- Comment #4 from Christoph --- Created attachment 50010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50010=edit C++ file generated by Bison run with -E Including all dependencies, created by GCC 11 with added -E
[Bug c++/98742] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in finish_omp_clauses, at cp/semantics.c:7435 since r11-6752-ga6d22fb21c6f1ad7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98742 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7ab1abf3b82a3bcfff9b7bc596166fef6a0d83ab commit r11-6810-g7ab1abf3b82a3bcfff9b7bc596166fef6a0d83ab Author: Jakub Jelinek Date: Wed Jan 20 08:35:20 2021 +0100 openmp: Don't ICE on detach clause with erroneous decl [PR98742] Similarly to how we handle erroneous operands to e.g. allocate clause, this change just removes those clauses instead of accessing TYPE_MAIN_VARIANT of its type, which doesn't work on error_mark_node. Also, just for good measure, bails out if TYPE_NAME is NULL. 2021-01-20 Jakub Jelinek PR c++/98742 * semantics.c (finish_omp_clauses) : If error_operand_p, remove clause without further checking. Check for non-NULL TYPE_NAME. * c-c++-common/gomp/task-detach-2.c: New test.
[Bug testsuite/98757] New test case gfortran.dg/gomp/is_device_ptr-2.f90 in r11-6787 fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98757 --- Comment #3 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c05cdfb3f6335d55226cef7917a783498aa41244 commit r11-6809-gc05cdfb3f6335d55226cef7917a783498aa41244 Author: Tobias Burnus Date: Wed Jan 20 08:31:30 2021 +0100 OpenMP/Fortran: Fix gfortran.dg/gomp/is_device_ptr-2.f90 gcc/testsuite/ChangeLog: PR fortran/98757 PR fortran/98476 * gfortran.dg/gomp/is_device_ptr-2.f90: Fix dg-error.
[Bug fortran/98476] OpenMP offload syntax restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98476 --- Comment #7 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c05cdfb3f6335d55226cef7917a783498aa41244 commit r11-6809-gc05cdfb3f6335d55226cef7917a783498aa41244 Author: Tobias Burnus Date: Wed Jan 20 08:31:30 2021 +0100 OpenMP/Fortran: Fix gfortran.dg/gomp/is_device_ptr-2.f90 gcc/testsuite/ChangeLog: PR fortran/98757 PR fortran/98476 * gfortran.dg/gomp/is_device_ptr-2.f90: Fix dg-error.
[Bug testsuite/98757] New test case gfortran.dg/gomp/is_device_ptr-2.f90 in r11-6787 fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98757 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563858.html
[Bug tree-optimization/98758] [9/10/11 Regression] ice in lambda_matrix_right_hermite by r9-3927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98758 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|11.0|9.4 --- Comment #2 from Richard Biener --- I will investigate (the patch increased the value range so likely a slightly different testcase is broken earlier).
[Bug testsuite/98757] New test case gfortran.dg/gomp/is_device_ptr-2.f90 in r11-6787 fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98757 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||x86_64-*-* Ever confirmed|0 |1 Last reconfirmed||2021-01-20 --- Comment #1 from Richard Biener --- Confirmed.
[Bug debug/98755] [11 regression] r11-6755 causes failure in g++.dg/debug/dwarf2/constexpr-var-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |11.0
[Bug c++/98753] -Wfree-nonheap-object on Bison generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 --- Comment #3 from Richard Biener --- The issue is that we isolate a path that is impossible to take but on that path we have p = free (p); and thus a "proved" mistake. But in reality it is guarded by an effective if (false) condition. So it's not as simple as you think. (we also emit diagnostics on function bodies we do not know are actually never called)
[Bug c++/98760] [modules] ICE in add_module_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760 --- Comment #1 from Boris Kolpackov --- Created attachment 50009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50009=edit Reproducer
[Bug c++/98760] New: [modules] ICE in add_module_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760
Bug ID: 98760
Summary: [modules] ICE in add_module_decl
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
The attached set of modules cause an internal compiler error:
c++ mxx{format}
c++ mxx{check}
c++ mxx{hello}
c++ cxx{hello}
/home/boris/work/build2/tests/modules/gcc2/bugs/x/hello.cxx: In function ‘void
hello::say_hello(std::ostream&, const string_view&)’:
/home/boris/work/build2/tests/modules/gcc2/bugs/x/hello.cxx:18:10: internal
compiler error: in add_module_decl, at cp/name-lookup.c:4188
18 | o << format_hello (n) << std::endl;
| ^~~~
0xc8ff5c add_module_decl(tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/name-lookup.c:4188
0xc5cc17 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14888
0xc66826 module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18036
0xc68b6c lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/gcc/cp/module.cc:18718
0xc80298 name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:918
0xc80f82 name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/gcc/cp/name-lookup.c:1149
0xc9b77d lookup_name_1
../../gcc/gcc/cp/name-lookup.c:7910
0xc9b86d lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/gcc/cp/name-lookup.c:7930
0xb6f6d5 lookup_name(tree_node*, LOOK_want)
../../gcc/gcc/cp/name-lookup.h:413
0xce7da2 cp_parser_lookup_name
../../gcc/gcc/cp/parser.c:29285
0xcddbf9 cp_parser_class_name
../../gcc/gcc/cp/parser.c:24612
0xcd1b56 cp_parser_type_name
../../gcc/gcc/cp/parser.c:19162
0xcd108d cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:18865
0xcb90d9 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7420
0xcbc6aa cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8818
0xcbddc5 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9722
0xcea805 cp_parser_simple_cast_expression
../../gcc/gcc/cp/parser.c:30478
0xcbe1d5 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9890
0xcbedc7 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:10128
0xcbf135 cp_parser_expression
../../gcc/gcc/cp/parser.c:10298
[Bug c++/98753] -Wfree-nonheap-object on Bison generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 Akim Demaille changed: What|Removed |Added CC||akim.demaille at gmail dot com --- Comment #2 from Akim Demaille --- Hi, I can't tell if it's the same bug of not, but there have never complaints about this piece of code before GCC11, so something has most likely changed recently. Note also that the 'free' is under an 'if' that clearly makes the diagnostic wrong (I mean, there's no need to solve the halting problem here, all the information is statically available). Besides, I would like to stress something that was said in the other PR (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202#c6): > If you can't fix GCC so that it can prove that the free is on a non-heap > object, then please change the warning to indicate that GCC may be wrong. For > example: > > warning: free() may be called with non-heap object 'name' Thiago Macieira is right: the warning claims "there is an error", but it only *suspects* that there is one. The wording is misleading and should be fixed. Cheers!
[Bug target/98759] New: arm cortex-r5 single precisions flotaing point generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98759 Bug ID: 98759 Summary: arm cortex-r5 single precisions flotaing point generation Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dallred at tesla dot com Target Milestone: --- Created attachment 50008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50008=edit Simple source file for replication Trying to compile the simple floating point C function in the attached C file, for an embedded Cortex-R5F core that does not support double precision in the VFPv3, to an object file using either of the following: $ arm-none-eabi-gcc -mcpu=cortex-r5+nofp.dp -mfloat-abi=hard -o float-test.o -c float-test.c $ arm-none-eabi-gcc -march=armv7-r+vfpv3xd -mfloat-abi=hard -o float-test.o -c float-test.c These two commands should be equivalent, and are, but they both fail at the assembly step with a message like the following: tmp/cc5XbvoO.s: Assembler messages: /tmp/cc5XbvoO.s:42: Error: selected processor does not support `vmul.f32 s15,s14,s15' in ARM mode The -mfloat-abi can be either 'hard' or 'softfp', result is the same. This was observed using the prepackaged GCC downloads for Cortex-R/M made available by ARM: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads This issue is observed using both gcc-arm-none-eabi-10-2020-q4-major and gcc-arm-none-eabi-9-2020-q2-update. To me, it seems the generated assembly is correct. I can't fathom why the assembler is complaining and I don't know why it is saying this instruction is not supported in ARM mode. Interestingly, using the -mthumb flag does allow the compilation to object file succeed. I can find no evidence of VFP instructions being restricted to either ARM or Thumb2 mode of the processor.
[Bug tree-optimization/98758] [9/10/11 Regression] ice in lambda_matrix_right_hermite by r9-3927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98758 H.J. Lu changed: What|Removed |Added Summary|[11 Regression] ice in |[9/10/11 Regression] ice in |lambda_matrix_right_hermite |lambda_matrix_right_hermite ||by r9-3927 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-01-20 --- Comment #1 from H.J. Lu --- 1c8badf66bec4e0ff73ae24bf4f8cabbef8c137a is the first bad commit commit 1c8badf66bec4e0ff73ae24bf4f8cabbef8c137a Author: Richard Biener Date: Thu Nov 8 12:15:49 2018 + tree-data-ref.h (lambda_int): New typedef. 2018-11-08 Richard Biener * tree-data-ref.h (lambda_int): New typedef. (lambda_vector_gcd): Adjust. (lambda_vector_new): Likewise. (lambda_matrix_new): Likewise. * tree-data-ref.c (print_lambda_vector): Adjust.
[Bug target/98065] [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7024 since r11-5457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065 --- Comment #4 from luoxhu at gcc dot gnu.org --- Sorry, my patch https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555906.html could fix this, but below two of them is still pending for approval, I pinged it 5 times since last Oct. @Segher :) https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555907.html https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555908.html
[Bug middle-end/98266] [11 Regression] bogus array subscript is partly outside array bounds on virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98266 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563894.html
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646
--- Comment #11 from Martin Sebor ---
(In reply to Marek Polacek from comment #5)
> A better one:
>
> // PR c++/98646
> // { dg-do compile }
> // { dg-options "-Wnonnull" }
>
> struct B {
> void foo();
> };
>
> struct D : B {
> void show();
> };
>
> void
> D::show()
> {
> constexpr void *p = nullptr;
> if (p)
> static_cast(p)->foo();
> }
This test case isn't representative of the reported problem. It shows the
general issue with the front-end part of -Wnonnull as well as with and most
other flow-based front end warnings. An equivalent test case that shows the
same issue with GCC 10 and prior is this:
__attribute__ ((nonnull)) void f (void*);
void g (void)
{
constexpr void *q = 0;
if (q)
f (q); // -Wnonnull
}
Because the front ends operate on one expression at a time they can't see past
the expression boundary and so these kinds of examples will always trigger
false positives in such warnings.
The new problem reported in comment #0 that's unique in GCC 11 is due to the
COND_EXPR that's implicitly added by the C++ front end for casts between
related types. The following is the expression that triggers the warning in
the attached test case, the this argument to virtual WId QXcbWindow::winId()
const:
SAVE_EXPR (tp)>)> != 0B ? (const struct QXcbWindow *) (SAVE_EXPR
(tp)>)> + 18446744073709551600) : 0B
The third operand of the COND_EXPR (i.e., the 0B) triggers the front end
warning because check_function_arguments_recurse() is designed to look for it.
The only bug I see here is not that the warning can be triggered in an if
statement with an unreachable branch but that it can be triggered by the
implicit literal null inserted by the front end that's not in the source code.
A test case that more closely reflects the problem is this
$ cat pr98646.C && gcc -S -Wall -fdump-tree-original=/dev/stdout pr98646.C
struct A { virtual ~A (); };
struct B { virtual ~B (); B* f (); };
struct C: A, B { virtual ~C (); void g () const; };
void f (B *p)
{
static_cast(p->f ())->g (); // no warning
}
void g (B *p)
{
static_cast(p->f ())->g ();// bogus -Wnonnull
}
;; Function void f(B*) (null)
;; enabled by -tree-original
<)> != 0B ? (struct C *) (SAVE_EXPR
)> + 18446744073709551608) : 0B) >;
pr98646.C: In function ‘void g(B*)’:
pr98646.C:13:38: warning: ‘this’ pointer null [-Wnonnull]
13 | static_cast(p->f ())->g ();// bogus -Wnonnull
| ^
pr98646.C:4:38: note: in a call to non-static member function ‘void C::g()
const’
4 | struct C: A, B { virtual ~C (); void g () const; };
| ^
;; Function void g(B*) (null)
;; enabled by -tree-original
<)> != 0B ? (const struct C *)
(SAVE_EXPR )> + 18446744073709551608) : 0B) >;
But the problem isn't new to GCC 11. The same warning can be triggered in GCC
10 with a slightly modified test case:
$ cat pr98646.C && /build/gcc-10-branch/gcc/xgcc -B /build/gcc-10-branch/gcc -S
-Wall pr98646.C
struct A { virtual ~A (); };
struct B { virtual ~B (); B* f (); };
struct C: A, B { virtual ~C (); };
__attribute__ ((nonnull)) void g (const void*);
void f (B *p)
{
g (static_cast(p->f ())); // bogus -Wnonnull
}
void g (B *p)
{
g (static_cast(p->f ()));// bogus -Wnonnull
}
pr98646.C: In function ‘void f(B*)’:
pr98646.C:10:30: warning: null argument where non-null required (argument 1)
[-Wnonnull]
10 | g (static_cast(p->f ())); // bogus -Wnonnull
| ^
pr98646.C: In function ‘void g(B*)’:
pr98646.C:15:36: warning: null argument where non-null required (argument 1)
[-Wnonnull]
15 | g (static_cast(p->f ()));// bogus -Wnonnull
|^
The only new aspect of it is that in GCC 11 it triggers for member functions.
[Bug debug/98751] [11 Regression] libgccjit fails in DWARF 5 handling with "`.Ldebug_loc2' is already defined" asm error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98751 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from David Malcolm --- Should be fixed by the above commit.
[Bug debug/98751] [11 Regression] libgccjit fails in DWARF 5 handling with "`.Ldebug_loc2' is already defined" asm error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98751 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:b83604c75fee324cc4767d039178cba2fbbe017e commit r11-6808-gb83604c75fee324cc4767d039178cba2fbbe017e Author: David Malcolm Date: Tue Jan 19 19:58:23 2021 -0500 dwarf2out: reset generation count in toplev::finalize [PR98751] PR debug/98751 reports an issue in which most of libgccjit's tests fails in DWARF 5 handling with `.Ldebug_loc2' is already defined" asm errors. The bogus label is being emitted at the 3rd in-process iteration, at: 31673 ASM_OUTPUT_LABEL (asm_out_file, loc_section_label); which on the initial iteration emits: 145 â .Ldebug_loc0: on the 2nd iteration: 145 â .Ldebug_loc1: and on the 3rd iteration: 145 â .Ldebug_loc2: which is a duplicate of a label emitted earlier: 138 â .section.debug_loclists,"",@progbits 139 â .long .Ldebug_loc3-.Ldebug_loc2 140 â .Ldebug_loc2: 141 â .value 0x5 142 â .byte 0x8 143 â .byte 0 144 â .long 0 145 â .Ldebug_loc2: The issue seems to be that init_sections_and_labels creates the label ASM_GENERATE_INTERNAL_LABEL (loc_section_label, DEBUG_LOC_SECTION_LABEL, generation); where "generation" is a static local to init_sections_and_labels that increments, and thus eventually hits the duplicate value. It appears that this value is intended to be either 0 or 1, but in the libgccjit case the compilation code can be invoked an arbitrary number of times in-process, and hence can eventually lead to a label name collision. This patch adds code to dwarf2out_c_finalize (called by toplev::finalize in libgccjit) to reset the generation counts, fixing the issue. gcc/ChangeLog: PR debug/98751 * dwarf2out.c (output_line_info): Rename static variable "generation", moving it out of the function to... (output_line_info_generation): New. (init_sections_and_labels): Likewise, renaming the variable to... (init_sections_and_labels_generation): New. (dwarf2out_c_finalize): Reset the new variables.
[Bug tree-optimization/98758] [11 Regression] ice in lambda_matrix_right_hermite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98758 Andrew Pinski changed: What|Removed |Added Version|unknown |11.0 Target Milestone|--- |11.0 Summary|ice in |[11 Regression] ice in |lambda_matrix_right_hermite |lambda_matrix_right_hermite
[Bug c/98758] New: ice in lambda_matrix_right_hermite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98758
Bug ID: 98758
Summary: ice in lambda_matrix_right_hermite
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
long *a, *b;
long c;
void d(void) {
b = a;
while (c) {
*a = a += (long)1 << 54;
c = b[0];
b = a;
}
}
compiled with recent gcc and compiler flag -O3 does this:
bug693.c:3:6: internal compiler error: in abs_hwi, at hwint.h:324
3 | void d(void) {
| ^
0x18fbeed lambda_matrix_right_hermite(long**, int, int, long**, long**)
../../trunk.git/gcc/wide-int.h:0
0x18fbeed analyze_subscript_affine_affine(tree_node*, tree_node*,
conflict_funct
ion**, conflict_function**, tree_node**)
../../trunk.git/gcc/tree-data-ref.c:4413
0x18f980d analyze_siv_subscript(tree_node*, tree_node*, conflict_function**,
con
flict_function**, tree_node**, int)
../../trunk.git/gcc/tree-data-ref.c:4669
0x18f980d analyze_overlapping_iterations(tree_node*, tree_node*,
conflict_functi
on**, conflict_function**, tree_node**, loop*)
../../trunk.git/gcc/tree-data-ref.c:4915
The bug first seems to occur sometime from date 20210113 to 20210114.
Git hashes are 3ddc18251a821fe6 and aa3d33dccb57621b.
I'll have a go at running a git bisect tomorrow. There are 31 commits
to be bisected. In that range, only Richard's commit
2182274f510c180ea92a4f826a0f6cf5f1f55b66 mentions source code file
tree-data-ref.c, so that looks a hot candidate.
[Bug c++/96511] Incorrect placement-new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96511 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- The patch is too intrusive to backport. Resolving as fixed.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Segher Boessenkool changed: What|Removed |Added Attachment #49996|0 |1 is obsolete|| --- Comment #21 from Segher Boessenkool --- Created attachment 50007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50007=edit Better patch
[Bug translation/93759] Invalid % in param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93759 --- Comment #7 from Roland Illig --- Is there still something to do for this bug? de.po looks good now, having "c-no-format" instead of "c-format".
[Bug testsuite/98757] New: New test case gfortran.dg/gomp/is_device_ptr-2.f90 in r11-6787 fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98757 Bug ID: 98757 Summary: New test case gfortran.dg/gomp/is_device_ptr-2.f90 in r11-6787 fails with excess error Product: gcc Version: 11.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: --- g:049bfd186fae9fb764a3ec04acb20d3eaacda7a3, r11-6787 make -k check-gcc RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/is_device_ptr-2.f90" FAIL: gfortran.dg/gomp/is_device_ptr-2.f90 -O (test for errors, line 11) FAIL: gfortran.dg/gomp/is_device_ptr-2.f90 -O (test for excess errors) # of unexpected failures2 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/gomp/is_device_ptr-2.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O -fopenmp -S -o is_device_ptr-2.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/gomp/is_device_ptr-2.f90:11:36: Error: Non-dummy object 'dd' in IS_DEVICE_PTR clause at (1) compiler exited with status 1 FAIL: gfortran.dg/gomp/is_device_ptr-2.f90 -O (test for errors, line 11) Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ exceptions_enabled128456.cc-fdiagnostics-plain-output -fdiagnostics-plain-output -S -o exceptions_enabled128456.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ exceptions_enabled128456.cc -fdiagnostics-plain-output -fdiagnostics-plain-output -S -o exceptions_enabled128456.s FAIL: gfortran.dg/gomp/is_device_ptr-2.f90 -O (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/gomp/is_device_ptr-2.f90:11:36: Error: Non-dummy object 'dd' in IS_DEVICE_PTR clause at (1) commit 049bfd186fae9fb764a3ec04acb20d3eaacda7a3 Author: Tobias Burnus Date: Tue Jan 19 11:57:34 2021 +0100
[Bug c++/98659] [11 Regression] ICE tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in maybe_instantiate_noexcept, at cp/pt.c:25445 since r11-6476-gaf362af18f405c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98659 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/98659] [11 Regression] ICE tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in maybe_instantiate_noexcept, at cp/pt.c:25445 since r11-6476-gaf362af18f405c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98659 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2b27f37f90cb66e277b734c605639e2f00a2e942 commit r11-6804-g2b27f37f90cb66e277b734c605639e2f00a2e942 Author: Marek Polacek Date: Wed Jan 13 13:12:14 2021 -0500 c++: Crash when deducing template arguments [PR98659] maybe_instantiate_noexcept doesn't expect to see error_mark_node, but the new callsite I introduced in r11-6476 can pass error_mark_node to it. So cope. gcc/cp/ChangeLog: PR c++/98659 * pt.c (maybe_instantiate_noexcept): Return false if FN is error_mark_node. gcc/testsuite/ChangeLog: PR c++/98659 * g++.dg/template/deduce8.C: New test.
[Bug c++/98756] New: Suspicious "(*this)." in mangled symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98756
Bug ID: 98756
Summary: Suspicious "(*this)." in mangled symbol
Product: gcc
Version: 11.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: ---
For the test in PR98545:
// PR c++/98545
// { dg-do compile { target c++11 } }
class a {
public:
a();
template a(b);
};
template using c = a;
class f {
protected:
template void operator()(d, double, e);
};
class i : f {
public:
template
[[gnu::used]] auto h(g...) -> decltype(operator()(g()...)) {}
// { dg-final { scan-assembler
"_ZN1i1hIJ1adS1_EEEDTcldtdefpTonclspcvT__EEEDpS2_" } }
};
template class C {
public:
template C(j);
i k() const;
int operator()() {
int l = 10;
c<> m, n;
operator()(m, l, n);
return 0;
}
int operator()(c<> &, c<> const &, c<> const &) const;
template void k(d m, double gamma, e o) const {
k().h(m, gamma, o);
}
};
template int C::operator()(c<> &, c<> const &, c<> const &) const
{
[&](c<> m, double gamma, c<> o) { k(m, gamma, o); };
return 0;
}
c<> p = C(p)();
we emit
$ c++filt _ZN1i1hIJ1adS1_EEEDTcldtdefpTonclspcvT__EEEDpS2_
decltype (((*this).(operator()))((a)(), (double)(), (a)())) i::h(a, double, a)
though other compilers emit:
$ c++filt _ZN1i1hIJ1adS1_EEEDTclonclspcvT__EEEDpS2_
decltype ((operator())((a)(), (double)(), (a)())) i::h(a, double,
a)
as mentioned in
.
This should be investigated.
[Bug c++/98687] [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f85372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98687 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Should be fixed.
[Bug middle-end/98664] inconsistent --Wfree-nonheap-object for inlined calls to system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98664 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |11.0 Keywords||patch --- Comment #3 from Martin Sebor --- Patch (https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563515.html) committed in r11-6801.
[Bug c++/98687] [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f85372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98687 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:d89b00c095e99cd5cb6d3e05f30d3a61fa592000 commit r11-6802-gd89b00c095e99cd5cb6d3e05f30d3a61fa592000 Author: Marek Polacek Date: Thu Jan 14 22:14:38 2021 -0500 c++: ICE with USING_DECL redeclaration [PR98687] My recent patch that introduced push_using_decl_bindings didn't handle USING_DECL redeclaration, therefore things broke. This patch amends that by breaking out a part of finish_nonmember_using_decl out to a separate function, push_using_decl_bindings, and calling it. It needs an overload, because name_lookup is only available inside of name-lookup.c. gcc/cp/ChangeLog: PR c++/98687 * name-lookup.c (push_using_decl_bindings): New, broken out of... (finish_nonmember_using_decl): ...here. * name-lookup.h (push_using_decl_bindings): Update declaration. * pt.c (tsubst_expr): Update the call to push_using_decl_bindings. gcc/testsuite/ChangeLog: PR c++/98687 * g++.dg/lookup/using64.C: New test. * g++.dg/lookup/using65.C: New test.
[Bug middle-end/98664] inconsistent --Wfree-nonheap-object for inlined calls to system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98664 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:9693e255ee2536c6823640eba5d0163c2b401161 commit r11-6801-g9693e255ee2536c6823640eba5d0163c2b401161 Author: Martin Sebor Date: Tue Jan 19 15:10:30 2021 -0700 PR middle-end/98664 - inconsistent -Wfree-nonheap-object for inlined calls to system headers gcc/ChangeLog: PR middle-end/98664 * tree-ssa-live.c (remove_unused_scope_block_p): Keep scopes for all functions, even if they're not declared artificial or inline. * tree.c (tree_inlined_location): Use macro expansion location only if scope traversal fails to expose one. gcc/testsuite/ChangeLog: PR middle-end/98664 * gcc.dg/Wvla-larger-than-4.c: Adjust expected output. * gcc.dg/plugin/diagnostic-test-inlining-3.c: Same. * g++.dg/warn/Wfree-nonheap-object-5.C: New test. * gcc.dg/Wfree-nonheap-object-4.c: New test.
[Bug debug/98755] New: [11 regression] r11-6755 causes failure in g++.dg/debug/dwarf2/constexpr-var-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755 Bug ID: 98755 Summary: [11 regression] r11-6755 causes failure in g++.dg/debug/dwarf2/constexpr-var-1.C Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:3804e937b0e252a7e42632fe6d9f898f1851a49c, r11-6755 make -k check-gcc RUNTESTFLAGS="dwarf2.exp=g++.dg/debug/dwarf2/constexpr-var-1.C" FAIL: g++.dg/debug/dwarf2/constexpr-var-1.C scan-assembler-times DW_AT_const_expr 2 # of expected passes1 # of unexpected failures1 commit 3804e937b0e252a7e42632fe6d9f898f1851a49c (HEAD, refs/bisect/bad) Author: Mark Wielaard Date: Tue Sep 29 15:52:44 2020 +0200 Default to DWARF5 gcc/ChangeLog: * common.opt (gdwarf-): Init(5). * doc/invoke.texi (-gdwarf): Document default to 5.
[Bug ada/98754] gnatmake no longer recognizes -P option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98754 --- Comment #3 from Eric Reischer --- (Or some other more descriptive error indicating "gprbuild" was not found on the path, rather than acting as though you have borked the command-line options.)
[Bug ada/98754] gnatmake no longer recognizes -P option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98754 --- Comment #2 from Eric Reischer --- In that case, this is not a RESOLVED WONTFIX -- this is still open. The documentation and output of "gnatmake --help" need to be updated to reflect the fact this is no longer a valid command line option.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 --- Comment #15 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:29853c653245c37ed31b6abcc9799b534372e938 commit r11-6800-g29853c653245c37ed31b6abcc9799b534372e938 Author: Patrick Palka Date: Tue Jan 19 16:20:00 2021 -0500 c++: Always check access during late-parsing of members [PR58993] This patch removes a vestigial use of dk_no_check from cp_parser_late_parsing_for_member, which ideally should have been removed as part of the PR41437 patch that improved access checking inside templates. This allows us to correctly reject f1 and f2 in the testcase access34.C below (whereas before we'd only reject f3). Additional testing revealed a new access issue when late-parsing a hidden friend within a class template. In the testcase friend68.C below, we're tripping over the checking assert from friend_accessible_p(f, S::j, S, S) during lookup of j in x.j (for which type_dependent_object_expression_p returns false, which is why we're doing the lookup at parse time). The reason for the assert failure is that DECL_FRIENDLIST(S) contains f but DECL_BEFRIENDING_CLASSES(f) is empty, and so friend_accessible_p (which looks at DECL_BEFRIENDING_CLASSES) wants to return false, but is_friend (which looks at DECL_FRIENDLIST) returns true. For sake of symmetry one would expect that DECL_BEFRIENDING_CLASSES(f) contains S, but add_friend avoids updating DECL_BEFRIENDING_CLASSES when the class type (S in this case) is dependent, for some reason. This patch works around this issue by making friend_accessible_p consider the DECL_FRIEND_CONTEXT of the access scope. Thus we sidestep the DECL_BEFRIENDING_CLASSES / DECL_FRIENDLIST asymmetry issue while correctly validating the x.j access at parse time. A earlier version of this patch checked friend_accessible_p instead of protected_accessible_p in the DECL_FRIEND_CONTEXT hunk below, but this had the side effect of making us accept the ill-formed testcase friend69.C below (ill-formed because the hidden friend g is not actually a member of A, so g doesn't have access to B's members despite B befriending A). gcc/cp/ChangeLog: PR c++/41437 PR c++/58993 * search.c (friend_accessible_p): If scope is a hidden friend defined inside a dependent class, consider access from the class. * parser.c (cp_parser_late_parsing_for_member): Don't push a dk_no_check access state. gcc/testsuite/ChangeLog: PR c++/41437 PR c++/58993 * g++.dg/opt/pr87974.C: Adjust. * g++.dg/template/access34.C: New test. * g++.dg/template/friend68.C: New test. * g++.dg/template/friend69.C: New test.
[Bug c++/58993] incorrectly accept access of protected member method from derived class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58993 --- Comment #9 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:29853c653245c37ed31b6abcc9799b534372e938 commit r11-6800-g29853c653245c37ed31b6abcc9799b534372e938 Author: Patrick Palka Date: Tue Jan 19 16:20:00 2021 -0500 c++: Always check access during late-parsing of members [PR58993] This patch removes a vestigial use of dk_no_check from cp_parser_late_parsing_for_member, which ideally should have been removed as part of the PR41437 patch that improved access checking inside templates. This allows us to correctly reject f1 and f2 in the testcase access34.C below (whereas before we'd only reject f3). Additional testing revealed a new access issue when late-parsing a hidden friend within a class template. In the testcase friend68.C below, we're tripping over the checking assert from friend_accessible_p(f, S::j, S, S) during lookup of j in x.j (for which type_dependent_object_expression_p returns false, which is why we're doing the lookup at parse time). The reason for the assert failure is that DECL_FRIENDLIST(S) contains f but DECL_BEFRIENDING_CLASSES(f) is empty, and so friend_accessible_p (which looks at DECL_BEFRIENDING_CLASSES) wants to return false, but is_friend (which looks at DECL_FRIENDLIST) returns true. For sake of symmetry one would expect that DECL_BEFRIENDING_CLASSES(f) contains S, but add_friend avoids updating DECL_BEFRIENDING_CLASSES when the class type (S in this case) is dependent, for some reason. This patch works around this issue by making friend_accessible_p consider the DECL_FRIEND_CONTEXT of the access scope. Thus we sidestep the DECL_BEFRIENDING_CLASSES / DECL_FRIENDLIST asymmetry issue while correctly validating the x.j access at parse time. A earlier version of this patch checked friend_accessible_p instead of protected_accessible_p in the DECL_FRIEND_CONTEXT hunk below, but this had the side effect of making us accept the ill-formed testcase friend69.C below (ill-formed because the hidden friend g is not actually a member of A, so g doesn't have access to B's members despite B befriending A). gcc/cp/ChangeLog: PR c++/41437 PR c++/58993 * search.c (friend_accessible_p): If scope is a hidden friend defined inside a dependent class, consider access from the class. * parser.c (cp_parser_late_parsing_for_member): Don't push a dk_no_check access state. gcc/testsuite/ChangeLog: PR c++/41437 PR c++/58993 * g++.dg/opt/pr87974.C: Adjust. * g++.dg/template/access34.C: New test. * g++.dg/template/friend68.C: New test. * g++.dg/template/friend69.C: New test.
[Bug ada/98754] gnatmake no longer recognizes -P option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98754 Arnaud Charlet changed: What|Removed |Added Resolution|--- |WONTFIX CC||charlet at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Arnaud Charlet --- Yes, that's as expected: support for project files has been moved entirely to gprbuild. If you have gprbuild in your path, gnatmake -Pproject will call gprbuild -Pproject.
[Bug debug/98751] [11 Regression] libgccjit fails in DWARF 5 handling with "`.Ldebug_loc2' is already defined" asm error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98751 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Priority|P3 |P1 Last reconfirmed||2021-01-19 Summary|libgccjit fails in DWARF 5 |[11 Regression] libgccjit |handling with |fails in DWARF 5 handling |"`.Ldebug_loc2' is already |with "`.Ldebug_loc2' is |defined" asm error |already defined" asm error Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from David Malcolm --- (In reply to Jakub Jelinek from comment #2) > Created attachment 50006 [details] > gcc11-pr98751.patch > > Completely untested patch. I independently wrote effectively the same patch. It seems to fix the jit issues. I'm running a full test now.
[Bug debug/98728] [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 --- Comment #2 from Mark Wielaard --- (In reply to Mark Wielaard from comment #1) > Maybe this bug should be split in two (or three) for each specific FAIL? > > (In reply to Rainer Orth from comment #0) > > With the switch to DWARF-5, two debug tests have started to FAIL: > > [...] > > +FAIL: gcc.dg/debug/dwarf2/dwarf-float.c scan-assembler > > 0x10.*DW_AT_byte_size > > > > 32-bit Solaris/x86 and Linux/x86_64 > > So this fails in 32bit mode, but not in 64bit mode. > > In 64bit mode gcc generates: > > .uleb128 0x2# (DIE (0x7d) DW_TAG_base_type) > .byte 0x10# DW_AT_byte_size > # DW_AT_encoding (0x4) > .long .LASF4 # DW_AT_name: "long double" > > But in 32bit mode it generates: > > .uleb128 0x2# (DIE (0x6d) DW_TAG_base_type) > .byte 0xc # DW_AT_byte_size > # DW_AT_encoding (0x4) > .long .LASF4 # DW_AT_name: "long double" This part has been fixed by Jeff: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563840.html
[Bug ada/98754] New: gnatmake no longer recognizes -P option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98754
Bug ID: 98754
Summary: gnatmake no longer recognizes -P option
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: emr-gnu at hev dot psu.edu
Target Milestone: ---
Using 10.2.0, "gnatmake -Pfoo" does not appear to be a valid command line
anymore. Contents of foo.gpr:
project foo is
for Source_Dirs use (".");
for Object_Dir use "./build";
for Exec_Dir use ".";
for Main use ("hello");
package Compiler is
for Default_Switches ("Ada")
use ("-fstack-check",
"-ffloat-store",
"-msse2",
"-mfpmath=sse",
"-O0",
"-gnatws",
"-gnatE",
"-gnato");
end Compiler;
end foo
I would expect gnat to start building the program defined by "hello", but
instead I receive:
try "gnatmake-10.2 --help" for more information.
Configured with: -v --enable-languages=c,c++,ada,fortran
--prefix=/opt/gcc-10.2.0 --program-suffix=-10.2 --enable-shared
--enable-linker-build-id --with-system-zlib --libexecdir=/opt/gcc-10.2.0/lib
--without-included-gettext --enable-threads=posix --libdir=/opt/gcc-10.2.0/lib
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-default-pie --enable-plugin --with-arch-32=i686
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --disable-nls --wihtout-cuda-driver --enable-libada
[Bug c++/98753] -Wfree-nonheap-object on Bison generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-01-19 Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- The attached file depends on a number of headers. To reproduce a problem we need a standalone test case that can be compiled on its own. One way to do that is to use the -E option to GCC to obtain the translation unit and attaching that. That said, based on the description I suspect the warning is a false positive with the same root cause as pr54202. Until a better solution is available in GCC the workaround is to suppress the warning, either by #pragma GCC diagnostic, or by using -Wno-free-nonheap-object on the command line.
[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 --- Comment #5 from Marek Polacek --- Actually Comment 3 test is unrelated to the original issue here. Comment 3 will be fixed by my PR98659 fix, but not the original issue.
[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 --- Comment #4 from Marek Polacek --- I posted a patch for this which fixes this test too.
[Bug c++/98333] [10 Regression] ICE in check_qualified_type, at tree.c:6593 since r10-1280-g78f7607db4c53f8c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98333 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10 Regression] ICE in |check_qualified_type, at|check_qualified_type, at |tree.c:6593 since |tree.c:6593 since |r10-1280-g78f7607db4c53f8c |r10-1280-g78f7607db4c53f8c --- Comment #4 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/93821] Define __cplusplus to 202002L in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821 Romain Geissler changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Romain Geissler --- Hi, This was implemented in gcc 11 with this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=libcpp/init.c;h=445430e16bd08ade34637d2346ded40dd49de508 Closing. Cheers, Romain
[Bug c++/98333] [10/11 Regression] ICE in check_qualified_type, at tree.c:6593 since r10-1280-g78f7607db4c53f8c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98333
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:c37f1d4081f5a19e39192d13e2a3acea13662e5a
commit r11-6799-gc37f1d4081f5a19e39192d13e2a3acea13662e5a
Author: Marek Polacek
Date: Fri Jan 8 15:48:41 2021 -0500
c++: ICE when late parsing noexcept/NSDMI [PR98333]
Since certain members of a class are a complete-class context
[class.mem.general]p7, we delay their parsing untile the whole class has
been parsed. For instance, NSDMIs and noexcept-specifiers. The order
in which we perform this delayed parsing matters; we were first parsing
NSDMIs and only they did we parse noexcept-specifiers. That turns out
to be wrong: since NSDMIs may use noexcept-specifiers, we must process
noexcept-specifiers first. Otherwise we'll ICE in code that doesn't
expect to see DEFERRED_PARSE.
This doesn't just shift the problem, noexcept-specifiers can use members
with a NSDMI just fine, and I've also tested a similar test with this
member function:
bool f() { return __has_nothrow_constructor (S); }
and that compiled fine too.
gcc/cp/ChangeLog:
PR c++/98333
* parser.c (cp_parser_class_specifier_1): Perform late-parsing
of NSDMIs before late-parsing of noexcept-specifiers.
gcc/testsuite/ChangeLog:
PR c++/98333
* g++.dg/cpp0x/noexcept62.C: New test.
[Bug c++/98752] wrong "error: ‘this’ is not a constant expression" with consteval constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752 --- Comment #3 from Marek Polacek --- (In reply to Jakub Jelinek from comment #2) > But if we can fix it, I'd think it would be worth an exception. Given the fix would likely only affect C++20 code, I think that would be reasonable.
[Bug debug/98751] libgccjit fails in DWARF 5 handling with "`.Ldebug_loc2' is already defined" asm error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98751 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 50006 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50006=edit gcc11-pr98751.patch Completely untested patch.
[Bug c++/98752] wrong "error: ‘this’ is not a constant expression" with consteval constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- But if we can fix it, I'd think it would be worth an exception.
[Bug c++/98752] wrong "error: ‘this’ is not a constant expression" with consteval constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-19 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Not a regression.
[Bug c++/98530] [11 Regression] g++.dg/modules/string-1_b.C etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98530 --- Comment #3 from Nathan Sidwell --- sigh, not a broken header, it is a broken compiler
[Bug c++/98753] New: -Wfree-nonheap-object on Bison generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
Bug ID: 98753
Summary: -Wfree-nonheap-object on Bison generated code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: foss at grueninger dot de
Target Milestone: ---
Build: 11.0.0 20210114 (experimental) [revision
08a4adcf2b6ded2fea97195c715757df61a23395] (SUSE Linux)
Created attachment 50005
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50005=edit
C++ file generated by Bison
While compiling CMake with GCC 11.0, I spot some -Wfree-nonheap-object
warnings. These came from files generated by Bison. I regenerated the C++ files
with the latest GNU Bison release and the problem persisted. So I asked on the
Bison user list and one of the developers claims, that Bison is right.
I don't know whether it is a false positive or whether Bison has a bug.
1.
Attached is the C++ file generated by Bison (cmCommandArgumentParser.cxx).
2.
The warning I get from G++:
[ 54%] Building CXX object
Source/CMakeFiles/CMakeLib.dir/LexerParser/cmCommandArgumentParser.cxx.o
cmCommandArgumentParser.cxx: In function ‘int
cmCommandArgument_yyparse(yyscan_t)’:
cmCommandArgumentParser.cxx:1838:18: warning: ‘void free(void*)’ called on
unallocated object ‘yyssa’ [-Wfree-nonheap-object]
cmCommandArgumentParser.cxx:1203:16: note: declared here
3.
The explanation / reduced code from one of the Bison developers, why the code
is correct:
> GCC 11 is wrong here. The full story (taken from your file) is:
>
>> // Create.
>> yy_state_t yyssa[YYINITDEPTH];
>> yy_state_t *yyss = yyssa;
>> [...]
>> // Grow.
>> yystacksize *= 2;
>> {
>> yy_state_t *yyss1 = yyss;
>> union yyalloc *yyptr =
>> YY_CAST (union yyalloc *,
>>YYSTACK_ALLOC (YY_CAST (YYSIZE_T, YYSTACK_BYTES
>> (yystacksize;
>> if (! yyptr)
>> goto yyexhaustedlab;
>> YYSTACK_RELOCATE (yyss_alloc, yyss);
>> if (yyss1 != yyssa)
>> YYSTACK_FREE (yyss1);
>> }
>> [...]
>> // Clean up
>> if (yyss != yyssa)
>> YYSTACK_FREE (yyss);
>
> Or, in words, we use a stack-allocated stack until it's too small and
> then we use a heap-allocated stack, and in that case, and that case
> only, we free it at the end. Said another way: we never ever call
> free(yyssa).
>
> So GCC's warning is a false positive.
Source: https://lists.gnu.org/archive/html/help-bison/2021-01/msg00021.html
4.
My GCC version is:
> gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210114 (experimental) [revision
08a4adcf2b6ded2fea97195c715757df61a23395] (SUSE Linux)
[Bug c++/98625] UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Note, -1 << x shifts are well defined in C++20 (assuming x < sizeof (int) * CHAR_BIT), but isn't well defined in older C++ versions. For C++11 .. C++17 in particular, x << y is UB if x < 0 or ((unsigned) x >> (sizeof (int) * CHAR_BIT - 1 - y)) > 1 (in addition to the usual y < 0 or y >= sizeof (int) * CHAR_BIT).
[Bug fortran/91640] [9 Regression] ICE: gimplification failed (contiguous expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Backported to 9-branch (needed only adjustment of commit message from SVN to git) and regtested on x86_64-pc-linux-gnu. Closing.
[Bug fortran/91640] [9 Regression] ICE: gimplification failed (contiguous expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:9aa61202d2d2f54b3eca473f78b7494c1e67c3c0 commit r9-9190-g9aa61202d2d2f54b3eca473f78b7494c1e67c3c0 Author: Tobias Burnus Date: Sat Jan 4 08:19:51 2020 + [Fortran] PR91640 â Fix call to contiguous dummy gcc/fortran/ PR fortran/91640 * trans-expr.c (gfc_conv_procedure_call): Avoid copy-out for nonvariable arguments to contiguous dummy args. Avoid re-checking whether fsym is NULL. gcc/testsuite/ PR fortran/91640 * gfortran.dg/contiguous_10.f90: New. (cherry picked from commit 9b9623194bf17328bc03e09b043149adf4fb0f9a)
[Bug c++/98625] UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625 --- Comment #3 from Martin Liška --- > only >> 4 and << 8 shifts going on there. The thing is here that -1 is being shifted. That's undefined, you likely want to do shifting in an unsigned type and later cast to an unsigned type.
[Bug c++/98752] New: wrong "error: ‘this’ is not a constant expression" with consteval constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752
Bug ID: 98752
Summary: wrong "error: ‘this’ is not a constant expression"
with consteval constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with gcc-c++-10.2.1-9.fc33.x86_64 and with a local GCC 11 trunk build:
> $ cat test.cc
> struct S1 { consteval S1(int) {} };
> struct S2 {
> S1 x;
> S2(): x(0) {}
> };
> $ g++ -std=c++20 -fsyntax-only test.cc
> test.cc: In constructor ‘S2::S2()’:
> test.cc:4:12: error: ‘this’ is not a constant expression
> 4 | S2(): x(0) {}
> |^
[Bug c++/98645] C++ modules support does not work on PowerPC with IEEE 128-bit long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645 Nathan Sidwell changed: What|Removed |Added Last reconfirmed||2021-01-19 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug debug/98751] libgccjit fails in DWARF 5 handling with "`.Ldebug_loc2' is already defined" asm error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98751 --- Comment #1 from David Malcolm --- s/generations/generation/g
[Bug debug/98751] New: libgccjit fails in DWARF 5 handling with "`.Ldebug_loc2' is already defined" asm error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98751 Bug ID: 98751 Summary: libgccjit fails in DWARF 5 handling with "`.Ldebug_loc2' is already defined" asm error Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Most of the jit.exp testsuite is failing, where the tests fail on 3rd in-process iteration, with asm errors of the form: symbol `.Ldebug_loc2' is already defined test-factorial.c.exe iteration 3 of 5: writing reproducer to ./test-factorial.c.exe.reproducer.c /tmp/libgccjit-7lPSFo/fake.s: Assembler messages: /tmp/libgccjit-7lPSFo/fake.s:145: Error: symbol `.Ldebug_loc2' is already defined ./test-factorial.c.exe: error: error invoking gcc driver FAILED: test-factorial.c.exe iteration 3 of 5: verify_code: result is NULL Adding this to set_options in jit.dg/harness.h: gcc_jit_context_set_bool_option ( ctxt, GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES, 1); allows the asm to be inspected after the test runs which has: 1st iteration: 138 │ .section.debug_loclists,"",@progbits 139 │ .long .Ldebug_loc3-.Ldebug_loc2 140 │ .Ldebug_loc2: 141 │ .value 0x5 142 │ .byte 0x8 143 │ .byte 0 144 │ .long 0 145 │ .Ldebug_loc0: 146 │ .LLST0: 2nd iteration: 138 │ .section.debug_loclists,"",@progbits 139 │ .long .Ldebug_loc3-.Ldebug_loc2 140 │ .Ldebug_loc2: 141 │ .value 0x5 142 │ .byte 0x8 143 │ .byte 0 144 │ .long 0 145 │ .Ldebug_loc1: 146 │ .LLST0: 3rd iteration: 138 │ .section.debug_loclists,"",@progbits 139 │ .long .Ldebug_loc3-.Ldebug_loc2 140 │ .Ldebug_loc2: 141 │ .value 0x5 142 │ .byte 0x8 143 │ .byte 0 144 │ .long 0 145 │ .Ldebug_loc2: 146 │ .LLST0: Note how line 145's number increments each time, and on the 3rd iteration is a duplicate, leading to failure. The bogus label is being emitted at: 31673 ASM_OUTPUT_LABEL (asm_out_file, loc_section_label); init_sections_and_labels: ASM_GENERATE_INTERNAL_LABEL (loc_section_label, DEBUG_LOC_SECTION_LABEL, generation); where "generations" is a static local to init_sections_and_labels that increments, and thus eventually hits the duplicate value. It looks like generations is meant to be just 0 or 1, but in libgccjit the compilation code can get repeatedly invoked an arbitrary number of times in process. If generations is meant to be just 0 or 1, should this value be reset to 0 at the end of toplev::main ? Doing so is likely to fix this bug.
[Bug rtl-optimization/98722] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722 --- Comment #3 from Vladimir Makarov --- (In reply to Martin Liška from comment #2) > It happens for s390x target, so you will need to build a cross compiler with: > --target=s390x-linux-gnu. Thank you, Martin. I've reproduced it on s390x.
[Bug c++/98750] does not detect dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98750 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Jonathan Wakely --- GCC doesn't emit any call to f() so it does detect it. Do you mean that it doesn't give a warning?
[Bug c++/98625] UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625
--- Comment #2 from Nathan Sidwell ---
This looks like a ubsan or optimizer bug. I can't see a -ve shift in the
source:
HOST_WIDE_INT
bytes_in::wi ()
{
HOST_WIDE_INT v = 0;
if (const char *ptr = read (1))
{
v = *ptr & 0xff;
if (v & 0x80)
{
unsigned bytes = (v >> 4) & 0x7;
v &= 0xf;
if (v & 0x8)
v |= -1 ^ 0x7;
if ((ptr = read (++bytes)))
while (bytes--)
v = (v << 8) | (*ptr++ & 0xff);
}
else if (v & 0x40)
v |= -1 ^ 0x3f;
}
return v;
}
only >> 4 and << 8 shifts going on there.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 98624, which changed state. Bug 98624 Summary: UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/98624] UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Nathan Sidwell --- fixed 6e6f3ed47e5 2021-01-19 | c++: Fix null this pointer [PR 98624]
[Bug c++/98624] UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:6e6f3ed47e5cb575819f8253e42313664b89b042 commit r11-6797-g6e6f3ed47e5cb575819f8253e42313664b89b042 Author: Nathan Sidwell Date: Tue Jan 19 11:31:57 2021 -0800 c++: Fix null this pointer [PR 98624] There's no need for this function to have an object, so make it static and avoid UB. PR c++/98624 gcc/cp/ * module.cc (trees_out::write_location): Make static.
[Bug rtl-optimization/98722] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722 --- Comment #2 from Martin Liška --- It happens for s390x target, so you will need to build a cross compiler with: --target=s390x-linux-gnu.
[Bug rtl-optimization/98722] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722 --- Comment #1 from Vladimir Makarov --- Sorry, I can not reproduce this on today trunk using reint.cpp test. I guess it is x86-64. I am using the following configuration (meaning with enabled checking) /home/cygnus/vmakarov/build1/gcc-git/gcc/configure --srcdir=/home/cygnus/vmakarov/build1/gcc-git/gcc --prefix=/home/cygnus/vmakarov/build1/gcc-git/64 --disable-bootstrap --enable-languages=c,c++,fortran Could you check it again or provide more info how to reproduce it.
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #7 from Brecht Sanders --- Adding flag `-gdwarf-4` to the above command still results in a file that won't execute, see attached file `conftest-gdwarf-4.exe`
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #6 from Brecht Sanders --- Created attachment 50004 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50004=edit test built with -gdwarf-4
[Bug tree-optimization/98512] [11 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html A workaround until the patch is approved, is to move the warning suppression pragmas above the the function declaration.
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #16 from Martin Sebor --- Patch to suppress the false positives in std::string: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
[Bug c++/98750] New: does not detect dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98750
Bug ID: 98750
Summary: does not detect dead code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
for the following code gcc will not detect that f() is never called. msvc
detects this correctly.
https://godbolt.org/z/Y5n78v
```
void f();
void _(int num) {
switch (num)
{
case 1:
break;
f();
}
}
```
[Bug libstdc++/98731] s390x: Large classes of std::bitset and std::vector hash the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98731 --- Comment #3 from Jonathan Wakely --- Yes the problem is that a bitset<2> uses the two least significant bits of an unsigned long, so we want to hash a single byte. But we take the address of the unsigned long and then hash the first byte. For BE we need to hash the last byte. With a bitset of more than 64 bits we have a layout like this: [76543210][...43210] We assume the value bytes are contiguous and just hash N bytes from the address of the first long, and then the next 5 bytes. We should be hashing the last 5 bytes of the last word instead. I haven't looked at hash> but it's probably the same bug.
[Bug ipa/92932] Optimizers generate wrong code due to aggressive data optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932 Bug 92932 depends on bug 92294, which changed state. Bug 92294 Summary: alias attribute generates incorrect code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from rsandifo at gcc dot gnu.org --- Fixed on trunk. I'm not sure it's suitable for backports.
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:6a2a38620cf178b53b217051f32d1d7bbba86fc9 commit r11-6796-g6a2a38620cf178b53b217051f32d1d7bbba86fc9 Author: Richard Sandiford Date: Tue Jan 19 17:50:53 2021 + alias: Fix offset checks involving section anchors [PR92294] memrefs_conflict_p assumes that: [XB + XO, XB + XO + XS) does not alias [YB + YO, YB + YO + YS) whenever: [XO, XO + XS) does not intersect [YO, YO + YS) In other words, the accesses can alias only if XB == YB at runtime. However, this doesn't cope correctly with section anchors. For example, if XB is an anchor symbol and YB is at offset XO from the anchor, then: [XB + XO, XB + XO + XS) overlaps [YB, YB + YS) whatever the value of XO is. In other words, when doing the alias check for two symbols whose local definitions are in the same block, we should apply the known difference between their block offsets to the intersection test above. gcc/ PR rtl-optimization/92294 * alias.c (compare_base_symbol_refs): Take an extra parameter and add the distance between two symbols to it. Enshrine in comments that -1 means "either 0 or 1, but we can't tell which at compile time". (memrefs_conflict_p): Update call accordingly. (rtx_equal_for_memref_p): Likewise. Take the distance between symbols into account.
[Bug testsuite/91799] [10/11 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
--- Comment #11 from CVS Commits ---
The master branch has been updated by Will Schmidt :
https://gcc.gnu.org/g:04cdb132020733bedc36d14d61cce4246b8bbe4c
commit r11-6795-g04cdb132020733bedc36d14d61cce4246b8bbe4c
Author: Will Schmidt
Date: Wed Jan 13 13:48:30 2021 -0600
[PATCH, rs6000] Update pr88233.c test (pr91799)
Hi,
This is a follow-up fix to clean up pr91799. Per review of test results,
it appears that the combination of target and dg-require stanzas is
not sufficient to properly limit the test to 64-bit only on darwin.
This adds an additional dg-require clause to limit the test to 64-bit
environments.
Tested on power7 and power8 using assorted variations of
make -k check-gcc-c "RUNTESTFLAGS=powerpc.exp=pr88233.c
--target_board=unix/'{-mcpu=power7,-mcpu=power6,-mcpu=power8}''{-m32,-m64}'"
PR target/91799
2021-01-19 Will Schmidt
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr88233.c: Update dg- stanzas.
[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98636 --- Comment #17 from prathamesh3492 at gcc dot gnu.org --- (In reply to Martin Liška from comment #15) > I see, so it's a real issue and I support the workaround mentioned in > Comment 10. > Please send it to the mailing list. Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563848.html Thanks, Prathamesh
[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98636
--- Comment #16 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Tamar Christina from comment #14)
> I just ran into the same problem, with a slightly different testcase:
This is a better one to reproduce the issue, thanks! I verified the patch in
comment 10 resolves the ICE for this test-case.
Thanks,
Prathamesh
>
> > cat crash.c
>
> #pragma GCC push_options
> #pragma GCC target ("arch=armv8.2-a+fp16")
> #pragma GCC pop_options
>
> results in the same crash:
>
> crash.c:3:9: internal compiler error: 'global_options' are modified in local
> context
> 3 | #pragma GCC pop_options
> | ^~~
> 0x1199c6d cl_optimization_compare(gcc_options*, gcc_options*)
> build-arm-none-eabi/obj/gcc2/gcc/options-save.c:14897
> 0xb38463 handle_pragma_pop_options
> src/gcc/gcc/c-family/c-pragma.c:1092
> 0xb38eef c_invoke_pragma_handler(unsigned int)
> src/gcc/gcc/c-family/c-pragma.c:1515
> 0xa80622 c_parser_pragma
> src/gcc/gcc/c/c-parser.c:12525
> 0xa63dc6 c_parser_external_declaration
> src/gcc/gcc/c/c-parser.c:1758
> 0xa63938 c_parser_translation_unit
> src/gcc/gcc/c/c-parser.c:1650
> 0xaa6139 c_parse_file()
> src/gcc/gcc/c/c-parser.c:21990
> 0xb322f2 c_common_parse_file()
> src/gcc/gcc/c-family/c-opts.c:1211
[Bug c++/89381] [8 Regression] Implicit copy constructor cannot be generated after unrelated class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89381 Patrick Palka changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #8 from Patrick Palka --- *** Bug 86494 has been marked as a duplicate of this bug. ***
[Bug c++/86494] Usage in unevaluated context causes compile time errors because of implicit deletion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86494 --- Comment #2 from Patrick Palka --- Drat sorry, meant to write PR89381.. *** This bug has been marked as a duplicate of bug 89381 ***
[Bug c++/89831] [8 Regression] passing 'const ...' as 'this' argument discards qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89831 Patrick Palka changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #6 from Patrick Palka --- *** Bug 86494 has been marked as a duplicate of this bug. ***
[Bug c++/86494] Usage in unevaluated context causes compile time errors because of implicit deletion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86494 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- This seems to be a dup of the already-fixed PR89831. *** This bug has been marked as a duplicate of bug 89831 ***
[Bug c++/60531] template function not resolved when comparing functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60531 Patrick Palka changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #7 from Patrick Palka --- *** Bug 86302 has been marked as a duplicate of this bug. ***
[Bug c++/86302] "f != 0" fails to choose the specialization f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86302 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- Dup of the already-fixed PR60531, I think. *** This bug has been marked as a duplicate of bug 60531 ***
[Bug c++/98355] [9/10/11 Regression] ICE in has_attribute, at c-family/c-attribs.c:5628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98355 --- Comment #4 from Martin Sebor --- I had stated my intent in the initial submission to complete the C++ support in a followup patch: https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510455.html Jason approved the initial patch with an encouragement to do so: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg01528.html I might have gotten around to it if you and Jeff hadn't blocked for four months (!) my fixes for a few simple ICEs in the code. Here's the first submission of a patch for the first ICE I found in December 2018: https://gcc.gnu.org/pipermail/gcc-patches/2018-December/512645.html The fixes didn't get approved and committed in r270326 until April 2019, and many rounds of back and forth bickering over whether the built-in should accept expressions or error out on them.
[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98636 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #15 from Martin Liška --- I see, so it's a real issue and I support the workaround mentioned in Comment 10. Please send it to the mailing list.
[Bug c++/97679] [10/11 Regression] [concepts] ICE with CTAD for a nested class template with constrained constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97679 Patrick Palka changed: What|Removed |Added Known to work||9.3.0 Keywords||ice-on-valid-code Summary|ICE with CTAD for a nested |[10/11 Regression] |class template with |[concepts] ICE with CTAD |constrained constructor |for a nested class template ||with constrained ||constructor Target Milestone|--- |10.3 --- Comment #1 from Patrick Palka --- This is apparently a regression relative to GCC 9 (when compiled with -std=c++2a -fconcepts). Seems to have started with the C++20 concepts merge r276764.
[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98636
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment #14 from Tamar Christina ---
I just ran into the same problem, with a slightly different testcase:
> cat crash.c
#pragma GCC push_options
#pragma GCC target ("arch=armv8.2-a+fp16")
#pragma GCC pop_options
results in the same crash:
crash.c:3:9: internal compiler error: 'global_options' are modified in local
context
3 | #pragma GCC pop_options
| ^~~
0x1199c6d cl_optimization_compare(gcc_options*, gcc_options*)
build-arm-none-eabi/obj/gcc2/gcc/options-save.c:14897
0xb38463 handle_pragma_pop_options
src/gcc/gcc/c-family/c-pragma.c:1092
0xb38eef c_invoke_pragma_handler(unsigned int)
src/gcc/gcc/c-family/c-pragma.c:1515
0xa80622 c_parser_pragma
src/gcc/gcc/c/c-parser.c:12525
0xa63dc6 c_parser_external_declaration
src/gcc/gcc/c/c-parser.c:1758
0xa63938 c_parser_translation_unit
src/gcc/gcc/c/c-parser.c:1650
0xaa6139 c_parse_file()
src/gcc/gcc/c/c-parser.c:21990
0xb322f2 c_common_parse_file()
src/gcc/gcc/c-family/c-opts.c:1211
[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98636
--- Comment #13 from prathamesh3492 at gcc dot gnu.org ---
IIUC, the issue comes from the following mismatch in cl_optimization_compare:
if (ptr1->x_arm_fp16_format != ptr2->x_arm_fp16_format)
internal_error ("% are modified in local context");
x_arm_fp16_format is of following type defined in arm-opts.h:
/* Which __fp16 format to use.
The enumeration values correspond to the numbering for the
Tag_ABI_FP_16bit_format attribute.
*/
enum arm_fp16_format_type
{
ARM_FP16_FORMAT_NONE = 0,
ARM_FP16_FORMAT_IEEE = 1,
ARM_FP16_FORMAT_ALTERNATIVE = 2
};
For the test-case passing -mfp16-format=alternative results in:
ptr1->x_arm_fp16_format == ARM_FP16_FORMAT_ALTERNATIVE and
ptr2->x_arm_fp16_format == ARM_FP16_FORMAT_IEEE,
and the mismatch results in ICE.
Thanks,
Prathamesh
[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #3 from David Binderman ---
Reduced code is:
template struct c { static constexpr int d = a; };
template struct e;
template struct e { typedef f g; };
template f aa();
class h {
public:
template void ab(i *, j...) { i(j()...); }
};
template using k = h;
template class l : public k {};
template struct m;
template struct m> {
using n = l;
using o = f *;
template using p = l;
template static void ab(n ac, i q, j...) {
ac.ab(q, j()...);
}
};
template struct r;
struct s : m>> {
struct ad {
typedef p> ae;
};
};
template struct af;
template using ag = typename af::g;
template class ah {};
template struct af> { typedef ai g;
};
template ag> ak(ah);
class al {
public:
template void operator=(w);
};
struct am {
struct an {
s::o ao;
};
struct : s::ad::ae, an {
} ap;
};
template class x : am {
public:
template s aq(j &&...);
};
template
template
s x::aq(j &&...) {
s::ab(ap, ap.ao, aa()...);
}
template class as;
template struct r {
int au;
r(at...);
template void aw(av);
};
class y {
public:
static constexpr struct {
template typename e::d, ax>::g ay();
template static typename e::d, ax>::g ay();
} az{};
};
template struct z {
static void bb() {
ah b;
ak(b) = y::az.ay;
}
};
template void be(bc, bd) { z<0>::bb; }
template r::r(at...) { aw(y::az); }
template template void r::aw(av ac) {
be(au, ac);
}
template class as {
public:
as ();
x bg;
};
template as ::bf() {
ax t;
bg.aq(t);
}
template as bh(at...);
auto bi = bh(1.0f).bf();
[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98636 --- Comment #12 from prathamesh3492 at gcc dot gnu.org --- Created attachment 50003 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50003=edit options-save.c
[Bug libgomp/98738] task-detach-6.f90 hangs intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98738 --- Comment #6 from Kwok Yeung --- It seems to be the '#pragma omp taskwait' inside the parallel region that is causing the intermittent hang - if you add it to task-detach-5.c, the hang also happens there (i.e. the target construct is not the problem). I think I added the taskwait because otherwise it always hung when the region was offloaded to a Nvidia accelerator.
[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #4 from Iain Sandoe --- (In reply to Nathan Sidwell from comment #3) > Oh, I see what you mean. > > FWIW this is the tip of a deceptively simple, but actually complex, iceberg. [for Darwin] These tests were working on the modules branch (although that might not be any help of course). IIRC - I did a small amount of debugging and found that (on Darwin) the underlying complaint was that it was not expecting a __cxa_xx function decl in the position that one appeared).
[Bug libgomp/98699] Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98699 --- Comment #3 from Bill Long --- Thanks, Tobias. GCC 11 should be fine. Great to see you back.
