: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rianquinn at gmail dot com
Target Milestone: ---
I think this is a bug, but I am dealing with allocators so I am not 100% sure
here. I have created a really simple allocator for testing. The allocators are
NOT equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189
--- Comment #4 from Rian Quinn ---
Nope, I think that is the root of the issue. Where exactly does the spec
state that as this is the first I have heard of this.
Thanks a ton,
- Rian
On Mon, Jun 18, 2018 at 6:31 AM, redi at gcc dot gnu.org <
gc
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rianquinn at gmail dot com
Target Milestone: ---
Currently bounds checks inside Microsoft's GSL are causing a strict overflow
warning to trigger that appears to be invalid (i.e. the bounds checks should be
fine). The issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78130
--- Comment #2 from Rian Quinn ---
The output:
Using built-in specs.
COLLECT_GCC=/usr/bin/c++
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78130
--- Comment #3 from Rian Quinn ---
Created attachment 39908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39908&action=edit
ii and s file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78130
--- Comment #6 from Rian Quinn ---
Correct me if I'm wrong, but it would appear that this is indeed an bug with
GCC (based on current activity). If that is the case, what would be your
recommendations on how to resolve this issue in the GSL. At t
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rianquinn at gmail dot com
Target Milestone: ---
Using the TARGET=elf-x86_64 compiler (OS development), I get a strange crash
with C++. The class definition is as follows:
class Blah1
{
public:
Blah1() {}
virtual ~Blah1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68738
--- Comment #2 from Rian Quinn ---
Yeah I'm am pretty sure it is specific to TARGET=elf-x86_64 (i.e. no OS
specified). When I ran the same test on Ubuntu's native GCC it ran fine.
objdump showed pretty different assembly for the Ubuntu case,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68738
--- Comment #3 from Rian Quinn ---
Just for completeness, here is the exact code out objdump output:
class Blah1
{
public:
Blah1() {}
virtual ~Blah1() {}
virtual int foo() { return 0; }
};
class Blah2 : public Blah1
{
public:
B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68738
--- Comment #4 from Rian Quinn ---
To expand on this issue, any attempt to use the following pattern will result
in instability:
some_type *p = &var;
*p or p-> // Crash
A couple of situations that I have seen include:
- allocate memory in g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68738
Rian Quinn changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rianquinn at gmail dot com
Target Milestone: ---
I think there is an issue with GCC 6.1, -mrealignstack and expressions. We use
-mrealignstack because without it, "-O3" crashes when we set the arch to
sandybridge (as SSE instru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71978
--- Comment #2 from Rian Quinn ---
We throw here:
https://github.com/rianquinn/hypervisor/blob/expression_support/bfvmm/src/vmcs/src/vmcs_intel_x64.cpp#L514
The following is were the issue is (meaning the unwinder unwinds until it hits
this func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71978
--- Comment #4 from Rian Quinn ---
Is this it? Never done that before:
https://github.com/rianquinn/hypervisor/tree/expression_support/tmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71978
Rian Quinn changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
15 matches
Mail list logo
