This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] partial fix for PR 13594 (3.4 regression)
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>, libstdc++ at gcc dot gnu dot org
- Cc: gcc-patches at gcc dot gnu dot org, jason at redhat dot com, rsandifo at redhat dot com
- Date: 12 Jan 2004 14:48:00 -0200
- Subject: Re: [PATCH] partial fix for PR 13594 (3.4 regression)
- Organization: GCC Team, Red Hat
- References: <orn08zpi4c.fsf@free.redhat.lsd.ic.unicamp.br><200401101358.15535.ebotcazou@libertysurf.fr><or3cal2lah.fsf@free.redhat.lsd.ic.unicamp.br>
On Jan 12, 2004, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jan 10, 2004, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
>> FAIL: 23_containers/bitset/invalidation/1.cc (test for excess errors)
>> WARNING: 23_containers/bitset/invalidation/1.cc compilation failed to produce
>> executable
> Here's a patch that fixes this problem. My mistake was to assume that
> it was ok to use a single queue for strongly-associated and other
> namespaces. Now I see it isn't.
Digging deeper, I see that it should be. See, for example,
[namespace.udir]/5. It doesn't seem like a name found in a given
namespace is to hide names found in other namespaces whose
declarations are to be visible in it because of using directives.
This means not only that our search is broken, for not following using
directives when a definition is found, but also that libstdc++
__gnu_debug is broken, for relying on such brokenness to obtain the
desired effect. More precisely, the problem in libstdc++ is that
__gnu_debug contains using directives for both __gnu_debug_def
(strong) and std (not strong). If we were to follow the Standard
semantics, of following using directives regardless of having found a
name, we'd find that the names defined in both std (or __gnu_norm) and
__gnu_debug_def are ambiguous in __gnu_debug. Oops.
Now how do we get out of this corner we've painted ourselves into? :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist Professional serial bug killer