: 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
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: ---
Reported originally at https://github.com/ned14/outcome/issues/225
Works on GCC 9.3 with -std=c++2a -O3 -DNDEBUG
++
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
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
: 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=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod
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
--- 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 #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 #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 #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=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 #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
--- 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=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 #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
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 #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
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=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
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
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
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=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
: 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 #8 from Niall Douglas ---
Added revised bug to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
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=86590
Niall Douglas changed:
What|Removed |Added
Summary|Codegen regression when |Codegen is poor when
|
: 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=60555
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
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
--- Comment #12 from Niall Douglas ---
Excellent. Thanks guys!
--- 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
: 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
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
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
--- 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
--- 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 #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
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
--
What|Removed |Added
Component|c++ |c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18479
: 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
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=80878
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=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 #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?
>
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=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.
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 #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=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
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
++
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
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.
59 matches
Mail list logo
