Обсуждение: "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

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
tospecifying -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
incompatiblewith 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
thefollowing letters:
 
                      c    (Default) Compile in a mode compatible with                           HP-UX releases prior
to7.0.  (See The C                           Programming Language, First Edition by                           Kernighan
andRitchie).  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
defineonly 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
bythe HPUX                           Operating System, define the symbol                           _HPUX_SOURCE; or use
theextension option                           described below.
 
                      e    Extended ANSI mode.  Same as -Aa -D_HPUX_SOURCE                           +e.  This would
definethe 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.
Additionalextensions                           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
---------------





--
   Ibrar Ahmed

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 ofcc: 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

--
   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.