This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, fortran] annotate library calls, part 1
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: Daniel Franke <franke dot daniel at gmail dot com>, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Tue, 13 Jul 2010 18:51:01 +0200
- Subject: Re: [patch, fortran] annotate library calls, part 1
- References: <201005122052.45338.franke.daniel@gmail.com> <4BFBDC46.9040201@net-b.de> <4C3B2938.40806@net-b.de> <4C3B4038.2040508@sfr.fr> <4C3C6850.5090501@net-b.de>
Le 13.07.2010 15:21, Tobias Burnus a écrit :
On 07/12/2010 06:18 PM, Mikael Morin wrote:
Le 12.07.2010 16:39, Tobias Burnus a écrit :
Attached patch annotates the library calls in trans-decl.c and
trans-io.c with
noclobber/noescape attributes.
I disagree for ttynam, fdate, ctime.
- ttynam : ".W.." instead of ".WW." :
- fdate : ".W." instead of ".ww" :
- ctime : ".W.." instead of ".Rw." :
I concur - seemingly, I wrongly looked at the subroutine version instead
of the function version. (trans-decl.c only handles the latter.)
By the way the documentation has the arguments in reversed order it seems.
I checked "ctime" and the result looks fine for both subroutine and
function version, cf. http://gcc.gnu.org/onlinedocs/gfortran/CTIME.html
-- why do you think that the order is reversed?
From your patch :
+ gfor_fndecl_ctime = gfc_build_library_function_decl_with_spec (
+ get_identifier (PREFIX("ctime")), ".W",
+ void_type_node, 3, pchar_type_node, gfc_charlen_type_node,
+ gfc_int8_type_node);
the char (pointer and length) is first, the integer is last.
From the documentation :
call ctime(i,date)
The integer is first, the char (pointer and length) is last.
But you have said that trans-decl.c doesn't handle the subroutine
version ? I was supposing that both were handled by the same subroutine
declaration and the front-end was rewriting the function version as a
subroutine call.
For set_args, isn't "..." the same as no spec at all ?
Changed to the no-spec version.
Updated patch attached, committed as Rev. 162140.
Thanks,
Mikael