just curious, most of the change is comments from C++ "//" to C style. Why?
Sun
On Sat, Jul 3, 2010 at 8:39 AM, David Coakley wrote:
> Hello all,
>
> Could one of the gatekeepers please review the attached code cleanup
> patch? It is intended to eliminate the compilation warnings seen when
> bu
rning appears when using newer versions of gcc (> 4.2?) as the
> build compiler.
>
> On Fri, Jul 2, 2010 at 6:35 PM, Sun Chan wrote:
> > just curious, most of the change is comments from C++ "//" to C style.
> Why?
> > Sun
> >
> > On Sat,
are you interested in a different compilation model for IPA? I.e. say,
matching .I file for each .c input file? What is the purpose of your
studying the .I files?
The original purpose is to enable parallel compilation by the later backend
phases. I believe partitioning of the call graph to maximize
you can also use whirl2c, whirl2f... to convert the .I files back to
.c/c++/f files for easier reading and debugging.
Sun
On Tue, Jul 6, 2010 at 4:51 PM, Tianwei wrote:
>
>
> On Tue, Jul 6, 2010 at 4:17 PM, Li Shengmei wrote:
>
>> Hi,all
>>I want to know how the .I files which are gene
Chakrabarti [mailto:gautam.c...@yahoo.com]
> *Sent:* Wednesday, July 07, 2010 12:08 PM
> *To:* Sun Chan; Tianwei
> *Cc:* Li Shengmei; open64-devel@lists.sourceforge.net
>
> *Subject:* Re: [Open64-devel] The debug and generation of .I files during
> IPA??
>
>
>
&
change of such magnitude is just too much to handle by gatekeepers.
Personally, I don't think this is the way to go to request for
checkins. It amounts to just shoving to open64 community's throat
through shear size and tight timing of your own making. I had serious
design issue with one of your pr
Some clarifications. I am not a professor, but thx for giving me such
honor title :-)
I have not reviewed the automake, config diff. I am not qualified to
do the review. Can someone review that?
Thx!
Sun
On Wed, Jul 14, 2010 at 3:25 PM, zhangxingliang
wrote:
> Hi, all:
> Simplnano plans to merg
thx for Steve to review the automake related stuff. All that is left
is to wait for test results against the major targets with the new
changes
Sun
On Fri, Jul 16, 2010 at 2:27 AM, Steve Ellcey wrote:
> On Wed, 2010-07-14 at 15:25 +0800, zhangxingliang wrote:
>
>> (5) diff_of_automake: changes of
Please indicate who did the code review.
Thx!
Sun
On Sun, Jul 18, 2010 at 6:46 PM, wrote:
> 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/install_compiler.sh
> trun
please state who reviewed the code
Sun
On Mon, Jul 19, 2010 at 2:26 AM, wrote:
> Author: shenruifen
> Date: 2010-07-19 05:26:10 -0400 (Mon, 19 Jul 2010)
> New Revision: 3286
>
> Modified:
> trunk/osprey/wgen/wgen_expr.cxx
> Log:
> fix a stupid error of last commit
>
> Modified: trunk/osprey/wg
sorry. I am ok with the change, much better implementation. May I ask
where the deleted code originated (you can tell me privately)
Sun
On Tue, Jul 20, 2010 at 6:18 AM, Steve Ellcey wrote:
>
> I originally sent this patch out on July 1 but I have not gotten any
> reviews of it so I am resending
unfortunately, whirl and symbol table was deliberately not design to
have such capability. This is a design choice we made almost since day
one.
Sun
On Thu, Jul 22, 2010 at 11:00 AM, Li Shengmei wrote:
> Hi, all
> I want to modify the IR files(.I file) for some reason. I want to do
> the m
actually, his problem is not in wopt, he is asking about the
standalone inliner's loopnest stuff. Frankly, I don't believe loopnest
value can be set without the right analysis.
Sun
On Wed, Jul 21, 2010 at 11:07 PM, Gautam Chakrabarti
wrote:
> Hi,
>
> I am not sure why you are seeing no DO_LOOP/WH
I think this whole idea of trying to be cute for speed up in places
that are irrelevant is just bad engineering. please go ahead with the
change.
Sun
On Sat, Jul 31, 2010 at 5:03 AM, Steve Ellcey wrote:
>
> I was looking at more of the 'unaligned access' warnings that we get
> from open64 on IA64
as far as I know, HP compiler team should be your natural partner.
That team has extensive experience in ia64, and is the official
compiler team inside HP for ia64 linux, I think. Tuning for ia64 needs
a lot of know how with the microarchitecture (having been part of the
ia64 compiler at Intel for
Oh, U of Houston is another good partner choice. Extensive work on
openMP and open64
Sun
On Tue, Aug 3, 2010 at 9:47 PM, Sun Chan wrote:
> as far as I know, HP compiler team should be your natural partner.
> That team has extensive experience in ia64, and is the official
> compiler te
And they have worked on ia64 + open64 extensively too
Sun
On Wed, Aug 4, 2010 at 6:03 AM, Shin-Ming Liu wrote:
> Besides HP and University of Houston, Tsinghua University in Beijing is very
> active in OpenMP development.
> - Shin
> On Tue, Aug 3, 2010 at 3:52 AM, Anton Shterenlikht
> wrote:
>>
I suppose the same problem will occur for open64 internal flag -shared
sun
On Wed, Aug 4, 2010 at 6:48 AM, Steve Ellcey wrote:
> This patch is my proposed fix for bug 577, The problem is that when
> linking a program using the -pie (-fPIE, -fpie) option to create a
> position independent executa
you answered my question.
Pls go ahead with the checkin
Sun
On Wed, Aug 4, 2010 at 7:04 AM, Steve Ellcey wrote:
> On Wed, 2010-08-04 at 06:52 +0800, Sun Chan wrote:
>> I suppose the same problem will occur for open64 internal flag -shared
>> sun
>
> I am not sure what you
but this is a problem with the library itself, not the checkin.
Sun
On Tue, Aug 3, 2010 at 8:55 PM, Peng Yuan wrote:
> If libopen64rt_shared.a can be used for executable except for shared
> library, I'll support the checkin. Not perfect, but it can work for the
> current trunk. Otherwise we must
(i.e. not related in its original purpose), not a
necessary condition.
Sun
2010/8/3 Peng Yuan :
> The checkin will affect the use of the library. I suspect the corectness of
> using libopen64rt_shared.a for PIE executable, which the checkin works.
>
> On Wed, Aug 4, 2010 at 12:01 PM, Sun
the swp from sgi is for Mips. Much work was done by ICT and Tsinghua
to get swp work reasonably good for IA64. I don't know of blackbird
from Reservoir lab. Can you elaborate?
The swp from SGI was not well tuned for IA64 (I guess I am the only
one involved in this swp through all the phases and tra
who reviewed?
Sun
On Tue, Aug 3, 2010 at 8:11 PM, wrote:
> Author: shenruifen
> Date: 2010-08-03 23:11:36 -0400 (Tue, 03 Aug 2010)
> New Revision: 3301
>
> Modified:
> trunk/osprey/be/cg/gra_mon/gra_color.cxx
> trunk/osprey/be/cg/gra_mon/gra_create.cxx
> trunk/osprey/be/cg/gra_mon/gra_gran
> tirval difference.
>
> For example,
> int biluochun = 100;
>
> int foo ()
> {
> return biluochun;
> }
>
> -fPIC will generate GOT for variable biluochun. For -fPIE, the variable
> never need GOT. (But if compiler generates GOT, it is also correct, though
> ve
Thx for bringing out a code quality issue and i apologize for not
doing the 'gatekeeping' well.
Such is a common problem for "large scale" checkins. I have seen other
(different company) checkins when the scale is large. The sloppiness
goes beyond cosmetic. Any gatekeeper would have a hard time to
I think you are right.
Sun
On Sun, Aug 8, 2010 at 9:56 PM, Chen, Rui (Roger, TSG-GDCC-SH)
wrote:
> Hi all,
>
>
>
> This is the fix for bug 589 (https://bugs.open64.net/show_bug.cgi?id=589).
> Can gatekeeper help to review it?
>
>
>
> I attached the test case and patch. You can reproduce the probl
Folks,
Someone asked me this question and I'm not sure I know the exact
reason why. May be someone can help.
In wfe_decl.cxx, function
static void
Add_Inito_For_Tree (tree init, tree decl, ST *st)
The symbol, if initiailzed by user to zero, FE will change the storage
class to undefined global. W
the size of object files as well as
> executables (most probably aggregaes).
>
> Murthy
>
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Monday, August 09, 2010 2:31 AM
> To: Open64-devel
> Cc: grey0...@gmail.com
> Subject: [Open6
aning of "capability" you mentioned.
> Can you explain more detailed?
>
> If I don't modify the .I directly, I want to add some codes in WHIRL form.
> Is it feasible?
>
> Thank you very much.
> May
>
>> -Original Message-
>> From: Sun Chan [mai
this make no sense. Pathscale already changed the library to C
implementation. I believe the changes have been merged
Sun
On Tue, Aug 10, 2010 at 11:38 PM, Jian-Xin Lai wrote:
> The workaround is to link with -lstdc++.
>
> 2010/8/10 Hucheng Zhou :
>> Hi:
>> When I tried to use fbo, there is an
if the fix need to be in multiple places, perhaps make a template out of that?
Sun
On Thu, Aug 12, 2010 at 9:27 AM, Ye, Mei wrote:
> Hello Kalin,
>
>
>
> Looks like you missed another place in Simd_Finalize_Loops that may require
> a similar fix.
>
>
>
> -Mei
>
>
>
> _
;> >
>> >
>> > Note that with this change compiler/library builds configured with
>> >
>> > --with-build-lib-optimize=DEBUG can now be used for performance
>> >
>> > testing.
>> >
>> > - Breakup install rule into
looks good to me.
Sun
On Fri, Aug 27, 2010 at 7:06 AM, David Coakley wrote:
> Could a gatekeeper review the attached patch to osprey/be/lno/forward.cxx?
>
> The proposed log message (also attached) gives the details on the bug.
> Thanks,
>
> -David Coakley / AMD Open Source Compiler Engineering
is your question about implementation, or about concept?
Sun
On Fri, Aug 27, 2010 at 11:04 AM, Hucheng Zhou wrote:
> Hi:
> Is there critical edges existed in WOPT? One edge is said to be critical
> edge that its source node has more than one outgoing edges, and meanwhile,
> its destination node
Aug 27, 2010 at 12:39 PM, Sun Chan wrote:
>>
>> is your question about implementation, or about concept?
>> Sun
>>
>> On Fri, Aug 27, 2010 at 11:04 AM, Hucheng Zhou
>> wrote:
>> > Hi:
>> > Is there critical edges existed in WOPT? One edg
Mei,
I think you are right. The assertion about RID is a hint of something
else wrong (RID stands for region id).
Sun
On Sat, Aug 28, 2010 at 12:36 AM, Ye, Mei wrote:
> My guess is that by adding a label statement you may have prevented the
> elimination of an empty block or something similar whi
hough it probably doesn’t hurt if later phases can clean it up.
>
>
>
> -Mei
>
>
>
>
>
> From: ruifen Shen [mailto:shenr...@gmail.com]
> Sent: Sunday, August 29, 2010 6:31 PM
> To: Sun Chan; Ye, Mei
> Cc: open64-devel
>
>
in the front in an early pahse, it should be
> cleared or merged if the label is useless in my view.
>
> hi, sun.
> which block? rvi_emit?
>
>
>
> 2010/8/31 Sun Chan
>>
>> I wondered why there is such a block though.
>> Sun
>>
>&g
This sounds a bit too trivial. OTOH, I had problem with people not
putting one space after the "//" as comment.
This happens almost always with China trained engrs.
Please add that space. It helps to keep formats consistent and a bit
more easy reading
Sun
On Tue, Aug 31, 2010 at 10:55 PM, wrote:
ot between persons).
>
> Thanks,
> Gautam
> ________
> From: Sun Chan
> To: open64-devel@lists.sourceforge.net
> Sent: Tue, August 31, 2010 11:07:41 PM
> Subject: Re: [Open64-devel] r3332 - trunk/osprey/wgen
>
> This sounds a bit too trivial. OTOH, I
Sorry, I am not familiar with openMP code, but your arguments doesn't
seem to relate to the verifier. You are saying verifier will call
lower_mp(), causing that to be recursive?
Sun
2010/9/1 Jiangzhou HE :
> Hi, Jianxin,
>
> I think there are two reasons why the verifier should be removed from
> l
), so finally nested OpenMP directives will also be lowered), so
> we need to remove the verifier for lower_mp() (maybe add the same verifier
> in some upstream function).
>
> My argument is that it is not appropriate to call lower_mp() itself
> recursively, so the second soluti
I think its fine. I suspect there are currently no other target
(besides x86 and Itanium) that will produce these types. May be
nvidia?
Sun
On Tue, Sep 7, 2010 at 1:08 AM, Jian-Xin Lai wrote:
> This patch looks fine to me.
> But since it involves several components, maybe it's better to get globa
may be you can grep for all occurences of "mtype == MTYPE_C4" in wgen
and see if there is still other places needed fixing.
Yes, since the C8, c10 are now first class citizens, mmiload is not
appropriate (only for user defined types)
Sun
On Wed, Sep 8, 2010 at 7:25 AM, Min Zhao wrote:
> Hi,
>
> C
ex types (in different target).
>
> Thanks,
>
> Min
>
> On Tue, Sep 7, 2010 at 4:31 PM, Sun Chan wrote:
>>
>> may be you can grep for all occurences of "mtype == MTYPE_C4" in wgen
>> and see if there is still other places needed fixing.
>> Yes
please give a brief description of the bug. Or a simple test case. The
portion of code change is not enough for me to tell why F8 is the
right type, but not, say, F4, or V8
Sun
On Sat, Sep 11, 2010 at 2:58 AM, Yiran Wang wrote:
> Hi All,
> Could a gatekeeper please review it?
> Simply, the re
le, the operator > would
> like to promote the type of the two operands, so they match. So it would not
> provide type information for the sqrt intrinsic. So, the compiler simply
> generate something like
> VSTID...
> VSQRT ...
> The change is to set default type to F8, for s
ype for sqrt.
> Another solution may be to set the type to the operand. But I simply want to
> make it consistent to other intrinsics with similar issue (they solve it in
> this way).
>
> Best Regards,
> yiran
>
> On Fri, Sep 10, 2010 at 3:14 PM, Sun Chan wrote:
>>
>>>
>>> OK. I have added the verifier at lower_entry() and
>>> Process_Parallel_Region(), which will cover the whole program. I have
>>> attached the new patch.
>>>
>>> Thanks.
>>>
>>> Jiangzhou
>>>
>>> 2010/9
the wrap_around_unsafe flag is supposed to be used to guard that.
Also, it is supposed to be turn off for O3, as I recall
sun
On Wed, Sep 22, 2010 at 4:57 AM, Dror Maydan wrote:
> We ran into the following bug.
>
> int a[1024];
> void r(unsigned int n)
> {
> unsigned int i,j;
> for (i=0; i for
being able to do this again will be tremondous.
Sun
2010/9/22 "C. Bergström" :
> David Coakley wrote:
>> In my last patch to remove the bash dependencies from the Makefiles
>> (r3343), I changed the targdir_lib Makefile so that it no longer uses
>> a shell for-loop to build the libraries. This is
I don't know the installation scripts, so i'm not qualified. Since Mei
knows about it, I'll take her advice and pls go ahead
Sun
On Wed, Sep 22, 2010 at 6:00 AM, Ye, Mei wrote:
> Looks good to me.
> Though I am not a gate keeper on installation scripts, I supported
> libhugetlbfs in the past, s
Doug,
I can understand that. For us, inside our own company, this is the
standard answer when I communicate with my own folks.
Sun
2010/9/27 "C. Bergström" :
> Gilmore, Doug wrote:
>> I don't see that there is an issue here.
>>
>> Why don't you tell us what you think the potential issue
>> is so t
please checkin
Sun
On Mon, Sep 27, 2010 at 9:37 PM, Wu Yongchong wrote:
> 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
I'd like to see more detailed reasons why current model does not
easily support change of target (micro-arch). The reason why that was
implemented as dso is precisely for that reason. And we have (back at
SGI) done multiple generations of the same family (past, present and
future) by stating proces
there is probably some build graph problem that may cause hidden
dependency during compile. Likely introduced as people add new
capability and did not have large apps to test, instead of fixing the
problem later on, they simply disable it (just a wild guess, but it
used to work fine back then) You
I am fine with either fixes
Sun
2010/10/9 "C. Bergström" :
> Steve Ellcey wrote:
>> Index: osprey/driver/file_names.c
>> ===
>> --- osprey/driver/file_names.c (revision 3367)
>> +++ osprey/driver/file_names.c (working co
would you care to share your experimental patch such that we can come
up with the most appropriate implementation?
sun
2010/10/12 "C. Bergström" :
> Min Zhao wrote:
>>
>> Hi,
>>
>> We propose to make changes for componentizing optimization phases in
>> open64 at HP.
>>
>> The primary motivation fo
looks fine to me
Sun
On Tue, Oct 12, 2010 at 7:15 AM, Gilmore, Doug wrote:
> I have a fix for a Fortran front-end related bug that I
> would like to have someone review.
>
> A test case (two files) and a patch for the fix is
> attached to the bug report:
>
> https://bugs.open64.net/show_bug.cgi?i
looks fine to me.
Sun
On Tue, Oct 12, 2010 at 4:27 PM, Wu Yongchong wrote:
> 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 lib
i don't know, the original code has "close(fd) at the end, your new
code does not. is this by design?
Sun
On Wed, Oct 13, 2010 at 1:55 AM, Gilmore, Doug wrote:
> The patch is attached to the bug report:
>
> https://bugs.open64.net/show_bug.cgi?id=667
>
> Mei has already reviewed it, so it probabl
ok, I trust you are right. pls go ahead. (btw, with overflow, your
code might still have problem since yuo truncate and not report error)
Sun
On Wed, Oct 13, 2010 at 6:37 AM, Gilmore, Doug wrote:
>> -Original Message-
>> From: Sun Chan [mailto:sun.c...@gmail.com]
>
sorry, I am not used to discussing whirl issues in the abstract. would
you care to give a program statement so I can see exactly what you
ultimately want to do? say, x = y-z; or something like that? What I
don't see here is your final result, you only showed the rhs of the
expr.
Sun
On Thu, Oct 14
pls go ahead
Sun
On Fri, Oct 15, 2010 at 2:07 AM, Jian-Xin Lai wrote:
> Hi,
>
> Rev 3374 introduced a new field alter_rr to SI. But the IA-64 targ_info is
> not updated to generate the new field. That cuase problems on IA-64. Here is
> the patch to generate the new field:
> Index: access/ekapi_it
looks fine to me. Pls try again
sun
2010/10/16 "C. Bergström" :
> Jian-Xin Lai wrote:
>> HI,
>>
>> The attachment is the design document for WHIRL SSA. We have presented
>> this work on the open64 forum on Aug. 25, 2010. After that, we did
>> some changes and we are looking forward to checking in
can you give some detail how run_build is set? I agree with you on
principle the fix.
Sun
On Thu, Oct 21, 2010 at 7:49 PM, David Coakley wrote:
> In the Open64 driver, there is code to add a linker '-rpath' option
> for libraries that are included with the compiler (see
> postprocess_ld_args() in
MPILER=SELF is set for the
> LIB_ARGS and LIB2_ARGS.
>
> On Thu, Oct 21, 2010 at 7:56 PM, Sun Chan wrote:
>> can you give some detail how run_build is set? I agree with you on
>> principle the fix.
>> Sun
>>
>> On Thu, Oct 21, 2010 at 7:49 PM, David Coakl
For testing, I built the patched compiler with BUILD_COMPILER=GNU and
> then used that compiler to do a separate build with
> BUILD_COMPILER=OSP. For both compilers I did testing after deleting
> the build area to make sure that the original problem was fixed.
>
> On Thu, Oct 21, 2010
I think Murthy can approve that.
Sun
On Thu, Oct 28, 2010 at 6:30 AM, Jian-Xin Lai wrote:
> This patch looks fine to me. But it seems we don't have a local gate keeper
> for FORTRAN front end?
>
> 2010/10/21 Gilmore, Doug
>>
>> Sorry, I should have provided a link to the bug report:
>>
>> http:/
looks good. OTOH, is this the only place that uses set_operator? If
so, should they need to be changed to your new scheme?
Sun
2010/10/31 Chen, Rui (Roger, TSG-GDCC-SH) :
> I modified the patch a little bit, creating a new "WN_change_operator"
> method to avoid many duplicate assertions.
>
>
>
> P
Either we remove that or fix that, regardless of not ref'd
Sun
On Sun, Oct 31, 2010 at 11:41 PM, Hucheng Zhou wrote:
> Yes! So this bug was never exposed:)
>
> On Mon, Nov 1, 2010 at 2:39 PM, Yiran Wang wrote:
>>
>> eems like there is no reference at all
>
>
> --
> Institute of High Performance
ll WN_change_operator.
>
> Regards,
> Roger
>
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: 2010年11月1日 14:43
> To: Chen, Rui (Roger, TSG-GDCC-SH)
> Cc: open64-devel@lists.sourceforge.net
> Subject: Re: [Open64-devel] Review request
Is this a global replacement? IOW, will there be scope that ties with
name space(I doubt you have this in mind, just want to be clear)?
Sun
On Sun, Nov 7, 2010 at 10:55 PM, Li Shengmei wrote:
> Hi, all
> I want to add a new pragma option in Open64. I want to rename the
> functions' name wi
with new_func_name.
>
> Thanks
> May
>
>> -----Original Message-
>> From: Sun Chan [mailto:sun.c...@gmail.com]
>> Sent: Monday, November 08, 2010 4:35 PM
>> To: Li Shengmei
>> Cc: open64-devel@lists.sourceforge.net
>> Subject: Re: [Open64-devel] About
Func3();
> #pragma end
> }
> Though the definitions of Func2() are the same, the calls in NEW_CALL1 and
> NEW_CALL2 are different.
>
> Thanks,
> May
>
>> -Original Message-
>> From: Sun Chan [mailto:sun.c...@gmail.com]
>&g
this problem is too simple to be wrong, makes me think something
really bad has happened. Can someone try the case for a different
target (such as IA64, SL, Mips ...?)
I'd like to know why this fails with a broader code fragment for review.
Mike,
What do you think?
Sun
On Thu, Nov 18, 2010 at 5:
> 2010/11/18 Sun Chan
>>
>> this problem is too simple to be wrong, makes me think something
>> really bad has happened. Can someone try the case for a different
>> target (such as IA64, SL, Mips ...?)
>> I'd like to know why this fails with a broader code fra
.size line3, 1
> line3: # 0x0
> .skip 1
> .org 0x1
> .align 0
> .type line4, @object
> .size line4, 1
> line4: # 0x1
>
>
> Gang
>
>
> On Fri, Nov 19, 2010 at 12:04 AM, Sun Chan wrote:
>>
&
zqing,
can you send the source file?
Thx!
Sun
On Fri, Nov 19, 2010 at 9:48 AM, Gang Yu wrote:
> In SL, as for the proposed case, control does not goes to the suggested
> patch.
>
> Gang
>
>
> On Fri, Nov 19, 2010 at 9:26 AM, Sun Chan wrote:
>>
>> thx Gang!
&g
Gang,
The code tells me that SL should have gone through the same logic. Can
you double check why your's work?
Sun
On Thu, Nov 18, 2010 at 5:41 PM, 朱庆 wrote:
> Hi, All
>
> Can gatekeeper help review this fix?
>
> Case a.c:
> struct line { char a[0];};
> static struct line line3;
> static struct l
ok. So this is something introduced no in the original code.
Pls check in. However, your print string does not need an extra '\n'
in front and should not.
Sun
On Thu, Nov 18, 2010 at 5:41 PM, 朱庆 wrote:
> Hi, All
>
> Can gatekeeper help review this fix?
>
> Case a.c:
> struct line { char a[0];};
is this code from somewhere else?
Sun
On Sat, Nov 20, 2010 at 3:01 AM, Jian-Xin Lai wrote:
> I read the patch and it looks fine to me.
>
> 2010/11/18 Gilmore, Doug
>>
>> The bug fix is attached to the bug:
>>
>> https://bugs.open64.net/show_bug.cgi?id=686
>>
>> Could someone review this patch wh
to the copyright notices will
> indicate the source.
>
> Also when a patch comes from elsewhere, my commit log message will identify
> the source.
>
> Doug
>
>> -Original Message-
>> From: Sun Chan [mailto:sun.c...@gmail.com]
>> Sent: Friday, November 1
your msg_str could get out of bound too (not now, but some fixes later on).
Sun
On Mon, Nov 22, 2010 at 3:31 PM, David Coakley wrote:
> Recently I tried to build Open64 with gcc-4.5.1 and FORTIFY_SOURCE
> checking turned on. The Fortran frontend would not run at all because
> of a failing buffer
str buffer size seemed small. However, I
> didn't see any immediate problems and there were no more complaints
> from the FORTIFY_SOURCE checking so I left it as-is.
>
> On Mon, Nov 22, 2010 at 4:53 AM, Sun Chan wrote:
>> your msg_str could get out of bound too (not now, but so
a most economic way to do that is to use #define like SZ_STR
then afterwards, assert that strlen(msg_str) < SZ_STR
Sun
On Tue, Nov 23, 2010 at 8:11 AM, Sun Chan wrote:
> If we are fixing that, we might as well fix potential issues. E.g.
> check for strlen and truncate, use alloca, ...
to the
> changes in the submitted patch. If that is the case, then I would
> rather make them as a separate commit as I have already tested the
> patch and I know that it fixes the FORTIFY_SOURCE issue.
>
> On Mon, Nov 22, 2010 at 4:13 PM, Sun Chan wrote:
>> a most economic
ld add a static assert that 13 < (sizeof(msg_str) /
> sizeof(msg_str[0])), although the above is simple enough that the
> FORTIFY_SOURCE checking will detect an overrun at compile-time. Thus
> we can be sure that no overruns will happen at run-time for msg_str.
> Is this satisfactor
ea.
>
> Doug
>> -Original Message-
>> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
>> Sent: Wednesday, November 24, 2010 12:03 PM
>> To: David Coakley; Sun Chan
>> Cc: open64-devel
>> Subject: Re: [Open64-devel] patch for building Fortran frontend with
use fortran to do that. Try some program in Nasa7
Sun
On Wed, Nov 24, 2010 at 6:57 PM, Gilmore, Doug wrote:
> To test out my change for bug 686 it would be good to have a test case in
> which common blocks are being split by IPA.
>
> Does anyone know of any programs that are compiled with IPA, w
ze of the destination
> buffer at compilation time.
>
> The handling of msg_str is the only difference in the revised patch.
> I also added more explanation to the proposed log message in msg.txt.
>
> On Wed, Nov 24, 2010 at 1:49 PM, Sun Chan wrote:
>> I think some existing co
looks fine, except a couple of minor things
Sun
in emitter.cxx, is this right
else {
new_idx = it->second + 1;
}
??
shouldn't this be it->second()?
WSSA_VSYM_TYPE, I would add FmtAssert outside of the switch. If people
add new cases and forgot to return inside the case stmt, you will have
please go ahead
Sun
On Wed, Dec 1, 2010 at 8:36 AM, David Coakley wrote:
> Could a gatekeeper review the following small patch to configure.ac?
> (I will also update "configure" by running autoconf.)
>
> The patch removes libelf from the list of target libraries since it is not
> used.
>
> There
one question, is this ftable thing always return null if not
successful in simplifying?
Sun
On Wed, Dec 1, 2010 at 12:42 PM, Ramanarayanan, Ramshankar
wrote:
> Hi
>
>
>
> I would like a code review for the attached file
> “extract_bits_with_simpnode.diff”. This is a fix for a recent regression
>
o WN_SimplifyIload,
> WN_SimplifyIntrinsic, WN_SimplifyExp1, WN_SimplifyCvtl, WN_SimplifyExp2,
> WN_SimplifyExp2.
>
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Wednesday, December 01, 2010 11:02 AM
> To: Ramanarayanan, Ramshankar
> Cc: op
Please check in
Sun
On Wed, Dec 1, 2010 at 2:33 PM, Ramanarayanan, Ramshankar
wrote:
> Thanks, yes, I wrote the code in the diff.
>
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Wednesday, December 01, 2010 11:26 AM
> To: Ramanarayanan, Ramsh
This fix would have been in the merge I coordinated but never "checked
in". I assume there is no copy right issues since it is before the
change to gpl3.0
Sun
On Fri, Dec 3, 2010 at 8:17 AM, Gilmore, Doug wrote:
> Again, the bug fix is attached to the patch.
>
> https://bugs.open64.net/show_bug.
I suggest someone check the license compatibility (or whatever) before
the checkin. This is likely beyond gatekeeper capability
Sun
On Fri, Dec 3, 2010 at 8:41 AM, Gilmore, Doug wrote:
>
>
>> -Original Message-----
>> From: Sun Chan [mailto:sun.c...@gmail.com]
>> Sen
did add a copyright notice for the change that I just added.
>
> If people think that my interpretation of copyright law is too
> strict then we can go ahead and apply that patch instead.
>
> Doug
>
>> -Original Message-
>> From: Sun Chan [mailto:sun.c..
where did this BSD copy right come from?
Sun
2010/12/4 "C. Bergström" :
> s...@open64.net wrote:
>> Author: laijx
>> Date: 2010-12-03 15:33:25 -0500 (Fri, 03 Dec 2010)
>> New Revision: 3417
>>
>> Modified:
>> trunk/osprey/common/com/intrn_entry.def
>> Log:
>> Change the license of intrn_entry.d
1 - 100 of 513 matches
Mail list logo
