| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
The following testcase is miscompiled since r279392 aka r10-5451-gef29b12cfbb4979
The strlen pass has adjust_last_stmt function, which performs mainly strcat
or strcat-like optimizations (say strcpy (x, "abcd"); strcat (x, p);
or equivalent memcpy (x, "abcd", strlen ("abcd") + 1); char *q = strchr (x, 0);
memcpy (x, p, strlen (p)); etc. where the first stmt stores '\0' character
at the end but next immediately overwrites it and so the first memcpy can be
adjusted to store 1 fewer bytes. handle_builtin_memcpy called this function
in two spots, the first one guarded like:
if (olddsi != NULL
&& tree_fits_uhwi_p (len)
&& !integer_zerop (len))
adjust_last_stmt (olddsi, stmt, false);
i.e. only for constant non-zero length. The other spot can call it even
for non-constant length but in that case we punt before that if that length
isn't length of some string + 1, so again non-zero.
The r279392 change I assume wanted to add some warning stuff and changed it
like
if (olddsi != NULL
- && tree_fits_uhwi_p (len)
&& !integer_zerop (len))
- adjust_last_stmt (olddsi, stmt, false);
+ {
+ maybe_warn_overflow (stmt, len, rvals, olddsi, false, true);
+ adjust_last_stmt (olddsi, stmt, false);
+ }
While maybe_warn_overflow possibly handles non-constant length fine,
adjust_last_stmt really relies on length to be non-zero, which
!integer_zerop (len) alone doesn't guarantee. While we could for
len being SSA_NAME ask the ranger or tree_expr_nonzero_p, I think
adjust_last_stmt will not benefit from it much, so the following patch
just restores the above condition/previous behavior for the adjust_last_stmt
call only.
2023-08-30 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/110914
* tree-ssa-strlen.c (strlen_pass::handle_builtin_memcpy): Don't call
adjust_last_stmt unless len is known constant.
* gcc.c-torture/execute/pr110914.c: New test.
(cherry picked from commit 398842e7038ea0f34054f0f694014d0ecd656846)
|
|
The following testcase shows that we mishandle bit insertion for
info->bitsize >= 64. The problem is in using unsigned HOST_WIDE_INT
shift + subtraction + build_int_cst to compute mask, the shift invokes
UB at compile time for info->bitsize 64 and larger and e.g. on the testcase
with info->bitsize happens to compute mask of 0x3f rather than
0x3f'ffffffff'ffffffff.
The patch fixes that by using wide_int wi::mask + wide_int_to_tree, so it
handles masks in any precision (up to WIDE_INT_MAX_PRECISION ;) ).
2023-08-30 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/111015
* gimple-ssa-store-merging.c
(imm_store_chain_info::output_merged_store): Use wi::mask and
wide_int_to_tree instead of unsigned HOST_WIDE_INT shift and
build_int_cst to build BIT_AND_EXPR mask.
* gcc.dg/pr111015.c: New test.
(cherry picked from commit 49a3b35c4068091900b657cd36e5cffd41ef0c47)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
instructions
gcc/ChangeLog:
* config/i386/i386.opt: Add new option mgather.
|
|
affected Intel Processors.
For more details of GDS (Gather Data Sampling), refer to
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/gather-data-sampling.html
After microcode update, there's performance regression. To avoid that,
the patch disables gather generation in autovectorization but uses
gather scalar emulation instead.
gcc/ChangeLog:
* config/i386/i386-options.c (m_GDS): New macro.
* config/i386/x86-tune.def (X86_TUNE_USE_GATHER): Don't enable
for m_GDS.
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx2-gather-2.c: Adjust options to keep
gather vectorization.
* gcc.target/i386/avx2-gather-6.c: Ditto.
* gcc.target/i386/avx512f-pr88464-1.c: Ditto.
* gcc.target/i386/avx512f-pr88464-5.c: Ditto.
* gcc.target/i386/avx512vl-pr88464-1.c: Ditto.
* gcc.target/i386/avx512vl-pr88464-11.c: Ditto.
* gcc.target/i386/avx512vl-pr88464-3.c: Ditto.
* gcc.target/i386/avx512vl-pr88464-9.c: Ditto.
(cherry picked from commit 3064d1f5c48cb6ce1b4133570dd08ecca8abb52d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When late processing a noexcept-spec from a nested class after completion
of the outer class (since it's a complete-class context), we pass the wrong
class context to noexcept_override_late_checks -- the outer class type
instead of the nested class type -- which leads to bogus errors in the
below test.
This patch fixes this by making noexcept_override_late_checks obtain the
class context directly via DECL_CONTEXT instead of via an additional
parameter.
PR c++/109761
gcc/cp/ChangeLog:
* parser.c (cp_parser_class_specifier): Don't pass a class
context to noexcept_override_late_checks.
(noexcept_override_late_checks): Remove 'type' parameter
and use DECL_CONTEXT of 'fndecl' instead.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept78.C: New test.
(cherry picked from commit c13906f258fb34b3e0c90ddc8d9191dd72f3da0e)
|
|
Don't access leaf 7 subleaf 1 unless subleaf 0 says it is
supported via EAX.
Intel documentation says invalid subleaves return 0. We had been
relying on that behavior instead of checking the max sublef number.
It appears that some Sandy Bridge CPUs return at least the subleaf 0
EDX value for subleaf 1. Best guess is that this is a bug in a
microcode patch since all of the bits we're seeing set in EDX were
introduced after Sandy Bridge was originally released.
This is causing avxvnniint16 to be incorrectly enabled with
-march=native on these CPUs.
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features): Check
max_subleaf_level for valid subleaf before use CPUID.
|
|
|
|
|
|
|
|
The pr107397.f90 test FAILs for me, one problem was that the
added diagnostics has an indefinite article before BOZ, but
the test dg-error didn't. The other problem was that on the
other dg-error there was no space between the string and closing
}, so it was completely ignored and the error was an excess
error.
2022-12-19 Jakub Jelinek <jakub@redhat.com>
PR fortran/107397
* gfortran.dg/pr107397.f90: Adjust expected diagnostic wording and
add space between dg-error string and closing }.
(cherry picked from commit 03fb35f8753d87148b29b3f34b6154abe7db4c41)
|
|
PR fortran/107397
gcc/fortran/ChangeLog:
* decl.c (add_init_expr_to_sym): Add check with new error message.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr107397.f90: New test.
(cherry picked from commit 09710f9934969dcb07131e1ed78b72e648123a3a)
|
|
|
|
PR fortran/103506
gcc/fortran/ChangeLog:
* parse.c (parse_module): Remove use of a bool error value
that prevented proper setting of the namespace pointer.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr103506_1.f90: New test.
(cherry picked from commit 8011fbba7baa46947341ca8069b5a327163a68d5)
|
|
|
|
|
|
|
|
|
|
PR110741 exposes one issue that we didn't use the correct
character for vsx operands in output operand substitution,
consequently it can map to the wrong registers which hold
some unexpected values.
PR target/110741
gcc/ChangeLog:
* config/rs6000/altivec.md (define_insn xxeval): Correct vsx
operands output with "x".
gcc/testsuite/ChangeLog:
* g++.target/powerpc/pr110741.C: New test.
(cherry picked from commit 96a839233ced3a0bfc3d5492a6d8b102e6981472)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
