On 12/02/2015 04:09 PM, Nathan Sidwell wrote:
+/* Output a pattern for a move instruction. */
+
+const char *
+nvptx_output_mov_insn (rtx dst, rtx src)
+{
+ machine_mode dst_mode = GET_MODE (dst);
+ machine_mode dst_inner = (GET_CODE (dst) == SUBREG
+ ? GET_MODE (XEXP
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Fri, 19 May 2017 21:28:25 -0400
>
>
> Please try this patch, since my mingw environment is old:
>
> Index: libiberty/ChangeLog
> ===
> --- libiber
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/gcc/da.po
(This file, 'gcc-7.1.0.da.po', has just
Hi all,
the attached patch fixes an ICE-on-valid regression by making sure
that the relevant vtype symbol is resolved properly (for further
discussion see the PR).
The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk and 7-branch?
Cheers,
Janus
2017-05-21 Janus Weil
PR fortran/
Hello,
generalizing a bit one transformation, to avoid a regression with another
patch I am working on. Handling conversions always gets messy :-( It would
have been easier to stick to scalars and wide_int, but since the existing
transformation handles vectors, I didn't want to regress.
Boot
Hello,
when we have a double*p, computing p+n, we multiply n by 8 (size of
double) then add it to p. According to the comment just below the modified
lines in the attached patch, the multiplication is supposed to happen in a
signed type. However, that does not match the current code which uses
Hello,
SRA uses char when scalarizing bool, and we end up with
_6 = u_1(D) == 0.0;
_7 = (unsigned char) _6;
_3 = VIEW_CONVERT_EXPR<_Bool>(_7);
which we currently do not simplify. I am not completely sure what happens
with types whose precision does not cover their size, I hope this is sa
On 05/21/2017 09:14 AM, Janus Weil wrote:
Hi all,
the attached patch fixes an ICE-on-valid regression by making sure
that the relevant vtype symbol is resolved properly (for further
discussion see the PR).
The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk and 7-branch?
Cheers,
Janus
On 05/19/2017 03:42 PM, Jason Merrill wrote:
On Fri, May 19, 2017 at 4:07 PM, Martin Sebor wrote:
On 05/19/2017 01:07 PM, Jason Merrill wrote:
On Tue, May 16, 2017 at 5:39 PM, Martin Sebor wrote:
On 05/16/2017 01:41 PM, Jason Merrill wrote:
I'm still not convinced we need to consider sta
On 05/18/2017 02:58 PM, Segher Boessenkool wrote:
> The function bb_is_just_return finds if the BB it is asked about does
> just a return and nothing else. It currently does not allow clobbers
> in the block either, which we of course can allow just fine.
>
> This patch changes that. Bootstrappe
On Sat, Apr 22, 2017 at 4:46 PM, James Abbatiello wrote:
> This is my first time attempting a contribution here so please point
> out any mistakes. I've tested this on x86_64-pc-linux-gnu in a VM.
Hello,
It has been a few weeks. Can anybody give me some feedback here or
tell me if I've done so
On 05/18/2017 12:55 PM, Prathamesh Kulkarni wrote:
> Hi,
> The attached patch tries to fix PR80806 by warning when a variable is
> set using memset (and friends) but not used. I chose to warn in dse
> pass since dse would detect if the variable passed as 1st argument is
> a dead store. Does this ap
On Sun, May 21, 2017 at 7:59 PM, Martin Sebor wrote:
> On 05/19/2017 03:42 PM, Jason Merrill wrote:
>> On Fri, May 19, 2017 at 4:07 PM, Martin Sebor wrote:
>>> On 05/19/2017 01:07 PM, Jason Merrill wrote:
On Tue, May 16, 2017 at 5:39 PM, Martin Sebor wrote:
> On 05/16/2017 01:41 PM, Jas
> The gcc source tree is as desired, but I may have made
> 2 inadvertent process mistakes:
> * did not send a revised PATCH to gcc-patches
That's OK since only a minor correction was requested.
> * made the 4 changes with 1 commit
That's as expected.
--
Eric Botcazou
14 matches
Mail list logo
