[Bug tree-optimization/101301] Improving sparse switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #6 from Thomas Koenig ---
If I create a foo3 function with
int foo3 (int n)
{
if (__builtin_expect_with_probability (n >= 5, 1, 0.55))
{
if (__builtin_expect_with_probability (n >= 7, 1, 0.33/0.55))
{
if (__builtin_expect_with_probability (n == 7, 1, 0.1/0.33))
return 7;
if (__builtin_expect_with_probability (n == 8, 1, 0.1/0.23))
return 8;
if (__builtin_expect_with_probability (n == 9, 1, 0.1/0.11))
return 9;
return 0;
}
else
{
if (__builtin_expect_with_probability (n == 5, 1, 0.1/0.22))
return 5;
if (__builtin_expect_with_probability (n == 6, 1, 0.1/0.11))
return 6;
return 0;
}
}
else
{
if (__builtin_expect_with_probability (n >= 3, 1, 0.22/0.45))
{
if (__builtin_expect_with_probability (n == 3, 1, 0.1/0.22))
return 3;
if (__builtin_expect_with_probability (n == 4, 1, 0.1/0.11))
return 4;
return 0;
}
else
{
if (__builtin_expect_with_probability (n == 1, 1, 0.1/0.23))
return 1;
if (__builtin_expect_with_probability (n == 2, 1, 0.1/0.13))
return 2;
return 0;
}
}
}
the numbers on POWER9 become
[tkoenig@gcc135 ~]$ gcc -O3 bench.c a.c
[tkoenig@gcc135 ~]$ ./a.out
foo: 7.134855
foo2: 7.842507
foo3: 6.624406
[tkoenig@gcc135 ~]$ gcc -mcpu=native -O3 bench.c a.c
[tkoenig@gcc135 ~]$ ./a.out
foo: 6.458520
foo2: 7.696735
foo3: 6.196469
where, on a few runs, the differene betweeh foo and foo3 with -mcpu=native
sometimes disappears and sometimes is larger (gcc135 is not a benchmark
machine).
So, I'd say there some advantage in the compiler not lying to itself :-)
[Bug fortran/101320] New: Bind(C): Missing diagnostic for constraint C1557 on allocatable/pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101320 Bug ID: 101320 Summary: Bind(C): Missing diagnostic for constraint C1557 on allocatable/pointer arguments Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- In the WIP TS29113 testsuite posted here https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html the testcase types/c516.f90 tests the constraint labeled C516 in the TS 29113 document and C1557 in the 2018 standard: "If proc-language-binding-spec is specified for a procedure, it shall not have a default-initialized dummy argument with the ALLOCATABLE or POINTER attribute." Neither of the two places in that example that are expecting a diagnostic are producing one.
[Bug middle-end/83711] GNU GCC version in graphviz dot data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83711
gml4gtk changed:
What|Removed |Added
CC||mooigraph at gmail dot com
--- Comment #2 from gml4gtk ---
Created attachment 51103
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51103=edit
add GNU GCC version information to the graph output data
Created this patch to add GCC version information to the graph data
using gcc git version of sun 4 july 2021
and using gml4gtk graph viewer on sourceforge with the GNU GCC graph data
git describe
basepoints/gcc-12-1999-gd07092a61d5
gcc --version
gcc (GCC) 12.0.0 20210704 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The start of the gcc -fcallgraph-info output now looks like this:
/* callgraph generated by GNU GCC Compiler -fcallgraph-info option version
* GNU C17 (GCC) version 12.0.0 20210704 (experimental) (x86_64-pc-linux-gnu)
* compiled by GNU C version 12.0.0 20210704 (experimental), GMP version
6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version none
* GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
*/
graph: { title: "foo.c"
node: { title: "hello_GCC" label: "hello_GCC\nfoo.c:3:6" }
...
}
The start of the rtl, tree, ipa graph data look like this
generated with gcc -fdump-rtl-all-graph -fdump-tree-all-graph
-fdump-ipq-all-graph
/* graph generated by GNU GCC Compiler version
* GNU C99 (GCC) version 12.0.0 20210704 (experimental) (x86_64-pc-linux-gnu)
* compiled by GNU C version 12.0.0 20210704 (experimental), GMP version
6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version none
* GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
*/
digraph "gml4gtk-dot.tab.c.296r.ira" {
...
}
The start of the -fanalyzer graph output files look like this
/* graph generated by GNU GCC Compiler version
* GNU C99 (GCC) version 12.0.0 20210704 (experimental) (x86_64-pc-linux-gnu)
* compiled by GNU C version 12.0.0 20210704 (experimental), GMP version
6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version none
* GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
*/
digraph "base" {
...
}
[Bug libstdc++/100900] error: missing 'typename' prior to dependent type name in elements_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900 Dmitry V. Levin changed: What|Removed |Added CC||ldv at sourceware dot org --- Comment #9 from Dmitry V. Levin --- Since PR95983 fix was backported to gcc-10 (by commit 1cb39945993c89746b0347746bd1267de85cbc42), please backport this follow-up fix to gcc-10, too.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Larkin Nickle changed: What|Removed |Added CC||me at larbob dot org --- Comment #229 from Larkin Nickle --- I have not been able to reproduce a working GCC 4.7.4, 4.9.2, or 4.9.3 build against binutils 2.36. Using HP's GCC 4.7.1 distribution, I am able to compile 4.7.4 against /opt/hp-gcc/bin/as and build a 4.9.2 or 4.9.3 against that same as. However, building against a patched binutils 2.36 or 2.36.1 (comment #215) results in an error when linking: libtool: link: /home/larbob/Projects/gcc/confdirs/gcc-4.9.3-2/./gcc/xgcc -shared-libgcc -B/home/larbob/Projects/gcc/confdirs/gcc-4.9.3-2/./gcc -nostdinc++ -L/home/larbob/Projects/gcc/confdirs/gcc-4 .9.3-2/ia64-hp-hpux11.31/hpux64/libstdc++-v3/src -L/home/larbob/Projects/gcc/confdirs/gcc-4.9.3-2/ia64-hp-hpux11.31/hpux64/libstdc++-v3/src/.libs -L/home/larbob/Projects/gcc/confdirs/gcc-4.9.3-2/ia 64-hp-hpux11.31/hpux64/libstdc++-v3/libsupc++/.libs -B/usr/util/gcc-4.9.3/ia64-hp-hpux11.31/bin/ -B/usr/util/gcc-4.9.3/ia64-hp-hpux11.31/lib/ -isystem /usr/util/gcc-4.9.3/ia64-hp-hpux11.31/include -isystem /usr/util/gcc-4.9.3/ia64-hp-hpux11.31/sys-include -mlp64 -shared -nostdlib -fPIC -Wl,+h -Wl,libstdc++.so.6 -Wl,+nodefaultrpath -o .libs/libstdc++.so.6.20 .libs/compatibility.o .libs/com patibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compa tibility-condvar.o .libs/libstdc++.lax/libsupc++convenience.a/array_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/atexit_arm.o .libs/libstdc++.lax/libsupc++convenience.a/atexit_thread.o .libs/libstdc++.lax/libsupc++convenience.a/bad_alloc.o .libs/libstdc++.lax/libsupc++convenience.a/bad_array_length.o .libs/libstdc++.lax/libsupc++convenience.a/bad_array_new.o .libs/libstdc++.lax/l ibsupc++convenience.a/bad_cast.o .libs/libstdc++.lax/libsupc++convenience.a/bad_typeid.o .libs/libstdc++.lax/libsupc++convenience.a/class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/del_ op.o .libs/libstdc++.lax/libsupc++convenience.a/del_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/del_opv.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvnt.o .libs/libstdc++.lax/libsupc++c onvenience.a/dyncast.o .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o .libs/libstdc++.lax/libsupc++convenience.a/eh_arm.o .libs/libstdc++.lax/libsupc++convenience.a/eh_aux_runtime.o .libs/li bstdc++.lax/libsupc++convenience.a/eh_call.o .libs/libstdc++.lax/libsupc++convenience.a/eh_catch.o .libs/libstdc++.lax/libsupc++convenience.a/eh_exception.o .libs/libstdc++.lax/libsupc++convenience .a/eh_globals.o .libs/libstdc++.lax/libsupc++convenience.a/eh_personality.o .libs/libstdc++.lax/libsupc++convenience.a/eh_ptr.o .libs/libstdc++.lax/libsupc++convenience.a/eh_term_handler.o .libs/li bstdc++.lax/libsupc++convenience.a/eh_terminate.o .libs/libstdc++.lax/libsupc++convenience.a/eh_tm.o .libs/libstdc++.lax/libsupc++convenience.a/eh_throw.o .libs/libstdc++.lax/libsupc++convenience.a /eh_type.o .libs/libstdc++.lax/libsupc++convenience.a/eh_unex_handler.o .libs/libstdc++.lax/libsupc++convenience.a/enum_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/function_type_info.o . libs/libstdc++.lax/libsupc++convenience.a/fundamental_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/guard.o .libs/libstdc++.lax/libsupc++convenience.a/guard_error.o .libs/libstdc++.lax/libsupc++convenience.a/hash_bytes.o .libs/libstdc++.lax/libsupc++convenience.a/nested_exception.o .libs/libstdc++.lax/libsupc++convenience.a/new_handler.o .libs/libstdc++.lax/libsupc++convenience.a/n$w_op.o .libs/libstdc++.lax/libsupc++convenience.a/new_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/new_opv.o .libs/libstdc++.lax/libsupc++convenience.a/new_opvnt.o .libs/libstdc++.lax/libsupc$+convenience.a/pbase_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/pmem_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/pointer_type_info.o .libs/libstdc++.lax/libsupc++convenience$a/pure.o .libs/libstdc++.lax/libsupc++convenience.a/si_class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/tinfo.o .libs/libstdc++.lax/libsupc++convenience.a/tinfo2.o .libs/libstdc++.lax/$ibsupc++convenience.a/vec.o .libs/libstdc++.lax/libsupc++convenience.a/vmi_class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o .libs/libstdc++.lax/libsupc++convenience.a/cp-d$mangle.o .libs/libstdc++.lax/libc++98convenience.a/bitmap_allocator.o .libs/libstdc++.lax/libc++98convenience.a/pool_allocator.o .libs/libstdc++.lax/libc++98convenience.a/mt_allocator.o .libs/lib$tdc++.lax/libc++98convenience.a/codecvt.o .libs/libstdc++.lax/libc++98convenience.a/complex_io.o .libs/libstdc++.lax/libc++98convenience.a/ctype.o
[Bug c++/101288] Invalid instantiated redeclaration considered valid by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101288 --- Comment #1 from Eligor Kadaf --- Compiler shall provide diagnostics in the current example according to https://eel.is/c++draft/basic.def.odr#15
[Bug fortran/101319] New: Missing diagnostic for argument with type parameters for assumed-type dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101319 Bug ID: 101319 Summary: Missing diagnostic for argument with type parameters for assumed-type dummy Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- In section 15.5.2.4 Ordinary dummy variables, the Fortran 2018 standard says: If the actual argument is of a derived type that has type parameters, type-bound procedures, or final subroutines, the dummy argument shall not be assumed-type. gfortran is giving a diagnostic for the type-bound procedures and final subroutines cases, but not the derived type with type parameters case. Testcase is procedures/assumed-type-dummy.f90 included in the TS29113 testsuite posted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html
[Bug target/100269] [12 Regression] i686 biarch compiler fails for Darwin after r12-36.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:d07092a61d5a6907b2d92563e810bf5bb8e61c01 commit r12-1999-gd07092a61d5a6907b2d92563e810bf5bb8e61c01 Author: Iain Sandoe Date: Fri Apr 30 16:20:42 2021 +0100 Darwin, config : Adjust X86 biarch definitions ordering [PR100269]. This reorganises the biarch definitions to cater for the macro changes and removals at r12-36. Signed-off-by: Iain Sandoe PR target/100269 - [12 Regression] i686 biarch compiler fails for Darwin after r12-36. PR target/100269 gcc/ChangeLog: PR target/100269 * config.gcc: Ensure that Darwin biarch definitions are added before i386.h. * config/i386/darwin.h (TARGET_64BIT): Remove. (PR80556_WORKAROUND): New. (REAL_LIBGCC_SPEC): Amend to use PR80556_WORKAROUND. (DARWIN_SUBARCH_SPEC): New. * config/i386/darwin32-biarch.h (TARGET_64BIT_DEFAULT, TARGET_BI_ARCH, PR80556_WORKAROUND): New. (REAL_LIBGCC_SPEC): Remove. * config/i386/darwin64-biarch.h (TARGET_64BIT_DEFAULT, TARGET_BI_ARCH, PR80556_WORKAROUND): New. (REAL_LIBGCC_SPEC): Remove.
[Bug libstdc++/101318] [10 only] Comparison operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101318 Andrew Pinski changed: What|Removed |Added Summary|Comparison operator |[10 only] Comparison ||operator Target Milestone|--- |10.4
[Bug libstdc++/101318] New: Comparison operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101318
Bug ID: 101318
Summary: Comparison operator
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobias.bruell at gmail dot com
Target Milestone: ---
The comparison operators for std::array seem a bit broken in gcc 10.
Seems to work in gcc 11 and 12. The following program should probably print the
same value twice. I assume it's a problem with the standard library?
```
#include
#include
int main() {
int8_t const a = 0;
int8_t const b = -1;
std::cout << (a > b) << '\n';
std::array A = {a};
std::array B = {b};
std::cout << (A > B) << '\n';
}
```
[Bug c++/101287] Implicit template specialization redefines member function but compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101287 Eligor Kadaf changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Eligor Kadaf --- I dind't know I have to add a comment to close bug
[Bug c++/101287] Implicit template specialization redefines member function but compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101287 --- Comment #3 from Eligor Kadaf --- I had found this example during the investigation of one another exmaple from real life, which was the bug in clang, and as fas as it is marked as error in standard I had decided it must be compile time error. However, during further investigation of current example I have found it is an ill-formed; no diagnostics required, so I will close this report.
[Bug tree-optimization/101039] Some simple fold_cond_expr_with_comparison with CMP 0 is not simplified if expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101039 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-July/57 ||4414.html --- Comment #2 from Andrew Pinski --- Submitted latest patch, note it depends on previous ones though: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574414.html
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #12 from ofv at wanadoo dot es --- I don't see other failure messages on the previous dozens of lines but, if they exist, they are not deemed serious enough to stop the build by the build system. BTW, we successfully built gcc-11-dwarf with gcc-10-sjlj. Now we will see if the resulting binaries work for bootstrapping gcc-11. That would suggest that there is a problem with 10 and it is fixed/masked/whatever on 11.
[Bug middle-end/100536] ICE: in expand_call with large union (1GB) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100536 Andrew Pinski changed: What|Removed |Added CC||anbu1024.me at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 101314 has been marked as a duplicate of this bug. ***
[Bug c/101314] ICE: in expand_call, at calls.c:4986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101314 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 100536. *** This bug has been marked as a duplicate of bug 100536 ***
[Bug c/101313] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in count_type_elements, at expr.c:6273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101313 Andrew Pinski changed: What|Removed |Added Summary|[12 regression] ICE: tree |ICE: tree check: expected |check: expected class |class ‘type’, have |‘type’, have ‘exceptional’ |‘exceptional’ (error_mark) |(error_mark) in |in count_type_elements, at |count_type_elements, at |expr.c:6273 |expr.c:6273 | --- Comment #1 from Andrew Pinski --- (In reply to John X from comment #0) > $ gcc-sp11 test.c > test.c:7:15: error: field ‘x’ has incomplete type > 7 | enum test x; > | ^ > test.c:21: confused by earlier errors, bailing out This is ICE just hidden for release checking if there was a sorry/error before hand. So this is not a regression from GCC 11.
[Bug c/101314] ICE: in expand_call, at calls.c:4986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101314 Andrew Pinski changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code --- Comment #1 from Andrew Pinski --- (In reply to John X from comment #0) > $ gcc-sp11 test.c > test.c: In function ‘main’: > test.c:13:3: sorry, unimplemented: passing too large argument on stack >13 | foo(a); > | ^~ > test.c:13: confused by earlier errors, bailing out This is ICE just hidden for release checking if there was a sorry/error before hand. So this is not a regression from GCC 11.
[Bug libfortran/101317] New: Bind(C): improve error checking in CFI_* functions declared in ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101317 Bug ID: 101317 Summary: Bind(C): improve error checking in CFI_* functions declared in ISO_Fortran_binding.h Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- ISO_Fortran_binding.h defines macros to indicate error conditions in functions such as CFI_establish, CFI_setpointer, etc that are declared in that header; it's table 18.5 in the 2018 Fortran standard. There seems to be no actual requirement that the library functions detect and return particular error codes (IIUC the "shall be" language in the argument descriptions implies undefined behavior otherwise), but the functions already do detect some errors with -fcheck=all. However, I noted some other easy-to-detect errors are not being checked. Test cases are library/establish-errors.f90 and library/setpointer-errors.f90, in the WIP TS 29113 testsuite. https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html
[Bug tree-optimization/101301] Improving sparse switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301 --- Comment #5 from Segher Boessenkool --- Looking at -fdump-tree-all-all, things are fine with "foo" until the switchlower pass. Before that all nine switch cases and the default case all had probability 0.10; after the switch conversion there are many basic blocks with "Invalid sum of incoming counts", and not everything has the same probability any more.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #11 from Eric Botcazou --- > Other users reported that only DWARF crashes. If the build is configured for > SJLJ or SEH exception models, it completes. > > A user speculated that the problem might be related to Gcc 11 using DWARF 5 > now. If you think that that is plausible and instruct me on how to revert > that change I'll test the hypothesis. We do have successful builds (DWARF EH + DWARF 5), that's why I'm trying to understand what's different in your setup. Do you really have no other failure message than the one output by 'make'?
[Bug fortran/100227] [9/10/11/12 Regression] write with implicit loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug libstdc++/57840] ::std ::result_of is undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840 --- Comment #9 from Christopher Yeleighton --- (In reply to Jonathan Wakely from comment #8) > Already fixed in r12-1964 > > You know doxygen output isn't the only way to look at the code, right? I thought merged commits refresh the published documentation.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #10 from ofv at wanadoo dot es --- Setting CFLAGS/CXXFLAGS/BOOT_CFLAGS to -dwarf-4 has no effect: the build fails the same.
[Bug c++/97077] Missed loop unrolling with range for over initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97077 magiblot at hotmail dot com changed: What|Removed |Added CC||magiblot at hotmail dot com --- Comment #2 from magiblot at hotmail dot com --- According to Godbolt, from GCC 7.1 to GCC 7.5 the loop gets unrolled if the initializer list has no more than four elements: https://godbolt.org/z/YhKjn4qj3 So this is not only a missed optimization, but also a regression.
[Bug c++/101316] New: [[maybe_unused]] to the right of array size accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101316
Bug ID: 101316
Summary: [[maybe_unused]] to the right of array size accepted
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at alanwu dot email
Target Milestone: ---
GCC 11.1.0 and trunk accepts [[maybe_unused]] in the following in a way
the standard doesn't seem to allow:
void func() {
int one, two[2] [[maybe_unused]];
}
$ g++ -c -std=c++20 -Wall test.cc
test.cc: In function ‘void func()’:
test.cc:2:13: warning: unused variable ‘one’ [-Wunused-variable]
2 | int one, two[2] [[maybe_unused]];
| ^~~
There is no unused variable warning about `two` because it
accepts the attribute.
The declaration for `two` matches the form outlined in
[dcl.array]p3 which says the attribute appertains to the array type.
[dcl.attr.unused]p2 doesn't allow [[maybe_unused]] to apply to type entities.
[dcl.attr.grammar]p5 says that when an attribute appertains to an entity
that it's not allowed to apply to, the program is ill-formed.
Should g++ reject the program in this case?
https://godbolt.org/z/EWr4q63cT
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #9 from ofv at wanadoo dot es --- With those variables unset the build fails the same. Other users reported that only DWARF crashes. If the build is configured for SJLJ or SEH exception models, it completes. A user speculated that the problem might be related to Gcc 11 using DWARF 5 now. If you think that that is plausible and instruct me on how to revert that change I'll test the hypothesis.
[Bug c++/101315] New: C++20 lambdas in unevaluated context: erroneously fails with "incomplete type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101315
Bug ID: 101315
Summary: C++20 lambdas in unevaluated context: erroneously
fails with "incomplete type"
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janpmoeller at gmx dot de
Target Milestone: ---
gcc 11.1 and gcc (trunk) fail to compile the following code with --std=c++20:
(1)
#include
#include
template Fn>
struct foo_t {
foo_t(Ptr ptr) {}
};
template
using alias = foo_t;
template
auto fun(T const& t) {
return alias{t};
}
int main() {
std::vector v;
auto const error = fun(v);
}
Both versions of gcc state:
: In function 'int main()':
:19:14: error: 'const void error' has incomplete type
19 | auto const error = fun(v);
| ^
Compiler returned: 1
The issue seems to somehow be related to the alias. Replacing the definition of
fun() with this code results in successful compilation:
(2)
template
auto fun(T const& t) {
return foo_t{t};
}
Specifying the return type of fun() explicitly results in a different error:
(3)
template
auto fun(T const& t) -> alias {
return alias{t};
}
: In function 'int main()':
:19:22: error: 'fun' was not declared in this scope
19 | auto const error = fun(v);
| ^~~
Compiler returned: 1
I believe all three variants to be valid c++20.
clang (trunk) compiles versions (1) and (2) of the code, (3) results in a
frontend crash (I'm going to file a bug report against clang for that as well.
I'll comment it here for reference after I'm done).
Also see this link to godbolt: https://godbolt.org/z/r9GMfxzEo
[Bug c/101314] New: [12 Regression] ICE: in expand_call, at calls.c:4986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101314
Bug ID: 101314
Summary: [12 Regression] ICE: in expand_call, at calls.c:4986
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
struct A
{
char x[0x];
};
extern void foo(struct A);
struct A a;
void main(void)
{
foo(a);
}
$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210627 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-sp12 test.c
test.c: In function ‘main’:
test.c:13:3: sorry, unimplemented: passing too large argument on stack
13 | foo(a);
| ^~
during RTL pass: expand
test.c:13:3: internal compiler error: in expand_call, at calls.c:4986
0x6a0164 expand_call(tree_node*, rtx_def*, int)
../../gcc-12-20210627/gcc/calls.c:4986
0xafcb9e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-12-20210627/gcc/expr.c:11442
0x9d7b3b expand_expr
../../gcc-12-20210627/gcc/expr.h:301
0x9d7b3b expand_call_stmt
../../gcc-12-20210627/gcc/cfgexpand.c:2846
0x9d7b3b expand_gimple_stmt_1
../../gcc-12-20210627/gcc/cfgexpand.c:3877
0x9d7b3b expand_gimple_stmt
../../gcc-12-20210627/gcc/cfgexpand.c:4041
0x9dd8c3 expand_gimple_basic_block
../../gcc-12-20210627/gcc/cfgexpand.c:6083
0x9df677 execute
../../gcc-12-20210627/gcc/cfgexpand.c:6809
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/101313] New: [12 regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in count_type_elements, at expr.c:6273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101313
Bug ID: 101313
Summary: [12 regression] ICE: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in
count_type_elements, at expr.c:6273
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
struct struct_A
{
union bar
{
enum test x;
} var;
};
struct struct_B
{
int x;
struct struct_A a;
};
int foo()
{
struct struct_A a = {0};
struct struct_B b = {2, a};
}
$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210627 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-sp12 test.c
test.c:7:15: error: field ‘x’ has incomplete type
7 | enum test x;
| ^
test.c: In function ‘foo’:
test.c:21:19: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in count_type_elements, at expr.c:6273
21 | struct struct_B b = {2, a};
| ^
0x7a7886 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-12-20210627/gcc/tree.c:8734
0x6c0d82 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-12-20210627/gcc/tree.h:3496
0x6c0d82 count_type_elements
../../gcc-12-20210627/gcc/expr.c:6273
0xaed8c0 count_type_elements
../../gcc-12-20210627/gcc/expr.c:6245
0xaf0c09 categorize_ctor_elements_1
../../gcc-12-20210627/gcc/expr.c:6426
0xbc651b gimplify_init_constructor
../../gcc-12-20210627/gcc/gimplify.c:4932
0xbd710a gimplify_modify_expr
../../gcc-12-20210627/gcc/gimplify.c:5762
0xbbf26f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210627/gcc/gimplify.c:14210
0xbc2bf6 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210627/gcc/gimplify.c:6869
0xbcc38d gimplify_and_add(tree_node*, gimple**)
../../gcc-12-20210627/gcc/gimplify.c:494
0xbcc38d gimplify_decl_expr
../../gcc-12-20210627/gcc/gimplify.c:1831
0xbbf566 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210627/gcc/gimplify.c:14407
0xbc2bf6 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210627/gcc/gimplify.c:6869
0xbc01e3 gimplify_statement_list
../../gcc-12-20210627/gcc/gimplify.c:1887
0xbc01e3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210627/gcc/gimplify.c:14655
0xbc2bf6 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210627/gcc/gimplify.c:6869
0xbc334d gimplify_bind_expr
../../gcc-12-20210627/gcc/gimplify.c:1426
0xbc0eae gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210627/gcc/gimplify.c:14411
0xbd8759 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210627/gcc/gimplify.c:6869
0xbd8759 gimplify_body(tree_node*, bool)
../../gcc-12-20210627/gcc/gimplify.c:15442
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/70417] Unhelpful diagnostic for dependent template-name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70417 Anthony Sharp changed: What|Removed |Added CC||anthonysharp15 at gmail dot com --- Comment #3 from Anthony Sharp --- I am working on a fix for this.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #8 from Eric Botcazou --- > make BOOT_CFLAGS='-O1' V=1 all > > make BOOT_CFLAGS='-O0' V=1 > > both fails the same way as the initial report. That's not what I was asking for though, BOOT_CFLAGS should generally not be fiddled with. > Finally, trying to reduce as much as possible the optimization passes: > > export CFLAGS="-march=i686 -mtune=generic -Og -pipe" > export CXXFLAGS="-march=i686 -mtune=generic -Og -pipe" > make BOOT_CFLAGS='-Og' V=1 What happens if you do not set any of CFLAGS/CXXFLAGS/BOOT_CFLAGS?
