Hi All,
Just sending these so people can test the series.
This is a small QoL codegen improvement for match.pd to not emit labels when
they are not needed. The codegen is nice and there is a small (but consistent)
improvement in compile time.
Bootstrapped Regtested on aarch64-none-linux-gnu
> If we want to fix it in the combiner, I think the fix would be following.
> The optimization is about
> (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c))
> and IMHO we can only optimize it into
> (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0)
> if we know that the upper bits of the
Hello All:
Eliminate unnecessary redundant extension within basic and across basic blocks.
For rs6000 target we see redundant zero and sign extension and done to improve
ree pass to eliminate such redundant zero and sign extension.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks &
On Wed, Apr 05, 2023 at 04:10:25PM -0400, 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 propagate a constant into it), its
> possible the ssa-name
maintainer-scripts/ChangeLog:
* update_web_docs_git: Add updated Texinfo to PATH
---
Hi,
I'm posting this as a ping and a patch necessary to get the wwwdocs
building with the new Texinfo version that's installed on gcc.gnu.org.
It would be nice to do this ahead of the GCC 13 release.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698
Matthijs Kooijman changed:
What|Removed |Added
CC||matthijs at stdin dot nl
---
Prathamesh Kulkarni writes:
> On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
> wrote:
>> > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
>> > b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
>> > index cd9cace3c9b..3de79060619 100644
>> > ---
On Thu, Apr 06, 2023 at 12:15:51PM +0200, Eric Botcazou wrote:
> > Originally I didn't really see this as an operation. But the more and
> > more I ponder it feels like it's an operation and thus should be subject
> > to WORD_REGISTER_OPERATIONS.
> >
> > While it's not really binding on RTL
On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Mon, 13 Mar 2023 at 13:03, Richard Biener wrote:
> >> On GIMPLE it would be
> >>
> >> _1 = { a, ... }; // (a)
> >> _2 = { _1, ... }; // (b)
> >>
> >> but I'm not sure if (b), a VL CTOR of fixed len(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
--- Comment #5 from Xi Ruoyao ---
(In reply to Jonathan Wakely from comment #4)
> N.B. this code is just copied from PR 54402. It might have been helpful to
> say where you found the code.
>
> zhonghao, it's really not helpful to just copy
> Originally I didn't really see this as an operation. But the more and
> more I ponder it feels like it's an operation and thus should be subject
> to WORD_REGISTER_OPERATIONS.
>
> While it's not really binding on RTL semantics, if we look at how some
> architectures implement reg->reg copies,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433
Bug ID: 109433
Summary: [12/13 Regression] ICE with -std=c++11 and static
constexpr array inside a template constexpr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Hi!
I've noticed
make: Circular build/genrvv-type-indexer.o <- gtype-desc.h dependency dropped.
The following patch fixes that. The RTL_BASE_H variable includes a lot of
headers which the generator doesn't include, including gtype-desc.h.
I've preprocessed it and checked all gcc/libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
--- Comment #1 from Andrew Pinski ---
Reduced:
```
struct RangeLimits
{
int low = 0;
int high = 1;
constexpr RangeLimits() { }
};
template
int parameterLimits(void)
{
static RangeLimits constexpr param_limits[ 2 ] = {};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
--- Comment #3 from Jovan Dmitrović ---
Another thing that has come to attention is the register pressure costs being
calculated improperly. More information and a patch are submitted at the link
below.
Yes, RISC-V riscv.h defined the WORD_REGISTER_OPERATIONS to be 1, while
aarch64.h defined it as 0, with below comments. No idea this can fit RISC-V or
not.
/* WORD_REGISTER_OPERATIONS does not hold for AArch64.
The assigned word_mode is DImode but operations narrower than SImode
behave as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
--- Comment #2 from Jovan Dmitrović ---
*** Bug 109430 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109430
Jovan Dmitrović changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
--- Comment #4 from Jonathan Wakely ---
N.B. this code is just copied from PR 54402. It might have been helpful to say
where you found the code.
zhonghao, it's really not helpful to just copy code that you don't
understand into bug reports
Jeff Law writes:
> On 4/5/23 10:48, Jakub Jelinek wrote:
>> On Wed, Apr 05, 2023 at 10:17:59AM -0600, Jeff Law wrote:
It is true that an instruction like
(insn 8 7 9 2 (set (reg:HI 141)
(subreg:HI (reg:SI 142) 0)) "aauu.c":6:18 181 {*movhi_internal}
(nil))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
--- Comment #14 from Jonathan Wakely ---
You need to change godbolt.org to compile C not C++. Please stop adding
completely useless comments to bugzilla or I will block your account.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480
--- Comment #5 from Jonathan Wakely ---
(In reply to zhonghao from comment #4)
> Is this bug fixed? I tried the latest gcc, but it still rejects the sample
> code.
No, the latest gcc accepts this C code without errors. Please stop commenting
on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508
--- Comment #3 from Jonathan Wakely ---
(In reply to Frank Heckenbach from comment #2)
> And all that because the library
> doesn't know what the space character is in UTF-8.
That's a completely wrong description of the problem.
The standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407
--- Comment #2 from johgjc ---
thank you very much.
At 2023-04-04 23:55:25, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407
>
>Andrew Pinski changed:
>
> What|Removed
Sigh thank you :)
I'll blame this on the construction work going on in the building /s
I have rebased the commits, built them and tested them, and they are now
properly pushed.
Thanks Thomas :)
On 4/6/23 09:59, Thomas Schwinge wrote:
Hi Arthur!
On 2023-04-05T16:02:43+0200,
Sigh thank you :)
I'll blame this on the construction work going on in the building /s
I have rebased the commits, built them and tested them, and they are now
properly pushed.
Thanks Thomas :)
On 4/6/23 09:59, Thomas Schwinge wrote:
Hi Arthur!
On 2023-04-05T16:02:43+0200,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
--- Comment #1 from Jovan Dmitrović ---
It seems that commit f9f69dd changed the way complexity is calculated, so now
the complexity equals zero across the board, for each candidate.
Here is one testcase:
void daxpy(float *vector1, float
On Thu, 2023-04-06 at 16:19 +0800, Lulu Cheng wrote:
> gcc/ChangeLog:
>
> * doc/extend.texi: Add section for LoongArch BASE Built-in functions.
> ---
> gcc/doc/extend.texi | 89 +
> 1 file changed, 89 insertions(+)
>
> diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
zhonghao at pku dot org.cn changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480
zhonghao at pku dot org.cn changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109432
Bug ID: 109432
Summary: tracker bug for issues with -Wanalyzer-out-of-bounds
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Hi Alexandre,
on 2023/4/6 14:19, Alexandre Oliva wrote:
>
> Skip ppc-fortran.exp if a trivial fortran program cannot be compiled.
>
IIUC, without this patch and under the configuration disabling fortran,
all the cases in this sub-testsuite would fail? Thanks for fixing!
> Regstrapped on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
Bug ID: 109431
Summary: internal compiler error: in
output_constructor_regular_field (varasm.c:5207)
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity:
Hi Haochen,
on 2023/4/6 13:35, HAO CHEN GUI wrote:
> Hi,
> This patch removes byte reverse operation before vector integer sign
> extension on big endian. These built-ins require to sign extend the element
> of the input vector that would fall in the least significant portion of the
> result
gcc/ChangeLog:
* doc/extend.texi: Add section for LoongArch BASE Built-in functions.
---
gcc/doc/extend.texi | 89 +
1 file changed, 89 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 3adb67aa47a..417af6c368d 100644
Hi Arthur!
On 2023-04-05T16:02:43+0200, arthur.co...@embecosm.com wrote:
> This patchset contains around 80 commits concerning the Rust frontend.
Did you not intend to actually 'git push' those? ;-P
Grüße
Thomas
> We have been hard at work trying to get the Rust core library to
> compile,
Hi Arthur!
On 2023-04-05T16:02:43+0200, arthur.co...@embecosm.com wrote:
> This patchset contains around 80 commits concerning the Rust frontend.
Did you not intend to actually 'git push' those? ;-P
Grüße
Thomas
> We have been hard at work trying to get the Rust core library to
> compile,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109430
Bug ID: 109430
Summary: ivopts: Revert register pressure cost when there are
enough registers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
Bug ID: 109429
Summary: ivopts: Compute complexity for unsupported addressing
modes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Looks like I did this only in my head back then. Finally pushed.
Thanks!
ChangeLog:
* MAINTAINERS: Add myself.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c8045d49861..cebf45d49e5 100644
--- a/MAINTAINERS
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495
--- Comment #8 from Jakub Jelinek ---
No, works just fine. Perhaps you are compiling with C++ when this is C?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696
--- Comment #12 from Jakub Jelinek ---
If you are trying to compile C code which isn't valid C++ by C++, then such an
error is expected.
Hi Alexandre,
on 2023/4/6 13:20, Alexandre Oliva wrote:
> Hello, Kewen,
>
> On Mar 27, 2023, "Kewen.Lin" wrote:
>
>> on 2023/3/25 16:35, Alexandre Oliva wrote:
>
>>> The first loop in main gets stores "vectorized" on powerpc into
>>> full-word stores, even without any vector instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495
zhonghao at pku dot org.cn changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
I spotted this problem while trying to collate my WIP patches (sorry
for not spotting it when the original patch was discussed).
Although we do not yet have any regression filed against this (AFAIK),
it's only a matter of time - so I'd suggest that we should apply to
13.
Tested on
Add Zcmp extension testcases, zcmpe means Zcmp with RVE extension.
Co-Authored by: Nandni Jamnadas
Co-Authored by: Yulong Shi
Co-Authored by: Shihua Liao
Co-Authored by: Sinan Lin
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zc-zcmp-push-pop-1.c: New test.
*
This patch is the minimal support for ZC* extensions, include the extension
name, mask and target defination. Also define the dependencies with Zca
and Zce extension. Notes that all ZC* extensions depend on the Zca extension.
Zce includes all relevant ZC* extensions for microcontrollers using. Zce
Add Zcmp extension instructions support. Generate push/pop
with follow steps:
1. preprocessing:
1.1. if there is no push rtx, then just return. e.g.
(note 5 1 22 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn/f 22 5 23 2 (set (reg/f:SI 2 sp)
(plus:SI (reg/f:SI 2 sp)
(const_int
RISC-V Code Size Reduction(ZC*) extensions is a group of extensions
which define subsets of the existing C extension (Zca, Zcd, Zcf) and new
extensions(Zcb, Zcmp, Zcmt) which only contain 16-bit encodings.[1]
The implementation of the RISC-V Code Size Reduction extension in GCC is
an important
From: Charlie Keaney
Add all ZC* extensions march args tests.
Co-Authored by: Nandni Jamnadas
Co-Authored by: Jiawei
Co-Authored by: Mary Bennett
Co-Authored by: Simon Cook
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-20.c: New test.
* gcc.target/riscv/arch-21.c: New
This patch enables the compressible features with ZC* extensions.
Since all ZC* extension depends on the Zca extension, it's sufficient to only
add the target Zca to extend the target RVC.
Co-Authored by: Mary Bennett
Co-Authored by: Nandni Jamnadas
Co-Authored by: Simon Cook
gcc/ChangeLog:
Skip ppc-fortran.exp if a trivial fortran program cannot be compiled.
Regstrapped on x86_64-linux-gnu and ppc64-linux-gnu. Also tested on
ppc64-vx7r2 with gcc-12, with the Fortran language disabled. Ok to
install?
for gcc/testsuite/ChangeLog
*
Hi Alexandre,
on 2023/4/6 12:43, Alexandre Oliva wrote:
> Hello, Kewen,
>
> Thanks for the feedback.
>
> On Mar 27, 2023, "Kewen.Lin" wrote:
>
>> on 2023/3/25 16:37, Alexandre Oliva via Gcc-patches wrote:
>>>
>>> When long double is 64-bit wide, as on vxworks, the rs6000 backend
>>> defines
101 - 155 of 155 matches
Mail list logo