[Bug rtl-optimization/56847] New: '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

2013-04-04 Thread shenhan at google dot com 

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

 Bug #: 56847
   Summary: '-fpie' triggers - internal compiler error: in
gen_add2_insn, at optabs.c:4705
Classification: Unclassified
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shen...@google.com


System - Ubuntu 12.04 64 bit.
GCC configuration - configure --disable-bootstrap --enable-languages='c,c++'
How to reproduce - 
 gcc -fpie -c -O2 case.c

Error message I got -

case.c: In function ‘get_clock’:
case.c:20:1: internal compiler error: in gen_add2_insn, at optabs.c:4705
 }
 ^
0x735e4b gen_add2_insn(rtx_def*, rtx_def*)
../../gcc.svn/gcc-4_8-branch/gcc/optabs.c:4705
0x7037f5 lra_emit_add(rtx_def*, rtx_def*, rtx_def*)
../../gcc.svn/gcc-4_8-branch/gcc/lra.c:313
0x7119a5 curr_insn_transform
../../gcc.svn/gcc-4_8-branch/gcc/lra-constraints.c:3082
0x712224 lra_constraints(bool)
../../gcc.svn/gcc-4_8-branch/gcc/lra-constraints.c:3613
0x705a2a lra(_IO_FILE*)
../../gcc.svn/gcc-4_8-branch/gcc/lra.c:2278
0x6d0820 do_reload
../../gcc.svn/gcc-4_8-branch/gcc/ira.c:4619
0x6d0820 rest_of_handle_reload
../../gcc.svn/gcc-4_8-branch/gcc/ira.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/56847] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

2013-04-04 Thread shenhan at google dot com 


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



--- Comment #1 from Han Shen  2013-04-04 23:31:02 
UTC ---

Created attachment 29807

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29807

test case

[Bug rtl-optimization/56847] [4.8/4.9 Regression] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

2013-04-17 Thread shenhan at google dot com 


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



--- Comment #8 from Han Shen  2013-04-17 23:42:22 
UTC ---

Hi, any progress on this?



Thanks!

[Bug c/55060] New: False un-initialized variable warnings

2012-10-24 Thread shenhan at google dot com 

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

 Bug #: 55060
   Summary: False un-initialized variable warnings
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shen...@google.com


Compiler version - trunk @ 192770
Compilation option - -c -O2 -Wall
Source - 
static void a(int *i) { }
static void b(int p) { }

int main(int argc, char *argv[]) {
  int i;
  a(&i);
  b(i);
  return 0;
}

Compilation output - 
/home/shenhan/test.c: In function ‘main’:
/home/shenhan/test.c:7:4: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   b(i);
^

A quick diagnose by David (Xingliang) Li is copied below - 

"The early uninitialized variable warning happens before inlining phase. Before
4.7, compiler does not warn this because the call to a(&i) which may initialize
'i' (the analysis is only intra-procedural).

In 4.7 (and above), the SRA optimization pass which happens before the analysis
is smart enough to replace the call to 'a' into a clone of 'a' which takes no
argument.  However the second access to 'i' still remains, thus the warning."

[Bug tree-optimization/55060] False un-initialized variable warnings

2012-10-24 Thread shenhan at google dot com 


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



--- Comment #2 from Han Shen  2012-10-24 17:55:40 
UTC ---

Yeah, I think value of "i" is never used.

[Bug inline-asm/60140] New: Cross compiler i386 atom fails - divtf3.c

2014-02-10 Thread shenhan at google dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60140

Bug ID: 60140
   Summary: Cross compiler i386 atom fails - divtf3.c
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shenhan at google dot com
CC: llozano at google dot com, wmi at google dot com

Created attachment 32099
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32099&action=edit
test case

Note - this only fails for google/gcc-4_8 branch.

Compilation failure while build cross compiler for i386 atom. 

To reproduce - 
  configure:
 ~/gcc.git/configure --disable-bootstrap --enable-languages='c,c++'
--disable-multilib --disable-libatomic --disable-libmudflap
--disable-libssp --enable-libgomp --enable-__cxa_atexit
--enable-checking=release --disable-libquadmath --disable-libitm
--enable-esp --with-arch=atom --with-tune=atom --enable-frame-pointer
  Build - 
 make -j40
  Compile a testcase - 
 ./gcc/xgcc -B./gcc -O2 -fpic -c -m32 ./divtf3.pp.c
  Output - 
 /divtf3.pp.c:64:1194: error: ‘asm’ operand has impossible constraints

Note divtf3.pp.c is actually a preprocessed file from libgcc/soft-fp/divtf3.c.

[Bug rtl-optimization/60141] New: ICE in i386.c distance_non_agu_define_in_bb

2014-02-10 Thread shenhan at google dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60141

Bug ID: 60141
   Summary: ICE in i386.c distance_non_agu_define_in_bb
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shenhan at google dot com
CC: llozano at google dot com, tejohnson at google dot com

This only fails for google/gcc-4_8

To reproduce - 
  configure:
 ~/gcc.git/configure --disable-bootstrap --enable-languages='c,c++'
--disable-multilib --disable-libatomic --disable-libmudflap
--disable-libssp --enable-libgomp --enable-__cxa_atexit
--enable-checking=release --disable-libquadmath --disable-libitm
--enable-esp --with-arch=atom --with-tune=atom --enable-frame-pointer
  Build - 
 make -j40
  Compile a testcase - 
   ./gcc/xgcc -B./gcc -g -O2 -fpic -c -m32 ~/SROA.pp.cpp
  Output - 
   SROA.cpp: In member function ‘void
{anonymous}::AllocaPartitioning::UseBuilder::operator()()’:
SROA.cpp:873:3: internal compiler error: Segmentation fault
0x8d0baf crash_signal
../../../gcc.git/gcc/toplev.c:346
0xa798c8 distance_non_agu_define_in_bb
../../../gcc.git/gcc/config/i386/i386.c:17506
0xa79cad distance_non_agu_define
../../../gcc.git/gcc/config/i386/i386.c:17564
0xa79cad ix86_lea_outperforms
../../../gcc.git/gcc/config/i386/i386.c:17730
0xb8e6ca output_89
../../../gcc.git/gcc/config/i386/i386.md:2152
0x72a5c3 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../../gcc.git/gcc/final.c:2895
0x72ae84 final(rtx_def*, _IO_FILE*, int)
../../../gcc.git/gcc/final.c:1986
0x72b46d rest_of_handle_final
../../../gcc.git/gcc/final.c:4432
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.

Debugging shows that in distance_non_agu_define_in_bb (i386.c),
BLOCK_FOR_INSN(start) returns zero, which caused this ICE.

A preliminary bisecting in google/gcc-4_8 shows that the follow CL introduces 
this ICE. (So I cc'ed Teresa Johnson)


commit 907fca49eae2da51a328eb192c691cc24f69e6af
Author: tejohnson 
Date:   Mon Dec 2 18:28:19 2013 +

Backport the last few fixes for -freorder-blocks-and-partition from
trunk to google/4_8: r204985, r205057 and r205243


r204985 | tejohnson | 2013-11-18 14:38:51 -0800 (Mon, 18 Nov 2013) | 15
lines

This patch fixes an lto profiledbootstrap failure with
-freorder-blocks-and-partition enabled. Currently compgotos
is the only pass that goes into cfglayout mode after bb reordering,
which is undesireable (and in the case of
-freorder-blocks-and-partition
can cause illegal partitioning) because of the optimizations performed
on the cfg when going into cfglayout mode. Moved compgoto before
bb reordering to avoid these problems.

2013-11-18  Teresa Johnson  

* gcc/cfgrtl.c (cfg_layout_initialize): Assert if we
try to go into cfglayout after bb reordering.
* gcc/passes.def: Move compgotos before bb reordering
since it goes into cfglayout.



r205057 | tmsriram | 2013-11-19 14:12:21 -0800 (Tue, 19 Nov 2013) | 7
lines

Emit a label for the split cold function part.  Label name is formed by
suffixing the original function name with "cold".

Patch tested for bootstrap on all default languages on x86_64 and
regression testsuite checked for parity with RUNTESTFLAGS -m32 and m64.

2013-11-19  Sriraman Tallam  

* final.c (final_scan_insn): Emit a label for the split
cold function part.  Label name is formed by suffixing
the original function name with "cold".

2013-11-19  Sriraman Tallam  

* gcc.dg/tree-prof/cold_partition_label.c: New testcase.



r205243 | tejohnson | 2013-11-21 20:16:47 -0800 (Thu, 21 Nov 2013) | 6
lines

2013-11-21  Teresa Johnson  

* cfgcleanup.c (outgoing_edges_match): Walk up past note instructions
not understood by old_insns_match_p.




git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/google/gcc-4_8@205594
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/63634] New: Compiler generated R_AARCH64_TLSLE_ADD_TPREL_HI12/LO12 pair overflowed by large TP offset

2014-10-23 Thread shenhan at google dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63634

Bug ID: 63634
   Summary: Compiler generated R_AARCH64_TLSLE_ADD_TPREL_HI12/LO12
pair overflowed by large TP offset
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shenhan at google dot com
CC: jingyu at google dot com, shenhan at google dot com
Target: aarch64

Created attachment 33798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33798&action=edit
Test case

(Trunk) Compiler generates by default the following insn and relocation pair to
access a TLS variable via its offset from TP, like below - 

main:
mrs x3, tpidr_el0
mov w2, 7
add x0, x3, #:tprel_hi12:.LANCHOR0
add x0, x0, #:tprel_lo12_nc:.LANCHOR0
add x1, x0, 1000
.L2:
strbw2, [x0], 1
cmp x0, x1
bne .L2
>>  add x3, x3, #:tprel_hi12:.LANCHOR1
>>  add x3, x3, #:tprel_lo12_nc:.LANCHOR1
ldr w0, [x3, 1024]
ret


Insns where indicated by ">>" are generated to add offset to x3, which is the
TP(thread pointer), the actually offset value is filled in by linker at static
link phase. However this means offsets are limited to 24 bits, in other words,
it fails the attach test case. (The bad things is bfd fails silently， resulting
a bad binary.)

To fix this, the compiler/assembler at least needs to generate the following to
support 32-bit TP offset.

>>  movk xx, #:R_AARCH64_TLSLE_MOVW_TPREL_G1, lsl 16
>>  movk xx, #:R_AARCH64_TLSLE_MOVW_TPREL_G0
>>  add  x3, xx

[Bug c/69256] New: Need to get rid of "Warning: IT blocks containing 32-bit Thumb instructions are deprecated in ARMv8"

2016-01-12 Thread shenhan at google dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69256

Bug ID: 69256
   Summary: Need to get rid of "Warning: IT blocks containing
32-bit Thumb instructions are deprecated in ARMv8"
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shenhan at google dot com
  Target Milestone: ---

Created attachment 37323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37323&action=edit
testcase

While building chrome, we are flooded with warnings like below - 

/tmp/ccxI02Yz.s: Assembler messages:
/tmp/ccxI02Yz.s:3854: Warning: IT blocks containing 32-bit Thumb instructions
are deprecated in ARMv8

To reproduce:
armv7a-cros-linux-gnueabi-gcc -O2 -fno-strict-aliasing -mthumb
-march=armv8-a+crc -c a.pp.c

Also '-mrestrict-it' does not help eliminate the warning.

[Bug target/69403] New: Wrong thumb2_ior_scc_strict_it insn pattern.

2016-01-20 Thread shenhan at google dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69403

Bug ID: 69403
   Summary: Wrong thumb2_ior_scc_strict_it insn pattern.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shenhan at google dot com
  Target Milestone: ---

Created attachment 37415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37415&action=edit
Test case

For the attached case.c, "armv7a-cros-linux-gnueabi-gcc -march=armv8-a -O2
case.c -S -mthumb" results in the following wrong assembly:

bug:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
push{r3, r4, r5, r6, r7, lr}
cmp r0, r2
add r7, sp, #0
bcc .L8
mvn r0, #-2147483648
pop {r3, r4, r5, r6, r7, pc}
.L8:
mov r6, r2
mov r4, r1
mov r5, r0
bl  FT_MSB(PLT)
rsb r3, r0, #31
addsr2, r0, #1
lslsr5, r5, r3
lsr r1, r4, r2
orrsr5, r5, r1
lsl r1, r4, r3
udivr0, r5, r6
mls r3, r6, r0, r5
.L3:
lsrsr4, r1, #31
lslsr0, r0, #1
orr r3, r4, r3, lsl #1
lslsr1, r1, #1
cmp r6, r3
sub r5, r3, r6
>>> it  ls
>>> movls   r0, #1
>>> it  ls
>>> orrls   r0, r0
it  ls
movls   r3, r5
subsr2, r2, #1
bne .L3
pop {r3, r4, r5, r6, r7, pc}
.size   bug, .-bug
.ident  "GCC: (4.9.2_cos_gg_b6125c7_4.9.2-r115)
.section.note.GNU-stack,"",%progbits


The ">>>" lines (corresponding to line 27 in case.c) effectively set r0 to 1.

By examing the source code :
(define_insn "*thumb2_ior_scc_strict_it"
  [(set (match_operand:SI 0 "s_register_operand" "=l,l")
(ior:SI (match_operator:SI 2 "arm_comparison_operator"
 [(match_operand 3 "cc_register" "") (const_int 0)])
(match_operand:SI 1 "s_register_operand" "0,?l")))]
  "TARGET_THUMB2 && arm_restrict_it"
  "@
   it\\t%d2\;mov%d2\\t%0, #1\;it\\t%d2\;orr%d2\\t%0, %1  <<<=== Alternative 1
   mov\\t%0, #1\;orr\\t%0, %1\;it\\t%D2\;mov%D2\\t%0, %1"  <<<=== Alternative 2


It seemd to me: alternative 1, when register %1 == register %0 (which is
asserted in the insn constraints), the first move "mov%d2\\t%0, #1" apparently
destroys the value in the register. The result of this being register %0 =
register %1 = 1.

A quick fix, which we currently use as workaround, is:
   it\\t%d2\;orr%d2\\t%0, %1, #1  <<<=== Alternative 1
Which is a fallback to "thumb2_ior_scc" and assembly warns about 32-bit thumb
within armv8 itblocks.

A better fix is welcomed!