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 46E363858D28 for ; Sun, 30 Jan 2022 18:59:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46E363858D28 Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-168-4_dVE1tfO5KmghNBEI-Bqg-1; Sun, 30 Jan 2022 13:59:12 -0500 X-MC-Unique: 4_dVE1tfO5KmghNBEI-Bqg-1 Received: by mail-qk1-f200.google.com with SMTP id n3-20020ae9c303000000b00477e4f3dfd2so8043225qkg.21 for ; Sun, 30 Jan 2022 10:59:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=p+fjQLQbVpHSKWMSlGTLteWyheAZrxq8rLjbJJN35Cg=; b=ATRaTdg07Hz2ujkNRuwc4yc3wCVVob0nsfV7e1CpYmIS3QAgLKUxu3DMz4F4b36d58 sj8F4mRonh7VkDtGHlIJgM8jlNBpwtOLsrk/1Zse9hKcSFxiIzTOtA1kdn9MxGTS2RJ0 sRzPYyJD0aRVykOCrwL1WOuSBex9p/dn+ruW7zpZsMAMIeygofqH/YBAk03lEdclQa6f CzUJYPRU73Ub6MHALp0Jc2c+beHS5hvOrn/gJ9nzxoQFQwYdMW9k3Iok8K6My+tu9Afy T2FPq8qqWB1EDNFrvPdRKrDSXegn3ewqfwSgi9R3OV6lMwhwkgZhu+vYlE6uXp+5F0Or PIKQ== X-Gm-Message-State: AOAM530vAd0DwdkQ8exy4aC8ktEBsV39WPY2dhFwOPmUTm0xEZNwPzBg xkZB8t+40Od0Cadh3Wn0L6YqHgGaPQXDkAMYHIpCstIwSDRPxJKMuKPGSyu5YjMkX5p/B2rJPbm wdz6S6GE= X-Received: by 2002:a05:620a:d84:: with SMTP id q4mr11511748qkl.200.1643569151446; Sun, 30 Jan 2022 10:59:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJzyt9Y5NrZ9eGnGC3CMNJRngz04Sv319Xt+TcmdIfyfYpdx/oWMhEa4tF+Zwxc5bfVOZzbToA== X-Received: by 2002:a05:620a:d84:: with SMTP id q4mr11511744qkl.200.1643569151187; Sun, 30 Jan 2022 10:59:11 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id h5sm5767222qti.95.2022.01.30.10.59.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Jan 2022 10:59:10 -0800 (PST) Message-ID: <1022f2067c88acf4d708f9a8b7793b57168c74a9.camel@redhat.com> Subject: Re: Bisecting From: David Malcolm To: Jonathan Wakely , =?ISO-8859-1?Q?S=F8ren?= Holm Cc: "gcc@gcc.gnu.org" Date: Sun, 30 Jan 2022 13:59:09 -0500 In-Reply-To: References: <30d4a81d-5974-2551-185e-cb18acb4f2b8@sgh.dk> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 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: Sun, 30 Jan 2022 18:59:16 -0000 On Sun, 2022-01-30 at 01:09 +0000, Jonathan Wakely via Gcc wrote: > On Sat, 29 Jan 2022, 20:25 Søren Holm via Gcc, wrote: > > > Hi > > > > I believe I have found some kind of bug in GCC. The target is a > > cortex-m7 CPU. I do not have an isolated test software so I'm > > thinking > > of bisecting GCC between GCC 9.4 and 10.1. > > > > Are there any easy way do do a fast "change - compile - test"- cycle > > - > > and how do I do that? All the guide on building GCC is using huge > > scripts with installs and such. I'm sure the main developers does not > > do > > that. > > > > > > https://gcc.gnu.org/wiki/InstallingGCC is not a huge script, it's a > very > small number of commands. > > You can use git bisect to simplify things, but if you don't have a > small > reproducer for the problem then I don't see how you can avoid doing a > full > build and install. With a simple reproducer, you can just great using > the > cc1 or cc1plus binary in the build tree, without installing anything. > Indeed: try to come up with a minimal reproducer demonstrating the issue (or its absence) deterministically, one that involves a simple invocation of cc1 (or cc1plus if C++). Some tips for speeding builds up: * configure gcc with --disable-bootstrap * configure gcc with --enable-languages containing just the languages you need * you may be able to get away with just "make cc1" in the BUILDDIR/gcc subdirectory each time; you might need to rebuild BUILDDIR/libcpp sometimes though, since the API/ABI exposed by BUILDDIR/libcpp to BUILDDIR/gcc/cc1 changes in some commits * do the build on a machine with plenty of cores and use an appropriate -j option to "make" Might be an idea to configure with --enable-checking=debug since the versions you refer to straddle the boundaries between released versions (where --enable-checking=release is the default) and development versions (where --enable-checking=debug is the default). --enable- checking=debug adds lots of extra checking, which is likely to identify problems in a more controlled fashion even though the built compiler will be slower. How deterministic is the failure? If you're seeing randomness, it could be an issue with garbage collector markings, in which case --param=ggc-min-expand=0 --param=ggc-min-heapsize=0 will fully run the garbage collector at every GC opportunity (which is *slow*, but very good at quickly pinpointing the problem if it's a issue with the GC, which otherwise are a major pain to track down). Hope this is helpful Dave