[Bug inline-asm/94552] New: issue with branch offset calculation by m68k-linux-gnu-as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94552 Bug ID: 94552 Summary: issue with branch offset calculation by m68k-linux-gnu-as Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: i...@abp-labs.com Target Milestone: --- Created attachment 48254 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48254&action=edit asm source to reproduce the assembler error. command : m68k-linux-gnu-as -o bug-as.o -m68000 bug-as.s when using bra, code is generated correctly : : 0: 2648moveal %a0,%a3 2: 6000 0002 braw 6 0006 : 6: 224bmoveal %a3,%a1 8: 60fcbras 6 When using bra.s instead of bra (or bra.w), wrong error message: bug-as.s: Messages de l'assembleur: bug-as.s:16: Erreur: décalage d'octets de branchement invalide as version : Version de l'assembleur GNU 2.30 (m68k-linux-gnu) utilisant la version BFD (GNU Binutils for Ubuntu) 2.30 Used with GNU/Linux Mint 19.3
[Bug inline-asm/94552] issue with branch offset calculation by m68k-linux-gnu-as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94552 Jean-Michel changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jean-Michel --- Wrong bug report! Code is OK with bra.w (6000 0002) Code can not be generated with bra.s (6000) since is causes an address trap error.
[Bug c/95429] New: Wrong code generated for -Os with target m68k on Ubuntu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95429 Bug ID: 95429 Summary: Wrong code generated for -Os with target m68k on Ubuntu Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: i...@abp-labs.com Target Milestone: --- Created attachment 48638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48638&action=edit C source file compiled with -E option. Hello, I am using m68k-linux-gnu-gcc to compile code for my homebrew computer. With the version gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04), the assembly for the following code is correct: RTC_Msg1.nbBytes = 9; RTC_buffer[0] = 8; RTC_buffer[1] = RTC_buffer[5] = (uint8_t)(year_bcd >> 24); RTC_buffer[2] = RTC_buffer[6] = (uint8_t)(year_bcd >> 16); RTC_buffer[3] = RTC_buffer[7] = (uint8_t)(year_bcd >> 8); RTC_buffer[4] = RTC_buffer[8] = (uint8_t)(year_bcd); gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 157c 0009 0001 moveb #9,%a2@(1) 1f7c 0008 0012 moveb #8,%sp@(18) 2002movel %d2,%d0 4240clrw %d0 4840swap %d0 e048lsrw #8,%d0 1f40 0017 moveb %d0,%sp@(23) 1f40 0013 moveb %d0,%sp@(19) 2002movel %d2,%d0 4240clrw %d0 4840swap %d0 1f40 0018 moveb %d0,%sp@(24) 1f40 0014 moveb %d0,%sp@(20) 2002movel %d2,%d0 e088lsrl #8,%d0 1f40 0019 moveb %d0,%sp@(25) 1f40 0015 moveb %d0,%sp@(21) 1f42 001a moveb %d2,%sp@(26) 1f42 0016 moveb %d2,%sp@(22) With the version 9.3.0 provided in Ubuntu 20.04 packages, the following code is generated and there is an illegal address trap during execution (write a long at an odd address in the stack): gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu1) 157c 0009 0001 moveb #9,%a2@(1) 1f7c 0008 001c moveb #8,%sp@(28) 2f42 001d movel %d2,%sp@(29) /* long on odd address! */ 2f42 0021 movel %d2,%sp@(33) /* long on odd address! */ Options are: -MMD -Os -m68000 -Wall -mpcrel -fdata-sections -ffunction-sections -fomit-frame-pointer -fno-builtin -fno-ident -Iarch/m68k/include If I use -O0 instead of -Os, the assembly is OK: 13fc 0009 0006 moveb #9,639fb 39fb 1ebc 0008 moveb #8,%sp@ 202f 000a movel %sp@(10),%d0 4240clrw %d0 4840swap %d0 e048lsrw #8,%d0 2000movel %d0,%d0 1f40 0005 moveb %d0,%sp@(5) 102f 0005 moveb %sp@(5),%d0 1f40 0001 moveb %d0,%sp@(1) 202f 000a movel %sp@(10),%d0 4240clrw %d0 4840swap %d0 2000movel %d0,%d0 1f40 0006 moveb %d0,%sp@(6) 102f 0006 moveb %sp@(6),%d0 1f40 0002 moveb %d0,%sp@(2) 202f 000a movel %sp@(10),%d0 e088lsrl #8,%d0 2000movel %d0,%d0 1f40 0007 moveb %d0,%sp@(7) 102f 0007 moveb %sp@(7),%d0 1f40 0003 moveb %d0,%sp@(3) 202f 000a movel %sp@(10),%d0 1f40 0008 moveb %d0,%sp@(8) 102f 0008 moveb %sp@(8),%d0 1f40 0004 moveb %d0,%sp@(4) Attached the C source file compiled with -E option. Thanks in advance for the support!
[Bug c/92395] New: m68k-linux-gnu-gcc generates wrong code when the -mshort option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92395
Bug ID: 92395
Summary: m68k-linux-gnu-gcc generates wrong code when the
-mshort option is used
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i...@abp-labs.com
Target Milestone: ---
Created attachment 47189
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47189&action=edit
C source file
The option -mshort makes GCC m68k to use int size = 16-bit instead of 32-bit.
But the pointers are also affected by this option and the asm code generated is
buggy. Compiling the following test case gives:
file a.c
void f(char *begin, char *end)
{
do
{
*end-- = 0;
}
while (end > begin);
}
m68k-linux-gnu-gcc -S -O2 -fomit-frame-pointer a.c -o -
.file "a.c"
.text
.align 2
.globl f
.type f, @function
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
.size f, .-f
.ident "GCC: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0"
.section.note.GNU-stack,"",@progbits
m68k-linux-gnu-gcc -mshort -S -O2 -fomit-frame-pointer a.c -o -
.file "a.c"
.text
.align 2
.globl f
.type f, @function
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 // Wrong code!
cmp.l %d1,%d0
jhi .L2
rts
.size f, .-f
.ident "GCC: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0"
.section.note.GNU-stack,"",@progbits
Another example with itoa function attached:
m68k-linux-gnu-gcc -c itoa.c -Os -m68000 -Wall -mshort -fdata-sections
-ffunction-sections -fomit-frame-pointer -fno-builtin -fno-ident -S -o -
.file "itoa.c"
.text
.section.text.itoa,"ax",@progbits
.align 2
.globl itoa
.type itoa, @function
itoa:
movem.l #14384,-(%sp)
move.w 24(%sp),%d0
move.l 26(%sp),%a0
move.w 30(%sp),%d1
move.w %d1,%d2
subq.w #2,%d2
cmp.w #14,%d2
jhi .L9
cmp.w #10,%d1
jne .L10
move.w %d0,%d3
jge .L4
neg.w %d3
.L4:
move.w %d0,%d2
move.w %d3,%d0
.L3:
move.l %a0,%a2
moveq #0,%d3 // moveq #-1,%d3 -> 32-bit OK
not.w %d3// remove this instruction
lea digits.1019,%a3
.L5:
ext.l %d0
divs.w %d1,%d0
move.l %d0,%d4
swap %d4
lea (1,%a2),%a1
move.b (%a3,%d4.w),(%a1,%d3.l)
tst.w %d0
jne .L11
tst.w %d2
jge .L6
lea (2,%a2),%a1
move.b #45,1(%a2)
.L6:
lea (-1,%a1),%a2
move.l %a0,%a3
moveq #0,%d0 // moveq #-1,%d0 -> 32-bit OK
not.w %d0// remove this instruction
.L7:
cmp.l %a2,%a3
jcs .L8
.L2:
clr.b (%a1)
move.l %a0,%d0
movem.l (%sp)+,#3100
rts
.L10:
clr.w %d2
jra .L3
.L11:
move.l %a1,%a2
jra .L5
.L8:
move.b (%a2),%d1
move.b (%a3)+,(%a2)
move.b %d1,(%a3,%d0.l)
add.l #65535,%a2// add.l #-1,%a2 -> 32-bit OK
jra .L7
.L9:
move.l %a0,%a1
jra .L2
.size itoa, .-itoa
.section.rodata.digits.1019,"a",@progbits
.type digits.1019, @object
.size digits.1019, 17
digits.1019:
.string "0123456789abcdef"
.section.note.GNU-stack,"",@progbits
[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 Jean-Michel changed: What|Removed |Added Component|target |c --- Comment #7 from Jean-Michel --- (In reply to Richard Biener from comment #6) > It doesn't support it because it changes the ABI. [these kind of options > shouldn't exist in the first place...] > > Leaving open to make m68k-linux eventually ignore the option. Good idea! If the compiler can generate an error and stop or at least a warning and ignore the option so the code is not corrupted, that would be perfect!
