https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:50374fdacbd121bc4a61b073e559208ff61bee06
commit r12-1765-g50374fdacbd121bc4a61b073e559208ff61bee06
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
--- Comment #6 from Uroš Bizjak ---
(In reply to Richard Biener from comment #5)
> Of course I wonder why the RA even chooses registers that are not available
> on the architecture. I suppose there's no real way to turn regs on/off but
> the wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101173
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=101061
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Summary|[11/12 Regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
--- Comment #7 from Hongtao.liu ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105
Richard Biener changed:
What|Removed |Added
Known to work||7.5.0
--- Comment #8 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #22 from Martin Liška ---
> For example, if an inlining pass happens after instrumentation, then the
> function attribute doesn't necessarily need to suppress inlining. After
> instrumentation is done, we can even treat the noprofile
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
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
: 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=101190
Bug ID: 101190
Summary: vectorizer failed to vectorize generate vashlv8hi, but
use vashlv4si and extend.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severit
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=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
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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=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=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=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=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 #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=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=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=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=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=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
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12 Regression] ICE |[11 Regression] ICE
|
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=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=101190
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-06-24
Keywords|
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=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=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=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
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at g
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=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=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=101194
Bug ID: 101194
Summary: 7.2 Regression
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassign
-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=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
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=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
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
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=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=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=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=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=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=101134
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
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
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=101186
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
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=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=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=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=91911
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
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
CC||juergen.reiss at gmx dot de
--- Comment
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||cadet.gabriel at gmail dot com
--- Comme
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=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=101134
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
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=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=101189
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
Keywords|
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=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=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=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
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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
: 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=92105
Jeremy R. changed:
What|Removed |Added
CC||llvm at rifkin dot dev
--- Comment #6 from J
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=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=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=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=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=91085
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment #
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=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=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=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=100952
--- Comment #7 from HaoChen Gui ---
PASS: gfortran.dg/parity_1.f90 -O0 execution test
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=101195
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
Ever confirmed|0
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=101202
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-06-25
Version|unknown
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=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
1 - 100 of 108 matches
Mail list logo
