Currently, the asm output file for MIPS has no rev info.
It can make some trouble, for example:
assembler is mips1 by default,
gcc is fpxx by default.
To assemble the output of gcc -S, we have to pass -mips2
to assembler.
The same situation is for some CPU has extension insn.
Octeon is an ex
For 32-bit libgcc configure w/o sse2, there's would be an error since
GCC only support _Float16 under sse2. Explicitly add -msse2 for those
HF related libgcc functions, so users can still link them w/ the
upper configuration.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk?
Hi,
On Thu, Aug 19, 2021 at 7:29 PM Sandra Loosemore
wrote:
> On 7/27/21 5:07 AM, Tobias Burnus wrote:
> > Hi Sandra, hi Thomas, hi all,
> >
> > @Thomas K: Comments about the following - and of course to the
> > testsuite itself - are highly welcome.
> >
> > In my opinion, the testsuite LGTM and
Hi Joseph,
> On 2 Sep 2021, at 21:03, Joseph Myers wrote:
>
> On Thu, 2 Sep 2021, Iain Sandoe via Gcc-patches wrote:
>
>> diff --git a/libgcc/soft-fp/eqdf2.c b/libgcc/soft-fp/eqdf2.c
>> index 2a44ee377ce..a3bb664f5f1 100644
>> --- a/libgcc/soft-fp/eqdf2.c
>> +++ b/libgcc/soft-fp/eqdf2.c
>> @@ -
On Fri, Aug 20, 2021 at 12:35:58PM +0200, Richard Biener wrote:
[...]
> > >
> > > + /* Handle strlen like loops. */
> > > + if (store_dr == NULL
> > > + && integer_zerop (pattern)
> > > + && TREE_CODE (reduction_iv.base) == INTEGER_CST
> > > + && TREE_CODE (reduction_iv.step) == I
Hi!
When __atomic_* builtins were introduced, omp-expand.c (omp-low.c
at that point) has been adjusted in several spots so that it uses
the atomic builtins instead of sync builtins, but
expand_omp_atomic_pipeline has not because the __atomic_compare_exchange_*
APIs take address of the argument, so
On Thu, 2 Sept 2021 at 14:32, Christophe Lyon
wrote:
>
>
>
> On Tue, Aug 24, 2021 at 10:17 AM Kyrylo Tkachov
> wrote:
>>
>>
>>
>> > -Original Message-
>> > From: Prathamesh Kulkarni
>> > Sent: 24 August 2021 09:01
>> > To: Christophe Lyon
>> > Cc: Kyrylo Tkachov ; gcc Patches > > patc.
Hi,
packed array types are sometimes represented with integer types under the hood
in Ada, but we nevertheless need to emit them as array types in the debug info
so we have the types.get_array_descr_info langhook for this purpose; but it is
not invoked from modified_type_die, which is responsible
On 8/31/21 3:24 PM, H.J. Lu via Gcc-patches wrote:
> On Thu, Aug 12, 2021 at 8:24 PM Ian Lance Taylor via Gcc-patches
> wrote:
>>
>> This patch updates libgo from the Go1.16.5 release to the Go 1.17rc2
>> release. As usual with these version updates, the patch itself is too
>> large to attach to
On Fri, Sep 03, 2021 at 03:41:13PM +0800, liuhongt via Gcc-patches wrote:
> --- a/libgcc/config/i386/64/t-softfp
> +++ b/libgcc/config/i386/64/t-softfp
> @@ -1 +1,6 @@
> softfp_extras := fixhfti fixunshfti floattihf floatuntihf
> +
> +CFLAGS-fixhfti.c += -msse2
> +CFLAGS-fixunshfti.c += -msse2
> +
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> After the recent r12-3278-823685221de986a change, the testcase
> gcc.target/aarch64/sve/acle/general-c/type_redef_1.c started
> to ICE as the code was not ready for error_mark_node in the
> type. This fixes that and the testcase now pa
Hi,
this old PR is about a link failure on x86-64/Cygwin with thread-local
storage variables:
use.o:use.cxx:(.text$_ZTWN1N3ptdE[_ZTWN1N3ptdE]+0x15): relocation
truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init
function for N::ptd'
collect2: error: ld returned 1 exit status
At th
Hi,
On 03.09.21 09:46, Christophe Lyon wrote:
I'm not quite sure I understand the expected status of this patch: are
all the "expected" failures tagged as XFAIL?
I think that's the idea.
If yes, then there's a problem because I see lots of unresolved on
aarch64/arm
XFAIL: gfortran.dg/c-intero
This makes sure that the style and warning settings used in the C/C++ bindings
generated by -fdump-ada-spec do not leak into the units that use them.
Tested on x86-64/Linux, applied on the mainline.
2021-09-03 Eric Botcazou
c-family/
* c-ada-spec.c (dump_ads): Generate pragmas to di
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
> we are not going to error out. It fixes the problem by the removal
> of the function from the IR.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no r
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> I got some ICEs in my latest testsing while running the libstdc++ testsuite.
> I had noticed the problem was connected to types and had just touched the
> builtins code but nothing which could have caused this and I looked for
> some ty
Tamar Christina via Gcc-patches writes:
> diff --git a/gcc/cse.c b/gcc/cse.c
> index
> 330c1e90ce05b8f95b58f24576ec93e10ec55d89..d76e01b6478e22e9dd5760b7c78cecb536d7daef
> 100644
> --- a/gcc/cse.c
> +++ b/gcc/cse.c
> @@ -44,6 +44,7 @@ along with GCC; see the file COPYING3. If not see
> #includ
*ping*
From: Paul Keir
Sent: 20 August 2021 21:17
To: gcc-patches@gcc.gnu.org
Cc: libstd...@gcc.gnu.org
Subject: [PATCH] libstdc++: Fix compare_three_way for constexpr and Clang
Hi,
The current compare_three_way implementation makes provision for constan
On 03/09/2021 10:35, Prathamesh Kulkarni via Gcc-patches wrote:
On Thu, 2 Sept 2021 at 14:32, Christophe Lyon
wrote:
On Tue, Aug 24, 2021 at 10:17 AM Kyrylo Tkachov wrote:
-Original Message-
From: Prathamesh Kulkarni
Sent: 24 August 2021 09:01
To: Christophe Lyon
Cc: Kyrylo T
Tamar Christina writes:
> Hi All,
>
> The following example
>
> void f5(float * restrict z0, float * restrict z1, float *restrict x,
> float * restrict y, float c, int n)
> {
> for (int i = 0; i < n; i++) {
> float a = x[i];
> float b = y[i];
> if (a > b) {
>
Ping
-Original Message-
From: Jirui Wu
Sent: Friday, August 20, 2021 4:28 PM
To: Richard Biener
Cc: Richard Biener ; Andrew Pinski
; Richard Sandiford ;
i...@airs.com; gcc-patches@gcc.gnu.org; Joseph S. Myers
Subject: RE: [Patch][GCC][middle-end] - Generate FRINTZ for (double)(int) u
On 24/08/2021 12:43, Richard Biener via Gcc-patches wrote:
On Tue, Aug 24, 2021 at 12:23 PM Thomas Schwinge
wrote:
Hi!
On 2021-08-19T22:13:56+0200, I wrote:
On 2021-08-16T10:21:04+0200, Jakub Jelinek wrote:
On Mon, Aug 16, 2021 at 10:08:42AM +0200, Thomas Schwinge wrote:
|> Concerning the
> On 3 Sep 2021, at 10:00, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Fri, Sep 03, 2021 at 03:41:13PM +0800, liuhongt via Gcc-patches wrote:
>> --- a/libgcc/config/i386/64/t-softfp
>> +++ b/libgcc/config/i386/64/t-softfp
>> @@ -1 +1,6 @@
>> softfp_extras := fixhfti fixunshfti floattihf flo
On Fri, Sep 03, 2021 at 01:32:14PM +0100, Iain Sandoe via Gcc-patches wrote:
> diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
> index cea33267e53..f5c1bc1aa6c 100644
> --- a/libgcc/libgcc-std.ver.in
> +++ b/libgcc/libgcc-std.ver.in
> @@ -1944,3 +1944,21 @@ GCC_7.0.0 {
>__PFX__
> On 3 Sep 2021, at 13:33, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Fri, Sep 03, 2021 at 01:32:14PM +0100, Iain Sandoe via Gcc-patches wrote:
>> diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
>> index cea33267e53..f5c1bc1aa6c 100644
>> --- a/libgcc/libgcc-std.ver.in
>>
On Mon, Aug 02, 2021 at 02:31:12PM +0800, liuhongt via Gcc-patches wrote:
> * doc/extend.texi (Half-Precision Floating Point): Documemt
> _Float16 for x86.
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -1102,6 +1102,7 @@ typedef _Complex float __attribute__((mode(IC)))
Currently we adjust statements containing an IMAGPART_EXPR if the
defining statement was one of a few built-ins known to return boolean
types. We can also adjust statements for both IMAGPART_EXPR and
REALPART_EXPR where the defining statement is a constant.
This patch adds such support, and clean
The function postfold_gcond_edges() registers relations coming out of a
GIMPLE_COND. With upcoming changes, we may be called with statements
not in the IL (for example, dummy statements created by the
forward threader). This patch avoids breakage by exiting if the
statement does not have a defini
Tested on x86-64 Linux.
Committed as obvious.
gcc/ChangeLog:
* tree-ssa-loop-ch.c: Remove unnecessary include file.
---
gcc/tree-ssa-loop-ch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/tree-ssa-loop-ch.c b/gcc/tree-ssa-loop-ch.c
index b4e09f97b28..ffb0aa85118 100644
--- a/g
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-relation.cc (relation_oracle::debug): New.
* value-relation.h (relation_oracle::debug): New.
---
gcc/value-relation.cc | 6 ++
gcc/value-relation.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/gcc/value-relation.cc b/gc
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-path.cc (path_range_query::dump): Dump path
length.
(path_range_query::precompute_ranges): Dump entire path.
---
gcc/gimple-range-path.cc | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --gi
Fixes the testcase for \r\n line breaks →
r12-3327-g4ce90454c2c81246be993d997cab12e21bc0be68
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Si
[Jeff, I'm CCing you to keep you in the loop on changes that will impact
jump threading. Since we're using one engine, any changes to the either
ranger or the path solver, is likely to improve jump threading.]
This patch improves ranges for pointers we are interested in a path, by
using the non-n
These are minor cleanups to the dumping code.
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-trace.cc (debug_seed_ranger): Remove static.
(dump_ranger): Dump function name.
---
gcc/gimple-range-trace.cc | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --g
On 9/1/21 6:53 AM, Iain Sandoe wrote:
Some of the state that is associated with the implementation
is of interest to a user debugging a coroutine. In particular
items such as the suspend point, promise object, and current
suspend point.
These variables live in the coroutine frame, but we can i
On 9/1/21 6:54 AM, Iain Sandoe wrote:
Some of the compiler-generated entries are of interest to a
user debugging - keep variables in the implementation namespace
but avoid using periods as separators (which is not compatible
with visible symbols for some assemblers).
Partial improvement to debu
Committed as obvious.
Tested on x86-64 Linux.
gcc/ChangeLog:
* tree-ssa-threadupdate.c (debug): New.
---
gcc/tree-ssa-threadupdate.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index d08e7d30d8d..1d32a0230fb 100644
On 9/1/21 6:54 AM, Iain Sandoe wrote:
This is an efficiency measure and repeats the pattern used for
other identifiers used in the coroutine implementation.
In support of debugging, the user might well need to look at some
of the variables that the implementation manipulates in lowering
the cor
> On 3 Sep 2021, at 14:39, Jason Merrill wrote:
>
> On 9/1/21 6:54 AM, Iain Sandoe wrote:
>> This is an efficiency measure and repeats the pattern used for
>> other identifiers used in the coroutine implementation.
>> In support of debugging, the user might well need to look at some
>> of the
> On 3 Sep 2021, at 14:39, Jason Merrill wrote:
>
> On 9/1/21 6:54 AM, Iain Sandoe wrote:
>> This is an efficiency measure and repeats the pattern used for
>> other identifiers used in the coroutine implementation.
>> In support of debugging, the user might well need to look at some
>> of the
We are popping state and then calling the registry code. This causes
the registry to have incorrect information. This isn't visible in
current trunk, but will be an issue when I submit further enhancements
to the threading code. However, it is a cleanup on its own so I am
pushing it now.
Tested
On 9/3/21 9:42 AM, Iain Sandoe wrote:
On 3 Sep 2021, at 14:39, Jason Merrill wrote:
On 9/1/21 6:54 AM, Iain Sandoe wrote:
This is an efficiency measure and repeats the pattern used for
other identifiers used in the coroutine implementation.
In support of debugging, the user might well need
[Jeff: I'm going to go out on a limb here and commit this under the
obvious rule. If I am overstepping my obvious powers, please let me
know.]
The jump threading state is about to get more interesting, and it may
get with a ranger or with the const_copies/etc helpers. This patch
makes sure we ha
On 9/1/21 6:55 AM, Iain Sandoe wrote:
The user might well wish to inspect some of the state that represents
the implementation of the coroutine machine.
In particular:
The promise object.
The function pointers for the resumer and destroyer.
The current resume index (suspend point).
We are inconsistent on dumping out reasons why a thread was canceled.
This makes debugging jump threading problems harder because paths can be
canceled with no reason given. This patch abstracts out the thread
canceling code and adds a reason for every cancellation.
Tested on x86-64 Linux.
OK?
This patch adds debugging helpers to the backwards threader. I have
also noticed that profitable_path_p() can bail early on paths that
crosses loops and leave the dump of blocks incomplete. Fixed as
well.
Unfortunately the new methods cannot be marked const, because we call
the solver's dump whi
> On 3 Sep 2021, at 14:52, Jason Merrill wrote:
>
> On 9/1/21 6:55 AM, Iain Sandoe wrote:
>> The user might well wish to inspect some of the state that represents
>> the implementation of the coroutine machine.
>> In particular:
>> The promise object.
>> The function pointers for the resum
The registry's thread_through_all_blocks() has a may_peel_loop_headers
argument. When refactoring the backward threader code, I removed this
argument for the local passthru method because it was always TRUE. This
may not necessarily be true in the future, if the backward threader is
called from a
This patch abstracts out a couple common idioms in the forward
threader that I found useful while navigating the code base.
Tested on x86-64 Linux.
OK?
gcc/ChangeLog:
* tree-ssa-threadedge.c (has_phis_p): New.
(forwarder_block_p): New.
(potentially_threadable_block): Cal
On 9/1/21 6:56 AM, Iain Sandoe wrote:
This adds top level proxy variables for the coroutine frame
copies of the original function args. These are then available
in the debugger to refer to the frame copies. We rewrite the
function body to use the copies, since the original parms will
no longer
On 9/3/21 9:56 AM, Iain Sandoe wrote:
On 3 Sep 2021, at 14:52, Jason Merrill wrote:
On 9/1/21 6:55 AM, Iain Sandoe wrote:
The user might well wish to inspect some of the state that represents
the implementation of the coroutine machine.
In particular:
The promise object.
The function
> On 3 Sep 2021, at 15:12, Jason Merrill wrote:
>
> On 9/3/21 9:56 AM, Iain Sandoe wrote:
>>> On 3 Sep 2021, at 14:52, Jason Merrill wrote:
>>>
>>> On 9/1/21 6:55 AM, Iain Sandoe wrote:
The user might well wish to inspect some of the state that represents
the implementation of the
> On 3 Sep 2021, at 15:07, Jason Merrill via Gcc-patches
> wrote:
>
> On 9/1/21 6:56 AM, Iain Sandoe wrote:
>> This adds top level proxy variables for the coroutine frame
>> copies of the original function args. These are then available
>> in the debugger to refer to the frame copies. We re
On 9/1/21 6:56 AM, Iain Sandoe wrote:
When we have a suspend method that returns a coroutine handle
we transfer (hopefully symmetrically, i.e. with a tailcall) to
that new coroutine instead of returning to our resumer.
This adds the variable to the outer block for the actor function
which means
This patch abstracts out a couple common idioms in the forward
threader that I found useful while navigating the code base.
Tested on x86-64 Linux.
OK?
gcc/ChangeLog:
* tree-ssa-threadedge.c (has_phis_p): New.
(forwarder_block_p): New.
(potentially_threadable_block): Cal
[Andrew, do you see any problem with using the minus relational code
here? It seems like everything matches up.]
I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equivalent, and yet we
fail to return 0 for the range. This i
Ping.
Qing
> On Aug 21, 2021, at 3:07 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi,
>
> This is the 8th version of the patch for the new security feature for GCC.
> I have tested it with bootstrap on both x86 and aarch64, regression testing
> on both x86 and aarch64.
> Also tested it with t
Hi Xionghu,
This looks okay to me. Recommend maintainers approve.
Thanks!
Bill
On 9/2/21 9:31 PM, Xionghu Luo wrote:
Resend the patch that addressed Will's comments.
fmod/fmodf and remainder/remainderf could be expanded instead of library
call when fast-math build, which is much faster.
fm
On Thu, Sep 2, 2021 at 10:31 PM Xionghu Luo wrote:
>
> Resend the patch that addressed Will's comments.
>
>
> fmod/fmodf and remainder/remainderf could be expanded instead of library
> call when fast-math build, which is much faster.
>
> fmodf:
> fdivs f0,f1,f2
> frizf0,f0
> f
On 9/3/2021 7:55 AM, Aldy Hernandez wrote:
We are inconsistent on dumping out reasons why a thread was canceled.
This makes debugging jump threading problems harder because paths can be
canceled with no reason given. This patch abstracts out the thread
canceling code and adds a reason for eve
On 9/3/2021 7:56 AM, Aldy Hernandez wrote:
This patch adds debugging helpers to the backwards threader. I have
also noticed that profitable_path_p() can bail early on paths that
crosses loops and leave the dump of blocks incomplete. Fixed as
well.
Unfortunately the new methods cannot be mar
On 9/3/2021 7:56 AM, Aldy Hernandez wrote:
This patch abstracts out a couple common idioms in the forward
threader that I found useful while navigating the code base.
Tested on x86-64 Linux.
OK?
gcc/ChangeLog:
* tree-ssa-threadedge.c (has_phis_p): New.
(forwarder_block_p):
On 9/3/2021 7:57 AM, Aldy Hernandez wrote:
The registry's thread_through_all_blocks() has a may_peel_loop_headers
argument. When refactoring the backward threader code, I removed this
argument for the local passthru method because it was always TRUE. This
may not necessarily be true in the f
On 9/3/21 10:41 AM, Aldy Hernandez wrote:
[Andrew, do you see any problem with using the minus relational code
here? It seems like everything matches up.]
I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equivalent, and ye
On Sep 02 2021, Segher Boessenkool wrote:
> On Tue, Aug 31, 2021 at 07:17:49PM +0800, liuhongt via Gcc-patches wrote:
>> * emit-rtl.c (validate_subreg): Get rid of all float-int
>> special cases.
>
> This caused various regressions on powerpc. Please revert this until
> this can be done
On 9/3/2021 9:05 AM, Andrew MacLeod via Gcc-patches wrote:
On 9/3/21 10:41 AM, Aldy Hernandez wrote:
[Andrew, do you see any problem with using the minus relational code
here? It seems like everything matches up.]
I've seen cases in the upcoming jump threader enhancements where we see
a dif
My change to make limit_bad_template_recursion avoid instantiating members
of erroneous classes produced a bogus "used but not defined" warning for
23_containers/unordered_set/instantiation_neg.cc; it's not defined because
we decided not to instantiate it. So we need to suppress that warning.
Tes
On 9/3/21 5:04 PM, Jeff Law wrote:
On 9/3/2021 7:57 AM, Aldy Hernandez wrote:
The registry's thread_through_all_blocks() has a may_peel_loop_headers
argument. When refactoring the backward threader code, I removed this
argument for the local passthru method because it was always TRUE. Thi
> On 3 Sep 2021, at 08:51, Iain Sandoe wrote:
>
>
>> On 2 Sep 2021, at 21:03, Joseph Myers wrote:
>>
>> On Thu, 2 Sep 2021, Iain Sandoe via Gcc-patches wrote:
>>
>>> diff --git a/libgcc/soft-fp/eqdf2.c b/libgcc/soft-fp/eqdf2.c
>>> index 2a44ee377ce..a3bb664f5f1 100644
>>> --- a/libgcc/soft
On Thu, 2 Sep 2021, Jason Merrill wrote:
> On 8/31/21 3:15 PM, Patrick Palka wrote:
> > On Mon, 30 Aug 2021, Patrick Palka wrote:
> >
> > > In the context of overload resolution we have the notion of a "bad"
> > > argument conversion, which is a conversion that "would be a permitted
> > > with a
On 9/3/21 5:05 PM, Andrew MacLeod wrote:
On 9/3/21 10:41 AM, Aldy Hernandez wrote:
[Andrew, do you see any problem with using the minus relational code
here? It seems like everything matches up.]
I've seen cases in the upcoming jump threader enhancements where we see
a difference of two poi
On Fri, Sep 03, 2021 at 09:09:59AM -0600, Jeff Law via Gcc-patches wrote:
>
>
> On 9/3/2021 9:05 AM, Andrew MacLeod via Gcc-patches wrote:
> > On 9/3/21 10:41 AM, Aldy Hernandez wrote:
> > > [Andrew, do you see any problem with using the minus relational code
> > > here? It seems like everything
Hi Kewen,
Sorry that we lost track of this patch! The heuristic approach looks
good. It is limited in scope and won't kick in often, and the case
you're trying to account for is important.
At the time you submitted this, I think reliable P10 testing wasn't
possible. Now that it is, could
Hi!
On 2021-09-02T21:09:54+0200, I wrote:
> On 2021-09-02T15:59:14+0200, I wrote:
>> On 2016-08-05T14:16:58-0400, David Malcolm wrote:
>>> Committed to trunk as r239175; I'm attaching the final version of the
>>> patch for reference.
>>
>> David, you've added here 'gcc/input.h:struct location_has
On 9/3/21 5:41 PM, Jakub Jelinek wrote:
On Fri, Sep 03, 2021 at 09:09:59AM -0600, Jeff Law via Gcc-patches wrote:
On 9/3/2021 9:05 AM, Andrew MacLeod via Gcc-patches wrote:
On 9/3/21 10:41 AM, Aldy Hernandez wrote:
[Andrew, do you see any problem with using the minus relational code
here?
On 9/3/21 8:41 AM, Aldy Hernandez via Gcc-patches wrote:
[Andrew, do you see any problem with using the minus relational code
here? It seems like everything matches up.]
I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equ
Patches welcome :-).
On Fri, Sep 3, 2021, 18:42 Martin Sebor wrote:
> On 9/3/21 8:41 AM, Aldy Hernandez via Gcc-patches wrote:
> > [Andrew, do you see any problem with using the minus relational code
> > here? It seems like everything matches up.]
> >
> > I've seen cases in the upcoming jump th
On 9/3/21 3:14 AM, Tobias Burnus wrote:
If I read https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
correctly, we should use _Float128 for the following errors
"The _Float128 type is supported on all systems where __float128 is
supported or where long double has the IEEE binary128 format
On 9/2/21 11:37 PM, Sandra Loosemore wrote:
On 9/2/21 10:18 PM, sunil.k.pandey wrote:
On Linux/x86_64,
93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit
commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d7
Author: Sandra Loosemore
Date: Wed Aug 18 07:22:03 2021 -0700
libgfort
On Mon, 30 Aug 2021, David Malcolm via Gcc-patches wrote:
> gcc/analyzer/ChangeLog:
> PR analyzer/99260
> * analyzer.h (class custom_edge_info): New class, adapted from
> exploded_edge::custom_info_t. Make member functions const.
> Make update_model return bool, converting
On Fri, Sep 3, 2021 at 10:25 AM Sandra Loosemore
wrote:
>
> On 9/2/21 11:37 PM, Sandra Loosemore wrote:
> > On 9/2/21 10:18 PM, sunil.k.pandey wrote:
> >> On Linux/x86_64,
> >>
> >> 93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit
> >> commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d
Hi!
Martin, thanks for your review. Now need someone to formally approve the
third patch.
On 2021-09-01T18:14:46-0600, Martin Sebor wrote:
> On 9/1/21 1:35 PM, Thomas Schwinge wrote:
>> On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches
>> wrote:
>>> On 6/22/21 5:28 PM, David Malcolm w
CR is saved and/or restored on some paths where GPR12 is already live
since it has a meaning in the calling convention in the ELFv2 ABI.
It is not completely clear to me that we can always use r11 here, but
it does seem save, there is checking code (to detect conflicts here),
and it is stage 1. S
Hi!
On Fri, Sep 03, 2021 at 10:31:24AM +0800, Xionghu Luo wrote:
> fmod/fmodf and remainder/remainderf could be expanded instead of library
> call when fast-math build, which is much faster.
Thank you very much for this patch.
Some trivial comments if you haven't commmitted it yet:
> +(define_e
On Fri, Sep 3, 2021 at 2:42 AM Richard Sandiford via Gcc-patches
wrote:
>
> apinski--- via Gcc-patches writes:
> > From: Andrew Pinski
> >
> > This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
> > we are not going to error out. It fixes the problem by the removal
> > of t
From: Andrew Pinski
This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
we are not going to error out. It fixes the problem by the removal
of the function from the IR.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
PR target/9
86 matches
Mail list logo
