From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 34E20384A40A; Wed, 6 Jan 2021 19:11:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 34E20384A40A Received: by mail-wr1-x42b.google.com with SMTP id r3so3412569wrt.2; Wed, 06 Jan 2021 11:11:20 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PIK0ACHBjPuepcgHJm1Ddgy1jy5QdgCnezKqDKUGJFI=; b=OQNXUOts3ZDjXs+HZ5HDzA0KrSgMqilc37315DUChstoGLBALivXxyCn8KFcZbqcqa xuwzlsaNKyrtoJxfL5E1tMIulqv6dskl8zBUAna9Gj9jsVELjLPoXc2KVqCxxBwMbugo JMLmSy5114QPJVjMk42c48BxhzPsflcacs2fquNBAbhdNaMsu45pmgzpyPSeo9BWpZWk npTSQfdpxYos8pARPbUhiauTLjpdTQhl7KS2EMymbwfbQ7lzLCKnfxy0iUy+ZZVNchYk 5ZdXDoKdSAHzr4cBSJVgrfYi9tqE6tLWSn2fJtQzGpdbEl64H6ffqcWILzoXyeDe1WEG 3i4Q== X-Gm-Message-State: AOAM533Exjod/a++RMkT0MgH2nyrJRriZ2hQzSgTmwi7Ya5a8Wye0kO4 qMZ2UPVyy9n2pGKx4f6na/rAVHlelo+HingJDnbDNMyF X-Google-Smtp-Source: ABdhPJwSNHKZnndl3s/ZZdDL8HcVX2QLC5flkzXktU0hnmUk1eHcs9GCOSu3bXO8Xb+5JjsUVoFltX53/sliLF5pMgA= X-Received: by 2002:a5d:6cc2:: with SMTP id c2mr5563502wrc.374.1609960278980; Wed, 06 Jan 2021 11:11:18 -0800 (PST) MIME-Version: 1.0 References: <82157de3-8afb-48a-44be-a8b38a7d7e44@stedding.saclay.inria.fr> In-Reply-To: <82157de3-8afb-48a-44be-a8b38a7d7e44@stedding.saclay.inria.fr> From: David Edelsohn Date: Wed, 6 Jan 2021 14:11:06 -0500 Message-ID: Subject: Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T To: "libstdc++" Cc: Jonathan Wakely , Iain Sandoe , GCC Patches , "CHIGOT, CLEMENT" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 19:11:21 -0000 On Wed, Jan 6, 2021 at 1:55 PM Marc Glisse wrote: > > On Wed, 6 Jan 2021, David Edelsohn via Gcc-patches wrote: > > > Currently the type of streamoff is determined at libstdc++ configure > > time, chosen by the definitions of _GLIBCXX_HAVE_INT64_T_LONG and > > _GLIBCXX_HAVE_INT64_T_LONG_LONG. For a multilib configuration, the > > difference is encoded in the different multilib header file paths. > > For "FAT" library targets that package 32 bit and 64 bit libraries > > together, G++ also expects a single header file directory hierarchy, > > causing an incorrect value for streamoff in some situations. > > Shouldn't we change that? I don't see why using the same directory for > linking should imply using the same directory for includes. First, the search path assumption is rather strongly embedded in the GCC driver in somewhat delicate code. There already is a lot of fragile, complicated processing for multilibs and search paths and exception. It is more risky, both in the potential new search logic and in possible breakage, to perform surgery on the multilib support code. Second, it's confusing and error-prone to have different search behavior for different parts of the compiler until we can completely remove multilib headers. Third, there is no inherent reason that the header files should be multilib-dependent. I'm not trying to boil the ocean and remove all multilib differences in headers. I'm trying to solve specific issues caused by the differences in header files that also happen to move GCC in a direction of less multilib differences encoded in header files, which I think is a GOOD THING[tm]. Thanks, David