[Bug middle-end/11491] Problem with optimized inline caller of alloca()

["steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org
           Severity|normal                      |critical
             Status|UNCONFIRMED                 |NEW
          Component|c                           |middle-end
     Ever Confirmed|                            |1
   GCC host triplet|Linux 2.4.9-13 i686         |
 GCC target triplet|Linux 2.4.9-13 i686         |
   Last reconfirmed|0000-00-00 00:00:00         |2003-07-10 19:35:28
               date|                            |
   Target Milestone|3.4                         |3.3.1


------- Additional Comments From steven at gcc dot gnu dot org  2003-07-10 19:35 -------
I can confirm this bug with "gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)".

I can also confirm that the bug is _NOT_ present on mainline
"GNU C version 3.4 20030710 (experimental) (i686-pc-linux-gnu)":
Assembling functions: alloca_caller main
11491.c:6: warning: inlining failed in call to `alloca_caller'
11491.c:20: warning: called from here

This is the correct behavior.  A function calling alloca cannot be inlined
according to our inlining rules.  From tree-inline.c:

  /* Refuse to inline alloca call unless user explicitly forced so as this may
     change program's memory overhead drastically when the function using alloca 
     is called in loop.  In GCC present in SPEC2000 inlining into schedule_block
    
     cause it to require 2GB of ram instead of 256MB.  */

In other words, functions calling alloca are only inlined when they have
__attribute__((always_inline)).

This bug is filed vs. 3.2, which is no longer a maintained compiler.  GCC 3.2
did not use the tree-inliner, so presumably the bug is in the old RTL inliner. 
I suspect therefore that 3.3 does not show the bug because it does use the
tree-inliner.  Unfortunately I cannot confirm.

Can somebody check that 3.3.1pre gets this right, and if so, close this bug or
otherwise assign it to me because that would definitely be critical?