On Sat, 30 Dec 2023, 01:24 Hans-Peter Nilsson, wrote:
> Tested for mmix and observing the increased timeout in the .log
> file - and the test passing.
>
> Ok to commit? Or better suggestions?
>
OK to commit, thanks.
> -- >8 --
> Testing for mmix (a 64-bit target using Knuth's simulator). Th
On Sat, 30 Dec 2023, 01:41 Hans-Peter Nilsson, wrote:
> I'm not completely sure I got the intent of the "log2_limit",
> or whether "limit" is sane to decrease like this; it just
> looked like an obvious and safe reduction. Also, I verified
> the 10+ minute runtime, on this same host (clocked at
Hi Rimvydas,
Documentation part.
The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings.
Thanks for your work on this!
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wordin
Replying to myself...
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wording?
Or maybe this is better:
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 4b83037a..d232f
chenxiaolong writes:
> After the detection of maximum reduction is enabled on LoongArch architecture,
> the regression test of GCC finds that vect-fmin-3.c fails. Currently, in the
> target-supports.exp file, only aarch64,arm,riscv, and LoongArch architectures
> are supported. Through analysis, th
Hi,
Ping on this patch.
TIA, have a lovely day and happy holidays!
--
Arsen Arsenović
signature.asc
Description: PGP signature
On Sat, 2023-12-30 at 12:15 +, Richard Sandiford wrote:
> This shouldn't be necessary. The test does:
>
> for (int i = 0; i < n; i += 2)
> {
> x0 = __builtin_fmin (x0, ptr[i + 0]);
> x1 = __builtin_fmin (x1, ptr[i + 1]);
> }
> res[0] = x0;
> res[1] = x1;
>
> __built
On Sat, 2023-12-30 at 20:25 +0800, Xi Ruoyao wrote:
> On Sat, 2023-12-30 at 12:15 +, Richard Sandiford wrote:
> > This shouldn't be necessary. The test does:
> >
> > for (int i = 0; i < n; i += 2)
> > {
> > x0 = __builtin_fmin (x0, ptr[i + 0]);
> > x1 = __builtin_fmin (x1, p
在 2023/12/30 下午8:25, Xi Ruoyao 写道:
On Sat, 2023-12-30 at 12:15 +, Richard Sandiford wrote:
This shouldn't be necessary. The test does:
for (int i = 0; i < n; i += 2)
{
x0 = __builtin_fmin (x0, ptr[i + 0]);
x1 = __builtin_fmin (x1, ptr[i + 1]);
}
res[0] = x0;
Ping^3
---
This patch adds a combine pass that runs late in the pipeline.
There are two instances: one between combine and split1, and one
after postreload.
The pass currently has a single objective: remove definitions by
substituting into all uses. The pre-RA version tries to restrict
itself t
This match pattern allows combination (zero_extract:DI 8, 24, QI)
with an sign-extend to 32bit INS instruction on TARGET_64BIT.
For SI mode, if the sign-bit is modified by bitops, we will need a
sign-extend operation. Since 32bit INS instruction can be sure that
result is sign-extended, and the Q
On Fri, Dec 29, 2023 at 09:14:52PM -0700, Jeff Law wrote:
> On 12/29/23 10:46, YunQiang Su wrote:
> >When we try to combine RTLs, the result may be very complex,
> >and `rtx_cost` may think that it need lots of costs. But in
> >fact, it may match a pattern in machine descriptions, which
> >may emit
On Sat, 30 Dec 2023, Jonathan Wakely wrote:
> On Sat, 30 Dec 2023, 01:41 Hans-Peter Nilsson, wrote:
> > Or perhaps the cause is known?
>
> Not to me. It probably is a target codegen bug, since all this test really
> does is emulate a wide integer type using masks and shifts.
If so, a generic co
Hi!
On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> This patch adds a combine pass that runs late in the pipeline.
But it is not. It is a completely new thing, and much closer to
fwprop than to combine, too.
Could you rename it to something else, please? Something less con
When I enable cgen rebuilding in the binutils-gdb tree, the default is
to run cgen using 'guile'. However, on my host, guile is guile 2.2,
which doesn't work for me -- I have to use guile3.0.
This patch arranges to pass "GUILE" down to subdirectories, so I can
use 'make GUILE=guile3.0'.
ChangeLo
> Right. But that's the whole point behind avoiding the narrowing subreg
> and forcing use of a truncate operation.
>
> So basically the question becomes is there a way to modify those bits in
> a way that GCC doesn't know that it needs to to truncate/extend?
>
I guess that this code may cause so
make: *** No rule to make target 'check-g++'. Stop.
gcc
* doc/install.texi (Testing): Correct check-g++ to
check-gcc-c++.
---
gcc/doc/install.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index d20b43
On Sat, Dec 30, 2023 at 11:26 PM YunQiang Su wrote:
>
> make: *** No rule to make target 'check-g++'. Stop.
>
> gcc
>
> * doc/install.texi (Testing): Correct check-g++ to
> check-gcc-c++.
Actually these targets exist in the gcc subdirectory.
Which is mentioned slightly above:
```
18 matches
Mail list logo
