On Wed, Apr 05, 2023 at 02:11:08PM +0200, Richard Biener wrote:
> Ok, but maybe there’s a gimple_build overload that meanwhile implements
> the desired semantics? It would probably need to specify the valueization
> hook to follow SSA edges beyond the sequence we’re currently building.
Jeff has a
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap failed in comparison failure on cp/module.o, because
Solaris date doesn't support the -r option and one stage's cp/module.o
was built before midnight
On Tue, 4 Apr 2023, Jan Hubicka wrote:
> > On Tue, 28 Mar 2023, Richard Biener wrote:
> >
> > > When adjusting calls to reflect instrumentation we failed to handle
> > > calls to aliases since they appear to have no body. Instead resort
> > > to symtab node availability. The patch also avoids t
On Tue, 4 Apr 2023, Jan Hubicka wrote:
> > On Tue, Apr 04, 2023 at 01:21:40AM +0200, Jan Hubicka via Gcc-patches wrote:
> > > It is however really side case and I am worried about dropping
> > > pure/const from builtin declarations...
> >
> > Yeah, that can certainly break stuff. See e.g. the re
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed either type of the comparison
operands, or even
On Mon, Apr 3, 2023 at 10:46 AM Martin Liška wrote:
>
> The revision r13-259-g76db543db88727 moved a condition from one
> file to another, but now we do not drop x_flag_var_tracking_assignments
> as it was done before the mentioned revision.
>
> Patch can bootstrap on x86_64-linux-gnu and survives
On Mon, Apr 3, 2023 at 11:03 AM Martin Liška wrote:
>
> Hi.
>
> The patch propagates noreturn attribute for MV functions. However, I noticed
> we've got the following ICE when we do the same for TREE_READONLY attr:
>
> $ cat tc.c
> double bar() __attribute__((target_clones("avx,avx2,avx512f,defaul
On Tue, 4 Apr 2023, David Malcolm wrote:
> Richi, Jakub: I can probably self-approve this, but it's technically a
> new feature. OK if I push this to trunk in stage 4? I believe it's
> low risk, and is very useful for benchmarking -fanalyzer.
Please wait for stage1 at this point. One comment o
On Wed, Apr 5, 2023 at 10:39 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> Hi,
> For the following test:
>
> svint32_t f(svint32_t v)
> {
> return svrev_s32 (svrev_s32 (v));
> }
>
> We generate 2 rev instructions instead of nop:
> f:
> rev z0.s, z0.s
> rev z0.s, z0.s
On Wed, 5 Apr 2023, Andre Vieira (lists) wrote:
> Hi,
>
> The original patch to fix this PR broke the if-conversion of calls into
> IFN_MASK_CALL. This patch restores that original behaviour and makes sure the
> tests added earlier specifically test inbranch SIMD clones.
OOps.
> Bootstrapped a
On Wed, Apr 5, 2023 at 3:53 PM wrote:
>
> >> So fusion in this context is really about identifying cases where two
> >> configuration settings are equivalent and you "fuse" them together.
> >> Presumably this is only going to be possible when the vector insns are
> >> just doing data movement rath
On 4/11/23 10:21, Jakub Jelinek wrote:
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed eit
On Wed, Apr 5, 2023 at 4:06 PM wrote:
>
> Hi everyone,
>
> This patchset contains around 80 commits concerning the Rust frontend.
>
> We have been hard at work trying to get the Rust core library to
> compile, and hope to push more commits in the coming days as we try
> and upstream a more recent
Hi Kewen,
Thanks a lot for your very helpful comments!
On 2023-04-10 17:26, Kewen.Lin wrote:
Hi Jeff,
on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
Hi,
In this test case (float128-cmp2-runnable.c), the instruction
xscmpexpqp is used to support a few builtins e.g.
__builtin_vsx_scalar_
On Mon, Apr 10, 2023 at 11:14:46PM +0800, juzhe.zh...@rivai.ai wrote:
> ARM SVE has:svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
> However, for RVV not only has vint8m1_t, vint8m1x2_t, vint8m1x3_t,
> vint8m1x4_t, vint8m1x5_t, vint
No, we can only pass "available" to LCM.
Passing "compatible" to LCM can not work for us.
LCM can only help for eliminate vsetvls can not help for fuse vsetvls.
For example:
bb 0:
vsetvl e8,mf8
vadd (Demand SEW = 8, LMUL = MF8)
bb 1:
vsetvl e32 mf2
vle32 (Demand RATIO (SEW/LMUL) = 64, so availab
On Wed, Apr 5, 2023 at 11:53 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 4/5/23 14:10, Andrew MacLeod via Gcc-patches wrote:
> > When a statement is first processed, any SSA_NAMEs that are dependencies
> > are cached for quick future access.
> >
> > if we ;later rewrite the statement (say propag
On Thu, Apr 6, 2023 at 3:58 PM Martin Liška wrote:
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed after stage1 opens?
Did we release a compiler with version 1? If not we might want to sneak
this in before 13.1 ...
Up to Honza.
Thanks,
Richa
On Mon, Mar 27, 2023 at 6:02 PM Kevin Lee wrote:
>
> This patch is a proper fix to the previous patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
> vect_grouped_store_supported checks if the count is a power of 2, but
> doesn't check the size of the GET_MODE_NUNITS.
> This s
Hi Jeff,
on 2023/4/11 17:14, guojiufu wrote:
> Hi Kewen,
>
> Thanks a lot for your very helpful comments!
>
> On 2023-04-10 17:26, Kewen.Lin wrote:
>> Hi Jeff,
>>
>> on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
>>> Hi,
>>>
>>> In this test case (float128-cmp2-runnable.c), the instruction
Hi Evandro,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Evandro
> Menezes via Gcc-patches
> Sent: Friday, April 7, 2023 11:34 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Evandro Menezes ; Richard Sandiford
>
> Subject: [PATCH] aarch64: Add
I am not sure whether aggregate type without a tuple mode can work for us.
Here is the example:
We already had a vector type "vint8mf8_t", the corresponding mode is VNx1SImode.
Now we have an intrinsic as following:
vint8mf8x2_t test_vlseg2e8_v_i8mf8(const int8_t *base, size_t vl) {
return __ri
writes:
> ARM SVE has:svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
Yeah, there are no separate types for partial vectors, but there
are separate modes. E.g. VNx2QI is a partial vector of QIs,
with each QI stored in a 64-bit cont
On Tue, Apr 11, 2023 at 10:46:25AM +0100, Richard Sandiford wrote:
> I agree with all the comments about the danger of growing the number of
> modes too much. But it looks like rtx_def should be easy to rearrange.
> Unless I'm missing something, there are less than 256 rtx codes at
> present. So
On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote:
writes:
ARM SVE has:svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
As far as I known, they don't have tuple type for partial vector.
Yeah, there are no separate types for partial vectors, but there
are separate modes. E.g. VNx2QI
Richard Biener via Gcc-patches writes:
> On Mon, Mar 27, 2023 at 6:02 PM Kevin Lee wrote:
>>
>> This patch is a proper fix to the previous patch
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
>> vect_grouped_store_supported checks if the count is a power of 2, but
>> doesn't
May RTX code grow faster than machine mode ?
Since RTX code grows target independent wheras
machine mode grows target dependent.
In the future, we may easily have more and more targets that some target may
have a lot of machine mode.
Maybe Richard Sandiford suggestion is a good idea to fix it?
On Tue, Apr 11, 2023 at 05:46:15PM +0800, juzhe.zh...@rivai.ai wrote:
> I am not sure whether aggregate type without a tuple mode can work for us.
> Here is the example:
>
> We already had a vector type "vint8mf8_t", the corresponding mode is
> VNx1SImode.
>
> Now we have an intrinsic as followi
Richard Earnshaw writes:
> On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote:
>> writes:
>>> ARM SVE has:svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
>>> As far as I known, they don't have tuple type for partial vector.
>>
>> Yeah, there are no separate types for partial vectors, but
Explicit sets multiple VNx1SImode with multiple dest operand and let RA to
assign them with continguous regsiters
will make RTL patterns in RVV hard to maintain.
Assume we have a new pattern flag to tell RA assign continguous registers for
multiple dest operand, and RA can handle this:
in RVV, w
gcc/Changelog:
* gcc/config/arm/arm.cc(arm_print_asm_arch_directives): fix compatability
typo
* gcc/fortran/gfortran.texi(intrinsics): fix compatability typo
* gcc/fortran/invoke.texi(-fdec-math): fix compatability typo
* gcc/m2/gm2-compiler/M2Base.def(CannotCheckTypeInPass3): fix
comp
On Tue, 11 Apr 2023, Jakub Jelinek wrote:
> On Wed, Apr 05, 2023 at 02:11:08PM +0200, Richard Biener wrote:
> > Ok, but maybe there?s a gimple_build overload that meanwhile implements
> > the desired semantics? It would probably need to specify the valueization
> > hook to follow SSA edges beyond
On Tue, Apr 11, 2023 at 06:25:58PM +0800, juzhe.zh...@rivai.ai wrote:
> Explicit sets multiple VNx1SImode with multiple dest operand and let RA to
> assign them with continguous regsiters
> will make RTL patterns in RVV hard to maintain.
Not necessarily. It can be handled through define_subst.
On Tue, 11 Apr 2023, Richard Sandiford wrote:
> writes:
> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> > As far as I known, they don't have tuple type for partial vector.
>
> Yeah, there are no separate types for partial vectors, but there
> are separate modes. E.g. VNx2QI is a
Richard Biener writes:
> On Tue, 11 Apr 2023, Richard Sandiford wrote:
>
>> writes:
>> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
>> > As far as I known, they don't have tuple type for partial vector.
>>
>> Yeah, there are no separate types for partial vectors, but there
>> are s
9 bit (512 modes) mode should be enough for RVV.
In the future, I would expect we will have BF16 vector, FP16 vector,.. matrix
modes.
And I think it will not be more 512 modes in the future.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-04-11 19:11
To: Richard Biener
CC: juzhe.zhong
On Tue, Apr 11, 2023 at 11:19 AM juzhe.zh...@rivai.ai
wrote:
>
> No, we can only pass "available" to LCM.
> Passing "compatible" to LCM can not work for us.
>
> LCM can only help for eliminate vsetvls can not help for fuse vsetvls.
>
> For example:
>
> bb 0:
> vsetvl e8,mf8
> vadd (Demand SEW = 8,
Commit r13-7137 fixes thethe dump issue with -m32, cf. attachment.
Tobias
On 09.04.23 00:11, haochen.jiang via Gcc-patches wrote:
Fortran: Fix dg directives and remove trailing whitespaces in testsuite
caused
FAIL: gfortran.dg/gomp/affinity-clause-1.f90 -O scan-tree-dump-times original
Oh, sorry for didn't explain this clearly.
In this example, the "vle32" should be using same VL as "vadd" that I didn't
mention.
But we do have other instructions doesn't care about VL operand. So let me
explain more clearly.
Same example I repeated again:
Loop:
{
bb 0:
vsetvl VL, e8,mf8,TA
vadd
From: Yanzhang Wang
This patch registers a riscv specific function to
TARGET_ZERO_CALL_USED_REGS instead of default in targhooks.cc. It will
clean gpr and vector relevant registers.
PR 109104
gcc/ChangeLog:
* config/riscv/riscv-protos.h (emit_hard_vlmax_vsetvl):
* confi
Hi Kito, Juzhe, Jeff,
Thanks for your kindly reviews. I have modified based on the comments and ran
the testsuite on my local. Could you please take another look ? If any more
comments please let me know.
Thanks
Yanzhang
> -Original Message-
> From: Wang, Yanzhang
> Sent: Tuesday, Apr
Hi, Richards.
Kindly Ping this patch.
This is the most important patch for RVV auto-vectorization support.
Bootstraped on X86 has passed.
Feel free to comments.
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-04-07 09:47
To: gcc-patches
CC: richard.sandiford; rguenther; jeffreyalaw
"juzhe.zh...@rivai.ai" writes:
> Hi, Richards.
> Kindly Ping this patch.
> This is the most important patch for RVV auto-vectorization support.
> Bootstraped on X86 has passed.
Can it wait for GCC 14? It doesn't seem like stage 4 material.
Also, pinging after 5 days seems a bit soon. It's be
Hi, Joseph and Jakub,
This is the 2nd ping to the 6th version of the patches -:)
Please let me know if you have any further comments on the patches, and whether
it’s Okay to commit them to trunk?
Thanks a lot for the help.
Qing
Begin forwarded message:
From: Qing Zhao mailto:qing.z...@oracle
Hi, Jakub,
This is the 2nd ping to the 6th version of the patches -:)
Please let me know if you have any further comments on this patch, and whether
it’s Okay to commit it to trunk?
Thanks a lot for the help.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@
Hi, Joseph,
This is the 2nd ping to the 6th version of the patch -:)
Please let me know if you have any further comments on the patch, and whether
it’s Okay to commit it to trunk?
Thanks a lot for the help.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc
Let me give more explanation why RISC-V vector need so many modes than AArch64.
The following will use "RVV" as an abbreviation for "RISC-V Vector"
instructions.
There are two key points here:
- RVV has a concept called LMUL - you can understand that as register
grouping, we can group up to 8 ad
On Tue, 11 Apr 2023 at 14:17, Richard Biener wrote:
>
> On Wed, Apr 5, 2023 at 10:39 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > Hi,
> > For the following test:
> >
> > svint32_t f(svint32_t v)
> > {
> > return svrev_s32 (svrev_s32 (v));
> > }
> >
> > We generate 2 rev instructions
Hi Yanzhang:
Thanks, applied to trunk now, and also congrats for your first patch on GCC!
On Tue, Apr 11, 2023 at 8:00 PM Wang, Yanzhang wrote:
>
> Hi Kito, Juzhe, Jeff,
>
> Thanks for your kindly reviews. I have modified based on the comments and ran
> the testsuite on my local. Could you plea
On Thu, 26 Jan 2023, Jason Merrill wrote:
> On 1/25/23 15:35, Patrick Palka wrote:
> > On Tue, 17 Jan 2023, Jason Merrill wrote:
> >
> > > On 1/9/23 14:25, Patrick Palka via Gcc-patches wrote:
> > > > On Mon, 9 Jan 2023, Patrick Palka wrote:
> > > >
> > > > > On Wed, 5 Oct 2022, Patrick Palka wr
Hi Jerry, all,
On 4/11/23 02:43, Jerry D via Gcc-patches wrote:
On 4/10/23 1:49 PM, Harald Anlauf via Fortran wrote:
Dear all,
when comparing formal and actual arguments of a procedure, there was no
check of rank for derived types from intrinsic module ISO_C_BINDING.
This could lead to a wrong
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/12?
libstdc++-v3/ChangeLog:
* include/std/ranges (lazy_split_view::_OuterIter::_OuterIter):
Propagate _M_trailing_empty in the const-converting constructor
as per LWG 3904.
* testsuite/std/ranges/adaptors/a
Tested on x86_64-pc-linux-gnu, does this look OK for trunk perhaps?
libstdc++-v3/ChangeLog:
* include/std/ranges (__cpp_lib_ranges_enumerate): Define
for C++23.
(__detail::__range_with_movable_reference): Likewise.
(enumerate_view): Likewise.
(enumerate_vie
On Tue, 11 Apr 2023 at 15:58, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/12?
OK for all, thanks.
(This hasn't been approved by LWG yet, but it should be soon.)
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (lazy_split_view::_
On Tue, 11 Apr 2023 at 15:59, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk perhaps?
Yes, this is only for C++23 so OK for trunk now.
The auto(x) uses mean this won't work with older versions of Clang,
but that's OK. I already introduced that d
On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
> on 2023/4/11 17:14, guojiufu wrote:
> > Thanks for raising this concern.
> > The behavior to check about bif on FLOAT128_HW and emit an error message for
> > requirements on quad-precision is added in gcc12. This is why gcc12 fails to
> >
On 4/10/23 14:59, Philipp Tomsich wrote:
On Mon, 10 Apr 2023 at 17:57, Jeff Law wrote:
On 4/9/23 23:07, Lin Sinan via Gcc-patches wrote:
From: Sinan Lin
there is no need to split an xori/ori with an small constant. take the test
case `int foo(int idx) { return idx|3; }` as an example,
On 4/9/23 23:07, Lin Sinan via Gcc-patches wrote:
From: Sinan Lin
there is no need to split an xori/ori with an small constant. take the test
case `int foo(int idx) { return idx|3; }` as an example,
rv64im_zba generates:
ori a0,a0,3
ret
but, rv64im_zba_zbs generates:
Ok, here is another attempt on fixing issues with size expression.
Not all are regressions, but it does not make sense to try to split
it up.
Martin
Fix ICEs related to VM types in C [PR106465, PR107557, PR108424,
PR109450]
Size expressions were sometimes lost and not gimpl
On Tue, Apr 11, 2023 at 11:47 AM Martin Uecker via Gcc-patches
wrote:
>
>
>
> Ok, here is another attempt on fixing issues with size expression.
> Not all are regressions, but it does not make sense to try to split
> it up.
They might be regressions still from pre gimple (3.4 and before),
though
The test case that was added is rv64i-specific, as there's better ways
to generate this code on rv32i (where the long/int cast is a NOP) and on
rv64i_zba (where we have word shifts). This renames the original test
case and adds two more for those targets.
gcc/testsuite/ChangeLog:
PR targe
Hi!
On 2022-12-06T14:47:26+, Gaius Mulley via Gcc-patches
wrote:
> This patch set consists of the libgm2 makefile, autoconf sources
> necessary to build the libm2pim, libm2iso, libm2min, libm2cor
> and libm2log.
Notice:
> --- /dev/null 2022-08-24 16:22:16.88870 +0100
> +++ gcc-git-deve
Dear all,
the testcase in the PR by Gerhard exhibited a mis-treatment of
the function decl of the entry master if the function result
had a pointer attribute and the translation unit was compiled
with -ff2c. We actually should not use the peculiar special
treatment for default-real functions in t
These functions are NOPs on the soft-float ABIs. Since we're already
forcing the ISA, let's just force the ABI too.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadfmv-fmv.c: Force the ilp32d ABI.
---
This one is also in the testing queue. OK for trunk?
---
gcc/testsuite/gcc.target/r
On 4/11/23 04:21, Jakub Jelinek wrote:
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed eithe
On 4/11/23 13:03, Palmer Dabbelt wrote:
The test case that was added is rv64i-specific, as there's better ways
to generate this code on rv32i (where the long/int cast is a NOP) and on
rv64i_zba (where we have word shifts). This renames the original test
case and adds two more for those target
On 4/11/23 14:10, Palmer Dabbelt wrote:
These functions are NOPs on the soft-float ABIs. Since we're already
forcing the ISA, let's just force the ABI too.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadfmv-fmv.c: Force the ilp32d ABI.
---
This one is also in the testing queue.
On 4/11/23 02:55, Richard Biener wrote:
Just to throw in a comment here - I think you should present LCM
with something it can identify as the same for compatible vsetvl and
then it should just work? OTOH if "compatible" is not transitive
that's not possible (but then I can't quickly make u
On 4/11/23 04:12, Jakub Jelinek wrote:
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap failed in comparison failure on cp/module.o, because
Solaris date doesn't support the -r option and one stage
Jakub,
for avoidance of doubt, your version is fine.
nathan
On 4/11/23 18:06, Nathan Sidwell wrote:
On 4/11/23 04:12, Jakub Jelinek wrote:
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap faile
I don't want to seperate VSETVL PASS into 2 seperate PASS.
I want make everything cleaner.
Another example is VSETVL PASS can do the branch prediction:
https://godbolt.org/z/K44r98E5v
In function "f", you can see we put the hoist vsetvl from a more likely block
(i !=cond) outside the loop,
then
On 4/11/23 17:09, juzhe.zh...@rivai.ai wrote:
I don't want to seperate VSETVL PASS into 2 seperate PASS.
I want make everything cleaner.
Well, two pass vsetvl might actually be cleaner. But as I've noted
before, now is not the time to debate the vsetvl implementation detail.
We've got much
This is a carry over from PR 108139.
When we have a PHI node which has 2 arguments and one is undefined, we
create an equivalence between the LHS and the non-undefined PHI
argument. THis allows us to perform certain optimizations.
The problem is, when we are evaluating range-on-entry in the
On Tue, 11 Apr 2023, Martin Uecker via Gcc-patches wrote:
> Ok, here is another attempt on fixing issues with size expression.
> Not all are regressions, but it does not make sense to try to split
> it up.
This wording implies this is version 2 or later of the patch, could you
please give a refe
On 4/10/23 01:10, Jakub Jelinek wrote:
On Sat, Apr 08, 2023 at 06:25:32PM -0600, Jeff Law wrote:
On 4/6/23 08:21, Eric Botcazou wrote:
So, perhaps just in the return op0; case add further code for
WORD_REGISTER_OPERATIONS and sub-word modes which will call nonzero_bits
again for the word m
Hi,
This patch xfails a float128 comparison test case on powerpc64 that
fails due to a longstanding issue with floating-point compares.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more
information.
The patch passed regression test on Power Linux platforms.
Thanks
Gui Haochen
Am Mittwoch, dem 12.04.2023 um 00:32 + schrieb Joseph Myers:
> On Tue, 11 Apr 2023, Martin Uecker via Gcc-patches wrote:
>
> > Ok, here is another attempt on fixing issues with size expression.
> > Not all are regressions, but it does not make sense to try to split
> > it up.
>
> This wording
Hi,
Segher Boessenkool writes:
> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>> on 2023/4/11 17:14, guojiufu wrote:
>> > Thanks for raising this concern.
>> > The behavior to check about bif on FLOAT128_HW and emit an error message
>> > for
>> > requirements on quad-precision is
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Segher Boessenkool writes:
>
>> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>>> on 2023/4/11 17:14, guojiufu wrote:
>>> > Thanks for raising this concern.
>>> > The behavior to check about bif on FLOAT128_HW and emit an error message
>>
Hi,
The case file-CWE-1341-example.c checkes [CWE-1341](`double-fclose`).
While on some systems, besides [CWE-1341], a message of [CWE-415] is
also reported. On those systems, attribute `malloc` may be attached on
fopen:
```
# 258 "/usr/include/stdio.h" 3 4
extern FILE *fopen (const char *__restri
On Tue, Apr 11, 2023 at 07:26:07PM -0600, Jeff Law wrote:
> I did bootstrap on riscv, but not a regression test, that's spinning right
> now.
>
> Jeff
> diff --git a/gcc/combine.cc b/gcc/combine.cc
> index 22bf8e1ec89..c41d8a09b3b 100644
> --- a/gcc/combine.cc
> +++ b/gcc/combine.cc
> @@ -10055,9
The following avoids an SLP region starting with a returns-twice
call where we cannot insert stmts at the head.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/109469
* tree-vect-slp.cc (vect_slp_function): Skip region starts with
a return
The byte tracking of call LHS didn't properly handle possibly
throwing calls correctly which cases bogus DSE and in turn, for the
testcase a bogus uninit diagnostic and (unreliable) wrong-code.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/109434
Hi Harald,
The patch looks good to me - OK for mainline.
Thanks
Paul
On Tue, 11 Apr 2023 at 21:12, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the testcase in the PR by Gerhard exhibited a mis-treatment of
> the function decl of the entry master if the function result
> had a pointer at
84 matches
Mail list logo