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=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
--- 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=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=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=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=100461
H.J. Lu changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|WAITING
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=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 #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 #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=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=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=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 #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
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
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=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=100479
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=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
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
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=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=100480
abebeos at lazaridis dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resol
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=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=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=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
--- 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=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=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=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 #5 from Bernd Edlinger ---
Rainer,
I would be happy if you could give this patch a try.
Thanks
Bernd.
101 - 136 of 136 matches
Mail list logo
