Re: Unportable coding in reorderbuffer.h

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unportable coding in reorderbuffer.h
Дата
Msg-id 23941.1394067796@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Unportable coding in reorderbuffer.h  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Unportable coding in reorderbuffer.h  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Unportable coding in reorderbuffer.h
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Unportable coding in reorderbuffer.h