On Wed, Dec 27, 2023 at 10:34 PM Harald Anlauf wrote:
> The patch is almost fine, except for a strange wording here:
>
> +@smallexample
> +gfortran -save-temps -c foo.F90
> +@end smallexample
> +
> +preprocesses to in @file{foo.fii}, compiles to an intermediate
> +@file{foo.s}, and then assembles
According to spec, fmv.h checks if the input operands are correctly
NaN-boxed. If not, the input value is treated as an n-bit canonical NaN.
This patch fixs the issue that operands returned by soft-fp16 libgcc
(i.e., __truncdfhf2) was not correctly NaN-boxed.
*gcc/ChangeLog:*
* config/riscv/ri
Notice current dynamic LMUL is not accurate for conversion codes.
Refine for it, there is current case is changed from choosing LMUL = 4 into
LMUL = 8.
Tested no regression, committed.
Before this patch (LMUL = 4): After this patch (LMUL = 8):
lw a7,56(sp)
Hi Rimvydas!
Am 24.12.23 um 02:33 schrieb Rimvydas Jasinskas:
Documentation part.
The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings.
The patch is almost fine, except for a strange wording here:
+@smallexample
+gfortran -save-temps -c foo.F90
+@end smallexample
+
+p
This patch hopefully fixes the test failure we see with gnu23-tag-4.c.
It does for me locally with -march=native (which otherwise reproduces
the problem).
Bootstrapped and regession tested on x86_64
C: Fix type compatibility for structs with variable sized fields.
This fixes the test gcc.dg/g
On Wed, 2023-12-27 at 11:59 +0800, chenglulu wrote:
> +FAIL: gcc.dg/pr86617.c scan-rtl-dump-times final "mem/v" 6
>
> In r14-6818 the issue persists. I kind of chased the code and found that the
> problem is like this:
> volatile unsigned char u8;
>
> void test (void)
> {
> u8 = u8 +
This patch adds a new tuning option 'AARCH64_EXTRA_TUNE_FULLY_PIPELINED_FMA',
to consider fully pipelined FMAs in reassociation. Also, set this option
by default for Ampere CPUs.
Tested on aarch64-unknown-linux-gnu. Is this OK for trunk?
Thanks,
Di Zhao
gcc/ChangeLog:
* config/aarch64/a
Committed at 6cec7b06b3c8187b36fc05cfd4dd38b42313d727
Thanks,
Di
> -Original Message-
> From: Richard Biener
> Sent: Friday, December 22, 2023 11:40 PM
> To: Di Zhao OS
> Cc: Thomas Schwinge ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH v4] [tree-optimization/110279] Consider FMA in
>
在 2023/12/27 下午4:46, Lulu Cheng 写道:
When cmodel=extreme, since the symbol address is obtained through four
instructions,
errors may occur in some cases during linking. Therefore, in order to ensure
that
the instructions for obtaining the symbol address are together, macro
instructions
are us
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_symbolic_constant_p):
Remove the sym+addend form from the SYMBOL_PCREL64 type symbol.
(loongarch_option_override_internal): Supports option combinations
of -cmodel=extreme and -mexplicit-relocs=none.
Instructions pcalau12i, addi.d, lu32i.d and lu52i.d must be adjancent so that
the
linker can infer the PC of pcalau12i to apply relocations to lu32i.d and
lu52i.d.
Otherwise, the results would be incorrect if these four instructions are not in
the same 4KiB page.
See the link for details:
https:
When cmodel=extreme, since the symbol address is obtained through four
instructions,
errors may occur in some cases during linking. Therefore, in order to ensure
that
the instructions for obtaining the symbol address are together, macro
instructions
are used to obtain the symbol address when cmo
> -Original Message-
> From: Haochen Jiang
> Sent: Thursday, December 21, 2023 4:26 PM
> To: gcc-patches@gcc.gnu.org
> Cc: ubiz...@gmail.com; Liu, Hongtao ;
> ger...@pfeifer.com
> Subject: [gcc-wwwdocs PATCH v2] gcc-13/14: Mention recent update for
> x86_64 backend
>
> Hi all,
>
> This i
Consider this following case:
int f[12][100];
void bad1(int v1, int v2)
{
for (int r = 0; r < 100; r += 4)
{
int i = r + 1;
f[0][r] = f[1][r] * (f[2][r]) - f[1][i] * (f[2][i]);
f[0][i] = f[1][r] * (f[2][i]) + f[1][i] * (f[2][r]);
f[0][r+2] = f[1][r+2] * (f[2][r+2]) -
14 matches
Mail list logo
