[Bug middle-end/114289] Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
--- Comment #3 from Dan Stahlke ---
Variants that generate more reasonable results:
struct foo {
int x:32;
} __attribute__((packed));
struct foo {
int x:16;
} __attribute__((packed));
struct foo {
int x:31;
};
struct foo {
int x:31;
} __attribute__((packed, aligned(4)));
[Bug tree-optimization/114289] Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
Dan Stahlke changed:
What|Removed |Added
Target|x86_64-linux-gnu|
Keywords|missed-optimization |
Component|middle-end |tree-optimization
--- Comment #1 from Dan Stahlke ---
Variants that generate more reasonable results:
struct foo {
int x:32;
} __attribute__((packed));
struct foo {
int x:16;
} __attribute__((packed));
struct foo {
int x:31;
};
struct foo {
int x:31;
} __attribute__((packed, aligned(4)));
[Bug tree-optimization/114289] New: Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
Bug ID: 114289
Summary: Non-optimal assembly for accessing bit-fields in
packed structs
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dan at stahlke dot org
Target Milestone: ---
// gcc -O3 -g -Wall -march=haswell -mavx2
// https://godbolt.org/z/Yfb9dnYx4
struct foo {
int x:31;
} __attribute__((packed));
int fx(struct foo const *o) { return o->x; }
Disassembly:
movzx eax, BYTE PTR [rdi+1]
movzx edx, BYTE PTR [rdi]
sal rax, 8
or rax, rdx
movzx edx, BYTE PTR [rdi+2]
sal rdx, 16
or rdx, rax
movzx eax, BYTE PTR [rdi+3]
and eax, 127
sal rax, 24
or rax, rdx
sal rax, 33
sar rax, 33
ret
Compare to clang:
mov eax, dword ptr [rdi]
add eax, eax
sar eax
ret
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #25 from Dan Stahlke --- The test case I just posted appears in the bug 105651 discussion. So maybe or maybe not related to the present discussion.
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
Dan Stahlke changed:
What|Removed |Added
CC||dan at stahlke dot org
--- Comment #24 from Dan Stahlke ---
Here is another test case, broken on 12.2 with "-std=c++20 -Wrestrict -O3" but
working on trunk and working on 12.2 with -O2 rather than -O3.
#include
#include // std::ignore
int main()
{
std::string s = "b";
std::ignore = "a" + std::move(s);
}
[Bug c++/106893] New: auto deduces wrong type for function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106893
Bug ID: 106893
Summary: auto deduces wrong type for function pointer
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dan at stahlke dot org
Target Milestone: ---
This works in 11.3.0 but not in 12.2.0.
struct IntegerCoordinate {
int x() const;
int y() const;
};
template
struct CoordTraits
{
static auto GetX(T const ) { return p.x(); }
static auto GetY(T const ) { return p.y(); }
using Ordinate = decltype(GetX(T{}));
};
template
struct Node {
static constexpr auto GetX = Traits::GetX; // works because of the `using
Ordinate = ...`
static constexpr auto GetY = Traits::GetY; // compilation error
// This compiles
//static constexpr auto GetX = ::GetX;
//static constexpr auto GetY = ::GetY;
// This compiles
//using fptr = int(*)(IntegerCoordinate const &);
//static constexpr fptr GetX = Traits::GetX;
//static constexpr fptr GetY = Traits::GetY;
// Not needed for minimal test case
auto x(auto const ) const { return GetX(p); }
auto y(auto const ) const { return GetY(p); }
};
int main() {
Node> node;
// Not needed for minimal test case
node.x(IntegerCoordinate{});
node.y(IntegerCoordinate{});
}
$ g++ -std=c++20 gcc-function-ptr-bug.cpp -c -o gcc-function-ptr-bug.o
gcc-function-ptr-bug.cpp: In instantiation of ‘constexpr auto (* const
Node >::GetY)(const IntegerCoordinate&)’:
gcc-function-ptr-bug.cpp:17:27: required from ‘struct
Node >’
gcc-function-ptr-bug.cpp:32:42: required from here
gcc-function-ptr-bug.cpp:17:27: error: invalid conversion from ‘int (*)(const
IntegerCoordinate&)’ to ‘auto (*)(const IntegerCoordinate&)’ [-fpermissive]
17 | static constexpr auto GetY = Traits::GetY; // compilation error
| ^~~~
| |
| int (*)(const IntegerCoordinate&)
gcc-function-ptr-bug.cpp: In instantiation of ‘auto Node::y(const
auto:2&) const [with auto:2 = IntegerCoordinate; Traits =
CoordTraits]’:
gcc-function-ptr-bug.cpp:35:11: required from here
gcc-function-ptr-bug.cpp:28:46: error: use of
‘Node >::GetY’ before deduction of ‘auto’
28 | auto y(auto const ) const { return GetY(p); }
| ^~~
[Bug c++/102970] New: stable_sort uninitialized value with -funroll-loops -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102970 Bug ID: 102970 Summary: stable_sort uninitialized value with -funroll-loops -fno-tree-vectorize Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dan at stahlke dot org Target Milestone: --- Created attachment 51682 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51682=edit demonstration source code The attached file, compiled with 11.2.0, using the command line in the comment, causes std::stable_sort to access uninitialized memory. In fact, it already goes wrong by the time it passes the inputs to the first comparison operation. The problem goes away if the copy constructor of the box struct is defaulted (see the "#if"). It only happens with "-funroll-loops -fno-tree-vectorize". Here is a Godbolt: https://godbolt.org/z/6PsdPj6q3
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 --- Comment #28 from Dan Stahlke --- Thank you. That makes sense. I had asked about it here: https://stackoverflow.com/questions/59690019 I was directed to this thread, and linked back to the SO thread you provided.
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 Dan Stahlke changed: What|Removed |Added CC||dan at stahlke dot org --- Comment #22 from Dan Stahlke --- Any reason why __is_bitwise_relocatable = is_trivial, instead of is_trivially_copyable? cppreference tells me the difference between these two is that the first needs a trivial default constructor. But is the default constructor relevant here? I could see the DEstructor being relevant.
[Bug c++/90998] [9/10 Regression] ICE (segfalut) in gcc/cp/call.c compare_ics() with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90998
Dan Stahlke changed:
What|Removed |Added
CC||dan at stahlke dot org
--- Comment #3 from Dan Stahlke ---
Me too, with gcc 9.2.0.
g++ -std=c++17 -Wconversion gcc-Wconversion-crash.cpp
--
struct B;
struct A {
operator B();
};
struct B {
B(A const );
B(B const );
};
B f(A x) {
return B(x);
}
--
gcc-Wconversion-crash.cpp: In function ‘B f(A)’:
gcc-Wconversion-crash.cpp:15:15: internal compiler error: Segmentation fault
15 | return B(x);
| ^
0xb8d10f crash_signal
../.././gcc/toplev.c:326
0x5ff192 compare_ics
../.././gcc/cp/call.c:10124
0x603090 joust
../.././gcc/cp/call.c:10737
0x603a2c tourney
../.././gcc/cp/call.c:11096
0x60b5f6 build_new_method_call_1
../.././gcc/cp/call.c:9805
0x60b5f6 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../.././gcc/cp/call.c:9973
0x600773 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../.././gcc/cp/call.c:9397
0x60ca93 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../.././gcc/cp/call.c:11314
0x746ab9 build_static_cast_1
../.././gcc/cp/typeck.c:7211
0x749807 cp_build_c_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck.c:8007
0x749807 cp_build_c_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck.c:7924
0x751c2a build_functional_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck2.c:2284
0x6b3b16 cp_parser_functional_cast
../.././gcc/cp/parser.c:28385
0x6c4864 cp_parser_postfix_expression
../.././gcc/cp/parser.c:7101
0x6d1409 cp_parser_unary_expression
../.././gcc/cp/parser.c:8472
0x6af31f cp_parser_cast_expression
../.././gcc/cp/parser.c:9357
0x6afb0a cp_parser_binary_expression
../.././gcc/cp/parser.c:9460
0x6b08a7 cp_parser_assignment_expression
../.././gcc/cp/parser.c:9758
0x6b0bca cp_parser_expression
../.././gcc/cp/parser.c:9925
0x6bef8a cp_parser_jump_statement
../.././gcc/cp/parser.c:12910
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
--
g++ -v
Reading specs from
/xxx/gcc/9.2.0/.bin/../lib64/gcc/x86_64-suse-linux/9.2.0/specs
COLLECT_GCC=/xxx/gcc/9.2.0/.bin/g++
COLLECT_LTO_WRAPPER=/xxx/gcc/9.2.0/.bin/../libexec/gcc/x86_64-suse-linux/9.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ./configure --prefix=/xxx/gcc/9.2.0
--libdir=/xxx/gcc/9.2.0/lib64 --libexecdir=/xxx/gcc/9.2.0/libexec
--bindir=/xxx/gcc/9.2.0/bin --with-isl=/xxx/gcc/9.2.0
--with-libelf=/xxx/gcc/9.2.0 --with-mpfr=/xxx/gcc/9.2.0
--with-gmp=/xxx/gcc/9.2.0 --with-mpc=/xxx/gcc/9.2.0 --enable-gold=yes
--enable-lto --enable-languages=c,c++,objc,fortran --build=x86_64-suse-linux
--host=x86_64-suse-linux --target=x86_64-suse-linux --enable-libotm
--disable-libstdcxx-pch
Thread model: posix
gcc version 9.2.0 (GCC)
[Bug libstdc++/89763] New: Making iterator's operator== breaks existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89763
Bug ID: 89763
Summary: Making iterator's operator== breaks existing code
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dan at stahlke dot org
Target Milestone: ---
gcc 9 has made operator== and operator!= free functions for std::map (and
probably other) iterators. Probably this is considered an implementation
detail and not a violation of the standard, but I thought I'd bring it to your
attention that this breaks CINT.
CINT does things like this:
./src/gcc3strm.cxx:
G__letint(result7,103,(long)((fpos*)(G__getstructoffset()))->operator==(*(fpos*)libp->para[0].ref));
./src/Apiifold.cxx:
G__letint(result7,105,(long)((G__ClassInfo*)(G__getstructoffset()))->operator==(*(G__ClassInfo*)libp->para[0].ref));
./src/Apiifold.cxx:
G__letint(result7,105,(long)((G__TypeInfo*)(G__getstructoffset()))->operator==(*(G__TypeInfo*)libp->para[0].ref));
./src/Apiif.cxx:
G__letint(result7,105,(long)((G__ClassInfo*)(G__getstructoffset()))->operator==(*(G__ClassInfo*)libp->para[0].ref));
./src/Apiif.cxx:
G__letint(result7,105,(long)((G__TypeInfo*)(G__getstructoffset()))->operator==(*(G__TypeInfo*)libp->para[0].ref));
Given that CINT is no longer supported, CERN is not likely to release any
patches for this.
Here is a standalone demonstration of the issue:
#include
bool f()
{
std::map m;
auto it = m.begin();
return it.operator==(it);
}
[Bug lto/89762] New: Mixing optimization levels with ostream gives lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:2098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89762
Bug ID: 89762
Summary: Mixing optimization levels with ostream gives lto1:
internal compiler error: in get_odr_type, at
ipa-devirt.c:2098
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dan at stahlke dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
=== A.cpp
#include
std::ostream *a;
int main() { }
=== B.cpp
#include
std::ostream *b;
=== script (note different optimization levels)
rm -f A.o B.o AB
$CXX -flto -Wall -O1 -c A.cpp -o A.o
$CXX -flto -Wall -O2 -c B.cpp -o B.o
$CXX -flto A.o B.o -o AB
=== result
lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:2098
0x5d4a06 get_odr_type(tree_node*, bool)
../../gcc-8.3.0/gcc/ipa-devirt.c:2098
0x8398a3 register_odr_type(tree_node*)
../../gcc-8.3.0/gcc/ipa-devirt.c:2123
0x626a86 lto_read_decls
../../gcc-8.3.0/gcc/lto/lto.c:1887
0x627788 lto_file_finalize
../../gcc-8.3.0/gcc/lto/lto.c:2121
0x627788 lto_create_files_from_ids
../../gcc-8.3.0/gcc/lto/lto.c:2131
0x627788 lto_file_read
../../gcc-8.3.0/gcc/lto/lto.c:2172
0x627788 read_cgraph_and_symbols
../../gcc-8.3.0/gcc/lto/lto.c:2845
0x627788 lto_main()
../../gcc-8.3.0/gcc/lto/lto.c:3362
=== build info
Broken in 8.3:
Using built-in specs.
COLLECT_GCC=XXX/gcc-8.3.0/install/bin/g++
COLLECT_LTO_WRAPPER=XXX/gcc-8.3.0/install/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.3.0/configure
--prefix=/nfs/orto/proj/tapeout/cit_dev10/mkgumbel/gcc-8.3.0/install
--enable-compressed-debug-sections=all
Thread model: posix
gcc version 8.3.0 (GCC)
Works in 9-20190310:
Using built-in specs.
COLLECT_GCC=XXX/gcc-9/install/bin/g++
COLLECT_LTO_WRAPPER=XXX/gcc-9/install/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9-20190310/configure
--prefix=/nfs/orto/proj/tapeout/cit_dev10/mkgumbel/gcc-9/install
--enable-compressed-debug-sections=all --enable-gold --disable-werror
--disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190310 (experimental) (GCC)
[Bug libstdc++/89629] New: std::hash segfault for long strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89629
Bug ID: 89629
Summary: std::hash segfault for long strings
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dan at stahlke dot org
Target Milestone: ---
_Hash_bytes crashes when len is 2^31 or greater. The length is converted to
int at hash_bytes.cc line 142, resulting in a negative number if the length
doesn't fit in an int variable. Then end < buf resulting in an infinite loop
that eventually runs into inaccessible memory.
#include
#include
#include
int main() {
size_t big = size_t(1) << 31;
std::cout << "line " << __LINE__ << std::endl;
// this succeeds
std::hash{}(std::string(big - 1, 'a'));
std::cout << "line " << __LINE__ << std::endl;
// segfault at libstdc++-v3/libsupc++/hash_bytes.cc:147
std::hash{}(std::string(big, 'a'));
std::cout << "line " << __LINE__ << std::endl;
}
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038 Dan Stahlke dan at stahlke dot org changed: What|Removed |Added CC||dan at stahlke dot org --- Comment #9 from Dan Stahlke dan at stahlke dot org --- It seems the same problem affects sleep_for, with negative values of magnitude at least one second: std::this_thread::sleep_for(std::chrono::seconds(-1)); Tested with Fedora's libstdc++ 4.8.3.
