Thread
-
"errno" not set in case of "libm" functions (HPUX)
Ibrar Ahmed <ibrar.ahmad@gmail.com> — 2011-05-24T17:21:42Z
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 -
Re: "errno" not set in case of "libm" functions (HPUX)
Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-24T17:44:09Z
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
-
Re: "errno" not set in case of "libm" functions (HPUX)
Andrew Dunstan <andrew@dunslane.net> — 2011-05-24T17:56:26Z
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
-
Re: "errno" not set in case of "libm" functions (HPUX)
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2011-05-24T18:00:08Z
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
-
Re: "errno" not set in case of "libm" functions (HPUX)
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2011-05-24T18:02:40Z
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
-
Re: "errno" not set in case of "libm" functions (HPUX)
Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-24T18:13:40Z
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 -
Re: "errno" not set in case of "libm" functions (HPUX)
Ibrar Ahmed <ibrar.ahmad@gmail.com> — 2011-05-25T16:37:20Z
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 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 > -- Ibrar Ahmed
-
Re: "errno" not set in case of "libm" functions (HPUX)
Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-26T16:14:38Z
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
-
Re: "errno" not set in case of "libm" functions (HPUX)
Peter Eisentraut <peter_e@gmx.net> — 2011-05-26T21:13:22Z
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.
-
Re: "errno" not set in case of "libm" functions (HPUX)
Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-26T21:31:49Z
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
-
Re: "errno" not set in case of "libm" functions (HPUX)
Ibrar Ahmed <ibrar.ahmad@gmail.com> — 2011-05-27T08:15:13Z
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
-
Re: "errno" not set in case of "libm" functions (HPUX)
Peter Eisentraut <peter_e@gmx.net> — 2011-05-27T22:10:02Z
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.