Update the C/C++ preprocessor built-in macros sections

[xen0n]

Also part of the discussions started at #24 and #25.

[xen0n]

self nit: “MIPS 风格” might be better

[yetist]

loongarch 相关的预定义宏，看起来有大写的，也有小写的，是不是讨论一下，在遵循习惯的基础上能保持统一规律。

[xen0n]

loongarch 相关的预定义宏，看起来有大写的，也有小写的，是不是讨论一下，在遵循习惯的基础上能保持统一规律。

大写的那部分都是“复制粘贴批量替换”时代的遗留。主要前面一段时间有些人跑得太快了，非要在工具链完整进上游之前就开始往下游刷补丁，所以才要保留支持。否则最后一张表整个可以全部删除。

这个处理我认为就遵循 #27 的思路即可。面向用户的文档不提及相关特性，各大编译器已经支持的保留支持，不支持的不添加支持，以后再渐渐把已有支持用 warning 等等方式干掉。

[xen0n]

Rebased to latest; opinions ppl?

[xen0n]

Review ping

[xen0n]

Review ping

[xen0n]

Ping? @scylaac @yetist @xry111 @ChenghuaXu

[xen0n]

Ping; others, opinions?

[xry111]

最新的内核代码还在用 _LOONGARCH_SZ*。

[xen0n]

最新的内核代码还在用 _LOONGARCH_SZ*。

我已回复建议修改。。

[xry111]

最新的内核代码还在用 _LOONGARCH_SZ*。

我已回复建议修改。。

除了这个，应该世界上没有别的地方用这些旧宏了。OK。

[xen0n]

最新的内核代码还在用 _LOONGARCH_SZ*。

我已回复建议修改。。

除了这个，应该世界上没有别的地方用这些旧宏了。OK。

还是有一些地方的，所以仍然需要作兼容处理。这就是技术人员需要有一些审美的必要性。。。

[xry111]

最新的内核代码还在用 _LOONGARCH_SZ*。

我已回复建议修改。。

除了这个，应该世界上没有别的地方用这些旧宏了。OK。

还是有一些地方的，所以仍然需要作兼容处理。这就是技术人员需要有一些审美的必要性。。。

好像主要就是 boehm GC 和 xv6，boehm GC 需要修一下，至于 xv6 坑学生本身就是教学用操作系统的一项任务 (狗头)

[xen0n]

Review ping

[xen0n]

我今天跟同事闲聊，聊到这篇文档，他看了有的预处理器符号大写，有的小写，他就问为什么；可见大小写不一致还是比较影响第一印象的。

[xen0n]

Rebased, please take a look? @xry111 @yetist @scylaac @FreeFlyingSheep @ChenghuaXu @chenglulu326

[xry111]

__loongarch64 目前内核，libgcc，以及 libffi 在用，__loongarch_grlen 目前 glibc 在用。

这里大概解释一下它们的问题：目前我们对 __loongarch_grlen 的使用存在错误，等 ILP32 成型以后会有人在 64 位机器上运行 32 位程序，他可能用下面的方式编译该 32 位程序需要的库：

gcc foo.c -shared -O2 -march=la464 -mabi=ilp32d -o libfoo.so.2

这样就会出现问题：由于 -march=la464 告诉编译器 CPU 的 GR 是 64 位的，编译器会定义 __loongarch_grlen 为 64，所以用 __loongarch_grlen 判断 ABI 是 LP64 还是 ILP32 的代码会炸掉。

__loongarch64 目前实现为“当且仅当 __loongarch_grlen == 64 时被定义”。所以用它判 ABI 也会出同样的问题，而且这和 __x86_64__ (用 x32 ABI 的话它也会置位)，__mips64 (N32 ABI 的话它也会置位) 是一致的。由于 __mips64 的误用，已经有东西炸掉了。

但是我感觉至少 __loongarch_grlen 还是保留比较好，因为不论 ABI 去判 GR 的宽度也是一种合理的需求。__loongarch64 由于存在歧义确实可以 deprecate 后删除。

[xen0n]

这个是我眼瞎，我从 2021 年开始就从未怀疑它有问题（之前只是看它是两个下划线开头，结尾没有下划线，加上全小写字母，就觉得它跟 RISC-V 风格很相似而略过了），直到你前几天提到这玩意规范里没写，才猛然醒悟它其实是 __mips64 的 1:1 等价物……

__loongarch_grlen 和 __loongarch_lp64 / __loongarch_XXX_float 对应的是两种不同的合理需求，都应该保留。__loongarch64 表达的语义完全可由 __loongarch_grlen == 64 替代，唯一就是稍微短一点；鉴于一件如此简单的事情都有多种方式完成，不够简洁，且使用 __loongarch_grlen 可以避免在未来出现其他 GRLEN 的时候引入新符号，因而不应当保留 __loongarch64。现有的代码都要抽空去改掉。。

[xry111]

RISC-V 大量用 __riscv_xlen 判定 ABI，所以很多人 (包括我) 就照猫画虎写 __loongarch_grlen == 64 了。刚才才想起来 RISC-V 的指令操作数长度是和寄存器宽度直接绑定的，所以不可能 -march=rv64 -mabi=ilp32……

[xen0n]

我才刚刚发现，__LP64__（以及 _LP64）和 __loongarch_lp64 意思完全一样，而且 __LP64__ 还架构无关。。

我们是不是把 __loongarch_lp64 都干掉最好呢？

[xry111]

我才刚刚发现，__LP64__（以及 _LP64）和 __loongarch_lp64 意思完全一样，而且 __LP64__ 还架构无关。。

我们是不是把 __loongarch_lp64 都干掉最好呢？

__LP64__ 和 _LP64 出自 GCC，而不是 C 标准 (标准的预定义宏在另一节)。如果我们要移植一个新编译器，可能维护人员并不愿意引入没有命名空间前缀的非标准预定义宏。

而且本文档应该完全不要提这些架构无关的 GCC 预定义宏，它们就是 GCC 自己搞的一套，和 LoongArch 没有必然的关系，我们也没法非得要求其他编译器定义它们。

[xen0n]

有一些道理，我看下把 gcc-specific 的内容去掉。

[xen0n]

Ping again?

[scylaac]

LGTM.

后续会另开一个 PR 增补关于 -march=native 和 -mtune=native 的说明。

[xen0n]

按照 @xry111 的评论，准备把特定于 gcc 的一部分宏从本文中去掉。今晚之前改一版

[xen0n]

不过刚才检查了 clang，他也提供了 __SIZEOF_XXX__、__LP64__ 这些东西，我估计是因为 gcc 深受群众喜爱，以至于不支持那些符号已经无法做到兼容大部分软件了。可能换一下措辞引入这些内容会比较好。@xry111 觉得呢？

[xry111]

不过刚才检查了 clang，他也提供了 __SIZEOF_XXX__、__LP64__ 这些东西，我估计是因为 gcc 深受群众喜爱，以至于不支持那些符号已经无法做到兼容大部分软件了。可能换一下措辞引入这些内容会比较好。@xry111 觉得呢？

我觉得直接丢个链接就好了

https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

[xry111]

不过刚才检查了 clang，他也提供了 __SIZEOF_XXX__、__LP64__ 这些东西，我估计是因为 gcc 深受群众喜爱，以至于不支持那些符号已经无法做到兼容大部分软件了。可能换一下措辞引入这些内容会比较好。@xry111 觉得呢？

而且 clang 这个东西应该是有历史原因，在 clang 出现之前 LLVM 官配的 C-family 编译器是一个改过的，产生 LLVM IR 的 GCC，所以重写前端的时候应该把这些也直接抄来了。

[ChenghuaXu]

先改文档？再处理gcc中的代码？看记录，其他地方都不用了。

[xen0n]

先改文档？再处理gcc中的代码？看记录，其他地方都不用了。

删那些 MIPS 风格宏定义是吧，可以这么搞，文档我晚点修订，现在在上班