[Bug libstdc++/6257] C-library symbols enter global namespace
--- Comment #24 from gdr at integrable-solutions dot net 2006-04-30 23:05 --- Subject: Re: C-library symbols enter global namespace "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #20) | > the | > very same source code would not be be portable across those targets. I don't | > think we would like that. Besides, more generally, I'm not at all sure that | > all the users would actually *like* the new behavior. | | I meant proposing it as a choice, with a flag like -fclean-global-namespace That is a non-starter. PR better suspended. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #31 from gdr at integrable-solutions dot net 2006-05-01 18:55 --- Subject: Re: hidden declarations klobber STL "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | Well, two comments: first, I cannot reproduce with current mainline. Second, | frankly, if the implication of the issue is that in the entire implementation | of we cannot use operator, only to allow the user to write | unrestricted operator, templates in the face of the ADL trickeries, then, well, | I don't think we are going to buy that. Before closing this I'm only curious to | know why mainline is fine, maybe, simply, ADL was too zelant here? Any language | lawyer kicking in? Why is operator, essential to libstdc++? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #32 from gdr at integrable-solutions dot net 2006-05-01 18:59 --- Subject: Re: hidden declarations klobber STL "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | --- Comment #14 from pcarlini at suse dot de 2006-04-20 09:37 --- | (In reply to comment #12) | > I don't think that the problem is in the STL. The STL can be as tricky as it | > wants, including use of operator,(). It should not be possible for the actual | > operator,()s I declared to hijack the STL the way that happened, because 1) my | > declarations were out of scope for the STL code and 2) their signatures did not | > match the STL call site. This suggests a compiler bug to me, not an STL | > mis-design. | | Actually, I'm not at all sure, given: 1- our vector<>::iterator not being a | built-in type; 2- ADL rules. 3- The nature of fill_n (templated on *both* _Size | and _OutputIterator). Again, I'm not a language lawyer, but I think that, | strictly speaking, the compiler may legally find and match your operator, Yes. | I can certainly patch fill_n to avoid the operator, no big deal, my question is | more general, whether, given our class-type vector<>::iterator, given the | "unrestrictedness" of many templates, given current ADL rules, | whether it makes sense for us to go that route trying piecewise to "improve" | now the library, in the current C++03 framework. I believe it makes sense to do so the extent we can -- we (e.g. *you*) did patch the library so that qualified call where OK, e.g. std::copy, where we did so only for implementation details. The use of operator, in this case is no different. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #33 from gdr at integrable-solutions dot net 2006-05-01 19:02 --- Subject: Re: hidden declarations klobber STL "bangerth at dealii dot org" <[EMAIL PROTECTED]> writes: | I mean, it's a miracle your code actually does what you expect. :-)) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #12 from gdr at integrable-solutions dot net 2006-05-01 20:45 --- Subject: Re: goto crossing P.O.D. initialization "falk at debian dot org" <[EMAIL PROTECTED]> writes: | I think this is a valid request. While random language extensions aren't | useful, | compatibility with C99 is. Maybe somebody else can comment on this... You have to be more precise about what you mean by C99 compatibility. My take on this goto stuff, if it is not valid C++, it is valid C++. Period. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #13 from gdr at integrable-solutions dot net 2006-05-01 20:47 --- Subject: Re: goto crossing P.O.D. initialization "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | PR 27252 (aka PR 9278) is another example where C and C++ diff and in fact was | just fixed for 4.2.0 for a bug report. These are just some examples of where C | and C++ differ. I fully agree. People have to be extra careful when they talk about compatibility with C99 where the C committee has carefully chosen to depart from C++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #14 from gdr at integrable-solutions dot net 2006-05-01 20:48 --- Subject: Re: goto crossing P.O.D. initialization "acahalan at gmail dot com" <[EMAIL PROTECTED]> writes: | I only ask that C compatibility be provided for code that would otherwise fail | to compile as C++. This makes code reuse much easier. Given prior existence in C++, I think logic would require that you ask gcc to be compatibile with g++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #16 from gdr at integrable-solutions dot net 2006-05-01 23:30 --- Subject: Re: goto crossing P.O.D. initialization "falk at debian dot org" <[EMAIL PROTECTED]> writes: | --- Comment #15 from falk at debian dot org 2006-05-01 20:55 --- | (In reply to comment #12) | > Subject: Re: goto crossing P.O.D. initialization | > | > "falk at debian dot org" <[EMAIL PROTECTED]> writes: | > | > | I think this is a valid request. While random language extensions aren't | > | useful, | > | compatibility with C99 is. Maybe somebody else can comment on this... | > | > You have to be more precise about what you mean by C99 compatibility. | | I have trouble seeing what might be unclear about this term. I suspect part of the problem is that everybody believes that his/her uses of the term are so clear that they he/she has trouble seeing anybody disagree with him/her. | I mean that code | that is valid C99 is accepted in C++ unless there is a good reason not to. And why not the other way around? I mean, codes that is valid C++ is accepted in C99 unless there is good reason not to. As far as I can see, that also is compatibility. | just like most of C89 is accepted in C++ unless there is a good reason not to. I suspect this is might be one the places things needs to be explained. If * only a subset of C89 is valid C++ and has same meaning as in C++, * C99 has carefully departed from both C89 and C++ why is it that "code that is valid C99 is accepted C++ unless there is a good reason not to"? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- Comment #7 from gdr at integrable-solutions dot net 2006-05-01 23:39 --- Subject: Re: valarray uses __cos which may conflict with libm functions "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #4) | > Should all those private classes and functions be declared in some | > specific namespace std::glibcxx_private to have a single point of failure? | | Oups, I just noticed that was one of the roles of __gnu_cxx (although I don't | understand why this namespace is not a subnamespace of std:: as tr1 (or at | least contains a using namespace std;), Why shall it? Before people suggest more tricky playing with libstdc++ name spaces, I would recommand people understand that namespaces are not silver bullet against machivelic playing with names. | which would at the same time fix things | like getenv not being prefixed by std:: in ext/mt_allocator.h). That is a separate problem that does not require namespace nesting. Nesting namespaces does not come for free. You really need to understand its consequences (name lookp, overload resolution, etc.) before proposing it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #57 from gdr at integrable-solutions dot net 2006-05-09 15:15 --- Subject: Re: __cplusplus defined to 1, should be 199711L "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #30) | > Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8 | | Out of curiosity, why not deal with __cplusplus the same way as __STDC__ (0 for | standard headers and 1 elsewhere IIRC) instead, or even defining it to 1 | directly for this platform? If I include stdlib.h (not cstdlib), I won't | include c++config.h first, and it should cause trouble with this approach. other standard headers might directly or indrectly include , so any macro game should work properly. I see c++config.h as a "built-in" header that should be always there anyway we are processing a C++ program. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #3 from gdr at integrable-solutions dot net 2006-05-11 16:24
---
Subject: Re: New: template function not recognized when invoked with enum
defined in function
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| Compiling this file, with mainline, gcc 4.0, or 4.1
|
| template void f(t a) { }
| void g() { enum e { v }; f(v); }
|
| gives this error message:
|
| foo.cc: In function Âvoid g()Â:
| foo.cc:2: error: no matching function for call to Âf(g()::e)Â
|
| If the enum definition is moved out of the function, this works. With gcc
3.2,
| this works. I didn't try 3.4.
There is a core issue for this. We discussed it again at the last
meeting in Berlin. There are proposals to make it "just work", but
that is still in the open state.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #6 from gdr at integrable-solutions dot net 2006-05-11 16:47 --- Subject: Re: template function not recognized when invoked with enum defined in function "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | It was not hastly closed, the current standard says this is invalid. and the current standard is known to be defective in that aspect, which is why we had the core issue in the first place. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #9 from gdr at integrable-solutions dot net 2006-05-11 23:20 --- Subject: Re: template function not recognized when invoked with enum defined in function "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #7) | > This may be related to 20589, but I don't think it is the same issue. | It is the same issue because there is only one Defect report for the C++ | standard. They are not the same thing. However, somehow, both issues have been conglomerated in the same _topic_ -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug libstdc++/27579] no warning for the non-standard integral overloads of math functions
--- Comment #2 from gdr at integrable-solutions dot net 2006-05-12 21:47 --- Subject: Re: New: no warning for the non-standard integral overloads of math functions "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | As a solution to "bug" 3181, integral overloads of many math functions (like | sqrt) were introduced. Would it be possible to add a warning when such | overloads are instantiated? I don't know how to do that with g++ (if it is not | possible, then it would be a nice feature to add). It would help people write | more portable code. this is a non-issue. PR should be closed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27579
[Bug c++/25915] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #9 from gdr at integrable-solutions dot net 2006-06-21 19:43 --- Subject: Re: use ODR rules to make C++ objects not be TREE_PUBLIC "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Yes this is all undefined but I rather have it be diagnose than | having it be undefined behavior. interesting shift of perspective :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25915
[Bug libstdc++/28080] header dependencies
--- Comment #8 from gdr at integrable-solutions dot net 2006-06-23 16:35 --- Subject: Re: header dependencies "chris at bubblescope dot net" <[EMAIL PROTECTED]> writes: | I did implement a version of this myself, basically by writing a | mapper around each container that did a few static_casts and mapped | the functions to a void* version of the container. However, having a | whole new bunch of inline functions causes problems for the | compiler, without providing (as far as I could measure) | significant reductions in the size of the executable. I'm not surprised. We should be very cautious about increasing abstraction penablty for the benefit of marginal reduction on header dependencies. Runtime performance of the library should not be under-emphasized. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug c/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #3 from gdr at integrable-solutions dot net 2006-07-02 16:03 --- Subject: Re: Diagnostic about wrong use _Complex prints __complex__ "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Confirmed, we don't record in the preprocessor which keyword is | used, _Complex is treated the same as __complex__. Indeed. However, we can approximate a fix by testing whether we're compiling under C99, GNU99, or just C90, or C++. -- gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #5 from gdr at integrable-solutions dot net 2006-07-02 16:37 --- Subject: Re: Diagnostic about wrong use _Complex prints __complex__ "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #3) | > Indeed. However, we can approximate a fix by testing whether we're | > compiling under C99, GNU99, or just C90, or C++. | | That would not work as _Complex is accepted in GNU90 more and with the C++ | front-end by default. Lookup the meaning of "approximation". -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #2 from gdr at integrable-solutions dot net 2006-07-17 16:51
---
Subject: Re: New: [4.2 regression] Issue with anonymous namespace
"jakub at redhat dot com" <[EMAIL PROTECTED]> writes:
| template
| const char *baz ()
| {
| return str;
| }
|
| namespace { char foo[] = "foo"; };
|
| const char *
| bar ()
| {
| return baz ();
| }
|
| used to compile before the "make anon-namespace non-public" changes and still
| compiles when the anon namespace is changed for a named namespace and using
| namespace below it.
This is a bug in the compiler. I have always warned people that the
unnamed namespace transformation to "static" should happen in the
*back-end*, not in the front-end using language rules, because the
language rules are slightly different in those cases. But, at the
time people said I was considering theoretical problems. The ability
to have the compiler do "would be nice" transformation should not take
over our ability for the compiler to have valid codes and generate
good executable.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #6 from gdr at integrable-solutions dot net 2006-07-17 20:19 --- Subject: Re: [4.2 regression] Issue with anonymous namespace "jason at redhat dot com" <[EMAIL PROTECTED]> writes: | --- Comment #3 from jason at redhat dot com 2006-07-17 19:53 --- | Subject: Re: [4.2 regression] Issue with anonymous namespace | | gdr at integrable-solutions dot net wrote: | > I have always warned people that the | > unnamed namespace transformation to "static" should happen in the | > *back-end*, not in the front-end using language rules, because the | > language rules are slightly different in those cases. | | I don't remember ever seeing you mention that before, but it does seem | like an interesting idea. Hi Jason, This transformation has been discussed several times. The last time I made again that statement was with respect to a PR whose number I can't remember right now. However, google gave a link to this http://gcc.gnu.org/ml/gcc/2004-01/msg02351.html http://gcc.gnu.org/ml/gcc/2004-01/msg02358.html the discussion is quite involved there, but I suspect it shows how difficult it is get the caution through. | Your comments in the PRs talk about not | changing the C++ linkage (which we obviously shouldn't), but not about | where to implement it. Basically what I'm saying is this: We should have two notions of linkage (1) one at the language level, as mandated by the language definition; (2) and one at the symbol level, that the middle-end, back-end and linker understand. Then we map the linkages in categrory (1) to those of category (2). So that would enable us to use "internal linkage" (or hidden visibilitty) at level (2) without affecting linkage at level 1. At the moment it looks like the tree reprsentation somehow conflates those two levels into a single one, leading to the current misbehaviour. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug libstdc++/7439] C99 compat: Can't use the name INFINITY in an enum.
--- Comment #8 from gdr at integrable-solutions dot net 2009-01-27 03:34 --- Subject: Re: C99 compat: Can't use the name INFINITY in an enum. On Mon, Jan 26, 2009 at 6:19 PM, bkoz at gcc dot gnu dot org > Thus, I am going to close this as WONTFIX. For C++0x, the case is INVALID, and > for open gcc branches the bug status is FIXED. > > Gaby, if I'm off on this please re-open. > > -benjamin I fully agree with your resolution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7439
[Bug c++/22238] [4.0/4.1 regression] '#'obj_type_ref' not supported by dump_expr
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-16 19:05 --- Subject: Re: [4.0/4.1 regression] '#'obj_type_ref' not supported by dump_expr "mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Gaby, please apply the simple OBJ_TYPE_REF patch so that we can remove the | regression markers from this PR. OK. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
[Bug c++/24657] [3.4/4.0/4.1 Regression] bizarre diagnostic when a member variable and a template parameter have the same name
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-16 19:14 --- Subject: Re: [3.4/4.0/4.1 Regression] bizarre diagnostic on valid (?) constructor "bangerth at dealii dot org" <[EMAIL PROTECTED]> writes: | I'm pretty sure I've seen this somewhere before -- the question was indeed | which name should be looked up, the template name or the name of a member | variable. Indeed this is an issue. Discussion in on the -core reached the consensus that we could change the lookup rules for member templates so that template parameters for *member* templates would be searched, before members of the enclosing class. But I don't recall the issue has attained an advanced state yet. Note that in the older "issue", there actually are TWO separate issues. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24657
[Bug c++/24702] Koenig found functoid ref, but "cannot be used as a function"
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-16 19:28 --- Subject: Re: Koenig found functoid ref, but "cannot be used as a function" "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Actually IIRC Koenig lookup only finds functions and not variables. That is incorrect. There is an active core language issue on "argument dependent name lookup specification." -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24702
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-16 19:43 --- Subject: Re: New: COMPLEX_ASSIGN is wrong "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The defintion of COMPLEX_ASSIGN is wrong, that is wrong according to Andrew. | This is in reference to PR 23497. In the reference to that thread, please do note that = yields an lvalue for built-in "="; in partiaular __imag__ z = r yields an lvalue. do whatever you want in the *middle end*, but be sure you don't transmute that basic semantics constraint. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
--- Comment #5 from gdr at integrable-solutions dot net 2005-11-16 20:24 --- Subject: Re: COMPLEX_ASSIGN is wrong "pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes: | Subject: Re: COMPLEX_ASSIGN is wrong | | > yields an lvalue. do whatever you want in the *middle end*, but be | > sure you don't transmute that basic semantics constraint. | | Gaby, it also prevents a huge amount of optimizations so what is | the difference from saying it is wrong? You're putting optimization before semantics; -that- is wrong. I'm not interested in the fastest program if it does not meet my needs. If __imag__ z yields a modifiable lvalue, then it follows, by ordinary language rules that it can be used on the left hand side of built-in "=". In C, the resulting expresion is an rvalue; in C++ it is an lvalue. No amount of bizarre extension should break those simple rules. | The issue comes down to what does | __imag__ a = b; really means. No, it comes down to what "__imag__ a" means. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
--- Comment #6 from gdr at integrable-solutions dot net 2005-11-16 20:27 --- Subject: Re: COMPLEX_ASSIGN is wrong "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I should also note that: | http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex | | recomends against using the extensions anyways. Exactly which sentence says so? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Comment #34 from gdr at integrable-solutions dot net 2005-11-16 20:29 --- Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I should also note that: | http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex | recomends against using the extensions anyways. Exactly which sentence says that? It is an extension, useful to build libraries that cannot plug or wait to have C99 . You would have to explain with hard arguments why it should go. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-16 20:39 --- Subject: Re: COMPLEX_ASSIGN is wrong "pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes: [...] | > Subject: Re: COMPLEX_ASSIGN is wrong | > | > "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | > | > | I should also note that: | > | http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex | > | | > | recomends against using the extensions anyways. | > | > Exactly which sentence says so? | | "you should use the ISO C99 function" every time it mentions the | extenstions. (1) that is not the same as recommending against the extension; (2) how do you use ISO C99 functions to implement C99 , C++98 that interoperate with C99 _Complex and other libraries that predate C99 functions or on plateforms where C99 functions don't exist but the libraries need to be implemented anyway? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #9 from gdr at integrable-solutions dot net 2005-11-17 20:46 --- Subject: Re: versioning weak symbols in libstdc++ "jason at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | This code, like the testcase for c++/16021, works fine if the implementation | namespace is nested within std. I'm thinking of enforcing that | requirement in parse_using_directive; that would allow us to avoid | adding more special lookup rules. Do you see any problem with that | requirement? I'm for minimal invasion in the name lookup rules; so if that takes care of issues raised by Benjamin, I'm all for it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug c++/24928] static const objects should go to .rodata
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-18 01:31 --- Subject: Re: New: Trivial static const objects should go to .rodata "msharov at hotmail dot com" <[EMAIL PROTECTED]> writes: | With the object being initialized at runtime as if it mattered. Because the | values of the member variables can not be changed after initialization, there | is no reason to do this at runtime. Because the constructor doesn't do | anything, this would not conflict with C++'s create-on-call mandate. Completely agreed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24928
[Bug c++/24983] Needs a warning?
--- Comment #1 from gdr at integrable-solutions dot net 2005-11-22 02:46
---
Subject: Re: New: Needs a warning?
"igodard at pacbell dot net" <[EMAIL PROTECTED]> writes:
| struct foo { const void f(); };
| void foo::f(){}
|
| gets you:
|
| ~/ootbc/members/src$ g++ foo.cc -Wall
| foo.cc:2: error: prototype for `void foo::f()' does not match any in class
| `foo'
| foo.cc:1: error: candidate is: const void foo::f()
| foo.cc:2: error: `void foo::f()' and `const void foo::f()' cannot be
overloaded
Awful. Please assign it to me.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24983
[Bug c++/24983] Needs a warning?
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-22 03:58 --- Subject: Re: Needs a warning? "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | earth:~>~/ia32_linux_gcc3_0/bin/gcc t.cc | t.cc:2: prototype for `void foo::f()' does not match any in class `foo' | t.cc:1: candidate is: const void foo::f() | earth:~>~/ia32_linux_gcc2_95//bin/gcc t.cc | t.cc:2: new declaration `void foo::f()' | t.cc:1: ambiguates old declaration `const void foo::f()' | | | I say that 3.0.x is the best if it is what we should say then we have a | regression. We should say: 'const void' is not a valid type and be done with it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24983
[Bug c++/25006] failure "using" a name contained in a class
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-23 19:36 --- Subject: Re: failure "using" a name contained in a class "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | ICC rejects it as invalid too: | t.cc(7): error: a class-qualified name is not allowed | using ::Foo::Bar::FooBar; // line 7 | | So does Comeau with the same error message. The construct is ill-formed -- sorry, someone needs to quote chapter and verse. I'll do that later if no one beats me at it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25006
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-24 03:38 --- Subject: Re: Bootstrap: Failure to build doc/gcc.info "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Actually this is invalid, you need to build with a clean object directory. That is bullshit. what about bubblestrap and the like? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-24 09:01 --- Subject: Re: Bootstrap: Failure to build doc/gcc.info "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #4) | > still does not work with bubblestrap and friends | | After a clean build? YES. | See http://gcc.gnu.org/ml/gcc/2005-11/msg01173.html That does not solve the problem. I did not experience that before. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-24 09:03 --- Subject: Re: Bootstrap: Failure to build doc/gcc.info "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #3) | > Subject: Re: Bootstrap: Failure to build doc/gcc.info | > "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | > | Actually this is invalid, you need to build with a clean object directory. | > That is bullshit. what about bubblestrap and the like? | | well are you bubblestrapping in the gcc directory of the objdir or the toplevel | directory, if the latter, maybe just maybe this is a bug. the gcc directory of the builddir. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-28 16:15 --- Subject: Re: Warning "missing braces around initializer" causing problems with tr1::array "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I don't see why the warning is not useful at all, in fact I rather | have the C++ standard fix their wording of TR1's array. it is not the C++ standard; but definitely a bug in the specification. he problem shoul dbe reported there. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-28 16:18
---
Subject: Re: New: Warning "missing braces around initializer" causing
problems with tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| The following code:
|
| struct S
| { int x[3]; };
|
| void f()
| { S s = {1,2,3};}
|
| With -Wmissing-braces (which is implied by -Wall, among others) gives:
|
| warning: missing braces around initializer for 'int [3]'
|
| In the specific case where a struct contains only a single array, adding the
| extra braces doesn't really seem that useful.
|
| The reason it would be nice to fix this that in the definition of tr1::array
in
| the TR1 specification (page 88, 6.2.2) says
|
| 2.An array is an aggregate ([dcl.init.aggr]) that can be initialized with the
| syntax
| array a = { initializer-list };
I believe there is a slight confusion between a "C-array" and a TR1
class-type called "array". You have found a bug in the TR1; would you
mind making a report?
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-28 18:46
---
Subject: Re: Warning "missing braces around initializer" causing problems with
tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| Actually, is a report really approriate? Writing array = {1,2,3} is
| perfectly valid C++, just warned about with -Wmissing-braces
You're absolutely right! I forgot 8.5.1/11!
Can't we have simple, general rules, without list of special cases? :-(
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-29 17:48 --- Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of bool) "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Hmm, it is looking at the wrong type, it is looking at the RESULT_DECL's type | instead of the FUNCTION_TYPE's type which has the correct type, I might fix | this later tonight. That is a combination of two things: (1) vestige of the old infamous named-returned value extension logic; (2) the default widening-strategy used in the compiler. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-29 18:02 --- Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of bool) "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Hmm, it is looking at the wrong type, it is looking at the RESULT_DECL's type | instead of the FUNCTION_TYPE's type which has the correct type, I might fix | this later tonight. Try this *** ChangeLog (revision 107674) --- ChangeLog (local) *** *** 1,3 --- 1,10 + 2005-11-29 Gabriel Dos Reis <[EMAIL PROTECTED]> + + PR c++/25156 + * typeck.c (check_return_expr): Get the return-type from the + function declaration, now that the named-return value extension is + no longer existent. + 2005-11-30 Ben Elliston <[EMAIL PROTECTED]> * typeck.c (build_x_unary_op): Correct spelling in error message. *** typeck.c(revision 107674) --- typeck.c(local) *** check_return_expr (tree retval, bool *no *** 6257,6270 return retval; } ! /* When no explicit return-value is given in a function with a named ! return value, the named return value is used. */ ! result = DECL_RESULT (current_function_decl); ! valtype = TREE_TYPE (result); gcc_assert (valtype != NULL_TREE); fn_returns_value_p = !VOID_TYPE_P (valtype); - if (!retval && DECL_NAME (result) && fn_returns_value_p) - retval = result; /* Check for a return statement with no return value in a function that's supposed to return a value. */ --- 6257,6269 return retval; } ! /* We no longer support the old "named-return value" extension, so get ! the return-type from the function declaration. */ ! valtype = TREE_TYPE (TREE_TYPE (current_function_decl)); gcc_assert (valtype != NULL_TREE); + result = DECL_RESULT (current_function_decl); + gcc_assert (TREE_TYPE (result) != 0); fn_returns_value_p = !VOID_TYPE_P (valtype); /* Check for a return statement with no return value in a function that's supposed to return a value. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c++/25163] [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time"
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-29 23:20 --- Subject: Re: New: [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time" "reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The test g++.dg/abi/vtt1.C is failing with "-funit-at-a-time" | (or optimization "-O" or higher since this enables "-funit-at-a-time" | by default). | | GCC 4.x.y doesn't seem to be affected. | Since this behaviour can be triggered with just "-O2" I rate this as | a regression (although "-funit-at-a-time" was introduced in 3.4.0). | | Gaby, do you think that this is a showstopper for 3.4.5 or not? I think we shoulkd deal with that after 3.4.5; but I don't consider it a showstopper. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25163
[Bug c++/22573] typedef in class scope not reported by error message
--- Comment #5 from gdr at integrable-solutions dot net 2005-11-30 20:19
---
Subject: Re: typedef in class scope not reported by error message
"brad dot king at kitware dot com" <[EMAIL PROTECTED]> writes:
| Okay, if you don't consider it a bug that is fine with me. I just reported
it
| to make sure you were aware of the inconsistency. I'm changing this bug's
| status to Verified.
I don't want to leave you under the impression that your report was
dismissed as unimportant. Quite the contrary. There is a furious
debate in the user community about what the right thing should be. It
is not clear and there does not seem be a right way of doing it.
We're well aware of this issue; we're trying to do our best. I
understand not everybody is happy, but is not an issue we can make
everybody happy.
| Meanwhile I'm still a bit curious as to where in the source the
| argument's true type as written by the user is lost
| ("dereferenced"). Why is it lost only for class-scope typedefs and
| not for namespace-scope ones?
all those are good questions I don't have the answer for yet. But, if
you dig the archive (gcc-patches) you'll have a hint from a recent
patch of Mark Mitchell and another hint about the on-going debate.
| I'm somewhat familiar
| with the internals of GCC and can read the output of -fdump-translation-unit
| but I could not find the spot that loses this information. Any pointers are
| appreciated. Thanks.
-fdump-translation-unit is broken at the present; and if it did work,
it won't help you much. Search for a recent patch of Mark Mitchell
about canonicalizing types.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573
[Bug middle-end/25181] [3.4 Regression] wrong "will never be executed" warning in switch - case block
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-30 22:23 --- Subject: Re: [3.4 Regression] wrong "will never be executed" warning in switch - case block "oliverst at online dot de" <[EMAIL PROTECTED]> writes: | I forgot to meintion, that this happens with C and C++, so I guess it's a | middle-end bug!? Most probably. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25181
[Bug c++/9925] ostrstream (buf, size) << "..." does not work properly
--- Comment #15 from gdr at integrable-solutions dot net 2005-12-01 00:10 --- Subject: Re: ostrstream (buf, size) << "..." does not work properly "igodard at pacbell dot net" <[EMAIL PROTECTED]> writes: | Two bugs: with no more details, that does not help me :-) --Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #7 from gdr at integrable-solutions dot net 2005-12-02 19:23
---
Subject: Re: exception_defines.h #defines try/catch
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Confirmed. This also causes problems in normal C++ code which does:
|
| #include
|
| 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-02 19:18 --- Subject: Re: exception_defines.h #defines try/catch I agree with Benjamin. "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-02 19:29 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-03 00:58 --- Subject: Re: exception_defines.h #defines try/catch "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #13 from gdr at integrable-solutions dot net 2005-12-03 01:02 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | (In reply to comment #8) | > Subject: Re: exception_defines.h #defines try/catch | > | > "hhinnant at apple dot com" <[EMAIL PROTECTED]> 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #15 from gdr at integrable-solutions dot net 2005-12-03 04:20 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #17 from gdr at integrable-solutions dot net 2005-12-04 02:54 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-04 17:07 --- Subject: Re: builtin *printf handlers are confused by -fexec-charset "ghazi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Backporting this fix to 3.4 requires also backporting the infrastructure patch | for the lang hook to_target_charset posted here: | http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00780.html Hmm, I'm tempted to leave it is as wontix on 3.4.x. Thoughts? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug c/25301] [3.4 regression] ICE for sizofe of incomplete type
--- Comment #2 from gdr at integrable-solutions dot net 2005-12-07 20:40
---
Subject: Re: New: [3.4 regression] ICE for sizofe of incomplete type
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch.
| A reduced testcase is:
|
| ===
| typedef struct A B;
| int i = sizeof(B);
| ===
|
| bug.c:2: error: invalid application of `sizeof' to incomplete type `
| Internal compiler error: Error reporting routines re-entered.
| Please submit a full bug report, [etc.]
|
| The culprit is the code in c-objc-common.c (c_tree_printer) :
|
| case 'T':
| if (TREE_CODE (t) == TYPE_DECL)
| {
| if (DECL_NAME (t))
| n = (*lang_hooks.decl_printable_name) (t, 2);
| }
| else
| {
| t = TYPE_NAME (t);
| if (t)
| n = IDENTIFIER_POINTER (t);
| }
| break;
|
| In the above case t is a RECORD_TYPE, but TYPE_NAME (t) is a TYPE_DECL.
| So there's some logic missing to handle this case.
In general, there is a "type" problem in both C and C++ front ends.
The documentation for TYPE_NAME says that it returns a TYPE_DECL -- as
opposed to an IDENTIFIER_NODE. However, at various occasions I found
that a TYPE_NAME would return an IDENTIFIER_NODE. That is a clear bug
in both front ends ans should be hunt. Obviously, you have identified a
place where instead of correcting the problem the pretty-printer had
assumed that TYPE_NAME will always return an IDENTIFIER_NODE --
despite the documentation. I believe a proper PR should be filled so
that both front ends are cured from that confusion.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25301
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #5 from gdr at integrable-solutions dot net 2005-12-07 23:42 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Related to PR 16505. This is the same issue as PR 16505. | | Can someone close to the standard answer the question why did they change the | return type for these functions? I think it really does not matter now -- many things changed when they got their way into the standard, for more or less obvious reasons. We've gotten a bug in libstdc++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #9 from gdr at integrable-solutions dot net 2005-12-08 03:32 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "sebor at roguewave dot com" <[EMAIL PROTECTED]> writes: | FWIW, I think Andrew makes a good point in comment #1. The algorithms really | should return the iterator, otherwise the caller may not be able to find out | the state of the iterator after the algorithm returns (e.g., when the iterator | is ostreambuf_iterator). It may not be a bad idea to open an issue (or at least | bring it up on the reflector). So do you suggest to get this PR in suspended state and get feedback from LWG? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25306] fill_n, generate_n assume Size is modifiable
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-08 03:36 --- Subject: Re: New: fill_n, generate_n assume Size is modifiable "sebor at roguewave dot com" <[EMAIL PROTECTED]> writes: | I came across this while gathering background for my post in | c++std-lib-16112. I thgought I might as well let you know in case | you think it's important enough to worry about (Size is only | required to be convertible to an integral type which doesn't mean it | needs to have the predecrement operator defined). The incorrect | return type in this test case works around bug #25304. I've come to take issue with the specification of Size. It says it is convertible to an integral type, does it does not say which. I believe the wording should be more precise -- yes, a library could conservatively take long (long) or unsigned long (long), but still that is a waste. Would you mind appending that issue to the one you raised in c++std-lib-16112? -- gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #11 from gdr at integrable-solutions dot net 2005-12-08 16:04 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "sebor at roguewave dot com" <[EMAIL PROTECTED]> writes: | No, I don't. The standard is clear and most of us seem to think it's "by | design." Rather I am suggesting is that we might want to discuss with the whole | LWG changing the return type as an enhancement. I think I understand that. However, I'm looking at the pratical effect. If libstdc++ changes the return types (correcting the bug) then it will be an ABI breakage. If LWG considers and agrees on the enhancement, libstdc++ will have to change again the return types. At the end of the day we would have two ABI breakages with zero net benefit for existing libstdc++ users. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #14 from gdr at integrable-solutions dot net 2005-12-08 16:23 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | 2- As I see the issue, it depends a lot on the actual timeframe of | the possible enhancement to the standard. I mean, if we are thinking | about C++0x, seems rather far in time. I think most of our users | would not perceive our practice as randomly going back and forward | on something. Fair enough. (At Lillehammer, we set to have x, in C++0x, a digit; so that means we're almost done by 2007. That is not far, given that LWG would not need to wait 2007 before agreeing on the issue. I was amazed to discover that CWG two two meetings to open an issue and move it to WP. LWG could do the same. Hint, hint, :-)) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #16 from gdr at integrable-solutions dot net 2005-12-08 17:12 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | + the more general consideration that, delivering a C++0x conforming | library certainly will involve breaking the ABI in tens of different | ways I have no trouble with that. My main concern is whether the flip flop worths it *if* we're going to change back. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug c++/25316] POD structures can have
--- Comment #2 from gdr at integrable-solutions dot net 2005-12-08 22:25
---
Subject: Re: New: POD structures can have
"mrs at apple dot com" <[EMAIL PROTECTED]> writes:
| A user reported that this:
|
| mrs $ cat > t98.c
| struct X {
| int a, b;
| X() : a(0), b(0) {}
| };
|
| static void f(const char *s, ...);
|
| int main()
| {
| X x;
| f("foo!", x);
| return 0;
| }
|
| works on other C++ compilers (Metroworks), but on gcc:
|
| mrs $ ./g++ -B./ -c t98.c
| t98.c: In function 'int main()':
| t98.c:11: warning: cannot pass objects of non-POD type 'struct X' through
| '...'; call will abort at runtime
|
| This, according the a reading of the standard is a POD type, no, really. :-)
Are you saying "struct X" is a POD?
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25316
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-12 17:37 --- Subject: Re: (optimisation) Functions in anonymous namespaces should default to "hidden" visibility "bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | There is a feature request to assign visibility attributes to | namespaces. If this is done, then making anonymous namespaces hidden | will just be a sub-class of that work. | | That enhancement request is | | c++/21764 | | Some of the semantics need to be fleshed out concretely, and | behavior decided. I agree. Independently of the visvibility issue, GCC can make some other entities have internal linkage from the assembler/linker point of view (not C++ source point of view). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c++/21494] condensed nested namespaces
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-15 03:40
---
Subject: Re: condensed nested namespaces
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #5 from bkoz at gcc dot gnu dot org 2005-12-14 17:16 ---
|
| I'm encouraged by this work!!! Great news.
|
| The reason this would be useful is that then it would be possible to use a
| single macro to represent both scope and namespace. Ie,
|
| #define ACTIVE_SCOPE
|
| works for
|
| namespace ACTIVE_SCOPE
| {
| }
|
| and explicit qualifications like
|
| ACTIVE_SCOPE::obj;
|
| Anyway.
I see what you mean. However, as ever, macro-based tehcniques just
don't play nicely with othe scope rules.
When I read the code, I don't want to be deceived. When I see
namespace ACTIVE_SCOPE { /* blah blah */ }
I really think of a named scope. Later, when I see
ACTIVE_SCOPE::obj, I really think of the obj found in ACTIVE_SCOPE
through usual rules. However, if ACTIVE_SCOPE is #defined to nothing,
then that breaks down -- the obj found is not the one from the unnamed
namespace through usual rules.
So. while I believe this work can be useful, I'm not convinced that
the macro-based techniques make a case for the extension that would
require a different set of lookup rules.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21494
[Bug bootstrap/25455] [4.2 Regression] "make all" with a native build now does a bootstrap instead of a normal build
--- Comment #9 from gdr at integrable-solutions dot net 2005-12-16 22:01 --- Subject: Re: [4.2 Regression] "make all" with a native build now does a bootstrap instead of a normal build Andrew Pinski <[EMAIL PROTECTED]> writes: [...] | But he did not which is why there is a bug report. At this moment, I guess the most important thing is that how to "make" is clarified and Paolo is willing to fix any problem that might result from his change. I'm doing what Daniel J. requested and I'll post the log once the build is finished. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25455
[Bug c++/25497] faults typedef redefinition in struct
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-19 22:45
---
Subject: Re: New: faults typedef redefinition in struct
"baraclese at hotmail dot com" <[EMAIL PROTECTED]> writes:
| +++ This bug was initially created as a clone of Bug #7869 +++
|
| I stumbled over the second issue that the original bug report mentioned. I
| think it was closed prematurely.
| To clarify this a bit I provide my own short example.
| It may be worth noting that comeau online does not produce any errors on this
| code, nor does microsofts c++ compiler that comes with visual studio 8.
That does not make them "right", nor does it turn your invalid code
into valid code.
| struct tag{};
|
| struct A {
| tag t; // *
| typedef int tag;
| };
|
| *omit this declaration and everything is fine for g++
|
| error msg on g++3.4.4:
|
| error: declaration of `typedef int A::tag'
| error: changes meaning of `tag' from `struct tag'
|
| Why would the outer tag declaration conflict with the tag declaration in
scope
| A? This is not an error that I would have expected intuitively which is why
I'd
| like to bring this up again.
The C++ standard says that your program is ill-formed.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25497
[Bug c++/25260] [4.0/4.1/4.2 Regression] Forward explicit intantiation declaration doesn't mix well with static integral member
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-20 17:23
---
Subject: Re: [4.0/4.1/4.2 Regression] Forward explicit intantiation
declaration doesn't mix well with static integral member
"fang at csl dot cornell dot edu" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.2 Regression] Forward explicit
| intantiation declaration doesn't mix well with static integral member
|
| > --- Comment #3 from nicos at maunakeatech dot com 2005-12-20 09:20
---
| > I was under the belief that out of class definitions of const static
integral
| > members was optional for gcc and that static const N = k; was equivalent to
| > enum { N = k};, was I wrong ?
|
| in-class definitions of static const integral types are *permitted* in
| lieu of out-of-class definitions -- but you need one or the other. Also
| enums are never allocated memory in object files (data section), as per
| W.B.'s remark.
For me, this discussion is yet another evidence for the remark
"that is a misfeature" (about the whole in-class initialization for
const integral business) that could be found in earlier printings of TC++PL3.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25260
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #14 from gdr at integrable-solutions dot net 2005-12-21 17:05 --- Subject: Re: can't voidify __attribute__((warn_unused_result)) "mueller at kde dot org" <[EMAIL PROTECTED]> writes: | ok, then, lets see if we can get this fixed in glibc. good luck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding
--- Comment #5 from gdr at integrable-solutions dot net 2005-12-21 17:28 --- Subject: Re: [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding "gdr at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | --- Comment #4 from gdr at gcc dot gnu dot org 2005-12-21 17:21 --- | (In reply to comment #3) | > Invalid as of 6.5.6/8 | > | I don't think that paragraph explains why this is an | invalid PR. More to the point: We need to be more precise about our mapping for pointer type -> integer type integer type -> pointer type T* -> U* This issue should not be resolved in isolation, piece meal looking only at benchmark numbers. It is fine to precisely define the mappings to make the code undefined, or have defined semantics. Notice also that this relates to the practice (T*)(-1) which is wiedely used in C programs (including GCC!). Finally, we don't have a policy that the opener of a PR has "more rights to close it", nor should we. We should be closing PRs on technical grounds. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25512
[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-21 18:40 --- Subject: Re: [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | One more thing, the comparision will fail with segmented memory targets like | x86 (when using the segment register). I don't know whether GCC supports such target (if yes, you've potentially found a bug in GCC's implementation of total pointer ordering as required by the C++ standard) That is more reason for GCC to document what the mapping for the conversion T* -> integer type. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25512
[Bug middle-end/25521] change semantics of const volatile variables
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-21 19:17 --- Subject: Re: New: change semantics of const volatile variables "drepper at redhat dot com" <[EMAIL PROTECTED]> writes: | In math code we often have to make sure the compiler does not fold operations | at compile time. In glibc we use variable declared as | | static const volatile double foo = 42.0; | | The problem is that gcc moves such variables into .data. But we could achieve | that easily by leaving out the 'const'. What is needed is a method to achieve | volatile behavior while having the variable in .rodata (and .rodata.cst8 etc). | | I therefore would like to ask for a change in the compiler which preserves the | 'const' in the presence of 'volatile' and place the variable in read-only | memory. that is tricky because of the general interpretation: [#10] EXAMPLE 1 An object declared extern const volatile int real_time_clock; may be modifiable by hardware, but cannot be assigned to, incremented, or decremented. If it may be modified by hardware or other external means, it can't go into .rodata section. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
[Bug middle-end/25521] change semantics of const volatile variables
--- Comment #3 from gdr at integrable-solutions dot net 2005-12-21 19:54
---
Subject: Re: change semantics of const volatile variables
"drepper at redhat dot com" <[EMAIL PROTECTED]> writes:
| __attribute((section(".rodata.cst8"))). This will cause gcc to fail with an
| ICE.
That is compiler bug. That is useful piece of data. I believe the PR
should be retitled and reclassified based on that.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
[Bug libstdc++/25524] libstdc++ headers should go in multilib directories
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-21 23:23 --- Subject: Re: New: libstdc++ headers should go in multilib directories "jsm28 at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Some libstdc++ headers are installed in GPLUSPLUS_TOOL_INCLUDE_DIR, i.e. | include/c++/version/target. These headers are derived from information | configured separately for each multilib, and in general may differ between | multilibs, so should go in a multilib directory (e.g. | include/c++/version/target/multilib). The precompiled headers installed there, | in particular, should be separately installed for each multilib in all cases, | even if in some cases the actual text headers happen to be the same for each | multilib. Most headers are target independents, so should not suffer from multilib issue. I would think that a proper plan to fix this is to install target dependent thingies in some deeper subdirectories. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
[Bug c++/25608] g++ miscompiles gcjx
--- Comment #2 from gdr at integrable-solutions dot net 2005-12-31 00:12 --- Subject: Re: g++ miscompiles gcjx "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | This needs more information than compiling and runing some piece of code. The PR provides way to reproduce the bug. And it is not random piece of code. You can help reduce the testcase or find better way to be useful, at least be less helpful. | I almost want to say gcjx uses some undefined code in it. Maybe. I looked at the code, could not find any. I highky suspect miscompilation, given recent breakage. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
[Bug libstdc++/25608] g++ miscompiles gcjx
--- Comment #9 from gdr at integrable-solutions dot net 2005-12-31 04:44 --- Subject: Re: g++ miscompiles gcjx "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #7) | > Before reclassifying, it would useful to provide data. If you cannot, | > please move on something else. You're not being helpful here. | | Since this is reproducible from 4.0 upwards and it is way down in the libstdc++ | and it is a dead lock, | it is more likely to be a bug in libstdc++ than anywhere else. OK, let see. | Are you sure that you cannot reproduce this with 3.4.x where x>=2? I used the latest GCC-3.4.5 to compile gcjx, classpath, jacks and produce some profile data. I did not run into the dead lock. Several time. However, with mainline, I get a stall exactly at the same place. | This seems very related to PR 12658. | | It seems like this could be a glibc bug reading that other bug, specifically | "testsuite/22_locale/locale/cons/12658_thread.cc" test. | | What glibc version do you have? glibc-2.3.4-23.4 (SuSE 9.3) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
[Bug libstdc++/25608] g++ miscompiles gcjx
--- Comment #10 from gdr at integrable-solutions dot net 2005-12-31 05:07 --- Subject: Re: g++ miscompiles gcjx "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | This seems very related to PR 12658. it was fixed in all branches. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
[Bug libstdc++/25608] g++ miscompiles gcjx
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-31 05:56 --- Subject: Re: g++ miscompiles gcjx "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Hmm, can you try the following C++ program and see if it works for you: It works for me at -O0, -O1, -O2, -O3 and combinations with -g. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
[Bug libstdc++/28414] return type of valarray's sqrt function isn't valarray
--- Comment #1 from gdr at integrable-solutions dot net 2006-07-17 23:57 --- Subject: Re: New: return type of valarray's sqrt function isn't valarray "djg at cray dot com" <[EMAIL PROTECTED]> writes: | The return type of valarray's sqrt function isn't valarray, as specified in | 26.3.3.3 [lib.valarray.transcend], and what it does return doesn't convert to | valarray in some cases. This causes the slice1.cpp example from the Josuttis | book examples to get a compile error: | | http://www.josuttis.com/libbook/num/slice1.cpp.html This is not a bug. The implementation is conformant to the C++ standard, which says, 16.3.1/3 Any function returning a valarray is permitted to return an object of another type, provided all the const member functions of valarray are also applicable to this type. This return type shall not add more than two levels of template nesting over the most deeply nested argument type. Please read further the book by Josuttis for a note about this. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28414
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #5 from gdr at integrable-solutions dot net 2006-07-23 18:03 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | drow at gcc dot gnu dot org wrote: | > --- Comment #3 from drow at gcc dot gnu dot org 2006-07-23 16:44 --- | > Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE | > | > On Sun, Jul 23, 2006 at 03:59:58PM -, mark at codesourcery dot com wrote: | >> If we're setting TYPE_CONTEXT to global_namespace, I think that's a C++ | >> front end bug. Which type is getting set up like that? | > | > I was wrong; TYPE_CONTEXT looks OK. How about for DECLs? | | The same rule applies; DECL_CONTEXT should also be NULL_TREE for an | entity in the global namespace. I believe the situation has been that clear for DECLs for a long time now. -- Gaby akcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #9 from gdr at integrable-solutions dot net 2006-07-23 23:45 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE "drow at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE | | On Sun, Jul 23, 2006 at 06:03:46PM -, gdr at integrable-solutions dot net | wrote: | > I believe the situation has been that clear for DECLs for a long time | > now. | | Hi Gaby, | | Is there supposed to be a "not" in that sentence somewhere? Yes, "obviously". I meant "has NOT been". Sorry for the confusion. I should not hold a baby and answer bugzilla PRs stuff at the same time. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #10 from gdr at integrable-solutions dot net 2006-07-23 23:47
---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
[...]
| (IMO, the ideal representation would have global_namespace for
| DECL_CONTEXT -- but that's not a change we can make without affecting
| the middle end, as you've noticed, so I think having
| {SET_,}CP_DECL_CONTEXT to insulate us would be a nice improvement.
I agree that is the correct representation. Can we agree to have it
for GCC-4.3 or higher?
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #13 from gdr at integrable-solutions dot net 2006-07-24 01:34 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE "drow at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE | | On Sun, Jul 23, 2006 at 11:47:32PM -, gdr at integrable-solutions dot net | wrote: | > I agree that is the correct representation. Can we agree to have it | > for GCC-4.3 or higher? | | Judging from this one PR, and the tangled bits of the middle end that I | could not untangle to sort out how to skip the global namespace, I | think this will be a lot of work. Thanks for the feedback; that is much appreciated. So, I suspect we would have to live with this for quite some time. Not a big deal though, compared to other issues. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #6 from gdr at integrable-solutions dot net 2006-08-03 21:13 --- Subject: Re: vector is extremely slow (900x slower than it should be) "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | By the way, I think Andrew has a point, maybe not clearly stated, in that all | the people actively working in the C++ Standard Commitee strongly dislike | vector for many reasons, and probably it will be deprecated in C++03 and | a replacement added. That implies, in turn, that it's not so easy to find | people willing to spend much time on (the various) implementations... some committee members dislike vector for various reasons; but I don't see a chance it is going to change. But that is no reason for us to keep the implementation slower :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #8 from gdr at integrable-solutions dot net 2006-08-03 23:01 --- Subject: Re: vector is extremely slow (900x slower than it should be) "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | (In reply to comment #6) | > some committee members dislike vector for various reasons; but | > I don't see a chance it is going to change. | | Really? well, that is my opinion. To me, the deprecation is pointless and ineffective. It would need a huge lobbying. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28406] What should be value of sqrt(complex(-1.0,-0.0))?
--- Comment #3 from gdr at integrable-solutions dot net 2006-08-04 00:09 --- Subject: Re: What should be value of sqrt(complex(-1.0,-0.0))? "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | The difference between 3.4.x and 4.x is due to the builtins, therefore the | underlying libc, being called by the latter. As such, this is not a | libstdc++-v3 proper issue anymore, because in any case, we definitely want to | use the builtins, when available... Gaby, can you have a look? yes; thanks! -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #14 from gdr at integrable-solutions dot net 2006-08-05 23:26 --- Subject: Re: vector is extremely slow (900x slower than it should be) "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | Fixed. Thanks Paolo! -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #5 from gdr at integrable-solutions dot net 2006-08-11 01:20 --- Subject: Re: New: [4.2.0 regression] dynamic_cast disallowed too rigorously with -fno-rtti "benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes: | Code compiled with -fno-rtti containing a dynamic_cast used to compile | and work properly on types with a vtable (the base class can be determined | entirely using the vtable without any RTTI information). RTTI is needed to have dynamic_cast works properly. Period. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #7 from gdr at integrable-solutions dot net 2006-08-11 04:48 --- Subject: Re: [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti "benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes: | Gabriel, can you explain how it worked correctly in all the previous | releases? I don't understand exactly what you mean by "it worked correctly". The documentation says: Disable generation of information about every class with virtual functions for use by the C++ runtime type identification features (`dynamic_cast' and `typeid'). If you don't use those parts of the language, you can save some space by using this flag. Note that exception handling uses the same information, but it will generate it as needed. In particular, you cannot use dynamic_cast and -fno-rtti at the same time. So far, it appears to me that your programs were contrary to the documented recommendation. This PR should be closed as invalid. | Is my summary of how it is done using only the vtable inaccurate? As far as I understand the issue, yes. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #9 from gdr at integrable-solutions dot net 2006-08-11 11:01 --- Subject: Re: [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti "benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes: | The documentation is incorrect. The documentation is what we expect users to follow and what we promise them. As far as I can tell, there is no mismatch between the documentation and the check we do. So, your assertion is incorrect. | RTTI is not required to find the most-derived | class pointer, because the vtable contains this information natively and does | not need to know anything about the type. and where do you put and find the vtables? | I'm making my point from years of working software, not some | theoretical discussion. probabluy; but you're wrong. Many, you should have a look at the theory. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #12 from gdr at integrable-solutions dot net 2006-08-11 12:33 --- Subject: Re: [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti "benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes: | I'm not claiming that the behavior isn't conformant to the docs, I'm claiming | that you regressed a construct that No, we did not regress because the documentation was very explicit. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/20599] variadic template support
--- Comment #9 from gdr at integrable-solutions dot net 2006-09-25 03:38 --- Subject: Re: variadic template support "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | For the record, personally and for what is worth my personal opinion | in the compiler area, I have nothing against adding to the compiler | -std=c++0x We should have -std=c++2003 and -std=c++0x. However, care must be exercise about what is included in both options. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-25 22:06 ---
Subject: Re: Do not print default template arguments in error messages
"giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes:
| --- Additional Comments From giovannibajo at libero dot it 2005-03-23
02:44 ---
| I'll try to do this. This is a simple testcase:
|
| ---
| template
| struct A
| {
|typedef typename T::x x;
| };
| void foo(void)
| {
| A a;
| }
| ---
| test.cc: At global scope:
| test.cc: In instantiation of 'A':
| test.cc:8: instantiated from here
| test.cc:4: error: 'void' is not a class, struct, or union type
|
| Do we want the error message to show 'A' or 'A'? In other
words,
Most of the time, we want to print what user wrote. In some cases, we
want to have the pretty-printer show all arguments. I certainly don't
want unconditional omission of default argument. You will probably
have to work on the '#' modifier -- ideally, a patch tp that effect
should confive cxx-pretty-printer.c and nor error.c.
| should GCC try and remember which arguments were really specified in the
| template-id (hard to do), or a simple check of equalness between the argument
| and the default parameter would suffice?
Not necessarily, we don't have unified types system in the C++
front-end. But, you can use same_type_p().
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-25 22:09 --- Subject: Re: Do not print default template arguments in error messages "giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes: | The first non-trivial issue is that, in order to print "std::vector" | instead of "std::vector >", we need to do the template | substitution at error printing time, and check if the resulting substitution | match. I don't think so. Look at the way error.c print templates. Either that, or I need to mark template arguments with a flag if they | come from the template-id. | | Also, should we skip default arguments also in lines like this: | | test.cc: In member function `void A::foo() [with T = int, int N = 0, | int X = 1]': | | We would be left with something like : Look at the most general template and same_type_p() with any default type. Again that is better done with cxx-pretty-print.c -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-25 22:09 --- Subject: Re: Do not print default template arguments in error messages "giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes: | --- Additional Comments From giovannibajo at libero dot it 2005-03-23 11:01 --- | or maybe: | | test.cc: In member function `void A::foo() [with T = int, int N = | , int X = ]': oh no. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-25 22:11 --- Subject: Re: Do not print default template arguments in error messages "giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes: | I cannot fix all the diagnostic problems in GCC with a single patch, | we need to do this incrementally. 100% agreed. | The first patch will deal with just removal of default | arguments, and I believe that the less intrusive and clean solution is to | display in the "with" clause. please: (1) don't do an unconditional removal; (2) don't show . I would oppose any patch short of that. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug target/20286] [3.3 only] gcc panic with __thread attribute
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-25 22:13 --- Subject: Re: [3.3 only] gcc panic with __thread attribute "wilson at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Technically, this isn't a regression, as gcc-3.2 did not have TLS | support, and gcc-3.3 is only open for regression fixes, so there is | the question of whether this patch is OK to install on the branch. | A strict interpretation of the rules says this is not OK, at least | not without approval of the branch maintainer, Gaby. I'm inclined to accept a simpler patch. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20286
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 04:04 --- Subject: Re: Do not print default template arguments in error messages "giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes: | --- Additional Comments From giovannibajo at libero dot it 2005-03-26 00:30 --- | (In reply to comment #14) | | > | The first patch will deal with just removal of default | > | arguments, and I believe that the less intrusive and clean solution is to | > | display in the "with" clause. | > please: | > (1) don't do an unconditional removal; | > (2) don't show . | > I would oppose any patch short of that. | | Yes, the remove will be conditioned on a flag (but I believe this has to become | the default). which flag? A compiler option? I don't think a multiplication of compiler options for this stuff is a good way to go. | About the , I don't understand what you are proposing as an | alternative. Are you proposing to completely remove those template parameters | from the "with" clause? when they are default, yes. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 04:06 --- Subject: Re: Do not print default template arguments in error messages "giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes: | --- Additional Comments From giovannibajo at libero dot it 2005-03-26 00:35 --- | (In reply to comment #12) | | > Look at the most general template and same_type_p() with any default | > type. | | How can it work? The default parameter can be dependent on previous template | parameters. For instace, in vector, the default type in the most general | template would be something like std::allocator (with T being a previous | template parameter), while the type in the instantiation is something like | std::allocator. | | > Again that is better done with cxx-pretty-print.c | | I don't know what cxx-pretty-print.c is, exactly. cp/cxx-pretty-print.c | Is it currently used? Yes. Curently, the pretty-printing job is done by both error.c and cxx-pretty-print.c. But, the goal is to move the codes to the latter. | Everytime I step with GDB into an error()/warning()/info() call I only see code | from errors.c being used. My current patch is modifying errors.c because that | is what the FE currently uses, as far as I can tell. you're just mistaken. I have been modifying the codes for long time now, and I have an idea of the code path. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 04:13 --- Subject: Re: Do not print default template arguments in error messages "dave at boost-consulting dot com" <[EMAIL PROTECTED]> writes: [...] | Please, I'm begging you not to go down this road. GCC is one of the I know you have strong opinions on what compilers should print; we had part of this discussions on -core and it did not seem like that was a universal solution that handles all the cases. I'm going to scheme that handle the majority of the cases right. | only compilers that gets it right today (VC8 will follow), and all the | ones that try to follow the "show how it was written" rule often give | errors that are, for all practical purposes, unusable. If you make | GCC work like the others, it will be a leap backwards and a terrible | disservice to users. yes, you're entitled to your opinions. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/20589] error: '' is/uses anonymous type'
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 04:20 --- Subject: Re: error: '' is/uses anonymous type' "bangerth at dealii dot org" <[EMAIL PROTECTED]> writes: | Intuitively, C++ treats unnamed enums differently than named ones, because | in templates the function/class name has to be mangled, and will contain | the name of the template arguments. If the template argument doesn't have | a name, then the compiler can't do its job, so the standard chose to | disallow unnamed enums as template arguments. | I know what the standard says, but the arguments used to make that rule are bogus. Those are on my list of things to fix for C++0x. If it were only mnagling, then the compiler can concoct a unique name for manglaing purposes. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
