> -Original Message-
> From: David Coakley [mailto:dcoak...@gmail.com]
> Sent: Sunday, August 26, 2012 8:37 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] review request for changes to libhugetlbfs
>
> Hi Doug,
>
> I reviewed the
> -Original Message-
> From: "C. Bergström" [mailto:cbergst...@pathscale.com]
> Sent: Thursday, August 23, 2012 3:15 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] review request for changes to libhugetlbfs
>
> On 08/24/12 05:13 A
I have two changes to libhugetlbfs that I would like to have reviewed.
The first is just a fix to eliminate a compiler warning.
The second is a change to the library to handle situations where a
huge page mapping would exhaust the huge page limit. Previously no
huge pages would be allocated (whe
I haven't heard back on the review of several of the patches that
I sent out.
For convenience I attached the patches to the message (the patch
number may have change due to running git rebase):
CG:
0004-Changed-a-test-in-INTERFERE_MGR-Create_End.patch
CG/Intrastructure:
0005-X8664-m32-FP-compila
Sorry, I forgot to add the CR info line to the commit log message for r4013 and
r4014.
I just ran svn propedit to edit the log entries, so they now read:
r4014 | dgilmore | 2012-08-20 13:04:42 -0700 (Mon, 20 Aug 2012) | 4 l
Per David's message, he already reviewed the change so if there are not
any objections I'll commit the change in the next few days.
Doug
-Original Message-
From: David Coakley [mailto:dcoak...@gmail.com]
Sent: Monday, August 13, 2012 2:15 PM
To: Gilmore, Doug
Subject: Re: F
Are there still objections to committing this patch?
Doug
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Thursday, August 02, 2012 11:15 PM
> To: Jian-Xin Lai
> Cc: Gilmore, Doug; open64-devel
> Subject: Re: [Open64-devel] Review request: fixing iss
better performance.
Could a gatekeeper review this patch?
Thanks,
Doug
> -----Original Message-
> From: Gilmore, Doug
> Sent: Wednesday, August 08, 2012 6:26 PM
> To: 'Sun Chan'
> Cc: '"C. Bergström"'; 'open64-devel'
> Subject: RE: [Open
I forgot that I was going to add some comments in the second patch.
I'll be sending out another version of that patch.
Doug
> -Original Message-
> From: Gilmore, Doug
> Sent: Wednesday, August 08, 2012 1:05 PM
> To: 'Sun Chan'
> Cc: "C. Bergström&qu
e compiler and compares the
generated assembly files.
Could a gatekeeper review these changes when they have the chance?
Thanks,
Doug
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Saturday, August 04, 2012 2:31 PM
> To: Gilmore, Doug
> Cc: &qu
I was looking into other issues yesterday so I was sidetracked.
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Saturday, August 04, 2012 3:24 AM
> To: Gilmore, Doug
> Cc: "C. Bergström"; open64-devel
> Subject: Re: [Open64-devel] R
WHIRL when
building with different variants of the compiler
(debug/release/32-bit/64-bit).
Doug
> -Original Message-
> From: Jian-Xin Lai [mailto:laij...@gmail.com]
> Sent: Thursday, August 02, 2012 2:05 AM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open6
> -Original Message-
> From: David Coakley [mailto:dcoak...@gmail.com]
> Sent: Thursday, August 02, 2012 2:02 AM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] Review request: fixing issues when building
> the compiler as 64-bit binaries
>
Sorry for the delay in my reply.
> -Original Message-
> From: "C. Bergström" [mailto:cbergst...@pathscale.com]
> Sent: Saturday, July 28, 2012 11:09 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] Review request: fixing issues when build
We found an long standing bug that causes the C/C++ FE to generate a
segmentation fault on exit when SPIN is being written to the output file.
Note that you need to build the compiler 64 bits to expose the problem (at
least with the example that I have provided).
The problem occurs when the gen
2012 10:43 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] (no subject) (make_libdeps change version
> 2)
>
> I guess I read wrong. I am not the one to review build makefiles :-)
> Sun
>
> On Fri, Apr 6, 2012 at 1:41 PM, Gilmore, Doug
> wrot
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Thursday, April 05, 2012 7:19 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] (no subject)
>
> looks like you folks are making the binary one monolithic executable, no
Folks probably noticed that I backed out my "make_libdeps rule"
change.
I attached a new version of the patch that works with old
versions of make.
Could someone review this change when they have the chance?
Thanks,
Doug
make_libdeps_v2.patch
Description: make_libdeps_v2.patch
---
Ooops, forgot to add "CR: Sun Chan".
I just used "svn propedit" to add this.
Doug
-Original Message-
From: s...@open64.net [mailto:s...@open64.net]
Sent: Tuesday, April 03, 2012 6:26 PM
To: open64-devel@lists.sourceforge.net
Subject: [Open64-devel] r3901 - trunk/osprey/linux/make
Autho
Sounds good with me -- thanks,
Doug
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Tuesday, April 03, 2012 5:54 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] Query on dependencies for libraries
>
> let'
We noticed that header file dependencies in the library builds
were not working when building shared objects.
This is a problem with the make_libdeps rule.
I can think of two options:
1) The definition of this rule for NVISA seems to be appropriate for
X8664. I attached the patch for this change
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Monday, April 02, 2012 5:39 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] review request -- CG
>
> looks fine with ebo fix.
Thanks!
> for the other fix, shouldn
This patch fixes initializations of several MEM_POOLs in
ebo_special.cxx, which eliminates many memory pool initialization
trace warnings when the compiler is built in debug mode.
Could a gatekeeper review this change when they have a chance?
Thanks,
Doug
ebo_special_pool.patch
Description: eb
The attached patch fixes a bug in DSP_SCH::Compute_Insn_Size().
Some operations have an opcode variant which assume that rax/eax is an
operand/result. Thus when this register is being targeted no Mod R/M
byte is needed, thus the instruction is 1 byte shorter.
Could a gatekeeper review this chang
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Tuesday, March 20, 2012 6:30 PM
> To: open64-devel
> Subject: [Open64-devel] bug fix to x8664/ebo_special.cxx
>
> We found that adding new fields to the OP structure caused a
> segment
We found that adding new fields to the OP structure caused a
segmentation fault in the build of SPEC dealII during code generation.
I tracked this down to a Chi node being assigned the _base field in a
POINTS_TO structure, which normally holds a pointer to ST entry, being
incorrectly interpreted.
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Saturday, March 17, 2012 2:56 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] Fix to bug 917
>
> The BE uses the same const fold in simplifier.
> to include s
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Saturday, March 17, 2012 10:37 AM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] Fix to bug 917
>
> which part of const_fold functions do you intend to use? Or are you
I originally sent a message on this, noting the issue in the front end.
I'll forward the message again.
Doug
From: Chandrasekhar Murthy [mailto:mur...@sgi.com]
Sent: Saturday, March 17, 2012 8:56 AM
To: Gang Yu
Cc: open64-devel
Subject: Re: [Open64-devel] Review request for fix the O0-DCE bug(bu
Other Fortran front ends are capable of folding calls to intrinsics that
have constant arguments in parameter statements, but this functionality
is missing in the Open64 front end.
As a first cut, I went to the process of handling this for the real
intrinsic. The patch and test case is attached.
, November 21, 2011 2:51 PM
To: Gilmore, Doug
Cc: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] FW: CG minor cleanup review request
sure
Sun
On Tue, Nov 22, 2011 at 5:56 AM, Gilmore, Doug
mailto:doug.gilm...@amd.com>> wrote:
Sorry for the delay in getting back, Jianxin had a dif
Sorry for the delay in getting back, Jianxin had a different proposal: we can
define a new function CGTARG_Is_Shift_Redundant() and implement it for all
targets.
Sun: how does that sound?
Doug
From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
Sent: Wednesday, November 09, 2011 2:59 PM
To: Sun
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Wednesday, November 09, 2011 2:41 PM
To: Gilmore, Doug
Cc: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] FW: CG minor cleanup review request
Or let CGTARG_Is_Right_Shift_Op() return false for X86 at where it is defined
[Doug
I see that another Post-5.0 change has been committed to the trunk.
Could someone review this change when they have a chance.
Thanks,
Doug
From: Gilmore, Doug
Sent: Wednesday, October 19, 2011 11:57 PM
To: Jian-Xin Lai
Cc: open64-devel@lists.sourceforge.net
Subject: RE: [Open64-devel] CG
s/got it/got in/
Sorry about that.
Doug
From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
Sent: Wednesday, October 19, 2011 11:33 PM
To: Jian-Xin Lai
Cc: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] CG minor cleanup review request
I wasn't too concerned about when it g
I wasn't too concerned about when it got it. I just wanted to know what people
thought was a better stylistic solution to this problem in the long term.
Doug
From: Jian-Xin Lai [mailto:laij...@gmail.com]
Sent: Wednesday, October 19, 2011 11:13 PM
To: Gilmore, Doug
Cc: open64-
I noticed tons of warnings associated with CGTARG_Is_Right_Shift_Op()
when I compiled a source file in CG with "-Wall -O2".
The patch cleans up the warnings.
Note that the only use for CGTARG_Is_Right_Shift_Op() is the following
code in cgemit.cxx:
if (CGTARG_Is_Right_Shift_Op (op)) {
I haven't heard back on this one.
Could a gatekeeper take a look at this change when he or she has the chance?
Thanks,
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Friday, October 07, 2011 6:42 PM
> To: open64-devel@list
Sorry about the flub.
This fix looks good to me.
Thanks!
Doug
> -Original Message-
> From: 朱庆 [mailto:zqing1...@gmail.com]
> Sent: Tuesday, October 11, 2011 12:40 AM
> To: open64-devel@lists.sourceforge.net
> Subject: [Open64-devel] Code review request for bug880, build fail
> caused by
From: Jian-Xin Lai [mailto:laij...@gmail.com]
Sent: Friday, October 07, 2011 11:21 PM
To: Gilmore, Doug
Cc: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] Fix for bug 771, problem in global value numbering.
Looks like the opt_vn.cxx_patch is unnecessary?
[Doug: ] Right, the
This change causes the driver to generate an error if -pg is supplied with
either -HP:bd or -HP:bdt.
I just added a comment to the bug about the issues involved:
https://bugs.open64.net/show_bug.cgi?id=744#c3
I plan to leave this bug open, but at a lower priority since there is a chance
that t
There are two changes I would like to have reviewed.
One is trace_cleanup.patch, which cleans up CODEREP
tracing output in WOPT. Without the patch the following
tracing output is generated:
> LDRC F10 0x0x80b67e8 flags:0x0 b=-1
> LDRC F10 0x0x80b68d8 flags:0x0 b=-1
> F10DIV isop_flags:0x
> From: Gautam Chakrabarti [mailto:gautam.c...@yahoo.com]
> Sent: Monday, June 13, 2011 1:31 AM
> To: open64-devel@lists.sourceforge.net; Gilmore, Doug
> Subject: Re: [Open64-devel] review request IPA global file table
> implementation -- bug 675
>
> Hi Doug,
>
Thanks!
Doug
-Original Message-
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Monday, August 15, 2011 7:06 PM
To: Gilmore, Doug
Cc: Open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] review request for bug in wn_lower.cxx
looks ok to me
Sun
On Tue, Aug 16, 2011 at 9:35
I uncovered a problem exposed by the debug build:
https://bugs.open64.net/show_bug.cgi?id=857
I attached a trivial fix, could a gatekeeper review/approve the change when
they have the chance?
Thanks,
Doug
bug857.patch
Description: bug857.patch
---
I think it would be good that we get a signed certificate, not doing so makes
Open64 look like a Podunk project, which it is not.
It only costs several hundred dollars a year and I would be happy to contribute
$50 a year to help make this happen.
Note that Open64 appears to be a SPI member pro
Thanks for the comments.
Hopefully I'll have a new version of the patch ready for review in the near
future.
Doug
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Monday, June 13, 2011 10:42 AM
To: Gautam Chakrabarti
Cc: open64-devel@lists.sourceforge.net; Gilmore, Doug
Subject: Re: [O
@lists.sourceforge.net; Gilmore, Doug
Subject: Re: [Open64-devel] Review request: fix to make -IPA:output_file_size
work properly
Hi Doug,
I believe this option is actually working as expected. Maybe it needs to be
better documented. The code (config_ipa.cxx) says this option is supposed to
specify the percentage
While tracking down the fix to bug 675, we noticed that -IPA:output_file_size
wasn't working properly.
I attached a patch to make this work better (this is a worthwhile
option to use from time to time if you are tracking down a back end
bug since it essentially allows IPA to generate one function
Attached is a patch that fixes bug 675 (line numbers of inlined routines
is broken by IPA).
The fix is basically described in a comment attached to the bug (which I have
cleaned up a bit):
Currently line number information in WHIRL statements for code being
inlined is
being replaced with
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Monday, May 23, 2011 6:26 PM
> To: Ye, Mei
> Cc: open64-devel@lists.sourceforge.net
> Subject: Re: [Open64-devel] code review - fix for Bug #778
> LFTR is not a safe optimization and never will be
> Sun
Note Mei's com
This patch fixes a "use before defined" problem exposed by building
gamess with -Ofast -apo -IPA:noinline, which can cause a segmentation
fault in the compiler during LNO.
The failure signature is that a segmentation fault occurs in
IPA_WN_MAP_Get() when Any_Loop_In_SNL_Parallelizable() is called
We saw a hard-to-reproduce runtime regression in SPEC Leslie3 that was
due the field Prefer_Fuse not being initialized in an instance of
the DO_LOOP_INFO class that was constructed with:
DO_LOOP_INFO::DO_LOOP_INFO(DO_LOOP_INFO *dli, MEM_POOL *pool)
I attached a patch to fix this problem.
Also I
We are having problems connecting to the SVN server.
Is anyone else seeing this?
Doug
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has ext
ff
openf95 INTERNAL ERROR:
/scratch/dgilmore/sot-pp2/bd/local/lib/gcc-lib/x86_64-open64-linux/4.2/be
returned non-zero status 1
I attached the test.
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Tuesday, May 03, 2011 4:41 PM
> To: open64-devel
s and probably more problems in the compiler.
Doug
> -Original Message-
> From: Gilmore, Doug
> Sent: Monday, May 02, 2011 6:21 PM
> To: open64-devel@lists.sourceforge.net
> Subject: RE: [Open64-devel] r3574 - in trunk/osprey/common/com: . MIPS
> NVISA SL ia64 loongson ppc
With this change my debug build of the compiler on x86-64, that is,
configure with --with-build-optimize=DEBUG, breaks during the library build:
### Assertion failure at line 259 of
/local/home/dgilmore/sot-pp1/bd/osprey/../../osprey/common/com/x8664/targ_const.cxx:
### Compiler Error during Writ
I have already started looking into the issue:
https://bugs.open64.net/show_bug.cgi?id=771
Doug
> -Original Message-
> From: Wu Yongchong [mailto:wuyongch...@gmail.com]
> Sent: Wednesday, April 13, 2011 2:34 PM
> To: Nelson H. F. Beebe
> Cc: open64-devel
> Subject: Re: [Open64-devel] floa
I attached the test and patch that were already attached to the bug.
The change was ported from the PSC 3.3 beta.
Could a gatekeeper review/approve this change when he or she has a chance?
Thanks,
Doug
bug758.f
Description: bug758.f
bug758.patch
Description: bug758.patch
---
I attached the test and patch that were already attached to the bug.
transcript of session that reproduces bug:
$ openf90 bug757.f90 -mso -O3 -c
### Assertion failure at line 458 of
/scratch/dgilmore/sot-pp1/bd/osprey/../../osprey/be/opt/opt_wn.cxx:
### Compiler Error in file ./gfort
I attached the test and patch that were already attached to the bug.
The text in the comment associated with patch attachment is:
The comment above the code I changed is:
// For example,
//I4I4LDID 41 <1,4,.preg_I4> T<4,.predef_I4,4> # i
//U4INTCONST 8 (0x
Could a gatekeeper review this change soon?
Thanks,
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Thursday, March 10, 2011 9:45 PM
> To: open64-devel@lists.sourceforge.net
> Subject: [Open64-devel] review request for workaround
Could a gatekeeper review this change soon?
Thanks,
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Thursday, March 10, 2011 9:19 PM
> To: open64-devel@lists.sourceforge.net
> Subject: Re: [Open64-devel] request for code review for
Is there any chance that a gatekeeper could review this change soon?
Thanks,
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Thursday, March 10, 2011 12:22 PM
> To: open64-devel@lists.sourceforge.net
> Subject: [Open64-devel] Review
Sorry for supplying a sloppy fix this issue.
The problem was exposed by a user so, so getting I think it is important that
we supply some sort of fix that prevents the compiler assertion for the current
release.
The problem was introduced when lowering in WOPT started to convert complex
types
I forgot to mention that the compile time problem will be fixed with the patch,
but the tests will abort unless the patch to bug 742 is also applied.
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Thursday, March 10, 2011 4:27 PM
> To:
This fix to this bug is straightforward, when libhugetlbfs is remapping program
segments it must check to see if memory has already been allocated (the runtime
startup invoked when compiling an app with -pg will do this).
If so, the segment to be copied must be extended to include this allocated
I attached patch that fixes issues exposed by bug 743.
The problem is that for each program unit, the compiler is currently generating
a new symbol for each thread private pointer array (this symbol points to the
array of pointers that point to the memory associated each threads version of
the
The OpenMP 2.5 SPEC states:
2.8.2 threadprivate Directive
...
Each copy of a threadprivate object is initialized once, in the manner
specified by the program, but at an unspecified point in the program
prior to the first reference to that copy.
I attached a test example that works with gcc, icc,
The expansion of I8/U8 loads is broken for -mcmodel=medium:
Executing on host: openf90 ./gfortran.dg/bug736.f -O0 -mcmodel=medium -lm
-o ./bug736.exe(timeout = 300)
/tmp/dgilmore/cco.jUK4px: In function `MAIN__':
/scratch/dgilmore/sanity/test/testsuite/bug736.f:17: relocation truncated
A test and a patch is attached to the bug.
It is a run time bug that is only exposed when team size is 1.
https://bugs.open64.net/show_bug.cgi?id=728
Could a gatekeeper review this change when they have the chance?
Thanks,
Doug
---
I haven't heard back on this one.
Can a gatekeeper take a look it when they have a chance?
Thanks,
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Monday, February 14, 2011 10:58 AM
> To: open64-devel@lists.sourceforge.net
> Su
I have a fix for bug 725, which it is attached to the bug report:
https://bugs.open64.net/show_bug.cgi?id=725
Could a gatekeeper review/approve the patch?
Thanks,
Doug
--
The ultimate all-in-one performance toolkit: I
Sun's experiment worked for me:
$ opencc -O0 -Wb,-PHASE:p,-tf3,-tra bug588-1.c -c -keep
$ grep -i preopt bug588-1.t
== Driver dump after PREOPT ==
$ opencc -O0 -Wb,-tf3,-tra bug588-1.c -c -keep
bug588-1.s: Assembler messages:
bug588-1.s:63: Error: Incorrect register `%rax' used wit
I added a new test example to bug 615:
https://bugs.open64.net/show_bug.cgi?id=615
AFAICS, if conditions are already folded so the DCE processing needed
is very straightforward.
If we need to add an extra pass to handle, this the detection of called
static inline functions (needed to fix bug 615
I'll update the comment to state the that change was approved by Sun.
Doug
> -Original Message-
> From: s...@open64.net [mailto:s...@open64.net]
> Sent: Thursday, January 20, 2011 10:34 AM
> To: open64-devel@lists.sourceforge.net
> Subject: [Open64-devel] r3466 - in trunk/osprey: be/com co
There is a test example and the bug fix patch attached to the bug:
https://bugs.open64.net/show_bug.cgi?id=719
Could a gatekeeper review the change when they have the chance?
Thanks,
Doug
--
Gaining the trust of on
I'll update the commit log entry for r3450, the fix was for bug 705 not 703.
Doug
> -Original Message-
> From: s...@open64.net [mailto:s...@open64.net]
> Sent: Monday, January 10, 2011 12:27 PM
> To: open64-devel@lists.sourceforge.net
> Subject: [Open64-devel] r3450 - trunk/osprey/wgen
>
There two mods in r3403 that we need to back out since they break when when the
F90 front end is built with debugging/tracing enabled.
I just filed a bug concerning the build of the FFE with debugging/tracing
enabled:
https://bugs.open64.net/show_bug.cgi?id=720
As it stands now only the compil
When building Open64 on RHEL 6.0 and building a program with libhugetlbfs, a
runtime link error occurs:
opencc hugebss.c -HP:bdt=2m:heap=2m
/local/home/dgilmore/sot-pp1/bd3410/local//lib/gcc-lib/x86_64-open64-linux/4.2/libhugetlbfs_open64.so:
undefined reference to `S_ISDIR'
collect2: ld return
Sorry I, neglected to add a comment that Mei reviewed the change and Sun
approved.
I'll update the comment.
Doug
> -Original Message-
> From: s...@open64.net [mailto:s...@open64.net]
> Sent: Wednesday, December 15, 2010 4:01 PM
> To: open64-devel@lists.sourceforge.net
> Subject: [Open64
There was a performance issue with the original fix to:
https://bugs.open64.net/show_bug.cgi?id=667
Attached to the bug is an update that I ported from the official repository for
libhugetlbfs.
Mei has already reviewed the change.
Could a gatekeeper please review/approve the change for me?
T
While testing out IPA filename generation fix (see bug 676), I noticed
that IPA compiles would sometime generate:
/bin/sh: line 0: [: mcf.ipakeep/1.t: binary operator expected
I attached a patch to fix this issue, also there is a small semantic
change that is described in a comment included in th
Bob Scollard is in the process of fixing the IPA line/file numbering problem:
https://bugs.open64.net/show_bug.cgi?id=675
and I noticed that I couldn't enable DevWarn messages, or enable the generating
ID/address information in WHIRL trace output when the appropriate flags were
passed to ipa_li
Could a gatekeeper review this change when they have the chance?
Thanks,
Doug
From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
Sent: Friday, December 03, 2010 1:43 PM
To: open64-devel
Subject: Re: [Open64-devel] review request for a fix to bug 628, backend
assertion with popcount builtin
I
The licensing change is due to that intrn_entry.def was derived from
files intrn_info.cxx and wintrinsic.h.
You can see this if you take a look at the commit in which
intrn_entry.def was created, r1764, see the attached file od1764.patch
to the last message I sent to you, which contains the contex
I updated the patch attached to the bug report to reflect Jian-Xin's commit:
https://bugs.open64.net/show_bug.cgi?id=628
Is it OK if I commit this patch?
Doug
From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
Sent: Friday, December 03, 2010 12:35 PM
To: Jian-Xin Lai
Cc: open64-devel
Su
Looks good, thanks!
Doug
From: Jian-Xin Lai [mailto:laij...@gmail.com]
Sent: Friday, December 03, 2010 12:11 PM
To: Gilmore, Doug
Cc: Sun Chan; open64-devel
Subject: Re: [Open64-devel] review request for a fix to bug 628, backend
assertion with popcount builtin
I will copy the license from the
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Thursday, December 02, 2010 4:22 PM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] review request for a fix to bug 628,
> backend assertion with popcount builtin
>
&g
Again, the bug fix is attached to the patch.
https://bugs.open64.net/show_bug.cgi?id=628
Could someone take a look at this when they have the chance?
Thanks,
Doug
--
Increase Visibility of Your 3D Game App & Earn a C
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, where split common
blocks are being generated?
Thanks,
Doug
Arggh, I neglected to take off the extra pair of parenthesis on the invocation
of GEN_MSG.
Anyway, you get the idea.
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Wednesday, November 24, 2010 12:03 PM
> To: David Coakley; Sun Chan
Here is something to consider. Don't worry about compile time checking,
just detect that there are problems at runtime, and avoid overflow.
Change:
char msg_str[30];
To:
/* Use a large buffer here, since we really want to avoid generating an
error message
* when generating a
Michael Lai review this change for me. Do I have the approval of a global
gatekeeper to commit this change?
Doug
> -Original Message-
> From: Gilmore, Doug
> Sent: Monday, November 15, 2010 5:19 PM
> To: 'open64-devel@lists.sourceforge.net'
> Subject: r
Doug
> -Original Message-
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Friday, November 19, 2010 4:28 PM
> To: Jian-Xin Lai
> Cc: Gilmore, Doug; open64-devel@lists.sourceforge.net
> Subject: Re: [Open64-devel] review request for fix to bug 686 --
> Problem using OM
The bug fix is attached to the bug:
https://bugs.open64.net/show_bug.cgi?id=686
Could someone review this patch when they have the chance?
Thanks,
Doug
--
Beautiful is writing same markup. Internet Explorer 9 support
The patch for the bug is attached to the bug report:
https://bugs.open64.net/show_bug.cgi?id=685
Could someone review this patch when they have the chance?
Thanks,
Doug
--
Beautiful is writing same markup. Internet
ed example, and I don't think we
have actually seen this problem exposed in practice.
> -Original Message-----
> From: Gilmore, Doug
> Sent: Monday, October 25, 2010 2:31 PM
> To: 'Tianwei'; Pengqi Cheng
> Cc: open64-devel@lists.sourceforge.net
> Subject: RE: [Open6
> Hi,
> which opencc version do you use? I have the following case:
> tian...@tianwei:~/test$ cat test.c
> int main() {
> foo();
> printf("hello world\n");
> }
>
> tian...@tianwei:~/test$ cat foo.c
> #include
> void foo(){
> printf("we are in foo!\n");
> }
>
> first I build the .a file
Sorry, I should have provided a link to the bug report:
http://bugs.open64.net/show_bug.cgi?id=677
Doug
> -Original Message-
> From: Gilmore, Doug [mailto:doug.gilm...@amd.com]
> Sent: Thursday, October 21, 2010 4:41 PM
> To: Open64-devel
> Subject: [Open64-devel] review
1 - 100 of 123 matches
Mail list logo