Hi Andrew,
"Apologies, I just realized that my previous reply may not have gone through.
I'm resending it for your reference."
Thank you for your response. I just wanted to clarify the issue I’m facing. The
concern is not that new files are being generated,
but rather that the LTO debug files a
> On 10 Dec 2024, at 7:09 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Soumya AR writes:
>> @@ -1815,6 +1849,42 @@
>> }
>> )
>>
>> +(define_insn "*aarch64_sve2_bsl2n_unpred"
>> + [(set (match_operand:VDQ_I 0 "register_operand")
>> +
> On 10 Dec 2024, at 7:03 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Soumya AR writes:
>> Hi Richard,
>>
>> Thanks for reviewing this!
>>
>> I’ve made the suggested changes and added the aarch64_ptrue_reg overload.
>
> The updated pa
On Mon, Dec 9, 2024 at 8:55 PM Alexandre Oliva wrote:
>
> This patch introduces various improvements to the logic that merges
> field compares, while moving it into ifcombine.
>
> Before the patch, we could merge:
>
> (a.x1 EQNE b.x1) ANDOR (a.y1 EQNE b.y1)
>
> into something like:
>
> (((ty
On Mon, 9 Dec 2024, Tamar Christina wrote:
> > >> So I think we can simply set const_n_elts to CONSTRUCTOR_NELTS
> > >> for vector_typed_elts_p?
> > >>
> > >
>
> Done,
>
> gcc/ChangeLog:
>
> PR target/96342
> * expr.cc (store_constructor): add support for variable-length
> vec
On Mon, 9 Dec 2024, Tamar Christina wrote:
> > > if (need_to_clear && maybe_gt (size, 0) && !vector)
> > > @@ -8058,9 +8058,9 @@ store_constructor (tree exp, rtx target, int
> > > cleared,
> > poly_int64 size,
> > >element of TARGET, determined by counting the elements. */
>
Hi,
int:
struct foo
{
int a;
void bar() const;
~foo()
{
if (a != 42)
__builtin_abort ();
}
};
__attribute__ ((noinline))
void test(const struct foo a)
{
int b = a.a;
a.bar();
if (a.a != b)
__builtin_printf ("optimize me away");
}
struct foo is p
Currently the __relocate_a function implementing in-place relocation for
std::vector only optimizes to memcpy for std::allocator, which is safe
because we know the precise effects of std::allocator::construct and
std::allocator::destroy. We could extend the optimization to other
allocators which do
Pushed r15-6090-gcf406a6c
Thanks for the review!
Jerry
On 12/10/24 12:15 AM, Andre Vehreschild wrote:
Hi Jerry,
patch looks good. Ok for mainline and backport after grace period.
Thanks for the patch,
Andre
On Mon, 9 Dec 2024 20:31:08 -0800
Jerry D wrote:
Hi all,
The attached p
On Thu, 28 Nov 2024 at 15:12, Marek Polacek wrote:
>
> On Thu, Nov 28, 2024 at 11:27:32AM +, Dimitri John Ledkov wrote:
> > Did bootstrap with gcc-14 (clean cherrypick, minor offsets).
> > Built and tested on arm64 & x86_64.
> > It resolved the reported problem.
> > Thank you for this patch.
>
Check the __glibcxx_polymorphic_allocator macro instead of just checking
whether __cplusplus > 201703L.
libstdc++-v3/ChangeLog:
* include/bits/memory_resource.h (polymoprhic_allocator): Use
feature test macro for P0339R6 features.
---
Tested x86_64-linux. Pushed to trunk.
libst
Difference with v3: Refresh
Samuel Thibault (3):
ada: Factorize bsd signal definitions
ada: Fix GNU/Hurd priority range
ada: Add GNU/Hurd x86_64 support
gcc/ada/Makefile.rtl | 52 +-
...-intnam__freebsd.ads => a-intnam__bsd.ads} | 2 +-
gcc/ada/libgnarl/a-in
GNU/Mach currently uses a 0..63 range.
gcc/ada/ChangeLog:
* libgnat/system-gnu.ads: New file.
* Makefile.rtl (x86-gnuhurd): Use libgnat/system-gnu.ads instead of
libgnat/system-freebsd.ads.
Signed-off-by: Samuel Thibault
---
gcc/ada/Makefile.rtl | 2 +-
gcc/
They are all the same on all BSD-like systems (including GNU/Hurd).
gcc/ada/ChangeLog:
* libgnarl/a-intnam__freebsd.ads: Rename to...
* libgnarl/a-intnam__bsd.ads: ... new file.
* libgnarl/a-intnam__dragonfly.ads: Remove file.
* Makefile.rtl (x86-kfreebsd, x86-gnuh
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-6095-gf102b82d3da6dd.
gcc/ChangeLog:
PR sarif-replay/117944
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Get any
helpUri from the rule_obj and pass it to add_rule.
Signed-off-
On Tue, 29 Oct 2024 at 13:20, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> 14?
OK for both, thanks.
>
> -- >8 --
>
> Use a local reference for the (now possibly lifetime extended) result of
> *__first to avoid making unnecessary copies of it.
On Linux/x86_64,
6fc3da8fa2af1d4ee154ea803636eabde358b553 is the first bad commit
commit 6fc3da8fa2af1d4ee154ea803636eabde358b553
Author: Vladimir N. Makarov
Date: Tue Dec 10 12:50:27 2024 -0500
[PR117946][LRA]: When assigning hard reg use biggest mode to check
ira_prohibited_class_mode_r
contrib/ChangeLog:
* gcc-changelog/git_commit.py (bug_components): Add
'libgdiagnostics' and 'sarif-replay'.
Signed-off-by: David Malcolm
---
contrib/gcc-changelog/git_commit.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/g
On Sat, 2024-12-07 at 10:19 -0500, Jason Merrill wrote:
> On 11/15/24 8:02 PM, David Malcolm wrote:
> > This patch is a followup to:
> > "c++: use diagnostic nesting [PR116253]"
> >
> > Following Sy Brand's UX suggestions in P2429R0 for example 1, this
> > patch
> > tweaks print_z_candidates to
On Mon, Dec 09, 2024 at 09:40:41AM -0800, Palmer Dabbelt wrote:
> On Mon, 09 Dec 2024 09:05:10 PST (-0800), Robin Dapp wrote:
> > > +/* { dg-additional-options "-mabi=lp64d" { target { rv64 } } } */
> > > +/* { dg-additional-options "-mabi=ilp32d" { target { rv32 } } } */
> >
> > Wouldn't skipping
writes:
> This patch adds the TARGET_CREATE_FMV_DISPATCHER_AT_DEFAULT_IMPL flag
> which changes FMV behavior for target_version functions to match the Arm
> C Language Extension.
>
> The functional differences consist of:
> 1. Generating the resolver for the dispatched symbol at the site of the
>
On Mon, Dec 9, 2024 at 11:54 PM Richard Sandiford
wrote:
>
> This patch removes the remaining traces of the vcond{,u,eq} optabs.
> Earlier patches removed the target-independent uses and I couldn't
> find any direct references to either the *_optabs or the ifns
> in target-specific code.
>
> Teste
Richard Biener writes:
> On Mon, Dec 9, 2024 at 11:54 PM Richard Sandiford
> wrote:
>>
>> This patch removes the remaining traces of the vcond{,u,eq} optabs.
>> Earlier patches removed the target-independent uses and I couldn't
>> find any direct references to either the *_optabs or the ifns
>> i
On Tue, 3 Dec 2024, Mike Stump wrote:
> > These tests can take several seconds per compilation to complete, taking
> > total elapsed time measured in minutes. Mark them as expensive so as to
> > let people skip them where they want to save on testing time.
> >
> > gcc/testsuite/
> > *
Soumya AR writes:
> @@ -1815,6 +1849,42 @@
>}
> )
>
> +(define_insn "*aarch64_sve2_bsl2n_unpred"
> + [(set (match_operand:VDQ_I 0 "register_operand")
> + (ior:VDQ_I
> + (and:VDQ_I
> + (match_operand:VDQ_I 1 "register_operand")
> + (match_operand:VDQ_I 2 "register_
Gentle ping. Any guidance on how to continue here?
--
Regards
Robin
On 03/12/2024 10:41, Claudio Bantaloukas wrote:
On 12/3/2024 10:24 AM, Kyrylo Tkachov wrote:
Hi Claudio,
On 2 Dec 2024, at 19:14, Claudio Bantaloukas
wrote:
The previous version of the patch was based on the mistaken
assumption that
features in /proc/cpuinfo had matching names to the fe
On Mon, Dec 9, 2024 at 8:38 PM Hans-Peter Nilsson wrote:
>
> I could probably assume that this is what you had in mind,
> but anyway: Ok to commit?
OK.
> -- >8 --
> PR117973 covers the aspect of
> non-LOGICAL_OP_NON_SHORT_CIRCUIT targets for PR111456, for
> which the test-case gcc.dg/tree-ssa/pr
std::is_trivial is deprecated in C++26, so this test needs to use
-Wno-deprecated now.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/trivial1.C: Add -Wno-deprecated for C++26.
---
Tested x86_64-linux. Pushed to trunk.
gcc/testsuite/g++.dg/cpp0x/trivial1.C | 1 +
1 file changed, 1 insertion(+
Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixe by avoiding redundant debug checks in std::array, there are many
more cases where the
Jason Merrill writes:
> On 9/18/24 4:36 PM, Arsen Arsenović wrote:
>> This patch implements support for frames and promises with new-extended
>> alignment.
>> There are two kinds of alignment to worry about here:
>> - Promise alignment, which causes "internal" padding inside the frame
>>struc
On 12/10/24 10:58 AM, Arsen Arsenović wrote:
Jason Merrill writes:
On 9/18/24 4:36 PM, Arsen Arsenović wrote:
This patch implements support for frames and promises with new-extended
alignment.
There are two kinds of alignment to worry about here:
- Promise alignment, which causes "internal" p
On 12/9/24 6:28 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
OK.
-- >8 --
In a template, for things like void() we'll create a CAST_EXPR with
a null operand. That causes a crash with -Wduplicated-branches on:
false ? void() : void();
because w
> On 10 Dec 2024, at 16:20, Arsen Arsenović wrote:
>
> Trimmed sending this email by accident. Reposting the latter section:
>
> WRT the question of Clang compatibility: the layout of the frame is
> changed when internal padding is present (i.e. when the promise type has
> an alignment great
On Mon, 9 Dec 2024 at 13:21, Jonathan Wakely wrote:
>
> On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote:
> >Hello,
> >
> >This aligns __is_bitwise_relocatable with its modern meaning, that is,
> >checking for trivial move construction and destruction.
>
> Looks good, thanks.
>
> >Thanks,
> >--
>
Hi Richard,
Thanks for reviewing this!
I’ve made the suggested changes and added the aarch64_ptrue_reg overload.
Thank you for providing the implementation for this, I have added you
as a co-author for the patch, hope that works :)
Best,
Soumya
> On 5 Dec 2024, at 10:08 PM, Richard Sandiford
On Tue, 10 Dec 2024 at 09:56, Jonathan Wakely wrote:
>
> On Mon, 9 Dec 2024 at 13:21, Jonathan Wakely wrote:
> >
> > On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote:
> > >Hello,
> > >
> > >This aligns __is_bitwise_relocatable with its modern meaning, that is,
> > >checking for trivial move const
Thanks, and please see my comments as below:
>> Currently, if could, scev-cprop unconditionally replaces loop closed ssa with
>> an expression built from loop initial value and loop niter, which might cause
>> redundant code-gen when all interior computations related to IV inside loop
>> are also
On Mon, 9 Dec 2024, liuhongt wrote:
> > Please pass 'sbitmap' instead of auto_sbitmap&, it should properly
> > decay to that. Applies everywhere I think.
> >
>
> Changed.
>
> > In fact I wonder whether we should simply populate the bitmap
> > from a
> >
> > for (auto loop : loops_list (cfun,
As requested, I split up into one part for the TYPE_MODE and
another one for the array size to help with git bisecting. This
is the first part.
Bootstrapped and regression tested on x86_64.
Allow the TYPE_MODE of a type with an array as last member to differ from
another compatible type.
The second part now only contains the changes for array size.
I added back a special case for this instead of having the
'ignore_size' flag (which I would nevertheless assume might be
needed in the future when matching pointer types).
In this version, I added an exception to the special case t
Hi Andre,
I don't think that's possible but I am prepared to be proven wrong :-) Do
you have an example in mind, where this might happen?
Regards
Paul
On Tue, 10 Dec 2024 at 10:52, Andre Vehreschild wrote:
> Hi Paul,
>
> in principle the patch looks sound, but is the vptr_size always the sam
Hi Paul,
no, I don't have an example in mind out of the box.
May be something like:
type :: T
character :: s(:)
character :: c
end type
class(T) :: foo(2)
But that is just a guess. I was triggered only by the first condition your
patch removes, where span was used instead of the of element
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
The patch was successfully tested and bootstrapped on x86_64, ppc64le,
aarch64.
commit 6fc3da8fa2af1d4ee154ea803636eabde358b553
Author: Vladimir N. Makarov
Date: Tue Dec 10 12:50:27 2024 -0500
[PR117946][LRA
Hi,
On 10/12/2024 10:56, Jonathan Wakely wrote:
We need this to depend on is_trivially_copyable too, so we can use memcpy.
I'm testing a fix now to fix bootstrap.
There's a broader question I think, which is how much we want to "bend"
the language rules.
[basic] isn't really super-explicit
Hi Paul,
in principle the patch looks sound, but is the vptr_size always the same as a
descriptor->span? Can't the later be larger because of padding? If that is the
case, then the first `else if (UNLIMITED...` you removed in `gfc_get_array_span
()` would return a larger number.
Regards,
Hello,
This patch fixes a C++26 deprecation warning in g++'s (not libstdc++)
autotests.
Thanks,
--
Giuseppe D'Angelo
From c1abe8e7a219e6218478249b93945c96ac81a78a Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Tue, 10 Dec 2024 10:49:10 +0100
Subject: [PATCH] Fix some more is_trivial C
On Tue, Dec 10, 2024 at 11:04 AM Feng Xue OS
wrote:
>
> Thanks, and please see my comments as below:
>
> >> Currently, if could, scev-cprop unconditionally replaces loop closed ssa
> >> with
> >> an expression built from loop initial value and loop niter, which might
> >> cause
> >> redundant co
Soumya AR writes:
> Hi Richard,
>
> Thanks for reviewing this!
>
> I’ve made the suggested changes and added the aarch64_ptrue_reg overload.
The updated patch is OK, thanks.
> Thank you for providing the implementation for this, I have added you
> as a co-author for the patch, hope that works :
On Mon, Dec 09, 2024 at 06:05:10PM +0100, Robin Dapp wrote:
> > +/* { dg-additional-options "-mabi=lp64d" { target { rv64 } } } */
> > +/* { dg-additional-options "-mabi=ilp32d" { target { rv32 } } } */
>
> Wouldn't skipping those tests also be reasonable?
> I.e. adding a target to the compile dir
Hi Paul,
the patch looks ok to me, but one questions remains:
You are doing this for all character arrays. Would it not be sufficient to
create the DECL only for deferred chararrays?
Ok for mainline and with a grace period for backporting.
Thanks for the patch,
Andre
On Tue, 10 Dec 202
Wilco Dijkstra writes:
> Hi Richard,
>
>>> A common case is a constant string which is compared against some
>>> argument. Most string functions work on 8 or 16-byte quantities. If we
>>> ensure the whole array fits in one aligned load, we save time in the
>>> string function.
>>>
>>> Runtime data
Hi All,
This was yet another regression that I caused, which was backported and so
I am rather anxious to fix it promptly.
The modifications that I made to gfc_get_array_span caused
unlimited polymorphic array components to be missed, when contained in a
dummy. Instead, the dummy was taken to be
Hi Jerry,
patch looks good. Ok for mainline and backport after grace period.
Thanks for the patch,
Andre
On Mon, 9 Dec 2024 20:31:08 -0800
Jerry D wrote:
> Hi all,
>
> The attached patch fixes this bug by checking for the case of a short
> READ that should be padded with blanks and if
Hi All,
This was a rather vexatious bug to track down and squash. I was led astray
by the appearance of the bug in the tests for the implementation of
intrinsic transformational functions with class arguments. It turns out to
be an incipient bug in the handling of character(*) array associate name
> On 5 Dec 2024, at 10:25 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Soumya AR writes:
>> NBSL, BSL1N, and BSL2N are bit-select intructions on SVE2 with certain
>> operands
>> inverted. These can be extended to work with Neon modes.
>>
Hi Jerry,
This looks okay to me, but maybe leave 48 hours for others to comment?
Best,
FX
This reverts r15-6060-ge4a0157c2397c9 so that __is_bitwise_relocatable
depends only on is_trivial. To avoid the deprecation warnings for C++26,
use the __is_trivial built-in directly instead of std::is_trivial.
We need to be sure that the type is trivially copyable, not just
trivially constructibl
On Tue, 10 Dec 2024 at 10:48, Giuseppe D'Angelo
wrote:
>
> Hi,
>
> On 10/12/2024 10:56, Jonathan Wakely wrote:
> > We need this to depend on is_trivially_copyable too, so we can use memcpy.
> >
> > I'm testing a fix now to fix bootstrap.
>
> There's a broader question I think, which is how much we
On 09/12/2024 21:11, Christophe Lyon wrote:
In this PR, we have to handle a case where MVE predicates are supplied
as a const_int, where individual predicates have illegal boolean
values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE,
fix the constant (any non-zero value is conver
On Tue, 10 Dec 2024, Martin Uecker wrote:
>
> The second part now only contains the changes for array size.
>
> I added back a special case for this instead of having the
> 'ignore_size' flag (which I would nevertheless assume might be
> needed in the future when matching pointer types).
I see
Update Sifive Xsfvqmacc and Xsfvfnrclip extension's testcases.
Co-Authored by: Jiawei Chen
Co-Authored by: Yulong Shi
Co-Authored by: Yixuan Chen
gcc/ChangeLog:
* config/riscv/vector.md: Add sf_vqmacc and sf_vfnrclip to the
has_vtype_op,ta,ma.
gcc/testsuite/ChangeLog:
* gcc
On Tue, 10 Dec 2024, Martin Uecker wrote:
>
> As requested, I split up into one part for the TYPE_MODE and
> another one for the array size to help with git bisecting. This
> is the first part.
>
>
> Bootstrapped and regression tested on x86_64.
OK.
Thanks,
Richard.
>
>
> Allow the TYPE
On 12/10/24 12:48 PM, Dimitar Dimitrov wrote:
On Mon, Dec 09, 2024 at 06:05:10PM +0100, Robin Dapp wrote:
+/* { dg-additional-options "-mabi=lp64d" { target { rv64 } } } */
+/* { dg-additional-options "-mabi=ilp32d" { target { rv32 } } } */
Wouldn't skipping those tests also be reasonable?
This is essentially the same as the i386-pc-gnu section, the differences
are the same as between freebsd i386 and freebsd x86_64.
gcc/ada/ChangeLog:
* Makefile.rtl: Add x86_64-pc-gnu section.
Signed-off-by: Samuel Thibault
---
gcc/ada/Makefile.rtl | 36 +
Hello,
Ping on this?
Samuel
Samuel Thibault, le mar. 12 nov. 2024 21:45:19 +0100, a ecrit:
> Difference with v2: dropped the ChangeLog changes
>
> Samuel Thibault (3):
> ada: Factorize bsd signal definitions
> ada: Fix GNU/Hurd priority range
> ada: Add GNU/Hurd x86_64 support
>
> gcc/a
On 12/10/24 6:05 PM, David Malcolm wrote:
On Sat, 2024-12-07 at 10:19 -0500, Jason Merrill wrote:
On 11/15/24 8:02 PM, David Malcolm wrote:
This patch is a followup to:
"c++: use diagnostic nesting [PR116253]"
Following Sy Brand's UX suggestions in P2429R0 for example 1, this
patch
tweaks
> This is essentially the same as the i386-pc-gnu section, the differences
> are the same as between freebsd i386 and freebsd x86_64.
>
> gcc/ada/ChangeLog:
>
> * Makefile.rtl: Add x86_64-pc-gnu section.
It is outdated and probably needs to have $(TRASYM_DWARF_UNIX_PAIRS) and the
associ
68 matches
Mail list logo
