https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #13 from Richard Biener ---
(In reply to Carlos Galvez from comment #11)
> Consider this more realistic example:
>
> https://godbolt.org/z/jbbqbe8d9
>
> The compiler has all the information available to ensure that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113013
--- Comment #6 from Siddhesh Poyarekar ---
Sorry I misread the reproducer as void *reallocarray(void)
__attribute__((__alloc_size__(1)));
Your fix looks fine to me, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031
--- Comment #2 from Nathaniel Shead ---
Reduced to:
template class variant;
template
auto __variant_cast(_Tp __rhs) { return static_cast&&>(__rhs);
}
template
struct _Move_assign_base : _Types {
void operator=(_Move_assign_base __rhs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
--- Comment #11 from Richard Biener ---
We now diagnose
std::__insertion_sort.isra (, [(void *) + 64B]);
the reason is still the same, failure to compute a range for 'qa' which
we fail to SCEV analyze. There's a duplicate bug about this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2021-11-30 00:00:00 |2023-12-15
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113013
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Tested x86_64-linux and x86_64-w64-mingw. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* src/c++23/print.cc (__write_to_terminal) [_WIN32]: If handle
does not refer to the console then just write to it using normal
file I/O.
* testsuite/27_io/print/2.cc
Tested x86_64-linux and x86_64-w64-mingw. Pushed to trunk.
-- >8 --
Since we don't need to do anything special to print Unicode on
non-Windows targets, we might as well just use std::vprint_nonunicode to
implement std::vprint_unicode. Removing the duplicated code should
reduce code size in cases
Tested x86_64-linux and x86_64-w64-mingw. Pushed to trunk.
-- >8 --
Tim Song pointed out that although std::print behaves as a formatted
output function, it does "determine padding" using the stream's flags.
libstdc++-v3/ChangeLog:
* include/std/ostream (vprint_nonunicode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080
--- Comment #7 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:5c3ab44771d0524140cf2ce5de594fcf7fefcd6f
commit r12-10044-g5c3ab44771d0524140cf2ce5de594fcf7fefcd6f
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:e35556c61bdeb9f41b4111fffb423a705232ab9c
commit r12-10043-ge35556c61bdeb9f41b4111fffb423a705232ab9c
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111253
--- Comment #8 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:e26608db3c2b2644decca5f49dab1e6846a9d1b0
commit r12-10041-ge26608db3c2b2644decca5f49dab1e6846a9d1b0
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
--- Comment #4 from avieira at gcc dot gnu.org ---
Drive by comments as it's been a while since I looked at this. I'm also
surprised we didn't adjust the bounds. But why do we only subtract VF? Like you
say, if there's no loop around edge, can't
We don't allow SImode in FCC, so constraint z is never really used
here.
gcc/ChangeLog:
* config/loongarch/loongarch.md (movsi_internal): Remove
constraint z.
---
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
gcc/config/loongarch/loongarch.md | 6 +++---
Hi!
On 2023-12-14T15:26:38+0100, Tobias Burnus wrote:
> On 19.08.23 00:47, Julian Brown wrote:
>> This patch adds support for non-constant component offsets in "map"
>> clauses for OpenMP (and the equivalants for OpenACC) [...]
Should eventually also add some OpenACC test cases?
> LGTM with:
LGTM.
Regards
Robin
This patch fixes the following FAILs in "full coverage" testing:
Running target
riscv-sim/-march=rv64gcv_zvl256b/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=m8/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c -flto -ffat-lto-objects execution
On 12/15/23 13:52, juzhe.zh...@rivai.ai wrote:
> Do you mean :
>
> /* We need to use precomputed mask for such situation and such mask
> can only be computed in compile-time known size modes. */
> bool indices_fit_selector_p
> = GET_MODE_BITSIZE (GET_MODE_INNER (vmode)) > 8 ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
Do you mean :
/* We need to use precomputed mask for such situation and such mask
can only be computed in compile-time known size modes. */
bool indices_fit_selector_p
= GET_MODE_BITSIZE (GET_MODE_INNER (vmode)) > 8 || known_lt (vec_len, 256);
if (!indices_fit_selector_p &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
Assignee|unassigned at
> Oh. I think it should be renamed into not_fit.
>
> Is this following make sense to you ?
>
> /* We need to use precomputed mask for such situation and such mask
> can only be computed in compile-time known size modes. */
> bool indices_not_fit_selector_p
> = maybe_ge (vec_len, 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112994
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
--- Comment #6 from Jakub Jelinek ---
And another testcase which ICEs:
unsigned _BitInt(495) f1 (signed _BitInt(381) x) { unsigned _BitInt(539) y = x;
return y; }
unsigned _BitInt(495) f2 (unsigned _BitInt(381) x) { unsigned _BitInt(539) y =
x;
Oh. I think it should be renamed into not_fit.
Is this following make sense to you ?
/* We need to use precomputed mask for such situation and such mask
can only be computed in compile-time known size modes. */
bool indices_not_fit_selector_p
= maybe_ge (vec_len, 2 <<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> See also https://stackoverflow.com/a/77515095/981959
And my comment there:
This seems like a bug in winpthreads. The INITIALIZER macro should not exist if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857
--- Comment #2 from Jonathan Wakely ---
See also https://stackoverflow.com/a/77515095/981959
Do you mean like this ?
/* We need to use precomputed mask for such situation and such mask
can only be computed in compile-time known size modes. */
bool indices_fit_selector_p
= maybe_ge (vec_len, 2 << GET_MODE_BITSIZE (GET_MODE_INNER (vmode)));
if (GET_MODE_BITSIZE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113022
--- Comment #1 from Andrew Stubbs ---
This is what I get for trying to get this done before vacation. :(
Yes, there's probably something in mkoffload that has to match the default
change from -mxnack=any to -mxnack=off on the older ISAs.
On 12/15/23 13:16, juzhe.zh...@rivai.ai wrote:
>
>>> bool indices_fit_selector = maybe_ge (vec_len, 2 << GET_MODE_BITSIZE
>>> (GET_MODE_INNER (vmode)));
> No, I think it will make us miss some optimization.
>
> For example, for poly value [16,16] maybe_ge ([16,16], 65536) which makes us
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111917
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110116
Bug 110116 depends on bug 111614, which changed state.
Bug 111614 Summary: [11 Regression] ICE at -O2: verify_gimple failed since
r14-2282-gf703d2fd3f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614
Richard Biener changed:
What|Removed |Added
Known to work||11.4.1
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764
Richard Biener changed:
What|Removed |Added
Known to fail||11.4.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111818
Richard Biener changed:
What|Removed |Added
Known to fail||11.4.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182
Richard Biener changed:
What|Removed |Added
Known to fail||11.4.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295
Richard Biener changed:
What|Removed |Added
Known to fail||11.4.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111917
--- Comment #11 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:ec8d0c33211c5e92c220483d6fe9f0a2391d2d6d
commit r11-11145-gec8d0c33211c5e92c220483d6fe9f0a2391d2d6d
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614
--- Comment #7 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:03b5888abc9fe9a81df77125a8d4975ab8695c8c
commit r11-11144-g03b5888abc9fe9a81df77125a8d4975ab8695c8c
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764
--- Comment #11 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:7473b2742aa1637d14a64505e855aa09452536b1
commit r11-11143-g7473b2742aa1637d14a64505e855aa09452536b1
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111818
--- Comment #7 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:45c296f2d81f6259e268e07707b4aa87dffba20a
commit r11-11142-g45c296f2d81f6259e268e07707b4aa87dffba20a
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295
--- Comment #9 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:01f088741bec84f8fa86f87fdb73db07d5febb0a
commit r11-11140-g01f088741bec84f8fa86f87fdb73db07d5febb0a
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298
--- Comment #9 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:0e332ee568739448a9439c7074d2a29badba60f2
commit r11-11141-g0e332ee568739448a9439c7074d2a29badba60f2
Author: Richard
>> bool indices_fit_selector = maybe_ge (vec_len, 2 << GET_MODE_BITSIZE
>> (GET_MODE_INNER (vmode)));
No, I think it will make us miss some optimization.
For example, for poly value [16,16] maybe_ge ([16,16], 65536) which makes us
missed merge optimization but
we definitely can do merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857
--- Comment #1 from Jonathan Wakely ---
Could you please run this and paste the output here?
#include
#include
#include
#include
#include
unsigned long
muh_handles()
{
unsigned long n = 0;
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113030
--- Comment #4 from Richard Earnshaw ---
Yes, that looks sensible. Can you post it please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #41 from Richard Biener ---
(In reply to Mathieu Malaterre from comment #40)
> (In reply to Richard Biener from comment #39)
> > (In reply to Kewen Lin from comment #38)
> > > I found this has been marked as resolved but it seems
On 2023/12/14 23:50, Richard Earnshaw (lists) wrote:
On 09/12/2023 15:39, Lipeng Zhu wrote:
This patch try to introduce the rwlock and split the read/write to
unit_root tree and unit_cache with rwlock instead of the mutex to
increase CPU efficiency. In the get_gfc_unit function, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #40 from Mathieu Malaterre ---
(In reply to Richard Biener from comment #39)
> (In reply to Kewen Lin from comment #38)
> > I found this has been marked as resolved but it seems that the patch in
> > comment #34 hasn't been pushed,
The following avoids creating a niter peeling epilog more consistently,
matching what peeling later uses for the skip_vector condition, in
particular when versioning is required which then also ensures the
vector loop is entered unless the epilog is vectorized. This should
ideally match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71093
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031
--- Comment #1 from Jonathan Wakely ---
Created attachment 56884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56884=edit
Gzipped preprocessed source
Compile the attached .ii with '-std=gnu++20 -O' (or any non-zero optimization
level)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031
Bug ID: 113031
Summary: [14 Regression] ICE in cxx_fold_indirect_ref_1
starting with r14-6508
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
Hi Juzhe,
in general looks OK.
> + /* We need to use precomputed mask for such situation and such mask
> + can only be computed in compile-time known size modes. */
> + if (GET_MODE_BITSIZE (GET_MODE_INNER (vmode)) == 8 && maybe_ge (vec_len,
> 256)
> + && !vec_len.is_constant ())
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
--- Comment #5 from Jakub Jelinek ---
Testcase covering various cases where 2 consecutive casts can't be optimized
away.
This ICEs in multiple ways as well:
void
f1 (_BitInt(4096) *p, int r, _BitInt(115) s, _BitInt(128) t, _BitInt(231) u)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113021
--- Comment #3 from Miro Palmu ---
Here is even more reduced. Notice that if the unused data member `pointer` is
removed from `vec` the problem goes away. Same with data member `a` in struct
`A`.
```
struct vec {
int data;
int*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113021
--- Comment #2 from Miro Palmu ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. We should reduce this to remove the include file too ...
Here is somewhat reduced:
```
#include
auto alloc = std::allocator{};
constexpr auto n = 3;
On Fri, 15 Dec 2023 at 01:17, Tim Song wrote:
>
> On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely wrote:
>> + inline void
>> + vprint_unicode(ostream& __os, string_view __fmt, format_args __args)
>> + {
>> +ostream::sentry __cerb(__os);
>> +if (__cerb)
>> + {
>> +
>> + const
On Thu, 14 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> Given what I saw in the aarch64/arm psABIs for BITINT_TYPE, as I said
> earlier I'm afraid we need to differentiate between the limb mode/precision
> specified in the psABIs (what is used to decide how it is actually passed,
> aligned or what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #39 from Richard Biener ---
(In reply to Kewen Lin from comment #38)
> I found this has been marked as resolved but it seems that the patch in
> comment #34 hasn't been pushed, is it intended? or did I miss something that
> one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
--- Comment #3 from Richard Biener ---
I do have a patch to avoid the epilog, but that doesn't help when adjusting the
testcase to
char dst[17];
void
foo (char *src, long n)
{
for (long i = 0; i < n; i++)
dst[i] = src[i];
}
because then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
--- Comment #4 from Jakub Jelinek ---
And after the PR113024 changes, one needs -O1 -fno-tree-forwprop on:
unsigned _BitInt(2049)
foo (unsigned _BitInt(6384) x, _BitInt(8) y)
{
unsigned _BitInt(6384) z = y;
return x * z;
}
_BitInt(2049)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #38 from Kewen Lin ---
I found this has been marked as resolved but it seems that the patch in comment
#34 hasn't been pushed, is it intended? or did I miss something that one commit
was pushed but wasn't associated to this PR?
Hi Jason!
I think you usually deal with these kind of GCC Git things? If not,
please let me know.
On 2023-10-26T10:21:18+0200, I wrote:
> First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2
> the "v2" libgrust changes as posted by Arthur, so that people can easily
> test this
Hi Jason!
I think you usually deal with these kind of GCC Git things? If not,
please let me know.
On 2023-10-26T10:21:18+0200, I wrote:
> First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2
> the "v2" libgrust changes as posted by Arthur, so that people can easily
> test this
Hi!
On 2023-12-13T08:14:28+, Di Zhao OS wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr110279-2.c
> @@ -0,0 +1,41 @@
> +/* PR tree-optimization/110279 */
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast --param tree-reassoc-width=4 --param
> fully-pipelined-fma=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112906
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112906
--- Comment #6 from GCC Commits ---
The master branch has been updated by Alex Coplan :
https://gcc.gnu.org/g:ef9754dfdf18a89de3da23c4f23365f4c2611367
commit r14-6583-gef9754dfdf18a89de3da23c4f23365f4c2611367
Author: Alex Coplan
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112906
--- Comment #5 from GCC Commits ---
The master branch has been updated by Alex Coplan :
https://gcc.gnu.org/g:bac33a522bb51e30729191e935f25c2b0a63e225
commit r14-6582-gbac33a522bb51e30729191e935f25c2b0a63e225
Author: Alex Coplan
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113003
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:330f1e078dae257d4f8f7b13299ececc2344e681
commit r14-6580-g330f1e078dae257d4f8f7b13299ececc2344e681
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113003
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d50d3d0a688e8dac31b307b3aad3fbc99283ebc4
commit r14-6579-gd50d3d0a688e8dac31b307b3aad3fbc99283ebc4
Author: Jakub Jelinek
Date:
We used a branch to load floating-point comparison results into GPR.
This is very slow when the branch is not predictable.
Implement movfcc so we can reload FCCmode into GPRs, FPRs, and MEM.
Then implement cstore4.
gcc/ChangeLog:
* config/loongarch/loongarch-tune.h
Hi,
PR112995 exposed one issue in current try_replace_dest_reg
that the result rtx insn after replace_dest_with_reg_in_expr
is probably unable to match any constraints. Although there
are some checks on the changes onto dest or src of orig_insn,
none is performed on the EXPR_INSN_RTX.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112999
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Gerald
---
htdocs/projects/cli.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/projects/cli.html b/htdocs/projects/cli.html
index 394832b6..47ddb362 100644
--- a/htdocs/projects/cli.html
+++ b/htdocs/projects/cli.html
@@ -460,7 +460,7 @@ allowing the user to
I pushed this obvious change.
Gerald
gcc:
* doc/install.texi (Specific) : Update nvptx-tools
Github link.
---
gcc/doc/install.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index c1128d9274c..fffad700af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113030
Andrew Pinski changed:
What|Removed |Added
Keywords||internal-improvement
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113030
--- Comment #2 from Andrew Pinski ---
Or rather there is a typo in the script.
This fixes the script's chkarch and chkcpu commands:
```
diff --git a/gcc/config/arm/parsecpu.awk b/gcc/config/arm/parsecpu.awk
index b827d71dded..fdc6e35a7ce 100644
Due to recent middle-end cost model changes, now we can do more VLA SLP.
Fix these following regressions:
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
XPASS:
On Fri, Dec 15, 2023 at 2:25 AM haochen.jiang
wrote:
>
> On Linux/x86_64,
>
> 8afdbcdd7abe1e3c7a81e07f34c256e7f2dbc652 is the first bad commit
> commit 8afdbcdd7abe1e3c7a81e07f34c256e7f2dbc652
> Author: Di Zhao
> Date: Fri Dec 15 03:22:32 2023 +0800
>
> Consider fully pipelined FMA in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113030
--- Comment #1 from Andrew Pinski ---
so I looked into config/arm/parsecpu.awk and yes it ignores aliases for chkarch
but I don't think that matters to the end user ...
101 - 187 of 187 matches
Mail list logo
