[Bug c++/113834] internal compiler error: in tree_to_shwi, at tree.cc:6461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113834 --- Comment #1 from Ivan Lazaric --- Created attachment 57362 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57362=edit Preprocessed file generated by `-freport-bug`
[Bug c++/113834] New: internal compiler error: in tree_to_shwi, at tree.cc:6461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113834
Bug ID: 113834
Summary: internal compiler error: in tree_to_shwi, at
tree.cc:6461
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ivan.lazaric.gcc at gmail dot com
Target Milestone: ---
Version of g++ is 14.0.1, built of commit
3979171d8ea149912d99bdca6aeb3e7276842f02
Complete backtrace:
```
/home/ilazaric/installs/gcc-latest/include/c++/14.0.1/bits/utility.h:231:13:
internal compiler error: in tree_to_shwi, at tree.cc:6461
231 | { using type = __type_pack_element<_Np, _Types...>; };
| ^~~~
0x99d54d tree_to_shwi(tree_node const*)
../../gcc/gcc/tree.cc:6461
0x99d54d tree_to_shwi(tree_node const*)
../../gcc/gcc/tree.cc:6459
0xd07a45 finish_type_pack_element
../../gcc/gcc/cp/semantics.cc:4653
0xd07a45 finish_trait_type(cp_trait_kind, tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.cc:12783
0xcc8fc7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:16920
0xcbb9ae tsubst_decl
../../gcc/gcc/cp/pt.cc:15518
0xce3350 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.cc:12494
0xd37570 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.cc:138
0xd3769d complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.cc:151
0xcc9c76 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:16795
0xcbb9ae tsubst_decl
../../gcc/gcc/cp/pt.cc:15518
0xce3350 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.cc:12494
0xd37570 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.cc:138
0xd3769d complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.cc:151
0xcc9c76 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:16795
0xcbb9ae tsubst_decl
../../gcc/gcc/cp/pt.cc:15518
0xcad863 instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.cc:22089
0xcc9adb instantiate_alias_template
../../gcc/gcc/cp/pt.cc:22180
0xcc9adb tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:16180
0xcc8652 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:16226
```
Attached is the preprocessed file generated by `-freport-bug`
[Bug c++/113826] New: string_view::find sometimes not working in constexpr contexts under -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113826
Bug ID: 113826
Summary: string_view::find sometimes not working in constexpr
contexts under -fsanitize=undefined
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ivan.lazaric.gcc at gmail dot com
Target Milestone: ---
https://godbolt.org/z/qKvecx48W
```
#include
template struct fixed_string {
char buf[N + 1]{};
consteval fixed_string(char const *s) {
for (unsigned i = 0; i != N; ++i)
buf[i] = s[i];
buf[N] = 0;
}
consteval operator std::string_view() const {return {buf, N};}
};
template fixed_string(char const (&)[N]) -> fixed_string;
template struct storage {
inline static constexpr std::string_view sv{Str};
inline static constexpr bool hasA = sv.find('A') != std::string_view::npos;
};
int main(){
using NS = storage<"ABC">;
return NS::hasA;
}
```
Locally I am using g++ version 14.0.1
When building with flags `-std=c++20` it builds normally
When building with flags `-std=c++20 -fsanitize=undefined` it explodes
When building with clang with flags `-std=c++20 -fsanitize=undefined` it works
normally
Error message:
```
In file included from
/home/ilazaric/installs/gcc-latest/include/c++/14.0.1/string_view:898,
from ex.cpp:1:
/home/ilazaric/installs/gcc-latest/include/c++/14.0.1/bits/string_view.tcc: In
instantiation of ‘constexpr const bool storage{"ABC"}>::hasA’:
ex.cpp:21:16: required from here
21 | return NS::hasA;
|^~~~
ex.cpp:16:46: in ‘constexpr’ expansion of
‘storage{"ABC"}>::sv.std::basic_string_view::find(65, 0)’
/home/ilazaric/installs/gcc-latest/include/c++/14.0.1/bits/string_view.tcc:88:15:
error: ‘(((const char*)(& fixed_string<3>{"ABC"}.fixed_string<3>::buf)) != 0)’
is not a constant expression
88 | if (__p)
| ^~~
```
Might be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426
[Bug c++/113154] New: std::views::values not working with rvalue references to ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113154
Bug ID: 113154
Summary: std::views::values not working with rvalue references
to ranges
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ivan.lazaric.gcc at gmail dot com
Target Milestone: ---
https://godbolt.org/z/a3c4P9sY6
```
#include
#include
void fn(){
std::map m;
m | std::views::values; // works
std::map{} | std::views::values; // does not work
}
```
not an issue in newer versions, checked 13.2 and it worked
came across this by wanting to do:
```
std::map produce_map();
std::cout << std::ranges::max(produce_map | std::views::values) << std::endl;
```
options used: -std=c++20 -O3
[Bug preprocessor/109988] -iwithprefix doesn't add folder to end of search list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988 --- Comment #3 from Ivan Lazaric --- Note that clang has the same flags and behaves according to the documentation, might be some value in matching it. If it's considered too breaking of a change, I would recommend introducing a -iwithprefixafter flag that would add the directory to the end of the include search list.
[Bug c++/109988] -iwithprefix doesn't add folder to end of search list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988 --- Comment #1 from Ivan Lazaric --- In `gcc/c-family/c-opts.cc`: ``` case OPT_iwithprefix: add_prefixed_path (arg, INC_SYSTEM); break; ``` Should `INC_SYSTEM` actually be `INC_AFTER` ?
[Bug c++/109988] New: -iwithprefix doesn't add folder to end of search list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988 Bug ID: 109988 Summary: -iwithprefix doesn't add folder to end of search list Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ivan.lazaric.gcc at gmail dot com Target Milestone: --- ``` echo | g++ -iprefix "./" -iwithprefix "." -E -v - ``` Snippet of output: ``` #include <...> search starts here: ./. /usr/lib/gcc/x86_64-linux-gnu/11/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include End of search list. ``` Issue is that "./." is at the front of the list, should be at bottom. Snippet of `man g++`: ``` -iprefix prefix Specify prefix as the prefix for subsequent -iwithprefix options. If the prefix represents a directory, you should include the final /. -iwithprefix dir -iwithprefixbefore dir Append dir to the prefix specified previously with -iprefix, and add the resulting directory to the include search path. -iwithprefixbefore puts it in the same place -I would; -iwithprefix puts it where -idirafter would. ``` ^ implying `-iwithprefix` should behave like `-idirafter` `echo | g++ -idirafter "./." -E -v -`: ``` #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/11/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include ./. End of search list. ``` Related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34502
[Bug c++/109112] New: [missed optimization] odd behaviour with [[assume(...)]] and member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112
Bug ID: 109112
Summary: [missed optimization] odd behaviour with
[[assume(...)]] and member variables
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ivan.lazaric.gcc at gmail dot com
Target Milestone: ---
Everything is built with flags: -std=c++23 -O3
[[assume(...)]] doesn't seem to work quite as well when dealing with member
variables.
First version of `fn`:
void do_something();
void fn(bool x){
[[assume(!x)]];
if (x) do_something();
}
`fn` compiles into nothing:
fn(bool):
ret
Second version of `fn`, wrapping the `bool` argument in a simple struct:
struct S { bool x; };
void do_something();
void fn(S s){
[[assume(!s.x)]];
if (s.x) do_something();
}
This no longer compiles into just `ret`:
fn(S):
testdil, dil
jne .L5
ret
.L5:
jmp do_something()
Expected behaviour was for `fn(S)` to reduce to just `ret`
Godbolt link with the examples: https://godbolt.org/z/nreM4Y6dW
