[Bug fortran/57987] New: Fortran finalizers considered extern-inline by middle-end

[Bug fortran/57987] New: Fortran finalizers considered extern-inline by middle-end

[jamborm at gcc dot gnu.org]

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

            Bug ID: 57987
           Summary: Fortran finalizers considered extern-inline by
                    middle-end
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jamborm at gcc dot gnu.org

When looking at PR 57904, I found out that inliner refused to even
consider __final_test2_T/0 because, according to the dump, "redefined
extern inline functions are not considered for inlining."  When I
looked at why, I realized that the function is "finalized" (by
cgraph_finalize_function) twice.  Once directly from front-end and
second time from un-nesting nested functions.  I asked Honza about
this and he claims that front-ends should not do that, despite the
confusing parameter of cgraph_finalize_function.

(It's best to try this whith -fno-ipa-cp because of PR 57904 itself
and because it's slightly easier to follow, but is not necessary to
see the problem).

[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

[jamborm at gcc dot gnu.org]

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

--- Comment #1 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Created attachment 30558
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30558&action=edit
An unsuccessful attempt to fix this

I attempted to fix this with the attached patch but it fails some Fortran
testcases:

Tests that now fail, but worked before:

gfortran.dg/coarray/registering_1.f90 -fcoarray=lib  -O2  -lcaf_single (test
for excess er
rors)
gfortran.dg/coarray/registering_1.f90 -fcoarray=single  -O2  (test for excess
errors)
gfortran.dg/coarray/this_image_2.f90 -fcoarray=lib  -O2  -lcaf_single (test for
excess err
ors)
gfortran.dg/coarray_13.f90  -O0  (test for excess errors)
gfortran.dg/coarray_13.f90  -O1  (test for excess errors)
gfortran.dg/coarray_13.f90  -O2  (test for excess errors)
gfortran.dg/coarray_13.f90  -O3 -fomit-frame-pointer  (test for excess errors)
gfortran.dg/coarray_13.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions
  (test for excess errors)
gfortran.dg/coarray_13.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for
excess erro
rs)
gfortran.dg/coarray_13.f90  -O3 -g  (test for excess errors)
gfortran.dg/coarray_13.f90  -Os  (test for excess errors)

New tests that FAIL:

gfortran.dg/coarray/registering_1.f90 -fcoarray=lib  -O2  -lcaf_single
(internal compiler 
error)
gfortran.dg/coarray/this_image_2.f90 -fcoarray=lib  -O2  -lcaf_single (internal
compiler e
rror)

[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Comment on attachment 30558
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30558
An unsuccessful attempt to fix this

>+      if (!has_coarray_vars || gfc_option.coarray == GFC_FCOARRAY_LIB)
>+	(void) cgraph_create_node (fndecl);

It seems to work if I change the condition to:
                              || gfc_option.coarray != GFC_FCOARRAY_LIB)
which matches the comment and looks more reasonable.

(Don't ask me why the normal !(a && b != c) -> (!a || b == c) doesn't work.
It's to hot to think about it.)
>From gcc-bugs-return-426764-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 26 12:20:53 2013
Return-Path: <gcc-bugs-return-426764-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4199 invoked by alias); 26 Jul 2013 12:20:53 -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 4113 invoked by uid 48); 26 Jul 2013 12:20:50 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns  (-nan,-nan)
Date: Fri, 26 Jul 2013 12:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57974-4-b9JMNuHY26@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57974-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57974-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-07/txt/msg01271.txt.bz2
Content-length: 485

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

--- Comment #16 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Also, in practice, I think it's *very* hard to explain to the users why long
double is so special, why the middle-end can't handle it in complete analogy
with float and double. And since clang and icc are *already* doing it,
apparently, you can't just tell them, vaguely, "it's very tough to implement"
or "performance would be horrible" or something similar.

[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Uh oh, but I do not really feel comfortable submitting a patch like
this that I do not understand at all but happens to pass the testsuite :-)

[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

[hubicka at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I suppose the old test was simply a bug: cgraph_finalize_function creates node
when it does not exist and uses existing one otherwise. So I suppose the new
patch is OK - the conditional ought to match condition on which
generate_coarray_init is called. What we had was just latent bug hidden by the
cgraph_finalize_function lazyness.

If things get complex, simply calling cgraph_get_create_node on all nested
functions may be better option.

Honza

[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> ---
OK, so eventually I have posted the patch to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00074.html

Thanks.

[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2013-08/msg00074.htm
                   |                            |l
         Resolution|---                         |FIXED

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Author: jamborm
Date: Tue Aug  6 12:48:53 2013
New Revision: 201526

URL: http://gcc.gnu.org/viewcvs?rev=201526&root=gcc&view=rev
Log:
2013-08-06  Martin Jambor  <mjambor@suse.cz>

    PR fortran/57987
    * cgraphunit.c (cgraph_finalize_function): Assert that nested function
    is not re-finalized.  Rename second parameter to no_collect.

fortran/
    * trans-decl.c (gfc_generate_function_code): Never call
    cgraph_finalize_function on nested functions.

testsuite/
    * gfortran.dg/pr57987.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/pr57987.f90
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraphunit.c
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog