This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 00/89] Compile-time gimple-checking
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>,Richard Sandiford <rdsandiford at googlemail dot com>,David Malcolm <dmalcolm at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 02 May 2014 11:09:19 +0200
- Subject: Re: [PATCH 00/89] Compile-time gimple-checking
- Authentication-results: sourceware.org; auth=none
- References: <1398099480-49147-1-git-send-email-dmalcolm at redhat dot com> <877g6hhjti dot fsf at talisman dot default> <1398186366 dot 26834 dot 95 dot camel at surprise> <87lhuxfb0n dot fsf at talisman dot default> <ac354302-43e9-4ecb-9706-662814a77982 at email dot android dot com> <CAFiYyc3cMpgyCNK6pbeNAgUfSHd=0MZP-M1CGOCkqwtnm2tVuw at mail dot gmail dot com> <CAFiYyc2=uNwYchErrjwVbB7=9cZuE9MmxgZ475zQi8Ns6omTnQ at mail dot gmail dot com> <53616A8B dot 4090502 at redhat dot com>
On April 30, 2014 11:26:35 PM CEST, Jeff Law <firstname.lastname@example.org> 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
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.