Re: Unportable coding in reorderbuffer.h

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-03-05 19:12:15 -0500, Tom Lane wrote:
>> I'm surprised too; I had thought we still had some critters running
>> hoary compilers. We need to do something about that if we actually
>> believe in C90-compiler support.

> What version was the gcc that triggered the error?

That was the 2.95.3 I have on my HPPA box. I don't have any 3.x versions
in captivity; the next oldest I have is 4.0.1 on a Mac (running Leopard
or thereabouts), and it seems to take this code.

> I have to admit that I am really not interested in supporting gcc 2.95 ,
> that thing is just too old (nearly 15 years!) and buggy.

[ shrug... ] In 15 years, the only problem I've seen with 2.95.3 is
that it's prone to complaining about variables-clobbered-by-longjmp
that no other compiler is unhappy with. Maybe the HPPA build is less
buggy due to less aggressive optimization? I usually use -O1 with it,
and that backend might be less tense than the Intel backend anyway.

However, this is probably a bit beside the point. I'm quite prepared
to believe that nobody uses gcc < 4.0 anymore. The question is what
older non-gcc compilers are still out there, and can we either get hold
of them for the buildfarm, or trust that a really old gcc will complain
about the same things they would? I suspect that most of the candidates
would be proprietary compilers, so short of shelling out license fees
I think we might be stuck with using old gcc as a proxy. As I said,
I've more often than not found that things 2.95.3 will take don't
cause problems elsewhere.

> I personally think it's time to dump some older compiler versions, and
> adopt at least individual C99 features (e.g. static inlines).

Meh. In the first place, what you want is not C99 inlines it's GNU
inlines; the standard's version is brain-dead. But I'm not prepared
to declare us a GCC-only shop. In the second place, we already have a
workable if slightly klugy solution for GNU inlines without assuming
all compilers do that. I don't see a need to throw that overboard.

regards, tom lane