Bug 64133 - m68k-rtems-gcc generates invalid code.
Summary: m68k-rtems-gcc generates invalid code.
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.9.2
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-01 03:34 UTC by Chris Johns
Modified: 2014-12-01 04:08 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Preprocessed source (21.99 KB, text/plain)
2014-12-01 03:34 UTC, Chris Johns
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Johns 2014-12-01 03:34:17 UTC
Created attachment 34151 [details]
Preprocessed source

The preprocessed output attached generates invalid code for the -O2 optimisation level and RTEMS fails to boot. The generated code is:

       clr.l 0.w
       trap #7

The full .s file can be seen in the attachments of RTEMS ticket https://devel.rtems.org/ticket/2204.

Moving the second nested block of code that copies the vector table out of the file results in correct code. Also selecting -O seems to work.
Comment 1 Andrew Pinski 2014-12-01 03:35:59 UTC
You need -fno-delete-null-pointer-checks since you are accessing NULL pointers through out the code.
Comment 2 Chris Johns 2014-12-01 04:03:16 UTC
Thanks for the quick response. The clean trap instruction did confuse me.

I suppose my work around to move the code into another file stops gcc detecting the access. Is this true ?

I am happy to build our code with the check enabled because accessing 0 is something we trap for with MMU targets such as ARM and PowerPC.
Comment 3 Andrew Pinski 2014-12-01 04:08:45 UTC
(In reply to Chris Johns from comment #2)
> Thanks for the quick response. The clean trap instruction did confuse me.
> 
> I suppose my work around to move the code into another file stops gcc
> detecting the access. Is this true ?
> 
> I am happy to build our code with the check enabled because accessing 0 is
> something we trap for with MMU targets such as ARM and PowerPC.

It looks like it is just the startup code in the Init5235 function which needs this extra option, you can use the #pragma's too.
Code like:
        *((short *)(0x00000000)) = 0;

Will produce the trap.