[Bug libstdc++/59027] New: std::is_signed does not include check for is_arithmetic

[marc.mutz at kdab dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027

Bug ID: 59027
   Summary: std::is_signed does not include check for
is_arithmetic
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com

According to N3797 Table 49, both is_signed and is_unsigned should evaluate to
true_type only if the argument is_arithmetic, too. is_unsigned honours this,
but is_signed doesn't:

  templatetypename _Tp,
   bool = is_arithmetic_Tp::value
struct __is_signed_helper
: public false_type { };

  templatetypename _Tp
struct __is_signed_helper_Tp, true
: public integral_constantbool, _Tp(-1)  _Tp(0)
{ };

  /// is_signed
  templatetypename _Tp
struct is_signed
: public __is_signed_helper_Tp::type
{ };

  /// is_unsigned
  templatetypename _Tp
struct is_unsigned
: public __and_is_arithmetic_Tp, __not_is_signed_Tp::type
{ };

[Bug libstdc++/59027] std::is_signed does not include check for is_arithmetic

[marc.mutz at kdab dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027

Marc Mutz marc.mutz at kdab dot com changed:

   What|Removed |Added

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

--- Comment #3 from Marc Mutz marc.mutz at kdab dot com ---
See code posted in http://llvm.org/bugs/show_bug.cgi?id=17834
is_unsignedMouseButton fails, !is_signed succeeds. MouseButton is an enum.

[Bug c++/58389] New: g++ ICE in ipa_find_reference

[marc.mutz at kdab dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58389

Bug ID: 58389
   Summary: g++ ICE in ipa_find_reference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com

Created attachment 30796
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30796action=edit
Preprocessed source (compressed to fit into file size limit)

Compiling master Qt with the trunk version of g++:

Command:
g++ -std=c++11 -o out.o -c -include .pch/release-shared/Qt5Widgets -pipe
-pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12 -O2 -fvisibility=hidden
-fvisibility-inlines-hidden -std=c++0x -fno-exceptions -Wall -W -D_REENTRANT
-fPIC -DQT_NO_XKB -DQT_NO_USING_NAMESPACE -DQT_BUILD_WIDGETS_LIB
-DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_STYLE_MAC
-DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE
-DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_ANDROID -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_GUI_LIB
-DQT_CORE_LIB -I/home/marc/qtbase/mkspecs/linux-g++
-I/home/marc/qtbase/src/widgets -I../../include -I../../include/QtWidgets
-I../../include/QtWidgets/5.2.0 -I../../include/QtWidgets/5.2.0/QtWidgets
-I/home/marc/qtbase/src/widgets/dialogs -I.uic/release-shared
-I../../include/QtGui -I../../include/QtGui/5.2.0
-I../../include/QtGui/5.2.0/QtGui -I../../include/QtCore
-I../../include/QtCore/5.2.0 -I../../include/QtCore/5.2.0/QtCore
-I.moc/release-shared -I.
/home/marc/qtbase/src/widgets/graphicsview/qgraphicsitem.cpp -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
In file included from
../../include/QtWidgets/5.2.0/QtWidgets/private/qpixmapfilter_p.h:1:0,
 from
../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/effects/qgraphicseffect_p.h:61,
 from
../../include/QtWidgets/5.2.0/QtWidgets/private/qgraphicseffect_p.h:1,
 from
../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/kernel/qwidget_p.h:66,
 from
../../include/QtWidgets/5.2.0/QtWidgets/private/qwidget_p.h:1,
 from
../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/widgets/qframe_p.h:56,
 from
../../include/QtWidgets/5.2.0/QtWidgets/private/qframe_p.h:1,
 from
../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/widgets/qabstractscrollarea_p.h:56,
 from
../../include/QtWidgets/5.2.0/QtWidgets/private/qabstractscrollarea_p.h:1,
 from
/home/marc/qtbase/src/widgets/graphicsview/qgraphicsview_p.h:64,
 from
/home/marc/qtbase/src/widgets/graphicsview/qgraphicsscene_p.h:62,
 from
/home/marc/qtbase/src/widgets/graphicsview/qgraphicsitem.cpp:725:
../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/effects/qpixmapfilter_p.h:146:24:
internal compiler error: Segmentation fault
 class Q_WIDGETS_EXPORT QPixmapColorizeFilter : public QPixmapFilter
^
0xacbd0f crash_signal
../../gcc/gcc/toplev.c:335
0x98af50 ipa_find_reference(symtab_node_def*, symtab_node_def*,
gimple_statement_d*, unsigned int)
../../gcc/gcc/ipa-ref.c:277
0x97ccde remove_described_reference
../../gcc/gcc/ipa-prop.c:2510
0x981064 ipa_edge_removal_hook
../../gcc/gcc/ipa-prop.c:3022
0x7d9068 cgraph_call_edge_removal_hooks
../../gcc/gcc/cgraph.c:314
0x7d9068 cgraph_node_remove_callees(cgraph_node*)
../../gcc/gcc/cgraph.c:1563
0x7d9524 cgraph_remove_node(cgraph_node*)
../../gcc/gcc/cgraph.c:1680
0x98e154 symtab_remove_unreachable_nodes(bool, _IO_FILE*)
../../gcc/gcc/ipa.c:453
0xf2bdb0 ipa_inline
../../gcc/gcc/ipa-inline.c:2014
0xf2bdb0 execute
../../gcc/gcc/ipa-inline.c:2380
Please submit a full bug report,
with preprocessed source if appropriate.

GCC version:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/gcc/4.9-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gcc/4.9-trunk
--enable-languages=c++
Thread model: posix
gcc version 4.9.0 20130911 (experimental) (GCC)

[Bug c++/79433] New: __has_include reports wrong result headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

Bug ID: 79433
   Summary: __has_include reports wrong result headers that #error
on __cplusplus
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Code that attempts to detect, say, string_view support by
__has_include() or __has_include() and
then attempts to #include those headers is greeted with an #error that these
headers require C++17 and C++14, resp.

Since there's no SG-10 SD-6 feature test macro for string_view, this means that
no portable way of detecting string_view support is possible.

Expected behaviour: __has_include should behave consistent with the header's
#error mechanism.

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

--- Comment #5 from Marc Mutz  ---
Andrew, you're taking the easy way out. It might be that it works as
implemented, but that behaviour is useless.

Please explain how one should detect, in a portable way, whether string_view
and experimental::string_view is available, if not by headers check.

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
And no, checking __cplusplus in addition is not an option, since many
compilers, GCC included (__cplusplus==1, remember?), do not necessarily bump
__cplusplus when they implement enough core features to make something like
string_view (which can be implemented in C++11 just fine) work.

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
Ok, there is __cpp_lib_experimental_string_view, at least, but it's defined ...
wait for it ... in , which you can't include.

[Bug c++/79564] New: [missed optimization][x86] relaxed atomic counting compiled the same as seq_cst

[marc.mutz at kdab dot com]

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

Bug ID: 79564
   Summary: [missed optimization][x86] relaxed atomic counting
compiled the same as seq_cst
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

I believe that the following code (https://godbolt.org/g/81DcP8):

#include 

int count_relaxed(const char *str) {
static std::atomic_int counter = {0};
while (*str++)
counter.fetch_add(1, std::memory_order_relaxed);
return counter;
}

could be optimized into

   register r = __builtin_strlen(str);
   counter.fetch_add(r, std::memory_order_relaxed);

Signed overflow is UB, so can be assumed not to happen.

The modification order of a relaxed atomic variable is not related to the
modification order of any other variable. All the compiler must ensure is that
no value can be read after a later one has been seen by this thread, and that
no values are read that weren't written by some other, possibly the same,
thread. Performing a single fetch_add() at the end of the loop (possibly
guarded by a check for zero to not introduce a (no-op) write where there's none
in the source) should be a valid optimization.

As the godbolt link shows, it currently is compiled identically to the seq_cst
version.

[Bug libstdc++/79433] __has_include does not conform to SD-6

[marc.mutz at kdab dot com]

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

--- Comment #11 from Marc Mutz  ---
Fair enough. Sorry for filing it under the wrong component.

[Bug c++/79561] New: Missed optimization: useless guards for zero-initialized POD statics at function scope.

[marc.mutz at kdab dot com]

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

Bug ID: 79561
   Summary: Missed optimization: useless guards for
zero-initialized POD statics at function scope.
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Example code:

BEGIN
#include 
#include 

template 
class BasicAtomic
{
public:
std::atomic v;

BasicAtomic() = default;
constexpr BasicAtomic(T t) noexcept : v(t) {}
BasicAtomic(const BasicAtomic&) = delete;
BasicAtomic =(const BasicAtomic &) = delete;
BasicAtomic =(const BasicAtomic &) volatile = delete;
};

static_assert(std::is_pod<BasicAtomic>::value, "oops");

static BasicAtomic s_dyn;

int f(const char *str) {
while (*str++)
++s_dyn.v;
return s_dyn.v;
}

int f_dynamic_init(const char *str) {
static BasicAtomic counter;
while (*str++)
++counter.v;
return counter.v;
}

int f_static_init(const char *str) {
static BasicAtomic counter = {0};
while (*str++)
++counter.v;
return counter.v;
}

END

GCC (all the way up to 7.0.1) adds a guard for f_dynamic_init(const
char*)::counter (but not for the other two).

Clang 3.9.1 doesn't.

See the difference here: https://godbolt.org/g/erFlRq

[Bug c++/79561] Missed optimization: useless guards for zero-initialized POD statics at function scope.

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
For a moment, I thought it was about std::atomic, but a simple

template  container { T t; }

instead of std::atomic produces the same result.

So it seems like the = default ctor is the problem. If I remove all special
member functions, the guards disappear: https://godbolt.org/g/oZlR3o

BEGIN
#include 
#include 

template 
struct container { T i; };

template 
class BasicAtomic
{
public:
container v;
#if 0
BasicAtomic() = default;
constexpr BasicAtomic(T t) noexcept : v{t} {}
BasicAtomic(const BasicAtomic&) = delete;
BasicAtomic =(const BasicAtomic &) = delete;
BasicAtomic =(const BasicAtomic &) volatile = delete;
 #endif
};

static_assert(std::is_pod::value, "oops");

static BasicAtomic s_dyn;

int f(const char *str) {
while (*str++)
++s_dyn.v.i;
return s_dyn.v.i;
}

int f_dynamic_init(const char *str) {
static BasicAtomic counter;
while (*str++)
++counter.v.i;
return counter.v.i;
}

int f_static_init(const char *str) {
static BasicAtomic counter = {0};
while (*str++)
++counter.v.i;
return counter.v.i;
}
END

[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

--- Comment #3 from Marc Mutz  ---
This is not restricted to thread_locals. It also affects statics in functions:
PR 79561

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

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

--- Comment #9 from Marc Mutz  ---
__has_include these days is defined by SD-6, and while not spelled out in
normative text, the intent is very much for it to be able to detect presence of
a header for inclusion. Quoting from
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations:

 This demonstrates a way to use a library optional facility only if it is
available.

#ifdef __has_include
#  if __has_include()
#include 
#define have_optional 1
#  elif __has_include()
#include 
#define have_optional 1
#define experimental_optional
#  else
#define have_optional 0
#  endif
#endif

So, IMHO, you do have a bug here, because this example does not work as
intended by its defining norm.

Absent any proof to the contrary, I believe that in order to conform to SD-6,
you have to move such headers under a c++1{1,4,z}/ subdir which only gets added
to the include path if the resp. -std is in effect. This will make the example
from SD-6 work, as well as enabling the use-case Jonathan mentioned in the IRC
log.

Note that removing the #error from the header files, so they can at least be
included, if present, and a corresponding __cpp_lib macro can be evaluated is
still not conforming to SD-6, since the example assumes that availability of
the header implies usability without further checks, making __cpp_lib macros
useful for versioning

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[marc.mutz at kdab dot com]

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

--- Comment #14 from Marc Mutz  ---
You can hide behind the letter of the standard, but you cannot escape the
simple fact that __has_include is the intended mechanism to check for library
features that added a new header. Proof: You need to include that header to get
at the __cpp_lib macro, if any. If you can't use __has_include for that,
because the header stabs you in the back, then that intended mechanism is
broken. Call it conforming if you want, but it simply isn't.

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

--- Comment #13 from Marc Mutz  ---
Created attachment 39769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39769=edit
Preprocessed source for a TU that fails

Command line for a TU that fails:

  g++ -c -include .pch/Qt5Core -pipe -g -O3 -std=c++1z \
-I/usr/include/glib-2.0 \
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include \
-pthread \
-fvisibility=hidden \
-fvisibility-inlines-hidden \
-fsanitize=address \
-fsanitize=undefined \
-fno-omit-frame-pointer \
-Wall \
-W \
-Wvla \
-Wdate-time \
-Wshift-overflow=2 \
-Wduplicated-cond \
-Werror \
-Wno-error=cpp \
-Wno-error=deprecated-declarations \
-Wno-error=strict-overflow \
-D_REENTRANT \
-fPIC \
-DQT_NO_USING_NAMESPACE \
-DQT_NO_FOREACH \
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" \
-DQT_USE_ICU \
-DQT_HAVE_POLL \
-DQT_HAVE_PPOLL \
-DQT_BUILD_CORE_LIB \
-DQT_BUILDING_QT \
-DQT_NO_CAST_TO_ASCII \
-DQT_ASCII_CAST_WARNINGS \
-DQT_MOC_COMPAT \
-DQT_USE_QSTRINGBUILDER \
-DQT_DEPRECATED_WARNINGS \
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 \
-D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE \
-DQT_NO_DEBUG \
-I/home/marc/Qt/qt5/qtbase/src/corelib \
-I. \
-Iglobal \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/harfbuzz/src \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md5 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md4 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/sha3 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/forkfd \
-I../../include \
-I../../include/QtCore \
-I../../include/QtCore/5.8.0 \
-I../../include/QtCore/5.8.0/QtCore \
-I.moc \
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ \
-o .obj/qlibraryinfo.o \
/home/marc/Qt/qt5/qtbase/src/corelib/global/qlibraryinfo.cpp

Fails with:
  {standard input}: Assembler messages:
  {standard input}:22992: Error: symbol `.Lubsan_type1' is already defined

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

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

--- Comment #14 from Marc Mutz  ---
More examples (incl. ones with .Lubsan_type3) available on request.

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

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

--- Comment #5 from Marc Mutz  ---
It's in a function template, in case that helps. I'll try to trim it down now.

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

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

--- Comment #7 from Marc Mutz  ---
Version:

  $ g++ -v
  Using built-in specs.
  COLLECT_GCC=g++
 
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
  Target: x86_64-pc-linux-gnu
  Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
  Thread model: posix
  gcc version 7.0.0 20161005 (experimental) (GCC) 

Specifically:

  $ git log -10 --online
  c7b01e7 PR sanitizer/77823  * c-ubsan.c (ubsan_instrument_shift):
Return NULL_TREE if type0 is not integral.
  d20 Fix pr69941.c test failure for avr
  ea55eab 2016-10-05  Jerry DeLisle  
  9ce1157 PR bootstrap/77819 - undefined reference to
gnu_libc_printf_pointer_format with uClibc
  5c176eb * c-common.c (c_common_reswords): Update comment for C++11.
  4ef2832 [fold-const] Fix native_encode_real for HFmode constants
  59deb1a 70564 fix newly-added tests for not_fn
  c375ef0 libcpp/ChangeLog:
  77a1a89 Move all existing strchr and strrchr folding from builtins.c to
gimple-fold.c.
  ad69f5a PR 70101 fix allocator-extended ctors for std::priority_queue

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

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

--- Comment #6 from Marc Mutz  ---
Created attachment 39770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39770=edit
Test case

Result:

  $ g++ -Wextra -std=c++1z -O2 bug.cpp
  bug.cpp: In function ‘void qt_memfill(T*, T, int) [with T = int]’:
  bug.cpp:10:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 0: do { *dest++ = value;
  ^
  bug.cpp:12:7: note: here
 case 7:  *dest++ = value;
 ^~~~
  bug.cpp:12:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 7:  *dest++ = value;
  ^
  bug.cpp:14:7: note: here
 case 6:  *dest++ = value;
 ^~~~
  bug.cpp:14:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 6:  *dest++ = value;
  ^
  bug.cpp:16:7: note: here
 case 5:  *dest++ = value;
 ^~~~
  bug.cpp:16:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 5:  *dest++ = value;
  ^
  bug.cpp:18:7: note: here
 case 4:  *dest++ = value;
 ^~~~
  bug.cpp:18:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 4:  *dest++ = value;
  ^
  bug.cpp:20:7: note: here
 case 3:  *dest++ = value;
 ^~~~
  bug.cpp:20:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 3:  *dest++ = value;
  ^
  bug.cpp:22:7: note: here
 case 2:  *dest++ = value;
 ^~~~

iow: only the attribute helps.

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

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

--- Comment #8 from Marc Mutz  ---
#c3 is also in a template, indeed.

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

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

--- Comment #12 from Marc Mutz  ---
Created attachment 39768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39768=edit
Preprocessed source for PCH

Command line for PCH file:

  g++ -pipe -g -O3 -std=c++1z \
-I/usr/include/glib-2.0 \
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include \
-pthread \
-fvisibility=hidden \
-fvisibility-inlines-hidden \
-fsanitize=address \
-fsanitize=undefined \
-fno-omit-frame-pointer \
-Wall \
-W \
-Wvla \
-Wdate-time \
-Wshift-overflow=2 \
-Wduplicated-cond \
-Werror \
-Wno-error=cpp \
-Wno-error=deprecated-declarations \
-Wno-error=strict-overflow \
-D_REENTRANT \
-fPIC \
-DQT_NO_USING_NAMESPACE \
-DQT_NO_FOREACH \
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" \
-DQT_USE_ICU \
-DQT_HAVE_POLL \
-DQT_HAVE_PPOLL \
-DQT_BUILD_CORE_LIB \
-DQT_BUILDING_QT \
-DQT_NO_CAST_TO_ASCII \
-DQT_ASCII_CAST_WARNINGS \
-DQT_MOC_COMPAT \
-DQT_USE_QSTRINGBUILDER \
-DQT_DEPRECATED_WARNINGS \
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 \
-D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE \
-DQT_NO_DEBUG \
-I/home/marc/Qt/qt5/qtbase/src/corelib \
-I. \
-Iglobal \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/harfbuzz/src \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md5 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md4 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/sha3 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/forkfd \
-I../../include \
-I../../include/QtCore \
-I../../include/QtCore/5.8.0 \
-I../../include/QtCore/5.8.0/QtCore \
-I.moc \
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ \
-x c++-header \
-c /home/marc/Qt/qt5/qtbase/src/corelib/global/qt_pch.h \
-o .pch/Qt5Core.gch/c++

  g++ -v
   Using built-in specs.
   COLLECT_GCC=g++
  
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
   Target: x86_64-pc-linux-gnu
   Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
   Thread model: posix
   gcc version 7.0.0 20161005 (experimental) (GCC) 

  git log -10 --oneline
   c7b01e7 PR sanitizer/77823  * c-ubsan.c
(ubsan_instrument_shift): Return NULL_TREE if type0 is not integral.
   d20 Fix pr69941.c test failure for avr
   ea55eab 2016-10-05  Jerry DeLisle  
   9ce1157 PR bootstrap/77819 - undefined reference to
gnu_libc_printf_pointer_format with uClibc
   5c176eb * c-common.c (c_common_reswords): Update comment for C++11.
   4ef2832 [fold-const] Fix native_encode_real for HFmode constants
   59deb1a 70564 fix newly-added tests for not_fn
   c375ef0 libcpp/ChangeLog:
   77a1a89 Move all existing strchr and strrchr folding from builtins.c to
gimple-fold.c.
   ad69f5a PR 70101 fix allocator-extended ctors for std::priority_queue

[Bug c++/77887] -Wimplicit-fallthrough fails to trigger in an unused function template specialisation

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
Created attachment 39772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39772=edit
Expanded version of test-case for 77886, adding an unused inline non-template
overload of the function template

Findings:

  l.30 \ l.29   template specialisation  overload
  inline - doesn"t warn  - doesn't warn
  non-inline + warns + warns

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

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

--- Comment #10 from Marc Mutz  ---
I can confirm patch fixes my Qt build, ie. not just bug.cpp.

Thanks!

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

--- Comment #8 from Marc Mutz  ---
I see the same in conditional code. Example fix that I applied to Qt locally,
but won't push, because the next compiler will warn that the *comment is
bogus*: 

   case QVariant::Bool:
   return qulonglong(d->data.b);
   #ifndef QT_BOOTSTRAPPED
   case QMetaType::QJsonValue:
   if (!v_cast(d)->isDouble())
   break;
  -// fall through
   #endif
  +// fall through
   case QVariant::Double:

We have about a dozen of those in QtBase alone, and while Qt 5.8 has a macro
for the attribute, the 5.6 LTS version does not, and still has >2 years of
support ahead of it, so a comment solution would be strongly preferred, and it
would *really* help if this was fixed before this version of the compiler went
into production.

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

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

--- Comment #3 from Marc Mutz  ---
Here's another example of a switch where I can't silence the warning, except by
C++11 attribute:

  switch (i & 7) {
  case 7: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
  case 6: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
  case 5: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
  case 4: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
  case 3: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
  case 2: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
  case 1: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
  }

[Bug c++/77887] New: -Wimplicit-fallthrough fails to trigger in an unused function template specialisation

[marc.mutz at kdab dot com]

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

Bug ID: 77887
   Summary: -Wimplicit-fallthrough fails to trigger in an unused
function template specialisation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

I have a switch statement here that -Wimplicit-fallthrough fails to warn about:

  template <>
  inline void qt_memfill_template(quint16 *dest, quint16 value, int count)
  {
  if (count < 3) {
  switch (count) {
  case 2: *dest++ = value;
  // fall through<-- absence is not detected
  case 1: *dest = value;
  }
  return;
  }

  // ...

This specialisation ends up not being instantiated, but I'd expect a warning
from a full specialisation nonetheless.

Hmm. If I change from specialisation to overloading (ie. to a non-template),
the switch still doesn't trigger.

I thought the warning was generated by the front-end, but it seems it'd
generated by the backend instead, after dead code elimination...?

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
It's worse than I thought:

int n = (count + 7) / 8;
switch (count & 0x07)
{
case 0: do { *dest++ = value;
// fall through
case 7:  *dest++ = value;
// fall through
case 6:  *dest++ = value;
// fall through
case 5:  *dest++ = value;
// fall through
case 4:  *dest++ = value;
// fall through
case 3:  *dest++ = value;
// fall through
case 2:  *dest++ = value;
// fall through
case 1:  *dest++ = value;
} while (--n > 0);
}

still warns.

The only way to avoid the warning is to use [[fallthrough]] at the end of each
line.

[Bug c/77886] New: -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

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

Bug ID: 77886
   Summary: -Wimplicit-fallthrough: breaks duff's device
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

The recent addition (or activation) of -Wimplicit-fallthrough breaks Duff's
Device:

int n = (count + 7) / 8;
switch (count & 0x07)
{
case 0: do { *dest++ = value;
case 7:  *dest++ = value;
case 6:  *dest++ = value;
case 5:  *dest++ = value;
case 4:  *dest++ = value;
case 3:  *dest++ = value;
case 2:  *dest++ = value;
case 1:  *dest++ = value;
} while (--n > 0);
}

adding all those pesky // fall through comments makes the code unreadable, the
more so as GCC doesn"t accept it as a trailing comment after each line but
insists on having it on a line of its own.

[Bug c/77909] New: -Wimplicit-fallthrough: accept more comment variants

[marc.mutz at kdab dot com]

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

Bug ID: 77909
   Summary: -Wimplicit-fallthrough: accept more comment variants
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

In QtBase, we have several unrecognised forms of fall-through comments, which
are quite common, and probably should be recognized, too:

- interpunctation: "fall through" followed by [;:!]

- prefix with "else", "otherwise", or "intentionl(ly)"

- "no break" instead of "fall through"

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[marc.mutz at kdab dot com]

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

--- Comment #12 from Marc Mutz  ---
Is replacing a matching comment with __attribute__(fallthrough)) so complicated
as to make this a wontfix?

[Bug c++/78434] Incorrect warning about missing align_val_t for placement new

[marc.mutz at kdab dot com]

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

--- Comment #3 from Marc Mutz  ---
Possibly. I couldn't check later versions because trunk failed to compile for
me in i386.c.

[Bug c++/78567] New: GCC trunk fails to compile all-stage2-gcc in i386.c

[marc.mutz at kdab dot com]

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

Bug ID: 78567
   Summary: GCC trunk fails to compile all-stage2-gcc in i386.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Last successful built was 5th of October (yielding gcc version 7.0.0 20161005
(experimental) (GCC)), this failure persists since somewhen around the
beginning of November:

  make[3]: Entering directory '/home/marc/C++/gcc-build/gcc'
  /home/marc/C++/gcc-build/./prev-gcc/xg++
-B/home/marc/C++/gcc-build/./prev-gcc/ -B/d/gcc/trunk/x86_64-pc-linux-gnu/bin/
-nostdinc++
-B/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/home/marc/C++/gcc/libstdc++-v3/libsupc++
-L/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o i386.o -MT i386.o -MMD
-MP -MF ./.deps/i386.TPo ../../gcc/gcc/config/i386/i386.c
  ../../gcc/gcc/config/i386/i386.c: In function ‘rtx_def*
ix86_expand_builtin(tree, rtx, rtx, machine_mode, int)’:
  ../../gcc/gcc/config/i386/i386.c:38407:18: error: ‘fcn’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
  emit_insn (fcn (target, accum, wide_reg, mem));
  ~~^~~~
  cc1plus: all warnings being treated as errors
  Makefile:2198: recipe for target 'i386.o' failed
  make[3]: *** [i386.o] Error 1
  make[3]: Leaving directory '/home/marc/C++/gcc-build/gcc'
  Makefile:4589: recipe for target 'all-stage2-gcc' failed
  make[2]: *** [all-stage2-gcc] Error 2
  make[2]: Leaving directory '/home/marc/C++/gcc-build'
  Makefile:24513: recipe for target 'stage2-bubble' failed
  make[1]: *** [stage2-bubble] Error 2
  make[1]: Leaving directory '/home/marc/C++/gcc-build'
  Makefile:935: recipe for target 'all' failed
  make: *** [all] Error 2

Host compiler is

  $ g++ -v
  Using built-in specs.
  COLLECT_GCC=g++
  COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
  Target: x86_64-linux-gnu
  Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
  Thread model: posix
  gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 

Configure line:

  configure --prefix=/d/gcc/trunk --enable-checking=release
--enable-languges=c,c++,fortran,lto,objc,obj-c++

(out-of-souce build, clean except for config.status, which was how this build
was configured)

[Bug c++/78567] GCC trunk fails to compile all-stage2-gcc in i386.c

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
Also happens on a fresh configure.

[Bug c++/78434] New: Incorrect warning about missing align_val_t for placement new

[marc.mutz at kdab dot com]

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

Bug ID: 78434
   Summary: Incorrect warning about missing align_val_t for
placement new
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

GCC incorrectly warns about a missing std::align_val_t argument on a
placement-new expression:

  qtbase-5.6/src/corelib/tools/qvector.h:663:5: warning: ‘new’ of type
‘Aligned128’ with extended alignment 128 [-Waligned-new=]
   new (d->end()) T(std::move(t));
   ^~
  qtbase-5.6/src/corelib/tools/qvector.h:663:5: note: uses ‘void* operator
new(std::size_t, void*)’, which does not have an alignment parameter
  qtbase-5.6/src/corelib/tools/qvector.h:663:5: note: use ‘-faligned-new’ to
enable C++17 over-aligned new support

This is with g++ -v

  Using built-in specs.
  COLLECT_GCC=/d/gcc/trunk/bin/g++
 
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
  Target: x86_64-pc-linux-gnu
  Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
  Thread model: posix
  gcc version 7.0.0 20161005 (experimental) (GCC)

[Bug c++/78434] Incorrect warning about missing align_val_t for placement new

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
Created attachment 40089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40089=edit
Testcase, compile with g++ -Wall -o 78434{,.cpp}

Actual Output:

  78434.cpp:11:30: warning: ‘new’ of type ‘Align128’ with extended alignment
128 [-Waligned-new=]
 new (buf) Align128{1.0, 2.0};
^
  78434.cpp:11:30: note: uses ‘void* operator new(std::size_t, void*)’, which
does not have an alignment parameter
  78434.cpp:11:30: note: use ‘-faligned-new’ to enable C++17 over-aligned new
support

Expected Output: none. placement new has no overload taking std::align_val_t.

[Bug target/78567] [7 Regression] GCC trunk fails to compile all-stage2-gcc in i386.c with x32 enabled

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #4 from Marc Mutz  ---
I can confirm this is fixed in trunk now. Thanks!

[Bug c++/78858] New: Bogus -Wnonnull warning involving strcmp.

[marc.mutz at kdab dot com]

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

Bug ID: 78858
   Summary: Bogus -Wnonnull warning involving strcmp.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Latest trunk emits spurious -Wnonnull warnings, eg. in Qt:

  qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp: In member function ‘void
QCoreApplicationPrivate::processCommandLineArguments()’:
  qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp:195:20: error: argument 1
null where non-null expected [-Werror=nonnull]
   if (strncmp(arg, "-qmljsdebugger=", 15) == 0) {
   ~~~^~~~

The surrounding code reads:

   int j = argc ? 1 : 0;
   for (int i = 1; i < argc; ++i) {
   if (!argv[i])
   continue;
   if (*argv[i] != '-') {
   argv[j++] = argv[i];
   continue;
   }
   const char *arg = argv[i];
   if (arg[1] == '-') // startsWith("--")
   ++arg;
   if (strncmp(arg, "-qmljsdebugger=", 15) == 0) {
   qmljs_debug_arguments = QString::fromLocal8Bit(arg + 15);

where argc and argv are member variables (of types int and char**, resp.).

This warning is bogus for two reasons: First, we deref 'arg' in the preceding
if-statements. If it was nullptr, then that would invoke UB, so the compiler
can assume that arg is non-null. Second, we explicitly check for a nullptr
'arg' as the first thing in the loop, and we call no functions in-between that
could change the state. We also don't do perform any atomic operations.

This is not an isolated error. GCC creates dozens of warnings in Qt code, but
most of them are not as clearly wrong as this one.

This one I cannot even fix by moving the arg definition to the first line of
the loop and checking for !arg in the first if:


const char *arg = argv[i];
if (!arg)
continue;

[Bug c++/78858] Bogus -Wnonnull warning involving strcmp.

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
Created attachment 40366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40366=edit
Preprocessed source

Command line used:

  g++ -E -pipe -ffunction-sections -O2 -g -fPIC -std=c++1z -fno-exceptions
-fsanitize=address -fsanitize=undefined -fno-omit-frame-pointer -Wall -W -Wvla
-Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror -Wno-error=cpp
-Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT
-DQT_VERSION_STR='"5.8.0"' -DQT_VERSION_MAJOR=5 -DQT_VERSION_MINOR=8
-DQT_VERSION_PATCH=0 -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_TO_ASCII
-DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_LIBRARY -DQT_NO_QOBJECT
-DQT_NO_SYSTEMLOCALE -DQT_NO_THREAD -DQT_NO_UNICODETABLES
-DQT_NO_USING_NAMESPACE -DQT_NO_DEPRECATED -DQT_NO_TRANSLATION
-DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_NO_FOREACH -DQT_NO_CAST_FROM_ASCII
-DQT_BUILD_BOOTSTRAP_LIB -DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/marc/Qt/qt5/qtbase/src/tools/bootstrap -I. -I../../../include
-I../../../include/QtCore -I../../../include/QtCore/5.8.0
-I../../../include/QtCore/5.8.0/QtCore -I../../../include/QtXml
-I../../../include/QtXml/5.8.0 -I../../../include/QtXml/5.8.0/QtXml
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ -o qcoreapplication.ii
/home/marc/Qt/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp

[Bug c++/78858] Bogus -Wnonnull warning involving strcmp.

[marc.mutz at kdab dot com]

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

--- Comment #3 from Marc Mutz  ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
gcc version 7.0.0 20161219 (experimental) (GCC)

[Bug c++/78858] [7 Regression] Bogus -Wnonnull warning involving strcmp with -fsanitize=undefined

[marc.mutz at kdab dot com]

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

--- Comment #5 from Marc Mutz  ---
Created attachment 40368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40368=edit
Another TU that has an unfixable -Wnonnull warning

g++ -c -pipe -ffunction-sections -O2 -g -fPIC -std=c++1z -fno-exceptions
-fsanitize=address -fsanitize=undefined -fno-omit-frame-pointer -Wall -W -Wvla
-Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror -Wno-error=cpp
-Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT
-DQT_VERSION_STR='"5.8.0"' -DQT_VERSION_MAJOR=5 -DQT_VERSION_MINOR=8
-DQT_VERSION_PATCH=0 -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_TO_ASCII
-DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_LIBRARY -DQT_NO_QOBJECT
-DQT_NO_SYSTEMLOCALE -DQT_NO_THREAD -DQT_NO_UNICODETABLES
-DQT_NO_USING_NAMESPACE -DQT_NO_DEPRECATED -DQT_NO_TRANSLATION
-DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_NO_FOREACH -DQT_NO_CAST_FROM_ASCII
-DQT_BUILD_BOOTSTRAP_LIB -DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/marc/Qt/qt5/qtbase/src/tools/bootstrap -I. -I../../../include
-I../../../include/QtCore -I../../../include/QtCore/5.8.0
-I../../../include/QtCore/5.8.0/QtCore -I../../../include/QtXml
-I../../../include/QtXml/5.8.0 -I../../../include/QtXml/5.8.0/QtXml
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ -o .obj/qjsonparser.o
/home/marc/Qt/qt5/qtbase/src/corelib/json/qjsonparser.cpp
In file included from ../../../include/QtCore/qvector.h:1:0,
 from
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/io/qdebug.h:51,
 from ../../../include/QtCore/qdebug.h:1,
 from
/home/marc/Qt/qt5/qtbase/src/corelib/json/qjsonparser.cpp:44:
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qvector.h: In
member function ‘void QJsonPrivate::Parser::ParsedObject::insert(uint)’:
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qvector.h:717:13:
error: argument 2 null where non-null expected [-Werror=nonnull]
 memmove(i, b, (d->size - offset) * sizeof(T));
 ^~~

[Bug c++/78858] [7 Regression] Bogus -Wnonnull warning involving strcmp with -fsanitize=undefined

[marc.mutz at kdab dot com]

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

--- Comment #6 from Marc Mutz  ---
Ah, I see.

[Bug middle-end/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM)

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

--- Comment #5 from Marc Mutz  ---
Why is this only "missed-optimization"? Don't these architecture's ABIs
stipulate passing in registers, as well as the Itanium ABI? So why is this not
a platform ABI conformance issue?

[Bug middle-end/81194] [8 Regression] ICE during RTL pass: expand

[marc.mutz at kdab dot com]

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

--- Comment #15 from Marc Mutz  ---
FWIW, the patch fixes the ICE for me, too.

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[marc.mutz at kdab dot com]

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

--- Comment #22 from Marc Mutz  ---
(In reply to Jonathan Wakely from comment #18)
> I've started a discussion about changing the SD-6 recommendations.
> 
> One idea that came out of the discussion so far would be to make a
> GCC-specific extension to __has_include. If the has-includes-expression
> finds a file then it could read the first line of the file to look for
> something like:
> 
> #pragma GCC has_include(constant-expression)
> 
> If found, the result of the has-include-expression would be 1 if the
> constant-expression is non-zero, and 0 otherwise.
> 
> Then we could decorate our C++17 headers with:
> 
> #pragma GCC has_include(__cplusplus > 201402L)
> 
> and __has_include would magically give the right answer.

Would that make its way into GCC 7, so we (Qt) could rely on it working at
least for the C++17 headers (C++14 didn't add many/any)?

[Bug rtl-optimization/81194] New: ICE during RTL pass: expand

[marc.mutz at kdab dot com]

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

Bug ID: 81194
   Summary: ICE during RTL pass: expand
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Created attachment 41622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41622=edit
compressed preprocessed source

during RTL pass: expand
In file included from
/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml/private/qv4isel_util_p.h:1:0,
 from
/home/marc/Qt/qt5/qtdeclarative/src/qml/jit/qv4isel_masm_p.h:56,
 from
/home/marc/Qt/qt5/qtdeclarative/src/qml/jit/qv4isel_masm.cpp:40:
/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml/private/../../../../../../../qt5/qtdeclarative/src/qml/compiler/qv4isel_util_p.h:
In member function ‘void QV4::JIT::InstructionSelection::run(int)
[with JITAssembler =
QV4::JIT::Assembler<QV4::JIT::AssemblerTargetConfiguration<JSC::MacroAssemblerARMv7,
(QV4::JIT::TargetOperatingSystemSpecialization)0> >]’:
/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml/private/../../../../../../../qt5/qtdeclarative/src/qml/compiler/qv4isel_util_p.h:215:9:
internal compiler error: Segmentation fault
 switch (s->stmtKind) {
 ^~
0xb21a6f crash_signal
../../gcc/gcc/toplev.c:338
0xb1391c expand_case(gswitch*)
../../gcc/gcc/stmt.c:1157
0x7bab17 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3569
0x7bab17 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3741
0x7bc2bf expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5745
0x7c171e execute
../../gcc/gcc/cfgexpand.c:6354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug rtl-optimization/81194] ICE during RTL pass: expand

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++ :
(reconfigured) ../gcc/configure --prefix=/d/gcc/trunk --enable-checking=release
--enable-languges=c,c++,fortran,lto,objc,obj-c++
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
gcc version 8.0.0 20170623 (experimental) (GCC)

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[marc.mutz at kdab dot com]

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

--- Comment #6 from Marc Mutz  ---
Sorry. Here it comes:

make[2]: Entering directory
'/home/marc/Qt/qt5-build/qtdeclarative/src/qmldevtools'
g++ -c -pipe -Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-c++0x-compat -ffunction-sections -O2 -fPIC -std=c++1z -fvisibility=hidden
-fvisibility-inlines-hidden -fno-exceptions -Wall -W
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-c++0x-compat -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond
-Werror -Wno-error=cpp -Wno-error=deprecated-declarations
-Wno-error=strict-overflow -Wno-error=implicit-fallthrough
-Wno-error=class-memaccess -D_REENTRANT -DWTF_EXPORT_PRIVATE=
-DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportBacktrace=qmlWTFReportBacktrace
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0
-DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0
-DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG -DWTF_EXPORT_PRIVATE=
-DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportBacktrace=qmlWTFReportBacktrace
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0
-DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0
-DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_QMLDEVTOOLS_LIB
-DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB
-I/home/marc/Qt/qt5/qtdeclarative/src/qmldevtools -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/jit
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/assembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/runtime
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler/udis86
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/jsruntime -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/compiler -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/memory -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/jit
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/assembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/runtime
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler/udis86
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/jit -I. -I.generated
-I/home/marc/Qt/qt5-build/qtbase/include
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore/5.10.0
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore/5.10.0/QtCore
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore -I.moc
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ -o .obj/qv4isel_masm.o
/home/marc/Qt/qt5/qtdeclarative/src/qml/jit/qv4isel_masm.cpp

[Bug c++/82193] incorrectly rejects int x; struct { decltype(x) x; } f = {x};

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
Basically: because the other two compilers compile it.

[Bug c++/82193] New: incorrectly rejects int x; struct { decltype(x) x; } f = {x};

[marc.mutz at kdab dot com]

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

Bug ID: 82193
   Summary: incorrectly rejects int x; struct { decltype(x) x; } f
= {x};
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

This code:

  void fun() {
constexpr int x = 42;

constexpr struct {
decltype(x) x;

constexpr auto operator()(int a) const { return a * x; }
} f = {x};
static_assert(f(0) == 0);
static_assert(f(2) == 2*42);
  }

(trying to show how a compiler might expand a lambda [x](int a){return a*x;}),
fails to compile on all GCCs I tested, incl. trunk as installed on godbold,
with the following incomprehensible error message:

6 : :6:21: error: declaration of 'const int fun()x'
[-fpermissive]
 decltype(x) x;
 ^
3 : :3:19: error: changes meaning of 'x' from 'constexpr const int x'
[-fpermissive]
 constexpr int x = 42;
   ^


Clang 4 and MSVC 2017 both compile this code just fine:
https://godbolt.org/g/4L6ULo

The problem is not the constexpr. I only added those to be able to execute the
function call operator without having to run the executable.

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[marc.mutz at kdab dot com]

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

--- Comment #15 from Marc Mutz  ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Marc Mutz from comment #12)
> > Is replacing a matching comment with __attribute__(fallthrough)) so
> > complicated as to make this a wontfix?
> 
> It is not really possible.
> __attribute__((fallthrough)) has precise rules on where it can appear, while
> /* FALLTHRU */ comments, being comments, can appear anywhere.  Especially
> with -Wimplicit-fallthrough=1 when all comments are considered fallthru
> comments...

I don't buy this. You don't need to use the 'official' attribute. You can
invent an internal one, say __attribute__((__replaced_fallthrough_comment)),
which does not have the limitations of [[fallthrough]]. It's just a way to
preserve a comment over the preprocessor stage.

[Bug libstdc++/82716] New: struct/class vs. tuple_element/tuple_size

[marc.mutz at kdab dot com]

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

Bug ID: 82716
   Summary: struct/class vs. tuple_element/tuple_size
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

I'm trying to support the tuple protocol for Qt's QPair:

namespace std {
// these have to be 'class', because MSVC warns about struct/class
mismatch, and
// in the std, they are classes:
template 
class tuple_size<QT_PREPEND_NAMESPACE(QPair)<T1,T2>> : public
std::integral_constant<size_t, 2> {};
template 
class tuple_element<0, QT_PREPEND_NAMESPACE(QPair)<T1, T2>> { public: using
type = T1; };
template 
class tuple_element<1, QT_PREPEND_NAMESPACE(QPair)<T1, T2>> { public: using
type = T2; };
}

I get these warnings from clang:

68 : :68:5: error: 'tuple_size' defined as a class template here but
previously declared as a struct template [-Werror,-Wmismatched-tags]
class tuple_size<~~~> : public std::integral_constant<std::size_t, 2> {};
^
/opt/compiler-explorer/gcc-7.1.0/lib/gcc/x86_64-linux-gnu/7.1.0/../../../../include/c++/7.1.0/utility:88:5:
note: did you mean class here?
struct tuple_size;
^
71 : :71:5: error: 'tuple_element' defined as a class template here but
previously declared as a struct template [-Werror,-Wmismatched-tags]
class tuple_element<I, >
^
/opt/compiler-explorer/gcc-7.1.0/lib/gcc/x86_64-linux-gnu/7.1.0/../../../../include/c++/7.1.0/utility:112:5:
note: did you mean class here?
struct tuple_element;
^
2 errors generated.
Compiler exited with result code 1

Here's a stripped-down example: https://godbolt.org/g/sUZxAQ
Works with -stdlib=libc++: https://godbolt.org/g/bW4u1u

The standard says that tuple_element and tuple_size are struct and continues to
use it as class (http://eel.is/c++draft/tuple.helper), and so does libstdc++,
which means that there's no way to write a tuple_size specialisation that will
avoid the warning.

Expected: libstdc++ recognizes that it may be used with compilers that warn
about struct/class mismatch, picks one of the two, and sticks to it, so one can
at least use #ifdefs to pick which one to use.

[Bug c++/96805] ICE: Segmentation fault in instantiate_template / pop_nested_class()

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
also in gcc version 10.2.1 20200826 (GCC)

[Bug c++/96805] ICE: Segmentation fault in instantiate_template / pop_nested_class()

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/d/gcc/10/libexec/gcc/x86_64-pc-linux-gnu/10.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/d/gcc/10
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion :
(reconfigured) ../gcc/configure --prefix=/d/gcc/10
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20200824 (GCC)

[Bug c++/96805] New: ICE: Segmentation fault in instantiate_template / pop_nested_class()

[marc.mutz at kdab dot com]

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

Bug ID: 96805
   Summary: ICE: Segmentation fault in instantiate_template /
pop_nested_class()
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Created attachment 49134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49134=edit
BZ2-compressed preprocessed source

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96732 looks similar, but this is
on 10.2, not 11...

$ g++ -E -pipe -O2 -fPIC -std=c++2a -fvisibility=hidden
-fvisibility-inlines-hidden -ffunction-sections -fdata-sections -fno-exceptions
-Wall -Wextra -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond
-Wno-stringop-overflow -Wno-format-overflow -Wsuggest-override -D_REENTRANT
-DQT_NO_JAVA_STYLE_ITERATORS -DPCRE2_DISABLE_JIT -DHAVE_CONFIG_H
-DQT_VERSION_STR='"6.0.0"' -DQT_VERSION_MAJOR=6 -DQT_VERSION_MINOR=0
-DQT_VERSION_PATCH=0 -DQT_BOOTSTRAPPED -DQT_NO_CAST_TO_ASCII
-DPCRE2_CODE_UNIT_WIDTH=16 -DQT_NO_FOREACH -DQT_NO_CAST_FROM_ASCII
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_BOOTSTRAP_LIB
-DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_DEPRECATED_WARNINGS_SINCE=0x06
-DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/marc/Qt/qtbase/src/tools/bootstrap -I. -I/home/marc/Qt/qtbase/src/tools
-I/home/marc/Qt/qtbase/src/3rdparty/tinycbor/src
-I/home/marc/Qt/qtbase/src/3rdparty/pcre2/src -I../../../include
-I../../../include/QtCore -I../../../include/QtCore/6.0.0
-I../../../include/QtCore/6.0.0/QtCore -I../../../include/QtXml
-I../../../include/QtXml/6.0.0 -I../../../include/QtXml/6.0.0/QtXml
-I/home/marc/Qt/qtbase/mkspecs/linux-g++ -o qendian.ii
/home/marc/Qt/qtbase/src/corelib/global/qendian.cpp
../../../include/QtCore/../../../qtbase/src/corelib/tools/qarraydataops.h:102:77:
internal compiler error: Segmentation fault
  102 | noexcept(std::is_nothrow_constructible_v>)
  |
^
0xc2ee1f crash_signal
../../gcc/gcc/toplev.c:328
0x6280c5 pop_nested_class()
../../gcc/gcc/cp/class.c:8184
0x738747 instantiate_template_1
../../gcc/gcc/cp/pt.c:20853
0x733694 instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:20908
0x733694 instantiate_alias_template
../../gcc/gcc/cp/pt.c:20946
0x733694 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:15147
0x739b0f lookup_template_class_1
../../gcc/gcc/cp/pt.c:9853
0x73a1ec lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:10119
0x756b3d finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:3408
0x6fe15d cp_parser_template_id
../../gcc/gcc/cp/parser.c:16739
0x6fe3cc cp_parser_class_name
../../gcc/gcc/cp/parser.c:23713
0x6fb101 cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:6776
0x6fb101 cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6458
0x702706 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:18134
0x6e93ed cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:17792
0x6fc9a9 cp_parser_type_specifier_seq
../../gcc/gcc/cp/parser.c:22402
0x6f6f34 cp_parser_type_id_1
../../gcc/gcc/cp/parser.c:22219
0x6f9473 cp_parser_template_type_arg
../../gcc/gcc/cp/parser.c:22310
0x6fcb2f cp_parser_template_argument
../../gcc/gcc/cp/parser.c:17189
0x6fcb2f cp_parser_template_argument_list
../../gcc/gcc/cp/parser.c:17100
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.

[Bug libstdc++/101406] poor codegen for shared_ptr copy & destory, compared to boost::shared_ptr and libc++'s implementation

[marc.mutz at kdab dot com via Gcc-bugs]

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

--- Comment #1 from Marc Mutz  ---
Comparison to the other two major standard library implementations:
https://godbolt.org/z/crPo44rxo

[Bug libstdc++/101406] poor codegen for shared_ptr copy & destory, compared to boost::shared_ptr and libc++'s implementation

[marc.mutz at kdab dot com via Gcc-bugs]

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

Marc Mutz  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #3 from Marc Mutz  ---
Ok, it doesn't seem to affect execution speed much, but oh my, the code size :/

[Bug libstdc++/101406] New: shared_ptr in _S_atomic mode still uses __atomic_add_dispatch()

[marc.mutz at kdab dot com via Gcc-bugs]

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

Bug ID: 101406
   Summary: shared_ptr in _S_atomic mode still uses
__atomic_add_dispatch()
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Consider

 // https://godbolt.org/z/efTW6MoEh
 void test_copy(const std::shared_ptr )
 { auto copy = sp; }

vs.

 // https://godbolt.org/z/3aoGq1f9P
 void test_copy(const boost::shared_ptr )
 { auto copy = sp; }

In the first cast, over 70 lines of assembler are emitted, in the second,
around 30. This seems to be in large part because in
_Sp_counted_base::_M_add_ref_copy(), you're using __atomic_add_dispatch() even
if _Lp is _S_atomic. It seems to me that a specialisation of this function
template for _S_atomic calling just __atomic_add() is missing:
https://godbolt.org/z/crPz9hGe7

Probably same for the deref case, too.