https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409
--- Comment #1 from Omar Sandoval ---
Patch sent:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630242.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #5 from rguenther at suse dot de ---
On Wed, 13 Sep 2023, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
>
> --- Comment #3 from Robin Dapp ---
> Several other things came up, so I'm just goi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #4 from rguenther at suse dot de ---
On Wed, 13 Sep 2023, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
>
> Robin Dapp changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111372
--- Comment #5 from Kito Cheng ---
> Ok, but it's better to have configure option or something else just
> for toolchains that definitely do not use vector extension
I can understand that there would be such a demand in the embedded world, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
--- Comment #16 from Andrew Pinski ---
Next patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630241.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
--- Comment #2 from Sam James ---
Created attachment 55897
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55897&action=edit
reduced.i
I've attached a reduced version but the memcpy bit could do with cleaning up
for it to be a bit more sen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
Andrew Pinski changed:
What|Removed |Added
Summary|[14 regression] ICE when|[14 regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
org/bugzilla/attachment.cgi?id=55896&action=edit
celt_decoder.c.i
```
gcc (Gentoo 14.0.0 p, commit d0b55776a4e1d2f293db5ba0e4a04aefed055ec4) 14.0.0
20230913 (experimental) 3af2af15798cb6243e2643f98f62c9270b1ca5d2
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
chenglulu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111402
--- Comment #2 from Hongtao.liu ---
Adjust code in foo1, use < n instead of != n, the issue remains.
void
foo1 (v4di* __restrict a, v4di *b, int n)
{
for (int i = 0; i < n; i+=2)
{
a[i] = b[i];
a[i+1] = b[i+1];
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111410
Bug ID: 111410
Summary: Bogus Wdangling-reference warning with ranges pipe
expression in for loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #20 from CVS Commits ---
The master branch has been updated by LuluCheng :
https://gcc.gnu.org/g:9a033b9feffc9d97d5acfe8ca3cd16359f4b714b
commit r14-3974-g9a033b9feffc9d97d5acfe8ca3cd16359f4b714b
Author: Lulu Cheng
Date: Mon Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
--- Comment #15 from Andrew Pinski ---
Created attachment 55895
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55895&action=edit
testcases for the constants off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
--- Comment #14 from Andrew Pinski ---
Created attachment 55894
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55894&action=edit
Third patch to support the constants that are off by one
This patch adds what I mentioned was missing in comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC|richard.sandiford at arm dot com |
--- Comment #39 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408
--- Comment #2 from Andrew Pinski ---
GCC 13.2:
sarl%cl, %eax
movld(%rip), %ecx
andl$1, %eax
andl$31, %edx
leal-9(%rcx,%rcx), %ecx
cmpl%eax, %ecx
While the trunk:
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-09-13
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409
Bug ID: 111409
Summary: Invalid .debug_macro.dwo macro information for split
DWARF
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #3 from Robin Dapp ---
Several other things came up, so I'm just going to post the latest status here
without having revised or tested it. Going to try fixing it and testing
tomorrow.
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408
Bug ID: 111408
Summary: [14 Regression] Wrong code at -O2/3 on
x86_64-linux-gnu since r14-2866-ge68a31549d9
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59526
--- Comment #4 from CVS Commits ---
The master branch has been updated by Francois Dumont :
https://gcc.gnu.org/g:92456291849fe88303bbcab366f41dcd4a885ad5
commit r14-3926-g92456291849fe88303bbcab366f41dcd4a885ad5
Author: François Dumont
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #14 from John Soo ---
> Here though it seems that you are dealing with another sort of limit which is
> much larger (I have seen 128K being mentioned on the GH page).If this
> somehow corrupts the command line, it wouldn't help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #8 from qinzhao at gcc dot gnu.org ---
the latest GCC14 has the same issue.
with the patch proposed in comment #1, the failure has been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #5)
> Testcase:
thanks a lot for the testing case. GCC8 failed with this, disable
tree-widening_mul fixed the failure.
and my patch for GCC8 also fixed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
--- Comment #26 from Andrew Pinski ---
Created attachment 55893
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55893&action=edit
Here is my idea around the patch for prototype for doing the constant prop idea
This is like the one in commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Testcase:
The way I figured out this testcase was trial and error and starting with the
testcase from PR 69167 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> Also what target is this for?
> I suspect aarch64 since x86_64 does not have widening multiply ...
you are right, it's aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> Do you have a testcase?
I have, but I cannot expose it to public.
I can provide the Bad IR and Good IR if you think it's okay.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #2 from Andrew Pinski ---
Also what target is this for?
I suspect aarch64 since x86_64 does not have widening multiply ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111398
--- Comment #2 from Thorsten Glaser ---
Right, which is why I suggested a -Wextra level option to warn about these.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
Bug ID: 111407
Summary: ICE: SSA corruption due to widening_mul opt on
conflict across an abnormal edge
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
--- Comment #5 from Andrew Pinski ---
To be able to detect this, an ABI change would be needed as you need to pass
back if the function fell through or not. Now for (non-address taken) static
functions that should be ok. The check should happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
--- Comment #8 from AK ---
> this does seem like a HW issue. Are you sure you have a decent RISCV machine
> without any memory issues?
> I suspect ninja is building with all of the cores which pushes the memory
> usage high.
possible. I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
--- Comment #7 from Andrew Pinski ---
Created attachment 55892
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55892&action=edit
version of using simple_dce_from_worklist in forwprop
This is a version of using simple_dce_from_worklist in f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111406
--- Comment #2 from Andreas K. Huettel ---
Indeed, sorry
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=libiberty/Makefile.in#l388
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111405
--- Comment #2 from Wang Chenyu <3180104919 at zju dot edu.cn> ---
(In reply to Andrew Pinski from comment #1)
> Signed integer overflow is undefined behavior.
>
> Use -fwrapv or unsigned to do the addition to get the behavior you want.
I see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111406
--- Comment #1 from Andrew Pinski ---
>This stems from libiberty/Makefile.am:
You mean Makefile.in, libiberty does not use automake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111405
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111406
Bug ID: 111406
Summary: libiberty build produces errors with CC=clang,
unsupported option '-print-multi-os-directory'
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111405
Bug ID: 111405
Summary: Problem with incorrect optimizion for "constexpr"
function with possible overflow
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111404
Bug ID: 111404
Summary: [AArch64] 128-bit __sync_val_compare_and_swap is not
atomic
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390
--- Comment #7 from joseph at codesourcery dot com ---
Stubbing out execution of tests can be done with a suitable board file (a
board file to stub out linking as well is a bit more complicated).
https://gcc.gnu.org/pipermail/gcc/2017-Septembe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
--- Comment #6 from Richard Biener ---
So the issue is that forwprop & folding has a hard time in cleaning up dead
code afterwards but it would also benefit from doing that more aggressively
(and early) because of single_use () and friends.
I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105928
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
Assignee|una
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53
--- Comment #4 from Robin Dapp ---
Yes, with VLS reduction this will improve.
On aarch64 + sve I see
loop inside costs: 2
This is similar to our VLS costs.
And their loop is indeed short:
ld1wz30.s, p7/z, [x0, x2, lsl 2]
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53
--- Comment #3 from JuzheZhong ---
(In reply to Robin Dapp from comment #2)
> With the current trunk we don't spill anymore:
>
> (VLS)
> .L4:
> vle32.v v2,0(a5)
> vadd.vv v1,v1,v2
> addia5,a5,16
> bne a5,a4,.L4
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53
--- Comment #2 from Robin Dapp ---
With the current trunk we don't spill anymore:
(VLS)
.L4:
vle32.v v2,0(a5)
vadd.vv v1,v1,v2
addia5,a5,16
bne a5,a4,.L4
Considering just that loop I'd say costing works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111364
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111364
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:06bedc3860d3e61857d72ffe699f79ed5c92855f
commit r14-3922-g06bedc3860d3e61857d72ffe699f79ed5c92855f
Author: Andrew Pinski
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111345
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111345
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:635a34e2be67d709088c31573732dfdf733e4cec
commit r14-3921-g635a34e2be67d709088c31573732dfdf733e4cec
Author: Andrew Pinski
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111387
Richard Biener changed:
What|Removed |Added
Known to work||14.0
--- Comment #4 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111387
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:04238615bba435f0b0ca7b263ad2c6bdb596e865
commit r14-3920-g04238615bba435f0b0ca7b263ad2c6bdb596e865
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111402
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
Xi Ruoyao changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
Bug ID: 111403
Summary: LoongArch: Wrong code with -O -mlasx -fopenmp-simd
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
--- Comment #4 from David Brown ---
(In reply to Andreas Schwab from comment #3)
> You already have -W[error=]return-type.
Yes, and that is what I normally use - I am a big fan of gcc's static warnings.
Sometimes, however, there are false posi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #38 from rguenther at suse dot de ---
On Wed, 13 Sep 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
>
> --- Comment #36 from JuzheZhong ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #37 from JuzheZhong ---
(In reply to Richard Biener from comment #35)
> (In reply to Richard Biener from comment #34)
> > The ELSE value of type TYPE would be constructed like
> >
> > tree var = create_tmp_var (type);
> > tree els
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #36 from JuzheZhong ---
(In reply to Richard Biener from comment #34)
> The ELSE value of type TYPE would be constructed like
>
> tree var = create_tmp_var (type);
> tree else_val = get_or_create_ssa_default_def (cfun, var);
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111402
Bug ID: 111402
Summary: Loop distribution fail to optimize memmove for
multiple consecutive moves within a loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
--- Comment #3 from Andreas Schwab ---
You already have -W[error=]return-type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #35 from Richard Biener ---
(In reply to Richard Biener from comment #34)
> The ELSE value of type TYPE would be constructed like
>
> tree var = create_tmp_var (type);
> tree else_val = get_or_create_ssa_default_def (cfun, var);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #34 from Richard Biener ---
The ELSE value of type TYPE would be constructed like
tree var = create_tmp_var (type);
tree else_val = get_or_create_ssa_default_def (cfun, var);
I'm not sure const0_rtx is a good representation on RT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111354
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
--- Comment #2 from David Brown ---
(In reply to Richard Biener from comment #1)
> Confirmed. Note C17 disallows a return wotihout an expression for a funcion
> that returns a value, not sure if that means falling off the function
> without a r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
Bug ID: 111401
Summary: Middle-end: Missed optimization of
MASK_LEN_FOLD_LEFT_PLUS
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111399
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-09-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111387
--- Comment #2 from Richard Biener ---
The main issue is that when BB SLP splits the function when we already entered
a cycle we have to go back and split at the containing cycles (recursively)
because otherwise we can end up seeing "externals"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
--- Comment #5 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
>
> So using the local range in this case is ok. There might be only a few times
> we don't want to use it though in match.
Agree, "get_range_query" w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
--- Comment #4 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #3)
> A patch is posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629534.html
It is not for this PR. Sorry for typo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111379
--- Comment #3 from Xi Ruoyao ---
If CWG 2749 is accepted we should just close this as WONTFIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #33 from JuzheZhong ---
Is it reasonable this way ?
ELSE VALUE = make_temp_ssa_name (vectype, NULL, "undefine_");
Then in the later "expand" stage:
defind_expand "cond_len_xxx"
...
if (REG_EXPR (operand) == "undefine") {
gen r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111379
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #32 from JuzheZhong ---
(In reply to Richard Biener from comment #31)
> On GIMPLE an "undefined" operand representation would be the default
> definition of an SSA name with the appropriate type. That's a somewhat
> "heavy" represen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111397
Richard Biener changed:
What|Removed |Added
Known to fail||12.3.1, 13.2.1
Summary|Spur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111397
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:92ea12ea99fce546772a40b7bbc2ea850db9b1be
commit r14-3916-g92ea12ea99fce546772a40b7bbc2ea850db9b1be
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
Bug ID: 111400
Summary: Missing return sanitization only works in C++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110488
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110488
Eric Botcazou changed:
What|Removed |Added
Summary|Legal deferred constant |[13/14 regression] legal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #31 from Richard Biener ---
On GIMPLE an "undefined" operand representation would be the default definition
of an SSA name with the appropriate type. That's a somewhat "heavy"
representation and it also doesn't fit the target hook r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111399
Bug ID: 111399
Summary: Sanitizer code generation smarter than warnings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111398
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111320
--- Comment #1 from JuzheZhong ---
Not only inorder reduction.
But also un-order reduction:
https://godbolt.org/z/sn5jbWPbd
#include
int
foo (int16_t * __restrict a, int n, int * __restrict cond)
{
int r = 0;
for (int i = 0; i < 8; i++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111397
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390
Jonathan Wakely changed:
What|Removed |Added
Summary|'make check-compile' target |libstdc++-v3/scripts/check_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
Richard Biener changed:
What|Removed |Added
Version|unknown |13.1.0
--- Comment #7 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390
--- Comment #5 from Richard Biener ---
Just to add a compile-only "override" would be useful to do bare testing of
cross compilers where no (or an incomplete) runtime is available to reduce
the amount of noise produced (you still get complaints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
Gayathri Gottumukkala changed:
What|Removed |Added
CC||gayathri.gottumukkala.27@gm
98 matches
Mail list logo
