Re: [COMMITTED] gccrust_debian_i386_builder: Add collapseRequests=True
June 9, 2025 at 12:32 PM, "Philip Herron" mailto:herron.phi...@googlemail.com?to=%22Philip%20Herron%22%20%3Cherron.philip%40googlemail.com%3E > wrote: > > Sounds good. Marc (dkm) is going to do a big push later tonight so > this will help handle that. > Yes... and this change has been motivated by the big push from Thomas yesterday evening :'D Thanks! Marc
Re: [PATCH] Add support for const bool and const float
Hey!
Looks like tests are not OK, at least in the github action. Can't test but
maybe you can confirm this issue ?
# of unexpected failures14
Marc
August 15, 2021 9:55 PM, "Mark Wielaard" wrote:
> Handle BOOL and FLOAT in ConstFoldExpr::visit (HIR::LiteralExpr) to
> make it possible to create const bool, f32 and f64 constants. Add a
> new testcase "primconsts.rs". Not yet handled are const char and &str
> types.
> ---
> gcc/rust/typecheck/rust-hir-const-fold.h | 30
> .../rust/compile/torture/primconsts.rs | 72 +++
> 2 files changed, 102 insertions(+)
> create mode 100644 gcc/testsuite/rust/compile/torture/primconsts.rs
>
> diff --git a/gcc/rust/typecheck/rust-hir-const-fold.h
> b/gcc/rust/typecheck/rust-hir-const-fold.h
> index f6c66163fc1..8efbb183403 100644
> --- a/gcc/rust/typecheck/rust-hir-const-fold.h
> +++ b/gcc/rust/typecheck/rust-hir-const-fold.h
> @@ -315,6 +315,36 @@ public:
> }
> return;
>
> + case HIR::Literal::BOOL: {
> + bool bval = literal_value->as_string ().compare ("true") == 0;
> + folded = ctx->get_backend ()->boolean_constant_expression (bval);
> + }
> + return;
> +
> + case HIR::Literal::FLOAT: {
> + mpfr_t fval;
> + if (mpfr_init_set_str (fval, literal_value->as_string ().c_str (), 10,
> + MPFR_RNDN)
> + != 0)
> + {
> + rust_fatal_error (expr.get_locus (),
> + "bad floating-point number in literal");
> + return;
> + }
> +
> + TyTy::BaseType *tyty = nullptr;
> + if (!tyctx->lookup_type (expr.get_mappings ().get_hirid (), &tyty))
> + {
> + rust_fatal_error (expr.get_locus (),
> + "did not resolve type for this literal expr");
> + return;
> + }
> +
> + Btype *type = ConstFoldType::fold (tyty, ctx->get_backend ());
> + folded = ctx->get_backend ()->float_constant_expression (type, fval);
> + }
> + return;
> +
> /* handle other literals */
>
> default:
> diff --git a/gcc/testsuite/rust/compile/torture/primconsts.rs
> b/gcc/testsuite/rust/compile/torture/primconsts.rs
> new file mode 100644
> index 000..bcf9456d059
> --- /dev/null
> +++ b/gcc/testsuite/rust/compile/torture/primconsts.rs
> @@ -0,0 +1,72 @@
> +const TRUE: bool = true;
> +const FALSE: bool = !TRUE;
> +
> +const U8ZERO: u8 = 0;
> +const U8ONE: u8 = U8ZERO + 1;
> +const U16ZERO: u16 = 0;
> +const U16ONE: u16 = U16ZERO + 1;
> +const U32ZERO: u32 = 0;
> +const U32ONE: u32 = U32ZERO + 1;
> +const U64ZERO: u64 = 0;
> +const U64ONE: u64 = U64ZERO + 1;
> +const U128ZERO: u128 = 0;
> +const U128ONE: u128 = U128ZERO + 1;
> +
> +const I8ZERO: i8 = 0;
> +const I8ONE: i8 = I8ZERO + 1;
> +const I16ZERO: i16 = 0;
> +const I16ONE: i16 = I16ZERO + 1;
> +const I32ZERO: i32 = 0;
> +const I32ONE: i32 = I32ZERO + 1;
> +const I64ZERO: i64 = 0;
> +const I64ONE: i64 = I64ZERO + 1;
> +const I128ZERO: i128 = 0;
> +const I128ONE: i128 = I128ZERO + 1;
> +
> +const F32ZERO: f32 = 0.0;
> +const F32ONE: f32 = F32ZERO + 1.0;
> +const F64ZERO: f64 = 0.0;
> +const F64ONE: f64 = F64ZERO + 1.0;
> +
> +const USIZEZERO: usize = 0;
> +const USIZEONE: usize = USIZEZERO + 1;
> +const ISIZEZERO: isize = 0;
> +const ISIZEONE: isize = ISIZEZERO + 1;
> +
> +/* Not yet supported
> +const CHARPI: char = '\u{03C0}';
> +const STRHELLO: &str = "Hello World!";
> +*/
> +
> +extern "C" { fn abort (); }
> +
> +pub fn main ()
> +{
> + if TRUE == FALSE { unsafe { abort (); } }
> + if U8ZERO > U8ONE { unsafe { abort (); } }
> + if U16ZERO > U16ONE { unsafe { abort (); } }
> + if U32ZERO > U32ONE { unsafe { abort (); } }
> + if U64ZERO > U64ONE { unsafe { abort (); } }
> + if U128ZERO > U128ONE { unsafe { abort (); } }
> +
> + if I8ONE <= I8ZERO { unsafe { abort (); } }
> + if I16ONE <= I16ZERO { unsafe { abort (); } }
> + if I32ONE <= I32ZERO { unsafe { abort (); } }
> + if I64ONE <= I64ZERO { unsafe { abort (); } }
> + if I128ONE <= I128ZERO { unsafe { abort (); } }
> +
> + if F32ZERO + F32ONE != F32ONE { unsafe { abort (); } }
> + if F64ZERO + F64ONE != F64ONE { unsafe { abort (); } }
> +
> + if USIZEZERO + USIZEONE - USIZEONE + USIZEZERO != USIZEZERO
> + {
> + unsafe { abort (); }
> + }
> + if ISIZEZERO + ISIZEONE - ISIZEONE + ISIZEZERO != ISIZEZERO
> + {
> + unsafe { abort (); }
> + }
> +
> + // if CHARPI != '\u{03c0}' { unsafe { abort (); } }
> + // if STRHELLO != "Hello World!" { unsafe { abort (); } }
> +}
> --
> 2.32.0
>
> --
> Gcc-rust mailing list
> Gcc-rust@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/gcc-rust
--
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
> Worker for this Build: debian-ppc64 Hi Mark, Looks like the ppc64 is requesting a bigger disk :) fatal: sha1 file '/var/lib/buildbot/workers/wildebeest/gccrust-debian-ppc64/gccrs/.git/index.lock' write error. Out of diskspace Cheers, Marc -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: ☠ Buildbot (GNU Toolchain): gccrust - failed 'grep unexpected ...' (failure) (master)
May 10, 2022 1:38 PM, "Mark Wielaard" wrote:
> On Tue, 2022-05-10 at 11:00 +, 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/98
>
> Just when we were all green :{
>
> It isn't clear to me what bors is doing though. It seems to just throw
> in commits randomly and then tries to fix things up with a merge
> commit.
>
> Is there any way to make bors not do that? It makes the buildbot
> unhappy and makes bisecting commits really hard.
>
> Ideally all commits are done on top of the tree without these odd merge
> commits. So do a simple rebase first, then commit/push.
>
I don't think that's possible. I recall reading that bors-ng handles it this
way and you can't change this behavior. It tests everything waiting in the
queue and only split this if tests are KO:
https://github.com/bors-ng/bors-ng
"
As commits are reviewed, bors lumps them into a queue of batches. If everything
passes, there will just be two batches; the one that's running, and the one
that's waiting to be run (and is accumulating more and more pull requests until
it gets a chance to run).
To run a batch, bors creates a merge commit, merging the main branch with all
the pull requests that make up the batch. Instead of pushing the merge commit
immediately, however, it will instead push it to the staging branch. They'll
look like this:
Merge #5 #7 #8
5: Rename `bifurcate()` to `bifurcateCrab()`
7: Call `bifurcate()` in the `onland` event handler
8: Fix crash in `drive()`
If the build passes, the main branch gets fast-forwarded to meet the staging
branch. Since the main branch contains the exact contents that were just
tested, bit-for-bit, it's not broken. (at least, not in any way that the
automated tests are able to detect)
If the build fails, bors will follow a strategy called "bisecting". Namely, it
splits the batch into two batches, and pushes those to the queue. In this
example, the first batch will look like this:
...
"
:(
Marc
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 --- Comment #7 from Marc Poulhiès --- There's no language spec yet, it's WIP: https://github.com/rust-lang/rust/issues/113527 Currently, the reference is rustc and the goal is to match its current behavior. I think the frontend is not listed because it's currently not enabled/working-enough. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/119333] [15 regression] Rust bootstrap fails with cargo trying to download polonius crates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119333 --- Comment #3 from Marc Poulhiès --- Correct. Not sure about having a .cargo at toplevel currently, so I'll simply --offline for bck, and we'll be able to revisit. https://github.com/Rust-GCC/gccrs/pull/3505 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/119333] [15 regression] Rust bootstrap fails with cargo trying to download polonius crates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119333 Marc Poulhiès changed: What|Removed |Added See Also||https://github.com/Rust-GCC ||/gccrs/pull/3505 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/120018] internal compiler error: in redirect_to_unreachable, at ipa-fnsummary.cc:258 for 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120018 --- Comment #3 from Marc Poulhiès --- Ok, thanks Andrew, we'll take care of fixing this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/108113] Rust and --enable-link-serialization=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113 Marc Poulhiès changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dkm at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-12-14 Ever confirmed|0 |1 --- Comment #1 from Marc Poulhiès --- Thanks Jakub! I'll fix that, thanks for the detailed report -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108113] Rust and --enable-link-serialization=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113 Marc Poulhiès changed: What|Removed |Added See Also||https://github.com/Rust-GCC ||/gccrs/pull/1704 -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108111] Rust meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111 --- Comment #1 from Marc Poulhiès --- Hello David, Looking at the errors, most of them are trivial to fix. 1-6: missing 'override'. 9: not present in most recent dev branch on github, can be ignored as it will disappear when we update the gcc master branch with latest code. 13-14: class is missing a virtual dtor 7,10-12: unused variables I'll need to read a bit more about the 8 (default move assignment op being deleted). I've a first patch that addresses most of the warnings, but I'm missing the last one. If Arthur (or someone else) doesn't beat me to it, I'll have a fix shortly -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108111] Rust meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111 --- Comment #3 from Marc Poulhiès --- Thanks Jonathan for the suggestion. The lexer code still need some refactor because the Source type (2nd template argument to buffered_queue) is expected to have a next() method and is used with both a InputSource& and a TokenSource. I have a local patch but still need to use clang to check the fix first :) -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108113] Rust and --enable-link-serialization=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113 --- Comment #3 from Marc Poulhiès --- I can yes, but wasn't really sure and didn't want to interfere with Arthur ongoing work at updating the gcc's master branch with all the pending changes from github. Should I submit the patch for formal approval on gcc-patches@ or can I go ahead and apply it directly ? -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108113] Rust and --enable-link-serialization=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113 Marc Poulhiès changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Marc Poulhiès --- Fixed in master. -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108111] Rust meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111 Marc Poulhiès changed: What|Removed |Added See Also||https://github.com/Rust-GCC ||/gccrs/pull/1975 -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
