One of the problems in this PR was that if we had:
vector_type1 array[] = { vector_value1 };
process_init_element would only treat vector_value1 as initialising
a vector_type1 if they had the same TYPE_MAIN_VARIANT. This has
several problems:
(1) It gives confusing error messages if the
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2020/7/27 下午9:10, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>> Hi,
>>>
>>> As Richard S. suggested in the thread:
>>>
>>> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550633.html
>>>
>>> this patch is separated from the one of that thread,
On Fri, Jul 31, 2020 at 1:39 PM Richard Biener
wrote:
>
> On Fri, Jul 31, 2020 at 1:35 PM Richard Biener
> wrote:
> >
> > On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
> > >
> > > When vector comparisons were forced to use vec_cond_expr, we lost a number
> > > of optimizations (my fault
On Fri, Jul 31, 2020 at 1:47 PM Richard Biener
wrote:
>
> On Fri, Jul 31, 2020 at 1:39 PM Richard Biener
> wrote:
> >
> > On Fri, Jul 31, 2020 at 1:35 PM Richard Biener
> > wrote:
> > >
> > > On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
> > > >
> > > > When vector comparisons were forced
On Fri, 31 Jul 2020, Marc Glisse wrote:
On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse writes:
On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse writes:
+/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
+ (simplify
+ (op (vec_cond:s @0 @1 @2)
on 2020/7/31 下午9:01, Richard Biener wrote:
> On Fri, Jul 31, 2020 at 2:37 PM Kewen.Lin wrote:
>>
>> Hi Richards,
>>
>> on 2020/7/31 下午7:20, Richard Biener wrote:
>>> On Fri, Jul 31, 2020 at 1:03 PM Richard Sandiford
>>> wrote:
"Kewen.Lin" writes:
>>> + bool niters_known_p =
On Fri, 31 Jul 2020, Richard Biener wrote:
This adds a ! marker to result expressions that should simplify
(and if not fail the simplification). This can for example be
used like
(simplify
(plus (vec_cond:s @0 @1 @2) @3)
(vec_cond @0 (plus! @1 @3) (plus! @2 @3)))
to make the simplification
Hey.
Motivation of the patch is to allow vectorization of an entire BB.
So far we bail out a sub-BB region when we reach a stmt for which
vect_find_stmt_data_reference returns false. That's replaced with
recoding of groups of the data references.
We can newly vectorize code like:
void foo();
On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse writes:
+/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
+ (simplify
+ (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
+ (with
+ {
+ tree rhs1, rhs2 = NULL;
+ rhs1 = fold_binary (op, type, @1, @3);
+ if
Marc Glisse writes:
> On Fri, 31 Jul 2020, Richard Sandiford wrote:
>
>> Marc Glisse writes:
>>> +/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
>>> + (simplify
>>> + (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
>>> + (with
>>> + {
>>> + tree rhs1, rhs2 = NULL;
>>> +
"Kewen.Lin" writes:
>>> + bool niters_known_p = LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo);
>>> + bool need_iterate_p
>>> + = (!LOOP_VINFO_EPILOGUE_P (loop_vinfo)
>>> + && !vect_known_niters_smaller_than_vf (loop_vinfo));
>>> +
>>> + /* Init min/max, shift and minus cost
On Fri, 31 Jul 2020, Richard Biener wrote:
+/* (v ? w : 0) ? a : b is just (v & w) ? a : b */
+(simplify
+ (vec_cond (vec_cond:s @0 @3 integer_zerop) @1 @2)
+ (vec_cond (bit_and @0 @3) @1 @2))
Does something check automatically that @0 and @3 have compatible types?
@0 should always have a
This adds a ! marker to result expressions that should simplify
(and if not fail the simplification). This can for example be
used like
(simplify
(plus (vec_cond:s @0 @1 @2) @3)
(vec_cond @0 (plus! @1 @3) (plus! @2 @3)))
to make the simplification only apply in case both plus operations
in
On Fri, Jul 31, 2020 at 02:24:08PM +0200, Richard Biener wrote:
> 2020-07-30 Richard Biener
>
> PR debug/96383
> c-family/
> * c-common.h (c_common_finalize_early_debug): Declare.
> * c-common.c: Include debug.h.
> (c_common_finalize_early_debug):
On Fri, Jul 31, 2020 at 2:37 PM Kewen.Lin wrote:
>
> Hi Richards,
>
> on 2020/7/31 下午7:20, Richard Biener wrote:
> > On Fri, Jul 31, 2020 at 1:03 PM Richard Sandiford
> > wrote:
> >>
> >> "Kewen.Lin" writes:
> > + bool niters_known_p = LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo);
> > +
On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse writes:
On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse writes:
+/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
+ (simplify
+ (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
+ (with
+ {
+ tree
On Fri, Jul 31, 2020 at 1:03 PM Richard Sandiford
wrote:
>
> "Kewen.Lin" writes:
> >>> + bool niters_known_p = LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo);
> >>> + bool need_iterate_p
> >>> + = (!LOOP_VINFO_EPILOGUE_P (loop_vinfo)
> >>> + && !vect_known_niters_smaller_than_vf
On Fri, 31 Jul 2020, Richard Biener wrote:
On Fri, Jul 31, 2020 at 1:39 PM Richard Biener
wrote:
On Fri, Jul 31, 2020 at 1:35 PM Richard Biener
wrote:
On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
When vector comparisons were forced to use vec_cond_expr, we lost a number
of
This makes sure to emit full declaration DIEs including
formal parameters for used external functions. This helps
debugging when debug information of the external entity is
not available and also helps external tools cross-checking
ABI compatibility which was the bug reporters use case.
For cc1
On Mon, Jul 27, 2020 at 12:37:17PM +0200, Martin Jambor wrote:
> the email with the patch did not make it to the mailing list because the
> patch was too big, so I'm trying again, this time with the patch
> compressed and attached.
>
> It is actually not exactly the same one but rather one I
On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
>
> When vector comparisons were forced to use vec_cond_expr, we lost a number
> of optimizations (my fault for not adding enough testcases to prevent
> that). This patch tries to unwrap vec_cond_expr a bit so some
> optimizations can still
On Fri, Jul 31, 2020 at 1:39 PM Marc Glisse wrote:
>
> On Fri, 31 Jul 2020, Richard Sandiford wrote:
>
> > Marc Glisse writes:
> >> +/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
> >> + (simplify
> >> + (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
> >> + (with
> >> + {
>
Hi Richards,
on 2020/7/31 下午7:20, Richard Biener wrote:
> On Fri, Jul 31, 2020 at 1:03 PM Richard Sandiford
> wrote:
>>
>> "Kewen.Lin" writes:
> + bool niters_known_p = LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo);
> + bool need_iterate_p
> + = (!LOOP_VINFO_EPILOGUE_P
On Fri, Jul 31, 2020 at 2:50 PM Richard Sandiford
wrote:
>
> Marc Glisse writes:
> > On Fri, 31 Jul 2020, Richard Sandiford wrote:
> >
> >> Marc Glisse writes:
> >>> +/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
> >>> + (simplify
> >>> + (op (vec_cond:s @0 @1 @2) (vec_cond:s
Andrea Corallo writes:
> Hi all,
>
> I'd like to submit the following patch that adds a missing CC reg
> clobber for the FJCVTZS instruction [1].
>
> The patch adds an executing testcase that fails without the clobber.
>
> Bootstrapped on aarch64-linux-gnu, regression ongoing.
>
> Okay for trunk
On 31/07/20 10:19 +0200, Jakub Jelinek wrote:
On Thu, Jul 30, 2020 at 05:59:18PM -0400, Jason Merrill via Gcc-patches wrote:
> Even if we are guaranteed that (what guarantees it?) when __builtin_bit_cast
> is constexpr evaluated no initializer will be omitted if may be value
initialized
> to
On Fri, Jul 31, 2020 at 10:54:46AM +0100, Jonathan Wakely wrote:
> > Does the standard require that somewhere? Because that is not what the
> > compiler implements right now.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78620
Ah, ok.
But does that imply that all CONSTRUCTORs without
Marc Glisse writes:
> +/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
> + (simplify
> + (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
> + (with
> + {
> + tree rhs1, rhs2 = NULL;
> + rhs1 = fold_binary (op, type, @1, @3);
> + if (rhs1 && is_gimple_val (rhs1))
> +
On Fri, Jul 31, 2020 at 1:35 PM Richard Biener
wrote:
>
> On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
> >
> > When vector comparisons were forced to use vec_cond_expr, we lost a number
> > of optimizations (my fault for not adding enough testcases to prevent
> > that). This patch tries to
On Fri, Jul 31, 2020 at 11:41:59AM +0100, Richard Sandiford wrote:
> @@ -10135,11 +10176,7 @@ process_init_element (location_t loc, struct c_expr
> value, bool implicit,
> /* Otherwise, if we have come to a subaggregate,
>and we don't have an element of its type, push into it.
> On 7/31/20 10:47 AM, Jan Hubicka wrote:
> > I think this needs to be restricted to targets that have dl library
>
> Hm, I can't find a dg-require that is used for similar test-cases.
OK, lets get it in and see if it breaks :)
Honza
>
> Martin
on 2020/7/31 下午6:57, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2020/7/27 下午9:10, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi,
As Richard S. suggested in the thread:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550633.html
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc (from_chars_impl): Use
LC_ALL_MASK not LC_ALL.
Tested x86_64-linux and powerpc-aix. Committed to trunk.
commit 4143efc1eed44050201b20c78d0206bc266e30c4
Author: Jonathan Wakely
Date: Fri Jul 31 14:36:56 2020
On Fri, 31 Jul 2020, Marc Glisse wrote:
> On Fri, 31 Jul 2020, Richard Biener wrote:
>
> > This adds a ! marker to result expressions that should simplify
> > (and if not fail the simplification). This can for example be
> > used like
> >
> > (simplify
> > (plus (vec_cond:s @0 @1 @2) @3)
> >
Hi All,
This is my first foray into gfortran for quite a little while so I am going
cautiously on this 'obvious' patch. The comment in the patch and the
ChangLog are clear enough that no further explanation is needed.
Regtests on FC31.x86_64 - OK for trunk?
I am a bit reluctant to get into
Hi Richard,
New version v5 is attached.
v5 main changes against v4:
1) use _stmt instead of _cnt to avoid confusion
2) factor out function vect_rgroup_iv_might_wrap_p
3) use generic scalar_stmt for min/max stmt
Does this look better? Thanks in advance!
BR,
Kewen
-
gcc/ChangeLog:
Sudakshina Das writes:
> Hi
>
> This is my attempt at reviving the old patch
> https://gcc.gnu.org/pipermail/gcc-patches/2019-January/514632.html
>
> I have followed on Kyrill's comment upstream on the link above and I am using
> the recommended option iii that he mentioned.
> "1) Adjust the
On Fri, 31 Jul 2020, Richard Biener wrote:
Or we simply automatically disable those patterns for GENERIC
(though that would probably be unexpected).
Since the definition is not clear, whatever we do will be unexpected at
least in some cases. Disabling it for GENERIC for now seems ok to me,
22:05, tor., 28. jul. 2020 je oseba Qing Zhao
napisala:
>
>
> Richard and Uros,
>
> Could you please review the change that H.J and I rewrote based on your
comments in the previous round of discussion?
>
> This patch is a nice security enhancement for GCC that has been requested
by security
Also reorder some directives so that the dg-options setting -std=gnu++17
comes before the dg-do that requires c++17.
Tested powerpc64le-linux, committed to trunk.
commit 6458742a15f899a7d4e7c57bc649119e8f7aa086
Author: Jonathan Wakely
Date: Fri Jul 31 19:58:02 2020
libstdc++: Ensure
The current dg directives say that the tests can run for any standard
mode, but should fail for C++20. What we want is that they only run for
C++20, and are always expected to fail.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/span/back_assert_neg.cc: Split c++2a
Some tests really are only intended for a specific -std mode, so add a
target selector to make that explicit.
Also reorder the dg-do directives to come after the dg-options ones, so
that the target selector in the dg-do directive is applied after the
dg-options that sets the -std option.
On 7/30/20 1:47 PM, Jason Merrill wrote:
On 7/30/20 12:25 PM, Martin Sebor wrote:
On 7/29/20 2:27 PM, Jason Merrill wrote:
On 7/23/20 3:08 PM, Martin Sebor wrote:
Another test case added to the bug since I posted the patch shows
that the no-warning bit set by the C++ front end is easily lost
Hi,
This patch breaks up the big monolithic tests in gdc.dg test directory.
The majority of tests in runnable are really compilable/ICE tests, and
have have dg-do adjusted where necessary. Tests that had a dependency
on Phobos have also been reproduced and reduced with all imports
stripped from
Hi,
This patch fixes a regression caused by 6ee874f1353.
For 32-bit btr(), BIT_NOT_EXPR was being generated twice, something that
was not seen with the 64-bit variant. Removed the second call to fix
the generated code.
Bootstrapped on x86_64-linux-gnu and checked for regressions on
-m32 and
On Wed, Jul 29, 2020 at 07:21:46PM -0400, Jason Merrill via Gcc-patches wrote:
> On 7/20/20 7:28 PM, Marek Polacek wrote:
> > P1975R0 tweaks the static_cast wording: it says that "An expression e can be
> > explicitly converted to a type T if [...] T is an aggregate type having a
> > first
> >
libstdc++-v3/ChangeLog:
PR libstdc++/96382
* include/bits/stl_iterator.h (reverse_iterator): Friend
declaration should not depend on __cplusplus.
Tested x86_64-linux, committed to trunk.
commit 8abab28bb5c0cd80063518d47494cb6078767b89
Author: Jonathan Wakely
Date:
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_istream/ignore/char/94749.cc: Use 0
instead of nullptr.
* testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc:
Likewise.
Tested powerpc64le-linux, committed to trunk.
commit
Local classes have no linkage so cannot be used as template arguments in
C++98.
libstdc++-v3/ChangeLog:
*
testsuite/20_util/specialized_algorithms/uninitialized_fill_n/sizes.cc:
Move struct to namespace scope.
Tested powerpc64le-linux, committed to trunk.
commit
Sorry for the slow reply.
luoxhu writes:
> Hi Richard,
>
> This is the updated version that could pass all regression test on
> Power9-LE.
> Just need another "maybe_lt (GET_MODE_SIZE (new_mode), access_size)"
> before generating shift for store_info->const_rhs to ensure correct
> constant is
libstdc++-v3/ChangeLog:
* testsuite/20_util/is_aggregate/value.cc: Adjust for changes to
definition of aggregates in C++20.
* testsuite/20_util/optional/requirements.cc: Adjust for
defaulted comparisons in C++20.
Tested x86_64-linux, committed to trunk.
commit
Also add an effective target to clarify it should only run for C++17 and
later.
libstdc++-v3/ChangeLog:
* testsuite/20_util/time_point_cast/rounding.cc: Remove
duplicate dg-do directive and add c++17 effective target.
Tested x86_64-linux, committed to trunk.
commit
libstdc++-v3/ChangeLog:
* testsuite/20_util/tuple/78939.cc: Suppress warnings about
deprecation of volatile-qualified structured bindings in C++20.
* testsuite/20_util/variable_templates_for_traits.cc: Likewise
for deprecation of is_pod in C++20
Tested
This was probably copied from a std::filesystem test and the -std option
wasn't removed.
libstdc++-v3/ChangeLog:
* testsuite/experimental/filesystem/filesystem_error/cons.cc:
Remove -std=gnu++17 option.
Tested x86_64-linux, committed to trunk.
commit
On 7/16/20 12:02 PM, Roger Sayle wrote:
>
> Many thanks to Richard Biener for approving the midde-end
> patch that cleared the way for this one. This nvptx patch
> defines the target hook TARGET_TRULY_NOOP_TRUNCATION to
> false, indicating that integer truncations require explicit
>
On Thu, Jul 30, 2020 at 11:55:19AM +0200, Richard Biener wrote:
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> OK for trunk and backports?
I'd go with it for trunk and 10.2.1 now and consider further backports
later. Maybe even defer the 10.2.1 backport for two weeks.
I
Add effective-target keywords to tests that would fail for certain
standard modes without the -std=gnu++NN option.
libstdc++-v3/ChangeLog:
* testsuite/18_support/set_terminate.cc: Require C++11 or
higher.
* testsuite/28_regex/simple_c++11.cc: Likewise.
*
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/numbers/float128.cc: Check
__STRICT_ANSI__ before using __float128.
*
testsuite/std/concepts/concepts.lang/concept.arithmetic/floating_point.cc:
Likewise.
Tested powerpc64le-linux, committed to trunk.
commit
On July 31, 2020 8:44:49 PM GMT+02:00, David Edelsohn wrote:
>On Thu, Jul 30, 2020 at 11:55:19AM +0200, Richard Biener wrote:
>
>> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>>
>> OK for trunk and backports?
>
>I'd go with it for trunk and 10.2.1 now and consider further backports
On Fri, 31 Jul 2020, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
> OK to instal?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Pushed.
Gerald
---
htdocs/readings.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 2488ca9d..f417ed6d 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -598,11 +598,11 @@ names.
-
Pushed.
(Something was off with the ChangeLog detection I'm afraid. I first got
an error message and what ended up in the commit didn't look completely
consistent.)
Gerald
2020-07-31 Gerald Pfeifer
* doc/xml/manual/status_cxx2017.xml: ParallelSTL is now part
of oneAPI
On 31/07/20 23:23 +0200, Gerald Pfeifer wrote:
Pushed.
(Something was off with the ChangeLog detection I'm afraid. I first got
an error message and what ended up in the commit didn't look completely
consistent.)
I noticed the other day that this link was redirecting, but I don't
think we
On 7/31/20 3:52 AM, Jakub Jelinek wrote:
On Wed, Jul 29, 2020 at 03:30:07PM -0400, Jason Merrill via Gcc-patches wrote:
On 7/14/20 4:50 AM, Jakub Jelinek wrote:
For C++11 we already emit an error if a constexpr function doesn't contain
a return statement, because in C++11 that is the only
On 7/31/20 6:06 AM, Jakub Jelinek wrote:
On Fri, Jul 31, 2020 at 10:54:46AM +0100, Jonathan Wakely wrote:
Does the standard require that somewhere? Because that is not what the
compiler implements right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78620
But does that imply that all
On 17/07/20 12:36 pm, Jonathan Wakely wrote:
On 16/12/19 08:18 +0100, François Dumont wrote:
A small refresh on this patch now tested also for versioned namespace
which require printers.py to be updated.
Note that this simplification works also for normal mode so I can
apply it
On 7/31/20 2:07 AM, Richard Biener wrote:
On Thu, Jul 30, 2020 at 8:55 PM Patrick Palka via Gcc-patches
wrote:
On Thu, 30 Jul 2020, Jason Merrill wrote:
On 7/30/20 9:49 AM, Patrick Palka wrote:
On Thu, 30 Jul 2020, Jason Merrill wrote:
On 7/21/20 3:07 PM, Patrick Palka wrote:
In the
On 31/07/20 23:03 +0200, François Dumont via Libstdc++ wrote:
On 17/07/20 12:36 pm, Jonathan Wakely wrote:
On 16/12/19 08:18 +0100, François Dumont wrote:
diff --git
a/libstdc++-v3/testsuite/23_containers/vector/bool/allocator/swap.cc
Hi Jonathan,
On Wed, Jul 22 2020, Jonathan Wakely via Gcc-patches wrote:
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_iterator.h (reverse_iterator): Constrain
> converting constructor and converting assignment operator.
> Access source iterator's data member directly instead
On Thu, 30 Jul 2020, Andrew Waterman wrote:
> IIRC, I didn't use this approach originally because I wanted to avoid
> the additional dynamic instruction. But I agree that code size is the
> more important metric for users of this feature. LGTM.
Applied now, thanks for your review.
Maciej
The folders for these functions (and some others) call c_getsr
which relies on string_constant to return the representation of
constant strings. Because the function doesn't handle constants
of other types, including aggregates, memcmp or memchr calls
involving those are not folded when they
Committed.
This test fails for mmix for (almost) the same reason it would fail
for e.g. mipsel-elf: the end-condition of the loop tests against a
register set to a constant, and that register is (one of) the
"unexpected IV" moved out of the loop "without introducing a new
temporary register" and
On Thu, Jul 30, 2020 at 8:55 PM Patrick Palka via Gcc-patches
wrote:
>
> On Thu, 30 Jul 2020, Jason Merrill wrote:
>
> > On 7/30/20 9:49 AM, Patrick Palka wrote:
> > > On Thu, 30 Jul 2020, Jason Merrill wrote:
> > >
> > > > On 7/21/20 3:07 PM, Patrick Palka wrote:
> > > > > In the testcase from
gcc/ChangeLog:
* config/csky/csky_opts.h (float_abi_type): New.
* config/csky/csky.h (TARGET_SOFT_FLOAT): New.
(TARGET_HARD_FLOAT): New.
(TARGET_HARD_FLOAT_ABI): New.
(OPTION_DEFAULT_SPECS): Use mfloat-abi.
* config/csky/csky.opt (mfloat-abi): New.
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, July 28, 2020 1:33 AM
> To: Zhongyunde
> Cc: gcc-patches@gcc.gnu.org; Yangfei (Felix)
> Subject: Re: [PATCH PR95696] regrename creates overlapping register
> allocations for vliw
>
>
This makes the special case of constant evaluated LHS for a
short-circuiting or/and explicit rather than doing range
merging and eventually exposing a side-effect that shouldn't be
evaluated.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
2020-07-31 Richard Biener
PR
On Thu, Jul 30, 2020 at 05:59:18PM -0400, Jason Merrill via Gcc-patches wrote:
> > Even if we are guaranteed that (what guarantees it?) when __builtin_bit_cast
> > is constexpr evaluated no initializer will be omitted if may be value
> > initialized
> > to something other than all zeros,
>
>
Hi all,
I'd like to submit the following patch that adds a missing CC reg
clobber for the FJCVTZS instruction [1].
The patch adds an executing testcase that fails without the clobber.
Bootstrapped on aarch64-linux-gnu, regression ongoing.
Okay for trunk when finished testing?
Andrea
[1]
Hi Tamar
> -Original Message-
> From: Tamar Christina
> Sent: 30 July 2020 09:28
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
>
> Subject: [PATCH] AArch64: Fix hwasan failure in readline.
>
> Hi All,
>
> My
On Wed, Jul 29, 2020 at 03:30:07PM -0400, Jason Merrill via Gcc-patches wrote:
> On 7/14/20 4:50 AM, Jakub Jelinek wrote:
> > For C++11 we already emit an error if a constexpr function doesn't contain
> > a return statement, because in C++11 that is the only thing it needs to
> > contain, but for
On 6/3/20 8:28 AM, Martin Liška wrote:
On 6/2/20 3:19 PM, Martin Liška wrote:
I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
Please take a look at the attached patch. I also added a test-case that
stresses that. I've just finished LTO PGO bootstrap of the GCC.
Ready
Hi Tamar,
> -Original Message-
> From: Tamar Christina
> Sent: 31 July 2020 09:07
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Richard Sandiford
>
> Subject: RE: [PATCH] AArch64: Fix hwasan failure in readline.
>
> Hi Kyrill,
>
> >
Hi Kyrill,
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Friday, July 31, 2020 8:47 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Richard Sandiford
>
> Subject: RE: [PATCH] AArch64: Fix hwasan failure in readline.
>
> Hi
> On 6/3/20 8:28 AM, Martin Liška wrote:
> > On 6/2/20 3:19 PM, Martin Liška wrote:
> > > I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
> > > Please take a look at the attached patch. I also added a test-case that
> > > stresses that. I've just finished LTO PGO bootstrap
On 7/31/20 10:47 AM, Jan Hubicka wrote:
I think this needs to be restricted to targets that have dl library
Hm, I can't find a dg-require that is used for similar test-cases.
Martin
xiezhiheng writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Friday, July 17, 2020 5:04 PM
>> To: xiezhiheng
>> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions
>>
Thanks for the update, looks good. Could you post a changelog too
so that I can use it when committing?
The changelog was the only reason I didn't just push the patch,
but FWIW, a couple of very minor things…
Zhongyunde writes:
> diff --git a/gcc/regrename.c b/gcc/regrename.c
> old mode 100644
> We noticed that when analyzing LTRANS memory peak that happens right
> after the start:
> https://gist.github.com/marxin/223890df4d8d8e490b6b2918b77dacad
>
> In case of chrome, we have symtab->order == 200M, so we allocate
> 16B * 200M = 3.2GB.
200M is very large number even for overall number
88 matches
Mail list logo
