[Bug target/92395] m68k-linux-gnu-gcc generates wrong code when the -mshort option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92395 Eero Tamminen changed: What|Removed |Added CC||eerott at gmail dot com --- Comment #10 from Eero Tamminen --- > I think the option should just be removed at this point. "-mshort" is still used with m68k gcc toolchain(s) that don't break it. Not to build Linux binaries, but to cross-compile things where size matters. It would be nice to be able to use (pre-built Debian) Linux m68k gcc to do such cross-compilation. Looking at https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/config/m68k;hb=HEAD "linux.h" and "netbsd-elf.h" headers use int & unsigned int for PTRDIFF & SIZE_T, which produces broken code with -mshort, whereas "openbsd.h" and "m68kemb.h" use "long int" & "long unsigned int" which work fine with and without -mshort. (I'm not sure whether I should be surprised that netbsd and openbsd work differently. :-))
[Bug middle-end/44848] Bogus "array subscript is below array bounds" with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44848 --- Comment #4 from Eero Tamminen --- (In reply to Richard Biener from comment #1) > This is the same as PR43270 (and the fix for it cures it). > > *** This bug has been marked as a duplicate of 43270 *** Current status is still NEW, but there's no comment why duplicate status was changed back to NEW. Did the fix to (already verified) bug 43270 fix also this bug (i.e. should this also be verified) or not?
[Bug c/48091] New: No warning when given function arguments mismatch earlier, old style K&R function definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48091
Summary: No warning when given function arguments mismatch
earlier, old style K&R function definition
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eer...@gmail.com
Program:
--
int test(a, b)
int a;
int b;
{
return a+b;
}
int main(void)
{
return test("foo");
}
--
With all of these compiler options:
- gcc -Wall -Wextra --std=c99 -pedantic -O test.c
The expected output is similar to other compilers i.e.:
- a warning about arguments mismatching
(As all argument types and number of them are fully specified), or
- warning about incomplete function definition
Actual outcome:
- No warnings about anything
(With -O2, GCC inlines the function and then finds a mismatch and I of course
can use -Wold-style-definition warning option, but that's beside the point.)
GCC version:
- 4.4.5 in Debian Squeeze
[Bug c/48091] No warning when given function arguments mismatch earlier, old style K&R function definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48091 --- Comment #2 from Eero Tamminen 2011-03-17 21:08:41 UTC --- (In reply to comment #1) > That's how K&R works. The function definition isn't a prototype. Why that would be a valid excuse not to give a warning when function call either doesn't match or isn't known by GCC to match what the function accepts? That makes no sense, especially when I'm requesting -Wall/-Wextra and/or pedantic C99 checking... It's dangerous behavior and makes GCC look bad compared to about any other compiler that hasn't died on previous century. User might not know that the code he's compiling happens to contain (mismatching) K&R function definitions, silently hiding such errors when user has requested stricter checking is evil. GCC should of course still accept K&R code (in case there's still K&R code that isn't dead or fixed), this bug is about giving warnings when function call doesn't match what GCC knows about the function. If somebody doesn't want warnings on K&R function definitions (which became obsolete 22 years ago), they can always specifically disable such warnings. Newer GCC being more strict and giving more warnings on the same code shouldn't come as a surprise to anybody.
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48091
Eero Tamminen changed:
What|Removed |Added
Summary|No warning when given |No warning when given
|function arguments mismatch |function arguments mismatch
|earlier, old style K&R |earlier function definition
|function definition |which GCC assumes to be K&R
--- Comment #3 from Eero Tamminen 2011-03-30 17:59:26
UTC ---
Another example about how dangerous this default GCC behavior is.
Consider code A:
--
static int a, b;
void set_a(int i) {
a = i;
}
void set_b(int i) {
b = i;
}
int add() {
return a+b;
}
--
And its usage from elsewhere:
--
#include
int main(int argc, const char *argv[] __attribute__((unused)))
{
return add(argc, 50);
}
--
GCC doesn't catch this because it assumes the code is obsolete K&R syntax
without even bothering to give user a warning about it. Even when user is
requesting warnings with options like:
gcc -Wall -Wextra --std=c99 -pedantic -O2 test.c
Code A) is *not* K&R. Nowadays it's either C++ code copied to a C program or
code from people who don't know or remember that only in C++ "add()" means void
argument whereas in ANSI-C "add(void)" should be used.
I see this in (non-K&R) C sources all the time, it's very common mistake about
which GCC doesn't bother to give any warning.
Confirmed?
[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K&R, even with --std=c99 -pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48091
Eero Tamminen changed:
What|Removed |Added
Summary|No warning when given |No warning when given
|function arguments mismatch |function arguments mismatch
|earlier function definition |earlier function definition
|which GCC assumes to be K&R |which GCC assumes to be
||K&R, even with --std=c99
||-pedantic
--- Comment #4 from Eero Tamminen 2011-06-23 19:28:45
UTC ---
(In reply to comment #0)
> Program:
> --
> int test(a, b)
> int a;
> int b;
> {
> return a+b;
> }
> int main(void)
> {
> return test("foo");
> }
> --
(In reply to comment #1)
> That's how K&R works. The function definition isn't a prototype.
Right, including an ANSI-C prototype either for:
int test(int a, int b);
or for:
int test(const char *);
Would cause there to be a warning. I would never have though somebody to mix
K&R & ANSI-C like that, but I just noticed that having K&R function
implementations in *.c files with ANSI-C prototypes in headers seems to be e.g.
how Glibc does things...
It still doesn't help with mistakes like "function() { ... }" for people who
have experience with other compilers than GCC. GCC is only compiler with this
dangerous defaulting to K&R interpretation.
[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532
Eero Tamminen changed:
What|Removed |Added
CC||eerott at gmail dot com
--- Comment #7 from Eero Tamminen ---
Timing and profiling whole EmuTOS (m68k ROM) bootup, showed these added
memcpy() calls adding 8% to the boot time [1] with GCC 13.1.
For that particular case, all those extra (2) memcpy() calls, and the
associated 8% bootup overhead, came from this loop:
---
uint32_t pair_planes[4];
...
for (i = 0; i < v_planes / 2; i++) {
*(uint32_t*)addr = pair_planes[i];
addr += sizeof(uint32_t);
}
---
And it went away when GCC -freestanding option was used.
Without that memcpy() overhead, GCC 13.1 perf was then very close to GCC 4.6
perf in that particular case (it did not help other cases where newer GCC was
slower).
Further testing with (compiler explorer) showed that when compiler was given a
better hint that the loop it replaced with memcpy() actually loops max 4 times,
those memcpy() instances went also away:
---
if (v_planes > 2*ARRAY_SIZE(pair_planes)) return;
---
How GCC deduced that above loop was large enough that it makes sense to replace
it with memcpy() overhead? From the max valid index for "pair_planes", it
should have already been clear that any large indexes get to "undefined
behavior".
[1] 1/3 of the boot time went to timeout for waiting user interaction, and 1/3
went to waiting slow disk responses, so in reality the overhead was really 3x
8%.
