OS X build fix

2015-08-01 Thread wispym . gcc
System -- MacBook Pro OS X Yosemite Version 10.10.4 XCode Version 6.4 (6E35b) $ clang --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.4.0 Thread model: posix Building gcc-5.2.0 Problems There were two build problems to o

[gomp4] note why 3 is missing

2015-08-01 Thread Nathan Sidwell
I committed this to gomp4 branch to note why device type 3 is missing. Someone's bound to forget ... nathan 2015-08-01 Nathan Sidwell include/ * gomp-constants.h: Note why device 3 is missing. libgomp/ * openacc.h: Note why device 3 is missing. * openacc.f90: Likewise. * openacc_lib.h

Re: offload data version number

2015-08-01 Thread Nathan Sidwell
On 08/01/15 20:06, Nathan Sidwell wrote: ok? I'll commit a version of this to gomp4 branch shortly. this is the gomp4 committed version. nathan 2015-08-01 Nathan Sidwell include/ * gomp-constants.h (GOMP_VERSION_INTEL_MIC): New. libgomp/ * plugin/plugin-nvptx.c (GOMP_OFFLOAD_load_i

Re: offload data version number

2015-08-01 Thread Nathan Sidwell
On 07/31/15 12:10, Jakub Jelinek wrote: This will hopefully be just GOMP_4.1 instead in the end, but it can change when gomp-4_1-branch is merged to trunk, we don't guarantee ABI stability at this point. Sure. I'd prefer version to go after devicep argument rather than before. Fixed. And

Re: [C++/66443] virtual base of abstract class

2015-08-01 Thread Nathan Sidwell
On 07/17/15 15:59, Nathan Sidwell wrote: On 07/17/15 15:42, Jason Merrill wrote: On 07/08/2015 10:50 AM, Nathan Sidwell wrote: On 06/30/15 19:21, Nathan Sidwell wrote: On 06/30/15 00:19, Jason Merrill wrote: On 06/29/2015 06:57 PM, Nathan Sidwell wrote: * method.c (synthesized_method_wal

[google][gcc-4.9][committed] Add inexpensive bounds checks to std::array

2015-08-01 Thread Paul Pluzhnikov
Greetings, For google b/9650176, attached patch adds bounds checks to std::array and updates expected line numbers in tests. This is similar to the checks that we do for std::vector. See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109 Committed as r226465. Thanks, -- Paul Pluzhnikov In

Re: [PATCH], PowerPC IEEE 128-bit patch #4c (revised)

2015-08-01 Thread David Edelsohn
On Thu, Jul 30, 2015 at 3:23 PM, Michael Meissner wrote: > Seger pointed out that the altivec_high_bit insn was not safe if it was called > when it could not allocate pseudos. I have removed that insn in this patch. I > will revise the patch. I had meant to tie it in with easy_altivec_constant >

RE: [PATCH, MIPS, Ping] Inline memcpy for MipsR6

2015-08-01 Thread Moore, Catherine
> -Original Message- > From: Simon Dardis [mailto:simon.dar...@imgtec.com] > Sent: Wednesday, July 29, 2015 4:29 AM > To: gcc-patches@gcc.gnu.org > Cc: Moore, Catherine > Subject: [PATCH, MIPS, Ping] Inline memcpy for MipsR6 > > > This patch enables inline memcpy for R6 which was previou

[Patch, fortran] PR67091 - Bad result for type-bound procedures returning pointers to the intrinsic function ASSOCIATED

2015-08-01 Thread Paul Richard Thomas
Dear All, I have committed a patch for this PR as revision 226464, since it is utterly trivial and obvious. I will wait a few days before committing it to 5 branch. Cheers Paul 2015-08-01 Paul Thomas PR fortran/67091 * trans-intrinsic.c (gfc_conv_associated): Add the pre and post

Re: Patch for fortran/62536 and fortran/66175

2015-08-01 Thread FX
> No, I don't, but I would be happy to assign copyright. How do I do that? I've > read this: https://www.fsf.org/licensing/assigning.html > and it says I should "email the maintainer of the program communicating [my] > desire to assign copyright.” As I understand it, you need to fill this form:

Re: Use cmpstr and cmpstrn optabs

2015-08-01 Thread Kaz Kojima
Richard Sandiford wrote: > This patch converts the code to do everything via the optabs interface. > This required a change to the sh.md cmpstrn pattern, where the length > predicate was "immediate_operand" but where the expander code wanted > to handle nonimmediates too. I also removed the now-r

Re: Patch for fortran/62536 and fortran/66175

2015-08-01 Thread FX
> This patch cleans up nested blocks when there's an unexpected end of a > compilation unit (66175), and it handles cleaned-up blocks gracefully > (62536). I've run "make check-fortran" with the attached test cases. The patch is OK. But the question I missed in my earlier email was: do you hav