On Thu, Dec 19, 2024 at 12:01 AM Richard Sandiford
wrote:
>
> In a later patch, I need to add "@" to a pattern that uses subst
> iterators. This combination is problematic for two reasons:
>
> (1) define_substs are applied and filtered at a later stage than the
> handling of "@" patterns, so
Hello-
This patch helps tools like contrib/compare_tests work out of the box for the
libitm testsuite. Without this change, compare_tests complains if the test
runs being compared were in different build directories.
I just moved the -B argument from one place to another, so the command line
exec
Not many newlib targets (IIRC the only targets where
int32_t is a typedef of long int) build libgfortran.
Building and testing fortran testsuite is usually a cheap
way to get additional coverage for a port, except that a
couple of times a year, there are these silly type-related
breakages.
Maybe
Richard, a bunch of things you address are in my bailwick.
When Jim and I set out to create a COBOL front end, I knew *NOTHING*
about, well, anything vis-à-vis GCC. I barely knew how it worked. Some
things I had to figure out even before I knew how to figure anything outl
notably, creating funct
Hello,
On 23/12/2024 17:55, Patrick Palka wrote:
Just to reiterate: if the projection returns an rvalue, it would be wrong for
the predicate to actually move from it, as it would violate the
equality-preserving semantic requirements of regular_invocable? I'll add the
missing forward then.
IIUC
Hi PA,
(next try, for some reasons, my original email disappeared.)
Paul-Antoine Arras wrote:
Replying to your last two messages here and attaching revised patches.
Regarding the C++ and ME patches:
==> 0003-C-fix.patch <==
Subject: [PATCH 3/4] C++ fix
==> 0004-ME-fixes.patch <==
Subject:
Ok for trunk and releases/gcc-14?
--
Test assumes libatomic.a is always available, but for some embedded
targets, there is no libatomic.a and the test thus fail.
libstdc++/ChangeLog:
* 29_atomics/atomic_float/compare_exchange_padding.cc: Use
effective-target libatomic_available.
On Sun, Dec 22, 2024 at 08:59:00PM -0300, Alexandre Oliva wrote:
> Hello, Dimitar,
>
> On Dec 22, 2024, Dimitar Dimitrov wrote:
>
> > On Sat, Dec 21, 2024 at 02:28:33AM -0300, Alexandre Oliva wrote:
> >> On Dec 20, 2024, Jakub Jelinek wrote:
> >>
> >> > On Wed, Dec 18, 2024 at 12:59:11AM -0300
Am 23.12.24 um 18:51 schrieb Jerry D:
On 12/23/24 9:19 AM, Harald Anlauf wrote:
Dear all,
while preparing the testcase null_actual_7.f90 for commit r15-6408,
I overlooked a corner case, leading to a regression (PR118179).
The obvious solution is to extend the suppression of copying back
the poi
On 12/23/24 9:19 AM, Harald Anlauf wrote:
Dear all,
while preparing the testcase null_actual_7.f90 for commit r15-6408,
I overlooked a corner case, leading to a regression (PR118179).
The obvious solution is to extend the suppression of copying back
the pointer also for NULL actual arguments to
Hi,
This is the 4th ping of the middle end review for the patch set.
Really appreciate any comments and suggestions from Middle-end reviewer
on this patch (the diagnostic part of the patch has been reviewed and approved
already).
As I know, Kees and Sam have been using this option for a while a
Dear all,
while preparing the testcase null_actual_7.f90 for commit r15-6408,
I overlooked a corner case, leading to a regression (PR118179).
The obvious solution is to extend the suppression of copying back
the pointer also for NULL actual arguments to pointer dummies
with no specified intent.
R
Hi, Kees,
(Sorry for the late reply, I was on vacation last week).
I read all the comments of PR117178 and also your patch.
Yes, I think the behavior of this patch is reasonable. The updated diagnostic
messages are more accurate and helpful.
And the testing cases look good.
I am wondering wh
On Sat, 21 Dec 2024, Giuseppe D'Angelo wrote:
> Hello,
>
> On 20/12/2024 22:20, Patrick Palka wrote:
> > > > The attached patch fixes it. I've tested on Linux x86-64. Adding a
> > > > negative test for this is somehow challenging (how do you test you're
> > > > not using a dangling reference?), b
Hi Paul,
thanks for the quick review. Pushed as gcc-15-6425-gdae506f73bd
Thanks again,
Andre
On Mon, 23 Dec 2024 15:13:50 +
Paul Richard Thomas wrote:
> Hi Andre,
>
> It looks good to me.
>
> Thanks
>
> Paul
>
>
> On Mon, 23 Dec 2024 at 14:58, Andre Vehreschild wrote:
>
> > Hi all
sorry for my stupid mistake, forgot v2, it's just same as v1 and see v3
On Mon, Dec 23, 2024 at 11:15 PM Kito Cheng wrote:
>
> ---
> gcc/config/riscv/autovec-opt.md | 16 ++--
> gcc/config/riscv/autovec.md | 30 +++
> gcc/config/riscv/riscv-v.cc | 4 +-
> gcc/confi
`.MASK_LEN_FOLD_LEFT_PLUS`(or `mask_len_fold_left_plus_m`) is expecting the
return value will be the start value even if the length is 0.
However current code gen in RISC-V backend is not meet that semantic, it will
result a random garbage value if length is 0.
Let example by current code gen for
On 12/19/24 12:56 AM, Robin Dapp wrote:
From: Yunze Zhu
Fix a bug th.vsetvli generates from vext_x_v with an imm operand,
which reports illegal operand. This patch fix this by replacing
imm operand with reg operand in th.vsetvli.
LGTM but you might want to add check force_vector_length_ope
On 12/18/24 5:04 PM, Lewis Hyatt wrote:
Hello-
Happened to notice this minor issue that seems worth fixing. bootstrap +
regtest on x86-64, is it OK please? Thanks!
-Lewis
-- >8 --
It seems that tokens_buff_new() has always been allocating the virtual
location buffer 4 times larger than int
---
gcc/config/riscv/autovec-opt.md | 16 ++--
gcc/config/riscv/autovec.md | 30 +++
gcc/config/riscv/riscv-v.cc | 4 +-
gcc/config/riscv/vector-iterators.md | 46 +++
gcc/config/riscv/vector.md | 118 +++
5 files changed, 1
Oh and I realized I send wrong version which didn't contain the
changelog, test case and the description, let me send the v2 first
On Mon, Dec 23, 2024 at 11:05 PM Kito Cheng wrote:
>
> On Mon, Dec 23, 2024 at 10:35 PM Robin Dapp wrote:
> >
> > > +;; Integer Reduction (vred(sum|maxu|max|minu|min
Hi Andre,
It looks good to me.
Thanks
Paul
On Mon, 23 Dec 2024 at 14:58, Andre Vehreschild wrote:
> Hi all,
>
> I did an ooppsie with the patch for 107635. Attached is a patch that fixes
> this. Essentially the regexp was to complicated for what was needed. So
> now we
> just count the numbe
Hi Tobias,
Replying to your last two messages here and attaching revised patches.
On 16/12/2024 22:34, Tobias Burnus wrote:
I have not looked in depth at the patch, but managed to
write C-ism code, which caused a segfault (due to a missing "call"),
after gfortran issued a reasonable error. Can
On 12/22/24 6:19 PM, Hans-Peter Nilsson wrote:
I could do it just for target mmix, but that wouldn't help other
simulator targets. Using different primes is deliberate.
Ok to commit?
-- >8 --
Running tests in parallel on my 4.5y+ old laptop made this
test time out: the test itself runs in 9m
On 12/23/24 6:11 AM, Simon Martin wrote:
'make tags' currently fails for libcc1 with this:
*** No rule to make target `marshall-c.hh', needed by `tags-am'. Stop.
The problem is that while marshall-c.hh has been removed via
r12-454-g25d1a6ecdc443f, it's still part of the libcc1_la_SOURCES
v
Hi Paul,
please run the style-checker on the patch before pushing.
Furthermore, shouldn't that
+changed, the dtype updating and the correct rank used. */
rather be
+changed, the dtype updated and the correct rank used. */
^^
B
On Mon, Dec 23, 2024 at 10:35 PM Robin Dapp wrote:
>
> > +;; Integer Reduction (vred(sum|maxu|max|minu|min|and|or|xor).vs), but for
> > auto vectorizer
> > +(define_insn "@pred_av_"
> > + [(set (match_operand: 0 "register_operand" "=vr")
> > + (unspec:
> > + [(unspec:
> >
> from output_constant_pool_2 and make it defer to native_encode_rtx
> instead. That seems like the most direct way of avoiding mishaps.
>
> E.g. another way in which different routines could make different choices
> is in whether, for SVE's VNx8BI (say), they fill the upper bit of each
> 2-bit el
Hi all,
I did an ooppsie with the patch for 107635. Attached is a patch that fixes
this. Essentially the regexp was to complicated for what was needed. So now we
just count the number of occurrences of caf_get_by_ct, which has to be four.
Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?
Rega
> +;; Integer Reduction (vred(sum|maxu|max|minu|min|and|or|xor).vs), but for
> auto vectorizer
> +(define_insn "@pred_av_"
> + [(set (match_operand: 0 "register_operand" "=vr")
> + (unspec:
> + [(unspec:
> + [(match_operand: 1 "vector_mask_operand" "vmWc
---
gcc/config/riscv/autovec-opt.md | 16 ++--
gcc/config/riscv/autovec.md | 30 +++
gcc/config/riscv/riscv-v.cc | 4 +-
gcc/config/riscv/vector-iterators.md | 46 +++
gcc/config/riscv/vector.md | 118 +++
5 files changed, 1
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/fortran/pr111395.f90: Move this file to...
* gfortran.target/riscv/rvv/pr111395.f90: ...here.
* gcc.target/riscv/rvv/fortran/pr111566.f90: Move this file to...
* gfortran.target/riscv/rvv/pr111566.f90: ...here.
'make tags' currently fails for libcc1 with this:
*** No rule to make target `marshall-c.hh', needed by `tags-am'. Stop.
The problem is that while marshall-c.hh has been removed via
r12-454-g25d1a6ecdc443f, it's still part of the libcc1_la_SOURCES
variable, hence the 'tags' target has a dependen
> Am 23.12.2024 um 10:57 schrieb Robin Dapp :
>
>
>>
>> I don't quite understand - you are checking loop_vinfo->vector_mode, but
>> how can you be sure no chosen vector uses a !VECTOR_MODE_P? It seems
>> fragile to rely on (it might work in this case), instead when any
>> !VECTOR_MODE_P nee
> I don't quite understand - you are checking loop_vinfo->vector_mode, but
> how can you be sure no chosen vector uses a !VECTOR_MODE_P? It seems
> fragile to rely on (it might work in this case), instead when any
> !VECTOR_MODE_P needs a 'len' we should reject it - so why does this
> not happen h
On Mon, Dec 23, 2024 at 2:52 PM wrote:
>
> From: Yunze Zhu
>
> Fix a bug th.vsetvli generates from vext_x_v with an imm operand,
> which reports illegal operand. This patch fix this by replacing
> imm operand with reg operand in th.vsetvli.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vset
On Mon, 23 Dec 2024 at 05:58, Andrew Pinski wrote:
>
> On Fri, Dec 13, 2024 at 6:31 AM Christophe Lyon
> wrote:
> >
> > On Tue, 10 Dec 2024 at 13:14, Richard Earnshaw (lists)
> > wrote:
> > >
> > > On 09/12/2024 21:11, Christophe Lyon wrote:
> > > > In this PR, we have to handle a case where MVE
Hi All,
These bugs were tricky to find because neither were detected by regression
testing on my platform.
PR116254: This bug was sporadic even where the regression was detected.
Richard Sandiford found "Conditional jump or move depends on uninitialised
value" errors in the library, triggered by
38 matches
Mail list logo
