Re: [PATCH] [gomp4] Initial support of OpenACC loop directive in C front-end.

Hi Thomas! On 19.03.2014 23:35, Thomas Schwinge wrote: Do you intend to support loop constructs that are not nested in a parallel or kernels construct? As I'm reading it, the specification is not clear on this. (I guess I'll raise this question with the OpenACC guys.) Yes, I do. There are thre

[PATCH] Fix i?86 pic thunk generation (PR target/60568)

Hi! With -flto -fpic -m32 sometimes (unfortunately the testcase provided was in form of *.o file with LTO bytecode, so can't be reduced), if the thunk target doesn't bind locally we get ICE because we can't recog what x86_output_mi_thunk creates. The problem is that it doesn't put UNSPEC_GOT into

Re: [PATCH] [gomp4] Initial support of OpenACC loop directive in C front-end.

Ilmir Usmanov wrote: > On 19.03.2014 23:35, Thomas Schwinge wrote: > > Do you intend to support loop constructs that are not nested in a > > parallel or kernels construct? As I'm reading it, the specification is > > not clear on this. (I guess I'll raise this question with the OpenACC > > guys.)

Re: [PATCH] Fix i?86 pic thunk generation (PR target/60568)

On Thu, Mar 20, 2014 at 10:05 AM, Jakub Jelinek wrote: > With -flto -fpic -m32 sometimes (unfortunately the testcase provided was > in form of *.o file with LTO bytecode, so can't be reduced), if the thunk > target doesn't bind locally we get ICE because we can't recog what > x86_output_mi_thunk

Re: [Patch, Fortran] PRs 60283/60543: Fix two wrong-code bugs related for implicit pure

Tobias, > However, after I wrote that, I saw that there is a dg-* > which permits to check the .mod file for a string. Are you sure it works now the *.mod files are gzipped? AFAICT it does not. The following test MODULE generalFunctions USE, INTRINSIC :: ISO_FORTRAN_ENV IMPLICIT NONE INTEGER

Re: [PATCH] [gomp4] Initial support of OpenACC loop directive in C front-end.

Hi Ilmir! On Tue, 18 Mar 2014 16:37:24 +0400, Ilmir Usmanov wrote: > This patch introduces support of OpenACC loop directive (and combined > directives) in C front-end up to GENERIC. Currently no clause is allowed. > --- /dev/null > +++ b/gcc/testsuite/c-c++-common/goacc/loop-1.c > @@ -0,0 +1,8

Re: [PATCH 4/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end

Hi Ilmir! On Fri, 7 Mar 2014 14:47:14 +0400, Ilmir Usmanov wrote: > OpenACC 1.0 fortran FE support -- tests. > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/goacc/coarray.f95 > @@ -0,0 +1,35 @@ > +! { dg-do compile } > +! { dg-excess-errors "Unimplemented" } > +! { dg-excess-errors "ACC

Re: [C++ PATCH] [gomp4] Initial OpenACC support to C++ front-end

Hi Ilmir! On Thu, 13 Mar 2014 21:05:17 +0400, Ilmir Usmanov wrote: > On 07.03.2014 15:37, Ilmir Usmanov wrote: > > I prepared simple patch to add support of OpenACC data, kernels and > > parallel constructs to C++ FE. > > > > It adds support of data clauses too. > OK to gomp4 branch? OK once J

[C PATCH] Warn if inline attributes conflict (PR c/18079)

We should warn if someone wants to use both always_inline and noinline attributes. Regtested/bootstrapped on x86_64-linux. This is hardly 4.9 material, so ok for 5.0? 2014-03-20 Marek Polacek PR c/18079 c-family/ * c-common.c (handle_noinline_attribute): Warn if the attribute

Re: [C PATCH] Warn if inline attributes conflict (PR c/18079)

On Thu, Mar 20, 2014 at 12:07 PM, Marek Polacek wrote: > We should warn if someone wants to use both always_inline and noinline > attributes. > > Regtested/bootstrapped on x86_64-linux. This is hardly 4.9 material, > so ok for 5.0? Shouldn't the warning state that the attribute will be ignored?

Re: [Patch, Fortran] PRs 60283/60543: Fix two wrong-code bugs related for implicit pure

Tobias, > succeeds with your patch, but without it. was supposed to be "succeeds with your patch, but not without it." I also understand what happened when the test was split in two files: If the module file is compiled with the patched compiler, then the test succeed with ot without the patch.

Remove left-overs from RTX_UNCHANGING_P era

While investigating PR rtl-opt/60452, I stumbled upon left-overs of the RTX_UNCHANGING_P era, in the form the following idiom: target = assign_temp (build_qualified_type (type, (TYPE_QUALS (type) | (TREE_READONLY (exp)

[SPARC] Implement workaround for new FPU erratum on LEON3

This implements a workaround for the recently-disclosed FPU erratum on LEON3. Tested on SPARC/Solaris, applied on the mainline and 4.8 branch. 2014-03-20 Eric Botcazou * config/sparc/sparc.c (sparc_do_work_around_errata): Implement work around for store forwarding issue in th

Re: [C PATCH] Warn if inline attributes conflict (PR c/18079)

On Thu, Mar 20, 2014 at 12:10:35PM +0100, Richard Biener wrote: > On Thu, Mar 20, 2014 at 12:07 PM, Marek Polacek wrote: > > We should warn if someone wants to use both always_inline and noinline > > attributes. > > > > Regtested/bootstrapped on x86_64-linux. This is hardly 4.9 material, > > so o

Re: [C PATCH] Warn if inline attributes conflict (PR c/18079)

On Thu, Mar 20, 2014 at 12:45 PM, Marek Polacek wrote: > On Thu, Mar 20, 2014 at 12:10:35PM +0100, Richard Biener wrote: >> On Thu, Mar 20, 2014 at 12:07 PM, Marek Polacek wrote: >> > We should warn if someone wants to use both always_inline and noinline >> > attributes. >> > >> > Regtested/boots

Re: [C PATCH] Warn if inline attributes conflict (PR c/18079)

On Thu, 20 Mar 2014, Marek Polacek wrote: > Dunno. I did what we do wrt conflicting cold/hot attributes. But > here's a patch with what you suggest (with some Extra Quotes). > > 2014-03-20 Marek Polacek > > PR c/18079 > c-family/ > * c-common.c (handle_noinline_attribute): Warn

[PATCH] Don't bootstrap libsanitizer or libvtv unless needed

Hi! We currently bootstrap both libsanitizer and libvtv, the former just in case somebody decides to --with-build-config=bootstrap-asan (or --with-build-config=bootstrap-ubsan), the latter if somebody decides to --enable-vtable-verify. This patch changes it so that we only bootstrap libsanitizer

Re: [PATCH] Don't bootstrap libsanitizer or libvtv unless needed

On Thu, 20 Mar 2014, Jakub Jelinek wrote: > Hi! > > We currently bootstrap both libsanitizer and libvtv, the former > just in case somebody decides to --with-build-config=bootstrap-asan > (or --with-build-config=bootstrap-ubsan), the latter if somebody decides > to --enable-vtable-verify. > > Th

Re: [AArch64] VDUP Testcases

On 14 March 2014 16:22, Alex Velenko wrote: > Hi, > This patch adds vdup intrinsic testcases for AArch64. those testcases > are nice to have, as it allows to reason about vdup consistency for > both LE and BE compiler flavors. > gcc/testsuite/ > > 2014-03-14 Alex Velenko > > * gcc.targ

Re: [PATCH] [gomp4] Initial support of OpenACC loop directive in C front-end.

Hi Thomas! On 20.03.2014 14:21, Thomas Schwinge wrote: I just realized that this is wrong usage of the dg-excess-errors directive, for this one will absorb *all* remaining errors, whereas you just wanted to mask out any »sorry, unimplemented: directive not yet implemented« ones. Sorry for that

Re: [PATCH 4/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end

Hi Thomas! On 20.03.2014 14:22, Thomas Schwinge wrote: As in , this is wrong usage of the dg-excess-errors directive, for this one will absorb *all* remaining errors, whereas you just wanted to mask out any »so

Re: [4.8, PATCH 0/26] Backport Power8 and LE support

Alan Modra wrote: > On Wed, Mar 19, 2014 at 03:35:59PM -0600, Jeff Law wrote: > > On 03/19/14 15:03, Bill Schmidt wrote: > > >The three pieces that are somewhat controversial for non-powerpc targets > > >are 9/26, 10/26, 15/26. > > > > > > * Uli and Alan, can you speak to any concerns for 9/26? >

Re: [AArch64] Logical vector shift right conformance

On 25 February 2014 11:58, Alex Velenko wrote: > Hi, > > This patch fixes a bug in vshr_n_u64 and vshrd_n_u64 intrinsic > behavior in case of shift by 64. Shift by 64 is strictly defined in ACLE to > use ushr instruction intended by those intrinsics. > > The testcase provided also tests the behavi

Re: [gomp4 9/9] OpenACC: Basic support for #pragma acc parallel.

Hi! On Wed, 6 Nov 2013 20:53:00 +0100, I wrote: > --- /dev/null > +++ gcc/testsuite/c-c++-common/goacc/parallel-1.c > @@ -0,0 +1,6 @@ > +void > +foo (void) > +{ > +#pragma acc parallel > + foo (); > +} Applied in r208699 on gomp-4_0-branch: commit 4a854d643b300adc0b79ad5dadd132aa1cdd535a Author

Re: [gomp4 2/2] Initial support for the OpenACC kernels construct in the C front end.

Hi! On Fri, 28 Feb 2014 10:23:01 +0100, I wrote: > diff --git gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c > gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c > index 24a4c11..d88ee8a 100644 > --- gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c > +++ gcc/testsuite/c-c++-common/goacc/nestin

[gomp4] Nesting of OpenACC constructs inside of OpenACC data constructs (was: [gomp4 2/3] OpenACC data construct implementation in terms of GF_OMP_TARGET_KIND_OACC_DATA.)

Hi! Applied in r208701 to gomp-4_0-branch: commit 22dd36a31c433dcd8bcc890d245a9e4ac6ed9c7f Author: tschwinge Date: Thu Mar 20 14:33:28 2014 + Nesting of OpenACC constructs inside of OpenACC data constructs. gcc/ * omp-low.c (check_omp_nesting_restrictions): Allow

Re: [PATCH 4/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end

On Thu, Mar 20, 2014 at 11:22:59AM +0100, Thomas Schwinge wrote: > > --- /dev/null > > +++ b/gcc/testsuite/gfortran.dg/goacc/coarray.f95 > > @@ -0,0 +1,35 @@ > > +! { dg-do compile } > > > +! { dg-excess-errors "Unimplemented" } > > +! { dg-excess-errors "ACC LOOP" } > > \ No newline at end of fi

Re: [C PATCH] Warn if inline attributes conflict (PR c/18079)

On Thu, Mar 20, 2014 at 11:57:57AM +, Joseph S. Myers wrote: > This version is OK (for after 4.9 branches). Thanks. > What happens if there are two declarations of the function, one with each > attribute? The testcase doesn't cover that. Nothing :(. I had to add some code into diagnose_m

Re: [PATCH] [gomp4] Initial support of OpenACC loop directive in C front-end.

On Thu, Mar 20, 2014 at 03:42:48PM +0100, Thomas Schwinge wrote: > Here are the patches, committed in r208702..4 to gomp-4_0-branch. Jakub, > are the first two fine for trunk, or shall I wait until stage 1? Stage1 IMHO. Jakub

[RFA jit] initialize input_location

This patch initializes input_location at the same spot where the line table is initialized. Without this, it's possible to crash when emitting a diagnostic in a reinvocation of the compiler, because input_location refers to a location that is no longer valid. --- gcc/ChangeLog.jit | 4 gcc/t

Re: [PATCH] [gomp4] Initial support of OpenACC loop directive in C front-end.

On Thu, Mar 20, 2014 at 10:27:20AM +0100, Tobias Burnus wrote: > > 3) GCC OpenMP implementation supports loop construct without parallel. It is not about GCC OpenMP implementation, it is the standard that requires it. If you have an orphaned #pragma omp for e.g., you still can call the containing

Re: [C PATCH] Warn if inline attributes conflict (PR c/18079)

On Thu, 20 Mar 2014, Marek Polacek wrote: > On Thu, Mar 20, 2014 at 11:57:57AM +, Joseph S. Myers wrote: > > This version is OK (for after 4.9 branches). > > Thanks. > > > What happens if there are two declarations of the function, one with each > > attribute? The testcase doesn't cover t

libgcc/config.host: Fix v850-rtems bug

Hi It took a while to find this but v850-rtems lost the include paths for the rtems specific .h files in newlib due to the line that resets tmake_file rather than appends to it. Is this OK to apply to all impacted branches and the head? 2014-03-20 Joel Sherrill * config.host (v850*-*

Re: libgcc/config.host: Fix v850-rtems bug

Hi Joel, > It took a while to find this but v850-rtems lost the include > paths for the rtems specific .h files in newlib due to > the line that resets tmake_file rather than appends to it. > > Is this OK to apply to all impacted branches and the head? > > 2014-03-20 Joel Sherrill > > *

[PATCH, PR 59176] Mark "zombie" call graph nodes to remove verifier false positive

Hi, in the PR, verifier claims an edge is pointing to a wrong declaration even though it has successfully verified the edge multiple times before. The reason is that symtab_remove_unreachable_nodes decides to "remove the body" of a node and also clear any information that it is an alias of anothe

[gomp4] Accelerator configury and paths changes 1/3

This adds the --enable-accelerator option. This isn't too useful yet as there's no nvptx target so far, but it's part of the other changes to the configury that allows for offloading/accelerator targets. Committed on gomp-4_0-branch. Bernd Index: ChangeLog ===

Re: libgcc/config.host: Fix v850-rtems bug

On 3/20/2014 10:57 AM, Rainer Orth wrote: > Hi Joel, > >> It took a while to find this but v850-rtems lost the include >> paths for the rtems specific .h files in newlib due to >> the line that resets tmake_file rather than appends to it. >> >> Is this OK to apply to all impacted branches and the

[PATCH, PR 60419] Clear thunk flag of "zombie" nodes

Hi, in PR 60419 we end up with a call graph node for a thunk that has no callee because symtab_remove_unreachable_nodes has determined its body is not needed although its declaration is still reachable (more details in comment 11 in bugzilla) and removal of callees is a part of the zombification p

[gomp4] Accelerator configury and paths changes 2/3

This adds three options to gcc's configure for accelerator/offload targets. --enable-as-accelerator-for=host This is used to build offload compilers. They get installed in a subdirectory of their host compiler's install directory, with the driver going into the standard bin/ directory but w

[gomp4/stage1] Clean up lto section name headers

This reduces duplication of a number of defines related to LTO section/segment names. Committed on gomp-4_0-branch; ok for stage1? Bernd Index: gcc/lto/ChangeLog === --- gcc/lto/ChangeLog (revision 208706) +++ gcc/lto/ChangeLog (w

Re: libgcc/config.host: Fix v850-rtems bug

On 03/20/14 09:33, Joel Sherrill wrote: Hi It took a while to find this but v850-rtems lost the include paths for the rtems specific .h files in newlib due to the line that resets tmake_file rather than appends to it. Is this OK to apply to all impacted branches and the head? 2014-03-20 Jo

[gomp4] Use OMP_SECTION_NAME_PREFIX in offload compilers

This makes us read in the offloaded functions in an offload compiler's lto1. This is essentially Michael Zolotukhin's patch 1/3 from a while ago. Committed on gomp-4_0-branch. Bernd Index: gcc/lto/ChangeLog === --- gcc/lto/ChangeL

[PATCH, PR 60556] Fix ICE on platforms with signed pointer extension.

This patch fixes pr60556, a GCC ICE. The problem is in convert_move where, if we are trying to put a 32 bit address into a 64 bit destination we can wind up calling emit_move_insn with NULL_RTX as a source. The problem comes when creating fill_value. If unsignedp is false then we call emit_store

[gomp4] Add tables generation

This is based on Michael Zolotukhin's patch 2/3 from a while ago. It adds functionality to build function/variable tables that will allow libgomp to look up offload target code based on the address of the corresponding host function. There are two alternatives, one based on named sections, and

[gomp4/stage1] Utility functions for collect2/lto-wrapper/mkoffload 1/2

Since we're about to introduce new mkoffload programs, and they're going to require a lot of functionality that's already present in lto-wrapper and collect2, I've decided to make a new set of utility functions that can be linked in with these programs. This is the first step, splitting off co

[gomp4/stage1] Utility functions for collect2/lto-wrapper/mkoffload 2/2

This is the second part of making a set of utility functions to be used by collect2, lto-wrapper and mkoffload. The implementations of some functions like fork_execute are changed to those from collect2 and the calls in lto-wrapper adapted accordingly. There are some minor changes in these fun

[gomp4] Add mkoffload invocations to lto-wrapper

This is based on Michael Zolotukhin's patch 3/3 from a while ago. It enables lto-wrapper to build target images using the offload compilers (identifying them through an env variable passed in by the gcc driver). All the target-specific code is gone, however. We now expect an offload compiler to

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

On 03/12/2014 03:51 PM, Ilya Verbin wrote: 2014-03-12 18:12 GMT+04:00 Bernd Schmidt : LGTM. Shall I start committing my changes to the branch? Yes, I think you should commit your changes. And we will rewrite our part to use the new configure approach. Done now. I think/hope that I've commit

Fwd: [GOOGLE] update ssa before compute_inline_parameters

This patch calls update_ssa before compute_inline_paramters. Bootstrapped and perf test on-going. OK for google-4_8? Thanks, Dehao Index: gcc/auto-profile.c === --- gcc/auto-profile.c (revision 208726) +++ gcc/auto-profile.c (worki

Re: [gomp4/stage1] Utility functions for collect2/lto-wrapper/mkoffload 2/2

On 03/20/2014 06:03 PM, Bernd Schmidt wrote: This is the second part of making a set of utility functions to be used by collect2, lto-wrapper and mkoffload. The implementations of some functions like fork_execute are changed to those from collect2 and the calls in lto-wrapper adapted accordingly

[PATCH] dwarf2out: Represent bound_info with normal constant values if possible.

Hi, The following patch made it so that 64-bit bounds could be output on 32-bit hosts with DWARF. 2009-07-11 Eric Botcazou * dwarf2out.c (enum dw_val_class): Replace dw_val_class_long_long with dw_val_class_const_double. (struct dw_long_long_struct): Delete. (s

[PATCH] Support spu-elf in libstdc++ crossconfig.m4

Hello, currently, there is no support for spu-elf in crossconfig.m4. In the past, we've usually worked around this by configuring GCC with --with-newlib. But that has other drawbacks since it performs no link tests at all, and thus assumes only a very minimal set of features available via newlib

Re: [PATCH] Support spu-elf in libstdc++ crossconfig.m4

On 20 March 2014 18:04, Ulrich Weigand wrote: > Hello, > > currently, there is no support for spu-elf in crossconfig.m4. In the past, > we've usually worked around this by configuring GCC with --with-newlib. > > But that has other drawbacks since it performs no link tests at all, and > thus assume

Re: extending constants in rtl

On Mar 17, 2014, at 8:36 PM, Mike Stump wrote: > So, to support things like this: > > (define_constants > (C1_TEMP_REGNUM PROLOGUE_SCRATCH_1) > (C1_TEMP2_REGNUM PROLOGUE_SCRATCH_2) > Absent a better solution, I’d like to pursue this. So, it turns out the patch won’

Re: [PATCH] Support spu-elf in libstdc++ crossconfig.m4

Jonathan Wakely wrote: > On 20 March 2014 18:04, Ulrich Weigand wrote: > > Hello, > > > > currently, there is no support for spu-elf in crossconfig.m4. In the past, > > we've usually worked around this by configuring GCC with --with-newlib. > > > > But that has other drawbacks since it performs no

Re: [GOOGLE] update ssa before compute_inline_parameters

I think the right way to fix this is to wrap the call to early_inliner and check the TODO flags. See execute_function_todo: if (flags & TODO_cleanup_cfg) { cleanup_tree_cfg (); if (!(flags & TODO_update_ssa_any) && need_ssa_update_p (cfun)) flags |= TODO_update_ssa;

Re: [PATCH, PR 59176] Mark "zombie" call graph nodes to remove verifier false positive

On Thu, Mar 20, 2014 at 05:07:32PM +0100, Martin Jambor wrote: > in the PR, verifier claims an edge is pointing to a wrong declaration > even though it has successfully verified the edge multiple times > before. The reason is that symtab_remove_unreachable_nodes decides to > "remove the body" of a

Re: [PATCH] Support spu-elf in libstdc++ crossconfig.m4

On 20 March 2014 18:31, Ulrich Weigand wrote: > Jonathan Wakely wrote: >> On 20 March 2014 18:04, Ulrich Weigand wrote: >> > Hello, >> > >> > currently, there is no support for spu-elf in crossconfig.m4. In the past, >> > we've usually worked around this by configuring GCC with --with-newlib. >> >

Re: [gomp4] Add tables generation

On Thu, Mar 20, 2014 at 05:50:13PM +0100, Bernd Schmidt wrote: > --- libgcc/crtstuff.c (revision 208706) > +++ libgcc/crtstuff.c (working copy) > @@ -311,6 +311,15 @@ register_tm_clones (void) > } > #endif /* USE_TM_CLONE_REGISTRY */ > > +#if defined(HAVE_GAS_HIDDEN) && defined(ENABLE_OFFLOADIN

[Testsuite, Patch] Fix testsuite/lib/gcc-dg.exp's scan-module-absence

gfortran's modules are since GCC 4.9 zipped. There are two functions, which test for the existence and absent of strings in the .mod files. While one was updated to apply gunzip before reading, the other wasn't. This patch copies over the unzip call from the other function. I have tested it th

Re: [C++ PATCH] Fix ICE in build_zero_init_1 (PR c++/60572)

OK. Jason

Re: [PATCH, PR 59176] Mark "zombie" call graph nodes to remove verifier false positive

Hi, On Thu, Mar 20, 2014 at 07:40:56PM +0100, Jakub Jelinek wrote: > On Thu, Mar 20, 2014 at 05:07:32PM +0100, Martin Jambor wrote: > > in the PR, verifier claims an edge is pointing to a wrong declaration > > even though it has successfully verified the edge multiple times > > before. The reason

Go patch committed: Fix bug leading to invalid initializer loop report

This patch by Chris Manghane fixes a bug in which gccgo could incorrectly report an invalid initializer loop when a struct field name is confused with a variable name. This is http://golang.org/issue/7590. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian

Re: [GOOGLE] update ssa before compute_inline_parameters

Patch updated to add a wrapper early_inline function Index: gcc/auto-profile.c === --- gcc/auto-profile.c (revision 208726) +++ gcc/auto-profile.c (working copy) @@ -1449,8 +1449,6 @@ afdo_vpt_for_early_inline (stmt_set *promoted_stmt

[committed] Fix a DEBUG_INSN related invalid RTL sharing bug in IRA (PR middle-end/60597)

Hi! This patch fixes a RTL sharing issue, if *reg_equiv[REGNO (loc)].src_p is e.g. a MEM and the cleared reg would be used in more than one DEBUG_INSN or more than once in a single one, we'd incorrectly share it, which can result e.g. in DF verification issue - change of one DEBUG_INSN with the sh

Re: [GOOGLE] update ssa before compute_inline_parameters

On Thu, Mar 20, 2014 at 12:40 PM, Dehao Chen wrote: > Patch updated to add a wrapper early_inline function > > Index: gcc/auto-profile.c > === > --- gcc/auto-profile.c (revision 208726) > +++ gcc/auto-profile.c (working copy) > @@ -14

Re: [GOOGLE] update ssa before compute_inline_parameters

On Thu, Mar 20, 2014 at 1:02 PM, Xinliang David Li wrote: > On Thu, Mar 20, 2014 at 12:40 PM, Dehao Chen wrote: >> Patch updated to add a wrapper early_inline function >> >> Index: gcc/auto-profile.c >> === >> --- gcc/auto-profile.c

Re: [GOOGLE] update ssa before compute_inline_parameters

The patch is ok. David On Thu, Mar 20, 2014 at 1:10 PM, Dehao Chen wrote: > On Thu, Mar 20, 2014 at 1:02 PM, Xinliang David Li wrote: >> On Thu, Mar 20, 2014 at 12:40 PM, Dehao Chen wrote: >>> Patch updated to add a wrapper early_inline function >>> >>> Index: gcc/auto-profile.c >>> ==

Re: [Build] libcilkrts/Makefile.am: Install cilk.h

It turned out, that my testing of the original state was screwed up and cilk.h was actually installed - see R other/60589. (Sorry!) There is still another issue, but that I will by a new patch. Reverted the patch of Rev. 208440 in Rev. 208736 Tobias Tobias Burnus wrote: The attached patch in

[Build] Don't install libcilkrt's include/cilk/ header files twice for multi-lib installations

When looking at PR 60589, I saw that libcilk's header files are installed multiple times. On my x86-64-gnu-linux system, I have them as: lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk/*.h lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk/*.h However, GCC only reads the latter - even wi

Re: PR libstdc++/60587

On 19/03/14 23:38 +0100, Paolo Carlini wrote: On 19/03/14 21:39 +, Jonathan Wakely wrote: I think the safe thing to do is (as I suggested at the time) to have a trait saying which iterator types refer to contiguous memory. Our debug mode only supports our own containers, so the ones which are

Re: [Build] Don't install libcilkrt's include/cilk/ header files twice for multi-lib installations

On Thu, Mar 20, 2014 at 1:25 PM, Tobias Burnus wrote: > When looking at PR 60589, I saw that libcilk's header files are installed > multiple times. On my x86-64-gnu-linux system, I have them as: > > lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk/*.h > lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/

FW: [PING] [PATCH] _Cilk_for for C and C++

I mis-spelled the "org" as "og" and thus the email got bounced. So, here it is again. Thanks, Balaji V. Iyer. > -Original Message- > From: Iyer, Balaji V > Sent: Thursday, March 20, 2014 4:34 PM > To: 'Jakub Jelinek' > Cc: gcc-patc...@gcc.gnu.og > Subject: RE: [PING] [PATCH] _Cilk_for fo

Re: [Testsuite, Patch] Fix testsuite/lib/gcc-dg.exp's scan-module-absence

On Thu, Mar 20, 2014 at 08:24:49PM +0100, Tobias Burnus wrote: > gfortran's modules are since GCC 4.9 zipped. There are two functions, > which test for the existence and absent of strings in the .mod files. > > While one was updated to apply gunzip before reading, the other wasn't. > This patch

Re: [4.8, PATCH 0/26] Backport Power8 and LE support

On Wed, 2014-03-19 at 16:03 -0500, Bill Schmidt wrote: > On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote: > > > I guess the most important question is what guarantees there are that it > > won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, > > plus the C++ FE / lib

Re: [Build] Don't install libcilkrt's include/cilk/ header files twice for multi-lib installations

H.J. Lu wrote: On Thu, Mar 20, 2014 at 1:25 PM, Tobias Burnus wrote: When looking at PR 60589, I saw that libcilk's header files are installed multiple times. On my x86-64-gnu-linux system, I have them as: lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk/*.h lib64/gcc/x86_64-unknown-linux-

Re: [PATCH][AArch64] Implement %c output template

On Oct 18, 2013, at 12:13 AM, Kyrill Tkachov wrote: > Hi all, > > This patch implements the %c output template for inline asm. The code for it > is almost identical to the support in arm, so it's pretty straightforward. > I've added a few compile tests for it as well. > > Tested aarch64-none-

Re: [4.8, PATCH 0/26] Backport Power8 and LE support

On Thu, Mar 20, 2014 at 04:25:54PM -0500, Peter Bergner wrote: > On Wed, 2014-03-19 at 16:03 -0500, Bill Schmidt wrote: > > On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote: > > > > > I guess the most important question is what guarantees there are that it > > > won't affect non-powerpc* por

Re: [4.8, PATCH 0/26] Backport Power8 and LE support

On 03/19/14 21:18, Alan Modra wrote: implementing either ELFv2 or ELFv1 ABIs. Another thing that we didn't change is that sibcalls can be allowed in more cases than the current code allows. Right. IIRC we deferred allowing more sibcalls until the next stage1 out of an abundance of caution. je

Re: Remove left-overs from RTX_UNCHANGING_P era

> 2014-03-20 Eric Botcazou > > * calls.c (store_one_arg): Remove incorrect const qualification on the > type of the temporary. > * cfgexpand.c (expand_return): Likewise. > * expr.c (expand_constructor): Likewise. > (expand_expr_real_1): Likewise. There is also a r

Re: Remove left-overs from RTX_UNCHANGING_P era

> 2014-03-20 Eric Botcazou > > * calls.c (store_one_arg): Remove incorrect const qualification on the > type of the temporary. > * cfgexpand.c (expand_return): Likewise. > * expr.c (expand_constructor): Likewise. > (expand_expr_real_1): Likewise. There is also a r

[patch] Fix PR59295 -- remove useless warning

Greetings, Attached patch deletes code to warn about repeated friend declaration. The warning has apparently been present since at least 1997, but it's unlikely to have ever prevented any actual bugs. Ok for trunk once it opens in stage1? Tested on Linux/x86_64 with no regressions. Thanks, G

[PATCH, rs6000] More efficient vector permute for little endian

Hi, The original workaround for vector permute on a little endian platform includes subtracting each element of the permute control vector from 31. Because the upper 3 bits of each element are unimportant, this was implemented as subtracting the whole vector from a splat of -1. On reflection this