Hi, all
Can someone help review this patch.
1. Bug descript
The hash function for VN_BINARY_EXPR will first canonicalize the
expression. as the following code in file opt_vn_expr_taxonomy.h:509
size_t hash()
{
Is_True(!has_bottom_opnd() && !has_top_opnd(),
("Cannot hash
ure".
>
> Best Regards,
> Yiran
>
> On Thu, Dec 8, 2011 at 9:27 PM, Wu Yongchong wrote:
>>
>> You should not configure and make open64 in the top directory of the
>> source file.
>> Please do the following steps
>>
>>
>> $ cd open64-src
As my experiment, you shoud use both --host= --target= to generate
64-bit executables.
$ ../configure --prefix=$PWD/binroot --with-build-optimize=DEBUG
--host=x86_64-gnu-linux --target=x86_64-gnu-linux
On Sun, Nov 13, 2011 at 1:12 AM, Hanfeng Qin wrote:
> Even --host option instead of --build,
You should not configure and make open64 in the top directory of the
source file.
Please do the following steps
$ cd open64-src
$ mkdir objs
$ cd objs
$ ../configure --prefix=
$ make && make install
On Mon, Dec 5, 2011 at 8:01 AM, Matthias Grobarek wrote:
> Hi. I am unable to build Open64 5.0
Hi all,
Can a gatekeeper review the attached patch for fixing return values of
GCC built-in functions?
This patch changes the return types of the following 9 GCC built-in functions.
name from to --F4ISNAN
F4
I4F8ISNAN
by eq_const_st of two ST?"
>
>
> -Original Message-
> From: Wu Yongchong [mailto:wuyongch...@gmail.com]
> Sent: Monday, October 31, 2011 10:47 AM
> To: Sun Chan
> Cc: open64-devel
> Subject: Re: [Open64-devel] [open64-devel] Code review request for bug 883
&
AM, Sun Chan wrote:
> your comment should be at where future new member may be added.
> sun
>
> On Sun, Oct 30, 2011 at 11:01 PM, Wu Yongchong
> wrote:
>>
>> Hi, all
>> Can a gate keeper help review this patch.
>> See https://bugs.open64.net/show_bug.cgi?id=88
Hi, all
Can a gate keeper help review this patch.
See https://bugs.open64.net/show_bug.cgi?id=883 for reference.
Revision 3760 add a new member "mINT32 line" to structure ST, it
cause the function eq_const_st::operator() get wrong return value,
then make the symbol merge process in IPA not work.
Hi
Can a gatekeeper help review this patch, it's a bug fixed for bug#838
When building the gcc front end with opencc -g -O0, there is some
dead functions that call other undefined functions. when building with
gcc or opencc -O1 optimization above, the compiler will eliminated the
dead function. B
:
> We have also made a fix for this problem in ST. The idea of the fix is
> exactly the same, but some implementation details are different. I
> reported it to Wu Yongchong, who suggested I submit it for general
> review and approval.
>
> Apologies: I am reporting a patch
Hi, all
can a gate keeper help review this patch.
This patch fixed bug 865.
In IA64, open64 need ftz.o to link. This patch build and install ftz.o
--
yongchong
ftz.diff
Description: Binary data
--
BlackBerry® DevCon A
Hi, all
Can a gate keeper help review this patch. It fixed build error in IA64 system.
Index: osprey/common/com/opcode_gen_core.h
===
--- osprey/common/com/opcode_gen_core.h (revision 3735)
+++ osprey/common/com/opcode_gen_core.h (wor
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
Since this change will impact other targets, would someone please
> review for other targets?
>
> Thanks,
>
> Min
>
> On Tue, Aug 16, 2011 at 2:22 AM, Wu Yongchong wrote:
>> Here is an improved version that deal with the situation of MTYPE_I1,
>> MTYPE_I2 and MTYPE_
iew about another patch for this
>> >> >> > bug?
>> >> >> > The last patch can not work for SL-target as long long and
>> >> >> > float
>> >> >> > point
>> >> >> > are emulated by INT for SL.
>>
Here is an improved version that deal with the situation of MTYPE_I1,
MTYPE_I2 and MTYPE_I4
On Sun, Aug 14, 2011 at 1:07 PM, Wu Yongchong wrote:
> Hi,
>
> Can a gatekeeper help review this patch. the patch fixed bug 855,
>
> https://bugs.open64.net/show_bug.cgi?id=855
>
&g
Hi,
Can a gatekeeper help review this patch. the patch fixed bug 855,
https://bugs.open64.net/show_bug.cgi?id=855
This patch will be change the file targ_const.cxx in all 7 target,
ia64, x8664, MIPS, NVISA, ppc32, loongson and SL .
The first hunk of the patch make sure after simplify I4NEG, if
) > MTYPE_byte_size(WN_rtype(kid0))) {
> field_tn = Build_TN_Of_Mtype (rtype);
> result = Build_TN_Of_Mtype (rtype);
> } else { // guard against U1MPY or U2MPY
> field_tn = Allocate_Result_TN (kid0, NULL);
> result = Allocate_Result_TN (kid0, NULL);
> }
>
>
> 2
);
> } else { // guard against U1MPY or U2MPY
> field_tn = Allocate_Result_TN (kid0, NULL);
> result = Allocate_Result_TN (kid0, NULL);
> }
>
>
> 2011/8/9 Jian-Xin Lai
>>
>> Looks fine to me.
>>
>> 2011/8/8 Wu Yongchong
>>>
>>&
HI,
Could a gatekeeper review the attached patch for a compiler assertion
in the EBO phase of CG when -O1 is given?
To see the assertion, DBG build compiler should be used.
Bug description:
test case:
#pragma pack (2)
struct S4
{
short a;
short b : 11;
int e : 18;
};
#prag
Hi,
I have remove VENDOR_OSP macro, here is the new patch
On Fri, Aug 5, 2011 at 10:43 AM, Jian-Xin Lai wrote:
> I don't think the "#if defined(VENDOR_OSP)" is needed for these kinds of
> changes. Could you please remove them?
>
> 2011/7/26 Wu Yongchong
>>
&g
Hi,
Can a gate keeper help review this patch
For volatile field in a struct, the volatile flag is not set correctly
in expanding WHIRL to OPs. The CG will reorder the store because it's
not volatile. This patch will return the right volatile flag for
MSTORE and ISTORE.
Index: osprey/common/com/
Hi, all
Can a gatekeeper help review this patch
This patch adds support to print VCG graphs for procedure CFGs, at
various points in CG.
Specifically, the 'V' character can be used (to create VCG graphs)
wherever the 'r' character is used to print the CG IR.
Examples:
-Wb,-tVa - create a VCG grap
Hi,
can a gate keeper help review this patch. It fix several memory leaks
in files osprey/be/cg/cgdwarf.cxx, osprey/libdwarf/dwf_section.c, and
osprey/libdwarf/libdwarf/pro_section.c . See the attachment for the
patch
--
yongchong
110719.patch
Description: Binary data
d it's not freed, too. Could you please also check the cycle_fn?
>
> 2011/7/4 Wu Yongchong :
>> Can a gate keeper help review this patch
>>
>> Class Priority_Selector(declared in open64/osprey/be/cg/hb_sched.h)
>> has a member std::list _curbb_list . Although
Can a gate keeper help review this patch
Class Priority_Selector(declared in open64/osprey/be/cg/hb_sched.h)
has a member std::list _curbb_list . Although we use local memory
pool when we call the constructor, the _curbb_list still use new
operator to allocate memory. So that this memory block is
Can a gate keeper help review this patch
The compiler build with --with-build-optimize=DEBUG
See the bug description at https://bugs.open64.net/show_bug.cgi?id=823
The problem is that we were calling:
GRA_LIVE_Recalc_Liveness(region ? REGION_get_rid( rwn) : NULL);
GRA_LIVE_Rename_TNs();
_138
On Mon, Jun 20, 2011 at 2:13 PM, Wu Yongchong wrote:
> You are right, I should check the debug level, not the performance level.
>
> On Mon, Jun 20, 2011 at 2:10 PM, Sun Chan wrote:
>> if it is for debuggability, shouldn't you use the -g3 option instead of -O0?
>> Su
You are right, I should check the debug level, not the performance level.
On Mon, Jun 20, 2011 at 2:10 PM, Sun Chan wrote:
> if it is for debuggability, shouldn't you use the -g3 option instead of -O0?
> Sun
>
> On Mon, Jun 20, 2011 at 1:55 PM, Wu Yongchong wrote:
>>
Hi,
can a gatekeeper help review this patch,
This patch will allocate stack space for unused variable in -O0. It's
useful for debug-ability in -O0.
Index: osprey/be/com/data_layout.cxx
===
--- osprey/be/com/data_layout.cxx (rev
allow static objects, can you put your new routines
> inside the right class?
> 2. please remove the #ifdef KEY, I think we can start removing this
> KEY thing now, everyone assumes this as default now
>
> Sun
>
> On Mon, Jun 13, 2011 at 7:52 PM, Wu Yongchong wrote:
>>
Hi
can a gatekeeper help review this patch
This patch tries to fix various C standard compliant problems related
to volatile in open64. Here is the list of the problems:
1. Incorrect simplification in the following case:
volatile int x;
return x - x;
The expression (x - x) cannot be simplif
EPIC is at least128bit aligned, no need for an "align" pseudo .
On Tue, May 24, 2011 at 5:09 PM, Sun Chan wrote:
> I don't understand why an "align" pseudo is not needed in IA64
> Sun
>
> On Tue, May 24, 2011 at 4:49 PM, Wu Yongchong wrote:
>> Here
Here is the patch,
1. the first one used #if defined to remove some code that specific in
X8664 and loogson, not in IA64.
2. the second one , in IA64, _wn_to_val_num_map->Get_val((POINTER)
wn_cond) return a *void type, it must convert to a type INTPTR before
convert to IF_CMP_VAL(actually UINT32)
Hi, Nelson
Would you please file a bug in https://bugs.open64.net
On Wed, Apr 13, 2011 at 8:00 AM, Nelson H. F. Beebe wrote:
> cbergst...@pathscale.com asks for the compilation options that I used
> in my report of floating-point test failures of the new opencc version
> 4.2.4 in the features-1.2
27;t this be a problem for
> other targets, too?
> 2. What if you are building the library in debug mode? Should the
> flag change also be conditional on -O3 existing in CFLAGS?
>
> -David Coakley / AMD Open Source Compiler Engineering
>
> On Thu, Mar 3, 2011 at 12:34 AM, Wu Yon
can a gatekeeper help review this patch
This is a round off issue in IA64 system relative open64 library, the libffio.a.
we use opencc -O3 to build libffio.a, the round off option in -O3 is
-OPT:ro=2, it allow reassociation transforma\
tions.
in line 531 of file osprey/libu/numconv/mpp/defgu2s.c
Hi,
can a gatekeeper help review this patch?
I have make a patch for bug 516, https://bugs.open64.net/show_bug.cgi?id=516
$ cat test.c
typedef float __v2f __attribute__ ((__vector_size__ (8)));
__v2f
foo3 (__v2f a0,__v2f a1,__v2f a2,__v2f a3)
{
return a0;
}
$ opencc -O0 -m32 -mmmx -c test.c
code review by David Coakley, forgot to mention in the log, thanks
On Wed, Jan 12, 2011 at 9:59 AM, wrote:
> Author: ycwu
> Date: 2011-01-11 20:59:27 -0500 (Tue, 11 Jan 2011)
> New Revision: 3454
>
> Modified:
> trunk/osprey/driver/table.c
> Log:
> fixed bug #709
> $cat test.c
> main(){}
>
>
that gcc gives an error in this case, which I think is also ok:
>
> $ gcc -I ./libs test.c -o test -I
> gcc: argument to '-I' is missing
>
> By the way, for any patch more than a few lines it is best to post it
> as an attachment. The automatic formatting can make it
ely until next week, but I have a
> few minor complaints... we can always address these later if the bug
> is blocking progress.
>
> The comment for want_directory() is exactly the same as the comment
> for is_directory(). This looks like an error.
>
> Also, I think it is stra
is blocking progress.
>
> The comment for want_directory() is exactly the same as the comment
> for is_directory(). This looks like an error.
>
> Also, I think it is strange to have a boolean function that always
> returns TRUE. Maybe the code generated by table.c should change
>
Hi, David
Could you please help review this patch
See https://bugs.open64.net/show_bug.cgi?id=709
In revision 3437 , the function want_directory has been remove
considering it's a dead function, but it's not true. This function
will always return TRUE no matter the path is a directory or not.
If
Hi
Can a gatekeeper help review this .
Most beginner will get this common issue when configure and make open64.
I make a small change in the configure file, the configuration will
fail when configure
under the top of trunk.
Index: configure.ac
===
Gang
>
>
> On Wed, Oct 20, 2010 at 5:13 PM, Wu Yongchong wrote:
>>
>> In current build process, we use gcc and gfortran to build the main
>> component of open64, and then use the built open64 to build libraries.
>> Some component like the c and c++ front end can only
In current build process, we use gcc and gfortran to build the main
component of open64, and then use the built open64 to build libraries.
Some component like the c and c++ front end can only build by gcc, and
some library can only be build by open64, so maybe you should not use
--with-build-compil
Hi
Did you configure and make the compiler under the top of trunk? It
will not work if you do so. The right process is
$ cd trunk
$ mkdir objs
$ cd objs
$ ../configure --profix=$INSTALLDIR
$ make -j 4
On Wed, Oct 20, 2010 at 4:13 PM, Gang Yu wrote:
> Hi,
>
> Does anyone have meet the problem
Hi,
can gatekeeper help review this patch,
Open64 use itself to build it's library, when building the share
library, the opencc default link libopen64rt_share.a, so all the
other libraries should depend on libopen64rt.
Without this dependency, it may fault when doing -j make.
following is a patch
This patch fixed the library makefile to delete the multiple
indentical target in the same rule.
This bug will cause library libu be buildtwice.
Can gate keeper help review this patch? Following is the patch
Index: configure
===
--- c
gt;> +#else
>>> + if (!MTYPE_is_complex(ctype))
>>> +#endif
>>>
>>> We can change to
>>> if (!MTYPE_is_complex(ctype))
>>>
>>> +#ifdef TARG_X8664
>>> if (ltype == MTYPE_V16C8 || MTYPE_is_complex(ltype))
>>> +
to
> if (!MTYPE_is_complex(ctype))
>
> +#ifdef TARG_X8664
> if (ltype == MTYPE_V16C8 || MTYPE_is_complex(ltype))
> +#else
> + if (MTYPE_is_complex(ltype))
> +#endif
>
> We can change to
> if (MTYPE_is_complex(ltype))
>
> 2010/9/5 Wu Yongchong
,16, MTYPE_V16C4 },
> 117 { MTYPE_V16C8, 128,128,128,16, 16,16, 0, 1, 0,
> "V16C8",MTYPE_CLASS_COMPLEX_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C8 },
>
> So that we can get rid of most of the #ifdef TARG_X8664 in the patch. But,
> since we change the mtypes.cxx, we ne
sorry, the last email has no attachment, here is the new patch
2010/9/5 Wu Yongchong :
> here is the new patch
> 2010/9/5 Wu Yongchong :
>> Hi
>> in ieee_module_support.c function _Ieee_get_underflow_mode_() does
>> not support on IA64.
>> Indeed, I set tow much #i
here is the new patch
2010/9/5 Wu Yongchong :
> Hi
> in ieee_module_support.c function _Ieee_get_underflow_mode_() does
> not support on IA64.
> Indeed, I set tow much #ifdef in
> osprey/libfi/mathlb/mathlb.gmakeinclude. There is just 1 file get
> compile error.
>
> 2010/9
e
> We can enable the module/c binding support/ieee/iso c/etc on IA-64. What's
> the problem if we compile these files on IA-64?
>
> 2010/9/2 Wu Yongchong
>>
>> Hi,
>> Can gatekeeper help review this patch.
>> Revision 3314 break the compiler in IA64 system
Hi,
Can gatekeeper help review this patch.
Revision 3314 break the compiler in IA64 system, this patch enclose
some of the change with #ifdef Macros .
--
yongchong
patch.diff
Description: Binary data
--
This SF.net Dev2
Hi,
I can not reproduce your problem, can you please give me the building
output in the attachment?
in my build process I can see the file genmodes
gcc -m32 -DKEY -DFE_GNU_4_2_0 -O2 -DTARG_X8664 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-defi\
review by Steve Ellcey.
This patch is a fixed in I386 and IA64 regression relative to the autoconfig
2010/7/19 :
> Author: ycwu
> Date: 2010-07-18 21:46:34 -0400 (Sun, 18 Jul 2010)
> New Revision: 3284
>
> Modified:
> trunk/Makefile.in
> trunk/configure
> trunk/configure.ac
> trunk/instal
Hi, steve
Thanks for your advice, I have make another patch, please have a look at it.
2010/7/15 Steve Ellcey :
> Yongchong,
>
> Rather then add an include of Makefile.override in all the targdir_lib
> Makefile.in files can we just put the Makefile.override code into
> the top-level Makefile.in f
Hi, steve
There are some error in IA64 and I386 system after your autoconfig patch.
1. In 32bit x86 system, we can not build the 64bit libraries.
2. In IA64 system, the former build static libraries, but the new
autoconfig will build dynamic libraries, we got some problem to build
dynamic librarie
61 matches
Mail list logo
