[Bug c++/38759] New: Incorrect warning/error when compiling with a typedef'ed ptr return type

2009-01-07 Thread gnu at bluedreamer dot com
y: Incorrect warning/error when compiling with a typedef'ed ptr return type Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu d

[Bug c++/32730] New: std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread gnu at bluedreamer dot com
CONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at bluedreamer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730

[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread gnu at bluedreamer dot com
--- Comment #1 from gnu at bluedreamer dot com 2007-07-11 18:10 --- Created an attachment (id=13887) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13887&action=view) Source file Example source that causes bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730

[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread gnu at bluedreamer dot com
--- Comment #2 from gnu at bluedreamer dot com 2007-07-11 18:11 --- Created an attachment (id=13888) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13888&action=view) >From --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730

[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread gnu at bluedreamer dot com
--- Comment #3 from gnu at bluedreamer dot com 2007-07-11 18:11 --- Created an attachment (id=13889) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13889&action=view) >From --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730

[Bug c++/44611] New: Including and hides ::signbit function

2010-06-21 Thread gnu at bluedreamer dot com
time-tools=/usr/local --enable-lto Thread model: posix gcc version 4.5.0 (GCC) -- Summary: Including and hides ::signbit function Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++

[Bug c++/44611] Including and hides ::signbit function

2010-06-21 Thread gnu at bluedreamer dot com
--- Comment #1 from gnu at bluedreamer dot com 2010-06-21 14:31 --- Created an attachment (id=20963) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20963&action=view) Source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44611] Including and hides ::signbit function

2010-06-21 Thread gnu at bluedreamer dot com
--- Comment #2 from gnu at bluedreamer dot com 2010-06-21 14:31 --- Created an attachment (id=20964) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20964&action=view) --save-temps output .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44611] Including and hides ::signbit function

2010-06-21 Thread gnu at bluedreamer dot com
--- Comment #3 from gnu at bluedreamer dot com 2010-06-21 14:32 --- Created an attachment (id=20965) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20965&action=view) --save-temps output .s file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44611] Including and hides ::signbit function

2010-06-21 Thread gnu at bluedreamer dot com
--- Comment #9 from gnu at bluedreamer dot com 2010-06-21 16:07 --- > I agree the macro and template can't co-exist, but the template could be > available as both std::signbit and ::signbit, and I think that's required by > appendix D. Are these still relevant

[Bug c++/44611] Including and hides ::signbit function

2010-06-21 Thread gnu at bluedreamer dot com
--- Comment #11 from gnu at bluedreamer dot com 2010-06-21 16:20 --- (In reply to comment #10) > (In reply to comment #9) > > Are these still relevant for c++0x? More so section 5 which says if they are > > macros in C they must be macros in C++ > > see 26.8

[Bug c++/44611] Including and hides ::signbit function

2010-06-21 Thread gnu at bluedreamer dot com
--- Comment #13 from gnu at bluedreamer dot com 2010-06-21 16:31 --- (In reply to comment #12) > Is there a reason you changed the component back to c++? > This is not a problem in the C++ compiler front-end. > I didn't mean to change anything. All I did was reply (maybe