Enable -mpcrel on PowerPC -mcpu=future ELF v2 systems, V3
This patch changes the default for -mcpu=future to be -mpcrel (i.e. use
PC-relative addressing) if the ABI allows PC-relative relocations and the user
did not use either -mno-pcrel or -mno-prefixed.
I have changed the spelling of the
This removes the use of replace_placeholders in cxx_eval_constant_expression
(which causes the new test lambda-this6.C to ICE due to replace_placeholders
mutating the shared TARGET_EXPR_INITIAL tree which then trips up the
gimplifier).
In its place, this patch adds a 'parent' field to
I noticed a bunch of comment typos in get_alias_set when I was reading
code to try to track down a bug affecting nios2 targets (see pr93946).
I've checked in this patch to clean them up.
-Sandra
commit 63f56527335a7667769b5dea15569e23d0ebc749
Author: Sandra Loosemore
Date: Thu Apr 2
Hi!
The ix86_get_mask_mode hook uses int mask for 512-bit vectors or 128/256-bit
vectors with AVX512VL (that is correct), and only for V*[SD][IF]mode if not
AVX512BW (also correct), but with AVX512BW it would stop checking the
elem_size altogether and pretend the hw has masking support for
Hi!
On Mon, Mar 30, 2020 at 11:59:57AM +0800, luoxhu wrote:
> > Do we want something later in the RTL pipeline to make "addi"s etc. again?
(This would be a good thing to consider -- maybe a define_insn_and_split
will work. But see below).
> [PATCH] rs6000: Don't split constant operator add
On Sat, Mar 28, 2020 at 06:39:56PM -0500, Peter Bergner wrote:
> On 3/28/20 2:22 PM, Segher Boessenkool wrote:
> > On Fri, Mar 27, 2020 at 05:41:36PM -0500, Peter Bergner wrote:
> >> A different (ie, safer) approach would be to just rerun lower-subreg at
> >> its old location, regardless of
On 4/2/20 4:09 AM, Tobias Burnus wrote:
Interestingly, only those two testcases use the effective-target check:
gcc.dg/analyzer/sigsetjmp-5.c, gcc.dg/analyzer/sigsetjmp-6.c
Regarding the link test: No header file is included – it just
defines the function ("extern char $funcname();") and calls
Hi!
Some more comments:
On Fri, Mar 27, 2020 at 09:31:46PM -0400, Michael Meissner wrote:
> There were no regressions when I did the bootstrap and make check steps. I
> verified that -mcpu=future does turn on -mprecl if you are targeting a Linux
> ELF v2 system and use the medium code model.
On Thu, 2 Apr 2020, Maciej W. Rozycki wrote:
> > OK. Can you also update gcc-10/changes.html?
>
> Change now applied, thank you for your review, and patch posted for
> wwwdocs [I meant to give a link to the message in the archive here, but it
> seems behind by ~2.5 hours; something to look
On Thu, Apr 2, 2020 at 3:43 AM Kewen.Lin wrote:
>
> on 2020/4/2 上午6:51, H.J. Lu wrote:
> >
> > This caused:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
> >
>
> Thanks for reporting this. The attached patch is to fix the stupid
> mistake by using gsi_insert_seq_before instead of
On 4/2/20 11:53 AM, Richard Henderson via Gcc-patches wrote:
> This is attacking case 3 of PR 94174.
>
> In v2, I unify the various subtract-with-borrow and add-with-carry
> patterns that also output flags with unspecs. As suggested by
> Richard Sandiford during review of v1. It does seem
Return the entire comparison expression, not just the cc_reg.
This will allow the routine to adjust the comparison code as
needed for TImode comparisons.
Note that some users were passing e.g. EQ to aarch64_gen_compare_reg
and then using gen_rtx_NE. Pass the proper code in the first place.
Modify aarch64_expand_subvti into a form that handles all
addition and subtraction, modulo, signed or unsigned overflow.
Use expand_insn to put the operands into the proper form,
and do not force values into register if not required.
* config/aarch64/aarch64.c (aarch64_ti_split) New.
The rtl description of signed/unsigned overflow from subtract
was fine, as far as it goes -- we have CC_Cmode and CC_Vmode
that indicate that only those particular bits are valid.
However, it's not clear how to extend that description to
handle signed comparison, where N == V (GE) N != V (LT) are
Now that we're using UNSPEC_ADCS instead of rtl, there's
no reason to distinguish CC_ADCmode from CC_Cmode. Both
examine only the C bit. Within uaddvti4, using CC_Cmode
is clearer, since it's the carry-outthat's relevant.
* config/aarch64/aarch64-modes.def (CC_ADC): Remove.
*
* config/aarch64/aarch64.md (absti2): New.
---
gcc/config/aarch64/aarch64.md | 29 +
1 file changed, 29 insertions(+)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index cf716f815a1..4a30d4cca93 100644
---
* config/aarch64/predicates.md (aarch64_reg_or_minus1): New.
* config/aarch64/aarch64.md (add3_carryin): Use it.
(*add3_carryin): Likewise.
(*addsi3_carryin_uxtw): Likewise.
---
gcc/config/aarch64/aarch64.md| 26 +++---
Similar to UNSPEC_SBCS, we can unify the signed/unsigned overflow
paths by using an unspec.
Accept -1 for the second input by using SBCS.
* config/aarch64/aarch64.md (UNSPEC_ADCS): New.
(addvti4, uaddvti4): Use adddi_carryin_cmp.
(add3_carryinC): Remove.
Use ccmp to perform all TImode comparisons branchless.
* config/aarch64/aarch64.c (aarch64_gen_compare_reg): Expand all of
the comparisons for TImode, not just NE.
* config/aarch64/aarch64.md (cbranchti4, cstoreti4): New.
---
gcc/config/aarch64/aarch64.c | 122
While cmp (extended register) and cmp (immediate) uses ,
cmp (shifted register) uses . So we can perform cmp xzr, x0.
For ccmp, we only have as an input.
* config/aarch64/aarch64.md (cmp): For operand 0, use
aarch64_reg_or_zero. Shuffle reg/reg to last alternative
and
This is attacking case 3 of PR 94174.
In v2, I unify the various subtract-with-borrow and add-with-carry
patterns that also output flags with unspecs. As suggested by
Richard Sandiford during review of v1. It does seem cleaner.
r~
Richard Henderson (11):
aarch64: Accept 0 as first
The expander and the insn pattern did not match, leading to
recognition failures in expand.
* config/aarch64/aarch64.md (*add3_carryin): Accept zeros.
---
gcc/config/aarch64/aarch64.md | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
In one place we open-code a special case of this pattern into the
more specific sub3_compare1_imm, and miss this special case
in other places. Centralize that special case into an expander.
* config/aarch64/aarch64.md (*sub3_compare1): Rename
from sub3_compare1.
Hello,
The free() function was missing from a part of the documentation!
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index bde37482b6e..79e2c8cb87f 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12670,7 +12670,7 @@ The ISO C90 functions
@code{abort}, @code{abs},
On Thu, 2 Apr 2020, Patrick Palka wrote:
> This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do
> not anticipate that a constructor element's initializer could mutate the
> underlying CONSTRUCTOR. Evaluation of the initializer could add new elements
> to
> the
This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do
not anticipate that a constructor element's initializer could mutate the
underlying CONSTRUCTOR. Evaluation of the initializer could add new elements to
the underlying CONSTRUCTOR, thereby potentially invalidating any
On Fri, Mar 27, 2020 at 02:30:36PM -0400, Michael Meissner wrote:
> > > -/* Support for a future processor's features. Do not enable -mpcrel
> > > until it
> > > - is fully functional. */
> > > +/* Support for a future processor's features. The addressing related
> > > options
> > > +
On Wed, Apr 1, 2020 at 2:55 PM Nathan Sidwell wrote:
> Jason,
>
> This is from pr94426, which is fallout from my pr94147 fix.
>
> You added the following to no_linkage_check as part of
>
> 2018-11-12 Jason Merrill
> Implement P0315R4, Lambdas in unevaluated contexts.
>
>/*
On Thu, 2 Apr 2020 at 17:16, Martin Liška wrote:
>
> Hi.
>
> The patch compares type attributes for gimple_call_fntypes in IPA ICF.
> Note that we were unable to find a generic function attribute that
> can be used on a function type definition.
>
> For a one which is allowed assume_aligned(16) I
Hi All,
It is currently impossible to use fp16 on any architecture higher than Armv8.3-a
due to a bug in options canonization. This bug results in the fp16 flag not
being emitted in the assembly when it should have been.
This is caused by a complicated architectural requirement at Armv8.4-a.
Hi,
This is non-trivial but rather straightforward backport of
29f23ed79b60949fc60f6fdbbd931bd58090b241 from master. See
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542390.html for
more information.
Bootstrapped and tested on gcc-9 branch, can I commit it there? It also
applies as-is
Tobias,
Thank you for the information. I didn't think about translations. I'll
post a new version and commit shortly.
Cheers,
Fritz
On Thu, Apr 2, 2020 at 3:50 AM Tobias Burnus wrote:
>
> In principle, I like the patch. However, I think one should
> replace
>
> gfc_error ("Attribute at %L is
On 02/04/2020 15:55, Kwok Cheung Yeung wrote:
Hello
This patch adds support for the unordered floating-point comparison
operators (UNEQ, UNGE, UNGT, UNLE, UNLT), which return true if one of
the operands is a NaN. These comparisons can be generated by builtins
such as __builtin_isgreater.
On Thu, Apr 2, 2020 at 5:30 AM CHIGOT, CLEMENT wrote:
>
> Description:
> * AIX applications using 128-bit long double must be linked with
>libc128.a, in order to have 128-bit compatible routines.
>
> Tests:
> * AIX 7.2, 7.1: Build/Tests: OK
>
> Changelog:
> * config/rs6000/aix61.h
Hi.
The patch compares type attributes for gimple_call_fntypes in IPA ICF.
Note that we were unable to find a generic function attribute that
can be used on a function type definition.
For a one which is allowed assume_aligned(16) I get affects_type_identity ==
false
which seems suspicious to
This one is a little bit wierd for me. It seems AS_DEFERRED
is overloaded and things get fixed up later. In array.c
one finds match_array_element_spec(), which set AS_DEFERRED
if the matchers sees (:) regardless of how the array is used.
Then in gfc_set_array_spec(), the array spec is attached
On Thu, 2 Apr 2020, Richard Biener wrote:
> > > Our installation instructions state binutils 2.28 as the requirement for
> > > all the RISC-V targets, however the change for fmv.x.w/fmv.w.x instruction
> > > support was only added in the binutils 2.30 development cycle.
> >
> > Here's the
Hello
This patch adds support for the unordered floating-point comparison operators
(UNEQ, UNGE, UNGT, UNLE, UNLT), which return true if one of the operands is a
NaN. These comparisons can be generated by builtins such as __builtin_isgreater.
GCC 10 appears to have a fall-back if the
Loop-im and PRE can hoist loads out of loops, creating artificial dependencies
that inhibit graphite's analysis.
do k = 1,4096
do j = 1,4096
do i = 1,4096
c(i,j)= c(i, j) + a(k,j) * b(i, k)
enddo
enddo
enddo
In the preceding loop body, the a(k,j) load can be
Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather
than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update
binutils requirement to 2.30").
---
Hi,
OK to apply?
Maciej
---
htdocs/gcc-10/changes.html | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
---
Hi,
Committed as obvious.
Maciej
---
htdocs/gcc-10/changes.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 1e1eaf43..3d8e0ba9 100644
--- a/htdocs/gcc-10/changes.html
+++
This removes the DW_TAG_imported_unit we generate for each referenced
early debug unit in LTRANS units. They are more harmful than they
do good and the semantics can be read in a way making it even wrong.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2020-04-02
Hi!
I've noticed while trying to reproduce PR92989 the following warning:
In file included from ./tm.h:42,
from ../../gcc/backend.h:28,
from ../../gcc/lra-assigns.c:80:
../../gcc/config/mips/mti-linux.h:31:5: warning: invalid suffix on literal;
C++11 requires a
On Thu, Apr 02, 2020 at 12:44:32PM +0200, Richard Biener wrote:
> > For the PR in question, my proposal would be to also lower
> > -param=max-find-base-term-values=
> > default from 2000 to 200 after this, at least in the above 4
> > bootstraps/regtests there is nothing that would ever result in
>
Hi!
On Thu, Apr 02, 2020 at 10:28:34AM +0200, Jakub Jelinek wrote:
> > + tree offset = dataref_offset
> > + ? dataref_offset
> > + : build_int_cst (ref_type, 0);
>
> The above is misformatted. The ? and :
On Thu, 2 Apr 2020, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, if !ACCUMULATE_OUTGOING_ARGS on large functions we
> can have hundreds of thousands of stack pointer adjustments and cselib
> creates a new VALUE after each sp adjustment, which form extremely deep
> VALUE chains, which
on 2020/4/2 上午6:51, H.J. Lu wrote:
>
> This caused:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
>
Thanks for reporting this. The attached patch is to fix the stupid
mistake by using gsi_insert_seq_before instead of gsi_insert_before.
BTW, the regression testing on one x86_64
On Thu, Apr 02, 2020 at 06:07:55PM +0800, Kewen.Lin wrote:
> > The above is misformatted. The ? and : shouldn't be indented further than
> > the dataref_offset, but usually e.g. for the sake of emacs we add ()s around
> > the expression in this case. So:
> > tree offset =
On Thu, Apr 2, 2020 at 12:21 PM Martin Jambor wrote:
>
> Hi,
>
> I forgot to document the new param in invoke.texi, does the text below
> look OK?
OK.
> Tested with make info and make pdf.
>
> Thanks,
>
> Martin
>
>
> 2020-04-02 Martin Jambor
>
> * doc/invoke.texi (Optimize Options):
on 2020/4/2 下午5:21, Richard Biener wrote:
> On Thu, Apr 2, 2020 at 9:15 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> The commit r10-7415 brings scalar type consideration
>> to eliminate epilogue peeling for gaps, but it exposed
>> one problem that the current handling doesn't consider
>> the memory access
Hi!
As discussed in the PR, if !ACCUMULATE_OUTGOING_ARGS on large functions we
can have hundreds of thousands of stack pointer adjustments and cselib
creates a new VALUE after each sp adjustment, which form extremely deep
VALUE chains, which is very harmful e.g. for find_base_term.
E.g. if we
Hi,
I forgot to document the new param in invoke.texi, does the text below
look OK?
Tested with make info and make pdf.
Thanks,
Martin
2020-04-02 Martin Jambor
* doc/invoke.texi (Optimize Options): Document sra-max-propagations.
---
gcc/ChangeLog | 4
Interestingly, only those two testcases use the effective-target check:
gcc.dg/analyzer/sigsetjmp-5.c, gcc.dg/analyzer/sigsetjmp-6.c
Regarding the link test: No header file is included – it just
defines the function ("extern char $funcname();") and calls it.
The check fails as "sigsetjmp" does
Hi,
on 2020/4/2 下午4:28, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Apr 02, 2020 at 03:15:42PM +0800, Kewen.Lin via Gcc-patches wrote:
>
> Just formatting nits, not commenting on what the actual patch does.
>
>> --- a/gcc/tree-vect-stmts.c
>> +++ b/gcc/tree-vect-stmts.c
>> @@ -9590,11 +9590,20 @@
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 02 April 2020 09:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE: Fix polymorphism for scalars and
> constants
>
> Hi,
>
> This patch merges some polymorphic functions that were
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 31 March 2020 17:13
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
>
> Subject: [GCC][PATCH][ARM]: Fix for MVE ACLE intrinsics with writeback
> (PR94317).
>
> Hello,
>
> Following MVE ACLE
Jonathan Wakely writes:
> On 02/04/20 10:44 +0200, Andrea Corallo wrote:
>>Jonathan Wakely writes:
>>
>>> On 01/04/20 16:56 +0100, Jonathan Wakely wrote:
>>
>>> Does that help, or does it still fail for other reasons?
>>
>>Yes it does thanks! Updated patch follows.
>>
>>Okay for trunk?
>
> OK,
Hi,
On Fri, Mar 20 2020, Jan Hubicka wrote:
>
[...]
>
> OK except for ...
>> @@ -3759,8 +3778,12 @@ process_isra_node_results (cgraph_node *node,
>> = node->create_virtual_clone (callers, NULL, new_adjustments, "isra",
>>suffix_counter);
>>
On Thu, 2 Apr 2020, Jakub Jelinek wrote:
> On Thu, Apr 02, 2020 at 11:12:48AM +0200, Richard Biener wrote:
> > > "The implementation may assume that any thread will eventually do one of
> > > the
> > > following:
> > > — terminate,
> > > — make a call to a library I/O function,
> > > —
Jakub Jelinek writes:
> Hi!
>
> The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits
> invalid RTL.
> For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that fits
> into that mode) and x being SImode; for non-CONST_INT y it zero extends y
> into SImode and
Hi!
On 2020-03-22T11:31:31-0600, Sandra Loosemore wrote:
> The new-ish analyzer test cases sigsetjmp-5.c and sigsetjmp-6.c were
> failing on nios2-elf and probably other newlib targets due to lack of
> support for sigsetjmp. I didn't see a suitable existing
> effective-target test for this, so
Hi Steve,
I think your patch is fine - however, I think calling the normal
resolve_formal_arglist looks a bit cleaner to me (as done in the
attached patch). — Additionally, I added the testcase.
Side effect of my variant is that gfc_check_dtio_interfaces will
be called again a bit later again.
Description:
* AIX applications using 128-bit long double must be linked with
libc128.a, in order to have 128-bit compatible routines.
Tests:
* AIX 7.2, 7.1: Build/Tests: OK
Changelog:
* config/rs6000/aix61.h (LIB_SPEC): Add -lc128 with -mlong-double-128.
* config/rs6000/aix71.h
On Thu, Apr 2, 2020 at 9:15 AM Kewen.Lin wrote:
>
> Hi,
>
> The commit r10-7415 brings scalar type consideration
> to eliminate epilogue peeling for gaps, but it exposed
> one problem that the current handling doesn't consider
> the memory access type VMAT_CONTIGUOUS_REVERSE, for
> which the
On Thu, Apr 02, 2020 at 11:12:48AM +0200, Richard Biener wrote:
> > "The implementation may assume that any thread will eventually do one of the
> > following:
> > — terminate,
> > — make a call to a library I/O function,
> > — perform an access through a volatile glvalue, or
> > — perform a
On 02/04/20 10:44 +0200, Andrea Corallo wrote:
Jonathan Wakely writes:
On 01/04/20 16:56 +0100, Jonathan Wakely wrote:
Does that help, or does it still fail for other reasons?
Yes it does thanks! Updated patch follows.
Okay for trunk?
OK, thanks.
On Wed, 1 Apr 2020, Jason Merrill wrote:
> On 4/1/20 9:36 AM, Richard Biener wrote:
> > This does away with enabling -ffinite-loops at -O2+ for all languages
> > and instead enables it selectively for C++ only.
> >
> > Jason, I didn't find a reference as to when the forward progress
> >
Hi Tobias,
I would say that if any patch were obvious, that one is :-) OK.
Thanks
Paul
On Mon, 30 Mar 2020 at 09:16, Tobias Burnus wrote:
> Early *ping*.
>
> Tobias
>
> On 3/27/20 11:06 AM, Tobias Burnus wrote:
>
> > Hi all,
> >
> > here, the reject_statement cleanup and the freeing of the
Jonathan Wakely writes:
> On 01/04/20 16:56 +0100, Jonathan Wakely wrote:
> Does that help, or does it still fail for other reasons?
Yes it does thanks! Updated patch follows.
Okay for trunk?
Thanks
Andrea
libstdc++-v3/ChangeLog
2020-??-?? Andrea Corallo
*
On Wednesday, 1 April 2020 19:48:11 CEST Olivier Hainque wrote:
>
> -r 's business was to arrange for the linker not to
> complain because the closure is incomplete, leaving us
> with complete control of the closure.
>
> It doesn't seem to me there was a really strong motivation
> to suddenly
Hi!
On Thu, Apr 02, 2020 at 03:15:42PM +0800, Kewen.Lin via Gcc-patches wrote:
Just formatting nits, not commenting on what the actual patch does.
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -9590,11 +9590,20 @@ vectorizable_load (stmt_vec_info stmt_info,
>
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 02 April 2020 09:20
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: Do not process rest of MVE header file after
> unsupported error
>
> Hi,
>
> This patch makes sure the rest of the header
Hi,
This patch makes sure the rest of the header file is not parsed if MVE
is not supported. The user should not be including this file if MVE is
not supported, nevertheless making sure it doesn't parse the rest of the
header file will save the user from a huge error output that would be
In principle, I like the patch. However, I think one should
replace
gfc_error ("Attribute at %L is not allowed in a %s definition",
…, state_name
by something like:
bool is_type = gfc_current_state () == COMP_DERIVED;
gfc_error (is_type ? G_("Attribute at %L is not allowed in a TYPE
On Thu, Apr 2, 2020 at 5:36 AM bule wrote:
>
> Hello,
>
> An Internal Compiler Error(ICE) is found in ipa-sra optimization pass when it
> handle the argument of internal call svst3 for SVE.
>
> The problem comes from
> gcc/testsuite/gcc.target/aarch64/sve/acle/asm/st2_bf16.c in the test suit,
Hi!
My recent protected_set_expr_location changes work well when
that function is called unconditionally, but as the testcase shows, the C++
FE has a few spots that do:
if (!EXPR_HAS_LOCATION (stmt))
protected_set_expr_location (stmt, locus);
or similar. Now, if we have for -g0 stmt of
On Wed, Apr 1, 2020 at 10:34 PM Maciej W. Rozycki via Gcc-patches
wrote:
>
> Complement commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather
> than fmv.x.s/fmv.s.x") and document a binutils 2.30 requirement in the
> installation manual, matching the addition of fmv.x.w/fmv.w.x mnemonics
>
On Thu, 2 Apr 2020 at 04:34, Pop, Sebastian wrote:
>
> I have also seen this error in tsan.
> The fix is
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ea376dd471a3b006bc48945c1d9a29408ab17a04
> "Fix shrinkwrapping interactions with atomics (PR92692)".
> This fix got committed as the last patch
For operands with an identical set of alternatives there is no point
in marking them commutative. This patch removes the superfluous
constraint modifiers in vector.md and vx-builtins.md since it might
slow down reload without buying us anything.
There were even two patterns where the constraint
Hi,
The commit r10-7415 brings scalar type consideration
to eliminate epilogue peeling for gaps, but it exposed
one problem that the current handling doesn't consider
the memory access type VMAT_CONTIGUOUS_REVERSE, for
which the overrun happens on low address side. This
patch is to make the
On 3/27/20 11:06 AM, Tobias Burnus wrote:
Hi all,
here, the reject_statement cleanup and the freeing of the
namespace both remove the symbol. Solution: Remove it first,
then clean the namespace – then the reject_statement has no
(deleted) statement to cleanup.
As select rank is new, that's
Hi,
I've created a bug for this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
And I'm going to solve this problem by propagating def's insn to its use
when they are at the same loop in fwprop pass.
I mean something like:
diff --git a/gcc/fwprop.c b/gcc/fwprop.c
index
82 matches
Mail list logo
