Hi.
It's a move of code outside of seltests that are not enabled with
--enable-checking=release.
@Stam: Can you please take a look at observer warnings related to your
code:
/home/marxin/Programming/gcc2/gcc/config/arm/arm.c: In function ‘const char*
arm_gen_far_branch(rtx_def**, int, const ch
Hi!
Some of the following testcases ICE, because one of the cpp_get_token
calls in builtin_has_include reads the CPP_EOF token but the caller isn't
aware that CPP_EOF has been reached and will do another cpp_get_token.
get_token_no_padding is something that is use by the
has_attribute/has_builtin
Hi!
The standard says http://eel.is/c++draft/cpp.cond#7.sentence-2 that
__has_include can't appear at arbitrary places in the source. As we have
not recognized __has_include* outside of preprocessing directives in the
past, accepting it there now would be a regression. The patch does still
allow
Hi!
My change
* typeck2.c (store_init_value): Don't call cp_fully_fold_init on
initializers of automatic non-constexpr variables in constexpr
functions.
- value = cp_fully_fold_init (value);
+ /* Don't fold initializers of automatic variables in constexpr functions,
+ that might fold away so
On Mon, 3 Feb 2020 at 14:56, Prathamesh Kulkarni
wrote:
>
> On Mon, 3 Feb 2020 at 14:41, Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 30 Jan 2020 at 19:17, Richard Biener
> > wrote:
> > >
> > > On Thu, Jan 30, 2020 at 11:49 AM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Wed, 29 Jan 202
On Tue, Feb 4, 2020 at 1:44 AM Martin Sebor wrote:
>
> PR 93519 reports a false positive -Wrestrict issued for an inlined call
> to strcpy that carefully guards against self-copying. This is caused
> by the caller's arguments substituted into the call during inlining and
> before dead code elimin
Hi!
As mentioned in the PR, the CLOBBERs in vzeroupper are added there even for
registers that aren't ever live in the function before and break the
prologue/epilogue expansion with ms ABI (normal ABIs are fine, as they
consider all [xyz]mm registers call clobbered, but the ms ABI considers
xmm0-1
On Tue, Feb 4, 2020 at 10:39 AM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, the CLOBBERs in vzeroupper are added there even for
> registers that aren't ever live in the function before and break the
> prologue/epilogue expansion with ms ABI (normal ABIs are fine, as they
> consider al
Although GCC should understand the limited range of clz/ctz/cls results,
Combine sometimes behaves oddly and duplicates ctz to remove a
sign extension. Avoid this by adding an explicit AND with 127 in the
patterns. Deepsjeng performance improves by ~0.6%.
Bootstrap OK.
ChangeLog:
2020-02-03 Wil
Hi Andrew,
> You might want to add a testcase that the autovectorizers too.
>
> Currently we get also:
>
> ldr q0, [x0]
> addv b0, v0.16b
> umov w0, v0.b[0]
> ret
My patch doesn't change this case on purpose - there are also many intrinsics
which generate re
On 03/02/2020 18:09, Michael Matz wrote:
But suggesting that using the subject line for tagging is recommended can
lead to subjects like
[PATCH][GCC][Foo][component] Fix foo component bootstrap failure
in an e-mail directed to gcc-patches@gcc.gnu.org (from somewhen last year,
where Foo/foo wa
On 03/02/20 21:07 -0500, Patrick Palka wrote:
These changes are needed for some of the tests in the constrained algorithm
patch, because they use move_iterator with an uncopyable output_iterator. The
other changes described in the paper are already applied, it seems.
libstdc++-v3/ChangeLog:
ping (updated comment to use the same wording as the AArch64 version on trunk)
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration
on practically any target. So set it correctly to 1 on Arm.
As a result w
ping
The current pressure scheduler doesn't appear to correctly track register
pressure and avoid creating unnecessary spills when register pressure is high.
As a result disabling the early scheduler improves integer performance
considerably and reduces codesize as a bonus. Since scheduling floati
Hi Kyrill,
> Hmm, I'm not too confident on that. I'd support such a change for the
> generic arm_cortex_tune, definitely, and the Armv8-a based ones, but I
> don't think the argument is as strong for Cortex-A7, Cortex-A8, Cortex-A9.
>
> So let's make the change for the Armv8-A-based cores now. I
Any further comments? Note GCC doesn't support S/UMULLS either since it is
equally
useless. It's no surprise that Thumb-2 removed support for flag-setting 64-bit
multiplies,
while AArch64 didn't add flag-setting multiplies. So there is no argument that
these
instructions are in any way useful to
On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> If it works OK, I'd rather see this functionality implemented as an
> epilogue_completed guarded splitter. In the .md files, there are
> already cases where we split at this point, and where it is assumed
> that allocated registers won'
On Tue, Feb 4, 2020 at 12:05 PM Jakub Jelinek wrote:
>
> On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> > If it works OK, I'd rather see this functionality implemented as an
> > epilogue_completed guarded splitter. In the .md files, there are
> > already cases where we split at thi
On Tue, Feb 4, 2020 at 12:13 PM Uros Bizjak wrote:
>
> On Tue, Feb 4, 2020 at 12:05 PM Jakub Jelinek wrote:
> >
> > On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> > > If it works OK, I'd rather see this functionality implemented as an
> > > epilogue_completed guarded splitter. In
On 1/31/20 1:45 PM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
On 1/30/20 10:01 AM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
On 1/29/20 12:42 PM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
Hi all,
This fixes:
https://gcc.gnu.org/bugzilla/show_bug.
Hi!
On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> I guess that Comment #9 patch form the PR should be trivially correct,
> but althouhg it looks obvious, I don't want to propose the patch since
> I have no means of testing it.
I don't have means of testing it either.
https://docs
Wilco Dijkstra writes:
> Although GCC should understand the limited range of clz/ctz/cls results,
> Combine sometimes behaves oddly and duplicates ctz to remove a
> sign extension. Avoid this by adding an explicit AND with 127 in the
> patterns. Deepsjeng performance improves by ~0.6%.
Could you
Stam Markianos-Wright writes:
> On 1/31/20 1:45 PM, Richard Sandiford wrote:
>> Stam Markianos-Wright writes:
>>> On 1/30/20 10:01 AM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
> On 1/29/20 12:42 PM, Richard Sandiford wrote:
>> Stam Markianos-Wright writes:
>>> Hi
Uros Bizjak writes:
> On Tue, Feb 4, 2020 at 12:13 PM Uros Bizjak wrote:
>>
>> On Tue, Feb 4, 2020 at 12:05 PM Jakub Jelinek wrote:
>> >
>> > On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
>> > > If it works OK, I'd rather see this functionality implemented as an
>> > > epilogue_co
On 2/3/20 8:47 PM, JunMa wrote:
在 2020/2/3 下午8:53, Nathan Sidwell 写道:
sorry, I should have realized you still needed this bit. This too is
stripping a reference access, right? I.e. TYPE_REF_P (TREE_TYPE
(resume_call)) is true. You should that as the condition too.
you mean REFERENCE_REF_
On 2/4/20 3:52 AM, Jakub Jelinek wrote:
Hi!
The standard says http://eel.is/c++draft/cpp.cond#7.sentence-2 that
__has_include can't appear at arbitrary places in the source. As we have
not recognized __has_include* outside of preprocessing directives in the
past, accepting it there now would be
On 2/4/20 3:46 AM, Jakub Jelinek wrote:
Hi!
Some of the following testcases ICE, because one of the cpp_get_token
calls in builtin_has_include reads the CPP_EOF token but the caller isn't
aware that CPP_EOF has been reached and will do another cpp_get_token.
get_token_no_padding is something tha
Hi
When testing coroutines with lambda function, I find we copy each captured
variable to frame. However, according to gimplify pass, for each declaration
that is an alias for another expression(DECL_VALUE_EXPR), we can
substitute them directly.
Since lambda captured variables is one of this kind
On Tue, Feb 4, 2020 at 1:06 PM Richard Sandiford
wrote:
>
> Uros Bizjak writes:
> > On Tue, Feb 4, 2020 at 12:13 PM Uros Bizjak wrote:
> >>
> >> On Tue, Feb 4, 2020 at 12:05 PM Jakub Jelinek wrote:
> >> >
> >> > On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> >> > > If it works O
On Tue, Feb 04, 2020 at 12:24:10PM +0100, Uros Bizjak wrote:
> > A && is missing in the split condition to inherit TARGET_AVX.
>
> Also, you don't need to emit "#" in output template. This is just for
> extra safety, we can live without. Please see e.g. "*tzcnt_1".
I was worried that -fipa-ra the
On Tue, Feb 4, 2020 at 1:30 PM Jakub Jelinek wrote:
>
> On Tue, Feb 04, 2020 at 12:24:10PM +0100, Uros Bizjak wrote:
> > > A && is missing in the split condition to inherit TARGET_AVX.
> >
> > Also, you don't need to emit "#" in output template. This is just for
> > extra safety, we can live witho
Hi.
The patch addresses https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401#c9
where we currently support mechanism for cross compilation:
GCC manual:
10.5 Data File Relocation to Support Cross-Profiling
That's very much the same what Honza needs for Firefox, where profile-gen
run happens in a di
On Tue, Feb 04, 2020 at 01:38:51PM +0100, Uros Bizjak wrote:
> As Richard advised, let's put this safety stuff back. Usually, in
> i386.md, these kind of splitters are implemented as two patterns, one
> (define_insn_and_split) having "#", and the other (define_insn) with a
> real insn. My opinion i
On Tue, Feb 4, 2020 at 2:13 PM Jakub Jelinek wrote:
>
> On Tue, Feb 04, 2020 at 01:38:51PM +0100, Uros Bizjak wrote:
> > As Richard advised, let's put this safety stuff back. Usually, in
> > i386.md, these kind of splitters are implemented as two patterns, one
> > (define_insn_and_split) having "#
The requirements for this function are only that the deleter is
swappable, but we incorrectly require that the element type is complete
and that the deleter can be swapped using std::swap (which requires it
to be move cosntructible and move assignable).
The fix is to add __uniq_ptr_impl::swap whic
Hi.
The patch is about enhancement of the documentation, where
we do not support ASLR for Precompiled Headers.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2020-02-04 Martin Liska
PR c++/92717
* doc/invoke.texi: Document that one should
not combine ASLR and -fpch.
On Mon, 3 Feb 2020 at 18:20, Mihail Ionescu wrote:
>
> Hi,
>
> We noticed that the profile for armv8.1-m.main was not set in arm-cpus.in
> , which led to TARGET_ARM_ARCH_PROFILE and _ARM_ARCH_PROFILE not being
> defined properly.
>
>
>
> gcc/ChangeLog:
>
> 2020-02-03 Mihail Ionescu
>
>
On Tue, Feb 4, 2020 at 2:45 PM Martin Liška wrote:
>
> Hi.
>
> The patch is about enhancement of the documentation, where
> we do not support ASLR for Precompiled Headers.
>
> Ready for trunk?
I think we support ASLR just fine?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-02-04 Martin Liska
On 2/4/20 2:55 PM, Richard Biener wrote:
On Tue, Feb 4, 2020 at 2:45 PM Martin Liška wrote:
Hi.
The patch is about enhancement of the documentation, where
we do not support ASLR for Precompiled Headers.
Ready for trunk?
I think we support ASLR just fine?
There's issue where somebody conf
On Tue, Feb 04, 2020 at 02:55:31PM +0100, Richard Biener wrote:
> On Tue, Feb 4, 2020 at 2:45 PM Martin Liška wrote:
> >
> > Hi.
> >
> > The patch is about enhancement of the documentation, where
> > we do not support ASLR for Precompiled Headers.
> >
> > Ready for trunk?
>
> I think we support A
On Sat, Feb 1, 2020 at 1:04 AM Uecker, Martin
wrote:
>
>
>
> Hi Richard and Joseph,
>
> for discussion: here is my simple patch
> for __builtin_escape/__builtin_bless.
>
> Maybe it does something stupid.
I'd use an internal function once the frontend inserts the calls,
we shouldn't expose those t
The macro that is defined is _GLIBCXX_NOT_FN_CALL_OP but the macro that
was named in the #undef directive was _GLIBCXX_NOT_FN_CALL. This fixes
the #undef.
* include/std/functional (_GLIBCXX_NOT_FN_CALL_OP): Un-define after
use.
Tested powerpc64le-linux. Committed to master.
commi
On Mon, Feb 3, 2020 at 12:37 PM Prathamesh Kulkarni
wrote:
>
> On Thu, 30 Jan 2020 at 19:10, Richard Biener
> wrote:
> >
> > On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Tue, 28 Jan 2020 at 17:17, Richard Biener
> > > wrote:
> > > >
> > > > On Fri, Jan 24, 202
This adds back a folding that worked in GCC 4.5 times by amending
the pattern that handles other cases of address vs. SSA name
comparisons.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
2020-02-04 Richard Biener
PR tree-optimization/93538
* match.pd (a
Hi Richard,
> Could you go into more detail about what the before and after code
> looks like, and what combine is doing? Like you say, this sounds
> like a target-independent thing on face value.
It is indeed, but it seems specific to instructions where we have range
information which allows it
Am Dienstag, den 04.02.2020, 15:01 +0100 schrieb Richard Biener:
> On Sat, Feb 1, 2020 at 1:04 AM Uecker, Martin
> wrote:
> >
> >
> >
> > Hi Richard and Joseph,
> >
> > for discussion: here is my simple patch
> > for __builtin_escape/__builtin_bless.
> >
> > Maybe it does something stupid.
On Mon, Feb 3, 2020 at 7:45 PM Jeff Law wrote:
>
> On Fri, 2020-01-31 at 12:04 -0700, Martin Sebor wrote:
> > Attached is a reworked patch since the first one didn't go far
> > enough to solve the major problems. The new solution relies on
> > get_range_strlen_dynamic the same way as the sprintf
On Mon, Feb 03, 2020 at 06:10:49PM -0800, H.J. Lu wrote:
> On Mon, Feb 3, 2020 at 4:02 PM H.J. Lu wrote:
> >
> > On Mon, Feb 3, 2020 at 10:35 AM H.J. Lu wrote:
> > >
> > > Define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY to make sure that the
> > > ENDBR are emitted before the patch area. When -
On 2/4/20 2:59 PM, Jakub Jelinek wrote:
On Tue, Feb 04, 2020 at 02:55:31PM +0100, Richard Biener wrote:
On Tue, Feb 4, 2020 at 2:45 PM Martin Liška wrote:
Hi.
The patch is about enhancement of the documentation, where
we do not support ASLR for Precompiled Headers.
Ready for trunk?
I thin
Hi.
The patch is about not loading of LTO bodies for symbols
that are only aliases.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/lto/ChangeLog:
2020-02-04 Martin Liska
PR lto/93489
* lto-dump.c (dump_list_
> Hi.
>
> The patch is about not loading of LTO bodies for symbols
> that are only aliases.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/lto/ChangeLog:
>
> 2020-02-04 Martin Liska
>
> PR lto/93489
>
On 2/4/20 2:34 AM, Richard Biener wrote:
On Tue, Feb 4, 2020 at 1:44 AM Martin Sebor wrote:
PR 93519 reports a false positive -Wrestrict issued for an inlined call
to strcpy that carefully guards against self-copying. This is caused
by the caller's arguments substituted into the call during i
DejaGNU uses in lib/target.exp's
proc default_target_compile {source destfile type options}
uses the following.
When running locally, $source is simply used
as argument. However, when run remotely, it is tried to be uploaded
on the remote host – and otherwise skipped. That's fine if the
argume
Fix some failures on xstormy16-elf:
gcc.dg/analyzer/data-model-1.c (test for warnings, line 595)
gcc.dg/analyzer/data-model-1.c (test for warnings, line 642)
gcc.dg/analyzer/data-model-1.c (test for warnings, line 690)
gcc.dg/analyzer/data-model-1.c (test for warnings, line 738)
due to
On Tue, 2020-02-04 at 10:34 +0100, Richard Biener wrote:
> On Tue, Feb 4, 2020 at 1:44 AM Martin Sebor wrote:
> > PR 93519 reports a false positive -Wrestrict issued for an inlined call
> > to strcpy that carefully guards against self-copying. This is caused
> > by the caller's arguments substitu
On 2/4/20 12:02 PM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
On 1/31/20 1:45 PM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
On 1/30/20 10:01 AM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
On 1/29/20 12:42 PM, Richard Sandiford wrote:
Stam Markianos
> My only worry would be asking for the length early in the RTL pipeline
> may not be as accurate, but it's supposed to work, so if you're
> comfortable with the end results, then OK.
>
Indeed, the length is not accurate, but the results seem slightly
better than using COST_RTX. Using INSN_COSTS se
Hi!
On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt wrote:
> The current built-in support in the rs6000 back end requires at least
> a master's degree in spelunking to comprehend. It's full of cruft,
> redundancy, and unused bits of code, and long overdue for a
> replacement. This is the
Richard Sandiford writes:
> [...]
>> I'm not sure given the issues you've introduced if I could actually
>> fill out the matrix of answers without more underlying information.
>> ie, when can we get symbols without source level decls,
>> anchors+interposition issues, etc.
>
> OK. In that case,
Hi!
On Mon, Feb 03, 2020 at 08:26:02PM -0600, Bill Schmidt wrote:
> Includes header documentation and initial set of include directives.
Please use full sentences in commit messages.
> +/* This program generates built-in function initialization and
> + recognition code for Power targets, based
On February 4, 2020 5:30:42 PM GMT+01:00, Jeff Law wrote:
>On Tue, 2020-02-04 at 10:34 +0100, Richard Biener wrote:
>> On Tue, Feb 4, 2020 at 1:44 AM Martin Sebor wrote:
>> > PR 93519 reports a false positive -Wrestrict issued for an inlined
>call
>> > to strcpy that carefully guards against self
Here, we were going down the wrong path in perform_member_init because of
the incorrect parens around the mem-initializer for the array. And then
cxx_eval_vec_init_1 didn't know what to do with a CONSTRUCTOR as the
initializer. The latter issue was a straightforward fix, but I also wanted
to fix
On 2/4/20 12:15 PM, Richard Biener wrote:
On February 4, 2020 5:30:42 PM GMT+01:00, Jeff Law wrote:
On Tue, 2020-02-04 at 10:34 +0100, Richard Biener wrote:
On Tue, Feb 4, 2020 at 1:44 AM Martin Sebor wrote:
PR 93519 reports a false positive -Wrestrict issued for an inlined
call
to strcpy
Committed.
Segher
---
htdocs/git.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/git.html b/htdocs/git.html
index 66d68eb..7fd22a9 100644
--- a/htdocs/git.html
+++ b/htdocs/git.html
@@ -44,7 +44,7 @@ through, you can replace git:// with
https://.
If there is a
On 2/4/20 12:27 PM, Segher Boessenkool wrote:
Hi!
On Mon, Feb 03, 2020 at 08:26:02PM -0600, Bill Schmidt wrote:
Includes header documentation and initial set of include directives.
Please use full sentences in commit messages.
OK.
+/* This program generates built-in function initializat
On Tue, 4 Feb 2020, Jonathan Wakely wrote:
> On 03/02/20 21:07 -0500, Patrick Palka wrote:
> > These changes are needed for some of the tests in the constrained algorithm
> > patch, because they use move_iterator with an uncopyable output_iterator.
> > The
> > other changes described in the paper
On Tue, 2020-02-04 at 13:08 -0700, Martin Sebor wrote:
> On 2/4/20 12:15 PM, Richard Biener wrote:
> > On February 4, 2020 5:30:42 PM GMT+01:00, Jeff Law wrote:
> > > On Tue, 2020-02-04 at 10:34 +0100, Richard Biener wrote:
> > > > On Tue, Feb 4, 2020 at 1:44 AM Martin Sebor wrote:
> > > > > PR 9
On 04/02/20 16:23 -0500, Patrick Palka wrote:
On Tue, 4 Feb 2020, Jonathan Wakely wrote:
On 03/02/20 21:07 -0500, Patrick Palka wrote:
> These changes are needed for some of the tests in the constrained algorithm
> patch, because they use move_iterator with an uncopyable output_iterator.
> The
On 2/4/20 2:31 PM, Jeff Law wrote:
On Tue, 2020-02-04 at 13:08 -0700, Martin Sebor wrote:
On 2/4/20 12:15 PM, Richard Biener wrote:
On February 4, 2020 5:30:42 PM GMT+01:00, Jeff Law wrote:
On Tue, 2020-02-04 at 10:34 +0100, Richard Biener wrote:
On Tue, Feb 4, 2020 at 1:44 AM Martin Sebor
Value-initialization is importantly different from {}-initialization for
this testcase, where the former calls the deleted S constructor and the
latter initializes S happily.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/90951
* constexpr.c (cxx_eval_array_reference): {}-i
On Tue, Feb 04, 2020 at 03:10:32PM -0600, Bill Schmidt wrote:
> >I really don't think using the new acronym "bif" helps; built-in
> >functions already are often called "builtins" (or "intrinsics", which is
> >problematic itself).
>
> Until we manage to replace the old methods, we already have
> r
On 2/4/20 4:36 PM, Segher Boessenkool wrote:
On Tue, Feb 04, 2020 at 03:10:32PM -0600, Bill Schmidt wrote:
I really don't think using the new acronym "bif" helps; built-in
functions already are often called "builtins" (or "intrinsics", which is
problematic itself).
Until we manage to replace th
Here, push_tinst_level refused to push into the scope of Foo::Foo
because it was triggered from the ill-formed function fun. But we didn't
check the return value and tried to pop the un-pushed level.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93551
* constraint.cc (sat
On Tue, Feb 04, 2020 at 04:44:04PM -0600, Bill Schmidt wrote:
> >"ldv" certainly is shorter and nicer in principle, but it is a bit
> >cryptic. As I said, it's probably not too hard to get used to it; and
> >maybe a better name will present itself?
> Maybe ldvec and stvec would serve without intro
Hi,
Adding support for extv and extzv on aarch64 as described in
PR86901. I also changed extract_bit_field_using_extv to use
gen_lowpart_if_possible instead of gen_lowpart directly. Using gen_lowpart
directly will fail with an ICE in building libgcc when the compiler fails to
successfully do s
Richard & Segher, if y'all could check my analysis here, it'd be
appreciated.
pr90275 is a P2 regression that is only triggering on ARM. David's
testcase in c#1 is the best for this problem as it doesn't require
magic flags like -fno-dce to trigger.
The block in question:
> (code_label 89 88 9
GCC diagnoses declarations of function aliases whose type doesn't
match that of the target (ditto for attribute weakref). It doesn't
yet diagnose such incompatbilities for variable aliases but that's
just an oversight that I will try to remember to correct in GCC 11.
The attached patch updates th
Hi,
This simple patch actually is a missing part of previous one at
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01451.html
It picks up more CO_AWAIT_EXPR expanding cases. Test is also added.
Bootstrap and test on x86_64. Is it OK?
Thanks,
bin
gcc/cp
2020-02-05 Bin Cheng
* coroutin
Something like attached.
I will clean it up next week and submit it then.
It should also fix some arm64be related issues too.
Thanks,
Andrew Pinski
On Mon, Feb 3, 2020 at 6:17 PM Ian Lance Taylor wrote:
>
> On Sun, Feb 2, 2020 at 2:27 AM Andreas Schwab wrote:
> >
> > I'm getting these errors on
Hi
This patch builds co_await/yield_expr with unknown_type when we can not
know the promise type in processing_template_decl phase. it avoid to
confuse compiler when handing type deduction and conversion.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-02-05 Jun Ma
On Tue, Feb 04, 2020 at 06:04:09PM -0700, Jeff Law wrote:
> --- a/gcc/cse.c
> +++ b/gcc/cse.c
> @@ -5572,6 +5572,16 @@ cse_insn (rtx_insn *insn)
> sets[i].rtl = 0;
> }
>
> + /* Similarly for no-op moves. */
> + if (n_sets == 1
> + && GET_CODE (src) == REG
Just nits
On Tue, Feb 4, 2020 at 4:09 PM Martin Liška wrote:
>
> On 2/4/20 2:59 PM, Jakub Jelinek wrote:
> > On Tue, Feb 04, 2020 at 02:55:31PM +0100, Richard Biener wrote:
> >> On Tue, Feb 4, 2020 at 2:45 PM Martin Liška wrote:
> >>>
> >>> Hi.
> >>>
> >>> The patch is about enhancement of the documentatio
On Tue, Feb 4, 2020 at 6:40 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt wrote:
> > The current built-in support in the rs6000 back end requires at least
> > a master's degree in spelunking to comprehend. It's full of cruft,
> > redundancy, and u
83 matches
Mail list logo
