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 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:
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
Arsen Arsenović writes:
> 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 following:
>
> DPOSTCOMPILE = ! test -f $(DEPFILE).Po && mv ...
>
> ...
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-details dump which the crc tests can use.
For PR115910 An
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
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 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
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
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 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
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
> 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
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
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
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
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
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
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
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/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
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 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
I used link() to create cheap copies of Incremental LTO cache contents
to prevent their deletion once linking is finished.
This is unnecessary, since output_files are deleted in our lto-plugin
and not in the linker itself.
Bootstrapped/regtested on x86_64-linux.
lto-wrapper now again builds on Min
> > 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 the smallest
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_iterator *forall_iterator;
+ gfc_expr_list *
> 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 the smallest unit and not abl
gcc/ChangeLog:
* gcc/config/riscv/riscv.cc
(riscv_file_end_indicate_exec_stack): Add .note.gnu.property.
* gcc/config/riscv/linux.h (TARGET_ASM_FILE_END): Define.
libgcc/ChangeLog:
* libgcc/config/riscv/crti.S: Add lpad instructions.
* libgcc/config/riscv/cr
Status
==
The GCC development branch which will become GCC 15 is now in
stage4, open for regression and documentation fixes only.
Quality Data
Priority # Change from last report
--- ---
P1 32 + 6
P2
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
addia5,a5,-1
and a4,a4,a5
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
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
On Mon, Jan 13, 2025 at 11:00:09AM +0100, Jakub Jelinek wrote:
> Why do you need there the directory or suffix?
> $(*F) is clearly bad, because there are rules like
> d/%.o: d/dmd/%.d
> $(DCOMPILE) $(D_INCLUDES) $<
> $(DPOSTCOMPILE)
>
> d/common-%.o: d/dmd/common/%.d
>
On Fri, Jan 10, 2025 at 9:43 PM Jeff Law wrote:
>
>
>
> On 1/10/25 1:00 AM, Richard Biener wrote:
> >
> > It's a problem we're never going to fully solve. Some of the
> > testcases show missed optimizations which we can work on. Some show
> > we diagnose IL we later are able to optimize away, so
Andreas Schwab wrote:
This breaks m68k:
Same issue on GCN, hence I filed https://gcc.gnu.org/PR118418
If I look at the debugging output, see PR, it seems as if
the self-test function test_comparisons contains the assumption:
FALSE < TRUE
but if TRUE is -1, that assumption does not hold
(fo
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 trunk and releases/gcc-14?
>>
>> OK
>
> Pushed as r15-6828-g4b0ef49d02
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
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
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
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 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
> 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/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
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/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 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
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/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-
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 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
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
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.
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
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/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/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 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 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
From: Piotr Trojanek
Fix a glitch in condition that effectively caused detection of redundant
parentheses in upper range bounds to be dead code.
gcc/ada/ChangeLog:
* par-ch3.adb (P_Discrete_Range): Replace N_Subexpr, which was catching
all subexpressions, with kinds that catch n
From: Piotr Trojanek
According to Ada grammar, raise expression is an expression, but requires
parens to be a simple_expression. We wrongly classified raise expressions
as expressions, because we mishandled a global state variable in the parser.
This patch causes some illegal code to be rejected
From: Eric Botcazou
gcc/ada/ChangeLog:
* libgnat/s-valrea.adb (Large_Powfive) [2 parameters]: Add a couple
of additional comments.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/libgnat/s-valrea.adb | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/
From: Piotr Trojanek
Use the same logic for warning about redundant parentheses in lower and upper
bounds of a discrete range. This fixes a spurious warning that, if followed,
would render the code illegal.
gcc/ada/ChangeLog:
* par-ch3.adb (P_Discrete_Range): Detect redundant parenthese
Hi!
On 2025-01-10T13:33:25+0100, Tobias Burnus wrote:
> The first change is a simple, generic Fortran change.
>
> Without it, external declarations have odd locations
> (namely their input_location):
>
> gcc/testsuite/gfortran.dg/gomp/dispatch-11.f90:67:46:
>
> 67 | !$omp dispatch interop(o
On Mon, 13 Jan 2025, Michal Jires wrote:
> I used link() to create cheap copies of Incremental LTO cache contents
> to prevent their deletion once linking is finished.
> This is unnecessary, since output_files are deleted in our lto-plugin
> and not in the linker itself.
>
> Bootstrapped/regteste
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 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 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 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
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 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 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 following:
>
> DPOSTCOMPILE = !
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 wrong ratio,
it is possible to generate
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: Gary Dismukes
The compiler was recursing endlessly when analyzing an aggregate of
an array type whose component subtype has a static predicate and the
component expressions are static, repeatedly transforming the aggregate
first into a string literal and then back into an aggregate. This is
From: Javier Miranda
Partially revert the fix for sem_ch13.adb as it does not comply
with RM 13.14(7.2/5).
gcc/ada/ChangeLog:
* sem_ch13.adb (Check_Aspect_At_End_Of_Declarations): Restore calls
to Preanalyze_Spec_Expression that were replaced by calls to
Preanalyze_And_R
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
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
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
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
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: 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: 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
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: 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 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
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.
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
Hi!
On 2025-01-10T21:22:03+, Tamar Christina via Gcc-cvs
wrote:
> https://gcc.gnu.org/g:68326d5d1a593dc0bf098c03aac25916168bc5a9
>
> commit r15-6807-g68326d5d1a593dc0bf098c03aac25916168bc5a9
> Author: Alex Coplan
> Date: Mon Mar 11 13:09:10 2024 +
>
> vect: Force alignment peeling
Here's another fix for a missing check that an IV value fits in a
HIW. It's originally from Stefan.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/117119
* tree-data-ref.cc (initialize_matrix_A): Check whether
an INTEGER_CST fits in HWI,
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
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,
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 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
1 - 100 of 126 matches
Mail list logo
