[
https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523429
]
Martin Sebor commented on STDCXX-509:
-------------------------------------
Looks like the committed change is binary compatible (see the post below) and
so it's not appropriate for 4.2. We need a different solution for this release.
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04613.html
> 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.
