From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 99CED3858004 for ; Sat, 3 Apr 2021 21:12:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 99CED3858004 Received: by mail-wm1-x332.google.com with SMTP id p19so4003131wmq.1 for ; Sat, 03 Apr 2021 14:12:40 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tUrb3kEm9ngf3DXI+q/ma6/SEI8Xk8MRxx+0Q/TBshE=; b=EzHqzLWqvqi7uaHUIbfB3G0DqeQ/6c2Kw6MycKYFrYCF4p7RQmDMYAGyvabhGmnmiv k0tximfU+xGQ8mq+p2LZ/pBhLGKwA3rwox2UPt1SayVSvX4ftl4XzDpF1k62ik0xcgZk czKApJILmBcZiwzuGF3TZVJ6wpuQy63KYB3xJ6Tf/c1iyruE2hC7gk6Kk3ZY+IkoIOgO gfWlrsmqm6Th+ZqCBw+0+GalDtjO9HeFoUTi0dyXiwzySWgzuSPySQqMQvLj6304aKCD Vc1zE3RJ/DAHuYFRczUFEQkr8glqW6evaWgzMmKh175/pDk4DAVHNcj4cqW3zj1YcZSF CO/Q== X-Gm-Message-State: AOAM533Hvg52Kyv3ctGeYy7+kZjEtxfaEnYPRqwni+p57Zq4FFTOx+I+ dZbVDNdQsJatMTX45wHGf9s= X-Google-Smtp-Source: ABdhPJxlRzrZ6cnWl7iwG90zoZC4EuPAmxnT64zAY/Q2IxphueZalyhezZqtpnp1NkaxVqZDwbEvlQ== X-Received: by 2002:a05:600c:4f8e:: with SMTP id n14mr19008662wmq.166.1617484359623; Sat, 03 Apr 2021 14:12:39 -0700 (PDT) Received: from [192.168.1.100] (dsl-multi-static-81-140-129-201.in-addr.broadbandscope.com. [81.140.129.201]) by smtp.gmail.com with ESMTPSA id m11sm20664419wri.44.2021.04.03.14.12.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Apr 2021 14:12:39 -0700 (PDT) Subject: Re: GCC 10.3 Release Candidate available from gcc.gnu.org To: Iain Sandoe , Jonathan Wakely Cc: "gcc@gcc.gnu.org" , Richard Biener References: <8F282F9C-23B0-4810-9D9C-0BACDD6C9BCB@googlemail.com> From: Richard Copley Message-ID: Date: Sat, 3 Apr 2021 22:12:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <8F282F9C-23B0-4810-9D9C-0BACDD6C9BCB@googlemail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2021 21:12:42 -0000 On 03/04/2021 13:25, Iain Sandoe wrote: > Jonathan Wakely via Gcc wrote: > >> On Sat, 3 Apr 2021 at 00:53, Richard Copley via Gcc >> wrote: >>> On 01/04/2021 13:35, Richard Biener wrote: >>>> The first release candidate for GCC 10.3 is available from >>>> >>>>  https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ >>>>  ftp://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ >>>> >>>> and shortly its mirrors.  It has been generated from git commit >>>> 892024d4af83b258801ff7484bf28f0cf1a1a999. >>>> >>>> I have so far bootstrapped and tested the release candidate on >>>> x86_64-linux.  Please test it and report any issues to bugzilla. >>>> >>>> If all goes well, I'd like to release 10.3 on Thursday, April 8th. >>> >>> On Windows, linking two C++ translation units that both #include >>> results in errors about multiple definition of the weak >>> function __dummy_resume_destroy. This can be avoided by cherry-picking >>> commit 94fd05f1f76faca9dc9033b55d44c960155d38e9 [PR 95917]. >> >> That problem is already present in GCC 10.2, right? Right, yes. >> I didn't backport that because it's an ABI change, so not appropriate >> to change between minor releases (even for an experimental feature >> like coroutines). PR 95917 was about suboptimal codegen; nobody >> reported that there's a multiple definition error on Windows. Yeah. This just happens to be the time I first came across the problem. I know I should have started with a bug report on bugzilla, but I thought I'd chance my arm. > That agrees with my recollection - the entity was marked as ‘weak’ so that > there should only be one instance in a linked exe.  However, that did lead > to a complaint that object files then contained the weak entity any time > the > coroutine header was included. > > Is there something more needed to support weak definitions for Windows? Maybe! I don't know though -- the description of weak definitions in the documentation doesn't seem to imply that multiple weak definitions are allowed. Forgive me if I misunderstood. >> I don’t think we should fix this for 10.3, but please report it to >> bugzilla >> and we can look into a fix for 10.4 (maybe with something specific to >> Windows). > > +1 Yes, I don't see any big urgency! I will construct a bugzilla report. Maybe the downstreams will decide to do something in the meantime (e.g., my PR at MINGW-packeges [1]). [1] https://github.com/msys2/MINGW-packages/pull/8263