Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
Target: m68k-elf
Testcase:
$ cat foo.c && m68k-elf-gcc -c foo.c -Wall -O
char *strcpy(char *, const char *);
int sprintf(char *, const char *, ...);
char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93517
Vincent Riviere changed:
What|Removed |Added
CC||vincent.riviere at freesbee
dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 94815, which changed state.
Bug 94815 Summary: Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815
Vincent Riviere changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92395
--- Comment #1 from Vincent Riviere ---
Simplified testcase :
void f(char *begin, char *end)
{
do
{
*end-- = 0;
}
while (end > begin);
}
Note that that the above code only manipulate pointers. No int type is
involved. Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92395
--- Comment #2 from Vincent Riviere ---
Cause is in gcc/config/m68k/linux.h:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/linux.h;h=ebdf02810711a28232041d3e73350c7bdcc7b509;hb=HEAD#l231
231 #undef SIZE_TYPE
232 #define SIZE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92395
--- Comment #4 from Vincent Riviere ---
(In reply to Andreas Schwab from comment #3)
> The m68k-linux target does not support -mshort.
In that case I suggest that GCC should cleanly display an error message when
-mshort is used instead of genera
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47672
Summary: math-68881.h does not support C99
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47672
--- Comment #1 from Vincent Riviere
2011-02-09 23:27:51 UTC ---
Created attachment 23291
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23291
Fix for math-68881.h and C99
This patch fixes the problem.
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
Target: m68k-elf
Basically, options specified with -Wa should be used in final LTO step.
Currently, they are not passed to LTO, this can break inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59946
Vincent Riviere changed:
What|Removed |Added
CC||vincent.riviere at freesbee
dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
Vincent Riviere changed:
What|Removed |Added
CC||vincent.riviere at freesbee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
--- Comment #6 from Vincent Riviere
2011-04-02 12:13:57 UTC ---
Created attachment 23850
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23850
Testcase
Here is my simplified testcase. It looks weird, but I didn't manage to simplify
more. It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
--- Comment #8 from Vincent Riviere
2011-04-06 17:07:26 UTC ---
Excellent! Your patch fixes both testcases here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550
--- Comment #12 from Vincent Riviere
2011-04-17 22:17:35 UTC ---
Created attachment 24023
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24023
Very simple testcase
I hit the "may be used uninitialized in this function" bug when compiling th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
--- Comment #17 from Vincent Riviere
2011-05-04 23:59:00 UTC ---
For me the bug seems to be fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48554
Vincent Riviere changed:
What|Removed |Added
CC||vincent.riviere at freesbee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47672
--- Comment #4 from Vincent Riviere
2011-06-06 19:06:07 UTC ---
Normal math implementation should always reside inside libm, to fully support
exceptions, error handling, etc.
When better speed is required, and strict standard compliance is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47672
--- Comment #6 from Vincent Riviere
2011-06-06 21:20:46 UTC ---
> What specific instructions are missing from -ffast-math?
I don't know myself, but I have been told it was the case.
http://gcc.gnu.org/ml/gcc/2011-02/msg00186.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
--- Comment #18 from Vincent Riviere
2011-08-02 07:30:06 UTC ---
I have applied your patch to GCC 4.6.1 and it worked fine on all the software
I'm used to compile. You should apply it to the 4.6 branch.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
Target: m68k-elf
Compiling a function named strlen with strlen-like body generates an infinite
loop.
$ cat bug.c
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160
Vincent Riviere changed:
What|Removed |Added
CC||vincent.riviere at freesbee
dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160
--- Comment #3 from Vincent Riviere ---
There are 2 lightweight workarounds for the OP testcase:
-fno-combine-stack-adjustments
-fno-omit-frame-pointer
$ m68k-elf-gcc -mshort -mcpu=5475 -g -O2 -c test.c
/tmp/ccW6hc6h.s: Assembler messages:
/tmp/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160
--- Comment #4 from Vincent Riviere ---
Created attachment 55647
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55647&action=edit
Workaround for compiling libgcc with -mcpu=5475 -mshort
Here is a patch for GCC 13.1.0. It allows libgcc to b
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
m68k-elf-g++ causes "internal compiler error: Segmentation fault" when
configured for m68k-elf, SJLJ exceptions, and compiling a specific program wi
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
In some circumstances, gcc produces bad code for switch instruction.
Main goal of the testcase is to force gcc to produce a jump table.
$ cat swi.c
int g;
void f(int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #2 from Vincent Riviere ---
Cause is in gcc/config/m68k/linux.h, macro ASM_RETURN_CASE_JUMP:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/linux.h;h=2e1cb5498b86f053d1e9b7c530648dfa186ca4c4;hb=HEAD#l96
jmp %%pc@(2,%0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #3 from Vincent Riviere ---
(In reply to Andrew Pinski from comment #1)
> I don't see any issues with the output of gcc. Are you sure this is not a
> binutils gnu as issue where the offsets are done incorrectly there.
Yes, I'm sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #6 from Vincent Riviere ---
(In reply to Mikael Pettersson from comment #4)
> Does the `.balignw` filler disappear if you drop `-malign-int`?
No, it stays, but its value becomes 2, so it doesn't cause trouble.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
--- Comment #8 from Vincent Riviere ---
This still happens with m68k-elf-gcc 13.1.0.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
Target: m68k-elf
This is about a missed optimization for an obvious case.
GCC fails to use a register to
31 matches
Mail list logo
