gcc -ansi versus SSE4.2 detection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: gcc -ansi versus SSE4.2 detection
Date: 2015-06-05 18:27:59
Message-ID: 24580.1433528879@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[ this is a bit roundabout, bear with me ]

I noticed that, contrary to project policy, a //-style comment snuck into
pg_regress.c a month or two back. I had had the idea that buildfarm
member pademelon would complain about such comments, given its stone-age
C compiler, but evidently not. After some experimentation it seems that
"gcc -ansi" can be used to throw errors for // comments, so I'm planning
to enable that flag on dromedary. However I found out that adding -ansi
also caused configure to stop selecting "-msse4.2", which seemed odd,
since that switch has no bearing on C language conformance. And it fell
back to the slicing-by-8 CRC implementation too.

Investigation showed that that's because -ansi causes the compiler to
stop defining __SSE4_2__, which configure supposes must get defined if
we are targeting an SSE 4.2 processor. This seems a bit dumb to me:
if we have determined that "-msse4.2" works, isn't that sufficient
evidence that we can use the intrinsics? Or if not, isn't there a less
fragile way to find out the target?

Also, it seems like the logic in configure.in is broken in any case:
if we are able to compile the intrinsics, should it not pick the
runtime-determination option for CRC? It isn't doing that.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-06-05 18:32:54 Re: Further issues with jsonb semantics, documentation
Previous Message Robert Haas 2015-06-05 18:26:57 Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1