Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On 1/31/24 14:44, Alex Coplan wrote: Hi Marek, On 30/01/2024 13:15, Marek Polacek wrote: On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: On 1/25/24 20:36, Marek Polacek wrote: Better version: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Real-world exp

Re: [PATCH v3 4/5] Add tests for C/C++ musttail attributes

On Tue, Jan 30, 2024 at 06:17:17PM -0800, Andi Kleen wrote: > Mostly adopted from the existing C musttail plugin tests. Please add a ChangeLog entry. > --- > gcc/testsuite/c-c++-common/musttail1.c | 17 > gcc/testsuite/c-c++-common/musttail2.c | 36 + > gcc

Re: [PATCH v3 1/5] Improve must tail in RTL backend

> This results in "error: cannot tail-call: cannot tail-call: other reasons". > So the second argument should be "other reasons" only. Yes will fix those. Thanks. > > I notice that if I don't use -O2 I also get "other reasons". But it should be > easy-ish to say "cannot tail-call: optimizations

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

On 1/30/24 21:49, Lewis Hyatt wrote: On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote: On 12/5/23 20:52, Lewis Hyatt wrote: Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 There are two related issues here really, a regression since GCC 11 where we can ICE after restor

Re: [PATCH v3 2/5] C++: Support clang compatible [[musttail]] (PR83324)

> > For compatibility it also detects clang::musttail > > FWIW, it's not clear to me we should do this. I don't see a precedent. It would make existing code just work (as long as they don't use ifdef) > > > One problem is that tree-tailcall usually fails when optimization > > is disabled, whic

Re: [PATCH v3 1/5] Improve must tail in RTL backend

On Wed, Jan 31, 2024 at 12:16:59PM -0800, Andi Kleen wrote: > > This results in "error: cannot tail-call: cannot tail-call: other reasons". > > So the second argument should be "other reasons" only. > > Yes will fix those. Thanks. > > > > > I notice that if I don't use -O2 I also get "other reas

Re: [PATCH V4 2/4] RISC-V: Add vector related pipelines

LGTM, thanks. Regards Robin

Re: [PATCH v3 2/5] C++: Support clang compatible [[musttail]] (PR83324)

On Wed, Jan 31, 2024 at 12:21:38PM -0800, Andi Kleen wrote: > > > + case RID_RETURN: > > > + { > > > + bool musttail_p = false; > > > + std_attrs = process_stmt_hotness_attribute (std_attrs, attrs_loc); > > > + if (lookup_attribute ("", "musttail", std_attrs)) > > > + { > > > +

Re: [PATCH] aarch64: libgcc: Cleanup ELF marking in asm

Szabolcs Nagy writes: > Use aarch64-asm.h in asm code consistently, this was started in > > commit c608ada288ced0268c1fd4136f56c34b24d4 > Author: Zac Walker > CommitDate: 2024-01-23 15:32:30 + > > Ifdef `.hidden`, `.type`, and `.size` pseudo-ops for `aarch64-w64-mingw32` > ta

Re: [PATCH] aarch64: -mstrict-align vs __arm_data512_t [PR113657]

Andrew Pinski writes: > After r14-1187-gd6b756447cd58b, simplify_gen_subreg can return > NULL for "unaligned" memory subreg. Since V8DI has an alignment of 8 bytes, > using TImode causes simplify_gen_subreg to return NULL. > This fixes the issue by using DImode instead for the loop. And then we wi

Re: [PATCH] aarch64: Fix ICE in poly-int.h due to SLP.

Richard Ball writes: > Hi Prathamesh, > > Thanks for the review, I missed that code up above. > I've looking into this and it seems to me at least, that what you have > suggested, is equivalent. > I'll make the change and repost. The original patch is OK. Checking in the other loop is too early,

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On Wed, Jan 31, 2024 at 07:44:41PM +, Alex Coplan wrote: > Hi Marek, > > On 30/01/2024 13:15, Marek Polacek wrote: > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: > > > On 1/25/24 20:36, Marek Polacek wrote: > > > > Better version: > > > > > > > > Bootstrapped/regtested on

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On Wed, Jan 31, 2024 at 02:57:09PM -0500, Jason Merrill wrote: > On 1/31/24 14:44, Alex Coplan wrote: > > Hi Marek, > > > > On 30/01/2024 13:15, Marek Polacek wrote: > > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: > > > > On 1/25/24 20:36, Marek Polacek wrote: > > > > > Better

Re: [PATCH] c++: ttp CTAD equivalence [PR112737]

On Wed, 31 Jan 2024, Jason Merrill wrote: > On 1/31/24 12:12, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > trunk? > > > > -- >8 -- > > > > Here during declaration matching we undesirably consider the two TT{42} > > CTAD expressions to be n

Re: [PATCH] c++: ttp CTAD equivalence [PR112737]

On Wed, 31 Jan 2024, Patrick Palka wrote: > On Wed, 31 Jan 2024, Jason Merrill wrote: > > > On 1/31/24 12:12, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > > trunk? > > > > > > -- >8 -- > > > > > > Here during declaration matching we und

[RFC PATCH 0/1] Nix Environment Support for GCC Development

I am writing to submit a revision of a patch for consideration to be included in the mainline GCC repository discussed in [1]. The only change is that this include the following suggestion [2] [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639235.html [2] https://gcc.gnu.org/piperma

[committed] c: Fix ICE for nested enum redefinitions with/without fixed underlying type [PR112571]

Bug 112571 reports an ICE-on-invalid for cases where an enum is defined, without a fixed underlying type, inside the enum type specifier for a definition of that same enum with a fixed underlying type. The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a case where it is NULL. Avo

[RFC PATCH 1/1] nix: add a simple flake nix shell

This commit is specifically targeting enhancements in Nix support for GCC development. This initiative stems from the recognized need within our community for a more streamlined and efficient development process when using Nix. Please not that in this case the Nix tool is used to define what shoul

Re: [PATCH v3 2/5] C++: Support clang compatible [[musttail]] (PR83324)

On Wed, 31 Jan 2024, Jakub Jelinek wrote: > On Wed, Jan 31, 2024 at 12:21:38PM -0800, Andi Kleen wrote: > > > > + case RID_RETURN: > > > > + { > > > > + bool musttail_p = false; > > > > + std_attrs = process_stmt_hotness_attribute (std_attrs, > > > > attrs_loc);

Re: [PATCH 2/2] libstdc++: Implement P2165R4 changes to std::pair/tuple/etc

On Wed, 31 Jan 2024 at 19:41, Patrick Palka wrote: > > On Wed, 31 Jan 2024, Patrick Palka wrote: > > > On Wed, 24 Jan 2024, Patrick Palka wrote: > > > > > > In v2: > > > > > > * Named the template parameters of the forward declaration of pair. > > > * Added dangling checks for the new tuple and pa

Re: [RFC PATCH 1/1] nix: add a simple flake nix shell

On 1/31/24 4:43 PM, Vincenzo Palazzo wrote: > This commit is specifically targeting enhancements in > Nix support for GCC development. This initiative stems > from the recognized need within our community for a more > streamlined and efficient development process when using Nix. > > Please not tha

[pushed] analyzer: fix skipping of debug stmts [PR113253]

PR analyzer/113253 reports a case where the analyzer output varied with and without -g enabled. The root cause was that debug stmts were in the FOR_EACH_IMM_USE_FAST list for SSA names, leading to the analyzer's state purging logic differing between the -g and non-debugging cases, and thus leading

Re: [Bug libstdc++/90276] PSTL tests fail in Debug Mode

On Wed, 31 Jan 2024 at 18:18, François Dumont wrote: > I replied to bugzilla rather than sending to proper mailing list ! > > At the same time it looks like you also found the root cause of the > problem Jonathan. Just let me know if you want to deal with it eventually. > I'll take care of it, t

[PATCH] c++: ICE with throw inside concept [PR112437]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13/12? -- >8 -- We crash in the loop at the end of treat_lvalue_as_rvalue_p for code like template concept Throwable = requires(T x) { throw x; }; because the code assumes that we eventually reach sk_function_parms or sk_try and ba

[COMMITTEDv2] aarch64: -mstrict-align vs __arm_data512_t [PR113657]

After r14-1187-gd6b756447cd58b, simplify_gen_subreg can return NULL for "unaligned" memory subreg. Since V8DI has an alignment of 8 bytes, using TImode causes simplify_gen_subreg to return NULL. This fixes the issue by using DImode instead for the loop. And then we will have later on the STP/LDP pa

Re: [PATCH] RISC-V: Allow constraint "S" even if the symbol does not bind locally

On Tue, Jan 30, 2024 at 11:26 PM Kito Cheng wrote: > > I realized there is 's' constraint which is defined in GCC generic > infra[1], and that's kinda what same as the new semantic of 'S' here, > > (define_constraint "s" > "Matches a symbolic integer constant." > (and (match_test "CONSTANT_P (op

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

On 1/25/2024 9:06 AM, Robin Dapp wrote: LGTM, thanks. Regards Robin Committed! Edwin

Re: [COMMITTED V3 3/4] RISC-V: Use default cost model for insn scheduling

On 1/25/2024 9:06 AM, Robin Dapp wrote: Use default cost model scheduling on these test cases. All these tests introduce scan dump failures with -mtune generic-ooo. Since the vector cost models are the same across all three tunes, some of the tests in PR113249 will be fixed with this patch series

Re: [COMMITTED V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation

On 1/25/2024 9:06 AM, Robin Dapp wrote: /* If we ever encounter an insn without an insn reservation, trip an assert so we can find and fix this problem. */ -#if 0 + if (! insn_has_dfa_reservation_p (insn)) { +print_rtl(stderr, insn); +fprintf(stderr, "%d", get_attr_type (insn

Re: [COMMITTED V4 2/4] RISC-V: Add vector related pipelines

On 1/31/2024 12:28 PM, Robin Dapp wrote: LGTM, thanks. Regards Robin Committed! Edwin

Re: [PATCH] RISC-V: Support scheduling for sifive p600 series

I recently committed changes modifying the scheduling reservations. Some things may need to be retested with the newly enabled asserts. Edwin On 1/31/2024 1:40 AM, Monk Chiang wrote: Add sifive p600 series scheduler module. For more information see https://www.sifive.com/cores/performance-p650

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

On Wed, Jan 31, 2024 at 03:18:01PM -0500, Jason Merrill wrote: > On 1/30/24 21:49, Lewis Hyatt wrote: > > On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote: > > > On 12/5/23 20:52, Lewis Hyatt wrote: > > > > Hello- > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 > >

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

On 1/31/24 21:09, Lewis Hyatt wrote: On Wed, Jan 31, 2024 at 03:18:01PM -0500, Jason Merrill wrote: On 1/30/24 21:49, Lewis Hyatt wrote: On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote: On 12/5/23 20:52, Lewis Hyatt wrote: Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105

Re: [PATCH] c++: ICE with throw inside concept [PR112437]

On 1/31/24 18:41, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13/12? OK. -- >8 -- We crash in the loop at the end of treat_lvalue_as_rvalue_p for code like template concept Throwable = requires(T x) { throw x; }; because the code assumes that we e

Re: [PATCH] c++: ttp CTAD equivalence [PR112737]

On 1/31/24 16:03, Patrick Palka wrote: On Wed, 31 Jan 2024, Jason Merrill wrote: On 1/31/24 12:12, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here during declaration matching we undesirably consider the two TT{42} CTAD expres

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On 1/31/24 15:56, Marek Polacek wrote: On Wed, Jan 31, 2024 at 02:57:09PM -0500, Jason Merrill wrote: On 1/31/24 14:44, Alex Coplan wrote: Hi Marek, On 30/01/2024 13:15, Marek Polacek wrote: On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: On 1/25/24 20:36, Marek Polacek wrote:

[COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

Hi, all. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b799a16ae59fc0f508c5931ebf1851a3446b707 https://gcc.gnu.org/gi

Re: [PATCH] RISC-V: Support scheduling for sifive p600 series

Thanks, I will push a V2 patch, to fix the typo and add a vector cost model for p600 series. About block the div units, I decided to use your suggestion. The P600 series divider is 4 bits per cycle. So blocking 3-5 cycles is enough. On Thu, Feb 1, 2024 at 9:50 AM Edwin Lu wrote: > I recently c

[PATCH v2] RISC-V: Support scheduling for sifive p600 series

Add sifive p600 series scheduler module. For more information see https://www.sifive.com/cores/performance-p650-670. Add sifive-p650, sifive-p670 for mcpu option will come in separate patches. gcc/ChangeLog: * config/riscv/riscv.md: Add "fcvt_i2f", "fcvt_f2i" type attribute, and in

[PATCH v2] RISC-V: Support scheduling for sifive p600 series

Hi, Monk. This model doesn't include vector. Will you add vector pipeline in the followup patches ? juzhe.zh...@rivai.ai

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

Hi Juzhe, I didn't see any ICEs when I tested locally (tested on https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8123f3ca3fd891034a8366518e756f161c4ff40d). Can you tell me what config you're using? Edwin On 1/31/2024 6:57 PM, juzhe.zh...@rivai.ai wrote: Hi, all. https://gcc.gnu.org/git/?p=gc

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

From what I know, if it was a problem with my dfa reservation assert, it would have ICEd in riscv.cc and not riscv-v.cc. For now I reverted the changes since I don't want to leave things possibly broken overnight and not knowing which patch is the root cause. I kicked off another set of test ru

Re: Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

Maybe I do the wrong testing. Let me use a clean linux environment and try again. juzhe.zh...@rivai.ai From: Edwin Lu Date: 2024-02-01 14:13 To: juzhe.zh...@rivai.ai; gcc-patches CC: Robin Dapp; kito.cheng; jeffreyalaw; palmer; vineetg; Patrick O'Neill Subject: Re: [COMMITTED V3 1/4] RISC-V:

Re: Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

Oh. Sorry. I think I have done the wrong testing with incremental compilation. With clean trunk, no ICEs now. Just this following FAILs: FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-11.c (test for excess errors) FAIL: gcc.target/riscv/rvv/autovec/unop/vfsqrt-run.c (test for e

Re: Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

Sorry again. I just realized you have reverted your patches that's why I can pass the testing now. I checkout your latest patch commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c Then I can reproduce the ICE now: bug.c: In function 'popcount32_uint6

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: > > > On 31/01/2024 14:35, Richard Biener wrote: > > On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: > > > >> > >> > >> On 31/01/2024 13:58, Richard Biener wrote: > >>> On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: > >>> > > >

Re: [PATCH v3 4/5] Add tests for C/C++ musttail attributes

> This will run the test only once with -std=c++11. We'll get better coverage > with dropping the line above and using > > /* { dg-do compile { target { tail_call && { c || c++11 } } } } */ > > but here it may not matter. The problem is that older C/C++ standards don't support [[]] attributes.

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

"Andre Vieira (lists)" writes: > [...] The question at hand > here is, what can the vectorizer use for a specific loop. If we are > using Advanced SIMD modes then it needs to call an Advanced SIMD clone, > and if we are using SVE modes then it needs to call an SVE clone. At > least until we su

[PATCH] i386: Clear REG_UNUSED and REG_DEAD notes from the IL at the end of vzeroupper pass [PR113059]

Hi! The move of the vzeroupper pass from after reload pass to after postreload_cse helped only partially, CSE-like passes can still invalidate those notes (especially REG_UNUSED) if they use some earlier register holding some value later on in the IL. So, either we could try to move it one pass f

[PATCH] lower-bitint: Fix up VIEW_CONVERT_EXPR handling in handle_operand_addr [PR113639]

Hi! Yet another spot where we need to treat VIEW_CONVERT_EXPR differently from NOP_EXPR/CONVERT_EXPR. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-01-31 Jakub Jelinek PR tree-optimization/113639 * gimple-lower-bitint.cc (bitint_large_huge::handle_

[PATCH] dwarf2out: Fix ICE on large _BitInt in loc_list_from_tree_1 [PR113637]

Hi! This spot uses SCALAR_INT_TYPE_MODE which obviously ICEs for large/huge BITINT_TYPE types which have BLKmode. But such large BITINT_TYPEs certainly don't fit into DWARF2_ADDR_SIZE either, so we can just assume it would be false if type has BLKmode. Bootstrapped/regtested on x86_64-linux and

[PATCH] simplify-rtx: Fix up last argument to simplify_gen_unary [PR113656]

Hi! When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF)) or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into (float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call simplify_gen_unary with incorrect op_mode argument, it should be the argument's mode, but we cal

Re: [PATCH] c++: add deprecation notice for -fconcepts-ts

On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > We plan to deprecate -fconcepts-ts in GCC 15 and remove the flag_concepts_ts > code. This note is an admonishing reminder to convert the Concepts TS > code to C++2

Re: [PATCH RFA] asan: poisoning promoted statics [PR113531]

On Wed, Jan 31, 2024 at 4:38 AM Jason Merrill wrote: > > Tested x86_64-pc-linux-gnu, OK for trunk? It's a quite "late" fixup, I suppose you have tried to avoid marking it during gimplification? I see we do parts of this during BIND_EXPR processing which is indeed a bit early but possibly difficu

Re: About 31109 - gprofng not built and installed in a combined binutils+gcc build

On Wed, Jan 31, 2024 at 4:46 AM Vladimir Mezentsev wrote: > > Hi, > > I asked in https://sourceware.org/bugzilla/show_bug.cgi?id=31109 > > I prepared a patch for the releases/gcc-13 branch. > > Richard Biener rejected my patch for > this branch. > > Which branch should I use? master, trunk or

Re: [PATCH RFA] asan: poisoning promoted statics [PR113531]

On Wed, Jan 31, 2024 at 09:51:05AM +0100, Richard Biener wrote: > On Wed, Jan 31, 2024 at 4:38 AM Jason Merrill wrote: > > > > Tested x86_64-pc-linux-gnu, OK for trunk? > > It's a quite "late" fixup, I suppose you have tried to avoid marking it > during gimplification? I see we do parts of this

Re: [PATCH] lower-bitint: Fix up VIEW_CONVERT_EXPR handling in handle_operand_addr [PR113639]

On Wed, 31 Jan 2024, Jakub Jelinek wrote: > Hi! > > Yet another spot where we need to treat VIEW_CONVERT_EXPR differently > from NOP_EXPR/CONVERT_EXPR. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK > 2024-01-31 Jakub Jelinek > > PR tree-optimization/1136

Re: [PATCH] dwarf2out: Fix ICE on large _BitInt in loc_list_from_tree_1 [PR113637]

On Wed, 31 Jan 2024, Jakub Jelinek wrote: > Hi! > > This spot uses SCALAR_INT_TYPE_MODE which obviously ICEs for large/huge > BITINT_TYPE types which have BLKmode. But such large BITINT_TYPEs certainly > don't fit into DWARF2_ADDR_SIZE either, so we can just assume it would be > false if type ha

Re: [PATCH] simplify-rtx: Fix up last argument to simplify_gen_unary [PR113656]

On Wed, 31 Jan 2024, Jakub Jelinek wrote: > Hi! > > When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF)) > or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into > (float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call > simplify_gen_unary with incorrect op_mode

[PATCH] tree-optimization/113670 - gather/scatter to/from hard registers

The following makes sure we're not taking the address of hard registers when vectorizing appearant gathers or scatters to/from them. Bootstrapped and tested on x86_64-unkown-linux-gnu, pushed. PR tree-optimization/113670 * tree-vect-data-refs.cc (vect_check_gather_scatter):

Re: [PATCH] aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

Alex Coplan writes: > Hi, > > The PR shows us ICEing due to an unrecognizable TFmode save emitted by > aarch64_process_components. The problem is that for T{I,F,D}mode we > conservatively require mems to be in range for x-register ldp/stp. That > is because (at least for TImode) it can be alloca

Re: [PATCH][GCC 13] aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

Alex Coplan writes: > Bootstrapped/regtested on aarch64-linux-gnu, OK for the 13 branch after > a week of the trunk fix being in? OK for the other active branches if > the same changes test cleanly there? > > GCC 14 patch for reference: > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644

Re: [PATCH] libstdc++: Enable std::text_encoding for darwin and FreeBSD

Hi Jonathan, > On 30 Jan 2024, at 15:02, Jonathan Wakely wrote: > > This should fix the std/text_encoding/* FAILs that Iain sees on darwin. > I assume it will make it work for FreeBSD too. > > I won't push this until I hear it works for at least one of those. It works on x86_64-darwin{19,21,23

[PATCH] RISC-V: Support scheduling for sifive p600 series

Add sifive p600 series scheduler module. For more information see https://www.sifive.com/cores/performance-p650-670. Add sifive-p650, sifive-p670 for mcpu option will come in separate patches. gcc/ChangeLog: * config/riscv/riscv.md: Add "fcvt_i2f", "fcvt_f2i" type attribute, and in

[committed] libstdc++: Fix -Wshift-count-overflow warning in std::bitset

Tested x86_64-linux and aarch64-linux. Pushed to trunk. -- >8 -- This shift only happens if the unsigned long long type is wider than unsigned long but the compiler warns when it sees the shift, without caring if it's reachable. Use the preprocessor to compare the sizes and just reuse _M_to_ulon

[committed] libstdc++: Add all supported headers to lists in the manual

Another piece of the manual that needs to be kept up to date as we add features. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * doc/xml/manual/using.xml: Update tables of supported headers. * doc/html/*: Regenerate. --- libstdc++-v3/doc/html/manual/index.html | 2 +

[committed] libstdc++: Add "ASCII" as an alias for std::text_encoding::id::ASCII

SG16 (Unicode and Text Study Group) and LWG are overwhelmingly in favour of adding this alias, so let's not wait for the issue to get voted into the working draft. Tested aarch64-linux. Pushed to trunk. -- >8 -- As noted in LWG 4043, "ASCII" is not an alias for any known registered character enc

Re: [PATCH] libstdc++: Enable std::text_encoding for darwin and FreeBSD

On Wed, 31 Jan 2024 at 09:38, Iain Sandoe wrote: > > Hi Jonathan, > > > On 30 Jan 2024, at 15:02, Jonathan Wakely wrote: > > > > This should fix the std/text_encoding/* FAILs that Iain sees on darwin. > > I assume it will make it work for FreeBSD too. > > > > I won't push this until I hear it work

Re: [PATCH V2] rs6000: New pass for replacement of adjacent loads fusion (lxv).

Hello Alex: Thanks for your valuable review comments. I am incorporating the comments and would send the patch with rs6000 and AARCH64 changes. Thanks & Regards Ajit On 24/01/24 10:13 pm, Alex Coplan wrote: > Hi Ajit, > > On 21/01/2024 19:57, Ajit Agarwal wrote: >> >> Hello All: >> >> New pass

GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'

Hi! OK to push "GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'", see attached? In pre-RDNA 3 ISA manuals, there are notes for 'DS_CMPST_[...]', like: Caution, the order of src and cmp are the *opposite* of the BUFFER_ATOMIC_CMPSWAP opcode. ..., and conversely in the RDNA 3 ISA manual

[PATCH] gimple-fold: Remove .ASAN_MARK calls on TREE_STATIC variables [PR113531]

On Wed, Jan 31, 2024 at 10:07:28AM +0100, Jakub Jelinek wrote: > Indeed. But what we could do is try to fold_stmt those .ASAN_MARK calls > away earlier (but sure, the asan.cc change would be still required because > that would be just an optimization). But that can be handled incrementally, > so

Re: GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'

On 31/01/2024 10:36, Thomas Schwinge wrote: Hi! OK to push "GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'", see attached? In pre-RDNA 3 ISA manuals, there are notes for 'DS_CMPST_[...]', like: Caution, the order of src and cmp are the *opposite* of the BUFFER_ATOMIC_CMPSWAP opcode

[PATCH] tree-optimization/113630 - invalid code hoisting

The following avoids code hoisting (but also PRE insertion) of expressions that got value-numbered to another one that are not a valid replacement (but still compute the same value). This time because the access path ends in a structure with different size, meaning we consider a related access as

Re: [PATCH] LoongArch: Fix soft-float builds of libffi

On Sat, 2024-01-27 at 15:09 +0800, Yang Yujie wrote: > This patch correspond to the upstream PR: > https://github.com/libffi/libffi/pull/817 > > libffi/ChangeLog: > > * src/loongarch64/ffi.c: Avoid defining floats > in struct call_context if the ABI is soft-float. You need to wait un

[PATCH] match: Fix vcond into conditional op folding [PR113607].

Hi, in PR113607 we see an invalid fold of _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0, ... }); vect_prephitmp_129.51_282 = _429; vect_iftmp.55_287 = VEC_COND_EXPR ; to Applying pattern match.pd:9607, gimple-match-10.cc:3817 gimple_simplified to vect_iftm

[PATCH] libgcc: Fix up i386/t-heap-trampoline [PR113403]

On Sun, Jan 28, 2024 at 02:07:32PM +, Iain Sandoe wrote: > --- a/libgcc/config/aarch64/t-heap-trampoline > +++ b/libgcc/config/aarch64/t-heap-trampoline > @@ -16,4 +16,5 @@ > # along with GCC; see the file COPYING3. If not see > # . > > -LIB2ADD += $(srcdir)/c

[PATCH] libgcc: Avoid warnings on __gcc_nested_func_ptr_created [PR113402]

On Sun, Jan 28, 2024 at 11:02:33AM +, Iain Sandoe wrote: > * config/aarch64/heap-trampoline.c: Rename > __builtin_nested_func_ptr_created to __gcc_nested_func_ptr_created and > __builtin_nested_func_ptr_deleted to __gcc_nested_func_ptr_deleted. > * config/i386/heap-tramp

Re: [PATCH] gimple-fold: Remove .ASAN_MARK calls on TREE_STATIC variables [PR113531]

On Wed, Jan 31, 2024 at 12:18 PM Jakub Jelinek wrote: > > On Wed, Jan 31, 2024 at 10:07:28AM +0100, Jakub Jelinek wrote: > > Indeed. But what we could do is try to fold_stmt those .ASAN_MARK calls > > away earlier (but sure, the asan.cc change would be still required because > > that would be jus

Re: [PATCH] match: Fix vcond into conditional op folding [PR113607].

On Wed, Jan 31, 2024 at 12:50 PM Robin Dapp wrote: > > Hi, > > in PR113607 we see an invalid fold of > > _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0, > ... }); > vect_prephitmp_129.51_282 = _429; > vect_iftmp.55_287 = VEC_COND_EXPR vect_prephitmp_129.51_282, v

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

On Tue, 30 Jan 2024, Andre Vieira wrote: > > This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the > target can reject a simd_clone based on the vector mode it is using. > This is needed because for VLS SVE vectorization the vectorizer accepts > Advanced SIMD simd clones when

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

On Wed, 31 Jan 2024, Richard Biener wrote: > On Tue, 30 Jan 2024, Andre Vieira wrote: > > > > > This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the > > target can reject a simd_clone based on the vector mode it is using. > > This is needed because for VLS SVE vectorization

Re: [PATCH 2/3] vect: disable multiple calls of poly simdclones

On Tue, 30 Jan 2024, Andre Vieira wrote: > > The current codegen code to support VF's that are multiples of a simdclone > simdlen rely on BIT_FIELD_REF to create multiple input vectors. This does not > work for non-constant simdclones, so we should disable using such clones when > the VF is a mu

[COMMITTED] testsuite: Require ucn in g++.dg/cpp0x/udlit-extended-id-1.C

g++.dg/cpp0x/udlit-extended-id-1.C FAILs on Solaris/SPARC and x86 with the native assembler: UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++14 compilation failed to produce executable FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 (test for excess errors) UNRESOLVED: g++.dg/cpp0x/u

Re: [PATCH v3 4/5] Add tests for C/C++ musttail attributes

On Wed, 31 Jan 2024 at 07:49, Andi Kleen wrote: > > Mostly adopted from the existing C musttail plugin tests. > --- > gcc/testsuite/c-c++-common/musttail1.c | 17 > gcc/testsuite/c-c++-common/musttail2.c | 36 + > gcc/testsuite/c-c++-common/musttail3.c | 31

[PATCH] tree-optimization/111444 - avoid insertions when skipping defs

The following avoids inserting expressions for IPA CP discovered equivalences into the VN hashtables when we are optimistically skipping may-defs in the attempt to prove it's redundant. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/111444 * tree

[PATCH] testsuite: i386: Disable .eh_frame in gcc.target/i386/auto-init-5.c etc.

The gcc.target/i386/auto-init-5.c and gcc.target/i386/auto-init-6.c tests FAIL on 64-bit Solaris/x86 with the native assembler: FAIL: gcc.target/i386/auto-init-5.c scan-assembler-times .long\\t0 14 FAIL: gcc.target/i386/auto-init-6.c scan-assembler-times long\\t0 8 /bin/as doesn't fully suppo

Re: [PATCH] RISC-V: Support scheduling for sifive p600 series

> + NULL, /* vector cost */ > +}; Does the P600 series include a vector unit? From what I found on the web it looks like it. If so I would suggest specifying at least the default (generic) vector cost model here. We fall back to the default one for

Re: [PATCH] testsuite: i386: Disable .eh_frame in gcc.target/i386/auto-init-5.c etc.

On Wed, Jan 31, 2024 at 01:50:33PM +0100, Rainer Orth wrote: > The gcc.target/i386/auto-init-5.c and gcc.target/i386/auto-init-6.c > tests FAIL on 64-bit Solaris/x86 with the native assembler: > > FAIL: gcc.target/i386/auto-init-5.c scan-assembler-times .long\\t0 14 > FAIL: gcc.target/i386/aut

[PATCH] testsuite: i386: Fix gcc.target/i386/no-callee-saved-1.c etc. on Solaris/x86

The gcc.target/i386/no-callee-saved-[12].c tests FAIL on Solaris/x86: FAIL: gcc.target/i386/no-callee-saved-1.c scan-assembler-not push FAIL: gcc.target/i386/no-callee-saved-2.c scan-assembler-not push In both cases, the test expect the Linux/x86 default of -fomit-frame-pointer, while Solaris/x86

[PATCH] testsuite: i386: Fix gcc.target/i386/pr38534-1.c etc. on Solaris/x86

The gcc.target/i386/pr38534-1.c etc. tests FAIL on 32 and 64-bit Solaris/x86: FAIL: gcc.target/i386/pr38534-1.c scan-assembler-not push FAIL: gcc.target/i386/pr38534-2.c scan-assembler-not push FAIL: gcc.target/i386/pr38534-3.c scan-assembler-not push FAIL: gcc.target/i386/pr38534-4.c scan-assembl

[PATCH] uninit-pr108968-register.c: use __UINTPTR_TYPE__ for LLP64

Ensure sp variable is long enough by using __UINTPTR_TYPE__ for rsp. Attached patch okay? Changes unsigned long to __UINTPTR_TYPE__.From 8b5e79e1345d99ec6d3595013a20a9c672edb403 Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Wed, 31 Jan 2024 13:31:30 + Subject: [PATCH]

Re: [PATCH v3 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

On 30/01/2024 14:09, Andre Simoes Dias Vieira wrote: > Hi Richard, > > Thanks for the reviews, I'm making these changes but just a heads up. > > When hardcoding LR_REGNUM like this we need to change the way we compare the > register in doloop_condition_get. This function currently compares the r

Re: [PATCH RFA] asan: poisoning promoted statics [PR113531]

On 1/31/24 03:51, Richard Biener wrote: On Wed, Jan 31, 2024 at 4:38 AM Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk? It's a quite "late" fixup, I suppose you have tried to avoid marking it during gimplification? I see we do parts of this during BIND_EXPR processing which i

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

On 31/01/2024 12:13, Richard Biener wrote: On Wed, 31 Jan 2024, Richard Biener wrote: On Tue, 30 Jan 2024, Andre Vieira wrote: This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the target can reject a simd_clone based on the vector mode it is using. This is needed bec

Re: [PATCH] c++: add deprecation notice for -fconcepts-ts

On 1/31/24 03:40, Richard Biener wrote: On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We plan to deprecate -fconcepts-ts in GCC 15 and remove the flag_concepts_ts code. This note is an admonishing reminder to conve

Re: [PATCH] uninit-pr108968-register.c: use __UINTPTR_TYPE__ for LLP64

On Wed, Jan 31, 2024 at 2:39 PM Jonathan Yong <10wa...@gmail.com> wrote: > > Ensure sp variable is long enough by using __UINTPTR_TYPE__ for > rsp. > > Attached patch okay? Changes unsigned long to __UINTPTR_TYPE__. OK.

Re: [PATCH] c++: add deprecation notice for -fconcepts-ts

On Wed, Jan 31, 2024 at 2:53 PM Jason Merrill wrote: > > On 1/31/24 03:40, Richard Biener wrote: > > On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote: > >> > >> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > >> > >> -- >8 -- > >> We plan to deprecate -fconcepts-ts in GCC 15 an

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: > > > On 31/01/2024 12:13, Richard Biener wrote: > > On Wed, 31 Jan 2024, Richard Biener wrote: > > > >> On Tue, 30 Jan 2024, Andre Vieira wrote: > >> > >>> > >>> This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the > >>> ta

Unreviewed patches

Three patches have remained unreviewed for a week or more: c++: Fix g++.dg/ext/attr-section2.C etc. with Solaris/SPARC as https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643434.html This one may even be obvious. testsuite: i386: Fix gcc.target/i386/pr70321.c on 32-

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

On Wed, 31 Jan 2024, Richard Biener wrote: > On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: > > > > > > > On 31/01/2024 12:13, Richard Biener wrote: > > > On Wed, 31 Jan 2024, Richard Biener wrote: > > > > > >> On Tue, 30 Jan 2024, Andre Vieira wrote: > > >> > > >>> > > >>> This patch adds s

  1   2   >