在 2019/6/19 上午4:38, Jeff Law 写道:
On 3/26/19 5:40 AM, JunMa wrote:
Hi
According to gnu document of function attributes, neither weakref nor alias
could be attached to a function defined in current translation unit.
Although GCC checks the attributes under some circumstances, it still fails
on so
在 2019/6/18 上午6:46, Jeff Law 写道:
On 5/9/19 2:01 AM, JunMa wrote:
在 2019/5/9 上午10:22, JunMa 写道:
在 2019/5/9 上午3:02, Bernd Edlinger 写道:
On 5/8/19 4:31 PM, Richard Biener wrote:
On Tue, May 7, 2019 at 4:34 AM JunMa wrote:
在 2019/5/6 下午7:58, JunMa 写道:
在 2019/5/6 下午6:02, Richard Biener 写道:
On T
On Thu, 27 Jun 2019, Uros Bizjak wrote:
> On Thu, Jun 27, 2019 at 8:05 AM Jakub Jelinek wrote:
> >
> > On Wed, Jun 26, 2019 at 12:19:28PM +0200, Uros Bizjak wrote:
> > > Yes, the patch works OK. I'll regression test it and push it later today.
> >
> > I think it caused
> > +FAIL: gcc.dg/tree-ssa/
The only preexisting use of GIMPLE_EH_ELSE, for transactional memory
commits, did not allow exceptions to escape from the ELSE path. The
trick it uses to allow the ELSE path to see the propagating exception
does not work very well if the exception cleanup raises further
exceptions: the ELSE block
I found GIMPLE_EH_ELSE offered exactly the semantics I needed for some
Ada changes yet to be contributed, but GIMPLE_EH_ELSE was only built
by GIMPLE passes, and I needed to build earlier something that
eventually became GIMPLE_EH_ELSE.
This patch does that, introducing an EH_ELSE tree, and logic
I wonder if we want this patch:
--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -74,6 +74,9 @@
#include
#include
#include
+#if __cplusplus == 201703L && defined __STRICT_ANSI__
+# include
+#endif
namespace std _GLIBCXX_VISIBILITY(default)
{
In the published
- the affine transformations are not commutative (the two source
operands have entirely different meaning)
- there's no need for three alternatives
- the nonimmediate_operand/Bm combination can better be vector_operand/m
gcc/
2019-06-27 Jan Beulich
* config/i386/sse.md (vgf2p8affinei
SSE2 is the required prereq of the builtins; as x86-64 has SSE2 enabled
anyway, the test failure was noticable on 32-bit builds only.
gcc/testsuite/
2019-06-27 Jan Beulich
* gcc.target/i386/gfni-4.c: Pass -msse2.
--- a/gcc/testsuite/gcc.target/i386/gfni-4.c
+++ b/gcc/testsuite/gcc.tar
Conversion of comparison results to full vectors does, when VPMOVM2* are
unavailable, not require any intermediate VMOVDQ{A,U}*: Simply use
embedded masking on VPTERNLOG* right away, which is available with
AVX512F (while VPMOVM2{D,Q} are available only with AVX512DQ).
Note that the chosen immedia
NOT on vectors of integers does not require loading a constant vector of
all ones into a register - VPTERNLOG can be used here (and could/should
be further used to carry out other binary and ternary logical operations
which don't have a special purpose instruction).
gcc/
2019-06-27 Jan Beulich
Hi Hongtao,
>> as usual, the new effective-target keyword needs documenting in
>> sourcebuild.texi.
> Like this?
a couple of nits: first of all, your mailer seems to replace tabs by a
single space. Please fix this or attach the patch instead.
> Index: ChangeLog
> ===
With just an "m" constraint misaligned memory operands won't be forced
into a register, and hence cause #GP. So far this was guaranteed only
in the case that CVT{,T}PD2DQ were chosen (which looks to be the case on
x86-64 only).
Instead of switching the second alternative to Bm, use just m on the
f
This fixes
FAIL: g++.dg/torture/pr34850.C -O2 (test for excess errors)
FAIL: g++.dg/torture/pr34850.C -O3 -g (test for excess errors)
FAIL: g++.dg/torture/pr34850.C -Os (test for excess errors)
FAIL: g++.dg/torture/pr34850.C -O2 -flto -fno-use-linker-plugin
-flto-partition=none (tes
On Thu, Jun 27, 2019 at 5:02 PM Rainer Orth
wrote:
>
> Hi Hongtao,
>
> >> as usual, the new effective-target keyword needs documenting in
> >> sourcebuild.texi.
> > Like this?
>
> a couple of nits: first of all, your mailer seems to replace tabs by a
> single space. Please fix this or attach the
Hi.
This is quite an obvious changes I've noticed during fuzzing
of s390x target compiler.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-06-27 Martin Liska
PR tree-optimization/91014
* tree-s
On Thu, Jun 27, 2019 at 10:58 AM Jan Beulich wrote:
>
> SSE2 is the required prereq of the builtins; as x86-64 has SSE2 enabled
> anyway, the test failure was noticable on 32-bit builds only.
>
> gcc/testsuite/
> 2019-06-27 Jan Beulich
>
> * gcc.target/i386/gfni-4.c: Pass -msse2.
OK.
On 6/26/19 1:39 PM, Jakub Jelinek wrote:
> On Wed, Jun 26, 2019 at 12:57:15PM +0200, Martin Liška wrote:
>> --- a/gcc/asan.c
>> +++ b/gcc/asan.c
>> @@ -1713,8 +1713,8 @@ asan_emit_allocas_unpoison (rtx top, rtx bot, rtx_insn
>> *before)
>>rtx ret = init_one_libfunc ("__asan_allocas_unpoison");
On Thu, Jun 27, 2019 at 5:23 AM Bill Schmidt wrote:
>
> Hi,
>
> We've done some experimenting and realized that the subject option almost
> always provide improved performance for Power when the loop unroller is
> enabled. So this patch turns that flag on by default for us.
>
> Bootstrapped and t
On Thu, Jun 27, 2019 at 10:18 AM Alexandre Oliva wrote:
>
> The only preexisting use of GIMPLE_EH_ELSE, for transactional memory
> commits, did not allow exceptions to escape from the ELSE path. The
> trick it uses to allow the ELSE path to see the propagating exception
> does not work very well
Hi Hongtao,
> On Thu, Jun 27, 2019 at 5:02 PM Rainer Orth
> wrote:
>>
>> Hi Hongtao,
>>
>> >> as usual, the new effective-target keyword needs documenting in
>> >> sourcebuild.texi.
>> > Like this?
>>
>> a couple of nits: first of all, your mailer seems to replace tabs by a
>> single space. Ple
On Thu, Jun 27, 2019 at 10:18 AM Alexandre Oliva wrote:
>
> I found GIMPLE_EH_ELSE offered exactly the semantics I needed for some
> Ada changes yet to be contributed, but GIMPLE_EH_ELSE was only built
> by GIMPLE passes, and I needed to build earlier something that
> eventually became GIMPLE_EH_E
On Thu, Jun 27, 2019 at 11:21 AM Martin Liška wrote:
>
> Hi.
>
> This is quite an obvious changes I've noticed during fuzzing
> of s390x target compiler.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
> gcc
When I refactored the filesystem_error code I changed it to only use the
constructor parameter in the what() string, instead of the string
returned by system_error::what(). That meant it no longer included the
description of the error_code that system_error adds. This restores the
previous behaivo
Hi,
this is updated patch for ODR based canonical type calculation. It makes use
of TYPE_CXX_ODR_P instead of doing the guesswork and while thinking how to get
rid of the quadratic behaviour of the hash I noticed that all the logic fits
quite naturally into gimple_register_canonical_type_1.
We on
Martin Liška writes:
> On 6/26/19 1:39 PM, Jakub Jelinek wrote:
>> On Wed, Jun 26, 2019 at 12:57:15PM +0200, Martin Liška wrote:
>>> --- a/gcc/tree-vect-stmts.c
>>> +++ b/gcc/tree-vect-stmts.c
>>> @@ -3483,8 +3483,7 @@ vectorizable_call (stmt_vec_info stmt_info,
>>> gimple_stmt_iterator *gsi,
>>>
On Thu, Jun 27, 2019 at 8:17 AM Jakub Jelinek wrote:
>
> Hi!
>
> In the last two alternatives of avx_vec_concat, we can allow memory
> source, which optimizes the following testcases from weird
> vmovaps (%rdi), %xmm0
> vmovaps %xmm0, %xmm0
> and similar to just the first instructi
Without these constraints asm() can't make use of mask registers.
gcc/
2019-06-27 Jan Beulich
* config/i386/constraints.md: Remove @internal from "k" and
"Yk".
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -79,10 +79,10 @@
"Second from top of 8
>>> On 27.06.19 at 12:11, wrote:
> Without these constraints asm() can't make use of mask registers.
Similarly it is entirely unclear to me how to use e.g. v4fmaddps or
vp2intersectd in asm(): For the former the respective "Yh"
constraint was dropped (oddly enough leaving its comment line in
plac
On Thu, 27 Jun 2019 at 04:23, Jeff Law wrote:
>
> On 6/26/19 7:14 PM, Bill Schmidt wrote:
> > Looks like this patch breaks bootstrap.
> >
> > /home3/wschmidt/gcc/gcc-mainline-base/gcc/tree-ssa-dse.c: In function
> > 'void dse\
> > _optimize_redundant_stores(gimple*)':
> > /home3/wschmidt/gcc/gcc-m
On Thu, Jun 27, 2019 at 10:57 AM Jan Beulich wrote:
>
> - the affine transformations are not commutative (the two source
> operands have entirely different meaning)
> - there's no need for three alternatives
> - the nonimmediate_operand/Bm combination can better be vector_operand/m
>
> gcc/
> 20
On Thu, 27 Jun 2019, Jan Hubicka wrote:
> Hi,
> this is updated patch for ODR based canonical type calculation. It makes use
> of TYPE_CXX_ODR_P instead of doing the guesswork and while thinking how to get
> rid of the quadratic behaviour of the hash I noticed that all the logic fits
> quite natu
> > + if (RECORD_OR_UNION_TYPE_P (t)
> > + && odr_type_p (t) && !odr_type_violation_reported_p (t))
> > +{
> > + /* Here we rely on fact that all non-ODR types was inserted into
> > +canonical type hash and thus we can safely detect conflicts between
> > +ODR types and intero
On Thu, 27 Jun 2019, Jan Hubicka wrote:
> > > + if (RECORD_OR_UNION_TYPE_P (t)
> > > + && odr_type_p (t) && !odr_type_violation_reported_p (t))
> > > +{
> > > + /* Here we rely on fact that all non-ODR types was inserted into
> > > + canonical type hash and thus we can safely detec
> > Actually this was intended to be prevail in both cases, but it is
> > harmless. The difference here is that anonymous types have
> > DECL_ASSEMBLED_NAME , so if we inserted them to the hash
> > table based on names they will all conflict.
> >
> > Anonymous namespace types never have duplicate
>>> On 27.06.19 at 12:20, wrote:
> On Thu, Jun 27, 2019 at 10:57 AM Jan Beulich wrote:
>>
>> - the affine transformations are not commutative (the two source
>> operands have entirely different meaning)
>> - there's no need for three alternatives
>> - the nonimmediate_operand/Bm combination can
On Thu, Jun 27, 2019 at 12:49 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 12:20, wrote:
> > On Thu, Jun 27, 2019 at 10:57 AM Jan Beulich wrote:
> >>
> >> - the affine transformations are not commutative (the two source
> >> operands have entirely different meaning)
> >> - there's no need for
Hi,
here is update patch I am re-testing. Ok if it suceeds?
Orace quary stats finished in meantime.
Alias oracle query stats:
refs_may_alias_p: 39232255 disambiguations, 47436580 queries
ref_maybe_used_by_call_p: 59801 disambiguations, 39811399 queries
call_may_clobber_ref_p: 5967 disambigu
On Thu, Jun 27, 2019 at 12:11 PM Jan Beulich wrote:
>
> Without these constraints asm() can't make use of mask registers.
asm should be deprecated. We have intrinsics for this purpose.
Uros.
> gcc/
> 2019-06-27 Jan Beulich
>
> * config/i386/constraints.md: Remove @internal from "k" a
On Thu, 27 Jun 2019, Jan Hubicka wrote:
> Hi,
> here is update patch I am re-testing. Ok if it suceeds?
+ if (!type_in_anonymous_namespace_p (t))
+ hash = htab_hash_string (IDENTIFIER_POINTER
+ (DECL_ASSEMBLER_NAME
+
Hi.
The patch addressed couple of issues that are explained and I should
have permission to install the patch.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
gcc/ChangeLog:
2019-06-27 Martin Liska
PR tree-optimization/90974
PR rtl-opti
This fixes FREs handling of TARGET_MEM_REF (it didn't consider
&TARGET_MEM_REF) and adds a late FRE pass which has iteration
disabled and runs only at -O[2s]+ to limit the compile-time
impact.
This helps cases where unrolling and vectorization exposes
"piecewise" redundancies DOM cannot handle.
Hi Bill,
On Wed, Jun 26, 2019 at 10:23:06PM -0500, Bill Schmidt wrote:
> 2019-06-27 Bill Schmidt
>
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Enable
> -fvariable-expansion-in-unroller by default.
>
>
> --- gcc/config/rs6000/rs6000.c(revision 272719)
> +
This is a minimal fix for the use of a deterministic RNG on mingw-w64,
simply using rand_s unconditionally. The rest of the r271740 changes on
trunk are not included. That means that RDSEED and RDRAND are not
available for mingw-w64 and the token passed to the constructor is
ignored completely.
>>> On 27.06.19 at 12:58, wrote:
> On Thu, Jun 27, 2019 at 12:49 PM Jan Beulich wrote:
>>
>> >>> On 27.06.19 at 12:20, wrote:
>> > On Thu, Jun 27, 2019 at 10:57 AM Jan Beulich wrote:
>> >>
>> >> - the affine transformations are not commutative (the two source
>> >> operands have entirely diff
> On Thu, 27 Jun 2019, Jan Hubicka wrote:
>
> > Hi,
> > here is update patch I am re-testing. Ok if it suceeds?
>
> + if (!type_in_anonymous_namespace_p (t))
> + hash = htab_hash_string (IDENTIFIER_POINTER
> + (DECL_ASSEMBLER_NAME
> +
On Thu, Jun 27, 2019 at 1:39 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 12:58, wrote:
> > On Thu, Jun 27, 2019 at 12:49 PM Jan Beulich wrote:
> >>
> >> >>> On 27.06.19 at 12:20, wrote:
> >> > On Thu, Jun 27, 2019 at 10:57 AM Jan Beulich wrote:
> >> >>
> >> >> - the affine transformations are
On Thu, Jun 27, 2019 at 11:33:45AM +0200, Richard Biener wrote:
> On Thu, Jun 27, 2019 at 5:23 AM Bill Schmidt wrote:
> > We've done some experimenting and realized that the subject option almost
> > always provide improved performance for Power when the loop unroller is
> > enabled. So this patc
>>> On 27.06.19 at 13:09, wrote:
> On Thu, Jun 27, 2019 at 12:11 PM Jan Beulich wrote:
>>
>> Without these constraints asm() can't make use of mask registers.
>
> asm should be deprecated. We have intrinsics for this purpose.
While maybe not explicitly applicable here, the intrinsics aren't
(af
On Thu, Jun 27, 2019 at 1:46 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 13:09, wrote:
> > On Thu, Jun 27, 2019 at 12:11 PM Jan Beulich wrote:
> >>
> >> Without these constraints asm() can't make use of mask registers.
> >
> > asm should be deprecated. We have intrinsics for this purpose.
>
> W
On 6/27/19 6:45 AM, Segher Boessenkool wrote:
> On Thu, Jun 27, 2019 at 11:33:45AM +0200, Richard Biener wrote:
>> On Thu, Jun 27, 2019 at 5:23 AM Bill Schmidt wrote:
>>> We've done some experimenting and realized that the subject option almost
>>> always provide improved performance for Power whe
>>> On 27.06.19 at 14:00, wrote:
> On Thu, Jun 27, 2019 at 1:46 PM Jan Beulich wrote:
>>
>> >>> On 27.06.19 at 13:09, wrote:
>> > On Thu, Jun 27, 2019 at 12:11 PM Jan Beulich wrote:
>> >>
>> >> Without these constraints asm() can't make use of mask registers.
>> >
>> > asm should be deprecated.
On Thu, Jun 27, 2019 at 2:23 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 14:00, wrote:
> > On Thu, Jun 27, 2019 at 1:46 PM Jan Beulich wrote:
> >>
> >> >>> On 27.06.19 at 13:09, wrote:
> >> > On Thu, Jun 27, 2019 at 12:11 PM Jan Beulich wrote:
> >> >>
> >> >> Without these constraints asm() c
Hi.
So this is a patch candidate for the .gnu.lto_.lto ELF section.
As mentioned, the section contains information about bytecode version,
compression algorithm used and slim LTO object flag.
One minor issues is that I need to append random suffix to the section:
[ 6] .gnu.lto_.lto.36e74acfb145
On 6/21/19 4:28 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>>
>> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
>>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19 1:47
On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>
> On 6/21/19 4:28 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
> >>
> >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> On Fri, Jun 21, 20
On Thu, Jun 27, 2019 at 05:46:00AM -0600, Jan Beulich wrote:
> While maybe not explicitly applicable here, the intrinsics aren't
> (afaict) providing full flexibility. In particular (just as example)
> I haven't found a way to use embedded broadcast with the
> intrinsics, but I can easily do so wit
On 6/18/19 12:16 PM, Jakub Jelinek wrote:
> I think any such length changes should be moved after the two punt checks.
> Move also the len3 setting before the new checks (of course conditional on
> is_ncmp).
Ok, I'm sending updated version of the patch that addresses this.
I've been testing the pa
No. Since this is LTO, it's very hard to simplify the big application. Sorry
for that.
I think Christophe is mentioning the case from g++.dg is reporting the similar
issue like " type variant differs by TYPE_CXX_ODR_P ", right?
Thanks,
-Jiangning
> -Original Message-
> From: Jan Hubic
Hi Dave,
last version for this patch addressing the suggestion about the
JIT_BIT_FIELD macros comment description.
Thank you for all the suggestions.
Regarding the write access please see my previous answer into the binary
op patch thread.
Bests
Andrea
2019-06-20 Andrea Corallo andrea.cora.
Hi.
This reduces 2 warnings reported by clang.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-06-27 Martin Liska
* edit-context.c (test_applying_fixits_unreadable_file): Do not
use () for a co
Hi.
The patch continues to remove quite obvious dead assignments
that are not used.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-06-27 Martin Liska
* config/i386/i386-expand.c (ix86_expand_sse2_mulv
On Thu, Jun 27, 2019 at 04:03:06PM +0200, Martin Liška wrote:
> * ggc-page.c (free_page): Use (char *) for %p printf format
> argument.
> --- a/gcc/ggc-page.c
> +++ b/gcc/ggc-page.c
> @@ -977,7 +977,7 @@ free_page (page_entry *entry)
>if (GGC_DEBUG_LEVEL >= 2)
> fprintf (G.deb
> On Jun 25, 2019, at 4:22 PM, acsaw...@linux.ibm.com wrote:
>
> From: Aaron Sawdey
>
> * config/pdp11/pdp11.md (movmemhi, movmemhi1,
> movmemhi_nocc, UNSPEC_MOVMEM): Change movmem to cpymem.
Ok, thanks.
paul
On 6/27/19 4:11 PM, Jakub Jelinek wrote:
> On Thu, Jun 27, 2019 at 04:03:06PM +0200, Martin Liška wrote:
>> * ggc-page.c (free_page): Use (char *) for %p printf format
>> argument.
>
>> --- a/gcc/ggc-page.c
>> +++ b/gcc/ggc-page.c
>> @@ -977,7 +977,7 @@ free_page (page_entry *entry)
>>
On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>>
>> On 6/21/19 4:28 PM, Richard Biener wrote:
>>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> On 6/21/19 1:58 PM,
On Thu, Jun 27, 2019 at 04:21:10PM +0200, Martin Liška wrote:
> 2019-06-27 Martin Liska
>
> * edit-context.c (test_applying_fixits_unreadable_file): Do not
> use () for a constructor call.
> (test_applying_fixits_line_out_of_range): Likewise.
> * ggc-page.c (alloc_page):
On 6/27/19 8:21 AM, Martin Liška wrote:
On 6/27/19 4:11 PM, Jakub Jelinek wrote:
On Thu, Jun 27, 2019 at 04:03:06PM +0200, Martin Liška wrote:
* ggc-page.c (free_page): Use (char *) for %p printf format
argument.
--- a/gcc/ggc-page.c
+++ b/gcc/ggc-page.c
@@ -977,7 +977,7 @@ f
On 6/26/19 8:40 PM, Martin Sebor wrote:
> On 6/26/19 4:31 PM, Jeff Law wrote:
>> On 6/25/19 5:03 PM, Martin Sebor wrote:
>>
>>>
>>> The caller ensures that handle_char_store is only called for stores
>>> to arrays (MEM_REF) or single elements as wide as char.
>> Where? I don't see it, even after f
On 6/27/19 9:00 AM, Jeff Law wrote:
> On 6/26/19 8:40 PM, Martin Sebor wrote:
>> On 6/26/19 4:31 PM, Jeff Law wrote:
>>> On 6/25/19 5:03 PM, Martin Sebor wrote:
>>>
The caller ensures that handle_char_store is only called for stores
to arrays (MEM_REF) or single elements as wide as c
On 6/27/19 8:03 AM, Martin Liška wrote:
Hi.
This reduces 2 warnings reported by clang.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-06-27 Martin Liska
* edit-context.c (test_applying_fixits_unread
On 6/27/19 12:05 AM, Jakub Jelinek wrote:
> On Wed, Jun 26, 2019 at 12:19:28PM +0200, Uros Bizjak wrote:
>> Yes, the patch works OK. I'll regression test it and push it later today.
>
> I think it caused
> +FAIL: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"
> which admittedly a
On Thu, Jun 27, 2019 at 09:24:58AM -0600, Jeff Law wrote:
> On 6/27/19 12:05 AM, Jakub Jelinek wrote:
> > On Wed, Jun 26, 2019 at 12:19:28PM +0200, Uros Bizjak wrote:
> >> Yes, the patch works OK. I'll regression test it and push it later today.
> >
> > I think it caused
> > +FAIL: gcc.dg/tree-ssa
On 6/27/19 9:34 AM, Jakub Jelinek wrote:
> On Thu, Jun 27, 2019 at 09:24:58AM -0600, Jeff Law wrote:
>> On 6/27/19 12:05 AM, Jakub Jelinek wrote:
>>> On Wed, Jun 26, 2019 at 12:19:28PM +0200, Uros Bizjak wrote:
Yes, the patch works OK. I'll regression test it and push it later today.
>>>
>>> I
On 26/06/19 19:13 -0400, Ed Smith-Rowland via libstdc++ wrote:
Here is the first of three patches for C++20 constexpr library.
?? Implement C++20 p0202 - Add constexpr Modifiers to Functions in
and Headers.
??Implement C++20 p1023 - constexpr comparison operators for std::array.
I
On 6/27/19 12:11 AM, Li Jia He wrote:
> Hi,
>
> According to the optimizable case described by Qi Feng on
> issue 88784, we can combine the cases into the following:
>
> 1. x > y && x != XXX_MIN --> x > y
> 2. x > y && x == XXX_MIN --> false
> 3. x <= y && x == XXX_MIN --> x == X
On Thu, Jun 27, 2019 at 09:15:41AM -0600, Jeff Law wrote:
> Actually it was trivial to create with store merging.
>
> char x[20];
> foo()
> {
> x[0] = 0x41;
> x[1] = 0x42;
> }
>
> MEM [(char *)&x] = 16961;
>
> So clearly we can get this in gimple. So we need a check of some kind,
> eithe
As I detail in PR 91009, I had some testsuite failures with my patches for a
future machine. In the future patches, I added new RTL attributes to support
the new prefixed load/store instructions (which will include pc-relative
support). This new attribute needs to look at the 'type' RTL attribute
On 6/27/19 11:41 AM, Jonathan Wakely wrote:
On 26/06/19 19:13 -0400, Ed Smith-Rowland via libstdc++ wrote:
Here is the first of three patches for C++20 constexpr library.
?? Implement C++20 p0202 - Add constexpr Modifiers to Functions
in and Headers.
??Implement C++20 p1023 - conste
On 6/27/19 9:15 AM, Jeff Law wrote:
On 6/27/19 9:00 AM, Jeff Law wrote:
On 6/26/19 8:40 PM, Martin Sebor wrote:
On 6/26/19 4:31 PM, Jeff Law wrote:
On 6/25/19 5:03 PM, Martin Sebor wrote:
The caller ensures that handle_char_store is only called for stores
to arrays (MEM_REF) or single eleme
On Thu, Jun 27, 2019 at 5:26 AM Uros Bizjak wrote:
>
> On Thu, Jun 27, 2019 at 2:23 PM Jan Beulich wrote:
> >
> > >>> On 27.06.19 at 14:00, wrote:
> > > On Thu, Jun 27, 2019 at 1:46 PM Jan Beulich wrote:
> > >>
> > >> >>> On 27.06.19 at 13:09, wrote:
> > >> > On Thu, Jun 27, 2019 at 12:11 PM J
On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
> The LHS is unsigned short so handle_char_store would not be called
> because of the check in the caller. You would need something like:
>
> MEM [(char *)&x] = { 'a', 'b' };
This is invalid, because the rhs is non-empty CONSTRUCTO
On Thu, 27 Jun 2019 at 19:55, Ed Smith-Rowland via libstdc++
wrote:
> > I don't think this will work in a constant expression:
> >
> > ?? /// Assign @p __new_val to @p __obj and return its previous value.
> > ?? template
> > +?? _GLIBCXX20_CONSTEXPR
> > ?? inline _Tp
> > ?? exchange(_
Martin Liška writes:
> diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> index d50b811d863..1bd251ea8e2 100644
> --- a/gcc/config/i386/i386-expand.c
> +++ b/gcc/config/i386/i386-expand.c
> @@ -19780,8 +19780,7 @@ ix86_expand_sse2_mulvxdi3 (rtx op0, rtx op1, rtx op2)
>
On Thu, Jun 27, 2019 at 10:23 AM Martin Liška wrote:
>
> On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> > On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
> >>
> >> On 6/21/19 4:28 PM, Richard Biener wrote:
> >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21, 2
I've committed the attached patch after successful
regression tests on x86_64-*-freebsd. The patch
returns MATCH_NO when matching is done for a COMMON
statement, but the statement in fact is not COMMON.
See testcases.
While here I corrected the recording of the wrong
revision number in the Change
On Mon, Jun 24, 2019 at 1:46 PM Jan Hubicka wrote:
> >
> > I thought I remembered someone's recent-ish work to treat specially
> > types containing a char array, but I'm not finding it now.
> >
> > > For dynamically allocated memory as well as for stack space after stack
> > > slot sharing done in
>
> It's useful on targets without COMDAT support. Are there any such
> that we care about at this point?
>
> If the problem is the combination with LTO, why not just prohibit that?
The problem is that at the collect2 time we want to decide whether to
hold stderr/stdout of the linker. The issue
> On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
>
>>
>> It's useful on targets without COMDAT support. Are there any such
>> that we care about at this point?
>>
>> If the problem is the combination with LTO, why not just prohibit that?
>
> The problem is that at the collect2 time we want to
On 6/25/19 4:43 PM, Jeff Law wrote:
> On 6/25/19 2:22 PM, acsaw...@linux.ibm.com wrote:
>> From: Aaron Sawdey
>>
>> * builtins.c (get_memory_rtx): Fix comment.
>> * optabs.def (movmem_optab): Change to cpymem_optab.
>> * expr.c (emit_block_move_via_cpymem): Change movmem to cpymem.
On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
>> The LHS is unsigned short so handle_char_store would not be called
>> because of the check in the caller. You would need something like:
>>
>> MEM [(char *)&x] = { 'a'
>
> > On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
> >
> >>
> >> It's useful on targets without COMDAT support. Are there any such
> >> that we care about at this point?
> >>
> >> If the problem is the combination with LTO, why not just prohibit that?
> >
> > The problem is that at the colle
The linker [ld64] that supports 64Bit does not need the JBSR longcall
optimisation, and will not work with the most generic case (where the
symbol is undefined external, but there is no symbl stub). So switch
the longcall option off. ld64 will generate branch islands as needed.
tested on powerpc
A recent merge dropped whitespace in the endfile specs, which affects
transactional memory cases.
applied to mainline
thanks
Iain
2019-06-27 Iain Sandoe
* config/rs6000/darwin.h (ENDFILE_SPEC): Correct whitespace in the
spec.
--- a/gcc/config/rs6000/darwin.h
+++ b/gcc/config/
The default for the kernel is soft-float, however a user writing a kernel
extension might want to make use of hard float. This change makes
" -mkernel -mhard-float " work as expected.
tested on powerpc-darwin9
applied to mainline
thanks
Iain
2019-06-27 Iain Sandoe
* config/rs6000/rs6
On 6/27/19 11:04 AM, Jakub Jelinek wrote:
On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
The LHS is unsigned short so handle_char_store would not be called
because of the check in the caller. You would need something like:
MEM [(char *)&x] = { 'a', 'b' };
This is invalid,
On Thu, Jun 27, 2019 at 11:16 AM Martin Sebor wrote:
>
> On 6/27/19 8:03 AM, Martin Liška wrote:
> > Hi.
> >
> > This reduces 2 warnings reported by clang.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> > g
I am testing the latest GCC with not-yet-submitted GLIBC changes that
implement libmvec on Aarch64.
While trying to run SPEC 2017 (specifically 521.wrf_r) I ran into a
case where GCC was generating a call to _ZGVnN2vv_powf, that is a
vectorized powf call for 2 (not 4) elements. This was a problem
A future PowerPC machine may have prefixed instructions. This patch changes
the RTL "length" attribute of all of the "mov*", and "*extend*" insns from an
explicit "4" to "*". This change prepares for the length attribute to be set
appropriately for single instruction loads, stores, and add immedi
Hi,
The parameter names here were in the wrong order (which doesn't matter
to the interpreter, but confuses the humans reading the calling code).
I am going to install the following patch soon.
gcc/ChangeLog:
* gdbhooks.py (GdbPrettyPrinters.add_printer_for_types): Reorder
param
This testcase in the PR is extremely recursive, and therefore uses a huge
amount of memory on caching the results of individual calls. We no longer
need to track all calls to catch infinite recursion, as we have other limits
on maximum depth and operations count. So let's only cache a few calls a
1 - 100 of 115 matches
Mail list logo
