Re: RFC: A redesign of `-Mmodules` output

[Ben Boeckel via Gcc]

On Fri, Feb 28, 2025 at 13:54:45 -0500, Paul Smith wrote:
> On Fri, 2025-02-28 at 19:26 +0100, Ben Boeckel via Gcc wrote:
> > > In POSIX make, including GNU Make, if a command doesn't modify the
> > > modification time of the target then that target is not considered
> > > updated, and other targets which list it as a prerequisite are not
> > > invoked:
> > 
> > Hmm. My understanding was that if a recipe is run, its outputs are
> > assumed to have been updated. I forget where I saw that, but it
> > sticks in my mind for some reason. Experimenting with GNU Make indeed
> > does exhibit `restat = 1` behavior out-of-the-box. That's good to
> > know :). I'll update my priors.
> 
> There is one issue related to this: I don't know if Ninja addresses
> this or not: maybe this is what people were thinking of?
> 
> Because the modification time of the target is not updated, the recipe
> for the the target will always be run (but targets that depend on it
> will not be run).

Ah! Yes, that is a difference. Ninja records the "last run" mtime as a
"shadow mtime" for the rule in its `.ninja_log` file. This is the mtime
used when deciding to rerun the rule or not. Another difference is that
this also encodes the command line last used for the output(s), so if
*that* changes, it is also considered out-of-date. CMake has command
line change detection, but it is much coarser: there's a file with
information about all command lines in a given target and if that file
changes, all commands in the target rerun.

> This is the best that make can do, because it relies solely on the
> filesystem as its database of "build state" and doesn't preserve any
> build state of its own.  Since "two"'s timestamp was not modified make
> has no way to know that its recipe was actually run previously.
> 
> If the recipe to build "two" is expensive, it's probably better to just
> bite the bullet and allow "two" to be updated whenever its
> prerequisites change.

Yes, this is reminding me of details I had eventually compressed to
"restat behavior isn't supported in make": it *works*, but is not
*useful* because it never results in a "do nothing" build.

> The only way for make to do better would be for it to keep its own
> database of up-to-date notations, alongside or in addition to the
> filesystem's modification time.  That would be a major structural
> change, of course.

If it does happen, it would be *wonderful* to reuse `ninja`'s
`.ninja_log` format. That would allow the usage of tools like
`ninjatracing`[1] to get performance graphs of arbitrary `make` builds.

Note that there is one fairly annoying thing with this in `ninja`: when
using `sudo ninja`, the log file is written using the elevated
permissions which makes further non-`sudo` usages…fail. See this issue:

https://github.com/ninja-build/ninja/issues/1302

--Ben

[1] https://github.com/nico/ninjatracing

Re: RFC: A redesign of `-Mmodules` output

[Paul Smith via Gcc]

On Fri, 2025-02-28 at 19:26 +0100, Ben Boeckel via Gcc wrote:
> > In POSIX make, including GNU Make, if a command doesn't modify the
> > modification time of the target then that target is not considered
> > updated, and other targets which list it as a prerequisite are not
> > invoked:
> 
> Hmm. My understanding was that if a recipe is run, its outputs are
> assumed to have been updated. I forget where I saw that, but it
> sticks in my mind for some reason. Experimenting with GNU Make indeed
> does exhibit `restat = 1` behavior out-of-the-box. That's good to
> know :). I'll update my priors.

There is one issue related to this: I don't know if Ninja addresses
this or not: maybe this is what people were thinking of?

Because the modification time of the target is not updated, the recipe
for the the target will always be run (but targets that depend on it
will not be run).

E.g., in my previous example I had:

  ~$ touch three; make MKTWO=echo
  echo two
  two

Now if I run it again after touching "three", the command for "two" is
again run as you'd expect, and "one" is not since "two"'s timestamp is
not changed:

  ~$ touch three; make MKTWO=echo
  echo two
  two

BUT!  Now if I do NOT update "three", "two" is STILL updated, and will
continue to be as long as the "two" target's timestamp is not changed:

  ~$ make MKTWO=echo
  echo two
  two

  ~$ make MKTWO=echo
  echo two
  two

If the recipe to create "two" is complex/long-running then this is not
great.

Only when we allow "two" to actually be modified (in my example, by not
overriding the MKTWO variable), will we get back to "normal" behavior:

  ~$ make
  touch two
  touch one

  ~$ make
  make: 'one' is up to date.

This is the best that make can do, because it relies solely on the
filesystem as its database of "build state" and doesn't preserve any
build state of its own.  Since "two"'s timestamp was not modified make
has no way to know that its recipe was actually run previously.

If the recipe to build "two" is expensive, it's probably better to just
bite the bullet and allow "two" to be updated whenever its
prerequisites change.

The only way for make to do better would be for it to keep its own
database of up-to-date notations, alongside or in addition to the
filesystem's modification time.  That would be a major structural
change, of course.

Re: memory model, READ_ONCE

[Richard Biener via Gcc]

> Am 28.02.2025 um 20:02 schrieb Martin Uecker :
> 
> Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov:
>>> On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
>>> 
>>> 
>>> I have one follow-up question:  What is the reason
>>> that we have stronger semantics for stores by default (i.e.
>>> when not using -fallow-store-data-races) than for reads
>>> given that the standard would allow more freedom.
>> 
>> Why would it? On the contrary, it makes an explicit note that
>> introducing new writes that could create a racing store is
>> not allowed, see note 13 in C11 5.1.2.4.
> 
> My original question was about inventing stores that currently
> seem to be allowed.  Turning
> 
> if (x != 1)
>  x = 1;
> 
> into
> 
> x = 1;
> 
> should be ok even though it invents a store for x == 1.
> 
> While this technically introduces a race with another
> reader, it does so only in a seeminglessly harmless way
> when overwriting 1 with 1.
> 
> Are you saying -fallow-store-data-races also introduces
> other kinds of races not allowed by C11?

The default is -fno-allow-store-data-races

> Martin
> 
>> 
>>> Only that for reads this is more difficult to have?
>>> Or other specific reasons why data races for stores
>>> are problematic?
>> 
>> Introducing racing loads is generally not harmful, see note 14.
> 
> 
> 
> 
> 

Re: memory model, READ_ONCE

[Martin Uecker via Gcc]

I have one follow-up question:  What is the reason
that we have stronger semantics for stores by default (i.e.
when not using -fallow-store-data-races) than for reads
given that the standard would allow more freedom.

Only that for reads this is more difficult to have?
Or other specific reasons why data races for stores
are problematic?

Martin


Am Freitag, dem 28.02.2025 um 19:13 +0100 schrieb Martin Uecker:
> Am Freitag, dem 28.02.2025 um 08:18 +0100 schrieb Richard Biener via Gcc:
> > On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker  wrote:
> > > 
> > > 
> > > Hi all,
> > > 
> > > one area where the Linux kernel people are unhappy with C's
> > > memory model is where they now have to use the READ_ONCE,
> > > WRITE_ONCE macros.  These are cases where they do not want
> > > a compiler to duplicate a load, e.g. to reload a value
> > > later because registers were not available to cache it.
> > 
> > The RA could do this as part of re-materialization to
> > avoid a spill-reload and I think this would be sensible.
> > 
> > > Or similar, where a compiler produces two writes to
> > > the same object where the source has only one or
> > > invents a write where none existed, e.g. by turning
> > > a conditional write after a read in an unconditional
> > > one.
> > 
> > That should be covered by -fno-allow-store-data-races
> > There might be the assumption that automatic variables
> > that have their address not taken are not subject to
> > store data races, and I have a hard time thinking of a
> > reason to want READ_ONCE or WRITE_ONCE for such.
> > 
> > > General, it seems compilers currently do not do this.
> > 
> > Yes, because it's a de-optimization.  But for example
> > the partial PRE optimization can introduce a read to
> > a program path where it wasn't read to remove a
> > redundancy on another path that looks more performance
> > critical.  Similarly a sinking transform could do the very
> > same to a store (but see above for -fallow-store-data-races).
> > 
> > > One could alreay use volatile and then the C standard
> > > would guarantee that there are exactly as many accesses
> > > as the source code implies, but this is too strong,
> > > because combining multiple reads into one and caching
> > > the value or dead store elimination would still be ok.
> > 
> > volatile is what gives you the guarantee for reads at
> > the moment.
> > 
> > > The question is whether there are cases where GCC (or
> > > C compilers in general) do such things?   Or if not,
> > > where this would be desirable?   In other words:
> > > Would it be a ok to strengthen the requirements
> > > here?
> > 
> > We have volatile, I don't see a good reason to invent
> > something new here, esp. that we have this guarantee
> > for stores anyway and that for reads it's going to be
> > quite difficult to implement that guarantee.
> 
> Thank you! This is very helpful information.
> 
> Martin
> 
> 

Re: RFC: A redesign of `-Mmodules` output

[Ben Boeckel via Gcc]

On Fri, Feb 28, 2025 at 07:59:00 -0800, NightStrike via Gcc wrote:
> Could your approach simultaneously be used to have better dependency
> information for Fortran modules? I feel like there’s at least some overlap
> there.

P1689 is also intended to be suitable for Fortran (CMake uses it for its
Fortran dependency scanning internally). I'd like to integrate it into
gfortran as well, but not had the time to do so.

> Regarding Fortran modules, it is possible to create both the .o and any
> needed .mod files from one compiler execution. You can tell GNU Make that a
> particular rule creates multiple files using a grouped target (
> https://www.gnu.org/software/make/manual/make.html#Multiple-Targets), and
> older make has a work around using pattern rules. With a grouped target and
> knowledge of the modules that a translation unit will create, the make
> rules are straightforward.
> 
> There’s not a whole lot of conceptual difference between that and these gcm
> files, right? If gcc could output a rule that a .o creates one or more .mod
> files for Fortran, or a whole lot of .gcm files for c++, then the same
> machinery could be used for both.

Yes, the basic features are the same. Note that one thing that is
missing is ninja's `restat = 1` feature. This "restats" the output for
the associated rule (probably spelled `.RESTAT: output` in Make) and
skips running dependent rules if the output has not updated the mtime of
the output(s) before the rule (recipe) was executed. This can be used
for modules to not have to recompile sources that import the output
modules it if they didn't change (e.g., a typo was fixed in an
unexported function body).

--Ben

Re: [PATCH v18 0/2] c: Add __countof__ operator

[Alejandro Colomar via Gcc]

Hi Joseph, Jakub,

On Thu, Feb 27, 2025 at 09:51:35PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 27, 2025 at 08:44:25PM +, Joseph Myers via Gcc wrote:
> > On Thu, 27 Feb 2025, Alejandro Colomar via Gcc wrote:
> > 
> > > Can you please confirm if we should add a version of this operator that
> > > need not be diagnosed under pedantic mode?  If so, I'll propose this
> > 
> > I'm doubtful of the need for a second variant, but in any case the 
> > starting point should be a patch that implements the standard name and 
> > semantics (and then if an extension is needed, it might go on top of that, 
> > whether in the same patch or a separate patch).
> 
> Yeah.  In order to avoid the pedantic warning, one can always use
> (__extension__ _Countof (x))

Hmmm, okay, then I'll prepare _Countof.  Thanks!


Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: Introduction & Interest in GCC Rust Frontend GSoC Project

[Sam James via Gcc]

Basile Starynkevitch  writes:

> Hello Bright Andoh,
>
>> 
>> My name is Bright Andoh, and I’m a Computer Engineering student at the
>> University of Alabama. I’m wrapping up my freshman year and have
>> experience working with Rust and C. Last fall, I collaborated on some
>> Rust projects with a friend, and I’m eager to deepen my understanding,
>> especially in compiler development and large codebases.
>> 
>
> Long time ago, I did contribute to GCC (its plugin infrastructure).
> https://arxiv.org/pdf/1109.0779 (perhaps this paper could be relevant to you)
>
> A possible approach to your goal might be:
>
> become familiar with GCC code base so be able to compile it (on a Linux
> computer) from source code. Be prepared to spend a few days on that.
>
> be able to run the GDB debugger on the GCC compiler (actually its cc1). Be
> prepared to spend a few days on that.
>
> study the source code of the existing Rust compiler 
> https://www.rust-lang.org/,
> only the front-end (e.g. macros & ownership things).
>
> Adapt it to GCC using libgccjit. This means understanding the current rust
> compiler internals and using libgccjit to feed GCC.
>
> https://gcc.gnu.org/onlinedocs/jit/
>
> so my suggestion could be to prototype your Rust frontend as a GCC plugin (and
> reuse as much as possible existing frontend from  https://www.rust-lang.org/)
>

I'm sorry, but this advice is mistaken/misplaced.

GCC *has* a rust frontend in-tree and it's one of our listed GSoC ideas
to help contribute to it at 
https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas.

Not only that, there is additionally a libgccjit backend for the
rust-lang.org implementation of rustc, see
https://github.com/rust-lang/rustc_codegen_gcc.

But this contributor is asking about the former.

> Be sure to put your experimental code on some publicly available website 
> (github
> or something else) for other to review it.
>
> BTW my current open source project is an inference engine, on
> https://github.com/RefPerSys/RefPerSys/
>
>
> Thanks

Re: Introduction & Interest in GCC Rust Frontend GSoC Project

[Basile Starynkevitch]

On Fri, 2025-02-28 at 12:54 +0100, Basile Starynkevitch wrote:
> Hello Bright Andoh,
> 
> > 
> > My name is Bright Andoh, and I’m a Computer Engineering student at the
> > University of Alabama. I’m wrapping up my freshman year and have
> > experience working with Rust and C. Last fall, I collaborated on some
> > Rust projects with a friend, and I’m eager to deepen my understanding,
> > especially in compiler development and large codebases.
> > 
> 
> Long time ago, I did contribute to GCC (its plugin infrastructure).
> https://arxiv.org/pdf/1109.0779 (perhaps this paper could be relevant to you)
> 
> A possible approach to your goal might be:
> 
> become familiar with GCC code base so be able to compile it (on a Linux
> computer) from source code. Be prepared to spend a few days on that.
> 
> be able to run the GDB debugger on the GCC compiler (actually its cc1). Be
> prepared to spend a few days on that.
> 
> study the source code of the existing Rust compiler
> https://www.rust-lang.org/,
> only the front-end (e.g. macros & ownership things).
> 
> Adapt it to GCC using libgccjit. This means understanding the current rust
> compiler internals and using libgccjit to feed GCC.
> 
> https://gcc.gnu.org/onlinedocs/jit/
> 
> so my suggestion could be to prototype your Rust frontend as a GCC plugin (and
> reuse as much as possible existing frontend from  https://www.rust-lang.org/)
> 
> Be sure to put your experimental code on some publicly available website
> (github
> or something else) for other to review it.
> 



BTW (assuming your computer is running Linux) a nice feature to have in your
Rust front-end is it to be multi-threaded.




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

Re: memory model, READ_ONCE

[Alexander Monakov]

On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:

> 
> I have one follow-up question:  What is the reason
> that we have stronger semantics for stores by default (i.e.
> when not using -fallow-store-data-races) than for reads
> given that the standard would allow more freedom.

Why would it? On the contrary, it makes an explicit note that
introducing new writes that could create a racing store is
not allowed, see note 13 in C11 5.1.2.4.

> Only that for reads this is more difficult to have?
> Or other specific reasons why data races for stores
> are problematic?

Introducing racing loads is generally not harmful, see note 14.

Alexander

Re: RFC: A redesign of `-Mmodules` output

[NightStrike via Gcc]

On Thu, Feb 27, 2025 at 21:39 vspefs via Gcc  wrote:

> Current `-Mmodules` output is based on [P1602R0](wg21.link/p1602r0), which
> speaks about a set of Makefile rules that can handle modules, with the
> help of
> module mappers and a modified GNU Make.
>
> The proposal came out in 2019, and the output of those rules was
> implemented
> at GCC in 2020. However, so far we still don't have a new release of GNU
> Make
> which implements P1602R0.
>
> What's more, the rules described in P1602R0 are not ideal. It sets up phony
> prerequisites for real-file targets, causing guaranteed rebuilds. It is
> also
> unable to handle dependencies among module interfaces - that is to say, if
> module A imports and exports B, then the interface of module A depends on
> that
> of module B, so its CMI should be rebuilt if the interface of B changes.
>
> I tried a few approaches to fix the current implementation, but in vain.
>
> It is possible, however, to have another set of Makefile rules generated,
> which
> solves all the problems, and doesn't need a new GNU Make. I've posted it in
> reddit.
>
> See [here](
> https://www.reddit.com/r/cpp/comments/1izg2cc/make_me_a_module_now/).
>
> To briefly summarize the idea:
>
> > If an object target is built from a module interface unit, the rules
> generated
> > are:
> >
> > ```Makefile
> > target.o: source.cc regular_prereqs header_unit_prereqs|
> header_unit_prereqs \
> > module_prereqs
> > source_cmi.gcm: source.cc regular_prereqs header_unit_prereqs \
> > module_prereqs| target.o
> > ```
> > If an object target is not, the rule generated is:
> >
> > ```Makefile
> > target.o: source_files regular_prereqs \
> > header_unit_prereqs| header_unit_prereqs module_prereqs
> > ```
> >
> > The `header_unit_prereqs` and `module_prereqs` are paths to the
> corresponding
> > CMI files.
>
> The patched GCC can be found [here](
> https://github.com/vspefs/gcc/tree/module-makefile-gen-fix).
>
> An example project can be found [here](
> https://github.com/vspefs/makefile-cxx-module).
>
> Best regards,
> vspefs


Could your approach simultaneously be used to have better dependency
information for Fortran modules? I feel like there’s at least some overlap
there.

Regarding Fortran modules, it is possible to create both the .o and any
needed .mod files from one compiler execution. You can tell GNU Make that a
particular rule creates multiple files using a grouped target (
https://www.gnu.org/software/make/manual/make.html#Multiple-Targets), and
older make has a work around using pattern rules. With a grouped target and
knowledge of the modules that a translation unit will create, the make
rules are straightforward.

There’s not a whole lot of conceptual difference between that and these gcm
files, right? If gcc could output a rule that a .o creates one or more .mod
files for Fortran, or a whole lot of .gcm files for c++, then the same
machinery could be used for both.

>

Re: RFC: A redesign of `-Mmodules` output

[Paul Smith via Gcc]

On Fri, 2025-02-28 at 18:05 +0100, Ben Boeckel via Gcc wrote:
> Note that one thing that is missing is ninja's `restat = 1` feature.
> This "restats" the output for the associated rule (probably spelled
> `.RESTAT: output` in Make) and skips running dependent rules if the
> output has not updated the mtime of the output(s) before the rule
> (recipe) was executed. This can be used for modules to not have to
> recompile sources that import the output modules it if they didn't
> change

I've seen this statement a few times and I've read the description of
restat in the Ninja docs and also the above, and I guess I'm just too
dumb to understand it.

Can someone explain with an example?

In POSIX make, including GNU Make, if a command doesn't modify the
modification time of the target then that target is not considered
updated, and other targets which list it as a prerequisite are not
invoked:

  $ cat Makefile
  MKTWO = touch
  one: two ; touch $@
  two: three ; $(MKTWO) $@

When we change "three" and then allow the MKTWO recipe to update "two"
then "one" is out-of-date and rebuilt:

  ~$ touch three; make
  touch two
  touch one

  ~$ touch three; make
  touch two
  touch one

When we change "three" then cause the MKTWO recipe to NOT update "two",
then "one" is not out-of-date and not rebuilt:

  ~$ touch three; make -f /tmp/x3.mk MKTWO=echo
  echo two
  two


Can someone explain how the Ninja "restat" feature differs from this?

Re: RFC: A redesign of `-Mmodules` output

[Paul Smith via Gcc]

On Fri, 2025-02-28 at 13:07 -0500, Paul Smith via Gcc wrote:
>   ~$ touch three; make -f /tmp/x3.mk MKTWO=echo

Sorry this should be just "make MKTWO=echo"; my typo.

Re: memory model, READ_ONCE

[Martin Uecker via Gcc]

Am Freitag, dem 28.02.2025 um 08:18 +0100 schrieb Richard Biener via Gcc:
> On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker  wrote:
> > 
> > 
> > Hi all,
> > 
> > one area where the Linux kernel people are unhappy with C's
> > memory model is where they now have to use the READ_ONCE,
> > WRITE_ONCE macros.  These are cases where they do not want
> > a compiler to duplicate a load, e.g. to reload a value
> > later because registers were not available to cache it.
> 
> The RA could do this as part of re-materialization to
> avoid a spill-reload and I think this would be sensible.
> 
> > Or similar, where a compiler produces two writes to
> > the same object where the source has only one or
> > invents a write where none existed, e.g. by turning
> > a conditional write after a read in an unconditional
> > one.
> 
> That should be covered by -fno-allow-store-data-races
> There might be the assumption that automatic variables
> that have their address not taken are not subject to
> store data races, and I have a hard time thinking of a
> reason to want READ_ONCE or WRITE_ONCE for such.
> 
> > General, it seems compilers currently do not do this.
> 
> Yes, because it's a de-optimization.  But for example
> the partial PRE optimization can introduce a read to
> a program path where it wasn't read to remove a
> redundancy on another path that looks more performance
> critical.  Similarly a sinking transform could do the very
> same to a store (but see above for -fallow-store-data-races).
> 
> > One could alreay use volatile and then the C standard
> > would guarantee that there are exactly as many accesses
> > as the source code implies, but this is too strong,
> > because combining multiple reads into one and caching
> > the value or dead store elimination would still be ok.
> 
> volatile is what gives you the guarantee for reads at
> the moment.
> 
> > The question is whether there are cases where GCC (or
> > C compilers in general) do such things?   Or if not,
> > where this would be desirable?   In other words:
> > Would it be a ok to strengthen the requirements
> > here?
> 
> We have volatile, I don't see a good reason to invent
> something new here, esp. that we have this guarantee
> for stores anyway and that for reads it's going to be
> quite difficult to implement that guarantee.

Thank you! This is very helpful information.

Martin

Re: [GSoC][Rewrite Rust lints]: Suggestions to get started

[Martin Jambor]

Hi,

On Sat, Mar 01 2025, 岡田隆太郎 via Gcc wrote:
> Hello,
>
> My name is Ryutaro Okada. I am interested in participating in Google Summer
> of Code 2024 with the GCC organization.

Presumably 2025? ;-)

> I am particularly fascinated by the
> project "Rewrite Rust lints to operate on our frontend's HIR instead of
> using GCC's existing infrastructure."
>
> I have prior experience in compiler development, having implemented a
> compiler based on the book *Modern Compiler Implementation in ML*.
>
> Since this is my first time contributing to GCC, I would appreciate any
> advice on how to get started. Currently, I have successfully built the
> source code and am eager to delve deeper into contributing to this project.

We are delighted you found contributing to GCC interesting.

Please note that Rust GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the GCC-Rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to the GCC-Rust community primarily there.

Thanks and good luck!

Martin

>
> I am excited about the opportunity to contribute and learn from this
> experience. Thank you for your time and guidance. I look forward to your
> response.
>
> Best regards,
> Ryutaro Okada

Re: RFC: A redesign of `-Mmodules` output

[Ben Boeckel via Gcc]

On Fri, Feb 28, 2025 at 13:07:04 -0500, Paul Smith wrote:
> On Fri, 2025-02-28 at 18:05 +0100, Ben Boeckel via Gcc wrote:
> > Note that one thing that is missing is ninja's `restat = 1` feature.
> > This "restats" the output for the associated rule (probably spelled
> > `.RESTAT: output` in Make) and skips running dependent rules if the
> > output has not updated the mtime of the output(s) before the rule
> > (recipe) was executed. This can be used for modules to not have to
> > recompile sources that import the output modules it if they didn't
> > change
> 
> I've seen this statement a few times and I've read the description of
> restat in the Ninja docs and also the above, and I guess I'm just too
> dumb to understand it.
> 
> Can someone explain with an example?
> 
> In POSIX make, including GNU Make, if a command doesn't modify the
> modification time of the target then that target is not considered
> updated, and other targets which list it as a prerequisite are not
> invoked:

Hmm. My understanding was that if a recipe is run, its outputs are
assumed to have been updated. I forget where I saw that, but it sticks
in my mind for some reason. Experimenting with GNU Make indeed does
exhibit `restat = 1` behavior out-of-the-box. That's good to know :) .
I'll update my priors. Thanks for the check. Here's my test case I was
working with with better names:

```make
restat_output: restat_input
cp -v $< $@
restat_input: source
diff -q $< $@ || cp -v $< $@
```

--Ben

Re: Introduction & Interest in GCC Rust Frontend GSoC Project

[Martin Jambor]

Hello,

On Thu, Feb 27 2025, Bright Andoh via Gcc wrote:
> Hello GCC Rust Team,
>
> My name is Bright Andoh, and I’m a Computer Engineering student at the
> University of Alabama. I’m wrapping up my freshman year and have
> experience working with Rust and C. Last fall, I collaborated on some
> Rust projects with a friend, and I’m eager to deepen my understanding,
> especially in compiler development and large codebases.
>
> I’m very interested in the Rust Frontend GSoC project and would love
> to contribute. I’ve started exploring the gccrs repository and would
> appreciate any guidance on where to begin. Are there any recommended
> beginner-friendly issues or specific areas that would be useful to
> familiarize myself with before applying?

We are delighted you found contributing to GCC interesting.

Please note that Rust GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the GCC-Rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to the GCC-Rust community primarily there.

Good luck!

Martin

>
> I’m excited to learn and contribute to this project. Looking forward
> to your guidance!
>
> Best ,
> Bright Andoh

Introduction & Interest in GCC Rust Frontend GSoC Project

[Basile Starynkevitch]

Hello Bright Andoh,

> 
> My name is Bright Andoh, and I’m a Computer Engineering student at the
> University of Alabama. I’m wrapping up my freshman year and have
> experience working with Rust and C. Last fall, I collaborated on some
> Rust projects with a friend, and I’m eager to deepen my understanding,
> especially in compiler development and large codebases.
> 

Long time ago, I did contribute to GCC (its plugin infrastructure).
https://arxiv.org/pdf/1109.0779 (perhaps this paper could be relevant to you)

A possible approach to your goal might be:

become familiar with GCC code base so be able to compile it (on a Linux
computer) from source code. Be prepared to spend a few days on that.

be able to run the GDB debugger on the GCC compiler (actually its cc1). Be
prepared to spend a few days on that.

study the source code of the existing Rust compiler https://www.rust-lang.org/,
only the front-end (e.g. macros & ownership things).

Adapt it to GCC using libgccjit. This means understanding the current rust
compiler internals and using libgccjit to feed GCC.

https://gcc.gnu.org/onlinedocs/jit/

so my suggestion could be to prototype your Rust frontend as a GCC plugin (and
reuse as much as possible existing frontend from  https://www.rust-lang.org/)

Be sure to put your experimental code on some publicly available website (github
or something else) for other to review it.

BTW my current open source project is an inference engine, on
https://github.com/RefPerSys/RefPerSys/


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

Re: Introduction & Interest in GCC Rust Frontend GSoC Project

[Basile Starynkevitch]

On Fri, 2025-02-28 at 12:00 +, Sam James wrote:
> Basile Starynkevitch  writes:
> 
> > Hello Bright Andoh,
> > 
> > > 
> > > My name is Bright Andoh, and I’m a Computer Engineering student at the
> > > University of Alabama. I’m wrapping up my freshman year and have
> > > experience working with Rust and C. Last fall, I collaborated on some
> > > Rust projects with a friend, and I’m eager to deepen my understanding,
> > > especially in compiler development and large codebases.
> > > 
> > 
> > Long time ago, I did contribute to GCC (its plugin infrastructure).
> > https://arxiv.org/pdf/1109.0779 (perhaps this paper could be relevant to
> > you)
> > 
> > A possible approach to your goal might be:
> > 
> > become familiar with GCC code base so be able to compile it (on a Linux
> > computer) from source code. Be prepared to spend a few days on that.
> > 
> > be able to run the GDB debugger on the GCC compiler (actually its cc1). Be
> > prepared to spend a few days on that.
> > 
> > study the source code of the existing Rust compiler
> > https://www.rust-lang.org/,
> > only the front-end (e.g. macros & ownership things).
> > 
> > Adapt it to GCC using libgccjit. This means understanding the current rust
> > compiler internals and using libgccjit to feed GCC.
> > 
> > https://gcc.gnu.org/onlinedocs/jit/
> > 
> > so my suggestion could be to prototype your Rust frontend as a GCC plugin
> > (and
> > reuse as much as possible existing frontend from 
> > https://www.rust-lang.org/)
> > 
> 
> I'm sorry, but this advice is mistaken/misplaced.
> 
> GCC *has* a rust frontend in-tree and it's one of our listed GSoC ideas
> to help contribute to it at
> https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas.
> 
> Not only that, there is additionally a libgccjit backend for the
> rust-lang.org implementation of rustc, see
> https://github.com/rust-lang/rustc_codegen_gcc.


Then you need to define your goals:

1. obtain a GCC frontend to Rust independent of any existing code
on https://github.com/rust-lang/

2. improve the existing GCC rust frontend to fit into latest Rust standard. 
Probably by running the existing testsuite (of rust-lang)

3. have similar (or not) diagnostics 


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

[GSoC][Rewrite Rust lints]: Suggestions to get started

[岡田隆太郎 via Gcc]

Hello,

My name is Ryutaro Okada. I am interested in participating in Google Summer
of Code 2024 with the GCC organization. I am particularly fascinated by the
project "Rewrite Rust lints to operate on our frontend's HIR instead of
using GCC's existing infrastructure."

I have prior experience in compiler development, having implemented a
compiler based on the book *Modern Compiler Implementation in ML*.

Since this is my first time contributing to GCC, I would appreciate any
advice on how to get started. Currently, I have successfully built the
source code and am eager to delve deeper into contributing to this project.

I am excited about the opportunity to contribute and learn from this
experience. Thank you for your time and guidance. I look forward to your
response.

Best regards,
Ryutaro Okada

Re: memory model, READ_ONCE

[Martin Uecker via Gcc]

Am Freitag, dem 28.02.2025 um 20:21 +0100 schrieb Richard Biener:
> 
> > Am 28.02.2025 um 20:02 schrieb Martin Uecker :
> > 
> > Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov:
> > > > On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
> > > > 
> > > > 
> > > > I have one follow-up question:  What is the reason
> > > > that we have stronger semantics for stores by default (i.e.
> > > > when not using -fallow-store-data-races) than for reads
> > > > given that the standard would allow more freedom.
> > > 
> > > Why would it? On the contrary, it makes an explicit note that
> > > introducing new writes that could create a racing store is
> > > not allowed, see note 13 in C11 5.1.2.4.
> > 
> > My original question was about inventing stores that currently
> > seem to be allowed.  Turning
> > 
> > if (x != 1)
> >  x = 1;
> > 
> > into
> > 
> > x = 1;
> > 
> > should be ok even though it invents a store for x == 1.
> > 
> > While this technically introduces a race with another
> > reader, it does so only in a seeminglessly harmless way
> > when overwriting 1 with 1.
> > 
> > Are you saying -fallow-store-data-races also introduces
> > other kinds of races not allowed by C11?
> 
> The default is -fno-allow-store-data-races

Sorry for being a bit slow.  This is still not clear to me.

In vect/pr65206.c the following loop can be vectorized
with -fallow-store-data-races.

#define N 1024

double a[N], b[N];

void foo ()
{
  for (int i = 0; i < N; ++i)
if (b[i] < 3.)
  a[i] += b[i];
}

But even though this invents stores these would still seem
to be allowed by C11 because they are not detectable to
another reader because they write back the same value as
read.

Is this understanding correct? 

Does -fallow-store-data-races also create other data races
which would not be allowed by C11?

What was the reason to disallow those optimizations that 
could be allowed by default?

Martin

> 
> > Martin
> > 
> > > 
> > > > Only that for reads this is more difficult t  o have?
> > > > Or other specific reasons why data races for stores
> > > > are problematic?
> > > 
> > > Introducing racing loads is generally not harmful, see note 14.
> > 
> > 
> > 
> > 
> >