[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 Woebbeking at web dot de --- 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 Woebbeking at web dot de --- 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=30722action=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 Woebbeking at web dot de changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #17 from André Wöbbeking Woebbeking at web dot de 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 Woebbeking at web dot de 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 #24 from André Wöbbeking Woebbeking at web dot de 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 #26 from André Wöbbeking Woebbeking at web dot de 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 #22 from André Wöbbeking Woebbeking at web dot de 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 Woebbeking at web dot de 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 Woebbeking at web dot de changed: What|Removed |Added CC||Woebbeking at web dot de --- Comment #13 from André Wöbbeking Woebbeking at web dot de 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] 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++/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=18622action=view) testcase -- 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
-- 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 #5 from Woebbeking at web dot de 2009-09-21 12:53 --- Paolo, but std::cout static_castfoo(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
--- 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++/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++/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] 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++/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_castB*(a);
static_castB*(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++/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++/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++/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++/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++/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 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++/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] 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=13194action=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 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] New: header dependencies
Hi,
could you clean up the header dependencies? E.g. a simple
#include memory
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 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 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] New: std::advance() isn't stable for floating point numbers
Hi, i.e. code like listint bla; // insert some stuff into bla listint::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++/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] 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++/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::__pooltrue::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0xb7fc7c26 in __gnu_cxx::__mt_allocstd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::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] 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::pairint, int 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++/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=9735action=view) example code, save-temps and compiler error message -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23896
[Bug c++/22137] New: Internal error: Segmentation fault (program cc1plus)
Hi,
the following code causes GCC to crash (without any options):
#include boost/optional.hpp
class Bla;
int main()
{
boost::optionalBla 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++/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=9124action=view) preprocessed code -- 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 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++/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 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 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 19:45 --- Thanks for enlightening me. -- 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++/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
[Bug c++/19404] New: error: 'QSizePolicy::anonymous enum' uses anonymous type
Hi,
the following Code doesn't compile:
class Base;
templatetypename Type
inline
Base
operator(Base rConfiguration,
Type const rType)
{
return rConfiguration;
}
templatetypename Type
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::anonymous enum' 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++/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
