This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/10109] documentation of target macro LIBCALL_VALUE
- From: "pinskia at physics dot uc dot edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Jul 2003 20:53:47 -0000
- Subject: [Bug other/10109] documentation of target macro LIBCALL_VALUE
- References: <20030316145601.10109.a.cilio@et.tudelft.nl>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10109
pinskia at physics dot uc dot edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2003-05-27 13:02:26 |2003-07-11 20:53:47
date| |
------- Additional Comments From pinskia at physics dot uc dot edu 2003-07-11 20:53 -------
In fact LIBRARY_VALUE is not used at all any more (at least on the mainline) so at least
this should be removed.
It does look like LIBRARY_VALUE should be replaced with LIBCALL_VALUE:
@defmac LIBCALL_VALUE (@var{mode})
A C expression to create an RTX representing the place where a library
function returns a value of mode @var{mode}. If the precise function
being called is known, @var{func} is a tree node
(@code{FUNCTION_DECL}) for it; otherwise, @var{func} is a null
pointer. This makes it possible to use a different value-returning
convention for specific functions when all their calls are
known.
Note that ``library function'' in this context means a compiler
support routine, used to perform arithmetic, whose name is known
specially by the compiler and was not mentioned in the C code being
compiled.
The definition of @code{LIBRARY_VALUE} need not be concerned aggregate
data types, because none of the library functions returns such types.
@end defmac