[Bug tree-optimization/57698] New: rev.200179 causes many errors (inlining failures) when building Firefox

[Bug tree-optimization/57698] New: rev.200179 causes many errors (inlining failures) when building Firefox

[markus at trippelsdorf dot de]

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

            Bug ID: 57698
           Summary: rev.200179 causes many errors (inlining failures) when
                    building Firefox
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: markus at trippelsdorf dot de

I cannot build Firefox anymore with trunk because of inline errors, e.g.:

/home/markus/mozilla-central/js/src/jsapi.h: In function
‘js::regexp_exec(JSContext*, unsigned int, JS::Value*)’:
/home/markus/mozilla-central/js/src/builtin/RegExp.cpp:307:1: error: inlining
failed in call to always_inline ‘IsRegExp(JS::Value const&)’: indirect function
call with a yet undetermined callee
 IsRegExp(const Value &v)
 ^
In file included from /home/markus/mozilla-central/js/src/jsprvtd.h:24:0,
                 from /home/markus/mozilla-central/js/src/builtin/RegExp.h:10,
                 from /home/markus/mozilla-central/js/src/builtin/RegExp.cpp:7:
/home/markus/mozilla-central/js/src/jsapi.h:706:5: error: called from here
     if (Test(thisv))

IMO that is to aggressive (and will affect many projects). 
Wouldn't a simple warning be enough?
>From gcc-bugs-return-424988-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 24 11:32:21 2013
Return-Path: <gcc-bugs-return-424988-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1462 invoked by alias); 24 Jun 2013 11:32:21 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1349 invoked by uid 48); 24 Jun 2013 11:32:18 -0000
From: "dominik.strasser@onespin-solutions.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
Date: Mon, 24 Jun 2013 11:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: dominik.strasser@onespin-solutions.com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: fdumont at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status version resolution
Message-ID: <bug-53263-4-70SBdSpmUo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53263-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53263-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01367.txt.bz2
Content-length: 1238

http://gcc.gnu.org/bugzilla/show_bug.cgi?idS263

dominik.strasser@onespin-solutions.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
            Version|4.7.0                       |4.8.1
         Resolution|FIXED                       |---

--- Comment #16 from dominik.strasser@onespin-solutions.com ---
The situation is much improved in 4.8.1, but still not usable for me in bigger
configurations:
time ./a.out 10000

real    0m0.907s
user    0m0.904s
sys    0m0.003s

time ./a.out 20000

real    0m3.713s
user    0m3.708s
sys     0m0.001s

time ./a.out 40000

real     0m13.820s
user    0m13.812s
sys     0m0.001s

time ./a.out 80000

real    0m56.759s
user    0m56.729s
sys    0m0.001s

Still O(n^2).

(I modified the test program to use argv[1] as loop counter.

W/o _GLIBCXX_DEBUG:
time ./a.out 10000

real    0m0.008s
user    0m0.006s
sys    0m0.002s

./a.out 20000

real    0m0.013s
user    0m0.008s
sys    0m0.004s

./a.out 40000

real    0m0.013s
user    0m0.013s
sys    0m0.000s

./a.out 80000

real    0m0.026s
user    0m0.024s
sys    0m0.002s

Which shows O(n) behavior.

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I saw this too. There is always_inline (force_inline in the source) function
taking always_inline as a callback and we don't work hard enough to inline all
of them.  I am not sure if GCC is missing some indirect call inlining or it is
bug in firefox.

Concerning error/warning We generally output error when always_inline is not
inlined for some reason, so it seems bit odd to error sometimes and warn at
other times.

We also may just have disregard_inline_limits attribute for uses like this.

Honza

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[markus at trippelsdorf dot de]

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

--- Comment #2 from Markus Trippelsdorf <markus at trippelsdorf dot de> ---
Here's a reduced example:

 % cat test.ii
typedef bool (*IsAcceptableThis) (const int &);
inline int
fn1 (IsAcceptableThis p1)
{
    p1 (0);
    return 0;
}

__attribute__ ((always_inline))
inline bool fn2 (const int &)
{
    return 0;
}

void
fn3 ()
{
    fn1 (fn2);
}

 % g++ -c -O2 test.ii
test.ii: In function ‘void fn3()’:
test.ii:10:13: error: inlining failed in call to always_inline ‘bool fn2(const
int&)’: indirect function call with a yet undetermined callee
 inline bool fn2 (const int &)
             ^
test.ii:5:11: error: called from here
     p1 (0);
           ^
>From gcc-bugs-return-425073-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 25 09:22:04 2013
Return-Path: <gcc-bugs-return-425073-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17554 invoked by alias); 25 Jun 2013 09:22:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17468 invoked by uid 48); 25 Jun 2013 09:22:01 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/40920] Derived type with BIND(C) - rejected as argument.
Date: Tue, 25 Jun 2013 09:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.5.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-40920-4-iFighFdQgj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-40920-4@http.gcc.gnu.org/bugzilla/>
References: <bug-40920-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01452.txt.bz2
Content-length: 547

http://gcc.gnu.org/bugzilla/show_bug.cgi?id@920

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
AFAICT this PR has been fixed from 4.6 up to trunk (4.9). Closing as FIXED.
Please reopen if I am missing something.

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka <hubicka at ucw dot cz> ---
Hmm,
the problem here is that we output errors after early inlining always now,
while previously we did
only when some other inlining happened in the function (adding extra early
inlinable function
to the testcase should reproduce the error message on early GCC releases).
We can fix by outputting always inline errors only after real inliner was run
(when optimizing)
but then such testcases won't compile at -O0 that is uncol too.

Other alternatives include declaring such testcases invalid, always not
outputting diagnostic on
previously indirect calls, teaching always inliner to do indirect inlining
(that will need to
do analysis at -O0), adding disregard_inline_limits attribute...

Each of these has pros and cons...

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[marxin.liska at gmail dot com]

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

Martin Liška <marxin.liska at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin.liska at gmail dot com

--- Comment #4 from Martin Liška <marxin.liska at gmail dot com> ---
*** Bug 57729 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-425218-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 26 15:27:06 2013
Return-Path: <gcc-bugs-return-425218-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16409 invoked by alias); 26 Jun 2013 15:27:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16336 invoked by uid 48); 26 Jun 2013 15:27:03 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57729] Always inline: indirect function call with a yet undetermined callee
Date: Wed, 26 Jun 2013 15:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin.liska at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-57729-4-VlOx87qOXa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57729-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57729-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01597.txt.bz2
Content-length: 510

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

Martin Liška <marxin.liska at gmail dot com> changed:

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

--- Comment #4 from Martin Liška <marxin.liska at gmail dot com> ---
Duplicate.

*** This bug has been marked as a duplicate of bug 57698 ***
>From gcc-bugs-return-425220-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 26 15:31:37 2013
Return-Path: <gcc-bugs-return-425220-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24017 invoked by alias); 26 Jun 2013 15:31:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23626 invoked by uid 48); 26 Jun 2013 15:31:33 -0000
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57727] RaspberryPi gcc internal compiler error unrecognisable insn
Date: Wed, 26 Jun 2013 15:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.6.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktkachov at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-57727-4-ip6ZlmYKmP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57727-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57727-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01599.txt.bz2
Content-length: 703

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW727

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |ktkachov at gcc dot gnu.org
         Resolution|---                         |WONTFIX

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Reproduced with GCC 4.6.4.
However, this is fixed on all currently maintained versions of GCC, it worked
for me with 4.7.4, 4.8.1 and current trunk (4.9).

GCC 4.6 is not maintained anymore, please use a more recent release if you can.

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[kpet at free dot fr]

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

kpet at free dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kpet at free dot fr

--- Comment #5 from kpet at free dot fr ---
I encounter a similar problem when building pixman.

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[markus at trippelsdorf dot de]

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

--- Comment #6 from Markus Trippelsdorf <markus at trippelsdorf dot de> ---
(In reply to Jan Hubicka from comment #3)
> Hmm,
> the problem here is that we output errors after early inlining always now,
> while previously we did
> only when some other inlining happened in the function (adding extra early
> inlinable function
> to the testcase should reproduce the error message on early GCC releases).
> We can fix by outputting always inline errors only after real inliner was
> run (when optimizing)
> but then such testcases won't compile at -O0 that is uncool too.

I"m not sure if I understand you correctly, but the test-case compiles
just fine at -O0. So outputting the always inline errors only after the
real inliner was run should fix the issue. No?

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[tmsriram at google dot com]

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

--- Comment #7 from Sriraman Tallam <tmsriram at google dot com> ---
Taking a stab at fixing this.  Here is what is going on. In rev. 200179, this
change to tree-inline.c

Index: tree-inline.c
===================================================================
--- tree-inline.c       (revision 200178)
+++ tree-inline.c       (revision 200179)
@@ -3905,8 +3905,6 @@
             for inlining, but we can't do that because frontends overwrite
             the body.  */
          && !cg_edge->callee->local.redefined_extern_inline
-         /* Avoid warnings during early inline pass. */
-         && cgraph_global_info_ready
          /* PR 20090218-1_0.c. Body can be provided by another module. */
          && (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
        {

made inline failure errors during early inlining reportable.  Now, this
function is called when the early_inliner calls  optimize_inline_calls.  The
reason for the failure, CIF_INDIRECT_UNKNOWN_CALL, should not be reported
because it is not a valid reason,(see can_inline_edge_p in ipa-inline.c for the
list of reasons we intend to report) but it gets reported because of the above
change. 

I have the following patch to tree-inline.c to fix this by enumerating all the
early inliner failures that should be reported. I took this list by simply
looking at can_inline_edge_p. Please see patch below. Comments please? 

Index: tree-inline.c
===================================================================
--- tree-inline.c       (revision 200912)
+++ tree-inline.c       (working copy)
@@ -3838,6 +3838,32 @@ add_local_variables (struct function *callee, stru
       }
 }

+/* Should an error be reported when early inliner fails to inline an
+   always_inline function?  That depends on the REASON.  */
+
+static inline bool
+report_early_inliner_always_inline_failure (cgraph_inline_failed_t reason)
+{
+  /* Only the following reasons need to be reported when the early inliner
+     fails to inline an always_inline function.  Called from
+     expand_call_inline.*/
+  switch (reason)
+  {
+  case CIF_BODY_NOT_AVAILABLE:
+  case CIF_FUNCTION_NOT_INLINABLE:
+  case CIF_OVERWRITABLE:
+  case CIF_MISMATCHED_ARGUMENTS:
+  case CIF_EH_PERSONALITY:
+  case CIF_UNSPECIFIED:
+  case CIF_NON_CALL_EXCEPTIONS:
+  case CIF_TARGET_OPTION_MISMATCH:
+  case CIF_OPTIMIZATION_MISMATCH:
+    return true;
+  default:
+    return false;
+  }
+}
+
 /* If STMT is a GIMPLE_CALL, replace it with its inline expansion.  */

 static bool
@@ -3905,6 +3931,9 @@ expand_call_inline (basic_block bb, gimple stmt, c
             for inlining, but we can't do that because frontends overwrite
             the body.  */
          && !cg_edge->callee->local.redefined_extern_inline
+         /* During early inline pass, check if the reason is reportable.  */
+         && (cgraph_global_info_ready
+             || report_early_inliner_always_inline_failure (reason))
          /* PR 20090218-1_0.c. Body can be provided by another module. */
          && (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
        {

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[tmsriram at google dot com]

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

--- Comment #8 from Sriraman Tallam <tmsriram at google dot com> ---
One other alternative to the patch proposed earlier.  The reported bug happens
only when optimization is turned on as the early inliner pass invokes
incremental inlining which calls optimize_inline_calls and triggers the above
failure.  So, the fix is then as simple as:

Index: tree-inline.c
===================================================================
--- tree-inline.c       (revision 200912)
+++ tree-inline.c       (working copy)
@@ -3905,6 +3905,10 @@ expand_call_inline (basic_block bb, gimple stmt, c
             for inlining, but we can't do that because frontends overwrite
             the body.  */
          && !cg_edge->callee->local.redefined_extern_inline
+         /* During early inline pass, report only when optimization is
+            not turned on.  */
+         && (cgraph_global_info_ready
+             || !optimize) 
          /* PR 20090218-1_0.c. Body can be provided by another module. */
          && (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
        {

Seems like the right fix to me. Ok?

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-07-18
     Ever confirmed|0                           |1

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Yes, this is OK.
I wonder if we should output direct calls to autoinlines we introduce late
(i.e. if the error should be moved to expander). That would of course break the
Firefox again, but I think once we decided to error on uninlined calls we
should be consistent in it...

Honza

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[tmsriram at google dot com]

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

--- Comment #10 from Sriraman Tallam <tmsriram at google dot com> ---
Patch committed. This should fix this.

Sri

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf <markus at trippelsdorf dot de> changed:

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

--- Comment #11 from Markus Trippelsdorf <markus at trippelsdorf dot de> ---
(In reply to Sriraman Tallam from comment #10)
> Patch committed. This should fix this.
> 
> Sri

Thanks Sri.