> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, July 24, 2024 1:09 PM
> To: Jiang, Haochen
> Cc: j...@ventanamicro.com; gcc-regress...@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [r15-2196 Regression] FAIL: c-c++-common/dfp/convert-bfp-6.c
> -std=gnu++98 execut
On Wed, Jul 24, 2024 at 01:49:06AM +, Jiang, Haochen wrote:
> It might be a false positive timeout alert. Please ignore that first.
It is not. I'm seeing it too consistently on i686-linux:
obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c execution test
obj49/LOGT:FAIL: c-c++-common/dfp/conv
On Wed, Jul 17, 2024 at 10:55 AM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
Just an FYI. This broke xalancbmk_r in SPEC 2017. clang has a flag to
delay the checking until instantiation time to work around this buggy
code, -fdelayed-t
When I was trying to add an scalar version of iorc and andc, the optab that
got matched was for and/ior with the mode of csi and cdi instead of iorc and
andc optabs for si and di modes. Since csi/cdi are the complex integer modes,
we need to rename the optabs to be without c there. This changes c t
I incline do not add skip_zacas stuffs (although skip_zabha is already
there but that's fine), because that's different situation compare to
the zaamo/zalrsc, zaamo/zalrsc should automatically append if a
extension is available, which is new behavior and new extensions.
But zacas is only added whe
Supports RISC-V profiles[1] in -march option.
Default input set the profile before other formal extensions.
V2: Fixes some format errors and adds code comments for parse function
Thanks for Jeff Law's review and comments.
V3: Update testcases and profiles extensions support.Remove S/M mode Profi
On 7/23/24 7:49 PM, Jiang, Haochen wrote:
It might be a false positive timeout alert. Please ignore that first.
Funny, I was wondering about that -- I couldn't get them to fail.
Jeff
It might be a false positive timeout alert. Please ignore that first.
Thx,
Haochen
> -Original Message-
> From: haochen.jiang
> Sent: Tuesday, July 23, 2024 7:51 PM
> To: j...@ventanamicro.com; gcc-regress...@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org; Jiang, Haochen
> Subject: [r15-2196 R
On 7/17/24 3:47 AM, Jakub Jelinek wrote:
Hi!
This patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655013.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657049.html
patches which just introduce non-o
> Just a slight comment improvement:
> /* Returns true if both types of TYPE_PAIR strictly match their modes,
> else returns false. */
> This testcase could go in g++.dg/torture/ without the -O3 option.
> Since we are scanning for the negative it should pass on all targets
> even ones without SA
co_await expressions are nearly calls to Awaitable::await_resume, and,
as such, should inherit its nodiscard. A discarded co_await expression
should, hence, act as if its call to await_resume was discarded.
CO_AWAIT_EXPR trees do conveniently contain the expression for calling
await_resume in the
It is possible to use parameters of a parent function of a lambda in
unevaluated contexts without capturing them. By not capturing them, we
work around the usual mechanism we use to prevent rewriting captured
parameters. Prevent this by simply skipping rewrites in unevaluated
contexts. Those won
This just adds the testcase from pr115877. It's working now on the
trunk. I'm not done with cleanups/bugfixing, but there's no reason to
not have the testcase installed at this point.
Pushed to the trunk.
jeff
commit f9a60d575f02822852aa22513c636be38f9c63ea
Author: Jeff Law
Date: Tue J
We would like to implement the following to store a single-precision FP
constant in a hardware FP register:
- Load the bit-exact integer image of the pooled single-precision FP
constant into an address (integer) register
- Then, assign from that address register to a hardware single-precision
According to the implemented pipeline model, this cost can be assumed to be
1 clock cycle.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_insn_cost):
Add a case statement for TYPE_FARITH.From b819dd4fb38bedd95ef5d66847a0f80b9ca8ee86 Mon Sep 17 00:00:00 2001
From: Takayuki 'Janu
(define_expand "atomic_compare_and_swap"
[(match_operand:SI 0 "register_operand" "") ;; bool output
(match_operand:GPR 1 "register_operand" "") ;; val output
(match_operand:GPR 2 "memory_operand" "");; memory
- (match_operand:GPR 3 "reg_or_0_operand" "") ;; expected value
From: Gianluca Guida
This patch adds support for amocas.{b|h|w|d}. Support for amocas.q
(64/128 bit cas for rv32/64) will be added in a future patch.
Extension: https://github.com/riscv/riscv-zacas
Ratification: https://jira.riscv.org/browse/RVS-680
gcc/ChangeLog:
* common/config/riscv
On 7/23/2024 11:20 AM, Richard Sandiford wrote:
Edwin Lu writes:
On 7/23/2024 4:56 AM, Richard Biener wrote:
On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu wrote:
Hi Richard,
On 5/31/2024 1:48 AM, Richard Biener wrote:
On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill wrote:
From: Greg McGary
On Mon, Jul 22, 2024 at 7:41 PM Kewen.Lin wrote:
>
> Hi Andrew,
>
> on 2024/7/23 08:09, Andrew Pinski wrote:
> > On Sun, Jun 30, 2024 at 11:17 PM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> As PR115659 shows, assuming c = x CMP y, there are some
> >> folding chances for patterns r = c ? 0/z : z/-1:
SPEC2017 perlbench for RISC-V was broke as runtime output mismatch
failure.
> 3830: mbox2:
> dWshe3Aa1EULre4CT5O/ErYFrk+o/EOoebA1kTVjQVQQH2EjT5fHcYnwjj2MdBmZu5y3Ce4Ei4QQZo/SNrry9g
>mbox2:
> uuWPimQiU0D4UrwFP+LS0lFNph4qL43WV1A6T3tHleatIOUaHixhrJU9NoA2lc9KjwYpdEL0lNTXkvo8ymNHzA
>
> On 23 Jul 2024, at 21:26, Jason Merrill wrote:
>
> On 6/17/24 8:14 AM, Iain Sandoe wrote:
>> This is a minor tidy-up, tested on x86_64-darwin,
>> OK For trunk?
>> thanks
>> Iain
>> --- 8< ---
>> At present, for pre-conditions and for post-conditions with a void
>> return, we are not emitting
On 7/23/24 15:18, Jeff Law wrote:
On 7/11/24 9:17 PM, HAO CHEN GUI wrote:
So why the test for real_isinf on the upper/lower bound? If op1 is
known to be a NaN, then why test the bounds at all? If a bounds
test is needed, why only test the upper bound?
IMHO, logical is if the op1 is a N
On 7/20/24 1:31 PM, Mark Harmstone wrote:
Translates DW_TAG_reference_type DIEs into LF_POINTER types.
gcc/
* dwarf2codeview.cc (get_type_num_reference_type): New function.
(get_type_num_array_type): Add DW_TAG_reference_type to switch.
(get_type_num): Handle DW_TAG_re
On 7/22/24 10:42 PM, Vineet Gupta wrote:
On 7/22/24 10:58, Jeff Law wrote:
On 7/22/24 11:52 AM, Vineet Gupta wrote:
On 7/9/24 17:26, Jeff Law wrote:
On 7/9/24 6:11 PM, Vineet Gupta wrote:
Couple weeks ago, 502.gcc was failing (PR/115669) which got fixed promptly.
On today's trunk I'm see
On 7/21/24 7:58 PM, HAO CHEN GUI wrote:
Hi,
This patch adds const0 move checking for CLEAR_BY_PIECES. The original
vec_duplicate handles duplicates of non-constant inputs. But 0 is a
constant. So even a platform doesn't support vec_duplicate, it could
still do clear by pieces if it supports
On Tue, Jul 23, 2024 at 05:12:14PM -0400, Jason Merrill wrote:
> On 7/23/24 4:18 PM, Marek Polacek wrote:
> > On Tue, Jul 23, 2024 at 12:53:07AM -0400, Jason Merrill wrote:
> > > On 7/20/24 2:31 PM, Marek Polacek wrote:
> > > > [ Entering the contest to fix the oldest PR in this cycle. ]
> > > >
>
A few ideas in case you want to generalize the transformation (these are
not requirements to get your patch in, and this is not a review):
On Fri, 19 Jul 2024, Eikansh Gupta wrote:
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4321,6 +4321,32 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
@0
@2))
On 7/19/24 3:04 PM, Carl Love wrote:
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 5af9bf920a2..2a18ee44526 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -878,9 +878,9 @@ (define_int_attr SLDB_lr [(UNSPEC_SLDB "l")
> (def
On 7/17/24 5:33 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Hmm, I thought I had replied to this already.
-- >8 --
Unfortunately, my r15-1946 fix broke the attached testcase. In it,
we no longer go into the
/* P1009: Array size deduction in new-ex
On Tue, 23 Jul 2024, Jason Merrill wrote:
> On 7/7/24 12:39 AM, Nathaniel Shead wrote:
> > Bootstrapped on x86_64-pc-linux-gnu, successfully regtested modules.exp;
> > OK for trunk if full regtest passes?
>
> Patrick, I assume this change won't mess with your streaming optimizations?
Should be f
On 7/23/24 4:18 PM, Marek Polacek wrote:
On Tue, Jul 23, 2024 at 12:53:07AM -0400, Jason Merrill wrote:
On 7/20/24 2:31 PM, Marek Polacek wrote:
[ Entering the contest to fix the oldest PR in this cycle. ]
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This 18-year-old
I'll push this as obvious soon.
-- >8 --
gcc/ChangeLog:
* doc/extend.texi: Add missing @option.
---
gcc/doc/extend.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b0273927b25..66c99ef7a66 100644
--- a/gcc/doc/ex
On 6/17/24 8:14 AM, Iain Sandoe wrote:
This is a minor tidy-up, tested on x86_64-darwin,
OK For trunk?
thanks
Iain
--- 8< ---
At present, for pre-conditions and for post-conditions with a void
return, we are not emitting a return statement. This patch adds the
relevant return statements.
Hmm,
On 7/7/24 12:39 AM, Nathaniel Shead wrote:
Bootstrapped on x86_64-pc-linux-gnu, successfully regtested modules.exp;
OK for trunk if full regtest passes?
Patrick, I assume this change won't mess with your streaming optimizations?
OK with Patrick's approval or on Friday, whichever comes first.
This patch adds support for arguments to the signal and interrupt
function attributes. It allows to specify the ISR by means of the
associated IRQ number, in extension to the current attributes that
require to specify the ISR name like "__vector_1" as (assembly) name
for the function. The new fe
On Tue, Jul 23, 2024 at 12:53:07AM -0400, Jason Merrill wrote:
> On 7/20/24 2:31 PM, Marek Polacek wrote:
> > [ Entering the contest to fix the oldest PR in this cycle. ]
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This 18-year-old PR reports that we
On 6/15/24 10:29 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
This probably isn't the most efficient approach, since we need to do
name lookup to find deduction guides for a type which will also
potentially do a bunch of pointless lazy loading from
On 7/18/24 7:46 PM, Andi Kleen wrote:
Updated patch with the !retval bug fix identified by Marek.
OK.
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter f
On 7/11/24 9:17 PM, HAO CHEN GUI wrote:
So why the test for real_isinf on the upper/lower bound? If op1 is known to be
a NaN, then why test the bounds at all? If a bounds test is needed, why only
test the upper bound?
IMHO, logical is if the op1 is a NAN, it's not an infinite number. If
On 7/22/24 11:07 AM, Roger Sayle wrote:
> > Whilst 33-bit pseudo-rotations almost certainly doesn't occur
frequently
in real code, this provides a very useful building block. Conventionally,
rotations require 2 cycles per bit; one cycle to shift the top-bit out
out of the source, and one cyc
On 22/07/2024 11:07, Alex Coplan wrote:
> Hi Claudio,
>
> I've left a couple of small comments below.
>
> On 22/07/2024 09:30, Claudio Bantaloukas wrote:
>>
>> Unlike most system registers, fpmr can be heavily written to in code that
>> exercises the fp8 functionality. That is because every fp8
Edwin Lu writes:
> On 7/23/2024 4:56 AM, Richard Biener wrote:
>> On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu wrote:
>>> Hi Richard,
>>>
>>> On 5/31/2024 1:48 AM, Richard Biener wrote:
On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill
wrote:
> From: Greg McGary
Still a NACK. If
GCC maintainers:
This patch was previously posted. Per the feedback, it is now the first
of two patches to remove the set built-ins.
This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df
and __builtin_vec_set_v2di built-ins. The users should just use normal
C-code to upda
GCC maintainers:
This patch removes the vsx set built-ins: __builtin_vsx_set_1ti,
__builtin_vsx_set_2df, __builtin_vsx_set_2di. With the removal of
these built-ins, the built-in attribute "set", used in the built-in
definition file, is no longer needed. The "set" and the associated
code f
Wilken Gottwalt writes:
> Fix using keywords as identifiers to prevent warnings coming from
> Modula-2's own libraries.
>
> m2pim/DynamicStrings.mod:1358:27: note: In procedure ‘Slice’: the symbol
> name ‘end’ is legal as an identifier, however as such it might cause
> confusion and is considered
Wilken Gottwalt writes:
> The Close() procedure in MemStream is missing a guard to prevent it from
> printing in non-debug mode.
>
> gcc/gm2:
> * gm2-libs-iso/MemStream.mod: Guard debug output.
>
> Signed-off-by: Wilken Gottwalt
> ---
> gcc/m2/gm2-libs-iso/MemStream.mod | 5 -
> 1 fil
On 7/23/24 10:30 AM, Roger Sayle wrote:
The subject line pretty much says it all; the count-trailing-zeros function
of -X produces the same result as count-trailing-zeros of X. This
transformation eliminates a negation which may potentially overflow with
an equivalent expression that doesn't
On 7/23/24 9:45 AM, Stefan Schulze Frielinghaus wrote:
They come from:
```
(define_insn "*tf_to_fprx2_0"
[(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "+f") 0)
(subreg:DF (match_operand:TF1 "general_operand" "v") 0))]
...
(define_insn "*tf_to_fprx2_1"
GCC maintainers:
The code generated by using C-code to set a vector element versus using
a built-in has been investigated. The assembly code generated from the
C-code is as good or better than the assembly code generated for the
built-ins for both the -O0 and -O3 levels of optimization.
For
On 23/07/2024 17:25, Adhemerval Zanella Netto wrote:
On 19/07/24 11:25, Richard Earnshaw (lists) wrote:
On 11/07/2024 19:31, Richard Sandiford wrote:
These tests used to generate:
bl swap
ldr r2, [sp, #4]
mov r0, r2 @ __fp16
but g:9d20529d94b23275885
On 7/23/2024 4:56 AM, Richard Biener wrote:
On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu wrote:
Hi Richard,
On 5/31/2024 1:48 AM, Richard Biener wrote:
On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill wrote:
From: Greg McGary
Still a NACK. If remain ends up zero then
GCC maintainers:
version 2, Updated patch comments, added missing ChangeLog. Fixed
unintended line removal.
The following patch removes the three __builtin_vsx_xvcmp[eq|ge|gt]sp
builtins as they similar to the overloaded vec_cmp[eq|ge|gt] built-ins.
The difference is the overloaded built-
On Tue, Jul 23, 2024 at 9:30 AM Roger Sayle wrote:
>
>
> The subject line pretty much says it all; the count-trailing-zeros function
> of -X produces the same result as count-trailing-zeros of X. This
> transformation eliminates a negation which may potentially overflow with
> an equivalent expre
The subject line pretty much says it all; the count-trailing-zeros function
of -X produces the same result as count-trailing-zeros of X. This
transformation eliminates a negation which may potentially overflow with
an equivalent expression that doesn't [much like the analogous abs(-X)
simplificat
On 19/07/24 11:25, Richard Earnshaw (lists) wrote:
> On 11/07/2024 19:31, Richard Sandiford wrote:
>> These tests used to generate:
>>
>> bl swap
>> ldr r2, [sp, #4]
>> mov r0, r2 @ __fp16
>>
>> but g:9d20529d94b23275885f380d155fe8671ab5353a means that we ca
On Mon, Jul 22, 2024 at 08:16:16PM -0700, Andrew Pinski wrote:
> On Sun, Jul 21, 2024 at 11:47 PM Stefan Schulze Frielinghaus
> > diff --git a/gcc/regrename.cc b/gcc/regrename.cc
> > index 054e601740b..6ae5a2309d0 100644
> > --- a/gcc/regrename.cc
> > +++ b/gcc/regrename.cc
> > @@ -1113,6 +1113,10
On Mon, 22 Jul 2024 07:16:28 PDT (-0700), kito.ch...@sifive.com wrote:
This provides a common abstraction layer to probe the available extensions at
run-time. These functions can be used to implement function multi-versioning or
to detect available extensions.
The advantages of providing this ab
Sam James writes:
(oops, forgot to CC docs maintainers. Done now.)
> At -O1, the intention is that we compile things in a "reasonable" amount
> of time (ditto memory use). In particular, we try to especially avoid
> optimizations which scale poorly on pathological cases, as is the case
> for lar
On 7/23/24 9:37 AM, Patrick Palka wrote:
On Tue, 23 Jul 2024, Jason Merrill wrote:
On 7/5/24 12:18 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14 and perhaps 13?
Alternatively we can set current_template_parms from weakly_subsumes
in
Hi Both,
> -Original Message-
> From: Jonathan Wakely
> Sent: Monday, July 22, 2024 3:21 PM
> To: Filip Kastl
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
>
> Subject: Re: [PATCH][contrib]: support json output from check_GNU_style_lib.py
>
> On Mon, 22 Jul 2024 at 14:54, Filip K
This PR seems to have been fixed by a fix for a seemingly unrelated PR.
Lets add a regression test to make sure it stays fixed.
PR c++/103953 - Leak of coroutine return object
PR c++/103953
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/torture/pr103953.C: New test.
Reviewed-by:
At -O1, the intention is that we compile things in a "reasonable" amount
of time (ditto memory use). In particular, we try to especially avoid
optimizations which scale poorly on pathological cases, as is the case
for large machine-generated code.
Recommend -O1 for large machine-generated code, as
Richard Biener writes:
> On Fri, Jul 19, 2024 at 1:10 PM wrote:
>>
>> From: Pan Li
>>
>> The direct_internal_fn_supported_p has no restrictions for the type
>> modes. For example the bitfield like below will be recog as .SAT_TRUNC.
>>
>> struct e
>> {
>> unsigned pre : 12;
>> unsigned a : 4
On Fri, Jul 19, 2024 at 1:10 PM wrote:
>
> From: Pan Li
>
> The direct_internal_fn_supported_p has no restrictions for the type
> modes. For example the bitfield like below will be recog as .SAT_TRUNC.
>
> struct e
> {
> unsigned pre : 12;
> unsigned a : 4;
> };
>
> __attribute__((noipa))
>
On Tue, Jul 23, 2024 at 10:27 AM Kugan Vivekanandarajah
wrote:
>
> On Tue, Jul 23, 2024 at 10:35 AM Andrew Pinski wrote:
> >
> > On Mon, Jul 22, 2024 at 5:26 PM Kugan Vivekanandarajah
> > wrote:
> > >
> > > Revised based on the comment and moved it into existing patterns as.
> > >
> > > gcc/Chan
On Tue, 23 Jul 2024, Jason Merrill wrote:
> On 7/5/24 12:18 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk/14 and perhaps 13?
> >
> > Alternatively we can set current_template_parms from weakly_subsumes
> > instead, who has only one
On 22/07/2024 10:45, Kyrylo Tkachov wrote:
> Hi Claudio,
> Thanks for working on this.
>
>> On 22 Jul 2024, at 11:30, Claudio Bantaloukas
>> wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
>> This introduces the relevant flags to enable access to the fpmr register a
On 7/22/24 9:16 PM, Andrew Pinski wrote:
It is interesting how there is a subreg of a hardregister after reload
showing up here. Is that on purpose?
In general subregs of hard regs shouldn't exist after allocation. There
are just a few exceptions to that rule. I don't remember where the co
Hi Vladimir,
Thanks for the update, this patch looks much better now.
Some more comments inline.
> On 23 Jul 2024, at 14:47, vladimir.miloser...@arm.com wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi All,
>
> Changes since V1: add missing MD constraints, rename i
On 23/07/2024 11:39, Richard Biener wrote:
On Tue, 23 Jul 2024, Jakub Jelinek wrote:
Hi!
Richi suggested to mention the PR116029 bug in 11.5.0 caveats as we can't
fix that anymore.
Here is a patch for that, which attempts to describe (my limited
understanding of) the issue.
As TARGET_CPU_gene
This provides a common abstraction layer to probe the available extensions at
run-time. These functions can be used to implement function multi-versioning or
to detect available extensions.
The advantages of providing this abstraction layer are:
- Easy to port to other new platforms.
- Easier to m
Hi All,
Changes since V1: add missing MD constraints, rename intrinsics,
remove SME2 flag for LUT feature.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
This depends on "Extend aarch64_feature_flags to 128 bits" work which is soon
to be submitted upstream as we ran out of 64-b
On 7/5/24 12:18 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14 and perhaps 13?
Alternatively we can set current_template_parms from weakly_subsumes
instead, who has only one caller anyway.
Would it also work to pass tmpl instead of NU
On 7/19/24 12:24 PM, Patrick Palka wrote:
On Fri, 19 Jul 2024, Jason Merrill wrote:
On 7/19/24 10:55 AM, Patrick Palka wrote:
On Fri, Jul 5, 2024 at 1:50 PM Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
-- >8 --
During the alias CT
On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu wrote:
>
> Hi Richard,
>
> On 5/31/2024 1:48 AM, Richard Biener wrote:
> > On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill
> > wrote:
> >>
> >> From: Greg McGary
> >
> > Still a NACK. If remain ends up zero then
> >
> > /* Try to us
On Linux/x86_64,
88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2 is the first bad commit
commit 88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2
Author: Jeff Law
Date: Mon Jul 22 08:45:10 2024 -0600
[NFC][PR rtl-optimization/115877] Avoid setting irrelevant bit groups as
live in ext-dce
caused
FAIL: c
On Mon, 22 Jul 2024 at 20:53, Michael Levine wrote:
>
> The bits/stl_algobase.h header was added to bits/ranges_algobase.h separately
> through two related commits:
>
> https://github.com/gcc-mirror/gcc/commit/674d213ab91871652e96dc2de06e6f50682eebe0
>
> https://github.com/gcc-mirror/gcc/commit/0b
On Tue, 23 Jul 2024, Jakub Jelinek wrote:
> Hi!
>
> Richi suggested to mention the PR116029 bug in 11.5.0 caveats as we can't
> fix that anymore.
>
> Here is a patch for that, which attempts to describe (my limited
> understanding of) the issue.
> As TARGET_CPU_generic is now 64, when config.gcc
On 23/07/2024 11:05, Tobias Burnus wrote:
Hi Andrew, hi all,
to be compatible with C++ (and Thomas' WIP work for GCN C++ support), I
suggest the attach patch that also suggest Thomas' Newlib commit (April
4, 2024)
ed50a50b9 amdgcn: Implement proper locks: Fix
'newlib/libc/sys/amdgcn/inclu
"Kewen.Lin" writes:
> Hi Jeff,
>
> on 2024/7/16 13:39, Jiufu Guo wrote:
>> Hi,
>>
>> For PR96866, when printing asm code for modifier "%a", an addressable
>> operand is required. While the constraint "X" allow any kind of
>> operand even which is hard to get the address directly. e.g. extern
>>
Hi!
Richi suggested to mention the PR116029 bug in 11.5.0 caveats as we can't
fix that anymore.
Here is a patch for that, which attempts to describe (my limited
understanding of) the issue.
As TARGET_CPU_generic is now 64, when config.gcc doesn't set
TARGET_CPU_DEFAULT, we end up with TARGET_CPU_
According to the Neoverse V2 Software Optimization Guide (section 4.14), the
instruction pairs CMP+CSEL and CMP+CSET can be fused, which had not been
implemented so far. This patch implements and tests the two fusion pairs.
The patch was bootstrapped and regtested on aarch64-linux-gnu, no regressi
On 2024-07-23 09:59, Richard Biener wrote:
On Tue, 23 Jul 2024, Torbjorn SVENSSON wrote:
Gentle ping :)
As mentioned in the ticket, I would like to target this to trunk and
releases/gcc-14.
OK.
Richard.
Pushed as releases/gcc-14.1.0-331-ga544898f6dd and
basepoints/gcc-15-2224-g7793f5
Hi Andrew, hi all,
to be compatible with C++ (and Thomas' WIP work for GCN C++ support), I
suggest the attach patch that also suggest Thomas' Newlib commit (April
4, 2024)
ed50a50b9 amdgcn: Implement proper locks: Fix
'newlib/libc/sys/amdgcn/include/sys/lock.h' for C++
and not only your
When the constraint graph consists of N nodes with only complex
constraints and no copy edges we have to be lucky to arrive at
a constraint solving order that requires the optimal number of
iterations. What happens in the testcase is that we bottle-neck
on computing the visitation order but propag
Tested x86_64-linux, built on avr.
Pushed to trunk.
-- >8 --
This avoids some warnings when the preprocessor conditions are not met.
libstdc++-v3/ChangeLog:
* src/c++23/print.cc (__open_terminal): Use [[maybe_unused]] on
parameter.
---
libstdc++-v3/src/c++23/print.cc | 4 ++--
I'm pushing this workaround from Detlef.
I incorrectly assumed that is enough to ensure isatty is
present, but that isn't true for avr-libc.
It might be cleaner to add a proper autoconf check for isatty and dup,
but we don't have any reports of it failing for other targets. This
simple workaroun
On Fri, Jul 19, 2024 at 4:11 AM wrote:
>
> From: Pan Li
>
> The direct_internal_fn_supported_p has no restrictions for the type
> modes. For example the bitfield like below will be recog as .SAT_TRUNC.
>
> struct e
> {
> unsigned pre : 12;
> unsigned a : 4;
> };
>
> __attribute__((noipa))
>
On Tue, 23 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 23, 2024 at 08:42:24AM +0200, Richard Biener wrote:
> > On Tue, 23 Jul 2024, Jakub Jelinek wrote:
> > > The folding into REALPART_EXPR is correct, used only when the mem_offset
> > > is zero, but for IMAGPART_EXPR it didn't check the exact of
On Tue, Jul 23, 2024 at 10:07:08AM +0200, Jakub Jelinek wrote:
> Anyway, yet another option because non_rewritable_mem_ref_base has
> the VECTOR/COMPLEX types cases together would be to have them together
> in maybe_rewrite_mem_ref_base too, so do:
In patch form that would be:
2024-07-23 Jakub J
On 22/07/2024 10:51, Kyrylo Tkachov wrote:
> Hi Claudio,
>
>> On 22 Jul 2024, at 11:30, Claudio Bantaloukas
>> wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
>> Unlike most system registers, fpmr can be heavily written to in code that
>> exercises the fp8 functiona
On Tue, Jul 23, 2024 at 10:35 AM Andrew Pinski wrote:
>
> On Mon, Jul 22, 2024 at 5:26 PM Kugan Vivekanandarajah
> wrote:
> >
> > Revised based on the comment and moved it into existing patterns as.
> >
> > gcc/ChangeLog:
> >
> > * match.pd: Extend A CMP 0 ? A : -A into (type)A CMP 0 ? A : -A.
>
On Tue, Jul 23, 2024 at 08:42:24AM +0200, Richard Biener wrote:
> On Tue, 23 Jul 2024, Jakub Jelinek wrote:
> > The folding into REALPART_EXPR is correct, used only when the mem_offset
> > is zero, but for IMAGPART_EXPR it didn't check the exact offset value (just
> > that it is not 0).
> > The fol
On Tue, 23 Jul 2024, Torbjorn SVENSSON wrote:
> Gentle ping :)
>
> As mentioned in the ticket, I would like to target this to trunk and
> releases/gcc-14.
OK.
Richard.
> Kind regards,
> Torbjörn
>
> On 2024-07-15 12:16, Torbjörn SVENSSON wrote:
> > As the test case requires +-Inf and NaN to w
Fix using keywords as identifiers to prevent warnings coming from
Modula-2's own libraries.
m2pim/DynamicStrings.mod:1358:27: note: In procedure ‘Slice’: the symbol
name ‘end’ is legal as an identifier, however as such it might cause
confusion and is considered bad programming practice
1358 |
Gentle ping :)
As mentioned in the ticket, I would like to target this to trunk and
releases/gcc-14.
Kind regards,
Torbjörn
On 2024-07-15 12:16, Torbjörn SVENSSON wrote:
As the test case requires +-Inf and NaN to work and -ffast-math is added
by default for arm-none-eabi, re-enable non-finit
96 matches
Mail list logo
