On Tue, 31 Dec 2019, Jakub Jelinek wrote:
> On Tue, Dec 31, 2019 at 05:47:54PM +0100, Richard Biener wrote:
> > >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > Ok.
>
> Thanks.
>
> > >One thing I haven't done anything about yet is that there is
> > >FAIL: gcc.dg/tr
> On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:
> > Inline should return failure either (newsize > param_large_function_insns)
> > OR (newsize > limit). Sometimes newsize is larger than
> > param_large_function_insns, but smaller than limit, inline doesn't return
> > failure even if the n
On Mon, 6 Jan 2020, Kewen.Lin wrote:
> Hi all,
>
> Recently I'm investigating on an issue related to use D-form/X-form vector
> memory access, it's the same as what the patch
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01879.html
> was intended to deal with. Power9 introduces DQ-form instru
On 1/6/20 3:04 PM, Martin Sebor wrote:
On 1/6/20 3:05 AM, Martin Liška wrote:
Hi.
The patch is about explanation what happens when
a target_clone function calls a function without
the attribute.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2020-01-06 Martin Liska
PR ipa/83411
Hi,
On Mon, Jan 06 2020, Jan Hubicka wrote:
>> Hi,
>>
>> throughout this year a few of us got burnt by the fact that
>> cgraph_edge::resolve_speculation method sometimes removed and
>> deallocated its this pointer, sometimes making the this pointer of a few
>> other methods of the class also sudd
On Tue, 7 Jan 2020, Jakub Jelinek wrote:
> Hi!
>
> In x * x = ((x & -2) + (x & 1))^2 = ((x^2) & -4) + 2 * (x & -2) * (x & 1) +
> (x & 1)^2
> the first two terms are divisible by 4 and the last one is 0 or 1, so
> (x * x) % 4U <= 1
> and thus bit ccp can assume he second least significant bit of
Hi.
I would like to make cgraph_node names consistent in cgraph_node::dump.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-01-02 Martin Liska
* cgraph.c (cgraph_node::dump): Use systematically
On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
>
> On Mon, 16 Dec 2019, Andrew Pinski wrote:
>
> > On Thu, Nov 15, 2018 at 12:31 AM Richard Biener wrote:
> > >
> > > On Thu, 15 Nov 2018, Richard Biener wrote:
> > >
> > > > On Wed, 14 Nov 2018, Andrew Pinski wrote:
> > > >
> > > > > On Fri,
On 1/6/20 8:03 PM, Jan Hubicka wrote:
OK
Actually I am not so sure about this patch - how do we ensure
reproducibility in this case?
ISTM that anyone trying to have reproducible builds shouldn't be using
PGO based optimizations.
OpenSUSE does that. Builds are supposed to be reproducible + PGO
First *ping* (two weeks old but all during the holiday season).
Side note, for what it is worth: Thomas K regarded the Fortran part as
reasonable/OK – but those OpenACC changes also affect
C/C++/omp-low.c/libgomp :-) – cf.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01596.html
Cheers,
Tob
Hi Julian,
looks good to me – thanks!
Tobias
On 1/4/20 3:25 AM, Julian Brown wrote:
Hi,
This test (by Tobias Burnus, mildly edited) adds a test to check whether
the final component of a derived-type access has pointer or allocatable
type for manual deep copy attach/detach operations. This is
On 1/7/20 9:40 AM, Jan Hubicka wrote:
On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:
Inline should return failure either (newsize > param_large_function_insns)
OR (newsize > limit). Sometimes newsize is larger than
param_large_function_insns, but smaller than limit, inline doesn't retur
On 2020/1/7 16:40, Jan Hubicka wrote:
>> On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:
>>> Inline should return failure either (newsize > param_large_function_insns)
>>> OR (newsize > limit). Sometimes newsize is larger than
>>> param_large_function_insns, but smaller than limit, inlin
Hi Julian,
@Jakub: I suggest to enable it also for OpenMP as prep work. Any
objections/comments?
@Thomas: This all assumes that "copy(a,a.comp)" is not valid in OpenACC;
does this match your understanding of the spec?
On 1/4/20 3:25 AM, Julian Brown wrote:
In C/C++, it's not permitted to mi
On Tue, 7 Jan 2020, Andrew Pinski wrote:
> On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
> >
> > On Mon, 16 Dec 2019, Andrew Pinski wrote:
> >
> > > On Thu, Nov 15, 2018 at 12:31 AM Richard Biener wrote:
> > > >
> > > > On Thu, 15 Nov 2018, Richard Biener wrote:
> > > >
> > > > > On Wed,
> On 1/6/20 8:03 PM, Jan Hubicka wrote:
> > > > > OK
> > > > Actually I am not so sure about this patch - how do we ensure
> > > > reproducibility in this case?
> > > ISTM that anyone trying to have reproducible builds shouldn't be using
> > > PGO based optimizations.
> >
> > OpenSUSE does that. B
> On 6 Jan 2020, at 16:21, Jonathan Wakely wrote:
>>
>> Overall, this really seems like a good setting for
>> --enable-libstdcxx-time auto.
>
> OK, that makes sense. Thanks!
Sure, thank you for your feedback :)
Hi,
On Tue, Jan 07 2020, Martin Liška wrote:
> Hi.
>
> I would like to make cgraph_node names consistent in cgraph_node::dump.
>
I try to use just the symtab_order numbers whenever I can to avoid
confusion but - at least if we care about the non-asm name at all -
shouldn't the dump have both the
On 1/7/20 11:08 AM, Jan Hubicka wrote:
On 1/6/20 8:03 PM, Jan Hubicka wrote:
OK
Actually I am not so sure about this patch - how do we ensure
reproducibility in this case?
ISTM that anyone trying to have reproducible builds shouldn't be using
PGO based optimizations.
OpenSUSE does that. Buil
Hi!
I'd like to ping a few patches:
PR target/93009 - avx512* wrong-code fix
http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01488.html
PR target/93069 - avx512* rejects-valid fix (rejected by assembler)
http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html
PR tree-optimization/92868 - compu
The SVE port needs to maintain a different type identity for
GNU vectors and "SVE vectors", since the types use different ABIs.
Until now we've done that using pointer equality between the
TYPE_MAIN_VARIANT and the built-in SVE type.
However, as Richard B noted, that doesn't work well for LTO,
whe
Hi Julian,
please hold back the commit.
Actually, it does not seem to work if one modifies the test
case a bit. The following code compiles – but I think it
should not:
type one
integer i, j
end type
type two
type(one) A, B
end type
type(two) x
!$acc enter data copyin(x%A, x%A%i)
!$acc en
On 1/7/20 11:12 AM, Martin Jambor wrote:
I try to use just the symtab_order numbers whenever I can to avoid
confusion
Which is fine. Apparently there are just few usages of manual printing
of a symtab node and order like:
fprintf (f,
"%*s%s/%i %s\n%*s freq:%4.2f",
Richard Sandiford writes:
> Richard Biener writes:
>> On December 14, 2019 11:43:48 AM GMT+01:00, Richard Sandiford
>> wrote:
>>>Richard Biener writes:
On December 13, 2019 10:12:40 AM GMT+01:00, Richard Sandiford
>>> wrote:
>Richard Biener writes:
>The AArch64 port emits an
On Tue, 17 Dec 2019, Martin Jambor wrote:
> Hi,
>
> PR 92486 shows that DSE, when seeing a "normal" gimple aggregate
> assignment coming from a C struct assignment and one a representing a
> folded memcpy, can kill the latter and keep in place only the former,
> which does not copy padding - at l
on 2020/1/7 下午5:14, Richard Biener wrote:
> On Mon, 6 Jan 2020, Kewen.Lin wrote:
>
>> We are thinking whether it can be handled in IVOPTs instead of one RTL pass.
>>
>> During IVOPTs selecting IV cands, it doesn't know the loop will be unrolled
>> so
>> it doesn't count the possible step cost in
Hi,
On 06/01/20 21:47, Jason Merrill wrote:
On 1/2/20 4:23 AM, Paolo Carlini wrote:
@@ -19320,8 +19320,8 @@ tsubst_copy_and_build (tree t,
tree op1 = tsubst (TREE_OPERAND (t, 1), args, complain,
in_decl);
tree op2 = RECUR (TREE_OPERAND (t, 2));
- ret = build_new (&placement_v
Is there any chance left we can get this done for 10.1? If not, can we please
get it ready for 10.2 ASAP?
Cheers,
Matthias
On Montag, 14. Oktober 2019 14:12:12 CET Matthias Kretz wrote:
> Let me try again to get this patch ready. It will need a few iterations...
> This patch is without documen
On 12/18/19 1:49 AM, Jakub Jelinek wrote:
On Tue, Dec 17, 2019 at 09:53:43AM -0700, Martin Sebor wrote:
I appreciate a cleanup but I don't have the impression this patch
does clean anything up. Because of all the formatting changes and
no tests the effect of the changes isn't as clear as it sho
Richard Biener writes:
> On Tue, 7 Jan 2020, Andrew Pinski wrote:
>
>> On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
>> >
>> > On Mon, 16 Dec 2019, Andrew Pinski wrote:
>> >
>> > > On Thu, Nov 15, 2018 at 12:31 AM Richard Biener
>> > > wrote:
>> > > >
>> > > > On Thu, 15 Nov 2018, Richa
Hi Julian, hi Thomas,
in terms of the check, it looks fine to me – but I am not sure about the
spec.
At least the following test case seems to work fine:
integer :: A(10,10), out(12)
A = reshape([(i, i=0,100)], shape(A))
!$omp target map(A(3:6,3:5), out)
!$acc parallel copy(A(3:6,3:5), out)
On Tue, Jan 7, 2020 at 3:01 AM Matthias Kretz wrote:
>
> Is there any chance left we can get this done for 10.1? If not, can we please
> get it ready for 10.2 ASAP?
>
> Cheers,
> Matthias
>
> On Montag, 14. Oktober 2019 14:12:12 CET Matthias Kretz wrote:
> > Let me try again to get this patch re
On Tue, 7 Jan 2020, Kewen.Lin wrote:
> on 2020/1/7 下午5:14, Richard Biener wrote:
> > On Mon, 6 Jan 2020, Kewen.Lin wrote:
> >
> >> We are thinking whether it can be handled in IVOPTs instead of one RTL
> >> pass.
> >>
> >> During IVOPTs selecting IV cands, it doesn't know the loop will be
> >>
On Tue, 7 Jan 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 7 Jan 2020, Andrew Pinski wrote:
> >
> >> On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
> >> >
> >> > On Mon, 16 Dec 2019, Andrew Pinski wrote:
> >> >
> >> > > On Thu, Nov 15, 2018 at 12:31 AM Richard Biene
On 12/19/19 10:08 AM, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index f57469b6e23..f40f6432fd4 100644
>> --- a/gcc/config/aarch64/aarch64.c
>> +++ b/gcc/config/aarch64/aarch64.c
>> @@ -21661,6 +21661,68
On 23/12/2019 16:57, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> On 12/19/19 10:01 AM, Richard Sandiford wrote:
+
+#pragma GCC push_options
+#pragma GCC target ("arch=armv8.2-a+bf16")
+#ifdef __ARM_FEATURE_BF16_SCALAR_ARITHMETIC
+
+typedef __bf16 bfloa
on 2020/1/7 下午7:25, Richard Biener wrote:
> On Tue, 7 Jan 2020, Kewen.Lin wrote:
>
>> on 2020/1/7 下午5:14, Richard Biener wrote:
>>> On Mon, 6 Jan 2020, Kewen.Lin wrote:
>>>
We are thinking whether it can be handled in IVOPTs instead of one RTL
pass.
During IVOPTs selecting IV
Richard Biener writes:
> On Tue, 7 Jan 2020, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Tue, 7 Jan 2020, Andrew Pinski wrote:
>> >
>> >> On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
>> >> >
>> >> > On Mon, 16 Dec 2019, Andrew Pinski wrote:
>> >> >
>> >> > > On Thu, Nov
Hi all,
This patch is part of a series adding support for Armv8.6-A features.
It depends on the patch enabling Arm BFmode
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html
This patch adds intrinsics for brain half-precision float-point dot product.
ACLE documents are at https://developer.
On Thu, Jan 2, 2020 at 10:04 AM Martin Liška wrote:
>
> Hi.
>
> The patch is about using Optimization for warn_inline as
> it's affected by -O0.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Err - Optimization also lists it in some -help sec
On Fri, Jan 3, 2020 at 1:26 PM Martin Liška wrote:
>
> Hi.
>
> One another fix where -Ox sets a parameter that
> is not marked with Optimize keyword. Fixed by
> adding the keyword.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
As said in the
Hi,
On Fri, Jan 03 2020, Feng Xue OS wrote:
> When checking a self-recursively generated value for aggregate jump
> function, wrong aggregate lattice was used, which will cause infinite
> constant propagation. This patch is composed to fix this issue.
>
> 2020-01-03 Feng Xue
>
> PR ipa
On Dienstag, 7. Januar 2020 12:16:57 CET Andrew Pinski wrote:
> On Tue, Jan 7, 2020 at 3:01 AM Matthias Kretz wrote:
> > Is there any chance left we can get this done for 10.1? If not, can we
> > please get it ready for 10.2 ASAP?
> >
> > Cheers,
> >
> > Matthias
> >
> > On Montag, 14. Oktobe
Hello,
Should we try to get this refactoring in stage 3 or park it for next
stage 1?
Cheers,
Andre
On 10/12/2019 13:36, Andre Vieira (lists) wrote:
Hi,
This patch aims at refactoring the vectorizer code to no longer need to
reset DR_OFFSET for epilogue vectorization and instead keep track
What about the previous patch fixing the existing testism by skipping
for big-endian arm using existing target supports?
On 07/01/2020 07:31, Richard Biener wrote:
On Fri, 13 Dec 2019, Andre Vieira (lists) wrote:
Consequently whilst looking at the list I noticed these two were missing.
This
This patch to the Go frontend avoids a couple of compiler crashes.
These came up while building 1.14beta1 while the code was still
invalid. The general policy is to not bother committing invalid test
cases that cause compiler crashes. Bootstrapped and ran Go tests on
x86_64-pc-linux-gnu. Committ
On Tue, 7 Jan 2020, Andre Vieira (lists) wrote:
> What about the previous patch fixing the existing testism by skipping for
> big-endian arm using existing target supports?
I thought this was an update containing both - so yes, that's OK as well.
Richard.
> On 07/01/2020 07:31, Richard Biener w
> Err - Optimization also lists it in some -help section? It's a Warning
> option and certainly we don't handle per-function Warnings in general
> (with LTO) even though we have #pragma GCC diagnostic, no?
>
> I'm not sure why we force warn_inline to zero with -O0, it seems much
> better to guard
On Wed, Dec 18, 2019 at 10:59 AM Andrew Pinski wrote:
>
> On Wed, Dec 18, 2019 at 1:18 AM Hongtao Liu wrote:
> >
> > On Wed, Dec 18, 2019 at 4:26 PM Segher Boessenkool
> > wrote:
> > >
> > > On Wed, Dec 18, 2019 at 10:37:11AM +0800, Hongtao Liu wrote:
> > > > Hi:
> > > > This patch is to simpl
在 2019/11/20 下午9:11, JunMa 写道:
在 2019/11/20 下午7:22, Iain Sandoe 写道:
Hello JunMa,
JunMa wrote:
在 2019/11/17 下午6:28, Iain Sandoe 写道:
I find that the patches donot support 'for co_await'. And it is
quiet simple to implement range based 'for co_await' based on your
patches, since it's just need
On Tue, Jan 7, 2020 at 3:26 PM Jan Hubicka wrote:
>
> > Err - Optimization also lists it in some -help section? It's a Warning
> > option and certainly we don't handle per-function Warnings in general
> > (with LTO) even though we have #pragma GCC diagnostic, no?
> >
> > I'm not sure why we force
This patch fixes some failures to assemble I encountered while fixing
other issues (not yet posted).
These were caused by emitting 'B' immediates that the ISA manual
indicates should work, but the assembler rejects. I've confirmed that
they are, in fact, not handled by the hardware; if I encod
On 12/12/19 4:19 PM, Matthew Malcomson wrote:
+-param=hwasan-stack=
+Common Joined UInteger Var(param_hwasan_stack) Init(1) IntegerRange(0, 1) Param
+Enable hwasan stack protection.
+
+-param=hwasan-random-frame-tag=
+Common Joined UInteger Var(param_hwasan_random_frame_tag) Init(1)
IntegerRange
DECL_VISIBILITY_SPECIFIED is also true if an enclosing scope has explicit
visibility, and we don't want that to override -fvisibility-inlines-hidden.
So check for the attribute specifically on the function, like we already do
for template argument visibility restriction.
Tested x86_64-pc-linux-gnu
On 1/7/20 5:46 AM, Paolo Carlini wrote:
Hi,
On 06/01/20 21:47, Jason Merrill wrote:
On 1/2/20 4:23 AM, Paolo Carlini wrote:
@@ -19320,8 +19320,8 @@ tsubst_copy_and_build (tree t,
tree op1 = tsubst (TREE_OPERAND (t, 1), args, complain,
in_decl);
tree op2 = RECUR (TREE_OPERAND (t
On 12/12/19 4:19 PM, Matthew Malcomson wrote:
- if (is_store && !param_asan_instrument_writes)
+ if (is_store
+ && (!param_asan_instrument_writes || !param_hwasan_instrument_writes))
return;
- if (!is_store && !param_asan_instrument_reads)
+ if (!is_store
+ && (!param_asan_instrument_reads || !pa
On 12/12/19 4:18 PM, Matthew Malcomson wrote:
Hello.
I've just sent few comments that are related to the v3 of the patch set.
Based on the HWASAN (limited) knowledge the patch seems reasonable to me.
I haven't looked much at the newly introduced RTL-hooks.
But these seems to me isolated to the a
Hi,
>On 1/6/20 7:10 AM, Jonathan Wakely wrote:
>> GCC now defaults to -fno-common. As a result, global
>> variable accesses are more efficient on various targets. In C, global
>> variables with multiple tentative definitions will result in linker
>> errors.
>
> This is better. I'd also s/will/n
Stam Markianos-Wright writes:
> On 12/19/19 10:08 AM, Richard Sandiford wrote:
>> Stam Markianos-Wright writes:
>>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>>> index f57469b6e23..f40f6432fd4 100644
>>> --- a/gcc/config/aarch64/aarch64.c
>>> +++ b/gcc/config/aarch6
This patch add vector comparison patterns for many more modes.
These test failures now pass:
FAIL: gcc.dg/vect/pr65947-2.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
FAIL: gcc.dg/vect/pr65947-5.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
FAIL: gcc.dg/vect/pr65947-9.c scan-tree-dump-times
Hi Andrew,
> On 6 Jan 2020, at 23:24, Andrew Pinski wrote:
> Just one small suggestion:
Sure
> Instead of:
> - char* pStr = alloca(SIZE);
> + char* pStr = __builtin_alloca(SIZE);
>
> Why not just do:
> -#include
> +#define alloca __builtin_alloca
Yes, good idea.
Revised patch attached, wh
This patch to the Go frontend avoids generating a write barrier for
code that appears in the Go1.14beta1 runtime package in
(*pageAlloc).sysGrow:
s.summary[l] = s.summary[l][:needIdxLimit]
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofro
>
>
> On 2020/1/7 16:40, Jan Hubicka wrote:
> >> On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:
> >>> Inline should return failure either (newsize > param_large_function_insns)
> >>> OR (newsize > limit). Sometimes newsize is larger than
> >>> param_large_function_insns, but smaller than
Andi Kleen writes:
Ping!
> Andi Kleen writes:
>
> Ping!
>
>> Andi Kleen writes:
>>
>> Ping!
>>
>>> Andi Kleen writes:
>>>
>>> Ping!
>>>
Andi Kleen writes:
Ping!
> From: Andi Kleen
>
> [v4: Rebased on current tree. Avoid some redundant log statements
> for
On 07/01/20 01:30 +0100, Kamil Rytarowski wrote:
On 07.01.2020 01:26, Jonathan Wakely wrote:
On 06/01/20 23:20 +0100, Kamil Rytarowski wrote:
On 06.01.2020 16:24, Jonathan Wakely wrote:
On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
Hi Matthew,
On Mon, 4 Feb 2019, Matthew Bauer wrote:
The c
On 07/01/20 15:40 +, Jonathan Wakely wrote:
On 07/01/20 01:30 +0100, Kamil Rytarowski wrote:
On 07.01.2020 01:26, Jonathan Wakely wrote:
On 06/01/20 23:20 +0100, Kamil Rytarowski wrote:
On 06.01.2020 16:24, Jonathan Wakely wrote:
On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
Hi Matthew,
> On Tue, Jan 7, 2020 at 3:26 PM Jan Hubicka wrote:
> >
> > > Err - Optimization also lists it in some -help section? It's a Warning
> > > option and certainly we don't handle per-function Warnings in general
> > > (with LTO) even though we have #pragma GCC diagnostic, no?
> > >
> > > I'm not sur
> On 1/7/20 11:08 AM, Jan Hubicka wrote:
> > > On 1/6/20 8:03 PM, Jan Hubicka wrote:
> > > > > > > OK
> > > > > > Actually I am not so sure about this patch - how do we ensure
> > > > > > reproducibility in this case?
> > > > > ISTM that anyone trying to have reproducible builds shouldn't be using
CannaWest
http://links.infocastevents.mkt8115.com/ctt?kn=13&ms=NDE0ODk2MDMS1&r=NjkyMTk1NzM3MTk0S0&b=2&j=MTY4MDY1Nzc0NwS2&mt=1&rt=0
Thanks for the update. The new patch looks really good, just some
minor comments.
Stam Markianos-Wright writes:
> [...]
> Also I've update the filenames of all our tests to make them a bit clearer:
>
> C tests:
>
> __ bfloat16_scalar_compile_1.c to bfloat16_scalar_compile_3.c: Compilation of
>
Olivier Hainque writes:
> Hi Andrew,
>
>> On 6 Jan 2020, at 23:24, Andrew Pinski wrote:
>> Just one small suggestion:
>
> Sure
>
>> Instead of:
>> - char* pStr = alloca(SIZE);
>> + char* pStr = __builtin_alloca(SIZE);
>>
>> Why not just do:
>> -#include
>> +#define alloca __builtin_alloca
>
>
Hi!
On 2020-01-07T08:20:44+0100, Jakub Jelinek wrote:
> When I wrote the code, for map clause the arguments couldn't contain any
> REF_COMPONENT (nor REF_UNQUIRY nor REF_SUBSTRING) and therefore it was
> ok (although unclean) to just look at u.ar.type
Jakub, thanks for fixing this.
> but now th
> On Jan 7, 2020, at 7:43 AM, Jonathan Wakely wrote:
>
> For Jason and Krister's benefit, that last comment was referring to
> an earlier suggestion to not try to support old NetBSD releases, see
> https://gcc.gnu.org/ml/libstdc++/2020-01/msg00026.html
>
>> I think we need the netbsd target ma
This patch to the Go frontend and libgo stops using
__go_runtime_error. We use specific panic functions instead, which
are mostly already in the runtime package. We also correct "defer
nil" to panic when we execute the defer, rather than throw when we
queue it. Bootstrapped and ran Go testsuite
This Go frontend patch by Cherry Zhang fixes the loopdepth tracking in
array slicing expressions in escape analysis. In the gc compiler, for
slicing an array, its AST has an implicit address operation node.
There isn't such a node in the gofrontend AST. During escape
analysis, we create a fake no
Tested x86_64-pc-linux-gnu, committed to trunk.
Jonathan Wakely writes:
> On 10/12/19 22:38 -0800, Thomas Rodgers wrote:
>>User-agent: mu4e 1.3.4; emacs 26.2
>> * include/std/condition_variable
>> (condition_variable_any::wait_on(_Lock&, stop_token, _Predicate): Rename
>> to matc
Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194
>From 60f489f2bf2b32afd1bdbb2405bb028dcedf82cc Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Tue, 7 Jan 2020 20:46:26 -0800
Subject: [PATCH] Align __patchable_function_entries to POINTER_SIZE
To: gcc-patches@gcc.gnu.org
---
gcc/Change
Hi,
Function use_pred_not_overlap_with_undef_path_pred of
pass_late_warn_uninitialized
checks if predicate of variable use overlaps with predicate of undefined
control flow path.
For now, it only checks ssa_var comparing against constant, this can be
improved where
ssa_var compares against anot
Sorry, here is the patch.
--
Sender:bin.cheng
Sent At:2020 Jan. 8 (Wed.) 12:58
Recipient:GCC Patches
Subject:[PATCH GCC11]Improve uninitialized warning with value range info
Hi,
Function use_pred_not_overlap_with_undef_path_pred o
On 1/6/20 4:17 PM, Jonathan Wakely wrote:
On 07/11/19 20:28 +0100, François Dumont wrote:
From what I understood from recent fix the unordered containers need
to be updated the same way.
I hope you'll appreciate the usage of rvalue forwarding. Containers
Yes, I think it makes sense.
node v
Am 02.01.20 um 23:35 schrieb Thomas Koenig:
Hello world,
the attached patch fixes an ICE where an array constructor
containing an empty array constructor with a type didn't
get the type from the inner constructor.
The solution is to stash the type away in yet another variable
and only use it if
On 2020/1/7 23:40, Jan Hubicka wrote:
>>
>>
>> On 2020/1/7 16:40, Jan Hubicka wrote:
On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:
> Inline should return failure either (newsize > param_large_function_insns)
> OR (newsize > limit). Sometimes newsize is larger than
> par
On Tue, 7 Jan 2020, Andre Vieira (lists) wrote:
> Hello,
>
> Should we try to get this refactoring in stage 3 or park it for next stage 1?
I only looked at the patch now and I think it nicely simplifies things.
The patch is OK now with the usual function comment added before
}
+inline tree
+g
Hi!
Joseph reported ia32 glibc build ICEs, because the
*adddi3_doubleword_cc_overflow_1 pattern allows a memory output and matching
input, but addcarry* to which it splits doesn't, for some strange
reason it only allows register output. As it emits an adc instruction
which is very similar to add,
84 matches
Mail list logo
