diff --git a/gcc/Makefile.in b/gcc/Makefile.in index a8e32e25cf5..c159825e62c 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3697,7 +3697,7 @@ TEXI_GCC_FILES = gcc.texi gcc-common.texi gcc-vers.texi frontends.texi \ # the *.texi files have changed. TEXI_GCCINT_FILES = gccint.texi gcc-common.texi gcc-vers.texi \ contribute.texi makefile.texi configterms.texi options.texi \ - portability.texi interface.texi passes.texi rtl.texi md.texi \ + portability.texi passes.texi rtl.texi md.texi \ $(srcdir)/doc/tm.texi hostconfig.texi fragments.texi \ configfiles.texi collect2.texi headerdirs.texi funding.texi \ gnu.texi gpl_v3.texi fdl.texi contrib.texi languages.texi \ diff --git a/gcc/doc/gccint.texi b/gcc/doc/gccint.texi index eea2d48f87a..d88fc1a1c68 100644 --- a/gcc/doc/gccint.texi +++ b/gcc/doc/gccint.texi @@ -87,8 +87,7 @@ Compiler Collection (GCC)}. This manual is mainly a reference manual rather than a tutorial. It discusses how to contribute to GCC (@pxref{Contributing}), the characteristics of the machines supported by GCC as hosts and targets -(@pxref{Portability}), how GCC relates to the ABIs on such systems -(@pxref{Interface}), and the characteristics of the languages for +(@pxref{Portability}), and the characteristics of the languages for which GCC front ends are written (@pxref{Languages}). It then describes the GCC source tree structure and build system, some of the interfaces to GCC front ends, and how support for a target system is @@ -100,7 +99,6 @@ Additional tutorial information is linked to from @menu * Contributing:: How to contribute to testing and developing GCC. * Portability:: Goals of GCC's portability features. -* Interface:: Function-call interface of GCC output. * Libgcc:: Low-level runtime library used by GCC. * Languages:: Languages for which GCC front ends are written. * Source Tree:: GCC source tree structure and build system. @@ -141,7 +139,6 @@ Additional tutorial information is linked to from @include contribute.texi @include portability.texi -@include interface.texi @include libgcc.texi @include languages.texi @include sourcebuild.texi diff --git a/gcc/doc/interface.texi b/gcc/doc/interface.texi deleted file mode 100644 index 1688d6f66ec..00000000000 --- a/gcc/doc/interface.texi +++ /dev/null @@ -1,70 +0,0 @@ -@c Copyright (C) 1988-2025 Free Software Foundation, Inc. -@c This is part of the GCC manual. -@c For copying conditions, see the file gcc.texi. - -@node Interface -@chapter Interfacing to GCC Output -@cindex interfacing to GCC output -@cindex run-time conventions -@cindex function call conventions -@cindex conventions, run-time - -GCC is normally configured to use the same function calling convention -normally in use on the target system. This is done with the -machine-description macros described (@pxref{Target Macros}). - -@cindex unions, returning -@cindex structures, returning -@cindex returning structures and unions -However, returning of structure and union values is done differently on -some target machines. As a result, functions compiled with PCC -returning such types cannot be called from code compiled with GCC, -and vice versa. This does not cause trouble often because few Unix -library routines return structures or unions. - -GCC code returns structures and unions that are 1, 2, 4 or 8 bytes -long in the same registers used for @code{int} or @code{double} return -values. (GCC typically allocates variables of such types in -registers also.) Structures and unions of other sizes are returned by -storing them into an address passed by the caller (usually in a -register). The target hook @code{TARGET_STRUCT_VALUE_RTX} -tells GCC where to pass this address. - -By contrast, PCC on most target machines returns structures and unions -of any size by copying the data into an area of static storage, and then -returning the address of that storage as if it were a pointer value. -The caller must copy the data from that memory area to the place where -the value is wanted. This is slower than the method used by GCC, and -fails to be reentrant. - -On some target machines, such as RISC machines and the 80386, the -standard system convention is to pass to the subroutine the address of -where to return the value. On these machines, GCC has been -configured to be compatible with the standard compiler, when this method -is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes. - -@cindex argument passing -@cindex passing arguments -GCC uses the system's standard convention for passing arguments. On -some machines, the first few arguments are passed in registers; in -others, all are passed on the stack. It would be possible to use -registers for argument passing on any machine, and this would probably -result in a significant speedup. But the result would be complete -incompatibility with code that follows the standard convention. So this -change is practical only if you are switching to GCC as the sole C -compiler for the system. We may implement register argument passing on -certain machines once we have a complete GNU system so that we can -compile the libraries with GCC@. - -On some machines (particularly the SPARC), certain types of arguments -are passed ``by invisible reference''. This means that the value is -stored in memory, and the address of the memory location is passed to -the subroutine. - -@cindex @code{longjmp} and automatic variables -If you use @code{longjmp}, beware of automatic variables. ISO C says that -automatic variables that are not declared @code{volatile} have undefined -values after a @code{longjmp}. And this is all GCC promises to do, -because it is very difficult to restore register variables correctly, and -one of GCC's features is that it can put variables in registers without -your asking it to.