On Wed, Nov 20, 2019 at 02:13:52AM +, Maciej W. Rozycki wrote:
Ok with appropriate ChangeLog entry.
> --- gcc.orig/libgomp/testsuite/lib/libgomp.exp
> +++ gcc/libgomp/testsuite/lib/libgomp.exp
> @@ -174,6 +174,20 @@ proc libgomp_init { args } {
> # For build-tree testing, also consider t
Am 16.11.19 um 18:36 schrieb Jeff Law:
On 11/8/19 9:19 AM, Georg-Johann Lay wrote:
Hi,
this patch adds support for a few more AVR devices. Because the offset
where flash is seen in RAM deviates from the settings for the family
(and hence also from the linker script defaults), a new field in
av
Thank you for your review, patch pushed.
//Claudiu
On Wed, Nov 20, 2019 at 1:58 AM Jeff Law wrote:
>
> On 11/19/19 2:02 AM, Claudiu Zissulescu wrote:
> > Use arc-passes.def to register ARC specific passes.
> >
> > Ok to apply?
> > Claudiu
> >
> > gcc/
> > -xx-xx Claudiu Zissulescu
> >
> >
You are right, I should start with cleaning up the movsi pattern :) I
will come back to you with a proper patch when it is ready.
Thank you,
Claudiu
On Wed, Nov 20, 2019 at 2:00 AM Jeff Law wrote:
>
> On 11/19/19 2:02 AM, Claudiu Zissulescu wrote:
> > ARC processors can use scaled addresses, i.e
There's a bit left in this PR which the following fixes. The root
only became external late and the check more naturally belongs to
the new place.
Boostrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-11-20 Richard Biener
PR tree-optimization/92537
* tree
We're doing quite some useless work here and in the case we
actually manage to "vectorize" it, we've done a no-op (bb-slp-42.c).
It also refactors the routine a bit and only dumps about "vectorizable"
CTORs when we actually analyze the SLP tree (when all CTOR elements
were internally defined).
On Wed, 20 Nov 2019, Alexandre Oliva wrote:
> On Nov 6, 2019, Alexandre Oliva wrote:
>
> > (CALLEE_FROM_CGRAPH_P): New.
> > (dump_final_callee_vcg, dump_final_node_vcg): New.
>
> I goofed in the testing of this last-minute change. It only works with
> optimization disabled. With any
On Tue, Nov 19, 2019 at 11:35:02PM -0500, Jason Merrill wrote:
> It would seem better to break after consuming the token, so we just skip the
> extra processing and still give the same error.
>
> And instead of this, maybe set CP_PARSER_FLAGS_NO_TYPE_DEFINITIONS so we
> keep the same diagnostic fo
On Tue, 19 Nov 2019 at 11:35, Richard Henderson
wrote:
>
> I'm not sure what happened to v2. I can see it in my sent email, but it never
> made it to the mailing list, and possibly not to Richard E. either.
>
> So resending, with an extra testsuite fix for ilp32, spotted by Christophe.
>
> Re thu
Segher Boessenkool writes:
>> find_sets_in_insn has:
>>
>> /* Don't count call-insns, (set (reg 0) (call ...)), as a set.
>> The hard function value register is used only once, to copy to
>> someplace else, so it isn't worth cse'ing. */
>> else if (GET_CODE (SET_SRC (x))
On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely wrote:
>
> On 09/11/19 02:07 +, Smith-Rowland, Edward M wrote:
> >Here is the part of C++20 p1032 Misc constexpr bits.
> >
> >Tested on x86_64-linux. OK?
>
> OK for trunk, thanks.
>
Hi,
The new test constexpr_allocator_arg_t.cc fails on arm and
Richard Biener writes:
> There's a bit left in this PR which the following fixes. The root
> only became external late and the check more naturally belongs to
> the new place.
>
> Boostrap and regtest running on x86_64-unknown-linux-gnu.
FWIW, I was just about to post the patch below before seei
On Tue, Nov 19, 2019 at 5:07 PM Vladimir Makarov wrote:
>
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
>
> Sometime ago a code which permits LRA to reload hard register into
> memory as it did for pseudo were added. But this LRA possibility was
> not reflecte
Matthias Klose writes:
> On 08.07.19 23:19, Matthias Klose wrote:
>> On 14.06.19 15:09, Gaius Mulley wrote:
>>>
>>> Hello,
>>>
>>> here is version two of the patches which introduce Modula-2 into the
>>> GCC trunk. The patches include:
>>>
>>> (*) a patch to allow all front ends to register a
On Wed, 20 Nov 2019 at 11:47, Christophe Lyon
wrote:
>
> On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely wrote:
> >
> > On 09/11/19 02:07 +, Smith-Rowland, Edward M wrote:
> > >Here is the part of C++20 p1032 Misc constexpr bits.
> > >
> > >Tested on x86_64-linux. OK?
> >
> > OK for trunk, tha
On Wed, 20 Nov 2019 at 11:10, Ville Voutilainen
wrote:
>
> On Wed, 20 Nov 2019 at 11:47, Christophe Lyon
> wrote:
> >
> > On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely wrote:
> > >
> > > On 09/11/19 02:07 +, Smith-Rowland, Edward M wrote:
> > > >Here is the part of C++20 p1032 Misc constexp
Richard Sandiford writes:
> Segher Boessenkool writes:
>>> find_sets_in_insn has:
>>>
>>> /* Don't count call-insns, (set (reg 0) (call ...)), as a set.
>>> The hard function value register is used only once, to copy to
>>> someplace else, so it isn't worth cse'ing. */
>>>
On Tue, Nov 19, 2019 at 11:02 PM David Malcolm wrote:
>
> > > The checker is implemented as a GCC plugin.
> > >
> > > The patch kit adds support for "in-tree" plugins i.e. GCC plugins
> > > that
> > > would live in the GCC source tree and be shipped as part of the GCC
> > > tarball,
> > > with a n
On Wed, Nov 20, 2019 at 12:30 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch fixes build of older GCC releases with newer ones.
> In GCC 4.6 and earlier, we had:
> struct cgraph_node;
> struct cgraph_node *cgraph_node (tree);
> and that is something on which GCC 9+ code errors on if it se
On Wed, Nov 20, 2019 at 11:25:46AM +0100, Richard Biener wrote:
> Nothing on the specific patch but I wonder if we should change the
> error ()s in init_dynamic_diag_info to warnings to make stage1 uses
> fine? That probably then boils down to ignoring __gcc_diag__ formats
> when initializing wasn
On Wed, 20 Nov 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > There's a bit left in this PR which the following fixes. The root
> > only became external late and the check more naturally belongs to
> > the new place.
> >
> > Boostrap and regtest running on x86_64-unknown-linux-gnu.
On Wed, 2019-11-20 at 00:38 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following patch is a minimal fix to avoid
> cannot convert ‘‘addr_expr’ not supported by dump_type’
> to ‘X*’
> and similar messages. The recently added complain_about_bad_argument
> function expects a from_type argument, but c
Hi.
The patch is about removal of an unused libtool-version file,
and comments in other libtool-version files are legacy.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch if there are no objections.
Thanks,
Martin
libsanitizer/ChangeLog:
20
On Wed, 20 Nov 2019 at 12:16, Christophe Lyon
wrote:
>
> On Wed, 20 Nov 2019 at 11:10, Ville Voutilainen
> wrote:
> >
> > On Wed, 20 Nov 2019 at 11:47, Christophe Lyon
> > wrote:
> > >
> > > On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely wrote:
> > > >
> > > > On 09/11/19 02:07 +, Smith-Rowl
On Wed, Nov 20, 2019 at 05:54:48AM -0500, David Malcolm wrote:
> I added complain_about_bad_argument in r264250 (aka
> b78e49d1ddf1a09e16152353b41bf7c0b44d6405); the intent is to special-
> case when there's a single candidate due to a bad argument, underlining
> the pertinent bogus argument at the
PING
On Wed, Nov 13, 2019 at 11:05 PM Janne Blomqvist
wrote:
>
> On Wed, Nov 13, 2019 at 10:41 PM Andrew Pinski wrote:
> >
> > On Wed, Nov 13, 2019 at 12:37 PM Janne Blomqvist
> > wrote:
> > >
> > > The FTP protocol is getting long in the tooth, and we should emphasize
> > > HTTP where that is
Hi,
Thanks for doing this. Adding Richard on cc:, since the SVE subject
tag might have put him off. There's not really anything SVE-specific
here apart from the testcase.
> 2019-11-19 Prathamesh Kulkarni
>
> PR tree-optimization/89007
> * tree-vect-patterns.c (vect_recog_average_
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
+# This file is used to maintain libtool version info for libmudflap. See
Just a small nit here, the comment is a copy&paste leftover, please rename
it to libhwasan. I've just sent similar patch that fixes that in other
places:
https://gcc.gnu.org/ml
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
These flags can't be used at the same time as any of the other
sanitizers.
We add an equivalent flag to -static-libasan in -static-libhwasan to
ensure static linking.
The -fsanitize=kernel-hwaddress option is for compiling targeting the
kernel. This
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 few more works on range for source to
> source transform. Any r
On Wed, 20 Nov 2019, Richard Sandiford wrote:
> Hi,
>
> Thanks for doing this. Adding Richard on cc:, since the SVE subject
> tag might have put him off. There's not really anything SVE-specific
> here apart from the testcase.
Ah.
> > 2019-11-19 Prathamesh Kulkarni
> >
> > PR tree-opti
Hi,
since inliner got faster malloc overhead starts to show up in profiles.
This patch eliminates a lot of malloc/free traffic by putting fibonaci
heaps nodes into pool allocators.
It also fixes a silly issue with constant sized vector not being
allocated on stack (which actually seems most import
On Wed, 20 Nov 2019, Jan Hubicka wrote:
> Hi,
> since inliner got faster malloc overhead starts to show up in profiles.
> This patch eliminates a lot of malloc/free traffic by putting fibonaci
> heaps nodes into pool allocators.
>
> It also fixes a silly issue with constant sized vector not being
Hi,
another common (ab)use of malloc/free is the DEF worklist and stack
used in streaming out. Since most of SCCs are small, we could easily
use stack for them in majority of time.
Bootstrapped/regtested x86_64-linux, OK?
* lto-streamer-out.c (DFS::sccstack): Turn into auto-vec;
Richard Biener writes:
> On Sat, 16 Nov 2019, Richard Sandiford wrote:
>> If stmt analysis failed for an SLP node, r278246 tried building the
>> node from scalars instead. By that point we've already processed child
>> nodes (usually successfully) and might have made some of them the lead
>> node
In vect-alias-check-1.c we unroll the inner loop and then vectorise
the stores at a[c + 1][b]. Since the access has no guaranteed
alignemnt, we need a realignment mechanism or support for unaligned
accesses in order to vectorise.
In vect-alias-check-18.c we use a reverse access and so need
permut
After r278246, we can try building the out[] store value from scalars
if the target has no multiplication support. That's not necessarily
a good thing, but like most of vect/, this test is run with the cost
model disabled.
Tested on aarch64-linux-gnu, x86_64-linux-gnu, powerpc64-linux-gnu
(Power
On Wed, 20 Nov 2019, Richard Biener wrote:
> On Tue, Nov 19, 2019 at 5:07 PM Vladimir Makarov wrote:
> >
> > The following patch fixes
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
> >
> > Sometime ago a code which permits LRA to reload hard register into
> > memory as it did for pse
This patch does two things regarding explicit and automatical variable
mapping to offloaded devices:
* Fixes bugs with optional arguments, which are present. They were
mapped but the mapping had issues causing run-time failures.
* It now also handles absent optional arguments.
Compared to the
在 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 few more works on range for sour
This is the analogue of r278103, but for DFP.
Committing to trunk.
Segher
2019-11-20 Segher Boessenkool
PR target/92573
* config/rs6000/dfp.md (dfptstsfi__ for DFP_TEST and DDTD):
Handle UNORDERED if !HONOR_NANS.
---
gcc/config/rs6000/dfp.md | 6 ++
1 file cha
On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson wrote:
>
> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt wrote:
> >
> > Hi Mikael,
> >
> > > This fixed the problem, thanks.
> >
> > Could you also run the testsuite to see if you can reproduce the
> > g++.old-deja failures Andreas reported?
>
> Y
On Wed, 20 Nov 2019, Jan Hubicka wrote:
> Hi,
> another common (ab)use of malloc/free is the DEF worklist and stack
> used in streaming out. Since most of SCCs are small, we could easily
> use stack for them in majority of time.
>
> Bootstrapped/regtested x86_64-linux, OK?
OK.
> * lto-st
On Wed, 20 Nov 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > On Sat, 16 Nov 2019, Richard Sandiford wrote:
> >> If stmt analysis failed for an SLP node, r278246 tried building the
> >> node from scalars instead. By that point we've already processed child
> >> nodes (usually succes
On 14/11/2019 20:23, Szabolcs Nagy wrote:
> Sorry v2 had a bug.
>
> v2: added documentation and tests.
> v3: fixed expand_simd_clones so different isa variants are actually
> generated.
>
> GCC currently supports two ways to declare the availability of vector
> variants of a scalar function:
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
Handling stack variables has three features.
1) Ensure HWASAN required alignment for stack variables
When tagging shadow memory, we need to ensure that each tag granule is
only used by one variable at a time.
This is done by ensuring that each tagge
Hi!
On Wed, Nov 20, 2019 at 03:31:36PM +0800, Kewen.Lin wrote:
> >> +(define_expand "vector_ge"
> >> + [(set (match_operand:VEC_F 0 "vlogical_operand")
> >> + (ge:VEC_F (match_operand:VEC_F 1 "vlogical_operand")
> >> +(match_operand:VEC_F 2 "vlogical_operand")))]
> >>"VECTOR_UNIT
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
There are four main features to this change:
1) Check pointer tags match address tags.
In the new `hwasan` pass we put HWASAN_CHECK internal functions around
all memory accesses, to check that tags in the pointer being used match
the tag stored in sh
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
Adding hwasan tests.
Frankly, these could be tidied up a little.
I will be tidying them up while getting feedback on the hwasan introduction.
Which is file, however I would consider adding some dynamic allocation tests.
One can easily inspire either
On 11/20/19 2:50 PM, Mikael Pettersson wrote:
> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson
> wrote:
>>
>> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt wrote:
>>>
>>> Hi Mikael,
>>>
This fixed the problem, thanks.
>>>
>>> Could you also run the testsuite to see if you can reproduce t
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
I have rebased this series onto Martin Liska's patches that take the most
recent libhwasan from upstream LLVM.
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
I've also cleared up some nomenclature (I had previously used the word 'colour'
a f
On 11/13/19 4:24 PM, Matthew Malcomson wrote:
On 12/11/2019 12:08, Martin Liška wrote:
On 11/11/19 5:03 PM, Matthew Malcomson wrote:
Ah!
My apologies -- I sent up a series with a few documentation mistakes.
(the others were wording problems so less noticeable)
That's fine, I fixed that very e
Hi Martin,
Thanks for the review,
I'll get working on your comments now, but since I really enjoyed
finding this bug in ./configure when I hit it I thought I'd answer this
right away.
On 20/11/2019 14:02, Martin Liška wrote:
> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>>
>> diff --git a/con
On 15/11/2019 09:55, Szabolcs Nagy wrote:
> Musl does not support initial-exec tls in dynamically loaded shared
> libraries.
ping.
>
> libgomp/ChangeLog:
>
> 2019-11-15 Szabolcs Nagy
>
> * configure.tgt: Avoid IE tls on *-*-musl*.
i should add PR libgomp/91938 here.
>
> libitm/Chan
On 11/20/19 3:37 PM, Matthew Malcomson wrote:
Hi Martin,
Thanks for the review,
You're welcome.
I'll get working on your comments now, but since I really enjoyed
finding this bug in ./configure when I hit it I thought I'd answer this
right away.
Heh :)
On 20/11/2019 14:02, Martin Liška
On 2019-11-20 5:06 a.m., Richard Biener wrote:
On Tue, Nov 19, 2019 at 5:07 PM Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
Sometime ago a code which permits LRA to reload hard register into
memory as it did for pseudo were added. But
On Wed, 2019-11-06 at 11:30 +0100, Martin Liska wrote:
> gcc/ChangeLog:
>
> 2019-11-06 Martin Liska
>
> * Makefile.in: Include params.opt.
> * flag-types.h (enum parloops_schedule_type): Add
> parloops_schedule_type used in params.opt.
> * params.opt: New file.
> ---
>
On 11/20/19 3:49 PM, David Malcolm wrote:
On Wed, 2019-11-06 at 11:30 +0100, Martin Liska wrote:
gcc/ChangeLog:
2019-11-06 Martin Liska
* Makefile.in: Include params.opt.
* flag-types.h (enum parloops_schedule_type): Add
parloops_schedule_type used in params.opt.
On 20/11/2019 14:46, Martin Liška wrote:
> On 11/20/19 3:37 PM, Matthew Malcomson wrote:
>> Hi Martin,
>>
>> Thanks for the review,
>
> You're welcome.
>
>> I'll get working on your comments now, but since I really enjoyed
>> finding this bug in ./configure when I hit it I thought I'd answer this
On Wed, 2019-11-20 at 15:51 +0100, Martin Liška wrote:
> On 11/20/19 3:49 PM, David Malcolm wrote:
> > On Wed, 2019-11-06 at 11:30 +0100, Martin Liska wrote:
> > > gcc/ChangeLog:
> > >
> > > 2019-11-06 Martin Liska
> > >
> > > * Makefile.in: Include params.opt.
> > > * flag-types.h (enum p
Hi,
I have noticed that for Firefox around 1GB of peak memory use goes into
the fact that we never free memory_block_pool::freelist.
This patch adds memory_block_pool::trim which reduces freelist to a given
size. It is called from ggc_collect which is a convenient place to return
heap allocations
On 11/20/19 4:03 PM, Jan Hubicka wrote:
I have noticed that for Firefox around 1GB of peak memory use goes into
the fact that we never free memory_block_pool::freelist.
Great, can you reduce the peak memory by the 1GB with the patch?
Thanks,
Martin
On 11/20/19 4:02 PM, David Malcolm wrote:
On Wed, 2019-11-20 at 15:51 +0100, Martin Liška wrote:
On 11/20/19 3:49 PM, David Malcolm wrote:
On Wed, 2019-11-06 at 11:30 +0100, Martin Liska wrote:
gcc/ChangeLog:
2019-11-06 Martin Liska
* Makefile.in: Include params.opt.
* fla
> On 11/20/19 4:03 PM, Jan Hubicka wrote:
> > I have noticed that for Firefox around 1GB of peak memory use goes into
> > the fact that we never free memory_block_pool::freelist.
>
> Great, can you reduce the peak memory by the 1GB with the patch?
About half of it, approx 0.5GB (8.3GB -> 7.8GB) j
bb-slp-40.c fails on SPARC targets without VIS4 because it
requires addition on vectors of bytes. There doesn't seem to be
an existing target selector for this, so I added vect_char_add.
(Wasn't sure whether to use vect_char_add, for consistency
with vect_no_int_add/vect_int_mult etc., or vect_add
Hi!
On Wed, Nov 20, 2019 at 09:42:46AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> >> Before I resubmit, why is the simplify-rtx.c part all wrong?
> >
> > It was nice and simple, and it isn't anymore. 8 4 2 1 for the four of
> > lt gt eq un are hardly worth documenting or maki
Allowing mixed vector sizes broke the assumption in the following assert,
since it's now possible for different accesses to require different
levels of alignment:
/* FORNOW: use the same mask to test all potentially unaligned
references in the loop. The vectorizer c
Hi,
sadly this patch seems to trigger false positive
../../gcc/vec.h:311:10: error: attempt to free a non-heap object �@Xa�@Y
[-Werror=free-nonheap-object]
which is about vec destructor freeing heap allocated memory if the
vector was ever resized from hits stack allocated place. In this case
it
On 20/11/2019 14:33, Martin Liška wrote:
> On 11/13/19 4:24 PM, Matthew Malcomson wrote:
>> On 12/11/2019 12:08, Martin Liška wrote:
>>> On 11/11/19 5:03 PM, Matthew Malcomson wrote:
Ah!
My apologies -- I sent up a series with a few documentation mistakes.
>
>>
>> b) Marking 'ptr' and 'm
Hi Janne,
On 11/18/19 9:34 PM, Janne Blomqvist wrote:
Now that we require a minimum of MPFR 3.1.0+ to build GCC, we can do
some modernization of the MPFR usage in the GFortran frontend.
OK – thanks for the cleanup.
[For reference, those changes were introduced in MPFR 3.0.0, cf.
https://www.
This patch builds on https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html.
Tie static assertion diagnostics into constraint diagnostic. For
example, this program:
template
concept iterator =
requires (I i)
{
++i;
*i;
};
static_assert(iterator);
Yields these errors:
x.cpp:11:1
Segher Boessenkool writes:
> Hi!
>
> On Wed, Nov 20, 2019 at 09:42:46AM +, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> >> Before I resubmit, why is the simplify-rtx.c part all wrong?
>> >
>> > It was nice and simple, and it isn't anymore. 8 4 2 1 for the four of
>> > lt gt eq u
On Wed, 20 Nov 2019, Jakub Jelinek wrote:
> Ok with appropriate ChangeLog entry.
I've used one included with the submission. Change applied now, thanks
for your review.
Maciej
LGTM.
Thanks,
Tobias
PS: For reference, mpfr_regular_p was added in MPFR 3.0.0 (as stated);
acting as follows:
mpfr_number_p = returns nonzero if ordinary number (i.e., neither NaN
nor an infinity),
mpfr_regular_p = returns nonzero if regular number (i.e., neither NaN,
nor an infinity nor ze
The `--enable-version-specific-runtime-libs' configuration option is now
supported throughout all of our target library subdirectories, so update
installation documentation accordingly and also mention that the default
for the option is `yes' for libada and `no' for the remaining libraries.
Hi,
this patch treads ages old problem that compile time needed to estimate call
size is not constant, but a function of a number of calls of the callee.
If there is a function with many callers and many callees this triggers
quadratic behaviour.
This patch adds summary info for all callees of a n
On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > UNLT & ORDERED is always LT. When would it not be true?
>
> LT traps on quiet NaNs for -ftrapping-math, UNLT and ORDERED don't.
No? -ftrapping-math makes nothing trap. The only thing it does is
Hi,
this patch avoids malloc traffic in evaluate_properties_for_edge which
allocates vectors holding known values, aggregates and polyorphic contextes.
I made the vector allocated by a caller who can place them at stack using
auto_vec.
The patch also adds logic to avoid calculation and clearing of
On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote:
> On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > UNLT & ORDERED is always LT. When would it not be true?
> >
> > LT traps on quiet NaNs for -ftrapping-math, UNLT and ORDER
Richard Sandiford writes:
>>> I'd actually considered converting to signed and back instead of adding
>>> extra cases, but I thought that would be rejected as too inefficient.
>>> (That was a concern with my patch above.) It seemed like one of the selling
>>> points of doing it your way was that
On Wed, 20 Nov 2019, Alexander Monakov wrote:
> On Wed, 20 Nov 2019, Richard Biener wrote:
>
> > On Tue, Nov 19, 2019 at 5:07 PM Vladimir Makarov
> > wrote:
> > >
> > > The following patch fixes
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
> > >
> > > Sometime ago a code which
My patch that added initial C2X support and associated command-line
options missed documenting -Wc11-c2x-compat although the other options
were properly documented. This patch adds the missing documentation.
Tested with "make info" and "make pdf". Applied to mainline. Will apply
to GCC 9 branc
Hi,
while working on improving the locations of cp_build_indirect_ref_1 &
co, I noticed this nit which seems a separate issue.
In a nutshell, at variance with many other cases, in build_x_arrow we
don't immediately check for error_mark_node the return value of
decay_conversion. Then, for the
Hi,
this patch makes inliner to update callee keys only in function within
newly inlined clone rather than in the whole function it is inlined to.
This is possible only when the remaining edges are not becoming more hot
for inlining and on this I rely on monotonocity of the badness function:
if cal
On Wed, Nov 20, 2019 at 05:30:48PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote:
> > On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandiford wrote:
> > > Segher Boessenkool writes:
> > > > UNLT & ORDERED is always LT. When would it not be tr
On 11/20/19 7:16 AM, Bernd Schmidt wrote:
> On 11/20/19 2:50 PM, Mikael Pettersson wrote:
>> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson
>> wrote:
>>>
>>> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt
>>> wrote:
Hi Mikael,
> This fixed the problem, thanks.
Cou
Segher Boessenkool writes:
> On Wed, Nov 20, 2019 at 05:30:48PM +0100, Jakub Jelinek wrote:
>> On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote:
>> > On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandiford wrote:
>> > > Segher Boessenkool writes:
>> > > > UNLT & ORDERED is a
On Wed, Nov 20, 2019 at 04:35:24PM +, Richard Sandiford wrote:
> Actually, this doesn't work because *_operators want rtxes rather
> than codes. I can get around that by passing op0 and op1 for
> the existing rtxes. For the conversion at the end, I can do:
>
> machine_mode compared_mode =
On Wed, Nov 20, 2019 at 04:59:49PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Wed, Nov 20, 2019 at 05:30:48PM +0100, Jakub Jelinek wrote:
> >> On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote:
> >> > On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandi
On 11/20/19 8:15 AM, Richard Sandiford wrote:
> bb-slp-40.c fails on SPARC targets without VIS4 because it
> requires addition on vectors of bytes. There doesn't seem to be
> an existing target selector for this, so I added vect_char_add.
> (Wasn't sure whether to use vect_char_add, for consistenc
On 11/20/19 5:46 AM, Richard Sandiford wrote:
> After r278246, we can try building the out[] store value from scalars
> if the target has no multiplication support. That's not necessarily
> a good thing, but like most of vect/, this test is run with the cost
> model disabled.
>
> Tested on aarch6
On 11/20/19 4:02 AM, Martin Liška wrote:
> Hi.
>
> The patch is about removal of an unused libtool-version file,
> and comments in other libtool-version files are legacy.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> I'm going to install the patch if there are no ob
On 20/11/2019 14:29, Martin Liška wrote:
> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>> I have rebased this series onto Martin Liska's patches that take the most
>> recent libhwasan from upstream LLVM.
>> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
>>
>> I've also cleared up some no
On 11/19/19 2:02 AM, Claudiu Zissulescu wrote:
> The patterns neg_scc_insn and not_scc_insn are not correct, leading to
> failing pr77309 test for ARC700. Add two new bic compare with zero
> patterns to improve output code.
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.md
On Wed, 20 Nov 2019, Maciej W. Rozycki wrote:
> > But even then, if you configure GCC using "--with-sysroot" or
> > "--with-build-sysroot", both of those paths are the top-level sysroot, to
> > which the sysroot suffix gets appended before GCC uses it for any purpose,
> > unless you explicitly
On 11/18/19 9:15 AM, Martin Sebor wrote:
> On 11/17/19 12:03 PM, Jeff Law wrote:
>> On 11/12/19 12:55 PM, Martin Sebor wrote:
>>> On 11/12/19 10:54 AM, Jeff Law wrote:
On 11/12/19 1:15 AM, Richard Biener wrote:
> On Tue, Nov 12, 2019 at 6:10 AM Jeff Law wrote:
>>
>> On 11/6/19 3:3
This patch is OK with http changed to https. (That is, with it changed
where the patch is already changing the URL. While changing http to https
makes sense more generally in the documentation whenever a site supports
https, that's probably best not mixed with the move from ftp.)
--
Joseph S
Since r278084 (part of the params refactoring), most of libgccjit's
test suite has been ICEing.
The root cause is that jit-playback.c injects params to its fake_args
here:
/* Aggressively garbage-collect, to shake out bugs: */
if (get_bool_option (GCC_JIT_BOOL_OPTION_SELFCHECK_GC))
{
On 11/19/19 12:42 AM, Richard Biener wrote:
> On Mon, 18 Nov 2019, Jeff Law wrote:
>
>> On 11/18/19 3:37 AM, Richard Biener wrote:
>>> On Mon, 18 Nov 2019, Jakub Jelinek wrote:
>>>
On Mon, Nov 18, 2019 at 11:07:22AM +0100, Richard Biener wrote:
> On Mon, 18 Nov 2019, Jakub Jelinek wrote:
On 19 November 2019 23:54:55 CET, Thomas Koenig wrote:
>Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
>> + char name[GFC_MAX_SYMBOL_LEN + 1];
>> + snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_num++,
>> +f->sym->name);
>> +
>> + if (gfc_get_sym_tr
1 - 100 of 164 matches
Mail list logo
