[Bug target/53256] New: [avr] Attribute 'interrupt' shall override attribute 'signal'

["gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53256

             Bug #: 53256
           Summary: [avr] Attribute 'interrupt' shall override attribute
                    'signal'
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: gjl@gcc.gnu.org
        ReportedBy: gjl@gcc.gnu.org
                CC: j@uriah.heep.sax.de
            Target: avr


AVR-LibC offered attributes 'interrupt' and 'signal' as INTERRUPT and SIGNAL
through its API.  This changed at some point in time to ISR which may lead to
code that adds attribute 'interrupt' and attribute 'signal' at the same time.

This leads to code that is not IRQ-safe in the current implementation which is:

1) Attributes 'interrupt' and 'signal' are exclusive. Specifying both at the
same time for the same function has not a well-defined behavior.

2) 'interrupt' emits a SEI instruction as the very first instruction of the
function.

3) Neither attributes make assumptions on the function's worker code. In
particular, they do *not* assume that interrupts are not (re-)enabled by the
user code.  Thus, it is safe to enable IRQs at any place in the function body. 
This "safe" covers only the generated code and IRQ-safeness of SP changes and
the instructions themselves, it does *not* cover the IRQ and timing layout of
the application.

4) The AVR hardware globally disables IRQs when an IRQ is raised. This allows
more efficient code in 'signal' prologues compared to 'interrupt' prologues in
cases where the stack pointer has to be written.  Writing SP is not an atomic
operation on all devices, and special precautions must be taken if SP is
written and IRQs might be on.


As of this extension request 1) shall be changed to:

1') Attribute 'interrupt' shall override attribute 'signal'. No warning should
be issued in such a case.  The documentation should be extended.