https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
--- Comment #2 from Sam James ---
Created attachment 54955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54955=edit
a-FetchTypes.ii.xz
I noticed the filename was 'Unified...' so I tried out
Thanks Jeff for comments.
It makes sense to me. For the EQ operator we should have CONSTM1. Does this
mean s390 parts has similar issue here? Then for instructions like VMSEQ, we
need to adjust the simplify_rtx up to a point.
Please help to correct me if any mistake. Thank you again.
Pan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109677
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|Access control
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
--- Comment #11 from Adelson Oliveira ---
I'm a linux user and gfortran comes with my distro. I mean, I did not compile
gcc.
Is this patch still to be tested? Am I expected to do something to test it? Or
I just wait until a new gfortran version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109677
Bug ID: 109677
Summary: Access control bypass for function template default
argument brace initialization of private default
constructor
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
Bug ID: 109676
Summary: [13/14 regression] ICE in simplify_subreg, at
simplify-rtx.cc:7426 when building firefox with -O2
-march=alderlake -g
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109675
Bug ID: 109675
Summary: GCC 13.1: the Modula-2 front-end fails to build on
some platforms
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #15 from Sam James ---
(In reply to Jonathan Wakely from comment #14)
> I think it should be fine. I would prefer to wait until 12.4 so it has more
> bake time, but that would just mean another few months of duplicate reports
> for
On 4/16/23 07:20, Ajit Agarwal wrote:
Hello All:
This patch improves code sinking pass to sink the blocks before calls
in the use blocks or immediate dominator blocks that reduces register pressure.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
On Fri, 28 Apr 2023, Jeff Law wrote:
> On 4/28/23 16:42, Hans-Peter Nilsson wrote:
> > On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
> > I don't see anything in those functions that checks if
> > ZERO_EXTEND is actually a feature of the ABI, e.g. as opposed to
> > no extension or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109657
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
There is no canonical form for this case defined. So the aarch64 backend needs
a pattern to match both of these forms.
The forms are:
(set (reg/i:SI 0 x0)
(if_then_else:SI (eq (reg:CC 66 cc)
(const_int 0 [0]))
(reg:SI 97)
(const_int -1 [0x])))
and
On 4/28/23 16:42, Hans-Peter Nilsson wrote:
On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
Hello All:
This new version of patch 4 use improve ree pass for rs6000 target using
defined ABI interfaces.
Bootstrapped and regtested on power64-linux-gnu.
Thanks & Regards
Ajit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109674
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109674
Bug ID: 109674
Summary: [14 Regression] linking with libhwasan is now broken
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: link-failure
Severity: normal
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
In the Fortran front end, most of
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C++ front end
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C front end
OpenMP 5.0 removed the restriction that collapsed loops in "omp
for/do" and related constructs must be perfectly nested; it now allows
intervening code to appear before/after each nested loop level. The
spec allows implementations considerable freedom in how many times this
intervening code is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109673
--- Comment #3 from Andrew Pinski ---
(In reply to Parke from comment #2)
>
> I compile my code with -Wall -Wextra and -Werror. Consequently, in order to
> get my code to compile (on Ubuntu), I have to write the following:
>
> void * discard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109673
--- Comment #2 from Parke ---
Thank you for the explanation.
It seems to me that it would (should?) be possible for -Os to detect the
cast-to-void and therefore suppress the second warning (line 5).
It also seems to me the above change, if
On 4/28/23 09:58, Hans-Peter Nilsson via Gcc-patches wrote:
Ok to commit?
-- >8 --
I tried to make use of check-function-bodies for cris-elf and was a
bit surprised to see it failing. There's a deliberate empty line
after the filled delay slot of the return-function which was
mishandled. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #11 from Jeffrey A. Law ---
Coming back to this.
WRT extension elimination. I've been pondering if we want a late pass to do a
bit of this that can't be handled by REE.
So let's take the case of a Zbs instruction operating on a
On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
> This new version of patch 4 use improve ree pass for rs6000 target using
> defined ABI interfaces.
> Bootstrapped and regtested on power64-linux-gnu.
>
> Thanks & Regards
> Ajit
>
>
> ree: Improve ree pass for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109673
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
Snapshot gcc-12-20230428 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20230428/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 4/26/23 15:45, Michael Collison wrote:
2023-04-24 Michael Collison
Juzhe Zhong
* config/riscv/riscv-protos.h
(riscv_vector_preferred_simd_mode): New.
(riscv_vector_mask_mode_p): Ditto.
(riscv_vector_get_mask_mode): Ditto.
The RISC-V psABI pull request is at
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/378 . Pointers to
Paul Kirth's corresponding LLVM patches are also there.
On Fri, Apr 28, 2023 at 2:42 PM Hans Boehm wrote:
> The concern with making the new behavior non-default is of course that the
On 4/26/23 15:45, Michael Collison wrote:
2023-04-24 Michael Collison
Juzhe Zhong
* config/riscv/riscv-v.cc
(riscv_vector_preferred_simd_mode): New function.
(get_mask_policy_no_pred): Ditto.
(get_tail_policy_no_pred): Ditto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109673
Bug ID: 109673
Summary: warn_unused_result warnings are incorrect (and/or
missing) and vary when -Os is specified
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 108219, which changed state.
Bug 108219 Summary: [12 Regression] requirement fails on a valid expression
since r12-5253-g4df7f8c79835d569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 4/26/23 15:45, Michael Collison wrote:
2023-03-02 Michael Collison
Juzhe Zhong
* config/riscv/riscv-vector-builtins.cc (get_tail_policy_for_pred):
Remove static declaration to to make externally visible.
(get_mask_policy_for_pred): Ditto.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106969
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106969
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:458bda5432d352469e258f1c0e4c2a37c853575a
commit r12-9493-g458bda5432d352469e258f1c0e4c2a37c853575a
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #15 from CVS Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:73e86b6766cc92aa8c18cc987bf95929c4ea0672
commit r12-9492-g73e86b6766cc92aa8c18cc987bf95929c4ea0672
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:73e86b6766cc92aa8c18cc987bf95929c4ea0672
commit r12-9492-g73e86b6766cc92aa8c18cc987bf95929c4ea0672
Author: Patrick Palka
On 4/20/23 15:03, Ajit Agarwal wrote:
Currently I support AND with const1_rtx. This is what is equivalent to zero
extension instruction in power instruction set. When you specify many other
constants and Could you please specify what other constants needs to be
supported and how to
On Fri, Apr 28, 2023 at 09:35:49AM +0100, Jonathan Wakely wrote:
> Yes, for both, thanks for the fix.
>
> After it lands on the gcc-13 branch I'll also update the manual with:
>
> --- a/libstdc++-v3/doc/xml/manual/abi.xml
> +++ b/libstdc++-v3/doc/xml/manual/abi.xml
> @@ -275,6 +275,7 @@
On 4/6/23 19:37, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp: Add auto-vectorization testing.
* gcc.target/riscv/rvv/vsetvl/vsetvl-17.c: Adapt testcase.
*
On 4/6/23 21:37, shiyul...@iscas.ac.cn wrote:
From: yulong
This patch fixes the problem of the contracts-tmpl-spec2.c running failure.
When run the dejagnu test, I find that the output is inconsistent with that
verified
in the testcase. So I try to modify it, and then it can be passed.
On 4/12/23 07:18, shiyul...@iscas.ac.cn wrote:
From: yulong
This patch fix a redefinition bug.
There are have a definition about mode_t in the fd-4.c, but it duplicates the
definition in types.h that be included by stdio.h.
Thanks to Jeff Law for reviewing the previous version.
On 4/28/23 09:21, Pan Li via Gcc-patches wrote:
From: Pan Li
When some RVV integer compare operators act on the same vector registers
without mask. They can be simplified to VMSET.
This PATCH allows the eq, le, leu, ge, geu to perform such kind of the
simplification by adding one macro in
The concern with making the new behavior non-default is of course that the
generated code will eventually end up on an A.7-capable platform.
An A.6-classic option for compiling code that will never run on a newer
machine seems OK. But I'm not sure that seq_cst stores are dynamically
frequent
On 4/20/23 09:56, Jeff Law via Gcc-patches wrote:
On 1/17/23 15:59, Vineet Gupta wrote:
This could be useful for library writers who want to write code variants
for fast vs. slow unaligned accesses.
We distinguish explicit -mstrict-align (1) vs. slow_unaligned_access
cpu tune param (2)
Hi,
I agree with you that C would benefit from a new type qualifier to
indicate pointer nullability, although not with your suggestion that
such a qualifier should indicate the property cannot-be-null.
If you just want a syntax for declaring that a function parameter is
not a null pointer, C
On 4/21/23 04:07, Fei Gao wrote:
Currently in rv32e, stack allocation for GPR callee-saved registers is
always 12 bytes w/o save-restore. Actually, for the case without save-restore,
less stack memory can be reserved. This patch decouples stack allocation for
rv32e w/o save-restore and makes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #31 from Romain Geissler ---
Ok thanks for confirming. I was about to ask for a deployment one of our
gcc-based toolchain in production containing the current gcc 13.1.1, I will
wait a bit that this patch lands in the gcc 13 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Component|fortran |libfortran
Last
GCC_11.0 is an aarch64-specific outlier.
* doc/xml/manual/abi.xml (abi.versioning.history): Add
GCC_7.0.0, GCC_9.0.0, GCC_11.0, GCC_12.0.0, GCC_13.0.0 for
libgcc_s.
---
libstdc++-v3/doc/xml/manual/abi.xml | 5 +
1 file changed, 5 insertions(+)
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #30 from Jonathan Wakely ---
(In reply to Romain Geissler from comment #28)
> In other words, in general, is there any guarantee that something built
> using gcc N.X.0 can be run with the runtime of gcc N.Y.0 for X > Y ?
No. There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109654
--- Comment #2 from Richard Smith ---
Hm, that doesn't explain why the second example I gave is accepted. But I
suppose what's happening there is probably just that the `packed` attribute is
ignored entirely for fields with alignment 1, so this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
--- Comment #10 from anlauf at gcc dot gnu.org ---
Created attachment 54954
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54954=edit
Patch (2nd try)
This one works and regtests ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #29 from Romain Geissler ---
Typo: If yes, given that you also maintain the gcc package in fedora 38
(https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that
something built in some future up to date Fedora 38 won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109652
--- Comment #7 from Sergei Trofimovich ---
(In reply to Richard Biener from comment #6)
> Should be fixed now.
I confirm it fixed valgrind-3.20.0 build as well. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #4 from Christoph Reiter ---
Everything seems to be dynamically linked to libgcc, I'm out of ideas.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109651
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On 4/28/23 10:10, Robin Dapp wrote:
Hi,
I figured I'm going to start sending some patches that build on top
of the upcoming RISC-V autovectorization. This one is obviously
not supposed to be installed before the basic support lands but
it's small enough that it shouldn't hurt to send it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #4 from Jeffrey A. Law ---
If we need to handle subregs here, I would suggest something like this
if (SUBREG_P (XEXP (op0, 0))
&& subreg_lowpart_p (op0)
... other tests ...
That way we know we're extracting the low word of
On 2/17/23 07:02, Matevos Mehrabyan via Gcc-patches wrote:
Hi all,
If we have division and remainder calculations with the same operands:
a = b / c;
d = b % c;
We can replace the calculation of remainder with multiplication +
subtraction, using the result from the previous division:
Kito and I were talking this morning, he's going to try and find the
time to actually write this. Kind of odd to send to the mailing list,
but I figure that's the easist way to get it out. It's very much not
mergeable as is...
---
gcc/doc/invoke.texi | 87
On Fri, 28 Apr 2023, Patrick Palka wrote:
> On Fri, 28 Apr 2023, Patrick Palka wrote:
>
> > After mechanically replacing RESULT_DECL within a constexpr call result
> > (for sake of RVO), we can in some cases simplify the call result
> > further.
> >
> > In the below testcase the result of get()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671
--- Comment #2 from Patrick J. LoPresti ---
Um... OK...
So I have to "correct" my code like so:
const Foo (bool x)
{
const std::string s = (x ? "x" : "y");
const Foo = get_foo_by_name(s);
return f;
}
But if get_foo_by_name() has the
On Fri, 28 Apr 2023, Patrick Palka wrote:
> After mechanically replacing RESULT_DECL within a constexpr call result
> (for sake of RVO), we can in some cases simplify the call result
> further.
>
> In the below testcase the result of get() during evaluation of a's
> initializer is the
After mechanically replacing RESULT_DECL within a constexpr call result
(for sake of RVO), we can in some cases simplify the call result
further.
In the below testcase the result of get() during evaluation of a's
initializer is the self-referential CONSTRUCTOR:
{._M_p=(char *) &._M_local_buf}
On 4/27/23 08:29, Karen Sargsyan via Gcc-patches wrote:
clmul[h] instructions were added only for the ZBKC extension.
This patch includes them in the ZBC extension too.
Besides, added support of 'clmulr' instructions for ZBC extension.
gcc/ChangeLog:
* config/riscv/bitmanip.md: Added
We're certainly pushing for the same ABI (A.6 + trailing fence on store) in
LLVM as well. I'm about to upload a pull request for the psABI document
that describes this version of the ABI, and a bit of the rationale for it.
I'll attach the current draft here.
I agree that compatibility is critical
On 28 April 2023 09:26:06 CEST, Tobias Burnus wrote:
>Committed as r14-319-g7ebd4a1d61993c0a75e9ff3098aded21ef04a4da
> Only other changes are fixing the variable name a(b)breviated_modproc_decl
I think this is not good, I've mentioned it somewhere, i think, but I'll rename
it.
thanks!
On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran
wrote:
>* Martin Liška:
>But that's okay for me as well.
Even better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109672
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|[143
On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran
wrote:
>* Martin Liška:
>But that's okay for me as well.
Even better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #3 from Christoph Reiter ---
This looks very much like bug 108202 though, so I'll see if I can find
something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #2 from Christoph Reiter ---
(In reply to Christoph Reiter from comment #1)
> [...] I'll try building without that.
That didn't make a difference sadly.
On 4/28/23 10:44, Patrick O'Neill wrote:
On 4/28/23 09:29, Palmer Dabbelt wrote:
On Fri, 28 Apr 2023 09:14:00 PDT (-0700), jeffreya...@gmail.com wrote:
On 4/27/23 10:22, Patrick O'Neill wrote:
...
LLVM mapping notes
LLVM emits corresponding fences for atomic_signal_fence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109672
Bug ID: 109672
Summary: [143 regression] many ICEs after
r14-323-g977a43f5ba778b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
On 4/27/23 10:23, Patrick O'Neill wrote:
These tests cover basic cases to ensure the atomic mappings follow the
strengthened Table A.6 mappings that are compatible with Table A.7.
2023-04-27 Patrick O'Neill
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-a-6-amo-add-1.c: New
On 4/27/23 10:23, Patrick O'Neill wrote:
This change brings atomic loads in line with table A.6 of the ISA
manual.
2023-04-27 Patrick O'Neill
gcc/ChangeLog:
* config/riscv/sync.md (atomic_load): Implement atomic
load mapping.
OK.
jeff
On 4/27/23 10:22, Patrick O'Neill wrote:
This change brings atomic fences in line with table A.6 of the ISA
manual.
Relax mem_thread_fence according to the memmodel given.
2023-04-27 Patrick O'Neill
gcc/ChangeLog:
* config/riscv/sync.md (mem_thread_fence_1): Change fence
On 4/27/23 10:22, Patrick O'Neill wrote:
Introduce the %I and %J flags for setting the .aqrl bits on LR/SC pairs
as needed.
Atomic compare and exchange ops provide success and failure memory
models. C++17 and later place no restrictions on the relative strength
of each model, so ensure we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671
--- Comment #1 from Andrew Pinski ---
There is no way for GCC to know that get_foo_by_name does not store the
argument into what is returned so it warns about this case ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671
Bug ID: 109671
Summary: Spurious dangling reference warning in GCC 13
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105525
--- Comment #3 from Mikael Pettersson ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617071.html
PR target/105525 is a build regression for the vax and lm32 linux
targets present in gcc-12/13/head, where the builds fail due to
unsatisfied references to __INTPTR_TYPE__ and __UINTPTR_TYPE__,
caused by these two targets failing to provide glibc-stdint.h.
Fixed thusly, tested by building
On 4/28/23 09:29, Palmer Dabbelt wrote:
On Fri, 28 Apr 2023 09:14:00 PDT (-0700), jeffreya...@gmail.com wrote:
On 4/27/23 10:22, Patrick O'Neill wrote:
This patchset aims to make the RISCV atomics implementation stronger
than the recommended mapping present in table A.6 of the ISA manual.
On Fri, 28 Apr 2023 10:40:15 PDT (-0700), jeffreya...@gmail.com wrote:
On 4/27/23 10:22, Patrick O'Neill wrote:
This change makes atomic stores strictly stronger than table A.6 of the
ISA manual. This mapping makes the overall patchset compatible with
table A.7 as well.
2023-04-27 Patrick
On 4/27/23 10:22, Patrick O'Neill wrote:
Atomic operations with the appropriate bits set already enfore release
semantics. Remove unnecessary release fences from atomic ops.
This change brings AMO ops in line with table A.6 of the ISA manual.
2023-04-27 Patrick O'Neill
gcc/ChangeLog:
On 4/27/23 10:22, Patrick O'Neill wrote:
This change makes atomic stores strictly stronger than table A.6 of the
ISA manual. This mapping makes the overall patchset compatible with
table A.7 as well.
2023-04-27 Patrick O'Neill
PR 89835
Should be "PR target/89835"
gcc/ChangeLog:
On 4/27/23 10:22, Patrick O'Neill wrote:
This patch sets the relevant .rl bits on amo operations.
2023-04-27 Patrick O'Neill
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_print_operand): change behavior
of %A to include release bits.
Capitalize "change" in the ChangeLog
Hi Kwok,
On 17.02.23 12:45, Kwok Cheung Yeung wrote:
This is a revised version of the patch for the 'present' modifier for
OpenMP. Compared to the first version, three improvements have been made:
- A bug which caused bootstrapping with a '-m32' multilib on x86-64 to
fail due to pointer size
On 4/27/23 10:22, Patrick O'Neill wrote:
This patch enforces SEQ_CST for atomic compare_exchange ops.
Replace Fence/LR.aq/SC.aq pairs with SEQ_CST LR.aqrl/SC.rl pairs
recommended by table A.6 of the ISA manual.
2023-04-27 Patrick O'Neill
gcc/ChangeLog:
* config/riscv/sync.md:
These two patches implement the base support of builtin_zero_pattern
into match.pd. To implement the other part requires match-and-simplify
inside phiopt to support moving 2 statements from the middle-bb. The
match.pd part is already incldued. I will try to get to it next week.
Also
This adds the patterns for
POPCOUNT BSWAP FFS PARITY CLZ and CTZ.
For "a != 0 ? FUNC(a) : CST".
CLRSB, CLRSBL, and CLRSBLL will be moved next.
Note this is not enough to remove
cond_removal_in_builtin_zero_pattern as we need to handle
the case where there is an NOP_CONVERT inside the conditional
While moving working on moving
cond_removal_in_builtin_zero_pattern to match, I noticed
that functions were not allowed to move as we reject all
non-assignments.
This changes to allowing a few calls which are known not
to throw/trap. Right now it is restricted to ones
which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #1 from Christoph Reiter ---
Could this be another case of exceptions being broken, as indicated here
https://github.com/AdaCore/gnat-llvm/issues/25#issuecomment-1057198363 ?
I see some "-static-libgcc" in the ada Makefile.in. I'll
> -Original Message-
> From: Andrea Corallo
> Sent: Friday, April 28, 2023 12:30 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; Stam Markianos-Wright wri...@arm.com>
> Subject: [PATCH 10/10] arm testsuite: Shifts and get_FPSCR ACLE optimisation
> fixes
>
> -Original Message-
> From: Andrea Corallo
> Sent: Friday, April 28, 2023 12:30 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; Stam Markianos-Wright wri...@arm.com>
> Subject: [PATCH 09/10] arm testsuite: XFAIL or relax registers in some tests
>
> From:
On 4/28/23 10:43, Palmer Dabbelt wrote:
On Fri, 28 Apr 2023 08:20:24 PDT (-0700), jeffreya...@gmail.com wrote:
On 4/27/23 01:39, Jan Beulich via Gcc-patches wrote:
On 26.04.2023 17:45, Palmer Dabbelt wrote:
On Wed, 26 Apr 2023 08:26:26 PDT (-0700), gcc-patches@gcc.gnu.org
wrote:
On
1 - 100 of 281 matches
Mail list logo
