[PATCH] testsuite: Fix various scan-assembler-symbol-section issues

[David Edelsohn]

On Mon, Dec 14, 2020 at 9:44 AM Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> Hi David,
>
> > On Fri, Dec 4, 2020 at 5:35 AM Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> >
> >> On AIX 7.2, there are changes like
> >>
> >> -PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section
> >> symbol ^_?ir$ (found ir) has section ^\\.tbss|\\[TL\\] (found
> >> _tls5.tls_[TL],4)
> >> +PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section
> >> symbol ^_?ir$ (found ir) has section ^\\.tbss|\\[TL\\] (found
> >> _tls5.tls_[TL])
> >>
> >> i.e. the ",4" after (?) the section name is now stripped.  I believe
> >> this is benign: David?
> >
> > The ",4" is the symbol alignment.  It is not necessary for the purpose
> > of the tests.
>
> fine, thanks for the clarification.
>
> > Thanks for looking further into this problem.  As I mentioned in my
> > earlier reply to the patch itself, I believe that this new feature and
> > infrastructure change should have been tested and fixed on
> > non-Linux/ELF/x86 architectures, not left as an exercise for the
> > maintainers of other targets.  A patch that introduces regressions in
> > the testsuite should be fixed or reverted and should be the
> > responsibility of the author -- whether the change is to the compiler
> > or to the testsuite.
>
> Yes and no: given the trouble I had myself trying an AIX bootstrap and
> test and the effort it took guiding Iain through a Solaris 11.3
> bootstrap on gcc211, I fear it's unreasonable to demand developers to do
> all this testing themselves: if you have to address only one issue per
> unfamiliar target while trying to, we'll loose contributors very
> quickly.  I believe we should be able to get the setup of the various
> cfarm hosts better in sync with the guidelines documented in the wiki to
> avoid such trouble.

I respectfully disagree.  I find the GCC community very inconsistent
about this policy and I will continue to object.  Sometimes the
community demands thorough testing on all major targets and sometimes
the community says that it's too much trouble.  It depends on the
patch, and the developer, and the target that the patch is trying to
fix.  I believe that this inconsistent policy is driving away
developers also.

Many other software packages have a policy that any test suite
regression requires patch reversion.  GCC historically has not had
that policy.  But GCC does have a policy that testsuite failures are
the responsibility of the person who created the patch.  The GCC
community historically has decided that it is impractical and
unscalable for one person to install a patch and generate
unanticipated work for every other maintainer in the community.
Software developers do not want to work on a software package where
another developer can break their configuration, generate extra,
unanticipated work, and have no responsibility.

Most active maintainers are willing to help.  Most maintainers are
willing to help a developer debug a problem on their target.

Bootstrap on AIX works best with some additional configuration
parameters that are mentioned in the Compile Farm wiki.  Bootstrap on
AIX would have been much easier for you if you had asked for help and
advice.

>
> Ultimately, something like the trybot feature of the (now mostly
> defunct) gdb buildbots could ease such pre-commit tests.

I agree that GCC needs better CI and there are efforts in that direction.

>
> But I fully agree that the original patch should have seen way wider
> cross-platform testing before being committed: asking target maintainers
> for help usually works well enough: one just cannot expect them to spot
> any patch that might require such testing themselves.

Thanks, David