[gcc r14-9490] bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

https://gcc.gnu.org/g:90b9872311ccb24685ba33b6ba6f374d50f03874 commit r14-9490-g90b9872311ccb24685ba33b6ba6f374d50f03874 Author: Jakub Jelinek Date: Fri Mar 15 09:16:43 2024 +0100 bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466

Re: [PATCH RFA] tree-core: clarify clobber comments

On Thu, Mar 14, 2024 at 04:27:22PM -0400, Jason Merrill wrote: > OK for trunk? > > -- 8< -- > > It came up on the mailing list that OBJECT_BEGIN/END are described as > marking object lifetime, but mark the beginning of the constructor and end > of the destructor, whereas the C++ notion of

[committed] gcn: Fix a comment typo

Hi! I've noticed a typo in the comment above ABI_VERSION_SPEC. Fixed thusly, committed to trunk as obvious. 2024-03-14 Jakub Jelinek * config/gcn/gcn-hsa.h (ABI_VERSION_SPEC): Fix comment typo. --- gcc/config/gcn/gcn-hsa.h.jj 2024-01-27 13:03:55.589073484 +0100 +++ gcc/config/gcn

[gcc r14-9477] gcn: Fix a comment typo

https://gcc.gnu.org/g:fd7104388406b77ad4b81eb77d976ecfff848913 commit r14-9477-gfd7104388406b77ad4b81eb77d976ecfff848913 Author: Jakub Jelinek Date: Thu Mar 14 17:51:32 2024 +0100 gcn: Fix a comment typo I've noticed a typo in the comment above ABI_VERSION_SPEC. Fixed

[gcc r14-9476] icf: Reset SSA_NAME_{PTR, RANGE}_INFO in successfully merged functions [PR113907]

https://gcc.gnu.org/g:7580e39452b65ab5fb5a06f3f1ad7d59720269b5 commit r14-9476-g7580e39452b65ab5fb5a06f3f1ad7d59720269b5 Author: Jakub Jelinek Date: Thu Mar 14 17:48:30 2024 +0100 icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907] AFAIK we have

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Thu, Mar 14, 2024 at 05:16:59PM +0100, Jan Hubicka wrote: > Sorry, this was bit of a misunderstanding: I tought you still considered > the original patch to be full fix, while I tought I should look into it > more and dig out more issues. This is bit of can of worms. Overall I > think the

[gcc r14-9469] aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310]

https://gcc.gnu.org/g:9349aefa1df7ae36714b7b9f426ad46e314892d1 commit r14-9469-g9349aefa1df7ae36714b7b9f426ad46e314892d1 Author: Jakub Jelinek Date: Thu Mar 14 14:09:20 2024 +0100 aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310] The following

Re: [PATCH] aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310]

On Thu, Mar 14, 2024 at 11:49:14AM +, Richard Earnshaw (lists) wrote: > On 14/03/2024 08:37, Jakub Jelinek wrote: > > Hi! > > > > The following testcase ICEs with LSE atomics. > > The problem is that the @atomic_compare_and_swap expander uses > > aarch64_reg_

[PATCH] bitint, v2: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

On Thu, Mar 14, 2024 at 09:59:12AM +0100, Richard Biener wrote: > On Thu, 14 Mar 2024, Jakub Jelinek wrote: > > > On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote: > > > Ugh. OK, but I wonder whether we might want to simply delay > > > fixing the

[gcc r14-9460] gimple-iterator: Some gsi_safe_insert_*before fixes

https://gcc.gnu.org/g:8f6e0814b4bfd0a399055e9214562aebfcd902ad commit r14-9460-g8f6e0814b4bfd0a399055e9214562aebfcd902ad Author: Jakub Jelinek Date: Thu Mar 14 09:57:13 2024 +0100 gimple-iterator: Some gsi_safe_insert_*before fixes When trying to use the gsi_safe_insert*before

Re: [PATCH] bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote: > Ugh. OK, but I wonder whether we might want to simply delay > fixing the CFG for inserts before returns-twice? Would that make > things less ugly? You mean in lower_call just remember if we added anything before ECF_RETURNS_TWICE

[PATCH] aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310]

into the link register to emulate pair of zeros. So, the following patch fixes that by forcing the newval operand into a register for the TImode LSE case. Bootstrapped/regtested on aarch64-linux, ok for trunk? 2024-03-14 Jakub Jelinek PR target/114310 * config/aarch64/aarch64.cc

[PATCH] bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

to be growed (otherwise it is just a partition_union). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-14 Jakub Jelinek PR tree-optimization/113466 * gimple-lower-bitint.cc (bitint_large_huge::lower_call): Handle ECF_RETURNS_TWICE call arguments

[PATCH] gimple-iterator: Some gsi_safe_insert_*before fixes

, but gsi_bb and gsi_seq are no longer correct; the patch updates it Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-14 Jakub Jelinek * gimple-iterator.cc (edge_before_returns_twice_call): Copy all flags and probability from ad_edge to e edge

[gcc r14-9453] store-merging: Match bswap64 on 32-bit targets with bswapsi2 [PR114319]

https://gcc.gnu.org/g:74bca21db31e3f4ab6543b56c3f26b4dfe586fef commit r14-9453-g74bca21db31e3f4ab6543b56c3f26b4dfe586fef Author: Jakub Jelinek Date: Wed Mar 13 15:34:59 2024 +0100 store-merging: Match bswap64 on 32-bit targets with bswapsi2 [PR114319] gimple-ssa-store-merging.cc

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Wed, Mar 13, 2024 at 12:18:45PM +0100, Jan Hubicka wrote: > > On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote: > > > > > So the ipa_jump_func are I think the only thing that actually can > > > > > differ > > > > > on the ICF merging candidates from value range POV. > > > > > > > >

Re: [PATCH] testsuite: Fix vfprintf-chk-1.c with -fhardened

On Wed, Mar 13, 2024 at 06:05:29PM +0800, Xi Ruoyao wrote: > On Tue, 2024-03-12 at 17:19 +0100, Jakub Jelinek wrote: > > On Thu, Feb 15, 2024 at 10:53:08PM +, Sam James wrote: > > > With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's > > >

[PATCH] store-merging: Match bswap64 on 32-bit targets with bswapsi2 [PR114319]

and i686-linux, ok for trunk? 2024-03-13 Jakub Jelinek PR middle-end/114319 * gimple-ssa-store-merging.cc (imm_store_chain_info::try_coalesce_bswap): For 32-bit targets allow matching __builtin_bswap64 if there is bswapsi2 optab. * gcc.target/i386

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote: > > > So the ipa_jump_func are I think the only thing that actually can differ > > > on the ICF merging candidates from value range POV. > > > > I agree. Btw, I would have approved the original patch in this > > thread that wipes

[gcc r14-9447] bitint: Fix up lowering of bitfield loads/stores [PR114313]

https://gcc.gnu.org/g:0613b12dd7f6274a1aac07f295ed51d86c2c85f1 commit r14-9447-g0613b12dd7f6274a1aac07f295ed51d86c2c85f1 Author: Jakub Jelinek Date: Wed Mar 13 10:19:04 2024 +0100 bitint: Fix up lowering of bitfield loads/stores [PR114313] The following testcase ICEs, because

Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]

On Wed, Mar 13, 2024 at 07:37:26AM +0100, Дилян Палаузов wrote: > Non-parallel build can fail, depending on the ./configure parameters - > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 . > > The change below does fix the problem. CCing build system maintainers and the Go maintainer. While

[PATCH] bitint: Fix up lowering of bitfield loads/stores [PR114313]

the right size to use anyway because the code uses VIEW_CONVERT_EXPR on it. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-13 Jakub Jelinek PR middle-end/114313 * gimple-lower-bitint.cc (bitint_large_huge::limb_access): Use TYPE_SIZE of TREE

[committed] asan, v2: Fix ICE during instrumentation of returns_twice calls [PR112709]

On Tue, Mar 12, 2024 at 02:46:07PM +0100, Richard Biener wrote: > OK. Thanks. Here is the actually committed version which uses gsi_safe_insert_before instead. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk. 2024-03-13 Jakub Jelinek PR sanitizer/112

[gcc r14-9445] asan: Fix ICE during instrumentation of returns_twice calls [PR112709]

https://gcc.gnu.org/g:6586359e8e4c611dd96129b5d4f24023949ac3fc commit r14-9445-g6586359e8e4c611dd96129b5d4f24023949ac3fc Author: Jakub Jelinek Date: Wed Mar 13 09:19:05 2024 +0100 asan: Fix ICE during instrumentation of returns_twice calls [PR112709] The following patch on top

[gcc r14-9444] gimple-iterator, ubsan: Fix ICE during instrumentation of returns_twice calls [PR112709]

https://gcc.gnu.org/g:364c684c474841e3c9c04e025a5c1bca49705c86 commit r14-9444-g364c684c474841e3c9c04e025a5c1bca49705c86 Author: Jakub Jelinek Date: Wed Mar 13 09:16:45 2024 +0100 gimple-iterator, ubsan: Fix ICE during instrumentation of returns_twice calls [PR112709] ubsan

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote: > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote: > > I am sorry for delaying this. I made the variant that simply compares > > value range of functions and prevents merging if they diverge and wanted &

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote: > I am sorry for delaying this. I made the variant that simply compares > value range of functions and prevents merging if they diverge and wanted > to make some bigger statistics. This made me notice some performance > problems on

Re: [PATCH] testsuite: Fix vfprintf-chk-1.c with -fhardened

On Thu, Feb 15, 2024 at 10:53:08PM +, Sam James wrote: > With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's > __vfprintf_chk ends up calling __vprintf_chk rather than vprintf. s/__vprintf_chk/__vfprintf_chk/ above > > ``` > --- a/fortify.s > +++ b/no-fortify.s > @@ -8,27

[PATCH] gimple-iterator, ubsan, v3: Fix ICE during instrumentation of returns_twice calls [PR112709]

line function. The patch is even shorter then (the asan patch as well). Tested again with make check-gcc check-g++ RUNTESTFLAGS='ubsan.exp asan.exp' 2024-03-12 Jakub Jelinek PR sanitizer/112709 * gimple-iterator.h (gsi_safe_insert_before, gsi_safe_insert_seq_before): D

Re: [PATCH] gimple-iterator, ubsan: Fix ICE during instrumentation of returns_twice calls [PR112709]

On Tue, Mar 12, 2024 at 01:47:53PM +0100, Richard Biener wrote: > > Admittedly the above is the ugliest part of the patch IMHO. > > It isn't needed in all cases, but e.g. for the pr112709-2.c (qux) case > > we have before ubsan pass > > # _7(ab) = PHI <_20(9), _8(ab)(11)> > > _22 = bar

Re: [PATCH] gimple-iterator, ubsan: Fix ICE during instrumentation of returns_twice calls [PR112709]

t;correctly" for abnormals (or add > split_block_before_returns_twice_call ()). But that's just bike-shedding. I don't see how is that possible. The usual case is that no split_block is needed, usually the returns_twice block has just a single normal predecessor an

[gcc r14-9438] asan: Instrument stores in callees rather than callers [PR112709]

https://gcc.gnu.org/g:ad860cc27b3312f9119c7fecb8638a7c1f6d77c9 commit r14-9438-gad860cc27b3312f9119c7fecb8638a7c1f6d77c9 Author: Jakub Jelinek Date: Tue Mar 12 11:34:50 2024 +0100 asan: Instrument stores in callees rather than callers [PR112709] asan currently instruments since

[gcc r14-9437] strlen: Fix another spot that can create invalid ranges [PR114293]

https://gcc.gnu.org/g:39737cdf002637c7a652e9c3e36f369cfce581e5 commit r14-9437-g39737cdf002637c7a652e9c3e36f369cfce581e5 Author: Jakub Jelinek Date: Tue Mar 12 10:23:19 2024 +0100 strlen: Fix another spot that can create invalid ranges [PR114293] This PR is similar to PR110603

[PATCH] asan: Fix ICE during instrumentation of returns_twice calls [PR112709]

case as well as instrumentation of loads from aggregate memory in the function arguments of returns_twice calls. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-12 Jakub Jelinek PR sanitizer/112709 * asan.cc (asan_insert_before): New function

[PATCH] gimple-iterator, ubsan: Fix ICE during instrumentation of returns_twice calls [PR112709]

o code executed during that point. The ubsan/pr112709-1.c testcase includes non-virtual PHIs to cover the handling of those as well. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-12 Jakub Jelinek PR sanitizer/112709

[PATCH] asan: Instrument stores in callees rather than callers [PR112709]

-linux and i686-linux, ok for trunk? 2024-03-12 Jakub Jelinek PR sanitizer/112709 * asan.cc (has_stmt_been_instrumented_p): Don't instrument call stores on the caller side unless it is a call to a builtin or internal function or function doesn't return by hidden

[PATCH] strlen: Fix another spot that can create invalid ranges [PR114293]

to that, and we have choice to only keep the min and use +inf for max, or only keep max and use 0 for min, or not set the range at all, or use [min, min] or [max, max] etc. The following patch uses [min, +inf]. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-12 Jakub

Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

Hi! On Thu, Feb 15, 2024 at 08:29:24AM +0100, Jakub Jelinek wrote: > 2024-02-15 Jakub Jelinek > > PR middle-end/113907 > * ipa-icf.cc (sem_item_optimizer::merge_classes): Reset > SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged &g

Re: [PATCH] bitint, v2: Avoid rewriting large/huge _BitInt vars into SSA after bitint lowering [PR114278]

On Mon, Mar 11, 2024 at 11:31:51AM +0100, Richard Biener wrote: > On Mon, 11 Mar 2024, Jakub Jelinek wrote: > > > On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote: > > > Ideally we?d clear TREE_ADDRESSABLE but set DECL_NOT_GIMPLE_REG, > > > I thi

Re: [Patch] OpenMP/Fortran: Fix defaultmap(none) issue with dummy procedures [PR114283]

On Mon, Mar 11, 2024 at 11:07:46AM +0100, Tobias Burnus wrote: > Using dummy procedures in a target region with 'defaultmap(none)' leads to: > > Error: 'g' not specified in enclosing 'target' > > and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines > are rejected as

[gcc r14-9424] bitint: Avoid rewriting large/huge _BitInt vars into SSA after bitint lowering [PR114278]

https://gcc.gnu.org/g:dbe5ccda4dbbd064c703cd3ab2a58ea40f08dd1a commit r14-9424-gdbe5ccda4dbbd064c703cd3ab2a58ea40f08dd1a Author: Jakub Jelinek Date: Mon Mar 11 11:00:54 2024 +0100 bitint: Avoid rewriting large/huge _BitInt vars into SSA after bitint lowering [PR114278

[PATCH] bitint, v2: Avoid rewriting large/huge _BitInt vars into SSA after bitint lowering [PR114278]

and i686-linux. 2024-03-11 Jakub Jelinek PR tree-optimization/114278 * tree-ssa.cc (maybe_optimize_var): If large/huge _BitInt vars are no longer addressable, set DECL_NOT_GIMPLE_REG_P on them. * gcc.dg/bitint-99.c: New test. --- gcc/tree-ssa.cc.jj 2024-01

[gcc r14-9412] fwprop: Restore previous behavior for forward propagation of RTL with MEMs [PR114284]

https://gcc.gnu.org/g:3e3e4156a5f93e6d62101594ca6660ee9ce9c10e commit r14-9412-g3e3e4156a5f93e6d62101594ca6660ee9ce9c10e Author: Jakub Jelinek Date: Sat Mar 9 13:04:26 2024 +0100 fwprop: Restore previous behavior for forward propagation of RTL with MEMs [PR114284] Before

[committed] i386: Regenerate i386.opt.urls

-mnoreturn-no-callee-saved-registers works, committed to trunk as obvious. 2024-03-09 Jakub Jelinek * config/i386/i386.opt.urls: Regenerate. --- gcc/config/i386/i386.opt.urls.jj2024-03-04 19:20:27.060201697 +0100 +++ gcc/config/i386/i386.opt.urls 2024-03-08 18:32:20.527162487

[gcc r14-9409] i386: Regenerate i386.opt.urls

https://gcc.gnu.org/g:e9753f4b633608ae4adc6efb747e638783cd6196 commit r14-9409-ge9753f4b633608ae4adc6efb747e638783cd6196 Author: Jakub Jelinek Date: Sat Mar 9 09:37:07 2024 +0100 i386: Regenerate i386.opt.urls When I've added the -mnoreturn-no-callee-saved-registers option

[PATCH] fwprop: Restore previous behavior for forward propagation of RTL with MEMs [PR114284]

table_p () is taken as the old profitable_p () as a requirement rather than just a hint. For propagation of something which doesn't load from memory this keeps the r14-8319 behavior. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-09 Jakub Jelinek PR target/114284

[PATCH] bitint: Avoid rewriting large/huge _BitInt vars into SSA after bitint lowering [PR114278]

trunk? 2024-03-09 Jakub Jelinek PR tree-optimization/114278 * tree-ssa.cc (maybe_optimize_var): Punt on large/huge _BitInt vars after bitint lowering. * gcc.dg/bitint-99.c: New test. --- gcc/tree-ssa.cc.jj 2024-01-03 11:51:39.902615009 +0100 +++ gcc/tree-

[gcc r14-9393] contrib: Improve dg-extract-results.sh's Python detection [PR109668]

https://gcc.gnu.org/g:64273a7e6bd8ba60058174d147521dd65d705637 commit r14-9393-g64273a7e6bd8ba60058174d147521dd65d705637 Author: Sam James Date: Fri Mar 8 15:24:20 2024 +0100 contrib: Improve dg-extract-results.sh's Python detection [PR109668] 'python' on some systems (e.g. SLES

[gcc r14-9392] testsuite: Fix up pr113617 test for darwin [PR113617]

https://gcc.gnu.org/g:8263a4b6505f84973c2ed2fb8d4f2036ca335ff3 commit r14-9392-g8263a4b6505f84973c2ed2fb8d4f2036ca335ff3 Author: Jakub Jelinek Date: Fri Mar 8 15:18:56 2024 +0100 testsuite: Fix up pr113617 test for darwin [PR113617] The test attempts to link a shared library

[gcc r14-9388] bb-reorder: Fix assertion

https://gcc.gnu.org/g:d6bcc2e257026b383ac3e6ccdee13f7763b38621 commit r14-9388-gd6bcc2e257026b383ac3e6ccdee13f7763b38621 Author: Jakub Jelinek Date: Fri Mar 8 12:49:43 2024 +0100 bb-reorder: Fix assertion When touching bb-reorder yesterday, I've noticed the checking assert

[PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

ype and dereferences it. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-08 Jakub Jelinek PR c++/111284 * constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with TREE_ADDRESSABLE types use vc_glvalue rather than vc_prva

[PATCH] testsuite: Fix up pr113617 test for darwin [PR113617]

Jakub Jelinek PR rtl-optimization/113617 * g++.dg/other/pr113617.C: Define -DSHARED when linking with -shared. * g++.dg/other/pr113617-aux.cc: Add definitions for used methods and templates not defined elsewhere. --- gcc/testsuite/g++.dg/other/pr113617.C.jj2024

[PATCH] bb-reorder: Fix assertion

asm. The following patch fixes the assertion to actually check that it is asm goto. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-08 Jakub Jelinek * bb-reorder.cc (fix_up_fall_thru_edges): Fix up checking assert, asm_noperands < 0 means it is not asm go

[gcc r14-9387] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-register

https://gcc.gnu.org/g:a307a26e8b392ba65edfdae15489556b7701db81 commit r14-9387-ga307a26e8b392ba65edfdae15489556b7701db81 Author: Jakub Jelinek Date: Fri Mar 8 09:18:19 2024 +0100 i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers

[gcc r14-9386] c-family, c++: Fix up handling of types which may have padding in __atomic_{compare_}exchange

https://gcc.gnu.org/g:eed4e541711ab4ae7783f75dd132e2acca71fdb9 commit r14-9386-geed4e541711ab4ae7783f75dd132e2acca71fdb9 Author: Jakub Jelinek Date: Fri Mar 8 09:15:39 2024 +0100 c-family, c++: Fix up handling of types which may have padding in __atomic_{compare_}exchange On Fri

[gcc r14-9384] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802]

https://gcc.gnu.org/g:3ecc5071797c4ceb6da67a6c2b2527a046091de2 commit r14-9384-g3ecc5071797c4ceb6da67a6c2b2527a046091de2 Author: Jakub Jelinek Date: Fri Mar 8 09:11:57 2024 +0100 c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802] The simple presence

[gcc r14-9385] dwarf2out: Emit DW_AT_export_symbols on anon unions/structs [PR113918]

https://gcc.gnu.org/g:05109b1bd5ef4ee9d78fe17d4563889694a26d05 commit r14-9385-g05109b1bd5ef4ee9d78fe17d4563889694a26d05 Author: Jakub Jelinek Date: Fri Mar 8 09:14:32 2024 +0100 dwarf2out: Emit DW_AT_export_symbols on anon unions/structs [PR113918] DWARF5 added

Re: [PATCH] contrib: Improve dg-extract-results.sh's Python detection

On Thu, Mar 07, 2024 at 02:25:09PM +, Sam James wrote: > Jakub Jelinek writes: > > > On Thu, Mar 07, 2024 at 02:16:37PM +, Sam James wrote: > >> 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer > >> ${EPYTHON} > >> if defined

Re: [PATCH] contrib: Improve dg-extract-results.sh's Python detection

On Thu, Mar 07, 2024 at 02:16:37PM +, Sam James wrote: > 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer ${EPYTHON} > if defined (used by Gentoo's python-exec wrapping), then python3, then python. I'd say EPYTHON is too distro specific, just use for python in python3 python

[gcc r14-9359] analyzer: Fix up some -Wformat* warnings

https://gcc.gnu.org/g:a242f69693d2fcac428cb82bf843882dee84fc81 commit r14-9359-ga242f69693d2fcac428cb82bf843882dee84fc81 Author: Jakub Jelinek Date: Thu Mar 7 14:19:49 2024 +0100 analyzer: Fix up some -Wformat* warnings I'm seeing warnings like ../../gcc/analyzer/access

Re: GCN, nvptx: Fatal error for missing symbols in 'libhsa-runtime64.so.1', 'libcuda.so.1' (was: [PATCH] Allow building GCC with PTX offloading even without CUDA being installed (gcc and nvptx-tools p

On Thu, Mar 07, 2024 at 12:53:31PM +0100, Thomas Schwinge wrote: > >From 6a6520e01f7e7118b556683c2934f2c64c6dbc81 Mon Sep 17 00:00:00 2001 > From: Thomas Schwinge > Date: Thu, 7 Mar 2024 12:31:52 +0100 > Subject: [PATCH] GCN, nvptx: Fatal error for missing symbols in > 'libhsa-runtime64.so.1',

Re: [PATCH v2] combine: Fix ICE in try_combine on pr112494.c [PR112560]

On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote: > > Since you CCed me - looking at the code I wonder why we fatally fail. > > The following might also fix the issue and preserve more of the > > rest of the flow of the function. > > > > If that works I'd prefer it. But I'll defer

[gcc r14-9355] bb-reorder: Fix -freorder-blocks-and-partition ICEs on aarch64 with asm goto [PR110079]

https://gcc.gnu.org/g:b209d905f5ce1fa9d76ce634fd54245ff340960b commit r14-9355-gb209d905f5ce1fa9d76ce634fd54245ff340960b Author: Jakub Jelinek Date: Thu Mar 7 10:02:49 2024 +0100 bb-reorder: Fix -freorder-blocks-and-partition ICEs on aarch64 with asm goto [PR110079

[gcc r14-9354] expand: Fix UB in choose_mult_variant [PR105533]

https://gcc.gnu.org/g:c655c8d8d845b36c59babb2413ce7aa3584dbeda commit r14-9354-gc655c8d8d845b36c59babb2413ce7aa3584dbeda Author: Jakub Jelinek Date: Thu Mar 7 10:02:00 2024 +0100 expand: Fix UB in choose_mult_variant [PR105533] As documented in the function comment

[gcc r14-9353] sccvn: Avoid UB in ao_ref_init_from_vn_reference [PR105533]

https://gcc.gnu.org/g:e1bd0f293d8407d4e8149fbafd470612323dc938 commit r14-9353-ge1bd0f293d8407d4e8149fbafd470612323dc938 Author: Jakub Jelinek Date: Thu Mar 7 10:01:08 2024 +0100 sccvn: Avoid UB in ao_ref_init_from_vn_reference [PR105533] When compiling libgcc or on e.g. int

[PATCH] analyzer: Fix up some -Wformat* warnings

here: grep pp_format_decoder.*=.default_tree_printer analyzer/* | wc -l 57 The following patch fixes that by making sure diagnostic-core.h is included before pretty-print.h. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-07 Jakub Jelinek * access-diagram.c

[PATCH] bb-reorder: Fix -freorder-blocks-and-partition ICEs on aarch64 with asm goto [PR110079]

ition on aarch64 before/after this patch just b .L? jumps which I believe are +-32MB, so if .text is larger than 32MB, it could fail to link, but this patch doesn't address that. Bootstrapped/regtested on x86_64-linux, i686-linux and aarch64-linux, ok for trunk? 2024-03-07 Jakub Jelinek

[PATCH] expand: Fix UB in choose_mult_variant [PR105533]

sts that something that could be expressed as x << 63 would be better expressed as (x * 0x7fff) + 1 In the long term, I think we should just rewrite choose_mult_variant/synth_mult etc. to work on wide_int. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-

[PATCH] sccvn: Avoid UB in ao_ref_init_from_vn_reference [PR105533]

does and triggers UB only if there would be signed multiply overflow. In the end, the compiler will treat them the same at least at the RTL level (at least, if not and they aren't the same cost, it should). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-07 Jakub

[gcc r14-9350] match.pd: Optimize a * !a to 0 [PR114009]

https://gcc.gnu.org/g:95b6ee96348041eaee9133f082b57f3e57ef0b11 commit r14-9350-g95b6ee96348041eaee9133f082b57f3e57ef0b11 Author: Jakub Jelinek Date: Thu Mar 7 08:43:16 2024 +0100 match.pd: Optimize a * !a to 0 [PR114009] The following patch attempts to fix an optimization

Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg

On Wed, Mar 06, 2024 at 05:28:21PM -0300, Alexandre Oliva wrote: > On Mar 1, 2024, "Richard Earnshaw (lists)" wrote: > > > On 01/03/2024 04:38, Alexandre Oliva wrote: > >> Thanks for the review. > > > For closure, Jakub has just pushed a patch to the generic code, so I > > don't think we need

C++ patch ping

Hi! https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#645781 [PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802] The thread contains two possible further versions of the patch.

[PATCH] match.pd, v2: Optimize a * !a to 0 [PR114009]

So, is the following still ok if it passes bootstrap/regtest? 2024-03-06 Jakub Jelinek PR tree-optimization/114009 * genmatch.cc (decision_tree::gen): Emit ARG_UNUSED for captures argument even for GENERIC, not just for GIMPLE. * match.pd (a * !a -> 0): New si

[gcc r14-9329] i386: Fix up the vzeroupper REG_DEAD/REG_UNUSED note workaround [PR114190]

https://gcc.gnu.org/g:1157d5de35b41eabe5ee51d532224864173c37bd commit r14-9329-g1157d5de35b41eabe5ee51d532224864173c37bd Author: Jakub Jelinek Date: Wed Mar 6 09:35:37 2024 +0100 i386: Fix up the vzeroupper REG_DEAD/REG_UNUSED note workaround [PR114190] When writing

[PATCH] match.pd: Optimize a * !a to 0 [PR114009]

686-linux, ok for trunk? 2024-03-06 Jakub Jelinek PR tree-optimization/114009 * match.pd (a * !a -> 0): New simplification. * gcc.dg/tree-ssa/pr114009.c: New test. --- gcc/match.pd.jj 2024-03-01 14:56:42.442810053 +0100 +++ gcc/match.pd2024-03-05 22:53:25

[PATCH] i386: Fix up the vzeroupper REG_DEAD/REG_UNUSED note workaround [PR114190]

Jakub Jelinek PR rtl-optimization/114190 * config/i386/i386-features.cc (rest_of_handle_insert_vzeroupper): Call df_remove_problem for df_note before calling df_analyze. * gcc.target/i386/avx-pr114190.c: New test. --- gcc/config/i386/i386-features.cc.jj 2024-02

Re: [PATCH] asan: Handle poly-int sizes in ASAN_MARK [PR97696]

On Tue, Mar 05, 2024 at 07:49:21PM +, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Tue, Mar 05, 2024 at 06:30:40PM +, Richard Sandiford wrote: > >> (1) Keep the test where it is, taking advantage of the current SVE > >> handling

Re: [PATCH] asan: Handle poly-int sizes in ASAN_MARK [PR97696]

On Tue, Mar 05, 2024 at 06:30:40PM +, Richard Sandiford wrote: > (1) Keep the test where it is, taking advantage of the current SVE > handling in aarch64-sve.exp, and add: > > /* { dg-skip-if "" { no_fsanitize_address } } */ I'd go with this. asan/ directory for test would be

Re: [PATCH] asan: Handle poly-int sizes in ASAN_MARK [PR97696]

On Tue, Mar 05, 2024 at 06:03:41PM +, Richard Sandiford wrote: > This patch makes the expansion of IFN_ASAN_MARK let through > poly-int-sized objects. The expansion itself was already generic > enough, but the tests for the fast path were too strict. > > Bootstrapped & regression tested on

Re: [PATCH] doc: Fix docs for -dD regarding predefined macros

On Tue, Mar 05, 2024 at 04:16:00PM +, Jonathan Wakely wrote: > OK for trunk? > > Or am I missing something and the docs are right? (sometimes? always?) > > > -- >8 -- > > The manual has always claimed that -dD differs from -dM by not > outputting predefined macros, but that's untrue. It

Re: [PATCH] lower-subreg: Fix ROTATE handling [PR114211]

On Tue, Mar 05, 2024 at 09:29:38AM +0100, Richard Biener wrote: > I wonder if we need to care about extra temporaries on RTL before > RA, thus whether always using a temporary would be OK? I'd still need to do the resolve_reg_p check, otherwise if it is e.g. a memory, the copying to temporary

Re: [PATCH] bitint: Handle BIT_FIELD_REF lowering [PR114157]

On Tue, Mar 05, 2024 at 09:27:22AM +0100, Richard Biener wrote: > On Tue, 5 Mar 2024, Jakub Jelinek wrote: > > The following patch adds support for BIT_FIELD_REF lowering with > > large/huge _BitInt lhs. BIT_FIELD_REF requires mode argument first > > operand, so the operand

[PATCH] lower-subreg: Fix ROTATE handling [PR114211]

temporary pseudo to hold the original (reg:DI 128 [ h+8 ]) value across the first store. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-05 Jakub Jelinek PR rtl-optimization/114211 * lower-subreg.cc (resolve_simple_move): For double-word

[PATCH] bitint: Handle BIT_FIELD_REF lowering [PR114157]

first argument of BIT_FIELD_REF and uses MEM_REF with an offset with VIEW_CONVERT_EXPR around it. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-05 Jakub Jelinek PR middle-end/114157 * gimple-lower-bitint.cc: Include stor-layout.h

[PATCH] combine: Fix recent WORD_REGISTER_OPERATIONS check [PR113010]

paradoxical subregs of non-scalar_int_mode REGs/MEMs and for the scalar_int_mode ones should initialize inner_mode before we use it. Another option would be to use maybe_lt (GET_MODE_PRECISION (GET_MODE (SUBREG_REG (op0))), BITS_PER_WORD) and load_extend_op (GET_MODE (SUBREG_REG (op0))) == ZERO_

Re: [PATCH] vect: Fix integer overflow calculating mask

On Mon, Mar 04, 2024 at 03:30:01PM +, Andrew Stubbs wrote: > vect: Fix integer overflow calculating mask > > The masks and bitvectors were broken when nunits==32 on hosts where int is > 32-bit. > > gcc/ChangeLog: > > * dojump.cc (do_compare_and_jump): Use full-width integers for

[committed] libgomp: Use void (*) (void *) rather than void (*)() for host_fn type [PR114216]

... and as a named argument. Tested on x86_64-linux, committed to trunk. 2024-03-04 Jakub Jelinek PR libgomp/114216 * target.c (gomp_target_rev): Change host_fn type and corresponding cast from void (*)() to void (*) (void *). --- libgomp/target.c.jj 2024-01-03 12:07

[PATCH] bitint: Fix tree node sharing bug [PR114209]

Hi! We ICE on the following testcase due to invalid tree sharing. The second hunk fixes that, the first one is from me looking around at other spots which might need end up with invalid tree sharing too. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-04 Jakub

Re: [PATCH] i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184]

On Mon, Mar 04, 2024 at 09:34:30AM +0100, Uros Bizjak wrote: > > --- gcc/config/i386/i386-expand.cc.jj 2024-03-01 14:56:34.120925989 +0100 > > +++ gcc/config/i386/i386-expand.cc 2024-03-03 18:41:08.278793046 +0100 > > @@ -451,6 +451,20 @@ ix86_expand_move (machine_mode mode, rtx > >

[PATCH] i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184]

that needs it from the scalar ones, others should just be folded. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-04 Jakub Jelinek PR target/114184 * config/i386/i386-expand.cc (ix86_expand_move): If XFmode op1 is SUBREG of CONSTANT_P, force

Re: [Patch] OpenMP/C++: Fix (first)private clause with member variables [PR110347]

On Fri, Mar 01, 2024 at 05:19:29PM +0100, Tobias Burnus wrote: > Jakub Jelinek wrote: > > As discussed on IRC, I believe not disregarding the capture proxies in > > target regions if they shouldn't be shared is always wrong, but also the > > gimplify.cc suggestion was incorrec

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Fri, Mar 01, 2024 at 01:53:08PM +, Richard Earnshaw (lists) wrote: > On 29/02/2024 17:56, Jakub Jelinek wrote: > > On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote: > >> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we

Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests

On Fri, Mar 01, 2024 at 09:29:01AM +0100, Tobias Burnus wrote: > John David Anglin wrote: > > On 2024-02-29 6:02 p.m., Thomas Schwinge wrote: > > > I wonder: shouldn't that cap at 50 threads happen inside libgomp, > > > generally, instead of per test case and user code (!)? > > > > Per my > > >

[PATCH] function: Fix another TYPE_NO_NAMED_ARGS_STDARG_P spot

ence, i.e. this time not all, but the floating point args were conditionally all saved twice. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-01 Jakub Jelinek * function.cc (assign_parms): Only call assign_parms_setup_varargs early for TYPE_NO_NAMED_ARGS_STDARG_P

[PATCH] bitint: Handle VCE from large/huge _BitInt SSA_NAME from load [PR114156]

of preventing the merging gimple_lower_bitint; we'd then copy from memory to memory and and do the vce only on the second one, it is just better to vce the first one. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-01 Jakub Jelinek PR middle-end/114156

[PATCH] c++, v2: Fix up decltype of non-dependent structured binding decl in template [PR92687]

On Thu, Feb 29, 2024 at 12:50:47PM +0100, Jakub Jelinek wrote: > finish_decltype_type uses DECL_HAS_VALUE_EXPR_P (expr) check for > DECL_DECOMPOSITION_P (expr) to determine if it is > array/struct/vector/complex etc. subobject proxy case vs. structured > binding using std::tuple_{

Re: [PATCH] calls: Fix up TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Fri, Mar 01, 2024 at 01:53:54AM -0300, Alexandre Oliva wrote: > On Feb 27, 2024, Richard Earnshaw wrote: > > > This one has been festering for a while; both Alexandre and Torbjorn > > have attempted to fix it recently, but I'm not sure either is really > > right... > > *nod* xref

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote: > Oh, but wait! Perhaps that now falls into the initial 'if' clause and we > never reach the point where you pick zero. So perhaps I'm worrying about > nothing. If you are worried about the + else if

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Thu, Feb 29, 2024 at 05:23:25PM +, Richard Earnshaw (lists) wrote: > On 29/02/2024 15:55, Jakub Jelinek wrote: > > On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote: > >>> I tried the above on arm, aarch64 and x86_64 and that seems fine, > >>&g

Re: [Patch] OpenMP/C++: Fix (first)private clause with member variables [PR110347] [was: [RFA/RFC] C++/OpenMP: Supporting (first)private for member variables [PR110347] - or VALUE_EXPR and gimplify]

On Sat, Feb 17, 2024 at 12:35:48AM +0100, Tobias Burnus wrote: > Hence, I now use this code, but also pass a flag to distinguish target > regions (→ map) from shared usage, assuming that it is needed for the > latter (otherwise, there wouldn't be that code). > > The issue only showed up for a

<    3   4   5   6   7   8   9   10   11   12   >