https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jürgen Reuter from comment #33)
> (In reply to Iain Sandoe from comment #32)
> > (In reply to Jürgen Reuter from comment #31)
> > > Then I get tons of duplicate symbol lines.
> > 
> > ah well, not so simple then,
> > 
> > then I think the next step is for you to identify the last working revision
> > of  the compiler - we can then analyse what the change was that caused the
> > difference and determine if that's a real regression or just exposing a
> > build system issue.
> 
> I fear I don't have the capacities to do that right now.

I'm afraid without that there is nothing we can do about it.
While bisection can be time consuming, it doesn't need to be time consuming for
you (at least not that much), it can be scripted.
If you have some compiler that works (guess because this PR got marked as [9
Regression] gcc 8.x works for you) and some compiler that doesn't, I see three
options for the bisection.
One is build with the "good" compiler and "bad" compiler in two separate
directories, verify one works and one doesn't, then make a copy of one of those
directories and bisect between the *.o files, start with half "good" ones and
half "bad" ones and from the outcome try to narrow it to a particular
problematic *.o file.  Another one is similar, but if you have "good" and "bad"
options, such as e.g. with -O0 it works and -O2 it doesn't, again bisect object
files to find the problematic one.
And the last one is try to bisect the compiler, after verifying "good"/"bad"
try to build gcc from half way in between those revisions etc.
The bisection to a particular *.o file is something that might help with the
bisection of compilers, you only can bisect the compilation of the problematic
TU and on that check what actually changed.

Reply via email to