From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 0CB2F385840C for ; Mon, 24 Oct 2022 16:23:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0CB2F385840C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666628601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yQlplo0vaSBxkQVGN9qHBXFKM9bIa4wwipPxPAVpvjA=; b=O43C63khIVOMVpeCdQYXKhOykJ3b7Vj1NQe2sA7RK1/ISMS1Ckr1u6mFztQwHSDpfU52ed Dv5b/7EwNbagL/qDnDI1OYM1hIs1gGUT9MoYo4UmkHBb3LP9B0JsJYDQefJ33BQ0e4ZkxJ E7xhRGZEkrakxyIKv2KQQbu2pNlVwBs= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-226-Y2hBPiJCO4myt2MCC0JD5w-1; Mon, 24 Oct 2022 12:23:20 -0400 X-MC-Unique: Y2hBPiJCO4myt2MCC0JD5w-1 Received: by mail-qt1-f197.google.com with SMTP id br5-20020a05622a1e0500b00394c40fee51so7354238qtb.17 for ; Mon, 24 Oct 2022 09:23:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yQlplo0vaSBxkQVGN9qHBXFKM9bIa4wwipPxPAVpvjA=; b=CqJ/QPpdk5CqVQw4ZVbQgKzFPdLBOfBHLHYSNORrueSh9y8CSNZ3uAeTV+tUg7+k6B yw1Gp1bpFJpkSWiSNQHah1X1O2nBZBKX5TPTlBpr/BXV1Bb4UJAyMJbESA1bfbsOnaA5 6WrdymFbAIIO2yblS8HURLYC7bb9O9uz15tqXW4tpJ1ft6J0t6E/bWVJxyuZklNePm9Z pQs1Q1vcxDrPZIugyhg/UVwPM6bMgcpf0c3St0aiASN/RyqJm5tEpNoxgQnlhfsvTDAE uJphNc3LxL07mYpcPtetC1JWq9SWJEPmd44rqMLWO8koKSx8bzmf/GBeq3UrFR6/SOak X89Q== X-Gm-Message-State: ACrzQf1/ZJwJlDPt2+rM+Iy+pI52mqKaHSL7saIC1mxSo85TRHDYK8UQ UpSfr5LPppWKU4EvzU0apXvw+guKiBoqYjkXpSY1oUW8CT8YF+q8KkaZCs9bbbH48y6kOzmexNZ 7UfNfXy4ISEAIreQITdASWA== X-Received: by 2002:a05:622a:30f:b0:39c:ebaa:8268 with SMTP id q15-20020a05622a030f00b0039cebaa8268mr27990580qtw.570.1666628599819; Mon, 24 Oct 2022 09:23:19 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6+t9w5hgkjr2+TsgeubsOOaWpMQGCfg/3K03dEv71WZFnBEQ6/WN4hGz8AUm7ZjDCaMI3quA== X-Received: by 2002:a05:622a:30f:b0:39c:ebaa:8268 with SMTP id q15-20020a05622a030f00b0039cebaa8268mr27990563qtw.570.1666628599416; Mon, 24 Oct 2022 09:23:19 -0700 (PDT) Received: from localhost ([31.111.84.238]) by smtp.gmail.com with ESMTPSA id bz26-20020a05622a1e9a00b0039c7b9522ecsm184613qtb.35.2022.10.24.09.23.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Oct 2022 09:23:19 -0700 (PDT) From: Andrew Burgess To: Tsukasa OI , gdb-patches@sourceware.org Subject: Re: [PATCH 10/10] sim/cris/m32c/sh: disable use of -Werror In-Reply-To: <8b1d6bee-36e6-b859-0950-8e4fa400964a@irq.a4lg.com> References: <42c09bcd56bb7bf0a84d58ffad71894f284b5401.1666192979.git.aburgess@redhat.com> <22060850-e52e-afd7-5828-84b9cc061e31@irq.a4lg.com> <87h6zx9ni4.fsf@redhat.com> <8b1d6bee-36e6-b859-0950-8e4fa400964a@irq.a4lg.com> Date: Mon, 24 Oct 2022 17:23:17 +0100 Message-ID: <87fsfd8a2y.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Tsukasa OI writes: > On 2022/10/22 0:58, Andrew Burgess wrote: >> Tsukasa OI writes: >> >>> Hi Andrew, >>> >>> It's surprising for me that you are working on that! >> >> While I was reviewing your previous clang patches I tried to build the >> sim/ tree with clang, but even with your patches I was hitting a bunch >> of warnings/errors. >> >> I created a set of changes as a fixup so that I could test your patches. >> That is, this started as the set of extra fixes I needed on top of your >> work to get the sim/ tree building with clang (for me). >> >> Once your work was merged I decided, having done this work, I might as >> well split the fixes into separate patches and get them merged. I may >> have expanded slightly by looking at any warnings emitted by gcc as well >> as any other non-fatal warnings from clang, and fixing anything that >> looked easy. >> >>> >>> Based on your branch, I applied one patch (from my upcoming patchset) >>> each time I met an error (until I see no errors) and here's some results >>> (including simple patches to CGEN-generated files): >>> >>> Required additional patches (from my patchset) to Andrew tree: >>> 1. With PATCH 10/10 - Clang 15.0.3 : 16 (+2 for cpu/cris) >>> 2. With PATCH 10/10 - Clang 15.0.0 : 19 (+2 for cpu/cris) >>> 3. W/O PATCH 10/10 - Clang 15.0.3 : 20 (+2 for cpu/cris) >>> 4. W/O PATCH 10/10 - Clang 15.0.0 : 23 (+2 for cpu/cris) >> >> Yeah, my version of clang is somewhat older than that (9.x !) >> >>> c.f. >>> 1. >>> >>> 2. >>> >>> 3. >>> >>> 4. >>> >>> >>> Environment: >>> - Ubuntu 22.04.1 LTS >>> - LLVM + Clang 15.0.0 (built from git source; primary) >>> - LLVM + Clang 15.0.3 (built from git source; secondary) >>> >>> And... my tree (alone with my changes) failed on Clang 15.0.0 but >>> succeeded on Clang 15.0.1. That is because >>> -Wimplicit-function-declaration was default-error on 15.0.0 but >>> downgraded to default-warning on 15.0.1. All error messages generated >>> by Clang 15.0.0 makes sense so I'll continue using Clang 15.0.0 as a >>> reference. >>> >>> c.f. >>> >>> >>> Thanks to your PATCH 09/10, I could build my working tree with Clang >>> except M32R simulator with Clang 15.0.0. Not only that, I could figure >>> out how to make M32R simulator (sort of) work. For CRIS and SuperH, I >>> can provide cleaner solution without disabling -Werror (at least on my >>> environment). >> >> Yes please. The disable -Werror isn't a final resting place, its more >> just a stopping point so we can have something that builds - though I >> think what you're saying above is that with later versions of clang >> things still don't build, which is a shame. >> >>> >>> My Current Tree (to be submitted as a RFC PATCH) is available at: >>> >>> >>> My initial plan was to split it to smaller patchsets and submit each >>> ones periodically but... it seems submitting all at once seems syncing / >>> reviewing my and your work easier. I'll submit a RFC patchset >>> consisting of 40 or 41 patches in total. >> >> It's not clear to me if any of my patches above conflict significantly >> with patches you have. >> >> If there are any of the above that are a problem, then just let me know >> and I wont merge them. >> >> I don't have any plans to do anything more on this in the immediate >> future, like I said, with the tools I have to hand right now the sim >> tree now builds fine. >> >> I have added revisiting cris/m32c/sh to my todo list, but I doubt that >> will get looked at before 2023, and it sounds like you might have a >> solution before then - which would be nice :) >> >> Ideally, I'd like to push any of the above patches that don't actively >> make your life harder, I'll drop anything that is a problem for you. >> And then look forward to your incoming fixes. >> >> Let me know, >> >> Thanks, >> Andrew > > c.f.: my related patchset > > > > Well... I just submitted my draft RFC PATCH (misnamed [PATCH] though) to > sync and discuss with your current/future work. I knew it will take > some time (**did** take some time) to investigate Clang issues and I > don't want I and you to avoid redoing each other's work. > > I almost support your patchset (as I describe below). > > TL;DR: > I support merging your ten patches except PATCH 04,07,10/10. Although I > personally don't like to write a patch like PATCH 10/10, it might be a > good short-term solution for now (I don't object like PATCH 04,07/10). > > Each review to your patchset is as follows: > [+] : Positive > [-] : Negative > > PATCH 01/10: [+] > Corresponds to my PATCH 36/40. I'll withdraw my one. > PATCH 02/10: [+] > Corresponds to my PATCH 30/40. I'll withdraw my one. > PATCH 03/10: [+] > Corresponds to my PATCH 28/40. Although my PATCH 28/40 is a bit > simpler, your patch is easy to understand and I feel this is OK > to me. > PATCH 04/10: [-] > Corresponds to my PATCH 31/40. I prefer my solution (to > initialize help with {0}). > PATCH 05/10: [+] > Corresponds (but very different) to my PATCH 27/40. > I chose to keep the semantics as in the original source code but > it seems it keeps the bug in this place. Andrew's fixes that bug > (I think) and I prefer Andrew's one. > PATCH 06/10: [+] > Corresponds to my PATCH 03/40. I'll withdraw my one. > PATCH 07/10: [-] > Corresponds to my PATCH 34/40. Although this function is currently > unused, I prefer to keep this function (with ATTRIBUTE_UNUSED) > for now. We don't generally keep dead code around, it's always possible to pull things back from git if needed. Before I push patch #7 I thought I'd ask why you wanted to keep this, but were OK with patch #6. Thanks, Andrew