Re: New contributor tasks

[Thomas Schwinge]

Hi!

On 2021-07-13T00:44:13+0200, Mark Wielaard  wrote:
> On Mon, Jul 12, 2021 at 11:06:01AM +0100, Philip Herron wrote:
>> The main one that sticks out in my mind is the AST, HIR dumps which are
>> a bit of a mess at the moment.
>
> The AST dump (--rust-dump-parse) was actually useful for checking the
> comment doc strings, but it could certainly be improved. Ideally it
> would be structured in a way that can easily be used in tests.

Right.  Already a while ago, I had run into the same (for a lexer-level
thing), and have early-stages WIP changes to implement dumps for the
several GCC/Rust front end stages using the (more or less) standard
'-fdump-lang-[...]' flag.  These dump files may then be scanned using the
usual GCC/DejaGnu testsuite idioms.  I plan to complete that work at some
later point in time, hopefully not too far out.  (Mark, I then actually
had planned to add some testcases fore your recent lexer changes.)

(My work there is independent of/orthogonal to the S-expression dump
format discussed elsewhere.)


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

[Thomas Schwinge]

Hi!

On 2021-07-29T12:55:38+0200, Mark Wielaard  wrote:
> On Thu, 2021-07-29 at 09:25 +0800, The Other via Gcc-rust wrote:
>> I think the core idea of this patch (fixing locations) is very
>> important and useful.

Agreed.

>> But isn’t it overkill to pass the token in instead of just the
>> location? You can avoid a fairly expensive shared_ptr copy by doing
>> so.
>
> I hadn't even noticed it was a smart pointer. At least the abstraction
> works transparently.

Wouldn't 'const_TokenPtr &pratt_parsed_token' work, passing a C++
reference?  (Or am I missing some C++ "detail"; I haven't looked
carefully.)

> My idea was that the code might want to double
> check/assert it was the correct token (as it does in the case the
> parser function is called directly and it has to consume the first
> token itself).

That also makes sense to me.  (Defensive programming; verify input data
to be what you expect to see.)


Grüße
 Thomas


> But yes, things might be even simpler by passing the location directly.
> I'll try to rewrite the code tonight to pass a location and see how
> that looks.
>
> Thanks,
>
> Mark
> --
> Gcc-rust mailing list
> Gcc-rust@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/gcc-rust
-
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 2/2] WIP union hir-lowering and type support

[Thomas Schwinge]

Hi!

On 2021-08-02T00:37:37+0200, Mark Wielaard  wrote:
> On Sun, Aug 01, 2021 at 01:29:16PM +0200, Mark Wielaard wrote:
>> I added two simple testcases to show the basic support for unions
>> works now. But there are a couple of things that don't work correctly
>> for unions yet. In particular when enabling warnings for the new
>> union.rs testcase you'll get:
>>
>> $ gcc/gccrs -Bgcc -g union.rs
>> union.rs:18:3: warning: field is never read: ‘f1’
>>18 |   f1: U,
>>   |   ^
>> union.rs:19:3: warning: field is never read: ‘f2’
>>19 |   f2: V
>>   |   ^
>>
>> But those (union) fields in the struct are read. Similarly unused
>> union fields aren't detected.
>
> This is why the testcase uses { dg-options "-w" } to suppress all
> warnings.

For that one, I've put in 
"Handle 'UnsafeBlockExpr' in liveness analysis".  Hope I got that right;
someone please review.


> Attached is a small followup patch to resolve two FIXMEs to add the
> correct locus for the Union variant fields (the actual fixme was fixed
> by Thomas Young in commit 6d7b87f9dd92 "make struct field carry the
> location info"). But it was missing TupleField and (obviously)
> Union variants since those weren't implemented yet.
>
> Also on
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=tuple-union-field-locus

For that one, Marc P. filed 
"Add locus to TupleField and pass it and union variants to HIR class".


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] Fix byte char and byte string lexing code

[Thomas Schwinge]

Hi Mark!

On 2021-09-22T00:54:30+0200, Mark Wielaard  wrote:
> There were two warnings in lexer parse_byte_char and parse_byte_string
> code for arches with signed chars:
>
> rust-lex.cc: In member function
>  ‘Rust::TokenPtr Rust::Lexer::parse_byte_char(Location)’:
> rust-lex.cc:1564:21: warning: comparison is always false due to limited
>  range of data type [-Wtype-limits]
>  1564 |   if (byte_char > 127)
>   |   ~~^

That's .

> rust-lex.cc: In member function
>  ‘Rust::TokenPtr Rust::Lexer::parse_byte_string(Location)’:
> rust-lex.cc:1639:27: warning: comparison is always false due to limited
>  range of data type [-Wtype-limits]
>  1639 |   if (output_char > 127)
>   |   ^

That's .

Both these related to 
"GCC '--enable-bootstrap' build".

> The fix would be to cast to an unsigned char before the comparison.
> But that is actually wrong, and would produce the following errors
> parsing a byte char or byte string:
>
> bytecharstring.rs:3:14: error: ‘byte char’ ‘�’ out of range
> 3 |   let _bc = b'\x80';
>   |  ^
> bytecharstring.rs:4:14: error: character ‘�’ in byte string out of range
> 4 |   let _bs = b"foo\x80bar";
>   |  ^
>
> Both byte chars and byte strings may contain up to \xFF (255)
> characters. It is utf-8 chars or strings that can only [truncated here -- but 
> I understand what you mean]

I think this does match my thoughts in
.

> Remove the faulty check and add a new testcase bytecharstring.rs
> that checks byte chars and strings do accept > 127 hex char
> escapes, but utf-8 chars and strings reject such hex char escapes.
> ---
>
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=bytecharstring

Thanks, that's now: 
"Fix byte char and byte string lexing code".


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Merge from GCC upstream into GCC/Rust

[Thomas Schwinge]

Hi "Testers"!

I'm preparing a merge from GCC upstream into GCC/Rust.  This is normally
pretty unexciting ;-) -- the exception being, as once mentioned in
:

| Aside from the GCC/Rust-specific files (not existing in GCC upstream),
| we also carry a lot of changes in 'gcc/config/' (GCC back ends
| implementations), originating in 
| "@SimplyTheOther"'s work on Rust Target Hooks.  For a few of these
| files/changes we run into merge conflicts (which I did sort out), but
| also this work may need updates corresponding to GCC upstream changes.
| As that work is (per the Git commit logs etc.) still very much work in
| progress, and I assume hasn't been tested with all the respective many
| GCC back ends, I'm not going to spend much effort on that, and just
| make sure that x86_64-pc-linux-gnu continues to work.

As for checking that the configurations that you're testing are still
fine, would you like to do (and/or fix) that before or after me pushing
the merge?


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Merge from GCC upstream into GCC/Rust

[Thomas Schwinge]

Hi!

On 2021-09-24T10:30:15+0200, I wrote:
> I'm preparing a merge from GCC upstream into GCC/Rust.

Pushed to master branch commit 28f527c9598339cf834a30b5ee1f14258b8ecbb2
"Merge commit '2961ac45b9e19523958757e607d11c5893d6368b' [#247]".

> This is normally
> pretty unexciting ;-) -- the exception being, as once mentioned in
> :
>
> | Aside from the GCC/Rust-specific files (not existing in GCC upstream),
> | we also carry a lot of changes in 'gcc/config/' (GCC back ends
> | implementations), originating in 
> | "@SimplyTheOther"'s work on Rust Target Hooks.  For a few of these
> | files/changes we run into merge conflicts (which I did sort out), but
> | also this work may need updates corresponding to GCC upstream changes.
> | As that work is (per the Git commit logs etc.) still very much work in
> | progress, and I assume hasn't been tested with all the respective many
> | GCC back ends, I'm not going to spend much effort on that, and just
> | make sure that x86_64-pc-linux-gnu continues to work.


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Buildbot failure in Wildebeest Builder on whole buildset

[Thomas Schwinge]

Hi!

On 2022-01-24T22:30:21+0100, Marc via Gcc-rust  wrote:
> Mark Wielaard  writes:
>
>> Sorry, I don't immediately know what is happening.
>> I assume some merge took place and the buildbot doesn't know what are
>> good/bad commits and just tries to do builds for everything in the
>> merge. I have shutdown the buildbot till I have time to figure out what
>> is going on.
>
> Yes, it seems Thomas did a merge in
> 21af490baa734a901fb798bc2ac4df62109bc895, bringing gcc's master from a
> few days back :) [490e23032baaece71f2ec09fa1805064b150fbc2]

Yes, I did.  Mark, should I announce that in advance from now on?


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Buildbot failure in Wildebeest Builder on whole buildset

[Thomas Schwinge]

Hi Mark!

On 2022-01-29T21:20:45+0100, Mark Wielaard  wrote:
> On Tue, Jan 25, 2022 at 11:42:41PM +0100, Mark Wielaard wrote:
>> I added a filesIsImportant filter to the buildbot gccrs scheduler:
>>
>> gccrs_files = ["gcc/rust/", "gcc/testsuite/rust/", "gcc/config/.*/*-rust.c"]

Is that last one correct, or should that be 'gcc/config/*/*-rust.c'
(glob) or 'gcc/config/.*/.*-rust\.c' (regexp)?

After my recent GCC/Rust commit 5691503f11fb6bc5acd8be1e43faa0c5898c4b14
'GCC/Rust pieces of GCC upstream "Mass rename of C++ .c files to .cc suffix"',
please change the last one to '.cc' suffix.

>> def gccrsImportant(change):
>> for file in change.files:
>> for pattern in gccrs_files:
>> match = re.match(pattern, file)
>> if match:
>> return True
>> return False

Ah, so regexp.  ;-)

>> I think that should make sure that in the future any commits that
>> aren't part of the gccrs frontend won't trigger a build.
>
> This seems to work as expected and has the additional benefit of
> skipping those "merge" commits by bors since those don't actually
> change any files.

That sounds useful, yes.

Maybe include 'gcc/DATESTAMP' in 'gccrs_files', so that we also build
after merges from upstream (assuming that they span more than a day/do
change that file)?


Grüße
 Thomas


> Under https://builder.wildebeest.org/buildbot/#/changes you can see
> the "builds" for each change (some will now be empty if they didn't
> touch any gccrs files).
>
> Cheers,
>
> Mark
-
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: Buildbot failure in Wildebeest Builder on whole buildset

[Thomas Schwinge]

Hi!

On 2022-03-02T00:15:41+0100, Mark Wielaard  wrote:
> On Tue, Mar 01, 2022 at 07:08:15PM +, build...@builder.wildebeest.org 
> wrote:
>> The Buildbot has detected a new failure on builder gccrust-debian-arm64 
>> while building gccrust.
>> Full details are available at:
>> https://builder.wildebeest.org/buildbot/#builders/58/builds/1710
>>
>> Buildbot URL: https://builder.wildebeest.org/buildbot/
>>
>> Worker for this Build: debian-arm64
>>
>> Build Reason: 
>> Blamelist: Arthur Cohen 
>>
>> BUILD FAILED: failed compile (failure)
>
> And the same for all other builders.

... and me: 
"'[...]/gcc/rust/parse/rust-cfg-parser.cc:67: rust_cfg_parser_test:
FAIL: ASSERT_TRUE ((Rust::parse_cfg_option (input, key, value)))'".

> I haven't figured out yet why the last commit caused this.

(Same here.)

> But it can be replicated when configuring with --enable-checking=yes

That's strange -- isn't some '--enable-checking=[...]' actually the
default for GCC builds?

> That causes the selftests to trigger:

At least we can see that the GCC/Rust self-tests are executing!  ;-P


Grüße
 Thomas


> make[2]: Entering directory '/home/mark/build/gccrs-obj/gcc'
> /home/mark/build/gccrs-obj/./gcc/xgcc -B/home/mark/build/gccrs-obj/./gcc/ 
> -xrs -nostdinc /dev/null -S -o /dev/null 
> -fself-test=/home/mark/src/gccrs/gcc/testsuite/selftests
> rust1: error: unexpected character ‘1’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘1’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘e0’
> rust1: error: unexpected character ‘d3’
> rust1: error: unexpected character ‘89’
> /home/mark/src/gccrs/gcc/rust/parse/rust-cfg-parser.cc:68: 
> rust_cfg_parser_test: FAIL: ASSERT_EQ ((key), ("key_no_value"))
> rust1: internal compiler error: in fail, at selftest.cc:47
> 0x1cf096b selftest::fail(selftest::location const&, char const*)
>   /home/mark/src/gccrs/gcc/selftest.cc:47
> 0x7bb9a3 selftest::rust_cfg_parser_test()
>   /home/mark/src/gccrs/gcc/rust/parse/rust-cfg-parser.cc:68
> 0x1c143b7 selftest::run_tests()
>   /home/mark/src/gccrs/gcc/selftest-run-tests.cc:119
> 0xf1310b toplev::run_self_tests()
>   /home/mark/src/gccrs/gcc/toplev.cc:2217
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[2]: *** [/home/mark/src/gccrs/gcc/rust/Make-lang.in:232: 
> s-selftest-rust] Error 1
> make[2]: Leaving directory '/home/mark/build/gccrs-obj/gcc'
>
> Cheers,
>
> Mark
>
> --
> Gcc-rust mailing list
> Gcc-rust@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/gcc-rust
-
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: Buildbot failure in Wildebeest Builder on whole buildset

[Thomas Schwinge]

Hi!

On 2022-03-02T09:03:48+, Philip Herron  wrote:
> Yet again the build bots are out doing github automation :D. Would you
> be able to give Arthur access to the failing buildbot to test his fix?

I suggest as a first step to figure out why your local build aren't
running into this issue.  What does running 'build-gcc/gcc/xgcc -v'
should for you, and 'grep -i checking build-gcc/gcc/auto-host.h'?

> We think we know what the issue is. We changed the lexer so we could
> give it a buffer instead of a file for macro expansion, but the string
> is going out of scope when we set it up.

Ah!  So, "standard C/C++ undefined behavior, memory corruption"...  ;-)
I can easily test any patches that you need tested.


Grüße
 Thomas


> On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge  wrote:
>>
>> Hi!
>>
>> On 2022-03-02T00:15:41+0100, Mark Wielaard  wrote:
>> > On Tue, Mar 01, 2022 at 07:08:15PM +, build...@builder.wildebeest.org 
>> > wrote:
>> >> The Buildbot has detected a new failure on builder gccrust-debian-arm64 
>> >> while building gccrust.
>> >> Full details are available at:
>> >> https://builder.wildebeest.org/buildbot/#builders/58/builds/1710
>> >>
>> >> Buildbot URL: https://builder.wildebeest.org/buildbot/
>> >>
>> >> Worker for this Build: debian-arm64
>> >>
>> >> Build Reason: 
>> >> Blamelist: Arthur Cohen 
>> >>
>> >> BUILD FAILED: failed compile (failure)
>> >
>> > And the same for all other builders.
>>
>> ... and me: <https://github.com/Rust-GCC/gccrs/issues/987>
>> "'[...]/gcc/rust/parse/rust-cfg-parser.cc:67: rust_cfg_parser_test:
>> FAIL: ASSERT_TRUE ((Rust::parse_cfg_option (input, key, value)))'".
>>
>> > I haven't figured out yet why the last commit caused this.
>>
>> (Same here.)
>>
>> > But it can be replicated when configuring with --enable-checking=yes
>>
>> That's strange -- isn't some '--enable-checking=[...]' actually the
>> default for GCC builds?
>>
>> > That causes the selftests to trigger:
>>
>> At least we can see that the GCC/Rust self-tests are executing!  ;-P
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> > make[2]: Entering directory '/home/mark/build/gccrs-obj/gcc'
>> > /home/mark/build/gccrs-obj/./gcc/xgcc -B/home/mark/build/gccrs-obj/./gcc/ 
>> > -xrs -nostdinc /dev/null -S -o /dev/null 
>> > -fself-test=/home/mark/src/gccrs/gcc/testsuite/selftests
>> > rust1: error: unexpected character ‘1’
>> > rust1: error: unexpected character ‘0’
>> > rust1: error: unexpected character ‘0’
>> > rust1: error: unexpected character ‘0’
>> > rust1: error: unexpected character ‘1’
>> > rust1: error: unexpected character ‘0’
>> > rust1: error: unexpected character ‘0’
>> > rust1: error: unexpected character ‘0’
>> > rust1: error: unexpected character ‘e0’
>> > rust1: error: unexpected character ‘d3’
>> > rust1: error: unexpected character ‘89’
>> > /home/mark/src/gccrs/gcc/rust/parse/rust-cfg-parser.cc:68: 
>> > rust_cfg_parser_test: FAIL: ASSERT_EQ ((key), ("key_no_value"))
>> > rust1: internal compiler error: in fail, at selftest.cc:47
>> > 0x1cf096b selftest::fail(selftest::location const&, char const*)
>> >   /home/mark/src/gccrs/gcc/selftest.cc:47
>> > 0x7bb9a3 selftest::rust_cfg_parser_test()
>> >   /home/mark/src/gccrs/gcc/rust/parse/rust-cfg-parser.cc:68
>> > 0x1c143b7 selftest::run_tests()
>> >   /home/mark/src/gccrs/gcc/selftest-run-tests.cc:119
>> > 0xf1310b toplev::run_self_tests()
>> >   /home/mark/src/gccrs/gcc/toplev.cc:2217
>> > Please submit a full bug report,
>> > with preprocessed source if appropriate.
>> > Please include the complete backtrace with any bug report.
>> > See <https://gcc.gnu.org/bugs/> for instructions.
>> > make[2]: *** [/home/mark/src/gccrs/gcc/rust/Make-lang.in:232: 
>> > s-selftest-rust] Error 1
>> > make[2]: Leaving directory '/home/mark/build/gccrs-obj/gcc'
>> >
>> > Cheers,
>> >
>> > Mark
>> >
>> > --
>> > Gcc-rust mailing list
>> > Gcc-rust@gcc.gnu.org
>> > https://gcc.gnu.org/mailman/listinfo/gcc-rust
>> -
>> 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
-
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: Buildbot failure in Wildebeest Builder on whole buildset

[Thomas Schwinge]

Hi!

On 2022-03-02T10:44:38+0100, I wrote:
> On 2022-03-02T09:03:48+, Philip Herron  wrote:
>> Yet again the build bots are out doing github automation :D. Would you
>> be able to give Arthur access to the failing buildbot to test his fix?
>
> I suggest as a first step to figure out why your local build aren't
> running into this issue.  What does running 'build-gcc/gcc/xgcc -v'
> should for you, and 'grep -i checking build-gcc/gcc/auto-host.h'?
>
>> We think we know what the issue is. We changed the lexer so we could
>> give it a buffer instead of a file for macro expansion, but the string
>> is going out of scope when we set it up.
>
> Ah!  So, "standard C/C++ undefined behavior, memory corruption"...  ;-)

Indeed.  Building GCC with '--enable-valgrind-annotations' and running
the GCC self-test through '-wrapper valgrind,--leak-check=full', we see:

$ [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/ -xrs -nostdinc 
/dev/null -S -o /dev/null -fself-test=[...]/source-gcc/gcc/testsuite/selftests 
-wrapper valgrind,--leak-check=full
==3228208== Memcheck, a memory error detector
==3228208== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3228208== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright 
info
==3228208== Command: [...]/build-gcc/./gcc/rust1 /dev/null -quiet -dumpbase 
null -mtune=generic -march=x86-64 
-fself-test=[...]/source-gcc/gcc/testsuite/selftests -o /dev/null 
-L[...]/build-gcc/./gcc -L/lib/x86_64-linux-gnu -L/lib/../lib64 
-L/usr/lib/x86_64-linux-gnu
==3228208==
rust1: error: unexpected character ‘1’
rust1: error: unexpected character ‘0’
rust1: error: unexpected character ‘0’
rust1: error: unexpected character ‘0’
rust1: error: unexpected character ‘1’
rust1: error: unexpected character ‘0’
rust1: error: unexpected character ‘0’
rust1: error: unexpected character ‘0’
==3228208== Conditional jump or move depends on uninitialised value(s)
==3228208==at 0x983D5E: Rust::Lexer::build_token() (rust-lex.cc:365)
==3228208==by 0x987DB4: 
Rust::buffered_queue, 
Rust::Lexer::TokenSource>::peek(int) (rust-lex.h:233)
==3228208==by 0x988A46: 
Rust::parse_cfg_option(std::__cxx11::basic_string, 
std::allocator >&, std::__cxx11::basic_string, std::allocator >&, 
std::__cxx11::basic_string, std::allocator 
>&) (rust-lex.h:166)
==3228208==by 0x988D83: selftest::rust_cfg_parser_test() 
(rust-cfg-parser.cc:67)
==3228208==by 0x96C5EE: selftest::run_rust_tests() (rust-lang.cc:457)
==3228208==by 0x2527223: selftest::run_tests() 
(selftest-run-tests.cc:119)
==3228208==by 0x11C2C29: toplev::run_self_tests() (toplev.cc:2217)
==3228208==by 0x96991B: toplev::main(int, char**) (toplev.cc:2317)
==3228208==by 0x96BFD6: main (main.cc:39)
[...]

Before commit 6cf9f8c99c5813a23d7cec473fedf00683f409e4 "Merge #983", that
was "clean" (just some lost memory etc.).

> I can easily test any patches that you need tested.


Grüße
 Thomas


>> On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge  wrote:
>>>
>>> Hi!
>>>
>>> On 2022-03-02T00:15:41+0100, Mark Wielaard  wrote:
>>> > On Tue, Mar 01, 2022 at 07:08:15PM +, build...@builder.wildebeest.org 
>>> > wrote:
>>> >> The Buildbot has detected a new failure on builder gccrust-debian-arm64 
>>> >> while building gccrust.
>>> >> Full details are available at:
>>> >> https://builder.wildebeest.org/buildbot/#builders/58/builds/1710
>>> >>
>>> >> Buildbot URL: https://builder.wildebeest.org/buildbot/
>>> >>
>>> >> Worker for this Build: debian-arm64
>>> >>
>>> >> Build Reason: 
>>> >> Blamelist: Arthur Cohen 
>>> >>
>>> >> BUILD FAILED: failed compile (failure)
>>> >
>>> > And the same for all other builders.
>>>
>>> ... and me: <https://github.com/Rust-GCC/gccrs/issues/987>
>>> "'[...]/gcc/rust/parse/rust-cfg-parser.cc:67: rust_cfg_parser_test:
>>> FAIL: ASSERT_TRUE ((Rust::parse_cfg_option (input, key, value)))'".
>>>
>>> > I haven't figured out yet why the last commit caused this.
>>>
>>> (Same here.)
>>>
>>> > But it can be replicated when configuring with --enable-checking=yes
>>>
>>> That's strange -- isn't some '--enable-checking=[...]' actually the
>>> default for GCC builds?
>>>
>>> > That causes the selftests to trigger:
>>>
>>> At least we can see 

Re: Buildbot failure in Wildebeest Builder on whole buildset

[Thomas Schwinge]

Hi Arthur!

On 2022-03-02T13:05:30+0100, Arthur Cohen  wrote:
> On 3/2/22 11:05, Thomas Schwinge wrote:
>> On 2022-03-02T10:44:38+0100, I wrote:
>>> On 2022-03-02T09:03:48+, Philip Herron  
>>> wrote:
>>>> Yet again the build bots are out doing github automation :D. Would you
>>>> be able to give Arthur access to the failing buildbot to test his fix?
>>>
>>> I suggest as a first step to figure out why your local build aren't
>>> running into this issue.  What does running 'build-gcc/gcc/xgcc -v'
>>> should for you, and 'grep -i checking build-gcc/gcc/auto-host.h'?
>>>
>>>> We think we know what the issue is. We changed the lexer so we could
>>>> give it a buffer instead of a file for macro expansion, but the string
>>>> is going out of scope when we set it up.
>>>
>>> Ah!  So, "standard C/C++ undefined behavior, memory corruption"...  ;-)
>>
>> Indeed.  Building GCC with '--enable-valgrind-annotations' and running
>> the GCC self-test through '-wrapper valgrind,--leak-check=full', we see:
>>
>>  $ [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/ -xrs -nostdinc 
>> /dev/null -S -o /dev/null 
>> -fself-test=[...]/source-gcc/gcc/testsuite/selftests -wrapper 
>> valgrind,--leak-check=full
>>  ==3228208== Memcheck, a memory error detector
>>  ==3228208== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et 
>> al.
>>  ==3228208== Using Valgrind-3.18.1 and LibVEX; rerun with -h for 
>> copyright info
>>  ==3228208== Command: [...]/build-gcc/./gcc/rust1 /dev/null -quiet 
>> -dumpbase null -mtune=generic -march=x86-64 
>> -fself-test=[...]/source-gcc/gcc/testsuite/selftests -o /dev/null 
>> -L[...]/build-gcc/./gcc -L/lib/x86_64-linux-gnu -L/lib/../lib64 
>> -L/usr/lib/x86_64-linux-gnu
>>  ==3228208==
>>  rust1: error: unexpected character ‘1’
>>  rust1: error: unexpected character ‘0’
>>  rust1: error: unexpected character ‘0’
>>  rust1: error: unexpected character ‘0’
>>  rust1: error: unexpected character ‘1’
>>  rust1: error: unexpected character ‘0’
>>  rust1: error: unexpected character ‘0’
>>  rust1: error: unexpected character ‘0’
>>  ==3228208== Conditional jump or move depends on uninitialised value(s)
>>  ==3228208==at 0x983D5E: Rust::Lexer::build_token() (rust-lex.cc:365)
>>  ==3228208==by 0x987DB4: 
>> Rust::buffered_queue, 
>> Rust::Lexer::TokenSource>::peek(int) (rust-lex.h:233)
>>  ==3228208==by 0x988A46: 
>> Rust::parse_cfg_option(std::__cxx11::basic_string> std::char_traits, std::allocator >&, 
>> std::__cxx11::basic_string, 
>> std::allocator >&, std::__cxx11::basic_string> std::char_traits, std::allocator >&) (rust-lex.h:166)
>>  ==3228208==by 0x988D83: selftest::rust_cfg_parser_test() 
>> (rust-cfg-parser.cc:67)
>>  ==3228208==by 0x96C5EE: selftest::run_rust_tests() 
>> (rust-lang.cc:457)
>>  ==3228208==by 0x2527223: selftest::run_tests() 
>> (selftest-run-tests.cc:119)
>>  ==3228208==by 0x11C2C29: toplev::run_self_tests() (toplev.cc:2217)
>>  ==3228208==by 0x96991B: toplev::main(int, char**) (toplev.cc:2317)
>>  ==3228208==by 0x96BFD6: main (main.cc:39)
>>  [...]
>>
>> Before commit 6cf9f8c99c5813a23d7cec473fedf00683f409e4 "Merge #983", that
>> was "clean" (just some lost memory etc.).
>
> Thanks a lot for this. I thought it was some memory corruption,
> considering the lexer was seeing garbage characters. I'm a bit
> disappointed my computer and github's CI didn't have the behaviour, but
> oh well.

But have you been able to reproduce the issue with Valgrind, per the
instructiosn I've given?  (That's generally useful in GCC development: to
know about '--enable-valgrind-annotations', how to use '-wrapper' for
Valgrind but also GDB, etc.)

> I'd like to say that this is not my fault

Heh, no worries!  ;-)

> and that there really should
> be a wrapper around FILE* operations in the standard C++ library, or
> that this would have been avoided had we been writing Rust, but sadly... :)
>
> I think the patch to test is pretty easy if any of you guys want to test
> it. I'll also send a public key to Mark, thank you for the offer:
>
> ---
>   gcc/rust/lex/rust-lex.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/rust/lex/rust-lex.h b/gcc/rust/lex/rust-lex.h
> ind

Regular Online GCC/Rust Meeting Time Slot

[Thomas Schwinge]

Hi!

We're trying to figure out a good regular online GCC/Rust meeting time
slot.  Currently we're meeting once a month.

It's been a bit difficult to find a (a) free online service that
(b) doesn't work just with actual dates but generic days of week and
(c) does consider different timezones...

If you wish to participate in these calls, please on
 submit your availability in a typical
week.


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Document mailing list (was: GCC Rust git branch)

[Thomas Schwinge]

Hi!

On 2021-05-28T11:19:16+0100, Philip Herron  wrote:
> On 28/05/2021 04:22, Jason Merrill wrote:
>> On Mon, May 24, 2021 at 9:25 AM Philip Herron > <mailto:philip.her...@embecosm.com>> wrote:
>>> As some of you might know, I have been working on GCC Rust over on
>>> GitHub https://github.com/Rust-GCC/gccrs
>>> <https://github.com/Rust-GCC/gccrs>. As the project is moving
>>> forward and enforcing GCC copyright assignments for contributors, I
>>> would like to create a branch on the GCC git repo to show the
>>> intention
>>> to be upstream with GCC someday.
>>>
>>>  [snip]
>>>
>>> Separately, some contributors have expressed interest in
>>> maintaining the
>>> GCC style communications of using a mailing list and irc. Is it
>>> reasonable for this project to get a r...@gcc.gnu.org
>>> <mailto:r...@gcc.gnu.org>?
>>
>> That makes sense to me; I think overseers@ can help set up a new
>> mailing list.
>
> Thanks For the info everyone i will reach out to overseers about the
> Mailing List idea.

A  mailing list has thus been set up a year ago;
now documented on <https://gcc.gnu.org/lists.html> per gcc-wwwdocs
commit 1c89cdccbebda5d4c2eeeb627b1461b8877bb27e
"Document  mailing list", see attached.


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
>From 1c89cdccbebda5d4c2eeeb627b1461b8877bb27e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 8 Jun 2022 12:55:55 +0200
Subject: [PATCH] Document  mailing list

---
 htdocs/lists.html | 5 +
 1 file changed, 5 insertions(+)

diff --git a/htdocs/lists.html b/htdocs/lists.html
index ad36a7e2..c32c505d 100644
--- a/htdocs/lists.html
+++ b/htdocs/lists.html
@@ -70,6 +70,11 @@ before subscribing and posting to these lists.
   is a moderate volume list where regression results for the GCC compilers
   are posted.
 
+  https://gcc.gnu.org/ml/gcc-rust/";>gcc-rust
+  is for discussing https://gcc.gnu.org/wiki/RustFrontEnd";>Rust
+  support in GCC.
+  Patches should be sent to both this list and gcc-patches.
+
   https://gcc.gnu.org/ml/libstdc++/";>libstdc++
   is the main discussion and development list for the standard C++
   library (libstdc++-v3).  Patches to libstdc++-v3 should be sent to
-- 
2.35.1

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

Re: GCC Rust git branch

[Thomas Schwinge]

Hi!

This is about GCC/Rust, <https://rust-gcc.github.io/>, now also having a
presence in GCC upstream Git sources; see also
<https://github.com/Rust-GCC/gccrs/issues/143> "GCC Git Branch".

On 2021-05-24T16:24:38+, Joseph Myers  wrote:
> On Mon, 24 May 2021, Philip Herron wrote:
>
>> remote: error: hook declined to update refs/heads/gccrs
>
> refs/heads/gccrs doesn't match the branch naming conventions as documented
> at https://gcc.gnu.org/git.html (where you'd use refs/heads/devel/* for
> shared development branches), so if you hadn't had commit message
> formatting issues, the push would have been rejected for bad branch naming
> as well.
>
>> The commit message here is poorly formatted. To move forward, should I
>> rebase the tree to fix this commit and force push to rewrite the
>> history? Or is there a way to relax the rule for a new branch? Any
>> advice would be welcome.
>
> If the community desires to relax the checks in a particular case, the way
> to do it would probably be to set hooks.no-precommit-check, naming the
> agreed branch name, temporarily in refs/meta/config:project.config, then
> revert that project.config change afterwards.  See
> https://github.com/AdaCore/git-hooks for the detailed documentation of
> hook configuration.

Thanks.  I've thus pushed to refs/meta/config branch
commit 15e03be6fc6406e41c75ff95a9de449663fc9f0e "Enable
'no-precommit-check' for GCC/Rust development branches, 'devel/rust/*'",
see attached.


I've further pushed to gcc-wwwdocs
commit 325020ef06c714fbfd508d57e3f0bda272470464
"Document Git branch devel/rust/master", see attached.


I've also set up GCC Bugzilla:

  - Add new component *rust*:

<https://gcc.gnu.org/bugzilla/editcomponents.cgi?action=edit&product=gcc&component=rust>.
  - Add new version *rust/master*:

<https://gcc.gnu.org/bugzilla/editversions.cgi?action=edit&product=gcc&version=rust%2Fmaster>.


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
>From 15e03be6fc6406e41c75ff95a9de449663fc9f0e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 8 Jun 2022 12:00:04 +0200
Subject: [PATCH] Enable 'no-precommit-check' for GCC/Rust development
 branches, 'devel/rust/*'

---
 project.config | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/project.config b/project.config
index b7bdaf30b9e..5905fe26272 100644
--- a/project.config
+++ b/project.config
@@ -87,3 +87,9 @@
 	# Custom email formatter.  This inserts GCC monotonically
 	# increasing commit ids in the commit emails.
 	commit-email-formatter = /git/gcc.git/hooks-bin/commit_email_formatter
+
+	# For GCC/Rust development that happens outside of GCC proper,
+	# <https://rust-gcc.github.io/>, the Git commit messages
+	# don't always adhere to standard GCC style; see
+	# <https://github.com/Rust-GCC/gccrs/issues/143>.
+	no-precommit-check = refs/heads/devel/rust/.*
-- 
2.35.1

>From 325020ef06c714fbfd508d57e3f0bda272470464 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 8 Jun 2022 14:21:06 +0200
Subject: [PATCH] Document Git branch devel/rust/master

---
 htdocs/git.html | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/htdocs/git.html b/htdocs/git.html
index 5fbd98bf..f9acea54 100644
--- a/htdocs/git.html
+++ b/htdocs/git.html
@@ -349,6 +349,12 @@ in Git.
 implementation of Fortran coarrays.  It is maintained by
 Nicolas König.
 
+  https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master";>devel/rust/master
+  
+This branch is for development of
+https://gcc.gnu.org/wiki/RustFrontEnd";>Rust programming language
+  support in GCC.
+  
 
 
 Distribution Branches
-- 
2.35.1

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

Re: Setting up editors for the GNU/GCC coding style?

[Thomas Schwinge]

Hi!

On 2022-07-29T09:36:41+0200, Marc Poulhies via Gcc  wrote:
> Iannetta Paul  writes:
>> About configuring recent editors to follow the GNU coding style, I don't 
>> really
>> know but it should always be possible to register a hook that will run 
>> `indent`
>> when the file is saved.
>
> There is a clang-format config file in contrib that one can symlink in
> the root dir as .clang-format. I hope/guess tools like CLion can pick it
> and use it? At least this can be used to indent using clang-format tools
> and derivatives (like git-clang-format). In the GCC Rust project, we are
> using it (but judging by Jakub's last review for Philip's patch, the
> config is maybe not exhaustive, or our setup is not correct).

Simple answer there: these files are in 'gcc/config/' etc.,
but 'clang-format' is restricted to 'gcc/rust/' only (both in
'.github/workflows/clang-format.yml' and 'CONTRIBUTING.md':
"Running `clang-format` locally").

Unless everyone uses it, using 'clang-format' everywhere is too noisy;
it has a very strict (in my opinion: restrictive) understanding of
"proper" format.  ;-)


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
-- 
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

[Thomas Schwinge]

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.

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 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) 

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

[Thomas Schwinge]

Hi!

On 2022-11-09T14:53:44+0100, Richard Biener via Gcc-patches 
 wrote:
> On Wed, Oct 26, 2022 at 10:37 AM  wrote:
>> This patch [...] also contains a constant evaluator, ported
>> over from the C++ frontend.

Given that, and then:

>> --- /dev/null
>> +++ b/gcc/rust/backend/rust-constexpr.cc

>> +struct constexpr_global_ctx
>> +{
>> +  HOST_WIDE_INT constexpr_ops_count;
>
> If this isn't a INTEGER_CST related value then please avoid HOST_WIDE_INT
> and instead use uint64_t (or other more appropriate types).
>
>> +
>> +  constexpr_global_ctx () : constexpr_ops_count (0) {}
>> +};
>> +[...]
>> +static tree
>> +constexpr_expression (const constexpr_ctx *ctx, tree t)
>> +{
>> +  [...]
>> +  // Avoid excessively long constexpr evaluations
>> +  if (++ctx->global->constexpr_ops_count >= constexpr_ops_limit)
>> +{
>> +  rust_error_at (
>> +   Location (loc),
>> +   "% evaluation operation count exceeds limit of "
>> +   "%wd (use %<-fconstexpr-ops-limit=%> to increase the limit)",
>> +   constexpr_ops_limit);
>> +
>> +  return t;
>> +}

Arthur thus turned the 'HOST_WIDE_INT constexpr_ops_count' into an
'unsigned long', see 
"58e75f65e56d: Remove HOST_WIDE_INT struct member", but that results in
GCC bootstrap failure:

[...]/source-gcc/gcc/rust/backend/rust-constexpr.cc: In function 
‘tree_node* Rust::Compile::constexpr_expression(const constexpr_ctx*, tree)’:
[...]/source-gcc/gcc/rust/backend/rust-constexpr.cc:99:42: error: 
comparison of integer expressions of different signedness: ‘long unsigned int’ 
and ‘long int’ [-Werror=sign-compare]
   99 |   if (++ctx->global->constexpr_ops_count >= constexpr_ops_limit)

See the original C++ code:

gcc/cp/constexpr.cc:  HOST_WIDE_INT constexpr_ops_count;

gcc/c-family/c.opt-fconstexpr-ops-limit=
gcc/c-family/c.opt:C++ ObjC++ Joined RejectNegative Host_Wide_Int 
Var(constexpr_ops_limit) Init(33554432)
gcc/c-family/c.opt--fconstexpr-ops-limit=   Specify maximum 
number of constexpr operations during a single constexpr evaluation.

So I suggest change back the GCC/Rust 'constexpr_ops_count' to
'HOST_WIDE_INT' (submitted 
'Revert #1661 "58e75f65e56d: Remove HOST_WIDE_INT struct member"'), and
if anything needs to be changed, do thatt in GCC/C++ first, and then
mirror that into GCC/Rust.


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

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

[Thomas Schwinge]

Hi!

On 2022-09-14T15:34:10+0200, Richard Biener via Gcc-patches 
 wrote:
> On Wed, Aug 24, 2022 at 2:22 PM  wrote:
>> --- /dev/null
>> +++ b/gcc/rust/Make-lang.in

>> +# TODO: possibly find a way to ensure C++11 compilation level here?
>> +RUST_CXXFLAGS = -std=c++11 -Wno-unused-parameter -Werror=overloaded-virtual
>
> You probably should inherit from $(CXXFLAGS) here which ensures C++11
> compatibility.

That was done in GCC/Rust commit da13bf4bbc46b399419c3e7f2c358a0efe3bdfdd
"make: Inherit CXXFLAGS, remove compiler-specific warnings", which
changed this to just 'RUST_CXXFLAGS = $(CXXFLAGS)'.

> Note you have to deal with non-g++ host compilers when not
> bootstrapping so adding -Wno-unused-parameter -Werror=overload-virtual
> needs to be guarded.

'-Werror=overloaded-virtual' is implied as by default, we have
'-Woverloaded-virtual' and '-Werror'.  (I've verified via putting
'class tmp : public Dump { void visit (int) {} };' into
'gcc/rust/ast/rust-ast-dump.cc', and getting a number of
'error: ‘virtual void Rust::AST::Dump::visit([...])’ was hidden'.)
(Maybe that isn't active for '--disable-bootstrap' builds, but that's
"OK".)

Remains only '-Wno-unused-parameter'.  That one should move into
'rust-warn', where we currently have:

>> +# Use strict warnings for this front end.
>> +rust-warn = $(STRICT_WARN)

Per GCC 4.8 documentation (baseline version to bootstrap GCC), we may use
'-Wno-[...]' without checking whether the corresponding '-W[...]' is
actually supported, so we may specify '-Wno-unused-parameter'
unconditionally, like existing ones, for example in 'gcc/Makefile.in':

# These files are to have specific diagnostics suppressed, [...]
gimple-match.o-warn = -Wno-unused
generic-match.o-warn = -Wno-unused
dfp.o-warn = -Wno-strict-aliasing

I thus understand that non-GCC compilers implement the same '-Wno-[...]'
behavior -- or maybe warning flags are not passed to those at all, at
stage 1 build where this is (only) relevant.

I've thus proposed 
"'rust-warn += -Wno-unused-parameter'".


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v4 20/46] gccrs: Add wrapper for make_unique

[Thomas Schwinge]

Hi!

On 2022-12-07T09:50:40+0100, Arsen Arsenović via Gcc-patches 
 wrote:
> arthur.co...@embecosm.com writes:
>
>> This is a wrapper for make_unique. We can likely get rid of this, as there
>> are other implementations available, or simply keep using the unique_ptr
>> constructor.
>> ---
>>  gcc/rust/util/rust-make-unique.h | 35 
>>  1 file changed, 35 insertions(+)
>>  create mode 100644 gcc/rust/util/rust-make-unique.h
>>
>> diff --git a/gcc/rust/util/rust-make-unique.h 
>> b/gcc/rust/util/rust-make-unique.h
>> new file mode 100644
>> index 000..7b79e625ff1
>> --- /dev/null
>> +++ b/gcc/rust/util/rust-make-unique.h
>> @@ -0,0 +1,35 @@
>> +// 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_MAKE_UNIQUE_H
>> +#define RUST_MAKE_UNIQUE_H
>> +
>> +#include "rust-system.h"
>> +
>> +namespace Rust {
>> +
>> +template 
>> +std::unique_ptr
>> +make_unique (Ts &&...params)
>> +{
>> +  return std::unique_ptr (new T (std::forward (params)...));
>> +}
>> +
>> +} // namespace Rust
>> +
>> +#endif // RUST_MAKE_UNIQUE_H
>
> I think this was added recently, see commit
> 00d7c8ff16e6838273cea808ffbe22e98104f9d5 and gcc/make-unique.h.

I too had seen that, but decided to wait for until after the GCC/Rust
merge, to not add more complexity to that one.  It's OK, in my opinion,
to add 'gcc/rust/util/rust-make-unique.h' now, and then later
re-factor/get rid of that, to use 'gcc/make-unique.h' instead.

Anyway, thanks for pointing that out, of course!  :-)


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust (was: Rust front-end patches v4)

[Thomas Schwinge]

Hi!

On 2022-12-06T12:03:56+0100, Richard Biener via Gcc-patches 
 wrote:
> On Tue, Dec 6, 2022 at 11:11 AM  wrote:
>> This patchset contains the fixed version of our most recent patchset. [...]
>
> Thanks a lot - this is OK to merge now

Hey, hey!  :-)


Still working on some final edits to make the Git commits comply with GCC
policies, but hopefully ready to push soon.


I've pushed "Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust"
to master branch in commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f, see
attached.

Please let me know if there is anything that I need to do to actually
generate the empty 'gcc/rust/ChangeLog' file.

(For avoidance of doubt: yes, only 'gcc/rust/' at this time.)


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
>From 325529e21e81fbc3561d2568cb7e8a26296e5b2f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 10 Dec 2022 07:27:55 +0100
Subject: [PATCH] Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust

	contrib/
	* gcc-changelog/git_commit.py (default_changelog_locations): Add
	'gcc/rust'.
	(bug_components): Add 'rust'.
---
 contrib/gcc-changelog/git_commit.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index fb1d15fd86df..aae3416e082f 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -45,6 +45,7 @@ default_changelog_locations = {
 'gcc/objc',
 'gcc/objcp',
 'gcc/po',
+'gcc/rust',
 'gcc/testsuite',
 'gnattools',
 'gotools',
@@ -122,6 +123,7 @@ bug_components = {
 'preprocessor',
 'regression',
 'rtl-optimization',
+'rust',
 'sanitizer',
 'spam',
 'target',
-- 
2.35.1

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

Add stub 'gcc/rust/ChangeLog' (was: Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust)

[Thomas Schwinge]

Hi!

On 2022-12-10T07:39:24+0100, I wrote:
> I've pushed "Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust"
> to master branch in commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f, see
> attached.
>
> Please let me know if there is anything that I need to do to actually
> generate the empty 'gcc/rust/ChangeLog' file.

I've now been informed of a non-public email, that indeed there is a
manual step involved; pushed "Add stub 'gcc/rust/ChangeLog'" to master
branch in commit 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3, see attached.

> (For avoidance of doubt: yes, only 'gcc/rust/' at this time.)


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
>From 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 10 Dec 2022 08:33:22 +0100
Subject: [PATCH] Add stub 'gcc/rust/ChangeLog'

---
 gcc/rust/ChangeLog | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 gcc/rust/ChangeLog

diff --git a/gcc/rust/ChangeLog b/gcc/rust/ChangeLog
new file mode 100644
index ..3a4f03c28af8
--- /dev/null
+++ b/gcc/rust/ChangeLog
@@ -0,0 +1,6 @@
+
+Copyright (C) 2022 Free Software Foundation, Inc.
+
+Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved.
-- 
2.35.1

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

Re: Rust front-end patches v4

[Thomas Schwinge]

Hi Martin!

On 2022-12-09T14:24:18+0100, Martin Liška  wrote:
> I noticed a minor git issues when I tried [applying] the patches: [...]
>
> Can you please take a look at that?

Done via 
"Fix whitespace errors".

I've then force-updated the staging branch gcc-patch-dev: incorporate
these changes into the respective original commits.

Additionally fix up "gccrs: Add Parser for Rust front-end pt.1":
`new blank line at EOF` for `gcc/rust/parse/rust-parse-impl.h`.


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

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

[Thomas Schwinge]

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?

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
>From 3b2a8a4df1637a0cad738165a2afa9b34e286fcf Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 14 Dec 2022 17:16:42 +0100
Subject: [PATCH] Make '-frust-incomplete-and-experimental-compiler-do-not-use'
 a 'Common' option

I noticed that GCC/Rust recently lost all LTO variants in torture testing:

 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.

The reason is that when probing for availability of LTO, we run into:

spawn [...]/build-gcc/gcc/testsuite/rust/../../gccrs -B[...]/build-gcc/gcc/testsuite/rust/../../ -fdiagnostics-plain-output -frust-incomplete-and-experimental-compiler-do-not-use -flto -c -o lto8274.o lto8274.c
cc1: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C

For GCC/Rust testing, this flag is defaulted in
'gcc/testsuite/lib/rust.exp:rust_init':

lappend ALWAYS_RUSTFLAGS "additional_flags=-frust-incomplete-and-experimental-compiler-do-not-use"

Make it generally accepted without "is valid for Rust but not for [...]"
diagnostic.

	gcc/rust/
	* lang.opt
	(-frust-incomplete-and-experimental-compiler-do-not-use): Remove.
	gcc/
	* common.opt
	(-frust-incomplete-and-experimental-compiler-do-not-use): New.
---
 gcc/common.opt| 6 ++
 gcc/rust/lang.opt | 4 
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 562d73d7f552..eba28e650f94 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2552,6 +2552,12 @@ frounding-math
 Common Var(flag_rounding_math) Optimization SetByCombined
 Disable optimizations that assume default FP rounding behavior.
 
+; This option applies to Rust only, but is defined 'Common' here, so that it's
+; generally accepted without "is valid for Rust but not for [...]" diagnostic.
+frust-incomplete-and-experimental-compiler-do-not-use
+Common Var(flag_rust_experimental)
+Enable experime

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

[Thomas Schwinge]

Hi!

On 2022-12-15T08:53:13+0100, Richard Biener  wrote:
> On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
>  wrote:
>> 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

That doesn't work; it's 'cc1' that is complaining here.


Grüße
 Thomas


>> 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
>From 3b2a8a4df1637a0cad738165a2afa9b34e286fcf Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 14 Dec 2022 17:16:42 +0100
Subject: [PATCH] Make '-frust-incomplete-and-experimental-compiler-do-not-use'
 a 'Common' option

I noticed that GCC/Rust recently lost all LTO variants in torture testing:

 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.

The reason is that when probing for availability of LTO, we run into:

spawn [...]/build-gcc/gcc/testsuite/rust/../../gccrs -B[...]/build-gcc/gcc/testsuite/rust/../../ -fdiagnostics-plain-output -frust-incomplete-and-experimental-compiler-do-not-use -flto -c -o lto8274.o lto8274.c
cc1: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C

For GCC/Rust testing, this flag is defaulted in
'gcc/testsuite/lib/rust.exp:rust_init':

lappend ALWAYS_RUSTFLAGS "additional_flags=-frust-incomplete-and-experimental-compiler-do-not-use"

Make it generally accepted without "is valid f

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

[Thomas Schwinge]

Hi!

On 2022-12-15T12:50:44+0100, Jakub Jelinek via Gcc-patches 
 wrote:
> On Thu, Dec 15, 2022 at 12:39:38PM +0100, Iain Buclaw wrote:
>> 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

..., and this is a compilation mode that GCC generally intends to
support, right?  For example, also in use with Fortran, to bring in C
code.

From that it follows that it's either the duty of all drivers ('gcc',
'g++', 'gdc', 'gfortran', 'grust', etc.) to appropriately handle such
options (like,
"Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' 
option"
that I proposed), or indeed:

> Maybe it would be nice to be able to pass options only to a certain
> gcc backend binary and not to others, similarly to how
> -Wa,option passes options to assembler, -Wp,option to preprocessor and
> -Wl,option to linker.
> -Wc,language,option ?
> Then one could
>   gdc -Wc,d,-fextern-std=c++11 testcpp11.d cpp11.cpp -o testcpp11.exe
> or
>   gccrs -Wc,rust,-frust-incomplete-and-experimental-compiler-do-not-use 
> whatever.rs something.c -o whatever
> etc.
> If we do, one would need to use it with care, because then e.g. for
> gcc -Wc,c,-fsanitize=address
> the driver wouldn't know it should link in -lasan etc.

Hmm.  :-) On the one hand, I like it (or some similar syntax), on the
other hand, isn't this a bit over-engineered?  (..., and then also
"under-engineered": which front end(s) does "-Wp,option to preprocessor",
then apply to, for example; all of them, and we ought to add a mechanism
to have separate such options for different front ends...)

One step back:

Typically, per my understanding, GCC options are intended to convey
similar semantics, when they apply to more than one front end.  For
example, '-Wunused' means similar things in C, C++, Fortran, Rust
compilation.

Or, options are applicable to just one front end, and can just be a no-op
for others, for shared-language compilation.  For example, '-nostdinc++',
or '-frust-incomplete-and-experimental-compiler-do-not-use' need not
necessarily emit a diagnostic, but can just just be ignored by 'cc1',
'f951', 'lto1'.

For others, a diagnostic may be considered appropriate.  For example, as
we already have:

cc1: warning: command-line option '-std=c++11' is valid for C++/ObjC++ but 
not for C

But, you could also argue that the 'c++' in '-std=c++11' imples that it's
targeted at the 'b.cc' C++ compilation part of 'g++ -std=c++11 a.c b.cc',
and 'a.c' is compiled with default C '-std=[...]'; and you might in fact
have: 'g++ -std=c89 -std=c++11 a.c b.cc', huh...

If we go for extending the syntax, should we do something similar to
'-foffload-options', where might have syntax similar to:

-ffront-end-options=-ffoo\ -fbar -ffront-end-options=c,c++=-fsigned-char\ 
-fshort-enums -ffront-end-options=d,rust=[...]

That is, in contrast to your proposed '-Wc,[...]', this allows for
specifying the same options for multiple front ends in one go.  Is that
useful?


Anyway: how to get us un-stuck here -- maybe pragmatically?  :-)


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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

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' option)

[Thomas Schwinge]

Hi!

On 2022-12-15T16:17:05+0100, Jakub Jelinek  wrote:
> On Thu, Dec 15, 2022 at 04:01:33PM +0100, Thomas Schwinge wrote:
>> Or, options are applicable to just one front end, and can just be a no-op
>> for others, for shared-language compilation.  For example, '-nostdinc++',
>> or '-frust-incomplete-and-experimental-compiler-do-not-use' need not
>> necessarily emit a diagnostic, but can just just be ignored by 'cc1',
>> 'f951', 'lto1'.
>
> One simple change could be to add a new warning option and use it for
> complain_wrong_lang warnings:
>   else if (ok_langs[0] != '\0')
> /* Eventually this should become a hard error IMO.  */
> warning (0, "command-line option %qs is valid for %s but not for %s",
>  text, ok_langs, bad_lang);

(By the way, that comment was originally added in 2003-06-07
commit 2772ef3ef33609dd64209323e9418a847685971a
"Move handling of lang-specific switches to toplev".)

>   else
> /* Happens for -Werror=warning_name.  */
> warning (0, "%<-Werror=%> argument %qs is not valid for %s",
>  text, bad_lang);
> We could keep the existing behavior, but give users (and our testsuite)
> a way to silence that warning if they are ok with it applying only to a
> subset of languages.
> Then one could use
> -frust-incomplete-and-experimental-compiler-do-not-use -Wno-whatever
> or add that -Wno-whatever in check_compile if the snippet is different
> language from main language of the testsuite (or always) etc.

Like in the attaached
"Add '-Wno-complain-wrong-lang', and use it in 
'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere",
for example?

Anything that 'gcc/opts-global.cc:complain_wrong_lang' might do is cut
short by '-Wno-complain-wrong-lang', not just the one 'warning'
diagnostic.  This corresponds to what already exists via
'lang_hooks.complain_wrong_lang_p'.

The 'gcc/opts-common.cc:prune_options' changes follow the same rationale
as PR67640 "driver passes -fdiagnostics-color= always last": we need to
process '-Wno-complain-wrong-lang' early, so that it properly affects
other options appearing before it on the command line.


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?


In addition to the test suites, I'm also seeing:

build-gcc/build-x86_64-pc-linux-gnu/libcpp/config.log:cc1: warning: command 
line option '-fno-rtti' is valid for C++/ObjC++ but not for C [enabled by 
default]
build-gcc/gcc/config.log:cc1: warning: command-line option '-fno-rtti' is 
valid for C++/D/ObjC++ but not for C
build-gcc/gcc/config.log:cc1: warning: command-line option '-fno-rtti' is 
valid for C++/D/ObjC++ but not for C
build-gcc/libbacktrace/config.log:cc1: warning: command-line option 
'-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/libcc1/config.log:cc1: warning: command-line option '-fno-rtti' 
is valid for C++/D/ObjC++ but not for C
build-gcc/libcpp/config.log:cc1: warning: command-line option '-fno-rtti' 
is valid for C++/D/ObjC++ but not for C
build-gcc/lto-plugin/config.log:cc1: warning: command-line option 
'-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libatomic/config.log:cc1: warning: 
command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libbacktrace/config.log:cc1: warning: 
command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libffi/config.log:cc1: warning: command-line 
option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libgfortran/config.log:cc1: warning: 
command-line option '-

[PING] Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

[Thomas Schwinge]

Hi!

Ping.


Grüße
 Thomas


On 2022-12-16T15:10:12+0100, I wrote:
> Hi!
>
> On 2022-12-15T16:17:05+0100, Jakub Jelinek  wrote:
>> On Thu, Dec 15, 2022 at 04:01:33PM +0100, Thomas Schwinge wrote:
>>> Or, options are applicable to just one front end, and can just be a no-op
>>> for others, for shared-language compilation.  For example, '-nostdinc++',
>>> or '-frust-incomplete-and-experimental-compiler-do-not-use' need not
>>> necessarily emit a diagnostic, but can just just be ignored by 'cc1',
>>> 'f951', 'lto1'.
>>
>> One simple change could be to add a new warning option and use it for
>> complain_wrong_lang warnings:
>>   else if (ok_langs[0] != '\0')
>> /* Eventually this should become a hard error IMO.  */
>> warning (0, "command-line option %qs is valid for %s but not for %s",
>>  text, ok_langs, bad_lang);
>
> (By the way, that comment was originally added in 2003-06-07
> commit 2772ef3ef33609dd64209323e9418a847685971a
> "Move handling of lang-specific switches to toplev".)
>
>>   else
>> /* Happens for -Werror=warning_name.  */
>> warning (0, "%<-Werror=%> argument %qs is not valid for %s",
>>  text, bad_lang);
>> We could keep the existing behavior, but give users (and our testsuite)
>> a way to silence that warning if they are ok with it applying only to a
>> subset of languages.
>> Then one could use
>> -frust-incomplete-and-experimental-compiler-do-not-use -Wno-whatever
>> or add that -Wno-whatever in check_compile if the snippet is different
>> language from main language of the testsuite (or always) etc.
>
> Like in the attaached
> "Add '-Wno-complain-wrong-lang', and use it in 
> 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere",
> for example?
>
> Anything that 'gcc/opts-global.cc:complain_wrong_lang' might do is cut
> short by '-Wno-complain-wrong-lang', not just the one 'warning'
> diagnostic.  This corresponds to what already exists via
> 'lang_hooks.complain_wrong_lang_p'.
>
> The 'gcc/opts-common.cc:prune_options' changes follow the same rationale
> as PR67640 "driver passes -fdiagnostics-color= always last": we need to
> process '-Wno-complain-wrong-lang' early, so that it properly affects
> other options appearing before it on the command line.
>
>
> 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?
>
>
> In addition to the test suites, I'm also seeing:
>
> build-gcc/build-x86_64-pc-linux-gnu/libcpp/config.log:cc1: warning: 
> command line option '-fno-rtti' is valid for C++/ObjC++ but not for C 
> [enabled by default]
> build-gcc/gcc/config.log:cc1: warning: command-line option '-fno-rtti' is 
> valid for C++/D/ObjC++ but not for C
> build-gcc/gcc/config.log:cc1: warning: command-line option '-fno-rtti' is 
> valid for C++/D/ObjC++ but not for C
> build-gcc/libbacktrace/config.log:cc1: warning: command-line option 
> '-fno-rtti' is valid for C++/D/ObjC++ but not for C
> build-gcc/libcc1/config.log:cc1: warning: command-line option '-fno-rtti' 
> is valid for C++/D/ObjC++ but not for C
> build-gcc/libcpp/config.log:cc1: warning: command-line option '-fno-rtti' 
> is valid for C++/D/ObjC++ but not for C
> build-gcc/lto-plugin/config.log:cc1: warning: command-line option 
> '-fno-rtti' is valid for C++/D/ObjC++ but not for C
> build-gcc/x86_64-pc-linux-gnu/libatomic/config.log:cc1: warning: 
> command-line

'#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc' (was: [gcc r13-5533] gccrs: const folding port)

[Thomas Schwinge]

Hi!

On 2023-01-31T13:14:10+, Arthur Cohen via Gcc-cvs  
wrote:
> commit r13-5533-ge66fec8e6ba35edf01f86c2bf6514109aba4ded2
> Author: Faisal Abbas <90.abbasfai...@gmail.com>
> Date:   Mon Jun 27 16:05:49 2022 +0100
>
> gccrs: const folding port

> --- a/gcc/rust/backend/rust-tree.cc
> +++ b/gcc/rust/backend/rust-tree.cc
> @@ -21,12 +21,37 @@
>  #include "stringpool.h"
>  #include "attribs.h"
>  #include "escaped_string.h"
> +#include "libiberty.h"
> +#include "stor-layout.h"
> +#include "hash-map.h"
> +#include "diagnostic.h"
> +#include "timevar.h"
> +#include "convert.h"
> +#include "gimple-expr.h"
> +#include "gimplify.h"
> +#include "function.h"
> +#include "gcc-rich-location.h"
> +#include "target.h"
> +#include "file-prefix-map.h"
> +#include "cgraph.h"
> +
> +#include "output.h"

GCC's '#include' is a m...ystery -- I've pushed to master branch
commit 27a89f84c458ae938bc3eb92ad0d594c06fc3b42
"'#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc'", see attached.


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
>From 27a89f84c458ae938bc3eb92ad0d594c06fc3b42 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 17 Feb 2023 23:36:20 +0100
Subject: [PATCH] '#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc'
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... to resolve issues like:

<https://github.com/Rust-GCC/gccrs/issues/1864> "Upstream GCC broken for --target=pdp11-aout":

In file included from ./tm.h:18:0,
 from [...]/gcc/target.h:52,
 from [...]/gcc/rust/backend/rust-tree.cc:34:
[...]/gcc/rust/backend/rust-tree.cc: In function ‘void Rust::mark_exp_read(tree)’:
[...]/gcc/config/pdp11/pdp11.h:572:48: error: ‘pdp11_gen_int_label’ was not declared in this scope
   pdp11_gen_int_label ((LABEL), (PREFIX), (NUM))
^
[...]/gcc/rust/backend/rust-tree.cc:53:3: note: in expansion of macro ‘ASM_GENERATE_INTERNAL_LABEL’
   ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lsrc_loc", 1);
   ^
[...]/gcc/rust/backend/rust-tree.cc: In function ‘tree_node* Rust::fold_builtin_source_location(location_t)’:
[...]/gcc/config/pdp11/pdp11.h:572:48: error: ‘pdp11_gen_int_label’ was not declared in this scope
   pdp11_gen_int_label ((LABEL), (PREFIX), (NUM))
^
[...]/gcc/rust/backend/rust-tree.cc:4799:7: note: in expansion of macro ‘ASM_GENERATE_INTERNAL_LABEL’
   ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lsrc_loc", source_location_id++);
   ^
make[1]: *** [rust/rust-tree.o] Error 1

<https://github.com/Rust-GCC/gccrs/issues/1819> "New build failure on upstream GCC for --target=powerpc-ibm-aix7.{1,2}":

In file included from ./tm.h:22:0,
 from [...]/gcc/target.h:52,
 from [...]/gcc/rust/backend/rust-tree.cc:34:
[...]/gcc/rust/backend/rust-tree.cc: In function ‘void Rust::mark_exp_read(tree)’:
[...]/gcc/config/rs6000/xcoff.h:206:63: error: ‘rs6000_xcoff_strip_dollar’ was not declared in this scope
   sprintf (LABEL, "*%s..%u", rs6000_xcoff_strip_dollar (PREFIX), (unsigned) (NUM))
   ^
[...]/gcc/rust/backend/rust-tree.cc:53:3: note: in expansion of macro ‘ASM_GENERATE_INTERNAL_LABEL’
   ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lsrc_loc", 1);
   ^
[...]/gcc/rust/backend/rust-tree.cc: In function ‘tree_node* Rust::fold_builtin_source_location(location_t)’:
[...]/gcc/config/rs6000/xcoff.h:206:63: error: ‘rs6000_xcoff_strip_dollar’ was not declared in this scope
   sprintf (LABEL, "*%s..%u", rs6000_xcoff_strip_dollar (PREFIX), (unsigned) (NUM))
   ^
[...]/gcc/rust/backend/rust-tree.cc:4799:7: note: in expansion of macro ‘ASM_GENERATE_INTERNAL_LABEL’
   ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lsrc_loc", source_location_id++);
   ^
make[1]: *** [rust/rust-tree.o] Error 1

Fix-up for recent commit e66fec8e6ba35edf01f86c2bf6514109aba4ded2
"gccrs: const folding port".

	gcc/rust/
	* backend/rust-tree.cc: '#include "tm_p.h"'.
---
 gcc/rust/backend/rust-tree.cc | 2 +-
 1 f

Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace' (was: [PATCH Rust front-end v2 32/37] gccrs: Add config-lang.in)

[Thomas Schwinge]

Hi!

On 2022-08-24T12:59:51+0100, herron.phi...@googlemail.com 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.

> --- /dev/null
> +++ b/gcc/rust/config-lang.in

> +target_libs="target-libffi target-libbacktrace"

(By the way, this setting of 'target_libs' was not present in the v1
<https://inbox.sourceware.org/gcc-patches/20220727134040.843750-2-philip.her...@embecosm.com>
"[PATCH Rust front-end v1 1/4] Add skeleton Rust front-end folder".)

So there's the issue that not all GCC target configurations support
building those libraries.  Given that they're indeed unused, is it be OK
to push the attached
"Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace'"?
(..., and once we get to the point where we'd like to use libffi and/or
libbacktrace, then think about how to handle those GCC target
configurations.)


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
>From 5d85939a3e3ebcfcf3f2ac9d3f2e01cbb1736578 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 20 Feb 2023 13:01:50 +0100
Subject: [PATCH] Rust: Don't depend on unused 'target-libffi',
 'target-libbacktrace'

For example:

configure: error: "libffi has not been ported to nvptx-unknown-none."

Follow-up to commit a75f038c069cc3a23b214854bedf04321fe88bc5
"gccrs: Add config-lang.in", which said:

> This was a copy/paste from gccgo front-end. We do not use any of the
> target_libs yet, [...]

	gcc/rust/
	* config-lang.in (target_libs): Remove.
---
 gcc/rust/config-lang.in | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/rust/config-lang.in b/gcc/rust/config-lang.in
index 89055be5cd4..aac66c9b962 100644
--- a/gcc/rust/config-lang.in
+++ b/gcc/rust/config-lang.in
@@ -29,6 +29,4 @@ 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

[PING, v2] Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

[Thomas Schwinge]

Hi!

On 2023-01-11T13:31:56+0100, Jakub Jelinek via Gcc-patches 
 wrote:
> On Wed, Jan 11, 2023 at 12:41:06PM +0100, Thomas Schwinge wrote:
>
> I think this should be reviewed by Joseph as option handling maintainer.

Joseph, please?

>> +@item -Wno-complain-wrong-lang
>> +@opindex Wcomplain-wrong-lang
>> +@opindex Wno-complain-wrong-lang
>> +By default, we complain about command-line options that are not valid
>> +for this front end.
>> +This may be disabled with @code{-Wno-complain-wrong-lang}.
>
> I think this description is too short and confusing, it isn't clear what
> "this" front end is, perhaps say "that are not valid for a front end
> which compiles a particular source file"?
> And certainly give an example and more explanation that the option is
> mostly useful when a single compiler driver invocation is compiling
> multiple sources written in different languages.

Good suggestion, thanks.  I've changed the documentation as follows:

--- gcc/common.opt
+++ gcc/common.opt
 Wcomplain-wrong-lang
 Common Var(warn_complain_wrong_lang) Init(1) Warning
-Complain when a command-line option is not valid for this front end.
+Complain when a command-line option is valid, but not applicable to the 
current front end.

--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -8943,9 +8943,21 @@ Warn for variables that might be changed by 
@code{longjmp} or
 @item -Wno-complain-wrong-lang
 @opindex Wcomplain-wrong-lang
 @opindex Wno-complain-wrong-lang
-By default, we complain about command-line options that are not valid
-for this front end.
-This may be disabled with @code{-Wno-complain-wrong-lang}.
+By default, language front ends complain when a command-line option is
+valid, but not applicable to that front end.
+This may be disabled with @option{-Wno-complain-wrong-lang},
+which is mostly useful when invoking a single compiler driver for
+multiple source files written in different languages, for example:
+
+@smallexample
+$ g++ -fno-rtti a.cc b.f90
+@end smallexample
+
+The driver @file{g++} invokes the C++ front end to compile @file{a.cc}
+and the Fortran front end to compile @file{b.f90}.
+The latter front end diagnoses
+@samp{f951: Warning: command-line option '-fno-rtti' is valid for 
C++/D/ObjC++ but not for Fortran},
+which may be disabled with @option{-Wno-complain-wrong-lang}.

Is the attached v2
"Add '-Wno-complain-wrong-lang', and use it in 
'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere"
OK?


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
>From 76c852eb86dc80a5391bdbc4ae58832695a565c9 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 14 Dec 2022 17:16:42 +0100
Subject: [PATCH] Add '-Wno-complain-wrong-lang', and use it in
 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

I noticed that GCC/Rust recently lost all LTO variants in torture testing:

 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.

The reason is that when probing for availability of LTO, we run into:

spawn [...]/build-gcc/gcc/testsuite/rust/../../gccrs -B[...]/build-gcc/gcc/testsuite/rust/../../ -fdiagnostics-plain-output -frust-incomplete-and-experimental-compiler-do-not-use -flto -c -o lto8274.o lto8274.c
cc1: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C

For GCC/Rust testing, this flag is (as of recently) defaulted in
'gcc/testsuite/lib/rust.exp:rust_init':

lappend ALWAYS_RUSTFLAGS "additional_flags=-frust-incomplete-and-experimental-compiler-do-not-use"

A few more "command-line option [...] is valid for [...] but not for [...]"
instances were found in the test suite logs, when more than one language is
involved.

With '-Wno-complain-wro

Update copyright years. (was: [committed 003/103] gccrs: dump: Emit visibility when dumping items)

[Thomas Schwinge]

Hi!

On 2023-02-21T13:00:53+0100, arthur.co...@embecosm.com wrote:
> --- a/gcc/rust/ast/rust-ast-dump.cc
> +++ b/gcc/rust/ast/rust-ast-dump.cc
> @@ -1,4 +1,4 @@
> -// Copyright (C) 2020-2023 Free Software Foundation, Inc.
> +// Copyright (C) 2020-2022 Free Software Foundation, Inc.

> --- a/gcc/rust/ast/rust-ast-dump.h
> +++ b/gcc/rust/ast/rust-ast-dump.h
> @@ -1,4 +1,4 @@
> -// Copyright (C) 2020-2023 Free Software Foundation, Inc.
> +// Copyright (C) 2020-2022 Free Software Foundation, Inc.

Eh.  ;-)

Pushed to master branch
commit e28c5b33b987374f753b32306b0d3ecf610b64f2
"Update copyright years.", see attached.


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
>From e28c5b33b987374f753b32306b0d3ecf610b64f2 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 21 Feb 2023 13:49:42 +0100
Subject: [PATCH] Update copyright years.

... which accidentally had gotten reverted in recent
commit r13-6156-g1e8eb102200902e12c1b00e867e338be0a92c292
"gccrs: dump: Emit visibility when dumping items".
---
 gcc/rust/ast/rust-ast-dump.cc | 2 +-
 gcc/rust/ast/rust-ast-dump.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/rust/ast/rust-ast-dump.cc b/gcc/rust/ast/rust-ast-dump.cc
index 131e23ea1801..77e04b972dc0 100644
--- a/gcc/rust/ast/rust-ast-dump.cc
+++ b/gcc/rust/ast/rust-ast-dump.cc
@@ -1,4 +1,4 @@
-// Copyright (C) 2020-2022 Free Software Foundation, Inc.
+// Copyright (C) 2020-2023 Free Software Foundation, Inc.
 
 // This file is part of GCC.
 
diff --git a/gcc/rust/ast/rust-ast-dump.h b/gcc/rust/ast/rust-ast-dump.h
index 4bc322cda988..56918f5fc986 100644
--- a/gcc/rust/ast/rust-ast-dump.h
+++ b/gcc/rust/ast/rust-ast-dump.h
@@ -1,4 +1,4 @@
-// Copyright (C) 2020-2022 Free Software Foundation, Inc.
+// Copyright (C) 2020-2023 Free Software Foundation, Inc.
 
 // This file is part of GCC.
 
-- 
2.39.1

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

Rust: Move void_list_node init to common code (was: [PATCH] Move void_list_node init to common code)

[Thomas Schwinge]

arameter-lists () and (void).  */
> -  explicit_void_list_node = build_void_list_node ();
> +  explicit_void_list_node = build_tree_list (NULL_TREE, void_type_node);
>
>{
>  /* Make sure we get a unique function type, so we can give
> @@ -18450,14 +18450,6 @@ cp_tree_node_structure (union lang_tree_node * t)
>  }
>  }
>
> -/* Build the void_list_node (void_type_node having been created).  */
> -tree
> -build_void_list_node (void)
> -{
> -  tree t = build_tree_list (NULL_TREE, void_type_node);
> -  return t;
> -}
> -
>  bool
>  cp_missing_noreturn_ok_p (tree decl)
>  {
> diff --git a/gcc/d/d-builtins.cc b/gcc/d/d-builtins.cc
> index c2ef0c836e1..5997e5dcaf4 100644
> --- a/gcc/d/d-builtins.cc
> +++ b/gcc/d/d-builtins.cc
> @@ -889,7 +889,6 @@ static GTY(()) tree signed_size_type_node;
>  static void
>  d_build_c_type_nodes (void)
>  {
> -  void_list_node = build_tree_list (NULL_TREE, void_type_node);
>string_type_node = build_pointer_type (char_type_node);
>const_string_type_node
>  = build_pointer_type (build_qualified_type (char_type_node,
> diff --git a/gcc/fortran/f95-lang.cc b/gcc/fortran/f95-lang.cc
> index ff4bf800e49..a6750bea787 100644
> --- a/gcc/fortran/f95-lang.cc
> +++ b/gcc/fortran/f95-lang.cc
> @@ -530,8 +530,6 @@ gfc_init_decl_processing (void)
>   only use it for actual characters, not for INTEGER(1).  */
>build_common_tree_nodes (false);
>
> -  void_list_node = build_tree_list (NULL_TREE, void_type_node);
> -
>/* Set up F95 type nodes.  */
>gfc_init_kinds ();
>gfc_init_types ();
> diff --git a/gcc/go/go-lang.cc b/gcc/go/go-lang.cc
> index d519a69e647..4743370ff66 100644
> --- a/gcc/go/go-lang.cc
> +++ b/gcc/go/go-lang.cc
> @@ -98,9 +98,6 @@ go_langhook_init (void)
>  {
>build_common_tree_nodes (false);
>
> -  /* I don't know why this has to be done explicitly.  */
> -  void_list_node = build_tree_list (NULL_TREE, void_type_node);
> -
>/* We must create the gogo IR after calling build_common_tree_nodes
>   (because Gogo::define_builtin_function_trees refers indirectly
>   to, e.g., unsigned_char_type_node) but before calling
> diff --git a/gcc/jit/dummy-frontend.cc b/gcc/jit/dummy-frontend.cc
> index 84ff359bfe3..0687567bc88 100644
> --- a/gcc/jit/dummy-frontend.cc
> +++ b/gcc/jit/dummy-frontend.cc
> @@ -594,9 +594,6 @@ jit_langhook_init (void)
>
>build_common_tree_nodes (false);
>
> -  /* I don't know why this has to be done explicitly.  */
> -  void_list_node = build_tree_list (NULL_TREE, void_type_node);
> -
>build_common_builtin_nodes ();
>
>/* The default precision for floating point numbers.  This is used
> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc
> index 972a0336f75..d36453ba25d 100644
> --- a/gcc/lto/lto-lang.cc
> +++ b/gcc/lto/lto-lang.cc
> @@ -1239,7 +1239,6 @@ lto_build_c_type_nodes (void)
>  {
>gcc_assert (void_type_node);
>
> -  void_list_node = build_tree_list (NULL_TREE, void_type_node);
>string_type_node = build_pointer_type (char_type_node);
>const_string_type_node
>  = build_pointer_type (build_qualified_type (char_type_node, 
> TYPE_QUAL_CONST));
> diff --git a/gcc/tree.cc b/gcc/tree.cc
> index 0546c8f4025..4165cbd7c3b 100644
> --- a/gcc/tree.cc
> +++ b/gcc/tree.cc
> @@ -9414,6 +9414,8 @@ build_common_tree_nodes (bool signed_char)
>void_node = make_node (VOID_CST);
>TREE_TYPE (void_node) = void_type_node;
>
> +  void_list_node = build_tree_list (NULL_TREE, void_type_node);
> +
>null_pointer_node = build_int_cst (build_pointer_type (void_type_node), 0);
>layout_type (TREE_TYPE (null_pointer_node));
>


-
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
>From 334f23d83261997ca89d8919b94b97aa22003a65 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 22 Feb 2023 10:15:19 +0100
Subject: [PATCH] Rust: Move void_list_node init to common code

Apply commit r13-2682-g8ff2a92a0450243e52d3299a13b30f208bafa7e0
"Move void_list_node init to common code" to the Rust front end, too.

	gcc/rust/
	* rust-lang.cc (grs_langhook_init): Do not initialize
	void_list_node.
---
 gcc/rust/rust-lang.cc | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/rust/rust-lang.cc b/gcc/rust/rust-lang.cc
index 75f6b4458d74..3e20c45d907b 100644
--- a/gcc/rust/rust-lang.cc
+++ b/gcc/rust/rust-lang.cc
@@ -123,10 +123,6 @@ grs_langhook_init (void)
whether char is signed.  */
   build_common_tree_nodes (false);
 
-  // Creates a new TREE_LIST node with purpose NULL_TREE and value
-  // void_type_node
-  void_list_node = build_tree_list (NULL_TREE, void_type_node);
-
   // Builds built-ins for middle-end after all front-end built-ins are already
   // instantiated
   build_common_builtin_nodes ();
-- 
2.39.1

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

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

[Thomas Schwinge]

Hi!

Richard, you may remember your words from <https://gcc.gnu.org/PR46805>
"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?

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 <https://gcc.gnu.org/bugs/> for instructions.
>   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
> Error 1

See also <https://github.com/Rust-GCC/gccrs/issues/1713>
"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 <https://gcc.gnu.org/bugs/> 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
>From cae898bef63db18cc40b94ee4d48f85aec258c02 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 22 Feb 2023 11:42:43 +0100
Subject: [PATCH] Rust: In 'type_for_mode' langhook also consider all 'int_n'
 modes/types

As reported in "Rust related issues" at the end of
<https://inbox.sourceware.org/gcc-patches/20221219212344.ewtuzd2jtztm7...@lug-owl.de>
"Modula-2 / Rust: Many targets failing",
<https://github.com/Rust-GCC/gccrs/issues/1713>
"Test failure on msp430-elfbare target", for '--target=msp430-elfbar' we ICE:

: internal compiler error: Segmentation faul

Re: ☠ Buildbot (Sourceware): gccrust - failed 'grep unexpected ...' (failure) (master)

[Thomas Schwinge]

Hi!

On 2023-03-01T15:59:32+, builder--- via Gcc-rust  
wrote:
> A new failure has been detected on builder gccrust-debian-i386 while building 
> gccrust.
>
> Full details are available at:
> https://builder.sourceware.org/buildbot/#builders/27/builds/893

I've filed 
'ICE with #1929 commit 9c46a853be4b5a9c2e1b965fa0dcd44beed71924 "Add feature 
gate definition for extern_types"'.


Grüße
 Thomas


> Build state: failed 'grep unexpected ...' (failure)
> Revision: 9c46a853be4b5a9c2e1b965fa0dcd44beed71924
> Worker: debian-i386-2
> Build Reason: (unknown)
> Blamelist: mxlol233 
>
> Steps:
>
> - 0: worker_preparation ( success )
>
> - 1: git checkout ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/1/logs/stdio
>
> - 2: rm -rf gccrs-build ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/2/logs/stdio
>
> - 3: configure ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/3/logs/stdio
> - config.log: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/3/logs/config_log
>
> - 4: make ( warnings )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/4/logs/stdio
> - warnings (29): 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/4/logs/warnings__29_
>
> - 5: make check ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/5/logs/stdio
> - rust.sum: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/5/logs/rust_sum
> - rust.log: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/5/logs/rust_log
>
> - 6: grep unexpected rust.sum ( failure )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/6/logs/stdio
>
> - 7: prep ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/7/logs/stdio
>
> - 8: build bunsen.cpio.gz ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/8/logs/stdio
>
> - 9: fetch bunsen.cpio.gz ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/9/logs/stdio
>
> - 10: unpack bunsen.cpio.gz ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/10/logs/stdio
>
> - 11: pass .bunsen.source.gitname ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/11/logs/stdio
>
> - 12: pass .bunsen.source.gitdescribe ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/12/logs/stdio
>
> - 13: pass .bunsen.source.gitbranch ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/13/logs/stdio
>
> - 14: pass .bunsen.source.gitrepo ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/14/logs/stdio
>
> - 15: upload to bunsen ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/15/logs/stdio
>
> - 16: clean up ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/16/logs/stdio
>
> - 17: rm -rf gccrs-build_1 ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/27/builds/893/steps/17/logs/stdio
>
> --
> Gcc-rust mailing list
> Gcc-rust@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/gcc-rust
-
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: [GSoC] gccrs Unicode support

[Thomas Schwinge]

Hi!

(By the way, this GSoC project is being discussed in GCC/Rust Zulip:
.)

I'm now also putting Mark Wielaard in CC; he once also started discussing
this topic, "thinking of importing a couple of gnulib modules to help
with UTF-8 processing [unless] other gcc frontends handle [these things]
already in a way that might be reusable".  See the thread starting at

"rust frontend and UTF-8/unicode processing/properties".

On 2023-03-15T16:18:18+0100, Jakub Jelinek via Gcc  wrote:
> On Wed, Mar 15, 2023 at 11:00:19AM +, Philip Herron via Gcc wrote:
>> Excellent work on getting up to speed on the rust front-end. From my
>> perspective I am interested to see what the wider GCC community thinks
>> about using https://www.gnu.org/software/libunistring/ library within GCC
>> instead of rolling our own, this means it will be another dependency on GCC.
>>
>> The other option is there is already code in the other front-ends to do
>> this so in the worst case it should be possible to extract something out of
>> them and possibly make this a shared piece of functionality which we can
>> mentor you through.
>
> I don't know what exactly Rust FE needs in this area, but e.g. libcpp
> already handles whatever C/C++ need from Unicode support POV and can handle
> it without any extra libraries.
> So, if we could avoid the extra dependency, it would be certainly better,
> unless you really need massive amounts of code from those libraries.
> libcpp already e.g. provides mapping of unicode character names to code
> points, determining which unicode characters can appear at the start or
> in the middle of identifiers, etc.

So that's exactly the answer that I supposed you or someone else would
give.  ;-)

That means, GCC/Rust has some investigation to do: whether what libcpp
contains is (a) sufficient for its needs, and (b) whether that code can
be reused/extracted/refactored in a sensible way, into GCC-level shared
source code file, to be used by several front ends (possibly via libcpp).
(I suppose GCC/Rust shouldn't link in libcpp directly.)


Thanks for the input, all!


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
-- 
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

[Thomas Schwinge]

Hi Arthur!

On 2023-04-05T16:02:43+0200, arthur.co...@embecosm.com wrote:
> This patchset contains around 80 commits concerning the Rust frontend.

Did you not intend to actually 'git push' those?  ;-P


Grüße
 Thomas


> 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.
>
> All the best,
>
> Arthur
-
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 2/2] rust: update usage of TARGET_AIX to TARGET_AIX_OS

[Thomas Schwinge]

Hi Paul!

On 2023-06-16T11:00:02-0500, "Paul E. Murphy via Gcc-patches" 
 wrote:
> This was noticed when fixing the gccgo usage of the macro, the
> rust usage is very similar.
>
> TARGET_AIX is defined as a non-zero value on linux/powerpc64le
> which may cause unexpected behavior.  TARGET_AIX_OS should be
> used to toggle AIX specific behavior.
>
> gcc/rust/ChangeLog:
>
>   * rust-object-export.cc [TARGET_AIX]: Rename and update
>   usage to TARGET_AIX_OS.

I don't have rights to formally approve this GCC/Rust change, but I'll
note that it follows "as obvious" (see
, "Obvious fixes") to the
corresponding GCC/Go change, which has been approved:
,
and which is where this GCC/Rust code has been copied from, so I suggest
you push both patches at once.


Grüße
 Thomas


> ---
>  gcc/rust/rust-object-export.cc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/rust/rust-object-export.cc b/gcc/rust/rust-object-export.cc
> index 1143c767784..f9a395f6964 100644
> --- a/gcc/rust/rust-object-export.cc
> +++ b/gcc/rust/rust-object-export.cc
> @@ -46,8 +46,8 @@
>  #define RUST_EXPORT_SECTION_NAME ".rust_export"
>  #endif
>
> -#ifndef TARGET_AIX
> -#define TARGET_AIX 0
> +#ifndef TARGET_AIX_OS
> +#define TARGET_AIX_OS 0
>  #endif
>
>  /* Return whether or not GCC has reported any errors.  */
> @@ -91,7 +91,7 @@ rust_write_export_data (const char *bytes, unsigned int 
> size)
>  {
>gcc_assert (targetm_common.have_named_sections);
>sec = get_section (RUST_EXPORT_SECTION_NAME,
> -  TARGET_AIX ? SECTION_EXCLUDE : SECTION_DEBUG, NULL);
> +  TARGET_AIX_OS ? SECTION_EXCLUDE : SECTION_DEBUG, NULL);
>  }
>
>switch_to_section (sec);
> --
> 2.31.1
-
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 2/3] build: Add libgrust as compilation modules

[Thomas Schwinge]

Hi!

On 2023-09-20T13:59:53+0200, Arthur Cohen  wrote:
> From: Pierre-Emmanuel Patry 
>
> Define the libgrust directory as a host compilation module as well as
> for targets.

> --- 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.

Maybe just I am confused, but to make sure that the build doesn't break
for different GCC configurations, don't we also directly need to
incorporate here a few GCC/Rust master branch follow-on commits, like:

  - commit 171ea4e2b3e202067c50f9c206974fbe1da691c0 "fixup: Fix bootstrap build"
  - commit 61cbe201029658c32e5c360823b9a1a17d21b03c "fixup: Fix missing build 
dependency"
  - commit 6a8b207b9ef7f9038e0cae7766117428783825d8 "libgrust: Add dependency 
to libstdc++"

(Not sure if all of these are necessary and/or if that's the complete
list; haven't looked up the corresponding GCC/Rust GitHub PRs.)

> --- a/gcc/rust/config-lang.in
> +++ b/gcc/rust/config-lang.in

> +target_libs="target-libffi target-libbacktrace target-libgrust"

Please don't add back 'target-libffi' and 'target-libbacktrace' here;
just 'target-libgrust'.  (As is present in GCC/Rust master branch, and
per commit 7411eca498beb13729cc2acec77e68250940aa81
"Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace'".)


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
-- 
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

[Thomas Schwinge]

Hi!

On 2023-09-26T13:40:40+0200, Richard Biener  wrote:
> 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.

Would seem reasonable -- but to make things explicit, may also add in
'MAINTAINERS', 'Various Maintainers' an entry like:

libgrustAll Rust front end maintainers

..., or similar?  Or, explicitly duplicate for all Rust front end
maintainers.  (We don't seem to be consistent with respect to that.)

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

Before pushing this, don't you first have to set up an empty
'libgrust/ChangeLog', like
commit 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3
"Add stub 'gcc/rust/ChangeLog'", for example?

..., and adjust
'contrib/gcc-changelog/git_commit.py:default_changelog_locations', like
commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f
"Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust", for
example?

..., and then replace your 'libgrust/[...]' Git commit log entries:

>> 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 

... with:

libgrust/
* Makefile.am: New file.
[...]

(Or similar syntax.)  That way, the "nightly" auto-updater will use
'libgrust/ChangeLog' instead of the top-level 'ChangeLog'.

(I hope I got all that right.)


Please also update 'contrib/gcc_update:files_and_dependencies' for all
'libgrust/' generated files' dependencies.


Grüße
 Thomas


>> ---
>>  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)" \
>> +

Re: [PATCH] rust: build failure after NON_DEPENDENT_EXPR removal [PR111899]

[Thomas Schwinge]

Hi Patrick!

On 2023-10-20T13:36:30-0400, Patrick Palka  wrote:
> Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully).
>
> -- >8 --
>
> This patch removes stray NON_DEPENDENT_EXPR checks following the removal
> of this tree code from the C++ FE.  (Since this restores the build I
> supppose it means the Rust FE never creates NON_DEPENDENT_EXPR trees in
> the first place, so no further analysis is needed.)

ACK, thanks!


For context: indeed, a non-trivial amount of C++ front end 'constexpr'
code was copied into the Rust front end, for implementing related Rust
functionality, mostly as part of the 2022 GSoC project
"Support for Constant Folding in Rust Frontend" (Faisal Abbas),
.

Yes, this should eventually be cleaned up (and merged with the original
C++ front end code, as much as feasible -- which I don't know whether or
to which extent it is).


Grüße
 Thomas


>   PR rust/111899
>
> gcc/rust/ChangeLog:
>
>   * backend/rust-constexpr.cc (potential_constant_expression_1):
>   Remove NON_DEPENDENT_EXPR handling.
>   * backend/rust-tree.cc (mark_exp_read): Likewise.
>   (mark_use): Likewise.
>   (lvalue_kind): Likewise.
> ---
>  gcc/rust/backend/rust-constexpr.cc | 1 -
>  gcc/rust/backend/rust-tree.cc  | 3 ---
>  2 files changed, 4 deletions(-)
>
> diff --git a/gcc/rust/backend/rust-constexpr.cc 
> b/gcc/rust/backend/rust-constexpr.cc
> index b28fa27b2d0..a7ae4166ea0 100644
> --- a/gcc/rust/backend/rust-constexpr.cc
> +++ b/gcc/rust/backend/rust-constexpr.cc
> @@ -6151,7 +6151,6 @@ potential_constant_expression_1 (tree t, bool 
> want_rval, bool strict, bool now,
>  case CLEANUP_POINT_EXPR:
>  case EXPR_STMT:
>  case PAREN_EXPR:
> -case NON_DEPENDENT_EXPR:
>/* For convenience.  */
>  case LOOP_EXPR:
>  case EXIT_EXPR:
> diff --git a/gcc/rust/backend/rust-tree.cc b/gcc/rust/backend/rust-tree.cc
> index 66e859cd70c..7040c75f825 100644
> --- a/gcc/rust/backend/rust-tree.cc
> +++ b/gcc/rust/backend/rust-tree.cc
> @@ -72,7 +72,6 @@ mark_exp_read (tree exp)
>  case ADDR_EXPR:
>  case INDIRECT_REF:
>  case FLOAT_EXPR:
> -case NON_DEPENDENT_EXPR:
>  case VIEW_CONVERT_EXPR:
>mark_exp_read (TREE_OPERAND (exp, 0));
>break;
> @@ -128,7 +127,6 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
>switch (TREE_CODE (expr))
>  {
>  case COMPONENT_REF:
> -case NON_DEPENDENT_EXPR:
>recurse_op[0] = true;
>break;
>  case COMPOUND_EXPR:
> @@ -4520,7 +4518,6 @@ lvalue_kind (const_tree ref)
>lvalues.  */
>return (DECL_NONSTATIC_MEMBER_FUNCTION_P (ref) ? clk_none : 
> clk_ordinary);
>
> -case NON_DEPENDENT_EXPR:
>  case PAREN_EXPR:
>return lvalue_kind (TREE_OPERAND (ref, 0));
>
> --
> 2.42.0.411.g813d9a9188
-
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

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

[Thomas Schwinge]

Hi!

On 2023-10-25T13:06:48+0200, Arthur Cohen  wrote:
> From: Pierre-Emmanuel Patry 
>
> Define the libgrust directory as a host compilation module as well as
> for targets.

I don't see a response to Richard's comments:
.
Re "doesn't build libgrust if [Rust is not enabled]", I suppose (but have
not checked) this works for the *target* libgrust module via
'gcc/rust/config-lang.in:target_libs' requesting 'target-libgrust' only
if the Rust language is enabled?  I don't know what enables/disables the
*host* libgrust build?


My comments:

don't seem to have been addressed?


Also, don't you first have to get in "build: Regenerate build files"
before the 'gcc/rust/config-lang.in:target_libs' change, to avoid
breaking bisection?

Maybe, after all, don't have a separate "build: Regenerate build files"
commit, but instead do the regeneration as part of the commits adding the
source files, in usual GCC style?

And then, the 'contrib/gcc_update' change that's currently in
"libgrust: Add entry for maintainers and stub changelog file" should be
part of the commit that actually adds the files referenced therein.


Grüße
 Thomas


> 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 15c068e4ac4..929a6f0a08e 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 692dc716343..b2a5511bab1 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
-
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

Re: [PATCH v2 2/4] libgrust: Add libproc_macro and build system

[Thomas Schwinge]

Hi!

First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2
the "v2" libgrust changes as posted by Arthur, so that people can easily
test this before it getting into Git master branch.

I'll myself later try this for GCN and nvptx targets -- in their current
form where they don't support C++ (standard library), and in my hacky WIP
trees where C++ (standard library) is supported to some extent.  (This
should, roughly, match C++ functionality (not) provided by a number of
other GCC "embedded" targets.)


Then:

On 2023-10-25T13:06:46+0200, Arthur Cohen  wrote:
> From: Pierre-Emmanuel Patry 
>
> Add some dummy files in libproc_macro along with its build system.

I've not reviewed the build system in detail, just had a very quick look.

Three instances of 'librust'; should be 'libgrust':

configure.ac:AC_INIT([libgrust], version-unused,,librust)

configure.ac:AC_MSG_NOTICE([librust has been configured.])

Makefile.am:"TARGET_LIB_PATH_librust=$(TARGET_LIB_PATH_librust)" \

Compared to libgomp (which I'm reasonably familiar with), I found missing
in 'libgrust' at 'configure'-level:

  --enable-multilib   build many library versions (default)

  --disable-werrordisable building with -Werror

  --enable-symvers=STYLE  enables symbol versioning of the shared library
  [default=yes]

  --enable-cetenable Intel CET in target libraries 
[default=auto]

  --with-gcc-major-version-only
  use only GCC major number in filesystem paths

I can't tell off-hand whether all these are important, however.

Additionally, the new one that's being discussed in

'Update libgrust for upstream GCC commit 
6a6d3817afa02bbcd2388c8e005da6faf88932f1 "Config,Darwin: Allow for configuring 
Darwin to use embedded runpath"'.


Grüße
 Thomas


> libgrust/Changelog:
>
>   * Makefile.am: New file.
>   * configure.ac: New file.
>   * libproc_macro/Makefile.am: New file.
>   * libproc_macro/proc_macro.cc: New file.
>   * 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_TAR

Only build host libgrust if the Rust language is enabled (was: [PATCH v2 3/4] build: Add libgrust as compilation modules)

[Thomas Schwinge]

Hi!

On 2023-10-25T23:40:40+0200, I wrote:
> On 2023-10-25T13:06:48+0200, Arthur Cohen  wrote:
>> From: Pierre-Emmanuel Patry 
>>
>> Define the libgrust directory as a host compilation module as well as
>> for targets.
>
> I don't see a response to Richard's comments:
> <https://inbox.sourceware.org/cafiyyc0pcqfbknt06fammsnrf7ww4kbor6qvetwj++kmup1...@mail.gmail.com>.
> Re "doesn't build libgrust if [Rust is not enabled]", I suppose (but have
> not checked) this works for the *target* libgrust module via
> 'gcc/rust/config-lang.in:target_libs' requesting 'target-libgrust' only
> if the Rust language is enabled?

That aspect appears to work: testing a GCC configuration without the Rust
language enabled, target libgrust doesn't get built, but...

> I don't know what enables/disables the
> *host* libgrust build?

... indeed, host libgrust still does get built.

The attached "Only build host libgrust if the Rust language is enabled"
ought to address this.


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
>From 403e6bf5349f8a22e4dc7b74ea80acb55e4f5133 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 27 Oct 2023 11:59:19 +0200
Subject: [PATCH] Only build host libgrust if the Rust language is enabled

	gcc/
	* rust/config-lang.in (lang_dirs): Set to 'libgrust'.
---
 gcc/rust/config-lang.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/rust/config-lang.in b/gcc/rust/config-lang.in
index 8f071dcb0bf0..aee6f0eb468f 100644
--- a/gcc/rust/config-lang.in
+++ b/gcc/rust/config-lang.in
@@ -30,5 +30,6 @@ compilers="rust1\$(exeext)"
 build_by_default="no"
 
 target_libs="target-libffi target-libbacktrace target-libgrust"
+lang_dirs=libgrust
 
 gtfiles="\$(srcdir)/rust/rust-lang.cc"
-- 
2.40.1

Re: [PATCH v2 2/4] libgrust: Add libproc_macro and build system

[Thomas Schwinge]

Hi!

Short Friday afternoon status update:

On 2023-10-27T08:51:12+0100, Iain Sandoe  wrote:
>> On 26 Oct 2023, at 09:21, Thomas Schwinge  wrote:
>> First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2
>> the "v2" libgrust changes as posted by Arthur, so that people can easily
>> test this before it getting into Git master branch.
>>
>> I'll myself later try this for GCN and nvptx targets -- in their current
>> form where they don't support C++ (standard library)

Indeed, this currently fails to build:

[...]
make[3]: Entering directory 
`[...]/build-gcc/amdgcn-amdhsa/libgrust/libproc_macro'
[...]
libtool: compile:  [...]/build-gcc/./gcc/xg++ -B[...]/build-gcc/./gcc/ 
-nostdinc++ -funconfigured-libstdc++-v3 [...] -c 
[...]/source-gcc/libgrust/libproc_macro/proc_macro.cc
xg++: error: unrecognized command-line option ‘-funconfigured-libstdc++-v3’
make[3]: *** [proc_macro.lo] Error 1
make[3]: Leaving directory 
`[...]/build-gcc/amdgcn-amdhsa/libgrust/libproc_macro'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `[...]/build-gcc/amdgcn-amdhsa/libgrust'
make[1]: *** [all-target-libgrust] Error 2
make[1]: Leaving directory `[...]/build-gcc'
make: *** [all] Error 2

("error: unrecognized command-line option ‘-funconfigured-libstdc++-v3’"
indeed is the expected outcome if libstdc++ is not available, as I
understand.)

Same for nvptx-none target.

We need two things: (a) make sure that target libgrust build depends on
target libstdc++, and (b) disable target libgrust if target libstdc++ is
not available (and, later, gracefully handle that situation in the Rust
front end).

As far as I remember, patches exist for (a), and Arthur is going to
integrate/re-submit those.  Arthur, before re-submission, feel free to
first cherr-pick and push'these into the GCC upstream Git branch
devel/rust/libgrust-v2, so that I can re-test.  I'm not sure about (b),
whether that fell out of the (a) changes, too?  I can otherwise look into
that later.

>> and in my hacky WIP
>> trees where C++ (standard library) is supported to some extent.

This does built -- but the default multilib only, as Iain already
reported:

>> (This
>> should, roughly, match C++ functionality (not) provided by a number of
>> other GCC "embedded" targets.)
>
> on Darwin, it works for later systems without multilibs, but fails to build 
> multilibs.

I see that, too.

> —— so….
>
> With the patch below bootstrap suceeded on x86_64-darwin17 and produced a 
> correct
> architecture multilib.

Confirmed, thanks!

> Of course, there is no way to test this at the moment - I’d suggest
> that the next step might be something small in functionality that can allow 
> at least one
> test to be wired up.

ACK.

> ^^^ this is “lightly tested” of course, as I cycle through other versions of 
> the OS will see
> how it pans out.
>
> Do you want me to make a PR with this change against upstream?

Yes, please.  (But no hurry.)


Grüße
 Thomas


> From 027bc2c5255a6f1b75592e896dd99fac55bfb9b8 Mon Sep 17 00:00:00 2001
> From: Iain Sandoe 
> Date: Thu, 26 Oct 2023 23:19:36 +0100
> Subject: [PATCH] libgrust: enable multilib
>
> Most of this change is the regenerated files, the multilib config macro
> was already present, but commented out.
>
> libgrust/ChangeLog:
>
>   * Makefile.in:
>   * aclocal.m4: Regenerate.
>   * configure: Regenerate.
>   * configure.ac: Uncomment AM_ENABLE_MULTILIB.
>   * libproc_macro/Makefile.in:
>
> Signed-off-by: Iain Sandoe 
> ---
>  libgrust/Makefile.in   |  2 +
>  libgrust/aclocal.m4|  1 +
>  libgrust/configure | 68 --
>  libgrust/configure.ac  |  2 +-
>  libgrust/libproc_macro/Makefile.in |  2 +
>  5 files changed, 71 insertions(+), 4 deletions(-)
>
> diff --git a/libgrust/Makefile.in b/libgrust/Makefile.in
> index bc9b6cc227a..2dc39adff24 100644
> --- a/libgrust/Makefile.in
> +++ b/libgrust/Makefile.in
> @@ -93,6 +93,7 @@ ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
>  am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
>   $(top_srcdir)/../config/depstand.m4 \
>   $(top_srcdir)/../config/lead-dot.m4 \
> + $(top_srcdir)/../config/multi.m4 \
>   $(top_srcdir)/../config/no-executables.m4 \
>   $(top_srcdir)/../config/override.m4 \
>   $(top_srcdir)/../config/toolexeclibdir.m4 \
> @@ -275,6 +276,7 @@ localedir = @localedir@
>  localstatedir = @localstatedir@
>  mandir = @mandir@
>  mkdir_p = @mkdir_p@
> +multi_basedir = @multi_basedir@
>  oldincludedir = @oldincludedir@
>  pdfdir = @pdfdir@
>  prefix = @prefix@
> diff -

Disable target libgrust if we're not building target libstdc++ (was: [PATCH v2 2/4] libgrust: Add libproc_macro and build system)

[Thomas Schwinge]

Hi!

Short Friday evening status update:

On 2023-10-27T16:20:34+0200, I wrote:
> Short Friday afternoon status update:
>
> On 2023-10-27T08:51:12+0100, Iain Sandoe  wrote:
>>> On 26 Oct 2023, at 09:21, Thomas Schwinge  wrote:
>>> First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2
>>> the "v2" libgrust changes as posted by Arthur, so that people can easily
>>> test this before it getting into Git master branch.
>>>
>>> I'll myself later try this for GCN and nvptx targets -- in their current
>>> form where they don't support C++ (standard library)
>
> Indeed, this currently fails to build:
>
> [...]
> make[3]: Entering directory 
> `[...]/build-gcc/amdgcn-amdhsa/libgrust/libproc_macro'
> [...]
> libtool: compile:  [...]/build-gcc/./gcc/xg++ -B[...]/build-gcc/./gcc/ 
> -nostdinc++ -funconfigured-libstdc++-v3 [...] -c 
> [...]/source-gcc/libgrust/libproc_macro/proc_macro.cc
> xg++: error: unrecognized command-line option 
> ‘-funconfigured-libstdc++-v3’
> make[3]: *** [proc_macro.lo] Error 1
> make[3]: Leaving directory 
> `[...]/build-gcc/amdgcn-amdhsa/libgrust/libproc_macro'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `[...]/build-gcc/amdgcn-amdhsa/libgrust'
> make[1]: *** [all-target-libgrust] Error 2
> make[1]: Leaving directory `[...]/build-gcc'
> make: *** [all] Error 2
>
> ("error: unrecognized command-line option ‘-funconfigured-libstdc++-v3’"
> indeed is the expected outcome if libstdc++ is not available, as I
> understand.)
>
> Same for nvptx-none target.
>
> We need two things: (a) make sure that target libgrust build depends on
> target libstdc++, and (b) disable target libgrust if target libstdc++ is
> not available (and, later, gracefully handle that situation in the Rust
> front end).
>
> As far as I remember, patches exist for (a), and Arthur is going to
> integrate/re-submit those.

In fact, for (a), it seem that we just this one
GCC/Rust commit 6a8b207b9ef7f9038e0cae7766117428783825d8
"libgrust: Add dependency to libstdc++"; see
<https://github.com/Rust-GCC/gccrs/pull/2143>
"Add libstdc++ dependency to libgrust".

> Arthur, before re-submission, feel free to
> first cherr-pick and push'these into the GCC upstream Git branch
> devel/rust/libgrust-v2, so that I can re-test.

> I'm not sure about (b),
> whether that fell out of the (a) changes, too?  I can otherwise look into
> that later.

..., which I've now done.  Indeed that is still broken.  We need, if I
understand this correctly, the attached
"Disable target libgrust if we're not building target libstdc++" to
address that issue.

Pierre-Emmanuel: In this case (that is we cannot build target libgrust
because we're not building target libstdc++), do we also disable host
libgrust, or do we still build that one?  (This can be settled later.)


>>> and in my hacky WIP
>>> trees where C++ (standard library) is supported to some extent.
>
> This does built

..., but only if target libstdc++ already happens to have been built.  If
not, you'll run into funny libtool errors like:

[...]
libtool: compile: unrecognized option 
`-B[...]/build-gcc/amdgcn-amdhsa/libstdc++-v3/src/.libs'
libtool: compile: Try `libtool --help' for more information.
make[3]: *** [proc_macro.lo] Error 1
make[3]: Leaving directory 
`[...]/build-gcc/amdgcn-amdhsa/libgrust/libproc_macro'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `[...]/build-gcc/amdgcn-amdhsa/libgrust'
make[1]: *** [all-target-libgrust] Error 2
[...]

(This translates into: target libstdc++ has not (yet) been built;
'[...]/build-gcc/amdgcn-amdhsa/libstdc++-v3/src/.libs' is not (yet)
available.)

Need "libgrust: Add dependency to libstdc++" (see above) to make this
work reliably.


Grüße
 Thomas


> -- but the default multilib only, as Iain already
> reported:
>
>>> (This
>>> should, roughly, match C++ functionality (not) provided by a number of
>>> other GCC "embedded" targets.)
>>
>> on Darwin, it works for later systems without multilibs, but fails to build 
>> multilibs.
>
> I see that, too.
>
>> —— so….
>>
>> With the patch below bootstrap suceeded on x86_64-darwin17 and produced a 
>> correct
>> architecture multilib.
>
> Confirmed, thanks!
>
>> Of course, there is no way to test this at the moment - I’d suggest
>> that the next step might be something small in functionality that can allow 
>> at least one
>> test to be wired up.
>
> ACK.
>
&g

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

[Thomas Schwinge]

Hi!

To close the loop here:

On 2023-09-27T00:25:16+0200, I wrote:
> On 2023-09-20T13:59:53+0200, Arthur Cohen  wrote:
>> From: Pierre-Emmanuel Patry 
>>
>> Define the libgrust directory as a host compilation module as well as
>> for targets.
>
>> --- 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.
>
> Maybe just I am confused, but to make sure that the build doesn't break
> for different GCC configurations

Indeed, as discussed in

"[PATCH v2 2/4] libgrust: Add libproc_macro and build system".

> don't we also directly need to
> incorporate here a few GCC/Rust master branch follow-on commits, like:
>
>   - commit 171ea4e2b3e202067c50f9c206974fbe1da691c0 "fixup: Fix bootstrap 
> build"
>   - commit 61cbe201029658c32e5c360823b9a1a17d21b03c "fixup: Fix missing build 
> dependency"

I've not yet run into the need for these two.  Let's please leave these
out of the upstream submission for now, until we understand what exactly
these are necessary for.

However:

>   - commit 6a8b207b9ef7f9038e0cae7766117428783825d8 "libgrust: Add dependency 
> to libstdc++"

... this one definitely is necessary right now; see discussion in

"Disable target libgrust if we're not building target libstdc++".


And:

> (Not sure if all of these are necessary and/or if that's the complete
> list; haven't looked up the corresponding GCC/Rust GitHub PRs.)
>
>> --- a/gcc/rust/config-lang.in
>> +++ b/gcc/rust/config-lang.in
>
>> +target_libs="target-libffi target-libbacktrace target-libgrust"
>
> Please don't add back 'target-libffi' and 'target-libbacktrace' here;
> just 'target-libgrust'.  (As is present in GCC/Rust master branch, and
> per commit 7411eca498beb13729cc2acec77e68250940aa81
> "Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace'".)

... that change is necessary, too.


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

GCC/Rust libgrust-v2/to-submit branch (was: [PATCH 2/3] build: Add libgrust as compilation modules)

[Thomas Schwinge]

Hi!

Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit
branch: .
In that one, most of the issues raised have been addressed, and which
I've now successfully "tested" in my different GCC configurations,
requiring just one additional change (see end of this email).  I'm using
"tested" in quotes here, as libgrust currently is still missing its
eventual content, and still is without actual users, so we may still be
up for surprises later on.  ;-)

On 2023-10-27T22:41:52+0200, I wrote:
> On 2023-09-27T00:25:16+0200, I wrote:
>> don't we also directly need to
>> incorporate here a few GCC/Rust master branch follow-on commits, like:
>>
>>   - commit 171ea4e2b3e202067c50f9c206974fbe1da691c0 "fixup: Fix bootstrap 
>> build"
>>   - commit 61cbe201029658c32e5c360823b9a1a17d21b03c "fixup: Fix missing 
>> build dependency"
>
> I've not yet run into the need for these two.  Let's please leave these
> out of the upstream submission for now, until we understand what exactly
> these are necessary for.

(Still the same.)

> However:
>
>>   - commit 6a8b207b9ef7f9038e0cae7766117428783825d8 "libgrust: Add 
>> dependency to libstdc++"
>
> ... this one definitely is necessary right now; see discussion in
> 
> "Disable target libgrust if we're not building target libstdc++".

This one still isn't in the GCC/Rust libgrust-v2/to-submit branch -- but
having now tested that branch, I'm now no longer seeing the respective
build failure.  Isn't that change "libgrust: Add dependency to libstdc++"
still necessary, conceptually?  (Maybe we're just lucky, currently?)
I'll be sure to re-test in my different GCC configurations once libgrust
gains actual content and use.  (..., which might then re-expose the
original problem?)

> And:
>
>> (Not sure if all of these are necessary and/or if that's the complete
>> list; haven't looked up the corresponding GCC/Rust GitHub PRs.)
>>
>>> --- a/gcc/rust/config-lang.in
>>> +++ b/gcc/rust/config-lang.in
>>
>>> +target_libs="target-libffi target-libbacktrace target-libgrust"
>>
>> Please don't add back 'target-libffi' and 'target-libbacktrace' here;
>> just 'target-libgrust'.  (As is present in GCC/Rust master branch, and
>> per commit 7411eca498beb13729cc2acec77e68250940aa81
>> "Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace'".)
>
> ... that change is necessary, too.

That's still unchanged in the GCC/Rust libgrust-v2/to-submit branch;
please apply to 'gcc/rust/config-lang.in':

-target_libs="target-libffi target-libbacktrace target-libgrust"
+target_libs=target-libgrust

Then, still should re-order the commits so that (re)generation of
auto-generated files comes before use of libgrust (so that later
bisection doesn't break), and move the 'contrib/gcc_update' update into
the commit that adds the auto-generated files.


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

Re: GCC/Rust libgrust-v2/to-submit branch

[Thomas Schwinge]

Hi!

On 2023-11-21T16:20:22+0100, Arthur Cohen  wrote:
> A newer version of the library has been force-pushed to the branch
> `libgrust-v2/to-submit`.

> On 11/20/23 15:55, Thomas Schwinge wrote:
>> Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit
>> branch: <https://github.com/Rust-GCC/gccrs/tree/libgrust-v2/to-submit>.
>> In that one, most of the issues raised have been addressed, and which
>> I've now successfully "tested" in my different GCC configurations,
>> requiring just one additional change (see end of this email).  I'm using
>> "tested" in quotes here, as libgrust currently is still missing its
>> eventual content, and still is without actual users, so we may still be
>> up for surprises later on.  ;-)

>> On 2023-10-27T22:41:52+0200, I wrote:
>>> On 2023-09-27T00:25:16+0200, I wrote:
>>>> don't we also directly need to
>>>> incorporate here a few GCC/Rust master branch follow-on commits, like:
>>>>
>>>>- commit 171ea4e2b3e202067c50f9c206974fbe1da691c0 "fixup: Fix bootstrap 
>>>> build"
>>>>- commit 61cbe201029658c32e5c360823b9a1a17d21b03c "fixup: Fix missing 
>>>> build dependency"
>>>
>>> I've not yet run into the need for these two.  Let's please leave these
>>> out of the upstream submission for now, until we understand what exactly
>>> these are necessary for.
>>
>> (Still the same.)
>
> Do you mean that we should remove the content of these commits from the
> submission? If so, I believe it's now done.

That's correct.  My theory is that "fixup: Fix bootstrap build" can be
dropped altogether (that is, reverted on GCC/Rust master branch; I'll
look into that, later), and "fixup: Fix missing build dependency" will be
necessary once the GCC/Rust front end links against libgrust (that is,
will then move into that commit).

>>> However:
>>>
>>>>- commit 6a8b207b9ef7f9038e0cae7766117428783825d8 "libgrust: Add 
>>>> dependency to libstdc++"
>>>
>>> ... this one definitely is necessary right now; see discussion in
>>> <https://inbox.sourceware.org/8734xv24dd@euler.schwinge.homeip.net>
>>> "Disable target libgrust if we're not building target libstdc++".
>>
>> This one still isn't in the GCC/Rust libgrust-v2/to-submit branch -- but
>> having now tested that branch, I'm now no longer seeing the respective
>> build failure.  Isn't that change "libgrust: Add dependency to libstdc++"
>> still necessary, conceptually?  (Maybe we're just lucky, currently?)
>> I'll be sure to re-test in my different GCC configurations once libgrust
>> gains actual content and use.  (..., which might then re-expose the
>> original problem?)

So I guess I really just was lucky in my testing, because: later I
actually again did run into the need for that commit, so:

> This commit was integrated into another one:
>
> fb31093105e build: Add libgrust as compilation modules
>
> (on libgrust-v2/to-submit as of 2 minutes ago)

ACK.

>>>>> --- a/gcc/rust/config-lang.in
>>>>> +++ b/gcc/rust/config-lang.in
>>>>
>>>>> +target_libs="target-libffi target-libbacktrace target-libgrust"
>>>>
>>>> Please don't add back 'target-libffi' and 'target-libbacktrace' here;
>>>> just 'target-libgrust'.  (As is present in GCC/Rust master branch, and
>>>> per commit 7411eca498beb13729cc2acec77e68250940aa81
>>>> "Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace'".)
>>>
>>> ... that change is necessary, too.
>>
>> That's still unchanged in the GCC/Rust libgrust-v2/to-submit branch;
>> please apply to 'gcc/rust/config-lang.in':
>>
>>  -target_libs="target-libffi target-libbacktrace target-libgrust"
>>  +target_libs=target-libgrust

(That's now been addressed, too.)

>> Then, still should re-order the commits so that (re)generation of
>> auto-generated files comes before use of libgrust (so that later
>> bisection doesn't break), and move the 'contrib/gcc_update' update into
>> the commit that adds the auto-generated files.
>
> Do you mean that the regeneration should happen before the commit adding
> the proc_macro library? Or that when we keep going and adding more
> commits on top of this, we need to make sure the regeneration commit
> happ

Re: GCC/Rust libgrust-v2/to-submit branch

[Thomas Schwinge]

Hi Arthur, Pierre-Emmanuel!

On 2023-11-27T16:46:08+0100, I wrote:
> On 2023-11-21T16:20:22+0100, Arthur Cohen  wrote:
>> On 11/20/23 15:55, Thomas Schwinge wrote:
>>> Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit
>>> branch: <https://github.com/Rust-GCC/gccrs/tree/libgrust-v2/to-submit>.

..., and now updated once again.

>>> In that one, most of the issues raised have been addressed, and which
>>> I've now successfully "tested" in my different GCC configurations,
>>> requiring just one additional change (see end of this email).  I'm using
>>> "tested" in quotes here, as libgrust currently is still missing its
>>> eventual content, and still is without actual users, so we may still be
>>> up for surprises later on.  ;-)

>>> Then, still should re-order the commits [...]

> So I suggest:
>
>   - "libgrust: Add entry for maintainers and stub changelog file"
>   - "libgrust: Add libproc_macro and build system"
> ... plus 'autoreconf' in 'libgrust/' folded in.
> ... plus 'contrib/gcc_update' update moved here.
>   - "build: Add libgrust as compilation modules"
> ... plus "Disable target libgrust if missing libstdc++" folded in.
> ... plus 'autoreconf' and 'autogen'in '/' folded in.
>   - "Regenerate build files" then evaporates.

That's now been done, thanks.

Rebasing onto current master branch, there's a minor (textual) conflict
in top-level 'configure.ac:host_libs': 'intl' replaced by 'gettext', and
top-level 'configure' plus 'gcc/configure' have to be re-generated (the
latter for some unrelated changes in line numbers).  Otherwise, those
initial libgrust changes are now in the form that I thought they should
be in -- so I suggest you fix that up (I can quickly have a look again,
if you like), and then you do the "scary" 'git push' ;-) -- and then:

>> All the best, and thanks again for testing :)
>
> :-) So I hope I've not missed any major issues...

..., we wait and see.  :-)


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

Re: GCC/Rust libgrust-v2/to-submit branch

[Thomas Schwinge]

Hi Arthur, Pierre-Emmanuel!

On 2023-12-12T10:39:50+0100, I wrote:
> On 2023-11-27T16:46:08+0100, I wrote:
>> On 2023-11-21T16:20:22+0100, Arthur Cohen  wrote:
>>> On 11/20/23 15:55, Thomas Schwinge wrote:
>>>> Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit
>>>> branch: <https://github.com/Rust-GCC/gccrs/tree/libgrust-v2/to-submit>.

> Rebasing onto current master branch, there's a minor (textual) conflict
> in top-level 'configure.ac:host_libs': 'intl' replaced by 'gettext', and
> top-level 'configure' plus 'gcc/configure' have to be re-generated (the
> latter for some unrelated changes in line numbers).  Otherwise, those
> initial libgrust changes are now in the form that I thought they should
> be in -- so I suggest you fix that up (I can quickly have a look again,
> if you like)

I've noticed that you've fix that up (looks good), but I also noticed one
additional small item: into "build: Add libgrust as compilation modules",
you'll have to add the effect of top-level 'autogen Makefile.def' (that
is, regenerate the top-level 'Makefile.in').


Grüße
 Thomas


> and then you do the "scary" 'git push' ;-) -- and then:
>
>>> All the best, and thanks again for testing :)
>>
>> :-) So I hope I've not missed any major issues...
>
> ..., we wait and see.  :-)
>
>
> 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

Re: [PATCH v2 2/4] libgrust: Add libproc_macro and build system

[Thomas Schwinge]

Hi Jason!

I think you usually deal with these kind of GCC Git things?  If not,
please let me know.

On 2023-10-26T10:21:18+0200, I wrote:
> First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2
> the "v2" libgrust changes as posted by Arthur, so that people can easily
> test this before it getting into Git master branch.  [...]

Please now delete the GCC Git 'devel/rust/libgrust-v2' branch, which was
only used temporarily, and is now obsolete.

$ git push upstream :devel/rust/libgrust-v2
remote: *** Deleting branch 'devel/rust/libgrust-v2' is not allowed.
remote: *** 
remote: *** This repository currently only allow the deletion of references
remote: *** whose name matches the following:
remote: *** 
remote: *** refs/users/[^/]*/heads/.*
remote: *** refs/vendors/[^/]*/heads/.*
remote: *** 
remote: *** Branch deletion is only allowed for user and vendor branches.  
If another branch was created by mistake, contact an administrator to delete it 
on the server with git update-ref.  If a development branch is dead, also 
contact an administrator to move it under refs/dead/heads/ rather than deleting 
it.
remote: error: hook declined to update refs/heads/devel/rust/libgrust-v2
To git+ssh://gcc.gnu.org/git/gcc.git
 ! [remote rejected]   devel/rust/libgrust-v2 (hook declined)
error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'


Grüße
 Thomas

libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056] (was: [PATCH v2 2/4] libgrust: Add libproc_macro and build system)

[Thomas Schwinge]

Hi!

> --- a/libgrust/configure.ac
> +++ b/libgrust/configure.ac

> -# AM_ENABLE_MULTILIB(, ..)
> +AM_ENABLE_MULTILIB(, ..)

Such a change was applied eventually, and is necessary for target builds
-- but potentially harmful for host builds.  OK to push the attached
"libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056]"?


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
>From 71e00b191bd630aa3be66e38069c707ae76a91d3 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 18 Dec 2023 16:27:39 +0100
Subject: [PATCH] libgrust: 'AM_ENABLE_MULTILIB' only for target builds
 [PR113056]

..., but not for host builds, which don't need it, and it may cause the build
to fail.

Use what appears to be the standard pattern for that (see
'libbacktrace/configure.ac', 'zlib/configure.ac').

	PR rust/113056
	libgrust/
	* configure.ac: 'AM_ENABLE_MULTILIB' only for target builds.
	* configure: Regenerate.
---
 libgrust/configure| 8 +---
 libgrust/configure.ac | 4 +++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/libgrust/configure b/libgrust/configure
index 5388a0e22a6..e778a253915 100755
--- a/libgrust/configure
+++ b/libgrust/configure
@@ -2387,7 +2387,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 ac_config_files="$ac_config_files Makefile"
 
 
-# Default to --enable-multilib
+if test -n "${with_target_subdir}"; then
+  # Default to --enable-multilib
 # Check whether --enable-multilib was given.
 if test "${enable_multilib+set}" = set; then :
   enableval=$enable_multilib; case "$enableval" in
@@ -2424,6 +2425,7 @@ fi
 
 ac_config_commands="$ac_config_commands default-1"
 
+fi
 
 # Do not delete or change the following two lines.  For why, see
 # http://gcc.gnu.org/ml/libstdc++/2003-07/msg00451.html
@@ -12653,7 +12655,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12656 "configure"
+#line 12658 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12759,7 +12761,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12762 "configure"
+#line 12764 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/libgrust/configure.ac b/libgrust/configure.ac
index 226c42ba649..adfb3500fb3 100644
--- a/libgrust/configure.ac
+++ b/libgrust/configure.ac
@@ -2,7 +2,9 @@ AC_INIT([libgrust], version-unused,,libgrust)
 AC_CONFIG_SRCDIR(Makefile.am)
 AC_CONFIG_FILES([Makefile])
 
-AM_ENABLE_MULTILIB(, ..)
+if test -n "${with_target_subdir}"; then
+  AM_ENABLE_MULTILIB(, ..)
+fi
 
 # Do not delete or change the following two lines.  For why, see
 # http://gcc.gnu.org/ml/libstdc++/2003-07/msg00451.html
-- 
2.34.1

Re: GSoC: Application for Rust Front-End Project at GCC

[Thomas Schwinge]

Hi Arpit!

First, welcome to GCC, and I appreciate your enthousiasm!

On 2023-12-30T22:30:37+0530, CS21B062 ARPIT GUPTA  wrote:
> Dear GCC Community,
>
> I hope this email finds you well. My name is Arpit and I am writing to
> express my interest in participating in GSoC, specifically for the
> Rust Front-End project at GCC.

You're, however, too late for GSoC 2023 (..., which you'd referenced at
the end of your email), but also still too early for GSoC 2024; see
.

Building the compiler and beginning to experiment as well as reaching out
to the community is always a good start, so if you're interested in
GCC/Rust specifically, please have a look at
.


Grüße
 Thomas


> Having completed an internship in
> Compiler Design at IIT Hyderabad in my IInd Year , where I gained
> hands-on experience in code compliance, optimization analysis, and
> cross-compilation, I am eager to contribute to the development of the
> Rust compiler front-end.
>
> After carefully reviewing the available projects, I am particularly
> interested in the following project:
>
> Project Choice:
> Rust Front-End,  all the subdomains
>
> Project Description:
> Rust supports several metadata outputs crucial for importing crates.
> The goal of this project is to extend the support for metadata exports
> in the Rust Front-End being developed by GCC. I am confident in my
> understanding of compilation and linking processes, which will be
> essential for this project. I am excited about the opportunity to work
> on this challenging task and contribute to the completion of metadata
> exports.
>
> Why This Project:
> I believe that improving metadata exports is a crucial step towards
> enhancing the interoperability of the Rust compiler with other tools
> and platforms. This effort aligns with my passion for compiler design
> and would significantly contribute to the overall functionality of the
> Rust Front-End. Moreover, as an intern I have already developed some
> compliance checkers using clang for C language in accordance with
> AUTOSAR.
>
> Proposed Timeline:
>
> Weeks 1-2: In-depth analysis of the existing metadata export framework
> in GCC and understanding the requirements for Rust.
> Weeks 3-5: Implementation of basic metadata export functionality for
> the Rust Front-End.
> Weeks 6-8: Testing and debugging of the implemented features,
> addressing any issues that may arise during the integration.
> Weeks 9-12: Fine-tuning, optimization, and documentation of the
> metadata export process, ensuring it meets the project's goals.
>
> I am committed to engaging with the community throughout the
> development process, seeking feedback, and incorporating suggestions
> to ensure the success of the project. I have subscribed to the
> g...@gcc.gnu.org mailing list and will actively participate in
> discussions regarding the Rust Front-End project.
>
> I would appreciate any feedback or guidance on my proposed project and
> timeline. I am eager to contribute to the GCC community and make a
> meaningful impact on the Rust Front-End project.
>
> Thank you for considering my application. I look forward to the
> opportunity to contribute to the GCC community during GSoC 2023.
>
> Best regards,
> Arpit Gupta,
> Code Club Head
> ph: 8299480636

Re: [PATCHSET] Fix Rust bootstrap for future libgrust changes

[Thomas Schwinge]

Hi!

On 2024-01-11T15:22:07+0100, Arthur Cohen  wrote:
> Sorry about this - two simple changes to Makefile.def we had missed
> during our first libgrust/ patchset

I don't think those were "missed" but rather "intentionally omitted"?
I'll have to have a more detailed look.

(..., and almost no changes in the top-level build system I'd personally
dare to qualify as "simple"...)  ;-P


Grüße
 Thomas


> plus the associated regen of
> Makefile.in in each commit.
>
> Let me know if I should squash them together. I'll follow them up
> with our entire patchset.
>
> Best,
>
> Arthur

Re: GSoC: Application for Rust Front-End Project at GCC

[Thomas Schwinge]

Hi Arpit!

On 2024-01-11T08:15:28+0530, CS21B062 ARPIT GUPTA  wrote:
> Thank you for your email. But is there anyway I can start contributing. I
> have worked upon similar ground before, and as such I am looking for a
> summer undergrad internship. I wanted to build my profile by doing open
> source contribution.

Yes, sure, you may contribute to GCC anytime!  (..., and then later do a
GSoC project, too, of course.)

For GCC/Rust specifically, please have a look at
<https://rust-gcc.github.io/>.  In particular, newcomers seem to find it
helpful to join Zulip, and introduce themselves there, and get started on
a first small task.


Grüße
 Thomas


> On Thu, 11 Jan, 2024, 4:16 am Thomas Schwinge,  wrote:
>
>> Hi Arpit!
>>
>> First, welcome to GCC, and I appreciate your enthousiasm!
>>
>> On 2023-12-30T22:30:37+0530, CS21B062 ARPIT GUPTA 
>> wrote:
>> > Dear GCC Community,
>> >
>> > I hope this email finds you well. My name is Arpit and I am writing to
>> > express my interest in participating in GSoC, specifically for the
>> > Rust Front-End project at GCC.
>>
>> You're, however, too late for GSoC 2023 (..., which you'd referenced at
>> the end of your email), but also still too early for GSoC 2024; see
>> <https://developers.google.com/open-source/gsoc/timeline>.
>>
>> Building the compiler and beginning to experiment as well as reaching out
>> to the community is always a good start, so if you're interested in
>> GCC/Rust specifically, please have a look at
>> <https://rust-gcc.github.io/>.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> > Having completed an internship in
>> > Compiler Design at IIT Hyderabad in my IInd Year , where I gained
>> > hands-on experience in code compliance, optimization analysis, and
>> > cross-compilation, I am eager to contribute to the development of the
>> > Rust compiler front-end.
>> >
>> > After carefully reviewing the available projects, I am particularly
>> > interested in the following project:
>> >
>> > Project Choice:
>> > Rust Front-End,  all the subdomains
>> >
>> > Project Description:
>> > Rust supports several metadata outputs crucial for importing crates.
>> > The goal of this project is to extend the support for metadata exports
>> > in the Rust Front-End being developed by GCC. I am confident in my
>> > understanding of compilation and linking processes, which will be
>> > essential for this project. I am excited about the opportunity to work
>> > on this challenging task and contribute to the completion of metadata
>> > exports.
>> >
>> > Why This Project:
>> > I believe that improving metadata exports is a crucial step towards
>> > enhancing the interoperability of the Rust compiler with other tools
>> > and platforms. This effort aligns with my passion for compiler design
>> > and would significantly contribute to the overall functionality of the
>> > Rust Front-End. Moreover, as an intern I have already developed some
>> > compliance checkers using clang for C language in accordance with
>> > AUTOSAR.
>> >
>> > Proposed Timeline:
>> >
>> > Weeks 1-2: In-depth analysis of the existing metadata export framework
>> > in GCC and understanding the requirements for Rust.
>> > Weeks 3-5: Implementation of basic metadata export functionality for
>> > the Rust Front-End.
>> > Weeks 6-8: Testing and debugging of the implemented features,
>> > addressing any issues that may arise during the integration.
>> > Weeks 9-12: Fine-tuning, optimization, and documentation of the
>> > metadata export process, ensuring it meets the project's goals.
>> >
>> > I am committed to engaging with the community throughout the
>> > development process, seeking feedback, and incorporating suggestions
>> > to ensure the success of the project. I have subscribed to the
>> > g...@gcc.gnu.org mailing list and will actively participate in
>> > discussions regarding the Rust Front-End project.
>> >
>> > I would appreciate any feedback or guidance on my proposed project and
>> > timeline. I am eager to contribute to the GCC community and make a
>> > meaningful impact on the Rust Front-End project.
>> >
>> > Thank you for considering my application. I look forward to the
>> > opportunity to contribute to the GCC community during GSoC 2023.
>> >
>> > Best regards,
>> > Arpit Gupta,
>> > Code Club Head
>> > ph: 8299480636

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

[Thomas Schwinge]

Hi!

Three 'cargo' ('command not found') as well as
one 'rustc' ('error[E0658]: `let...else` statements are unstable')
errors:

On 2024-02-29T18:09:22+, buil...@sourceware.org wrote:
> A new failure has been detected on builder gccrust-fedora-x86_64 while 
> building gccrust.
>
> Full details are available at:
> https://builder.sourceware.org/buildbot/#/builders/16/builds/1917
>
> Build state: failed compile (failure)
> Revision: e9de5b410da43cb2ac5f9865756153648e6f078b
> Worker: bb3
> Build Reason: (unknown)
> Blamelist: Arthur Cohen , Thomas Schwinge 
> 
>
> Steps:
>
> - 0: worker_preparation ( success )
>
> - 1: git checkout ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/16/builds/1917/steps/1/logs/stdio
>
> - 2: rm -rf gccrs-build ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/16/builds/1917/steps/2/logs/stdio
>
> - 3: configure ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/16/builds/1917/steps/3/logs/stdio
> - config.log: 
> https://builder.sourceware.org/buildbot/#/builders/16/builds/1917/steps/3/logs/config_log
>
> - 4: make ( failure )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/16/builds/1917/steps/4/logs/stdio
> - warnings (10): 
> https://builder.sourceware.org/buildbot/#/builders/16/builds/1917/steps/4/logs/warnings__10_

/bin/sh: line 1: cargo: command not found
make[2]: *** [../../gccrs/gcc/rust/Make-lang.in:412: 
rust/libformat_parser.a] Error 127


> A new failure has been detected on builder gccrust-debian-i386 while building 
> gccrust.
>
> Full details are available at:
> https://builder.sourceware.org/buildbot/#/builders/27/builds/1934
>
> Build state: failed compile (failure)
> Revision: e9de5b410da43cb2ac5f9865756153648e6f078b
> Worker: debian-i386
> Build Reason: (unknown)
> Blamelist: Arthur Cohen , Thomas Schwinge 
> 
>
> Steps:
>
> - 0: worker_preparation ( success )
>
> - 1: git checkout ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/27/builds/1934/steps/1/logs/stdio
>
> - 2: rm -rf gccrs-build ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/27/builds/1934/steps/2/logs/stdio
>
> - 3: configure ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/27/builds/1934/steps/3/logs/stdio
> - config.log: 
> https://builder.sourceware.org/buildbot/#/builders/27/builds/1934/steps/3/logs/config_log
>
> - 4: make ( failure )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/27/builds/1934/steps/4/logs/stdio
> - warnings (5): 
> https://builder.sourceware.org/buildbot/#/builders/27/builds/1934/steps/4/logs/warnings__5_

cargo build --manifest-path 
../../gccrs/gcc/../libgrust/libformat_parser/Cargo.toml --release # FIXME: Not 
always release, right?
[...]
   Compiling libc v0.2.152
   Compiling unicode-xid v0.2.4
   Compiling generic_format_parser v0.1.0 
(/srv/buildbot/worker/gccrust-debian-i386/gccrs/libgrust/libformat_parser/generic_format_parser)
error[E0658]: `let...else` statements are unstable
   --> generic_format_parser/src/lib.rs:994:5
|
994 | / let Some(unescaped) = unescape_string(snippet) else {
995 | | return InputStringKind::NotALiteral;
996 | | };
| |__^
|
= note: see issue #87335 
<https://github.com/rust-lang/rust/issues/87335> for more information
For more information about this error, try `rustc --explain E0658`.
error: could not compile `generic_format_parser` due to previous error
warning: build failed, waiting for other jobs to finish...
make[2]: *** [../../gccrs/gcc/rust/Make-lang.in:412: 
rust/libformat_parser.a] Error 101


> A new failure has been detected on builder gccrust-debian-testing-x86_64 
> while building gccrust.
>
> Full details are available at:
> https://builder.sourceware.org/buildbot/#/builders/146/builds/1682
>
> Build state: failed compile (failure)
> Revision: e9de5b410da43cb2ac5f9865756153648e6f078b
> Worker: bb1-1
> Build Reason: (unknown)
> Blamelist: Arthur Cohen , Thomas Schwinge 
> 
>
> Steps:
>
> - 0: worker_preparation ( success )
>
> - 1: git checkout ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/146/builds/1682/steps/1/logs/stdio
>
> - 2: rm -rf gccrs-build ( success )
> Logs:
> - stdio: 
> h

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

[Thomas Schwinge]

Hi!

One more 'cargo' ('command not found') error:

On 2024-02-29T18:25:26+, buil...@sourceware.org wrote:
> A new failure has been detected on builder gccrust-rawhide-x86_64 while 
> building gccrust.
>
> Full details are available at:
> https://builder.sourceware.org/buildbot/#/builders/132/builds/1691
>
> Build state: failed compile (failure)
> Revision: 6895e0bb24ddc3893f917537b319ac20ba31f369
> Worker: bb1-2
> Build Reason: (unknown)
> Blamelist: Arthur Cohen , Thomas Schwinge 
> 
>
> Steps:
>
> - 0: worker_preparation ( success )
>
> - 1: git checkout ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/132/builds/1691/steps/1/logs/stdio
>
> - 2: rm -rf gccrs-build ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/132/builds/1691/steps/2/logs/stdio
>
> - 3: configure ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/132/builds/1691/steps/3/logs/stdio
> - config.log: 
> https://builder.sourceware.org/buildbot/#/builders/132/builds/1691/steps/3/logs/config_log
>
> - 4: make ( failure )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/132/builds/1691/steps/4/logs/stdio
> - warnings (10): 
> https://builder.sourceware.org/buildbot/#/builders/132/builds/1691/steps/4/logs/warnings__10_

/bin/sh: line 1: cargo: command not found
make[2]: *** [../../gccrs/gcc/rust/Make-lang.in:412: 
rust/libformat_parser.a] Error 127


Grüße
 Thomas

Re: [PATCH] rust: Add rust.install-dvi and rust.install-html rules

[Thomas Schwinge]

Hi Christophe!

On 2024-04-04T16:27:19+, Christophe Lyon  wrote:
> rust has the (empty) rust.dvi and rust.html rules, but lacks the
> (empty) rust.install-dvi and rust.install-html ones.

Thanks, looks good to me.


Grüße
 Thomas


> 2024-04-04  Christophe Lyon  
>
>   gcc/rust/
>   * Make-lang.in (rust.install-dvi, rust.install-html): New rules.
> ---
>  gcc/rust/Make-lang.in | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
> index 4d646018792..4d73412739d 100644
> --- a/gcc/rust/Make-lang.in
> +++ b/gcc/rust/Make-lang.in
> @@ -342,6 +342,8 @@ selftest-rust-valgrind: $(RUST_SELFTEST_DEPS)
>  # should have dependencies on info files that should be installed.
>  rust.install-info:
>  
> +rust.install-dvi:
> +rust.install-html:
>  rust.install-pdf:
>  
>  # Install man pages for the front end. This target should ignore errors.

Re: [gcc r14-7544] gccrs: libproc_macro: Build statically

[Thomas Schwinge]

Hi!

On 2024-01-16T17:43:10+, Arthur Cohen via Gcc-cvs  
wrote:
> https://gcc.gnu.org/g:71180a9eed367667e7b2c3f6aea1ee1bba15e9b3
>
> commit r14-7544-g71180a9eed367667e7b2c3f6aea1ee1bba15e9b3
> Author: Pierre-Emmanuel Patry 
> Date:   Wed Apr 26 10:31:35 2023 +0200
>
> gccrs: libproc_macro: Build statically
> 
> We do not need dynamic linking, all use case of this library cover can
> be done statically hence the change.
> 
> gcc/rust/ChangeLog:
> 
> * Make-lang.in: Link against the static libproc_macro.

> --- a/gcc/rust/Make-lang.in
> +++ b/gcc/rust/Make-lang.in
> @@ -182,11 +182,14 @@ RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS)
>  
>  rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
>  
> +RUST_LDFLAGS = $(LDFLAGS) -L./../libgrust/libproc_macro
> +RUST_LIBDEPS = $(LIBDEPS) ../libgrust/libproc_macro/libproc_macro.a
> +
>  # The compiler itself is called crab1
> -crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBDEPS) $(rust.prev)
> +crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(RUST_LIBDEPS) 
> $(rust.prev)
>   @$(call LINK_PROGRESS,$(INDEX.rust),start)
> - +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
> -   $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
> + +$(LLINKER) $(ALL_LINKERFLAGS) $(RUST_LDFLAGS) -o $@ \
> +   $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) 
> ../libgrust/libproc_macro/libproc_macro.a $(BACKENDLIBS)
>   @$(call LINK_PROGRESS,$(INDEX.rust),end)

The 'crab1' compiler is (at least potentially) just one of several
executables that 'gcc/rust/Make-lang.in' may build, which may all have
different library dependencies, etc.  Instead of via generic 'RUST_[...]'
variables, those dependencies etc. should therefore be specified as they
are individually necessary.

I've pushed to trunk branch the following clean-up commits, see attached:

  - commit cb70a49b30f0a22ec7a1b7df29c3ab370d603f90 "Remove 
'libgrust/libproc_macro_internal' from 'gcc/rust/Make-lang.in:RUST_LDFLAGS'"
  - commit f7c8fa7280c85cbdea45be9c09f36123ff16a78a "Inline 
'gcc/rust/Make-lang.in:RUST_LDFLAGS' into single user"
  - commit 24d92f65f9ed9b3c730c59f700ce2f5c038c8207 "Add 
'gcc/rust/Make-lang.in:LIBPROC_MACRO_INTERNAL'"
  - commit e3fda76af4f342ad1ba8bd901a72d811e8357e99 "Inline 
'gcc/rust/Make-lang.in:RUST_LIBDEPS' into single user"


Grüße
 Thomas


>From cb70a49b30f0a22ec7a1b7df29c3ab370d603f90 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 28 Feb 2024 22:41:42 +0100
Subject: [PATCH 1/4] Remove 'libgrust/libproc_macro_internal' from
 'gcc/rust/Make-lang.in:RUST_LDFLAGS'

This isn't necessary, as the full path to 'libproc_macro_internal.a' is
specified elsewhere.

	gcc/rust/
	* Make-lang.in (RUST_LDFLAGS): Remove
	'libgrust/libproc_macro_internal'.
---
 gcc/rust/Make-lang.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
index 4d73412739d..e901668b93d 100644
--- a/gcc/rust/Make-lang.in
+++ b/gcc/rust/Make-lang.in
@@ -208,7 +208,7 @@ RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS)
 
 rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
 
-RUST_LDFLAGS = $(LDFLAGS) -L./../libgrust/libproc_macro_internal
+RUST_LDFLAGS = $(LDFLAGS)
 RUST_LIBDEPS = $(LIBDEPS) ../libgrust/libproc_macro_internal/libproc_macro_internal.a
 
 # The compiler itself is called crab1
-- 
2.34.1

>From f7c8fa7280c85cbdea45be9c09f36123ff16a78a Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 28 Feb 2024 22:45:18 +0100
Subject: [PATCH 2/4] Inline 'gcc/rust/Make-lang.in:RUST_LDFLAGS' into single
 user

	gcc/rust/
	* Make-lang.in (RUST_LDFLAGS): Inline into single user.
---
 gcc/rust/Make-lang.in | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
index e901668b93d..ffeb325d6ce 100644
--- a/gcc/rust/Make-lang.in
+++ b/gcc/rust/Make-lang.in
@@ -208,13 +208,12 @@ RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS)
 
 rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
 
-RUST_LDFLAGS = $(LDFLAGS)
 RUST_LIBDEPS = $(LIBDEPS) ../libgrust/libproc_macro_internal/libproc_macro_internal.a
 
 # The compiler itself is called crab1
 crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(RUST_LIBDEPS) $(rust.prev)
 	@$(call LINK_PROGRESS,$(INDEX.rust),start)
-	+$(LLINKER) $(ALL_LINKERFLAGS) $(RUST_LDFLAGS) -o $@ \
+	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
 	  $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) ../libgrust/libproc_macro_internal/libproc_macro_internal.a $(BACKENDLIBS)
 	@$(call LINK_PROGRESS,$(INDEX.rust),end)
 
-- 
2.34.1

>From 24d92f65f9ed9b3c730c59f700ce2f5c038c8207 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 

Re: [PATCH] build: Check for cargo when building rust language

[Thomas Schwinge]

Hi!

On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
> The rust frontend requires cargo to build some of it's components,

In GCC upstream still: 's%requires%is going to require'.  ;-)

> it's presence was not checked during configuration.

After confirming the desired semantics/diagnostics, I've now pushed this
to trunk branch in commit 3e1e73fc99584440e5967577f2049573eeaf4596
"build: Check for cargo when building rust language".


I now wonder: instead of 'AC_CHECK_TOOL', shouldn't this use
'AC_CHECK_PROG'?  (We always want plain 'cargo', not host-prefixed
'aarch64-linux-gnu-cargo' etc., right?)  I'll look into changing this.


Grüße
 Thomas


> Prevent rust language from building when cargo is
> missing.
>
> config/ChangeLog:
>
>   * acx.m4: Add a macro to check for rust
>   components.
>
> ChangeLog:
>
>   * configure: Regenerate.
>   * configure.ac: Emit an error message when cargo
>   is missing.
>
> Signed-off-by: Pierre-Emmanuel Patry 
> ---
>  config/acx.m4 |  11 +
>  configure | 117 ++
>  configure.ac  |  18 
>  3 files changed, 146 insertions(+)
>
> diff --git a/config/acx.m4 b/config/acx.m4
> index 7efe98aaf96..3c5fe67342e 100644
> --- a/config/acx.m4
> +++ b/config/acx.m4
> @@ -424,6 +424,17 @@ else
>  fi
>  ])
>  
> +# Test for Rust
> +# We require cargo and rustc for some parts of the rust compiler.
> +AC_DEFUN([ACX_PROG_CARGO],
> +[AC_REQUIRE([AC_CHECK_TOOL_PREFIX])
> +AC_CHECK_TOOL(CARGO, cargo, no)
> +if test "x$CARGO" != xno; then
> +  have_cargo=yes
> +else
> +  have_cargo=no
> +fi])
> +
>  # Test for D.
>  AC_DEFUN([ACX_PROG_GDC],
>  [AC_REQUIRE([AC_CHECK_TOOL_PREFIX])
> diff --git a/configure b/configure
> index 874966fb9f0..46e66e20197 100755
> --- a/configure
> +++ b/configure
> @@ -714,6 +714,7 @@ PGO_BUILD_GEN_CFLAGS
>  HAVE_CXX11_FOR_BUILD
>  HAVE_CXX11
>  do_compare
> +CARGO
>  GDC
>  GNATMAKE
>  GNATBIND
> @@ -5786,6 +5787,104 @@ else
>have_gdc=no
>  fi
>  
> +
> +if test -n "$ac_tool_prefix"; then
> +  # Extract the first word of "${ac_tool_prefix}cargo", so it can be a 
> program name with args.
> +set dummy ${ac_tool_prefix}cargo; ac_word=$2
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> +$as_echo_n "checking for $ac_word... " >&6; }
> +if ${ac_cv_prog_CARGO+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  if test -n "$CARGO"; then
> +  ac_cv_prog_CARGO="$CARGO" # Let the user override the test.
> +else
> +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
> +for as_dir in $PATH
> +do
> +  IFS=$as_save_IFS
> +  test -z "$as_dir" && as_dir=.
> +for ac_exec_ext in '' $ac_executable_extensions; do
> +  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
> +ac_cv_prog_CARGO="${ac_tool_prefix}cargo"
> +$as_echo "$as_me:${as_lineno-$LINENO}: found 
> $as_dir/$ac_word$ac_exec_ext" >&5
> +break 2
> +  fi
> +done
> +  done
> +IFS=$as_save_IFS
> +
> +fi
> +fi
> +CARGO=$ac_cv_prog_CARGO
> +if test -n "$CARGO"; then
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $CARGO" >&5
> +$as_echo "$CARGO" >&6; }
> +else
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> +$as_echo "no" >&6; }
> +fi
> +
> +
> +fi
> +if test -z "$ac_cv_prog_CARGO"; then
> +  ac_ct_CARGO=$CARGO
> +  # Extract the first word of "cargo", so it can be a program name with args.
> +set dummy cargo; ac_word=$2
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> +$as_echo_n "checking for $ac_word... " >&6; }
> +if ${ac_cv_prog_ac_ct_CARGO+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  if test -n "$ac_ct_CARGO"; then
> +  ac_cv_prog_ac_ct_CARGO="$ac_ct_CARGO" # Let the user override the test.
> +else
> +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
> +for as_dir in $PATH
> +do
> +  IFS=$as_save_IFS
> +  test -z "$as_dir" && as_dir=.
> +for ac_exec_ext in '' $ac_executable_extensions; do
> +  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
> +ac_cv_prog_ac_ct_CARGO="cargo"
> +$as_echo "$as_me:${as_lineno-$LINENO}: found 
> $as_dir/$ac_word$ac_exec_ext" >&5
> +break 2
> +  fi
> +done
> +  done
> +IFS=$as_save_IFS
> +
> +fi
> +fi
> +ac_ct_CARGO=$ac_cv_prog_ac_ct_CARGO
> +if test -n "$ac_ct_CARGO"; then
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CARGO" >&5
> +$as_echo "$ac_ct_CARGO" >&6; }
> +else
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> +$as_echo "no" >&6; }
> +fi
> +
> +  if test "x$ac_ct_CARGO" = x; then
> +CARGO="no"
> +  else
> +case $cross_compiling:$ac_tool_warned in
> +yes:)
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not 
> prefixed with host triplet" >&5
> +$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" 
> >&2;}
> +ac_tool_warned=yes ;;
> +esac
> +CARGO=$ac_ct_CARGO
> +  fi
> +else
> +  CARGO="$ac_cv_prog_CARGO"
> +fi
> +
> +if test "x$CARGO" != xno; then
> +  have_cargo=yes
> +els

build: Don't check for host-prefixed 'cargo' program (was: [PATCH] build: Check for cargo when building rust language)

[Thomas Schwinge]

Hi!

On 2024-04-15T13:14:42+0200, I wrote:
> On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
>> The rust frontend requires cargo to build some of it's components,
>
> In GCC upstream still: 's%requires%is going to require'.  ;-)
>
>> it's presence was not checked during configuration.
>
> After confirming the desired semantics/diagnostics, I've now pushed this
> to trunk branch in commit 3e1e73fc99584440e5967577f2049573eeaf4596
> "build: Check for cargo when building rust language".
>
>
> I now wonder: instead of 'AC_CHECK_TOOL', shouldn't this use
> 'AC_CHECK_PROG'?  (We always want plain 'cargo', not host-prefixed
> 'aarch64-linux-gnu-cargo' etc., right?)  I'll look into changing this.

OK to push "build: Don't check for host-prefixed 'cargo' program", see
attached?


Grüße
 Thomas


>From 913be0412665d02561f8aeb999860ce8d292c61e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 15 Apr 2024 13:33:48 +0200
Subject: [PATCH] build: Don't check for host-prefixed 'cargo' program

Follow-up to commit 3e1e73fc99584440e5967577f2049573eeaf4596
"build: Check for cargo when building rust language":

On 2024-04-15T13:14:42+0200, I wrote:
> I now wonder: instead of 'AC_CHECK_TOOL', shouldn't this use
> 'AC_CHECK_PROG'?  (We always want plain 'cargo', not host-prefixed
> 'aarch64-linux-gnu-cargo' etc., right?)  I'll look into changing this.

	* configure: Regenerate.
	config/
	* acx.m4 (ACX_PROG_CARGO): Use 'AC_CHECK_PROGS'.
---
 config/acx.m4 |  3 +--
 configure | 64 ++-
 2 files changed, 8 insertions(+), 59 deletions(-)

diff --git a/config/acx.m4 b/config/acx.m4
index 3c5fe67342e..c45e55e7f51 100644
--- a/config/acx.m4
+++ b/config/acx.m4
@@ -427,8 +427,7 @@ fi
 # Test for Rust
 # We require cargo and rustc for some parts of the rust compiler.
 AC_DEFUN([ACX_PROG_CARGO],
-[AC_REQUIRE([AC_CHECK_TOOL_PREFIX])
-AC_CHECK_TOOL(CARGO, cargo, no)
+[AC_CHECK_PROGS(CARGO, cargo, no)
 if test "x$CARGO" != xno; then
   have_cargo=yes
 else
diff --git a/configure b/configure
index dd96445ac4a..e254aa132b5 100755
--- a/configure
+++ b/configure
@@ -5818,10 +5818,10 @@ else
   have_gdc=no
 fi
 
-
-if test -n "$ac_tool_prefix"; then
-  # Extract the first word of "${ac_tool_prefix}cargo", so it can be a program name with args.
-set dummy ${ac_tool_prefix}cargo; ac_word=$2
+for ac_prog in cargo
+do
+  # Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
 if ${ac_cv_prog_CARGO+:} false; then :
@@ -5837,7 +5837,7 @@ do
   test -z "$as_dir" && as_dir=.
 for ac_exec_ext in '' $ac_executable_extensions; do
   if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
-ac_cv_prog_CARGO="${ac_tool_prefix}cargo"
+ac_cv_prog_CARGO="$ac_prog"
 $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
 break 2
   fi
@@ -5857,59 +5857,9 @@ $as_echo "no" >&6; }
 fi
 
 
-fi
-if test -z "$ac_cv_prog_CARGO"; then
-  ac_ct_CARGO=$CARGO
-  # Extract the first word of "cargo", so it can be a program name with args.
-set dummy cargo; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CARGO+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  if test -n "$ac_ct_CARGO"; then
-  ac_cv_prog_ac_ct_CARGO="$ac_ct_CARGO" # Let the user override the test.
-else
-as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=$as_save_IFS
-  test -z "$as_dir" && as_dir=.
-for ac_exec_ext in '' $ac_executable_extensions; do
-  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
-ac_cv_prog_ac_ct_CARGO="cargo"
-$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
-break 2
-  fi
+  test -n "$CARGO" && break
 done
-  done
-IFS=$as_save_IFS
-
-fi
-fi
-ac_ct_CARGO=$ac_cv_prog_ac_ct_CARGO
-if test -n "$ac_ct_CARGO"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CARGO" >&5
-$as_echo "$ac_ct_CARGO" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-  if test "x$ac_ct_CARGO" = x; then
-CARGO="no"
-  else
-case $cross_compiling:$ac_tool_warned in
-yes:)
-{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
-$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
-ac_tool_warned=yes ;;
-esac
-CARGO=$ac_ct_CARGO
-  fi
-else
-  CARGO="$ac_cv_prog_CARGO"
-fi
+test -n "$CARGO" || CARGO="no"
 
 if test "x$CARGO" != xno; then
   have_cargo=yes
-- 
2.34.1

Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)

[Thomas Schwinge]

Hi!

On 2024-04-15T11:50:55+, buil...@sourceware.org wrote:
> A new failure has been detected on builder gcc-fedora-mingw while building 
> gcc.
>
> Full details are available at:
> https://builder.sourceware.org/buildbot/#/builders/262/builds/5337
>
> Build state: failed configure (failure)

As expected, a number of GCC builders are going to pass out after
GCC commit 3e1e73fc99584440e5967577f2049573eeaf4596
"build: Check for cargo when building rust language".

If I remember correctly, Mark said to look either into installing
suitable Cargo packages, or disable '--enable-languages=rust' for those.


Grüße
 Thomas


> Revision: a3281dd0f4b46c16ec1192ad411c0a96e6d086eb
> Worker: bb1-1
> Build Reason: (unknown)
> Blamelist: H.J. Lu , Pierre-Emmanuel Patry 
> , Tamar Christina 
> , Thomas Schwinge 
>
> Steps:
>
> - 0: worker_preparation ( success )
>
> - 1: git checkout ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/262/builds/5337/steps/1/logs/stdio
>
> - 2: rm -rf gcc-build ( success )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/262/builds/5337/steps/2/logs/stdio
>
> - 3: configure ( failure )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#/builders/262/builds/5337/steps/3/logs/stdio
> - config.log: 
> https://builder.sourceware.org/buildbot/#/builders/262/builds/5337/steps/3/logs/config_log

build: Use of cargo not yet supported here in Canadian cross configurations (was: [PATCH] build: Check for cargo when building rust language)

[Thomas Schwinge]

Hi!

On 2024-04-15T13:14:42+0200, I wrote:
> On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
>> The rust frontend requires cargo to build some of it's components,
>
> In GCC upstream still: 's%requires%is going to require'.  ;-)
>
>> it's presence was not checked during configuration.
>
> After confirming the desired semantics/diagnostics, I've now pushed this
> to trunk branch in commit 3e1e73fc99584440e5967577f2049573eeaf4596
> "build: Check for cargo when building rust language".

On top of that, OK to push the attached
"build: Use of cargo not yet supported here in Canadian cross configurations"?


Grüße
 Thomas


>From eb38990b4147951dd21f19def43072368f782af5 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 15 Apr 2024 14:27:45 +0200
Subject: [PATCH] build: Use of cargo not yet supported here in Canadian cross
 configurations

..., until <https://github.com/Rust-GCC/gccrs/issues/2898>
"'cargo' should build for the host system" is resolved.

Follow-up to commit 3e1e73fc99584440e5967577f2049573eeaf4596
"build: Check for cargo when building rust language".

	* configure.ac (have_cargo): Force to "no" in Canadian cross
	configurations
	* configure: Regenerate.
---
 configure| 13 +
 configure.ac | 12 
 2 files changed, 25 insertions(+)

diff --git a/configure b/configure
index e254aa132b5..e59a870b2bd 100755
--- a/configure
+++ b/configure
@@ -9179,6 +9179,19 @@ $as_echo "$as_me: WARNING: --enable-host-shared required to build $language" >&2
   ;;
 esac
 
+# Pre-conditions to consider whether cargo being supported.
+if test x"$have_cargo" = xyes \
+  && test x"$build" != x"$host"; then
+  # Until <https://github.com/Rust-GCC/gccrs/issues/2898>
+  # "'cargo' should build for the host system" is resolved:
+  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: use of cargo not yet supported here in Canadian cross configurations" >&5
+$as_echo "$as_me: WARNING: use of cargo not yet supported here in Canadian cross configurations" >&2;}
+  have_cargo=no
+else
+  # Assume that cargo-produced object files are compatible with what
+  # we're going to build here.
+  :
+fi
 # Disable Rust if cargo is unavailable.
 case ${add_this_lang}:${language}:${have_cargo} in
   yes:rust:no)
diff --git a/configure.ac b/configure.ac
index 87205d0ac1f..4ab54431475 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2306,6 +2306,18 @@ directories, to avoid imposing the performance cost of
   ;;
 esac
 
+# Pre-conditions to consider whether cargo being supported.
+if test x"$have_cargo" = xyes \
+  && test x"$build" != x"$host"; then
+  # Until <https://github.com/Rust-GCC/gccrs/issues/2898>
+  # "'cargo' should build for the host system" is resolved:
+  AC_MSG_WARN([use of cargo not yet supported here in Canadian cross configurations])
+  have_cargo=no
+else
+  # Assume that cargo-produced object files are compatible with what
+  # we're going to build here.
+  :
+fi
 # Disable Rust if cargo is unavailable.
 case ${add_this_lang}:${language}:${have_cargo} in
   yes:rust:no)
-- 
2.34.1

Don't override 'LIBS' if '--enable-languages=rust'; use 'CRAB1_LIBS' (was: [PATCH 005/125] gccrs: libgrust: Add format_parser library)

[Thomas Schwinge]

Hi!

On 2024-08-01T16:56:01+0200, Arthur Cohen  wrote:
> Compile libformat_parser and link to it.

> --- a/gcc/rust/Make-lang.in
> +++ b/gcc/rust/Make-lang.in

> +LIBS += -ldl -lpthread

That's still not correct.  I've pushed to trunk branch
commit 816c4de4d062c89f5b7a68f68f29b2b033f5b136
"Don't override 'LIBS' if '--enable-languages=rust'; use 'CRAB1_LIBS'",
see attached.


Grüße
 Thomas


>From 816c4de4d062c89f5b7a68f68f29b2b033f5b136 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 5 Aug 2024 10:06:05 +0200
Subject: [PATCH] Don't override 'LIBS' if '--enable-languages=rust'; use
 'CRAB1_LIBS'

Recent commit 6fef4d6ffcab0fec8518adcb05458cba5dbeac25
"gccrs: libgrust: Add format_parser library", added a general override of
'LIBS += -ldl -lpthread' if '--enable-languages=rust'.  This is wrong
conceptually, and will make the build fail on systems not providing such
libraries.  Instead, 'CRAB1_LIBS', added a while ago in
commit 75299e4fe50aa8d9b3ff529e48db4ed246083e64
"rust: Do not link with libdl and libpthread unconditionally", should be used,
and not generally, but for 'crab1' only.

	gcc/rust/
	* Make-lang.in (LIBS): Don't override.
	(crab1$(exeext):): Use 'CRAB1_LIBS'.
---
 gcc/rust/Make-lang.in | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
index 24229c02770..c3be5f9d81b 100644
--- a/gcc/rust/Make-lang.in
+++ b/gcc/rust/Make-lang.in
@@ -54,8 +54,6 @@ GCCRS_D_OBJS = \
rust/rustspec.o \
$(END)
 
-LIBS += -ldl -lpthread
-
 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 \
@@ -237,7 +235,7 @@ RUST_LIBDEPS = $(LIBDEPS) $(LIBPROC_MACRO_INTERNAL)
 crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(RUST_LIBDEPS) $(rust.prev)
 	@$(call LINK_PROGRESS,$(INDEX.rust),start)
 	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
-	  $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) $(LIBPROC_MACRO_INTERNAL) $(LIBFORMAT_PARSER) $(BACKENDLIBS)
+	  $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) $(CRAB1_LIBS) $(LIBPROC_MACRO_INTERNAL) $(LIBFORMAT_PARSER) $(BACKENDLIBS)
 	@$(call LINK_PROGRESS,$(INDEX.rust),end)
 
 # Build hooks.
-- 
2.34.1

Inline 'gcc/rust/Make-lang.in:RUST_LIBDEPS' (was: [PATCH 006/125] gccrs: Add 'gcc/rust/Make-lang.in:LIBFORMAT_PARSER')

[Thomas Schwinge]

Hi!

On 2024-08-01T16:56:02+0200, Arthur Cohen  wrote:
> --- a/gcc/rust/Make-lang.in
> +++ b/gcc/rust/Make-lang.in
> @@ -212,6 +212,9 @@ RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS)
>  rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
>  
>  LIBPROC_MACRO_INTERNAL = 
> ../libgrust/libproc_macro_internal/libproc_macro_internal.a
> +LIBFORMAT_PARSER = rust/libformat_parser.a
> +
> +RUST_LIBDEPS = $(LIBDEPS) $(LIBPROC_MACRO_INTERNAL) $(LIBFORMAT_PARSER)
>  
>  
>  RUST_LIBDEPS = $(LIBDEPS) $(LIBPROC_MACRO_INTERNAL)

That must've been a mis-merge; my GCC/Rust master branch original of this
commit (as part of <https://github.com/Rust-GCC/gccrs/pull/2947>
"Move 'libformat_parser' build into the GCC build directory, and into libgrust")
didn't include a bogus second definition of 'RUST_LIBDEPS'.  I've pushed
to trunk branch commit aab9f33ed1f1b92444a82eb3ea5cab1048593791
"Inline 'gcc/rust/Make-lang.in:RUST_LIBDEPS'", see attached -- this
commit apparently had been omitted from the 2024-08-01 upstream
submission.


Grüße
 Thomas


>From aab9f33ed1f1b92444a82eb3ea5cab1048593791 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 28 Feb 2024 23:06:25 +0100
Subject: [PATCH] Inline 'gcc/rust/Make-lang.in:RUST_LIBDEPS'

..., also fixing up an apparently mis-merged
commit 2340894554334a310b891a1d9e9d5e3f502357ac
"gccrs: Add 'gcc/rust/Make-lang.in:LIBFORMAT_PARSER'", which was adding a bogus
second definition of 'RUST_LIBDEPS'.

	gcc/rust/
	* Make-lang.in (RUST_LIBDEPS): Inline into all users.
---
 gcc/rust/Make-lang.in | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
index c3be5f9d81b..aed9a998c80 100644
--- a/gcc/rust/Make-lang.in
+++ b/gcc/rust/Make-lang.in
@@ -226,13 +226,8 @@ rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
 LIBPROC_MACRO_INTERNAL = ../libgrust/libproc_macro_internal/libproc_macro_internal.a
 LIBFORMAT_PARSER = ../libgrust/libformat_parser/debug/liblibformat_parser.a
 
-RUST_LIBDEPS = $(LIBDEPS) $(LIBPROC_MACRO_INTERNAL) $(LIBFORMAT_PARSER)
-
-
-RUST_LIBDEPS = $(LIBDEPS) $(LIBPROC_MACRO_INTERNAL)
-
 # The compiler itself is called crab1
-crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(RUST_LIBDEPS) $(rust.prev)
+crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBDEPS) $(LIBPROC_MACRO_INTERNAL) $(LIBFORMAT_PARSER) $(rust.prev)
 	@$(call LINK_PROGRESS,$(INDEX.rust),start)
 	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
 	  $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) $(CRAB1_LIBS) $(LIBPROC_MACRO_INTERNAL) $(LIBFORMAT_PARSER) $(BACKENDLIBS)
-- 
2.34.1

Re: Linking commits to PRs/MRs

[Thomas Schwinge]

Hi!

On 2024-10-23T17:33:38+0100, Jonathan Wakely  wrote:
> On Wed, 23 Oct 2024 at 16:14, Sam James  wrote:
>> I think we want a way to link commits to any possible reviews or
>> discussions on the forge (*).
>>
>> freedesktop.org projects use 'Part-of' in each commit as a trailer
>> linking to the relevant Pull Request (PR) / Merge Request (MR). I don't
>> know what tooling handles this or if it's built-in to gitlab.
>
> e.g.  Part-of:  at
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/ebd67382604d0b7bddf2ebd2aa824a272e8e9bb2
>
> That's just built in to gitlab and also forgejo, e.g.
> https://forge.sourceware.org/redi/gcc/pulls/1#issuecomment-48
> Any text in that form in a commit msg or issue comment will get linked.

> I can see that being a problem. We have hundreds, if not thousands, of
> commits where the message refers to a Bugzilla bug as #1234 which will now
> "magically" link to an issue or pr in a Forgejo repo, but those IDs are
> completely unrelated to the Bugzilla IDs.

Right.  I assume we have to consider any unadorned '#N', 'PRNNN',
'PR COMPONENT/NNN' (have to check the exact patterns) to be "owned" by
GCC: Bugzilla, and that's not going to change any time soon.  Therefore,
we have to teach  to only auto-link the
scoped ones (like,
?), and
leave all unadorned others alone (or rather-link them to what's currently
expected in GCC: Bugzilla.)


> We should ask the gccrs devs to
> stop using Issue #2514 to refer to issues in their external github repo.
> They could use Rust-GCC/gccrs#1234 instead, which won't refer to some
> arbitrary #1234 in an unrelated repo. e.g. for gccgo the commits include
> things like "Fixes golang/go#33739" which is fine, the ID is scoped so
> won't link to the wrong thing.

I've filed 
"[meta] Enforce scoped Rust-GCC/gccrs#NNN instead of unadorned #NNN in Git 
commit logs".


> There's a feature request for Forgejo to support custom auto-link:
> https://codeberg.org/forgejo/forgejo/issues/3274
> That would allow us to make rNN- and similar GCC conventions work from
> commit messages.


Grüße
 Thomas

gccrs: Remove unused files 'gcc/rust/typecheck/rust-hir-type-check-toplevel.{cc,h}' (was: [PATCH] gccrs: Remove unused files)

[Thomas Schwinge]

Hi!

On 2024-12-01T21:17:39-0500, Owen Avery  wrote:
> These files only exist upstream, and were presumably either never
> removed upstream or accidentally upstreamed despite being removed
> downstream.
>
> gcc/rust/ChangeLog:
>
>   * typecheck/rust-hir-type-check-toplevel.cc: Removed.
>   * typecheck/rust-hir-type-check-toplevel.h: Removed.

Confirmed: something went wrong during upstreaming of
"Refactor TypeResolution to be a simple query based system" -- but no
harm done at all.  I'd come up with the same patch just a week ago.  ;-)
I've added a bit more context to your Git commit log, and then pushed to
trunk branch in commit 8173d0a4b75ae2b25e9ed8b4ed8bdc39c3438560
"gccrs: Remove unused files 
'gcc/rust/typecheck/rust-hir-type-check-toplevel.{cc,h}'",
see attached.  


Grüße
 Thomas


>From 8173d0a4b75ae2b25e9ed8b4ed8bdc39c3438560 Mon Sep 17 00:00:00 2001
From: Owen Avery 
Date: Sun, 1 Dec 2024 21:17:39 -0500
Subject: [PATCH] gccrs: Remove unused files
 'gcc/rust/typecheck/rust-hir-type-check-toplevel.{cc,h}'

These files only still exist upstream; they should have been removed as
part of commit 104cc285533e742726ae18a7d3d4f384dd20c350
"gccrs: Refactor TypeResolution to be a simple query based system".

gcc/rust/ChangeLog:

	* typecheck/rust-hir-type-check-toplevel.cc: Removed.
	* typecheck/rust-hir-type-check-toplevel.h: Removed.

Signed-off-by: Owen Avery 
Co-authored-by: Thomas Schwinge 
---
 .../typecheck/rust-hir-type-check-toplevel.cc | 378 --
 .../typecheck/rust-hir-type-check-toplevel.h  |  56 ---
 2 files changed, 434 deletions(-)
 delete mode 100644 gcc/rust/typecheck/rust-hir-type-check-toplevel.cc
 delete mode 100644 gcc/rust/typecheck/rust-hir-type-check-toplevel.h

diff --git a/gcc/rust/typecheck/rust-hir-type-check-toplevel.cc b/gcc/rust/typecheck/rust-hir-type-check-toplevel.cc
deleted file mode 100644
index 8224afb4b684..
--- a/gcc/rust/typecheck/rust-hir-type-check-toplevel.cc
+++ /dev/null
@@ -1,378 +0,0 @@
-// Copyright (C) 2020-2024 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
-// <http://www.gnu.org/licenses/>.
-
-#include "rust-hir-type-check-toplevel.h"
-#include "rust-hir-type-check-enumitem.h"
-#include "rust-hir-type-check-type.h"
-#include "rust-hir-type-check-expr.h"
-#include "rust-hir-type-check-pattern.h"
-#include "rust-hir-type-check-implitem.h"
-
-namespace Rust {
-namespace Resolver {
-
-TypeCheckTopLevel::TypeCheckTopLevel () : TypeCheckBase () {}
-
-void
-TypeCheckTopLevel::Resolve (HIR::Item &item)
-{
-  rust_assert (item.get_hir_kind () == HIR::Node::BaseKind::VIS_ITEM);
-  HIR::VisItem &vis_item = static_cast (item);
-
-  TypeCheckTopLevel resolver;
-  vis_item.accept_vis (resolver);
-}
-
-void
-TypeCheckTopLevel::visit (HIR::TypeAlias &alias)
-{
-  TyTy::BaseType *actual_type
-= TypeCheckType::Resolve (alias.get_type_aliased ().get ());
-
-  context->insert_type (alias.get_mappings (), actual_type);
-
-  for (auto &where_clause_item : alias.get_where_clause ().get_items ())
-{
-  ResolveWhereClauseItem::Resolve (*where_clause_item.get ());
-}
-}
-
-void
-TypeCheckTopLevel::visit (HIR::TupleStruct &struct_decl)
-{
-  std::vector substitutions;
-  if (struct_decl.has_generics ())
-resolve_generic_params (struct_decl.get_generic_params (), substitutions);
-
-  for (auto &where_clause_item : struct_decl.get_where_clause ().get_items ())
-{
-  ResolveWhereClauseItem::Resolve (*where_clause_item.get ());
-}
-
-  std::vector fields;
-  size_t idx = 0;
-  for (auto &field : struct_decl.get_fields ())
-{
-  TyTy::BaseType *field_type
-	= TypeCheckType::Resolve (field.get_field_type ().get ());
-  TyTy::StructFieldType *ty_field
-	= new TyTy::StructFieldType (field.get_mappings ().get_hirid (),
- std::to_string (idx), field_type,
- field.get_locus ());
-  fields.push_back (ty_field);
-  context->insert_type (field.get_mappings (), ty_field->get_field_type ());
-  idx++;
-}
-
-  // get the path
-  const CanonicalPath *canonical_path = nullptr;
-  bool ok = mappings->lookup_canonical_path (
-struct_decl.get_mappings ().get_nodeid (), &canon

Re: Rust: Work around 'error[E0658]: `let...else` statements are unstable'

[Thomas Schwinge]

Hi Arthur!

On 2024-11-25T11:24:08+0100, Arthur Cohen  wrote:
> Thanks, this patch (and your other one on the matter) looks good

Oh, wow -- I passed the first non-trivial Rust programming I've done!
:-D ;-)

> but I 
> have a slight issue with it. We had previously done something similar to 
> adapt to Rust 1.72 when we originally reused the format_args parser:
>
> https://github.com/Rust-GCC/gccrs/pull/2964
>
> This was later reverted because a GSoC student needed some nightly 
> features. I would rather re-apply this entire patch, lower our Rust 
> version requirement to 1.49, and upstream the fixes as part of our next 
> upstreaming period. What do you think about this?
>
> There are a couple more fixes to go from 1.72 to 1.49, and the 
> `String::leak` method is also slightly easier to use.
>
> Let me know and I'm happy to reapply the PR.

Hmm, in terms of incremental progress, to resolve one real issue in my
(and others') testing of upstream GCC trunk, would it be OK if I push my
two patches now, and then we later extend (or even revert) them as
necessary for continued GCC/Rust upstreaming?  (..., while keeping the
tree buildable with old 'rustc'/'cargo'.)


Grüße
 Thomas


> On 11/23/24 9:09 PM, Thomas Schwinge wrote:
>> Hi!
>> 
>> On 2024-08-01T16:56:01+0200, Arthur Cohen  wrote:
>>> Compile libformat_parser and link to it.
>> 
>>> --- /dev/null
>>> +++ b/libgrust/libformat_parser/generic_format_parser/src/lib.rs
>>> @@ -0,0 +1,1102 @@
>>> +[...]
>>> +let Some(unescaped) = unescape_string(snippet) else {
>>> +return InputStringKind::NotALiteral;
>>> +};
>>> +[...]
>> 
>> OK to push the attached
>> "Rust: Work around 'error[E0658]: `let...else` statements are unstable'"?
>> Builds and tests fine, but I don't know if this code path is actually
>> exercised at this time, so please check carefully; as you know I'm not
>> actually a Rust programmer (yet).  ;-)
>> 
>> 
>> Grüße
>>   Thomas

Rust: libformat_parser: Lower minimum Rust version to 1.49 (was: Rust: Work around 'error[E0658]: `let...else` statements are unstable')

[Thomas Schwinge]

Hi!

On 2024-12-05T13:37:13+0100, Arthur Cohen  wrote:
> On 12/4/24 13:35, Thomas Schwinge wrote:
>> On 2024-11-25T11:24:08+0100, Arthur Cohen  wrote:
>>> [...] We had previously done something similar to
>>> adapt to Rust 1.72 when we originally reused the format_args parser:
>>>
>>> https://github.com/Rust-GCC/gccrs/pull/2964

(By the way: I'm confused why I didn't see that one/this existing
GCC/Rust commit, before attempting to fix this myself...  Anyway -- at
least I did a little bit of Rust programming this way.)  ;-)

Anyway:

> In that case, could you instead add the commit mentioned in the PR so we 
> don't need to revert it or change it? But instead we'd just be 
> upstreaming this commit slightly earlier. My thinking is we do the 
> following:
>
> 1. Push commit 039624951f9 upstream, which lowers the required Rust 
> version to 1.49

Pushed to trunk branch commit 67a164eb1da6dba9fb789ae768beebbaa3be37de
"Rust: libformat_parser: Lower minimum Rust version to 1.49", see
attached.

> 2. Send a PR to our github repo with that commit so we merge it in our 
> dev repo as well

That's not actually necessary, I think?  Because:

> 3. This way once we rebase our branch to send it upstream, this commit 
> will just be skipped

This will happen "automatically"?


Grüße
 Thomas


> I think the commit should apply on both our dev repo and our version of 
> gccrs which is upstream.
>
> Feel free to take ownership of it - the changes are extremely similar, 
> the only difference is the use of a trait extension for String::leak() 
> instead of a dedicated leak_string() function.
>
> How do you feel about that? Would that be okay?
>
> Best,
>
> Arthur


>From 67a164eb1da6dba9fb789ae768beebbaa3be37de Mon Sep 17 00:00:00 2001
From: Arthur Cohen 
Date: Tue, 23 Apr 2024 14:13:21 +0200
Subject: [PATCH] Rust: libformat_parser: Lower minimum Rust version to 1.49

libgrust/ChangeLog:

	* libformat_parser/Cargo.toml: Change Rust edition from 2021 to 2018.
	* libformat_parser/generic_format_parser/Cargo.toml: Likewise.
	* libformat_parser/generic_format_parser/src/lib.rs: Remove usage of
	then-unstable std features and language constructs.
	* libformat_parser/src/lib.rs: Likewise, plus provide extension trait
	for String::leak.
---
 libgrust/libformat_parser/Cargo.toml  |  2 +-
 .../generic_format_parser/Cargo.toml  |  2 +-
 .../generic_format_parser/src/lib.rs  | 41 ++-
 libgrust/libformat_parser/src/lib.rs  | 10 +
 4 files changed, 42 insertions(+), 13 deletions(-)

diff --git a/libgrust/libformat_parser/Cargo.toml b/libgrust/libformat_parser/Cargo.toml
index 0fcfa3e89a4c..3c214915d31e 100644
--- a/libgrust/libformat_parser/Cargo.toml
+++ b/libgrust/libformat_parser/Cargo.toml
@@ -1,7 +1,7 @@
 [package]
 name = "libformat_parser"
 version = "0.1.0"
-edition = "2021"
+edition = "2018"
 
 [workspace]
 
diff --git a/libgrust/libformat_parser/generic_format_parser/Cargo.toml b/libgrust/libformat_parser/generic_format_parser/Cargo.toml
index 34577038cbed..224ad6826ec8 100644
--- a/libgrust/libformat_parser/generic_format_parser/Cargo.toml
+++ b/libgrust/libformat_parser/generic_format_parser/Cargo.toml
@@ -1,7 +1,7 @@
 [package]
 name = "generic_format_parser"
 version = "0.1.0"
-edition = "2021"
+edition = "2018"
 
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 
diff --git a/libgrust/libformat_parser/generic_format_parser/src/lib.rs b/libgrust/libformat_parser/generic_format_parser/src/lib.rs
index 8062bf9e5cec..e255bf16908f 100644
--- a/libgrust/libformat_parser/generic_format_parser/src/lib.rs
+++ b/libgrust/libformat_parser/generic_format_parser/src/lib.rs
@@ -505,7 +505,7 @@ impl<'a> Parser<'a> {
 }
 
 pos = peek_pos;
-description = format!("expected `'}}'`, found `{maybe:?}`");
+description = format!("expected `'}}'`, found `{:?}`", maybe);
 } else {
 description = "expected `'}'` but string was terminated".to_owned();
 // point at closing `"`
@@ -690,12 +690,16 @@ impl<'a> Parser<'a> {
 
 // fill character
 if let Some(&(idx, c)) = self.cur.peek() {
-if let Some((_, '>' | '<' | '^')) = self.cur.clone().nth(1) {
-spec.fill = Some(c);
-spec.fill_span = Some(self.span(idx, idx + 1));
-self.cur.next();
+match self.cur.clone().nth(1) {
+Some((_, '>')) | Some((_, '<')) | Some((_, '^')) => {
+spec

Rust: Work around 'error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope' (was: [PATCH 048/125] gccrs: format-args: Start storing string in Rust memory)

[Thomas Schwinge]

Hi!

On 2024-08-01T16:56:44+0200, Arthur Cohen  wrote:
> --- a/libgrust/libformat_parser/src/lib.rs
> +++ b/libgrust/libformat_parser/src/lib.rs

> [...]
> +let rust_string = RustString {
> +len: str.len(),
> +cap: str.capacity(),
> +ptr: str.leak().as_ptr(),
> +};
> [...]

> [...]
> +let RustString { ptr, len, cap } = *s;
> +let s = unsafe { String::from_raw_parts(ptr as *mut u8, len, cap) };
> +let cloned_s = s.clone();
> +
> +// FIXME: Documentation
> +s.leak();
> +
> +let rust_string = RustString {
> +len: cloned_s.len(),
> +cap: cloned_s.capacity(),
> +ptr: cloned_s.leak().as_ptr(),
> +};
> [...]

OK to push the attached
"Rust: Work around 'error[E0599]: no method named `leak` found for struct 
`std::string::String` in the current scope'"?
Builds and tests fine, but I don't know if this code path is actually
exercised at this time, so please check carefully; as you know I'm not
actually a Rust programmer (yet).  ;-)


Grüße
 Thomas


>From 8d4821dabcf4663e51c7db859801837710038821 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 3 Aug 2024 16:39:17 +0200
Subject: [PATCH] Rust: Work around 'error[E0599]: no method named `leak` found
 for struct `std::string::String` in the current scope'

Compiling with Debian GNU/Linux 12 (bookworm) packages:

$ apt-cache madison cargo rustc
 cargo | 0.66.0+ds1-1 | http://deb.debian.org/debian bookworm/main ppc64el Packages
 cargo | 0.66.0+ds1-1 | http://deb.debian.org/debian bookworm/main Sources
 rustc | 1.63.0+dfsg1-2 | http://deb.debian.org/debian bookworm/main ppc64el Packages
 rustc | 1.63.0+dfsg1-2 | http://deb.debian.org/debian bookworm/main Sources

..., we run into:

   Compiling libformat_parser v0.1.0 ([...]/source-gcc/libgrust/libformat_parser)
error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope
   --> src/lib.rs:396:18
|
396 | ptr: str.leak().as_ptr(),
|   method not found in `std::string::String`

error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope
   --> src/lib.rs:434:7
|
434 | s.leak();
|    method not found in `std::string::String`

error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope
   --> src/lib.rs:439:23
|
439 | ptr: cloned_s.leak().as_ptr(),
|    method not found in `std::string::String`

Locally replace 1.72.0+ method 'leak' for struct 'std::string::String'.

	libgrust/
	* libformat_parser/src/lib.rs: Work around 'error[E0599]:
	no method named `leak` found for struct `std::string::String` in the current scope'.
---
 libgrust/libformat_parser/src/lib.rs | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libgrust/libformat_parser/src/lib.rs b/libgrust/libformat_parser/src/lib.rs
index 84fac38e224d..28f6a6a62b62 100644
--- a/libgrust/libformat_parser/src/lib.rs
+++ b/libgrust/libformat_parser/src/lib.rs
@@ -5,6 +5,13 @@
 
 use std::ffi::CStr;
 
+// Local replacement for 1.72.0+ method 'leak' for struct 'std::string::String',
+// <https://doc.rust-lang.org/1.72.0/src/alloc/string.rs.html#1853>
+fn leak_string<'a>(s: String) -> &'a mut str {
+let slice = s.into_bytes().leak();
+unsafe { std::str::from_utf8_unchecked_mut(slice) }
+}
+
 trait IntoFFI {
 fn into_ffi(self) -> T;
 }
@@ -393,7 +400,7 @@ pub extern "C" fn collect_pieces(
 let rust_string = RustString {
 len: str.len(),
 cap: str.capacity(),
-ptr: str.leak().as_ptr(),
+ptr: leak_string(str).as_ptr(),
 };
 
 FormatArgsHandle(piece_slice, rust_string)
@@ -431,12 +438,12 @@ pub extern "C" fn clone_pieces(
 let cloned_s = s.clone();
 
 // FIXME: Documentation
-s.leak();
+leak_string(s);
 
 let rust_string = RustString {
 len: cloned_s.len(),
 cap: cloned_s.capacity(),
-ptr: cloned_s.leak().as_ptr(),
+ptr: leak_string(cloned_s).as_ptr(),
 };
 
 FormatArgsHandle(piece_slice, rust_string)
-- 
2.34.1

Re: Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

[Thomas Schwinge]

Hi!

On 2025-03-17T20:03:48+, Iain Sandoe via Gcc  wrote:
>> On 17 Mar 2025, at 19:43, Toon Moene  wrote:
>> 
>> I was eager to try the new rust updates ...
>> 
>> But I got this:
>> 
>> error[E0554]: `#![feature]` may not be used on the stable release channel
>>  --> src/lib.rs:19:1
>>   |
>> 19 | #![feature(extern_types)]
>>   | ^
>> 
>> For more information about this error, try `rustc --explain E0554`.
>> error: could not compile `ffi-polonius` (lib) due to 1 previous error
>> [/home/toon/compilers/gcc/gcc/rust/Make-lang.in:506: rust/libffi_polonius.a] 
>> Error 101

This should've been resolved via 
"[15 regression] Rust fails to build (build failure: error[E0554]: 
`#![feature]` may not be used on the stable release channel)".

>> Am I the only one seeing this ?
>
> No, if I allow the cargo download to progress (another issue in itself)

This shouldn've been resolved via 
"[15 regression] Rust bootstrap fails with cargo trying to download polonius 
crates".

> I hit this too on Darwin.

Thanks for testing!


Grüße
 Thomas

[PUSHED] Disable parallel testing for 'rust/compile/nr2/compile.exp' [PR119508]

[Thomas Schwinge]

..., using the standard idiom.  This '*.exp' file doesn't adhere to the
parallel testing protocol as defined in 'gcc/testsuite/lib/gcc-defs.exp'.

This also restores proper behavior for '*.exp' files executing after (!) this
one, which erroneously caused hundreds or even thousands of individual test
cases get duplicated vs. skipped, randomly, depending on the '-jN' level.

PR testsuite/119508
gcc/testsuite/
* rust/compile/nr2/compile.exp: Disable parallel testing.
---
 gcc/testsuite/rust/compile/nr2/compile.exp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gcc/testsuite/rust/compile/nr2/compile.exp 
b/gcc/testsuite/rust/compile/nr2/compile.exp
index 4d91dd004a3..9e15cdd7253 100644
--- a/gcc/testsuite/rust/compile/nr2/compile.exp
+++ b/gcc/testsuite/rust/compile/nr2/compile.exp
@@ -19,6 +19,15 @@
 # Load support procs.
 load_lib rust-dg.exp
 
+# These tests don't run runtest_file_p consistently if it
+# doesn't return the same values, so disable parallelization
+# of this *.exp file.  The first parallel runtest to reach
+# this will run all the tests serially.
+if ![gcc_parallel_test_run_p compile] {
+return
+}
+gcc_parallel_test_enable 0
+
 # Initialize `dg'.
 dg-init
 
@@ -136,3 +145,5 @@ namespace eval rust-nr2-ns {
 
 # All done.
 dg-finish
+
+gcc_parallel_test_enable 1
-- 
2.34.1

Re: [COMMITTED 136/145] gccrs: Fix nightly rustc warnings

[Thomas Schwinge]

Hi Arthur!

On 2025-03-22T15:48:18+0100, Arthur Cohen  wrote:
> Thanks for testing that commit. I think a partial revert is not
> necessary, as I'm currently
> working on our milestone to make all Rust code compile with a Rust
> 1.49 toolchain.
>
> I think pushing a partial revert upstream would just create some
> confusion when the
> correct version of the code which will fully compile with Rust 1.49
> will be on our dev repo
> in a few days or weeks. I'm hoping to upstream it on Monday or next
> Monday if I cannot
> finish it in time.
>
> I feel like holding on on this for a few days would make the process
> easier? What do you
> think?

Works for me; I'll keep this local until then.


Grüße
 Thomas


> On Sat, 22 Mar 2025 at 15:43, Thomas Schwinge  wrote:
>>
>> Hi!
>>
>> On 2025-03-17T16:33:34+0100, arthur.co...@embecosm.com wrote:
>> > From: Kushal Pal 
>> >
>> > libgrust/ChangeLog:
>> >
>> >   * libformat_parser/Cargo.toml:
>> >   Used crate-type instead of depricated crate_type.
>> >   * libformat_parser/generic_format_parser/src/lib.rs:
>> >   Remove dead code.
>> >   * libformat_parser/src/lib.rs: Likewise.
>> >
>> > Signed-off-by: Kushal Pal 
>>
>> This isn't "dead code" on a Debian "bookworm" system where I'm testing
>> with:
>>
>> $ rustc --version
>> rustc 1.63.0
>>
>> With this commit in place, I get:
>>
>> [...]
>> Making all in libformat_parser
>> make[3]: Entering directory '[...]/build-gcc/libgrust/libformat_parser'
>> cargo \
>>   --config [...]/source-gcc/libgrust/libformat_parser/.cargo/config \
>>   build \
>> --offline \
>> --target-dir . \
>> --manifest-path 
>> [...]/source-gcc/libgrust/libformat_parser/Cargo.toml \
>> # FIXME: Not always '--release', right?
>>Compiling generic_format_parser v0.1.0 
>> ([...]/source-gcc/libgrust/libformat_parser/generic_format_parser)
>> error[E0658]: use of unstable library feature 'is_some_with'
>>--> generic_format_parser/src/lib.rs:615:34
>> |
>> 615 | ...   .is_some_and(is_id_start)
>> |^^^
>> |
>> = note: see issue #93050 
>> <https://github.com/rust-lang/rust/issues/93050> for more information
>>
>> error[E0631]: type mismatch in function arguments
>>--> generic_format_parser/src/lib.rs:615:46
>> |
>> 17  | fn is_id_start(c: char) -> bool {
>> | --- found signature of `fn(char) -> _`
>> ...
>> 615 | .is_some_and(is_id_start)
>> |  --- ^^^ expected 
>> signature of `for<'r> fn(&'r char) -> _`
>> |  |
>> |  required by a bound introduced by 
>> this call
>> |
>> note: required by a bound in `Optionis_some_and`
>>
>> Some errors have detailed explanations: E0631, E0658.
>> For more information about an error, try `rustc --explain E0631`.
>> error: could not compile `generic_format_parser` due to 2 previous errors
>> make[3]: *** [Makefile:431: debug/liblibformat_parser.a] Error 101
>> make[3]: Target 'all' not remade because of errors.
>> make[3]: Leaving directory '[...]/build-gcc/libgrust/libformat_parser'
>> [...]
>>
>> With this commit reverted, the build again succeeds, with good test
>> results.  May I, therefore, push a (partial, I suppose?) 'git revert' of
>> this commit?
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> > ---
>> >  libgrust/libformat_parser/Cargo.toml |  2 +-
>> >  .../generic_format_parser/src/lib.rs | 16 
>> >  libgrust/libformat_parser/src/lib.rs | 14 --
>> >  3 files changed, 1 insertion(+), 31 deletions(-)
>> >
>> > diff --git a/libgrust/libformat_parser/Cargo.toml 
>> > b/libgrust/libformat_parser/Cargo.toml
>> > index 3c214915d31..39c017d249b 100644
>> > --- a/libgrust/libformat_parser/Cargo.toml
>> > +++ b/libgrust/libformat_parser/Cargo.toml
>> > @@ -14,7 +14,7 @@ libc = "0.2"
>> >  gener

Re: [COMMITTED 136/145] gccrs: Fix nightly rustc warnings

[Thomas Schwinge]

Hi!

On 2025-03-17T16:33:34+0100, arthur.co...@embecosm.com wrote:
> From: Kushal Pal 
>
> libgrust/ChangeLog:
>
>   * libformat_parser/Cargo.toml:
>   Used crate-type instead of depricated crate_type.
>   * libformat_parser/generic_format_parser/src/lib.rs:
>   Remove dead code.
>   * libformat_parser/src/lib.rs: Likewise.
>
> Signed-off-by: Kushal Pal 

This isn't "dead code" on a Debian "bookworm" system where I'm testing
with:

$ rustc --version
rustc 1.63.0

With this commit in place, I get:

[...]
Making all in libformat_parser
make[3]: Entering directory '[...]/build-gcc/libgrust/libformat_parser'
cargo \
  --config [...]/source-gcc/libgrust/libformat_parser/.cargo/config \
  build \
--offline \
--target-dir . \
--manifest-path [...]/source-gcc/libgrust/libformat_parser/Cargo.toml \
# FIXME: Not always '--release', right?
   Compiling generic_format_parser v0.1.0 
([...]/source-gcc/libgrust/libformat_parser/generic_format_parser)
error[E0658]: use of unstable library feature 'is_some_with'
   --> generic_format_parser/src/lib.rs:615:34
|
615 | ...   .is_some_and(is_id_start)
|^^^
|
= note: see issue #93050 
 for more information

error[E0631]: type mismatch in function arguments
   --> generic_format_parser/src/lib.rs:615:46
|
17  | fn is_id_start(c: char) -> bool {
| --- found signature of `fn(char) -> _`
...
615 | .is_some_and(is_id_start)
|  --- ^^^ expected 
signature of `for<'r> fn(&'r char) -> _`
|  |
|  required by a bound introduced by 
this call
|
note: required by a bound in `Optionis_some_and`

Some errors have detailed explanations: E0631, E0658.
For more information about an error, try `rustc --explain E0631`.
error: could not compile `generic_format_parser` due to 2 previous errors
make[3]: *** [Makefile:431: debug/liblibformat_parser.a] Error 101
make[3]: Target 'all' not remade because of errors.
make[3]: Leaving directory '[...]/build-gcc/libgrust/libformat_parser'
[...]

With this commit reverted, the build again succeeds, with good test
results.  May I, therefore, push a (partial, I suppose?) 'git revert' of
this commit?


Grüße
 Thomas


> ---
>  libgrust/libformat_parser/Cargo.toml |  2 +-
>  .../generic_format_parser/src/lib.rs | 16 
>  libgrust/libformat_parser/src/lib.rs | 14 --
>  3 files changed, 1 insertion(+), 31 deletions(-)
>
> diff --git a/libgrust/libformat_parser/Cargo.toml 
> b/libgrust/libformat_parser/Cargo.toml
> index 3c214915d31..39c017d249b 100644
> --- a/libgrust/libformat_parser/Cargo.toml
> +++ b/libgrust/libformat_parser/Cargo.toml
> @@ -14,7 +14,7 @@ libc = "0.2"
>  generic_format_parser = { path = "generic_format_parser" }
>  
>  [lib]
> -crate_type = ["staticlib", "rlib"]
> +crate-type = ["staticlib", "rlib"]
>  
>  [[bin]]
>  name = "format_parser_test"
> diff --git a/libgrust/libformat_parser/generic_format_parser/src/lib.rs 
> b/libgrust/libformat_parser/generic_format_parser/src/lib.rs
> index e255bf16908..25f6b0ead17 100644
> --- a/libgrust/libformat_parser/generic_format_parser/src/lib.rs
> +++ b/libgrust/libformat_parser/generic_format_parser/src/lib.rs
> @@ -22,22 +22,6 @@ fn is_id_continue(c: char) -> bool {
>  unicode_xid::UnicodeXID::is_xid_continue(c)
>  }
>  
> -// Workaround for Ubuntu 18.04. The default Rust package is 1.65 (and 
> unlikely to change I assume?), but the
> -// generic format parser library uses `is_some_and` which was introduced in 
> 1.70. So this is a reimplementation,
> -// directly taken from the standard library sources
> -trait IsSomeAnd {
> -fn is_some_and(self, f: impl FnOnce(T) -> bool) -> bool;
> -}
> -
> -impl IsSomeAnd for Option {
> -fn is_some_and(self, f: impl FnOnce(T) -> bool) -> bool {
> -match self {
> -None => false,
> -Some(x) => f(x),
> -}
> -}
> -}
> -
>  // use rustc_lexer::unescape;
>  pub use Alignment::*;
>  pub use Count::*;
> diff --git a/libgrust/libformat_parser/src/lib.rs 
> b/libgrust/libformat_parser/src/lib.rs
> index 0769577740f..f4670bf9b1f 100644
> --- a/libgrust/libformat_parser/src/lib.rs
> +++ b/libgrust/libformat_parser/src/lib.rs
> @@ -5,16 +5,6 @@
>  
>  use std::ffi::CStr;
>  
> -trait StringLeakExt {
> -fn leak<'a>(self) -> &'a mut str;
> -}
> -
> -impl StringLeakExt for String {
> -fn leak<'a>(self) -> &'a mut str {
> -Box::leak(self.into_boxed_str())
> -}
> -}
> -
>  trait IntoFFI {
>  fn into_ffi(self) -> T;
>  }
> @@ -98,10 +88,6