The instructions are just for optimization. To clarity the intention,
this change adds the prefix "opt_", like "opt_case_dispatch".
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65600 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
r65577 seems to have made MJIT_CC (MJIT_CC_COMMONA) become an absolute
path. So start_process doesn't need to find that from PATH by dln_find_exe_r.
This commit is motivated by the msys2 AppVeyor CI failure:
https://ci.appveyor.com/project/ruby/ruby/builds/20084104/job/1pg15os4dtttyl0q
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65599 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
In these expressions `1` is of type `signed int` (cf: ISO/IEC
9899:1990 section 6.1.3.2). The variable (e.g. `num`) is of type
`rb_num_t`, which is in fact `unsigned long`. These two expressions
then exercises the "usual arithmetic conversions" (cf: ISO/IEC
9899:1990 section 6.2.1.5) and both eventually become `unsigned long`.
The two unsigned expressions are then subtracted to generate another
unsigned integer expression (cf: ISO/IEC 9899:1990 section 6.3.6).
This is where integer overflows can occur. OTOH the left hand side of
the assignments are `rb_snum_t` which is `signed long`. The
assignments exercise the "implicit conversion" of "an unsigned integer
is converted to its corresponding signed integer" case (cf: ISO/IEC
9899:1990 section 6.2.1.2), which is "implementation-defined" (read:
not portable).
Casts are the proper way to avoid this problem. Because all
expressions are converted to some integer types before any binary
operations are performed, the assignments now have fully defined
behaviour. These values can never exceed LONG_MAX so the casts must
not lose any information.
See also: https://travis-ci.org/ruby/ruby/jobs/451726874#L4357
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65595 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Unaligned word access warnings generated by UBSAN are often
treated well already, depending on this macro.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65593 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Looking at the lines right above, it is clear than a blue sky
that we cannot assume `p` to be aligned at all when
UNALIGNED_WORD_ACCESS is true. It is a wrong idea to use
__builtin_assume_aligned for that situation.
See also: https://travis-ci.org/ruby/ruby/jobs/451710732#L2007
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65592 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Integer overflow for unsigned types are fully defined in C. They
are not always problematic (but not always OK). These functions
in this changeset intentionally utilizes that behaviour.
Blacklist from UBSAN checks for better output.
See also: https://travis-ci.org/ruby/ruby/jobs/451624829
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65589 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* Makefile.in (mjit_build_dir.so): separate MJIT_BUILD_DIR to
eliminate the feature for test-all after installation.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65587 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It may cause an access to uninitialized variables.
The call to ppoll will set the `revents` field, but ppoll is not always
called because it is in the guard `!RUBY_VM_INTERRUPTED(th->ec)`.
This issue was found by Coverity Scan.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65584 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The only usage of rb_fiber_reset_root_local_storage() is from
ruby_vm_destruct(), where the object space is already terminated.
This `th->self` is not alive. Why not just use `th` itself.
See also: https://travis-ci.org/ruby/ruby/jobs/451294954
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65574 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
These APIs are much like <valgrind/memcheck.h>. Use them to
fine-grain annotate the usage of our memory.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65573 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I'm planning to use _one later, but it may be doubly registered by
switching `stop_worker_p` now and so we should not use _one for now.
Otherwise stale job may reject new job registration and
copy_cache_from_main_thread may wait forever.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65571 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* Makefile.in (mjit_config.h): expand MJIT_CC only if native
build, the path on cross compiling host is useless.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65570 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
-available region. reducing risk of SEGV in mjit_copy_job_handler() like
http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1446117
I'm not sure which exact part is causing "[BUG] Segmentation fault at 0x0000000000000008"
on `(mjit_copy_job_handler+0x12) [0x564a6c4ce632] /home/ko1/ruby/src/trunk-mjit/mjit.c:26`...
mjit.c: ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65569 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* Makefile.in (mjit_config.h): convert MJIT_CC to Windows path on
mingw.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65568 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
When loading iseq from binary while a TracePoint is on, we need to
recompile instructions to their "trace_" variant. Before this commit
we only recompiled instructions in the top level iseq, which meant
that TracePoint was malfunctioning for code inside module/class/method
definitions.
* compile.c: Move rb_iseq_init_trace to rb_ibf_load_iseq_complete.
It is called on all iseqs during loading.
* test_iseq.rb: Test that tracepoints fire within children iseq when
using load_from_binary.
This patch is from: Alan Wu <XrXr@users.noreply.github.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65567 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
In these functions we are intentionally reading memory address
not owned by us. These reads should not be diagnosed.
See also [Bug #8680]
See also https://travis-ci.org/ruby/ruby/jobs/451202718
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65564 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* Makefile.in (mjit_build_dir.so): separate MJIT_BUILD_DIR to
eliminate the feature for test-all after installation.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65563 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* configure.ac (DLDSHARED): `.dylib` (created by `-dynamiclib`)
and `.bundle` (created by `-dynamic -bundle`) on macOS are
different. `LIBRUBY_LDSHARED` should be the former always.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65561 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* internal.h (ATTRIBUTE_NO_ADDRESS_SAFETY_ANALYSIS): of course, parens around
function signature in its definition is syntax error.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65560 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I remember this configuration unveiled several bugs before.
Better check it occasionally.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65559 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Inspired by [GH-1984], let us add some tests that run only
once a day. These configurations are either slow to compile
or slow to run. But I think they are worth done occasionally.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65556 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
poll(2) and ppoll(2) implementations need to check and write to
.revents on the initial scan, anyways. So any poll/ppoll call
which returns a positive result can be expected to have an
initialized .revents value.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65553 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
