It is not a target specific issue, it will fail if we enabled AVX.
e.g.:
$ /export/users/haochenj/env/build_no_bootstrap_master/gcc/xgcc
-B/export/users/haochenj/env/build_no_bootstrap_master/gcc/
/export/users/haochenj/src/gcc/master/gcc/testsuite/gcc.dg/gnu23-tag-4.c -m64
-mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #13 from Lipeng Zhu ---
OK, I think I find the root cause of this error, when thread number greater
than 1000, the file_name = 1000_tst.dat, character(11) will overflow. This will
generate the same file_name like ***_tst.dat.
diff
OK. This sub-patch is ok to commit after adding new line to prefix.c
juzhe.zh...@rivai.ai
发件人： joshua
发送时间： 2023-12-25 15:08
收件人： juzhe.zh...@rivai.ai; gcc-patches
抄送： Jim Wilson; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; jinma; cooper.qu
主题： 回复：[PATCH v4 4/6] RISC-V:
+ if (current_output_insn == NULL_RTX)
+ return p;
This is for inline assembly case.
--
发件人：juzhe.zh...@rivai.ai
发送时间：2023年12月25日(星期一) 14:37
收件人："cooper.joshua";
"gcc-patches"
抄 送：Jim Wilson; palmer;
andrew; "philipp.tomsich";
+ if (current_output_insn == NULL_RTX)
+return p;
What is this used for ?
How about:
+ /* We need to add th. prefix to all the xtheadvector
+ insturctions here.*/
+ if (TARGET_XTHEADVECTOR && p[0] == 'v')
+fputs ("th.", asm_out_file);
\ No newline at end of file
New line should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113131
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-12-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113131
Bug ID: 113131
Summary: `((A)^C)|B` should be simplified to `C | B`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(BASE): Define new builtin bases.
*
This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share
This patch adds th. prefix to all XTheadVector instructions by
implementing new assembly output functions. In this version, we
follow Kito's suggestions and only check the prefix is 'v', so that
no extra attribute is needed.
gcc/ChangeLog:
* config/riscv/riscv-protos.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #12 from Lipeng Zhu ---
(In reply to Lipeng Zhu from comment #9)
> Since I still can't reproduce the failure on my side :(, just curious, will
> the new added 'rwlock' test cases failed on mutex lock?
OK, I rerun these rwlock* test
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/pr113112-1.c: Add one more ASM check.
---
gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr113112-1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr113112-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832
--- Comment #14 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:59ecd5ff096f800de17b804f1482055f2d84d629
commit r14-6827-g59ecd5ff096f800de17b804f1482055f2d84d629
Author: Andrew Pinski
Date:
In the testcase provided, we would match f_plus but not g_plus
due to a missing `:c` on the plus operator. This fixes the oversight
there.
Note this was noted in https://github.com/llvm/llvm-project/issues/76318 .
Committed as obvious after bootstrap/test on x86_64-linux-gnu.
PR
We found that using the latest compiled gcc will cause a miscompare error
when running spec2006 400.perlbench test with -flto turned on. After testing,
it was found that only the LoongArch architecture will report errors.
The first error commit was located through the git bisect command as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #11 from Lipeng Zhu ---
(In reply to Jakub Jelinek from comment #10)
>For what I can reproduce on my box (rwlock_1.exe built in the
>x86_64-pc-linux-gnu/libgomp/testsuite subdirectory using the -O0
>compilation line from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #26 from JuzheZhong ---
CC Li Pan who may also reproduce the bugs for me.
Plz give us more details how to reproduce the bugs since we don't see any bugs
when build and run SPEC.
在 2023/12/24 下午8:59, Xi Ruoyao 写道:
On Sat, 2023-12-23 at 18:47 +0800, Xi Ruoyao wrote:
On Sat, 2023-12-23 at 18:44 +0800, Xi Ruoyao wrote:
On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote:
The performance drop has nothing to do with this patch. I found that the h264
performance compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #22 from YunQiang Su ---
Any way, we should split the assert to another patch.
I will try to find all the wrongly used TRULY_NOOP_TRUNCATION_MODES_P.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #21 from YunQiang Su ---
Sorry, Roger. Your patch is correct.
I misunderstood it.
Thanks for the tip!
2023年12月24日(日) 23:35 Jonathan Wakely :
> This mailing list is for automated emails from our bug database, not
> for reporting bugs directly.
>
> See https://gcc.gnu.org/bugs/ for how to report bugs, thanks.
>
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|middle-end
--- Comment #11 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #20 from YunQiang Su ---
This patch has 2 problems:
1. We may need some more steps to add
gcc_assert (outprec < inprec)
Now, I met some ICE with it.
2. It doesn't solve the this problem:
In combine.cc, jump_insn eats
Snapshot gcc-14-20231224 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20231224/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113130
Bug ID: 113130
Summary: `abs(a) == b` could be expanded as `(a == b || a ==
-b)`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111837
Andrew Pinski changed:
What|Removed |Added
CC||gigor-ads at yandex dot ru
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128
Igor S Gerasimov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-12-24
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
--- Comment #2 from Larry Smith ---
@Andrew Thanks for the feedback. I don't work in Unix-like environments though
normally (including Linux) so CMake, make, and shell commands are something I
rarely work with (I specialize on Microsoft
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-12-24
Ever confirmed|0
Hi All,
This patch was pre-appproved by Richi.
This updates the testsuite and adds more #pragma GCC novector to various tests
that would otherwise vectorize the vector result checking code.
This cleans out the testsuite since the last rebase and prepares for the landing
of the early break
This test needs fma support. It is only available on hppa in PA 2.0.
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
hppa: Fix pr110279-1.c on hppa
2023-12-24 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/pr110279-1.c: Add -march=2.0 option on hppa*-*-*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
Bug ID: 113129
Summary: "using declaration" not detected as "exported" in
exported namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128
Bug ID: 113128
Summary: Wrong implied-do with optimizations
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #11 from andysem at mail dot ru ---
> I'm not sure what you mean by "the compiler is free to generate code that
> takes it into account." Takes what into account? What problem does that
> freedom cause?
I mean the compiler could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113127
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #19 from Roger Sayle ---
Created attachment 56930
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56930=edit
proposed patch
And now for a patch that does (or should) work. This even contains an
optimization, we middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #10 from Peter Dimov ---
Maybe the right thing to do is to use dynamic_cast only for virtual inheritance
(either have a trait or check whether static_cast isn't a valid expression),
otherwise static_cast, in both cases (standard and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Peter Dimov from comment #7)
> > You don't necessarily need dynamic_cast because facets are always installed
> > and obtained by their exact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #8 from Jonathan Wakely ---
(In reply to Peter Dimov from comment #7)
> You don't necessarily need dynamic_cast because facets are always installed
> and obtained by their exact type, not via a reference to base.
Is that true?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111485
--- Comment #5 from GCC Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:84cab505d69038647d98f9340559fc941446e479
commit r11-11168-g84cab505d69038647d98f9340559fc941446e479
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111485
--- Comment #4 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:f24d6f0031fd515e6497c8c96446afd02aa4dbaa
commit r12-10068-gf24d6f0031fd515e6497c8c96446afd02aa4dbaa
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #7 from Peter Dimov ---
You don't necessarily need dynamic_cast because facets are always installed and
obtained by their exact type, not via a reference to base. You can store the
Facet* as given (like shared_ptr does), and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #6 from Jonathan Wakely ---
(In reply to andysem from comment #3)
> I think, a failing dynamic_cast would not be useful as this would make
> std::use_facet unusable with -fno-rtti.
I don't see a problem with that. If you want to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #5 from Jonathan Wakely ---
I'm not sure what you mean by "the compiler is free to generate code that takes
it into account." Takes what into account? What problem does that freedom
cause?
The locale facet instantiations are
This mailing list is for automated emails from our bug database, not
for reporting bugs directly.
See https://gcc.gnu.org/bugs/ for how to report bugs, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
--- Comment #6 from Jonathan Wakely ---
OK that's great, thanks for clarifying. (I haven't looked at the impl on
godbolt yet, sorry)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #18 from Roger Sayle ---
Please ignore comment #17, the above patch is completely bogus/broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #17 from Roger Sayle ---
I think this patch might resolve the problem (or move it somewhere else):
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 9fef2bf6585..218bca905f5 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6274,10 +6274,7
On Sat, 2023-12-23 at 18:47 +0800, Xi Ruoyao wrote:
> On Sat, 2023-12-23 at 18:44 +0800, Xi Ruoyao wrote:
> > On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote:
> > > > The performance drop has nothing to do with this patch. I found that
> > > > the h264 performance compiled
> > > > by r14-6787
On Sun, 2023-12-24 at 01:04 +0800, Xi Ruoyao wrote:
> On Sun, 2023-12-24 at 00:56 +0800, Xi Ruoyao wrote:
> > On Sat, 2023-12-23 at 15:00 +0800, chenglulu wrote:
> > > Hi,
> > >
> > > This patch will cause the following tests to fail:
> > >
> > > +FAIL: gcc.dg/vect/pr97081-2.c (internal compiler
gcc/ChangeLog:
* config/loongarch/loongarch.md (rotl3):
New define_expand.
* config/loongarch/simd.md (vrotl3): Likewise.
(rotl3): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/rotl-with-rotr.c: New test.
*
> > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't
> > > actually a truncation! The output precision is first, the input
> > > precision is second. The docs explicitly state the output precision
> > > should be smaller than the input precision (which makes sense for
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113127
Bug ID: 113127
Summary: Unexpected error: '' was not declared
'constexpr'
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
On Sun, Dec 24, 2023, 01:18 YunQiang Su wrote:
> Roger Sayle 于2023年12月24日周日 16:51写道：
> >
> >
> > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> > > truncation! The output precision is first, the input precision is
> second. The docs
> > > explicitly state the
Roger Sayle 于2023年12月24日周日 16:51写道：
>
>
> > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> > truncation! The output precision is first, the input precision is second.
> > The docs
> > explicitly state the output precision should be smaller than the input
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #14 from Hans-Peter Nilsson ---
(In reply to GCC Commits from comment #9)
> The master branch has been updated by Hans-Peter Nilsson :
>
> https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0
>
> commit
> What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> truncation! The output precision is first, the input precision is second.
> The docs
> explicitly state the output precision should be smaller than the input
> precision
> (which makes sense for truncation).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Roger Sayle 于2023年12月24日周日 08:49写道：
>
>
> Hi YunQiang (and Jeff),
>
> > MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true
> > based on that the hard register is always sign-extended, but here
> > the hard register is polluted by zero_extract.
>
> I suspect that the bug here is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
224094952-gbd901d76734-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231224 (experimental) (GCC)
> > Yes. I also guess so. Any new idea?
> Well, I see multiple intertwined issues and I think MIPS has largely
> mucked this up.
>
> At a high level DI -> SI truncation is not a nop on MIPS64. We must
> explicitly sign extend the value from SI->DI to preserve the invariant
> that SI mode objects
64 matches
Mail list logo
