From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118427 invoked by alias); 27 Jan 2018 10:24:34 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 118402 invoked by uid 89); 27 Jan 2018 10:24:33 -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_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=8gb, 8GB X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yb0-f177.google.com Received: from mail-yb0-f177.google.com (HELO mail-yb0-f177.google.com) (209.85.213.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 27 Jan 2018 10:24:31 +0000 Received: by mail-yb0-f177.google.com with SMTP id h9so1105821ybg.10; Sat, 27 Jan 2018 02:24:31 -0800 (PST) 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=9PNq8DUxv+WZat2fPxAlCkOfID6iW2asXHwjtOp9X1M=; b=XDETyOmB+h7Rrp5APx24y7ynJfi6lU/MZlgelqcPEuCtbTbi6CGG6jmnv5kwoZ327m 1NXZTU86tpoOPPu0V0oRIV8tfMbFGAjaJ+nlN83D90wZG9WAYCB4szz46A8t8xo0E605 zIGgL1kes8AVs6Zntc6/rILMMDD50+fRc6o9DMfsd7rQnp0XVOic3aKc4ruIwF6Mmt/N jmTiFpXx9ltapyzfdlNWdNkHkzJIOvmFszLZniQn6JO8Cb73Y50yTWm+t2hNKVYgRKTg xG/9usrFlHj0GDV85/Fa1rDuehUB81C6MGFKANlWby/lSrvO8CyVmfefKDdHfTy8iIXQ O1Pw== X-Gm-Message-State: AKwxyteq+MutiemlDr1euNP9bQjrCAK7VoInryfb4X4r4a+sesFlbsyo bU+0FkaChNd/HhEYBFAr4qkZM3Gfrn+Mzrj/mSw= X-Google-Smtp-Source: AH8x224IzWiUEFsJKXyTPlip8FltbHdfQmNGn77DE8JnLQo92ssQEaXbXMi6SySHZqgmqA7nGvAL0M9muW8Y9B7sue8= X-Received: by 10.37.201.196 with SMTP id z187mr13164911ybf.250.1517048670258; Sat, 27 Jan 2018 02:24:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.241.4 with HTTP; Sat, 27 Jan 2018 02:24:29 -0800 (PST) In-Reply-To: <20180126232101.GE2063@tucnak> References: <20180126232101.GE2063@tucnak> From: Janne Blomqvist Date: Sat, 27 Jan 2018 10:24:00 -0000 Message-ID: Subject: Re: [PATCH] Avoid creating >= 8GB EXPR_CONSTANT initializers for ilp32 targets (PR fortran/84065) To: Jakub Jelinek Cc: GCC Patches , Fortran List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00193.txt.bz2 On Sat, Jan 27, 2018 at 1:21 AM, Jakub Jelinek wrote: > Hi! > > resolve_charlen is going to error on ilp32 target charlens above what > can fit into 32-bit signed int, but add_init_expr_to_sym is done before > resolve_charlen, allocating huge amounts of memory in those cases > when we'll error later is just waste of compile time if running on 64-bit > host with enough memory, or will unnecessarily ICE due to out of memory > otherwise. > > Another option would be to emit the error resolve_charlen is going to > emit and arrange for it not to be emitted afterwards, this just seemed > to be easier. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Ok, thanks. > It would be nice if the FE had some way to express very large repetitive > EXPR_CONSTANT more efficiently, say by not allocating the memory for > the rest which is filled only by ' ', or by allowing to say this and this > is repeated after the initial portion this many times. Yes, we probably want to give up on populating large objects at compile-time long before we hit the 2 GB limit. For some cases this works already, for others it doesn't.. -- Janne Blomqvist