On Mon, Nov 14, 2022 at 8:52 AM Jakub Jelinek wrote:
>
> Hi!
>
> Working virtually out of Baker Island.
>
> Given
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688#c10
> the following patch implements atomic load/store (and therefore also
> enabling compare and exchange) for -m64 -mcx16
On Mon, Nov 14, 2022 at 8:48 AM Jakub Jelinek wrote:
>
> Hi!
>
> Working virtually out of Baker Island.
>
> We got a response from AMD in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688#c10
> so the following patch starts treating AMD with AVX and CMPXCHG16B
> ISAs like Intel by using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #12 from Jakub Jelinek ---
I've posted the patches (so far only lightly tested):
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606021.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606022.html
It is still
Hi!
Working virtually out of Baker Island.
Given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688#c10
the following patch implements atomic load/store (and therefore also
enabling compare and exchange) for -m64 -mcx16 -mavx.
Ok for trunk if it passes bootstrap/regtest?
2022-11-13 Jakub
Hi!
Working virtually out of Baker Island.
We got a response from AMD in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688#c10
so the following patch starts treating AMD with AVX and CMPXCHG16B
ISAs like Intel by using vmovdqa for atomic load/store in libatomic.
Ok for trunk if it passes
On Sun, Nov 13, 2022 at 9:39 PM Jakub Jelinek wrote:
>
> On Sun, Nov 13, 2022 at 09:05:53PM +0100, Aldy Hernandez wrote:
> > It seems SQRT is relatively straightforward, and it's something Jakub
> > wanted for this release.
> >
> > Jakub, what do you think?
> >
> > p.s. Too tired to think about
On Sun, Nov 13, 2022 at 4:38 PM Christoph Muellner
wrote:
>
> From: mtsamis
>
> The IPA CP pass offers a wide range of optimizations, where most of them
> lead to specialized functions that are called from a call site.
> This can lead to multiple specialized function clones, if more than
> one
> Sorry for the breakage. However, I contacted you (and your colleague)
> and haven't received
> any feedback for a couple of weeks.
> >>>
> >>> Right although I did give you feedback that what you sent wasn’t in a
> >>> suitable form for review wrt Ada.
> >>
> >> Sure, but
On Sun, Nov 13, 2022 at 4:09 PM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> This patch adds a new pass that looks up function pointer assignments,
> and adds guarded direct calls to the call sites of the function
> pointers.
>
> E.g.: Lets assume an assignment to a function pointer
On Mon, 14 Nov 2022, Jiufu Guo wrote:
>
> Hi!
> Thanks so much for your review!
>
> Richard Biener writes:
>
> > On Fri, 11 Nov 2022, Jiufu Guo wrote:
> >
> >> Hi,
> >>
> >> When assigning a struct parameter to another variable, or loading a
> >> memory block to a struct var (especially for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634
--- Comment #10 from Eric Botcazou ---
> About the number of files. Yes, that's the biggest change when it comes to
> Sphinx and I see it also as a drawback. However, it's the only valid file
> naming scheme supported by Sphinx and there are
The following avoids exceeding the maximum object size on 32bit
platforms.
Pushed.
* gcc.dg/pr107554.c: Restrict to lp64.
---
gcc/testsuite/gcc.dg/pr107554.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/pr107554.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107672
Bug ID: 107672
Summary: [13 Regression] ICE during GIMPLE pass: slp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106854
Sam James changed:
What|Removed |Added
CC||ericb at gcc dot gnu.org
--- Comment #8
On Fri, Nov 11, 2022 at 10:45 AM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> For all AMX related ISAs, we have a potential dependency on AMX-TILE
> or we even won't have the basic support on AMX.
>
> This patch added those dependency. Ok for trunk?
Ok.
>
> BRs,
> Haochen
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
> Ok, Note GCC documents have been ported to sphinx, so you need to
> adjust changes in invoke.texi to new sphinx files.
Yes, this is the patch I'm going to check-in. Thanks.
Hongtao Liu 于2022年11月14日周一 09:35写道：
>
> On Wed, Nov 9, 2022 at 9:29 AM Hongyu Wang wrote:
> >
> > > Although
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
Xi Ruoyao changed:
What|Removed |Added
Summary|gcc and libatomic can use |gcc and libatomic can use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #11 from Sam James ---
(In reply to GGanesh from comment #10)
> Can we extend this patch to AMD processors as well. If not, I will plan to
> submit the patch for stage-1!
GCC 13 (as of today) is in stage 3 - see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #44 from Andrew Downing ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Downing from comment #41)
> > > Thus for types without a non-trivial ctor/dtor you do not need to use
> > > placement new. So take your
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__find_last_fn, find_last):
Define.
(__find_last_if_fn, find_last_if): Define.
(__find_last_if_not_fn, find_last_if_not): Define.
*
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (out_value_result): Define.
(iota_result): Define.
(__iota_fn, iota): Define.
* testsuite/25_algorithms/iota/1.cc: New test.
---
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__contains_fn, contains): Define.
(__contains_subrange_fn, contains_subrange): Define.
* testsuite/25_algorithms/contains/1.cc: New test.
*
> On 21 Oct 2022, at 09:40, Florian Weimer via Gcc wrote:
>
> What should we do about these when they are not relevant to what's being
> tested? For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c
> has this:
>
> int main ()
> {
>if (__builtin_copysign (1.0, func (0.0 /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105611
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #2 from Iain Buclaw ---
Expected generated code would be:
---
bt32_setb*:
...
shrl$5, %edx
movl(%eax,%edx,4), %edx
xorl%eax, %eax
btl %ecx, %edx
setb%al
...
---
bt32_setae*:
...
shrl$5, %edx
Hi!
Thanks so much for your review!
Richard Biener writes:
> On Fri, 11 Nov 2022, Jiufu Guo wrote:
>
>> Hi,
>>
>> When assigning a struct parameter to another variable, or loading a
>> memory block to a struct var (especially for return value),
>> Now, "block move" would be used during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #1 from Iain Buclaw ---
Non-pointer variants also not detected.
---
int bt32v_setb(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return ((v & (1 << (bitnum & 31 != 0;
}
int bt64v_setb(const __UINT64_TYPE__ v,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
Bug ID: 107671
Summary: i386: Missed optimization: use of bt in bit test
pattern when LHS is an array index
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
GGanesh changed:
What|Removed |Added
CC||Ganesh.Gopalasubramanian@am
On 11/14/22 02:21, Gerald Pfeifer wrote:
> On Sun, 13 Nov 2022, Martin Liška wrote:
>> So Gerald, I'm suggesting a new url base gcc.gnu.org/docs that will be
>> filled with the new manuals and gcc.gnu.org/onlinedocs/$man and
>> gcc.gnu.org/install locations should point to older (trunk) manuals
On 11/13/22 18:03, Arnaud Charlet wrote:
Sorry for the breakage. However, I contacted you (and your colleague) and
haven't received
any feedback for a couple of weeks.
>>>
>>> Right although I did give you feedback that what you sent wasn’t in a
>>> suitable form for review wrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107670
Bug ID: 107670
Summary: Suspicious redundant code in ipa-cp
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
The following patch will be needed for ChangeLog entry emission
of the reverted Sphinx commits.
Pushed.
Martin
contrib/ChangeLog:
* gcc-changelog/git_commit.py: Temporarily disable
check_line.start.
---
contrib/gcc-changelog/git_commit.py | 2 ++
1 file changed, 2 insertions(+)
Hi.
The situation with the Sphinx migration went out of control. The TODO list
overwhelmed me and there are road-blocks that can't be easily fixed with what
Sphinx currently supports. That would require addition of an upstream support
and
a possible new Sphinx release.
Let me summarize the
Hi.
The situation with the Sphinx migration went out of control. The TODO list
overwhelmed me and there are road-blocks that can't be easily fixed with what
Sphinx currently supports. That would require addition of an upstream support
and
a possible new Sphinx release.
Let me summarize the
On 11/13/22 15:05, Christoph Muellner wrote:
+static bool
+riscv_overlap_op_by_pieces (void)
+{
+ return tune_param->overlap_op_by_pieces;
Does this not need to be gated on unaligned access enabled as well.
-Vineet
How about I do this work on Glibc?
在 2022/11/12 下午3:08, Xi Ruoyao 写道:
On Wed, 2022-11-09 at 21:53 +0800, Xi Ruoyao wrote:
These patches allow to expand the following builtins to floating point
instructions for LoongArch:
- __builtin_rint{,f}
- __builtin_{l,ll}rint{,f}
-
On Fri, Nov 11, 2022 at 10:47 PM Tamar Christina via Gcc-patches
wrote:
>
> Hi All,
>
> The current i386 implementation of the TARGET_CAN_CHANGE_MODE_CLASS is
> currently
> not useful before re-alloc.
>
> In particular before regalloc optimization passes query the hook using
> ALL_REGS,
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669
Bug ID: 107669
Summary: [13 Regression] commit
r13-3931-59a63247992eb13153b82c4902aadf111460eac2
causes lots of testcase failure
Product: gcc
Version: 13.0
On Thu, Nov 10, 2022 at 2:04 PM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> This patch aims to mention newly added Intel ISA and march support.
>
> Ok for trunk?
Ok.
>
> BRs,
> Haochen
>
> ---
> htdocs/gcc-13/changes.html | 50 ++
> 1 file changed, 50
On Wed, Nov 9, 2022 at 9:29 AM Hongyu Wang wrote:
>
> > Although ix86_small_unroll_insns is coming from issue_rate, it's tuned
> > for codesize.
> > Make it exact as issue_rate and using factor * issue_width /
> > loop->ninsns may increase code size too much.
> > So I prefer to add those 2
On Sun, 13 Nov 2022, Martin Liška wrote:
> So Gerald, I'm suggesting a new url base gcc.gnu.org/docs that will be
> filled with the new manuals and gcc.gnu.org/onlinedocs/$man and
> gcc.gnu.org/install locations should point to older (trunk) manuals
> (prev folder at server I guess). Having
From: Christoph Müllner
This patch implements expansions for the cmpstrsi and the cmpstrnsi
builtins using Zbb instructions (if available).
This allows to inline calls to strcmp() and strncmp().
The expansion basically emits a peeled comparison sequence (i.e. a peeled
comparison loop) which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106235
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
From: Christoph Müllner
This patch implements the expansion of the strlen builtin
using Zbb instructions (if available) for aligned strings
using the following sequence:
li a3,-1
addia4,a0,8
.L2: ld a5,0(a0)
addia0,a0,8
orc.b a5,a5
beq
From: Christoph Müllner
Let's try to not accumulate too much functionality in one single file
as this does not really help maintaining or extending the code.
So in order to add more similar functionality like riscv_block_move_loop
let's move this function to a separate file.
This change does
From: Christoph Müllner
INSNs are usually postfixed by a number representing the argument count.
Given the instructions will be used in a later commit, let's make them
visible, but add a "riscv_" prefix to avoid conflicts with standard
INSNs.
gcc/ChangeLog:
* config/riscv/bitmanip.md
From: Philipp Tomsich
As a basis for optimized string functions (e.g., the by-pieces
implementations), we need orc.b available. This adds orc.b as an
unspec, so we can expand to it.
gcc/ChangeLog:
* config/riscv/bitmanip.md (orcb2): Add orc.b as an
unspec.
*
From: Christoph Müllner
This patchset adds includes patches to improve the following builtin
expansions:
* cpymemsi: Allow by-pieces to generate overlapping memory accesses
* cmpstrsi: Add expansion for strcmp and strncmp for aligned strings when
zbb/orc.b is available
* strlen: Add expansion
From: Christoph Müllner
The current implementation of riscv_block_move_straight() emits a couple
of load-store pairs with maximum width (e.g. 8-byte for RV64).
The remainder is handed over to move_by_pieces(), which emits code based
target settings like slow_unaligned_access and
From: Christoph Müllner
This patch adds the field overlap_op_by_pieces to the struct
riscv_tune_param, which allows to enable the overlap_op_by_pieces
infrastructure.
gcc/ChangeLog:
* config/riscv/riscv.c (struct riscv_tune_param): New field.
(riscv_overlap_op_by_pieces): New
This patch adds a new -Wanalyzer-tainted-assertion warning to
-fanalyzer's "taint" mode (which also requires -fanalyzer-checker=taint).
It complains about attacker-controlled values being used in assertions,
or in any expression affecting control flow that guards a "noreturn"
function. As noted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106235
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:d777b38cde91a87f2345dcd13901862a9513562a
commit r13-3947-gd777b38cde91a87f2345dcd13901862a9513562a
Author: David Malcolm
Date:
Snapshot gcc-13-20221113 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20221113/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
--- Comment #2 from Jonathan Wakely ---
Patch for time zones and incomplete formatting support:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605926.html
On Sun, Nov 13, 2022 at 1:57 PM Alejandro Colomar via Gcc
wrote:
>
> Hi!
>
> I'd like to get warnings if I write the following code:
>
> char foo[3] = "foo";
This should be easy to add as it is already part of the -Wc++-compat
option as for C++ it is invalid code.
:2:19: warning:
From: "moiz.hussain"
The XTheadMacXTheadMemPair ISA extension provides load/store
pair instructions:
* th.ldd
* th.sdd
* th.lwd
* th.lwud
* th.swd
We added the following unnamed patterns to the
peephole.md stage:
* load/store pair patterns for 4 instructions
* load/store pair patterns for 2
Hi!
I'd like to get warnings if I write the following code:
char foo[3] = "foo";
It's hard to keep track of sizes to make sure that the string literals always
initialize to terminated strings. It seems something that should be easy to
implement in the compiler.
A morecomplex case where
On 13 November 2022 21:29:50 CET, Harald Anlauf wrote:
>Replacing "int" by "signed char" adds confusion and makes code
>less understandable, so I would oppose it, as we don't solve a
>real problem and rather add confusion.
Ok so consider the non-bool hunks dropped, they just fell out of my
From: Christoph Müllner
The XTheadMac ISA extension provides multiply-accumulate/subtract
instructions:
* mula/mulaw/mulah
* muls/mulsw/mulsh
To benefit from middle-end passes, we expand the following named
patterns in riscv.md (as they are not T-Head-specific):
* maddhisi4
* msubhisi4
From: Christoph Müllner
This patch add basic support for the XTheadFmv and XTheadInt
ISA extension. As both extensions only contain instruction,
which are not supposed to be emitted by the compiler, the support
only covers awareness of the extension name in the march string
and the definition of
From: Christoph Müllner
The XTheadBb ISA extension provides instructions similar to Zbb:
* th.srri/th.srriw
* th.ext/th.extu
* th.ff1 (count-leading-zeros)
* th.rev/th.revw
Instructions that are not covered, because they don't fit into a
pattern:
* th.ff0 (count-leading-ones)
* th.tstnbz
For
From: Christoph Müllner
This patch adds support for the following T-Head vendor extensions:
* XTheadBa
* XTheadBs
Both extensions provide just one instruction, that has a counterpart
in the similar named Bitmanip ISA extension.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_rtx_costs):
From: Christoph Müllner
This patch adds support for XTheadCondMov ISA extension.
The extension brings a one-sided conditional move (no else-assignment).
Given that GCC has a great if-conversion pass, we don't need to do much,
besides properly expanding movcc accordingly and adjust the cost
From: Christoph Müllner
This series adds support for the following vendor extensions
from T-Head:
* XTheadCmo, XTheadSync
* XTheadBa, XTheadBb, XTheadBs
* XTheadCondMov
* XTheadMac
* XTheadFmv, XTheadInt
No regressions observed.
Christoph Müllner (7):
riscv: Add basic XThead* vendor
From: Christoph Müllner
This patch add basic support for the following XThead* ISA extensions:
* XTheadCmo, XTheadSync
* XTheadBa, XTheadBb, XTheadBs, XTheadCondMov
* XTheadMac
* XTheadFMemIdx, XTheadMemIdx
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Add xthead* extensions.
From: Christoph Müllner
This adds T-Head's XuanTie C906 to the list of known cores as "thead-c906".
The C906 is shipped for quite some time (it is the core of the Allwinner D1).
Note, that the tuning struct for the C906 is already part of GCC (it is
also name "thead-c906").
gcc/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
--- Comment #2 from David Binderman ---
Reduced C++ code seems to be:
--- /home/dcb36/cvise/bug862.cc ---
float dot();
float intersectcylinder_md;
void intersectcylinder(float ) {
float nd = dot();
dist = 0 / nd;
float offset =
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_CORE): Update the
Ventana-VT1 definition to include the xventanacondops
extension.
Signed-off-by: Philipp Tomsich
---
Changes in v2:
- New in v2.
gcc/config/riscv/riscv-cores.def | 2 +-
1 file changed, 1
Some architectures, as it the case on RISC-V with the proposed
ZiCondOps and the vendor-defined XVentanaCondOps, define a
conditional-zero instruction that is equivalent to:
- the positive form: rd = (rc != 0) ? rs : 0
- the negated form: rd = (rc == 0) ? rs : 0
While
When if-conversion in noce_try_store_flag_mask starts the sequence off
with an order-operator, our patterns for vt.maskc will receive the
result of the order-operator as a register argument; consequently,
they can't know that the result will be either 1 or 0.
To convey this information (and make
While the positive case "if ((bits >> SHAMT) & 1)" for SHAMT 0..10 can
trigger conversion into efficient branchless sequences
- with Zbs (bexti + neg + and)
- with XVentanaCondOps (andi + vt.maskc)
the inverted/negated case results in
andi a5,a0,1024
seqz a5,a5
neg a5,a5
and a5,a5,a1
When if-conversion encounters sequences using immediates, the
sequences can't trivially map back onto vt.maskc/vt.maskcn (even if
benefitial) due to vt.maskc and vt.maskcn not having immediate forms.
This adds a splitter to rewrite opportunities for XVentanaCondOps that
operate on an immediate by
Both the XVentanaCondOps (a vendor-defined extension from Ventana
Microsystems) and the proposed ZiCondOps extensions define a
conditional-zero(-or-value) instruction, which is similar to the
following C construct:
rd = rc ? rs : 0
This functionality can be tied back into if-convertsion and
Users might use explicit arithmetic operations to create a mask and
then and it, in a sequence like
cond = (bits >> SHIFT) & 1;
mask = ~(cond - 1);
val &= mask;
which will present as a single-bit sign-extract.
Dependening on what combination of XVentanaCondOps and Zbs are
available,
Adds a pattern to map the output of noce_try_store_flag_mask
if-conversion in the combiner onto vt.maskc; the input patterns
supported are similar to the following:
(set (reg/v/f:DI 75 [ ])
(and:DI (neg:DI (ne:DI (reg:DI 82)
(const_int 0 [0])))
This adds the xventanacondops extension to the option parsing and as a
default for the ventana-vt1 core:
gcc/Changelog:
* common/config/riscv/riscv-common.cc: Recognize
"xventanacondops" as part of an architecture string.
* config/riscv/riscv-opts.h
On 11/13/22 20:26, Martin Liška wrote:
The patch is fine, please send it to gcc-patches ML and install it.
I sent a patch now, but don't have commit rights.
...similar to 1f9c79367e136e0ca5b775562e6111e1a0d0046f "sphinx: fix
building if
sphinx-build is missing"
gcc/ChangeLog:
* fortran/Make-lang.in: Build info pages conditionally.
---
gcc/fortran/Make-lang.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On Sat, Nov 12 2022, Martin Jambor wrote:
> Hi,
>
> When building vectors of known aggregate values, there is no point in
> including those for parameters which are not used in any way
> whatsoever.
>
> Bootstrapped and tested on x86_64-linux. OK for master?
>
> Thanks,
>
> Martin
When doing LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
Am 13.11.22 um 09:51 schrieb Andreas Schwab:
This breaks aarch64:
$ /opt/gcc/gcc-20221113/Build/./gcc/xgcc -B/opt/gcc/gcc-20221113/Build/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include
Hi!
x86_64/i686 has for a few weeks working std::bfloat16_t support, __bf16
there is no longer a storage only type, but can be used for arithmetics
and is supported in libgcc and libstdc++.
The following patch adds similar support for AArch64.
Bootstrapped/regtested on aarch64-linux.
We avoid reassociating "(~(a >> BIT_NO)) & 1" into "((~a) >> BIT_NO) & 1"
by splitting it into a zero-extraction (bext) and an xori. This both
avoids burning a register on a temporary and generates a sequence that
clearly captures 'extract bit, then invert bit'.
This change improves the
Use Zbs when generating a sequence for "if ((a & twobits) == singlebit) ..."
that can be expressed as bexti + bexti + andn.
gcc/ChangeLog:
* config/riscv/bitmanip.md
(*branch_mask_twobits_equals_singlebit):
Handle "if ((a & T) == C)" using Zbs, when T has 2 bits set and C has
The Ventana VT1 core supports quad-issue and instruction fusion.
This implemented TARGET_SCHED_MACRO_FUSION_P to keep fusible sequences
together and adds idiom matcheing for the supported fusion cases.
gcc/ChangeLog:
* config/riscv/riscv.cc (enum riscv_fusion_pairs): Add symbolic
For a straightforward application of bext for the following function
long bext64(long a, char bitno)
{
return (a & (1UL << bitno)) ? 0 : -1;
}
we generate
srl a0,a0,a1# 7 [c=4 l=4] lshrdi3
andia0,a0,1 # 8 [c=4 l=4] anddi3/1
addi
The Ventana-VT1 core is compatible with rv64gc, Zb[abcs], Zifenci and
XVentanaCondOps.
This introduces a placeholder -mcpu=ventana-vt1, so tooling and
scripts don't need to change once full support (pipeline, tuning,
etc.) will become public later.
gcc/ChangeLog:
*
This series provides support for the Ventana VT1 (a 4-way superscalar
rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support
for the supported instruction fusion patterns.
This includes the addition of the fusion-aware scheduling
infrastructure for RISC-V and implements idiom
The Zihintpause extension uses an opcode from the 'fence' opcode range
to add a true hint instruction (i.e. if it is not supported on any
given platform, the 'fence' that is encoded will not enforce any
specific ordering on memory accesses) for entering a low-power state
(e.g. in an idle thread).
RISC-V's .p2align (currently) ignores the max-skip argument. As we
have experimental patches underway to address this in a
backwards-compatible manner, let's prepare GCC for the day when
binutils gets updated.
gcc/ChangeLog:
* config/riscv/riscv.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Implement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106235
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
On Sun, Nov 13, 2022 at 09:05:53PM +0100, Aldy Hernandez wrote:
> It seems SQRT is relatively straightforward, and it's something Jakub
> wanted for this release.
>
> Jakub, what do you think?
>
> p.s. Too tired to think about op1_range.
That would be multiplication of the same value twice,
On Sun, 13 Nov 2022 19:42:52 +
Jonathan Wakely via Gcc-patches wrote:
> On Sun, 13 Nov 2022, 18:06 Arsen Arsenović via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
>
> > I'm unsure why this issue only started manifesting now with how old this
> > code is, but this should fix it.
> >
>
Am 13.11.22 um 11:39 schrieb Bernhard Reutner-Fischer via Gcc-patches:
On Sun, 13 Nov 2022 12:13:26 +0200
Janne Blomqvist wrote:
On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
wrote:
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1135,7 +1135,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> std::mt19937
r11-4535-g822c1d21a3c710
Hmm, this might be expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104
--- Comment #5 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:58e7732a2feddf475e72b232bf16494d84a41acf
commit r13-3946-g58e7732a2feddf475e72b232bf16494d84a41acf
Author: José Rui Faustino de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
--- Comment #4 from Andrew Pinski ---
std::mt19937
1 - 100 of 231 matches
Mail list logo
