Bug c++/19317 still appears to exist
Hi, Whilst this bug has been marked as resolved, I am still experiencing the same problems (with arts-1.4.91 - the version shipped with KDE 35. Beta 1). My gcc version info : gcc (GCC) 4.1.0 20050924 (experimental) The following is the stack dump for the problem: --- Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1209124384 (LWP 31570)] [KCrash handler] #4 0x0034ffe3 in __gnu_cxx::__pool::_M_reclaim_block (this=0xa91b20, __p=0x84e6378 "\234�\b�\b�N\b", __bytes=4) at ../../.././libstdc++-v3/src/mt_allocator.cc:254 #5 0x00a71f37 in __gnu_cxx::__mt_alloc >::deallocate (this=0xbfc15838, __p=0x84e6378, __n=1) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/ext/mt_allocator.h:711 #6 0x00a71f71 in std::_Vector_base >::_M_deallocate (this=0xbfc15838, __p=0x84e6378, __n=1) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:129 #7 0x00a71fae in ~_Vector_base (this=0xbfc15838) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:115 #8 0x00a72017 in ~vector (this=0xbfc15838) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:268 #9 0x00a7204a in ~ObjectReference (this=0xbfc1582c) at ../mcop/core.h:117 #10 0x00a5adc7 in Arts::SoundServerStartup_base::_fromString ( [EMAIL PROTECTED]) at soundserver.cc:2545 #11 0x08067572 in SoundServerStartup (this=0xbfc158b0, [EMAIL PROTECTED]) at soundserver.h:1376 #12 0x08066b83 in Arts::SoundServerStartup_impl::cleanReference ( this=0x853e6f8) at soundserverstartup_impl.cc:54 #13 0x08066cc1 in Arts::SoundServerStartup_impl::lock (this=0x853e6f8) at soundserverstartup_impl.cc:78 #14 0x08062bf9 in Arts::SoundServerStartup::lock (this=0xbfc15a58) at soundserver.h:2082 #15 0x080624ac in main (argc=14, argv=0xbfc15b74) at artsd.cc:293 --- As I am far from an expert in gcc I'll outline how I installed the development version. --- export CVS_RSH=ssh export CVSROOT=":ext:[EMAIL PROTECTED]:/cvsroot/gcc" cvs -z9 checkout -P gcc wwwdocs cd gcc ./configure make -j 2 make install --- Cheers, Kevin Gilbert
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- Comment #4 from davejmurphy at me dot com 2008-12-27 21:46 --- Created an attachment (id=16992) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16992&action=view) preprocessed source for arm-eabi testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- Comment #5 from davejmurphy at me dot com 2008-12-27 21:48 ---
(From update of attachment 16992)
I've tripped over this bug on arm-eabi too, with this code, compiled as thumb.
extern int doStreamReadBlock(int *, char *, int size, int);
char readStream(int *s)
{
char c = 0;
doStreamReadBlock(s, &c, 1, *s);
return c;
}
arm-eabi davem$ arm-eabi-gcc -v -O2 -mthumb -c test.c
Using built-in specs.
Target: arm-eabi
Configured with: ../../gcc-4.3.2/configure --enable-languages=c,c++
--with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc
--with-gnu-ld --with-gnu-as --disable-shared --disable-threads
--disable-win32-registry --disable-nls --disable-debug --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libstdcxx-pch --target=arm-eabi
--with-newlib --prefix=/opt/devkitpro/devkitARM
--with-bugurl=http://wiki.devkitpro.org/index.php/Bug_Reports
--with-pkgversion='devkitARM release 24'
Thread model: single
gcc version 4.3.2 (devkitARM release 24)
:
0: b510push{r4, lr}
2: b082sub sp, #8
4: 466cmov r4, sp
6: 3407addsr4, #7
8: 2300movsr3, #0
a: 7023strbr3, [r4, #0]
c: 1c21addsr1, r4, #0
e: 6803ldr r3, [r0, #0]
10: 2201movsr2, #1
12: f7ff fffe bl 0
16: b002add sp, #8
18: 7820ldrbr0, [r4, #0]
1a: bc10pop {r4}
1c: bc02pop {r1}
1e: 4708bx r1
The same thing happens with mainline
/opt/devkitpro/devkitARM_mainline/bin/arm-eabi-gcc -v -O2 -mthumb -c test.c
Using built-in specs.
Target: arm-eabi
Configured with: ../../../gcc_mainline/configure --disable-nls
--target=arm-eabi --prefix=/opt/devkitPro/devkitARM --enable-languages=c,c++
--with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc
--with-gnu-ld --with-gnu-as --disable-shared --disable-threads
--disable-win32-registry --disable-nls --disable-debug --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libstdcxx-pch
Thread model: single
gcc version 4.4.0 20081223 (experimental) (GCC)
:
0: b510push{r4, lr}
2: b082sub sp, #8
4: 466cmov r4, sp
6: 3407addsr4, #7
8: 2300movsr3, #0
a: 7023strbr3, [r4, #0]
c: 1c21addsr1, r4, #0
e: 6803ldr r3, [r0, #0]
10: 2201movsr2, #1
12: f7ff fffe bl 0
16: b002add sp, #8
18: 7820ldrbr0, [r4, #0]
1a: bc10pop {r4}
1c: bc02pop {r1}
1e: 4708bx r1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug c/38644] New: Optimization flag -O1 -fschedule-insns2 causes wrong code
The -fschedule-insns2 optimisation causes wrong code to be emitted for the
following testcase. The assembly code loads a value from a stack frame which
has already been deallocated.
This is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282 for
powerpc-eabi.
extern int doStreamReadBlock(int *, char *, int size, int);
char readStream(int *s)
{
char c = 0;
doStreamReadBlock(s, &c, 1, *s);
return c;
}
arm-eabi davem$ arm-eabi-gcc -v -O2 -mthumb -c test.c
Using built-in specs.
Target: arm-eabi
Configured with: ../../gcc-4.3.2/configure --enable-languages=c,c++
--with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc
--with-gnu-ld --with-gnu-as --disable-shared --disable-threads
--disable-win32-registry --disable-nls --disable-debug --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libstdcxx-pch --target=arm-eabi
--with-newlib --prefix=/opt/devkitpro/devkitARM
--with-bugurl=http://wiki.devkitpro.org/index.php/Bug_Reports
--with-pkgversion='devkitARM release 24'
Thread model: single
gcc version 4.3.2 (devkitARM release 24)
:
0: b510push{r4, lr}
2: b082sub sp, #8
4: 466cmov r4, sp
6: 3407addsr4, #7
8: 2300movsr3, #0
a: 7023strbr3, [r4, #0]
c: 1c21addsr1, r4, #0
e: 6803ldr r3, [r0, #0]
10: 2201movsr2, #1
12: f7ff fffe bl 0
16: b002add sp, #8 <--- stack frame deallocated
18: 7820ldrbr0, [r4, #0]<--- value loaded from stack
frame
1a: bc10pop {r4}
1c: bc02pop {r1}
1e: 4708bx r1
The same thing happens with mainline
/opt/devkitpro/devkitARM_mainline/bin/arm-eabi-gcc -v -O2 -mthumb -c test.c
Using built-in specs.
Target: arm-eabi
Configured with: ../../../gcc_mainline/configure --disable-nls
--target=arm-eabi --prefix=/opt/devkitPro/devkitARM --enable-languages=c,c++
--with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc
--with-gnu-ld --with-gnu-as --disable-shared --disable-threads
--disable-win32-registry --disable-nls --disable-debug --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libstdcxx-pch
Thread model: single
gcc version 4.4.0 20081223 (experimental) (GCC)
:
0: b510push{r4, lr}
2: b082sub sp, #8
4: 466cmov r4, sp
6: 3407addsr4, #7
8: 2300movsr3, #0
a: 7023strbr3, [r4, #0]
c: 1c21addsr1, r4, #0
e: 6803ldr r3, [r0, #0]
10: 2201movsr2, #1
12: f7ff fffe bl 0
16: b002add sp, #8
18: 7820ldrbr0, [r4, #0]
1a: bc10pop {r4}
1c: bc02pop {r1}
1e: 4708bx r1
--
Summary: Optimization flag -O1 -fschedule-insns2 causes wrong
code
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davejmurphy at me dot com
GCC build triplet: i386-apple-darwin9.6.0
GCC host triplet: i386-apple-darwin9.6.0
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug c/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #1 from davejmurphy at me dot com 2008-12-27 22:10 --- Created an attachment (id=16993) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16993&action=view) preprocessed source for arm-eabi testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug web/3119] Broken gcc mailing list archives
--- Comment #8 from me at cgf dot cx 2005-12-10 05:45 --- Subject: Re: Broken gcc mailing list archives On Sat, Dec 10, 2005 at 05:30:21AM -, pinskia at gcc dot gnu dot org wrote: > >-- > >pinskia at gcc dot gnu dot org changed: > > What|Removed |Added > > Last reconfirmed|2005-09-07 16:53:59 |2005-12-10 05:30:21 > date|| > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3119 > >--- You are receiving this mail because: --- >You are the assignee for the bug, or are watching the assignee. Given the age of these bugs should we just close them as "wontfix"? I don't see anyone stepping up to fix them anytime soon. cgf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3119
[Bug target/92318] Nondeterministic ICE with -mcmodel=large -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92318 --- Comment #8 from cgf at gcc dot gnu.org --- email from sourceware
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #5 from Fangrui Song --- This bug exposes several problems: * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS symbol * GCC should not produce R_X86_64_PC32 referencing an external symbol in -fpie mode. % gcc -fuse-ld=lld -nostdlib -fpie -pie a.c % objdump -dr a.o ... : 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# b 7: R_X86_64_PC32_binary_a_c_size-0x4 b: 5d pop%rbp c: c3 retq % gcc -fuse-ld=bfd -nostdlib -fpie -pie a.c b.o -o a /usr/bin/ld.bfd: warning: cannot find entry symbol _start; defaulting to 1000 % objdump -dr a ... 1000 : 1000: 55 push %rbp 1001: 48 89 e5mov%rsp,%rbp 1004: 48 8d 05 39 f0 ff fflea-0xfc7(%rip),%rax# 44 <_binary_a_c_size> 100b: 5d pop%rbp 100c: c3 retq It is incorrect to reference a non-preemptible symbol with a PC relative relocation in a -pie link. GNU ld allows it but the code can be incorrect at runtime. lea-0xfc7(%rip),%rax # loads 44 to %rax only if the load base is 0. Due to ASLR (-pie), this is simply not true. lld correctly rejects the relocation. To fix this, I had a write-up last year: https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html We should change the configure-time HAVE_LD_PIE_COPYRELOC to an option, probably -f(no-)direct-access-extern In clang, HAVE_LD_PIE_COPYRELOC is a compile-time option: -mpie-copy-relocations. But I think we should improve the option name. At the very least, we can also let -fno-pic code reference an external symbol with GOT to avoid copy relocations. -f(no-)direct-access-extern may be a candidate.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #6 from Fangrui Song --- > It is incorrect to reference a non-preemptible symbol with a PC relative > relocation in a -pie link. GNU ld allows it but the code can be incorrect at > runtime. Correction: It is incorrect to reference a non-preemptible SHN_ABS symbol with a PC relative relocation in a PIC (-shared or -pie) link. This is non-representable due to ASLR (load base not fixed at link time)
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #10 from Fangrui Song ---
> extern unsigned long _binary_a_c_size;
> unsigned long foo() { return _binary_a_c_size; }
This is incorrect. The code will treat the value of _binary_a_c_size as an
address (load base + size) and dereference that address
mov-0xfc3(%rip),%rax# 44 <_binary_a_c_size>
> NO LLD is not implemented the ABI as PIE COPYRELOC is required by the ABI
> these days.
My objdump -d output in Comment #5 demonstrates that GNU ld linked code will be
incorrect at runtime.
It can be argued that either the user code or GCC does the wrong thing, but a
linker is not responsible for the mistake.
(I have argued lld does the right thing by erroring at link time.)
The compiler can ask the assembler to produce an indirect (GOT) reference.
The code (`unsigned long foo() { return (unsigned long)_binary_a_c_size; })
will work perfectly.
> Also it is wrong for a person to assume a normal C variable could be SHN_ABS;
> that is the bug here.
> It is a bug in the user code.
> I showed up to fix it by using an top level inline-asm.
-fno-pic and -fpic work fine. -fpie before commit
77ad54d911dd7cb88caf697ac213929f6132fdcf worked fine.
commit 77ad54d911dd7cb88caf697ac213929f6132fdcf ("x86-64: Optimize access to
globals in PIE with copy reloc")
is responsible for the -fpie change.
In 2015, H.J. invented R_X86_64_{REX,}GOTPCRELX. The linker relaxation is a
perfect solution.
We can retire HAVE_LD_PIE_COPYREL now.
// The code will still be faulty but we can argue that it is an user error.
__attribute__((visibility("hidden"))) extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }
The relaxed R_X86_64_{REX,}GOTPCRELX will be a bit longer than R_X86_64_PC32.
The difference is small enough and should not matter for practical use cases.
For those who care about the tiny regression, we can invent an option
-fdirect-access-extern (clang currently calls it -mpie-copy-relocations but we
can design a better name).
It is more useful on non-x86 architectures for a mostly statically linked
program.
extern int var; int foo(void) { return var; }
// clang -target aarch64 -fPIE -O3
adrpx8, :got:var
ldr x8, [x8, :got_lo12:var]
ldr w0, [x8]
ret
// clang -target aarch64 -fPIE -O3 -mpie-copy-relocations
adrpx8, var
ldr w0, [x8, :lo12:var]
ret
// x86-64
// clang -O3 -fPIE a.c -Wa,--mrelax-relocations=yes
0: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 7
3: R_X86_64_REX_GOTPCRELX var-0x4
7: 8b 00 mov(%rax),%eax
9: c3 retq
// clang -O3 -fPIE a.c -mpie-copy-relocations
0: 8b 05 00 00 00 00 mov0x0(%rip),%eax# 6
2: R_X86_64_PC32var-0x4
6: c3 retq
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #23 from Fangrui Song ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
>
> I gave you the correct usage for your use case. If you don't like it is not
> my fault.
A wontfix/invalid does not seem a proper resolution to the bug(s).
We need a solution, instead of a workaround (SHN_ABS _binary_*_size can be
changed to _binary_*_end minus _binary_*_start).
Let me repeat. The code has worked fine for a long time.
1. -fno-pie code can only be linked with -no-pie. A PC32 relocation can be
resolved to a SHN_ABS definition.
2. -fpie code can be linked with either -no-pie or -pie.
3. -fpic code can be linked with -no-pie, -pie or -shared. GCC produces a GOT
relocation.
The linker will fill up the GOT entry at link time. It is a constant at
runtime.
1 and 3 always work. For 2 -fpie -pie, it is incorrect to reference a
non-preemptible SHN_ABS symbol with a PC relative relocation in a PIC (-shared
or -pie) link (missed GNU ld diagnostic:
https://sourceware.org/bugzilla/show_bug.cgi?id=25749)
A GOT relocation was produced until commit
77ad54d911dd7cb88caf697ac213929f6132fdcf
("x86-64: Optimize access to globals in PIE with copy reloc").
I have proposed my solution in Comment 10: revert the patch.
It has very little value after H.J. invented GOTPCRELX in 2015.
As a compensation, we can invent a pair of new -f options,
-f(no-)direct-access-extern-object.
-fno-pie defaults to -fdirect-access-extern-object. -fpie defaults to
-fno-direct-access-extern-object.
-fno-pie users who really want to get rid of copy relocations can enable
-fno-direct-access-extern-object.
Note: a copy relocation is needed if the definition turns out to be provided
by a shared object.
-fpie users who really care about GOT slowdown can enable
-fdirect-access-extern-object.
This is more relevant on non-x86 due to the lack of linker relaxation
(R_X86_64_{REX_,}GOTPCRELX)
[Bug preprocessor/94535] New: __LINE__ value changed for macro invocations spanning multiple lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 Bug ID: 94535 Summary: __LINE__ value changed for macro invocations spanning multiple lines Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: alisdairm at me dot com Target Milestone: --- Given the following simple program, the line that static_asserts changed from gcc 8 to gcc 9 (and remains so for current trunk prior to 10's release): #define LINE(DUMMY) __LINE__ constexpr int X = LINE( wrap); static_assert(X == 3); // gcc 8 and earlier, non-gcc compilers static_assert(X == 4); // gcc 9 and 10 Note that every other compiler I have access to has the original gcc 8 behavior. (tested widely with Godbolt compiler explorer, and on Solaris/AIX with native compilers) Unsurprisingly, this is breaking unit tests and other code similarly sensitive to line numbers. Godbolt link for quick testing: https://godbolt.org/z/LU--gC
[Bug preprocessor/94535] __LINE__ value changed for funciton macro invocations spanning multiple lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 --- Comment #2 from Alisdair Meredith --- Thanks for the speedy response, really appreciated! I believe this is well-defined behavior, but can accept that the value of __LINE__ may be unspecified - I do struggle with pre-processor wording. There is no multiline "macro function" here, there is an invocation of a macro, and the invocation spans multiple lines. Our actual use case looks more like: INVOKE_MACRO(ARG1, ARG2, ARG3); Where the line-wraps are forced by coding convention and line-length limits. This is not a control-line that defined a macro, so I believe the token sequence is taken after discarding irrelevant whitespace. The issue is whether __LINE__ should correspond to the line with the opening paren, the closing paren, or one of the lines in-between. Until gcc9, AFAICT, all compilers agreed on the line with the opening paren. Even if it is unspecified behavior (so free to choose) it would be helpful to preserve a compatibility with past gcc compilers, and all other tested compilers, unless there is a strong reason to want the change. If there were more compiler divergence on the issue, I would be less concerned.
[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 --- Comment #4 from Alisdair Meredith --- (In reply to Andrew Pinski from comment #3) > I miss-remembered the issue, the issue was only with preprocessor directives > inside macro functions (this changed in GCC 3.3 and above really). > > But I still think both line #s are correct. is the line at the opening of > the macro function or the closing? I have been bitten by that UB as well in the past, and can see the confusion :) I believe I got it backwards in my previous message: historically gcc and other compilers produced __LINE__ from the closing paren, and from gcc 9 it is now determined by the opening paren.
[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 --- Comment #8 from Alisdair Meredith --- (In reply to Andrew Pinski from comment #6) > Why not do this: > static_assert(X == 3 || X == 4); > > There that works for both cases. The code example was intended to the be smallest reproducible example that shows the value changing. The typical failure we see is unit tests for our testing framework, validating the message coming from our testing assert macros and similar. We format the error message we expect to see with a value offset from the current line, to verify that the message captured writing to the console (which we redirect for comparison) is the same. We now need to adjust those tests, and similar, to account for the __LINE__ number varying in some testing invocations - which is doable. My concern is how many other folks are waiting to upgrade to gcc 9 and stumble over the same issue? If it is a dark enough corner, then maybe none :) If this were to revert to historical behavior for gcc 10, we would just skip those particular formatting tests on gcc9, as we have enough test coverage with other compilers to have confidence in the message we output, and when actual tests fire in production, they will still point to a valid line for our test asserts.
[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 --- Comment #9 from Alisdair Meredith --- (In reply to Martin Sebor from comment #7) > The following proposal was accepted into C2X last year: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2322.htm > It seems to me like it's about the same thing but I just skimmed it. Thanks - that is a good reference, and it looks that gcc9 is implementing the new recommended best practice. Does anyone active in SG14 know if existing practice was surveyed before making this recommendation? My testing has been limited to C++ compilers, and I believe there are a wider range of C vendors that may be relevant than my little survey had access to.
[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 --- Comment #10 from Alisdair Meredith --- And double-checking the C++ Standard again, I think I have wording in favor of my report and contradicting the recommended best practice for the pending C standard: [cpp.line]p2 "The line number of the current source line is one greater than the number of new-line characters read or introduced in translation phase 1 (5.2) while processing the source file to the current token." We will not start interpreting the tokens for macro expansion until after seeing the closing paren for the invocation, which means counting all the newlines up to the closing paren, and so reporting the higher line number. The joys of a shared pre-processor specification.
[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #8 from Fangrui Song --- Clang since version 9 supports `__FILE_NAME__` (basename) as an extension https://reviews.llvm.org/D61756 I don't know whether it has been proposed on WG14 or WG21 mailing lists, though (seems not).
[Bug c++/91867] Internal compiler error in simple for(auto) loop when using -std=c++11 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91867
me at myrrec dot space changed:
What|Removed |Added
CC||me at myrrec dot space
--- Comment #3 from me at myrrec dot space ---
Also confirmed with -std=c++17 and -std=c++2a
main.cpp--
int main(){
for (bool e : {true, false});
}
-
[Bug target/95095] New: Feature request: support -fno-unique-section-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
Bug ID: 95095
Summary: Feature request: support -fno-unique-section-names
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
-ffunction-sections produces sections .text.foo , .text.bar , etc, which can
take significant amount of string table space.
In clang, -fno-unique-section-names emits multiple ".text" sections which can
share the section name. Multiple sections with the same name require the new
GNU as feature https://sourceware.org/bugzilla/show_bug.cgi?id=25380 (binutils
2.35).
For .text.exit.* .text.unlikely.* .text.hot.* .text.startup.* , the preferred
sections are .text.exit. .text.unlikely. .text.hot. .text.startup. The trailing
dots can avoid a linker problem described in https://reviews.llvm.org/D79600
- pasted below for your convenience
GNU ld's internal linker script uses
(https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=add44f8d5c5c05e08b11e033127a744d61c26aee)
.text :
{
*(.text.unlikely .text.*_unlikely .text.unlikely.*)
*(.text.exit .text.exit.*)
*(.text.startup .text.startup.*)
*(.text.hot .text.hot.*)
*(SORT(.text.sorted.*))
*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf.em. */
*(.gnu.warning)
}
Because *(.text.exit .text.exit.*) is ordered before *(.text .text.*), in a
-ffunction-sections build, the C library function exit will be placed before
other functions.
gold's -z keep-text-section-prefix has the same problem.
In lld, -z keep-text-section-prefix recognizes
.text.{exit,hot,startup,unlikely,unknown}.*, but not
.text.{exit,hot,startup,unlikely,unknown}, to avoid the strange placement
problem.
[Bug debug/95096] New: Feature request: add -fsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95096 Bug ID: 95096 Summary: Feature request: add -fsplit-dwarf Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me Target Milestone: --- -gsplit-dwarf has an undesired property: it sets the debug info level to 2. When plugged into a build system, this can enable debug info unnecessarily (when the user does not specify -g or specifies -g0). -fsplit-dwarf can enable .dwo, but do not enable debug info by itself. Its reaction with -g1 may need some thoughts: whether line tables in .dwo will be beneficial. As a start, we can add the option first, which should be simple (for a beginner like me:/ )
[Bug debug/95096] Feature request: add -fsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95096 --- Comment #1 from Fangrui Song --- Created https://sourceware.org/pipermail/gcc-patches/2020-May/545638.html
[Bug c++/95153] New: Arrays of 'const void *' should not be copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95153 Bug ID: 95153 Summary: Arrays of 'const void *' should not be copyable Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alisdairm at me dot com Target Milestone: --- In general, we do not expect array types to be copyable according to the 'is_copy_constructible_v' trait. However, the following started passing in gcc 10: #include static_assert(!std::is_copy_constructible_v); Note that the 'const' is important, arrays of 'void *' remain non-copyable according to the trait. 'void' may be a specific trigger too, as arrays of 'const int *' do not have this problem. Finally, the array bound does not seem significant, other than it gives the expected answer again for an array of unknown bound.
[Bug c++/95153] Arrays of 'const void *' should not be copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95153 --- Comment #1 from Alisdair Meredith --- Forgot to add this is specific to -std=c++20 too.
[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 --- Comment #13 from Alisdair Meredith --- As this has shipped for two releases now (gcc9 and 10) I recommend closing as Works As Designed, citing C standard paper N2322 as reason for the change.
[Bug c/95189] New: memcmp being wrongly stripped (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Bug ID: 95189
Summary: memcmp being wrongly stripped (regression)
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at pkh dot me
Target Milestone: ---
Given the following C code:
% cat a.c
#include
static const float z[1] = {0};
int f(float x) { return memcmp(&x, z, sizeof(x)); }
GCC 10 generates this on x86-64:
% gcc -Wall -O2 -c a.c && objdump -d -Mintel a.o
a.o: file format elf64-x86-64
Disassembly of section .text:
:
0: f3 0f 11 44 24 fc movss DWORD PTR [rsp-0x4],xmm0
6: 0f b6 44 24 fc movzx eax,BYTE PTR [rsp-0x4]
b: c3 ret
This doesn't happen if "= {0}" is removed from the z initialization (wtf?).
It also doesn't happen with -O1.
[Bug target/95095] Feature request: support -fno-unique-section-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #1 from Fangrui Song ---
I just learned that `int main() {}` compiles to .text.startup in -O2 or -Os
It seems that .text.startup. may be better to not accidentally move a C
function named `startup` (`startup.` is not a valid C identifier)
[Bug debug/95482] New: Feature request: add -gsplit-dwarf=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95482 Bug ID: 95482 Summary: Feature request: add -gsplit-dwarf=single Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me Target Milestone: --- DWARF v5 Appendix F. says > The sections that do not require relocation, however, can be written to the > relocatable object (.o) file but ignored by the linker, or they can be > written to a separate DWARF object (.dwo) file that need not be accessed by > the linker. GCC/clang -gsplit-dwarf write a separate DWARF object (.dwo) clang in addition supports -gsplit-dwarf=single (https://reviews.llvm.org/D52296 ) to write the sections (with the SHF_EXCLUDE flag) in the .o file. Linkers ignore SHF_EXCLUDE sections in non -r mode. Note, SHF_EXCLUDE (0x8000) is in the range of processor-specific bits and clashes with several processors's (obsoleted?) flags (see https://sourceware.org/pipermail/binutils/2020-April/110691.html )
[Bug middle-end/95189] [10/11 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #5 from gcc at pkh dot me ---
I'd like to point out that this regression impacts badly a production app.
We're using this pattern to compare an input vector of floats to a vector of
zeros, but the comparison always returns 0 now, which basically breaks
everything. We do have a workaround (removing the "= {0}"), but I don't think
this is an isolate case.
Maybe the priority could be raised?
[Bug target/96026] New: overlap register bewteen DEST and SOURCE in different machine mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96026 Bug ID: 96026 Summary: overlap register bewteen DEST and SOURCE in different machine mode Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rjiejie at me dot com Target Milestone: --- GCC seems to overlap register bewteen DEST and SOURCE in different machine mode, e.g. RISCV vector extension: when VMUL > 1, most of instructions do not support with overlapped register Is there any target hooks to control this feature ? We can use ‘&’ to forbid register allocator to overlap bewteen DEST and SOURCE, but there are some redundancy instructions in the result code :(
[Bug libstdc++/96074] New: Associative containers never propagate allocator on copy assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96074 Bug ID: 96074 Summary: Associative containers never propagate allocator on copy assignment Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: alisdairm at me dot com Target Milestone: --- Created attachment 48834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48834&action=edit Validate allocator propagation for all containers The attached test driver is a simple validation that each container correctly propgates allocators, given all 16 possible permutations of the traits. All containers pass with the exception of the 4 associative containers that each ignore the propagate_on_container_copy_assigment trait. Note the test driver is slow to build as it instantiates a lot of templates.
[Bug c++/95153] Arrays of 'const void *' should not be copyable in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95153 --- Comment #3 from Alisdair Meredith --- Sorry, thought I had confirmed that I agree with the analysis above - this is a (perhaps surprising) change to the specification of C++20. What is the best way to withdraw this report as invalid?
[Bug gcov-profile/96092] New: Should --coverage respect -ffile-prefix-map?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96092
Bug ID: 96092
Summary: Should --coverage respect -ffile-prefix-map?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
% gcc-10 -ffile-prefix-map=/tmp/c=/src --coverage -c -g /tmp/c/a.c
# -ffile-prefix-map implies -fdebug-prefix-map
% llvm-dwarfdump -debug-info a.o | grep /src
DW_AT_name("/src/a.c")
DW_AT_comp_dir("/src")
DW_AT_decl_file ("/src/a.c")
# --coverage is not affected
% r2 -qc 'pxw `?v $s`' a.gcno
0x 0x67636e6f 0x42303065 0x27b4c272 0x0002 oncge00Br..'
0x0010 0x706d742f 0x632f 0x0001 0x0100 /tmp/c..
0x0020 0x000f 0x067072eb 0x40058857 0xdb5de9e8 .rp.W..@..].
0x0030 0x0002 0x6e69616d 0x 0x main
0x0040 0x0003 0x706d742f 0x612f632f 0x632e /tmp/c/a.c..
0x0050 0x0001 0x0005 0x0001 0x000c
0x0060 0x0141 0x0001 0x0004 0x0143 ..A...C.
0x0070 0x0003 0x 0x0002 0x0004
0x0080 0x0143 0x0003 0x0002 0x0003 ..C.
0x0090 0x0005 0x0143 0x0003 0x0003 ..C.
0x00a0 0x0001 0x0001 0x0145 0x0009 ..E.
0x00b0 0x0002 0x 0x0003 0x706d742f /tmp
0x00c0 0x612f632f 0x632e 0x0001 0x /c/a.c..
0x00d0 0x
I created this issue because I saw a clang-side proposal
https://reviews.llvm.org/D83154 (add -fcoverage-prefix-map) today.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 jojo changed: What|Removed |Added CC||rjiejie at me dot com --- Comment #35 from jojo --- (In reply to Martin Liška from comment #30) > A possible solution can be usage of '-flinker-output=nolto-rel -r' for huge > files. it's useful for splitting huge files ?
[Bug gcov-profile/96092] Should --coverage respect -ffile-prefix-map?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96092 --- Comment #3 from Fangrui Song --- (In reply to Martin Liška from comment #2) > Apparently we've got a patch in queue that does something similar: > > +fprofile-prefix-path= > +Common·Joined·RejectNegative·Var(profile_prefix_path) > +remove·prefix·from·absolute·path·before·manging·name·for·-fprofile- > generate=·and·-fprofile-use=. Can we generalize the option to -fprofile-prefix-map= and let it be part of -ffile-prefix-map? We can let clang side add -fprofile-prefix-map= as well (https://reviews.llvm.org/D83154#2146085 ) clang may not support -fprofile-prefix-path= as it can be emulated by -fprofile-prefix-map= (IIUC, in GCC, -fprofile-generate uses gcov so either -fprofile-prefix-map= or -fcoverage-prefix-map= will be an ok name. In clang, -fprofile-generate is an instrumentation different from --coverage (gcov).)
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #38 from jojo --- (In reply to Martin Liška from comment #36) > (In reply to jojo from comment #35) > > (In reply to Martin Liška from comment #30) > > > A possible solution can be usage of '-flinker-output=nolto-rel -r' for > > > huge > > > files. > > > > it's useful for splitting huge files ? > > There's experiment I did: > > $ time g++ -O2 /tmp/gimple-match.ii -c > > real0m35.790s > user0m35.490s > sys0m0.268s > > $ time g++ -O2 /tmp/gimple-match.ii -c -flto > > real0m8.138s > user0m7.915s > sys0m0.202s > > $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -r -o > gimple-match2.o > > real0m9.087s > user1m56.028s > sys0m3.292s > > $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -r -o > gimple-match2.o --param lto-partitions=8 > > real0m7.350s > user0m48.548s > sys0m0.976s > > $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -r -o > gimple-match2.o --param lto-partitions=4 > > real0m9.847s > user0m30.462s > sys0m0.392s > > so for N==4 we get to 8+10s = 18s (compared to the original 36s). And total > user time is 30+8, which is comparable > to the original 36s. It's looks a little cost down for huge file as insn-emit.c.. I want to use shell tool like 'csplit' to split it and compile parallelly
[Bug driver/93645] Support Clang 12 --ld-path=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 --- Comment #4 from Fangrui Song --- https://sourceware.org/pipermail/gcc-patches/2020-July/550659.html [PATCH v3] Add --ld-path= to specify an arbitrary executable as the linker I changed the title to --ld-path because -fuse-ld=/absolute/path/to/ld is not a good design. -fuse-ld= can mean the linker flavor (there can be option dispatch on this option) & --ld-path can specify the path overriding -fuse-ld='s default choice. -f* options are usually about code generation or language features. --ld-path does not belong to the category so -f is not very appropriate. Clang 12 will have --ld-path.
[Bug ipa/96352] New: inflated text section with ipa inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96352 Bug ID: 96352 Summary: inflated text section with ipa inline Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rjiejie at me dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 48942 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48942&action=edit inflated text section with ipa inline My case is compare size of object between two versions. >From v8.3, the text section size is 3232, but from v8.4, the text section size is 5692. My test command line: cc1 bitstream.i -march=rv64gc -mabi=lp64 -O3 -o a.s as --traditional-format -march=rv64gc -mabi=lp64 -o a.o a.s size a.o I found this issue from gcc version v8.4 and it is present at gcc version 10.2.1 also :( I have researched gcc sources and found the issue comes from edge_badness@ipa-inline.c at commit be917808aa3310d46f586e6586ef08d302837f1e : diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c index 73da38c..8e34400 100644 --- a/gcc/ipa-inline.c +++ b/gcc/ipa-inline.c @@ -1173,7 +1173,7 @@ edge_badness (struct cgraph_edge *edge, bool dump) overall_growth += 256 * 256 - 256; denominator *= overall_growth; } - denominator *= inlined_time; + denominator *= ipa_fn_summaries->get (caller)->self_size + growth; badness = - numerator / denominator;
[Bug c/96368] New: False negative with maybe-uninitialized with goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96368 Bug ID: 96368 Summary: False negative with maybe-uninitialized with goto Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: felix at piedallu dot me Target Milestone: --- Created attachment 48951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48951&action=edit minimal code for missing maybe-uninitialized warning There are cases where GCC should warn about maybe-uninitialized variables but doesn't. In the attached minimal code, the `goto` may prevent the eth.pktio to be initialized, but GCC doesn't warn about it. Weirdly enough, if the pktio_read() call is uncommented, GCC warns that eth.pktio may be uninitialized. Of course the fix is to initialize eth.pktio before the goto.
[Bug c/96368] False negative with maybe-uninitialized with goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96368 Salamandar changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #2 from Salamandar --- I just tried with GCC 9.3 and the bug is still present. https://godbolt.org/z/TYarqe
[Bug ipa/96352] inflated text section with ipa inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96352 --- Comment #2 from jojo --- (In reply to Richard Biener from comment #1) > It was a bugfix. If you want to have small binaries use -Os. You can also > tune the inliner with various knobs, the most important maybe > --param inline-unit-growth which defaults to 40 (40% growth). Ok and thank you :)
[Bug middle-end/192] String literals don't obey -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #19 from Fangrui Song ---
(In reply to Jakub Jelinek from comment #14)
> This doesn't really look like a good idea to me. Instead, perhaps ld's
> --gc-sections or new special option should just remove unused string
> literals from mergeable sections.
> With your patch, I bet you lose e.g. all tail merging. Consider:
> const char *used1 () { return "foo bar baz blah blah"; }
> in one TU and
> const char *used2 () { return "bar baz blah blah"; }
> in another. The linker necessarily knows which strings (or other data) in
> mergeable sections are used and which are unused.
I second Jakub's idea that the linker should perform the constant merge (which
is implemented in LLD): the cost of a section header (sizeof(Elf64_Shdr)=64) +
a section name (".rodata.xxx.str1.1") is quite large.
Created a GNU ld (and gold) feature request:
https://sourceware.org/bugzilla/show_bug.cgi?id=26622
[Bug gcov-profile/97062] New: [gcov] Don't repeat display of inline functions in headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97062 Bug ID: 97062 Summary: [gcov] Don't repeat display of inline functions in headers Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me CC: marxin at gcc dot gnu.org Target Milestone: --- This is a minor display issue. >a.cc cat<b.cc cat<a.h cat<
[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #17 from Fangrui Song --- The algorithm is Donald B. Johnson's "Finding all the elementary circuits of a directed graph" (1975). (Hawick and James's just implemented the same algorithm by changing the representation of graphs). I am wondering why we enumerate every elementary cycle, find the minimum edge, reduce edge weighs, and repeat the process. What do we lose if we don't use the costly algorithm? (The time complexity is O(n*e*(c+1)). However, many implementations (Boost and gcov.c) do not use a hash set for the blocked list, and thus I suspect the actual complexity is higher). Do we have other low-cost approaches? (e.g. repeatedly finding strongly connected components and reducing)
[Bug gcov-profile/97065] New: Support -fprofile-update=set (boolean counters)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97065 Bug ID: 97065 Summary: Support -fprofile-update=set (boolean counters) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me CC: marxin at gcc dot gnu.org Target Milestone: --- I can understand that defaulting -fprofile-update=prefer-atomic in GCC 7 and using atomic counters when -pthread is specified is for very good reasons that imprecise line execution counts can be very confusing. However, atomic counters can lead to very drastic performance degradation when the contention is large (e.g. bug 80952) Sometimes users just need to know whether a statement is executed or not. For example lcov does not really need to know the number. A boolean mode -fprofile-update=set may be useful. 'set' is the name used by Go -covermode=set
[Bug gcov-profile/85351] [GCOV] Wrong coverage with exit() executed in a if statement within a called function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85351 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #5 from Fangrui Song --- I am a bit curious how GCC instruments such functions which may alter control flows * exit/execve/execl/etc * fork * functions which may throw or call any above functions If you force a split basic block after such functions, you get counts correct but you pay the costs that there is one more basic block and two more arcs. In -fprofile-arcs you need to pay the instrumentation cost of one arc (after taking into account of the Kirchhoff circuit law's spanning tree optimization). If you assume every external function call may alter control flows, you pay rather large overhead for things you probably care little (since I know some underlying mechanism I don't trust line counts after special functions).
[Bug driver/93645] Support Clang 12 --ld-path=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 --- Comment #5 from Fangrui Song --- Ping
[Bug rtl-optimization/97170] New: Wrong optimization in fwprop pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97170 Bug ID: 97170 Summary: Wrong optimization in fwprop pass Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rjiejie at me dot com Target Milestone: --- insn seqs: s1: __builtin_set_float_convert_mode(0); r1 = __builtin_load(a1, a2); r2 = __builtin_float_convert(r1); __builtin_store(a3, r2); __builtin_set_float_convert_mode(0); s2: __builtin_set_float_convert_mode(1); r1 = __builtin_load(a1, a2); r2 = __builtin_float_convert(r1); __builtin_store(a3, r2); __builtin_set_float_convert_mode(0); the diference of s1 and s2 only is "__builtin_set_float_convert_mode" from beginning, the s1 mode is set 0, but s2 mode is set 1. from optimization 'fwprop', the s2 insns seqs is deleted as dead code, is it gcc bug ? builtin patten of __builtin_set_float_convert_mode: (define_insn "target_fcvtmode" [(set (reg:SI FCVTMODE_REGNUM) (unspec_volatile:SI [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FCVTMODE))] "" "fcvtmode\t%1" ) builtin patten of __builtin_set_float_convert_mode: (define_insn "target_fcvt" [(set (match_operand:SI 0 "register_operand" "=r") (unspec:SI [(match_operand:SF 1 "register_operand" "f")] UNSPEC_FCVT)) (use (reg:SI FCVTMODE_REGNUM))] "" "fcvt\t%0,%1" ) As far as i know, __builtin_set_float_convert_mode depend on 'FCVTMODE_REGNUM' which is from __builtin_set_float_convert_mode, it's not dead code. or something wrong in my pattens ? Anyone could give me some hints ? Thanks
[Bug rtl-optimization/97170] Wrong optimization in fwprop pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97170 --- Comment #2 from jojo --- (In reply to Andrew Pinski from comment #1) > target_fcvt is wrong. > try: > (define_insn "target_fcvt" > [(set (match_operand:SI 0 "register_operand" "=r") > (unspec:SI [(match_operand:SF 1 "register_operand" "f") > (reg:SI FCVTMODE_REGNUM)] > UNSPEC_FCVT))] > "" > "fcvt\t%0,%1" > ) > > instead. Basically the set is not dependent on the reg (FCVTMODE_REGNUM) > only the instruction itself which is what ever. It works, Thanks so much :)
[Bug c++/92138] New: Compiler does not define __CPP_THREADS__ when multiple threads are supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92138 Bug ID: 92138 Summary: Compiler does not define __CPP_THREADS__ when multiple threads are supported Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alisdairm at me dot com Target Milestone: --- According to [cpp.predefined], the __CPP_THREADS__ macro should be (implicitly) predefined "if and only if a program can have more than one thread of execution". I believe this is entirely dependent on the memory model, and the necessary ordering guarantees that are likely to impact optimizers etc. (whether data races are a thing to worry about or not) and totally unrelated to library support for the header, etc. This requirement was added for C++11, but from my attempts at searching Bugzilla, I have not found any other reports featuring the token "__CPP_THREADS__", which means either my search skills are sadly wanting, or this is not a highly requested feature. My research of other C++11 compilers suggests that the Intel compiler (EDG front end) and Microsoft compilers correctly define this macro, and the Clang folks already have bug reports tracking this.
[Bug c++/92138] Compiler does not define __CPP_THREADS__ when multiple threads are supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92138 Alisdair Meredith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Alisdair Meredith --- Sorry - not enough caffeine early morning: the bug is correct but the macro name is not, that should be __STDCPP_THREADS__ and is a duplicate of 63287. *** This bug has been marked as a duplicate of bug 63287 ***
[Bug c++/63287] __STDCPP_THREADS__ is not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287 Alisdair Meredith changed: What|Removed |Added CC||alisdairm at me dot com --- Comment #2 from Alisdair Meredith --- *** Bug 92138 has been marked as a duplicate of this bug. ***
[Bug c/92257] New: AVX512 incorrect usage of aligned loads and stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92257
Bug ID: 92257
Summary: AVX512 incorrect usage of aligned loads and stores
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ilya at alfs dot me
Target Milestone: ---
Hello,
I had few segmentation faults while writing AVX512 code. SEGFAULTs were caused
by aligned loads used when data alignment can not be guaranteed in compile
time.
test.c:
#include
__m512i foo(__m512i *a) {
return a[100];
}
gcc -S -O3 -march=icelake-client -mavx512f ./test.c
test.s:
.file "test.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB5279:
.cfi_startproc
vmovdqa64 6400(%rdi), %zmm0
ret
.cfi_endproc
.LFE5279:
.size foo, .-foo
.ident "GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
.section.note.GNU-stack,"",@progbits
[Bug target/92257] AVX512 incorrect usage of aligned loads and stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92257 --- Comment #2 from Ilya Albrekht --- Thank you for your prompt reply. I missed that __m512i_u type exists to avoid alignment requirement. PS. I guess you meant 512 bit? Regards, Ilya
[Bug c++/92413] New: [temp.explicit] Explicit template instantiations should not define member functions that are not defined at the point of instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
Bug ID: 92413
Summary: [temp.explicit] Explicit template instantiations
should not define member functions that are not
defined at the point of instantiation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
https://wg21.cmeerw.net/cwg/issue546
Change 17.8.2 [temp.explicit] paragraph 8 as follows:
An explicit instantiation definition that names a class template specialization
explicitly instantiates the class template specialization and is only an
explicit instantiation definition of members whose definition is
visible>that have been defined at the point of
instantiation.
template struct C {void foo();};
template struct C;
template void C::foo() {}
GCC<4.9 does not define C::foo(), while GCC>=4.9 defines C::foo()
I am not sure whether this example is non-conforming, but -Wall -Wextra
-pedantic gives no diagnostic. (clang 3.0~trunk does not define C::foo().
You may read the discussions at https://bugs.llvm.org/show_bug.cgi?id=43937)
[Bug c++/67228] Template partial ordering failure ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67228
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment #1 from Alisdair Meredith ---
Finally tracked down a simple reproducer from our own code base, that looks
simpler to run into (we have had a gcc specific workaround for years, but
apparently never filed a bugzilla report):
template
T make(A, Args&&...) { return {}; }
template
T make(A*, Args&&...) { return {}; }
int main() {
int * p = 0;
auto x = make(p, 1);
}
Reproducible on every gcc available on Compiler Explorer, including trunk. All
other C++11 compilers pass this test.
The ambiguity goes away if I remove the parameter pack argument at the call
site (i.e., deduce an empty pack).
[Bug c++/69089] C++11: alignas(0) causes an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089 Tom de Geus changed: What|Removed |Added CC||tom at geus dot me --- Comment #7 from Tom de Geus --- Same problem here. It would be great if the patch could be integrated!
[Bug c++/92672] New: OpenMP shared clause not respected without pointer to the variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92672
Bug ID: 92672
Summary: OpenMP shared clause not respected without pointer to
the variable
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at cimba dot li
Target Milestone: ---
It seems that if the address of a stack variable is never taken, it is treated
by child OpenMP tasks with firstprivate semantics, even though it is declared
as shared.
The following example compiles to different code (that behaves differently) if
"&i;" is removed:
#include
#include
int main()
{
omp_lock_t lock;
omp_init_lock(&lock);
int i = 1;
&i;
#pragma omp parallel shared(i)
#pragma omp single
{
omp_set_lock(&lock);
#pragma omp task shared(i)
{
// enter task, then suspend until i = 2
omp_set_lock(&lock);
std::cout << i;
omp_unset_lock(&lock);
}
i = 2;
// unset lock after i is set to 2 and child task is created
// child task is possibly started and suspended at this point
omp_unset_lock(&lock);
}
omp_destroy_lock(&lock);
std::cout << std::endl;
return 0;
}
- With "&i", the code prints 2. The task’s verbose assembly is as follows:
.LFE2010:
.size main._omp_fn.0, .-main._omp_fn.0
.type main._omp_fn.1, @function
main._omp_fn.1:
.LFB2011:
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDA2011
pushq %rbp#
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp #,
.cfi_def_cfa_register 6
subq$16, %rsp #,
movq%rdi, -8(%rbp) # .omp_data_i, .omp_data_i
# test.cc:18: omp_set_lock(&lock);
movq-8(%rbp), %rax # .omp_data_i, tmp86
movq(%rax), %rax# .omp_data_i_2(D)->lock, _3
movq%rax, %rdi # _3,
callomp_set_lock#
# test.cc:19: std::cout << i;
movq-8(%rbp), %rax # .omp_data_i, tmp87
movq8(%rax), %rax # .omp_data_i_2(D)->i, _6
movl(%rax), %eax# *_6, i.0_7
# test.cc:19: std::cout << i;
movl%eax, %esi # i.0_7,
movl$_ZSt4cout, %edi#,
call_ZNSolsEi #
# test.cc:20: omp_unset_lock(&lock);
movq-8(%rbp), %rax # .omp_data_i, tmp88
movq(%rax), %rax# .omp_data_i_2(D)->lock, _9
movq%rax, %rdi # _9,
callomp_unset_lock #
# test.cc:15: #pragma omp task shared(i)
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
- Without "&i", the code prints 1. The task’s verbose assembly is as follows:
.LFE2010:
.size main._omp_fn.0, .-main._omp_fn.0
.type main._omp_fn.1, @function
main._omp_fn.1:
.LFB2011:
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDA2011
pushq %rbp#
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp #,
.cfi_def_cfa_register 6
subq$32, %rsp #,
movq%rdi, -24(%rbp) # .omp_data_i, .omp_data_i
# test.cc:15: #pragma omp task shared(i)
movq-24(%rbp), %rax # .omp_data_i, tmp84
movl8(%rax), %eax # .omp_data_i_2(D)->i, tmp85
movl%eax, -4(%rbp) # tmp85, i
# test.cc:18: omp_set_lock(&lock);
movq-24(%rbp), %rax # .omp_data_i, tmp86
movq(%rax), %rax# .omp_data_i_2(D)->lock, _4
movq%rax, %rdi # _4,
callomp_set_lock#
# test.cc:19: std::cout << i;
movl-4(%rbp), %eax # i, tmp87
movl%eax, %esi # tmp87,
movl$_ZSt4cout, %edi#,
call_ZNSolsEi #
# test.cc:20: omp_unset_lock(&lock);
movq-24(%rbp), %rax # .
[Bug c++/92752] New: Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92752
Bug ID: 92752
Summary: Bogus "ignored qualifiers" warning on const-qualified
pointer-to-member-function objects
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
We are seeing a bogus warning on the default constructor for a class template
that wraps a data member of the template parameter type, when that template
parameter is a const-qualified pointer-to-member-function type (note, the
pointer-to-member function type is cv-qualified, not the member function that
is pointed to). This comes up in our own library implementation for a
pair-like type used for our associative containers (pair)
Example code, should be compiled with -Wextra to show the warning:
struct X {};
using MemFn = int (X::*)();
template
struct Wrap {
T data;
Wrap() : data() {}
};
int main() {
Wrap x;
}
Compiler output:
In instantiation of 'Wrap::Wrap() [with T = int (X::* const)()]':
13:23: required from here
9:29: warning: type qualifiers ignored on cast result type
[-Wignored-qualifiers]
9 | Wrap() : data() {}
| ^
Compiler returned: 0
As far as we can tell, this applies only to pointer-to-member-function types,
not regular function pointers, not pointer-to-data-member, nor any other scalar
type.
Checking past compilers with the Godbolt compiler explorer, this warning seems
to first appear in gcc 8.1:
https://godbolt.org/z/8Mxpsm
[Bug c/93045] New: gc bug with test "start_unit-test-1.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93045 Bug ID: 93045 Summary: gc bug with test "start_unit-test-1.c" Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rjiejie at me dot com Target Milestone: --- /lhome/software/jojo/csky-toolchain-build-riscv/build-riscv64-linux-glibc-opt4mabi-lp64_march-rv64gc/gcc-riscv/build-gcc-linux-stage2/gcc/xgcc -B/lhome/software/jojo/csky-toolchain-build-riscv/build-riscv64-linux-glibc-opt4mabi-lp64_march-rv64gc/gcc-riscv/build-gcc-linux-stage2/gcc/ /lhome/software/jojo/csky-toolchain-build-riscv/gcc-riscv/riscv-gcc/gcc/testsuite/gcc.dg/plugin/start_unit-test-1.c -march=rv64gc -mabi=lp64 -mcmodel=medlow -fno-diagnostics-show-caret -fdiagnostics-color=never -fplugin=./start_unit_plugin.so -O -S -o start_unit-test-1.s fake_var not INTEGER_TYPE FAIL: gcc.dg/plugin/start_unit-test-1.c -fplugin=./start_unit_plugin.so (test for excess errors) Excess errors: fake_var not INTEGER_TYPE
[Bug c/93194] New: -fpatchable-function-entries : __patchable_function_entries has wrong sh_flags and sh_addralign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194
Bug ID: 93194
Summary: -fpatchable-function-entries :
__patchable_function_entries has wrong sh_flags and
sh_addralign
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
void f(){}
% gcc -fpatchable-function-entry=3 -c a.c
% readelf -S a.o
...
[Nr] Name TypeAddress OffSize ES Flg
Lk Inf Al
[ 0] NULL 00 00 00
0 0 0
[ 1] .text PROGBITS 40 0a 00 AX
0 0 1
[ 2] .data PROGBITS 4a 00 00 WA
0 0 1
[ 3] .bss NOBITS 4a 00 00 WA
0 0 1
[ 4] __patchable_function_entries PROGBITS 4a
08 00 A 0 0 1
[ 5] .rela__patchable_function_entries RELA
0001a0 18 18 I 10 4 8
sh_addralign of __patchable_function_entries should be 8 on ELF64 platforms, 4
on ELF32 platforms, instead of 1.
__patchable_function_entries should have the SHF_WRITE flag. A
__patchable_function_entries entry is relocated by a symbolic relocation (e.g.
R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64).
In -shared or -pie mode, the linker will create a dynamic relocation,
* non-preemptible (STB_LOCAL / non-STV_DEFAULT / -Bsymbolic / not-shared /
--dynamic-list excluded / etc): relative relocation (e.g. R_X86_64_RELATIVE)
* preemptible: symbolic relocation (e.g. R_X86_64_64)
(We can't emit an offset relative to the image base (.quad .Lfoo - .Lbase),
because differences across sections are generally not representable. A symbolic
relocation gives the runtime code information about the symbol names, which may
be desirable.)
[Bug middle-end/93194] -fpatchable-function-entries : __patchable_function_entries has wrong sh_flags and sh_addralign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194 --- Comment #1 from Fangrui Song --- The SHF_WRITE issue has been fixed. https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00271.html will fix sh_addralign
[Bug middle-end/93195] New: -fpatchable-function-entries : __patchable_function_entries should consider comdat groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195
Bug ID: 93195
Summary: -fpatchable-function-entries :
__patchable_function_entries should consider comdat
groups
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.cc
inline void foo() {}
void bar() { foo(); }
% cat b.cc
inline void foo() {}
void bar1() { foo(); }
% g++ -fpatchable-function-entry=1 -c a.cc b.cc
Linkers don't allow a relocation to a discarded symbol (foo).
% ld.bfd a.o b.o
...
`.text._Z3foov' referenced in section `__patchable_function_entries' of b.o:
defined in discarded section `.text._Z3foov[_Z3foov]' of b.o
% gold a.o b.o
b.o(__patchable_function_entries+0x0): error: relocation refers to local symbol
"" [5], which is defined in a discarded section
section group signature: "_Z3foov"
prevailing definition is from a.o
% ld.lld a.o b.o
ld.lld: error: relocation refers to a discarded section: .text._Z3foov
>>> defined in b.o
>>> referenced by b.cc
>>> b.o:(__patchable_function_entries+0x0)
[Bug middle-end/93197] New: -fpatchable-function-entries : __patchable_function_entries does not survive under --gc-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93197 Bug ID: 93197 Summary: -fpatchable-function-entries : __patchable_function_entries does not survive under --gc-sections Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me Target Milestone: --- __patchable_function_entries is not a GC root, and not referenced by a retained section. It will thus be garbage collected. The only solution I can think of requires fixes to both GCC and GNU ld. * GNU ld: implement interaction between SHF_LINK_ORDER and --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=24526 * GCC: Create one __patchable_function_entry section for each function. For each function `foo`, + If foo needs to be placed in a comdat group, place __patchable_function_entry in the comdat group + Otherwise, set the SHF_LINK_ORDER flag of __patchable_function_entry and set its sh_link to reference the section containing `foo`
[Bug c++/93257] New: consteval functions returning 'void' are rejected when called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93257
Bug ID: 93257
Summary: consteval functions returning 'void' are rejected when
called
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
The following simple program is accepted by Clang (trunk) and rejected by
current gcc (trunk) at the time of filing:
template
consteval void test() {}
int main() {
test();
return 0;
}
This gives the confusing error:
: In function 'int main()':
:5:22: error: '(void)0' is not a constant expression
5 | test();
Not sure where the void cast of a 0 literal enters the picture, nor why it
would not be a constant expression.
Handy link to running the test on compiler explorer (where Clang results can be
confirmed):
https://godbolt.org/z/_AaBvh
[Bug c++/93257] consteval functions returning 'void' are rejected when called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93257 --- Comment #2 from Alisdair Meredith --- I am trying to use these extensively as ways to collect related static assertions in my test suite for and . By using consteval rather then constexpr, I get notified if any code is unexpectedly deferred to runtime, and can fix my own bugs.
[Bug c++/92672] OpenMP shared clause not respected without pointer to the variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92672 --- Comment #3 from Cimbali --- Would it be possible to deactivate that optimization when shared is not the default mapping? In practice here explicitly setting `shared(i)` has no effect at all. Note that I already recommended against such tricks in the discussion that originated this bug: https://stackoverflow.com/a/59017666/1387346
[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #8 from Fangrui Song --- Where shall we place .cfi_startproc? Clang HEAD (and clang 10)'s placement is: foo: .loc 1 3 0 # line number .cfi_startproc # CFI bti c .Lpatch0: # __patchable_function_entries label nop Not placing .cfi_startproc (as GCC current does) will make addr2line on the function entry address print ??:0 For M>0, clang does not attach line number information for NOPs before the function entry label.
[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #2 from Fangrui Song --- On Clang's side. After https://reviews.llvm.org/D73760 , clang -target x86_64 -fpatchable-function-entry=2,0 -fcf-protection=branch -S a.c -g: .cfi_startproc is placed at the function entry, so that NOPs after the function entry are in the CFI region .loc directive is similar. The idea is that addr2line at the function address should show the correct filename and line, instead of ??:0. foo:# @foo .Lfoo$local: .Lfunc_begin0: .file 1 "/tmp/c" "a.c" .loc1 3 0 # a.c:3:0 .cfi_startproc # %bb.0:# %entry endbr64 .Lpatch0: xchgw %ax, %ax ... .section __patchable_function_entries,"awo",@progbits,foo,unique,0 .p2align3 .quad .Lpatch0 The section flag "o" and the linkage "unique" (LLVM assembly extensions) are used to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93197 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195 . I have filed GNU as feature requests (https://sourceware.org/bugzilla/show_bug.cgi?id=25380 https://sourceware.org/bugzilla/show_bug.cgi?id=25381). GNU ld needs required garbage collection semantics https://sourceware.org/ml/binutils/2019-11/msg00266.html)
[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #7 from Fangrui Song ---
> Is -fasynchronous-unwind-tables compatible with -fpatchable-function-entry?
Apparently the Linux kernel does not care about it. To make it usable in
userspace, we should place .cfi_startproc in a reasonable place.
(A more concerning issue is that __patchable_function_entries can be stripped
by -Wl,--gc-sections , as the bug I linked above describes)
Interaction with -g1 (line table)
% clang -g -fpatchable-function-entry=2 a.c -o a # latest clang
% addr2line -e a 0x$(nm a | awk '/ main/{print $1}')
/tmp/c/a.c:1
% gcc -g -fpatchable-function-entry=2 a.c -o a
% addr2line -e a 0x$(nm a | awk '/ main/{print $1}')
??:?
For M>0, I think it is fine to leave NOPs before the function entry uncovered
by line table information. clang -fpatchable-function-entry=2,1 layout is the
same as #c2, except for a NOP above foo:
% clang -g -fpatchable-function-entry=2,1 a.c -o a
# or gcc -g -fpatchable-function-entry=2,1 a.c -o a
% addr2line -e a $(nm a | ruby -ane 'print ($F[0].to_i(16)-1).to_s(16) if /
main/')
crtstuff.c:?
[Bug middle-end/93195] -fpatchable-function-entries : __patchable_function_entries should consider comdat groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195 --- Comment #1 from Fangrui Song --- This is similar to --gc-sections (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93536) but a bit different. The only reasonable fix I can think of is to place __patchable_function_entries in the same section group. The ELF spec says: > A symbol table entry with STB_LOCAL binding that is defined relative to one > of a group's sections, and that is contained in a symbol table section that > is not part of the group, must be discarded if the group members are > discarded. References to this symbol table entry from outside the group are > not allowed. Both GCC and clang reference a .L local symbol in __patchable_function_entries. The __patchable_function_entries must be discarded when the associated text section is discarded. We don't want __patchable_function_entries.foo __patchable_function_entries.bar because that can waste lots of bytes in .shstrtab . clang -fpatchable-function-entry=2 -S a.cc b.cc # COMDAT and SHF_LINK_ORDER are used at the same time .section __patchable_function_entries,"awo",@progbits,_Z3barv,unique,0 .p2align3 .quad .Lfunc_begin0 .section __patchable_function_entries,"aGwo",@progbits,_Z3foov,comdat,_Z3foov,unique,1 .p2align3 .quad .Lfunc_begin1 Because GNU as and ld don't have the features yet. So when -no-integrated-as is specified (the output is expected to be consumable by GNU as) clang -fpatchable-function-entry=2 -no-integrated-as -S a.cc b.cc ## The assembler will combine sections with the same name ## If either .Lfunc_begin0 or .Lfunc_begin1 is discarded, the linker will report an error. .section__patchable_function_entries,"aw",@progbits .p2align3 .quad .Lfunc_begin0 .section__patchable_function_entries,"aw",@progbits .p2align3 .quad .Lfunc_begin1
[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #11 from Fangrui Song --- (In reply to H.J. Lu from comment #8) > Created attachment 47762 [details] > A patch to handle targetm.asm_out.post_cfi_startproc I don't work on GCC, so I am hoping other x86 maintainers can review. (I know close to zero about its build system. "How to work on GCC" is not well documented. I can play with stage1-gcc/xgcc -B stage1-gcc -fsyntax-only /tmp/c/a.c but I don't even know how to build stage1 only) For tests, I think at least 3 configurations should be tested. -fpatchable-function-entry=0 -fcf-protection=branch -fpatchable-function-entry=1 -fcf-protection=branch -fpatchable-function-entry=2,1 -fcf-protection=branch I am a bit concerned about the introduction of cfi_startproc_emitted My idea is that NOPs after the function entry label should really be a arch specific feature. It should be implemented like a pass beside make_pass_insert_endbranch. We build the function body, then prepend NOPs, then prepend endbr64. That may be cleaner.
[Bug libstdc++/93590] New: [diagnostic] The header is deprecated since C++17, but no warning for #include-ing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93590 Bug ID: 93590 Summary: [diagnostic] The header is deprecated since C++17, but no warning for #include-ing it Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: alisdairm at me dot com Target Milestone: --- C++ currently has two deprecated C++ headers, and . For quite a while, gcc has warned on #include with: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] It seems inconsistent to not get the same warning for #include , at least if the language dialect is C++17 or later.
[Bug driver/93645] New: Support -fuse-ld=/absolute/path/to/ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 Bug ID: 93645 Summary: Support -fuse-ld=/absolute/path/to/ld Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me Target Milestone: --- This feature request generalizes -fuse-ld=bfd -fuse-ld=gold https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470 and -fuse-ld=lld clang -fuse-ld= also supports the following forms: -fuse-ld=/path/to/binutils-gdb/Debug/ld/ld-new -fuse-ld=/path/to/ld.lld -fuse-ld=/usr/bin/ld.lld-9
[Bug driver/93645] Support -fuse-ld=/absolute/path/to/ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 --- Comment #1 from Fangrui Song --- Posted a patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00510.html I agree with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321#c4 we should use a new option, instead of overloading --print-prog-name=ld for a different meaning gcc --print-prog-name=ld -fuse-ld=bfd => ld.bfd
[Bug driver/52982] add option to select particular linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52982 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #4 from Fangrui Song --- I posted a patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00510.html to make -fuse-ld=linker generic (absolute path or ld.linker)
[Bug c++/57437] New: C++11: mutable lambdas; gcc 4.7-4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437
Bug ID: 57437
Summary: C++11: mutable lambdas; gcc 4.7-4.8
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alxchk at alxchk dot me
> cat test.cpp
#include
#include
int main(int argc, char *argv[])
{
auto x = std::vector({1, 2, 3});
auto y = [x] ()
mutable {
for (auto &i: x)
i ++;
return x;
};
for (const auto &i: y())
std::cout << i << std::endl;
for (const auto &i: y())
std::cout << i << std::endl;
return 0;
}
> x86_64-pc-linux-gnu-g++-4.6.3 -o test test.cpp -std=gnu++0x
> ./test
2
3
4
3
4
5
> LC_ALL=C x86_64-pc-linux-gnu-g++-4.6.3 -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++-4.6.3
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-esp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,objc,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.6.3
p1.11, pie-0.5.2'
Thread model: posix
gcc version 4.6.3 (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2)
> x86_64-pc-linux-gnu-g++-4.7.2 -o test2 test.cpp -std=gnu++0x
> ./test2
2
3
4
> LC_ALL=C x86_64-pc-linux-gnu-g++-4.7.2 -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++-4.7.2
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-esp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,objc,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
4.7.2-r1 p1.5, pie-0.5.5'
Thread model: posix
gcc version 4.7.2 (Gentoo Hardened 4.7.2-r1 p1.5, pie-0.5.5)
> x86_64-pc-linux-gnu-g++-4.8.0 -o test test.cpp -std=gnu++11
> ./test
2
3
4
> LC_ALL=C x86_64-pc-linux-gnu-g++-4.8.0 -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++-4.8.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-isl-version-check
--with-cloog --enable-lto --enable-nls --w
[Bug sanitizer/57507] New: gcc 4.8: thread sanitizer: std::thread false(?) positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507
Bug ID: 57507
Summary: gcc 4.8: thread sanitizer: std::thread false(?)
positive
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: alxchk at alxchk dot me
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
$ cat test.cpp
#include
int main(int argc, char *argv[])
{
std::thread t([](){});
t.join();
return 0;
}
$ LC_ALL=C g++ --version
g++ (Gentoo Hardened 4.8.0 p1.2, pie-0.5.5) 4.8.0
Copyright (C) 2013 Free Software Foundation, Inc.
$ g++ -o test test.cpp --std=gnu++11 -pthread -fsanitize=thread -ggdb3 -O0
$ ./test
==
WARNING: ThreadSanitizer: data race (pid=14129)
Write of size 8 at 0x7d08bfc8 by thread T1:
#0 :0 (libtsan.so.0+0x00020dc0)
#1 deallocate
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/ext/new_allocator.h:110
(exe+0x2b42)
#2 deallocate
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/alloc_traits.h:377
(exe+0x2972)
#3 _M_destroy
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:417
(exe+0x3336)
#4 :0 (libstdc++.so.6+0x000c8cea)
Previous atomic write of size 4 at 0x7d08bfc8 by main thread:
#0 :0 (libtsan.so.0+0xdfc5)
#1 __exchange_and_add
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/ext/atomicity.h:47
(exe+0x1898)
#2 __exchange_and_add_dispatch
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/ext/atomicity.h:80
(exe+0x1995)
#3 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:141
(exe+0x3c86)
#4 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:553
(exe+0x3c2d)
#5 std::__shared_ptr::~__shared_ptr()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:810
(exe+0x3aae)
#6 std::shared_ptr::~shared_ptr()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr.h:93
(exe+0x3afc)
#7 thread
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/thread:135
(exe+0x1c10)
#8 main /tmp/test.cpp:5 (exe+0x1a3e)
Location is heap block of size 56 at 0x7d08bfc0 allocated by main thread:
#0 :0 (libtsan.so.0+0x00020ad2)
#1 allocate
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/ext/new_allocator.h:104
(exe+0x2a5b)
#2 allocate
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/alloc_traits.h:351
(exe+0x2881)
#3 __shared_count >,
std::allocator > >, std::_Bind_simple >
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:519
(exe+0x26e5)
#4
__shared_ptr > >, std::_Bind_simple >
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:986
(exe+0x25a1)
#5 shared_ptr > >, std::_Bind_simple >
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr.h:316
(exe+0x2511)
#6 allocate_shared >,
std::allocator > >, std::_Bind_simple >
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr.h:598
(exe+0x2422)
#7 make_shared >, std::_Bind_simple >
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr.h:614
(exe+0x225a)
#8 _M_make_routine >
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/thread:193
(exe+0x1fa2)
#9 thread
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/thread:135
(exe+0x1bde)
#10 main /tmp/test.cpp:5 (exe+0x1a3e)
Thread T1 (tid=14130, running) created by main thread at:
#0 :0 (libtsan.so.0+0x00022cdb)
#1 :0 (libstdc++.so.6+0x000c8ef6)
#2 main /tmp/test.cpp:5 (exe+0x1a3e)
SUMMARY: ThreadSanitizer: data race ??:0 ??
==
ThreadSanitizer: reported 1 warnings
[Bug target/57837] New: ARM function pointer tailcall miscompilation regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837
Bug ID: 57837
Summary: ARM function pointer tailcall miscompilation
regression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: me at williamgrant dot id.au
Created attachment 30469
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30469&action=edit
arm.md fix
The fix for PR target/19599 in svn trunk r198928 causes predicated function
pointer tailcalls for some ARM targets to lose their predicate and execute
unconditionally, resulting in a crash or other misbehaviour. I was able to
reproduce the miscompilation, manifesting as a segfault, using -march=armv4t
-marm -O3, as below:
gcc -march=armv4t -marm -O3 -o bx-test bx-test.c
void baz() {};
void (*bar)() = baz;
void foo(int c) {
if (c == 1) {
foo(0);
}
bar();
}
int main(int argc, char **argv) {
foo(1);
}
Today's trunk gives the following asm:
foo:
cmp r0, #1
stmfd sp!, {r4, lr}
ldr r4, .L8
ldrne r3, [r4]
ldmnefd sp!, {r4, lr}
bx r3 @ indirect register sibling call
Note the bx to an r3 that is uninitialised when r0 == 1; it should actually be
a bxne. The bug in arm.md is fairly clear: the %? is missing from two bx
instructions, so the predicate is omitted. After identifying the bad code I
discovered that the issue was raised in review, but deemed irrelevant
(http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01022.html).
The attached patch fixes the bug for me.
[Bug libgcc/58061] New: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061
Bug ID: 58061
Summary: internal compiler error
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: whitequill at abstractions dot me
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.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux)
AR=/tools/bin/$LFS_TGT-ar RANLIB=/tools/bin/$LFS_TGT-ranlib
/mnt/Share/source/gcc/configure --build=$MACHTYPE --host=$MACHTYPE
--target=$LFS_TGT --prefix=/tools --disable-nls --disable-shared
--disable-multilib --disable-decimal-float --disable-threads
--disable-libmudflap --disable-libssp --disable-libgomp
--enable-languages=c,c++ --without-ppl --without-cloog
--with-headers=/tools/$LFS_TGT/include
/home/lfs/./gcc/xgcc -B/home/lfs/./gcc/ -L/tools/x86_64-w64-mingw32/lib
-L/tools/mingw/lib -isystem /tools/x86_64-w64-mingw32/include -isystem
/tools/mingw/include -B/tools/x86_64-w64-mingw32/bin/
-B/tools/x86_64-w64-mingw32/lib/ -isystem /tools/x86_64-w64-mingw32/include
-isystem /tools/x86_64-w64-mingw32/sys-include-g -O2 -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-I. -I. -I../.././gcc -I/mnt/Share/source/gcc/libgcc
-I/mnt/Share/source/gcc/libgcc/. -I/mnt/Share/source/gcc/libgcc/../gcc
-I/mnt/Share/source/gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o
_trampoline.o -MT _trampoline.o -MD -MP -MF _trampoline.dep -DL_trampoline -c
/mnt/Share/source/gcc/libgcc/libgcc2.c
In file included from /home/lfs/gcc/include/x86intrin.h:27:0,
from /tools/x86_64-w64-mingw32/include/intrin.h:30,
from /tools/x86_64-w64-mingw32/include/winnt.h:1444,
from /tools/x86_64-w64-mingw32/include/windef.h:137,
from /tools/x86_64-w64-mingw32/include/windows.h:62,
from /mnt/Share/source/gcc/libgcc/libgcc2.c:2082:
/home/lfs/gcc/include/ia32intrin.h:54:9: internal compiler error: in
c_builtin_function_ext_scope, at c/c-decl.c:3633
#pragma GCC target("sse4.2")
^
0x50f1a2 c_builtin_function_ext_scope(tree_node*)
/mnt/Share/source/gcc/gcc/c/c-decl.c:3633
0x808f01 add_builtin_function_common
/mnt/Share/source/gcc/gcc/langhooks.c:561
0x809bb3 add_builtin_function_ext_scope(char const*, tree_node*, int,
built_in_class, char const*, tree_node*)
/mnt/Share/source/gcc/gcc/langhooks.c:597
0xb7fdc8 ix86_add_new_builtins
/mnt/Share/source/gcc/gcc/config/i386/i386.c:27184
0xb7fdc8 ix86_valid_target_attribute_tree(tree_node*)
/mnt/Share/source/gcc/gcc/config/i386/i386.c:4512
0x5c99d0 ix86_pragma_target_parse
/mnt/Share/source/gcc/gcc/config/i386/i386-c.c:385
0x5afb6d handle_pragma_target
/mnt/Share/source/gcc/gcc/c-family/c-pragma.c:805
0x54f5be c_parser_pragma
/mnt/Share/source/gcc/gcc/c/c-parser.c:8972
0x55ffeb c_parser_external_declaration
/mnt/Share/source/gcc/gcc/c/c-parser.c:1345
0x560957 c_parser_translation_unit
/mnt/Share/source/gcc/gcc/c/c-parser.c:1251
0x560957 c_parse_file()
/mnt/Share/source/gcc/gcc/c/c-parser.c:11223
0x5ad6f4 c_common_parse_file()
/mnt/Share/source/gcc/gcc/c-family/c-opts.c:1046
for proper reproduction the version of gcc build being cross-built was:
revision: 201377 from svn update.
the headers being included are here:
http://mingw-wine.googlecode.com/files/mingw64api-mingwport-src.7z
/mnt/network/source/mingw64api-mingwport-src/mingw-w64-headers/configure
--build=$MACHTYPE --host=$LFS_TGT --prefix=/tools/$LFS_TGT
[Bug libgcc/58061] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061 --- Comment #2 from Whitequill Riclo --- This is the first bug I have reported, so I didn't know where to look to see if it has been reported before. Also I can reproduce it over, and over again without fail. I was a little unnerved when I saw the text: "Please submit a full bug report, with prepossessed source if appropriate. Please include complete back-trace with any bug report." Did I include enough?
[Bug c/50584] No warning for passing small array to C99 static array declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 Malcolm Inglis changed: What|Removed |Added CC||me at minglis dot id.au --- Comment #2 from Malcolm Inglis --- GCC 4.8.1 is still failing to warn for static array indices in function parameters. The C99 status pages say this feature has been done since 3.1: http://gcc.gnu.org/gcc-3.1/c99status.html Was there a regression?
[Bug libgcc/58061] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061 --- Comment #3 from Whitequill Riclo --- I can not proceseed with a project due to this bug, is there anything I can do in the mean time?
[Bug c++/58366] New: thread_local class containing bound function leads to : "Illegal instruction: 4"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366 Bug ID: 58366 Summary: thread_local class containing bound function leads to : "Illegal instruction: 4" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jbcoe at me dot com Created attachment 30768 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30768&action=edit small program illustrating crash I've struggled to pare this bug down to a smaller example but noticed that invocation of a thread_local random number generating functor in GCC 4.8.1 caused a regular, though not always reproducible, crash that I did not see in Clang 3.3. Both thread_local and use of std::bind seem to be necessary to reproduce the crash. Code was compiled with -std=c++11
[Bug c++/58366] invocation of thread_local class containing bound function leads to : "Illegal instruction: 4"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366 Jonathan Coe changed: What|Removed |Added CC||jbcoe at me dot com --- Comment #2 from Jonathan Coe --- Created attachment 30777 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30777&action=edit Crash log
[Bug c++/58366] invocation of thread_local class containing bound function leads to : "Illegal instruction: 4"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366 --- Comment #4 from Jonathan Coe --- Yes, I've built on OS X 10.8.4 using a macports build of GCC 4.8.1. I've tried adding -pthread when building - it makes no difference to the crashing. 19 of 20 runs on my machine crash. I think if you managed 10-20 runs without a crash I think that the bug does not exist on your machine.
[Bug c++/58366] invocation of thread_local class containing bound function leads to : "Illegal instruction: 4"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366 --- Comment #8 from Jonathan Coe --- I've pared down the example. The crash is much harder to reproduce now (maybe 1 in 20 runs). Please find code and crash log attached.
[Bug c++/58366] invocation of thread_local class containing bound function leads to : "Illegal instruction: 4"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366 --- Comment #10 from Jonathan Coe --- Created attachment 30780 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30780&action=edit OSX 10.8.4 Crash log from smaller program crash
[Bug c++/58366] invocation of thread_local class containing bound function leads to : "Illegal instruction: 4"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366 Jonathan Coe changed: What|Removed |Added Attachment #30768|0 |1 is obsolete|| --- Comment #9 from Jonathan Coe --- Created attachment 30779 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30779&action=edit Smaller program illustrating crash (fewer includes)
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #21 from Whitequill Riclo --- The patch worked for me, but now I'm getting a new error that looks like Bug 47052 accept the proposed fix doesn't work because is says DW2 isn't suppored on 64-bit yet. I can get around this if I change "--enable-languages=c,c++" to "--enable-languages=c", but I don't really want to, cause then I don't have a c++ compiler. checking whether the /home/lfs/build.gcc1/./gcc/xgcc -shared-libgcc -B/home/lfs/build.gcc1/./gcc -nostdinc++ -L/home/lfs/build.gcc1/x86_64-w64-mingw32/libstdc++-v3/src -L/home/lfs/build.gcc1/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/tools/x86_64-w64-mingw32/lib -L/tools/mingw/lib -isystem /tools/x86_64-w64-mingw32/include -isystem /tools/mingw/include -B/tools/x86_64-w64-mingw32/bin/ -B/tools/x86_64-w64-mingw32/lib/ -isystem /tools/x86_64-w64-mingw32/include -isystem /tools/x86_64-w64-mingw32/sys-includelinker (/home/lfs/build.gcc1/./gcc/collect-ld) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking for exception model to use... call frame checking for compiler with PCH support... yes checking for enabled PCH... yes checking for thread model used by GCC... single checking for atomic builtins for bool... yes checking for atomic builtins for short... yes checking for atomic builtins for int... yes checking for atomic builtins for long long... yes checking for ISO/IEC TR 24733 ... no checking for __int128... yes checking for __float128... yes checking for g++ that supports -ffunction-sections -fdata-sections... yes checking for underlying I/O to use... stdio checking for C locale to use... generic checking for std::allocator base class... new configure: "C" header strategy set to c_global checking for enabled long long specializations... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for mbstate_t... yes checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for enabled wchar_t specializations... yes checking for ISO C99 support in ... yes checking tgmath.h usability... yes checking tgmath.h presence... yes checking for tgmath.h... yes checking complex.h usability... yes checking complex.h presence... yes checking for complex.h... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for fully enabled ISO C99 support... yes configure: Debug build flags set to -gdwarf-4 -g3 -O0 checking for additional debug build... no configure: target-libgomp not built checking for parallel mode support... no checking for extra compiler flags for building... checking for extern template support... yes checking for custom python install directory... no checking for -Werror... yes checking for gets declaration... yes checking for EOWNERDEAD... no checking for ENOTRECOVERABLE... no checking for ENOLINK... no checking for EPROTO... no checking for ENODATA... no checking for ENOSR... no checking for ENOSTR... no checking for ETIME... no checking for EBADMSG... no checking for ECANCELED... no checking for EOVERFLOW... no checking for ENOTSUP... no checking for EIDRM... no checking for ETXTBSY... no checking for ECHILD... yes checking for ENOSPC... yes checking for EPERM... yes checking for ETIMEDOUT... no checking for EWOULDBLOCK... no checking for int64_t... yes checking for int64_t as long... checking for int64_t as long long... yes checking for LFS support... yes checking sys/ioctl.h usability... no checking sys/ioctl.h presence... no checking for sys/ioctl.h... no checking sys/filio.h usability... no checking sys/filio.h presence... no checking for sys/filio.h... no checking for poll... no checking for S_ISREG or S_IFREG... S_ISREG checking sys/uio.h usability... no checking sys/uio.h presence... no checking for sys/uio.h... no checking for writev... no checking for complex.h... (cached) yes checking for ISO C99 support to TR1 in ... yes checking for ISO C99 support to TR1 in ... yes checking fenv.h usability... yes checking fenv.h presence... yes checking for fenv.h... yes checking for ISO C99 support to TR1 in ... yes checking for ISO C99 support to TR1 in ... yes checking for ISO C99 support to TR1 in ... yes checking for ISO C99 support to TR1 in ... yes checking for wchar_t ISO C99 support to TR1 in ... yes checking stdbool.h usability... yes checking stdbool.h presence... yes checking for stdbool.h... yes checking stdalign.h usability... yes checking stdalign.h presence... yes checking for stdalign.h... yes checking for the value of EOF... -1 checking for the value of SEEK_CUR... 1 checking for the value of SEEK_END... 2 checking for gettimeofday... checking sys/time.h usability... yes checking sy
[Bug c++/52892] Function pointer loses constexpr qualification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52892
Adrien Guinet changed:
What|Removed |Added
CC||adrien at guinet dot me
--- Comment #2 from Adrien Guinet 2012-05-29 09:26:29
UTC ---
Hello everyone,
Im ay have an issue related to this issue, if that can help:
#include
struct A
{
void f(int i) { std::cout << "f " << i << " " << _i << std::endl; }
void f2(int i) { std::cout << "f2 " << i << " " << _i << std::endl; }
int _i;
};
template
struct class_f
{
typedef F f_type;
static constexpr f_type f_value = f;
static constexpr f_type get() { return f; }
};
int main()
{
typedef class_f ff_t;
// This does not compile
class_f ff;
// This does not compile either
class_f(&A::f)> ff2;
// This does
class_f ff_works;
}
It looks like using a function pointer that has been "instantiated" as an
"f_type" makes the compilation fails. here is the output of g++-4.7 with the
first "failing" tests :
$ g++-4.7 -std=c++0x ftempl.cpp
ftempl.cpp: In function ‘int main()’:
ftempl.cpp:24:37: error: could not convert template argument ‘class_f::f_value’ to ‘void (A::*)(int)’
ftempl.cpp:24:41: error: invalid type in declaration before ‘;’ token
$ g++-4.7 --version
g++-4.7 (Debian 4.7.0-8) 4.7.0
[Bug libgomp/53600] New: Fatal Error: Can't open module file 'omp_lib.mod' for reading at (1).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53600 Bug #: 53600 Summary: Fatal Error: Can't open module file 'omp_lib.mod' for reading at (1). Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: pascu...@me.com I was able to successfully install the family of gcc compiles in Cygwin. I tried to compile a Fortran90 code with the option -fopenmp and I got the following error message (the program uses OpenMP directives): Fatal Error: Can't open module file 'omp_lib.mod' for reading at (1). No such file or directory Thank you very much for all your help.
[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531 --- Comment #4 from kaladhorn at me dot com 2012-06-08 18:46:11 UTC --- (In reply to comment #3) > (In reply to comment #2) > > Out of curiosity, would there be a technical issue in this case? > > It sure seemed natural to me. > > AFAICS there should not be any huge issues. One might consider to implement > this as an extension. If it does not hurt, I think it would be a good thing. As far as I am concerned, I engineered around it, as it is really an edge case we do not want to rely on. It arguably makes some code uglier, though.
[Bug fortran/52531] New: Compilation fails with polymorphic dummy argument and OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531 Bug #: 52531 Summary: Compilation fails with polymorphic dummy argument and OpenMP Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: kaladh...@me.com The following code does not compile: -- module test_mod type, public :: test_type end type contains subroutine foo(bar) type(test_type) :: bar !$omp parallel default(none) shared(bar) ! Compiles if one removes default(none) call question(bar) !$omp end parallel end subroutine subroutine question(var) class(test_type), intent(in) :: var ! Compiles if one replaces class by type end subroutine end module -- The error message is: ‘__vtab_test_mod_Test_type’ not specified in enclosing parallel This was reproduced with gfortran 4.6 (gcc version 4.6.3 (GCC) ) and 4.7 (gcc version 4.7.0 20120121 (experimental) (GCC) ) on x86_64-unknown-linux-gnu .
[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531 --- Comment #2 from kaladhorn at me dot com 2012-03-08 19:33:24 UTC --- (In reply to comment #1) > OpenMP 3.1 or earlier releases don't cover Fortran 2003 nor 2008, so what you > are trying to compile is not valid. hmm that's true, I did not think of it that way. My apologies, then. However, I think a proper error message would be nice. Out of curiosity, would there be a technical issue in this case? It sure seemed natural to me. Thanks!
[Bug c/50584] No warning for passing small array to C99 static array declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 --- Comment #4 from Malcolm Inglis --- I don't have a copy of the C99 standard, but IBM says [1] that if the function is called with a pointer to a smaller array than specified with `static`, then the behavior is undefined. Ergo, there should be a warning. Could someone change the status of this bug? I'm about 60% sure that I once played around with this in GCC, and it correctly reported an error. This wouldn't have been too long ago; maybe 4.6 or even 4.7. Clang emits a warning for this. [2] I think this is a fantastic language feature. It's a shame GCC doesn't support it yet. [1]: http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/topic/com.ibm.xlcpp8a.doc/language/ref/param_decl.htm [2]: http://hamberg.no/erlend/posts/2013-02-18-static-array-indices.html
[Bug fortran/51605] New: internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 Bug #: 51605 Summary: internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: danlna...@me.com Created attachment 26126 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26126 output copied from shell window and source file
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 --- Comment #1 from Dan Nagle 2011-12-17 22:45:42 UTC --- Compiles with fort 12.1, nagfor has a different problem.
[Bug fortran/51607] New: configure: error: GNU fortran compiler is not working ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607 Bug #: 51607 Summary: configure: error: GNU fortran compiler is not working ; Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.barr...@me.com checking whether we are using the GNU Fortran compiler... yes checking whether /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includeaccepts -g... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includeoption to produce PIC... -fno-common checking if /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includePIC flag -fno-common works... yes checking if /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includestatic flag -static works... no checking if /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includesupports -c -o file.o... yes checking if /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includesupports -c -o file.o... (cached) yes checking whether the /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includelinker (/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/collect-ld) supports shared libraries... yes checking dynamic linker characteristics... darwin11.2.0 dyld checking how to hardcode library paths into programs... immediate checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /Users/Exodus/downloads/gcc-4.6.2/build/x86_64-apple-darwin11.2.0/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make: *** [all] Error 2 i'm quite new to unix, i have tried to find solutions to this but any help/pointers would be useful
[Bug fortran/51607] configure: error: GNU fortran compiler is not working ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607 --- Comment #1 from David 2011-12-18 09:25:27 UTC --- Created attachment 26127 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26127 fortran library config log
