[uvclang] Basic support for C++ language features. by jslap · Pull Request #44 · maximecb/uvm

jslap · 2026-09-24T02:50:30Z

No std library support yet.
Added freestanding compiler switch to avoid using host headers. Since Freestanding -> no-builtins, added support for all math functions

No std library support yet. Added freestanding compiler switch to avoid using host headers. Since Freestanding -> no-builtins, added support for all math functions

jslap · 2026-09-24T02:55:01Z

Trying to see how far C++ support can be pushed. Starting with plain C++ with no libraries.

I have very little exp. with Rust: Do not hesitate to tell me what is not idiomatic or what is plainly wrong!

maximecb · 2026-10-04T13:41:03Z

                    Value::Global(name) if name.starts_with("__uvm_") => {
                        self.gen_syscall(ctx, inst.dest.as_deref(), name, ret_ty, args)?;
                    }
+                    Value::Global(name) if syscalls::SYSCALL_NAMES.contains(&name.as_str())  => {
+                        self.gen_syscall(ctx, inst.dest.as_deref(), &("__uvm_".to_owned()+name), ret_ty, args)?;
+                    }


Does the new case you added here basically supercede the first one? If so we should remove the older one?

it is two different cases: the former is explicit calls to uvm_ functions, the later is calls that are lowered to uvm_ functions.

Ok but there should be no more need to have _uvm syscalls given the chaneges you made in syscalls.h, if I'm not mistaken?

You're right! Technically, we could replace all the '_uvm' calls in the C std implementation with the corresponding non-uvm calls. But now, I'm wondering if we should, in fact, do the opposite:

Right now, we are "polluting" the global namespace with names like print_i64, which could break a C program that would be working on a regular C compiler. So maybe we should only keep the '_uvm' version (which, because they are prefixed with reserved __ would not break user code). Then we could add some function alias (using __attribute__((alias("original_function"))) wich is not yet supported by the parser, BTW) on memset, memcmp etc. .

Good point. Are the names included in the global namespace for everyone? How it was in the uvclang C compiler is that the names are only available if you include the uvm header. That's what we would want.

I think we should either stick with the way the C version was doing it (if possible), or use your function alias idea (I'm assuming that would be in the header, no longer polluting the global namespace?). If the function alias can achieve the same thing but cleaner I'm very much open to it.

In C, adding a function in a std lib header should only be done if it starts with '__' or one underscore and an uppercase letter. In C++, it is about the same rule (unless the functions are in a non-std namespace.)

So this was kind of broken before, and still is with this MR.

Another thing that was broken was the preproc definition for memset, memcpy and such. It should be possible to take the function pointer. But this part is fixed with this MR.

As a first MR, I tried to be the less disruptive that I could; If it is ok, I think cleaning up the global namespace could be part of another MR.

Supporting function alias will also be needed for some other C++ std lib functionalities, but I think it would be better to implement it in a separate MR, if possible.

I wouldn't mind trying to do them both!

Sure thing. I'll merge this PR, and if you have the motiviation for one or two more PRs with function aliases and then implementing a better solution for the UVM header / UVM primitives, I would be happy with that :)

Thanks for contributing 🙏

maximecb

Makes sense over all but it would be good to maybe add tests with a few more C++ features such as functions with the same name but different argument types, and virtual functions or inheritance if that's currently working. ie: testing the C++ features that do work with these changes.

jslap · 2026-10-04T15:49:01Z

Thanks for the review.

I added a new test for virtual methods.
Overloaded functions are already covered by the "cpp_class" test; I can put it in its own test file if needed.

Everything using c++ libraries is not working (new, etc...), but I have it working locally, so I might have other MRs coming.

maximecb · 2026-10-07T19:42:26Z

Added some minor comments but I think it's basically ready

[uvclang] Basic support for C++ language features.

b895685

No std library support yet. Added freestanding compiler switch to avoid using host headers. Since Freestanding -> no-builtins, added support for all math functions