[Bug c++/94045] New: [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94045 Bug ID: 94045 Summary: [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: manisandro at gmail dot com Target Milestone: --- The following preprocessed source $ wget https://smani.fedorapeople.org/tmp/test.ii compiled with $ gcc -O2 -g -m32 -march=i686 -mtune=generic -c test.ii -o test.o results in GCC hanging, eating 100% of CPU core. Only reproducible on i686 (real world case is [1]). Using gcc-10.0.1-0.8.fc33.x86_64 $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200216 (Red Hat 10.0.1-0.8) (GCC [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=42199321
[Bug c++/56438] New: [4.8 regression] ICE in value_dependent_expression_p, at cp/pt.c:19551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56438
Bug #: 56438
Summary: [4.8 regression] ICE in value_dependent_expression_p,
at cp/pt.c:19551
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: manisan...@gmail.com
gcc version 4.8.0 20130220 (Red Hat 4.8.0-0.14) (GCC)
g++ -c ice.cc
ice.cc: In function ‘void foo()’:
ice.cc:19:25: internal compiler error: in value_dependent_expression_p, at
cp/pt.c:19551
a << bar(b.size(), C());
^
== ice.cc ==
struct A { };
A& operator<<(A&, const char*);
struct B {
int size();
};
struct C { };
template
S bar(const S& s, const T& t) {
return s;
}
template
void foo() {
A a;
B b;
a << bar(b.size(), C());
}
===
gcc version 4.7.2 20121109 (Red Hat 4.7.2-9) (GCC), gives get the expected
result
g++ -c ice.cc
ice.cc: In function ‘void foo()’:
ice.cc:19:25: error: no match for ‘operator<<’ in ‘a << bar(b.B::size(), C())’
ice.cc:19:25: note: candidate is:
ice.cc:2:4: note: A& operator<<(A&, const char*)
ice.cc:2:4: note: no known conversion for argument 2 from ‘int’ to ‘const
char*’
[Bug tree-optimization/56661] New: [4.8 regression] Incorrect code with -O1 -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56661
Bug #: 56661
Summary: [4.8 regression] Incorrect code with -O1 -ftree-pre
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: manisan...@gmail.com
Using gcc version 4.8.0 20130316 (Red Hat 4.8.0-0.17)
- main.c -
typedef long unsigned int size_t;
extern int printf (const char *__restrict __format, ...);
extern void *malloc (size_t __size) __attribute__ ((__nothrow__ , __leaf__))
__attribute__ ((__malloc__));
void setb(int* b);
void foo(int x){
if(x == 0){
int* b = malloc(3*sizeof(int));
while(b[0]);
}else if(x == 1){
int i, j;
int* b = malloc(3*sizeof(int));
for(i = 0; i < 2; i++){
setb(b);
for(j = 0; j < 3; ++j){
printf("%d ", b[j]);
}
printf("\nb[0] = %d\n", b[0]);
}
}
}
extern int g_x;
int main(){
foo(g_x);
return 0;
}
- stuff.c -
void setb(int* b){
b[0] = b[1] = b[2] = 1;
}
int g_x = 1;
---
$ gcc -O1 -ftree-pre -o test main.c stuff.c
$ ./test
1 1 1
b[0] = 0
1 1 1
b[0] = 0
Works with gcc version 4.7.2 20121109 (Red Hat 4.7.2-8)
[Bug translation/58087] New: Huge memory consumption with #pragma GCC optimize, __attribute__ and long output paths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58087 Bug ID: 58087 Summary: Huge memory consumption with #pragma GCC optimize, __attribute__ and long output paths Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: manisandro at gmail dot com Using gcc version 4.8.1 20130717 (Red Hat 4.8.1-5) (GCC) Description: Any code containing #pragma GCC optimize, lots of __attribute__(()) will result in cc1 taking up huge amounts of memory _depending_ on the length of the output path. Test case: $ for i in $(seq 1 1); do echo -e "void __attribute__(()) fz$i();" >> test.h; done $ cat > test.c <https://gist.github.com/netj/526585/raw/9044a9972fd71d215ba034a38174960c1c9079ad/memusg $ chmod +x memusg $ mkdir a $ ./memusg gcc -c -o a/test.o test.c memusg: peak=485796 $ mkdir aaa $ ./memusg gcc -c -o aaa/test.o test.c memusg: peak=4827100 Observations: - The "-O1" is not important, passing any other string to #pragma GCC optimize (regardless of whether it is valid or invalid) will also trigger the issue - As noted, the memory consumption depends on the length of the output path
[Bug debug/86593] New: [8.0 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593
Bug ID: 86593
Summary: [8.0 Regression] internal compiler error: in
based_loc_descr, at dwarf2out.c:14272
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: manisandro at gmail dot com
Target Milestone: ---
Following is reproducible using mingw64-gcc-8.1.0-2.fc29 [1] on Fedora Rawhide,
and only when compiling for x86_64-w64-mingw32 (and not i686-w64-mingw32).
I could also reproduce it with gcc-8.2.0-RC-20180719.tar.xz built for mingw64.
I could not reproduce it with native gcc.
The issue also did not appear with mingw64-gcc-7.2.0-1.fc28.x86_64
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1114148
This program:
struct Foo
{
int bar(int a, int b, int c, int d);
};
int Foo::bar(int a, int b, int c, int d)
{
return 0;
}
compiled as
x86_64-w64-mingw32-g++ -O -g -fno-omit-frame-pointer -o test.o -c test.cpp
produces:
during RTL pass: final
test.cpp: In member function 'int Foo::bar(int, int, int, int)':
test.cpp:9:1: internal compiler error: in based_loc_descr, at dwarf2out.c:14272
}
^
All three of "-O -g -fno-omit-frame-pointer" are needed to reproduce the crash.
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #2 from Sandro Mani --- Started with commit cd557ff63f388ad27c376d0a225e74d3594a6f9d Author: hjl Date: Thu Aug 10 15:29:05 2017 + i386: Don't use frame pointer without stack access When there is no stack access, there is no need to use frame pointer even if -fno-omit-frame-pointer is used and caller's frame pointer is unchanged. gcc/ PR target/81736 * config/i386/i386.c (ix86_finalize_stack_realign_flags): Renamed to ... (ix86_finalize_stack_frame_flags): This. Also clear frame_pointer_needed if -fno-omit-frame-pointer is used without stack access. (ix86_expand_prologue): Replace ix86_finalize_stack_realign_flags with ix86_finalize_stack_frame_flags. (ix86_expand_epilogue): Likewise. (ix86_expand_split_stack_prologue): Likewise. * doc/invoke.texi: Add a note for -fno-omit-frame-pointer. gcc/testsuite/ PR target/81736 * gcc.target/i386/pr81736-1.c: New test. * gcc.target/i386/pr81736-2.c: Likewise. * gcc.target/i386/pr81736-3.c: Likewise. * gcc.target/i386/pr81736-4.c: Likewise. * gcc.target/i386/pr81736-5.c: Likewise. * gcc.target/i386/pr81736-6.c: Likewise. * gcc.target/i386/pr81736-7.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@251028 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 Sandro Mani changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from Sandro Mani --- @hjl.to...@gmail.com Any ideas?
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #6 from Sandro Mani --- Looking good for my use-cases, thanks!
[Bug c++/87137] New: [8 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137
Bug ID: 87137
Summary: [8 Regression] Non-virtual member function increases
struct size
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manisandro at gmail dot com
Target Milestone: ---
With gcc-8.0.0 onwards, specifically commit
ab87ee8f509c0b600102195704105d4d98ec59d9, the following test case fails to
compile using either i686-w64-mingw32-g++ or x86_64-w64-mingw32-g++ (but
compiles normally using the native x86_64-linux-g++):
--- test.cpp ---
template
void check_size() {
static_assert(ExpectedSize == RealSize, "Size is off!");
}
struct Foo {
unsigned u1 : 5;
unsigned u2 : 5;
unsigned u3 : 3;
unsigned u4 : 3;
unsigned u5 : 4;
unsigned u6 : 2;
unsigned u7 : 3;
unsigned u8 : 2;
unsigned u9 : 1;
unsigned u10 : 3;
// 31 bits
unsigned u11 : 2;
unsigned u12 : 2;
unsigned u13 : 2;
unsigned u14 : 6;
unsigned u15 : 7;
unsigned u16 : 1;
unsigned u17 : 1;
unsigned u18 : 1;
unsigned u19 : 1;
unsigned u20 : 1;
bool bar() const { return false; }
private:
unsigned u21 : 1;
unsigned u22 : 1;
unsigned u23 : 1;
unsigned u24 : 1;
// 59 bits
};
int main(int argc, char* argv[]) {
check_size();
return 0;
}
-
$ x86_64-w64-mingw32-g++ test.cpp -o test.exe
test.cpp: In instantiation of 'void check_size() [with ToCheck = Foo; unsigned
int ExpectedSize = 8; unsigned int RealSize = 12]':
test.cpp:41:24: required from here
test.cpp:3:30: error: static assertion failed: Size is off!
static_assert(ExpectedSize == RealSize, "Size is off!");
Notice the presence of the bar member function. Without the member function,
sizeof(Foo) = 8 as expected, but with the member function, sizeof(Foo) = 12.
[Bug c++/87137] [8 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 Sandro Mani changed: What|Removed |Added Target||i686-w64-mingw32, ||x86_64-w64-mingw32 CC||nathan at acm dot org --- Comment #1 from Sandro Mani --- CC nat...@acm.org as author of ab87ee8f509c0b600102195704105d4d98ec59d9
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #7 from Sandro Mani --- Any chance of getting the fix committed?
[Bug c++/87137] [8 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 --- Comment #3 from Sandro Mani --- See https://github.com/gcc-mirror/gcc/commit/ab87ee8f509c0b600102195704105d4d98ec59d9
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #9 from Sandro Mani --- Thanks --- Comment #10 from Sandro Mani --- Thanks
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #9 from Sandro Mani --- Thanks --- Comment #10 from Sandro Mani --- Thanks
[Bug c++/71076] New: Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71076
Bug ID: 71076
Summary: Internal compiler error
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manisandro at gmail dot com
Target Milestone: ---
Following is with gcc version 6.1.1 20160510 (Red Hat 6.1.1-2) (GCC)
Following code snippet compiled as
g++ -c -O foo.cpp -o foo.o
produces an ICE:
foo.cpp:
extern "C" {
extern float sqrtf (float);
}
template struct Foo
{
Foo();
T a() const;
Foo b() const;
};
template
Foo Foo::b() const
{
T x = a();
T y = x < 0 ? 0 : ::sqrtf (x);
return y == T(0) ? Foo() : Foo();
}
struct Bar
{
~Bar();
};
void foo()
{
Bar bar;
Foo dir = Foo().b();
}
[Bug middle-end/58087] Huge memory consumption with #pragma GCC optimize, __attribute__ and long output paths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58087 Sandro Mani changed: What|Removed |Added Component|translation |middle-end Version|4.8.1 |4.8.2 --- Comment #1 from Sandro Mani --- Still applies to 4.8.2. Changing component to a (hopefully) more relevant one.
[Bug c++/65057] New: Broken shared library if created with -fuse-ld=gold -shared -Wl,--dynamic-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65057 Bug ID: 65057 Summary: Broken shared library if created with -fuse-ld=gold -shared -Wl,--dynamic-list Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: manisandro at gmail dot com Created attachment 34752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34752&action=edit testcase What follows is with gcc-5.0.0-0.10.fc22.x86_64 (Fedora rawhide). See test case attached, build and run with the provided build.sh script. Overview: - A base class in a shared library (base.h, base.cpp) - The shared library is linked with -fuse-ld=gold -shared -Wl,--dynamic-list, the contents of the actual list provided to --dynamic-list does not seem to matter (in the provided testcase, the name of the symbol is made up). - A derived class in an application linking with the library (derived.h, derived.cpp) - Some random class which uses the derived class Problem: - The assertion at derived.h:25 fails => Derived::Derived calls Base::Base passing a DerivedPrivate instance to the base class, then Derived::Derived calls Base::init, which sets Base::self to the instance pointer this and calls DerivedPrivate::foo on the passed DerivedPrivate instance, which tests that Base::self is not null. This incorrectly fails. Background: This is causing Qt5 applications to crash in various ways.
[Bug c++/65057] Broken shared library if created with -fuse-ld=gold -shared -Wl,--dynamic-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65057 --- Comment #3 from Sandro Mani --- Yes, without -fuse-ld=gold it works. What I forgot to mention: qt worked with gcc 4.9 (and the options passed to the Qt configure script haven't changed). The build log of a qt5-qtbase build built with gcc 4.9 shows that it was also built using the gold linker. So this really appears to be a gcc 5.0 regression.
[Bug c++/65209] New: [5.0 regression] Broken code with global static variables, invalid pointer when freeing global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65209 Bug ID: 65209 Summary: [5.0 regression] Broken code with global static variables, invalid pointer when freeing global variables Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: manisandro at gmail dot com Created attachment 34870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34870&action=edit testcase Using gcc-5.0.0-0.15.fc23.x86_64 Test case attached. Build with $ g++ -g -Wall -o main foo.cpp main.cpp The test case crashes when freeing global variables: ./main *** Error in `/home/sandro/Desktop/a/main': free(): invalid pointer: 0x00610001 *** #0 0x771a6ae8 in raise () from /lib64/libc.so.6 #1 0x771a877a in abort () from /lib64/libc.so.6 #2 0x771eb092 in __libc_message () from /lib64/libc.so.6 #3 0x771f2994 in _int_free () from /lib64/libc.so.6 #4 0x771f748c in free () from /lib64/libc.so.6 #5 0x0040099b in FooData::~FooData (this=0x602118 <_ZGVZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvE6holder>, __in_chrg=) at foo.cpp:5 #6 0x004009da in Foo::~Foo (this=0x602100 <_ZZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvE6holder>, __in_chrg=) at foo.cpp:8 #7 0x00400a12 in FooSingleton::~FooSingleton (this=0x602100 <_ZZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvE6holder>, __in_chrg=) at foo.cpp:15 #8 0x00400a69 in (anonymous namespace)::Q_QGS_s_self::innerFunction()::Holder::~Holder() ( this=0x602100 <_ZZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvE6holder>, __in_chrg=) at foo.cpp:33 #9 0x771ab628 in __run_exit_handlers () from /lib64/libc.so.6 #10 0x771ab675 in exit () from /lib64/libc.so.6 #11 0x77191847 in __libc_start_main () from /lib64/libc.so.6 #12 0x004007e9 in _start () Observations: - Depends on the Q_QGS_s_self namespace being called such (more precisely, exactly such, not even any other name with equal length) - Depends on the innerFunction method being called such - Depends on innerFunction being inline - Depends on the size of the global variables
[Bug c++/65209] [5 Regression] Broken code with global static variables, invalid pointer when freeing global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65209 --- Comment #2 from Sandro Mani --- Created attachment 34874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34874&action=edit Slightly reduced test case ==30483== Invalid free() / delete / delete[] / realloc() ==30483==at 0x4C2D143: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30483==by 0x400983: Foo::~Foo() (foo.cpp:4) ==30483==by 0x40099F: (anonymous namespace)::Q_QGS_s_self::innerFunction()::Holder::~Holder() (foo.cpp:21) ==30483==by 0x570F627: __run_exit_handlers (in /usr/lib64/libc-2.21.90.so) ==30483==by 0x570F674: exit (in /usr/lib64/libc-2.21.90.so) ==30483==by 0x56F5846: (below main) (in /usr/lib64/libc-2.21.90.so) ==30483== Address 0x1 is not stack'd, malloc'd or (recently) free'd
