On Fri, 3 Feb 2023 at 20:47, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
> > wrote:
> >>
> >> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
> >> wrote:
> >> >
> >> > Prathamesh Kulkarni writes:
> >> > >> >> > I have attached a
Tested cris-elf and native x86_64-pc-linux-gnu.
Ok to commit?
8<
The use of a "naked" int32_t (i.e. without a fitting #include:
stdint.h or cstdint or inttypes.h or an equivalent internal header),
in libstdc++-v3/include/pstl/unseq_backend_simd.h, caused an error for
cris-elf and
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pass_vsetvl::compute_probabilities):
Skip exit block.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/exception-1.C: New test.
---
gcc/config/riscv/riscv-vsetvl.cc | 10 +--
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vneg_v-1.C: New test.
* g++.target/riscv/rvv/base/vneg_v-2.C: New test.
* g++.target/riscv/rvv/base/vneg_v-3.C: New test.
* g++.target/riscv/rvv/base/vneg_v_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vnot_v-1.C: New test.
* g++.target/riscv/rvv/base/vnot_v-2.C: New test.
* g++.target/riscv/rvv/base/vnot_v-3.C: New test.
* g++.target/riscv/rvv/base/vnot_v_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/unop_v_constraint-1.c: New test.
---
.../riscv/rvv/base/unop_v_constraint-1.c | 132 ++
1 file changed, 132 insertions(+)
create mode 100644
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vneg_v-1.c: New test.
* gcc.target/riscv/rvv/base/vneg_v-2.c: New test.
* gcc.target/riscv/rvv/base/vneg_v-3.c: New test.
* gcc.target/riscv/rvv/base/vneg_v_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vnot_v-1.c: New test.
* gcc.target/riscv/rvv/base/vnot_v-2.c: New test.
* gcc.target/riscv/rvv/base/vnot_v-3.c: New test.
* gcc.target/riscv/rvv/base/vnot_v_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/iterators.md: Add neg and not.
* config/riscv/riscv-vector-builtins-bases.cc (class unop): New class.
(BASE): Ditto.
* config/riscv/riscv-vector-builtins-bases.h: Ditto.
*
Pushed.
Gerald
libstdc++-v3/ChangeLog:
* doc/xml/manual/documentation_hacking.xml: Adjust link to pdftex.
* doc/html/manual/documentation_hacking.html: Regenerate.
---
libstdc++-v3/doc/html/manual/documentation_hacking.html | 4 ++--
Okay, thanks all for the comments and suggestions.
Based on the discussion so far, I have the following plan for resolving this
issue:
In GCC13:
1. Add documentation in extend.texi to include all the following 3 cases as GCC
extension:
Case 1: The structure with a flexible array member is
This patch adds support for a saturating subtract built-in function that may be
added to a future PowerPC processor. Note, if it is added, the name of the
built-in function may change before GCC 13 is released. If the name changes,
we will submit a patch changing the name.
I also added support
This patch adds support for new instructions that may be added to the PowerPC
architecture in the future to enhance the load and store vector with length
instructions.
The current instructions (lxvl, lxvll, stxvl, and stxvll) are inconvient to use
since the count for the number of bytes must be
This patch is a prelimianry patch to add the full 1,024 bit dense math register
(DMRs) for -mcpu=future. The MMA 512-bit accumulators map onto the top of the
DMR register.
This patch only adds the new 1,024 bit register support. It does not add
support for any instructions that need 1,024 bit
This patch changes the assembler instruction names for MMA instructions from
the original name used in power10 to the new name when used with the dense math
system. I.e. xvf64gerpp becomes dmxvf64gerpp. The assembler will emit the
same bits for either spelling.
The patches have been tested on
This patch changes the MMA instructions to use either FPR registers
(-mcpu=power10) or DMRs (-mcpu=future). In this patch, the existing MMA
instruction names are used.
A macro (__PPC_DMR__) is defined if the MMA instructions use the DMRs.
The patches have been tested on the following platforms.
The MMA subsystem added the notion of accumulator registers as an optional
feature of ISA 3.1. In ISA 3.1, these accumulators overlapped with the VSX
vector registers 0..31, but logically the accumulator registers were separate
from the FPR registers. In ISA 3.1, it was anticipated that in
This patch enables generating load and store vector pair instructions when
doing certain memory copy operations when -mcpu=future is used. In doing tests
on power10, it was determined that using these instructions were problematical
in a few cases, so we disabled generating them by default. This
On Mon, 30 Jan 2023, Jason Merrill wrote:
> On 1/27/23 17:02, Patrick Palka wrote:
> > This patch turns the manifestly_const_eval flag used by the constexpr
> > machinery into a tri-state enum so that we're able to express wanting
> > to fold __builtin_is_constant_evaluated to false via late
These patches implement support for potential future PowerPC cpus. At this
time, features enabled with -mcpu=future may or may not be in actual PowerPCs
that will be delivered in the future.
This patch adds support for the -mcpu=future and -mtune=future options.
If you use -mcpu=future, the
These patches were originally posted on November 10th. Segher has asked that I
repost them. These patches are somewhat changed since the original posting to
address some of the comments.
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605581.html
In the first patch (adding
On Fri, 3 Feb 2023, Patrick Palka wrote:
> On Mon, 30 Jan 2023, Jason Merrill wrote:
>
> > On 1/27/23 17:02, Patrick Palka wrote:
> > > This PR illustrates that __builtin_is_constant_evaluated currently acts
> > > as an optimization barrier for our speculative constexpr evaluation,
> > > since
On Thu, 2 Feb 2023, Siddhesh Poyarekar wrote:
> I dug into this on the glibc end and it looks like this commit:
>
> commit 63fb8f9aa9d19f85599afe4b849b567aefd70a36
> Author: Zack Weinberg
> Date: Mon Feb 5 14:13:41 2018 -0500
>
> Post-cleanup 2: minimize _G_config.h.
>
> ripped all of
On Mon, 30 Jan 2023, Jason Merrill wrote:
> On 1/27/23 17:02, Patrick Palka wrote:
> > This PR illustrates that __builtin_is_constant_evaluated currently acts
> > as an optimization barrier for our speculative constexpr evaluation,
> > since we don't want to prematurely fold the builtin to false
LGTM
On 2/3/23 19:59, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, we ICE because lhs is singleton [0, 0]
or [1, 1] but op2 (or in other cases op1) is undefined and op?.*_bound ()
ICEs on those because there are no pairs for UNDEFINED.
The following patch makes us set r to varying or
On Fri, Feb 03, 2023 at 08:03:36PM +0100, Jakub Jelinek via Fortran wrote:
> Hi!
>
> The first testcase in the PR (which I haven't included in the patch because
> it is unclear to me if it is supposed to be valid or not) ICEs since extra
> hash table checking has been added recently. The problem
Hi!
As mentioned in the PR, we ICE because lhs is singleton [0, 0]
or [1, 1] but op2 (or in other cases op1) is undefined and op?.*_bound ()
ICEs on those because there are no pairs for UNDEFINED.
The following patch makes us set r to varying or return false in those
cases.
Included is a
Hi!
The first testcase in the PR (which I haven't included in the patch because
it is unclear to me if it is supposed to be valid or not) ICEs since extra
hash table checking has been added recently. The problem is that
gfc_trans_use_stmts does
tree *slot =
Hi!
We ICE on the following testcase, because ivcanon calls
gimple_build_builtin_unreachable but doesn't expect it would need vops.
BUILT_IN_UNREACHABLE_TRAP I've introduced yesterday doesn't need
vops and should be used in that case instead of BUILT_IN_TRAP which
needs them.
On Fri, Feb 03, 2023 at 07:09:18PM +0100, Aldy Hernandez wrote:
> This patch gracefully handles undefined operand ranges for the floating
> point op[12]_range operators. This is very low risk, as we would have
> ICEd otherwise.
>
> We don't have a testcase that ICEs for floating point ranges,
On Fri, Feb 03, 2023 at 11:23:28AM -0500, Andrew MacLeod wrote:
>
> On 2/3/23 04:16, Jakub Jelinek wrote:
> > On Fri, Feb 03, 2023 at 09:50:43AM +0100, Aldy Hernandez wrote:
> > > [PR tree-optimization/18639] Compare nonzero bits in irange with
> > > widest_int.
> > 0 missing in the bug number
On Fri, Feb 03, 2023 at 02:52:43PM +, Gaius Mulley via Gcc-patches wrote:
>
> Hello,
>
> The following patch provides a summary of the modula-2 front end
> and also contains links to the online modula-2 documentation in
> index.html.
>
> [I'm just about to git push fixes so that modula-2
On Fri, 3 Feb 2023, 19:20 Gerald Pfeifer wrote:
> libstdc++-v3/ChangeLog:
>
> * doc/xml/manual/abi.xml: Tweak link to ABIcheck project.
>
We should probably link to libabigail instead, or as well.
* doc/html/manual/abi.html: Regenerate.
> ---
>
Business as usual.
Pushed.
Gerald
---
htdocs/news/profiledriven.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/news/profiledriven.html b/htdocs/news/profiledriven.html
index 13a61ec0..cac172b4 100644
--- a/htdocs/news/profiledriven.html
+++
libstdc++-v3/ChangeLog:
* doc/xml/manual/abi.xml: Tweak link to ABIcheck project.
* doc/html/manual/abi.html: Regenerate.
---
libstdc++-v3/doc/html/manual/abi.html | 2 +-
libstdc++-v3/doc/xml/manual/abi.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On Fri, 3 Feb 2023, Gaius Mulley wrote:
> The following patch provides a summary of the modula-2 front end
> and also contains links to the online modula-2 documentation in
> index.html.
> +Modula-2
> +
> + Support for the language Modula-2 has been added. The dialects
> + supported are PIM2,
> Am 03.02.2023 um 16:55 schrieb Richard Sandiford via Gcc-patches
> :
>
> Richard Biener via Gcc-patches writes:
Am 03.02.2023 um 15:20 schrieb Richard Sandiford via Gcc-patches
:
>>>
>>> Richard Biener via Gcc-patches writes:
The RTL CSE hash table has a fixed number of
On Fri, Feb 03, 2023 at 01:53:48PM -0500, Jason Merrill wrote:
> On 2/3/23 13:08, Marek Polacek wrote:
> > On Thu, Feb 02, 2023 at 05:29:44PM -0500, Jason Merrill wrote:
> > > On 1/30/23 21:35, Marek Polacek wrote:
> > > > In this test case, we find ourselves evaluating 't' which is
> > > >
On 2/3/23 13:08, Marek Polacek wrote:
On Thu, Feb 02, 2023 at 05:29:44PM -0500, Jason Merrill wrote:
On 1/30/23 21:35, Marek Polacek wrote:
In this test case, we find ourselves evaluating 't' which is
((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)]
in cxx_eval_array_reference.
As a happy accident, this was fixed by the recent r13-2978.
PR c++/101071
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/variadic-alias8.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/variadic-alias8.C | 95
1 file changed, 95 insertions(+)
create mode 100644
> Am 03.02.2023 um 16:54 schrieb Andrew MacLeod :
>
>
>> On 2/2/23 07:22, Richard Biener wrote:
>>> On Wed, Feb 1, 2023 at 7:12 PM Andrew MacLeod via Gcc-patches
>>> wrote:
>>> We can reset SCEV after we fold, then SCEVs cache shouldn't have
>>> anything in it when we go to remove ssa-names
This patch gracefully handles undefined operand ranges for the floating
point op[12]_range operators. This is very low risk, as we would have
ICEd otherwise.
We don't have a testcase that ICEs for floating point ranges, but it's
only a matter of time. Besides, this dovetails nicely with the
On Thu, Feb 02, 2023 at 05:29:44PM -0500, Jason Merrill wrote:
> On 1/30/23 21:35, Marek Polacek wrote:
> > In this test case, we find ourselves evaluating 't' which is
> > ((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)]
> > in cxx_eval_array_reference. ctx->object is non-null, a
We can use bytepick.[wd] for
a << (8 * x) | b >> (8 * (sizeof(a) - x))
while a and b are uint32_t or uint64_t. This is useful for some cases,
for example:
https://sourceware.org/pipermail/libc-alpha/2023-February/145203.html
Bootstrapped and regtested on loongarch64-linux-gnu.
Ok for trunk
On 3 February 2023 12:35:32 CET, Richard Biener via Gcc-patches
>
>I think it's OK as-is given this explanation.
>
s/derefernce/dereference/
thanks,
On 2/3/23 04:16, Jakub Jelinek wrote:
On Fri, Feb 03, 2023 at 09:50:43AM +0100, Aldy Hernandez wrote:
[PR tree-optimization/18639] Compare nonzero bits in irange with widest_int.
0 missing in the bug number in the subject line, though the current
recommended formatting of the subject is I
On 2/2/23 10:05, Kees Cook via Gcc-patches wrote:
Right -- this can lead (at least) to type confusion and other problems
too. We've been trying to remove all of these overlaps in the Linux
kernel. I mention it the "Overlapping composite structure members"
section at
On 2/2/23 07:22, Richard Biener wrote:
On Wed, Feb 1, 2023 at 7:12 PM Andrew MacLeod via Gcc-patches
wrote:
We can reset SCEV after we fold, then SCEVs cache shouldn't have
anything in it when we go to remove ssa-names in remove_unreachable().
We were resetting it later sometimes if we were
Richard Biener via Gcc-patches writes:
>> Am 03.02.2023 um 15:20 schrieb Richard Sandiford via Gcc-patches
>> :
>>
>> Richard Biener via Gcc-patches writes:
>>> The RTL CSE hash table has a fixed number of buckets (32) each
>>> with a linked list of entries with the same hash value. The
>>>
> Am 03.02.2023 um 15:20 schrieb Richard Sandiford via Gcc-patches
> :
>
> Richard Biener via Gcc-patches writes:
>> The RTL CSE hash table has a fixed number of buckets (32) each
>> with a linked list of entries with the same hash value. The
>> actual hash values are computed using
On 01/02/2023 09:46, Christophe Lyon via Gcc-patches wrote:
I have noticed that the "length" "8" attribute is missing in a few
patterns in mve.md.
gcc/
* config/arm/mve.md (mve_vabavq_p_): Add length
attribute.
(mve_vqshluq_m_n_s): Likewise.
On 01/02/2023 09:46, Christophe Lyon via Gcc-patches wrote:
I have noticed some warnings when building GCC for arm-eabi:
pr-support.c:110:7: warning: variable ‘set_pac_sp’ set but not used
[-Wunused-but-set-variable]
pr-support.c:109:7: warning: variable ‘set_pac’ set but not used
Xi Ruoyao via Gcc-patches 于2023年2月3日周五 22:35写道：
>
> On Fri, 2023-02-03 at 14:08 +, Richard Sandiford via Gcc-patches
> wrote:
> > > Do you mean that the "wrong" format is quite interesting?
> > > Yes, While this format is never used at all.
> >
> > My point was that there is nothing wrong in
Prathamesh Kulkarni writes:
> On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
> wrote:
>>
>> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
>> wrote:
>> >
>> > Prathamesh Kulkarni writes:
>> > >> >> > I have attached a patch that extends the transform if one half is
>> > >> >> > dup
>> > >>
On Fri, Feb 03, 2023 at 09:10:21 +, Jonathan Wakely wrote:
> On Fri, 3 Feb 2023 at 08:58, Jonathan Wakely wrote:
> > On Fri, 3 Feb 2023, 04:09 Andrew Pinski via Gcc, wrote:
> >> On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
> >> wrote:
> >> > This patch series adds initial support
> On Feb 2, 2023, at 11:25 PM, Siddhesh Poyarekar wrote:
>
> On 2023-02-02 03:33, Richard Biener wrote:
>> looking at PR77650 what seems missing there is the semantics of this
>> extension as expected/required by the glibc use. comment#5 seems
>> to suggest that for my example above its
Hello,
The following patch provides a summary of the modula-2 front end
and also contains links to the online modula-2 documentation in
index.html.
[I'm just about to git push fixes so that modula-2 builds html, info and
pdf documentation into the standard directories.]
regards,
Gaius
On Wed, 28 Dec 2022 at 14:28, Nathaniel Shead via Libstdc++
wrote:
>
> These two patches implement P1413 (deprecate std::aligned_storage and
> std::aligned_union) for C++23. Tested on x86_64-linux.
>
> -- >8 --
>
> Updates _GLIBCXX20_DEPRECATED to be defined and behave the same as the
> versions
On Wed, 25 Jan 2023 at 18:38, François Dumont wrote:
>
> Let's submit a proper patch proposal then.
>
> The occasion for me to ask if there is any reason for cow string not
> being C++11 allocator compliant ? Just lack of interest ?
Mostly lack of interest, but also I don't really want to
On Fri, 2023-02-03 at 14:08 +, Richard Sandiford via Gcc-patches
wrote:
> > Do you mean that the "wrong" format is quite interesting?
> > Yes, While this format is never used at all.
>
> My point was that there is nothing wrong in principle with creating
> an o32 executable that has a 64-bit
Richard Biener via Gcc-patches writes:
> The RTL CSE hash table has a fixed number of buckets (32) each
> with a linked list of entries with the same hash value. The
> actual hash values are computed using hash_rtx which uses adds
> for mixing and adds the rtx CODE as CODE << 7 (apart from some
YunQiang Su writes:
> Richard Sandiford via Gcc-patches
> 于2023年2月3日周五 20:29写道：
>>
>> YunQiang Su writes:
>> > The value of default_mips_arch will be always used for -march by default,
>> > no matter what value is given to -mabi.
>> > It will produce abnormal elf file like:
>> > ELF 32-bit LSB
The RTL CSE hash table has a fixed number of buckets (32) each
with a linked list of entries with the same hash value. The
actual hash values are computed using hash_rtx which uses adds
for mixing and adds the rtx CODE as CODE << 7 (apart from some
exceptions such as MEM). The unsigned int typed
Hello
This patch implements support for the OpenMP 5.1 'present' modifier in
C, C++ and Fortran. 'present' can be used in the 'map' clause for the
'target', 'target data', 'target data enter' and 'target data exit'
constructs, and the 'to'/'from' clauses of 'target update'. It can be
used in
Richard Sandiford via Gcc-patches
于2023年2月3日周五 20:29写道：
>
> YunQiang Su writes:
> > The value of default_mips_arch will be always used for -march by default,
> > no matter what value is given to -mabi.
> > It will produce abnormal elf file like:
> > ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2
> On Feb 3, 2023, at 2:49 AM, Richard Biener wrote:
>
> On Thu, 2 Feb 2023, Qing Zhao wrote:
>
>>
>>
>>> On Feb 2, 2023, at 8:54 AM, Richard Biener wrote:
>>>
>>> On Thu, 2 Feb 2023, Qing Zhao wrote:
>>>
>
> [...]
>
+ return flexible_size_type_p (TREE_TYPE
When cse_insn prunes src{,_folded,_eqv_here,_related} with the
equivalence set in the *_same_value chain it also searches for
an equivalence to the destination of the instruction with
/* This is the same as the destination of the insns, we want
to prefer it. Copy it to
On Fri, 7 Oct 2022 at 21:45, Samuel Thibault wrote:
>
> This is notably needed because in glibc 2.34, the move of pthread functions
> into libc.so happened for Linux only, not GNU/Hurd.
>
> The pthread_self() function can also always be used fine as it is on
> GNU/Hurd.
Sorry for the delay, I'm
YunQiang Su writes:
> The value of default_mips_arch will be always used for -march by default,
> no matter what value is given to -mabi.
> It will produce abnormal elf file like:
> ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
Is that really wrong though? There's nothing in
On Fri, Feb 3, 2023 at 10:40 AM Martin Jambor wrote:
>
> On Fri, Feb 03 2023, Richard Biener wrote:
> > On Thu, Feb 2, 2023 at 5:20 PM Martin Jambor wrote:
> >>
> >> Hi,
> >>
> >> when the compiled program contains type mismatches between callers and
> >> callees when it comes to a parameter,
On Thu, 5 May 2022 at 07:56, Alexandre Oliva via Libstdc++
wrote:
>
>
> The async call and future variable initialization may take a while to
> complete on uniprocessors, especially if the async call and other
> unrelated processes run before context switches back to the main
> thread.
>
> Taking
Now committed as obvious as
r13-5680-g0b1ce70a813b98ef2893779d14ad6c90c5d06a71.
I improved the wording in the commit comment a bit, compared to previous
attachment and I have verified that those features work with AMDGCN* and
without offloading.
Tobias
(* it seems as if there is still another
Hi,
This patch checks if a constant is possible to be built by "li;rldic".
We only need to take care of "negative li", other forms do not need to check.
For example, "negative lis" is just a "negative li" with an additional shift.
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk or
Hi,
This patch checks if a constant is possible to be rotated to/from a negative
value from "lis". If so, we could use "lis;rotldi" to build it.
The positive value of "lis" does not need to be analyzed. Because if a
constant can be rotated from positive value of "lis", it also can be rotated
Hi,
This patch checks if a constant is possible left/right cleaned on a rotated
value from a negative value of "li/lis". If so, we can build the constant
through "li/lis ; rldicl/rldicr".
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk or next stage1?
BR,
Jeff (Jiufu)
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 or lis",
another is 'rldicl, rldicr or rldic'.
Through checking and analyzing the characters of the insns "li/lis;rldicX",
all the possible
Hi,
This patch checks if a constant is possible to be rotated to/from a positive
or negative value from "li". If so, we could use "li;rotldi" to build it.
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk or next stage1?
BR,
Jeff (Jiufu)
gcc/ChangeLog:
*
The gen_insn method is used to generate ADJUST_SP_RTX here, which has certain
potential risks:
When the architecture adds pre-processing to `define_insn "adddi3"`, such as
`define_expend "adddi3"`, the gen_expand will be automatically called here,
causing the patern to emit directly, which will
On Fri, Feb 03 2023, Richard Biener wrote:
> On Thu, Feb 2, 2023 at 5:20 PM Martin Jambor wrote:
>>
>> Hi,
>>
>> when the compiled program contains type mismatches between callers and
>> callees when it comes to a parameter, IPA-CP can try to propagate one
>> constant from callers while IPA-SRA
On Fri, Feb 03, 2023 at 09:50:43AM +0100, Aldy Hernandez wrote:
> [PR tree-optimization/18639] Compare nonzero bits in irange with widest_int.
0 missing in the bug number in the subject line, though the current
recommended formatting of the subject is I think:
value-range: Compare nonzero bits in
aarch64/fcsel_1.c contains:
double
f_2 (double a, double b, double c, double d)
{
if (a > b)
return c;
else
return d;
}
which started failing in the GCC 12 timeframe. When it passed,
the RTL had the form:
[A]
(set (reg ret) (reg c))
(set (pc) (if_then_else (gt ...) (label_ref
On Fri, 3 Feb 2023 at 08:58, Jonathan Wakely wrote:
>
>
>
> On Fri, 3 Feb 2023, 04:09 Andrew Pinski via Gcc, wrote:
>>
>> On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
>> wrote:
>> >
>> > Hi,
>> >
>> > This patch series adds initial support for ISO C++'s [P1689R5][], a
>> > format for
The value of default_mips_arch will be always used for -march by default,
no matter what value is given to -mabi.
It will produce abnormal elf file like:
ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
So we use with_arch_32 and with_arch_64 instead of default_mips_arch
for all
On Fri, 3 Feb 2023, 04:09 Andrew Pinski via Gcc, wrote:
> On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
> wrote:
> >
> > Hi,
> >
> > This patch series adds initial support for ISO C++'s [P1689R5][], a
> > format for describing C++ module requirements and provisions based on
> > the
Gentle ping.
The patch I previously submitted:
| Date: Wed, 30 Nov 2022 00:38:08 -0800
| Subject: [PATCH] RISC-V: optimize stack manipulation in save-restore
| Message-ID:
I split the patches as per Palmer's review comment.
BR
Fei
>gcc/ChangeLog:
>
> * config/riscv/riscv.cc
Gentle ping.
The patch I previously submitted:
| Date: Wed, 30 Nov 2022 00:38:08 -0800
| Subject: [PATCH] RISC-V: optimize stack manipulation in save-restore
| Message-ID:
I split the patches as per Palmer's review comment.
BR
Fei
>The stack that save-restore reserves is not well accumulated
Gentle ping.
The patch I previously submitted:
| Date: Wed, 30 Nov 2022 00:38:08 -0800
| Subject: [PATCH] RISC-V: optimize stack manipulation in save-restore
| Message-ID:
I split the patches as per Palmer's review comment.
BR
Fei
>frame->total_size to remaining_size conversion is done as an
Gentle ping.
The patch I previously submitted:
| Date: Wed, 30 Nov 2022 00:38:08 -0800
| Subject: [PATCH] RISC-V: optimize stack manipulation in save-restore
| Message-ID:
I split the patches as per Palmer's review comment.
BR
Fei
On 2022-12-01 18:03 Fei Gao wrote:
>
>The patches allow
The problem here is we are trying to compare two ranges with different
precisions and the == operator in wide_int is complaining.
Interestingly, the problem is not the nonzero bits, but the fact that
the entire ranges have different precisions. The reason we don't ICE
when comparing the
On Thu, Feb 02, 2023 at 03:30:29PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Tested in non-bootstrapped build with both -std=gnu++17 and -std=gnu++11,
> ok for trunk if it passes full bootstrap/regtest?
Bootstrapped/regtested successfully on x86_64-linux and i686-linux
(gcc 12 as stage1
90 matches
Mail list logo
