[Bug c++/115239] New: ICE: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115239
Bug ID: 115239
Summary: ICE: internal compiler error: Segmentation fault
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
Link at Compiler Explorer:
https://godbolt.org/z/b1oW566E5
I stumbled on this while compiling some invalid code during refactoring.
Test case has been reduced by cvise.
Discovered using gcc-14.1.1-4.fc40.x86_64. Might be a regression - gcc-13 does
not crash.
Acutal code: ```
constexpr bool foo(const char *, char *, long) { return true; }
constexpr bool foo(const char *, char *, unsigned) { return true; }
constexpr bool foo(char, char, long) { return true; }
constexpr bool foo(char, char, unsigned) { return true; }
static_assert(foo((char *)nullptr, nullptr, 0));
```
[Bug c++/111606] [11/12/13/14 Regression] [ICE] internal compiler error: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606 --- Comment #6 from Markus F.X.J. Oberhumer --- @Andrew Pinksi Many thanks for cleaning up the bug case! cvise (https://github.com/marxin/cvise) did correctly reduce the original from ~5 lines to 18 lines, but the result looked extremely strange...
[Bug c++/111606] [ICE] internal compiler error: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606 --- Comment #1 from Markus F.X.J. Oberhumer --- Created attachment 55999 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55999=edit bug.cpp Added attachment bug.cpp
[Bug c++/111606] New: [ICE] internal compiler error: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606 Bug ID: 111606 Summary: [ICE] internal compiler error: error reporting routines re-entered. Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: markus at oberhumer dot com Target Milestone: --- Link at Compiler Explorer: https://godbolt.org/z/EbPWr3qxx I stumbled on this while compiling some invalid code during refactoring. Test case has been reduced by cvise. Might be related to / duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90747 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557
[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #6 from Markus F.X.J. Oberhumer --- Please note that I'm explicitly using "int_max" and not "INT_MAX", and I'd appreciate if you could give me a link where the standard says this is "ill-formed". Thanks!
[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #3 from Markus F.X.J. Oberhumer --- Indeed. And just for reference I had also reported this as clang bug in https://github.com/llvm/llvm-project/issues/59195
[Bug c++/107861] New: C++ static_assert() does not honor -fwrapv, leading to compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 Bug ID: 107861 Summary: C++ static_assert() does not honor -fwrapv, leading to compilation error Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: markus at oberhumer dot com Target Milestone: --- C++ static_assert() does not honor -fwrapv, leading to compilation error godbolt link: https://gcc.godbolt.org/z/Po8vc5Kex $ g++ --version g++ (GCC) 12.2.1 20220819 (Red Hat 12.2.1- $ g++ -fwrapv -Wno-overflow -c test.cpp test.cpp:7:34: error: non-constant condition for static assertion $ cat test.cpp // compile with: g++ -fwrapv -Wno-overflow -c test.cpp // // extra rant: -Wno-overflow should not be needed here! #include #define wrap_inc(x) ((x) + 1 < (x)) constexpr int int_max = INT_MAX; bool b0 = wrap_inc(int_max); const bool b1 = wrap_inc(int_max); constexpr bool b2 = wrap_inc(int_max); static_assert(b2, ""); // works // error: non-constant condition for static assertion static_assert(wrap_inc(int_max), "");
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #54 from Markus F.X.J. Oberhumer --- Many thanks for finally fixing this!
[Bug c++/29823] attribute((sentinel)) warning does not trigger for member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29823 Markus F.X.J. Oberhumer changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Markus F.X.J. Oberhumer --- This seems to have been fixed in gcc-4.9.
[Bug preprocessor/64698] preprocessor ignores #pragma GCC diagnostic when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64698 --- Comment #2 from Markus F.X.J. Oberhumer --- Still a problem in 2021 with gcc-11.1.0
[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920 Markus F.X.J. Oberhumer changed: What|Removed |Added CC||markus at oberhumer dot com --- Comment #3 from Markus F.X.J. Oberhumer --- Still a problem in 2021 with gcc-11.1.0
[Bug middle-end/95903] gcc 10: wrong code with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903 --- Comment #9 from Markus F.X.J. Oberhumer --- [ Just for reference, created bug 95908 ]
[Bug target/95908] New: [AArch64] wrong code with ILP32 and -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95908
Bug ID: 95908
Summary: [AArch64] wrong code with ILP32 and -fwrapv
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
[this issue has been extraced from bug 95903]
Link at Compiler Explorer: https://gcc.godbolt.org/z/mRf2kd
The function below does compute the address in 64 (and not in 32) bits, which
seems wrong when using "-fwrapv -fwrapv-pointer".
As discussed in bug 95903 some feedback from the target maintainer
would be welcome.
// arm64-linux-gcc -mabi=ilp32 -O2 -fwrapv -fwrapv-pointer
char get_byte(const char* ptr, int off)
{
off += 2147483647;
return ptr[off];
}
[Bug middle-end/95903] gcc 10: wrong code with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903 --- Comment #8 from Markus F.X.J. Oberhumer --- Got it, thanks!
[Bug middle-end/95903] gcc 10: wrong code with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #6 from Markus F.X.J. Oberhumer ---
Thanks for the quick fix!
And no need to be grumpy, I'm just trying to nail down those pesky edge
cases...
As for ILP32, here is another suspicious test case, now only using just a
little bit more than 2 GiB of memory: https://gcc.godbolt.org/z/mRf2kd
// arm64-linux-gcc -mabi=ilp32 -O2 -fwrapv -fwrapv-pointer
char get_byte(const char* ptr, int off)
{
off += 2147483647;
return ptr[off];
}
[Bug middle-end/95903] gcc 10: wrong code with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903 --- Comment #4 from Markus F.X.J. Oberhumer --- Yes, ilp32 might be a corner case. Still, clang-10 does create the expected code. See https://gcc.godbolt.org/z/aEokbX for clang-10 -target arm64_32-ios -O2 -fomit-frame-pointer -fwrapv and clang-10 -target arm64_32-ios -O2 -fomit-frame-pointer -fno-wrapv
[Bug middle-end/95903] gcc 10: wrong code with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903 --- Comment #2 from Markus F.X.J. Oberhumer --- Somewhat related: the same code compiled with arm64-gcc -mabi=ilp32 -frwapv does miscompile *both* functions. See https://gcc.godbolt.org/z/uxDAtx Should I open a new issue for this?
[Bug middle-end/95903] New: gcc 10: wrong code with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
Bug ID: 95903
Summary: gcc 10: wrong code with -fwrapv
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
Link at Compiler Explorer: https://godbolt.org/z/VgNLcX
The following 2 functions should generate identical code when using "-fwrapv",
but
the second function is missing the sign extension after the add.
// compile with: gcc-10 -m64 -O2 -fwrapv
char get_byte_use_add(const char* ptr, int off)
{
off += 1;
return ptr[off];
}
char get_byte_use_plus(const char* ptr, int off)
{
return ptr[off + 1]; // gcc: BUG
}
[Bug c/93287] _Static_assert creates spurious -Wdeclaration-after-statement warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287 --- Comment #5 from Markus F.X.J. Oberhumer --- I see, many thanks for the clarification. Still this is not nice from a usability perspective - why did the standard make this a declaration instead of a statement? Well, will revert back to using homegrown COMPILE_TIME_ASSERT macros...
[Bug c/93287] _Static_assert creates spurious -Wdeclaration-after-statement warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287 --- Comment #2 from Markus F.X.J. Oberhumer --- This is somewhat unexpected, and I do not get any warnings when using clang: $ clang-9 -Wdeclaration-after-statement test.c
[Bug c/93287] New: _Static_assert creates spurious -Wdeclaration-after-statement warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
Bug ID: 93287
Summary: _Static_assert creates spurious
-Wdeclaration-after-statement warnings
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
gcc 9 under Fedora 31: gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
The small program below creates spurious warnings:
$ gcc -Wdeclaration-after-statement test.c
test.c: In function ‘main’:
test.c:4:5: warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
4 | _Static_assert(1 == 1, "error");
| ^~
$ cat test.c
int main() {
int r;
r = 0;
_Static_assert(1 == 1, "error");
return r;
}
[Bug middle-end/64516] [5 Regression] arm: wrong unaligned load generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516 --- Comment #11 from Markus F.X.J. Oberhumer --- Did you have a chance to backport this for 5.5 yet ? Thanks, Markus
[Bug middle-end/64516] [4.9/5 Regression] arm: wrong unaligned load generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516 --- Comment #8 from Markus F.X.J. Oberhumer --- Richard, many thanks for finally fixing this issue. Will there be a backport to 4.9.4 and/or 5.4 ?
[Bug target/64516] [4.x Regression] arm: wrong unaligned load generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516 --- Comment #3 from Markus F.X.J. Oberhumer markus at oberhumer dot com --- Just for reference, here is the expected result: $ clang -target armv5-unknown-linux-gnu -marm -mfloat-abi=soft --version clang version 3.5.1 (tags/RELEASE_351/final) Target: armv5-unknown-linux-gnu Thread model: posix $ clang -target armv5-unknown-linux-gnu -marm -mfloat-abi=soft -O2 -Wall -W -Wcast-align -c unaligned_load_bug.c $ arm-linux-gnueabihf-objdump -d unaligned_load_bug.o unaligned_load_bug.o: file format elf32-littlearm Disassembly of section .text: put16_unaligned: 0: e5c01000strbr1, [r0] 4: e1a01421lsr r1, r1, #8 8: e5c01001strbr1, [r0, #1] c: e12fff1ebx lr 0010 get16_unaligned: 10: e5d01000ldrbr1, [r0] 14: e5d1ldrbr0, [r0, #1] 18: e1810400orr r0, r1, r0, lsl #8 1c: e12fff1ebx lr 0020 put16_aligned: 20: e1c010b0strhr1, [r0] 24: e12fff1ebx lr 0028 get16_aligned: 28: e1d000b0ldrhr0, [r0] 2c: e12fff1ebx lr
[Bug target/64516] [4.x Regression] arm: wrong unaligned load generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516
Markus F.X.J. Oberhumer markus at oberhumer dot com changed:
What|Removed |Added
Known to work||4.3.3
--- Comment #2 from Markus F.X.J. Oberhumer markus at oberhumer dot com ---
This is a wrong code regression against gcc 4.3.3.
I've booted an older ARM Ubuntu box just for testing:
$ gcc -v
[...]
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
$ gcc -O3 -Wall -W -Wcast-align -c unaligned_load_bug.c
$ objdump -d unaligned_load_bug.o
unaligned_load_bug.o: file format elf32-littlearm
Disassembly of section .text:
put16_unaligned:
0: e52de004push{lr}; (str lr, [sp, #-4]!)
4: e24dd00csub sp, sp, #12 ; 0xc
8: e28d3008add r3, sp, #8 ; 0x8
c: e3a02002mov r2, #2 ; 0x2
10: e16310b2strhr1, [r3, #-2]!
14: e1a01003mov r1, r3
18: ebfebl 0 memcpy
1c: e28dd00cadd sp, sp, #12 ; 0xc
20: e8bd8000pop {pc}
0024 get16_unaligned:
24: e52de004push{lr}; (str lr, [sp, #-4]!)
28: e24dd00csub sp, sp, #12 ; 0xc
2c: e1a01000mov r1, r0
30: e3a02002mov r2, #2 ; 0x2
34: e28d0006add r0, sp, #6 ; 0x6
38: ebfebl 0 memcpy
3c: e1dd00b6ldrhr0, [sp, #6]
40: e28dd00cadd sp, sp, #12 ; 0xc
44: e8bd8000pop {pc}
0048 put16_aligned:
48: e1c010b0strhr1, [r0]
4c: e12fff1ebx lr
0050 get16_aligned:
50: e1d000b0ldrhr0, [r0]
54: e12fff1ebx lr
[Bug preprocessor/64698] New: preprocessor ignores #pragma GCC diagnostic when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64698
Bug ID: 64698
Summary: preprocessor ignores #pragma GCC diagnostic when using
-save-temps
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
This could be related to bug 53431, though this report is about C and not C++.
Actually I had thought that -save-temps just dumps the internal state, but
that does not seem to be true.
The following code:
#pragma GCC diagnostic ignored -Wundef
#if FOO
#endif
int main (void) { return 42; }
compiled with
gcc-4.9 -Wundef -Werror -save-temps -c bug_wundef.c
gives:
bug_wundef.c:2:5: error: FOO is not defined [-Werror=undef]
#if FOO
^
cc1: all warnings being treated as errors
On the contrary
gcc-4.9 -Wundef -Werror -c bug_wundef.c
does not give any error.
[Bug target/64516] New: arm: wrong unaligned load generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516
Bug ID: 64516
Summary: arm: wrong unaligned load generated
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Created attachment 34391
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34391action=edit
unaligned_load_bug.c to reproduce the problem.
arm: bad code generated = run time crash
- gcc 4.9.2 seems to forget the attribute(packed) in some cases.
- please see the disassembly for get16_unaligned().
- put16_unaligned() is correct !
- FWIW, gcc 4.3.5 and clang 3.5 work
~Markus
$ cat unaligned_load_bug.c
typedef struct { char a[2]; } __attribute__((__packed__)) TU2;
// OK: correct (but poor) code generated for the store
void put16_unaligned(void *p, unsigned short v) {
if (sizeof(TU2) == sizeof(v) __alignof__(TU2) == 1) {
*(TU2 *)p = *(const TU2 *)(const void *)(v);
}
}
// BUG: incorrect transformation into an aligned load = run time crash !!
unsigned short get16_unaligned(const void *p) {
unsigned short v;
if (sizeof(TU2) == sizeof(v) __alignof__(TU2) == 1) {
*(TU2 *)(void *)(v) = *(const TU2 *)p;
}
return v;
}
// aligned versions - just for comparison
void put16_aligned(void *p, unsigned short v) {
*(unsigned short *)p = *(v);
}
unsigned short get16_aligned(const void *p) {
unsigned short v;
*(v) = *(const unsigned short *)p;
return v;
}
// EOF
$ arm-linux-gnueabi-gcc-4.9 -v
gcc version 4.9.2 (Ubuntu/Linaro 4.9.2-7ubuntu3)
$ arm-linux-gnueabi-gcc-4.9 -march=armv4 -marm -O2 -Wall -W -Wcast-align -c
unaligned_load_bug.c
$ arm-linux-gnueabi-objdump -d unaligned_load_bug.o
unaligned_load_bug.o: file format elf32-littlearm
Disassembly of section .text:
put16_unaligned:
0: e52de004push{lr}; (str lr, [sp, #-4]!)
4: e24dd00csub sp, sp, #12
8: e28d3008add r3, sp, #8
c: e16310b2strhr1, [r3, #-2]!
10: e3a02002mov r2, #2
14: e1a01003mov r1, r3
18: ebfebl 0 memcpy
1c: e28dd00cadd sp, sp, #12
20: e49de004pop {lr}; (ldr lr, [sp], #4)
24: e12fff1ebx lr
0028 get16_unaligned:
28: e1d000b0ldrhr0, [r0]
2c: e12fff1ebx lr
0030 put16_aligned:
30: e1c010b0strhr1, [r0]
34: e12fff1ebx lr
0038 get16_aligned:
38: e1d000b0ldrhr0, [r0]
3c: e12fff1ebx lr
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored -Wundef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Markus F.X.J. Oberhumer markus at oberhumer dot com changed: What|Removed |Added CC||markus at oberhumer dot com --- Comment #2 from Markus F.X.J. Oberhumer markus at oberhumer dot com 2013-03-03 04:09:42 UTC --- Still NOT fixed in gcc-4.8-20130210.
[Bug c++/29823] New: attribute((sentinel)) warning does not trigger for member function template
// gcc-bug: attribute((sentinel)) warning does not trigger for member function
template
//
// how to reproduce: g++-4.1.1 -Wall -c test.cpp
// Markus F.X.J. Oberhumer [EMAIL PROTECTED]
#define SENTINEL __attribute__((__sentinel__))
void func1(const char *, ...) SENTINEL;
template class Tvoid func2(const T *, ...)SENTINEL;
static void func3(const char *, ...) SENTINEL;
template class T static void func4(const T *, ...)SENTINEL;
struct C {
void func1(const char *, ...) SENTINEL;
template class Tvoid func2(const T *, ...)SENTINEL;
static void func3(const char *, ...) SENTINEL;
template class T static void func4(const T *, ...)SENTINEL;
};
static void func3(const char *, ...) { } // definition
void foo(C c)
{
func1(a, b);// warning here
func2(a, b);// warning here
func3(a, b);// warning here
func4(a, b);// warning here
c.func1(a, b); // warning here
c.func2(a, b); // NO warning here !
c.func3(a, b); // warning here
c.func4(a, b); // NO warning here !
}
--
Summary: attribute((sentinel)) warning does not trigger for
member function template
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29823
[Bug rtl-optimization/25196] [4.0 Regression] i386: wrong arguments passed
--- Comment #10 from markus at oberhumer dot com 2006-01-27 18:03 --- What is the status of this bug for gcc 4.0.3 ? According to the thread at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00542.html it seems it has been approved a while ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug target/25196] New: i386: wrong arguments passed
I really had a hard time tracking this down from a large program: gcc 4.0.2 on i386-linux sometimes passes wrong arguments. Please try the attached source file on i386 with gcc-4.0.2 -march=i386 -O3 -fomit-frame-pointer. When looking at the disassembly of f2() it seems that %edi is incorrectly used twice: 5e: 89 f8 mov%edi,%eax ! 60: ff 74 24 24 pushl 0x24(%esp) 64: 55 push %ebp 65: 89 f9 mov%edi,%ecx ! 67: 89 da mov%ebx,%edx 69: e8 92 ff ff ff call 0 f1 This wrong-code bug is probably a 3.2, 3.3 and 3.4 regression. ~Markus -- Summary: i386: wrong arguments passed Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus at oberhumer dot com GCC host triplet: i386-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug target/25196] i386: wrong arguments passed
--- Comment #1 from markus at oberhumer dot com 2005-12-01 06:06 --- Created an attachment (id=10373) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10373action=view) wrong_args.c Please try gcc-4.0.2 -march=i386 -O3 -fomit-frame-pointer wrong_args.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug target/21715] New: code-generation regression
During recent performance testing I have identified a number of small code
fragments where gcc 4.x produces worse code than gcc 3.4.3. Some of these may be
target specific, and I plan to gradually enter such small performance
regressions into the bug database unless there is a better way to report these.
$ cat test.c
long foo(long v) { return v -v; }
$ gcc-3.4.3 -O3 -c test.c objdump -d test.o
test.o: file format elf64-x86-64
Disassembly of section .text:
foo:
0: 48 89 f8mov%rdi,%rax
3: 48 f7 d8neg%rax
6: 48 21 f8and%rdi,%rax
9: c3 retq
$ gcc-4.1-20050516 -O3 -c test.c objdump -d test.o
test.o: file format elf64-x86-64
Disassembly of section .text:
foo:
0: 48 89 f8mov%rdi,%rax
3: 48 f7 d8neg%rax
6: 48 21 c7and%rax,%rdi
9: 48 89 f8mov%rdi,%rax
c: c3 retq
--
Summary: code-generation regression
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86_64-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug target/21715] code-generation performance regression
-- What|Removed |Added Keywords||missed-optimization Known to fail||4.0.0 4.1.0 Known to work||3.4.3 Summary|code-generation regression |code-generation performance ||regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug tree-optimization/20922] missed always false conditional
--- Additional Comments From markus at oberhumer dot com 2005-04-25 00:38
---
Is this optimization really legal in C/C++? Could some language lawyer look at
this (and check the output when compiling with -O3):
#include limits.h
int f1(int i) { return (i - 2) i; }
int f2(int i) { return (i + 2) i; }
int g1(void) { return f1(INT_MIN); }
int g2(void) { return f2(INT_MAX); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
[Bug tree-optimization/20922] missed always false conditional
--- Additional Comments From markus at oberhumer dot com 2005-04-25 01:01 --- Ah, many thanks for the clarification. Still it's somewhat confusing that f1() and g1() don't agree after inlining, but undefined probably means exactly that... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
[Bug other/17361] [3.3 Regression] gcc driver complains about C++ options when assembling
--- Additional Comments From markus at oberhumer dot com 2005-01-21 02:02 --- This seems to be fixed for 3.4 and 4.0 now, so the bug should be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17361
[Bug c++/17115] [3.3 Regression] -Winline does not respect __attribute__((__noinline__))
--- Additional Comments From markus at oberhumer dot com 2005-01-21 02:02 --- This seems to be fixed for 3.4 and 4.0 now, so the bug should be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17115
[Bug middle-end/18071] [3.4/4.0 Regression] -Winline does not respect -fno-default-inline
--- Additional Comments From markus at oberhumer dot com 2005-01-21 02:10 --- What is the status of the latest patch from Giovanni ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug c++/18744] C++ ABI is incomplete for ILP64
--- Additional Comments From markus at oberhumer dot com 2005-01-21 02:14 --- Just a short update that the MIPS -mint64 option works again in mainline, so the ICE reported here is back for both the 3.4 and 4.0 branches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18744
[Bug target/18759] [x86] using both -fomit-frame-pointer and -momit-leaf-frame-pointer enables frame pointers for non-leaf functions
--- Additional Comments From markus at oberhumer dot com 2004-12-02 21:28 --- Might this be a candidate for 3.3/3.4 backporting ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18759
[Bug c/18799] error: static declaration of 'x' follows non-static declaration
--- Additional Comments From markus at oberhumer dot com 2004-12-02 23:12 --- I'm reopening this against gcc-3.4.3 then, as the warning has vanished - a possible regression against 3.2 and 3.3. Note that gcc-3.4.3/gcc/c-decl.c talks about -Wtraditional, but even that doesn't make the warning appear. Please feel free to close this bug again if you disagree. gcc-3.3 -c -Wall -W -Wtraditional -pedantic x.c x.c:2: warning: static declaration for `x' follows non-static x.c: In function `foo': x.c:3: warning: traditional C rejects ISO C style function definitions gcc-3.4.3 -c -Wall -W -Wtraditional -pedantic x.c x.c: In function `foo': x.c:3: warning: traditional C rejects ISO C style function definitions -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | Version|4.0.0 |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18799
[Bug target/18759] New: [x86] using both -fomit-frame-pointer and -momit-leaf-frame-pointer enables frame pointers for non-leaf functions
Using both -fomit-frame-pointer and -momit-leaf-frame-pointer _enables_ frame
pointers for non-leaf functions.
cat x.c
int foo(void) { return 0; }
int bar(void) { return foo() + 1; }
gcc-3.4 -O2 -fomit-frame-pointer -c x.c objdump -d x.o
[...]
0010 bar:
10: e8 fc ff ff ff call 11 bar+0x1
15: 40 inc%eax
16: c3 ret
[...]
gcc-3.4 -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -c x.c objdump
-d x.o
[...]
0010 bar:
10: 55 push %ebp
11: 89 e5 mov%esp,%ebp
13: e8 fc ff ff ff call 14 bar+0x4
18: 5d pop%ebp
19: 40 inc%eax
1a: c3 ret
[...]
This check in i386.c ix86_frame_pointer_required() could be the cause:
/* In override_options, TARGET_OMIT_LEAF_FRAME_POINTER turns off
the frame pointer by default. Turn it back on now if we've not
got a leaf function. */
if (TARGET_OMIT_LEAF_FRAME_POINTER
(!current_function_is_leaf))
return 1;
--
Summary: [x86] using both -fomit-frame-pointer and -momit-leaf-
frame-pointer enables frame pointers for non-leaf
functions
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18759
[Bug middle-end/18071] [3.4/4.0 Regression] -Winline does not respect -fno-default-inline
--- Additional Comments From markus at oberhumer dot com 2004-11-30 19:54 --- Just a short note that the testcase has a typo and should read ... k |= f.a(r); k |= f.b(r); k |= f.c(r); ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug target/17643] ICE in propagate_one_insn, at flow.c:1582
-- What|Removed |Added GCC host triplet||hppa-linux-gnu GCC target triplet|hppa-unknown-linux-gnu |hppa-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17643
[Bug c++/18744] New: C++ ABI is incomplete for ILP64
The C++ ABI is missing fallbacks for exact 16- and 32-bit types when
using programming models like ILP64 (e.g. MIPS -mint64 option below):
/opt/cross/mips-linux-uclibc-gcc341/bin/mips-linux-uclibc-g++ -c -mint64
bug01.cpp
bug01.cpp:19: internal compiler error: in write_builtin_type, at
cp/mangle.c:1686
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
typedef int int16_exact_t __attribute__((__mode__(__HI__)));
typedef int int32_exact_t __attribute__((__mode__(__SI__)));
long getbit(int16_exact_t v) { return v 1; }
long getbit(int32_exact_t v) { return v 1; }
--
Summary: C++ ABI is incomplete for ILP64
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18744
[Bug c++/18744] C++ ABI is incomplete for ILP64
--- Additional Comments From markus at oberhumer dot com 2004-11-30 20:39 --- Created an attachment (id=7642) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7642action=view) Testcase to reproduce the ICE. Testcase to reproduce the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18744
[Bug c++/18744] C++ ABI is incomplete for ILP64
--- Additional Comments From markus at oberhumer dot com 2004-11-30 20:42 --- Created an attachment (id=7643) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7643action=view) Quick and dirty patch for gcc/cp/mangle.c . This is just a quick patch, but I think this issue should be addressed in the C++ ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18744
[Bug c++/18744] C++ ABI is incomplete for ILP64
--- Additional Comments From markus at oberhumer dot com 2004-11-30 20:56 --- I'm not sure if this is really related to bug18442 - actually I've ported current mainline to generate ILP64 code on AMD64, and __mode__(__SI__) works without problems there. But it's the incomplete C++ ABI that is a showstopper for C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18744
[Bug bootstrap/18745] New: compile fix for gcc/include/md5.h
gcc/include/md5.h currently does not compile under ILP64. This tiny patch will fix this: --- md5.h 14 Mar 2001 19:44:38 - 1.3 +++ md5.h 30 Nov 2004 20:59:32 - @@ -58,9 +58,13 @@ # if LONG_MAX == INT_MAX_32_BITS typedef unsigned long md5_uint32; # else - /* The following line is intended to evoke an error. -Using #error is not portable enough. */ - Cannot determine unsigned 32-bit data type. +#if defined(__GNUC__) (__GNUC__ = 3) (__INT_MAX__ 2147483647) + typedef unsigned int md5_uint32 __attribute__ ((__mode__ (__SI__))); +#else + /* The following line is intended to evoke an error. + Using #error is not portable enough. */ + Cannot determine unsigned 32-bit data type. +#endif # endif # endif # endif -- Summary: compile fix for gcc/include/md5.h Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus at oberhumer dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18745
[Bug bootstrap/18745] compile fix for gcc/include/md5.h
--- Additional Comments From markus at oberhumer dot com 2004-11-30 21:04 --- Created an attachment (id=7644) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7644action=view) md5.h patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18745
[Bug bootstrap/18745] compile fix for gcc/include/md5.h
--- Additional Comments From markus at oberhumer dot com 2004-11-30 21:18 --- Point taken. Still please note that gcc-3.4 MIPS -mint64 does work, so IMHO this is not an unsupported target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18745
[Bug c++/18140] New: C++ parser bug when using shr () in templates
gcc incorrectly rejects the following template code - seems to be a bug in the
new (gcc 3.4) C++ parser.
g++-4.0 -Wall -W x.cpp
x.cpp:6: error: spurious '', use '' to terminate a template argument list
x.cpp:6: error: expected primary-expression before S
x.cpp:6: error: expected %;% before S
template int N struct IntHolder {
static const int value = N;
};
template int N, int S struct ShrIntHolder {
static const int value = IntHolder NS ::value;
};
--
Summary: C++ parser bug when using shr () in templates
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18140
[Bug c++/18069] New: Contradicting type and variable attributes (possible regression)
While playing around with contradicting type and variable attributes I may have
stumbled across a g++ 3.4/4.0 regression.
Here is a short example - see the attachment for full details.
typedef struct {
char dummy;
} type01c_t
__attribute__((aligned(8)))
__attribute__((aligned(4)));
In any case, some documentation is clearly needed for this and similar
attributes cases, and a warning also seems reasonable (at -Wall level).
--
Summary: Contradicting type and variable attributes (possible
regression)
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18069
[Bug c++/18069] Contradicting type and variable attributes (possible regression)
--- Additional Comments From markus at oberhumer dot com 2004-10-20 04:58 --- Created an attachment (id=7381) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7381action=view) Test program and log of failure. g++-3.4 and g++.4.0 fail. All other (including gcc-3.4 and gcc-4.0) work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18069
[Bug c/18070] New: Contradicting function attributes
This is a call for opinions on contradicting function attributes like giving both cdecl and stdcall or both always_inline and noinline. Somewhat related to bug18069 (Contradicting type and variable attributes) I've seen that contradicting inline attributes give varying results/warnings/errors, depending on gcc verision, C vs. C++ and optimization flags. At the very least the documentation needs some clarification. Using conflicting calling conventions (both cdecl and stdcall) is an error IMHO. Furthermore I have not examined how changes in definitions vs. declarations are handled (i.e. protypes, multiple conflicting prototypes, conflicting implementation). -- Summary: Contradicting function attributes Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus at oberhumer dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i386-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18070
[Bug c/18070] Contradicting function attributes
--- Additional Comments From markus at oberhumer dot com 2004-10-20 05:24 --- Created an attachment (id=7382) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7382action=view) Test program, and log of compilation with various gcc versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18070
[Bug c++/18071] New: -Winline does not respect -fno-default-inline
-Winline does not respect -fno-default-inline (this is split out of bug17115,
and a possible 3.3 regression).
Consider this code:
struct Foo {
int a(int r) { return r 1; }
virtual int b(int r) { return r 2; }
static int c(int r) { return r 4; }
};
int bar(int r) {
Foo f; int k = 0;
k |= f.a(r); k |= f.b(r); k |= f.a(r);
return k;
}
g++-3.3 -c -O2 -fno-default-inline -Winline test.cpp
g++-3.4 -c -O2 -fno-default-inline -Winline test.cpp
test.cpp: In function `int bar(int)':
test.cpp:6: warning: inlining failed in call to 'int Foo::a(int)': --param
max-inline-insns-single limit reached
test.cpp:13: warning: called from here
test.cpp:7: warning: inlining failed in call to 'virtual int Foo::b(int)':
--param max-inline-insns-single limit reached
test.cpp:13: warning: called from here
test.cpp:6: warning: inlining failed in call to 'int Foo::a(int)': --param
max-inline-insns-single limit reached
test.cpp:13: warning: called from here
test.cpp:6: warning: inlining failed in call to 'int Foo::a(int)': --param
max-inline-insns-single limit reached
test.cpp:13: warning: called from here
test.cpp:7: warning: inlining failed in call to 'virtual int Foo::b(int)':
--param max-inline-insns-single limit reached
test.cpp:13: warning: called from here
test.cpp:6: warning: inlining failed in call to 'int Foo::a(int)': --param
max-inline-insns-single limit reached
test.cpp:13: warning: called from here
Futhermore, the warnings disappear if you use -O3 instead of -O2, so -O3 seems
to silently override -fno-default-inline (at least a documentation bug).
Full test program and log file will follow as attachment.
--
Summary: -Winline does not respect -fno-default-inline
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug c++/18071] -Winline does not respect -fno-default-inline
--- Additional Comments From markus at oberhumer dot com 2004-10-20 05:49 --- Created an attachment (id=7383) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7383action=view) Test program, and log of compilation with various gcc versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug c++/17115] [3.3 Regression] -Winline does not respect __attribute__((__noinline__))
--- Additional Comments From markus at oberhumer dot com 2004-10-20 05:55 --- Mayn thanks for the fix. May I also draw your attention to bug18071 (-Winline does not respect -fno-default-inline), and I'd also appreciate comments on bug18070 (Contradicting function attributes). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17115
