compiler_rt: export floorl

[jcmoyer]

This fixes a linker error when compiling with VS2022 on Windows:

zig1.obj : LNK2019: unresolved external symbol floorl referenced in function Sema.coerceInMemoryAllowedPtrs [D:\zig\build\zig.vcxproj]

I'm not entirely sure this is the correct place to export or if it should go into one of the conditional branches above.

E: So actually this is the classic C thing where long double isn't necessarily bigger than double, this will probably require some more thought. I'm going to have a closer look at what andrew suggested in IRC (related: #7265) since it looks like there's a better way to write this already in std/special/c_stage1.zig.

[jcmoyer]

Is it correct to delete code from c_stage1.zig as it is moved to compiler_rt or will this cause problems elsewhere?

[matu3ba]

@jcmoyer As compiler_rt is intended to match LLVM (see the README), this does not look like the right place to me.
Another argument for keeping it matching to LLVM is simpler review, tests and fuzzing.

So personally I think another structure resembling compiler_rt sounds useful for this and I communicated it here.
see below.

[andrewrk]

This looks OK to merge to me. What's the problem as it stands?

Is it correct to delete code from c_stage1.zig as it is moved to compiler_rt or will this cause problems elsewhere?

Yes it is correct 👍

[andrewrk]

compiler_rt is intended to match LLVM

It's not intended to match LLVM exactly. It already has extra things for Zig to rely on that are not provided by LLVM's compiler-rt. See #7265 for more details.

[matu3ba]

It's not intended to match LLVM exactly.

I find it confusing to call the document compiler_rt.zig, when it is not describing/abstracting the files in the folder compiler_rt/ (which is ported and reimplemented from LLVM).
In llvm you have this with a differentiation between builtins, sanitizer runtimes, profile and BlocksRuntime.

A small README of the structure would be nice and personally I would finding a rename of the folder compiler_rt to builtin more clear on what is happening, if the object export is simpler in one file.

@LemonBoy What is your take on this?

[LemonBoy]

@LemonBoy What is your take on this?

IMO compiler-rt must follow LLVM's structure (of course with the only exception of our custom stack probes) which in turn (loosely) follows libgcc, having one extra CU is better than shoving everything into a single huge file (ir.cpp flashbacks intensify).

But let's take one step back. You don't want floorl, what you want is to get around this LLVM problem by implementing some custom lowering in stage1/stage2 like it's being done for fmaq.

#7265 arguments are weak, merging everything together doesn't simplify anything for developers nor for the average user.

[andrewrk]

merging everything together doesn't simplify anything for developers nor for the average user.

one thing is simpler than two things. what's the argument for having two things? is it to follow some standard? but already we see that llvm's compiler-rt, libgcc, and msvc's equivalent are subtly different. the only realistic way to make sure everything works is to provide every symbol ourselves, but allow overriding (which is why we use weak_odr linkage).

plus we have zig-specific stuff that requires non-"standard" symbols, such as math with arbitrary sized integers which we will need to lower to a compiler-rt call of a function that llvm's compiler-rt will never have. #1485

also, as this pull request demonstrates, this solves a problem that is currently causing windows to not link, precisely because of the improved simplicity of compiler-rt having more of the, well, compiler's runtime!

what you want is to get around this LLVM problem

Thank you for making that patch upstream btw.