"errno" not set in case of "libm" functions (HPUX)
I have found a problem which is specifically related to "HP-UX" compiler.
All 'libm' functions on "HP-UX Integrity server" do not set "errno" by
default. For 'errno' setting we should compile the code using +Olibmerrno
option. So we should add this option in "/src/makefiles/Makefile.hpux".
Otherwise we cannot expect this code to work properly
[float.c]
Datum
dacos(PG_FUNCTION_ARGS)
{
...
errno = 0;
result = acos(arg1);
if (errno != 0)
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
...
}
Because "acos" function will not set the errono in case of invalid input, so
check will not trigger the error message. I have attached a patch to add
this option in HPUX makefile.
BTW I have found same kind of discussion without any conclusion here
http://archives.postgresql.org/pgsql-hackers/2011-05/msg00046.php
--
Ibrar Ahmed
Attachments:
hpux_Olibmerrno_ibrar1.patchtext/x-diff; charset=US-ASCII; name=hpux_Olibmerrno_ibrar1.patchDownload
diff --git a/src/makefiles/Makefile.hpux b/src/makefiles/Makefile.hpux
index 1917d61..f2a8f19 100644
--- a/src/makefiles/Makefile.hpux
+++ b/src/makefiles/Makefile.hpux
@@ -43,6 +43,12 @@ else
CFLAGS_SL = +Z
endif
+
+# HP-UX libm functions on 'Integrity server' do not set errno by default,
+# for errno setting, compile with the +Olibmerrno option.
+
+CFLAGS := +Olibmerrno $(CFLAGS)
+
# Rule for building a shared library from a single .o file
%$(DLSUFFIX): %.o
ifeq ($(GCC), yes)
Ibrar Ahmed <ibrar.ahmad@gmail.com> writes:
I have found a problem which is specifically related to "HP-UX" compiler.
All 'libm' functions on "HP-UX Integrity server" do not set "errno" by
default. For 'errno' setting we should compile the code using +Olibmerrno
option. So we should add this option in "/src/makefiles/Makefile.hpux".
This patch will break things on my admittedly rather ancient HPUX box:
$ cc +Olibmerrno
cc: warning 450: Unrecognized option +Olibmerrno.
As submitted, it would also break gcc-based builds, though that at least
wouldn't be hard to fix.
If you want to submit a configure patch to test whether the switch is
appropriate, we could consider it.
BTW, is it really true that HP decided they could make the compiler's
default behavior violate the C standard so flagrantly? I could believe
offering a switch that you had to specify to save a few cycles at the
cost of nonstandard behavior; but if your report is actually correct,
their engineering standards have gone way downhill since I worked there.
I wonder whether you are inserting some other nonstandard switch that
turns on this effect.
regards, tom lane
On 05/24/2011 01:44 PM, Tom Lane wrote:
Ibrar Ahmed<ibrar.ahmad@gmail.com> writes:
I have found a problem which is specifically related to "HP-UX" compiler.
All 'libm' functions on "HP-UX Integrity server" do not set "errno" by
default. For 'errno' setting we should compile the code using +Olibmerrno
option. So we should add this option in "/src/makefiles/Makefile.hpux".This patch will break things on my admittedly rather ancient HPUX box:
$ cc +Olibmerrno
cc: warning 450: Unrecognized option +Olibmerrno.As submitted, it would also break gcc-based builds, though that at least
wouldn't be hard to fix.If you want to submit a configure patch to test whether the switch is
appropriate, we could consider it.BTW, is it really true that HP decided they could make the compiler's
default behavior violate the C standard so flagrantly? I could believe
offering a switch that you had to specify to save a few cycles at the
cost of nonstandard behavior; but if your report is actually correct,
their engineering standards have gone way downhill since I worked there.
I wonder whether you are inserting some other nonstandard switch that
turns on this effect.
I have been whining for years about the lack of HP-UX support (both for
gcc and their compiler) on the buildfarm. I really really wish HP would
come to the party and supply some equipment and software. Failing that,
some spare cycles being made available on a machine by someone else who
runs it would be good.
cheers
andrew
On 24.05.2011 20:44, Tom Lane wrote:
BTW, is it really true that HP decided they could make the compiler's
default behavior violate the C standard so flagrantly? I could believe
offering a switch that you had to specify to save a few cycles at the
cost of nonstandard behavior; but if your report is actually correct,
their engineering standards have gone way downhill since I worked there.
I wonder whether you are inserting some other nonstandard switch that
turns on this effect.
This (http://docs.hp.com/en/B3901-90015/ch02s07.html) says:
+O[no]libmerrno
Description:
This option enables[disables] support for errno in libm functions. The default is +Onolibmerrno.
In C++ C-mode, the default is +Olibmerrno with -Aa option.
So the default is indeed non-standard. But I wonder if we should use -Aa
instead? The documentation I found for -Aa
(http://docs.hp.com/en/B3901-90017/ch02s22.html) says:
-Aa
The -Aa option instructs the compiler to use Koenig lookup and strict ANSI for scope rules. This option is equivalent to specifying -Wc,-koenig_lookup,on and -Wc,-ansi_for_scope,on.
The default is off. Refer to -Ae option for C++ C-mode description. The standard features enabled by -Aa are incompatible with earlier C and C++ features.
That sounds like what we want. Apparently that description is not
complete, and -Aa changes some other behavior to ANSI C compatible as
well, like +Olibmerrno. There's also -AC99, which specifies compiling in
C99-mode - I wonder if that sets +Olibmerrno too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On 24.05.2011 20:56, Andrew Dunstan wrote:
I have been whining for years about the lack of HP-UX support (both for
gcc and their compiler) on the buildfarm. I really really wish HP would
come to the party and supply some equipment and software. Failing that,
some spare cycles being made available on a machine by someone else who
runs it would be good.
I'm trying to arrange access to a HP-UX box within EnterpriseDB. No luck
this far. Hopefully I'll get a buildfarm animal up in the next week or
so, but don't hold your breath...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
So the default is indeed non-standard. But I wonder if we should use -Aa
instead?
Probably not; at least on older HPUX versions, -Aa turns off access to
assorted stuff that we do want, eg "long long". "man cc" on my box
saith
-Amode Specify the compilation standard to be used by the
compiler. mode can be one of the following letters:
c (Default) Compile in a mode compatible with
HP-UX releases prior to 7.0. (See The C
Programming Language, First Edition by
Kernighan and Ritchie). This option also
defines the symbol _HPUX_SOURCE and allows the
user to access macros and typedefs provided by
the HPUX Operating System. The default
compilation mode may change in future releases.
a Compile under ANSI mode (ANSI programming
language C standard ISO 9899:1990). When
compiling under ANSI mode, the header files
would define only those names (macros and
typedefs) specified by the Standard. To access
macros and typedefs that are not defined by the
ANSI Standard but are provided by the HPUX
Operating System, define the symbol
_HPUX_SOURCE; or use the extension option
described below.
e Extended ANSI mode. Same as -Aa -D_HPUX_SOURCE
+e. This would define the names (macros and
typedefs) provided by the HPUX Operating System
and, in addition, allow the following
extensions: $ characters in identifier names,
sized enums, sized bit-fields, and 64-bit
integral type long long. Additional extensions
may be added to this option in the future.
The +e option is elsewhere stated to mean
+e Enables HP value-added features while compiling
in ANSI C mode, -Aa. This option is ignored
with -Ac because these features are already
provided. Features enabled:
o Long pointers
o Integral type specifiers can appear in
enum declarations.
o The $ character can appear in
identifier names.
o Missing parameters on intrinsic calls
which isn't 100% consistent with what it says under -Ae, so maybe some
additional experimentation is called for. But anyway, autoconf appears
to think that -Ae is preferable to the combination -Aa -D_HPUX_SOURCE
(that choice is coming from autoconf not our own code); so I'm not
optimistic that we can get more-standard behavior by overriding that.
regards, tom lane
Please find the updated patch. I have added this "+Olibmerrno" compile flag
check in configure/configure.in file.
OS
----
HP-UX B.11.31 U ia64
without patch
---------------
postgres=# select acos(2);
acos
------
NaN
(1 row)
with patch
-----------
postgres=# select acos(2);
ERROR: input is out of range
On Tue, May 24, 2011 at 11:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
So the default is indeed non-standard. But I wonder if we should use -Aa
instead?Probably not; at least on older HPUX versions, -Aa turns off access to
assorted stuff that we do want, eg "long long". "man cc" on my box
saith-Amode Specify the compilation standard to be used by the
compiler. mode can be one of the following letters:c (Default) Compile in a mode compatible with
HP-UX releases prior to 7.0. (See The C
Programming Language, First Edition by
Kernighan and Ritchie). This option also
defines the symbol _HPUX_SOURCE and allows the
user to access macros and typedefs provided by
the HPUX Operating System. The default
compilation mode may change in future releases.a Compile under ANSI mode (ANSI programming
language C standard ISO 9899:1990). When
compiling under ANSI mode, the header files
would define only those names (macros and
typedefs) specified by the Standard. To access
macros and typedefs that are not defined by the
ANSI Standard but are provided by the HPUX
Operating System, define the symbol
_HPUX_SOURCE; or use the extension option
described below.e Extended ANSI mode. Same as -Aa -D_HPUX_SOURCE
+e. This would define the names (macros and
typedefs) provided by the HPUX Operating System
and, in addition, allow the following
extensions: $ characters in identifier names,
sized enums, sized bit-fields, and 64-bit
integral type long long. Additional extensions
may be added to this option in the future.The +e option is elsewhere stated to mean
+e Enables HP value-added features while compiling
in ANSI C mode, -Aa. This option is ignored
with -Ac because these features are already
provided. Features enabled:o Long pointers
o Integral type specifiers can appear in
enum declarations.
o The $ character can appear in
identifier names.
o Missing parameters on intrinsic callswhich isn't 100% consistent with what it says under -Ae, so maybe some
additional experimentation is called for. But anyway, autoconf appears
to think that -Ae is preferable to the combination -Aa -D_HPUX_SOURCE
(that choice is coming from autoconf not our own code); so I'm not
optimistic that we can get more-standard behavior by overriding that.regards, tom lane
--
Ibrar Ahmed
Attachments:
hpux_Olibmerrno_ibrar2.patchtext/x-diff; charset=US-ASCII; name=hpux_Olibmerrno_ibrar2.patchDownload
diff --git a/configure b/configure
index 3b23c46..d448534 100755
--- a/configure
+++ b/configure
@@ -4468,6 +4468,66 @@ if test x"$pgac_cv_prog_cc_cflags__qnoansialias" = x"yes"; then
CFLAGS="$CFLAGS -qnoansialias"
fi
+elif test "$PORTNAME" = "hpux"; then
+ # HP-UX libm functions on 'Integrity server' do not set errno by default,
+ # for errno setting, compile with the +Olibmerrno option.
+ { $as_echo "$as_me:$LINENO: checking whether $CC supports +Olibmerrno" >&5
+$as_echo_n "checking whether $CC supports +Olibmerrno... " >&6; }
+if test "${pgac_cv_prog_cc_cflags_pOlibmerrno+set}" = set; then
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+CFLAGS="$pgac_save_CFLAGS +Olibmerrno"
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (ac_try="$ac_compile"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\""
+$as_echo "$ac_try_echo") >&5
+ (eval "$ac_compile") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest.$ac_objext; then
+ pgac_cv_prog_cc_cflags_pOlibmerrno=yes
+else
+ $as_echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ pgac_cv_prog_cc_cflags_pOlibmerrno=no
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+CFLAGS="$pgac_save_CFLAGS"
+fi
+{ $as_echo "$as_me:$LINENO: result: $pgac_cv_prog_cc_cflags_pOlibmerrno" >&5
+$as_echo "$pgac_cv_prog_cc_cflags_pOlibmerrno" >&6; }
+if test x"$pgac_cv_prog_cc_cflags_pOlibmerrno" = x"yes"; then
+ CFLAGS="$CFLAGS +Olibmerrno"
+fi
+
fi
# supply -g if --enable-debug
diff --git a/configure.in b/configure.in
index 76c1a88..0444f7f 100644
--- a/configure.in
+++ b/configure.in
@@ -445,6 +445,10 @@ elif test "$ICC" = yes; then
elif test "$PORTNAME" = "aix"; then
# AIX's xlc has to have strict aliasing turned off too
PGAC_PROG_CC_CFLAGS_OPT([-qnoansialias])
+elif test "$PORTNAME" = "hpux"; then
+ # HP-UX libm functions on 'Integrity server' do not set errno by default,
+ # for errno setting, compile with the +Olibmerrno option.
+ PGAC_PROG_CC_CFLAGS_OPT([+Olibmerrno])
fi
# supply -g if --enable-debug
Ibrar Ahmed <ibrar.ahmad@gmail.com> writes:
Please find the updated patch. I have added this "+Olibmerrno" compile flag
check in configure/configure.in file.
I tried this on my HP-UX 10.20 box, and it didn't work very nicely:
configure decided that the compiler accepted +Olibmerrno, so I got a
compile full of
cc: warning 450: Unrecognized option +Olibmerrno.
warnings. The reason is that PGAC_PROG_CC_CFLAGS_OPT does not pay any
attention to whether the proposed flag generates a warning. That seems
like a bug --- is there any situation where we'd want to accept a flag
that does generate a warning? I'm thinking that macro should set
ac_c_werror_flag=yes, the same way PGAC_C_INLINE does.
regards, tom lane
On tor, 2011-05-26 at 12:14 -0400, Tom Lane wrote:
Ibrar Ahmed <ibrar.ahmad@gmail.com> writes:
Please find the updated patch. I have added this "+Olibmerrno" compile flag
check in configure/configure.in file.I tried this on my HP-UX 10.20 box, and it didn't work very nicely:
configure decided that the compiler accepted +Olibmerrno, so I got a
compile full of
cc: warning 450: Unrecognized option +Olibmerrno.
warnings. The reason is that PGAC_PROG_CC_CFLAGS_OPT does not pay any
attention to whether the proposed flag generates a warning. That seems
like a bug --- is there any situation where we'd want to accept a flag
that does generate a warning? I'm thinking that macro should set
ac_c_werror_flag=yes, the same way PGAC_C_INLINE does.
I think so.
We could also do that globally, but that would probably be something for
the next release.
Peter Eisentraut <peter_e@gmx.net> writes:
On tor, 2011-05-26 at 12:14 -0400, Tom Lane wrote:
I tried this on my HP-UX 10.20 box, and it didn't work very nicely:
configure decided that the compiler accepted +Olibmerrno, so I got a
compile full of
cc: warning 450: Unrecognized option +Olibmerrno.
warnings. The reason is that PGAC_PROG_CC_CFLAGS_OPT does not pay any
attention to whether the proposed flag generates a warning. That seems
like a bug --- is there any situation where we'd want to accept a flag
that does generate a warning? I'm thinking that macro should set
ac_c_werror_flag=yes, the same way PGAC_C_INLINE does.
I think so.
OK, committed with that addition.
We could also do that globally, but that would probably be something for
the next release.
Hmm. I'm a bit scared of how much might break. I don't think the
autoconf tests are generally designed to guarantee no warnings.
regards, tom lane
On Fri, May 27, 2011 at 2:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On tor, 2011-05-26 at 12:14 -0400, Tom Lane wrote:
I tried this on my HP-UX 10.20 box, and it didn't work very nicely:
configure decided that the compiler accepted +Olibmerrno, so I got a
compile full of
cc: warning 450: Unrecognized option +Olibmerrno.
warnings. The reason is that PGAC_PROG_CC_CFLAGS_OPT does not pay any
attention to whether the proposed flag generates a warning. That seems
like a bug --- is there any situation where we'd want to accept a flag
that does generate a warning? I'm thinking that macro should set
ac_c_werror_flag=yes, the same way PGAC_C_INLINE does.I think so.
OK, committed with that addition.
Thanks,
Is it worth to backport this?
We could also do that globally, but that would probably be something for
the next release.Hmm. I'm a bit scared of how much might break. I don't think the
autoconf tests are generally designed to guarantee no warnings.regards, tom lane
--
Ibrar Ahmed
On tor, 2011-05-26 at 17:31 -0400, Tom Lane wrote:
We could also do that globally, but that would probably be something
for
the next release.
Hmm. I'm a bit scared of how much might break. I don't think the
autoconf tests are generally designed to guarantee no warnings.
Yeah, I think you're right. Although one wonders why they have built-in
support for that. Might be worth trying sometime.