[Bug c++/112633] [13/14 Regression] ICE with type aliases and depedent value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633 --- Comment #5 from Hana Dusíková --- Thanks for really quick fix! You are awesome!
[Bug c++/112633] New: ICE in parser GCC 13+ (including 14) around type aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
Bug ID: 112633
Summary: ICE in parser GCC 13+ (including 14) around type
aliases
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hanicka at hanicka dot net
Target Milestone: ---
Tested on GCC 14.0.0 20231119 (on Compiler-Explorer) and it's giving me ICE,
also on all 13.x versions (not 12.x)
```c++
template constexpr bool dependent_true = true;
template struct empty_type { }; // something like enable_if
template using empty_type_t = typename empty_type::type;
struct wrapper {
using type = void;
};
template using all = wrapper;
template
using constraints = typename all::type;
template >> = nullptr>
void calculate() { };
```
I don't even need to instantiate `calculate` function.
It gives me this error:
: In substitution of 'template using constraints
= typename all::type [with Conditions = {typename
empty_type >::type}]':
:16:66: required from here
16 | template >> =
nullptr>
| ^
:14:7: internal compiler error: Segmentation fault
14 | using constraints = typename all::type;
| ^~~
0x26a742e internal_error(char const*, ...)
???:0
0xd276f0 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd1b8f3 instantiate_template(tree_node*, tree_node*, int)
???:0
0xd285ea tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd35ed6 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0xd6996f finish_template_type(tree_node*, tree_node*, int)
???:0
0xcf6a49 c_parse_file()
???:0
0xe38e79 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380 Hana Dusíková changed: What|Removed |Added CC||hanicka at hanicka dot net --- Comment #3 from Hana Dusíková --- This would be really useful for many constexpr only libraries (like CTRE).
[Bug libstdc++/108517] New: std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Bug ID: 108517 Summary: std::sort of empty range yield "warning: 'this' pointer is null" Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hanicka at hanicka dot net Target Milestone: --- Bug in GCC 11.1-13 (including trunk) https://compiler-explorer.com/z/EEjeaKfv7 I couldn't minimize it further. Lowering optimization level will make the warning gone.
[Bug c++/102045] New: constructor is not being instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102045
Bug ID: 102045
Summary: constructor is not being instantiated
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hanicka at hanicka dot net
Target Milestone: ---
this error is in 11.0+ (including current trunk) and wasn't in gcc-10, the
compiler won't emit std::span::span symbol as it should
```
#include
struct byte_writer: std::span {
using std::span::span;
//byte_writer(auto && arg): std::span{arg} { }
constexpr void do_something() noexcept {
(void)this->empty();
}
};
int main() {
char array[1];
auto writer = byte_writer{array};
writer.do_something();
}
```
if you explicitly use the constructor (commented out) it will emit the symbol,
also the symbol is emitted if `using std::span::span;` is added to the
type.
https://compiler-explorer.com/z/q8z833eqd
[Bug c++/99637] bit_cast doesn't work with padding bits and it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637 --- Comment #2 from Hana Dusíková --- I know this is not an argument but MSVC accepts this code, meanwhile I'm asking Richard what to do about it.
[Bug c++/99637] New: bit_cast doesn't work with padding bits and it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637
Bug ID: 99637
Summary: bit_cast doesn't work with padding bits and it should
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hanicka at hanicka dot net
Target Milestone: ---
Standard states in https://eel.is/c++draft/bit.cast#2 "Padding bits of the
result are unspecified."
Current trunk GCC (11.0.1 20210316) gives error in presence of padding bits:
https://compiler-explorer.com/z/MhKMb5
```
struct my_field
{
// change size to 64 and it will work
unsigned long long a : 63;
};
constexpr unsigned long long get_value(const auto & val) noexcept {
static_assert(sizeof(val) == sizeof(unsigned long long));
return __builtin_bit_cast(unsigned long long, val);
}
constexpr auto f = my_field{0};
constexpr auto v = get_value(f);
```
this is the error message GCC gives, but this shouldn't be a hard error
```
:14:29: in 'constexpr' expansion of 'get_value(f)'
:10:31: error: '__builtin_bit_cast' accessing uninitialized byte at
offset 7
10 | return __builtin_bit_cast(unsigned long long, val);
```
[Bug c++/99013] New: std::source_location::function_name should return same result in constexpr mode and non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99013
Bug ID: 99013
Summary: std::source_location::function_name should return same
result in constexpr mode and non-constexpr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hanicka at hanicka dot net
Target Milestone: ---
Hi found out std::source_location is returning different result in constexpr:
```
#include
template
constexpr std::string_view get_object_name1()
{
/*constexpr*/ const char * ptr =
std::source_location::current().function_name();
return ptr;
}
template
constexpr std::string_view get_object_name2()
{
constexpr const char * ptr =
std::source_location::current().function_name();
return ptr;
}
void foo() { }
```
when called `get_object_name1` it returns `constexpr std::string_view
get_object_name1() [with auto Object = foo; std::string_view =
std::basic_string_view]`
but when called `get_object_name2` it returns `constexpr std::string_view
get_object_name2()`
the difference is the BUG (missing `[with auto Object = foo; std::string_view =
std::basic_string_view]`)
error with latest trunk on compiler-explorer.com
https://compiler-explorer.com/z/4e8Gd1
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 --- Comment #1 from Hana Dusíková --- I found out that build done on Catalina generates correct binary, which is able to run on Big Sur without any problem.
[Bug c++/98805] New: exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805
Bug ID: 98805
Summary: exception abort on mac os 11 (big sur)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hanicka at hanicka dot net
Target Milestone: ---
Any C++ code I try to compile with GCC 10.2.0 (homebrew package AND build from
source) aborts when exception is thrown even when the exception should caught.
This minimal example aborts:
```
struct exception { };
int main() {
try {
throw exception{};
} catch (exception) {
} catch (...) {
}
}
```
(Build with g++ exception.cpp && ./a.out)
My GCC build is:
```
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-10.2/bin/g++-10.2
COLLECT_LTO_WRAPPER=/usr/local/gcc-10.2/libexec/gcc/x86_64-apple-darwin20.2.0/10.2.0/lto-wrapper
Target: x86_64-apple-darwin20.2.0
Configured with: ../gcc-10.2.0/configure --prefix=/usr/local/gcc-10.2
--enable-checking=release --enable-languages=c,c++ --disable-multilib
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
--program-suffix=-10.2
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
```
Backtrace of the binary when crashes is:
```
* frame #0: 0x7fff20347462 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff20375610 libsystem_pthread.dylib`pthread_kill + 263
frame #2: 0x7fff202c8720 libsystem_c.dylib`abort + 120
frame #3: 0x00010048b00a libgcc_s.1.dylib`uw_init_context_1.cold + 5
frame #4: 0x000100488475
libgcc_s.1.dylib`_Unwind_RaiseException(exc=0x000100505760) at
unwind.inc:93:3
frame #5: 0x0001001382f7 libstdc++.6.dylib`__cxa_throw + 55
frame #6: 0x00013f13 a.out`main at exception.cpp:5:19
frame #7: 0x7fff20390621 libdyld.dylib`start + 1
```
[Bug c++/96742] [10/11 Regression] "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96742 Hana Dusíková changed: What|Removed |Added CC||hanicka at hanicka dot net --- Comment #7 from Hana Dusíková --- (In reply to Jonathan Wakely from comment #4) > (In reply to William Throwe from comment #2) > > This warns if passed an array of length 0 because the for-loop condition is > > always false. Any change I can make to fix it seems to make the code worse. > > I could replace "i < N" with "i + 1 < N + 1", but that certainly doesn't > > make the code clearer (and in similar cases could lead to weird overflow > > bugs). I can't partially specialize the function, because that's not > > allowed. I could write an implementation struct and specialize that, but > > that seems like massive overkill when the generic function works fine. > > You can use N != 0 && i < N which doesn't have the overflow problem, but I > agree it doesn't make the code clearer, and should not be necessary. This is what I had in CTRE but it's also triggering same warning: https://compiler-explorer.com/z/fjY7sG
