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

2022-10-14 Thread Iain Buclaw via Gcc-rust
Excerpts from herron.phi...@googlemail.com's message of August 24, 2022 1:59 pm:
> From: Philip Herron 
> 
> This specifies the extensions of the Rust language.
> ---
>  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",

I've just noticed that you named the spec language "rs", I think you
mean to name it "@rust" instead.

Regards,
Iain.
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust


Re: Rust front-end patches v4

2022-12-06 Thread Iain Buclaw via Gcc-rust
Excerpts from Richard Biener via Gcc-patches's message of Dezember 6, 2022 
12:03 pm:
> 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.
> 

Finally! Some competition. :-)

Don't feel any pressure, and reach out if you ever need any guidance.

All the best.

Iain.
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust


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

2022-12-15 Thread Iain Buclaw via Gcc-rust
Excerpts from Jakub Jelinek via Gcc-patches's message of Dezember 15, 2022 
12:16 pm:
> We seem to have a problem in other testsuites too:
> grep ' valid for .*but not for' */*.log | sort -u
> gcc/gcc.log:/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pragma-diag-6.c:2:30: 
> warning: option '-Wnoexcept' is valid for C++/ObjC++ but not for C [-Wpragmas]
> gdc/gdc.log:cc1plus: warning: command-line option '-fextern-std=c++11' is 
> valid for D but not for C++
> gdc/gdc.log:cc1plus: warning: command-line option '-fpreview=in' is valid for 
> D but not for C++
> gfortran/gfortran.log:cc1: warning: command-line option '-fcheck=all' is 
> valid for Fortran but not for C
> g++/g++.log:cc1: warning: command-line option '-nostdinc++' is valid for 
> C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++11' is valid for 
> C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++14' is valid for 
> C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++17' is valid for 
> C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++20' is valid for 
> C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++23' is valid for 
> C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++98' is valid for 
> C++/ObjC++ but not for C
> rust/rust.log:cc1plus: warning: command-line option 
> '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust 
> but not for C++
> rust/rust.log:cc1: warning: command-line option 
> '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust 
> but not for C
> (of course, some of them could be from tests that this valid for but not for
> messages work right, that is clearly the case of pragma-diag-6.c).
> 
> In gcc/testsuite/lib/target-supports.exp (check_compile) we already
> determine extension for the check_compile snippet based on magic comments
> with default to .c (Rust nor Modula 2 don't have any, should that be
> changed?), shouldn't we at that point based on the language filter out
> known options that will not work?
> 
> So, given the above, at least when in gdc testsuite and language is
> not D filter out -fextern-std=* and -fpreview=in, for gfortran testsuite
> and language not Fortran filter out -fcheck=all, when in g++ testsuite and
> language is not C++ filter out -nostdinc++, -std=gnu++* and when
> in rust testsuite and language is not Rust filter out
> -frust-incomplete-and-experimental-compiler-do-not-use ?
> 

For the gdc testsuite, those warnings arise because both language files
are compiled in the same invocation (dg-additional-sources "cpp11.cpp"),
so it ends up looking something like:

gdc -fextern-std=c++11 testcpp11.d cpp11.cpp -o testcpp11.exe

So ruling out some sort of filtering done by the gdc driver when
delegating calls to the C/C++/D language compilers, is there a way to
get dejagnu to compile dg-additional-sources one-at-a-time?

Iain.
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust


Re: Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere (was: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' opt

2022-12-16 Thread Iain Buclaw via Gcc-rust
Excerpts from Thomas Schwinge's message of Dezember 16, 2022 3:10 pm:
> 
> In the test suites, a number of existing test cases explicitly match the
> "command-line option [...] is valid for [...] but not for [...]"
> diagnostic with 'dg-warning'; I've left those alone.  On the other hand,
> I've changed 'dg-prune-output' of this diagnostic into
> '-Wno-complain-wrong-lang' usage.  I'm happy to adjust that in either way
> anyone may prefer.  I've not looked for test cases that just to silence
> this diagnostic use more general 'dg-prune-output', 'dg-excess-errors',
> '-w', etc.
> 
> In the GCC/D test suite, I see a number of:
> 
> cc1plus: warning: command-line option '-fpreview=in' is valid for D but 
> not for C++
> 
> cc1plus: warning: command-line option '-fextern-std=c++11' is valid for D 
> but not for C++
> 
> It's not clear to me how they, despite this, do achieve
> 'PASS: [...] (test for excess errors)'?  Maybe I haven't found where that
> gets pruned/ignored?
> 

There's an implicit dg-prune-output inserted by the gdc-convert-test
proc. As the only tests that mix C++ and D sources is the runnable_cxx
part of the testsuite, I can add the flag to the D2 testsuite scripts
later just for those tests.

Iain.
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust


Re: [PATCHSET] Reintroduce targetrustm hooks

2023-09-13 Thread Iain Buclaw via Gcc-rust
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.

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