This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Ada PATCH] Clean-up Ada front-end use of TREE_OVERFLOW
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Sun, 15 May 2005 18:31:14 -0600 (MDT)
- Subject: Re: [Ada PATCH] Clean-up Ada front-end use of TREE_OVERFLOW
On Sun, 15 May 2005, Richard Kenner wrote:
> Diagnosing these these types of problem in GCC's Ada front-end would be
> easier if the following patch could be approved (ping?):
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00175.html
>
> That needs somebody who knows the pp stuff; it's OK with me if it looks
> correct to them.
Hopefully, Gabriel can comment? I apologise in advance as I appreciate
he's currently being kept busy by gcc 3.3.5.
> > Ok for mainline?
>
> Probably, but I'd like to ask what the TREE_OVERFLOW checking will be
> testing. If TREE_CODE_CLASS, then I think it's more consistent to do
> the same check in max_size, but if a list of explicit codes, then I
> agree with your patch.
Whilst I agree that using CONSTANT_CLASS_P would be consistent and
therefore obviously safe, the explicit use of an explicit INTEGER_CST
test is motivated by context. IIUC the values being represented and
manipulated by ada/utils.c's max_size function denote the size in
bytes (or possibly bits) of data types and data structures. These
presumably should never be floating point, complex or vector constant
values, i.e. REAL_CST, COMPLEX_CST or VECTOR_CST.
Let me know if I'm overlooking something.
Thanks for your speedy review.
Roger
--