[Bug libstdc++/66017] Undefined behaviour in std::setlong long

[public at hansmi dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66017

--- Comment #7 from M. Hanselmann public at hansmi dot ch ---
Confirmed for revision 223846 in gcc-5-branch. Thank you!

[Bug libstdc++/66017] New: Undefined behaviour in std::setlong long

[public at hansmi dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66017

Bug ID: 66017
   Summary: Undefined behaviour in std::setlong long
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: public at hansmi dot ch
  Target Milestone: ---

Created attachment 35463
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35463action=edit
Test program and output after building with Clang 3.6 (using GCC toolchain
5.1.0)

When building for Linux x86 (Debian 8 (Jessie), 32 bit) using `long long' as
std::set's value type causes UBSan as included in Clang 3.5 and 3.6 to report
an downcast/upcast of a misaligned address at runtime and ASan to report
undefined behaviour, all of them in _Rb_tree.

The simplest example I could find:

---
#include set

int main(int, char **)
{
  std::setlong long foo {1LL};
}
---

std::set::begin, std::set::end, set::set::empty cause reports too.

This is not reproducible when compiling with GCC 5.1.0 (with the same options
sans those specific to Clang) and neither when building for x86-64 with either
compiler.

Reproduced using:

- Clang 3.5 w/ GCC toolchain 4.9
- Clang 3.6 w/ GCC toolchain 4.9
- Clang 3.6 w/ GCC toolchain 5.1.0

Shorter value types for std::set, e.g. `long' or `char', work. Packaging the
`long long' in another type, e.g. a struct, works too. The issue does not occur
with libc++.

Bug 60734 reported something similar, though there seem to be more issues. I'm
uncertain as to whether it's an issue in _Rb_tree, __aligned_buffer or another
place altogether.

Original report at LLVM/Clang: https://llvm.org/bugs/show_bug.cgi?id=23413

[Bug libstdc++/66017] Undefined behaviour in std::setlong long

[public at hansmi dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66017

--- Comment #1 from M. Hanselmann public at hansmi dot ch ---
Forgot to add that A. Bougacha has analyzed the issue. According to him it's a
cast (or casts) invoking undefined behaviour.

https://llvm.org/bugs/show_bug.cgi?id=23413#c2

[Bug libstdc++/66017] Undefined behaviour in std::setlong long

[public at hansmi dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66017

--- Comment #2 from M. Hanselmann public at hansmi dot ch ---
This may be related to bug 63345.

[Bug middle-end/61207] Win64 gcc 4.9.0: ICE at -Os compiling some C++ code

[public at hansmi dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207

M. Hanselmann public at hansmi dot ch changed:

   What|Removed |Added

 CC||public at hansmi dot ch

--- Comment #5 from M. Hanselmann public at hansmi dot ch ---
This also happens when compiling Boost 1.57.0. I've reproduced it using
TDM64-GCC (version 4.9.2-3) and Stephan T. Lavavej's MinGW distribution
(version 12.2).

How to reproduce:

- Unpack Boost 1.57.0 and change into source directory
- g++ -v -save-temps -Os -I. libs\test\src\unit_test_parameters.cpp

As mentioned in earlier comments, -O{1,2,3} work and only -Os produced an ICE.
I'm not attaching 2.3 MB preprocessed file due to the wide availability of
Boost sources.

[Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()

[public at hansmi dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258

--- Comment #9 from M. Hanselmann public at hansmi dot ch ---
A few days ago I submitted a patch for this issue based on Dmitry's patch. It
seems as if we can get it in after the 5.0 release.

https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00027.html

[Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()

[public at hansmi dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258

M. Hanselmann public at hansmi dot ch changed:

   What|Removed |Added

 CC||public at hansmi dot ch

--- Comment #7 from M. Hanselmann public at hansmi dot ch ---
Confirmed using GCC 5.0.0 20150125 built from source (see below) and 4.7.2
(Debian 4.7.2-5; Debian Wheezy). Tested using the test case in comment 1.

Output:
$ g++-5-20150125 -std=c++11 -o test62258 test62258.c -Wall  ./test62258
test62258: test62258.c:11: int main(): Assertion `!std::uncaught_exception()'
failed.
Aborted

$ g++-5-20150125 -v
Using built-in specs.
COLLECT_GCC=g++-5-20150125
COLLECT_LTO_WRAPPER=/home/user/gcc50/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/user/gcc50build/src-gcc-5-20150125/configure
--target=x86_64-unknown-linux-gnu
--prefix=/home/user/gcc50build/target-x86_64-unknown-linux-gnu
--program-suffix=-5-20150125 --disable-nls --enable-c99
--enable-checking=release --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-long-long --enable-multiarch
--enable-multilib --enable-shared --enable-targets=all --enable-threads=posix
--with-system-zlib --with-tune=generic
Thread model: posix
gcc version 5.0.0 20150125 (experimental) (GCC)