From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7026 invoked by alias); 16 Apr 2013 11:48:55 -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 7002 invoked by uid 89); 16 Apr 2013 11:48:54 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_SEMBACKSCATTER autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 3 recipients Received: from mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 16 Apr 2013 11:48:53 +0000 Received: from archimedes.net-b.de (port-92-195-195-180.dynamic.qsc.de [92.195.195.180]) by mx02.qsc.de (Postfix) with ESMTP id 52BDA27F57; Tue, 16 Apr 2013 13:48:49 +0200 (CEST) Message-ID: <516D3AA0.4000106@net-b.de> Date: Tue, 16 Apr 2013 16:19:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Janus Weil CC: Mikael Morin , gfortran , gcc-patches Subject: Re: [Patch, Fortran, OOP] PR 56266: ICE on invalid in gfc_match_varspec References: <51695BFC.9010101@sfr.fr> <51697D4A.1060903@sfr.fr> <516C3AA0.4020302@sfr.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00990.txt.bz2 Janus Weil wrote: > As the comment says which the patch is removing, the gfc_match_varspec > should be relevant for cases like this: > > print *,char_func()(1:3) > print *,array_func()(2) > print *,derived_type_func()%comp > > Are we sure that all of these are actually invalid? (At least they are > rejected by gfortran.) Or are there other cases which would be valid? They are all invalid. The only exception is that a function itself is regarded as variable (if it returns a pointer): f() = 5 That's a new Fortran 2008 feature, which caused quite some trouble with user-defined operators, e.g. something like: 123 .foo. 5 = ... where "123" could be an argument (binary operator) or a label (+plus unary operator). (When we implement it, we should do some careful interpretation-request reading.) However, I think that doesn't affect the code you are removing. (Disclaimer: I haven't looked at the actual patch.) Tobias