libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[axiong]

>Number:         9378
>Category:       libstdc++
>Synopsis:       64-bit g++: construct base:std::moneypunct_byname<char>->memory fault
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 20 20:26:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Guan-Zhu (Andrew) Xiong
>Release:        gcc version 3.2
>Organization:
>Environment:
Linux Version 2.4.19
SuSE SLES 8 (ppc) - Kernel 2.4.19-ul1-ppc64-SMP (34)
pSeries
>Description:
=> 64-bit g++ compiling:
construct base, std::moneypunct_byname<char> -> memory fault

=> not a problem with 32-bit "dfs" version g++
=> also a problem for local version of 32-bit g++ -> failed with "Abort" (not memory fault)    

>How-To-Repeat:
/*********************************************************
 * Copile the following code with 64-bit g++ and run it
 *********************************************************/
#include <locale>

class D : public std::moneypunct_byname<char, false> {
public:
        D(const char* p) : std::moneypunct_byname<char>(p) {}
};

int main(void)
{
        const char* c01 = "abc";
        D d(c01);

        return 0;
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[steven]

Synopsis: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

State-Changed-From-To: feedback->analyzed
State-Changed-By: steven
State-Changed-When: Mon May 12 11:22:28 2003
State-Changed-Why:
    Feedback came in long ago.  Confirmed vs. mainline which is 3.4 at this moment.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9378

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[Benjamin Kosnik]

The following reply was made to PR libstdc++/9378; it has been noted by GNATS.

From: Benjamin Kosnik <bkoz@redhat.com>
To: Martin Sebor <sebor@roguewave.com>
Cc: bkoz@gcc.gnu.org, axiong@ca.ibm.com, gcc-bugs@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault
Date: Wed, 29 Jan 2003 20:53:54 -0600

 On Wed, 29 Jan 2003 18:45:32 -0700
 Martin Sebor <sebor@roguewave.com> wrote:
 
 >In fact, I would even propose that we remove the _byname ctors,
 >or better yet, the entire facets from the standard ;-) (only
 >half joking).
 
 I would support any attempt to remove the _byname disasters from any future
 standard (no joking.)
 
 -benjamin

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[Martin Sebor]

The following reply was made to PR libstdc++/9378; it has been noted by GNATS.

From: Martin Sebor <sebor@roguewave.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: bkoz@gcc.gnu.org, axiong@ca.ibm.com, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory
 fault
Date: Wed, 29 Jan 2003 18:45:32 -0700

 Benjamin Kosnik wrote:
 > On Wed, 29 Jan 2003 14:24:10 -0700
 > Martin Sebor <sebor@roguewave.com> wrote:
 > 
 > 
 >>FWIW, I don't think the requirements on the ctors of class
 >>locale are relevant in this case. The problem is, IMO, that
 >>there are no requirements at all on the ctors of the byname
 >>facets, so pretty much anything goes. I.e., abort is just
 >>as legal as successful construction.
 > 
 > 
 > Hmm. I wasn't paying attention, and didn't realize these were _byname facets. 
 > It doesn't really matter though, because....
 > 
 > 22.1.1.1.2 - Class locale::facet [lib.locale.facet]
 > 
 > -4- For some standard facets a standard ``..._byname'' class, derived
 > from it, implements the virtual function semantics equivalent to that
 > facet of the locale constructed by locale(const char*) with the same
 > name. 
 > 
 > So, with this equivalence argument, I think the original point still
 > holds: these name strings are implementation-defined, and people should
 > not assume that any arbitray string will in fact, lead to a constructed
 > locale object.
 
 I agree (with the name argument). I would go even further and
 assert that programs that directly construct any of the _byname
 facets have unspecified behavior. The only safe (or portable)
 way to use the _byname facets is via a call to use_facet<
 xxx_byname>(), and even that only after a corresponding call
 to has_facet<xxx_byname>()).
 
 In fact, I would even propose that we remove the _byname ctors,
 or better yet, the entire facets from the standard ;-) (only
 half joking).
 
 Regards
 Martin
 

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[Benjamin Kosnik]

The following reply was made to PR libstdc++/9378; it has been noted by GNATS.

From: Benjamin Kosnik <bkoz@redhat.com>
To: Martin Sebor <sebor@roguewave.com>
Cc: bkoz@gcc.gnu.org, axiong@ca.ibm.com, gcc-bugs@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault
Date: Wed, 29 Jan 2003 20:34:37 -0600

 On Wed, 29 Jan 2003 14:24:10 -0700
 Martin Sebor <sebor@roguewave.com> wrote:
 
 >
 >FWIW, I don't think the requirements on the ctors of class
 >locale are relevant in this case. The problem is, IMO, that
 >there are no requirements at all on the ctors of the byname
 >facets, so pretty much anything goes. I.e., abort is just
 >as legal as successful construction.
 
 Hmm. I wasn't paying attention, and didn't realize these were _byname facets. 
 It doesn't really matter though, because....
 
 22.1.1.1.2 - Class locale::facet [lib.locale.facet]
 
 -4- For some standard facets a standard ``..._byname'' class, derived
 from it, implements the virtual function semantics equivalent to that
 facet of the locale constructed by locale(const char*) with the same
 name. 
 
 So, with this equivalence argument, I think the original point still
 holds: these name strings are implementation-defined, and people should
 not assume that any arbitray string will in fact, lead to a constructed
 locale object.
 
 -benjamin

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[Martin Sebor]

The following reply was made to PR libstdc++/9378; it has been noted by GNATS.

From: Martin Sebor <sebor@roguewave.com>
To: bkoz@gcc.gnu.org, axiong@ca.ibm.com, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory
 fault
Date: Wed, 29 Jan 2003 14:24:10 -0700

 bkoz@gcc.gnu.org wrote:
 ...
 >     
 >     ISO 14882: 22.1.1.2 locale ctors and dtors
 >     
 >     throws: runtime_error if the argument is ont valid, or is null. The set of valid string argument values is "C", "", and any implementation-defined values.
 >     
 >     In the above case, you're trying to create a locale based on the implementation-defined value of "abc." The GNU implemenation defines this value to be junk, and errors out. (Correctly so, I think.)
 
 FWIW, I don't think the requirements on the ctors of class
 locale are relevant in this case. The problem is, IMO, that
 there are no requirements at all on the ctors of the byname
 facets, so pretty much anything goes. I.e., abort is just
 as legal as successful construction.
 
 Regards
 Martin
 
  >
 ...
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9378
 

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[bkoz]

Synopsis: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Wed Jan 29 21:05:10 2003
State-Changed-Why:
    Thanks for the IBM guys being so quick on this one. 
    
    For your compilation errors, talk to Mr. Modra or Janis, they'll be able to point you to compilers that work.
    
    As for your code, Janis is correct. The behavior reported:
    
    What's supposed to happen here?  With mainline, for both 32-bit and 
     native 64-bit powerpc64-linux I get:
     
     elm3b10% a.out
     terminate called after throwing an instance of 'std::runtime_error'
       what():  attempt to create locale from unknown name
     Aborted 
     
    Is correct. Here's why:
    
    ISO 14882: 22.1.1.2 locale ctors and dtors
    
    throws: runtime_error if the argument is ont valid, or is null. The set of valid string argument values is "C", "", and any implementation-defined values.
    
    In the above case, you're trying to create a locale based on the implementation-defined value of "abc." The GNU implemenation defines this value to be junk, and errors out. (Correctly so, I think.)
    
    Current libstdc++/g++ combos are more strict on this than other C++ libraries (namely, ones that only do one locale.)  This was an issue in some commerical C++ library validators until the above was pointed out to them.
    
    best,
    benjamin

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9378

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[axiong]

The following reply was made to PR libstdc++/9378; it has been noted by GNATS.

From: axiong@ca.ibm.com
To: Janis Johnson <janis187@us.ibm.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory
 fault
Date: Tue, 21 Jan 2003 16:34:09 -0500

 1) "dfs" -> DFS (Distributed File System)
      - We also put a g++ compiler at /.../../fs/.../3.2.0/bin/g++
 
 2) Expected result: The program runs successfully and returns 0 to the OS
 
 Regards,
 
 Andrew
 

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[Janis Johnson]

The following reply was made to PR libstdc++/9378; it has been noted by GNATS.

From: Janis Johnson <janis187@us.ibm.com>
To: axiong@ca.ibm.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault
Date: Tue, 21 Jan 2003 12:07:14 -0800

 On Mon, Jan 20, 2003 at 08:20:24PM -0000, axiong@ca.ibm.com wrote:
 > 
 > >Description:
 > => 64-bit g++ compiling:
 > construct base, std::moneypunct_byname<char> -> memory fault
 > 
 > => not a problem with 32-bit "dfs" version g++
 
 What is "dfs"?
 
 > => also a problem for local version of 32-bit g++ -> failed with "Abort" (not memory fault)    
 > 
 > >How-To-Repeat:
 > /*********************************************************
 >  * Copile the following code with 64-bit g++ and run it
 >  *********************************************************/
 > #include <locale>
 > 
 > class D : public std::moneypunct_byname<char, false> {
 > public:
 >         D(const char* p) : std::moneypunct_byname<char>(p) {}
 > };
 > 
 > int main(void)
 > {
 >         const char* c01 = "abc";
 >         D d(c01);
 > 
 >         return 0;
 > }
 
 What's supposed to happen here?  With mainline, for both 32-bit and 
 native 64-bit powerpc64-linux I get:
 
 elm3b10% a.out
 terminate called after throwing an instance of 'std::runtime_error'
   what():  attempt to create locale from unknown name
 Aborted 
 
 Janis

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault

[Alan Modra]

The following reply was made to PR libstdc++/9378; it has been noted by GNATS.

From: Alan Modra <amodra@bigpond.net.au>
To: axiong@ca.ibm.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault
Date: Tue, 21 Jan 2003 16:47:07 +1030

 I couldn't reproduce this problem with a couple of ppc64 compilers I
 had lying around.
 
 powerpc64-linux-g++ (GCC) 3.2.1 20021107 (prerelease)
 and
 powerpc64-linux-g++ (GCC) 3.2.2 20030110 (prerelease)
 
 These were both built from 3.2 branch CVS sources with patches applied
 from ftp.linuxppc64.org/pub/people/amodra/gcc-3.2/.  I believe the
 SLES8 compiler is built from gcc-3.2 plus an assortment of patches,
 including an older one of mine.
 
 So you may have better luck with a newer compiler.
 
 -- 
 Alan Modra
 IBM OzLabs - Linux Technology Centre