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, so
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] &&) &D.2497->b>)[0]
so
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
> *
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 statem
... 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): Ne
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 t
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]
../../.
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. c
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 pla
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
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
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 to
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
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 aarch64-apple-da
14 matches
Mail list logo