https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 109563, which changed state.
Bug 109563 Summary: accessing 9223372036854775810 or more bytes at offsets [2,
9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at
offset -3 [-Wrestrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651
Andrew Pinski changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
--- Comment #2 from Frank Heckenbach ---
Since I can't easily upgrade to trunk, I need to know if the warning is bogus
in 12.2 and I can safely disable it, or do I need to worry about the generated
code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:57e7229a29ca0e9929b61051e4f5857f0b41b6c7
commit r14-105-g57e7229a29ca0e9929b61051e4f5857f0b41b6c7
Author: Jiufu Guo
Date: Tue Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
Bug ID: 109563
Summary: accessing 9223372036854775810 or more bytes at offsets
[2, 9223372036854775807] and 1 may overlap up to
9223372036854775813 bytes at offset -3 [-Wrestrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #18 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #17)
> (In reply to Steve Kargl from comment #16)
> > First, note, 'allocated(f())' throws an error.
>
> Agree.
>
> > Now, with the original code,
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #2 from Andrew Pinski ---
Note for some x86 cores having 2 or more cmove back to back is worse than a
conditional jump so maybe the testcase is now catching what it should happen
...
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=108840
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
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:
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=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=109549
--- Comment #1 from Andrew Pinski ---
> BTW, I saw Andrew's patch fixing cmov:
It is unrelated. This is a cost model issue of the x86 backend I think.
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
Bug ID: 109549
Summary: [14 Regression] cmov6.c test fail after commit
r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109550
Richard Biener changed:
What|Removed |Added
Blocks||24639
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #7 from Puneet B ---
Any pointers here help to debug further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109550
Bug ID: 109550
Summary: warning: "p" may be used uninitialized
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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=109549
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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:
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=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:
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=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=109556
--- Comment #2 from Fabian Sauter
---
Created attachment 54884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54884=edit
Preprocessed Source
Ah, it failed to upload with: "The file you are trying to attach is 2505
kilobytes (KB) in
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=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=109465
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
--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=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:
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 #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
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=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=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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-04-19
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:
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=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=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
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=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:
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
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=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
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=109561
Bug ID: 109561
Summary: -Wmaybe-uninitialized false positive false positive
false positive false positive false positive
Product: gcc
Version: 12.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109562
Bug ID: 109562
Summary: Failed to build native GCC 12.2.0 on RISC-V64 linux
machine
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109562
--- Comment #1 from Andrew Pinski ---
>/usr/include/stdio.h:189:24: error: expected ‘,’ or ‘;’ before ‘__attr_dealloc’
Hmm, --disable-multilib is not working
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=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
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:
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
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
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=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
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://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=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
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection,|
|needs-reduction
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=109556
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Khokholkov Vladimir changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #3 from
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=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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-19
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=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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
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=108099
Jason Merrill changed:
What|Removed |Added
Known to work|13.0|
Summary|[12 Regression]
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=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
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=58538
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
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=109558
Bug ID: 109558
Summary: bpf: support BTF and DWARF tag annotations for BPF
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
Jose E. Marchesi changed:
What|Removed |Added
Status|NEW |ASSIGNED
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
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558
Jose E. Marchesi changed:
What|Removed |Added
Last reconfirmed||2023-04-19
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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109551
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
1 - 100 of 118 matches
Mail list logo
