Subversion Repositories Open64

[/] [branches/] [open64-booster/] [install_compiler.sh] - Rev 3834

Rev

Go to most recent revision | Details | Compare with Previous | Blame

Filtering Options

Clear current filter

Rev Log message Author Age Path
3468 Merge trunk changes r3461-3467 into open64-booster branch. dcoakley 845d 19h /branches/open64-booster/install_compiler.sh
3461 Merge trunk changes r3439-3460 into open64-booster branch. dcoakley 856d 17h /branches/open64-booster/install_compiler.sh
3355 Merge trunk changes r3344-3354 into open64-booster branch. dcoakley 970d 17h /branches/open64-booster/install_compiler.sh
3344 Merge trunk changes r3228-3343 to open64-booster branch. dcoakley 974d 20h /branches/open64-booster/install_compiler.sh
3228 Merge trunk changes through r3226.

Also fix a build problem where unallocated memory was freed when
LD_LIBRARY_PATH is set (osprey/driver/opt_actions.c).
dcoakley 1068d 17h /branches/open64-booster/install_compiler.sh
3220 Update copyright notices. dcoakley 1075d 17h /branches/open64-booster/install_compiler.sh
3204 - Finished 1GB huge page support in libhugetlbfs. Note that
the driver option -HP:bdt=1g only maps data and BSS (but not
text) using 1G pages.
- Added compiler driver option -HP=bd=[1g|2m] which supports mapping
data and BSS using huge pages. When using 2M pages, mapping of text
using huge pages can be enabled by setting the environment variable
HUGETLB_ENABLE_MAPPING_TEXT.
- Note that when -HP:bdt=1g or -HP:bd=1g is specified, the rest of
the 1GB page used to map data and BSS is used heap allocations, thus
when -HP:bdt=1g by specified by itself implies
-HP:bdt=1g:heap=1g,limit=1. Setting -HP:bdt=1g:heap=1g,limit=2
implies that an another page can be allocated for heap (along with
the rest of the 1GB page used to map BD).
- Fixed bug 15564, BDT mappings can fail on SLES11 (and also on
SLES10). We now properly account for the number of extra pages for
copy-on-write faults that can occur when program segments are mapped
private (beforehand we over calculated the number of pages needed
for BDT mappings, so in most cases this constraint was fortuitously
satisfied). Note that currently private mappings are still being
used for program segments mapped with 2M pages, while program segment
mappings that use 1G pages use shared mappings since private mappings
with 1G pages wastes too much memory. In the rare situation where
too much memory is being reserved for copy-on-write faults for
program segments when 2M pages are being used, the environment
variable HUGETLB_ELF_MAP_SHARED can set to force shared mapping
of program segments.
dcoakley 1075d 17h /branches/open64-booster/install_compiler.sh
3201 Ported F03 iso_c_binding module supported from PSC 3.3 beta. dcoakley 1075d 17h /branches/open64-booster/install_compiler.sh
3199 Add libacml_mv.so to the build.

This change enables building shared objects that reference the fastmath
functions and allows more applications to be compiled with -Ofast (bug 15531).
dcoakley 1075d 17h /branches/open64-booster/install_compiler.sh
3192 dcoakley 1075d 17h /branches/open64-booster/install_compiler.sh
3127 Compile omp_lib.f Fortran interface to corresponding module
files so that "use omp_lib" works out of the box (bug 15522).
dcoakley 1075d 19h /branches/open64-booster/install_compiler.sh
3107 dcoakley 1075d 19h /branches/open64-booster/install_compiler.sh
3081 Merge changes through 3067 from trunk. dcoakley 1104d 22h /branches/open64-booster/install_compiler.sh
2811 Merge changes through r2788 from trunk. dcoakley 1200d 19h /branches/open64-booster/install_compiler.sh
2766 Merge change r2752 from trunk. dcoakley 1222d 17h /branches/open64-booster/install_compiler.sh
2683 Fix typo that prevented install of the 32-bit libacml_mv.a.

Also, since some system tools complain about empty archives
add a dummy function to the library.
dcoakley 1278d 17h /branches/open64-booster/install_compiler.sh
2660 Add LGPL-licensed source version of the libacml_mv library, and build this
library from source like other libraries included with Open64.

This version of the library depends on the system libm, so the driver adds
'-lacml_mv -lm' to the link line. The library is only used for x86-64; to
simplify the driver code, we build an empty library for other targets.
dcoakley 1284d 18h /branches/open64-booster/install_compiler.sh
2647 Add libfortran.so and libffio.so to the compiler install (bug 15407).

To prevent a warning message about 'feupdateenv' when libfortran.so
is loaded, the routine _Ieee_restore should avoid calling feupdateenv
as described in the comments at the top of ieee_module_support.c.
dcoakley 1284d 18h /branches/open64-booster/install_compiler.sh
2602 Create symbolic links to the internal gcc shared objects in the lib
directory so that all runtime dependencies can be found in a single
directory.
dcoakley 1284d 18h /branches/open64-booster/install_compiler.sh
2551 Build and include internal gcc 4.2.0 distribution. Use of this internal gcc
for preprocessing and linking will be enabled in a future update to the
Open64 driver.

- Add missing 'libstdc++-v3' files from GNU gcc 4.2.0 distribution.
- Add missing x86-specific header file 'ammintrin.h' from SUSE gcc 4.1.2.
- Build all C/C++ components for gcc 4.2.0 except for documentation.
- Remove the '42' suffix from the gcc 4.2.0 components because it interferes
with the complete build.
- Remove the deprecated gcc 4.0.2 front-end from the build and install.
- Install the internal gcc components at the top level of the Open64
installation directory in 'open64-gcc-4.2.0' directory. Make the Open64
C/C++ front-end executables symbolic links into this directory.
dcoakley 1284d 19h /branches/open64-booster/install_compiler.sh

1 2 Next >

Show All