aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-02-05fortran: Set name for *LOC default BACK argument [PR108450]Mikael Morin2-0/+34
This change fixes an ICE caused by the double resolution of MINLOC, MAXLOC and FINDLOC expressions which get a default value for the BACK argument at resolution time. That argument is added without name, and argument reordering code is not prepared to handle unnamed arguments coming after named ones, so the second resolution causes a NULL pointer dereference. The problem is fixed by explicitly setting the argument name. PR fortran/108450 gcc/fortran/ChangeLog: * check.cc (gfc_check_minloc_maxloc): Explicitly set argument name. (gfc_check_findloc): Ditto. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/minmaxloc_1.f90: New test. (cherry picked from commit 2e32a12c04c72f692a7bd119fd3e4e5b74392c9d)
2023-02-05Fortran: error recovery on invalid array section [PR108609]Harald Anlauf2-2/+6
The testcase for PR108527 uncovered a latent issue with invalid array sections that resulted in different paths being taken on different architectures. Detect the invalid array declaration for a clean recovery. gcc/fortran/ChangeLog: PR fortran/108609 * expr.cc (find_array_section): Add check to prevent interpreting an mpz non-integer constant as an integer. gcc/testsuite/ChangeLog: PR fortran/108609 * gfortran.dg/pr108527.f90: Adjust test pattern. (cherry picked from commit 88a2a09dd4529107e7ef7a6e7ce43acf96457173)
2023-02-05Fortran: fix ICE in compare_bound_int [PR108527]Harald Anlauf2-15/+24
gcc/fortran/ChangeLog: PR fortran/108527 * resolve.cc (compare_bound_int): Expression to compare must be of type INTEGER. (compare_bound_mpz_t): Likewise. (check_dimension): Fix comment on checks applied to array section and clean up associated logic. gcc/testsuite/ChangeLog: PR fortran/108527 * gfortran.dg/pr108527.f90: New test. Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org> (cherry picked from commit 22afa4947584c701633a79fd8750c9ceeaa96711)
2023-02-05Daily bump.GCC Administrator1-1/+1
2023-02-04Daily bump.GCC Administrator3-1/+18
2023-02-03c++: unexpected ADDR_EXPR after overload set pruning [PR107461]Patrick Palka2-5/+36
Here the ahead-of-time overload set pruning in finish_call_expr is unintentionally returning a CALL_EXPR whose (pruned) callee is wrapped in an ADDR_EXPR, despite the original callee not being wrapped in an ADDR_EXPR. This ends up causing a bogus declaration mismatch error in the below testcase because the call to min in #1 gets expressed as a CALL_EXPR of ADDR_EXPR of FUNCTION_DECL, whereas the level-lowered call to min in #2 gets expressed instead as a CALL_EXPR of FUNCTION_DECL. This patch fixes this by stripping the spurious ADDR_EXPR appropriately. Thus the first call to min now also gets expressed as a CALL_EXPR of FUNCTION_DECL, matching the behavior before r12-6075-g2decd2cabe5a4f. PR c++/107461 gcc/cp/ChangeLog: * semantics.cc (finish_call_expr): Strip ADDR_EXPR from the selected callee during overload set pruning. gcc/testsuite/ChangeLog: * g++.dg/template/call9.C: New test. (cherry picked from commit 59e0376f607805ef9b67fd7b0a4a3084ab3571a5)
2023-02-03libgomp: Fix reverse offload issuesTobias Burnus3-4/+45
If there is nothing to map, skip the mapping and avoid attempting to copy 0 bytes from addrs, sizes and kinds. Additionally, it could happen that a non-allocated address was deallocated, such as a pointer set, leading to a free for the actual data. libgomp/ * target.c (gomp_target_rev): Handle mapnum == 0 and avoid freeing not allocated memory. * testsuite/libgomp.fortran/reverse-offload-6.f90: New test. (cherry picked from commit 0b1ce70a813b98ef2893779d14ad6c90c5d06a71)
2023-02-03Daily bump.GCC Administrator4-1/+77
2023-02-02Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]Harald Anlauf2-0/+24
gcc/fortran/ChangeLog: PR fortran/108453 * match.cc (gfc_match_common): A USE associated name shall not appear in a COMMON block (F2018:C8121). gcc/testsuite/ChangeLog: PR fortran/108453 * gfortran.dg/common_27.f90: New test. (cherry picked from commit aba9ff8f30d4245294ea2583de1dc28f1c7ccf7b)
2023-02-02amdgcn: Add instruction pattern for conditional shift operationsPaul-Antoine Arras11-0/+301
gcc/ChangeLog: * config/gcn/gcn-valu.md (cond_<expander><mode>): Add cond_{ashl|ashr|lshr} gcc/testsuite/ChangeLog: * gcc.target/gcn/cond_shift_3.c: New test. * gcc.target/gcn/cond_shift_3_run.c: New test. * gcc.target/gcn/cond_shift_4.c: New test. * gcc.target/gcn/cond_shift_4_run.c: New test. * gcc.target/gcn/cond_shift_8.c: New test. * gcc.target/gcn/cond_shift_8_run.c: New test. * gcc.target/gcn/cond_shift_9.c: New test. * gcc.target/gcn/cond_shift_9_run.c: New test. (cherry picked from commit 9c7e898bbd643f45a553afcb5204717048205a1a)
2023-02-02libstdc++: Fix std::random_device for avrJonathan Wakely1-0/+2
This fixes a build failure that affects avr, but could affect other targets in theory. The _M_fini function should not try to use ::open or ::fopen if _GLIBCXX_USE_DEV_RANDOM is not defined, because no file can ever have been opened. libstdc++-v3/ChangeLog: * src/c++11/random.cc (random_device::_M_fini): Do not try to close the file handle if the target doesn't support the /dev/random and /dev/urandom files. (cherry picked from commit 277dd6ea416718ba5493023b5a4660ecdbaf936c)
2023-02-02libstdc++: Fix build failures for avrJonathan Wakely4-2/+17
The abr-libc <errno.h> does not define EOVERFLOW, which means that std::errc::value_too_large is not defined, and so <charconv> cannot be compiled. Define value_too_large for avr with a value that does not clash with any that is defined in <errno.h>. This is a kluge to fix bootstrap for avr; it can be removed after PR libstdc++/104883 is resolved. The avr-libc <errno.h> fails to meet the C and POSIX requirements that each error macro has a distinct integral value, and is usable in #if directives. Add a special case for avr to system_error.cc so that only the valid errors are recognized. Also disable the errno checks in std::filesystem::remove_all that assume a meaningful value for errno. On avr-libc <unistd.h> exists but does not define the POSIX functions needed by std::filesystem, so _GLIBCXX_HAVE_UNISTD_H is not sufficient to check for basic POSIX APIs. Check !defined __AVR__ as well as _GLIBCXX_HAVE_UNISTD_H before using those functions. This is a kluge and we should really have a specific macro that says the required functions are available. libstdc++-v3/ChangeLog: * config/os/generic/error_constants.h (errc::value_too_large) [__AVR__]: Define. * src/c++11/system_error.cc (system_category::default_error_condition) [__AVR__]: Only match recognize values equal to EDOM, ERANGE, ENOSYS and EINTR. * src/c++17/fs_ops.cc (fs::current_path) [__AVR__]: Do not check for ENOENT etc. in switch. (fs::remove_all) [__AVR__]: Likewise. * src/filesystem/ops-common.h [__AVR__]: Do not use POSIX open, close etc. (cherry picked from commit 2d2e163d12f64a5e68f9e0381751ed9d5d6d3617)
2023-02-02libstdc++: Declare const global variables inlinePatrick Palka5-23/+23
The changes inside the regex_constants and execution namespaces seem to be (the only) unimplemented parts of P0607R0 "Inline Variable for the Standard Library"; the rest of the changes are to implementation details. libstdc++-v3/ChangeLog: * include/bits/atomic_wait.h (_detail::__platform_wait_alignment): Declare inline. Remove redundant static specifier. (__detail::__atomic_spin_count_relax): Declare inline. (__detail::__atomic_spin_count): Likewise. * include/bits/regex_automaton.h (__detail::_S_invalid_state_id): Declare inline for C++17. Declare constexpr. Remove redundant const and static specifiers. * include/bits/regex_error.h (regex_constants::error_collate): Declare inline for C++17 as per P0607R0. (regex_constants::error_ctype): Likewise. (regex_constants::error_escape): Likewise. (regex_constants::error_backref): Likewise. (regex_constants::error_brack): Likewise. (regex_constants::error_paren): Likewise. (regex_constants::error_brace): Likewise. (regex_constants::error_badbrace): Likewise. (regex_constants::error_range): Likewise. (regex_constants::error_space): Likewise. (regex_constants::error_badrepeat): Likewise. (regex_constants::error_complexity): Likewise. (regex_constants::error_stack): Likewise. * include/ext/concurrence.h (__gnu_cxx::__default_lock_policy): Likewise. Remove redundant static specifier. * include/pstl/execution_defs.h (execution::seq): Declare inline for C++17 as per P0607R0. (execution::par): Likewise. (execution::par_unseq): Likewise. (execution::unseq): Likewise. (cherry picked from commit e3b10249119fb4258fb83d21d805a04f30b63152)
2023-02-02nested, openmp: Wrap OMP_CLAUSE_*_GIMPLE_SEQ into GIMPLE_BIND for ↵Jakub Jelinek4-16/+57
declare_vars [PR108435] When gimplifying OMP_CLAUSE_{LASTPRIVATE,LINEAR}_STMT, we wrap it always into a GIMPLE_BIND, but when putting statements directly into OMP_CLAUSE_{LASTPRIVATE,LINEAR}_GIMPLE_SEQ, we do it only if needed (there are any temporaries that need to be declared in the sequence). convert_nonlocal_omp_clauses was relying on the GIMPLE_BIND to be there always because it called declare_vars on it. The following patch wraps it into GIMPLE_BIND in tree-nested if we need to declare_vars on it on demand. 2023-02-02 Jakub Jelinek <jakub@redhat.com> PR middle-end/108435 * tree-nested.cc (convert_nonlocal_omp_clauses) <case OMP_CLAUSE_LASTPRIVATE>: If info->new_local_var_chain and *seq is not a GIMPLE_BIND, wrap the sequence into a new GIMPLE_BIND before calling declare_vars. (convert_nonlocal_omp_clauses) <case OMP_CLAUSE_LINEAR>: Merge with the OMP_CLAUSE_LASTPRIVATE handling except for whether seq is initialized to &OMP_CLAUSE_LASTPRIVATE_GIMPLE_SEQ (clause) or &OMP_CLAUSE_LINEAR_GIMPLE_SEQ (clause). * gcc.dg/gomp/pr108435.c: New test. (cherry picked from commit 0f349928e16fdc7dba52561e8d40347909f9f0ff)
2023-02-02Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus20-8/+238
Merge up to r12-9097-gd31bd7138610a883310dce212bb0bdaaa8da7304 (2nd Feb 2023)
2023-02-02Daily bump.GCC Administrator4-1/+27
2023-02-01ipa: Release body more carefully when removing nodes (PR 107944)Martin Jambor1-2/+12
The code removing function bodies when the last call graph clone of a node is removed is too aggressive when there are nodes up the clone_of chain which still need them. Fixed by expanding the check. gcc/ChangeLog: 2023-01-18 Martin Jambor <mjambor@suse.cz> PR ipa/107944 * cgraph.cc (cgraph_node::remove): Check whether nodes up the lcone_of chain also do not need the body. (cherry picked from commit db959e250077ae6b4fc08f53fb322719582c5de6)
2023-02-01libgomp.texi: Reverse-offload updatesTobias Burnus2-7/+28
libgomp/ * libgomp.texi (5.0 Impl. Status): Update 'requires' and 'ancestor'. (GCN): Add item about 'omp requires'. (nvptx): Likewise; add item about reverse offload. (cherry picked from commit eda38850a7980d78d966a39b58961349bea7c984)
2023-02-01Fortran: Extend align-clause checks of OpenMP's allocate directiveTobias Burnus5-6/+66
gcc/fortran/ChangeLog: * openmp.cc (resolve_omp_clauses): Check also for power of two. libgomp/ChangeLog: * testsuite/libgomp.fortran/allocate-3.f90: Fix ALIGN usage, remove unused -fdump-tree-original. * testsuite/libgomp.fortran/allocate-4.f90: New. (cherry picked from commit bf2cf6f3f1851054237ee7df99bdf60bf5a3e3ae)
2023-02-01c++: ICE with -Wlogical-op [PR107755]Marek Polacek2-1/+24
Here we crash in the middle end because warn_logical_operator calls build_range_check which calls various fold_* functions and those don't work too well when we're still processing template trees. For instance here we crash because we're converting a RECORD_TYPE to bool. At this point VIEW_CONVERT_EXPR<struct Foo>(b) hasn't yet been converted to Foo::operator bool (&b). I was excited to fix this with instantiation_dependent_expression_p which can now be called from c-family/ as well, but the problem isn't that the expression is dependent. So, p_t_d it is. PR c++/107755 gcc/cp/ChangeLog: * call.cc (build_new_op): Don't call warn_logical_operator when processing a template. gcc/testsuite/ChangeLog: * g++.dg/warn/Wlogical-op-4.C: New test. (cherry picked from commit 5ce8961b46f050a96e8c542b34b1cf024ba95f1b)
2023-02-01c++, openmp: Handle some OMP_*/OACC_* constructs during constant expression ↵Jakub Jelinek4-0/+112
evaluation [PR108607] While potential_constant_expression_1 handled most of OMP_* codes (by saying that they aren't potential constant expressions), OMP_SCOPE was missing in that list. I've also added OMP_SCAN, though that is less important (similarly to OMP_SECTION it ought to appear solely inside of OMP_{FOR,SIMD} resp. OMP_SECTIONS). As the testcase shows, it isn't enough, potential_constant_expression_1 can catch only some cases, as soon as one uses switch or ifs where at least one of the possible paths could be constant expression, we can run into the same codes during cxx_eval_constant_expression, so this patch handles those there as well. 2023-02-01 Jakub Jelinek <jakub@redhat.com> PR c++/108607 * constexpr.cc (cxx_eval_constant_expression): Handle OMP_* and OACC_* constructs as non-constant. (potential_constant_expression_1): Handle OMP_SCAN and OMP_SCOPE. * g++.dg/gomp/pr108607.C: New test. (cherry picked from commit bfc070595bfb00abef88a002eee5d9117f5b86a7)
2023-02-01Daily bump.GCC Administrator5-1/+30
2023-01-31c++: fix ICE with -Wduplicated-cond [PR107593]Marek Polacek7-2/+81
Here we crash because a CAST_EXPR, representing T(), doesn't have its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't expect that. (o_e_p is called from warn_duplicated_cond_add_or_warn.) In the past we've adjusted o_e_p to better cope with template codes, but in this case I think we just want to avoid attempting to warn about inst-dependent expressions; I don't think I've ever envisioned -Wduplicated-cond to warn about them. Also destroy the chain when an inst-dependent expression is encountered to not warn in Wduplicated-cond4.C. The ICE started with r12-6022, two-stage name lookup for overloaded operators, which gave dependent operators a TREE_TYPE (in particular, DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p: /* Similar, if either does not have a type (like a template id), they aren't equal. */ if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1)) return false; PR c++/107593 PR c++/108597 gcc/c-family/ChangeLog: * c-common.h (instantiation_dependent_expression_p): Declare. * c-warn.cc (warn_duplicated_cond_add_or_warn): If the condition is dependent, invalidate the chain. gcc/c/ChangeLog: * c-objc-common.cc (instantiation_dependent_expression_p): New. gcc/cp/ChangeLog: * cp-tree.h (instantiation_dependent_expression_p): Don't declare here. gcc/testsuite/ChangeLog: * g++.dg/warn/Wduplicated-cond3.C: New test. * g++.dg/warn/Wduplicated-cond4.C: New test. * g++.dg/warn/Wduplicated-cond5.C: New test.
2023-01-31Daily bump.GCC Administrator5-1/+35
2023-01-30Correctly detect shifts out of rangeAndrew MacLeod2-2/+31
get_shift_range was incorrectly communicating that it couldn't calculate a range when the shift values was always out fo range. Fix this and alwasy return [0, 0] when the shift value is always out of range. PR tree-optimization/108306 gcc/ * range-op.cc (operator_lshift::fold_range): Return [0, 0] not varying for shifts that are always out of void range. (operator_rshift::fold_range): Return [0, 0] not varying for shifts that are always out of void range. gcc/testsuite/ * gcc.dg/pr108306.c: New.
2023-01-30Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus47-73/+1889
Merge up to r12-9090-g591ec4820aa4e6d757ddc76cae1d92d445daf72c (30th Jan 2023)
2023-01-30OpenMP/Fortran: Fix has_device_addr clause splitting [PR108558]Tobias Burnus2-0/+61
gcc/fortran/ChangeLog: PR fortran/108558 * trans-openmp.cc (gfc_split_omp_clauses): Handle has_device_addr. libgomp/ChangeLog: PR fortran/108558 * testsuite/libgomp.fortran/has_device_addr.f90: New test. (cherry picked from commit 2325c8920bbc99edcc9fffaa79577c528df41eb8)
2023-01-30Change AVX512FP16 to AVX512-FP16 in the document.liuhongt2-3/+3
The official name is AVX512-FP16. gcc/ChangeLog: * config/i386/i386.opt: Change AVX512FP16 to AVX512-FP16. * doc/invoke.texi: Ditto.
2023-01-30Daily bump.GCC Administrator2-1/+48
2023-01-29Disable gather/scatter for zen4Jan Hubicka3-4/+32
this patch adds more tunes for zen4: - new tunes for avx512 scater instructions. In micro benchmarks these seems consistent loss compared to open-coded coe - disable use of gather for zen4 While these are win for a micro benchmarks (based on TSVC), enabling gather is a loss for parest. So for now it seems safe to keep it off. - disable pass to avoid FMA chains for znver4 since fmadd was optimized and does not seem to cause regressions. * config/i386/i386.cc (ix86_vectorize_builtin_scatter): Guard scatter by TARGET_USE_SCATTER. * config/i386/i386.h (TARGET_USE_SCATTER_2PARTS, TARGET_USE_SCATTER_4PARTS, TARGET_USE_SCATTER): New macros. * config/i386/x86-tune.def (TARGET_USE_SCATTER_2PARTS, TARGET_USE_SCATTER_4PARTS, TARGET_USE_SCATTER): New tunes. (X86_TUNE_AVOID_256FMA_CHAINS, X86_TUNE_AVOID_512FMA_CHAINS): Disable for znver4. (X86_TUNE_USE_GATHER): Disable for zen4. (cherry picked from commit 967592488c64a86f37bef3dabebb56364f14acdd)
2023-01-29Zen4 tuning part 2Jan Hubicka5-11/+29
Adds tunes needed for zen4 microarchitecture. I added two new knobs. TARGET_AVX512_SPLIT_REGS which is used to specify that internally 512 vectors are split to 256 vectors. This affects vectorization costs and reassociation width. It probably should also affect RTX costs however I doubt it is very useful since RTL optimizers are usually not judging between 256 and 512 vectors. I also added X86_TUNE_AVOID_256FMA_CHAINS. Since fma has improved in zen4 this flag may not be a win except for very specific benchmarks. I am still doing some more detailed testing here. Oherwise I disabled gathers on zen4 for 2 parts nad 4 parts. We can open code them and since the latencies has only increased since zen3 opencoding is better than actual instrucction. This shows at 4 tsvc benchmarks. I ended up setting AVX256_OPTIMAL. This is a compromise. There are some tsvc benchmarks that increase noticeably (up to 250%) however there are also few regressions. Most of these can be solved by incrasing vec_perm cost in the vectorizer. However this does not cure about 14% regression on x264 that is quite important. Here we produce vectorized loops for avx512 that probably would be faster if the loops in question had high enough iteration count. We hit this problem with avx256 too: since the loop iterates few times, only prologues/epilogues are used. Adding another round of prologue/epilogue code does not make it better. Finally I enabled avx stores for constnat sized memcpy and memset. I am not sure why this is an opt-in feature. I think for most hardware this is a win. gcc/ChangeLog: 2022-12-22 Jan Hubicka <hubicka@ucw.cz> * config/i386/i386-expand.cc (ix86_expand_set_or_cpymem): Add TARGET_AVX512_SPLIT_REGS * config/i386/i386-options.cc (ix86_option_override_internal): Honor x86_TONE_AVOID_256FMA_CHAINS. * config/i386/i386.cc (ix86_vec_cost): Honor TARGET_AVX512_SPLIT_REGS. (ix86_reassociation_width): Likewise. * config/i386/i386.h (TARGET_AVX512_SPLIT_REGS): New tune. * config/i386/x86-tune.def (X86_TUNE_USE_GATHER_2PARTS): Disable for znver4. (X86_TUNE_USE_GATHER_4PARTS): Likewise. (X86_TUNE_AVOID_256FMA_CHAINS): Set for znver4. (X86_TUNE_AVOID_512FMA_CHAINS): New utne; set for znver4. (X86_TUNE_AVX256_OPTIMAL): Add znver4. (X86_TUNE_AVX512_SPLIT_REGS): New tune. (X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3. (X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3. (X86_TUNE_AVX512_MOVE_BY_PIECES): Add znver4. (X86_TUNE_AVX512_STORE_BY_PIECES): Add znver4. (cherry picked from commit eef81eefcdc2a58111e50eb2162ea1f5becc8004)
2023-01-29Update znver4 costsJan Hubicka1-30/+31
Update cost of znver4 mostly based on data measued by Agner Fog. Compared to previous generations x87 became bit slower which is probably not big deal (and we have minimal benchmarking coverage for it). One interesting improvement is reducation of FMA cost. I also updated costs of AVX256 loads/stores based on latencies (not throughput which is twice of avx256). Overall AVX512 vectorization seems to improve noticeably some of TSVC benchmarks but since internally 512 vectors are split to 256 vectors it is somewhat risky and does not win in SPEC scores (mostly by regressing benchmarks with loop that have small trip count like x264 and exchange), so for now I am going to set AVX256_OPTIMAL tune but I am still playing with it. We improved since ZNVER1 on choosing vectorization size and also have vectorized prologues/epilogues so it may be possible to make avx512 small win overall. 2022-12-22 Jan Hubicka <hubicka@ucw.cz> * config/i386/x86-tune-costs.h (znver4_cost): Upate costs of FP and SSE moves, division multiplication, gathers, L2 cache size, and more complex FP instrutions. (cherry picked from commit bbe04bade0cc3b17e62c2af3d89b899367e7d2d1)
2023-01-29Daily bump.GCC Administrator4-1/+166
2023-01-29Add AMD znver4 instruction reservationsTejas Joshi3-1/+1070
This adds znver4 automata units and reservations separately from other znver automata, avoiding the insn-automata.cc size blow-up. gcc/ChangeLog: * common/config/i386/i386-common.cc (processor_alias_table): Use CPU_ZNVER4 for znver4. * config/i386/i386.md: Add znver4.md. * config/i386/znver4.md: New. (cherry picked from commit 72ce780a497eb3e5efe7a79ea5f21f8dd6858f7f)
2023-01-29Remove znver4 instruction reservationsTejas Joshi2-814/+37
This reverts the changes made to znver.md in: commit bf3b532b524ecacb3202ab2c8af419ffaaab7cff 2022-10-21 Tejas Joshi <TejasSanjay.Joshi@amd.com> gcc/ChangeLog: * common/config/i386/i386-common.cc (processor_alias_table): Use CPU_ZNVER3 for znver4. * config/i386/znver.md: Remove znver4 reservations. (cherry picked from commit d93171509aa7ca23148508b96f1c1f70b941d808)
2023-01-29Enable AMD znver4 support and add instruction reservationsTejas Joshi17-70/+1035
2022-09-28 Tejas Joshi <TejasSanjay.Joshi@amd.com> gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_amd_cpu): Recognize znver4. * common/config/i386/i386-common.cc (processor_names): Add znver4. (processor_alias_table): Add znver4 and modularize old znvers. * common/config/i386/i386-cpuinfo.h (processor_subtypes): AMDFAM19H_ZNVER4. * config.gcc (x86_64-*-* |...): Likewise. * config/i386/driver-i386.cc (host_detect_local_cpu): Let -march=native recognize znver4 cpus. * config/i386/i386-c.cc (ix86_target_macros_internal): Add znver4. * config/i386/i386-options.cc (m_ZNVER4): New definition. (m_ZNVER): Include m_ZNVER4. (processor_cost_table): Add znver4. * config/i386/i386.cc (ix86_reassociation_width): Likewise. * config/i386/i386.h (processor_type): Add PROCESSOR_ZNVER4. (PTA_ZNVER1): New definition. (PTA_ZNVER2): Likewise. (PTA_ZNVER3): Likewise. (PTA_ZNVER4): Likewise. * config/i386/i386.md (define_attr "cpu"): Add znver4 and rename md file. * config/i386/x86-tune-costs.h (znver4_cost): New definition. * config/i386/x86-tune-sched.cc (ix86_issue_rate): Add znver4. (ix86_adjust_cost): Likewise. * config/i386/znver1.md: Rename to znver.md. * config/i386/znver.md: Add new reservations for znver4. * doc/extend.texi: Add details about znver4. * doc/invoke.texi: Likewise. gcc/testsuite/ChangeLog: * gcc.target/i386/funcspec-56.inc: Handle new march. * g++.target/i386/mv29.C: Likewise. (cherry picked from commit bf3b532b524ecacb3202ab2c8af419ffaaab7cff)
2023-01-28Fortran: ICE in transformational_result [PR108529]Harald Anlauf2-0/+10
gcc/fortran/ChangeLog: PR fortran/108529 * simplify.cc (simplify_transformation): Do not try to simplify transformational intrinsic when the ARRAY argument has a NULL shape. gcc/testsuite/ChangeLog: PR fortran/108529 * gfortran.dg/pr108529.f90: New test. (cherry picked from commit 6c96382eed96a9285611f2e3e2e59557094172b8)
2023-01-28Fortran: error recovery for bad initializers of implied-shape arrays [PR106209]Harald Anlauf2-2/+22
gcc/fortran/ChangeLog: PR fortran/106209 * decl.cc (add_init_expr_to_sym): Handle bad initializers for implied-shape arrays. gcc/testsuite/ChangeLog: PR fortran/106209 * gfortran.dg/pr106209.f90: New test. Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org> (cherry picked from commit 748f8a8b145dde59c7b63aa68b5a59515b7efc49)
2023-01-28Fortran: fix ICE in get_expr_storage_size [PR108421]Harald Anlauf2-1/+13
gcc/fortran/ChangeLog: PR fortran/108421 * interface.cc (get_expr_storage_size): Check that we actually have an integer value before trying to extract it with mpz_get_si. gcc/testsuite/ChangeLog: PR fortran/108421 * gfortran.dg/pr108421.f90: New test. (cherry picked from commit a75760374ee54768e5fd6a27080698bfbbd041ab)
2023-01-28Fortran: fix ICE in check_charlen_present [PR108420]Harald Anlauf2-3/+16
gcc/fortran/ChangeLog: PR fortran/108420 * iresolve.cc (check_charlen_present): Preserve character length if there is no array constructor. gcc/testsuite/ChangeLog: PR fortran/108420 * gfortran.dg/pr108420.f90: New test. (cherry picked from commit e6669c0a50ed8aee9e5997d61e6271668d149218)
2023-01-28Fortran: avoid ICE on invalid array subscript triplets [PR108501]Harald Anlauf2-7/+30
gcc/fortran/ChangeLog: PR fortran/108501 * interface.cc (get_expr_storage_size): Check array subscript triplets that we actually have integer values before trying to extract with mpz_get_si. gcc/testsuite/ChangeLog: PR fortran/108501 * gfortran.dg/pr108501.f90: New test. (cherry picked from commit 771d793df1622a476e1cf8d05f0a6aee350fa56b)
2023-01-28Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]Harald Anlauf2-0/+17
gcc/fortran/ChangeLog: PR fortran/108502 * dependency.cc (gfc_check_dependency): Prevent NULL pointer dereference while recursively checking expressions. gcc/testsuite/ChangeLog: PR fortran/108502 * gfortran.dg/pr108502.f90: New test. (cherry picked from commit 51767f31878a95161142254dca7119b409699670)
2023-01-28Daily bump.GCC Administrator3-1/+18
2023-01-27arm: Fix MVE's vcmp vector-scalar patterns [PR107987]Andre Vieira2-4/+17
This patch surrounds the scalar operand of the MVE vcmp patterns with a vec_duplicate to ensure both operands of the comparision operator have the same (vector) mode. gcc/ChangeLog: PR target/107987 * config/arm/mve.md (mve_vcmp<mve_cmp_op>q_n_<mode>, @mve_vcmp<mve_cmp_op>q_n_f<mode>): Apply vec_duplicate to scalar operand. gcc/testsuite/ChangeLog: * gcc.target/arm/mve/pr107987.c: New test. (cherry picked from commit ed34c3bc3428bce663d42e9eeda10bc0c5d56d5c)
2023-01-27Daily bump.GCC Administrator3-1/+38
2023-01-26opts: SANITIZE_ADDRESS wrongly cleared [PR108543]Marek Polacek5-1/+68
Here we crash on a null fndecl ultimately because we haven't defined the built-ins described in sanitizer.def. So builtin_decl_explicit (BUILT_IN_ASAN_POINTER_SUBTRACT); returns NULL_TREE, causing an ICE later. DEF_SANITIZER_BUILTIN only actually defines the built-ins when flag_sanitize has SANITIZE_ADDRESS, or some of the other SANITIZE_*, but it doesn't check SANITIZE_KERNEL_ADDRESS or SANITIZE_USER_ADDRESS. Unfortunately, with -fsanitize=address -fno-sanitize=kernel-address or -fsanitize=kernel-address -fno-sanitize=address SANITIZE_ADDRESS ends up being unset from flag_sanitize even though _USER/_KERNEL are set. That's because -fsanitize=address means SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS and -fsanitize=kernel-address is SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS but parse_sanitizer_options does flags &= ~sanitizer_opts[i].flag; so the subsequent -fno- unsets SANITIZE_ADDRESS. Then no sanitizer built-ins are actually defined. I'm not sure why SANITIZE_ADDRESS isn't just SANITIZE_USER_ADDRESS | SANITIZE_KERNEL_ADDRESS, I don't think we need 3 bits. PR middle-end/108543 gcc/ChangeLog: * opts.cc (parse_sanitizer_options): Don't always clear SANITIZE_ADDRESS if it was previously set. gcc/testsuite/ChangeLog: * c-c++-common/asan/pointer-subtract-5.c: New test. * c-c++-common/asan/pointer-subtract-6.c: New test. * c-c++-common/asan/pointer-subtract-7.c: New test. * c-c++-common/asan/pointer-subtract-8.c: New test. (cherry picked from commit a82ce9c8d155ecda2d1c647d5c588f29e21ef4a3)
2023-01-26pru: Fix CLZ expansion for QI and HI modesDimitar Dimitrov2-5/+15
The recent gcc.dg/tree-ssa/clz-char.c test case failed for PRU target, exposing a wrong code generation bug in the PRU backend. The "clz" pattern did not produce correct output for QI and HI input operand modes. SI mode is ok. The "clz" pattern is expanded to an LMBD instruction to get the left-most bit position having value "1". In turn, to get the correct "clz" value, that bit position must be subtracted from the MSB bit position of the input operand. The old behaviour of hard-coding 31 for MSB bit position is wrong. The LMBD instruction returns 32 if input operand is zero, irrespective of its register mode. This maps nicely for SI mode, where the "clz" pattern outputs -1. It also leads to peculiar (but valid!) output values from the "clz" pattern for QI and HI zero-valued inputs. The corresponding commit in trunk contains two new test cases, which have been removed here because they depend on r13-5195-g4798080d4a3530. Regtested for pru-unknown-elf. gcc/ChangeLog: * config/pru/pru.h (CLZ_DEFINED_VALUE_AT_ZERO): Fix value for QI and HI input modes. * config/pru/pru.md (clz): Fix generated code for QI and HI input modes. Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu> (cherry picked from commit c517295940a23db8ca165dfd5d0edea4457eda49)
2023-01-26libgomp.texi: Impl. status - non-rect loop nest only partialTobias Burnus2-1/+8
libgomp/ * libgomp.texi (OpenMP 5.0): Set non-rectangular loop nest back to 'P' as Fortran support is incomplete. (cherry picked from commit 20552407ae11b61fccb46b3e96a8814e790254e7)
2023-01-26install.texi: Bump newlib version for nvptx + gcnTobias Burnus2-2/+9
Before, newlib 3.2 was required for amdgcn and 3.1 for nvptx. Now recommended is 4.3.0 which was just released on 2023-01-20. While currently the old versions would work fine, upcoming GCC changes depend on a newer newlib. Thus, the minimal version is bumped instead of just recommending the new version. For GCN, the bump is in preparation for permitting non-threadlocal stack variables and vectorized math functions - both scheduled for GCC 13 and added to newlib in 4.3.0. For nvptx, this includes an emulated clock (commit 6bb96d13a), a calloc fix (5fca4e0f1) and changes to permit libgfortran to be compiled with I/O support instead of only in minimal mode. (Patch approved for GCC 13 but pending on a nvtpx patch, which for which review is pending.) gcc/ChangeLog: * doc/install.texi (amdgcn, nvptx): Require newlib 4.3.0. (cherry picked from commit e94e9944f59b00de455bb719fd0c5281c5509be6)
2023-01-26Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus29-21/+1373
Merge up to r12-9069-g6484fc2bf682ccf50c11675773cf72d32a079426 (26th Jan 2023)
generated by cgit v1.1 at 2025-09-24 05:07:05 +0000