Snapshot gcc-13-20230909 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230909/
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=111357
--- Comment #1 from Andrew Pinski ---
The front-end does:
hi = instantiate_non_dependent_expr (hi, complain);
hi = cxx_constant_value (hi, complain);
int len = valid_constant_size_p (hi) ? tree_to_shwi (hi) : -1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-09-10
Ever confirmed|0
If a const vector all elements are same, the slide up is unnecessary.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid
unnecessary slideup.
---
gcc/config/riscv/riscv-v.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Vladimir Makarov via Gcc-patches 于2023年9月9日周六 01:04写道：
>
>
> On 8/31/23 04:20, Hongyu Wang wrote:
> > @@ -2542,6 +2542,8 @@ the code of the immediately enclosing expression
> > (@code{MEM} for the top level
> > of an address, @code{ADDRESS} for something that occurs in an
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111341
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
On Sat, 2023-09-09 at 16:21 +0800, chenglulu wrote:
> LGTM!
Pushed r14-3821.
> 在 2023/9/9 下午4:20, Xi Ruoyao 写道:
> > The generic code will split 16-byte copy into two 8-byte copies, so the
> > vector code wouldn't be used even if -mno-strict-align. This
> > contradicted with the purpose of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #13 from Paul Thomas ---
(In reply to anlauf from comment #12)
> Fixed on mainline for gcc-14.
>
> Shall we close it? Or does it deserve backporting?
Hi Harald,
I was considering a backport of a composite finalization patch to
/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230909 (experimental) (GCC)
[520] %
[520] % gcctk -O1 -w small.c
during GIMPLE pass: ccp
small.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-09-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #3 from cqwrteur ---
what i am talking about is uninitialized memory for later initialization like
implementing containers for example
From: redi at gcc dot gnu.org
Sent: Saturday, September 9,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300
--- Comment #2 from Jonathan Wakely ---
The FAIL should be gone after r14-3812-gb96b554592c5cb but the underlying g++
problem is latent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #19 from Xi Ruoyao ---
(In reply to chenglulu from comment #18)
> This problem has been fixed on LA664．
> I don't quite understand why this operation is still needed in !TARGET_64BIT?
It's not needed with !TARGET_64BIT. I just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #2 from Jonathan Wakely ---
This is not a proper bug report. What are you reporting, that you get an error
for some code (what code? where is the testcase? where is the `gcc -v` output?)
or that you want a new feature to support
在 2023/9/8 上午12:14, Xi Ruoyao 写道:
gcc/ChangeLog:
* config/loongarch/loongarch.h (LARCH_MAX_MOVE_PER_INSN):
Define to the maximum amount of bytes able to be loaded or
stored with one machine instruction.
* config/loongarch/loongarch.cc
在 2023/9/8 上午12:33, Xi Ruoyao 写道:
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_block_move_straight):
Check precondition (delta must be a power of 2) and use
popcount_hwi instead of a homebrew loop.
---
I've not run a full bootstrap with this, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111354
--- Comment #3 from d_vampile ---
(In reply to Andrew Pinski from comment #1)
> First off the performance is difference is die to micro-arch issues with
> unaligned stores of 256 bits.
>
> Also iirc rte_mov128blocks is tuned at copying blocks
On Sat, 2023-09-09 at 14:26 +0800, Yang Yujie wrote:
> I remember you were against it because you think non-multilib users
> would be punished because the libdir layout changes (no toplevel).
> However this directory should be (mostly) private to each gcc instance,
> so I don't see real
Pushed r14-3818 with test cases added. The pushed patch is attached.
On Sat, 2023-09-09 at 14:10 +0800, chenglulu wrote:
>
> 在 2023/9/8 上午12:14, Xi Ruoyao 写道:
> > gcc/ChangeLog:
> >
> > * config/loongarch/loongarch.h (LARCH_MAX_MOVE_PER_INSN):
> > Define to the maximum amount
Pushed r14-3819.
On Sat, 2023-09-09 at 14:16 +0800, chenglulu wrote:
>
> 在 2023/9/8 上午12:33, Xi Ruoyao 写道:
> > gcc/ChangeLog:
> >
> > * config/loongarch/loongarch.cc
> > (loongarch_block_move_straight):
> > Check precondition (delta must be a power of 2) and use
> >
Hi,RuoYao:
I think the test example memcpy-vec-3.c submitted in r14-3818 is
implemented incorrectly.
The 16-byte length in this test example will cause can_move_by_pieces to
return true when with '-mstrict-align', so no vector load instructions
will be generated.
在 2023/9/8 上午12:14, Xi
在 2023/9/9 下午3:06, Xi Ruoyao 写道:
On Sat, 2023-09-09 at 15:04 +0800, chenglulu wrote:
Hi,RuoYao:
I think the test example memcpy-vec-3.c submitted in r14-3818 is
implemented incorrectly.
The 16-byte length in this test example will cause can_move_by_pieces to
return true when with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #16 from chenglulu ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to chenglulu from comment #13)
> > (In reply to Xi Ruoyao from comment #12)
> > > (In reply to chenglulu from comment #11)
> > > > (In reply to Xi Ruoyao
LGTM!
在 2023/9/9 下午4:20, Xi Ruoyao 写道:
The generic code will split 16-byte copy into two 8-byte copies, so the
vector code wouldn't be used even if -mno-strict-align. This
contradicted with the purpose of this test case.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/memcpy-vec-3.c:
Le 08/09/2023 à 23:22, Harald Anlauf via Fortran a écrit :
Am 08.09.23 um 12:04 schrieb Mikael Morin via Gcc-patches:
Hello,
this avoids some redundant work in the symbol deletion code, which is
used a lot by the parser to cancel statements that fail to match in the
end.
I haven't tried to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330
--- Comment #6 from Gaius Mulley ---
Created attachment 55864
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55864=edit
Proposed fix
Here is a proposed interim patch. In the meantime I'll hunt down the missing
case clause (and fix the
On Sat, Sep 09, 2023 at 01:56:57PM +0800, Xi Ruoyao wrote:
> On Sat, 2023-09-09 at 10:46 +0800, Yang Yujie wrote:
> > The next option I can think of would be MULTILIB_EXTRA_OPTS, where
> > -fmultiflags
> > fit in nicely. However, these options won't reach the toplevel builds, and
> > tweaking
PR 111334
gcc/ChangeLog:
* config/loongarch/loongarch.md: Fix bug of di3_fake.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr111334.c: New test.
---
gcc/config/loongarch/loongarch.md | 14 +--
gcc/testsuite/gcc.target/loongarch/pr111334.c | 39
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
addi a2,1
sd a2,8(t2)
into the following
On Sat, 2023-09-09 at 15:14 +0800, chenglulu wrote:
>
> 在 2023/9/9 下午3:06, Xi Ruoyao 写道:
> > On Sat, 2023-09-09 at 15:04 +0800, chenglulu wrote:
> > > Hi,RuoYao:
> > >
> > > I think the test example memcpy-vec-3.c submitted in r14-3818 is
> > > implemented incorrectly.
> > >
> > > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #17 from Xi Ruoyao ---
I think the proper description should be:
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..000d17b0ba6 100644
--- a/gcc/config/loongarch/loongarch.md
+++
On Sat, 2023-09-09 at 15:42 +0800, Lulu Cheng wrote:
> PR 111334
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md: Fix bug of di3_fake.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/loongarch/pr111334.c: New test.
Ok. Despite I still think we should use unspec
The generic code will split 16-byte copy into two 8-byte copies, so the
vector code wouldn't be used even if -mno-strict-align. This
contradicted with the purpose of this test case.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/memcpy-vec-3.c: Increase the amount of
copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > (In reply to Francois-Xavier Coudert from comment #3)
> > > Clang: 14.0.0 build 1400
> > > CLT: 14.2.0.0.1.1668646533
On Sat, 2023-09-09 at 15:04 +0800, chenglulu wrote:
> Hi,RuoYao:
>
> I think the test example memcpy-vec-3.c submitted in r14-3818 is
> implemented incorrectly.
>
> The 16-byte length in this test example will cause can_move_by_pieces to
> return true when with '-mstrict-align', so no vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #18 from chenglulu ---
(In reply to Xi Ruoyao from comment #17)
> I think the proper description should be:
>
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index 75f641b38ee..000d17b0ba6
This new version fixes the issues discussed in v4 and also fixes an
issue that is described in the newly introduced
compute_validity_closure.
Bootstrapped on x86-64 and AArch64.
I also ran the GCC testsuite on x86-64, AArch64 and RISCV64. There are
no regressions except for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Hi!
On 2017-01-23T15:10:44-0700, Jeff Law wrote:
> On 01/19/2017 04:46 AM, Martin Liška wrote:
>> Following patch fixes asan bootstrap, as mentioned in the PR.
>>
>> Ready to be installed?
>> * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Insert assert
>> that would prevent us to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111355
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356
--- Comment #1 from comer352l at googlemail dot com ---
Created attachment 55866
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55866=edit
cpp file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356
Bug ID: 111356
Summary: Segmentation fault when compiling large static data
structure
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356
--- Comment #2 from Andrew Pinski ---
Works for me on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #6 from Jonathan Wakely ---
Defect reports to WG21 do not go to GCC's bugzilla though.
And it's not a defect, it's the intended design, working as intended and
approved by the committee. Just because you don't like it, doesn't make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #8 from John Soo ---
> Also, it is typically Windows that suffers from this limitation of command
> line length.
Ok that may be true but I am effected by this on linux as are quite a few
others in this issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Benjamin Priour :
https://gcc.gnu.org/g:50b5199cff690891726877e1c00ac53dfb7cc1c8
commit r14-3823-g50b5199cff690891726877e1c00ac53dfb7cc1c8
Author: benjamin priour
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #5 from cqwrteur ---
It's evident that there's a flaw in the standard, making it impossible to
allocate uninitialized memory for freestanding environments. That's precisely
why I reported it as a potential issue for future
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300
--- Comment #3 from Jonathan Wakely ---
Possibly relevant, compiling anything including with
-Wsystem-headers -Wabi gives these warnings:
/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace: At global scope:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111355
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Andrew Pinski changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
John Soo changed:
What|Removed |Added
CC||john.soo+gcc-bugzilla@arist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #7 from Costas Argyris ---
(In reply to John Soo from comment #6)
> This is not a Windows-only bug, so I don't think it is fixed.
Althought it is not mentioned explicitly in the title of this PR, the original
reporter did describe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #9 from John Platts ---
Created attachment 55867
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55867=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug
The attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #10 from John Platts ---
Created attachment 55868
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55868=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug
The ppc9_test_sat_widen_pairwise_add_090923_2b.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #7 from Jonathan Wakely ---
And there are a number of proposals related to increasing how much of the
standard library is available for freestanding, which might eventually meet
your needs. But it would help if you stop publicly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #11 from John Platts ---
Created attachment 55869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55869=edit
Test program to reproduce GCC 12 compilation bug
Here is the expected output of the ppc9_test_sat_add_090923.cpp test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Jonathan Wakely from comment #2)
> The FAIL should be gone after r14-3812-gb96b554592c5cb
Also: thanks!
To make the dump FILE not too big, add TDF_DETAILS.
This patch fix these following FAILs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl, -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions comparison
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Sunday, September 10, 2023 9:22 AM
To: Juzhe-Zhong
Cc: GCC Patches ; Kito Cheng
Subject: Re: [PATCH] RISC-V: Fix dump FILE of VSETVL PASS[PR111311]
LGTM
Juzhe-Zhong 於
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
Bug ID: 111357
Summary: __integer_pack fails to work with values of dependent
type convertible to integers
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #5 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:0d50facd937bda26e3083046dc5dec8fca47e1e6
commit r14-3825-g0d50facd937bda26e3083046dc5dec8fca47e1e6
Author: Juzhe-Zhong
Date: Sun Sep
When debugging FAIL: gcc.dg/pr92301.c execution test.
Realize a vls vector permutation situation failed to vectorize since early
return false:
- /* For constant size indices, we dont't need to handle it here.
- Just leave it to vec_perm. */
- if (d->perm.length ().is_constant ())
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300
--- Comment #4 from Hans-Peter Nilsson ---
(In reply to Jonathan Wakely from comment #2)
> The FAIL should be gone after r14-3812-gb96b554592c5cb
Confirmed
> but the underlying
> g++ problem is latent.
So, keeping this PR open is TRT?
LGTM
Juzhe-Zhong 於 2023年9月10日 週日 07:58 寫道：
> To make the dump FILE not too big, add TDF_DETAILS.
>
> This patch fix these following FAILs in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
>
> FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl, -O3
> -fomit-frame-pointer -funroll-loops
68 matches
Mail list logo
