> > So in neither of those scenarios testing maxsize=minsize alone makes too
> > much sense to me... What was the original motivation for differentiating
> > between precisely known size?
There is a case that could meet small maxsize. https://godbolt.org/z/489Tf7ssj
typedef unsigned char e_u8;
#d
On Thu, Apr 01, 2021 at 12:52:20AM -0400, Jason Merrill wrote:
> On 1/8/21 2:29 PM, Jakub Jelinek wrote:
> > On Fri, Jan 08, 2021 at 02:22:59PM -0500, Jason Merrill wrote:
> > > I like the idea to use *walk_subtrees to distinguish between walking
> > > syntactic subtrees and walking type-identity s
On 1/8/21 2:29 PM, Jakub Jelinek wrote:
On Fri, Jan 08, 2021 at 02:22:59PM -0500, Jason Merrill wrote:
I like the idea to use *walk_subtrees to distinguish between walking
syntactic subtrees and walking type-identity subtrees. But it should be
more general; how does this look to you?
LGTM, th
On 3/31/21 8:45 PM, David Edelsohn via Gcc-patches wrote:
> This patch is causing new crashes in the testsuite.
>
> ICE in release_body, at graph.c:1863
> ranges offset out of range
Hello.
Should be fixed with 23ce9945d5efa77c96161443f68e03664705ada3.
Martin
>
> Thanks, David
>
Yes OK for trunk and affected branches.
Thanks,
Jerry
On 3/31/21 2:08 PM, Harald Anlauf via Fortran wrote:
Dear all,
the simplification of the TRANSPOSE of a zero-sized array would lead to
an ICE if the result was used in a subsequent simplification of a MATMUL.
The reason was the lack of the
We don't want to print '' in our diagnostics, but
PR analyzer/99771 lists various cases where -fanalyzer does, due to
using the SSA_NAME for a temporary when determining the best tree to
use.
This can happen in two ways:
(a) ...when a better expression than the SSA_NAME could be built, but
findin
Hello,
This patch fixes PR tree-optimization/95176. A new pattern in match.pd was
added to transform "a * (b / a)" --> "b - (b % a)". A new test case was also
added to cover this scenario.
The new pattern interfered with the existing pattern of "X - (X / Y) * Y". In
some cases (such as in fn4(
Hi,
SRA represents parts of aggregates which are arrays accessed with
unknown index as "unscalarizable regions." When there are two such
regions one within another and the outer is only read whereas the
inner is written to, SRA fails to propagate that write information
across assignments. This m
Dear all,
the simplification of the TRANSPOSE of a zero-sized array would lead to
an ICE if the result was used in a subsequent simplification of a MATMUL.
The reason was the lack of the proper initialization of the shape, which
is mpz_t. Use mpz_init_set instead of mpz_set.
Regtested on x86_64-
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and aarch64.
commit 1458059fc1faf6170f2fe45159065f91876307ac
Author: Vladimir N. Makarov
Date: Wed Mar 31 13:26:30 2021 -0400
[PR99781
On Wed, Mar 31, 2021 at 11:21 AM Jan Hubicka wrote:
>
> > On Linux/x86_64,
> >
> > d7145b4bb6c8729a1e782373cb6256c06ed60465 is the first bad commit
> > commit d7145b4bb6c8729a1e782373cb6256c06ed60465
> > Author: Jan Hubicka
> > Date: Wed Mar 31 11:35:29 2021 +0200
> >
> > Small refactoring
Hi,
This fixes a stage 1 bootstrap fail on some Darwin versions when the
bootstrap compiler is clang / libc++ from Xcode.
bootstrapped on x86_64-darwin16, x86_64-linux-gnu
OK for master?
thanks
Iain
It appears that many targets include the map header transitively in
other std headers inc
Hi!
In GCC8/9 we used to optimize this into a bswap, but we no longer do.
Handling byteswapping of pointers is easy, all we need is to allow them,
for the __builtin_bswap* we already use TYPE_PRECISION to determine
the precision and we cast the operand and result to the correct type
if they aren't
Hi!
On Tue, Mar 30, 2021 at 06:49:29PM -0500, Peter Bergner wrote:
> The mma_assemble_input_operand predicate does not accept reg+reg indexed
> addresses which can lead to ICEs. The problem is that the quad_address_p
> function only accepts reg+offset addresses that are valid for quad word
> acce
Per https://gcc.gnu.org/pipermail/gcc/2021-March/235245.html
"In 2012 RMS was added to the GCC Steering Committee web page based
on his role in the GNU Project, though his role as a member of the
Steering Committee has been ambiguous and he was not a member of
the Steering Committee when EGCS beca
This patch is causing new crashes in the testsuite.
ICE in release_body, at graph.c:1863
ranges offset out of range
Thanks, David
On Mar 27, 2021, Jonathan Wakely wrote:
> OK, thanks.
Thanks, I'm finally checking this in.
>> for libstdc++-v3/ChangeLog
>>
>> * testsuite/30_threads/future/members/poll.cc: Use faster
>> after-ready call in the calibration loop.
Thanks for the patch and for having kept me posted on the ra
Richard Biener via Gcc-patches writes:
> On Wed, Mar 31, 2021 at 12:15 PM Richard Sandiford via Gcc-patches
> wrote:
>>
>> create_intersect_range_checks_index tries to create a runtime
>> alias check based on index comparisons. It looks through the
>> access functions for the two DRs to find a S
Hi!
__floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so}
entrypoints for backwards compatibility should mean IBM double double
handling (i.e. IFmode), gcc emits such calls for that format and
form IEEE long double emits *kf* instead.
When gcc is configured without --with-long-double-
> On Linux/x86_64,
>
> d7145b4bb6c8729a1e782373cb6256c06ed60465 is the first bad commit
> commit d7145b4bb6c8729a1e782373cb6256c06ed60465
> Author: Jan Hubicka
> Date: Wed Mar 31 11:35:29 2021 +0200
>
> Small refactoring of cgraph_node::release_body
>
> caused
>
> FAIL: g++.dg/ipa/devirt
On Linux/x86_64,
d7145b4bb6c8729a1e782373cb6256c06ed60465 is the first bad commit
commit d7145b4bb6c8729a1e782373cb6256c06ed60465
Author: Jan Hubicka
Date: Wed Mar 31 11:35:29 2021 +0200
Small refactoring of cgraph_node::release_body
caused
FAIL: g++.dg/ipa/devirt-7.C -std=gnu++14 (inte
On Wed, Mar 31, 2021 at 10:43 AM Jan Hubicka wrote:
>
> > > Reading through the optimization manual it seems that mosvb is fast for
> > > small block no matter if the size is hard wired. In that case you
> > > probably want to check whetehr max_size or expected_size is known to be
> > > small rath
> > Reading through the optimization manual it seems that mosvb is fast for
> > small block no matter if the size is hard wired. In that case you
> > probably want to check whetehr max_size or expected_size is known to be
> > small rather than max_size == min_size and both being small.
> >
> > But
I pushed this.
At first cilkplus.org was broken for weeks, it not months. Now it
redirects to a generic intel.com page. So remove it.
---
htdocs/gcc-4.9/changes.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-4.9/changes.html b/htdocs/gcc-4.9/changes.html
i
On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches wrote:
> diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
> index 9f993c4..c0d9e57 100644
> --- a/gcc/c-family/c-cppbuiltin.c
> +++ b/gcc/c-family/c-cppbuiltin.c
> @@ -1277,8 +1277,10 @@ c_cpp_builtins (cp
Yes, basically, I agreed with Eric.
One of the major reason to intentionally put these testing cases under
c-c++-common
is to fail them by default on the platforms that do not support this feature
yet.
Then the platform maintainer could decide whether to complete this feature on
the
specif
r11-7932 adds a test case for another ancient -Wuninitialized bug
fixed eons ago:
https://gcc.gnu.org/g:31199d95de1304e200554bbf98b2d8a6a7298bec
Martin
On Wed, Mar 31, 2021 at 6:47 AM Jan Hubicka wrote:
>
> > > >
> > > > Patch is OK now. I was wondering about using avx256 for moves of known
> > >
> > > Done. X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is in now. Can
> > > you take a look at the patch for Skylake:
> > >
> > > https://gcc.gnu.org/pi
On Wed, 31 Mar 2021 at 12:08, Richard Biener wrote:
>
> On Mon, Mar 29, 2021 at 1:40 PM Christophe Lyon via Gcc-patches
> wrote:
> >
> > The vectorizer has a very different effect with -mabi=ilp32, and
> > doesn't emit the expecte diagnostic, so this patch expects it only
> > under lp64.
>
> OK (
In this testcase, iterative_hash_template_arg checks
alias_template_specialization_p to determine whether to treat a type as a
dependent alias, and structural_comptypes checks
dependent_alias_template_spec_p. Normally that difference isn't a problem
because canonicalizing template arguments strips
> > >
> > > Patch is OK now. I was wondering about using avx256 for moves of known
> >
> > Done. X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is in now. Can
> > you take a look at the patch for Skylake:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567096.html
>
> I was wondering, i
> >
> > Patch is OK now. I was wondering about using avx256 for moves of known
>
> Done. X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is in now. Can
> you take a look at the patch for Skylake:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567096.html
I was wondering, if CPU preffers rep
On Wed, Mar 31, 2021 at 3:31 PM Alex Coplan via Gcc-patches
wrote:
>
> Hi all,
>
> I'd like to backport the fix for PR97849 to GCC 10. The patch on trunk:
> https://gcc.gnu.org/g:5700973f4a30762b4fc21687bb5f7843e55da2e4
> applies cleanly to the 10 branch.
>
> Bootstrapped and regtested on aarch64-
Hi all,
I'd like to backport the fix for PR97849 to GCC 10. The patch on trunk:
https://gcc.gnu.org/g:5700973f4a30762b4fc21687bb5f7843e55da2e4
applies cleanly to the 10 branch.
Bootstrapped and regtested on aarch64-linux-gnu, no regressions.
OK for GCC 10.3?
Thanks,
Alex
---
gcc/ChangeLog
202
On Wed, Mar 31, 2021 at 1:05 AM Jan Hubicka wrote:
>
> > > It looks like X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is quite obviously
> > > benefical and independent of the rest of changes. I think we will need
> > > to discuss bit more the move ratio and the code size/uop cache polution
> > > issues
> On 3/31/21 1:08 PM, Jan Hubicka wrote:
> > >
> > > 2021-03-15 Jan Hubicka
> > >
> > > * config/i386/i386-options.c (processor_cost_table): Add znver3_cost.
> > > * config/i386/x86-tune-costs.h (znver3_cost): New gobal variable; copy
> > > of znver2_cost.
> >
> > I have backported the
Hi!
The SECTION_LINK_ORDER changes broke powerpc64-linux ELFv1. Seems
that the assembler/linker relies on the symbol mentioned for the
"awo" section to be in the same section as the symbols mentioned in
the relocations in that section (i.e. labels for the patchable area
in this case). That is th
On 3/31/21 1:08 PM, Jan Hubicka wrote:
2021-03-15 Jan Hubicka
* config/i386/i386-options.c (processor_cost_table): Add znver3_cost.
* config/i386/x86-tune-costs.h (znver3_cost): New gobal variable; copy
of znver2_cost.
I have backported the patch to gcc10 branch as
On Wed, Mar 31, 2021 at 12:24 PM Richard Sandiford via Gcc-patches
wrote:
>
> This PR is caused by POLY_INT_CSTs being (necessarily) valid
> in tree-level VECTOR_CSTs but CONST_POLY_INTs not being valid
> in RTL CONST_VECTORs. I can't tell/remember how deliberate
> that was, but I'm guessing not
>
> 2021-03-15 Jan Hubicka
>
> * config/i386/i386-options.c (processor_cost_table): Add znver3_cost.
> * config/i386/x86-tune-costs.h (znver3_cost): New gobal variable; copy
> of znver2_cost.
I have backported the patch to gcc10 branch as
g:aa99212489545c6c970a8f91b3d37ea646
On Wed, Mar 31, 2021 at 12:23 PM Richard Sandiford via Gcc-patches
wrote:
>
> The gimple verifier picked up that an ADDR_EXPR of a MEM_REF was not
> marked TREE_CONSTANT even though the address was in fact invariant.
> This came from folding a &TARGET_MEM_REF with constant operands to
> a &MEM_REF
On Wed, Mar 31, 2021 at 12:15 PM Richard Sandiford via Gcc-patches
wrote:
>
> create_intersect_range_checks_index tries to create a runtime
> alias check based on index comparisons. It looks through the
> access functions for the two DRs to find a SCEV for the loop
> that is being versioned and c
The vectoriser supports peeling for alignment using predication:
we move back to the previous aligned boundary and make the skipped
elements inactive in the first loop iteration. As it happens,
the costs for existing CPUs give an equal cost to aligned and
unaligned accesses, so this feature is rar
This PR is caused by POLY_INT_CSTs being (necessarily) valid
in tree-level VECTOR_CSTs but CONST_POLY_INTs not being valid
in RTL CONST_VECTORs. I can't tell/remember how deliberate
that was, but I'm guessing not very. In particular,
valid_for_const_vector_p was added to guard against symbolic
co
The gimple verifier picked up that an ADDR_EXPR of a MEM_REF was not
marked TREE_CONSTANT even though the address was in fact invariant.
This came from folding a &TARGET_MEM_REF with constant operands to
a &MEM_REF; &TARGET_MEM_REF is never treated as TREE_CONSTANT
but &MEM_REF can be.
Tested on a
create_intersect_range_checks_index tries to create a runtime
alias check based on index comparisons. It looks through the
access functions for the two DRs to find a SCEV for the loop
that is being versioned and converts a DR_STEP-based check
into an index-based check.
However, there isn't any re
On Wed, 31 Mar 2021, Stam Markianos-Wright wrote:
> On 29/03/2021 10:20, Richard Biener wrote:
> > On Fri, 26 Mar 2021, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >>> On Wed, 24 Mar 2021, Stam Markianos-Wright wrote:
> >>>
> Hi all,
>
> This patch resolves bug:
> >
On Mon, Mar 29, 2021 at 1:40 PM Christophe Lyon via Gcc-patches
wrote:
>
> The vectorizer has a very different effect with -mabi=ilp32, and
> doesn't emit the expecte diagnostic, so this patch expects it only
> under lp64.
OK (please also backport as necessary)
> 2021-03-29 Christophe Lyon
>
On 29/03/2021 10:20, Richard Biener wrote:
On Fri, 26 Mar 2021, Richard Sandiford wrote:
Richard Biener writes:
On Wed, 24 Mar 2021, Stam Markianos-Wright wrote:
Hi all,
This patch resolves bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
This is achieved by forcing a re-calculati
Hi,
in the dicussion on PR 99447 there was some confusion about release_body
being used in context where call edges/references survive. This is not
a valid use because it would leave stale pointers to ggc_freed memory
location. By auditing code I did not find any however this patch moves
the callee
Approved by Honza and pushed to master.
Martin
gcc/ChangeLog:
* ipa-modref.c (analyze_ssa_name_flags): Fix coding style
and one negated condition.
---
gcc/ipa-modref.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
Jakub Jelinek writes:
> Hi!
>
> As mentioned in the PR, Uai constraint stands for
> aarch64_sve_scalar_inc_dec_immediate
> while Uav for
> aarch64_sve_addvl_addpl_immediate.
> Both *add3_aarch64 and *add3_poly_1 patterns use
> * return aarch64_output_sve_scalar_inc_dec (operands[2]);
> * retur
[AMD Public Use]
Hi Honza,
> -Original Message-
> From: Jan Hubicka
> Sent: Wednesday, March 31, 2021 1:27 PM
> To: Kumar, Venkataramanan
> Cc: Uros Bizjak ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3
> CPU
>
> [CAUTION: Extern
> > It looks like X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is quite obviously
> > benefical and independent of the rest of changes. I think we will need
> > to discuss bit more the move ratio and the code size/uop cache polution
> > issues - one option would be to use increased limits for -O3 only.
>
> [AMD Public Use]
>
> Hi Honza,
>
> > -Original Message-
> > From: Jan Hubicka
> > Sent: Wednesday, March 31, 2021 1:15 AM
> > To: Kumar, Venkataramanan
> > Cc: Uros Bizjak ; gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3
> > CPU
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 29 March 2021 14:16
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Fix mult autovectorization patterm for iwmmxt (PR
> target/99786)
>
> Similarly to other recently-added autovectoriz
> That is true, but nothing really happened during the 5 months that the tests
> have been failing on many other architectures (except that powerpc and arm
> had skipped those tests). There has been a PR open for all those 5 months.
So what? This is not the first example and I don't see anything
[AMD Public Use]
Hi Honza,
> -Original Message-
> From: Jan Hubicka
> Sent: Wednesday, March 31, 2021 1:15 AM
> To: Kumar, Venkataramanan
> Cc: Uros Bizjak ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3
> CPU
>
> [CAUTION: Externa
On Wed, 31 Mar 2021, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping the PR98860 P1 fix - workaround for PECOFF linkers without
> DWARF5 support - to make -gdwarf-4 the default in such configurations.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567245.html
OK.
Richard.
> Thanks
>
Hi!
I'd like to ping the PR98860 P1 fix - workaround for PECOFF linkers without
DWARF5 support - to make -gdwarf-4 the default in such configurations.
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567245.html
Thanks
Jakub
On Wed, Mar 31, 2021 at 08:01:29AM +0200, Eric Botcazou wrote:
> > It looks like the latter - I've seen no attempt by the original authors to
> > make the feature work on more targets than they cared for.
>
> On the other hand, if you hide the failures, there is essentially zero chance
> that arc
61 matches
Mail list logo
