http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809
Bug #: 56809
Summary: Revision 197266 causes trunk ICE for arm-none-eabi
targets
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809
--- Comment #1 from Terry Guo 2013-04-02 08:12:32
UTC ---
The latest trunk code still has this issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55019
Bug #: 55019
Summary: Incorrectly use live argument register to save high
register in thumb1 prologue
Classification: Unclassified
Product: gcc
Version: 4.7.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55019
--- Comment #2 from Terry Guo 2012-10-22 11:23:16
UTC ---
Created attachment 28505
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28505
case to reproduce this bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55019
Terry Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55019
--- Comment #6 from Terry Guo 2012-10-23 10:13:08
UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > This issue is fixed.
>
> The problem was reported for 4.7 branch, the fix was OK:d for 4.7 and trunk,
> but so far only a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53983
Terry Guo changed:
What|Removed |Added
CC||terry.guo at arm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57329
Terry Guo changed:
What|Removed |Added
CC||terry.guo at arm dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57329
--- Comment #4 from Terry Guo ---
Now the fix is in 4.8 branch
http://gcc.gnu.org/ml/gcc-cvs/2013-06/msg01005.html. I think we can close this
bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886
Terry Guo changed:
What|Removed |Added
CC||terry.guo at arm dot com
--- Comment #8 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51631
Terry Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
: blocker
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 31523
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31523&action=edit
a reduced case
Thumb-1 target like cortex-m0 hasn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609
--- Comment #1 from Terry Guo ---
Here are some investigations. In the dump of IRA pass, we have jump insn like:
(jump_insn 31 24 172 5 (parallel [
(set (pc)
(if_then_else (lt (plus:SI (reg/v:SI 119 [ i ])
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51631
Bug #: 51631
Summary: Trunk ICE for case vst1_lanese64.c with -Os
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51631
--- Comment #1 from Terry Guo 2011-12-20 07:46:44
UTC ---
build@sha-pdsh-build04:~/workspace/GCC-Trunk-Daily-Test/build-linux/gcc-final/gcc/testsuite/gcc$
cat
/home/build/workspace/GCC-Trunk-Daily-Test/src/gcc/gcc/testsuite/gcc.target/arm/neon/vs
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
When build file gcc/libstdc++-v3/libsupc++/eh_arm.cc for Thumb-1 target, run
into below error:
/tmp/ccJ7atpP.s: Assembler messages:
/tmp/ccJ7atpP.s:26: Error: invalid register list to push/pop
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
When build some c++ files for pure thumb1 target, I ran into below ICE:
terguo01@terry-pc01:thumb1-reorg$
/myssd/terguo01/toolchain-build/thumb1-reorg/build-native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544
Terry Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 35199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35199&action=edit
gcc won't stop when compile this file
When use
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 35200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35200&action=edit
test case
When compile attached case with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647
--- Comment #11 from Terry Guo ---
(In reply to Jakub Jelinek from comment #10)
> In any case, a remaining testsuite issue doesn't deserve P1 at this point.
If nobody work on this, I will come up with a patch soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647
--- Comment #14 from Terry Guo ---
The test case is already updated with -mfloat-abi=soft.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648
--- Comment #7 from Terry Guo ---
(In reply to Jakub Jelinek from comment #6)
> Thus fixed, still would be nice to have a testcase in the testsuite. Terry
> or other ARM folks, can you please help with that?
> See http://gcc.gnu.org/ml/gcc-patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65710
--- Comment #2 from Terry Guo ---
(In reply to Richard Biener from comment #1)
> Needs confirming/reducing.
Working on reducing.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 35268
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35268&action=edit
test case
Revision 221867 is the fix to PR65647. But it causes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65710
--- Comment #33 from Terry Guo ---
(In reply to clyon from comment #32)
> > 2015-04-13 Terry Guo
> >
> > PR target/65710
> > * gcc.target/arm/pr65710.c: New.
> >
>
> Terry, any particular reason you use -march=armv6-m instea
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 31840
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31840&action=edit
case to reproduce the ICE
When use upstream 4.8 gcc to compile a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59826
--- Comment #1 from Terry Guo ---
As discussed in http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00875.html, the
root cause should be incorrect insn type of preload instruction. 4.8 assigns
alu type attribute to preload insn which causes other optim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59826
Terry Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 31903
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31903&action=edit
A preprocessed test case
Use trunk gcc to compile attached case with command "arm-n
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 32185
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32185&action=edit
case to reproduce the ICE
This issue is found during regression test of latest trunk for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60298
--- Comment #1 from Terry Guo ---
I did a little investigation and think the issue may be related to following
code from function remove_some_program_points_and_update_live_ranges:
782 max_regno = max_reg_num ();
783 for (i = FIRST_PSEU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64154
--- Comment #2 from Terry Guo ---
Hi Tom,
I enabled this optimization to thumb1 target cortex-m0 and found this IPA-RA
optimization doesn't consider the register clobber information attached to call
rtx and thus generated bad code. Here are the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64539
--- Comment #5 from Terry Guo ---
Thanks and it did fixed the issue I observed.
ormal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
I was calling function volatile_refs_p to implement a new feature, and then ran
into below ICE:
f.c: In function 'foo':
f.c:8:1: internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64815
--- Comment #2 from Terry Guo ---
(In reply to Andrew Pinski from comment #1)
> I don't think you need to call volatile_refs_p on the notes part of the
> instruciton.
The volatile_refs_p works in a recursive way which makes itself to scan the
no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64815
--- Comment #5 from Terry Guo ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Terry Guo from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > I don't think you need to call volatile_refs_p on the notes part of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64815
Terry Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
Terry Guo changed:
What|Removed |Added
CC||terry.guo at arm dot com
--- Comment #35
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
I am doing a clean trunk build for mingw and facing below issue:
/home/build/work/GCC-5-0-build/src/gcc/gcc/../libgcc/libgcov-util.c:55:17:
fatal error: ftw.h: No such file or directory
compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
--- Comment #38 from Terry Guo ---
(In reply to Kai Tietz from comment #37)
> I confirm that in libgcc we still have an issue ...
> Could you please make a new report for libgcc's libgcov-util.c for it.
>
> Thanks in advance
Reported it at http
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Due to the impact of option -fstrict-volatile-bitfields, current trunk gcc
generate worse code to access volatile bitfield which can be nicely handled
with gcc 4.8.
Here is test case:
$ cat y.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067
--- Comment #2 from Terry Guo ---
(In reply to Richard Biener from comment #1)
> This looks more like a failure to use bfi rather than shifts and bit
> operations.
If the above IF clause returns false, which means we don't need to consider
stric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
Terry Guo changed:
What|Removed |Added
CC||terry.guo at arm dot com
--- Comment #27
44 matches
Mail list logo
