On 2021/10/29 19:52, Richard Biener wrote:
> On Wed, 27 Oct 2021, Xionghu Luo wrote:
>
>> loop_version currently does lv_adjust_loop_entry_edge
>> before it loopifys the copy inserted on the header. This patch moves
>> the condition generation later and thus we have four pieces to help
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013
--- Comment #5 from Andrey ---
Sorry, my fault, spanhttps://eel.is/c++draft/views.span#span.overview-4. It looks strange for me,
but of course, it's not a topic for this tracker.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991
--- Comment #3 from luoxhu at gcc dot gnu.org ---
(In reply to Kewen Lin from comment #2)
> (In reply to luoxhu from comment #1)
> > Couldn't reproduce on rain6p1 (P10):
> >
>
> It's weird, I can reproduce this on rain6p1.
>
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #45 from Eric Gallager ---
(In reply to Martin Liška from comment #0)
> [...]
> Then I built GCC with -j1 and used following parser to generate reports:
> https://github.com/marxin/script-misc/blob/master/parse-make-log.py
The new
On 10/31/21 1:50 PM, Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
PR fortran/101337
gcc/fortran/ChangeLog:
* resolve.c (resolve_operator): Continue resolving on op2 error.
---
The PR rightfully notes that we only diagnose the right operator
and do not check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102955
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102657
--- Comment #5 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:7a71ea4df7e97a640e6747d6787a1885eb3bbc40
commit r12-4817-g7a71ea4df7e97a640e6747d6787a1885eb3bbc40
Author: Martin Liska
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #4 from TC
PR101145 is supporting if the number of iterations can be calculated
for the 'until wrap' condition. Current test cases are checking if
the loop can be vectorized, if a loop can be vectorized then the number
of interations is known. While it would be better to check the loop's
number of
> (I'm assuming the difference is due to some architectural
> constraints as opposed to arbitrary limitations in the code
There're 2 difference:
1. target support unaligned store or not.
2. target support move by piece or not(which will enable block move in gimple
level).
Updated patch.
Adjust
On Fri, Oct 8, 2021 at 10:57 AM Fāng-ruì Sòng wrote:
>
> On Fri, Sep 24, 2021 at 11:29 AM H.J. Lu wrote:
> >
> > On Fri, Sep 24, 2021 at 11:14 AM Fāng-ruì Sòng wrote:
> > >
> > > On Fri, Sep 24, 2021 at 10:41 AM H.J. Lu wrote:
> > > >
> > > > On Fri, Sep 24, 2021 at 10:29 AM Fāng-ruì Sòng
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
From: Bernhard Reutner-Fischer
contrib/ChangeLog:
* testsuite-management/validate_failures.py: 2to3
---
Tested with python-3.9.7 where it now works again.
---
.../testsuite-management/validate_failures.py | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
Snapshot gcc-12-20211031 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20211031/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Fri, 29 Oct 2021 22:09:07 +0200
Bernhard Reutner-Fischer wrote:
> On Fri, 29 Oct 2021 21:36:26 +0200
> Harald Anlauf via Gcc-patches wrote:
>
> > Dear Bernhard, all,
> >
> > Am 29.10.21 um 02:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> >
> > >> diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #12 from Han Boetes ---
Wow, thanks, let's see if I can manage that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> I looked and I see openbsd has a patch which adds fname_as_string to one of
> the generic parts of GCC which is causing this.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #9 from Andrew Pinski ---
Do you have any patches that gets applied to the gcc sources from say openbsd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #8 from Han Boetes ---
Well that's unexpected…
/usr/local/lib % ag -a fname_as_string
Binary file libgccjit.so.0.0.1 matches.
gcc/x86_64-unknown-openbsd7.0/11.2.0/plugin/include/c-family/c-common.h
extern const char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #7 from Andrew Pinski ---
Can you post the output of "nm /usr/local/lib/libgccjit.so.0.0.1"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #6 from Han Boetes ---
So this is what I did:
% export LD_DEBUG=yes
% /usr/pkgmk/work/emacs/src/emacs/lisp % ../src/bootstrap-emacs -batch
--no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l comp -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102715
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
Dear Fortranners,
the fix for initialization of DT arrays caused an apparent regression for
cases where inconsistent ranks were used in such an initialization.
This caused either an ICE in subsequent uses of these arrays, or showed
up in valgrind as invalid reads, all of which seemed to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #5 from David Malcolm ---
(In reply to David Malcolm from comment #4)
> Hopefully that will give a hint as to where that symbol is coming from.
...or, rather, where the *usage* of that symbol is coming from.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #4 from David Malcolm ---
I'm not sure how best to debug this.
$ echo _Z15fname_as_stringi | c++filt
fname_as_string(int)
and indeed, that seems to be just for the C/C++ frontends, not for libgccjit.
Some ideas:
Given:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #3 from Han Boetes ---
I've just grepped the Emacs code for 'fname_as_string' and it isn't in there
either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #2 from Andrew Pinski ---
gcc/ChangeLog-2001: (fname_as_string): Likewise.
gcc/ChangeLog-2001: (fname_as_string): New function from remnants of
gcc/ChangeLog-2003: * c-common.c (fname_as_string): Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #1 from Andrew Pinski ---
fname_as_string is only defined in the C/C++ front-ends ...
c-family/ChangeLog: * c-common.c (fname_as_string): Use cxx_printable_name
for
c-family/c-common.c:fname_as_string (int pretty_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
Bug ID: 103016
Summary: libgccjit on OpenBSD-7.0 fails with
bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1:
undefined symbol '_Z15fname_as_stringi'
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #7 from Jan Hubicka ---
this is compile time plot
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=227.270.8
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.270.8
(-O2 and -Ofast with lto)
Things has improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
Bernhard Reutner-Fischer changed:
What|Removed |Added
Keywords||patch
URL|
From: Bernhard Reutner-Fischer
PR fortran/101337
gcc/fortran/ChangeLog:
* resolve.c (resolve_operator): Continue resolving on op2 error.
---
The PR rightfully notes that we only diagnose the right operator
and do not check the left operator if the right one was faulty.
Hi,
This patch fixes a regression caused by r12-3986. The _Unwind_Exception
struct had its alignment adjusted to 16-bytes in order to be compatible
with other languages, however malloc() on Solaris X86 is not guaranteed
to allocate memory aligned to 16-bytes as well.
Bootstrapped and regression
Hi,
This patch fixes test failures seen on SPARC and HPPA targets. The
value used to initialize the integer field in the union didn't account
for BigEndian targets running this code.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, as
well as sparc-sun-solaris2.11. Committed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837
--- Comment #6 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:d41092ec52f46d2f4b08fff8d1519e50354331b0
commit r12-4813-gd41092ec52f46d2f4b08fff8d1519e50354331b0
Author: Iain Buclaw
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959
--- Comment #2 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:1b5f73858412731bb2e821bdf0fc85d6cc012d33
commit r12-4812-g1b5f73858412731bb2e821bdf0fc85d6cc012d33
Author: Iain Buclaw
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013
--- Comment #3 from Jonathan Wakely ---
And libstdc++ has exactly the constraints required by the C++ draft. I suggest
reporting this as an LWG defect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013
--- Comment #2 from Jonathan Wakely ---
According to the standard, span is undefined behaviour, see the
last bullet of [res.on.functions].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100991
Bernhard Reutner-Fischer changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100972
Bernhard Reutner-Fischer changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884
Bernhard Reutner-Fischer changed:
What|Removed |Added
Keywords||patch
Ever confirmed|0
On Sun, 31 Oct 2021 18:05:36 +0100
Thomas Koenig wrote:
> Hi Bernhard,
>
> > gcc/fortran/ChangeLog:
> >
> > * resolve.c (resolve_fl_procedure): Initialize
> > allocatable_or_pointer.
>
> Looking at the code, it is clear that this is a false
> positive, or a false maybe, but the
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/100972
* decl.c (gfc_match_implicit_none): Fix typo in warning.
* resolve.c (resolve_unknown_f): Reject external procedures
without explicit EXTERNAL attribute whe IMPLICIT none (external)
Hi Bernhard,
gcc/fortran/ChangeLog:
* resolve.c (resolve_fl_procedure): Initialize
allocatable_or_pointer.
Looking at the code, it is clear that this is a false
positive, or a false maybe, but the semantics of C/C++
may well indicate that sym->result could change, although
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015
--- Comment #3 from Iain Buclaw ---
(In reply to Andrew Pinski from comment #2)
> Are you using Solaris's ld or as? Or what version of binutils are you using?
> Yes it does matter here.
Configured gcc --without-gnu-ld --with-ld=/usr/bin/ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103014
Andrew Pinski changed:
What|Removed |Added
Summary|gnat1 segfaults in |[11/12 Regression] gnat1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015
--- Comment #2 from Andrew Pinski ---
Are you using Solaris's ld or as? Or what version of binutils are you using?
Yes it does matter here.
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* resolve.c (resolve_fl_procedure): Initialize
allocatable_or_pointer.
---
fortran/resolve.c: In function 'bool resolve_fl_procedure(gfc_symbol*, int)':
fortran/resolve.c:13391:7: warning: 'allocatable_or_pointer' may be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975
--- Comment #4 from Johel Ernesto Guerrero Peña ---
I'm fine with closing this as RESOLVED INVALID or something along those lines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975
--- Comment #3 from Patrick Palka ---
(In reply to Patrick Palka from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Hmm, this is interesting:
> > template concept Never = false;
> > template concept C = Never;
> > void f() {
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015
--- Comment #1 from Iain Buclaw ---
The specific CPU config options of -m32 are: -mcpu=generic -march=pentium4
-mtune=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015
Bug ID: 103015
Summary: [i386][solaris] Segmentation fault loading pointer to
TLS
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103014
Bug ID: 103014
Summary: gnat1 segfaults in tree_could_trap_p when C double
parameter, -O2 -gnatn -gnatVa
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
On Sun, 10 Oct 2021 23:10:20 +
Daniil Stas wrote:
> This option is enabled by default when -Wformat option is enabled. A
> user can specify -Wno-format-int-precision to disable emitting
> warnings when passing an argument of an incompatible integer type to
> a 'd', 'i', 'o', 'u', 'x', or 'X'
Business as usual...
Gerald
---
htdocs/gcc-11/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 6dec8856..c81f0e82 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -142,7
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/99884
* io.c (check_open_constraints): Remove double spaces.
---
gcc/fortran/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index
After Jeff's explanation of the symbiosis between jump threading and
the uninit pass, I'm beginning to see that (almost) every
Wuninitialized warning is cause for reflection. It usually hides a
missing jump thread. I investigated one such false positive
(uninit-pred-7_a.c) and indeed, there's a
This complements the same change I made to the GCC 5 release notes a bit
ago.
Gerald
---
htdocs/gcc-6/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-6/changes.html b/htdocs/gcc-6/changes.html
index e95aabbe..6dd86d83 100644
---
This option (enabled by default) controls optimizations which convert
a sequence of operations into an equivalent sequence that includes
calls to builtin functions. Typical cases here are code which matches
memcpy, calloc, sincos.
The -ftree-loop-distribute-patterns flag only covers converting
This option (enabled by default) controls optimizations which convert
a sequence of operations into an equivalent sequence that includes
calls to builtin functions. Typical cases here are code which matches
memcpy, calloc, sincos.
The -ftree-loop-distribute-patterns flag only covers converting
Very many thanks to Jakub for proof-reading my patch, catching my silly
GNU-style
mistakes and making excellent suggestions. This revised patch incorporates
all of
his feedback, and has been tested on x86_64-pc-linux-gnu with make bootstrap
and
make -k check with no new failures.
2021-10-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013
--- Comment #1 from Andrey ---
Sorry, the first link to godbolt in the starter message is wrong, it should be
https://gcc.godbolt.org/z/jWeqs6cM4.
From: SiYu Wu
---
gcc/testsuite/gcc.target/riscv/Zbkx.c | 17 +
1 file changed, 17 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/Zbkx.c
diff --git a/gcc/testsuite/gcc.target/riscv/Zbkx.c
b/gcc/testsuite/gcc.target/riscv/Zbkx.c
new file mode 100644
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013
Bug ID: 103013
Summary: Underconstrained constructor span(_Range&&)
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012
--- Comment #2 from Andrew Pinski ---
Someone else has to reduce the testcase and such.
I found this while trying to reduce PR 102990.
From: SiYu Wu
---
gcc/common/config/riscv/riscv-common.c | 2 ++
gcc/config/riscv/crypto.md | 19 +++
gcc/config/riscv/riscv-opts.h | 2 ++
3 files changed, 23 insertions(+)
diff --git a/gcc/common/config/riscv/riscv-common.c
From: SiYu Wu
---
gcc/common/config/riscv/riscv-common.c | 2 ++
gcc/config/riscv/crypto.md | 21 +
gcc/config/riscv/riscv-opts.h | 2 ++
3 files changed, 25 insertions(+)
diff --git a/gcc/common/config/riscv/riscv-common.c
From: SiYu Wu
---
gcc/config/riscv/riscv-builtins-crypto.def | 6 ++
gcc/config/riscv/riscv-builtins.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/gcc/config/riscv/riscv-builtins-crypto.def
b/gcc/config/riscv/riscv-builtins-crypto.def
index 47bfff80f2e..abef52057a0
From: SiYu Wu
Co-authored-by: Shihua Liao
---
gcc/testsuite/gcc.target/riscv/Zksh-sm3.c | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/Zksh-sm3.c
diff --git a/gcc/testsuite/gcc.target/riscv/Zksh-sm3.c
From: SiYu Wu
---
gcc/common/config/riscv/riscv-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/common/config/riscv/riscv-common.c
b/gcc/common/config/riscv/riscv-common.c
index 4ed2a1f662a..e801fa149a2 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012
--- Comment #1 from Andrew Pinski ---
Created attachment 51714
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51714=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012
Bug ID: 103012
Summary: ICE with #pragma GCC optimize followed by long line
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990
--- Comment #1 from Andrew Pinski ---
Reducing.
From: SiYu Wu
---
gcc/config/riscv/riscv-builtins-crypto.def | 6 ++
gcc/config/riscv/riscv-builtins.c | 3 +++
2 files changed, 9 insertions(+)
diff --git a/gcc/config/riscv/riscv-builtins-crypto.def
b/gcc/config/riscv/riscv-builtins-crypto.def
index abef52057a0..e8c36789fe5
From: SiYu Wu
---
gcc/common/config/riscv/riscv-common.c | 16 +++-
gcc/config/riscv/arch-canonicalize | 16 +++-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/gcc/common/config/riscv/riscv-common.c
b/gcc/common/config/riscv/riscv-common.c
index
From: SiYu Wu
---
gcc/common/config/riscv/riscv-common.c | 6 ++
gcc/config/riscv/riscv-opts.h | 6 ++
2 files changed, 12 insertions(+)
diff --git a/gcc/common/config/riscv/riscv-common.c
b/gcc/common/config/riscv/riscv-common.c
index b2b85180ffe..18c09591c42 100644
---
From: SiYu Wu
Co-authored-by: Shihua Liao
---
gcc/testsuite/gcc.target/riscv/Zksed-sm4.c | 17 +
1 file changed, 17 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/Zksed-sm4.c
diff --git a/gcc/testsuite/gcc.target/riscv/Zksed-sm4.c
From: SiYu Wu
---
gcc/config/riscv/riscv-builtins-crypto.def | 6 ++
gcc/config/riscv/riscv-builtins.c | 3 +++
2 files changed, 9 insertions(+)
diff --git a/gcc/config/riscv/riscv-builtins-crypto.def
b/gcc/config/riscv/riscv-builtins-crypto.def
index ca008929927..47bfff80f2e
From: SiYu Wu
NOTE: The Zbkx should be implemented in bitmanip's Zbp, but since zbp is not
included in the bitmanip spec v1.0, and crypto's v1.0 release will earlier
than bitmanip's next release, so for now we implementing it here.
---
gcc/config/riscv/crypto.md | 27 +++
From: SiYu Wu
---
gcc/common/config/riscv/riscv-common.c | 6 ++
gcc/config/riscv/crypto.md | 129 +
gcc/config/riscv/riscv-opts.h | 6 ++
gcc/config/riscv/riscv.md | 2 +
gcc/config/riscv/riscv.opt | 3 +
5 files
From: SiYu Wu
---
gcc/common/config/riscv/riscv-common.c | 3 +++
gcc/config/riscv/riscv-opts.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/gcc/common/config/riscv/riscv-common.c
b/gcc/common/config/riscv/riscv-common.c
index 8f4f4472690..b2b85180ffe 100644
---
From: SiYu Wu
Co-authored-by: Shihua Liao
---
gcc/testsuite/gcc.target/riscv/Zknh-sha256.c | 27 +
.../gcc.target/riscv/Zknh-sha512-01.c | 40 +++
.../gcc.target/riscv/Zknh-sha512-02.c | 28 +
3 files changed, 95 insertions(+)
create
From: jiawei
---
gcc/config/riscv/arch-canonicalize | 2 ++
gcc/config/riscv/riscv.md | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/config/riscv/arch-canonicalize
b/gcc/config/riscv/arch-canonicalize
index c7df3c8a313..e2feb7e85cd 100755
---
From: SiYu Wu
This patch add gcc backend support for RISC-V Scalar Cryptography
Extension (k-ext), including machine description, builtins defines and
testcases for each k-ext's subset.
A note about Zbkx: The Zbkx should be implemented in bitmanip's Zbp, but
since zbp is not included in the
From: SiYu Wu
---
gcc/common/config/riscv/riscv-common.c | 2 +
gcc/config/riscv/crypto.md | 123 +
gcc/config/riscv/riscv-opts.h | 2 +
3 files changed, 127 insertions(+)
diff --git a/gcc/common/config/riscv/riscv-common.c
From: SiYu Wu
---
gcc/config/riscv/riscv-builtins-crypto.def | 34 ++
gcc/config/riscv/riscv-builtins.c | 15 ++
gcc/config/riscv/riscv-ftypes.def | 3 ++
3 files changed, 52 insertions(+)
create mode 100644
From: SiYu Wu
---
gcc/config/riscv/riscv-builtins-crypto.def | 24 ++
gcc/config/riscv/riscv-builtins.c | 2 ++
gcc/config/riscv/riscv-ftypes.def | 3 +++
3 files changed, 29 insertions(+)
diff --git a/gcc/config/riscv/riscv-builtins-crypto.def
From: linsinan1995 <47880367+linsinan1...@users.noreply.github.com>
---
gcc/config/riscv/riscv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index 6aef3d3a6cf..0529b6d60cd 100644
--- a/gcc/config/riscv/riscv.c
+++
From: SiYu Wu
Co-authored-by: Shihua Liao
---
gcc/testsuite/gcc.target/riscv/Zknd-aes-01.c | 15 +++
gcc/testsuite/gcc.target/riscv/Zknd-aes-02.c | 21 +++
gcc/testsuite/gcc.target/riscv/Zkne-aes-01.c | 15 +++
gcc/testsuite/gcc.target/riscv/Zkne-aes-02.c | 27
Hi Jason,
here is the fourth version of the patch.
I followed your suggestion and now make this
transformation sooner in pointer_int_sum.
I also added a check to only do this
transformation when the pointer is not a
VAR_DECL, which avoids it in the most
common cases where it is not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959
--- Comment #1 from Iain Buclaw ---
(In reply to Rainer Orth from comment #0)
> (gdb) p array
> $2 = {16, 678}
> (gdb) p u
> $3 = {i = 0, b = false}
> (gdb) n
> 9 u.i = 0xDEADBEEF;
> (gdb) n
> 10assert(array[u.b] == 678);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011
--- Comment #3 from cqwrteur ---
compilation succeeded when comment out process.h. HAVE_PROCESS_H does not make
sense tbh. Actually #if __has_include() can replace all headers. Are
you trying to support old versions' compilers by not using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011
--- Comment #2 from cqwrteur ---
Probably because of this that breaks compilation
https://github.com/gcc-mirror/gcc/commit/c3e80a16af287e804b87b8015307085399755cd4#diff-6499efb534d0a9459d3af89fe12f0ee024636b275addb16130c9dbe6c5c3dda9
1 - 100 of 102 matches
Mail list logo
