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/45 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
Hi,
On Sat, Jun 12, 2021 at 11:38:01PM +0000, buildbot@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/45
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-arm64
>
> Build Reason: <unknown>
> Blamelist: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>
> BUILD FAILED: failed compile (failure)
Sorry, that was my fault, I was experimenting with ccache to speed up
builds, but misconfigured things. It should be setup correctly now.
At least we know now that the buildbot sents out emails when something
goes wrong.
Apologies,
Mark
The Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/40 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
On Fri, 2021-06-18 at 11:06 +0000, buildbot@builder.wildebeest.org
wrote:
> The Buildbot has detected a new failure on builder gccrust-fedora-
> ppc64 while building gccrust.
> Full details are available at:
> https://builder.wildebeest.org/buildbot/#builders/61/builds/40
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: fedora-ppc64
>
> Build Reason: <unknown>
> Blamelist: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
>
> BUILD FAILED: failed compile (failure)
Apologies again. This is me playing with ccache again.
It seems to work fine on all other arches (arm64, x86_64 and ppc64le)
but on ppc64 it causes signal 13 (SIGPIPE) failures. I haven't figured
out why yet.
Cheers,
Mark
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/270 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/269 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/262 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/247 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
Hi,
On Wed, Aug 04, 2021 at 03:15:00PM +0000, buildbot@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/270
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-arm64
>
> Build Reason: <unknown>
> Blamelist: CohenArthur <arthur.cohen@epita.fr>
>
> BUILD FAILED: failed compile (failure)
This commit (and the following 3) were really bad. They didn't build.
Apparently bors doesn't check commit individually, but the buildbot
does build every commit separately.
The tree is buildable again, but I think it would be good to not have
any commits that break the build.
Periodically broken trees make it also hard to bisect issues.
Is it possible to make bors check all commits in a series? Or can we
somehow connect the buildbot workers to the bors checks?
Thanks,
Mark
[-- Attachment #1.1: Type: text/plain, Size: 1424 bytes --] On 04/08/2021 21:25, Mark Wielaard wrote: > Hi, > > On Wed, Aug 04, 2021 at 03:15:00PM +0000, buildbot@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/270 >> >> Buildbot URL: https://builder.wildebeest.org/buildbot/ >> >> Worker for this Build: debian-arm64 >> >> Build Reason: <unknown> >> Blamelist: CohenArthur <arthur.cohen@epita.fr> >> >> BUILD FAILED: failed compile (failure) > This commit (and the following 3) were really bad. They didn't build. > Apparently bors doesn't check commit individually, but the buildbot > does build every commit separately. > > The tree is buildable again, but I think it would be good to not have > any commits that break the build. > > Periodically broken trees make it also hard to bisect issues. > > Is it possible to make bors check all commits in a series? Or can we > somehow connect the buildbot workers to the bors checks? > > Thanks, > > Mark > Hi Mark, I think the build-bot checks for every commit is a really nice feature here. I think you should keep the build-bots as are. I really like to make sure each of my commits are build-able and pass tests. It keeps me honest to avoid regressions as best I can. What do you think? Thanks --Phil [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 665 bytes --]
On 21/08/06 03:31PM, Philip Herron wrote: > On 04/08/2021 21:25, Mark Wielaard wrote: > > Hi, > > > > On Wed, Aug 04, 2021 at 03:15:00PM +0000, buildbot@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/270 > >> > >> Buildbot URL: https://builder.wildebeest.org/buildbot/ > >> > >> Worker for this Build: debian-arm64 > >> > >> Build Reason: <unknown> > >> Blamelist: CohenArthur <arthur.cohen@epita.fr> > >> > >> BUILD FAILED: failed compile (failure) > > This commit (and the following 3) were really bad. They didn't build. > > Apparently bors doesn't check commit individually, but the buildbot > > does build every commit separately. Really sorry about this. > > The tree is buildable again, but I think it would be good to not have > > any commits that break the build. > > > > Periodically broken trees make it also hard to bisect issues. > > > > Is it possible to make bors check all commits in a series? Or can we > > somehow connect the buildbot workers to the bors checks? I think bors is mostly focused on having the latest commit on the main branch always build, but I might be wrong on this. I think it should be possible to integrate buildbot to the CI on github directly, side to side with bors. > > > > Thanks, > > > > Mark > > > Hi Mark, > > I think the build-bot checks for every commit is a really nice feature > here. I think you should keep the build-bots as are. I really like to > make sure each of my commits are build-able and pass tests. It keeps me > honest to avoid regressions as best I can. > > What do you think? > > Thanks > > --Phil > I'm really sorry about not having all the commits build. I tried to keep them as atomic as possible and clearly didn't check all of them separately. This could have been a single commit and would have avoided this, but since each change was big I decided to split them up. I was not aware that buildbot checks every commit separately. I think this is a good feature, and I'll keep it in mind. Won't happen again! Sorry again, -- Arthur
Hi Philip,
On Fri, Aug 06, 2021 at 03:31:07PM +0100, Philip Herron wrote:
> > Is it possible to make bors check all commits in a series? Or can we
> > somehow connect the buildbot workers to the bors checks?
>
> I think the build-bot checks for every commit is a really nice feature
> here. I think you should keep the build-bots as are. I really like to
> make sure each of my commits are build-able and pass tests. It keeps me
> honest to avoid regressions as best I can.
>
> What do you think?
I am just a little afraid it is running too late. But I am pretty
happy we have workers for 4 different architectures and they are green
most of the time. We really should add a 32bit (i686 or armhf) one
just to be sure that works correctly.
Currently i686 gets lots of failures like:
/home/mark/gccrs/gcc/testsuite/rust/compile/torture/methods3.rs:27:5: error: type mismatch in binary exp
ression
f64
<float:80>
<float:80>
D.229 = _2 + _4;
/home/mark/gccrs/gcc/testsuite/rust/compile/torture/methods3.rs:27:5: internal compiler error: 'verify_g
imple' failed
0x8b41fd4 verify_gimple_in_seq(gimple*)
../../gccrs/gcc/tree-cfg.c:5157
0x884b4c3 gimplify_body(tree_node*, bool)
../../gccrs/gcc/gimplify.c:15401
0x884b692 gimplify_function_tree(tree_node*)
../../gccrs/gcc/gimplify.c:15472
0x86a6448 cgraph_node::analyze()
../../gccrs/gcc/cgraphunit.c:670
0x86a9218 analyze_functions
../../gccrs/gcc/cgraphunit.c:1236
0x86a9e01 symbol_table::finalize_compilation_unit()
../../gccrs/gcc/cgraphunit.c:2514
Cheers,
Mark
Hi Arthur,
On Fri, Aug 06, 2021 at 05:55:09PM +0200, cohenarthur.dev via Gcc-rust wrote:
> I'm really sorry about not having all the commits build. I tried to keep
> them as atomic as possible and clearly didn't check all of them
> separately. This could have been a single commit and would have avoided
> this, but since each change was big I decided to split them up.
>
> I was not aware that buildbot checks every commit separately. I think
> this is a good feature, and I'll keep it in mind. Won't happen again!
No worries, that is what the bots are for. We are all human, but the
bots aren't :)
It would be more helpful if the buildbot workers ran a bit earlier.
Cheers,
Mark
[-- Attachment #1.1: Type: text/plain, Size: 2056 bytes --] On 06/08/2021 23:39, Mark Wielaard wrote: > Hi Philip, > > On Fri, Aug 06, 2021 at 03:31:07PM +0100, Philip Herron wrote: >>> Is it possible to make bors check all commits in a series? Or can we >>> somehow connect the buildbot workers to the bors checks? >> I think the build-bot checks for every commit is a really nice feature >> here. I think you should keep the build-bots as are. I really like to >> make sure each of my commits are build-able and pass tests. It keeps me >> honest to avoid regressions as best I can. >> >> What do you think? > I am just a little afraid it is running too late. But I am pretty > happy we have workers for 4 different architectures and they are green > most of the time. We really should add a 32bit (i686 or armhf) one > just to be sure that works correctly. > > Currently i686 gets lots of failures like: > > /home/mark/gccrs/gcc/testsuite/rust/compile/torture/methods3.rs:27:5: error: type mismatch in binary exp > ression > f64 > <float:80> > <float:80> > D.229 = _2 + _4; > /home/mark/gccrs/gcc/testsuite/rust/compile/torture/methods3.rs:27:5: internal compiler error: 'verify_g > imple' failed > 0x8b41fd4 verify_gimple_in_seq(gimple*) > ../../gccrs/gcc/tree-cfg.c:5157 > 0x884b4c3 gimplify_body(tree_node*, bool) > ../../gccrs/gcc/gimplify.c:15401 > 0x884b692 gimplify_function_tree(tree_node*) > ../../gccrs/gcc/gimplify.c:15472 > 0x86a6448 cgraph_node::analyze() > ../../gccrs/gcc/cgraphunit.c:670 > 0x86a9218 analyze_functions > ../../gccrs/gcc/cgraphunit.c:1236 > 0x86a9e01 symbol_table::finalize_compilation_unit() > ../../gccrs/gcc/cgraphunit.c:2514 > > Cheers, > > Mark > I would be interested in seeing 32bit build bots since this patch has been merged: https://github.com/Rust-GCC/gccrs/pull/614 Which thanks to Adrian who has been testing it out. Do you have access to 32bit machines? I have some unused space on digital ocean where we could put some build-bots if you like? Thanks --Phil [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 665 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 2491 bytes --] On 06/08/2021 16:55, cohenarthur.dev wrote: > On 21/08/06 03:31PM, Philip Herron wrote: >> On 04/08/2021 21:25, Mark Wielaard wrote: >>> Hi, >>> >>> On Wed, Aug 04, 2021 at 03:15:00PM +0000, buildbot@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/270 >>>> >>>> Buildbot URL: https://builder.wildebeest.org/buildbot/ >>>> >>>> Worker for this Build: debian-arm64 >>>> >>>> Build Reason: <unknown> >>>> Blamelist: CohenArthur <arthur.cohen@epita.fr> >>>> >>>> BUILD FAILED: failed compile (failure) >>> This commit (and the following 3) were really bad. They didn't build. >>> Apparently bors doesn't check commit individually, but the buildbot >>> does build every commit separately. > Really sorry about this. > >>> The tree is buildable again, but I think it would be good to not have >>> any commits that break the build. >>> >>> Periodically broken trees make it also hard to bisect issues. >>> >>> Is it possible to make bors check all commits in a series? Or can we >>> somehow connect the buildbot workers to the bors checks? > I think bors is mostly focused on having the latest commit on the main > branch always build, but I might be wrong on this. I think it should be > possible to integrate buildbot to the CI on github directly, side to > side with bors. > >>> Thanks, >>> >>> Mark >>> >> Hi Mark, >> >> I think the build-bot checks for every commit is a really nice feature >> here. I think you should keep the build-bots as are. I really like to >> make sure each of my commits are build-able and pass tests. It keeps me >> honest to avoid regressions as best I can. >> >> What do you think? >> >> Thanks >> >> --Phil >> > I'm really sorry about not having all the commits build. I tried to keep > them as atomic as possible and clearly didn't check all of them > separately. This could have been a single commit and would have avoided > this, but since each change was big I decided to split them up. > > I was not aware that buildbot checks every commit separately. I think > this is a good feature, and I'll keep it in mind. Won't happen again! > > Sorry again, > > -- > Arthur No need to apologies Arthur, you've done great work! This is something we haven't thought about before until now. Thanks --Phil [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 665 bytes --]
On Sun, Aug 08, 2021 at 12:51:47PM +0100, Philip Herron wrote: > I would be interested in seeing 32bit build bots since this patch has > been merged: https://github.com/Rust-GCC/gccrs/pull/614 > > Which thanks to Adrian who has been testing it out. > > Do you have access to 32bit machines? I have some unused space on > digital ocean where we could put some build-bots if you like? Just added one: https://builder.wildebeest.org/buildbot/#/builders/62 (Ignore the red builds, the last one is green, they were setup issues) It isn't super fast (takes ~25 to do a build plus check-rust), but as long as we do < 48 commits a day we should be fine. I tried adding ccache on it (which reduces build times a lot on the other builders) but that caused some odd failures. I think for now we are fine, but we start adding lots more commits a day adding some extra VMs would be nice. Cheers, Mark
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/355 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/354 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/347 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/332 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/62/builds/70 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-i386 Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/65 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
Hi,
On Sun, Aug 22, 2021 at 03:55:47PM +0000, buildbot@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/355
This seems to have been a transient build failure caused by:
commit d5dd96322b588ffcf5bdd2fe0e3a14eb217d75b2
Author: Philip Herron <philip.herron@embecosm.com>
Date: Sun Aug 22 13:42:14 2021 +0100
Add Trait Resolver simple type-path lookup
Post type checking we need to be able to lookup trait references, but do
not need to resolve the trait with error messages. We simple want to look
it up if it exists.
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc:233:1: error: ‘PathProbeImplTrait’ has not been declared
PathProbeImplTrait::process_trait_impl_items_for_candidates ()
^~~~~~~~~~~~~~~~~~
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc: In function ‘void Rust::Resolver::process_trait_impl_items_for_candidates()’:
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc:235:3: error: ‘mappings’ was not declared in this scope
mappings->iterate_impl_items (
^~~~~~~~
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc:235:3: note: suggested alternative: ‘warning’
mappings->iterate_impl_items (
^~~~~~~~
warning
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc: In lambda function:
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc:244:12: error: ‘trait_reference’ was not declared in this scope
if (!trait_reference->is_equal (*resolved))
^~~~~~~~~~~~~~~
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc:244:12: note: suggested alternative: ‘TraitReference’
if (!trait_reference->is_equal (*resolved))
^~~~~~~~~~~~~~~
TraitReference
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc:247:7: error: ‘process_impl_item_candidate’ was not declared in this scope
process_impl_item_candidate (id, item, impl);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gccrs/gcc/rust/typecheck/rust-hir-trait-resolve.cc:247:7: note: suggested alternative: ‘process_trait_impl_items_for_candidates’
process_impl_item_candidate (id, item, impl);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
process_trait_impl_items_for_candidates
make[2]: *** [../../gccrs/gcc/rust/Make-lang.in:301: rust/rust-hir-trait-resolve.o] Error 1
But resolved by the next commit:
commit a6c8bd136dd4e89752eaec6415ba651f3cd73b9e
Author: Philip Herron <philip.herron@embecosm.com>
Date: Sun Aug 22 13:44:46 2021 +0100
Add impl-trait path probe helper
This adds a probe to lookup candidates for a segment for any impl block
for this receiver and trait. This simplifies some query based compilation
code. When the item is resolved to a trait item but might be overriden by
a reciever impl block instead.
Not all buildbot workers have finished building all the latest commits though.
Cheers,
Mark
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/469 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: H.J. Lu <hjl.tools@gmail.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/468 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: H.J. Lu <hjl.tools@gmail.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/461 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: H.J. Lu <hjl.tools@gmail.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/446 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: H.J. Lu <hjl.tools@gmail.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/62/builds/184 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-i386 Build Reason: <unknown> Blamelist: H.J. Lu <hjl.tools@gmail.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/179 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: H.J. Lu <hjl.tools@gmail.com> BUILD FAILED: failed configure (failure) Sincerely, -The Buildbot
On Sat, Sep 25, 2021 at 12:04:01PM +0000, buildbot@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/469
O fun. I hadn't expected the buildbot to try and build every commit in
the merge... They all fail in the configure step:
configure: error: The following requested languages could not be
built: rust
But this will take some time, there are many, many, many commits. I'll
go and reset the buildbot so it picks up the builds after the merge
again.
Cheers,
Mark
The Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/1072 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
Hi,
On Fri, 2021-11-05 at 13:49 +0000, buildbot@builder.wildebeest.org
wrote:
> The Buildbot has detected a new failure on builder gccrust-fedora-
> s390x while building gccrust.
> Full details are available at:
> https://builder.wildebeest.org/buildbot/#builders/63/builds/1072
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: fedora-s390x
Sorry, the buildbot worker ran out of disk space. Space has been
restored and the next builds look green again.
Cheers,
Mark
The Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/6 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed 'rm -rf ...' (failure) Sincerely, -The Buildbot
On Sun, 2021-12-19 at 17:13 +0000, buildbot@builder.wildebeest.org wrote: > The Buildbot has detected a new failure on builder gccrust-debian- > ppc64 while building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/64/builds/6 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: debian-ppc64 > > Build Reason: <unknown> > Blamelist: Philip Herron <philip.herron@embecosm.com> > > BUILD FAILED: failed 'rm -rf ...' (failure) Sorry, we are testing a new ppc64[be] debian builder. Everything should be setup correctly now and it is reporting (green) results at: https://builder.wildebeest.org/buildbot/#/builders/64 Cheers, Mark
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/1581 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: Jonathan Wakely <jwakely@redhat.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/1502 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: Jonathan Wakely <jwakely@redhat.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/1504 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: Jonathan Wakely <jwakely@redhat.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/1492 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: Jonathan Wakely <jwakely@redhat.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/62/builds/1224 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-i386 Build Reason: <unknown> Blamelist: Jonathan Wakely <jwakely@redhat.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/1229 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: Jonathan Wakely <jwakely@redhat.com> BUILD FAILED: failed configure (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/44 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: Jonathan Wakely <jwakely@redhat.com> BUILD FAILED: failed configure (failure) Sincerely, -The Buildbot
Hi,
On Mon, 2022-01-24 at 12:29 +0000, buildbot@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/1581
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-arm64
>
> Build Reason: <unknown>
> Blamelist: Jonathan Wakely <jwakely@redhat.com>
>
> BUILD FAILED: failed configure (failure)
>
> [lots more...]
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.
Cheers,
Mark
Mark Wielaard <mark@klomp.org> 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
Hi!
On 2022-01-24T22:30:21+0100, Marc via Gcc-rust <gcc-rust@gcc.gnu.org> wrote:
> Mark Wielaard <mark@klomp.org> 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
Hi,
On Tue, Jan 25, 2022 at 08:33:50AM +0100, Thomas Schwinge wrote:
> On 2022-01-24T22:30:21+0100, Marc via Gcc-rust <gcc-rust@gcc.gnu.org> wrote:
> > Mark Wielaard <mark@klomp.org> 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?
I added a filesIsImportant filter to the buildbot gccrs scheduler:
gccrs_files = ["gcc/rust/", "gcc/testsuite/rust/", "gcc/config/.*/*-rust.c"]
def gccrsImportant(change):
for file in change.files:
for pattern in gccrs_files:
match = re.match(pattern, file)
if match:
return True
return False
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.
Cheers,
Mark
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/1609 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
Hi, 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"] > > def gccrsImportant(change): > for file in change.files: > for pattern in gccrs_files: > match = re.match(pattern, file) > if match: > return True > return False > > 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. 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
Hi,
On Sat, Jan 29, 2022 at 04:20:57PM +0000, buildbot@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/1609
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-arm64
>
> Build Reason: <unknown>
> Blamelist: Philip Herron <philip.herron@embecosm.com>
>
> BUILD FAILED: failed compile (failure)
That is somewhat odd. It was the oom-killer:
oom_reaper: reaped process 25752 (ld), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
But the next builds succeeded. I am not sure what caused the out of memory this time.
Cheers,
Mark
Hi Mark! On 2022-01-29T21:20:45+0100, Mark Wielaard <mark@klomp.org> 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
Hi Thomas, On Thu, 2022-02-03 at 21:55 +0100, Thomas Schwinge wrote: > On 2022-01-29T21:20:45+0100, Mark Wielaard <mark@klomp.org> 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. Well spotted. Thanks. Changed it to: gccrs_files = ["gcc/rust/", "gcc/testsuite/rust/", "gcc/config/.*/.*-rust.cc"] I really should clean the buildbot cfg file up (it contains everything, including passwords and tokens in one file) and check it into git so others can more easily contribute to it. > 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)? That won't work. At least not with the current setup/filter. The buildbot doesn't know what the correct "side" is for the commits that are being merged. So the buildbot would see the commits containing gcc/DATESTAMP and think those commits should be build. Even if those commits come from the "side" where there are no gccrs files yet. We could however add a daily or weekly builder/scheduler. Which would be especially helpful when we add container image builders, where the image itself might be updated once a week. But at the moment we seem to have an average of at least one commit a day, so in practice we would notice pretty soon after a merge. Cheers, Mark
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/1620 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/1536 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/1549 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/1527 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/62/builds/1259 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-i386 Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/1273 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/81 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: CohenArthur <arthur.cohen@epita.fr>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
Hi,
On Sat, 2022-02-05 at 16:58 +0000, buildbot@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/1620
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-arm64
>
> Build Reason: <unknown>
> Blamelist: CohenArthur <arthur.cohen@epita.fr>, bors[bot] <26634292+bors[bot]@users.noreply.github.com>
>
> BUILD FAILED: failed compile (failure)
This was caused by two commits being flipped:
commit bc47ace0ec97ef1b3498c17ff03e2ee873743d5c
Author: CohenArthur <cohenarthur.dev@gmail.com>
Date: Tue Jan 25 13:59:06 2022 +0100
selftest: Move C specific tests in c_family_test()
commit 2b1345a73654cf5b2b13e334813ee97016ba5d1a
Author: CohenArthur <arthur.cohen@epita.fr>
Date: Tue Oct 19 10:46:45 2021 +0200
selftest: Enable unit testing for the rust frontend
So the first commit enabled the selftests (which fails in the buildbot)
and the second moved the C specific selftests (which just failed) into
c_family_tests so they won't trigger a failure next time.
Unfortunately the buildbot thinks the second commit isn't rust frontend
related (which is technically correct) and so won't do a build with
that commit.
But the next gccrs commit should turn the buildbot green again.
Cheers,
Mark
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/1648 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: Philip Herron <philip.herron@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
buildbot@builder.wildebeest.org writes:
> Build Reason: <unknown>
> Blamelist: Philip Herron <philip.herron@embecosm.com>
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
Hi Marc,
On Thu, Feb 17, 2022 at 08:46:01PM +0100, Marc via Gcc-rust wrote:
> buildbot@builder.wildebeest.org writes:
>
> > Build Reason: <unknown>
> > Blamelist: Philip Herron <philip.herron@embecosm.com>
>
> 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 ?
It did indeed. The machine only has 4GB of memory and 2GB swap. With
make -j4 there are 4 processes each taking ~1GB and it is just
swapping:
926 root 20 0 0 0 0 R 97.6 0.0 135:41.18 kswapd0
15794 buildbot 20 0 1539436 928056 0 D 2.4 24.5 1:41.92 cc1plus
15817 buildbot 20 0 781108 674280 328 D 2.4 17.8 1:08.31 cc1plus
15792 buildbot 20 0 1250264 763912 384 D 2.1 20.2 1:40.62 cc1plus
15800 buildbot 20 0 1427104 784820 132 D 2.1 20.7 1:41.67 cc1plus
I'll reconfigure with make -j3 to see if that helps.
I don't know why we are suddenly seeing this, did the code get that
much bigger recently?
Cheers,
Mark
Hi, On Thu, Feb 17, 2022 at 10:05:29PM +0100, Mark Wielaard wrote: > On Thu, Feb 17, 2022 at 08:46:01PM +0100, Marc via Gcc-rust wrote: > > ../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 ? > > It did indeed. The machine only has 4GB of memory and 2GB swap. With > make -j4 there are 4 processes each taking ~1GB and it is just > swapping: > > 926 root 20 0 0 0 0 R 97.6 0.0 135:41.18 kswapd0 > 15794 buildbot 20 0 1539436 928056 0 D 2.4 24.5 1:41.92 cc1plus > 15817 buildbot 20 0 781108 674280 328 D 2.4 17.8 1:08.31 cc1plus > 15792 buildbot 20 0 1250264 763912 384 D 2.1 20.2 1:40.62 cc1plus > 15800 buildbot 20 0 1427104 784820 132 D 2.1 20.7 1:41.67 cc1plus > > I'll reconfigure with make -j3 to see if that helps. It didn't. With -j3 the oom-killer kicks in (dunno why not with -j4): [1643873.684998] Out of memory: Killed process 16625 (cc1plus) total-vm:1764740kB, anon-rss:1040744kB, file-rss:0kB, shmem-rss:0kB, UID:998 pgtables:3464kB oom_score_adj:0 [1643873.992761] oom_reaper: reaped process 16625 (cc1plus), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB So now using make -j2 which does succeed. https://builder.wildebeest.org/buildbot/#/builders/58/builds/1655 Very odd. But apparently for some reason 4GB isn't enough anymore to use -j3 or -j4. Which is unfortunate because this board doesn't take more than 4GB memory. Cheers, Mark
The Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/120 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed update (failure) Sincerely, -The Buildbot
> 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
Hi Marc, Hi Tom,
On Fri, Feb 18, 2022 at 12:48:23PM +0000, dkm--- via Gcc-rust wrote:
> > Worker for this Build: debian-ppc64
>
> 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
Right. Tom, could you take a peek at this?
Thanks,
Mark
Hi Mark,
Mark Wielaard <mark@klomp.org> writes:
> Hi Marc, Hi Tom,
>
> On Fri, Feb 18, 2022 at 12:48:23PM +0000, dkm--- via Gcc-rust wrote:
>> > Worker for this Build: debian-ppc64
>>
>> 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
>
> Right. Tom, could you take a peek at this?
I made an extra 11 GiB available.
Thomas
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/1681 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/62/builds/1316 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-i386 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/139 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The Buildbot
Hi,
So, this works as expected. Note that it reports issues not just for
debian-i386, but also for some other arches (all debian based). The
i386 issues are not new. But the others do seem to be caused by the
latest commit. I haven't investigated why yet though.
The buildbot links also point to the log and sum files that might be
useful to inspect.
Cheers,
Mark
On Wed, Feb 23, 2022 at 10:26:16AM +0000, buildbot@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/1681
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-arm64
>
> Build Reason: <unknown>
> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com>
>
> BUILD FAILED: failed 'grep unexpected ...' (failure)
>
> Sincerely,
> -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-i386 while building gccrust.
> Full details are available at:
> https://builder.wildebeest.org/buildbot/#builders/62/builds/1316
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-i386
>
> Build Reason: <unknown>
> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com>
>
> BUILD FAILED: failed 'grep unexpected ...' (failure)
>
> Sincerely,
> -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust.
> Full details are available at:
> https://builder.wildebeest.org/buildbot/#builders/64/builds/139
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-ppc64
>
> Build Reason: <unknown>
> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com>
>
> BUILD FAILED: failed 'grep unexpected ...' (failure)
>
> Sincerely,
> -The Buildbot
>
> --
> Gcc-rust mailing list
> Gcc-rust@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/gcc-rust
Hi,
On Wed, 2022-02-23 at 11:35 +0100, Mark Wielaard wrote:
> So, this works as expected. Note that it reports issues not just for
> debian-i386, but also for some other arches (all debian based). The
> i386 issues are not new. But the others do seem to be caused by the
> latest commit. I haven't investigated why yet though.
>
> The buildbot links also point to the log and sum files that might be
> useful to inspect.
So there were 3 issues:
- The debian-i386 build had pre-existing failures that weren't
reported before.
- The recent commits introduced some tests which failed, and then
some code changes that fixed those tests so they succeeded.
IMHO the buildbot was correct to flag those because they are real
failures, even though they were fixed 2 commits later. This makes
e.g. bisecting issues a bit of a pain. So I would like to see us
commit in the "correct order".
- The buildbot test was incorrect when /bin/sh wasn't bash (as on
the debian builders, where it is dash).
test $? == 1 should have been $? -eq 1
Fixed.
Cheers,
Mark
The Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/1598 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/1609 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/1587 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/1333 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The Buildbot
Hi, On Wed, Feb 23, 2022 at 12:26:26PM +0100, Mark Wielaard wrote: > So there were 3 issues: > > - The debian-i386 build had pre-existing failures that weren't > reported before. > - The recent commits introduced some tests which failed, and then > some code changes that fixed those tests so they succeeded. > IMHO the buildbot was correct to flag those because they are real > failures, even though they were fixed 2 commits later. This makes > e.g. bisecting issues a bit of a pain. So I would like to see us > commit in the "correct order". So on irc we did briefly discusss that this "correct order" is slightly opposite to what you do when using Test Driven Development (TDD). And I agree that test driven development is great. First writing the testcases, then the code to match the intended behaviour. But if popssible please first commit the code, then the testcases (or both together). Or if you wrote the tests first, committed them locally, then wrote the code to make them PASS as a separate commit, git rebase the commits to swap (or merge/squash) them before pushing. git rebase --interactive is really cool BTW. > - The buildbot test was incorrect when /bin/sh wasn't bash (as on > the debian builders, where it is dash). > test $? == 1 should have been $? -eq 1 > Fixed. So everything, except debian-i386, is green again: https://builder.wildebeest.org/buildbot/#/builders?tags=gccrust The buildbot will only sent email when another builder switches from green to red. So it will no longer sent email about the already red debian-i386 builder. So currently we have a BuildSetStatusGenerator with mode=('problem',) where problem is "Include a build which failed when the previous build has passed." https://docs.buildbot.net/current/manual/configuration/report_generators/buildset.html But we could use a different setting, maybe 'failing' to always sent mail when a build fails (but currently that means all builds, because debian-i386 fails). Or 'change' to report on any builder that changed status. Cheers, Mark
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: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/1624 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/1635 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/1613 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/1359 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/169 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
Hi, On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@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: <unknown> > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> > > BUILD FAILED: failed compile (failure) And the same for all other builders. I haven't figured out yet why the last commit caused this. But it can be replicated when configuring with --enable-checking=yes That causes the selftests to trigger: 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
Hi! On 2022-03-02T00:15:41+0100, Mark Wielaard <mark@klomp.org> wrote: > On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@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: <unknown> >> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> >> >> 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
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?
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.
Thanks
--Phil
On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> Hi!
>
> On 2022-03-02T00:15:41+0100, Mark Wielaard <mark@klomp.org> wrote:
> > On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@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: <unknown>
> >> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>
> >>
> >> 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
Hi! On 2022-03-02T09:03:48+0000, Philip Herron <philip.herron@embecosm.com> 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 <thomas@codesourcery.com> wrote: >> >> Hi! >> >> On 2022-03-02T00:15:41+0100, Mark Wielaard <mark@klomp.org> wrote: >> > On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@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: <unknown> >> >> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> >> >> >> >> 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
Hi, On Wed, 2022-03-02 at 09:03 +0000, 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? Sure. Arthur can you sent me your ssh pubkey? > 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. Aha. That explains why the lexer is seeing garbage. At least in my local case. I am slightly surprised it isn't showing up locally for you. What triggers the running of the selftests? Cheers, Mark
Hi! On 2022-03-02T10:44:38+0100, I wrote: > On 2022-03-02T09:03:48+0000, Philip Herron <philip.herron@embecosm.com> 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<std::shared_ptr<Rust::Token>, Rust::Lexer::TokenSource>::peek(int) (rust-lex.h:233) ==3228208== by 0x988A46: Rust::parse_cfg_option(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (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 <thomas@codesourcery.com> wrote: >>> >>> Hi! >>> >>> On 2022-03-02T00:15:41+0100, Mark Wielaard <mark@klomp.org> wrote: >>> > On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@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: <unknown> >>> >> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> >>> >> >>> >> 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
[-- Attachment #1.1.1: Type: text/plain, Size: 9470 bytes --] Hi everyone, On 3/2/22 11:05, Thomas Schwinge wrote: > Hi! > > On 2022-03-02T10:44:38+0100, I wrote: >> On 2022-03-02T09:03:48+0000, Philip Herron <philip.herron@embecosm.com> 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<std::shared_ptr<Rust::Token>, Rust::Lexer::TokenSource>::peek(int) (rust-lex.h:233) > ==3228208== by 0x988A46: Rust::parse_cfg_option(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (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. I'd like to say that this is not my fault 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 index c50f63208de..b0d7494f063 100644 --- a/gcc/rust/lex/rust-lex.h +++ b/gcc/rust/lex/rust-lex.h @@ -144,7 +144,7 @@ public: /** * Lex the contents of a string instead of a file */ - static Lexer lex_string (std::string input) + static Lexer lex_string (std::string &input) { // We can perform this ugly cast to a non-const char* since we're only // *reading* the string. This would not be valid if we were doing any -- 2.35.1 This forces the string to simply be a reference and the caller to make sure that it outlives the lexer. If this passes the valgrind tests, I'll open up a PR with a comment explaining the behavior and how we should think about cleaning it up. Moral of the story is: fmemopen(3) does not allocate memory in all cases, RTFM >> I can easily test any patches that you need tested. > > > Grüße > Thomas > > >>> On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge <thomas@codesourcery.com> wrote: >>>> >>>> Hi! >>>> >>>> On 2022-03-02T00:15:41+0100, Mark Wielaard <mark@klomp.org> wrote: >>>>> On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@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: <unknown> >>>>>> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> >>>>>> >>>>>> 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 Thanks a lot, -- Arthur Cohen <arthur.cohen@embecosm.com> Toolchain Engineer Embecosm GmbH Geschäftsführer: Jeremy Bennett Niederlassung: Nürnberg Handelsregister: HR-B 36368 www.embecosm.de Fürther Str. 27 90429 Nürnberg Tel.: 091 - 128 707 040 Fax: 091 - 128 707 077 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
Hi Arthur! On 2022-03-02T13:05:30+0100, Arthur Cohen <arthur.cohen@embecosm.com> 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+0000, Philip Herron <philip.herron@embecosm.com> 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<std::shared_ptr<Rust::Token>, Rust::Lexer::TokenSource>::peek(int) (rust-lex.h:233) >> ==3228208== by 0x988A46: Rust::parse_cfg_option(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (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 > index c50f63208de..b0d7494f063 100644 > --- a/gcc/rust/lex/rust-lex.h > +++ b/gcc/rust/lex/rust-lex.h > @@ -144,7 +144,7 @@ public: > /** > * Lex the contents of a string instead of a file > */ > - static Lexer lex_string (std::string input) > + static Lexer lex_string (std::string &input) > { > // We can perform this ugly cast to a non-const char* since we're only > // *reading* the string. This would not be valid if we were doing any That is, revert commit f7ff6020f8c68e4fb54c17c4460aa7f8a31f85bd "lexer: Improve safety by taking ownership of the tokenized string". ;-) > This forces the string to simply be a reference and the caller to make > sure that it outlives the lexer. > If this passes the valgrind tests, I'll open up a PR with a comment > explaining the behavior and how we should think about cleaning > it up. I don't have time right now to think throught the C++ aspects, but I've quickly tested this, and yes, with that we've got: [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/ -xrs -nostdinc /dev/null -S -o /dev/null -fself-test=[...]/source-gcc/gcc/testsuite/selftests -fself-test: 65613 pass(es) in 0.301854 seconds ... as well as "clean" Valgrind results (just some lost memory etc., as before). Grüße Thomas > Moral of the story is: fmemopen(3) does not allocate memory in all > cases, RTFM > >>> I can easily test any patches that you need tested. >> >> >> Grüße >> Thomas >> >> >>>> On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge <thomas@codesourcery.com> wrote: >>>>> >>>>> Hi! >>>>> >>>>> On 2022-03-02T00:15:41+0100, Mark Wielaard <mark@klomp.org> wrote: >>>>>> On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@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: <unknown> >>>>>>> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> >>>>>>> >>>>>>> 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 > > Thanks a lot, > > -- > Arthur Cohen <arthur.cohen@embecosm.com> > > Toolchain Engineer > > Embecosm GmbH > > Geschäftsführer: Jeremy Bennett > Niederlassung: Nürnberg > Handelsregister: HR-B 36368 > www.embecosm.de > > Fürther Str. 27 > 90429 Nürnberg > > > Tel.: 091 - 128 707 040 > Fax: 091 - 128 707 077 ----------------- 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
[-- Attachment #1.1.1: Type: text/plain, Size: 14449 bytes --] Hi Thomas, thanks a lot! On 3/2/22 13:36, Thomas Schwinge wrote: > Hi Arthur! > > On 2022-03-02T13:05:30+0100, Arthur Cohen <arthur.cohen@embecosm.com> 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+0000, Philip Herron <philip.herron@embecosm.com> 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<std::shared_ptr<Rust::Token>, Rust::Lexer::TokenSource>::peek(int) (rust-lex.h:233) >>> ==3228208== by 0x988A46: Rust::parse_cfg_option(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (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 knew about -wrapper but had only used it for gdb! So this is great information. Weirdly, I do not get the behavior on my machine, even under valgrind. arthur@platypus ~/G/gccrs (lexer-string-lifetime)> build/./gcc/xgcc -Bbuild/./gcc/ -xrs -nostdinc /dev/null -S -o /dev/null -fself-test=gcc/testsuite/selftests -wrapper valgrind,--leak-check=full ==87067== Memcheck, a memory error detector ==87067== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==87067== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==87067== Command: build/./gcc/rust1 /dev/null -quiet -dumpbase null -mtune=generic -march=x86-64 -fself-test=gcc/testsuite/selftests -o /dev/null -Lbuild/./gcc -L/lib/../lib64 -L/usr/lib/../lib64 ==87067== --87067-- WARNING: Serious error when reading debug info --87067-- When reading debug info from /home/arthur/Git/gccrs/build/gcc/rust1: --87067-- Can't make sense of .rodata section mapping -fself-test: 65613 pass(es) in 7.880207 seconds ==87067== ==87067== HEAP SUMMARY: ==87067== in use at exit: 962,793 bytes in 2,362 blocks ==87067== total heap usage: 2,032,407 allocs, 2,030,045 frees, 1,033,564,484 bytes allocated ==87067== ==87067== 12,640 (48 direct, 12,592 indirect) bytes in 1 blocks are definitely lost in loss record 1,445 of 1,454 ==87067== at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==87067== by 0x28EDF9C: ??? (in /home/arthur/Git/gccrs/build/gcc/rust1) ==87067== by 0x4DE605F: ??? ==87067== by 0x2144E59: ??? (in /home/arthur/Git/gccrs/build/gcc/rust1) ==87067== by 0xEB8C6B: ??? (in /home/arthur/Git/gccrs/build/gcc/rust1) ==87067== by 0x28C452D: ??? (in /home/arthur/Git/gccrs/build/gcc/rust1) ==87067== by 0x1F: ??? ==87067== by 0x1FFEFFFE8F: ??? ==87067== by 0x4DE6E4F: ??? ==87067== by 0x119ECDAC19DB17FF: ??? ==87067== by 0x1FFEFFFE3F: ??? ==87067== by 0x4E00C2F: ??? ==87067== ==87067== LEAK SUMMARY: ==87067== definitely lost: 48 bytes in 1 blocks ==87067== indirectly lost: 12,592 bytes in 333 blocks ==87067== possibly lost: 0 bytes in 0 blocks ==87067== still reachable: 950,153 bytes in 2,028 blocks ==87067== suppressed: 0 bytes in 0 blocks ==87067== Reachable blocks (those to which a pointer was found) are not shown. ==87067== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==87067== ==87067== For lists of detected and suppressed errors, rerun with: -s ==87067== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Only memory leaks, but no jumps based on uninitialized values. There is no difference with the master branch: I kept double-checking since I thought I had already applied the fix. So thanks a lot to Mark for hosting the buildbot! > >> 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 >> index c50f63208de..b0d7494f063 100644 >> --- a/gcc/rust/lex/rust-lex.h >> +++ b/gcc/rust/lex/rust-lex.h >> @@ -144,7 +144,7 @@ public: >> /** >> * Lex the contents of a string instead of a file >> */ >> - static Lexer lex_string (std::string input) >> + static Lexer lex_string (std::string &input) >> { >> // We can perform this ugly cast to a non-const char* since we're only >> // *reading* the string. This would not be valid if we were doing any > > That is, revert commit f7ff6020f8c68e4fb54c17c4460aa7f8a31f85bd > "lexer: Improve safety by taking ownership of the tokenized string". ;-) Yes haha. But I'd like to add a little more explanation and a FIXME comment saying that we should think of a better way to handle this. >> This forces the string to simply be a reference and the caller to make >> sure that it outlives the lexer. >> If this passes the valgrind tests, I'll open up a PR with a comment >> explaining the behavior and how we should think about cleaning >> it up. > > I don't have time right now to think throught the C++ aspects, but I've > quickly tested this, and yes, with that we've got: > > [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/ -xrs -nostdinc /dev/null -S -o /dev/null -fself-test=[...]/source-gcc/gcc/testsuite/selftests > -fself-test: 65613 pass(es) in 0.301854 seconds > > ... as well as "clean" Valgrind results (just some lost memory etc., as > before). Perfect. Thank you so much for taking the time to run it. I will open a pull-request for this. I wish you all a very pleasant afternoon and thank you for helping with this! Kindly, Arthur > > Grüße > Thomas > > >> Moral of the story is: fmemopen(3) does not allocate memory in all >> cases, RTFM >> >>>> I can easily test any patches that you need tested. >>> >>> >>> Grüße >>> Thomas >>> >>> >>>>> On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge <thomas@codesourcery.com> wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> On 2022-03-02T00:15:41+0100, Mark Wielaard <mark@klomp.org> wrote: >>>>>>> On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@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: <unknown> >>>>>>>> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com> >>>>>>>> >>>>>>>> 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 >> >> Thanks a lot, >> >> -- >> Arthur Cohen <arthur.cohen@embecosm.com> >> >> Toolchain Engineer >> >> Embecosm GmbH >> >> Geschäftsführer: Jeremy Bennett >> Niederlassung: Nürnberg >> Handelsregister: HR-B 36368 >> www.embecosm.de >> >> Fürther Str. 27 >> 90429 Nürnberg >> >> >> Tel.: 091 - 128 707 040 >> Fax: 091 - 128 707 077 > ----------------- > 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 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
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/1716 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/1630 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/1641 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/1619 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/1365 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/175 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The Buildbot
On Sun, Mar 06, 2022 at 10:01:10PM +0000, buildbot@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/1716
>
> Buildbot URL: https://builder.wildebeest.org/buildbot/
>
> Worker for this Build: debian-arm64
>
> Build Reason: <unknown>
> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com>
>
> BUILD FAILED: failed 'grep unexpected ...' (failure)
And the same for all other arches. The unexpected fails or in the rust.log:
Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O0 -lm -o ./macros6.exe (timeout = 300)
spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O0 -lm -o ./macros6.exe
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
compiler exited with status 1
FAIL: rust/execute/torture/macros6.rs -O0 (test for excess errors)
Excess errors:
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
UNRESOLVED: rust/execute/torture/macros6.rs -O0 compilation failed to produce executable
Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O1 -lm -o ./macros6.exe (timeout = 300)
spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O1 -lm -o ./macros6.exe
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
compiler exited with status 1
FAIL: rust/execute/torture/macros6.rs -O1 (test for excess errors)
Excess errors:
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
UNRESOLVED: rust/execute/torture/macros6.rs -O1 compilation failed to produce executable
Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O2 -lm -o ./macros6.exe (timeout = 300)
spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O2 -lm -o ./macros6.exe
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
compiler exited with status 1
FAIL: rust/execute/torture/macros6.rs -O2 (test for excess errors)
Excess errors:
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
UNRESOLVED: rust/execute/torture/macros6.rs -O2 compilation failed to produce executable
Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O3 -g -lm -o ./macros6.exe (timeout = 300)
spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O3 -g -lm -o ./macros6.exe
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
compiler exited with status 1
FAIL: rust/execute/torture/macros6.rs -O3 -g (test for excess errors)
Excess errors:
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
UNRESOLVED: rust/execute/torture/macros6.rs -O3 -g compilation failed to produce executable
Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -Os -lm -o ./macros6.exe (timeout = 300)
spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -Os -lm -o ./macros6.exe
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
compiler exited with status 1
FAIL: rust/execute/torture/macros6.rs -Os (test for excess errors)
Excess errors:
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
UNRESOLVED: rust/execute/torture/macros6.rs -Os compilation failed to produce executable
Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o ./macros6.exe (timeout = 300)
spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o ./macros6.exe
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
compiler exited with status 1
FAIL: rust/execute/torture/macros6.rs -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors)
Excess errors:
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
UNRESOLVED: rust/execute/torture/macros6.rs -O2 -flto -fno-use-linker-plugin -flto-partition=none compilation failed to produce executable
Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -lm -o ./macros6.exe (timeout = 300)
spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -lm -o ./macros6.exe
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
compiler exited with status 1
FAIL: rust/execute/torture/macros6.rs -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
Excess errors:
/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope
UNRESOLVED: rust/execute/torture/macros6.rs -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable
Hi, On Sun, Mar 06, 2022 at 11:20:56PM +0100, Mark Wielaard wrote: > On Sun, Mar 06, 2022 at 10:01:10PM +0000, buildbot@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/1716 > > > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > > > Worker for this Build: debian-arm64 > > > > Build Reason: <unknown> > > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> > > > > BUILD FAILED: failed 'grep unexpected ...' (failure) > > And the same for all other arches. The unexpected fails or in the rust.log: > > Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O0 -lm -o ./macros6.exe (timeout = 300) > spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O0 -lm -o ./macros6.exe > /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope > compiler exited with status 1 > FAIL: rust/execute/torture/macros6.rs -O0 (test for excess errors) > Excess errors: > /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope > UNRESOLVED: rust/execute/torture/macros6.rs -O0 compilation failed to produce executable This seems to have been resolved by a followup commit: commit 58d1721529e99c7c633615e7491b777a6198ed00 (github/pr/985) Author: Arthur Cohen <arthur.cohen@embecosm.com> Date: Tue Mar 1 10:41:45 2022 +0100 macroinvocation: Only allow *stmt* visitors when semicoloned All, except debian-i386, are green again: https://builder.wildebeest.org/buildbot/#/builders?tags=gccrust Cheers, Mark
[-- Attachment #1.1.1: Type: text/plain, Size: 3172 bytes --] Hi Mark, On 3/6/22 23:33, Mark Wielaard wrote: > Hi, > > On Sun, Mar 06, 2022 at 11:20:56PM +0100, Mark Wielaard wrote: >> On Sun, Mar 06, 2022 at 10:01:10PM +0000, buildbot@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/1716 >>> >>> Buildbot URL: https://builder.wildebeest.org/buildbot/ >>> >>> Worker for this Build: debian-arm64 >>> >>> Build Reason: <unknown> >>> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> >>> >>> BUILD FAILED: failed 'grep unexpected ...' (failure) >> >> And the same for all other arches. The unexpected fails or in the rust.log: >> >> Executing on host: /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O0 -lm -o ./macros6.exe (timeout = 300) >> spawn -ignore SIGHUP /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../gccrs -B/var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs-build/gcc/testsuite/rust/../../ /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs -fdiagnostics-plain-output -O0 -lm -o ./macros6.exe >> /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope >> compiler exited with status 1 >> FAIL: rust/execute/torture/macros6.rs -O0 (test for excess errors) >> Excess errors: >> /var/lib/buildbot/workers/wildebeest/gccrust-debian-arm64/gccrs/gcc/testsuite/rust/execute/torture/macros6.rs:10:13: error: Cannot find path 'Foo' in this scope >> UNRESOLVED: rust/execute/torture/macros6.rs -O0 compilation failed to produce executable > > This seems to have been resolved by a followup commit: Yes, I felt bad making Philip review an enormous commit and decided to instead keep it split-up despite not all the tests passing. All the commits in that set compile, but they don't all pass some macro tests. > > commit 58d1721529e99c7c633615e7491b777a6198ed00 (github/pr/985) > Author: Arthur Cohen <arthur.cohen@embecosm.com> > Date: Tue Mar 1 10:41:45 2022 +0100 > > macroinvocation: Only allow *stmt* visitors when semicoloned > > All, except debian-i386, are green again: > https://builder.wildebeest.org/buildbot/#/builders?tags=gccrust > > Cheers, > > Mark Hope it's all good, Kindly, -- Arthur Cohen <arthur.cohen@embecosm.com> Toolchain Engineer Embecosm GmbH Geschäftsführer: Jeremy Bennett Niederlassung: Nürnberg Handelsregister: HR-B 36368 www.embecosm.de Fürther Str. 27 90429 Nürnberg Tel.: 091 - 128 707 040 Fax: 091 - 128 707 077 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
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/1720 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/1634 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/1645 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/1623 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/1369 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/179 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed compile (failure) Sincerely, -The Buildbot
[-- Attachment #1.1.1: Type: text/plain, Size: 3471 bytes --] Hi, This is due to the lexer's fix not being in yet. I think it should be resolved later as soon as bors merges the fix, but I'll check just in case. Sorry for the noise, Kindly, Arthur On 3/7/22 10:49, buildbot@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/1720 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: debian-arm64 > > Build Reason: <unknown> > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> > > BUILD FAILED: failed compile (failure) > > Sincerely, > -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/59/builds/1634 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: fedora-x86_64 > > Build Reason: <unknown> > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> > > BUILD FAILED: failed compile (failure) > > Sincerely, > -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/60/builds/1645 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: fedora-ppc64le > > Build Reason: <unknown> > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> > > BUILD FAILED: failed compile (failure) > > Sincerely, > -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/61/builds/1623 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: fedora-ppc64 > > Build Reason: <unknown> > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> > > BUILD FAILED: failed compile (failure) > > Sincerely, > -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/63/builds/1369 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: fedora-s390x > > Build Reason: <unknown> > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> > > BUILD FAILED: failed compile (failure) > > Sincerely, > -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/64/builds/179 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: debian-ppc64 > > Build Reason: <unknown> > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> > > BUILD FAILED: failed compile (failure) > > Sincerely, > -The Buildbot > [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
Hi, On Mon, 2022-03-07 at 10:57 +0100, Arthur Cohen wrote: > This is due to the lexer's fix not being in yet. I think it should > be > resolved later as soon as bors merges the fix, but I'll check just in > case. According to: https://builder.wildebeest.org/buildbot/#/builders?tags=gccrust It was fixed by: commit 7a3c935c0f220835c001307944587a84c5af0192 Author: Philip Herron <philip.herron@embecosm.com> Date: Fri Mar 4 13:45:34 2022 +0000 Check if this constant item might already be compiled Which is slightly odd, because that isn't a lexer fix. So I suspect the bug is still there, but is hidden again. Cheers, Mark
[-- Attachment #1.1.1: Type: text/plain, Size: 1692 bytes --] On 3/7/22 15:23, Mark Wielaard wrote: > Hi, > > On Mon, 2022-03-07 at 10:57 +0100, Arthur Cohen wrote: >> This is due to the lexer's fix not being in yet. I think it should >> be >> resolved later as soon as bors merges the fix, but I'll check just in >> case. > > According to: > https://builder.wildebeest.org/buildbot/#/builders?tags=gccrust > > It was fixed by: > > commit 7a3c935c0f220835c001307944587a84c5af0192 > Author: Philip Herron <philip.herron@embecosm.com> > Date: Fri Mar 4 13:45:34 2022 +0000 > > Check if this constant item might already be compiled > > Which is slightly odd, because that isn't a lexer fix. > So I suspect the bug is still there, but is hidden again. I've checked the master branch, and the lexer is fixed there. I've checked out the commit you mentionned, and running git blame on it shows that the fix was introduced in 45eac5686867: commit 45eac568686745af73848f6c238fefcd87e315de (HEAD, origin/lexer-string-lifetime, lexer-string-lifetime) Author: Arthur Cohen <arthur.cohen@embecosm.com> Date: Wed Mar 2 15:18:40 2022 +0100 lexer: Add reference and warning documentation Fixes the -fself-test invalid memory accesses and adds documentation regarding a possible future fix. Co-authored-by: tschwinge <thomas@schwinge.name> Co-authored-by: philberty <philip.herron@embecosm.com> Which is the proper commit. I suspect this might be due to bors, our merging bot on github, and me asking it to merge multiple pull requests this morning (around 4 or 5). Not really sure. But the bug is fixed and properly placed in the history :) All the best, Arthur [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
Hi Arthur, On Mon, 2022-03-07 at 15:32 +0100, Arthur Cohen wrote: > I suspect this might be due to bors, our merging bot on github, and me > asking it to merge multiple pull requests this morning (around 4 or 5). > Not really sure. > > But the bug is fixed and properly placed in the history :) Aha, I see, you are right. For some reason bors adds commits on top of old commits with a merge instead of doing a simple rebase on top of the latest commit. Making the git history look like a Christmas tree: https://code.wildebeest.org/git/mirror/gccrs/log/ Your new commits were indeed on top of a 5 day old commit, so the buildbot dutifully tested it in context. And that context didn't include the fix yet. Would it make sense to tell bors to do a rebase instead of a merge before pushing to trunk? Cheers, Mark
[-- Attachment #1.1.1: Type: text/plain, Size: 1232 bytes --] Hi Mark, On 3/7/22 15:42, Mark Wielaard wrote: > Hi Arthur, > > On Mon, 2022-03-07 at 15:32 +0100, Arthur Cohen wrote: >> I suspect this might be due to bors, our merging bot on github, and me >> asking it to merge multiple pull requests this morning (around 4 or 5). >> Not really sure. >> >> But the bug is fixed and properly placed in the history :) > > Aha, I see, you are right. For some reason bors adds commits on top of > old commits with a merge instead of doing a simple rebase on top of the > latest commit. Making the git history look like a Christmas tree: > https://code.wildebeest.org/git/mirror/gccrs/log/ > > Your new commits were indeed on top of a 5 day old commit, so the > buildbot dutifully tested it in context. And that context didn't > include the fix yet. > > Would it make sense to tell bors to do a rebase instead of a merge > before pushing to trunk? > > Cheers, > > Mark I've checked, and I don't think that bors is able to do that. Since it maintains a staging queue containing multiple PRs and then merges it onto the main branch if all tests pass, I think the christmas tree is unavoidable. I'd be happy to be proved wrong however. Kindly, Arthur [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
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/1770 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/59/builds/1684 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64le while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/60/builds/1695 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64le Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/61/builds/1673 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-fedora-s390x while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/63/builds/1419 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The BuildbotThe Buildbot has detected a new failure on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/64/builds/229 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-ppc64 Build Reason: <unknown> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> BUILD FAILED: failed 'grep unexpected ...' (failure) Sincerely, -The Buildbot
[-- Attachment #1: Type: text/plain, Size: 1829 bytes --] Hi, On Tue, Mar 22, 2022 at 12:41:01PM +0000, buildbot@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/1770 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: debian-arm64 > > Build Reason: <unknown> > Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>, bors[bot] <26634292+bors[bot]@users.noreply.github.com> > > BUILD FAILED: failed 'grep unexpected ...' (failure) This is on all arches and happened after: commit f8c550f7e19c79c98f6d21ad6ce68d615451459a Author: Arthur Cohen <arthur.cohen@embecosm.com> Date: Fri Mar 18 13:20:09 2022 +0100 macros: Only expand merged repetitions if they contain the same amount of matches Forbid merging repetitions if the matched fragments do not contain the same amount of repetitions But I am not sure how/why. The last step fails with: grep unexpected gcc/testsuite/rust/rust.sum; test $? -eq 1 # of unexpected failures 9 But that canot be seen in the saved rust.sum or rust.log files... So something is going wrong there. It seems the buildbot captured the wrong logs because I can see the failures in rust.log for the worker. See the attached rust.log file which has several errors like: /srv/buildbot/worker/gccrust-fedora-x86_64/gccrs/gcc/testsuite/rust/compile/macro26.rs:7:13: error: Failed to match any rule within macro compiler exited with status 1 FAIL: rust/compile/macro26.rs at line 3 (test for errors, line 2) FAIL: rust/compile/macro26.rs (test for excess errors) Excess errors: /srv/buildbot/worker/gccrust-fedora-x86_64/gccrs/gcc/testsuite/rust/compile/macro26.rs:7:28: error: expecting ',' but ';' found Cheers, Mark [-- Attachment #2: rust.log.gz --] [-- Type: application/gzip, Size: 76370 bytes --]
[-- Attachment #1.1.1: Type: text/plain, Size: 2706 bytes --] Hi everyone, Sorry for the failure! Here's the explanation of why it happened: I created a pull request for a64a5cf77c9685aa623ec69168e7f50324a102b9: ``` commit a64a5cf77c9685aa623ec69168e7f50324a102b9 (origin/invalid-macro-match-fix, invalid-macro-match-fix) Author: Arthur Cohen <arthur.cohen@embecosm.com> Date: Fri Mar 18 11:34:39 2022 +0100 macros: Do not propagate parse errors in match repetitions Since parsing repetitions is very eager, the parser might accumulate bogus errors by trying to match more repetitions than there are. We can avoid this by clearing the parsing errors if parsing repetitions returned a valid result. This should not be an issue for previous matchers erroring out, as they would immediately return upon failure and not reach inside other match functions. ``` Roughly at the same time, I also created one for the following commit: ``` commit f8c550f7e19c79c98f6d21ad6ce68d615451459a (origin/repetition-fragments-must-refer-to-the-same-amount, repetition-fragments-must-refer-to-the-same-amount) Author: Arthur Cohen <arthur.cohen@embecosm.com> Date: Fri Mar 18 13:20:09 2022 +0100 macros: Only expand merged repetitions if they contain the same amount of matches Forbid merging repetitions if the matched fragments do not contain the same amount of repetitions ``` The later commit requiring the first one to pass all tests (otherwise, some spurious errors were present). To make Philip's reviewing process easier, I developped the second commit while having cherry-picked the first one, but created the pull request without it: This way, changes were easier to see and did not need as much digging around. Likewise, Philip would not have to review the same commit twice. Once Philip was done reviewing, I asked bors to rebase both pull requests, the second one after the first. Meaning that on the current master branch, all tests are passing, since the second commit was applied on top of the first. Nonetheless, bors also applies all commits when merging, meaning there is a stray 'second commit' without the first one, causing the testsuite to fail. The later commits should resolve the situation. Next time, I'll wait for the first pull request to be merged and rebase the second one on top of it. Sorry for the noise! Kindly, -- Arthur Cohen <arthur.cohen@embecosm.com> Toolchain Engineer Embecosm GmbH Geschäftsführer: Jeremy Bennett Niederlassung: Nürnberg Handelsregister: HR-B 36368 www.embecosm.de Fürther Str. 27 90429 Nürnberg Tel.: 091 - 128 707 040 Fax: 091 - 128 707 077 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]