https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
--- Comment #4 from Richard Biener ---
Visiting statement:
+j_13 = j_39 + 9;
+
+Match-and-simplified j_39 + 9 to -1420678594
+
+Visiting statement:
if (j_13 <= 2147483628)
Trying to determine truth value of predicate if (j_13 <= 2147483628)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
--- Comment #5 from Yann Girsberger ---
Sorry the initial error slipped through.
The original large case seems fine. I re-reduced it but it seems I was too slow
:)
The result is the same as the shown fixed version except for the constant used
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #12 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #11)
> > when a module has the same name but a different interface are the
> symbols distinct (i.e. mangled differently)?
>
> no. So, as you say, the ordering of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #7 from Segher Boessenkool ---
-m64 requires 64-bit instructions. We will ICE if we try to generate code
for -m64 without support for 64-bit insns enabled in the compiler. For
example, the stdu insn is required to implement the ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0986c351aa8a9f08b3cb614baec13564dd62c114
commit r13-5100-g0986c351aa8a9f08b3cb614baec13564dd62c114
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #13 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #12)
> (In reply to Gaius Mulley from comment #11)
> > > when a module has the same name but a different interface are the
> > symbols distinct (i.e. mangled differentl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #14 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Gaius Mulley from comment #11)
> > > > when a module has the same name but a different interface are th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
--- Comment #6 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #5)
> NOt sure we want to do that for this release tho...?
Why not? Regression fixes are fine even in stage4, we are still in stage3.
I'd go with something like you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #15 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #14)
> (In reply to Iain Sandoe from comment #13)
> > (In reply to Iain Sandoe from comment #12)
> > > (In reply to Gaius Mulley from comment #11)
> > > > > when a module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
Jonathan Wakely changed:
What|Removed |Added
Resolution|MOVED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #24 from Eric Botcazou ---
> Maybe we want something like this:
>
> diff --git a/libstdc++-v3/config/os/mingw32-w64/os_defines.h
> b/libstdc++-v3/config/os/mingw32-w64/os_defines.h
> index ee02ff82e86..68ac100acc8 100644
> --- a/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #25 from Jonathan Wakely ---
For --enable-threads=posix the value of _WIN32_WINNT doesn't matter, so we
don't want to disable _GLIBCXX_HAS_GTHREADS in that case. That's why we need to
include , to find out if it's actually affected b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105973
--- Comment #8 from Martin Liška ---
Thinking about it, we would likely need a "data flow" algorithm, where we want
to transitively propagate equal predicates that occur in both successors of a
basic block. Once we "merge" such a predictor, a ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108137
--- Comment #10 from Martin Liška ---
Great, glad to hear that. I'm testing the backport to gcc-12 branch right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108366
Martin Liška changed:
What|Removed |Added
Summary|[12/13 Regression] Spurious |[12/13 Regression] Spurious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:445a48a226ffd530b37bcdc13b6bdca94ba2e122
commit r13-5102-g445a48a226ffd530b37bcdc13b6bdca94ba2e122
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108352
Richard Biener changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108137
--- Comment #11 from CVS Commits ---
The releases/gcc-12 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:bd4c310b06d747975853ac6dfef6da120c13f6ec
commit r12-9040-gbd4c310b06d747975853ac6dfef6da120c13f6ec
Author: Martin Liska
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108137
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108367
Bug ID: 108367
Summary: [12/13 Regression] ICE: verify_ssa failed (error:
definition in block 4 does not dominate use in block
3)
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108367
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-01-11
Summary|[12/13 Reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108352
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:7c9f20fcfdc2d8453df88ceb7e693debfcd678c0
commit r13-5103-g7c9f20fcfdc2d8453df88ceb7e693debfcd678c0
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976
--- Comment #5 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:8221efae233e2d5992a79600071dd0a52f1b3c74
commit r13-5104-g8221efae233e2d5992a79600071dd0a52f1b3c74
Author: Martin Liska
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108352
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108308
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b39c1bea5bae9aee1df25cab1064f983b9ec6941
commit r13-5105-gb39c1bea5bae9aee1df25cab1064f983b9ec6941
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #19 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f99d7d669eaa2830eb5878df4da67e77ec791522
commit r13-5106-gf99d7d669eaa2830eb5878df4da67e77ec791522
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108366
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105126
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108367
--- Comment #2 from Richard Biener ---
The OACC parloops pass adds a loop-around edge which short-cuts the definition
of the debug use. I don't see anywhere how that handles debug stmts - maybe it
gets fixed during lowering ... (yes, with -fno-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #7 from Richard Biener ---
(In reply to Martin Liška from comment #6)
> We fail in the param assignment:
>
> (gdb) pp x
> (reg:V4DI 82)
> (gdb) pp y
> (mem/c:BLK (reg/f:DI 76 virtual-incoming-args) [1 x+0 S32 A256])
>
> So we will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #7)
> (In reply to Martin Liška from comment #6)
> > We fail in the param assignment:
> >
> > (gdb) pp x
> > (reg:V4DI 82)
> > (gdb) pp y
> > (mem/c:BLK (reg/f:DI 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108368
Bug ID: 108368
Summary: [13 Regression] Dead Code Elimination Regression at
-O3 since r13-1759-gdbb093f4f15
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
Bug ID: 108369
Summary: FM509 Fails to compile with error
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
Bug ID: 108370
Summary: gcc doesn't merge bitwise-AND if an explicit
comparison against 0 is given
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108368
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #1 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
Thomas Schwinge changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-01-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108371
Bug ID: 108371
Summary: gcc for x86_64 may sign/zero extent arguments
unnecessarily
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
--- Comment #16 from Jonathan Wakely ---
Unfortunately this change causes a regression for libs that were statically
linked to libstdc++.a before the PR 91057 fix. Any object which has the buggy
std::locale::id::_M_id() code linked into it can g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
--- Comment #2 from Richard Biener ---
ifcombine seems to assume that
D.1987_7 = op0 & 1;
if (D.1987_7 != 0)
is canonical but we see
_9 = (_Bool) _6;
if (_9 != 0)
instead. That's already the form introduced by inlining from
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108371
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #8 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #7)
> -m64 requires 64-bit instructions. We will ICE if we try to generate code
> for -m64 without support for 64-bit insns enabled in the compiler. For
> example,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108372
Bug ID: 108372
Summary: [12 regression] -E -fdirectives-only crash
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108373
Bug ID: 108373
Summary: Update 'contrib/gcc_update:files_and_dependencies' for
Modula-2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
--- Comment #3 from dhowells at redhat dot com ---
We don't want to do:
return ((unsigned int) bio->bi_flags >> bit & 1) != 0;
if we can avoid it as "bit" is usually constant - though I'm guessing the
optimiser should handle that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #26 from Eric Botcazou ---
> For --enable-threads=posix the value of _WIN32_WINNT doesn't matter, so we
> don't want to disable _GLIBCXX_HAS_GTHREADS in that case. That's why we need
> to include , to find out if it's actually affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108355
--- Comment #2 from Richard Biener ---
Basically get_ref_base_and_extent trusts TYPE_SIZE of the array operand of an
ARRAY_REF (it would also use range info on an SSA name index, but we'd expect
a singleton to be propagated there already). In p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #16 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Gaius Mulley from comment #11)
> > > > when a module has the same name but a different interface are th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #14 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:3e1cba12a8d71e70235a9a9b8f1a237a561db3e7
commit r13-5109-g3e1cba12a8d71e70235a9a9b8f1a237a561db3e7
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #17 from Gaius Mulley ---
Yes I was coming to the same conclusion (re: name mangling).
If each library module had its mangled name component set via -flibname=pim or
-flibname=iso etc. Then we have one universe of distinct named mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #18 from Gaius Mulley ---
For the runtime perspective then your layered approach is much cleaner.
It would be good to allow users to be able to use pim and some iso
functionality or visa versa.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108334
--- Comment #5 from Jamaika ---
Created attachment 54247
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54247&action=edit
Added zip files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andreas Krebbel changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andreas Krebbel changed:
What|Removed |Added
Version|13.0|12.2.1
--- Comment #16 from Andreas K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
--- Comment #3 from Tobias Burnus ---
Commenting out the 'gcc_assert' of comment 0, it compiles and produces the
following dump.
I don't understand why there is a 'lastprivate' – and 'i' in the bounds are
wrong: for the first iteration, it is un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Eric Botcazou changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #13 from Iain Sandoe ---
Created attachment 54248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54248&action=edit
Revised fix
This essentially makes Modula-2 build its include paths in the Front End (which
is how all the othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293
--- Comment #4 from CVS Commits ---
The master branch has been updated by David Faust :
https://gcc.gnu.org/g:c7279270a2deda81eaeba37a87d721bee0ed6004
commit r13-5110-gc7279270a2deda81eaeba37a87d721bee0ed6004
Author: David Faust
Date: Tue J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71343
--- Comment #4 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:98837d6e79dd27c15f5218f3f1ddf838cda4796c
commit r13-5111-g98837d6e79dd27c15f5218f3f1ddf838cda4796c
Author: Roger Sayle
Date: Wed Ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293
Jose E. Marchesi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
In file included from
/opt/compiler-explorer/gcc-trunk-20230111/include/c++/13.0.0/atomic:41,
from :1:
In member function 'std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = long
unsigned int]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
--- Comment #1 from Romain Geissler ---
I forgot to mention: this happens on x86-64 with -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
Bug ID: 108375
Summary: [10/11/12/13 Regression] Some variably modified types
not detected as such
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108376
Bug ID: 108376
Summary: TSVC s1279 runs 40% faster with aocc than gcc at zen4
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99408
--- Comment #3 from Jan Hubicka ---
with zen4 gcc build loop takes 19s, while aocc 6.6.
aocc:
.LBB0_1:# %for.cond22.preheader
# =>This Loop Header: Depth=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99412
--- Comment #2 from Jan Hubicka ---
This is also seen with zen4 comparing gcc and aocc. (about 2.3 times
differnece)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108372
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244
Andrew Pinski changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gcc-patches/2006-May/194375.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> https://gcc.gnu.org/pipermail/gcc-patches/2006-May/194375.html
I can't tell if the Ada testcase was added or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #18 from CVS Commits ---
The releases/gcc-12 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:eec3a65ed638a1c58fa08ddf508d2d60b64d311d
commit r12-9041-geec3a65ed638a1c58fa08ddf508d2d60b64d311d
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #19 from CVS Commits ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:01e80c4c630a5a6286a521b047d0ef80631c892c
commit r11-10463-g01e80c4c630a5a6286a521b047d0ef80631c892c
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108334
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108376
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107838
Guilherme Janczak changed:
What|Removed |Added
CC||guilherme.janczak at yandex
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108377
Bug ID: 108377
Summary: Unexpected 'exceeds maximum object size' diagnostic,
wrong-code?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #19 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #18)
> For the runtime perspective then your layered approach is much cleaner.
indeed ..
> It would be good to allow users to be able to use pim and some iso
> functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108377
--- Comment #1 from Thomas Schwinge ---
That's x86_64-pc-linux-gnu at today's commit
de99049f6fe5341024d4d939ac50d063280f90db.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:23b4ce18379cd336d99d7c71701be28118905b57
commit r13-5112-g23b4ce18379cd336d99d7c71701be28118905b57
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108377
--- Comment #2 from Andrew Pinski ---
So we have:
const __SIZE_TYPE__ n = calc_n(259);
#if 1
haystack = __builtin_malloc(n + 1);
if (!haystack)
__builtin_abort();
for (__SIZE_TYPE__ i = 0; i < n + 1; ++i)
haystack[i] = '0';
#endi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108377
--- Comment #3 from Andrew Pinski ---
Just adding:
if (n+1 == 0) __builtin_unreachable();
Right before the first malloc removes the warning as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:688fc162b76dc6747a30fcfd470f4770da0f4924
commit r13-5113-g688fc162b76dc6747a30fcfd470f4770da0f4924
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252
--- Comment #4 from David Malcolm ---
Should be fixed on trunk for gcc 13 by the above commit.
I *think* the store::set_value change can be readily backported to GCC 12, so
keeping this bug open to track that backport (perhaps even earlier???)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> (In reply to Ben Brewer from comment #0)
> Workaround: either use -std=legacy or fix the above argument declaration to:
>
> CHARACTER C1D001(*)*8,CVD00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99634
--- Comment #2 from Jan Hubicka ---
AOCC produced code is:
.LBB0_2:# %vector.body
# Parent Loop BB0_1 Depth=1
# => This Inner Loop
1 - 100 of 115 matches
Mail list logo
