Bisecting

Bisecting

[Søren Holm]

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.


Thanks

Søren Holm

Re: Bisecting

[Jonathan Wakely]

On Sat, 29 Jan 2022, 20:25 Søren Holm via Gcc, <gcc@gcc.gnu.org> 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.



>
> Thanks
>
> Søren Holm
>
>

Re: Bisecting

[David Malcolm]

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, <gcc@gcc.gnu.org> 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