On 29 November 2016 at 17:49, Christophe Lyon
wrote:
> On 29 November 2016 at 17:33, Aldy Hernandez wrote:
>> This fixes the gcc.dg/uninit-pred-6* failures I seem to have caused on some
>> non x86 platforms. Sorry for the delay.
>>
>> The problem is that my fix for PR61409 had the logic backwards
On Tue, Nov 29, 2016 at 02:14:17PM -0500, Michael Meissner wrote:
> I was developing the next round of ISA 3.0 code changes to use the vector
> extract byte, half word, and word instructions (VEXTU{B,H,W}{R,L}X) that
> deposit the value into a general purpose register instead of a vector
> registe
On Tue, Nov 29, 2016 at 2:08 PM, David Malcolm wrote:
>
> gcc/ChangeLog:
> PR c/78498
> * selftest.c (selftest::assert_strndup_eq): New function.
> (selftest::test_strndup): New function.
> (selftest::test_libiberty): New function.
> (selftest::selftest_c_te
Hi all,
here is a rather straightforward patch for an ice-on-invalid
regression. Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-11-29 Janus Weil
PR fortran/78573
* decl.c (build_struct): On error, return directly and do not build
class symbol.
2016-11-2
On 11/29/2016 01:04 AM, Christophe Lyon wrote:
On 29 November 2016 at 03:59, Martin Sebor wrote:
On 11/28/2016 06:35 PM, David Edelsohn wrote:
Martin,
I am seeing a number of new failures with the testcases on AIX.
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
Exc
2016-11-29 Max Filippov
gcc/
* config/xtensa/xtensa.c (hwloop_optimize): Don't emit zero
overhead loop start between a call and its CALL_ARG_LOCATION
note.
---
gcc/config/xtensa/xtensa.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/config/x
On 11/15/2016 09:04 AM, Richard Sandiford wrote:
alias.c encodes memory sizes as follows:
size > 0: the exact size is known
size == 0: the size isn't known
size < 0: the exact size of the reference itself is known,
but the address has been aligned via AND. In this case
"-size" includes the
On Tue, Nov 29, 2016 at 2:08 PM, Max Filippov wrote:
> 2016-11-29 Max Filippov
> gcc/
> * config/xtensa/xtensa.c (hwloop_optimize): Don't emit zero
> overhead loop start between a call and its CALL_ARG_LOCATION
> note.
Approved. Please apply.
On 11/29/2016 12:41 PM, Jakub Jelinek wrote:
Hi!
The x86_64 stv pass uses PUT_MODE to change REGs and MEMs in place to affect
all setters and users, but that is undesirable in debug insns which are
intentionally ignored during the analysis and we should keep using correct
modes (TImode) instead
On Tue, Nov 29, 2016 at 10:58:35PM +0100, Janus Weil wrote:
>
> here is a rather straightforward patch for an ice-on-invalid
> regression. Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>
Yes.
--
Steve
On Tue, Nov 29, 2016 at 03:20:08PM -0700, Jeff Law wrote:
> On 11/29/2016 12:41 PM, Jakub Jelinek wrote:
> >The x86_64 stv pass uses PUT_MODE to change REGs and MEMs in place to affect
> >all setters and users, but that is undesirable in debug insns which are
> >intentionally ignored during the ana
On Tue, Nov 29, 2016 at 2:16 PM, augustine.sterl...@gmail.com
wrote:
> On Tue, Nov 29, 2016 at 2:08 PM, Max Filippov wrote:
>> 2016-11-29 Max Filippov
>> gcc/
>> * config/xtensa/xtensa.c (hwloop_optimize): Don't emit zero
>> overhead loop start between a call and its CALL_ARG_L
Jeff Law writes:
> On 11/15/2016 09:04 AM, Richard Sandiford wrote:
>> alias.c encodes memory sizes as follows:
>>
>> size > 0: the exact size is known
>> size == 0: the size isn't known
>> size < 0: the exact size of the reference itself is known,
>> but the address has been aligned via AND. I
On 11/29/2016 03:51 PM, Richard Sandiford wrote:
Jeff Law writes:
On 11/15/2016 09:04 AM, Richard Sandiford wrote:
alias.c encodes memory sizes as follows:
size > 0: the exact size is known
size == 0: the size isn't known
size < 0: the exact size of the reference itself is known,
but the ad
On 11/28/2016 10:33 AM, Andre Vehreschild wrote:
PING!
I know it's a lengthy patch, but comments would be nice anyway.
- Andre
On Tue, 22 Nov 2016 20:46:50 +0100
Andre Vehreschild wrote:
Hi all,
attached patch addresses the need of extending the API of the caf-libs to
enable allocatable co
Hi Jerry,
Tests with multiple images go into the opencoarrays testsuite. Still to push
though. The tests I have so far all pass.
- Andre
Am 30. November 2016 00:06:22 MEZ, schrieb Jerry DeLisle
:
>On 11/28/2016 10:33 AM, Andre Vehreschild wrote:
>> PING!
>>
>> I know it's a lengthy patch, but
On 11/29/2016 12:48 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, the LSHIFT_EXPR computation of values that
will need longest or shortest string is both incorrect (it shifts
integer_one_node left, so for precisions above precision of integer
it returns 0 (not to mention that it is invali
On Tue, 2016-11-29 at 14:23 -0700, Jeff Law wrote:
> On 11/21/2016 04:23 PM, Matthias Klose wrote:
> > On 21.11.2016 18:16, Rainer Orth wrote:
> > > Hi Matthias,
> > >
> > > > ahh, didn't see that :-/ Now fixed, is this clearer now?
> > > >
> > > > The options @option{--with-target-bdw-gc-include
The ICE in PR preprocessor/78569 appears to be due to an attempt to
generate substring locations in a .i file where the underlying .c file
has changed since the .i file was generated.
This can't work, so it seems safest for the on-demand substring
locations to be unavailable for such files, fallin
On 11/29/2016 06:10 PM, David Malcolm wrote:
[snip]
r242985 seems to have broken the build, for me at least (with texinfo
5.1):
../../src/gcc/doc/install.texi:2199: use braces to give a command as an
argument to @=
make[2]: *** [doc/gccinstall.info] Error 1
The attached patch fixes it.
OK to
On Tue, 2016-11-29 at 18:20 -0700, Sandra Loosemore wrote:
> On 11/29/2016 06:10 PM, David Malcolm wrote:
> > [snip]
> >
> > r242985 seems to have broken the build, for me at least (with
> > texinfo
> > 5.1):
> >
> > ../../src/gcc/doc/install.texi:2199: use braces to give a command
> > as an argu
On 11/18/2016 03:24 AM, Jakub Jelinek wrote:
> On Sat, Nov 12, 2016 at 08:51:00AM -0800, Cesar Philippidis wrote:
>> On 11/11/2016 02:34 AM, Jakub Jelinek wrote:
>>> On Thu, Nov 10, 2016 at 06:46:46PM +0800, Chung-Lin Tang wrote:
>>
>> And here's the patch.
>
> The patch doesn't look like OpenACC
On 11/29/2016 12:48 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, the LSHIFT_EXPR computation of values that
will need longest or shortest string is both incorrect (it shifts
integer_one_node left, so for precisions above precision of integer
it returns 0 (not to mention that it is invali
This patch to libgo fixes a couple of problems that arise when
building Go code into an archive or shared library that is linked into
a C program.
In archive mode, initsig is called before the memory allocator has
been initialized. The code was doing a memory allocation because of
the call to fun
Hi Jeff,
>> I believe Richi asked for a small change after which you can consider
>> the patch approved:
Yeah. Thanks for all the comments and reviews.
Patch committed after the modification as:-
https://gcc.gnu.org/ml/gcc-cvs/2016-11/msg01019.html
Thanks,
Naveen
On 11/29/2016 03:44 AM, Martin Liška wrote:
Currently we an assert that prevents proper use-after-scope sanitization
in nested functions. With the attached patch, we are able to do so.
I'm adding 2 test-cases, first one is the ICE reported in PR and the second
one tests proper report of use-after
That said, I defer to you on how to proceed here. I'm prepared
to do the work(*) but I do worry about jeopardizing the chances
of this patch and the others making it into 7.0.
So would it make sense to just init/fini the b_o_s framework in your
pass and for builtin expansion?
I think that shou
On 11/26/2016 05:52 PM, Martin Sebor wrote:
On 11/25/2016 12:51 PM, Jeff Law wrote:
On 11/23/2016 06:15 PM, Martin Sebor wrote:
gcc_assert works only in some instances (e.g., in c-ada-spec.c:191)
but not in others because some actually do make the alloca(0) call
at runtime: at a minimum, lto.c
On 11/19/2016 02:04 PM, Martin Sebor wrote:
On 10/26/2016 02:46 PM, Joseph Myers wrote:
On Wed, 26 Oct 2016, Martin Sebor wrote:
The attached patch implements one such approach by having the pretty
printer recognize the space format flag to suppress the type suffix,
so "%E" still prints the su
On 11/02/2016 01:20 PM, Bernd Schmidt wrote:
On 10/29/2016 06:21 PM, Jeff Law wrote:
On a small number of ports, we only have 2 defined register classes.
NO_REGS and ALL_REGS. Examples would include nvptx and vax.
So let's look at check_and_process_move from lra-constraints.c:
sclass = dcl
There's a couple unused variables in arc_handle_option. This patch
removes them. Verified the arc port builds again.
Installed on the trunk.
Jeff
commit 0177a97d002107d99f82be0861ac0052285ccc0a
Author: law
Date: Wed Nov 30 04:37:10 2016 +
* common/config/arc/arc-common.c
This patch checks for negative character length in the array constructor,
and treats it as LEN=0. A warning message is also printed if bounds checking is
enabled.
Bootstrapped and regression tested the patch on x86_64-linux-gnu and
aarch64-linux-gnu.
Index: ChangeLog
===
Please excuse the messy formatting in my initial mail. Resending with proper
formatting.
This patch checks for negative character length in the array constructor, and
treats it as LEN=0.
A warning message is also printed if bounds checking is enabled.
Bootstrapped and regression tested the pa
Now I've merged GCC trunk revision 242992 to the gccgo branch.
Ian
On Tue, Nov 29, 2016 at 1:09 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> This ICE only occurs on big-endian ILP32 -fpie code. The expansion code
> generates the invalid load:
> (insn 6 5 7 (set (reg/f:SI 76)
> (unspec:SI [
> (mem/u/c:SI (lo_sum:SI (nil)
>
These two patches to fix PRs 78602 and 78560 fix aspects of the vector set and
extract code I've been working on in the last couple of months.
The two symptoms were essentially the same thing, one on vector set and the
other on vector extract. The core issue was both set and extract did not
verif
On Tuesday 29 November 2016 10:06 PM, Denis Chertykov wrote:
2016-11-28 10:17 GMT+03:00 Pitchumani Sivanupandi
:
On Saturday 26 November 2016 12:11 AM, Denis Chertykov wrote:
I'm sorry for delay.
I have a problem with the patch:
(Stripping trailing CRs from patch; use --binary to disable.)
pat
Dear Andre,
This all looks OK to me. The only comment that I have that you might
deal with before committing is that some of the Boolean expressions,
eg:
+ int caf_dereg_mode
+ = ((caf_mode & GFC_STRUCTURE_CAF_MODE_IN_COARRAY) != 0
+ || c->attr.codimension)
+ ?
On Tue, Nov 29, 2016 at 8:44 PM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs because DECL_RTL/DECL_INCOMING_RTL are adjusted
> by the stv pass through the PUT_MODE modifications, which means that for
> var-tracking.c they contain a bogus mode.
>
> Fixed by wrapping those into TImode
Hello world,
the patch at https://gcc.gnu.org/ml/fortran/2016-11/msg00246.html
(the one going to gcc-patches was rejected due to size of
regernerated files) contains one libgcc change, which exposes
the __cpu_model interface fox i386 to libgfortran.
The Fortran bits are OKd, but I need an approv
2016-11-29 23:21 GMT+01:00 Steve Kargl :
> On Tue, Nov 29, 2016 at 10:58:35PM +0100, Janus Weil wrote:
>>
>> here is a rather straightforward patch for an ice-on-invalid
>> regression. Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>
>
> Yes.
Thanks, Steve. Committed as r242996.
Cheers,
Jan
On 2016.11.29 at 15:25 -0600, Segher Boessenkool wrote:
> On Tue, Nov 29, 2016 at 05:00:05PM +0100, Markus Trippelsdorf wrote:
> > Building gcc with -fsanitize=undefined shows:
> > rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too large
> > for 64-bit type 'long unsigned int'
> >
> the patch at https://gcc.gnu.org/ml/fortran/2016-11/msg00246.html
> (the one going to gcc-patches was rejected due to size of
> regernerated files) contains one libgcc change, which exposes
> the __cpu_model interface fox i386 to libgfortran.
>
> The Fortran bits are OKd, but I need an approval f
101 - 143 of 143 matches
Mail list logo
