Hi Richard,
On Mon, Nov 05, 2018 at 10:09:30AM +, Richard Earnshaw (lists) wrote:
> >>> Shouldn't you be able to do this per function at least?
> >>
> >> do what per function? track speculation?
> >
> > disable shrink-wrapping only when any speculation was there
> > (this is about
On Mon, Nov 5, 2018 at 3:18 PM augustine.sterl...@gmail.com
wrote:
>
> On Mon, Nov 5, 2018 at 11:07 AM Max Filippov wrote:
>>
>> xtensa-uclinux uses bFLT executable file format that cannot relocate
>> fields representing offsets from data to code. C++ objects built as PIC
>> use offsets to
On Mon, Nov 5, 2018 at 6:55 AM Richard Biener wrote:
>
>
> The fragile PHI copying logic in the vectorizer got confused by
> constants in loop-closed PHI nodes. Fixed like the following.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> Richard.
>
> From
On Sat, Nov 3, 2018 at 9:03 AM, Svante Signell wrote:
> ping, no feedback so far, is anything missing/are the patches rejected?
I haven't had time to look at them yet.
As I've probably said before you will get a faster response if you are
able to follow the contribution guidelines described at
On 11/5/18 1:28 AM, H.J. Lu wrote:
> On Sun, Nov 4, 2018 at 10:02 AM Jeff Law wrote:
>>
>> On 10/22/18 9:08 AM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>> This makes c_strlen avoid an unsafe strlen folding of const arguments
>>> with non-const offset. Currently a negative out of bounds offset
>>>
Hi!
On Mon, Nov 05, 2018 at 11:08:39AM -0600, Aaron Sawdey wrote:
> This does the same thing for bswap2 that I previously did for bswapdi2.
> The predicates for bswap2_{load,store} are now
> indexed_or_indirect_operand,
> and bswap2 uses rs6000_force_indexed_or_indirect_mem to make sure the
>
On Mon, Nov 5, 2018 at 11:07 AM Max Filippov wrote:
> xtensa-uclinux uses bFLT executable file format that cannot relocate
> fields representing offsets from data to code. C++ objects built as PIC
> use offsets to encode FDE structures. As a result C++ exception handling
> doesn't work correctly
On Mon, Nov 5, 2018 at 2:39 PM Tim van Deurzen wrote:
> I've been getting to know my way around the c++ compiler front-end while
> implementing the spaceship operator. To ensure this feature is part of
> the next release I'm including my work so far as a patch. Testing and
> development are still
On Mon, 5 Nov 2018, Jakub Jelinek wrote:
> On Fri, Nov 02, 2018 at 11:43:03PM +, Joseph Myers wrote:
> > Here's an updated version of the patch that also updates most of the
> > previously omitted libquadmath/math/ files that are based on glibc sources
> > (not fmaq.c or rem_pio2q.c),
Hi!
On Mon, Nov 05, 2018 at 12:35:24PM +, Renlin Li wrote:
> >>--- a/gcc/combine.c
> >>+++ b/gcc/combine.c
> >>@@ -14998,6 +14998,8 @@ make_more_copies (void)
> >>continue;
> >> if (TEST_HARD_REG_BIT (fixed_reg_set, REGNO (src)))
> >>continue;
> >>+ if (REG_P (dest)
Hello all,
I've been getting to know my way around the c++ compiler front-end while
implementing the spaceship operator. To ensure this feature is part of
the next release I'm including my work so far as a patch. Testing and
development are still very much ongoing.
This patch adds only the new
On 11/05/2018 11:32 PM, gcc-patches-h...@gcc.gnu.org wrote:
> Hi! This is the ezmlm program. I'm managing the
> gcc-patches@gcc.gnu.org mailing list.
>
> To confirm that you would like
>
>t...@kompiler.org
>
> added to the gcc-patches mailing list, please send
> an empty reply to this address:
>>>
- ipa-pta (disabled by default, -fno-ipa-pta)
- ipa-reference (list of accessed/modified global vars), disable by
-fno-ipa-refernece
- stack alignment requirements (no flag to disable)
>>>
>>> Would it be possible to add flag for it? Can you please point to a location
Hi Mike,
On Fri, Nov 02, 2018 at 02:37:34PM -0400, Michael Meissner wrote:
> This patch removes all of the so-called power9 fusion support for the GCC
> compiler. It leaves -mpower9-fusion as a deprecated switch in case somebody
> used it (the switch was never documented).
As Mike Stump says,
Hi Richard, Jakub,
Can you take a look at this patch? The last review from Kirill was in
June.
Thanks.
H.J.
--
There are many duplicated AVX2/AVX512 vec_dup patterns like:
(define_insn "avx2_vec_dup"
[(set (match_operand:VF1_128_256 0 "register_operand" "=v")
On Mon, Nov 05, 2018 at 10:03:29AM +0100, Corinna Vinschen wrote:
> On Nov 3 07:00, Stafford Horne wrote:
> > The new GCC port for OpenRISC will use the init_fini_array only and not
> > provide the init() and fini() functions. Disable the function usage by
> > default as its no longer needed.
>
The code with an intermediate register is perfectly fine, but LRA
apparently cannot handle the resulting code, or perhaps something else
is wrong. In either case, making an extra temporary will not likely
help here, so let's just skip it.
Committing.
Segher
2018-11-05 Segher Boessenkool
Hi,
Would you be interested in "Attendees list of Consumer Electronics Show -
CES 2019?"
List Contains: Contact Name, Company's Name, Phone Number, Title, Email
address, Complete Mailing Address, Web address etc.
Please let me know your interest to send you the number of Attendees and
cost.
Hi,
this patch reset some of frontend langhooks that I think should be
completely handled by middle-end now. I will also make patch to rewrite
set_assembler_name in some way that is safe, the comment bellow
the hunk added is bit oversimplified because we do add external
symbols (such as ctors and
This patch to the Go frontend changes
Builtin_call_expression::do_numeric_constant_value to accept an
argument of abstract type. This is because it can be called by
Array_type::verify_length before the determine types pass. The test
case for this is https://golang.org/cl/147537. This fixes
On Mon, Nov 05, 2018 at 10:10:22AM -0500, Rich Felker wrote:
> On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> > On 04/11/18 09:05, Stafford Horne wrote:
> > > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> > >> On 27/10/18 05:37, Stafford Horne wrote:
> > ...
>
On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> On 04/11/18 09:05, Stafford Horne wrote:
> > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> >> On 27/10/18 05:37, Stafford Horne wrote:
> ...
> >>> +#undef LINK_SPEC
> >>> +#define LINK_SPEC "%{h*} \
On 11/05/2018 11:17 AM, Paul Koning wrote:
On Nov 5, 2018, at 11:45 AM, Jeff Law wrote:
...
I can do that, but I'm wondering if some systems have different prototypes than
the C standard calls for so I'd end up breaking those.I wouldn't worry about
those. I think the bigger question
On Mon, 5 Nov 2018 at 20:46, Richard Henderson wrote:
>
> On 11/4/18 9:05 AM, Stafford Horne wrote:
> > I have had some inqueries into helping
> > bootstrap some linux nommu machines.
>
> For nommu, we'd need to implement an FDPIC ABI.
>
> Otherwise, code segments cannot be mapped separately
>
On 11/4/18 9:05 AM, Stafford Horne wrote:
> I have had some inqueries into helping
> bootstrap some linux nommu machines.
For nommu, we'd need to implement an FDPIC ABI.
Otherwise, code segments cannot be mapped separately
from data segments. I believe that the arm (32bit)
port has recently
The C++ frontend gained various location wrapper nodes in r256448 (GCC 8).
That patch:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00799.html
added wrapper nodes around all nodes with !CAN_HAVE_LOCATION_P for:
* arguments at callsites, and for
* typeid, alignof, sizeof, and offsetof.
This
The C frontend is able (where expression locations are available) to print
problems with binary operators in 3-location form, labelling the types of
the expressions:
arg_0 op arg_1
~ ^~ ~
||
|arg1 type
arg0 type
The C++ frontend currently just shows the
This patch adds recognition of the u8string and u8string_view type
aliases to the gdb pretty printer extension.
libstdc++-v3/ChangeLog:
2018-11-04 Tom Honermann
* python/libstdcxx/v6/printers.py (register_type_printers): Add
type printers for u8string and u8string_view.
*
On 11/5/18 12:36 PM, Peter Bergner wrote:
> On 11/5/18 1:20 PM, Jeff Law wrote:
>> On 11/1/18 4:07 PM, Peter Bergner wrote:
>>> On 11/1/18 1:50 PM, Renlin Li wrote:
Is there any update on this issues?
arm-none-linux-gnueabihf native toolchain has been mis-compiled for a
while.
>>>
This patch adds new tests for char8_t standard library features. Most
of these tests were cloned from existing tests that exercise char16_t
and adapted for char8_t. Only testsuite/experimental/feat-char8_t.cc
and testsuite/ext/char8_t/atomic-1.cc are net new tests.
libstdc++-v3/ChangeLog:
This patch augments existing tests to validate behavior for char8_t. In
all cases, added test cases are cloned from existing tests for wchar_t
or char16_t.
A few tests required updates to line numbers for diagnostic messages.
libstdc++-v3/ChangeLog:
2018-11-04 Tom Honermann
*
This patch updates existing testing gaps related to support for u8
character and string literals. None of these changes exercise new
char8_t functionality; they are intended to guard against regressions in
behavior of u8 literals when support for char8_t is not enabled.
This patch corrects ambiguous partial specializations of
typelist::detail::append_. Previously, neither append_,
Typelist_Chain> nor append_ was a better
match for append_, null_type>.
libstdc++-v3/ChangeLog:
2018-11-04 Tom Honermann
* include/ext/typelist.h: Constrained a partial
This patch adds support to libstdc++ for the P0482R5 standard library
changes. This includes:
- New char8_t based specializations:
- std::numeric_limits
- std::char_traits
- std::hash
- std::hash
- std::hash
- std::codecvt
- std::codecvt
- std::codecvt_byname
-
This patch adds new tests to exercise new behavior for when support for
char8_t is enabled as well as protect against unintended behavioral
impact when support for char8_t is not enabled. In some cases, existing
tests suffice to exercise existing behavior and such tests have been
cloned to
This patch adds support for the P0482R5 core language changes. This
includes:
- The -fchar8_t and -fno_char8_t command line options.
- char8_t as a keyword.
- The char8_t builtin type as a non-aliasing unsigned integral
character type of size 1.
- Use of char8_t as a simple type specifier.
-
This series of patches provides an implementation of the core language
and library changes for C++ proposal P0482R5 [1]. These changes are
believed to be complete with the exception of the proposed mbrtoc8() and
c8rtomb() functions (the expectation is that the C library will provide
mbrtoc8()
This patch adds documentation for new -fchar8_t and -fno-char8_t options.
gcc/ChangeLog:
2018-11-04 Tom Honermann
* doc/invoke.texi (-fchar8_t): Document new option.
Tom.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 57491f1033c..cd3a2a715db 100644
---
> On Nov 4, 2018, at 2:33 PM, Jeff Law wrote:
>
> On 11/1/18 1:30 PM, Paul Koning wrote:
>> A number of test cases fail on pdp11 because they use the "inf" float value
>> which does not exist on that target (nor on VAX). Rainer Orth and Joseph
>> Myers suggested adding a new
On 11/5/18 1:20 PM, Jeff Law wrote:
> On 11/1/18 4:07 PM, Peter Bergner wrote:
>> On 11/1/18 1:50 PM, Renlin Li wrote:
>>> Is there any update on this issues?
>>> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
>>
>> From the analysis I've done, my commit is just
On 11/5/18 1:19 PM, Joseph Myers wrote:
On Sun, 4 Nov 2018, Ed Smith-Rowland wrote:
I looked in glibc. Unfortunately, I see how they have the same mistake:
glibc/math/w_tgammal_compat.c:
long double
__tgammal(long double x)
{
int local_signgam;
long double y =
On 11/1/18 4:07 PM, Peter Bergner wrote:
> On 11/1/18 1:50 PM, Renlin Li wrote:
>> Is there any update on this issues?
>> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
>
> From the analysis I've done, my commit is just exposing latent issues
> in LRA. Can you try
> On Nov 5, 2018, at 1:48 PM, Michael Matz wrote:
>
> Hi,
>
> On Mon, 5 Nov 2018, Jeff Law wrote:
>
Don't we have a flag specific to honoring nans? Would that be better
to use than flag_unsafe_math_optimizations? As Uli mentioned,
there's
>>>
>>> That's only relevant for
xtensa-uclinux uses bFLT executable file format that cannot relocate
fields representing offsets from data to code. C++ objects built as PIC
use offsets to encode FDE structures. As a result C++ exception handling
doesn't work correctly on xtensa-uclinux. Don't use PIC by default on
xtensa-uclinux uses bFLT executable file format that cannot relocate
fields representing offsets from data to code. C++ objects built as PIC
use offsets to encode FDE structures. As a result C++ exception handling
doesn't work correctly on xtensa-uclinux. Don't use PIC by default on
Hi,
On Mon, 5 Nov 2018, Jeff Law wrote:
> >> Don't we have a flag specific to honoring nans? Would that be better
> >> to use than flag_unsafe_math_optimizations? As Uli mentioned,
> >> there's
> >
> > That's only relevant for the comparison optimization, of course.
> >
> > Converting erfc
Hi,
On Fri, 2 Nov 2018, Martin Liška wrote:
> V2 of the patch.
>
> Thoughts?
Whereever the new function belongs it certainly isn't system.h. Also the
definition in a header seems excessive. Sure, it enables inlining of it,
but that seems premature optimization. It contains a loop, and
On 11/5/18 11:27 AM, Joseph Myers wrote:
> On Sun, 4 Nov 2018, Jeff Law wrote:
>
>> Don't we have a flag specific to honoring nans? Would that be better to
>> use than flag_unsafe_math_optimizations? As Uli mentioned, there's
>
> That's only relevant for the comparison optimization, of course.
On Sun, 4 Nov 2018, Jeff Law wrote:
> Don't we have a flag specific to honoring nans? Would that be better to
> use than flag_unsafe_math_optimizations? As Uli mentioned, there's
That's only relevant for the comparison optimization, of course.
Converting erfc to 1-erf is dubious, since the
On Sun, 4 Nov 2018, Ed Smith-Rowland wrote:
> I *do* think a couple tests should be added to test-signgam-*.c to test
> alternation of signs:
The main tests for results of libm functions are in auto-libm-test-in
(from which auto-libm-test-out-* are generated by gen-auto-libm-tests.c)
and
On Sun, 4 Nov 2018, Ed Smith-Rowland wrote:
> I looked in glibc. Unfortunately, I see how they have the same mistake:
> glibc/math/w_tgammal_compat.c:
> long double
> __tgammal(long double x)
> {
> int local_signgam;
> long double y = __ieee754_gammal_r(x,_signgam);
>
> On Nov 5, 2018, at 11:45 AM, Jeff Law wrote:
>
>>> ...
>>
>> I can do that, but I'm wondering if some systems have different prototypes
>> than the C standard calls for so I'd end up breaking those.I wouldn't worry
>> about those. I think the bigger question (thanks
> Martin) is whether
On 11/05/2018 12:35 PM, Renlin Li wrote:
Hi Segher,
On 11/03/2018 02:34 AM, Jeff Law wrote:
On 11/2/18 5:54 PM, Segher Boessenkool wrote:
On Fri, Nov 02, 2018 at 06:03:20PM -0500, Segher Boessenkool wrote:
The original rtx is generated by expand_builtin_setjmp_receiver to adjust
the frame
On Fri, Nov 02, 2018 at 11:43:03PM +, Joseph Myers wrote:
> Here's an updated version of the patch that also updates most of the
> previously omitted libquadmath/math/ files that are based on glibc sources
> (not fmaq.c or rem_pio2q.c), including *gamma*. It adds exp2q and
> issignalingq
On Sat, 3 Nov 2018, Jeff Law wrote:
> Note that Joseph's follow-up doesn't touch on the gamma problem AFAICT,
> but instead touches on the larger issues around trying to keep the
> quadmath implementations between glibc and gcc more in sync.
The second version of my patch
On 11/01/2018 07:45 AM, Martin Liška wrote:
On 11/1/18 1:15 PM, Jakub Jelinek wrote:
On Thu, Nov 01, 2018 at 01:09:16PM +0100, Martin Liška wrote:
-range 0.0 to 1.0, inclusive.
+range 0.0 to 1.0, inclusive. The @var{probability} argument must be
+a compiler time constant.
When you say must,
On November 5, 2018 5:11:09 PM GMT+01:00, Jan Hubicka wrote:
>> Hi,
>> this is patch I ended up testing. It ensures that canonical types of
>> copies I create are same as of originals C++ FE has its own refernece
>piece of mail got lost rendering the paragraph unreadable. I wanted to
>say:
>
This does the same thing for bswap2 that I previously did for bswapdi2.
The predicates for bswap2_{load,store} are now
indexed_or_indirect_operand,
and bswap2 uses rs6000_force_indexed_or_indirect_mem to make sure the
address is appropriate for that predicate.
Bootstrap/regtest passes on ppc64le
On 11/02/2018 04:37 AM, marxin wrote:
gcc/ChangeLog:
2018-11-02 Martin Liska
* mem-stats.h (mem_alloc_description::get_list): Fix GNU coding
style.
* vec.c: Likewise.
I have no preference here or even know what the style guide calls
for (nor have I been able to
On 11/5/18 7:44 AM, Richard Biener wrote:
>
> The PR18041 testcase is about bitfield insertion of the style
>
> b->bit |= <...>
>
> where the RMW cycle we end up generating contains redundant
> masking and ORing of the original b->bit value. The following
> adds a combine pattern in
On 11/5/18 8:12 AM, Paul Koning wrote:
>
>
>> On Nov 3, 2018, at 10:12 PM, Jeff Law wrote:
>>
>> On 11/1/18 1:13 PM, Paul Koning wrote:
>>> A number of test cases contain declarations like:
>>> void *memcpy();
>>> which currently are silently accepted on most platforms but not on all;
>>>
On 05.11.18 15:38, Robin Dapp wrote:
> Hi,
>
> the attached patch increases the move costs for moves involving the CC
> register. This saves us some instructions in SPEC CPU2006.
>
> Regards
> Robin
>
> --
>
> gcc/ChangeLog:
>
> 2018-11-05 Robin Dapp
>
> * config/s390/s390.c
On 05.11.18 17:32, Ilya Leoshkevich wrote:
> RTL output now includes column numbers in addition to line numbers,
> like this:
>
> "gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c":16:1
>
> This confuses some S/390 tests.
>
> gcc/testsuite/ChangeLog:
>
> 2018-11-05 Ilya Leoshkevich
>
>
RTL output now includes column numbers in addition to line numbers,
like this:
"gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c":16:1
This confuses some S/390 tests.
gcc/testsuite/ChangeLog:
2018-11-05 Ilya Leoshkevich
* gcc.target/s390/md/andc-splitter-1.c: Add colon to
On Nov 2, 2018, at 11:37 AM, Michael Meissner wrote:
>
> As I discussed in my 2018 Cauldron talk, the PowerPC GCC compiler supported a
> subset of the original design for fusion in the power9 hardware using
> peepholes
> to fuse together ADDIS instructions and floating point load/store
> Hi,
> this is patch I ended up testing. It ensures that canonical types of
> copies I create are same as of originals C++ FE has its own refernece
piece of mail got lost rendering the paragraph unreadable. I wanted to say:
This is patch I ended up testing. It ensures that canonical types of
Hi,
this is patch I ended up testing. It ensures that canonical types of
copies I create are same as of originals C++ FE has its own refernece
type construction (cp_build_reference_type) and it creates additional
pointer types with TYPE_REF_IS_RVALUE set and it has different
TYPE_CANONICAL.
On 11/05/2018 08:12 AM, Paul Koning wrote:
On Nov 3, 2018, at 10:12 PM, Jeff Law wrote:
On 11/1/18 1:13 PM, Paul Koning wrote:
A number of test cases contain declarations like:
void *memcpy();
which currently are silently accepted on most platforms but not on all; pdp11 (and
possibly
> > + gcc_assert (TYPE_CANONICAL (t2) != t2
> > + && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t)));
> > + TYPE_CANONICAL (first) = TYPE_CANONICAL (TYPE_MAIN_VARIANT (t));
>
> as said the TYPE_CANONICAL assign should be already done exactly this
> way in
On Mon, 5 Nov 2018, Jan Hubicka wrote:
> > Hmm, this _should_ be a no-op. Can you, before that line, add
> >
> > gcc_assert (TYPE_CANONICAL (t2) != t2
> > && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t)));
> >
> > ? That is, the incomplete variant should share
> On 11/5/18 7:21 AM, Jan Hubicka wrote:
> >>
> >> Did you mean "the nearest common dominator"?
> >
> > If the nearest common dominator appears in the loop while all uses are
> > out of loops, this will result in suboptimal xor placement.
> > In this case you want to split edges out of the loop.
> Hmm, this _should_ be a no-op. Can you, before that line, add
>
> gcc_assert (TYPE_CANONICAL (t2) != t2
> && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t)));
>
> ? That is, the incomplete variant should share TYPE_CANONICAL with
> the pointed-to type and be _not_ the
> On Nov 3, 2018, at 10:12 PM, Jeff Law wrote:
>
> On 11/1/18 1:13 PM, Paul Koning wrote:
>> A number of test cases contain declarations like:
>> void *memcpy();
>> which currently are silently accepted on most platforms but not on all;
>> pdp11 (and possibly some others) generate a
On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> On 04/11/18 09:05, Stafford Horne wrote:
> > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> >> On 27/10/18 05:37, Stafford Horne wrote:
> ...
> >>> +#undef LINK_SPEC
> >>> +#define LINK_SPEC "%{h*} \
On 11/5/18 7:21 AM, Jan Hubicka wrote:
>>
>> Did you mean "the nearest common dominator"?
>
> If the nearest common dominator appears in the loop while all uses are
> out of loops, this will result in suboptimal xor placement.
> In this case you want to split edges out of the loop.
>
> In
The fragile PHI copying logic in the vectorizer got confused by
constants in loop-closed PHI nodes. Fixed like the following.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
>From a965417cbefd54f45ac6f2b6e3d5dc39c307da09 Mon Sep 17 00:00:00 2001
From: Richard
On Mon, 5 Nov 2018, Jan Hubicka wrote:
> Hi,
> this patch fixes the miscompare I introduced to spec2006 GCC benchmark
> when build with LTO.
> The problem is that fld_incomplete_type_of builds new pointer type to
> incomplete type rather than complete but it ends up giving wrong type
> canonical.
The PR18041 testcase is about bitfield insertion of the style
b->bit |= <...>
where the RMW cycle we end up generating contains redundant
masking and ORing of the original b->bit value. The following
adds a combine pattern in simplify-rtx to specifically match
(X & C) | ((X | Y) & ~C)
diff --git a/gcc/profile-count.h b/gcc/profile-count.h
index 4289bc5a004..2b5e3269250 100644
--- a/gcc/profile-count.h
+++ b/gcc/profile-count.h
@@ -218,6 +218,11 @@ public:
}
+ /* Return true if value is zero. */
+ bool never_p () const
+{
+ return m_val == 0;
+}
/*
Hi,
the attached patch increases the move costs for moves involving the CC
register. This saves us some instructions in SPEC CPU2006.
Regards
Robin
--
gcc/ChangeLog:
2018-11-05 Robin Dapp
* config/s390/s390.c (s390_register_move_cost): Increase costs
for moves involving
diff --git a/gcc/profile-count.h b/gcc/profile-count.h
index f4d0c340a0a..4289bc5a004 100644
--- a/gcc/profile-count.h
+++ b/gcc/profile-count.h
@@ -200,11 +200,11 @@ public:
ret.m_quality = profile_guessed;
return ret;
}
- static profile_probability always ()
+ static
One more change is needed.
Thanks for understanding,
Martin
>From 60d59b8b3deea1b59c135705b333ddf2ab6a9ba4 Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 5 Nov 2018 15:28:21 +0100
Subject: [PATCH] Do not use %zu format in libcpp.
libcpp/ChangeLog:
2018-11-05 Martin Liska
* symtab.c
Hi.
I'm sending obvious fix that I forgot to adjust.
Martin
>From 873c7df254f98b27a83272abd9f60adb32741026 Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 5 Nov 2018 15:22:20 +0100
Subject: [PATCH] Fix printf call in symtab.c.
libcpp/ChangeLog:
2018-11-05 Martin Liska
* symtab.c
>
> Did you mean "the nearest common dominator"?
If the nearest common dominator appears in the loop while all uses are
out of loops, this will result in suboptimal xor placement.
In this case you want to split edges out of the loop.
In general this is what the LCM framework will do for you if
In order to properly fix PR87762, we need to distinguish between
instructions which support relative addressing and instructions which
don't. We could check whether the existing "type" attribute is equal to
"larl", but there are notable exceptions (lrl, for example), and
changing them makes
Hi!
I've backported from trunk, bootstrapped/regtested on x86_64-linux and
i686-linux and committed to gcc-8-branch the following 6 patches.
Jakub
2018-11-05 Jakub Jelinek
Backported from mainline
2018-10-19 Jakub Jelinek
PR middle-end/85488
PR
On Mon, 5 Nov 2018 at 18:14, Richard Biener wrote:
>
> On Mon, Nov 5, 2018 at 1:11 PM Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 5 Nov 2018 at 15:10, Richard Biener
> > wrote:
> > >
> > > On Fri, Nov 2, 2018 at 10:37 AM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > Hi,
> > > > This patch
On 26/10/2018 06:04, Prathamesh Kulkarni wrote:
> Hi,
> This is a rebased version of patch that adds a pattern to neon.md for
> implementing division with multiplication by reciprocal using
> vrecpe/vrecps with -funsafe-math-optimizations excluding -Os.
> The newly added test-cases are not
On Sun, Nov 4, 2018 at 11:00 PM Uros Bizjak wrote:
>
> On Mon, Nov 5, 2018 at 6:54 AM Wei Xiao wrote:
> >
> > > Please also rename these:
> > >
> > > _mm512_mask_fixupimm_round_pd (__m512d __A, __mmask8 __U, __m512d __B,
> > > __m512i __C, const int __imm, const int __R)
> >
Hi,
this patch fixes the miscompare I introduced to spec2006 GCC benchmark
when build with LTO.
The problem is that fld_incomplete_type_of builds new pointer type to
incomplete type rather than complete but it ends up giving wrong type
canonical.
This patch also improves TBAA with early opts
Hi.
There's a sparc fix that I've just installed in libsanitizer upstream
repository. I'm going to install it into GCC's trunk.
Martin
>From c43ed4eb4d76ec25e42b954a00a1684de09011da Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 5 Nov 2018 14:30:00 +0100
Subject: [PATCH] Fix build on
Hi Prathamesh,
Prathamesh Kulkarni wrote:
> Thanks for the suggestions. The last time I benchmarked the patch
> (around Jan 2016)
> I got following results with the patch for SPEC2006:
>
> a15: +0.64% overall, 481.wrf: +6.46%
> a53: +0.21% overall, 416.gamess: -1.39%, 481.wrf: +6.76%
> a57:
On Mon, Nov 5, 2018 at 1:17 PM Martin Liška wrote:
>
> On 11/5/18 10:56 AM, Richard Biener wrote:
> > On Mon, Nov 5, 2018 at 9:07 AM marxin wrote:
> >>
> >>
> >> gcc/ChangeLog:
> >
> >/* Release PTR pointer of SIZE bytes. If REMOVE_FROM_MAP is set to true,
> > remove the instance from
On Mon, Nov 5, 2018 at 1:17 PM Martin Liška wrote:
>
> On 11/5/18 10:52 AM, Richard Biener wrote:
> > On Mon, Nov 5, 2018 at 9:07 AM marxin wrote:
> >>
> >>
> >> libcpp/ChangeLog:
> >
> > Hmm, the patch suggests the flag might be instead
> > part of cpp_hash_table instead of each individual
> >
On Mon, Nov 5, 2018 at 1:11 PM Prathamesh Kulkarni
wrote:
>
> On Mon, 5 Nov 2018 at 15:10, Richard Biener
> wrote:
> >
> > On Fri, Nov 2, 2018 at 10:37 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > Hi,
> > > This patch adds two transforms to match.pd to CSE erf/erfc pair.
> > > erfc(x) is
On Mon, Nov 5, 2018 at 1:07 PM Andre Vieira (lists)
wrote:
>
>
> Hi,
>
> This patch enables targets to describe DR_TARGET_ALIGNMENT as a
> compile-time variable. It does so by turning the variable into a
> 'poly_uint64'. This should not affect the current code-generation for
> any target.
>
>
Hi Segher,
On 11/03/2018 02:34 AM, Jeff Law wrote:
On 11/2/18 5:54 PM, Segher Boessenkool wrote:
On Fri, Nov 02, 2018 at 06:03:20PM -0500, Segher Boessenkool wrote:
The original rtx is generated by expand_builtin_setjmp_receiver to adjust
the frame pointer.
And later in LRA, it will try to
On 11/5/18 10:56 AM, Richard Biener wrote:
> On Mon, Nov 5, 2018 at 9:07 AM marxin wrote:
>>
>>
>> gcc/ChangeLog:
>
>/* Release PTR pointer of SIZE bytes. If REMOVE_FROM_MAP is set to true,
> remove the instance from reverse map. */
> - void release_instance_overhead (void *ptr,
On 11/5/18 10:52 AM, Richard Biener wrote:
> On Mon, Nov 5, 2018 at 9:07 AM marxin wrote:
>>
>>
>> libcpp/ChangeLog:
>
> Hmm, the patch suggests the flag might be instead
> part of cpp_hash_table instead of each individual
> ht_identifier? Or the patch is confused when it
> sets HT_GGC to 1
On Mon, 5 Nov 2018 at 15:10, Richard Biener wrote:
>
> On Fri, Nov 2, 2018 at 10:37 AM Prathamesh Kulkarni
> wrote:
> >
> > Hi,
> > This patch adds two transforms to match.pd to CSE erf/erfc pair.
> > erfc(x) is canonicalized to 1 - erf(x) and is then reversed to 1 -
> > erf(x) when
1 - 100 of 124 matches
Mail list logo
