Bug 49141 - 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
Summary: 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: 4.6.1
Assignee: Paolo Carlini
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-24 13:43 UTC by Rainer Orth
Modified: 2011-05-26 11:35 UTC (History)
0 users

See Also:
Host: alpha-dec-osf5.1b, *-*-solaris2.[89]
Target: alpha-dec-osf5.1b, *-*-solaris2.[89]
Build: alpha-dec-osf5.1b, *-*-solaris2.[89]
Known to work:
Known to fail:
Last reconfirmed: 2011-05-24 14:18:36


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Orth 2011-05-24 13:43:29 UTC
On platforms without <complex.h> (at least Tru64 UNIX V5.1B, Solaris 8 and 9),
two tests FAIL:

FAIL: 26_numerics/complex/cons/48760.cc (test for excess errors)
WARNING: 26_numerics/complex/cons/48760.cc compilation failed to produce executable

FAIL: 26_numerics/complex/cons/48760.cc (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc:31:2: error: 'isnan' is not a member of 'std'
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc:31:2: note: suggested alternative:
/var/gcc/regression/trunk/9-gcc/build/./gcc/include-fixed/math.h:145:12: note:   'isnan'

FAIL: 26_numerics/complex/cons/48760_c++0x.cc (test for excess errors)
WARNING: 26_numerics/complex/cons/48760_c++0x.cc compilation failed to produce 
executable

  Rainer
Comment 1 Paolo Carlini 2011-05-24 14:17:19 UTC
It seems to me that the problem is isnan, not complex.h. We should check what we do for the other tests using isnan.
Comment 2 Paolo Carlini 2011-05-24 14:18:36 UTC
Will fix it momentarily.
Comment 3 ro@CeBiTec.Uni-Bielefeld.DE 2011-05-24 14:39:57 UTC
> --- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-24 14:17:19 UTC ---
> It seems to me that the problem is isnan, not complex.h. We should check what
> we do for the other tests using isnan.

Strangely, config.h defines HAVE_ISNAN 1.

	Rainer
Comment 4 Paolo Carlini 2011-05-24 14:49:30 UTC
But isn't imported in std::, because something else is missing. We don't do this kind of config-time work with a very small granularity. We want dg-require-c-std to be safe.
Comment 5 paolo@gcc.gnu.org 2011-05-24 14:59:16 UTC
Author: paolo
Date: Tue May 24 14:59:13 2011
New Revision: 174120

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174120
Log:
2011-05-24  Paolo Carlini  <paolo.carlini@oracle.com>

	PR libstdc++/49141
	* testsuite/26_numerics/complex/cons/48760.cc: Use dg-require-c-std.
	* testsuite/26_numerics/complex/cons/48760_c++0x.cc: Likewise.
	* testsuite/26_numerics/headers/cmath/19322.cc: Likewise.


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc
    trunk/libstdc++-v3/testsuite/26_numerics/complex/cons/48760_c++0x.cc
    trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/19322.cc
Comment 6 Paolo Carlini 2011-05-24 15:00:21 UTC
Rainer, please confirm that everything is ok now, 2/3 of the patch goes to 4_6-branch too.
Comment 7 paolo@gcc.gnu.org 2011-05-25 09:46:02 UTC
Author: paolo
Date: Wed May 25 09:45:58 2011
New Revision: 174179

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174179
Log:
2011-05-24  Paolo Carlini  <paolo.carlini@oracle.com>

	PR libstdc++/49141
	* testsuite/26_numerics/complex/cons/48760.cc: Use dg-require-c-std.
	* testsuite/26_numerics/headers/cmath/19322.cc: Likewise.


Modified:
    branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
    branches/gcc-4_6-branch/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc
    branches/gcc-4_6-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/19322.cc
Comment 8 Paolo Carlini 2011-05-25 09:48:12 UTC
Done.
Comment 9 ro@CeBiTec.Uni-Bielefeld.DE 2011-05-26 09:26:13 UTC
> --- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-24 15:00:21 UTC ---
> Rainer, please confirm that everything is ok now, 2/3 of the patch goes to
> 4_6-branch too.

The tests now become UNSUPPORTED on sparc-sun-solaris2.8.  Thanks.

On the other hand, I new see several tests that fail to link with
missing cexp{, f, l}, e.g.

FAIL: 26_numerics/complex/13450.cc (test for excess errors)
Excess errors:
Undefined			first referenced
 symbol  			    in file
cexp                                /var/tmp//ccvyjKLM.o
cexpf                               /var/tmp//ccvyjKLM.o
cexpl                               /var/tmp//ccvyjKLM.o
ld: fatal: Symbol referencing errors. No output written to ./13450.exe
collect2: error: ld returned 1 exit status

that passed before.  I don't believe this is related and probably
warrants a new PR.

	Rainer
Comment 10 Paolo Carlini 2011-05-26 09:37:55 UTC
(In reply to comment #9)
> that passed before.  I don't believe this is related and probably
> warrants a new PR.

For sure isn't related to my tweak, neither to something that went in the library over the last weeks or even months, AFAIK. I would really recommend nailing down a bit the timeframe over which the fails started, before opening a PR in this area, I don't know what you mean by 'before'.
Comment 11 ro@CeBiTec.Uni-Bielefeld.DE 2011-05-26 09:57:17 UTC
> --- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-26 09:37:55 UTC ---
> (In reply to comment #9)
>> that passed before.  I don't believe this is related and probably
>> warrants a new PR.
>
> For sure isn't related to my tweak, neither to something that went in the
> library over the last weeks or even months, AFAIK. I would really recommend
> nailing down a bit the timeframe over which the fails started, before opening a
> PR in this area, I don't know what you mean by 'before'.

They passed on 20110520.  I'll compare the two builds in more detail to
see what's happening.

	Rainer
Comment 12 Paolo Carlini 2011-05-26 10:01:48 UTC
(In reply to comment #11)
> They passed on 20110520.

Then I'm relieved ;) Really, nothing changed in the <complex> code of the library and 13450.cc between 20110520 and now.
Comment 13 ro@CeBiTec.Uni-Bielefeld.DE 2011-05-26 11:25:27 UTC
> --- Comment #12 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-26 10:01:48 UTC ---
> (In reply to comment #11)
>> They passed on 20110520.
>
> Then I'm relieved ;) Really, nothing changed in the <complex> code of the
> library and 13450.cc between 20110520 and now.

Indeed: the .ii files from -save-temps are mostly unchanged.  As of
20110520, there are no calls to cexp in the .s file, while as of
20110525, they do occur.  I'll start looking elsewhere for the culprit
patch.

	Rainer
Comment 14 Paolo Carlini 2011-05-26 11:32:20 UTC
Thanks Rainer. Let me know if I can be otherwise useful.
Comment 15 ro@CeBiTec.Uni-Bielefeld.DE 2011-05-26 11:35:05 UTC
> --- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-26 11:32:20 UTC ---
> Thanks Rainer. Let me know if I can be otherwise useful.

I will, thanks.  I've already identified the most likely culprit: PR
tree-optimization/49170.

	Rainer