[PATCH] Libquadmath: add nansq() function

Hi, This patch adds nansq() to libquadmath, a function that returns a signalling NaN. It is a need for full libgfortran support of signalling NaNs, because not all targets that have _Float128 define a __builtin_nanq() function. Bootstrapped and tested on x86_64-pc-gnu-linux and

[PATCH, committed] PR 89639, fix testcase for targets without REAL128

Attached patch pushed as cb48166e52c0f159eb80a0666c4847825e294ec0 Confirmed by Dave to make the testcase pass on hppa-unknown-linux-gnu FX 0001-Fortran-Fix-test-on-targets-without-REAL128.patch Description: Binary data

Re: [gofrontend-dev] Re: Go patch committed: Don't pad epollevent on sparc64 GNU/Linux

On Fri, Dec 31, 2021 at 1:32 AM Jakub Jelinek wrote: > > The following patch adjusts the testcase for the above change. > Tested on x86_64-linux, ok for trunk? > > 2021-12-31 Jakub Jelinek > > * gcc.misc-tests/godump-1.c: Adjust for renaming of last > field from _align suffix

Re: [power-ieee128] gfortran, v2: Introduce gfc_type_abi_kind

Hi Jakub, Actually playing with that (e.g. for matmul) revealed a brown paper bag bug in the previous patch, fixed thusly: OK. Thanks a lot! Best regards Thomas

Re: [power-ieee128] libgfortran: Small progress on the library side

Hi Jakub, Ok for power-ieee128 branch? OK. Thanks for stepping up! I am a little distracted right now, but I think I will also continue working on this for a bit. Best regards Thomas

[power-ieee128] gfortran, v2: Introduce gfc_type_abi_kind

On Fri, Dec 31, 2021 at 03:16:47PM +0100, Jakub Jelinek via Gcc-patches wrote: > Haven't played enough with it to see if the various *_r17 or *_c17 > API entrypoints are called (but verified abi_kind is right in the > debugger), in all my attempts so far everything was emitted inline. Actually

[power-ieee128] gfortran: Introduce gfc_type_abi_kind

Hi! The following patch detects the powerpc64le-linux kind == 16 cases and for the -mabi=ieeelongdouble case (no matter whether it is the configured in default or just option used on the command line) uses _r17 or _c17 instead of _r16 or _c17 in the library API names. >From what I can see, e.g.

[power-ieee128] libgfortran: Small progress on the library side

Hi! The following patch quiets ../../../libgfortran/generated/in_pack_r17.c:35:1: warning: no previous prototype for ‘internal_pack_r17’ [-Wmissing-prototypes] ../../../libgfortran/generated/in_pack_c17.c:35:1: warning: no previous prototype for ‘internal_pack_c17’ [-Wmissing-prototypes]

[pushed] libgfortran: Fix bootstrap on targets without static_assert macro.

Although we build the library with GCC which is known to support _Static_assert this might be done on a system without the macro mapping static_assert to the compiler keyword. The use of static_assert introduced with r12-6126-g3430132f3e82 causes bootstrap to fail on such targets, fixed by using

[PATCH] testsuite: XFAIL some Wstringop-overflow tests ...

... for targets that support vectorization of 2-byte char stores with unaligned address at plain O2. 2021-12-31 Uroš Bizjak gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_vect_slp_store_usage): Handle TEST_V2QI_2. (check_effective_target_vect_slp_v2qi_store_unalign):

Re: [PATCH] objc: Fix handling of break stmt inside of switch inside of ObjC foreach [PR103639]

Hi Jakub, thanks for looking at this, > On 30 Dec 2021, at 09:33, Jakub Jelinek via Gcc-patches > wrote: > > The r11-3302-g3696a50beeb73f changes broke the following ObjC testcase. > in_statement is either 0 (not in a looping statement), various IN_* flags > for various kinds of looping

Re: Go patch committed: Don't pad epollevent on sparc64 GNU/Linux

On Wed, Dec 29, 2021 at 03:54:03PM -0800, Ian Lance Taylor via Gcc-patches wrote: > PR go/103847 > * godump.c (go_force_record_alignment): Name the alignment > field "_". > --- a/gcc/godump.c > +++ b/gcc/godump.c > @@ -651,7 +651,7 @@ go_force_record_alignment (struct obstack *ob, const char >

[PATCH] c++: Silence -Wuseless-cast warnings during move [PR103480]

Hi! This is maybe just a shot in the dark, but IMHO we shouldn't be diagnosing -Wuseless-cast on casts the compiler adds on its own when calling its move function. We don't seem to warn when user calls std::move either. We call move on elinit (*NON_LVALUE_EXPR <(struct C[2] &&) >b>)[0] so it is

[PATCH] c++: Fix ICEs with OBJ_TYPE_REF pretty printing [PR101597]

Hi! The following testcase ICEs, because middle-end uses the C++ FE pretty printing code through langhooks in the diagnostics. The FE expects OBJ_TYPE_REF_OBJECT's type to be useful (pointer to the class type it is called on), but in the middle-end conversions between pointer types are useless,