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: open64-devel@l
Author: zhuqing
Date: 2011-03-10 23:05:43 -0500 (Thu, 10 Mar 2011)
New Revision: 3513
Modified:
trunk/osprey/be/cg/cgemit.cxx
trunk/osprey/be/cg/hb.cxx
trunk/osprey/be/cg/hb.h
Log:
The fix solve two problems:
1. It is not appropriate to use a char* to record a string recorded in STR
tabl
Could a gatekeeper please review the attached patch to fix bug 735:
C++ exception handling introduces false catch-all ranges.
This is a long-standing bug in C++ exception handling that leads to
incorrect runtime behavior -- when there is a catch-all range and a
cleanup range in the same region, th
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
Thanks for the numerous defect fixes that have come in.
I think we are ready to move to the phase of validating the
quality of the trunk with lots of test suites.
Prasad from AMD sent email on Feb 25 listing a number of test
suites he is planning to validate with. I think now is a good time
to do
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,
