Re: [patch] [java] bump libgcj soname

- Original Message - > On Tue, Apr 21, 2015 at 01:04:04PM -0400, Andrew Hughes wrote: > > - Original Message - > > > On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: > > > > bump the libgcj soname on the trunk, as done for every release cycle, > > > > > > Is that rea

Re: [PATCH][expr.c] PR 65358 Avoid clobbering partial argument during sibcall

On 21/04/15 15:09, Jeff Law wrote: On 04/21/2015 02:30 AM, Kyrill Tkachov wrote: From reading config/stormy16/stormy-abi it seems to me that we don't pass arguments partially in stormy16, so this code would never be called there. That leaves pa as the potential problematic target. I don't sup

[PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

New patch, v3. PTAL. Regards, Petar gcc/ChangeLog: 2015-04-21 Petar Jovanovic * config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Fix the macro to use la/jalr instead of jal. gcc/testsuite/ChangeLog: 2015-04-21 Petar Jovanovic * gcc.target/mips/call-from-init.c: Ne

Re: [RFC] Dynamically aligning the stack

On Tue, Apr 21, 2015 at 9:52 AM, Steve Ellcey wrote: > On Tue, 2015-04-14 at 10:08 -0700, H.J. Lu wrote: > >> We have done just that in GCC 4.4 to implement dynamic stack >> alignment on x86 :-). Some of x86 backend changes for dynamic >> stack alignment are x86 psABI specific. Others are histor

[patch, libgfortran] PR65234 Output descriptor (*(1E15.7)) not accepted

I have had this simple patch in my trunk for quite some time and it has tested OK. I plan to commit with a test case based on the one in the PR today. Regards, Jerry 2015-04-21 Jerry DeLisle PR libgfortran/65234 * io/format.c (parse_format_list): Set the seen_dd flag in all

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

-Original Message- From: Moore, Catherine [mailto:catherine_mo...@mentor.com] Sent: Friday, April 17, 2015 8:36 PM To: Petar Jovanovic Cc: Maciej W. Rozycki; Matthew Fortune; gcc-patches@gcc.gnu.org Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro > > Hi Petar, > Running

Re: Re: [RFC stage 1] Proposed new warning: -Wmisleading-indentation

On 21/04/15 18:07, David Malcolm wrote: I have the patch working now for the C++ frontend. Am attaching the work-in-progress (sans ChangeLog). This one (v2) bootstrapped and regrtested on x86_64-unknown-linux-gnu (Fedora 20), with: 63 new "PASS" results in gcc.sum 189 new "PASS" results

Re: [PATCH, fortran] Add gfc_define_builtin_with_spec

Hi! On Fri, 9 Jan 2015 16:37:00 +0100, Tom de Vries wrote: > For the oacc kernels patch series I need a fortran builtin with fn spec > attribute (as mentioned here: > https://gcc.gnu.org/ml/gcc/2014-12/msg1.html ). > > Attached patch adds a function gfc_define_builtin_with_spec that allows

Re: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

On Tue, 21 Apr 2015, Petar Jovanovic wrote: > --- /dev/null > +++ b/gcc/testsuite/gcc.target/mips/call-from-init.c > @@ -0,0 +1,10 @@ > +/* Check that __do_global_ctors_aux can be reached from .init section that > + is in a different (256MB) region. */ > +/* { dg-do run } */ > +/* { dg-options "

Add BUILT_IN_GOACC_KERNELS_INTERNAL (was: openacc kernels directive -- initial support)

Hi! On Sat, 15 Nov 2014 13:14:52 +0100, Tom de Vries wrote: > I'm submitting a patch series with initial support for the oacc kernels > directive. > > The patch series uses pass_parallelize_loops to implement parallelization of > loops in the oacc kernels region. Committed to gomp-4_0-branch

Expand oacc kernels after pass_fre (was: [PATCH, 1/8] Expand oacc kernels after pass_build_ealias)

Hi! On Tue, 25 Nov 2014 12:22:02 +0100, Tom de Vries wrote: > On 24-11-14 11:56, Tom de Vries wrote: > > On 15-11-14 18:19, Tom de Vries wrote: > >> On 15-11-14 13:14, Tom de Vries wrote: > >>> I'm submitting a patch series with initial support for the oacc kernels > >>> directive. > >>> > >>> Th

Re: [PATCH, 2/8] Add pass_oacc_kernels

Hi! On Tue, 25 Nov 2014 12:25:35 +0100, Tom de Vries wrote: > On 15-11-14 18:20, Tom de Vries wrote: > > On 15-11-14 13:14, Tom de Vries wrote: > >> I'm submitting a patch series with initial support for the oacc kernels > >> directive. > >> > >> The patch series uses pass_parallelize_loops to im

Re: [PATCH, 3/8] Add pass_ch_oacc_kernels to pass_oacc_kernels

Hi! On Tue, 25 Nov 2014 12:27:34 +0100, Tom de Vries wrote: > On 15-11-14 18:21, Tom de Vries wrote: > > On 15-11-14 13:14, Tom de Vries wrote: > >> Hi, > >> > >> I'm submitting a patch series with initial support for the oacc kernels > >> directive. > >> > >> The patch series uses pass_paralleli

Re: [PATCH, 4/8] Add pass_tree_loop_{init,done} to pass_oacc_kernels

Hi! On Tue, 25 Nov 2014 12:29:28 +0100, Tom de Vries wrote: > On 15-11-14 18:21, Tom de Vries wrote: > > On 15-11-14 13:14, Tom de Vries wrote: > >> I'm submitting a patch series with initial support for the oacc kernels > >> directive. > >> > >> The patch series uses pass_parallelize_loops to im

Re: [PATCH, 5/8] Add pass_lim to pass_oacc_kernels

Hi! On Tue, 25 Nov 2014 12:30:52 +0100, Tom de Vries wrote: > On 15-11-14 18:22, Tom de Vries wrote: > > On 15-11-14 13:14, Tom de Vries wrote: > >> I'm submitting a patch series with initial support for the oacc kernels > >> directive. > >> > >> The patch series uses pass_parallelize_loops to im

Re: [PATCH, 6/8] Add pass_copy_prop in pass_oacc_kernels

Hi! On Tue, 25 Nov 2014 12:38:55 +0100, Tom de Vries wrote: > On 15-11-14 18:22, Tom de Vries wrote: > > On 15-11-14 13:14, Tom de Vries wrote: > >> I'm submitting a patch series with initial support for the oacc kernels > >> directive. > >> > >> The patch series uses pass_parallelize_loops to im

Re: [PATCH, 7/8] Add pass_parallelize_loops_oacc_kernels to pass_oacc_kernels

Hi! On Tue, 25 Nov 2014 12:42:28 +0100, Tom de Vries wrote: > On 15-11-14 18:23, Tom de Vries wrote: > > On 15-11-14 13:14, Tom de Vries wrote: > >> I'm submitting a patch series with initial support for the oacc kernels > >> directive. > >> > >> The patch series uses pass_parallelize_loops to im

RE: [PATCH][AArch64] Implement -m{cpu,tune,arch}=native using only /proc/cpuinfo

Kyrill, Here's what I get on an Exynos M1: $ cat /proc/cpuinfo < Processor : AArch64 Processor rev 0 (aarch64) ... Features: fp asimd aes pmull sha1 sha2 crc32 CPU implementer : 0x53 CPU architecture: AArch64 CPU variant : 0x0 CPU part

Handle global loop counters in fortran oacc kernels (was: openacc kernels directive -- initial support)

Hi! On Sat, 15 Nov 2014 13:14:52 +0100, Tom de Vries wrote: > I'm submitting a patch series with initial support for the oacc kernels > directive. Committed to gomp-4_0-branch in r86: commit 0c33234340aa17536c2c86e0982c42070c89226b Author: tschwinge Date: Tue Apr 21 20:22:54 2015 +

Handle global loop counters in c/c++ oacc kernels (was: openacc kernels directive -- initial support)

Hi! On Sat, 15 Nov 2014 13:14:52 +0100, Tom de Vries wrote: > I'm submitting a patch series with initial support for the oacc kernels > directive. Committed to gomp-4_0-branch in r87: commit abaf92b2db3c0799edac63cfb846af2dbde47423 Author: tschwinge Date: Tue Apr 21 20:27:40 2015 +

Handle oacc kernels with other directives (was: openacc kernels directive -- initial support)

Hi! On Sat, 15 Nov 2014 13:14:52 +0100, Tom de Vries wrote: > I'm submitting a patch series with initial support for the oacc kernels > directive. Committed to gomp-4_0-branch in r88: commit 7109b39defb87bc839983339c9fb4cdcb3891238 Author: tschwinge Date: Tue Apr 21 20:32:01 2015 +

Re: [PATCH, rs6000, testsuite] Fix PR target/64579, __TM_end __builtin_tend failed to return transactional state

On Fri, 2015-03-20 at 17:41 -0500, Peter Bergner wrote: > On Fri, 2015-03-20 at 15:52 -0500, Segher Boessenkool wrote: > > Maybe it would be nicer if the builtin-expansion code handled the copy > > from cc, instead of stacking on RTL expanders. > > That would allow getting rid of the expanders com

[PATCH 1/5] libcc1: Make libcc1.so->libcc1.so.0

Hi, the next [patch 3/5] will change the libcc1.so API. I am not sure if the API change gets approved that way but for such case: (1) We really need to change GCC_FE_VERSION_0 -> GCC_FE_VERSION_1, this feature is there for this purpose. That is [patch 2/5]. (2) Currently GDB does only dlopen

[PATCH 2/5] libcc1: Use libcc1.so.0->libcc1.so.1

Hi, see [patch 1/5], particularly: (3) Currently there is no backward or forward compatibility although there could be one implemented. Personally I think the 'compile' feature is still in experimental stage so that it is OK to require last releases. At least in Fedora we can keep GDB

[PATCH 3/5] libcc1: set debug compile: Display GCC driver filename

Hi, as discussed in How to use compile & execute function in GDB https://sourceware.org/ml/gdb/2015-04/msg00026.html GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but it does not display which one. It cannot, GCC method set_arguments() does not yet know whether

[PATCH 4/5] libcc1: Add 'set compile-gcc'

as discussed in How to use compile & execute function in GDB https://sourceware.org/ml/gdb/2015-04/msg00026.html GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but one cannot override which one. GDB would provide new option 'set compile-gcc'. This patch does not

[PATCH 5/5] libcc1: 'set debug compile': Display absolute GCC driver filename

Hi, with the patches so far after (gdb) set debug compile 1 one would get: searching for compiler matching regex ^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$ found compiler x86_64-unknown-linux-gnu-gcc But I believe it is more readable to see: searching for compiler m

[C PATCH] Make -Wno-shift-count-negative -Wno-shift-count-overflow work for const ints (PR c/65830)

A trivial patch to use OPT_* where they belong. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-04-21 Marek Polacek PR c/65830 * c-common.c (c_fully_fold_internal): Use OPT_Wshift_count_negative and OPT_Wshift_count_overflow. * c-c++-common/pr65830.

Re: [patch, fortran] PR 37131

Hello Mikael and Dominique, thanks for your helpful comments! > To sum um, tests missing for the following: > array(4,:,:) > array(3:5,:) > array(3:10:2,:) > array(:,:)%comp > with both lbound == 1 and lbound != 1. > One test with lhs-rhs dependency would be good as well.

Re: Re: [RFC stage 1] Proposed new warning: -Wmisleading-indentation

On Tue, 2015-04-21 at 20:14 +0200, Manuel López-Ibáñez wrote: > On 21/04/15 18:07, David Malcolm wrote: > > > > I have the patch working now for the C++ frontend. Am attaching the > > work-in-progress (sans ChangeLog). This one (v2) bootstrapped and > > regrtested on x86_64-unknown-linux-gnu (Fed

Re: Ping^3 : [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

On Tue, Apr 21, 2015 at 03:13:38PM +0800, Terry Guo wrote: > > Did you fix the comment? REG_USERVAR_P and HARD_REGISTER_P can be > > set for more than just register asm. > > Sorry for missing the patch. I believe that I addressed your patch. > Please review it again to make sure my understanding

Re: [PATCH, rs6000, testsuite] Fix PR target/64579, __TM_end __builtin_tend failed to return transactional state

On Tue, Apr 21, 2015 at 03:56:18PM -0500, Peter Bergner wrote: > On Fri, 2015-03-20 at 17:41 -0500, Peter Bergner wrote: > > On Fri, 2015-03-20 at 15:52 -0500, Segher Boessenkool wrote: > > > Maybe it would be nicer if the builtin-expansion code handled the copy > > > from cc, instead of stacking o

Re: Ping^3 : [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

On Wed, Apr 22, 2015 at 9:44 AM, Segher Boessenkool wrote: > On Tue, Apr 21, 2015 at 03:13:38PM +0800, Terry Guo wrote: >> > Did you fix the comment? REG_USERVAR_P and HARD_REGISTER_P can be >> > set for more than just register asm. >> >> Sorry for missing the patch. I believe that I addressed yo

Re: Ping^3 : [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

On Wed, Apr 22, 2015 at 10:21:43AM +0800, Terry Guo wrote: > gcc/ChangeLog: > 2015-04-22 Hale Wang > Terry Guo > >PR rtl-optimization/64818 >* combine.c (can_combine_p): Don't combine user-specified register if >it is in an asm input. > > gcc/testsui

<    1   2