Re: [PATCH] fortran/66052 -- Prevent dereference of NULL pointer

On Sat, May 16, 2015 at 01:58:30PM +0200, Mikael Morin wrote: > > Index: gcc/fortran/decl.c > > === > > --- gcc/fortran/decl.c (revision 223094) > > +++ gcc/fortran/decl.c (working copy) > > @@ -6968,7 +6968,8 @@ gfc_match_pr

Re: [PATCH] fortran/66057 -- detect malformed GENERIC statement

On Fri, May 15, 2015 at 10:37:24PM +0200, FX wrote: > Does it also catch the other cases shown in the PR? Things like: > > generic :: 2 > generic :: 2 = > generic :: 1 => x > generic :: ? > Yes, the patch appears to catch those as well. -- Steve

[match-and-simplify] report error for invalid operator-lists

Hi, genmatch segfaults on: (define_operator_list op (plus)) The above syntax is invalid, and it segfaults on: fatal_error (token, "operator list is empty"); because token is NULL. The patch puts a check for CPP_CLOSE_PAREN after parsing id-list. OK for trunk after bootstrap+testing completes ? T

Re: [PATCH/libiberty] fix build of gdb/binutils with clang.

Yes, the problem is libiberty is compiling some files with _GNU_SOURCE defined and some not. So the configure file does not include "#define _GNU_SOURCE". I have reduced the failing compiling as below. #define _GNU_SOURCE (1) #define ATTRIBUTE_NONNULL(m) __at

Re: [PATCH/libiberty] fix build of gdb/binutils with clang.

On Mon, May 18, 2015 at 4:26 PM, Yunlian Jiang wrote: > > Yes, the problem is libiberty is compiling some files > with _GNU_SOURCE defined and some not. So the configure > file does not include "#define _GNU_SOURCE". As far as I can see it should be fine to define _GNU_SOURCE when compiling all

Re: [match-and-simplify] fix incorrect code-gen in 'for' pattern

On 18 May 2015 at 20:17, Prathamesh Kulkarni wrote: > On 18 May 2015 at 14:12, Richard Biener wrote: >> On Sat, 16 May 2015, Prathamesh Kulkarni wrote: >> >>> Hi, >>> genmatch generates incorrect code for following (artificial) pattern: >>> >>> (for op (plus) >>> op2 (op) >>> (simplify >>

[PATCH, RS6000] gpc_reg_operand

gpc_reg_operand contains a test that dates back to the early 1990s, when FIRST_PSEUDO_REGISTER was 76. At that point, testing REGNO (op) >= ARG_POINTER_REGNUM allowed ap, xer/ca, cr0..cr7 and pseudos. A later patch corrected this to remove xer. Nowadays we have a lot more hard registers, altivec

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

On Tue, 19 May 2015, Magnus Granberg wrote: > > > noted a > > > possible issue with MIPS. Actually, rather more config/*.h and > > > config/*/*.h headers contain specs testing for (-fpie, -fPIE, -fno-pie, > > > -fno-PIE, -pie) options, wh

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

On Mon, May 18, 2015 at 6:11 PM, Joseph Myers wrote: > On Tue, 19 May 2015, Magnus Granberg wrote: > >> > > noted a >> > > possible issue with MIPS. Actually, rather more config/*.h and >> > > config/*/*.h headers contain specs testing fo

Re: [PATCH, RS6000] gpc_reg_operand

On Mon, May 18, 2015 at 9:09 PM, Alan Modra wrote: > gpc_reg_operand contains a test that dates back to the early 1990s, > when FIRST_PSEUDO_REGISTER was 76. At that point, testing > REGNO (op) >= ARG_POINTER_REGNUM allowed ap, xer/ca, cr0..cr7 and > pseudos. A later patch corrected this to remo

Re: [PATCH] add self-tuning to x86 hardware fast path in libitm

On Mon, May 18, 2015 at 5:29 PM, Torvald Riegel wrote: > > First of all, sorry for taking so long to review this. Thank you for > the contribution. Hello Torvald, thanks for taking the time to look into this! > My major concern is about rdtsc being used. The relation to frequency > adaption

Re: [PATCH] Refactoring: use std::swap instead of manual swaps

On 19.05.2015 0:39, Jeff Law wrote: > Did you mean to lose the assignment to heapa->m_nodes in fibonacci_heap.h? > > I just spot-checked and it looks fine to me, except for perhaps losing > the assignment noted above. > > jeff Oops. Fixed that and committed to trunk (just in case, I re-ran tests

Fwd: Re: [PATCH, RFC]: Next stage1, refactoring: propagating rtx subclasses

It seems rather weird to me: I have definitely sent this message, but now I realized that it did not get to the mailing list archive (and it was not bounced either). Thus, resending. On 12.05.2015 23:10, Jeff Law wrote: > There's a makefile fragment in contrib which will build a large number > of

Ref: Package with Reg #: BK272062313GDM..

Good Day, Your package arrived successfully. Awaiting your reply for onward delivery. Sincerely, Mr. Rowland Dewey (Cargo Unit Director)

[PATCH] S390: SUpport -mtune=native and -march=native.

The attached patch activates the -mtune=native and -march=native command line options on S390 and System z. Most of the code is a modified copy of gcc/config/mips/driver-native.c. ChangeLog attached. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany gcc/ChangeLog: 2015-05-05 Dominik Vogt

[RFC] COMDAT Safe Module Level Multi versioning

We have the following problem with selectively compiling modules with -m options and I have provided a solution to solve this. I would like to hear what you think. Multi versioning at module granularity is done by compiling a subset of modules with advanced ISA instructions, supported on later ge

Re: [PATCH] fortran/66057 -- detect malformed GENERIC statement

> Yes, the patch appears to catch those as well. Then: OK to commit. Thanks! FX

Re: [PATCH] move check-gcc parallelize value into C front end

On 05/17/2015 09:42 PM, Jim Wilson wrote: Every check_$lang_parallelize setting is in the language specific Make-lang.in file except for the C front-end check_gcc_parallelize setting which is in the toplevel Makefile.in file. This seems to be an oversight, as it was only 3 years ago that the c/

Re: [PATCH] Fix memory orders description in atomic ops built-ins docs.

On 05/15/2015 10:22 AM, Torvald Riegel wrote: This patch improves the documentation of the built-ins for atomic operations. First, to be consistent with the C++11 standard and make it easier for users to relate the built-ins to the C++11 specification, the patch changes 'memory model' to 'memory

Re: Improve error message for vector conversion

On 05/15/2015 03:59 AM, Marc Glisse wrote: Hello, this patch was regtested on ppc64le-redhat-linux. 2015-05-15 Marc Glisse gcc/ * convert.c (convert_to_integer, convert_to_vector): Include the types in the error message. gcc/testsuite/ * gcc.dg/simd-1.c: Update to the new mes

Re: [2/9] Add a REG_NREGS macro

Jeff Law writes: > On 05/18/2015 12:13 PM, Richard Sandiford wrote: >> This patch adds a REG_NREGS macro that by the end of the series >> will simply be an rtx field access. The definition in this patch >> is just a placeholder (and so I haven't tried to avoid the double >> evaluation of the para

<    1   2