Bootstrapping from `bootstrap.c`, issues compiling `zig2.c` with `tcc` and `slimcc`

[fuhsnn]

These are encountered at the $CC -o zig2 zig2.c compiler_rt.c -std=c99 ... step, with shell command ulimit -s unlimited to workaround stack-overflow mentioned at issue #22111

Here in stage1/zig.h, cpuid.h is included on any x86-64 compiler that is not MSVC. This header may not be present if the C compiler implemented their own preprocessor, tcc, slimcc as well as pcc, cparser, currently don't provide it.

zig/stage1/zig.h

Lines 11 to 17 in aa7d138

	#if _MSC_VER
	#include <intrin.h>
	#elif defined(__i386__) || defined(__x86_64__)
	#include <cpuid.h>
	#endif

With #include <cpuid.h> commented out (to see what lies ahead), tcc and slimcc failed at, respectively:

The zig_import macro use the non-standard __asm convention for function aliasing on any compiler not MSVC. slimcc stopped here, as its maintainer I will implement it ASAP.

zig/stage1/zig.h

Lines 224 to 234 in aa7d138

	#if _MSC_VER
	#define zig_import(Type, fn_name, libc_name, sig_args, call_args) zig_extern Type fn_name sig_args;\
	__pragma(comment(linker, "/alternatename:" zig_mangle_c(#fn_name) "=" zig_mangle_c(#libc_name)));
	#define zig_import_builtin(Type, fn_name, libc_name, sig_args, call_args) zig_import(Type, fn_name, sig_args, call_args)
	#else /* _MSC_VER */
	#define zig_import(Type, fn_name, libc_name, sig_args, call_args) zig_extern Type fn_name sig_args __asm(zig_mangle_c(#libc_name));
	#define zig_import_builtin(Type, fn_name, libc_name, sig_args, call_args) zig_extern Type libc_name sig_args; \
	static inline Type fn_name sig_args { return libc_name call_args; }
	#endif

tcc stopped at this point,

zig/stage1/zig.h

Lines 1250 to 1252 in aa7d138

	typedef struct { zig_align(16) uint64_t hi; uint64_t lo; } zig_u128;
	typedef struct { zig_align(16) int64_t hi; uint64_t lo; } zig_i128;
	#endif

since it does not advertise __has_attribute((aligned)) and the build driver passes -std=c99, zig_align expands to zig_align_unavailable as the result of these two macro, failing the compilation.

zig/stage1/zig.h

Lines 132 to 146 in aa7d138

	#if zig_has_attribute(aligned)
	#define zig_under_align(alignment) __attribute__((aligned(alignment)))
	#elif _MSC_VER
	#define zig_under_align(alignment) __declspec(align(alignment))
	#else
	#define zig_under_align zig_align_unavailable
	#endif
	#if __STDC_VERSION__ >= 201112L
	#define zig_align(alignment) _Alignas(alignment)
	#else
	#define zig_align(alignment) zig_under_align(alignment)
	#endif

[alexrp]

since it does not advertise __has_attribute((aligned)) and the build driver passes -std=c99, zig_align expands to zig_align_unavailable as the result of these two macro, failing the compilation.

Does it work when passing -std=gnu99?

[fuhsnn]

-std=gnu99 is the same, -std=c11 helps
https://godbolt.org/z/joGY53an5

[alexrp]

It seems odd that TCC wouldn't have any way of specifying alignment pre-C11. __attribute__((aligned(...))) (and its MSVC equivalent) is one of those things you see in a ton of real-world C projects. I also doubt glibc headers even work without it...?

[fuhsnn]

With -std=c11 tcc stops at:
zig2.c:8800: error: identifier expected
which is
typedef zig_under_align(1) struct zig_Client_Message_Header__23850 anon__aligned_3467;
in term expands to:
typedef zig_align_unavailable(1) struct zig_Client_Message_Header__23850 anon__aligned_3467;
https://godbolt.org/z/5vsnxrvYf

[fuhsnn]

I also doubt glibc headers even work without it...?

glibc does the #define __attribute__(x) /* empty */ trick in its headers for non-__GNUC__ compilers, so the compiler won't see the attributes if they follow the #define.

I actually put a special case in slimcc's preprocessor to resist the define to make it work out of the box with glibc while still recognize the attributes, epoll.h for example would loose packed attribute, creating ABI mismatch if you obey glibc's define.
https://github.com/fuhsnn/slimcc/blob/fd14b7d38ee757c53956fcf5bf88fe40a0c27c65/preprocess.c#L815

[alexrp]

That's what I mean; I'm surprised TCC can even be used to compile real, working programs when it ends up with ABI mismatches like this. That makes me wonder if there's something I'm missing.

[alexrp]

Maybe the issue here is just that, while TCC supports __attribute__((aligned(...))) and friends, it doesn't speak __has_attribute?

[fuhsnn]

Looks like tcc:

1. supports __attribute__(aligned) when not affect by glibc
2. supports __has_attribute
3. reports 0 with __has_attribute(aligned)

https://godbolt.org/z/4E4K4Pecr

[alexrp]

Curiously enough, I can't find any mention of __has_attribute in the TCC source code... 🤔

[alexrp]

❯ cat test.c
#include <stdio.h>
int main()
{
#ifdef __has_attribute
    printf("has attribute\n");
#endif
}
❯ tcc -run test.c
❯ tcc -dM -E - < /dev/null | grep __has_attribute
❯

Same deal with a fresh tcc built from the mob branch.

I have no idea what's going on with the TCC on godbolt.

[alexrp]

Yeah, seriously, what's going on here? https://godbolt.org/z/9ce99jvEr

[fuhsnn]

I think it's here: https://repo.or.cz/tinycc.git/blob/HEAD:/include/tccdefs.h#l155
155 #define __has_attribute(x) 0

So it will be 0 no matter the input, stuff like this was how Autoconf came to be...