[Bug tree-optimization/29484] [4.0/4.1/4.2 Regression] tree-inline.c bug with local static vars
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29484
[Bug tree-optimization/29484] [4.0/4.1/4.2 Regression] tree-inline.c bug with local static vars
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-16 16:06 --- Confirmed. generates at -O and higher a reference to undefined local label No it generates an undefined local label at all levels of optimization in 4.0.x and above (there was a bug about not supporting used on local static at -O0 which you are running into also). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||link-failure Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2006-10-16 16:06:40 date|| Summary|tree-inline.c bug with local|[4.0/4.1/4.2 Regression] |static vars |tree-inline.c bug with local ||static vars Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29484
[Bug tree-optimization/29484] [4.0/4.1/4.2 Regression] tree-inline.c bug with local static vars
--- Comment #2 from jakub at gcc dot gnu dot org 2006-10-16 18:42 --- Actually, even C generates one static var for all the inlined functions (in C within one object), so I'd say we just should mark functions containing local static variables with label in their initializers as non-inlinable, because anything else means we can't use the same variable for more than one inlined copy of the function. In that light the original testcase would just issue an error, as always_inline function can't be inlined, but e.g. void baz (unsigned long *); static inline void bar (void) { addr:; static unsigned long b = (unsigned long) addr; baz (b); } void f1 (void) { bar (); } void f2 (void) { bar (); } would be a valid testcase that we don't handle properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29484