Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
As the associated test case in PR114846 shows, currently
with eh_return involved some register restoring for EH
RETURN DATA in epilogue can clobber the one which holding
the return value. Referring to the existing handlings in
some other targets, this patch makes eh_return expander
call one new define_insn_and_split eh_return_internal which
directly calls rs6000_emit_epilogue with epilogue_type
EPILOGUE_TYPE_EH_RETURN instead of the previous treating
normal return with crtl->calls_eh_return specially.
PR target/114846
gcc/ChangeLog:
* config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): As
EPILOGUE_TYPE_EH_RETURN would be passed as epilogue_type directly
now, adjust the relevant handlings on it.
* config/rs6000/rs6000.md (eh_return expander): Append by calling
gen_eh_return_internal and emit_barrier.
(eh_return_internal): New define_insn_and_split, call function
rs6000_emit_epilogue with epilogue type EPILOGUE_TYPE_EH_RETURN.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr114846.c: New test.
(cherry picked from commit e5fc5d42d25c86ae48178db04ce64d340a834614)
|
|
|
|
|
|
|
|
The CPU features initialization code uses CPUID registers (rather than
HWCAP). The equality comparisons it uses are incorrect: for example FEAT_SVE
is not set if SVE2 is available. Using HWCAPs for these is both simpler and
correct. The initialization must also be done atomically to avoid multiple
threads causing corruption due to non-atomic RMW accesses to the global.
libgcc:
PR target/115342
* config/aarch64/cpuinfo.c (__init_cpu_features_constructor):
Use HWCAP where possible. Use atomic write for initialization.
Fix FEAT_PREDRES comparison.
(__init_cpu_features_resolver): Use atomic load for correct
initialization.
(__init_cpu_features): Likewise.
(cherry picked from commit d7cbcfe7c33645eaf95f175f19884d443817857b)
|
|
* Running a test compiled with AVX512 instructions requires
avx512f_runtime not just avx512f.
* The 'reduce2' test violated an invariant of fixed_size_simd_mask and
thus failed on all targets without 16-Byte vector builtins enabled (in
bits/simd.h).
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
PR libstdc++/115575
* testsuite/experimental/simd/pr115454_find_last_set.cc: Require
avx512f_runtime. Don't memcpy fixed_size masks.
(cherry picked from commit 77f321435b4ac37992c2ed6737ca0caa1dd50551)
|
|
gcc_cv_as_mips_explicit_relocs_pcrel
We check gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel
only, while gcc_cv_as_mips_explicit_relocs is used by later code.
gcc
* configure.ac: Set gcc_cv_as_mips_explicit_relocs if
gcc_cv_as_mips_explicit_relocs_pcrel.
* configure: Regenerate.
(cherry picked from commit 573f11ec34eeb6a6c3bd3d7619738f927236727b)
|
|
The following adds the missing guard for volatile stores to the
embedded DSE in the loop if-conversion pass.
PR tree-optimization/115278
* tree-if-conv.cc (ifcvt_local_dce): Do not DSE volatile stores.
* g++.dg/vect/pr115278.cc: New testcase.
(cherry picked from commit 65dbe0ab7cdaf2aa84b09a74e594f0faacf1945c)
|
|
When there's a permute after an extern vector we can run into a case
that didn't consider the scheduled node being a permute which lacks
a representative.
PR tree-optimization/115508
* tree-vect-slp.cc (vect_schedule_slp_node): Guard check on
representative.
* gcc.target/i386/pr115508.c: New testcase.
(cherry picked from commit 65e72b95c63a5501cf1482f3814ae8c8e672bf06)
|
|
SLP permute nodes can end up without a SLP_REPRESENTATIVE now,
the following avoids touching it in this case in vect_schedule_slp_node.
* tree-vect-slp.cc (vect_schedule_slp_node): Avoid looking
at SLP_REPRESENTATIVE for VEC_PERM nodes.
(cherry picked from commit 31e9bae0ea5e5413abfa3ca9050e66cc6760553e)
|
|
|
|
With the change to the AVX512 find_last_set implementation, the change
to AVX512 operator!= is unnecessary. However, the latter was not
producing optimal code and unnecessarily set the padding bits. In
theory, the compiler could determine that with the new !=
implementation, the bit operation for clearing the padding bits is a
no-op and can be elided.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
PR libstdc++/115454
* include/experimental/bits/simd_x86.h (_S_not_equal_to): Use
neq comparison instead of bitwise negation after eq.
(_S_find_last_set): Clear unused high bits before computing
bit_width.
* testsuite/experimental/simd/pr115454_find_last_set.cc: New
test.
(cherry picked from commit 1340ddea0158de3f49aeb75b4013e5fc313ff6f4)
|
|
gcc/testsuite/ChangeLog:
* g++.dg/torture/vshuf-mem.C: Use -march=z14 only, if the we are
on a machine which can actually run it.
(cherry picked from commit 7e59f0c05da840ca13ba73d25947df8a4eaf199e)
|
|
The newly added test FAILs on i686-linux.
On x86_64-linux
make check-g++ RUNTESTFLAGS='--target_board=unix\{-m64,-m32/-msse2,-m32/-mno-sse/-mno-mmx\} dg-torture.exp=vshuf-mem.C'
shows that as well.
The problem is that without SSE2/MMX the vector is passed differently
than normally and so GCC warns about that.
-Wno-psabi is the usual way to shut it up.
Also wonder about the
// { dg-additional-options "-march=z14" { target s390*-*-* } }
line, doesn't that mean the test will FAIL on all pre-z14 HW?
Shouldn't it use some z14_runtime or similar effective target, or
check in main (in that case copied over to g++.target/s390) whether
z14 instructions can be actually used at runtime?
2024-06-14 Jakub Jelinek <jakub@redhat.com>
* g++.dg/torture/vshuf-mem.C: Add -Wno-psabi to dg-options.
(cherry picked from commit 1bb2535c7cb279e6aab731e79080d8486dd50cce)
|
|
The current implementation assumes to always be invoked with register
operands. For memory operands we even have an instruction
though (vlrep). With the patch we try this first and only if it fails
force the input into a register and continue.
vec_splats generation fails for single element 128bit types which are
allowed for vec_splat. This is something to sort out with another
patch I guess.
gcc/ChangeLog:
* config/s390/s390.cc (expand_perm_as_replicate): Handle memory
operands.
* config/s390/vx-builtins.md (vec_splats<mode>): Turn into parameterized expander.
(@vec_splats<mode>): New expander.
gcc/testsuite/ChangeLog:
* g++.dg/torture/vshuf-mem.C: New test.
(cherry picked from commit 21fd8c67ad297212e3cb885883cc8df8611f3040)
|
|
We don't really support _Complex _BitInt(N), the only place we use
bitint complex types is for the .{ADD,SUB,MUL}_OVERFLOW internal function
results and COMPLEX_EXPR in the usual case should be either not present
yet because the ifns weren't folded and will be lowered, or optimized
into something simpler, because normally the complex bitint should be
used just for extracting the 2 subparts from it.
Still, with disabled optimizations it can occassionally happen that it
appears in the IL and that is why there is support for lowering those,
but it doesn't handle optimizing those too much, so if it uses SSA_NAME,
it relies on them having a backing VAR_DECL during the lowering.
This is normally achieves through the
&& ((is_gimple_assign (use_stmt)
&& (gimple_assign_rhs_code (use_stmt)
!= COMPLEX_EXPR))
|| gimple_code (use_stmt) == GIMPLE_COND)
hunk in gimple_lower_bitint, but as the following testcase shows, there
is one thing I've missed, the load optimization isn't guarded by the
above stuff. So, either we'd need to add support for loads to
lower_complexexpr_stmt, or because they should be really rare, this
patch just disables the load optimization if at least one load use is
a COMPLEX_EXPR (like we do already for PHIs, calls, asm).
2024-06-19 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/115544
* gimple-lower-bitint.cc (gimple_lower_bitint): Disable optimizing
loads used by COMPLEX_EXPR operands.
* gcc.dg/bitint-107.c: New test.
(cherry picked from commit 25860fd2a674373a6476af5ff0bd92354fc53d06)
|
|
The option_map array for most entries contains just non-NULL opt0
{ "-Wno-", NULL, "-W", false, true },
{ "-fno-", NULL, "-f", false, true },
{ "-gno-", NULL, "-g", false, true },
{ "-mno-", NULL, "-m", false, true },
{ "--debug=", NULL, "-g", false, false },
{ "--machine-", NULL, "-m", true, false },
{ "--machine-no-", NULL, "-m", false, true },
{ "--machine=", NULL, "-m", false, false },
{ "--machine=no-", NULL, "-m", false, true },
{ "--machine", "", "-m", false, false },
{ "--machine", "no-", "-m", false, true },
{ "--optimize=", NULL, "-O", false, false },
{ "--std=", NULL, "-std=", false, false },
{ "--std", "", "-std=", false, false },
{ "--warn-", NULL, "-W", true, false },
{ "--warn-no-", NULL, "-W", false, true },
{ "--", NULL, "-f", true, false },
{ "--no-", NULL, "-f", false, true }
and so add_misspelling_candidates works correctly for it, but 3 out of
these,
{ "--machine", "", "-m", false, false },
{ "--machine", "no-", "-m", false, true },
and
{ "--std", "", "-std=", false, false },
use non-NULL opt1. That says that
--machine foo
should map to
-mfoo
and
--machine no-foo
should map to
-mno-foo
and
--std c++17
should map to
-std=c++17
add_misspelling_canidates was not handling this, so it hapilly
registered say
--stdc++17
or
--machineavx512
(twice) as spelling alternatives, when those options aren't recognized.
Instead we support
--std c++17
or
--machine avx512
--machine no-avx512
The following patch fixes that. On this particular testcase, we no longer
suggest anything, even when among the suggestion is say that
--std c++17
or
-std=c++17
etc.
2024-06-17 Jakub Jelinek <jakub@redhat.com>
PR driver/115440
* opts-common.cc (add_misspelling_candidates): If opt1 is non-NULL,
add a space and opt1 to the alternative suggestion text.
* g++.dg/cpp1z/pr115440.C: New test.
(cherry picked from commit 96db57948b50f45235ae4af3b46db66cae7ea859)
|
|
|
|
|
|
|
|
The warning code uses %D to print the ARRAY_REF first operands.
That works in the most common case where those operands are decls, but
as can be seen on the following testcase, they can be other expressions
with array type.
Just changing %D to %E isn't enough, because then the diagnostics can
suggest something like
note: use '&(x) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0] == &(y) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0]' to compare the addresses
which is a bad suggestion, the %E printing doesn't know that the
warning code will want to add & before it and [0] after it.
So, the following patch adds ()s around the operand as well, but does
that only for non-decls, for decls keeps it as &arr[0] like before.
2024-06-17 Jakub Jelinek <jakub@redhat.com>
PR c/115290
* c-warn.cc (do_warn_array_compare): Use %E rather than %D for
printing op0 and op1; if those operands aren't decls, also print
parens around them.
* c-c++-common/Warray-compare-3.c: New test.
(cherry picked from commit b63c7d92012f92e0517190cf263d29bbef8a06bf)
|
|
if float/double are same size [PR115511]
On AVR and SH with some options sizeof (float) == sizeof (double) and
the 2 types have the same set of values.
http://eel.is/c++draft/conv.rank#2.2 for this says that double still
has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2
says that extended type with the same set of values as more than one
standard floating point type shall have the same rank as double.
I've implemented the latter rule as
if (cnt > 1 && mv2 == long_double_type_node)
return -2;
with the _Float64/double/long double case having same mode case (various
targets with -mlong-double-64) in mind.
But never thought there are actually targets where float and double
are the same, that needs handling too, if cnt > 1 (that is the extended
type mv1 has same set of values as 2 or 3 of float/double/long double)
and mv2 is float, we need to return 2, because mv1 in that case should
have same rank as double and double has bigger rank than float.
2024-06-17 Jakub Jelinek <jakub@redhat.com>
PR target/111343
PR c++/115511
* typeck.cc (cp_compare_floating_point_conversion_ranks): If an
extended floating point type mv1 has same set of values as more
than one standard floating point type and mv2 is float, return 2.
* g++.dg/cpp23/ext-floating18.C: New test.
(cherry picked from commit 8584c98f370cd91647c184ce58141508ca478a12)
|
|
Since the terms of a requires-clause are grammatically primary-expressions
and not e.g. postfix-expressions, it seems we need to explicitly handle
and diagnose the case where a term parses to a bare unresolved identifier,
like cp_parser_postfix_expression does, since cp_parser_primary_expression
leaves that up to its callers. Otherwise we incorrectly accept the first
three requires-clauses below.
Note that the only occurrences of primary-expression in the grammar are
postfix-expression and constraint-logical-and-expression, so it's not too
surprising that we need this special handling here.
PR c++/99678
gcc/cp/ChangeLog:
* parser.cc (cp_parser_constraint_primary_expression): Diagnose
a bare unresolved unqualified-id.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires38.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit d387ecb2b2f44f33fd6a7c5ec7eadaf6dd70efc9)
|
|
Here during overload resolution we have two strictly viable ambiguous
candidates #1 and #2, and two non-strictly viable candidates #3 and #4
which we hold on to ever since r14-6522. These latter candidates have
an empty second arg conversion since the first arg conversion was deemed
bad, and this trips up joust when called on #3 and #4 which assumes all
arg conversions are there.
We can fix this by making joust robust to empty arg conversions, but in
this situation we shouldn't need to compare #3 and #4 at all given that
we have a strictly viable candidate. To that end, this patch makes
tourney shortcut considering non-strictly viable candidates upon
encountering ambiguity between two strictly viable candidates (taking
advantage of the fact that the candidates list is sorted according to
viability via splice_viable).
PR c++/115239
gcc/cp/ChangeLog:
* call.cc (tourney): Don't consider a non-strictly viable
candidate as the champ if there was ambiguity between two
strictly viable candidates.
gcc/testsuite/ChangeLog:
* g++.dg/overload/error7.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 7fed7e9bbc57d502e141e079a6be2706bdbd4560)
|
|
Like with alias templates, it seems we don't maintain visibility flags
for concepts either, so min_vis_expr_r should ignore them for now.
Otherwise after r14-6789 we may incorrectly give a function template that
uses a concept-id in its signature internal linkage.
PR c++/115283
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r) <case TEMPLATE_DECL>: Ignore
concepts.
gcc/testsuite/ChangeLog:
* g++.dg/template/linkage5.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit b1fe718cbe0c8883af89f52e0aad3ebf913683de)
|
|
With the change of r15-787-g57e04879389f9c I forgot to also update this
test.
gcc/testsuite/ChangeLog:
* gcc.target/s390/ifcvt-one-insn-bool.c: Fix loc.
(cherry picked from commit ac66736bf2f8a10d2f43e83ed6377e4179027a39)
|
|
Consider a NOCE conversion as profitable if there is at least one
conditional move.
gcc/ChangeLog:
PR target/109549
* config/s390/s390.cc (TARGET_NOCE_CONVERSION_PROFITABLE_P):
Define.
(s390_noce_conversion_profitable_p): Implement.
gcc/testsuite/ChangeLog:
* gcc.target/s390/ccor.c: Order of loads are reversed, now, as a
consequence the condition has to be reversed.
(cherry picked from commit 57e04879389f9c0d5d53f316b468ce1bddbab350)
|
|
|
|
|
|
I triggered an ICE on Ubuntu 24.04 when compiling code that uses
function attributes. Looking into the sources shows that we have
a systematic issue in the attribute handling code:
* we determine the length with strlen() (excluding the terminating null)
* we allocate a buffer with this length
* we copy the original string using strcpy() (incl. the terminating null)
To quote the man page of strcpy():
"The programmer is responsible for allocating a destination buffer
large enough, that is, strlen(src) + 1."
The ICE looks like this:
*** buffer overflow detected ***: terminated
xtheadmempair_bench.c:14:1: internal compiler error: Aborted
14 | {
| ^
0xaf3b99 crash_signal
/home/ubuntu/src/gcc/scaleff/gcc/toplev.cc:319
0xe5b957 strcpy
/usr/include/riscv64-linux-gnu/bits/string_fortified.h:79
0xe5b957 riscv_process_target_attr
/home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:339
0xe5baaf riscv_process_target_attr
/home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:314
0xe5bc5f riscv_option_valid_attribute_p(tree_node*, tree_node*, tree_node*, int)
/home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:389
0x6a31e5 handle_target_attribute
/home/ubuntu/src/gcc/scaleff/gcc/c-family/c-attribs.cc:5915
0x5d3a07 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/home/ubuntu/src/gcc/scaleff/gcc/attribs.cc:900
0x5db403 c_decl_attributes
/home/ubuntu/src/gcc/scaleff/gcc/c/c-decl.cc:5501
0x5e8965 start_function(c_declspecs*, c_declarator*, tree_node*)
/home/ubuntu/src/gcc/scaleff/gcc/c/c-decl.cc:10562
0x6318ed c_parser_declaration_or_fndef
/home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:2914
0x63a8ad c_parser_external_declaration
/home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:2048
0x63b219 c_parser_translation_unit
/home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:1902
0x63b219 c_parse_file()
/home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:27277
0x68fec5 c_common_parse_file()
/home/ubuntu/src/gcc/scaleff/gcc/c-family/c-opts.cc:1311
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch):
Fix allocation size of buffer.
(riscv_process_one_target_attr): Likewise.
(riscv_process_target_attr): Likewise.
(cherry picked from commit 6762d5738b02d84ad3f51e89979b48acb68db65b)
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
|
|
|
|
Thanks to Jérôme Duval for noticing this.
libstdc++-v3/ChangeLog:
* libsupc++/new_opa.cc [!_GLIBCXX_HOSTED]: Fix declaration of
posix_memalign.
(cherry picked from commit 161efd677458f20d13ee1018a4d5e3964febd508)
|
|
|
|
|
|
This patch adds missing assembly directives to the CMSE library wrapper to call
functions with attribute cmse_nonsecure_call. Without the .type directive the
linker will fail to produce the correct veneer if a call to this wrapper
function is to far from the wrapper itself. The .size was added for
completeness, though we don't necessarily have a usecase for it.
libgcc/ChangeLog:
PR target/115360
* config/arm/cmse_nonsecure_call.S: Add .type and .size directives.
(cherry picked from commit c559353af49fe5743d226ac3112a285b27a50f6a)
|
|
For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.
gcc/testsuite/ChangeLog:
PR target/115253
* gcc.target/arm/cmse/extend-return.c: Update test case
condition for Armv8.1-M.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Co-authored-by: Yvan ROUX <yvan.roux@foss.st.com>
(cherry picked from commit cf5f9171bae1f5f3034dc9a055b77446962f1a8c)
|
|
Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is an internal compiler error on Cortex-M23 for the
epilog processing of sign extension.
This patch addresses the following CVE-2024-0151 for Armv8-M.baseline.
gcc/ChangeLog:
PR target/115253
* config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
Sign extend for Thumb1.
(thumb1_expand_prologue): Add zero/sign extend.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Co-authored-by: Yvan ROUX <yvan.roux@foss.st.com>
(cherry picked from commit 65bd0655ece268895e5018e393bafb769e201c78)
|
|
|
|
Just like r13-6662-g0e6f87835ccabf but this time for jit/jit-recording.cc.
Pushed as obvious after a quick build to make sure jit still builds.
gcc/jit/ChangeLog:
PR jit/115442
* jit-recording.cc: Define INCLUDE_SSTREAM before including
system.h and don't directly incldue sstream.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
(cherry picked from commit e4244b88d75124f6957bfa080c8ad34017364e53)
|
|
go_through_subreg used:
else if (!can_div_trunc_p (SUBREG_BYTE (x),
REGMODE_NATURAL_SIZE (GET_MODE (x)), offset))
to calculate the register offset for a pseudo subreg x. In the blessed
days before poly-int, this was:
*offset = (SUBREG_BYTE (x) / REGMODE_NATURAL_SIZE (GET_MODE (x)));
But I think this is testing the wrong natural size. If we exclude
paradoxical subregs (which will get an offset of zero regardless),
it's the inner register that is being split, so it should be the
inner register's natural size that we use.
This matters in the testcase because we have an SFmode lowpart
subreg into the last of three variable-sized vectors. The
SUBREG_BYTE is therefore equal to the size of two variable-sized
vectors. Dividing by the vector size gives a register offset of 2,
as expected, but dividing by the size of a scalar FPR would give
a variable offset.
I think something similar could happen for fixed-size targets if
REGMODE_NATURAL_SIZE is different for vectors and integers (say),
although that case would trade an ICE for an incorrect offset.
gcc/
PR rtl-optimization/115281
* ira-conflicts.cc (go_through_subreg): Use the natural size of
the inner mode rather than the outer mode.
gcc/testsuite/
PR rtl-optimization/115281
* gfortran.dg/pr115281.f90: New test.
(cherry picked from commit 46d931b3dd31cbba7c3355ada63f155aa24a4e2b)
|
|
|
|
Here find_parameter_packs_r is incorrectly treating the 'auto' return
type of a lambda as a parameter pack due to Concepts-TS specific logic
added in r6-4517, leading to confusion later when expanding the pattern.
Since we intend on removing Concepts TS support soon anyway, this patch
fixes this by restricting the problematic logic with flag_concepts_ts.
Doing so revealed that add_capture was relying on this logic to set
TEMPLATE_TYPE_PARAMETER_PACK for the 'auto' type of an pack expansion
init-capture, which we now need to do explicitly.
PR c++/115378
gcc/cp/ChangeLog:
* lambda.cc (lambda_capture_field_type): Set
TEMPLATE_TYPE_PARAMETER_PACK on the auto type of an init-capture
pack expansion.
* pt.cc (find_parameter_packs_r) <case TEMPLATE_TYPE_PARM>:
Restrict TEMPLATE_TYPE_PARAMETER_PACK promotion with
flag_concepts_ts.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/decltype-auto-103497.C: Adjust expected diagnostic.
* g++.dg/template/pr95672.C: Likewise.
* g++.dg/cpp2a/lambda-targ5.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 5c761395402a730535983a5e49ef1775561ebc61)
|
|
This just adds the missing guard.
gcc/ada/
PR ada/114708
* exp_util.adb (Finalize_Address): Add guard for incomplete types.
gcc/testsuite/
* gnat.dg/incomplete8.adb: New test.
|
|
gcc/testsuite/
PR ada/114398
* gnat.dg/access11.adb: New test.
|
|
At runtime the code generated by the compiler reports the
exception Storage_Error in an indirect call through an
access-to-subprogram variable that references a function
returning a limited tagged type object.
gcc/ada/
* sem_ch6.adb (Might_Need_BIP_Task_Actuals): Add support
for access-to-subprogram parameter types.
* exp_ch6.adb (Add_Task_Actuals_To_Build_In_Place_Call):
Add dummy BIP parameters to access-to-subprogram types
that may reference a function that has BIP parameters.
|
|
Much like AT_HWCAP is already provided in case the platform headers
don't have the value (yet).
libgcc/
* config/aarch64/cpuinfo.c: Provide AT_HWCAP2.
|
|
The special case for Clang in the trait producing a signed integer type
lead to the trait returning 'char' where it should have been 'signed
char'. This workaround was introduced because on Clang the return type
of vector compares was not convertible to '_SimdWrapper<
__int_for_sizeof_t<...' unless '__int_for_sizeof_t<char>' was an alias
for 'char'. In order to not rewrite the complete mask type code (there
is code scattered around the implementation assuming signed integers),
this needs to be 'signed char'; so the special case for Clang needs to
be removed.
The conversion issue is now solved in _SimdWrapper, which now
additionally allows conversion from vector types with compatible
integral type.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
PR libstdc++/115308
* include/experimental/bits/simd.h (__int_for_sizeof): Remove
special cases for __clang__.
(_SimdWrapper): Change constructor overload set to allow
conversion from vector types with integral conversions via bit
reinterpretation.
(cherry picked from commit 8e36cf4c5c9140915d0019999db132a900b48037)
|
|
This resolves a regression on i686 that was introduced with
r15-429-gfb1649f8b4ad50.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
PR libstdc++/115247
* include/experimental/bits/simd.h (__as_vector): Don't use
vector_size(8) on __i386__.
(__vec_shuffle): Never return MMX vectors, widen to 16 bytes
instead.
(concat): Fix padding calculation to pick up widening logic from
__as_vector.
(cherry picked from commit 241a6cc88d866fb36bd35ddb3edb659453d6322e)
|
|
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
PR libstdc++/114958
* include/experimental/bits/simd.h (__as_vector): Return scalar
simd as one-element vector. Return vector from single-vector
fixed_size simd.
(__vec_shuffle): New.
(__extract_part): Adjust return type signature.
(split): Use __extract_part for any split into non-fixed_size
simds.
(concat): If the return type stores a single vector, use
__vec_shuffle (which calls __builtin_shufflevector) to produce
the return value.
* include/experimental/bits/simd_builtin.h
(__shift_elements_right): Removed.
(__extract_part): Return single elements directly. Use
__vec_shuffle (which calls __builtin_shufflevector) to for all
non-trivial cases.
* include/experimental/bits/simd_fixed_size.h (__extract_part):
Return single elements directly.
* testsuite/experimental/simd/pr114958.cc: New test.
(cherry picked from commit fb1649f8b4ad5043dd0e65e4e3a643a0ced018a9)
|