https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #1 from Tomasz Konojacki ---
(In reply to Tomasz Konojacki from comment #0)
> The error below occurs only with -Od.
Sorry, -Og.
PS. It seems that moving the definition of fun4 to the first line
makes the error disappear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
Bug ID: 107931
Summary: [12 Regression] -Od causes always_inline to fail
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103769
Andrew Pinski changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102739
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553
--- Comment #9 from Andrew Pinski ---
Full backtrace:
0x121ce0f crash_signal
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:314
0x14e5890 strip_array_types(tree_node*)
/home/apinski/src/upstream-gcc/gcc/gcc/tree.cc:7262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553
--- Comment #8 from Andrew Pinski ---
Reduced all the way:
struct s1{};
template inline constexpr s1 ch{};
template struct s2{};
template using alias1 = s2;
template
void general(int n)
{
alias1>{};
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102550
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #16 from Rama Malladi ---
(In reply to Wilco from comment #15)
> (In reply to Rama Malladi from comment #14)
> > This fix also improved performance of 538.imagick_r by 15%. Did you have a
> > similar observation? Thank you.
>
> No,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
--- Comment #5 from Jerry DeLisle ---
Except WARNING: program timed out.
FAIL: gfortran.dg/merge_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
--- Comment #4 from Jerry DeLisle ---
Pauls patch regression tests fine. Thanks Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107930
Bug ID: 107930
Summary: wchar_t may not be the native character type for
windows
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107929
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107929
Bug ID: 107929
Summary: std::experimental::simd needs to be reimplemented with
GCC's vector extension
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
--- Comment #11 from Andrew Pinski ---
(In reply to piliu from comment #10)
> (In reply to Andrew Pinski from comment #7)
> > I am trying to understand this. Is it ok to use the SSE registers inside
> > purgatory or not?
> >
>
> SSE can speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
--- Comment #10 from piliu at redhat dot com ---
(In reply to Andrew Pinski from comment #7)
> I am trying to understand this. Is it ok to use the SSE registers inside
> purgatory or not?
>
SSE can speed up the program, and if possible it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107926
--- Comment #3 from Andrew Pinski ---
Note we reference char array still with:
unsigned short s[5] = {u"abc",1};
__WCHAR_TYPE__ s1[5] = {L"abc", 1};
But I also notice clang does too so maybe it is not so bad ...
Just for reference the C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107928
Bug ID: 107928
Summary: ICE in on_bind, at analyzer/sm-fd.cc:1869
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107927
Bug ID: 107927
Summary: vector::push_back gives array bounds warning with
optimization and undefined sanitizer
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107926
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801
--- Comment #16 from Jonathan Wakely ---
Already fixed on trunk, see g:a7b97a1f6b9d4993545525fd5cb334ae640ddf45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107926
Andrew Pinski changed:
What|Removed |Added
Known to fail||12.1.0, 4.1.2
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107926
Bug ID: 107926
Summary: wrong error message for excess elements in array
initializer using a string literal
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103546
--- Comment #7 from David Malcolm ---
As it notes, the above patch reduces the number of false positives on
flex-generated scanners, but doesn't fix them all. Keeping this bug open to
track fixing them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105784
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103546
--- Comment #6 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:78a17f4452db9514da7cc8706c654cb98ba0a8e6
commit r13-4399-g78a17f4452db9514da7cc8706c654cb98ba0a8e6
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105784
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:3a32fb2eaa761aac13ffe5424748d5839038ef66
commit r13-4398-g3a32fb2eaa761aac13ffe5424748d5839038ef66
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801
--- Comment #15 from Jan Dubiec ---
I have applied the patch manually to 12.2 tree and this time got following
error message:
/bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile
/d/Works/xcomp/gcc-build/./gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |12.3
--- Comment #6 from Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:000e9863120cbc75a0f8d497264519974c97669f
commit r13-4397-g000e9863120cbc75a0f8d497264519974c97669f
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #4 from Andrew Pinski ---
Maybe related to r8-4520-g1bad9c1806ac51 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #2 from Martin Liška ---
Created attachment 53987
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53987=edit
gcda file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #1 from Martin Liška ---
Created attachment 53986
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53986=edit
test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
Bug ID: 107925
Summary: ICE in update_specialized_profile at
gcc/ipa-cp.cc:5082 for 531.deepsjeng_r benchmark
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
--- Comment #8 from Andrew Pinski ---
There is another question, how does this folding interact with
-fnon-call-exceptions and is it still correct?
E.g. compile at -O1 -march=armv8-a+sve2 -fnon-call-exceptions:
#include "arm_sve.h"
svint8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
--- Comment #7 from Andrew Pinski ---
Something like this should fix the issue (note setting the location should be
done also):
diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107922
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=107920
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107627
--- Comment #6 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #5)
> On the other side, split_double_concat needs to take into account when the
> destination
> and/or source are MEMs and some registers are used in their
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
--- Comment #5 from Andrew Pinski ---
Note I tried with (same options):
void
f (void)
{
int t = 16;
int t1 = 4;
int t2 = 8;
int t3 = 0;
__builtin_aarch64_im_lane_boundsi (t, t1, t3);
}
But since we are removing the vdef via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107905
--- Comment #4 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #3)
> LLVM does a better job at code layout, and massively wins on the amount of
> executed branches (in particular unconditional jumps). With
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107905
Alexander Monakov changed:
What|Removed |Added
Keywords|ra |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Which was added by r13-1055-g494bec025002df .
>
> The question becomes is gimple folding allowed to add MEM references here or
> not?
No other target (or even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107627
--- Comment #5 from Jakub Jelinek ---
(In reply to Roger Sayle from comment #4)
> Perhaps:
> (define_insn_and_split "*concat3_1"
> [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r")
> (any_or_plus:
> (ashift:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846
--- Comment #10 from James Hilliard ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to James Hilliard from comment #7)
> > (In reply to Jakub Jelinek from comment #6)
> > > Created attachment 53984 [details]
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846
--- Comment #9 from Andrew Pinski ---
(In reply to James Hilliard from comment #7)
> This appears to fix error, the warning is still present:
> progs/test_tc_tunnel.c: In function '__encap_ipv4':
> progs/test_tc_tunnel.c:228:31: warning: taking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899
--- Comment #3 from joseph at codesourcery dot com ---
C2x provides type-generic versions of various such operations,
in addition to type-specific versions (but the type-specific versions are
for unsigned char through unsigned long long, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846
--- Comment #8 from Jakub Jelinek ---
(In reply to James Hilliard from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Created attachment 53984 [details]
> > gcc13-pr107846.patch
> >
> > Untested fix.
>
> This appears to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846
--- Comment #7 from James Hilliard ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 53984 [details]
> gcc13-pr107846.patch
>
> Untested fix.
This appears to fix error, the warning is still present:
progs/test_tc_tunnel.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104546
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> It is specifically svld1rq_s8 folding into:
> # VUSE <.MEM>
> _5 = MEM [(signed char * {ref-all})x_3(D)];
>
>
> Which is done by svld1rq_impl::fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
--- Comment #2 from Andrew Pinski ---
It is specifically svld1rq_s8 folding into:
# VUSE <.MEM>
_5 = MEM [(signed char * {ref-all})x_3(D)];
Which is done by svld1rq_impl::fold (aarch64-sve-builtins-base.cc:1214).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #10 from Charles-Henri Gros ---
I'd be happy with any algorithm that meets my needs, though the presence of a
different algorithm that does the same thing that the existing algorithm
currently does, or at least subsumes all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105746
--- Comment #4 from Jonathan Wakely ---
(In reply to Richard Biener from comment #3)
> Fixed by r13-4393-gcca06f0d6d76b0 on trunk?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105823
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105746
Richard Biener changed:
What|Removed |Added
Known to work||13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106149
Richard Biener changed:
What|Removed |Added
Target|powerpc64-linux-gnu |powerpc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107004
Richard Biener changed:
What|Removed |Added
Known to fail|13.0|
Summary|[12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #7 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:3832c6f7e672e76bba74a508bf3a49740ea38046
commit r13-4394-g3832c6f7e672e76bba74a508bf3a49740ea38046
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105918
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #1)
> Shorter testcase (still need to reduce it futher):
> #include
> void toChars(int number) {
> char temp[1];
> std::to_chars(temp, temp + 1, number);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107924
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 107924, which changed state.
Bug 107924 Summary: ICE in trees_out::tree_node with fsanitize=undefined and
modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107924
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98735
Andrew Pinski changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107924
Bug ID: 107924
Summary: ICE in tree_node, at cp/module.cc:9260
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #8 from Carlos Galvez ---
I see!
In that case may I suggest to split the diagnostic into "Warray-bounds" and
"Wmaybe-array-bounds"? That way we could enable the first and disable the
second. The way it is today, we need to disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107923
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107923
Bug ID: 107923
Summary: ICE in lookup_function_fuzzy_find_candidates /
check_interface0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #7 from rguenther at suse dot de ---
On Tue, 29 Nov 2022, carlosgalvezp at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
>
> --- Comment #5 from Carlos Galvez ---
> > is not good programming practice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107922
Bug ID: 107922
Summary: ICE in gfc_simplify_unpack, at
fortran/simplify.cc:8473
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107921
Bug ID: 107921
Summary: Overflow warnings in libsupc++/hash_bytes.cc for
msp430-elf -mlarge
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
--- Comment #10 from Jonathan Wakely ---
(In reply to Marco Clemencic from comment #8)
> But the warning is not issued in -O0 builds, which I believe means the code
> is correct by itself,
That's not a valid assumption. -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
commit r13-4393-gcca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
commit r13-4393-gcca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
commit r13-4393-gcca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
Bug ID: 107920
Summary: [13 Regression] ICE in execute_todo, at passes.cc:2140
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #10 from Jonathan Wakely ---
With that compiler patch for the missed-optimization one of the two bogus
warnings goes away. The second one goes away with this change:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919
--- Comment #1 from Freddie Chopin ---
More possibly imporant notes:
1. The warning appears only with -O1 or -O2, with 0, s, g or 3 the warning is
gone.
2. Adding -fsanitize=undefined to compiler invocation makes the warning go away
as well -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106363
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107918
Cameron changed:
What|Removed |Added
CC||dacamara.cameron at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #9 from Jonathan Wakely ---
The problem with side effects is not that they happen more than once, but that
they happen at all. The algorithm is called "erase_if" so it's surprising if it
actually mutates the remaining elements,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919
Bug ID: 107919
Summary: Possibly false-positive "maybe-uninitialized" with GCC
12 on complex variant-variant-tuple-unique_ptr types
Product: gcc
Version: 12.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107918
--- Comment #1 from Andrew Pinski ---
/* Ambiguity between normal and reversed comparison operators
with the same parameter types. P2468 decided not to go with
this approach to resolving the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #8 from Charles-Henri Gros ---
Thanks for all the comments. I agree that for consistency this should be
rejected, though my preference would still be to make remove_if/erase_if more
useful in practical cases (this happens dozens of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107918
Bug ID: 107918
Summary: P2468R2 and operator ambiguity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
--- Comment #15 from Jonathan Wakely ---
*** Bug 106199 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107910
--- Comment #1 from Andrew Pinski ---
The problem is an interaction between the SLP vectorizer and store merging.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107911
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107912
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107916
--- Comment #4 from Andrew Pinski ---
Reduced even further just compile with `-O2 -mvsx` is enough to show the issue
really:
```
typedef unsigned u32x8 __attribute__ ((vector_size (32)));
void f(int n, u32x8 *a, u32x8 *b)
{
u32x8 c = {0};
1 - 100 of 170 matches
Mail list logo
