[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #37 from gdr at integrable-solutions dot net 2010-02-21 18:04 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistent with gcc On Sun, Feb 21, 2010 at 7:04 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Or suspend it. I think this warrants a defect report anyway since I think is_modulo was intended to describe CPU behavior as otherwise defining signed integer overflow as undefined in one piece of the standard and then requiring a sane answer for is_modulo in another part sounds like a conflict of interest. is_modulo is intended to describe the implementation's choice, not necessarily the CPU behaviour (which the implementation may choose to mask or not.) The issue here is that GCC does not always deliver the CPU behaviour, so it is more a problem with GCC than with the standard. Users who want to make incompatible assumptions about types in the same program deserve what they get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistent with gcc On Sun, Feb 21, 2010 at 12:20 PM, veksler at il dot ibm dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #38 from veksler at il dot ibm dot com 2010-02-21 18:20 --- (In reply to comment #37) is_modulo is intended to describe the implementation's choice, not necessarily the CPU behaviour (which the implementation may choose to mask or not.) The issue here is that GCC does not always deliver the CPU behaviour, so it is more a problem with GCC than with the standard. Users who want to make incompatible assumptions about types in the same program deserve what they get. This is not that simple. libstdc++.so is out of user's control, libkde.so (or whatever its name is) is out of user's control. Agreed. So if -fwrapv affects the definition of is_modulo then: so the issue then is that you get two people who make incompatible assumptions about the same type for the same program. If that is case, I'm not sure what libstdc++ would have to do. After all, the resulting program is out of the control of libstdc++. If libstdc++.so is compiled without -fwrapv, then the user can't use -fwrapv without a potential ODR violation. agreed. What if libkde.so, which is supplied by a third party, was compiled with -fwrapv, while libsdc++.so was compiled by some sysadmin, accessible through NFS. agreed. They must be compiled with exactly the same flags, both out of user's control, otherwise they'll cause an ODR violation. Having is_modulo lie looks not as bad as it initially seemed. At least I have the option to ignore is_modulo altogether without going to the land of undefined behavior. my conclusion would be that is_modulo is not the right interface to test whether a component in the program was compiled with -fwrapv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug c++/43108] mixed complexT multiplication horribly inefficient
--- Comment #25 from gdr at integrable-solutions dot net 2010-02-18 04:55 --- Subject: Re: mixed complexT multiplication horribly inefficient On Wed, Feb 17, 2010 at 4:54 PM, jan at epgmod dot phys dot tue dot nl gcc-bugzi...@gcc.gnu.org wrote: --- Comment #13 from jan at epgmod dot phys dot tue dot nl 2010-02-17 22:54 --- (In reply to comment #10) Regarding the specific semantics, Richard, there is little to say: we want the C99 semantics, by and large. Maybe there are some missing details, but we decided already that, when we switched the complex multiplication to be the slow, C99 annex, by default. Thus, in a first, and second too, approx, the C++ standard doesn't count, really, this is just, sketched: __complex__ double val; double d; val *= d; But the point in question is that gcc *does not implement Annex G-4.1 (item 2) correctly*. That clearly states that u*(x+iy) = (ux)+i(uy), whereas gcc does (u+0i)*(x+iy), leading to wrongly signed zeros. The patch fixes exactly that (for C++) by circumventing gcc's flawed implementation of mixed arithmetic involving C99's complex type. then, the proper fix is to fix should be in the compiler. Not in the library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug c++/43108] mixed complexT multiplication horribly inefficient
--- Comment #26 from gdr at integrable-solutions dot net 2010-02-18 04:56 --- Subject: Re: mixed complexT multiplication horribly inefficient On Wed, Feb 17, 2010 at 4:27 PM, paolo dot carlini at oracle dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #9 from paolo dot carlini at oracle dot com 2010-02-17 22:27 --- To be clear, once more: the proposed change has been suggested *already* and rejected, being something which the compiler should be perfectly able to figure out, when legal according to the optimization options. Thus, unless Gaby says something different, the proposed patch will *not* go in. If there is any fix, it should be in the compiler. std::complexT is just a simple notation around _Complex T, for scalar T. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug c++/43108] mixed complexT multiplication horribly inefficient
--- Comment #27 from gdr at integrable-solutions dot net 2010-02-18 04:59 --- Subject: Re: mixed complexT multiplication horribly inefficient On Wed, Feb 17, 2010 at 3:24 PM, paolo dot carlini at oracle dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from paolo dot carlini at oracle dot com 2010-02-17 21:24 --- I don't see why you want to deal with special cases in the library instead of the optimizers: indeed, your *very* analysis shows that the missed optimization is happening in tree-complex.c and improving it would benefit *many* more uses outside the library. Actually, I'm pretty sure we rejected already proposals to change complex to deal more explicitly with special cases... Anyway, Gaby, can you please comment on this issue? I agree with your comments. From my point of view, the fix should be in the compiler. PS: I was away from mail for a good part of the day. I'm catching up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug libstdc++/9679] Strange behaviour of valarray::apply method
--- Comment #13 from gdr at integrable-solutions dot net 2010-02-12 11:06 --- Subject: Re: Strange behaviour of valarray::apply method On Thu, Feb 11, 2010 at 6:22 PM, paolo dot carlini at oracle dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #11 from paolo dot carlini at oracle dot com 2010-02-12 00:22 --- Thanks. Thus, would you support closing this as WONTFIX? if that is agreable to you, that is fine by me. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
[Bug libstdc++/9679] Strange behaviour of valarray::apply method
--- Comment #10 from gdr at integrable-solutions dot net 2010-02-12 00:20 --- Subject: Re: Strange behaviour of valarray::apply method On Thu, Feb 11, 2010 at 6:08 PM, paolo dot carlini at oracle dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #9 from paolo dot carlini at oracle dot com 2010-02-12 00:08 --- Gaby, any chance you can give me some guidance about this issue? What do you think should we do now? The PR remained in limbo for way too much time, in my opinion. Thanks in advance. at the moment, I believe fixing this means throwing away the current valarray implementation. I'm fine with that if someone proposes a better implementation performance-wise. Personal opinion: I do not think that the case submitted is an examplar of the usage envisioned for valarray. If you want to take address into a valarray object, create a valarray object. Don't stick references into the middle temporaries. But, that is - again - a personal opinion. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- Comment #15 from gdr at integrable-solutions dot net 2010-02-06 22:21 --- Subject: Re: valarray uses __cos which may conflict with libm functions On Sat, Feb 6, 2010 at 2:44 PM, paolo dot carlini at oracle dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #14 from paolo dot carlini at oracle dot com 2010-02-06 20:44 --- Done. Thanks, Paolo. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[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 gcc-bugzi...@gcc.gnu.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++/31246] -Wunreachable-code warnings for compiler-generated code
--- Comment #26 from gdr at integrable-solutions dot net 2008-08-26 05:45 --- Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG On Sat, Aug 23, 2008 at 1:43 PM, paolo dot carlini at oracle dot com [EMAIL PROTECTED] wrote: --- Comment #23 from paolo dot carlini at oracle dot com 2008-08-23 18:43 --- To be clear, there are no #pragma GCC system_header at all in the entire libsupc++ directory. I hope we don't have to begin... I think I agree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #15 from gdr at integrable-solutions dot net 2007-01-12 13:06 --- Subject: Re: SIGSEGV in valarray::cshift(n) on empty array paolo at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Subject: Bug 30416 | | Author: paolo | Date: Fri Jan 12 11:09:26 2007 | New Revision: 120720 | | URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120720 | Log: | 2007-01-12 Paolo Carlini [EMAIL PROTECTED] Paolo -- Your patch had issues I just commented on. I expected you'd have waited for me to review it. :-( I was travelling back to CS all day yesterday. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #12 from gdr at integrable-solutions dot net 2007-01-10 23:27 --- Subject: Re: SIGSEGV in valarray::cshift(n) on empty array pcarlini at suse dot de [EMAIL PROTECTED] writes: | Forgot: assuming we imagine the standard clarified per your proposal | on LWG (or read as such for all practical matters), I understand | that not segfaulting when size == 0 would be a conforming | behavior. Yes, it is interesting to note that a specific request to make the standard much clearer on the semantics is curiously construed as an argument for arguing that the standard says the beahviour is undefined. No wonder. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug other/29694] missed warnings about comparisons which are always true/false.
--- Comment #4 from gdr at integrable-solutions dot net 2007-01-09 18:41 --- Subject: Re: missed warnings about comparisons which are always true/false. manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Wextra warns for this, what is the bug? I believe pluto wants -Walways-true to cover this. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29694
[Bug c++/27975] warning for comparison of different enum types impossible to control/is undocumented
--- Comment #5 from gdr at integrable-solutions dot net 2007-01-09 18:43 --- Subject: Re: warning for comparison of different enum types impossible to control/is undocumented manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | What name do you want for the warning? Wenum-mismatch ? I believe we must watch for the inflation of -Wswitches. This particular request is part of a more general problem that can is dealt with elsewhere. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27975
[Bug c++/27975] warning for comparison of different enum types impossible to control/is undocumented
--- Comment #6 from gdr at integrable-solutions dot net 2007-01-09 18:44 --- Subject: Re: warning for comparison of different enum types impossible to control/is undocumented manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | I could also add it to the new -Wconversion option. I believe this is the way to go. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27975
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #2 from gdr at integrable-solutions dot net 2007-01-09 22:05 --- Subject: Re: New: SIGSEGV in valarray::cshift(n) on empty array sebor at roguewave dot com [EMAIL PROTECTED] writes: | AFAIK, the program below should have well-defined behavior but it abends with | gcc 4.1.0 on Solaris 9. Why do you think it should have well-dfeined behaviour? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #6 from gdr at integrable-solutions dot net 2007-01-10 03:32 --- Subject: Re: SIGSEGV in valarray::cshift(n) on empty array chris at bubblescope dot net [EMAIL PROTECTED] writes: | The standard refers to (l+n)%size(), so if size()=0, that seems to be | undefined. On the other hand, it seems fairly obvious what should happen in | this case (ie nothing). On the other other hand [semi ;-)], even without resorting to undefinedness of % size(), it takes a special rule to define the cyclic rotation of nothing. I don't see that special rule, which is why I asked why it was obvious that the result it well-defined. | On an unrelated note, isn't there a another bug in the standard here, as it | seems to be assuming that (-1)%n = (n-1) for positive n, which isn't required | by the standard? the c in cshift stands for cyclic, and yes the standard should have described the behviour in terms of cyclic permutation instead of showing an implementation. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #7 from gdr at integrable-solutions dot net 2007-01-10 03:33 --- Subject: Re: SIGSEGV in valarray::cshift(n) on empty array sebor at roguewave dot com [EMAIL PROTECTED] writes: | (In reply to comment #3) | The standard refers to (l+n)%size(), so if size()=0, that seems to be | undefined. On the other hand, it seems fairly obvious what should happen in | this case (ie nothing). | | The requirement is to return an object of length size() each of whose | elements... If there are no elements the ... doesn't/cannot apply. I disagree. The specification is not that of unconditional return. And if that is what is intended, then that is not what the standard wrote. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #8 from gdr at integrable-solutions dot net 2007-01-10 03:37 --- Subject: Re: SIGSEGV in valarray::cshift(n) on empty array pcarlini at suse dot de [EMAIL PROTECTED] writes: | Well, IMHO, avoiding this SIGSEGV is so easy, I would change anyway both shift | and cshift (i.e., wrap everything in a check that size() 0), and be done with | it, if nobody strongly disagree... Paolo -- there is what the standard says, and what we can or should implement. I believe there is a genuine bug in the standard here, no matter how easy it is to avoid the segmentation fault. This specific corner case is most likely run into in testsuites; we better have the standard be clear and let the testsuite implement what the standard says. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug target/8512] [hppa64-hp-hpux11.11] libstdc++-v3 fails to build with HP assembler
--- Comment #9 from gdr at integrable-solutions dot net 2007-01-09 05:28 --- Subject: Re: [hppa64-hp-hpux11.11] libstdc++-v3 fails to build with HP assembler jbuck at gcc dot gnu dot org [EMAIL PROTECTED] writes: | We might just document that it doesn't work for 4.0.4 assuming we do | that, and close the bug. That is fine with me. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8512
[Bug middle-end/30364] [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant folding
--- Comment #8 from gdr at integrable-solutions dot net 2007-01-05 21:06 --- Subject: Re: [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant folding jakub at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Do the parenthesis matter in C? Yes, see paragraphes 11 dowward in the section 5.1.2.3. | They do matter in say Fortran, but in C I | think | (a - 20) + (b - 20) can be evaluated as (a + b) + (-20 + -20) or a - 20 - 20 + | b while that is permitted by the fortran standard, it is my understanding that *existing* practice has fortran compilers refrain from messing with parenthesis. However, this has become a middle-end issue; so I guess I must voice the concern for languages where unconditional re-association is not permitted. The C and C++ languages are example of those. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug middle-end/30364] [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant folding
--- Comment #9 from gdr at integrable-solutions dot net 2007-01-05 21:09 --- Subject: Re: [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant folding pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: [...] | That is most explict thing about overflow and groupping. In C, every | expression has an implicate parenthesises. Yes. Note. however, that if people don't insist on signed integer arithmetic overflow being undefined, but intead define it as wrapping, they can reassociate and as they wish and the result won't change. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug c/30368] wrong result
--- Comment #4 from gdr at integrable-solutions dot net 2007-01-05 21:11 --- Subject: Re: wrong result pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | anther, consider an example definite[2] of 'offsetof', if you think | that is undefined, it's almost impossible to give a definite of | offsetof. | | #define offsetof(TYPE,MEMBER) ((size_t)((TYPE*)0)-MEMBER) | | The C standard still says that is undefined. See 6.5.3.2/4. | Also GCC has a builtin for offsetof to get around the undefinedness of the | above. The C front-end should probably warn -- the C++ front-end does. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30368
[Bug libstdc++/30365] No possibility to disable large file support (LFS)
--- Comment #26 from gdr at integrable-solutions dot net 2007-01-05 07:02 --- Subject: Re: No possibility to disable large file support (LFS) pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | I really don't think turning off LFS and using libstdc++ is a good idea anyways | because STL just bloats things anyways. Where is the connection? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30365
[Bug c++/30340] pure virtual function called on const declared with previous declaration without a definition, const assigned by temporary
--- Comment #9 from gdr at integrable-solutions dot net 2007-01-02 11:49 --- Subject: Re: pure virtual function called on const declared with previous declaration without a definition, const assigned by temporary mjtruog at fastmail dot ca [EMAIL PROTECTED] writes: | Thank you for looking at this. My mistake. [...] |What|Removed |Added | |Severity|normal |critical So, why did you raise this PR to critical? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30340
[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
--- Comment #5 from gdr at integrable-solutions dot net 2007-01-02 12:02 --- Subject: Re: New: '#define false FALSE' undefines '#define FALSE false' h8_spam at sonic dot net [EMAIL PROTECTED] writes: | I ran into an issue where doing #define FALSE false followed by #define false | FALSE undefined the first FALSE which is not what I would expect. | | Perhaps this is part of the standard, but in case not, I'm reporting it. During the translation phases 3-6, `true' and `false' are pp-tokens with special meanings. See 16.1/4. I don't know how common this PR is, to warrant a warning. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
--- Comment #6 from gdr at integrable-solutions dot net 2007-01-02 12:05
---
Subject: Re: '#define false FALSE' undefines '#define FALSE false'
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| --- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-01 22:34
---
| so what is happening here is the following:
|
| #define FALSE false
| #define false FALSE
|
| bool a = FALSE;
|
| So we get again:
| bool a = FALSE;
|
|
| This is the same problem as:
| int b;
|
| #define a b
| #define b a
|
| int main() {
| int test2 = a;
| }
|
| also true/false are not defined in C++ but rather they are keywords
`true' and `false' have special meanings, in C++, during
pre-processing phases. They can be used in the condition for
conditional inclusion, for example. Consequently, I don't think it is
valid to
#define false something
just like
#define 0 something
would be invalid.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
--- Comment #7 from gdr at integrable-solutions dot net 2007-01-02 12:06 --- Subject: Re: '#define false FALSE' undefines '#define FALSE false' h8_spam at sonic dot net [EMAIL PROTECTED] writes: | Right, but since true and false are keywords, I would expect the #define true | TRUE and false FALSE to be no-ops. I don't follow. Please see 16.1. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
--- Comment #8 from gdr at integrable-solutions dot net 2007-01-02 12:08 --- Subject: Re: '#define false FALSE' undefines '#define FALSE false' pinskia at gmail dot com [EMAIL PROTECTED] writes: | Subject: Re: '#define false FALSE' undefines '#define FALSE | false' | | On Mon, 2007-01-01 at 22:43 +, h8_spam at sonic dot net wrote: | Right, but since true and false are keywords, I would expect the | #define true | TRUE and false FALSE to be no-ops. | | | How? Preprocessing happens before tokenazation happens. Right; however `true' and `false' are also pp-tokens with special meanings during pre-processing. Therefore I think the PR is invalid, but you have to double-check that with a CPP expert. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug c++/28986] Failure to diagnose overflow in constant expression
--- Comment #7 from gdr at integrable-solutions dot net 2007-01-02 23:33 --- Subject: Re: Failure to diagnose overflow in constant expression andrew dot stubbs at st dot com [EMAIL PROTECTED] writes: | --- Comment #6 from andrew dot stubbs at st dot com 2007-01-02 14:04 --- | (In reply to comment #5) | Why is this accepts-invalid? Shouldn't it be diagnostic instead? I am | trying to understand what is the expected output here: a warning or a pedantic | error? | | Clause 5 paragraph 5 says it is ill-formed. Therefore accepts-invalid sounds | right to me. In C++, ill-formed implies diagnostic is required unless explicitly noted otherwise. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28986
[Bug c++/30340] pure virtual function called on const declared with previous declaration without a definition, const assigned by temporary
--- Comment #5 from gdr at integrable-solutions dot net 2007-01-01 09:47 --- Subject: Re: pure virtual function called on const declared with previous declaration without a definition, const assigned by temporary pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | For the last question on this code: | C c(1, B()); | | What is the life time of the temp that holds B()? That temporary is destroyed at the of the declaration of c -- e.g. right before the semicolon if I'm allowed that expression. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30340
[Bug libstdc++/30280] SIGSEGV on operator==(valarraybool, bool)
--- Comment #8 from gdr at integrable-solutions dot net 2006-12-23 11:17 --- Subject: Re: SIGSEGV on operator==(valarraybool, bool) pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | What target is this one, all I get is: | t.cc:8: error: cannot convert 'std::_Exprstd::_UnClosstd::__logical_not, | std::_Expr, std::_UnClosstd::__logical_not, std::_Expr, | std::_BinClosstd::__equal_to, std::_ValArray, std::_Constant, bool, bool , | bool' to 'long int' for argument '1' to 'long int __builtin_expect(long int, | long int)' I don't remember I ever used this funky __builtin_expect. valarray is improving everyday :-( -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug target/30280] SIGSEGV on operator==(valarraybool, bool)
--- Comment #13 from gdr at integrable-solutions dot net 2006-12-24 05:23 --- Subject: Re: SIGSEGV on operator==(valarraybool, bool) pinskia at gmail dot com [EMAIL PROTECTED] writes: | --- Comment #9 from pinskia at gmail dot com 2006-12-23 18:50 --- | Subject: Re: SIGSEGV on operator==(valarraybool, | bool) | | On Sat, 2006-12-23 at 11:17 +, gdr at integrable-solutions dot net | wrote: | | I don't remember I ever used this funky __builtin_expect. | valarray is improving everyday :-( | | | You most likely did not but assert did :). Doh. You're right; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug c++/29618] argument dependent lookup: what about built-in types?
--- Comment #4 from gdr at integrable-solutions dot net 2006-10-28 03:19 --- Subject: Re: argument dependent lookup: what about built-in types? v dot vasaitis at sms dot ed dot ac dot uk [EMAIL PROTECTED] writes: | Interesting analysis. However, wouldn't this imply that the example I posted | could be made to work if hash_value(long long) were put inside the boost | namespace? I don't see why. | Because it doesn't really; and in fact I can't find any way to make | it work, and I'd be grateful if you could point one out to me. the bugdatabase is about defects in the compiler suite, not about asking help to fix your programs. Please do not reopen bugs for the sole purpose of getting answers to questions that are best sent to appropriate newgroups. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29618
[Bug libstdc++/25608] g++ miscompiles gcjx
--- Comment #21 from gdr at integrable-solutions dot net 2006-10-24 06:18 --- Subject: Re: g++ miscompiles gcjx pcarlini at suse dot de [EMAIL PROTECTED] writes: | Gaby, any news about this issue? gcjx has been declared dead. I never got to have the issue fixed. So, it is up to you. It was a blocking issue for work on gcjx, and since the latter no longer exists it is less of an issue. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #6 from gdr at integrable-solutions dot net 2006-10-24 06:32
---
Subject: Re: New: Issues with -Wchar-subscripts
h dot b dot furuseth at usit dot uio dot no [EMAIL PROTECTED]
writes:
| [This is both a C and C++ bug report, not sure how to classify that.]
|
| int a[256];
| int A(char c) { return a[c]; } // C and C++ warnings, OK.
OK.
| int D(void) { return a['%'];} // Spurious C++ warning, no C warning
The absence of warning in C is OK -- literal characters have type int
in C. The warning in C++ is arguably bogus because the value of the
character '%' is known at compile-time, consequently the warning is
unwarranted (unless it really is negative).
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #24 from gdr at integrable-solutions dot net 2006-10-24 06:53 --- Subject: Re: [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | --- Comment #22 from mark at codesourcery dot com 2006-10-04 05:39 --- | Subject: Re: [4.0/4.1/4.2 Regression] placement new | does not change the dynamic type as it should | | ian at airs dot com wrote: | --- Comment #21 from ian at airs dot com 2006-10-03 23:44 --- | In C a general allocation function should work with a char array. A specific | allocation function should use a union. I don't think there are many existing | exceptions to these guidelines. | | So I don't see a serious problem in C either. Am I missing something/ | | I think there are two remaining issues: | |int i; |*(float*)(i) = 7.0; | | IIUC, Mike's position is that this is valid -- and that, in fact, after | this point i can no longer be accessed as an int. Do you agree? I don't see how that code is supported by the paragraphs quoted by Mike. There was a recent discussion (at most two weeks ago) on the C++ standard reflector -core about similar topic. I do agree with Mark that the proper way to resolve this is to go to the C++ committee. It would be incredible that C++ was less type-strict than C. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[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++/28687] [4.2 regression] dynamic_castvoid* 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_castvoid* 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_castvoid* 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_castvoid* 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++/28687] [4.2 regression] dynamic_castvoid* 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_castvoid* disallowed too rigorously with -fno-rtti benjamin at smedbergs dot us [EMAIL PROTECTED] writes: | Code compiled with -fno-rtti containing a dynamic_castvoid* 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_castvoid* 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_castvoid* 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 libstdc++/28587] vectorbool 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: vectorbool 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 libstdc++/28587] vectorbool 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: vectorbool 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 | vectorbool 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 vectorbool 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] vectorbool 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: vectorbool 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 vectorbool 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(complexdouble(-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(complexdouble(-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 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 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:
| templateconst char *str
| const char *baz ()
| {
| return str;
| }
|
| namespace { char foo[] = foo; };
|
| const char *
| bar ()
| {
| return bazfoo ();
| }
|
| 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++/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 valarrayT is permitted to return an object of another type, provided all the const member functions of valarrayT 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/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 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++/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++/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++/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
|
| templatetypename t 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++/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 cstdlib, 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 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 algorithm 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 algorithm 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++/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 c/27055] Structures are copied byte by byte into function arguments
--- Comment #1 from gdr at integrable-solutions dot net 2006-04-06 12:03 --- Subject: Re: New: Structures are copied byte by byte into function arguments guillaume dot melquiond at ens-lyon dot fr [EMAIL PROTECTED] writes: [...] | With 3.4.6, the copy is done byte-by-byte without string | opcodes. With 4.0.3 and 4.1.0, it is done byte-by-byte and | out-of-line: there are two jumps for each copied byte! So argument | copy got broken for x86 during GCC 3.4 cycle and it did not get any | better with GCC 4. That is insane, if I may. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27055
[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #5 from gdr at integrable-solutions dot net 2006-04-06 12:23 --- Subject: Re: When using excessive -ftemplate-depth g++ overflows the stack gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED] writes: | The standard says the limit have to be more than 17, No, the standard did not say that. the standard just said there is an implementation defined limit. An implementation may define that limit to be infinite. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #7 from gdr at integrable-solutions dot net 2006-04-06 13:09 --- Subject: Re: When using excessive -ftemplate-depth g++ overflows the stack gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED] writes: | ( As an aside that suggests that you could have a strictly conforming | implementation where the max limit is 0, but that discussion is more fitting on | comp.std.c++) That is technically correct; but it is beside the point. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug libstdc++/25608] g++ miscompiles gcjx
--- Comment #19 from gdr at integrable-solutions dot net 2006-03-17 23:37 --- Subject: Re: g++ miscompiles gcjx bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes: | is this still an active issue, or was it indicative of some temporary or | transient thing in the gcc sources? Now, I get a segmentation fault -- instead of dead lock. gcjx is compiled with mainline GCC/g++. I was trying to compile classptah. Adding generated files in builddir '..'. /home/gdr/bin/gcjx -encoding UTF-8 -classpath .: -d . @classes make[1]: *** [compile-classes] Segmentation fault make[1]: Leaving directory `/home/gdr/build/classpath/lib' -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
[Bug target/26436] [3.4 only] Use of 'mov' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 14
--- Comment #13 from gdr at integrable-solutions dot net 2006-02-28 09:02 --- Subject: Re: [3.4 only] Use of 'mov' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 14 wilson at gcc dot gnu dot org [EMAIL PROTECTED] writes: [...] | As a workaround, we could modify the compiler to try to detect nested DV cases, | and emit extra unnecessary .pred.rel.mutex directives for them. This would | work around the assembler bug. Jim, you seem to understand well the issue. Would you ve willing to contribute a patch? GCC-3.4.6 release is soon; otherwise, I will just close this PR as won't fix. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
[Bug c++/17332] [3.4 Regression] Missed inline opportunity
--- Comment #6 from gdr at integrable-solutions dot net 2006-02-28 10:13 --- Subject: Re: [3.4 Regression] Missed inline opportunity yuri at tsoft dot com [EMAIL PROTECTED] writes: | So there should be no performance-related bugs reported any more | since you only care about correctness? As ever, performance releated bugs are welcome. However, this is a bug that will not get fixed on the 3.4.x branch. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17332
[Bug c++/26395] Wrong attempts to create a copy of an anonymous object
--- Comment #2 from gdr at integrable-solutions dot net 2006-02-21 17:19 --- Subject: Re: Wrong attempts to create a copy of an anonymous object pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 15:59 --- | Please read: | http://gcc.gnu.org/gcc-3.4/changes.html | | | GCC before 3.4 was accepting invalid code. | | | -- | | pinskia at gcc dot gnu dot org changed: | |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||INVALID In fact, there should be an open PR for this -- which is a request for enhancement. The code is ill-formed under C++98 and C++03; it is well formed in C++0x (the changes are in the Working Paper.) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26395
[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented
--- Comment #26 from gdr at integrable-solutions dot net 2006-02-16 14:52 --- Subject: Re: --enable-languages=c,c++ not working as expected, documented pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | GDR you commented on this before: | http://gcc.gnu.org/ml/java/2000-12/msg00174.html good. So you understand that building things that are not asked for was considered at best annoying back then. | Back when the patch was created did you forgot about removing | directories now? so does it make it less issue today? Please stop being silly. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented
--- Comment #25 from gdr at integrable-solutions dot net 2006-02-16 14:49 --- Subject: Re: --enable-languages=c,c++ not working as expected, documented pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | How would you guys design this? That was explained in the several messages we sent. | Have configure do all the work? No. We would like configure not to be overzealous. | What happens when someone wants to add a new language, do you have to update | configure? No, on the contrary. [...] | Status|NEW |RESOLVED | Resolution||INVALID You seem to be toally confused and unable to understand the issue. For the nth time, please stop closing this issue. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented when removing gcc/ada and libada but not gnattools
--- Comment #31 from gdr at integrable-solutions dot net 2006-02-16 15:53 --- Subject: Re: --enable-languages=c,c++ not working as expected, documented when removing gcc/ada and libada but not gnattools pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #29) | Again this bug is about removing two directories and then trying to build | | You're totally confused. The bug really is about components being built | when they are not asked for. removing two directories is just a way | to trigger the behaviour. | | Actually the components were asked for since gnattools was not | associated with any language after the removal of gcc/ada. That is wrong. The component should be asked for because that decision is derived from the --enable-languages setting, not because gcc/Ada is missing. That is what the defect is about. See Benjamin's comment #15. | Since you're unable to appreciate that point, you have earn the right NOT | to touch this PR. Please concentrate your helping effort on other issues. | You're NOT being helpful here. | | I have been helpful by saying why it is not working the way you want it to be | working. This is how the building works. yes, you have been saying how it works, not *why* it should work that way. The PR acknowledges how it is currently working; the PR is saying that that current behaivour is not very helpful and should be improved. Please take a deep breath and explore that path. Is it really helpful or useful it wokrs the way it currently is? Can it be improved? While exploring that path, don't consider the current behaviuour God given. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented
--- Comment #18 from gdr at integrable-solutions dot net 2006-02-16 01:59 --- Subject: Re: --enable-languages=c,c++,fortran needs ada pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | | Status|UNCONFIRMED |RESOLVED | Resolution||INVALID Andrew -- Please stop closing issues until you fully appreciate what people are getting at. The current behaviour does NOT make much sense. BTW, you don't need a poll on IRC about me and this issue, as I've heard. Thanks. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented
--- Comment #19 from gdr at integrable-solutions dot net 2006-02-16 02:00 --- Subject: Re: --enable-languages=c,c++,fortran needs ada pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | The wiki mentions what needs to be removed also: | http://gcc.gnu.org/wiki/SvnSetup The Wiki is nice and helpful but it is not GCC official documentation. If there is any documented behaviour it should be part of GCC. If the documented behaviour does not make any sense, it should be changed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented
--- Comment #20 from gdr at integrable-solutions dot net 2006-02-16 02:01 --- Subject: Re: --enable-languages=c,c++,fortran needs ada bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes: | I guess I'm left unimpressed at the current --enable-languages=c,c++ behavior | though. This flag should not be a hint! Fully agreed. This issue should be reopened and the current behaviour be improved. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented
--- Comment #21 from gdr at integrable-solutions dot net 2006-02-16 02:05 --- Subject: Re: --enable-languages=c,c++ not working as expected, documented pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | I think there is a misunderstanding on how our build mechanism works and has | since at least 2000, since when it started working like that does not make it less than a bug. I had the same understanding as Benjamin when I saw the PR; then, walking through the steps just convinces me that the current behaviour is useless. It does not matter since when it was like that. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada
--- Comment #4 from gdr at integrable-solutions dot net 2006-02-14 18:15 --- Subject: Re: --enable-languages=c,c++,fortran needs ada pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Yes you forgot to remove the library and tools directory for Ada. So what? He did not ask for building Ada in --enable-languages. Clearly this is a bug. If I don't want to build C++, I don't have to remove the language and front-end directory -- it suffices I don't ask for C++ in --enable-languages. Ada should not be any different. | This bug report is, doctor it hurts when I do this. Doctor: Don't do it | then. That is pure nonsense. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada
--- Comment #6 from gdr at integrable-solutions dot net 2006-02-14 19:14 --- Subject: Re: --enable-languages=c,c++,fortran needs ada pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #4) | Subject: Re: --enable-languages=c,c++,fortran needs ada | | pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | | | Yes you forgot to remove the library and tools directory for Ada. | | So what? He did not ask for building Ada in --enable-languages. | Clearly this is a bug. If I don't want to build C++, I don't have to | remove the language and front-end directory -- it suffices I don't ask | for C++ in --enable-languages. Ada should not be any different. | | Lets look at what happens here. The ada subdirectory in gcc was | removed so the toplevel configure did not know those | libraries/programs are only to build when ada is enabled. But the point is that the build machinery should not attempt to build those libraries/programs when ada is not part of --enable-languages, not just when the ada directory is present or absent. The decision should be based on --enable-languages, nto just absence or presence of directory. | The same goes for when removing the c++ subdirectory in gcc and libstdc++ is | still being built. No. If not language (e.g. c++) requiring libstdc++ is specified, its build is not attempted, where the subdirectory is present or not. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada
--- Comment #8 from gdr at integrable-solutions dot net 2006-02-14 20:37 --- Subject: Re: --enable-languages=c,c++,fortran needs ada pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #6) | But the point is that the build machinery should not attempt to build | those libraries/programs when ada is not part of --enable-languages, | not just when the ada directory is present or absent. The decision | should be based on --enable-languages, nto just absence or presence of | directory. | But the language subdirectories has this information in config-lang.in. | For an example ada/config-lang.in: | | target_libs=target-libada | lang_dirs=gnattools Yes, I understand that. What I'm saying is that that file *enables* program/libraries to build for ada target; so by default the build machinery should not try to build anything that does not come from implied config-lang.in. In this case, since ada was not enabled, the ada-related tools builds should not be attempted -- whether the relevant config-lang.in is present or absent. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada
--- Comment #11 from gdr at integrable-solutions dot net 2006-02-14 21:11 --- Subject: Re: --enable-languages=c,c++,fortran needs ada pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-14 20:50 --- | (In reply to comment #9) | This is the opposite from what you think it does. I bet there is a documention | failure here but I have not checked yet. | | http://gcc.gnu.org/onlinedocs/gccint/Front-End-Config.html#Front-End-Config | lang_dirs | If defined, this variable lists (space-separated) top level directories | (parallel to gcc), apart from the runtime libraries, that should not be | configured if this front end is not built. | | | So it looks like it is documented a little but maybe not as we should have it. OK; that is odd (in terms of usability) but I guess a documentation clarification is most certainly welcomed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #3 from gdr at integrable-solutions dot net 2006-02-08 15:32 --- Subject: Re: -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call mueller at gcc dot gnu dot org [EMAIL PROTECTED] writes: | ugh, that warning isn't even in -Wextra. I'll be happy to review patch to make the warning work in the C++ front-end. I'll do it myself if nobody feels like tackling it :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug c++/26148] g++ bug, possibly introduced around gcc 3.4.0
--- Comment #4 from gdr at integrable-solutions dot net 2006-02-08 22:30 --- Subject: Re: g++ bug, possibly introduced around gcc 3.4.0 pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | try comp.lang.c++ first and then go from there. comp.std.c++ is the place to talk about ISO C++ definition -- that is where most ISO C++ standard people look for changes in C++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26148
[Bug c++/26099] support for type traits is not available
--- Comment #6 from gdr at integrable-solutions dot net 2006-02-05 03:56 --- Subject: Re: support for type traits is not available pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | The interest should really go to the committe than one | implementation. Now GCC can add this as an extensions and that can | help the discussion/decision to add it to the standard. I have no doubt many (all?) of of the tr1 traits will be part of C++0x. I think the PR is a valid request for enhancement, with priority higher than most requests for enhancements I've seen. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #24 from gdr at integrable-solutions dot net 2006-02-05 03:58 --- Subject: Re: gcc lays down two copies of constructors ian at airs dot com [EMAIL PROTECTED] writes: | I don't feel that this PR should be suspended, at least not until we | have fixed the common case. I think I agree with Ian. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #25 from gdr at integrable-solutions dot net 2006-02-05 04:00 --- Subject: Re: gcc lays down two copies of constructors pinskia at physics dot uc dot edu [EMAIL PROTECTED] writes: | But that does not work for some assemblers/file formats (like Darwin) as | Darwin's as finds subsections via labels. then we would just have not to implement what Ian proposes for Darwin. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug middle-end/26061] error and warning count
--- Comment #4 from gdr at integrable-solutions dot net 2006-02-02 15:12 --- Subject: Re: error and warning count pinskia at physics dot uc dot edu [EMAIL PROTECTED] writes: | IMO this is a useful feature because the number of lines of error output that | GCC produces for a file is not (always) a correct measure for the amount of | errors and warnings produced for that file. This is because GCC produces not | only the error messages themselves, but also extra helpful output. And it is | also nice to see in one fast look how many errors I still have to fix in my | code. | | It is not really a good measure as sometimes fixing one error will fix the | rest. true, but it is still a helpful information. That reminds of when I first iused sun's CC -- it really was a pleasant experience. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
--- Comment #13 from gdr at integrable-solutions dot net 2006-01-30 12:50 --- Subject: Re: std::advance() isn't stable for floating point numbers Woebbeking at web dot de [EMAIL PROTECTED] writes: | Subject: Re: std::advance() isn't stable for floating point numbers | | On Monday 30 January 2006 08:54, gdr at integrable-solutions dot net | wrote: | --- Comment #11 from gdr at integrable-solutions dot net | | | FYI, I suggested tests for 0 and 0 as MSVC 7.1 does it that | | way. | | | | If you convert Distance to difference_type the question is what | | happens if Distance is i.e. 0.2. Do you advance by 0 or 1 position? | | does not that follow from the conversion rule? | | Of course. I meant what should it do. Do you want it to advance by 0 or | 1 position? Do we just use a simple cast or do we need to do some | rounding? AFAIK MSVC advance by 1 in this case. Given that Distance is supposed to behave like en integral type in the first place, I would simply use: (1) implicit conversion to convert it to difference_type; (2) advance the number of time computed from (1). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020
[Bug c++/26037] no match for 'operator'
--- Comment #4 from gdr at integrable-solutions dot net 2006-01-30 18:14 --- Subject: Re: no match for 'operator' pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | I should note this is called argument dependent lookup (or ADL, there is | another name for it after a person but he no longer wants to be | associated with this). yup. The printing is a bit ugly though. Should be fixed (not the PR, the printing). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26037
[Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
--- Comment #4 from gdr at integrable-solutions dot net 2006-01-30 00:35 --- Subject: Re: std::advance() isn't stable for floating point numbers pcarlini at suse dot de [EMAIL PROTECTED] writes: | AFAICS, the standard is silent about this issue. I think the suggested change | is correct. I believe Martin Sebor filled a related PR, whereby we should have converted n to *some* integral type before proceeding... -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020
[Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
--- Comment #7 from gdr at integrable-solutions dot net 2006-01-30 01:05 --- Subject: Re: std::advance() isn't stable for floating point numbers pcarlini at suse dot de [EMAIL PROTECTED] writes: | --- Comment #5 from pcarlini at suse dot de 2006-01-30 00:45 --- | (In reply to comment #4) | | AFAICS, the standard is silent about this issue. I think the suggested | | change is correct. | | I believe Martin Sebor filled a related PR, whereby we should have | converted n to *some* integral type before proceeding... | | I was also under that impression. That issue, however, was about Size in algos, sorry; memory failing. | which, at least, is required to be convertible to an integral type. I don't | think we even have such *minimal* requirement here... What do you suggest? reading the standard specification let me under the impression that Distance is supposed to related to difference_type. For example the distance between the p before and after calling distance(p, n) is supposed to be n. So I would suggest conversion to the difference_type of the iterator as a momentary resolution. | Should the LWG discuss such kind of requirements for Distance too? Definitely. | In the meanwhile suspend? I have no strong opinions... I'm not sure the resolution would introduce an ABI breakage, so I would say let's do both; but I'm open to other alternatives. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020
[Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
--- Comment #8 from gdr at integrable-solutions dot net 2006-01-30 01:07 --- Subject: Re: std::advance() isn't stable for floating point numbers pcarlini at suse dot de [EMAIL PROTECTED] writes: | Hi again. On second tought, I don't think we have an issue here. Maybe of QoI | only, at most. The reason is that, according to 24.1/9, Distance is a | difference type in the following sections. A bit vague, but that seem to | imply to also the template argument Distance in 24.3.4 is a difference type... That matches my interpretation --- hence Distance must behave like an integral type -- but still, the question is exactly what kind of relation does it have with say std::iteratorFowardIterator::difference_type. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020
