Hi JianXin,
I have Filed the bug #871 for this and assigned to myself. Will move to
resolved state in the coming days.
Thanks,
Shivaram
From: Jian-Xin Lai [mailto:laij...@gmail.com]
Sent: Thursday, September 08, 2011 11:42 AM
To: Rao, Shivarama
Cc: open64-devel
Subject: Re: [Open64-devel] Code
Forgot to mention, could you please file a bug to bugs.open64.net and attach
the test case and patch? Thank you very much.
2011/9/8 Rao, Shivarama
> Hi JianXin,
>
> ** **
>
> Thanks for the review comments. I have attached the revised patch with
> these changes. Let me know if it is fine.*
Author: shivaram
Date: 2011-09-08 01:45:14 -0400 (Thu, 08 Sep 2011)
New Revision: 3732
Modified:
trunk/osprey/be/cg/x8664/ebo_special.cxx
Log:
Fixed a problem in load folding optimization where the memory location used
in the load operation is overwritten by a store operation. A check is adde
Looks fine to me. Please commit it. Thank you very much.
2011/9/8 Rao, Shivarama
> Hi JianXin,
>
> ** **
>
> Thanks for the review comments. I have attached the revised patch with
> these changes. Let me know if it is fine.
>
> ** **
>
> Regards,
>
> Shivaram
>
> ** **
>
> ** *
Hi JianXin,
Thanks for the review comments. I have attached the revised patch with these
changes. Let me know if it is fine.
Regards,
Shivaram
From: Jian-Xin Lai [mailto:laij...@gmail.com]
Sent: Thursday, September 08, 2011 7:25 AM
To: Rao, Shivarama
Cc: open64-devel
Subject: Re: [Open64-dev
Also, it's better to move the definition of arcs close to its uses.
2011/9/8 Jian-Xin Lai
> Hi Shivaram,
>
> The true_arcs and ops are defined but never used. Could you please check
> that?
>
> 2011/8/24 Rao, Shivarama
>
>> Hi,
>>
>> ** **
>>
>> Could a gatekeeper please review the attache
Hi Shivaram,
The true_arcs and ops are defined but never used. Could you please check
that?
2011/8/24 Rao, Shivarama
> Hi,
>
> ** **
>
> Could a gatekeeper please review the attached patch.
>
> ** **
>
> This patch fixes a problem in load folding optimization where the memory
> locati
Looks fine to me.
2011/9/7 Wu Yongchong
> Hi all,
>
> Could a gatekeeper review the attached patch for bug 826, which is an
> output difference failure in accessing union member for the attached
> test case?
>
> Bug description:
>
> When the test case is compiled with the follow
I think we breaks the compatibility of .B file time to time. For example,
the changes in TY_IDX for user specific alignment has broken the
compatibility.
2011/9/7 Gang
> **
> On 09/07/2011 10:59 AM, Jian-Xin Lai wrote:
>
>
>> 3. In osprey/common/com/opcode_gen_core.h, since OPR_ZDLBR is added f
Mike also suggested another way that YongChong adopted in one recent change.
I also mentioned using templates and partial specialization that you
did not include.
There are multiple ways. #ifdef is known to cause readability and
maintenability problem. It is fastest to implementors, but causes most
On 09/07/2011 10:59 AM, Jian-Xin Lai wrote:
3. In osprey/common/com/opcode_gen_core.h, since OPR_ZDLBR is
added for all targets, why not move it out of the #ifdef and
change the value for the later OPRs?
This is mainly for maintainance, we can add it as the numbe
On 09/07/2011 10:52 AM, Jian-Xin Lai wrote:
6. It looks like there is no options to skip some of the ZDL
transformation? is it only controlled by the pragma?
For ZDL transformation , we have "WOPT_Enable_ZDL" option to
control the whole zdl transformation. If this i
Sun:
It's again the "#ifdef" problem:( AFAIK, there are the following
suggestions , practices regarding on this CG porting issue:
a.) common interface, general "assert" implementation, target specific
real work done.
typical snippet:
cg/cgtarget.h
extern void CGTARG_Perform_THR_Code_Gene
Looks good to me.
2011/9/7 Wu Yongchong
> Hi, all
> Can a gatekeeper help review this patch
>
> It is fix of open64.net bug 828.
>
> The change of version 3360 is introduced to resolve the issue about
> cleanup code of GOTO to outer block and RETURN statements. It
> manipulate the scope-cleanup-
Hi,
Could a gate keeper review the patch for #827? Thank you very much.
The error message should be reported at toplev.c, line 884:
874 if (TREE_CODE (decl) == FUNCTION_DECL
875 && DECL_INITIAL (decl) == 0
876 && DECL_EXTERNAL (decl)
877 && ! DECL_ARTIFICIAL (d
Hi all,
Could a gatekeeper review the attached patch for bug 826, which is an
output difference failure in accessing union member for the attached
test case?
Bug description:
When the test case is compiled with the following command,
$ opencc name.c
the execution fails as follows
Hi, all
Can a gatekeeper help review this patch
It is fix of open64.net bug 828.
The change of version 3360 is introduced to resolve the issue about
cleanup code of GOTO to outer block and RETURN statements. It
manipulate the scope-cleanup-stack, so that cleanup code of each
cleanup would only co
17 matches
Mail list logo
