Hi All,
When the input is already a subreg and we try to make a paradoxical
subreg out of it for copysign this can fail if it violates the sugreg
relationship.
Use force_lowpart_subreg instead of lowpart_subreg to then force the
results to a register instead of ICEing.
Bootstrapped Regtested on
Hello,
I've added myself to MAINTAINERS. Patch is attached.
Thank you,
--
Giuseppe D'Angelo
From a3f77f2528b9383c70f0361e0f3863cee58e9648 Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Fri, 28 Feb 2025 08:37:25 +0100
Subject: [PATCH] MAINTAINERS: add myself to write after approval and D
Hi Thomas,
are you really telling me, that gfortran's coarray test library is compiled for
offloading to GPU (or other SIMD processors)? Because that's what NVPTX is used
for most, right? In my opinion that makes no sense, because coarrays in Fortran
are used for SISD style accesses. Although the
This patch modifies the sequence:
vsetvli zero,a4,e32,m4,ta,ma + vsetvli zero,a4,e8,m2,ta,ma
to:
vsetvli zero,a4,e32,m8,ta,ma + vsetvli zero,zero,e8,m2,ta,ma
Functionally, there is no difference. However, this change resolves the
issue with "e64,mf4", and allows the second vsetvli to omit a4, wh
On Thu, 27 Feb 2025 16:00:08 +0100, "Robin Dapp" wrote:
> Hi,
>
> when merging two vsetvls that both only demand "SEW >= ..." we
> use their maximum SEW and keep the LMUL. That may lead to invalid
> vector configurations like
> e64, mf4.
> As we make sure that the SEW requirements overlap we ca
On Mon, Feb 17, 2025 at 9:51 AM Hongtao Liu wrote:
>
> On Thu, Feb 13, 2025 at 4:08 PM Haochen Jiang wrote:
> >
> > Hi all,
> >
> > According to the previous feedback on our RFC for AVX10 option adjustment
> > and discussion with LLVM, we finalized how we are going to handle that.
> >
> > The ove
My r15-998-g2a83084ce55363 change replaced the use of nothrow
operator new with a call to __get_temporary_buffer, so update the
comment to match.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (_Impl::_M_allocate): Fix outdated
comment.
---
Lightly tested on x86_64-linux (becau
On Wed, Feb 26, 2025 at 6:01 AM H.J. Lu wrote:
>
> Move the TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P target hook from
> i386.h to i386.cc.
Ok for the patch, looks obvious.
>
> * config/i386/i386.h (TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P):
> Moved to ...
> * config/i386/i386.cc (TARGET_SMALL_REGI
Hi,
This patches fixes the libphobos unittest testsuite to use `dg-runtest'
test driver rather than `dg-test', same as all other libphobos tests.
This prevents the tests from being ran multiple times when parallelized.
Set `libphobos_test_name' as well so that all tests get a unique name.
Regres
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
-- >8 --
When a generic lambda calls an overload set containing an iobj member
function we speculatively capture 'this'. We need to do the same
for an xobj member function.
PR c++/119038
gcc/cp/ChangeLog:
Tested on x86_64-pc-linux-gnu, does this look OK for stage 1?
-- >8 --
The PR68942 fix used the tf_conv flag to disable mark_used when
substituting a FUNCTION_DECL callee of an ADL-enabled call. In this
slightly more elaborate testcase, we end up prematurely calling
mark_used anyway on the FUNCT
> Am 27.02.2025 um 20:54 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase ICEs, because we first construct file_cache object
> inside of *global_dc, then process options and then call file_cache::tune.
> The earlier construction allocates the m_file_slots array (using new)
> based o
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> On Thu, 27 Feb 2025 at 20:52, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > 14?
>
> OK for both.
Thanks.
>
> Do we want a library issue for this? The "buggy" code you're changing
> is exact
The ranges::move and ranges::move_backward algorithms are supposed to
use ranges::iter_move(iter) instead of std::move(*iter), which matters
for an iterator type with an iter_move overload findable by ADL.
Currently those algorithms use std::__assign_one which uses std::move,
so define a new range
The standard requires that we reject attempts to create a ranges::to
adaptor for cv-qualified types and non-class types. Currently we only
diagnose it once the adaptor is used in a pipeline.
This adds static assertions to diagnose it immediately.
libstdc++-v3/ChangeLog:
PR libstdc++/1128
The specification for std::ranges::iter_move apparently requires us to
handle types which do not satisfy std::indirectly_readable, for example
with overloaded operator* which behaves differently for different value
categories.
libstdc++-v3/ChangeLog:
PR libstdc++/106612
* include/
On Thu, 27 Feb 2025 at 20:52, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> 14?
OK for both.
Do we want a library issue for this? The "buggy" code you're changing
is exactly what the standard says.
>
> -- >8 --
>
> Here for
>
> using RCI =
On 2/27/25 11:31 AM, Harald Anlauf wrote:
Am 27.02.25 um 02:58 schrieb Jerry D:
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 1
On Thu, 27 Feb 2025 at 21:03, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> 14? Not sure about backporting further given the original fix seems
> harmless.
Yeah, trunk and 14 seems good enough. Thanks.
>
> -- >8 --
>
> It turns out the reason
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14? Not sure about backporting further given the original fix seems
harmless.
-- >8 --
It turns out the reason the behavior of this testcase changed after CWG
2369 is because validity of the substituted return type is now che
> Am 27.02.2025 um 21:11 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase is miscompiled since r15-7597.
> The left comparison is unsigned (x & 0x8000U) != 0) while the
> right one is signed (x >> 16) >= 0 and is actually a signbit test,
> so rsignbit is 64.
> After debugging this a
gcc/testsuite/
* gcc.target/nvptx/stack_frame-1.c: New.
---
.../gcc.target/nvptx/stack_frame-1.c | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/nvptx/stack_frame-1.c
diff --git a/gcc/testsuite/gcc.target/nvptx/stack
... instead of 64 via 'gcc/defaults.h':
MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (DImode)
This fixes ICEs:
[-FAIL: c-c++-common/pr111309-1.c -Wc++-compat (internal compiler error:
in expand_fn_using_insn, at internal-fn.cc:268)-]
[-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c -Wc++-com
As of recent commit 8bf0ee8d62b8a08e808344d31354ab713157e15d
"Fortran: Add transfer_between_remotes [PR107635]", we've got 'alloca' usage
in 'libgfortran/caf/single.c:_gfortran_caf_transfer_between_remotes', and
the libgfortran target library fails to build for legacy configurations where
PTX 'allo
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
-- >8 --
Here for
using RCI = reverse_iterator::iterator>>
static_assert(std::totally_ordered);
we effectively need to check the requirement
requires (RCI x) { x RELOP x; } for each RELOP in {<, >, <=, >=}
which
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 allocation, compilation and assembly then
succeeds
This gives the back end a chance to clean out a few more unnecessary instances
of dynamic stack allocation. This progresses:
PASS: gcc.dg/pr78902.c (test for warnings, line 7)
PASS: gcc.dg/pr78902.c (test for warnings, line 8)
PASS: gcc.dg/pr78902.c (test for warnings, line 9)
gcc/testsuite/
* gcc.target/nvptx/alloca-1-dead-O0-sm_30.c: New.
* gcc.target/nvptx/alloca-1-dead-O0.c: Likewise.
* gcc.target/nvptx/alloca-1-dead-O1-sm_30.c: Likewise.
* gcc.target/nvptx/alloca-1-dead-O1.c: Likewise.
* gcc.target/nvptx/alloca-1-unuse
On 2/27/25 12:33 PM, Peter Hill wrote:
On Thu, 27 Feb 2025 at 18:09, Jerry D wrote:
On 2/27/25 7:38 AM, Peter Hill wrote:
Dear all,
The attached patch fixes an ICE in gfc_resolve_code when passing an
optional array to an elemental procedure with `-pedantic` enabled.
PR95446 added the origina
Hi!
As documented in the manual, FIX/UNSIGNED_FIX from floating point
mode to integral mode has unspecified rounding and FIX from floating point
mode to the same floating point mode is expressing rounding toward zero.
So, some targets (arc, arm, csky, m68k, mmix, nds32, pdp11, sparc and
visium) us
On Thu, Feb 27, 2025 at 10:42:07AM -0500, Jason Merrill wrote:
> On 2/26/25 2:16 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Yet another problem that started with r15-6052, compile time evaluation of
> > prvalues.
> >
> > cp_fold_
On Thu, 27 Feb 2025 at 18:09, Jerry D wrote:
>
> On 2/27/25 7:38 AM, Peter Hill wrote:
> > Dear all,
> >
> > The attached patch fixes an ICE in gfc_resolve_code when passing an
> > optional array to an elemental procedure with `-pedantic` enabled.
> > PR95446 added the original check, this patch f
The following patch adds a test for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
The PR is actually solved by a patch I submitted this week for another PR.
commit 3071eb2848a2e748cfd67e8c897890ce06c69d06
Author: Vladimir N. Makarov
Date: Thu Feb 27 13:39:04 2025 -0500
[PR118940][
Hi!
The following testcase is miscompiled since r15-7597.
The left comparison is unsigned (x & 0x8000U) != 0) while the
right one is signed (x >> 16) >= 0 and is actually a signbit test,
so rsignbit is 64.
After debugging this and reading the r15-7597 change, I believe there
is just a pasto, the i
Hi!
I've added the asserts that probe == target because {REAL,IMAG}PART_EXPR
always implies a scalar type and so applying ARRAY_REF/COMPONENT_REF
etc. on it further doesn't make sense and the later code relies on it
to be the last one in refs array. But as the following testcase shows,
we can fai
Hi Andre,
Am 27.02.25 um 18:36 schrieb Andre Vehreschild:
Hi all,
attached patch fixes user defined finalizers in derived (class) types not
getting called, when the variable declared of that type was not used in the
current block. The patch ensures calling the finalizer by marking the
variable
Hi!
The following testcase ICEs, because we first construct file_cache object
inside of *global_dc, then process options and then call file_cache::tune.
The earlier construction allocates the m_file_slots array (using new)
based on the static data member file_cache::num_file_slots, but then tune
c
Am 27.02.25 um 02:58 schrieb Jerry D:
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 14?
OK for trunk.
I don't think we backp
On Thu, Feb 27, 2025 at 01:15:12PM -0500, Jason Merrill wrote:
> On 2/20/25 9:51 AM, Marek Polacek wrote:
> > Now with the test fixed.
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > In this PR we crash in cxx_eval_constant_expression/GOTO_EXPR on:
> >
>
This is a test taken from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116336
The PR is actually solved a few weeks ago.
commit e59dd301aea9c8d5a5d04e808c87d591a26e85bb
Author: Vladimir N. Makarov
Date: Thu Feb 27 13:05:44 2025 -0500
[PR116336][LRA]: Add a test
Patch for PR11
On 2/26/25 5:58 PM, Jerry D wrote:
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 14?
Regards,
Jerry
Author: Jerry DeLisle
D
Compared to v2, this splits out the alignment switching into a new class and
merges the rest of the switching functionality into aarch64_target_switcher,
as agreed with Richard in the previous review discussion.
Bootstrapped and regression tested on aarch64. Is this ok for master?
---
Refactor t
On 2/20/25 9:51 AM, Marek Polacek wrote:
Now with the test fixed.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
In this PR we crash in cxx_eval_constant_expression/GOTO_EXPR on:
gcc_assert (cxx_dialect >= cxx23);
The code obviously doesn't expect to see a goto pre-C
On 2/27/25 7:38 AM, Peter Hill wrote:
Dear all,
The attached patch fixes an ICE in gfc_resolve_code when passing an
optional array to an elemental procedure with `-pedantic` enabled.
PR95446 added the original check, this patch fixes the case where the
other actual argument is an array literal (
For the record, this small change have been committed as part of another
larger one:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bcc8dea6a45b46febfa76df6f5e3e5b13f3b4a58
On 19/02/2025 13:49, Jonathan Wakely wrote:
On Mon, 17 Feb 2025 at 11:59, François Dumont wrote:
On 16/02/2025 23:14,
Hi all,
attached patch fixes user defined finalizers in derived (class) types not
getting called, when the variable declared of that type was not used in the
current block. The patch ensures calling the finalizer by marking the
variable referenced, if it has not been.
Additionally I had to patch
On Thu, Feb 27, 2025 at 10:48:14AM -0500, Jason Merrill wrote:
> > --- libcpp/directives.cc.jj 2025-02-13 19:59:56.202572170 +0100
> > +++ libcpp/directives.cc2025-02-20 21:40:56.379899457 +0100
> > @@ -1367,7 +1367,7 @@ do_embed (cpp_reader *pfile)
> > {
> > if (CPP_OPTION (pfile
> gcc/ChangeLog:
>
> 2025-02-24 Martin Jambor
>
> PR ipa/118785
>
> * ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Handle non-conversion
> unary operations separately before doing any conversions. Check
> expr_type_first_operand_type_p for non-unary operations too.
> gcc/ChangeLog:
>
> 2025-02-10 Martin Jambor
>
> PR ipa/118243
> * ipa-sra.cc (pull_accesses_from_callee): New parameters
> caller_ipcp_ts and param_idx. Check that scalar pulled accesses would
> not clash with a known IPA-CP aggregate constant.
> (param_splitting
On 2/20/25 5:53 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Since C++20 P0846, a name followed by a < can be treated as a template-name
even though name lookup did not find a template-name. That happens
in this test with "i < foo ()":
On 2/24/25 4:31 AM, Jakub Jelinek wrote:
Hi!
Now that the #embed paper has been voted in, the following patch
removes the pedwarn for C++26 on it (and adjusts pedwarn warning for
older C++ versions) and predefines __cpp_pp_embed FTM.
I believe we otherwise implement everything in the paper alre
On 2025-02-27 16:36, Richard Earnshaw wrote:
On 17/12/2024 15:04, Richard Earnshaw (lists) wrote:
On 15/11/2024 10:15, Christophe Lyon wrote:
On Thu, 14 Nov 2024 at 18:33, Torbjorn SVENSSON
wrote:
On 2024-11-14 16:53, Christophe Lyon wrote:
On Sun, 10 Nov 2024 at 17:44, Torbjörn SVENSS
On 2/26/25 2:16 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Yet another problem that started with r15-6052, compile time evaluation of
prvalues.
cp_fold_r/TARGET_EXPR sees:
TARGET_EXPR >>>
so when we call maybe_constant_init, the obje
Dear all,
The attached patch fixes an ICE in gfc_resolve_code when passing an
optional array to an elemental procedure with `-pedantic` enabled.
PR95446 added the original check, this patch fixes the case where the
other actual argument is an array literal (or something else other
than a variable)
On 17/12/2024 15:04, Richard Earnshaw (lists) wrote:
> On 15/11/2024 10:15, Christophe Lyon wrote:
>> On Thu, 14 Nov 2024 at 18:33, Torbjorn SVENSSON
>> wrote:
>>>
>>>
>>>
>>> On 2024-11-14 16:53, Christophe Lyon wrote:
On Sun, 10 Nov 2024 at 17:44, Torbjörn SVENSSON
wrote:
>
>
This test uses incremental linking, but that can generate warnings if
the LTO step contains a mix of LTO and non-LTO object files (this can
happen when there's a testglue file that is normally included during
linking).
We don't care about the testglue, though, so just tell the LTO
optimizer to gen
Hi,
when merging two vsetvls that both only demand "SEW >= ..." we
use their maximum SEW and keep the LMUL. That may lead to invalid
vector configurations like
e64, mf4.
As we make sure that the SEW requirements overlap we can use the SEW
and LMUL of the configuration with the larger SEW.
Ma J
On 26/02/25 17:27 +0100, Giuseppe D'Angelo wrote:
On 26/02/2025 16:33, Giuseppe D'Angelo wrote:
Whops, sorry, missed this sub-thread (while replying to the other one).
Change of plans then, I'll amend and remove the ad-hoc constexpr macro.
Done, v3 attached.
Thanks,
--
Giuseppe D'Angelo
F
Hi, Jakub,
Thanks a lot for fixing this issues.
Qing
> On Feb 26, 2025, at 03:53, Jakub Jelinek wrote:
>
> Hi!
>
> r15-209 allowed flexible array members inside of unions, but as the
> following testcase shows, not everything has been adjusted for that.
> Unlike structures, in unions flexible
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> Compiling a Cobol Hello World results in
>
> > ./install/gcc-cobol/usr/local/bin/gcobol t.cob
> /usr/bin/ld: cannot find -lgcobol: No such file or directory
> collect2: error: ld returned 1 exit status
>
> possibly because the 64bit lib
Status
==
The GCC development branch which will become GCC 15 is still in
stage4, open for regression and documentation fixes only. We've
been in this stage for 6 weeks now and are slowly progressing
towards a release.
Besides of tackling the remaining P1 bugs also have an eye on
the testsui
From: Pan Li
This patch would like to fix one bug when expanding const vector for the
interleave case. For example, we have:
base1 = 151
step = 121
For vec_series, we will generate vector in format of v[i] = base + i * step.
Then the vec_series will have below result for HImode, and we can fin
Hi Jin Ma:
I realized multilib os dir is not correctly set as you described, but
I think that info should just come from multilib_select rather than
creating a new hook to do that, anyway I just wrote a fix...because we
hit that issue last week...
Hi Jeff:
Here is another approach to fix that -
This patch fixes the multilib_os_dir and multiarch_dir for those targets
that use TARGET_COMPUTE_MULTILIB, since the TARGET_COMPUTE_MULTILIB hook
only update/fix the multilib_dir but not the multilib_os_dir and multiarch_dir,
so the multilib_os_dir and multiarch_dir are not set correctly for those
On 17/02/2025 14:28, Alex Coplan wrote:
> Hi,
>
> After the recent alignment peeling enhancements in the vectorizer we
> started vectorizing the "checking" loops (that check for the right
> result) in gcc.target/powerpc/vsx-vectorize-*.c, thus skewing the
> expected counts of various scan-dump-ti
Sure thing, will send the v5 for CI system and commit it if no surprise.
BTW, shall we plan some refactor for expand_const_vector in next stage 1, which
grows to more than 500 lines and unfriendly for debugging up to a point.
Yeah, sounds very reasonable.
--
Regards
Robin
Sure thing, will send the v5 for CI system and commit it if no surprise.
BTW, shall we plan some refactor for expand_const_vector in next stage 1, which
grows to more than 500 lines and unfriendly for debugging up to a point.
Pan
-Original Message-
From: Robin Dapp
Sent: Thursday
Hi Tobias!
On 2025-02-17T19:49:43+0100, Tobias Burnus wrote:
> OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant
> [PR115271]
The OG14 "cherry-pick" of this apparently has some different code at
least in one place; trunk code:
> --- a/gcc/fortran/openmp.cc
> +++ b/g
Excerpts from Lewis Hyatt's message of Februar 26, 2025 2:04 am:
> On Tue, Feb 25, 2025 at 12:00 PM Iain Buclaw wrote:
>>
>> Hi,
>>
>> It was noticed that when running the testsuite for gdc and libphobos in
>> parallel, this was capped at 10 simultaneous jobs each. Increase this
>> limit to 128,
+/* { dg-do run { target { riscv_v } } } */
+/* { dg-options "-O3 -march=rv64gcv -flto -mrvv-vector-bits=zvl" } */
Ah, the CI flagged the test in previous versions. It's missing the usual
-mabi=... I keep forgetting this...
--
Regards
Robin
Hi Pan,
+ poly_int64 base1_poly = rtx_to_poly_int64 (base1);
+ bool overflow_smode_p = false;
+
+ if (!step1.is_constant ())
+ overflow_smode_p = true;
+ else
+ {
+ int elem_count = XVECLEN (src, 0);
+ uint64_t step1_val
On Wed, 26 Feb 2025, Tamar Christina wrote:
> > > >
> > > > No, I don't think so. The code that eventually performs a
> > > > contiguous sub-group access directly should never extend
> > > > the load beyond GROUP_SIZE - or should be gated on the DR
> > > > not executed speculatively. That is, we
Hi!
The following testcase is miscompiled during evrp.
Before vrp, we have (from ccp):
# RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000
VALUE 0x2d
_3 = _2 + 18446744073708503085;
...
# RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000
VALUE 0x
Hi Thomas,
thanks for the review. Committed as gcc-15-7726-g0fc1abcc46e.
Thanks again,
Andre
On Wed, 26 Feb 2025 21:40:51 +0100
Thomas Koenig wrote:
> Hi Andre,
>
> > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> Looks good to me.
>
> Thanks for the patch!
>
> Best reg
From: Pan Li
This patch would like to fix one bug when expanding const vector for the
interleave case. For example, we have:
base1 = 151
step = 121
For vec_series, we will generate vector in format of v[i] = base + i * step.
Then the vec_series will have below result for HImode, and we can fin
This patch support Qualcomm uC Xqccmp extension[1].
To enable GCC to recognize and process xqccmp extension correctly at
compile time.
[1]https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0
Changes for v2:
- Remove the addition of xqccmp extension in
gcc/common/config
76 matches
Mail list logo
