[Bug target/65710] [4.9/5 Regression] Thumb1 ICE caused by no register to spill

[terry.guo at arm dot com]

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 instead of -march=armv6 ?
> 
> Some of my test configurations add -marm to RUNTESTFLAGS, and they fail
> because:
> error: target CPU does not support ARM mode
> 
> Can we switch to armv6, or do we need a few additional guards to avoid
> running this test in unsupported configurations?

Thanks for reminding. I just made a stupid copy-paste error here. The correct
options should be "-mthumb -O2 -mfloat-abi=soft" as shown in comment#1. I
reused some test case template and forgot to update the options. I will fix
this soon.

[Bug target/65710] [5 Regression] Thumb1 ICE caused by no register to spill

[terry.guo at arm dot com]

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.

[Bug target/65710] New: [5 Regression] Thumb1 ICE caused by no register to spill

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65710

Bug ID: 65710
   Summary: [5 Regression] Thumb1 ICE caused by no register to
spill
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  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 another ICE for thumb1
target as below:

$./install/bin/arm-none-eabi-gcc -mthumb -O2 -S regex.i 
regex.i: In function ‘byte_re_match_2_internal’:
regex.i:10121:1: error: unable to find a register to spill
 }
 ^
regex.i:10121:1: error: this is the insn:
(insn 12390 15093 12392 2 (set (reg:SI 8731 [8730])
(plus:SI (reg:SI 8731 [8730])
(reg:SI 10838))) regex.i:8483 718 {*thumb1_addsi3}
 (expr_list:REG_DEAD (reg:SI 10838)
(nil)))
regex.i:10121:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1419
0xa36eea _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/gcc/rtl-error.c:110
0x9521e7 assign_by_spills
../../src/gcc/gcc/lra-assigns.c:1419
0x952bd3 lra_assign()
../../src/gcc/gcc/lra-assigns.c:1594
0x94e919 lra(_IO_FILE*)
../../src/gcc/gcc/lra.c:2360
0x90cc09 do_reload
../../src/gcc/gcc/ira.c:5418
0x90cc09 execute
../../src/gcc/gcc/ira.c:5589
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

This issue still happens to the latest trunk.

[Bug target/65648] [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel

[terry.guo at arm dot com]

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-patches/2015-04/msg00262.html for more details.

It seems to me that Yvan is working on this, please refer to
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00272.html.

[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m

[terry.guo at arm dot com]

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.

[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m

[terry.guo at arm dot com]

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.

[Bug target/65648] New: [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648

Bug ID: 65648
   Summary: [5 Regression] Bad code due to IRA fails to recognize
the clobber in parallel
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: 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 command:
arm-none-eabi-gcc -march=armv6-m -mthumb -Os x.c -S

The gcc generates bad code as below:
main:
push{r0, r1, r2, r4, r5, r6, r7, lr}
ldr r4, .L5
movsr5, #0
ldr r0, [r4, #8]
add r1, sp, #4
rsbsr2, r0, #0
adcsr2, r2, r0
subsr3, r2, r3  //r3 is used but not initialized

The instruction to initialize r3 is removed due to IRA failed to recognize the
clobber in reload pass. Before the reload pass, we have three instructions like
below:
(insn 12 11 14 2 (parallel [
(set (reg:SI 128)
(eq:SI (reg:SI 110 [ D.4914 ])
(const_int 0 [0])))
(clobber (reg:SI 129))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
 (expr_list:REG_UNUSED (reg:SI 129)
(nil)))
(insn 20 19 22 2 (set (reg:SI 135)
(plus:SI (plus:SI (reg:SI 136)
(reg:SI 137))
(geu:SI (reg:SI 131 [ D.4914 ])
(reg:SI 134 [ c ] x.c:23 764 {thumb1_addsi3_addgeu}
 (expr_list:REG_DEAD (reg:SI 137)
(expr_list:REG_DEAD (reg:SI 136)
(expr_list:REG_DEAD (reg:SI 134 [ c ])
(expr_list:REG_DEAD (reg:SI 131 [ D.4914 ])
(nil))
(insn 22 20 23 2 (set (reg:SI 138)
(minus:SI (reg:SI 128)
(reg:SI 135))) x.c:23 720 {thumb1_subsi3_insn}
 (expr_list:REG_DEAD (reg:SI 135)
(expr_list:REG_DEAD (reg:SI 128)
(nil

After the reload pass, those instructions are wrongly turned into:
(insn 20 53 58 2 (set (reg:SI 3 r3 [135])
(plus:SI (plus:SI (reg:SI 3 r3 [137])
(reg:SI 2 r2 [136]))
(geu:SI (reg:SI 7 r7 [orig:131 D.4914 ] [131])
(reg:SI 6 r6 [153] x.c:23 764 {thumb1_addsi3_addgeu}
 (nil))
(insn 58 20 55 2 (parallel [
(set (reg:SI 2 r2 [128])
(eq:SI (reg:SI 0 r0 [orig:110 D.4914 ] [110])
(const_int 0 [0])))
(clobber (reg:SI 3 r3 [129]))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
 (nil))
(note 55 58 22 2 NOTE_INSN_DELETED)
(insn 22 55 23 2 (set (reg:SI 3 r3 [138])
(minus:SI (reg:SI 2 r2 [128])
(reg:SI 3 r3 [135]))) x.c:23 720 {thumb1_subsi3_insn}
 (nil))

However the later pass can recognize the clobber in insn 58 and will remove the
insn 20 because the r3 defined in insn 20 is clobbered by insn 58.

[Bug target/65647] New: [5 Regression] GCC won't stop when compile for armv6-m with -Os

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647

Bug ID: 65647
   Summary: [5 Regression] GCC won't stop when compile for armv6-m
with -Os
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  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 below command to compile the attached case for armv6-m, seems the gcc
won't stop:

arm-none-eabi-gcc -march=armv6-m -mthumb -O3 gcc-no-stop.c -S

With -da option, the file gcc-no-stop.c.234r.reload becomes larger an larger. I
have to use contrl+c to terminate the gcc. Here are some lines extracted from
the bottom of the file:

  Spill r17277(hr=0, freq=328) for r17822
   Assign 0 to reload r17822 (freq=328)
 Assigning to 17823 (cl=LO_REGS, orig=17823, freq=328, tfirst=17823,
tfreq=328)...
   Assign 0 to reload r17823 (freq=328)
 Assigning to 17825 (cl=LO_REGS, orig=17825, freq=328, tfirst=17825,
tfreq=328)...


The gcc version is "gcc version 5.0.0 20150401 (experimental) (GCC)".

The issue happens after this commit:

commit e0d2c8640c504ecd83291c4e008cb91d17df3e0d
Author: rsandifo 
Date: Fri May 30 07:35:47 2014 +
gcc/
ira.c (ira_get_dup_out_num): Check for output operands at

[Bug rtl-optimization/65067] regression on accessing volatile bit field

[terry.guo at arm dot com]

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
strict bit field, the gcc will try to check whether we can use BFI instruction.
Is it a good idea to do same check and attempt when IF clause returns True?

[Bug rtl-optimization/65067] New: regression on accessing volatile bit field

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067

Bug ID: 65067
   Summary: regression on accessing volatile bit field
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-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
#include 

struct tmp {
 uint32_t dummy;
 union {
  struct {
   uint32_t xyz : 1;
   uint32_t mode: 3;
   uint32_t res : 28;
  } bf;
  uint32_t wordval;
 } reg;
};

void set_mode(int mode)
{
 volatile struct tmp *t = (struct tmp *) 0x1000;
 t->reg.bf.mode = mode;
}

When compiled with gcc 4.8 and command
"gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -O2
-S y.c", the generated code is good and expected:

movr3, #4096
ldrr2, [r3, #4]
bfir2, r0, #1, #3
strr2, [r3, #4]
bxlr

But when compiled with current gcc 5.0 and same command, worse code is
generated:

mov r2, #4096
ldr r3, [r2, #4]
and r0, r0, #7
bic r3, r3, #14
orr r3, r3, r0, lsl #1
str r3, [r2, #4]
bx  lr

If turn off the option -fstrict-volatile-bitfields, we can get expected code. 

In my opinion, this gcc code is making bad decision:

  /* Handle -fstrict-volatile-bitfields in the cases where it applies.  */
  if (strict_volatile_bitfield_p (str_rtx, bitsize, bitnum, fieldmode,
  bitregion_start, bitregion_end))
{

The function strict_volatile_bitfield_p should make correct decision that we
don't need to consider strict volatile bitfield here for this case. When debug
this function, the arguments are:

Breakpoint 1, strict_volatile_bitfield_p (op0=0x76096e88, bitsize=3,
bitnum=33, fieldmode=SImode, bitregion_start=32, bitregion_end=63)

The mode of op0 is also SImode. So it should be easy to figure out that we are
working on a perfect 32-bit entity and no boundary crossing here.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[terry.guo at arm dot com]

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 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038. Not sure we
can mark them as duplication.

[Bug libgcc/65038] New: Unable to find ftw.h for libgcov-util.c

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038

Bug ID: 65038
   Summary: Unable to find ftw.h for libgcov-util.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: libgcc
  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 terminated.
make[1]: *** [libgcov-util.o] Error 1

This looks very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[terry.guo at arm dot com]

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 from Terry Guo  ---
I am building trunk for mingw and still having 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 terminated.
make[1]: *** [libgcov-util.o] Error 1

Is this something we just missed?

[Bug rtl-optimization/64815] ICE caused by volatile_refs_p doesn't skip NULL operand

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64815

Terry Guo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Terry Guo  ---
I am calling the function in wrong way. Thanks Andrew, now everything is ok.

[Bug rtl-optimization/64815] ICE caused by volatile_refs_p doesn't skip NULL operand

[terry.guo at arm dot com]

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
> > > instruciton.
> > 
> > The volatile_refs_p works in a recursive way which makes itself to scan the
> > notes part. I just call volatile_refs_p to the insn.
> > 
> > Do you mean I should update volatile_refs_p to avoid recursively scanning
> > the notes part of the insn?
> 
> Oh you should be using volatile_refs_p on the insn but only the set.
> 
> dse.c:  || volatile_refs_p (PATTERN (insn))

Thanks so much. You are right. The ICE disappears. Please mark this bug as
INVALID.

[Bug rtl-optimization/64815] ICE caused by volatile_refs_p doesn't skip NULL operand

[terry.guo at arm dot com]

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
notes part. I just call volatile_refs_p to the insn.

Do you mean I should update volatile_refs_p to avoid recursively scanning the
notes part of the insn?

[Bug rtl-optimization/64815] New: ICE caused by volatile_refs_p doesn't skip NULL operand

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64815

Bug ID: 64815
   Summary: ICE caused by volatile_refs_p doesn't skip NULL
operand
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  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 compiler error: Segmentation fault
 }
 ^
0xa52bef crash_signal
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/toplev.c:381
0x9f1edb volatile_refs_p(rtx_def const*)
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/rtlanal.c:2350
0x9f2009 volatile_refs_p(rtx_def const*)
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/rtlanal.c:2389
0x9f2009 volatile_refs_p(rtx_def const*)
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/rtlanal.c:2389
0xefa2fd recog_72
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/config/arm/arm.md:10757
0xefa2fd recog_90
   
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/config/arm/arm-fixed.md:230
0x9be96b insn_invalid_p(rtx_insn*, bool)
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/recog.c:357
0x9beb50 verify_changes(int)
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/recog.c:455
0x9bedda apply_change_group()
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/recog.c:548
0xf8eb18 cond_exec_process_if_block
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/ifcvt.c:754
0xf93299 cond_exec_find_if_block
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/ifcvt.c:3762
0xf93299 find_if_header
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/ifcvt.c:3444
0xf94c79 if_convert
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/ifcvt.c:4587
0xf94d4d execute
/work/terry/build-toolchain/GCC32RM-448/src/gcc/gcc/ifcvt.c:4780

This happens when volatile_refs_p is recursively scanning operands in below
insn:

(gdb) p debug_rtx(x)
(insn 12 11 51 3 (cond_exec (gt (reg:CC 100 cc)
(const_int 0 [0]))
(set (reg:SI 0 r0 [orig:110 D.4180 ] [110])
(mem/v:SI (reg/v/f:SI 2 r2 [orig:114 c ] [114]) [1 *c_5(D)+0 S4
A32]))) f.c:5 -1
 (expr_list:REG_DEAD (reg/v/f:SI 2 r2 [orig:114 c ] [114])
(nil)))

The last operand (nil) in expr_list caused this ICE. By adding below code, I
can avoid such ICE.

int
volatile_refs_p (const_rtx x)
{
  if (x == 0)
return 0;

  const RTX_CODE code = GET_CODE (x);
  
}

But I am not sure this is the correct fix. Maybe I am calling volatile_refs_p
in wrong way. Please advise.

[Bug rtl-optimization/64539] [5 regression] cprop_hardreg does not respect clobbers in C_I_F_U

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64539

--- Comment #5 from Terry Guo  ---
Thanks and it did fixed the issue I observed.

[Bug target/64154] enable fipa-ra for Thumb1

[terry.guo at arm dot com]

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 bad rtxs I extracted from the
dump of cprop_hardreg pass:

(insn 292 291 141 13 (set (reg:SI 4 r4 [orig:163 ivtmp.108 ] [163])
(reg:SI 12 ip [orig:163 ivtmp.108 ] [163])) 742 {*thumb1_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 12 ip [orig:163 ivtmp.108 ] [163])
(nil)))

(call_insn 141 292 142 13 (parallel [
(call (mem:SI (symbol_ref:SI ("f2") [flags 0x3]  ) [0 f2 S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
])
/myssd/terguo01/toolchain-build/GCC32RM-424/src/gcc/gcc/testsuite/gcc.dg/vshift-3.c:119
770 {*call_insn}
 (expr_list:REG_CALL_DECL (symbol_ref:SI ("f2") [flags 0x3]  )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list (clobber (reg:SI 12 ip))
(nil)))

(insn 11 10 12 13 (set (reg:SI 0 r0 [orig:170 ivtmp.130 ] [170])
(reg:SI 12 ip [orig:163 ivtmp.108 ] [163]))
/myssd/terguo01/toolchain-build/GCC32RM-424/src/gcc/gcc/testsuite/gcc.dg/vshift-3.c:121
742 {*thumb1_movsi_insn}
 (expr_list:REG_EQUAL (symbol_ref:SI ("j") [flags 0x80]  )
(nil)))

I checked the code in 'if (CALL_P (insn))' part in file regcprop.c and found
the algorithm doesn't consider the '(expr_list (clobber (reg:SI 12 ip))' in
insn 141 which makes current algorithm think it is safe to propagate ip from
insn 292 to insn 11.

The case is from gcc regression test and compiled with option "-mthumb
-mcpu=cortex-m0 -O3".

[Bug plugins/59335] Plugin doesn't build on trunk

[terry.guo at arm dot com]

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 from Terry Guo  ---
It seems we have one more file missed when build plugin with latest trunk:

install-native/lib/gcc/arm-none-eabi/5.0.0/plugin/include/tree-core.h:24:22:
fatal error: hash-set.h: No such file or directory.

[Bug target/61544] ICE due to thumb1_reorg function mishandles label type insn

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544

Terry Guo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Terry Guo  ---
The fix is submitted.

[Bug target/61544] New: ICE due to thumb1_reorg function mishandles label type insn

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544

Bug ID: 61544
   Summary: ICE due to thumb1_reorg function mishandles label type
insn
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  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/gcc-final/./gcc/xgcc
-shared-libgcc
-B/myssd/terguo01/toolchain-build/thumb1-reorg/build-native/gcc-final/./gcc
-nostdinc++
-L/myssd/terguo01/toolchain-build/thumb1-reorg/build-native/gcc-final/arm-none-eabi/libstdc++-v3/src
-L/myssd/terguo01/toolchain-build/thumb1-reorg/build-native/gcc-final/arm-none-eabi/libstdc++-v3/src/.libs
-L/myssd/terguo01/toolchain-build/thumb1-reorg/build-native/gcc-final/arm-none-eabi/libstdc++-v3/libsupc++/.libs
-B/myssd/terguo01/toolchain-build/thumb1-reorg/install-native/arm-none-eabi/bin/
-B/myssd/terguo01/toolchain-build/thumb1-reorg/install-native/arm-none-eabi/lib/
-isystem
/myssd/terguo01/toolchain-build/thumb1-reorg/install-native/arm-none-eabi/include
-isystem
/myssd/terguo01/toolchain-build/thumb1-reorg/install-native/arm-none-eabi/sys-include
-I/myssd/terguo01/toolchain-build/thumb1-reorg/src/gcc/libstdc++-v3/../libgcc
-I/myssd/terguo01/toolchain-build/thumb1-reorg/build-native/gcc-final/arm-none-eabi/libstdc++-v3/include/arm-none-eabi
-I/myssd/terguo01/toolchain-build/thumb1-reorg/build-native/gcc-final/arm-none-eabi/libstdc++-v3/include
-I/myssd/terguo01/toolchain-build/thumb1-reorg/src/gcc/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=sstream-inst.lo -g -O2 -c
/myssd/terguo01/toolchain-build/thumb1-reorg/src/gcc/libstdc++-v3/src/c++98/sstream-inst.cc
-o sstream-inst.o 
In file included from
/myssd/terguo01/toolchain-build/thumb1-reorg/src/gcc/libstdc++-v3/src/c++98/sstream-inst.cc:29:0:
/myssd/terguo01/toolchain-build/thumb1-reorg/build-native/gcc-final/arm-none-eabi/libstdc++-v3/include/sstream:
In member function 'std::basic_stringstream<_CharT, _Traits,
_Alloc>::__string_type std::basic_stringstream<_CharT, _Traits, _Alloc>::str()
const [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator; std::basic_stringstream<_CharT, _Traits,
_Alloc>::__string_type = std::basic_string]':
/myssd/terguo01/toolchain-build/thumb1-reorg/build-native/gcc-final/arm-none-eabi/libstdc++-v3/include/sstream:584:36:
internal compiler error: Segmentation fault
   { return _M_stringbuf.str(); }
^
0xd90226 crash_signal
/myssd/terguo01/toolchain-build/thumb1-reorg/src/gcc/gcc/toplev.c:337
0x10e1219 thumb1_reorg
   
/myssd/terguo01/toolchain-build/thumb1-reorg/src/gcc/gcc/config/arm/arm.c:16954
0x10e1cbe arm_reorg
   
/myssd/terguo01/toolchain-build/thumb1-reorg/src/gcc/gcc/config/arm/arm.c:17223
0xd1451c execute
/myssd/terguo01/toolchain-build/thumb1-reorg/src/gcc/gcc/reorg.c:3959
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Such ICE is triggered when apply thumb1_reorg function to below basic block:

(gdb) p debug_bb(bb)
(code_label/s 477 953 480 736 "" [1 uses])
(note 480 477 954 [bb 19] NOTE_INSN_BASIC_BLOCK)
(note 954 480 955 (var_location this (plus:SI (reg/f:SI 103 afp)
(const_int -20 [0xffec]))) NOTE_INSN_VAR_LOCATION)
(note 955 954 956 (var_location this (plus:SI (reg/f:SI 103 afp)
(const_int -20 [0xffec]))) NOTE_INSN_VAR_LOCATION)

For the code_label insn 477, its INSN_CODE accidentally equals the value of
CODE_FOR_cbranchsi4_insn. This leads to the execution of subsequent gcc code:

16953  pat = PATTERN (insn);
16954  op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);

Then the ICE is triggered due to applying SET_SRC to a code_label insn.

>From the very beginning, we shouldn't use INSN_CODE to insn like code_label.
Thus when the head of basic block isn't a proper insn, we should move to next
basic block.

Patch at https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00809.html can fix this
ICE.

[Bug libstdc++/61223] New: libstdc++ build fail due to pop lr register

[terry.guo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223

Bug ID: 61223
   Summary: libstdc++ build fail due to pop lr register
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: 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 instruction --
`pop {r1,r2,r3,lr}'

According to ARM arch manual, only PC and low registers are allowed in POP
instruction.

This failure happens with commit:

commit 13795f627c41a40f028d98e75f19774bc3a795b1
Author: merzlyakovao 
Date:   Fri May 16 13:16:33 2014 +

2014-05-16  Alexey Merzlyakov  

PR libstdc++/60758
* libsupc++/eh_arm.cc (__cxa_end_cleanup): Change r4 to lr in
save/restore
and add unwind directives.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210515
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/60298] [ARM/Thumb1] ICE caused by LRA for case pr54713-1.c

[terry.guo at arm dot com]

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_PSEUDO_REGISTER; i < (unsigned) max_regno; i++)
784{
785  for (r = lra_reg_info[i].live_ranges; r != NULL; r = r->next)
786{
787  lra_assert (r->start <= r->finish);
788  bitmap_set_bit (born, r->start);
789  bitmap_set_bit (dead, r->finish);
790}
791}

The max_regno is 575, while the length of array lra_reg_info is just 568. When
the loop index i is 568, the issue is triggered.

[Bug target/60298] New: [ARM/Thumb1] ICE caused by LRA for case pr54713-1.c

[terry.guo at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60298

Bug ID: 60298
   Summary: [ARM/Thumb1] ICE caused by LRA for case pr54713-1.c
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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 Thumb-1 target
Cortex-M0. Here is command to reproduce this issue:

terguo01@terry-pc01:case$ ../install-native/bin/arm-none-eabi-gcc  -O0 -w -c
-mthumb -mcpu=cortex-m0 -o pr54713-1.o pr54713-1.c 
pr54713-1.c: In function 'f10':
pr54713-1.c:70:1: internal compiler error: Segmentation fault
 }
 ^
0xb1b7ce crash_signal
/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/toplev.c:337
0xaeccbf simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def*
(*)(rtx_def*, rtx_def const*, void*), void*)
   
/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/simplify-rtx.c:417
0x9a6df3 update_equiv
   
/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra-constraints.c:351
0x9b06e7 lra_constraints(bool)
   
/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra-constraints.c:4054
0x99d609 lra(_IO_FILE*)
/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra.c:2339
0x94b7af do_reload
/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5457
0x94baf8 rest_of_handle_reload
/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5598
0x94bb42 execute
/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5627
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/59896] New: Thumb-1 LRA unable to generate reloads for jump_insn

[terry.guo at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59896

Bug ID: 59896
   Summary: Thumb-1 LRA unable to generate reloads for jump_insn
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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-none-eabi-gcc -mthumb
-O2 -S dtoa.i", we will get below error:

/home/build/work/GCC-4-9-build/src/newlib/newlib/libc/stdlib/dtoa.c: In
function '_dtoa_r':
/home/build/work/GCC-4-9-build/src/newlib/newlib/libc/stdlib/dtoa.c:862:1:
error: unable to generate reloads for:
(jump_insn 424 2763 425 32 (parallel [
(set (pc)
(if_then_else (ge (plus:SI (reg:SI 491 [ D.6302 ])
(const_int -1 [0x]))
(const_int 0 [0]))
(label_ref:SI 427)
(pc)))
(set (reg/v:SI 178 [ s2 ])
(plus:SI (reg:SI 491 [ D.6302 ])
(const_int -1 [0x])))
(clobber (reg:SI 833))
])
/home/build/work/GCC-4-9-build/src/newlib/newlib/libc/stdlib/dtoa.c:369 225
{*addsi3_cbranch}
 (expr_list:REG_UNUSED (reg:SI 833)
(expr_list:REG_DEAD (reg:SI 491 [ D.6302 ])
(int_list:REG_BR_PROB 7300 (nil
 -> 427)
/home/build/work/GCC-4-9-build/src/newlib/newlib/libc/stdlib/dtoa.c:862:1:
internal compiler error: in curr_insn_transform, at lra-constraints.c:3220
0xaa7a9b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/myssd/terguo01/toolchain-build/thumb1-uxtb/src/gcc/gcc/rtl-error.c:109
0x9a9f71 curr_insn_transform
   
/myssd/terguo01/toolchain-build/thumb1-uxtb/src/gcc/gcc/lra-constraints.c:3220
0x9acb2a lra_constraints(bool)
   
/myssd/terguo01/toolchain-build/thumb1-uxtb/src/gcc/gcc/lra-constraints.c:4115
0x999647 lra(_IO_FILE*)
/myssd/terguo01/toolchain-build/thumb1-uxtb/src/gcc/gcc/lra.c:2339
0x947791 do_reload
/myssd/terguo01/toolchain-build/thumb1-uxtb/src/gcc/gcc/ira.c:5457
0x947ada rest_of_handle_reload
/myssd/terguo01/toolchain-build/thumb1-uxtb/src/gcc/gcc/ira.c:5598
0x947b24 execute
/myssd/terguo01/toolchain-build/thumb1-uxtb/src/gcc/gcc/ira.c:5627
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

The gcc version is:
gcc version 4.9.0 20140120 (experimental) 

If we disable LRA, there is no such issue.

[Bug target/59826] ICE caused by mishandling PLD rtx on ARM cortex-m4 target

[terry.guo at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59826

Terry Guo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Terry Guo  ---
Forgot to mention PR number in my commit. This issue is fixed by
http://gcc.gnu.org/ml/gcc-cvs/2014-01/msg00436.html.

[Bug target/59826] ICE caused by mishandling PLD rtx on ARM cortex-m4 target

[terry.guo at arm dot com]

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 optimization passes think
it can cause data dependence between alu->load/store. The trunk gcc with patch
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00322.html, correctly assign load1
insn type to preload instruction, which avoids the check of data dependence
between alu->load/store, thereby no such issue. So the best way to fix this
issue in 4.8 is to back port the patch to assign the proper insn type
attribute.

[Bug target/59826] New: ICE caused by mishandling PLD rtx on ARM cortex-m4 target

[terry.guo at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59826

Bug ID: 59826
   Summary: ICE caused by mishandling PLD rtx on ARM cortex-m4
target
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  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 attached case with command:
"arm-none-eabi-gcc -mthumb -fprefetch-loop-arrays crash.c -O2 -S
-mcpu=cortex-m4", we will get ICE:

crash.c: In function 'genxScrubText':
crash.c:32:1: internal compiler error: in reg_overlap_mentioned_p, at
rtlanal.c:1469
 }
 ^

The option -fprefetch-loop-arrays causes gcc to generate rtx for ARM PLD
instruction like:

(insn 99 100 105 10 (prefetch (plus:SI (reg/v/f:SI 3 r3 [orig:143 last ] [143])
(const_int 34 [0x22]))
(const_int 0 [0])
(const_int 3 [0x3])) 343 {prefetch}
 (nil))

When check data dependencies between this rtx and others, gcc mishandles it as
a normal SET rtx and thus end up with ICE.

Trunk gcc hasn't such issue due to code improvement at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00533.html.

[Bug target/59609] [4.9 Regression] LRA generates bad code for libgcc function udivmoddi4 on thumb1 target

[terry.guo at arm dot com]

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 ])
(const_int -32 [0xffe0]))
(const_int 0 [0]))
(label_ref 35)
(pc)))
(set (reg:SI 181)
(plus:SI (reg/v:SI 119 [ i ])
(const_int -32 [0xffe0])))
(clobber (scratch:SI))
]) myudi.c:13 225 {*addsi3_cbranch}
 (int_list:REG_BR_PROB 2100 (nil))
 -> 35)

Next in the dump of reload pass, it is turned into:

(jump_insn 31 254 255 5 (parallel [
(set (pc)
(if_then_else (lt (plus:SI (reg:SI 3 r3 [181])
(const_int -32 [0xffe0]))
(const_int 0 [0]))
(label_ref 35)
(pc)))
(set (reg:SI 3 r3 [181])
(plus:SI (reg:SI 3 r3 [181])
(const_int -32 [0xffe0])))
(clobber (scratch:SI))
]) myudi.c:13 225 {*addsi3_cbranch}
 (int_list:REG_BR_PROB 2100 (nil))
 -> 35)
(insn 255 31 172 5 (set (reg:SI 12 ip [181])
(reg:SI 3 r3 [181])) myudi.c:13 197 {*thumb1_movsi_insn}
 (nil))

The subsequent passes will change the position of insn 255 and cause ip
uninitialized when do jump.

When disable LRA, in reload pass the jump_insn 31 will be turned into something
like:

(jump_insn 31 255 172 5 (parallel [
(set (pc)
(if_then_else (lt (plus:SI (reg:SI 0 r0)
(const_int -32 [0xffe0]))
(const_int 0 [0]))
(label_ref 35)
(pc)))
(set (reg:SI 12 ip [181])
(plus:SI (reg:SI 0 r0)
(const_int -32 [0xffe0])))
(clobber (reg:SI 0 r0))
]) myudi.c:13 225 {*addsi3_cbranch}
 (int_list:REG_BR_PROB 2100 (nil))
 -> 35)

This is good and will produce correct code.

[Bug c/59609] New: LRA generates bad code for libgcc function udivmoddi4 on thumb1 target

[terry.guo at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609

Bug ID: 59609
   Summary: LRA generates bad code for libgcc function udivmoddi4
on thumb1 target
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: 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't hardware div instruction, thus the
function __udivmoddi4 in libgcc is used. However this function is wrongly
compiled by LRA which is enabled in recent gcc, codes that use __udivmoddi4
will get a wrong results. When print unsigned long long value using printf
function, the printf function will use __udivmoddi4 and eventually will end up
with dead loop.

Attachment is a reduced case based on __udivmoddi4 function.And I am using the
latest gcc trunk code. Compile the attached case with command:

arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -O2 -S myudi.c

then check the assembly code:

sub r3, r3, #32 << should initialize ip after this insn
bpl .LCB31
b   .L4 @long jump
.LCB31:
mov ip, r3
mov r3, r9
mov r2, ip
lsl r3, r3, r2
mov r7, r3
.L5:
mov r3, r9
lsl r3, r3, r1
mov r6, r3
cmp r7, r5
bhi .L20
beq .L29
.L22:
mov r3, ip << Here is the wrong code, the ip is uninitialized.
sub r4, r4, r6
sbc r5, r5, r7
cmp r3, #0
bge .LCB50

[Bug target/57329] ICE with -O2 and -mthumb

[terry.guo at arm dot com]

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.

[Bug target/57329] ICE with -O2 and -mthumb

[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 Terry Guo  ---
The case has operations on vector for Thumb-1 targets. Thus subreg is generated
for example:

(insn 65 64 66 2 (set (subreg:SI (reg:TI 137 [ D.4126 ]) 4)
(reg:SI 211)) 187 {*thumb1_movsi_insn}
 (nil))

The subreg:SI is supposed to be turned into normal reg:SI in subreg1 pass.
However current 4.8 branch incorrectly calculates the rtx cost of such
transformation.

Speed costs
===
SI move: from zero cost 4, from reg cost 4
DI move: original cost 4, split cost 4 * 2
TI move: original cost 4, split cost 4 * 4
EI move: original cost 4, split cost 4 * 6

The subreg will be kept until IRA stage and causes ICE there.

With Bin's patch at http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00784.html, we
will get correct rtx cost:

Speed costs
===
SI move: from zero cost 4, from reg cost 4
DI move: original cost 8, split cost 4 * 2
TI move: original cost 16, split cost 4 * 4
EI move: original cost 24, split cost 4 * 6

Then the split happens, we will get:

(insn 65 64 66 2 (set (reg:SI 393 [ D.4126+4 ])
(reg:SI 211)) 187 {*thumb1_movsi_insn}
 (nil))

and then everything works well.

I believe this is the cause of the issue and am doing back port to 4.8 branch.

[Bug c/56809] Revision 197266 causes trunk ICE for arm-none-eabi targets

[terry.guo at arm dot com]

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.

[Bug c/56809] New: Revision 197266 causes trunk ICE for arm-none-eabi targets

[terry.guo at arm dot com]

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: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: terry@arm.com





After build a tool chain from trunk@r197266 for arm-none-eabi, then use it to

compile a simple case with switch statement, I got below ICE:



terguo01@terry-pc01:bad$ ../../install-native/bin/arm-none-eabi-gcc -O2 -S

test.c 

test.c: In function 'foo':

test.c:29:1: internal compiler error: in thumb2_output_casesi, at

config/arm/arm.c:25830

 }

 ^

0x87f9da3 thumb2_output_casesi(rtx_def**)

/work/terguo01/build-toolchain/latest/src/gcc/gcc/config/arm/arm.c:25830

0x83265d6 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)

/work/terguo01/build-toolchain/latest/src/gcc/gcc/final.c:2854

0x83271c5 final(rtx_def*, _IO_FILE*, int)

/work/terguo01/build-toolchain/latest/src/gcc/gcc/final.c:1958

0x832740a rest_of_handle_final

/work/terguo01/build-toolchain/latest/src/gcc/gcc/final.c:4333

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



It seems r197266 made some changes to jump table which then causes such error.



Here are the full configure options of my GCC:



terguo01@terry-pc01:bad$ ../../install-native/bin/arm-none-eabi-gcc -v

Using built-in specs.

COLLECT_GCC=../../install-native/bin/arm-none-eabi-gcc

COLLECT_LTO_WRAPPER=/work/terguo01/build-toolchain/latest/install-native/lib/gcc/arm-none-eabi/4.9.0/lto-wrapper

Target: arm-none-eabi

Configured with: /work/terguo01/build-toolchain/latest/src/gcc/configure

--target=arm-none-eabi

--prefix=/work/terguo01/build-toolchain/latest/install-native

--libexecdir=/work/terguo01/build-toolchain/latest/install-native/lib

--infodir=/work/terguo01/build-toolchain/latest/install-native/share/doc/gcc-arm-none-eabi/info

--mandir=/work/terguo01/build-toolchain/latest/install-native/share/doc/gcc-arm-none-eabi/man

--htmldir=/work/terguo01/build-toolchain/latest/install-native/share/doc/gcc-arm-none-eabi/html

--pdfdir=/work/terguo01/build-toolchain/latest/install-native/share/doc/gcc-arm-none-eabi/pdf

--enable-languages=c --disable-decimal-float --disable-libffi --disable-libgomp

--disable-libmudflap --disable-libquadmath --disable-libssp

--disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads

--disable-tls --with-newlib --without-headers --with-gnu-as --with-gnu-ld

--with-python-dir=share/gcc-arm-none-eabi

--with-sysroot=/work/terguo01/build-toolchain/latest/install-native/arm-none-eabi

--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'

--with-pkgversion='GNU Tools for ARM Embedded Processors' --disable-multilib

--with-mode=thumb --with-cpu=cortex-m4

Thread model: single

gcc version 4.9.0 20130330 (experimental) (GNU Tools for ARM Embedded

Processors) 



Among them, the important ones are "--target=arm-none-eabi --disable-multilib

--with-mode=thumb --with-cpu=cortex-m4".



Here is my test case:

terguo01@terry-pc01:bad$ cat test.c 



int

foo (int mode, int i)

{

  int x;



  switch (mode)

{

case 0:

  x = i + 1;

  break;

case 1:

  x = i / 2;

  break;

case 2:

  x = i * 3;

  break;

case 3:

  x = i + 3;

  break;

case 4:

  x = i + 5;

  break;

default:

  x = i - 1;

}



  return x;

}

[Bug target/53983] Cross arm-none-eabi armv6-m need a fake Makefile to compile libgcc

[terry.guo at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53983



Terry Guo  changed:



   What|Removed |Added



 CC||terry.guo at arm dot com



--- Comment #1 from Terry Guo  2012-10-25 09:53:19 
UTC ---

The provided configure options imply two things: the default target of current

tool chain is set to armv6-m and the multilib isn't disabled. If multilib isn't

disabled, gcc will try to build three multilibs from options "-marm", "-mthumb"

and "-mfloat-abi=hard". And the last option "-mfloat-abi=hard" can't work with

armv6-m because thumb1 doesn't support hard-float ABI so far. I think this is

the reason of your problem. If you check the config.log in folder

BUILDDIR/arm-none-eabi/fpu/libgcc/, you will find something like "sorry,

unimplemented: Thumb1-1 hard-float VFP ABI".



To get a successful build, you need to add configure option --disable-multilib.

Otherwise you can remove "--with-arch=armv6-m --with-mode=thumb" and use

multilib Makefile fragment to build libraries for armv6-m.



Here the multilib means the libgcc and c libraries will be built multiple times

with different options. Finally we will get multiple libraries for different

targets.

[Bug target/55019] Incorrectly use live argument register to save high register in thumb1 prologue

[terry.guo at arm dot com]

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 applied to trunk.



I plan to wait for some time to see if there is any unforeseen issue in trunk.

And then will do back port.

[Bug target/55019] Incorrectly use live argument register to save high register in thumb1 prologue

[terry.guo at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55019



Terry Guo  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #4 from Terry Guo  2012-10-23 03:55:25 
UTC ---

This issue is fixed.

[Bug target/55019] Incorrectly use live argument register to save high register in thumb1 prologue

[terry.guo at arm dot com]

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

[Bug target/55019] New: Incorrectly use live argument register to save high register in thumb1 prologue

[terry.guo at arm dot com]

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

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: terry@arm.com





When run 4.7 regression test on cortex-m0 with options "-mthumb -mcpu=cortex-m0

-O1 -funroll-loops", case gcc.dg/torture/builtin-complex-1.c will fail due to

the corruption of argument register as shown in below:



compare:

push{r3, r4, r6, lr}

movr6, fp

movr4, sl

movr3, r9<<-- r3 is clobbered

push{r3, r4, r6}

movr6, r8

push{r6}

movfp, r0

movsl, r1

movr9, r2

movr8, r3  <<-- wrong value is used

[Bug rtl-optimization/51631] Trunk ICE for case vst1_lanes64.c with -Os

[terry.guo at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51631

Terry Guo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Terry Guo  2012-08-03 12:27:32 
UTC ---
I applied this patch against trunk code at revision 190090 and it dose fix this
bug. Thanks Ramana.

[Bug rtl-optimization/51631] Trunk ICE for case vst1_lanese64.c with -Os

[terry.guo at arm dot com]

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/vst1_lanes64.c
/* Test the `vst1_lanes64' ARM Neon intrinsic.  */
/* This file was autogenerated by neon-testgen.  */

/* { dg-do assemble } */
/* { dg-require-effective-target arm_neon_ok } */
/* { dg-options "-save-temps -O0" } */
/* { dg-add-options arm_neon } */

#include "arm_neon.h"

void test_vst1_lanes64 (void)
{
  int64_t *arg0_int64_t;
  int64x1_t arg1_int64x1_t;

  vst1_lane_s64 (arg0_int64_t, arg1_int64x1_t, 0);
}

/* { dg-final { scan-assembler "vst1\.64\[
\]+((\\\{\[dD\]\[0-9\]+\\\})|(\[dD\]\[0-9\]+)),
\\\[\[rR\]\[0-9\]+\(:\[0-9\]+\)?\\\]!?\(\[ \]+@\[a-zA-Z0-9 \]+\)?\n" } } */
/* { dg-final { cleanup-saved-temps } } */

The buggy code fragment is:

   case VEC_SELECT:
  if (!VECTOR_MODE_P (mode))
{
  gcc_assert (VECTOR_MODE_P (GET_MODE (trueop0)));
  gcc_assert (mode == GET_MODE_INNER (GET_MODE (trueop0)));


The value of mode is DImode.
The value of trueop0 is: (reg/v:DI 135 [ arg1_int64x1_t ])

The whole insn that the function was trying to handle is:
(insn 5 2 0 2 (set (mem:DI (reg/v/f:SI 134 [ arg0_int64_t ]) [0 S8 A64])
(vec_select:DI (reg/v:DI 135 [ arg1_int64x1_t ])
(parallel [
(const_int 0 [0])
])))
/home/terguo01/work/Os-failed-cases/arm-none-eabi-gcc-4_6-20111208/build-linux/gcc-final/gcc/include/arm_neon.h:8412
1590 {neon_vst1_lanedi}
 (nil))

[Bug rtl-optimization/51631] New: Trunk ICE for case vst1_lanese64.c with -Os

[terry.guo at arm dot com]

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
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: terry@arm.com
CC: joey...@arm.com
  Host: i686-linux-gnu
Target: arm-none-eabi
 Build: i686-linux-gnu


When I was trying to run regression test using option -Os, I got this ICE for
latest trunk code:

build@sha-pdsh-build04:~/workspace/GCC-Trunk-Daily-Test/build-linux/gcc-final/gcc/testsuite/gcc$
/home/build/workspace/GCC-Trunk-Daily-Test/build-linux/gcc-final/gcc/xgcc
-B/home/build/workspace/GCC-Trunk-Daily-Test/build-linux/gcc-final/gcc/   
-save-temps  -mfpu=neon -mfloat-abi=softfp -c-mthumb -mcpu=cortex-m3 -o
vst1_lanes8.o
/home/build/workspace/GCC-Trunk-Daily-Test/src/gcc/gcc/testsuite/gcc.target/arm/neon/vst1_lanes64.c
-Os
/home/build/workspace/GCC-Trunk-Daily-Test/src/gcc/gcc/testsuite/gcc.target/arm/neon/vst1_lanes64.c:
In function 'test_vst1_lanes64':
/home/build/workspace/GCC-Trunk-Daily-Test/src/gcc/gcc/testsuite/gcc.target/arm/neon/vst1_lanes64.c:17:1:
internal compiler error: in simplify_binary_operation_1, at simplify-rtx.c:3128
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/49886] [4.6/4.7 Regression] pass_split_functions cannot deal with function type attributes

[terry.guo at arm dot com]

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 Terry Guo  2011-09-19 05:46:58 
UTC ---
(In reply to comment #7)
> I reverted the fix on 4.6 branch because it was causing a lot of other trouble
> (particularly PR 50295).  Therefore, this has to be re-opened.

Hi Martin,

I noticed a new dg directive was added as "/* { dg-xfail-run-if "" { "*-*-*" }
{ "-O2" "-O3" "-Os" } } */". Since then, this case is XPASS for arm-none-eabi
on QEMU for Cortex-M3. Here are the log:

Running
/home/build/work/jenkins-daily-build/src/gcc/gcc/testsuite/gcc.dg/torture/dg-torture.exp
...
XPASS: gcc.dg/torture/pr49886.c  -O2  execution test
XPASS: gcc.dg/torture/pr49886.c  -O3 -fomit-frame-pointer  execution test
XPASS: gcc.dg/torture/pr49886.c  -O3 -fomit-frame-pointer -funroll-loops 
execution test
XPASS: gcc.dg/torture/pr49886.c  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
XPASS: gcc.dg/torture/pr49886.c  -O3 -g  execution test
XPASS: gcc.dg/torture/pr49886.c  -Os  execution test

Do you think the case should fail for arm-none-eabi or not? If not, I think we
may need arm-none-eabi from dg-xfail-run-if.