Re: BUG #7816: test for compiler output produces bogus results

Seebs <seebs(at)seebs(dot)net> writes:
> On 20 Jan 2013, at 23:02, Tom Lane wrote:
>> [ shrug... ] Given the lack of previous complaints, it works 99.999%
>> of the time, which is about as much reliability as can be hoped for in
>> most autoconf tests :-(. I'm afraid we can't help you without
>> breaking it worse for a larger number of other people.

> I guess my question would be, what's the problem this is solving? Were
> there actual cases of flags which were accepted (meaning, compiler
> produced working output and exited with a successful status), but
> produced diagnostics, but were not necessary and could be safely
> omitted?

No, the problem as I recall it was that if we ignored the warnings,
we got executables that didn't work properly, at least on some
platforms/compilers, because we made the wrong choices of thread flags.

It's conceivable that the configure script could be made to test
threading functionality instead of just looking for warnings, but it
would be noticeably slower and wouldn't work in cross-compile cases.
So I'm disinclined to change it when we have only one complaint, and
that from a person who's using a quite nonstandard compiler.

> ... It just offends my
> dogmatic sensibilities; the compiler is allowed to offer a diagnostic
> for any reason whatsoever, whether or not anything is wrong.

I don't disagree, but the script has got to deal with the world as it
is, including a lot of non-especially-sane compilers. And frankly,
I'd have to include yours in that category. I certainly would refuse
to use a compiler that produced a warning on every single run --- how
are you going to find the real warnings amongst such noise?

regards, tom lane