[Bug c++/110078] New: [13 regression] Excessive memory usage constructing std::variant from a high-index alternative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110078 Bug ID: 110078 Summary: [13 regression] Excessive memory usage constructing std::variant from a high-index alternative. Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: toojays at toojays dot net Target Milestone: --- Created attachment 55233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55233=edit Reproducer demonstrating excessive memory use constructing std::variant from a high-index alternative. The attached source contains a function which constructs a std::variant<29 alternatives> from the 29th alternative. Attempting to compile it with GCC 13.1 results in cc1plus consuming more than 20GiB of memory before being killed. GCC 12.2.0 is able to compile it promptly with no apparent problems. $ g++-13 -v Using built-in specs. COLLECT_GCC=/opt/acacia/3rd-party/gcc-13.1.0-1/bin/g++ COLLECT_LTO_WRAPPER=/opt/acacia/3rd-party/gcc-13.1.0-1/libexec/gcc/x86_64-pc-linux-gnu/13.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /docker-20.04-build/extract/gcc-13.1.0/configure --prefix=/opt/acacia/3rd-party/gcc-13.1.0-1 CPPFLAGS=-I/opt/acacia/3rd-party/gcc-13.1.0-1/include CFLAGS='-O2 -g -fno-omit-frame-pointer' CXXFLAGS='-O2 -g -fno-omit-frame-pointer' --enable-languages=c,c++,d --disable-multilib --with-system-zlib --enable-checking=release --program-prefix= --program-suffix= --with-gmp=/opt/acacia/3rd-party/gcc-13.1.0-1 --with-mpfr=/opt/acacia/3rd-party/gcc-13.1.0-1 --with-mpc=/opt/acacia/3rd-party/gcc-13.1.0-1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.1.0 (GCC)
[Bug c/80354] Poor support to silence -Wformat-truncation=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80354 John Steele Scott changed: What|Removed |Added CC||toojays at toojays dot net --- Comment #6 from John Steele Scott --- (In reply to Stephan Bergmann from comment #5) > (In reply to Martin Sebor from comment #3) > > The warning does just what it's designed to do: point out the potential > > unhandled truncation. > > But it is unusable in practice if there is no reliable way to silence false > positives. ^- This! A simple cast-to-void is the conventional way to indicate to the compiler that it should consider the value as having been consumed even though it wasn't really. It's a real shame if this information is not available to the code that generates this warning. (In reply to Martin Sebor from comment #1) > Besides actually handling the truncation (e.g., branching on > it and taking some action that does affect the behavior), storing the return > value in a volatile variable and reading it should suppress it. Thanks for the tip. For isolated instances this may be less invasive than what I have been contemplating (checking the return value and calling some no-op function). It would be better if there were some solution that didn't generate unnecessary code though.
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 John Steele Scott changed: What|Removed |Added CC||toojays at toojays dot net --- Comment #14 from John Steele Scott --- FWIW Clang has this warning via -Wnon-pod-varargs.
[Bug debug/78247] New: Unused inline function returning u32string causes u32string debuginfo to be emitted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78247
Bug ID: 78247
Summary: Unused inline function returning u32string causes
u32string debuginfo to be emitted.
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: toojays at toojays dot net
Target Milestone: ---
Consider the following source, compiled with and without MORE_BLOAT defined:
jscott@citra:~/src/debuginfo-bloat$ cat bloat-string.cpp
#include
#ifdef MORE_BLOAT
inline std::u32string f(const char32_t* __str, size_t __len)
{ return std::u32string{__str, __len}; }
#endif
jscott@citra:~/src/debuginfo-bloat$ g++-6 -std=c++11 -gdwarf-4 -c
bloat-string.cpp -o bloat-string.o
jscott@citra:~/src/debuginfo-bloat$ g++-6 -DMORE_BLOAT -std=c++11 -gdwarf-4 -c
bloat-string.cpp -o bloat-string-more.o
jscott@citra:~/src/debuginfo-bloat$ ls -l bloat-string.o bloat-string-more.o
-rw-rw-r-- 1 jscott jscott 61256 Nov 8 13:58 bloat-string-more.o
-rw-rw-r-- 1 jscott jscott 24672 Nov 8 13:58 bloat-string.o
I.e. if I have an inline function refering to u32string it bloats my output
object by 40K, even though I never used that function. The extra space seems to
go toward debug info for u32string and its associated char_traits.
In effect this occurs whenever someone switches from -std=c++11 to -std=c++14,
because of the inline string literal operators at the end of basic_string.h.
I originally noticed this because switching from -std=c++11 to -std=c++14
increased the size of generated binaries. Discussion at
<https://gcc.gnu.org/ml/gcc-help/2016-11/msg6.html>.
I tried to create a smaller example (i.e. not requiring ), but couldn't
figure out how. The only types I have seen affected by this problem so far are
u16string and u32string.
My test setup:
jscott@citra:~/src/debuginfo-bloat$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
6.2.0-3ubuntu11~14.04' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~14.04)
[Bug c++/60972] New: Mixing #pragma pack and __attribute__((packed)) leads to spurious warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60972
Bug ID: 60972
Summary: Mixing #pragma pack and __attribute__((packed)) leads
to spurious warnings.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: toojays at toojays dot net
┌(toojays@kano)─(568)─(0)─(2014 04 26 10:35:27)
└─(/tmp)─ /opt/gcc-4.9/bin/gcc --version | head -n1
gcc (GCC) 4.9.0
┌(toojays@kano)─(569)─(0)─(2014 04 26 10:35:35)
└─(/tmp)─ cat packed.cpp
#include cstdint
#include type_traits
#pragma pack(push, 1)
struct A
{
private:
uint16_t x;
uint32_t y;
public:
A () = default;
A (uint16_t x_, uint32_t y_) : x(x_), y(y_) {}
};
#pragma pack(pop)
struct __attribute__((packed)) B
{
A xx;
uint32_t yy;
A zz;
};
A a;
B b;
static_assert(std::is_podA::value, Expect A to be POD.);
static_assert(std::is_podB::value, Expect B to be POD.);
┌(toojays@kano)─(570)─(0)─(2014 04 26 10:35:46)
└─(/tmp)─ /opt/gcc-4.9/bin/gcc -std=c++11 -o packed.o -c packed.cpp -g
packed.cpp:22:5: warning: ignoring packed attribute because of unpacked non-POD
field ‘A B::xx’
A xx;
^
packed.cpp:26:5: warning: ignoring packed attribute because of unpacked non-POD
field ‘A B::zz’
A zz;
I have three problems with these warnings:
1) The warning claims that A is non-POD, but the type trait disagrees.
2) The warning claims that A is not-packed, but in fact it is.
3) Despite saying the attribute would be ignored, GCC went ahead and packed
struct B anyway. I am on amd64. If B is not packed then B::yy would be aligned
to a 4-byte boundary. Instead, the structures are packed, as shown:
┌(toojays@kano)─(571)─(0)─(2014 04 26 10:36:19)
└─(/tmp)─ pahole packed.o
die__process_class: tag not supported (template_type_parameter)!
die__process_class: tag not supported (template_value_parameter)!
struct A {
private:
uint16_t x;/* 0 2 */
uint32_t y;/* 2 4 */
void A(class A *);
void A(class A *, uint16_t, uint32_t);
/* size: 6, cachelines: 1, members: 2 */
/* last cacheline: 6 bytes */
};
struct B {
struct A xx; /* 0 6 */
uint32_t yy; /* 6 4 */
struct A zz; /*10 6 */
void B(class B *);
/* size: 16, cachelines: 1, members: 3 */
/* last cacheline: 16 bytes */
};
If I consistently use #pragma or __attribute__ for both structures, GCC does
not complain, and my structures are packed as I would expect.
[Bug sanitizer/60892] New: GCC fails to build with Linux 2.6.21 headers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60892 Bug ID: 60892 Summary: GCC fails to build with Linux 2.6.21 headers. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: toojays at toojays dot net 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 I got the following errors while trying to build gcc-4.9 (from the 20140416 snapshot) for a Linux 2.6.21 system (Maemo 4 / diablo). Configuration was run via ../gcc-4.9-20140416/configure --program-suffix=-4.9 --disable-shared --enable-languages=c,c++ --enable-checking=release I got not complaints from the, but the build failed at: xgcc -B/home/maemo/gcc-4.9-20140416/build-dir/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.9-20140416/libquadmath -I ../../../gcc-4.9-20140416/libquadmath/../include -g -O2 -MT math/catanq.lo -MD -MP -MF $depbase.Tpo -c -o math/catanq.lo ../../../gcc-4.9-20140416/libquadmath/math/catanq.c \ mv -f $depbase.Tpo $depbase.Plo ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:390:30: error: 'EVIOCGREP' was not declared in this scope unsigned IOCTL_EVIOCGREP = EVIOCGREP; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:399:30: error: 'EVIOCSREP' was not declared in this scope unsigned IOCTL_EVIOCSREP = EVIOCSREP; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:682:36: error: 'FS_IOC_GETFLAGS' was not declared in this scope unsigned IOCTL_FS_IOC_GETFLAGS = FS_IOC_GETFLAGS; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:683:38: error: 'FS_IOC_GETVERSION' was not declared in this scope unsigned IOCTL_FS_IOC_GETVERSION = FS_IOC_GETVERSION; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:684:36: error: 'FS_IOC_SETFLAGS' was not declared in this scope unsigned IOCTL_FS_IOC_SETFLAGS = FS_IOC_SETFLAGS; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:685:38: error: 'FS_IOC_SETVERSION' was not declared in this scope unsigned IOCTL_FS_IOC_SETVERSION = FS_IOC_SETVERSION; http://gcc.gnu.org/install/specific.html does not mention a minimum kernel version for GCC. http://gcc.gnu.org/install/configure.html does not explain how to disable building the sanitizer. I don't particularly mind if I can't have the sanitizer, but expect the GCC configure script to detect that, and disable the sanitizer build automatically. This bug is similar in spirit to bug 59068, but I'm filing a separate issue since the root cause is different.
[Bug c/38927] New: _mm_set_epi32 does not set the third argument if the fourth argument is a constant.
This bug appears in all of the gcc 4.0.x series, but does not occur in the 4.1.x series. If you create an __m128i vector using _mm_set_epi32(a, b, c, K), where a, b and c are variables, and K is a compile-time constant, the resulting vector has zeros where the value of c should be. This problem only occurs when optimisation is enabled. -- Summary: _mm_set_epi32 does not set the third argument if the fourth argument is a constant. Product: gcc Version: 4.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toojays at toojays dot net GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38927
[Bug c/38927] _mm_set_epi32 does not set the third argument if the fourth argument is a constant.
--- Comment #1 from toojays at toojays dot net 2009-01-21 04:53 --- Created an attachment (id=17157) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17157action=view) Test case which shows fault with _mm_set_epi32 in gcc 4.0.x. Simple testcase to show the problem with _mm_set_epi32(a, b, c, 0x). With GCC 4.1.0: jsc...@gypsum:/local/jscott$ touch test.c make CFLAGS=-march=pentium4 -O2 CC=/local/jscott/install-gcc-4.1.0/bin/gcc test ./test /local/jscott/install-gcc-4.1.0/bin/gcc -march=pentium4 -O2test.c -o test Vector content is 0x. Should be 0x. But with GCC 4.0.4: jsc...@gypsum:/local/jscott$ touch test.c make CFLAGS=-march=pentium4 -O2 CC=/local/jscott/install-gcc-4.0.4/bin/gcc test ./test /local/jscott/install-gcc-4.0.4/bin/gcc -march=pentium4 -O2test.c -o test Vector content is 0x. Should be 0x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38927
