Hi all,
On Thu, Jul 09, 2020 at 10:29:44AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jul 09, 2020 at 09:17:46AM +0100, Richard Sandiford wrote:
> > If target-independent code is going to optimise for “no subreg operand”
> > targets like nvptx, I think it needs to know that the target w
The range infrastructure has code to decompose POLY_INT_CST ranges
to worst-case integer bounds. However, it had the fundamental flaw
(obvious in hindsight) that it applied to anti-ranges too, meaning
that a range 2+2X would end up with a range of ~[2, +INF], i.e.
[-INF, 1]. This patch decays to
Hi Aaron,
On Fri, Jul 10, 2020 at 05:58:59PM -0500, Aaron Sawdey via Gcc-patches wrote:
> Add a test for dejagnu to determine if execution of MMA instructions is
> supported in the test environment. Add an execution test to make sure
> that __builtin_cpu_supports("mma") is true if we can execute M
Jan Hubicka writes:
>> Jan Hubicka writes:
>> >> The testcase has failed since r9-5035, because obj_type_ref_class
>> >> tries to look up an ODR type when no ODR type information is
>> >> available. (The information was available earlier in the
>> >> compilation, but was freed during pass_ipa_fr
Dmitrij Pochepko writes:
> Hi,
>
> please take a look at updated version (attached).
Looks good, but a couple more points, sorry:
> + /* Convert the perm constant if we can. Require even, odd as the pairs.
> */
> + for (unsigned int i = 0; i < nelt; i += 2)
> +{
> + poly_int64 elt0
Dmitrij Pochepko writes:
> Hi,
>
> thank you for reviewing it.
>
> Please check updated version(attached) with all comments addressed.
>
> Thanks,
> Dmitrij
>
> On Tue, Jun 23, 2020 at 06:10:52PM +0100, Richard Sandiford wrote:
> ...
>>
>> I think it would be better to test this as part of the lo
On July 11, 2020 10:01:41 AM GMT+02:00, Richard Sandiford
wrote:
>The range infrastructure has code to decompose POLY_INT_CST ranges
>to worst-case integer bounds. However, it had the fundamental flaw
>(obvious in hindsight) that it applied to anti-ranges too, meaning
>that a range 2+2X would en
Iain-san,
I have not heard (or do not find) any news for one year after your reply 500657.
I have just tried my patch for gcc 10.1.0 release and the patch just
worked, which is unexpected for me...
How is your patch going?
T. Yamada
> On Tue, 14 May 2019 at 17:05, ciel wrote:
> >
> > Dear GCC
On 7/8/20 4:35 PM, Marek Polacek wrote:
On Fri, Jul 03, 2020 at 05:24:34PM -0400, Jason Merrill via Gcc-patches wrote:
On 6/22/20 10:09 PM, Marek Polacek wrote:
convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
Hello world,
I have just committed the attached patch to master as obvious and
simple. Explanation is in the ChangeLog below.
Best regards
Thomas
Fix ICE on warning with new interface check (the patch for PR 27318).
In the test case, there was a warning about INTENT where an EXTERNAL
This patch eliminates a check of targetm.truly_noop_truncation from
the early middle-end, where the gimple/generic being generated by
GCC's front-ends is being inappropriately influenced by the target's
TRULY_NOOP_TRUNCATION. The (recent) intention of TRULY_NOOP_TRUNCATION
is to indicate that a b
The following patch adds support for 16-bits shifts and for sign extension
from 8 bits to 16 bits.
This patch has been tested on nvptx-none with no new regressions.
Ok for mainline?
2020-07-11 Roger Sayle
gcc/ChangeLog
* config/nvptx/nvptx.md (extendqihi2): New instruction.
(a
The Go frontend miscompiled some cases where a program defined an
alias to a pointer type, and then tried to convert that type to an
interface type, or build a method table for that type. This patch
fixes those problems. The test case is https://golang.org/cl/241997.
Bootstrapped and ran Go tests
This patch to the Go frontend avoids generating a type descriptor for
the unnamed abstract boolean type. We were generating it in cases
where a boolean expression was converted directly to an empty
interface type, which caused equality comparisons to fail. This patch
adds a check that we never ge
This patch adds function definition described in the section 5.5.6 of
the OpenMP API Specificiation 5.0. It also partially defines some of the
handler data types related to the section.
2020-07-11 Tony Sim
libgomp/ChangeLog:
* libgompd.h (ompd_thread_handle_t): Add.
(ompd_para
Even by my standards, this is an odd patch. This adds expanders to
i386.md requesting that integer truncations be represented in RTL
using SUBREGs. This exactly matches the (current) default behaviour
when TARGET_TRULY_NOOP_TRUNCATION is undefined. Hence this patch
is mostly for documentation/
Doh! With the attachment.
-Original Message-
From: Roger Sayle
Sent: 12 July 2020 00:29
To: 'gcc-patches@gcc.gnu.org'
Subject: [PATCH] x86: Provide expanders for truncdisi2 and friends.
Even by my standards, this is an odd patch. This adds expanders to i386.md
requesting that integ
>From 589dbe8a1c2397bfafefa4e84abe5ec6e6798928 Mon Sep 17 00:00:00 2001
From: Andrew Pinski
Date: Wed, 12 Feb 2020 11:42:57 +
Subject: [PATCH] MIPS: Fix __builtin_longjmp (PR 64242)
The problem here is mips has its own builtin_longjmp
pattern and it was not fixed when expand_builtin_longjmp
w
18 matches
Mail list logo
