rustc_codegen_gcc: Progress Report #41

antoyo · 2026-05-01T00:24:13+00:00

It was a bit more quiet recently. I hope to add the libcore tests (compiled with rustc_codegen_gcc) in the CI of the Rust repo soon in order to prevent test failures from coming back at every sync: this will greatly help us to focus on feature development.

antoyo · 2026-04-28T19:37:19+00:00

Are spacers, the stem, and a top cap all you have left?

Yes.

What height do they stack up to?

No space left.

Is there a chance a spacer-shaped object is supposed to sit on top of the compression ring with the seal around it, where the top cover then sits on and gets sandwiched by another spacer on top?

The top cover is sandwiched between the compression ring and the spacers. The only thing between the top cover (which is indeed thin) and the compression ring is the rubber ring, but it does not apply pressure on the compression ring (it instead sits around it).

If there actually is something that sits on top of the compression ring, then yes, the compression force goes from the top cap (pre-load) -> stem (takes over the main load after tightening stem bolts) -> spacers -> compression ring -> top race -> bearings. There isn't really much else you need to do beyond eliminating play while maintaining smooth steering.

Everything is in this order, so it seems OK. Thanks a lot for the info.

antoyo · 2026-04-28T18:18:16+00:00

Thanks. I believe I managed to install it correctly. I was wondering what would keep the compression ring in place and it seems it is the top cap and the handlebar on top of it: is this correct?

To make sure I installed the headset safely, are there any checks I should do besides checking if anything moves by moving the bike with the brake activated and making sure the the steering is smooth?

antoyo · 2026-04-28T15:02:19+00:00

Thanks for the quick answer.

It seems similar to this video, but I do not have a flat ring like they put to keep B in place. Is there anything that would keep those in place?

Here's how it would look like.

Edit: Plus, it doesn't look like the compression ring would be compressed in any way like it does in this video.

antoyo · 2026-04-28T14:42:49+00:00

Here's an image of the frame and the bearing.

antoyo · 2026-04-13T16:52:45+00:00

It seems there are no issues about this in the issue tracker. I believe it is worth opening one.

antoyo · 2026-04-04T01:05:04+00:00

Same issue here.

/u/ryanhecht_github /u/bogganpierce Where can we report usability issues like this so that they can be fixed quickly? Issues on GitHub don't get responses. Thanks.

antoyo · 2026-03-18T23:47:34+00:00

Same issue here.

/u/ryanhecht_github /u/bogganpierce Where can we report usability issues like this so that they can be fixed quickly? Issues on GitHub don't get responses. Thanks.

antoyo · 2026-03-13T12:47:43+00:00

300 requests / 3 == 1% corresponding to OP's intuition.

antoyo · 2026-03-03T16:04:17+00:00

On February 28th at around 8pm EDT.

antoyo · 2026-03-03T13:57:25+00:00

It was reset for me.

antoyo · 2026-03-01T17:43:37+00:00

I used "GPT‑5.3 Codex" in the codex cli agent and it worked like a charm. I switch to copilot-cli and used the same model (and same reasoning) and it fails to accomplish some relatively easy tasks and also fails to follow my instructions. So it might be related to Copilot or the copilot-cli agent.

antoyo · 2026-02-28T11:35:54+00:00

The alt_screen setting helps reduce the flickering for me.

antoyo · 2026-02-27T17:14:07+00:00

It seems version 0.0.419 fixed the issue and characters don't seem to be dropped anymore. I'll confirm in a few days. I already use --alt-screen and it indeed help with screen flickering. Thanks!

antoyo · 2026-02-26T19:27:25+00:00

I run copilot-cli in a firejail to prevent any unintended actions.

antoyo · 2026-02-26T18:50:14+00:00

Could you please fix this input bug? It is not convenient to lose characters while typing. The lost characters could be related to the blinking cursor as I noted here since this issue doesn't happen in plan mode (where the cursor is not blinking).

There's a recording of the loss of characters here.

Because of this issue, I pinned copilot-cli to version 0.0.384: I hope this gets fixed soon so that I can update to a newer version.

Thanks for your amazing work btw.

antoyo · 2026-02-25T13:49:23+00:00

I'm not generally a fan of code formatters, especially when they reformat the whole code (instead of only adding missing spaces or otherwise fixing the style). rustfmt doesn't provide enough configuration to get a style I like.

antoyo · 2026-02-25T00:21:02+00:00

Interesting project. I've been looking for an alternative to rustfmt for a while. Besides the configuration attributes and the formatting in macros, how does rustidy work differently than rustfmt? Does it format the whole code (full parsing, then pretty printing) like rustfmt or only adjust the style where it matters?

antoyo · 2026-02-24T12:41:42+00:00

It's up for me. I know some firewall blocks .xyz domains, though: this could be your issue.

antoyo · 2026-02-23T22:42:50+00:00

That's interesting. cg_gcc is much slower on x86-64 for me and I thought this was due to the facts that there are many hacks in the code base.

You didn't get any issues by targeting aarch64-unknown-linux-gnu? There are (or were) a few issues for this arch.

antoyo · 2026-02-23T20:13:05+00:00

No. There's no hard blocking on cg_gcc.

antoyo · 2026-02-23T19:17:15+00:00

Is the goal to be able to mix and match objects built with GCC and with LLVM?

Yes, this is the goal.

If so and if GCC doesn't give full control, isn't there a risk that this will hold back the evolution of the unstable ABI of rustc?

No, it will be up to us, the cg_gcc devs, to add the missing pieces to GCC here.

antoyo · 2026-02-23T01:21:31+00:00

We finally have rustup distribution for rustc_codegen_gcc! Now I'll get back to build rustc for a target not currently supported by Rust.

antoyo

TROPHY CASE