[Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Bug ID: 96416
Summary: address_of() is broken by static_assert in
pointer_traits
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: whatwasthataddress at gmail dot com
Target Milestone: ---
pointer_traits contains this static_assert:
static_assert(!is_same::value,
"pointer type defines element_type or is like SomePointer");
When trying to use address_of() with an iterator that has a usable
operator->(), address_of() fails because the static_assert causes a hard error
in the trailing decltype here:
template
constexpr auto
__to_address(const _Ptr& __ptr) noexcept
-> decltype(std::pointer_traits<_Ptr>::to_address(__ptr))
{ return std::pointer_traits<_Ptr>::to_address(__ptr); }
template
constexpr auto
__to_address(const _Ptr& __ptr, _None...) noexcept
{
if constexpr (is_base_of_v<__gnu_debug::_Safe_iterator_base, _Ptr>)
return std::__to_address(__ptr.base().operator->());
else
return std::__to_address(__ptr.operator->());
}
When I comment out the static_assert, to_address() works with the iterator in
question.
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #13 from David Edelsohn --- The symptom I see on AIX is that the labels for DWARF variable locations differ between stage2 and stage3 for some files. The difference started with the recent change to the var-tracking pass. Once the labels diverge, the addresses no longer match and the object file differ. The var-tracking dump files are over 1GB with lots of address differences, but it doesn't contain any differences in the BB dump output for vt_find_locations, which is the function that was changed. The assembly file differences give the appearance of an unstable sort. The beginning of the difference for an assembly file looks like: --- tree-vrp.S 2020-08-01 19:42:00.0 -0400 +++ ../gcc/tree-vrp.S 2020-08-01 19:43:33.0 -0400 @@ -38428,8 +38428,8 @@ LM..7111: addi 19,1,792 li 20,1 -L..2070: LVL..2903: +L..2070: LBE..22006: LBE..22005: LBE..22004: @@ -38466,6 +38466,7 @@ LM..7114: cmpwi 0,31,0 beq 0,L..2043 +LVL..2904: LBB..22481: LM..7115: LM..7116: @@ -38475,12 +38476,12 @@ mr 30,31 bl .memcpy nop -LVL..2904: +LVL..2905: LM..7117: LM..7118: LM..7119: lwz 27,8(31) -LVL..2905: +LVL..2906: LM..7120: LM..7121: lwz 9,4(27) @@ -38489,7 +38490,7 @@ beq 0,L..2348 L..2044: LM..7123: -LVL..2906: +LVL..2907: LBE..22481: LBE..22508: LBE..22535:
[Bug tree-optimization/96415] New: GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96415
Bug ID: 96415
Summary: GCC produces incorrect code for loops with -O3 for
skylake-avx512 and icelake-server
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Error:
>$ g++ -O0 driver.cpp func.cpp && ./a.out
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0
>$ g++ -O3 driver.cpp func.cpp -march=skylake-avx512 && sde -skx -- ./a.out
1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 0
Reproducer:
//driver.cpp
#include
unsigned short var_0 = 14;
unsigned int arr_10 [16];
void test(unsigned short var_0);
int main() {
test(var_0);
for (int i = 0; i < 16; ++i)
printf("%u ", arr_10[i]);
printf("\n");
}
//func.cpp
extern int arr_10[16];
void test(unsigned short a) {
for (unsigned e = 0; e < 16; e += 4)
for (char f = 0; f < 6; f += 4)
for (unsigned g = 0; g < a + 1; g++)
arr_10[g] = 1;
}
GCC version:
11.0.0 (3a4a92598014d33ef2c8b8ec38d8ad917812921a)
I also applied the fix for bug #95396
[Bug c++/96414] Second char relation test incorrect with constexpr dynamic allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96414
--- Comment #1 from Paul Keir ---
constexpr int lt_fun(const char& c1, const char& c2) {
return c1 < c2;
}
constexpr bool doit()
{
char *pc = new char;
const char* s = "a";
*pc = 'b';
lt_fun(*s, *pc); // a < b
*pc = 'a';
bool lt = lt_fun(*s, *pc); // a < a
delete pc;
return !lt;
}
int main(int argc, char *argv[])
{
static_assert(doit());
return doit() ? 0 : -1;
}
[Bug c++/96414] New: Second char relation test incorrect with constexpr dynamic allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96414 Bug ID: 96414 Summary: Second char relation test incorrect with constexpr dynamic allocation Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pkeir at outlook dot com Target Milestone: --- Created attachment 48981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48981=edit The file containing the code described. The attached C++20 code behaves differently at compile-time than at runtime, but shouldn't. As with `__gnu_cxx::char_traits::lt`, the function `lt_fun` applies built-in `operator<` to two character references, and returns the result as an `int`. However, with the character pointer `pc` pointing to memory allocated dynamically, the second call returns true (1) indicating that 'a' < 'a' is true. This is demonstrated by a failing static assert. Commenting out the static assert produces an executable which correctly reports that 'a' < 'a' is false; by returning a 0.
[Bug libstdc++/96413] New: Is single parameter specialisation useful besides variadic template?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96413
Bug ID: 96413
Summary: Is single parameter specialisation useful besides
variadic template?
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gogdizzy at qq dot com
Target Milestone: ---
I read some code from in gcc 10.2.0
```
// Manage in-place contained object.
template
struct _Manager_internal
{
static void
_S_manage(_Op __which, const any* __anyp, _Arg* __arg);
template
static void
_S_create(_Storage& __storage, _Up&& __value)
{
void* __addr = &__storage._M_buffer;
::new (__addr) _Tp(std::forward<_Up>(__value));
}
template
static void
_S_create(_Storage& __storage, _Args&&... __args)
{
void* __addr = &__storage._M_buffer;
::new (__addr) _Tp(std::forward<_Args>(__args)...);
}
};
```
And I can't understand why there are two _S_create, the second is superset of
the first, isn't it? Can we omit the first one?
[Bug c/96407] LTO inlined functions don't inherit disabled warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2020-08-01 Assignee|unassigned at gcc dot gnu.org |law at redhat dot com CC||law at redhat dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 --- Comment #15 from Jan Hubicka --- > I think, this inliner change needs to be reverted. People expect -O2 to > produce > decently optimized binaries, and starting with gcc 10.x it doesn't deliver. > -O3 > traditionally enabled optimizations that may or may not improve performance > (and historically, sometimes even break code), so most projects don't use it. I wrote a short description of inliner changes to the phoronix discussion https://www.phoronix.com/forums/forum/software/programming-compilers/1196789-gcc-benchmarks-at-varying-optimization-levels-with-core-i9-10900k-show-an-unexpected-surprise/page5 comment 44. Inliner changes was not targetting to make compile time faster and compiled code slower. It was intended to reflect more closely modern C++ codebases and get faster binaries (at -O2 and -O2 -flto) without regressing in code sizes. In fact more inlining happens and thus we needed to optimize inliner code carefully to avoid regressions with LTO. It was benchmarked on wide range of bechmarks including some where phoronix measured a degradation before GCC10 release. The benchmarks presented does not reproduce and seems odd. 50% on very simple benchmarks is bit too much for a change in one optimization. It seems more like thermal throttling. Michael promised to re-run the tests and he is still spekaing about htat in the last reply from 31st. Testcases are greatly welcome. Honza
Re: [Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
> I think, this inliner change needs to be reverted. People expect -O2 to > produce > decently optimized binaries, and starting with gcc 10.x it doesn't deliver. > -O3 > traditionally enabled optimizations that may or may not improve performance > (and historically, sometimes even break code), so most projects don't use it. I wrote a short description of inliner changes to the phoronix discussion https://www.phoronix.com/forums/forum/software/programming-compilers/1196789-gcc-benchmarks-at-varying-optimization-levels-with-core-i9-10900k-show-an-unexpected-surprise/page5 comment 44. Inliner changes was not targetting to make compile time faster and compiled code slower. It was intended to reflect more closely modern C++ codebases and get faster binaries (at -O2 and -O2 -flto) without regressing in code sizes. In fact more inlining happens and thus we needed to optimize inliner code carefully to avoid regressions with LTO. It was benchmarked on wide range of bechmarks including some where phoronix measured a degradation before GCC10 release. The benchmarks presented does not reproduce and seems odd. 50% on very simple benchmarks is bit too much for a change in one optimization. It seems more like thermal throttling. Michael promised to re-run the tests and he is still spekaing about htat in the last reply from 31st. Testcases are greatly welcome. Honza
[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 --- Comment #14 from Dávid Bolvanský --- Or change -Os to be gcc10 -O2 with less inlining, -revert O2 to gcc9 -02 and implement -Oz to create agressive “-Os”.
[Bug d/96140] internal compiler error: in expand_intrinsic_vaarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96140 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Buclaw --- Fixed.
[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 --- Comment #13 from andysem at mail dot ru --- I think, this inliner change needs to be reverted. People expect -O2 to produce decently optimized binaries, and starting with gcc 10.x it doesn't deliver. -O3 traditionally enabled optimizations that may or may not improve performance (and historically, sometimes even break code), so most projects don't use it. If there needs to be an optimization mode that prioritizes compilation speed then let that be a separate mode, e.g. -O1.
[Bug d/96140] internal compiler error: in expand_intrinsic_vaarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96140 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:a6e2dc45099d5d23dfeae245617f316e95ac646b commit r9-8776-ga6e2dc45099d5d23dfeae245617f316e95ac646b Author: Iain Buclaw Date: Thu Jul 16 18:34:18 2020 +0200 d: Fix ICE in expand_intrinsic_vaarg Both intrinsics did not handle the case where the va_list object comes from a ref parameter. gcc/d/ChangeLog: PR d/96140 * intrinsics.cc (expand_intrinsic_vaarg): Handle ref parameters as arguments to va_arg(). (expand_intrinsic_vastart): Handle ref parameters as arguments to va_start(). gcc/testsuite/ChangeLog: PR d/96140 * gdc.dg/pr96140.d: New test. (cherry picked from commit dfc420f8d4492dbf5f45df4fecf93cb9645c0d7b)
[Bug d/96140] internal compiler error: in expand_intrinsic_vaarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96140 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:891bd1f15280def813bf6a363495d44951e13e04 commit r10-8558-g891bd1f15280def813bf6a363495d44951e13e04 Author: Iain Buclaw Date: Thu Jul 16 18:34:18 2020 +0200 d: Fix ICE in expand_intrinsic_vaarg Both intrinsics did not handle the case where the va_list object comes from a ref parameter. gcc/d/ChangeLog: PR d/96140 * intrinsics.cc (expand_intrinsic_vaarg): Handle ref parameters as arguments to va_arg(). (expand_intrinsic_vastart): Handle ref parameters as arguments to va_start(). gcc/testsuite/ChangeLog: PR d/96140 * gdc.dg/pr96140.d: New test. (cherry picked from commit dfc420f8d4492dbf5f45df4fecf93cb9645c0d7b)
[Bug c++/96412] New: format suggestion issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96412
Bug ID: 96412
Summary: format suggestion issue
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Running on godbolt trunk
The suggestion is '%ld' in green type colour in the terminal, but should it
actually be '%zu' ?
-Wformat-signedness -Wall
#include
int main()
{
size_t i = 0;
printf("%ld\n", i);
}
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:5:11: warning: format '%ld' expects argument of type 'long int', but
argument 2 has type 'size_t' {aka 'long unsigned int'} [-Wformat=]
5 | printf("%ld\n", i);
| ~~^ ~
| | |
| | size_t {aka long unsigned int}
| long int
| %ld
Compiler returned: 0
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #12 from David Edelsohn --- r11-2446 succeeds and r11-2447 fails, so the failure (at least on AIX) is the var-tracking dataflow patch.
[Bug c++/96411] New: erroneous "trait used in its own initializer" error when using concepts in a requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96411
Bug ID: 96411
Summary: erroneous "trait used in its own initializer" error
when using concepts in a requirement
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced from StackOverflow (https://stackoverflow.com/q/63202619/2069064):
template constexpr bool trait = true;
template concept C = trait;
void f(auto) {
[](){
requires { C; };
};
}
int main() { f(42); }
This fails on gcc 10.2 with:
: In instantiation of 'void f(auto:1) [with auto:1 = int]':
:10:18: required from here
:2:31: required by the constraints of 'template concept C'
:2:35: error: the value of 'trait' is not usable in a constant
expression
2 | template concept C = trait;
| ^~~~
:1:36: note: 'trait' used in its own initializer
1 | template constexpr bool trait = true;
|^
Compiler returned: 1
But trait isn't used in its own initializer, and trait is certainly
usable in a constant expression.
[Bug c/96407] LTO inlined functions don't inherit disabled warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- Same for using -Wstack-usage= on the command line. It is one of the workarounds needed for building elfutils with LTO enabled: https://sourceware.org/pipermail/elfutils-devel/2020q2/002733.html This version of elfutils handles debuginfo generated with GCC LTO better and it can finally be build with GCC LTO itself: export AR=gcc-ar RANLIB=gcc-ranlib NM=gcc-nm ./configure CFLAGS="-O2 -g -flto=auto -flto-partition=none \ -Wno-error=stack-usage=" \ CXXFLAGS="-O2 -g -flto=auto -flto-partition=none" Note the two workaround. -flto-partition=none is needed to preserve the symbol versioning. -Wno-error=stack-usage= is needed because LTO will combine objects build with and without a -Wstack-usage limit.
[Bug c++/96409] A lambda with a template parameter list inside the template function using C++20 nested requirements clauses occurs internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96409 --- Comment #2 from 康桓瑋 --- Equivalent example: https://godbolt.org/z/n47Gfh
[Bug c++/96408] C++20 new attribute [[no_unique_address]] occurs internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96408 --- Comment #3 from 康桓瑋 --- Live example: https://godbolt.org/z/vMT5Md
[Bug c++/96410] A lambda with a template parameter list inside the template function using C++20 requires clauses is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96410 --- Comment #1 from 康桓瑋 --- Equivalent example: https://godbolt.org/z/chYW3c
[Bug c++/96410] New: A lambda with a template parameter list using C++20 requires clauses is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96410
Bug ID: 96410
Summary: A lambda with a template parameter list using C++20
requires clauses is not usable in a constant
expression
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Created attachment 48980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48980=edit
the preprocessed file
The following code:
#include
template
void f(T t) {
auto g = [](U u) {
if constexpr (requires { std::integral; });
};
g(t);
}
int main()
{
f(1);
}
will occurs compile error:
: In instantiation of 'void f(T) [with T = int]':
:13:6: required from here
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/concepts:102:13:
required by the constraints of 'template concept std::integral'
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/concepts:102:24: error:
the value of 'std::is_integral_v' is not usable in a constant expression
102 | concept integral = is_integral_v<_Tp>;
|^~
In file included from
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/concepts:44,
from :1:
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:3031:25: note:
'std::is_integral_v' used in its own initializer
3031 | inline constexpr bool is_integral_v = is_integral<_Tp>::value;
| ^
ASM generation compiler returned: 1
This seems weird since the type U can be deduced in the compiler time.
command line:
$ gcc -v -save-temps -std=c++20 main.cpp
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc-10
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/lto-wrapper
Target: x86_64-apple-darwin17
Configured with: ../configure --build=x86_64-apple-darwin17
--prefix=/usr/local/Cellar/gcc/10.1.0
--libdir=/usr/local/Cellar/gcc/10.1.0/lib/gcc/10 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-10 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC 10.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib SED=/usr/bin/sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (Homebrew GCC 10.1.0)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a'
'-mmacosx-version-min=10.13.0' '-asm_macosx_version_min=10.13' '-mtune=core2'
/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/cc1plus
-E -quiet -v -D__DYNAMIC__ main.cpp -fPIC -mmacosx-version-min=10.13.0
-mtune=core2 -std=c++2a -fpch-preprocess -o main.ii
ignoring duplicate directory "/usr/local/include"
ignoring nonexistent directory
"/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../x86_64-apple-darwin17/include"
#include "..." search starts here:
#include <...> search starts here:
.
/usr/local/include
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0/x86_64-apple-darwin17
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0/backward
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/include
/usr/local/Cellar/gcc/10.1.0/include
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a'
'-mmacosx-version-min=10.13.0' '-asm_macosx_version_min=10.13' '-mtune=core2'
/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/cc1plus
-fpreprocessed main.ii -fPIC -quiet -dumpbase main.cpp
-mmacosx-version-min=10.13.0 -mtune=core2 -auxbase main -std=c++2a -version -o
main.s
GNU C++17 (Homebrew GCC 10.1.0) version 10.1.0 (x86_64-apple-darwin17)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Homebrew GCC 10.1.0) version 10.1.0 (x86_64-apple-darwin17)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b1074358e29f54f1a357a06623845700
In file included from main.cpp:1:
main.cpp: In instantiation of 'void f(T) [with T = int]':
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214 --- Comment #5 from Jonny Grant --- I saw this similar one too:- https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options -Wduplicated-cond Warn about duplicated conditions in an if-else-if chain. For instance, warn for the following code:
[Bug c++/96408] C++20 new attribute [[no_unique_address]] occurs the internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96408 --- Comment #2 from 康桓瑋 --- Created attachment 48979 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48979=edit the source file
[Bug c++/96409] A lambda with a template parameter list inside the template function using C++20 nested requirements clauses occurs internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96409 --- Comment #1 from 康桓瑋 --- Created attachment 48978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48978=edit the source file
[Bug c++/96409] New: A lambda with a template parameter list inside the template function using C++20 nested requirements clauses occurs internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96409
Bug ID: 96409
Summary: A lambda with a template parameter list inside the
template function using C++20 nested requirements
clauses occurs internal compiler error
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Created attachment 48977
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48977=edit
the preprocessed file
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc-10
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/lto-wrapper
Target: x86_64-apple-darwin17
Configured with: ../configure --build=x86_64-apple-darwin17
--prefix=/usr/local/Cellar/gcc/10.1.0
--libdir=/usr/local/Cellar/gcc/10.1.0/lib/gcc/10 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-10 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC 10.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib SED=/usr/bin/sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (Homebrew GCC 10.1.0)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a'
'-mmacosx-version-min=10.13.0' '-asm_macosx_version_min=10.13' '-mtune=core2'
/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/cc1plus
-E -quiet -v -D__DYNAMIC__ main.cpp -fPIC -mmacosx-version-min=10.13.0
-mtune=core2 -std=c++2a -fpch-preprocess -o main.ii
ignoring duplicate directory "/usr/local/include"
ignoring nonexistent directory
"/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../x86_64-apple-darwin17/include"
#include "..." search starts here:
#include <...> search starts here:
.
/usr/local/include
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0/x86_64-apple-darwin17
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0/backward
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/include
/usr/local/Cellar/gcc/10.1.0/include
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a'
'-mmacosx-version-min=10.13.0' '-asm_macosx_version_min=10.13' '-mtune=core2'
/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/cc1plus
-fpreprocessed main.ii -fPIC -quiet -dumpbase main.cpp
-mmacosx-version-min=10.13.0 -mtune=core2 -auxbase main -std=c++2a -version -o
main.s
GNU C++17 (Homebrew GCC 10.1.0) version 10.1.0 (x86_64-apple-darwin17)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Homebrew GCC 10.1.0) version 10.1.0 (x86_64-apple-darwin17)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b1074358e29f54f1a357a06623845700
main.cpp: In instantiation of 'void f(T) [with T = std::vector]':
main.cpp:14:23: required from here
main.cpp:7:39: internal compiler error: in dependent_type_p, at cp/pt.c:26343
7 | if constexpr (requires { requires std::same_as>; });
|
~^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug c++/96408] C++20 new attribute [[no_unique_address]] occurs the internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96408 --- Comment #1 from 康桓瑋 --- Created attachment 48976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48976=edit the preprocessed file gcc -v -save-temps -std=c++20 main.cpp
[Bug c++/96408] New: C++20 new attribute [[no_unique_address]] occurs the internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96408
Bug ID: 96408
Summary: C++20 new attribute [[no_unique_address]] occurs the
internal compile error
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc-10
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/lto-wrapper
Target: x86_64-apple-darwin17
Configured with: ../configure --build=x86_64-apple-darwin17
--prefix=/usr/local/Cellar/gcc/10.1.0
--libdir=/usr/local/Cellar/gcc/10.1.0/lib/gcc/10 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-10 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC 10.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib SED=/usr/bin/sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (Homebrew GCC 10.1.0)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a'
'-mmacosx-version-min=10.13.0' '-asm_macosx_version_min=10.13' '-mtune=core2'
/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/cc1plus
-E -quiet -v -D__DYNAMIC__ main.cpp -fPIC -mmacosx-version-min=10.13.0
-mtune=core2 -std=c++2a -fpch-preprocess -o main.ii
ignoring duplicate directory "/usr/local/include"
ignoring nonexistent directory
"/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../x86_64-apple-darwin17/include"
#include "..." search starts here:
#include <...> search starts here:
.
/usr/local/include
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0/x86_64-apple-darwin17
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/../../../../../../include/c++/10.1.0/backward
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/include
/usr/local/Cellar/gcc/10.1.0/include
/usr/local/Cellar/gcc/10.1.0/lib/gcc/10/gcc/x86_64-apple-darwin17/10.1.0/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a'
'-mmacosx-version-min=10.13.0' '-asm_macosx_version_min=10.13' '-mtune=core2'
/usr/local/Cellar/gcc/10.1.0/libexec/gcc/x86_64-apple-darwin17/10.1.0/cc1plus
-fpreprocessed main.ii -fPIC -quiet -dumpbase main.cpp
-mmacosx-version-min=10.13.0 -mtune=core2 -auxbase main -std=c++2a -version -o
main.s
GNU C++17 (Homebrew GCC 10.1.0) version 10.1.0 (x86_64-apple-darwin17)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Homebrew GCC 10.1.0) version 10.1.0 (x86_64-apple-darwin17)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b1074358e29f54f1a357a06623845700
during RTL pass: expand
main.cpp: In copy constructor 'vector::vector(const vector&)':
main.cpp:7:109: internal compiler error: in assign_temp, at function.c:984
7 | :
alloc_(std::allocator_traits>::select_on_container_copy_construction(other.alloc_))
{ }
|
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #11 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:7d599ad27b9bcf5165f87710f1abc64bbabd06ae
commit r11-2481-g7d599ad27b9bcf5165f87710f1abc64bbabd06ae
Author: Richard Sandiford
Date: Sat Aug 1 12:41:28 2020 +0100
c: Fix bogus vector initialisation error [PR96377]
One of the problems in this PR was that if we had:
vector_type1 array[] = { vector_value1 };
process_init_element would only treat vector_value1 as initialising
a vector_type1 if they had the same TYPE_MAIN_VARIANT. This has
several problems:
(1) It gives confusing error messages if the vector types are
incompatible. (Tested by gcc.dg/pr96377-1.c.)
(2) It means that we reject code that should be valid with
-flax-vector-conversions. (Tested by gcc.dg/pr96377-2.c.)
(3) On arm and aarch64 targets, it means that we reject some
initializers that mix Advanced SIMD and standard GNU vectors.
These vectors have traditionally had different TYPE_MAIN_VARIANTs
because they have different mangling schemes. (Tested by
gcc.dg/pr96377-[3-6].c.)
(4) It means that we reject SVE initializers that should be valid.
(Tested by gcc.target/aarch64/sve/gnu_vectors_[34].c.)
(5) After r11-1741-g:31427b974ed7b7dd54e2 we reject:
arm_neon_type1 array[] = { k ^ arm_neon_value1 };
because applying the binary operator to arm_neon_value1 strips
the "Advanced SIMD type" attributes that were added in that patch.
Stripping the attributes is problematic for other reasons though,
so that still needs to be fixed separately.
g++.target/aarch64/sve/gnu_vectors_[34].C already pass.
gcc/c/
PR c/96377
* c-typeck.c (process_init_element): Split test for whether to
recurse into a record, union or array into...
(initialize_elementwise_p): ...this new function. Don't recurse
into a vector type if the initialization value is also a vector.
gcc/testsuite/
PR c/96377
* gcc.dg/pr96377-1.c: New test.
* gcc.dg/pr96377-2.c: Likewise.
* gcc.dg/pr96377-3.c: Likewise.
* gcc.dg/pr96377-4.c: Likewise.
* gcc.dg/pr96377-5.c: Likewise.
* gcc.dg/pr96377-6.c: Likewise.
* gcc.target/aarch64/pr96377-1.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_3.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_4.c: Likewise.
* g++.target/aarch64/sve/acle/general-c++/gnu_vectors_3.C:
Likewise.
* g++.target/aarch64/sve/acle/general-c++/gnu_vectors_4.C:
Likewise.
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #11 from David Edelsohn --- r11-2447 fails. Testing r11-2446.
[Bug c/96407] New: LTO inlined functions don't inherit disabled warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407
Bug ID: 96407
Summary: LTO inlined functions don't inherit disabled warnings
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
This is a very reduced example from some real code where we are using -Werror
-Wstack-usage=5000.
We want most functions to have limited stack usage, but in some cases we have
carefully examined functions to ensure their stack usage isn't unbounded - but
it's hard to prove it - so we have disabled the warning for those functions.
--- test.c ---
#include
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstack-usage="
int
test (int i)
{
char str[i];
memset (str, 0, sizeof str);
return str[0]+i;
}
#pragma GCC diagnostic pop
--- main.c ---
#include
extern int test (int i);
int
main (int argc, char *argv[])
{
int j = test (argc);
printf ("%d\n", j);
return 0;
}
---
$ gcc -O2 -flto main.c test.c -Werror -Wstack-usage=5000 -o a.out
main.c: In function ‘main’:
main.c:6:1: error: stack usage might be unbounded [-Werror=stack-usage=]
6 | main (int argc, char *argv[])
| ^
lto1: all warnings being treated as errors
Note that if you combine these two functions into a single file, it
does *not* warn/error, even though presumably it can easily inline the
test() function. So LTO seems to be causing the difference.
[Bug tree-optimization/95433] Failure to completely optimize simple compare after operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433 --- Comment #5 from Marc Glisse --- Patch posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551154.html for the original testcase. Note that solving univariate polynomial equations *in the integers* (the rationals are not much harder) is actually rather simple, just enumerate the divisors of the constant term and evaluate the polynomial on each of them to check which ones are roots. If someone wants to implement that...
