GSoC Interest in enhancing OpenACC support

[Pau Sum via Gcc]

Hey GCC Community,
I am interested in contributing to the "Enhance OpenACC Support" project for 
Google Summer of Code 2025. In particular, I am excited about implementing 
acc_memcpy_device and the #pragma acc cache directive.

To prepare, I have started reviewing the OpenACC 2.6 specification and have 
explored how acc_memcpy_to_device is implemented in GCC. Specifically, I have 
examined libgomp/oacc-mem.c and libgomp/oacc-mem.h to understand memory 
operations, as well as c-family/c-pragma.c, omp-expand.cc, and omp-low.cc to 
see how OpenACC directives are parsed and processed. I have some experience 
with OpenMP and a compilers course and those are proving to be helpful while I 
research the requirements of the project.

I would appreciate any guidance on understanding the init, shutdown, and set 
directives, as I have not yet explored them in depth. Additionally, I would 
like to get a better sense of the scope and challenges of this project. From my 
research, it seems that implementing the cache directive could be particularly 
complex. Are there other key technical considerations or design constraints I 
should focus on? Also, how much technical detail should I provide in my GSoC 
proposal? Should I already have an idea of how I should be implementing these 
issues?

Thanks for any guidance!
Pau

[GSOC 2025] Interests in extending the static analysis pass(es): support for C++ or CPython API

[zzmic via Gcc]

Dear all,


I hope you’ve been doing well!

I’m Zhiwen, an undergraduate who is working towards his degree jointly in
mathematics and computer science.


I’m writing to express my interest in working on a medium-sized (or
large-sized) project that, broadly speaking, extends the static-analysis
pass(es). In particular, I’ve been dabbling between extending the
analyzer’s support for C++ and extending the plugin to add checking for
usage of the CPython API, such as reference counting. Both topics can be
found in the [ideas list](https://gcc.gnu.org/wiki/SummerOfCode).
Nevertheless, I haven’t yet settled down a fine-grained problem (in the
scope of the aforementioned topics) to work on. For extending the
analyzer’s support for C++, I was wondering if I should (or am expected to)
curate a very specific proposition that may be generated from [the existing
bugs](https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110) or
something else (e.g., loosely coupling a batch of bugs that have a similar
gist).


To briefly introduce my background, I have gained previous experience in
compilers, mainly through engineering compilers and interpreters in C++ and
OCaml. One of the compiler projects I’ve been working on is [ccmic](
https://github.com/zzmic/ccmic), a work-in-progress implementation of a C
compiler (that supports a subset of the C programming language) written in
C++. On top of that, I had and have been working on (1) an interpreter for
a (quite simple/naive) object-oriented language that adheres to its syntax
and small-step operational semantics and (2) compilers that can be thought
of as transpilers that, for instance, compile scheme-like programs to
C-like programs and compile C-like programs to RISC-V assembly.
Furthermore, I’ve some experience in contributing to open-source projects,
such as [p4c](https://github.com/p4lang/p4c), although the [PRs I made](
https://github.com/p4lang/p4c/issues?q=state%3Aclosed%20is%3Apr%20author%3A%40me)
are not game-changing and are definitely not to the extent of a GSoC
project.


Thanks for your patience in reading this perhaps long-winded message, and
please feel absolutely free to make any comments or suggestions.


Best regards,
Zhiwen

Undeliverable: Front certainly player travel can third. SMTP-1

[postmaster--- via Gcc]

Delivery has failed to these recipients or groups:

lindaphipps...@aol.com
The email system had a problem processing this message. It won't try to deliver 
this message again.








Diagnostic information for administrators:

Generating server: exchange2019.ionos.com

lindaphipps...@aol.com
Remote Server returned '550 5.6.0 CAT.InvalidContent.Exception: 
InvalidCharsetException, Character set name (pt154) is invalid or not 
installed.; cannot handle content of message with InternalId 44959717659851, 
InternetMessageId <93e87ab58330193e87ab58330193e87ab583...@adams.net>.'

Original message headers:

Received: from [94.154.173.35] (10.72.152.123) by winhex19beus4.winusa.mail
 (10.72.152.142) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1748.10; Thu, 20 Mar
 2025 02:47:08 -0400
Content-Type: multipart/mixed;
boundary="===4188926895973399641=="
MIME-Version: 1.0
To: 
Precedence: bulk
Subject: 
=?pt154?B?RnJvbnQgY2VydGFpbmx5IHBsYXllciB0cmF2ZWwgY2FuIHRoaXJkLiBTTVRQLTE=?=
From: =?pt154?B?Q29tYnMsIFBvd2VsbCBhbmQgSGF5ZXM=?= 
X-Mailer: Becky!InternetMail/2.74
X-Originating-Client: Alpine/2.23(Macintosh; Intel Mac OS X 10_8_0)
X-MSMail-Priority: 2
Message-ID: <93e87ab58330193e87ab58330193e87ab583...@adams.net>
X-Powered-By: Koa
X-Sieve: fileinto 'INBOX.important';
X-Mailer-LID: 1045531-239087046
Return-Path: gcc@gcc.gnu.org
Date: Thu, 20 Mar 2025 02:47:08 -0400
X-ClientProxiedBy: winhex19beus1.winusa.mail (10.72.152.11) To
 winhex19beus4.winusa.mail (10.72.152.142)

Reporting-MTA: dns;exchange2019.ionos.com
Received-From-MTA: dns;[94.154.173.35]
Arrival-Date: Thu, 20 Mar 2025 06:47:08 +

Final-Recipient: rfc822;lindaphipps301@aol.com
Action: failed
Status: 5.6.0
Diagnostic-Code: smtp;550 5.6.0 CAT.InvalidContent.Exception: InvalidCharsetException, Character set name (pt154) is invalid or not installed.; cannot handle content of message with InternalId 44959717659851, InternetMessageId <93e87ab58330193e87ab58330193e87ab583301@adams.net>.

Re: [GSOC 2025] Interests in extending the static analysis pass(es): support for C++ or CPython API

[zzmic via Gcc]

On Wed, Mar 19, 2025 at 10:46 PM zzmic  wrote:
>
> Dear all,
>
>
> I hope you’ve been doing well!
>
> I’m Zhiwen, an undergraduate who is working towards his degree jointly in 
> mathematics and computer science.
>
>
> I’m writing to express my interest in working on a medium-sized (or 
> large-sized) project that, broadly speaking, extends the static-analysis 
> pass(es). In particular, I’ve been dabbling between extending the analyzer’s 
> support for C++ and extending the plugin to add checking for usage of the 
> CPython API, such as reference counting. Both topics can be found in the 
> [ideas list](https://gcc.gnu.org/wiki/SummerOfCode). Nevertheless, I haven’t 
> yet settled down a fine-grained problem (in the scope of the aforementioned 
> topics) to work on. For extending the analyzer’s support for C++, I was 
> wondering if I should (or am expected to) curate a very specific proposition 
> that may be generated from [the existing 
> bugs](https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110) or 
> something else (e.g., loosely coupling a batch of bugs that have a similar 
> gist).
>
>
> To briefly introduce my background, I have gained previous experience in 
> compilers, mainly through engineering compilers and interpreters in C++ and 
> OCaml. One of the compiler projects I’ve been working on is 
> [ccmic](https://github.com/zzmic/ccmic), a work-in-progress implementation of 
> a C compiler (that supports a subset of the C programming language) written 
> in C++. On top of that, I had and have been working on (1) an interpreter for 
> a (quite simple/naive) object-oriented language that adheres to its syntax 
> and small-step operational semantics and (2) compilers that can be thought of 
> as transpilers that, for instance, compile scheme-like programs to C-like 
> programs and compile C-like programs to RISC-V assembly. Furthermore, I’ve 
> some experience in contributing to open-source projects, such as 
> [p4c](https://github.com/p4lang/p4c), although the [PRs I 
> made](https://github.com/p4lang/p4c/issues?q=state%3Aclosed%20is%3Apr%20author%3A%40me)
>  are not game-changing and are definitely not to the extent of a GSoC project.

I'm sorry that the link that I attached with "PRs I made" doesn’t (and
won’t) work as intended. Just in case any of the message reviewers are
interested, the following link should point to the right place:
https://github.com/p4lang/p4c/pulls?q=state%3Aclosed+is%3Apr+author%3Azzmic.

> Thanks for your patience in reading this perhaps long-winded message, and 
> please feel absolutely free to make any comments or suggestions.
>
>
> Best regards,
> Zhiwen

Re: Using nonzero_bits() in insn conditions?

[Georg-Johann Lay via Gcc]

Am 16.03.25 um 14:51 schrieb Jeff Law via Gcc:

On 3/13/25 5:39 AM, Georg-Johann Lay via Gcc wrote:

There are situations where knowledge about which bits
of a value are (not) set can be used for optimization.
For example in an insn combine pattern like:

(define_insn_and_split ""
   [(set (match_operand:QI 0 "register_operand"   
"=d")
 (ior:QI (ashift:QI (match_operand:QI 1 "register_operand" 
"r")
    (match_operand:QI 2 "const_0_to_7_operand" 
"n"))

 (match_operand:QI 3 "register_operand" "0")))]
   "optimize
    && !reload_completed
    && nonzero_bits (operands[1], VOIDmode) == 1"
...

This pattern is only correct when operands[1] is 0 or 1.

While such patterns seem to work, it's all quite wonky,
in particular since nonzero_bits() may forget about known
properties in later passes.
While it works most of the time, it's fundamentally wrong to have a 
pattern where the conditional is dependent on state that changes based 
on pass specific data, nearby context, etc.




For the use case I have in mind, it is in order when the
pattern works until split1 which would transform it into
something else (and without nonzero_bits() in the insn
condition, asserting that the existence of the pattern
certifies the bit condition).
It's still the wrong thing to do.  You'll get away with it for a while, 
but one day it'll break.


We have similar problems in the RISC-V world where we would like to be 
able to match certain patterns based on known ranges of an operand.  The 
most common case would be bset/bclr/binv on an SImode object on rv64 
where the bit twiddled is variable.  In particular we need to know the 
bit position is not bit 31.


There's no way to really describe that in an insn's condition because 
range information like that isn't available in RTL and something like 
nonzero bits is pass specific.


As a result we're limited in our ability to use the bset/bclr/binv 
instructions.


Jeff


One way to support this is a new target hook that would run somewhere
in recog_for_combine().  The hook would allow the backend to replace
the pattern as synthesized by combine with an equivalent pattern.

The backend could use nonzero_bits and ranges information which have
to be available.  As is seems, nonzero_bits is available.  For ranges
information I don't know.  The backend would have to make sure that
no other routes can lead to the pattern (provided extra range or
bits info is used.  When the hook us used for, say canonicalization,
other ways to the patterns are in order).

The default implementation of the hook just returns the unchanged
pattern.

Johann

Remove duplication for the handling of attributes between different frontends in GCC

[Basile Starynkevitch]

Hello
Antoni Boucher wrote:




> We're trying to remove the duplication of the attributes code between
> the C and libgccjit frontend.
> The attached patch shows a draft of this attempt that only supports a
> few attributes.
> Would that kind of approach be acceptable (I'm not sure since this
> includes a c-family file in libgccjit)?

Certainly yes, once it is properly documented


-- 
Basile STARYNKEVITCH   
8 rue de la Faïencerie
92340 Bourg-la-Reine,  France
http://starynkevitch.net/Basile & https://github.com/bstarynk 
& https://github.com/RefPerSys/RefPerSys/