RE: [PATCH] [libiberty] MAX_PATH problems with mingw gcc

> -Original Message- > From: Ian Lance Taylor [mailto:i...@google.com] > Sent: Wednesday, November 06, 2013 6:42 PM > To: Joey Ye > Cc: gcc-patches; d...@redhat.com; Vladimir Simonov > Subject: Re: [PATCH] [libiberty] MAX_PATH problems with mingw gcc Jan, thank you for your attention. It

Re: [RFA][PATCH] Minor erroneous path isolation followups

On Wed, Nov 06, 2013 at 07:48:49PM -0700, Jeff Law wrote: > * doc/invoke.texi (-fisolate-erroneous-paths): Document. > > * gimple-ssa-isolate-paths.c (gate_isolate_erroneous_paths): > No longer check if we have __builtin_trap, assume it's > available. > > java/ > > * builtins

Re: PATCH: PR target/59034: FAIL gcc.c-torture/compile/20031208-1.c

On Thu, Nov 7, 2013 at 7:19 AM, H.J. Lu wrote: > We should use Pmode with stack_pointer_rtx. OK for trunk and 4.8 > branch? OK everywhere. Thanks, Uros.

Re: [C] Fix PR57258: unused variable warning is emitted for volatile variables

On Thu, Nov 7, 2013 at 11:53 AM, Mingjie Xing wrote: > 2013/11/6 Richard Biener : >> You miss a testcase. >> >> Also why should the warning be omitted for unused automatic >> volatile variables? They cannot be used in any way. >> >> Richard. > > Thanks. I've updated the patch with a test case. >

Re: [PATCH]Fix computation of offset in ivopt

On Thu, Nov 7, 2013 at 1:06 AM, Richard Sandiford wrote: > Hi, > > "bin.cheng" writes: >> Index: gcc/tree-ssa-loop-ivopts.c >> === >> --- gcc/tree-ssa-loop-ivopts.c(revision 203267) >> +++ gcc/tree-ssa-loop-ivopts.c(w

Re: [Patch, MIPS] Add new multilibs to mips-mti-* targets.

"Steve Ellcey " writes: > @@ -40,3 +40,11 @@ MULTILIB_EXCEPTIONS += *mips16/mabi=64* > MULTILIB_EXCEPTIONS += *mips64*/mmicromips* > MULTILIB_EXCEPTIONS += *mips32/mmicromips* > MULTILIB_EXCEPTIONS += *mmicromips/mabi=64* > + > +# We do not want nan2008 libraries for soft-float. > +MULTILIB_EXC

Re: [wide-int] Remove SHIFT_COUNT_TRUNCATED uses at tree/gimple level

Kenneth Zadeck writes: > So what is the big plan here? if you remove it here and then do not > do it in wide int, then it is not going to be truncated. Yeah, that is the big plan for trees. Mainline doesn't truncate at the tree level after: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg

PATCH: PR target/59034: FAIL gcc.c-torture/compile/20031208-1.c

Hi, We should use Pmode with stack_pointer_rtx. OK for trunk and 4.8 branch? Thanks. H.J. --- gcc/ 2013-11-06 H.J. Lu PR target/59034 * config/i386/i386.md (push peepholer/splitter): Use Pmode with stack_pointer_rtx. gcc/testsuite/ 2013-11-06 H.J. Lu P

Re: libsanitizer merge from upstream r191666

On Wed, Nov 6, 2013 at 3:53 AM, Jakub Jelinek wrote: > On Tue, Nov 05, 2013 at 01:49:43PM -0800, Evgeniy Stepanov wrote: >> This way we can't test kernel interfaces that are not used in glibc, >> like linux aio. > > So you just test what you can test. Why do you need to intercept kernel > aio whe

Re: [PATCH] Add gimple subclasses for every gimple code (was Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3))

[ Just a note, of this reply is meant for Michael and other parts for David, hopefully the audience is clear from the context. ] On 11/06/13 21:56, David Malcolm wrote: On Wed, 2013-11-06 at 16:32 +0100, Michael Matz wrote: Hi, On Tue, 5 Nov 2013, David Malcolm wrote: Here's a followup patc

Re: [PATCH] Add gimple subclasses for every gimple code (was Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3))

On Wed, 2013-11-06 at 16:32 +0100, Michael Matz wrote: > Hi, > > On Tue, 5 Nov 2013, David Malcolm wrote: > > > Here's a followup patch which ensures that every gimple code has its own > > subclass, by adding empty subclasses derived from the GSS_-based > > subclasses as appropriate (I don't both

Re: [C] Fix PR57258: unused variable warning is emitted for volatile variables

2013/11/6 Richard Biener : > You miss a testcase. > > Also why should the warning be omitted for unused automatic > volatile variables? They cannot be used in any way. > > Richard. Thanks. I've updated the patch with a test case. c/ChangeLog PR 57258 * c-decl.c (pop_scope): Don

Re: [RFA][PATCH] Minor erroneous path isolation followups

On 11/06/13 00:12, Jakub Jelinek wrote: On Tue, Nov 05, 2013 at 11:15:30PM -0700, Jeff Law wrote: * java/builtins.c (initialize_builtins): Provide __builtin_trap. Without java/ ;) Yes. I was aware of that. I probably should have done java/ * builtins.c ... --- a/gcc/ja

Re: [v3 patch] Fix spelling in regex headers

On Wed, Nov 6, 2013 at 4:47 AM, Jonathan Wakely wrote: > This simply fixes s/boundry/boundary/, which I wanted to do first > before some more regex refactoring I'm planning. Thanks a lot Jonathan! -- Regards, Tim Shen

Re: [wide-int] Remove SHIFT_COUNT_TRUNCATED uses at tree/gimple level

So what is the big plan here? if you remove it here and then do not do it in wide int, then it is not going to be truncated. kenny On 11/06/2013 05:10 PM, Richard Sandiford wrote: Following the removal of SHIFT_COUNT_TRUNCATED from double-int, this patch reverts the changed I'd made to mi

Re: [RFC] libgcov.c re-factoring and offline profile-tool

On Wed, 6 Nov 2013, Rong Xu wrote: > In current implementation, if you use 'profile-tool help', it will > print out the usage and exit. Please make sure you follow the GNU Coding Standards. Any installed tool needs to support --help, with output following the GNU Coding Standards, to standard

Re: wwwdocs: gcc-4.9/changes.html: Add OpenMP4 + -Wdate-time

On Tue, 5 Nov 2013, Tobias Burnus wrote: OK? Looks good to me, thanks! Gerald PS: If I were to nitpick, I'd probably omit the comma before "while".

Re: [PATCH] Add check for aarch64 in vect_cmdline_needed

You should be testing aarch64*-*-* so as to match aarch64_be targets. -- Joseph S. Myers jos...@codesourcery.com

Re: [gomp4] rewrite simd clone argument adjustment to avoid regimplification

On 11/06/13 15:48, Jakub Jelinek wrote: On Wed, Nov 06, 2013 at 03:24:40PM -0700, Aldy Hernandez wrote: I have checked the following patch with the attached testcases that were previously ICEing, and with a handful of handcrafted tests that I checked manually (array references on lhs and rhs, ve

Re: fixincludes patch RFA: Fix fenv.h on Ubuntu Precise

On Wed, Nov 6, 2013 at 4:03 PM, Bruce Korb wrote: > please try to see if just one file name expression is sufficient. > If one is sufficient, please fix, otherwise, approved. > But, also, "all active branches", please. I tried to do that, but I ran into my lack of knowledge of the fixincludes fra

[Patch, MIPS] Add new multilibs to mips-mti-* targets.

This patch is to add another set of multilibs to the mips-mti-* targets. The new multilibs are for programs compiled and linked with -mfp64 using the old 32 bit ABI. They are only going to be built for the mips32r2 architecture in order to reduce the number of new libraries being added. I also d

[PATCH] Add check for aarch64 in vect_cmdline_needed

The following tests were failing on Aarch64 because the vectorizer was successfully able to vectorize their loop nests: FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect "vectorized 0 loops" 1 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect "vectorized 0 loops" 1 Appar

Re: mismatched decls w/ both builtin and explicit decl

Thanks! Committed.

fixincludes patch RFA: Fix fenv.h on Ubuntu Precise

On my Ubuntu precise system /usr/include/bits is a symlink to /usr/include/x86_64-linux-gnu/bits. This breaks the fix for fenv.h, which only looks for bits/fenv.h. The ordering of the directories is such that x86_64-linux-gnu/bits is handled first, which means that nothing in bits is handled expl

Re: mismatched decls w/ both builtin and explicit decl

On Wed, 6 Nov 2013, DJ Delorie wrote: > > Please send a patch that adds a testcase to the testsuite to show the > > diagnostics you get after the patch. > > How's this? > > * c-decl.c (locate_old_decl): If a previous conflicting decl is > both explicit and builtin, print the locatio

Re: [RFC] libgcov.c re-factoring and offline profile-tool

I have not looked this in detail, but it looks like the copy right header of the new file is wrong (including the year). You should 1) document the command line syntax somewhere, possibly in comment? 2) add a help command for the tool to dump out help message. David On Wed, Nov 6, 2013 at 1:25

Re: mismatched decls w/ both builtin and explicit decl

> Please send a patch that adds a testcase to the testsuite to show the > diagnostics you get after the patch. How's this? * c-decl.c (locate_old_decl): If a previous conflicting decl is both explicit and builtin, print the location of the explicit one. * gcc.dg/mismatc

Re: [wide-int] Fix avr build

On Nov 6, 2013, at 2:48 PM, Richard Sandiford wrote: > The main part of getting avr to work was changing the type used to > handle the insert_bits mask, which went into mainline first. This just > mops up a couple of other problems. > Will say more about the comparison later. Look forward to

Re: [SH] PR 30807 - Add test case

On Nov 6, 2013, at 2:33 PM, Oleg Endo wrote: > I've committed the attached patch as rev 204487. I doubled checked the patch, all looks good, thanks for the work.

Re: [gomp4] rewrite simd clone argument adjustment to avoid regimplification

On Wed, Nov 06, 2013 at 03:24:40PM -0700, Aldy Hernandez wrote: > I have checked the following patch with the attached testcases that > were previously ICEing, and with a handful of handcrafted tests that > I checked manually (array references on lhs and rhs, vectors of > pointers, etc). I'd like

[wide-int] Fix avr build

The main part of getting avr to work was changing the type used to handle the insert_bits mask, which went into mainline first. This just mops up a couple of other problems. The first two hunks are from still using double_int for fixed-point. Tested by comparing avr-rtems between the branch and

Re: [gomp4] mangle linear step of 1 with just 'l'

On 11/02/13 09:50, Jakub Jelinek wrote: On Sat, Nov 02, 2013 at 08:25:28AM -0500, Aldy Hernandez wrote: Your patch mangling negative linear steps caused a regression in simd-clones-2.c. Well, it already had a failure, but now it has two :). The problem is that AFAIU, a linear step of 1, is man

Re: [PATCH] Fix PR58941

Richard Biener writes: > --- 599,615 > > exp = TREE_OPERAND (exp, 0); > } > > + /* We need to deal with variable arrays ending structures. */ > + if (seen_variable_array_ref > + && maxsize != -1 > + && (!bit_offset.fits_shwi () > + || !host_integerp

Re: Implement C11 _Atomic

On 11/05/2013 06:21 PM, Joseph S. Myers wrote: This patch, relative to trunk and based on work done on the C11-atomic branch, adds support for C11 _Atomic. It is intended to include all the required language support. Thanks for picking this up Joseph... It would have taken me months to do the

Re: [wide-int] Make integer_onep return false for signed 1-bit bitfields

Ping. Richard Sandiford writes: > As discussed on gcc@, integer_onep is supposed to return false for > a nonzero 1-bit value if the type is signed. > > Tested on x86_64-linux-gnu and powerpc64-linux-gnu. OK to install? > > Thanks, > Richard > > > Index: gcc/tree.c > =

Re: [Patch: libcpp, c-family, Fortran] Re: Warning about __DATE__ and __TIME__

Ian Lance Taylor wrote: On Wed, Nov 6, 2013 at 7:37 AM, Tom Tromey wrote: Tobias> + cpp_warning (pfile, CPP_W_DATE_TIME, "Macro \"%s\" might prevent " Tobias> + "reproduce builds", NODE_NAME (node)); Tobias> + cpp_warning (pfile, CPP_W_DATE_TIME, "Macro \"%s

[wide-int] Remove shift truncation from wide-int.h

After the previous two patches, we can remove the shift truncation from wide-int.h, which simplifies the interface and makes it behave more like double_int does now. At the same time I generalised the rotate code to handle non-power-of-2 widths. Tested on powerpc64-linux-gnu and by comparing asse

Re: Re-factor tree.h - Part 1

On 11/05/13 20:22, Diego Novillo wrote: This is the first patch in a series of patches to cleanup tree.h to reduce the exposure it has all over the compiler. [ ... ] Additionally, the patch removes functions that were never used. This part should just go forward and should be considered pre-a

[gomp4] rewrite simd clone argument adjustment to avoid regimplification

On 11/04/13 08:44, Jakub Jelinek wrote: I guess short time yes, but I wonder if it wouldn't be better to use walk_gimple_op and do all changes in the callback. Instead of passing adjustments pass around a struct containing the adjustments, current stmt and the modified flag. You can use the val

[wide-int] Tweak handling of rtx shifts

This patch makes the shift code in simplify-rtx.c more like the CONST_INT handling on mainline. There we have: case LSHIFTRT: case ASHIFT: case ASHIFTRT: /* Truncate the shift if SHIFT_COUNT_TRUNCATED, otherwise make sure the value is in range. We c

RE: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Sorry Dodji, I still do not see how this is supposed to work: If the previous invocation of get_line already had read some characters of the following line(s), how is that information recovered? I see it is copied behind lineptr[cur_len]. But when get_line is re-entered, cur_len is set to zero a

Re: [PATCH, i386]: Fix PR 59021, new vzeroupper instructions generated with -mavx

On Wed, Nov 6, 2013 at 11:06 PM, Eric Botcazou wrote: >> Attached patch fixes PR 59021, where new vzeroupper instructions are >> generated for -mavx after Vlad's useless insn removal patch. >> >> The problem was, that we depent on (useless) moves to AVX256 function >> argument registers in front o

Re: [PATCH] Use get_range_info during number of iterations analysis

On 11/06/13 10:23, Jakub Jelinek wrote: On Wed, Nov 06, 2013 at 06:13:42PM +0100, Jakub Jelinek wrote: I've looked at the above testcase to see why we aren't able to determine the number of iterations upper bound properly here. And here is a patch that uses get_range_info during # of iteration

[wide-int] Remove SHIFT_COUNT_TRUNCATED uses at tree/gimple level

Following the removal of SHIFT_COUNT_TRUNCATED from double-int, this patch reverts the changed I'd made to mimic the old behaviour on wide-int. Tested on powerpc64-linux-gnu and by assembly comparison on a range of targets. OK to install? Thanks, Richard Index: gcc/fold-const.c

Re: [PATCH, i386]: Fix PR 59021, new vzeroupper instructions generated with -mavx

> Attached patch fixes PR 59021, where new vzeroupper instructions are > generated for -mavx after Vlad's useless insn removal patch. > > The problem was, that we depent on (useless) moves to AVX256 function > argument registers in front of the function call to switch the mode to > DIRTY mode. Thi

Re: [wide-int] Do not treat rtxes as sign-extended

Richard Biener writes: > On Sat, Nov 2, 2013 at 3:25 PM, Richard Sandiford > wrote: >> Kenneth Zadeck writes: >>> On 11/02/2013 06:30 AM, Richard Sandiford wrote: Bah. After all that effort, it turns out that -- by design -- there is one special case where CONST_INTs are not sign-exte

Re: [PATCH] Improve VRP assert creation for loops

On 11/06/13 10:13, Jakub Jelinek wrote: On Tue, Nov 05, 2013 at 02:00:16PM -0800, Cong Hou wrote: I'm also curious -- did this code show up in a particular benchmark, if so, which one? I didn't find this problem from any benchmark, but from another concern about loop upper bound estimation. Lo

Re: [gofrontend-dev] Moved gccgo branch to mainline

On Wed, Nov 6, 2013 at 1:51 PM, Michael Hudson-Doyle wrote: > Ian Lance Taylor writes: > >> I removed the gccgo branch based on the GCC 4.8 branch, and then >> recreated it as a copy of mainline. Future changes to the gccgo >> branch will be merged from mainline. > > This is probably a silly que

Re: PATCHES: [4.9 Regression] libsanitizer doesn't build for x32

On Wed, Nov 6, 2013 at 12:45 PM, Jakub Jelinek wrote: > On Wed, Nov 06, 2013 at 12:37:42PM -0800, H.J. Lu wrote: >> diff --git a/libsanitizer/ChangeLog.x32 b/libsanitizer/ChangeLog.x32 >> new file mode 100644 >> index 000..7b54005 >> --- /dev/null >> +++ b/libsanitizer/ChangeLog.x32 >> @@ -0,0

Re: [gofrontend-dev] Moved gccgo branch to mainline

Ian Lance Taylor writes: > I removed the gccgo branch based on the GCC 4.8 branch, and then > recreated it as a copy of mainline. Future changes to the gccgo > branch will be merged from mainline. This is probably a silly question, but presuamably bug fixes to the 4.8 gccgo will continue to lan

[PATCH] Factorize the two read_line functions present in gcov.c and input.c

Hello, It appeared that gcov.c and input.c both have a static function named read_line. I guess we ought to keep just one. So I changed the one in input.c as it handles lines with bytes of zero value (as of the work on PR preprocessor/58580) to make it suitable for what the uses of read_line in

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/13 13:56, Andrew MacLeod wrote: 5 - When done we will be significantly closer to having the ability to create a self contained IL that we can strictly define... That alone seems a worthwhile goal to me. The IL then becomes appropriate for streaming at any point in during compilation.

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/13 02:31, Richard Biener wrote: We decided to move to C++. As part of a later discussion we decided to go with a single general dynamic-casting style, mimicing the "real" C++ variant which is dynamic_cast < ... >. Which resulted in is-a.h. So yes, we've decided to go C++ so we have

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/13 06:23, Joseph S. Myers wrote: On Wed, 6 Nov 2013, Jakub Jelinek wrote: On Wed, Nov 06, 2013 at 12:31:00PM +0100, Richard Biener wrote: Maybe we need to revisit it? As one of those who were not in favour of the C++ move, can I ask you guys to step back for a moment and think about -

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/13 04:42, Jakub Jelinek wrote: On Wed, Nov 06, 2013 at 12:31:00PM +0100, Richard Biener wrote: Maybe we need to revisit it? As one of those who were not in favour of the C++ move, can I ask you guys to step back for a moment and think about - what do all of these changes buy us, exactly

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/2013 06:31 AM, Richard Biener wrote: On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt wrote: Maybe we need to revisit it? As one of those who were not in favour of the C++ move, can I ask you guys to step back for a moment and think about - what do all of these changes buy us, exactly?

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/13 04:31, Richard Biener wrote: On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt wrote: On 11/06/2013 10:31 AM, Richard Biener wrote: We decided to move to C++. As part of a later discussion we decided to go with a single general dynamic-casting style, mimicing the "real" C++ variant w

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On Wed, Nov 06, 2013 at 01:38:23PM -0700, Jeff Law wrote: > On 11/05/13 16:23, Ian Lance Taylor wrote: > >On Tue, Nov 5, 2013 at 2:12 PM, Jeff Law wrote: > >> > >>I can't speak for Andrew, but my experience with this kind of object type > >>casting in a large C++ project is that it's a red flag fo

Moved gccgo branch to mainline

I removed the gccgo branch based on the GCC 4.8 branch, and then recreated it as a copy of mainline. Future changes to the gccgo branch will be merged from mainline. The effect is that the gccgo branch now provides an early snapshot of Go 1.2. I tagged the former gccgo branch as tags/gccgo-go1_1

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/13 04:02, Bernd Schmidt wrote: On 11/06/2013 10:31 AM, Richard Biener wrote: We decided to move to C++. As part of a later discussion we decided to go with a single general dynamic-casting style, mimicing the "real" C++ variant which is dynamic_cast < ... >. Which resulted in is-a.h.

Re: PATCHES: [4.9 Regression] libsanitizer doesn't build for x32

On Wed, Nov 06, 2013 at 12:37:42PM -0800, H.J. Lu wrote: > diff --git a/libsanitizer/ChangeLog.x32 b/libsanitizer/ChangeLog.x32 > new file mode 100644 > index 000..7b54005 > --- /dev/null > +++ b/libsanitizer/ChangeLog.x32 > @@ -0,0 +1,20 @@ Just put it into libsanitizer/ChangeLog, please don'

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/05/13 16:23, Ian Lance Taylor wrote: On Tue, Nov 5, 2013 at 2:12 PM, Jeff Law wrote: I can't speak for Andrew, but my experience with this kind of object type casting in a large C++ project is that it's a red flag for a design problem. I'm going to chime in to say that I think it's a p

PATCHES: [4.9 Regression] libsanitizer doesn't build for x32

These 4 patches fix libsanitizer build for x32. They will be checked into upstream: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018#c4 In the meantime, OK to install to unblock x32 build? Thanks. H.J. >From de59975f158501bc99b345c02687944a49c9d31c Mon Sep 17 00:00:00 2001 From: "H.J. Lu" D

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/13 13:01, Tom Tromey wrote: "Jeff" == Jeff Law writes: Jeff> ISTM that one liner belongs in GCC's .gdbinit. Until then, I'm adding Jeff> it to my own :-) Yeah, I think that would be reasonable. It seems like it isn't appropriate in many cases, so we left it off by default. Here's t

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

> "Jeff" == Jeff Law writes: Jeff> ISTM that one liner belongs in GCC's .gdbinit. Until then, I'm adding Jeff> it to my own :-) Yeah, I think that would be reasonable. It seems like it isn't appropriate in many cases, so we left it off by default. Tom

[gomp4 4/9] OpenACC: The runtime library will be implemented in libgomp, too.

From: Thomas Schwinge gcc/ * gcc.c (LINK_COMMAND_SPEC, GOMP_SELF_SPECS): For -fopenacc, link to libgomp and its dependencies. * config/arc/arc.h (LINK_COMMAND_SPEC): Likewise. * config/darwin.h (LINK_COMMAND_SPEC_A): Likewise. * config/i386/mingw32.

[gomp4 6/9] OpenACC: Infrastructure for builtins.

From: Thomas Schwinge gcc/ * oacc-builtins.def: New file. * Makefile.in (BUILTINS_DEF): Add oacc-builtins.def. * builtins.def (DEF_GOACC_BUILTIN): New macro. Include "oacc-builtins.def". gcc/fortran/ * f95-lang.c (DEF_GOACC_BUILTIN): New mac

[gomp4 8/9] OpenACC: Basic support for #pragma acc in the C front end.

From: Thomas Schwinge gcc/c-family/ * c-pragma.c (oacc_pragmas): New array. (c_pp_lookup_pragma, init_pragma): Handle it. gcc/ * doc/invoke.texi (-fopenacc): Update. gcc/c/ * c-parser.c (c_parser_omp_all_clauses): Make a parser error

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

On Wed, Nov 06, 2013 at 08:42:23PM +0100, tho...@codesourcery.com wrote: > +#define OACC_PARALLEL_CLAUSE_MASK\ > + PRAGMA_OMP_CLAUSE_NONE This is incorrect, either you should define in c-common.h also OMP_CLAUSE_MASK_0 and define this to it, or it needs to be (OMP_CLAUSE_MA

Committed patch implementing live range shrinkage.

Here is the final version of the patch I committed as rev.204465. It takes Jeff's proposal into account. The patch was successfully bootstrapped with -flive-range-shrinkage on x86 and x86-64. 2013-11-06 Vladimir Makarov * tree-pass.h (make_pass_live_range_shrinkage): New ext

[PATCH, i386]: Fix PR 59021, new vzeroupper instructions generated with -mavx

Hello! Attached patch fixes PR 59021, where new vzeroupper instructions are generated for -mavx after Vlad's useless insn removal patch. The problem was, that we depent on (useless) moves to AVX256 function argument registers in front of the function call to switch the mode to DIRTY mode. This is

[gomp4 7/9] OpenACC: Use OpenMP's lowering and expansion passes.

From: Thomas Schwinge gcc/ * gimplify.c (gimplify_body): Consider flag_openacc additionally to flag_openmp. * omp-low.c (execute_expand_omp, execute_lower_omp) (gate_diagnose_omp_blocks): Likewise. gcc/testsuite/ * gcc.dg/goacc-gomp/goacc-go

[gomp4 3/9] OpenACC: Recognize -fopenacc.

From: Thomas Schwinge gcc/c-family/ * c.opt (fopenacc): New option. gcc/fortran/ * lang.opt (fopenacc): New option. * invoke.texi (-fopenacc): Document it. * gfortran.h (gfc_option_t): New member. * options.c (gfc_init_options, gfc_handle_op

[gomp4 5/9] OpenACC: preprocessor definition, Fortran integer parameter.

From: Thomas Schwinge gcc/c-family/ * c-cppbuiltin.c (c_cpp_builtins): Conditionally define _OPENACC. gcc/fortran/ * cpp.c (cpp_define_builtins): Conditionally define _OPENACC. gcc/testsuite/ * c-c++-common/cpp/openacc-define-1.c: Test _OPENACC.

[gomp4 1/9] Add missing include.

From: Thomas Schwinge libgomp/ * libgomp_g.h: Include for size_t. --- libgomp/libgomp_g.h | 1 + 1 file changed, 1 insertion(+) diff --git libgomp/libgomp_g.h libgomp/libgomp_g.h index 32c4cf6..577956a 100644 --- libgomp/libgomp_g.h +++ libgomp/libgomp_g.h @@ -29,6 +29,7 @@ #d

[gomp4 2/9] libgomp: Prepare for testcases without -fopenmp.

From: Thomas Schwinge libgomp/ * testsuite/lib/libgomp.exp (libgomp_init): Don't add -fopenmp to ALWAYS_CFLAGS. * testsuite/libgomp.c++/c++.exp (ALWAYS_CFLAGS): Add -fopenmp. * testsuite/libgomp.c/c.exp (ALWAYS_CFLAGS): Likewise. * testsuite/libgomp

Initial submission of OpenACC support integrated into OpenMP's lowering and expansion passes

Hi! Here is our take of adding OpenACC support to GCC's front end and middle end. What I post here (that is, as replies to this email, to gcc-patches only) is still very incomplete, but hopefully enough to outline the general approach, and I'd like to commit these patches to gomp-4_0-branch -- OK

Re: [C++ Patch, Java related/RFC] PR 11006

On 11/06/2013 05:42 AM, Andrew Haley wrote: On 11/04/2013 05:21 PM, Jason Merrill wrote: Surely it should be valid to allocate a Java boolean type. Andrew, how should that work? It's not allowed. All objects that are allocated by new must be of class type (i.e. instances of a subclass of ja

Re: [Patch, RTL] Eliminate redundant vec_select moves.

On Wed, 2013-11-06 at 17:34 +, Richard Sandiford wrote: > Tejas Belagod writes: > > Richard Sandiford wrote: > >> Tejas Belagod writes: > >>> Richard Sandiford wrote: > Tejas Belagod writes: > > + /* This is big-endian-safe because the elements are kept in target > > + memo

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/13 11:04, Tom Tromey wrote: "Jakub" == Jakub Jelinek writes: Jakub> 1) p debug_tree (0x718b3690) Jakub>not working anymore, typically one would use this when just Jakub>cut'n'pasting addresses seen in backtrace, other debug_tree Jakub>etc., one now has to add explicitl

Clean up configure glibc version detection, add --with-glibc-version

When bootstrapping a cross toolchain with GCC and glibc, it's desirable to keep down the number of GCC builds needed: to be able to build an initial static-only C-only GCC, use that to build glibc, and then build the full compiler with the resulting glibc. The aim is that if glibc were then rebuil

Re: [PATCH, MPX, 2/X] Pointers Checker [7/25] Suppress BUILT_IN_CHKP_ARG_BND optimizations.

2013/11/6 Michael Matz : > Hi, > > On Wed, 6 Nov 2013, Ilya Enkovich wrote: > >> >>> Well, but clearly you can see that bounds for p == NULL are >> >>> useless and thus there is no problem with the transform. >> >> >> >> This example just demonstrates the issue. I may use some var's address >> >> i

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

> "Jakub" == Jakub Jelinek writes: Jakub> 1) p debug_tree (0x718b3690) Jakub>not working anymore, typically one would use this when just Jakub>cut'n'pasting addresses seen in backtrace, other debug_tree Jakub>etc., one now has to add explicitly a cast p debug_tree Jakub>((

Re: [Patch, RTL] Eliminate redundant vec_select moves.

Tejas Belagod writes: > Richard Sandiford wrote: >> Tejas Belagod writes: >>> Richard Sandiford wrote: Tejas Belagod writes: > + /* This is big-endian-safe because the elements are kept in target > + memory order. So, for eg. PARALLEL element value of 2 is the same > in >

Re: [PATCH, MPX, 2/X] Pointers Checker [7/25] Suppress BUILT_IN_CHKP_ARG_BND optimizations.

Hi, On Wed, 6 Nov 2013, Ilya Enkovich wrote: > >>> Well, but clearly you can see that bounds for p == NULL are > >>> useless and thus there is no problem with the transform. > >> > >> This example just demonstrates the issue. I may use some var's address > >> in comparison with the similar result

Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib

On 24 October 2013 17:47, Steve Ellcey wrote: > I am not sure how we would fix the build issue to allow us to not > hardcode the newlib configure details into the libgfortran configure > script. The linker script that needs to be used to get a good link is > different depending on what options o

[PATCH] Fix PR58697

This fixes PR58697 by instead of trying to preserve reference structure when generating initial loads for the predictive commoned loop, just builds an approprate MEM_REF. That now can handle the cases that previously could be discovered as non-trapping (all constant offsets). I don't see a bette

[PATCH] Use get_range_info during number of iterations analysis

On Wed, Nov 06, 2013 at 06:13:42PM +0100, Jakub Jelinek wrote: > I've looked at the above testcase to see why we aren't able to determine > the number of iterations upper bound properly here. And here is a patch that uses get_range_info during # of iterations analysis, so that for your testcase we

[PATCH] Improve VRP assert creation for loops

On Tue, Nov 05, 2013 at 02:00:16PM -0800, Cong Hou wrote: > > I'm also curious -- did this code show up in a particular benchmark, if so, > > which one? > > I didn't find this problem from any benchmark, but from another > concern about loop upper bound estimation. Look at the following code: > >

Re: Re-factor tree.h - Part 1

On Wed, Nov 6, 2013 at 11:54 AM, Jeff Law wrote: > On 11/06/13 00:04, Marc Glisse wrote: >> >> On Tue, 5 Nov 2013, Diego Novillo wrote: >> >>> This is the first patch in a series of patches to cleanup tree.h to >>> reduce the exposure it has all over the compiler. >>> >>> In this patch, I'm moving

Re: Re-factor tree.h - Part 1

On Wed, Nov 6, 2013 at 2:04 AM, Marc Glisse wrote: > On Tue, 5 Nov 2013, Diego Novillo wrote: > >> This is the first patch in a series of patches to cleanup tree.h to >> reduce the exposure it has all over the compiler. >> >> In this patch, I'm moving functions that are used once into the files >>

Re: [PATCH]Fix computation of offset in ivopt

Hi, "bin.cheng" writes: > Index: gcc/tree-ssa-loop-ivopts.c > === > --- gcc/tree-ssa-loop-ivopts.c(revision 203267) > +++ gcc/tree-ssa-loop-ivopts.c(working copy) > @@ -2037,12 +2037,12 @@ find_interesting_uses (struc

Re: [Patch, RTL] Eliminate redundant vec_select moves.

Richard Sandiford wrote: Tejas Belagod writes: Richard Sandiford wrote: Tejas Belagod writes: + /* This is big-endian-safe because the elements are kept in target + memory order. So, for eg. PARALLEL element value of 2 is the same in + either endian-ness. */ + if (GET_CODE (src)

Re: [Patch, RTL] Eliminate redundant vec_select moves.

On Wed, 2013-11-06 at 10:42 -0600, Bill Schmidt wrote: > On Wed, 2013-11-06 at 15:01 +0100, Richard Biener wrote: > > On Wed, Nov 6, 2013 at 2:24 PM, Tejas Belagod wrote: > > > > > > Hi, > > > > > > The attached patch eliminates moves of the form > > > > > > set( (reg:DI n) vec_select:DI

Re: patch implementing a new pass for register-pressure relief through live range shrinkage

On 11/6/2013, 4:17 AM, Richard Biener wrote: On Tue, Nov 5, 2013 at 4:35 PM, Vladimir Makarov wrote: I'd like to add a new experimental optimization to the trunk. This optimization was discussed on RA BOF of this summer GNU Cauldron. It is a register pressure relief through live-range s

Re: [RFA][PATCH] Isolate erroneous paths optimization

On 11/06/13 08:27, Jakub Jelinek wrote: On Wed, Nov 06, 2013 at 04:23:06PM +0100, Richard Biener wrote: In that case I think it would be fine to run the isolate paths optimization, but to not omit the actual dereference of the NULL pointer (possibly the dereference could be followed by a trap).

Re: Re-factor tree.h - Part 1

On 11/06/13 00:04, Marc Glisse wrote: On Tue, 5 Nov 2013, Diego Novillo wrote: This is the first patch in a series of patches to cleanup tree.h to reduce the exposure it has all over the compiler. In this patch, I'm moving functions that are used once into the files that use them, and make the

Disable floating-point contraction in ISO C conformance modes

In , I noted that, as I'd previously noted in , ISO C conformance modes should set -ffp-contract=on (= -ffp-contract=off) rather than the default -ffp-contract=fast, given the ISO C res

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On Wed, Nov 06, 2013 at 11:25:31AM -0500, David Malcolm wrote: > On Wed, 2013-11-06 at 14:11 +0100, Jakub Jelinek wrote: > > On Wed, Nov 06, 2013 at 02:00:56PM +0100, Richard Biener wrote: > > > Well, what else, besides as_a<> or keeping the current > > > global accessor functions would you propose

Re: [PATCH] Add gimple subclasses for every gimple code (was Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3))

Hi, On Tue, 5 Nov 2013, David Malcolm wrote: > Here's a followup patch which ensures that every gimple code has its own > subclass, by adding empty subclasses derived from the GSS_-based > subclasses as appropriate (I don't bother for gimple codes that already > have their own subclass due to hav

  1   2   >