https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
--- Comment #2 from Jakub Jelinek ---
I need -mfpmath=sse,387 -fexcess-precision=standard -Ofast -msse2
--param=scev-max-expr-size=0 -m32 (-Werror not needed, but -msse2 required) to
reproduce.
The function suggests that the "enabled" attribute o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #2)
> So, either we need to consider also -ffast-math options to be part of target
> and force different this_target_recog if it changes between functions, or
> the i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
Martin Liška changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #10 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #9)
> It's likely by us doing
>
> mpfr_set_emin (-32990);
> mpfr_set_emax (32766);
>
> during startup to work around a similar bug in MPC (IIRC it also
> was t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
--- Comment #6 from Jakub Jelinek ---
Guess we should defer for GCC11 then, and figure out a way what
OPTIMIZATION_NODE flags could be relevant for target globals (guess the vast
majority isn't, most of them will be flags affecting FE or GIMPLE o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:c15ff4d0803ffd02fdb9147e82e8881f3620e848
commit r9-8436-gc15ff4d0803ffd02fdb9147e82e8881f3620e848
Author: Kyrylo Tkachov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:bb9156ede009cfb572ab98c64288de5b21a89c17
commit r9-8435-gbb9156ede009cfb572ab98c64288de5b21a89c17
Author: Kyrylo Tkachov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
--- Comment #24 from CVS Commits ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:ea376dd471a3b006bc48945c1d9a29408ab17a04
commit r9-8434-gea376dd471a3b006bc48945c1d9a29408ab17a04
Author: Kyrylo Tkachov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:13f6d5ac48a7d55b41927849aeebc5832f8c63f0
commit r9-8437-g13f6d5ac48a7d55b41927849aeebc5832f8c63f0
Author: Kyrylo Tkachov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |10.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
Bug ID: 94443
Summary: [10 Regression] 510.parest_r and 526.blender_r ICE:
verify_ssa failed since
r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #11 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #10)
> Paul Zimmermann says that this bug is fixed in the MPC development version.
I could check that the bug is actually fixed, but the does not solve the GCC
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88826
Paolo Carlini changed:
What|Removed |Added
Known to work||9.1.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|paolo.carlini at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
--- Comment #1 from Martin Liška ---
$ cat sparsity_pattern.ii
int a;
unsigned *b;
class A {
A();
};
A::A() {
for (unsigned i; i <= a; ++i, ++b)
;
}
$ g++ -O3 -march=znver2 sparsity_pattern.ii
sparsity_pattern.ii: In constructor 'A::A()'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
--- Comment #2 from Martin Liška ---
Or a simple C code:
$ cat tc.i
int a;
unsigned *b;
void foo()
{
for (unsigned i; i <= a; ++i, ++b)
;
}
$ gcc -O3 -march=znver2 tc.i
tc.i: In function 'foo':
tc.i:4:6: error: missing definition
4 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #14 from Bill Seurer ---
I compared what happens with long double and they are very different
int do_signbit_tf (long double a) { return __builtin_signbit (a); }
cross:
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94441
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Bug ID: 9
Summary: __attribute__((access(...))) ignored for memcpy when
compiling with -Os
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #12 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #11)
> (In reply to Vincent Lefèvre from comment #10)
> > Paul Zimmermann says that this bug is fixed in the MPC development version.
>
> I could check that the b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445
Bug ID: 94445
Summary: gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #17 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #16)
> Any progress?
I'm sorry, I've been swamped with other things. Even so, given this (up to now
latent) bug has been there a while, and any patch here will affec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #18 from Jakub Jelinek ---
Yes, we want to fix it, unless you want to revert the PR93658 change even for
GCC 10 and reapply only to 11 once this bug is fixed too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-04-01
CC|
fortran --disable-multilib : (reconfigured)
../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools --disable-multilib
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200401 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #19 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #18)
> Yes, we want to fix it, unless you want to revert the PR93658 change even
> for GCC 10 and reapply only to 11 once this bug is fixed too.
Ok, let me take anoth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447
Bug ID: 94447
Summary: Not handling CONSTRUCTOR tree code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94377
--- Comment #3 from Fred Krogh ---
Just got GNU Fortran (GCC) 9.3.1 20200317 (Red Hat 9.3.1-1). I gives the error
$ gfortran -g -o pdt pdt.f90
pdt.f90:20:0:
20 | deallocate(av, stat=ista)
|
internal compiler error: in gimplify_v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #39 from Segher Boessenkool ---
commit 07fe4af4d51d74b63a76ea632d4db01d1f69f037
Author: Segher Boessenkool
Date: Wed Mar 18 21:58:45 2020 +
rs6000: Add back some w* constraints (PR91886)
In May and June last year I de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #41 from Segher Boessenkool ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386
--- Comment #15 from Paul Thomas ---
(In reply to markeggleston from comment #12)
> Created attachment 48155 [details]
> Proposed fix
>
> Sorry for the duplicate (PR94430) I missed this PR.
>
> The cause of the errors messages is due to most of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
--- Comment #10 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:032f2366a4cd57f781f2093d977b9cf9600c83b8
commit r10-7497-g032f2366a4cd57f781f2093d977b9cf9600c83b8
Author: Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94448
Bug ID: 94448
Summary: LSan: leaks should report PID and TID of allocation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #3 from Richard Biener ---
Note the access attribute is only for diagnostics, not for optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94448
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-04-01
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #15 from Iain Buclaw ---
Rainer, Unless I'm mistaken, that is the same secondary bug I raised in pr94290
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #16 from Iain Buclaw ---
Oops, apparently I mistyped the pr reference in the changelog.
The real bug report is pr94240.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
Bug ID: 94449
Summary: [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c
gcc.dg/torture/pr48731.c
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: n
d reject or at least warn
| ^~~
t.c:4:14: note: in a call to function ‘memcpy’ declared with attribute
‘write_only (1, 3)’
4 | extern void* memcpy(void* dest, const void* src, size_t len);
| ^~
$ gcc -c t.c -Os
$ gcc -v
[...]
gcc version 10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #17 from Iain Buclaw ---
The commit for it is here.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98eb7b2ed249537d12004f2c58583140ac25d666
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85982
Fritz Reese changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #5 from Fritz Reese -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
Khem Raj changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #19 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #20 from Khem Raj ---
(In reply to CVS Commits from comment #18)
> The master branch has been updated by Martin Liska :
>
> https://gcc.gnu.org/g:142d68f50b48309f48e34fc1d9d6dbbeecfde684
>
> commit r10-7492-g142d68f50b48309f48e34fc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87919
Fritz Reese changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94425
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> Well, there's no dependence visible to the compiler between the control word
> stores and loads so it's obvious the asms cannot be pure. Is 'asm' a D
> feature or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94426
--- Comment #5 from Nathan Sidwell ---
Reduced testcase:
template using Void = void;
template bool Init (U);
template bool VAR = Init ([] {});
template
Void> Foo (T)
{}
void q ()
{
Foo ([] {});
}
bug.ii: At global scope:
bug.ii:5:38:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94315
--- Comment #1 from Iain Buclaw ---
The test generates a make dependency file, and scans that it succeeded.
I can only think that there's something about where you build makes the
generated file different.
Maybe it looks like this?
pr93038.o:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Fritz Reese changed:
What|Removed |Added
Attachment #47883|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Fritz Reese changed:
What|Removed |Added
Status|ASSIGNED|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321
--- Comment #2 from Iain Buclaw ---
(In reply to Rainer Orth from comment #0)
> As originally reported in
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542177.html
>
> [which didn't get Cc'ed to you due to the abominable header rewri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94437
Giles Atkinson changed:
What|Removed |Added
Known to fail||9.3.0
--- Comment #6 from Giles Atkinso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364
--- Comment #2 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
> Huh, looks like this is the (patched by us) memory copying done in
> spec_qsort?
Yes
> I wonder if you can re-measure with our patching undone but then with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096
--- Comment #28 from David Edelsohn ---
GCC 7 is no longer supported. The patch was backported and released in GCC 8.4
and GCC 9.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
--- Comment #11 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:7546463b9f7a0b001cf61a94dcfc18f540721390
commit r10-7501-g7546463b9f7a0b001cf61a94dcfc18f540721390
Author: Peter Bergner
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:a96f1c38a787fbc847cb014d4b094e2787d539a7
commit r10-7502-ga96f1c38a787fbc847cb014d4b094e2787d539a7
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Martin Sebor changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804
--- Comment #2 from Peter Bergner ---
The copy us inserted by IRA's find_moveable_pseudos() function. The problem
seems to be that the new pseudo r134 has a different preferred reg class than
the original pseudo r133.
r134: preferred VSX_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
--- Comment #6 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> Do we ever hit the vectorized paths?
What's the best way to find out? If I open the disassembled code in
perf report and search for ymm, some of these (groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096
--- Comment #29 from Andrew Paprocki ---
David, Using GCC 9.2.0 I can reproduce using the steps from comment 27. Did you
run them yourself?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94429
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321
--- Comment #3 from Iain Buclaw ---
FYI, I checked on avr-elf as well, and the symbol is:
_DT4_D7pr922161C9getStructMFZv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94435
Andrew Pinski changed:
What|Removed |Added
Summary|[10 Regression] ICE in |[9/10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321
--- Comment #4 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:fb25041e11d92ea2df2e92065b256f8e5aa58a6c
commit r10-7504-gfb25041e11d92ea2df2e92065b256f8e5aa58a6c
Author: Iain Buclaw
Date: Wed Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
--- Comment #1 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94240
--- Comment #1 from Iain Buclaw ---
Fix applied for gcc-10 in r10-7314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94219
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2020-04-01
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94315
--- Comment #2 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:918b89b7623b6c42b09f37b7e3ef807d1abbabb8
commit r10-7505-g918b89b7623b6c42b09f37b7e3ef807d1abbabb8
Author: Iain Buclaw
Date: Wed Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94315
--- Comment #3 from Iain Buclaw ---
I've relaxed the match string in scan-file. Can you verify it's fine?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
Bug ID: 94450
Summary: lto abstract variable emitted as concrete decl
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: deb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
--- Comment #3 from Simon Marchi ---
Thanks, I confirm that issue with the snippet I posted is fixed.
It didn't fix the original issue that lead be to making this minimal
reproducer, so I guess I'll have to go back and make another reproducer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2020-04-01
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
--- Comment #2 from H.J. Lu ---
/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.dg/torture/pr48731.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
--- Comment #4 from David Malcolm ---
Can you attach the analyzer report please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
--- Comment #3 from H.J. Lu ---
/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.c-torture/execute/pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
--- Comment #5 from Simon Marchi ---
Created attachment 48165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48165&action=edit
Analyzer report for argpar
Here it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
H.J. Lu changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4 from H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> It is caused by r10-7501:
It is r10-7491
> commit bd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
> Author: Kewen Lin
> Date: Tue Mar 31 22:48:46 2020 -0500
>
> Fix PR9404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
--- Comment #6 from H.J. Lu ---
May need to boostrap GCC on Linux/x86-64 to see it. It can be reproduced
even when x32 isn't enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451
Bug ID: 94451
Summary: April 1st 2020 GCC does not compile spec 2017 gcc_r
benchmark with -O3
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
--- Comment #6 from David Malcolm ---
Thanks Simon. The second diagnostic definitely looks like a false positive; am
not sure about the first. Please can you file a separate bug about this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451
Michael Meissner changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451
--- Comment #2 from Andrew Pinski ---
Maybe:
g:f14b41d27124601284347a10d496362c8b4b8e1c
or
g:8d689cf43b501a2f5c077389adbb6d2bfa530ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57836
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|5.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94429
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451
Segher Boessenkool changed:
What|Removed |Added
Priority|P2 |P1
--- Comment #4 from Segher Boess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
--- Comment #4 from Kewen Lin ---
This case has one conversion insn generated after bit_field_ref, the patch
introduces one stupid mistake to use gsi_insert_before instead of
gsi_insert_seq_before, it leads to miss the conversion insn. The below
101 - 200 of 210 matches
Mail list logo
