Martin Jambor writes:
> Hi,
>
> When GCC is built with clang, it emits warnings that several member
> functions of various ranger classes override a virtual function of an
> ancestor but are not marked with the override keyword. After
> inspecting the cases, I found that all these classes had ot
On Sat, Jun 28, 2025 at 12:03 PM Jeff Law wrote:
>
>
>
> On 6/27/25 5:34 PM, H.J. Lu wrote:
> > Add "void debug (tree)" to support:
> >
> > (gdb) call debug (expr)
> >> type > size
> > unit-size
> > user align:256 warn_if_not_align:0 symtab:0 alias-set -1
>
On 6/27/25 5:34 PM, H.J. Lu wrote:
Add "void debug (tree)" to support:
(gdb) call debug (expr)
unit-size
user align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe99cebd0
fields
XF x.c:2:15
size
unit-
HI,
I have tested your patch on exchange2 and noticed multiple problems:
1) with LTO the translation from dwarf names to symbol names is disabled
since we free lang data sooner. I moved the offline pass upstream which
however also may make us miss clones intorduced betwen free lang dat
Since a backend may ignore user type alignment for arguments passed on
stack, update alignment for arguments passed on stack when copying MEM's
memory attributes.
gcc/
PR target/120839
* emit-rtl.cc (set_mem_attrs): Update alignment for argument on
stack.
gcc/testsuite/
PR target/120839
* gcc.t
Hi Jakub,
> signbit is documented to be a macro, so please don't declare
> int signbit (double);
> function in the testcase and instead of signbit use __builtin_signbit.
This is indeed my negligence. Done.
If everything looks good, could you please help me merge this patch? Thank you!
Yuao
0
On Sat, Jun 28, 2025 at 12:24 AM Cui, Lili wrote:
>
>
>
> > -Original Message-
> > From: Cui, Lili
> > Sent: Friday, June 27, 2025 5:04 PM
> > To: H.J. Lu
> > Cc: ubiz...@gmail.com; gcc-patches@gcc.gnu.org; Liu, Hongtao
> > ; richard.guent...@gmail.com; Michael Matz
> > ; Sam James ; kenj
The CI reported 2 failures but seems unrelated and passed locally, thus will
commit this before the end of next Monday(6/30) if no more concerns.
> FAIL: gcc.dg/vect/pr115669.c -flto -ffat-lto-objects (test for excess errors)
Executing on host:
/home/lipan/gnu-toolchain/build/build-riscv64-unkn
On 6/25/25 10:22 AM, Iain Sandoe wrote:
On 25 Jun 2025, at 15:17, Martin Jambor wrote:
Hi,
when building GCC with clang, it warns that the private member suffix
in class cp_coroutine_transform (defined in gcc/cp/coroutines.h) is
not used which indeed looks like it is the case. This patch t
Add "void debug (tree)" to support:
(gdb) call debug (expr)
unit-size
user align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe99cebd0
fields
XF x.c:2:15
size
unit-size
align:128 warn_if_not_align:0
On 6/27/25 5:58 PM, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled since the introduction of UBSan,
cp_build_array_ref COND_EXPR handling replaces
(cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there are
SAVE_EXPRs inside of idx, they will be evaluated just in one of the
On 6/27/25 3:28 AM, Nathaniel Shead wrote:
On Wed, Jun 25, 2025 at 11:52:14AM -0400, Jason Merrill wrote:
On 6/25/25 9:02 AM, Nathaniel Shead wrote:
On Tue, Jun 24, 2025 at 12:10:09PM -0400, Patrick Palka wrote:
On Tue, 24 Jun 2025, Jason Merrill wrote:
On 6/23/25 5:41 PM, Nathaniel Shead wr
On 6/26/25 4:12 PM, Marek Polacek wrote:
On Wed, Jun 25, 2025 at 03:13:25PM -0400, Jason Merrill wrote:
On 6/25/25 1:28 PM, Marek Polacek wrote:
@@ -24604,7 +24604,7 @@ resolve_nondeduced_context (tree orig_expr,
tsubst_flags_t complain)
}
if (good == 1)
{
- ma
Hi!
The following testcase is miscompiled since the introduction of UBSan,
cp_build_array_ref COND_EXPR handling replaces
(cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there are
SAVE_EXPRs inside of idx, they will be evaluated just in one of the
branches and the other uses uninitialized
Hi!
My changes for "Module Declarations Shouldn’t be Macros" paper broke
the following testcase. The backup handling intentionally tries to
drop CPP_PRAGMA_EOL token if things go wrong, which is desirable for the
case where we haven't committed to the module preprocessing directive
(i.e. changed
On Fri, Jun 27, 2025 at 05:17:55PM -0400, Jason Merrill wrote:
> I've pushed those changes.
Great.
> > /* For a non-pointer simple base reference, express it as a
> > COMPONENT_REF
> >without taking its address (and so causing lambda capture, 91933).
> > */
> > - if (code == PLUS_
On 6/27/25 5:03 AM, Nathaniel Shead wrote:
On Wed, Jun 25, 2025 at 01:05:39PM -0400, Jason Merrill wrote:
On 5/21/25 10:14 PM, Nathaniel Shead wrote:
This patch isn't currently necessary with how I've currently done the
follow-up patches, but is needed for avoiding any potential issues in
the f
On 6/27/25 5:17 PM, Jason Merrill wrote:
On 6/26/25 1:30 PM, Jakub Jelinek wrote:
On Thu, Jun 26, 2025 at 01:33:08PM +0200, Jakub Jelinek wrote:
I get some regressions (which I didn't get with the earlier patch, but
it isn't obvious by what it has been caused):
It ICEs were caused by the cano
On 6/26/25 1:30 PM, Jakub Jelinek wrote:
On Thu, Jun 26, 2025 at 01:33:08PM +0200, Jakub Jelinek wrote:
I get some regressions (which I didn't get with the earlier patch, but
it isn't obvious by what it has been caused):
It ICEs were caused by the canonicalize_obj_off change and indeed
The IC
The cherry-picked patch fixes sanitizer builds with musl libc. Which
should fix both ppc and riscv issues using the sanitizer with musl.
Pushed to the trunk.
Jeff
commit 5111ea055f5699ad47605890fb45af5c3db1de4f
Author: Jeff Law
Date: Fri Jun 27 15:11:41 2025 -0600
[sanitizer_common]
Am 27.06.25 um 22:57 schrieb Jerry D:
On 6/27/25 1:48 PM, Harald Anlauf wrote:
Dear all,
my original patch caused a regression on previously working code where
an imported interface was *not* renamed-on-use, as the related new logic
did not expect a local_name to be an empty string.
Funnily, t
On 6/27/25 1:48 PM, Harald Anlauf wrote:
Dear all,
my original patch caused a regression on previously working code where
an imported interface was *not* renamed-on-use, as the related new logic
did not expect a local_name to be an empty string.
Funnily, there was no previously existing test in
Dear all,
my original patch caused a regression on previously working code where
an imported interface was *not* renamed-on-use, as the related new logic
did not expect a local_name to be an empty string.
Funnily, there was no previously existing test in the testsuite...
The attached fixes this
On 6/27/25 12:30 PM, Andrew Pinski wrote:
On Fri, Jun 27, 2025, 11:06 AM Raphael Moreira Zinsly
mailto:rzin...@ventanamicro.com>> wrote:
Hi all,
For targets that have expensive shifts this may not get a better
sequence right now, specially for AVR and MSP430 according to
On Fri, Jun 27, 2025 at 01:38:51PM +, Qing Zhao wrote:
> The good news is: With the above simple heuristic and a simple back tracing
> of the CFG, all the
> current testing cases for the following PRs passed without any issue:
>
> PR109071
> PR88771
> PR85788
> PR108770
> PR106762
> PR11
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
With Jakub's constexpr virtual base patch,
23_containers/vector/bool/cmp_c++20.cc failed the assert I add to
fixed_type_or_null, meaning that it returned the wrong value. Let's fix the
result as well as adding the assert, and fix cp_parser_
On Fri, Jun 27, 2025, 11:06 AM Raphael Moreira Zinsly <
rzin...@ventanamicro.com> wrote:
> Hi all,
>
> For targets that have expensive shifts this may not get a better
> sequence right now, specially for AVR and MSP430 according to
> our tests.
> Before I start looking for a fix on those targets I
On Fri, Jun 27, 2025, 11:06 AM Raphael Moreira Zinsly <
rzin...@ventanamicro.com> wrote:
> Hi all,
>
> For targets that have expensive shifts this may not get a better
> sequence right now, specially for AVR and MSP430 according to
> our tests.
> Before I start looking for a fix on those targets I
s390 missed constant vector permutation cases based on the vector pack
instruction or changing the size of the vector elements during vector
merge. This enables some more patterns that do not need to load a
constant vector for permutation.
Bootstrapped and regtested on s390. Okay for trunk?
gcc
Hi all,
For targets that have expensive shifts this may not get a better
sequence right now, specially for AVR and MSP430 according to
our tests.
Before I start looking for a fix on those targets I want to know
if someone has any advise or other concerns with this transformation.
Thanks,
-- >8
On 2025-06-27 08:39, Siddhesh Poyarekar wrote:
MEM_REF cast of a subobject to its containing object has negative
offsets, which objsz sees as an invalid access. Support this use case
by peeking into the structure to validate that the containing object
indeed contains a type of the subobject at t
Hi!
On Wed, Jun 25, 2025 at 02:50:14PM -0400, Michael Meissner wrote:
> This is patch #1 of 3 that adds the support that can be used in developing GCC
> support for potential future PowerPC processors. With all 3 patches, the
> tuning
> for the 'future' processor is the same as power10 and power
On Fri, 27 Jun 2025, Richard Biener wrote:
> > I think such a warning should be based on an attribute on the time_t type
> > that means "warn for implicit truncation of this type" (I'm less clear on
> > why warnings for implicit widening conversions *to* time_t are supposed to
> > be useful), r
On Fri, Jun 27, 2025 at 08:11:29AM +0200, Uros Bizjak wrote:
> On Fri, Jun 27, 2025 at 7:27 AM Andi Kleen wrote:
> >
> > Uros Bizjak writes:
> >
> > > Introduce crc_revsi4 expanders to generate CRC32 instruction when
> > > using
> > > __builtin_rev_crc32_data* builtins with 0x1EDC6F41 poylnomial
> -Original Message-
> From: Cui, Lili
> Sent: Friday, June 27, 2025 5:04 PM
> To: H.J. Lu
> Cc: ubiz...@gmail.com; gcc-patches@gcc.gnu.org; Liu, Hongtao
> ; richard.guent...@gmail.com; Michael Matz
> ; Sam James ; kenjin4...@gmail.com
> Subject: RE: [PATCH V3] x86: Enable separate shrin
On Fri, Jun 27, 2025 at 03:38:32PM +, Yuao Ma wrote:
> Hi Jakub,
>
> > Please don't include math.h here.
>
> Done.
>
> > And instead of this line use __builtin_acospi (0.5).
> > and, in dejagnu for runtime tests we prefer __builtin_abort on failure, so
>
> Done.
Oh, one more thing.
signbit
Hi Jakub,
> Please don't include math.h here.
Done.
> And instead of this line use __builtin_acospi (0.5).
> and, in dejagnu for runtime tests we prefer __builtin_abort on failure, so
Done.
Yuao
0001-gcc-middle-end-opt-for-trigonometric-pi-based-functi.patch
Description: 0001-gcc-middle-en
This patch adjust all internal std::format call inside of __formatter_chrono,
to use runtime format string and thus avoid compile time checking of validity
of the format string. Majority of cases are covered by calling newly introduced
_S_empty_fs() function that returns __Runtime_format_string con
On Fri, Jun 27, 2025 at 03:04:35PM +, Yuao Ma wrote:
> > I think the __builtin_constant_p(acospi(0.5)) approach is usable, but would
> > be much better done on the lib/target-supports.exp side.
> > So, have foldable_pi_based_trigonometry effective target, which would test
> > if __builtin_const
This patch lifts locale initialization from locale-specific handling methods
into _M_format_to function, and pass the locale by const reference.
To avoid uncessary computation of locale::classic(), we use _Optional_locale,
and emplace __fc.locale() into it only for localized formatting
(_M_spec._M
On Fri, 27 Jun 2025 at 15:37, Patrick Palka wrote:
>
> On Fri, 27 Jun 2025, Jonathan Wakely wrote:
>
> > On 27/06/25 14:53 +0100, Jonathan Wakely wrote:
> > > On 26/06/25 23:12 -0400, Patrick Palka wrote:
> > > > On Thu, 26 Jun 2025, Patrick Palka wrote:
> > > >
> > > > > PR libstdc++/1007
Hi Jakub,
> I think the __builtin_constant_p(acospi(0.5)) approach is usable, but would
> be much better done on the lib/target-supports.exp side.
> So, have foldable_pi_based_trigonometry effective target, which would test
> if __builtin_constant_p(acospi(0.5)) is 1.
Thanks again for your helpfu
On Fri, 27 Jun 2025 at 15:26, Patrick Palka wrote:
>
> On Fri, 27 Jun 2025, Jonathan Wakely wrote:
>
> > On 26/06/25 22:25 -0400, Patrick Palka wrote:
> > > PR libstdc++/100795
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > > * include/bits/ranges_algo.h (__detail::__find_if_not_n): New,
>
The r16-1709-g4b3cefed1a08344495fedec4982d85168bd8173f caused `-Woverflow`
in empty_spec.cc file. This warning is not cause by any issue in shipping
code, and results in taking to much shortcut when implementing a test-only
custom representation type Rep, where long was always used to store a value
From: Pan Li
Add asm dump check test for vec_duplicate + vssubu.vv combine to
vssubu.vx, with the GR2VR cost is 0, 1 and 2.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-4-u16.c: Add asm check
for vssubu.vx combine.
* gcc.target/riscv/rvv/autovec/vx_vf
On Fri, 27 Jun 2025, Jonathan Wakely wrote:
> On 27/06/25 14:53 +0100, Jonathan Wakely wrote:
> > On 26/06/25 23:12 -0400, Patrick Palka wrote:
> > > On Thu, 26 Jun 2025, Patrick Palka wrote:
> > >
> > > > PR libstdc++/100795
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > >
On Fri, 27 Jun 2025, Jonathan Wakely wrote:
> On 26/06/25 22:25 -0400, Patrick Palka wrote:
> > PR libstdc++/100795
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/ranges_algo.h (__detail::__find_if_not_n): New,
> > based on the stl_algo.h implementation.
> > (__detail::__
On 6/27/25 7:59 AM, Oleg Endo wrote:
On Fri, 2025-06-27 at 10:51 -0300, Raphael Moreira Zinsly wrote:
A right shift of 31 will become 0 or 1, this can be checked for
treg_set_expr_not_const01 to avoid matching addc_t_r as this
can expand to a 3 insn sequence instead.
This improves tests 023
On Fri, 27 Jun 2025 at 15:16, Jonathan Wakely wrote:
>
> On Fri, 27 Jun 2025 at 15:15, Patrick Palka wrote:
> >
> > On Fri, 27 Jun 2025, Jonathan Wakely wrote:
> >
> > > On 26/06/25 22:25 -0400, Patrick Palka wrote:
> > > > PR libstdc++/100795
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
>
From: Pan Li
Add asm dump check and run test for vec_duplicate + vssubu.vv
combine to vssubu.vx, with the GR2VR cost is 0, 2 and 15.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-u16.c: Add asm check.
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-u32.c: Ditto.
On Fri, 27 Jun 2025 at 15:15, Patrick Palka wrote:
>
> On Fri, 27 Jun 2025, Jonathan Wakely wrote:
>
> > On 26/06/25 22:25 -0400, Patrick Palka wrote:
> > > PR libstdc++/100795
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > > * include/bits/ranges_algo.h (__detail::__move_merge): New,
> > >
On Fri, 27 Jun 2025, Jonathan Wakely wrote:
> On 26/06/25 22:25 -0400, Patrick Palka wrote:
> > PR libstdc++/100795
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/ranges_algo.h (__detail::__move_merge): New,
> > based on the stl_algo.h implementation.
> > (__detail::__mer
From: Pan Li
The cost model change will make the default cost of vx to 2, thus
reconcile the asm check for this change.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/sat/vec_sat_u_sub_trunc-1-u16.c:
Update the asm check due to cost model change.
* gcc.target/ri
Adjusted backends.html for avr.
Applied as obvious.
Johann
--
commit 3ba9c3647d9dee45c5afe90ccc21c3b5753ca8aa
backends.html (avr): Uses LRA per default.
https:/gcc.gnu.org/r16-1733 enabled LRA per default on AVR.
diff --git a/htdocs/backends.html b/htdocs/backends.html
index 2a63f91b..52f897
On 26/06/25 22:25 -0400, Patrick Palka wrote:
PR libstdc++/100795
OK for trunk (the FIXME can stay for now and be dealt with later).
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__sample_fn::operator()):
Reimplement the forward_iterator branch directly.
From: Pan Li
This patch would like to combine the vec_duplicate + vssubu.vv to the
vssubu.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR. Then the late-combine will
take action if the cost of GR2VR is zero, and reject the combination
if
It is better to leave a record in CI system, I will send v3 to trigger another
CI and see, will commit it if CI is OK.
Pan
-Original Message-
From: Robin Dapp
Sent: Friday, June 27, 2025 9:53 PM
To: Li, Pan2 ; Robin Dapp ;
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@g
On 27/06/25 14:53 +0100, Jonathan Wakely wrote:
On 26/06/25 23:12 -0400, Patrick Palka wrote:
On Thu, 26 Jun 2025, Patrick Palka wrote:
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__sample_fn::operator()):
Reimplement the forward_iterator
From: Pan Li
This patch would like to introduce the combine of vec_dup + vssubu.vv
into vssubu.vx on the cost value of GR2VR. The late-combine will take
place if the cost of GR2VR is zero, or reject the combine if non-zero
like 1, 2, 15 in test. There will be two cases for the combine:
Case 0:
Is there anyway we can retrigger the test somewhere ? If no I can send a v3
series with the commit reordered and see.
I don't think there's a way other than re-submitting. But if you're sure you
tested properly and the CI is mistaken we can go ahead. I just wanted to make
sure as with the s
On Fri, 2025-06-27 at 10:51 -0300, Raphael Moreira Zinsly wrote:
> A right shift of 31 will become 0 or 1, this can be checked for
> treg_set_expr_not_const01 to avoid matching addc_t_r as this
> can expand to a 3 insn sequence instead.
> This improves tests 023 to 026 from gcc.target/sh/pr54236-
On 26/06/25 22:25 -0400, Patrick Palka wrote:
PR libstdc++/100795
OK for trunk.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (shuffle_fn::operator()):
Reimplement directly.
* testsuite/25_algorithms/shuffle/constrained.cc (test02):
---
libstdc++-v3/in
OK.
Hmm, I'm still seeing test failures in the CI. Could you check if those are
valid?
--
Regards
Robin
A right shift of 31 will become 0 or 1, this can be checked for
treg_set_expr_not_const01 to avoid matching addc_t_r as this
can expand to a 3 insn sequence instead.
This improves tests 023 to 026 from gcc.target/sh/pr54236-2.c, e.g.:
test_023:
shllr5
mov #0,r1
mov r4,r0
rts
addcr1,
On 26/06/25 23:12 -0400, Patrick Palka wrote:
On Thu, 26 Jun 2025, Patrick Palka wrote:
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__sample_fn::operator()):
Reimplement the forward_iterator branch directly.
* testsuite/25_algorith
> Hi Honza,
> > So merging the profiles will also lead to inconsistencies making the
> > .part variant to seem more hot than it is...
>
> I am looking into this and will post the patch as a follow up patch.
Thanks. Note that now with merging being done recursively to inline
instances while offli
I found that isn't included in this patch after I committed that...I try to
fix that soon but CI caught me :P
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c67f7f8d4c8aadbe8efd733c29d13bfcbb0f50f
On Thu, Jun 26, 2025 at 10:05 PM Robin Dapp wrote:
> Hi Kito,
>
> > This patch adds a comment to t
On Fri, 27 Jun 2025, Richard Biener wrote:
> > I am testing partial fixes for these issues.
>
> Can you check again after r16-1731-g08bdb6b4a32f1f?
Certainly. There's no more fmaddsub-related testsuite failures, and only
three tests need adjustment on x86.
* gcc.target/i386/pr116979.c
Here
I take this patch back. It seems to be incomplete.
- Andre
On Fri, 27 Jun 2025 14:45:36 +0200
Andre Vehreschild wrote:
> Hi all,
>
> this patch fixes a reject valid when the coranks of two operands do not match
> and no coindex is given. I.e. when only an implicit this_image co-ref is used.
>
Hi,
A status update on this patch: (Actually a good news!)
> On Jun 10, 2025, at 11:32, Qing Zhao wrote:
>
>
>
>>>
>>> It's difficult to do any meaningful pruning I think. Consider
>>>
>>> if (i == -1)
>>> tem = a[i];
>>>
>>> when we transform this to
>>>
>>> if (i == -1)
>>> t
Hi,
>
> We can look into this. We do compare manually the IR dumps from both and it
> is not ideal.
> What we should do is an additional (optional) pass that runs after
> auto-profile to compare the annotations
> using the profile-use. We will have to filter out any functions/path that
> runs
On 26/06/25 22:25 -0400, Patrick Palka wrote:
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__introselect): New,
based on the stl_algo.h implementation.
(nth_element_fn::operator()): Reimplement in terms of the above.
On 26/06/25 22:25 -0400, Patrick Palka wrote:
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__find_if_not_n): New,
based on the stl_algo.h implementation.
(__detail::__stable_partition_adaptive): Likewise.
(__stable_p
On 26/06/25 22:25 -0400, Patrick Palka wrote:
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__find_if_not_n): New,
based on the stl_algo.h implementation.
(__detail::__stable_partition_adaptive): Likewise.
(__stable_p
Seem the CI only pick up the last commit to run, from the Apply Status of
https://github.com/ewlu/gcc-precommit-ci/issues/3576#issuecomment-3012381157.
Is there anyway we can retrigger the test somewhere ? If no I can send a v3
series with the commit reordered and see.
Pan
-Original Messag
On 6/27/25 7:08 AM, Georg-Johann Lay wrote:
This turns on -mlra per default on avr.
Ok for trunk?
Yes, definitely. The more soak time it gets the better IMHO.
jeff
On 26/06/25 22:25 -0400, Patrick Palka wrote:
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__move_merge): New,
based on the stl_algo.h implementation.
(__detail::__merge_sort_loop): Likewise.
(__detail::__chunk_inser
The standard does not currently specify how the precision value
is interpreted if specify, only prohibit it from being used for
formatting any other object than durations with floating point types.
This patch interprets user-specified duration value as follows:
* if spec is empty for floating-poi
This turns on -mlra per default on avr.
Ok for trunk?
Johann
--
AVR: target/113934 - Use LRA per default.
Now that the patches for PR120424 are upstream, the last known bug
associated with avr+lra has been fixed: PR118591. So we can pull the
switch that turns on LRA per default.
This patch
Hi,
Changes from v1:
- Add gather_scatter argument to support_vector_misalignment.
- Don't rely on DR_BASE_ALIGNMENT.
- Add IFN helpers and use them.
- Add gather/scatter helper macros.
- Clarify is_packed handling in docs.
This patch adds simple misalignment checks for gather/scatter
operations
On 5/5/25 11:56 PM, Bernhard Reutner-Fischer wrote:
On 5 May 2025 20:42:34 CEST, Jeff Law wrote:
diff --git a/gcc/testsuite/gcc.target/riscv/pr119971.c
b/gcc/testsuite/gcc.target/riscv/pr119971.c
new file mode 100644
index 000..c3f23b05ec3
--- /dev/null
+++ b/gcc/testsuite/gcc.targe
Hi all,
this patch fixes a reject valid when the coranks of two operands do not match
and no coindex is given. I.e. when only an implicit this_image co-ref is used.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot d
On 2025-06-27 08:05, Jakub Jelinek wrote:
On Fri, Jun 27, 2025 at 02:00:26PM +0200, Richard Biener wrote:
+ gcc_assert (RECORD_OR_UNION_TYPE_P (container));
+
+ for (tree t = TYPE_FIELDS (container); t; t = DECL_CHAIN (t))
+{
+ if (TREE_CODE (t) != FIELD_DECL)
+continue;
+
+
MEM_REF cast of a subobject to its containing object has negative
offsets, which objsz sees as an invalid access. Support this use case
by peeking into the structure to validate that the containing object
indeed contains a type of the subobject at that offset and if present,
adjust the wholesize f
On 26/06/25 22:25 -0400, Patrick Palka wrote:
As with the previous patch, this patch reimplements ranges::inplace_merge
directly instead of incorrectly forwarding to std::inplace_merge. In
addition to the compatibility changes listed in the previous patch we
also:
- explicitly cast the differe
On 26/06/25 22:25 -0400, Patrick Palka wrote:
As with the previous patch, this patch reimplements ranges::sort
directly instead of incorrectly forwarding to std::sort. In addition to
the compatibility changes listed in the previous patch we also:
- use ranges::iter_swap instead of std::iter_sw
On 26/06/25 22:25 -0400, Patrick Palka wrote:
ranges::push_heap, ranges::pop_heap, ranges::make_heap and
ranges::sort_heap are currently defined in terms of the corresponding
STL-style algorithms, but this is incorrect because the STL-style
algorithms rely on the legacy iterator system, and so mi
Le 23/06/2025 à 09:34, Richard Biener a écrit :
On Sun, Jun 22, 2025 at 10:23 PM Mikael Morin wrote:
From: Mikael Morin
See the description in the ChangeLog entry below.
The testcases are best effort; for some operators the fortran frontend
generates a temporary variable, so the simplificat
On 27/06/25 13:01 +0200, Tomasz Kamiński wrote:
The r16-1709-g4b3cefed1a08344495fedec4982d85168bd8173f caused `-Woverflow`
in empty_spec.cc file. This warning is not cause by any issue in shipping
code, and results in taking to much shorcut when implementing a test-only
custom representation type
On Fri, Jun 27, 2025 at 02:00:26PM +0200, Richard Biener wrote:
> > + gcc_assert (RECORD_OR_UNION_TYPE_P (container));
> > +
> > + for (tree t = TYPE_FIELDS (container); t; t = DECL_CHAIN (t))
> > +{
> > + if (TREE_CODE (t) != FIELD_DECL)
> > +continue;
> > +
> > + tree byte_off
> Am 27.06.2025 um 13:40 schrieb Siddhesh Poyarekar :
>
> MEM_REF cast of a subobject to its containing object has negative
> offsets, which objsz sees as an invalid access. Support this use case
> by peeking into the structure to validate that the containing object
> indeed contains a type o
On Fri, Jun 27, 2025 at 11:23 AM Jonathan Wakely wrote:
> On Fri, 27 Jun 2025 at 10:10, Tomasz Kaminski wrote:
> >
> >
> >
> > On Fri, Jun 27, 2025 at 10:31 AM Tomasz Kamiński
> wrote:
> >>
> >> This patch adjust all internal std::format call inside of
> __formatter_chrono,
> >> to use runtime
On 2025-06-27 07:40, Siddhesh Poyarekar wrote:
MEM_REF cast of a subobject to its containing object has negative
offsets, which objsz sees as an invalid access. Support this use case
by peeking into the structure to validate that the containing object
indeed contains a type of the subobject at t
MEM_REF cast of a subobject to its containing object has negative
offsets, which objsz sees as an invalid access. Support this use case
by peeking into the structure to validate that the containing object
indeed contains a type of the subobject at that offset and if present,
adjust the wholesize f
On 6/27/25 11:44, Jonathan Wakely wrote:
On Fri, 27 Jun 2025 at 10:39, Tomasz Kaminski wrote:
Also, for single patch (not-patch series), you do not need to have [PATCH 0/N],
simple [PATCH] and then [PATCH v2] also works.
Yeah, sending a 0/N cover letter is only useful to describe what a
Sorry, I'll continue working another day. This commit is
broken; please ignore.
On 6/27/25 13:15, Luc Grosheintz wrote:
libstdc++-v3/ChangeLog:
* include/std/mdspan (default_accessor): New class.
* src/c++23/std.cc.in: Register default_accessor.
* testsuite/23_containers
libstdc++-v3/ChangeLog:
* include/std/mdspan (default_accessor): New class.
* src/c++23/std.cc.in: Register default_accessor.
* testsuite/23_containers/mdspan/accessors/default.cc: New test.
* testsuite/23_containers/mdspan/accessors/default_neg.cc: New test.
Signe
On Fri, Jun 27, 2025 at 1:03 PM Tomasz Kamiński wrote:
> The r16-1709-g4b3cefed1a08344495fedec4982d85168bd8173f caused `-Woverflow`
> in empty_spec.cc file. This warning is not cause by any issue in shipping
> code, and results in taking to much shorcut when implementing a test-only
> custom repr
The r16-1709-g4b3cefed1a08344495fedec4982d85168bd8173f caused `-Woverflow`
in empty_spec.cc file. This warning is not cause by any issue in shipping
code, and results in taking to much shorcut when implementing a test-only
custom representation type Rep, where long was always used to store a value.
On Wed, Jun 25, 2025 at 11:39 AM Richard Biener
wrote:
>
> On Tue, Jun 24, 2025 at 5:25 PM Alexander Monakov wrote:
> >
> > > I'd say we want to fix these kind of things before switching the default.
> > > Can
> > > you file bugreports for the distinct issues you noticed when adjusting the
> >
1 - 100 of 172 matches
Mail list logo
