The current gyp config tries to test whether the compiler is an arm / mips
compiler and whether it supports -m32 / -m64 based on a test within gyp.
Unfortunately CXX / CXX_target / CXX_host are no no longer set early enough
in gyp for this to work, and so all of these tests were actually being done
using "$(which g++)" rather than the appropriate CXX_target / CXX_host compiler.
This change removes these dynamic tests and instead bases the decisions on
knowledge of the host / target / v8_target architecture combination. The
the -m32/-m64 flags are set based on host_cxx_is_biarch / target_cxx_is_biarch,
which are set to reasonable defaults of only ia32/x64 or clang compilers
being build for biarch support. The host_cxx_is_biarch / target_cxx_is_biarch
variables can be overriden if required.
Original Review URL: https://codereview.chromium.org/382343003TBR=jkummerow@chromium.org
BUG=384474
LOG=NO
Review URL: https://codereview.chromium.org/400573002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current gyp config tries to test whether the compiler is an arm / mips
compiler and whether it supports -m32 / -m64 based on a test within gyp.
Unfortunately CXX / CXX_target / CXX_host are no no longer set early enough
in gyp for this to work, and so all of these tests were actually being done
using "$(which g++)" rather than the appropriate CXX_target / CXX_host compiler.
This change removes these dynamic tests and instead bases the decisions on
knowledge of the host / target / v8_target architecture combination. The
the -m32/-m64 flags are set based on host_cxx_is_biarch / target_cxx_is_biarch,
which are set to reasonable defaults of only ia32/x64 or clang compilers
being build for biarch support. The host_cxx_is_biarch / target_cxx_is_biarch
variables can be overriden if required.
BUG=384474
LOG=NO
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/382343003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22425 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Simplify the compile time feature detection on Arm:
- Define CAN_USE_XXX definitions unconditionally for all target/host
toolchain combinations
- Rename arm_test / ARM_TEST to arm_test_noprob / ARM_TEST_NO_FEATURE_PROBE
- Don't set ARM_TEST_NO_FEATURE_PROBE implicitly on the simulator to make
make simulator / native more consistent
- Unify CpuFeatures::PrintTarget for simulator and native builds
- Remove unecessary CAN_USE_VFP_INSTRUCTIONS definition for android (this is
the default for arm_fpu=default)
- Add a CpuFeatures::Probe() before calling CpuFeatures::PrintFeatures() in PrintHelp
to ensure we have probed features before printing them.
BUG=384474
LOG=N
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/340373002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21935 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Important notices:
- The snapshot cannot be created for big-endian target in cross-compilation
environment on little-endian host using simulator.
- In order to have i18n support working on big-endian target, the icudt46b.dat and
icudt46b_dat.S files should be generated and upstreamed to ICU repo.
- The mjsunit 'nans' test is endian dependent, it is skipped for mips target.
- The zlib and Mandreel from Octane 2.0 benchmark are endian dependent due to
use of typed arrays.
TEST=
BUG=
R=jkummerow@chromium.org, plind44@gmail.com
Review URL: https://codereview.chromium.org/228943009
Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20778 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem is that conditions are evaluated before configuration inheritance is resolved, so we can't just define a configuration like this:
'Optdebug': {
'inherits_from': ['Debug'],
'variables': {
'v8_optimized_debug': 2,
}
}
Instead, we have to put the different settings depending on the optimization level into separate configurations, and use conditions inside the concrete configurations to inherit from the correct base class.
Common settings go in the base configuration DebugBaseCommon, and v8_optimized_debug dependent settings go into DebugBase{0,1,2}
The new Debug configuration inherits from DebugBaseCommon and DebugBase<(v8_optimized_debug), while the new configuration Optdebug inherits from DebugBaseCommon and DebugBase2.
BUG=v8:3252
R=machenbach@chromium.org, jkummerow@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/224443003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20605 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch contains contributions from the following members of the
BlackBerry Web Technologies team:
Eli Fidler <efidler@blackberry.com>
Konrad Piascik <kpiascik@blackberry.com>
Jeff Rogers <jrogers@blackberry.com>
Cosmin Truta <ctruta@blackberry.com>
Peter Wang <peter.wang@torchmobile.com.cn>
Xiaobo Wang <xiaobwang@blackberry.com>
Ming Xie <mxie@blackberry.com>
Leo Yang <leoyang@blackberry.com>
R=bmeurer@chromium.org, jkummerow@chromium.org
Review URL: https://codereview.chromium.org/61153009
Patch from Cosmin Truta <ctruta@blackberry.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18430 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I sometimes observe broken pipe errors when I run gyp, which causes the gyp
process to fail. This seems to happen if gyp is executed under heavy I/O
pressure.
This change removes the pipes by replacing "echo |" with "< /dev/null".
Technically these are not the same, because "echo |" prints a newline while
"< /dev/null" doesn't, but this difference is not significant in the context of
the commands in toolchain.gypi.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/73623002
Patch from Yuta Kitamura <yutak@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17836 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We recently had some XP issues on chromium.win after https://codereview.chromium.org/19384011/.
This might fix it - quote: "The most likely cause of the problem is a gyp (or similar) change that resulted in v8.dll linking against the release version of the crt (for a debug build). There are two MS VC related files: the crt and the c++ std lib (MSVCR100.DLL and MSVCP100D.DLL). The former is set to release, the latter to debug."
I am not entirely sure if this change fits to the linker options for debug level 2.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/21776002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16026 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch changes the definition of v8_optimized_debug==1 to match the release-mode compiler optimization settings (generally, going from -O1 to -O3 on Linux, similar switches for Mac/Win). This produces a minor speed up on Linux, but significant speedups on Mac and Win. This may make it much harder to debug, though.
It also adds a v8_optimized_debug==2 that, in addition to the compiler optimizations, undef's DEBUG and defines DEBUG. This leaves V8_ENABLE_CHECKS alone (so that the assertions are still enabled), but otherwise basically matches a release mode build.
Builds with v8_optimized_debug==2 roughly match a Release mode build for speed; the V8_ENABLE_CHECKS checks appear to have minimal performance impact (maybe 5-10%, unlike what was previously thought). In addition, switching from the previous optimization settings makes a significant improvement on Mac and Win (50% or more), and switching from DEBUG to NDEBUG makes a significant improvement (another 50% or more).
Note that using v8_optimized_debug==2 may also cause some v8 tests to fail. This is currently is believed to be acceptable.
R=machenbach@chromium.org
BUG=254188
Review URL: https://codereview.chromium.org/19384011
Patch from Dirk Pranke <dpranke@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15937 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
