[Bug c++/64052] New: compilation error "local frame unavailable" appears for some optimization levels

[Bug c++/64052] New: compilation error "local frame unavailable" appears for some optimization levels

[eugene at hutorny dot in.ua]

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

            Bug ID: 64052
           Summary: compilation error "local frame unavailable" appears
                    for some optimization levels
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eugene at hutorny dot in.ua
              Host: Linux 2.6.32-5-686
            Target: avr

Created attachment 34097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34097&action=edit
code sample illustrating the issue

Compilation success of the attached example depend on the optimization
settings: with optimize("O0") compilation fails with error _local frame
unavailable (naked function?)_ while with optimize("Os") it succeeds.

Expected behavior -  optimization option has no effect on compilation success

avr-g++ (GCC) 4.7.2 

Command line:
avr-g++ -Wall -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields
-fno-exceptions -mmcu=atmega16 -DF_CPU=1000000UL -MMD -MP
-MF"local_frame_test.d" -MT"local_frame_test.d" -c -o "local_frame_test.o"
"local_frame_test.cpp"

[Bug target/64052] compilation error "local frame unavailable" appears for some optimization levels

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-11-24
               Host|Linux 2.6.32-5-686          |
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please check with a newer GCC version, GCC 4.7.2 is no longer maintained (try
at least GCC 4.8.3).

[Bug target/64052] compilation error "local frame unavailable" appears for some optimization levels

[eugene at hutorny dot in.ua]

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

Eugene <eugene at hutorny dot in.ua> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.7.2                       |4.8.1

--- Comment #2 from Eugene <eugene at hutorny dot in.ua> ---
As per https://packages.debian.org/unstable/devel/
avr-gcc 4.8.1 is the most recent available for debian

This issue is reproducible on 4.8.1

[Bug target/64052] compilation error "local frame unavailable" appears for some optimization levels

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gjl at gcc dot gnu.org

--- Comment #3 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
I think this PR is invalid:

Your code rets up avariable which needs a place to be stored, which is the
function frame for non-optimized code.  As the function is naked, no frame is
available to store the value.

If the compiler would not check this and proceed compilation, the resulting
code would be non-functional.  This is similar for C.  Consider

extern void fun (int*);

__attribute__((naked))
void test (void)
{
    int x;
    fun (&x);
}

There's no place to store x here, and this even applies to optimized code.

Apart from this, the documentation for "naked" attribute reads:

>> [...] It allows the compiler to construct the requisite function
>> declaration, while allowing the body of the function to be
>> assembly code.
>> [...] Only Basic asm statements can safely be included in naked
>> functions. While using Extended asm or a mixture of Basic asm
>> and C code may appear to work, they cannot be depended upon to
>> work reliably and are not supported.

[Bug target/64052] compilation error "local frame unavailable" appears for some optimization levels

[eugene at hutorny dot in.ua]

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

--- Comment #4 from Eugene <eugene at hutorny dot in.ua> ---
I am not arguing for the sample code to be compilable and functional.
My expectation is a consistent compilation result regardless of the
optimisation settings. If it fails with 'O0' should fail with 'Os' too.

[Bug target/64052] compilation error "local frame unavailable" appears for some optimization levels

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Eugene from comment #4)
> I am not arguing for the sample code to be compilable and functional.
> My expectation is a consistent compilation result regardless of the
> optimisation settings. If it fails with 'O0' should fail with 'Os' too.

IMO this "consistency" is not feasible as the result depends on the
optimization level and probably optimization switches.  For such a
"consistency" the compiler would have to know the results of all other possible
option sets.

Not all diagnostics are emit during lexing or parsing, many diagnostics depend
on further analysis of code and data and might run after early inlining or dead
code / data elimination.