From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2585 invoked by alias); 22 May 2017 16:19:13 -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 2557 invoked by uid 89); 22 May 2017 16:19:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 May 2017 16:19:11 +0000 Received: by mail-wm0-f48.google.com with SMTP id e127so673816wmg.1 for ; Mon, 22 May 2017 09:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=evuwkghpY02jqc8z2oTuu0jcq/c4lvZs5NvhO3bC59M=; b=ioEciZU2O8ifs4yQgNiApHHKyRsfKRHm1QQtIKc4BDInE6rbj99OwykcbcBdG6mBkb 3TY3vsFDZOHaWl7CPoDArGUajwEmrpyKxo6NY1ddFZpWVEebzmfAUlCl14VemUnlWRYk eZ/uzZpIr3hM1w4cRcMBdHFMn2h9XSpn+O0NdjS9meLLppJSJCzbcAKnVU5Ywew4s7oE 5iCZUCUBLopqXgSmRS8gCanDPQ0kRlPpqbqCmNEVOyLAQmizDpEvnE2czfRLc+rcqbfk Q1GAIhl5srHAAOidoSlAQTsO/gGImSap4MbEqGe08F1NfzNYaeyLbJa4xACtWM2eLuLp UkDw== X-Gm-Message-State: AODbwcA5s6x9h8eNvt0vvdL/g6sj6/DQuGA9YyYM0PSkLzSJBNqCKlhW gn/ZZmfNLSWnxc/9 X-Received: by 10.28.167.197 with SMTP id q188mr25273834wme.79.1495469952364; Mon, 22 May 2017 09:19:12 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id 17sm24428878wml.32.2017.05.22.09.19.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 09:19:11 -0700 (PDT) Subject: Re: MinGW compilation warnings in libiberty's xstrndup.c To: DJ Delorie References: Cc: eliz@gnu.org, gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, richard.guenther@gmail.com, thomas@codesourcery.com From: Pedro Alves Message-ID: Date: Mon, 22 May 2017 16:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg01686.txt.bz2 On 05/20/2017 01:38 AM, DJ Delorie wrote: > > Pedro Alves writes: >> Ah, yeah. AFAICS, all the declaration checks in libiberty.h are >> HAVE_DECL checks. This suggests to me that this declaration guard >> should be HAVE_DECL too [1]. > > Except the ones in the $funcs list, which includes strnlen. I think in > the old days, we didn't put in declarations at all... until "char *" > became a different size than "int" and we started needing them. Running: $ grep HAVE_ libiberty/config.h | sed 's/DECL_//g'| sort | uniq -c | sort -n on the build I have handy shows: ... 2 #define HAVE_ASPRINTF 1 2 #define HAVE_BASENAME 1 2 #define HAVE_CALLOC 1 2 #define HAVE_FFS 1 2 #define HAVE_SBRK 1 2 #define HAVE_SNPRINTF 1 2 #define HAVE_STRTOL 1 2 #define HAVE_STRTOLL 1 2 #define HAVE_STRTOUL 1 2 #define HAVE_STRTOULL 1 2 #define HAVE_STRVERSCMP 1 2 #define HAVE_VASPRINTF 1 "2" means above means each FOO symbol above has both HAVE_FOO and HAVE_DECL_FOO defines: $ grep "HAVE.*_SNPRINTF" config.h #define HAVE_DECL_SNPRINTF 1 #define HAVE_SNPRINTF 1 > > So some functions in libiberty are HAVE_DECL and others are still HAVE. But I don't see any HAVE check in libiberty.h (for function symbols), only HAVE_DECL ones: $ grep HAVE libiberty.h /* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is #if !HAVE_DECL_BASENAME || defined (__DragonFly__) || defined (HAVE_DECL_BASENAME) autoconf which would result in HAVE_DECL_BASENAME being set. */ #if defined (HAVE_DECL_FFS) && !HAVE_DECL_FFS #if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF #if !HAVE_DECL_VASPRINTF #if defined(HAVE_DECL_SNPRINTF) && !HAVE_DECL_SNPRINTF #if defined(HAVE_DECL_VSNPRINTF) && !HAVE_DECL_VSNPRINTF #if defined (HAVE_DECL_STRNLEN) && !HAVE_DECL_STRNLEN #if defined(HAVE_DECL_STRVERSCMP) && !HAVE_DECL_STRVERSCMP #if defined(HAVE_DECL_STRTOL) && !HAVE_DECL_STRTOL #if defined(HAVE_DECL_STRTOUL) && !HAVE_DECL_STRTOUL #if defined(HAVE_LONG_LONG) && defined(HAVE_DECL_STRTOLL) && !HAVE_DECL_STRTOLL #if defined(HAVE_LONG_LONG) && defined(HAVE_DECL_STRTOULL) && !HAVE_DECL_STRTOULL #if defined(HAVE_DECL_STRVERSCMP) && !HAVE_DECL_STRVERSCMP Nor in other headers under include/, while at it. Are you looking elsewhere perhaps? Based on the above, it looks to me like the non-HAVE_DECL HAVE symbols are implementation detail to libiberty, side effect of the checks used to determine whether a replacement is necessary. > > Ah, found it, this commit is incomplete: > > https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00784.html > > It changes gcc's configure but nobody else's (and now we have an answer > to the three-year-old question "why don't we have a more liberal commit > policy?" ;) which breaks both libiberty and libgfortran. Yeah, that exactly the sort of thing that gets fixed by design by having a centralized libiberty.m4 file. > >> BTW, I once proposed a new libiberty.m4 file that all libiberty >> clients would source so that these checks are all centralized. > > I have no philosophical problem with that type of change, but I have the > usual fear of touching anything in libiberty that's been around this > long ;-) > > (this bug being a prime example of how subtle an incorrect change can be) > > (and honestly, my upstream attention is elsewhere these days) > Thanks, Pedro Alves