This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
*ping* Re: [Fortran,Patch] PR40955 - Save ext_attr such as STDCALL to .MOD file
- From: Tobias Burnus <burnus at net-b dot de>
- To: fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Sat, 08 Aug 2009 23:39:52 +0200
- Subject: *ping* Re: [Fortran,Patch] PR40955 - Save ext_attr such as STDCALL to .MOD file
- References: <20090804082319.GA7941@net-b.de> <20090805123157.GA14013@net-b.de>
*ping* http://gcc.gnu.org/ml/fortran/2009-08/msg00050.html
Tobias Burnus wrote:
> On Tue, Aug 04, 2009 at 10:23:19AM +0200, Tobias Burnus wrote:
>
>> Another STDCALL (and friends) omission: The extended attribute was not
>> saved in the MOD file.
>>
> Attached patch supercedes that patch. New features:
> - gfc_copy_attr now also copies the extended attributes
> - Extended attributes now also work with procedure (pointers), inheriting
> the attributes from the (abstract) interface (or-ed together with local
> addition; if a combination does not make sense, I leave it to the middle
> end to warn)
>
> And I changed gfc_add_ext_attr to take an enum as argument instead of
> an unsigned int. The reason is that I was tempted to use
> gfc_add_ext_attr (sym, attr->ext_attr)
> which does not work. (In gfc_add_ext_attr the argument a "1" is bit
> shifted depending on the argument.) With enum there is at least the
> chance that we get a compile-time warning (or via -Werror an error).
>
>
>> I could have bumped the MOD file version; however, as it already was
>> bumped for 4.5 and as the message is somewhat clear
>> ("Fatal Error: Reading module ... Expected attribute bit name" ...
>> and "... Expected integer"), I have not done it.
>>
>> I have bootstrapped and regtested (check gfortran & libgomp) it on
>> x86-64-linux, but I cannot really test it - except that for a simple
>> test case, there is now an additional
>> test.f90:10:0: warning: 'stdcall' attribute ignored
>> for the CALL, i.e. it seems to work correctly.
>>
> The procedure part was tested on x86-64-linux with the test case from
> the PR. (GCC on x86-64 shows nice warnings that the options was ignored.)
>
>
>> I do not know how to best create a test case, thus I have not added
>> one. I think we badly need a test case for 32bit MinGW/Cygwin, which
>> calls some STDCALL Windows ABI function.
>>
> Another option is to add a test for x86-64 and check for dg-warning.
> I can add such a patch, if it is deemed to be useful.
>
>
>> OK for the trunk?
>>
> Tobias
>