This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 3.2.2 on Sol 9 x86 failure

On Mon, 17 Feb 2003 02:24:58 GMT, "J.D. Bronson" <> wrote:

>"Kai Ruottu" <> wrote in message
>> On Sat, 15 Feb 2003 03:24:03 GMT, "J.D. Bronson"
><> wrote:
>> >I compiled gcc 3.2.1 on solaris 9 via gcc 2.95.3 and it compiled fine.
>> >However, I attempt to compile GCC 3.2.2 using the same command line
>> >arguments and via gcc 3.2.1 and this is what happens:
>> >
>> ><snip>
>> >        ../../gcc/config/i386/i386.c -o i386.o
>> >../../gcc/config/i386/i386.c: In function `override_options':
>> >../../gcc/config/i386/i386.c:927: `DEFAULT_PCC_STRUCT_RETURN' undeclared
>> >
>> >Any thoughts on this?
>>  Clearly a bug in gcc-3.2.2 with the SVR4/i386s.  How to fix it is then
>> another issue...  Anyway my suggestion would be to patch the config file
>> 'gcc/config/i386/sysv4.h' as follows:
>> ------------------- clip ------------------------
>> *** sysv4.h.orig Tue Jan 22 21:59:30 2002
>> --- sysv4.h Sun Feb 16 17:54:24 2003
>> ***************
>> *** 27,32 ****
>> --- 27,35 ----
>>   /* The svr4 ABI for the i386 says that records and unions are returned
>>      in memory.  */
>> +
>>   #undef RETURN_IN_MEMORY
>>   #define RETURN_IN_MEMORY(TYPE) \
>>     (TYPE_MODE (TYPE) == BLKmode \
>> ------------------- clip ------------------------
>>  You could report this bug and try to investigate whether the previous
>> fix is ok via the SVR4 docs at:
>this fixed the build under solaris. MANY THANKS :)

 You are welcome!

 Some elaborations still... It can be that the Solaris9 libs still use the
old slower convention and defining the DEFAULT_PCC_STRUCT_RETURN to be '1'
would be right.  Anyway the GCC-internals manual for gcc-3.2.2 tells about
the shown two macros:

------------------------------- clip -------------------------------------
	A C expression which can inhibit the returning of certain function
	values in registers, based on the type of value. A nonzero value
	says to return the function value in memory, just as large structures
	are always returned. Here type will be a C expression of type tree,
	representing the data type of the value.

	Note that values of mode BLKmode must be explicitly handled by this
	macro. Also, the option `-fpcc-struct-return' takes effect regardless
	of this macro. On most systems, it is possible to leave the macro
	undefined; this causes a default definition to be used, whose value
	is the constant 1 for BLKmode values, and 0 otherwise.

	Do not use this macro to indicate that structures and unions should
	always be returned in memory. You should instead use
	DEFAULT_PCC_STRUCT_RETURN to indicate this.

	Define this macro to be 1 if all structure and union return values
	must be in memory. Since this results in slower code, this should
	be defined only if needed for compatibility with other compilers or
	with an ABI. If you define this macro to be 0, then the conventions
	used for structure and union return values are decided by the

	If not defined, this defaults to the value 1.
------------------------------- clip -------------------------------------

 The 'PCC' comes from the AT&T's 'Portable C Compiler' being present in the
SVR-Unices some time, AFAIK. So compatability with this C compiler might require
defining the option `-fpcc-struct-return' being the default (please see the
GCC User Manual). What convention the C-compiler used to compile the Solaris9
C-libraries uses is however the important thing here. I would expect producing
fast code would be one goal in it though...

 The words "this results in slower code" made me suggest to disable this (like
in FreeBSD and NetBSD). The words: "If not defined, this defaults to the value 1"
are wrong as you could see, the 'gcc/toplev.c' does define this but the config
file 'gcc/config/i386/i386.c' doesn't define it at all although uses it... So
maybe something like:


should be there instead... I have forwarded this message to the gcc-bugs and
gcc-patches maillists, so perhaps we will see someone replying from them...

Cheers, Kai

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]