On 4/7/25 3:33 PM, Jakub Jelinek wrote:
On Mon, Apr 07, 2025 at 03:28:29PM +0530, Tejas Belagod wrote:
Add AArch64 SVE target exectute tests to test various workshare constructs and
clauses with SVE types.
libgomp/ChangeLog:
* testsuite/libgomp.c-target/aarch64/aarch64.exp: Test driver
On Tue, Apr 8, 2025 at 1:25 AM Jonathan Wakely wrote:
> When formatting floating-point values to wide strings there's a case
> where we invalidate a std::wstring buffer while a std::wstring_view is
> still referring to it.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/119671
> * in
On 2025-04-07 14:53, Qing Zhao wrote:
Is there a reason to do this at the very end like this and not in the
GIMPLE_ASSIGN case in the switch block? Something like this:
tree rhs = gimple_assign_rhs1 (stmt);
tree counted_by_ref = NULL_TREE;
if (gimple_assign_rhs_code
Attached patch OK for master branch?
Will push soon if there are no objections.
From 66c30c0db9560af4f61ebda0742d0eb7da45f474 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 7 Apr 2025 15:40:05 +
Subject: [PATCH] deref-before-check-pr113253.c: Fix bogus warnings on
Pushed to r15-9245 and r14-11538.
在 2025/4/7 下午3:44, Lulu Cheng 写道:
In GCC14, LoongArch added __float128 as an alias for _Float128.
In commit r15-8962, support for q/Q suffixes for 128-bit floating point
numbers. This will cause the compiler to automatically link libquadmath
when compiling Fort
On Sat, 5 Apr 2025, Martin Uecker wrote:
>
>
> The checking assertion added for PR118765
>
> https://gcc.gnu.org/cgit/gcc/commit/?id=accbc1b90bd942aa36ac1485a21056b774ce02df
>
> did indeed catch some case I hadn't considered. I think there
> might be other cases in the C FE where we test for
When formatting floating-point values to wide strings there's a case
where we invalidate a std::wstring buffer while a std::wstring_view is
still referring to it.
libstdc++-v3/ChangeLog:
PR libstdc++/119671
* include/std/format (__formatter_fp::format): Do not invalidate
_
> On 22 Mar 2025, at 23:13, Robert Dubner wrote:
> But, by all means, if you have a fix for something I am not seeing, a fix
> that doesn't mess with the status quo ante, then by all means, apply it.
I applied the simplest fix possible - which was to remove the trailling //
from the conversion
On 3/31/25 21:54, Jeff Law wrote:
> And if that's the case then you can't simply skip an abnormal edge. You
> have to do something sensible.
>
> That "something sensible" has traditionally been to ensure there is
> never a need propagated to an edge since you can't insert on an abnormal
> criti
Simplify memcpy and memset inline strategies to avoid branches for
-mtune=generic:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
a
On Wed, Feb 12, 2025 at 08:27:37PM -0500, Lewis Hyatt wrote:
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838
>
> This patch addresses the issue mentioned in the PR (another instance of
> _Pragma string location issues). bootstrap + regtest all languages on
> aarch64 looks good. I
On 2025-04-07 11:56, Qing Zhao wrote:
when the type is a structure with flexible array member.
Not just when the structure has a flexible array member, also when the
FAM size is recorded in a __counted_by__, isn't it?
In tree-object-size.cc, if the size is UNKNOWN after evaluating use-def
c
when the type is a structure with flexible array member.
In tree-object-size.cc, if the size is UNKNOWN after evaluating use-def
chain, We can evaluate the SIZE of the pointee TYPE ONLY when this TYPE
is a structure type with flexible array member, since a structure with
FAM can not be an element
libstdc++-v3/ChangeLog:
PR libstdc++/119642
* include/bits/formatfwd.h: Remove stray pragma.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/bits/formatfwd.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/formatfwd.h
b/libstdc++-v3/
Hello,
On Mon, 7 Apr 2025, Martin Uecker wrote:
> > So, what specifically would the two attributes do different? FWIW: what
> > worries me about accepting a generic expression in counted_by, that isn't
> > prefixed by a (possibly empty) decl, is that after seeing a non-type
> > identifier the
[PR109071,PR85788,PR88771,PR106762,PR108770,PR115274,PR117179]
Add debugging for move history.
PR tree-optimization/109071
PR tree-optimization/85788
PR tree-optimization/88771
PR tree-optimization/106762
PR tree-optimization/108770
PR tree-optimiza
This adds the new C23 headers to the PCH, and also removes the
__has_include check for because we provide that
unconditionally now.
libstdc++-v3/ChangeLog:
* include/precompiled/stdc++.h: Include and
. Include unconditionally.
---
Tested x86_64-linux. Pushed to trunk.
libst
[PR109071,PR85788,PR88771,PR106762,PR108770,PR115274,PR117179]
During array out-of-bound checking or -Wstringop-* warning checking, the
"move_history" that was attached to the gimple statement is used to form
a sequence of diagnostic events that are added to the corresponding rich
location to be u
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in (INPUT): Add flat_map, flat_set,
text_encoding, stdbit.h and stdckdint.h.
---
Pushed to trunk.
libstdc++-v3/doc/doxygen/user.cfg.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in
b/
[PR109071,PR85788,PR88771,PR106762,PR108770,PR115274,PR117179]
Control this with a new option -fdiagnostics-details.
$ cat t.c
extern void warn(void);
static inline void assign(int val, int *regs, int *index)
{
if (*index >= 4)
warn();
*regs = val;
}
struct nums {int vals[4];};
void spar
Hi Iain,
>>> diff --git a/gcc/ginclude/stddef.h b/gcc/ginclude/stddef.h
>>> index 0d53103ce20..bf9c6e609dc 100644
>>> --- a/gcc/ginclude/stddef.h
>>> +++ b/gcc/ginclude/stddef.h
>>> @@ -89,6 +89,17 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
>>> If not, see
>>> #undef _PTRDIFF_T_
> On Apr 7, 2025, at 10:31, Michael Matz wrote:
>
> Hello,
>
> On Mon, 7 Apr 2025, Martin Uecker wrote:
>
>>> So, what specifically would the two attributes do different? FWIW: what
>>> worries me about accepting a generic expression in counted_by, that isn't
>>> prefixed by a (possibly e
Hi Folks
this has more than 2 weeks without comment,
(it is darwin-local)
thanks
Iain
> On 29 Mar 2025, at 15:23, Iain Sandoe wrote:
>
> C++ modules are not really usable on latest Darwin without resolving this,
> thanks
> Iain
>
>> On 23 Mar 2025, at 12:29, Iain Sandoe wrote:
>>
>> From: Ia
On Mon, 7 Apr 2025 at 12:38, Andrew Stubbs wrote:
> Otherwise LGTM. At least GCN certainly does support atomics, so the
> configure test must be broken somehow.
I'm very curious why they fail.
Am Montag, dem 07.04.2025 um 14:44 +0200 schrieb Michael Matz:
> Hello,
>
> On Sat, 5 Apr 2025, Bill Wendling wrote:
>
> > > > > > So, a different attribute name “counted_by_exp” might be better?
> > > > >
> > > > > I would prefer Martins empty-decl idea to that: "counted_by(;len+0)"
> > > > > (
For both GCN, nvptx, this gets rid of 'configure'-time:
configure: WARNING: No native atomic operations are provided for this
platform.
configure: WARNING: They will be faked using a mutex.
configure: WARNING: Performance of certain classes will degrade as a result.
..., and changes:
Hi!
On 2025-02-27T21:51:11+0100, I wrote:
> With '-mfake-ptx-alloca' enabled, the user-visible behavior changes only
> for configurations where PTX 'alloca' is not available. Rather than a
> compile-time 'sorry, unimplemented: dynamic stack allocation not supported'
> in presence of dynamic stack
On Mon, Apr 7, 2025 at 2:53 AM Richard Biener wrote:
>
> On Fri, 4 Apr 2025, Jakub Jelinek wrote:
>
> > On Fri, Apr 04, 2025 at 08:52:10PM +0200, Richard Biener wrote:
> > > > Or do you want something further (like
> > > > switch (global_options.x_flag_cf_protection & ~CF_SET)
> > > > )?
> > >
> >
Hello,
On Sat, 5 Apr 2025, Bill Wendling wrote:
> > >>> So, a different attribute name “counted_by_exp” might be better?
> > >>
> > >> I would prefer Martins empty-decl idea to that: "counted_by(;len+0)"
> > >> (looks up 'len' normally, i.e. doesn't look into current struct). It
> > >> would nat
This produces a toolchain that can successfully build binaries targeting
riscv*-gnu.
gcc/ChangeLog:
* config.gcc: Recognize riscv*-*-gnu* targets.
* config/riscv/gnu.h: New file.
Signed-off-by: Hakan Candar
---
gcc/config.gcc | 14 ++
gcc/config/riscv/gnu.h |
On Wed, Apr 02, 2025 at 04:24:30PM -0500, Robert Dubner wrote:
> Solutions have been put in place that don't involve modifying the source
> code of the copied files. I haven't made an opportunity to understand how
> they work, but I am choosing to drop the matter.
In order to unbreak Darwin, I'v
> On 7 Apr 2025, at 10:21, Tamar Christina wrote:
>
>> -Original Message-
>> From: Kyrylo Tkachov
>> Sent: Monday, March 31, 2025 1:43 PM
>> To: i...@sandoe.co.uk
>> Cc: Tamar Christina ; GCC Patches > patc...@gcc.gnu.org>; Alice Carlotti ; Richard
>> Sandiford
>> ; s...@gentoo.org
>>
On Mon, 7 Apr 2025, Jakub Jelinek wrote:
> Hi!
>
> What make html does for COBOL is quite inconsistent with all
> other FEs. Normally make html creates HTML/gcc-15.0.1/
> subdirectory and puts there subdirectories like gcc, cpp, gccint, gfortran
> etc. and only those contain *.html files. COBOL
On Mon, 7 Apr 2025, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the COBOL documentation is currently not present
> in onlinedocs at all.
> While the script generates gcobol{,-io}.{pdf,html}, it generates them in
> the gcc/gcc/cobol/ subdirectory of the update_web_docs_git temporary
> d
On 07/04/2025 09:07, Thomas Schwinge wrote:
Hi!
On 2025-03-14T11:39:20+0100, I wrote:
As the first of a few patches to enable libstdc++ for GCN, nvptx targets,
[...]
some more fine-tuning is to follow later on.)
Any comments before I push the attached
"GCN, nvptx libstdc++: Force use of '_
Hi!
As mentioned in the PR, the COBOL documentation is currently not present
in onlinedocs at all.
While the script generates gcobol{,-io}.{pdf,html}, it generates them in
the gcc/gcc/cobol/ subdirectory of the update_web_docs_git temporary
directory and nothing find it there afterwards, all the p
On Fri, 4 Apr 2025, Jakub Jelinek wrote:
> On Fri, Apr 04, 2025 at 08:52:10PM +0200, Richard Biener wrote:
> > > Or do you want something further (like
> > > switch (global_options.x_flag_cf_protection & ~CF_SET)
> > > )?
> >
> > Dunno what that CF_SET is, we’re supposed to record options like th
Hi!
What make html does for COBOL is quite inconsistent with all
other FEs. Normally make html creates HTML/gcc-15.0.1/
subdirectory and puts there subdirectories like gcc, cpp, gccint, gfortran
etc. and only those contain *.html files. COBOL puts gcobol.html and
gcobol-io.html into the current
When the whole shift is invariant but the shift amount needs
to be converted and a vector shift used we can mess up placement
of vector stmts because we do not make SLP scheduling aware of
the need to insert code for it. The following mitigates this
by more conservative placement of such code in v
When MUL is not available, then the __umulhisi3 and __mulhisi3
functions can use __mulhisi3_helper. This improves code size,
stack footprint and runtime on AVRrc. Applied as obvious.
Johann
--
AVRrc: Tweak __[u]mulhisi3.
When MUL is not available, then the __umulhisi3 and __mulhisi3
functio
Add compile-only OpenMP error tests for target clause used with SVE types.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/gomp/gomp.exp: Test driver.
* gcc.target/aarch64/sve/gomp/target-device.c: New test.
* gcc.target/aarch64/sve/gomp/target-link.c: Likewise.
Add a function to traverse down the pointer layers to the pointee type.
gcc/ChangeLog:
* tree.h (strip_pointer_types): New.
---
gcc/tree.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/tree.h b/gcc/tree.h
index 55f97f9f999..99f26177628 100644
--- a/gcc/tree.h
+++ b/
Hi,
I've combined the two patchsets
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678086.html
and the associated tests in
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680030.html
into a single patchset with the review comments incorporated. Thanks
Jakub and RichardS for the r
Add AArch64 SVE target exectute tests to test various workshare constructs and
clauses with SVE types.
libgomp/ChangeLog:
* testsuite/libgomp.c-target/aarch64/aarch64.exp: Test driver.
* testsuite/libgomp.c-target/aarch64/firstprivate.c: New test.
* testsuite/libgomp.c-tar
On Mon, Apr 07, 2025 at 03:28:29PM +0530, Tejas Belagod wrote:
> Add AArch64 SVE target exectute tests to test various workshare constructs and
> clauses with SVE types.
>
> libgomp/ChangeLog:
>
> * testsuite/libgomp.c-target/aarch64/aarch64.exp: Test driver.
> * testsuite/libgomp.c-t
From: Richard Sandiford
Various parts of the omp code checked whether the size of a decl
was an INTEGER_CST in order to determine whether the decl was
variable-sized or not. If it was variable-sized, it was expected
to have a DECL_VALUE_EXPR replacement, as for VLAs.
This patch uses poly_int_tr
The target clause in OpenMP is used to offload loop kernels to accelarator
peripeherals. target's 'map' clause is used to move data from and to the
accelarator. When the data is SVE type, it may not be suitable because of
various reasons i.e. the two SVE targets may not agree on vector size or
so
On 06/04/2025 19:49, Christophe Lyon wrote:
The previous version of this test required arch v6+ (for sxth), and
the number of vmov depended on the float-point ABI (where softfp
needed more of them to transfer floating-point values to and from
general registers).
With this patch we require arch v
On Mon, Apr 07, 2025 at 11:43:27AM +0200, Richard Biener wrote:
> I do wonder with all these patches whether it would be better to
> preserve the LHS on musttail calls instead?
It can't be instead, because without musttail all those tests regress
as well (before IPA-VRP they were successfully tail
On Mon, 7 Apr 2025, Jakub Jelinek wrote:
> Hi!
>
> The IPA-VRP workaround in the tailc/musttail passes was just comparing
> the singleton constant from a tail call candidate return with the ret_val.
> This unfortunately doesn't work in the following testcase, where we have
>[local count: 1522
On Sun, Apr 6, 2025 at 10:03 AM Iain Sandoe wrote:
>
> Even when we are using IEC 128b floating point, the quadmath library can
> be pulled in 'as needed'.
LGTM.
> gcc/testsuite/ChangeLog:
>
> * lib/cobol.exp: Add libquadmath paths.
>
> Signed-off-by: Iain Sandoe
> ---
> gcc/testsuite/
在 2025/4/7 下午4:02, Jakub Jelinek 写道:
On Mon, Apr 07, 2025 at 03:44:52PM +0800, Lulu Cheng wrote:
In GCC14, LoongArch added __float128 as an alias for _Float128.
In commit r15-8962, support for q/Q suffixes for 128-bit floating point
numbers. This will cause the compiler to automatically link
On Mon, Apr 07, 2025 at 03:12:22PM +0800, Lulu Cheng wrote:
> In GCC14, LoongArch added __float128 as an alias for _Float128.
> In commit r15-8962, support for q/Q suffixes for 128-bit floating point
> numbers. This will cause the compiler to automatically link libquadmath
> when compiling Fortran
In GCC14, LoongArch added __float128 as an alias for _Float128.
In commit r15-8962, support for q/Q suffixes for 128-bit floating point
numbers. This will cause the compiler to automatically link libquadmath
when compiling Fortran programs. But on LoongArch `long double` is
IEEE quad, so there is
For technical reasons, the recently reimplemented finalization machinery for
controlled types requires arrays of controlled types to be allocated with
their bounds, including in the case where their nominal subtype is
constrained. However, in this case, the type of 'Access for the arrays is
po
In GCC14, LoongArch added __float128 as an alias for _Float128.
In commit r15-8962, support for q/Q suffixes for 128-bit floating point
numbers. This will cause the compiler to automatically link libquadmath
when compiling Fortran programs. But on LoongArch `long double` is
IEEE quad, so there is
Hi,
On Tue, Apr 01 2025, Richard Biener wrote:
> On Mon, 31 Mar 2025, Martin Jambor wrote:
>
>> Hi,
>>
>> the testcase in PR 118924, when compiled on Aarch64, contains an
>> gimple aggregate assignment statement in between different types which
>> are types_compatible_p but behave differently for
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, March 31, 2025 1:43 PM
> To: i...@sandoe.co.uk
> Cc: Tamar Christina ; GCC Patches patc...@gcc.gnu.org>; Alice Carlotti ; Richard
> Sandiford
> ; s...@gentoo.org
> Subject: Re: [PATCH v2] aarch64, Darwin: Initial implementation
On Mon, Apr 7, 2025 at 9:41 AM Simon Sobisch wrote:
>
>
>
> Am 07.04.2025 um 09:30 schrieb Richard Biener:
> > On Mon, Apr 7, 2025 at 9:00 AM Simon Sobisch wrote:
> >>
> >> My question stands on integrating COBOLworx' UAT as-is for now
> >> (Copyright is all on FSF; built automatically [it is aut
Hi!
On 2025-03-14T11:39:20+0100, I wrote:
> As the first of a few patches to enable libstdc++ for GCN, nvptx targets,
> [...]
> some more fine-tuning is to follow later on.)
Any comments before I push the attached
"GCN, nvptx libstdc++: Force use of '__atomic' builtins [PR119645]"?
Jonathan, pl
On Mon, Apr 07, 2025 at 03:44:52PM +0800, Lulu Cheng wrote:
> In GCC14, LoongArch added __float128 as an alias for _Float128.
> In commit r15-8962, support for q/Q suffixes for 128-bit floating point
> numbers. This will cause the compiler to automatically link libquadmath
> when compiling Fortran
Am 07.04.2025 um 09:36 schrieb Jakub Jelinek:
On Mon, Apr 07, 2025 at 09:30:59AM +0200, Richard Biener wrote:
On Mon, Apr 7, 2025 at 9:00 AM Simon Sobisch wrote:
My question stands on integrating COBOLworx' UAT as-is for now
(Copyright is all on FSF; built automatically [it is autoconf, which
Sam James writes:
> Richard Sandiford writes:
>
>> This series is an update of:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/679924.html
>>
>> As discussed in that thread, the changes since last time are to make
>> distribute_links start from the last use, where easy, and to avoid
> On 7 Apr 2025, at 01:19, Simon Sobisch wrote:
>
> As noted in bug #119632, ignored section segments should be a warning,
> ideally with an option to raise that to an error, like -Wignored, which
> should be included with -Wall (note bug #119329) and is fine to be also
> raised by default (
In GCC14, LoongArch added __float128 as an alias for _Float128.
In commit r15-8962, support for q/Q suffixes for 128-bit floating point
numbers. This will cause the compiler to automatically link libquadmath
when compiling Fortran programs. But on LoongArch `long double` is
IEEE quad, so there is
Am 07.04.2025 um 09:30 schrieb Richard Biener:
On Mon, Apr 7, 2025 at 9:00 AM Simon Sobisch wrote:
My question stands on integrating COBOLworx' UAT as-is for now
(Copyright is all on FSF; built automatically [it is autoconf, which is
a requirement for VCS checkouts], possibly also hooked in
On Mon, Apr 7, 2025 at 9:00 AM Simon Sobisch wrote:
>
> My question stands on integrating COBOLworx' UAT as-is for now
> (Copyright is all on FSF; built automatically [it is autoconf, which is
> a requirement for VCS checkouts], possibly also hooked into the current
> test target) - with the goal
在 2025/4/7 下午3:19, Jakub Jelinek 写道:
On Mon, Apr 07, 2025 at 03:12:22PM +0800, Lulu Cheng wrote:
The above hunks clearly show that you're regenerating it with some patched
autoconf or something like that. Please manually remove those hunks or use
vanilla upstream autoconf 2.69. Otherwise the
My question stands on integrating COBOLworx' UAT as-is for now
(Copyright is all on FSF; built automatically [it is autoconf, which is
a requirement for VCS checkouts], possibly also hooked into the current
test target) - with the goal to get rid of UAT later (next GCC version,
not GCC 15).
T
On Fri, Apr 4, 2025 at 11:50 PM Robert Dubner wrote:
>
> Anybody who might have gotten interested should stand down.
>
> As usual, that analysis got me thinking.
>
> I got focused on where var_decl_return_code was being used. (I was wrong.
> I made the mistake because I had just eliminated two se
omp_target_memcpy_rect uses Nvidia's (CUDA) and AMD's (ROCr/HSA)
features to transfer noncontiguous rectangular data efficient.
While for CUDA, the wording was already there, it was missing
for HSA. (Both landed in GCC 14, albeit HSA half a year later.)
This patch adds it also for AMD GPUs; for
On Sun, 6 Apr 2025 at 14:39, Paul Richard Thomas
wrote:
>
> Hi All,
>
> As far as I can tell, the attached patch fixes the problems with the reduce
> intrinsic. I would be grateful to the reporters if they would confirm that
> this is the case.
>
> The key to the fix appears in reduce_3.f90, whi
72 matches
Mail list logo
