[Bug libstdc++/49141] New: 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[Bug libstdc++/49141] New: 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

           Summary: 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX
                    V5.1B, Solaris 8 and 9
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org
                CC: paolo.carlini@oracle.com
              Host: alpha-dec-osf5.1b, *-*-solaris2.[89]
            Target: alpha-dec-osf5.1b, *-*-solaris2.[89]
             Build: alpha-dec-osf5.1b, *-*-solaris2.[89]


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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.05.24 14:18:36
     Ever Confirmed|0                           |1

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-24 14:18:36 UTC ---
Will fix it momentarily.

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.1

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 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.

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

--- Comment #5 from paolo at gcc dot gnu.org <paolo at gcc dot 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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

--- Comment #7 from paolo at gcc dot gnu.org <paolo at gcc dot 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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|paolo.carlini at oracle dot |
                   |com                         |
         Resolution|                            |FIXED
         AssignedTo|unassigned at gcc dot       |paolo.carlini at oracle dot
                   |gnu.org                     |com

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-25 09:48:12 UTC ---
Done.

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

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

[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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