This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] Fix PR26439

From: Jakub Jelinek <jakub at redhat dot com>
To: Daniel Berlin <dberlin at dberlin dot org>
Cc: Diego Novillo <dnovillo at redhat dot com>, Richard Guenther <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, pinskia at physics dot uc dot edu
Date: Thu, 23 Feb 2006 10:44:58 -0500
Subject: Re: [PATCH] Fix PR26439
References: <Pine.LNX.4.63.0602231534460.7478@t148.fhfr.qr> <43FDD62C.9080703@redhat.com> <1140709241.17170.9.camel@linux.site>
Reply-to: Jakub Jelinek <jakub at redhat dot com>

On Thu, Feb 23, 2006 at 10:40:41AM -0500, Daniel Berlin wrote:
> AGGREGATE_TYPE_P (type) || TREE_CODE (type) == COMPLEX_TYPE, which is,
> uh, dumb :(
> 
> I'd guess it's not in AGGREGATE_TYPE_P because they sometimes appear in
> SSA_NAME_VAR, and this will confuse is_gimple_reg or something.
> 
> (even though it should be checking DECL_COMPLEX_GIMPLE_REG_P or whatever
> the name is)
> 
> I agree it's a much better fix to put COMPLEX_TYPE in AGGREGATE_TYPE_P,
> i'm just not sure how much work it is.

Note e.g. that a big number of backends use AGGREGATE_TYPE_P when
determining calling conventions, so making COMPLEX_TYPE AGGREGATE_TYPE_P
would mean checking all those places and making sure it doesn't break the
ABI.

	Jakub

Follow-Ups:
- Re: [PATCH] Fix PR26439
  - From: Richard Guenther

References:
- [PATCH] Fix PR26439
  - From: Richard Guenther
- Re: [PATCH] Fix PR26439
  - From: Diego Novillo
- Re: [PATCH] Fix PR26439
  - From: Daniel Berlin

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