[Bug middle-end/18071] [3.4/4.0/4.1 Regression] -Winline does not respect -fno-default-inline
wilson at gcc dot gnu dot org
gcc-bugzilla@gcc.gnu.org
Fri Nov 4 04:32:00 GMT 2005
------- Comment #19 from wilson at gcc dot gnu dot org 2005-11-04 04:32 -------
Giovanni's patch substitutes DECL_INLINE for DECL_DECLARED_INLINE_P. This
breaks -finline-functions, since now we get warnings for functions that weren't
originally declared inline. See for instance PR 10929 which is a report about
this case. The testcase in 10929 won't fail anymore because of other changes,
but it isn't hard to construct a testcase that will fail. Here is one:
int foo (int);
int main(int,char)
{
return foo(10);
}
int
foo (int i)
{
static void *a[3] = {&&foo, &&bar, &&baz};
goto *a[i];
foo:
return i;
bar:
return 0;
baz:
return -i;
}
This gives a warning with -O -Winline -finline-functions, but it shouldn't.
I believe the correct solution here is to test both DECL_INLINE and
DECL_DECLARED_INLINE_P. This seems to solve both problems. There is no
warning with -finline-functions, because DECL_DECLARED_INLINE_P won't be set.
There is no warning with -fno-default-inline, because DECL_INLINE won't be set.
This construct is already used in another place in tree-inline.c.
The C front end change doesn't re-introduce the PR 5163 failure because it was
a different part of the patch that fixed it. The part that changed
"flag_inline_functions" to "flag_inline_function && initialized" which isn't
being reverted here. The part that is being reverted will cause the PR 5163
testcase to fail with gcc-3.1 only if we add the inline keyword to both vinit
declarations. Investigating, I see that this no longer fails on mainline
because of a side-effect of a C front end rewrite patch from Zack.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02114.html
This replaces a DECL_ORIGIN call with a DECL_ABSTRACT_ORIGIN call which
eliminates the problem that Richard's patch was fixing. The use of DECL_ORIGIN
here was accidentally setting DECL_ABSTRACT_ORIGIN when we shouldn't have been
setting it. So I think it is now safe to revert Richard's grokdeclarator
change here, except that I think we should revert both parts, instead of just
the one part that the proposed patch reverts. Just reverting one part leaves
an inconsistency in the code.
--
wilson at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilson at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
More information about the Gcc-bugs
mailing list