[Bug libstdc++/113159] More robust std::sort for silly comparator functions
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
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
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
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))
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
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
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
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)
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)
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
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
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 "
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 <https://gcc.gnu.org/bugs/> 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
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
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
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?
[Bug c++/93064] ICE on C++20 operator<=> use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064 --- Comment #1 from Jan Engelhardt --- Possibly a duplicate of #92496 (the automatic "Possible duplicates" in the New Bug form was slow to load), but my preconditions are different: I don't have a public data member, nor is a template used like 92496.
[Bug c++/93064] New: ICE on C++20 operator<=> use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064
Bug ID: 93064
Summary: ICE on C++20 operator<=> use
Product: gcc
Version: 10.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 x.cpp
#include
#include
struct D {
D() { printf("*D\n"); }
~D() { printf("~D\n"); }
auto operator<=>(const D &) = default;
};
int main()
{
D d;
d <=> d;
}
» g++-10 -v x.cpp -std=c++2a
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
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
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/10 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --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=-10 --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 10.0.0 20191210 (experimental) (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-std=c++2a' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/10/cc1plus -quiet -v -D_GNU_SOURCE x.cpp
-quiet -dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -std=c++2a
-version -o /tmp/ccBzGUTo.s
GNU C++17 (SUSE Linux) version 10.0.0 20191210 (experimental)
(x86_64-suse-linux)
compiled by GNU C version 10.0.0 20191210 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/10
/usr/include/c++/10/x86_64-suse-linux
/usr/include/c++/10/backward
/usr/lib64/gcc/x86_64-suse-linux/10/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/10/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/include
/usr/include
End of search list.
GNU C++17 (SUSE Linux) version 10.0.0 20191210 (experimental)
(x86_64-suse-linux)
compiled by GNU C version 10.0.0 20191210 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 17fc461878f813b85b050d0380f89fc7
x.cpp:6:7: error: defaulted ‘auto D::operator<=>(const D&)’ must be ‘const’
6 | auto operator<=>(const D &) = default;
| ^~~~
x.cpp: In member function ‘constexpr auto D::operator<=>(const D&)’:
x.cpp:6:7: internal compiler error: Segmentation fault
0x7fa3e9f2a14f ???
/usr/src/debug/glibc-2.30-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7fa3e9f14e0a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.opensuse.org/> for instructions.
[Bug c/92748] New: Two different -Wreturn-type diagnostics for essentially same code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92748
Bug ID: 92748
Summary: Two different -Wreturn-type diagnostics for
essentially same code
Product: gcc
Version: 9.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 --
» cat x.c
static void *f() {}
void *g() {}
-- Observed output --
» gcc x.c -c -Wall -v
gcc version 9.2.1 20190903 [gcc-9-branch revision 275330] (SUSE Linux)
…
x.c:1:1: warning: no return statement in function returning non-void
[-Wreturn-type]
x.c:2:1: warning: control reaches end of non-void function [-Wreturn-type]
-- Expected output --
Emit the same diagnostic messages for both issues, e.g.
x.c:1:1: warning: no return statement in function returning non-void
[-Wreturn-type]
x.c:2:1: warning: no return statement in function returning non-void
[-Wreturn-type]
[Bug libstdc++/78747] Duplicate _S_empty_rep_storage causes crash when STV_HIDDEN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78747
Jan Engelhardt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Jan Engelhardt ---
>So, are version-scripts with local:* basically incompatible with C++?
Answering myself: yes.
Symbols from library headers (inlines, typeinfos) can be spill-duplicated into
one's own program, such is the nature of contemporary C++ compilation.
Due to ODR, linkers need to collapse duplicate symbols. Only ELF global symbols
participate.
-fvisibility=hidden changes the default symbol visibility. A proper library
header therefore declares __attribute__((visibility("default"))) for its
exports; this way, the visibility of those spilled library symbols will stay
correct even if one's program is built with -fvisibility=hidden.
Version scripts however have the power to force-downgrade the visibility of
symbols in one's program, inhibiting the required collapse. So probably avoid
local:* when linking a C++ lib.
[Bug c++/91086] New: std namespace symbols can get their visibility degraded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086
Bug ID: 91086
Summary: std namespace symbols can get their visibility
degraded
Product: gcc
Version: 9.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: ---
Created attachment 46557
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46557=edit
g++ -fPIC -fvisibility=hidden -E t.cpp
gcc version 9.1.1 20190611 [gcc-9-branch revision 272147] (SUSE Linux)
» cat t.cpp
#include
class __attribute__((visibility("hidden"))) H {};
class __attribute__((visibility("default"))) V {};
int main()
{
std::make_shared();
std::make_shared();
}
» g++ -fPIC -shared -fvisibility=hidden -o t.so t.cpp
Observed behavior: The two instances of _Sp_ebo_helper::_S_get have
different visibility.
» nm -C t.so | grep _S_get
582d t std::_Sp_ebo_helper<0, std::allocator,
true>::_S_get(std::_Sp_ebo_helper<0, std::allocator, true>&)
5810 W std::_Sp_ebo_helper<0, std::allocator,
true>::_S_get(std::_Sp_ebo_helper<0, std::allocator, true>&)
Expected behavior: That the two instances of _S_get have same visibility
(either both t or both W)
» nm -C t.so | grep _S_get
582d W std::_Sp_ebo_helper<0, std::allocator,...
5810 W std::_Sp_ebo_helper<0, std::allocator,...
_S_get (t.i:25368) is inside a template struct _Sp_ebo_helper (t.i:25361) which
is inside a "namespace std __attribute__ ((__visibility__ ("default")))"
(t.i:25008), so I would anticipate that the ebo_helper functions are both
global. (Or, if there is a reason I do not see, both local. But never dependent
upon the visibility of a template argument.)
[Bug c++/88517] Virtual-base class class constructor with for-loop with initializer list referencing local variable not executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88517 --- Comment #1 from Jan Engelhardt --- > clang++ x.cpp -Wall && ./a.out 42 > clang++ -v clang version 6.0.1 (tags/RELEASE_601/final 335528) Target: x86_64-unknown-linux-gnu
[Bug c++/88517] New: Virtual-base class class constructor with for-loop with initializer list referencing local variable not executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88517
Bug ID: 88517
Summary: Virtual-base class class constructor with for-loop
with initializer list referencing local variable not
executed
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
== Testcase
#include
#include
struct B {};
struct D : public virtual B { D(); };
D::D()
{
int z = 42;
for (auto i : {z})
std::cout << i << std::endl;
}
int main() { D o; }
== Observed behavior ==
$ g++-7 x.cpp -Wall && ./a.out
$ g++-8 x.cpp -Wall && ./a.out
$ g++-9 x.cpp -Wall && ./a.out
== Expected behavior
./a.out
42
== Additional info
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
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
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-7 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 7.4.0 (SUSE Linux)
Using built-in specs.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/8/defaults.spec
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
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
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/8 --enable-ssp --disable-libssp
--disable-libvtv --disable-cet --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-8 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 8.2.1 20181108 [gcc-8-branch revision 265914] (SUSE Linux)
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
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
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --disable-libcc1
--enable-plugin --with-bugurl=http://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=-9 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 9.0.0 20181204 (experimental) [trunk revision 266778] (SUSE Linux)
[Bug c++/86997] error: call of overloaded ‘NoDestructor()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86997
Jan Engelhardt changed:
What|Removed |Added
CC||jengelh at inai dot de
--- Comment #4 from Jan Engelhardt ---
>Is it trying to construct an 'a' object and pass that to the NoDestructor? Or
>just default construct the NoDestructor object?
As I read it, it's definitely the 1-arg form (always), not the default ctor.
auto a = NoDestructor(); // NoDestructor a;
auto b = NoDestructor{}; // NoDestructor b{};
auto c = NoDestructor({}); // NoDestructor c({});
auto d = NoDestructor{{}}; // NoDestructor d{{}};
The actual chromium code is something like
template class NoDestructor { ... }
and is used as
NoDestructor> google_tlds({"foo"});
which means ({}), if it appears, was intended to mean the empty set, and this
empty set is passed as the first and only parameter to the NoDestructor 1-arg
ctor.
[Bug sanitizer/87840] LSAN not always printing the leaks when -fsanitize=address is absent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87840 --- Comment #8 from Jan Engelhardt --- g++-9 from openSUSE devel:gcc, the rest from Tumbleweed, SVN numbers see -v banners above.
[Bug sanitizer/87840] LSAN not always printing the leaks when -fsanitize=address is absent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87840 Jan Engelhardt changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WORKSFORME |---
[Bug sanitizer/87840] LSAN misses self-refential shared_ptrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87840
--- Comment #6 from Jan Engelhardt ---
Found a case where g++-9 also misses a leak when -fsanitize=address is not
present.
14:47 a4:~ > cat y.cpp
#include
struct S {
std::shared_ptr other;
};
int main()
{
auto e = std::make_shared();
auto f = std::make_shared();
e->other = f;
f->other = e;
}
14:48 a4:~ > g++-9 -ggdb3 -fsanitize=leak y.cpp; ./a.out
14:48 a4:~ > g++-9 -ggdb3 -fsanitize=address -fsanitize=leak y.cpp; ./a.out
=
==18624==ERROR: LeakSanitizer: detected memory leaks
[...]
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
SUMMARY: AddressSanitizer: 64 byte(s) leaked in 2 allocation(s).
[Bug sanitizer/87840] LSAN misses self-refential shared_ptrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87840 Jan Engelhardt changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Jan Engelhardt --- Must have made a mistake somewhere in the g++9 invocation... so I just reran a number of flag combinations to be sure, and now observe: 14:39 a4:~ > export ASAN_OPTIONS="verbose=111:leak_detect=1" 14:39 a4:~ > export LSAN_OPTIONS="$ASAN_OPTIONS" 14:39 a4:~ > g++-8 -ggdb3 -fsanitize=leak x.cpp; ./a.out 14:39 a4:~ > g++-8 -ggdb3 -fsanitize=address -fsanitize=leak x.cpp; ./a.out [blah] SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s). 14:39 a4:~ > g++-9 -ggdb3 -fsanitize=leak x.cpp; ./a.out [blah] SUMMARY: LeakSanitizer: 32 byte(s) leaked in 1 allocation(s). So it does work, if only the right flags are used.
[Bug sanitizer/87840] LSAN misses self-refential shared_ptrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87840 --- Comment #2 from Jan Engelhardt --- How could I go about debugging why such a backtrace won't show for me?
[Bug sanitizer/87840] New: LSAN misses self-refential shared_ptrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87840
Bug ID: 87840
Summary: LSAN misses self-refential shared_ptrs
Product: gcc
Version: 9.0
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: ---
$ cat x.cpp
#include
struct S {
std::shared_ptr other;
};
int main()
{
auto e = std::make_shared();
e->other = e;
}
$ g++-9 x.cpp -ggdb3 -llsan -fsanitize=leak
$ ./a.out
$
LSAN fails to report the cycle while valgrind does.
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
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
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/9 --enable-ssp --disable-libssp
--disable-libvtv --disable-cet --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-9 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 9.0.0 20181026 (experimental) [trunk revision 265522] (SUSE Linux)
Applies to
gcc version 8.2.1 20180831 [gcc-8-branch revision 264010] (SUSE Linux)
gcc version 7.3.1 20180817 [gcc-7-branch revision 263612] (SUSE Linux)
as well.
[Bug c++/87427] New: -Wclass-memaccess improvement for POD with convenience initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87427
Bug ID: 87427
Summary: -Wclass-memaccess improvement for POD with convenience
initializer
Product: gcc
Version: 8.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: ---
#include
struct S { int z; S() { z = 1; } } s;
int main() { memset(, 0, sizeof(s)); }
The rationale of -Wclass-memaccess as presented in the manpage ("Modifying the
representation of such objects may violate invariants maintained by member
functions") is sound.
For the 3-liner example though, it could be argued that member functions do not
guarantee any invariant, given all member variables are public and kinda invite
direct access.
Would it be considered worthwhile to have a, say,
-Wclass-memaccess=except-struct, to relax the warning for types that satisfy
(standard_layout && (all members are public) && (all members are non-const))?
[Bug c++/87384] New: Likely syntax error not reported as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87384
Bug ID: 87384
Summary: Likely syntax error not reported as such
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: ---
$ cat x.cpp
void (*f)(const char *, int &&...);
void g(const char *, int &, int &) {}
int main() { f = g; return 0; }
OBSERVED:
$ g++-8 -c x.cpp
x.cpp: In function ‘int main()’:
x.cpp:3:18: error: invalid conversion from ‘void (*)(const char*, int&&,
int&&)’ to ‘void (*)(const char*, int&&, ...)’ [-fpermissive]
int main() { f = g; return 0; }
EXPECTED:
That "int &&..." be reported as a syntax error of some kind. An argument pack
is normally only viable with a template, isn't it.
Using built-in specs.
COLLECT_GCC=g++-8
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
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
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/8 --enable-ssp --disable-libssp
--disable-libvtv --disable-cet --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-8 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 8.2.1 20180831 [gcc-8-branch revision 264010] (SUSE Linux)
COLLECT_GCC_OPTIONS='-c' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/8/cc1plus -quiet -v -D_GNU_SOURCE x.cpp
-quiet -dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -version -o
/tmp/ccboFSGw.s
GNU C++14 (SUSE Linux) version 8.2.1 20180831 [gcc-8-branch revision 264010]
(x86_64-suse-linux)
compiled by GNU C version 8.2.1 20180831 [gcc-8-branch revision
264010], GMP version 6.1.2, MPFR version 4.0.1-p6, MPC version 1.1.0, isl
version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/8
/usr/include/c++/8/x86_64-suse-linux
/usr/include/c++/8/backward
/usr/lib64/gcc/x86_64-suse-linux/8/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/8/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/include
/usr/include
End of search list.
GNU C++14 (SUSE Linux) version 8.2.1 20180831 [gcc-8-branch revision 264010]
(x86_64-suse-linux)
compiled by GNU C version 8.2.1 20180831 [gcc-8-branch revision
264010], GMP version 6.1.2, MPFR version 4.0.1-p6, MPC version 1.1.0, isl
version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9a7181e015deb6ba65f2fa22664edb4d
[Bug c++/84471] New: Instruction reordering happens in lambdas even with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471
Bug ID: 84471
Summary: Instruction reordering happens in lambdas even with
-O0
Product: gcc
Version: 7.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: ---
Expected behavior:
Objects built with -O0 ought not cause gdb to spuriously "go backwards" in
source (for reasons other than the end of a loop).
Observed behavior:
Despite being explicitly built with no optimizations, I observe that gdb jumps
around inside C++ programs' lambdas that capture something.
#include
#include
#define N 256
int main()
{
const char key[] = "keykeykeykeykeykey";
[&]() {
unsigned char S[N];
int len = strlen(key);
int j = 0;
for (int i = 0; i < N; ++i)
j = (j + S[i] + key[i%len]) % N;
}();
}
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
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
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-7 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 7.3.0 (SUSE Linux)
$ g++-7 x.cpp -O0 -ggdb3 -fno-reorder-blocks -fno-reorder-blocks-and-partition
-fno-reorder-functions
$ gdb a.out
GNU gdb (GDB; openSUSE Tumbleweed) 8.0.1
(gdb) b main
Breakpoint 1 at 0x4005c0: file x.cpp, line 6.
(gdb) r
Breakpoint 1, main () at x.cpp:6
6 const char key[] = "keykeykeykeykeykey";
(gdb) s
13 }();
(gdb)
<lambda()>::operator()(void) const (__closure=0x7fffdd98) at x.cpp:9
9 int len = strlen(key);
(gdb) n
10 int j = 0;
(gdb)
11 for (int i = 0; i < N; ++i)
(gdb)
12 j = (j + S[i] + key[i%len]) % N;
(gdb)
9 int len = strlen(key);
(gdb)
12 j = (j + S[i] + key[i%len]) % N;
Expected behavior:
Never reach line 9 again.
[Bug c++/82522] New: std::map::insert(value_type &&) not selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82522
Bug ID: 82522
Summary: std::map::insert(value_type &&) not selected
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
#include
struct only_movable {
only_movable(){}
only_movable(only_movable&&){}
only_movable =(only_movable&&){return *this;}
};
int main()
{
std::map<int, only_movable> map;
map.insert({0, only_movable()});
}
Building this code succeeds with clang++, but fails under g++ 7.2.1/8.0 with:
In file included from
/opt/wandbox/gcc-head/include/c++/8.0.0/x86_64-pc-linux-gnu/bits/c++allocator.h:33:0,
from
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/allocator.h:46,
from
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/stl_tree.h:64,
from /opt/wandbox/gcc-head/include/c++/8.0.0/map:60,
from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/8.0.0/ext/new_allocator.h: In instantiation
of 'void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up
= std::pair; _Args = {const std::pair&}; _Tp = std::_Rb_tree_node<std::pair
>]':
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/alloc_traits.h:475:4: required
from 'static void std::allocator_traits<std::allocator<_Tp1>
>::construct(std::allocator_traits<std::allocator<_Tp1> >::allocator_type&,
_Up*, _Args&& ...) [with _Up = std::pair; _Args =
{const std::pair&}; _Tp =
std::_Rb_tree_node<std::pair >;
std::allocator_traits<std::allocator<_Tp1> >::allocator_type =
std::allocator<std::_Rb_tree_node<std::pair > >]'
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/stl_tree.h:626:32: required from
'void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_construct_node(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type, _Args&& ...) [with _Args = {const std::pair&}; _Key = int; _Val = std::pair;
_KeyOfValue = std::_Select1st<std::pair >; _Compare =
std::less; _Alloc = std::allocator<std::pair >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node<std::pair >*]'
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/stl_tree.h:643:4: required from
'std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_create_node(_Args&& ...) [with _Args = {const std::pair&}; _Key = int; _Val = std::pair;
_KeyOfValue = std::_Select1st<std::pair >; _Compare =
std::less; _Alloc = std::allocator<std::pair >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node<std::pair >*]'
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/stl_tree.h:556:62: required from
'std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Alloc_node::operator()(_Arg&&) const [with _Arg = const
std::pair&; _Key = int; _Val = std::pair; _KeyOfValue = std::_Select1st<std::pair
>; _Compare = std::less; _Alloc = std::allocator<std::pair >; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type = std::_Rb_tree_node<std::pair
>*]'
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/stl_tree.h:1758:29: required
from 'std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_insert_(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Base_ptr, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Base_ptr, _Arg&&, _NodeGen&) [with _Arg = const std::pair&; _NodeGen = std::_Rb_tree<int, std::pair, std::_Select1st<std::pair >,
std::less, std::allocator<std::pair >
>::_Alloc_node; _Key = int; _Val = std::pair;
_KeyOfValue = std::_Select1st<std::pair >; _Compare =
std::less; _Alloc = std::allocator<std::pair >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator =
std::_Rb_tree_iterator<std::pair >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Base_ptr =
std::_Rb_tree_node_base*]'
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/stl_tree.h:2101:11: required
from 'std::pair<std::_Rb_tree_iterator<_Val>, bool> std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_M_insert_unique(_Arg&&) [with _Arg = const
std::pair&; _Key = int; _Val = std::pair; _KeyOfValue = std::_Select1st<std::pair
>; _Compare = std::less; _Alloc = std::allocator<std::pair >]'
/opt/wandbox/gcc-head/include/c++/8.0.0/bits/stl_map.h:797:41: required from
'std::pair,
std::_Selec
[Bug sanitizer/80963] UBSAN false positive with visibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80963 --- Comment #5 from Jan Engelhardt --- >Where would those magic numbers come from? We don't have anything like that. Maybe something similar to .build-id?, i.e. randomly-generated IDs (per .so) that merely serve to distinguish two structs. >>some -f option to always make UBSAN treat same-name classes as the same thing >>irrespective of visibility. I think I now found that as -fvisibility-ms-compat. >By using visibility other than default, you intentionally depart from the C++ >ODR rules I see. Then however the manpage should perhaps be updated to sport some stronger language, since it currently rather encourages the use of visibility and even lists the few conditions that need to be met. """It is strongly recommended that you use this in any shared objects you distribute.""" """-fvisibility does affect C++ vague linkage entities. This means that, for instance, an exception class that is be thrown between DSOs must be explicitly marked with default visibility so that the type_info nodes are unified between the DSOs."""
[Bug sanitizer/80963] UBSAN false positive with visibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80963 --- Comment #3 from Jan Engelhardt --- The question is more like - can it be made to work even if (In reply to Andrew Pinski from comment #1) > > That is Archive in the shared library and in the main executable are > considered two different classes. If that is how UBSAN thinks, then it should say so by uniquely identifying each "distinct" class, e.g.: main.cpp:3:16: runtime error: member call on address 0x00dcfc20 which does not point to an object of type 'Archive.1234' 0x00dcfc20: note: object is of type 'ArchiveImpl' [Archive.5678] Secondly, I think that considering them two different classes is only valid in C, but not under the ODR rules of C++. Finally, nonwithstanding all the above, it would be nice to have some -f option to always make UBSAN treat same-name classes as the same thing irrespective of visibility. Reason: to make UBSAN "work" with this example meant having to edit configure.ac+Makefile.am (of the particular real-world program) to not use "-Wl,--version-script=foo.sym -fvisiblity=hidden" at all, and that was a little more work than just slapping another -f into CXXFLAGS.
[Bug sanitizer/80963] New: UBSAN false positive with visibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80963
Bug ID: 80963
Summary: UBSAN false positive with visibility=hidden
Product: gcc
Version: 7.1.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: ---
$ cat lib.h
struct Archive {
virtual void foo() = 0;
};
__attribute__((visibility("default"))) Archive *factory();
$ cat libimpl.cpp
#include "lib.h"
struct ArchiveImpl : Archive { void foo(); };
void ArchiveImpl::foo() {}
Archive *factory() { return new ArchiveImpl; }
$ cat main.cpp
#include "lib.h"
int main(void) {
factory()->foo();
}
$ make
g++ -fPIC -o libimpl.so -shared libimpl.cpp -fvisibility=hidden -Wall
-fsanitize=undefined -lubsan
g++ -o main main.cpp ./libimpl.so -fvisibility=hidden -Wall
-fsanitize=undefined -lubsan
$ ./main
main.cpp:3:16: runtime error: member call on address 0x00dcfc20 which does
not point to an object of type 'Archive'
0x00dcfc20: note: object is of type 'ArchiveImpl'
00 00 00 00 88 ed 59 dc 84 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 21 00 00 00
^~~
vptr for 'ArchiveImpl'
The symbol table of main or libimpl.so do not appear to change when
removing/adding -fvisiblity=hidden (no added/removed symbols, just address
changes), so I wonder what exactly it is that UBSAN is trying to look up and
not finding.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
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
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-7 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 7.1.1 20170530 [gcc-7-branch revision 248621] (SUSE Linux)
[Bug libstdc++/78747] Duplicate _S_empty_rep_storage causes crash when STV_HIDDEN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78747
--- Comment #3 from Jan Engelhardt ---
The workaround is
global { extern "C++" { *::_Rep::_S_empty_rep_storage; }}
but of course that was not the question embedded in this "bug" report.
[Bug c++/79563] New: Same-name labels in lambdas considered duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79563
Bug ID: 79563
Summary: Same-name labels in lambdas considered duplicate
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: ---
$ clang++ -c cmd.cpp -std=gnu++11
$ g++-7 -c cmd.cpp -std=gnu++11
cmd.cpp: In function ‘void f()’:
cmd.cpp:2:7: error: label ‘exit’ used but not defined
goto exit;
^~~~
cmd.cpp:7:1: error: duplicate label ‘exit’
}
^
$ cat cmd.cpp
void f() {
goto exit;
[]() -> void {
exit: ;
}();
exit: ;
}
gcc version 7.0.1 20170214 (experimental) [trunk revision 245417] (SUSE Linux)
Also happens with 4.8, 5.4.1 and 6.3.1.
[Bug middle-end/78937] New data.rel.ro.local section in TW's gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78937 --- Comment #3 from Jan Engelhardt --- Now that you mention it, I have a PIE-by-default extension installed on that one (/usr/lib64/gcc/x86_64-suse-linux/6/defaults.spec file). Thanks for clearing that up.
[Bug translation/78937] New: New data.rel.ro.local section in TW's gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78937
Bug ID: 78937
Summary: New data.rel.ro.local section in TW's gcc
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
$ cat x.c
static const struct { int i; } foobar = {42};
static const struct { const char *n; } foobaz = {"moo"};
When compiled with the openSUSE Leap 42.2 + devel:gcc "gcc version 6.2.1
20161214 [gcc-6-branch revision 243648] (SUSE Linux)", the result is
anticipated; both symbols end up in rodata:
$ gcc-6 -std=gnu11 -c x.c && nm x.o | grep fooba
r foobar
0008 r foobaz
$ gcc-6 -std=gnu11 -S x.c && grep section x.s
.section.rodata
.section.note.GNU-stack,"",@progbits
However, when compiled with pretty much the same compiler, openSUSE Tumbleweed
"gcc version 6.2.1 20161209 [gcc-6-branch revision 243481] (SUSE Linux)", the
following sections are output instead:
$ gcc-6 -std=gnu11 -c x.c -fno-use-linker-plugin && nm x.o | grep fooba
r foobar
d foobaz
$ gcc-6 -std=gnu11 -S x.c -fno-use-linker-plugin && grep section x.s
.section.rodata
.section.data.rel.ro.local,"aw",@progbits
.section.note.GNU-stack,"",@progbits
This section seems to be new; why does foobaz end up in .data now? Is this a
result of how gcc itself was built? The only difference is
42.2 gcc -v: [...] --with-default-libstdcxx-abi=gcc4-compatible
TWgcc -v: [...] --enable-plugin
C++ is not used in this case, so is the plugin thing the cause (and if, should
-fno-use-linker-plugin not disable it)?
[Bug libstdc++/78747] New: Duplicate _S_empty_rep_storage causes crash when STV_HIDDEN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78747
Bug ID: 78747
Summary: Duplicate _S_empty_rep_storage causes crash when
STV_HIDDEN
Product: gcc
Version: 6.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: ---
The following testcase produces a crashing program.
The gist seems to be that main.o and lib1.o each get a copy of the
std::basic_string::Rep::_M_dispose function, and along with it, the
_ZNSbIDsSt11char_traitsIDsESaIDsEE4_Rep20_S_empty_rep_storageE symbol. They get
marked hidden by the used symbol visiblity file (see below), which means that
they will not be combined by the runtime linker, and each _M_dispose tests for
its own empty_rep only, leading to Undesired Behavior when one _M_dispose gets
the other _S_empty_rep_storage.
void
_M_dispose(const _Alloc& __a) _GLIBCXX_NOEXCEPT
{
#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
if (__builtin_expect(this != &_S_empty_rep(), false))
#endif
In other words, a situation arises which is loosely described in the gcc
manpage: "-fvisibility-inlines-hiddenThis switch declares that the user
does not attempt to compare pointers to inline functions or methods", but here,
we have a third case, a static object.
So, are version-scripts with local:* basically incompatible with C++? Trying to
figure out whether this is just a documentation RFE, or whether there is
something that could be done to libstdc++ to improve the situation (abandoning
pointerish comparisons?) Maybe bug #54173 is related too.
---main.cpp--
#include
__attribute__((visibility("default"))) void l1_func(std::u16string &);
int main(void)
{
std::u16string a;
a.append(a);
l1_func(a);
return 0;
}
---lib1.cpp---
#include
__attribute__((visibility("default"))) void l1_func(std::u16string &);
void l1_func(std::u16string ) {
static const char16_t t[] = {41, 42};
a.append(t, 2);
}
---lib.sym---
ABC { global: *l1_func*; local: *; };
---makeit.sh---
g++ -std=gnu++11 lib1.cpp -shared -fPIC -o lib1.so -Wl,--version-script=lib.sym
g++ -std=gnu++11 ldr.cpp ./lib1.so
--- Observed behavior ---
11:13 zap:/dev/shm/t > ./mk
11:13 zap:/dev/shm/t > ./a.out
*** Error in `./a.out': free(): invalid pointer: 0x006020a0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x721af)[0x7f794e17c1af]
/lib64/libc.so.6(+0x779d6)[0x7f794e1819d6]
/lib64/libc.so.6(+0x78723)[0x7f794e182723]
./lib1.so(+0x149a)[0x7f794ed4b49a]
./lib1.so(+0x140d)[0x7f794ed4b40d]
./lib1.so(+0x11d0)[0x7f794ed4b1d0]
./lib1.so(+0xf19)[0x7f794ed4af19]
./lib1.so(+0xbd8)[0x7f794ed4abd8]
./lib1.so(_Z7l1_funcRSbIDsSt11char_traitsIDsESaIDsEE+0x24)[0x7f794ed4]
./a.out[0x4009de]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f794e12a6e5]
./a.out[0x400839]
Using built-in specs.
COLLECT_GCC=g++-6
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/6/lto-wrapper
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++,java,ada,go
--enable-offload-targets=hsa --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/6 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --enable-gnu-indirect-function --program-suffix=-6
--without-system-libunwind --enable-multilib --with-arch-32=x86-64
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.2.1 20161121 [gcc-6-branch revision 242657] (SUSE Linux)
[Bug c++/78564] cp-demangle fails to decode Ul+auto/anon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78564 --- Comment #1 from Jan Engelhardt --- crosslink https://sourceware.org/bugzilla/show_bug.cgi?id=20873
[Bug c++/78564] New: cp-demangle fails to decode Ul+auto/anon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78564
Bug ID: 78564
Summary: cp-demangle fails to decode Ul+auto/anon
Product: gcc
Version: 6.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: ---
$ g++-6 -std=gnu++14 -c x.cpp
int main(void)
{
struct NAMED {} f;
struct {} g;
struct {} h;
[](auto &&){}(f);
[](auto &&, auto &&){}(g, h);
}
{binutils 2.27}
$ nm -C x.o
t _ZZ4mainENKUlOT_E_clIRZ4mainE5NAMEDEEDaS0_
0010 t _ZZ4mainENKUlOT_OT0_E0_clIRZ4mainEUt_RZ4mainEUt0_EEDaS0_S2_
$ gcc -v
Using built-in specs.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/6/defaults.spec
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/6/lto-wrapper
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++,java,ada,go
--enable-offload-targets=hsa --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/6 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --enable-gnu-indirect-function --program-suffix=-6
--without-system-libunwind --enable-multilib --with-arch-32=x86-64
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.2.1 20160830 [gcc-6-branch revision 239856] (SUSE Linux)
[Bug c++/78502] New: Analyze 'final'/'override' even for uninstantiated class templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78502
Bug ID: 78502
Summary: Analyze 'final'/'override' even for uninstantiated
class templates
Product: gcc
Version: 6.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: ---
This is a feature request for a future version.
gcc 6.x currently misses to warn about nonderivable classes of templates that
are left uninstantiated:
$ cat t.cpp
class A final {};
template class B : public A {};
Observed:
$ g++-6 t.cpp -std=gnu++11 -c -Wall
$
(no diagnostics)
Expected:
Clang 3.7.0:
$ clang++ -std=gnu++11 -c -Wall t.cpp
t.cpp:2:39: error: base 'A' is marked 'final'
template class B : public A {};
Coverity 8.5.0.5:
$ cov-build g++ -std=gnu++11 -c -Wall t.cpp
"t.cpp", line 2: error #1920: a "final" class type cannot be used as a base
class
class B : public A {
gcc version 6.2.1 20161121 [gcc-6-branch revision 242657] (SUSE Linux)
[Bug libstdc++/78475] New: Mixing objects form different g++ versions can crash a program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78475
Bug ID: 78475
Summary: Mixing objects form different g++ versions can crash a
program
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Is mixing "finalized" object files (ET_EXEC, ET_DYN) produced by different g++
versions a supported scenario? If so, consider this:
$ cat all.h
#include
#include
struct handler { virtual ~handler() {} };
extern std::shared_ptr get_handler(void);
$ cat g48.cpp
#include "all.h"
std::shared_ptr get_handler(void)
{
printf("%zu\n", sizeof(std::_Sp_counted_ptr_inplace<handler,
std::allocator, (__gnu_cxx::_Lock_policy)2 >));
return std::make_shared();
}
$ cat main.cpp
#include "all.h"
int main(void)
{
printf("%zu\n", sizeof(std::_Sp_counted_ptr_inplace<handler,
std::allocator, (__gnu_cxx::_Lock_policy)2 >));
get_handler();
std::make_shared();
return 0;
}
$ g++-4.8 g48.cpp -fPIC -shared -o g48.so -std=gnu++11
$ g++-6 main.cpp -o main ./g48.so -std=gnu++11
$ ./main
24
32
Segmentation fault (core dumped)
The reason, as I have found, is that there was an ABI change in
Sp_counted_ptr_inplace which made it grow in size. Furthermore, if you
single-step through g48.cpp's make_shared, you will notice it jumps between
functions from /usr/include/c++/4.8 and /usr/include/c++/6, which I suppose is
a result of symbols
(_ZNSt23_Sp_counted_ptr_inplaceI7handlerSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info)
not being sufficiently versioned, causing weak symbols from main(.o) and
g48(.o) to trample on one another. That is to say, to remedy the problem,
_Sp_counted_ptr_inplace would need something like __attribute__((__abi_tag__
("GLIBCXX_3.4.22"))) maybe.
Compilers used:
> gcc-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-4.8
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
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++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.5 (SUSE Linux) [openSUSE Leap 42.1 base compiler]
$ gcc-6 -v
Using built-in specs.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/6/defaults.spec
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/6/lto-wrapper
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++,java,ada,go
--enable-offload-targets=hsa --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/6 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --enable-gnu-indirect-function --program-suffix=-6
--without-system-libunwind --enable-multilib --with-arch-32=x86-64
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.2.1 20161121 [gcc-6-branch revision 242657] (SUSE Linux)
[devel:gcc for 42.1]
(Both compilers are using _GLIBCXX_USE_CXX11_ABI=0 in all cases)
[Bug c++/47877] -fvisibility-inlines-hidden does not hide member template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47877 --- Comment #3 from Jan Engelhardt --- Hm yes, I begin to see why this was done. Template instantiations show up as W-type symbols in `nm`, and template specializations are 'T'-type, and both need to be visible so that the override works. But only on -O0. When compiling with -O2, the template instantiations gets inlined and the symbol (_ZN3Foo3barIS_EEvv in this example) disappears because of -fvisibility-inlines-hidden and could not possibly be overridden. So template specializations from elsewhere will have no effect. ... So IMO we can probably just drop the "!processing_template_decl" part.
[Bug c++/47877] -fvisibility-inlines-hidden does not hide member template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47877 Jan Engelhardt changed: What|Removed |Added CC||jengelh at inai dot de, ||rguenther at suse dot de --- Comment #1 from Jan Engelhardt --- The issue persists with gcc 6.2.1 and was also posted at https://www.spinics.net/lists/gcchelp/msg46007.html with more detail.
[Bug c++/70417] New: New g++6 rejects previously valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70417
Bug ID: 70417
Summary: New g++6 rejects previously valid code
Product: gcc
Version: 6.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: ---
---8<---
template struct ref {
template ref dy() const { return ref(); }
};
template ref dy(ref y) {
return y.dy();
}
--->8---
gcc version 6.0.0 20160324 (experimental) [trunk revision 234449] (SUSE Linux)
produces:
t.cpp: In function ‘ref dy(ref)’:
t.cpp:5:15: error: expected primary-expression before ‘>’ token
return y.dy();
^
t.cpp:5:17: error: expected primary-expression before ‘)’ token
return y.dy();
^
Prior g++ versions, including
* gcc version 4.8.5 (SUSE Linux)
* gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux)
* and some un-rememberable g++6 "from last month or so"
all accepted the code. Is there something new in the C++ standards, or is this
a g++ regression?
[Bug c/70042] Room for optimization of x+1>y vs x>=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70042 Jan Engelhardt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jan Engelhardt --- Meh, overflow. Of course :)
[Bug c/70042] New: Room for optimization of x+1>y vs x>=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70042
Bug ID: 70042
Summary: Room for optimization of x+1>y vs x>=y
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/6/lto-wrapper
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++,java,ada,go --enable-checking=yes
--with-gxx-include-dir=/usr/include/c++/6 --enable-ssp --disable-libssp
--disable-libvtv --disable-plugin --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-6 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.0.0 20160202 (experimental) [trunk revision 233076] (SUSE Linux)
$ cat g1.c geq.c
#include
int main(int argc, char **argv) { return strlen(argv[0])+1 > 108; }
#include
int main(int argc, char **argv) { return strlen(argv[0]) >= 108; }
$ gcc-6 g1.c -Wall -O2 -c geq.c
$ objdump -d g1.o geq.o
: //g1
0: 48 83 ec 08 sub$0x8,%rsp
4: 48 8b 3emov(%rsi),%rdi
7: e8 00 00 00 00 callq c <main+0xc>
c: 48 83 c0 01 add$0x1,%rax
10: 48 83 f8 6c cmp$0x6c,%rax
14: 0f 97 c0seta %al
17: 48 83 c4 08 add$0x8,%rsp
1b: 0f b6 c0movzbl %al,%eax
1e: c3 retq
: //geq
0: 48 83 ec 08 sub$0x8,%rsp
4: 48 8b 3emov(%rsi),%rdi
7: e8 00 00 00 00 callq c <main+0xc>
c: 48 83 f8 6b cmp$0x6b,%rax
10: 0f 97 c0seta %al
13: 48 83 c4 08 add$0x8,%rsp
17: 0f b6 c0movzbl %al,%eax
1a: c3 retq
The x+1>=y variant uses more code, but does not have to.
In contrast, with -Os:
: //g1
0: 48 8b 3emov(%rsi),%rdi
3: 31 c0 xor%eax,%eax
5: 48 83 c9 ff or $0x,%rcx
9: f2 ae repnz scas %es:(%rdi),%al
b: 31 c0 xor%eax,%eax
d: 48 f7 d1not%rcx
10: 48 83 f9 6c cmp$0x6c,%rcx
14: 0f 97 c0seta %al
17: c3 retq
: //geq
0: 48 8b 3emov(%rsi),%rdi
3: 31 c0 xor%eax,%eax
5: 48 83 c9 ff or $0x,%rcx
9: f2 ae repnz scas %es:(%rdi),%al
b: 48 89 c8mov%rcx,%rax
e: 48 f7 d0not%rax
11: 48 ff c8dec%rax
14: 48 83 f8 6b cmp$0x6b,%rax
18: 0f 97 c0seta %al
1b: 0f b6 c0movzbl %al,%eax
1e: c3 retq
the reverse is true, x>=y using more code but does not have to.
[Bug c/70042] Room for optimization of x+1>y vs x>=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70042 Jan Engelhardt changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/65194] Compiler warns of maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65194 Jan Engelhardt changed: What|Removed |Added Resolution|WONTFIX |WORKSFORME --- Comment #2 from Jan Engelhardt --- It no longer triggers, not even in g++-4.8. No idea what happened there.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #20 from Jan Engelhardt jengelh at inai dot de --- Seems like the short route is to add a new attribute ((warn_unused_result_with_void_cancelling)) that exhibits the desired behavior of (void) cancelling the warning, and then make glibc use that. Simple, no?
[Bug gcov-profile/66805] Crash in gcov_exit when combining --coverage, C++, #pragma pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66805 --- Comment #4 from Jan Engelhardt jengelh at inai dot de --- If one uses #pragma pack(push, 1) #pragma pack(pop) the issue goes away, so indeed, it seems that some gcov parts are implicitly built with different padding.
[Bug c++/66805] Crash in gcov_exit when combining --coverage, C++, #pragma pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66805 --- Comment #1 from Jan Engelhardt jengelh at inai dot de --- (gdb) r Starting program: t Program received signal SIGSEGV, Segmentation fault. compute_summary (max_length=synthetic pointer, this_prg=0x7fff9540, list=0x77dda180) at ../../../libgcc/libgcov-driver.c:307 307 ../../../libgcc/libgcov-driver.c: No such file or directory. (gdb) bt #0 compute_summary (max_length=synthetic pointer, this_prg=0x7fff9540, list=0x77dda180) at ../../../libgcc/libgcov-driver.c:307 #1 gcov_do_dump (list=0x77dda180, run_counted=0) at ../../../libgcc/libgcov-driver.c:837 #2 0x77bd9112 in __gcov_dump_one (root=0x77ddb280 __gcov_root) at ../../../libgcc/libgcov-driver.c:858 #3 gcov_exit () at ../../../libgcc/libgcov-driver.c:874 #4 0x76fccf7f in __cxa_finalize (d=0x77dda120) at cxa_finalize.c:56 #5 0x77bd7173 in __do_global_dtors_aux () from ./pack.so #6 0x7fffde00 in ?? () #7 0x77deaf3a in _dl_fini () at dl-fini.c:252 Backtrace stopped: frame did not save the PC
[Bug c++/66805] New: Crash in gcov_exit when combining --coverage, C++, #pragma pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66805
Bug ID: 66805
Summary: Crash in gcov_exit when combining --coverage, C++,
#pragma pack
Product: gcc
Version: 5.1.1
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: ---
Observed: When building in C++ mode, combined with #pragma pack(1), combined
with --coverage, there is a crash somewhere in gcov_exit.
$ cat MF
#!/bin/sh
echo 'void foo(void){}' pack.cpp
echo '#pragma pack(1)' pack.cpp
echo 'int main(void){return 0;}' t.cpp
g++ --coverage pack.cpp -shared -fPIC -o pack.so
g++ --coverage t.cpp -o t ./pack.so
./t
$ sh MF
MF: line 7: 22909 Segmentation fault ./t
$ gcc -v
gcc version 4.8.5 (SUSE Linux)
Also happens with:
gcc version 5.1.1 20150609 [gcc-5-branch revision 224273] (SUSE Linux)
(platform is an openSUSE 13.2 x86_64 with the compilers provided by
/devel:/gcc)
[Bug c++/66294] New: Nonsensical warning message for address-of static member function expr through expr.B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66294
Bug ID: 66294
Summary: Nonsensical warning message for address-of static
member function expr through expr.B
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
The following code:
struct F {
F self(void) { return *this; };
static void test(void) { };
} f;
int main(void) { f.self().test; }
yields the following compiler output:
t.cpp: In function ‘int main()’:
t.cpp:5:32: warning: right operand of comma operator has no effect
[-Wunused-value]
int main(void) { f.self().test; }
However, there is no comma in the source at all. The warning is misleading.
This occurs for all known versions.
gcc version 5.1.1 20150518 [gcc-5-branch revision 223286] (SUSE Linux)
gcc version 4.9.0 (SUSE Linux)
gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux)
What was expected:
[that which clang outputs, maybe?]
t.cpp:5:18: warning: expression result unused [-Wunused-value]
int main(void) { f.self().test; }
^~
[Bug c++/65801] New: Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
Bug ID: 65801
Summary: Allow -Wno-narrowing to silence stricter C++11
narrowing rules
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
This code:
---8---
static struct zai { unsigned int x; } x = {-1};
---8---
gives this error in C++11 mode:
$ g++-5 -std=gnu++11 -c y.cpp
y.cpp:1:46: error: narrowing conversion of ‘-1’ from ‘int’ to ‘unsigned int’
inside { }
Clang 3.5 offers using -Wno-narrowing to ignore this and continue with the
previous semantics of silently converting it, which is helpful if one's C++11
project has to include e.g. zend_API.h (which uses the -1 conversion).
Such a feature is missing from gcc.
$ gcc-5 -v
gcc version 5.0.1 20150416 (prerelease) [gcc-5-branch revision 222148] (SUSE
Linux)
[Bug c++/65194] New: Compiler warns of maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65194 Bug ID: 65194 Summary: Compiler warns of maybe-uninitialized Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jengelh at inai dot de Created attachment 34857 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34857action=edit A testcase. (It used to be over 6 lines after the initial g++ -E, so excuse if I did not resolve #include string) The attached testcase warns of maybe-used uninitialized. g++-4.9 m.cpp -Wall -O2 -ggdb3 -o m -std=gnu++11 m.cpp: In function ‘int main()’: m.cpp:25:13: warning: ‘idx’ may be used uninitialized in this function [-Wmaybe-uninitialized] srand(idx); ^ However, as soon as one modifies the source, the warning disappears. Pick one of the transformations from the bullet point list, and it goes away. * replace *one* instance of new char by NULL * replace new str by new char * replace std::string by str This happens both with Using built-in specs. COLLECT_GCC=g++-4.9 COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.9/lto-wrapper 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++,java,ada,go --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.9 --enable-ssp --disable-libssp --disable-libvtv --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.9 --without-system-libunwind --enable-multilib --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 4.9.0 (SUSE Linux) and Using built-in specs. COLLECT_GCC=g++-4.8 COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper 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++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.8 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) What might be happening in gcc?
[Bug c++/60354] fails to demangle _Z3fooIPUlvE_EvT_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60354
Jan Engelhardt jengelh at inai dot de changed:
What|Removed |Added
CC||jengelh at inai dot de
--- Comment #1 from Jan Engelhardt jengelh at inai dot de ---
Manually decomposing _Z3fooIPUlvE_EvT_, there is:
- PUlvE_: {lambda(void)#1}*
- I PULvE_ E: templatethat
- finally, 3foo IPUlvE_E vT_ is
fooT returning void taking (T)
Looks correctly mangled to me.
[Bug c++/60366] New: ICE with self-invoking lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60366
Bug ID: 60366
Summary: ICE with self-invoking lambdas
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
This not-so-serious code:
$ cat w.cpp
int main(int argc, const char **argv)
{
auto f = [](const struct __lambda0 self) { self(self); };
f(f);
return 0;
}
causes an ICE instead of just exiting(1):
$ g++ w.cpp -std=gnu++11 -o w -ggdb3 -Wall
w.cpp: In lambda function:
w.cpp:3:55: error: use of ‘main(int, const char**)::__lambda0’ before deduction
of ‘auto’
auto f = [](const struct __lambda0 self) { self(self); };
^
w.cpp:3:55: error: invalid use of ‘auto’
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
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++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.2 20140225 [gcc-4_8-branch revision 208119] (SUSE Linux)
$ g++-4.9 w.cpp -std=gnu++11 -o w -ggdb3 -Wall
g++-4.9: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.
$ g++-4.9 -v
Using built-in specs.
COLLECT_GCC=g++-4.9
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.9/lto-wrapper
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++,java,ada,go --enable-checking=yes
--with-gxx-include-dir=/usr/include/c++/4.9 --enable-ssp --disable-libssp
--disable-libvtv --disable-plugin --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--enable-linker-build-id --enable-linux-futex --program-suffix=-4.9
--without-system-libunwind --enable-multilib --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 4.9.0 20140226 (experimental) [trunk revision 208172] (SUSE Linux)
[Bug rtl-optimization/59429] New: Missed optimization opportunity in qsort-style comparison functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
Bug ID: 59429
Summary: Missed optimization opportunity in qsort-style
comparison functions
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
The following code:
extern int comLG(int, int);
extern int comLE(int, int);
extern int comEL(int, int);
extern int comEG(int, int);
extern int comGL(int, int);
extern int comGE(int, int);
int comLG(int a, int b) { return (a b) ? -1 : (a b) ? 1 : 0; }
int comLE(int a, int b) { return (a b) ? -1 : (a == b) ? 0 : 1; }
int comEL(int a, int b) { return (a == b) ? 0 : (a b) ? -1 : 1; }
int comEG(int a, int b) { return (a == b) ? 0 : (a b) ? 1 : -1; }
int comGL(int a, int b) { return (a b) ? 1 : (a b) ? -1 : 0; }
int comGE(int a, int b) { return (a b) ? 1 : (a == b) ? 0 : -1; }
when compiled with:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
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++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.8 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux)
yields object code with different realizations and sizes.
What I observe:
$ gcc -Os -c cmp.c
(also shows with -O3)
$ readelf -s cmp.o
Num:Value Size TypeBind Vis Ndx Name
8: 16 FUNCGLOBAL DEFAULT1 comLG
9: 001016 FUNCGLOBAL DEFAULT1 comLE
10: 002018 FUNCGLOBAL DEFAULT1 comEL
11: 003218 FUNCGLOBAL DEFAULT1 comEG
12: 004418 FUNCGLOBAL DEFAULT1 comGL
13: 005618 FUNCGLOBAL DEFAULT1 comGE
$ objdump -d cmp.o -Mintel
comLG:
0: 31 d2 xoredx,edx
2: 39 f7 cmpedi,esi
4: b8 ff ff ff ff moveax,0x
9: 0f 9f c2setg dl
c: 0f 4d c2cmovge eax,edx
f: c3 ret
0010 comLE:
10: 31 d2 xoredx,edx
12: 39 f7 cmpedi,esi
14: b8 ff ff ff ff moveax,0x
19: 0f 95 c2setne dl
1c: 0f 4d c2cmovge eax,edx
1f: c3 ret
0020 comEL:
20: 39 f7 cmpedi,esi
22: 74 0b je 2f comEL+0xf
24: 0f 9d c0setge al
27: 0f b6 c0movzx eax,al
2a: 8d 44 00 ff leaeax,[rax+rax*1-0x1]
2e: c3 ret
2f: 31 c0 xoreax,eax
31: c3 ret
0032 comEG:
32: 39 f7 cmpedi,esi
34: 74 0b je 41 comEG+0xf
36: 0f 9f c0setg al
39: 0f b6 c0movzx eax,al
3c: 8d 44 00 ff leaeax,[rax+rax*1-0x1]
40: c3 ret
41: 31 c0 xoreax,eax
43: c3 ret
0044 comGL:
44: 39 f7 cmpedi,esi
46: b8 01 00 00 00 moveax,0x1
4b: 7f 08 jg 55 comGL+0x11
4d: 0f 9c c0setl al
50: 0f b6 c0movzx eax,al
53: f7 d8 negeax
55: c3 ret
0056 comGE:
56: 39 f7 cmpedi,esi
58: b8 01 00 00 00 moveax,0x1
5d: 7f 08 jg 67 comGE+0x11
5f: 0f 95 c0setne al
62: 0f b6 c0movzx eax,al
65: f7 d8 negeax
67: c3 ret
What I expected instead:
All functions to have the same asm.
[Bug rtl-optimization/59429] Missed optimization opportunity in qsort-style comparison functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429 --- Comment #2 from Jan Engelhardt jengelh at inai dot de --- Suppose all functions are used and taken.
[Bug rtl-optimization/59429] Missed optimization opportunity in qsort-style comparison functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429 --- Comment #3 from Jan Engelhardt jengelh at inai dot de --- I took it Component: rtl-optimization meant Register Transfer Language, not Runtime Linking. If needed, please reassign to whatever component is actually applicable. I am looking for a compiler enhancement so that the functions _become_ equal, not a way to eliminate duplicate functions.
[Bug c/59125] New: [4.8 regression] gcc triggers wrong strncpy_chk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59125
Bug ID: 59125
Summary: [4.8 regression] gcc triggers wrong strncpy_chk
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Given this compiler version/variant:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
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++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.2 20131016 [gcc-4_8-branch revision 203692] (SUSE Linux)
and this source:
#include string.h
union u {
struct {
char vi[8];
char pi[16];
};
char all[8+16+4];
};
void f(union u *u)
{
char vi[8+1];
char pi[16+1];
strncpy(vi, u-vi, sizeof(u-vi));
strncpy(pi, u-pi, sizeof(u-pi));
strncpy(u-all, AbcdefghAbcdefghijklmnopAbcd, sizeof(u-all));
}
I observe:
$ gcc-4.8 -O2 -D_FORTIFY_SOURCE=2 -c test.c
In file included from /usr/include/string.h:638:0,
from sci.c:1:
In function ‘strncpy’,
inlined from ‘f’ at sci.c:15:9:
/usr/include/bits/string3.h:120:3: warning: call to __builtin___strncpy_chk
will always overflow destination buffer [enabled by default]
return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
^
$ gcc-4.7 -O2 -D_FORTIFY_SOURCE=2 -c sci.c
$ clang -O2 -D_FORTIFY_SOURCE=2 -c sci.c
I would have expected:
gcc-4.8 to do as gcc-4.7 did and remain silent. I cannot see anything wrong
with the strncpy lines…
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283 --- Comment #2 from Jan Engelhardt jengelh at inai dot de --- Oh, -DPRECOMP `wx-config --cflags` is a remnant and may be removed from the Makefile. The issue continues to be reproducible. It appears on openSUSE Factory's gcc 4.8. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper 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++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.8 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.8.1 20130806 [gcc-4_8-branch revision 201525] (SUSE Linux)
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283 --- Comment #4 from Jan Engelhardt jengelh at inai dot de --- you cannot include a precompiled header from inside another header. Ok. So, this limitation was properly implemented in gcc 4.7, which simply skipped over the indirectly-included .gch file as if it did not exist. Safe thing to do. In gcc 4.8 however, the indirectly-included .gch *is* used rather than skipped, which I base upon the observation that compile time goes down significantly for projects with larger amounts of C++ code and the same indirect-inclusion scheme.
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283 --- Comment #6 from Jan Engelhardt jengelh at inai dot de --- It seems to be ineffective.
[Bug c/58283] New: Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283
Bug ID: 58283
Summary: Incorrect debug info when precompilation is on
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Created attachment 30731
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30731action=edit
testcase
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper
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++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7
--enable-ssp --disable-libssp --disable-libitm --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.7 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux)
GNU ld (GNU Binutils; openSUSE 12.3) 2.23.1
Testcase is appended. What I observe with it:
$ make
gcc-4.8 -gdwarf-2 -g3 -O0 -DPRECOMP -o pc1.h.gch -c pc1.h
gcc-4.8 -gdwarf-2 -g3 -O0 -DPRECOMP -o x m.c
nm -C x | grep main
U __libc_start_main
00400560 T main
addr2line -e x $(nm -C x | grep ' main$' | awk '{print $1}')
/usr/include/stdio.h:947
What I would have expected:
Have addr2line return m.c:3.
Additional information:
I do get addr2line to output m.c:3 if I include pc1.h instead of pc.h
from m.c. So this problem seems to be related with headers including
(precompiled) headers. In fact, gcc-4.7.2 even ignored pc1.h.gch (itself a bug,
or a non-implemented feature) if m.c includes pc.h, which means I don't get
wrong line numbers on gcc-4.7.
The outputting of wrong line numbers also occurs if compiled as C++ code.
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 Jan Engelhardt jengelh at inai dot de changed: What|Removed |Added CC||hjl at gcc dot gnu.org --- Comment #2 from Jan Engelhardt jengelh at inai dot de 2012-11-06 16:19:09 UTC --- Thanks for the description. It seems that what you say also affects the x32 mode (-mx32) for x86_64, am I correct in that observation?
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 --- Comment #5 from Jan Engelhardt jengelh at inai dot de 2012-11-07 00:00:01 UTC --- Dave, what do you think about a new mode for SPARC similar to -mx32, in other words, -m64+ILP32?
[Bug c/54088] ICE at dwarf2out.c:20632 with -O1 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54088 Jan Engelhardt jengelh at inai dot de changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #6 from Jan Engelhardt jengelh at inai dot de 2012-07-31 10:22:21 UTC --- Well it seems rev 187605 just did not fix it; it certainly is in the tarball. (Richard, you prepare the tarballs that go into the openSUSE Build Service..)
[Bug c/54088] ICE at dwarf2out.c:20632 with -O1 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54088 --- Comment #8 from Jan Engelhardt jengelh at inai dot de 2012-07-31 11:04:01 UTC --- The ICE continues to occur even if I leave out the handful of openSUSE patches.
