Re: What replaces FOR_EACH_LOOP_FN

On Wed, Mar 02, 2022 at 10:04:40PM +, Gary Oblock via Gcc wrote: > Guys, > > I've been working on an optimization for quite a bit of time and > in an attempt to move it to GCC 12 I found that FOR_EACH_LOOP_FN > no longer exists. I poked around in the archives and tried a Google > search but fo

Re: What replaces FOR_EACH_LOOP_FN

Andrew, That's super! I was dreading an answer along the lines of "we don't do that anymore so why would you ever want to do that?" 😉 Many thanks, Gary From: Andrew Pinski Sent: Wednesday, March 2, 2022 2:09 PM To: Gary Oblock Cc: gcc@gcc.gnu.org Subject: Re:

Re: What replaces FOR_EACH_LOOP_FN

On Wed, Mar 2, 2022 at 2:05 PM Gary Oblock via Gcc wrote: > > Guys, > > I've been working on an optimization for quite a bit of time and > in an attempt to move it to GCC 12 I found that FOR_EACH_LOOP_FN > no longer exists. I poked around in the archives and tried a Google > search but found nothi

What replaces FOR_EACH_LOOP_FN

Guys, I've been working on an optimization for quite a bit of time and in an attempt to move it to GCC 12 I found that FOR_EACH_LOOP_FN no longer exists. I poked around in the archives and tried a Google search but found nothing on it. It suited my needs and I'd hate to have to rewrite a bunch of

Re: Project guidance regarding the cp-demangler non recursive .

Hello, we are delighted you found contributing to GCC interesting. On Fri, Feb 25 2022, Krishna Narayanan wrote: > Hello, > I am keen on working with the non recursive demangler,I have done a I have just replied to another request about the project, you'll find my email at https://gcc.gnu.org/pi

Re: GSoC (Make cp-demangle non-recursive)

Hello Juan, we are delighted you found contributing to GCC interesting. On Sat, Feb 26 2022, Juan Scerri wrote: > To whom this may concern, > > Firstly, I will introduce myself. I am Juan Scerri and I am a student at > the University of Malta studying Computer Science and Mathematics for my > und

RE: OpenMP auto-simd

> -Original Message- > From: Jakub Jelinek > Sent: 02 March 2022 15:25 > To: Stubbs, Andrew > Cc: gcc@gcc.gnu.org > Subject: Re: OpenMP auto-simd > > On Wed, Mar 02, 2022 at 03:12:30PM +, Stubbs, Andrew wrote: > > Has anyone ever considered having GCC add the "simd" clause to offload

Re: OpenMP auto-simd

On Wed, Mar 02, 2022 at 03:12:30PM +, Stubbs, Andrew wrote: > Has anyone ever considered having GCC add the "simd" clause to offload (or > regular) loop nests automatically? > > For example, something like "-fomp-auto-simd" would transform "distribute > parallel" to "distribute parallel simd

OpenMP auto-simd

Hi Jakub, all, Has anyone ever considered having GCC add the "simd" clause to offload (or regular) loop nests automatically? For example, something like "-fomp-auto-simd" would transform "distribute parallel" to "distribute parallel simd" automatically. Loop nests that already contain "simd" c

Minor C2X-induced ABI issue on powerpc64le

I've been following [RFC] Enabling -Wstrict-prototypes by default in C and I've just realized that treating extern int foo(); as a prototype declaration (with the same ABI as extern "C" int foo(); in

Re: ARM Cortex-R5F Support

On 3/2/2022 05:49, Richard Earnshaw wrote: On 01/03/2022 16:23, Kinsey Moore wrote: Hi, I'm looking at working on Cortex-R5F support for RTEMS, but it seems as if latest GCC supports the Cortex-R5. This R5 has implicit FPU support which would make it really R5F. The ARM reference page on t

Re: ARM Cortex-R5F Support

On 01/03/2022 16:23, Kinsey Moore wrote: Hi, I'm looking at working on Cortex-R5F support for RTEMS, but it seems as if latest GCC supports the Cortex-R5. This R5 has implicit FPU support which would make it really R5F. The ARM reference page on this core (https://developer.arm.com/Process