[Bug libstdc++/13284] New: 126 g++ failures due to lrand48 not defined

[Bug libstdc++/13284] New: 126 g++ failures due to lrand48 not defined

[giovannibajo at libero dot it]

Hello,

126 out of the 148 failures I see with mainline on cygwin are due to this:

In file included from /home/Administrator/gcc/mainline/out/i686-pc-
cygwin/libstdc++-v3/include/algorithm:69,
                 from /home/Administrator/gcc/mainline/out/i686-pc-
cygwin/libstdc++-v3/include/string:56,
                 
from /home/Administrator/gcc/mainline/gcc/gcc/testsuite/g++.dg/init/array4.C:8: 
/home/Administrator/gcc/mainline/out/i686-pc-cygwin/libstdc++-
v3/include/bits/stl_algo.h: In function `_Distance std::__random_number
(_Distance)':
/home/Administrator/gcc/mainline/out/i686-pc-cygwin/libstdc++-
v3/include/bits/stl_algo.h:1670: error: there are no arguments to `lrand48' 
that depend on a templ
ate parameter, so a declaration of `lrand48' must be available
/home/Administrator/gcc/mainline/out/i686-pc-cygwin/libstdc++-
v3/include/bits/stl_algo.h:1670: error: (if you use `-fpermissive', G++ will 
accept your code, but allowing the use of an undeclared name is deprecated)

Now, newlib does not define lrand48 if __STRICT_ANSI__, and the testsuite is 
run with "-ansi". Danny Smith suggests that cygwin's newlib should always 
define those C99 functions in C++ mode. 

But I wonder, why _GLIBCXX_HAVE_LRAND48 is defined in the first place? 
Shouldn't the configure test for it be run in -ansi mode?

-- 
           Summary: 126 g++ failures due to lrand48 not defined
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: giovannibajo at libero dot it
                CC: dannysmith at gcc dot gnu dot org,gcc-bugs at gcc dot
                    gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug libstdc++/13284] 126 g++ failures due to lrand48 not defined

[dannysmith at gcc dot gnu dot org]

------- Additional Comments From dannysmith at gcc dot gnu dot org  2003-12-03 20:11 -------
lrand48 is not ansi under any standard I am aware of.  IMO, it shouldn't be 
exposed at all in STL interface.  

There are other problems in newlib where some C99 math functions/macros (eg, 
scalbn, fpclassify)  are protected by __STRICT_ANSI__ in math.h.

Danny


-- 


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

[Bug libstdc++/13284] 126 g++ failures due to lrand48 not defined

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2003-12-04 03:06 -------
I found out this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00058.html.

Notice this part:

* Even though this new declaration test may succeed, the testsuite may
  still produce the failures above, since there g++ -ansi is run, which may
  hide declarations present without -ansi.  This part is not fixed by this
  patch.

Rainer, maybe you can provide a follow-up patch for this problem?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at techfak dot uni-
                   |                            |bielefeld dot de


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

[Bug libstdc++/13284] 126 g++ failures due to lrand48 not defined

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-12-04 16:41:59
               date|                            |


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

[Bug libstdc++/13284] 126 g++ failures due to lrand48 not defined

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2003-12-04 18:44 -------

I think, on balance and after looking at this, that stl_algo.h should just be
using rand.


  /**
   *  @if maint
   *  Return a random number in the range [0, __n).  This function encapsulates
   *  whether we're using rand (part of the standard C library) or lrand48
   *  (not standard, but a much better choice whenever it's available).
   *
   *  XXX There is no corresponding encapsulation fn to seed the generator.
   *  @endif
  */
  template<typename _Distance>
    inline _Distance
    __random_number(_Distance __n)
    {
  #ifdef _GLIBCXX_HAVE_LRAND48
      return lrand48() % __n;
  #else
      return rand() % __n;
  #endif
    }

Ie, this should just be rand, the code collapsed, and the configuration
complexity should be removed.

-benjamin

-- 


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

[Bug libstdc++/13284] 126 g++ failures due to lrand48 not defined

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2003-12-04 19:37 -------
Subject: Bug 13284

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	bkoz@gcc.gnu.org	2003-12-04 19:37:21

Modified files:
	libstdc++-v3   : ChangeLog Makefile.in acconfig.h aclocal.m4 
	                 config.h.in configure crossconfig.m4 linkage.m4 
	libstdc++-v3/include: Makefile.in 
	libstdc++-v3/include/bits: stl_algo.h 
	libstdc++-v3/include/ext: algorithm 
	libstdc++-v3/libmath: Makefile.in 
	libstdc++-v3/libsupc++: Makefile.in 
	libstdc++-v3/po: Makefile.in 
	libstdc++-v3/src: Makefile.in 
	libstdc++-v3/testsuite: Makefile.in 

Log message:
	2003-12-04  Benjamin Kosnik  <bkoz@redhat.com>
	
	PR libstdc++/13284
	* include/bits/stl_algo.h (__random_number): Remove.
	(random_shuffle): Use rand, as permitted by DR 395.
	* include/ext/algorithm: Same.
	* linkage.m4 (GLIBCXX_CHECK_STDLIB_SUPPORT): Remove lrand48.
	* acconfig.h: Same.
	* crossconfig.m4: Remove HAVE_DRAND48, HAVE_LRAND48.
	* config.h.in: Regenerated.
	* configure: Same.
	* aclocal.m4: Same.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2128&r2=1.2129
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/Makefile.in.diff?cvsroot=gcc&r1=1.132&r2=1.133
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acconfig.h.diff?cvsroot=gcc&r1=1.36&r2=1.37
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/aclocal.m4.diff?cvsroot=gcc&r1=1.291&r2=1.292
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config.h.in.diff?cvsroot=gcc&r1=1.76&r2=1.77
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.diff?cvsroot=gcc&r1=1.367&r2=1.368
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/crossconfig.m4.diff?cvsroot=gcc&r1=1.9&r2=1.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/linkage.m4.diff?cvsroot=gcc&r1=1.3&r2=1.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/Makefile.in.diff?cvsroot=gcc&r1=1.90&r2=1.91
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_algo.h.diff?cvsroot=gcc&r1=1.42&r2=1.43
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/algorithm.diff?cvsroot=gcc&r1=1.9&r2=1.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/libmath/Makefile.in.diff?cvsroot=gcc&r1=1.90&r2=1.91
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/libsupc++/Makefile.in.diff?cvsroot=gcc&r1=1.104&r2=1.105
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/po/Makefile.in.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/Makefile.in.diff?cvsroot=gcc&r1=1.191&r2=1.192
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/Makefile.in.diff?cvsroot=gcc&r1=1.65&r2=1.66



-- 


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

[Bug libstdc++/13284] [3.4 regression] 126 g++ failures due to lrand48 not defined

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-04 21:20 -------
Fiexed checked in.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
            Summary|126 g++ failures due to     |[3.4 regression] 126 g++
                   |lrand48 not defined         |failures due to lrand48 not
                   |                            |defined
   Target Milestone|---                         |3.4


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

[Bug libstdc++/13284] [3.4 regression] 126 g++ failures due to lrand48 not defined

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2003-12-05 00:25 -------
I can confirm that this patch cured those failures. Many thanks Benjamin!

-- 


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

[Bug libstdc++/13284] [3.4 regression] 126 g++ failures due to lrand48 not defined

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-08-05 22:00 -------
Subject: Bug 13284

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	hammer-3_3-branch
Changes by:	paolo@gcc.gnu.org	2004-08-05 22:00:43

Modified files:
	libstdc++-v3   : ChangeLog.hammer 
	libstdc++-v3/include/bits: stl_algo.h 
	libstdc++-v3/include/ext: algorithm 

Log message:
	2004-08-05  Paolo Carlini  <pcarlini@suse.de>
	
	Backport from mainline/3.4:
	2003-12-04  Benjamin Kosnik  <bkoz@redhat.com>
	
	PR libstdc++/13284
	* include/bits/stl_algo.h (random_shuffle): Use rand, as
	permitted by DR 395.
	* include/ext/algorithm: Same.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.hammer.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.1.2.32&r2=1.1.2.33
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_algo.h.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.27.18.2&r2=1.27.18.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/algorithm.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.6&r2=1.6.12.1



-- 


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