[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

2021-11-10 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103162

--- Comment #13 from Florin Iucha  ---
(In reply to Jonathan Wakely from comment #11)
> I'm going to get the standard clarified instead (and then cppreference will
> probably follow suit).

That will be great!

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

2021-11-10 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103162

--- Comment #12 from Florin Iucha  ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Florin Iucha from comment #2)
> > It indicates that it reports errors via exceptions.
> 
> Yes, but that doesn't mean 0 is a valid return value. The non-nothrow forms
> of operator new also use exceptions to report errors, but that doesn't mean
> that they can return 0 as a valid pointer. pmr::memory_resource is intended
> to work the same way: either return a valid pointer to dereferencable
> memory, or throw an exception. There is no third alternative, of returning
> an invalid or null pointer value.

Well, bitten by a co-variant of Hyrum's law - the documentation doesn't
explicitly say "0 is not a valid return", and I was relying on the
documentation and my reading of the spec, without having access to the mental
model of the authors. Thank you again for acting as a conduit and clarifying
the design intent.

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

2021-11-10 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103162

--- Comment #10 from Florin Iucha  ---
(In reply to Jonathan Wakely from comment #8)
> > There are uses for the memory_resources pattern, outside of its current
> > application in the standard library - for example allocating ranges in a
> > file, or in a shared memory segment. 0 is valid allocation, although
> > obviously not directly dereferenceable.
> 
> Well then it's not a valid use of pmr::memory_resource. It needs to return a
> pointer to dereferenceable memory (after casting it from void* to something
> else of course).
>
... 
>
> If you're abusing the pmr::memory_resource interface to return a uintptr_t
> disguised a a void*, well that's abusing the API and not intended to be
> supported (according to the author of the proposal that added it to C++).

Thank you for taking the time to consider this - I will create the "abstract
integer range" allocator and use that for the other use cases.

It might be good though to update the documentation - perhaps even on
cppreference if you have access - to explicitly indicate these constraints as
following from the design intent.

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

2021-11-10 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103162

--- Comment #7 from Florin Iucha  ---
That is most unfortunate because it will force us to duplicate the library used
for resource management. Not only that, but if I were to implement the
pmr::memory_resource interface in terms of the other library which returns
uintptr_t/size_t (including the occasional 0), I would have to pay an
additional virtual method call just to wrap a static_cast / bit_cast.

There are uses for the memory_resources pattern, outside of its current
application in the standard library - for example allocating ranges in a file,
or in a shared memory segment. 0 is valid allocation, although obviously not
directly dereferenceable.

Also -fno-delete-null-pointer-checks is not helping me (I mistakenly thought it
silenced the sanitizer) because I am not directly dereferencing the result.
However the error I am getting is when I run the undefined behavior sanitizer
and it notices that the values returned from allocate() (retrieved from my
do_allocate) or passed back to deallocate() violate the attributes.

So I am left with three unsavory choices:
   1. patch the standard library to remove the checks;
   2. do not run undefined behavior sanitizer, or figure out some way to
distribute suppression files with the binaries;
   3. internally fork the libraries, with one flavor to be used with real
memory and real objects, the other with abstract "address ranges", and delegate
one implementation to the other, paying an extra virtual method call.

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

2021-11-09 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103162

Florin Iucha  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Florin Iucha  ---
Thank you Jonathan - adding the flag silences the sanitizer output, so I'll use
it henceforth.

-

20.12.2.3 says nothing about not null, and it is the section about
std::pmr::memory_resource members. It indicates that it reports errors via
exceptions. It is still not clear to me which of the paragraphs in 6.7.5.5.2
truly apply here, but I can see how the reference from 20.12.2.3 could be
interpreted as implemented.

Are memory_resource members "allocation functions" or are the next layer up
(std::pmr::polymorphic_allocator) the "allocation functions" ?

[Bug libstdc++/103162] New: overconstrained std::pmr::memory_resource allocate/deallocate methods

2021-11-09 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103162

Bug ID: 103162
   Summary: overconstrained std::pmr::memory_resource
allocate/deallocate methods
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florin.iucha at amd dot com
  Target Milestone: ---

std::pmr::memory_resource::allocate() is annotated with
__attribute__((__returns_nonnull__)) and
std::pmr::memory_resource::deallocate() is annotated with
__attribute__((__nonnull__)) .

Looking at https://en.cppreference.com/w/cpp/memory/memory_resource/allocate it
is not clear why the annotation is required.

I have implemented several specialized memory resources, which sometimes can be
used to manage pools in CPU space, sometimes from pools in other memory spaces,
where allocating from 0 is perfectly acceptable.

Checking https://eel.is/c++draft/mem.res.class, there's no mention of "null" in
the context of allocate/deallocate .

This attribute can be helpful to catch bugs in specialized memory resources in
general, but specifically in my case it is tripping the address sanitizer when
I'm returning null.

[Bug libstdc++/102077] null-pointer dereference in std::thread::detach()

2021-08-26 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102077

Florin Iucha  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Florin Iucha  ---
Sorry for the noise, I shall move this to GDB bugzilla.

[Bug libstdc++/102077] New: null-pointer dereference in std::thread::detach()

2021-08-26 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102077

Bug ID: 102077
   Summary: null-pointer dereference in std::thread::detach()
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florin.iucha at amd dot com
  Target Milestone: ---

Building static GDB using crosstool-ng
(https://github.com/cpackham/crosstool-ng/tree/glibc-2.34) using: glibc 2.34,
binutils 2.37, GCC from 11 branch (2e90914b79dd1c591c8a4d663ae2319fbb15df2c),
gdb 10.2 (statically linked) I get crash on startup:


fldiag114 ~/x-tools/x86_64-tng-linux-gnu$ gdb
./x86_64-tng-linux-gnu/debug-root/usr/bin/gdb
GNU gdb (Ubuntu 10.2-0ubuntu1~18.04~2) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Traceback (most recent call last):
  File "", line 3, in 
ModuleNotFoundError: No module named 'libstdcxx'
/home/fiucha/.gdbinit:7: Error in sourced command file:
Error while executing Python code.
Reading symbols from ./x86_64-tng-linux-gnu/debug-root/usr/bin/gdb...
(gdb) run
Starting program:
/home/fiucha/x-tools/x86_64-tng-linux-gnu/x86_64-tng-linux-gnu/debug-root/usr/bin/gdb
[Detaching after vfork from child process 35124]
[New LWP 35125]

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x00ac96c9 in std::thread::detach() ()
#2  0x00a4424b in gdb::thread_pool::set_thread_count(unsigned long) ()
#3  0x0070be47 in update_thread_pool_size() ()
#4  0x0070cb5e in _initialize_maint_cmds() ()
#5  0x008fad52 in initialize_all_files() ()
#6  0x00899f0b in gdb_init(char*) ()
#7  0x00703cb4 in captured_main_1(captured_main_args*) ()
#8  0x00704913 in captured_main(void*) ()
#9  0x0070497e in gdb_main(captured_main_args*) ()
#10 0x004022de in main ()
(gdb)

This is running on x86-64, built for x86-64. Os is Ubuntu 18.04 .

[Bug sanitizer/100439] stack overflow running ubsan

2021-07-06 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #14 from Florin Iucha  ---
Bisecting the configure flags, I think I narrowed it down to: it fails when
"--enable-gnu-indirect-function" is present.

[Bug sanitizer/100439] stack overflow running ubsan

2021-07-06 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #13 from Florin Iucha  ---
With GCC 11-20210703 snapshot I can reproduce the observation on Ubuntu 20.04
but can not reproduce the observation on Debian testing.

[Bug sanitizer/100439] stack overflow running ubsan

2021-07-02 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #12 from Florin Iucha  ---
Actually, it gets even better - no clang needed. Just build GCC 11-20210626
Snapshot and build the example using the Google test recipe:

#
# Makefile
#
ALL: bin/test_hello

.PHONY: clean

CXX=/opt/gcc11-for-tng/bin/g++-11

CXXFLAGS=-m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer

LDFLAGS=-L/opt/gcc11-for-tng/lib64 -Wl,-rpath,/opt/gcc11-for-tng/lib64
-fsanitize=undefined

GOOGLE_TEST_PATH=googletest/googletest
GOOGLE_TEST_OBJECTS=obj/gtest.o obj/gtest_main.o obj/gtest-port.o
obj/gtest-filepath.o obj/gtest-death-test.o obj/gtest-test-part.o
obj/gtest-printers.o

obj/test_hello.o: test_hello.cpp
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include -c $<

obj/gtest.o: $(GOOGLE_TEST_PATH)/src/gtest.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<

obj/gtest%.o: $(GOOGLE_TEST_PATH)/src/gtest%.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<

bin/test_hello: obj/test_hello.o $(GOOGLE_TEST_OBJECTS)
$(CXX) -o $@ $(LDFLAGS) $^ -lpthread

clean:
$(RM) bin/test_hello obj/*.o


#
# test_hello.cpp
#
#include 

#include 

TEST(Hello, World)
{
ASSERT_EQ(43, std::stoi("42"));
}

--

After build:

$ ldd bin/test_hello
linux-vdso.so.1 (0x7ffc551ee000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f387908d000)
libstdc++.so.6 => /opt/gcc11-for-tng/lib64/libstdc++.so.6
(0x7f3878ce4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3878b95000)
libubsan.so.1 => /opt/gcc11-for-tng/lib64/libubsan.so.1
(0x7f387803c000)
libgcc_s.so.1 => /opt/gcc11-for-tng/lib64/libgcc_s.so.1
(0x7f3877e29000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3877c37000)
/lib64/ld-linux-x86-64.so.2 (0x7f387933a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3877c2f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f3877c24000)

$ gdb bin/test_hello
...
...
Program received signal SIGSEGV, Segmentation fault.
0x76f4f555 in HandleDynamicTypeCacheMiss (Data=0x557a49a0,
Pointer=140737353637960, Hash=3327454538508686025, Opts=...)
at ../../../../gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cpp:36
36  ../../../../gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cpp: No such file
or directory.
...
(gdb) bt
#44921 0x76f50516 in __ubsan::checkDynamicType
(Object=Object@entry=0x77f87588 >,
Type=0x77f860b8 , Hash=8146310091054124745) at
../../../../gcc/libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:233
#44922 0x76f4f55a in HandleDynamicTypeCacheMiss (Data=0x557a49a0,
Pointer=140737353643400, Hash=, Opts=...) at
../../../../gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cpp:36
#44923 0x76f4fa92 in __ubsan::__ubsan_handle_dynamic_type_cache_miss
(Data=, Pointer=, Hash=) at
../../../../gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cpp:87
#44924 0x5567addd in std::type_info::operator== (this=0x77f87588
>, __arg=...) at
/opt/gcc11-for-tng/include/c++/11.1.1/typeinfo:122
#44925 0x77c9beec in __cxxabiv1::__vmi_class_type_info::__do_dyncast
(this=0x77f87588 >, src2dst=0,
access_path=__cxxabiv1::__class_type_info::__contained_public,
dst_type=0x77f87588 >, obj_ptr=0x77f93e00
<(anonymous namespace)::ctype_c>, src_type=0x77f86298 , src_ptr=0x77f93e00 <(anonymous namespace)::ctype_c>,
result=...) at ../../../../gcc/libstdc++-v3/libsupc++/vmi_class_type_info.cc:91
#44926 0x77c999e9 in __cxxabiv1::__dynamic_cast (src_ptr=0x77f93e00
<(anonymous namespace)::ctype_c>, src_type=0x77f86298 , dst_type=0x77f87588 >,
src2dst=0) at ../../../../gcc/libstdc++-v3/libsupc++/dyncast.cc:74
#44927 0x77cdfd6d in std::has_facet > (__loc=...) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/bits/locale_classes.tcc:110
#44928 0x77cd6fcf in std::basic_ios
>::_M_cache_locale (this=this@entry=0x557cc988 ,
__loc=...) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:159
#44929 0x77cd7263 in std::basic_ios
>::init (this=this@entry=0x557cc988 ,
__sb=__sb@entry=0x77f92460 <__gnu_internal::buf_cout_sync>) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:132
#44930 0x77ce72db in std::basic_ostream
>::basic_ostream (__sb=, __vtt_parm=0x0, __in_chrg=1,
this=0x557cc980 ) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/ostream:85
#44931 std::basic_ostream >::basic_ostream
(this=0x557cc980 , __sb=0x77f92460
<__gnu_internal::buf_cout_sync>) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/ostream:85
#44932 0x77ca39c3 in std::ios_base::Init::Init (this=)
at /home/fiucha/tools/gcc/libstdc++-v3/libsupc++/new:175
#44933 

[Bug sanitizer/100439] stack overflow running ubsan

2021-07-02 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #11 from Florin Iucha  ---
Updated Makefile for clang12:

#---

ALL: bin/test_hello

.PHONY: clean

CXX=/opt/clang12-for-tng/bin/clang++

CXXFLAGS=-m64 -g -std=c++20 --gcc-toolchain=/opt/gcc11-for-tng
-fsanitize=undefined -fno-omit-frame-pointer

LDFLAGS=-L/opt/gcc11-for-tng/lib64 -Wl,-rpath,/opt/gcc11-for-tng/lib64
-fsanitize=undefined

GOOGLE_TEST_PATH=googletest/googletest
GOOGLE_TEST_OBJECTS=obj/gtest.o obj/gtest_main.o obj/gtest-port.o
obj/gtest-filepath.o obj/gtest-death-test.o obj/gtest-test-part.o
obj/gtest-printers.o

obj/test_hello.o: test_hello.cpp
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include -c $<

obj/gtest.o: $(GOOGLE_TEST_PATH)/src/gtest.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<

obj/gtest%.o: $(GOOGLE_TEST_PATH)/src/gtest%.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<

bin/test_hello: obj/test_hello.o $(GOOGLE_TEST_OBJECTS)
$(CXX) -o $@ $(LDFLAGS) $^ -lpthread

clean:
$(RM) bin/test_hello obj/*.o


# -

The content of the test file:

#include 

#include 

TEST(Hello, World)
{
ASSERT_EQ(43, std::stoi("42"));
}

[Bug sanitizer/100439] stack overflow running ubsan

2021-07-02 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #10 from Florin Iucha  ---
I am able to reproduce something similar by building GCC11 from snapshot
11-20210626 (96358cbbe6e6447519a155301b6acb1624c0) and then using Clang12
(12.0.1-rc4) ubsan:

#234 0x7f9769d39670 in __cxxabiv1::__si_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__[0/48169]
e_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result&) const /home/fiuch
a/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsupc++/si_class_type_info.cc:52:13
#235 0x7f9769d379e8 in __dynamic_cast
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsu
pc++/dyncast.cc:74:28
#236 0x5dd0b6 in __ubsan::checkDynamicType(void*, void*, unsigned long)
/home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_type_hash_itaniu
m.cpp:233:5
#237 0x5dbf11 in
HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long,
unsigned long, __ubsan::ReportOptions)
/home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:36:7
 
#238 0x5dbee9 in __ubsan_handle_dynamic_type_cache_miss
/home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:87:3
#239 0x60b931 in std::type_info::operator==(std::type_info const&) const
/opt/gcc11-for-tng/lib/gcc/x86_64-linux-gnu/11.1.1/../../../../include/c++/11.1.1/typeinfo:122:16
   
 #240 0x7f9769d39670 in
__cxxabiv1::__si_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info
const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result&) const
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsupc++/si_class_type_info.cc:52:13
#241 0x7f9769d379e8 in __dynamic_cast
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsu
pc++/dyncast.cc:74:28
#242 0x5dd0b6 in __ubsan::checkDynamicType(void*, void*, unsigned long)
/home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_type_hash_itaniu
m.cpp:233:5
#243 0x5dbf11 in
HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long,
unsigned long, __ubsan::ReportOptions) /home/fi
ucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:36:7
#244 0x5dbee9 in __ubsan_handle_dynamic_type_cache_miss
/home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:87:3
#245 0x60b931 in std::type_info::operator==(std::type_info const&) const
/opt/gcc11-for-tng/lib/gcc/x86_64-linux-gnu/11.1.1/../../../../includ
e/c++/11.1.1/typeinfo:122:16
#246 0x7f9769d39670 in __cxxabiv1::__si_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_typ
e_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result&) const /home/fiuch
a/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsupc++/si_class_type_info.cc:52:13
#247 0x7f9769d379e8 in __dynamic_cast
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsu
pc++/dyncast.cc:74:28
#248 0x5dd0b6 in __ubsan::checkDynamicType(void*, void*, unsigned long)
/home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_type_hash_itaniu
m.cpp:233:5
#249 0x5dbf11 in
HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long,
unsigned long, __ubsan::ReportOptions) /home/fi
ucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:36:7

SUMMARY: AddressSanitizer: stack-overflow
/home/fiucha/tools/llvm12/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:278
in __sanitize
r::IsAccessibleMemoryRange(unsigned long, unsigned long)
==2162813==ABORTING


This doesn't fail on a simple hello_ub.cpp example - but on a complex module
using Google test, again.

[Bug sanitizer/100439] stack overflow running ubsan

2021-05-14 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #9 from Florin Iucha  ---
I was not able to reproduce the observation using the native compiler and
system glibc.

[Bug sanitizer/100439] stack overflow running ubsan

2021-05-13 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #7 from Florin Iucha  ---
Created attachment 50809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50809=edit
crosstool-ng configuration file

[Bug sanitizer/100439] stack overflow running ubsan

2021-05-13 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #6 from Florin Iucha  ---
With the test file above, and this Makefile:


--8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8<

ALL: bin/test_hello

.PHONY: clean

CXX=/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++

CXXFLAGS=-m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer
LDFLAGS=-Wl,-rpath
-Wl,/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib
-Wl,-dynamic-linker
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2
-fsanitize=undefined

GOOGLE_TEST_PATH=googletest/googletest
GOOGLE_TEST_OBJECTS=obj/gtest.o obj/gtest_main.o obj/gtest-port.o
obj/gtest-filepath.o obj/gtest-death-test.o obj/gtest-test-part.o
obj/gtest-printers.o

obj/test_hello.o: test_hello.cpp
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include -c $<

obj/gtest.o: $(GOOGLE_TEST_PATH)/src/gtest.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<

obj/gtest%.o: $(GOOGLE_TEST_PATH)/src/gtest%.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<

bin/test_hello: obj/test_hello.o $(GOOGLE_TEST_OBJECTS)
$(CXX) -o $@ $(LDFLAGS) $^ -lpthread

clean:
$(RM) bin/test_hello obj/*.o

--8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8<


Cloning google test:

$ git clone https://github.com/google/googletest

(The HEAD now is at f5e592d8ee5ffb1d9af5be7f715ce3576b8bf9c4)

Building:

$ make
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o obj/test_hello.o
-Igoogletest/googletest/include -c test_hello.cpp
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest.o
-Igoogletest/googletest/include -Igoogletest/googletest -c
googletest/googletest/src/gtest.cc
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest_main.o
-Igoogletest/googletest/include -Igoogletest/googletest -c
googletest/googletest/src/gtest_main.cc
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-port.o
-Igoogletest/googletest/include -Igoogletest/googletest -c
googletest/googletest/src/gtest-port.cc
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-filepath.o
-Igoogletest/googletest/include -Igoogletest/googletest -c
googletest/googletest/src/gtest-filepath.cc
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-death-test.o
-Igoogletest/googletest/include -Igoogletest/googletest -c
googletest/googletest/src/gtest-death-test.cc
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-test-part.o
-Igoogletest/googletest/include -Igoogletest/googletest -c
googletest/googletest/src/gtest-test-part.cc
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-printers.o
-Igoogletest/googletest/include -Igoogletest/googletest -c
googletest/googletest/src/gtest-printers.cc
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -o bin/test_hello
-Wl,-rpath -Wl,/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib
-Wl,-dynamic-linker
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2
-fsanitize=undefined obj/test_hello.o obj/gtest.o obj/gtest_main.o
obj/gtest-port.o obj/gtest-filepath.o obj/gtest-death-test.o
obj/gtest-test-part.o obj/gtest-printers.o -lpthread

Running:

$  ./bin/test_hello
zsh: segmentation fault (core dumped)  ./bin/test_hello

Debugging:

(gdb) b __dynamic_cast
Breakpoint 1 at 0x4095c0
(gdb) ignore 1 3
Will ignore next 3 crossings of breakpoint 1.
(gdb) run
...
Breakpoint 1, 0x77ea92fd in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
(gdb) bt
#0  0x77ea92fd in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#1  0x7736be36 in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#2  0x7736ae7a in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#3  0x7736b3b2 in __ubsan_handle_dynamic_type_cache_miss () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#4  0x0045fdaa in std::type_info::operator== (this=0x77f97068
, __arg=...)
at
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/include/c++/11.1.1/typeinfo:122
#5  0x77eab007 in 

[Bug sanitizer/100439] stack overflow running ubsan

2021-05-13 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #5 from Florin Iucha  ---
It is a "CMake object library" - not a static library.

I will prepare a more self-contained test case shortly.

[Bug sanitizer/100439] stack overflow running ubsan

2021-05-06 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #3 from Florin Iucha  ---
Tried it with current HEAD of https://github.com/google/googletest
(f5e592d8ee5ffb1d9af5be7f715ce3576b8bf9c4), with the cmake patched to add
"-fsanitize=undefined -fno-omit-frame-pointer -std=c++2a" and the behavior is
reproducible there.

[Bug sanitizer/100439] stack overflow running ubsan

2021-05-06 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

--- Comment #2 from Florin Iucha  ---
This is for regular x86-64; we're using a cross-compiler sysroot to avoid
dependency on system libraries and be able to run the binary on different Linux
distributions.

I can't reproduce the problem on a "hello, world" C++ program, but I was able
to reproduce it on a minimal Google test:

   --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< 

   #include 

   #include 

   TEST(Hello, World)
   {
   ASSERT_EQ(43, std::stoi("42"));
   }

   --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< 

Built using:

/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o hello.o -c hello.cpp
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -o hello -Wl,-rpath
-Wl,/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib
-Wl,-dynamic-linker
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2
-fsanitize=undefined hello.o
/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20
-fsanitize=undefined -fno-omit-frame-pointer -o test_hello.o
-I/home/fiucha/.conan/data/gtest/20201109/amd/tng/package/150f650d359c1c443c3bb8ac2ffee0bdec61d239/include
-c test_hello.cpp

/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -o test_hello
-Wl,-rpath -Wl,/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib
-Wl,-dynamic-linker
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2
-fsanitize=undefined test_hello.o
/home/fiucha/.conan/data/gtest/20201109/amd/tng/package/150f650d359c1c443c3bb8ac2ffee0bdec61d239/lib/libgmock_maind.a
/home/fiucha/.conan/data/gtest/20201109/amd/tng/package/150f650d359c1c443c3bb8ac2ffee0bdec61d239/lib/libgmockd.a
/home/fiucha/.conan/data/gtest/20201109/amd/tng/package/150f650d359c1c443c3bb8ac2ffee0bdec61d239/lib/libgtestd.a
-lpthread

 ./test_hello
zsh: segmentation fault (core dumped)  ./test_hello

Running under gdb:

(gdb) b __dynamic_cast
Breakpoint 1 at 0x40a620
(gdb) run
Breakpoint 1, 0x77ea92fd in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
(gdb) bt
#0  0x77ea92fd in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#1  0x77eef6ff in bool std::has_facet >(std::locale
const&) ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#2  0x77ee6977 in std::basic_ios
>::_M_cache_locale(std::locale const&) ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#3  0x77ee6c01 in std::basic_ios
>::init(std::basic_streambuf >*) ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#4  0x77ef6c6d in std::basic_ostream
>::basic_ostream(std::basic_streambuf >*) ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#5  0x77eb335b in std::ios_base::Init::Init() () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#6  0x0040af7b in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535)
at
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/include/c++/11.1.1/iostream:74
#7  0x0040b1d3 in _GLOBAL__sub_I__ZN16Hello_World_Test10test_info_E ()
at test_hello.cpp:8
#8  0x0053c5f5 in __libc_csu_init (argc=argc@entry=1,
argv=argv@entry=0x7fffe8b8, envp=0x7fffe8c8) at elf-init.c:89
#9  0x771aa76d in __libc_start_main (main=0x40f8b9 ,
argc=1, argv=0x7fffe8b8, init=0x53c5b0 <__libc_csu_init>,
fini=, rtld_fini=, stack_end=0x7fffe8a8)
at ../csu/libc-start.c:279
#10 0x0040ac4a in _start () at ../sysdeps/x86_64/start.S:120
(gdb) ignore 1 999
Will ignore next 999 crossings of breakpoint 1.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x7736ae75 in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
(gdb) info breakpoints
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x77ea92fd <__dynamic_cast>
breakpoint already hit 7488 times
ignore next 9992512 hits

[Bug sanitizer/100439] New: stack overflow running ubsan

2021-05-05 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439

Bug ID: 100439
   Summary: stack overflow running ubsan
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florin.iucha at amd dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Running 204213fdf23d8228084ded03e1ca9f8acd91d39a (GCC 11-20210501)

Building a test app with -fsanitize=undefined, then putting a breakpoint on
__dynamic_cast:

Breakpoint 1, 0x77ea12fd in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
(gdb) bt
#0  0x77ea12fd in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#1  0x77363e36 in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#2  0x77362e7a in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#3  0x773633b2 in __ubsan_handle_dynamic_type_cache_miss () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#4  0x0041882c in std::type_info::operator== (this=0x6009b8 @GLIBCXX_3.4>, __arg=...)
at
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/include/c++/11.1.1/typeinfo:122
#5  0x77ea3882 in __cxxabiv1::__vmi_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info
const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result&) const ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#6  0x77ea1379 in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#7  0x77ee76ff in bool std::has_facet >(std::locale
const&) ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#8  0x77ede977 in std::basic_ios
>::_M_cache_locale(std::locale const&) ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#9  0x77edec01 in std::basic_ios
>::init(std::basic_streambuf >*) ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#10 0x77eeec6d in std::basic_ostream
>::basic_ostream(std::basic_streambuf >*) ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#11 0x77eab35b in std::ios_base::Init::Init() () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#12 0x00416e8f in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535)
at
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/include/c++/11.1.1/iostream:74


Continuing...

#0  0x77ea12fd in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#1  0x77363e36 in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#2  0x77362e7a in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#3  0x773633b2 in __ubsan_handle_dynamic_type_cache_miss () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#4  0x0041882c in std::type_info::operator== (this=0x77f8f068
, __arg=...)
at
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/include/c++/11.1.1/typeinfo:122
#5  0x77ea3007 in __cxxabiv1::__si_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info
const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result&) const ()
   from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#6  0x77ea1379 in __dynamic_cast () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6
#7  0x77363e36 in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#8  0x77362e7a in ?? () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#9  0x773633b2 in __ubsan_handle_dynamic_type_cache_miss () from
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1
#10 0x0041882c in std::type_info::operator== (this=0x6009b8 @GLIBCXX_3.4>, __arg=...)
at
/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/include/c++/11.1.1/typeinfo:122
#11 0x77ea3882 in __cxxabiv1::__vmi_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info
const*, 

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

2020-11-18 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899

--- Comment #7 from Florin Iucha  ---
Cool, thank you!

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

2020-11-18 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899

--- Comment #5 from Florin Iucha  ---
Curious, were you able to reduce it further, or just bisected it?

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

2020-11-18 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899

--- Comment #3 from Florin Iucha  ---
gcc version 11.0.0 20201108 (previous snapshot) is compiling fine.

[Bug c++/97899] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

2020-11-18 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899

--- Comment #1 from Florin Iucha  ---
Created attachment 49590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49590=edit
pre-processed source file

[Bug c++/97899] New: internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

2020-11-18 Thread florin.iucha at amd dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899

Bug ID: 97899
   Summary: internal compiler error: in split_nonconstant_init_1,
at cp/typeck2.c:626
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florin.iucha at amd dot com
  Target Milestone: ---

Created attachment 49589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49589=edit
c++ source code

gcc version 11.0.0 20201115 (experimental) (GCC) built from
c746fc40f4ec8cfc1092efd49d567751858d2099 (equivalent to
https://gcc.gnu.org/pub/gcc/snapshots/LATEST-11/gcc-11-20201115.tar.xz)

Backtrace:

$ /opt/gcc11-for-tng/bin/g++-11 -std=c++17 -O3 -c pack-fail.cpp
pack-fail.cpp: In member function 'int Baz::otherTest()':
pack-fail.cpp:37:58: internal compiler error: in split_nonconstant_init_1, at
cp/typeck2.c:626
   37 | const auto address = uint64_t{packUint(low, high)};
  |  ^
0x7224d6 split_nonconstant_init_1
../../gcc/gcc/cp/typeck2.c:626
0xb3238f split_nonconstant_init(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck2.c:657
0x99ac66 check_initializer
../../gcc/gcc/cp/decl.c:6909
0x9bebcd cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7699
0xa69587 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:21362
0xa475a3 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13943
0xa63dfd cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:13342
0xa4935f cp_parser_statement
../../gcc/gcc/cp/parser.c:11588
0xa4a46d cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11954
0xa4a548 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11904
0xa63f65 cp_parser_function_body
../../gcc/gcc/cp/parser.c:23551
0xa63f65 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:23602
0xa68800 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:29492
0xa68c4c cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:30394
0xa4482b cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:24664
0xa45723 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:24688
0xa45723 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:17943
0xa466b9 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:14565
0xa70215 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:29888
0xa70596 cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:29552
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Source code for pack-fail.cpp is attached.