Re: Rust front-end

[Richard Biener via Gcc-rust]

On Mon, Jun 27, 2022 at 4:52 PM Philip Herron
 wrote:
>
> Hi everyone,
>
> Since November 2020, I've worked full-time on the Rust front-end for
> GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
> am writing to this mailing list to seek feedback from the collective
> experience here early to plan a path for upstreaming the front-end
> into GCC.
>
> 1. What is the actual process of merging a prominent feature like this 
> upstream
>   - How do we review this?
>   - Do we create a "mega-commit" patch
>   - How long should we expect this review process to take
>   - Is there anything we can do to make this easier?

Usually a new frontend is first proposed for merge and generally approved
by the steering committee (which should also sort out legal issues).

For the actual review process it's best to consult previous frontend
merges - the most recent merged frontend was the D frontend and the
modula2 frontend is in the process of being reviewed.

To be able to focus on the possibly controversical pieces separating
out changes to the generic GCC code base (such as driver or
even middle-end) should be separated out.

It would also be helpful to provide an overview of how a rust
compile + link cycle works through the pieces in GCC (see the
modula-2 case where that involved creating stub C++ code,
compiling and linking that and how this is now done much
more straight-forward).

> 2. What sort of quality does the GCC community expect?
>   - I think it is essential that we can compile valid test cases from
> a testsuite and real projects before merging.
>   - It seems reasonable that our error handling may not be 100% but be
> expected to improve over time
>   - Upon merging, can features like Rust be marked as experimental

Rust can be marked as experimental, sure.  It would be not enabled
to be built by default (and you can have a whitelist of supported targets).
The most important part would be that the build works when enabled
and that most of the existing testsuite passes so it can be used to
regression test middle-end changes.

If it is not useful at all for (basic) real-world usage then it might be not
ready yet.

> 3. How do GCC releases work?
>   - If you miss a window can we still merge code into the front-end?
>   - Can we merge without a borrow checker and backport this in the future?

The rust frontend will not be part of the release critical pieces of the
compiler (which includes the C and C++ frontends plus the set of
primary and secondary targets) so it is up to the maintainers to decide
what to merge and when.  Release managers will generally ignore
issues in Rust.

> 4. What about the possibility of merging sooner rather than later,
> which would help the project gain interest through the increased
> visibility of it as part of the GCC family.
>   - Does this still allow for development churn, or will it cause friction?

The parts where GCC and Rust overlap still need to be reviewed and
_some_ usability for users should be provided.

> 5. Does anyone have prior experience or advice they could give us?

I suppose Ian (for the Go frontend) or Iain (for the D frontend) can give
you hints.

> For some context, my current project plan brings us to November 2022
> where we (unexpected events permitting) should be able to support
> valid Rust code targeting Rustc version ~1.40 and reuse libcore,
> liballoc and libstd. This date does not account for the borrow checker
> feature and the proc macro crate, which we have a plan to implement,
> but this will be a further six-month project.
>
> Regarding patch management, we currently do our development on GitHub:
> https://github.com/Rust-GCC/gccrs; this means we can integrate our
> issue tracking with the official Rust project by linking back to the
> official Rust project's RFC issues, for example. The downside is that
> when someone uses our compiler and hits an ICE, they will be directed
> to the GCC Bugzilla, which is correct but can lead to a mismatch in
> issue tracking. Nevertheless, I think it's essential to have the
> GitHub link here to integrate with the broader Rust community. I
> believe we can triage Rust issues on the Bugzilla and raise associated
> ones on Github to manage this.
>
> From my perspective as the lead on this front-end, we are currently
> under heavy development, so this means a fair amount of code churn
> still, and I don't see this changing until we can successfully compile
> the libcore crate later this year. Although I would love to see us
> merged into GCC 13, I want to make sure this project is a success for
> everyone, and this might mean pushing back to the next release window
> to make sure this is manageable to produce a quality front-end to sit
> alongside the others.

If you want to target GCC 13 for experimental Rust support I suggest to
get review on the overall design (where it touches GCC) and the changes
necessary to driver and build changes.  The core frontend itself will usually
only get revie

Re: Rust front-end

[Richard Biener via Gcc-rust]

On Fri, Jul 8, 2022 at 7:32 PM Philip Herron  wrote:
>
> Hi Richard
>
> Thanks for your detailed response, I took some time to figure this out
> myself to give a decent response. It seems like we should keep the end
> of the year as our goal to aim for but in the meantime see if we can
> split patches which affect GCC over the next month or so. We have no
> changes to the GCC gimple/generic IRs. Usually, when I hit something
> inside the GCC middle-end, the front-end is doing something wrong,
> which has helped keep me on a good path. Other than that we have
> changes to:
>
> 1. Grabbing target info using the TARGET_HOOKS interfaces in gcc/config.
> 2. Tweaks to selftest which was already merged last year by Arthur Cohen
> 3. We have some minor issues with lang.opt in the latest merge from
> upstream which Thomas Schwinge is working on, but I believe we can
> work around this if we want
> 4. Our compiler driver needs some cleanup which we can do in the short
> term to get it reviewed
> 5. We need to make some build changes to incorporate libcore being
> built by gccrs which is still WIP.
>
> As for the compile link cycle, we mostly reuse the model from the GO
> front-end. In Rust the "crate" is a compilation unit, which means if
> you have a project with multiple files, you point gccrs at a single
> src/source.rs, the main entry point for a library (usually lib.rs).
> Keywords such as "mod foo", trigger the expansion of a relative path
> of foo.rs like a C++ included inside a namespace. All source files are
> then included inside this single compilation unit. When the
> compilation is successful, we reuse code from the Go front-end to put
> custom front-end metadata into a section ".rust_export". At this
> point, all source files are compiled into a single object file, which
> can be compiled into an archive or shared library as required. To link
> against this, it again follows similar to Go front-end, whereby the
> source.rs has a declaration such as "extern crate foo"; the search
> code will look for foo.o or libfoo.a (I haven't tested against shared
> libraries yet) and grab the metadata out of it and parse it in the
> front-end for all the necessary information such as types, public
> functions and generics, etc., so we can compile any imports correctly
> and emit the correct mangled symbols for linking.
>
> Given we are still working on this I think we can try to line up all
> the other GCC relating pieces for review over the summer, do we send
> this as usual to gcc-patches?

Yes, that's the prefered way.  Having an integration branch ready for
people to play with is also useful - if you are ready you might want to
push something like that to the gcc.gnu.org repository under the devel/
namespace.

Thanks,
Richard.

> Again thanks to everyone for helping me navigate this and answering my
> questions.
>
> --Phil
>
> On Tue, 28 Jun 2022 at 08:30, Richard Biener  
> wrote:
> >
> > On Mon, Jun 27, 2022 at 4:52 PM Philip Herron
> >  wrote:
> > >
> > > Hi everyone,
> > >
> > > Since November 2020, I've worked full-time on the Rust front-end for
> > > GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
> > > am writing to this mailing list to seek feedback from the collective
> > > experience here early to plan a path for upstreaming the front-end
> > > into GCC.
> > >
> > > 1. What is the actual process of merging a prominent feature like this 
> > > upstream
> > >   - How do we review this?
> > >   - Do we create a "mega-commit" patch
> > >   - How long should we expect this review process to take
> > >   - Is there anything we can do to make this easier?
> >
> > Usually a new frontend is first proposed for merge and generally approved
> > by the steering committee (which should also sort out legal issues).
> >
> > For the actual review process it's best to consult previous frontend
> > merges - the most recent merged frontend was the D frontend and the
> > modula2 frontend is in the process of being reviewed.
> >
> > To be able to focus on the possibly controversical pieces separating
> > out changes to the generic GCC code base (such as driver or
> > even middle-end) should be separated out.
> >
> > It would also be helpful to provide an overview of how a rust
> > compile + link cycle works through the pieces in GCC (see the
> > modula-2 case where that involved creating stub C++ code,
> > compiling and linking that and how this is now done much
> > more straight-forward).
> >
> > > 2. What sort of quality does the GCC community expect?
> > >   - I think it is essential that we can compile valid test cases from
> > > a testsuite and real projects before merging.
> > >   - It seems reasonable that our error handling may not be 100% but be
> > > expected to improve over time
> > >   - Upon merging, can features like Rust be marked as experimental
> >
> > Rust can be marked as experimental, sure.  It would be not enabled
> > to be built by default (and you can have a whitelist of supporte

Re: [PATCH Rust front-end v2 09/37] gccrs: Add Lexer for Rust front-end

[Richard Biener via Gcc-rust]

On Wed, Aug 24, 2022 at 2:04 PM  wrote:
>
> From: The Other 
>
> The lexer is refered to as a ManagedTokenSource within the parser, this
> lexer does not currently support unicode but serves as a starting point
> to do so.
>
> Co-authored-by: Philip Herron 
> Co-authored-by: Arthur Cohen 
> Co-authored-by: Mark Wielaard 
> ---
>  gcc/rust/lex/rust-codepoint.h  |   46 +
>  gcc/rust/lex/rust-lex.cc   | 2729 
>  gcc/rust/lex/rust-lex.h|  271 
>  gcc/rust/lex/rust-token.cc |  135 ++
>  gcc/rust/lex/rust-token.h  |  455 ++
>  gcc/rust/rust-buffered-queue.h |  204 +++
>  6 files changed, 3840 insertions(+)
>  create mode 100644 gcc/rust/lex/rust-codepoint.h
>  create mode 100644 gcc/rust/lex/rust-lex.cc
>  create mode 100644 gcc/rust/lex/rust-lex.h
>  create mode 100644 gcc/rust/lex/rust-token.cc
>  create mode 100644 gcc/rust/lex/rust-token.h
>  create mode 100644 gcc/rust/rust-buffered-queue.h
>
> diff --git a/gcc/rust/lex/rust-codepoint.h b/gcc/rust/lex/rust-codepoint.h
> new file mode 100644
> index 000..22da080bbb2
> --- /dev/null
> +++ b/gcc/rust/lex/rust-codepoint.h
> @@ -0,0 +1,46 @@
> +// Copyright (C) 2020-2022 Free Software Foundation, Inc.
> +
> +// This file is part of GCC.
> +
> +// GCC is free software; you can redistribute it and/or modify it under
> +// the terms of the GNU General Public License as published by the Free
> +// Software Foundation; either version 3, or (at your option) any later
> +// version.
> +
> +// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> +// WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +// for more details.
> +
> +// You should have received a copy of the GNU General Public License
> +// along with GCC; see the file COPYING3.  If not see
> +// .
> +
> +#ifndef RUST_CODEPOINT_H
> +#define RUST_CODEPOINT_H
> +
> +#include 
> +
> +namespace Rust {
> +struct Codepoint
> +{
> +  uint32_t value;
> +
> +  // Creates a zero codepoint.
> +  Codepoint () : value (0) {}
> +
> +  // Creates a codepoint from an encoded UTF-8 value.
> +  Codepoint (uint32_t value) : value (value) {}
> +
> +  static Codepoint eof () { return Codepoint (UINT32_MAX); }
> +  bool is_eof () const { return value == UINT32_MAX; }
> +
> +  // Returns a C++ string containing string value of codepoint.
> +  std::string as_string ();
> +
> +  bool operator== (Codepoint other) const { return value == other.value; }
> +  bool operator!= (Codepoint other) const { return !operator== (other); }
> +};
> +} // namespace Rust
> +
> +#endif
> diff --git a/gcc/rust/lex/rust-lex.cc b/gcc/rust/lex/rust-lex.cc
> new file mode 100644
> index 000..70e6b50209f
> --- /dev/null
> +++ b/gcc/rust/lex/rust-lex.cc
> @@ -0,0 +1,2729 @@
> +// Copyright (C) 2020-2022 Free Software Foundation, Inc.
> +
> +// This file is part of GCC.
> +
> +// GCC is free software; you can redistribute it and/or modify it under
> +// the terms of the GNU General Public License as published by the Free
> +// Software Foundation; either version 3, or (at your option) any later
> +// version.
> +
> +// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> +// WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +// for more details.
> +
> +// You should have received a copy of the GNU General Public License
> +// along with GCC; see the file COPYING3.  If not see
> +// .
> +
> +#include "rust-lex.h"
> +
> +#include "rust-system.h"  // for rust_assert and rust_unreachable
> +#include "rust-diagnostics.h" // for rust_error_at
> +#include "rust-linemap.h"
> +#include "rust-session-manager.h"
> +#include "safe-ctype.h"

just diving into a random patch here - I'm assuming I can take rust-lex.cc as
a boiler-plate example for the #include structure.

In GCC all files should start with #including "config.h" followed by
"system.h" where _all_ system, including C++ standard library headers
should be pulled via system.h to allow working around OS and system
compiler issues.

It might be that rust-system.h plays the role of config.h + system.h
but then the rust-lex.h include is before it.

rust-codepoint.h including  is also problematic btw.

Richard.

> +namespace Rust {
> +// TODO: move to separate compilation unit?
> +// overload += for uint32_t to allow 32-bit encoded utf-8 to be added
> +std::string &
> +operator+= (std::string &str, Codepoint char32)
> +{
> +  if (char32.value < 0x80)
> +{
> +  str += static_cast (char32.value);
> +}
> +  else if (char32.value < (0x1F + 1) << (1 * 6))
> +{
> +  str += static_cast (0xC0 | ((char32.value >> 6) & 0x1F));
> +  str += static_cast (0x80 | ((char32.value >> 0) & 0x3F));
> +}
> +  else if (char32.value < (0x0F + 1) << (2 *

Re: [PATCH Rust front-end v2 31/37] gccrs: Add GCC Rust front-end Make-lang.in

[Richard Biener via Gcc-rust]

On Wed, Aug 24, 2022 at 2:22 PM  wrote:
>
> From: Philip Herron 
>
> This is the Makefile for our front-end.
> ---
>  gcc/rust/Make-lang.in | 400 ++
>  1 file changed, 400 insertions(+)
>  create mode 100644 gcc/rust/Make-lang.in
>
> diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
> new file mode 100644
> index 000..f687cc2f667
> --- /dev/null
> +++ b/gcc/rust/Make-lang.in
> @@ -0,0 +1,400 @@
> +# Make-lang.in -- Top level -*- makefile -*- fragment for GCC Rust frontend.
> +
> +# Copyright (C) 2009-2022 Free Software Foundation, Inc.
> +
> +# This file is part of GCC.
> +
> +# GCC is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3, or (at your option)
> +# any later version.
> +
> +# GCC is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +
> +# You should have received a copy of the GNU General Public License
> +# along with GCC; see the file COPYING3.  If not see
> +# .
> +
> +# This file provides the language dependent support in the main Makefile.
> +
> +#RUST_EXES = rust
> +
> +# Use strict warnings for this front end.
> +rust-warn = $(STRICT_WARN)
> +
> +# Installation name. Useful for cross compilers and used during install.
> +GCCRS_INSTALL_NAME := $(shell echo gccrs|sed '$(program_transform_name)')
> +GCCRS_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo gccrs|sed 
> '$(program_transform_name)')
> +
> +# Define the names for selecting rust in LANGUAGES.
> +rust: rust1$(exeext)
> +
> +# Tell GNU make to ignore files by these names if they exist.
> +.PHONY: rust
> +
> +# removed GRS_CFLAGS from here
> +
> +CFLAGS-rust/rustspec.o += $(DRIVER_DEFINES)
> +
> +# Create the compiler driver gccrs.
> +# A compiler driver is the program that interprets command argument and can 
> be called from the command
> +# line - e.g. gcc or g++, and not cc1, which is the actual compiler
> +
> +# Create driver objects
> +GCCRS_D_OBJS = \
> +   $(GCC_OBJS) \
> +   rust/rustspec.o \
> +   $(END)
> +
> +gccrs$(exeext): $(GCCRS_D_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a 
> $(LIBDEPS)
> +   +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
> + $(GCCRS_D_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a \
> + $(EXTRA_GCC_LIBS) $(LIBS)
> +
> +# List of host object files used by the rust language - files for 
> translation from the parse tree
> +# to GENERIC
> +# The compiler proper, not driver
> +GRS_OBJS = \
> +rust/rust-lang.o \
> +rust/rust-object-export.o \
> +rust/rust-linemap.o \
> +rust/rust-gcc-diagnostics.o \
> +rust/rust-diagnostics.o \
> +rust/rust-gcc.o \
> +rust/rust-token.o \
> +rust/rust-lex.o \
> +rust/rust-cfg-parser.o \
> +rust/rust-parse.o \
> +rust/rust-ast-full-test.o \
> +rust/rust-ast-dump.o \
> +rust/rust-hir-dump.o \
> +rust/rust-session-manager.o \
> +rust/rust-compile.o \
> +rust/rust-mangle.o \
> +rust/rust-compile-resolve-path.o \
> +rust/rust-macro-expand.o \
> +rust/rust-attribute-visitor.o \
> +rust/rust-macro-invoc-lexer.o \
> +rust/rust-macro-substitute-ctx.o \
> +rust/rust-macro-builtins.o \
> +rust/rust-hir-full-test.o \
> +rust/rust-hir-map.o \
> +rust/rust-attributes.o \
> +rust/rust-abi.o \
> +rust/rust-ast-lower.o \
> +rust/rust-ast-lower-base.o \
> +rust/rust-ast-lower-pattern.o \
> +rust/rust-ast-lower-item.o \
> +rust/rust-name-resolver.o \
> +rust/rust-ast-resolve.o \
> +rust/rust-ast-resolve-base.o \
> +rust/rust-ast-resolve-item.o \
> +rust/rust-ast-resolve-pattern.o \
> +rust/rust-ast-resolve-expr.o \
> +rust/rust-ast-resolve-type.o \
> +rust/rust-ast-resolve-path.o \
> +rust/rust-ast-resolve-stmt.o \
> +rust/rust-ast-resolve-struct-expr-field.o \
> +rust/rust-hir-type-check.o \
> +rust/rust-privacy-check.o \
> +rust/rust-privacy-ctx.o \
> +rust/rust-reachability.o \
> +rust/rust-visibility-resolver.o \
> +rust/rust-pub-restricted-visitor.o \
> +rust/rust-privacy-reporter.o \
> +rust/rust-tyty.o \
> +rust/rust-tyty-call.o \
> +rust/rust-tyctx.o \
> +rust/rust-tyty-bounds.o \
> +rust/rust-hir-type-check-util.o \
> +rust/rust-hir-trait-resolve.o \
> +rust/rust-hir-type-check-toplevel.o \
> +rust/rust-hir-type-check-item.o \
> +rust/rust-hir-type-check-type.o \
> +rust/rust-hir-type-check-struct.o \
> +rust/rust-hir-type-check-pattern.o \
> +rust/rust-hir-type-check-expr.o \
> +rust/rust-hir-type-check-stmt.o \
> +rust/rust-hir-type-check-enumitem.o \
> +rust/rust-hir-type-check-implitem.o \
> +rust/rust-hir-dot-o

Re: [PATCH Rust front-end v2 34/37] gccrs: add lang.opt

[Richard Biener via Gcc-rust]

On Wed, Aug 24, 2022 at 2:13 PM  wrote:
>
> From: Philip Herron 
>
> We have some rust specific langugage options note -fwrapv is enabled by
> default in the code. We are trying to respect options such as
> -Wunused-result which we get by porting over c++ no-discard for rust's
> must-use attribute, so we have enabled these by default directly here.

LGTM

Richard.

> ---
>  gcc/rust/lang.opt | 118 ++
>  1 file changed, 118 insertions(+)
>  create mode 100644 gcc/rust/lang.opt
>
> diff --git a/gcc/rust/lang.opt b/gcc/rust/lang.opt
> new file mode 100644
> index 000..1f6855ede1d
> --- /dev/null
> +++ b/gcc/rust/lang.opt
> @@ -0,0 +1,118 @@
> +; Options for the Rust front end.
> +; Copyright (C) 2003-2022 Free Software Foundation, Inc.
> +;
> +; This file is part of GCC.
> +;
> +; GCC is free software; you can redistribute it and/or modify it under
> +; the terms of the GNU General Public License as published by the Free
> +; Software Foundation; either version 3, or (at your option) any later
> +; version.
> +;
> +; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> +; WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +; for more details.
> +;
> +; You should have received a copy of the GNU General Public License
> +; along with GCC; see the file COPYING3.  If not see
> +; .
> +
> +; See the GCC internals manual for a description of this file's format.
> +
> +; Please try to keep this file in ASCII collating order.
> +
> +; Describes command-line options used by this frontend
> +
> +Language
> +Rust
> +
> +I
> +Rust Joined Separate
> +; Documented in c.opt
> +
> +L
> +Rust Joined Separate
> +; Not documented
> +
> +Wall
> +Rust
> +; Documented in c.opt
> +
> +Wunused-variable
> +Rust Var(warn_unused_variable) Init(1) Warning
> +; documented in common.opt
> +
> +Wunused-const-variable
> +Rust Warning Alias(Wunused-const-variable=, 2, 0)
> +Warn when a const variable is unused.
> +
> +Wunused-const-variable=
> +Rust Joined RejectNegative UInteger Var(warn_unused_const_variable) Init(1) 
> Warning LangEnabledBy(Rust,Wunused-variable, 1, 0) IntegerRange(0, 2)
> +Warn when a const variable is unused.
> +
> +Wunused-result
> +Rust Var(warn_unused_result) Init(1) Warning
> +Warn if a caller of a function, marked with attribute warn_unused_result, 
> does not use its return value.
> +
> +frust-crate=
> +Rust Joined RejectNegative
> +-frust-crate= Set the crate name for the compilation
> +
> +frust-debug
> +Rust Var(flag_rust_debug)
> +Dump various Rust front end internals.
> +
> +frust-dump-
> +Rust Joined RejectNegative
> +-frust-dump- Dump Rust frontend internal information.
> +
> +frust-max-recursion-depth=
> +Rust RejectNegative Type(int) Var(rust_max_recursion_depth) Init(64)
> +-frust-max-recursion-depth=integer
> +
> +frust-mangling=
> +Rust Joined RejectNegative Enum(frust_mangling) Var(flag_rust_mangling)
> +-frust-mangling=[legacy|v0] Choose which version to use for name mangling
> +
> +Enum
> +Name(frust_mangling) Type(int) UnknownError(unknown rust mangling option %qs)
> +
> +EnumValue
> +Enum(frust_mangling) String(legacy) Value(0)
> +
> +EnumValue
> +Enum(frust_mangling) String(v0) Value(1)
> +
> +frust-cfg=
> +Rust Joined RejectNegative
> +-frust-cfg= Set a config expansion option
> +
> +frust-edition=
> +Rust Joined RejectNegative Enum(frust_edition) Var(flag_rust_edition)
> +-frust-edition=[2015|2018|2021] Choose which edition to use when 
> compiling rust code
> +
> +Enum
> +Name(frust_edition) Type(int) UnknownError(unknown rust edition %qs)
> +
> +EnumValue
> +Enum(frust_edition) String(2015) Value(0)
> +
> +EnumValue
> +Enum(frust_edition) String(2018) Value(1)
> +
> +EnumValue
> +Enum(frust_edition) String(2021) Value(2)
> +
> +frust-embed-metadata
> +Rust Var(flag_rust_embed_metadata)
> +Flag to enable embeding metadata directly into object files
> +
> +frust-metadata-output=
> +Rust Joined RejectNegative
> +-frust-metadata-output=  Path to output crate metadata
> +
> +o
> +Rust Joined Separate
> +; Documented in common.opt
> +
> +; This comment is to ensure we retain the blank line above.
> --
> 2.25.1
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v2 32/37] gccrs: Add config-lang.in

[Richard Biener via Gcc-rust]

On Wed, Aug 24, 2022 at 2:19 PM  wrote:
>
> From: Philip Herron 
>
> This was a copy paste from gccgo front-end, we do not use any of the
> target_libs yet but we will need these when we support the libpanic crate.

LGTM

> ---
>  gcc/rust/config-lang.in | 34 ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 gcc/rust/config-lang.in
>
> diff --git a/gcc/rust/config-lang.in b/gcc/rust/config-lang.in
> new file mode 100644
> index 000..d2ff376032a
> --- /dev/null
> +++ b/gcc/rust/config-lang.in
> @@ -0,0 +1,34 @@
> +# config-lang.in -- Top level configure fragment for gcc Rust frontend.
> +
> +# Copyright (C) 2009-2022 Free Software Foundation, Inc.
> +
> +# This file is part of GCC.
> +
> +# GCC is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3, or (at your option)
> +# any later version.
> +
> +# GCC is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +
> +# You should have received a copy of the GNU General Public License
> +# along with GCC; see the file COPYING3.  If not see
> +# .
> +
> +# Configure looks for the existence of this file to auto-config each 
> language.
> +# We define several parameters used by configure:
> +#
> +# language - name of language as it would appear in $(LANGUAGES)
> +# compilers- value to add to $(COMPILERS)
> +
> +language="rust"
> +compilers="rust1\$(exeext)"
> +
> +build_by_default="no"
> +
> +target_libs="target-libffi target-libbacktrace"
> +
> +gtfiles="\$(srcdir)/rust/rust-lang.cc"
> --
> 2.25.1
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v2 33/37] gccrs: add lang-spec.h

[Richard Biener via Gcc-rust]

On Wed, Aug 24, 2022 at 2:20 PM  wrote:
>
> From: Philip Herron 
>
> This specifies the extensions of the Rust language.

LGTM

> ---
>  gcc/rust/lang-specs.h | 26 ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 gcc/rust/lang-specs.h
>
> diff --git a/gcc/rust/lang-specs.h b/gcc/rust/lang-specs.h
> new file mode 100644
> index 000..9b14a559dd6
> --- /dev/null
> +++ b/gcc/rust/lang-specs.h
> @@ -0,0 +1,26 @@
> +/* lang-specs.h -- gcc driver specs for Rust frontend.
> +   Copyright (C) 2009-2022 Free Software Foundation, Inc.
> +
> +   This file is part of GCC.
> +
> +   GCC is free software; you can redistribute it and/or modify it under
> +   the terms of the GNU General Public License as published by the Free
> +   Software Foundation; either version 3, or (at your option) any later
> +   version.
> +
> +   GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> +   WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +   FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +   for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with GCC; see the file COPYING3.  If not see
> +   .  */
> +
> +/* This is the contribution to the `default_compilers' array in gcc.cc
> +   for the Rust language.  */
> +
> +{".rs", "@rs", 0, 1, 0},
> +  {"@rs",
> +   "rust1 %i %(cc1_options) %{I*} %{L*} %D %{!fsyntax-only:%(invoke_as)}", 
> 0, 1,
> +   0},
> --
> 2.25.1
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v2 07/37] gccrs: Add gcc-check-target check-rust

[Richard Biener via Gcc-rust]

On Wed, Aug 24, 2022 at 2:08 PM  wrote:
>
> From: Philip Herron 
>
> This allows us to invoke the rust testsuite.

OK.

>
> ChangeLog:
> * Makefile.def: Add autogen target
> * Makefile.in: regenerate via autogen
> ---
>  Makefile.def | 1 +
>  Makefile.in  | 8 
>  2 files changed, 9 insertions(+)
>
> diff --git a/Makefile.def b/Makefile.def
> index 3291b126b26..821016af3a2 100644
> --- a/Makefile.def
> +++ b/Makefile.def
> @@ -681,6 +681,7 @@ languages = { language=go;  gcc-check-target=check-go;
>  languages = { language=d;  gcc-check-target=check-d;
> lib-check-target=check-target-libphobos; };
>  languages = { language=jit;gcc-check-target=check-jit; };
> +languages = { language=rust;   gcc-check-target=check-rust; };
>
>  // Toplevel bootstrap
>  bootstrap_stage = { id=1 ; };
> diff --git a/Makefile.in b/Makefile.in
> index 1919dfee829..9ed2c0dec52 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -60583,6 +60583,14 @@ check-gcc-jit:
> (cd gcc && $(MAKE) $(GCC_FLAGS_TO_PASS) check-jit);
>  check-jit: check-gcc-jit
>
> +.PHONY: check-gcc-rust check-rust
> +check-gcc-rust:
> +   r=`${PWD_COMMAND}`; export r; \
> +   s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> +   $(HOST_EXPORTS) \
> +   (cd gcc && $(MAKE) $(GCC_FLAGS_TO_PASS) check-rust);
> +check-rust: check-gcc-rust
> +
>
>  # The gcc part of install-no-fixedincludes, which relies on an intimate
>  # knowledge of how a number of gcc internal targets (inter)operate.  
> Delegate.
> --
> 2.25.1
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v2 34/37] gccrs: add lang.opt

[Richard Biener via Gcc-rust]

On Wed, Sep 14, 2022 at 6:20 PM Thomas Schwinge  wrote:
>
> Hi!
>
> On 2022-09-14T15:39:47+0200, Richard Biener via Gcc-patches 
>  wrote:
> > On Wed, Aug 24, 2022 at 2:13 PM  wrote:
> >>
> >> From: Philip Herron 
> >>
> >> We have some rust specific langugage options note -fwrapv is enabled by
> >> default in the code. We are trying to respect options such as
> >> -Wunused-result which we get by porting over c++ no-discard for rust's
> >> must-use attribute, so we have enabled these by default directly here.
> >
> > LGTM
>
> Actually, NACK.  ;-)
>
> See 
> "gccrs setting warn_unused_variable breaks thousands of non-Rust tests".
> The 'Init(1)' in 'gcc/rust/lang.opt' are in conflict with any (default)
> 'Init(0)' in other '*.opt' files -- remember that all '*.opt' files are
> processed together by GCC's "options machinery", and thus
> 'gcc/rust/lang.opt' may (and here, does) affect non-Rust front end code.

Ah, I wondered about the duplicates adding to the list of supported FEs, I guess
that the awk script should check for obvious mismatches in other settings?

> I do have a patch series adding a 'LangInit(@var{language}, @var{value})'
> option property, and patches to use this in a lot of places (here and in
> other front ends' '*.opt' files), where currently we implement such logic
> in '*.cc' files; '[...]_init_options_struct' functions via
> 'LANG_HOOKS_INIT_OPTIONS_STRUCT' (those then largely become empty and may
> be removed).  I assume this idea to be uncontroversial; I "just" need to
> get it polished and submitted...
>
>
> Grüße
>  Thomas
>
>
> >>  gcc/rust/lang.opt | 118 ++
> >>  1 file changed, 118 insertions(+)
> >>  create mode 100644 gcc/rust/lang.opt
> >>
> >> diff --git a/gcc/rust/lang.opt b/gcc/rust/lang.opt
> >> new file mode 100644
> >> index 000..1f6855ede1d
> >> --- /dev/null
> >> +++ b/gcc/rust/lang.opt
> >> @@ -0,0 +1,118 @@
> >> +; Options for the Rust front end.
> >> +; Copyright (C) 2003-2022 Free Software Foundation, Inc.
> >> +;
> >> +; This file is part of GCC.
> >> +;
> >> +; GCC is free software; you can redistribute it and/or modify it under
> >> +; the terms of the GNU General Public License as published by the Free
> >> +; Software Foundation; either version 3, or (at your option) any later
> >> +; version.
> >> +;
> >> +; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> >> +; WARRANTY; without even the implied warranty of MERCHANTABILITY or
> >> +; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> >> +; for more details.
> >> +;
> >> +; You should have received a copy of the GNU General Public License
> >> +; along with GCC; see the file COPYING3.  If not see
> >> +; .
> >> +
> >> +; See the GCC internals manual for a description of this file's format.
> >> +
> >> +; Please try to keep this file in ASCII collating order.
> >> +
> >> +; Describes command-line options used by this frontend
> >> +
> >> +Language
> >> +Rust
> >> +
> >> +I
> >> +Rust Joined Separate
> >> +; Documented in c.opt
> >> +
> >> +L
> >> +Rust Joined Separate
> >> +; Not documented
> >> +
> >> +Wall
> >> +Rust
> >> +; Documented in c.opt
> >> +
> >> +Wunused-variable
> >> +Rust Var(warn_unused_variable) Init(1) Warning
> >> +; documented in common.opt
> >> +
> >> +Wunused-const-variable
> >> +Rust Warning Alias(Wunused-const-variable=, 2, 0)
> >> +Warn when a const variable is unused.
> >> +
> >> +Wunused-const-variable=
> >> +Rust Joined RejectNegative UInteger Var(warn_unused_const_variable) 
> >> Init(1) Warning LangEnabledBy(Rust,Wunused-variable, 1, 0) IntegerRange(0, 
> >> 2)
> >> +Warn when a const variable is unused.
> >> +
> >> +Wunused-result
> >> +Rust Var(warn_unused_result) Init(1) Warning
> >> +Warn if a caller of a function, marked with attribute warn_unused_result, 
> >> does not use its return value.
> >> +
> >> +frust-crate=
> >> +Rust Joined RejectNegative
> >> +-frust-crate= Set the crate name for the compilation
> >> +
> >> +frust-debug
> >> +Rust Var(flag_rust_debug)
> >> +Dump various Rust front end internals.
> >> +
> >> +frust-dump-
> >> +Rust Joined RejectNegative
> >> +-frust-dump- Dump Rust frontend internal information.
> >> +
> >> +frust-max-recursion-depth=
> >> +Rust RejectNegative Type(int) Var(rust_max_recursion_depth) Init(64)
> >> +-frust-max-recursion-depth=integer
> >> +
> >> +frust-mangling=
> >> +Rust Joined RejectNegative Enum(frust_mangling) Var(flag_rust_mangling)
> >> +-frust-mangling=[legacy|v0] Choose which version to use for name 
> >> mangling
> >> +
> >> +Enum
> >> +Name(frust_mangling) Type(int) UnknownError(unknown rust mangling option 
> >> %qs)
> >> +
> >> +EnumValue
> >> +Enum(frust_mangling) String(legacy) Value(0)
> >> +
> >> +EnumValue
> >> +Enum(frust_mangling) String(v0) Value(1)
> >> +
> >> +frust-cfg=
> >> +Rust Joined RejectNegative
> >> +-frust-cfg= Set

Re: Rust frontend patches v3

[Richard Biener via Gcc-rust]

On Fri, Oct 28, 2022 at 1:45 PM Arthur Cohen  wrote:
>
> Hi David,
>
> On 10/26/22 23:15, David Malcolm wrote:
> > On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote:
> >> This is the fixed version of our previous patch set for gccrs - We've
> >> adressed
> >> the comments raised in our previous emails.
> >
> > [...snip...]
> >
> > (Caveat: I'm not a global reviewer)
> >
> > Sorry if this is answered in the docs in the patch kit, but a high-
> > level question: what's the interaction between gccrs and gcc's garbage
> > collector?  Are the only GC-managed objects (such as trees) either (a)
> > created near the end of the gccrs, or (b) common globals created at
> > initialization and with GTY roots?
>
> We only create trees at the last point of our compilation pipeline,
> before directly writing them to the backend. This then calls a
> `write_global_definitions` method, that we ported over directly from the
> Go frontend. Among other things, this method has the role of preserving
> trees from the GC using `go_preserve_from_gc()` (or
> `rust_preserve_from_gc()` in our case).
>
> Elsewhere in our pipeline, we never call any garbage-collection routines
> or GC-related functions.
>
> > Are there any points where a collection happen within gccrs?  Or is almost 
> > everything stored using
> > gccrs's own data structures, and are these managed in the regular (non-
> > GC) heap?
>
> This is correct. We have an AST representation, implemented using unique
> pointers, which is then lowered to an HIR, also using unique pointers.
>
> > I skimmed the patches and see that gccrs uses e.g. std::vector,
> > std::unique_ptr, std::map, and std::string; this seems reasonable to
> > me, but it got me thinking about memory management strategies.
> >
> > I see various std::map e.g. in Rust::Compile::Context; so e.g.
> > is the GC guaranteed never to collect whilst this is live?
>
> This is a really interesting question, and I hope the answer is yes! But
> I'm unsure as to how to enforce that, as I am not too familiar with the
> GCC GC. I'm hoping someone else will weigh in. As I said, we do not do
> anything particular with the GC during the execution of our
> `CompileCrate` visitor, so hopefully it shouldn't run.

collection points are explicit, but some might be hidden behind
middle-end APIs, in particular once you call cgraph::finalize_compilation_unit
you should probably expect collection.

Richard.

> > Hope this is constructive
> > Dave
> >
>
> Thanks a lot for the input,
>
> All the best,
>
> Arthur
>
>
>
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC lowering entry point

[Richard Biener via Gcc-rust]

On Wed, Oct 26, 2022 at 10:37 AM  wrote:
>
> From: Philip Herron 
>
> This patch contains the entry point and utilities used for the lowering
> of HIR nodes to `tree`s. It also contains a constant evaluator, ported
> over from the C++ frontend.
>
> Co-authored-by: David Faust 
> Co-authored-by: Faisal Abbas <90.abbasfai...@gmail.com>
> ---
>  gcc/rust/backend/rust-compile-context.cc | 146 
>  gcc/rust/backend/rust-compile-context.h  | 343 ++
>  gcc/rust/backend/rust-compile.cc | 414 +
>  gcc/rust/backend/rust-compile.h  |  47 +++
>  gcc/rust/backend/rust-constexpr.cc   | 441 +++
>  gcc/rust/backend/rust-constexpr.h|  31 ++
>  6 files changed, 1422 insertions(+)
>  create mode 100644 gcc/rust/backend/rust-compile-context.cc
>  create mode 100644 gcc/rust/backend/rust-compile-context.h
>  create mode 100644 gcc/rust/backend/rust-compile.cc
>  create mode 100644 gcc/rust/backend/rust-compile.h
>  create mode 100644 gcc/rust/backend/rust-constexpr.cc
>  create mode 100644 gcc/rust/backend/rust-constexpr.h
>
> diff --git a/gcc/rust/backend/rust-compile-context.cc 
> b/gcc/rust/backend/rust-compile-context.cc
> new file mode 100644
> index 000..cb2addf6c21
> --- /dev/null
> +++ b/gcc/rust/backend/rust-compile-context.cc
> @@ -0,0 +1,146 @@
> +// Copyright (C) 2020-2022 Free Software Foundation, Inc.
> +
> +// This file is part of GCC.
> +
> +// GCC is free software; you can redistribute it and/or modify it under
> +// the terms of the GNU General Public License as published by the Free
> +// Software Foundation; either version 3, or (at your option) any later
> +// version.
> +
> +// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> +// WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +// for more details.
> +
> +// You should have received a copy of the GNU General Public License
> +// along with GCC; see the file COPYING3.  If not see
> +// .
> +
> +#include "rust-compile-context.h"
> +#include "rust-compile-type.h"
> +
> +namespace Rust {
> +namespace Compile {
> +
> +Context::Context (::Backend *backend)
> +  : backend (backend), resolver (Resolver::Resolver::get ()),
> +tyctx (Resolver::TypeCheckContext::get ()),
> +mappings (Analysis::Mappings::get ()), mangler (Mangler ())
> +{
> +  setup_builtins ();
> +}
> +
> +void
> +Context::setup_builtins ()
> +{
> +  auto builtins = resolver->get_builtin_types ();
> +  for (auto it = builtins.begin (); it != builtins.end (); it++)
> +{
> +  HirId ref;
> +  bool ok = tyctx->lookup_type_by_node_id ((*it)->get_node_id (), &ref);
> +  rust_assert (ok);
> +
> +  TyTy::BaseType *lookup;
> +  ok = tyctx->lookup_type (ref, &lookup);
> +  rust_assert (ok);
> +
> +  TyTyResolveCompile::compile (this, lookup);
> +}
> +}
> +
> +hashval_t
> +Context::type_hasher (tree type)
> +{
> +  inchash::hash hstate;
> +
> +  hstate.add_int (TREE_CODE (type));
> +
> +  if (TYPE_NAME (type))
> +{
> +  hashval_t record_name_hash
> +   = IDENTIFIER_HASH_VALUE (DECL_NAME (TYPE_NAME (type)));
> +  hstate.add_object (record_name_hash);
> +}

The following does look a bit like type_hash_canon_hash.  I'll probably see what
we use tree type hashing for, just wondering here.

> +  for (tree t = TYPE_ATTRIBUTES (type); t; t = TREE_CHAIN (t))
> +/* Just the identifier is adequate to distinguish.  */
> +hstate.add_object (IDENTIFIER_HASH_VALUE (TREE_PURPOSE (t)));
> +
> +  switch (TREE_CODE (type))
> +{
> +case METHOD_TYPE:
> +  hstate.add_object (TYPE_HASH (TYPE_METHOD_BASETYPE (type)));
> +  /* FALLTHROUGH. */
> +case FUNCTION_TYPE:
> +  for (tree t = TYPE_ARG_TYPES (type); t; t = TREE_CHAIN (t))
> +   if (TREE_VALUE (t) != error_mark_node)
> + hstate.add_object (TYPE_HASH (TREE_VALUE (t)));
> +  break;
> +
> +case OFFSET_TYPE:
> +  hstate.add_object (TYPE_HASH (TYPE_OFFSET_BASETYPE (type)));
> +  break;
> +
> +  case ARRAY_TYPE: {

GCC coding conventions would say the { goes to the next line and indented.
The rust FE might intentionally diverge from that standard, if so a
pointer in some
README in rust/ would be helpful.

> +   if (TYPE_DOMAIN (type))
> + hstate.add_object (TYPE_HASH (TYPE_DOMAIN (type)));
> +   if (!AGGREGATE_TYPE_P (TREE_TYPE (type)))
> + {
> +   unsigned typeless = TYPE_TYPELESS_STORAGE (type);
> +   hstate.add_object (typeless);
> + }
> +  }
> +  break;
> +
> +  case INTEGER_TYPE: {
> +   tree t = TYPE_MAX_VALUE (type);
> +   if (!t)
> + t = TYPE_MIN_VALUE (type);
> +   for (int i = 0; i < TREE_INT_CST_NUNITS (t); i++)
> + hstate.add_object (TREE_INT_CST_ELT (t, i));
> +   break;
> +  }
> +
> +case REAL_TYPE:
> 

Re: Rust frontend patches v3

[Richard Biener via Gcc-rust]

On Wed, Oct 26, 2022 at 10:16 AM  wrote:
>
> This is the fixed version of our previous patch set for gccrs - We've adressed
> the comments raised in our previous emails.
>
> This patch set does not contain any work that was not previously included, 
> such
> as closure support, the constant evaluator port, or the better implementation
> of target hooks by Iain Buclaw. They will follow up in subsequent patch sets.
>
> Thanks again to Open Source Security, inc and Embecosm who have accompanied us
> for this work.
>
> Many thanks to all of the contributors and our community, who made this
> possible.
>
> A very special thanks to Philip Herron, without whose mentoring I would have
> never been in a position to send these patches.
>
> You can see the current status of our work on our branch:
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
>
> The patch set contains the following:

Can you mark the patches that have been reviewed/approved?  Can you
maybe either split the series or organize it in a way to separate the
pieces touching common parts of GCC from the gcc/rust/ parts?
Can you separate testsuite infrastructure from actual tests, can
you mark/separate target specific changes?  And for those (then small)
changes CC the appropriate maintainers?

Thanks,
Richard.

> [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char'
> [PATCH Rust front-end v3 02/46] gccrs: Add nessecary hooks for a Rust
> [PATCH Rust front-end v3 03/46] gccrs: Add Debug info testsuite
> [PATCH Rust front-end v3 04/46] gccrs: Add link cases testsuite
> [PATCH Rust front-end v3 05/46] gccrs: Add general compilation test
> [PATCH Rust front-end v3 06/46] gccrs: Add execution test cases
> [PATCH Rust front-end v3 07/46] gccrs: Add gcc-check-target
> [PATCH Rust front-end v3 08/46] gccrs: Add Rust front-end base AST
> [PATCH Rust front-end v3 09/46] gccrs: Add definitions of Rust Items
> [PATCH Rust front-end v3 10/46] gccrs: Add full definitions of Rust
> [PATCH Rust front-end v3 11/46] gccrs: Add Rust AST visitors
> [PATCH Rust front-end v3 12/46] gccrs: Add Lexer for Rust front-end
> [PATCH Rust front-end v3 13/46] gccrs: Add Parser for Rust front-end
> [PATCH Rust front-end v3 14/46] gccrs: Add Parser for Rust front-end
> [PATCH Rust front-end v3 15/46] gccrs: Add expansion pass for the
> [PATCH Rust front-end v3 16/46] gccrs: Add name resolution pass to
> [PATCH Rust front-end v3 17/46] gccrs: Add declarations for Rust HIR
> [PATCH Rust front-end v3 18/46] gccrs: Add HIR definitions and
> [PATCH Rust front-end v3 19/46] gccrs: Add AST to HIR lowering pass
> [PATCH Rust front-end v3 20/46] gccrs: Add wrapper for make_unique
> [PATCH Rust front-end v3 21/46] gccrs: Add port of FNV hash used
> [PATCH Rust front-end v3 22/46] gccrs: Add Rust ABI enum helpers
> [PATCH Rust front-end v3 23/46] gccrs: Add Base62 implementation
> [PATCH Rust front-end v3 24/46] gccrs: Add implementation of Optional
> [PATCH Rust front-end v3 25/46] gccrs: Add attributes checker
> [PATCH Rust front-end v3 26/46] gccrs: Add helpers mappings canonical
> [PATCH Rust front-end v3 27/46] gccrs: Add type resolution and trait
> [PATCH Rust front-end v3 28/46] gccrs: Add Rust type information
> [PATCH Rust front-end v3 29/46] gccrs: Add remaining type system
> [PATCH Rust front-end v3 30/46] gccrs: Add unsafe checks for Rust
> [PATCH Rust front-end v3 31/46] gccrs: Add const checker
> [PATCH Rust front-end v3 32/46] gccrs: Add privacy checks
> [PATCH Rust front-end v3 33/46] gccrs: Add dead code scan on HIR
> [PATCH Rust front-end v3 34/46] gccrs: Add unused variable scan
> [PATCH Rust front-end v3 35/46] gccrs: Add metadata ouptput pass
> [PATCH Rust front-end v3 36/46] gccrs: Add base for HIR to GCC
> [PATCH Rust front-end v3 37/46] gccrs: Add HIR to GCC GENERIC
> [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC
> [PATCH Rust front-end v3 39/46] gccrs: These are wrappers ported from
> [PATCH Rust front-end v3 40/46] gccrs: Add GCC Rust front-end
> [PATCH Rust front-end v3 41/46] gccrs: Add config-lang.in
> [PATCH Rust front-end v3 42/46] gccrs: Add lang-spec.h
> [PATCH Rust front-end v3 43/46] gccrs: Add lang.opt
> [PATCH Rust front-end v3 44/46] gccrs: Add compiler driver
> [PATCH Rust front-end v3 45/46] gccrs: Compiler proper interface
> [PATCH Rust front-end v3 46/46] gccrs: Add README, CONTRIBUTING and
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC lowering entry point

[Richard Biener via Gcc-rust]

On Tue, Nov 15, 2022 at 2:46 PM Arthur Cohen  wrote:
>
>
>
> On 11/9/22 14:53, Richard Biener wrote:
> > On Wed, Oct 26, 2022 at 10:37 AM  wrote:
> >>
> >> From: Philip Herron 
> >>
> >> This patch contains the entry point and utilities used for the lowering
> >> of HIR nodes to `tree`s. It also contains a constant evaluator, ported
> >> over from the C++ frontend.
> >>
> >> Co-authored-by: David Faust 
> >> Co-authored-by: Faisal Abbas <90.abbasfai...@gmail.com>
> >> ---
> >>   gcc/rust/backend/rust-compile-context.cc | 146 
> >>   gcc/rust/backend/rust-compile-context.h  | 343 ++
> >>   gcc/rust/backend/rust-compile.cc | 414 +
> >>   gcc/rust/backend/rust-compile.h  |  47 +++
> >>   gcc/rust/backend/rust-constexpr.cc   | 441 +++
> >>   gcc/rust/backend/rust-constexpr.h|  31 ++
> >>   6 files changed, 1422 insertions(+)
> >>   create mode 100644 gcc/rust/backend/rust-compile-context.cc
> >>   create mode 100644 gcc/rust/backend/rust-compile-context.h
> >>   create mode 100644 gcc/rust/backend/rust-compile.cc
> >>   create mode 100644 gcc/rust/backend/rust-compile.h
> >>   create mode 100644 gcc/rust/backend/rust-constexpr.cc
> >>   create mode 100644 gcc/rust/backend/rust-constexpr.h
> >>
> >> diff --git a/gcc/rust/backend/rust-compile-context.cc 
> >> b/gcc/rust/backend/rust-compile-context.cc
> >> new file mode 100644
> >> index 000..cb2addf6c21
> >> --- /dev/null
> >> +++ b/gcc/rust/backend/rust-compile-context.cc
> >> @@ -0,0 +1,146 @@
> >> +// Copyright (C) 2020-2022 Free Software Foundation, Inc.
> >> +
> >> +// This file is part of GCC.
> >> +
> >> +// GCC is free software; you can redistribute it and/or modify it under
> >> +// the terms of the GNU General Public License as published by the Free
> >> +// Software Foundation; either version 3, or (at your option) any later
> >> +// version.
> >> +
> >> +// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> >> +// WARRANTY; without even the implied warranty of MERCHANTABILITY or
> >> +// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> >> +// for more details.
> >> +
> >> +// You should have received a copy of the GNU General Public License
> >> +// along with GCC; see the file COPYING3.  If not see
> >> +// .
> >> +
> >> +#include "rust-compile-context.h"
> >> +#include "rust-compile-type.h"
> >> +
> >> +namespace Rust {
> >> +namespace Compile {
> >> +
> >> +Context::Context (::Backend *backend)
> >> +  : backend (backend), resolver (Resolver::Resolver::get ()),
> >> +tyctx (Resolver::TypeCheckContext::get ()),
> >> +mappings (Analysis::Mappings::get ()), mangler (Mangler ())
> >> +{
> >> +  setup_builtins ();
> >> +}
> >> +
> >> +void
> >> +Context::setup_builtins ()
> >> +{
> >> +  auto builtins = resolver->get_builtin_types ();
> >> +  for (auto it = builtins.begin (); it != builtins.end (); it++)
> >> +{
> >> +  HirId ref;
> >> +  bool ok = tyctx->lookup_type_by_node_id ((*it)->get_node_id (), 
> >> &ref);
> >> +  rust_assert (ok);
> >> +
> >> +  TyTy::BaseType *lookup;
> >> +  ok = tyctx->lookup_type (ref, &lookup);
> >> +  rust_assert (ok);
> >> +
> >> +  TyTyResolveCompile::compile (this, lookup);
> >> +}
> >> +}
> >> +
> >> +hashval_t
> >> +Context::type_hasher (tree type)
> >> +{
> >> +  inchash::hash hstate;
> >> +
> >> +  hstate.add_int (TREE_CODE (type));
> >> +
> >> +  if (TYPE_NAME (type))
> >> +{
> >> +  hashval_t record_name_hash
> >> +   = IDENTIFIER_HASH_VALUE (DECL_NAME (TYPE_NAME (type)));
> >> +  hstate.add_object (record_name_hash);
> >> +}
> >
> > The following does look a bit like type_hash_canon_hash.  I'll probably see 
> > what
> > we use tree type hashing for, just wondering here.
> >
> >> +  for (tree t = TYPE_ATTRIBUTES (type); t; t = TREE_CHAIN (t))
> >> +/* Just the identifier is adequate to distinguish.  */
> >> +hstate.add_object (IDENTIFIER_HASH_VALUE (TREE_PURPOSE (t)));
> >> +
> >> +  switch (TREE_CODE (type))
> >> +{
> >> +case METHOD_TYPE:
> >> +  hstate.add_object (TYPE_HASH (TYPE_METHOD_BASETYPE (type)));
> >> +  /* FALLTHROUGH. */
> >> +case FUNCTION_TYPE:
> >> +  for (tree t = TYPE_ARG_TYPES (type); t; t = TREE_CHAIN (t))
> >> +   if (TREE_VALUE (t) != error_mark_node)
> >> + hstate.add_object (TYPE_HASH (TREE_VALUE (t)));
> >> +  break;
> >> +
> >> +case OFFSET_TYPE:
> >> +  hstate.add_object (TYPE_HASH (TYPE_OFFSET_BASETYPE (type)));
> >> +  break;
> >> +
> >> +  case ARRAY_TYPE: {
> >
> > GCC coding conventions would say the { goes to the next line and indented.
> > The rust FE might intentionally diverge from that standard, if so a
> > pointer in some
> > README in rust/ would be helpful.
>
> This is not our intention. We would like to stick to the GCC coding
> convention, and use a `.clang-format` file 

Re: [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC lowering entry point

[Richard Biener via Gcc-rust]

On Tue, Nov 29, 2022 at 7:10 PM Arthur Cohen  wrote:
>
> Hi Richard,
>
> (...)
>
>  +
>  +  unsigned HOST_WIDE_INT ltype_length
>  += wi::ext (wi::to_offset (TYPE_MAX_VALUE (ltype_domain))
>  +- wi::to_offset (TYPE_MIN_VALUE (ltype_domain)) + 1,
> >>>
> >>> TYPE_MIN_VALUE is not checked to be constant, also the correct
> >>> check would be to use TREE_CODE (..) == INTEGER_CST, in
> >>> the GCC middle-end an expression '1 + 2' (a PLUS_EXPR) would
> >>> be TREE_CONSTANT but wi::to_offset would ICE.
> >>>
>  +  TYPE_PRECISION (TREE_TYPE (ltype_domain)),
>  +  TYPE_SIGN (TREE_TYPE (ltype_domain)))
>  +   .to_uhwi ();
> >>>
> >>> .to_uhwi will just truncate if the value doesn't fit, the same result as
> >>> above is achieved with
> >>>
> >>>unsigned HOST_WIDE_INT ltype_length
> >>>   = TREE_INT_CST_LOW (TYPE_MAX_VALUE (..))
> >>> - TREE_INT_CST_LOW (TYPE_MIN_VALUE (...)) + 1;
> >>>
> >>> so it appears you wanted to be "more correct" here (but if I see
> >>> correctly you fail on that attempt)?
> >>>
>
> I've made the changes you proposed and noticed failure on our 32-bit CI.
>
> I've had a look at the values in detail, and it seems that truncating
> was the expected behavior.
>
> On our 64 bit CI, with a testcase containing an array of zero elements,
> we get the following values:
>
> TREE_INT_CST_LOW(TYPE_MAX_VALUE(...)) = 18446744073709551615;
> TREE_INT_CST_LOW(TYPE_MIN_VALUE(...)) = 0;
>
> Adding 1 to the result of the substraction results in an overflow,
> wrapping back to zero.
>
> With the -m32 flag, we get the following values:
>
> TREE_INT_CST_LOW(TYPE_MAX_VALUE(...)) = 4294967295;
> TREE_INT_CST_LOW(TYPE_MIN_VALUE(...)) = 0;
>
> The addition of 1 does not overflow the unsigned HOST_WIDE_INT type and
> we end up with 4294967296 as the length of our array.
>
> I am not sure on how to fix this behavior, and whether or not it is the
> expected one, nor am I familiar enough with the tree API to reproduce
> the original behavior. Any input is welcome.
>
> In the meantime, I'll revert those changes and probably keep the
> existing code in the patches if that's okay with you.

Sure - take my comments as that the code needs comments explaining
what it tries to do.  Apparently I misunderstood the intent (and still don't
get it, but I don't remember the part in detail either).

> >>> Overall this part of the rust frontend looks OK.  Take the comments as
> >>> suggestions (for future
> >>> enhancements).
>
> Which seems to be the case :)
>
> The v4 of patches, which contains a lot of fixes for the issues you
> mentioned, will be sent soon.
>
> All the best,
>
> Arthur
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust front-end patches v4

[Richard Biener via Gcc-rust]

On Tue, Dec 6, 2022 at 11:11 AM  wrote:
>
> This patchset contains the fixed version of our most recent patchset. We
> have fixed most of the issues noted in the previous round of reviews, and are
> keeping some for later as they would otherwise create too many conflicts with
> our updated development branch.
>
> Similarly to the previous round of patches, this patchset does not contain any
> new features - only fixes for the reviews of the v3. New features will follow
> shortly once that first patchset is merged.
>
> Once again, thank you to all the contributors who made this possible and
> especially to Philip Herron for his dedication to the project.

Thanks a lot - this is OK to merge now, thanks for your patience and I'm
looking forward for the future improvements.

Thanks,
Richard.

> You can see the current status of our work on our branch:
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
>
> Patch status table:
>
> An 'x' in the first column indicates a patch has been reviewed.
> One in the second column indicates that a patch has been approved.
>
> |0001-Use-DW_ATE_UTF-for-the-Rust-char-type.patch   |x|x|
> |0002-gccrs-Add-necessary-hooks-for-a-Rust-front-end-tests.patch|x|x|
> |0003-gccrs-Add-Debug-info-testsuite.patch  | | |
> |0004-gccrs-Add-link-cases-testsuite.patch  | | |
> |0005-gccrs-Add-general-compilation-test-cases.patch| | |
> |0006-gccrs-Add-execution-test-cases.patch  | | |
> |0007-gccrs-Add-gcc-check-target-check-rust.patch   |x| |
> |0008-gccrs-Add-Rust-front-end-base-AST-data-structures.patch   | | |
> |0009-gccrs-Add-definitions-of-Rust-Items-in-AST-data-stru.patch| | |
> |0010-gccrs-Add-full-definitions-of-Rust-AST-data-structur.patch| | |
> |0011-gccrs-Add-Rust-AST-visitors.patch | | |
> |0012-gccrs-Add-Lexer-for-Rust-front-end.patch  |x| |
> |0013-gccrs-Add-Parser-for-Rust-front-end-pt.1.patch| | |
> |0014-gccrs-Add-Parser-for-Rust-front-end-pt.2.patch| | |
> |0015-gccrs-Add-expansion-pass-for-the-Rust-front-end.patch | | |
> |0016-gccrs-Add-name-resolution-pass-to-the-Rust-front-end.patch| | |
> |0017-gccrs-Add-declarations-for-Rust-HIR.patch | | |
> |0018-gccrs-Add-HIR-definitions-and-visitor-framework.patch | | |
> |0019-gccrs-Add-AST-to-HIR-lowering-pass.patch  | | |
> |0020-gccrs-Add-wrapper-for-make_unique.patch   | | |
> |0021-gccrs-Add-port-of-FNV-hash-used-during-legacy-symbol.patch| | |
> |0022-gccrs-Add-Rust-ABI-enum-helpers.patch | | |
> |0023-gccrs-Add-Base62-implementation.patch | | |
> |0024-gccrs-Add-implementation-of-Optional.patch| | |
> |0025-gccrs-Add-attributes-checker.patch| | |
> |0026-gccrs-Add-helpers-mappings-canonical-path-and-lang-i.patch| | |
> |0027-gccrs-Add-type-resolution-and-trait-solving-pass.patch| | |
> |0028-gccrs-Add-Rust-type-information.patch | | |
> |0029-gccrs-Add-remaining-type-system-transformations.patch | | |
> |0030-gccrs-Add-unsafe-checks-for-Rust.patch| | |
> |0031-gccrs-Add-const-checker.patch | | |
> |0032-gccrs-Add-privacy-checks.patch| | |
> |0033-gccrs-Add-dead-code-scan-on-HIR.patch | | |
> |0034-gccrs-Add-unused-variable-scan.patch  | | |
> |0035-gccrs-Add-metadata-output-pass.patch  | | |
> |0036-gccrs-Add-base-for-HIR-to-GCC-GENERIC-lowering.patch  | | |
> |0037-gccrs-Add-HIR-to-GCC-GENERIC-lowering-for-all-nodes.patch |x|x|
> |0038-gccrs-Add-HIR-to-GCC-GENERIC-lowering-entry-point.patch   |x|x|
> |0039-gccrs-These-are-wrappers-ported-from-reusing-gccgo.patch  | | |
> |0040-gccrs-Add-GCC-Rust-front-end-Make-lang.in.patch   |x| |
> |0041-gccrs-Add-config-lang.in.patch|x|x|
> |0042-gccrs-Add-lang-spec.h.patch   | | |
> |0043-gccrs-Add-lang.opt.patch  |x| |
> |0044-gccrs-Add-compiler-driver.patch   | | |
> |0045-gccrs-Compiler-proper-interface-kicks-off-the-pipeli.patch| | |
> |0046-gccrs-Add-README-CONTRIBUTING-and-compiler-logo.patch | | |
>
> Patches 34 to 39 and 44 to 45 interact with common GCC APIs:
>
> 0034-gccrs-Add-unused-variable-scan.patch
> 0035-gccrs-Add-metadata-output-pass.patch
> 0036-gccrs-Add-base-for-HIR-to-GCC-GENERIC-lowering.patch
> 0037-gccrs-Add-HIR-to-GCC-GENERIC-lowering-for-all-nodes.patch
> 0038-gccrs-Add-HIR-to-GCC-GENERIC-lowering-entry-point.patch
> 0039-gccrs-These-are-wrappers-ported-from-reusing-gccgo.patch
> 0044-gccrs-Add-compiler-driver.patch
> 0045-gccrs-Compiler-proper-interface-kicks-off-the-pipeli.patch
>
> Patch 02 and 07 contain test infrastructure changes:
>
> 0002-gccrs-A

Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)

[Richard Biener via Gcc-rust]

On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
 wrote:
>
> Hi!
>
> On 2022-12-13T14:40:36+0100, Arthur Cohen  wrote:
> > We've also added one more commit, which only affects files inside the
> > Rust front-end folder. This commit adds an experimental flag, which
> > blocks the compilation of Rust code when not used.
>
> (That's commit r13-4675-gb07ef39ffbf4e77a586605019c64e2e070915ac3
> "gccrs: Add fatal_error when experimental flag is not present".)
>
> I noticed that GCC/Rust recently lost all LTO variants in torture
> testing -- due to this commit.  :-O
>
> OK to push the attached
> "Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' 
> option",
> or should this be done differently?

Just add 'LTO' to the option in lang.opt, like

frust-incomplete-and-experimental-compiler-do-not-use
Rust LTO Var(flag_rust_experimental)
Enable experimental compilation of Rust files at your own risk


>
> With that, we get back:
>
>  PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O0  (test 
> for excess errors)
>  PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O1  (test 
> for excess errors)
>  PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2  (test 
> for excess errors)
> +PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
> +PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
>  PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O3 -g  
> (test for excess errors)
>  PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -Os  (test 
> for excess errors)
>
> Etc., and in total:
>
> === rust Summary for unix ===
>
> # of expected passes[-4990-]{+6718+}
> # of expected failures  [-39-]{+51+}
>
>
> Grüße
>  Thomas
>
>
> > We hope this helps
> > indicate to users that the compiler is not yet ready, but can still be
> > experimented with :)
> >
> > We plan on removing that flag as soon as possible, but in the meantime,
> > we think it will help not creating divide within the Rust ecosystem, as
> > well as not waste Rust crate maintainers' time.
>
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] testsuite: Add support for Rust and Modula-2 effective target tests

[Richard Biener via Gcc-rust]

On Thu, 15 Dec 2022, Jakub Jelinek wrote:

> Hi!
> 
> This patch allows magic comments also for Rust and Modula-2
> for effective target tests etc. and fixes up the Assembly entry
> - it is a glob, so /* Assembly can match /whatever Assembly and
> not just /* Assembly.
> 
> Tested on x86_64-linux with
> make check-g++ RUNTESTFLAGS=i386.exp=pr35513*
> and verifying it still uses *.S extension for the property_1_needed
> effective target test.
> 
> Ok for trunk?

OK.

Thanks,
Richard.

> 2022-12-15  Jakub Jelinek  
> 
>   * lib/target-supports.exp (check_compile): Add support for
>   Rust and Modula-2.  Use \* rather than * for /* comment for
>   Assembly.
> 
> --- gcc/testsuite/lib/target-supports.exp.jj  2022-11-30 10:29:42.217698938 
> +0100
> +++ gcc/testsuite/lib/target-supports.exp 2022-12-15 13:08:47.941221943 
> +0100
> @@ -36,7 +36,9 @@
>  # "! Fortran" for Fortran code,
>  # "/* ObjC", for ObjC
>  # "// ObjC++" for ObjC++
> -# and "// Go" for Go
> +# "// Go" for Go
> +# "// Rust" for Rust
> +# and "(* Modula-2" for Modula-2
>  # If the tool is ObjC/ObjC++ then we overide the extension to .m/.mm to 
>  # allow for ObjC/ObjC++ specific flags.
>  
> @@ -58,13 +60,15 @@ proc check_compile {basename type conten
>   set options ""
>  }
>  switch -glob -- $contents {
> - "*/* Assembly*" { set src ${basename}[pid].S }
> + "*/\* Assembly*" { set src ${basename}[pid].S }
>   "*! Fortran*" { set src ${basename}[pid].f90 }
>   "*// C++*" { set src ${basename}[pid].cc }
>   "*// D*" { set src ${basename}[pid].d }
>   "*// ObjC++*" { set src ${basename}[pid].mm }
>   "*/* ObjC*" { set src ${basename}[pid].m }
>   "*// Go*" { set src ${basename}[pid].go }
> + "*// Rust*" { set src ${basename}[pid].rs }
> + "*(\* Modula-2*" { set src ${basename}[pid].mod }
>   default {
>   switch -- $tool {
>   "objc" { set src ${basename}[pid].m }
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

[Richard Biener via Gcc-rust]

On Wed, 22 Feb 2023, Thomas Schwinge wrote:

> Hi!
> 
> Richard, you may remember your words from 
> "ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O 
> -fno-tree-scev-cprop -ftree-vectorize":
> 
> > Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the
> > middle-end but had a pure middle-end based implementation.
> 
> Is there a canonical PR or other discussion thread for that?

No, not that I'm aware of.

Richard.

> Here's another instance of this issue:
> 
> On 2022-12-19T22:23:45+0100, Jan-Benedict Glaw  wrote:
> > With the recent merges for Modula-2 and Rust, I see a good number of
> > targets failing with --enable-languages=all, mostly due to issues with
> > the Modula-2 driver.
> 
> Thanks for reporting.
> 
> >  Modula-2 related issues
> > [snipped]
> 
> >  Rust related issues
> > =
> >
> >  --target=msp430-elfbare
> > ~
> >   /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc 
> > -B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/  -xrust 
> > -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null 
> > -S -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
> >   : internal compiler error: Segmentation fault
> >   0xf2efbf crash_signal
> > ../../gcc/gcc/toplev.cc:314
> >   0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
> > ../../gcc/gcc/tree.cc:7360
> >   0x120cc20 build_function_type_list(tree_node*, ...)
> > ../../gcc/gcc/tree.cc:7442
> >   0x120d16b build_common_builtin_nodes()
> > ../../gcc/gcc/tree.cc:9883
> >   0x8449b4 grs_langhook_init
> > ../../gcc/gcc/rust/rust-lang.cc:132
> >   0x8427b2 lang_dependent_init
> > ../../gcc/gcc/toplev.cc:1815
> >   0x8427b2 do_compile
> > ../../gcc/gcc/toplev.cc:2110
> >   Please submit a full bug report, with preprocessed source (by using 
> > -freport-bug).
> >   Please include the complete backtrace with any bug report.
> >   See  for instructions.
> >   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
> > Error 1
> 
> See also 
> "Test failure on msp430-elfbare target".
> 
> I confirm with both upstream GCC master branch and GCC/Rust master
> branch:
> 
> $ ../source-gcc/configure --target=msp430-elfbare --enable-languages=rust 
> [...]
> $ make all-gcc [...]
> [...]
> [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xc -nostdinc 
> /dev/null -S -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
> -fself-test: 57323 pass(es) in 0.42 seconds
> echo timestamp > s-selftest-c
> [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xrust 
> -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
> -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
> : internal compiler error: Segmentation fault
> 0xf51b9f crash_signal
> ../../source-gcc/gcc/toplev.cc:314
> 0x12e6a3a build_function_type(tree_node*, tree_node*, bool)
> ../../source-gcc/gcc/tree.cc:7447
> 0x12e6ee0 build_function_type_list(tree_node*, ...)
> ../../source-gcc/gcc/tree.cc:7529
> 0x12e748e build_common_builtin_nodes()
> ../../source-gcc/gcc/tree.cc:9977
> 0x7661c4 grs_langhook_init
> ../../source-gcc/gcc/rust/rust-lang.cc:128
> 0x762ac9 lang_dependent_init
> ../../source-gcc/gcc/toplev.cc:1815
> 0x762ac9 do_compile
> ../../source-gcc/gcc/toplev.cc:2110
> Please submit a full bug report, with preprocessed source (by using 
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[1]: *** [s-selftest-rust] Error 1
> [...]
> 
> OK to push the attached
> "Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types"?
> 
> 
> Grüße
>  Thomas
> 
> 
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust front-end update 2023-04-05

[Richard Biener via Gcc-rust]

On Wed, Apr 5, 2023 at 4:06 PM  wrote:
>
> Hi everyone,
>
> This patchset contains around 80 commits concerning the Rust frontend.
>
> We have been hard at work trying to get the Rust core library to
> compile, and hope to push more commits in the coming days as we try
> and upstream a more recent version of gccrs. All of the team has done
> a tremendous amount of work in the last few weeks, as we get closer
> and closer to compiling libcore 1.49.
>
> Our focus before GCC 13 releases is to improve the documentation of the
> compiler and write more about the various flags used by the frontend,
> which a user will need to understand and interact with.
>
> The commits we will be pushing before GCC 13 releases will not contain
> any "major breakthrough", as some functionality required to compile
> libcore properly will still take some time to implement. Very often used
> Rust macros such as `format_args` are defined within the core library,
> and require a high amount of work on the compiler side.
>
> Furthermore, integrating libcore as part of GCC will require
> significant build system changes which are incompatible with the current
> GCC stage. We will be making these changes as soon as possible and
> integrate a version of libcore in GCC 14, as well as an implementation
> of the libproc_macro crate. We will be submitting these patches and
> pinging build system experts for extensive reviewing.
>
> Thank you to everyone involved with the project, and to everyone who
> has helped us.

Thanks a lot for the update.  I see it's still required to use
-frust-incomplete-and-experimental-compiler-do-not-use - for GCC 13.1
I would suggest to instead discourage from distributing rust in the
documentation
and release notes.

Do you expect enough progress until GCC 13.2 (which should be about
two to three months after GCC 13.1 is released) so that libcore can be compiled?
If not then I'm not sure it makes much sense to keep rust configurable
for GCC 13.

On the general note - were you planning to keep the GCC 13 branch copy of rust
up-to-date with the GCC 14 trunk?

Richard.

> All the best,
>
> Arthur
>
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCHSET] Reintroduce targetrustm hooks

[Richard Biener via Gcc-rust]

On Wed, Sep 13, 2023 at 10:14 PM Iain Buclaw via Gcc-patches
 wrote:
>
> Excerpts from Arthur Cohen's message of September 7, 2023 3:41 pm:
> > Alright, was not expecting to mess up this patchset so bad so here we go:
> >
> > This patchset reintroduces proper targetrustm hooks without the old
> > problematic mess of macros we had, which had been removed for the first
> > merge of gccrs upstream.
> >
> > Tested on x86-64 GNU Linux, and has also been present in our development
> > repository for a long time - added by this pull-request from Iain [1]
> > which was merged in October 2022.
> >
> > Ok for trunk?
> >
> > [PATCH 01/14] rust: Add skeleton support and documentation for
> > [PATCH 02/14] rust: Reintroduce TARGET_RUST_CPU_INFO hook
> > [PATCH 03/14] rust: Reintroduce TARGET_RUST_OS_INFO hook
> > [PATCH 04/14] rust: Implement TARGET_RUST_CPU_INFO for i[34567]86-*-*
> > [PATCH 05/14] rust: Implement TARGET_RUST_OS_INFO for *-*-darwin*
> > [PATCH 06/14] rust: Implement TARGET_RUST_OS_INFO for *-*-freebsd*
> > [PATCH 07/14] rust: Implement TARGET_RUST_OS_INFO for *-*-netbsd*
> > [PATCH 08/14] rust: Implement TARGET_RUST_OS_INFO for *-*-openbsd*
> > [PATCH 09/14] rust: Implement TARGET_RUST_OS_INFO for *-*-solaris2*.
> > [PATCH 10/14] rust: Implement TARGET_RUST_OS_INFO for *-*-dragonfly*
> > [PATCH 11/14] rust: Implement TARGET_RUST_OS_INFO for *-*-vxworks*
> > [PATCH 12/14] rust: Implement TARGET_RUST_OS_INFO for *-*-fuchsia*.
> > [PATCH 13/14] rust: Implement TARGET_RUST_OS_INFO for
> > [PATCH 14/14] rust: Implement TARGET_RUST_OS_INFO for *-*-*linux*.
> >
>
> Thanks for eventually getting round to this.
>
> As the co-author of this patch series, I'm not going to look at it.
>
> FWIW, these being Rust-specific target changes isolated to just
> Rust-specific files, you should have the automony to commit without
> needing any request for review - at least this is my understanding when
> have made D-specific target changes in the past that have not touched
> common back-end headers.
>
> I'll let someone else confirm and check over the shared parts touched by
> the patch however.

I confirm.  I briefly went over the shared parts and they look OK.

Thanks,
Richard.

> For reviewers, this is pretty much a mirror of the D front-end's CPU and
> OS-specific target hooks (D has built-in version identifiers, not
> built-in attributes, but both Rust and D are otherwise the same in the
> kind of information exposed by them).
>
> > [1]: https://github.com/Rust-GCC/gccrs/pull/1543
> >
>
> The other GitHub pull request that added these is here.
>
> https://github.com/Rust-GCC/gccrs/pull/1596
>
> Regards,
> Iain.
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH 1/3] librust: Add libproc_macro and build system

[Richard Biener via Gcc-rust]

On Wed, Sep 20, 2023 at 2:04 PM Arthur Cohen  wrote:
>
> From: Pierre-Emmanuel Patry 
>
> This patch series adds the build system changes to allow the Rust
> frontend to develop and distribute its own libraries. The first library
> we have been working on is the `proc_macro` library, comprised of a C++
> library as well as a user-facing Rust library.
>
> Follow up commits containing the actual library code will be committed.
> Should I submit patches to the MAINTAINERS file to allow Philip and I to
> commit to this folder without first approval?

I think the Rust language frontend maintainership implicitly includes
the rust runtime libraries.

> This first commit adds a simple `libgrust` folder with on top of which the
> full library will be built.

OK.

> All the best,
>
> Arthur
>
> -
>
> Add some dummy files in libproc_macro along with it's build system.
>
> ChangeLog:
>
> * libgrust/Makefile.am: New file.
> * libgrust/configure.ac: New file.
> * libgrust/libproc_macro/Makefile.am: New file.
> * libgrust/libproc_macro/proc_macro.cc: New file.
> * libgrust/libproc_macro/proc_macro.h: New file.
>
> Signed-off-by: Pierre-Emmanuel Patry 
> ---
>  libgrust/Makefile.am |  68 
>  libgrust/configure.ac| 113 +++
>  libgrust/libproc_macro/Makefile.am   |  58 ++
>  libgrust/libproc_macro/proc_macro.cc |   7 ++
>  libgrust/libproc_macro/proc_macro.h  |   7 ++
>  5 files changed, 253 insertions(+)
>  create mode 100644 libgrust/Makefile.am
>  create mode 100644 libgrust/configure.ac
>  create mode 100644 libgrust/libproc_macro/Makefile.am
>  create mode 100644 libgrust/libproc_macro/proc_macro.cc
>  create mode 100644 libgrust/libproc_macro/proc_macro.h
>
> diff --git a/libgrust/Makefile.am b/libgrust/Makefile.am
> new file mode 100644
> index 000..8e5274922c5
> --- /dev/null
> +++ b/libgrust/Makefile.am
> @@ -0,0 +1,68 @@
> +AUTOMAKE_OPTIONS = 1.8 foreign
> +
> +SUFFIXES = .c .rs .def .o .lo .a
> +
> +ACLOCAL_AMFLAGS = -I . -I .. -I ../config
> +
> +AM_CFLAGS = -I $(srcdir)/../libgcc -I $(MULTIBUILDTOP)../../gcc/include
> +
> +TOP_GCCDIR := $(shell cd $(top_srcdir) && cd .. && pwd)
> +
> +GCC_DIR = $(TOP_GCCDIR)/gcc
> +RUST_SRC = $(GCC_DIR)/rust
> +
> +toolexeclibdir=@toolexeclibdir@
> +toolexecdir=@toolexecdir@
> +
> +SUBDIRS = libproc_macro
> +
> +RUST_BUILDDIR := $(shell pwd)
> +
> +# Work around what appears to be a GNU make bug handling MAKEFLAGS
> +# values defined in terms of make variables, as is the case for CC and
> +# friends when we are called from the top level Makefile.
> +AM_MAKEFLAGS = \
> +"GCC_DIR=$(GCC_DIR)" \
> +"RUST_SRC=$(RUST_SRC)" \
> +   "AR_FLAGS=$(AR_FLAGS)" \
> +   "CC_FOR_BUILD=$(CC_FOR_BUILD)" \
> +   "CC_FOR_TARGET=$(CC_FOR_TARGET)" \
> +   "RUST_FOR_TARGET=$(RUST_FOR_TARGET)" \
> +   "CFLAGS=$(CFLAGS)" \
> +   "CXXFLAGS=$(CXXFLAGS)" \
> +   "CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)" \
> +   "CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)" \
> +   "INSTALL=$(INSTALL)" \
> +   "INSTALL_DATA=$(INSTALL_DATA)" \
> +   "INSTALL_PROGRAM=$(INSTALL_PROGRAM)" \
> +   "INSTALL_SCRIPT=$(INSTALL_SCRIPT)" \
> +   "LDFLAGS=$(LDFLAGS)" \
> +   "LIBCFLAGS=$(LIBCFLAGS)" \
> +   "LIBCFLAGS_FOR_TARGET=$(LIBCFLAGS_FOR_TARGET)" \
> +   "MAKE=$(MAKE)" \
> +   "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" \
> +   "PICFLAG=$(PICFLAG)" \
> +   "PICFLAG_FOR_TARGET=$(PICFLAG_FOR_TARGET)" \
> +   "SHELL=$(SHELL)" \
> +   "RUNTESTFLAGS=$(RUNTESTFLAGS)" \
> +   "exec_prefix=$(exec_prefix)" \
> +   "infodir=$(infodir)" \
> +   "libdir=$(libdir)" \
> +   "includedir=$(includedir)" \
> +   "prefix=$(prefix)" \
> +   "tooldir=$(tooldir)" \
> +   "gxx_include_dir=$(gxx_include_dir)" \
> +   "AR=$(AR)" \
> +   "AS=$(AS)" \
> +   "LD=$(LD)" \
> +   "RANLIB=$(RANLIB)" \
> +   "NM=$(NM)" \
> +   "NM_FOR_BUILD=$(NM_FOR_BUILD)" \
> +   "NM_FOR_TARGET=$(NM_FOR_TARGET)" \
> +   "DESTDIR=$(DESTDIR)" \
> +   "WERROR=$(WERROR)" \
> +"TARGET_LIB_PATH=$(TARGET_LIB_PATH)" \
> +"TARGET_LIB_PATH_librust=$(TARGET_LIB_PATH_librust)" \
> +   "LIBTOOL=$(RUST_BUILDDIR)/libtool"
> +
> +include $(top_srcdir)/../multilib.am
> diff --git a/libgrust/configure.ac b/libgrust/configure.ac
> new file mode 100644
> index 000..7aed489a643
> --- /dev/null
> +++ b/libgrust/configure.ac
> @@ -0,0 +1,113 @@
> +AC_INIT([libgrust], version-unused,,librust)
> +AC_CONFIG_SRCDIR(Makefile.am)
> +AC_CONFIG_FILES([Makefile])
> +
> +# AM_ENABLE_MULTILIB(, ..)
> +
> +# Do not delete or change the following two lines.  For why, see
> +# http://gcc.gnu.org/ml/libstdc++/2003-07/msg00451.html
> +AC_CANONICAL_SYSTEM
> +target_alias=${target_alias-$host_alias}
> +AC_SUBST(target_alias)
> +
> +# Automake should never attempt to rebuild configure
> +AM_MAINTAINER_MODE

Re: [PATCH 2/3] build: Add libgrust as compilation modules

[Richard Biener via Gcc-rust]

On Wed, Sep 20, 2023 at 2:04 PM Arthur Cohen  wrote:
>
> From: Pierre-Emmanuel Patry 
>
> Define the libgrust directory as a host compilation module as well as
> for targets.

OK if you tested this doesn't break build when rust is enabled on trunk
(and doesn't build libgrust if not).

Richard.

> ChangeLog:
>
> * Makefile.def: Add libgrust as host & target module.
> * configure.ac: Add libgrust to host tools list.
>
> gcc/rust/ChangeLog:
>
> * config-lang.in: Add libgrust as a target module for the rust
> language.
>
> Signed-off-by: Pierre-Emmanuel Patry 
> ---
>  Makefile.def| 2 ++
>  configure.ac| 3 ++-
>  gcc/rust/config-lang.in | 2 ++
>  3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.def b/Makefile.def
> index 870150183b9..3df3fc18d14 100644
> --- a/Makefile.def
> +++ b/Makefile.def
> @@ -149,6 +149,7 @@ host_modules= { module= libcc1; 
> extra_configure_flags=--enable-shared; };
>  host_modules= { module= gotools; };
>  host_modules= { module= libctf; bootstrap=true; };
>  host_modules= { module= libsframe; bootstrap=true; };
> +host_modules= { module= libgrust; };
>
>  target_modules = { module= libstdc++-v3;
>bootstrap=true;
> @@ -192,6 +193,7 @@ target_modules = { module= libgm2; lib_path=.libs; };
>  target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
>  target_modules = { module= libitm; lib_path=.libs; };
>  target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };
> +target_modules = { module= libgrust; };
>
>  // These are (some of) the make targets to be done in each subdirectory.
>  // Not all; these are the ones which don't have special options.
> diff --git a/configure.ac b/configure.ac
> index 1d16530140a..036e5945905 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -133,7 +133,7 @@ build_tools="build-texinfo build-flex build-bison 
> build-m4 build-fixincludes"
>
>  # these libraries are used by various programs built for the host environment
>  #f
> -host_libs="intl libiberty opcodes bfd readline tcl tk itcl libgui zlib 
> libbacktrace libcpp libcody libdecnumber gmp mpfr mpc isl libiconv libctf 
> libsframe"
> +host_libs="intl libiberty opcodes bfd readline tcl tk itcl libgui zlib 
> libbacktrace libcpp libcody libdecnumber gmp mpfr mpc isl libiconv libctf 
> libsframe libgrust "
>
>  # these tools are built for the host environment
>  # Note, the powerpc-eabi build depends on sim occurring before gdb in order 
> to
> @@ -164,6 +164,7 @@ target_libraries="target-libgcc \
> target-libada \
> target-libgm2 \
> target-libgo \
> +   target-libgrust \
> target-libphobos \
> target-zlib"
>
> diff --git a/gcc/rust/config-lang.in b/gcc/rust/config-lang.in
> index aac66c9b962..8f071dcb0bf 100644
> --- a/gcc/rust/config-lang.in
> +++ b/gcc/rust/config-lang.in
> @@ -29,4 +29,6 @@ compilers="rust1\$(exeext)"
>
>  build_by_default="no"
>
> +target_libs="target-libffi target-libbacktrace target-libgrust"
> +
>  gtfiles="\$(srcdir)/rust/rust-lang.cc"
> --
> 2.42.0
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust