https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101196
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-06-25
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202
--- Comment #3 from Richard Biener ---
So we still have failed backedge destinations in the SLP graph, those have
vect_uninitialized_def and the
- /* For leafs there's nothing to do - we've seeded permutes
-on those above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101203
--- Comment #2 from Jonathan Wakely ---
We also can't guarantee that the address of the new function is unique across
shared libraries, making the test in _M_equal unreliable. The technique in
std::any has a fallback to using RTTI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101190
--- Comment #2 from Hongtao.liu ---
(In reply to Richard Biener from comment #1)
> the issue is that likely (is that prerequesite patch in yet?)
> vect_recog_over_widening_pattern is not detecting that the shift could be
> done in smaller than i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101203
--- Comment #1 from Jonathan Wakely ---
PR 56551 uses a similar idea. It wouldn't be ABI compatible with existing code
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-06-25
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101195
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194
Richard Biener changed:
What|Removed |Added
Component|c++ |libstdc++
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #7 from HaoChen Gui ---
PASS: gfortran.dg/parity_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #6 from HaoChen Gui ---
Seurer,
Could you provide detail info about test? Such as config and build option. I
tested the build on P10 and no failure on parity_1.f90. Thanks.
PASS: gfortran.dg/parity_1.f90 -O0 (test for excess err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
--- Comment #2 from ygal klein ---
The problem also persists in an example code that is with no extended type:
```fortran
module mod_original_struct
implicit none
private
public :: original_struct
type original_struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
--- Comment #1 from ygal klein ---
The problem stays for even a smaller example program:
``` fortran
module mod_original_struct
implicit none
private
public :: extended_struct
type original_struct
private
real,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101203
Bug ID: 101203
Summary: Remove unnecessary empty check in std::function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101079
--- Comment #4 from xiao@compiler-dev.com ---
(In reply to Jakub Jelinek from comment #1)
> Under discussions in OpenMP language committee, but the latest proposal is
> that this is invalid, you need to increment the linear variable by
> lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #4 from bin cheng ---
(In reply to Jiu Fu Guo from comment #3)
> Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky:
>
> /* Only support simple cases for the moment. */
> if (TREE_CODE (iv0->base) != IN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #3 from Jiu Fu Guo ---
Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky:
/* Only support simple cases for the moment. */
if (TREE_CODE (iv0->base) != INTEGER_CST
|| TREE_CODE (iv1->base) != INTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
--- Comment #14 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:980e278dbe5b50dc5a856ea627359c521f1cda53
commit r12-1800-g980e278dbe5b50dc5a856ea627359c521f1cda53
Author: liuhongt
Date: Thu Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #13 from Giuseppe D'Angelo ---
Hi,
(In reply to Martin Sebor from comment #12)
> So in general, the distinction between the two cases can only be made when
> it can be discerned from the IL, and the IL doesn't always preserve the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92105
Jeremy R. changed:
What|Removed |Added
CC||llvm at rifkin dot dev
--- Comment #6 from J
: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210624 (experimental) [master revision
a0accaa9984:cc7f2982315:ce3316e9c02c81c509173572c71a101f4eb62a24] (GCC)
[530] %
[530] % gcctk -O2 small.c; ./a.out
[531] %
[531] % gcctk -O3 small.c
during GIMPLE pass: slp
small.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #12 from Martin Sebor ---
I don't need to be convinced that it would be nice to be able to differentiate
between certain bugs and possible ones. The text of this class of warnings
already does differentiate between "may write/read/a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101114
--- Comment #2 from seurer at gcc dot gnu.org ---
To be complete this shows up as two failures:
FAIL: libgomp.c++/../libgomp.c-c++-common/struct-elem-5.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/struct-elem-5.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
--- Comment #2 from Andrew Pinski ---
Note the tree level looks decent:
a_6 = d.0_1 >> 4;
f_7 = d.0_1 & 15;
_2 = (int) f_7;
_3 = (int) a_6;
_4 = c.b[_2];
c.b[_3] = _4;
Which gets expanded (for c.b[_3] and dependents) into:
(insn 5 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #5 from seurer at gcc dot gnu.org ---
*** Bug 101201 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101201
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101201
Bug ID: 101201
Summary: [12 regression] test case gcc.target/powerpc/pr56605.c
fails on BE after r12-1202
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
Bug ID: 101200
Summary: Unneeded AND after shift
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:a0accaa99844b0c40661202635859f8c0be76cdd
commit r12-1797-ga0accaa99844b0c40661202635859f8c0be76cdd
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
Bug ID: 101199
Summary: program changes the value of a dummy argument
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101198
--- Comment #2 from Jonathan Wakely ---
I think this will fix it:
--- a/libstdc++-v3/doc/xml/manual/test_policy_data_structures.xml
+++ b/libstdc++-v3/doc/xml/manual/test_policy_data_structures.xml
@@ -105,6 +105,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101198
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-06-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91911
Patrick Palka changed:
What|Removed |Added
CC||cadet.gabriel at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100723
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91911
Patrick Palka changed:
What|Removed |Added
CC||juergen.reiss at gmx dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98077
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91911
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #23 from Nick Desaulniers ---
(In reply to Fangrui Song from comment #18)
> I
> think a similar topic may need to be raided on llvm-dev side as I feel this
> is the tip of the iceberg - more attributes can be similarly leveraged. So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189
--- Comment #2 from Andrew Macleod ---
We always register relations on outgoing edges from a conditional.
in this case
_2 = -f_6; // f_6 was known to be [4,5]
if (_2 == f_6) // This this was known to fail because _2 was [-5, -4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101198
Bug ID: 101198
Summary: libstdc++-v3/doc/html/manual/policy_based_data_structu
res_test.html is not valid XHTML; fails DTD validation
Product: gcc
Version: 12.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101195
Andrew Pinski changed:
What|Removed |Added
Version|tree-ssa|12.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98832
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:c761be53f6b62e22ac5de18c4aaf88648f64f5b7
commit r12-1793-gc761be53f6b62e22ac5de18c4aaf88648f64f5b7
Author: Patrick Palka
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #2 from bin cheng ---
(In reply to Richard Biener from comment #1)
> This comes up with a pending patch to split loops like
>
> void
> foo (int *a, int *b, unsigned l, unsigned n)
> {
> while (++l != n)
> a[l] = b[l] + 1;
> }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101182
--- Comment #1 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:c06493dc30afbf65b14d783c7cd53f20877ef577
commit r12-1792-gc06493dc30afbf65b14d783c7cd53f20877ef577
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
Bug ID: 101197
Summary: __builtin_memmove does not perform constant
optimizations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98832
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #8 from Giuseppe D'Angelo ---
In a -Wall build, it's a bit unfair to pretend the users to know if a warning
is being generated by the frontend, the middleend, the backend and so on. All
they get is a list of warnings saying "this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101176
--- Comment #3 from Jakub Jelinek ---
Fixed on the trunk so far. Guess it needs fixing in 9/10/11 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101171
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101176
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:178fb8df9315f2f8f45b7fe5faf11a9c2912cc28
commit r12-1791-g178fb8df9315f2f8f45b7fe5faf11a9c2912cc28
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101171
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fdc5522fb04b4a820b28c4d1f16f54897f5978de
commit r12-1790-gfdc5522fb04b4a820b28c4d1f16f54897f5978de
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101196
Bug ID: 101196
Summary: [12 Regression] ICE: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in
useless_type_conversion_p
Product: gcc
Version
-gnu
Configured with: /tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210624 (experimental
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194
Bug ID: 101194
Summary: 7.2 Regression
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89021
--- Comment #59 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:836328b2c99f5b8d45dcca5797f162af322e74da
commit r12-1789-g836328b2c99f5b8d45dcca5797f162af322e74da
Author: Uros Bizjak
Date: Thu J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101193
Bug ID: 101193
Summary: [GCOV] Bit operation leads to wrong coverage
information
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80504
--- Comment #5 from Jonathan Wakely ---
Huh, what I actually committed doesn't match the changelog. Oops.
But what I committed is better anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328
--- Comment #3 from Kewen Lin ---
(In reply to Vladimir Makarov from comment #2)
> (In reply to Kewen Lin from comment #1)
> > Created attachment 50715 [details]
> > ira:consider matching cstr in all alternatives
> >
> > With little understandi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101192
Bug ID: 101192
Summary: [GCOV] The coverage of a callee function goes wrong.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
--- Comment #4 from Stefan Schulze Frielinghaus
---
(In reply to Martin Jambor from comment #3)
> I have proposed a fix on the mailing list:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573338.html
I gave it a try on IBM Z where the t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101190
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-06-24
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163
--- Comment #6 from Jakub Jelinek ---
Yes, the C++ FE has quadratic behavior here:
#define A(n) int f##n;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101170
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101172
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12 Regression] ICE |[11 Regression] ICE
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101170
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9872bd8c35be0f4d475fac739115cf5b82cdabc0
commit r12-1772-g9872bd8c35be0f4d475fac739115cf5b82cdabc0
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101172
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:65371066d8967560e3508af4a804e0ddb90acee7
commit r12-1771-g65371066d8967560e3508af4a804e0ddb90acee7
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163
--- Comment #5 from René Bürgel ---
Do I get that right, that this procedure is done for *every* member when adding
it?
So, this would make it basically quadratic...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187
--- Comment #4 from Jakub Jelinek ---
To make sure we diagnose it and catch it in ubsan and FE constant expression
folding. The folding of the shift count into constant can happen almost any
time during the optimizations.
For ubsan and FE const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187
--- Comment #3 from rguenther at suse dot de ---
On Thu, 24 Jun 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
--- Comment #12 from Richard Biener ---
(In reply to Hongtao.liu from comment #7)
> The key point here is cpuid check function should not be compiled with
> -mavx512vl or -mavx512bw, rely on cost model or alloca order is not
> all-inclusive.
Ye
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |12.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
--- Comment #11 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to Hongtao.liu from comment #9)
> > (In reply to Jakub Jelinek from comment #8)
> > > Yeah, ideally main including the cpuid check should be compiled wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
--- Comment #10 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Yeah, ideally main including the cpuid check should be compiled with the
> > least possible target and if the check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186
--- Comment #2 from Di Zhao ---
(In reply to Richard Biener from comment #1)
> The complication is that the a == b equivalence has to be taken into account
> to relate the c < a and c >= b relations.
>
> Maybe the new relation code can do sth h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101191
Bug ID: 101191
Summary: [GCOV] Wrong coverage with "for(;;)" statement
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
--- Comment #9 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #8)
> Yeah, ideally main including the cpuid check should be compiled with the
> least possible target and if the check is successful call a noipa function
> with the co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #20 from YunQiang Su ---
(In reply to Andrew Pinski from comment #15)
> (In reply to YunQiang Su from comment #14)
> > The problem sees due to some problem of LTO.
>
> So I if understand correctly this binutils patch is fixes the iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #19 from YunQiang Su ---
It is a bug of binutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=28009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101190
Bug ID: 101190
Summary: vectorizer failed to vectorize generate vashlv8hi, but
use vashlv4si and extend.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severit
: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210624 (experimental) [master revision
fcf617f0d2a:8f55dced666:3bd86940c428de9dde53e41265fb1435ed236f5e] (GCC)
[536] %
[536] % gcctk -O1 small.c; ./a.out
[537] %
[537] % gcctk -Os small.c
during GIMPLE pass: evrp
small.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101178
--- Comment #1 from Richard Biener ---
Another case:
double a[2], b[2], c[2];
void foo ()
{
double tem0 = a[1] + b[1];
double tem1 = a[0] - b[0];
c[0] = tem0;
c[1] = tem1;
}
here the addsub VEC_PERM merge node has wrong order (+, - in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Bug ID: 101188
Summary: [AVR] Miscompilation and function pointers
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
1 - 100 of 108 matches
Mail list logo
