[Bug middle-end/111523] Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523 --- Comment #6 from Andrew Pinski --- (In reply to Sam James from comment #3) > manager_deserialize takes ~1s instead of ~0.2s I looked into manager-serialize.c and its code generation with and without -ftrivial-auto-var-init=zero and

[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_{size,element}. >

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

[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #9 from Xi Ruoyao --- (In reply to chenglulu from comment #8) > (In reply to Xi Ruoyao from comment #7) > > Any update? :) > > Well, I haven't run it yet. Since this does not have a big impact on the > spec score, I am currently

Re:[PATCH 5/5] RISC-V: Support vmsxx.vx for autovec comparison of vec and imm

Hi, han. My comment for this patch is same as [PATCH 3/5] RISC-V: Support vmfxx.vf for autovec comparison of vec and imm --Original-- From: "demin.han"

Re:[PATCH 3/5] RISC-V: Support vmfxx.vf for autovec comparison of vec and imm

Hi, han. I understand you are trying to support optimize vector-splat_vector into vector-scalar in "expand" stage, that is, vv - vx or vv - vf. It's a known issue that we know for a long time. This patch is trying to transform vv-vf when the splat vector is duplicate from a constant (by

Re:[PATCH 4/5] RISC-V: Remove integer vector eqne pattern

Hi, han. My review comment of this patch is same as I said in: [PATCH 1/5] RISC-V: Remove float vector eqne pattern --Original-- From: "demin.han"

Re:[PATCH 2/5] RISC-V: Refactor expand_vec_cmp

LGTM. But please commit it with adding [NFC] into the title of this patch: RISC-V: Refactor expand_vec_cmp [NFC] --Original-- From: "demin.han"

Re:[PATCH 1/5] RISC-V: Remove float vector eqne pattern

Hello, han. Thanks for trying to optimize the codes. But I believe those vector-scalar patterns (eq/ne) you remove in this patch are necessary. This is the story: 1. For commutative RTL code in GCC like plus, eq, ne, ... etc, we known in semantic Both (eq: (reg) (vec_duplicate ... ) and

[Bug middle-end/114185] Missed tail-call optimization due to an argument whose address is taken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114185 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #4

[Bug middle-end/114185] Missed tail-call optimization due to an argument whose address is taken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114185 --- Comment #3 from Di Zhao --- Sorry, the old tracker for the code is PR 17749 .

[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3

RE: [PATCH 0/5] RISC-V: Support vf and vx for autovec comparison of

Sorry for the unexpected truncation. Hi, vf and vx are not supported well when comparing vector and immediate in current autovec. For example, following insts generated for float type: flw vsetvli vfmv.v.f ... vmfxx.vv Two issues: 1. Additional vsetvl and vfmv instructions

[Bug d/114155] gdc.test/runnable/literal.d FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155 --- Comment #1 from Iain Buclaw --- Upstream is notified, https://github.com/dlang/dmd/pull/16263#issuecomment-1969502776

[Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116 --- Comment #14 from Lukas Grätz --- (In reply to Jakub Jelinek from comment #2) > Created attachment 57545 [details] > gcc14-pr114116.patch > > This seems to fix it, so far tested just on the small testcase, back to the > expected backtrace

[Bug debug/114186] New: Incorrect CTF generated for multidimensional array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114186 Bug ID: 114186 Summary: Incorrect CTF generated for multidimensional array Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug middle-end/114185] Missed tail-call optimization due to an argument whose address is taken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114185 --- Comment #2 from Andrew Pinski --- Also the PR # you gave is wrong.

[PATCH 4/5] RISC-V: Remove integer vector eqne pattern

We can unify eqne and other comparison operations. Tested on RV32 and RV64. gcc/ChangeLog: * config/riscv/predicates.md (comparison_except_eqge_operator): Only exclue ge (comparison_except_ge_operator): Ditto * config/riscv/riscv-string.cc (expand_rawmemchr): Use

[Bug middle-end/114185] Missed tail-call optimization due to an argument whose address is taken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114185 --- Comment #1 from Andrew Pinski --- This code is undefined if the if is not taken.

[PATCH 3/5] RISC-V: Support vmfxx.vf for autovec comparison of vec and imm

Currently, following instructions generated in autovector: flw vsetvli vfmv.v.f ... vmfxx.vv Two issues: 1. Additional vsetvl and vfmv instructions 2. Occupy one vector register and may results in smaller lmul We expect: flw ... vmfxx.vf Tested on RV32 and

[PATCH 2/5] RISC-V: Refactor expand_vec_cmp

There are two expand_vec_cmp functions. They have same structure and similar code. We can use default arguments instead of overloading. Tested on RV32 and RV64. gcc/ChangeLog: * config/riscv/riscv-protos.h (expand_vec_cmp): Change proto * config/riscv/riscv-v.cc

[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Last

[PATCH 5/5] RISC-V: Support vmsxx.vx for autovec comparison of vec and imm

Similar to previous float change, vmsxx.vx is needed. 1. Only those which can't match vi should use vx. 2. DImode is processed by sew64_scalar_helper. Tested on RV32 and RV64. gcc/ChangeLog: * config/riscv/riscv-v.cc (get_cmp_insn_code): Select scalar pattern (expand_vec_cmp):

[PATCH 1/5] RISC-V: Remove float vector eqne pattern

We can unify eqne and other comparison operations. Tested on RV32 and RV64 gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc: Remove eqne cond * config/riscv/vector.md (@pred_eqne_scalar): Remove patterns (*pred_eqne_scalar_merge_tie_mask): Ditto

[PATCH 0/5] RISC-V: Support vf and vx for autovec comparison of

We expect: flw ... vmfxx.vf For simplicity of supporting vx and vf, two refactors completed first. 1. remove eqne pattern; any special case or reason for eqne when first added? 2. refactor duplicate code. demin.han (5): RISC-V: Remove float vector eqne pattern RISC-V: Refactor

[Bug middle-end/114185] New: Missed tail-call optimization due to an argument whose address is taken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114185 Bug ID: 114185 Summary: Missed tail-call optimization due to an argument whose address is taken Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug target/114184] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn ) with -Og -mavx512f and __builtin_memmove() _BitInt(256)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114184 Bug ID: 114184 Summary: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn ) with -Og -mavx512f and __builtin_memmove() _BitInt(256) Product: gcc

[Bug c++/114183] [11/12/13/14 Regression] Lambda constexpr works in msvc but not in gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114183 Andrew Pinski changed: What|Removed |Added Known to work||7.5.0 Known to fail|

[Bug c++/114183] New: Lambda constexpr works in msvc but not in gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114183 Bug ID: 114183 Summary: Lambda constexpr works in msvc but not in gcc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug middle-end/111523] Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523 --- Comment #5 from Andrew Pinski --- Hmm, systemd uses the cleanup attribute ...

[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171 --- Comment #1 from Andrew Pinski --- [apinski@xeond2 libstdc++-v3]$ c++filt --format dlang _D4core8lifetime__T12_d_newclassTTC1a14BreakStatementZQBjFNaNbNeZQBf core.lifetime._d_newclassT!(a.BreakStatement)._d_newclassT()

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

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 https://gcc.gnu.org/pipermail/gcc-patches/2024-March/646926.html The patch I proposed was

[Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116 --- Comment #13 from Lukas Grätz --- (In reply to H.J. Lu from comment #12) > (In reply to Lukas Grätz from comment #11) > > > > I applied it, double checked, make distclean, configure, make again. > > > > But your result seems different.

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

Hello, Matthew, Thanks for the review. On Feb 26, 2024, Matthew Malcomson wrote: > I think you're right that the AAPCS32 requires all arguments to be passed in > registers for this testcase. > (Nit on the commit-message: It says that your reading of the AAPCS32 > suggests > that the *caller*

Re: [PATCH] combine: Don't simplify paradoxical SUBREG on WORD_REGISTER_OPERATIONS [PR113010]

On 2/26/24 17:17, Greg McGary wrote: The sign-bit-copies of a sign-extending load cannot be known until runtime on WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM load. See the fix for PR112758. 2024-02-22 Greg McGary PR rtl-optimization/113010

[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143 --- Comment #6 from Hans-Peter Nilsson --- Can --with-multilib-list=aprofile,rmprofile at least be made the default when no colliding --with-* options are specified? Would that blow up "everyone"'s CI due to the extra build time? If so,

Re: [PATCH] LoongArch: Allow s9 as a register alias

在 2024/2/29 下午3:14, Xi Ruoyao 写道: The psABI allows using s9 as an alias of r22. gcc/ChangeLog: * config/loongarch/loongarch.h (ADDITIONAL_REGISTER_NAMES): Add s9 as an alias of r22. --- Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk? I think a test is

libbacktrace patch committed: Read symbol table of debuginfo file

This patch to libbacktrace reads symbol tables from debuginfo files. These become another symbol table to search. This is needed if people use --strip-all rather than --strip-debug when adding a debuglink section. This fixes https://github.com/ianlancetaylor/libbacktrace/issues/113. Bootstrapped

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #13 from Andrew

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 g.peterh...@t-online.de changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #12 from

[PATCH, rs6000] Add subreg patterns for SImode rotate and mask insert

Hi, This patch fixes regression cases in gcc.target/powerpc/rlwimi-2.c. In combine pass, SImode (subreg from DImode) lshiftrt is converted to DImode lshiftrt with an out AND. It matches a DImode rotate and mask insert on rs6000. Trying 2 -> 7: 2: r122:DI=r129:DI REG_DEAD r129:DI

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #11 from Andrew

[Bug tree-optimization/114164] simdclone vectorization creates unsupported IL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114164 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 g.peterh...@t-online.de changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #10 from

Re: [PATCH] RISC-V: Add riscv_vector_cc function attribute

Ping. xu...@eswincomputing.com From: Li Xu Date: 2024-02-27 09:17 To: gcc-patches CC: kito.cheng; palmer; juzhe.zhong; zhengyu; xuli Subject: [PATCH] RISC-V: Add riscv_vector_cc function attribute From: xuli Standard vector calling convention variant will only enabled when function has

Re: [PATCH gcc] Hurd x86_64: add unwind support for signal trampoline code

Flavio Cruz, le mer. 28 févr. 2024 22:59:09 -0500, a ecrit: > Tested with some simple toy examples where an exception is thrown in the > signal handler. > > libgcc/ChangeLog: > * config/i386/gnu-unwind.h: Support unwinding x86_64 signal frames. > > Signed-off-by: Flavio Cruz Reviewed-by:

[Bug middle-end/111523] Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523 --- Comment #4 from Andrew Pinski --- >From that github issue: Internal memory management to take exponentially longer on at least ARM platforms. This narrows things down slightly. But it also makes me think there is some brokenness inside

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #9 from Andrew

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 g.peterh...@t-online.de changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #8 from

[PATCH] c++/modules: Stream definitions for implicit instantiations [PR114170]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- An implicit instantiation has an initializer depending on whether DECL_INITIALIZED_P is set (like normal VAR_DECLs) which needs to be written to ensure that consumers of header modules properly emit definitions for these

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 --- Comment #7 from Andrew Pinski --- C++ standard does not define a std::issubnormal yet.

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #6 from Andrew

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 g.peterh...@t-online.de changed: What|Removed |Added Resolution|MOVED |FIXED --- Comment #5 from

[Bug testsuite/114182] gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114182 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|WAITING

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 --- Comment #3 from g.peterh...@t-online.de --- Of course issubnormal is defined in math.h (in my case line 1088, gcc 13.2).

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 --- Comment #2 from Andrew Pinski --- Also please provide a full testcase to show what you are doing because this code snippet is not even valid c++.

[Bug testsuite/114182] New: gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114182 Bug ID: 114182 Summary: gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c/114181] issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

Re: [PATCH v3] c++: implement [[gnu::non_owning]] [PR110358]

On 2/29/24 19:12, Marek Polacek wrote: On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote: Hmm, if we're also going to allow the attribute to be applied to a function, the name doesn't make so much sense. For a class, it says that the class refers to its initializer; for a

[Bug c/114181] New: issubnormal is a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181 Bug ID: 114181 Summary: issubnormal is a macro Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee:

[Bug target/111898] [12/13/14 Regression][SH] internal compiler error: Segmentation fault when building PostgreSQL 16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111898 Oleg Endo changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED

[PATCH v3] c++: implement [[gnu::non_owning]] [PR110358]

On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote: > On 2/21/24 19:35, Marek Polacek wrote: > > On Fri, Jan 26, 2024 at 04:04:35PM -0500, Jason Merrill wrote: > > > On 1/25/24 20:37, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > >

[Bug middle-end/111523] Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523 --- Comment #3 from Sam James --- There's some trace output at https://github.com/systemd/systemd/issues/26950#issue-1637752077 but it's not quite the same as perf output. But they do identify some bad functions: """ Observations:

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #18 from palmer at gcc dot gnu.org --- (In reply to palmer from comment #17) > (In reply to Edwin Lu from comment #16) > > So if I understand correctly, there may also be a problem where it's trying > > to create that named first

[Bug target/114180] New: RISC-V: missing vsetvl changes tail policy and causes wrong codegen

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114180 Bug ID: 114180 Summary: RISC-V: missing vsetvl changes tail policy and causes wrong codegen Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #17 from palmer at gcc dot gnu.org --- (In reply to Edwin Lu from comment #16) > (In reply to palmer from comment #15) > > It's a little easier to see from the float version of the code. > > > > $ cat

[Bug analyzer/114159] [13 Regression] ICE: in call_info, at analyzer/call-info.cc:143 with -fanalyzer -fanalyzer-call-summaries --param=analyzer-max-svalue-depth=0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114159 David Malcolm changed: What|Removed |Added Summary|[13/14 Regression] ICE: in |[13 Regression] ICE: in

[pushed] analyzer: fix ICE in call summarization [PR114159]

PR analyzer/114159 reports an ICE inside playback of call summaries for very low values of --param=analyzer-max-svalue-depth=VAL. Root cause is that call_summary_edge_info's ctor tries to evaluate the function ptr of a gimple call stmt and assumes it gets a function *, but with low values of

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

On 2024-02-29 6:02 p.m., Thomas Schwinge wrote: Hi! On 2024-02-01T19:20:57+, John David Anglin wrote: Tested on hppa-unknown-linux-gnu. Committed to trunk. Set num_threads to 50 on 32-bit hppa in two libgomp loop tests We support a maximum of 50 threads on 32-bit hppa. What happens if

[Bug analyzer/114159] [13/14 Regression] ICE: in call_info, at analyzer/call-info.cc:143 with -fanalyzer -fanalyzer-call-summaries --param=analyzer-max-svalue-depth=0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114159 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:c0d8a64e72324d1c2981da21a66394bf8f7a2889 commit r14-9245-gc0d8a64e72324d1c2981da21a66394bf8f7a2889 Author: David Malcolm Date:

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178 --- Comment #5 from Andrew Pinski --- (In reply to Evan Teran from comment #4) > @Andrew, thanks for the quick analysis! Just to confirm, the warning is in > fact incorrect and the emitted code is not stomping outside of the buffer > bounds? >

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178 --- Comment #4 from Evan Teran --- @Andrew, thanks for the quick analysis! Just to confirm, the warning is in fact incorrect and the emitted code is not stomping outside of the buffer bounds? I ask because I did also one last bit, which is

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

Hi! On 2024-02-01T19:20:57+, John David Anglin wrote: > Tested on hppa-unknown-linux-gnu. Committed to trunk. > Set num_threads to 50 on 32-bit hppa in two libgomp loop tests > > We support a maximum of 50 threads on 32-bit hppa. What happens if you go higher? Curious, what/why is that

Re: [PATCH 1/3] Change 'v1' float and int code to fall back to v0

> "Jeff" == Jeff Law writes: >> I don't know how to fix this. Jeff> Me neither, but I can suggest a hacky workaround. FTR, I asked Jakub on irc and he fixed it, so thankfully I didn't have to resort to the hack :-) thanks, Tom

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #16 from Edwin Lu --- (In reply to palmer from comment #15) > It's a little easier to see from the float version of the code. > > $ cat gcc/testsuite/gcc.dg/c23-stdarg-6.c > /* Test C23 variadic functions with no named parameters,

[Bug tree-optimization/114166] word_mode vectorization still relies on vector lowering

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114166 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-29

[Bug target/114173] miss optimization of redundant load operation, may confused by type conversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114173 --- Comment #1 from Andrew Pinski --- Trying 7, 8, 9 -> 10: 7: r100:HI=zero_extend([const(`g_63'+0x10)]) 8: {r107:HI=r100:HI+0x1;clobber flags:CC;} REG_UNUSED flags:CC 9: r108:SI=zero_extend(r107:HI) REG_DEAD r107:HI

gcc-11-20240229 is now available

Snapshot gcc-11-20240229 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240229/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

[Bug analyzer/114179] New: diagnostic-manager.cc:811:28: warning: unknown conversion type character 'E' in format

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114179 Bug ID: 114179 Summary: diagnostic-manager.cc:811:28: warning: unknown conversion type character 'E' in format Product: gcc Version: 14.0 Status: UNCONFIRMED

Re: [PATCH] Fortran: improve checks of NULL without MOLD as actual argument [PR104819]

On 2/29/24 12:56 PM, Harald Anlauf wrote: Dear all, here's a first patch addressing issues with NULL as actual argument: if the dummy is assumed-rank or assumed length, MOLD shall be present. There is also an interp on interoperability of c_sizeof and NULL pointers, for which we have a

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #15 from palmer at gcc dot gnu.org --- It's a little easier to see from the float version of the code. $ cat gcc/testsuite/gcc.dg/c23-stdarg-6.c /* Test C23 variadic functions with no named parameters, or last named parameter

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-29 Ever confirmed|0

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178 --- Comment #1 from Andrew Pinski --- Confirmed. There is a dup of this bug somewhere. Basically the vectorizer is causing some IR which shows up the warning. Yes even though you disable the vector instruction sets, the vectorizer still

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 --- Comment #31 from Richard Sandiford --- (In reply to Tamar Christina from comment #29) > This works fine for normal gather and scatters but doesn't work for widening > gathers and narrowing scatters which only the pattern seems to handle.

Re: [PATCH] libgccjit: Add option to allow special characters in function names

Hi and thanks for the review. I thought it would be a bit weird to have an option to change which characters are allowed, but I can't think of a better solution. Here's the updated patch that now allow arbitrary characters. Le 2024-02-20 à 16 h 05, Iain Sandoe a écrit : On 20 Feb 2024, at

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

Hi, please keep me in the loop for this one. I need cargo for the borrow checker as well (the external Polonius engine). Best Jakub On Thu, 29 Feb 2024, at 21:22, Mark Wielaard wrote: > Hi, > > On Thu, Feb 29, 2024 at 09:00:13PM +0100, Thomas Schwinge wrote: > > Three 'cargo' ('command not

[Bug c++/114178] New: incorrect -Wstringop-overflow with freestanding + placement new w/ initialization + no sse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178 Bug ID: 114178 Summary: incorrect -Wstringop-overflow with freestanding + placement new w/ initialization + no sse Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug testsuite/114177] New: gcc.target/aarch64/sve/loop_add_6.c needs to be fixed for LLP64 targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114177 Bug ID: 114177 Summary: gcc.target/aarch64/sve/loop_add_6.c needs to be fixed for LLP64 targets Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords:

[Bug target/65010] ppc backend generates unnecessary signed extension

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010 --- Comment #13 from Segher Boessenkool --- (In reply to pthaugen from comment #11) > Another example to clean up. The back to back constant load/sign extend > sequence of rtl insns is created in each block by the block reordering pass > (.bbo)

Re: [PATCH V3 2/2] rs6000: Load store fusion for rs6000 target using common infrastructure

Hi! On Mon, Feb 19, 2024 at 04:24:37PM +0530, Ajit Agarwal wrote: > --- a/gcc/config.gcc > +++ b/gcc/config.gcc > @@ -518,7 +518,7 @@ or1k*-*-*) > ;; > powerpc*-*-*) > cpu_type=rs6000 > - extra_objs="rs6000-string.o rs6000-p8swap.o rs6000-logue.o" > +

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-02-29 Ever

[PATCH] c++: Ensure DECL_CONTEXT is set for temporary vars [PR114005]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Alternatively we could update 'DECL_CONTEXT' only for 'make_temporary_var_for_ref_to_temp' in call.cc, as a more targetted fix, but I felt that this way it'd also fix any other similar issues that have gone uncaught so far. -- >8

Re: [PATCH] libgccjit: Add support for creating temporary variables

Hi and thanks for the review! Here's the updated patch. Le 2024-01-24 à 09 h 54, David Malcolm a écrit : On Fri, 2024-01-19 at 16:54 -0500, Antoni Boucher wrote: Hi. This patch adds a new way to create local variable that won't generate debug info: it is to be used for compiler-generated

[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot

[PATCH] c++/modules: depending local enums [PR104919, PR106009]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- For local enums defined in a non-template function or a function template instantiation it seems we neglect to make the function depend on the enum definition, which ultimately causes streaming to fail due

[PATCH] Fortran: improve checks of NULL without MOLD as actual argument [PR104819]

Dear all, here's a first patch addressing issues with NULL as actual argument: if the dummy is assumed-rank or assumed length, MOLD shall be present. There is also an interp on interoperability of c_sizeof and NULL pointers, for which we have a partially incorrect testcase

[Bug libstdc++/114147] [11/12/13/14 Regression] tuple allocator-extended constructor requires non-explicit default constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug analyzer/110483] [14 Regression] Several gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > * out-of-bounds-diagram-3.c gets skipped on that machine due to > { dg-require-effective-target lp64 } > "check_cached_effective_target lp64: returning 0 for unix" > > Is

  1   2   3   >