From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65365 invoked by alias); 11 Jul 2017 20:23:33 -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 63718 invoked by uid 89); 11 Jul 2017 20:23:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPAM_BODY,SPF_PASS autolearn=no version=3.3.2 spammy=blown, mains, gurus, blood X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yb0-f182.google.com Received: from mail-yb0-f182.google.com (HELO mail-yb0-f182.google.com) (209.85.213.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Jul 2017 20:23:30 +0000 Received: by mail-yb0-f182.google.com with SMTP id 84so1074454ybe.0; Tue, 11 Jul 2017 13:23:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eH+J6uY/nuXpcaLVq+spOJJmc40vWzY5k0O80jLL0nE=; b=GXm6HJx9J1ONmuTTIBNRX9dVlW6MD18KZEpRT1xxte7X6QsGf1LnfMXlezgpZ8duDE hhlKjV8vkDq6hR13k+Ia/HfUR3QXAWB+awv8S4+ZLeNhdXrvkS213rHYb6ZKuo05CwMp v+bYj44TEBv6X2WLK1zQIOnc/D9dlshDLvasj0woLZ7H4eNBM8tdYD4xMHom14m+fkzH mvg4reezu2uWAwdOf/64wzEAF9z7+eovlNL5G/QTEHKsbWZSgqnmvA/21Dy0xP9XDSMz iWua+pUQf5G54Ef7bhVj9OLKr8GYgw4QLIjn6A2g+egrVkctbDt13M8Dk5xKYqgLUWi+ CosQ== X-Gm-Message-State: AIVw112RLWR4M5eLo85hXpX/cAf1/BgQMmg4XEbCDCHmricE0Hr7zyKc nR2Y0KwtT6ciPPdhny9wXYsVN15QOA== X-Received: by 10.37.76.131 with SMTP id z125mr100077yba.241.1499804608813; Tue, 11 Jul 2017 13:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.203.200 with HTTP; Tue, 11 Jul 2017 13:23:28 -0700 (PDT) In-Reply-To: References: <36a479a8-e22b-f675-7f3d-b7324f872357@netcologne.de> <3db0f7be-b48b-cbd5-c526-7b29c25437d3@charter.net> From: Paul Richard Thomas Date: Tue, 11 Jul 2017 20:23:00 -0000 Message-ID: Subject: Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer To: Thomas Koenig Cc: Jerry DeLisle , "fortran@gcc.gnu.org" , gcc-patches , Damian Rouson , "Bader, Reinhold" Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-07/txt/msg00554.txt.bz2 Hi Jerry and Thomas, As Thomas noted, the span field is added in the middle of the descriptor because the caf token field makes the descriptor variable length. This is reflected in the change in libgfortran.h. It has crossed my mind in the last twenty four hours that I should add some more fields, for example by expanding the dtype field, which would then allow us to bump up the maximum number of dimensions for example. However, I seem, temporarily I hope, to be completely blown out of the water. We had a rainstorm this afternoon, which caused a glitch in the mains. Now, neither of my workstations seem to work any more. I have tried everything but both remain totally unresponsive. As to anything to do with lto, I am sorry but it is beyond my pay grade. I got caught with lto in implementing the submodule patch. I got lucky in that I found the fix more or less by trying things at random. That said, I'll take a look at p68649 once my blood pressure has dropped. It seems to me that the gurus have provided more than enough clues. Regards Paul On 11 July 2017 at 19:12, Thomas Koenig wrote: > Am 11.07.2017 um 16:48 schrieb Jerry DeLisle: > >> Somewhere in the threads on this, there was mentioned ABI breakage/change. > > > That was me. > >> Does it really do this? > > > Yes. Look at this part: > > Index: libgfortran/libgfortran.h > =================================================================== > *** libgfortran/libgfortran.h (revision 250082) > --- libgfortran/libgfortran.h (working copy) > *************** struct {\ > *** 339,344 **** > --- 339,345 ---- > type *base_addr;\ > size_t offset;\ > index_type dtype;\ > + index_type span;\ > descriptor_dimension dim[r];\ > } > >> If the significant change is in the descriptor and you >> just added the span on the end of the structure, I am not convinced this >> is an >> issue. (I have not studied the patch at all, I would rather not bump >> library >> version) > > Unless I am mistaken, we only build the required dimensions for > an array descriptor. Putting it on the end would not work > unless we changed that behavior. > > But we are doing something wrong with the array descriptors anyway. See > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649#c7 for a description. > Other comments in the same PR have some suggestions, but nothing that > works (or so I think). > > So, if we do break the ABI, we could try to fix the remaining > issues with the array descriptors - not with this patch, but > before 8.1 is released. Flexible array members come to mind. > > Regards > > Thomas -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein