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: [PATCH 00/89] Compile-time gimple-checking

On April 30, 2014 11:26:35 PM CEST, Jeff Law <> wrote:
>On 04/23/14 08:32, Richard Biener wrote:
>>> Also I see you introduce a const_FOO class with every FOO one.
>>> I wonder whether, now that we have C++, can address
>>> in a less awkward way than with a typedef.  Can you try to go back
>>> in time and see why we did with that in the first place?  ISTR that
>>> it was "oh, if we were only using C++ we wouldn't need to jump
>>> that hoop".
>> To followup myself here, it's because 'tree' is a typedef to a
>> and thus 'const tree' is different from 'const tree_node *'.
>> Not sure why we re-introduced the 'mistake' of making 'tree' a
>> when we introduced 'gimple'.  If we were to make 'gimple' the class
>> type itself we can use gimple *, const gimple * and also const gimple
>> (when a NULL pointer is not expected).
>It wasn't ever really discussed to the best of my recollection.
>> Anyway, gazillion new typedefs are ugly :/  (typedefs are ugly)
>Yea, can't argue with that.  However, do we want to ask David to fix up
>the gimple vs gimple * vs const gimple * vs const gimple & as a 
>prerequisite for this patchset or are you comfortable going forward
>the patchset, then researching if there's a cleaner way to handle the 
>const/typedef issues?

Well, I'd like to see both and one affects the other. Doing the const correctness thing first seems more natural to me.
Of course both need to wait for 4.9.1.



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