--
Summary: 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
--
Summary: 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
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 gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
What|Removed |Added
Component|c++ |c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18479
--- 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 libraries which is rather
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
Niall Douglas s_gccbugzilla at nedprod dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #5 from Niall Douglas s_gccbugzilla at nedprod dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #11 from Niall Douglas s_gccbugzilla at nedprod dot com
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #15 from Niall Douglas s_gccbugzilla at nedprod dot com
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #18 from Niall Douglas s_gccbugzilla at nedprod dot com
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #22 from Niall Douglas s_gccbugzilla at nedprod dot com
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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #25 from Niall Douglas s_gccbugzilla at nedprod dot com
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #3 from Niall Douglas s_gccbugzilla at nedprod dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #4 from Niall Douglas s_gccbugzilla at nedprod dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #6 from Niall Douglas s_gccbugzilla at nedprod dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
Niall Douglas s_gccbugzilla at nedprod dot com changed:
What|Removed |Added
Component|c++ |libstdc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #10 from Niall Douglas s_gccbugzilla at nedprod dot com
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
: 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=15732action=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
--- 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=15733action=view)
Failing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
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
: 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=edit
preprocessed source
ned@K
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
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
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
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=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
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
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: ---
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
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, , sizeof(T));
>
> // Put reinterpreted bytes back. This avoids
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();
}
```
: 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
: 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
: 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
++
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
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
--- 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
--- 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
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
++
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=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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101133
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
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
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
59 matches
Mail list logo
