[Bug target/93737] inline memmove for insertion into small arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93737 --- Comment #4 from Richard Biener --- On GIMPLE we're more into canonicalization which means we avoid this kind of expansion and thus at the moment limit it to single load/store cases. But in principle we could apply the same costing as we later do during RTL expansion (note a memcpy/memmove is easier to handle for VN / alias-analysis than decomposed operation). Note memmove can be generally expanded inline if you perform all loads before the first store at the expense of requiring a temporary register for each load.
[Bug preprocessor/92319] Macro expansion using the __VA_OPT__ construct is incorrect when the variadic argument expands to nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92319 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e235031d490e8ed2aa0bc229694975493fd58977 commit r10-6633-ge235031d490e8ed2aa0bc229694975493fd58977 Author: Jakub Jelinek Date: Fri Feb 14 09:04:14 2020 +0100 c++: Partially implement P1042R1: __VA_OPT__ wording clarifications [PR92319] I've noticed we claim in cxx-status.html that we implement P1042R1, but it seems we don't implement any of the changes from there. The following patch implements just the change that __VA_OPT__ determines whether to expand to nothing or the enclosed tokens no longer based on whether there were any tokens passed to __VA_ARGS__, but whether __VA_ARGS__ expands to any tokens (from testing apparently it has to be non-CPP_PADDING tokens). I'm afraid I'm completely lost about the padding preservation/removal changes that are also in the paper, so haven't touched that part. 2020-02-14 Jakub Jelinek Partially implement P1042R1: __VA_OPT__ wording clarifications PR preprocessor/92319 * macro.c (expand_arg): Move declarations before vaopt_state definition. (class vaopt_state): Move enum update_type definition earlier. Remove m_allowed member, add m_arg and m_update members. (vaopt_state::vaopt_state): Change last argument from bool any_args to macro_arg *arg, initialize m_arg and m_update instead of m_allowed. (vaopt_state::update): When bumping m_state from 1 to 2 and m_update is ERROR, determine if __VA_ARGS__ expansion has any non-CPP_PADDING tokens and set m_update to INCLUDE if it has any, DROP otherwise. Return m_update instead of m_allowed ? INCLUDE : DROP in m_state >= 2. (replace_args, create_iso_definition): Adjust last argument to vaopt_state ctor. * c-c++-common/cpp/va-opt-4.c: New test.
[Bug tree-optimization/92203] [9 Regression] ICE in eliminate_stmt, at tree-ssa-sccvn.c:5492
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92203 Richard Biener changed: What|Removed |Added Known to work||9.2.1 --- Comment #4 from Richard Biener --- Even though latent the testcase doesn't actually fail on the branch.
[Bug target/93724] macro of _mm512_shrdi_epi16 lack a closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93724 --- Comment #2 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:cf1db5c9a342352d66164fea8c4ea0a540627024 commit r10-6634-gcf1db5c9a342352d66164fea8c4ea0a540627024 Author: liuhongt Date: Wed Feb 12 18:04:42 2020 +0800 Intrinsic macro of vpshr* and vpshl* lack a closing parenthesis which would cause failure in O0. 2020-02-14 Hongtao Liu gcc/ PR target/93724 * config/i386/avx512vbmi2intrin.h (_mm512_shrdi_epi16, _mm512_mask_shrdi_epi16, _mm512_maskz_shrdi_epi16, _mm512_shrdi_epi32, _mm512_mask_shrdi_epi32, _mm512_maskz_shrdi_epi32, _m512_shrdi_epi64, _m512_mask_shrdi_epi64, _m512_maskz_shrdi_epi64, _mm512_shldi_epi16, _mm512_mask_shldi_epi16, _mm512_maskz_shldi_epi16, _mm512_shldi_epi32, _mm512_mask_shldi_epi32, _mm512_maskz_shldi_epi32, _mm512_shldi_epi64, _mm512_mask_shldi_epi64, _mm512_maskz_shldi_epi64): Fix typo of lacking a closing parenthesis. * config/i386/avx512vbmi2vlintrin.h (_mm256_shrdi_epi16, _mm256_mask_shrdi_epi16, _mm256_maskz_shrdi_epi16, _mm256_shrdi_epi32, _mm256_mask_shrdi_epi32, _mm256_maskz_shrdi_epi32, _m256_shrdi_epi64, _m256_mask_shrdi_epi64, _m256_maskz_shrdi_epi64, _mm256_shldi_epi16, _mm256_mask_shldi_epi16, _mm256_maskz_shldi_epi16, _mm256_shldi_epi32, _mm256_mask_shldi_epi32, _mm256_maskz_shldi_epi32, _mm256_shldi_epi64, _mm256_mask_shldi_epi64, _mm256_maskz_shldi_epi64, _mm_shrdi_epi16, _mm_mask_shrdi_epi16, _mm_maskz_shrdi_epi16, _mm_shrdi_epi32, _mm_mask_shrdi_epi32, _mm_maskz_shrdi_epi32, _mm_shrdi_epi64, _mm_mask_shrdi_epi64, _m_maskz_shrdi_epi64, _mm_shldi_epi16, _mm_mask_shldi_epi16, _mm_maskz_shldi_epi16, _mm_shldi_epi32, _mm_mask_shldi_epi32, _mm_maskz_shldi_epi32, _mm_shldi_epi64, _mm_mask_shldi_epi64, _mm_maskz_shldi_epi64): Ditto. gcc/testsuite/ * gcc.target/i386/avx512vbmi2-vpshld-1.c: New test. * gcc.target/i386/avx512vbmi2-vpshrd-1.c: Ditto. * gcc.target/i386/sse-12.c: Add -mavx512vbmi2. * gcc.target/i386/sse-13.c: Ditto. * gcc.target/i386/sse-14.c: Add -mavx512vbmi2 and tests. * gcc.target/i386/sse-22.c: Ditto.
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #8)
> Some typos:
> (simplify
> (rshift @0 (mod @1 integer_pow2p@2))
> (rshift @0 (bit_and @1 (minus @2 { build_int_cst (TREE_TYPE (@2), 1); }
>
> This would be under the for:
> (for mod (ceil_mod floor_mod round_mod trunc_mod)
It should be also
(for shift (lshift rshift)
and use shift instead of rshift, because it applies to left shifts equally.
Maube for rotates too, dunno if we consider the negative or out of bounds
amounts UB or not for those, I bet they could be matched from expressions where
it would be UB or where it wouldn't. Certainly if the @2 is the precision of
the rotated value, it would be ok anyway (even if we don't consider int32 r>>
-1 UB, it will still be the same thing as int32 r>> 31 (-1 & 31).
[Bug target/93724] macro of _mm512_shrdi_epi16 lack a closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93724 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Thanks. Please make sure to backport it soon, we want to release GCC 8.4 and 9.3 soon.
[Bug preprocessor/92319] Macro expansion using the __VA_OPT__ construct is incorrect when the variadic argument expands to nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92319 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed on the trunk.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.2.0 Resolution|--- |FIXED --- Comment #71 from Richard Biener --- I think this was fixed with the introduction of contrib/compare-lto for GCC 9 (PR85571).
[Bug c++/93739] New: Ability to print a type name without aborting compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93739
Bug ID: 93739
Summary: Ability to print a type name without aborting
compilation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Over the past several years, C++ has seen increased use of type deduction via
auto variables (C++11), auto return type (C++14), template deduction guides and
more. The language already had delicate rules regarding decays, references
being added or removed, etc. All of these motivates the developer to sometimes
want to ascertain what the type of an expression or the value of a template
parameter is, in their program, while it is being compiled - with the
information printed to the standard error stream like warnings and errors are.
(And nota bene: Not at run-time).
This is partly doable today already, e.g. with the kludge in the following
example:
using mystery = int;
// ... etc etc
template struct has_type{};
using foo = typename has_type::mystery;
this results in an error whose first line is:
:6:59: error: 'mystery' in 'struct has_type' does not name a type
and tells us the type of mystery is int. This has several drawbacks:
* Abuse of a mechanism with a different intent (although in C++ that is
sometimes considered a good idea...)
* Irrelevant clutter in the output - you need to pay attention and know what
you're looking for.
* [MOST IMPORTANT] Compilation stops when hitting this type check.
(consequences of the above)
* Can't check more than one type at a time this way.
* Can't be used in compilation log parsing - must be introduced and then
removed.
* Effectively unusable if the same expression has a different type when called
from different locations - i.e. within templates: Compilation will stop with
the first instantiation, not the one you want (and preventing this stoppage is
overkill).
I therefore ask that a feature be added to GCC, of allowing the printing of a
type's name at some appropriate point during compilation. I'm not familiar with
the various passes and stages of parsing and comprehending C++ programs in GCC,
but obviously the type is deduced at some point - the same point where the
error in the above example can be printed. Instead, I suggest for some pragma
(new or existing one) to be able to print type names.
Syntax ideas (a bike-shed issue of course):
#pragma print_type_of( mystery )
#pragma message( typeof(mystery) )
[Bug target/89114] rtx_cost of VEC_SELECT, VEC_CONCAT and VEC_DUPLICATE with memory operands is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89114 --- Comment #2 from Richard Biener --- Honza?
[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93169 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- > It is caused by > commit 88bbd5a94e06eb42a5ed84a3ff6da498bea229e9 (HEAD, refs/bisect/bad) r274671, or r10-2655-g04e1749c557a5df14f8528efa451bb0e93afea80 in the new git. The problem is that TREE_READONLY (e) = true; ends up setting the flag on the variable 'f' because its initialization is not actually constant. Protecting that by checking one or both of *non_constant_p and TREE_CODE (e) should fix the issue. What do you think, Marek?
[Bug target/93724] macro of _mm512_shrdi_epi16 lack a closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93724 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:d7ab361df604fb66e1ba1e3fb45b4453cba803c4 commit r9-8229-gd7ab361df604fb66e1ba1e3fb45b4453cba803c4 Author: liuhongt Date: Fri Feb 14 16:32:49 2020 +0800 Intrinsic macro of vpshr* and vpshl* lack a closing parenthesis which would cause failure in O0. 2020-02-14 Hongtao Liu gcc/ PR target/93724 * config/i386/avx512vbmi2intrin.h (_mm512_shrdi_epi16, _mm512_mask_shrdi_epi16, _mm512_maskz_shrdi_epi16, _mm512_shrdi_epi32, _mm512_mask_shrdi_epi32, _mm512_maskz_shrdi_epi32, _m512_shrdi_epi64, _m512_mask_shrdi_epi64, _m512_maskz_shrdi_epi64, _mm512_shldi_epi16, _mm512_mask_shldi_epi16, _mm512_maskz_shldi_epi16, _mm512_shldi_epi32, _mm512_mask_shldi_epi32, _mm512_maskz_shldi_epi32, _mm512_shldi_epi64, _mm512_mask_shldi_epi64, _mm512_maskz_shldi_epi64): Fix typo of lacking a closing parenthesis. * config/i386/avx512vbmi2vlintrin.h (_mm256_shrdi_epi16, _mm256_mask_shrdi_epi16, _mm256_maskz_shrdi_epi16, _mm256_shrdi_epi32, _mm256_mask_shrdi_epi32, _mm256_maskz_shrdi_epi32, _m256_shrdi_epi64, _m256_mask_shrdi_epi64, _m256_maskz_shrdi_epi64, _mm256_shldi_epi16, _mm256_mask_shldi_epi16, _mm256_maskz_shldi_epi16, _mm256_shldi_epi32, _mm256_mask_shldi_epi32, _mm256_maskz_shldi_epi32, _mm256_shldi_epi64, _mm256_mask_shldi_epi64, _mm256_maskz_shldi_epi64, _mm_shrdi_epi16, _mm_mask_shrdi_epi16, _mm_maskz_shrdi_epi16, _mm_shrdi_epi32, _mm_mask_shrdi_epi32, _mm_maskz_shrdi_epi32, _mm_shrdi_epi64, _mm_mask_shrdi_epi64, _m_maskz_shrdi_epi64, _mm_shldi_epi16, _mm_mask_shldi_epi16, _mm_maskz_shldi_epi16, _mm_shldi_epi32, _mm_mask_shldi_epi32, _mm_maskz_shldi_epi32, _mm_shldi_epi64, _mm_mask_shldi_epi64, _mm_maskz_shldi_epi64): Ditto. gcc/testsuite/ * gcc.target/i386/avx512vbmi2-vpshld-1.c: New test. * gcc.target/i386/avx512vbmi2-vpshrd-1.c: Ditto. * gcc.target/i386/sse-12.c: Add -mavx512vbmi2. * gcc.target/i386/sse-13.c: Ditto. * gcc.target/i386/sse-14.c: Add -mavx512vbmi2 and tests. * gcc.target/i386/sse-22.c: Ditto.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #12 from Richard Biener --- I have a patch.
[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #34 from Richard Biener --- This PR is a mess now... there were many enhancements to store-merging and remaining opportunities should be tracked one [qualitatively distict] from each other in separate PRs. Closing this one as fixed.
[Bug target/93724] macro of _mm512_shrdi_epi16 lack a closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93724 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e6a329e42d127a0e6094250ace5ea147d3cc9550 commit r8-9979-ge6a329e42d127a0e6094250ace5ea147d3cc9550 Author: liuhongt Date: Fri Feb 14 16:32:49 2020 +0800 Intrinsic macro of vpshr* and vpshl* lack a closing parenthesis which would cause failure in O0. 2020-02-14 Hongtao Liu gcc/ PR target/93724 * config/i386/avx512vbmi2intrin.h (_mm512_shrdi_epi16, _mm512_mask_shrdi_epi16, _mm512_maskz_shrdi_epi16, _mm512_shrdi_epi32, _mm512_mask_shrdi_epi32, _mm512_maskz_shrdi_epi32, _m512_shrdi_epi64, _m512_mask_shrdi_epi64, _m512_maskz_shrdi_epi64, _mm512_shldi_epi16, _mm512_mask_shldi_epi16, _mm512_maskz_shldi_epi16, _mm512_shldi_epi32, _mm512_mask_shldi_epi32, _mm512_maskz_shldi_epi32, _mm512_shldi_epi64, _mm512_mask_shldi_epi64, _mm512_maskz_shldi_epi64): Fix typo of lacking a closing parenthesis. * config/i386/avx512vbmi2vlintrin.h (_mm256_shrdi_epi16, _mm256_mask_shrdi_epi16, _mm256_maskz_shrdi_epi16, _mm256_shrdi_epi32, _mm256_mask_shrdi_epi32, _mm256_maskz_shrdi_epi32, _m256_shrdi_epi64, _m256_mask_shrdi_epi64, _m256_maskz_shrdi_epi64, _mm256_shldi_epi16, _mm256_mask_shldi_epi16, _mm256_maskz_shldi_epi16, _mm256_shldi_epi32, _mm256_mask_shldi_epi32, _mm256_maskz_shldi_epi32, _mm256_shldi_epi64, _mm256_mask_shldi_epi64, _mm256_maskz_shldi_epi64, _mm_shrdi_epi16, _mm_mask_shrdi_epi16, _mm_maskz_shrdi_epi16, _mm_shrdi_epi32, _mm_mask_shrdi_epi32, _mm_maskz_shrdi_epi32, _mm_shrdi_epi64, _mm_mask_shrdi_epi64, _m_maskz_shrdi_epi64, _mm_shldi_epi16, _mm_mask_shldi_epi16, _mm_maskz_shldi_epi16, _mm_shldi_epi32, _mm_mask_shldi_epi32, _mm_maskz_shldi_epi32, _mm_shldi_epi64, _mm_mask_shldi_epi64, _mm_maskz_shldi_epi64): Ditto. gcc/testsuite/ * gcc.target/i386/avx512vbmi2-vpshld-1.c: New test. * gcc.target/i386/avx512vbmi2-vpshrd-1.c: Ditto. * gcc.target/i386/sse-12.c: Add -mavx512vbmi2. * gcc.target/i386/sse-13.c: Ditto. * gcc.target/i386/sse-14.c: Add -mavx512vbmi2 and tests. * gcc.target/i386/sse-22.c: Ditto.
[Bug target/93724] macro of _mm512_shrdi_epi16 lack a closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93724 Hongtao.liu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Hongtao.liu --- Fixed in GCC10, back port to GCC9 and GCC8.
[Bug middle-end/80533] Alias analysis of zero length array does not recognize accesses beyond end of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80533 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||7.5.0 --- Comment #4 from Richard Biener --- Fixed on all still maintained branches.
[Bug c++/90764] [10 Regression] internal compiler error in build_deduction_guide, at cp/pt.c:27162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90764 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed by r273623.
[Bug tree-optimization/80702] FRE fails to eliminate to leader dominating after unreachable edge removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80702 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Richard Biener --- Re-confirmed at -O2. The -O1 greedy mode get's this correct (it eliminates on-the-fly): : _1 = a_5(D) + b_6(D); c = _1; _3 = a_5(D) * 2; c = _3; return _3; re-writing the -O2/PRE elimination RPO style with RPO availability is possible (but the avail tracking is a bit more expensive).
[Bug c++/93739] Ability to print a type name without aborting compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93739
--- Comment #1 from Jonathan Wakely ---
template
[[gnu::warning("your type here")]]
bool print_type() { return true; }
int i;
bool b = print_type();
[Bug c++/90546] [9/10 Regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 Jason Merrill changed: What|Removed |Added CC||gufideg at gmail dot com --- Comment #10 from Jason Merrill --- *** Bug 91051 has been marked as a duplicate of this bug. ***
[Bug c++/91051] [9/10 Regression] Templated conversion operator to rvalue reference to constant don't match when converting to lvalue reference to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91051 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jason Merrill --- Fixed. *** This bug has been marked as a duplicate of bug 90546 ***
[Bug lto/92674] [8/9 Regression] ICE in gimple_phi_arg, at gimple.h:4406 since r240291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92674 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Guenther : https://gcc.gnu.org/g:c6480e01fc53f0e9822ec1694239155756430952 commit r9-8230-gc6480e01fc53f0e9822ec1694239155756430952 Author: Richard Biener Date: Fri Feb 14 09:10:48 2020 +0100 middle-end/92674 delay purging EH edges when folding during inlining 2020-02-14 Richard Biener Backport from mainline 2019-11-27 Richard Biener PR middle-end/92674 * tree-inline.c (expand_call_inline): Delay purging EH/abnormal edges and instead record blocks in bitmap. (gimple_expand_calls_inline): Adjust. (fold_marked_statements): Delay EH cleanup until all folding is done. (optimize_inline_calls): Do EH/abnormal cleanup for calls after inlining finished.
[Bug tree-optimization/92704] [8/9 Regression] ICE: Segmentation fault (in process_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92704 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Guenther : https://gcc.gnu.org/g:4230afc0f4f498cc3967bde173c84dde66519711 commit r9-8231-g4230afc0f4f498cc3967bde173c84dde66519711 Author: Richard Biener Date: Fri Feb 14 09:14:42 2020 +0100 tree-optimization/92704 fix ifcvt ICE with loops without stores 2020-02-14 Richard Biener Backport from mainline 2019-11-29 Richard Biener PR tree-optimization/92704 * tree-if-conv.c (combine_blocks): Deal with virtual PHIs in loops performing only loads. * gcc.dg/torture/pr92704.c: New testcase.
[Bug tree-optimization/93439] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Guenther : https://gcc.gnu.org/g:03d2b1d79740c5b2d05bbf84af2dbaf2e1e80ebb commit r9-8234-g03d2b1d79740c5b2d05bbf84af2dbaf2e1e80ebb Author: Richard Biener Date: Fri Feb 14 09:23:06 2020 +0100 tree-optimization/93439 move clique bookkeeping to OMP expansion Autopar was doing clique bookkeeping too early when creating destination functions but then later introducing new cliques via versioning loops. The following moves the bookkeeping to the actual outlining process. 2020-02-14 Richard Biener Backport from mainline 2020-01-28 Richard Biener PR tree-optimization/93439 * tree-parloops.c (create_loop_fn): Move clique bookkeeping... * tree-cfg.c (move_sese_region_to_fn): ... here. (verify_types_in_gimple_reference): Verify used cliques are tracked. * gfortran.dg/graphite/pr93439.f90: New testcase.
[Bug tree-optimization/93054] [8/9 Regression] ICE in gimple_set_lhs, at gimple.c:1820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Guenther : https://gcc.gnu.org/g:3bcda566d6f485f6eccdc029d115f4246016ba05 commit r9-8233-g3bcda566d6f485f6eccdc029d115f4246016ba05 Author: Richard Biener Date: Fri Feb 14 09:19:40 2020 +0100 middle-end/93054 deal with undefs in call gimplification 2020-02-14 Richard Biener Backport from mainline 2020-01-09 Richard Biener PR middle-end/93054 * gimplify.c (gimplify_expr): Deal with NOP definitions. * gcc.dg/pr93054.c: New testcase.
[Bug c++/92556] [10 Regression] ICE if using dependent name inside lambda expression in simple-requirement since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92556 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug debug/92763] [8/9 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:22659, or in force_type_die, at dwarf2out.c:26224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92763 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Guenther : https://gcc.gnu.org/g:794bb8c2f5d328d9d4cfa55efd41cdd420ebb13a commit r9-8232-g794bb8c2f5d328d9d4cfa55efd41cdd420ebb13a Author: Richard Biener Date: Fri Feb 14 09:17:57 2020 +0100 debug/92763 keep DIEs that might be used in DW_TAG_inlined_subroutine We were pruning type-local subroutine DIEs if their context is unused despite us later needing those DIEs as abstract origins for inlines. The patch makes code already present for -fvar-tracking-assignments unconditional. 2020-02-14 Richard Biener Backport from mainline 2020-01-20 Richard Biener PR debug/92763 * dwarf2out.c (prune_unused_types): Unconditionally mark called function DIEs. * g++.dg/debug/pr92763.C: New testcase.
[Bug tree-optimization/93439] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.2.1 Resolution|--- |FIXED Known to fail||9.2.0 --- Comment #11 from Richard Biener --- Fixed.
[Bug target/93583] [10 Regression] bootstrap failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93583 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-14 CC||bernds at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I can confirm that.
[Bug target/93583] [10 Regression] bootstrap failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93583 --- Comment #3 from Richard Biener --- Confirmed (c940105cc17111be98d8d42ba48a413b0e63aebe), with ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go --disable-werror --with-gxx-include-dir=/usr/include/c++/10 --enable-ssp --disable-libssp --disable-libvtv --disable-cet --disable-libcc1 --enable-plugin --with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-10 --without-system-libunwind --with-cpu=power8 --with-tune=power9 --enable-secureplt --with-long-double-128 --enable-targets=powerpcle-linux --disable-multilib --with-build-config=bootstrap-lto-lean --enable-link-mutex --build=powerpc64le-suse-linux --host=powerpc64le-suse-linux and make profiledbootstrap in stagefeedback. So profiledbootstrap is maybe not needed to reproduce.
[Bug target/93583] [10 Regression] bootstrap failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93583 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/93246] [8 Regression] Unexpected program behavior when -fsanitize=address and -O2/O3 used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93246 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1 Resolution|--- |FIXED Known to fail||8.3.0 --- Comment #16 from Richard Biener --- Fixed. --- Comment #17 from CVS Commits --- The releases/gcc-8 branch has been updated by Richard Guenther : https://gcc.gnu.org/g:1b169f1ea0c9fab7712ede65edb0ffb6e021ad7c commit r8-9980-g1b169f1ea0c9fab7712ede65edb0ffb6e021ad7c Author: Richard Biener Date: Tue Jan 14 08:43:32 2020 +0100 PR middle-end/93246 - missing alias subsets Starting with the introduction of TYPE_TYPELESS_STORAGE the situation of having a alias-set zero aggregate field became more common which prevents recording alias-sets of fields of said aggregate as subset of the outer aggregate. component_uses_parent_alias_set_from in the past fended off some of the issues with that but the alias oracles use of the alias set of the base of an access path never appropriately handled it. The following makes it so that alias-sets of fields of alias-set zero aggregate fields are still recorded as subset of the container. 2020-01-14 Richard Biener PR middle-end/93246 * alias.c (record_component_aliases): Take superset to record into, recurse for alias-set zero fields. (record_component_aliases): New oveerload wrapping around the above. * g++.dg/torture/pr93246.C: New testcase.
[Bug middle-end/93246] [8 Regression] Unexpected program behavior when -fsanitize=address and -O2/O3 used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93246 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1 Resolution|--- |FIXED Known to fail||8.3.0 --- Comment #16 from Richard Biener --- Fixed.
[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Iain Sandoe --- > These systems are EOL so we can't expect any fixes to the systems themselves. > > The question is "is the latest imported as an version even supposed to support > 10.7"? When I tried to build all of LLVM before the 9.0 release and ran into a couple of issues, I asked the same question. Getting an answer was like pulling teeth, unfortunately, and in the end no one was able or willing to state which macOS version are supposed to be supported by LLVM. Very disappointing IMO, but given this precedent I don't expect anything better now. > I agree that spending much time on making the sanitisers work on EOL machines > is not a priority. I don't have access to my 10.7 box right now - but will > take a look next week. I'm only building mainline on 10.7 because we happen to have a couple of old Mac minis running 10.7 still around that I can use for the purpose. Given the nightmarish slowdowns since 10.13, that is still a decent option. That said, when experimenting with bootstraps inside VirtualBox VMs, I had also tried 10.11 where unlike 10.7 I could run with 4 virtual cpus, getting reasonable build times.
[Bug c++/93739] Ability to print a type name without aborting compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93739
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> template
> [[gnu::warning("your type here")]]
> bool print_type() { return true; }
>
> int i;
> bool b = print_type();
Oops, that was meant to be print_type()
The output is:
warn.cc: In function ‘void __static_initialization_and_destruction_0(int,
int)’:
warn.cc:6:33: warning: call to ‘print_type’ declared with attribute
warning: your type here [-Wattribute-warning]
6 | bool b = print_type();
| ~~~^~
[Bug tree-optimization/89182] [8 Regression] [graphite] ICE in extract_affine, at graphite-sese-to-poly.c:280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182 Richard Biener changed: What|Removed |Added Priority|P2 |P4
[Bug c++/93739] Ability to print a type name without aborting compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93739 --- Comment #3 from Eyal Rozenberg --- (In reply to Jonathan Wakely from comment #2) > Oops, that was meant to be print_type() Ok, that's a better kludge than mine - it doesn't have the more serious shortcomings. That makes the motivation for this feature request more about convenience / aesthetics. It would still be nice to have.
[Bug libgomp/93219] unused return value in affinity-fmt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c++/93557] __builtin_convertvector doesn't mark input as used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93557 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/93739] Ability to print a type name without aborting compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93739 --- Comment #4 from Eyal Rozenberg --- (In reply to Eyal Rozenberg from comment #3) A couple more points: * The error I get (https://godbolt.org/z/5GpR2T) doesn't have the "your type here" string. * This forces you to define a variable you're not using. So, you need to also say [[unused]] in some cases - more clutter.
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 --- Comment #6 from Martin Jambor --- I proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00850.html
[Bug c++/93740] New: Template base classes parametrized by pointer-to-member are amibiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
Bug ID: 93740
Summary: Template base classes parametrized by
pointer-to-member are amibiguous
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code does not compile on any gcc version regardless of chosen C++
standard version, but compiles correctly on clang, msvc and icc.
struct A
{
virtual void foo() = 0;
virtual void bar() = 0;
};
template
struct const_val{};
template
struct indexed_elem{};
using mem_fun_A_foo = const_val;
using mem_fun_A_bar = const_val;
struct A_indexed_member_funcs
: indexed_elem<0, mem_fun_A_foo>,
indexed_elem<1, mem_fun_A_bar>
{};
template
constexpr int index_of(indexed_elem)
{
return N;
}
void test()
{
static_assert(index_of(A_indexed_member_funcs{}) == 0, "");
}
[Bug fortran/93736] Add .f18 and .F18 file suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736 --- Comment #6 from Thomas Henlich --- Created attachment 47842 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47842&action=edit Proposed patch to add .f18/.F18 suffix Add .f18 and .F18 to list of recognized filename suffixes to match the most recent standard Fortran 2018
[Bug c++/93741] New: [10 regression] ICE in incomplete concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93741
Bug ID: 93741
Summary: [10 regression] ICE in incomplete concept definition
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following (very invalid) code fragment causes gcc-trunk to ICE:
template struct a { b({
concept c =
[Bug tree-optimization/93381] points-to wrong for integer offsetting and field-sensitive analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93381 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Guenther : https://gcc.gnu.org/g:b00c3228041bfb450e3fec21fe424f5f322f23b3 commit r9-8235-gb00c3228041bfb450e3fec21fe424f5f322f23b3 Author: Richard Biener Date: Wed Jan 22 12:38:12 2020 +0100 tree-optimization/93381 fix integer offsetting in points-to analysis We were incorrectly assuming a merge operation is conservative enough for not explicitely handled operations but we also need to consider offsetting within fields when field-sensitive analysis applies. 2020-01-22 Richard Biener PR tree-optimization/93381 * tree-ssa-structalias.c (find_func_aliases): Assume offsetting throughout, handle all conversions the same. * gcc.dg/torture/pr93381.c: New testcase.
[Bug middle-end/90648] [8 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Guenther : https://gcc.gnu.org/g:b8c42b4d0a2595fb6806473f816b94cc1b222cb1 commit r9-8236-gb8c42b4d0a2595fb6806473f816b94cc1b222cb1 Author: Richard Biener Date: Wed Feb 5 14:04:29 2020 +0100 middle-end/90648 fend off builtin calls with not enough arguments from match This adds guards to genmatch generated code before accessing call expression or stmt arguments that might be out of bounds when the user provided bogus prototypes for what we consider builtins. 2020-02-05 Richard Biener PR middle-end/90648 * genmatch.c (dt_node::gen_kids_1): Emit number of argument checks before matching calls. * gcc.dg/pr90648.c: New testcase.
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:515dd04260c6049110d7624eaf1b276929dcd9af commit r10-6636-g515dd04260c6049110d7624eaf1b276929dcd9af Author: Martin Jambor Date: Fri Feb 14 15:02:35 2020 +0100 sra: Avoid verification failure (PR 93516) get_ref_base_and_extent can return different sizes for COMPONENT_REFs and DECLs of the same type, with the latter including (more?) padding. When in the IL there is an assignment between such a COMPONENT_REF and a DECL, SRA will try to propagate the access from the former as a child of the latter, creating an artificial reference that does not match the access's declared size, which triggers a verifier assert. Fixed by teaching the propagation functions about this special situation so that they don't do it. The condition is the same that build_user_friendly_ref_for_offset uses so the artificial reference causing the verifier is guaranteed not to be created. 2020-02-14 Martin Jambor PR tree-optimization/93516 * tree-sra.c (propagate_subaccesses_from_rhs): Do not create access of the same type as the parent. (propagate_subaccesses_from_lhs): Likewise. gcc/testsuite/ * g++.dg/tree-ssa/pr93516.C: New test.
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 --- Comment #17 from CVS Commits --- The releases/gcc-9 branch has been updated by Alexander Monakov : https://gcc.gnu.org/g:0f7b7aeb71d06fc85f49c323fbd4879d5a02f336 commit r9-8237-g0f7b7aeb71d06fc85f49c323fbd4879d5a02f336 Author: Alexander Monakov Date: Fri Feb 14 16:51:21 2020 +0300 sel-sched: allow negative insn priority (PR 88879) PR rtl-optimization/88879 * sel-sched.c (sel_target_adjust_priority): Remove assert.
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Alexander Monakov --- Fixed.
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720
--- Comment #2 from Dmitrij Pochepko ---
I have a patch, which recognize such pattern and adds ins instructions. Example
in this issue description is compiled fine and produce this assembly:
:
0: 6e184420mov v0.d[1], v1.d[1]
4: d65f03c0ret
However, there are a little bit more complicated examples, where allocated
registers are preventing from optimal assembly to be generated.
(example: part of blender benchmark from speccpu)
#include
static inline float dot_v3v3(const float a[3], const float b[3])
{
return a[0] * b[0] + a[1] * b[1] + a[2] * b[2];
}
static inline float len_v3(const float a[3])
{
return sqrtf(dot_v3v3(a, a));
}
void window_translate_m4(float winmat[4][4], float perspmat[4][4], const float
x, const float y)
{
if (winmat[2][3] == -1.0f) {
/* in the case of a win-matrix, this means perspective always
*/
float v1[3];
float v2[3];
float len1, len2;
v1[0] = perspmat[0][0];
v1[1] = perspmat[1][0];
v1[2] = perspmat[2][0];
v2[0] = perspmat[0][1];
v2[1] = perspmat[1][1];
v2[2] = perspmat[2][1];
len1 = (1.0f / len_v3(v1));
len2 = (1.0f / len_v3(v2));
winmat[2][0] += len1 * winmat[0][0] * x;
winmat[2][1] += len2 * winmat[1][1] * y;
}
else {
winmat[3][0] += x;
winmat[3][1] += y;
}
}
This will produce:
...
24: fd400010ldr d16, [x0]
28: fd400807ldr d7, [x0,#16]
...
34: 6e040611mov v17.s[0], v16.s[0]
38: 6e0c24f1mov v17.s[1], v7.s[1]
...
# v16/d17 and d7/v7 are not used in any other places
while it can be:
...
24: fd400010ldr d16, [x0]
28: fd400807ldr d7, [x0,#16]
...
38: 6e0c24f1mov v16.s[1], v7.s[1]
...
# and v16 is used instead of v17.
It looks like peephole2 can be used to optimize it. I'm currently looking into
in.
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor --- Fixed.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #177 from dave.anglin at bell dot net --- On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote: > I have tried playing around with weak using aCC, however even though it > accepts > both attribute and pragma (and complains if you misspell "weak"), both > compiler > and linker seem to ignore it. But I might have made some mistake there, will > double check tonight. Did you look at .s output? You could also test a simple program with a weak function in two objects. My sense is the situation will be similar to hppa64-hpux11. Weak is partially supported in that calls to a weak function resolve to a single instance. However, undefined weak is not really supported. While the linker errors can be overridden, the dynamic linker will object to applications with undefined weak symbols. We worked around this with a libgcc_stub.a library and a linker script. HP ld also probably leaves all the instances of weak linkonce functions contributing to bloat.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #178 from dave.anglin at bell dot net --- On 2020-02-13 6:04 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #176 from Peter Bisroev --- > (In reply to dave.anglin from comment #174) >> On 2020-02-13 2:44 p.m., dave.anglin at bell dot net wrote: >>> The first thing to note is aCC doesn't use weak. Instead, it uses COMDAT >>> sections. Probably, HP ld does support >>> weak but it's unlikely there is support for linkonce sections. See defines >>> in >>> config/pa/som.h. There we implimented >>> one only support using the linker's COMDAT support. >> Is HAVE_COMDAT_GROUP defined in auto-host.h? > For both 4.9.4 and 8.3.0, gcc/auto-host.h contains only one reference to that: > > /* Define 0/1 if your assembler and linker support COMDAT groups. */ > #ifndef USED_FOR_TARGET > #define HAVE_COMDAT_GROUP 0 > #endif > The configure test didn't find support for COMDAT groups even though aCC and HP ld support them. So, there's likely something incompatible with the default support for COMDAT groups. Could you look at configure test and see why it fails?
[Bug target/45414] _mm_prefetch parameter is "char const *" in ICC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45414 Matthias Kretz (Vir) changed: What|Removed |Added Keywords||rejects-valid --- Comment #2 from Matthias Kretz (Vir) --- New information: starting with ICC 19.0, ICC accepts `const void*` arguments to _mm_prefetch. (MSVC still expects `const char*`) The signature Intel documents is `_mm_prefetch(char const*, int)`: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_prefetch&expand=4391 Using the type-safe _mm_hint enum for the second _mm_prefetch argument in GCC still leads to source incompatibility with ICC: https://godbolt.org/z/Pu6CDB I'd rather close this PR as WONTFIX than keeping it in limbo forever. ;-)
[Bug middle-end/93742] New: Optimization request: pattern-match typical addition overflow checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93742
Bug ID: 93742
Summary: Optimization request: pattern-match typical addition
overflow checks
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
It would be nice if GCC could pattern-match the typical pattern for
overflow-safe addition and optimize it to just branch on the overflow flag.
Right now, this:
_Bool add_overflow(int a, int b, int *res) {
if ((a > 0 && b > INT_MAX - a) || (a < 0 && b < INT_MIN - a)) {
return 1;
} else {
*res = a + b;
return 0;
}
}
compiles to this:
testl %edi, %edi
jle .L2
movl$2147483647, %ecx
movl$1, %eax
subl%edi, %ecx
cmpl%esi, %ecx
jl .L12
.L4:
addl%esi, %edi
xorl%eax, %eax
movl%edi, (%rdx)
ret
.L12:
ret
.L2:
je .L4
movl$-2147483648, %ecx
movl$1, %eax
subl%edi, %ecx
cmpl%esi, %ecx
jle .L4
ret
#48580 is similar but about multiplication, for which the overflow-safe pattern
is a lot more complicated. But the addition one above is a lot simpler and
pretty widespread I think. For example, it's what CERT recommends:
https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:54d87ffe4b34052f159ac5b72b250129ce813b2a commit r8-9981-g54d87ffe4b34052f159ac5b72b250129ce813b2a Author: Jakub Jelinek Date: Fri Feb 14 12:33:27 2020 +0100 backport: re PR sanitizer/92154 (new glibc breaks arm bootstrap due to libsanitizer) Backported from mainline 2019-10-22 Tamar Christina PR sanitizer/92154 * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry-pick compiler-rt revision r375220.
[Bug inline-asm/92615] [8 Regression] ICE in extract_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92615 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ef7d101ee0eb663c078cfc018db164387e97cc02 commit r8-9983-gef7d101ee0eb663c078cfc018db164387e97cc02 Author: Jakub Jelinek Date: Fri Feb 14 12:37:40 2020 +0100 backport: re PR inline-asm/92615 (ICE in extract_insn) Backported from mainline 2019-11-23 Jakub Jelinek PR target/92615 * config/i386/i386.c (ix86_md_asm_adjust): If dest_mode is GET_MODE (dest), is not QImode, using ZERO_EXTEND and dest is not register_operand, force x into register before storing it into dest. Formatting fix. * gcc.target/i386/pr92615.c: New test.
[Bug c++/90842] [8 Regression] ICE in poplevel, at cp/decl.c:585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90842 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:56728b264c1b0d9f193aa5e8b1702a1cd7a08868 commit r8-9982-g56728b264c1b0d9f193aa5e8b1702a1cd7a08868 Author: Jakub Jelinek Date: Fri Feb 14 12:34:46 2020 +0100 backport: re PR c++/90842 (ICE in poplevel, at cp/decl.c:585) Backported from mainline 2019-11-21 Jakub Jelinek Jason Merrill PR c++/90842 * parser.c (cp_parser_decl_specifier_seq): For concept or typedef break early if CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR. For type specifiers, set CP_PARSER_FLAGS_NO_TYPE_DEFINITIONS if CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR is set. * g++.dg/cpp1y/lambda-generic-90842.C: New test.
[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dbdf86838aaaef76620c00c53096cfe157d5af6e commit r8-9984-gdbdf86838aaaef76620c00c53096cfe157d5af6e Author: Jakub Jelinek Date: Fri Feb 14 12:38:30 2020 +0100 backport: re PR sanitizer/92154 (new glibc breaks arm bootstrap due to libsanitizer) Backported from mainline 2019-11-26 Jakub Jelinek PR sanitizer/92154 * sanitizer_common/sanitizer_platform_limits_posix.h: Cherry-pick llvm-project revision 947f9692440836dcb8d88b74b69dd379d85974ce. * sanitizer_common/sanitizer_platform_limits_posix.cc: Likewise.
[Bug fortran/91944] [8 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91944 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bf5e3130c0ed518311a79c5a0099e0e39f33a889 commit r8-9989-gbf5e3130c0ed518311a79c5a0099e0e39f33a889 Author: Jakub Jelinek Date: Fri Feb 14 12:53:12 2020 +0100 backport: re PR fortran/91944 (ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6156) Backported from mainline 2019-11-27 Jakub Jelinek PR fortran/91944 * simplify.c (gfc_simplify_spread): Check gfc_init_expr_flag instead of gfc_current_ns->sym_root->n.sym->attr.flavor == FL_PARAMETER. * gfortran.dg/spread_size_limit_2.f90: New test.
[Bug c++/92648] Handling of unknown attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92648 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:37c0297f864394ddceba143ad410a6eb44a3119e commit r8-9986-g37c0297f864394ddceba143ad410a6eb44a3119e Author: Jakub Jelinek Date: Fri Feb 14 12:48:05 2020 +0100 backport: re PR c++/92648 (Handling of unknown attributes) Backported from mainline 2019-11-26 Jakub Jelinek PR c++/92648 * parser.c (cp_parser_std_attribute): For unknown attributes, skip balanced token seq instead of trying to parse attribute-argument-clause as expression list. * g++.dg/cpp0x/gen-attrs-71.C: New test.
[Bug debug/92664] Wrong .debug_line section information when compiling stdin input with -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92664 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5c265f5f1977f7c935b8b54cfdb23c862f686f20 commit r8-9987-g5c265f5f1977f7c935b8b54cfdb23c862f686f20 Author: Jakub Jelinek Date: Fri Feb 14 12:49:07 2020 +0100 backport: re PR debug/92664 (Wrong .debug_line section information when compiling stdin input with -g3) Backported from mainline 2019-11-27 Jakub Jelinek PR debug/92664 * dwarf2out.c (lookup_filename): Use "" instead of "".
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 --- Comment #25 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:22a7fa8517063c76b069d2b08dca5a9d270798f8 commit r8-9985-g22a7fa8517063c76b069d2b08dca5a9d270798f8 Author: Jakub Jelinek Date: Fri Feb 14 12:45:30 2020 +0100 backport: re PR c++/61414 (enum class bitfield size-checking needs a separate warning flag controlling it) Backported from mainline 2019-11-26 Jakub Jelinek PR c++/61414 * c-attribs.c (handle_mode_attribute): Add mode attribute to ENUMERAL_TYPEs. * class.c (enum_to_min_precision): New hash_map. (enum_min_precision): New function. (check_bitfield_decl): Use it. * g++.dg/cpp0x/enum23.C: Remove xfail. * g++.dg/cpp0x/enum28.C: New test.
[Bug c++/92524] [9 Regression] ICE in short program with constexpr and std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92524 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:929d901ead4f859c8e385d91547482445a85066c commit r8-9988-g929d901ead4f859c8e385d91547482445a85066c Author: Jakub Jelinek Date: Fri Feb 14 12:51:28 2020 +0100 backport: re PR c++/92524 (ICE in short program with constexpr and std::array) Backported from mainline 2019-11-27 Jakub Jelinek PR c++/92524 * tree.c (replace_placeholders_r): Don't walk constructor elts with RANGE_EXPR indexes. * g++.dg/cpp0x/pr92524.C: New test.
[Bug c++/60228] ICE using lambda in #pragma omp declare reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60228 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1aafdd7c93226cb092b560462028394a82f404a2 commit r8-9990-g1aafdd7c93226cb092b560462028394a82f404a2 Author: Jakub Jelinek Date: Fri Feb 14 12:56:42 2020 +0100 backport: re PR c++/60228 (ICE using lambda in #pragma omp declare reduction) Backported from mainline 2019-11-29 Jakub Jelinek PR c++/60228 * parser.c (cp_parser_omp_declare_reduction_exprs): If processing_template_decl, wrap the combiner or initializer into EXPR_STMT. * decl.c (start_preparsed_function): Don't start a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions. (finish_function): Don't finish a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions, nor cp_fold_function them nor cp_genericize them. * mangle.c (decl_mangling_context): Look through DECL_OMP_DECLARE_REDUCTION_P functions. * semantics.c (expand_or_defer_fn_1): For DECL_OMP_DECLARE_REDUCTION_P functions, use tentative linkage, don't keep their bodies with -fkeep-inline-functions and return false at the end. * g++.dg/gomp/openmp-simd-2.C: Don't expect bodies for DECL_OMP_DECLARE_REDUCTION_P functions. * testsuite/libgomp.c++/udr-20.C: New test. * testsuite/libgomp.c++/udr-21.C: New test.
[Bug fortran/92899] [8 Regression] [OpenMP] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92899 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f9a0c0800994d5e0b68c0a8eed47454bce841f97 commit r8-9994-gf9a0c0800994d5e0b68c0a8eed47454bce841f97 Author: Jakub Jelinek Date: Fri Feb 14 15:23:34 2020 +0100 backport: re PR fortran/92899 ([OpenMP] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3769) Backported from mainline 2019-12-11 Jakub Jelinek PR fortran/92899 * trans-openmp.c (gfc_trans_omp_atomic): For GFC_OMP_ATOMIC_SWAP, do look through conversion on expr2 if any. * testsuite/libgomp.fortran/atomic1.f90: New test.
[Bug c++/92732] Bit-field of scoped enumeration type cannot be initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92732 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:41e5eec55cb64b54c717d9625bcee1aac1def569 commit r8-9991-g41e5eec55cb64b54c717d9625bcee1aac1def569 Author: Jakub Jelinek Date: Fri Feb 14 12:58:46 2020 +0100 backport: re PR c++/92732 (Bit-field of scoped enumeration type cannot be initialized) Backported from mainline 2019-12-03 Jakub Jelinek PR c++/92732 * typeck2.c (digest_nsdmi_init): For bitfields, use DECL_BIT_FIELD_TYPE instead of TREE_TYPE. * g++.dg/cpp2a/bitfield3.C: Don't expect narrowing conversion warnings. * g++.dg/cpp2a/bitfield4.C: New test.
[Bug fortran/92781] ICE in convert_nonlocal_reference_op, at tree-nested.c:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92781 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:37e948410c67d1e4a0bb5bd3721b9fbf4d77f889 commit r8-9992-g37e948410c67d1e4a0bb5bd3721b9fbf4d77f889 Author: Jakub Jelinek Date: Fri Feb 14 12:59:53 2020 +0100 backport: re PR fortran/92781 (ICE in convert_nonlocal_reference_op, at tree-nested.c:1065) Backported from mainline 2019-12-05 Jakub Jelinek PR fortran/92781 * trans-decl.c (gfc_get_symbol_decl): If sym->backend_decl is current_function_decl, add length to current rather than parent function and expect DECL_CONTEXT (length) to be current_function_decl. * gfortran.dg/pr92781.f90: New test.
[Bug target/92904] varargs for __int128 is placed at an unaligned location and uses movdqa for the load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92904 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ffb5cc9a5599b1936c5ebea153ca52a0aa2c785d commit r8-9995-gffb5cc9a5599b1936c5ebea153ca52a0aa2c785d Author: Jakub Jelinek Date: Fri Feb 14 15:24:48 2020 +0100 backport: re PR target/92904 (varargs for __int128 is placed at an unaligned location and uses movdqa for the load) Backported from mainline 2019-12-12 Jakub Jelinek PR target/92904 * config/i386/i386.c (ix86_gimplify_va_arg): If need_intregs and not need_temp, decrease alignment of the read because the GPR save area only guarantees 8-byte alignment. * gcc.c-torture/execute/pr92904.c: New test.
[Bug target/92723] [8 Regression] ICE in expand_shift_1, at expmed.c:2635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92723 --- Comment #12 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c58bec27145c9a049d6642ca011b7f0fbe9c5f33 commit r8-9993-gc58bec27145c9a049d6642ca011b7f0fbe9c5f33 Author: Jakub Jelinek Date: Fri Feb 14 13:08:33 2020 +0100 backport: re PR target/92723 (ICE in expand_shift_1, at expmed.c:2635) Backported from mainline 2019-12-11 Jakub Jelinek PR target/92723 * tree-vect-patterns.c (vect_recog_rotate_pattern): If dt is not vect_internal_def, use oprnd1 as is, without trying to cast it. Formatting fix. * gcc.dg/vect/pr92723.c: New test.
[Bug ipa/92357] ICE in IPA pass fnsummary in openmp offload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92357 --- Comment #14 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4ece9571bcb003148a4c7c8e909da2c1adf60292 commit r8-9997-g4ece9571bcb003148a4c7c8e909da2c1adf60292 Author: Jakub Jelinek Date: Fri Feb 14 13:45:52 2020 +0100 backport: re PR ipa/92357 (ICE in IPA pass fnsummary in openmp offload) Backported from mainline 2019-12-14 Jakub Jelinek PR ipa/92357 * ipa-fnsummary.c (ipa_fn_summary_write): Use lto_symtab_encoder_iterator with lsei_start_function_in_partition and lsei_next_function_in_partition instead of walking all cgraph nodes in encoder.
[Bug c++/92992] Side-effects dropped when decltype(nullptr) typed expression is passed to ellipsis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92992 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7d35cad11152895d239f103f1fffbd6f0cb58c8b commit r8--g7d35cad11152895d239f103f1fffbd6f0cb58c8b Author: Jakub Jelinek Date: Fri Feb 14 15:27:21 2020 +0100 re PR c++/92992 (Side-effects dropped when decltype(nullptr) typed expression is passed to ellipsis) PR c++/92992 * call.c (convert_arg_to_ellipsis): For decltype(nullptr) arguments that have side-effects use cp_build_compound_expr. * g++.dg/cpp0x/nullptr45.C: New test.
[Bug tree-optimization/92930] [8 Regression] GCC incorrectly optimizes away __builtin_apply() calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92930 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4982521a900158e5d6d93138e0aafb5f59f75093 commit r8-9996-g4982521a900158e5d6d93138e0aafb5f59f75093 Author: Jakub Jelinek Date: Fri Feb 14 15:25:45 2020 +0100 backport: re PR tree-optimization/92930 (GCC incorrectly optimizes away __builtin_apply() calls) Backported from mainline 2019-12-14 Jakub Jelinek PR tree-optimization/92930 * ipa-pure-const.c (special_builtin_state): Don't handle BUILT_IN_APPLY. * gcc.dg/tree-ssa/pr92930.c: New test.
[Bug fortran/92977] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92977 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b69684fdac2ac4bd128150631de6391c786e2184 commit r8-9998-gb69684fdac2ac4bd128150631de6391c786e2184 Author: Jakub Jelinek Date: Fri Feb 14 15:26:52 2020 +0100 backport: re PR fortran/92977 (ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3526) Backported from mainline 2019-12-19 Jakub Jelinek PR fortran/92977 * frontend-passes.c (call_external_blas): Use || instead of |. PR fortran/92977 * frontend-passes.c (in_omp_atomic): New variable. (cfe_expr_0, matmul_to_var_expr, matmul_temp_args, inline_matmul_assign, call_external_blas): Don't optimize in EXEC_OMP_ATOMIC. (optimize_namespace): Clear in_omp_atomic. (gfc_code_walker): Set in_omp_atomic for EXEC_OMP_ATOMIC, save/restore it around. * gfortran.dg/gomp/pr92977.f90: New test.
[Bug libgomp/93065] libgomp: destructor missing to delete goacc_cleanup_key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93065 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c343d4aab243cb477c65c6d0c37b1a6cdd2f858e commit r8-10001-gc343d4aab243cb477c65c6d0c37b1a6cdd2f858e Author: Jakub Jelinek Date: Fri Feb 14 13:57:45 2020 +0100 re PR libgomp/93065 (libgomp: destructor missing to delete goacc_cleanup_key) PR libgomp/93065 * oacc-init.c (goacc_runtime_deinitialize): New function.
[Bug c++/92438] [8 Regression] Function declaration parsed incorrectly with `-std=c++1z`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92438 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:becbae00641077f7104d16b4565c1d64df5fafc6 commit r8-1-gbecbae00641077f7104d16b4565c1d64df5fafc6 Author: Jakub Jelinek Date: Fri Feb 14 15:32:20 2020 +0100 re PR c++/92438 (Function declaration parsed incorrectly with `-std=c++1z`) PR c++/92438 * parser.c (cp_parser_constructor_declarator_p): If open paren is followed by RID_ATTRIBUTE, skip over the attribute tokens and try to parse type specifier. * g++.dg/ext/attrib61.C: New test.
[Bug ipa/93087] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93087 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f01dfd67820e6a8254e6bf9ea242bf86134486ff commit r8-10002-gf01dfd67820e6a8254e6bf9ea242bf86134486ff Author: Jakub Jelinek Date: Fri Feb 14 15:33:44 2020 +0100 re PR ipa/93087 (Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`) PR ipa/93087 * predict.c (compute_function_frequency): Don't call warn_function_cold on functions that already have cold attribute. * c-c++-common/cold-1.c: New test.
[Bug rtl-optimization/93088] [10 Regression] Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1ccdfea80e8ead4936c35b5eb736dc407a07fb32 commit r8-10003-g1ccdfea80e8ead4936c35b5eb736dc407a07fb32 Author: Jakub Jelinek Date: Fri Feb 14 15:34:43 2020 +0100 re PR rtl-optimization/93088 (Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp) PR rtl-optimization/93088 * loop-iv.c (find_single_def_src): Punt after looking through 128 reg copies for regs with single definitions. Move definitions to first uses. * gcc.target/i386/pr93088.c: New test.
[Bug inline-asm/93202] [RISCV] ICE when using inline asm 'h' operand modifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93202 --- Comment #12 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:04e48115ac4f4eab20525280653e8ff985f1a3d8 commit r8-10004-g04e48115ac4f4eab20525280653e8ff985f1a3d8 Author: Jakub Jelinek Date: Fri Feb 14 15:35:59 2020 +0100 re PR inline-asm/93202 ([RISCV] ICE when using inline asm 'h' operand modifier) PR inline-asm/93202 * config/riscv/riscv.c (riscv_print_operand_reloc): Use output_operand_lossage instead of gcc_unreachable. * doc/md.texi (riscv f constraint): Fix typo. * gcc.target/riscv/pr93202.c: New test.
[Bug c++/93228] [[deprecated("message")]] on template struct/class drops message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93228 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ef2e6135591f2a197d4fb8a7dbb8425a9d2df85e commit r8-10005-gef2e6135591f2a197d4fb8a7dbb8425a9d2df85e Author: Jakub Jelinek Date: Fri Feb 14 15:39:57 2020 +0100 c++: Fix deprecated attribute handling on templates (PR c++/93228) As the following testcase shows, when deprecated attribute is on a template, we'd never print the message if any, because the attribute is not present on the TEMPLATE_DECL with which warn_deprecated_use is called, but on its DECL_TEMPLATE_RESULT or its type. 2020-01-17 Jakub Jelinek PR c++/93228 * parser.c (cp_parser_template_name): Look up deprecated attribute in DECL_TEMPLATE_RESULT or its type's attributes. * g++.dg/cpp1y/attr-deprecated-3.C: New test.
[Bug target/93073] [8 Regression] ICE in extract_insn, at recog.c:2294 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93073 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f0776f088dce384106609fc868061defd472bc10 commit r8-10006-gf0776f088dce384106609fc868061defd472bc10 Author: Jakub Jelinek Date: Fri Feb 14 15:40:34 2020 +0100 powerpc: Fix ICE with fp conditional move (PR target/93073) The following testcase ICEs, because for TFmode the particular subtraction pattern (*subtf3) is not enabled with the given options. Using expand_simple_binop instead of emitting the subtraction by hand just moves the ICE one insn later, NEG of ABS is not then recognized, etc., but ultimately the problem is that when rs6000_emit_cmove is called for floating point operand mode (and earlier condition ensures that in that case compare_mode is also floating point), the expander makes sure the operand mode is SFDF, but for the comparison mode nothing checks it, yet there is just one *fsel* pattern with 2 separate SFDF iterators. The following patch fixes it by giving up if compare_mode is not SFmode or DFmode. 2020-01-21 Jakub Jelinek PR target/93073 * config/rs6000/rs6000.c (rs6000_emit_cmove): If using fsel, punt for compare_mode other than SFmode or DFmode. * gcc.target/powerpc/pr93073.c: New test.
[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91298 --- Comment #14 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:93266871ac794243e9785d92a0cec09b2fa5648b commit r8-10010-g93266871ac794243e9785d92a0cec09b2fa5648b Author: Jakub Jelinek Date: Fri Feb 14 15:43:47 2020 +0100 i386: Fix up -fdollars-in-identifiers with identifiers starting with $ in -masm=att [PR91298] In AT&T syntax leading $ is special, so if we have identifiers that start with dollar, we usually fail to assemble it (or assemble incorrectly). As mentioned in the PR, what works is wrapping the identifiers inside of parens, like: movl$($a), %eax leaq($a)(,%rdi,4), %rax movl($a)(%rip), %eax movl($a)+16(%rip), %eax .globl $a .type $a, @object .size $a, 72 $a: .string "$a" .quad ($a) (this is x86_64 -fno-pic -O2). In some places ($a) is not accepted, like as .globl operand, in .type, .size, so the patch overrides ASM_OUTPUT_SYMBOL_REF rather than e.g. ASM_OUTPUT_LABELREF. I didn't want to duplicate what assemble_name is doing (following transparent aliases), so split assemble_name into two parts; just mere looking at the first character of a name before calling assemble_name wouldn't be good enough, a transparent alias could lead from a name not starting with $ to one starting with it and vice versa. 2020-01-22 Jakub Jelinek PR target/91298 * output.h (assemble_name_resolve): Declare. * varasm.c (assemble_name_resolve): New function. (assemble_name): Use it. * config/i386/i386.h (ASM_OUTPUT_SYMBOL_REF): Define. * gcc.target/i386/pr91298-1.c: New test. * gcc.target/i386/pr91298-2.c: New test.
[Bug fortran/93463] ICE in oacc_code_to_statement, at fortran/openmp.c:6007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93463
--- Comment #6 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e0cbedff53ead3bbb6e7af959c727a04ec8445c7
commit r8-10012-ge0cbedff53ead3bbb6e7af959c727a04ec8445c7
Author: Jakub Jelinek
Date: Fri Feb 14 15:45:07 2020 +0100
openmp: Handle rest of EXEC_OACC_* in oacc_code_to_statement [PR93463]
As the testcase shows, some EXEC_OACC_* codes weren't handled in
oacc_code_to_statement. Fixed thusly.
2020-01-29 Jakub Jelinek
PR fortran/93463
* openmp.c (oacc_code_to_statement): Handle
EXEC_OACC_{ROUTINE,UPDATE,WAIT,CACHE,{ENTER,EXIT}_DATA,DECLARE}.
* gfortran.dg/goacc/pr93463.f90: New test.
[Bug rtl-optimization/93402] [8 Regression] Wrong code when returning padded struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93402
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:83799a013b4a7f555b1a168fcb5f8df25edede99
commit r8-10011-g83799a013b4a7f555b1a168fcb5f8df25edede99
Author: Jakub Jelinek
Date: Fri Feb 14 15:44:23 2020 +0100
postreload: Fix up postreload combine [PR93402]
The following testcase is miscompiled, because the postreload pass changes:
-(insn 14 13 23 2 (parallel [
-(set (reg:DI 1 dx [94])
-(plus:DI (reg:DI 1 dx [95])
-(reg:DI 5 di [92])))
-(clobber (reg:CC 17 flags))
-]) "pr93402.c":8:30 186 {*adddi_1}
- (expr_list:REG_EQUAL (plus:DI (reg:DI 5 di [92])
-(const_int [0x19debd01c7]))
-(nil)))
-(insn 23 14 25 2 (set (reg:SI 0 ax)
+(insn 23 13 25 2 (set (reg:SI 0 ax)
(const_int 0 [0])) "pr93402.c":10:1 67 {*movsi_internal}
(nil))
(insn 25 23 26 2 (use (reg:SI 0 ax)) "pr93402.c":10:1 -1
(nil))
-(insn 26 25 35 2 (use (reg:DI 1 dx)) "pr93402.c":10:1 -1
+(insn 26 25 35 2 (use (plus:DI (reg:DI 1 dx [95])
+(reg:DI 5 di [92]))) "pr93402.c":10:1 -1
(nil))
A USE insn is not a normal insn and verify_changes called from
apply_change_group is happy about any changes into it.
The following patch avoids this optimization if we were to change
the USE operand (this routine only changes a reg into (plus reg reg2)).
2020-01-23 Jakub Jelinek
PR rtl-optimization/93402
* postreload.c (reload_combine_recognize_pattern): Don't try to adjust
USE insns.
* gcc.c-torture/execute/pr93402.c: New test.
[Bug target/93333] ICE: RTL check: expected code 'const_int', have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0b00f43cf381f03aeaced375f8f0ef1e731c9f43 commit r8-10007-g0b00f43cf381f03aeaced375f8f0ef1e731c9f43 Author: Jakub Jelinek Date: Fri Feb 14 15:41:22 2020 +0100 riscv: Fix up riscv_rtx_costs for RTL checking (PR target/9) As mentioned in the PR, during combine rtx_costs can be called sometimes even on RTL that has not been validated yet and so can contain even operands that aren't valid in any instruction. 2020-01-21 Jakub Jelinek PR target/9 * config/riscv/riscv.c (riscv_rtx_costs) : Verify the last two operands are CONST_INT_P before using them as such. * gcc.c-torture/compile/pr9.c: New test.
[Bug fortran/93329] ICE in omp_code_to_statement, at fortran/openmp.c:5902
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93329 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba6ebaafc62924a05c961146cb0ec114ae8b04cf commit r8-10008-gba6ebaafc62924a05c961146cb0ec114ae8b04cf Author: Jakub Jelinek Date: Fri Feb 14 15:41:59 2020 +0100 openmp: Teach omp_code_to_statement about rest of OpenMP statements The omp_code_to_statement function added with the initial OpenACC support only handled small subset of the OpenMP statements, leading to ICE if any other OpenMP directive appeared inside of OpenACC directive. 2020-01-22 Jakub Jelinek PR fortran/93329 * openmp.c (omp_code_to_statement): Handle remaining EXEC_OMP_* cases. * gfortran.dg/goacc/pr93329.f90: New test.
[Bug middle-end/93505] [8 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 --- Comment #21 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a73ee641c3d2ca729bdf55225afd881f57bf4d96 commit r8-10013-ga73ee641c3d2ca729bdf55225afd881f57bf4d96 Author: Jakub Jelinek Date: Fri Feb 14 15:46:13 2020 +0100 combine: Punt on out of range rotate counts [PR93505] What happens on this testcase is with the out of bounds rotate we get: Trying 13 -> 16: 13: r129:SI=r132:DI#0<-<0x20 REG_DEAD r132:DI 16: r123:DI=r129:SI<0 REG_DEAD r129:SI Successfully matched this instruction: (set (reg/v:DI 123 [ ]) (const_int 0 [0])) during combine. So, perhaps we could also change simplify-rtx.c to punt if it is out of bounds rather than trying to optimize anything. Or, but probably GCC11 material, if we decide that ROTATE/ROTATERT doesn't have out of bounds counts or introduce targetm.rotate_truncation_mask, we should truncate the argument instead of punting. Punting is better for backports though. 2020-01-30 Jakub Jelinek PR middle-end/93505 * combine.c (simplify_comparison) : Punt on out of range rotate counts. * gcc.c-torture/compile/pr93505.c: New test.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fdaf101b1dd46d6673a318139e9620c068f45a12 commit r8-10015-gfdaf101b1dd46d6673a318139e9620c068f45a12 Author: Jakub Jelinek Date: Fri Feb 14 14:18:10 2020 +0100 openmp: Fix handling of non-addressable shared scalars in parallel nested inside of target [PR93515] As the following testcase shows, we need to consider even target to be a construct that forces not to use copy in/out for shared on parallel inside of the target. E.g. for parallel nested inside another parallel or host teams, we already avoid copy in/out and we need to treat target the same. 2020-02-06 Jakub Jelinek PR libgomp/93515 * omp-low.c (use_pointer_for_field): For nested constructs, also look for map clauses on target construct. (scan_omp_1_stmt) : Bump temporarily taskreg_nesting_level. * testsuite/libgomp.c-c++-common/pr93515.c: New test.
[Bug middle-end/93555] ICE in simd_clone_struct_copy, at omp-simd-clone.c:84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93555 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5781600c42f3ed9860a804dbbf892392bea3e39d commit r8-10014-g5781600c42f3ed9860a804dbbf892392bea3e39d Author: Jakub Jelinek Date: Fri Feb 14 15:46:51 2020 +0100 openmp: Avoid ICEs with declare simd; declare simd inbranch [PR93555] The testcases ICE because when processing the declare simd inbranch, we don't create the i == 0 clone as it already exists, which means clone_info->nargs is not adjusted, but we then rely on it being adjusted when trying other clones. 2020-02-05 Jakub Jelinek PR middle-end/93555 * omp-simd-clone.c (expand_simd_clones): If simd_clone_mangle or simd_clone_create failed when i == 0, adjust clone->nargs by clone->inbranch. * c-c++-common/gomp/pr93555-1.c: New test. * c-c++-common/gomp/pr93555-2.c: New test. * gfortran.dg/gomp/pr93555.f90: New test.
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #10 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:baef3efdc4992e4dcb7f4de62ff5bcb13bf05f60
commit r8-10016-gbaef3efdc4992e4dcb7f4de62ff5bcb13bf05f60
Author: Jakub Jelinek
Date: Fri Feb 14 15:47:55 2020 +0100
i386: Make xmm16-xmm31 call used even in ms ABI [PR65782]
On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> I guess that Comment #9 patch form the PR should be trivially correct,
> but althouhg it looks obvious, I don't want to propose the patch since
> I have no means of testing it.
I don't have means of testing it either.
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15
(low
128-bits only) are call preserved.
We are talking e.g. about
/* { dg-options "-O2 -mabi=ms -mavx512vl" } */
typedef double V __attribute__((vector_size (16)));
void foo (void);
V bar (void);
void baz (V);
void
qux (void)
{
V c;
{
register V a __asm ("xmm18");
V b = bar ();
asm ("" : "=x" (a) : "0" (b));
c = a;
}
foo ();
{
register V d __asm ("xmm18");
V e;
d = c;
asm ("" : "=x" (e) : "0" (d));
baz (e);
}
}
where according to the MSDN doc gcc incorrectly holds the c value
in xmm18 register across the foo call; if foo is compiled by some Microsoft
compiler (or LLVM), then it could clobber %xmm18.
If all xmm18 occurrences are changed to say xmm15, then it is valid to hold
the 128-bit value across the foo call (though, surprisingly, LLVM saves it
into stack anyway).
The other parts are I guess mainly about SEH. Consider e.g.
void
foo (void)
{
register double x __asm ("xmm14");
register double y __asm ("xmm18");
asm ("" : "=x" (x));
asm ("" : "=v" (y));
x += y;
y += x;
asm ("" : : "x" (x));
asm ("" : : "v" (y));
}
looking at cross-compiler output, with -O2 -mavx512f this emits
.file "abcdeq.c"
.text
.align 16
.globl foo
.deffoo;.scl2; .type 32; .endef
.seh_proc foo
foo:
subq$40, %rsp
.seh_stackalloc 40
vmovaps %xmm14, (%rsp)
.seh_savexmm%xmm14, 0
vmovaps %xmm18, 16(%rsp)
.seh_savexmm%xmm18, 16
.seh_endprologue
vaddsd %xmm18, %xmm14, %xmm14
vaddsd %xmm18, %xmm14, %xmm18
vmovaps (%rsp), %xmm14
vmovaps 16(%rsp), %xmm18
addq$40, %rsp
ret
.seh_endproc
.ident "GCC: (GNU) 10.0.1 20200207 (experimental)"
Does whatever assembler mingw64 uses even assemble this (I mean the
.seh_savexmm %xmm16, 16 could be problematic)?
I can find e.g.
https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
which then links to
https://gcc.gnu.org/PR65782
2020-02-08 Uroš Bizjak
Jakub Jelinek
PR target/65782
* config/i386/i386.h (CALL_USED_REGISTERS): Make
xmm16-xmm31 call-used even in 64-bit ms-abi.
* gcc.target/i386/pr65782.c: New test.
Co-authored-by: Uroš Bizjak
[Bug target/93696] AVX512VPOPCNTDQ writemask intrinsics produce incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93696
--- Comment #6 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:db4bfbae142906291ee319d768f4fa56d2a7682c
commit r8-10020-gdb4bfbae142906291ee319d768f4fa56d2a7682c
Author: Jakub Jelinek
Date: Fri Feb 14 15:50:10 2020 +0100
i386: Fix up _mm*_mask_popcnt_epi* [PR93696]
As mentioned in the PR and as
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mask_popcnt_epi
also documents, _mm*_popcnt_epi* intrinsics are consistent with all other
unary AVX512* intrinsics regarding arguments, i.e. the
_mm*_whatever has just single argument (called a in the docs, and __A in
the
GCC headers),
_mm*_mask_whatever has 3 arguments (called src, k, a in the docs and
_W, __U, __A in GCC headers) and
_mm*_maskz_whatever 2 arguments (called k, a in the docs and __U, __A in
GCC
headers). Unfortunately, whomever implemented the _mm*_popcnt_epi*
intrinsics got it wrong for the _mm*_mask_popcnt_epi* ones, calling the
args __A, __U, __B and not passing them in the canonical order to the
builtins, making it API incompatible with ICC as well as clang (tested on
godbolts clang 7/8/9/trunk and ICC 19.0.{0,1}, older clang/ICC don't
understand those, so it isn't that it used to be broken even in other
compilers and got changed afterwards).
2020-02-13 Jakub Jelinek
PR target/93696
* config/i386/avx512bitalgintrin.h (_mm512_mask_popcnt_epi8,
_mm512_mask_popcnt_epi16, _mm256_mask_popcnt_epi8,
_mm256_mask_popcnt_epi16, _mm_mask_popcnt_epi8,
_mm_mask_popcnt_epi16): Rename __B argument to __A and __A to __W,
pass __A to the builtin followed by __W instead of __A followed by
__B.
* config/i386/avx512vpopcntdqintrin.h (_mm512_mask_popcnt_epi32,
_mm512_mask_popcnt_epi64): Likewise.
* config/i386/avx512vpopcntdqvlintrin.h (_mm_mask_popcnt_epi32,
_mm256_mask_popcnt_epi32, _mm_mask_popcnt_epi64,
_mm256_mask_popcnt_epi64): Likewise.
* gcc.target/i386/pr93696-1.c: New test.
* gcc.target/i386/pr93696-2.c: New test.
* gcc.target/i386/avx512bitalg-vpopcntw-1.c (TEST): Fix argument order
of _mm*_mask_popcnt_*.
* gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c (TEST): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c (TEST): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntb-1.c (TEST): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntb.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntbvl.c (foo): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntd.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntwvl.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntw.c (foo): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntq.c (foo): Likewise.
[Bug target/93637] [9 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:231b10fe9f870a8a8a162e95416a6bc6df023839 commit r8-10017-g231b10fe9f870a8a8a162e95416a6bc6df023839 Author: Jakub Jelinek Date: Fri Feb 14 15:48:42 2020 +0100 i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637] As mentioned in the PR, for -mavx -mno-avx2 the backend does support vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors aren't much supported in that case, it is performed using vandps/vandnps/vorps). The problem is that after the last generic vector lowering (where the VEC_COND_EXPR still compares two V4DF vectors and has two V4DI last operands and V4DI result and so is considered ok) fre4 folds the condition into constant, at which point the middle-end during expansion will try vcond_mask_optab and fall back to trying to expand it as the constant vector < 0 vcondv4div4di, but neither of them is supported for -mavx -mno-avx2 and thus we ICE. So, the options I see is either what the following patch does, also support vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current TARGET_AVX. 2020-02-10 Jakub Jelinek PR target/93637 * config/i386/sse.md (VI_256_AVX2): New mode iterator. (vcond_mask_): Use it instead of VI_256. Change condition from TARGET_AVX2 to TARGET_AVX. * gcc.target/i386/avx-pr93637.c: New test.
[Bug middle-end/93576] [8 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 --- Comment #12 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cd73697811f4d638a26be9aeada6eb20b645b739 commit r8-10021-gcd73697811f4d638a26be9aeada6eb20b645b739 Author: Jakub Jelinek Date: Fri Feb 14 15:50:57 2020 +0100 c: Fix ICE with cast to VLA [93576] The following testcase ICEs, because the PR84305 changes try to evaluate the size earlier. If size has side-effects, that is desirable, and the side-effects will actually be wrapped in a SAVE_EXPR. The problem on this testcase is that there are no side-effects, and c_fully_fold doesn't fold those COMPOUND_EXPRs to constant, and while before gimplification we unshare trees found in the expressions, the unsharing doesn't involve TYPE_SIZE etc. of used types. Gimplification is destructive though, so when we gimplify the two nested COMPOUND_EXPRs and then try to gimplify it the second time for the TYPE_SIZEs, we ICE. Now, we could use unshare_expr in what we push to *expr, SAVE_EXPRs and their operands in there aren't unshared, but I really don't see a point of evaluating expressions that don't have side-effects before, so instead this just pushes there expressions that do have side-effects. 2020-02-13 Jakub Jelinek PR c/93576 * c-decl.c (grokdeclarator): If this_size_varies, only push size into *expr if it has side effects. * gcc.dg/pr93576.c: New test.
[Bug target/93673] Fake error given by gcc when compiling for _kshift intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93673 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fbb4d21086a20cd996049309d6c24d7fb3099123 commit r8-10019-gfbb4d21086a20cd996049309d6c24d7fb3099123 Author: Jakub Jelinek Date: Fri Feb 14 15:49:32 2020 +0100 i386: Fix k*shift* intrinsics [PR93673] As mentioned in the PR, the intrinsics allow counts from 0 to 255, but we actually reject values from 128 to 255. That is because QImode CONST_INTs can be only -128 to 127. Fixed by using const_0_to_255_operand and dropping the modes for the operands with those predicates (the IL actually contains the CONST_INT which has VOIDmode). 2020-02-13 Jakub Jelinek PR target/93673 * config/i386/sse.md (k): Drop mode from last operand and use const_0_to_255_operand predicate instead of immediate_operand. (avx512dq_fpclass, avx512dq_vmfpclass, vgf2p8affineinvqb_, vgf2p8affineqb_): Drop mode from const_0_to_255_operand predicated operands. * gcc.target/i386/avx512f-pr93673.c: New test. * gcc.target/i386/avx512dq-pr93673.c: New test. * gcc.target/i386/avx512bw-pr93673.c: New test.
[Bug target/93670] ICE for _mm256_extractf32x4_ps (unrecognized insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93670
--- Comment #7 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:5538456480ad9c1a411b76479c798984bcae2c5c
commit r8-10018-g5538456480ad9c1a411b76479c798984bcae2c5c
Author: Jakub Jelinek
Date: Fri Feb 14 15:49:11 2020 +0100
i386: Fix up vec_extract_lo* patterns [PR93670]
The VEXTRACT* insns have way too many different CPUID feature flags (ATT
syntax)
vextractf128 $imm, %ymm, %xmm/mem AVX
vextracti128 $imm, %ymm, %xmm/mem AVX2
vextract{f,i}32x4 $imm, %ymm, %xmm/mem {k}{z} AVX512VL+AVX512F
vextract{f,i}32x4 $imm, %zmm, %xmm/mem {k}{z} AVX512F
vextract{f,i}64x2 $imm, %ymm, %xmm/mem {k}{z} AVX512VL+AVX512DQ
vextract{f,i}64x2 $imm, %zmm, %xmm/mem {k}{z} AVX512DQ
vextract{f,i}32x8 $imm, %zmm, %ymm/mem {k}{z} AVX512DQ
vextract{f,i}64x4 $imm, %zmm, %ymm/mem {k}{z} AVX512F
As the testcase shows and the patch too, we didn't get it right in all
cases.
The first hunk is about avx512vl_vextractf128v8s[if] incorrectly
requiring TARGET_AVX512DQ. The corresponding insn is the first
vextract{f,i}32x4 above, so it requires VL+F, and the builtins have it
correct (TARGET_AVX512VL implies TARGET_AVX512F):
BDESC (OPTION_MASK_ISA_AVX512VL, 0, CODE_FOR_avx512vl_vextractf128v8sf,
"__builtin_ia32_extractf32x4_256_mask", IX86_BUILTIN_EXTRACTF32X4_256, UNKNOWN,
(int) V4SF_FTYPE_V8SF_INT_V4SF_UQI)
BDESC (OPTION_MASK_ISA_AVX512VL, 0, CODE_FOR_avx512vl_vextractf128v8si,
"__builtin_ia32_extracti32x4_256_mask", IX86_BUILTIN_EXTRACTI32X4_256, UNKNOWN,
(int) V4SI_FTYPE_V8SI_INT_V4SI_UQI)
We only need TARGET_AVX512DQ for avx512vl_vextractf128v4d[if].
The second hunk is about vec_extract_lo_v16s[if]{,_mask}. These are using
the vextract{f,i}32x8 insns (AVX512DQ above), but we weren't requiring
that,
but instead incorrectly && 1 for non-masked and && (64 == 64 &&
TARGET_AVX512VL)
for masked insns. This is extraction from ZMM, so it doesn't need VL for
anything. The hunk actually only requires TARGET_AVX512DQ when the insn
is masked, if it is not masked, when TARGET_AVX512DQ isn't available we can
use vextract{f,i}64x4 instead which is available already in TARGET_AVX512F
and does the same thing, extracts the low 256 bits from 512 bits vector
(often we split it into just nothing, but there are some special cases like
when using xmm16+ when we can't without AVX512VL).
The last hunk is about vec_extract_lo_v8s[if]{,_mask}. The non-_mask
suffixed ones are ok already and just split into nothing (lowpart subreg).
The masked ones were incorrectly requiring TARGET_AVX512VL and
TARGET_AVX512DQ, when we only need TARGET_AVX512VL.
2020-02-12 Jakub Jelinek
PR target/93670
* config/i386/sse.md (VI48F_256_DQ): New mode iterator.
(avx512vl_vextractf128): Use it instead of VI48F_256. Remove
TARGET_AVX512DQ from condition.
(vec_extract_lo_): Use
instead of in condition. If
TARGET_AVX512DQ is false, emit vextract*64x4 instead of
vextract*32x8.
(vec_extract_lo_): Drop
from condition.
* gcc.target/i386/avx512vl-pr93670.c: New test.
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 --- Comment #26 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:519a33f954fd71cb8b74053e168e23a1cb00d30b commit r10-6637-g519a33f954fd71cb8b74053e168e23a1cb00d30b Author: Jakub Jelinek Date: Fri Feb 14 17:36:00 2020 +0100 c++: Fix thinko in enum_min_precision [PR61414] When backporting the PR61414 fix to 8.4, I've noticed that the caching of prec is actually broken, as it would fail to actually store the computed precision into the hash_map's value and so next time we'd think the enum needs 0 bits. 2020-02-14 Jakub Jelinek PR c++/61414 * class.c (enum_min_precision): Change prec type from int to int &. * g++.dg/cpp0x/enum39.C: New test.
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 --- Comment #27 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f0a72494ea3747d1f66a0cda3e67a7611779030d commit r9-8238-gf0a72494ea3747d1f66a0cda3e67a7611779030d Author: Jakub Jelinek Date: Fri Feb 14 17:36:00 2020 +0100 c++: Fix thinko in enum_min_precision [PR61414] When backporting the PR61414 fix to 8.4, I've noticed that the caching of prec is actually broken, as it would fail to actually store the computed precision into the hash_map's value and so next time we'd think the enum needs 0 bits. 2020-02-14 Jakub Jelinek PR c++/61414 * class.c (enum_min_precision): Change prec type from int to int &. * g++.dg/cpp0x/enum39.C: New test.
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 --- Comment #28 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:53073523bca574251d45bded65b2b0c183b01e5d commit r8-10022-g53073523bca574251d45bded65b2b0c183b01e5d Author: Jakub Jelinek Date: Fri Feb 14 17:36:00 2020 +0100 c++: Fix thinko in enum_min_precision [PR61414] When backporting the PR61414 fix to 8.4, I've noticed that the caching of prec is actually broken, as it would fail to actually store the computed precision into the hash_map's value and so next time we'd think the enum needs 0 bits. 2020-02-14 Jakub Jelinek PR c++/61414 * class.c (enum_min_precision): Change prec type from int to int &. * g++.dg/cpp0x/enum39.C: New test.
[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.4 --- Comment #10 from Jakub Jelinek --- Fixed for 8.4+ and 9.3+ too.
