Re: Test results for gccrs on Debian unstable ia64
John Paul Adrian Glaubitz writes: > Hi! Hi! > I have started to test gccrs on various targets supported by Debian to see if > there are any portability issues with the code. The first target I have tested > is Debian unstable ia64. Thanks ! > # of expected passes2347 > # of unexpected failures21 > # of expected failures 26 Would it be possible to have the corresponding .log file ? Looks like nearly all execution tests are KO (3 out of 4...). Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable ia64
John Paul Adrian Glaubitz writes: > Hi Marc! > > On 6/2/21 2:41 PM, Marc wrote: >>> # of expected passes2347 >>> # of unexpected failures21 >>> # of expected failures 26 >> >> Would it be possible to have the corresponding .log file ? Looks like >> nearly all execution tests are KO (3 out of 4...). > > Sure, just found the log file. Didn't know that there was one ;). Thanks! Looks like something is missing : ./block_expr1.exe: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory Is libunwind installed ? Not sure why your exe needs it, maybe that's a particularity of ia64? Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable ia64
John Paul Adrian Glaubitz writes: > Hello! > > On 6/2/21 3:08 PM, John Paul Adrian Glaubitz wrote: >>> Is libunwind installed ? Not sure why your exe needs it, maybe that's a >>> particularity of ia64? >> >> Yes, gcc explicitly needs libunwind on ia64 unless it's configured to use >> the internal version. I might be able to fix that myself. > > Addendum: Building with "--with-system-libunwind" fixes the problem for me > (see below). Hi! Thanks for testing this! IIUC, this is an issue on our side, so I'll open an issue. Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable ia64
John Paul Adrian Glaubitz writes: > Hi Marc! > > On 6/2/21 6:58 PM, Marc wrote: >> Thanks for testing this! IIUC, this is an issue on our side, so I'll >> open an issue. > > Let me test a plain GCC build with just C and C++ first to make sure it's > not a general GCC problem on ia64. > > libunwind on ia64 can be a bit tricky sometimes, so it might not be gccrs > which is to be blamed here. Ah, sorry, already opened :). I'll close it if needed ! https://github.com/Rust-GCC/gccrs/issues/474 Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable s390x
John Paul Adrian Glaubitz writes: > Hello! > > Just built gccrs revision 59b417323b25072aff2662f1f54f417f7b7ded61 on Debian > unstable s390x. > > The testsuite fails with the following failures. Attaching the log file. > > Adrian Hi again! looks like all errors here (ICE) are the same as seen on 32-bits debian, see https://github.com/Rust-GCC/gccrs/issues/467 . Thanks for these tests! Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[PING] [PATCH] rust: avoid clobbering LIBS
Hello, Gentle reminder for this simple autoconf patch :) Thanks, Marc
Re: [PING] [PATCH] rust: avoid clobbering LIBS
Richard Biener writes: > On Wed, Aug 28, 2024 at 11:10 AM Marc wrote: >> >> Hello, >> >> Gentle reminder for this simple autoconf patch :) > > OK. > > Note that completely wiping LIBS might remove requirements detected earlier, > like some systems require explicit -lc for example. I would instead not clear > LIBS here and instead allow the possible duplicates through CRAB_LIBS. > YMMV of course. Oh, that's a good remark. I've simply followed this suggestion that was given on #gcc and also took inspiration from gcc/configure.ac that has many instances of clearing LIBS like that. I think I'll merge it like that, unless you see any reason this pattern would cause issue here (top level) and not in gcc/configure. Thank you, Marc
Re: [PATCH][15.2] nr2.0: late: Correctly initialize funny_error member
April 29, 2025 at 10:39 AM, "Andrew Pinski" mailto:pins...@gmail.com?to=%22Andrew%20Pinski%22%20%3Cpinskia%40gmail.com%3E > wrote: > > On Tue, Apr 29, 2025 at 1:26 AM wrote: > > > > > From: Arthur Cohen > > > > Hi everyone, > > > > We noticed inconsistent errors when running name-resolution 2.0 on > > certain files, where an invalid error was triggered and the message was > > from the `funny_ice` error finalizer function we had added as an easter > > egg. We realized yesterday that the undefined value was actually our > > `funny_error` boolean, which is supposed to be set only when resolving > > specific easter eggs `AST::IdentifierExpr`s. > > > > Since `funny_error` is a boolean, it does not get default-initialized in > > the constructor of `Late` - which this patch corrects. > > > > I will be pushing it to trunk directly, but this email specifically > > concerns its port into 15.2. > > > I am not sure if using NSDMI might be a better style here than doing > it in the constructor. > We discussed this before sending the patch but we didn't have any strong arguments for/against any solution. Do you have any? Thanks, Marc
Re: bootstrapping on a new platform - chicken and egg problem
> cargo should be a rust program but without the gccrs > how I am supposed to bootstrap ? Hello! Currently, the Rust frontend can't be bootstraped. You need an existing rustc toolchain (including cargo). Marc
Re: [PATCH] Fix inner attribute parsing
Mark Wielaard writes: > parse_inner_attribute tried to skip the right square token twice. This caused > odd error > messages in case there were multiple inner attributes. This bug masked > another bug in > parse_attr_input where when the (optional) attr input was an assignment to a > literal > the parser failed to skip the literal. > > The existing top_attr.rs testcase relied on the two bugs cancelling each > other out. > Add a new testcase inner_attributes.rs for the first bug. > > Resolves: https://github.com/Rust-GCC/gccrs/issues/510 Hi Mark, Sent to GH: https://github.com/Rust-GCC/gccrs/pull/530 Thanks :) Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] Suppress warning in rust-ast-lower-type.h ASTLowerGenericParam.visit.
Hi, > Translating the AST LifetimeType to the HIR LifetimeType causes a warning: > warning: ‘ltt’ may be used uninitialized Was wondering why this is needed as the switch case covers all enum variants, how can ltt be uninitialized ? I have the same fix locally but was thinking something else was causing the error... Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] Suppress warning in rust-ast-lower-type.h ASTLowerGenericParam.visit.
Mark Wielaard writes: > On Tue, Jun 29, 2021 at 12:47:07AM +0200, Mark Wielaard wrote: >> On Tue, Jun 29, 2021 at 12:06:56AM +0200, Marc wrote: >> > Hi, >> > >> > > Translating the AST LifetimeType to the HIR LifetimeType causes a >> > > warning: >> > > warning: ‘ltt’ may be used uninitialized >> > >> > Was wondering why this is needed as the switch case covers all enum >> > variants, how can ltt be uninitialized ? I have the same fix locally but >> > was thinking something else was causing the error... >> >> LifetimeType is a plain enum, which aren't really their own types, >> they are really just ints with fancy names. We could make them enum >> class, which is a strong type. Then the compiler would know the switch >> really covers all enum (class) variants. But then we have to provide >> the right scope/type everywhere we use them in the code (which might >> be a good idea, but is more typing). > > I just tried to make LifetimeType an enum class and that doesn't help. > So I was wrong. I don't know why the compiler doesn't see this? It > should know since if not all switch cases were covered, -Wswitch > (enabled by -Wall) gives us a warning... So, I don't fully understand > why gcc needs the default gcc_unreachable case. It is what is used in > the rest of the code though. I thought maybe that's a C++ vs C diff, or something caused by the Lifetime being returned by a function call, but I can't reproduce it, so that must be something else: https://godbolt.org/z/sjbcWEqdj Anyway, Philipp wants to have these enum shared between AST and HIR, so this kind of 'if(AST::Foo) t=HIR::Foo' can be removed. I'm still curious about why the warning is raised in this case... Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH 2/2] Remove unused have_more_segments from TypeCheckExpr::resolve_root_path
Mark Wielaard writes: > It isn't necessary to know whether there are more segments while > iteration through the expression segements. Both patches in GH: https://github.com/Rust-GCC/gccrs/pull/537/commits Fixed a small typo in the commit message while creating the PR :) Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: shebang handling
Mark Wielaard writes: > [PATCH 1/2] Handle shebang line, plus any whitespace and comment > [PATCH 2/2] Remove has_shebang flag from AST and HIR Crate classes Pushed to githup: https://github.com/Rust-GCC/gccrs/pull/546 Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: UTF-8 BOM handling
Mark Wielaard writes: > Hi, > > A rust source file can start with a UTF-8 BOM sequence (EF BB > BF). This simply indicates that the file is encoded as UTF-8 (all rust > input is interpreted as asequence of Unicode code points encoded in > UTF-8) so can be skipped before starting real lexing. > > It isn't necessary to keep track of the BOM in the AST or HIR Crate > classes. So I removed the has_utf8bom flag. > > Also included are a couple of simple tests to show we handle the BOM > correctly now. Merged : https://github.com/Rust-GCC/gccrs/pull/552 Marc -- 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
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] Marc -- 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
build...@builder.wildebeest.org writes: > Build Reason: > Blamelist: Philip Herron g++ -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Irust -I../../gccrs/gcc -I../../gccrs/gcc/rust -I../../gccrs/gcc/../include -I../../gccrs/gcc/../libcpp/include -I../../gccrs/gcc/../libcody -I../../gccrs/gcc/../libdecnumber -I../../gccrs/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gccrs/gcc/../libbacktrace -o rust/rust-hir-full-test.o -MT rust/rust-hir-full-test.o -MMD -MP -MF rust/.deps/rust-hir-full-test.TPo -std=c++11 -Wno-unused-parameter -Werror=overloaded-virtual -I ../../gccrs/gcc/rust -I ../../gccrs/gcc/rust/lex -I ../../gccrs/gcc/rust/parse -I ../../gccrs/gcc/rust/ast -I ../../gccrs/gcc/rust/analysis -I ../../gccrs/gcc/rust/backend -I ../../gccrs/gcc/rust/expand -I ../../gccrs/gcc/rust/hir/tree -I ../ ../gccrs/gcc/rust/hir -I ../../gccrs/gcc/rust/resolve -I ../../gccrs/gcc/rust/util -I ../../gccrs/gcc/rust/typecheck -I ../../gccrs/gcc/rust/lint ../../gccrs/gcc/rust/hir/tree/rust-hir-full-test.cc command timed out: 1200 seconds without output running [b'make', b'-j4'], attempting to kill process killed by signal 9 program finished with exit code -1 elapsedTime=1425.203557 Looks suspicious. Is it possible that the VM got stuck ? Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] Remove lambda iterators in various HIR classes
David Faust via Gcc-rust writes: > On 10/8/21 10:45, David Faust via Gcc-rust wrote: >> This patch removes the lambda iterators used in various HIR objects. >> These iterators make interacting with the IR for static analysis more >> difficult. Instead, get_X () helpers are added for accessing elements, >> and uses of the iterators replaced with for loops. >> The following objects are adjusted in this patch: >> - HIR::TupleExpr >> - HIR::StructExprField >> - HIR::StructStruct >> - HIR::TupleStruct >> Fixes: #704, #705, #706, #707 > > This also adjusts HIR::ArrayElemsValues, fixing #703. > Must have lost those lines in the patch prep, sorry. Hi David, Thank you for this patch ! As gccrs is relying on github, feel free to open a pull request directly (if you can/want). I took care of it (and added the #703 while I was at it), and you can see that there are some small issues with the indentation: https://github.com/Rust-GCC/gccrs/pull/726/checks?check_run_id=3841896345 You need to be logged-in to see the results. If you don't have an account, you can still apply clang-format by hand :) Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char' type
Mark Wielaard writes: > https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=no-Rust-old > if someone wants to push that, to merge for a v4. Sorry, missed that part, taking care of merging it right now :) https://github.com/Rust-GCC/gccrs/pull/1649 Thanks, Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
