Re: New feature: -fdump-gimple-nodes (once more, with feeling)

Robert Dubner writes: > There didn't seem to be any such functionality in GCC. I found a routine > in print-tree.cc which printed out a single node, but I needed to > understand the entire tree of nodes for a function. FWIW the standard way to do this is to run the compiler in gdb with the .gdb

New feature: -fdump-gimple-nodes (once more, with feeling)

I have not contributed to GCC before, so I am not totally sure how to go about it. So, I am letting you know what I want to do, so that I can get advice on a good way to do it. I have read https://gcc.gnu.org/contribute.html, and I have reviewed the Gnu Coding Standards and the GCC additional cod

RE: New feature -fdump-gimple-nodes

Oh, crap. This is *not* an auspicious beginning. This message fragment was sent from Outlook, which does not have a good working relationship with the e-mail handler my company uses. Please ignore this while I painfully reconstruct the much longer message that those two programs managed to lose,

New feature -fdump-gimple-nodes

I have not contributed to GCC before, so I am not sure how to go about it. So, I am letting you know what I want to do, so that I can get advice on the best way to do it. I have read https://gcc.gnu.org/contribute.html, and I have Jim Lowden and I have been developing a COBOL front end for GCC.

Re: Nested restrict pointers: missed optimization & client with UB?

> Am 13.02.2024 um 16:27 schrieb Ties Klappe via Gcc : > > Thank you both for your quick replies. > > @Joseph, thank you for linking me to the other issue. If I understand > correctly what the point is, would you then agree that the program main > when calling foo2 has *defined* behavior? > W

Re: Nested restrict pointers: missed optimization & client with UB?

On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote: > Thank you both for your quick replies. > > @Joseph, thank you for linking me to the other issue. If I understand > correctly what the point is, would you then agree that the program main > when calling foo2 has *defined* behavior? I think that's

Re: Nested restrict pointers: missed optimization & client with UB?

Thank you both for your quick replies. @Joseph, thank you for linking me to the other issue. If I understand correctly what the point is, would you then agree that the program main when calling foo2 has *defined* behavior? What surprises me is that *p and *q might be the same restricted pointer: t

Re: Nested restrict pointers: missed optimization & client with UB?

On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote: > int foo2(int *restrict *p, int *restrict *q) > { > **p = 10; > **q = 11; > return **p; > } In this case, *p and *q might be the same restricted pointer object. See the more detailed explanation at

Re: Nested restrict pointers: missed optimization & client with UB?

On Tue, Feb 13, 2024 at 2:02 PM Ties Klappe via Gcc wrote: > > Hi, > > I have two questions related to nested restrict pointers. > GCC 13.02 with optimization level 3 optimizes the function *foo1* to simply > return 10. > > int foo1(int *restrict *restrict p, int *restrict *restrict q) > { > *

Nested restrict pointers: missed optimization & client with UB?

Hi, I have two questions related to nested restrict pointers. GCC 13.02 with optimization level 3 optimizes the function *foo1* to simply return 10. int foo1(int *restrict *restrict p, int *restrict *restrict q) { **p = 10; **q = 11; return **p; } I am curious why the function *foo2*

Re: Optimization of bit field assignemnts

On Mon, Feb 12, 2024 at 5:49 PM Hugh Gleaves via Gcc wrote: > > I’m interested in whether it would be feasible to add an optimization that > compacted assignments to multiple bit fields. > > Today, if I have a 32 bit long struct composed of say, four 8 bit fields and > assign constants to them l