public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/64133] New: m68k-rtems-gcc generates invalid code.
@ 2014-12-01  3:34 chris at contemporary dot net.au
  2014-12-01  3:36 ` [Bug other/64133] " pinskia at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: chris at contemporary dot net.au @ 2014-12-01  3:34 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133

            Bug ID: 64133
           Summary: m68k-rtems-gcc generates invalid code.
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chris at contemporary dot net.au

Created attachment 34151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34151&action=edit
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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug other/64133] m68k-rtems-gcc generates invalid code.
  2014-12-01  3:34 [Bug other/64133] New: m68k-rtems-gcc generates invalid code chris at contemporary dot net.au
@ 2014-12-01  3:36 ` pinskia at gcc dot gnu.org
  2014-12-01  4:03 ` chris at contemporary dot net.au
  2014-12-01  4:08 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2014-12-01  3:36 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You need -fno-delete-null-pointer-checks since you are accessing NULL pointers
through out the code.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug other/64133] m68k-rtems-gcc generates invalid code.
  2014-12-01  3:34 [Bug other/64133] New: m68k-rtems-gcc generates invalid code chris at contemporary dot net.au
  2014-12-01  3:36 ` [Bug other/64133] " pinskia at gcc dot gnu.org
@ 2014-12-01  4:03 ` chris at contemporary dot net.au
  2014-12-01  4:08 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: chris at contemporary dot net.au @ 2014-12-01  4:03 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133

--- Comment #2 from Chris Johns <chris at contemporary dot net.au> ---
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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug other/64133] m68k-rtems-gcc generates invalid code.
  2014-12-01  3:34 [Bug other/64133] New: m68k-rtems-gcc generates invalid code chris at contemporary dot net.au
  2014-12-01  3:36 ` [Bug other/64133] " pinskia at gcc dot gnu.org
  2014-12-01  4:03 ` chris at contemporary dot net.au
@ 2014-12-01  4:08 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2014-12-01  4:08 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-12-01  4:08 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-01  3:34 [Bug other/64133] New: m68k-rtems-gcc generates invalid code chris at contemporary dot net.au
2014-12-01  3:36 ` [Bug other/64133] " pinskia at gcc dot gnu.org
2014-12-01  4:03 ` chris at contemporary dot net.au
2014-12-01  4:08 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).