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

Hi! When compiling libgcc or on e.g. int a[64]; int p; void foo (void) { int s = 1; while (p) { s -= 11; a[s] != 0; } } sccvn invokes UB in the compiler as detected by ubsan: ../../gcc/poly-int.h:1089:5: runtime error: left shift of negative value -40 The problem is that

回复: RE: [PATCH] RISC-V: Fix ICE in riscv vector costs

I suggest open an PR with a PR id. juzhe.zh...@rivai.ai 发件人： Demin Han 发送时间： 2024-03-07 15:39 收件人： juzhe.zh...@rivai.ai; gcc-patches 抄送： kito.cheng; pan2.li; jeffreyalaw 主题： RE: [PATCH] RISC-V: Fix ICE in riscv vector costs OK. Which is better for testcase name? 1. ice-biggestmode.c or

[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Patrick O'Neill changed: What|Removed |Added Attachment #57640|0 |1 is obsolete|

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

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

[Bug tree-optimization/114009] [11/12/13/14 Regression] Missed optimization: (!a) * a => 0 when a=(a/2)*2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009 --- Comment #5 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:95b6ee96348041eaee9133f082b57f3e57ef0b11 commit r14-9350-g95b6ee96348041eaee9133f082b57f3e57ef0b11 Author: Jakub Jelinek Date:

[Bug target/114252] Introducing bswapsi reduces code performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252 --- Comment #7 from Richard Biener --- Note I do understand what you are saying, just the middle-end in detecting and using __builtin_bswap32 does what it does everywhere else - it checks whether the target implements the operation. The

RE: [PATCH] RISC-V: Fix ICE in riscv vector costs

OK. Which is better for testcase name? 1. ice-biggestmode.c or 2. Report a bug and name the testcase with PR id From: juzhe.zh...@rivai.ai Sent: 2024年3月7日 15:20 To: Demin Han ; gcc-patches Cc: kito.cheng ; pan2.li ; jeffreyalaw Subject: Re: [PATCH] RISC-V: Fix ICE in riscv vector

Results for 14.0.1 20240307 (experimental) [remotes/origin/HEAD r14-9349-g1cd8254eba] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:1cd8254ebad7b73993d2acee80a7caf37c21878a gcc-descr r14-9349-g1cd8254ebad7b7 power8 Linux 5.4.0-172-generic ppc64le GNU Make 4.2.1 DejaGnu: DejaGnu version 1.6.2 Expect version 5.45.4 Tcl version 8.6 64-bit LAST_UPDATED: Thu Mar 7 05:40:39 UTC 2024

[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 --- Comment #10 from rguenther at suse dot de --- On Wed, 6 Mar 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 > > Jakub Jelinek changed: > >What|Removed

[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #3 from Alexander Monakov --- The first attachment is empty (perhaps you made a non-recursive archive when you meant to recursively zip a directory).

Re: [PATCH] RISC-V: Fix ICE in riscv vector costs

Could you plz add testcase ? I just noticed you didn't append a testcase (jpeg) in this patch. juzhe.zh...@rivai.ai From: demin.han Date: 2024-03-07 13:54 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; jeffreyalaw Subject: [PATCH] RISC-V: Fix ICE in riscv vector costs The following

Re: [PATCH] RISC-V: Fix ICE in riscv vector costs

LGTM. juzhe.zh...@rivai.ai From: demin.han Date: 2024-03-07 13:54 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; jeffreyalaw Subject: [PATCH] RISC-V: Fix ICE in riscv vector costs The following code can result in ICE: -march=rv64gcv_zba_zbb --param riscv-autovec-lmul=dynamic -O3 char

Re: [PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

Hi Dimitry, folks, > On 6 Mar 2024, at 23:02, Dimitry Andric wrote: > > On 6 Mar 2024, at 15:57, FX Coudert wrote: >> >>> Hmm I recall trying it and finding a problem - was there some different fix >>> applied >>> in the end? >> >> The bug is still open, I don’t think a patch was applied,

Regressions on native/releases/gcc-13 at commit r13-8408 vs commit r13-8397 on Linux/x86_64

Regressions on native/releases/gcc-13 at commit r13-8408 vs commit r13-8397 on Linux/x86_64 New failures: FAIL: 30_threads/future/members/poll.cc execution test FAIL: gcc.dg/torture/convert-dfp-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL:

Results for 13.2.1 20240307 [native/releases/gcc-13 r13-8408-g58cbab9c1d1] (GCC) testsuite on x86_64-pc-linux-gnu

LAST_UPDATED: Thu Mar 7 05:40:04 UTC 2024 (revision r13-8408-g58cbab9c1d1) Native configuration is x86_64-pc-linux-gnu === gcc tests === Running target unix FAIL: gcc.dg/analyzer/data-model-4.c (test for excess errors) FAIL: gcc.dg/analyzer/torture/conftest-1.c -O0 (test

RE: [PATCH] c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]

> -Original Message- > From: Andrew Pinski (QUIC) > Sent: Tuesday, February 20, 2024 7:06 PM > To: gcc-patches@gcc.gnu.org > Cc: Andrew Pinski (QUIC) > Subject: [PATCH] c++/c-common: Fix convert_vector_to_array_for_subscript > for qualified vector types [PR89224] > > After

Results for 12.3.1 20240307 [remotes/origin/releases/gcc-12 r12-10196-gdb302d81d2] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:db302d81d246c324171422c20ffe1175feaa5e16 gcc-descr r12-10196-gdb302d81d246c3 power9 Linux 5.15.0-97-generic ppc64le GNU Make 4.3 DejaGnu: DejaGnu version 1.6.2 Expect version 5.45.4 Tcl version 8.6 64-bit LAST_UPDATED: Thu Mar 7 05:49:08 UTC 2024

Results for 15.0.0 (clang-1500.3.9.4) testsuite on x86_64-apple-darwin23

) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (test for excess errors) === g++ Summary === # of expected passes253197 # of unexpected failures73 # of expected failures 2778 # of unresolved testcases 1 # of unsupported tests 11391 /Users/

[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 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

Results for 14.0.1 20240307 (experimental) [remotes/origin/HEAD r14-9348-g03932d3203] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:03932d3203bce244edd812b81921c2f16ea18d86 gcc-descr r14-9348-g03932d3203bce2 power9 IEEE128 Linux 6.8.0-0.rc6.20240229git805d849d7c3c.51.fc41.ppc64le ppc64le GNU Make 4.4.1 DejaGnu: DejaGnu version 1.6.3 Expect version 5.45.4 Tcl version 8.6 64-bit

[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114195 --- Comment #2 from Li Pan --- Trigger below assert in vectorizable_store, the loop_vinfo use_partial, fully_masked and fully_lens are all true here. /* Shouldn't go with length-based approach if fully masked. */ gcc_assert (!loop_lens ||

Results for 14.0.1 20240306 (experimental) [master-ia32 r14-9346-g74e8cc28eda] (GCC) testsuite on i686-pc-linux-gnu

=== # of expected passes196942 # of unexpected failures118 # of unexpected successes 27 # of expected failures 1556 # of unsupported tests 4056 /export/gnu/import/git/gcc-test-master-ia32/bld/gcc/xgcc version 14.0.1 20240306 (experimental) [master-ia32 r14-9346

[PATCH] RISC-V: Fix ICE in riscv vector costs

The following code can result in ICE: -march=rv64gcv_zba_zbb --param riscv-autovec-lmul=dynamic -O3 char *jpeg_difference7_input_buf; void jpeg_difference7(int *diff_buf) { unsigned width; int samp, Rb; while (--width) { Rb = samp = *jpeg_difference7_input_buf; *diff_buf++ =

Results for 14.0.1 20240306 (experimental) [master r14-9337-g71aad523144] (GCC) testsuite on x86_64-pc-linux-gnu

=== gcc Summary === # of expected passes600642 # of unexpected failures400 # of unexpected successes 59 # of expected failures 4657 # of unsupported tests 10710 /export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc version 14.0.1

Results for 14.0.1 20240307 (experimental) [remotes/origin/HEAD r14-9348-g03932d3203b] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:03932d3203bce244edd812b81921c2f16ea18d86 gcc-descr r14-9348-g03932d3203bce2 power9 Linux 5.15.0-97-generic ppc64le GNU Make 4.3 DejaGnu: DejaGnu version 1.6.2 Expect version 5.45.4 Tcl version 8.6 64-bit LAST_UPDATED: Thu Mar 7 04:20:13 UTC 2024

[Bug target/114200] [14] RISC-V fixed-length vector miscompile at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114200 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0

Results for 14.0.1 20240307 (experimental) [remotes/origin/HEAD r14-9347-g8b483cd552] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:8b483cd5521de79c13cf4807fd004d442b9ad9cd gcc-descr r14-9347-g8b483cd5521de7 power8 Linux 5.4.0-172-generic ppc64le GNU Make 4.2.1 DejaGnu: DejaGnu version 1.6.2 Expect version 5.45.4 Tcl version 8.6 64-bit LAST_UPDATED: Thu Mar 7 03:34:33 UTC 2024

[gcc r14-9349] RISC-V: Refactor expand_vec_cmp [NFC]

https://gcc.gnu.org/g:1cd8254ebad7b73993d2acee80a7caf37c21878a commit r14-9349-g1cd8254ebad7b73993d2acee80a7caf37c21878a Author: demin.han Date: Mon Feb 26 14:50:15 2024 +0800 RISC-V: Refactor expand_vec_cmp [NFC] There are two expand_vec_cmp functions. They have same

[Bug ipa/114263] LTO generating incorrect code with -O2 -std=c++20 -fno-strict-aliasing flags in GCC13

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114263 --- Comment #2 from Andrew Pinski --- the testcase in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359#c15 makes it even more likely the same as this one.

[Bug ipa/114263] LTO generating incorrect code with -O2 -std=c++20 -fno-strict-aliasing flags in GCC13

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114263 --- Comment #1 from Andrew Pinski --- This sounds almost the same as what is mentioned in PR 113359 ("is changed by SRA to only store 64 + 32 bits into the std::pair rather than 64 + 64 bits.").

[Bug lto/114263] New: LTO generating incorrect code with -O2 -std=c++20 -fno-strict-aliasing flags in GCC13

: 66`. The bug won't reproduce if I specify C++ standard before C++20, or if I don't disable strict-aliasing optimization. Changing the size of A::y affects the number of bytes that are correctly copied in the output. The bug reproduces in gcc 13.2.0 and from the latest releases/gcc-13 branch (g

Re: [PATCH] LoongArch: Emit R_LARCH_RELAX for TLS IE with non-extreme code model to allow the IE to LE linker relaxation

在 2024/3/7 下午12:05, mengqinggang 写道: Hi, Thanks, this patch is LGTM. I don't have a problem either. Thanks. 在 2024/3/7 上午10:56, Xi Ruoyao 写道: On Thu, 2024-03-07 at 10:43 +0800, mengqinggang wrote: Hi, Whether to add an option to control the generation of R_LARCH_RELAX, similar to as

[Bug tree-optimization/114238] [14 regression] Multiple 554.roms_r run-time regressions (4%-20%) since r14-9193-ga0b1798042d033

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238 Andrew Pinski changed: What|Removed |Added Summary|Multiple 554.roms_r |[14 regression] Multiple

[no subject]

Loadings,.

Results for 14.0.1 20240306 (experimental) [master r14-9343-gb575f37a342] (GCC) testsuite on s390x-ibm-linux-gnu arch14

LAST_UPDATED: Wed Mar 6 18:04:46 UTC 2024 (revision r14-9343-gb575f37a342) === acats tests === FAIL: cb1010a === acats Summary === # of expected passes2327 # of unexpected failures1 Native configuration is s390x-ibm-linux-gnu arch14

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

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

Results for 14.0.1 20240307 (experimental) [remotes/origin/HEAD r14-9347-g8b483cd552] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:8b483cd5521de79c13cf4807fd004d442b9ad9cd gcc-descr r14-9347-g8b483cd5521de7 power9 IEEE128 Linux 6.8.0-0.rc6.20240229git805d849d7c3c.51.fc41.ppc64le ppc64le GNU Make 4.4.1 DejaGnu: DejaGnu version 1.6.3 Expect version 5.45.4 Tcl version 8.6 64-bit

Results for 13.2.1 20240307 [releases/gcc-13 r13-8408-g58cbab9c1d] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:58cbab9c1d1b863e0079a6525fe9a5b83960a5d3 gcc-descr r13-8408-g58cbab9c1d1b86 power9 Linux 5.15.0-97-generic ppc64le GNU Make 4.3 DejaGnu: DejaGnu version 1.6.2 Expect version 5.45.4 Tcl version 8.6 64-bit LAST_UPDATED: Thu Mar 7 03:13:34 UTC 2024

Re: [PATCH] LoongArch: Emit R_LARCH_RELAX for TLS IE with non-extreme code model to allow the IE to LE linker relaxation

Hi, Thanks, this patch is LGTM. 在 2024/3/7 上午10:56, Xi Ruoyao 写道: On Thu, 2024-03-07 at 10:43 +0800, mengqinggang wrote: Hi, Whether to add an option to control the generation of R_LARCH_RELAX, similar to as -mrelax/-mno-relax. There are already -mrelax and -mno-relax, they can be checked

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 3/6/24 9:13 AM, Harald Anlauf wrote: Hi Jerry, can you please replace the user message in e.g. your new testcase pr105456-wf.f90 by say: piomsg="The users message containing % and %% and %s and other stuff" This behaves as expected with Intel, but dies horribly with gfortran after your

Re: [PATCH] c++: lambda capturing structured bindings [PR85889]

On 3/4/24 12:49, Marek Polacek wrote: On Fri, Mar 01, 2024 at 07:58:24PM -0500, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 15? (Or even trunk?) -- >8 -- clarifies that it's OK to capture structured bindings.

[gcc r14-9348] Fortran: Fix issue with using snprintf function.

https://gcc.gnu.org/g:03932d3203bce244edd812b81921c2f16ea18d86 commit r14-9348-g03932d3203bce244edd812b81921c2f16ea18d86 Author: Jerry DeLisle Date: Wed Mar 6 19:46:04 2024 -0800 Fortran: Fix issue with using snprintf function. The previous patch used snprintf to set the message

[Bug libfortran/105456] Child I/O does not propage iostat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 --- Comment #7 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:03932d3203bce244edd812b81921c2f16ea18d86 commit r14-9348-g03932d3203bce244edd812b81921c2f16ea18d86 Author: Jerry DeLisle Date:

Re: [PATCH] c++: ICE with variable template and [[deprecated]] [PR110031]

On 3/4/24 17:11, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? OK. -- >8 -- lookup_and_finish_template_variable already has and uses the complain parameter but it is not passing it down to mark_used so we got the default tf_warning_or_error, which

Re: [PATCH] c++/modules: member alias tmpl partial inst [PR103994]

On 3/4/24 17:26, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Alias templates are weird in that their specializations can appear in both decl_specializations and type_specializations. They appear in the latter only at parse time

Results for 14.0.1 20240306 (experimental) [master r14-9346-g74e8cc28eda] (GCC) testsuite on i686-pc-linux-gnu

; 2 === gcc Summary === # of expected passes196892 # of unexpected failures126 # of unexpected successes 27 # of expected failures 1556 # of unsupported tests 4071 /export/gnu/import/git/gcc-test-master-ia32/bld/gcc/x

[Bug tree-optimization/114246] [11/12/13 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246 Andrew Pinski changed: What|Removed |Added Keywords|ice-checking| --- Comment #6 from Andrew Pinski

Results for 12.3.1 20240307 [remotes/origin/releases/gcc-12 r12-10196-gdb302d81d2] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:db302d81d246c324171422c20ffe1175feaa5e16 gcc-descr r12-10196-gdb302d81d246c3 power8 Linux 5.4.0-172-generic ppc64le GNU Make 4.2.1 DejaGnu: DejaGnu version 1.6.2 Expect version 5.45.4 Tcl version 8.6 64-bit LAST_UPDATED: Thu Mar 7 02:00:20 UTC 2024

[Bug ipa/114262] Over-inlining when optimizing for size with gnu_inline function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 --- Comment #5 from Andrew Pinski --- (In reply to LIU Hao from comment #4) > The only difference between the C99 `extern inline` and C++ `extern inline` > is that the C++ external definition is COMDAT. Well not really. comdat changes

[Bug tree-optimization/114253] False positive maybe-uninitialized with std::optional and ternary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114253 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #5

[Bug ipa/114262] Over-inlining when optimizing for size with gnu_inline function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 --- Comment #4 from LIU Hao --- (In reply to Andrew Pinski from comment #3) > It looks like it has been this way since r0-37737-g4838c5ee553f06 (2001) (or > rather that is when it was used by the tree inline; I don't want to dig > further back

[Bug tree-optimization/114253] False positive maybe-uninitialized with std::optional and ternary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114253 --- Comment #4 from Andrew Pinski --- VIEW_CONVERT_EXPR(pid$4_26) Where I have seen this before ...

[Bug ipa/114262] Over-inlining when optimizing for size with gnu_inline function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 Andrew Pinski changed: What|Removed |Added Keywords||documentation --- Comment #3 from

Re: [PATCH] LoongArch: Emit R_LARCH_RELAX for TLS IE with non-extreme code model to allow the IE to LE linker relaxation

On Thu, 2024-03-07 at 10:43 +0800, mengqinggang wrote: > Hi, > > Whether to add an option to control the generation of R_LARCH_RELAX, > similar to as -mrelax/-mno-relax. There are already -mrelax and -mno-relax, they can be checked in the compiler code with TARGET_LINKER_RELAXATION. /* snip */

Results for 11.4.1 20240307 [releases/gcc-11 revision 16ead05d13a:fce62c30b6e:788cf673bd752b833e81a591a820259e9198973f] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:788cf673bd752b833e81a591a820259e9198973f gcc-descr r11-11271-g788cf673bd752b power9 Linux 5.15.0-97-generic ppc64le GNU Make 4.3 DejaGnu: DejaGnu version 1.6.2 Expect version 5.45.4 Tcl version 8.6 64-bit LAST_UPDATED: Thu Mar 7 01:52:06 UTC 2024

Results for 12.3.1 20240307 [releases/gcc-12 r12-10196-gdb302d81d2] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:db302d81d246c324171422c20ffe1175feaa5e16 gcc-descr r12-10196-gdb302d81d246c3 power9 IEEE128 Linux 6.8.0-0.rc6.20240229git805d849d7c3c.51.fc41.ppc64le ppc64le GNU Make 4.4.1 DejaGnu: DejaGnu version 1.6.3 Expect version 5.45.4 Tcl version 8.6 64-bit

Re: [PATCH] LoongArch: Emit R_LARCH_RELAX for TLS IE with non-extreme code model to allow the IE to LE linker relaxation

Hi, Whether to add an option to control the generation of R_LARCH_RELAX, similar to as -mrelax/-mno-relax. 在 2024/2/29 下午3:11, Xi Ruoyao 写道: In Binutils we need to make IE to LE relaxation only allowed when there is an R_LARCH_RELAX after R_LARCH_TLE_IE_PC_{HI20,LO12} so an invalid "partial"

[Bug ipa/114262] Over-inlining when optimizing for size with gnu_inline function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 --- Comment #2 from LIU Hao --- (In reply to Andrew Pinski from comment #1) > I thought it was documented that gnu_inline also causes always_inline if > optimization is turned on but I can't seem to find that ... Is that the case in GCC

Re: [PATCH] c++/modules: inline namespace abi_tag streaming [PR110730]

On Wed, 6 Mar 2024, Jason Merrill wrote: > On 3/6/24 14:10, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > > > -- >8 -- > > > > The unreduced testcase from this PR crashes at runtime ultimately > > because we don't stream the abi_tag attribute on inline

[Bug tree-optimization/114262] Over-inlining when optimizing for size?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 --- Comment #1 from Andrew Pinski --- I thought it was documented that gnu_inline also causes always_inline if optimization is turned on but I can't seem to find that ...

[Bug tree-optimization/114262] New: Over-inlining when optimizing for size?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 Bug ID: 114262 Summary: Over-inlining when optimizing for size? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Results for 14.0.1 20240306 (experimental) [remotes/origin/HEAD r14-9346-g74e8cc28ed] (GCC) testsuite on powerpc64le-unknown-linux-gnu

(test for excess errors) === gcc Summary === # of expected passes177989 # of unexpected failures148 # of unexpected successes 12 # of expected failures 1597 # of unsupported tests 4948 /home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc

Re: [PATCH] c++: Fix ICE diagnosing incomplete type of overloaded function set [PR98356]

On 3/4/24 18:30, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- In the linked PR the result of 'get_first_fn' is a USING_DECL against the template parameter, to be filled in on instantiation. But we don't actually need to get the first

RE: [PATCH v2] Draft|Internal-fn: Introduce internal fn saturation US_PLUS

Thanks Richard for comments. > gen_int_libfunc will no longer make it emit libcalls for fixed point > modes, so this can't be correct > and there's no libgcc implementation for integer mode saturating ops, > so it's pointless to emit calls > to them. Got the pointer here, the

Results for 14.0.1 20240307 (experimental) [remotes/origin/HEAD r14-9347-g8b483cd5521] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:8b483cd5521de79c13cf4807fd004d442b9ad9cd gcc-descr r14-9347-g8b483cd5521de7 power9 Linux 5.15.0-97-generic ppc64le GNU Make 4.3 DejaGnu: DejaGnu version 1.6.2 Expect version 5.45.4 Tcl version 8.6 64-bit LAST_UPDATED: Thu Mar 7 00:23:56 UTC 2024

[PATCH] LoongArch: testsuite: Add compilation options to the regname-fp-s9.c.

When the value of the macro DEFAULT_CFLAGS is set to '-ansi -pedantic-errors', regname-s9-fp.c will test to fail. To solve this problem, add the compilation option '-Wno-pedantic -std=gnu90' to this test case. gcc/testsuite/ChangeLog: * gcc.target/loongarch/regname-fp-s9.c: Add

Results for 13.2.1 20240307 [releases/gcc-13 r13-8408-g58cbab9c1d] (GCC) testsuite on powerpc64le-unknown-linux-gnu

git commit g:58cbab9c1d1b863e0079a6525fe9a5b83960a5d3 gcc-descr r13-8408-g58cbab9c1d1b86 power9 IEEE128 Linux 6.8.0-0.rc6.20240229git805d849d7c3c.51.fc41.ppc64le ppc64le GNU Make 4.4.1 DejaGnu: DejaGnu version 1.6.3 Expect version 5.45.4 Tcl version 8.6 64-bit

[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #2 from Patrick O'Neill --- Created attachment 57641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57641=edit unreduced preprocessed testcase

[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3 CC|

[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #1 from Patrick O'Neill --- Created attachment 57640 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57640=edit Raw testcase and headers

[Bug rtl-optimization/114261] New: [13/14 Regression] Scheduling takes excessive time (97%)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Bug ID: 114261 Summary: [13/14 Regression] Scheduling takes excessive time (97%) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

Results for 14.0.1 20240307 (experimental) [master revision 74e8cc28eda:bad6306994b:8b483cd5521de79c13cf4807fd004d442b9ad9cd] (GCC) testsuite on pru-unknown-elf

LAST_UPDATED: 7.03.2024 (чт) 1:00:12 UTC (revision ) Target is pru-unknown-elf Host is x86_64-pc-linux-gnu === gcc tests === Running target pru-sim FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c (test for excess errors) FAIL:

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On 3/5/24 00:24, Nathaniel Shead wrote: On Mon, Mar 04, 2024 at 10:07:33PM -0500, Patrick Palka wrote: On Tue, 5 Mar 2024, Nathaniel Shead wrote: On Mon, Mar 04, 2024 at 09:26:00PM -0500, Patrick Palka wrote: On Tue, 5 Mar 2024, Nathaniel Shead wrote: On Mon, Mar 04, 2024 at 07:14:54PM

Re: [PATCH] c++/modules: inline namespace abi_tag streaming [PR110730]

On 3/6/24 14:10, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The unreduced testcase from this PR crashes at runtime ultimately because we don't stream the abi_tag attribute on inline namespaces and so the filesystem::current_path() call resolves to

[Bug libstdc++/114244] Need to use round when parsing fractional seconds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 --- Comment #5 from Jonathan Wakely --- Yup, that's what I have in my local tree now.

[PATCH v1] LoongArch: Fixed an issue with the implementation of the template atomic_compare_and_swapsi.

If the hardware does not support LAMCAS, atomic_compare_and_swapsi needs to be implemented through "ll.w+sc.w". In the implementation of the instruction sequence, it is necessary to determine whether the two registers are equal. Since LoongArch's comparison instructions do not distinguish between

[Bug libstdc++/114244] Need to use round when parsing fractional seconds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 --- Comment #4 from Howard Hinnant --- Not positive (because I don't know your code that well), but I think: __s = round<_Duration>(__fs); will do it.

Results for 14.0.1 20240306 (experimental) [master r14-9337-g71aad523144] (GCC) testsuite on x86_64-pc-linux-gnu

=== gcc Summary === # of expected passes600655 # of unexpected failures403 # of unexpected successes 59 # of expected failures 4657 # of unresolved testcases 2 # of unsupported tests 10710 /export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc version 1

Regressions on master at commit r14-9337 vs commit r14-9326 on Linux/x86_64

Regressions on master at commit r14-9337 vs commit r14-9326 on Linux/x86_64 New failures: FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O -flto -save-temps FAIL: gcc.dg/torture/convert-dfp-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess

[Bug libstdc++/114244] Need to use round when parsing fractional seconds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > Yup, the seconds part "00.002" is parsed using std::numpunct (in order to Oops, std::num_get obviously. > handle the locale's decimal point) and then

[Bug libstdc++/114244] Need to use round when parsing fractional seconds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > and another duration_cast in chrono::from_stream for durations. That one > could be used with either integral or floating-point reps. Ah, but we're

[Bug target/114200] [14] RISC-V fixed-length vector miscompile at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114200 Patrick O'Neill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/114244] Need to use round when parsing fractional seconds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 --- Comment #1 from Jonathan Wakely --- Yup, the seconds part "00.002" is parsed using std::numpunct (in order to handle the locale's decimal point) and then converted to milliseconds using duration_cast: auto& __ng =

Results for 14.0.1 20240306 (experimental) [remotes/origin/HEAD r14-9346-g74e8cc28ed] (GCC) testsuite on powerpc64le-unknown-linux-gnu

Summary === # of expected passes178997 # of unexpected failures116 # of unexpected successes 19 # of expected failures 1614 # of unsupported tests 4171 /home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240306 (experimental) [remote

[Linaro-TCWG-CI] gcc-14-9343-gb575f37a342: FAIL: 6 regressions on arm

Dear contributor, our automatic CI has detected problems related to your patch(es). Please find some details below. If you have any questions, please follow up on linaro-toolch...@lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer

[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240 --- Comment #5 from Jonathan Wakely --- >using __format::_ChronoParts; >auto __need = _ChronoParts::_Year | _ChronoParts::_Month > - | _ChronoParts::_Day | _ChronoParts::_TimeOfDay; > + |

Results for 13.2.1 20240306 [releases/gcc-13 r13-8407-g1f5787e4b8] (GCC) testsuite on powerpc64le-unknown-linux-gnu

htly/build-gcc-13/gcc/xgcc version 13.2.1 20240306 [releases/gcc-13 r13-8407-g1f5787e4b8] (GCC) === gfortran tests === Running target unix XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O1 execution

[Bug c++/106851] [modules] Name conflict for exported using-declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106851 --- Comment #6 from Jonathan Wakely --- Excellent! Thanks for the fix.

Re: [PATCH] c-family, c++, v2: Fix up handling of types which may have padding in __atomic_{compare_}exchange

On 2/20/24 05:02, Jakub Jelinek wrote: On Tue, Feb 20, 2024 at 09:01:10AM +0100, Richard Biener wrote: I'm not sure those would be really equivalent (MEM_REF vs. V_C_E as well as combined vs. split). It really depends how RTL expansion handles this (as you can see padding can be fun here). So

[Bug c++/106851] [modules] Name conflict for exported using-declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106851 --- Comment #5 from Nathaniel Shead --- (In reply to Jonathan Wakely from comment #4) > I tried doing it this way instead > > namespace std { > export using std::vector; > namespace pmr { > export using std::vector; > } > } > > but

[Bug libstdc++/114260] New: std::formatter> formats as the previous day

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114260 Bug ID: 114260 Summary: std::formatter> formats as the previous day Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Results for 13.2.1 20240306 [releases/gcc-13 r13-8407-g1f5787e4b8] (GCC) testsuite on powerpc64le-unknown-linux-gnu

f expected failures 1550 # of unsupported tests 3982 /home/gccbuild/build/nightly/build-gcc-13/gcc/xgcc version 13.2.1 20240306 [releases/gcc-13 r13-8407-g1f5787e4b8] (GCC) === gfortran tests === Running target unix XPASS: gfortran.dg/large_real_kind_form_io_2

Re: [PATCH] dwarf2out, v3: Emit DW_AT_export_symbols on anon unions/structs [PR113918]

On 2/16/24 16:06, Jakub Jelinek wrote: On Fri, Feb 16, 2024 at 03:40:39PM -0500, Jason Merrill wrote: --- gcc/cp/cp-objcp-common.cc.jj2024-02-13 12:50:21.666846296 +0100 +++ gcc/cp/cp-objcp-common.cc 2024-02-16 20:40:51.374763528 +0100 @@ -410,6 +410,15 @@ cp_type_dwarf_attribute

Re: [PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802]

On 2/16/24 17:15, Jakub Jelinek wrote: On Fri, Feb 16, 2024 at 10:47:47PM +0100, Jakub Jelinek wrote: The following patch works. Or yet another option would be instead of (sometimes) clearing declarator->parameter_pack_p when we diagnose this bug for error recovery ignore the this specifier.

Results for 14.0.1 20240306 (experimental) [master revision gcc-14-9346-g74e8cc28eda] (GCC) testsuite on aarch64-unknown-linux-gnu

d failures310 # of expected failures 1764 # of unresolved testcases 1 # of unsupported tests 4410 /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/aarch64-linux-gnu-gcc version 14.0.1 20240306 (experimental) [master revision g

Results for 14.0.1 20240306 (experimental) [master r14-9343-gb575f37a342] (GCC) testsuite on s390x-ibm-linux-gnu default

ghil\\t%r2,1 FAIL: gcc.target/s390/vector/vec-scalar-cmp-1.c scan-assembler ne:\\n[^:]*\\twfcdb\\t%v[0-9]*,%v[0-9]*\\n\\t[^:]+\\tlocghine\\t%r2,1 XPASS: gcc.target/s390/vxe/popcount-1.c scan-assembler vpopctb\\t%v24,%v24 XPASS: gcc.target/s390/vxe/popcount-1.c scan-assembler vpopcth\\t%v24,%v24

[Bug rtl-optimization/101523] Huge number of combine attempts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #18 from Andrew Pinski --- Hmm, looking at what is done in combine, I wonder why forwprop didn't do the address add into the memory. That would definitely decrease the # of combines being done. Maybe it is because it is used more

Re: [PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

On 6 Mar 2024, at 15:57, FX Coudert wrote: > >> Hmm I recall trying it and finding a problem - was there some different fix >> applied >> in the end? > > The bug is still open, I don’t think a patch was applied, and I don’t find > any email to the list stating what the problem could be. The

Results for 14.0.1 20240306 (experimental) [remotes/origin/HEAD r14-9346-g74e8cc28eda] (GCC) testsuite on powerpc64le-unknown-linux-gnu

=== gcc Summary === # of expected passes178997 # of unexpected failures132 # of unexpected successes 19 # of expected failures 1614 # of unsupported tests 4169 /home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240306 (ex

[Bug rtl-optimization/101523] Huge number of combine attempts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #17 from Segher Boessenkool --- Why does this happen so extremely often for s390x customers? It should from first principles happen way more often for e.g. powerpc, but we never see such big problems, let alone "all of the time"!

  1   2   3   4   5   >