[Bug libstdc++/113159] More robust std::sort for silly comparator functions

[jengelh at inai dot de via Gcc-bugs]

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

Jan Engelhardt  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #4 from Jan Engelhardt  ---
>And in upcoming Glibc-2.39 there will be a major reimplementation of qsort

Even so, a recent commit strongly suggests that sticking to array bounds
remains important:

commit b9390ba93676c4b1e87e218af5e7e4bb596312ac
Author: Florian Weimer 
Date:   Mon Dec 4 06:35:56 2023 +0100

stdlib: Fix array bounds protection in insertion sort phase of qsort

[Bug libstdc++/113159] New: More robust std::sort for silly comparator functions

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 113159
   Summary: More robust std::sort for silly comparator functions
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Type: enhancement
Version: 13.2.1 20231130 [revision 741743c028dc00f27b9c8b1d5211c1f602f2fddd]
(SUSE Linux) x86_64

Input:

#include 
#include 
#include 
int main()
{
std::vector v(256);
sort(v.begin(), v.end(), [](int a, int b) -> bool { return rand() & 1;
});
// alternatively, { return true; }
//
// -D_GLIBCXX_DEBUG can diagnose obviously-broken cases like
// {return true;}, but won't necessarily for
// rand()&1 at all times.
}

Observed output:



Expected output:

Though I recognize this is undefined behavior, I would love to see the
implementation not run into an out-of-bounds access. glibc's qsort for example
stays within the array bounds even if given a buggy comparator like that.

[Bug sanitizer/112100] New: ubsan: misses UB when modifying std::string's trailing \0

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 112100
   Summary: ubsan: misses UB when modifying std::string's trailing
\0
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
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: ---

Input:

#include 
int main()
{
std::string s="fooo";
s[s.size()] = 0xff;
}

Observed:
$  g++ x.cpp -v -Wall -ggdb3 -fsanitize=undefined,address && ./a.out
gcc version 13.2.1 20230912 [revision b96e66fd4ef3e36983969fb8cdd1956f551a074b]
(SUSE Linux) 

(no runtime output by executable)

Expected:

==55843==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xsomething

https://eel.is/c++draft/string.access specifies the modification of the NUL
char's position to values other than \0 is UB, so it should warn about this.

[Bug c++/110866] New: No UDC lookup with va_arg

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 110866
   Summary: No UDC lookup with va_arg
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Bugtype: enhancement
Version: 13.1.1 20230720 [revision 9aac37ab8a7b919a89c6d64bc7107a8436996e93]
(SUSE Linux)

Input
=

#include 
struct va_wrap {
~va_wrap() { if (engaged) va_end(vl); }
va_list vl;
operator va_list &() { return vl; }
bool engaged = false;
};
void f(const char *fmt, ...)
{
va_wrap va;
va_start(va, fmt); va.engaged = 1;
va_arg(va, int);
if (0)
va_copy(va, va);
if (0)
va_end(va);
}
int main()
{
f("", 42);
}


Observed output
===
$ g++ -c x.cpp
x.cpp:12:20: error: first argument to ‘va_arg’ not of type ‘va_list’


Expected output
===
Succeed.

If va_start and va_end can take a va_wrap and have the user-defined conversion
operator invoked, surely va_arg could do so too.

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #52 from Jan Engelhardt  ---
>This is useful for functions where not checking the
>result is either a security problem or always a bug, such as
>'realloc'.

always? reall..y..oc?

  void *x = malloc(1);
  realloc(x, 0);

[Bug c++/109020] New: Lambdas have different DWARF signature than the function they are in

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 109020
   Summary: Lambdas have different DWARF signature than the
function they are in
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
CC: rguenther at suse dot de
  Target Milestone: ---

== Input ==

$ cat x.cpp
#include 
static void ff(uint64_t b) { [&](){}(); }
int main() { ff(0); }
$ g++ x.cpp -g
$ gdb a.out
(gdb) b ff

== Observed ==

ff(uint64_t)
ff(unsigned long)::{lambda()#1}::operator()() const

== Expectation ==

ff(unsigned long)
ff(unsigned long)::{lambda()#1}::operator()() const

[or]

ff(uint64_t)
ff(uint64_t)::{lambda()#1}::operator()() const

== Additional info ==

I am filing this for gcc since I believe this might have to do with DWARF
generation rather than gdb being funky.

Using built-in specs.
COLLECT_GCC=g++-13
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit,rust,m2
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --enable-offload-defaulted
--without-cuda-driver --enable-host-shared --enable-checking=release
--disable-werror --with-gxx-include-dir=/usr/include/c++/13
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-13 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230127 (experimental) [revision
ca8fb0096713a8477614ef874f16ba5bf16c48bc] (SUSE Linux)

[Bug tree-optimization/107895] mt19937 bad performance on LP64

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #1 from Jan Engelhardt  ---
clang-15.0.5+gnustdlibc timing distribution.

-m32  -m64
mt19937  6.0   4.7
mt19937_64   9.2   4.7

[Bug tree-optimization/107895] New: mt19937 bad performance on LP64

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 107895
   Summary: mt19937 bad performance on LP64
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input
=

#include 
#include 
static std::mt19937 rng;
int main() {
for (size_t j = 0; j < 0x8000; ++j) {
uint32_t numbers[65536];
for (size_t i = 0; i < std::size(numbers); ++i)
numbers[i] = rng();
// ensure number generation is not all optimized away
write(STDOUT_FILENO, numbers, sizeof(numbers));
}
}


Observed


Target: x86_64-suse-linux
gcc version 12.2.1 20221020 [revision 0aaef83351473e8f4eb774f8f999bbe87a4866d7]
(SUSE Linux)

$ g++ x.cpp -O2 && time ./a.out >/dev/zero

  -m32-m64
===  =  ==
std::mt19937  3.9s   11.5s
std::mt19937_64  14.0s   11.6s
===  =  ==
error ±0.1s

With -ftree-loop-if-convert [Bug #80520], but still not at -m32 levels:

+-ftree-  -m32-m64
===  =  ==
std::mt19937  3.9s5.2s
std::mt19937_64  14.0s5.4s
===  =  ==
error ±0.1s


Expected


Expected to see <= 4.7s on -m64 at all times. (3.9 + ~20% margin for wider
transfers CPU<->caches/RAM)

The -m64 versions should have somewhat equal runtime or faster runtime (because
more registers, more opportunities); concerns like https://gmplib.org/32vs64
apply to old CPUs, but I do not think it's indicative of how contemporary
x86_64 systems perform.


Additional information
==

CPUs:
 "11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz"
[fam 6 model 140 stepping 1 microcode 0xa4] and
 "AMD Ryzen 7 3700X 8-Core Processor"
[fam 23 model 113 stepping 0 microcode 0x8701013]
(about 3.0 and 10.2 seconds runtime, respectively)

[Bug sanitizer/103930] asan intercepts fail if target library is only loaded (indirectly) through dlopen (e.g. plugin)

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #2 from Jan Engelhardt  ---
Subissue a) "the crash output is completely useless" seems to have been
addressed in the past already; I observe in gcc 12 that

Found plugin run function: 0x7fecaa0e01a0
AddressSanitizer:DEADLYSIGNAL
=
==75097==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x bp 0x7ffccfe3f0b0 sp 0x7ffccfe3f0a8 T0)
==75097==Hint: pc points to the zero page.
==75097==The signal is caused by a READ memory access.
==75097==Hint: address points to the zero page.
#0 0x0  ()
#1 0x4010ea in main main.c:10
#2 0x7feca982c5af in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58

(But yeah, I remember a time when calling null pointer functions often meant no
usable stack trace, even in gdb. Not sure what that was about.)

[Bug sanitizer/103930] asan intercepts fail if target library is only loaded (indirectly) through dlopen (e.g. plugin)

[jengelh at inai dot de via Gcc-bugs]

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

Jan Engelhardt  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #1 from Jan Engelhardt  ---
gcc version 12.2.1 20221020 [revision 0aaef83351473e8f4eb774f8f999bbe87a4866d7]
(SUSE Linux) 

Thread 5 "a.out" hit Breakpoint 2, __interceptor_crypt (key=0x60207050 "",
salt=0x60b15800 "") at
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:9981
9981INTERCEPTOR(char *, crypt, char *key, char *salt) {
(gdb) n
9983  COMMON_INTERCEPTOR_ENTER(ctx, crypt, key, salt);
(gdb) 
9984  COMMON_INTERCEPTOR_READ_RANGE(ctx, key, internal_strlen(key) + 1);
(gdb) 
9985  COMMON_INTERCEPTOR_READ_RANGE(ctx, salt, internal_strlen(salt) + 1);
(gdb) 
9986  char *res = REAL(crypt)(key, salt);
(gdb) disas
…
=> 0x77862cdd <+125>:   lea-0x28(%rbp),%rsp
   0x77862ce1 <+129>:   mov%r12,%rsi
   0x77862ce4 <+132>:   mov%rbx,%rdi
   0x77862ce7 <+135>:   pop%rbx
   0x77862ce8 <+136>:   pop%r12
   0x77862cea <+138>:   pop%r13
   0x77862cec <+140>:   pop%r14
   0x77862cee <+142>:   pop%r15
   0x77862cf0 <+144>:   pop%rbp
   0x77862cf1 <+145>:   jmp*0xeade1(%rip)# 0x7794dad8
<_ZN14__interception10real_cryptE>
…
(gdb) p _ZN14__interception10real_cryptE
$1 = (crypt_type) 0x0

[Bug c/106195] New: RFE: Split -msse into -msse and -fenable-intrinsics

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 106195
   Summary: RFE: Split -msse into -msse and -fenable-intrinsics
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Some libraries may use cpuid to runtime-test for SSE availability, yet their
authors may, intentionally or not, cause a profound lack of #ifdef __SSE__
guards around sections that do use _mm_* functions. The problem is not tied to
SSE specifically; any CPU extension may be affected. Consider this source code:


#include 
#include 
#include 
struct ADLConfig {
int cc=6,eid=0,bank=14,vol=0,pcm=0,pan=1,ban2k=false;
std::string cbank;
};
ADLConfig adlConfig; // generates MOVAPS under -O2 -msse
int main()
{
long x=0,a=0,b=0,c=0,d=0;
__cpuid(x,a,b,c,d);
if (x) {
__m128 a,b;
_mm_add_ss(a,b);
} else {
// 
}
}


Without -msse, compilation of the snippet fails.
With -msse, the program builds but then won't run on SSE-less CPUs, because SSE
is emitted in a place where it's undesired - basically the only places where it
*is* desired is the _mm calls. There should be a better option than to find and
edit all _mm callsites and add #ifdef __SSE__.
If only I could tell the compiler "-mno-sse -fenable-sse-intrinsics" or so..

[Bug sanitizer/104929] New: UBSAN: false positive with sprintf

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 104929
   Summary: UBSAN: false positive with sprintf
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
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: ---

// g++ -Wall -fsanitize=undefined -O2 -c t.cpp
#include 
size_t fun(char *s)
{
sprintf(s, " ");
return __builtin_strlen(s);
}

Observed:
t.cpp: In function ‘size_t fun(char*)’:
t.cpp:5:16: warning: null destination pointer [-Wformat-overflow=]
5 | sprintf(s, " ");
//gcc version 11.2.1 20220103 [revision
d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6] (SUSE Linux), Linux amd64 glibc-2.35

Expected:
Don't warn(?)

[Bug c++/104806] New: Weird error message: did you mean "__dt "

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 104806
   Summary: Weird error message: did you mean "__dt "
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input
=
struct S{};
int main() { S s; s.__d; }

Observed

g++ -c x.cpp
gcc version 11.2.1 20220103 [revision d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6]
(SUSE Linux) 

x.cpp: In function ‘int main()’:
x.cpp:2:21: error: ‘struct S’ has no member named ‘__d’; did you mean ‘__dt ’?
2 | int main() { S s; s.__d; }
  | ^~~
  | __dt 

Expected

x.cpp: did you mean "__dt"?

That is, without the extra space. In addition, where does __dt come from? I
have not even included anything. This in the source code git repo looks like
the culprit.

gcc/cp/decl.cc:{"__dt ", _identifier, cik_dtor},

[Bug c++/104437] Constructor of templated class with full instantiation name rejected in -std=c++2a

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #1 from Jan Engelhardt  ---
Due to http://eel.is/c++draft/diff.cpp17.class#2 , it's probably going to be
(b).
However, adding inline, i.e.

  inline S() {}

makes it compile again, so that case.. might be improperly rejected.

[Bug c++/104437] New: Constructor of templated class with full instantiation name rejected in -std=c++2a

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 104437
   Summary: Constructor of templated class with full instantiation
name rejected in -std=c++2a
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input
=

struct K {};
template struct S : Base {
S() {}
};
int main() { S s; }

Output
==
$ g++ -c -std=c++2a x.cpp (-v)
gcc version 11.2.1 20220103 [revision d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6]
(SUSE Linux) 
x.cpp:3:17: error: expected unqualified-id before ‘)’ token
3 | S() {}

Expected output
===

One of two options.

(a) succeed, as it does with g++ -std=c++17 (clang13 also accepts it under both
-std=).
(b) improve the error message to hint that the current instantiation of a class
template is no longer accepted in the new standard.

[Bug c++/103923] New: is_invocable inexplicably fails

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 103923
   Summary: is_invocable inexplicably fails
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input:

#include 
#include 
#include 
#include 
struct T {
struct K {
bool operator==(const K &) const { return 0; }
bool operator<(const K &) const { return 0; }
};
struct H {
auto operator()(const K &) const { return 0; }
};
std::unordered_map m;
};
int main()
{
printf("%d\n", std::is_invocable_v);
printf("%d\n", std::is_invocable_v);
//T().m[T::K()]; // for extra fun
}

Output:

GNU C++17 (SUSE Linux) version 11.2.1 20211124 [revision
7510c23c1ec53aa4a62705f0384079661342ff7b] (x86_64-suse-linux)
compiled by GNU C version 11.2.1 20211124 [revision
7510c23c1ec53aa4a62705f0384079661342ff7b], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP

0
1

Expected output:

1
1

Expectation based on it being possible to invoke on a const H &:
{ T::H h; const T::H  = h; hh(T::K()); }

[Bug tree-optimization/103733] Missed optimization: defaulted op== for trivially comparable types worse than memcmp

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #4 from Jan Engelhardt  ---
Is there a way to convey that it is safe to access every and all parts of S,
e.g. by initializing S::b at construction time?

[Bug tree-optimization/103733] Missed optimization: defaulted op== for trivially comparable types worse than memcmp

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #2 from Jan Engelhardt  ---
== New input ==
$ cat x.cpp
struct S {
char b[16];
#if __cplusplus >= 202000L
bool operator==(const S &) const = default;
#else
inline bool operator==(const S ) const { return __builtin_memcmp(b,
o.b, sizeof(b)); }
#endif
};
bool fff(const S , const S ) { return a == b; }

== Observed ==
$ ./xgcc -B. -c /dev/shm/x.cpp -O2 && objdump -d x.o
 <_Z3fffRK1SS1_>: C++17
   0:   48 8b 17mov(%rdi),%rdx
   3:   48 8b 47 08 mov0x8(%rdi),%rax
   7:   48 33 16xor(%rsi),%rdx
   a:   48 33 46 08 xor0x8(%rsi),%rax
   e:   48 09 d0or %rdx,%rax
  11:   0f 95 c0setne  %al
  14:   c3  ret

 <_Z3fffRK1SS1_>: C++20
   0:   31 c0   xor%eax,%eax
   2:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
   8:   0f b6 14 06 movzbl (%rsi,%rax,1),%edx
   c:   38 14 07cmp%dl,(%rdi,%rax,1)
   f:   75 17   jne28 <_Z3fffRK1SS1_+0x28>
  11:   48 83 c0 01 add$0x1,%rax
  15:   48 83 f8 10 cmp$0x10,%rax
  19:   75 ed   jne8 <_Z3fffRK1SS1_+0x8>
  1b:   b8 01 00 00 00  mov$0x1,%eax
  20:   c3  ret
  21:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
  28:   31 c0   xor%eax,%eax
  2a:   c3  ret

[Bug tree-optimization/103733] New: Missed optimization: defaulted op== for trivially comparable types worse than memcmp

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 103733
   Summary: Missed optimization: defaulted op== for trivially
comparable types worse than memcmp
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

== Input ==
struct S {
char b[16];
#if __cplusplus >= 202000L
bool operator==(const S &) const = default;
#else
inline bool operator==(const S ) const { return
__builtin_memcpy(const_cast(b), o.b, sizeof(b)); }
#endif
};
bool fff(const S , const S ) { return a == b; }


== Observed ==
gcc version 12.0.0 20211214 973f6aedeb6489a9fdc7aeceaed0514348ee1e1a x86_64

$ ./xgcc -B. -c x.cpp -O2 -std=c++20 && objdump -d x.o
 <_Z3fffRK1SS1_>:
   0:   31 c0   xor%eax,%eax
   2:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
   8:   0f b6 14 06 movzbl (%rsi,%rax,1),%edx
   c:   38 14 07cmp%dl,(%rdi,%rax,1)
   f:   75 17   jne28 <_Z3fffRK1SS1_+0x28>
  11:   48 83 c0 01 add$0x1,%rax
  15:   48 83 f8 10 cmp$0x10,%rax
  19:   75 ed   jne8 <_Z3fffRK1SS1_+0x8>
  1b:   b8 01 00 00 00  mov$0x1,%eax
  20:   c3  ret
  21:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
  28:   31 c0   xor%eax,%eax
  2a:   c3  ret  

== Expected ==
Expected the same result as when -std=c++17/memcmp is used.

 <_Z3fffRK1SS1_>:
   0:   f3 0f 6f 06 movdqu (%rsi),%xmm0
   4:   b8 01 00 00 00  mov$0x1,%eax
   9:   0f 11 07movups %xmm0,(%rdi)
   c:   c3  ret

[Bug rtl-optimization/103710] Missed optimization: common bit prefix/suffixes of multiple values

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #2 from Jan Engelhardt  ---
Created attachment 52001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52001=edit
testcase

[Bug rtl-optimization/103710] New: Missed optimization: common bit prefix/suffixes of multiple values

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 103710
   Summary: Missed optimization: common bit prefix/suffixes of
multiple values
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Environment:
» ./xgcc -v ...
Reading specs from /home/jengelh/repos/gcc/host-x86_64-pc-linux-gnu/gcc/specs
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211214 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-B'
'/home/jengelh/repos/gcc/host-x86_64-pc-linux-gnu/gcc' '-D' 'noexcept=' '-c'
'-O2' '-mtune=generic' '-march=x86-64'
GNU C17 (GCC) version 12.0.0 20211214 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.2.1 20211124 [revision
7510c23c1ec53aa4a62705f0384079661342ff7b], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096


Input: attachment #0
Observed output:

$ ./xgcc -B. -x c++ -c -O2 t.cpp && readelf -a t.o | grep fct
 3: 54 FUNCGLOBAL DEFAULT1 _Z4fct0j
 4: 004054 FUNCGLOBAL DEFAULT1 _Z4fct4j
 5: 008054 FUNCGLOBAL DEFAULT1 _Z4fct8j
 6: 00c054 FUNCGLOBAL DEFAULT1 _Z5fct12j
 7: 010054 FUNCGLOBAL DEFAULT1 _Z5fct16j
 8: 014054 FUNCGLOBAL DEFAULT1 _Z5fct20j
 9: 018038 FUNCGLOBAL DEFAULT1 _Z5fct24j
10: 01b032 FUNCGLOBAL DEFAULT1 _Z5fct25j
11: 01d035 FUNCGLOBAL DEFAULT1 _Z6fctmaxj

Desired output:

Provided I made no mistake in the equivalency of all fct functions, the fct
functions should, preferably, all compile to the same machine code.

[Bug tree-optimization/103535] New: [missed optimization] remainder-of-2 with subtract-1

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 103535
   Summary: [missed optimization] remainder-of-2 with subtract-1
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux)  x86_64

== input ==
unsigned int fff(unsigned int p)
{
// equivalent to  return p & ~1;
if (p % 2 != 0)
--p;
return p;
}

== Observed output ==
» gcc -O2 -c x.cpp; objdump -Mintel -d x.o
   0:   89 fa   movedx,edi
   2:   89 f8   moveax,edi
   4:   83 e2 01andedx,0x1
   7:   83 fa 01cmpedx,0x1
   a:   83 d0 ffadceax,0x
   d:   c3  ret

== Expected output ==
   0:   89 f8   moveax,edi
   2:   83 e0 feandeax,0xfffe
   5:   c3  ret

[Bug driver/102957] New: [riscv64] ICE on bogus -march value

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 102957
   Summary: [riscv64] ICE on bogus -march value
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/riscv64-suse-linux/11/lto-wrapper
Target: riscv64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit --enable-host-shared
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --program-suffix=-11
--without-system-libunwind --disable-multilib --enable-link-mutex
--build=riscv64-suse-linux --host=riscv64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux) 


> g++ -v -march=rv64gzb
Using built-in specs.
g++: internal compiler error: in multi_letter_subset_rank, at
common/config/riscv/riscv-common.c:200
Please submit a full bug report,


Yeah, zb is not valid (should be zbb), but should rather yield a normal message
than an ICE.

[Bug tree-optimization/102929] New: [missed optimization] two ways to rounddown-to-next-multiple

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 102929
   Summary: [missed optimization] two ways to
rounddown-to-next-multiple
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input
=
unsigned long calc(unsigned long x, unsigned long y)
{
return x/y*y;
}
unsigned long calc2(unsigned long x, unsigned long y)
{
return x - x % y;
}

Observed

» g++ -O3 -c x.c; objdump -Mintel -d x.o
gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux) x86_64
 <_Z4calcmm>:
   0:   48 89 f8movrax,rdi
   3:   31 d2   xoredx,edx
   5:   48 f7 f6divrsi
   8:   48 0f af c6 imul   rax,rsi
   c:   c3  ret
   d:   0f 1f 00nopDWORD PTR [rax]

0010 <_Z5calc2mm>:
  10:   48 89 f8movrax,rdi
  13:   31 d2   xoredx,edx
  15:   48 f7 f6divrsi
  18:   48 89 f8movrax,rdi
  1b:   48 29 d0subrax,rdx
  1e:   c3  ret

Expected

I do not see any obvious differences in the outcome of the two C functions, so
I would expect that, ideally, both should lead to the same asm. (Either by
making calc use div-mov-sub, or by making calc2 using div-imul; whichever
happens to be determined more beneficial as per the machine descriptions).

[Bug c++/102877] New: missed optimization: memcpy produces lots more asm than otherwise

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 102877
   Summary: missed optimization: memcpy produces lots more asm
than otherwise
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input (C++)
===
struct GLOBCNT { unsigned char ab[6]; };
unsigned long long gc_to_num(GLOBCNT gc)
{
unsigned long long value;
auto v = reinterpret_cast();
v[0] = 0;
v[1] = 0;
#ifdef WITH_MEMCPY
__builtin_memcpy(v + 2, gc.ab, 6);
#else
v[2] = gc.ab[0]; v[3] = gc.ab[1]; v[4] = gc.ab[2];
v[5] = gc.ab[3]; v[6] = gc.ab[4]; v[7] = gc.ab[5];
#endif
if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
value = __builtin_bswap64(value);
return value;
}

I hope this is UB-free.


Observed behavior
=
The use of memcpy/__builtin_memcpy produces a function with 28
instructions/0x5c bytes long.

► g++ -O2 -c t3.cpp -Wall -DWITH_MEMCPY -v
Target: x86_64-suse-linux
gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux)

► objdump -Mintel -d t3.o
 <_Z9gc_to_num7GLOBCNT>:
   0:   89 f8   moveax,edi
   2:   89 f9   movecx,edi
   4:   89 fa   movedx,edi
   6:   44 0f b6 c7 movzx  r8d,dil
   a:   c1 e9 10shrecx,0x10
   d:   0f b6 f4movzx  esi,ah
  ...
  5c:   c3  ret


Expected behavior
=
► g++ -O2 -c t3.cpp -Wall -UWITH_MEMCPY
► objdump -Mintel -d t3.o
 <_Z9gc_to_num7GLOBCNT>:
   0:   0f b7 c7movzx  eax,di
   3:   48 c1 ef 10 shrrdi,0x10
   7:   48 c1 e7 20 shlrdi,0x20
   b:   48 c1 e0 10 shlrax,0x10
   f:   48 09 f8or rax,rdi
  12:   48 0f c8bswap  rax
  15:   c3  ret


Other notes
===
In a twist, clang 13.0.0 produces the short version for memcpy (even shorter
than gcc), and produces a long version for non-memcpy case (even longer than
gcc).

► clang++ -O2 -c t3.cpp -Wall -DWITH_MEMCPY; objdump -Mintel -d t3.o
 <_Z9gc_to_num7GLOBCNT>:
   0:   48 89 f8movrax,rdi
   3:   48 c1 e0 10 shlrax,0x10
   7:   48 0f c8bswap  rax
   a:   c3  ret

► clang++ -O2 -c t3.cpp -Wall -UWITH_MEMCPY; objdump -Mintel -d t3.o
 <_Z9gc_to_num7GLOBCNT>:
   0:   48 89 f8movrax,rdi
   3:   48 b9 ff ff ff ff ffmovabs rcx,0x
   a:   ff 00 00 
 ...
  6c:   c3  ret

[Bug libstdc++/102839] New: filesystem::path::wstring runs in C locale / practically always throws

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 102839
   Summary: filesystem::path::wstring runs in C locale /
practically always throws
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

► cat x.cpp
#include 
#include 
#include 
namespace fs = std::filesystem;
int main()
{
const char localeName[] = "ja_JP.UTF-8";
std::setlocale(LC_ALL, localeName);
std::locale::global(std::locale(localeName));
fs::path p(u8"壊した");
std::wcout << p.wstring() << L'\n';
}
 g++ -v x.cpp
Using built-in specs.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/11/defaults.spec
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux) 

► ./a.out 
terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: Cannot convert character sequence: Invalid or
incomplete multibyte or wide character
Aborted (core dumped)

Single-stepping through a -ggdb3 build reveals these code fragments in
libstdc++ which suggest that codecvt<> always operates in C locale:

(x.cpp)
step into
<< p.wstring() <<

leads to

#0  0x77e58f09 in std::codecvt::codecvt
(this=0x7fffdb30, __refs=0) at
../../../../../libstdc++-v3/src/c++98/codecvt.cc:118
116 #ifdef _GLIBCXX_USE_WCHAR_T
117   // codecvt required specialization
118   codecvt::
119   codecvt(size_t __refs)
120   : __codecvt_abstract_base(__refs),
*121   _M_c_locale_codecvt(_S_get_c_locale())
122   { }

std::codecvt::do_max_length (this=0x7fffdb50)
at codecvt_members.cc:220
217   int
218   codecvt::
219   do_max_length() const throw()
220   {
221 #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
*222 __c_locale __old = __uselocale(_M_c_locale_codecvt);
223 #endif
224 // XXX Probably wrong for stateful encodings.
225 int __ret = MB_CUR_MAX;
226 #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
227 __uselocale(__old);
228 #endif
229 return __ret;
230   }

[Bug tree-optimization/102795] New: RFE: recognize !! vs branch similarity better

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 102795
   Summary: RFE: recognize !! vs branch similarity better
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input
=

unsigned long p1(unsigned long x)
{
return x - x / 10 - !!(x % 10);
}
unsigned long p2(unsigned long x)
{
if (x % 10 == 0)
return x - x / 10;
return x - x / 10 - 1;
}
unsigned long p3(unsigned long x)
{
unsigned long z = x - x / 10;
if (x % 10)
--z;
return z;
}

Outcome
===

► ./host-x86_64-pc-linux-gnu/gcc/xg++ -B ./host-x86_64-pc-linux-gnu/gcc -c -O3
-v t.cpp
GNU C++17 (GCC) version 12.0.0 20211016 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.2.1 20210816 [revision
056e324ce46a7924b5cf10f61010cf9dd2ca10e9], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

► objdump -Mintel -d t.o
 <_Z2p1m>:
...
  24:   0f 95 c2setne  dl
  27:   0f b6 d2movzx  edx,dl
  2a:   48 29 d0subrax,rdx
...

0030 <_Z2p2m>:
...
  4f:   48 29 d6subrsi,rdx
  52:   48 29 d0subrax,rdx
  55:   48 01 c9addrcx,rcx
  58:   48 39 cfcmprdi,rcx
  5b:   48 0f 44 c6 cmove  rax,rsi
...

0060 <_Z2p3m>:
...
  81:   48 29 d7subrdi,rdx
  84:   48 83 ff 01 cmprdi,0x1
  88:   48 83 d0 ff adcrax,0x
...


Expected outcome


I would have hoped that the optimizer were able to reduce p1, p2 and p3 to the
same asm.

[Bug c/101705] Missed optimization opportunity when copying lots of bitfields

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #2 from Jan Engelhardt  ---
Created attachment 51229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51229=edit
testcase, 2.c

[Bug c/101705] Missed optimization opportunity when copying lots of bitfields

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #1 from Jan Engelhardt  ---
Created attachment 51228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51228=edit
testcase, 1.c

[Bug c/101705] New: Missed optimization opportunity when copying lots of bitfields

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 101705
   Summary: Missed optimization opportunity when copying lots of
bitfields
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Using gcc-11.1.1 [revision 62bbb113ae68a7e724255e17143520735bcb9ec9], I observe
that gcc is able to recognize and combine lots of "structb->member =
structa->member" assignments into SIMD instructions. However, this only works
as long as "member" has exactly 8*n bits. It would appear gcc is not smart
enough to consider smaller entities (if and when they add up to multiples of 8
or 64).

Observed

[On x86_64]

»gcc -O3 -c 1.c; gcc -O3 -c 2.c
»objdump -d 1.o
   0:   f3 0f 6f 3e movdqu (%rsi),%xmm7
...
»objdump -d 2.o
   0:   0f b6 16movzbl (%rsi),%edx
   3:   0f b6 07movzbl (%rdi),%eax
   6:   83 e2 01and$0x1,%edx
   9:   83 e0 feand$0xfffe,%eax
   c:   09 d0   or %edx,%eax
   e:   88 07   mov%al,(%rdi)
  10:   0f b6 16movzbl (%rsi),%edx
  13:   83 e0 fdand$0xfffd,%eax
  16:   83 e2 02and$0x2,%edx
  19:   09 d0   or %edx,%eax
  1b:   88 07   mov%al,(%rdi)
...

Expected

Emit some movdqu/movups even for 2.c.

Other info
==
gcc version 11.1.1 20210625 [revision 62bbb113ae68a7e724255e17143520735bcb9ec9]
(SUSE Linux) &
gcc version 7.5.0 (SUSE Linux)

[Bug c++/100386] New: Not all constant brace-init-lists receive symbols

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 100386
   Summary: Not all constant brace-init-lists receive symbols
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input:

```
#include 
#include 
void f(int x) { printf("%d", x); }
void foo(const std::initializer_list ) { for (auto y : x) f(y); }
int main()
{
for (auto x : {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15})
f(x);
foo({
1,2,3,4,5,6,7,8,9,2,1,3,4,5,6,7,8,9,3,2,1,4,5,6,7,8,9,5,4,3,
1,2,3,4,5,6,7,8,9,2,1,3,4,5,6,7,8,9,3,2,1,4,5,6,7,8,9,5,4,3,
1,2,3,4,5,6,7,8,9,2,1,3,4,5,6,7,8,9,3,2,1,4,5,6,7,8,9,5,4,3,
});
}
```

Build and objdump:

```
$ gcc -v -O2 -g x.cpp
Target: x86_64-suse-linux
…
gcc version 10.3.0 (SUSE Linux/Tumbleweed)

$ objdump -d a.out
…
00401040 :
  401040:   53  push   rbx
  401041:   be 01 00 00 00  movesi,0x1
  401046:   bb a0 21 40 00  movebx,0x4021a0
  40104b:   48 81 ec 80 01 00 00subrsp,0x180
  401052:   eb 06   jmp40105a 
  401054:   0f 1f 40 00 nopDWORD PTR [rax+0x0]
  401058:   8b 33   movesi,DWORD PTR [rbx]
  40105a:   bf 04 20 40 00  movedi,0x402004
  40105f:   31 c0   xoreax,eax
  401061:   48 83 c3 04 addrbx,0x4
  401065:   e8 c6 ff ff ff  call   401030 
  40106a:   48 81 fb dc 21 40 00cmprbx,0x4021dc
  401071:   75 e5   jne401058 
  401073:   48 8d 44 24 10  learax,[rsp+0x10]
  401078:   48 8d 7c 24 10  leardi,[rsp+0x10]
  40107d:   be 20 20 40 00  movesi,0x402020
  401082:   b9 2d 00 00 00  movecx,0x2d
  401087:   f3 48 a5rep movs QWORD PTR es:[rdi],QWORD PTR
ds:[rsi]
…
```

Observed output:

```
$ nm a.out | sort
…
00402000 R _IO_stdin_used
004021a0 r C.0.0
…
```

Expected output:

```
$ nm a.out
…
00402000 R _IO_stdin_used
00402020 r C.something.something
004021a0 r C.0.0
…
```

[Bug c++/100215] New: Improve text of -Wmaybe-uninitialized references

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 100215
   Summary: Improve text of -Wmaybe-uninitialized references
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Request for enhancements on a particular warning message emitted for shoddy
code.

Input:

```
#include 
#include 
struct C {
C() = default;
C(C &) { memcpy(bar, o.bar, sizeof(bar)); }
int foo = -1;
char bar[1024];
};
int main()
{
C z;
std::list().push_back(std::move(z));
}
```

Command & observed output:

```
$ g++ -v
gcc version 10.3.0 (SUSE Linux) 

$ g++ test.cpp -O2 -Wall
t2.cpp:5:19: warning: ‘*((void*)& z +4)’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
5 |  C(C &) { memcpy(bar, o.bar, sizeof(bar)); }
  | ~~^
```

The warning references the original variable name, and the caret is placed in a
somewhat arbitrary position.

Expected output:

```
t2.cpp:5:19: warning: ‘o.bar’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
5 |  C(C &) { memcpy(bar, o.bar, sizeof(bar)); }
  | ^~~
```

- granted, z+4 is a result of the optimizer; it would be nice if it could show
o+4 though
- more on that, z+4/o+4 could be shown as z.bar/o.bar
- caret be adjusted accordingly to point to the 2nd argument of memcpy

[Bug tree-optimization/99383] New: No tree-switch-conversion under PIC

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 99383
   Summary: No tree-switch-conversion under PIC
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

== Input source ==
enum {
itm01, itm02, itm03, itm04, itm05, itm06, itm07, itm08, itm09, itm0A, itm0B,
itm0C, itm0D, itm0E, itm0F, itm10,
};
#define E(s) case s: return #s;
const char *r2i(unsigned int i) {
switch (i) {
E(itm01) E(itm02) E(itm03) E(itm04) E(itm05) E(itm06) E(itm07)
E(itm08) E(itm09) E(itm10)
}
return "";
}


== Expected output ==

» g++-11 -v x.cpp -c -O2
» objdump -d x.o
 <_Z3r2ij>:
   0:   b8 00 00 00 00  mov$0x0,%eax
   5:   83 ff 0fcmp$0xf,%edi
   8:   77 0a   ja 14 <_Z3r2ij+0x14>
   a:   89 ff   mov%edi,%edi
   c:   48 8b 04 fd 00 00 00mov0x0(,%rdi,8),%rax
  13:   00 
  14:   c3  ret

0x0(,%rdi,8) points to a CSWTCH symbol generated by gcc's
tree-switch-conversion.c.


== Observed behavior with extra flag ==

When enabling pic/PIC, tree-switch-conversion optimization is completely missed
and a lot of lea/ret instruction pairs are generated.

» g++-11 -v x.cpp -c -O2 -fpic
Target: x86_64-suse-linux
gcc version 11.0.0 20210208 (experimental) [revision
efcd941e86b507d77e90a1b13f621e036eacdb45] (SUSE Linux) 
...
» objdump -d x.o
…
  20:   48 8d 05 00 00 00 00lea0x0(%rip),%rax# 27
<_Z3r2ij+0x27>
  27:   c3  ret
  28:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
  2f:   00 
  30:   48 8d 05 00 00 00 00lea0x0(%rip),%rax# 37
<_Z3r2ij+0x37>
  37:   c3  ret
…

[Bug c++/97918] [8/9/10/11 Regression] ICE near htab_hash_string when LTO, -O & -g

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #9 from Jan Engelhardt  ---
The new g++.dg/debug/localclass2.C test file you added is marked "target
c++11", but it seems I can only cause the crash with -std=c++17 or later
standards. Should the test file perhaps be amended?

[Bug c++/97918] New: ICE near htab_hash_string when LTO, -O & -g

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 97918
   Summary: ICE near htab_hash_string when LTO, -O & -g
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Created attachment 49602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49602=edit
Reproducer.

An ICE is observed on firefox-83 with gcc-10.2.1, persisting in git master du
jour too (d3f293348768667c07770e433ff00af51fee73a2).
I distilled the original cpp output from 298k to about 80k lines so far (x3.ii
attachment). The last two functions in that file ultimately trigger it all.
Perhaps the template parameter packs are causing this…


Taking away any one of -flto, -O or -g makes the compile succeed.

» ./xg++ -B $PWD -std=gnu++17 -flto -O -g -c x3.ii
/home/jengelh/x3.ii: At global scope:
/home/jengelh/x3.ii:80113:1: internal compiler error: Segmentation fault
80113 | }
  | ^
0x103917f crash_signal
../.././gcc/toplev.c:330
0x7f09bf684d1f ???
   
/usr/src/debug/glibc-2.32-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x1c09464 htab_hash_string
../.././libiberty/hashtab.c:838
0xc71874 external_ref_hasher::hash(external_ref const*)
../.././gcc/dwarf2out.c:8963
0xc71874 hash_table::find_slot(external_ref* const&, insert_option)
../.././gcc/hash-table.h:435
0xc71874 lookup_external_ref
../.././gcc/dwarf2out.c:8991
0xc71943 optimize_external_refs_1
../.././gcc/dwarf2out.c:9029
0xc7190f optimize_external_refs_1
../.././gcc/dwarf2out.c:9033
0xc71a08 optimize_external_refs
../.././gcc/dwarf2out.c:9082
0xc7aae9 output_comp_unit
../.././gcc/dwarf2out.c:11101
0xca95a3 dwarf2out_early_finish
../.././gcc/dwarf2out.c:32299
0xc066af symbol_table::finalize_compilation_unit()
../.././gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

» ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20201119 (experimental) (GCC)

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #4 from Jan Engelhardt  ---
>don't dlclose a library when you are using anything from it.

That's easier said then done when using C++, as (inline) functions and static
objects can potentially be instantiated in any object file. A shared library
using typeid(T) could be getting the typeinfo either from a possible copy in
the main program, or from the copy inside any loaded shared library.

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #1 from Jan Engelhardt  ---
On second thought, this is practically the same issue as functions going away
(like example below), so wontfix seems appropriate.

-- main
#include 
struct base { virtual ~base() {}; };
int main()
{
auto hnd = dlopen("./libx.so", RTLD_NOW);
auto f = reinterpret_cast(dlsym(hnd, "makederiv"));
auto deriv = f();
dlclose(hnd);
delete deriv;
}
-- libx
#include 
struct base { virtual ~base() {}; }
struct deriv : base { virtual ~deriv() {}; }
extern "C" { base *makederiv(); }
base *makederiv() { return new deriv; }

[Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 97908
   Summary: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

» cat libx.cpp
#include 
class Foobar {};
extern "C" { const char *makename(); }
const char *makename() { Foobar f; return typeid(f).name(); }
» cat m.cpp
#include 
#include 
int main()
{
auto hnd = dlopen("./libx.so", RTLD_NOW);
auto f = reinterpret_cast(dlsym(hnd, "makename"));
auto name = f();
printf("%s\n", name);
dlclose(hnd);
printf("%s\n", name);
}
» g++-11 libx.cpp -shared -fPIC -ggdb3 -o libx.so; g++ m.cpp -fPIC -ggdb3 -Wall
-ldl
» ./a.out 
6Foobar
Segmentation fault (core dumped)
» g++-11 -v
gcc version 11.0.0 20201112 (experimental) [revision
876b45db81a708616d70b1ab66b71bd503809c21] (SUSE Linux) 


I do not know if this is even supposed to work. dlopen/dlclose is outside the
scope of the C++ standard, and POSIX (where dlopen comes from) does not mention
C++ during dlopen. However, this _alternate_ libx.cpp makes the program work:

#include 
struct Foobar { static constexpr char __tag[sizeof(std::type_info)] = { }; };
extern "C" { const char *makename(); }
const char *makename() { Foobar f; return typeid(f).name(); }
const char *helperfunc() { Foobar f; return f.__tag; }

__tag is emitted into the object file as a STB_GNU_UNIQUE symbol, which happens
to implicate RTLD_NODELETE for dlopen.

So, if __tag is getting the "unique" treatment to fulfill some guarantee,
should typeinfo variables (_ZTS* and _ZTI*) not get the same treatment, for the
same reasons?