Re: libsanitizer merge from upstream r191666

On Mon, Nov 04, 2013 at 05:48:31PM -0800, Konstantin Serebryany wrote: > Hi Peter. > Does this also mean that asan in llvm trunk is broken for Power? > We'll need to fix it there too (or, in fact, first). I bet on all targets, not just PPC. By including kernel headers directly, you are entering v

Re: Fix __GCC_IEC_559 determination for 32-bit x86

On Tue, Nov 05, 2013 at 01:14:46AM +, Joseph S. Myers wrote: > HJ's regression tester shows the new test gcc.dg/iec-559-macros-9.c > failing for 32-bit x86. It turns out the excess precision handling > for determining the value of __GCC_IEC_559 has two problems: > flag_excess_precision hasn't

Re: [C, C++, OpenMP] Add support for -fopenmp-simd

On Mon, Nov 04, 2013 at 11:56:38PM +0100, Tobias Burnus wrote: > gcc/ > * doc/invoke.texi (-fopenmp-simd): Document new option. > * gimplify.c (gimplify_body): Accept -fopenmp-simd. > * omp-low.c (execute_expand_omp, execute_lower_omp): Ditto. > * tree.c (attribute_value_equ

Re: libsanitizer merge from upstream r191666

Bill, This build does not seem to be testing any of the asan code: you need "check-asan" --kcc On Mon, Nov 4, 2013 at 7:30 PM, Bill Schmidt wrote: > Hi Peter, > > The buildbot shows the latest LLVM ppc64 build is working ok: > > http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/8086 >

Re: libsanitizer merge from upstream r191666

Is this the same failure or different? On Mon, Nov 4, 2013 at 9:49 PM, H.J. Lu wrote: > It also breaks x32 build. > > > On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany > wrote: >> Hi Peter. >> Does this also mean that asan in llvm trunk is broken for Power? >> We'll need to fix it there to

Re: libsanitizer merge from upstream r191666

It also breaks x32 build. On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany wrote: > Hi Peter. > Does this also mean that asan in llvm trunk is broken for Power? > We'll need to fix it there too (or, in fact, first). > > --kcc > > On Mon, Nov 4, 2013 at 4:33 PM, Peter Bergner wrote: >> On M

[PATCH] Fix for PR bootstrap/58951

Hello Everyone, Attached, please find a patch to fix PR 58951. The usage of -ldl is not necessary. The patch is tested in x86_64 and x86. It is committed as obvious. Thanks, Balaji V. Iyer. Index: Makefile.in === --- Makefil

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

On Mon, Nov 4, 2013 at 10:21 PM, Bill Schmidt wrote: > Hi, > > This fixes the two companion patterns vec_pack_[su]fix_trunc_v2df in the > same manner as the recent fix for vec_pack_trunc_v2df. The same fix > obviously applies here as well. Bootstrapped and tested on > powerpc64{,le}-unknown-linu

Re: libsanitizer merge from upstream r191666

Hi Peter, The buildbot shows the latest LLVM ppc64 build is working ok: http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/8086 This build completed about two hours ago. Hope this helps, Bill On Mon, 2013-11-04 at 20:02 -0600, Peter Bergner wrote: > On Mon, 2013-11-04 at 17:48 -0800, K

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

Hi, This fixes the two companion patterns vec_pack_[su]fix_trunc_v2df in the same manner as the recent fix for vec_pack_trunc_v2df. The same fix obviously applies here as well. Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no regressions. Is this ok for trunk? Thanks, Bill

[C11-atomic] Miscellaneous fixes 7/n

I've applied this patch to C11-atomic branch to add support for handling x87 floating-point exceptions for atomic compound assignment. With this applied, c11-atomic-exec-5.c now passes on x86_64-unknown-linux-gnu. I consider the branch now feature-complete regarding _Atomic support (as opposed to

Re: libsanitizer merge from upstream r191666

On Mon, 2013-11-04 at 17:48 -0800, Konstantin Serebryany wrote: > Hi Peter. > Does this also mean that asan in llvm trunk is broken for Power? > We'll need to fix it there too (or, in fact, first). I'm not sure. Bill, can you fire off a quick LLVM trunk build on powerpc64-linux and see you see th

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

On 11/04/13 06:19, Richard Biener wrote: 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 tes

Re: libsanitizer merge from upstream r191666

Hi Peter. Does this also mean that asan in llvm trunk is broken for Power? We'll need to fix it there too (or, in fact, first). --kcc On Mon, Nov 4, 2013 at 4:33 PM, Peter Bergner wrote: > On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote: >> This patch has not been tested on Mac an

Fix __GCC_IEC_559 determination for 32-bit x86

HJ's regression tester shows the new test gcc.dg/iec-559-macros-9.c failing for 32-bit x86. It turns out the excess precision handling for determining the value of __GCC_IEC_559 has two problems: flag_excess_precision hasn't been initialized at the point it's tested, so flag_excess_precision_cmdli

Re: [PATCH, rs6000] (1/3) Reverse meanings of multiply even/odd for little endian

Hi, Here's a new version of this patch, revised according to Richard Sandiford's suggestions. Unfortunately the diffing is a little bit ugly for this version. Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no regressions. Is this ok for trunk? Thanks, Bill 2013-11-04 Bill

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

Hi, Here's a revised version of this patch according to Richard's suggestions. It differs from the previous version only in the method used to ensure vmulouh is generated; we now call the new gen_altivec_vmulouh to accomplish this. Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with

Re: libsanitizer merge from upstream r191666

On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote: > 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

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

On Nov 4, 2013, at 5:43 AM, Senthil Kumar Selvaraj wrote: > 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. Ok. > If ok, could someone commit please? Committed re

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

I wonder if it makes sense to get rid of the conditional compile such as #ifdef L_gcov_x .. #endif This has the advantage of producing slightly smaller instrumented binary, but this benefit can also be achieved via -ffunction-sections and let linker to garbage collect unused functions. (pro

Patch RFC: x86: Emit .cfi directives for BX register swap

This patch to the x86 backend adds .cfi directives for the BX register swap in the atomic compare-and-exchange-doubleword insn. If we don't do this, then when compiling with -fnon-call-exceptions, if the cmpxchg8 memory address is invalid, and the SIGSEGV signal handler throws an exception, the BX

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

Hi, On Mon, 4 Nov 2013 16:40:38, Dodji Seketeli wrote: > +static ssize_t > +get_line (char **lineptr, size_t *n, FILE *fp) > +{ > + ssize_t cur_len = 0, len; > + char buf[16384]; > + > + if (lineptr == NULL || n == NULL) > + return -1; > + > + if (*lineptr == NULL || *n == 0) > + { > + *n = 120; >

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

Hi Iain, I have prefixed all my replies below with "BVI:" Thanks, Balaji V. Iyer. From: Iain Sandoe [mailto:i...@codesourcery.com] Sent: Sunday, November 3, 2013 11:01 AM To: Iyer, Balaji V Cc: Joseph S. Myers; Tobias Burnus; gcc patches Subject: Re: Testsuite / Cilk Plus: Include library

Re: [C, C++, OpenMP] Add support for -fopenmp-simd

Am 31.10.2013 17:40, schrieb Jakub Jelinek: On Sun, Oct 27, 2013 at 10:45:57PM +0100, Tobias Burnus wrote: The code is written such that when "-fopenmp" is used, -f(no-)openmp-simd has no effect. The following "simd" pragmas are listed in OpenMP 4.0 - and will all get translated into "#pragma om

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

On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu wrote: > Honza, Thanks for the comments! > Attached is the patch. > Passed spec2006 fdo build and profiledbootstrap in gcc. > I'm doing some other tests. > > -Rong > > On Mon, Nov 4, 2013 at 1:55 AM, Jan Hubicka wrote: >>> Thanks! Can you attach the patch f

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

BTW, this part of patch only does the re-factoring work. I haven't finished the porting of profile-tool part of patch to the trunk. They should be in a separate patch anyway. -Rong On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu wrote: > Honza, Thanks for the comments! > Attached is the patch. > Passed

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

On 11/04/2013 05:25 PM, Jakub Jelinek wrote: On Mon, Nov 04, 2013 at 04:43:33PM -0500, David Malcolm wrote: I tried converting gimple_call_set_lhs to accept a gimple_call, rather than a gimple, and excitingly, it was easiest to also convert cgraph_edge's call_stmt to also be a gimple_call, rathe

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

The warning should say "macro" not "Macro" and I think "reproducing" not "reproduce". The c-family and libcpp changes are OK with that fixed. -- Joseph S. Myers jos...@codesourcery.com

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

On 11/04/2013 05:03 PM, David Malcolm wrote: I believe it would be easiest to do them one subclass at-a-time e.g. convert all gimple_call_* functions to accepting a gimple_call, then another subclass etc - assuming that this approach is blessed by the core reviewers. I think the strategy for re

[wide-int] merged trunk

I merged trunk into wide-int.

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

On 11/04/2013 05:03 PM, David Malcolm wrote: On Mon, 2013-11-04 at 16:43 -0500, David Malcolm wrote: On Mon, 2013-11-04 at 08:19 -0500, Andrew MacLeod wrote: 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

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

On Mon, Nov 04, 2013 at 04:43:33PM -0500, David Malcolm wrote: > I tried converting gimple_call_set_lhs to accept a gimple_call, rather > than a gimple, and excitingly, it was easiest to also convert > cgraph_edge's call_stmt to also be a gimple_call, rather than just a > gimple. > > Am attaching

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

On Mon, Nov 4, 2013 at 1:24 PM, Marc Glisse wrote: > On Mon, 4 Nov 2013, Ian Lance Taylor wrote: > >> 2013-11-04 Ian Lance Taylor >> >> * builtins.def (ATTR_NOTHROWCALL_LEAF_LIST): Define. >> * sync-builtins.def: Use ATTR_NOTHROWCALL_LEAF_LIST for all sync >> builtins th

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

On Mon, 2013-11-04 at 16:43 -0500, David Malcolm wrote: > On Mon, 2013-11-04 at 08:19 -0500, Andrew MacLeod wrote: > > 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: >

Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion

Thanks! The three patches are commited as r204367, r204369 and r204371. Regards, Wei Mi. On Sun, Nov 3, 2013 at 5:18 PM, Jan Hubicka wrote: >> Ping. Is it ok for x86 maintainer? > > I tought I already approved the x86 bits. >> >> Thanks, >> Wei Mi. >> >> On Wed, Oct 16, 2013 at 4:25 PM, Wei Mi

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

> I am seeing a bootstrap failure that seems related: ... Me too, Dominique

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

On Mon, 4 Nov 2013, Ian Lance Taylor wrote: 2013-11-04 Ian Lance Taylor * builtins.def (ATTR_NOTHROWCALL_LEAF_LIST): Define. * sync-builtins.def: Use ATTR_NOTHROWCALL_LEAF_LIST for all sync builtins that take pointers. * lto-opts.c (lto_write_options): Write -

Re: RFA: patch to fix PR58967

On 11/04/2013 02:26 PM, David Edelsohn wrote: > On Mon, Nov 4, 2013 at 2:23 PM, Vladimir Makarov wrote: >> The following patch fixes >> >>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967 >> >> The removed code is too old. To be honest, I even don't remember why I >> added this. LRA has been

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

Tobias Burnus wrote: Gerald Pfeifer wrote: To make it easier to reproduce builds of software and entire GNU/Linux distributions, RMS had the idea of adding a warning to GCC that warns about the use of __DATE__ and __TIME__. I assume that he also likes to have a warning for __TIMESTAMP__. I w

Re: [PATCH] LRA: Fix incorrect register spill/reload

On 11/01/13 19:42, Vladimir Makarov wrote: I did not expected from the patch any problems too. It is so obvious. This simple change should not affect x86 (or any other target currently using LRA). The code in question is used only for x86-64 and only for modern intel processing tuning. It is

Re: libsanitizer merge from upstream r191666

On Mon, Nov 4, 2013 at 8:46 AM, Jack Howarth wrote: > 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*

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

On 11/04/2013 08:00 PM, Zhenqiang Chen wrote: > Thanks. I add a new hook. The default function will return -1 if the target > does not care about the order. > > +DEFHOOK > +(select_ccmp_cmp_order, > + "For some target (like ARM), the order of two compares is sensitive for\n\ > +conditional compare

Remove SHIFT_COUNT_TRUNCATED from double-int.c

...as suggested by Richard. This means that out-of-range shift values produce the same results on all targets at the tree level. The rtl level isn't affected since it explicitly truncates the count. Tested on mips64-linux-gnu. OK to install? Thanks, Richard gcc/ * double-int.c (lshif

Re: [Patch, fortran] PR58771 - [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164

Thanks - committed to trunk as r204358. 4.7 and 4.8 are to follow in a few days. Paul On 4 November 2013 21:01, Tobias Burnus wrote: > Paul Richard Thomas wrote: >> >> When I first posted it in Bugzilla, I thought that this patch is too >> kludgey by far. However, it has grown on me and I now

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

On Mon, Nov 04, 2013 at 06:23:19PM +, James Greenhalgh wrote: > > --- gcc/optabs.c.jj 2013-10-29 09:25:45.0 +0100 > > +++ gcc/optabs.c2013-10-31 13:20:40.384808642 +0100 > > @@ -6674,7 +6674,7 @@ expand_vec_perm (enum machine_mode mode, > > } > >tmp = gen_rtx

Re: Aliasing: look through pointer's def stmt

Marc Glisse wrote: >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(revisi

Re: PR 58958: wrong aliasing info

Marc Glisse wrote: >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 > >>

[committed] Fix a regression caused by my __builtin_unreachable assertion changes (PR tree-optimization/58978)

Hi! single_imm_use (to my surprise) modifies what it's last argument points to even when returning false, this function wasn't expecting that. Furthermore, if a the var is used in a store which does't have lhs as SSA_NAME, this would ICE. Fixed thusly, bootstrapped/regtested on x86_64-linux and

[PATCH] Fix ipcp_transform_function (PR tree-optimization/58984)

Hi! This patch fixes PR58984, where determine_known_aggregate_parts notices that o.f0 = 1 store (because of ESRA) and p.f0 = 1 store (because the field isn't a bitfield) are known constants at offset 0 of the first parameter, but doesn't record the access of that size (8 bits) and happily replaces

Re: [Patch, fortran] PR58771 - [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164

Paul Richard Thomas wrote: When I first posted it in Bugzilla, I thought that this patch is too kludgey by far. However, it has grown on me and I now think that it is the right thing to do. The patch is self-explanatory. Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.7/4.8 with

[Patch, fortran] PR58771 - [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164

Dear All, When I first posted it in Bugzilla, I thought that this patch is too kludgey by far. However, it has grown on me and I now think that it is the right thing to do. The patch is self-explanatory. Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.7/4.8 with an appropriate de

Re: RFA: patch to fix PR58967

On 11/4/2013 2:23 PM, Vladimir Makarov wrote: The following patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967 The removed code is too old. To be honest, I even don't remember why I added this. LRA has been changed a lot since this change and now it works fine without it. Whe

[PATCH] testsuite/lib/gcc-defs.exp (dg-additional-files-options)

Change dg-additional-files to match the behaviour of dg-additional-sources. This fix has been in the CS trunk for 2 months without problem. It's fairly obvious so I'll commit in the next day or two unless there are objections. -- Jim Lemke Mentor Graphics / CodeSourcery Orillia Ontario 2013-11

Re: [Patch, fortran] PR57445 - [4.8/4.9 Regression] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array

Dear Steve, Thanks for the review. Patch committed to trank as revision 204356. I'll wait a few days before going back to 4.8 partly because I do not have a 4.8 tree loaded :-) Cheers Paul On 2 November 2013 18:11, Steve Kargl wrote: > On Fri, Nov 01, 2013 at 04:56:36PM +0100, Paul Richar

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

On Mon, Nov 4, 2013 at 12:34 AM, Bill Schmidt wrote: > Hi, > > This patch fixes the widening multiply high/low operations to work > correctly in the presence of the first patch of this series, which > reverses the meanings of multiply even/odd instructions. Here we > reorder the input operands to

Re: RFA: patch to fix PR58967

On Mon, Nov 4, 2013 at 2:23 PM, Vladimir Makarov wrote: > The following patch fixes > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967 > > The removed code is too old. To be honest, I even don't remember why I > added this. LRA has been changed a lot since this change and now it > works fi

RFA: patch to fix PR58967

The following patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967 The removed code is too old. To be honest, I even don't remember why I added this. LRA has been changed a lot since this change and now it works fine without it. There is no test for this case as it is too big. The

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

2013/10/31 Florian Weimer : > On 10/20/2013 02:55 PM, Roman Gareev wrote: >> >> During testing of the linux kernel (3.8.8) compilation time, the >> acquired results were the following: increasing by 0.17% for the >> version 4.8.0, increasing by 1.12% for the version 4.8.1, decreasing >> by 0.598% f

[PATCH] PR58985: testcase error.

Hi, This is to fix testcase error reported in PR58985. The intention of the testcase was to ensure there was no REG_EQUIV notes generated for a reg which was used in a paradoxical subreg. When target was x86, there was subreg generated so I omitted to add the subreg in the regexp pattern. However

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

On 11/04/2013 06:21 PM, Jason Merrill wrote: Surely it should be valid to allocate a Java boolean type. Andrew, how should that work? Thanks. The problem we are facing (assuming we want to resolve this old isue) is that something seems seriously broken for the builtin Java types as declared in

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

Richard Biener wrote: >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

[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

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

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: [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, 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: [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 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: 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 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: [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, 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 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: [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: 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: 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

[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: 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

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: [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

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 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

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: [C++ PATCH] Fix PR58979

OK. Jason

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: [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: 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: [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 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: [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: [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 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: [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

[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: [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. --

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: 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

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: 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

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

  1   2   >