ersion: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
gcc 10 regression: the same source file builds in gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
--- Comment #2 from Avi Kivity ---
It does not look similar to 93923. There, there is an incomplete type. In my
reproducer the type is complete but the default constructor is private.
Note that for simple cases is_trivially_constructible works (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
--- Comment #3 from Avi Kivity ---
Created attachment 47993
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47993&action=edit
reduced test case
Reduced test case, build with g++ -std=gnu++17 -c database
works on gcc 9.2.1, fails on gcc 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
--- Comment #4 from Avi Kivity ---
Type in build instructions, should be
g++ -std=gnu++17 -c database.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
--- Comment #7 from Avi Kivity ---
That commit is in gcc 9.3, so I'm guessing 9.3 is affected too.
5c7938eb3f1a116b1cf9a28090f2cc5e08814ce4 tags/releases/gcc-9.3.0~221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
--- Comment #9 from Avi Kivity ---
Thanks. I'll test 9.3 as soon as it hits koji.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
--- Comment #13 from Avi Kivity ---
Can you attach the patch here please?
I'd like to test that this is the only blocker for adopting gcc 10 for us, so
that we can adopt it as soon as it is released. I'm anxious to start using
coroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
--- Comment #16 from Avi Kivity ---
I confirm this fixes my original problem, not just the reduced test case.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Created attachment 48303
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48303&action=edit
reduced test case (before prepro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645
--- Comment #1 from Avi Kivity ---
Created attachment 48304
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48304&action=edit
reduced test case (after preprocessing)
This is what the compiler spat out after it failed to compile the
non-prep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #20 from Avi Kivity ---
Note that clang generates cmpxchg16b when the conditions are ripe:
https://godbolt.org/z/j9Whgh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #22 from Avi Kivity ---
Perhaps PR 84522 should be reopened and unmarked as a duplicate. While the
reproducer there is a C API, it is the C equivalent of
().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94644
Avi Kivity changed:
What|Removed |Added
CC||a...@cloudius-systems.com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #24 from Avi Kivity ---
I'll file a new PR.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
The code
#include
struct alignas(16) a {
long x;
long y;
};
bool cmpxchg(std::atomic& data, a expected, a ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #25 from Avi Kivity ---
PR 94649.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645
--- Comment #4 from Avi Kivity ---
Yes (at least mine, don't know about Rafael's)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
--- Comment #2 from Avi Kivity ---
Maybe we can have a new flag -mcx16all that assumes that all code using 16-byte
CAS is compiled with the flag.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
coroutines copy their input to the coroutine frame, so a coroutine like
future f(T x) {
co_await something();
co_return x;
}
will copy x back from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #2 from Avi Kivity ---
Created attachment 48524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48524&action=edit
lame testcase
Lame testcase that shows that the lambda is passed as a pointer rather than by
value, leading to a l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #3 from Avi Kivity ---
The test case I uploaded only shows the failure, it won't work if gcc worked as
I expect it. I'll try to get a better testcase, unfortunately a small coroutine
testcase is still some work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #5 from Avi Kivity ---
This snippet from cppreference:
If the coroutine is a non-static member function, such as task
my_class::method1(int x) const;, its Promise type is
std::coroutine_traits, const my_class&, int>::promise_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #8 from Avi Kivity ---
Created attachment 48526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48526&action=edit
less lame testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #7 from Avi Kivity ---
I have a simple reproducer. A lambda fails while a fake lambda using structs
passes. I don't think gcc is at fault, but the standard is problematic here
IMO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #10 from Avi Kivity ---
Well, the standard is useless here.
In
[foo] () -> lazy { co_return foo; } ()
a temporary is clearly passed to the lambda body, yet the standard mandates
that we capture it by reference. As a result, a u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #11 from Avi Kivity ---
I started a conversation on the std-proposals list about this.
Meanwhile, how about a -fnonstandard-coroutines-that-actually-work flag that
captures the parameter to a non-static member function coroutine by v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #13 from Avi Kivity ---
Yes. gcc has a minor bug in that the lambda is reflected as a pointer instead
of a reference in coroutine_traits. The major bug is in the standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #15 from Avi Kivity ---
I believe that my suggestion works for mutable lambdas (and for any coroutine
called as a member function):
- if the object passeed to the member function is an lvalue, then the
coroutine captures a reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #18 from Avi Kivity ---
The work-around works if initial_suspend() returns suspend_never or similar. If
the lambda is suspended before execution, the reference may dangle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #20 from Avi Kivity ---
My coroutines do return suspend_never from initial_suspend(); so thanks for the
workaround, I'll use it until we have a better fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #22 from Avi Kivity ---
Certainly, closing as invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Avi Kivity changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #17 from Avi Kivity ---
Is that the test were a lambda coroutine is called from future::then()? In that
case it's a real use-after-free.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #22 from Avi Kivity ---
@Iain: if you can publish your patches somewhere we can test them with our
codebase and report.
(if you can publish them on releases/gcc-10 that's even better).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95455
--- Comment #2 from Avi Kivity ---
Appears to be invalid. Clang rejects it even after some massaging (lambda in
unevaluated context).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95455
--- Comment #3 from Avi Kivity ---
Here's a valid version (which gcc accepts):
void f() {
int foo = 4;
auto lambda = [bar = foo] {};
static_assert(requires (decltype(lambda) x) {
x;
});
}
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Created attachment 48651
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48651&action=edit
test case
If a coroutine_traits specialization fails, and if the cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #25 from Avi Kivity ---
Requesting a backport to gcc 10. We're hitting this even when not called in a
loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95895
Avi Kivity changed:
What|Removed |Added
CC||a...@cloudius-systems.com
--- Comment #6
++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
The following example compiles with gcc and fails with clang. I believe clang
is correct but can't prove it.
=== begin example =
#include
void foo() {
std::r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97120
--- Comment #2 from Avi Kivity ---
This makes sense, according to my very limited ability to understand the
standard. I reflected it to the clang bug here:
https://bugs.llvm.org/show_bug.cgi?id=47509.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722
Avi Kivity changed:
What|Removed |Added
CC||a...@cloudius-systems.com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93502
--- Comment #6 from Avi Kivity ---
Even if match_results stores a copy of the matching string, it would be stored
on the heap and only pointers would be stored on the stack. So the stack
overflow comes from recursion, not because of the delegatio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718
Avi Kivity changed:
What|Removed |Added
CC||a...@cloudius-systems.com
--- Comment #1
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Consider the code:
[[gnu::cold]]
int slow_path();
int f()
{
asm goto ("" : : : : cold);
return 1;
cold:
return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59639
--- Comment #2 from Avi Kivity ---
(In reply to Andrew Pinski from comment #1)
> The option you want is -freorder-blocks-and-partition but it only does
> something when there are real profiling info (aka
> -fprofile-generate/-fprofile-use).
No.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #14 from Avi Kivity ---
This is a common missed optimization. A container is cleared as part of
destruction, but the stores are not eliminated, even though they are illegal.
If you want to access members of an object, don't destroy i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #16 from Avi Kivity ---
Sorry, of course the stores are not illegal.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Consider
=== example starts ===
enum class E { a, b, c, d, e, f, g, h, i, j };
bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85516
--- Comment #2 from Avi Kivity ---
Interesting. Still missing optimizations - v cannot be larger than 9 (UB), and
bt is faster than mov+shift+and.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82380
Avi Kivity changed:
What|Removed |Added
CC||a...@cloudius-systems.com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940
--- Comment #4 from Avi Kivity ---
Since constexpr constructors do send the variable into the .data (or .tls)
section, perhaps gcc can attempt to evaluate the initializer as if it (and any
functions it calls) was marked constexpr. If it fails it
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
The code
enum xx { x1 = 1, x2 = 2, x3 = 3, x4, x5, x6 };
unsigned char f(xx x) {
switch (x
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
A saveall function attribute, with the meaning that the function saves all
registers and therefore its caller does not need to save them, can be useful.
Two use cases:
- currently, debugging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84809
--- Comment #1 from Avi Kivity ---
I think no_caller_saved_registers is very close to what I want, except for
"Since GCC doesn't preserve MPX, SSE, MMX nor x87 states, the GCC option
'-mgeneral-regs-only' should be used to compile functions with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #8 from Avi Kivity ---
Still unfixed in trunk.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Created attachment 38497
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38497&action=edit
Reproducer
gcc (GCC) 6.1.1 201605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71147
Avi Kivity changed:
What|Removed |Added
Attachment #38497|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091
--- Comment #2 from Avi Kivity ---
Another instance:
unsigned long clear(unsigned long x) {
return x & ~ ((unsigned long)1 << 63);
}
This compiles to movabs+andq, while it could compile to a single btr
instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091
--- Comment #6 from Avi Kivity ---
I believe bts/btc/btr can do more - they also calculate the word offset when
addressing memory, see first comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091
--- Comment #9 from Avi Kivity ---
I believe the comment is wrong. Here's what the manual says:
"This instruction can be used with a LOCK prefix to allow the instruction to be
executed atomically."
Implying that without the LOCK prefix, it is n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #3 from Avi Kivity ---
A gentle ping, in the unlikely case that this bug was forgotten.
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
From std::experimental::optional:
void
swap(optional& __other)
noexcept(is_nothrow_move_constructible<_Tp>()
&& noe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80493
--- Comment #3 from Avi Kivity ---
Please consider a backport to older branches (5, 6, 7).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #7 from Avi Kivity ---
Hitting something similar-looking on Fedora 26's gcc 7.1.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #10 from Avi Kivity ---
Oh, and a binary that triggers it is build/release/tests/view_schema_test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #9 from Avi Kivity ---
(In reply to Martin Liška from comment #8)
> (In reply to Avi Kivity from comment #7)
> > Hitting something similar-looking on Fedora 26's gcc 7.1.1.
>
> Can you please provide a test-case so that I can verify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #13 from Avi Kivity ---
Output:
$ build/debug/tests/view_schema_test_g -- --smp 1 -m 1G
WARNING: debug mode. Not for benchmarking or production
Running 60 test cases...
WARN 2017-07-10 11:41:14,955 seastar - Seastar compiled with de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #15 from Avi Kivity ---
Unfortunately, backporting your patch is not enough; it depends on another, and
backporting the dependency generates many conflicts.
There is now a ./install-dependencies.sh in the scylla repositories, so to g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #17 from Avi Kivity ---
(In reply to Martin Liška from comment #16)
>
> Unfortunately I don't have any Fedora system to test it. Do you have any
> experience using Docker? This can be good candidate to reproduce that?
If you run the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #19 from Avi Kivity ---
(In reply to Martin Liška from comment #18)
> I can confirm I can reproduce it. Now with just AddressSanitizer I see:
>
> ==5488==ERROR: AddressSanitizer: unknown-crash on address 0x7fa04c0092e0 at
> pc 0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #20 from Avi Kivity ---
btw, you can try pulling from https://github.com/avikivity/scylla/tree/2546; it
has some fixes (specifically
https://github.com/avikivity/scylla/commit/408d540eda30b557ecc0ab07ac3d39b617b37c4c)
that fixed failu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #26 from Avi Kivity ---
Thanks a lot for handling this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #28 from Avi Kivity ---
It's a combination of several things:
1. We use antlr to generate a parser. The generated code allocates many local
variables in the same function
2. use-after-scope disabled -fstack-reuse=all
3. ASAN is quite
ormal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Consider the following code
=== begin code ===
#include
using namespace std::experimental;
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78713
--- Comment #2 from Avi Kivity ---
I think the middle-end knows it is safe to write to *this, because this is
happening in a constructor, so all of the object's memory is known clobbered.
Similarly, if the assignment operator is written as
o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78713
--- Comment #4 from Avi Kivity ---
This bug has a cousin https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 where
the optimizer doesn't eliminate a store to an object that is about to be
destroyed. While for sure it is easier to implement in the
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
If I write
extern thread_local std::atomic foo;
gcc will emit guard variables everywhere to ensure it is properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #46 from Avi Kivity ---
Hopefully, the fix can be propagated to gdb's demangler soon.
: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Processing some complex code involving lambdas in gnu++1y mode, the compiler
segfaults:
$ g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 fail.i
In file included from ./core/seastar.hh:26:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433
--- Comment #1 from Avi Kivity ---
Created attachment 35038
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35038&action=edit
Preprocessed source triggering ICE (bzip2'ed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433
--- Comment #3 from Avi Kivity ---
Ok, will check with trunk.
On Sun, Mar 15, 2015 at 9:48 PM, maltsevm at gmail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433
>
> Mikhail Maltsev changed:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433
--- Comment #4 from Avi Kivity ---
I see the same crash on trunk, only now I get a stack trace:
0xca999f crash_signal
../../gcc/toplev.c:383
0x7f0b74 contains_struct_check
../../gcc/tree.h:2959
0x7f0b74 lambda_expr_this_capture(tree_node
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
lto1: internal compiler error: Segmentation fault
0xa283bf crash_signal
../../gcc/toplev.c:383
0x111c7b0 htab_hash_string
../../libiberty/hashtab.c:839
0x6d06bf external_ref_hasher::hash(external_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47361
Avi Kivity changed:
What|Removed |Added
CC||a...@cloudius-systems.com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
--- Comment #25 from Avi Kivity ---
It's not a latent bug for me:
lto1: internal compiler error: Segmentation fault
0xa2f1af crash_signal
../../gcc/toplev.c:383
0x1129f20 htab_hash_string
../../libiberty/hashtab.c:839
0x6d264f external_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
--- Comment #27 from Avi Kivity ---
Patch fixes the problem for me (though the linker still fails)
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Too much template magic causes gcc 5.1 to reject the following valid code:
#include
#include
#include
using T1 = int;
using T2 = std::vector;
bool cmp1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
--- Comment #5 from Avi Kivity ---
That's clang + libstdc++-5.1, so if the problem is in libstdc++, it's the same
bug.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
As a complement to __thread and thread_local, add __fiber storage class which
is local storage for user-level threads. User-level threads is a common
technique in high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
--- Comment #10 from Avi Kivity ---
Any chance that the fix can be committed? gcc 5 is useless for me without
this.
: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Created attachment 36715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36715&action=edit
Test case (derived from ScyllaDB; AGPL)
g++6 (GCC) 6.0.0 20151113 (experimental)
Copyright (C) 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Avi Kivity changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
After a destructor is run, access to the object is forbidden; the object is
turned into a pile of bytes. Yet the generated code for:
struct X {
int i;
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #3 from Avi Kivity ---
I observed this with non-trivial destructors as well.
In fact, something like:
X::~X() { i = 3; }
also emits a store.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #5 from Avi Kivity ---
Ah, I see that non-trivial destructors were fixed in gcc 4.9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091
Avi Kivity changed:
What|Removed |Added
CC||a...@cloudius-systems.com
--- Comment #1
++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
The code
struct A {
virtual ~A() {}
};
struct B final : A {
virtual ~B() {}
};
B* dc(A* a) {
return dynamic_cast(a);
}
compiles into the following assembly, which contains a call
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
A random change (adding a new virtual function) in a program produced this. I
realize this is not sufficient to reproduce, but maybe this can jog someone's
memory. If not, I can try to minimize.
(gdb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #2 from Avi Kivity ---
I managed to narrow it down to 400 lines (before preprocessing), strangely in
one file. Now, practically anything I touch turns the segfault into link
errors.
Is this useful? I could share it privately.
1 - 100 of 107 matches
Mail list logo
