https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #5 from Bernd Edlinger ---
Rainer,
I would be happy if you could give this patch a try.
Thanks
Bernd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #4 from Bernd Edlinger ---
Created attachment 50778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50778&action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #3 from Bernd Edlinger ---
Okay, after some debugging I see the problem.
Usually thunks are emitted from ymtab-thunks.cc:
cfun->is_thunk = 1;
insn_locations_init ();
set_curr_insn_location (DECL_SOURCE_LOCATION (t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100484
Bug ID: 100484
Summary: [12 regression] Test case gcc.dg/sso-9.c fails after
r12-622
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100482
--- Comment #1 from Jeremy R. ---
This appears to be valid for function return types as well but the compiler
does error when decltype is used in a function parameter
namespace std{}
int A(int a) { // fine
decltype(std) b = a;
return b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Bug ID: 100483
Summary: Extend -fno-semantic-interposition to global variables
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100482
Bug ID: 100482
Summary: namespaces as int in decltype expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100481
Bug ID: 100481
Summary: namespaces as int in decltype expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100249
--- Comment #8 from 康桓瑋 ---
(In reply to Patrick Palka from comment #6)
> > Maybe this can help:
> >
> > auto&& __proj_val = std::__invoke(__proj, __val);
> > if (std::__invoke(__comp,
> > std::forward(__proj_val), std::__invoke(__proj,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
abebeos at lazaridis dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
--- Comment #4 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #3)
> Also, the operator->() simply uses operator& instead of std::__addressof.
>
> https://godbolt.org/z/zfGnEoePG
Another issue is that the has_value() of this specialization will alw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
--- Comment #3 from 康桓瑋 ---
Also, the operator->() simply uses operator& instead of std::__addressof.
https://godbolt.org/z/zfGnEoePG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #58 from abebeos at lazaridis dot com ---
Well, now I'm really really curious.
Does the gcc project have at least some(!) liberal qualities, or will
IT-fascism win?
Follow-up:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
Bug ID: 100480
Summary: Where to file complaints re project-maintainers?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479
Bug ID: 100479
Summary: range adaptors handle cached iterators incorrectly
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #16 from CVS Commits ---
The master branch has been updated by Andrew Stubbs :
https://gcc.gnu.org/g:07d7d37d1a33efb04f1262e56f4b82d6e1089e75
commit r12-632-g07d7d37d1a33efb04f1262e56f4b82d6e1089e75
Author: Andrew Stubbs
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100478
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #7 from Steve Kargl ---
On Fri, May 07, 2021 at 09:12:15PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> There seems to be something fishy with default initialization of function
> resu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100478
Bug ID: 100478
Summary: Type Pointer Segfaults
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #6 from anlauf at gcc dot gnu.org ---
There seems to be something fishy with default initialization of function
results of derived types. Looking at the attached code, I guessed the
following potential reproducer:
program p
implic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #5 from kargl at gcc dot gnu.org ---
David,
On amd64-*-freebsd, I see
% gfcx -o z -O2 -fcheck=all allocate_error.f95
% ./z
Sample 10. Eigenvalue from matrix powers.
Iterationeigenvalue approximation
0 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #5 from Iain Sandoe ---
(In reply to Jason Merrill from comment #3)
> (In reply to Jason Merrill from comment #2)
> > (In reply to Iain Sandoe from comment #1)
> > > I am by no means an expert at reading standardese - and it might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #4 from Iain Sandoe ---
great, that does simplify things - and means that a useful error can be
diagnosed from a mismatched type between g_r_o/g_r_o_o_a_f and the coroutine
ramp return value.
The statement about phasing of the calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #3 from Jason Merrill ---
(In reply to Jason Merrill from comment #2)
> (In reply to Iain Sandoe from comment #1)
> > I am by no means an expert at reading standardese - and it might be that I'm
> > not alone, (library writers might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #2 from Jason Merrill ---
(In reply to Iain Sandoe from comment #1)
> I am by no means an expert at reading standardese - and it might be that I'm
> not alone, (library writers might have made the same assumption) but it
> seems to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
H.J. Lu changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
--- Comment #4 from Iain Sandoe ---
for the record the patch in comment #3 allowed bootstrap to succeed on Darwin12
with clang 3.4-based Xcode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #1 from Iain Sandoe ---
I am by no means an expert at reading standardese - and it might be that I'm
not alone, (library writers might have made the same assumption) but it seems
to me that:
http://eel.is/c++draft/dcl.fct.def.corout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #13 from Jakub Jelinek ---
The error is clear, the header you want to include doesn't exist, which is the
case.
Usually people use PCH as an optimization, have the header normally in search
path and have there also the precompiled ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #12 from Marco Trevisan ---
Well, I see...
At least the error should be a bit clearer though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Marco Trevisan changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87839
--- Comment #5 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:3488242b9a949ebc55b4a857380f94506f90ff76
commit r8-10959-g3488242b9a949ebc55b4a857380f94506f90ff76
Author: Jakub Jelinek
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
Bug ID: 100477
Summary: Bogus -Wstringop-overflow warning on memset
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
--- Comment #2 from 康桓瑋 ---
Reduced example:
#include
struct S {
S() = default;
S(int, int) {}
S(std::initializer_list) = delete;
};
std::ranges::single_view single(std::in_place, 0, 0);
https://godbolt.org/z/d1bE8sPdd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2021-05-07
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #8 from Marco Trevisan ---
It's also relevant to say that just using
main.c:
#include "gjs_pch.h"
int main(int argc, char**argv)
{
std::string s = "Hi";
return 0;
}
fails with:
❯ g++ -I _build main.c -o main -include string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
--- Comment #6 from Daniel Starke ---
Thank you for the suggestion, however, I am not involved in the mingw-w64
project. Furthermore, the fact that this regression remains against all
versions of mingw-w64 known to date does not change.
It is al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e2979f8687f590461bef9f87bd997390af67312e
commit r8-10958-ge2979f8687f590461bef9f87bd997390af67312e
Author: Jakub Jelinek
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ec910efa1f70e3903091b23e80c5c554b4db6c9b
commit r9-9521-gec910efa1f70e3903091b23e80c5c554b4db6c9b
Author: Jakub Jelinek
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d7c8e6261532e7b2d16221becd5db11ded03e059
commit r10-9810-gd7c8e6261532e7b2d16221becd5db11ded03e059
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8482ed658ca77bfd7fc119cd62afd5b70a024500
commit r11-8371-g8482ed658ca77bfd7fc119cd62afd5b70a024500
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-* |powerpc*
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #3 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935
--- Comment #1 from Nick Clifton ---
Created attachment 50777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50777&action=edit
Proposed patch
Here is a possible patch for the problem, adding a recursion limit to the
demangle_path() functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
Bug ID: 100476
Summary: coroutines: questionable handling of void
get_return_object
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79333
--- Comment #5 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:601191b2a48cb8f4657bb2fa2270a7fde9d52e9c
commit r12-617-g601191b2a48cb8f4657bb2fa2270a7fde9d52e9c
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
Bug ID: 100475
Summary: semiregular-box's constructor uses wrong
list-initialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:170c850e4bd46745e2a5130b5eb09f9fceb98416
commit r12-616-g170c850e4bd46745e2a5130b5eb09f9fceb98416
Author: Jakub Jelinek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
--- Comment #6 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:5795ec0edc30e077a9900cf3ca0a04ad8ac5ac97
commit r12-615-g5795ec0edc30e077a9900cf3ca0a04ad8ac5ac97
Author: Uros Bizjak
Date: Fri May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93320
vopl at bk dot ru changed:
What|Removed |Added
CC||vopl at bk dot ru
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #7 from Marco Trevisan ---
(In reply to Marco Trevisan from comment #6)
> # Works
> g++ -I _build main.c -o main -include string -include gjs_pch.h
Ouch, I forgot to delete an include after pasting
# Works
g++ -I _build main.c -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #6 from Marco Trevisan ---
(In reply to Jakub Jelinek from comment #5)
> As documented - see
> https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html - PCH is only
> tried if no C token is seen before the #include directive (com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465
--- Comment #5 from Jonathan Wakely ---
As a workaround the library could use __str.append or __str.operator+=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474
Bug ID: 100474
Summary: ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #4 from David.Smith at lmu dot edu ---
> Thanks for reduce this to a testcase. I don't see it attached
> to this email or in bugzilla. gcc.gno.org may have stripped
> the attachment (for some dumb reason). Feel free to send the
>t
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
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473
--- Comment #1 from Andreas Schwab ---
$ git grep 'optimize >= 2'
gcc/ChangeLog-2008: 100 for optimize >= 2.
gcc/ChangeLog-2010: only conditionally on optimize >= 2.
gcc/ada/gcc-interface/trans.c:&& optimize >= 2
gcc/c-family/c-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465
--- Comment #4 from Jonathan Wakely ---
Reduced:
namespace N
{
template
struct string_view
{
using char_type = C;
};
template
struct string
{
void operator+=(const string&);
template
void operator+=(const T&);
};
template
void f()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #4 from Marco Trevisan ---
(In reply to Marco Trevisan from comment #3)
> Created attachment 50775 [details]
> strace.log
>
> This is crazy, as even according to strace the file isn't there...
>
> But it is and it's valid.
> ❯ ls -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #8 from Steven Sun ---
under c++17
Step 4 needs `types_match == 1` [at 1] but, its value is zero, which is caused
by `function_requirements_equivalent_p` [at 3] returns 0 [at 2] .
[1]
https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-05-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #3 from Marco Trevisan ---
Created attachment 50775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50775&action=edit
strace.log
This is crazy, as even according to strace the file isn't there...
But it is and it's valid.
❯ ls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465
--- Comment #2 from Jonathan Wakely ---
Maybe another case of PR 51577 but I haven't looked into it yet.
I will say that a templated operator in the global namespace with absolutely no
constraints to limit what it accepts is a very bad idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808
--- Comment #14 from CVS Commits ---
The releases/gcc-8 branch has been updated by Christophe Lyon
:
https://gcc.gnu.org/g:bcc4f85667c88f9be098f2671b01831d4b8d9f7c
commit r8-10957-gbcc4f85667c88f9be098f2671b01831d4b8d9f7c
Author: Kyrylo Tkachov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808
--- Comment #13 from CVS Commits ---
The releases/gcc-9 branch has been updated by Christophe Lyon
:
https://gcc.gnu.org/g:c9c429cf986c885cf90259866186849de44e1e1f
commit r9-9520-gc9c429cf986c885cf90259866186849de44e1e1f
Author: Kyrylo Tkachov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #34 from Jonathan Wakely ---
(In reply to Niall Douglas from comment #33)
> Re: your original point, I cannot say anything about _Atomic. However, for
> std::atomic<__int128>, as __int128 is not an integral type it seems
That depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #2 from Bernd Edlinger ---
> so it is not possible to debug those functions
Aehm, i meant of course it is _now_ possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473
Bug ID: 100473
Summary: O2 vs optimization flags
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
Bernd Edlinger changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464
--- Comment #9 from Chengnian Sun ---
Thanks for the tip. We will use that flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464
--- Comment #8 from Jakub Jelinek ---
gcc has the -fcompare-debug option, which compiles twice, once with -g and once
with -g -gtoggle and compares result, anything that fails with that option with
an error about debug vs. non-debug differences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #16 from Iain Sandoe ---
(In reply to Erik Schnetter from comment #15)
> One thing that e.g. changed is that there is now a newer version of Apple
> Clang.
XCode 12.5 is broken, with compare-debug error : see PR100340 (already repo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464
--- Comment #7 from Chengnian Sun ---
(In reply to Jakub Jelinek from comment #6)
> Yes.
Great. Thanks. We have a bunch of such test programs. I will report them
shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464
--- Comment #6 from Jakub Jelinek ---
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464
--- Comment #5 from Chengnian Sun ---
I have a question. If the test program has undefined behaviors, is GCC still
expected to emit the same binary code for compilation with and without debug
symbols?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #7 from Steven Sun ---
After digging for two days, I think I may know what's happening inside.
Under std=c++20 and my code in comment 1, the flow when parsing a full function
specialization would be
1. Found a full specialization o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471
--- Comment #2 from Tom Vander Aa ---
Thanks Jakub. Let me know when I can do something.
-Wno-pedantic,
Tom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420
Patrick Palka changed:
What|Removed |Added
CC||frankhb1989 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100472
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100472
Bug ID: 100472
Summary: [C++17] Wrong template non-type argument handling on
function reference to noexcept functions
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
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=100347
--- Comment #15 from Erik Schnetter ---
When I try to rebuild GCC 10.3 or 10.2, they end up having the same problem.
Also, when I enable bootstrapping, bootstrapping fails with differences in many
files. Given that this used to work on a previou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
--- Comment #5 from H.J. Lu ---
(In reply to Daniel Starke from comment #4)
> Created attachment 50772 [details]
> rdtsc.c
>
> Please find attached the mingw-w64 file.
Please change
#if !__has_builtin(__rdtsc)
to
#if !__has_builtin(__rdtsc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100304
--- Comment #4 from Zdenek Sojka ---
I can't reproduce this anymore on r12-581 ; but it still reproduces for me on
the 11-branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441
Alex Coplan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471
Bug ID: 100471
Summary: #pragma omp taskloop with
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100470
Bug ID: 100470
Summary: std::is_nothrow_move_constructible incorrect behavior
for explicitly defaulted members
Product: gcc
Version: 11.1.0
URL: https://godbolt.org/z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100468
--- Comment #5 from Jakub Jelinek ---
Though it is static and what you're talking about is making automatic into
static. So guess we would need automatic temporary with something like { 1, 2,
3 } initializer and have reference bind to that temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100468
--- Comment #4 from Jakub Jelinek ---
I meant something like
struct S { constexpr S () : s (0), t (0), u(0) {} constexpr S (int x, int y,
int z) : s (x), t (y), u (z) {} int s, t, u; };
constexpr S bar () { return S (0, 1, 2); }
bool
foo (void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100469
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-05-07
Target Milestone|---
1 - 100 of 136 matches
Mail list logo
