[Bug middle-end/30506] New: violation of automatic storage duration [basic.stc.auto 3.7.2/1].

[Bug middle-end/30506] New: violation of automatic storage duration [basic.stc.auto 3.7.2/1].

[pluto at agmk dot net]

consider following testcase:

void f( char );
void g( char c )
{
        {
                char buf[ 128 * 1024 ];
                __builtin_memset( buf, 0, sizeof( buf ) );
                c = buf[ 0 ];
        }
        f( c );
}

3.7.2/1:
"(...) the storage for these objects lasts until the block
 in which they are created exits."

in fact gcc-4.2 keeps allocated storage until the end of function.
such situation may lead to stack overflow during few recursive f->g calls.

$ g++ local_buf.cpp -O2 -Wall -S

g(char):
        subq    $131080, %rsp
        movl    $131072, %edx
        xorl    %esi, %esi
        movq    %rsp, %rdi
        call    memset
        movsbl  (%rsp),%edi
        call    f(char)
        addq    $131080, %rsp
        ret


-- 
           Summary: violation of automatic storage duration [basic.stc.auto
                    3.7.2/1].
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pluto at agmk dot net


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

[Bug middle-end/30506] violation of automatic storage duration [basic.stc.auto 3.7.2/1].

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-01-18 23:15 -------
This is not really a violation of that rule at all.  What that rule is stating
is that if you access that array again outside of the block where it was
created, you invoke undefined behavior.


-- 


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

[Bug middle-end/30506] violation of automatic storage duration [basic.stc.auto 3.7.2/1].

[pluto at agmk dot net]

------- Comment #2 from pluto at agmk dot net  2007-01-18 23:23 -------
(In reply to comment #1)
> This is not really a violation of that rule at all.  What that rule is stating
> is that if you access that array again outside of the block where it was
> created, you invoke undefined behavior.

hmm, you've a right, so could we rework the bug to some kind
of feature-request? i'd love to see the stack cleanup before f() call.


-- 


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

[Bug target/30506] not sibcalling a function

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


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

[Bug target/30506] not sibcalling a function

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-01-18 23:26 -------
(In reply to comment #2)
> hmm, you've a right, so could we rework the bug to some kind
> of feature-request? i'd love to see the stack cleanup before f() call.
Actually for this case, we just need to have f sibcalled and now the reason why
it is not sibcalled is a different reason and target dependent issue now
because it is sibcalled on ppc.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target
 GCC target triplet|                            |x86-64-linux-gnu
            Summary|violation of automatic      |not sibcalling a function
                   |storage duration            |
                   |[basic.stc.auto 3.7.2/1].   |


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

[Bug middle-end/30506] not sibcalling a function

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-01-21 21:10 -------
I was wrong about this being tail called on PPC, though it should.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end


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

[Bug middle-end/30506] not sibcalling a function

[pluto at agmk dot net]

------- Comment #5 from pluto at agmk dot net  2010-03-11 09:40 -------
recent 4.5.0 sibcalls this on x86-64 only:

/opt/gcc45/bin/g++45 t.cpp -O2 -S -m64 -fpie -o t64.s

_Z1gc:
        .cfi_startproc
        subq    $131080, %rsp
        .cfi_def_cfa_offset 131088
        movl    $131072, %edx
        xorl    %esi, %esi
        movq    %rsp, %rdi
        call    memset@PLT
        xorl    %edi, %edi
        addq    $131080, %rsp
        .cfi_def_cfa_offset 8
        jmp     _Z1fc@PLT

/opt/gcc45/bin/g++45 t.cpp -O2 -S -m32 -fpie -o t32.s

_Z1gc:
        .cfi_startproc
        pushl   %ebp
        .cfi_def_cfa_offset 8
        movl    %esp, %ebp
        .cfi_offset 5, -8
        .cfi_def_cfa_register 5
        pushl   %ebx
        .cfi_offset 3, -12
        call    __i686.get_pc_thunk.bx
        addl    $_GLOBAL_OFFSET_TABLE_, %ebx
        subl    $131092, %esp
        leal    -131080(%ebp), %eax
        movl    $131072, 8(%esp)
        movl    $0, 4(%esp)
        movl    %eax, (%esp)
        call    memset@PLT
        movl    $0, (%esp)
        call    _Z1fc@PLT
        addl    $131092, %esp
        popl    %ebx
        .cfi_restore 3
        popl    %ebp
        .cfi_restore 5
        .cfi_def_cfa 4, 4
        ret
        .cfi_endproc


-- 


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

[Bug middle-end/30506] not sibcalling a function

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2010-03-11 12:34 -------
That's not a bug.  Unlike x86-64, on i?86 when calling (or jumping to) a PLT
slot in position independent code %ebx must be set to the calling function's
PIC pointer.  As %ebx is call saved register, this precludes sibcall.


-- 


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

[Bug middle-end/30506] not sibcalling a function

[pluto at agmk dot net]

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

Pawel Sikora <pluto at agmk dot net> changed:

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

--- Comment #7 from Pawel Sikora <pluto at agmk dot net> 2011-06-22 22:14:00 UTC ---
seems to be fixed:

g:      subq    $131080, %rsp
        movl    $131072, %edx
        xorl    %esi, %esi
        movq    %rsp, %rdi
        call    memset
        xorl    %edi, %edi
        addq    $131080, %rsp
        jmp     f