Hi Andre,
> thanks for testing and also for giving a solution. I was sure, I would break
> something. Fixed as obvious as gcc-15-7662-g08bdc2ac98a after regtesting ok on
> x86_64-pc-linux-gnu / Fedora 41 (which gets more unstable with every update I
> receive IMO). I opted for the __builtin_alloca
Hi Rainer,
thanks for testing and also for giving a solution. I was sure, I would break
something. Fixed as obvious as gcc-15-7662-g08bdc2ac98a after regtesting ok on
x86_64-pc-linux-gnu / Fedora 41 (which gets more unstable with every update I
receive IMO). I opted for the __builtin_alloca versio
Hi Harald,
seconding Thomas here, thanks for the patch.
- Andre
On Thu, 20 Feb 2025 21:18:01 +0100
Harald Anlauf wrote:
> Dear all,
>
> the attached simple patch addresses a small, left-over issue in the
> above PR and was already OK'ed in the PR by Thomas. With it we
> initialize the data co
Alexander pointed out the way to do a dg-bogus in an included header.
Tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/118521
* g++.dg/torture/pr118521.C: Use dg-bogus properly.
---
gcc/testsuite/g++.dg/torture/pr118521.C | 2 +-
1 file changed, 1 insertion(+), 1
Richard Sandiford writes:
> I think this would also simplify the evpc detection, since the requirement
> for using AND is the same for big-endian and little-endian, namely that
> index I of the result must either come from index I of the nonzero
> vector or from any element of the zero vector. (W
* James K. Lowden:
> As I mentioned in other posts, IMO (IANAL) the copyright in
> unimportant and probably unenforceable. The National Computing
> Centre no longer exists, and the document was also published by NIST
> which, as part of the US government, does not copyright its
> publications.
I
On Thu, Feb 20, 2025 at 07:41:26PM +0530, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> Changes to amo.h include the addition of the following load atomic operations:
> Compare and Swap Not Equal, Fetch and Increment Bounded, Fetch
>> diff --git a/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c
>> b/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c
>> index 0406f2c3595..e549cab84ca 100644
>> --- a/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c
>> +++ b/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c
>> @@ -3,7 +3,8 @@
>> int
>> foo (
Jan Hubicka writes:
>>
>> Thanks for running these. I saw poor results for perlbench with my
>> initial aarch64 hooks because the hooks reduced the cost to zero for
>> the entry case:
>>
>> auto entry_cost = targetm.callee_save_cost
>>(spill_cost_type::SAVE, hard_regno, mod
On Fri, 21 Feb 2025 01:17:15 + (UTC)
Joseph Myers wrote:
> > The Makefile fetches the NIST archive from our website.
>
> The normal build and test process ("make" and "make check") must
> never rely on any network connectivity.
Fair enough. I haven't added the NIST tests and documenta
Ping
On 2/12/25 16:30, Jørgen Kvalsvik wrote:
I have applied fixes for everything in the last review, plus some GNU
style fixes that I had missed previously. We have tested and used a
build with this applied for 3-4 months now and haven't run into any
issues.
Jørgen Kvalsvik (2):
gcov: branc
> On Feb 21, 2025, at 1:59 PM, Florian Weimer wrote:
>
> * James K. Lowden:
>
>> As I mentioned in other posts, IMO (IANAL) the copyright in
>> unimportant and probably unenforceable. The National Computing
>> Centre no longer exists, and the document was also published by NIST
>> which, as
Tom> While working on this I found a couple of paths in modified_type_die
Tom> where "mod_scope" should be used, but is not. I suspect these cases
Tom> are only reachable by Ada code, as in both spots (subrange types and
Tom> base types), I believe that other languages don't generally have named
T
* Paul Koning:
>> On Feb 21, 2025, at 1:59 PM, Florian Weimer wrote:
>>
>> * James K. Lowden:
>>
>>> As I mentioned in other posts, IMO (IANAL) the copyright in
>>> unimportant and probably unenforceable. The National Computing
>>> Centre no longer exists, and the document was also published b
On Fri, 21 Feb 2025 13:00:13 +0100
Richard Biener wrote:
> > Branches in git don't have independent permissions. If we use
> > gcc.gnu.org git, are we granted commit rights with the priviso that
> > we color inside the lines, and commit only to our own branches?
>
> My expectation is that by co
> On Feb 21, 2025, at 2:23 PM, Florian Weimer wrote:
>
> * Paul Koning:
>
>>> On Feb 21, 2025, at 1:59 PM, Florian Weimer wrote:
>>>
>>> * James K. Lowden:
>>>
As I mentioned in other posts, IMO (IANAL) the copyright in
unimportant and probably unenforceable. The National Computi
On 2/20/25 8:11 AM, jeevitha wrote:
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
A note for the future:
1) When sending a V2, V3, ... patch, please send it as its own email
thread, meaning, don't hit reply to a previous patch version email,
since that
Hi!
José, any objection to me pushing the attached
"BPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation not
supported'"?
(Why this is useful, you'll understand later today.)
I've tested BPF as follows:
$ [...]/configure --target=bpf-none
$ make -j12 all-gcc
$
On Fri, Feb 21, 2025 at 11:28:14AM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > On Wed, Feb 19, 2025 at 12:17:55PM +, Richard Sandiford wrote:
> >> Andrew Carlotti writes:
> >> > /* Print a list of CANDIDATES for an argument, and try to suggest a
> >> > specific
> >> >
Hi all,
during testing and compiling some larger coarray codes, I found a few
deficiencies. One was with handling class types when splitting the coarray
expression and the other was that the backend_decl of a formal argument in a
function's symbol was not the same as the one the function was compi
Pengxuan Zheng writes:
> This patch optimizes certain vector permute expansion with the FMOV
> instruction
> when one of the input vectors is a vector of all zeros and the result of the
> vector permute is as if the upper lane of the non-zero input vector is set to
> zero and the lower lane remai
On Thu, Feb 20, 2025 at 7:23 PM Paul Koning wrote:
>
>
>
> > On Feb 19, 2025, at 8:18 PM, James K. Lowden
> > wrote:
> >
> > On Wed, 19 Feb 2025 12:55:03 +0100
> > Matthias Klose wrote:
> >
> >> libgcobol/ChangeLog
> >> * Makefile.in: New file.
> >> * acinclude.m4: New file.
> >> * aclocal.m4:
On Thu, Feb 20, 2025 at 8:38 PM James K. Lowden
wrote:
>
> On Thu, 20 Feb 2025 11:38:58 +0100
> Richard Biener wrote:
>
> > Can you clarify on the future development model for Cobol after it has
> > been merged? Is the cobolworx gitlab still going to be the primary
> > development location and c
On Fri, Feb 21, 2025 at 3:36 AM H.J. Lu wrote:
>
> Append a newline in debug_edge so that we get
>
> (gdb) call debug_edge (e)
> edge (bb_9, bb_1)
> (gdb)
>
> instead of
>
> (gdb) call debug_edge (e)
> edge (bb_9, bb_1)(gdb)
OK.
> * sese.cc (debug_edge): Append a newline.
>
> --
> H.J.
When predicitive commoning moves an invariant ref it makes sure to
not build a MEM_REF with a base that is negatively offsetted from
an object. But in trying to preserve some transforms it does not
consider association of a constant offset with the address computation
in DR_BASE_ADDRESS leading to
Hi Richard, thanks for the feedback.
On Tue, Feb 18, 2025 at 9:17 PM Richard Biener
wrote:
>
>
>
> > Am 18.02.2025 um 17:04 schrieb Konstantinos Eleftheriou
> > :
> >
> > From: kelefth
> >
> > The pass rejects the transformation when there are instructions in the
> > sequence that might throw
Hi Thomas.
> José, any objection to me pushing the attached
> "BPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation
> not supported'"?
Sure, please do. It is good to have a consistent message, and yours is
better anyway.
> (Why this is useful, you'll understand later to
On 2/21/25 09:21, Andre Vehreschild wrote:
Hi Harald,
seconding Thomas here, thanks for the patch.
Thanks, Andre!
Pushed: r15-7663-g7d383a7343af05
- Andre
On Thu, 20 Feb 2025 21:18:01 +0100
Harald Anlauf wrote:
Dear all,
the attached simple patch addresses a small, left-over issue in t
From 7cca6e23b293bdf47280997df87a0cda70d2f91d Mon Sep 17 00:00:00 2001
From: Lino Hsing-Yu Peng
Date: Thu, 20 Feb 2025 17:09:22 +0800
Subject: [PATCH] RISC-V: Fix .cfi_offset directive when push/pop in zcmp
The incorrect cfi directive info breaks stack unwind in try/catch/cxa.
Before patch:
c
Andrew Carlotti writes:
> On Wed, Feb 19, 2025 at 12:17:55PM +, Richard Sandiford wrote:
>> Andrew Carlotti writes:
>> > /* Print a list of CANDIDATES for an argument, and try to suggest a
>> > specific
>> > close match. */
>> > diff --git a/gcc/config/aarch64/aarch64-builtins.cc
>> >
Add a fold at gimple_fold_builtin to prefer the highpart variant of a builtin
if the arguments are better suited to it. This helps us avoid copying data
between lanes before operation.
E.g. We prefer to use UMULL2 rather than DUP+UMULL for the following:
uint16x8_t
foo(const uint8x16_t s) {
Hi all,
This patch implements the missed optimisation noted in PR117850.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117850
Changes since the last revision:
- Now processing different function signatures programatically
- Fixed ICE RE the type referred to by a BIT_FIELD_REF
After seeing PR c++/118964 I'm coming back around to this [1] patch
series, since it appears that this can cause errors on otherwise valid
code by instantiations coming into module purview that reference
TU-local entities.
[1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650324.html
We'd p
On Fri, Feb 21, 2025 at 5:11 AM Andrew Pinski wrote:
>
> While looking into PR 118947, I noticed that optimize_memcpy_to_memset didn't
> handle STRING_CST which are also used for a memset of 0 but for char arrays.
> This fixes that and improves optimize_memcpy_to_memset to handle that case.
>
> Th
The following set of patches update gcc documentation to include the
COBOL front end. I have tried to follow the style.
The order of appearance of the supported languages in various places
looks inconsistent to me. I don't *think* they occur in the order they
were implemented, which in any case
In LoongArch, when the permutation idx comes from different vectors and
idx is not repeated, for V8SI/V8SF/V4DI/V4DF type vectors, we can use
two xvperm.w + one xvbitsel.v instructions or two xvpermi.d + one
xvbitsel.v instructions for shuffle optimization.
gcc/ChangeLog:
* config/loongar
Currently, the shuffle in which LoongArch selects two vectors at
corresponding positions is implemented through the [x]vshuf instruction,
but this will introduce additional index copies. In this case, the
[x]vbitsel.v instruction can be used for optimization.
gcc/ChangeLog:
* config/loong
Currently, the shuffle in which LoongArch selects two vectors at
corresponding positions is implemented through the [x]vshuf instruction,
but this will introduce additional index copies. In this case, the
[x]vbitsel.v instruction can be used for optimization.
gcc/ChangeLog:
* config/loong
In LoongArch, we have xvshuf.{b/h/w/d} instructions which can dealt the
situation that all low 128-bit elements of the target vector are shuffled
by concatenating the low 128-bit elements of the two input vectors, and
all high 128-bit elements of the target vector are similarly shuffled.
Therefore,
In LoongArch, when the permutation idx comes from different vectors and
idx is not repeated, for V8SI/V8SF/V4DI/V4DF type vectors, we can use
two xvperm.w + one xvbitsel.v instructions or two xvpermi.d + one
xvbitsel.v instructions for shuffle optimization.
gcc/ChangeLog:
* config/loongar
In LoongArch, we have xvshuf.{b/h/w/d} instructions which can dealt the
situation that all low 128-bit elements of the target vector are shuffled
by concatenating the low 128-bit elements of the two input vectors, and
all high 128-bit elements of the target vector are similarly shuffled.
Therefore,
Patch v2:
The special treatment about + and - seems to be specific to `ASM_OUTPUT_SYMBOL_REF()`. Neither
operator is passed to `ASM_OUTPUT_LABELREF()`, so it's not necessary to check for them in
`ix86_asm_output_labelref()`.
--
Best regards,
LIU Hao
From f6c09e9397d5fe9c0dd1f7a02c90536732aed
> diff --git a/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c
> b/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c
> index 0406f2c3595..e549cab84ca 100644
> --- a/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c
> +++ b/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c
> @@ -3,7 +3,8 @@
> int
> foo (int x)
Now for __builtin_popcountl we are getting things like
vrepli.b$vr0,0
vinsgr2vr.d $vr0,$r4,0
vpcnt.d $vr0,$vr0
vpickve2gr.du $r4,$vr0,0
slli.w $r4,$r4,0
jr $r1
The "vrepli.b" instruction is introduced by the init-regs pass (see
PR618
45 matches
Mail list logo
