Hi Richard,
On 1/23/24 08:23, Richard Biener wrote:
On Mon, Jan 22, 2024 at 7:51 PM Arthur Cohen wrote:
Hi everyone,
In order to increase the development speed of Rust features, we are
seeking feedback on reusing some Rust components directly within our
front-end. As mentioned in other
Hi Arthur,
> On 25 Jan 2024, at 15:03, Arthur Cohen wrote:
> On 1/23/24 08:23, Richard Biener wrote:
>> On Mon, Jan 22, 2024 at 7:51 PM Arthur Cohen
>> wrote:
>>>
>>> Hi everyone,
>>>
>>> In order to increase the development speed of Rust features, we are
>>> seeking feedback on reusing
Note that it may not make sense to include a source copy of rustc, as that
will itself require an (earlier) stage of rustc to build. mrustc can offer
a bootstrap for 1.54, but depending on the versions required, you may need
upwards of 10 additional rustc sources.
On Thu, 25 Jan 2024 at 10:04,
> Am 25.01.2024 um 16:03 schrieb Arthur Cohen :
>
> Hi Richard,
>
>> On 1/23/24 08:23, Richard Biener wrote:
>>> On Mon, Jan 22, 2024 at 7:51 PM Arthur Cohen
>>> wrote:
>>>
>>> Hi everyone,
>>>
>>> In order to increase the development speed of Rust features, we are
>>> seeking feedback
Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes
On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote:
>
> Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
> > On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
> >>
> >> Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
> >>> Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
> On Fri, Jan
Snapshot gcc-11-20240125 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20240125/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #4 from John Sanpe ---
(In reply to Andrew Pinski from comment #1)
> Why do you think this is a bug?
>
> You are forcing a function which calls alloca to be inlined, GCC DOES not
> normally inline functions which call alloca due to
Andrew Pinski writes:
> The split for movv8di is not ready to handle the case where the setting
> register overlaps with the address of the memory that is being load.
> Fixing the split than just making the output constraint as an early clobber
> for this alternative. The split would first need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #3 from
Hi David,
> On 24 Jan 2024, at 18:31, David Malcolm wrote:
>
> On Tue, 2024-01-16 at 11:10 +, Iain Sandoe wrote:
>> Tested on x86_64, i686 Darwin and x86_64 Linux,
>> OK for trunk? when ?
>> thanks,
>> Iain
>
> Hi Iain, thanks for the patch.
>
> I'll have to defer to your Darwin expertise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #10 from Richard Biener ---
Created attachment 57212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57212=edit
patch for debugging
Btw, I've used the attached to investigate other issues with the change. It
will show the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:f251bbfec9174169510b2dec14b9bf763e7b77af
commit r14-8420-gf251bbfec9174169510b2dec14b9bf763e7b77af
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113550
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:8eead1148cd0ac086b39a7abccea404041c85cb5
commit r14-8421-g8eead1148cd0ac086b39a7abccea404041c85cb5
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:c3de14ba1ba0e77254118af64ed881f115ee42a0
commit r14-8422-gc3de14ba1ba0e77254118af64ed881f115ee42a0
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Some programing styles use a lot of inline assembler, and it is common
to use very complex preprocessor macros to generate the assembler
strings for the asm statements. In C++ there would be a typesafe alternative
using templates and constexpr to generate the assembler strings, but
unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113538
--- Comment #1 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:acc22d56e140220e7dc6c138918cb6754b6d1c0b
commit r14-8424-gacc22d56e140220e7dc6c138918cb6754b6d1c0b
Author: Yanzhang Wang
Date: Thu Jan
Committed, thanks Juzhe.
Pan
From: juzhe.zhong
Sent: Thursday, January 25, 2024 9:08 PM
To: Wang, Yanzhang
Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; Li, Pan2
; Wang, Yanzhang
Subject: Re: [PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]
lgtm
Replied Message
This patch series presents the comprehensive implementation of the MEM
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
However, your input, reviews, and suggestions are invaluable
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
*
This patch series presents the comprehensive implementation of the BITMANIP
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
However, your input, reviews, and suggestions are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #19 from rguenther at suse dot de ---
On Thu, 25 Jan 2024, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
>
> --- Comment #18 from Richard Sandiford ---
> (In reply to Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
Bug ID: 113596
Summary: Stack memory leakage caused by inline alloca
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113522
--- Comment #6 from Jonathan Wakely ---
I'd also like to ban it for std::make_pair, but that would break loads of very
silly code that does std::make_pair(a,b) (c.f. Bug 92300 comment 3).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113577
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
When generalising vector_cst_all_same, I'd forgotten to update
VECTOR_CST_ENCODED_ELT to VECTOR_CST_ELT. The check deliberately
looks at implicitly encoded elements in some cases.
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/
PR target/113572
*
This patch avoids assembler warnings for gfx908 and gfx90a such as
'-xnack-mattr=-sramecc' is not a recognized feature for this target(ignoring
feature)
as we pass -mattr=-xnack-mattr=-sramecc to the llvm-mc assembler.
Solution: Add a space before the second '-mattr='.
OK for mainline?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #18 from Richard Sandiford ---
(In reply to Tamar Christina from comment #17)
> Well the mid-end has generated the right precision. The type it generates is
> vector(4) vexit_reduc_67;
> so it does say it's a single bit boolean.
>
Hi Mike,
on 2024/1/6 07:38, Michael Meissner wrote:
> The MMA subsystem added the notion of accumulator registers as an optional
> feature of ISA 3.1 (power10). In ISA 3.1, these accumulators overlapped with
> the traditional floating point registers 0..31, but logically the accumulator
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #7 from Richard Biener ---
In theory, if somebody really wanted it, we could replace alloca with
__builtin_stack_save/restore during inlining (not sure if it would
simply work, and be efficient, by just putting save at the start of
> On Jan 24, 2024, at 18:40, Richard Biener wrote:
>
> We can't support niters with may_be_zero when we end up with a
> non-empty latch due to early exit peeling. At least not in
> the simplistic way the vectorizer handles this now. Disallow
> it again for exits that are not the last one.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
Bug ID: 113597
Summary: [14 Regression] aarch64: Significant code quality
regression since r14-8346-ga98d5130a6dcff
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #1 from Richard Biener ---
I will have a look - but can you explain for me what I see? I suppose the
testcase was reduced from something?
Is the assembly diff complete? That is, do we really have more fmla or
are they just moved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113574
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113574
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fb1b7e2fec951ba0bf4f68fac6a16929f4f63910
commit r14-8423-gfb1b7e2fec951ba0bf4f68fac6a16929f4f63910
Author: Jakub Jelinek
Date:
From: Yanzhang Wang
Also adjust some of the tests for scan-assembly. The behavior is the
same as --param=riscv-vector-abi before.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag.
(riscv_fntype_abi): Ditto.
* config/riscv/riscv.opt: Ditto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #11 from Richard Biener ---
In DSE the only differences is
fbt (0x751a1a50: (plus:DI (reg/v/f:DI 117 [ u ])
-(reg:DI 146 [ _44 ]))) == (address 0)
+(reg:DI 146 [ _44 ]))) == (nil)
fbt (0x7700b3c0: (reg/f:DI 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
Bug ID: 113600
Summary: 525.x264_r run-time regresses by 8% with PGO -Ofast
-march=znver4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 57215 [details]
> gcc14-pr113596.patch
>
> Untested patch to do that.
> The disadvantage of doing that is that it may penalize inline
Confusion in binding_cluster::maybe_get_compound_binding about whether
offsets are relative to the start of the region or to the start of the
cluster was leading to incorrect handling of default values, leading
to false positives from -Wanalyzer-use-of-uninitialized-value, from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #13 from Richard Sandiford ---
I don't think there's any principle that upper bits must be zero.
How do we end up with a pattern that depends on that being the case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588
--- Comment #4 from Tamar Christina ---
The change Richi made this morning to only allow may_be_zero for the last exit
makes it not rotate this loop anymore.
However the bug is simply that if the final exit has a memory access it should
be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #4 from Alex Coplan ---
Created attachment 57211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57211=edit
after.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #13 from Richard Biener ---
(In reply to Robin Dapp from comment #12)
> Created attachment 57209 [details]
> Tentative
>
> I tested the attached "fix". On my machine with 13.2 host compiler it
> reduced the build time for
It's stage 4, so I think it would be great to not disturb code base
too much, and adding intrinsic without adding VLS modes should be
better way to go, and here is not really something serious coding
style issue, just few minor indentation issue, so I gonna run
regression to make not break
Recent commit introduced a conditional branch in eh_return epilogues
that is not compatible with speculation tracking:
commit 426fddcbdad6746fe70e031f707fb07f55dfb405
Author: Szabolcs Nagy
CommitDate: 2023-11-27 15:52:48 +
aarch64: Use br instead of ret for eh_return
Refactor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #8 from Richard Biener ---
(In reply to JuzheZhong from comment #7)
>
> But I wonder if we see it is beneficial on some boards, could you teach us
> how we can enable vectorization for such case according to uarchs ?
If you figure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
--- Comment #15 from Maxim Kuvyrkov ---
(In reply to Maxim Kuvyrkov from comment #13)
> We are seeing scan-assembler failures in a single 32-bit arm test. This
> affects both linux and bare-metal targets: arm-linux-gnueabihf and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #5 from John Sanpe ---
(In reply to Andrew Pinski from comment #3)
> The documentation should be more clear on this though.
But adding a hint would also be reasonable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Hongtao Liu changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
On 24/01/2024 22:12, Tobias Burnus wrote:
This patch fixes "-g" debug compilation for gfx1100 and gfx1030,
which fail to link when "-g" is specified. The reason is:
When using gfx1100 and compiling with '-g' I was running into an error
because the eflags used for the debugger file has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
--- Comment #10 from Andrew Pinski ---
The instruction increase is 2:
sub sp, sp, #128
...
stp x29, x30, [sp, 112]
vs:
stp x29, x30, [sp, -128]!
and
ldp x29, x30, [sp, 112]
...
add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #5 from Andrew Pinski ---
Note I think this testcase has been reduced too much, but maybe that can be
"fixed". The stores to the arguments go past the bounds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #6 from Alex Coplan ---
Looking at the dump files, the first difference seems to be in 292r.dse1:
8: NOTE_INSN_BASIC_BLOCK 2
2: r116:SI=zero_extend(x0:HI)
REG_DEAD x0:HI
@@ -178,7 +161,26 @@
5:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #9 from Alex Coplan ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Alex Coplan from comment #7)
> > I expect the store pairs come from memcpy lowering/expansion in the aarch64
> > backend, that is the only way we get
On 25/01/2024 10:29, Maxim Kuvyrkov wrote:
> After fwprop improvement in r14-8319-g86de9b66480, codegen in
> bics_3.c test changed from "bics" to "bic" instruction, with
> the overall instruction stream remaining at the same quality.
>
> This patch makes the scan-assembler directive accept both
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-01-25
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #2
Szabolcs Nagy writes:
> Recent commit introduced a conditional branch in eh_return epilogues
> that is not compatible with speculation tracking:
>
> commit 426fddcbdad6746fe70e031f707fb07f55dfb405
> Author: Szabolcs Nagy
> CommitDate: 2023-11-27 15:52:48 +
>
> aarch64: Use br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #9 from Jakub Jelinek ---
Created attachment 57215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57215=edit
gcc14-pr113596.patch
Untested patch to do that.
The disadvantage of doing that is that it may penalize inline calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
--- Comment #5 from Iain Sandoe ---
(In reply to Rainer Orth from comment #4)
> On macOS 11, everything is still fine. On macOS 14, there's progress:
> The remaining failures fall into two categories:
>
> FAIL: obj-c++.dg/encode-10.mm
pushed :)
On Thu, Jan 25, 2024 at 9:53 PM Kito Cheng wrote:
>
> It's stage 4, so I think it would be great to not disturb code base
> too much, and adding intrinsic without adding VLS modes should be
> better way to go, and here is not really something serious coding
> style issue, just few
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112969
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:6426d466779fa889bca170e3ff80dbfc6ea8c2e8
commit r14-8428-g6426d466779fa889bca170e3ff80dbfc6ea8c2e8
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #2 from Andrew Pinski ---
You could instead use VLA which is done correctly though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113522
--- Comment #7 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #6)
> I'd also like to ban it for std::make_pair, but that would break loads of
> very silly code that does std::make_pair(a,b) (c.f. Bug 92300 comment
> 3).
Note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113590
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #3 from Alex Coplan ---
Created attachment 57210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57210=edit
before.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113550
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
This patch fixes the recent noticed bug in RV32 glibc.
We incorrectly deleted a vsetvl:
...
and a4,a4,a3
vmv.v.i v1,0 ---> Missed vsetvl cause illegal
instruction report.
vse8.v v1,0(a5)
The root cause the laterin in LCM is incorrect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598
Bug ID: 113598
Summary: GCC internal compiler error
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113422
--- Comment #2 from Jan Hubicka ---
Cycling read-only var discovery would be quite expensive, since you need to
interleave it with early opts each round. I wonder how llvm handles this?
I think there is more hope with IPA-PTA getting scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #17 from Tamar Christina ---
Well the mid-end has generated the right precision. The type it generates is
vector(4) vexit_reduc_67;
so it does say it's a single bit boolean.
Isn't this just an expand problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113538
Yanzhang, Wang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
On Wed, Jan 24, 2024 at 4:50 PM Georg-Johann Lay wrote:
>
>
>
> Am 22.01.24 um 08:45 schrieb Richard Biener:
> > On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote:
> >>
> >>
> >>
> >> Am 18.01.24 um 20:54 schrieb Roger Sayle:
> >>>
> >>> This patch tweaks RTL expansion of multi-word shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113522
--- Comment #5 from Jonathan Wakely ---
(In reply to Jiang An from comment #4)
> Hmm... currently it's specified in [algorithms.requirements] that
> > The well-formedness and behavior of a call to an algorithm with an
> > explicitly-specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #1 from Andrew Pinski ---
Why do you think this is a bug?
You are forcing a function which calls alloca to be inlined, GCC DOES not
normally inline functions which call alloca due to not restoring the stack
pointer after the return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Maxim Kuvyrkov changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113592
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
John Sanpe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
After fwprop improvement in r14-8319-g86de9b66480, codegen in
bics_3.c test changed from "bics" to "bic" instruction, with
the overall instruction stream remaining at the same quality.
This patch makes the scan-assembler directive accept both
"bics" and "bic".
BEFORE r14-8319-g86de9b66480:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227
Andrew Pinski changed:
What|Removed |Added
CC||usaxena95 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #7 from Alex Coplan ---
I expect the store pairs come from memcpy lowering/expansion in the aarch64
backend, that is the only way we get store pairs so early in the RTL pipeline
IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #8 from Andrew Pinski ---
(In reply to Alex Coplan from comment #7)
> I expect the store pairs come from memcpy lowering/expansion in the aarch64
> backend, that is the only way we get store pairs so early in the RTL
> pipeline
g:74e3e839ab2d36841320 handled the UXTL{,2}-ZIP[12] optimisation
in split1. The UXTL input is a 64-bit vector of N-bit elements
and the result is a 128-bit vector of 2N-bit elements. The
corresponding ZIP1 operates on 128-bit vectors of N-bit elements.
This meant that the ZIP1 input had to be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Bug ID: 113599
Summary: Wrong computation of member offset through
pointer-to-member
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Thanks.
Can we please agree on some wording to use so I know when the patch can
be pushed. Especially since we're now in stage 4, it would help me if
you say something like "you can push to master".
Regards.
On Wed, 2024-01-24 at 12:14 -0500, David Malcolm wrote:
> On Fri, 2024-01-19 at 16:55
lgtm Replied Message Fromyanzhang.w...@intel.comDate01/25/2024 21:06 Togcc-patches@gcc.gnu.org Ccjuzhe.zh...@rivai.ai,kito.ch...@sifive.com,pan2...@intel.com,yanzhang.w...@intel.comSubject[PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
--- Comment #3 from Jakub Jelinek ---
The problem is in that typeck2.cc change:
- datum = fold_build_pointer_plus (fold_convert (ptype, datum),
component);
+ datum = cp_convert (ptype, datum, complain);
+ if
Use this reduced testcase, but please verify this in your end again.
For the code change part, I would like to let other to review :P
struct a {
int b;
int c : 1;
int : 1;
} d();
typedef struct
{
int e;
struct {
int f;
};
} g;
int i;
char k, l, n;
void *m;
char *o;
void h();
char *j();
On 25/01/2024 12:44, Tobias Burnus wrote:
This patch avoids assembler warnings for gfx908 and gfx90a such as
'-xnack-mattr=-sramecc' is not a recognized feature for this target(ignoring
feature)
as we pass -mattr=-xnack-mattr=-sramecc to the llvm-mc assembler.
Solution: Add a space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #11 from Jakub Jelinek ---
In reply to Richard Biener from comment #10)
> We can make ->calls_alloca more precise though of course
> we usually also do not want to inline functions with VLAs.
Yes. Or remember while inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #14 from Robin Dapp ---
Ok, running tests with the adjusted version and going to post a patch
afterwards.
However, during a recent run compiling insn-recog took 2G and insn-emit-7 as
well as insn-emit-10 required > 1.5G each.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
--- Comment #5 from Patrick Palka ---
D'oh, sorry for the breakage.
(In reply to Jakub Jelinek from comment #3)
> If no checking is needed, then it could be just datum = build_nop (ptype,
> datum);
> if we don't want folding.
Makes sense to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70730
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Eric Gallager from comment #2)
> (In reply to Manuel López-Ibáñez from comment #1)
> > If not, this then depends on PR43486
>
> (that's now fixed, btw... so maybe that's had an impact on
1 - 100 of 292 matches
Mail list logo
