We're wrongly guard zero_extendsidi2_internal pattern both ZBA and ZBB,
only ZBA provide zero_extendsidi2 instruction.
gcc/ChangeLog
* config/riscv/riscv.md (zero_extendsidi2_internal): Allow ZBB
use this pattern.
---
gcc/config/riscv/riscv.md | 2 +-
1 file changed, 1 insertion(
Canonical order for z-prefixed extension are rely on the canonical order of
single letter extension, however we didn't put i into the list before,
so when we put zicsr or zifencei it will got exception.
gcc/ChangeLog:
* config/riscv/arch-canonicalize (CANONICAL_ORDER): Add `i` to
On 2021/10/27 21:24, David Edelsohn wrote:
> On Sun, Oct 24, 2021 at 10:51 PM Xionghu Luo wrote:
>>
>> If the second operand of __builtin_shuffle is const vector 0, and with
>> specific mask, it can be optimized to vspltisw+xxpermdi instead of lxv.
>>
>> gcc/ChangeLog:
>>
>> * config/rs
On Tue, Oct 19, 2021 at 12:37 PM Fāng-ruì Sòng wrote:
>
> On Thu, Oct 14, 2021 at 5:13 PM Fangrui Song wrote:
> >
> > On 2021-10-06, Fangrui Song wrote:
> > >On 2021-09-27, Fangrui Song wrote:
> > >>On 2021-09-27, Florian Weimer wrote:
> > >>>* Fangrui Song:
> > >>>
> > Sanitizer runtimes nee
On Oct 26, 2021, Richard Biener wrote:
> OK.
Thanks. I've just fixed the ChangeLog entry and pushed it:
>> * common.opt (fharden-compares): New.
>> (fharden-conditional-branches): New.
>> * doc/invoke.texi: Document new options.
>> * gimple-harden-conditionals.cc: New.
+ * Makefile.in (OBJS)
Sorry for reposting, but I forgot to CC the gcc-patches mailing list. :-(
PR101324 shows a problem in disabling shrink-wrapping when using -mrop-protect
when there is a attribute optimize/pragma. Martin's patch below moves handling
of flag_shrink_wrap so it gets re-disbled when we change or add
On Mon, Oct 25, 2021 at 4:24 PM liuhongt wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
I'm going to check in this patch if there's no objection.
> gcc/ChangeLog:
>
> PR target/102464
> * config/i386/i386-builtin-types.def (V8HF_FTYPE_V8H
I just had a test on ppc64le, this patch pass bootstrap and regtest.
Is this patch OK for trunk?
Thanks for any comments.
BR,
Jiufu
On 2021-10-18 21:37, Jiufu Guo wrote:
With reference the discussions in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
https://gcc.gnu.org/pip
on 2021/10/28 上午9:43, David Edelsohn wrote:
> On Wed, Oct 27, 2021 at 9:30 PM Kewen.Lin wrote:
>>
>> Hi David,
>>
>> Thanks for the review!
>>
>> on 2021/10/27 下午9:12, David Edelsohn wrote:
>>> On Sun, Oct 24, 2021 at 11:04 PM Kewen.Lin wrote:
Hi,
As PR102767 shows, the commit
On 2021/10/27 20:54, Jan Hubicka wrote:
>> Hi,
>>
>> On 2021/9/28 20:09, Richard Biener wrote:
>>> On Fri, Sep 24, 2021 at 8:29 AM Xionghu Luo wrote:
Update the patch to v3, not sure whether you prefer the paste style
and continue to link the previous thread as Segher dislikes th
On Wed, Oct 27, 2021 at 9:30 PM Kewen.Lin wrote:
>
> Hi David,
>
> Thanks for the review!
>
> on 2021/10/27 下午9:12, David Edelsohn wrote:
> > On Sun, Oct 24, 2021 at 11:04 PM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> As PR102767 shows, the commit r12-3482 exposed one ICE in function
> >> rs6000_bu
PR102976 shows a test case where we generate wrong code when building
a vector pair from 2 vector registers. The bug here is that with unlucky
register assignments, we can clobber one of the input operands before
we write both registers of the output operand. The solution is to use
early-clobbers
Hi David,
Thanks for the review!
on 2021/10/27 下午9:12, David Edelsohn wrote:
> On Sun, Oct 24, 2021 at 11:04 PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR102767 shows, the commit r12-3482 exposed one ICE in function
>> rs6000_builtin_vectorization_cost. We claims V1TI supports movmisalign
>> on rs6
On Tue, Oct 26, 2021 at 5:51 PM Hongyu Wang via Gcc-patches
wrote:
>
> Hi,
>
> For _Float16 type, add insn and expanders to optimize x / y to
> x * rcp (y), and x / sqrt (y) to x * rsqrt (y).
> As Half float only have minor precision difference between div and
> mul * rcp, there is no need for New
On Wed, 27 Oct 2021 20:13:21 +0200
Aldy Hernandez via Gcc-patches wrote:
[would have to think about this some more but it's late here. Nits:]
> diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
> index 2acf375ca9a..0ad4f7a9495 100644
> --- a/gcc/value-relation.cc
> +++ b/gcc/value-relat
On Wed, Oct 27, 2021 at 12:14 AM Kito Cheng wrote:
> Otherwise it is LGTM, but I'm just surprised it's still 0.1 and not frozen
> yet.
>
We should have binutils support first before we have gcc support.
Otherwise that may lead to binutils errors later when zmmul gets passed
down to binutils. I
Hi!
On Wed, Oct 27, 2021 at 11:44:59AM -0700, H.J. Lu wrote:
> On Mon, Oct 25, 2021 at 4:39 PM Segher Boessenkool
> wrote:
> > This fixes bootstrap for the current problems building libffi.
> >
> > I'll work on getting this into upstream as well. If the maintainers
> > want it done differently,
On Sat, 4 Aug 2018 18:32:24 +0200
Bernhard Reutner-Fischer wrote:
> On Tue, 16 May 2017 at 21:08, Mike Stump wrote:
> >
> > On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote:
> >
> > > The change I care about in 1.5.3
> >
> > So, we haven't talked much about the version people want most.
On Linux/x86_64,
2f0b6a971a051f6e687a15dd2fa4bf431381e551 is the first bad commit
commit 2f0b6a971a051f6e687a15dd2fa4bf431381e551
Author: Aldy Hernandez
Date: Wed Oct 27 18:22:29 2021 +0200
Reorder relation calculating code in the path solver.
caused
FAIL: gcc.dg/guality/pr41616-1.c -O
This fixes an issue in the glibc port I am working on where the build
fails due to the warning:
error: calling ‘__builtin_return_address’ with a nonzero argument is unsafe
[-Werror=frame-address]
This is due to how the current implementation of _mcount in glibc uses
__builtin_return_address wi
On 10/27/21 17:10, Patrick Palka wrote:
On Wed, 27 Oct 2021, Jason Merrill wrote:
On 10/27/21 14:54, Patrick Palka wrote:
On Tue, 26 Oct 2021, Jakub Jelinek wrote:
On Tue, Oct 26, 2021 at 05:07:43PM -0400, Patrick Palka wrote:
The performance impact of the other calls to
cxx_eval_outermost_
ping
[I'll rebase and retest this too since it's been a while.
Ok if it passes?]
On Sun, 21 Oct 2018 16:04:34 +0200
Bernhard Reutner-Fischer wrote:
> Hi!
>
> Regtested on x86_64-unknown-linux, installing on
> aldot/fortran-fe-stringpool.
>
> We did not free global symbols. For a simplified abs
Ping
[hmz. it's been a while, I'll rebase and retest this one.
Ok if it passes?]
On Mon, 15 Oct 2018 10:23:06 +0200
Bernhard Reutner-Fischer wrote:
> If a finalization is not required we created a namespace containing
> formal arguments for an internal interface definition but never used
> any o
Hi!
I found this lying around in an oldish tree.
Regtest running over night, ok for trunk if it passes?
Bernhard Reutner-Fischer (1):
Tweak locations around CAF simplify
gcc/fortran/simplify.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
--
2.33.0
From: Bernhard Reutner-Fischer
addresses: FIXME: gfc_current_locus is wrong
by using the locus of the current intrinsic.
Regtests clean, ok for trunk?
gcc/fortran/ChangeLog:
2018-09-20 Bernhard Reutner-Fischer
* simplify.c (gfc_simplify_failed_or_stopped_images): Use
current
From: Bernhard Reutner-Fischer
Hi!
Delete some more declarations without definitions and make some
functions static.
Bootstrapped and regtested on x86_64-unknown-linux without regressions.
Ok for trunk?
gcc/fortran/ChangeLog:
* decl.c (gfc_insert_kind_parameter_exprs): Make static.
On Wed, 27 Oct 2021, Jason Merrill wrote:
> On 10/27/21 14:54, Patrick Palka wrote:
> > On Tue, 26 Oct 2021, Jakub Jelinek wrote:
> >
> > > On Tue, Oct 26, 2021 at 05:07:43PM -0400, Patrick Palka wrote:
> > > > The performance impact of the other calls to
> > > > cxx_eval_outermost_const_expr
> >
On 10/21/21 04:42, Jakub Jelinek wrote:
Hi!
Here is an attempt to implement DR2351 - void{} - where void{} after
pack expansion is considered valid and the same thing as void().
For templates, dunno if we have some better way to check if a CONSTRUCTOR
might be empty after pack expansion. Would
On Wed, 27 Oct 2021 21:05:03 +0100
Richard Purdie via Gcc-patches wrote:
> OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
> separately from the compiler and slightly differently to the standard gcc
> build.
>
> In general this works well but in trying to build them
On Wed, 27 Oct 2021 21:05:02 +0100
Richard Purdie via Gcc-patches wrote:
> When building in longer build paths (200+ characters), the
> "echo $(PLUGIN_HEADERS)" from the install-plugins target would cause an
> "argument list too long error" on some systems.
>
> Avoid this by calling make's sort
On 10/26/21 13:44, Patrick Palka wrote:
Here when checking for erroneous occurrences of 'auto' inside a template
argument (which is allowed by the concepts TS for class templates),
extract_autos_r picks up the CTAD placeholder for X{T{0}} which causes
check_auto_in_tmpl_args to reject this valid
On Wed, 27 Oct 2021 21:44:52 +0200
Harald Anlauf via Fortran wrote:
> Hi Bernhard,
>
> Am 27.10.21 um 19:40 schrieb Bernhard Reutner-Fischer via Fortran:
> > AFAICS current trunk still has this issue.
> > Any takers?
> > thanks,
>
> can you create a PR tracking this issue?
now https://gcc.gn
On 10/27/21 14:54, Patrick Palka wrote:
On Tue, 26 Oct 2021, Jakub Jelinek wrote:
On Tue, Oct 26, 2021 at 05:07:43PM -0400, Patrick Palka wrote:
The performance impact of the other calls to cxx_eval_outermost_const_expr
from p_c_e_1 is probably already mostly mitigated by the constexpr call
ca
During cross compiling, CPP is being set to the target compiler even for
build targets. As an example, when building a cross compiler targetting
mingw, the config.log for libiberty in
build.x86_64-pokysdk-mingw32.i586-poky-linux/build-x86_64-linux/libiberty/config.log
shows:
configure:3786: checki
OpenEmbedded/Yocto Project extensively uses gcc to cross compile in many
different and interesting places. On the most part we're very happy,
thanks! We do have a small collection of patches and I believe it would
be beneficial to share some of them.
I've picked some of the simpler ones and have t
OpenEmbedded/Yocto Project extensively uses the --sysroot support within gcc.
We discovered that when compiling preprocessed source (.i or .ii files), the
compiler will try and access the builtin sysroot location rather than the
--sysroot option specified on the commandline. If access to that direc
OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
separately from the compiler and slightly differently to the standard gcc build.
In general this works well but in trying to build them separately we run into
an issue since we're using our gcc, not xgcc and there is no w
Add a definition of the musl linker used on the nios2 platform.
2021-10-26 Richard Purdie
gcc/ChangeLog:
* config/nios2/linux.h (MUSL_DYNAMIC_LINKER): Add musl linker
Signed-off-by: Richard Purdie
---
gcc/config/nios2/linux.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/config
When building in longer build paths (200+ characters), the
"echo $(PLUGIN_HEADERS)" from the install-plugins target would cause an
"argument list too long error" on some systems.
Avoid this by calling make's sort function on the list which removes
duplicates and stops the overflow from reaching th
On Tue, Oct 26, 2021 at 5:47 AM Martin Liška wrote:
>
> On 10/25/21 18:10, Eric Gallager wrote:
> > On Mon, Oct 25, 2021 at 7:35 AM Martin Liška wrote:
> >>
> >> Hello.
> >>
> >> The patch adds missing Makefile mostlyclean.
> >>
> >> Ready to be installed?
> >> Thanks,
> >> Martin
> >>
> >
> > Ge
Dear Fortranners,
when debugging the testcase, I noticed that a coarray declaration in
a COMMON statement wrongly set the dimension attribute instead of the
codimension. As a consequence, subsequent checks that catch this
invalid situation would not trigger.
I see two possible solutions:
- in g
On Tue, 26 Oct 2021, Jakub Jelinek wrote:
> On Tue, Oct 26, 2021 at 05:07:43PM -0400, Patrick Palka wrote:
> > The performance impact of the other calls to cxx_eval_outermost_const_expr
> > from p_c_e_1 is probably already mostly mitigated by the constexpr call
> > cache and the fact that we try t
On Mon, Oct 25, 2021 at 4:39 PM Segher Boessenkool
wrote:
>
> This fixes bootstrap for the current problems building libffi.
>
> I'll work on getting this into upstream as well. If the maintainers
> want it done differently, at least we have bootstrap working again
> until then.
>
> Tested on pow
Add
commit 90205f67e465ae7dfcf733c2b2b177ca7ff68da0
Author: Segher Boessenkool
Date: Mon Oct 25 23:29:26 2021 +
rs6000: Fix bootstrap (libffi)
This fixes bootstrap for the current problems building libffi.
to LOCAL_PATCHES.
* LOCAL_PATCHES: Add commit 90454a90082.
---
l
From: Saagar Jha
Patch from the Arm64 Darwin branch, originally by Saagar Jha.
It seems that the OS major version is now tracking the kernel
major version - 9. Minor version has been set to kernel
minor - 1 as for Darwin20.
Tested on x86-64-darwin21, darwin20, darwin19, i686-darwin9,
x86_64-li
This change fixes a couple of warnings observed building libgcc on hppa64-linux.
The hppa64-linux target uses OPDs and doesn't require any special code to
canonicalize
function pointers for comparison. I removed inclusion of pa/t-linux from
tmake_file and
adjusted pa/t-linux64 to fix this issu
My upcoming work replacing the VRP threaders with a fully resolving
backward threader has tripped over various corner cases in the path
sensitive relation oracle. This patch kills second order relations when
we kill a relation.
Tested on x86-64 and ppc64le Linux.
Co-authored-by: Andrew MacLeod
Every time we have a killing statement, we must also kill the relations
seen so far. This is similar to what we did for the equivs inherent in
PHIs along a path.
Tested on x86-64 and ppc64le Linux.
gcc/ChangeLog:
* gimple-range-path.cc
(path_range_query::range_defined_in_block
Enabling the fully resolving threader triggers various relation
ordering issues that have previously been dormant because the VRP
hybrid threader (forward threader based) never gives us long enough
paths for this to matter. The new threader spares no punches in
finding non-obvious paths, so gettin
I merged trunk revision 99b1021d21e5812ed01221d8fca8e8a32488a934 to
the gccgo branch.
Ian
AFAICS current trunk still has this issue.
Any takers?
thanks,
On Sun, 2 Sep 2018 17:16:07 +0200
Bernhard Reutner-Fischer wrote:
>i spotted one
> (pre-existing) possible inconsistency that i did overlook back then:
>
> gfc_match_associate () reads
Richard Biener writes:
> This refactors the main loop analysis part in vect_analyze_loop,
> re-purposing the existing vect_reanalyze_as_main_loop for this
> to reduce code duplication. Failure flow is a bit tricky since
> we want to extract info from the analyzed loop but I wanted to
> share the
On 10/27/21 3:59 AM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
The problem here is tree-ssa-forwprop.c likes to produce
&MEM [(void *)_4 + 152B] which is the same as
_4 p+ 152 which the rest of GCC likes better.
This implements this transformation back to pointer plus to
improve be
On 10/27/21 9:48 AM, Tobias Burnus wrote:
On 27.10.21 17:36, Martin Sebor via Gcc-patches wrote:
On 10/27/21 7:30 AM, Jakub Jelinek wrote:
On Tue, Oct 26, 2021 at 10:22:19PM -0700, sunil.k.pandey via
Gcc-patches wrote:
FAIL: libgomp.c/doacross-1.c (test for excess errors)
I don't see this f
On October 27, 2021 4:44:53 PM GMT+02:00, Jakub Jelinek
wrote:
>On Wed, Oct 27, 2021 at 04:29:38PM +0200, Richard Biener wrote:
>> So something like the following below? Note I have to fix
>> simplify_const_unary_operation to not perform the invalid constant
>> folding with (not worrying about
On 27.10.21 17:36, Martin Sebor via Gcc-patches wrote:
On 10/27/21 7:30 AM, Jakub Jelinek wrote:
On Tue, Oct 26, 2021 at 10:22:19PM -0700, sunil.k.pandey via
Gcc-patches wrote:
FAIL: libgomp.c/doacross-1.c (test for excess errors)
I don't see this failure in my logs (or the other one) or any
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, October 26, 2021 3:46 PM
> To: Tamar Christina
> Cc: Tamar Christina via Gcc-patches ; Richard
> Earnshaw ; nd ; Marcus
> Shawcroft
> Subject: Re: [PATCH 2/2]AArch64: Add better costing for vector constants
> and operation
On 10/27/21 7:30 AM, Jakub Jelinek wrote:
On Tue, Oct 26, 2021 at 10:22:19PM -0700, sunil.k.pandey via Gcc-patches wrote:
FAIL: libgomp.c/doacross-1.c (test for excess errors)
I don't see this failure in my logs (or the other one) or any
evidence of the libhomp tests having run. Does the libg
On Wed, Oct 27, 2021 at 04:29:38PM +0200, Richard Biener wrote:
> So something like the following below? Note I have to fix
> simplify_const_unary_operation to not perform the invalid constant
> folding with (not worrying about the exact conversion case - I doubt
> any of the constant folding is
On Wed, 27 Oct 2021, Jakub Jelinek wrote:
> On Wed, Oct 27, 2021 at 03:20:29PM +0200, Richard Biener via Gcc-patches
> wrote:
> > The following honors -frounding-math when converting a FP constant
> > to another FP type.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > I
On Wed, Oct 27, 2021 at 03:20:29PM +0200, Richard Biener via Gcc-patches wrote:
> The following honors -frounding-math when converting a FP constant
> to another FP type.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> I wonder what a good way to test this in a portable way, the
On Tue, Oct 26, 2021 at 10:22:19PM -0700, sunil.k.pandey via Gcc-patches wrote:
> FAIL: libgomp.c/doacross-1.c (test for excess errors)
At least this one is a clear false positive.
int a[256];
...
#pragma omp for schedule(static, 1) ordered (1) nowait
for (i = 0; i < 256; i++)
{
On Sun, Oct 24, 2021 at 10:51 PM Xionghu Luo wrote:
>
> If the second operand of __builtin_shuffle is const vector 0, and with
> specific mask, it can be optimized to vspltisw+xxpermdi instead of lxv.
>
> gcc/ChangeLog:
>
> * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Add
>
Hi,
On Mon, Oct 18 2021, Martin Jambor wrote:
>
[...]
>
>
> This is a follow-up small patch to address Honza's review of my
> previous patch to select saner profile count to base heuristics on.
> Currently the IPA-CP heuristics switch to PGO-mode only if there are
> PGO counters available for any
The following honors -frounding-math when converting a FP constant
to another FP type.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
I wonder what a good way to test this in a portable way, the bugreport
unfortunately didn't contain something executable and I don't see
much -frounding-
Hi,
On Mon, Aug 23 2021, Martin Jambor wrote:
> When profile feedback is available, IPA-CP takes the count of the
> hottest node and then evaluates all call contexts relative to it.
> This means that typically almost no clones for specialized contexts
> are ever created because the maximum is some
This patch series is okay.
Thanks, David
On Thu, Oct 21, 2021 at 11:25 PM Xionghu Luo wrote:
>
> Ping^3, thanks.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579637.html
>
>
> On 2021/10/15 14:28, Xionghu Luo via Gcc-patches wrote:
> > Ping^2, thanks.
> >
> > https://gcc.gnu.org/
On Mon, Oct 18 2021, Martin Jambor wrote:
>
[...]
>
> IPA-CP does not do a reasonable job when it is updating profile counts
> after it has created clones of recursive functions. This patch
> addresses that by:
>
> 1. Only updating counts for special-context clones. When a clone is
> created for
On Sun, Oct 24, 2021 at 11:04 PM Kewen.Lin wrote:
>
> Hi,
>
> As PR102767 shows, the commit r12-3482 exposed one ICE in function
> rs6000_builtin_vectorization_cost. We claims V1TI supports movmisalign
> on rs6000 (See define_expand "movmisalign"), so it return true in
> rs6000_builtin_support_ve
> Hi,
>
> On 2021/9/28 20:09, Richard Biener wrote:
> > On Fri, Sep 24, 2021 at 8:29 AM Xionghu Luo wrote:
> >>
> >> Update the patch to v3, not sure whether you prefer the paste style
> >> and continue to link the previous thread as Segher dislikes this...
> >>
> >>
> >> [PATCH v3] Don't move co
* MAINTAINERS: Clarify the policy WRT the Write After Approval
list.
---
On Tue, 26 Oct 2021, Jeff Law wrote:
> > > It seems like there's been hardly any discussion about this matter
> > > around
> > > the time this stuff was added with commit bddcac9d1c32 ("[contrib] Add
> > > c
This refactors the main loop analysis part in vect_analyze_loop,
re-purposing the existing vect_reanalyze_as_main_loop for this
to reduce code duplication. Failure flow is a bit tricky since
we want to extract info from the analyzed loop but I wanted to
share the destruction part. Thus I add some
On Wed, Oct 27, 2021 at 12:00 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> The problem here is tree-ssa-forwprop.c likes to produce
> &MEM [(void *)_4 + 152B] which is the same as
> _4 p+ 152 which the rest of GCC likes better.
> This implements this transformation back to po
On 27 October 2021 11:59:58 CEST, apinski--- via Gcc-patches
wrote:
>From: Andrew Pinski
>
>The problem here is tree-ssa-forwprop.c likes to produce
>&MEM [(void *)_4 + 152B] which is the same as
>_4 p+ 152 which the rest of GCC likes better.
>This implements this transformation back to pointer
From: Andrew Pinski
The problem here is tree-ssa-forwprop.c likes to produce
&MEM [(void *)_4 + 152B] which is the same as
_4 p+ 152 which the rest of GCC likes better.
This implements this transformation back to pointer plus to
improve better code generation later on.
OK? Bootstrapped and test
This refactors epilogue loop handling in try_vectorize_loop_1 to not
suggest we're analyzing those there by splitting out the transform
phase which then can handle the epilogues.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-10-27 Richard Biener
* tree-vectorizer.c
From: Andrew Pinski
The problem here is tree-ssa-forwprop.c likes to produce
&MEM [(void *)_4 + 152B] which is the same as
_4 p+ 152 which the rest of GCC likes better.
This implements this transformation back to pointer plus to
improve better code generation later on.
OK? Bootstrapped and test
Hi Jakub,
on 2021/10/27 下午3:51, Jakub Jelinek wrote:
> On Tue, Oct 26, 2021 at 11:40:01AM +0800, Kewen.Lin via Gcc-patches wrote:
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.dg/pr102897.c: New test.
>
> The testcase FAILs on i686-linux due to:
> FAIL: gcc.dg/pr102897.c (test for excess errors)
>
From: yfeldblum
The stdout stream is reserved for output intentionally produced by the
application. Assertion failures and other forms of logging must be
emitted to stderr, not to stdout.
It is common for testing and monitoring infrastructure to scan stderr
for errors, such as for assertion fail
On Tue, Oct 26, 2021 at 11:40:01AM +0800, Kewen.Lin via Gcc-patches wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr102897.c: New test.
The testcase FAILs on i686-linux due to:
FAIL: gcc.dg/pr102897.c (test for excess errors)
Excess errors:
.../gcc/gcc/testsuite/gcc.dg/pr102897.c:11:1: war
Hi!
I've found we claim to support non-rectangular loops, but don't actually
support those in Fortran, as can be seen on:
integer i, j
!$omp parallel do collapse(2)
do i = 0, 10
do j = 0, i
end do
end do
end
To support this, the Fortran FE needs to allow the valid forms of
non-rect
Hi!
This patch handles pointer iterators for non-rectangular loops. They are
more limited than integral iterators of non-rectangular loops, in particular
only var-outer, var-outer + a2, a2 + var-outer or var-outer - a2 can appear
in lb or ub where a2 is some integral loop invariant expression, so
Hi!
In C++, if an iterator has or might have (e.g. dependent type) class type we
remember the original init expressions and check those separately for presence
of iterators, because for class iterators we turn those into expressions that
always do contain reference to the current iterator. But th
> On Wed, 27 Oct 2021, Jan Hubicka wrote:
>
> > >
> > > gcc/ChangeLog:
> > >
> > > * tree-ssa-loop-split.c (split_loop): Fix incorrect probability.
> > > (do_split_loop_on_cond): Likewise.
> > > ---
> > > gcc/tree-ssa-loop-split.c | 25 -
> > > 1 file changed, 16 ins
On Wed, 27 Oct 2021, Jan Hubicka wrote:
> >
> > gcc/ChangeLog:
> >
> > * tree-ssa-loop-split.c (split_loop): Fix incorrect probability.
> > (do_split_loop_on_cond): Likewise.
> > ---
> > gcc/tree-ssa-loop-split.c | 25 -
> > 1 file changed, 16 insertions(+), 9 de
> As discussed yesterday, for loop of form
>
> for (...)
> if (cond)
> cond = something();
> else
> something2
>
> Split as
>
Say "if (cond)" has probability p, then individual statements scale as
follows:
loop1:
pfor (...)
p if (true)
1cond = something();
1
Hi Shi-Hua:
> --- a/gcc/config/riscv/riscv.c
> +++ b/gcc/config/riscv/riscv.c
> @@ -1872,7 +1872,7 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
> outer_code, int opno ATTRIBUTE_UN
> case MULT:
>if (float_mode_p)
> *total = tune_param->fp_mul[mode == DFmode];
> - els
>
> gcc/ChangeLog:
>
> * tree-ssa-loop-split.c (split_loop): Fix incorrect probability.
> (do_split_loop_on_cond): Likewise.
> ---
> gcc/tree-ssa-loop-split.c | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/tree-ssa-loop-split.
88 matches
Mail list logo
