These testcases require RV64 targets. They fail when -march=rv32* is
specified while using an riscv64* compiler.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/crc-21-rv64-zbc.c: Disallow rv32 targets.
* gcc.target/riscv/crc-21-rv64-zbkc.c: Ditto.
---
gcc/testsuite/gcc.target/riscv
On Tue, Jan 14, 2025 at 6:05 AM Alexandre Oliva wrote:
>
>
> Arrange for decode_field_reference to use local variables throughout,
> to modify the out parms only when we're about to return non-NULL, and
> to drop the unused case of NULL pand_mask, that had a latent failure
> to detect signbit mask
On Mon, 13 Jan 2025, Alexandre Oliva wrote:
>
> Add logic to check and extend constants compared with bitfields, so
> that fields are only compared with constants they could actually
> equal. This involves making sure the signedness doesn't change
> between loads and conversions before shifts: w
On Mon, Jan 13, 2025 at 10:47 PM Eugene Rozenfeld
wrote:
>
> We are initializing both the call graph node count and
>
> the entry block count of the function with the head_count value
>
> from the profile.
>
>
>
> Count propagation algorithm may refine the entry block count
>
> and we may end up w
On 12/30/24 3:02 PM, Richard Sandiford wrote:
So it seems like it's a bit of a mess :(
If we do try to fix combine, I think something like the attached
would fit within the current scheme. It is a pure shift-for-shift
transformation, avoiding any extensions.
Will think more about it, but
On 1/13/25 18:08, Kito Cheng wrote:
> Thanks, that's apparently my stupid mistake...:P
No worries. We've all done that many times over !
Cheers,
-Vineet
Arrange for decode_field_reference to use local variables throughout,
to modify the out parms only when we're about to return non-NULL, and
to drop the unused case of NULL pand_mask, that had a latent failure
to detect signbit masking.
Regstrapped on x86_64-linux-gnu along with the PR118456 patc
On 1/13/25 16:43, Tobias Burnus wrote:
Hi all,
Tobias Burnus wrote:
Tobias Burnus wrote:
Sandra Loosemore wrote:
This patch reimplements the middle-end support for "declare variant"
and extends the resolution mechanism to also handle metadirectives
(PR112779). It also adds partial support fo
On 9/12/24 1:07 PM, Patrick Palka wrote:
(Sorry to resurrect this thread so late, I lost track of this patch...)
On Fri, 2 Dec 2022, Jason Merrill wrote:
On 12/2/22 09:30, Patrick Palka wrote:
On Thu, 1 Dec 2022, Jason Merrill wrote:
On 12/1/22 14:51, Patrick Palka wrote:
On Thu, 1 Dec 202
> So as written this test will be totally skipped (and I've verified that
> locally). It looks like you just wanted -O2 and we're not cycling
> through options, so we don't need/want the dg-skip-if. I'll fix that too.
Sorry, I made a mistake again :(
>
> I'll make the obvious changes and pu
Add logic to check and extend constants compared with bitfields, so
that fields are only compared with constants they could actually
equal. This involves making sure the signedness doesn't change
between loads and conversions before shifts: we'd need to carry a lot
more data to deal with all the
Thanks, that's apparently my stupid mistake...:P
On Tue, Jan 14, 2025 at 12:26 AM Jeff Law wrote:
>
>
>
> On 1/11/25 4:45 PM, Vineet Gupta wrote:
> > This seeming benign mistake caused a massive SPEC2017 Cactu regression
> > (2.1 trillion insn to 2.5 trillion) wiping out all the gains from my
> >
On 1/10/25 2:20 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
The documentation for LAMBDA_EXPR_THIS_CAPTURE seems outdated because
it says the field is only used at parse time, but apparently it's also
used at instantiation time.
Non-'
On 1/12/25 2:39 PM, Simon Martin wrote:
[ Fixing David’s email address :-/ ]
Hi,
On 9 Jan 2025, at 20:08, Simon Martin wrote:
On 9 Jan 2025, at 20:00, Marek Polacek wrote:
On Thu, Jan 09, 2025 at 12:05:43PM -0500, Patrick Palka wrote:
On Wed, 8 Jan 2025, Jason Merrill wrote:
On 12/21/24
Committed as:
commit 20b8500cfa522ebe0fcf756d5b32816da7f904dd (HEAD -> master,
origin/master, origin/HEAD)
Author: Anuj Mohite
Date: Mon Jan 13 16:28:57 2025 -0800
Fortran: Add LOCALITY support for DO_CONCURRENT
This patch provided by Anuj Mohite as part of the GSoC project
On 1/13/25 10:57 AM, Jakub Jelinek wrote:
On Fri, Jan 10, 2025 at 12:04:53PM -0500, Jason Merrill wrote:
Note, the PR raises another problem.
If on the same testcase the B b; line is removed, we silently synthetize
operator<=> which will crash at runtime due to returning without a return
stateme
On 1/13/25 2:57 PM, Marek Polacek wrote:
On Mon, Jan 13, 2025 at 11:25:25AM -0500, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
Looks okay to me.
OK.
-- >8 --
PR c++/116417
gcc/cp/ChangeLog:
* cp-tree.h (finish_pseu
On Tue, 2025-01-14 at 00:08 +, Joseph Myers wrote:
> On Sun, 12 Jan 2025, David Malcolm wrote:
>
> > So I've dropped the takes_int_p, takes_void_p, and
> > maybe_inform_empty_args_c23_transition from the patch. Here's an
> > updated version that keeps the rest of the changes. I'd like to
> >
On 12/18/24 3:37 AM, Robin Dapp wrote:
Hi,
currently ssa-dse-1.C ICEs because expand_simple_binop returns NULL
when building the scalar that is used to IOR two interleaving
sequences.
That's because we try to emit a shift in HImode. This patch shifts in
Xmode and then lowpart-subregs the re
On 12/17/24 8:27 AM, Robin Dapp wrote:
Hi,
in PR117682 we build an interleaving pattern
{ 1, 201, 209, 25, 161, 105, 113, 185, 65, 9,
17, 89, 225, 169, 177, 249, 129, 73, 81, 153,
33, 233, 241, 57, 193, 137, 145, 217, 97, 41,
49, 121 };
with negative step expecting wraparo
On 1/13/25 3:27 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
OK, but do we also need this in the "still packed" case earlier in the
function?
-- >8 --
During ahead of time template argument coercion, we handle the case of
passing
On Sun, 12 Jan 2025, David Malcolm wrote:
> So I've dropped the takes_int_p, takes_void_p, and
> maybe_inform_empty_args_c23_transition from the patch. Here's an
> updated version that keeps the rest of the changes. I'd like to get
> this into GCC 15 to make build failures due to C23-incompatibi
On 1/13/25 4:55 PM, Andrew Pinski wrote:
With the addition of supporting operations on the SVE scalable vector types,
the vec_duplicate tree will show up in expressions and the constexpr handling
was not done for this tree code.
This is a simple fix to treat VEC_DUPLICATE like any other unary ope
On 1/12/25 7:03 AM, Nathaniel Shead wrote:
On Sun, Jan 12, 2025 at 04:14:41AM +1100, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The ICE in the linked PR is caused because name lookup finds duplicate
copies of the deduction guides, causing a
On 1/12/25 7:20 AM, Nathaniel Shead wrote:
On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
From: yxj-github-437 <2457369...@qq.com>
This patch attempts to fix an error when build module std. The reason for the
error is __builrin_va_list (aka struct __va_list) is an internal linkage. so
att
On 12/22/24 11:51 PM, yunze...@linux.alibaba.com 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-
Hi all,
Tobias Burnus wrote:
Tobias Burnus wrote:
Sandra Loosemore wrote:
This patch reimplements the middle-end support for "declare variant"
and extends the resolution mechanism to also handle metadirectives
(PR112779). It also adds partial support for dynamic selectors
(PR113904) and fixes
On 1/10/25 1:38 AM, Robin Dapp wrote:
Hi,
the zbb-rol-ror and stack_save_restore tests use the -fno-lto option and
scan the final assembly. For an invocation like -flto ... -fno-lto the
output file we scan is still something like
zbb-rol-ror-09.ltrans0.ltrans.s.
Therefore skip the tests
Raw dump of lang tree was missing information about virtual method call.
The information is provided in "tok" field of obj_type_ref.
gcc/ChangeLog:
* tree-dump.cc (dequeue_and_dump): Handle OBJ_TYPE_REF.
gcc/testsuite/ChangeLog:
* g++.dg/lang-dump-1.C: New test.
---
gcc/testsuite/g++.dg/lan
After my other patch, I decided to write a test case with an illegal
constant operand value to a built-in to see what the results would be.
Without my other patch, we fail to catch the illegal use and emit an
invalid rtl insn and hit an unrecognizable insn ICE. With my previous
patch, we correctly
With the addition of supporting operations on the SVE scalable vector types,
the vec_duplicate tree will show up in expressions and the constexpr handling
was not done for this tree code.
This is a simple fix to treat VEC_DUPLICATE like any other unary operator and
allows
the constexpr-add-1.C tes
We are initializing both the call graph node count and
the entry block count of the function with the head_count value
from the profile.
Count propagation algorithm may refine the entry block count
and we may end up with a case where the call graph node count
is set to 0 but the entry block count
On 1/13/25 12:18 AM, Tobias Burnus wrote:
Hi,
On 9/25/24 3:18 AM, Andre Vehreschild wrote:
@@ -3089,7 +3099,15 @@ typedef struct gfc_code
gfc_inquire *inquire;
gfc_wait *wait;
gfc_dt *dt;
- gfc_forall_iterator *forall_iterator;
+
+ struct
+ {
+ gfc_forall_iterat
Richard Sandiford writes:
> Tamar Christina writes:
>>> -Original Message-
>>> From: Richard Sandiford
>>> Sent: Monday, January 13, 2025 6:35 PM
>>> To: Tamar Christina
>>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>>> ; ktkac...@gcc.gnu.org
>>> Subject: Re: [PATCH]AArch64: ha
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, January 13, 2025 6:35 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; ktkac...@gcc.gnu.org
>> Subject: Re: [PATCH]AArch64: have -mcpu=native detect architecture
Signed-off-by: Keith Packard
---
gcc/config/lm32/lm32.cc | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/config/lm32/lm32.cc b/gcc/config/lm32/lm32.cc
index 4445295fe2b..d78efc59da5 100644
--- a/gcc/config/lm32/lm32.cc
+++ b/gcc/config/lm32/lm32.cc
@@ -632,8 +632,7 @@ lm
Hi,
This patch bumps the soname of libphobos from version 5 to version 6.
Each major release is not binary compatible with the previous.
Regstrapped on x86_64-linux-gnu, committed to mainline.
Regards,
Iain.
---
PR d/117701
libphobos/ChangeLog:
* configure: Regenerate.
Adjust the conditionals so that pretend_size is always computed, even
if no_rtl is set.
Signed-off-by: Keith Packard
---
gcc/config/lm32/lm32.cc | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/gcc/config/lm32/lm32.cc b/gcc/config/lm32/lm32.cc
index dfec28608a
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
During ahead of time template argument coercion, we handle the case of
passing a pack expansion to a non-pack parameter by breaking out early
and using the original unconverted arguments, deferring coercion u
lm32 has 8 register parameter slots, so many vararg functions end up
with several anonymous parameters passed in registers. If we run out
of registers in the middle of a parameter, the entire parameter will
be placed on the stack, skipping any remaining available registers.
The receiving varargs f
The cumulative args value in setup_incoming_varargs points at
the last named parameter. We need to skip over that (if present) to
get to the first anonymous argument as we only want to include
those anonymous args in the saved register block.
Signed-off-by: Keith Packard
---
gcc/config/lm32/lm32
In doing picolibc testing for lm32, I discovered that varargs handling
had an issue when the set of anonymous arguments spanned register
arguments and stack arguments.
On lm32, FIRST_PARM_OFFSET is '4', meaning there are four bytes
between the stack top and the first non-register parameter. When
On 1/12/25 7:49 AM, Xi Ruoyao wrote:
The test case
long
test (long x, long y)
{
return ((x | 0x1ff) << 3) + y;
}
is now compiled (-O2 -march=rv64g_zba) to
li a4,4096
slliw a5,a0,3
addia4,a4,-8
or a5,a5,a4
addwa0,a5,a1
On Mon, Jan 13, 2025 at 11:25:25AM -0500, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
Looks okay to me.
> -- >8 --
>
> PR c++/116417
>
> gcc/cp/ChangeLog:
>
> * cp-tree.h (finish_pseudo_destructor_expr): Add complain
>
Hi all,
> In that case, I'm coming round to the idea of deprecating ILP32.
> I think it was already common ground that the GNU/Linux support is dead.
> watchOS would use Mach objects rather than ELF. As you say, it isn't
> clear how much of the current ILP32 support would be relevant for it.
> An
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, January 13, 2025 6:35 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: have -mcpu=native detect architecture extensions
> for unknown non-hom
On Mon, Jan 13, 2025 at 06:38:00PM +, Richard Sandiford wrote:
> In g:06c4cf398947b53b4bfc65752f9f879bb2d07924 I mishandled signed
> comparisons of comparison results on STORE_FLAG_VALUE < 0 targets
> (despite specifically referencing STORE_FLAG_VALUE in the commit
> message). There, (lt TRUE
In g:06c4cf398947b53b4bfc65752f9f879bb2d07924 I mishandled signed
comparisons of comparison results on STORE_FLAG_VALUE < 0 targets
(despite specifically referencing STORE_FLAG_VALUE in the commit
message). There, (lt TRUE FALSE) is true, although (ltu FALSE TRUE)
still holds.
Things get messy wi
On Mon, Jan 13, 2025 at 07:29:52PM +0100, Iain Buclaw wrote:
> For example, changing the common package sources we end up with the
> following, though can't say I'm a strong fan of having test and
> optionally mkdir ran on every recipe execution.
You also then need to handle it for cleaning etc.
Tamar Christina writes:
> Hi All,
>
> in g:e91a17fe39c39e98cebe6e1cbc8064ee6846a3a7 we added the ability for
> -mcpu=native on unknown CPUs to still enable architecture extensions.
>
> This has worked great but was only added for homogenous systems.
>
> However the same thing works for big.LITTLE
Excerpts from Jakub Jelinek's message of Januar 13, 2025 2:58 pm:
> On Mon, Jan 13, 2025 at 02:45:28PM +0100, Arsen Arsenović wrote:
>> > So the former d/.deps/file.Po which handled both d/dmd/common/file.d and
>> > d/dmd/root/file.d in your case would be d/.deps/d-common-file.o.d and
>> > d/.deps/
On 1/12/25 7:49 AM, Xi Ruoyao wrote:
When zbs is not available, there's nothing special with single-bit
immediates and we should perform reassociation as normal immediates.
gcc/ChangeLog:
PR target/115921
* config/riscv/riscv.md (_shift_reverse): Only check
popcount_h
On 1/13/25 3:15 AM, Jin Ma wrote:
When the vsetvl instructions of the two RVV instructions are merged
using "use_max_sew", it is possible to update the sew of prev if
prev.sew < next.sew, but keep the original ratio, which is obviously
wrong. when the subsequent instructions are equal to the w
This seeming benign mistake caused a massive SPEC2017 Cactu regression
(2.1 trillion insn to 2.5 trillion) wiping out all the gains from my
recent sched1 improvement. Thankfully the issue was trivial to fix even
if hard to isolate.
On BPI3:
Before bug
--
| Performance counter stats for '
On 13/01/2025 16:51, Tobias Burnus wrote:
Hi PA,
Paul-Antoine Arras wrote:
I am not sure I am getting that part. Is this what you are suggesting?
Yes, something like that, but not quite, as you found out.
I think we need something like the following (untested):
diff --git gcc/fortran/openm
On 08/01/25 2:30 pm, 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 and Increment
> E
Iain Sandoe writes:
> Hi Folks,
>
>> On 10 Jan 2025, at 18:30, Wilco Dijkstra wrote:
>>
>> Hi Andrew,
>>
>>> Personally I would like this deprecated even for bare-metal. Yes the
>>> iwatch ABI is an ILP32 ABI but I don't see GCC implementing that any
>>> time soon and I suspect it would not be
On 1/12/25 10:44 PM, Zhijin Zeng wrote:
Compared to the patch v2, I added Zfinx check and Zfh check. Please help to
review again.
Thanks,
Zhijin
From 9ddb402cebe868050ebc2f75e4d87238161411b4 Mon Sep 17 00:00:00 2001
From: Zhijin Zeng
Date: Sat, 11 Jan 2025 12:09:11 +0800
Subject: [PATCH]
Andrew Carlotti writes:
> This doesn't enable anything within the compiler, but this allows the
> flag to be passed the assembler. There also doesn't appear to be a
> kernel cpuinfo name yet.
>
>
> Ok for master?
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-arches.def (V9_5A): Add CPA.
>
On 1/6/25 6:03 AM, Maciej W. Rozycki wrote:
Similarly to data races with 8-bit byte or 16-bit word quantity memory
writes on non-BWX Alpha implementations we have the same problem even on
BWX implementations with partial memory writes produced for unaligned
stores as well as block memory move
Andrew Carlotti writes:
> Ok for master?
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-arches.def (V9_5A): New.
> * doc/invoke.texi: Document armv9.5-a option.
>
> diff --git a/gcc/config/aarch64/aarch64-arches.def
> b/gcc/config/aarch64/aarch64-arches.def
> index
> fd4881a8ebfbd34
On 1/13/25 2:07 AM, Jin Ma wrote:
Correct logic on 64-bit host:
...
bseti a5,zero,38
bseti a5,a5,63
addia5,a5,-1
and a4,a4,a5
...
Wrong logic on 32-bit host:
...
li a5,64
bseti a5,a5,31
On 1/13/25 1:41 AM, Jin Ma wrote:
Thank you very much for your professional reply. I am trying to solve the
problem
using the "spec_restriction" way. But unfortunately, I have a new problem. As
pattern below, how can I enable "r" and disable "K" when XTheadVector? "rK"
already
seems to be th
> Yes. This will solve the problem, but it will lead to very large-scale changes
> (splitting each rK, adding 1 column constraint), and make the pattern more
> complex
> and more difficult to maintain. In contrast, how about replacing "rK" with a
> new
> constrain in the way jeff mentioned? For e
On 1/11/25 4:45 PM, Vineet Gupta wrote:
This seeming benign mistake caused a massive SPEC2017 Cactu regression
(2.1 trillion insn to 2.5 trillion) wiping out all the gains from my
recent sched1 improvement. Thankfully the issue was trivial to fix even
if hard to isolate.
On BPI3:
Before bug
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
PR c++/116417
gcc/cp/ChangeLog:
* cp-tree.h (finish_pseudo_destructor_expr): Add complain
parameter.
* parser.cc (cp_parser_postfix_dot_deref_expression): Pass
compla
Hi,
This is the 5th ping of the middle end review of the patch set.
Could you please take a look at the patch set for -fdiagnostics-details, and
provide
more advice on:
A. Whether the middle-end design and implementation is reasonable and
extendable to more other
optimizations (including
On Fri, Jan 10, 2025 at 12:04:53PM -0500, Jason Merrill wrote:
> > Note, the PR raises another problem.
> > If on the same testcase the B b; line is removed, we silently synthetize
> > operator<=> which will crash at runtime due to returning without a return
> > statement. That is because the stan
Hi PA,
Paul-Antoine Arras wrote:
I am not sure I am getting that part. Is this what you are suggesting?
Yes, something like that, but not quite, as you found out.
I think we need something like the following (untested):
diff --git gcc/fortran/openmp.cc gcc/fortran/openmp.cc
index 9d28dc
On Sat, Jan 11, 2025 at 01:21:13PM +, Iain Sandoe wrote:
> Hi,
>
> I originally made this patch for the Darwin Arm64 development branch,
> however in discussions on IRC, it seems that it is also relevant to
> Linux - since there are implementations running on Apple hardware with
> the M1..3 CP
On 1/13/25 7:47 AM, Richard Biener wrote:
On Mon, 13 Jan 2025, Richard Biener wrote:
The following makes niter analysis recognize a loop with an exit
condition scanning over a STRING_CST. This is done via enhancing
the force evaluation code rather than recognizing for example
strlen (s) as
On 13/01/2025 14:57, Tobias Burnus wrote:
Hi PA,
Paul-Antoine Arras wrote:
Here is an updated patch following your suggestion.
Thanks. It is not clear whether you are just waiting
for test result or not before committing it as obvious.
Thus, just in case: LGTM.
Thanks,
Tobias
Thanks for
Hi Tobias,
Here are an updated patch and a few questions.
On 07/01/2025 13:18, Tobias Burnus wrote:
Paul-Antoine Arras:
Add support to the Fortran parser for the new OpenMP syntax that allows a
comma after the directive name and between clauses of declare variant.
The C and C++ parsers already
On 2025-01-13 15:21, Christophe Lyon wrote:
On 1/13/25 15:05, Torbjorn SVENSSON wrote:
Hi Richard and Robin,
It looks like this patch introduced a regression with MVE (Cortex-M55
and Cortex-M85).
If I try to build testsuite/c-c++-common/vector-compare-3.c (there are
other test cases th
On Mon, 13 Jan 2025, Richard Biener wrote:
> The following makes niter analysis recognize a loop with an exit
> condition scanning over a STRING_CST. This is done via enhancing
> the force evaluation code rather than recognizing for example
> strlen (s) as number of iterations because it allows t
This resurrects a patch from a bit over 2 years ago that I never wrapped
up. IIRC, I ended up up catching covid, then in the hospital for an
unrelated issue and it just got dropped on the floor in the insanity.
The basic idea here is to help postreload-cse eliminate more
const/copies by recor
Hi Iain,
> On 11 Jan 2025, at 14:21, Iain Sandoe wrote:
>
> Hi,
>
> I originally made this patch for the Darwin Arm64 development branch,
> however in discussions on IRC, it seems that it is also relevant to
> Linux - since there are implementations running on Apple hardware with
> the M1..3 CP
On 1/13/25 15:05, Torbjorn SVENSSON wrote:
Hi Richard and Robin,
It looks like this patch introduced a regression with MVE (Cortex-M55
and Cortex-M85).
If I try to build testsuite/c-c++-common/vector-compare-3.c (there are
other test cases that fail with a similar ICE):
arm-none-eabi-gc
Hi Richard and Robin,
It looks like this patch introduced a regression with MVE (Cortex-M55 and
Cortex-M85).
If I try to build testsuite/c-c++-common/vector-compare-3.c (there are other
test cases that fail with a similar ICE):
arm-none-eabi-gcc /src/gcc/testsuite/c-c++-common/vector-compare-
On Mon, Jan 13, 2025 at 02:45:28PM +0100, Arsen Arsenović wrote:
> > So the former d/.deps/file.Po which handled both d/dmd/common/file.d and
> > d/dmd/root/file.d in your case would be d/.deps/d-common-file.o.d and
> > d/.deps/d-root-file.o.d while with the above DEPFILE it would be
> > d/.deps/co
Hi PA,
Paul-Antoine Arras wrote:
Here is an updated patch following your suggestion.
Thanks. It is not clear whether you are just waiting
for test result or not before committing it as obvious.
Thus, just in case: LGTM.
Thanks,
Tobias
Ping for trunk
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672050.html
Notice that the patch is bootstrapped and reg-tested and I may
commit-after-approval, so no further work from admins is needed.
The avr part has already been approved 2024-12-20.
The default action is an obvious
Jakub Jelinek writes:
> On Sun, Jan 12, 2025 at 04:16:58PM +0100, Arsen Arsenović wrote:
>> Regstrapped on x86_64-pc-linux-gnu. I've also checked the generated
>> dependency files are correct by hand and "instrumented" the build to
>> fail if two dependency files are the same, by doing the follo
Hi Tobias,
On 13/01/2025 13:24, Tobias Burnus wrote:
Hi PA,
Paul-Antoine Arras wrote:
Hi Thomas,
Added libgomp/testsuite/libgomp.fortran/dispatch-1.f90.
I see this new test case FAIL (execution test SIGSEGV) for most (but not
all) offloading configurations, both GCN and nvptx:
+PASS: l
The following makes niter analysis recognize a loop with an exit
condition scanning over a STRING_CST. This is done via enhancing
the force evaluation code rather than recognizing for example
strlen (s) as number of iterations because it allows to handle
some more cases.
STRING_CSTs are easy to h
This commit makes the contrib/check-MAINTAINERS.py script happy about
our MAINTAINERS file. I hope that it knows best how things ought to
be and so am committing this as obvious.
ChangeLog:
2025-01-13 Martin Jambor
* MAINTAINERS: Fix the name order of the Write After Approval section
When vectorizing a load we are now checking alignment before emitting
a vector(1) T load instead of blindly assuming it's OK when we had
a scalar T load. For reasons we're not handling alignment computation
optimally here but we shouldn't ICE when we fall back to loads of T.
The following ensures
On Mon, 13 Jan 2025 at 11:12, Thomas Schwinge wrote:
>
> Hi!
>
> On 2025-01-13T11:04:50+, Jonathan Wakely wrote:
> > On Mon, 13 Jan 2025 at 11:03, Thomas Schwinge
> > wrote:
> >> On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON
> >> wrote:
> >> > On 2025-01-12 01:05, Jonathan Wakely wrote:
Hi PA,
Paul-Antoine Arras wrote:
Hi Thomas,
Added libgomp/testsuite/libgomp.fortran/dispatch-1.f90.
I see this new test case FAIL (execution test SIGSEGV) for most (but not
all) offloading configurations, both GCN and nvptx:
+PASS: libgomp.fortran/dispatch-1.f90 -O (test for excess
e
On Mon, 13 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> Something I've noticed during working on the crc wrong-code fix.
> My first version of the patch failed because of no longer matching some
> expected strings in the assembly, so I had to add TDF_DETAILS debugging
> into the -fdump-rtl-expand-det
Hi Thomas,
On 08/01/2025 10:04, Thomas Schwinge wrote:
Hi Paul-Antoine!
On 2024-12-16T19:35:01+0100, Paul-Antoine Arras wrote:
On 15/11/2024 14:59, Tobias Burnus wrote:
Paul-Antoine Arras wrote:
This patch adds support for the `dispatch` construct and the
`adjust_args` clause to the Fortran
Hi!
On 2025-01-13T11:04:50+, Jonathan Wakely wrote:
> On Mon, 13 Jan 2025 at 11:03, Thomas Schwinge wrote:
>> On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON
>> wrote:
>> > On 2025-01-12 01:05, Jonathan Wakely wrote:
>> >> On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
>> >> mailto:torbjorn.
From: Piotr Trojanek
GNAT already emits a style warning when redundant parentheses appear inside
logical and short-circuit operators. A similar warning is now emitted for
unary operators as well.
gcc/ada/ChangeLog:
* par-ch4.adb (P_Factor): Warn when the operand of a unary operator
From: Pascal Obry
gcc/ada/ChangeLog:
* doc/gnat_ugn/platform_specific_information.rst: Update.
* gnat_ugn.texi: Regenerate.
Tested on x86_64-pc-linux-gnu, committed on master.
---
.../platform_specific_information.rst | 19 ++-
gcc/ada/gnat_ugn.texi
From: Pascal Obry
gcc/ada/ChangeLog:
* mdll.adb: For the created DLL to be relocatable we do not want to use
the base file name when calling gnatdll.
* gnatdll.adb: Removes option -d which is not working anymore. And
when using a truly relocatable DLL the base-add
From: Piotr Trojanek
GNAT already emits a style warning when redundant parentheses appear inside
logical and short-circuit operators. A similar warning will be soon emitted for
unary operators as well. This patch removes the redundant parentheses to avoid
future build errors.
gcc/ada/ChangeLog:
From: Piotr Trojanek
GNAT already emits a style warning when redundant parentheses appear inside
logical and short-circuit operators. A similar warning will be soon emitted for
unary operators as well. This patch removes the redundant parentheses to avoid
build errors.
gcc/ada/ChangeLog:
From: Piotr Trojanek
Code cleanup; semantics is unaffected.
gcc/ada/ChangeLog:
* exp_ch4.adb: (Expand_N_Not_In): Preserve Alternatives in expanded
membership operator just like preserving Right_Opnd (though only
one of these fields is present at a time).
* par-ch
From: Javier Miranda
Fix regression in the SPARK 2014 testsuite.
gcc/ada/ChangeLog:
* sem_util.adb (Build_Actual_Subtype_Of_Component): No action
under preanalysis.
* sem_ch5.adb (Set_Assignment_Type): If the right-hand side contains
target names, expansion has b
On Mon, 13 Jan 2025 at 11:03, Thomas Schwinge wrote:
>
> Hi!
>
> On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON
> wrote:
> > On 2025-01-12 01:05, Jonathan Wakely wrote:
> >> On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
> >> mailto:torbjorn.svens...@foss.st.com>>
> >> wrote:
> >>
> >> Ok for
1 - 100 of 126 matches
Mail list logo
