The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
if (entry_test_needed)
{
tem = build_range_check (loc, optype, unshare_expr (exp),
false, lowi, high);
if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.
The following testcase is miscompiled because the two abnormal cases
are triggered. The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.
The following patch ensures that.
2024-05-08 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.
* gcc.c-torture/execute/pr114965.c: New test.
(cherry picked from commit 9adec2d91e62a479474ae79df5b455fd4b8463ba)
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.cc (convert_vector_to_array_for_subscript): Call build_qualified_type
for the inner type.
gcc/cp/ChangeLog:
* constexpr.cc (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.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
(cherry picked from commit 4421d35167b3083e0f2e4c84c91fded09a30cf22)
In r14-9266-g2823b4d96d9ec4 I gave all temporary vars a DECL_CONTEXT,
including those at namespace or global scope, so that they could be
properly merged across importers. However, not all of these temporary
vars are actually supposed to be mergeable.
For instance, in the attached testcase we have an unnamed temporary var
used in the NSDMI of a class member, which cannot properly merged -- but
it also doesn't need to be, as it'll be thrown away when the class type
itself is merged anyway.
This patch reverts the change made above and instead makes a weaker
adjustment that only causes temporary vars with linkage have a
DECL_CONTEXT to merge from. This way these unnamed, "unmergeable"
temporaries are properly streamed by value again.
PR c++/114856
gcc/cp/ChangeLog:
* call.cc (make_temporary_var_for_ref_to_temp): Set context for
temporaries with linkage.
* init.cc (create_temporary_var): Revert to only set context
when in a function decl.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr114856.h: New test.
* g++.dg/modules/pr114856_a.H: New test.
* g++.dg/modules/pr114856_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
(cherry picked from commit e60032b382364897a58e67994baac896bcd03327)
The HF and BF modes have the same size/precision and neither is
a subset nor superset of the other.
So, using either __extendhfbf2 or __trunchfbf2 is weird.
The expansion apparently emits __extendhfbf2, but on the libgcc side
we apparently have __trunchfbf2 implemented.
I think it is easier to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.
2024-05-07 Jakub Jelinek <jakub@redhat.com>
PR middle-end/114907
* expr.cc (convert_mode_scalar): Use trunc_optab rather than
sext_optab for HF->BF conversions.
* optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.
* gcc.dg/pr114907.c: New test.
(cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)
In r9-5742 we've started allowing to inline always_inline functions into
functions which have disabled e.g. address sanitization even when the
always_inline function is implicitly from command line options sanitized.
This mostly works fine because most of the asan instrumentation is done only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.
Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.
2024-05-07 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/114956
* tree-inline.cc: Include asan.h.
(copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has asan/hwasan
sanitization disabled.
* gcc.dg/asan/pr114956.c: New test.
(cherry picked from commit d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a)
This bug fix corrects the test codes below by converting the constant
literals to the type required by C. In the testcases below the values, 1
etc were converted into the INTEGER type before being passed to a C
vararg function. By default in modula2 constant literal ordinals are
represented as the ZTYPE (the largest GCC integer type node).
gcc/testsuite/ChangeLog:
PR modula2/113768
PR modula2/114133
* gm2/extensions/run/pass/callingc10.mod: Convert constant literal
numbers into INTEGER.
* gm2/extensions/run/pass/callingc11.mod: Ditto.
* gm2/extensions/run/pass/vararg2.mod: Ditto.
* gm2/iso/run/pass/packed.mod: Emit a printf as a runtime
diagnostic.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
Recently -march=gfx{90c,1036,1103} support has been added, but corresponding
changes weren't done in the testsuite.
The following patch adds that.
Tested on x86_64-linux (with fiji and gfx1103 devices; had to use
OMP_DEFAULT_DEVICE=1 there, fiji doesn't really work due to LLVM dropping
support, but we still list those as offloading devices).
2024-05-02 Jakub Jelinek <jakub@redhat.com>
* testsuite/libgomp.c/declare-variant-4.h (gfx90c, gfx1036, gfx1103):
New functions.
(f): Add #pragma omp declare variant directives for those.
* testsuite/libgomp.c/declare-variant-4-gfx90c.c: New test.
* testsuite/libgomp.c/declare-variant-4-gfx1036.c: New test.
* testsuite/libgomp.c/declare-variant-4-gfx1103.c: New test.
(cherry picked from commit 5eb25d1561dd22316331feee92164f97ca79d1c3)
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.
Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.
I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128. Anyway, didn't feel I should touch that right now.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max == 0,
set max, likely and unlikely members to 1 rather than 0. Remove
useless res.knownrange = true;. Formatting fixes.
* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.
(cherry picked from commit 6c6b70f07208ca14ba783933988c04c6fc2fff42)
When adding to CLASSTYPE_BEFRIENDING_CLASSES as part of installing an
imported class definition, we need to look through TEMPLATE_DECL like
make_friend_class does.
Otherwise in the below testcase we won't add _Hashtable<int, int> to
CLASSTYPE_BEFRIENDING_CLASSES of _Map_base, which leads to a bogus
access check failure for _M_hash_code.
PR c++/114889
gcc/cp/ChangeLog:
* module.cc (trees_in::read_class_def): Look through
TEMPLATE_DECL when adding to CLASSTYPE_BEFRIENDING_CLASSES.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-8_a.H: New test.
* g++.dg/modules/friend-8_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 22b20ac6c6aead2d3f36c413a77dd0b80adfec39)
ipa/92606: Inter-procedural analysis optimizes data across
address-spaces and PROGMEM. As of v14, the PROGMEM part is
still not fixed (and there is still no target hook as proposed
in PR92932). Just disable respective bogus optimization.
PR ipa/92606
gcc/
* config/avr/avr.cc (avr_option_override): Set
flag_ipa_icf_variables = 0.
gcc/testsuite/
* gcc.target/avr/torture/pr92606.c: New test.
(cherry picked from commit 08e752e72363ae7fd5a5fcb70913a0f7b240387b)
Almost 1400 C++ analyzer tests FAIL on Solaris. The patch is too risky
to apply so close to the GCC 14.1.0 release, so disable the tests on
Solaris instead to reduce the noise.
Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.
2024-05-05 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
PR analyzer/111475
* g++.dg/analyzer/analyzer.exp: Disable on *-*-solaris2.*.
There is a bug in the for loop control code which is exposed when an
unsigned type is used in the iterator variable. See
gm2/pim/run/pass/testforloopzero[234].mod. The bug is in the
calculation of the last iterator value. The bug fix is to avoid using
negative expressions when calculating the last iterator value with a
negative step value. This patch detects if e1, e2, step value are all
constant, in which case the ztype is used internally and there is no
overflow. If the last iterator value is held in a variable then it
uses a different method to calculate the last iterator depending upon
the sign of the step value.
gcc/m2/ChangeLog:
PR modula2/114929
* gm2-compiler/M2Quads.mod (ForLoopLastIteratorVariable): New
procedure.
(ForLoopLastIteratorConstant): Ditto.
(ForLoopLastIterator): Ditto.
(BuildForToByDo): Remove LastIterator calculation and call
ForLoopLastIterator instead.
(FinalValue): Replace with ...
(LastIterator): ... this.
gcc/testsuite/ChangeLog:
PR modula2/114929
* gm2/pim/run/pass/testforloopzero.mod: New test.
* gm2/pim/run/pass/testforloopzero2.mod: New test.
* gm2/pim/run/pass/testforloopzero3.mod: New test.
* gm2/pim/run/pass/testforloopzero4.mod: New test.
(cherry picked from commit a561dc0f6c7085e102fe9e9b6abd7f2138512576)
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
When we initialize an array of a type with a non-trivial destructor, such as
the backing array for the initializer_list, we have a cleanup to destroy any
constructed elements if a later constructor throws. When the array being
created is a variable, the end of that EH region naturally coincides with
the beginning of the EH region for the cleanup for the variable as a whole.
But if the array is a temporary, or a subobject of one, the array cleanup
region lasts for the rest of the full-expression, along with the normal
cleanup for the TARGET_EXPR. As a result, when tata throws we clean it up
twice. Before r14-1705 we avoided this by disabling the array cleanup in
split_nonconstant_init, but after that we don't go through
split_nonconstant_init, so let's handle it in cp_genericize_target_expr.
PR c++/114935
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_genericize_init): Add flags parm.
(cp_genericize_init_expr): Pass nullptr.
(cp_genericize_target_expr): Handle cleanup flags.
* typeck2.cc (build_disable_temp_cleanup): Factor out of...
(split_nonconstant_init): ...here.
* cp-tree.h (build_disable_temp_cleanup): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-eh1.C: New test.
(cherry picked from commit 8f3afb83c879f1bfa722a963a07c06aaf174ef72)
When expand_call_mem_ref looks at the definition of the address
argument to eventually expand a &TARGET_MEM_REF argument together
with a masked load it fails to honor constraints imposed by SSA
coalescing decisions. The following fixes this.
PR middle-end/114734
* internal-fn.cc (expand_call_mem_ref): Use
get_gimple_for_ssa_name to get at the def stmt of the address
argument to honor SSA coalescing constraints.
(cherry picked from commit 4d3a5618de5a949c61605f545f90e81bc0000502)
The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up
replacing it with the underlying MEM_REF. This leads to an
inconsistency in the MEM_EXPR information, and could lead to wrong code.
While the walk down to the MEM_REF is necessary to update
MR_DEPENDENCE_CLIQUE, we should use the outer tree expression for the
MEM_EXPR. This patch does that.
gcc/ChangeLog:
PR rtl-optimization/114924
* cfgrtl.cc (duplicate_insn_chain): When updating MEM_EXPRs,
don't strip (e.g.) ARRAY_REFs from the final MEM_EXPR.
(cherry picked from commit fe40d525619eee9c2821126390df75068df4773a)
The vectorizer handles a _Float16 to __bf16 conversion through
vectorizable_assignment, thinking it's a noop. The following
fixes this by requiring the same vector component mode when
checking for CONVERT_EXPR_CODE_P, being stricter than for
VIEW_CONVERT_EXPR.
PR tree-optimization/114921
* tree-vect-stmts.cc (vectorizable_assignment): Require
same vector component modes for input and output for
CONVERT_EXPR_CODE_P.
(cherry picked from commit 87e35da16df74cd1c4729a55d94e7bc592487f48)
We don't want to add grouping to strings like "-inf", and there is no
radix character to replace either.
libstdc++-v3/ChangeLog:
PR libstdc++/114863
* include/std/format (__formatter_fp::format): Only use
_M_localized for finite values.
* testsuite/std/format/functions/format.cc: Check localized
formatting of NaN and initiny.
(cherry picked from commit 7501c0a397fcf609a1ff5f083746b6330b89ee11)
2024-04-29 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/114959
* trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE
if the default initializer has all NULL fields. Guard this
by a requirement that the code not be EXEC_INIT_ASSIGN and that
the object be an INTENT_OUT dummy.
* trans-stmt.cc (gfc_trans_allocate): Change the initializer
code for allocate with mold to EXEC_ALLOCATE to allow an
initializer with all NULL fields.
gcc/testsuite/
PR fortran/114959
* gfortran.dg/pr114959.f90: New test.
(cherry picked from commit bca41a8d55e830c882b0f39246afead4fcfae6f7)
The assertion doesn't allow IFN_COND_MIN/IFN_COND_MAX, which are
commutative conditional binary operations like ADD/MUL/AND/IOR/XOR,
and can be handled just fine.
In particular, we emit
vminpd %zmm3, %zmm5, %zmm0{%k2}
vminpd %zmm0, %zmm3, %zmm5{%k1}
and
vmaxpd %zmm3, %zmm5, %zmm0{%k2}
vmaxpd %zmm0, %zmm3, %zmm5{%k1}
in the vectorized loops of the first and second subroutine.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
Hongtao Liu <hongtao.liu@intel.com>
PR tree-optimization/114883
* tree-vect-loop.cc (vect_transform_reduction): Allow IFN_COND_MIN and
IFN_COND_MAX in the assert.
* gfortran.dg/pr114883.f90: New test.
(cherry picked from commit 04ef92a62af3a815b86a2037267cd4e747ae225c)
On Mon, Apr 29, 2024 at 01:44:24PM +0000, Joseph Myers wrote:
> > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> > dummy shared library with just some symbol versions for compatibility, but
> > all the pthread_* APIs are in libc.so.6).
>
> I suspect this has caused link failures in the glibc testsuite for Hurd,
> which still has separate libpthread.
>
> https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html
So like this then?
2024-04-30 Jakub Jelinek <jakub@redhat.com>
* gthr.h (GTHREAD_USE_WEAK): Don't redefine to 0 for glibc 2.34+
on GNU Hurd.
(cherry picked from commit 3146a92a77f1fccec71a880c7f890a1251aeab41)
In the sizeof / sizeof operator expression handling we're missing
a dependence check for the second operand.
PR c++/114888
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op) <case *_DIV_*>: Add missing
dependence check for the second sizeof operand.
gcc/testsuite/ChangeLog:
* g++.dg/template/sizeof19.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 3900e944b0ac9db77380c5bb8635977dfd3b0691)
This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
added in GCC 14.0.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each), together with the GLIBCXX_3.4.32 update, on both gcc-14 branch
and trunk.
2024-04-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.
This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
added in GCC 13.2.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33 update)
on both gcc-14 branch and trunk.
2024-04-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.
(cherry picked from commit 3e1ca512848994950cc0641986b6ec337df5765f)
When we build with isl, there will be a ICE for graphite in both
the c/c++ and fortran. The legitimize move cannot take care of
below rtl.
(set (subreg:DI (reg:TI 237) 8) (subreg:DI (const_poly_int:TI [4, 2]) 8))
Then we will have ice similar to below:
internal compiler error: in extract_insn, at recog.cc:2812.
This patch would like to take care of the above rtl. Given the value of
const_poly_int can hardly excceed the max of int64, we can simply
consider the highest 8 bytes of TImode is zero and then set the dest
to (const_int 0).
The below test cases are fixed by this PATCH.
C:
FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)
Fortran:
FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/graphite/pr14741.f90 -O (test for excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for
excess errors)
FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90 -O (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -g (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90 -O (test for excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for
excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr14741.f90 -O (internal compiler error:
in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -g (internal compiler
error: in extract_insn, at recog.cc:2812)
The below test suites are passed for this patch:
* The rv64gcv fully regression test.
* The rv64gc fully regression test.
Try to write some RTL code for test but not works well according to
existing test cases. Thus, take above as test cases. Please note
graphite require the gcc build with isl.
PR target/114885
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_subreg_const_poly_move): New
func impl to take care of (const_int_poly:TI 8).
(riscv_legitimize_move): Handle subreg is const_int_poly,
Signed-off-by: Pan Li <pan2.li@intel.com>
(cherry picked from commit 25213c4c11aa96aff1beda2aa4471cdff29e8953)
Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
error: could not split insn
(insn:TI 1764 67 1745
(set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
(and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
(const_int -50331649 [0xfffffffffcffffff])))
"drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111
{*bstrins_di_for_mask}
(nil))
Add these constrants to fix the issue.
gcc/ChangeLog:
PR target/114861
* config/loongarch/loongarch.md (bstrins_<mode>_for_mask): Add
constraints for operands.
(bstrins_<mode>_for_ior_mask): Likewise.
gcc/testsuite/ChangeLog:
PR target/114861
* gcc.target/loongarch/pr114861.c: New test.
(cherry picked from commit 140124ad54eef88ca87909f63aedc8aaeacefc65)
It seems the diagnostic machinery's source line printing respects
the pretty printer prefix, but this is undesirable for the call to
diagnostic_show_locus in print_instantiation_partial_context_line
(added in r14-4388-g1c45319b66edc9) since the prefix may have been
set when issuing an earlier, unrelated diagnostic and we just want
to print an unprefixed source line.
This patch naively fixes this by clearing the prefix before calling
diagnostic_show_locus.
Before this patch, for error60a.C below we'd print
gcc/testsuite/g++.dg/template/error60a.C: In function ‘void usage()’:
gcc/testsuite/g++.dg/template/error60a.C:24:3: error: ‘unrelated_error’ was not declared in this scope
24 | unrelated_error; // { dg-error "not declared" }
| ^~~~~~~~~~~~~~~
gcc/testsuite/g++.dg/template/error60a.C: In instantiation of ‘void test(Foo) [with Foo = int]’:
gcc/testsuite/g++.dg/template/error60a.C:25:13: required from here
gcc/testsuite/g++.dg/template/error60a.C:24:3: error: 25 | test<int> (42); // { dg-message " required from here" }
gcc/testsuite/g++.dg/template/error60a.C:24:3: error: | ~~~~~~~~~~^~~~
gcc/testsuite/g++.dg/template/error60a.C:19:24: error: invalid conversion from ‘int’ to ‘int*’ [-fpermissive]
19 | my_pointer<Foo> ptr (val); // { dg-error "invalid conversion from 'int' to 'int\\*'" }
| ^~~
| |
| int
gcc/testsuite/g++.dg/template/error60a.C:9:20: note: initializing argument 1 of ‘my_pointer<Foo>::my_pointer(Foo*) [with Foo = int]’
9 | my_pointer (Foo *ptr) // { dg-message " initializing argument 1" }
| ~~~~~^~~
and afterward we print
gcc/testsuite/g++.dg/template/error60a.C: In function ‘void usage()’:
gcc/testsuite/g++.dg/template/error60a.C:24:3: error: ‘unrelated_error’ was not declared in this scope
24 | unrelated_error; // { dg-error "not declared" }
| ^~~~~~~~~~~~~~~
gcc/testsuite/g++.dg/template/error60a.C: In instantiation of ‘void test(Foo) [with Foo = int]’:
gcc/testsuite/g++.dg/template/error60a.C:25:13: required from here
25 | test<int> (42); // { dg-message " required from here" }
| ~~~~~~~~~~^~~~
gcc/testsuite/g++.dg/template/error60a.C:19:24: error: invalid conversion from ‘int’ to ‘int*’ [-fpermissive]
19 | my_pointer<Foo> ptr (val); // { dg-error "invalid conversion from 'int' to 'int\\*'" }
| ^~~
| |
| int
gcc/testsuite/g++.dg/template/error60a.C:9:20: note: initializing argument 1 of ‘my_pointer<Foo>::my_pointer(Foo*) [with Foo = int]’
9 | my_pointer (Foo *ptr) // { dg-message " initializing argument 1" }
| ~~~~~^~~
gcc/cp/ChangeLog:
* error.cc (print_instantiation_partial_context_line): Clear the
pretty printer prefix around the call to diagnostic_show_locus.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic2.C: Expect source line printed
for the "required from here" message.
* g++.dg/template/error60a.C: New test.
(cherry picked from commit 7d5479a2ecf6309281de10b747a7423169a2ff95)
Add support for gfx90c GCN5 APU integrated graphics devices.
The LLVM AMDGPU documentation does not list those devices as supported
by rocm-amdhsa, but it passes most libgomp offloading tests.
Although they are constrainted compared to dGPUs, they might be
interesting for learning, experimentation, and testing.
gcc/ChangeLog:
* config.gcc: Add gfx90c.
* config/gcn/gcn-hsa.h (NO_SRAM_ECC): Likewise.
* config/gcn/gcn-opts.h (enum processor_type): Likewise.
(TARGET_GFX90c): New macro.
* config/gcn/gcn.cc (gcn_option_override): Handle gfx90c.
(gcn_omp_device_kind_arch_isa): Likewise.
(output_file_start): Likewise.
* config/gcn/gcn.h: Add gfx90c.
* config/gcn/gcn.opt: Likewise.
* config/gcn/mkoffload.cc (EF_AMDGPU_MACH_AMDGCN_GFX90c): New macro.
(get_arch): Handle gfx90c.
(main): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c
* config/gcn/t-omp-device: Add gfx90c.
* doc/install.texi: Likewise.
* doc/invoke.texi: Likewise.
libgomp/ChangeLog:
* plugin/plugin-gcn.c (isa_hsa_name): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c.
(isa_code): Handle gfx90c.
(max_isa_vgprs): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c.
Signed-off-by: Frederik Harwath <frederik@harwath.name>
The array index should not be over 8 for v8hi, or it will fail
under -O0 or using -fstack-protector.
gcc/testsuite/ChangeLog:
PR target/110621
* gcc.target/i386/pr105354-2.c: As mentioned.
BTF is the standard debug info used with BPF programs, so it makes sense
to default to BTF rather than DWARF.
gcc/
* config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG.
gcc/testsuite/
* gcc.target/bpf/bpf-debug-options-1.c: New test.
* gcc.target/bpf/bpf-debug-options-2.c: Likewise.
* gcc.target/bpf/bpf-debug-options-3.c: Likewise.
* gcc.target/bpf/core-options-4.c: Likewise.
