RE: [PATCH GCC]Simplify address expression in IVOPT

> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: Wednesday, October 30, 2013 10:46 PM > To: Bin Cheng > Cc: GCC Patches > Subject: Re: [PATCH GCC]Simplify address expression in IVOPT > > On Tue, Oct 29, 2013 at 10:18 AM, bin.cheng wrote: > > Hmm.

Re: [wide-int] Update main comment

On Wed, 30 Oct 2013, Richard Sandiford wrote: > Kenneth Zadeck writes: > > On 10/30/2013 07:01 AM, Richard Sandiford wrote: > >> Kenneth Zadeck writes: > >>> On 10/29/2013 06:37 PM, Richard Sandiford wrote: > This patch tries to update the main wide_int comment to reflect the > curren

[wide-int] Fix UNSIGNED_FIX typo

"t" had got switched to "x" during the conversion. This showed up in one of the alpha g++.dg tests. Applied as obvious. Richard Index: gcc/simplify-rtx.c === --- gcc/simplify-rtx.c 2013-11-03 13:01:39.083385620 + +++ gcc/simp

Re: [wide-int] Avoid some changes in output code

On Fri, 1 Nov 2013, Richard Sandiford wrote: > I'm building one target for each supported CPU and comparing the wide-int > assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding > output from the merge point. This patch removes all the differences I saw > for alpha-linux-gnu i

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

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 === --- gcc/tree.

Re: [wide-int] Avoid some changes in output code

On Mon, 4 Nov 2013, Richard Biener wrote: > On Fri, 1 Nov 2013, Richard Sandiford wrote: > > > I'm building one target for each supported CPU and comparing the wide-int > > assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding > > output from the merge point. This patch remo

Re: [wide-int] Avoid some changes in output code

Richard Biener writes: > On Fri, 1 Nov 2013, Richard Sandiford wrote: >> I'm building one target for each supported CPU and comparing the wide-int >> assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding >> output from the merge point. This patch removes all the differences I

Re: [wide-int] Avoid some changes in output code

Richard Biener writes: > On Mon, 4 Nov 2013, Richard Biener wrote: > >> On Fri, 1 Nov 2013, Richard Sandiford wrote: >> >> > I'm building one target for each supported CPU and comparing the wide-int >> > assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding >> > output from t

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

> Thanks! Can you attach the patch file for the proposed change? > > David > > On Fri, Nov 1, 2013 at 2:08 PM, Rong Xu wrote: > > libgcov.c is the main file to generate libgcov.a. This single source > > generates > > 21 object files and then archives to a library. These objects are of > > very

Re: [PATCH 1/n] Add conditional compare support

+ "TARGET_ARM || TARGET_THUMB2" TARGET_32BIT +static const char *const ite = "it\t%d4"; +static const int cmp_idx[9] = {0, 0, 1, 0, 1}; s/9/5/ On Wed, Oct 30, 2013 at 5:32 PM, Zhenqiang Chen wrote: > >> -Original Message- >> From: Richard Henderson [mailto:r...@redhat.com] >> Se

Re: [wide-int] Avoid some changes in output code

On Mon, 4 Nov 2013, Richard Sandiford wrote: > Richard Biener writes: > > On Fri, 1 Nov 2013, Richard Sandiford wrote: > >> I'm building one target for each supported CPU and comparing the wide-int > >> assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding > >> output from th

RE: [PATCH 1/n] Add conditional compare support

> -Original Message- > From: Richard Henderson [mailto:r...@redhat.com] > Sent: Friday, November 01, 2013 12:27 AM > To: Zhenqiang Chen > Cc: Richard Earnshaw; 'Richard Biener'; GCC Patches > Subject: Re: [PATCH 1/n] Add conditional compare support > > On 10/31/2013 02:06 AM, Zhenqiang Ch

Re: [PATCH] Introducing SAD (Sum of Absolute Differences) operation to GCC vectorizer.

On Fri, Nov 01, 2013 at 04:48:53PM +, Cong Hou wrote: > diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi > index 2a5a2e1..8f5d39a 100644 > --- a/gcc/doc/md.texi > +++ b/gcc/doc/md.texi > @@ -4705,6 +4705,16 @@ wider mode, is computed and added to operand 3. > Operand 3 is of a mode equal or > wi

Re: [wide-int] Avoid some changes in output code

On Mon, 4 Nov 2013, Richard Sandiford wrote: > Richard Biener writes: > > On Mon, 4 Nov 2013, Richard Biener wrote: > > > >> On Fri, 1 Nov 2013, Richard Sandiford wrote: > >> > >> > I'm building one target for each supported CPU and comparing the wide-int > >> > assembly output of gcc.c-torture,

Re: [PATCH] Fix up reassoc (PR tree-optimization/58946)

On Fri, 1 Nov 2013, Jakub Jelinek wrote: > Hi! > > My recent reassoc patch caused following regression (though, it only started > failing on this testcase with Andrew's ifcombine changes). > > The issue is that update_ops relies on walking the same stmts as get_ops > did, and uses has_single_use

PATCH: middle-end/58981: movmem/setmem use mode wider than Pmode for size

emit_block_move_via_movmem and set_storage_via_setmem have for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode; mode = GET_MODE_WIDER_MODE (mode)) { enum insn_code code = direct_optab_handler (movmem_optab, mode); if (code != CODE_FOR_nothing /* We

Re: RFC: simd enabled functions (omp declare simd / elementals)

On Fri, Nov 1, 2013 at 4:04 AM, Aldy Hernandez wrote: > Hello gentlemen. I'm CCing all of you, because each of you can provide > valuable feedback to various parts of the compiler which I touch. I have > sprinkled love notes with your names throughout the post :). > > This is a patch against the

Re: [PATCH] Handle __builtin_unreachable () using assertions in VRP

On 04/11/13 01:59, Tom de Vries wrote: > On 29/10/13 14:54, Jakub Jelinek wrote: >> +/* Return true if all imm uses of VAR are either in STMT, or >> + feed (optionally through a chain of single imm uses) GIMPLE_COND >> + in basic block COND_BB. */ >> + >> +static bool >> +all_imm_uses_in_stmt_

Re: [PATCH] Time profiler - phase 1

> diff --git a/gcc/ChangeLog b/gcc/ChangeLog > index fca665b..3b62bcc 100644 > --- a/gcc/ChangeLog > +++ b/gcc/ChangeLog > @@ -1,3 +1,31 @@ > +2013-10-29 Martin Liska > + Jan Hubicka > + > + * cgraph.c (dump_cgraph_node): Profile dump added. > +

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich wrote: > Hi, > > This patch adds support Pointer Bounds Checker into c-family and LTO > front-ends. The main purpose of changes in front-end is to register all > statically initialized objects for checker. We also need to register such > objects

Re: PR 58958: wrong aliasing info

On Fri, Nov 1, 2013 at 11:39 PM, Marc Glisse wrote: > Hello, > > the issue was described in the PR and the message linked from there. > ao_ref_init_from_ptr_and_size calls get_ref_base_and_extent, which may > detect an array_ref of variable index, but ao_ref_init_from_ptr_and_size > never learns o

Re: RFC: simd enabled functions (omp declare simd / elementals)

Hi! On Mon, Nov 04, 2013 at 11:37:19AM +0100, Richard Biener wrote: > Just a quick question, queueing the thread for later review (aww, queue > back at >100 threads again - I can't get any work done anymore :(). > > What does #pragma omp declare simd guarantee about memory > side-effects and memo

Re: PR 58958: wrong aliasing info

On Mon, Nov 4, 2013 at 11:55 AM, Richard Biener wrote: > On Fri, Nov 1, 2013 at 11:39 PM, Marc Glisse wrote: >> Hello, >> >> the issue was described in the PR and the message linked from there. >> ao_ref_init_from_ptr_and_size calls get_ref_base_and_extent, which may >> detect an array_ref of var

Re: Expect JUMP_TABLE_DATA in NEXT_INSN(label)

On Sat, Nov 2, 2013 at 1:45 AM, Steven Bosscher wrote: > Hello, > > As $SUBJECT. The assert for this has been in place for several months > now without triggering any issues, so I'd like to make this next step > before stage1 is over. > > OK for trunk? Ok. Can you verify this from some RTL insn

Re: PR 58958: wrong aliasing info

On Mon, 4 Nov 2013, Richard Biener wrote: On Fri, Nov 1, 2013 at 11:39 PM, Marc Glisse wrote: Hello, the issue was described in the PR and the message linked from there. ao_ref_init_from_ptr_and_size calls get_ref_base_and_extent, which may detect an array_ref of variable index, but ao_ref_in

Re: PATCH: middle-end/58981: movmem/setmem use mode wider than Pmode for size

"H.J. Lu" writes: > emit_block_move_via_movmem and set_storage_via_setmem have > > for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode; >mode = GET_MODE_WIDER_MODE (mode)) > { > enum insn_code code = direct_optab_handler (movmem_optab, mode); > > if (code !=

Re: PR 58958: wrong aliasing info

On Mon, 4 Nov 2013, Richard Biener wrote: On Mon, Nov 4, 2013 at 11:55 AM, Richard Biener wrote: On Fri, Nov 1, 2013 at 11:39 PM, Marc Glisse wrote: Hello, the issue was described in the PR and the message linked from there. ao_ref_init_from_ptr_and_size calls get_ref_base_and_extent, which

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

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-extended. >>> Nonzero/true BImode in

[C++ PATCH] Fix PR58979

Even RO_ARROW_STAR can end up in invalid_indirection_error in invalid code, so handle that instead of ICEing later on. Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8? 2013-11-04 Marek Polacek PR c++/58979 c-family/ * c-common.c (invalid_indirection_error): Handle

Re: [wide-int] Simplify some force_fit_type calls

On Sun, Nov 3, 2013 at 11:31 AM, Richard Sandiford wrote: > When going through force_fit_type calls to see whether they were > extending correctly, I noticed some of the calls in VRP could be simplified. > > There's no change in behaviour, it's just shorter and more efficient. > > Tested on powerp

Re: PATCH: middle-end/58981: movmem/setmem use mode wider than Pmode for size

Y On Mon, Nov 4, 2013 at 3:11 AM, Richard Sandiford wrote: > "H.J. Lu" writes: >> emit_block_move_via_movmem and set_storage_via_setmem have >> >> for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode; >>mode = GET_MODE_WIDER_MODE (mode)) >> { >> enum insn_code cod

Re: [PATCH GCC]Compute, cache and use cost of auto-increment rtx patterns in IVOPT

On Mon, Nov 4, 2013 at 4:31 AM, bin.cheng wrote: > Hi, > > The IVOPT in GCC has a problem that it does not use cost of auto-increment > address expression in accounting, while it retreats to cost of address > expression if auto-increment addressing mode is unavailable. > For example, on ARM target

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

Jakub Jelinek writes: > I think even as a fallback is the patch too expensive. > I'd say best would be to write some getline API compatible function > and just use it, using fread on say fixed size buffer. OK, thanks for the insight. I have just used the getline_fallback function you proposed,

Re: Patch RFA: With -fnon-call-exceptions sync builtins may throw

On Mon, Nov 4, 2013 at 7:01 AM, Ian Lance Taylor wrote: > The middle-end currently marks all the sync builtins as nothrow. That > is incorrect for most of them when using -fnon-call-exceptions. The > -fnon-call-exceptions option means that instructions that trap may throw > exceptions. Most of

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

On Mon, Nov 04, 2013 at 12:46:10PM +0100, Dodji Seketeli wrote: > --- a/gcc/diagnostic.c > +++ b/gcc/diagnostic.c > @@ -259,12 +259,13 @@ diagnostic_build_prefix (diagnostic_context *context, > MAX_WIDTH by some margin, then adjust the start of the line such > that the COLUMN is smaller tha

Re: PR 58958: wrong aliasing info

On Mon, Nov 4, 2013 at 12:18 PM, Marc Glisse wrote: > On Mon, 4 Nov 2013, Richard Biener wrote: > >> On Mon, Nov 4, 2013 at 11:55 AM, Richard Biener >> wrote: >>> >>> On Fri, Nov 1, 2013 at 11:39 PM, Marc Glisse >>> wrote: Hello, the issue was described in the PR and the mess

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

Hi, I see another "read_line" at gcov.c, which seems to be a copy. Maybe this should be changed too? What do you think? Bernd. On Mon, 4 Nov 2013 12:46:10, Dodji Seketeli wrote: > > Jakub Jelinek writes: > >> I think even as a fallback is the patch too expensive. >> I'd say best would be to

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

On Mon, Nov 04, 2013 at 12:59:49PM +0100, Bernd Edlinger wrote: > I see another "read_line" at gcov.c, which seems to be a copy. Copy of what? gcov.c read_line hardly can be allowed to fail because out of mem unlike this one for caret diagnostics. Though, surely, this one could be somewhat adjust

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

> > On Mon, Nov 04, 2013 at 12:59:49PM +0100, Bernd Edlinger wrote: >> I see another "read_line" at gcov.c, which seems to be a copy. > > Copy of what? gcov.c read_line hardly can be allowed to fail because out of > mem unlike this one for caret diagnostics. > Though, surely, this one could be some

Re: [PATCH, MPX, 2/X] Pointers Checker [5/25] Tree and gimple ifaces

On Wed, Oct 30, 2013 at 5:20 PM, Jeff Law wrote: > On 10/30/13 04:34, Ilya Enkovich wrote: >> >> On 30 Oct 10:26, Richard Biener wrote: >>> >>> >>> Ick - you enlarge all return statements? But you don't set the >>> actual value? So why allocate it with 2 ops in the first place?? >> >> >> When ret

Re: [PATCH, MPX, 2/X] Pointers Checker [5/25] Tree and gimple ifaces

On Wed, Oct 30, 2013 at 6:40 PM, Jeff Law wrote: > On 10/30/13 04:48, Richard Biener wrote: >> >> foo (int * p, unsigned int size) >> { >> __bound_tmp.0; >>long unsigned int D.2239; >>long unsigned int _2; >>sizetype _6; >>int * _7; >> >>: >>__bound_tmp.0_4 = __builtin_

Re: PATCH to use -Wno-format during stage1

On Wed, Oct 30, 2013 at 8:55 PM, Ian Lance Taylor wrote: > On Wed, Oct 30, 2013 at 8:47 AM, Jason Merrill wrote: >> I find -Wformat warnings about unknown % codes when building with an older >> GCC to be mildly annoying noise; this patch avoids them by passing >> -Wno-format during stage 1. >> >>

Re: [PATCH][RFA] Improvements to infer_nonnull_range

On Thu, Oct 31, 2013 at 6:41 AM, Jeff Law wrote: > On 10/28/13 23:02, Jeff Law wrote: >> >> >> Based on a suggestion from Marc, I want to use infer_nonnull_range in >> the erroneous path isolation optimization. >> >> In the process of doing that, I found a few deficiencies in >> infer_nonnull_ran

Re: [PATCH GCC]Compute, cache and use cost of auto-increment rtx patterns in IVOPT

On Mon, Nov 4, 2013 at 7:38 PM, Richard Biener wrote: > On Mon, Nov 4, 2013 at 4:31 AM, bin.cheng wrote: >> Hi, >> >> The IVOPT in GCC has a problem that it does not use cost of auto-increment >> address expression in accounting, while it retreats to cost of address >> expression if auto-incremen

Re: PATCH: middle-end/58981: movmem/setmem use mode wider than Pmode for size

On Mon, Nov 4, 2013 at 3:34 AM, H.J. Lu wrote: > Y > On Mon, Nov 4, 2013 at 3:11 AM, Richard Sandiford > wrote: >> "H.J. Lu" writes: >>> emit_block_move_via_movmem and set_storage_via_setmem have >>> >>> for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode; >>>mode = GET_M

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

On 11/01/2013 06:42 PM, David Malcolm wrote: ! gimple_statement_call *call; ! call = gimple_build_call_vec (build_fold_addr_expr_loc (0, alias), vargs); gimple_call_set_lhs (call, atree); that is looking much better :-) I'd love to make use of compile-time type-safety li

[Patch, avr] Emit diagnostics if -f{pic,PIC,pie,PIE} or -shared is passed

The AVR backend does not generate position independent code, yet it happily accepts -fpic, -fPIC, -fpie and -fPIE. The generated code doesn't change at all. Also, it accepts the -shared option to generate a shared library, without really doing anything with it. This causes one of the regression te

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

On Thu, Oct 31, 2013 at 7:11 AM, Jeff Law wrote: > > I've incorporated the various suggestions from Marc and Richi, except for > Richi's to integrate this into jump threading. > > I've also made the following changes since the last version: > > 1. Added more testcases. > > 2. Use infer_nonnull

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

On 11/01/2013 06:58 PM, David Malcolm wrote: On Fri, 2013-11-01 at 22:57 +0100, Jakub Jelinek wrote: On Fri, Nov 01, 2013 at 05:47:14PM -0400, Andrew MacLeod wrote: On 11/01/2013 05:41 PM, Jakub Jelinek wrote: On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote: static inline vo

Re: Pre-Patch RFC: proposed changes to option-lookup

On Wed, Oct 30, 2013 at 11:56 PM, Joseph S. Myers wrote: > On Wed, 30 Oct 2013, David Malcolm wrote: > >> My idea is to introduce a GCC_OPTION macro, and replace the above with: >> >> static bool >> gate_vrp (void) >> { >> return GCC_OPTION (flag_tree_vrp) != 0; >> } > > That's only sl

[PATCH, rs6000] Fix vect_pack_trunc_v2df pattern for little endian

Hi, This cleans up another case where a vector-pack operation needs to reverse its operand order for little endian. This fixes the last remaining vector test failure in the test suite when building for little endian. Next I'll be spending some time looking for additional little endian issues for

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

On Thu, Oct 31, 2013 at 10:02 AM, Ilya Enkovich wrote: > Hi, > > Here is a patch which hadles the problem with optimization of > BUILT_IN_CHKP_ARG_BND calls. Pointer Bounds Checker expects that argument of > this call is a default SSA_NAME of the PARM_DECL whose bounds we want to get. > The p

Re: [PATCH, MPX, 2/X] Pointers Checker [10/25] Calls copy and verification

On Thu, Oct 31, 2013 at 10:24 AM, Ilya Enkovich wrote: > Hi, > > Here is a patch to support of instrumented code in calls verifiers and calls > copy with skipped args. > > Thanks, > Ilya > -- > > gcc/ > > 2013-10-29 Ilya Enkovich > > * cgraph.c (gimple_check_call_args): Handle bound ar

[Patch, testsuite] Require scheduling support in gcc.dg/superblock.c

Hi, gcc.dg/superblock.c uses the -fdump-rtl-sched2 option and then scans the resulting dump. This fails for the AVR target, as it doesn't have any instruction scheduling support. The attached patch makes this test require scheduling support in the target. If ok, could someone commit please? I do

Re: Aliasing: look through pointer's def stmt

On Thu, Oct 31, 2013 at 6:11 PM, Marc Glisse wrote: > On Wed, 30 Oct 2013, Richard Biener wrote: > >>> --- gcc/tree-ssa-alias.c(revision 204188) >>> +++ gcc/tree-ssa-alias.c(working copy) >>> @@ -567,20 +567,29 @@ void >>> ao_ref_init_from_ptr_and_size (ao_ref *ref, tree ptr, tree

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

On 11/01/2013 05:57 PM, Jakub Jelinek wrote: On Fri, Nov 01, 2013 at 05:47:14PM -0400, Andrew MacLeod wrote: On 11/01/2013 05:41 PM, Jakub Jelinek wrote: On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote: static inline void ! gimple_call_set_lhs (gimple gs, tree lhs) { - G

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

On Mon, Nov 04, 2013 at 08:54:40AM -0500, Andrew MacLeod wrote: > >>What checking? There ought to be no checking at all in this > >>example... gimple_build_call_vec returns a gimple_call, and > >>gimple_call_set_lhs() doesn't have to check anything because it > >>only accepts gimple_call's.. so

Re: [PATCH, rs6000] Fix vect_pack_trunc_v2df pattern for little endian

On Mon, Nov 4, 2013 at 8:28 AM, Bill Schmidt wrote: > Hi, > > This cleans up another case where a vector-pack operation needs to > reverse its operand order for little endian. This fixes the last > remaining vector test failure in the test suite when building for little > endian. > > Next I'll be

Re: [PATCH, rs6000] Re-permute source register for postreload splits of VSX LE stores

On Sat, Nov 2, 2013 at 7:44 PM, Bill Schmidt wrote: > Hi, > > When I created the patch to split VSX loads and stores to add permutes > so the register image was correctly little endian, I forgot to implement > a known requirement. When a VSX store is split after reload, we must > reuse the source

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

On 11/04/2013 09:00 AM, Jakub Jelinek wrote: On Mon, Nov 04, 2013 at 08:54:40AM -0500, Andrew MacLeod wrote: What checking? There ought to be no checking at all in this example... gimple_build_call_vec returns a gimple_call, and gimple_call_set_lhs() doesn't have to check anything because it

Re: LRA vs reload on powerpc: 2 extra FAILs that are actually improvements?

Hi, Steven Thanks for investigating this. This presumably was the reason that Vlad changed the constraint modifier for that pattern in his patch for LRA. I don't think that using memory is an improvement, but Mike is the best person to comment. Thanks, David On Sat, Nov 2, 2013 at 6:48 PM, Stev

Re: [wide-int] Avoid some changes in output code

On 11/04/2013 04:12 AM, Richard Biener wrote: On Fri, 1 Nov 2013, Richard Sandiford wrote: I'm building one target for each supported CPU and comparing the wide-int assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding output from the merge point. This patch removes all th

Re: libsanitizer merge from upstream r191666

+glider, our Mac expert. Hi Jack, This patch has not been tested on Mac and we generally do not claim that gcc-asan is supported on Mac. clang-asan *is* supported on Mac and our bots are green (this patch is a merge of the sources which are regularly tested on Mac, but the build procedure is diff

Ping^3 Re: Add predefined macros for library use in defining __STDC_IEC_559*

Ping^3. The addition of a new target hook in this patch is still pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: Ping^3 Re: Add predefined macros for library use in defining __STDC_IEC_559*

On Mon, Nov 04, 2013 at 02:51:37PM +, Joseph S. Myers wrote: > Ping^3. The addition of a new target hook in this patch > is still pending > review. Ok. Jakub

Re: [wide-int] Avoid some changes in output code

Kenneth Zadeck writes: > However, i would also say that it would be nice if were actually done > right. There are (as far as i know) actually 3 ways handling shift > amounts that have been used in the past: > > (1) mask the shift amount by (bitsize - 1). This is the most popular > and is wh

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

Bernd Edlinger writes: > I see another "read_line" at gcov.c, which seems to be a copy. > > Maybe this should be changed too? I have seen it as well. I'd rather have the patch be reviewed and everthing, and only then propose to share the implementation with the gcov module. --

[omp4]

Hi. While looking over some of your testcases I noticed that array subscripts are not being properly adjusted: foo(int i) { array[i] = } The `i' should use the simd array magic instead of ICEing :). Is the attached patch OK for the branch? Aldy gcc/ChangeLog.gomp * omp

Re: [omp4] fix array subscripts in simd clones

On 11/04/13 08:19, Aldy Hernandez wrote: Hi. While looking over some of your testcases I noticed that array subscripts are not being properly adjusted: foo(int i) { array[i] = } The `i' should use the simd array magic instead of ICEing :). Is the attached patch OK for the branch? A

Re: PATCH to use -Wno-format during stage1

On 11/04/2013 07:41 AM, Richard Biener wrote: Please make sure the warning is preserved when not bootstrapping, it's useful to have them in your dev-tree and not notice errors only during -Werror bootstrap ... I found it to be useless noise when not bootstrapping, since my system compiler isn'

Re: [C++ PATCH] Fix PR58979

On 11/04/2013 05:50 AM, Marek Polacek wrote: case RO_ARROW: +case RO_ARROW_STAR: error_at (loc, "invalid type argument of %<->%> (have %qT)", type); I think the diagnostic for RO_ARROW_STAR should say ->*, not just ->. Jason

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

Jakub Jelinek writes: [...] > Eventually, I think using int for sizes is just a ticking bomb, what if > somebody uses > 2GB long lines? Surely, on 32-bit hosts we are unlikely to > handle it, but why couldn't 64-bit host handle it? Column info maybe bogus > in there, sure, but at least we shou

Re: PATCH to use -Wno-format during stage1

On 11/04/2013 04:34 PM, Jason Merrill wrote: On 11/04/2013 07:41 AM, Richard Biener wrote: Please make sure the warning is preserved when not bootstrapping, it's useful to have them in your dev-tree and not notice errors only during -Werror bootstrap ... I found it to be useless noise when not

Re: [omp4]

On Mon, Nov 04, 2013 at 08:19:12AM -0700, Aldy Hernandez wrote: > Hi. > > While looking over some of your testcases I noticed that array > subscripts are not being properly adjusted: > > foo(int i) { > array[i] = > } > > The `i' should use the simd array magic instead of ICEing :). >

Re: PATCH to use -Wno-format during stage1

On Mon, Nov 04, 2013 at 10:34:55AM -0500, Jason Merrill wrote: > On 11/04/2013 07:41 AM, Richard Biener wrote: > >Please make sure the warning is preserved when not bootstrapping, > >it's useful to have them in your dev-tree and not notice errors only > >during -Werror bootstrap ... > > I found it

Re: [PATCH, rs6000] (3/3) Fix mulv4si3 and mulv8hi3 patterns for little endian

Bill Schmidt writes: > + /* We need this to be vmulouh for both big and little endian, > + but for little endian we would swap this, so avoid that. */ > + if (BYTES_BIG_ENDIAN) > + emit_insn (gen_vec_widen_umult_odd_v8hi (low_product, one, two)); > + else > + emit_insn (gen_vec

Re: [C++ PATCH] Fix PR58979

On Mon, Nov 04, 2013 at 10:36:35AM -0500, Jason Merrill wrote: > On 11/04/2013 05:50 AM, Marek Polacek wrote: > > case RO_ARROW: > >+case RO_ARROW_STAR: > >error_at (loc, > > "invalid type argument of %<->%> (have %qT)", > > type); > > I think the diagnosti

Re: [C++ PATCH] Fix PR58979

OK. Jason

Re: Testsuite / Cilk Plus: Include library path in compile flags in gcc.dg/cilk-plus/cilk-plus.exp

Balaji, I am seeing a large number of libcilkrts failures on AIX. These all are of the form: Executing on host: /tmp/20131103/gcc/xgcc -B/tmp/20131103/gcc/ /nasfarm/edelsohn /src/src/gcc/testsuite/c-c++-common/cilk-plus/CK/sync_wo_spawn.c -fno-diagnosti cs-show-caret -fdiagnostics-color=never

Re: [omp4]

On 11/04/13 08:44, Jakub Jelinek wrote: On Mon, Nov 04, 2013 at 08:19:12AM -0700, Aldy Hernandez wrote: Hi. While looking over some of your testcases I noticed that array subscripts are not being properly adjusted: foo(int i) { array[i] = } The `i' should use the simd array magic

patch to fix pr58968

The following patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58968 It is actually the 3rd try to fix the problem. Removing no-ops move may result in mode-switching crashes on x86/x86-64 as it expects a specific code (by the way reload has the same problem on x86/x86-64). The pat

Re: [omp4]

On Mon, Nov 04, 2013 at 09:22:39AM -0700, Aldy Hernandez wrote: > Ok, then let's leave this for later. I'm following what we've done > in tree-sra.c to be consistent. Perhaps later we could even clean > up ipa_sra_modify_function_body in tree-sra.c. But for now I think > we can concentrate on th

Re: [PATCH, rs6000] (3/3) Fix mulv4si3 and mulv8hi3 patterns for little endian

On Mon, 2013-11-04 at 15:48 +, Richard Sandiford wrote: > Bill Schmidt writes: > > + /* We need this to be vmulouh for both big and little endian, > > + but for little endian we would swap this, so avoid that. */ > > + if (BYTES_BIG_ENDIAN) > > + emit_insn (gen_vec_widen_umult_od

Re: Aliasing: look through pointer's def stmt

On Mon, 4 Nov 2013, Richard Biener wrote: Well, host_integer_p (, 0) looks correct to me. But ... Ok, I'll put it back. Index: gcc/tree-ssa-alias.h === --- gcc/tree-ssa-alias.h(revision 204267) +++ gcc/tree-ssa-alias.h

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

Hi, we have got this very old bug, where we ICE in build_java_class_ref because TYPE is an INTEGER_TYPE and we try to use TYPE_FIELDS on it. Shall we apply something like the below and resolve it for good? Alternately, we could maybe provide the same message we currently provide in release-bu

Re: libsanitizer merge from upstream r191666

On Mon, Nov 04, 2013 at 06:47:13AM -0800, Konstantin Serebryany wrote: > +glider, our Mac expert. > > Hi Jack, > > This patch has not been tested on Mac and we generally do not claim > that gcc-asan is supported on Mac. > clang-asan *is* supported on Mac and our bots are green (this patch is > a

Re: PR 58958: wrong aliasing info

On Mon, 4 Nov 2013, Richard Biener wrote: On Mon, Nov 4, 2013 at 12:18 PM, Marc Glisse wrote: On Mon, 4 Nov 2013, Richard Biener wrote: On Mon, Nov 4, 2013 at 11:55 AM, Richard Biener wrote: On Fri, Nov 1, 2013 at 11:39 PM, Marc Glisse wrote: Hello, the issue was described in the PR a

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

Surely it should be valid to allocate a Java boolean type. Andrew, how should that work? Jason

Re: PATCH to use -Wno-format during stage1

On 11/04/2013 10:50 AM, Jakub Jelinek wrote: That's true, but it is easy to ignore those, while without -Wformat you won't notice until you bootstrap that you actually passed incorrect parameters to some *printf etc. family function. Sure, but that is much less common than the false positives,

Re: [Patch, avr] Emit diagnostics if -f{pic,PIC,pie,PIE} or -shared is passed

As Senthil Kumar Selvaraj wrote: > If ok, could someone commit please? I don't have commit access. I don't have commit access either, but the changes look reasonable to me. -- Joerg Wunsch * Development engineer, Dresden, Germany Atmel Automotive GmbH, Theresienstrasse 2, D-74027 Heilbronn Gesc

Re: [PATCH, rs6000] (2/3) Fix widening multiply high/low operations for little endian

Per Richard S's suggestion, I'm reworking parts 1 and 3 of the patch set, but this one will remain unchanged and is ready for review. Thanks, Bill On Sun, 2013-11-03 at 23:34 -0600, Bill Schmidt wrote: > Hi, > > This patch fixes the widening multiply high/low operations to work > correctly in th

Re: Patch RFA: With -fnon-call-exceptions sync builtins may throw

Ian Lance Taylor wrote: >On Mon, Nov 4, 2013 at 3:52 AM, Richard Biener > wrote: >> On Mon, Nov 4, 2013 at 7:01 AM, Ian Lance Taylor >wrote: >>> The middle-end currently marks all the sync builtins as nothrow. >That >>> is incorrect for most of them when using -fnon-call-exceptions. The >>> -fn

Re: lto-plugin: mismatch between ld's architecture and GCC's configure --host

>> Ping. To sum it up, with these patches applied, there are no changes for >> a "regular" build (not using the new configure options). On the other >> hand, configuring GCC as described, it is possible use the 32-bit x86 >> linker for/with a x86_64 build, and get the very same GCC test results a

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

On 11/01/13 15:41, Jakub Jelinek wrote: On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote: static inline void ! gimple_call_set_lhs (gimple gs, tree lhs) { - GIMPLE_CHECK (gs, GIMPLE_CALL); gimple_set_op (gs, 0, lhs); to static inline void ! gimple_call_set_lhs (gi

Re: [PATCH] Try to avoid vector mode punning in SET_DEST on i?86

On Thu, Oct 31, 2013 at 04:49:47PM +, Jakub Jelinek wrote: > 2013-10-31 Jakub Jelinek > > * optabs.c (expand_vec_perm): Avoid vector mode punning > SUBREGs in SET_DEST. > * expmed.c (store_bit_field_1): Likewise. > * config/i386/sse.md (movdi_to_sse, vec_pac

Re: [Patch, ObjC, ObjC++, Darwin] Remove "-fobjc-sjlj-exceptions"

On Sun, 3 Nov 2013, Iain Sandoe wrote: > gcc/c-family: > > * c-opts.c (c_common_post_options): Remove handling of > flag_objc_sjlj_exceptions. > * c.opt (fobjc-sjlj-exceptions): Issue a warning if this > option is given. The c-family changes are OK. -- Joseph S. Myers j

Re: [driver] Force options Wa, Wl, Wp, to take a mandatory argument

On Mon, 4 Nov 2013, Mingjie Xing wrote: > Hello, > > This patch forces options Wa, Wl, Wp, to take a mandatory argument, > which can fix the bug > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651. > > Tested on i686-pc-linux-gnu. > > 2013-11-04 Mingjie Xing > > * common.opt (Wa, Wl

Re: [PATCH] Introducing SAD (Sum of Absolute Differences) operation to GCC vectorizer.

On Mon, Nov 4, 2013 at 2:06 AM, James Greenhalgh wrote: > On Fri, Nov 01, 2013 at 04:48:53PM +, Cong Hou wrote: >> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi >> index 2a5a2e1..8f5d39a 100644 >> --- a/gcc/doc/md.texi >> +++ b/gcc/doc/md.texi >> @@ -4705,6 +4705,16 @@ wider mode, is computed

Re: changing a collision resolution strategy of the symbol table of identifiers

2013/10/20 Ondřej Bílka : > On Sun, Oct 20, 2013 at 06:55:40PM +0600, Roman Gareev wrote: >> Dear gcc contributors, >> >> Recently I came across the list of "ideas for speeding up GCC" >> (http://gcc.gnu.org/wiki/Speedup_areas). Among others, there was >> suggested to replace identifier hash table

[PATCH] Optional alternative base_expr in finding basis for CAND_REFs

Hi, This patch extends the slsr pass to optionally use an alternative base expression in finding basis for CAND_REFs. Currently the pass uses hash-based algorithm to match the base_expr in a candidate. Given a test case like the following, slsr will not be able to recognize the two CAND_REF

  1   2   >