[gcc r14-10222] PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143]

https://gcc.gnu.org/g:89ab128656b9da1359705bd770ae7d2367b33ec2 commit r14-10222-g89ab128656b9da1359705bd770ae7d2367b33ec2 Author: Andrew Pinski Date: Sat May 18 11:55:58 2024 -0700 PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143] The problem here is even if

[gcc r15-699] PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143]

https://gcc.gnu.org/g:9ff8f041331ef8b56007fb3c4d41d76f9850010d commit r15-699-g9ff8f041331ef8b56007fb3c4d41d76f9850010d Author: Andrew Pinski Date: Sat May 18 11:55:58 2024 -0700 PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143] The problem here is even if

[gcc r15-697] aarch64: Fold vget_low_* intrinsics to BIT_FIELD_REF [PR102171]

https://gcc.gnu.org/g:a2e4fe5a53cf75cd055f64e745ebd51253e42254 commit r15-697-ga2e4fe5a53cf75cd055f64e745ebd51253e42254 Author: Pengxuan Zheng Date: Mon May 13 10:47:10 2024 -0700 aarch64: Fold vget_low_* intrinsics to BIT_FIELD_REF [PR102171] This patch folds vget_low_*

[RFC] New optab for `a&~b` (and future expand improvements)

Hi all, This is an RFC more than anything and I will be implementing the ideas here. So thinking about how to improve code generation in general and depend less on RTL passes (like combine) to do some instruction selection. So there are 2 ways of implementing this but both involve adding

[gcc r15-501] tree-cfg: Move the returns_twice check to be last statement only [PR114301]

https://gcc.gnu.org/g:642f31d6286b8a342130fbface51530befd975fd commit r15-501-g642f31d6286b8a342130fbface51530befd975fd Author: Andrew Pinski Date: Tue May 14 06:29:18 2024 -0700 tree-cfg: Move the returns_twice check to be last statement only [PR114301] When I was checking to

[gcc r11-11422] Fix PR 110386: backprop vs ABSU_EXPR

https://gcc.gnu.org/g:dbfc2d075f10149bd94e16c1210ffe4bac7e60c3 commit r11-11422-gdbfc2d075f10149bd94e16c1210ffe4bac7e60c3 Author: Andrew Pinski Date: Sat Sep 23 21:53:09 2023 -0700 Fix PR 110386: backprop vs ABSU_EXPR The issue here is that when backprop tries to go and strip

[gcc r12-10434] Fix PR 110386: backprop vs ABSU_EXPR

https://gcc.gnu.org/g:f5c7306d7f039e5c74c5e82cf06610f0ae07a0e8 commit r12-10434-gf5c7306d7f039e5c74c5e82cf06610f0ae07a0e8 Author: Andrew Pinski Date: Sat Sep 23 21:53:09 2023 -0700 Fix PR 110386: backprop vs ABSU_EXPR The issue here is that when backprop tries to go and strip

[gcc r12-10433] testsuite: fix Wmismatched-new-delete-8.C with -m32

https://gcc.gnu.org/g:58d11bfc27d5412619c0919738158a4c05cca2cf commit r12-10433-g58d11bfc27d5412619c0919738158a4c05cca2cf Author: Marek Polacek Date: Thu Feb 22 18:52:32 2024 -0500 testsuite: fix Wmismatched-new-delete-8.C with -m32 This fixes error: 'operator new' takes type

[gcc r12-10432] warn-access: Fix handling of unnamed types [PR109804]

https://gcc.gnu.org/g:16319f8fba6c049d743046488588f40da2349048 commit r12-10432-g16319f8fba6c049d743046488588f40da2349048 Author: Andrew Pinski Date: Wed Feb 21 20:12:21 2024 -0800 warn-access: Fix handling of unnamed types [PR109804] This looks like an oversight of handling

[gcc r12-10431] Fix PR 111331: wrong code for `a > 28 ? MIN : 29`

https://gcc.gnu.org/g:39d56b96996dd8336652ceac97983c26fd8de4c6 commit r12-10431-g39d56b96996dd8336652ceac97983c26fd8de4c6 Author: Andrew Pinski Date: Thu Sep 7 22:13:31 2023 -0700 Fix PR 111331: wrong code for `a > 28 ? MIN : 29` The problem here is after

[gcc r11-11421] Fix PR 111331: wrong code for `a > 28 ? MIN : 29`

https://gcc.gnu.org/g:16e27b6d03756bf1fae22607fa93107787a7b9cb commit r11-11421-g16e27b6d03756bf1fae22607fa93107787a7b9cb Author: Andrew Pinski Date: Thu Sep 7 22:13:31 2023 -0700 Fix PR 111331: wrong code for `a > 28 ? MIN : 29` The problem here is after

[gcc r11-11420] Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351]

https://gcc.gnu.org/g:6c00c3245e688d00dae3e928f0d03f530640caae commit r11-11420-g6c00c3245e688d00dae3e928f0d03f530640caae Author: Andrew Pinski Date: Sun Mar 10 22:17:09 2024 + Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351] The problem here is that

[gcc r12-10430] Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351]

https://gcc.gnu.org/g:d88fe8210e4edc2f4ddf722ba788924452c6f6a0 commit r12-10430-gd88fe8210e4edc2f4ddf722ba788924452c6f6a0 Author: Andrew Pinski Date: Sun Mar 10 22:17:09 2024 + Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351] The problem here is that

[gcc r13-8728] Fix PR 110066: crash with -pg -static on riscv

https://gcc.gnu.org/g:929b0fffe4d3d836e07e5a398a8e176e65f8b2c2 commit r13-8728-g929b0fffe4d3d836e07e5a398a8e176e65f8b2c2 Author: Andrew Pinski Date: Sat Jul 22 08:52:42 2023 -0700 Fix PR 110066: crash with -pg -static on riscv The problem -fasynchronous-unwind-tables is on by

[gcc r15-328] match: `a CMP nonnegative ? a : ABS` simplified to just `ABS` [PR112392]

https://gcc.gnu.org/g:5726de79e2154a16d8a045567d2cfad035f7ed19 commit r15-328-g5726de79e2154a16d8a045567d2cfad035f7ed19 Author: Andrew Pinski Date: Mon May 6 23:53:41 2024 -0700 match: `a CMP nonnegative ? a : ABS` simplified to just `ABS` [PR112392] We can optimize `a ==

[gcc r11-11419] c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]

https://gcc.gnu.org/g:046aeffba336295fbdaf0e1ecf64b582d08f0aa6 commit r11-11419-g046aeffba336295fbdaf0e1ecf64b582d08f0aa6 Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After

[gcc r12-10420] c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]

https://gcc.gnu.org/g:315f8a474eb1a9b2d213aa650bdb132c78546264 commit r12-10420-g315f8a474eb1a9b2d213aa650bdb132c78546264 Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After

[gcc r13-8713] c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]

https://gcc.gnu.org/g:f5d9eef6507f36692066c0934d9f8c9d462e698f commit r13-8713-gf5d9eef6507f36692066c0934d9f8c9d462e698f Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After

[gcc r14-10183] c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]

https://gcc.gnu.org/g:cacc48014c7fdb888b4449830b567e5375dfb4e3 commit r14-10183-gcacc48014c7fdb888b4449830b567e5375dfb4e3 Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After

[gcc r15-309] c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]

https://gcc.gnu.org/g:4421d35167b3083e0f2e4c84c91fded09a30cf22 commit r15-309-g4421d35167b3083e0f2e4c84c91fded09a30cf22 Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After

[gcc r15-308] DCE __cxa_atexit calls where the function is pure/const [PR19661]

https://gcc.gnu.org/g:c9dd853680b12d9c9def5de61abde5d057c526ba commit r15-308-gc9dd853680b12d9c9def5de61abde5d057c526ba Author: Andrew Pinski Date: Fri Mar 15 16:34:22 2024 -0700 DCE __cxa_atexit calls where the function is pure/const [PR19661] In C++ sometimes you have a

[gcc r15-307] MATCH: Add some more value_replacement simplifications (a != 0 ? expr : 0) to match

https://gcc.gnu.org/g:e472527c7b45d23e8dfd0fb767a6e663b4bc136e commit r15-307-ge472527c7b45d23e8dfd0fb767a6e663b4bc136e Author: Andrew Pinski Date: Tue Apr 30 14:45:26 2024 -0700 MATCH: Add some more value_replacement simplifications (a != 0 ? expr : 0) to match This adds a few

Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)

On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote: > > On 5/7/24 00:02, Toon Moene wrote: > > > OK, perhaps on the aarch64 I need the following option to make the > > comparison fair: > > > > ‘rdma’ > > > > Enable Round Double Multiply Accumulate instructions. This is on by > > default for

[gcc r15-237] Mention that some options are turned on by `-Ofast` in their descriptions [PR97263]

https://gcc.gnu.org/g:0920e64ffa55adb063174559b274b0a521f34934 commit r15-237-g0920e64ffa55adb063174559b274b0a521f34934 Author: Andrew Pinski Date: Mon May 6 14:14:41 2024 -0700 Mention that some options are turned on by `-Ofast` in their descriptions [PR97263] Like was done for

Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)

On Mon, May 6, 2024 at 2:27 PM Toon Moene wrote: > > I have now, for some time, ran LAPACK's test programs on my gcc/gfortran > builds on both on the x86_64-linux-gnu architecture, as well as the > aarch64-linux-gnu one (see, e.g., > http://moene.org/~toon/lapack-amd64-gfortran13-O3). > > The

[gcc r15-212] aarch64: Fix gcc.target/aarch64/sve/loop_add_6.c for LLP64 targets

https://gcc.gnu.org/g:53026cbf08889d00fed34d8667796d22ef8554cf commit r15-212-g53026cbf08889d00fed34d8667796d22ef8554cf Author: Andrew Pinski Date: Mon May 6 12:20:17 2024 -0700 aarch64: Fix gcc.target/aarch64/sve/loop_add_6.c for LLP64 targets Even though the aarch64-mingw32

[gcc r15-166] Remove m_nloops field from loop_versioning

https://gcc.gnu.org/g:ffb521f157fec823907913602ed5cb73dd1c63e8 commit r15-166-gffb521f157fec823907913602ed5cb73dd1c63e8 Author: Andrew Pinski Date: Sat Apr 27 18:54:43 2024 -0700 Remove m_nloops field from loop_versioning This is a small cleanup of loop_versioning where m_nloops

[gcc r15-139] Fix printing COMPOUND_EXPR in .original [PR23872]

https://gcc.gnu.org/g:04f24e44fb14a22516444f70503719f3fda15d6c commit r15-139-g04f24e44fb14a22516444f70503719f3fda15d6c Author: Andrew Pinski Date: Tue Apr 16 17:43:36 2024 -0700 Fix printing COMPOUND_EXPR in .original [PR23872] Starting with the merge of the openmp branch into

[gcc r15-77] Fix the build: error message `quote`

https://gcc.gnu.org/g:1ff71f71a13f5ed423389d20ed34f3217e632777 commit r15-77-g1ff71f71a13f5ed423389d20ed34f3217e632777 Author: Andrew Pinski Date: Tue Apr 30 09:44:52 2024 -0700 Fix the build: error message `quote` The problem here is the quote mark is for English's

[gcc r15-74] MATCH: change single_non_singleton_phi_for_edges for singleton phis

https://gcc.gnu.org/g:9c18bdb07e299b25e7526fea16659c7ff8f0d14e commit r15-74-g9c18bdb07e299b25e7526fea16659c7ff8f0d14e Author: Andrew Pinski Date: Sat Apr 27 18:54:44 2024 -0700 MATCH: change single_non_singleton_phi_for_edges for singleton phis I noticed that

[gcc r15-76] PHIOPT: Value-replacement check undef

https://gcc.gnu.org/g:a30d2e6bd0b965e7687f58530a767a3c3b079158 commit r15-76-ga30d2e6bd0b965e7687f58530a767a3c3b079158 Author: Andrew Pinski Date: Sun Apr 28 20:21:02 2024 -0700 PHIOPT: Value-replacement check undef While moving value replacement part of PHIOPT over to use

[gcc r15-75] PHI-OPT: speed up value_replacement slightly

https://gcc.gnu.org/g:611815e0233302e1fa113e6f865fa450b7ae commit r15-75-g611815e0233302e1fa113e6f865fa450b7ae Author: Andrew Pinski Date: Sat Apr 27 18:54:45 2024 -0700 PHI-OPT: speed up value_replacement slightly This adds a few early outs to value_replacement that I

[gcc r15-73] Remove support for nontemporal stores with ssa_names on lhs [PR112976]

https://gcc.gnu.org/g:8614d60233a64afd7e28ae7af2ab74c4a5b06010 commit r15-73-g8614d60233a64afd7e28ae7af2ab74c4a5b06010 Author: Andrew Pinski Date: Wed Apr 17 14:30:06 2024 -0700 Remove support for nontemporal stores with ssa_names on lhs [PR112976] When cfgexpand was changed to

[gcc r15-72] Add verification of gimple_assign_nontemporal_move_p [PR112976]

https://gcc.gnu.org/g:e3a7f359c18bf347f6ac8fcda05e9839fac5bd62 commit r15-72-ge3a7f359c18bf347f6ac8fcda05e9839fac5bd62 Author: Andrew Pinski Date: Wed Apr 17 14:12:17 2024 -0700 Add verification of gimple_assign_nontemporal_move_p [PR112976] Currently the middle-end only knows

Re: Question about information from -fdump-rtl-sched2 on M1 Max

On Mon, Apr 29, 2024 at 4:26 PM Lucier, Bradley J via Gcc wrote: > > The question: How to interpret scheduling info with the compiler listed below. > > Specifically, a tight loop that was reported to be scheduled in 23 cycles (as > I understand it) actually executes in a little over 2 cycles per

[gcc r15-12] aarch64: Use vec_perm_indices::new_shrunk_vector in aarch64_evpc_reencode

https://gcc.gnu.org/g:f91569e779041e2723be23d31c2a79f1861efc7f commit r15-12-gf91569e779041e2723be23d31c2a79f1861efc7f Author: Andrew Pinski Date: Mon Feb 12 15:48:48 2024 -0800 aarch64: Use vec_perm_indices::new_shrunk_vector in aarch64_evpc_reencode While working on PERM

Re: for discussion: should we close all the Java-related bugs?

On Fri, Apr 26, 2024 at 11:28 AM Abe Skolnik via Gcc-bugs wrote: > > Dear all, > > AFAIK, GCJ has been dead for _years_... quoting > : "As of GCC 7, the GCC Java frontend and > associated libjava runtime library have been removed from GCC. The > information on

Re: Build errors for older versions

On Thu, Apr 25, 2024 at 4:21 AM Stefan Schulze Frielinghaus via Gcc wrote: > > Hi all, > > while bisecting I recently ran into build errors like > > In file included from /devel/gcc/libgcc/../gcc/tsystem.h:101, > from /devel/gcc/libgcc/libgcov.h:42, > from

gcc-wwwdocs branch master updated. aef6b8ef509ad182c79437476ef1ee4643a754be

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gcc-wwwdocs". The branch, master has been updated via aef6b8ef509ad182c79437476ef1ee4643a754be (commit) from

[gcc r14-9994] Document that vector_size works with typedefs [PR92880]

https://gcc.gnu.org/g:8eddd87da2dd01c841f9742f973f65ebe0a88e71 commit r14-9994-g8eddd87da2dd01c841f9742f973f65ebe0a88e71 Author: Andrew Pinski Date: Mon Apr 15 17:13:36 2024 -0700 Document that vector_size works with typedefs [PR92880] This just adds a clause to make it more

[gcc r14-9941] match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 bit types [PR114666]

https://gcc.gnu.org/g:245595d72818526e2ca857848831e8afa87ae2de commit r14-9941-g245595d72818526e2ca857848831e8afa87ae2de Author: Andrew Pinski Date: Wed Apr 10 13:39:01 2024 -0700 match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 bit types [PR114666] The problem is `!a?b:c`

Re: [RFC] Linux system call builtins

On Mon, Apr 8, 2024 at 11:20 AM Paul Iannetta via Gcc wrote: > > Hi, > > On Mon, Apr 08, 2024 at 06:19:14AM -0300, Matheus Afonso Martins Moreira via > Gcc wrote: > > Hello! I'm a beginner when it comes to GCC development. > > I want to learn how it works and start contributing. > > Decided to

[gcc r14-9718] Use fatal_error instead of internal_error for when ZSTD is not enabled

https://gcc.gnu.org/g:22f48d78f033922fd2fbf9252041cd97ce201052 commit r14-9718-g22f48d78f033922fd2fbf9252041cd97ce201052 Author: Andrew Pinski Date: Thu Mar 28 16:46:33 2024 -0700 Use fatal_error instead of internal_error for when ZSTD is not enabled This changes an internal

Re: Is --as-needed the default these days?

On Sun, Mar 24, 2024 at 11:54 AM Yuri Kanivetsky via Gcc wrote: > > > That's a linker option, and the linker is not part of GCC. Any change in > > linker behaviour is not because of a change in GCC. > > Have you noticed what gcc does? Upstream GCC does (still) not default to adding `--as-needed`

[gcc r14-9613] Another ICE after conflicting types of redeclaration [PR109619]

https://gcc.gnu.org/g:dbe9062ce070c861cd3fa6435187618413b1b3d1 commit r14-9613-gdbe9062ce070c861cd3fa6435187618413b1b3d1 Author: Andrew Pinski Date: Thu Mar 21 16:29:20 2024 -0700 Another ICE after conflicting types of redeclaration [PR109619] This another one of these ICE after

[gcc r13-8420] Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351]

https://gcc.gnu.org/g:ac96973150b3279fe157f160efd83995077c7590 commit r13-8420-gac96973150b3279fe157f160efd83995077c7590 Author: Andrew Pinski Date: Sun Mar 10 22:17:09 2024 + Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351] The problem here is that

[gcc r13-8419] Reject -fno-multiflags [PR114314]

https://gcc.gnu.org/g:4bd9d097197334e786690ba1566ccf79396da730 commit r13-8419-g4bd9d097197334e786690ba1566ccf79396da730 Author: Andrew Pinski Date: Mon Mar 11 17:40:08 2024 -0700 Reject -fno-multiflags [PR114314] When -fmultiflags option support was added in

[gcc r14-9434] Reject -fno-multiflags [PR114314]

https://gcc.gnu.org/g:c4e5789cede6974b6483c0f82069ff80b5a547e4 commit r14-9434-gc4e5789cede6974b6483c0f82069ff80b5a547e4 Author: Andrew Pinski Date: Mon Mar 11 17:40:08 2024 -0700 Reject -fno-multiflags [PR114314] When -fmultiflags option support was added in

[gcc r14-9422] Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351]

https://gcc.gnu.org/g:31ce2e993d09dcad1ce139a2848a28de5931056d commit r14-9422-g31ce2e993d09dcad1ce139a2848a28de5931056d Author: Andrew Pinski Date: Sun Mar 10 22:17:09 2024 + Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351] The problem here is that

Re: _BitInt() as underlying enum type

On Sat, Jan 27, 2024 at 6:24 PM Andrew Pinski wrote: > > On Sat, Jan 27, 2024 at 6:07 PM Thomas Voss via Gcc-bugs > wrote: > > > > Hi all, > > > > Earlier today I decided to clone the GCC repo and build the latest code > > just to play around with some new C23 features. One thing I attempted >

Re: _BitInt() as underlying enum type

On Sat, Jan 27, 2024 at 6:07 PM Thomas Voss via Gcc-bugs wrote: > > Hi all, > > Earlier today I decided to clone the GCC repo and build the latest code > just to play around with some new C23 features. One thing I attempted > was the following: > > typedef _BitInt(128) underlying; > enum

Re: int8_t lives matter

On Fri, Dec 22, 2023 at 1:54 PM Olavi Esker via Gcc wrote: > > Hello, > > #include > #include > > int main() > { > std::int8_t myInt{65}; > myInt += 1; > std::cout << myInt; > } > > Guess what this returns? > Character "B". > > int main() > { > std::int8_t myInt{}; > std::cin >> myInt; >

Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15

On Sun, Dec 17, 2023 at 1:20 PM Eric Gallager wrote: > > On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc wrote: > > > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > > not even supported with LTO. Does it make sense to deprecate th

Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15

On Sun, Dec 17, 2023 at 8:26 AM Florian Weimer wrote: > > * Andrew Pinski via Gcc: > > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > > not even supported with LTO. Does it make sense to deprecate the > > support for GCC 14 and remove it in GC

Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15

-fgnu-tm support has not been improved since GCC 5 or earlier. It is not even supported with LTO. Does it make sense to deprecate the support for GCC 14 and remove it in GCC 15? Thanks, Andrew Pinski

Re: Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

On Wed, Dec 13, 2023 at 1:08 PM Andrew Pinski wrote: > > On Wed, Dec 13, 2023 at 6:19 AM Florian Weimer via Gcc > wrote: > > > > I feel like I have asked this before. Currently, GCC uses calls to > > __tls_get_addr to obtain the address of global-dynamic TLS variables. > > On other

Re: Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

On Wed, Dec 13, 2023 at 6:19 AM Florian Weimer via Gcc wrote: > > I feel like I have asked this before. Currently, GCC uses calls to > __tls_get_addr to obtain the address of global-dynamic TLS variables. > On other architectures with support for GNU2 TLS descriptors, those are > used by

Deprecating nds32-*-linux-* target for GCC 14 (and removing it for GCC 15)

nds32 support in Linux was removed last year: https://www.phoronix.com/news/Andes-Tech-NDS32-Removal The support for glibc never made it upstream as far as I can tell either. What are others thoughts on this? Thanks, Andrew Pinski

Re: wwwdocs: cxx-reflection/index.html Standardeze

On Sat, Dec 2, 2023 at 5:40 PM Jonny Grant wrote: > > Hello > > I held of making a patch to change this (to remove it), does Standardeze mean > something: > > https://gcc.gnu.org/projects/cxx-reflection/index.html It means written in the same form as the language that is the C++ standard. It

Re: Strange compile error when g++ work with std=c++20.

On Mon, Nov 27, 2023 at 8:24 PM Lew Robin via Gcc-bugs wrote: > > This error happens when using macro and template. > GCC Version: gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04) > OS: ubuntu 22.04 (x64) > Compile Command: > g++-12 ./testmacro.cc --std=c++20 > > In fact, this error exisits from

Re: [ARM] unexpected sizeof() of a complex packed type

On Thu, Nov 16, 2023 at 8:42 AM Dmitry Antipov wrote: > > (The following sample is taken from my LKML post at > https://lkml.org/lkml/2023/11/15/213) > > $ cat t-build-bug.c > > struct vring_tx_mac { > unsigned int d[3]; > unsigned int ucode_cmd; > } __attribute__((packed)); > >

Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*

On Tue, Nov 7, 2023 at 8:33 PM Maxim Blinov via Gcc wrote: > > I see, thanks for clarifying, that makes sense. > > In that case, what about doing the inverse? I mean, are there unique > patches in the vendor branch, and would it be useful to try to > upstream them into master? My motivation is to

Re: Emacs ChangeLog generation and commit messages

On Mon, Nov 6, 2023 at 8:39 AM Florian Weimer via Gcc wrote: > > Emacs has a very useful facility. You press “C-x 4 a” in a place where > you make changes, and the editor automatically opens the right ChangeLog > file and adds a draft entry to it, like this: > > 2023-11-06 Florian Weimer > >

Re: Advice on how to disable floating point instructions

On Sat, Nov 4, 2023 at 9:41 AM Enrico via Gcc wrote: > > Hello, > > > for a custom architecture I am working on, I would like to entirely disable > the usage of hardware floating point instructions in favor of library > methods on demand. > > I need advice on what is the best strategy to do this.

Re: Question on GIMPLE shifts

On Wed, Nov 1, 2023 at 3:56 AM Daniil Frolov wrote: > > Hi! > > When investigating bit shifts I got an incomprehensible moment with > the following example: > > int f(int x, int k) > { > int tmp = x >> k; > return (tmp & 1) << 10; > } > > If we would like to take a look into GIMPLE then

Re: Need some analyzer testcase help

On Fri, Oct 27, 2023 at 2:12 PM David Malcolm wrote: > > On Fri, 2023-10-27 at 12:48 -0700, Andrew Pinski wrote: > > Hi David and others, > > I am in the process of improving phi-opt and moving what was > > handled > > in value_replacement to match-and-simplify and ran into a few > > failures >

Need some analyzer testcase help

Hi David and others, I am in the process of improving phi-opt and moving what was handled in value_replacement to match-and-simplify and ran into a few failures in the analyzer testsuite. For an example c-c++-common/analyzer/inlining-3-multiline.c (and c-c++-common/analyzer/inlining-3.c) now

Re: Install page misses Bison prerequisite

On Thu, Oct 26, 2023 at 11:01 AM Simon Sobisch via Gcc wrote: > > https://gcc.gnu.org/install/prerequisites.html has a bunch of tools > under "Tools/packages necessary for modifying GCC", but GNU Bison is > missing. > > I found it interesting to see that some files like under intl say > 1 /*

Re: Install page misses Bison prerequisite

Looks like it was removed on accident here: https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/doc/install.texi;h=3bf2305c8d14181bfb61d112ab3e1c0c2f605322;hp=5735f054317e08b2c5b629adfe72a308459b8bd9;hb=e8645a4001a8d117dd336ea75942aac49101af49;hpb=3825be8c96775cf8e6fcb5eef04455f07717a5ea But it

Re: Question about gimple code during optimizing if-conversion

On Fri, Oct 13, 2023 at 10:16 PM Hanke Zhang via Gcc wrote: > > Hi, I'm working on optimizing if-conversion for my own business > recently. I got a problem here. > > I tried to optimize it in such a case, for example, when a conditional > statement block has only if statement and no else

Re: Test with an lto-build of libgfortran.

On Wed, Sep 27, 2023 at 11:28 PM Richard Biener via Fortran wrote: > > On Wed, Sep 27, 2023 at 11:48 PM Jeff Law via Fortran > wrote: > > > > > > > > On 9/27/23 12:21, Toon Moene wrote: > > > > > > > > The lto-ing of libgfortran did succeed, because I did get a new warning: > > > > > > gfortran

Re: ipa-inline & what TARGET_CAN_INLINE_P can assume

On Mon, Sep 25, 2023 at 10:16 AM Richard Sandiford via Gcc wrote: > > Hi, > > I have a couple of questions about what TARGET_CAN_INLINE_P is > alllowed to assume when called from ipa-inline. (Callers from the > front-end don't matter for the moment.) > > I'm working on an extension where a

Re: [PATCH] MATCH: Add simplifications for `(a * zero_one) ==/!= CST`

On Mon, Sep 18, 2023 at 12:09 AM Richard Biener via Gcc-patches wrote: > > On Sat, Sep 16, 2023 at 7:50 AM Andrew Pinski via Gcc-patches > wrote: > > > > Transforming `(a * b@[0,1]) != 0` into `((cast)b) & a != 0` > > that isn't strictly a simplification (one

Re: Question on -fwrapv and -fwrapv-pointer

On Mon, Sep 18, 2023 at 12:33 AM Richard Biener via Gcc wrote: > > On Sat, Sep 16, 2023 at 10:38 AM Martin Uecker via Gcc > wrote: > > > > > > > > (moved to gcc@) > > > > > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote: > > > > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: >

[PATCH] Remove xfail from gcc.dg/tree-ssa/20040204-1.c

So the xfail was there because at one point the difference from having logical-op-non-short-circuit set to 1 or 0 made a difference in being able to optimizing a conditional way. This has not been true for over 10 years in this case so instead of keeping on adding to the xfail list, removing it is

[PATCH] MATCH: Make zero_one_valued_p non-recusive fully

So it turns out VN can't handle any kind of recusion for match. In this case we have `b = a & -1` and we try to match a as being zero_one_valued_p and VN returns b as being the value and we just go into an infinite loop at this point. OK? Bootstrapped and tested on x86_64-linux-gnu with no

[PATCH] MATCH: Avoid recusive zero_one_valued_p for conversions

So when VN finds a name which has a nop conversion, it says both names are equivalent to each other and the valuaization function for one will return the other. This normally does not cause any issues as there is no recusive matches. But after r14-4038-gb975c0dc3be285, there was one added. So we

[PATCH] MATCH: Add simplifications of `(a == CST) & a`

`(a == CST) & a` can be either simplified to simplying `a == CST` or 0 depending on the first bit of the CST. This is an extension of the already pattern of `X & !X` and allows us to remove the 2 xfails on gcc.dg/binop-notand1a.c and gcc.dg/binop-notand4a.c. OK? Bootstrapped and tested on

[PATCH] MATCH: Add simplifications for `(a * zero_one) ==/!= CST`

Transforming `(a * b@[0,1]) != 0` into `((cast)b) & a != 0` will produce better code as a lot of the time b is defined by a comparison. Also since canonicalize `a & -zero_one` into `a * zero_one` we start to lose information when doing comparisons against 0. In the case of PR 110992, we lose that

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: > > > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > CLANG already provided -fsanitize=unsigned-integer-overflow. GCC > might need to do the same. > >>> > >>> NO. There is

Re: [PATCH] MATCH: Improve zero_one_valued_p for cases without range information

On Thu, Sep 14, 2023 at 11:28 PM Richard Biener via Gcc-patches wrote: > > On Fri, Sep 15, 2023 at 3:09 AM Andrew Pinski via Gcc-patches > wrote: > > > > I noticed we sometimes lose range information in forwprop due to a few > > match and simplify patterns optimizin

[PATCH] MATCH: Improve zero_one_valued_p for cases without range information

I noticed we sometimes lose range information in forwprop due to a few match and simplify patterns optimizing away casts. So the easier way to these cases is to add a match for zero_one_valued_p wich mathes a cast from another zero_one_valued_p. This also adds the case of `x & zero_one_valued_p`

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, Sep 14, 2023 at 1:50 PM Qing Zhao via Gcc-patches wrote: > > > > > On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote: > > > > On Thu, 2023-09-14 at 15:57 +, Qing Zhao via Gcc-patches wrote: > >> Currently, GCC behaves as following: > >> > >> /* True if overflow wraps around for the given

[PATCH] MATCH: Fix `(1 >> X) != 0` pattern for vector types

I had missed that integer_onep can match vector types with uniform constant of `1`. This means the shifter could be an scalar type and then doing a comparison against `0` would be an invalid transformation. This fixes the problem by adding a check for the type of the integer_onep to make sure

[PATCH] MATCH: Support `(a != (CST+1)) & (a > CST)` optimizations

Even though this is done via reassocation, match can support these with a simple change to detect that the difference is just one. This allows to optimize these earlier and even during phiopt for an example. This patch adds the following cases: (a != (CST+1)) & (a > CST) -> a > (CST+1) (a !=

Re: Compilation Error Regarding RID_MAX

On Wed, Sep 13, 2023 at 9:35 PM Ken Matsui wrote: > > On Wed, Sep 13, 2023 at 9:23 PM Andrew Pinski wrote: > > > > On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc wrote: > > > > > > Hi, > > > > > > I have merged all my patches into a single branch for better > > > maintainability for me, but

Re: Compilation Error Regarding RID_MAX

On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc wrote: > > Hi, > > I have merged all my patches into a single branch for better > maintainability for me, but I am unable to build GCC. Initially, I > faced an error related to RID_MAX, which was fixed in >

[PATCH] Improve error message for if with an else part while in switch

While writing some match.pd code, I was trying to figure out why I was getting an `expected ), got (` error message while writing an if statement with an else clause. For switch statements, the if statements cannot have an else clause so it would be better to have a decent error message saying

Re: [PATCH 1/2] MATCH: [PR111364] Add some more minmax cmp operand simplifications

On Tue, Sep 12, 2023 at 11:45 PM Richard Biener via Gcc-patches wrote: > > On Tue, Sep 12, 2023 at 5:31 PM Andrew Pinski via Gcc-patches > wrote: > > > > This adds a few more minmax cmp operand simplifications which were missed > > before. > > `MIN(

[PATCH] MATCH: Simplify `(X % Y) < Y` pattern.

This merges the two patterns to catch `(X % Y) < Y` and `Y > (X % Y)` into one by using :c on the comparison operator. It does not change any code generation nor anything else. It is more to allow for better maintainability of this pattern. OK? Bootstrapped and tested on x86_64-linux-gnu.

[PATCH 2/2] MATCH: Move `X <= MAX(X, Y)` before `MIN (X, C1) < C2` pattern

Since matching C1 as C2 here will decrease how much other simplifications will need to happen to get the final answer. OK? Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: * match.pd (`X <= MAX(X, Y)`): Move before `MIN (X, C1) < C2` pattern. --- gcc/match.pd | 15

[PATCH 1/2] MATCH: [PR111364] Add some more minmax cmp operand simplifications

This adds a few more minmax cmp operand simplifications which were missed before. `MIN(a,b) < a` -> `a > b` `MIN(a,b) >= a` -> `a <= b` `MAX(a,b) > a` -> `a < b` `MAX(a,b) <= a` -> `a >= b` OK? Bootstrapped and tested on x86_64-linux-gnu. Note gcc.dg/pr96708-negative.c needed to updated to

[PATCH] MATCH: Simplify (a CMP1 b) ^ (a CMP2 b)

This adds the missing optimizations here. Note we don't need to match where CMP1 and CMP2 are complements of each other as that is already handled elsewhere. I added a new executable testcase to make sure we optimize it correctly as I had originally messed up one of the entries for the resulting

[PATCH] MATCH: [PR111348] add missing :c to cmp in the `(a CMP b) ? minmax : minmax` pattern

When I added this pattern in r14-337-gc43819a9b4cd, I had missed the :c on the cmp part of the pattern meaning there might be some missing optimizations happening. The testcase shows an example of the missed optmization. Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

[PATCH] MATCH: [PR111349] add missing :c to cmp in the `(a CMP CST1) ? max : a` pattern

When I added this pattern in r14-1411-g17cca3c43e2f49, I had missed the :c on the cmp part of the pattern meaning there might be some missing optimizations happening. The testcase shows an example of the missed optmization. Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

[PATCH] MATCH: [PR111346] `X CMP MINMAX` pattern missing :c on CMP

I noticed this while working on other MINMAX optimizations. It was hard to find a simplified testcase though because it was dependent on the ssa name versions. Adding the `:c` to cmp allows the pattern to be match for the case where minmax as the first operand of the comparison rather than the

[PATCH] Fix PR 111331: wrong code for `a > 28 ? MIN : 29`

The problem here is after r6-7425-ga9fee7cdc3c62d0e51730, the comparison to see if the transformation could be done was using the wrong value. Instead of see if the inner was LE (for MIN and GE for MAX) the outer value, it was comparing the inner to the value used in the comparison which was

Re: [PATCH] Support folding min(poly,poly) to const

On Thu, Sep 7, 2023 at 10:25 PM Lehua Ding wrote: > > Hi, > > This patch adds support that tries to fold `MIN (poly, poly)` to > a constant. Consider the following C Code: Does it make sense to handle max also? Thanks, Andrew > > ``` > void foo2 (int* restrict a, int* restrict b, int n) > { >

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

On Tue, Sep 5, 2023 at 2:51 PM Jakub Jelinek wrote: > > On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote: > > > I admit it isn't really clear to me what do you want to achieve by the > > > above build_nonstandard_integer_type. Is it because of BOOLEAN_TYPE > > > or perhaps

Re: [PATCH 18/12] Handle BITINT_TYPE in build_{, minus_}one_cst [PR102989]

On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > Recent match.pd changes trigger ICE in build_minus_one_cst, apparently > I forgot to handle BITINT_TYPE in these (while I've handled it in > build_zero_cst). > > Will commit as obvious together with the rest of the

  1   2   3   4   5   6   7   8   >