This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch,Fortran] PR40949 - Fix gfc_get_function_type to fix -flto failure
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Tobias Burnus <burnus at net-b dot de>, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 5 Aug 2009 00:08:45 +0200
- Subject: Re: [Patch,Fortran] PR40949 - Fix gfc_get_function_type to fix -flto failure
- References: <20090804163448.GA25801@net-b.de> <571f6b510908041019o214782f7l90308dd1eaff2977@mail.gmail.com>
On Tue, Aug 4, 2009 at 7:19 PM, Steven Bosscher<stevenb.gcc@gmail.com> wrote:
> On Tue, Aug 4, 2009 at 6:34 PM, Tobias Burnus<burnus@net-b.de> wrote:
>> Hello,
>>
>> the test case gfortran.dg/proc_ptr_7.f90 fails on the LTO branch with "-flto -O3"
>> without the attached patch as the function prototype is wrong.
>>
>> The problem is that if one does not add a trailing void node, the middle end
>> assumes that one is allowed to pass more arguments (cf. C's "..."). The void
>> node was added - except for the case of no arguments.
>>
>> The fix is rather trivial.
>> Bootstrapped and regtested on x86-64-linux & build and tested with
>> gfortran.dg/proc_ptr_7.f90 on the LTO branch.
>>
>> OK for the trunk?
>
> So if the middle end handled Fortran functions as C's "..." functions
> before, does your patch result in an ABI change for gfortran? (Not
> that this would be an argument against the patch, but if it is then we
> should be aware of it...)
It seems that callers always built their own function decl, so there wasn't
really a varargs function being called.
Richard.