[Bug c++/58273] [4.7/4.8/4.9 Regression] Segmentation fault with C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273 --- Comment #7 from André Wöbbeking --- Thanks!
[Bug tree-optimization/47679] [4.7/4.8/4.9 Regression] Strange uninitialized warning after SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 --- Comment #12 from André Wöbbeking --- Does anyone look into this? The warnings are really annoying. FYI, Clang 3.3 doesn't warn about this.
[Bug c++/58273] New: ICE: Segmentation fault with C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273 Bug ID: 58273 Summary: ICE: Segmentation fault with C++11 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Woebbeking at web dot de Created attachment 30722 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30722&action=edit Testcase Hi, I get an ICE with the attached test case when I compile with -std=c++11. I'm using GCC 4.8.1 from Debian experimental (x86_64). The ICE happens with 4.7.3 too. I don't get the ICE when I change the line to int i(B::goo(t)); int const i = B::goo(t); Cheers, André
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 André Wöbbeking changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #17 from André Wöbbeking 2013-04-23 08:07:27 UTC --- Thanks!
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 --- Comment #16 from André Wöbbeking 2013-04-14 14:15:47 UTC --- Thanks for your fast support!
[Bug c++/56895] New: ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 Bug #: 56895 Summary: ICE: unexpected expression of kind arrow_expr Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: woebbek...@web.de Created attachment 29843 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29843 reduced test case Hi, I get an ICE with the attached test case. I'm using GCC 4.8.0 from Debian experimental (x86_64). Cheers, André
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764 --- Comment #26 from André Wöbbeking 2013-03-15 13:45:50 UTC --- (In reply to comment #25) > (In reply to comment #24) > > 3) some other compiler don't compile this > > Which? Recent versions of EDG and clang both accept the testcase in comment > 22. MSVC 2010 In another duplicate ICC 6 was mentioned. > > couldn't you at least give us a warning (e. g. with -pedantic)? > > -pedantic means "strictly enforce the standard"; since the standard says that > the testcase in comment 22 is well-formed, -pedantic should not complain about > it. Someone could add another warning flag to warn about this, Yep, that is probably the better solution.
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764 --- Comment #24 from André Wöbbeking 2013-03-15 09:25:02 UTC --- OK, I read some explanations in the duplicates but still don't know why this should be valid code. IMO it makes no sense to write A:A:A:B and given the facts that 1) people don't write this intentionally 2) people expect this to be invalid (see number of duplicates) 3) some other compiler don't compile this couldn't you at least give us a warning (e. g. with -pedantic)?
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764 --- Comment #22 from André Wöbbeking 2013-02-20 16:31:47 UTC --- Hi, shouldn't struct A { struct B {}; }; int main() { A::A::B b; } fail to compile? It compiles with 4.6 and 4.7. Cheers, André
[Bug c++/35688] template visibility not overridden by template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688 --- Comment #14 from André Wöbbeking 2013-02-10 15:50:14 UTC --- Could anyone reply to my last question? Thanks in advance.
[Bug c++/35688] template visibility not overridden by template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688 André Wöbbeking changed: What|Removed |Added CC||Woebbeking at web dot de --- Comment #13 from André Wöbbeking 2012-12-08 12:09:37 UTC --- HI, I've the following problem with this: 3rd party libs don't "export" their templates, e. g. Boost doesn't export shared_ptr. So if I use a shared_ptr as template parameter the template itself isn't exported. I don't understand why fully declared templates like Boost's shared_ptr have a visibility at all. I know that C++11's shared_ptr is exported but that doesn't help me now. Do I've to change my code or is this a regression or is it Boost's fault? Cheers, André
[Bug c++/41425] switch with enums doesn't work
--- Comment #9 from Woebbeking at web dot de 2009-09-21 16:46 --- So it's ok to change the behavior in a minor release? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
[Bug c++/41425] switch with enums doesn't work
--- Comment #5 from Woebbeking at web dot de 2009-09-21 12:53 --- Paolo, but std::cout << static_cast(i); prints 5, so it's not the conversion but the switch statement which is "broken". Richard, if it's only truncation shouldn't case B be triggered? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
[Bug c++/41425] switch with enums doesn't work
-- Woebbeking at web dot de changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
[Bug c++/41425] switch with enums doesn't work
--- Comment #2 from Woebbeking at web dot de 2009-09-21 12:21 --- g++ case.cpp is sufficient to reproduce this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
[Bug c++/41425] switch with enums doesn't work
--- Comment #1 from Woebbeking at web dot de 2009-09-21 12:19 --- Created an attachment (id=18622) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18622&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
[Bug c++/41425] New: switch with enums doesn't work
If I cast an int to the enum type all values outside the enum triggers the first case-statement. The number of enum values is important. It must be a power of 2. This works in GCC 4.3.4. -- Summary: switch with enums doesn't work Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #15 from Woebbeking at web dot de 2009-06-01 10:28 --- Ian, I know open source and I also know that some parts are more interesting than others :-) Most the time I'm a happy GCC user (sure, it could be faster but that's what compile farms are for). But this bug is assigned for nearly 6 years now that makes me a bit sad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
[Bug c++/40294] method definition can have the class scope multiple time
--- Comment #2 from Woebbeking at web dot de 2009-05-30 08:49 --- Thanks, I didn't know which term I should looking for :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40294
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #13 from Woebbeking at web dot de 2009-05-30 08:46 --- If you're sure that it's a bug why isn't it fixed yet? Is it that hard that you need more than six years? Sure it's no show stopper but it's annoying. I'm using -pedantic and -ansi to ensure platform independent code and then this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
[Bug c++/40294] New: method definition can have the class scope multiple time
Hi, is it correct that struct S { S(); }; S::S::S::S::S() { } int main() { S s; return 0; } compiles? At least other compilers have problems with that. Cheers, André -- Summary: method definition can have the class scope multiple time Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40294
[Bug c++/38557] New: dynamic_cast should give a warning/error for non related classes
Hi, in this example struct A { virtual ~A() {} }; struct B { virtual ~B() {} }; int main() { A* a(0); dynamic_cast(a); static_cast(a); return 0; } the static_cast gives an error but the dynamic_cast not even a warning. Cheers, André -- Summary: dynamic_cast should give a warning/error for non related classes Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38557
[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions
--- Comment #10 from Woebbeking at web dot de 2008-11-30 15:46 --- And if you've many overloads of a virtual function and override only one you also get a warning. And in some projects this happens very often :-( So I also support this suggestion! -- Woebbeking at web dot de changed: What|Removed |Added CC||Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17920
[Bug c++/20423] Warning -Woverloaded-virtual triggers to often
--- Comment #7 from Woebbeking at web dot de 2008-11-30 15:36 --- Any progress on this? This warning could be really useful if only 1) would be handled. In its current state I can't use it as I get too many "false" positives :-( -- Woebbeking at web dot de changed: What|Removed |Added CC| |Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423
[Bug c++/32282] dynamic_cast compiles where static_cast fails
--- Comment #2 from Woebbeking at web dot de 2007-06-11 11:42 --- Oops, I searched for dynamic_cast but didn't find that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32282
[Bug c++/32282] New: dynamic_cast compiles where static_cast fails
Hi, this happens if you cast to an unrelated class. Could you at least give a warning. Cheers, André -- Summary: dynamic_cast compiles where static_cast fails Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32282
[Bug c++/31147] increased size of debug information
--- Comment #4 from Woebbeking at web dot de 2007-03-12 16:46 --- Created an attachment (id=13194) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13194&action=view) preprocessed qcombobox.cpp I added both versions (4.2.0 and 4.1.2). It's compiled with -c -fno-exceptions -pipe -O2 -g -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
[Bug c++/31147] increased size of debug information
--- Comment #2 from Woebbeking at web dot de 2007-03-12 14:22 --- Subject: Re: increased size of debug information On Monday 12 March 2007, rguenth at gcc dot gnu dot org wrote: > It's more information - whether it's useful depends. Wow, more than 50%. Are there any docs to this change? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
[Bug c++/31147] New: increased size of debug information
Hi, compared to 4.1.2 the size increased by 50% and more. E.g. Qt 4.2.2 libQtGui.so.4.2.2.debug - 4.2.0 97902763 bytes - 4.1.2 62435403 bytes We compile with -O2 -g. Is this a regression or just more (useful?) information? -- Summary: increased size of debug information Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #7 from Woebbeking at web dot de 2007-03-12 09:37 --- Any news on this? It's really annoying if you've many pimpls which often use anonymous namespace. -- Woebbeking at web dot de changed: What|Removed |Added CC| |Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug libstdc++/28080] header dependencies
--- Comment #11 from Woebbeking at web dot de 2007-02-17 20:42 --- Subject: Re: header dependencies On Saturday 17 February 2007, pcarlini at suse dot de wrote: > I have some improvements in testing... Nice to hear :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug libstdc++/28080] header dependencies
--- Comment #4 from Woebbeking at web dot de 2006-06-19 17:58 --- Subject: Re: header dependencies On Monday 19 June 2006 11:29, pcarlini at suse dot de wrote: > --- Comment #1 from pcarlini at suse dot de 2006-06-19 09:29 > Ok, let's see what we can do... Wow, fast reply! I hope you're successful :-) Maybe you could look at STLPort 5.x, AFAIK it's "more" efficient in this case. It also has other nice features like: - STL containers vector, deque, list and slist pointer specialization to limit code bloats (see _STLP_USE_PTR_SPECIALIZATIONS on config file); - Expression template for string concatenation operations (available through the _STLP_USE_TEMPLATE_EXPRESSION config option); Cheers, André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug libstdc++/28080] New: header dependencies
Hi, could you clean up the header dependencies? E.g. a simple #include int main() { return 0; } produces 250kb preprocessed output. So the usage of STL slows down compilation considerable. Cheers, André -- Summary: header dependencies Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug c++/27935] gcc fails to compile code with operator delete(void*,size_t)
--- Comment #5 from Woebbeking at web dot de 2006-06-07 20:30 --- FYI, it doesn't work in gcc version 4.1.2 20060604 (prerelease) (Debian 4.1.1-2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
[Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
--- Comment #12 from Woebbeking at web dot de 2006-01-30 12:03 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020
[Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
--- Comment #10 from Woebbeking at web dot de 2006-01-30 07:07 --- Subject: Re: std::advance() isn't stable for floating point numbers On Monday 30 January 2006 02:09, pcarlini at suse dot de wrote: > --- Comment #9 from pcarlini at suse dot de 2006-01-30 01:09 > --- (In reply to comment #7) > > > 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. > > Excellent idea. 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020
[Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
--- Comment #2 from Woebbeking at web dot de 2006-01-29 23:40 --- Subject: Re: std::advance() isn't stable for floating point numbers On Monday 30 January 2006 00:32, pinskia at gcc dot gnu dot org wrote: > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-29 > 23:32 --- > What does the standard says about this case? Don't know, but I was suprised that Distance is a template parameter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020
[Bug libstdc++/26020] New: std::advance() isn't stable for floating point numbers
Hi, i.e. code like list bla; // insert some stuff into bla list::iterator it(bla.begin()); advance(it, bla.size() * 0.5); can lead to an endless loop. I know that the code is "broken" but it should work nevertheless. Please change the code to < 0 and > 0, not just while (n--). Cheers, André -- Summary: std::advance() isn't stable for floating point numbers Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete its keys
--- Additional Comments From Woebbeking at web dot de 2005-09-28 17:16 --- Subject: Re: mt allocator doesn't pthread_key_delete its keys On Tuesday 27 September 2005 16:43, jakub at gcc dot gnu dot org wrote: > If you are compiling with -fvisibility*, > then the problem is PR libstdc++/22482, not this one. I compile with -fvisibility=hidden -fvisibility-inlines-hidden, but I get no linker errors. And as noted export GLIBCXX_FORCE_NEW=1 prevents the crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete its keys
--- Additional Comments From Woebbeking at web dot de 2005-09-27 14:38 --- Subject: Re: mt allocator doesn't pthread_key_delete its keys On Tuesday 27 September 2005 01:03, bkoz at gcc dot gnu dot org wrote: > --- Additional Comments From bkoz at gcc dot gnu dot org > 2005-09-26 23:03 --- > > André, > > Any chance you can detail how I can reproduce your failure? The only way I know is to compile artsd and run it from console, it crashes at once. I already tried to write a small test case but I totally failed. Let me know if a backtrace with more debug information could help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete its keys
--- Additional Comments From Woebbeking at web dot de 2005-09-24 14:44 --- Hi, I already thought that is the same as with KDE's artsd but it still crashes for me (since GCC 4.0.0): #0 0xb7857b5e in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0xb7fc7c26 in __gnu_cxx::__mt_alloc >::deallocate (this=0xbffe8a20, __p=0x81015d0, __n=4) at mt_allocator.h:714 #2 0xb7fc8b2e in ~ObjectReference (this=0xbffe8a14) at stl_vector.h:123 #3 0xb7fbafd3 in Arts::SoundServerStartup_base::_fromString ([EMAIL PROTECTED]) at ./soundserver/soundserver.cc:2545 #4 0x0806a832 in Arts::SoundServerStartup_impl::cleanReference ( this=0x8159838) at soundserver.h:1376 #5 0x0806b1f2 in Arts::SoundServerStartup_impl::lock (this=0x8159838) at /Devel/src/kde/arts/soundserver/soundserverstartup_impl.cc:78 I'm using Debian's GCC 4.0.1-9 (CVS 20050922) and compile with visibility support. Without visibility or with export GLIBCXX_FORCE_NEW=1 it doesn't crash. The specs are: Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 (Debian 4.0.1-9) Cheers, André -- What|Removed |Added CC| |Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug c++/23896] [4.0/4.1 Regression] boost::tie() = std::pair doesn't compile
--- Additional Comments From Woebbeking at web dot de 2005-09-20 17:21 --- Works for me. I hope VERIFIED is the same as CLOSED. -- What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23896
[Bug c++/23896] [4.0/4.1 Regression] boost::tie() = std::pair doesn't compile
--- Additional Comments From Woebbeking at web dot de 2005-09-17 08:30 --- Wow, that was fast, thanks. I'll give it a try with the next Debian package. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23896
[Bug c++/23896] boost::tie() = std::pair doesn't compile
--- Additional Comments From Woebbeking at web dot de 2005-09-15 14:54 --- Created an attachment (id=9735) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9735&action=view) example code, save-temps and compiler error message -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23896
[Bug c++/23896] New: boost::tie() = std::pair doesn't compile
Hi, with Debian's gcc (version 4.0.2 20050913 (prerelease) (Debian 4.0.1-7)) this doesn't compile anymore: const std::pair p(1, 2); int i, j; boost::tie(i, j) = p; It works with all older versions and MSVC 7.1. Cheers, André -- Summary: boost::tie() = std::pair doesn't compile Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de CC: doko at cs dot tu-berlin dot de,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23896
[Bug c++/22137] Internal error: Segmentation fault (program cc1plus)
--- Additional Comments From Woebbeking at web dot de 2005-06-21 16:51 --- Created an attachment (id=9124) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9124&action=view) preprocessed code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22137
[Bug c++/22137] New: Internal error: Segmentation fault (program cc1plus)
Hi, the following code causes GCC to crash (without any options): #include class Bla; int main() { boost::optional test; } I can reproduce it with GCC 4 but not with GCC 3.3.6. Without ulimit -s this error crashes even the whole system. Smells like kind of endless recursion. Cheers, André -- Summary: Internal error: Segmentation fault (program cc1plus) Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22137
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 19:45 --- Thanks for enlightening me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 17:24 --- I see. Then I'm looking forward to 4.1 :-) One last thing: is it a bug that the behaviour differs for named namespace in my second example? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 16:17 --- Are you sure? None of the given PRs uses friend declarations. In my two cases I only have to use friend struct ::S1 and all is fine but to find the broken friend declarations is PITA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 16:01 --- One additional note: if I use a named namespace in the 2nd case it compiles fine. Dunno if this is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 15:23 --- Hi, he's not complaining about the "new" friend lookup behaviour but about the misleading error message. I had two similar cases and it was not easy to find out what was going on. Have a look at the attachments. Cheers, André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From Woebbeking at web dot de 2005-01-14 09:56 --- Subject: Re: [4.0 Regression] name lookup is broken with friends On Thursday 13 January 2005 15:52, lerdsuwa at gcc dot gnu dot org wrote: > > > So B's ctor uses the global A without the friend declaration and with the > > friend declaration the local injected A? Sometimes the holy standard > > confuses me a bit. > > No. With or without friend declaration, the B's ctor should always pick > the global A. This is one weird rule in C++ standard. Now I'm even more confused than before. Who is right, Gaby or lerdsuwa? André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From Woebbeking at web dot de 2005-01-13 10:07 --- Subject: Re: [4.0 Regression] name lookup is broken with friends On Wednesday 12 January 2005 20:37, gdr at integrable-solutions dot net wrote: > > Excuse me? > > The behaviour mandated by the C++ standard is that if there is no > declaration for type A in the innermost enclosing namespace then an > implicit one is added -- because A is used unqualified. In > particular, the global A should not be found. Thus the code is > ill-formed. So B's ctor uses the global A without the friend declaration and with the friend declaration the local injected A? Sometimes the holy standard confuses me a bit. André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19406] New: ICE: in force_decl_die, at dwarf2out.c:12442
Hi, I get the mentioned ICE if I compile the following code with -g (gcc < 4 works fine): struct A { virtual int foo(); double d; }; struct B : public A { A::d; }; int main() { return 0; } Cheers, André -- Summary: ICE: in force_decl_die, at dwarf2out.c:12442 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19406
[Bug c++/19404] New: error: 'QSizePolicy::' uses anonymous type
Hi, the following Code doesn't compile: class Base; template inline Base& operator<<(Base& rConfiguration, Type const& rType) { return rConfiguration; } template inline Base const& operator>>(Base const& rConfiguration, Type& rType) { return rConfiguration; } struct QSizePolicy { enum { HSize = 6, HMask = 0x3f, VMask = HMask << HSize }; enum SizeType { Fixed = 0 }; SizeType verData() const { return (SizeType)( (data & VMask) >> HSize ); } void setVerData( SizeType d ) { data = (unsigned int)(data & ~(HMask << HSize)) | (d << HSize); } unsigned int data; }; It compiles with g++ < 4.0. Cheers, André -- Summary: error: 'QSizePolicy::' uses anonymous type Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19404
[Bug c++/19403] New: name lookup is broken
Hi, the following code doesn't compile: struct A {}; namespace Boo { struct B { friend struct A; B(const A&) {}; }; } int main() { A a; Boo::B b(a); return 0; } It compiles with g++ < 4.0. -- Summary: name lookup is broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403