https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102118
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078
--- Comment #3 from Jakub Jelinek ---
Actually no, it is in libada and built only for VxWorks, maybe it is built with
C rather than C++. In that case it would indeed be UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102121
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68050
--- Comment #3 from Richard Biener ---
We don't really do it as you show - instead of
vect__5.7_12 = vect__1.5_14 + { -3.0e+0, -3.0e+0 };
vect__2.6_13 = vect__1.5_14 + { 3.0e+0, 3.0e+0 };
_7 = VEC_PERM_EXPR ;
we'd like to see
_7 = vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102102
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098
Pilar Latiesa changed:
What|Removed |Added
CC||pilarlatiesa at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2018-04-24 00:00:00 |2021-8-30
Component|tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2009-04-22 21:49:30 |2021-8-30
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102031
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83636
--- Comment #3 from CVS Commits ---
The master branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:d7e56b084d0b230ae5ee280f569d679fa0f09f4d
commit r12-3219-gd7e56b084d0b230ae5ee280f569d679fa0f09f4d
Author: YunQiang Su
Date: Sat Au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124
Bug ID: 102124
Summary: GCC 11.2.1 -ftree-loop-vectorize Causing Data To Lose
Sign Bit
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124
--- Comment #1 from Tomas Chang ---
Test Program is as below:
#include
#include
#include
typedef uint8_t byte;
int buf_eq_const(const void *_a, const void *_b, size_t len)
{
const byte *a = _a;
const byte *b = _b;
int ab, ba;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125
Bug ID: 102125
Summary: (ARM Cortex-M3 and newer) missed optimization. memcpy
not needed operations
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098
Martin Liška changed:
What|Removed |Added
Summary|ICE when #include |ICE when #include
| wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125
--- Comment #1 from Piotr ---
IMO it is quite important as `memcpy` type punning is considered as the safest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124
--- Comment #3 from Jakub Jelinek ---
Before vectorization the loop body is:
_1 = a_19(D) + i_29;
_2 = *_1;
_3 = (int) _2;
_4 = b_20(D) + i_29;
_5 = *_4;
_6 = (int) _5;
_7 = _3 - _6;
ab_21 = _7 | ab_25;
_10 = _6 - _3;
ba_22 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
Bug ID: 102126
Summary: Wrong optimization of multiplication by 1 and -1 with
-ftrapping-math when an underflow is possible
Product: gcc
Version: 11.2.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
--- Comment #11 from Martin Jambor ---
(In reply to Andrew Pinski from comment #10)
> Even LLVM does this same thing.
What do you mean by "does this same thing?" Does it copy the structure
element-wise or does it copy it is a block like GCC does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
Bug ID: 102127
Summary: [12 Regression] ICE when compiling
powerpc/440-mulchw-1.c
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #1 from Vincent Lefèvre ---
Division by 1 and -1 is affected too (as being equivalent to multiplication).
Note that F.9.2 "Expression transformations" in ISO C17 says:
1 × x and x/1 → x The expressions 1 × x, x/1, and x are e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
Iain Sandoe changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124
--- Comment #4 from Tomas Chang ---
(In reply to Jakub Jelinek from comment #3)
> Before vectorization the loop body is:
> _1 = a_19(D) + i_29;
> _2 = *_1;
> _3 = (int) _2;
> _4 = b_20(D) + i_29;
> _5 = *_4;
> _6 = (int) _5;
> _7 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #2 from Vincent Lefèvre ---
In the testcase, I forgot
#pragma STDC FP_CONTRACT OFF
Anyway, it is currently ignored by GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
Martin Liška changed:
What|Removed |Added
Summary|[12 Regression] ICE when|[12 Regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128
Bug ID: 102128
Summary: [12 Regression] Huge performance drop for 519.lbm_r
since
r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128
--- Comment #1 from Martin Liška ---
Created attachment 51375
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51375&action=edit
Optimized dump on znver3 - bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128
--- Comment #2 from Martin Liška ---
Created attachment 51376
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51376&action=edit
Optimized dump on znver3 - good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124
--- Comment #5 from Jakub Jelinek ---
I think the bug is in vect_recog_widen_op_pattern.
When we have half_type unsigned, for PLUS_EXPR, MULT_EXPR (and supposedly
LSHIFT_EXPR) it is ok that itype is twice the precision and same sign as
half_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #12 from CVS Commits ---
The releases/gcc-11 branch has been updated by Segher Boessenkool
:
https://gcc.gnu.org/g:c27080718d480ef08986b9224c0d146b75791c25
commit r11-8941-gc27080718d480ef08986b9224c0d146b75791c25
Author: Haochen G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128
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=102124
--- Comment #6 from Jakub Jelinek ---
Created attachment 51377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51377&action=edit
gcc12-pr102124.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #7 from Rimvydas (RJ) ---
The suggested removal of -fdefault-real-8 -fdefault-double-8 options would be
very problematic for many climate modeling libraries where similar '-r8' option
works as users expect in different compilers: pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #8 from Rimvydas (RJ) ---
If we can agree that use of -fdefault-real-8 -fdefault-double-8 with -flto does
not magically recompile intrinsic subroutines in runtime libgfortran.so
library, it looks like it is a frontend issue not provi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
--- Comment #13 from Rimvydas (RJ) ---
I agree that it is preferred to rewrite such look up table initialization,
however it is not always possible due to licensing restrictions preventing
making local modifications to the source code provided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128
--- Comment #4 from Richard Biener ---
I see now extra .REDUC_PLUS vectorized likely because of that. I'm testing sth
to keep the separate subgraph costing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
Richard Biener changed:
What|Removed |Added
Version|10.2.1 |12.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #3 from Richard Biener ---
(In reply to Vincent Lefèvre from comment #2)
> In the testcase, I forgot
>
> #pragma STDC FP_CONTRACT OFF
>
> Anyway, it is currently ignored by GCC.
You can use -ffp-contract=off but I don't think thes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #13)
> I agree that it is preferred to rewrite such look up table initialization,
> however it is not always possible due to licensing restrictions preventi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125
Richard Biener changed:
What|Removed |Added
Component|c |target
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56985
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=102128
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:89f33f44addbf9853bc3e6677db1fa941713cb6c
commit r12-3222-g89f33f44addbf9853bc3e6677db1fa941713cb6c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 102128, which changed state.
Bug 102128 Summary: [12 Regression] Huge performance drop for 519.lbm_r since
r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100089
Bug 100089 depends on bug 102128, which changed state.
Bug 102128 Summary: [12 Regression] Huge performance drop for 519.lbm_r since
r12-3116-g9216ee6d1195d48388f825cf1b072e570129cbbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #3 from Bill Schmidt ---
Also reported for AIX over the weekend. Seems to occur on all BE targets.
I'll try to look at this later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #4 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #3)
> You can use -ffp-contract=off but I don't think these transforms are
> affected.
I confirm that the test behaves in the same way with -ffp-contract=off too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #4 from Segher Boessenkool ---
Program received signal SIGSEGV, Segmentation fault.
0x10f9b10c in ._Z19build_function_typeP9tree_nodeS0_ ()
(gdb) bt
#0 0x10f9b10c in ._Z19build_function_typeP9tree_nodeS0_ ()
#1 0x00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #5 from Bill Schmidt ---
This will be similar to some other issues that arose in the past -- there are
function types that shouldn't be built when the type of an operand or return
value doesn't exist. I must have missed some such co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101144
Yaoxin Liu changed:
What|Removed |Added
CC||liuyaoxin1976 at qq dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129
Bug ID: 102129
Summary: -ftrapping-math is broken or badly documented
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #9 from Steve Kargl ---
On Mon, Aug 30, 2021 at 10:26:59AM +, rimvydas.jas at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
>
> --- Comment #7 from Rimvydas (RJ) ---
> The suggested removal of -fdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #8)
> If we can agree that use of -fdefault-real-8 -fdefault-double-8 with -flto
> does not magically recompile intrinsic subroutines in runtime libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #7)
At least some common examples of what to look for in
> documentation about "gfortran -fdefault-real-8 -fdefault-double-8"
> limitations (if these option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129
--- Comment #1 from Vincent Lefèvre ---
Additional surprising behavior...
On the following C code:
void g (void);
double f (void)
{
double x = 0.0, y = 0.0;
double r = x / y;
g ();
return r;
}
one can see with -ftrapping-math (the def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #12 from Rimvydas (RJ) ---
(In reply to kargl from comment #11)
> One of these is no like the others. Yes, the behavior is documented,
> and the unlike other result is likely the result that is no desired
> unless the user enjoys cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #13 from Steve Kargl ---
On Mon, Aug 30, 2021 at 03:23:59PM +, rimvydas.jas at gmail dot com wrote:
>
> > You need to use -fdefault-real-8 -fdefault-double-8 when compiling both
> > files. How is the 2nd invocation of gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
--- Comment #12 from Andrew Pinski ---
(In reply to Martin Jambor from comment #11)
> (In reply to Andrew Pinski from comment #10)
> > Even LLVM does this same thing.
>
> What do you mean by "does this same thing?" Does it copy the structure
> e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
--- Comment #5 from Paul Clarke ---
Fails with "-mcpu=power10" and "-O2" or "-O3".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078
--- Comment #4 from David Binderman ---
Full cppcheck error message is
gcc/ada/affinity.c:59:19: error: Signed integer overflow for expression
'1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102078
--- Comment #5 from Jakub Jelinek ---
index doesn't go to 32, just to 31.
And whether 1 << 31 or -1 << 31 etc. is or isn't UB heavily depends on the
language and standard version, C++20 and later accepts both, C89 and C++98 were
fuzzy, 1 << 31 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #6 from Bill Schmidt ---
OK, I see. This involves vector_pair_type_node and
vector_quad_type_node...which are not getting initialized because
TARGET_EXTRA_BUILTINS is false. This is a patch-ordering problem in the series
that I mis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #7 from Bill Schmidt ---
...by always initializing these types, not builtins...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102130
Bug ID: 102130
Summary: [c++filt] Stack overflow in demangle_path
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #14 from Rimvydas (RJ) ---
(In reply to Steve Kargl from comment #13)
> The -fdefault-* options change the storage association rules
> in a way that breaks Fortran. Places of concern include, but
> are not limited, to COMMON, EQUIVA
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210830 (experimental) [master revision
02dbf5d1273:023508d4548:d73c44800b53c7e130da29e4eff1960b8311ffcd] (GCC)
[595] %
[595] % gcctk -O0 small.c; ./a.out
[596] %
[596] % gcctk -O1 small.c
[597] % ./a.out
Aborted
[598] %
[598] % cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102132
Bug ID: 102132
Summary: [nm] Stack overflow in demangler_path
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #15 from Segher Boessenkool ---
This should be fixed now, please confirm. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #15 from Steve Kargl ---
On Mon, Aug 30, 2021 at 05:11:12PM +, rimvydas.jas at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
>
> --- Comment #14 from Rimvydas (RJ) ---
> (In reply to Steve Kargl fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101355
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133
Bug ID: 102133
Summary: [12 Regression] ICE in set_rtl building libgcc
__muldc3 for 32-bit SPARC
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101355
--- Comment #4 from Iain Sandoe ---
patch proposed here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578401.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #16 from Rimvydas (RJ) ---
(In reply to Steve Kargl from comment #15)
> I'm also the person that made these options work
> for some definition of "work", and I have always considered
> these options to be broken because of what you a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102113
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=102125
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101349
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=101327
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=102126
--- Comment #5 from joseph at codesourcery dot com ---
Exception traps (and thus exact underflow) are outside the scope of ISO C.
(Some forms of alternate exception handling are described in TS 18661-5,
which is *not* being integrated into C2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
Joseph S. Myers changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129
--- Comment #2 from joseph at codesourcery dot com ---
On Mon, 30 Aug 2021, vincent-gcc at vinc17 dot net via Gcc-bugs wrote:
> In the generated code with -O1 and above, one can see that the multiplication
> is done after g is called, even if -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30336
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #6 from joseph at codesourcery dot com ---
Issues relating to traps being enabled are still bugs (unlike e.g. any
issues with changing x87 rounding precision, which are definitely "don't
do that" when it invalidates assumptions mad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327
--- Comment #3 from Steve Kargl ---
On Mon, Aug 30, 2021 at 07:35:17PM +, anlauf at gcc dot gnu.org wrote:
>
> Steve,
>
> are you going to submit this or your version?
>
I no longer have the ability to commit changes,
so I won't being su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101349
--- Comment #3 from Steve Kargl ---
On Mon, Aug 30, 2021 at 07:31:17PM +, anlauf at gcc dot gnu.org wrote:
>
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> Steve,
>
> are you going to submit your patch?
>
I submitted the patch to
d model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210830 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102134
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102134
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #3)
> I no longer have the ability to commit changes,
> so I won't being submitting patches to fortran@
> and gcc-patches@ for review. I'll simply add
> patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:53907e20ee1fdf91163ff19b8f1dc716563e903a
commit r10-10081-g53907e20ee1fdf91163ff19b8f1dc716563e903a
Author: Paul Thomas
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:53907e20ee1fdf91163ff19b8f1dc716563e903a
commit r10-10081-g53907e20ee1fdf91163ff19b8f1dc716563e903a
Author: Paul Thomas
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125
--- Comment #4 from Piotr ---
mov r3, r0
ldr r0, [r0] @ unaligned
ldr r1, [r3, #4] @ unaligned
bx lr
can be optimized even more
ldr r1, [r0, #4] @ unaligned
ldr
1 - 100 of 201 matches
Mail list logo
