[Bug target/112413] Wrong switch jump table offset
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.
[Bug target/112413] Wrong switch jump table offset
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 it's a gcc bug.
With the testcase I initially provided, by chance it's the favourable case.
But if I artificially add a misalignment with a nop, for example, the wrong
result appears:
$ cat swi2.c
int g;
void f(int i)
{
asm("nop");
switch (i)
{
case 0: g = 6082; break;
case 1: g = 9332; break;
case 2: g = 5642; break;
case 3: g = 1423; break;
case 4: g = 2152; break;
case 5: g = 6779; break;
case 6: g = 7074; break;
case 7: g = 8280; break;
}
}
$ m68k-linux-gcc -Os -c swi2.c -mlong-jump-table-offsets -malign-int
$ m68k-linux-objdump -d swi2.o
swi2.o:file format elf32-m68k
Disassembly of section .text:
:
0: 202f 0004 movel %sp@(4),%d0
4: 4e71nop
6: 7207moveq #7,%d1
8: b280cmpl %d0,%d1
a: 6536bcss 42
c: e588lsll #2,%d0
e: 203b 0808 movel %pc@(18 ,%d0:l),%d0 |right offset
12: 4efb 0802 jmp %pc@(16 ,%d0:l) |wrong offset
16: 284cmoveal %a4,%a4 |harmful filler
18: 0020 orib #32,%d0
1c: 002c orib #44,%d0
20: 0038 orib #56,%d0
See that:
- actual jump table starts at offset 0x18
- at offset 0x16, a useless "moveal %a4,%a4" instruction is inserted as filler
- at offset 0xe, offset 0x18 is used appropriately for label .L4. So the right
jump table entry is properly read.
- but at offset 0x12, a *wrong* offset 0x16 is used for the jump. That's
actually the offset of the filler, while it should be 0x18 for label .L4.
This can't work:
- the jump table offsets are computed from the start of the jump table
- but jmp, with that "2" hardcoded as offset, expects offsets being relative to
the address right after itself.
So if a filler is inserted between jmp and actual table contents, as in the
example above, the jump occurs to a wrong address.
[Bug target/112413] Wrong switch jump table offset
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:w) Offset 2 is hardcoded in the macro. Ideally, it should be replaced with the label of the first jump table entry. But I guess it isn't possible inside that macro. A solution is to force ADDR_VEC_ALIGN to 0, in order to completely disable the jump table alignment. That's consistent with ASM_RETURN_CASE_JUMP expectations. #define ADDR_VEC_ALIGN(ADDR_VEC) 0 This should be done for all m68k targets.
[Bug c/112413] New: Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
Bug ID: 112413
Summary: Wrong switch jump table offset
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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)
{
switch (i)
{
case 0: g = 6082; break;
case 1: g = 9332; break;
case 2: g = 5642; break;
case 3: g = 1423; break;
case 4: g = 2152; break;
case 5: g = 6779; break;
case 6: g = 7074; break;
case 7: g = 8280; break;
}
}
$ m68k-linux-gcc -Os -S -o - swi.c -mlong-jump-table-offsets -malign-int
#NO_APP
.file "swi.c"
.text
.align 2
.globl f
.type f, @function
f:
move.l 4(%sp),%d0
moveq #7,%d1
cmp.l %d0,%d1
jcs .L1
lsl.l #2,%d0
move.l .L4(%pc,%d0.l),%d0
jmp %pc@(2,%d0:l)
.balignw 4,0x284c |Potential bug here
.L4:
.long .L11-.L4
.long .L10-.L4
.long .L9-.L4
.long .L8-.L4
.long .L7-.L4
.long .L6-.L4
.long .L5-.L4
.long .L3-.L4
.L11:
move.l #6082,g
.L1:
rts
.L10:
move.l #9332,g
jra .L1
...
As the jmp may not be aligned on a multiple of 4, the .balignw directive may
introduce a 2-byte filler, causing jmp to use a wrong offset.
Same happens with m68k-elf-gcc.
[Bug c++/111279] New: ICE: Segmentation fault with m68k,SJLJ and -malign-int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
Bug ID: 111279
Summary: ICE: Segmentation fault with m68k,SJLJ and -malign-int
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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 with
-malign-int.
$ cat >bug.cc <
struct A
{
A()
{ }
char buf[4];
};
template
struct B : public A
{
B()
{ }
};
template
struct C : public B
{
C() throw()
{ }
};
void f()
{
C tmp;
}
EOF
gcc was configured with:
~/sources/gcc/configure --target=m68k-elf --disable-nls --disable-multilib
--enable-languages="c,c++" --disable-libstdc++-pch --disable-lto
--enable-sjlj-exceptions
$ /home/vincent/compil/gccelfsjlj.obj/gcc/cc1plus bug.cc -malign-int
A::A() B::B() C::C() void f() C B A C::C() [with
T = char] C::C() [with T = char] C::C() [with T = char] B::B() [with T
= char] B::B() [with T = char] B::B() [with T = char] A::A() [with T =
char] A::A() [with T = char] A::A() [with T = char]
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1068k} {heap 1068k}
{heap 1068k} {heap 1348k} {heap 1348k}
{heap 1348k} {heap 1348k}Streaming LTO
{heap 1348k} {heap 1348k} {heap 1348k}
{heap 1348k} {heap 1348k} {heap 1348k}
{heap 1348k}Assembling functions:
void f() C::C() [with T = char]during RTL pass: expand
bug.cc: In constructor 'C::C() [with T = char]':
bug.cc:21:5: internal compiler error: Segmentation fault
21 | { }
| ^
0x1174ec3 crash_signal
/home/vincent/sources/gcc/gcc/toplev.cc:314
0x7f7ca4a3c4af ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xe08653 assign_temp(tree_node*, int, int)
/home/vincent/sources/gcc/gcc/function.cc:976
0xdab01f emit_push_insn(rtx_def*, machine_mode, tree_node*, rtx_def*, unsigned
int, int, rtx_def*, poly_int<1u, long>, rtx_def*, rtx_def*, int, rtx_def*,
bool)
/home/vincent/sources/gcc/gcc/expr.cc:4920
0xc5f915 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
/home/vincent/sources/gcc/gcc/calls.cc:4585
0xd765bf emit_library_call(rtx_def*, libcall_type, machine_mode, rtx_def*,
machine_mode)
/home/vincent/sources/gcc/gcc/rtl.h:4343
0xd765bf sjlj_emit_function_enter
/home/vincent/sources/gcc/gcc/except.cc:1212
0xd7b90d sjlj_build_landing_pads
/home/vincent/sources/gcc/gcc/except.cc:1491
0xd7b90d finish_eh_generation()
/home/vincent/sources/gcc/gcc/except.cc:1520
0xc7c1a6 execute
/home/vincent/sources/gcc/gcc/cfgexpand.cc:6940
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ /home/vincent/compil/gccelfsjlj.obj/gcc/cc1plus bug.cc -malign-int
A::A() B::B() C::C() void f() C B A C::C() [with
T = char] C::C() [with T = char] C::C() [with T = char] B::B() [with T
= char] B::B() [with T = char] B::B() [with T = char] A::A() [with T =
char] A::A() [with T = char] A::A() [with T = char]
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1068k} {heap 1068k}
{heap 1068k} {heap 1348k} {heap 1348k}
{heap 1348k} {heap 1348k}Streaming LTO
{heap 1348k} {heap 1348k} {heap 1348k}
{heap 1348k} {heap 1348k} {heap 1348k}
{heap 1348k}Assembling functions:
void f() C::C() [with T = char]during RTL pass: expand
bug.cc: In constructor 'C::C() [with T = char]':
bug.cc:21:5: internal compiler error: Segmentation fault
21 | { }
| ^
0x1174ec3 crash_signal
/home/vincent/sources/gcc/gcc/toplev.cc:314
0x7f7ca4a3c4af ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xe08653 assign_temp(tree_node*, int, int)
/home/vincent/sources/gcc/gcc/function.cc:976
0xdab01f emit_push_insn(rtx_def*, machine_mode, tree_node*, rtx_def*, unsigned
int, int, rtx_def*, poly_int<1u, long>, rtx_def*, rtx_def*, int, rtx_def*,
bool)
/home/vincent/sources/gcc/gcc/expr.cc:4920
0xc5f915 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
/home/vincent/sources/gcc/gcc/calls.cc:4585
0xd765bf emit_library_call(rtx_def*, libcall_type, machine_mode, rtx_def*,
machine_mode)
/home/vincent/sources/gcc/gcc/rtl.h:4343
0xd765bf sjlj_emit_function_enter
/home/vincent/sources/gcc/gcc/except.cc:1212
0xd7b90d sjlj_build_landing_pads
/home/vincent/sources/gcc/gcc/except.cc:1491
0xd7b90d finish_eh_generation()
/home/vincent/sources/gcc/gcc/except.cc:152
[Bug target/88160] Error: register save offset not a multiple of 4 only with optimize
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=edit
Workaround for compiling libgcc with -mcpu=5475 -mshort
Here is a patch for GCC 13.1.0. It allows libgcc to be compiled with -mcpu=5475
-mshort. As a workaround, it uses -fno-combine-stack-adjustments on the
impacted functions.
__attribute__((optimize("-fno-combine-stack-adjustments")))
Of course, it would be much better to fix the root of the issue.
[Bug target/88160] Error: register save offset not a multiple of 4 only with optimize
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/ccW6hc6h.s:20: Error: register save offset not a multiple of 4 /tmp/ccW6hc6h.s:21: Error: register save offset not a multiple of 4 /tmp/ccW6hc6h.s:22: Error: register save offset not a multiple of 4 $ m68k-elf-gcc -mshort -mcpu=5475 -g -O2 -c test.c -fno-combine-stack-adjustments # OK $ m68k-elf-gcc -mshort -mcpu=5475 -g -O2 -c test.c -fno-omit-frame-pointer # OK
[Bug target/88160] Error: register save offset not a multiple of 4 only with optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160 Vincent Riviere changed: What|Removed |Added CC||vincent.riviere at freesbee dot fr --- Comment #2 from Vincent Riviere --- I reproduce this bug with GCC 13.1.0 for m68k. It happens when compiling libgcc with -mcpu=5475 -mshort -O2. Affected files are: unwind-dw2.c unwind-dw2-fde.c libgcov-driver.c Workaround: compile with -O1.
[Bug c/110567] New: GCC fails using a register to initialize multiple variables with a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110567
Bug ID: 110567
Summary: GCC fails using a register to initialize multiple
variables with a constant
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: 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 initialize several global variables with the
same constant value.
$ cat foo.c
extern long init;
extern long g1, g2, g3, g4, g5;
void f(void)
{
long val = 12345678;
g1 = val;
g2 = val;
g3 = val;
g4 = val;
g5 = val;
}
$ m68k-elf-gcc -S foo.c -o - -Os
#NO_APP
.file "foo.c"
.text
.align 2
.globl f
.type f, @function
f:
move.l #12345678,g1
move.l #12345678,g2
move.l #12345678,g3
move.l #12345678,g4
move.l #12345678,g5
rts
.size f, .-f
.ident "GCC: (GNU) 13.1.0"
We can see that 12345678 is used many times. This is a waste of space and time.
On the other hand, if I replace 12345678 by "init" (an external global
variable) then GCC produces the expected optimized output:
$ m68k-elf-gcc -S foo.c -o - -Os
#NO_APP
.file "foo.c"
.text
.align 2
.globl f
.type f, @function
f:
move.l init,%d0
move.l %d0,g1
move.l %d0,g2
move.l %d0,g3
move.l %d0,g4
move.l %d0,g5
rts
.size f, .-f
.ident "GCC: (GNU) 13.1.0"
GCC should be able to optimize a constant initializer, just as it does with a
variable initializer.
I can reproduce the same wrong behaviour with GCC 11.4.0 for x86_64-pc-cygwin
host with -m32:
$ gcc -m32 -S foo.c -o - -Os
.file "foo.c"
.text
.globl _f
.def_f; .scl2; .type 32; .endef
_f:
movl$12345678, _g1
movl$12345678, _g2
movl$12345678, _g3
movl$12345678, _g4
movl$12345678, _g5
ret
.ident "GCC: (GNU) 11.4.0"
[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768
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.
[Bug c/106349] New: strlen reimplementation produces infinite loop with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106349
Bug ID: 106349
Summary: strlen reimplementation produces infinite loop with
-Os
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
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
size_t strlen(const char *str)
{
size_t n;
for (n = 0; *str++; n++);
return n;
}
$ m68k-elf-gcc -S bug.c -o - -Os
#NO_APP
.file "bug.c"
.text
.align 2
.globl strlen
.type strlen, @function
strlen:
jra strlen
.size strlen, .-strlen
.ident "GCC: (GNU) 12.1.0"
The only generated code is the infinite loop. That's a nonsense.
This issue doesn't occur with -O2.
[Bug c/94815] Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815
Vincent Riviere changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED|REOPENED
--- Comment #4 from Vincent Riviere ---
Thanks for your explanations.
But apologies, I oversimplified my real-world testcase. The one below is more
realistic, and still triggers the warning with -O2
$ cat foo.c && m68k-elf-gcc -c foo.c -Wall -O2
char *strcpy(char *, const char *);
int sprintf(char *, const char *, ...);
char* myalloc(int n) __attribute__((alloc_size(1)));
void f(void)
{
char* buf = myalloc(30);
char* str1 = buf;
char* str2 = buf + 10;
char* str3 = buf + 20;
strcpy(str3, "123");
sprintf(str2, "ABC%s", str3);
sprintf(str1, "DEF%s", str2);
}
foo.c: In function 'f':
foo.c:15:5: warning: 'sprintf' argument 3 may overlap destination object 'buf'
[-Wrestrict]
15 | sprintf(str1, "DEF%s", str2);
| ^~~~
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
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 Status|RESOLVED|REOPENED Resolution|WONTFIX |---
[Bug middle-end/93517] bogus -Wrestrict on sprintf with unknown strings bounded by array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93517 Vincent Riviere changed: What|Removed |Added CC||vincent.riviere at freesbee dot fr --- Comment #1 from Vincent Riviere --- Bug #94815 is similar to this one.
[Bug c/94815] New: Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815
Bug ID: 94815
Summary: Abusive -Wrestrict warning with sprintf
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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* myalloc(int n);
void f(void)
{
char* buf = myalloc(20);
char* str1 = buf;
char* str2 = buf + 10;
strcpy(str2, "123");
sprintf(str1, "ABC%s", str2);
}
foo.c: In function 'f':
foo.c:13:5: warning: 'sprintf' argument 3 may overlap destination object 'buf'
[-Wrestrict]
13 | sprintf(str1, "ABC%s", str2);
| ^~~~
This warning is a unexpected because:
1) strcpy() and sprintf() are declared without __restrict, but __restrict rules
are still actually used.
2) In this simple example, it is obvious that the buffer will not overflow.
This is annoying, because it prevents creating several logical buffers from a
single allocation.
[Bug c/92395] m68k-linux-gnu-gcc generates wrong code when the -mshort option is used
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 generating wrong code. That would avoid a lot of questions and headaches.
[Bug c/92395] m68k-linux-gnu-gcc generates wrong code when the -mshort option is used
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 "unsigned int" 233 234 #undef PTRDIFF_TYPE 235 #define PTRDIFF_TYPE "int" The Linux target uses "unsigned int" as size type. This is obviously wrong when -mshort is used. On the other hand, the standard m68k-elf-gcc works fine.
[Bug c/92395] m68k-linux-gnu-gcc generates wrong code when the -mshort option is used
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. Save it as a.c.
I use the official Ubuntu 19.10 Eoan Ermine.
m68k-linux-gnu-gcc --version
m68k-linux-gnu-gcc (Ubuntu 9.2.1-9ubuntu1) 9.2.1 20191008
m68k-linux-gnu-gcc -S -O2 -fomit-frame-pointer a.c -o -
f:
move.l 4(%sp),%d0
move.l 8(%sp),%a0
.L2:
clr.b (%a0)
subq.l #1,%a0
cmp.l %d0,%a0
jhi .L2
rts
That's fine.
Now the same but with -mshort:
m68k-linux-gnu-gcc -mshort -S -O2 -fomit-frame-pointer a.c -o -
f:
move.l 4(%sp),%d1
move.l 8(%sp),%a0
.L2:
clr.b (%a0)
move.l %a0,%d0
subq.l #1,%d0
add.l #65535,%a0 // Madness
cmp.l %d1,%d0
jhi .L2
rts
The latter is wrong.
[Bug lto/70415] New: -Wa options should be passed to LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70415
Bug ID: 70415
Summary: -Wa options should be passed to LTO
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
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.
Concretely, LTO fails if inline assembly requires gas
--register-prefix-optional option.
Testcase:
$ cat bug.c
void _start(void)
{
asm("clr.l d0"); /* Note the absence of % in front of d0 */
}
$ m68k-elf-gcc -nostartfiles -nodefaultlibs -Wa,--register-prefix-optional
bug.c -o bug
# This works
$ m68k-elf-gcc -nostartfiles -nodefaultlibs -Wa,--register-prefix-optional
bug.c -o bug -flto
/tmp/ccQVzOtj.ltrans0.ltrans.o: In function `_start':
:(.text+0x6): undefined reference to `d0'
collect2: error: ld returned 1 exit status
If we add -v on the command line, we can see that --register-prefix-optional is
not passed to "as" when for the LTO pass. While it should.
[Bug c/59946] -mpcrel -O2 produces illegal asm code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59946 Vincent Riviere vincent.riviere at freesbee dot fr changed: What|Removed |Added CC||vincent.riviere at freesbee dot fr --- Comment #1 from Vincent Riviere vincent.riviere at freesbee dot fr --- Confirmed with the following compilers: m68k-atari-mint-gcc 4.7.1 m68k-atari-mint-gcc 4.6.4 m68k-elf-gcc 4.5.2
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #18 from Vincent Riviere vincent.riviere at freesbee dot fr 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.
[Bug target/47672] math-68881.h does not support C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47672 --- Comment #4 from Vincent Riviere vincent.riviere at freesbee dot fr 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 required, a user can compile his program with -ffast-math. As a result, any call to sin() will be implemented by a single fsin instruction rather than a call to libm. The purpose is the same as math-68881.h. But the implementation is different: math-68881.h relies on the preprocessor, while -ffast-math is directly handled by GCC at low level for better register usage, etc. This is why ideally math-68881.h should be removed from GCC and -ffast-math always used by the users, when needed. However, someone reported that all the functionnality of math-68881.h was not reported to -ffast-math: some instructions are missing. So I propose the following roadmap: 1) Commit my proposed patch, then close this bug. This will fix the current math-68881.h for C99. I hit that problem when compiling libtiff. 2) Move the missing functionnality from math-68881.h to -ffast-math, then remove math-68881.h from GCC.
[Bug target/47672] math-68881.h does not support C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47672 --- Comment #6 from Vincent Riviere vincent.riviere at freesbee dot fr 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
[Bug target/48554] Regression for coldfire platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48554 Vincent Riviere vincent.riviere at freesbee dot fr changed: What|Removed |Added CC||vincent.riviere at freesbee ||dot fr --- Comment #2 from Vincent Riviere vincent.riviere at freesbee dot fr 2011-05-15 21:11:48 UTC --- This bug looks similar to PR 47612.
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #17 from Vincent Riviere vincent.riviere at freesbee dot fr 2011-05-04 23:59:00 UTC --- For me the bug seems to be fixed.
[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550 --- Comment #12 from Vincent Riviere vincent.riviere at freesbee dot fr 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 this small testcase. I think it is the same as the bug described here. $ gcc -c bug.c -Os -Wuninitialized bug.c: In function 'f': bug.c:9: warning: 'b' may be used uninitialized in this function This happens with: - GCC 4.4.5 (Debian 4.4.5-8) for the target i486-linux-gnu - GCC 4.5.2 for the target m68k-atari-mint
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #8 from Vincent Riviere vincent.riviere at freesbee dot fr 2011-04-06 17:07:26 UTC --- Excellent! Your patch fixes both testcases here.
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #6 from Vincent Riviere vincent.riviere at freesbee dot fr 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 fails with ICE when compiled using: gcc -c bug.c -mcpu=5475 -O2
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 Vincent Riviere vincent.riviere at freesbee dot fr changed: What|Removed |Added CC||vincent.riviere at freesbee ||dot fr --- Comment #5 from Vincent Riviere vincent.riviere at freesbee dot fr 2011-03-26 15:02:11 UTC --- I confirm I have also hit this bug on GCC 4.6.0 release for the unofficial m68k-atari-mint target with only -mcpu=5475 -O2 on a rather big and complicated file.
[Bug c/47672] New: math-68881.h does not support C99
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.org ReportedBy: vincent.rivi...@freesbee.fr Target: m68k-* The file gcc/config/m68k/math-68881.h is distributed with GCC, however it does not support C99. When this file is included in multiple files, then compiled with --std=c99 or --std=gnu99 this leads to duplicate definitions. This is because it uses extern inline unconditionally.
[Bug c/47672] math-68881.h does not support C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47672 --- Comment #1 from Vincent Riviere vincent.riviere at freesbee dot fr 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.
