The current method of treating shifts of extended values on RISC-V
frequently causes sequences of 3 shifts, despite the presence of the
'zero_extendsidi2_shifted' pattern.
Consider:
unsigned long f(unsigned int a, unsigned long b)
{
a = a << 1;
unsigned long c = (un
A few of the gcc.target/riscv/mcpu-*.c tests have been failing for a
while now, due to the pipeline model for sifive-7-series not being
selected despite -mtune=sifive-7-series. The root cause is that the
respective RISCV_TUNE entry points to generic instead. Fix this.
Fixes 97d1ed67fc6 ("RISC-V:
This patch to the GCC-specific part of the Go frontend defines the
__atomic_fetch_add functions. The frontend only generates calls to
the __atomic_add_fetch functions, but in some cases the middle-end can
transform the latter into the former. This patch is originally by
Marc Poulhiès. This fixes
On Fri, Nov 17, 2017 at 11:08 AM Wilco Dijkstra wrote:
>
> Remove SLOW_BYTE_ACCESS given it's confusing, badly named,
> badly documented and used incorrectly. Although most targets
> define it as 1, there are several targets which confuse it
> (based on comments next to it) and set it to 0 since
LGTM, thank you for catching that!!
On Wed, Nov 9, 2022 at 3:50 PM Philipp Tomsich wrote:
>
> A few of the gcc.target/riscv/mcpu-*.c tests have been failing for a
> while now, due to the pipeline model for sifive-7-series not being
> selected despite -mtune=sifive-7-series. The root cause is tha
From: Andrew Pinski
SLOW_SHORT_ACCESS is defined in bfin and i386 target
headers but the target macro is not used elsewhere.
So let's remove it from those two headers and posion it.
OK? Built x86_64-linux-gnu and bfin-elf.
gcc/ChangeLog:
* config/bfin/bfin.h (SLOW_SHORT_ACCESS): Delete
On Wed, Nov 9, 2022 at 5:16 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> SLOW_SHORT_ACCESS is defined in bfin and i386 target
> headers but the target macro is not used elsewhere.
> So let's remove it from those two headers and poison it.
Just to add, this target macro was de
I am not sure if I am missing something, your testcase should rely on
movmisalignhi pattern, but you defined movmisalign with ANYF
mode iterator rather than movmisalign with HI, SI, DI?
And seems the testcase compile with `-march=rv64gc -mabi=lp64
-mtune=size -O2` w/o this patch already generated
On Tue, 08 Nov 2022 11:54:34 PST (-0800), philipp.toms...@vrull.eu wrote:
The strength-reduction implementation in expmed.c will assess the
profitability of using shift-and-add using a RTL expression that wraps
a MULT (with a power-of-2) in a PLUS. Unless the RISC-V rtx_costs
function recognizes
This patch extends -Wdangling-reference to also warn for
auto v = std::minmax(1, 2);
which dangles because this overload of std::minmax returns
a std::pair where the two references are
bound to the temporaries created for the arguments of std::minmax.
This is a common footgun, also described at
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This uses variable templates and constraints to define a much simpler
std::destructible concept. This avoids instantiating the trait
std::is_nothrow_destructible and all its implementation in terms of
__is_destructible_safe and __is_destructible_impl
Hi Prathamesh and Richard,
Thanks for the review and nice suggestions!
> > I guess the transform should work as long as mask is same for both
> > vectors even if it's
> > not constant ?
>
> Yes, please change accordingly (and maybe push separately).
>
Removed VECTOR_CST for integer ops.
> > If
This patch is very preliminary support for a potential new feature to the
PowerPC that extends the current power10 MMA architecture. This feature may or
may not be present in any specific future PowerPC processor.
In the current MMA subsystem for Power10, there are 8 512-bit accumulator
registers
This patch adds support for the -mcpu=future and -mtune=future options.
Besides defining __ARCH_PWR_FUTURE__ this particular patch does not enable any
new features.
These patches implement support for potential future PowerPC cpus. At this
time, features enabled with -mcpu=future may or may not b
This patch enables generating load and store vector pair instructions when
doing certain memory copy operations when -mcpu=future is used. In doing tests
on power10, it was determined that using these instructions were problematical
in a few cases, so we disabled generating them by default. This
The MMA system added the notion of accumulator registers. In power10, these
accumulators overlapped with the FPR registers, but logically the accumulators
were separate from the FPR registers. It is anticipated that in future
systems, we may have a separate dense math unit and the accumulators wi
This patch changes the MMA instructions to use either FPR registers
(-mcpu=power10) or DMRs (-mcpu=future). In this patch, the existing MMA
instruction names are used.
A macro (__PPC_DMR__) is defined if the MMA instructions use the DMRs.
The patches have been tested on the following platforms.
This patch changes the assembler instruction names for MMA instructions from
the original name used in power10 to the new name when used with the dense math
system. I.e. xvf64gerpp becomes dmxvf64gerpp. The assembler will emit the
same bits for either spelling.
The patches have been tested on th
This patch is a prelimianry patch to add the full 1,024 bit dense math register
(DMRs) for -mcpu=future. The MMA 512-bit accumulators map onto the top of the
DMR register.
This patch only adds the new 1,024 bit register support. It does not add
support for any instructions that need 1,024 bit re
On Tue, Dec 5, 2017 at 9:50 AM Thomas Preudhomme
wrote:
>
> Hi,
>
> dump-noaddr test FAILS when $tmpdir is not the same as the directory
> where runtest is called from. Note that this does not happen when
> running make check because tmpdir is set to srcdir.
>
> In that case, file mkdir will creat
Something similar has been proposed before, but didn't get approval.
Jeff wanted a more general framework for ignoring pragmas. It might make
sense to do that, and reuse it for the Darwin-specific 'mark' pragmas.
But as I said in the PR, I looked at the darwin ones and they are unique
among all pra
on 2022/11/9 15:56, Eric Botcazou wrote:
>> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but
>> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada
>> on powerpc64le-linux-gnu, the result looked good. Both x86 and aarch64
>> cfarm machines which I us
On 11/9/22 22:31, Arsen Arsenović wrote:
> ChangeLog:
>
> * doc/baseconf.py: Inject dirname(__file__)/'modules' to path
> instead of just ``.''.
> * doc/gcc_sphinx.py: Moved to...
> * doc/modules/gcc_sphinx.py: ...here.
> ---
> Evening,
>
> This patch addresses a path mixu
Pushed.
ChangeLog:
* doc/baseconf.py: Modernize by using pathlib.
---
doc/baseconf.py | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/doc/baseconf.py b/doc/baseconf.py
index d85659e4540..8021a101e77 100644
--- a/doc/baseconf.py
+++
Hi.
I noticed:
https://gcc.gnu.org/pipermail/gccadmin/2022q4/019260.html
/home/gccadmin/venv/bin/python3: /home/gccadmin/venv/bin/python3: cannot
execute binary file
It will be fixed with the following patch.
@Jakub: Please update the cron.
Thanks,
Martin
maintainer-scripts/ChangeLog:
Hi all,
This patch aims to mention newly added Intel ISA and march support.
Ok for trunk?
BRs,
Haochen
---
htdocs/gcc-13/changes.html | 50 ++
1 file changed, 50 insertions(+)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index bd11cb
在 2022/11/9 下午9:53, Xi Ruoyao 写道:
+;; Convert floating-point numbers to integers
+(define_insn "2"
+ [(set (match_operand:ANYFI 0 "register_operand" "=f")
+ (unspec:ANYFI [(match_operand:ANYF 1 "register_operand" "f")]
+ LRINT))]
+ "TARGET_HARD_FLOAT &&
+ (
+||
On Thu, 10 Nov 2022, Philipp Tomsich wrote:
> Our ifcombine pass combines 2 single-bit tests into a single test of
> the form "(a & T) == T".
>
> However, detection of the bit-tests does not work for sign-bits (of
> any mode) as the RTL presented to the pass uses a cast to a
> signed-type and an
On Thu, 10 Nov 2022, Philipp Tomsich wrote:
> Our ifcombine pass combines 2 single-bit tests into a single test of
> the form "(a & T) == T", requiring the same polarity (i.e., tests for
> bit set/cleared) for both bit-tests. However some applications test
> against two bits expecting one set and
On 11/9/22 02:18, Jakub Jelinek wrote:
On Tue, Nov 08, 2022 at 01:40:03PM -1000, Jason Merrill wrote:
A comment in D2552R1:
"The only questionable (but still conforming) case we found was
[[carries_dependency(some_argument)]] on GCC, where the emitted diagnostic said
that the
carries_dependency
On Wed, 9 Nov 2022, Alexander Monakov wrote:
> For this I would suggest using the tag to neatly fold links
> for old releases. Please see the attached patch.
Loving it, Alexander!
What do you guys think about unfolding all releases we, the GCC project,
currently support (per https://gcc.gnu.org
101 - 131 of 131 matches
Mail list logo
