[Bug middle-end/18071] [3.4/4.0/4.1 Regression] -Winline does not respect -fno-default-inline

[Bug middle-end/18071] [3.4/4.0/4.1 Regression] -Winline does not respect -fno-default-inline

[mmitchel at gcc dot gnu dot org]

------- Comment #18 from mmitchel at gcc dot gnu dot org  2005-10-31 01:32 -------
I'm somewhat confused by the proposed patch in Comment #12.

The documentation says -Winline warns about functions *declared* inline, but
not actually inlined.  I think that makes sense.  DECL_INLINE is an internal
note to the compiler that it might make sense to inline that function.  Warning
a user because some small function, not declared inline, was not in fact
inlined, seems wrong.

So, I'm confused by "what we actually want is to emit a warning for the
functions
marked with DECL_INLINE".

In any case, I think P2 is the right setting for this bug.


-- 


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

[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]

------- 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

[Bug middle-end/18071] [3.4/4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline

[mmitchel at gcc dot gnu dot org]

------- Comment #20 from mmitchel at gcc dot gnu dot org  2006-02-24 00:25 -------
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.3                       |4.1.1


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

[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline

[mmitchel at gcc dot gnu dot org]

------- Comment #21 from mmitchel at gcc dot gnu dot org  2006-05-25 02:32 -------
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.1                       |4.1.2


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

[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline

[bonzini at gnu dot org]

------- Comment #22 from bonzini at gnu dot org  2006-08-05 08:16 -------
patch break -finline-functions, so it cannot be applied as is.  removing patch
keyword to avoid confusion with regressions awaiting review.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-  |
                   |patches/2004-               |
                   |11/msg02664.html            |
           Keywords|patch                       |


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

[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline

[lopezibanez at gmail dot com]

------- Comment #23 from lopezibanez at gmail dot com  2006-09-30 12:36 -------
I think I found out what is going on, although I cannot decide myself what is
the correct action.

For functions declared within class scope we do: (gcc/cp/decl.c start_method()
line 11285)

 DECL_DECLARED_INLINE_P (fndecl) = 1;
 if (flag_default_inline) 
    DECL_INLINE (fndecl) = 1;


Winline tests DECL_DECLARED_INLINE (which is correct). However, as shown above,
fno-default-inline does not change the DECL_DECLARED_INLINE but DECL_INLINE.
Solutions:

1) Nothing, things are correct as they are.
2) When we are going to emit the warning, we check for fno-default-inline and
check that the function is declared within class scope. I have no idea how to
do this or whether it is appropriate.
3) fno-default-inline sets both DECL_DECLARED_INLINE and DECL_INLINE to false.
It may break other things and the text of fno-default-inline says that these
functions will have linkage like inline functions.
4) Something else.


-- 

lopezibanez at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lopezibanez at gmail dot com


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

[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline

[wilson at gcc dot gnu dot org]

------- Comment #24 from wilson at gcc dot gnu dot org  2006-10-02 19:23 -------
Created an attachment (id=12372)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12372&action=view)
improved patch for inline warning

Works for simple testcases.  Needs full bootstrap regression test.


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline

[wilson at tuliptree dot org]

------- Comment #25 from wilson at tuliptree dot org  2006-10-02 19:25 -------
Subject: Re:  [4.0/4.1/4.2 Regression] -Winline does
        not respect -fno-default-inline

On Sat, 2006-09-30 at 12:36 +0000, lopezibanez at gmail dot com wrote:
> I think I found out what is going on, although I cannot decide myself what is
> the correct action.

If you look at Comment #19, you will see that I have already provided a
solution.  However, I see that I failed to add the patch I wrote to the
bug report.  I will do that now.  My work on this patch was interrupted
by health problems, and I haven't gotten back to it yet.  It is still
part of my large backlog.

Jim


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline

[lopezibanez at gmail dot com]

------- Comment #26 from lopezibanez at gmail dot com  2006-10-02 21:03 -------
(In reply to comment #25)
> If you look at Comment #19, you will see that I have already provided a
> solution.  However, I see that I failed to add the patch I wrote to the
> bug report.  I will do that now.  My work on this patch was interrupted
> by health problems, and I haven't gotten back to it yet.  It is still
> part of my large backlog.

And if you look at comment #18, you will see that Mark Mitchell has already
stated the Winline is suppossed to warn "about functions  *declared* inline,
but
not actually inlined. [...]  DECL_INLINE is an internal note to the compiler
that it might make sense to inline that function."

Your patch will break Winline output for any function that is declared inline (
DECL_DECLARED_INLINE_P (fndecl) = 1;) but it is marked as not making sense to
be inlined by the compiler (DECL_INLINE (fndecl) = 0;). From a quick grep,
there seems to be a few places where this may occur.

Of course, you know more about gcc than me. I was just trying to point out this
potential issue.


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[patchapp at dberlin dot org]

------- Comment #27 from patchapp at dberlin dot org  2007-01-16 19:45 -------
Subject: Bug number PR middle-end/18071

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01366.html


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[steven at gcc dot gnu dot org]

------- Comment #28 from steven at gcc dot gnu dot org  2007-12-16 23:16 -------
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[manu at gcc dot gnu dot org]

------- Comment #29 from manu at gcc dot gnu dot org  2007-12-17 10:46 -------
(In reply to comment #28)
> Open regression with no activity since February 14.  Ping?
> 

The last thread about this was in:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00523.html

Summarising:

* C++ front-end sets  DECL_DECLARED_INLINE_P for methods always. It sets
DECL_INLINE unless -fno-default-inline.

* -Winline warns when a function "declared inlined" is not inlined.  Currently,
"declared inline" means DECL_DECLARED_INLINE_P is set. 

* DECL_DECLARED_INLINE_P controls linkage.

* -fno-default-inline should not affect linkage.


Geoff Keating said: 

"DECL_DECLARED_INLINE_P in the C++ front-end means 'this function is an "inline
function" as defined by the standard'. There are two ways to get a function to
be an inline function: (a) the 'inline' keyword, and (b) define the function
inside a class; the ways are equivalent from the language's perspective. See
[dcl.fct.spec] in the C++ standard, especially paragraphs 2 and 3.

The question here is whether -Winline should be limited to those inline
functions in case (a) or whether it can include those in case (b) too."


Therefore, if -Winline also include case (b) then the warning seems correct. A
function that was declared inline was not inlined. Alternatively, we could not
warn for -fno-default-inline but then we would have to detect that: 1)
-fno-default-inline was given, 2) this is a method, 3) it wasn't declared using
the 'inline' keyword.

On the other hand, if -Winline is limited to case (a), then we need a way to
distinguish between (a) and (b).

Therefore, either the warning is correct and this is not a bug, or we need a
way to distinguish between (a) and (b). At least, this is how I see. I wouldn't
mind to implement other solution if one is clearly described and agreed.


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[rguenth at gcc dot gnu dot org]

------- Comment #31 from rguenth at gcc dot gnu dot org  2008-01-15 15:22 -------
Created an attachment (id=14943)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14943&action=view)
other approach to supress the warnings


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[rguenth at gcc dot gnu dot org]

------- Comment #30 from rguenth at gcc dot gnu dot org  2008-01-15 15:21 -------
I suggest to tag the DECL with TREE_NO_WARNING if -fno-default-inline is set
and
check this.

On the trunk the functions are inlined anyway, because we inline small
functions by default (and the functions are pure anyway).  Also trunk
tests

 if (!flag_inline_small_functions && !DECL_DECLARED_INLINE_P (decl))
    {
      if (reason)
        *reason = N_("function not inline candidate");
      return false;

that is, it uses DECL_DECLARED_INLINE_P (!) which is not affected by
-fno-default-inline.

Better testcase:

volatile int x;
struct Foo {
            int a(int r) { return r & x; }
    virtual int b(int r) { return r & x; }
    static  int c(int r) { return r & x; }
};

int bar(int r) {
    Foo f; int k = 0;
    k |= f.a(r); k |= f.b(r); k |= f.a(r);
    return k;
}

which will on the trunk warn with -fno-inline only.

With the proposed approach we'd improve this to

./cc1plus -quiet -Winline t.ii -O -fno-default-inline -fno-inline
t.ii: In constructor 'Foo::Foo()':
t.ii:2: warning: function 'Foo::Foo() throw ()' can never be inlined because it
is suppressed using -fno-inline
t.ii: In function 'int bar(int)':
t.ii:2: warning: inlining failed in call to 'Foo::Foo() throw ()': function not
inlinable
t.ii:9: warning: called from here

that is, the compiler-generated methods are still marked inline and are not
affected by -fno-default-inline.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org, hubicka at gcc dot gnu
                   |                            |dot org


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[hubicka at gcc dot gnu dot org]

------- Comment #32 from hubicka at gcc dot gnu dot org  2008-01-15 15:47 -------
I am bit confused by logic of code here. Middle end now ingore DECL_INLINE
consistently, it is still arround since it affect some instantiation decisions
in C++ FE.  Does fno-default-inline work?  I think only way to prevent inlining
is to make C++ frontend to drop implicit noinline attribute or split the two
meanings of DECL_DECLARED_INLINE (ie meaning to drive inliner and to drive
linkage).  As I understand it now, DECL_DECLARED_INLINE must be always set for
functions that are implicitly inline, even with -fno-default-inline, because it
affects linkage, right?

Honza


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[hubicka at ucw dot cz]

------- Comment #34 from hubicka at ucw dot cz  2008-01-15 15:59 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] -Winline does not respect
-fno-default-inline

> Yes, this is what I understand.  I think we need a new flag specifying
> if in the source the 'inline' keyword was used and solely use that for
> inline warning purposes.  (That is, I would not expect to get a warning
> for non-'inline' class methods either, regardless of -fdefault-inline
> setting).

Here I tend to be more with Geoff: since C++ standard says that inline
keyword is imlicit, I don't see why we should not warn on it and why
extra inline keyword should make difference. We don't handle those
functions specially in other inlining heuristics and thus it is bit
instructive to users to force them realize that they really are inline.
But if C++ people preffer to not warn, I definitly won't object.

Honza


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[rguenther at suse dot de]

------- Comment #33 from rguenther at suse dot de  2008-01-15 15:54 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] -Winline
 does not respect -fno-default-inline

On Tue, 15 Jan 2008, hubicka at gcc dot gnu dot org wrote:

> ------- Comment #32 from hubicka at gcc dot gnu dot org  2008-01-15 15:47 -------
> I am bit confused by logic of code here. Middle end now ingore DECL_INLINE
> consistently, it is still arround since it affect some instantiation decisions
> in C++ FE.  Does fno-default-inline work?  I think only way to prevent inlining
> is to make C++ frontend to drop implicit noinline attribute or split the two
> meanings of DECL_DECLARED_INLINE (ie meaning to drive inliner and to drive
> linkage).  As I understand it now, DECL_DECLARED_INLINE must be always set for
> functions that are implicitly inline, even with -fno-default-inline, because it
> affects linkage, right?

Yes, this is what I understand.  I think we need a new flag specifying
if in the source the 'inline' keyword was used and solely use that for
inline warning purposes.  (That is, I would not expect to get a warning
for non-'inline' class methods either, regardless of -fdefault-inline
setting).

Richard.


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[manu at gcc dot gnu dot org]

------- Comment #35 from manu at gcc dot gnu dot org  2008-01-15 16:44 -------
(In reply to comment #33)
> Yes, this is what I understand.  I think we need a new flag specifying
> if in the source the 'inline' keyword was used and solely use that for
> inline warning purposes.  (That is, I would not expect to get a warning
> for non-'inline' class methods either, regardless of -fdefault-inline
> setting).
> 

Then, you would need more than a new flag. Currently the problem is to
distinguish
1) the explicit 'inline' keyword and the implicit inline keyword of
-fdefault-inline from 2) no inline whatsoever and no inline because of
-fno-default-inline

Currently:

explicit inline: DECL_DECLARED_INLINE 
fdefault-inline : DECL_DECLARED_INLINE
fno-default-inline: DECL_DECLARED_INLINE
no inline:

(DECL_INLINE is an internal note that the function may be inlinable. Neither
explicit inline nor -fdefault-inline actually ensure that DECL_INLINE will be
always true).

Ideally:

explicit inline: DECL_DECLARED_INLINE && DECL_INLINE_LINKAGE
fdefault-inline : DECL_DECLARED_INLINE && DECL_INLINE_LINKAGE
fno-default-inline: DECL_INLINE_LINKAGE
no inline:

In your proposal we will need:

explicit inline: DECL_EXPLICITLY_DECLARED_INLINE && DECL_DECLARED_INLINE &&
DECL_INLINE_LINKAGE
fdefault-inline : DECL_DECLARED_INLINE && DECL_INLINE_LINKAGE
fno-default-inline: DECL_INLINE_LINKAGE
no inline:


-- 


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

[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline

[jsm28 at gcc dot gnu dot org]

------- Comment #36 from jsm28 at gcc dot gnu dot org  2008-07-04 16:34 -------
Closing 4.1 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression] -
                   |-Winline does not respect - |Winline does not respect -
                   |fno-default-inline          |fno-default-inline
   Target Milestone|4.1.3                       |4.2.5


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

[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline

[hubicka at gcc dot gnu dot org]

------- Comment #37 from hubicka at gcc dot gnu dot org  2008-09-17 15:02 -------
Subject: Bug 18071

Author: hubicka
Date: Wed Sep 17 15:00:59 2008
New Revision: 140418

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140418
Log:
        PR c++/18071
        * tree.h (DECL_INLINE): remove.
        (DECL_DECLARED_INLINE_P): Update docs.
        (DECL_NO_INLINE_WARNING_P): new.
        (tree_function_decl): Replace inline_flag by no_inline_warning_flag.
        * tree-inline.c (inlinable_function_p): Set DECL_NO_INLINE_WARNING_P.

        Java:
        * class.c (add_method_1): Do not initialize DECL_INLINE.
        (make_local_function_alias): Likewise.
        * expr.c (rewrite_arglist_getcaller): Set DECL_UNINLINABLE.
        * lang.c (java_decl_ok_for_sibcall): Use DECL_UNINLINABLE.

        Objc:
        * objc/objc-act.c (objc_finish_method_definition): Do not set
DECL_INLINE.

        C++:
        * cp/decl.c (start_method): Set DECL_NO_INLINE_WARNING_P.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl.c
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/class.c
    trunk/gcc/java/expr.c
    trunk/gcc/java/lang.c
    trunk/gcc/objc/ChangeLog
    trunk/gcc/objc/objc-act.c
    trunk/gcc/tree-inline.c
    trunk/gcc/tree.h


-- 


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

[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline

[steven at gcc dot gnu dot org]

------- Comment #38 from steven at gcc dot gnu dot org  2008-09-21 13:07 -------
Fixed by Honza's patch.


-- 

steven at gcc dot gnu dot org changed:

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


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

[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.5                       |4.4.0


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