On 2019/6/27 11:48 PM, Jeff Law wrote:
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 &
Hi.
This patch includes implementation of new function roundeven along
with two utility functions. The patch bootstraps on x86_64-linux-gnu
and passes regression tests.
Thanks,
Tejas
gcc/ChangeLog:
2019-06-12 Tejas Joshi
* builtins.c (mathfn_built_in_2): Added CASE_MATHFN for ROUNDEVEN.
On Jun 27, 2019, Richard Biener wrote:
> On Thu, Jun 27, 2019 at 10:18 AM Alexandre Oliva wrote:
>> @@ -909,6 +909,13 @@ DEFTREECODE (TRY_CATCH_EXPR, "try_catch_expr",
>> tcc_statement, 2)
>> The second operand is a cleanup expression which is evaluated
>> on any exit (normal, exception, or ju
On Thu, Jun 27, 2019 at 5:38 PM Rainer Orth
wrote:
>
> 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 ni
On 6/27/19 10:12 AM, Jakub Jelinek wrote:
> 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
This patch updates the predicates for prefixed addressing.
This patch deletes a predicate that I had originally added, but the code no
longer uses.
This patch changes how local symbols for pc-relative addressing are marked.
Previously, we had used a machine dependent bit in the SYMBOL_REF node.
To keep things organized, I'm going to start submitting the patches for for a
possible future PowerPC machine's prefixed addressing (including pc-relative
suport) as threads under this message.
There are two patches that I've already submitted that are needed for the rest
of the patches:
Patch #1
On Thu, Jun 20, 2019 at 12:50 PM Jim Wilson wrote:
> This looks OK to me. It is worth pointing out that ARM already ships
> compilers built this way, but they didn't bother adding a configure
> option. They just override Makefile variables in their build scripts.
> I think this is much cleaner a
On 27/06/19 19:07 -0400, Ed Smith-Rowland wrote:
On 6/27/19 1:06 PM, Ville Voutilainen wrote:
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.
?? tem
On 6/27/19 1:06 PM, Ville Voutilainen wrote:
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
On 6/27/19 12:40 PM, Richard Biener wrote:
> 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 s
Hi!
The likely/unlikely C++11 attributes on case labels result in GIMPLE_PREDICT
statements inserted after the label; we should just ignore such statements,
they aren't something executable in between the labels.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued fo
Hi!
As the testcase shows, offset{1,2} can be NULL and operand_equal_p doesn't
like NULL arguments. If both are NULL, we should return true, if just one,
we should return false.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2019-06-27 Jakub Jelinek
PR tr
On 6/23/19 5:51 PM, Martin Sebor wrote:
On 6/22/19 9:37 PM, Jason Merrill wrote:
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
ini
On 6/24/19 4:52 AM, Paolo Carlini wrote:
Hi,
On 23/06/19 19:45, Jason Merrill wrote:
On 6/23/19 7:53 AM, Paolo Carlini wrote:
... hi again ;)
The other day I was having a look at using declarations for this
issue and noticed that only a few lines below the de-virtualization
check we have to
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
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
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
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
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
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,
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
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 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
>
> > 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
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 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 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
>
> 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 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
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 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
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, 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(_
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, 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 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 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
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 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
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 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 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 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 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 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 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/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 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 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 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 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 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 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
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
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 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.
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
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
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 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 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
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 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
>>> 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 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 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 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 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 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, 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 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
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.
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 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.
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
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 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
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: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
>>> 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
> > 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 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
> > + 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:
> 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
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 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 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
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 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
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,
>>>
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
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
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
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
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:
>
> 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
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 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 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.
1 - 100 of 115 matches
Mail list logo
