> On May 14, 2024, at 10:29, Richard Biener wrote:
>
> On Tue, 14 May 2024, Qing Zhao wrote:
>
>>
>>
>>> On May 14, 2024, at 09:08, Richard Biener wrote:
>>>
>>> On Mon, 13 May 2024, Qing Zhao wrote:
>>>
-Warray-bounds is an important option to enable linux kernal to keep
the ar
On 5/7/24 11:38 PM, Christoph Müllner wrote:
Make clear_by_pieces() available to other parts of the compiler,
similar to store_by_pieces().
gcc/ChangeLog:
* expr.cc (clear_by_pieces): Remove static from clear_by_pieces.
* expr.h (clear_by_pieces): Add prototype for clear_by_p
On 6 May 2024, at 18:28, Jason Merrill wrote:
On 5/6/24 09:20, Simon Martin wrote:
Hi,
We currently ICE upon the following invalid snippet because we fail
to properly handle tsubst_arg_types returning error_mark_node in
build_deduction_guide.
== cut ==
template
struct A { A(Ts...); };
A a;
Hi Matthias,
From my side, I get several error like this:
/export/users/haochenj/src/gcc-bisect/master/master/r15-429/bld/x86_64-linux/32/libstdc++-v3/include/experimental/bits/simd_builtin.h:131:
error: could not convert
'std::experimental::parallelism_v2::__vec_shuffle<__vector(4) wchar_t,
_
> On 14 May 2024, at 14:29, Richard Biener wrote:
>
> On Wed, May 8, 2024 at 9:37 PM Iain Sandoe wrote:
>>
>> Hi Folks,
>>
>> I’d like to land a viable solution to this issue if possible, (it is a show-
>> stopper for the aarch64-darwin development branch).
>
> I was looking as to how we h
On 5/14/24 8:51 AM, Patrick O'Neill wrote:
I was able to find the summary info:
Tests that now fail, but worked before (15 tests):
libgomp: libgomp.fortran/simd7.f90 -O0 execution test
libgomp: libgomp.fortran/task2.f90 -O0 execution test
libgomp: libgomp.fortran/vla2.f90 -O0 ex
When I was checking to making sure that all of the bugs dealing
with the case where gimple_can_duplicate_bb_p would return false was fixed,
I noticed that the code which was checking if a call statement was
returns_twice was checking all call statements rather than just the
last statement. Since ca
On 5/13/24 22:16, HAO CHEN GUI wrote:
Hi Aldy,
Thanks for your review comments.
在 2024/5/13 19:18, Aldy Hernandez 写道:
+//Implement range operator for CFN_BUILT_IN_ISFINITE
+class cfn_isfinite : public range_operator
+{
+public:
+ using range_operator::fold_range;
+ using range_operator::
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-14.1.0.sv.po', has ju
On Tue, May 07, 2024 at 10:37:55AM +0800, HAO CHEN GUI wrote:
> The former patch adds isfinite optab for __builtin_isfinite.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
>
> Thus the builtin might not be folded at front end. The range op for
> isfinite is needed for value
> On May 14, 2024, at 11:08, Jeff Law wrote:
>
>
>
> On 5/14/24 8:57 AM, Qing Zhao wrote:
>>> On May 13, 2024, at 20:14, Kees Cook wrote:
>>>
>>> On Tue, May 14, 2024 at 01:38:49AM +0200, Andrew Pinski wrote:
On Mon, May 13, 2024, 11:41 PM Kees Cook wrote:
> But it makes no sense
On Dienstag, 14. Mai 2024 17:42:09 MESZ Jiang, Haochen wrote:
> Hi Matthias,
>
> From my side, I get several error like this:
>
> /export/users/haochenj/src/gcc-bisect/master/master/r15-429/bld/x86_64-linux
> /32/libstdc++-v3/include/experimental/bits/simd_builtin.h:131: error: could
> not conver
> Looks generally OK though does this mean people can debug
> programs using [[gnu::musttail]] only with optimized builds? It
> seems to me we should try harder to make [[gnu::musttail]] work
> at -O0 and generally behave the same at all optimization levels?
Yes that's a fair point. The problem i
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in
>
> The built-in __builtin_vsx_xvcmpeqsp_p is a duplicate of the overloaded
> __builtin_altivec_vcmpeqfp_p built-in. The built-in is undocumented and
> there are no test cases for it. The patch removes
On 5/14/24 08:44, Jeff Law wrote:
> On 5/14/24 8:51 AM, Patrick O'Neill wrote:
>>> I was able to find the summary info:
>>>
Tests that now fail, but worked before (15 tests):
libgomp: libgomp.fortran/simd7.f90 -O0 execution test
libgomp: libgomp.fortran/task2.f90 -O0 executi
On Mon, May 13, 2024 at 07:48:30PM +, Qing Zhao wrote:
> The false positive warnings are moved from -Warray-bounds=1 to
> -Warray-bounds=2 now.
On a Linux kernel x86_64 allmodconfig build, this takes the -Warray-bounds
warnings from 14 to 9. After examining these 9, I see:
- 4: legitimate bu
On Thu, May 09, 2024 at 12:44:52PM -0400, Jason Merrill wrote:
> On 5/9/24 12:16, Marek Polacek wrote:
> > +static void
> > +maybe_warn_extra_semi (location_t loc, extra_semi_kind kind)
> > +{
> > + /* -Wno-extra-semi suppresses all. */
> > + if (warn_extra_semi == 0)
> > +return;
> > +
> >
On 5/14/24 10:36 AM, Vineet Gupta wrote:
On 5/14/24 08:44, Jeff Law wrote:
On 5/14/24 8:51 AM, Patrick O'Neill wrote:
I was able to find the summary info:
Tests that now fail, but worked before (15 tests):
libgomp: libgomp.fortran/simd7.f90 -O0 execution test
libgomp: libgomp.fortran/
On Tue, May 14, 2024 at 6:30 PM Andi Kleen wrote:
>
> > Looks generally OK though does this mean people can debug
> > programs using [[gnu::musttail]] only with optimized builds? It
> > seems to me we should try harder to make [[gnu::musttail]] work
> > at -O0 and generally behave the same at all
Hi Mikael,
Thanks for your comments.
在 2024/5/9 16:03, Mikael Morin 写道:
> I think the canonical API behaviour sets R to varying and returns true
> instead of just returning false if nothing is known about the range.
>
> I'm not sure whether it makes any difference; Aldy can probably tell. But
On Tue, 14 May 2024, Qing Zhao wrote:
>
>
> > On May 14, 2024, at 10:29, Richard Biener wrote:
> >
[...]
> > It would of course
> > need experimenting since we can end up moving stmts and merging blocks
> > though the linear traces created by jump threading should be quite
> > stable (as oppo
> > diff --git a/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
> > b/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
> > index 3a6d4cceaba7..44af361e2925 100644
> > --- a/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
> > +++ b/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
> > @@ -1,4 +1,5 @@
> >
> On May 14, 2024, at 13:14, Richard Biener wrote:
>
> On Tue, 14 May 2024, Qing Zhao wrote:
>
>>
>>
>>> On May 14, 2024, at 10:29, Richard Biener wrote:
>>>
> [...]
>>> It would of course
>>> need experimenting since we can end up moving stmts and merging blocks
>>> though the linear tra
Hi Jason,
On Mon, May 06, 2024 at 11:02:20PM -0400, Jason Merrill wrote:
> > @@ -30189,7 +30207,7 @@ cp_parser_std_attribute (cp_parser *parser, tree
> > attr_ns)
> > /* Maybe we don't expect to see any arguments for this attribute. */
> > const attribute_spec *as
> > = looku
Hi Andrew,
On Fri, May 3, 2024 at 8:50 PM Andrew Pinski
wrote:
> This patch adds Qualcomm's new oryon-1 core; this is enough
> to recongize the core and later on will add the tuning structure.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-cores.def (oryon-1): New entry.
> * con
Hi Joseph and Richi,
Thanks for the suggestions and comments!
on 2024/5/10 14:31, Richard Biener wrote:
> On Thu, May 9, 2024 at 9:12 PM Joseph Myers wrote:
>>
>> On Wed, 8 May 2024, Kewen.Lin wrote:
>>
>>> to widen IFmode to TFmode. To make build_common_tree_nodes
>>> be able to find the corre
Tested x86_64-pc-linux-gnu, OK to add such a test?
-- >8 --
Let
int8_t x = 127;
This DR says that while
x++;
invokes UB,
++x;
does not. The resolution was to make the first one valid. The
following test verifies that we don't report any errors in a constexpr
context.
DR 2855
Ping.
I see that GCC-14 has been released recently. This is a gentle ping to
see if this is a better time for this patch.
Have a lovely day!
Alex
signature.asc
Description: PGP signature
Hi Ajit,
Please can you pay careful attention to the review comments?
In particular, you have ignored my comment about changing the access of
member functions in ldp_bb_info several times now (on at least three
patch reviews).
Likewise on multiple occasions you've only partially implemented a pi
... if the constant can be represented as sum of two S12 values.
The two S12 values could instead be fused with subsequent ADD insn.
The helps
- avoid an additional LUI insn
- side benefits of not clobbering a reg
e.g.
w/o patch w/ patch
long
On 5/9/24 04:47, HAO CHEN GUI wrote:
Hi Mikael,
Thanks for your comments.
在 2024/5/9 16:03, Mikael Morin 写道:
I think the canonical API behaviour sets R to varying and returns true instead
of just returning false if nothing is known about the range.
I'm not sure whether it makes any diff
Commit r15-436-g44e7855e did not fix PR115013 for PRU because
SMALL_REGISTER_CLASS_P is not returning an accurate value for the PRU
backend.
Word mode for PRU backend is defined as 8-bit, yet all ALU operations
are preferred in 32-bit mode. Thus checking whether a register class
contains a single
On Tue, May 14, 2024 at 02:17:16PM +, Qing Zhao wrote:
> The current major issue with the warning is: the constant index value 4
> is not in the source code, it’s a compiler generated intermediate value
> (even though it’s a correct value -:)). Such warning messages confuse
> the end-users wit
From: trcrsired
When building native GCC for the x86_64-w64-mingw32 host, the compiler copies
its library DLLs to the `bin` directory. However, in the case of a multilib
configuration, both 32-bit and 64-bit libraries end up in the same `bin`
directory, leading to conflicts where 64-bit DLLs a
Ping
On 5/2/24 09:54, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk? 14.2?
This two-year-old thread seems relevant:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593410.html
-- 8< --
#pragma target and optimize should also apply to implicitly-generated
functions li
On 5/14/24 13:54, Marek Polacek wrote:
Tested x86_64-pc-linux-gnu, OK to add such a test?
OK.
-- >8 --
Let
int8_t x = 127;
This DR says that while
x++;
invokes UB,
++x;
does not. The resolution was to make the first one valid. The
following test verifies that we don't report
On 5/14/24 13:24, Andi Kleen wrote:
Hi Jason,
On Mon, May 06, 2024 at 11:02:20PM -0400, Jason Merrill wrote:
@@ -30189,7 +30207,7 @@ cp_parser_std_attribute (cp_parser *parser, tree
attr_ns)
/* Maybe we don't expect to see any arguments for this attribute. */
const attribute_spe
On 5/14/24 12:55, Marek Polacek wrote:
On Thu, May 09, 2024 at 12:44:52PM -0400, Jason Merrill wrote:
On 5/9/24 12:16, Marek Polacek wrote:
+static void
+maybe_warn_extra_semi (location_t loc, extra_semi_kind kind)
+{
+ /* -Wno-extra-semi suppresses all. */
+ if (warn_extra_semi == 0)
+r
On 5/14/24 09:48, Marek Polacek wrote:
On Thu, May 09, 2024 at 03:47:54PM -0400, Jason Merrill wrote:
On 5/9/24 12:04, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we crash on a cp_gimplify_expr/TARGET_EXPR assert:
/* A TARGET_EXPR th
On 5/13/24 08:10, Rainer Orth wrote:
Hi Nathaniel,
There are a couple of other tests that appear to potentially have a
similar issue:
global-2_a.C
21:// { dg-final { scan-lang-dump-not {Reachable GMF '::printf[^\n']*'
added} module } }
global-3_a.C
15:// { dg-final { scan-lang-dump-not {Reach
On Mon, 13 May 2024 16:08:21 PDT (-0700), Vineet Gupta wrote:
On 5/13/24 15:47, Jeff Law wrote:
On 5/13/24 11:49, Vineet Gupta wrote:
500.perlbench_r-0 | 1,214,534,029,025 | 1,212,887,959,387 |
500.perlbench_r-1 |740,383,419,739 | 739,280,308,163 |
500.perlbench_r-2 |692,074,
On 5/13/24 06:19, Jakub Jelinek wrote:
On Fri, May 10, 2024 at 03:59:25PM -0400, Jason Merrill wrote:
2024-05-09 Jakub Jelinek
Jason Merrill
PR lto/113208
* cp-tree.h (maybe_optimize_cdtor): Remove.
* decl2.cc (tentative_decl_linkage): Call maybe_make_on
On 5/12/24 22:58, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This appears to be an oversight in the definition of module_has_cmi_p;
this comes up transitively in other functions used for e.g. determining
whether a name could potential
On 5/11/24 08:32, Nathaniel Shead wrote:
I wasn't entirely sure what to do with the 'abi/main.C' testcase here;
is this OK, or should I e.g. lower the linkage error to a pedwarn for
the purposes of this test?
I think it should be a pedwarn anyway, since it's harmless. The others
can still be
On 5/11/24 20:46, Patrick Palka wrote:
On Fri, 10 May 2024, Jason Merrill wrote:
On 5/9/24 16:23, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14? For trunk as a follow-up I can implement the
mentionted representation change to use CALL_E
Hello Alex:
On 13/05/24 8:49 pm, Alex Coplan wrote:
> Hi Ajit,
>
> Why did you send three mails for this revision of the patch? If you're
> going to send a new revision of the patch you should increment the
> version number and outline the changes / reasons for the new revision.
>
There were i
Hi,
Segher Boessenkool writes:
> Oh, btw:
>
> On Tue, May 14, 2024 at 11:00:38AM +0800, Jiufu Guo wrote:
>> >> --- a/gcc/config/rs6000/rs6000.cc
>> >> +++ b/gcc/config/rs6000/rs6000.cc
>> >> @@ -14659,6 +14659,12 @@ print_operand_address (FILE *file, rtx x)
>> >>else if (SYMBOL_REF_P (x) ||
On 5/14/24 15:12, Palmer Dabbelt wrote:
> On Mon, 13 May 2024 16:08:21 PDT (-0700), Vineet Gupta wrote:
>>
>> On 5/13/24 15:47, Jeff Law wrote:
On 5/13/24 11:49, Vineet Gupta wrote:
> 500.perlbench_r-0 | 1,214,534,029,025 | 1,212,887,959,387 |
> 500.perlbench_r-1 |740,383,4
Some processors from T-Head don't implement the `fence.tso` instruction
natively and instead trap to firmware. This breaks some users who
haven't yet updated the firmware and one could imagine it breaking users
who are trying to build firmware if they're using the C memory model.
So just add an o
> > > You need a template testcase; I expect it doesn't work in templates with
> > > the
> > > current patch. It's probably enough to copy it in tsubst_expr where we
> > > currently propagate CALL_EXPR_OPERATOR_SYNTAX.
> >
> > I tried it with the appended test case, everything seems to work with
Since there is no corresponding instruction, the shift operation for
vector int8 is implemented using the instructions for vector int16,
but for some special shift counts, it can be transformed into vpcmpgtb.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/Chang
On 5/14/24 5:13 PM, Palmer Dabbelt wrote:
Some processors from T-Head don't implement the `fence.tso` instruction
natively and instead trap to firmware. This breaks some users who
haven't yet updated the firmware and one could imagine it breaking users
who are trying to build firmware if they
From: Pan Li
This patch would like to add the middle-end presentation for the
saturation add. Aka set the result of add to the max when overflow.
It will take the pattern similar as below.
SAT_ADD (x, y) => (x + y) | (-(TYPE)((TYPE)(x + y) < x))
Take uint8_t as example, we will have:
* SAT_AD
From: Pan Li
The patch implement the SAT_ADD in the riscv backend as the
sample for both the scalar and vector. Given below vector
as example:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
unsigned i;
for (i = 0; i < n; i++)
out[i] = (x[i] + y[i]) | (- (u
On Mon, May 13, 2024 at 3:40 PM Richard Biener
wrote:
>
> On Mon, May 13, 2024 at 4:29 AM liuhongt wrote:
> >
> > As testcase in the PR, O3 cunrolli may prevent vectorization for the
> > innermost loop and increase register pressure.
> > The patch removes the 1/3 reduction of unr_insn for innermo
From: Pan Li
For vectorize, we leverage the existing vect pattern recog to find
the pattern similar to scalar and let the vectorizer to perform
the rest part for standard name usadd3 in vector mode.
The riscv vector backend have insn "Vector Single-Width Saturating
Add and Subtract" which can be
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, May 14, 2024 8:23 PM
> To: Hu, Lin1
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> ubiz...@gmail.com
> Subject: RE: [PATCH] vect: generate suitable convert insn for int -> int,
> float ->
> float and int <-> float.
>
> On Tue
Hi,
Segher Boessenkool writes:
> On Tue, May 14, 2024 at 05:53:56PM +0800, Jiufu Guo wrote:
>> Thanks so much for your great review!
>> Reference other messages, I'm wondering "invalid %%a value" may be
>> acceptable, or "invalid %%a address expression in TOC" maybe better.
>
> "%%a requires a
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
symbol whose address is in TOC.
An error message would be reported to indicate the invalid
Hi,
Sorry for missing word "V2". According to previous comments,
this version updates:
1. using different 'tests' for the invalid case, and put the msg
to a better and safer possition.
2. refine the words of the message.
3. updates the test case a little for comments.
BR,
Jeff(Jiufu) Guo
Jiufu G
Hi Jakub,
Thanks for your review comments.
在 2024/5/14 23:57, Jakub Jelinek 写道:
> BUILT_IN_ISFINITE is just one of many BUILT_IN_IS... builtins,
> would be nice to handle the others as well.
>
> E.g. isnormal/isnan/isinf, fpclassify etc.
>
Yes, I already sent the patches which add range op for
Previously, we use 16:11:8 in generic tune for Intel processors, which
lead to cross cache line issue and result in some random performance
penalty in benchmarks with small loops commit to commit.
After changing to always aligning to 16 bytes, it will somehow solve
the issue.
gcc/ChangeLog:
Hi all,
Recently, we have encountered several random performance regressions in
benchmarks commit to commit. It is caused by cross cacheline issue for
tight loops.
We are trying to solve the issue by two patches. One is adjusting the
loop alignment for generic tune, the other is aligning tight an
From: liuhongt
When hot loop is small enough to fix into one cacheline, we should align
the loop with ceil_log2 (loop_size) without considering maximum
skipp bytes. It will help code prefetch.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_avoid_jump_mispredicts): Change
gen_pad to
Also cc Honza and Richard since we touched generic tune.
Thx,
Haochen
> -Original Message-
> From: Haochen Jiang
> Sent: Wednesday, May 15, 2024 11:04 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH 0/2] Align tight loops to solve cross cacheline
I should have double-checked the CI system before pushing Christoph's
patches for memset-zero. While I thought I'd checked CI state, I must
have been looking at the wrong patch from Christoph.
Anyway, this fixes the rv32 ICEs and disables one of the tests for rv32.
The test would need a revam
On Fri, May 10, 2024 at 6:01 AM Patrick O'Neill wrote:
>
> Hi Christoph,
>
> cpymemsi-1.c fails on a subset of newlib targets.
>
> "UNRESOLVED: gcc.target/riscv/cpymemsi-1.c -O0 compilation failed to
> produce executable"
>
> Full list of failing targets here (New Failures section):
> https://g
This patch would like to add new sub extension (aka Zvfbfwma) to the
-march= option. It introduces a new data type BF16.
1 In spec: "Zvfbfwma requires the Zvfbfmin extension and the Zfbfmin extension."
1.1 In EmbeddedProcessor: Zvfbfwma -> Zvfbfmin -> Zve32f
1.2 In Application Processor: Z
LGTM, I agree we should only implement what Embedded Processor
implies, we have no way to know that from the arch string
On Wed, May 15, 2024 at 1:35 PM Xiao Zeng wrote:
>
> This patch would like to add new sub extension (aka Zvfbfwma) to the
> -march= option. It introduces a new data type BF
On Tue, 14 May 2024, Kees Cook wrote:
> On Tue, May 14, 2024 at 02:17:16PM +, Qing Zhao wrote:
> > The current major issue with the warning is: the constant index value 4
> > is not in the source code, it’s a compiler generated intermediate value
> > (even though it’s a correct value -:)). Su
Hi Andrew,
Thanks so much for your explanation. I got it. I will address the issue.
Thanks
Gui Haochen
在 2024/5/15 2:45, Andrew MacLeod 写道:
>
> On 5/9/24 04:47, HAO CHEN GUI wrote:
>> Hi Mikael,
>>
>> Thanks for your comments.
>>
>> 在 2024/5/9 16:03, Mikael Morin 写道:
>>> I think the canonic
On Tue, 14 May 2024, Qing Zhao wrote:
>
>
> > On May 14, 2024, at 13:14, Richard Biener wrote:
> >
> > On Tue, 14 May 2024, Qing Zhao wrote:
> >
> >>
> >>
> >>> On May 14, 2024, at 10:29, Richard Biener wrote:
> >>>
> > [...]
> >>> It would of course
> >>> need experimenting since we can
A bug was found when adding operand %ah to an invalid test case, so patch 1/2
was added to fix it. And made the following changes to the old patch.
1. Removed two redundant judgment codes in zu.
2. Added various types of register sizes in invalid test cases (found a bug
about AH/BH/CH/DH).
3.
gas/ChangeLog:
* config/tc-i386.c (md_assemble): Add invalid check for old byte
registers in EVEX/VEX format.
* testsuite/gas/i386/x86-64-apx-inval.l: Add new test.
* testsuite/gas/i386/x86-64-apx-inval.s: Ditto.
---
gas/config/tc-i386.c | 12 +
gas/ChangeLog:
* config/tc-i386.c (build_apx_evex_prefix): Handle ZU.
* testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
* testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
* testsuite/gas/i386/x86-64-apx-zu-intel.d: New test.
* testsuite/gas/i386
Sorry, please ignore these patches.
Regards,
Lili.
> -Original Message-
> From: Cui, Lili
> Sent: Wednesday, May 15, 2024 2:24 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH 0/2] Support APX zero-upper
>
>
> A bug was found when adding operand
Emitting a DI pattern won't find a match for rv32 and manifests in
the failing test case gcc.target/riscv/cmo-zicboz-zic64-1.c.
Let's fix this in the expansion and also address the different
code that gets generated for rv32/rv64.
gcc/ChangeLog:
* config/riscv/riscv-string.cc (riscv_expan
We have an arch-independent routine to generate an address with an offset.
Let's use that instead of doing the calculation in the backend.
gcc/ChangeLog:
* config/riscv/riscv-string.cc (emit_strcmp_scalar_load_and_compare):
Use adjust_address() to calculate MEM-PLUS pattern.
Sign
GCC has a generic cmpmemsi expansion via the by-pieces framework,
which shows some room for target-specific optimizations.
E.g. for comparing two aligned memory blocks of 15 bytes
we get the following sequence:
my_mem_cmp_aligned_15:
li a4,0
j .L2
.L8:
bgeua4
On Thu, May 9, 2024 at 4:50 PM Jeff Law wrote:
>
>
>
> On 5/7/24 11:52 PM, Christoph Müllner wrote:
> > GCC has a generic cmpmemsi expansion via the by-pieces framework,
> > which shows some room for target-specific optimizations.
> > E.g. for comparing two aligned memory blocks of 15 bytes
> > we
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, fix error in unsigned vector float to unsigned int built-in
> definitions
>
> The built-ins __builtin_vsx_vunsigned_v2df and__builtin_vsx_vunsigned_v4sf
> are supposed to take a vector of floats and return a vector of unsigned
> long long ints.
Minor update – to include GCC 14 and update mainline to 15.
I also replaced the doc links to the latest release; shouldn't matter
for the status but it is nicer nonetheless.
Tobias
commit 6d76756d2070040c35e7991a626805a736edea1d
Author: Tobias Burnus
Date: Tue May 14 09:34:47 2024 +0200
Hi,
在 2024/5/10 20:50, Richard Biener 写道:
> IMO give we're dispatching to the rtx_cost hook eventually it needs
> documenting there or alternatively catching zero and adjusting its
> result there. Of course cost == 0 ? 1 : cost is wrong as it makes
> zero vs. one the same cost - using cost + 1 wh
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, extend the current vec_{un,}signed{e,o} built-ins
>
> The built-ins __builtin_vsx_xvcvspsxds and __builtin_vsx_xvcvspuxds
> convert a vector of floats to signed/unsigned long long ints. Extend the
> existing vec_{un,}signed{e,o} built-ins to han
This breaks libstdc++-abi/abi_check.
3 incompatible symbols
0
_ZTIPKDF16b
typeinfo for std::bfloat16_t const*
version status: incompatible
CXXABI_1.3.14
type: object
type size: 32
status: added
1
_ZTIPDF16b
typeinfo for std::bfloat16_t*
version status: incompatible
CXXABI_1.3.14
type: object
ty
From: Ronan Desplanques
The crash this patch fixes happened because calling the Errout.Error_Msg
procedures that don't have an N parameter is not allowed when not
parsing and -gnatdJ is on. And -gnatyB style checks are not emitted during
parsing but during semantic analysis.
This commit moves Ch
From: Eric Botcazou
The Name is optional on these nodes and a superflous space is printed if
it is not present on them.
gcc/ada/
* sprint.adb (Sprint_Node_Actual) : Be prepared
for an empty Name.
: Likewise.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/
From: Eric Botcazou
Unlike what is assumed in other parts of the front-end, some objects created
with No_Initialization set on their declaration may end up being initialized
with a default value.
gcc/ada/
* exp_ch3.adb (Default_Initialize_Object): Return immediately when
either
From: Eric Botcazou
The recent fix to Default_Initialize_Object, which has ensured that the
No_Initialization flag set on an object declaration, for example for the
temporary created by Expand_N_Case_Expression, is honored in all cases,
has also uncovered a latent issue in the machinery responsib
From: Eric Botcazou
As written down in a comment, "There is a *huge* amount of code duplication"
in the implementation of default initializaion for objects in the front-end,
between the (static) declaration case and the dynamic allocation case.
This change factors out the implementation of the (
From: Yannick Moy
Update checking of ghost code after a small change in SPARK RM
rules 6.9(15) and 6.9(20), so that the Ghost assertion policy
that matters when checking the validity of a reference to a ghost entity
in an assertion expression is the Ghost assertion policy at the point
of declarat
101 - 191 of 191 matches
Mail list logo
