https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58751
--- Comment #2 from Job Noorman ---
I can also confirm that this is reproducible with GCC 4.9.
Also note that Clang *does* accept this code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63339
Job Noorman changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58751
Job Noorman changed:
What|Removed |Added
CC||jobnoorman at gmail dot com
--- Comment
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jobnoorman at gmail dot com
GCC implicitly deletes constructors pulled from a virtual base class with a
"using" directive. The error indicates GCC thinks the default def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48578
--- Comment #2 from Job Noorman 2011-04-12
18:29:41 UTC ---
Ok I see. Thanks for the clarification!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48578
Summary: Range-based for-loops do not compile when -nostdinc is
given
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
--- Comment #8 from jobnoorman at gmail dot com 2010-09-09 08:00 ---
(In reply to comment #7)
> That's because the compiler's expectation is that if you define
> __cxa_guard_acquire, you also define __cxa_guard_release and
> __cxa_guard_abort.
> And, they should
--- Comment #6 from jobnoorman at gmail dot com 2010-09-09 07:35 ---
(In reply to comment #5)
> Then you should look into the ABI to see how it is defined. I think this ICE
> only happens when it is declared incorrectly.
According to the ABI, it should be declared as
extern &
--- Comment #4 from jobnoorman at gmail dot com 2010-09-09 07:25 ---
(In reply to comment #3)
> You need to include -fno-threadsafe-statics to disable the use of
> __cxa_guard_acquire. This functions is part of the normal C++ ABI we follow
> (the IA64 C++ ABI and it is includ
--- Comment #2 from jobnoorman at gmail dot com 2010-09-09 07:11 ---
(In reply to comment #1)
> Note, if you really need the name __cxa_guard_acquire to trigger the bug,
> which
> is in the implementor "namespace", due to the double underscore in front, this
> is
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jobnoorman at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
--- Comment #7 from jobnoorman at gmail dot com 2010-08-18 14:03 ---
(In reply to comment #3)
> Looking at the diagnostics issued when -pedantic is added, I think the right
> conversion is
>
> (void*)(plain_foobar_t)&Foo::foobar
>
> That still uses the G++ exten
--- Comment #6 from jobnoorman at gmail dot com 2010-08-17 10:49 ---
(In reply to comment #5)
> For inline-asm? Certainly not. Consider much simpler:
> void foo (void)
> {
> int i;
> i = 6;
> asm volatile ("" : : "i" (i));
> }
> which
--- Comment #4 from jobnoorman at gmail dot com 2010-08-17 10:04 ---
(In reply to comment #1)
> IMHO this isn't a bug, to simplify that into an integer you really need some
> optimizations. The conversion looks very weird, if you use something saner
> like (void *)&Fo
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jobnoorman at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45303
15 matches
Mail list logo
