Bug 25191 - exception_defines.h #defines try/catch
Summary: exception_defines.h #defines try/catch
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.0.1
: P1 blocker
Target Milestone: 4.4.0
Assignee: Paolo Carlini
URL:
Keywords: accepts-invalid, wrong-code
: 36032 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-11-30 22:25 UTC by Howard Hinnant
Modified: 2009-02-03 23:46 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.1.3 4.3.0 4.4.0
Last reconfirmed: 2008-11-18 18:45:35


Attachments
Compiler patch to allow try/catch and rethrow under -fno-exceptions (1.65 KB, patch)
2008-11-19 21:42 UTC, Jason Merrill
Details | Diff
My current patch for -fignore-exceptions (1.25 KB, patch)
2008-11-21 22:23 UTC, Andrew Pinski
Details | Diff
Updated patch with some testcases (1.90 KB, patch)
2008-11-21 23:08 UTC, Andrew Pinski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Howard Hinnant 2005-11-30 22:25:40 UTC
exception_defines.h #defines try/catch when -fno-exceptions.  This destroys Objective C code using @try and @catch.  A simple fix is to insteaad in exception_defines.h do something like (untested):

#ifndef __EXCEPTIONS
// Iff -fno-exceptions, transform error handling code to work without it.
# define __try      if (true)
# define __catch(X) if (false)
# define __throw_exception_again
#else
// Else proceed normally.
# define __try      try
# define __catch(X) catch(X)
# define __throw_exception_again throw
#endif

And then religiously use __try/__catch in libstdc++ instead of try/catch.
Comment 1 Andrew Pinski 2005-11-30 23:57:49 UTC
This is a library issue and not a front-end issue.
Comment 2 Benjamin Kosnik 2005-12-02 18:59:21 UTC
We are trying to keep the libstc++ code as clean and representative of standards-conforming C++ code as possible, and have avoided __try, __catch, etc. or other uglification in favor of the actual C++ terms, ie try, catch.

I'd rather you work around this in objective-c or objective c++.

-benjamin
Comment 3 Andrew Pinski 2005-12-02 19:01:44 UTC
(In reply to comment #2)
> We are trying to keep the libstc++ code as clean and representative of
> standards-conforming C++ code as possible, and have avoided __try, __catch,
> etc. or other uglification in favor of the actual C++ terms, ie try, catch.
> 
> I'd rather you work around this in objective-c or objective c++.

Actaully I can think of why this cannot be worked around, first try is the keyword and not just @try.

I personally would like this fixed in libstdc++ as it is changing valid code in people's sources without them knowing it is happening to them (maybe an #undef before the end of the header files will fix the issue).
Comment 4 Andrew Pinski 2005-12-02 19:04:30 UTC
Confirmed.  This also causes problems in normal C++ code which does:

#include <string>

int f(void);
int main(void)
{
  try {
  f();
  }catch (a) {}
}

Without the include, you get an error but with the include, you don't which is inconstaint behavior.

So this is not just an obc++ vs libstdc++ with -fno-exceptions issue, this is also an diagnostic issue.
Comment 5 Howard Hinnant 2005-12-02 19:07:48 UTC
(In reply to comment #2)
> I'd rather you work around this in objective-c or objective c++.

How?  I'm open to suggestions.

-Howard
Comment 6 Gabriel Dos Reis 2005-12-02 19:18:41 UTC
Subject: Re:  exception_defines.h #defines try/catch


I agree with Benjamin.

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I personally would like this fixed in libstdc++ as it is changing
| valid code 

I don't think that can be true.

try and catch are C++ keyword.  And exceptions are integral part of
the language.  As a courtesy, libstdc++ lets you use it with
-fno-exceptions at the conditions that iy you use try and catch then
they are rewritten into the if(0)/else stuff.

| in 
| people's sources without them knowing it is happening to them (maybe an #undef
| before the end of the header files will fix the issue).

#undef at the files of the files will not fix the issue.  However,
it is a good suggestion of how objc can fix the issue on its side.

-- Gaby
Comment 7 Gabriel Dos Reis 2005-12-02 19:23:35 UTC
Subject: Re:  exception_defines.h #defines try/catch

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| Confirmed.  This also causes problems in normal C++ code which does:
| 
| #include <string>
| 
| int f(void);
| int main(void)
| {
|   try {
|   f();
|   }catch (a) {}
| }
| 
| Without the include, you get an error but with the include, you don't which is
| inconstaint behavior.

Indeed.  But that is not changing a valid code into something else as
you claimed earlier.

The use of try/catch is part of the contract of -fno-exceptions. If a
determined programmer decides to abuse them beyond reasons, then I
believe he/she gets what he/she gets.

-- Gaby
Comment 8 Gabriel Dos Reis 2005-12-02 19:29:08 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #5 from hhinnant at apple dot com  2005-12-02 19:07 -------
| (In reply to comment #2)
| > I'd rather you work around this in objective-c or objective c++.
| 
| How?  I'm open to suggestions.

#undef them if you intend to include libstdc++ files and use try/catch
with funny characters to mean something else with -fno-exceptions?

-- Gaby
Comment 9 Howard Hinnant 2005-12-02 21:00:55 UTC
(In reply to comment #8)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> "hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | ------- Comment #5 from hhinnant at apple dot com  2005-12-02 19:07 -------
> | (In reply to comment #2)
> | > I'd rather you work around this in objective-c or objective c++.
> | 
> | How?  I'm open to suggestions.
> 
> #undef them if you intend to include libstdc++ files and use try/catch
> with funny characters to mean something else with -fno-exceptions?

I'm sorry, I'm just not understanding what you're suggesting.  If you could expound on your suggestion I would be most appreciative.  If it helps, here is a demo file that I would like to have work with -fno-exceptions.

#include <list>
#include <vector>
#import <Cocoa/Cocoa.h>
#import "my_header.h"  // may have contain ObjC @try/@catch
#include <iostream>

int main()
{
//    ....
}

An alternative to my original suggested fix is to solve this problem in the FE by parsing try/catch differently (e.g. as if they were if(true)/if(false)) in system headers when -fno-exceptions.  Then we could just get rid of exception_defines.h, and still have pretty std::headers.  Not being someone with a lot of FE experience, I have more hesitation about this latter approach.
Comment 10 Andrew Pinski 2005-12-02 21:06:32 UTC
(In reply to comment #9)
> Not being someone with a lot of FE experience, I have more hesitation about this latter approach.

That solution still does not solve my issue of the diagnostic issue.  

We really should not be defining keywords in the headers at all.  If we define bool somewhere to be int, we would get incorrect behavior the same way we are getting for try/catch.
Comment 11 Howard Hinnant 2005-12-02 21:21:40 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > Not being someone with a lot of FE experience, I have more hesitation about this latter approach.
> 
> That solution still does not solve my issue of the diagnostic issue.  

Doesn't it?  try/catch is no longer #defined, and client code will get a diagnostic if it uses try/catch with -fno-exceptions (only the system headers get special treatment by the FE).  That's what we want, right?

> 
> We really should not be defining keywords in the headers at all.  If we define
> bool somewhere to be int, we would get incorrect behavior the same way we are
> getting for try/catch.
> 

<nod>  That's always been a golden rule that has worked well for me (after learning it the hard way many moons ago ;-) ).

-Howard
Comment 12 Gabriel Dos Reis 2005-12-03 00:58:41 UTC
Subject: Re:  exception_defines.h #defines try/catch

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| We really should not be defining keywords in the headers at all.  If we define
| bool somewhere to be int, we would get incorrect behavior the same way we are
| getting for try/catch.

But the issues are not the same.  You're using try/catch with
-fno-exceptions!  If you used a compiler options that tells you that
bool is defined to something else, that is it!  

-- gaby
Comment 13 Gabriel Dos Reis 2005-12-03 01:02:52 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #8)
| > Subject: Re:  exception_defines.h #defines try/catch
| > 
| > "hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| > 
| > | ------- Comment #5 from hhinnant at apple dot com  2005-12-02 19:07 -------
| > | (In reply to comment #2)
| > | > I'd rather you work around this in objective-c or objective c++.
| > | 
| > | How?  I'm open to suggestions.
| > 
| > #undef them if you intend to include libstdc++ files and use try/catch
| > with funny characters to mean something else with -fno-exceptions?
| 
| I'm sorry, I'm just not understanding what you're suggesting.  If you could
| expound on your suggestion I would be most appreciative.  If it helps, here is
| a demo file that I would like to have work with -fno-exceptions.

I'm saying that if you're intending to use try/catch and yet not
want what the mean in standard C++, nor what they would mean in GNU
C++ with -fno-exceptions, then you have to watch what you're doing.
Meaning, in your *own* codes, you #undef try/catch.  Whether it is in
Cocoa.h or foobar.c, I don't care.  Just take your responsability to
#undef them -- because you have decided to have mean something else.
I'm not inclined in seeing the libstdc++ be uglified in that direction.

-- Gaby
Comment 14 Howard Hinnant 2005-12-03 01:25:16 UTC
(In reply to comment #13)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> I'm saying that if you're intending to use try/catch and yet not
> want what the mean in standard C++, nor what they would mean in GNU
> C++ with -fno-exceptions, then you have to watch what you're doing.
> Meaning, in your *own* codes, you #undef try/catch.  Whether it is in
> Cocoa.h or foobar.c, I don't care.  Just take your responsability to
> #undef them -- because you have decided to have mean something else.
> I'm not inclined in seeing the libstdc++ be uglified in that direction.

I see, thanks for the clarification.

It is my understanding that gcc 4.1 supports a language called Obj C++.  In this language (and I am by no means an Obj C++ expert) you can pretty much mix & match Obj C and C++.  I have customers using Obj C++ who want to turn off C++ exception support, but retain Obj C exception support.  They can easily do so -- unless they include a libstdc++ header.  The libstdc++ headers are messing up their ObjC @try/@catch statements.  That is, libstdc++ is not supportive of ObjC++ in this manner.

They are not trying to use C++ try/catch in a bizarre or unsupported manner.  They are simply trying to use ObjC++ exceptions without the unwanted cost of C++ exceptions.

This is quite analogous to the C headers compiled under C++.  <math.h>, under C++, is supposed to behave a little differently than <math.h> under C.  As a C++ programmer I appreciate that some C vendors will make some modest accomadations for me.

This seems to me like a very modest accomadation we can make for the ObjC++ programmer.  Afterall, ObjC++ is a supported language of gcc now, and libstdc++ is part of that support.  Asking every ObjC++ programmer to order the C++ and ObjC headers and #undef things just right seems quite error prone to me when we can easily solve the problem once and for all.

// C++ includes
#include <list>
#include <vector>

// Obj C includes
#undef try
#undef catch
#import <Cocoa/Cocoa.h>
#import "my_header.h" 
#include <iostream>     // oops, put C++ header in wrong place!

int main()
{
//    ....
}

That is a customer-hostile solution.

-Howard
Comment 15 Gabriel Dos Reis 2005-12-03 04:20:19 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #14 from hhinnant at apple dot com  2005-12-03 01:25 -------
| (In reply to comment #13)
| > Subject: Re:  exception_defines.h #defines try/catch
| > 
| > I'm saying that if you're intending to use try/catch and yet not
| > want what the mean in standard C++, nor what they would mean in GNU
| > C++ with -fno-exceptions, then you have to watch what you're doing.
| > Meaning, in your *own* codes, you #undef try/catch.  Whether it is in
| > Cocoa.h or foobar.c, I don't care.  Just take your responsability to
| > #undef them -- because you have decided to have mean something else.
| > I'm not inclined in seeing the libstdc++ be uglified in that direction.
| 
| I see, thanks for the clarification.
| 
| It is my understanding that gcc 4.1 supports a language called Obj C++. 

I don't think anybody is disputing that.  It is also a simple fact
that GCC documents what happens with -fno-exceptions.

 In
| this language (and I am by no means an Obj C++ expert) you can pretty much mix
| & match Obj C and C++.  I have customers using Obj C++ who want to turn off C++
| exception support, but retain Obj C exception support.  They can easily do so
| -- unless they include a libstdc++ header.  The libstdc++ headers are messing
| up their ObjC @try/@catch statements.  That is, libstdc++ is not supportive of
| ObjC++ in this manner.

No. ObjC++ is messing with itself.  -fno-exceptions is documented.
Either you don't want to use it, and you don't.  Or you want to use it
and you have to abide by what it does.  

| They are not trying to use C++ try/catch in a bizarre or unsupported manner. 

Then, why what is this PR is about in the first place?
-fno-exceptions turns try/catch into macros with specified semantics.
If you don't like those semantics, either you don't use
-fno-exceptions, or redifine the macros to meet your needs.

[...]

| That is a customer-hostile solution.

Trying not to abide by the rules and getting back and shouting for
hostility is a joke.  A sad one, Howard :-(

Asking for more uglification in libstdc++ just to fix ObjC++ is a
hostile solutions, if "hostile" is found to be appropriate
qualification in this discussion.

-- Gaby
Comment 16 Howard Hinnant 2005-12-04 02:12:29 UTC
(In reply to comment #15)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> I don't think anybody is disputing that.  It is also a simple fact
> that GCC documents what happens with -fno-exceptions.

I think it is good that gcc documents what it does, and I am also impressed with the gcc documentation in general.  But just because something is documented doesn't make it the best answer.  Thank you for letting me know this behaivor is documented (I hadn't even tried to look that up, and still haven't found it).  It is still a customer-hostile solution.

> Trying not to abide by the rules and getting back and shouting for
> hostility is a joke.  A sad one, Howard :-(

I'm not shouting (no caps, not even an exlamation point), but perhaps my vocabulary needs explaining.  I'm a pretty simple guy.  And I'm also very customer focused in everything I do (even in situations that are not traditionally vendor/customer).  If a solution seems to work for customers very well, I'll often call it customer-friendly.  If a solution seems to work for customers very poorly, I'll often call it customer-hostile.  I'm not trying to shout or make any jokes.  It is simply the way I work.  My apologies for not explaining that up front.

But I won't apologize for being customer focused.  That focus has served me well over the past two decades.  If I provide a service, and those who I'm providing the service to don't find that service useful, I'll look inward first - every single time.  I'll continue to think about solutions from the customer's viewpoint as best I am able.  And if or when I ever find myself having trouble doing that, I pray I'm able to retire.

> No. ObjC++ is messing with itself.

I don't know what that means.  Or even how it would be relevant.  ObjC++ is what it is.  If you or I don't like ObjC++, is that relevant?

> Either you don't want to use it, and you don't.  Or you want to use it
> and you have to abide by what it does.  

Maybe it does the wrong thing.  We have customer complaints.

> Then, why what is this PR is about in the first place?

My bad for not explaining it better in the original post.

This PR is about the fact that although our customers find the compiler's definition of -fno-exceptions useful, and want use it, but they find the libstdc++'s reaction to this compiler flag unhelpful.  Furthermore, making libstdc++'s behavior under -fno-exceptions to actually be useful for our customers is nearly trivial.  Yes readability takes a minor hit.  But functionality/usefulness increases.

I really don't even understand why this is controversial.  This is a minor issue that will have absolutely no impact on our C++ customers, and will make our ObjC++ customers much happier.  If someone had raised a point about how we are harming our C++ customers with this fix, I would have been alarmed and searched for a solution that didn't harm our C++ customers.  If it was a major imposition from an implementation point of view, I would be alarmed.  But as it is, all I'm hearing is that there is an objection to helping our ObjC++ customers at the expense of a very minor readability hit in libstdc++ internals.  I'm honestly very confused by that response.

-Howard
Comment 17 Gabriel Dos Reis 2005-12-04 02:54:47 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| But I won't apologize for being customer focused.

Geeat!  And people disagreeing with you on this point are not necessary
customer unfocused.

[...]

| > No. ObjC++ is messing with itself.
| 
| I don't know what that means.  Or even how it would be relevant.  ObjC++ is
| what it is.  If you or I don't like ObjC++, is that relevant?

I'm quite disappointed you reduced this issue to liking/disliking ObjC++.
If you believe that is the appropriate reduction, this is my last
message on the issue.  The rest clarifies what I said earlier.

This issue has nothing to do with liking or disliking ObjC++, not
matter how much of "hostility" or other "emotion" you would like to
inject into it.  ObjC++ got it wrong, it got it wrong.  The place to
fix it is in ObjC++.  That has nothing to do with liking or disliking
ObjC++. 

[...]

| I'm honestly very confused by that response.

I would not guess that it is partly because you seem to approach the
issue only from ObjC++-centric point of view.  This is issue is not
just fixing ObjC++ by uglifying libstdc++.  Those macro definitions of
try/catch when -fno-exceptions have been there long before ObjC++ came
in.  It is not like we're suddenly changing them.  
The uglification you're proposing is also breaking interfaces:  All
user codes that worked with both -fexceptions and -fno-exceptions and
used try/catch now will break.  I don't think I'm prepared to accept
that breakage.  The fix is simple for ObjC++: #undef them if it thinks
it wants both -fno-exceptions, libstdc++ headers.

-- Gaby
Comment 18 Howard Hinnant 2005-12-04 15:55:45 UTC
(In reply to comment #15)
> Subject: Re:  exception_defines.h #defines try/catch
> It is also a simple fact
> that GCC documents what happens with -fno-exceptions.

I'm trying to find this documentation.  So far all I've found is:

http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options

-fexceptions
Enable exception handling....

Is there more?

Thanks,
Howard
Comment 19 Howard Hinnant 2005-12-06 01:19:36 UTC
(In reply to comment #17)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> "hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | I don't know what that means.  Or even how it would be relevant.  ObjC++ is
> | what it is.  If you or I don't like ObjC++, is that relevant?
> 
> I'm quite disappointed you reduced this issue to liking/disliking ObjC++.
> If you believe that is the appropriate reduction, this is my last
> message on the issue.  The rest clarifies what I said earlier.

Message #16, starting with the paragaph:

> This PR is about the fact...

states what I think this issue reduces to.
 
> This issue has nothing to do with liking or disliking ObjC++, not
> matter how much of "hostility" or other "emotion" you would like to
> inject into it.

I'm sorry if you find my vocabulary offensive, even after I've politely explained myself.  "customer-friendly" and "customer-hostile" are terms I've used for a long time.  I find them self explanatory, to the point, and not inflamatory.  Would "customer-friendly" and "not customer-friendly" work better for you?  I'm certainly willing to change my vocabulary.

> ObjC++ got it wrong, it got it wrong.  The place to
> fix it is in ObjC++.  That has nothing to do with liking or disliking
> ObjC++. 

How did ObjC++ get it wrong?  And what is "it"?

> I would not guess that it is partly because you seem to approach the
> issue only from ObjC++-centric point of view.

<chuckle>  I would not guess that either, considering my background.  Indeed I'm trying my best not to approach this from a C++ centric point of view.

> This is issue is not
> just fixing ObjC++ by uglifying libstdc++.  Those macro definitions of
> try/catch when -fno-exceptions have been there long before ObjC++ came
> in.  It is not like we're suddenly changing them.  
> The uglification you're proposing is also breaking interfaces:  All
> user codes that worked with both -fexceptions and -fno-exceptions and
> used try/catch now will break.  I don't think I'm prepared to accept
> that breakage.

Thank you for pointing me to our documentation.  We apparently do not document the behavior you want to preserve.  Therefore we will not be breaking anything.  If user code is using try/catch and -fno-exceptions at the same time, it is doing so at its own peril.  Simply omitting a standard header from the customer's code could change compiling code into non-compiling code.

#include <limits>  // breaks under -fno-excetions if this header is removed

void foo()
{
     try 
    {
         bar();
    }
    catch (...)
    {
    }
}

>  The fix is simple for ObjC++: #undef them if it thinks
> it wants both -fno-exceptions, libstdc++ headers.

If this fix were simple, then great.  But it isn't simple because each ObjC++ customer has to re-implement it, and not just in one place, but in every single translation unit.  And it doesn't even work in general if ObjC++ headers can contain @try/@catch and contain std::lib includes:

// C++ includes
#include <list>
#include <vector>

// Obj C includes
#undef try
#undef catch
#import "my_header.h"   // oops, my_header.h includes <iostream>!

That's a maintenance nightmare for the ObjC++ customer!  And the reason we put the customer through this is so that we can read "try" instead of "__try" in the libstdc++ implementation?

If we really wanted to fix this right, we'd get rid of 95% of the try/catch clauses in the first place (via RAII techniques).  Then we wouldn't have to read "try" or "__try" (except very rarely).

-Howard
Comment 20 Benjamin Kosnik 2005-12-07 19:01:58 UTC
>  I have customers using Obj C++ who want to turn off C++
> exception support, but retain Obj C exception support.  [snip]

What does this even mean? Can you detail or explain how this is supposed to work?

> They are not trying to use C++ try/catch in a bizarre or unsupported manner.
> They are simply trying to use ObjC++ exceptions without the unwanted cost of
> C++ exceptions.

IMHO, yes, this is completely misguided, unsupported, bizarre, known to fail, and should be documented as such.

If you are going to go through and add in hacks to deal with -fno-exceptions for every C++/X language combo, then I'd be in favor of -fno-exceptions be changed so that the C++ FE takes care of the keywords, since at least then it'll all be taken care of in one place and would be consistently well-defined. I think that's the proper place to fix this.

Can you point out where Objective C++ -fno-exceptions behavior documented?

-benjamin
Comment 21 Andrew Pinski 2005-12-13 20:03:38 UTC
One more thing is that this is not documented anywhere (I can find) that libstdc++ does this.
Comment 22 Howard Hinnant 2006-01-11 15:30:14 UTC
Conforming C++ programs exist that work correctly with -fno-exceptions as long as they don't include any libstdc++ header.  These same programs can fail (at either compile time or run time) if they also include some (not all) libstdc++ header.

For example:

#include <stdio.h>

#define glue(a, b)  a ## b
#define xglue(a, b) glue(a, b)
#define tryLOW     "hello"
#define LOW         LOW ", world"

int main()
{
    printf("%s\n", xglue(try, LOW));
}

This is a conforming C++ program.  It should run and print out:

hello, world

And it does so for gcc whether or not -fno-exceptions.

However if the same program includes <vector> or <iostream> (just as an example), then the program runs only if -fno-exceptions is not specified.  Otherwise:

/Volumes/Data/Development/XcTest/main.cpp:12:1: error: pasting ")" and "LOW" does not give a valid preprocessing token
/Volumes/Data/Development/XcTest/main.cpp: In function 'int main()':
/Volumes/Data/Development/XcTest/main.cpp:12: error: expected primary-expression before 'if'

#define'ing try and catch is non-conforming.
Comment 23 gdr@cs.tamu.edu 2006-01-11 15:56:09 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| #define'ing try and catch is non-conforming.

You forgot to mentin that -fno-exceptions is neither mandated, nor
required to work with programs that play tricks with try/catch.
So, your assertion is unfounded.

-- Gaby
Comment 24 Howard Hinnant 2006-01-11 16:10:10 UTC
(In reply to comment #23)
> You forgot to mentin that -fno-exceptions is neither mandated, nor
> required to work with programs that play tricks with try/catch.
> So, your assertion is unfounded.

The demo program does not play tricks with try/catch.  It uses the identifier "try" in a completely conforming manner.

What subset of C++ programs do we expect to work under -fno-exceptions?  And where is that documented?  The only thing I can find in our documentation that addresses my question is:

>You may also wish to disable this option if you are compiling older
>C++ programs that don't use exception handling. 

My demo is exactly that:  A C++ program that does not use exception handling (and yet is still conforming).  And gcc (without libstdc++) handles it just fine.

Where do we document that some, but not all libstdc++ headers change the semantics of -fno-exception (as gcc documents it) and may render some conforming C++ programs broken?
Comment 25 gdr@cs.tamu.edu 2006-01-11 16:41:58 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #24 from hhinnant at apple dot com  2006-01-11 16:10 -------
| (In reply to comment #23)
| > You forgot to mentin that -fno-exceptions is neither mandated, nor
| > required to work with programs that play tricks with try/catch.
| > So, your assertion is unfounded.
| 
| The demo program does not play tricks with try/catch.

It does, with xlgue(try, ....).


| What subset of C++ programs do we expect to work under -fno-exceptions?

Those that understand that try/catch are special.

[...]

| >You may also wish to disable this option if you are compiling older
| >C++ programs that don't use exception handling. 
| 
| My demo is exactly that:  A C++ program that does not use exception handling
| (and yet is still conforming).

Can you provide standard specs that says the program must work with
-fno-exceptions?

| Where do we document that some, but not all libstdc++ headers change the
| semantics of -fno-exception (as gcc documents it) and may render some
| conforming C++ programs broken?

If the issue is that -fno-exceptions is not well documented, then we
should document it better.  I'm happy to review documentation patches
that reflect the current state. 

-- Gaby

Comment 26 Howard Hinnant 2006-01-11 18:02:05 UTC
(In reply to comment #25)
> Subject: Re:  exception_defines.h #defines try/catch
> | The demo program does not play tricks with try/catch.
> 
> It does, with xlgue(try, ....).
 
No, "try" in this context is not a keyword.  There is no try, no catch, no exception, in this conforming C++ program.
 
> | What subset of C++ programs do we expect to work under -fno-exceptions?
> 
> Those that understand that try/catch are special.

The intent of turning off exception handling in the compiler is to accomidate programs that are ignorant of try/catch, and have no need to process exceptions.
 
> Can you provide standard specs that says the program must work with
> -fno-exceptions?

Of course not.  Does this imply that we ought to lower our expectations of our product when exceptions are disabled such that it will seemingly randomly break conforming code?  Or are our quality standards higher than that?
 
> | Where do we document that some, but not all libstdc++ headers change the
> | semantics of -fno-exception (as gcc documents it) and may render some
> | conforming C++ programs broken?
> 
> If the issue is that -fno-exceptions is not well documented, then we
> should document it better.  I'm happy to review documentation patches
> that reflect the current state. 

I would rather not document that the libstdc++ takes a position contrary to the compiler and does not work with exception-ignorant but conforming code with -fno-exceptions.  Such a position would be hard to justify.
Comment 27 gdr@cs.tamu.edu 2006-01-12 00:12:11 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Or are our quality standards higher than that?

The way you solve this is neither through rhetorics, neither as a
libstdc++ PR.  The way you solve this is to make the front-end complete
-- try/catch are special with -fno-exceptions.  Really.

-- Gaby
Comment 28 gdr@cs.tamu.edu 2006-01-12 00:12:32 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #26 from hhinnant at apple dot com  2006-01-11 18:02 -------
| (In reply to comment #25)
| > Subject: Re:  exception_defines.h #defines try/catch
| > | The demo program does not play tricks with try/catch.
| > 
| > It does, with xlgue(try, ....).
| 
| No, "try" in this context is not a keyword.

I did not say it was a keyword.  I know what it is in that phase.

try/catch are special when -fno-exceptions.

[...]

| > Can you provide standard specs that says the program must work with
| > -fno-exceptions?
| 
| Of course not.

Then stop claiming that your use was conformant.

[...]

| I would rather not document that the libstdc++ takes a position
| contrary to the compiler

It does not take a position contrary to the compiler.  It complements
the compiler, with its own additional requirement.  That is not new.

-- Gaby
Comment 29 Howard Hinnant 2006-01-12 00:59:43 UTC
(In reply to comment #28)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> | No, "try" in this context is not a keyword.
> 
> I did not say it was a keyword.  I know what it is in that phase.
> 
> try/catch are special when -fno-exceptions.

In the preprocess stage, try/catch are not special when -fno-exceptions according to the compiler.  They are only special at this stage according to libstdc++, and for no reason I find convincing.
 
> | > Can you provide standard specs that says the program must work with
> | > -fno-exceptions?
> | 
> | Of course not.
> 
> Then stop claiming that your use was conformant.

*No* program is conformant if it uses -fno-exceptions (by definition).  I'm claiming that this demo is conforming if it does not use -fno-exceptions.  I'm also claiming that it does not use the C++ try, catch, or throw, and therefore is an excellent candidate to work correctly under -fno-exceptions.
 
> | I would rather not document that the libstdc++ takes a position
> | contrary to the compiler
> 
> It does not take a position contrary to the compiler.  It complements
> the compiler, with its own additional requirement.  That is not new.

The mere inclusion of <vector> breaks the conforming C++ program (under -fno-excepttions).

#include <stdio.h>
#include <vector>

#define glue(a, b)  a ## b
#define xglue(a, b) glue(a, b)
#define tryLOW     "hello"
#define LOW         LOW ", world"

int main()
{
    printf("%s\n", xglue(try, LOW));
}

I realize that once the customer specifies -fno-exceptions, all bets are off.  Nothing has to work.  Not g++, not libstdc++.  But there has obviously been effort to make g++ and libstdc++ work under this environment.  I'm simply pointing out that the effort could be improved.  Obviously no standard is going to back this view up.

We have a conforming C++ program, which does not use try/catch/throw, which works as expected under -fno-exceptions if you don't include <vector>, and breaks if you do.  I think libstdc++ can and should do better than that.  We have customer complaints on this issue.  I'm developing a library-based patch to improve our support in this area.

> The way you solve this is to make the front-end complete

If you want to lead an effort to improve support of this issue in the front end, that sounds really good to me.  Please do.  Note that this solution will still involve libstdc++ being changed to not #define try and catch (which is the fundamental problem).
Comment 30 gdr@cs.tamu.edu 2006-01-12 01:10:42 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #28)
| > Subject: Re:  exception_defines.h #defines try/catch
| > 
| > | No, "try" in this context is not a keyword.
| > 
| > I did not say it was a keyword.  I know what it is in that phase.
| > 
| > try/catch are special when -fno-exceptions.
| 
| In the preprocess stage, try/catch are not special when -fno-exceptions
| according to the compiler.

They are for libstdc++.  You can debate at length.  You won't change
that fundamental fact.  However, you'll make progress, when you
recognize that and solve the problem where it should be.

[...]
 
| I realize that once the customer specifies -fno-exceptions, all bets
| are off.  

Great.  Fix the problem in the front-end.

-- Gaby
Comment 31 gdr@cs.tamu.edu 2006-01-12 01:15:55 UTC
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| I'm simply pointing out that the effort could be improved.
| Obviously no standard is going to back this view up.

Great.  Then stopping making conformance claims.  Also consider the
suggestion made earlier that the root of the problem is elsewhere --
extend the front-end to be complete.

| We have a conforming C++ program, which does not use try/catch/throw, 

it uses the identifier "try".

| which
| works as expected under -fno-exceptions if you don't include <vector>, and
| breaks if you do.  I think libstdc++ can and should do better than that.  We
| have customer complaints on this issue.  I'm developing a library-based patch
| to improve our support in this area.

given than bkoz and I have already expressed our suggestion of no
further uglification of libstdc++, I'm waiting to see how the
library-based patch would look like.

-- Gaby
Comment 32 Andrew Pinski 2006-01-12 01:26:13 UTC
Subject: Re:  exception_defines.h #defines try/catch


On Jan 11, 2006, at 8:10 PM, gdr at cs dot tamu dot edu wrote:
> | I realize that once the customer specifies -fno-exceptions, all bets
> | are off.
>
> Great.  Fix the problem in the front-end.

As I said before, there is still a diagnostic issue and now it is worse 
with
doing that in the front-end since people don't read docs that well so 
we will
be getting bug reports about try/catch not doing the correct thing when
-fno-exceptions is supplied (yes I am serious).


-- Pinski

Comment 33 Howard Hinnant 2006-01-12 02:49:52 UTC
(In reply to comment #32)
> As I said before, there is still a diagnostic issue and now it is worse 
> with
> doing that in the front-end since people don't read docs that well so 
> we will
> be getting bug reports about try/catch not doing the correct thing when
> -fno-exceptions is supplied (yes I am serious).

Yes, excellent point.  Let's back up a minute:

What do we want to happen for this program (under -fno-exceptions)?

int main()
{
    try
    {
    }
    catch (...)
    {
    }
}

?

My recommendation would be something along the lines of:

error: exception handling disabled, use -fexceptions to enable

(which is what currently happens, good job all around).

Now:  what do we want to happen for this program:

#include <vector>

int main()
{
    try
    {
    }
    catch (...)
    {
    }
}

?

My recommendation:  Same as the last program.  Today's results:  Compiles with no diagnostic.

I don't think this is the best quality that we can offer, mainly due to the difference in behavior by merely including <vector>.

So it comes back to the first example:  What is the best solution for the customer if try/catch is used with -fno-exceptions?  Perhaps I am wrong that an error is best?  What do other compilers do in this situation?

EDG:

"ComeauTest.c", line 3: error: support for exception handling is disabled
      try
      ^

CodeWarrior:

Error   : exception handling option is disabled
HelloWorld.cp line 4    { 

If I'm wrong about a diagnostic being preferrable, I'm in good company.  And both of these products give the same result if <vector> is included.

If there is to be a front end fix, it would have to be special for #pragma GCC system_header.  Just seems like a lot of fuss just so you can read "try" instead of "__try" in a libstdc++ header.  But I have no objection to someone fixing the front end that way.
Comment 34 Lubos Lunak 2007-04-24 10:54:18 UTC
I think the reason why the discussion here is so complicated is that you libstdc++ people are, because of exception_defines.h, confused about what -fno-exceptions actually does. From comment #15: "Then, why what is this PR is about in the first place? -fno-exceptions turns try/catch into macros with specified semantics." That's clearly not true. It is libstdc++ that changes the try/catch keywords into macros and _changes_ their semantics. Also, again from comment #15: "It is also a simple fact that GCC documents what happens with -fno-exceptions." - Sorry, but where? The info/man pages only say "You may also wish to disable this option if you are compiling older C++ programs that don't use exception handling.", but it doesn't say anything more about -fno-exceptions.

What -fno-exceptions does (when libstdc++ is not used) is that it disables exceptions support. If any code requiring exceptions support is actually used, an error is generated (try compiling the testcase from comment #4 with -fno-exceptions and without the <string> include). This is the same like when asking for full ANSI compliance when compiling and using GNU extensions in the code.

What libstdc++ does is that it (silently, to make it even worse) globally changes the semantics of the try/catch keywords, preventing the compiler from producing the error message and changing the behaviour of the compiled code, which may lead to incorrect results.

Comment #2 also doesn't hold much of value, since if libstdc++ tries to be as much conforming as possible, why does it change semantics of C++ keywords? Also, if you argue against __try/__catch, why do you already use __throw_exception_again, which is just a different name for throw? If you can use this, you can as well use __try and __catch. Since try/catch can be redefined, try and catch used in the libstdc++ code clearly are not the actual normal C++ keywords.

Please do as the original comment says and use __try/__catch instead of changing semantics of C++ keywords. What libstdc++ now does is very clearly a bug. The severity of this bug should be also raised since this bug can silently change code behaviour of any code using libstdc++.
Comment 35 Paolo Carlini 2007-04-27 10:04:36 UTC
(In reply to comment #34)
> Also, if you argue against __try/__catch, why do you already use
> __throw_exception_again, which is just a different name for throw? If you can
> use this, you can as well use __try and __catch. Since try/catch can be
> redefined, try and catch used in the libstdc++ code clearly are not the actual
> normal C++ keywords.

I'm finding this, seemingly secondary, argument rather compelling. All in all, I'm personally coming to the conclusion that we should implement the change originally suggested by Howard, for many additional reasons, totally unrelated to Objective C. In other terms, in that way -fno-exceptions would be much more safe and much more useful, and, in any case, we would not be playing any trick which we are not playing already (as explained above).
Comment 36 Paolo Carlini 2007-04-27 12:04:04 UTC
Humm, probably, however, I'm finally getting Gaby's point about the front-end involvement (sorry, I wasn't really paying attention to this PR until a few days ago): if we implement something like Howard's change we would certainly solve many problems *but* we would regress in another area: some general user code (thus freely using try/catch blocks) would not compile anymore when -fno-exceptions is passed on the command line. I see why some people would not consider that a problem, because they are removing by hand try/catch from translation units not meant to use exceptions, but I consider that a defect anyway, or, at least, a very substantive change of behavior which must be seriously weighted. Instead, ideally, one would like to compile the *very same code* and just not generate the heavy exception machinery when -fno-exceptions is passed on the command line. I think that idea exists in the current design of the macros, maybe incompletely implemented (e.g., at least one library header must be included), and it's nice, very nice, by itself.

Now, that idea in principle it's perfectly doable, the only problem is that the front-end must be changed, isn't something we can do completely at the library level. Alternately, probably better in order not to break existing code, a new option could be added, which, essentially, at variance with the current -fno-exceptions, would parse try/catch normally, and then finally simply skip the semantics.
Comment 37 Howard Hinnant 2007-04-27 14:15:12 UTC
Thanks for looking at this issue.

Also consider Andrew's point about useful diagnostics, for example from comment #4.  And the followup to that point in #33 which includes field experience on how other compilers deal with this same option.  I.e. from this viewpoint, getting a compile time error when you use try/catch with -fnoexceptions is a feature, not a bug.
Comment 38 Paolo Carlini 2007-04-27 14:22:34 UTC
(In reply to comment #37)
> Thanks for looking at this issue.
> 
> Also consider Andrew's point about useful diagnostics, for example from
> comment #4.

Of course, if/when the front-end is changed as I was outlining, diagnostic would be emitted in such cases.

> And the followup to that point in #33 which includes field experience on
> how other compilers deal with this same option.  I.e. from this viewpoint,
> getting a compile time error when you use try/catch with -fnoexceptions is a
> feature, not a bug.

That would be a good argument for my last point: i.e., do not change the semantics of -fno-exceptions, provide instead a new switch, which would be different only in that the front-end would still accept syntactically exception constructs, only would not emit semantics for those. *If* we have that switch, then probably we could *additionally* change the library as you are suggesting, that would provide a complete set of features to the users, in my opinion.
 

Comment 39 Lubos Lunak 2007-04-27 14:41:44 UTC
I find the reasoning that this change should not be done because somebody possibly might be using the libstdc++'s different semantics of try/catch rather weak, for several reasons:
- it's not documented anywhere, at least I haven't found any such docs, so it's internal undocumented feature
- if somebody actually uses it, then they can simply switch to __try/__catch and be done with it; additionally compared to users who want normal try/catch keywords they have the advantage that the compiler will detect the problem, while with the current changed try/catch there's absolutely no detection besides non-working code
- finally, I find it very unlikely that there actually would be people using try/catch in the way libstdc++ does. You cannot "just not generate the heavy exception machinery" and hope it works. Code that explicitly uses exceptions relies on them, just like e.g. code using explicit NULL pointer checks relies on them. You cannot silently remove all "if( pointer == NULL )" checks in code and hope it works, because that would avoid error recovery code. The same way silently dumping catch blocks means dumping error recovery code. Libstc++ can work this way because it doesn't use exceptions on its own, it just has the try/catch #defines to be able to work with code both using and not using them. In general if somebody wants to write code not using exceptions they can simply not use them. Special cases like libstdc++ are special and people doing that should better known what they're doing.
Comment 40 Andrew Pinski 2008-04-24 08:40:05 UTC
*** Bug 36032 has been marked as a duplicate of this bug. ***
Comment 41 Andrew Pinski 2008-04-24 08:42:07 UTC
>I'd rather you work around this in objective-c or objective c++.
Well guess what, it is more than an objective-c or objective C++ issue as PR 36032 had a good example for why, it can produce wrong code:
  #include <iostream>

  int main()
  {
    if(true) try {} catch(int) {}
    else std::cout << "bla\n";
  }
Comment 42 Richard Biener 2008-06-02 11:48:50 UTC
Can we please do something about this?  Either make -fno-exceptions unconditionally always only execute the try block via frontend support (and not
only if you happen to include some libstdc++ header), or apply the suggested
fix of only fixing up the standard library and let user programs still using
exceptions when they specify -fno-exceptions error during compilation.

Thanks.
Comment 43 Paolo Carlini 2008-06-02 12:05:21 UTC
Ok, I will just implement the __try / __catch suggestion. Hopefully the other library maintainers will not disagree...
Comment 44 Benjamin Kosnik 2008-06-02 20:20:37 UTC
> Either make -fno-exceptions
> unconditionally always only execute the try block via frontend support (and not
> only if you happen to include some libstdc++ header)

This is my very strong preference. 

-fno-exceptions should be completely defined by cc1plus.

-benjamin

Comment 45 Paolo Carlini 2008-06-02 20:59:55 UTC
Frankly, at this point in the history of this issue, I don't have a strong opinion. If we decide for the library-only solution, I can do it quickly, just let me know.
Comment 46 Benjamin Kosnik 2008-06-02 22:27:17 UTC
To clarify, I would like to see this solution come into being:

1) -fno-exceptions
This flag turns off C++ exception handling support, which is indicated at compile time by __GXX_EXCEPTIONS being undefined. Use of the keywords try, catch, or throw produces an error. As a result, use of most C++ includes will fail. 

2) -ftransform-exceptions 
This flag transforms the C++ language such that the keywords try, catch, and throw change meaning. In particular, try blocks are executed "as if" transformed into "if (true)", catch blocks are executed "as if" transformed into "if (false)", and throw expressions are discarded. Although this will compile C++ code that uses exceptions, please note that the resulting error handling and code paths are decidedly different and is almost certainly not what the original authors intended. 

At this point, exception_defines.h can just get junked, __throw_exception_again mechanically changed into throw, documentation updated that reprobates that had been happily using -fno-exceptions should just use -ftransform-exceptions, etc. There will be bitching about this change of course, but separating out these two things will be a blessing for GNU users.  

I believe this solution would fix the problem for all the various communities:

1) C++ purists who want to be able to use all the C++ keywords without increasing levels of macro uglification
2) C hackers that want to write pseudo C++, or take existing C++ code and "run it without exceptions"
3) C++ and ObjC++ people who want accurate diagnostics with and without -fno-exceptions will get them. 

Perhaps this would solve Howard's issue with -fno-exceptions C++ code and ObjC++ code that uses exceptions, but I don't really understand that issue. 

-benjamin

Comment 47 Martin Sebor 2008-06-02 23:08:35 UTC
(In reply to comment #46)
[...]
> 2) -ftransform-exceptions 

should catch(X) expand into "else if (false)" rather than just "if (false)?"

That said, I don't think there is a way to do this using the preprocessor
alone. Consider that

    try { foo (); }
    catch (SomeException ex) {
        puts (ex.what ());
    }

will preprocess to:

    try { foo (); }
    if (false) {
        puts (ex.what ());   // <<< ex undefined
    }
Comment 48 Martin Sebor 2008-06-03 00:07:55 UTC
FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
in the C++ front end:

1. "try" is a no-op
2. "catch" blocks are syntax-checked but eliminated as dead code
3. "throw" checks to see if a user-defined handler is installed and if so,
   calls it with useful arguments (e.g., the what() string); if no handler
   is installed or if it returns, std::terminate() is called
4. function exception specification is diagnosed as a warning but otherwise
   ignored (libc, libsupc++, and libstdc++ header should compile cleanly)

libsupc++ provides a __set_xxx() function to let users install the handler.

AFAIK, IBM XLC++ implements 1, 2, and 4 when -qnoeh is used. Apache stdcxx
implements 3 for exceptions thrown by the library.
Comment 49 Paolo Carlini 2008-06-03 09:52:16 UTC
(In reply to comment #48)
> FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
> in the C++ front end:

FWIW, I find your suggestion very sensible and probably have already vaguely hinted to something along these lines in the past. Then the PR is less and less a library one and I'm afraid we have to strong arm a solid C++-front-end hacker if we want to see progress in the near future...
Comment 50 rguenther@suse.de 2008-06-03 10:00:11 UTC
Subject: Re:  exception_defines.h #defines try/catch

On Tue, 3 Jun 2008, paolo dot carlini at oracle dot com wrote:

> ------- Comment #49 from paolo dot carlini at oracle dot com  2008-06-03 09:52 -------
> (In reply to comment #48)
> > FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
> > in the C++ front end:
> 
> FWIW, I find your suggestion very sensible and probably have already vaguely
> hinted to something along these lines in the past. Then the PR is less and less
> a library one and I'm afraid we have to strong arm a solid C++-front-end hacker
> if we want to see progress in the near future...

Well, can't we simply remove the libstdc++ #defines then and declare
libstdc++ unsupported for -fno-exceptions until the FE fixes it properly?

IMHO the libstdc++ #defines are clearly a bug.

Richard.
Comment 51 Paolo Carlini 2008-06-03 10:03:29 UTC
(In reply to comment #50)
> Well, can't we simply remove the libstdc++ #defines then and declare
> libstdc++ unsupported for -fno-exceptions until the FE fixes it properly?
> 
> IMHO the libstdc++ #defines are clearly a bug.

Maybe, but a very, very old one ;) That said, if the other library maintainers want that, I do not object.
Comment 52 Richard Biener 2008-09-22 12:40:50 UTC
Can we please have

"1) -fno-exceptions
This flag turns off C++ exception handling support, which is indicated at
compile time by __GXX_EXCEPTIONS being undefined. Use of the keywords try,
catch, or throw produces an error. As a result, use of most C++ includes will
fail."

of comment #46 simply by the original suggestion, make the standard library
use __try and __catch and change libsupc++/exception_defines.h accordingly?
Appearantly the library wants to work without exception support, but this
support needs to be implemented in a way not messing with standard C++
keywords.

Note the frontend already undefines __EXCEPTIONS for -fno-exceptions:

>g++ -dD -E t.C | grep EXCE
#define __EXCEPTIONS 1
> g++ -dD -E t.C -fno-exceptions | grep EXCE

The frontend also produces an error if try or catch are used with -fno-exceptions, but the _standard library implementation_ causes this
error do disappear(!)  Which is what this bug is about really.

It seems the library maintainers are not willing to see this problem.
Asking for a new C++ frontend feature as an excuse to not fix the
library problem is very lame IMHO.

So can we please - finally - do something about this?

Thank you very much.
Richard.
Comment 53 Richard Biener 2008-09-22 12:41:48 UTC
CCing C++ FE maintainers.
Comment 54 Paolo Carlini 2008-09-22 14:08:46 UTC
(In reply to comment #52)
> It seems the library maintainers are not willing to see this problem.
> Asking for a new C++ frontend feature as an excuse to not fix the
> library problem is very lame IMHO.

For the record, speaking of myself, see Comments #43 and #45.
Comment 55 Jason Merrill 2008-09-23 20:43:57 UTC
It seems reasonable to me for try { X } catch... to mean X when -fno-exceptions.  We don't need to error except on throw.
Comment 56 Lubos Lunak 2008-09-24 08:50:44 UTC
(In reply to comment #55)
> It seems reasonable to me for try { X } catch... to mean X when
> -fno-exceptions.  We don't need to error except on throw.

It seems unreasonable to me that gcc would silently modify code's behaviour, just like it would be unreasonable that -pedantic would silently change 'long long i = 2LL << 34;' to 'long i = 0;'. With today's complex build systems it is not that difficult to get -fno-exceptions without noticing and then get code that works differently than intended (and I'm not making this up, I had such a real case).
If people really want code with exception handling to work with both -fexception states, then they need to write the code with that in mind and then they can as well just use __try/__catch macros the way libstdc++ does now, just without breaking the code for the rest of people who can run into trouble if the compiler/libraries try to outguess them.
Comment 57 Mark Mitchell 2008-09-24 13:03:15 UTC
Subject: Re:  exception_defines.h #defines try/catch

jason at gcc dot gnu dot org wrote:
> ------- Comment #55 from jason at gcc dot gnu dot org  2008-09-23 20:43 -------
> It seems reasonable to me for try { X } catch... to mean X when
> -fno-exceptions.  We don't need to error except on throw.

We have to be careful, in some cases.  For example:

  extern int f();

  template <typename T>
  struct S {
    static int i;
  };
  template <typename T>
  int S<T>::i = f();

 int main() {
    try {
      return 0;
    } catch (...) {
      return S<int>::i;
    }
  }

This program, IIRC, is guaranteed to call "f", as a side-effect of the
presence of the catch-clause?  Of course, the C++ FE could still process
the "catch" clause; my only point is that we cannot literally just throw
away the catch clause.

I don't objection to -fno-exceptions silently discarding catch clauses,
as long as we avoid the kind of problem above.

Comment 58 Jason Merrill 2008-09-24 19:21:42 UTC
Subject: Re:  exception_defines.h #defines try/catch

l dot lunak at suse dot cz wrote:
> ------- Comment #56 from l dot lunak at suse dot cz  2008-09-24 08:50 -------
> (In reply to comment #55)
>> It seems reasonable to me for try { X } catch... to mean X when
>> -fno-exceptions.  We don't need to error except on throw.
> 
> It seems unreasonable to me that gcc would silently modify code's behaviour,

The change I was talking about doesn't modify behavior.  If there are no 
exceptions, catch blocks will never be executed, so we can optimize them 
away in the presence of -fno-exceptions.

> This program, IIRC, is guaranteed to call "f", as a side-effect of the
> presence of the catch-clause?  Of course, the C++ FE could still process
> the "catch" clause; my only point is that we cannot literally just throw
> away the catch clause.

True, it would be more like { X } if (0) ...

Jason

Comment 59 Lubos Lunak 2008-09-25 09:56:06 UTC
(In reply to comment #58)
> >> It seems reasonable to me for try { X } catch... to mean X when
> >> -fno-exceptions.  We don't need to error except on throw.
> > 
> > It seems unreasonable to me that gcc would silently modify code's behaviour,
> 
> The change I was talking about doesn't modify behavior.  If there are no 
> exceptions, catch blocks will never be executed, so we can optimize them 
> away in the presence of -fno-exceptions.

But only in your perfect world. This bug and its silent discarding of exception handling code (and an unintended -fno-exception from the build system) made us release a broken package. If you want to add support for discarding of explicitly written exceptions code, ok, whatever, but please make it explicit, because having it the way it is with this bug is rather pointless (since then either you don't use exceptions at all and then there's no need to write the exception handling code, or you mix it and then you soon may find it simpler to drop the -fno-exception rather than explicitly check all code paths after you refactor something).
Comment 60 Jason Merrill 2008-09-26 21:57:01 UTC
Subject: Re:  exception_defines.h #defines try/catch

l dot lunak at suse dot cz wrote:
> But only in your perfect world. This bug and its silent discarding of exception
> handling code (and an unintended -fno-exception from the build system) made us
> release a broken package.

-fno-exceptions is a big hammer.  It will break exceptions trying to 
pass through code compiled with that flag whether or not that code has 
any try/catch constructs.  If you might have some code that throws, you 
shouldn't use -fno-exceptions; that's what broke your package.  Getting 
an error on try would have helped you find that problem, but that 
doesn't mean it's the right answer for all situations; if I'm writing 
code that may be used by other programs, I should write it to be 
exception-safe even if I don't throw any exceptions myself.

Perhaps we could just warn once if we see try/catch outside library 
headers with -fno-exceptions.

Jason

Comment 61 Jason Merrill 2008-11-19 21:42:31 UTC
Created attachment 16725 [details]
Compiler patch to allow try/catch and rethrow under -fno-exceptions

I've attached a proposed patch to ignore try/catch/rethrow in the compiler with a warning, which should make the libstdc++ header unnecessary.  Comments?
Comment 62 Lubos Lunak 2008-11-19 22:41:35 UTC
(In reply to comment #60)
> -fno-exceptions is a big hammer.  It will break exceptions trying to 
> pass through code compiled with that flag whether or not that code has 
> any try/catch constructs.  If you might have some code that throws, you 
> shouldn't use -fno-exceptions; that's what broke your package.

 In that case I suggest you remove -fno-exceptions altogether, because it's virtually impossibly for any non-trivial C++ application to make sure it doesn't use any code that might throw, starting with operator new. Sorry, but it's about as sensible argument as yours.

 Let me put it simply: -fno-exceptions is an optimization that saves generating code that would not be used, in line with the C++ rule of not paying for what one does not use. So it simply makes sense to use it in projects (or parts thereof) that do no use exceptions in order to get some savings (does somebody use -fno-exceptions in any other way?). Now, such code calls code from elsewhere that may throw, and so the programmer uses also try-catch, but does not actually test that specific part, since a) it's trivial code, b) he's too busy and we're just people, c) getting an exception should be exceptional. And we have perfectly fine code that compiles, but, when it eventually comes, does not work. It may not happen in your perfect world but in the real one it does.

> Getting an error on try would have helped you find that problem, but that 
> doesn't mean it's the right answer for all situations;

 And what other situations are there, except for people who write code with exception handling, who make sure it works even without exceptions, who are too lazy to run sed few times, who will be explicitly aware of this and who presumably will be just a handful of people in total compared to the rest? What's the problem with giving these people -fstrip-exceptions or whatever and leaving the rest as it is (with fixing libstdc++)?

> if I'm writing 
> code that may be used by other programs, I should write it to be 
> exception-safe even if I don't throw any exceptions myself.

 Irrelevant, this is the other way around.

> Perhaps we could just warn once if we see try/catch outside library 
> headers with -fno-exceptions.

 I'd love to live in your perfect world. Sadly, I don't, so I'm looking forward to having to take care of code that will not have -Wexceptions in its flag (since it needs to be explicitly enabled, right?) or where one warning will get easily overlooked for whatever reason. I really fail to see what's so complicated about not letting one shoot themselves in the foot just because of lazy people with special needs. Thanks for trying, anyway.
Comment 63 Richard Biener 2008-11-20 10:01:10 UTC
The patch looks reasonable.  I understand that the warning is enabled by default
but does not trigger from libstdc++ because that's system headers.
Comment 64 Paolo Carlini 2008-11-20 10:24:39 UTC
(assuming I understand correctly Jason' approach - didn't really follow in detail the thread, lately) let me know if you want me to remove the exception_defines.h tricks from the library...
Comment 65 Jason Merrill 2008-11-20 15:14:17 UTC
Subject: Re:  exception_defines.h #defines try/catch

No, it doesn't make any sense to use try/catch in a program that you're 
planning to build with -fno-exceptions.  It does, however, make sense to 
use try/catch in a general purpose library that you want to work with 
exceptions enabled or disabled, such as libstdc++.

I believe Lubos is arguing that such libraries ought to use preprocessor 
tricks to accomplish this, but defining something like __try and __catch 
instead of try and catch.  The difference between this approach and my 
patch is that it requires the library writer to jump through hoops to 
make their code work with exceptions enabled and disabled.  I guess 
Lubos thinks this is good, that this is an unusual thing to want to do 
and so people that want to do it need to be very explicit about it so 
that people who don't want that but mistakenly build their code with 
-fno-exceptions get an error rather than a warning.

Anyone else have an opinion about this?

And yes, -Wexceptions is on by default in my patch.

Comment 66 Howard Hinnant 2008-11-20 17:40:13 UTC
(In reply to comment #65)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> No, it doesn't make any sense to use try/catch in a program that you're 
> planning to build with -fno-exceptions.  It does, however, make sense to 
> use try/catch in a general purpose library that you want to work with 
> exceptions enabled or disabled, such as libstdc++.
> 
> I believe Lubos is arguing that such libraries ought to use preprocessor 
> tricks to accomplish this, but defining something like __try and __catch 
> instead of try and catch.  The difference between this approach and my 
> patch is that it requires the library writer to jump through hoops to 
> make their code work with exceptions enabled and disabled.  I guess 
> Lubos thinks this is good, that this is an unusual thing to want to do 
> and so people that want to do it need to be very explicit about it so 
> that people who don't want that but mistakenly build their code with 
> -fno-exceptions get an error rather than a warning.
> 
> Anyone else have an opinion about this?
> 
> And yes, -Wexceptions is on by default in my patch.

I've tried really hard to just stay out of this one. :-)  I think Jason makes a good argument.  However I just surveyed a bunch of my own code written to work both with and without exceptions enabled, using "macro hoops".  In about 95% of the cases transforming:

try
{
   X
} 
catch (Y)
{
   Z
}

to just:

X

is exactly what I want.  In the other 5% of the cases it is not.  In these (relatively rare, but not uncommon) cases, the code under X gets transformed into code that checks return values for error codes and acts on that error code:

int er = X
if (er)
   return P

This scenario usually pops up when X is doing an allocation which throws when exceptions are enabled and returns null when exceptions are disabled.

All that being said, is Jason's patch good or bad?  <shrug>  I'm still going to have to manually design 100% of my try/catch clauses for exceptions enabled and disabled.  If I don't, then I'll have a 5% bug rate even with Jason's patch.  Part of me would prefer the error just to ensure that I haven't forgotten to design for the exceptions-disabled case, even if that design would simply translate to X.  Perhaps the warning will fill that role, I do not know.
Comment 67 Mark Mitchell 2008-11-20 17:55:35 UTC
I think that the current libstdc++ behavior is undesirable, for the reasons that Howard says.  In particular, the fact that including a libstdc++ header can result in definitions of "try" and "catch" as macros is bad, even though, of course, that happens only in the -fno-exceptions mode.  I find comments about exceptions being a standard part of the language unpersuasive; while that is of course true, G++ is certainly used by people who wan the "C++ without exceptions" language and not supporting that well would put us at a competitive disadvantage relative to other C++ compilers.

I think that changing libstdc++ to use __try, __catch, etc. is reasonable.  That's certainly the approach used in other libraries.  However, I also think Jason's patch is reasonable, provided of course that the documentation is updated to reflect this new behavior.  

If I recall correctly, unwinding into a frame with no EH data will cause a runtime abort, so programs will not silently skip catch clauses that have been compiled away.  The program may fail, but at least it will not do so silently.  Jason, is that correct?
Comment 68 Jason Merrill 2008-11-20 18:10:11 UTC
Subject: Re:  exception_defines.h #defines try/catch

mmitchel at gcc dot gnu dot org wrote:
> If I recall correctly, unwinding into a frame with no EH data will cause a
> runtime abort, so programs will not silently skip catch clauses that have been
> compiled away.  The program may fail, but at least it will not do so silently. 
> Jason, is that correct?

Yes.  If the unwinder runs out of unwind info before it finds a handler, 
we call terminate().
Comment 69 Andrew Pinski 2008-11-21 22:19:38 UTC
I think this patch will not handle:
int main(void)
{
  try {
  }catch (int &a)
  {
    a = 1;
  }
}

-- CUT ---
In fact exception_defines.h's defines does not handle them correctly anyways.
I am working on a patch which adds -fignore-exceptions which has to be used with -fno-exceptions which handles this correctly.  Plus we don't get erroneous errors with -fno-exceptions now too.  Should -fignore-exceptions be default for C++ when -fno-exceptions is used?
Comment 70 Andrew Pinski 2008-11-21 22:21:18 UTC
Also my -fignore-exceptions calls __built_trap for a throw and make sure that throw with an expression that the expression is evaluated.
Comment 71 Andrew Pinski 2008-11-21 22:23:53 UTC
Created attachment 16744 [details]
My current patch for -fignore-exceptions

Note I have not added the testsuite part yet and this is based on 4.1.1 rather than the trunk since I just happen to be working on this for the PS3 compiler.
Comment 72 Andrew Pinski 2008-11-21 23:08:56 UTC
Created attachment 16745 [details]
Updated patch with some testcases

Here is updated patch which allows more try/catch to work correctly without any errors.  Plus it includes some testcases (sorry about the DOS line endings, and about where the testcases are).  This again is against 4.1.1.
Comment 73 Jason Merrill 2008-11-23 00:02:06 UTC
Subject: Re:  exception_defines.h #defines try/catch

pinskia at gcc dot gnu dot org wrote:
> I think this patch will not handle:
> int main(void)
> {
>   try {
>   }catch (int &a)
>   {
>     a = 1;
>   }
> }

Ah yes, I probably still need to push the declaration of a.

> I am working on a patch which adds -fignore-exceptions which has to be used
> with -fno-exceptions which handles this correctly.

This sounds like the wrong approach to me.  libstdc++ needs to work with 
or without -fno-exceptions, it shouldn't require another flag.  And I 
don't see the point in allowing 'throw expr;' under -fno-exceptions; I 
don't think the compiler can come up with another error reporting 
mechanism by itself.

Jason
Comment 74 Jason Merrill 2009-02-02 20:27:18 UTC
Since my suggested patch proved somewhat controversial, for 4.4 I'd like to fall back on the simpler solution that Howard proposed in the initial bug report; it is inappropriate for library headers to redefine keywords.
Comment 75 Mark Mitchell 2009-02-02 20:29:24 UTC
Subject: Re:  exception_defines.h #defines try/catch

jason at gcc dot gnu dot org wrote:

> Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
> fall back on the simpler solution that Howard proposed in the initial bug
> report; it is inappropriate for library headers to redefine keywords.

Makes sense to me.

Comment 76 Paolo Carlini 2009-02-02 21:11:03 UTC
Ok, let's wait a couple of days and, assuming there are no objections, I volunteer to implement that.
Comment 77 Paolo Bonzini 2009-02-03 17:10:05 UTC
Can't the library just #undef try/catch at the end of each file that includes exception_defines.h?
Comment 78 Paolo Carlini 2009-02-03 17:14:36 UTC
Nope, we never do that.
Comment 79 Paolo Bonzini 2009-02-03 17:15:48 UTC
Yeah, but it seems better than uglifying __try/__catch all over the place...
Comment 80 Paolo Carlini 2009-02-03 17:20:41 UTC
Many solutions are better, in principle, but really this issue is too old. After all we are uglifying also in other cases. Let's do that and be done with it. Unless there are objections (or, better, constructive proposals, aka patches) that the library solutions is an improvement.
Comment 81 paolo@gcc.gnu.org 2009-02-03 23:45:20 UTC
Subject: Bug 25191

Author: paolo
Date: Tue Feb  3 23:44:53 2009
New Revision: 143913

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143913
Log:
2009-02-03  Paolo Carlini  <paolo.carlini@oracle.com>

	PR libstdc++/25191	
	* libsupc++/exception_defines.h: Depending on __EXCEPTIONS,
	deal consistently with __try and __catch too.
	* src/localename.cc: Replace try -> __try, catch -> __catch.
	* src/ios.cc: Likewise.
	* src/locale.cc: Likewise.
	* src/istream.cc: Likewise.
	* src/thread.cc: Likewise.
	* src/compatibility.cc: Likewise.
	* src/bitmap_allocator.cc: Likewise.
	* src/ios_init.cc: Likewise.
	* include/debug/deque: Likewise.
	* include/debug/list: Likewise.
	* include/tr1_impl/hashtable: Likewise.
	* include/std/bitset: Likewise.
	* include/ext/pb_ds/detail/resize_policy/
	hash_load_check_resize_trigger_imp.hpp: Likewise.
	* include/ext/pb_ds/detail/resize_policy/
	hash_standard_resize_policy_imp.hpp: Likewise.
	* include/ext/pb_ds/detail/cc_hash_table_map_/
	resize_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/cc_hash_table_map_/
	constructor_destructor_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/pat_trie_/
	split_join_branch_bag.hpp: Likewise.
	* include/ext/pb_ds/detail/pat_trie_/
	constructors_destructor_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/bin_search_tree_/
	constructors_destructor_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/gp_hash_table_map_/
	resize_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/gp_hash_table_map_/
	constructor_destructor_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/binary_heap_/
	constructors_destructor_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/binary_heap_/
	erase_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/binary_heap_/
	split_join_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/left_child_next_sibling_heap_/
	constructors_destructor_fn_imps.hpp: Likewise.
	* include/ext/pb_ds/detail/debug_map_base.hpp: Likewise.
	* include/ext/pb_ds/detail/list_update_map_/
	constructor_destructor_fn_imps.hpp: Likewise.
	* include/ext/slist: Likewise.
	* include/ext/memory: Likewise.
	* include/ext/rc_string_base.h: Likewise.
	* include/ext/ropeimpl.h: Likewise.
	* include/ext/vstring.tcc: Likewise.
	* include/ext/rope: Likewise.
	* include/ext/sso_string_base.h: Likewise.
	* include/bits/shared_ptr.h: Likewise.
	* include/bits/stl_list.h: Likewise.
	* include/bits/locale_classes.tcc: Likewise.
	* include/bits/locale_facets.tcc: Likewise.
	* include/bits/locale_classes.h: Likewise.
	* include/bits/forward_list.h: Likewise.
	* include/bits/stl_vector.h: Likewise.
	* include/bits/stl_deque.h: Likewise.
	* include/bits/istream.tcc: Likewise.
	* include/bits/stl_uninitialized.h: Likewise.
	* include/bits/ostream.tcc: Likewise.
	* include/bits/vector.tcc: Likewise.
	* include/bits/stl_tempbuf.h: Likewise.
	* include/bits/deque.tcc: Likewise.
	* include/bits/basic_string.tcc: Likewise.
	* include/bits/ostream_insert.h: Likewise.
	* include/bits/locale_facets_nonio.tcc: Likewise.
	* include/bits/stl_tree.h: Likewise.
	* include/bits/fstream.tcc: Likewise.
	* include/tr1/shared_ptr.h: Likewise.
	* include/tr1/hypergeometric.tcc: Likewise.
	* include/backward/hashtable.h: Likewise.
	* libsupc++/exception_ptr.h: Likewise.
	* libsupc++/eh_personality.cc: Likewise.
	* libsupc++/eh_call.cc: Likewise.
	* config/locale/gnu/monetary_members.cc: Likewise.
	* config/locale/gnu/time_members.h: Likewise.
	* config/locale/generic/time_members.h: Likewise.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/locale/generic/time_members.h
    trunk/libstdc++-v3/config/locale/gnu/monetary_members.cc
    trunk/libstdc++-v3/config/locale/gnu/time_members.h
    trunk/libstdc++-v3/include/backward/hashtable.h
    trunk/libstdc++-v3/include/bits/basic_string.tcc
    trunk/libstdc++-v3/include/bits/deque.tcc
    trunk/libstdc++-v3/include/bits/forward_list.h
    trunk/libstdc++-v3/include/bits/fstream.tcc
    trunk/libstdc++-v3/include/bits/istream.tcc
    trunk/libstdc++-v3/include/bits/locale_classes.h
    trunk/libstdc++-v3/include/bits/locale_classes.tcc
    trunk/libstdc++-v3/include/bits/locale_facets.tcc
    trunk/libstdc++-v3/include/bits/locale_facets_nonio.tcc
    trunk/libstdc++-v3/include/bits/ostream.tcc
    trunk/libstdc++-v3/include/bits/ostream_insert.h
    trunk/libstdc++-v3/include/bits/shared_ptr.h
    trunk/libstdc++-v3/include/bits/stl_deque.h
    trunk/libstdc++-v3/include/bits/stl_list.h
    trunk/libstdc++-v3/include/bits/stl_tempbuf.h
    trunk/libstdc++-v3/include/bits/stl_tree.h
    trunk/libstdc++-v3/include/bits/stl_uninitialized.h
    trunk/libstdc++-v3/include/bits/stl_vector.h
    trunk/libstdc++-v3/include/bits/vector.tcc
    trunk/libstdc++-v3/include/debug/deque
    trunk/libstdc++-v3/include/debug/list
    trunk/libstdc++-v3/include/ext/memory
    trunk/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/constructors_destructor_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/erase_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/split_join_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/constructor_destructor_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/resize_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/debug_map_base.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/resize_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/left_child_next_sibling_heap_/constructors_destructor_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/list_update_map_/constructor_destructor_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/pat_trie_/split_join_branch_bag.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_standard_resize_policy_imp.hpp
    trunk/libstdc++-v3/include/ext/rc_string_base.h
    trunk/libstdc++-v3/include/ext/rope
    trunk/libstdc++-v3/include/ext/ropeimpl.h
    trunk/libstdc++-v3/include/ext/slist
    trunk/libstdc++-v3/include/ext/sso_string_base.h
    trunk/libstdc++-v3/include/ext/vstring.tcc
    trunk/libstdc++-v3/include/std/bitset
    trunk/libstdc++-v3/include/tr1/hypergeometric.tcc
    trunk/libstdc++-v3/include/tr1/shared_ptr.h
    trunk/libstdc++-v3/include/tr1_impl/hashtable
    trunk/libstdc++-v3/libsupc++/eh_call.cc
    trunk/libstdc++-v3/libsupc++/eh_personality.cc
    trunk/libstdc++-v3/libsupc++/exception_defines.h
    trunk/libstdc++-v3/libsupc++/exception_ptr.h
    trunk/libstdc++-v3/src/bitmap_allocator.cc
    trunk/libstdc++-v3/src/compatibility.cc
    trunk/libstdc++-v3/src/ios.cc
    trunk/libstdc++-v3/src/ios_init.cc
    trunk/libstdc++-v3/src/istream.cc
    trunk/libstdc++-v3/src/locale.cc
    trunk/libstdc++-v3/src/localename.cc
    trunk/libstdc++-v3/src/thread.cc

Comment 82 Paolo Carlini 2009-02-03 23:46:42 UTC
Fixed for 4.4.0.