Hi!
On Fri, Feb 17, 2023 at 11:33:16AM +0800, Kewen.Lin wrote:
> on 2023/2/16 23:10, Segher Boessenkool wrote:
> > No, you are right that the semantics are pretty much the same. Please
> > just keep UNSPEC_PARITY everywhere.
>
> OK, since it has UNSPEC, I would hope the reader can realize it's
>
On 2/17/23 14:42, Marek Polacek wrote:
On Fri, Feb 17, 2023 at 04:32:50PM -0500, Patrick Palka wrote:
On Fri, 17 Feb 2023, Patrick Palka wrote:
On Fri, 17 Feb 2023, Marek Polacek wrote:
On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
On Fri, 17 Feb 2023, Marek Polacek via Gcc
Hi,
Gental ping these patches:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611286.html
BR,
Jeff (Jiufu)
Jiufu Guo writes:
> Hi,
>
> For a given constant, it would be profitable if we can use 2 insns to build.
> This patch enables more constants building through 2 insns: one is "li
Alexandre Oliva writes:
> Back in September last year, some of the vmsr and vmrs patterns had an
> extraneous blank removed, and the case of register names lowered, but
> another instance remained, and so did a few testcases.
[...]
Hi Alexandre,
I'm not approver but LGTM, thanks for fixing thi
Hi Segher,
Thanks for the comments!
on 2023/2/19 20:12, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Feb 17, 2023 at 11:33:16AM +0800, Kewen.Lin wrote:
>> on 2023/2/16 23:10, Segher Boessenkool wrote:
>>> No, you are right that the semantics are pretty much the same. Please
>>> just keep UNSPEC_
On 17/02/2023 08:12, Thomas Schwinge wrote:
Hi Andrew!
On 2023-02-16T23:06:44+0100, I wrote:
On 2023-02-16T16:17:32+, "Stubbs, Andrew via Gcc-patches"
wrote:
The mmap implementation was not optimized for a lot of small allocations, and I
can't see that issue changing here
That's corre
Hi,
This patch merges two "vsldoi" insns when their sources are the
same. Particularly, it is simplified to be one move if the total
shift is multiples of 16 bytes.
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions.
Thanks
Gui Haochen
ChangeLog
2023-02-20 Haochen Gui
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608292.html
BR,
Jeff (Jiufu)
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> I would like to have a ping on this patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608292.html
>
>
> BR,
> Jeff (Jiufu)
>
>
> Jiu
Hi,
Gently ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611550.html
Gui Haochen
Thanks
在 2023/2/8 13:08, HAO CHEN GUI 写道:
> Hi,
> The logical operations for TImode is split after reload pass right now. Some
> potential optimizations miss as the split is too late. This
On Mon, Feb 20, 2023 at 07:56:14AM +0100, Tobias Burnus wrote:
> On 17.02.23 17:27, Steve Kargl wrote:
> > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> > > OK for mainline?
> > Short version: no.
>
> Would you mind to write a reasoning beyond only a single word?
>
> > > subrou
On 2/15/23 13:37, Marek Polacek wrote:
On Wed, Feb 15, 2023 at 02:39:16PM -0500, Jason Merrill wrote:
On 2/9/23 09:39, Marek Polacek wrote:
In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide
the Y::Y(const Y&) call used to initialize o.c. So store_init_value
-> cxx_constant_in
On 16/02/2023 21:11, Thomas Schwinge wrote:
--- /dev/null
+++ b/libgomp/basic-allocator.c
+#ifndef BASIC_ALLOC_YIELD
+#deine BASIC_ALLOC_YIELD
+#endif
In file included from [...]/libgomp/config/nvptx/allocator.c:49:
[...]/libgomp/config/nvptx/../../basic-allocator.c:52:2: error: in
On 2/15/23 12:11, Patrick Palka wrote:
On Wed, 15 Feb 2023, Jason Merrill wrote:
On 2/15/23 09:21, Patrick Palka wrote:
On Tue, 14 Feb 2023, Jason Merrill wrote:
On 2/13/23 09:23, Patrick Palka wrote:
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-Novemb
On Sat, Feb 18, 2023 at 1:30 PM Palmer Dabbelt wrote:
>
> On Sat, 18 Feb 2023 13:06:02 PST (-0800), jeffreya...@gmail.com wrote:
> >
> >
> > On 2/18/23 11:26, Palmer Dabbelt wrote:
> >> On Fri, 17 Feb 2023 06:02:40 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> >>> Hi all,
> >>> If we have division
On 2/17/23 22:55, Alexandre Oliva wrote:
When a multi-source module is found to be unsupported, we fail
module_cmi_p and subsequent sources. Override proc unsupported to
mark the result in module_do, and test it to skip module_cmp_p and
subsequent related tests.
Hmm, I guess the problem that
Hi,
I would like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609373.html
BR,
Jeff (Jiufu)
Jiufu Guo writes:
> Hi,
>
> Compare with previous version, this patch updates the comments only.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608293.html
>
> Fo
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc (class reducop): New
class.
(class widen_reducop): Ditto.
(class freducop): Ditto.
(class widen_freducop): Ditto.
(BASE): Ditto.
* config/riscv/riscv-vector-builtins-b
On 17.02.23 17:27, Steve Kargl wrote:
On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
OK for mainline?
Short version: no.
Would you mind to write a reasoning beyond only a single word?
subroutine foo(n)
integer :: n
integer :: array(n*5)
integer :: my_len
...
m
The issue is that unroll-and-jam applies RPO VN on the transformed body but
that leaves the IL in "indetermined" state (it returns a TODO to make it
valid again). But unroll-and-jam then continues to transform another loop and
in using the tree_unroll_loop helper runs into tree_transform_and_unrol
Hello,
bootstrapped on gcc master x86_64 and no extra failures generated on all
front ends.
Would this be ok for trunc?
regards,
Gaius
Allow front ends to register spec functions gcc/{gcc.cc,gcc.h} [PR108261]
This patch allows front ends to register spec functions. It is motivated
by PR108
Nick has not been able to update his blog for a while and confirmed
we should remove this link.
Pushed.
Gerald (who is missing those nice updates)
---
htdocs/index.html | 1 -
1 file changed, 1 deletion(-)
diff --git a/htdocs/index.html b/htdocs/index.html
index 80730c06..3d0f8700 100644
---
On Sun, Feb 19, 2023 at 2:15 AM Maciej W. Rozycki wrote:
>
> On Sat, 18 Feb 2023, Jeff Law wrote:
>
> > > Barring the fusion case, which indeed asks for a dedicated `divmod'
> > > pattern (and then I suppose a post-reload splitter or a peephole so that
> > > where one of the two results produced
Alexandre Oliva via Gcc-patches writes:
> The pr104882.c test is an execution test, but arm_v8_1m_mve_ok only
> tests for compile-time support. Add a requirement for mve hardware.
>
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install?
>
> for
The following makes sure we do not ICE on unfolded stmts like
_1 = 1 & 1.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/108819
* tree-ssa-loop-niter.cc (number_of_iterations_cltz): Check
we have an SSA name as iv_2 as expected.
This series adds basic support for the Scalar Cryptography extensions:
* Zbkb
* Zbkc
* Zbkx
* Zknd
* Zkne
* Zknh
* Zksed
* Zksh
The implementation follows the version Scalar Cryptography v1.0.0 of the
specification,
which can be found here:
https://github.com/riscv/riscv-crypto/releases/tag/v1.0.
This patch supports Zksh and Zksed extension.
It includes instruction's machine description and built-in funtions.
gcc/ChangeLog:
* config/riscv/crypto.md (riscv_sm3p0_): Add ZKSED's and ZKSH's
instructions.
(riscv_sm3p1_):
(riscv_sm4ed_):
(riscv_sm4ks_):
This patch adds prototypes for RISC-V Crypto built-in functions.
gcc/ChangeLog:
* config/riscv/riscv-builtins.cc (RISCV_FTYPE_NAME2):
(RISCV_FTYPE_NAME3):
(RISCV_ATYPE_QI):
(RISCV_ATYPE_HI):
(RISCV_FTYPE_ATYPES2):
(RISCV_FTYPE_ATYPES3):
* co
This patch supports Zkne and Zknd extension.
It includes instruction's machine description and built-in funtions.
gcc/ChangeLog:
* config/riscv/constraints.md (D03): Add constants of bs and rnum.
(DsA):
* config/riscv/crypto.md (riscv_aes32dsi): Add ZKND's and ZKNE's
in
This patch supports Zkbk, Zbkc and Zkbx extension.
It includes instruction's machine description and built-in funtions.
It is worth mentioning that this patch only adds instructions in Zbkb but no
longer in Zbb.
If any instructions both in Zbb and Zbkb, they will be generated by code
generator
This patch supports Zknh extension.
It includes instruction's machine description and built-in funtions.
gcc/ChangeLog:
* config/riscv/crypto.md (riscv_sha256sig0_): Add ZKNH's
instructions.
(riscv_sha256sig1_):
(riscv_sha256sum0_):
(riscv_sha256sum1_):
As promised yesterday, this not only improves the one case that
triggered NightStrike's note, but all cases I found in wwwdocs.
Pushed.
Gerald
--
wwwdocs: *: Add a comma after "In addition" when used as transition
On the way reduce one use and simplify a sentence.
---
htdocs/gcc-12/changes.ht
Hello,
bootstrapped on gcc master x86_64 and no extra failures generated on all
front ends.
Would this be ok for trunc?
regards,
Gaius
Allow front ends to register spec functions gcc/{gcc.cc,gcc.h} [PR108261]
This patch allows front ends to register spec functions. It is motivated
by PR108
This patch
commit 27a89f84c458ae938bc3eb92ad0d594c06fc3b42
Author: Thomas Schwinge
Date: Fri Feb 17 23:36:20 2023 +0100
'#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc'
broke rust bootstrap on SPARC:
In file included from ./tm_p.h:4,
from
/vol/gcc/src/hg/master/lo
Thanks Rainer!
Ok for trunk :)
Kindly,
--
Arthur
On 2/20/23 11:36, Rainer Orth wrote:
This patch
commit 27a89f84c458ae938bc3eb92ad0d594c06fc3b42
Author: Thomas Schwinge
Date: Fri Feb 17 23:36:20 2023 +0100
'#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc'
broke rust bootstrap
On Mon, Feb 20, 2023 at 11:05 AM Tobias Burnus wrote:
>
> On 17.02.23 17:27, Steve Kargl wrote:
> > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> >> OK for mainline?
> > Short version: no.
>
> Would you mind to write a reasoning beyond only a single word?
>
> >> subroutine foo(n
On Fri, Feb 17, 2023 at 10:46 PM Andrew Pinski via Gcc-patches
wrote:
>
> get_range_query didn't support a nullptr argument
> before and would crash.
> See also the thread at
> https://inbox.sourceware.org/gcc/4f6718af-e17a-41ef-a886-f45e4ac3d...@redhat.com/T/
>
> OK? Bootstrapped and tested on x8
The split of the versioning condition assumes the definition is
in the condition block which is ensured by the versioning code.
But that only works when we actually have to insert any statements
for the versioning condition. The following adjusts the guard
accordingly and asserts this condition.
On Sat, 18 Feb 2023 at 19:23, Andreas Schwab wrote:
>
> libstdc++-v3/:
> * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
All the additions (and the one change) look correct, thanks.
On 20.02.23 11:41, Richard Biener wrote:
Generally SAVE_EXPR is used to make sure an expression is only evaluated
once. It's DECL_EXPR that ensures something is evaluated early
and available. So generally "unwrapping" a SAVE_EXPR looks dangerous
to me unless the SAVE_EXPR is really never necess
On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote:
> As mentioned in the TODO for 'deferred', I think we really want
> to have NULL as upper value for the domain for the type, but that
> requires literally hundred of changes to the compiler, which
> I do not want to due during Stage 4,
The comments on PR79700 mentioned that it was somewhat ambiguous whether
these functions were supposed to exist for C++11 or not. I chose to add
them there, since other resources (such as cppreference) seem to think
that C++11 should be the standard these functions were introduced, and I
don't know
On Mon, 20 Feb 2023 at 11:23, Nathaniel Shead via Libstdc++
wrote:
>
> The comments on PR79700 mentioned that it was somewhat ambiguous whether
> these functions were supposed to exist for C++11 or not. I chose to add
> them there, since other resources (such as cppreference) seem to think
> that
On 20.02.23 12:15, Jakub Jelinek wrote:
On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote:
As mentioned in the TODO for 'deferred', I think we really want
to have NULL as upper value for the domain for the type, but that
requires literally hundred of changes to the compiler, which
I
Hi!
This updates baseline_symbols.txt for the Fedora 39 arches.
Most of the added symbols are added to all 6 files, exceptions are
DF16_ rtti stuff (only added on x86 and aarch64 which supports those),
DF16b rtti stuff (only x86 right now), _M_replace_cold (m vs. j
differences), DF128_ charconv (o
On Mon, Feb 20, 2023 at 12:48:38PM +0100, Tobias Burnus wrote:
> On 20.02.23 12:15, Jakub Jelinek wrote:
> > On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote:
> > > As mentioned in the TODO for 'deferred', I think we really want
> > > to have NULL as upper value for the domain for the
On Mon, Feb 20, 2023 at 10:30 PM Jonathan Wakely wrote:
>
> On Mon, 20 Feb 2023 at 11:23, Nathaniel Shead via Libstdc++
> wrote:
> >
> > The comments on PR79700 mentioned that it was somewhat ambiguous whether
> > these functions were supposed to exist for C++11 or not. I chose to add
> > them th
On Mon, 20 Feb 2023 at 11:57, Nathaniel Shead wrote:
>
> On Mon, Feb 20, 2023 at 10:30 PM Jonathan Wakely wrote:
> >
> > On Mon, 20 Feb 2023 at 11:23, Nathaniel Shead via Libstdc++
> > wrote:
> > >
> > > The comments on PR79700 mentioned that it was somewhat ambiguous whether
> > > these functio
libstdc++-v3/
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
---
.../riscv64-linux-gnu/baseline_symbols.txt| 98 ++-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git
a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
b/
On Mon, Feb 20, 2023 at 12:57 PM Jakub Jelinek wrote:
>
> On Mon, Feb 20, 2023 at 12:48:38PM +0100, Tobias Burnus wrote:
> > On 20.02.23 12:15, Jakub Jelinek wrote:
> > > On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote:
> > > > As mentioned in the TODO for 'deferred', I think we real
When computing the number of iterations until wrap types are mixed up,
eventually leading to checking ICEs with a pointer bitwise inversion.
The following uses niter_type for the calculation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/108793
Hi Alexandre,
On 2/17/23 08:17, Alexandre Oliva via Gcc-patches wrote:
Back when quotes were added around "+cdecp" in the "coproc must be
a constant immediate" error in arm-builtins.cc, tests for that message
lagged behind. Fixed thusly.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks
On Mon, 20 Feb 2023, Richard Biener via Gcc-patches wrote:
> On Sun, Feb 19, 2023 at 2:15 AM Maciej W. Rozycki wrote:
> >
> > > The problem is you don't see it as a divmod in expand_divmod unless you
> > > expose
> > > a divmod optab. See tree-ssa-mathopts.cc's divmod handling.
> >
> > That'
Hi!
On 2022-08-24T12:59:51+0100, herron.phi...@googlemail.com wrote:
> From: Philip Herron
>
> This was a copy paste from gccgo front-end, we do not use any of the
> target_libs yet but we will need these when we support the libpanic crate.
> --- /dev/null
> +++ b/gcc/rust/config-lang.in
> +tar
Hi!
On 2023-02-20T09:48:53+, Andrew Stubbs wrote:
> On 17/02/2023 08:12, Thomas Schwinge wrote:
>> On 2023-02-16T23:06:44+0100, I wrote:
>>> On 2023-02-16T16:17:32+, "Stubbs, Andrew via Gcc-patches"
>>> wrote:
The mmap implementation was not optimized for a lot of small allocations
On Mon, 20 Feb 2023 at 12:10, Andreas Schwab via Libstdc++
wrote:
>
> libstdc++-v3/
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
Looks good, thanks.
Hi!
On 2022-07-07T23:18:03+0100, Andrew Stubbs wrote:
> On 07/07/2022 12:54, Tobias Burnus wrote:
>> On 07.07.22 12:34, Andrew Stubbs wrote:
>>> Implement the -foffload-memory=pinned option such that libgomp is
>>> instructed to enable fully-pinned memory at start-up. The option is
>>> intended
> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote:
>
> On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote:
>> + else if (!DECL_NAME (lhs_var))
>> +{
>> + char *lhs_var_name_str
>> += xasprintf ("D.%u", DECL_UID (lhs_var))
On Mon, Feb 20, 2023 at 03:04:51PM +, Qing Zhao via Gcc-patches wrote:
>
>
> > On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote:
> >
> > On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote:
> >> +else if (!DECL_NAME (lhs_var))
> >> + {
> >> +
Catched by running gcc.c-torture/execute/builtin-prefetch-2.c with
-march=rv64gc_zicbop.
gcc/ChangeLog:
* config/riscv/riscv.md (prefetch): Use r instead of p for the
address operand.
(riscv_prefetchi_): Ditto.
---
gcc/config/riscv/riscv.md | 4 ++--
1 file changed, 2 ins
Hi Alexandre,
> -Original Message-
> From: Alexandre Oliva
> Sent: Friday, February 17, 2023 7:06 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> ramana@gmail.com; Kyrylo Tkachov
> Subject: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine tes
Hi Richard, hi all,
On 20.02.23 13:46, Richard Biener wrote:
+ /* TODO: A more middle-end friendly alternative would be to use NULL_TREE
+as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN.
+Caveat: this requires some cleanup throughout the code to consistently
Tested x86_64-pc-linux. Pushed to trunk.
-- >8 --
Signed-off-by: Matthias Kretz
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h (__extract_part, split):
Use reserved name for template parameter.
---
libstdc++-v3/include/experimental/bits/simd.h | 22 +---
On Mon, 20 Feb 2023 at 16:32, Matthias Kretz via Libstdc++
wrote:
>
> Tested x86_64-pc-linux. Pushed to trunk.
OK for all relevant branches, thanks.
On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu. Since this is fixing experimental (C++20)
> functionality, I think it's reasonable to apply now; I'm interested in other
> opinions, and thoughts about the user-facing functionality. I'm thinking to
> make it
> On Feb 20, 2023, at 10:17 AM, Jakub Jelinek wrote:
>
> On Mon, Feb 20, 2023 at 03:04:51PM +, Qing Zhao via Gcc-patches wrote:
>>
>>
>>> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote:
>>>
>>> On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote:
+el
According to [basic.start.static]/2 and [expr.const]/2, a variable
with static storage duration initialized with a constant initializer
has constant initialization, and such an initializer is manifestly
constant-evaluated.
We're already getting this right with copy initialization because in
that c
Dear all,
the attached patch fixes an ICE on invalid (non-integer)
specification expressions for character length in function
declarations. It appears that the error handling was
already in place (mostly) and we need to essentially
prevent run-on errors.
Regtested on x86_64-pc-linux-gnu. OK for
Hi!
The following testcase is miscompiled on powerpc64le-linux with
-O2 -mcpu=power9. The problem is that gen_umaddditi4 is called with
the same TImode register for both op0 and op3, and maddlddi4
overwrites the low half of op0 before the low half of op3 is read,
so when they are the same registe
Instructions that use high-part QImode registers can not be encoded
with REX prefix. To avoid REX prefix, operand constraints allow
only legacy QImode registers, immediates and constant memory operands.
The patch introduces matching predicate, so invalid operands are not
combined into instruction
Hi,
Gently Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609504.html
BR,
Jeff (Jiufu)
Jiufu Guo writes:
> Hi,
>
> During discussing/review patches in maillist, we find more modes are
> tieable, e.g. DI<->DF. With some discussion, I drafted this patch
> to mark more tieable m
On Fri, Feb 17, 2023 at 8:54 PM Takayuki 'January June' Suwa
wrote:
>
> Leaf function often omits saving its return address to the stack slot,
> and this feature often makes debugging very confusing, especially for
> stack dump analysis.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xt
From: Matthew Fortune
---
gcc/testsuite/gcc.target/mips/mips.exp | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
b/gcc/testsuite/gcc.target/mips/mips.exp
index 81e19f39853..bf32fe0c93f 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/tests
From: Matthew Fortune
---
gcc/config/mips/mips.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index 590c311e98c..bb9f4e19c22 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -8853,7 +8853,7 @@ mip
Hi,
Kindly reminder for this PR.
Pan
-Original Message-
From: Li, Pan2
Sent: Friday, February 17, 2023 4:39 PM
To: richard.sandif...@arm.com; juzhe.zhong
Cc: incarnation.p@outlook.com; gcc-patches@gcc.gnu.org;
kito.ch...@sifive.com; Richard Biener
Subject: RE: [PATCH] RISC-V: Bug
Hi Harald,
the attached patch fixes an ICE on invalid (non-integer)
specification expressions for character length in function
declarations. It appears that the error handling was
already in place (mostly) and we need to essentially
prevent run-on errors.
Regtested on x86_64-pc-linux-gnu. OK
Like la264 only has 40 effective bits of virtual address space.
When TRY_EMPTY_VM_SPACE is set to 0x80, it just exceeds
the range of 40-bit virtual address, causing the mmap mapping
to fail, thus causing the pch function to fail. To be compatible
with this situation set the macro to 0x1
On Mon, Feb 20, 2023 at 5:23 PM Tobias Burnus wrote:
>
> Hi Richard, hi all,
>
> On 20.02.23 13:46, Richard Biener wrote:
> > + /* TODO: A more middle-end friendly alternative would be to use
> > NULL_TREE
> > +as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN.
> > +
On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
> Like la264 only has 40 effective bits of virtual address space.
I'm OK with the change. But the VA length is configurable building the
kernel. Is there any specific reason LA264 has to use the 40-bit
configuration, or should we reword the co
78 matches
Mail list logo
