Sun Studio 12 vs. __builtin_constant_p()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Sun Studio 12 vs. __builtin_constant_p()
Date: 2017-12-14 15:07:46
Message-ID: 22997.1513264066@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Well, that's annoying: buildfarm member castoroides just fell over
with symptoms indicating that its compiler thinks that
__builtin_constant_p("string literal") is false, thus breaking the
check I installed in commit 9fa6f00b1 that AllocSetContextCreate's
name argument is a literal.

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides&dt=2017-12-14%2013%3A03%3A05

I think removing that check would be entirely impractical, and
anyway it's sufficient if it works on "most people's" compilers.
Fortunately, buildfarm results so far suggest that most compilers
do accept this usage of __builtin_constant_p, if they know the
function at all.

What I propose to do is adjust the configure check for
__builtin_constant_p so that it explicitly checks for
__builtin_constant_p("string literal") being true, in addition
to what it tests now. That will result in slightly worse
code optimization around ereport/elog calls on compilers that
don't have this behavior, but that seems fine to me.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-12-14 15:12:45 Re: access/parallel.h lacks PGDLLIMPORT
Previous Message Robert Haas 2017-12-14 14:58:43 Re: PATCH: Exclude unlogged tables from base backups