First of all thank you! These are quite some nice enhancements, and it's great to see them documented.
On Tue, 18 Apr 2023, Lulu Cheng wrote: > + <li>The new command-line option <code>-mexplicit-relocs</code> > decides whether > + to use or not use the assembler relocation operator when dealing > with Here it is sufficient to say "to use" (and skip "or not to use"), since "whether" indicates this kind of choice. > + symbolic addresses. <code>-mexplicit-relocs</code> is enabled by > default > + when GCC is configured to use a compatible assembler. We could say "It" instead of listing the option again. That's just an idea, you can keep it as is if you prefer. > + </li> > + <li>Avoid using the GOT to access external symbols when the new > + <code>-mdirect-extern-access</code> command-line option is > specified. > + </li> > + <li>The <a > href="https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Variable-Attributes.html#LoongArch-Variable-Attributes";><code>model</code></a> > + variable attributes has been added. "attribute" (singular) to match "has". > + <li>Built-in functions support Improvements</li> Maybe just say "Built-in functions"? > + <li>The <code>rint</code> and <code>copysign</code> mathematical > builtins > + (and their float variants) are now inplemented as inline "implemented" > + float variants) are now inplemented as inline LoongArch intrinsics > when using "implemented" > + (and their float variants) are now inplemented as inline LoongArch > intrinsics "implemented" > + <li>Subprojects Support</li> ^^^^^ > + <ul> > + <li><code>libvtv</code> now supports LoongArch architecture.</li> > + <li><code>libitm</code> now supports LoongArch architecture.</li> > + <li>LoongArch supports address sanitizers other than > <code>hwasan</code> and <code>tsan</code>.</li> > + </ul> Here, and in the other cases, the closing </li> (that I marked aboved) should follow </ul>, since both the heading and the <ul> are part of the same list item. (See the RISC-V entry, for example.) This change is fine with the changes highlighted above. (If you prefer, I can have another look; it's not required, though.) Gerald
