This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH 3.3 0203 i386/{i386.c,{i386elf,ptx4-i,sysv4}.h} for UnixWare build failure.
> Jan Hubicka <jh@suse.cz> writes:
> >
> > It is not clear to my why I am "moving to using
> > DEFAULT_PCC_STRUCT_RETURN over RETURN_IN_MEMORY". I just have to
> > disable flag_pcc_struct_return for x86-64 that is enabled by default for
> > Linux. That was the only reason for that change.
> > I didn't intended to change anything else to be safe.
> >
> > Currently flag_pcc_struct_return controls the PS-ABI compiliant behaviour
> > where each structure is returned in memory (used by Linux for instance),
> > and the "gcc" way of returning small structs in registers (used by BSD).
> >
> > I agree that it would be cleaner to have this decided in
> > x86_return_in_memory, but I wanted to first ensure whether you are
> > discussing some bug I introduced by the change, or future cleanup.
>
> Okay, I see where the confusion is now. I had three different things
> tangled up in my original post.
>
> You did sort of introduce a bug, in that you induced new requirements
> on ix86 subtargets. They now should not define RETURN_IN_MEMORY, and
> need to provide some definition of DEFAULT_PCC_STRUCT_RETURN, or
> i386.c will not compile. Rodney's patch was addressing that problem.
>
> Independent of that, I observe that the 32-bit case of ix86_return_in_memory
> reads
>
> if (TYPE_MODE (type) == BLKmode
> || (VECTOR_MODE_P (TYPE_MODE (type))
> && int_size_in_bytes (type) == 8)
> || (int_size_in_bytes (type) > 12 && TYPE_MODE (type) != TImode
> && TYPE_MODE (type) != TFmode
> && !VECTOR_MODE_P (TYPE_MODE (type))))
> return 1;
> return 0;
>
> Now it is my understanding that "TYPE_MODE (type) == BLKmode" and
> "AGGREGATE_TYPE_P (type)" wind up being equivalent tests even though
I believe that small strucutures can have QI/HI/SI/DImodes, so this is
not equivalent and where the difference between
DEFAULT_PCC_STRUCT_RETURN beig 0/1 comes from. Not dificult to fix.
Honza
> they base their test on different data. I could be wrong about that.
> If I am correct, then the setting of DEFAULT_PCC_STRUCT_RETURN makes
> no difference on any 32-bit ix86 target, which means that we could
> make life easier for subtarget maintainers by putting an unconditional
>
> #define DEFAULT_PCC_STRUCT_RETURN 0
>
> in i386.h, removing all subtarget definitions of
> DEFAULT_PCC_STRUCT_RETURN and RETURN_IN_MEMORY, and removing the code
> in i386.c that diddles flag_pcc_struct_return.
>
> Independent of *that*, I want to see -fpcc-struct-return go away and
> all targets use RETURN_IN_MEMORY exclusively to specify this part of
> their ABI.
>
> zw
- References:
- Re: PATCH 3.3 0203 i386/{i386.c,{i386elf,ptx4-i,sysv4}.h} forUnixWare build failure.
- Re: PATCH 3.3 0203 i386/{i386.c,{i386elf,ptx4-i,sysv4}.h} for UnixWare build failure.
- Re: PATCH 3.3 0203 i386/{i386.c,{i386elf,ptx4-i,sysv4}.h} forUnixWare build failure.
- Re: PATCH 3.3 0203 i386/{i386.c,{i386elf,ptx4-i,sysv4}.h} for UnixWare build failure.
- Re: PATCH 3.3 0203 i386/{i386.c,{i386elf,ptx4-i,sysv4}.h} forUnixWare build failure.