Re: [Open64-devel] Code Review request for fix bug974[CG]

I tried investigations on other targets. for IA64 , seems that it does both pre and post section alignments declarations. the assembly dump for above case below: .section .text, "ax", "progbits" .align 32 .section .data, "wa", "progbits" .align 4 .sectio

Re: [Open64-devel] Code Review request for fix bug974[CG]

a bit why you change it the way you are now? The diff is > something very minor, thus, should not have caused that many lines of > change. > > On Fri, May 4, 2012 at 1:58 PM, Gang Yu wrote: > >> Hi, >> >>Could a gatekeeper please help review the fix for bug974( &

[Open64-devel] Code Review request for fix bug974[CG]

Hi, Could a gatekeeper please help review the fix for bug974( https://bugs.open64.net/show_bug.cgi?id=974)? This is a code-size issue, however, we can't ignore the slightly behavior difference compared to GCC, that will break the link for opencc's build kernel 3.0.x. A cut-down case below: i

[Open64-devel] Code Review request for fix bug962[CG]

Hi, could a gatekeeper please help review the fix bug962( https://bugs.open64.net/show_bug.cgi?id=962)? A cut-down case below: a sample case: unsigned long copy_user_generic_string(void *to, const void *from, unsigned len); unsigned long copy_user_generic_unrolled(void *to, const void *from, un

[Open64-devel] Code review request for bug964[WGEN]

Hi, Could a gatekeeper please help review the fix for bug964( https://bugs.open64.net/show_bug.cgi?id=964)? A cut-down case: struct cpuinfo_x86 { unsigned char x86; } __attribute__((__aligned__((1 << (6); typedef struct pgprot { unsigned long pgprot; } pgprot_t; typedef unsigned long pte

[Open64-devel] Code review request for fix bug963[WOPT]

Hi, could a gatekeeper please help review the fix for bug963?( https://bugs.open64.net/show_bug.cgi?id=963) bug case: static inline __attribute__((always_inline)) __attribute__((pure)) unsigned char __static_cpu_has(unsigned short bit) { unsigned char flag; asm volatile("1: movb $0,%0\n"

[Open64-devel] Code review request for fix bug967[WGEN]

Hi, gatekeeper and Gautam: Could you please help review the fix for bug967? bug case: static unsigned long *anon1; int x86_this_cpu_constant_test_bit(unsigned int nr) { return ((1UL << (nr % 64)) & ({ typeof(*anon1) pfo_ret__; switch (sizeof(*anon1)) { case 1: asm("mov" "b ""%%""gs"":" "%P" "1

Re: [Open64-devel] review request for fix bug965[WGEN]

VECTOR<29516> (42)IB_BIT_VECTOR<29532> @gs_decl_size GS_INTEGER_CST<1168> { (0)GS_TCC<1200> GS_TCC_CONSTANT (3)IB_BIT_VECTOR<1204> GS_TREE_CONSTANT GS_TREE_INVARIANT (4)IB_UNSIGNED_LONG_LONG<2668> 64 (5)IB_LONG_LONG<2684> 0 } } > > -Gautam > >

Re: [Open64-devel] review request for fix bug965[WGEN]

> 3. #define this string in config.h or something appropriate > 4. replace all hard coded use of "anon" > then your change is the right fix, not continue previous bad practice. > > Sun > > On Fri, Apr 20, 2012 at 3:05 PM, Gang Yu wrote: > > On Fri, Apr 20, 2

Re: [Open64-devel] review request for fix bug965[WGEN]

gs"":" "%P" "1"",%0" : "=r" (pfo_ret__) : "m" (*a)); break; case 8: asm("mov" "q ""%%""gs"":" "%P" "1"",%0" : "=r" (pfo_ret__) : "m" (*a)); b

Re: [Open64-devel] review request for fix bug965[WGEN]

if (name != tempname || strncmp(tempname,"anon",4)) 1786 level = GLOBAL_SYMTAB; 1787 else 1788 level = CURRENT_SYMTAB; Regards Gang > On Fri, Apr 20, 2012 at 2:01 PM, Gang Yu wrote: > > Hi, Gautam > > > > Thanks for the review.

Re: [Open64-devel] review request for fix bug965[WGEN]

g on this issue. But this change is not clean. The change > is essentially assuming special semantics based on a variable name. What if > a user variable is named anon? > > -Gautam > > *From:* Gang Yu > *To:* open64-devel > *Sent:* Thursday, April 19, 2012 2:01 AM > *S

Re: [Open64-devel] Code review request for fix bug783[CGDwarf]

Thanks. Any other questions? Regards Gang On Wed, Apr 18, 2012 at 12:58 PM, Jian-Xin Lai wrote: > The comments should be moved from the middle of the expression. > > 2012/4/13 Gang Yu > >> Hi, >> >>Could a gatekeeper please help review the fix for bug7

Re: [Open64-devel] Code review for update for kernel build script[driver wrapper]

arg =~ s /\)/\\)/g; > $arg =~ s /"(.*)"$/'"$1"'/g; > $arg =~ s /\ $arg =~ s /\|/\\|/g; > $arg =~ s /\>/\\>/g; > > > -David Coakley / AMD Open Source Compiler Engineering > > On Sat, Apr 14, 2012 at 12:40 AM, DONG Yuan >

Re: [Open64-devel] Code review for update for kernel build script[driver wrapper]

86 machine? > > No, all the working machines are x86_64 based. I will have a test when I find one available. Regards Gang > 在 2012-04-13五的 19:09 +0800，Gang Yu写道： > > The source file is in the attachment. Thanks > > > > Regards > > Gang > > > > > >

Re: [Open64-devel] Code review for update for kernel build script[driver wrapper]

The source file is in the attachment. Thanks Regards Gang On Fri, Apr 13, 2012 at 6:27 PM, Jian-Xin Lai wrote: > Since most of the contents are changed, could you please attach the file > also? Thank you very much. > > 2012/4/13 Gang Yu > >> Hi, >> >>W

[Open64-devel] Code review for update for kernel build script[driver wrapper]

Hi, We have updated the kdriver script for linux kernel build. The kdriver build script was contributed by Dongyuan's team, Tsinghua University at 2009 around for linux 2.6.27 build. We made some changes to the old version, including: *). we change this bash script to a perl script. This is fo

[Open64-devel] Code review request for fix bug783[CGDwarf]

Hi, Could a gatekeeper please help review the fix for bug783( https://bugs.open64.net/show_bug.cgi?id=783)? This is a dwalf generation issue for x86_64 target, a joint work from Qing Zhu and myself. a sample case: int __vdso_clock_gettime(){ } with the following command: opencc -fpic -m64 -

Re: [Open64-devel] Review request for fix bug955[CG], a regression caused by r3882

On Wed, Mar 21, 2012 at 9:27 PM, Jian-Xin Lai wrote: > It looks like this branch is redundent? > + else if (OP_iadd(lda_op)) > +asm_opnd = OP_opnd( lda_op, 1 ); > It's fully covered by the else part. > Yes, thanks. The intended word logic is: under -m32 -fPIC, when we want to extra

Re: [Open64-devel] Review request for fix the O0-DCE bug(bug798)[CG]

break; > case 8: > undefined_fun3(); > default: > undefined_fun(); > } > return 0; > } > > gets a link time error from gcc. > > Dead code elimination needs to be done for all cases where the condition > value is known at compile time.

Re: [Open64-devel] Review request for fix the O0-DCE bug(bug798)[CG]

ant. Maybe you can simplify the high level SCF in >> > VHO and split this work into 3 parts: >> > part1: simplify the high level SCF in VHO >> > part2: simplify the low level BR instructions in the new phase >> > part3: build the CFG and remove unreachab

Re: [Open64-devel] Review request for fix the O0-DCE bug(bug798)[CG]

line: 1/21} I4INTCONST 0 (0x0) I4RETURN_VAL {line: 1/23} > part2: simplify the low level BR instructions in the new phase > part3: build the CFG and remove unreachable code. > The suggested way obviously make things complexed. *). You still need CFG *). *remove unreachable code* whi

[Open64-devel] Review request for fix bug955[CG], a regression caused by r3882

Hi, could a gatekeeper please help review the fix for bug955? regression caused by r3882. r3882 causes some regressions on compilation for m32 fpic related applications. For example, open64 triple build failed. a cut down bug-case below: opencc -m32 -fpic -S bug955

Re: [Open64-devel] Code Review request for fix bug952[CG]

Thanks very much for the comment: On Wed, Mar 7, 2012 at 11:13 AM, Jian-Xin Lai wrote: > Two comments: > 1. This patch is not generic enough. If the type tenths is shor or > other, it still fails > Yes, when tenths is short, it still fails at O2 or above. the patch does not handle the case:

Re: [Open64-devel] Code Review request for fix bug953[CG]

't you bite the bullet and figure out why you got that > assertion. I used your same reasoning and conclude that you should > always do -O0 and you have no answer. > Sun > > On Mon, Mar 5, 2012 at 9:54 PM, Gang Yu wrote: > > Some reasons to defend the fix suggestion: >

[Open64-devel] Review request for fix the O0-DCE bug(bug798)[CG]

Hi, list: We have a new design and implementation for fix the gcc incompatible issue, tracked as bug798,bug588,..., i,e. open64 unable to delete the unreachable code under O0 as gcc does. A typical case below: int defined_fun() { } int main() { int t; switch(sizeof(t)) { case 1:

Re: [Open64-devel] Code Review request for fix bug951[CG]

e_ofst != 0 ){ - Build_OP( TOP_lea32, tn, tmp, Gen_Literal_TN(base_ofst, 4), &newops ); - } } else { Build_OP( TOP_ldc32, tn, Gen_Symbol_TN( base_sym, base_ofst, TN_RELOC_NONE ), Regards Gang On Fri, Feb 24, 2012 at 2:30 PM, Gang

Re: [Open64-devel] Code Review request for fix bug953[CG]

b 24, 2012 at 8:18 PM, Sun Chan wrote: > this is not a fix, you might as well say, always do -O0 and you can > close 99% of a lot of optimization bugs > Sun > > On Fri, Feb 24, 2012 at 3:56 PM, Gang Yu wrote: > > Hi, > > > > Could a gatekeeper please help revie

[Open64-devel] Code Review request for fix bug953[CG]

Hi, Could a gatekeeper please help review the fix for bug953( http://bugs.open64.net/show_bug.cgi?id=953 )? Cut-down case please have a look at the attachment: http://bugs.open64.net/attachment.cgi?id=512 openCC -S bug953.cpp -fpic -m32 -O2 ### Ass

[Open64-devel] Code Review request for fix bug952[CG]

Hi, Could a gatekeeper please help review the fix for bug952( http://bugs.open64.net/show_bug.cgi?id=952)? Cut-down case please have a look at the attachment: http://bugs.open64.net/attachment.cgi?id=511 opencc asserts: ### Assertion failure at line 6888 of /fc/home/yug/open64/osprey/be/cg/x

[Open64-devel] Code Review request for fix bug951[CG]

Hi, Could a gatekeeper please help review the fix for bug951( http://bugs.open64.net/show_bug.cgi?id=951)? The cut-down bugcase: typedef union { } GenefxAccumulator; struct _GenefxState { int length; void *Aop[3]; int AopY; GenefxAccumulator *Dacc; GenefxAccumulator *

Re: [Open64-devel] Review request for fix bug950[CG]

_Substring(asm_string, B_suffix, "b"); +} else if (strstr(asm_string, Q_suffix) != NULL) { + asm_string = Replace_Substring(asm_string, Q_suffix, "l"); +} else if (strstr(asm_string, S_suffix) != NULL) { + asm_string = Replace_Substring(asm_string, S_suffix, "s"

Re: [Open64-devel] Review request for fix bug950[CG]

egards Gang On Thu, Feb 16, 2012 at 1:14 PM, Jian-Xin Lai wrote: > sprintf should be replace by snprintf and the return value must be > checked to make sure there is no buffer overflow. > > 2012/2/15 Gang Yu : > > Hi, > > > >Could a gatekeeper please help re

[Open64-devel] Review request for fix bug950[CG]

Hi, Could a gatekeeper please help review the fix for bug950? a sample case: void outb(unsigned short port, unsigned char val) { __asm__ __volatile__("out%B0 (%1)" : :"a" (val), "d" (port)); } opencc compiles it with: /tmp/ccspin#.i28qhO.s: Assembler messages: /tmp/ccspin#.i28qhO.s:36: Err

[Open64-devel] Review request: fix for bug949[CG]

Hi, Could a gatekeeper please help review the fix for bug949( https://bugs.open64.net/show_bug.cgi?id=949)? the cutdown bugcase snippet (data definition ignored) below: if (is_send) { a= (((__extension__ ({ register unsigned int __v, __x = (cqe->wqe); if (__builtin_constant_p (__x)) __v = (

Re: [Open64-devel] Review request for fix bug787[WOPT]

wrote: > debug build compiler has so many assertions and verification checks > that the total compile time is totally skewed. > Sun > > On Wed, Jan 11, 2012 at 11:43 AM, Gang Yu wrote: > > I have a whole build for the linux kernel(the intensive using of ASM > >

[Open64-devel] Code Review for fix bug941(CG)

Hi, could a gatekeeper please help review the fix for bug941( https://bugs.open64.net/show_bug.cgi?id=941)? Thanks to David Coakley to provide the cut-down source code and the relevant info in the register usage. below is the info " In 32-bit x86 code, %bpl is not a valid register and the compil

[Open64-devel] Code Review request for fix bug889/bug891[WOPT]

Hi, Could a gatekeeper please help review the following bug? Bug case: typedef signed char int8_t; typedef int int32_t; typedef long int int64_t; typedef unsigned long int uint64_t; struct S0 { }; struct S1 { int8_t f2; }; int32_t g_45 = 4L; struct S0 * const g_376[9][1] = { }; struct S0 * con

Re: [Open64-devel] Review request for fix bug787[WOPT]

le, compile time testing. it is known to cause > longer compile time also (it is basically a n^^2 algo > Sun > > On Sat, Jan 7, 2012 at 5:28 PM, Gang Yu wrote: > > Thanks for the review. > > > > The new patch introduces more copy-props in the code. so, personally I > th

Re: [Open64-devel] Review request for fix bug787[WOPT]

wrote: > this fix looks better. i am still a bit worry about regressions > (performance). Have you checked perf regression with this change? > Sun > > On Sat, Jan 7, 2012 at 1:36 PM, Gang Yu wrote: > > Hi, > > > > I have a new fix for the bug787, the cut-d

[Open64-devel] Review request for fix bug787[WOPT]

Hi, I have a new fix for the bug787, the cut-down case from Rao(thanks) is as follows: extern int main(int argc) { int res1; int val0,val1; val1=100; if(1) { asm("bswapl %0" : "=r" (val0) : "0" (val1)); res1=val0; } val0=res1; asm("bswapl %0" : "=r" (val1) : "0" (val0));

Re: [Open64-devel] Current build status for linux kernel on open64

(i1)]; } st1; > st1.ary1[1] = i1 + 1; > assert( st1.ary1[1] == 3); > } > > int main () { > f1(2); > return 0; > > } > > > On Sun, Jan 1, 2012 at 9:02 PM, Gang Yu wrote: > >> Hi, Ling Kun: >> >> Glad to hear loongson team has

Re: [Open64-devel] Current build status for linux kernel on open64

64 > > LingKun, > > can you send the changes for VLS (or VLA) to this alias (or send to me > and Yugang privately and we can help review and test out on x86) for > review? > Sun > > On Sun, Jan 1, 2012 at 10:14 AM, Ling Kun wrote: > > hi, Gang Yu: > > Loongson

Re: [Open64-devel] Current build status for linux kernel on open64

Sat, Dec 31, 2011 at 10:36 AM, Gang Yu wrote: > > Hi, list: > > > >We have some efforts on building and tuning linux kernel on open64, we > > have fixed several bugs and now we have only two building issues and > > several running issues at x86_64 target, O2

[Open64-devel] Current build status for linux kernel on open64

Hi, list: We have some efforts on building and tuning linux kernel on open64, we have fixed several bugs and now we have only two building issues and several running issues at x86_64 target, O2 level. linux 2.6.32 as an example, the two building issues are: A). bug787, Rao Shivarama has subm

[Open64-devel] Details on analysis for bug897 segment fault and fix rational

Since effort has been made on the original fix and the bug-case is not that big to affect the analyse , I will still use the original bug-case. Source: typedef short int int16_t; typedef int int32_t; typedef unsigned char uint8_t; typedef unsigned int uint32_t; typedef unsigned long int uint64_t;

Re: [Open64-devel] Review request for fix bug897[WOPT]

On the fix its own, what is your doubt? What do you think is illogical? Regards Gang On Sat, Dec 17, 2011 at 5:28 PM, Sun Chan wrote: > running correct means nothing to me. you are fixing the optimizer > trace of dce and htable > > On Sat, Dec 17, 2011 at 5:23 PM, Gang Yu wrote

Re: [Open64-devel] Review request for fix bug595[WOPT]

goal. > Sun > > On Sat, Dec 17, 2011 at 5:23 PM, Sun Chan wrote: > >> if at O0, gcc optimized it, why is it the case different at O2? >> Sun >> >> On Sat, Dec 17, 2011 at 5:18 PM, Gang Yu wrote: >> >>> For your questions: >>> [1]. w

Re: [Open64-devel] Review request for fix bug595[WOPT]

gcc does not do the built_in fold at O2. Regards Gang On Sat, Dec 17, 2011 at 5:23 PM, Sun Chan wrote: > if at O0, gcc optimized it, why is it the case different at O2? > Sun > > On Sat, Dec 17, 2011 at 5:18 PM, Gang Yu wrote: > >> For your questions: >> [1]. wh

Re: [Open64-devel] Review request for fix bug897[WOPT]

er. Can you further cut down the example? Also, try to use > something less confusing in names because it gets mixed up with versioning > of stmt, symbol etc. > Once you have a minimum case, we can look at some trace first > Sun > > On Sat, Dec 17, 2011 at 5:11 PM, Gang Yu wro

Re: [Open64-devel] Review request for fix bug595[WOPT]

macro will not be enabled. Regards Gang On Sat, Dec 17, 2011 at 5:11 PM, Sun Chan wrote: > Pls send more info for me to adequately review this fix. > Why do you suggest this fix. What is the problem with the assertion. > If you do that at -O0, what would happen? > Sun > > On

[Open64-devel] Review request for fix bug897[WOPT]

Hi, Could a gatekeeper please help review the fix for bug897( https://bugs.open64.net/show_bug.cgi?id=897)? when we use csmith to test the compiler stability, we find the DCE always trapped into segment fault. A typical case: int32_t g_46 = 0L; int32_t g_71 = 0L; int32_t *g_311 = &g_46; int32

[Open64-devel] Review request for fix bug595[WOPT]

Hi, Could a gatekeeper please help review the fix for bug595( https://bugs.open64.net/show_bug.cgi?id=595)? bug case: extern void doit(int); void quick_doit(int x) { if (__builtin_constant_p (x) && x != 0) asm volatile ("%0" : : "i#*X"(x)); else doit(x); } Compiling quick_do

Re: [Open64-devel] Review request for bug934(regression fix for r3843)[WOPT]

Hi, Sun Would you please kindly furthur input to this issue? If we could not find alternative better fix, can we check in the patch firstly? the regression bugs are marked major priority, we should get it fixed quickly. Thanks Regards Gang On Thu, Dec 15, 2011 at 10:19 AM, Gang Yu wrote

Re: [Open64-devel] Review request for bug934(regression fix for r3843)[WOPT]

e well except for cases like bug912, so, we make more effort on limit the changes, i.e, more constraint on the change. if we add the MAINOPT condition, the branch get eliminted by later DCE in preopt, then proactive_loop_transform happy. we get things done. Regards Gang > On Wed, Dec 14, 2011 at 12

[Open64-devel] Review request for bug934(regression fix for r3843)[WOPT]

Hi, Would a gatekeeper please help review the fix for bug934 , regression caused by r3843? segment-fault function snippet of bug case: void LibRaw:: tiff_set (ushort *ntag, ushort tag, ushort type, int count, int val) { struct tiff_tag *tt; int c; if (type < 3 && count <= 4) for (

Re: [Open64-devel] Review request for fix bug929[GCC-SPIN]

n converted to spin (using gspin_invoked()), and using > gs_set_operand to update the align. For similar instances, you can search > for gs_set_flag_value in the source code, and you would see the usage. > > Please see if the above works. > > Gautam > > > *From:* Gang Yu > *To

Re: [Open64-devel] Review request for fix bug929[GCC-SPIN]

Hi, Gautam: Since you are the gcc expert and the gatekeeper for FE. Would you please kindly review this patch? thank you very much. Regards Gang On Sat, Dec 3, 2011 at 3:52 PM, Gang Yu wrote: > Hi, > > Could a gatekeeper please help review the fix for bug929( > http://bug

Re: [Open64-devel] Review request for fix bug798(O0 does not do dce)[WOPT, infrastructure]

excuse me, I wonder if why not do such kind >> of >> > stuff with WGEN. >> > >> > Regards, >> > Yiran >> > >> > >> > On Tue, Dec 6, 2011 at 6:53 PM, Gang Yu wrote: >> >> >> >> Hi, >> >> >>

Re: [Open64-devel] Review request for fix bug798(O0 does not do dce)[WOPT, infrastructure]

te: > Hi Gang, > > I have a few questions: > > Is this phase going to be run at -g? From a quick look at the change > below, it seems yes. I do see similar behavior from GCC at -O0 -g also. But > for us by adding WOPT, does it affect debuggability? Has this been tested? &g

Re: [Open64-devel] Review request for fix bug798(O0 does not do dce)[WOPT, infrastructure]

not do such kind of > stuff with WGEN. > > Regards, > Yiran > > > On Tue, Dec 6, 2011 at 6:53 PM, Gang Yu wrote: > >> Hi, >> >>Could a gatekeeper please help review the fix for bug798( >> http://bugs.open64.net/show_bug.cgi?id=798)? >>

[Open64-devel] Review request for fix bug798(O0 does not do dce)[WOPT, infrastructure]

Hi, Could a gatekeeper please help review the fix for bug798( http://bugs.open64.net/show_bug.cgi?id=798)? This is a bug for a long time, a typical bug case below: int defined_fun() { } int main() { int t; switch(sizeof(t)) { case 4: defined_fun(); break; default:

[Open64-devel] Review request for fix bug903/bug910[CG]

Hi, Could a gatekeeper please help review the fix for bug903( https://bugs.open64.net/show_bug.cgi?id=903)? bug910 is a duplication of this bug, since it is a little complex on the source code, I will not show full source code, only IR snippet. bug assertion: Signal: Segmentation fault in CF

[Open64-devel] Review request for fix bug929[GCC-SPIN]

Hi, Could a gatekeeper please help review the fix for bug929( http://bugs.open64.net/show_bug.cgi?id=929)? A cut-down bug case: typedef long __kernel_time_t; typedef long __kernel_suseconds_t; typedef signed long long s64; typedef __kernel_suseconds_t suseconds_t; struct timespec; extern str

[Open64-devel] Review request for fix bug908(lower bit_field assertion failure)[WGEN]

Hi, Could a gatekeepler please help review the patch for fix bug908 https://bugs.open64.net/show_bug.cgi?id=908? A cutdown bugcase: typedef unsigned int __u32; typedef unsigned long long __u64; typedef unsigned char __u8; struct in_core_key { __u32 k_dir_id; /* packing localit

[Open64-devel] bug912 fix review request resent

Hi, list and Sun Let me re-organize the review request for bug912 fix. The bug case: struct go7007 { int sensor_framerate; int fps_scale; }; int vti_bitlen(struct go7007 *go) { unsigned int i, max_time_incr = go->sensor_framerate / go->fps_scale; for (i = 31; (max_time_incr & ((1 << i) -

Re: [Open64-devel] Review request for fix bug912(literal for operand 1 is not in range) [WOPT]

b=-1 flags:0x2 pj2 Sid-1 I8CONST does not appear. Regards Gang On Tue, Nov 29, 2011 at 12:38 PM, Sun Chan wrote: > just want to double check. You are saying, right after coderep creation, > the I8 const appeared? > Sun > > On Tue, Nov 29, 2011 at 11:39 AM, Gang Yu wrote: > >&

Re: [Open64-devel] Review request for fix bug912(literal for operand 1 is not in range) [WOPT]

1 at 11:10 AM, Sun Chan wrote: > I said, send me the entire expr (you just sent const and cvtl) > I want to know why const became I8 where the input is I4 > > On Tue, Nov 29, 2011 at 10:49 AM, Gang Yu wrote: > >> On Mon, Nov 28, 2011 at 10:40 AM, Sun Chan wrote: >> &

Re: [Open64-devel] Review request for fix bug912(literal for operand 1 is not in range) [WOPT]

On Tue, Nov 29, 2011 at 10:16 AM, Gang Yu wrote: > >> Before the change, the input expression is wrongly codemapped to >> >> >LDC I8 -2147483649 flags:0x0 b=-1 >> >> it should be rightly mapped to: >> >> > LDC I8 -2147483649 flags:0x0 b=-1 >&

Re: [Open64-devel] Review request for fix bug912(literal for operand 1 is not in range) [WOPT]

without your change, what is the output of this function for the same > input expr? > Sun > > On Mon, Nov 28, 2011 at 10:50 AM, Gang Yu wrote: > >> opt_htable.cxx >> 2244BOOL >> 2245CODEMAP::Canon_cvt(WN *wn, >> 2246 OPT_STAB *opt_stab

Re: [Open64-devel] Review request for fix bug924(invalid storage class for ST flag)[WGEN]

lias symbol be emitted as alias again, which cause the assembler assert. Regards Gang On Mon, Nov 28, 2011 at 11:10 AM, Jian-Xin Lai wrote: > Could you please explain more about the changes in cgemit.cxx? Thank > you very much. > > 2011/11/25 Gang Yu : > > Hi, > >

Re: [Open64-devel] Review request for fix bug912(literal for operand 1 is not in range) [WOPT]

flags:0x0 b=-1 the input is still: I4INTCONST 1 (0x1) I4I4LDID 0 T<4,.predef_I4,4> I4SHL I4INTCONST -1 (0x) I4ADD U4I4CVT Regards Gang On Mon, Nov 28, 2011 at 10:40 AM, Sun Chan wrote: > Sorry, pls send the corresponding function so I get a bigg

Re: [Open64-devel] Review request for fix bug912(literal for operand 1 is not in range) [WOPT]

t; I will need much more detail dump (e.g.when BAND first appear, before and > after) to know more about that. > Sun > > On Sun, Nov 27, 2011 at 9:48 PM, Gang Yu wrote: > >> >> On 11/27/2011 03:02 PM, Sun Chan wrote: >> >> you only showed the outpu

Re: [Open64-devel] Review request for fix bug912(literal for operand 1 is not in range) [WOPT]

egards Gang On Sun, Nov 27, 2011 at 11:24 AM, Gang Yu wrote: > Hi, > >Could a gatekeeper please help review the fix for bug912? > http://bugs.open64.net/show_bug.cgi?id=912 > > The cut down bug case: > > struct go7007 { > int sensor_framerate; > int fps_scale;

[Open64-devel] Review request for fix bug912(literal for operand 1 is not in range) [WOPT]

Hi, Could a gatekeeper please help review the fix for bug912? http://bugs.open64.net/show_bug.cgi?id=912 The cut down bug case: struct go7007 { int sensor_framerate; int fps_scale; }; int vti_bitlen(struct go7007 *go) { unsigned int i, max_time_incr = go->sensor_framerate / go->fps_scale

[Open64-devel] Review request for fix bug911(invalid widen a BS type wn)[WGEN]

Hi, Could a gatekeeper please help revie the fix for bug911 https://bugs.open64.net/show_bug.cgi?id=911? A cutted down bug case below: union flexcop_ibi_value { struct { u32 unused : 2; u32 dma_cur_addr :30; } dma_0x8; u32 no; } t; extern union flexcop_ibi_value f(void); u64 x; void fo

[Open64-devel] Review request for fix bug924(invalid storage class for ST flag)[WGEN]

Hi, Could a gatekeeper please help review the fix for bug924? https://bugs.open64.net/show_bug.cgi?id=924 This is a kernel build bug, the cut-down bug case below: typedef unsigned int __u32; typedef unsigned long kernel_ulong_t; struct pci_device_id { __u32 vendor, device; __u32 subvendor,

[Open64-devel] Code Review Request for fix bug362

Hi, Could a gatekeeper please help review the fix for bug362 http://bugs.open64.net/show_bug.cgi?id=362? This is an old linux kernel build bug, but it does still exist today. Source: static inline void cpuid_count(int op, int count, int *eax, int *ebx, int *ecx,

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

tant, imho > Sun > > On Mon, Nov 21, 2011 at 11:38 AM, Gang Yu wrote: > >> Sun: >> >>If you don't think this behavior compatibility is essential, I am OK >> with that. We can save time to do more relevant things, but I am still >> inter

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

OWs, I don't believe you thought about > this problem and understood what the underlying condition before a certain > function can be deleted. You just looked at what gcc or others behavior and > turn on/off some global flag. This is dangerous and not my recommended way > to change

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

don't believe > O0/1/2/3 does no dfe, only IPA does. May be you can show me which part of > compiler will do DFE besides IPA? Even if dfe is performed, "inlined" does > not imply the function body can be removed, it's a lot more complicated > than "inlin

[Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

Hi, could a gatekeeper help a review? any suggestions or comments are highly appreciated. This is an accidentally discovered issue when I review bug597cases: cat bug921 .c void static test(void) { as

Re: [Open64-devel] Code Review request for fix bug919, insufficient olimit value [driver]

mit because one program > needs it bigger, we keep doing that, we might as well put Olimit to infinity > Sun > > On Fri, Nov 18, 2011 at 10:42 AM, Gang Yu wrote: > >> Hi, >> >>Could a gatekeeper please help review the fix for bug919? >> https://bugs.

[Open64-devel] Code Review request for fix bug919, insufficient olimit value [driver]

Hi, Could a gatekeeper please help review the fix for bug919? https://bugs.open64.net/show_bug.cgi?id=919 Thank you very much when compiling big programs like linux kernel, open64's default olimit is not sufficient, which leads to no PU scope optimisation furthur more. In current optimisation

Re: [Open64-devel] Code review request for fix bug597 (constraint p not implemented assertion) [CG]

two check-ins, since they are really two separate problems. > > -David Coakey / AMD Open Source Compiler Engineering > > On Tue, Nov 15, 2011 at 4:09 PM, Gang Yu wrote: > > Hi, David > > > > As for the "%P" format string, we directly get it from linux kernel

[Open64-devel] Code Review Request for fix bug906[WOPT]

Hi, Could a gatekeeper please help review the fix for bug906? http://bugs.open64.net/show_bug.cgi?id=906 Sympton: This bug occurs at different phases of wopt, both c-smith [bug906] and kernel build [bug907, bug913] report this bug, ### Assertion failure at line 653 of /fc/proj/ctires/o

[Open64-devel] code review request for fix bug916 (asm constraint 'i" wrong assertion) [CG, WOPT]

Hi, Could a gatekeeper please help review the following patch for bug916 http://bugs.open64.net/show_bug.cgi?id=916? Symptom: opencc does not accept the asm constraint like , "i"(&p.v), while gcc does. struct T { int u; int v; } t; int main(void) { void * ret__; asm volatile ("mov

Re: [Open64-devel] Code review request for fix bug597 (constraint p not implemented assertion) [CG]

;=q" (ret__) >: "p" (&per_cpu__kernel_stack)); > } > > You can see "%P" is part of the name "%P1", and 'P' is not documented > as a valid modifier. It doesn't compile for me with gcc-4.1.2 or > gcc-4.5.3: > &

Re: [Open64-devel] Code review request for fix bug597 (constraint p not implemented assertion) [CG]

gt; I am fine with this (although I suspect the use of strstr on %P may be not > covering some error situations) > Sun > > On Mon, Nov 14, 2011 at 8:35 PM, Gang Yu wrote: > >> Hi, >> >>Could a gatekeeper please help review the fix for bug597, constraint &

[Open64-devel] Code review request for fix bug597 (constraint p not implemented assertion) [CG]

Hi, Could a gatekeeper please help review the fix for bug597, constraint not implemented assertion? Thanks very much. Current status: open64 does not implement the "p" asm constraint for x86_64 target, assertion throws out: void test(void) { char *per_cpu__kernel_stack; void *ret__;

Re: [Open64-devel] Review request on fix for bug838 [inline]

efinition and use just seems added complexity. > > - Suneel > > > On Thu, Oct 27, 2011 at 7:58 PM, Gang Yu wrote: > > The patch is now ready, reviewed by Fred Chow and discussed with > pathscale > > guys. Thanks > > > > besides fixing bug838, the patch a

Re: [Open64-devel] Review request on fix for bug838 [inline]

v] = VISITED_AND_KEEP; +#endif } else if (visited[v] == 0) visited[v] = VISITED_BUT_UNDECIDED; break; On Wed, Oct 12, 2011 at 1:38 PM, Gang Yu wrote: > Sorry for the duplication effort on this bug, before my patch, yongchong > had also submitted a patch to the

Re: [Open64-devel] Review request on fix for bug838 [inline]

_CFLAGS} -INLINE" +fi ;; *) AC_MSG_ERROR(["BUILD_OPTIMIZE=$BUILD_OPTIMIZE is not supported"]) -- yongchong Regards Gang On Sat, Oct 8, 2011 at 9:26 AM, Gang Yu wrote: > Hi, > >Could a gatekeeper please help review the fix for bug838? > http://

[Open64-devel] Review request for fix bug670, bug878[WGEN]

Hi, Could a gatekeeper help review the fix for bug 878/670? Thanks The assertion case: static int clear_page_array[0x120 / 4]; void clear_page(void *page) __attribute__((alias("clear_page_array"))); with the debug compiler, we get: Error: Declaration of alias "clear_page" does not match its t

[Open64-devel] Review request on fix for bug869 [WOPT]

Hi, Could a gatekeep please help review on fix for bug869? http://bugs.open64.net/show_bug.cgi?id=869 symptom: opencc builds broken for this case: int g = 0x10; int *volatile h = &g; int f(){ while (1) if (*h) continue; } Analysis: after goto convertion, we get whirl program: L

[Open64-devel] Review request on fix for bug838 [inline]

Hi, Could a gatekeeper please help review the fix for bug838? http://bugs.open64.net/show_bug.cgi?id=838 symptom: opencc could not compile gcc for debug build(O0), a cutted down case as below: int i; static __inline__ void should_not_exist (void) { i=1; } yug@jupiter:~/work/bugs/b

Re: [Open64-devel] Review request for bug 875 fix, itanium dbg compiler build broken[BUILD]

OPTIONS_SIZE 4080 class OPTIONS_STACK { private: Regards Gang On Wed, Sep 21, 2011 at 9:20 AM, Jian-Xin Lai wrote: > It looks like we don't need to double the buffer size since it's not very > often to add new options. I guess 1.2x or 1.5x is enough. > > 2011

[Open64-devel] Review request for bug 875 fix, itanium dbg compiler build broken[BUILD]

Hi, Could a gatekeeper help review the fix for bug 875, itanium debug compiler build broken? ### Assertion failure at line 1339 of /fc/proj/ctires/open64/o64guru/src/Fri/trunk/osprey/common/util/flags.c: ### Compiler Error in file /fc/proj/ctires/open64/o64guru/src/Fri/trunk/osprey/libm/vacos.

Re: [Open64-devel] Please help review a build broken fix for non-x86 targets [CG][LNO]

ment the interface. However, I think it should be another check-in for this issue. The same is for other #TARG_X86 in cg_loop. If there are no other objections, I will check the patch in tomorrow. Gang On Wed, Aug 3, 2011 at 9:27 PM, Gang Yu wrote: > en, I will take a look to see whether the

Re: [Open64-devel] Please help review a build broken fix for non-x86 targets [CG][LNO]

er #ifdef? > sun > > On Wed, Aug 3, 2011 at 8:58 PM, Gang Yu wrote: > > According to Mike, it is only defined in > > osprey/common/com/x8664/config_targ.cxx > > Gang > > > > > > On Wed, Aug 3, 2011 at 8:33 PM, Sun Chan wrote: > >> >

  1   2   >