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
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
.
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 issues when building
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; open64-devel
Subject: RE: [Open64-devel
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
-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?
Sun
This was exposed
-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't that be inside
x8664? Or at least
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
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's go with the simpler one. If other arch
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
Author:
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
-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
writing your own?
I am using
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
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
, 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
doug.gilm...@amd.commailto:doug.gilm...@amd.com wrote:
Sorry for the delay in getting back, Jianxin
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 got
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
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@lists.sourceforge.net
Subject
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
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 u=1 cr10 flags:0x0 b=-1
LDRC F10 0x0x80b68d8 u=1 cr20 flags:0x0 b=-1
F10DIV
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
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
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
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
-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 comment at
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
this 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 ppc32 x8664
With this change my
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@lists.sourceforge.net
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
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]
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.
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 T4,.predef_I4,4 # i
//U4INTCONST 8 (0x8)
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
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 OpenMP bug 743
I
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 fix to bug 688
Sorry
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
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: open64-devel
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
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
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
Subject: [Open64-devel
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 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
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
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
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
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
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
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
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
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
Subject
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
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
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
Cc: open64-devel
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
, 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: [Open64-devel] Can ipa_link link static libraries
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 request for fix
The patch is attached to the bug report:
https://bugs.open64.net/show_bug.cgi?id=667
Mei has already reviewed it, so it probably just needs
an approval from a gate keeper.
Doug
--
Beautiful is writing same markup.
-Original Message-
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Tuesday, October 12, 2010 3:29 PM
To: Gilmore, Doug
Cc: Open64-devel
Subject: Re: [Open64-devel] review/approval request for libhugetlbfs
bug fix.
i don't know, the original code has close(fd) at the end, your
-Original Message-
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Tuesday, October 12, 2010 3:45 PM
To: Gilmore, Doug
Cc: Open64-devel
Subject: Re: [Open64-devel] review/approval request for libhugetlbfs
bug fix.
ok, I trust you are right. pls go ahead.
Thanks.
(btw
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?id=674
Could someone review the patch when they have a chance?
Thanks,
Doug
Those options were added recently by AMD and only recently merged with the
trunk.
You will need to use the AMD Open64 compiler:
http://developer.amd.com/cpu/open64/pages/default.aspx
or build a compiler from the trunk.
Doug
From: Eunjung Park [mailto:bol...@gmail.com]
Sent: Wednesday,
I have some changes the fix some problems related to the handling of
Character variables reported in bug 668:
https://bugs.open64.net/show_bug.cgi?id=668
The patch is attached to the bug, could someone review the patch when
they have a chance?
Thanks,
Doug
I suspect that the translation is done in a way that that ensures correctness.
The temp is not needed in your example, but it is needed for:
j = i-- + i--
Doug
-Original Message-
From: C. Bergström [mailto:cbergst...@pathscale.com]
Sent: Wednesday, September 29, 2010 7:15 AM
To:
Could someone review my fix to bug 628? See:
https://bugs.open64.net/show_bug.cgi?id=628
The patch is attached to the bug, which involves changes to:
osprey/be/com/emulate.cxx
osprey/common/com/intrn_entry.def
osprey/wgen/wgen_expr.cxx
osprey/kg++fe/wfe_expr.cxx
Also I added a comment that
, Doug
Cc: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] review request : fix for bug 628
Gilmore, Doug wrote:
Minus the AMD copyright additions, the copyright notices match those
in the
PSC 3.3 beta that we have.
What do you think that they should be?
I'm not a lawyer
Minus the AMD copyright additions, the copyright notices match those in the
PSC 3.3 beta that we have.
What do you think that they should be?
Doug
-Original Message-
From: C. Bergström [mailto:cbergst...@pathscale.com]
Sent: Monday, September 27, 2010 5:20 PM
To: Gilmore, Doug
Cc
I didn't hear back from Sun about this.
Other gatekeepers: is it OK if I commit configure.patch, it has been reviewed.
Regards,
Doug
From: Gilmore, Doug
Sent: Tuesday, September 21, 2010 12:48 PM
To: 'sun.c...@gmail.com'
Subject: FW: [Open64-devel] error when linking libinstr,a (review
70 matches
Mail list logo
