[Bug bootstrap/57900] /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2013-09-01 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added CC||gdr at gcc dot

[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

2013-08-30 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #9 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #8) note that the patch at: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01460.html is not quite enough to fix this on Darwin - since we

[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

2013-08-30 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #12 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #10) also the gcc driver silently ignores -static-libstdc++. Isn't this the problem? certainly, the -B options are passed when other gcc

[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

2013-08-25 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #1 from Gabriel Dos Reis gdr at gcc dot gnu.org --- Here is the definition of pretty_printer::~pretty_printer () at the location indicated: pretty_printer::~pretty_printer () { buffer-~output_buffer (); XDELETE (buffer

[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

2013-08-25 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #2 from Gabriel Dos Reis gdr at gcc dot gnu.org --- OK, I see the emitted reference to 'operator delete', and I suspect I have an idea of why the compiler generated this reference even though it isn't used anywhere in the input source

[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

2013-08-25 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #5 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) (In reply to Gabriel Dos Reis from comment #2) OK, I see the emitted reference to 'operator delete', and I suspect I have an idea

[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

2013-08-25 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #6 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #4) OK, I see the emitted reference to 'operator delete', and I suspect I have an idea of why the compiler generated this reference even

[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

2013-08-25 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #7 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #4) OK, I see the emitted reference to 'operator delete', and I suspect I have an idea of why the compiler generated this reference even

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

2013-07-26 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #2 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #1) Gaby, can you help me with this? I think this is typical confusion about what valarray expressions are. f1() has some complicated return

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

2013-07-26 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #3 from Gabriel Dos Reis gdr at gcc dot gnu.org --- Also, there might be some interactions with move semantics; I don't know.

[Bug middle-end/57974] std::pow(std::complexlong double(0),1) returns (-nan,-nan)

2013-07-25 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #11 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #10) Gaby, do you have an opinion on this? Irrespective of the long double issue, do you want me to re-enable (contra LWG 844) the pow(const

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

2013-07-04 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #30 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #27) DR2058 is now WP, thus we are supposed to reassess this. Now, according to the resolution, additional 'begin' and 'end' overloads shall

[Bug c++/11582] Odd error message with dynamically sized template arg printing

2013-04-22 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582 --- Comment #8 from Gabriel Dos Reis gdr at gcc dot gnu.org 2013-04-22 10:10:36 UTC --- (In reply to comment #7) The '[(((sizetype)anonymous) + 1)]' is just awful. If we don't know the actual type there, that is int [size()], then we

[Bug c++/11582] Odd error message with dynamically sized template arg printing

2013-04-22 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582 --- Comment #10 from Gabriel Dos Reis gdr at gcc dot gnu.org 2013-04-23 03:45:56 UTC --- (In reply to comment #9) (In reply to comment #8) Printing int[] or int[size_t] would be confusing too. More confusing than int[(((sizetype)anonymous

[Bug c++/54401] New: Missing diagnostics about type-alias at class scope

2012-08-29 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401 Bug #: 54401 Summary: Missing diagnostics about type-alias at class scope Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major

[Bug c++/54401] Missing diagnostics about type-alias at class scope

2012-08-29 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last

[Bug driver/52863] New: Enable -Wall by default

2012-04-04 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52863 Bug #: 52863 Summary: Enable -Wall by default Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc

2012-02-29 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added CC||gdr at gcc dot

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

2011-11-02 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added CC||gdr at gcc dot

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

2011-11-02 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #14 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-11-02 12:27:20 UTC --- (In reply to comment #9) Created attachment 25654 [details] BC2 Since we are talking about branch cut and prespectiving since zeros, I think we should

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

2011-11-02 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #17 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-11-02 12:48:23 UTC --- (In reply to comment #16) Well, I guess this would be most of it: templatetypename _Tp std::complex_Tp __complex_acosh(const std::complex_Tp

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

2011-11-02 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #18 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-11-02 12:48:47 UTC --- (In reply to comment #16) Well, I guess this would be most of it: templatetypename _Tp std::complex_Tp __complex_acosh(const std::complex_Tp

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

2011-06-14 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #24 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-06-14 13:54:13 UTC --- (In reply to comment #18) It should be identical to auto range = v1 + v2; for (auto b = std::begin(range), e = std::end(range); b != e; ++b

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

2011-06-14 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #25 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-06-14 14:01:30 UTC --- (In reply to comment #23) Ok, now I see, it's the operator[] of _BinBase which returns by value, I overlooked that. Yes, val in valarray stands for value

[Bug libstdc++/48365] Non-constant references in std::valarray::operator

2011-06-14 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added CC||gdr at gcc dot

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

2011-05-17 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added CC||gdr at gcc dot

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

2011-05-17 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #7 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-05-17 15:14:04 UTC --- (In reply to comment #6) Double Sigh! I was hoping very few overloads would be enough... If we are really talking about many I would be in favor of raising

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

2011-05-17 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #13 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-05-17 16:24:57 UTC --- (In reply to comment #11) All in all, now that I understand the issue with the temporary, this seems really sort of a NAD, maybe the wording needs only

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

2011-05-17 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #12 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-05-17 16:23:37 UTC --- (In reply to comment #10) For sure that works. Gaby, just to make sure we are on the same page: did you send a message to the reflector about this issue

[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's

2011-04-29 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #30 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-04-29 23:52:32 UTC --- (In reply to comment #29) This is now fixed in 4_6-branch too in C++03 mode, not in C++0x mode, where we would need list-initialization of __complex__

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

2011-04-26 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #14 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-04-26 14:12:35 UTC --- (In reply to comment #12) (In reply to comment #9) I guess, in the 4.6.1 time frame we can only workaround the issue in C++03 mode by doing

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

2011-04-25 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added CC||gdr at gcc dot

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

2011-04-25 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added CC||jason at redhat

[Bug libstdc++/48101] New: obscure error message with std::setconst int

2011-03-13 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48101 Summary: obscure error message with std::setconst int Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug c++/46983] Diagnostic about change in meaning of name in class misses some cases

2010-12-16 Thread gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46983 Gabriel Dos Reis gdr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last