[PATCH 3/3] rs6000: Teach legitimate_address_p about LEN_{LOAD, STORE} [PR110248]

Hi, This patch is to teach rs6000_legitimate_address_p to handle the queried rtx constructed for LEN_{LOAD,STORE}, since lxvl and stxvl doesn't support x-form or ds-form, so consider it as not legitimate when outer code is PLUS. This can help to fix SPEC2017 503.bwaves_r degradation as reported

[PATCH 2/3] ivopts: Call valid_mem_ref_p with code_helper [PR110248]

Hi, As PR110248 shows, to get the expected query results for that case internal functions LEN_{LOAD,STORE} is unable to adopt some addressing modes, we need to pass down the related IFN code as well. This patch is to make IVOPTs pass down ifn code for USE_PTR_ADDRESS type uses, it adjusts the

[PATCH 1/3] targhooks: Extend legitimate_address_p with code_helper [PR110248]

Hi, As PR110248 shows, some middle-end passes like IVOPTs can query the target hook legitimate_address_p with some artificially constructed rtx to determine whether some addressing modes are supported by target for some gimple statement. But for now the existing legitimate_address_p only checks

[PATCH] Collect both user and kernel events for autofdo tests and autoprofiledbootstrap

When we collect just user events for autofdo with lbr we get some events where branch sources are kernel addresses and branch targets are user addresses. Without kernel MMAP events create_gcov can't make sense of kernel addresses. Currently create_gcov fails if it can't map at least 95% of

[PATCH] tree.h: Hide wi::from_mpz from GENERATOR_FILE

Hi, Similar to r0-85707-g34917a102a4e0c for PR35051, the uses of mpz_t should be guarded with "#ifndef GENERATOR_FILE". This patch is to fix it and avoid some possible build errors. Bootstrapped and regress-tested on x86_64-redhat-linux, and powerpc64{,le}-linux-gnu. And cross-build well on

[Bug tree-optimization/110494] [14 Regression] Wrong code at -O3 on x86_64-pc-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110494 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252 --- Comment #12 from Andrew Pinski --- *** Bug 110494 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/110494] New: [14 Regression] Wrong code at -O3 on x86_64-pc-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110494 Bug ID: 110494 Summary: [14 Regression] Wrong code at -O3 on x86_64-pc-linux-gnu Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

Re: PR82943 - Suggested patch to fix

On Thu, Jun 29, 2023 at 10:38:42PM -0500, Alexander Westbrooks via Fortran wrote: > I have finished my testing, and updated my patch and relevant Changelogs. I > added 4 new tests and all the existing tests in the current testsuite > for gfortran passed or failed as expected. Do I need to attach

[Bug c++/110493] 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110493 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #3 from Andrew Pinski

[Bug libstdc++/110493] 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110493 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |--- See Also|

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962 --- Comment #11 from Andrew Pinski --- *** Bug 110493 has been marked as a duplicate of this bug. ***

[Bug libstdc++/110493] 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110493 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug libstdc++/110493] New: 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110493 Bug ID: 110493 Summary: 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined Product: gcc Version: 12.3.0

[Bug c++/92752] [10 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92752 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:8c12c47d0c5c40df6e5eeb8625d4708c8a42dbe0 commit r10-11483-g8c12c47d0c5c40df6e5eeb8625d4708c8a42dbe0 Author: Patrick Palka

[Bug c++/97420] [10 Regression] NTTP function reference cannot bind to noexcept function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ad42219766d0e67bede2c9bd94c98082cde42518 commit r10-11482-gad42219766d0e67bede2c9bd94c98082cde42518 Author: Patrick Palka

[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108672 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED

Inquiry about Getting Started with GCC Projects as a Beginner

Dear GCC Company, I hope this email finds you well. I am writing to express my interest in working on GCC projects as a beginner and seeking guidance on how to get started. I am excited about the opportunity to contribute to your projects and gain valuable experience in the process. As a

PR108672 re-fixed after [PATCH] libstdc++: Synchronize PSTL with upstream

> Date: Mon, 26 Jun 2023 11:57:49 -0700 > From: Thomas Rodgers via Gcc-patches > On Wed, May 17, 2023 at 12:32 PM Jonathan Wakely wrote: > > All the actual code changes look good. Unfortunately, this overwrote the fix for PR108672. I take it there's a step missing from the synchronization

Re: PR82943 - Suggested patch to fix

Hello, I have finished my testing, and updated my patch and relevant Changelogs. I added 4 new tests and all the existing tests in the current testsuite for gfortran passed or failed as expected. Do I need to attach the test results here? The platform I tested on was a Docker container running

Re: [PATCH] rs6000: Update the vsx-vector-6.* tests.

Hi Carl, on 2023/6/30 05:36, Carl Love wrote: > Kewen: > > On Wed, 2023-06-28 at 16:35 +0800, Kewen.Lin wrote: >>> Yea, I was going with a runnable test and didn't include the >>> instruction counts. Added back in. Rather then doing by processor >>> version (P8, P9, P10) I was able to do it by

[Bug c++/110492] Attempted optimization of switch statement pessimizes it instead

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110492 --- Comment #1 from Andrew Pinski --- Created attachment 55431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55431=edit testcase Next time please attach or paste inline the code instead of posting just a link to godbolt.org .

[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108672 --- Comment #4 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:b22cf5f0321f6425a357c06647a4366d99ddac61 commit r14-2206-gb22cf5f0321f6425a357c06647a4366d99ddac61 Author: Hans-Peter Nilsson

[Bug target/109435] overaligned structs are not passed correctly for mips64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 --- Comment #4 from CVS Commits --- The master branch has been updated by YunQiang Su : https://gcc.gnu.org/g:e20abdb749d0c0c8552da998ff8ec139b830f5eb commit r14-2205-ge20abdb749d0c0c8552da998ff8ec139b830f5eb Author: Jovan Dmitrovic Date:

Re: [PATCH] rs6000, __builtin_set_fpscr_rn add retrun value

On 6/29/23 4:13 AM, Kewen.Lin wrote: > on 2023/6/19 23:57, Carl Love wrote: >> The following patch changes the return type of the >> __builtin_set_fpscr_rn builtin from void to double. The return value >> is the current value of the various FPSCR fields DRN, VE, OE, UE, ZE, >> XE, NI, RN bit

[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108672 Hans-Peter Nilsson changed: What|Removed |Added Resolution|FIXED |--- Ever confirmed|0

[Bug c++/110492] New: Attempted optimization of switch statement pessimizes it instead

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110492 Bug ID: 110492 Summary: Attempted optimization of switch statement pessimizes it instead Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[PATCH V2] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

From: Ju-Zhe Zhong Hi, Richi and Richard. This patch is adding LEN_MASK_{GATHER_LOAD,SCATTER_STORE} to allow targets handle flow control by mask and loop control by length on gather/scatter memory operations. Consider this following case: #include void f (uint8_t *restrict a, uint8_t

[Bug c/110491] Wrong code at -O2 on x86_64-linux-gnu (a recent regression)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110491 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #19 from Andrew Pinski --- *** Bug 110491 has been marked as a duplicate of this bug. ***

[PATCH v1 4/6] LoongArch: Added Loongson ASX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Added compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. *

[PATCH v1 1/6] LoongArch: Added Loongson SX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Added compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. *

[PATCH v1 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

These patches add the Loongson SX/ASX instruction support to the LoongArch target, and can be utilized by using the new "-mlsx" and "-mlasx" option. Patches are bootstrapped and tested on loongarch64-linux-gnu target. Lulu Cheng (6): LoongArch: Added Loongson SX vector directive compilation

Re: Re: [PATCH] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

Thanks for the comments. I will fix doc's description as you suggested. I personally prefer **NOT** to include BIAS in the gather/scatter since I don't known how it will be used. Let's wait for Richi or Richard more comments. Thanks. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-29

RE: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

That’s very cool, thanks Thomas for help! Let’s wait the AMD test running result for the final version of the patch. Pan From: juzhe.zh...@rivai.ai Sent: Friday, June 30, 2023 9:27 AM To: Thomas Schwinge ; Li, Pan2 ; gcc-patches ; rguenther ; jakub Cc: Robin Dapp ; jeffreyalaw ; Wang,

[Bug c/110491] New: Wrong code at -O2 on x86_64-linux-gnu (a recent regression)

ured with: ../configure --disable-multilib --disable-bootstrap --enable-languages=c,c++ --prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-5f590ee3174cf6058ac882c3a84a96ae639349c8 Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230629 (experimental) (GCC) $

Re: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

>> I've triple checked this already. You mean you still didn't see vfwmul.vv ? That's odd. Let's wait for kito or Robin test this patch. Then, I believe they will know what I am saying. >> I would strongly suggest looking at a dependency height reduction >> pattern if you want to optimize that

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

On 6/29/23 19:14, juzhe.zh...@rivai.ai wrote: No, reduction patterns won't help. As I said in vfwmul patch. You should make sure your environment is working then try again. I've triple checked this already. I checked it again and your patch does not impact behavior, nor should it. I

Re: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Thanks a lot! Really appreciate your help ! That's really helpful for RVV (RISC-V vector). Could you merge your patch after you tested? Thanks. juzhe.zh...@rivai.ai From: Thomas Schwinge Date: 2023-06-30 04:14 To: Pan Li; gcc-patches@gcc.gnu.org; Richard Biener; Jakub Jelinek CC:

Re: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

No, reduction patterns won't help. As I said in vfwmul patch. You should make sure your environment is working then try again. Thanks. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-06-30 07:43 To: 钟居哲; gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc Subject: Re: [PATCH]

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

Hi, Jeff. That's odd. I think maybe you should first clean up your environment ? Or you didn't build up the toolchain correctly with this patch? Compile option: --param=riscv-autovec-preference=scalable -O3 -ffast-math Before this patch: https://godbolt.org/z/Y5d44WMqs fail.s: lw t5,0(sp) ble

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/29/23 17:46, juzhe.zhong wrote: You should try the example check the codegen before and after the patch. You will understand it. I've already done that. It makes _no_ difference on the godbold example. Jeff

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

On 6/28/23 16:56, 钟居哲 wrote: juzhe.zh...@rivai.ai *From:* Jeff Law *Date:* 2023-06-29 06:43 *To:* 钟居哲 ; gcc-patches

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb You patch doesn't help that code and your patch is a result of fundamentally misunderstanding combine's capabilities AFAICT. Jeff

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb So just to be explicit, I see no difference with that test before/after your proposed change. Nor would I expect one based on my understanding of the patch. The explicit

[Bug analyzer/110198] [14 regression] g++.dg/analyzer/pr100244.C fails after r14-1632-g9589a46ddadc8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198 Benjamin Priour changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug analyzer/110198] [14 regression] g++.dg/analyzer/pr100244.C fails after r14-1632-g9589a46ddadc8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Benjamin Priour : https://gcc.gnu.org/g:1eb90f46c16453f72dc119ba20b07053a15b452d commit r14-2203-g1eb90f46c16453f72dc119ba20b07053a15b452d Author: benjamin priour Date:

[Bug middle-end/110443] [14 Regression] ICE on a52dec-0.7.4: GIMPLE pass: vect SIGSEGV in vect_get_gather_scatter_ops()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110443 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |--- CC|

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110487 --- Comment #3 from Andrew Pinski --- /* Optimize # x_5 in range [cst1, cst2] where cst2 = cst1 + 1 x_5 ? cstN ? cst4 : cst3 # op is == or != and N is 1 or 2 to r_6 = x_5 + (min (cst3, cst4) - cst1) or r_6 = (min (cst3, cst4) +

[PATCH ver 3] rs6000: Update the vsx-vector-6.* tests.

GCC maintainers: Ver 3. Added __attribute__ ((noipa)) to the test files. Changed some of the scan-assembler-times checks to cover multiple similar instructions. Change the function check macro to a macro to generate a function to do the test and check the results. Retested on the various

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

Or do you have better solution to make the case succeed to combine into vfwmul? I am ok with any solution. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-06-30 06:59 To: 钟居哲; gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc Subject: Re: [PATCH] RISC-V: Support vfwmul.vv

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

>> Right now I don't see a need for this patch. No, we need this patch. With this patch, this following case can be combine into vfwmul.vv: #define TEST_TYPE(TYPE1, TYPE2)\ __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 (

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2d40cd2f199e32f185d4b72db2043e91313ab7f2 commit r13-7511-g2d40cd2f199e32f185d4b72db2043e91313ab7f2 Author: Jonathan

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ae7cdc8c0f5278e7941f1de7c72ffe9f1fed2775 commit r13-7510-gae7cdc8c0f5278e7941f1de7c72ffe9f1fed2775 Author: Jonathan

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741 --- Comment #17 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:dbd4acd72274f3b3d542ebf68f9962eda8f8b769 commit r13-7509-gdbd4acd72274f3b3d542ebf68f9962eda8f8b769 Author: Jonathan

[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285 --- Comment #16 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:132015b9c6c9f9156ff31f7d66ba92cf01d0bc90 commit r13-7508-g132015b9c6c9f9156ff31f7d66ba92cf01d0bc90 Author: Jonathan

[Bug libstdc++/52799] deque::emplace(iterator, ...) tries to call push_front(...), which doesn't exist

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52799 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:52997b14311726447850341ecaf286b68587ff32 commit r13-7505-g52997b14311726447850341ecaf286b68587ff32 Author: Jonathan

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb The first case can't genreate vfwmul.vv but second case succeed. Failed to match this instruction: (set (reg:VNx2DF 150 [ vect__11.50 ])     (if_then_else:VNx2DF (unspec:VNx2BI

[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org

gcc-11-20230629 is now available

Snapshot gcc-11-20230629 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20230629/ and on various mirrors, see http://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

Re: [PATCH] c++: fix up caching of level lowered ttps

On 6/1/23 17:42, Patrick Palka wrote: Due to level/depth mismatches between the template parameters of a level lowered ttp and the original ttp, the ttp comparison check added by r14-418-g0bc2a1dc327af9 never actually holds outside of erroneous cases. Moreover, it'd be good to cache the overall

Re: [PATCH 2/19][front-end] C/C++ front-end: add pragma GCC novector

On 6/28/23 09:41, Tamar Christina wrote: Hi All, FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should not be applied to a particular loop. ICC/ICX also has such a pragma for C and C++ called #pragma novector. As part of this patch series I need a way to easily turn

[Bug tree-optimization/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110490 --- Comment #3 from Andrew Pinski --- I was wrong about where the problem was but not wrong about the missed optimization. Anyways the issue is in expression_expensive_p where the issue of clzdi2 and not having clzsi2 ...

Re: [PATCH] rs6000: Update the vsx-vector-6.* tests.

Kewen: On Wed, 2023-06-28 at 16:35 +0800, Kewen.Lin wrote: > > Yea, I was going with a runnable test and didn't include the > > instruction counts. Added back in. Rather then doing by processor > > version (P8, P9, P10) I was able to do it by BE/LE. The > > instruction > > counts were the same

[Bug tree-optimization/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110490 Andrew Pinski changed: What|Removed |Added Component|testsuite |tree-optimization Ever confirmed|0

Re: [PATCH v1] RISC-V: Refactor vxrm_mode attr for type attr equal

On 6/29/23 00:00, pan2...@intel.com wrote: From: Pan Li This patch would like to refactor the vxrm_mode attr for duplicated eq_attr condition. The common condition of attr is extraced to one place instead of many places. Signed-off-by: Pan Li gcc/ChangeLog: *

Extend ipa-fnsummary to skip __builtin_expect

Compute ipa-predicates for conditionals involving __builtin_expect_p std::vector allocator looks as follows: __attribute__((nodiscard)) struct pair * std::__new_allocator >::allocate (struct __new_allocator * const this, size_type __n, const void * D.27753) { bool _1; long int _2; long

[Bug middle-end/109849] suboptimal code for vector walking loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #19 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:9dc18fca431626404b0692c689a2e103666e7adb commit r14-2202-g9dc18fca431626404b0692c689a2e103666e7adb Author: Jan Hubicka Date: Thu

[Bug testsuite/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110490 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment

Re: [PATCH] analyzer: Fix regression bug after r14-1632-g9589a46ddadc8b [PR110198]

On Thu, 2023-06-29 at 20:45 +0200, priour...@gmail.com wrote: > From: benjamin priour > > See below formatting updates on my patch. > In mail > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623140.html, > David Malcolm says regtesting failed for him. > > So I did it once more this morning

Re: [PATCH] testsuite: Use -fno-report-bug in gcc.dg/plugin/

On Thu, 2023-06-29 at 15:03 -0400, Marek Polacek wrote: > Certain downstream compilers (for example, in Fedora) default to > -freport-bug.  The extra output breaks the following tests.  We can > use > -fno-report-bug to fix that.  Patch verified with: > > $ make check

[Bug testsuite/110490] New: tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110490 Bug ID: 110490 Summary: tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483 --- Comment #1 from David Malcolm --- Thanks for filing this; sorry about the failures. What's the endianness of the hosts that this is happening on? Is there a machine in the GCC compile farm that this happens on? The row of indices is is

Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Hi! On 2023-06-29T11:29:57+0200, I wrote: > On 2023-06-21T15:58:24+0800, Pan Li via Gcc-patches > wrote: >> We extend the machine mode from 8 to 16 bits already. But there still >> one placing missing from the streamer. It has one hard coded array >> for the machine code like size 256. >> >> In

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > protector-strong. > > > To avoid

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > protector-strong. >

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > These tests fail when the testsuite is executed with -fstack- > > protector-strong. > > To avoid this, this patch adds -fno-stack-protector to dg-options. > > > >

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Thu, Jun 29, 2023 at 04:01:20PM -0400, Marek Polacek via Gcc-patches wrote: > These tests fail when the testsuite is executed with -fstack-protector-strong. > To avoid this, this patch adds -fno-stack-protector to dg-options. > > Tested on x86_64-pc-linux-gnu, ok for trunk? > >

[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110468 --- Comment #13 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9479da4515f7d019b4ef282d0e21536431c44f71 commit r14-2199-g9479da4515f7d019b4ef282d0e21536431c44f71 Author: Patrick Palka Date:

[Bug c++/110463] [13/14 Regression] Mutable subobject is usable in a constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110463 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:fd8a1be04d4cdbfefea457b99ed8404d77b35dd6 commit r14-2198-gfd8a1be04d4cdbfefea457b99ed8404d77b35dd6 Author: Patrick Palka Date:

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > These tests fail when the testsuite is executed with -fstack- > protector-strong. > To avoid this, this patch adds -fno-stack-protector to dg-options. > > Tested on x86_64-pc-linux-gnu, ok for trunk? LGTM, we've noticed

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #30 from anlauf at gcc dot gnu.org --- BTW: you can get a traceback on FP exceptions by adding to the linker options: -ffpe-trap=zero,overflow,invalid

[Bug analyzer/94355] analyzer support for C++ new expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355 --- Comment #15 from Benjamin Priour --- (In reply to Jonathan Wakely from comment #14) > [...snip...] > > See the -fcheck-new option: > > Check that the pointer returned by "operator new" is non-null before > attempting to modify the

[PATCH] i386: add -fno-stack-protector to two tests

These tests fail when the testsuite is executed with -fstack-protector-strong. To avoid this, this patch adds -fno-stack-protector to dg-options. Tested on x86_64-pc-linux-gnu, ok for trunk? gcc/testsuite/ChangeLog: * gcc.target/i386/pr104610.c: Use -fno-stack-protector. *

[Bug middle-end/110489] Slow building virtual.c.i from p11-kit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110489 --- Comment #2 from Andrew Pinski --- So I took a look at the sources, there are very many small functions. This might be the reason why dump files Timevar takes a long time, it is called for each pass and for each function. Maybe that can be

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|---

[Bug fortran/100297] FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1a023e688186ea4cd284f5d269f2ecde9f80438c commit r13-7501-g1a023e688186ea4cd284f5d269f2ecde9f80438c Author: Harald Anlauf

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277 --- Comment #35 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:74ef4221b5ebb1122349ad48422ddc40e98c267d commit r13-7502-g74ef4221b5ebb1122349ad48422ddc40e98c267d Author: Harald Anlauf

[Bug testsuite/83904] gfortran.dg allocatable_function_1 failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1a023e688186ea4cd284f5d269f2ecde9f80438c commit r13-7501-g1a023e688186ea4cd284f5d269f2ecde9f80438c Author: Harald Anlauf

[Bug middle-end/110489] Slow building virtual.c.i from p11-kit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110489 --- Comment #1 from Andrew Pinski --- The only ones that stick out are: dump files : 1.07 ( 4%) 0.24 ( 5%) 1.58 ( 5%) 0 ( 0%) integrated RA : 1.75 ( 7%) 0.11 ( 2%) 2.10 (

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #29 from Jürgen Reuter --- (In reply to anlauf from comment #28) > Update: recompiling that file with 13-branch fails for me, too. > Playing with the one-line patch for pr86277 makes no difference, fortunately. > > Compiling the

[Bug c/110489] New: Slow building virtual.c.i from p11-kit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110489 Bug ID: 110489 Summary: Slow building virtual.c.i from p11-kit Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #28 from anlauf at gcc dot gnu.org --- Update: recompiling that file with 13-branch fails for me, too. Playing with the one-line patch for pr86277 makes no difference, fortunately. Compiling the file with gfortran-12 seems to work

Re: types in GIMPLE IR

On Thu, Jun 29, 2023 at 12:10 PM Krister Walfridsson via Gcc wrote: > > On Thu, 29 Jun 2023, Richard Biener wrote: > > > IIRC we have some simplification rules that turn bit operations into > > arithmetics. Arithmetic is allowed if it keeps the values inside > > [-1,0] for signed bools or [0, 1]

[Bug ada/110488] New: Legal deferred constant rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110488 Bug ID: 110488 Summary: Legal deferred constant rejected Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada

[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852 --- Comment #18 from Jonathan Wakely --- That's not a crash, it's a warning. And it looks like a separate problem, since it comes from vector::reserve not vector::insert. Please file a new bug for it instead.

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110487 Andrew Pinski changed: What|Removed |Added Summary|invalid wide Boolean value |[12/13/14 Regression]

[Bug tree-optimization/110487] invalid wide Boolean value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110487 --- Comment #2 from Andrew Pinski --- Part of the issue is what does TYPE_PRECISION on BOOLEAN_TYPE really mean. there are many more of these issues all over GCC about boolean types assuming being TYPE_PRECISION == 1 even and such.

[Bug tree-optimization/110487] invalid wide Boolean value

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

  1   2   3   >