incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-509) std::numeric_limits<double>::infinity() depends on dynamic initialization
Date Tue, 16 Oct 2007 03:37:50 GMT

    [ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535048
] 

Martin Sebor commented on STDCXX-509:
-------------------------------------

The change committed at rev 584981 (http://svn.apache.org/viewcvs?view=rev&rev=584981)
along with rev 584956 (http://svn.apache.org/viewvc?view=rev&revision=584956) implement
a binary compatible fix for all supported platforms except Visual Studio (and most likely
Intel C++ on Windows). Still need to come up with a fix for that one.

> std::numeric_limits<double>::infinity() depends on dynamic initialization
> -------------------------------------------------------------------------
>
>                 Key: STDCXX-509
>                 URL: https://issues.apache.org/jira/browse/STDCXX-509
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: 18. Language Support
>    Affects Versions: 4.1.2, 4.1.3
>         Environment: gcc3.2, linux AS3.0
>            Reporter: Ravi K Inampudi
>            Assignee: Martin Sebor
>             Fix For: 4.2
>
>         Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd.
Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead
of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from
Apache. From our understanding, when creating the libFoo.so and using the native standard
library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit
dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd
instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
>  # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG
-I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include
-I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2
-Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared
-o libFooRW-link.so foo.C 
>  # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++
-lm -lFooRW 
> However, using the RW standard library, if such dependency is created explicitly then
it prints "inf". For example, the following set of commands fixes the problem:
>  # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG
-I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include
-I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2
-Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared
-o libFooRW-link.so foo.C -lstd12d
>  # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++
-lm -lFooRW 
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd.
 They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And
they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const]
the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time).
It seems that the compiler should be able to initialize it statically anyway, even if it's
not required to. Regardless, we should avoid making the assumption that it will and change
the initialization of the extern constants to use constant expressions instead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message