aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
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-03Daily bump.GCC Administrator3-1/+18
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-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 Burnus19-8/+230
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-01Fortran: Extend align-clause checks of OpenMP's allocate directiveTobias Burnus2-4/+13
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 Administrator4-1/+27
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 Burnus46-73/+1830
Merge up to r12-9090-g591ec4820aa4e6d757ddc76cae1d92d445daf72c (30th Jan 2023)
2023-01-30OpenMP/Fortran: Fix has_device_addr clause splitting [PR108558]Tobias Burnus1-0/+2
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-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)
2023-01-26restrict gcc.dg/pr107554.c to 64bit platformsRichard Biener1-1/+1
The following avoids exceeding the maximum object size on 32bit platforms. * gcc.dg/pr107554.c: Restrict to lp64. (cherry picked from commit e7ebdf51ea514ad0b2272ecfa97d6ec72a527e40)
2023-01-26Daily bump.GCC Administrator3-1/+39
2023-01-25aarch64: fix warning emission for ABI break since GCC 9.1Christophe Lyon15-7/+1132
While looking at PR 105549, which is about fixing the ABI break introduced in GCC 9.1 in parameter alignment with bit-fields, we noticed that the GCC 9.1 warning is not emitted in all the cases where it should be. This patch fixes that and the next patch in the series fixes the GCC 9.1 break. We split this into two patches since patch #2 introduces a new ABI break starting with GCC 13.1. This way, patch #1 can be back-ported to release branches if needed to fix the GCC 9.1 warning issue. The main idea is to add a new global boolean that indicates whether we're expanding the start of a function, so that aarch64_layout_arg can emit warnings for callees as well as callers. This removes the need for aarch64_function_arg_boundary to warn (with its incomplete information). However, in the first patch there are still cases where we emit warnings were we should not; this is fixed in patch #2 where we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly. The fix in aarch64_function_arg_boundary (replacing & with &&) looks like an oversight of a previous commit in this area which changed 'abi_break' from a boolean to an integer. We also take the opportunity to fix the comment above aarch64_function_arg_alignment since the value of the abi_break parameter was changed in a previous commit, no longer matching the description. 2022-11-28 Christophe Lyon <christophe.lyon@arm.com> Richard Sandiford <richard.sandiford@arm.com> gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Fix comment. (aarch64_layout_arg): Factorize warning conditions. (aarch64_function_arg_boundary): Fix typo. * function.cc (currently_expanding_function_start): New variable. (expand_function_start): Handle currently_expanding_function_start. * function.h (currently_expanding_function_start): Declare. gcc/testsuite/ChangeLog: * gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test. * gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New test. * gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test. * gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New test. * gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test. * gcc.target/aarch64/bitfield-abi-warning.h: New test. * g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test. * g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New test. * g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test. * g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New test. * g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test. * g++.target/aarch64/bitfield-abi-warning.h: New test. (cherry picked from commit 3df1a115be22caeab3ffe7afb12e71adb54ff132)
2023-01-25Daily bump.GCC Administrator3-1/+73
2023-01-24tree-optimization/108164 - undefined overflow with IV vectorizationRichard Biener2-5/+26
vect_update_ivs_after_vectorizer can end up emitting a signed IV update when the loop body performed an unsigned computation. The following makes sure to perform that update in the type of the loop update type to avoid undefined behavior on overflow. PR tree-optimization/108164 * tree-vect-loop-manip.cc (vect_update_ivs_after_vectorizer): Perform vect_step_op_add update in the appropriate type. * gcc.dg/pr108164.c: New testcase. (cherry picked from commit ec459469f8a75d96a9b26694554efcc900d411de)
2023-01-24tree-optimization/108076 - if-conversion and forced labelsRichard Biener2-2/+29
When doing if-conversion we simply throw away labels without checking whether they are possibly targets of non-local gotos or have their address taken. The following rectifies this and refuses to if-convert such loops. PR tree-optimization/108076 * tree-if-conv.cc (if_convertible_loop_p_1): Reject blocks with non-local or forced labels that we later remove labels from. * gcc.dg/torture/pr108076.c: New testcase. (cherry picked from commit b4fddbe9592e9feb37ce567d90af822b75995531)
2023-01-24middle-end/107994 - ICE after error with comparison gimplificationRichard Biener1-2/+4
The following avoids passing down error_mark_node to fold_convert. PR middle-end/107994 * gimplify.cc (gimplify_expr): Catch errorneous comparison operand. (cherry picked from commit 845b514e8a150447ba041294586af76a6ac05158)
2023-01-24tree-optimization/107554 - fix ICE in stlen optimizationRichard Biener2-1/+13
The following fixes a wrongly typed variable causing an ICE. PR tree-optimization/107554 * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes): Use unsigned HOST_WIDE_INT type for the strlen. * gcc.dg/pr107554.c: New testcase. Co-Authored-By: Nikita Voronov <nik_1357@mail.ru> (cherry picked from commit 81de4037454275f8ed6d858fbc129e832c6147ef)
2023-01-24driver: fix environ corruption after putenv() [PR106624]Sergei Trofimovich1-1/+1
The bug appeared afte r13-2010-g1270ccda70ca09 "Factor out jobserver_active_p" slightly changed `putenv()` use from allocating to non-allocating: -xputenv (concat ("MAKEFLAGS=", dup, NULL)); +xputenv (jinfo.skipped_makeflags.c_str ()); `xputenv()` (and `putenv()`) don't copy strings and only store the pointer in the `environ` global table. As a result `environ` got corrupted as soon as `jinfo.skipped_makeflags` store got deallocated. This started causing bootstrap crashes in `execv()` calls: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address The change restores memory allocation for `xputenv()` argument. gcc/ PR driver/106624 * gcc.cc (driver::detect_jobserver): Allocate storage xputenv() argument using xstrdup(). (cherry picked from commit 2b403297b111c990c331b5bbb6165b061ad2259b)
2023-01-24Daily bump.GCC Administrator4-1/+45
2023-01-23Fortran: error recovery for invalid CLASS component [PR108434]Harald Anlauf2-2/+13
gcc/fortran/ChangeLog: PR fortran/108434 * expr.cc (class_allocatable): Prevent NULL pointer dereference or invalid read. (class_pointer): Likewise. gcc/testsuite/ChangeLog: PR fortran/108434 * gfortran.dg/pr108434.f90: New test. (cherry picked from commit 117848f425a3c0eda85517b4bdaf2ebe3bc705c2)
generated by cgit v1.1 at 2025-09-21 04:54:33 +0000