This patch fixes an oversight in the handling of debug instructions
in rtl-ssa. At the moment (and whether this is a good idea or not
remains to be seen), we maintain a linear RPO sequence of definitions
and non-debug uses. If a register is defined more than once, we use
a degenerate phi to reestablish a previous definition where necessary.
However, debug instructions shouldn't of course affect codegen,
so we can't create a new definition just for them. In those situations
we instead hang the debug use off the real definition (meaning that
debug uses do not follow a linear order wrt definitions). Again,
it remains to be seen whether that's a good idea.
The problem in the PR was that we weren't taking this into account
when increasing (or potentially increasing) the live range of an
existing definition. We'd create the phi even if it would only
be used by debug instructions.
The patch goes for the simple but inelegant approach of passing
a bool to say whether the use is a debug use or not. I imagine
this area will need some tweaking based on experience in future.
gcc/
PR rtl-optimization/100303
* rtl-ssa/accesses.cc (function_info::make_use_available): Take a
boolean that indicates whether the use will only be used in
debug instructions. Treat it in the same way that existing
cross-EBB debug references would be handled if so.
(function_info::make_uses_available): Likewise.
* rtl-ssa/functions.h (function_info::make_uses_available): Update
prototype accordingly.
(function_info::make_uses_available): Likewise.
* fwprop.c (try_fwprop_subst): Update call accordingly.
rtl-ssa: Extend m_num_defs to a full unsigned int [PR108086]
insn_info tried to save space by storing the number of
definitions in a 16-bit bitfield. The justification was:
// ... FIRST_PSEUDO_REGISTER + 1
// is the maximum number of accesses to hard registers and memory, and
// MAX_RECOG_OPERANDS is the maximum number of pseudos that can be
// defined by an instruction, so the number of definitions should fit
// easily in 16 bits.
But while that reasoning holds (I think) for real instructions,
it doesn't hold for artificial instructions. I don't think there's
any sensible higher limit we can use, so this patch goes for a full
unsigned int.
gcc/
PR rtl-optimization/108086
* rtl-ssa/insns.h (insn_info): Make m_num_defs a full unsigned int.
Adjust size-related commentary accordingly.
This was another PR caused by the way that
vect_determine_precisions_from_range handles shifts. We tried to
narrow 32768 >> x to a 16-bit shift based on range information for
the inputs and outputs, with vect_recog_over_widening_pattern
(after PR110828) adjusting the shift amount. But this doesn't
work for the case where x is in [16, 31], since then 32-bit
32768 >> x is a well-defined zero, whereas no well-defined
16-bit 32768 >> y will produce 0.
We could perhaps generate x < 16 ? 32768 >> x : 0 instead,
but since vect_determine_precisions_from_range was never really
supposed to rely on fix-ups, it seems better to fix that instead.
The patch also makes the code more selective about which codes
can be narrowed based on input and output ranges. This showed
that vect_truncatable_operation_p was missing cases for
BIT_NOT_EXPR (equivalent to BIT_XOR_EXPR of -1) and NEGATE_EXPR
(equivalent to BIT_NOT_EXPR followed by a PLUS_EXPR of 1).
pr113281-1.c is the original testcase. pr113281-[23].c failed
before the patch due to overly optimistic narrowing. pr113281-[45].c
previously passed and are meant to protect against accidental
optimisation regressions.
gcc/
PR target/113281
* tree-vect-patterns.c (vect_recog_over_widening_pattern): Remove
workaround for right shifts.
(vect_truncatable_operation_p): Handle NEGATE_EXPR and BIT_NOT_EXPR.
(vect_determine_precisions_from_range): Be more selective about
which codes can be narrowed based on their input and output ranges.
For shifts, require at least one more bit of precision than the
maximum shift amount.
create_intersect_range_checks checks whether two access ranges
a and b are alias-free using something equivalent to:
end_a <= start_b || end_b <= start_a
It has two ways of doing this: a "vanilla" way that calculates
the exact exclusive end pointers, and another way that uses the
last inclusive aligned pointers (and changes the comparisons
accordingly). The comment for the latter is:
/* Calculate the minimum alignment shared by all four pointers,
then arrange for this alignment to be subtracted from the
exclusive maximum values to get inclusive maximum values.
This "- min_align" is cumulative with a "+ access_size"
in the calculation of the maximum values. In the best
(and common) case, the two cancel each other out, leaving
us with an inclusive bound based only on seg_len. In the
worst case we're simply adding a smaller number than before.
The problem is that the associated code implicitly assumed that the
access size was a multiple of the pointer alignment, and so the
alignment could be carried over to the exclusive end pointer.
The testcase started failing after g:9fa5b473b5b8e289b6542
because that commit improved the alignment information for
the accesses.
gcc/
PR tree-optimization/115192
* tree-data-ref.c (create_intersect_range_checks): Take the
alignment of the access sizes into account.
gcc/testsuite/
PR tree-optimization/115192
* gcc.dg/vect/pr115192.c: New test.
where SImode divmod_operator (div,mod,udiv,umod) has DImode operands.
Wrap input operand with truncate:SI to make machine modes consistent.
PR target/115297
gcc/ChangeLog:
* config/alpha/alpha.md (<any_divmod:code>si3): Wrap DImode
operands 3 and 4 with truncate:SI RTX.
(*divmodsi_internal_er): Ditto for operands 1 and 2.
(*divmodsi_internal_er_1): Ditto.
(*divmodsi_internal): Ditto.
* config/alpha/constraints.md ("b"): Correct register
number in the description.
Jonathan Wakely [Wed, 29 May 2024 09:59:48 +0000 (10:59 +0100)]
libstdc++: Replace link to gcc-4.3.2 docs in manual [PR115269]
Link to the docs for GCC trunk instead. For the release branches, the
link should be to the docs for appropriate release branch.
Also replace the incomplete/outdated list of explicit -std options with
a single entry for the -std option.
libstdc++-v3/ChangeLog:
PR libstdc++/115269
* doc/xml/manual/using.xml: Replace link to gcc-4.3.2 docs.
Replace list of -std=... options with a single entry for -std.
* doc/html/manual/using.html: Regenerate.
YunQiang Su [Tue, 28 May 2024 18:28:25 +0000 (02:28 +0800)]
MIPS16: Mark $2/$3 as clobbered if GP is used
PR Target/84790.
The gp init sequence
li $2,%hi(_gp_disp)
addiu $3,$pc,%lo(_gp_disp)
sll $2,16
addu $2,$3
is generated directly in `mips_output_function_prologue`, and does
not appear in the RTL.
So the IRA/IPA passes are not aware that $2/$3 have been clobbered,
so they may be used for cross (local) function call.
Let's mark $2/$3 clobber both:
- Just after the UNSPEC_GP RTL of a function;
- Just after a function call.
Reported-by: Matthias Schiffer <mschiffer@universe-factory.net> Origin-Patch-by: Felix Fietkau <nbd@nbd.name>.
gcc
* config/mips/mips.c(mips16_gp_pseudo_reg): Mark
MIPS16_PIC_TEMP and MIPS_PROLOGUE_TEMP clobbered.
(mips_emit_call_insn): Mark MIPS16_PIC_TEMP and
MIPS_PROLOGUE_TEMP clobbered if MIPS16 and CALL_CLOBBERED_GP.
Jakub Jelinek [Wed, 22 May 2024 07:12:28 +0000 (09:12 +0200)]
ubsan: Use right address space for MEM_REF created for bool/enum sanitization [PR115172]
The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't. Together with asan it then causes that load to be sanitized.
2024-05-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/115172
* ubsan.c (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space. Formatting fix.
Jason Merrill [Thu, 25 Jan 2024 17:02:07 +0000 (12:02 -0500)]
c++: array of PMF [PR113598]
Here AGGREGATE_TYPE_P includes pointers to member functions, which is not
what we want. Instead we should use class||array, as elsewhere in the
function.
Jason Merrill [Wed, 27 Mar 2024 20:14:01 +0000 (16:14 -0400)]
c++: __is_constructible ref binding [PR100667]
The requirement that a type argument be complete is excessive in the case of
direct reference binding to the same type, which does not rely on any
properties of the type. This is LWG 2939.
PR c++/100667
gcc/cp/ChangeLog:
* semantics.c (same_type_ref_bind_p): New.
(finish_trait_expr): Use it.
Jason Merrill [Tue, 2 Apr 2024 14:52:28 +0000 (10:52 -0400)]
c++: binding reference to comma expr [PR114561]
We represent a reference binding where the referent type is more qualified
by a ck_ref_bind around a ck_qual. We performed the ck_qual and then tried
to undo it with STRIP_NOPS, but that doesn't work if the conversion is
buried in COMPOUND_EXPR. So instead let's avoid performing that fake
conversion in the first place.
PR c++/114561
PR c++/114562
gcc/cp/ChangeLog:
* call.c (convert_like_internal): Avoid adding qualification
conversion in direct reference binding.
gcc/testsuite/ChangeLog:
* g++.dg/conversion/ref10.C: New test.
* g++.dg/conversion/ref11.C: New test.
PR libstdc++/114803
* include/experimental/bits/simd_builtin.h
(_SimdBase2::operator __vector_type_t): There is no __builtin()
function in _SimdWrapper, instead use its conversion operator.
* testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New
test.
PR libstdc++/114750
* include/experimental/bits/simd_builtin.h
(_SimdImplBuiltin::_S_load, _S_store): Fall back to copying
scalars if the memory type cannot be vectorized for the target.
* include/experimental/bits/simd_x86.h (_S_masked_unary):
Cast inputs < 16 bytes to 16 byte vectors before calling the
right subtraction builtin. Before returning, truncate to the
return vector type.
* include/experimental/bits/simd_x86.h (_S_masked_unary): Call
the 4- and 8-byte variants of __builtin_ia32_subp[ds] without
rounding direction argument.
PR libstdc++/109822
* include/experimental/bits/simd_builtin.h (_S_store): Rewrite
to avoid casts to other vector types. Implement store as
succession of power-of-2 sized memcpy to avoid PR90424.
Matthias Kretz [Fri, 2 Jun 2023 11:44:22 +0000 (13:44 +0200)]
libstdc++: Replace use of incorrect non-temporal store
The call to the base implementation sometimes didn't find a matching
signature because the _Abi parameter of _SimdImpl* was "wrong" after
conversion. It has to call into <new ABI tag>::_SimdImpl instead of the
current ABI tag's _SimdImpl. This also reduces the number of possible
template instantiations.
PR libstdc++/110054
* include/experimental/bits/simd_builtin.h (_S_masked_store):
Call into deduced ABI's SimdImpl after conversion.
* include/experimental/bits/simd_x86.h (_S_masked_store_nocvt):
Don't use _mm_maskmoveu_si128. Use the generic fall-back
implementation. Also fix masked stores without SSE2, which
were not doing anything before.
Objective-C, NeXT, v2: Correct a regression in code-gen.
There have been several changes in the ABI of Objective-C which
depend on the OS version targetted. In this case Protocols and
LabelProtocols should be made weak/hidden/extern from macOS 10.7
however there was a mistake in the code causing this to occur
from macOS 10.6. Fixed thus.
gcc/objc/ChangeLog:
* objc-next-runtime-abi-02.c (WEAK_PROTOCOLS_AFTER): New.
(next_runtime_abi_02_protocol_decl): Use WEAK_PROTOCOLS_AFTER
to determine this ABI change.
(build_v2_protocol_list_address_table): Likewise.
Jakub Jelinek [Thu, 9 May 2024 09:18:21 +0000 (11:18 +0200)]
testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]
The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.
This fixes it by adding -Wno-psabi, like commonly done in other tests.
2024-05-09 Jakub Jelinek <jakub@redhat.com>
PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.
Andrew Pinski [Sun, 24 Sep 2023 04:53:09 +0000 (21:53 -0700)]
Fix PR 110386: backprop vs ABSU_EXPR
The issue here is that when backprop tries to go
and strip sign ops, it skips over ABSU_EXPR but
ABSU_EXPR not only does an ABS, it also changes the
type to unsigned.
Since strip_sign_op_1 is only supposed to strip off
sign changing operands and not ones that change types,
removing ABSU_EXPR here is correct. We don't handle
nop conversions so this does cause any missed optimizations either.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
The problem here is after r6-7425-ga9fee7cdc3c62d0e51730,
the comparison to see if the transformation could be done was using the
wrong value. Instead of see if the inner was LE (for MIN and GE for MAX)
the outer value, it was comparing the inner to the value used in the comparison
which was wrong.
Committed to GCC 13 branch after bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR tree-optimization/111331
* tree-ssa-phiopt.c (minmax_replacement):
Fix the LE/GE comparison for the
`(a CMP CST1) ? max<a,CST2> : a` optimization.
gcc/testsuite/ChangeLog:
PR tree-optimization/111331
* gcc.c-torture/execute/pr111331-1.c: New test.
* gcc.c-torture/execute/pr111331-2.c: New test.
* gcc.c-torture/execute/pr111331-3.c: New test.
Andrew Pinski [Sun, 10 Mar 2024 22:17:09 +0000 (22:17 +0000)]
Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351]
The problem here is that merge_truthop_with_opposite_arm would
use the type of the result of the comparison rather than the operands
of the comparison to figure out if we are honoring NaNs.
This fixes that oversight and now we get the correct results in this
case.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
PR middle-end/95351
gcc/ChangeLog:
* fold-const.c (merge_truthop_with_opposite_arm): Use
the type of the operands of the comparison and not the type
of the comparison.
Andrew Pinski [Tue, 20 Feb 2024 21:38:28 +0000 (13:38 -0800)]
c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]
After r7-987-gf17a223de829cb, the access for the elements of a vector type would lose the qualifiers.
So if we had `constvector[0]`, the type of the element of the array would not have const on it.
This was due to a missing build_qualified_type for the inner type of the vector when building the array type.
We need to add back the call to build_qualified_type and now the access has the correct qualifiers. So the
overloads and even if it is a lvalue or rvalue is correctly done.
Note we correctly now reject the testcase gcc.dg/pr83415.c which was incorrectly accepted after r7-987-gf17a223de829cb.
Built and tested for aarch64-linux-gnu.
PR c++/89224
gcc/c-family/ChangeLog:
* c-common.c (convert_vector_to_array_for_subscript): Call build_qualified_type
for the inner type.
gcc/cp/ChangeLog:
* constexpr.c (cxx_eval_array_reference): Compare main variants
for the vector/array types instead of the types directly.
gcc/testsuite/ChangeLog:
* g++.dg/torture/vector-subaccess-1.C: New test.
* gcc.dg/pr83415.c: Change warning to error.
Peter Bergner [Thu, 2 May 2024 23:07:05 +0000 (18:07 -0500)]
rs6000: Add OPTION_MASK_POWER8 [PR101865]
The bug in PR101865 is the _ARCH_PWR8 predefine macro is conditional upon
TARGET_DIRECT_MOVE, which can be false for some -mcpu=power8 compiles if the
-mno-altivec or -mno-vsx options are used. The solution here is to create
a new OPTION_MASK_POWER8 mask that is true for -mcpu=power8, regardless of
Altivec or VSX enablement.
Unfortunately, the only way to create an OPTION_MASK_* mask is to create
a new option, which we have done here, but marked it as WarnRemoved since
we do not want users using it. For stage1, we will look into how we can
create ISA mask flags for use in the compiler without the need for explicit
options.
2024-04-12 Will Schmidt <will_schmidt@linux.ibm.com>
Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/101865
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Use
OPTION_MASK_POWER8.
* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add OPTION_MASK_POWER8.
(ISA_2_7_MASKS_SERVER): Likewise.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Update
comment. Use OPTION_MASK_POWER8 and TARGET_POWER8.
* config/rs6000/rs6000.h (TARGET_SYNC_HI_QI): Use TARGET_POWER8.
* config/rs6000/rs6000.md (define_attr "isa"): Add p8.
(define_attr "enabled"): Handle it.
(define_insn "prefetch"): Use TARGET_POWER8.
* config/rs6000/rs6000.opt (mpower8-internal): New.
gcc/testsuite/
PR target/101865
* gcc.target/powerpc/predefine-p7-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-noaltivec-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-noaltivec.c: New test.
* gcc.target/powerpc/predefine-p8-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-pragma-vsx.c: New test.
* gcc.target/powerpc/predefine-p9-novsx.c: New test.
Peter Bergner [Tue, 9 Apr 2024 20:24:39 +0000 (15:24 -0500)]
rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR [PR101865]
This is a cleanup patch in preparation to fixing the real bug in PR101865.
TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that.
Also replace all usages of OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
and delete the now dead mask.
2024-04-09 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/101865
* config/rs6000/rs6000.h (TARGET_DIRECT_MOVE): Define.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR. Delete redundant
OPTION_MASK_DIRECT_MOVE usage. Delete TARGET_DIRECT_MOVE dead code.
(rs6000_opt_masks): Neuter the "direct-move" option.
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR. Delete useless
comment.
* config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
OPTION_MASK_DIRECT_MOVE.
(OTHER_P8_VECTOR_MASKS): Likewise.
(POWERPC_MASKS): Likewise.
* config/rs6000/rs6000.opt (mdirect-move): Remove Mask and Var.
I caused a regression with commit r10-908 by adding a constraint to the
non-explicit allocator-extended default constructor, but seemingly
forgot to add an explicit overload with the corresponding constraint.
Iain Sandoe [Sat, 13 Jan 2024 17:20:47 +0000 (17:20 +0000)]
jit, Darwin: Implement library exports list.
Currently, we have no exports list for libgccjit, which means that
all symbols are exported, including those from libstdc++ which is
linked statically into the lib. This causes failures when the
shared libstdc++ is used but some c++ symbols are satisfied from
libgccjit.
This implements an export file for Darwin (which is currently
manually created by cross-checking libgccjit.map). Ideally we'd
script this, at some point. Update libtool current and age to
reflect the current ABI version (we are not bumping the SO name
at this stage).
This fixes a number of new failures in jit testing.
gcc/jit/ChangeLog:
* Make-lang.in: Implement exports list, and use a shared
libgcc.
* libgccjit.exports: New file.
Iain Sandoe [Sun, 31 Mar 2024 10:22:58 +0000 (11:22 +0100)]
testsuite: Remove duplicate -lgcov [PR114034]
Duplicate library entries now cause linker warnings with newer linker
versions on Darwin which leads to these tests regressing. The library
is already added by the test flags so there is no need to put an extra
one in the options.
PR testsuite/114034
gcc/testsuite/ChangeLog:
* g++.dg/gcov/gcov-dump-1.C: Remove extra -lgcov.
* g++.dg/gcov/gcov-dump-2.C: Likewise.
Iain Sandoe [Sun, 31 Mar 2024 22:25:31 +0000 (23:25 +0100)]
Darwin: Do not emit .macinfo when dsymutil cannot consume it.
Some verions of dsymutil do not ignore .macinfo sections, but instead
ignore the entire debug in the file.
To avoid this total loss of debug, when we detect that the debug level
is g3 and the dsymutil version cannot support it, we reduce the level
to g2 and issue a note.
This behaviour can be overidden by -gstrict-dwarf (although the objects
will contain macinfo; dsymutil will not produce a .dSYM with it).
gcc/ChangeLog:
* config/darwin.c (darwin_override_options): Reduce the debug
level to 2 if dsymutil cannot handle .macinfo sections.
Iain Sandoe [Thu, 8 Feb 2024 17:54:31 +0000 (17:54 +0000)]
libstdc++, Darwin: Handle a linker warning [PR112397].
Darwin's linker warns when we make a direct branch to code that is
in a weak definition (citing that if a different implementation of
the weak function is chosen by the dynamic linker this would be an
error).
As the analysis in the PR shows, this can happen when we have hot/
cold partitioning and there is an error path that is primarily cold
but makes use of epilogue code in the hot section. In this simple
case, we can easily deduce that the code is in fact safe; however
that is not something we can realistically implement in the linker.
Since the user-replaceable allocators are implemented using weak
definitions, this is a warning that is frequently flagged up in both
the testsuite and end-user code.
The chosen solution here is to suppress the hot/cold partitioning for
these cases (it is unlikely to impact performance much c.f. the
actual allocation).
PR target/112397
libstdc++-v3/ChangeLog:
* configure: Regenerate.
* configure.ac: Detect if we are building for Darwin.
* libsupc++/Makefile.am: If we are building for Darwin, then
suppress hot/cold partitioning for the array allocators.
* libsupc++/Makefile.in: Regenerated.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
(cherry picked from commit 1609fdff16f17ead37666f6d0e801800ee3d04d2)
Iain Sandoe [Mon, 18 Mar 2024 10:06:44 +0000 (10:06 +0000)]
testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].
The intent of the test is to show that we find a framework that
is installed in /System/Library/Frameworks when the user has added
a '-F' option. The trick is to choose some header that is present
for all the Darwin versions we support and that does not contain any
content we cannot parse. We had been using the Kernel framework for
this, but recent SDK versions have revealed that this is not suitable.
Replacing with a use of IOKit.
PR target/114049
gcc/testsuite/ChangeLog:
* gcc.dg/framework-1.c: Use an IOKit header instead of a
Kernel one.
Iain Sandoe [Mon, 18 Mar 2024 09:57:33 +0000 (09:57 +0000)]
libstdc++: Sync the atomic_link_flags implementation with GCC.
For Darwin, in order to allow uninstalled testing, we need to provide
a '-B' option pointing to each path containing an uninstalled library
that we are using (these get appended to the embedded runpaths).
This updates the version of the atomic_link_flags proc in the libstdc++
testsuite to do the same as the one in the GCC testsuite.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (atomic_link_flags): Emit a -B
option for the path to the uninstalled libatomic.
Iain Sandoe [Tue, 19 Mar 2024 10:40:50 +0000 (10:40 +0000)]
libstdc++, Darwin: Do not use dev/null as the file for executables.
Darwin has a separate debug linker, which is invoked when the command
line contains source files and debug is enabled.
Using /dev/null as the executable name does not, therefore, work when
debug is enabled, since the debug linker does not accept /dev/null as
a valid executable name.
The leads to incorrectly UNSUPPORTED testcases because of the unintended
error result from the test compilation.
The solution here is to use a temporary file that is deleted at the
end of the test (which is the mechanism used elsewhere)
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp (v3_target_compile): Instead of
/dev/null, use a temporary file for test executables on Darwin.
Iain Sandoe [Mon, 29 Jan 2024 10:09:25 +0000 (10:09 +0000)]
testsuite, Darwin: Allow for undefined symbols in shared test.
Darwin's linker defaults to error on undefined (which makes it look as
if we do not support shared, leading to tests being marked incorrectly
as unsupported).
This fixes the issue by allowing the symbols used in the target
supports test to be undefined.
On macOS, system headers redefine by default some macros (memcpy,
memmove, etc) to checked versions, which defeats the analyzer. We
want to turn this off.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
gcc/testsuite/ChangeLog:
PR analyzer/104042
* gcc.dg/analyzer/analyzer.exp: Pass -D_FORTIFY_SOURCE=0 on Darwin.
Iain Sandoe [Sun, 19 Jun 2022 09:31:01 +0000 (10:31 +0100)]
testsuite, asan: Avoid color in asan test output.
The presence of the color markers in the some of the asan tests
appears to confuse the dg-output matching (possibly a platform
TCL or termios bug) on some Darwin platforms.
Since the color is not being tested, switch it off (makes the log
files easier to read too). This fixes a large number of spurious
test fails on AVX512 Darwin19.
Two of the encode testcases include '-lobjc' as their dg-options.
Since the library is already appended as part of the generic testsuite
handling, this means that two instances appear on the link line leading
to spurious warnings from Darwin's new linker.
Iain Sandoe [Thu, 25 Jan 2024 20:11:09 +0000 (20:11 +0000)]
Objective-C, Darwin: Do not overalign CFStrings and Objective-C metadata.
We have reports of regressions in both Objective-C and Objective-C++ on
Darwin23 (macOS 14). In some cases, these are linker warnings about the
alignment of CFString constants; in other cases the built executables
crash during runtime initialization. The underlying issue is the same in
both cases; since the objects (CFStrings, Objective-C meta-data) are TU-
local, we are choosing to increase their alignment for efficiency - to
values greater than ABI alignment.
However, although these objects are TU-local, they are also visible to the
linker (since they are placed in specific named sections). In many cases
the metadata can be regarded as tables of data, and thus it is expected
that these sections can be concatenated from multiple TUs and the data
treated as tabular. In order for this to work the data cannot be allowed
to exceed ABI alignment - which leads to the crashes.
For GCC-15+ it would be nice to find a more elegant solution to this issue
(perhaps by adjusting the concept of binds-locally to exclude specific
named sections) - but I do not want to do that in stage 4.
The solution here is to force the alignment to be preserved as created by
setting DECL_USER_ALIGN on the relevant objects.
gcc/ChangeLog:
* config/darwin.c (darwin_build_constant_cfstring): Prevent over-
alignment of CFString constants by setting DECL_USER_ALIGN.
Iain Sandoe [Mon, 8 Jan 2024 16:17:04 +0000 (16:17 +0000)]
Darwin: Fix a typo in Objective-C meta-data.
We have a typo in the metadata for assigning NSStrings to a specific
section for the V1 (32b) ABI. When that is fixed we should never see
the case where the section needs to be deduced from the properties of
the DECLs.
gcc/ChangeLog:
* config/darwin.c (darwin_objc1_section): Use the correct
meta-data version for constant strings.
(machopic_select_section): Assert if we fail to handle CFString
sections as Obejctive-C meta-data or drectly.
Although this only fires for one of the Darwin sub-ports, it is latent
elsewhere, it is also a regression c.f. the Darwin system compiler.
In the code we imported from an earlier branch, CFString objects (which
are constant aggregates) are constructed as CONST_DECLs. Although our
current documentation suggests that these are reserved for enumeration
values, in fact they are used elsewhere in the compiler for constants.
This includes Objective-C where they are used to form NSString constants.
In the particular case, we take the address of the constant and that
triggers varasm.cc:decode_addr_constant, which does not currently support
CONST_DECL.
If there is a general intent to allow/encourage wider use of CONST_DECL,
then we should fix decode_addr_constant to look through these and evaluate
the initializer (a two-line patch, but I'm not suggesting it for stage-4).
We also need to update the GCC internals documentation to allow for the
additional uses.
This patch is Darwin-local and fixes the problem by making the CFString
constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan
to back-port this to the open branches once it has baked a while on trunk.
Since, for Darwin, the Objective-C default is to construct constant
NSString objects as CFStrings; this will also cover the majority of cases
there (this patch does not make any changes to Objective-C NSStrings).
PR target/105522
gcc/ChangeLog:
* config/darwin.c (machopic_select_section): Handle C and C++
CFStrings.
(darwin_rename_builtins): Move this out of the CFString code.
(darwin_libc_has_function): Likewise.
(darwin_build_constant_cfstring): Create an anonymous var to
hold each CFString.
* config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant
CFstrings.
Iain Sandoe [Sat, 6 Jan 2024 19:21:40 +0000 (19:21 +0000)]
Objective-C, Darwin: Fix a regression in handling bad receivers.
This is seen on 32b hosts with a 64b multilib, and is an ICE when
the build has checking enabled. The fix is to exit the routine
early if the sender or receiver are already error_mark_node.
gcc/objc/ChangeLog:
* objc-next-runtime-abi-02.c
(build_v2_objc_method_fixup_call): Early exit for cases
where the sender or receiver are known to be in error.
Iain Sandoe [Wed, 25 Oct 2023 14:28:52 +0000 (15:28 +0100)]
Darwin: Handle the fPIE option specially.
For Darwin, PIE requires PIC codegen, but otherwise is only a link-time
change. For almost all Darwin, we do not report __PIE__; the exception is
32bit X86 and from Darwin12 to 17 only (32 bit is no longer supported
after Darwin17).
Darwin: Make metadata symbol lables linker-visible for GNU objc.
Now we have shifted to using the same relocation mechanism as clang for
objective-c typeinfo the static linker needs to have a linker-visible
symbol for metadata names (this is only needed for GNU objective C, for
NeXT the names are in seaprate sections).
gcc/ChangeLog:
* config/darwin.h
(darwin_label_is_anonymous_local_objc_name): Make metadata names
linker-visibile for GNU objective C.
There are two problems here; first that the emitted asm for
-fdebug-types-section is ELF-specfic leading to assembler errors for
Mach-O. If we fix this, we get a secondary fail since the debug linker
does not recognise DW_FORM_ref_sig8. Disable ths test until we get
DWARF-5 support in the external Darwin toolchain components.
Darwin: Move checking of the 'shared' driver spec.
This avoids a bunch of irrelevant diagnostics if the user passes '-shared' to
gnatmake. Currently, we push '-dynamiclib' back onto the command line (since
that is the Darwin spelling of 'shared') but this is not handled by gnat1,
leading to a diagnostic for every character after the '-d'.
'-shared' has no effect on gnatmake (it needs to be passed to gnatbind).
This moves the handling of '-shared' to leaf specs so that we do not need to
push 'dynamiclib' onto the command line.
gcc/ChangeLog:
* config/darwin.h:
(SUBTARGET_DRIVER_SELF_SPECS): Move handling of 'shared' into the same
specs as 'dynamiclib'. (STARTFILE_SPEC): Handle 'shared'.
projects / thirdparty / gcc.git / log
