From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 3F1873858D20 for ; Tue, 15 Feb 2022 15:20:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F1873858D20 Received: by mail-wr1-x42d.google.com with SMTP id d27so28921207wrb.5 for ; Tue, 15 Feb 2022 07:20:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tWn/L/j5LF6FZOC0vUSS5yXZDRLbllwQbLbgmiI4v2A=; b=XX4F6hkV91X6Jsw09l9mLvyfABWVaGMk6ltZqHJEkocz33jt9Vli2YqLzae+5Wg6e6 q16+VGJd8s9Wvxbm7CjN+4F2/6IqByoug4i2dudvLcIjeuC/YP5aLzBjeDlogqOuDWS/ My/2vb0NhZkSQv0NEjVEyR6EZjU0a5o40Qqf+crATr5c4T7S4nUdh0D/5+P2QXzfEXgt juK2g8jOSt323ohLFRDODb7cZR9xp5NWqfleHa7x+QmRikylQd9r0VkRuA/sDSiU04Oa nZIdWdJJWUEXmZMsddwZp+7PV3api04I476kaspyvu/RwsHyyPFS0L7/ff7CnZkjBcvS 99Jw== X-Gm-Message-State: AOAM533h7YOsmfcqrKjOcmMbW5FCd2k+gHyQgpTrb5CrEwoOO3Mp8rpE ucOmA/OYuTOYNyGGrEQGDvmNc1hIjmLe1K/0E+w= X-Google-Smtp-Source: ABdhPJzyE6arpKzRL7PpM2uU3tZo7MP48y+IVX7EGIwj9GX/lZo87s0lUBaTj9BqxTrwa1X61APg9EPCmri8mkdHfX4= X-Received: by 2002:a05:6000:1a51:: with SMTP id t17mr3635831wry.102.1644938450207; Tue, 15 Feb 2022 07:20:50 -0800 (PST) MIME-Version: 1.0 References: <27d907087416c330d59ce78dce522fd26a5d712e.camel@redhat.com> In-Reply-To: <27d907087416c330d59ce78dce522fd26a5d712e.camel@redhat.com> From: Jonathan Wakely Date: Tue, 15 Feb 2022 15:20:38 +0000 Message-ID: Subject: Re: Request easy bug fix To: David Malcolm Cc: Baruch Burstein , "gcc@gcc.gnu.org" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 15 Feb 2022 15:20:54 -0000 On Tue, 15 Feb 2022 at 13:58, David Malcolm wrote: > On Tue, 2022-02-15 at 12:55 +0000, Jonathan Wakely via Gcc wrote: > > On Tue, 15 Feb 2022 at 12:34, Baruch Burstein via Gcc < > > gcc@gcc.gnu.org> > > wrote: > > > > > Hi, > > > > > > I hope it is not inappropriate to call attention to a specific bug. > > > https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85487. > > > I tried to do it myself, but got lost on the part where I needed to > > > compile gcc 3 times and compare test results to some (un)known test > > > results. > > Thanks for trying to fix the bug. > > > > > > > You compare the test results of your patched gcc to the test results > > of an > > unpatched gcc. > > > > How did you get lost? To "compile gcc 3 times" you just run "make", > > and it > > does that automatically (unless you configured with --disable- > > bootstrap, in > > which case it just compiles once). > > Jonathan, if I may: you're extremely familiar with hacking on GCC, and > I think that familiarity is leading you to underestimate the learning > curve for someone new getting involved in GCC development. > > As you say, --disable-bootstrap is the configure-time option to use > when working on a new patch, since it avoids the "compile 3 times" > cycle. We could probably document that better. > Agreed. So it would help to know which docs Baruch was looking at when getting lost. There's no point adding *more* docs if we already have some that are doing more harm than good. > > > > > > > > It was too much time and setup for a fix that will probably > > > take 2 minutes to implement, so I am asking if someone that already > > > contributes to gcc can please look at this. I think it should only > > > take a couple of minutes to implement. > > Baruch: here you are underestimating the time that adding a new feature > takes; yes, it perhaps could take about 2 minutes to get a minimal > proof-of-concept working, but once you start adding documentation, > test-cases, etc it becomes more than that. Also, looking at the > discussion now happening in the bug report, it's not clear that the > absolute minimum implementation is the correct one > > I'm guessing that you care because you're working in a mixed Visual > Studio/GCC environment, and have a codebase with these pragmas. > Does Visual Studio complain about mismatches, or incorrect nesting? > If so, can you give some more information about these interoperability > issues being discussed in the bug report? > (I used to work in such an environment, but that was over 20 years ago; > my knowledge of Visual Studio is *very* out of date, sorry) > Clang and the MSVC compiler both ignore any tokens after the pragma, so that seems good enough for GCC too: https://godbolt.org/z/norv947a5