https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
Richard Biener changed:
What|Removed |Added
Summary|[13 Regression] Missed |[13/14 Regression] Missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109550
Richard Biener changed:
What|Removed |Added
Blocks||24639
--- Comment #1 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:794ffdb0fb6312ce07af0bfc797bef9f4cff4c61
commit r14-59-g794ffdb0fb6312ce07af0bfc797bef9f4cff4c61
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524
--- Comment #13 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:865d712a9a20eed444ce61a0a0106534479bedf1
commit r13-7224-g865d712a9a20eed444ce61a0a0106534479bedf1
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8f81100115f68b37fb2723e987c14a3185d1f47d
commit r14-60-g8f81100115f68b37fb2723e987c14a3185d1f47d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109551
Bug ID: 109551
Summary: Show location where implicit instantiation first
required
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108840
--- Comment #4 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:136330bf637b50a4f10ace017a4316541386b9c0
commit r14-62-g136330bf637b50a4f10ace017a4316541386b9c0
Author: Kyrylo Tkachov
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108840
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109550
--- Comment #2 from Frank Heckenbach ---
It might be useful then to actually say to in the warning, e.g. "p[...] may be
used uninitialized". This might have saved me some debugging effort.
But actually, that's not all. This code still gives the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
--- Comment #8 from Costas Argyris ---
Not likely to be fixed, so if someone stumbles upon this and needs a
workaround, you need to override the default specs as in the example above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-04-19
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815
--- Comment #4 from Paul Thomas ---
Hi Martin,
This is fixed in 12-branch onwards.
I have not been able to find the fix - could you find it, please? I tried
comparing the diff in comment #2 with the current head but the differences in
the affe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:76f44fbfea1f11e53d4b7e83f0debd029c94a1b3
commit r14-64-g76f44fbfea1f11e53d4b7e83f0debd029c94a1b3
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ade0a1ee5c6707b950ba284adcfed0514866c12d
commit r14-65-gade0a1ee5c6707b950ba284adcfed0514866c12d
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103366
Paul Thomas changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237
--- Comment #15 from Richard Biener ---
Spread pretty evenly now. Everything >= 5%
tree CFG cleanup : 5.25 ( 8%) 0.00 ( 0%) 5.27 ( 7%)
89k ( 0%)
expand : 3.22 ( 5%) 0.18 ( 2%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815
Martin Liška changed:
What|Removed |Added
Summary|[10/11/12/13/14 Regression] |[10/11 Regression] Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548
Richard Biener changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109465
--- Comment #2 from CVS Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:6d7e0bcfa49e4ddc84dabe520bba8a023bc52692
commit r14-70-g6d7e0bcfa49e4ddc84dabe520bba8a023bc52692
Author: Xi Ruoyao
Date: Wed Apr 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109465
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
ed with "--enable-languages=fortran,c,c++
--enable-checking=all --disable-multilib --disable-bootstrap" and the version
is
"gcc version 14.0.0 20230419 (experimental) (GCC)".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Bug ID: 109553
Summary: Atomic operations vs const locations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Bug ID: 109554
Summary: Compiler generates incorrect code when the function
declared with returned parameterm but no 'return' in
its body
Product: gcc
Version: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a243ce2a52a6c62bc0d6be0b756a85dd9c1bceb7
commit r14-71-ga243ce2a52a6c62bc0d6be0b756a85dd9c1bceb7
Author: Richard Biener
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
--- Comment #7 from Richard Biener ---
Heuristic to not unroll loops with prefetches is missing. The aprefetch pass
could set ->unroll to 1 in the loop structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
--- Comment #2 from Xi Ruoyao ---
And it's clearly documented in https://gcc.gnu.org/gcc-8/changes.html:
Flowing off the end of a non-void function is considered unreachable and may be
subject to optimization on that basis. As a result of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> Btw, is there an API to std::move the (possibly) allocated string out of
> the std::string and make it available as C string pointer?
No, ownership always be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
Bug ID: 109555
Summary: suboptimal code for comparing strings with string
literals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
--- Comment #1 from Andrew Pinski ---
Note branchless might be worse. Anyways there is a duplicate of this bug
already. I think I filed it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
--- Comment #2 from niXman ---
(In reply to Andrew Pinski from comment #1)
> Note branchless might be worse.
really?
could you explain please?
> Anyways there is a duplicate of this bug
> already. I think I filed it.
thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
--- Comment #3 from Andrew Pinski ---
(In reply to niXman from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Note branchless might be worse.
>
> really?
> could you explain please?
Yes cache misses. That is the second load migh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Bug ID: 109556
Summary: internal compiler error: in
iterative_hash_template_arg, at cp/pt.cc:1927
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #2 from Fabian Sauter
---
Created attachment 54884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54884&action=edit
Preprocessed Source
Ah, it failed to upload with: "The file you are trying to attach is 2505
kilobytes (KB) i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #4 from Jeffrey A. Law ---
x86's tuning does have some support for avoiding multiple cmovs in a single
if-converted sequence. I'll double check if that's kicking in here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #3 from Jakub Jelinek ---
Reproduced, reducing now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #21 from Sam James ---
The commits got reverted in r14-76-ga6e4b81b12e57b and r14-77-gfac24d43e68838
after marxin reported a segfault with mold in #gcc and fweimer reported an
issue with cmake at https://bugzilla.redhat.com/show_bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #22 from Jakub Jelinek ---
extern int cinalias __attribute__((__symver__ ("_ZSt4cin@GLIBCXX_3.4")));
void foo ()
{
cinalias++;
}
doesn't work to refer to older symver, but
extern int cinalias;
asm (".symver cinalias, _ZSt4cin@GLIBC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Khokholkov Vladimir changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #3 from Khokh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342
--- Comment #10 from Ilya Leoshkevich ---
This bug was fixed and backported to gcc-12:
commit 06254d97b8fa3a5d1c8b6b4e091d851700801385
Author: Ilya Leoshkevich
Date: Fri Jul 29 16:14:10 2022 +0200
PR106342 - IBM zSystems: Provide vsel f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #23 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #20)
> So, when the @@GLIBCXX_3.4.31 alias is weak, at least the F36 linker puts
> into the binary not just one but both symbols and so the aliasing isn't
> broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #24 from Jakub Jelinek ---
You're right. libstdc++.so.6 would then initialize just the old symver copy
and not the new one, which could be used by newer shared libraries.
So that leaves the asm (".globl _Zwhatever"); in the header f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
--- Comment #9 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:0df6d181230f0480547ed08b4e4354db68242724
commit r14-85-g0df6d181230f0480547ed08b4e4354db68242724
Author: Uros Bizjak
Date: Wed Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #15 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:0df6d181230f0480547ed08b4e4354db68242724
commit r14-85-g0df6d181230f0480547ed08b4e4354db68242724
Author: Uros Bizjak
Date: Wed Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Andreas Schwab changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #21 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:ed32ec26697cc77492d094b31a0d2eebc0535644
commit r14-88-ged32ec26697cc77492d094b31a0d2eebc0535644
Author: Jason Merrill
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #6 from Jeffrey A. Law ---
And just an FYI, the tester is flagging conditional move failures for mips64-*
rx-elf and s390-linux-gnu. Most likely these are additional cases where the
hook is indicating the transformation isn't profit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:04a9209dc865dafe3c9615f5c868aa3fd89b96cf
commit r14-89-g04a9209dc865dafe3c9615f5c868aa3fd89b96cf
Author: Andrew Pinski
Date: Thu A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Summary|suboptim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
--- Comment #3 from Andrew Pinski ---
Note I disagree with load_uint32_t having a warning. the pointer might be have
a const qualifier on it does not mean the location is const overall.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-19
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection,|
|needs-reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
--- Comment #4 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #3)
> Note I disagree with load_uint32_t having a warning. the pointer might be
> have a const qualifier on it does not mean the location is const overall.
And the doc di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Bug ID: 109557
Summary: __builtin_dynamic_object_size() does not work for
simple testing case
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558
Bug ID: 109558
Summary: bpf: support BTF and DWARF tag annotations for BPF
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558
Jose E. Marchesi changed:
What|Removed |Added
Last reconfirmed||2023-04-19
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #40 from qinzhao at gcc dot gnu.org ---
I had an initial patch to support the element_count attribute and use this
attribute in builtin_dynamic_object_size(), for the following testing case:
1 #include
2 #include
3 #ifdef ENA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
Jose E. Marchesi changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #1 from Siddhesh Poyarekar ---
The __bdos call itself cannot succeed in main() because it cannot see the
allocation in store(). One way it could succeed is if store() was inlined, but
for some reason it doesn't, even if you make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #6 from Jakub Jelinek ---
Indeed, the reduction got stuck at around 1.4M size and didn't reduce further
until I've killed it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107481
Jose E. Marchesi changed:
What|Removed |Added
CC||jemarch at gcc dot gnu.org
Last re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #0)
> I am wondering for
> p.3_1 = p;
> _2 = __builtin_object_size (p.3_1, 0);
>
> why the size of p.3_1 cannot use the TYPE_SIZE of the pointee of p when its
> size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107480
Jose E. Marchesi changed:
What|Removed |Added
Last reconfirmed||2023-04-19
Assignee|unassi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904
--- Comment #2 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6fc8e25cb6b5d720bedd85194b0ad740d75082f4
commit r14-90-g6fc8e25cb6b5d720bedd85194b0ad740d75082f4
Author: Harald Anlauf
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
--- Comment #5 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6fc8e25cb6b5d720bedd85194b0ad740d75082f4
commit r14-90-g6fc8e25cb6b5d720bedd85194b0ad740d75082f4
Author: Harald Anlauf
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107479
Jose E. Marchesi changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #4 from Siddhesh Poyarekar ---
(In reply to Martin Uecker from comment #3)
> I general the pointer could point to the first object of an array that has
> more elements, or to an object of a different type.
How so? p in comment 0 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #22 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:7b30f13b904f137c77e5180357af7917a3b47af0
commit r12-9447-g7b30f13b904f137c77e5180357af7917a3b47af0
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #5 from Martin Uecker ---
(In reply to Siddhesh Poyarekar from comment #4)
> (In reply to Martin Uecker from comment #3)
> > I general the pointer could point to the first object of an array that has
> > more elements, or to an objec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
Jason Merrill changed:
What|Removed |Added
Known to work|13.0|
Summary|[12 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #7 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:5e284ebbc3082c5a8974d24e3a0977aa48f3cc60
commit r14-91-g5e284ebbc3082c5a8974d24e3a0977aa48f3cc60
Author: Patrick Palka
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:90361bc6f4edb444e86380b6d1e08475fa74
commit r13-7227-g90361bc6f4edb444e86380b6d1e08475fa74
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #12 from Leandro Lupori ---
(In reply to anlauf from comment #11)
> Do you have anybody else supporting the view that the code in question
> should work as an extension?
>
I know there is some usage of this extension, in code simil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109551
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #7 from qinzhao at gcc dot gnu.org ---
Okay, thanks for the comment. I see why this should not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #13 from Steve Kargl ---
On Wed, Apr 19, 2023 at 05:25:20PM +, leandro.lupori at linaro dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> I'm trying to check with the issue reporter how extensive is his us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #13)
> Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative
> text. I suppose one can claim that gfortran should throw an
> error when a function re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58538
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
--- Comment #12 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:58b7dbf865b146a4e65dbda9be6df78f212c03b6
commit r14-92-g58b7dbf865b146a4e65dbda9be6df78f212c03b6
Author: Patrick Palka
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #16 from Steve Kargl ---
On Wed, Apr 19, 2023 at 07:15:50PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> --- Comment #15 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Ka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Bug ID: 109559
Summary: Unexpected -Wmaybe-uninitialized warning when inlining
with system header
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Marek Polacek changed:
What|Removed |Added
Summary|Unexpected |[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
--- Comment #2 from Marek Polacek ---
Originally this happened when including boost headers, function_template.hpp in
particular, where newer versions suppress a lot of warnings:
commit b75386f628b46f1060a20b6e015931bac37b7da7 (origin/feature/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #16)
> First, note, 'allocated(f())' throws an error.
Agree.
> Now, with the original code,
>
> is_allocated(f())
>
> The function reference is eva
1 - 100 of 116 matches
Mail list logo