Hi Yuao,
Yuao Ma wrote:
This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this
patch, we
add intrinsic documentation for the newly added trig functions with
half-revolutions. We also reorder the documentation for `atand` to
place it in
correct alphabetical order.
When I try to
Hi!
My r16-1398 patch broke bootstrap on aarch64-linux and powerpc64le-linux
at least. Fixed with r16-1408.
The following patch just adds testcases with which the bug can be reproduced
also on x86_64-linux where it hasn't been caught by the testsuite (while
there are 2 tests with it, both where c
On Tue, Jun 10, 2025 at 03:03:27PM -0400, Andrew MacLeod wrote:
> Thats perfect, but you arent using the path ranger (thats just threading),so
> that latter bit is not neceesary... it'll never trigger where you are in
> expand.
Ok, here is what I've committed after bootstrap/regtest on x86_64-linu
From: Lili Cui
Hi Uros,
Thank you very much for providing detailed BKM to reproduce Linux kernel boot
failure. My patch and Matz's patch have this problem. We inserted a SUB
between TEST and JLE, and the SUB changes the value of EFlags. The branch JLE
here went wrong, and a null pointer appe
Andrew MacLeod writes:
> There is a bug in irange::set_range_from_bitmask where if the bitmask
> indicated the result is a singleton, it would simply return that
> singleton. It never actually checked to see if that singleton was
> actually contained in the range, in which case it should return
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/x86_64/abi/callabi/leaf-2.c: Adjust the test.
> > * gcc.target/i386/interrupt-16.c: Likewise.
> > * g++.target/i386/shrink_wrap_separate.c: New test.
>
> This one should have .C suffix.
>
Done.
> Some comment fixes/clarif
> Am 11.06.2025 um 00:33 schrieb Jakub Jelinek :
>
> Hi!
>
> Apparently my ranger during expansion patch broke bootstrap on
> aarch64-linux, while building libsupc++, there is endless recursion
> on __builtin_popcountl (x) == 1 expansion.
> The hack to temporarily replace SSA_NAME_VAR of the
This patch to the "experimental-html" diagnostic sink:
* adds use of the PatternFly 3 CSS library (via an optional link
in the generated html to a copy in a CDN)
* uses PatternFly's "alert" pattern to show severities for diagnostics,
properly nesting "note" diagnostics for diagnostic groups.
Spotted whilst implementing nesting support in the
experimental-html diagnostic sink.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1403-gb619b4d7e7a507.
gcc/ChangeLog:
* gimple-ssa-warn-access.cc
(pass_waccess::maybe_check_dealloc_call): Ad
I've been seeing issues in the experimental-html sink where the nesting
of tags goes wrong.
The two issues I've seen are:
* the pp_token_list from the diagnostic message that reaches the
html_token_printer doesn't always have matching pairs of begin/end
tokens (PR other/120610)
* a bug in diag
Various places use
xp.add_text (pp_formatted_text (&pp))
Add a helper function for this.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1405-g896edb1d0ae90f.
gcc/ChangeLog:
* diagnostic-path-output.cc: Use xml::printe
On Tue, 10 Jun 2025, Martin Uecker wrote:
> Here I simply override the type with the one with the prototype.
> This is not a perfect replacement for forming the composite type,
> but I assume this does not matter for any existing code. But if
> you think it is better to keep forming the composite
On Tue, 10 Jun 2025, Martin Uecker wrote:
> When looking for the casue of PR120510 I noticed there
> is some minor issues that make the code harder to understand
> which are left over from previous changes.
>
> Bootstrapped and regression tested for x86_64.
>
>
> c: clean up some functions
Support the btf_decl_tag and btf_type_tag attributes in BTF by creating
and emitting BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records,
respectively, for them.
Some care is required when -gprune-btf is in effect to avoid emitting
decl or type tags for declarations or types which have been pruned and
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
On Tue, 10 Jun 2025, Martin Uecker wrote:
> Small fix.
>
> Bootstrapped and regression tested for x86_64.
>
> Martin
>
> c: fix ICE for invalid code in generic selection [PR120303]
>
> Fix an error recovery ICE that occurs when a type name
> can not be parsed correctly in the c
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
Joseph,
this fixes the remaining issue related to PR120510. It is
related to this GNU extenions:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Function-Prototypes.html#Function-Prototypes
Here I simply override the type with the one with the prototype.
This is not a perfect replacement for for
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
BTF_KIND_TYPE_TAG records.
The new CTF kinds used to represent these annotations, CTF_K_DECL_T
[v3: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html
Changes v3->v4:
- Only patch 2 (DWARF generation) is changed; update based on Richard's
review comments.
- Fix an issue with generating DWARF for type_tags when a typedef involves
type_tags and the use of the typedef add
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with a simple shared handler for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_tag_attribute): New handler for both new attrib
When looking for the casue of PR120510 I noticed there
is some minor issues that make the code harder to understand
which are left over from previous changes.
Bootstrapped and regression tested for x86_64.
c: clean up some functions in c-typeck.cc
This removes two unnecessary vari
Small fix.
Bootstrapped and regression tested for x86_64.
Martin
c: fix ICE for invalid code in generic selection [PR120303]
Fix an error recovery ICE that occurs when a type name
can not be parsed correctly in the controlling expression
of a generic selection.
gc
Hi!
Apparently my ranger during expansion patch broke bootstrap on
aarch64-linux, while building libsupc++, there is endless recursion
on __builtin_popcountl (x) == 1 expansion.
The hack to temporarily replace SSA_NAME_VAR of the lhs which replaced
the earlier hack to temporarily change the gimple
> Am 10.06.2025 um 22:18 schrieb Andrew MacLeod :
>
>
> I had a question asked of me, and now I'm passing the buck.
>
> extern void *memcpy(void *, const void *, unsigned int);
> extern int memcmp(const void *, const void *, unsigned int);
> typedef unsigned long bits32;
> typedef unsigned ch
On Tue, 13 May 2025, Qing Zhao wrote:
> + /* This attribute cannot be applied to a pointer type whose pointee type
> + is void. */
> + else if (TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE
> +&& TREE_CODE (TREE_TYPE (TREE_TYPE (decl))) == VOID_TYPE)
> +{
> + error_at (DECL_
On 6/10/25 13:35, Edwin Lu wrote:
> The instruction scheduler appears to be speculatively hoisting vsetvl
> insns outside of their basic block without checking for data
> dependencies. This resulted in a situation where the following occurs
>
> vsetvli a5,a1,e32,m1,tu,ma
> vle32.
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sub a1,a1,a5 <-- a1 poten
On Tue, 10 Jun 2025, Marek Polacek wrote:
> +
> +Anonymous structures and unions
> + href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1406.pdf";>N1406
> +4.6
> +
> +
4.6 is probably a reasonable version to list here given that a significant
piece (support for designato
For a non-multilib build, I see following errors.
| FAIL: gcc.target/riscv/rvv/vtype-call-clobbered.c (test for excess errors)
| Excess errors:
| TC-INSTxyz/sysroot/usr/include/gnu/stubs.h:14:11: fatal error:
gnu/stubs-lp64.h: No such file or directory compilation terminated.
The test selects no
On Wed, Jun 04, 2025 at 03:47:31PM +, Alfie Richards wrote:
> Hi,
>
> This fixes the FMV powerpc tests I recently committed, and hopefully makes
> them
> work on a wider range of target configurations.
>
> I plan to commit this on Monday if no one has any objections.
I, the sole maintainer
For final target classes of which the source type is a unique non-
virtual base, we know that the dynamic_cast succeeding is equivalent to
the vptr pointing to the target's vtable. So check this if possible
instead of calling the more expensive `__dynamic_cast` runtime method.
This might be extend
OK.
--
Regards
Robin
I had a question asked of me, and now I'm passing the buck.
extern void *memcpy(void *, const void *, unsigned int);
extern int memcmp(const void *, const void *, unsigned int);
typedef unsigned long bits32;
typedef unsigned char byte;
static const byte orig[10] = {
'J', '2
This patch adds a C11 status table to c-status.html.
I consulted n3220.pdf (M.4) and https://gcc.gnu.org/wiki/C11Status,
and checked that Implemented in Version is correct.
I've added links to proposals where it seemed relevant.
Also add a small note about C17.
W3 validated. Ok?
---
htdocs/gcc-
For a non-multilib build, I see following errors.
| FAIL: gcc.target/riscv/rvv/vtype-call-clobbered.c (test for excess errors)
| Excess errors:
| TC-INSTxyz/sysroot/usr/include/gnu/stubs.h:14:11: fatal error:
gnu/stubs-lp64.h: No such file or directory compilation terminated.
The test selects no
On 6/9/25 23:56, Jan Beulich wrote:
On 06.06.2025 17:28, Sandra Loosemore wrote:
On 6/6/25 00:44, Jan Beulich wrote:
As per documentation, even 4.7 ought to suffice. At least 4.13 objects
to there being nothing ahead of the first comma in @xref{}.
---
The text inserted it merely a guess; I'm op
On 6/10/25 13:52, Jakub Jelinek wrote:
On Tue, Jun 10, 2025 at 10:51:25AM -0400, Andrew MacLeod wrote:
Edge range should be fine, and really that assert doesnt really need to be
there.
Where the issue could arise is in gimple-range-fold.cc in
fold_using_range::range_of_range_op() where we se
Spencer Abson writes:
> On Fri, Jun 06, 2025 at 04:04:18PM +0100, Richard Sandiford wrote:
>> Spencer Abson writes:
>> > Extend the ternary op/UNSPEC_SEL combiner patterns from SVE_FULL_F/
>> > SVE_FULL_F_BF to SVE_F/SVE_F_BF, where the strictness value is
>> > SVE_RELAXED_GP.
>> >
>> > We can on
Spencer Abson writes:
> On Fri, Jun 06, 2025 at 03:52:12PM +0100, Richard Sandiford wrote:
>> Spencer Abson writes:
>> > @@ -8165,20 +8169,25 @@
>> > ;;
>> > ;; For unpacked vectors, it doesn't really matter whether SEL uses the
>> > ;; the container size or the element size. If SEL used the
Spencer Abson writes:
> On Fri, Jun 06, 2025 at 12:46:32PM +0100, Richard Sandiford wrote:
>> Spencer Abson writes:
>> > This patch extends the unpredicated FP division expander to support
>> > partial FP modes. It extends the existing patterns used to implement
>> > UNSPEC_COND_FDIV and it's ap
Spencer Abson writes:
> On Mon, Jun 09, 2025 at 02:48:58PM +0100, Richard Sandiford wrote:
>> Spencer Abson writes:
>> > On Thu, Jun 05, 2025 at 09:24:27PM +0100, Richard Sandiford wrote:
>> >> Spencer Abson writes:
>> >> > diff --git
>> >> > a/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond
On Tue, Jun 10, 2025 at 3:47 AM Richard Biener
wrote:
>
> On Tue, Jun 10, 2025 at 2:02 AM Andrew Pinski wrote:
> >
> > On Mon, Jun 9, 2025 at 2:49 AM Richard Biener
> > wrote:
> > >
> > > On Sun, Jun 8, 2025 at 7:52 PM Andrew Pinski
> > > wrote:
> > > >
> > > > While thinking about how to impl
> Am 10.06.2025 um 19:53 schrieb Jakub Jelinek :
>
> On Tue, Jun 10, 2025 at 10:51:25AM -0400, Andrew MacLeod wrote:
>> Edge range should be fine, and really that assert doesnt really need to be
>> there.
>>
>> Where the issue could arise is in gimple-range-fold.cc in
>> fold_using_range::ran
On Tue, Jun 10, 2025 at 10:51:25AM -0400, Andrew MacLeod wrote:
> Edge range should be fine, and really that assert doesnt really need to be
> there.
>
> Where the issue could arise is in gimple-range-fold.cc in
> fold_using_range::range_of_range_op() where we see something like:
>
> el
simplify_switch_using_ranges has never been converted over properly to
use irange. It still uses get_legacy_range, and as a result, is very
limited in how it processes cases labels. In particular it is unable to
remove cases in the middle which are not possible to call.
This patch rewrites t
There is a bug in irange::set_range_from_bitmask where if the bitmask
indicated the result is a singleton, it would simply return that
singleton. It never actually checked to see if that singleton was
actually contained in the range, in which case it should return UNDEFINED.
I haven't been ab
On Tue, 10 Jun 2025, Gábor Németh wrote:
> A new option is added to warn if floating point literals have non-standard
> suffices (currently Q and W) in pedantic mode. The option is ON by default.
> The negative form `-Wno-non-standard-suffix` is expected to be used typically,
> as is done for GCC
On Tue, 10 Jun 2025, Gábor Németh wrote:
> diff --git a/gcc/testsuite/c-c++-common/pr92826.c
> b/gcc/testsuite/c-c++-common/pr92826.c
> new file mode 100644
> index 000..ea2e20c6331
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/pr92826.c
> @@ -0,0 +1,6 @@
> +/* { dg-options "-pedanti
With improved memset optimizations in std::uninitialized_fill and
std::uninitialized_fill_n (see r15-4473-g3abe751ea86e34), we can make
the non-standard internal helpers __uninitialized_default and
__uninitialized_default_n use those directly instead of using std::fill
and std::fill_n respectively.
These variables could be used by custom definitions of the VERIFY macro
prior to GCC 7.1 but serve no purpose now. They can be removed, along
with the documentation with the historical note.
libstdc++-v3/ChangeLog:
* doc/xml/manual/test.xml: Remove note about unused 'test'
variabl
On Thu, Jun 5, 2025 at 11:50 PM Jan Beulich wrote:
>
> As per documentation, even 4.7 ought to suffice. At least 4.13 objects
> to there being nothing ahead of the first comma in @xref{}.
> ---
> The text inserted it merely a guess; I'm open to better suggestions.
>
> Noticed with gcc15, so may wa
Hello,
On 10/06/2025 16:32, Jonathan Wakely wrote:
Whops, I again addedstd::string to a constexpr test, so this will fail
on the old ABI. Should I change it to e.g.std::vector, or should I keep
it and add a `{ dg-require-effective-target cxx11_abi }` directive?
Would string_view work instead?
This is OK for the trunk.
--
Regards
Robin
Hi Alex,
> It might be nice to at least experiment with supporting DRs with
> different steps as follow-on work. I agree that we should leave it out
> for the first version to keep things simple.
> FWIW, in case it's of interest, I wrote a script to calculate the
> possible combinations of align
> On Jun 10, 2025, at 09:40, Richard Biener wrote:
>
> On Tue, Jun 10, 2025 at 3:37 PM Richard Biener
> wrote:
>>
>> On Mon, Jun 9, 2025 at 8:06 PM Qing Zhao wrote:
>>>
>>>
>>>
On Jun 6, 2025, at 03:31, Richard Biener
wrote:
On Fri, May 30, 2025 at 5:13 PM Qing Zhao
> We could
> have (any:CC (eq:V4BI (reg:V4SI) (reg:V4SI))) or so, or alternatively
> (more intrusive) have (any_eq:CC (reg:V4SI) (reg:V4SI))? That
> would also allow you to have a proper RTL representation rather
> than more and more UNSEPCs.
> >>>
> >>> We do have proper
> On Jun 10, 2025, at 09:37, Richard Biener wrote:
>
> On Mon, Jun 9, 2025 at 8:06 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jun 6, 2025, at 03:31, Richard Biener wrote:
>>>
>>> On Fri, May 30, 2025 at 5:13 PM Qing Zhao wrote:
Hi, Richard,
Really appreciate for your sugge
> Am 10.06.2025 um 15:51 schrieb Tamar Christina :
>
>
>>
>> -Original Message-
>> From: Richard Biener
>> Sent: Tuesday, June 10, 2025 2:12 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
>> nd
>> Subject: RE: [PATCH 1/3]middle-end: support vec_cbran
On 6/10/25 10:07, Jakub Jelinek wrote:
On Tue, Jun 10, 2025 at 09:59:33AM -0400, Andrew MacLeod wrote:
Yes, there are places , particularly fold_using_range in
gimple-range-fold.cc, which expects there to be 2 edges to a GCOND stmt.
it always expects 2 successors. There are not many places
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, June 10, 2025 2:12 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> nd
> Subject: RE: [PATCH 1/3]middle-end: support vec_cbranch_any and
> vec_cbranch_all [PR118974]
>
> On Mon, 9 Jun 2025, Tamar C
On Tue, 10 Jun 2025 at 15:17, Giuseppe D'Angelo
wrote:
>
> Hello,
>
> Thank you for the review.
>
> >> +#ifdef __cpp_lib_optional_range_support // >= C++26
> >> + // Iterator support.
> >> + constexpr iterator begin() noexcept
> >> + {
> >> +return iterator(
> >> + this->_M
On Mon, 9 Jun 2025, 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::it
Hello,
Thank you for the review.
+#ifdef __cpp_lib_optional_range_support // >= C++26
+ // Iterator support.
+ constexpr iterator begin() noexcept
+ {
+ return iterator(
+ this->_M_is_engaged() ? std::__addressof(this->_M_get()) : nullptr
This can use std::address
Tamar Christina writes:
>> > However because insn 35 only cares about 0 or !0 the shape doesn't matter.
>> > So insn 34 will be eliminated by combine.
>> >
>> > This leaves insn and 31 and 35. Essentially only the compare + branch,
>> > directly on the vector elements, which is what vec_cbranch i
On Tue, Jun 10, 2025 at 09:59:33AM -0400, Andrew MacLeod wrote:
> Yes, there are places , particularly fold_using_range in
> gimple-range-fold.cc, which expects there to be 2 edges to a GCOND stmt.
> it always expects 2 successors. There are not many places like that, many
> simply look at the
On 6/10/25 07:10, Jakub Jelinek wrote:
On Tue, Jun 10, 2025 at 12:55:39PM +0200, Richard Biener wrote:
Yes, it must (but we expand those separately, so we could tear down
ranger then).
So apart from ICEing I wonder how ranger (and it's cache) deals with
basic blocks being added, edges vanishi
Hi, Kees,
I will study this testing case to see what is missing there. And update if I
found anything.
thanks.
Qing
> On Jun 5, 2025, at 19:49, Kees Cook wrote:
>
> On Thu, Jun 05, 2025 at 03:52:21PM -0700, Kees Cook wrote:
>> On Mon, May 19, 2025 at 11:23:34AM -0700, Kees Cook wrote:
>>> On
On Tue, Jun 10, 2025 at 3:37 PM Richard Biener
wrote:
>
> On Mon, Jun 9, 2025 at 8:06 PM Qing Zhao wrote:
> >
> >
> >
> > > On Jun 6, 2025, at 03:31, Richard Biener
> > > wrote:
> > >
> > > On Fri, May 30, 2025 at 5:13 PM Qing Zhao wrote:
> > >>
> > >> Hi, Richard,
> > >>
> > >> Really appreci
On Mon, Jun 9, 2025 at 8:06 PM Qing Zhao wrote:
>
>
>
> > On Jun 6, 2025, at 03:31, Richard Biener wrote:
> >
> > On Fri, May 30, 2025 at 5:13 PM Qing Zhao wrote:
> >>
> >> Hi, Richard,
> >>
> >> Really appreciate for your suggestions.
> >>
> >>> On May 30, 2025, at 05:22, Richard Biener
> >>>
On 6/10/25 06:55, Richard Biener wrote:
On Mon, 9 Jun 2025, Jakub Jelinek wrote:
On Sun, Jun 08, 2025 at 10:49:44AM +0200, Richard Biener wrote:
I'm also a bit nervous about this given during RTL expansion the IL is
neither fully GIMPLE nor fully RTL. Given we do not perform many
range quer
On 6/10/25 08:21, Richard Biener wrote:
On Tue, 10 Jun 2025, Jakub Jelinek wrote:
On Tue, Jun 10, 2025 at 01:05:51PM +0200, Richard Biener wrote:
With your experiment of computing ranges for everything we're good
from the ICE point-of-view. I think there's nothing we can do to
reassure us o
On Mon, 9 Jun 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, June 9, 2025 10:30 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> > nd
> > Subject: Re: [PATCH 1/3]middle-end: support vec_cbranch_any and
> >
On Mon, Jun 9, 2025 at 4:07 PM Jonathan Wakely wrote:
> From: Yihan Wang
>
> Implement LWG3528 to make std::make_from_tuple SFINAE friendly.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/tuple (__can_make_from_tuple): New variable
> template.
> (__make_from_tuple_impl): A
On Tue, 10 Jun 2025, Jakub Jelinek wrote:
> On Tue, Jun 10, 2025 at 01:05:51PM +0200, Richard Biener wrote:
> > With your experiment of computing ranges for everything we're good
> > from the ICE point-of-view. I think there's nothing we can do to
> > reassure us of correctness, so I'd take Andre
On 10/06/25 09:18 +0200, Giuseppe D'Angelo wrote:
Hello,
The attached patch implements C++26's range support for std::optional.
It's also available on Forge here:
https://forge.sourceware.org/gcc/gcc-TEST/pulls/54
It's mostly straightforward, but I had to lift format_kind out of
(together w
On Tue, Jun 10, 2025 at 01:05:51PM +0200, Richard Biener wrote:
> With your experiment of computing ranges for everything we're good
> from the ICE point-of-view. I think there's nothing we can do to
> reassure us of correctness, so I'd take Andrews advice here (aka,
> go ahead). The only thing w
On Tue, 10 Jun 2025, Jakub Jelinek wrote:
> On Mon, Jun 09, 2025 at 07:46:28PM +0200, Jakub Jelinek wrote:
> > > So using, say, get_all_dominated_blocks (we free dominators, possibly
> > > PHI expansion might insert on edges) to get a PRE ordered set of
> >
> > I think PHI expansion does insert o
On Tue, Jun 10, 2025 at 10:47 AM Eric Botcazou wrote:
>
> Hi,
>
> the compiler can swap the operands of the short-circuit operators in some
> cases, which can be problematic for tools like Valgrind that detect uses of
> uninitialized data, and is probably counterproductive in most cases.
>
> The c
On Tue, Jun 10, 2025 at 12:55:39PM +0200, Richard Biener wrote:
> Yes, it must (but we expand those separately, so we could tear down
> ranger then).
>
> So apart from ICEing I wonder how ranger (and it's cache) deals with
> basic blocks being added, edges vanishing (we kill off all abnormal
> edg
> the patch looks good to me. I only have x86_64, too, therefore I haven't
> tested
> it (again). There's a lot of repetition in the regenerate.sh file. I hope to
> see this "simplified" or rather DRY'ed (Don't repeat yourself - principle) in
> the future.
Following up on this, here is a new patc
On Mon, 9 Jun 2025, Jakub Jelinek wrote:
> On Sun, Jun 08, 2025 at 10:49:44AM +0200, Richard Biener wrote:
> > I'm also a bit nervous about this given during RTL expansion the IL is
> > neither fully GIMPLE nor fully RTL. Given we do not perform many
> > range queries we might be just lucky to no
On 10/06/2025 09:49, Tobias Burnus wrote:
This add experimental support for AMD Instinct MI300. It has been
tested to support hello world, but not yet much beyond (to come).
OK for mainline?
I forgot that %G would have to have an operand number. That's not ideal,
but using a punctuation mark
Hi,
I stumbled into the bug [1] that I hope can be fixed with a new -W option.
A commenter [2] suggested splitting out a minor part in a separate patch first,
so that's why the series. I hope I got the formatting right; kindly asking
for comments.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?i
On Tue, Jun 10, 2025 at 2:02 AM Andrew Pinski wrote:
>
> On Mon, Jun 9, 2025 at 2:49 AM Richard Biener
> wrote:
> >
> > On Sun, Jun 8, 2025 at 7:52 PM Andrew Pinski
> > wrote:
> > >
> > > While thinking about how to implement the rest of the copy prop and makes
> > > sure not
> > > to introduc
Hi Pengfei,
This looks really good, I've just left a couple of small comments below.
On 06/06/2025 14:35, Pengfei Li wrote:
> Current GCC uses either peeling or versioning, but not in combination,
> to handle unaligned data references (DRs) during vectorization. This
> limitation causes some loop
On Tue, 2025-06-10 at 16:55 +0800, mengqinggang wrote:
> Add a new movsi_internal_la32 similar to movsi_internal, change
> constraint w(m, k, ZC) to m.
"w" is defined as TARGET_MEM_CONSTRAINT, and per GCC Internal:
-- Macro: TARGET_MEM_CONSTRAINT
A single character to be used instead of the defau
This script claims that wchar_t tests are filtered out if the toolchain
being tested doesn't support it. That doesn't seem to have been true
since r0-68039-ga72c74a1dee345 in 2005.
libstdc++-v3/ChangeLog:
* scripts/create_testsuite_files: Remove incorrect comment about
filtering
By using std::is_trivially_destructible instead of the old
__has_trivial_destructor built-in we no longer need the static_assert to
deal with types with deleted destructors. All non-destructible types,
including those with deleted destructors, will now give user-friendly
diagnostics that clearly ex
The std::basic_stringbuf::get_allocator() member is only available for
the SSO std::string ABI.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_istringstream/cons/char/string_view.cc:
Only check get_allocator() for new string ABI.
* testsuite/27_io/basic_ostringstream/cons
On Tue, Jun 10, 2025 at 1:19 AM Robert Dubner wrote:
>
> In the course of stamping out cppcheck warnings, we ran across a complaint
> about a "shadowed variable."
>
> It turns out that a variable declared in gcc/gcc/h as "extern int
> n_infiles;" is used only locally in gcc/gcc/cc.
>
> This change
A new option is added to warn if floating point literals have non-standard
suffices (currently Q and W) in pedantic mode. The option is ON by default.
The negative form `-Wno-non-standard-suffix` is expected to be used typically,
as is done for GCC itself and a few tests that otherwise would issue
On Tue, 2025-06-10 at 16:59 +0800, mengqinggang wrote:
> Disable k constraint to avoid generate stx/ldx instructions.
>
> gcc/ChangeLog:
>
> * config/loongarch/constraints.md: Add TARGET_64BIT condition for k.
> ---
> gcc/config/loongarch/constraints.md | 2 +-
> 1 file changed, 1 insert
On Mon, Jun 9, 2025 at 7:28 PM Jakub Jelinek wrote:
>
> Hi!
>
> For C++26 P2786R13 I'm afraid I'll need 4 new flags on class types
> in struct lang_type (1 bit for trivially_relocatable_if_eligible,
> 1 for replaceable_if_eligible, 1 for not_trivially_relocatable and
> 1 for not_replaceable) and t
On Tue, 2025-06-10 at 16:59 +0800, mengqinggang wrote:
> Add support for atomic_,
> atomic_fetch_,
> atomic_exchange on LA32.
>
> gcc/ChangeLog:
>
> * config/loongarch/sync.md: Add la32 support.
> ---
> gcc/config/loongarch/sync.md | 56 ++--
> 1 file chang
On Tue, 10 Jun 2025 at 04:23, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> This patch makes these integer-class types structural types by
> public-izing their data memberss so that they could be used as NTTP
s/memberss/members/
OK for trunk
On Mon, Jun 09, 2025 at 07:46:28PM +0200, Jakub Jelinek wrote:
> > So using, say, get_all_dominated_blocks (we free dominators, possibly
> > PHI expansion might insert on edges) to get a PRE ordered set of
>
> I think PHI expansion does insert on edges.
As for whether to expand in some different
On Tue, 2025-06-10 at 17:00 +0800, mengqinggang wrote:
> enum can't be used in #if.
> For #if expression, identifiers that are not macros,
> which are all considered to be the number zero.
Ooops :(.
> This patch may fix
> https://sourceware.org/bugzilla/show_bug.cgi?id=32776.
>
> gcc/ChangeLog:
On Tue, 2025-06-10 at 16:55 +0800, mengqinggang wrote:
> From: Jiajie Chen
>
> LoongArch32 does not include LDX/STX instructions, and cannot lower
> (plus (reg) (reg)) pattern. Forbid ADDRESS_REG_REG and do not emit
(mem (plus (reg) (reg)))
/* snip */
> diff --git a/gcc/testsuite/gcc.target/lo
1 - 100 of 139 matches
Mail list logo
