Re: Go patch committed: Move lowering pass after check types pass

On Mon, Dec 18, 2023 at 5:32 PM Ian Lance Taylor wrote: > > This Go frontend patch moves the lowering pass after the type > determination and the type checking passes. This lets us simplify > some of the code that determines the type of an expression, which > previously had to work correctly

Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]

On Jan 18, 2024, "Kewen.Lin" wrote: > Not sure if I missed something in the testing, could you > kindly double check if those test cases started to fail from r14-6275 on your > env? My guess is that they started to fail when David attempted to bypass the strub tests by changing the dg proc that

Re: [PATCH] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

Thanks! generally LGTM, but I would wait one more week to see any other comments :) On Fri, Jan 19, 2024 at 3:05 PM Monk Chiang wrote: > > Since the match.pd transforms (zero_one == 0) ? y : z y, > into ((typeof(y))zero_one * z) y. Add splitters to recongize > this expression to generate SFB

Re: [PATCH V1] rs6000: New pass for replacement of adjacent (load) lxv with lxvp

On Mon, Jan 15, 2024 at 06:25:13PM +0530, Ajit Agarwal wrote: > Also Mike and Kewwn suggested to use this pass \before IRA register > allocator. They are in To List. They have other concerns doing after > register allocator. > > They have responded in other mail Chain. The problem with doing it

[PATCH] RISC-V: Bugfix for resolve_overloaded_builtin[PR113420]

From: xuli Change the hash value of overloaded intrinsic from considering all parameter types to: 1. Encoding vector data type 2. In order to distinguish vle8_v_i8mf8_m(vbool64_t vm, const int8_t *rs1, size_t vl) and vle8_v_u8mf8_m(vbool64_t vm, const uint8_t *rs1, size_t vl), encode the

[PATCH] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

Since the match.pd transforms (zero_one == 0) ? y : z y, into ((typeof(y))zero_one * z) y. Add splitters to recongize this expression to generate SFB instructions. gcc/ChangeLog: PR target/113095 * config/riscv/sfb.md: New splitters to rewrite single bit sign extension

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

Pushed to trunk :) On Tue, Jan 16, 2024 at 10:33 PM Jeff Law wrote: > > > > On 1/9/24 17:58, Kito Cheng wrote: > > Oops, I should leave more context here: > > > > Actually we discussed that years ago, and most people agree with that, > > but I guess we are just missing that, and also the ISA

[PATCH] testsuite: Disable test for PR113292 on targets without TLS support

Tested on x86_64-pc-linux-gnu using a cross-compiler to arm-unknown-linux-gnueabihf with --enable-threads=0 that the link test is correctly skipped. OK for trunk? -- >8 -- This disables the new test added by r14-8168 on machines that don't have TLS support, such as bare-metal ARM.

Re: [PATCH v2 2/2] LoongArch: When the code model is extreme, the symbol address is obtained through macro instructions regardless of the value of -mexplicit-relocs.

On Wed, 2024-01-17 at 17:57 +0800, chenglulu wrote: > > > Virtual register 1479 will be used in insn 2744, but register 1479 was > > > assigned the REG_UNUSED attribute in the previous instruction. > > > > > > The attached file is the wrong file. > > > The compilation command is as follows: > > >

Re: [PATCH] RISC-V: Bugfix for resolve_overloaded_builtin[PR113420]

Could you add a test for vle with mask? For example: __riscv_vle8 which overload __riscv_vle8_v_i8mf8_m and __riscv_vle8_v_u8mf8_m You are using pointer type and mask type to resolve it. So this pointer type is expecting const int8_t or const uint8_t. Could you add test: 1.__riscv_vle8 (const

Re: [PATCH] riscv: Remove Bool keywords from riscv.opt

OK, thanks :) On Thu, Jan 18, 2024 at 4:17 PM Jakub Jelinek wrote: > > Hi! > > As I wrote recently, Bool is an undocumented unsupported keyword, as > can be seen by > grep Bool doc/options.texi *.awk > The option parsing just parses and ignores all keywords it doesn't handle. > But, because it

[PATCH] riscv: Remove Bool keywords from riscv.opt

Hi! As I wrote recently, Bool is an undocumented unsupported keyword, as can be seen by grep Bool doc/options.texi *.awk The option parsing just parses and ignores all keywords it doesn't handle. But, because it isn't a supported keyword, I think we shouldn't have it in *.opt files, because that

Re: [PATCH] RISC-V: Support vi variant for vec_cmp

LGTM, thanks :) On Thu, Jan 18, 2024 at 5:59 PM Juzhe-Zhong wrote: > > While running various benchmarks, I notice we miss vi variant support for > integer comparison. > That is, we can vectorize code into vadd.vi but we can't vectorize into > vmseq.vi. > > Consider this following case: > >

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

And --- gcc/expr.cc.jj 2024-01-12 10:07:58.194851657 +0100 +++ gcc/expr.cc 2024-01-18 12:08:16.412147569 +0100 @@ -12382,6 +12382,21 @@ expand_expr_real_1 (tree exp, rtx target } } + /* Ensure non-BLKmode array VAR_DECLs VCEd to BLKmode BITINT_TYPE +aren't

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, Jan 18, 2024 at 01:34:53PM +0100, Richard Biener wrote: > So - if we simply do > > /* If the input and output modes are both the same, we are done. */ > if (mode == GET_MODE (op0) || (mode == BLKmode && MEM_P (op0)) > ; > > ? After all if we want BLKmode we want a

Re: [PATCH] libstdc++: add ARM SVE support to std::experimental::simd

On Thursday, 18 January 2024 08:40:48 CET Andrew Pinski wrote: > On Wed, Jan 17, 2024 at 11:28 PM Matthias Kretz wrote: > > template > > struct Point > > { > > T x, y, z; > > > > T distance_to_origin() { > > return sqrt(x * x + y * y + z * z); > > } > > }; > > > > Point is one

Re: [PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.

在 2024/1/18 下午3:44, Xi Ruoyao 写道: On Thu, 2024-01-18 at 15:15 +0800, chenglulu wrote: gcc.dg/tree-ssa/scev-16.c is OK to move gcc.dg/pr104992.c should simply add -fno-tree-vectorize to the used options and remove the vect_* stuff Hi Richard: I have a question. I don't understand the

Re: [PATCH] libstdc++: hashtable: No need to update before begin node in _M_remove_bucket_begin

Yes, I have. I did a benchmark today. The conclusion is: the time consumption can be reduced by 0.4% ~ 1.2% when unordered_set erase(begin()), and 1.2% ~ 2.4% when erase(begin(), end()). My test environment: CPU: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz, 2393.365 MHz, 56 CPUs MEM: 256G OS:

[PATCH] RISC-V: Support vi variant for vec_cmp

While running various benchmarks, I notice we miss vi variant support for integer comparison. That is, we can vectorize code into vadd.vi but we can't vectorize into vmseq.vi. Consider this following case: void foo (int n, int **__restrict a) { int b; int c; int d; for (b = 0; b < n;

[patch,avr,applied] Tabify some files.

The C++ files in the avr backend are a mix of TABS and 8 spaces for indentation. This patch rectifies that according to the coding rules. I applied this prior to the advent of the v14 branch so that back-porting will be easier, at least from the new master to v14. Johann -- gcc/

Re: [PATCH] libstdc++: Update baseline symbols for riscv64-linux

On Thu, Jan 18, 2024 at 01:11:56PM +0100, Rainer Orth wrote: > Andreas Schwab writes: > > > * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. > > Speaking of baselines: is this a good time to update them for other > targets, too, or should we better wait a little longer? I

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, 18 Jan 2024, Jakub Jelinek wrote: > On Thu, Jan 18, 2024 at 01:16:45PM +0100, Richard Biener wrote: > > > This doesn't actually do anything, because the base is TREE_ADDRESSABLE. > > > The var gets both with -O0 and -O2 DECL_RTL like > > > (mem/c:OI (plus:DI (reg/f:DI 95

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, Jan 18, 2024 at 08:27:51AM +0100, Richard Biener wrote: > On Thu, 18 Jan 2024, Jakub Jelinek wrote: > > > Hi! > > > > On aarch64 the backend decides to use non-BLKmode for some arrays > > like unsigned long[4] - OImode in that case, but the corresponding > > BITINT_TYPEs have BLKmode

Re: [COMMITTED] rust_debug: Cast size_t values to unsigned long before printing.

Hi Arthur, > On 18 Jan 2024, at 10:30, Arthur Cohen wrote: > On 1/18/24 10:13, Rainer Orth wrote: >> Arthur Cohen writes: >>> Using %lu to format size_t values breaks 32 bit targets, and %zu is not >>> supported by one of the hosts GCC aims to support - HPUX >> But we do have uses of %zu in

Re: [RFC] Either fix or disable SME feature for `aarch64-w64-mingw32` target?

Are there any further comments or suggestions, please? What needs to be done to merge this change? (Note we don't have merge rights). Thank you. Radek

Re: [PATCH] libstdc++: Update baseline symbols for riscv64-linux

Andreas Schwab writes: > * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. Speaking of baselines: is this a good time to update them for other targets, too, or should we better wait a little longer? Thanks. Rainer --

[PATCH] tree-optimization/113475 - fix memory leak in phi_analyzer

phi_analyzer leaks all phi_group objects it allocates. The following fixes this by maintaining a vector of allocated objects and release them when destroying the phi_analyzer object. Bootstrap and regtest running on x86_64-unknown-linux-gnu. PR tree-optimization/113475 *

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, Jan 18, 2024 at 01:16:45PM +0100, Richard Biener wrote: > > This doesn't actually do anything, because the base is TREE_ADDRESSABLE. > > The var gets both with -O0 and -O2 DECL_RTL like > > (mem/c:OI (plus:DI (reg/f:DI 95 virtual-stack-vars) > > (const_int -64

[COMMITTED] rust_debug: Cast size_t values to unsigned long before printing.

Using %lu to format size_t values breaks 32 bit targets, and %zu is not supported by one of the hosts GCC aims to support - HPUX gcc/rust/ChangeLog: * backend/rust-compile-base.cc (HIRCompileBase::resolve_method_address): Cast size_t value to unsigned long. *

Re: [PATCH] i386: Add -masm=intel profiling support [PR113122]

On Thu, Jan 18, 2024 at 8:31 AM Jakub Jelinek wrote: > > Hi! > > x86_function_profiler emits assembly directly into file and only emits > AT syntax. The following patch adjusts it to emit MASM syntax > if -masm=intel. > As it doesn't use asm_fprintf, I can't use {|} syntax for the dialects. > >

[patch,avr,applied] Minor fixes in device-specs generation

This fixes a typo in the diagnose of a spec. Also re-uses a spec for a simpler specs file. Johann -- AVR: Fix typo in device-specs generation. Reuse -m[no-]rodata-in-ram checker. gcc/ * config/avr/gen-avr-mmcu-specs.cc (diagnose_rodata_in_ram): Fix typo in the diagnostic,

Re: [COMMITTED] rust_debug: Cast size_t values to unsigned long before printing.

Hi Rainer, On 1/18/24 10:13, Rainer Orth wrote: Arthur Cohen writes: Using %lu to format size_t values breaks 32 bit targets, and %zu is not supported by one of the hosts GCC aims to support - HPUX But we do have uses of %zu in gcc/rust already! diff --git

Re: [COMMITTED] rust_debug: Cast size_t values to unsigned long before printing.

Hi Arthur, > Yes, I was talking about this on IRC the other day - if we do run in a > situation where we have more than UINT32_MAX procedural macros in memory > we have big issues. These debug prints will probably end up getting removed > soon as they clutter the output a lot for little

Re: [PATCH] libstdc++: Fix constexpr _Safe_iterator in C++20 mode

On Thu, 18 Jan 2024 at 02:48, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? Please add PR109536 to the commit message. > > -- >8 -- > > Some _Safe_iterator member functions define a variable of non-literal > type __gnu_cxx::__scoped_lock, which

[PATCH] Fix memory leak in vectorizable_store

The following fixes a memory leak in vectorizable_store which happens because the functions populating gvec_oprnds[i] will call .create () on the incoming vector, leaking what we've previously allocated. Bootstrap and regtest running on x86_64-unknown-linux-gnu. * tree-vect-stmts.cc

Re: [COMMITTED] rust_debug: Cast size_t values to unsigned long before printing.

Arthur Cohen writes: > Using %lu to format size_t values breaks 32 bit targets, and %zu is not > supported by one of the hosts GCC aims to support - HPUX But we do have uses of %zu in gcc/rust already! > diff --git a/gcc/rust/expand/rust-proc-macro.cc > b/gcc/rust/expand/rust-proc-macro.cc >

Re: [PATCH v4] RISC-V: Introduce XTheadVector as a subset of V1.0.0

LGTM On Fri, Jan 12, 2024 at 3:32 PM juzhe.zh...@rivai.ai wrote: > > This patch needs kito review. I can't approve that. > > > juzhe.zh...@rivai.ai > > > From: Jun Sha (Joshua) > Date: 2024-01-12 11:20 > To: gcc-patches > CC: jim.wilson.gcc; palmer; andrew;

Re: Add -falign-all-functions

On Wed, 17 Jan 2024, Jan Hubicka wrote: > > On Wed, 17 Jan 2024, Jan Hubicka wrote: > > > > > > > > > > I meant the new option might be named -fmin-function-alignment= > > > > rather than -falign-all-functions because of how it should > > > > override all other options. > > > > > > I was also

[PATCH] Fix memory leak in vect_analyze_loop_form

The following fixes a memory leak in vect_analyze_loop_form which fails to free the loop body it gets. It also allows more countable exits, matching what we can handle later, when we decide which exit to use as main exit. Finally some no longer applying comments are adjusted. Bootstrap and

[wwwdocs] Document new additions to libstdc++

Pushed to wwwdocs. -- >8 -- std::generator, std::format improvements, std::text_encoding. --- htdocs/gcc-14/changes.html | 10 ++ 1 file changed, 10 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 5644de1e..951d005b 100644 ---

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, 18 Jan 2024, Jakub Jelinek wrote: > On Thu, Jan 18, 2024 at 08:27:51AM +0100, Richard Biener wrote: > > On Thu, 18 Jan 2024, Jakub Jelinek wrote: > > > > > Hi! > > > > > > On aarch64 the backend decides to use non-BLKmode for some arrays > > > like unsigned long[4] - OImode in that

Re: [PATCH V1] rs6000: New pass for replacement of adjacent (load) lxv with lxvp

Hello Michael: On 17/01/24 7:58 pm, Michael Matz wrote: > Hello, > > On Wed, 17 Jan 2024, Ajit Agarwal wrote: > >>> first is even, since OOmode is only ok for even vsx register and its >>> size makes it take two consecutive vsx registers. >>> >>> Hi Peter, is my understanding correct? >>> >> >>

[PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]

When generating RMW logical operations on m68k, the backend recognizes single-bit operations and rewrites them as bit instructions on operands adjusted to address the intended byte. When offsetting the addresses the backend keeps the modes as SImode, even though the actual access will be in

[pushed] Fix ICE in -fdiagnostics-generate-patch [PR112684]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-8255-ge254d1224df306. gcc/ChangeLog: PR middle-end/112684 * toplev.cc (toplev::main): Don't ICE in -fdiagnostics-generate-patch when exiting after options, since no edit context

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 1/17/24 20:53, Greg McGary wrote: On Tue, Jan 16, 2024 at 11:44 PM Richard Biener mailto:richard.guent...@gmail.com>> wrote: > On Tue, Jan 16, 2024 at 11:20 PM Greg McGary > wrote: > > > > The sign bit of a sign-extending load cannot be known until

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, Jan 18, 2024 at 01:57:49PM +0100, Richard Biener wrote: > > - RTL expansion expectes TARGET_MEM_REF to always address actual > > memory. */ > > + RTL expansion expectes TARGET_MEM_REF to always address actual memory. > > + Also, force to stack non-BLKmode vars accessed

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, Jan 18, 2024 at 02:13:55PM +0100, Jakub Jelinek wrote: > The == BITINT_TYPE check is non-essential, was just trying to keep existing > behavior otherwise. I can certainly drop that. So following then? 2024-01-18 Jakub Jelinek Richard Biener * cfgexpand.cc

Re: [PATCH] libstdc++: Fix constexpr _Safe_iterator in C++20 mode

On Thu, 18 Jan 2024 at 13:51, Patrick Palka wrote: > > On Thu, 18 Jan 2024, Jonathan Wakely wrote: > > > On Thu, 18 Jan 2024 at 02:48, Patrick Palka wrote: > > > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > > > Please add PR109536 to the commit message. > > Done. > > > >

[pushed] Objective-C/C++: Ensure sufficient setup for the preprocessor.

This is a regression fix where non-trivial Objective-C parses would ICE when given -save-temps (ICE in the lexer). This is a short-term fix for stage-4. ISTM that we should not really be making use of these functions in lexing and hopefully in GCC-15 we can take a look at moving the

Re: HELP: Questions on unshare_expr

> On Jan 17, 2024, at 1:43 AM, Richard Biener > wrote: > > On Wed, Jan 17, 2024 at 7:42 AM Richard Biener > wrote: >> >> On Tue, Jan 16, 2024 at 9:26 PM Qing Zhao wrote: >>> >>> >>> On Jan 15, 2024, at 4:31 AM, Richard Biener wrote: > All my questions for

[PATCH v3] Fix __builtin_nested_func_ptr_{created, deleted} symbol versions [PR113402]

In order to regularise the two new builtins as extension library types the scope of this patch has grown w.r.t "just rename". Tested on x86_64-darwin21 (default heap trampolines) and x86_64 Linux and other Darwin platforms that are default executable stack. How does this look now? thanks Iain

[PATCH] Another memory leak in vectorizable_store

Similar to the last one. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * tree-vect-stmts.cc (vectorizable_store): Do not pre-allocate operands vector. --- gcc/tree-vect-stmts.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v2] c++: side effect in nullptr_t conversion fix

[PATCH v3] c++: side effect in nullptr_t conversion fix Hi, > This seems to assume that a CONVERT_EXPR can't have any other > side-effects nested in it. > > It seems to me a better approach is the one in keep_unused_object_arg > and cp_gimplify_expr, basically > > if (TREE_THIS_VOLATILE (e)) >

[pushed] analyzer: fix offsets in has_null_terminator [PR112811]

PR analyzer/112811 reports an ICE attempting to determine whether a string is null-terminated. The root cause is confusion in the code about whether byte offsets are relative to the start of the base region, or relative to the bound fragment within the the region. This patch rewrites the code to

[pushed] analyzer: fix ICE on strlen ((char *)_CST) [PR111361]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Successful run of analyzer integration tests on x86_64-pc-linux-gnu. Pushed to trunk as r14-8257-gd5604febcfb094. gcc/analyzer/ChangeLog: PR analyzer/111361 * region-model.cc (svalue_byte_range_has_null_terminator_1):

[pushed] Darwin, configure: Handle a missing substitution.

Tested on x86_64 Darwin21 (has default rpath) and i686 darwin9 and x86_64 Linux (no @rpath), pushed to trunk, thanks, Iain --- 8< --- The configure substitution for enable_darwin_at_rpath has been omitted, which leads to a failure to set ENABLE_DARWIN_AT_RPATH in the testsuite site.exp (which

[committed] libstdc++: Fix std::format test for Solaris [PR113450]

Tested x86_64-linux. Pushed to trunk. -- >8 -- When int8_t is a typedef for char (rather than signed char) this test fails because it tries to format a char, which is treated differently from formatting other integral types (including signed char). Use signed char explicitly so the result

[committed] libstdc++: Avoid -Wmaybe-uninitialized warnings in text_encoding.cc

Tested x86_64-linux. Pushed to trunk. -- >8 -- These variables are only read from if we haven't reached the end of either range, in which case they're guaranteed to be initialized to the next alphanumeric character. But we can just initialize them to make the compiler happy.

Re: [PATCH] libstdc++: Fix constexpr _Safe_iterator in C++20 mode

On Thu, 18 Jan 2024, Jonathan Wakely wrote: > On Thu, 18 Jan 2024 at 02:48, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > Please add PR109536 to the commit message. Done. > > > > > > > -- >8 -- > > > > Some _Safe_iterator member functions

[pushed] Darwin: Fix a typo in Objective-C meta-data.

Tested on i686, powerpc, x86_64 Darwin, x86_64 Linux, pushed to trunk, thanks, Iain --- 8< --- We have a typo in the metadata for assigning NSStrings to a specific section for the V1 (32b) ABI. When that is fixed we should never see the case where the section needs to be deduced from the

Re: [PATCH v3] Fix __builtin_nested_func_ptr_{created,deleted} symbol versions [PR113402]

On Thu, Jan 18, 2024 at 02:59:23PM +, Iain Sandoe wrote: > --- a/gcc/builtins.cc > +++ b/gcc/builtins.cc > @@ -8416,6 +8416,11 @@ expand_builtin (tree exp, rtx target, rtx subtarget, > machine_mode mode, > case BUILT_IN_ADJUST_DESCRIPTOR: >return expand_builtin_adjust_descriptor

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, 18 Jan 2024, Jakub Jelinek wrote: > On Thu, Jan 18, 2024 at 01:34:53PM +0100, Richard Biener wrote: > > So - if we simply do > > > > /* If the input and output modes are both the same, we are done. */ > > if (mode == GET_MODE (op0) || (mode == BLKmode && MEM_P (op0)) > >

Re: [PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.

在 2024/1/18 下午4:49, chenglulu 写道: 在 2024/1/18 下午3:44, Xi Ruoyao 写道: On Thu, 2024-01-18 at 15:15 +0800, chenglulu wrote: gcc.dg/tree-ssa/scev-16.c is OK to move gcc.dg/pr104992.c should simply add -fno-tree-vectorize to the used options and remove the vect_* stuff Hi Richard: I have a

Re: [PATCH] hwasan: Check if Intel LAM_U57 is enabled

On Wed, Jan 17, 2024 at 8:51 PM Hongtao Liu wrote: > > On Wed, Jan 10, 2024 at 12:47 AM H.J. Lu wrote: > > > > When -fsanitize=hwaddress is used, libhwasan will try to enable LAM_U57 > > in the startup code. Update the target check to enable hwaddress tests > > if LAM_U57 is enabled. Also

Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode

On Thu, 18 Jan 2024, Jakub Jelinek wrote: > On Thu, Jan 18, 2024 at 02:13:55PM +0100, Jakub Jelinek wrote: > > The == BITINT_TYPE check is non-essential, was just trying to keep existing > > behavior otherwise. I can certainly drop that. > > So following then? OK. Thanks, Richard. >

[pushed] Darwin: Fix constant CFString code-gen [PR105522].

@Richi, @Andrew - FIO since you were involved in the IRC discussion. Tested on i686, powerpc, x86_64 Darwin (and x86_64 Linux), pushed to trunk, thanks, Iain --- 8< --- Although this only fires for one of the Darwin sub-ports, it is latent elsewhere, it is also a regression c.f. the Darwin

[pushed] Darwin: Suppress adding embedded rpaths for earlier OS versions.

The current setup leads to spurious test fails, where we are building for macOS 10.4 or earlier. Tested on x86_64, i868, powerpc Darwin, x86_64 Linux, pushed to trunk, thanks Iain --- 8< --- When we have @rpath support by virtue of the OS version we're hosting on we still need to omit those

Re: [PATCH v5] RISC-V: Support XTheadVector extension

On Fri, Jan 12, 2024 at 4:18 AM Jun Sha (Joshua) wrote: > > This patch series presents gcc implementation of the XTheadVector > extension [1]. > > [1] https://github.com/T-head-Semi/thead-extension-spec/ > > For some vector patterns that cannot be avoided, we use > "!TARGET_XTHEADVECTOR" to

[PATCH] hwasan: Always set target_hwasan_flags

Fix the "make check" error: Running .../gcc/testsuite/gcc.dg/hwasan/hwasan.exp ... ERROR: tcl error sourcing .../gcc/testsuite/gcc.dg/hwasan/hwasan.exp. ERROR: tcl error code TCL LOOKUP VARNAME target_hwasan_flags ERROR: can't read "target_hwasan_flags": no such variable ... on non-x86-64

[COMMITTED] Restore documentation for const/volatile functions [PR107942]

In r5-7698-g8648c55f3b703a I accidentally removed the documentation of GCC's special interpretation of const/volatile qualifiers on functions from the function attributes section, thinking this was just a bit-rotten leftover from old versions of GCC. PR107942 points out that this functionality is

[PATCH] Remove remnant of removed Cygwin options from invoke.texi [PR108521]

From: Brian Inglis The -mcygwin option for x86 Windows was removed in 2010 by commit 3edeb30d044a4852881c34229e618b34f95b0d9e, but this reference was overlooked. gcc/ChangeLog PR target/108521 * doc/invoke.texi (Option Summary): Remove -mcygwin and -mno-cygwin from x86

Re: [COMMITTED] rust_debug: Cast size_t values to unsigned long before printing.

Hi Rainer, On 1/18/24 10:34, Rainer Orth wrote: Hi Arthur, Yes, I was talking about this on IRC the other day - if we do run in a situation where we have more than UINT32_MAX procedural macros in memory we have big issues. These debug prints will probably end up getting removed soon as they

Re: [PATCH] Remove remnant of removed Cygwin options from invoke.texi [PR108521]

On 1/18/24 12:41, Sandra Loosemore wrote: From: Brian Inglis The -mcygwin option for x86 Windows was removed in 2010 by commit 3edeb30d044a4852881c34229e618b34f95b0d9e, but this reference was overlooked. gcc/ChangeLog PR target/108521 * doc/invoke.texi (Option Summary): Remove

[middle-end PATCH] Prefer PLUS over IOR in RTL expansion of multi-word shifts/rotates.

This patch tweaks RTL expansion of multi-word shifts and rotates to use PLUS rather than IOR for disjunctive operations. During expansion of these operations, the middle-end creates RTL like (X<>C2) where the constants C1 and C2 guarantee that bits don't overlap. Hence the IOR can be performed

Re: [COMMITTED] rust_debug: Cast size_t values to unsigned long before printing.

Hi Iain, On 1/18/24 12:02, Iain Sandoe wrote: Hi Arthur, On 18 Jan 2024, at 10:30, Arthur Cohen wrote: On 1/18/24 10:13, Rainer Orth wrote: Arthur Cohen writes: Using %lu to format size_t values breaks 32 bit targets, and %zu is not supported by one of the hosts GCC aims to support -

Re: [PATCH] Pass GUILE down to subdirectories

Andrew> This change is causing some problems for me. Yeah, Tom de Vries as well. Andrew> One of my build machines has 2 versions of guile installed. One is Andrew> guile 2.0.14 and the other is guile 2.2.21. Andrew> When GDB configures itself the configure script figures out that it Andrew>

[COMMITTED] Improve documentation of noinline and noipa attributes [PR108470]

gcc/ChangeLog PR ipa/108470 * doc/extend.texi (Common Function Attributes): Document that noinline also disables some interprocedural optimizations and improve flow to the part about using inline asm instead to disable calls from being optimized away

[PATCH] aarch64: Fix __builtin_apply with -mgeneral-regs-only [PR113486]

The problem here is the builtin apply mechanism thinks the FP registers are to be used due to get_raw_arg_mode not returning VOIDmode. This fixes that oversight and the backend now returns VOIDmode for non-general-regs if TARGET_GENERAL_REGS_ONLY is true. Built and tested for aarch64-linux-gnu

[r14-8206 Regression] FAIL: gfortran.dg/forall_1.f90 -O3 -g (test for excess errors) on Linux/x86_64

On Linux/x86_64, 0f3880d6ad0e40c4a8b6d94b2c93931cdf42 is the first bad commit commit 0f3880d6ad0e40c4a8b6d94b2c93931cdf42 Author: Richard Biener Date: Wed Jan 17 13:24:22 2024 +0100 tree-optimization/113374 - early break vect and virtual operands caused FAIL:

[PATCH] Fix testcase failure on many platforms which don't support vect_int_max.

After r14-7124-g6686e16fda4190, the testcase can be optimized to MAX_EXPR if the backends support that. So I adjust the testcase to scan for MAX_EXPR, but it failed many platforms which don't support that. As pinski mentioned, target vect_no_int_min_max is only available under vect directory, so

[COMMITTED] More precise documentation for cleanup attribute [PR110029]

gcc/ChangeLog PR c/110029 * doc/extend.texi (Common Variable Attributes): Explain what happens when multiple variables with cleanups are in the same scope. --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi

[PATCH] RISC-V:Raname UNSPEC_CLMUL in vector-crypto.md

UNSPEC_CLMUL is defined to define_c_enum in riscv.md, so it shouldn't be redefined to define_int_iterator again. *gcc/ChangeLog:* * config/riscv/vector-crypto.md (UNSPEC_CLMUL): Rename to UNSPEC_CLMUL_VC. 0001-RISC-V-Raname-UNSPEC_CLMUL-in-vector-crypto.md.patch Description: Binary data

[PATCH] RISC-V: Tweak the wording for the sorry message

Use "does not" rather than "cannot", because it's implementation issue. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_override_options_internal): Tweak sorry message. --- gcc/config/riscv/riscv.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] RISC-V: Tweak the wording for the sorry message

OK juzhe.zh...@rivai.ai From: Kito Cheng Date: 2024-01-19 10:34 To: rep.dot.nop; jeffreyalaw; rdapp.gcc; juzhe.zhong; gcc-patches CC: Kito Cheng Subject: [PATCH] RISC-V: Tweak the wording for the sorry message Use "does not" rather than "cannot", because it's implementation issue.

Re: [PATCH] RISC-V:Raname UNSPEC_CLMUL in vector-crypto.md

Thanks, pushed to trunk :) On Fri, Jan 19, 2024 at 10:30 AM KuanLin Chen wrote: > > UNSPEC_CLMUL is defined to define_c_enum in riscv.md, so > it shouldn't be redefined to define_int_iterator again. > > gcc/ChangeLog: > > * config/riscv/vector-crypto.md (UNSPEC_CLMUL): Rename to

Re: [PATCH] RISC-V: Tweak the wording for the sorry message

Thanks, pushed to trunk :) On Fri, Jan 19, 2024 at 10:36 AM juzhe.zh...@rivai.ai wrote: > > OK > > > juzhe.zh...@rivai.ai > > > From: Kito Cheng > Date: 2024-01-19 10:34 > To: rep.dot.nop; jeffreyalaw; rdapp.gcc; juzhe.zhong; gcc-patches > CC: Kito Cheng >

[PATCH] Adjust testcase gcc.target/i386/part-vect-copysignhf.c.

After vect_early_break is supported, more vectorization is enabled(3 COPYSIGN), so adjust testcase for that. Commit as obvious fix. gcc/testsuite/ChangeLog: * gcc.target/i386/part-vect-copysignhf.c: Remove -ftree-vectorize from dg-options. ---