From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14890 invoked by alias); 13 Aug 2014 08:07:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 14880 invoked by uid 89); 13 Aug 2014 08:07:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yh0-f51.google.com Received: from mail-yh0-f51.google.com (HELO mail-yh0-f51.google.com) (209.85.213.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 13 Aug 2014 08:07:58 +0000 Received: by mail-yh0-f51.google.com with SMTP id f73so8543877yha.10 for ; Wed, 13 Aug 2014 01:07:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.166.138 with SMTP id g10mr23933yhl.197.1407917276062; Wed, 13 Aug 2014 01:07:56 -0700 (PDT) Received: by 10.170.85.194 with HTTP; Wed, 13 Aug 2014 01:07:55 -0700 (PDT) In-Reply-To: References: <53E24E47.2090803@grosser.es> <53E3806E.7040903@grosser.es> <53E4CD87.5080105@grosser.es> <53E5D33C.6050800@grosser.es> <53E86219.6010904@grosser.es> <53E87052.6030004@grosser.es> Date: Wed, 13 Aug 2014 08:07:00 -0000 Message-ID: Subject: Re: [GSoC] Elimination of CLooG library installation dependency From: Roman Gareev To: Tobias Grosser Cc: Mircea Namolaru , gcc-patches@gcc.gnu.org Content-Type: multipart/mixed; boundary=14dae9d7c0ea1d0c3905007e49bf X-SW-Source: 2014-08/txt/msg01257.txt.bz2 --14dae9d7c0ea1d0c3905007e49bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-length: 1443 If I=E2=80=99m 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). I think that we=E2=80=99re 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=E2=80=99t 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 that it is better to do this when the pointer handling is completed. I=E2=80=99ve 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? --=20 Cheers, Roman Gareev. --14dae9d7c0ea1d0c3905007e49bf Content-Type: text/plain; charset=US-ASCII; name="ChangeLog_entry.txt" Content-Disposition: attachment; filename="ChangeLog_entry.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hysdjxl91 Content-length: 318 MjAxNC0wNy0xMiAgUm9tYW4gR2FyZWV2ICA8Z2FyZWV2cm9tYW5AZ21haWwu Y29tPgoKCWdjYy8KCSogZ3JhcGhpdGUtc2NvcC1kZXRlY3Rpb24uYzoKCUFk ZCBpbmNsdXNpb24gb2YgY3AtdHJlZS5oLgoJKGdyYXBoaXRlX2Nhbl9yZXBy ZXNlbnRfc2Nldik6IERpc2FibGVzIHRoZSBoYW5kbGluZyBvZiBTU0FfTkFN RSBub2RlcwoJaW4gY2FzZSB0aGV5IGFyZSBwb2ludGVycyB0byBvYmplY3Qg dHlwZXMuCg== --14dae9d7c0ea1d0c3905007e49bf--