BASERUBY needs to be at least Ruby 2.2 since
46acd0075d.
I think it's better to explicitly fail early as soon as BASERUBY
is used in this case, versus trying to debug later failures.
This modifies things to check both implicitly use of ruby in the
PATH as BASERUBY, and explicitly specified older versions of ruby
when using --with-baseruby.
Fixes [Bug #16668]
Allow the 'Dir.home' method to reliably locate the user's home directory when
all three of the following are true at the same time:
1. Ruby is running on a Unix-like OS
2. The $HOME environment variable is not set
3. The process is not a descendant of login(1) (or a work-alike)
The prior behavior was that the lookup could only work for login-descended
processes.
This is accomplished by looking up the user's record in the password database
by uid (getpwuid_r(3)) as a fallback to the lookup by name (getpwname_r(3))
which is still attempted first (based on the name, if any, returned by
getlogin_r(3)).
If getlogin_r(3), getpwnam_r(3), and/or getpwuid_r(3) is not available at
compile time, will fallback on using their respective non-*_r() variants:
getlogin(3), getpwnam(3), and/or getpwuid(3).
The rationale for attempting to do the lookup by name prior to doing it by uid
is to accommodate the possibility of multiple login names (each with its own
record in the password database, so each with a potentially different home
directory) being mapped to the same uid (as is explicitly allowed for by
POSIX; see getlogin(3posix)).
Preserves the existing behavior for login-descended processes, and adds the
new capability of having Dir.home being able to find the user's home directory
for non-login-descended processes.
Fixes [Bug #16787]
Related discussion:
https://bugs.ruby-lang.org/issues/16787https://github.com/ruby/ruby/pull/3034
GCC/Clang can optimize to calculate `sin(x)` and `cos(x)` at once,
when the both are closely called on the same argument.
Similar optimization is possible for `__sinpi(x)` and `__cospi(x)`
if available, which calculate arguments in radian, i.e.
`sin(x*M_PI)` and `cos(x*M_PI)` respectively.
On some architectures (like RISC-V) sub-word atomics are only available
when linking against -latomic, but the configure script doesn't do that,
causing the atomic checks to fail and the resulting ruby binary is
non-functional. Ruby does not use sub-word atomic operations, rb_atomic_t
is defined to unsigned int, so use unsigned int when checking for atomic
operations.
To this date there is no way for Oracle developer Studio to suppress
warnings about unreachable codes (12.6 manual says it implemented
__builtin_unreachable "as a no-op to C++. It might be added to C.")
There is no way but globally kill the warning.
Every time a pointer to/from VALUE conversion happens, these two
warnings are issued:
- warning #1684: conversion from pointer to same-sized integral type (potential portability problem)
- warning #2312: pointer cast involving 64-bit pointed-to type
Thank you, but we are well aware of the "potential portability problem".
Let us ignore them all.
C++ keyword `nullptr` represents a null pointer (note also that NULL is
an integer in C++ due to its design flaw). Its type is `std::nullptr_t`,
defined in <cstddef> standard header. Why not support it when the
backend implementation can take a null pointer as an argument.
ISO/IEC 9899:1999 section 6.5.7 states that "If the value of the right
operand is negative or is greater than or equal to the width of the
promoted left operand, the behavior is undefined". So we have to take
care of such situations.
This has not been a problem because contemporary C compilers are
extraordinary smart to compile the series of shifts into a single
ROTLQ/ROTRQ machine instruction. In contrast to what C says those
instructions have fully defined behaviour for all possible inputs.
Hence it has been quite difficult to observe the undefined-ness of such
situations. But undefined is undefined. We should not rely on such
target-specific assumptions.
We are fixing the situation by carefully avoiding shifts with out-of-
range values. At least GCC since 4.6.3 and Clang since 8.0 can issue
the exact same instructions like before the changeset.
Also in case of Intel processors, there supposedly be intrinsics named
_rotr/_rotl that do exactly what we need. They, in practice, are absent
on Clang before 9.x so we cannot blindly use. But we can at least save
MSVC.
See also:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157https://bugs.llvm.org/show_bug.cgi?id=17332
MJIT with ccache has a problem on docker environment, so
we need to use original CC (/usr/bin/gcc, for example).
Ubuntu system provides /usr/lib/ccache/gcc and so on to use
gcc with ccache. It is easy to setup ccache by adding
/usr/lib/ccache to $PATH. However we need to use /usr/bin/gcc
(and so on) for MJIT_CC. We can specify MJIT_CC option at
configure, but specifying them is troublesome.
This patch choose original $CC (/usr/bin/gcc, for example)
if $CC is /usr/lib/ccache/$CC.
The use of RUBY_WERROR_FLAG causes this test to fail on OpenBSD
platforms that use the binutils linker (ld.bfd) instead of the
llvm linker (ld.lld), due to warnings added to the binutils linker
in OpenBSD.
Removing the RUBY_WERROR_FLAG would probably also fix it, but that
would affect other platforms.
This should also be backported to Ruby 2.7.
Analysis and similar fix recommended by George Koehler.
With these macros implemented we can write codes just like we can assume
the compiler being clang. MSC_VERSION_SINCE is defined to implement
those macros, but turned out to be handy for other places. The -fdeclspec
compiler flag is necessary for clang to properly handle __has_declspec().
On cross-compilation, compiled binary can no be created because
compiled binary should be created by same interpreter (on cross-
compilation, host ruby is used to build ruby (BASERUBY)).
So that cross-compilation system loads required scripts in text.
It is same as miniruby.
Downstream C++ projects that compile with C++11 or newer and include
the generated config.h file issue compiler warnings. Both C and C++
compilers do string-literal token pasting regardless of whitespace
between the tokens to paste. C++ compilers since C++11 require such
spaces, to avoid ambiguity with the new style of string literals
introduced then. This change fixes such projects without affecting
core Ruby.
icc_version was wrongly defined as "__ICC" on non-icc C compiler, which
caused a warning:
```
./configure: line 8211: test: __ICC: integer expression expected
```
This change adds a sed commend to delete "__ICC".
The icc_version guessing was accidentally disabled because of
61885c9b7ca8ccdaf53d7c365fbb86bad3294d88; `AC_PROG_CC_C99` changes
CC like "icc -std=c99", and `AS_CASE(["x$CC"], [xicc],` does not match.
The variable `icc_version` is eventually defined, so the `AS_CASE` is
not needed. This change removes the `AS_CASE`.
Nobuyoshi Nakada
Watson
Jeremy Evans
Alan D. Salewski
Yusuke Endoh
Andreas Schwab
卜部昌平
Paul Jordan
Takashi Kokubun
Koichi Sasada
Matt Valentine-House
Mark Abraham
Kazuhiro NISHIYAMA