libcpp currently lacks the infrastructure to assign correct locations to
macros that were defined prior to loading a PCH and then restored
afterwards. While I plan to address that fully for GCC 15, this patch
improves things by using at least a valid location, even if it's not the
best one. Without this change, libcpp uses pfile->directive_line as the
location for the restored macros, but this location_t applies to the old
line map, not the one that was just restored from the PCH, so the resulting
location is unpredictable and depends on what was stored in the line maps
before. With this change, all restored macros get assigned locations at the
line of the #include that triggered the PCH restore. A future patch will
store the actual file name and line number of each definition and then
synthesize locations in the new line map pointing to the right place.
gcc/c-family/ChangeLog:
PR preprocessor/105608
* c-pch.cc (c_common_read_pch): Adjust line map so that libcpp
assigns a location to restored macros which is the same location
that triggered the PCH include.
libcpp/ChangeLog:
PR preprocessor/105608
* pch.cc (cpp_read_state): Set a valid location for restored
macros.
We crash in the loop at the end of treat_lvalue_as_rvalue_p for code
like
template <class T>
concept Throwable = requires(T x) { throw x; };
because the code assumes that we eventually reach sk_function_parms or
sk_try and bail, but in a concept we're in a sk_namespace.
We're already checking sk_try so we don't crash in a function-try-block,
but I've added a test anyway.
PR c++/112437
gcc/cp/ChangeLog:
* typeck.cc (treat_lvalue_as_rvalue_p): Bail out on sk_namespace in
the move on throw of parms loop.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-throw1.C: New test.
* g++.dg/eh/throw4.C: New test.
Add sifive p600 series scheduler module. For more information
see https://www.sifive.com/cores/performance-p650-670.
Add sifive-p650, sifive-p670 for mcpu option will come in separate patches.
gcc/ChangeLog:
* config/riscv/riscv.md: Add "fcvt_i2f", "fcvt_f2i" type
attribute, and include sifive-p600.md.
* config/riscv/generic-ooo.md: Update type attribute.
* config/riscv/generic.md: Update type attribute.
* config/riscv/sifive-7.md: Update type attribute.
* config/riscv/sifive-p600.md: New file.
* config/riscv/riscv-cores.def (RISCV_TUNE): Add parameter.
* config/riscv/riscv-opts.h (enum riscv_microarchitecture_type):
Add sifive_p600.
* config/riscv/riscv.cc (sifive_p600_tune_info): New.
* config/riscv/riscv.h (TARGET_SFB_ALU): Update.
* doc/invoke.texi (RISC-V Options): Add sifive-p600-series
The RISC-V Profiles specification here:
https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions
These extensions don't add any new features but
describe existing features. So this patch only adds parsing.
Za64rs: Reservation set size of 64 bytes
Za128rs: Reservation set size of 128 bytes
Ziccif: Main memory supports instruction fetch with atomicity requirement
Ziccrse: Main memory supports forward progress on LR/SC sequences
Ziccamoa: Main memory supports all atomics in A
Zicclsm: Main memory supports misaligned loads/stores
Zic64b: Cache block size isf 64 bytes
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Add Za64rs, Za128rs,
Ziccif, Ziccrse, Ziccamoa, Zicclsm, Zic64b items.
* config/riscv/riscv.opt: New macro for 7 new unprivileged
extensions.
* doc/invoke.texi (RISC-V Options): Add Za64rs, Za128rs,
Ziccif, Ziccrse, Ziccamoa, Zicclsm, Zic64b extensions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/za-ext.c: New test.
* gcc.target/riscv/zi-ext.c: New test.
g++.dg/asan/default-options-1.C FAILs on Solaris/SPARC and x86:
FAIL: g++.dg/asan/default-options-1.C -O0 execution test
FAIL: g++.dg/asan/default-options-1.C -O1 execution test
FAIL: g++.dg/asan/default-options-1.C -O2 execution test
FAIL: g++.dg/asan/default-options-1.C -O2 -flto execution test
FAIL: g++.dg/asan/default-options-1.C -O2 -flto -flto-partition=none execution test
FAIL: g++.dg/asan/default-options-1.C -O3 -g execution test
FAIL: g++.dg/asan/default-options-1.C -Os execution test
The failure is always the same:
AddressSanitizer: CHECK failed: asan_rtl.cpp:397 "((!AsanInitIsRunning() && "ASan init calls itself!")) != (0)" (0x0, 0x0) (tid=1)
This happens because libasan makes unportable assumptions about
initialization order that don't hold on Solaris. The problem has
already been fixed in clang by
[Driver] Link shared asan runtime lib with -z now on Solaris/x86
https://reviews.llvm.org/D156325
where it was way more prevalent.
This patch applies the same fix to gcc.
Tested on i386-pc-solaris2.11 (ld and gld) and sparc-sun-solaris2.11.
2024-01-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc:
* config/sol2.h (LIBASAN_EARLY_SPEC): Add -z now unless
-static-libasan. Add missing whitespace.
The gcc.target/i386/no-callee-saved-[12].c tests FAIL on Solaris/x86:
FAIL: gcc.target/i386/no-callee-saved-1.c scan-assembler-not push
FAIL: gcc.target/i386/no-callee-saved-2.c scan-assembler-not push
In both cases, the test expect the Linux/x86 default of
-fomit-frame-pointer, while Solaris/x86 defaults to
-fno-omit-frame-pointer.
So this patch explicitly specifies -fomit-frame-pointer.
Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu.
2024-01-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* gcc.target/i386/no-callee-saved-1.c: Add -fomit-frame-pointer to
dg-options.
* gcc.target/i386/no-callee-saved-2.c: Likewise.
gcc.target/i386/avx512vl-stv-rotatedi-1.c FAILs on 32-bit Solaris/x86
since its introduction in
commit 4814b63c3c
Author: Roger Sayle <roger@nextmovesoftware.com>
Date: Mon Jul 10 09:04:29 2023 +0100
i386: Add AVX512 support for STV of SI/DImode rotation by constant.
FAIL: gcc.target/i386/avx512vl-stv-rotatedi-1.c scan-assembler-times vpro[lr]q 29
While the test depends on -mstv, 32-bit Solaris/x86 defaults to
-mstackrealign which is incompatible.
The patch thus specifies -mstv -mno-stackrealign explicitly.
Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu.
2024-01-23 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* gcc.target/i386/avx512vl-stv-rotatedi-1.c: Add -mstv
-mno-stackrealign to dg-options.
gcc.target/i386/pr70321.c FAILs on 32-bit Solaris/x86 since its
introduction in
commit 43201f2c21
Author: Roger Sayle <roger@nextmovesoftware.com>
Date: Mon May 30 21:20:09 2022 +0100
PR target/70321: Split double word equality/inequality after STV on x86.
FAIL: gcc.target/i386/pr70321.c scan-assembler-times mov 1
The failure happens because 32-bit Solaris/x86 defaults to
-fno-omit-frame-pointer.
Fixed by specifying -fomit-frame-pointer explicitly.
Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu.
2024-01-23 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* gcc.target/i386/pr70321.c: Add -fomit-frame-pointer to
dg-options.
The new g++.dg/ext/attr-section2*.C tests FAIL on Solaris/SPARC with the
native assembler:
+FAIL: g++.dg/ext/attr-section2.C -std=c++14 scan-assembler
.(section|csect)[ \\\\t]+.foo
+FAIL: g++.dg/ext/attr-section2.C -std=c++17 scan-assembler
.(section|csect)[ \\\\t]+.foo
+FAIL: g++.dg/ext/attr-section2.C -std=c++20 scan-assembler
.(section|csect)[ \\\\t]+.foo
The problem is that the SPARC assembler requires the section name to be
double-quoted, like
.section ".foo%_Z3varIiE",#alloc,#write,#progbits
This patch allows for that. At the same time, it quotes literal dots in
the REs.
Tested on sparc-sun-solaris2.11 (as and gas) and i386-pc-solaris2.11 (as
and gas).
2024-01-18 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* g++.dg/ext/attr-section2.C (scan-assembler): Quote dots. Allow
for double-quoted section name.
* g++.dg/ext/attr-section2a.C: Likewise.
* g++.dg/ext/attr-section2b.C: Likewise.
For OpenACC/GCN '-march=gfx1100', a lot of libgomp OpenACC test cases FAIL:
/tmp/ccGfLJ8a.mkoffload.2.s:406:2: error: instruction not supported on this GPU
ds_cmpst_rtn_b32 v0, v0, v4, v3
^
In RDNA 3, 'ds_cmpst_[...]' has been replaced by 'ds_cmpstore_[...]', and the
notes for 'ds_cmpst_[...]' in pre-RDNA 3 ISA manuals:
Caution, the order of src and cmp are the *opposite* of the BUFFER_ATOMIC_CMPSWAP opcode.
..., have been resolved for 'ds_cmpstore_[...]' in the RDNA 3 ISA manual:
In this architecture the order of src and cmp agree with the BUFFER_ATOMIC_CMPSWAP opcode.
..., and therefore '%2', '%3' now swapped with regards to GCC operand order.
Most of the affected libgomp OpenACC test cases then PASS their execution test.
gcc/
* config/gcn/gcn.md (sync_compare_and_swap<mode>_lds_insn)
[TARGET_RDNA3]: Adjust.
Although PR 111627 can be fixed by renaming testsuite modules it
highlighted that a possible ICE can occur if a malformed
implementation module is actually a program module. This small
patch defends against this ICE and checks to see whether the module
is a DefImp before testing IsDefinitionForC.
gcc/m2/ChangeLog:
PR modula2/111627
PR modula2/112506
* gm2-compiler/M2Comp.mod (Pass0CheckMod): Test IsDefImp before
checking IsDefinitionForC.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
The following fixes LC SSA preserving with region VN which was broken
when availability checking was enhanced to treat not visited value
numbers as available. The following makes sure to honor availability
data we put in place for LC SSA preserving instead.
PR tree-optimization/113693
* tree-ssa-sccvn.cc (rpo_elim::eliminate_avail): Honor avail
data when available.
* gcc.dg/pr113693.c: New testcase.
Use aarch64-asm.h in asm code consistently, this was started in
commit c608ada288
Author: Zac Walker <zacwalker@microsoft.com>
CommitDate: 2024-01-23 15:32:30 +0000
Ifdef `.hidden`, `.type`, and `.size` pseudo-ops for `aarch64-w64-mingw32` target
But that commit failed to remove some existing markings from asm files,
which means some objects got double marked with gnu property notes.
libgcc/ChangeLog:
* config/aarch64/crti.S: Remove stack marking.
* config/aarch64/crtn.S: Remove stack marking, include aarch64-asm.h
* config/aarch64/lse.S: Remove stack and GNU property markings.
Since the r14-1500-g4d935f52b0d5c0 commit we promote an initializer_list
backing array to static storage where appropriate, but this happens after
we decided to add it to asan_poisoned_variables. As a result we add
unpoison/poison for it to the gimple. But then sanopt removes the unpoison.
So the second time we call the function and want to load from the array asan
still considers it poisoned.
The following patch fixes it by removing the .ASAN_MARK internal calls
during gimple lowering if they refer to TREE_STATIC vars.
2024-02-01 Jakub Jelinek <jakub@redhat.com>
Jason Merrill <jason@redhat.com>
PR c++/113531
* gimple-low.cc (lower_stmt): Remove .ASAN_MARK calls
on variables which were promoted to TREE_STATIC.
* g++.dg/asan/initlist1.C: New test.
Co-authored-by: Jason Merrill <jason@redhat.com>
This patch resolves PR113560, a code quality regression from GCC12
affecting x86_64, by enhancing the middle-end's tree-ssa-math-opts.cc
to recognize more instances of widening multiplications.
The widening multiplication perception code identifies cases like:
_1 = (unsigned __int128) x;
__res = _1 * 100;
but in the reported test case, the original input looks like:
_1 = (unsigned long long) x;
_2 = (unsigned __int128) _1;
__res = _2 * 100;
which gets optimized by constant folding during tree-ssa to:
_2 = x & 18446744073709551615; // x & 0xffffffffffffffff
__res = _2 * 100;
where the BIT_AND_EXPR hides (has consumed) the extension operation.
This reveals the more general deficiency (missed optimization
opportunity) in widening multiplication perception that additionally
both
__int128 foo(__int128 x, __int128 y) {
return (x & 1000) * (y & 1000)
}
and
unsigned __int128 bar(unsigned __int128 x, unsigned __int128) {
return (x >> 80) * (y >> 80);
}
should be recognized as widening multiplications. Hence rather than
test explicitly for BIT_AND_EXPR (as in the first version of this patch)
the more general solution is to make use of range information, as
provided by tree_non_zero_bits.
As a demonstration of the observed improvements, function foo above
currently with -O2 compiles on x86_64 to:
foo: movq %rdi, %rsi
movq %rdx, %r8
xorl %edi, %edi
xorl %r9d, %r9d
andl $1000, %esi
andl $1000, %r8d
movq %rdi, %rcx
movq %r9, %rdx
imulq %rsi, %rdx
movq %rsi, %rax
imulq %r8, %rcx
addq %rdx, %rcx
mulq %r8
addq %rdx, %rcx
movq %rcx, %rdx
ret
with this patch, GCC recognizes the *w and instead generates:
foo: movq %rdi, %rsi
movq %rdx, %r8
andl $1000, %esi
andl $1000, %r8d
movq %rsi, %rax
imulq %r8
ret
which is perhaps easier to understand at the tree-level where
__int128 foo (__int128 x, __int128 y)
{
__int128 _1;
__int128 _2;
__int128 _5;
<bb 2> [local count: 1073741824]:
_1 = x_3(D) & 1000;
_2 = y_4(D) & 1000;
_5 = _1 * _2;
return _5;
}
gets transformed to:
__int128 foo (__int128 x, __int128 y)
{
__int128 _1;
__int128 _2;
__int128 _5;
signed long _7;
signed long _8;
<bb 2> [local count: 1073741824]:
_1 = x_3(D) & 1000;
_2 = y_4(D) & 1000;
_7 = (signed long) _1;
_8 = (signed long) _2;
_5 = _7 w* _8;
return _5;
}
2023-02-01 Roger Sayle <roger@nextmovesoftware.com>
Richard Biener <rguenther@suse.de>
gcc/ChangeLog
PR target/113560
* tree-ssa-math-opts.cc (is_widening_mult_rhs_p): Use range
information via tree_non_zero_bits to check if this operand
is suitably extended for a widening (or highpart) multiplication.
(convert_mult_to_widen): Insert explicit casts if the RHS or LHS
isn't already of the claimed type.
gcc/testsuite/ChangeLog
PR target/113560
* g++.target/i386/pr113560.C: New test case.
* gcc.target/i386/pr113560.c: Likewise.
* gcc.dg/pr87954.c: Update test case.
Enables assert that every typed instruction is associated with a
dfa reservation
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert
After r14-1187-gd6b756447cd58b, simplify_gen_subreg can return
NULL for "unaligned" memory subreg. Since V8DI has an alignment of 8 bytes,
using TImode causes simplify_gen_subreg to return NULL.
This fixes the issue by using DImode instead for the loop. And then we will have
later on the STP/LDP pass combine it back into STP/LDP if needed.
Since strict align is less important (usually used for firmware and early boot only),
not doing LDP/STP here is ok.
Built and tested for aarch64-linux-gnu with no regressions.
PR target/113657
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (split for movv8di):
For strict aligned mode, use DImode instead of TImode.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/acle/ls64_strict_align.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
PR analyzer/113253 reports a case where the analyzer output varied
with and without -g enabled.
The root cause was that debug stmts were in the
FOR_EACH_IMM_USE_FAST list for SSA names, leading to the analyzer's
state purging logic differing between the -g and non-debugging cases,
and thus leading to differences in the exploration of the user's code.
Fix by skipping such stmts in the state-purging logic, and removing
debug stmts when constructing the supergraph.
gcc/analyzer/ChangeLog:
PR analyzer/113253
* region-model.cc (region_model::on_stmt_pre): Add gcc_unreachable
for debug statements.
* state-purge.cc
(state_purge_per_ssa_name::state_purge_per_ssa_name): Skip any
debug stmts in the FOR_EACH_IMM_USE_FAST list.
* supergraph.cc (supergraph::supergraph): Don't add debug stmts
to the supernodes.
gcc/testsuite/ChangeLog:
PR analyzer/113253
* gcc.dg/analyzer/deref-before-check-pr113253.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Bug 112571 reports an ICE-on-invalid for cases where an enum is
defined, without a fixed underlying type, inside the enum type
specifier for a definition of that same enum with a fixed underlying
type.
The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a
case where it is NULL. Avoid this by clearing
ENUM_FIXED_UNDERLYING_TYPE_P in thie case of inconsistent definitions.
Bootstrapped wth no regressions for x86_64-pc-linux-gnu.
PR c/112571
gcc/c/
* c-decl.cc (start_enum): Clear ENUM_FIXED_UNDERLYING_TYPE_P when
defining without a fixed underlying type an enumeration previously
declared with a fixed underlying type.
gcc/testsuite/
* gcc.dg/c23-enum-9.c, gcc.dg/c23-enum-10.c: New tests.
In PR113607 we see an invalid fold of
_429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0, ... });
vect_prephitmp_129.51_282 = _429;
vect_iftmp.55_287 = VEC_COND_EXPR <mask_patt_209.54_286, vect_prephitmp_129.51_282, vect_cst__262>;
to
Applying pattern match.pd:9607, gimple-match-10.cc:3817
gimple_simplified to vect_iftmp.55_287 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0, ... });
where we essentially use COND_SHL's else instead of VEC_COND_EXPR's.
This patch adjusts the corresponding match.pd pattern and makes it only
match when the else values are the same.
That, however, causes the exact test case for which this pattern was
introduced for to fail. Therefore XFAIL it for now.
gcc/ChangeLog:
PR middle-end/113607
* match.pd: Make sure else values match when folding a
vec_cond into a conditional operation.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/pre_cond_share_1.c: XFAIL.
* gcc.target/riscv/rvv/autovec/pr113607-run.c: New test.
* gcc.target/riscv/rvv/autovec/pr113607.c: New test.
We plan to remove -fconcepts-ts in GCC 15 and thus remove the flag_concepts_ts
code. This note is an admonishing reminder to convert the Concepts TS
code to C++20 Concepts.
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Add an inform saying that
-fconcepts-ts is deprecated and will be removed in GCC 15.
gcc/ChangeLog:
* doc/invoke.texi: Mention that -fconcepts-ts was deprecated in GCC 14.
Set TYPE_STUB_DECL to an artificial decl when creating a new structure
as a composite type.
PR c/113438
gcc/c/
* c-typeck.cc (composite_type_internal): Set TYPE_STUB_DECL.
gcc/testsuite/
* gcc.dg/pr113438.c: New test.
Ensure sp variable is long enough by using __UINTPTR_TYPE__ for
rsp.
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/uninit-pr108968-register.c:
Use __UINTPTR_TYPE__ instead of unsigned long for LLP64.
This patch improves a comment and also adds the location tokenno to
possibly exported idents as they are encountered.
gcc/m2/ChangeLog:
* gm2-compiler/M2Comp.mod (Pass0CheckMod): Tidy up comment.
* gm2-compiler/P1Build.bnf (PossiblyExportIdent): Replace
PushTF with PushTFtok.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
This patch renames gm2 testsuite modules whose names conflict with library
modules. The conflict is not seen on case preserving case sensitive file
systems.
gcc/testsuite/ChangeLog:
PR modula2/111627
* gm2/pim/pass/stdio.mod: Moved to...
* gm2/pim/pass/teststdio.mod: ...here.
* gm2/pim/run/pass/builtins.mod: Moved to...
* gm2/pim/run/pass/testbuiltins.mod: ...here.
* gm2/pim/run/pass/math.mod: Moved to...
* gm2/pim/run/pass/testmath.mod: ...here.
* gm2/pim/run/pass/math2.mod: Moved to...
* gm2/pim/run/pass/testmath2.mod: ...here.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
Recently something in the midend had started inverting the branches by inverting
the condition and the branches.
While this is fine, it makes it hard to actually test. In RTL I disable
scheduling and BB reordering to prevent this. But in GIMPLE there seems to be
nothing I can do. __builtin_expect seems to have no impact on the change since
I suspect this is happening during expand where conditions can be flipped
regardless of probability during compare_and_branch.
Since the mid-end has plenty of correctness tests, this weakens the backend
tests to just check that a correct looking sequence is emitted.
gcc/testsuite/ChangeLog:
PR testsuite/113502
* gcc.target/aarch64/sve/vect-early-break-cbranch.c: Ignore exact branch.
* gcc.target/aarch64/vect-early-break-cbranch.c: Likewise.
With recent updates to hwasan runtime libraries, the error reporting for
this particular check is has been reworked.
I would question why it has lost this message. To me it looks strange
that num_descriptions_printed is incremented whenever we call
PrintHeapOrGlobalCandidate whether that function prints anything or not.
(See PrintAddressDescription in libsanitizer/hwasan/hwasan_report.cpp).
The message is no longer printed because we increment this
num_descriptions_printed variable indicating that we have found some
description.
I would like to question this upstream, but it doesn't look that much of
a problem and if pressed for time we should just change our testsuite.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
gcc/testsuite/ChangeLog:
PR sanitizer/112644
* c-c++-common/hwasan/hwasan-thread-clears-stack.c: Update testcase.
Recent libhwasan updates[1] intercept various string and memory functions.
These functions have checking in them, which means there's no need to
inline the checking.
This patch marks said functions as intercepted, and adjusts a testcase
to handle the difference. It also looks for HWASAN in a check in
expand_builtin. This check originally is there to avoid using expand to
inline the behaviour of builtins like memset which are intercepted by
ASAN and hence which we rely on the function call staying as a function
call. With the new reliance on function calls in HWASAN we need to do
the same thing for HWASAN too.
HWASAN and ASAN don't seem to however instrument the same functions.
Looking into libsanitizer/sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc
it looks like the common ones are memset, memmove and memcpy.
The rest of the routines for asan seem to be defined in
compiler-rt/lib/asan/asan_interceptors.h however compiler-rt/lib/hwasan/
does not have such a file but it does have
compiler-rt/lib/hwasan/hwasan_platform_interceptors.h which it looks like is
forcing off everything but memset, memmove, memcpy, memcmp and bcmp.
As such I've taken those as the final list that hwasan currently supports.
This also means that on future updates this list should be cross checked.
[1] https://discourse.llvm.org/t/hwasan-question-about-the-recent-interceptors-being-added/75351
gcc/ChangeLog:
PR sanitizer/112644
* asan.h (asan_intercepted_p): Incercept memset, memmove, memcpy and
memcmp.
* builtins.cc (expand_builtin): Include HWASAN when checking for
builtin inlining.
gcc/testsuite/ChangeLog:
PR sanitizer/112644
* c-c++-common/hwasan/builtin-special-handling.c: Update testcase.
Co-Authored-By: Matthew Malcomson <matthew.malcomson@arm.com>
This cherry-picks and squashes the differences between commits
d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63
from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the changes relevant
for GCC.
This is required to fix the linked PR.
As mentioned in the PR the last sync brought in a bug from upstream[1] where
operations became non-recoverable and as such the tests in AArch64 started
failing. This cherry picks the fix and there are minor updates needed to GCC
after this to fix the cases.
[1] https://github.com/llvm/llvm-project/pull/74000
PR sanitizer/112644
Cherry-pick llvm-project revision
672b71cc1003533460a82f06b7d24fbdc02ffd58,
5fcf3bbb1acfe226572474636714ede86fffcce8,
3bded112d02632209bd55fb28c6c5c234c23dec3 and
76e1e45922e6709392fb82aac44bebe3dbc2ea63.
The following fixes a wrong pattern that didn't match the behavior
of the original fold_widened_comparison in that get_unwidened
returned a constant always in the wider type. But here we're
using (int) 4294967295u without the conversion applied. Fixed
by doing as earlier in the pattern - matching constants only
if the conversion was actually applied.
PR middle-end/110176
* match.pd (zext (bool) <= (int) 4294967295u): Make sure
to match INTEGER_CST only without outstanding conversion.
* gcc.dg/torture/pr110176.c: New testcase.
The PR shows us ICEing due to an unrecognizable TFmode save emitted by
aarch64_process_components. The problem is that for T{I,F,D}mode we
conservatively require mems to be in range for x-register ldp/stp. That
is because (at least for TImode) it can be allocated to both GPRs and
FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
a q-register load/store.
As Richard pointed out in the PR, aarch64_get_separate_components
already checks that the offsets are suitable for a single load, so we
just need to choose a mode in aarch64_reg_save_mode that gives the full
q-register range. In this patch, we choose V16QImode as an alternative
16-byte "bag-of-bits" mode that doesn't have the artificial range
restrictions imposed on T{I,F,D}mode.
For T{F,D}mode in GCC 15 I think we could consider relaxing the
restriction imposed in aarch64_classify_address, as typically T{F,D}mode
should be allocated to FPRs. But such a change seems too invasive to
consider for GCC 14 at this stage (let alone backports).
Fortunately the new flexible load/store pair patterns in GCC 14 allow
this mode change to work without further changes. The backports are
more involved as we need to adjust the load/store pair handling to cater
for V16QImode in a few places.
Note that for the testcase we are relying on the torture options to add
-funroll-loops at -O3 which is necessary to trigger the ICE on trunk
(but not on the 13 branch).
gcc/ChangeLog:
PR target/111677
* config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use
V16QImode for the full 16-byte FPR saves in the vector PCS case.
gcc/testsuite/ChangeLog:
PR target/111677
* gcc.target/aarch64/torture/pr111677.c: New test.
The gcc.target/i386/auto-init-5.c and gcc.target/i386/auto-init-6.c
tests FAIL on 64-bit Solaris/x86 with the native assembler:
FAIL: gcc.target/i386/auto-init-5.c scan-assembler-times \\\\.long\\t0 14
FAIL: gcc.target/i386/auto-init-6.c scan-assembler-times long\\t0 8
/bin/as doesn't fully support the CFI directives, so the .eh_frame
sections are emitted directly and contain .long. Since .eh_frame
doesn't matter for those tests, this patch disables its generation in
the first place.
Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu.
2024-01-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* gcc.target/i386/auto-init-5.c: Add
-fno-asynchronous-unwind-tables to dg-options.
* gcc.target/i386/auto-init-6.c: Likewise.
The following avoids inserting expressions for IPA CP discovered
equivalences into the VN hashtables when we are optimistically
skipping may-defs in the attempt to prove it's redundant.
PR tree-optimization/111444
* tree-ssa-sccvn.cc (vn_reference_lookup_3): Do not use
vn_reference_lookup_2 when optimistically skipping may-defs.
* gcc.dg/torture/pr111444.c: New testcase.
g++.dg/cpp0x/udlit-extended-id-1.C FAILs on Solaris/SPARC and x86 with
the native assembler:
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++14 compilation failed to produce executable
FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 (test for excess errors)
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 compilation failed to produce executable
FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++20 (test for excess errors)
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++20 compilation failed to produce executable
/bin/as doesn't support UCN identifiers:
/usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: invalid character (0xcf)
/usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: invalid character (0x80)
/usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: statement syntax
/usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: statement syntax
[...]
To avoid this, this patch requires ucn support.
Tested on i386-pc-solaris2.11 (as and gas), sparc-sun-solaris2.11 (as
and gas), and i686-pc-linux-gnu.
2024-01-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* g++.dg/cpp0x/udlit-extended-id-1.C: Require ucn support.
The following avoids code hoisting (but also PRE insertion) of
expressions that got value-numbered to another one that are not
a valid replacement (but still compute the same value). This time
because the access path ends in a structure with different size,
meaning we consider a related access as not trapping because of the
size of the base of the access.
PR tree-optimization/113630
* tree-ssa-pre.cc (compute_avail): Avoid registering a
reference with a representation with not matching base
access size.
* gcc.dg/torture/pr113630.c: New testcase.
When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF))
or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into
(float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call
simplify_gen_unary with incorrect op_mode argument, it should be
the argument's mode, but we call it with the outer mode instead.
As these are all floating point operations, the argument always
has non-VOIDmode and so we can just use that mode (as done in similar
simplifications a few lines later), but neither FLOAT_TRUNCATE nor
FLOAT_EXTEND are operations that should have the same modes of operand
and result. This bug hasn't been a problem for years because normally
op_mode is used only if the mode of op is VOIDmode, otherwise it is
redundant, but r10-2139 added an assertion in some spots that op_mode
is right even in such cases.
2024-01-31 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/113656
* simplify-rtx.cc (simplify_context::simplify_unary_operation_1)
<case FLOAT_TRUNCATE>: Fix up last argument to simplify_gen_unary.
* gcc.target/i386/pr113656.c: New test.
This spot uses SCALAR_INT_TYPE_MODE which obviously ICEs for large/huge
BITINT_TYPE types which have BLKmode. But such large BITINT_TYPEs certainly
don't fit into DWARF2_ADDR_SIZE either, so we can just assume it would be
false if type has BLKmode.
2024-01-31 Jakub Jelinek <jakub@redhat.com>
PR debug/113637
* dwarf2out.cc (loc_list_from_tree_1): Assume integral types
with BLKmode are larger than DWARF2_ADDR_SIZE.
* gcc.dg/bitint-80.c: New test.
Yet another spot where we need to treat VIEW_CONVERT_EXPR differently
from NOP_EXPR/CONVERT_EXPR.
2024-01-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113639
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
For VIEW_CONVERT_EXPR set rhs1 to its operand.
* gcc.dg/bitint-79.c: New test.
The <xlocale.h> header is needed for newlocale and locale_t on these
targets.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CHECK_TEXT_ENCODING): Use <xlocale.h> if
needed for newlocale.
* configure: Regenerate.
* src/c++26/text_encoding.cc: Use <xlocale.h>.
Reviewed-by: Iain Sandoe <iain@sandoe.co.uk>
