This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [GSoC] Elimination of CLooG library installation dependency
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Roman Gareev <gareevroman at gmail dot com>
- Cc: Tobias Grosser <tobias at grosser dot es>, Mircea Namolaru <mircea dot namolaru at inria dot fr>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 13 Aug 2014 11:55:39 +0200
- Subject: Re: [GSoC] Elimination of CLooG library installation dependency
- Authentication-results: sourceware.org; auth=none
- References: <CABGF_gco8bbFoBD=PORcSp=Q_wQpqca2M72mRzmyRO46B0juFQ at mail dot gmail dot com> <53E24E47 dot 2090803 at grosser dot es> <CABGF_geZoaTRwfc4on8NFehEdbrjH=xFD36QyH0a8AGi01yrBA at mail dot gmail dot com> <53E3806E dot 7040903 at grosser dot es> <CABGF_gfCmbvkSmwbzH20DibgUQvCj7WFasQw1yaRSOoNTPR6hA at mail dot gmail dot com> <53E4CD87 dot 5080105 at grosser dot es> <CABGF_gfnXsQhcZ3b55Fr43kzA_9qtTeN6oHUsk3suaDQQ5B7=w at mail dot gmail dot com> <53E5D33C dot 6050800 at grosser dot es> <CABGF_gcNZWxZriTAKaok_SsgadFj5n1hohbkQWErqPnLuGKDbg at mail dot gmail dot com> <53E86219 dot 6010904 at grosser dot es> <CABGF_gei3Mzg2sAgxmHBeObLsGF6oV-UpzPDsmMpz8mBSEx90Q at mail dot gmail dot com> <53E87052 dot 6030004 at grosser dot es> <CABGF_gcpJKNiN+Km=NOeK15j0DSS3nnhNkKD6xnzeNw3PLQ9pg at mail dot gmail dot com> <CABGF_geMr1sJ3kvG5ZUdQcd4X+nwmWDMeVYL+_exG4hVQ2F04A at mail dot gmail dot com>
On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev <gareevroman@gmail.com> wrote:
> If Iâm not mistaken all tree nodes, which have pointer type, can be
> divided into two groups: the type is a is a pointer to data member
> (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the
> pointee is not a data member (TYPE_PTR_P is true for it).
Both are C++ frontend concepts and not relevant for the middle-end
and thus GRAPHITE.
I think that
> weâre interested in disabling of the second group handling. It can
> also be divided into two groups: the type is a pointer to function
> type (TYPE_PTRFN_P is true for it), the type is a pointer to object
> type (TYPE_PTROB_P is true for it). In my opinion, the second one is
> worth to be considered. It contains, for example, nop_expr (these
> nodes are used to represent conversions that do not require any
> code-generation) integer_cst (these nodes represent integer
> constants), ssa_name. I havenât found all types, which are contained
> in it. However, I think that we could disable other types, if it is
> necessary in the future.
>
>> What we should do later is to build a run-time check that ensures
>> no pointer overflow is happening and then just create code without it.
I think you can assume that pointers don't overflow.
Richard.
> I think that it is better to do this when the pointer handling is completed.
>
> Iâve attached a Change_Log, which corresponds to the previous patch.
> Are they fine for trunk? Could we give a headsup on the GCC mailing
> list and ask other people to try the new isl support in case this
> patch is committed?
>
> --
> Cheers, Roman Gareev.