[Bug c/83397] New: void f() { } has zero arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83397
Bug ID: 83397
Summary: void f() { } has zero arguments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: izaberina at gmail dot com
Target Milestone: ---
https://godbolt.org/g/8ZcWKk
according to c11 6.7.6.3, function prototypes without arguments don't specify
anything about their parameters
gcc is assuming that f1 takes an unspecified number of arguments, and as such
it's treating it as potentially vararg, and that's (probably) why it clears eax
before calling it
in my understanding, this requirement only applies to prototypes and not to
function definitions
furthermore, the function is static and gcc is definitely able to see what it
does so it's not needed either way
[Bug c/83397] void f() { } has zero arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83397
--- Comment #1 from Isabella ---
int a;
static void __attribute__((noinline)) f1() { a = 7; }
void g1(void) { f1(); }
static void __attribute__((noinline)) f2(void) { a = 7; }
void g2(void) { f2(); }
gets compiled to
f1:
movl $7, a(%rip)
ret
f2:
movl $7, a(%rip)
ret
g1:
xorl %eax, %eax
jmp f1
g2:
jmp f2
[Bug c/69616] New: optimization of 8 movb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69616
Bug ID: 69616
Summary: optimization of 8 movb
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: izaberina at gmail dot com
Target Milestone: ---
I'm on arch linux on x86_64, using gcc 5.3.0.
From this code:
char tape[65536];
void f() {
tape[0] = 0;
tape[1] = 0;
tape[2] = 0;
tape[3] = 0;
tape[4] = 0;
tape[5] = 0;
tape[6] = 0;
tape[7] = 0;
}
gcc produces 8 movb at any -O level, while clang produces 1 movq.
Why is that not being optimized?
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-5.3.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC)
[Bug c/70412] New: -Wswitch and functions that can only return a small set of values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70412
Bug ID: 70412
Summary: -Wswitch and functions that can only return a small
set of values
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: izaberina at gmail dot com
Target Milestone: ---
$ cat wswitch.c
#include
typedef enum { a, b, c, d, e } letter;
letter func (int arg) {
if (arg > 0) return a;
return b;
}
int main() {
switch(func(7)) {
case a: puts("a"); break;
case b: puts("b"); break;
}
return 0;
}
$ gcc -Wall wswitch.c
wswitch.c: In function 'main':
wswitch.c:11:3: warning: enumeration value 'c' not handled in switch [-Wswitch]
switch(func(7)) {
^
wswitch.c:11:3: warning: enumeration value 'd' not handled in switch [-Wswitch]
wswitch.c:11:3: warning: enumeration value 'e' not handled in switch [-Wswitch]
This is more of a question than a bug report: does that code need a default
case? I think it shouldn't, it handles all the possible return values...
Is that warning useful?
For the records, clang 3.7 reports a very similar warning.
[Bug c/81166] New: no need to check if the pointer you pass to free is NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81166
Bug ID: 81166
Summary: no need to check if the pointer you pass to free is
NULL
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: izaberina at gmail dot com
Target Milestone: ---
gcc -Os compiles this function
void myfree(void *mem) {
if (mem)
free(mem);
}
to
myfree(void*):
testrdi, rdi
je .L1
jmp free
.L1:
ret
why is that test not removed? free(NULL) is valid and a no op
[Bug c/71926] New: wrong -Wparentheses warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71926
Bug ID: 71926
Summary: wrong -Wparentheses warning
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: izaberina at gmail dot com
Target Milestone: ---
int main() {
int a = 1, b = 2, c = 3, d = 4;
if (a = 2 || (b != 3 &&
c != 4 && d != 5)) return 1;
return 0;
}
-Wparentheses produces the following warning:
gccfail.c:4:23: warning: suggest parentheses around assignment used as truth
value [-Wparentheses]
c != 4 && d != 5)) return 1;
^
gcc found the problem, but the warning is pretty misleading: i was about to
ignore it because it looked like a bogus warning
[Bug c++/106675] New: g++ crashes on funky operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106675 Bug ID: 106675 Summary: g++ crashes on funky operators Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: izaberina at gmail dot com Target Milestone: --- Created attachment 53472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53472&action=edit short repro Attached is a small reproducer of something that originally came from boost::system::error_code. g++ from v11 onward crashes on it: https://godbolt.org/z/nYqo1zj31
[Bug c/117909] New: gcc fails to save registers with no_caller_saved_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117909 Bug ID: 117909 Summary: gcc fails to save registers with no_caller_saved_registers Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: izaberina at gmail dot com Target Milestone: --- c version https://godbolt.org/z/z3v1W3njb c++ version https://godbolt.org/z/T3cns6rPe i need countbar to save rdi, and any registers used by __tls_get_addr somehow the definition being above or below seems to affect the result is this miscompiled or am i doing things wrong?
[Bug c++/119778] New: gcc gimple crashes on some setjmp/longjmp code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119778
Bug ID: 119778
Summary: gcc gimple crashes on some setjmp/longjmp code
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: izaberina at gmail dot com
Target Milestone: ---
Created attachment 61092
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61092&action=edit
the horrible code in question
so i wrote some horrible code: https://godbolt.org/z/v9fe1Mo98
as shown on godbolt:
- it behaves as intended with asan
- it doesn't print anything without asan
- it reliably crashes gcc with -Wall -O2 starting from gcc 13.3.0 up to at
least 14.2.0
```
during GIMPLE pass: uninit
: In member function 'void tac::f()':
:10:10: internal compiler error: Segmentation fault
10 | void f() {
| ^
```
crashing seems suboptimal, although one could argue that this code wasn't ever
supposed to work, and that crashing on it is a better result than building it
one could also argue that asan shouldn't change its behaviour this way
