https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112339
--- Comment #3 from Niall Douglas ---
Thanks for the patch. I've sent it on to the originator of the bug, if they
confirm it fixes their issue to me I'll let you know.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
This, if compiled with trunk GCC or any recent major version of GCC:
```
[[clang::no_sanitize("bounds")]] void foo()
{
}
```
... with options `-Wno-attrib
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
I know this will be a minor enhancement request, however I would like this to
produce more useful diagnostics:
template concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #10 from Niall Douglas ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Wilco from comment #8)
> > Yes that sounds like a reasonable approach.
>
> I don't think so. Not all variables on which __atomic_* intrinsics are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #7 from Niall Douglas ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Niall Douglas from comment #3)
> > You may be interested in reading https://reviews.llvm.org/D110069. It wanted
> > to have LLVM generate a 128 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #3 from Niall Douglas ---
> AMD has guaranteed it, but there is still VIA and Zhaoxin and while we have
> some statement from the latter, I'm not sure it is enough and we don't have
> anything from VIA. See PR104688 for details.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
Related:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
- https://gcc.gnu.org/bugzilla/show_bug.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101133
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
--- Comment #8 from Niall Douglas ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Niall Douglas from comment #0)
> > I would assume that the ABI ship has sailed, as usual, but if libstdc++'s
> > span could instead have the layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #35 from Niall Douglas ---
(In reply to Jonathan Wakely from comment #34)
> > Perhaps I ought to open a separate issue here, as my specific problem is
> > that std::atomic<__int128>::compare_exchange_weak() is not using cmpxchg16b?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #33 from Niall Douglas ---
(In reply to Andrew Pinski from comment #31)
>
> Again the problem is stuff like:
> static const _Atomic __int128_t t = 2000;
>
> __int128_t g(void)
> {
> return t;
> }
>
> DOES NOT WORK if you use CAS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
--- Comment #6 from Niall Douglas ---
Cool, thanks. I believe that all three major STLs now implement struct iovec
compatibility with span. That's a nice win.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96485
--- Comment #3 from Niall Douglas ---
(In reply to Jakub Jelinek from comment #2)
> [[gnu::no_sanitize_undefined]] instead of the GNU __attribute__ is accepted,
> but as the C++ specification requires it applies to the type not the
> declaration
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
As the repro at https://godbolt.org/z/Gvx75e shows, the following code compiled
fine in GCCs up to and including GCC 8.3:
```
void test()
{
[]()
#if 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
--- Comment #2 from Niall Douglas ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Niall Douglas from comment #0)
> > I would assume that the ABI ship has sailed, as usual
>
> Nope.
Ok, so if you did want to reuse span as any fu
++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
I would assume that the ABI ship has sailed, as usual, but if libstdc++'s
span could instead have the layout:
{
T *p;
size_t l;
}
... then a span would be layout-compatible
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
Reported originally at https://github.com/ned14/outcome/issues/225
Works on GCC 9.3 with -std=c++2a -O3 -DNDEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95001
--- Comment #5 from Niall Douglas ---
Just to clarify what I'm asking for:
Calling a [[noreturn]] function ought to have the same effects on codegen as:
```
[[noreturn]] void theend();
...
if(a)
{
theend();
__builtin_unreachable();
}
```
R
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
Consider the codegen from https://godbolt.org/z/xhmBrL:
```
#include
#include
#include
#include
void sum(uint32_t
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
8.3: https://wandbox.org/permlink/2pmM3pg8Fygh5Gi5
8.2: https://wandbox.org/permlink/RIobfNd409w0uQRT
8.1: https://wandbox.org/permlink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90285
--- Comment #4 from Niall Douglas ---
> "non-aliasing reinterpret cast"? Whatever that means.
>
> // Reinterpret bytes by copying (not UB for TC types)
> memmove(temp, &v, sizeof(T));
>
> // Put reinterpreted bytes back. This avoid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90285
--- Comment #2 from Niall Douglas ---
To put this into a wider context, the detach and attach cast proposal passed
muster earlier this week at the WG14 meeting that I am currently sitting in.
The current C2x draft allows this implementation of "u
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
The following code produces poor optimised codegen on trunk GCC at the time of
writing (2019-04-29):
// Reinterprets a T into its array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60555
--- Comment #12 from Niall Douglas ---
Excellent. Thanks guys!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60555
--- Comment #9 from Niall Douglas ---
Transferring over from #86750:
--- cut ---
Got bitten by this yet again today in Boost.Outcome and the P1031 LLFIO
reference implementation, so despite it being already reported at #60555, I'd
like to get t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60555
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
Got bitten by this yet again today in Boost.Outcome and the P1031 LLFIO
reference implementation, so despite it being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
Niall Douglas changed:
What|Removed |Added
Summary|Codegen regression when |Codegen is poor when
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #1 from Niall Douglas ---
Quoting from bug 86573 regarding this bug:
> The real difference in -std=c++17 is _GLIBCXX_EXTERN_TEMPLATE. With
> -std=c++14, we have many extern templates which the compiler almost never
> inlines. This le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
--- Comment #8 from Niall Douglas ---
Added revised bug to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
If compiled as C++ 14:
#include
inline size_t calc(std::string a, std::string b)
{
return a.size() + b.size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
--- Comment #5 from Niall Douglas ---
Thanks for the rapid feedback. Very very interesting that -std=c++17 causes
spew for the copy case https://godbolt.org/g/Xnrgg2, yet -std=c++14 or
-std=c++11 does not.
Is the -std=c++17 case worth opening a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
#include
inline size_t calc(std::string a, std::string b)
{
return a.size() + b.size();
}
int main()
{
std::string a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79118
--- Comment #8 from Niall Douglas ---
(In reply to Marek Polacek from comment #7)
> I'm giving up; there's just too much C++.
Thanks for looking into it. You should know that the above code works without
issue on clang and VS2017 (with C++ 14 co
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
Created attachment 40531
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40531&action=edit
preprocessed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #10 from Niall Douglas
2012-06-18 10:01:19 UTC ---
(In reply to comment #9)
> I'm ambivalent.
Ok then. Well, thanks for all your help and very useful input. As we have
something now which is very close to a code patch, I suppose we l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
Niall Douglas changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #8 from Niall Dougl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #6 from Niall Douglas 2012-06-15
16:53:01 UTC ---
(In reply to comment #5)
> > They don't have any ABI impact that we know of at the present time in this
> > present generation of GCCs. As a debug aid that's likely to be there from
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #4 from Niall Douglas 2012-06-15
15:23:21 UTC ---
(In reply to comment #2)
> you can use -frecord-gcc-switches to detect mixed objects in linked library.
Indeed, one could grok the .text section this adds, parse the command line and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #3 from Niall Douglas 2012-06-15
15:13:37 UTC ---
(In reply to comment #1)
> There's no point differentiating the gnu variants, they don't have any ABI
> impact.
They don't have any ABI impact that we know of at the present time in t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #25 from Niall Douglas
2012-06-14 16:37:15 UTC ---
(In reply to comment #24)
> (In reply to comment #22)
> > I can submit a wishlist issue for GCC for the above if it doesn't already
> > exist?
>
> Sure.
Added as #53673.
Niall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
Bug #: 53673
Summary: Add magic weak symbol to indicate C++ standard setting
(C++03, C++11 etc) to help debug ABI problems
Classification: Unclassified
Product: gcc
Version: unkn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #22 from Niall Douglas
2012-06-14 16:16:19 UTC ---
(In reply to comment #20)
> That wouldn't help if you built one object with -std=c++11 and another with
> -std=c++98 and linked them both into the same .so, you'd have the symbol, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #18 from Niall Douglas
2012-06-14 15:15:30 UTC ---
(In reply to comment #17)
> (In reply to comment #16)
> > I think I built it correctly with std=c++11, but is there a way to verify
> > this
> > properly in the built library?
>
> c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #15 from Niall Douglas
2012-06-14 13:24:58 UTC ---
Agreed, but it is highly unlikely to happen anytime soon unless a new sponsor
turns up. BPL needs a fair bit of post-bitrot work as it is.
Niall
(In reply to comment #12)
> Maybe so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #11 from Niall Douglas
2012-06-14 11:49:01 UTC ---
(In reply to comment #9)
> maybe related: https://svn.boost.org/trac/boost/ticket/6919
> Had similar crash issue. Though in my case (which may well be different from
> the OP) rebuild
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #5 from Niall Douglas 2012-05-22
19:51:04 UTC ---
Link to the c++-sig discussion thread:
http://mail.python.org/pipermail/cplusplus-sig/2012-May/016581.html
For the purposes of assigning tags, this bug is C++11 mode only, GCC 4.7.x
o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod
--- Comment #3 from s_gccbugzilla at nedprod dot com 2008-06-08 17:19
---
Created an attachment (id=15733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15733&action=view)
Failing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
--- Comment #2 from s_gccbugzilla at nedprod dot com 2008-06-08 17:19
---
This problem actually seems to be one of subclassing: child class rvalue
constructors invoke base class lvalue constructors!!!
I have attached an example. As is, it compiles and works. If however you throw
a
--- Comment #1 from s_gccbugzilla at nedprod dot com 2008-06-08 17:07
---
Created an attachment (id=15732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15732&action=view)
Test Case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s_gccbugzilla at nedprod dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
: Non-ISO template qualifiers
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s_gccbugzilla at nedprod dot com
: Non-ISO template qualifiers
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s_gccbugzilla at nedprod dot com
--- Additional Comments From s_gccbugzilla at nedprod dot com 2005-09-01
10:42 ---
Vladimir Prus Wrote:
> It's is mess, but I hope that we don't just agree on *that*. The situation
> is that the whole -fvisibility thing does not work reliably for C++
> dynamic librar
--
What|Removed |Added
Component|c++ |c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18479
ror
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s_gccbugzilla at nedprod dot com
CC: gcc-bugs at gcc dot g
59 matches
Mail list logo
