From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 260D91F8C6 for ; Fri, 30 Jul 2021 16:53:51 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 355473951CB5 for ; Fri, 30 Jul 2021 16:53:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 355473951CB5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1627664030; bh=Fx8EDELsc6OMnqHjVxPVX3HLC36Uy0XU36eFofyE5gI=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=MsSCQWtVTCTDkjRca2n6S8bM5KuE5FKZRvQrJb9c142yl/fgvxHzMGAnte2em58W0 WxjlfCk098HHnf6WSX1kTR9eAi6V6vYC9RP1bFXMZ3UDjhP25lUuB91vJqi4kWgWD0 NAx5AFnSg4Os17qjBjtpwoPuZopZnSCNe9JygVKo= Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by sourceware.org (Postfix) with ESMTPS id 06F373951E5E for ; Fri, 30 Jul 2021 16:53:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 06F373951E5E Received: by mail-qt1-x834.google.com with SMTP id m11so6849902qtx.7 for ; Fri, 30 Jul 2021 09:53: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:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Fx8EDELsc6OMnqHjVxPVX3HLC36Uy0XU36eFofyE5gI=; b=e2FdLNwnN6TlZebglNfSDUZg3QclkxM4Jl/pS/xs1ROkQGc/puCwx/8xkBAbAUmODu gsbvkT7Bh6S0DNcZxKAICDyiVF58GvX4EwtpCS0dh80KW6sghCV18s84OIxPQFIeKSRL q8WQ4G8DQBJTfqR4aqAc+tWqlihfTiE19lBNVSx4M1/kZW763fConxNMhhp6K7wP0tC6 UOwbVi7SC19Uqj4TJWim5oubnM3Dbq/3WMMIUp9o5UZzmgvwDwRIMHHkH0dMkSYDzZjA zUNV5s9NKncXPsuKvkfNLe0bidFUsPRgXXxYKnlaf2Z+1KeWEAPNK+ddT+8apyPQeMjZ +X8Q== X-Gm-Message-State: AOAM531SvCskTSATmZfrzYUrD47iJRAkIua1+r7NP47LnRSVyjbzZnmG 0/iac8AFKKPgAsOzdniHJxw= X-Google-Smtp-Source: ABdhPJwdQqdtr5LS1PexOX8oY7sCRl9Gs2kJ2iRhXi2VpO2dcd+WkrjZhuVBSjCXs+vupziEdqG7Cg== X-Received: by 2002:ac8:57c4:: with SMTP id w4mr3086295qta.39.1627664009702; Fri, 30 Jul 2021 09:53:29 -0700 (PDT) Received: from [192.168.0.41] (75-166-102-22.hlrn.qwest.net. [75.166.102.22]) by smtp.gmail.com with ESMTPSA id n13sm808768qtx.92.2021.07.30.09.53.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jul 2021 09:53:29 -0700 (PDT) Subject: Re: Failures building glibc with mainline GCC To: Joseph Myers , libc-alpha@sourceware.org, gcc@gcc.gnu.org References: Message-ID: <1bcf4c26-1619-06fa-fd8d-4e944ac6f07a@gmail.com> Date: Fri, 30 Jul 2021 10:53:28 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Martin Sebor via Libc-alpha Reply-To: Martin Sebor Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 7/30/21 9:30 AM, Joseph Myers wrote: > There are a lot of failures building glibc with mainline GCC right now > > (previously, there were ICEs building glibc on various architectures, so > these might be hard to bisect): > > > * x86_64-linux-gnu: "error: array subscript 0 is outside array bounds of > '__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds]". This is > the one discussed in > . I submitted a patch for this warning to Glibc: https://sourceware.org/pipermail/libc-alpha/2021-July/128829.html which is what ultimately precipitated Florian's question. If null pointers to named address spaces are valid I'll adjust GCC to avoid the warning for now (as has been discussed, for GCC 12 I'd like to redo the logic to detect the problematic null pointer arithmetic instead). I haven't seen the rest of the warnings in my tests but the uninit one could be due to the interaction of the recent threader changes and a -Wuninitialized enhancement I committed earlier this week that I didn't test with the new threader (but did with Glibc with no new warnings). I'll look into the warnings if I can quickly reproduce them with a native x86_64-linux build or get the translation units for other targets. Martin > > In file included from ../sysdeps/generic/libc-tsd.h:44, > from ../include/../locale/localeinfo.h:224, > from ../include/ctype.h:26, > from loadmsgcat.c:29: > loadmsgcat.c: In function '_nl_load_domain': > ../sysdeps/x86_64/nptl/tls.h:185:4: error: array subscript 0 is outside array bounds of '__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds] > 185 | (*(struct pthread *__seg_fs *) offsetof (struct pthread, header.self)) > | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ../sysdeps/nptl/libc-lock.h:92:18: note: in expansion of macro 'THREAD_SELF' > 92 | void *self = THREAD_SELF; \ > | ^~~~~~~~~~~ > loadmsgcat.c:770:3: note: in expansion of macro '__libc_lock_lock_recursive' > 770 | __libc_lock_lock_recursive (lock); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > > * i686-gnu: > > hurdselect.c: In function '_hurd_select': > hurdselect.c:555:7: error: 'ss' may be used uninitialized in this function [-Werror=maybe-uninitialized] > 555 | _hurd_sigstate_unlock (ss); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > As far as I can tell, this is a false positive from the compiler (this > code is only reached if (sigport != MACH_PORT_NULL), in which case ss has > been initialized). > > > * Several architectures (all of them 32-bit), powerpc-linux-gnu for > example: > > In file included from t.61.c:437: > In function 'from_t_61_single', > inlined from 'gconv' at ../iconv/skeleton.c:568:15: > ../iconv/loop.c:440:22: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] > 440 | bytebuf[inlen++] = *inptr++; > | ~~~~~~~~~~~~~~~~~^~~~~~~~~~ > ../iconv/loop.c: In function 'gconv': > ../iconv/loop.c:382:17: note: at offset 2 into destination object 'bytebuf' of size 2 > 382 | unsigned char bytebuf[MAX_NEEDED_INPUT]; > | ^~~~~~~ > > I don't know if this is a false positive or not. > > > * powerpc64-linux-gnu: > > In file included from ../sysdeps/powerpc/dl-tls.c:20: > In function '_dl_allocate_tls_init', > inlined from '_dl_allocate_tls' at ../elf/dl-tls.c:621:10: > ../elf/dl-tls.c:529:10: error: array subscript -1 is outside array bounds of 'void[9223372036854775807]' [-Werror=array-bounds] > 529 | dtv_t *dtv = GET_DTV (result); > | ^~~ > In file included from ../elf/dl-tls.c:28, > from ../sysdeps/powerpc/dl-tls.c:20: > ../sysdeps/powerpc/nptl/tls.h:136:34: error: array subscript -1 is outside array bounds of 'void[9223372036854775807]' [-Werror=array-bounds] > 136 | ((tcbhead_t *) (tcbp))[-1].dtv = dtvp + 1 > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ > ../elf/dl-tls.c:544:7: note: in expansion of macro 'INSTALL_DTV' > 544 | INSTALL_DTV (result, &dtv[-1]); > | ^~~~~~~~~~~ > > > * powerpc64le-linux-gnu: "error: '-mabi=ibmlongdouble' requires > '-mlong-double-128'". See > . > >