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
|
Список | 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 по дате отправления: