Bug 98047 - LTC3381 - c++locale.h redefines default arugment.
Summary: LTC3381 - c++locale.h redefines default arugment.
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc   
(Show other bugs)
Version: 3.0
Hardware: powerpc Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
: 98868 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-06-25 19:25 UTC by Ka Lam
Modified: 2007-11-30 22:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-26 00:02:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
shows GCC incorrectly accpet template with default arugment redefined. (136 bytes, text/plain)
2003-06-25 19:26 UTC, Ka Lam
no flags Details
Show GCC correct flag the error with redefined default arugment in non-template function. (85 bytes, text/plain)
2003-06-25 19:27 UTC, Ka Lam
no flags Details

Description Ka Lam 2003-06-25 19:25:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Description of problem:
in c++locale.h
around line 56, a template function is defined with default argument.  This
function is refined in locales_facets.tcc

According to the C++ Standard, duplicate definition of default argument is not
allowed.  I believe this is a bug in the GNU GCC header files.

There is also a bug in GCC, becuase according to the ISO C++ Standard sector
8.3.6 paragraph 4, it should not accept this code.

The testcase defparm3.C fails to compile (which is correct) when no template is
involved.

g++ defparm3.C -c
defparm3.C: In function `int foo(int)':
defparm3.C:7: default argument given for parameter 1 of `int foo(int = -1)'
defparm3.C:2: after previous specification in `int foo(int = -1)'


The testcase defparm.C, even there is a redefined default arugment, GCC fails to
catch it as an error.

The c++locale.h header file should be changed such that the default argument is
not redefined.

Version-Release number of selected component (if applicable):
gcc-3.2.3-2

How reproducible:
Always

Steps to Reproduce:
1.Compile the included defparm.C file to see GCC's incorrect accepting of
default arugment.
2.Since GCC is incorrectly accepting the C++locale.h file, the bug in
C++locale.h can only be seen when GCC is fixed.
3.
    

Actual Results:  GCC incorrectly accept code that's not ISO C++ compliance.

Expected Results:  GCC should give error on C++locale.h.
C++locale.h should not redefine default arugment.

Additional info:

Comment 1 Ka Lam 2003-06-25 19:26:30 UTC
Created attachment 92617 [details]
shows GCC incorrectly accpet template with default arugment redefined.

Comment 2 Ka Lam 2003-06-25 19:27:16 UTC
Created attachment 92618 [details]
Show GCC correct flag the error with redefined default arugment in non-template function.

Comment 3 Bill Nottingham 2003-07-10 00:50:48 UTC
*** Bug 98868 has been marked as a duplicate of this bug. ***

Comment 4 Benjamin Kosnik 2003-07-11 22:28:44 UTC
Mainline gcc and gcc-3_3-branch sources don't have the issue with c++locale.h.
Perhaps previous versions did have the __convert_from_v default argument in two
places: since this has been replaced in mainline and on gcc-3_3-branch it's no
longer an issue.

Anyway.

I've tried to compile above with gcc-3_2-rhl-branch and gcc-3_3-branch and
mainline gcc, and all give me the proper error, so I don't know what's up.
Perhaps this is specific to ppc64 (seems unlikely?)

-benjamin

Comment 5 Jakub Jelinek 2003-07-15 11:11:53 UTC
I have changed gcc-3_2-rhl8-branch to avoid the problem there.
As for the missing pedwarn, it is missing on all of gcc-3_2-rhl8-branch,
gcc-3_3-branch and HEAD.
Benjamin, you get any errors compiling:
http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=92617&action=view
?

Comment 6 Olof Johansson 2003-08-05 22:28:23 UTC
------- Additional Comments From olof@us.ibm.com(prefers email via olof@austin.ibm.com)  2003-05-08 18:26 -------
Do we have an estimate of when this will be fixed in RHEL? Thanks.



Comment 7 Jakub Jelinek 2003-08-05 22:33:49 UTC
The bug in the headers is fixed in gcc-3.2.3-10 and later (ie. already
in beta1 for example).  Are you talking about the headers or the lack of diagnostics?

Comment 8 Olof Johansson 2003-08-07 15:50:40 UTC
------- Additional Comments From olof@us.ibm.com(prefers email via olof@austin.ibm.com)  2003-07-08 11:49 -------
I was talking about the headers. Closing this as FIXED_BY_DISTRO. Thanks Jakub!


olof@us.ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |FIXEDAWAITINGTEST
         Resolution|                            |FIX_BY_DISTRO






Comment 9 Olof Johansson 2003-09-08 19:06:49 UTC
------- Additional Comments From kaena@us.ibm.com  2003-08-09 14:16 -------
Is this problem fixed? Or can someone answer Red Hat?

Comment 10 Olof Johansson 2003-09-08 20:02:46 UTC
------- Additional Comments From kaena@us.ibm.com  2003-08-09 15:51 -------
Hi,

This bug is fixed in beta1 or RHEL, but bugzilla won't let me add comment
or update the status.  Can you please close this defect for me? Thanks.

--
Ka Lam
C/C++ Compiler/Runtime Development
IBM Toronto Laboratory
kayinlam@ca.ibm.com (905) 413-2733 C2/KD2/8200/MKM

Comment 11 Matt Wilson 2003-09-26 00:02:44 UTC
closed, thanks.



Note You need to log in before you can comment on or make changes to this bug.