Re: gnu as
Is it similar to the gnu as86 assembly compiler? Actually, I just hope to have a separate branch of the as86 assembly compiler Replied Message | From | Jonathan Wakely | | Date | 08/19/2023 14:29 | | To | h3140067...@163.com | | Cc | gcc | | Subject | Re: gnu as | On Sat, 19 Aug 2023, 00:21 h3140067568--- via Gcc, wrote: Hi, I am an open-source enthusiast from China. I really like the cross platform features of AS assembly compilers. I hope the community can independently open source a branch of the backend assembly compiler of GCC compiler in gcc.gnu.org, just like nasm, and continuously improve it through open source I'm not sure what you mean, but maybe the Binutils project is what you want.
Re: Testsuite issue and warning about floating-point conversion
Hi Jakub, I should have pinged you, I see you recently touched that code. FX > Le 18 août 2023 à 21:07, FX Coudert a écrit : > > Hello, > > On the WIP aarch64-darwin port of GCC > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite > failures which are due to the following: > > 1. The testsuite check_effective_target_has_q_floating_suffix check tries to > compile the code "float dummy = 1.0q;” to determine if the q suffix is > allowed on floating-point types. > > 2. The check should pass on aarch64-darwin, and indeed the code compiles, > because the q suffix matches the _Float128 type. > > 3. However, a warning is emitted which makes the test fail: > > a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater > conversion rank >1 | float dummy = 1.0q; > | ^~~~ > > > 4. Therefore, the expectations of the different tests fail. > > > Now, I am not sure why other targets are not affected in the same way, for > example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning > warranted here? If so, we should adjust the check to silence warnings, or use > a cast. Or is the warning emitted in error? > > Any help would be appreciated. > > Thanks, > FX
Re: gnu as
On Sat, 19 Aug 2023 at 09:58, h3140067...@163.com wrote: > Is it similar to the gnu as86 assembly compiler? Actually, I just hope to > have a separate branch of the as86 assembly compiler > I don't know what GNU as86 is, but GCC does not have any assembler. GCC uses your system's assembler, which will be the GNU Binutils 'as' on many systems (proprietary UNIX systems tend to have their own 'as' that isn't the one from Binutils). > > Replied Message > From Jonathan Wakely > Date 08/19/2023 14:29 > To h3140067...@163.com > Cc gcc > Subject Re: gnu as > > > On Sat, 19 Aug 2023, 00:21 h3140067568--- via Gcc, > wrote: > >> Hi, I am an open-source enthusiast from China. I really like the cross >> platform features of AS assembly compilers. I hope the community can >> independently open source a branch of the backend assembly compiler of GCC >> compiler in gcc.gnu.org, just like nasm, and continuously improve it >> through open source >> > > I'm not sure what you mean, but maybe the Binutils project is what you > want. > > >
Re: Testsuite issue and warning about floating-point conversion
On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc wrote: > > Hello, > > On the WIP aarch64-darwin port of GCC > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite > failures which are due to the following: > > 1. The testsuite check_effective_target_has_q_floating_suffix check tries to > compile the code "float dummy = 1.0q;” to determine if the q suffix is > allowed on floating-point types. > > 2. The check should pass on aarch64-darwin, and indeed the code compiles, > because the q suffix matches the _Float128 type. > > 3. However, a warning is emitted which makes the test fail: > > a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater > conversion rank > 1 | float dummy = 1.0q; > | ^~~~ > > > 4. Therefore, the expectations of the different tests fail. > > > Now, I am not sure why other targets are not affected in the same way, for > example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning > warranted here? If so, we should adjust the check to silence warnings, or use > a cast. Or is the warning emitted in error? It's probably because 1.0q produces __float128 on those targets, not _Float128. In C++23 _Float128 (and _Float32 etc.) have special rules about implicit conversions to other floating-point types. I don't know why 1.0q is _Float128 on aarch64 instead of __float128. I was going to suggest that using 'long double dummy = 1.0q' instead of 'float' would help, but IIRC the Apple M1 ABI says that long double is the same type as double, and so 'long double' would still have lower conversion rank than _Float128. An explicit cast prevents the warning: float dummy = (float) 1.0q;
Re: Testsuite issue and warning about floating-point conversion
Hi,
> I don't know why 1.0q is _Float128 on aarch64 instead of __float128.
That’s weird. I create it in this way:
+ /* Populate the float128 node if it is not already done so that the FEs
+ know it is available. */
+ if (float128_type_node == NULL_TREE)
+{
+ float128_type_node = make_node (REAL_TYPE);
+ TYPE_PRECISION (float128_type_node) = 128;
+ SET_TYPE_MODE (float128_type_node, TFmode);
+ layout_type (float128_type_node);
+}
+
+ lang_hooks.types.register_builtin_type (float128_type_node, "__float128");
> An explicit cast prevents the warning:
> float dummy = (float) 1.0q;
Yes, I think a cast does the job. It will still error out when q suffix is not
supported, and will not have other messages.
FX
Re: Testsuite issue and warning about floating-point conversion
On Sat, Aug 19, 2023 at 10:25:50AM +0100, Jonathan Wakely wrote: > On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc wrote: > > > > Hello, > > > > On the WIP aarch64-darwin port of GCC > > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite > > failures which are due to the following: > > > > 1. The testsuite check_effective_target_has_q_floating_suffix check tries > > to compile the code "float dummy = 1.0q;” to determine if the q suffix is > > allowed on floating-point types. > > > > 2. The check should pass on aarch64-darwin, and indeed the code compiles, > > because the q suffix matches the _Float128 type. > > > > 3. However, a warning is emitted which makes the test fail: > > > > a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater > > conversion rank > > 1 | float dummy = 1.0q; > > | ^~~~ > > > > > > 4. Therefore, the expectations of the different tests fail. > > > > > > Now, I am not sure why other targets are not affected in the same way, for > > example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning > > warranted here? If so, we should adjust the check to silence warnings, or > > use a cast. Or is the warning emitted in error? > > It's probably because 1.0q produces __float128 on those targets, not > _Float128. In C++23 _Float128 (and _Float32 etc.) have special rules > about implicit conversions to other floating-point types. > > I don't know why 1.0q is _Float128 on aarch64 instead of __float128. That seems like a bug in the aarch64-darwin port. 1.0q should definitely be __float128 rather than _Float128. The c-lex.cc code has: /* For Q suffix, prefer float128t_type_node (__float128) type over float128_type_node (_Float128) type if they are distinct. */ if (type == float128_type_node && float128t_type_node) type = float128t_type_node; Now, the generic tree.cc initialization will initialize float128_type_node (i.e. _Float128) to some floating point type if there is IEEE quad mode backend support, and float128t_type_node (i.e. __float128) to float128_type_node, and c-family/c-common.cc later on will: /* For C, let float128t_type_node (__float128 in some backends) be the same type as float128_type_node (_Float128), for C++ let those be distinct types that mangle and behave differently. */ if (c_dialect_cxx ()) float128t_type_node = NULL_TREE; i.e. __float128 and _Float128 are the same type for C and for C++ distinct, then i386, ia64 and rs6000 backends create their own float128t_type_node as distinct types. q/w suffixes aren't supported at all unless the backend overrides c.mode_for_suffix target hook, and besides the above 3 arches only aarch64 and pa do that. pa does that iff it it registers __float128 type as an alias to long double and aarch64 except for Darwin does that as well. So, if aarch64-darwin wants 64-bit long double, the question is if it should have __float128 support and q suffix support at all. If it should, then it needs to initialize float128t_type_node to a distinct type if NULL like i386, ia64 and rs6000 backends do (i.e. for C++). Jakub
Re: Testsuite issue and warning about floating-point conversion
On Sat, Aug 19, 2023 at 11:58:31AM +0200, Jakub Jelinek via Gcc wrote: > well. So, if aarch64-darwin wants 64-bit long double, the question is if > it should have __float128 support and q suffix support at all. If it > should, then it needs to initialize float128t_type_node to a distinct type > if NULL like i386, ia64 and rs6000 backends do (i.e. for C++). Oh, and as the comment say, one needs to decide how to mangle the types. long_double_type_node, even when distinct from double_type_node, will mangle unless overridden as e (double d), and float128_type_node as DF128_. __float128 should mangle per Itanium ABI mangling as g (unless overridden) but backend needs to do that. Also, one needs to decide what _Float16 and __bf16 mangles as, whether the Itanium ABI DF16_ and DF16b or something different (aarch64-linux mangles the latter as u6__bf16 instead). See what clang does as well... Jakub
Re: Testsuite issue and warning about floating-point conversion
Hi, > That seems like a bug in the aarch64-darwin port. > 1.0q should definitely be __float128 rather than _Float128. Is there a simple way to test what type 1.0q is, in C? I tried using _Generic, but it says > a.c:7:52: error: ‘_Generic’ specifies two compatible types > 7 | int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2); > |^ > a.c:7:37: note: compatible type is here > 7 | int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2); > | ^~ Then: > /* For C, let float128t_type_node (__float128 in some backends) be the > same type as float128_type_node (_Float128), for C++ let those > be distinct types that mangle and behave differently. */ OK so my mistake is in not defining float128t_type_node in the aarch64-darwin port. I will do that. Am I correct in reading that this “new” way of handling extended types in C++ was introduced in 2022-09-27? If so, my port to aarch64-darwin was done two years ago, and that explains why I missed that entirely… Thanks a lot Jakub for the help! FX
Re: Testsuite issue and warning about floating-point conversion
On Sat, 19 Aug 2023, 11:45 FX Coudert, wrote: > Hi, > > > That seems like a bug in the aarch64-darwin port. > > 1.0q should definitely be __float128 rather than _Float128. > > Is there a simple way to test what type 1.0q is, in C? I tried using > _Generic, but it says > > > a.c:7:52: error: ‘_Generic’ specifies two compatible types > > 7 | int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2); > > |^ > > a.c:7:37: note: compatible type is here > > 7 | int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2); > > | ^~ > > > Then: > > > /* For C, let float128t_type_node (__float128 in some backends) be the > > same type as float128_type_node (_Float128), for C++ let those > > be distinct types that mangle and behave differently. */ > > OK so my mistake is in not defining float128t_type_node in the > aarch64-darwin port. I will do that. Am I correct in reading that this > “new” way of handling extended types in C++ was introduced in 2022-09-27? Yes, this is a new C++23 feature first supported in gcc 13. If so, my port to aarch64-darwin was done two years ago, and that explains > why I missed that entirely… > > Thanks a lot Jakub for the help! > FX
gcc-13-20230819 is now available
Snapshot gcc-13-20230819 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20230819/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision b823634589d5f3fa98e5d904e3b4680b23fc7ba9 You'll find: gcc-13-20230819.tar.xz Complete GCC SHA256=0ddc4dcfab3120064a8c6712986a75891d1c77d4e3c19f3003292d87bb19692c SHA1=37deb4a9a4277b5325f33585d78772941bcafcff Diffs from 13-20230812 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
