Harald Anlauf [Mon, 23 Jan 2023 20:19:03 +0000 (21:19 +0100)]
Fortran: avoid ICE on invalid array subscript triplets [PR108501]
gcc/fortran/ChangeLog:
PR fortran/108501
* interface.cc (get_expr_storage_size): Check array subscript triplets
that we actually have integer values before trying to extract with
mpz_get_si.
gcc/testsuite/ChangeLog:
PR fortran/108501
* gfortran.dg/pr108501.f90: New test.
This patch surrounds the scalar operand of the MVE vcmp patterns with a
vec_duplicate to ensure both operands of the comparision operator have the same
(vector) mode.
Marek Polacek [Wed, 25 Jan 2023 22:19:54 +0000 (17:19 -0500)]
opts: SANITIZE_ADDRESS wrongly cleared [PR108543]
Here we crash on a null fndecl ultimately because we haven't defined
the built-ins described in sanitizer.def. So
builtin_decl_explicit (BUILT_IN_ASAN_POINTER_SUBTRACT);
returns NULL_TREE, causing an ICE later.
DEF_SANITIZER_BUILTIN only actually defines the built-ins when flag_sanitize
has SANITIZE_ADDRESS, or some of the other SANITIZE_*, but it doesn't check
SANITIZE_KERNEL_ADDRESS or SANITIZE_USER_ADDRESS. Unfortunately, with
-fsanitize=address -fno-sanitize=kernel-address
or
-fsanitize=kernel-address -fno-sanitize=address
SANITIZE_ADDRESS ends up being unset from flag_sanitize even though
_USER/_KERNEL are set. That's because -fsanitize=address means
SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS and -fsanitize=kernel-address
is SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS but parse_sanitizer_options
does
flags &= ~sanitizer_opts[i].flag;
so the subsequent -fno- unsets SANITIZE_ADDRESS. Then no sanitizer
built-ins are actually defined.
I'm not sure why SANITIZE_ADDRESS isn't just SANITIZE_USER_ADDRESS |
SANITIZE_KERNEL_ADDRESS, I don't think we need 3 bits.
PR middle-end/108543
gcc/ChangeLog:
* opts.cc (parse_sanitizer_options): Don't always clear SANITIZE_ADDRESS
if it was previously set.
gcc/testsuite/ChangeLog:
* c-c++-common/asan/pointer-subtract-5.c: New test.
* c-c++-common/asan/pointer-subtract-6.c: New test.
* c-c++-common/asan/pointer-subtract-7.c: New test.
* c-c++-common/asan/pointer-subtract-8.c: New test.
Dimitar Dimitrov [Sat, 21 Jan 2023 16:10:59 +0000 (18:10 +0200)]
pru: Fix CLZ expansion for QI and HI modes
The recent gcc.dg/tree-ssa/clz-char.c test case failed for PRU target,
exposing a wrong code generation bug in the PRU backend. The "clz"
pattern did not produce correct output for QI and HI input operand
modes. SI mode is ok.
The "clz" pattern is expanded to an LMBD instruction to get the
left-most bit position having value "1". In turn, to get the correct
"clz" value, that bit position must be subtracted from the MSB bit
position of the input operand. The old behaviour of hard-coding 31
for MSB bit position is wrong.
The LMBD instruction returns 32 if input operand is zero, irrespective
of its register mode. This maps nicely for SI mode, where the "clz"
pattern outputs -1. It also leads to peculiar (but valid!) output
values from the "clz" pattern for QI and HI zero-valued inputs.
The corresponding commit in trunk contains two new test cases, which
have been removed here because they depend on r13-5195-g4798080d4a3530.
Regtested for pru-unknown-elf.
gcc/ChangeLog:
* config/pru/pru.h (CLZ_DEFINED_VALUE_AT_ZERO): Fix value for QI
and HI input modes.
* config/pru/pru.md (clz): Fix generated code for QI and HI
input modes.
Christophe Lyon [Tue, 14 Jun 2022 21:08:33 +0000 (21:08 +0000)]
aarch64: fix warning emission for ABI break since GCC 9.1
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be. This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.
We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1. This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.
The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers. This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information). However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.
The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.
We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.
2022-11-28 Christophe Lyon <christophe.lyon@arm.com>
Richard Sandiford <richard.sandiford@arm.com>
* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.
Richard Biener [Mon, 19 Dec 2022 13:55:45 +0000 (14:55 +0100)]
tree-optimization/108164 - undefined overflow with IV vectorization
vect_update_ivs_after_vectorizer can end up emitting a signed
IV update when the loop body performed an unsigned computation.
The following makes sure to perform that update in the type
of the loop update type to avoid undefined behavior on overflow.
PR tree-optimization/108164
* tree-vect-loop-manip.cc (vect_update_ivs_after_vectorizer):
Perform vect_step_op_add update in the appropriate type.
Richard Biener [Mon, 12 Dec 2022 16:52:46 +0000 (17:52 +0100)]
tree-optimization/108076 - if-conversion and forced labels
When doing if-conversion we simply throw away labels without checking
whether they are possibly targets of non-local gotos or have their
address taken. The following rectifies this and refuses to if-convert
such loops.
PR tree-optimization/108076
* tree-if-conv.cc (if_convertible_loop_p_1): Reject blocks
with non-local or forced labels that we later remove
labels from.
`xputenv()` (and `putenv()`) don't copy strings and only store the
pointer in the `environ` global table. As a result `environ` got
corrupted as soon as `jinfo.skipped_makeflags` store got deallocated.
This started causing bootstrap crashes in `execv()` calls:
xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
The change restores memory allocation for `xputenv()` argument.
Andreas Krebbel [Mon, 23 Jan 2023 07:56:05 +0000 (08:56 +0100)]
PR 106101: IBM zSystems: Fix strict_low_part problem
This avoids generating illegal (strict_low_part (reg ...)) RTXs. This
required two changes:
1. Do not use gen_lowpart to generate the inner expression of a
STRICT_LOW_PART. gen_lowpart might fold the SUBREG either because
there is already a paradoxical subreg or because it can directly be
applied to the register. A new wrapper function makes sure that we
always end up having an actual SUBREG.
2. Change the movstrict patterns to enforce a SUBREG as inner operand
of the STRICT_LOW_PARTs. The new predicate introduced for the
destination operand requires a SUBREG expression with a
register_operand as inner operand. However, since reload strips away
the majority of the SUBREGs we have to accept single registers as well
once we reach reload.
Bootstrapped and regression tested on IBM zSystems 64 bit.
gcc/ChangeLog:
PR target/106101
* config/s390/predicates.md (subreg_register_operand): New
predicate.
* config/s390/s390-protos.h (s390_gen_lowpart_subreg): New
function prototype.
* config/s390/s390.cc (s390_gen_lowpart_subreg): New function.
(s390_expand_insv): Use s390_gen_lowpart_subreg instead of
gen_lowpart.
* config/s390/s390.md ("*get_tp_64", "*zero_extendhisi2_31")
("*zero_extendqisi2_31", "*zero_extendqihi2_31"): Likewise.
("movstrictqi", "movstricthi", "movstrictsi"): Use the
subreg_register_operand predicate instead of register_operand.
gcc/testsuite/ChangeLog:
PR target/106101
* gcc.c-torture/compile/pr106101.c: New test.
Jonathan Wakely [Thu, 22 Dec 2022 09:56:47 +0000 (09:56 +0000)]
libstdc++: Avoid recursion in __nothrow_wait_cv::wait [PR105730]
The commit r12-5877-g9e18a25331fa25 removed the incorrect
noexcept-specifier from std::condition_variable::wait and gave the new
symbol version @@GLIBCXX_3.4.30. It also redefined the original symbol
std::condition_variable::wait(unique_lock<mutex>&)@GLIBCXX_3.4.11 as an
alias for a new symbol, __gnu_cxx::__nothrow_wait_cv::wait, which still
has the incorrect noexcept guarantee. That __nothrow_wait_cv::wait is
just a wrapper around the real condition_variable::wait which adds
noexcept and so terminates on a __forced_unwind exception.
This doesn't work on uclibc, possibly due to a dynamic linker bug. When
__nothrow_wait_cv::wait calls the condition_variable::wait function it
binds to the alias symbol, which means it just calls itself recursively
until the stack overflows.
This change avoids the possibility of a recursive call by changing the
__nothrow_wait_cv::wait function so that instead of calling
condition_variable::wait it re-implements it. This requires accessing
the private _M_cond member of condition_variable, so we need to use the
trick of instantiating a template with the member-pointer of the private
member.
libstdc++-v3/ChangeLog:
PR libstdc++/105730
* src/c++11/compatibility-condvar.cc (__nothrow_wait_cv::wait):
Access private data member of base class and call its wait
member.
Jonathan Wakely [Thu, 28 Jul 2022 15:15:58 +0000 (16:15 +0100)]
libstdc++: Unblock atomic wait on non-futex platforms [PR106183]
When using a mutex and condition variable, the notifying thread needs to
increment _M_ver while holding the mutex lock, and the waiting thread
needs to re-check after locking the mutex. This avoids a missed
notification as described in the PR.
By moving the increment of _M_ver to the base _M_notify we can make the
use of the mutex local to the use of the condition variable, and
simplify the code a little. We can use a relaxed store because the mutex
already provides sequential consistency. Also we don't need to check
whether __addr == &_M_ver because we know that's always true for
platforms that use a condition variable, and so we also know that we
always need to use notify_all() not notify_one().
Reviewed-by: Thomas Rodgers <trodgers@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/106183
* include/bits/atomic_wait.h (__waiter_pool_base::_M_notify):
Move increment of _M_ver here.
[!_GLIBCXX_HAVE_PLATFORM_WAIT]: Lock mutex around increment.
Use relaxed memory order and always notify all waiters.
(__waiter_base::_M_do_wait) [!_GLIBCXX_HAVE_PLATFORM_WAIT]:
Check value again after locking mutex.
(__waiter_base::_M_notify): Remove increment of _M_ver.
we found that the Um constraint would also allow through a
register offset writeback, resulting in an assembler error.
Here I have added a new constraint and predicate for these
instructions, which (uniquely, AFAICT), only support a `!` writeback
increment by the data size (inside the compiler this is a POST_INC).
No regressions in arm-none-eabi with MVE and MVE.FP.
gcc/ChangeLog:
PR target/107714
* config/arm/arm-protos.h (mve_struct_mem_operand): New protoype.
* config/arm/arm.cc (mve_struct_mem_operand): New function.
* config/arm/constraints.md (Ug): New constraint.
* config/arm/mve.md (mve_vst4q<mode>): Change constraint.
(mve_vst2q<mode>): Likewise.
(mve_vld4q<mode>): Likewise.
(mve_vld2q<mode>): Likewise.
* config/arm/predicates.md (mve_struct_operand): New predicate.
gcc/testsuite/ChangeLog:
PR target/107714
* gcc.target/arm/mve/intrinsics/vldst24q_reg_offset.c: New test.
Kyrylo Tkachov [Mon, 19 Dec 2022 11:16:47 +0000 (11:16 +0000)]
aarch64: PR target/108140 Handle NULL target in data intrinsic expansion
In this PR we ICE when expanding the __rbit builtin with a NULL target rtx.
I *think* that only happens when the result is unused and hence maybe we shouldn't be expanding
any RTL at all, but the ICE here is easily fixed by deriving the mode from the type of the expression
rather than the target.
This patch does that.
Bootstrapped and tested on aarch64-none-linux-gnu.
Kewen Lin [Wed, 21 Dec 2022 03:02:08 +0000 (21:02 -0600)]
rs6000: Raise error for __vector_{quad,pair} uses without MMA enabled [PR106736]
As PR106736 shows, it's unexpected to use __vector_quad and
__vector_pair types without MMA support, it would cause ICE
when expanding the corresponding assignment. We can't guard
these built-in types registering under MMA support as Peter
pointed out in that PR, because the registering is global,
it doesn't work for target pragma/attribute support with MMA
enabled. The existing verify_type_context mentioned in [2]
can help to make the diagnostics invalid built-in type uses
better, but as Richard pointed out in [4], it can't deal with
all cases. As the discussions in [1][3], this patch is to
check the invalid use of built-in types __vector_quad and
__vector_pair in mov pattern of OOmode and XOmode, on the
currently being expanded gimple assignment statement. It
still puts an assertion in else arm rather than just makes
it go through, it's to ensure we can catch any other possible
unexpected cases in time if there are.
* config/rs6000/mma.md (define_expand movoo): Call function
rs6000_opaque_type_invalid_use_p to check and emit error message for
the invalid use of opaque type.
(define_expand movxo): Likewise.
* config/rs6000/rs6000-protos.h
(rs6000_opaque_type_invalid_use_p): New function declaration.
(currently_expanding_gimple_stmt): New extern declaration.
* config/rs6000/rs6000.cc (rs6000_opaque_type_invalid_use_p): New
function.
Patrick Palka [Wed, 4 Jan 2023 19:12:25 +0000 (14:12 -0500)]
c++: mark_single_function and SFINAE [PR108282]
We typically ignore mark_used failure when in a non-SFINAE context for
sake of better error recovery. But in mark_single_function we're
instead ignoring mark_used failure in a SFINAE context, which ends up
causing the second static_assert here to incorrectly fail.
PR c++/108282
gcc/cp/ChangeLog:
* decl2.cc (mark_single_function): Ignore mark_used failure
only in a non-SFINAE context rather than in a SFINAE one.
Florian Weimer [Tue, 18 Oct 2022 14:58:48 +0000 (16:58 +0200)]
libiberty: Fix C89-isms in configure tests
libiberty/
* acinclude.m4 (ac_cv_func_strncmp_works): Add missing
int return type and parameter list to the definition of main.
Include <stdlib.h> and <string.h> for prototypes.
(ac_cv_c_stack_direction): Add missing
int return type and parameter list to the definitions of
main, find_stack_direction. Include <stdlib.h> for exit
prototype.
* configure: Regenerate.
Harald Anlauf [Sat, 17 Dec 2022 21:04:32 +0000 (22:04 +0100)]
Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]
gcc/fortran/ChangeLog:
PR fortran/108131
* array.cc (match_array_element_spec): Avoid too early simplification
of matched array element specs that can lead to a misinterpretation
when used as array bounds in array declarations.
Richard Biener [Thu, 22 Dec 2022 14:51:46 +0000 (15:51 +0100)]
bootstrap/106482 - document minimal GCC version
There's no explicit mention of what GCC compiler supports C++11
and the cross compiler build requirement mentions GCC 4.8 but not
GCC 4.8.3 which is the earliest known version to not run into
C++11 implementation bugs. The following adds explicit wording.
PR bootstrap/106482
* doc/install.texi (ISO C++11 Compiler): Document GCC version
known to work.
Jonathan Wakely [Fri, 16 Dec 2022 16:07:29 +0000 (16:07 +0000)]
libstdc++: Fixes for std::expected
This fixes some bugs in the swap functions for std::expected.
It also disables the noexcept-specifiers for equality operators, because
those are problematic when querying whether a std::expected is equality
comparable. The operator==(const expected<T,E>&, const U&) function is
not constrained, so is viable for comparing expected<T,E> with
expected<void,G>, but then we get an error from the noexcept-specifier.
libstdc++-v3/ChangeLog:
* include/std/expected (expected::_M_swap_val_unex): Guard the
correct object.
(expected::swap): Move is_swappable
requirement from static_assert to constraint.
(swap): Likewise.
(operator==): Remove noexcept-specifier.
* testsuite/20_util/expected/swap.cc: Check swapping of
types without non-throwing move constructor. Check constraints
on swap.
* testsuite/20_util/expected/unexpected.cc: Check constraints on
swap.
* testsuite/20_util/expected/equality.cc: New test.
Tobias Burnus [Wed, 21 Dec 2022 06:55:22 +0000 (07:55 +0100)]
libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]
Since GCC 12, the conversion between the array descriptors formats - the
internal (GFC) and the C binding one (CFI) - moved to the compiler itself
such that the cfi_desc_to_gfc_desc/gfc_desc_to_cfi_desc functions are only
used with older code (GCC 9 to 11). The newly added checks caused asserts
as older code did not pass the proper values (e.g. real(4) as effective
argument arrived as BT_ASSUME type as the effective type got lost inbetween).
As proposed in the PR, revert to the GCC 11 version - known bugs is better
than some fixes and new issues. Still, GCC 12 is much better in terms of
TS29113 support and should really be used.
This patch uses the current libgomp version of the GCC 11 branch, except
it fixes the GFC version number (which is 0), uses calloc instead of malloc,
and sets the lower bound to 1 instead of keeping it as is for
CFI_attribute_other.
PR libfortran/108056
* runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc,
gfc_desc_to_cfi_desc): Mostly revert to GCC 11 version for
those backward-compatiblity-only functions.
Hongyu Wang [Tue, 6 Dec 2022 01:53:35 +0000 (09:53 +0800)]
i386: Avoid fma_chain for -march=alderlake and sapphirerapids.
For Alderlake there is similar issue like PR81616, enable
avoid_fma256_chain will also benefit on Intel latest platforms
Alderlake and Sapphire Rapids.
Patrick Palka [Thu, 15 Dec 2022 21:02:05 +0000 (16:02 -0500)]
c++: extract_local_specs and unevaluated contexts [PR100295]
Here during partial instantiation of the constexpr if, extra_local_specs
walks the statement looking for local specializations within to capture.
However, we're thwarted by the fact that 'ts' first appears inside an
unevaluated context, and so the calls to process_outer_var_ref for its
local specializations are a no-op. And since we walk each tree exactly
once, we end up not capturing the local specializations despite 'ts'
later occurring in an evaluated context.
This patch fixes this by making extract_local_specs walk evaluated
contexts first before walking unevaluated contexts. We could probably
get away with not walking unevaluated contexts at all, but this approach
seems more clearly safe.
PR c++/100295
PR c++/107579
gcc/cp/ChangeLog:
* pt.cc (el_data::skip_unevaluated_operands): New data member.
(extract_locals_r): If skip_unevaluated_operands is true,
don't walk into unevaluated contexts.
(extract_local_specs): Walk the pattern twice, first with
skip_unevaluated_operands true followed by it set to false.
Patrick Palka [Thu, 15 Dec 2022 20:38:47 +0000 (15:38 -0500)]
c++: partial ordering with memfn ptr cst [PR108104]
Here we're triggering an overzealous assert in unify during partial
ordering since the member function pointer constants are represented as
ordinary CONSTRUCTORs (with TYPE_PTRMEMFUNC_P TREE_TYPE) but the assert
expects COMPOUND_LITERAL_P constructors.
PR c++/108104
gcc/cp/ChangeLog:
* pt.cc (unify) <default>: Relax assert to accept any
CONSTRUCTOR parm, not just COMPOUND_LITERAL_P one.
Patrick Palka [Sun, 4 Dec 2022 15:47:24 +0000 (10:47 -0500)]
c++: pack in requires-expr parm list [PR107417]
Here find_parameter_packs_r isn't detecting the pack T inside the
requires-expr's parameter list ultimately because cp_walk_trees
deliberately avoids walking the list so as to avoid false positives in
the unexpanded pack checker.
But it should still be fine to walk the TREE_TYPE of each parameter,
which we already need to do from for_each_template_parm_r, and is
sufficient to fix the testcase.
PR c++/107417
gcc/cp/ChangeLog:
* pt.cc (for_each_template_parm_r) <case REQUIRES_EXPR>: Move
walking of the TREE_TYPE of each parameter to ...
* tree.cc (cp_walk_subtrees) <case REQUIRES_EXPR>: ... here.
We implement class-scope using enum by injecting clones of the enum's
CONST_DECLs as fields of the class, for which CONST_DECL_USING_P is
true, so that qualified lookup naturally finds the enumerators.
Substitution into such a CONST_DECL currently ICEs however, because we
assume the DECL_CONTEXT is always the ENUMERAL_TYPE (which has
TYPE_VALUES) but in this case it's the RECORD_TYPE for the class scope
(which has TYPE_FIELDS).
Since these CONST_DECLs appear to always be non-dependent, this patch
fixes this by shortcutting substitution for CONST_DECLs that have
non-dependent DECL_CONTEXT. This subsumes the existing (and seemingly
dead) DECL_NAMESPACE_SCOPE_P early exit test and also benefits
substitution into ordinary non-dependent CONST_DECLs.
PR c++/103081
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy) <case CONST_DECL>: Generalize
early exit test for namespace-scope decls to check dependence of
the enclosing scope instead. Remove dead early exit test.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/using-enum-10.C: New test.
* g++.dg/cpp2a/using-enum-10a.C: New test.
Patrick Palka [Wed, 30 Nov 2022 00:25:37 +0000 (19:25 -0500)]
c++: ICE with <=> of incompatible pointers [PR107542]
In a SFINAE context composite_pointer_type returns error_mark_node if
the given pointer types are incompatible. But the SPACESHIP_EXPR case
of cp_build_binary_op wasn't prepared for this error_mark_node result,
which led to an ICE (from spaceship_comp_cat) for the below testcase.
(In a non-SFINAE context composite_pointer_type issues a permerror and
returns cv void* in this case, so this ICE seems specific to SFINAE.)
PR c++/107542
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op): In the SPACESHIP_EXPR case,
handle an error_mark_node result type.
Sebastian Pop [Wed, 30 Nov 2022 19:45:24 +0000 (19:45 +0000)]
AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]
Currently patchable area is at the wrong place on AArch64. It is placed
immediately after function label, before .cfi_startproc. This patch
adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
modifies aarch64_print_patchable_function_entry to avoid placing
patchable area before .cfi_startproc.
Iain Buclaw [Tue, 13 Dec 2022 21:34:57 +0000 (22:34 +0100)]
libphobos: Backport library and bindings fixes from mainline
D Runtime changes:
- Fix MIPS64 bindings for CRuntime_UClibc.
Phobos changes:
- Fix std.path.expandTilde erroneously raising onOutOfMemory
after failed call to getpwnam_r().
- Fix std.random unittest failures on ILP32 targets.
- Use GENERIC_IO on CRuntime_UClibc port of std.stdio.
libphobos/ChangeLog:
* libdruntime/core/stdc/fenv.d: Compile in MIPS uClibc bindings on
MIPS_Any targets.
* libdruntime/core/stdc/math.d: Likewise.
* libdruntime/core/sys/posix/dlfcn.d: Likewise.
* libdruntime/core/sys/posix/setjmp.d: Add MIPS64 definitions for
CRuntime_UClibc.
* libdruntime/core/sys/posix/sys/types.d: Likewise.
* src/std/path.d (expandTilde): Handle more errno codes that could be
left set by getpwnam_r.
* src/std/random.d: Use D_LP64 in unittests.
* src/std/stdio.d: Set CRuntime_UClibc as GENERIC_IO target.
git://gcc.gnu.org / gcc.git / log