FAQ
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

Search Discussions

  • Tom Lane at May 24, 2011 at 5:44 pm

    Ibrar Ahmed 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
  • Andrew Dunstan at May 24, 2011 at 5:56 pm

    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
  • Heikki Linnakangas at May 24, 2011 at 6:02 pm

    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 at May 24, 2011 at 6:00 pm

    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
  • Tom Lane at May 24, 2011 at 6:14 pm

    Heikki Linnakangas 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 at May 25, 2011 at 4:44 pm
    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 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
  • Tom Lane at May 26, 2011 at 4:14 pm

    Ibrar Ahmed 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
  • Peter Eisentraut at May 26, 2011 at 9:13 pm

    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.
  • Tom Lane at May 26, 2011 at 9:32 pm

    Peter Eisentraut 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
  • Ibrar Ahmed at May 27, 2011 at 8:15 am

    On Fri, May 27, 2011 at 2:31 AM, Tom Lane 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
  • Peter Eisentraut at May 27, 2011 at 10:10 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 24, '11 at 5:21p
activeMay 27, '11 at 10:10p
posts12
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase