Re: [PATCH, testsuite] ignore some "conflicting types for built-in" messages

[Martin Sebor <msebor at gmail dot com>]

On 11/05/2018 11:17 AM, Paul Koning wrote:
> > On Nov 5, 2018, at 11:45 AM, Jeff Law <law@redhat.com> wrote:
> >
> > > > ...
> > >
> > > I can do that, but I'm wondering if some systems have different prototypes than the C standard calls for so I'd end up breaking those.I wouldn't worry about those.  I think the bigger question (thanks
> > Martin) is whether or not any of those tests are checking for issues
> > that arise specifically due to not having a full prototype available
> > (and in those cases your fix is probably more appropriate).
> >
> > Probably the only way to figure that out is to dig into the history of
> > each one :(  Mighty unpleasant.
> >
> > jeff
>
> I took a quick look.  PR83655 is specifically about an issue due to a declaration with no prototype, but the others (55890, 71816, 83463, 83603, 84244) are not so clear to me.  Still, what IS clear is that none of them are interested in messages that may or may not be generated as a result of these funny declarations.  In other words, pruning the messages still looks appropriate.
>
> So where do I go from here?  Without the change I can deal with this by recognizing these cases as false failures when I do my test runs.

The only way to determine for sure if adding a prototype won't
affect the tests is to try it with the affected compiler.  For
tests exercising bugs in released versions of GCC on x86_64
(like for 55890) it's not too difficult to do with Godbolt(*).
For tests for bugs in development versions (e.g., 71816) or
it's quite a bit more time-consuming.

The test for 55890 does rely on the absence of a prototype and
providing it results in compilation errors.

The test for 83463 also relies on it and adding the prototype
prevents the ICE.  Ditto for 83603 and 84224.

The test for 71816 doesn't seem to depend on it.  An unpatched
GCC 7.0 (at r238207) still crashes after adding the prototypes.

I agree with adding missing prototypes to tests that exercise
the behavior of features, but it would be risky to change
the source code of tests that verify the absence of an ICE.
Such changes could easily have subtle effects that could
compromise the efficacy of those tests.  IMO, in these cases,
or when in doubt, the safest thing to do is to prune their
output (I wouldn't even add options to suppress warnings
ince that could have similar effects).

Martin

[*] https://gcc.godbolt.org