Re: [middle-end,patch] Making __builtin_signbit type-generic

Joseph Myers writes: > On Wed, 19 Aug 2015, Andreas Schwab wrote: > >> >> Why only in usafe mode? Isn't the sign bit of NaN always unreliable? >> > >> > NaN sign bits are meaningful for a limited set of operations. >> >> And what are those? > > Assignment to the same type, negation, absolute va

Re: [PATCH][2/n] Change dw2_asm_output_offset to allow assembling extra offset

On Wed, 19 Aug 2015, Mike Stump wrote: > On Aug 19, 2015, at 7:25 AM, Richard Biener wrote: > > > > This is needed so that we can output references to $early-debug-symbol + > > constant offset where $early-debug-symbol is the beginning of a > > .debug_info section containing early debug info f

Re: [PATCH] Only accept BUILT_IN_NORMAL stringops for interesting_stringop_to_profile_p

On Thu, Aug 20, 2015 at 5:17 AM, Yangfei (Felix) wrote: > Hi, > > As DECL_FUNCTION_CODE is overloaded for builtin functions in different > classes, so need to check builtin class before using fcode. > Patch posted below. Bootstrapped on x86_64-suse-linux, OK for trunk? > Thanks. Ugh

Re: Move some flag_unsafe_math_optimizations using simplify and match

On Thu, Aug 20, 2015 at 6:48 AM, Hurugalawadi, Naveen wrote: > Hi, > > Thanks again for your review and useful comments. > >>> I see. But I can't really help without a testcase that I can use to have a >>> look >>> (same for the above issue with the segfaults). > > The following testcase does no

[AArch64] Break -mcpu tie between the compiler and assembler

On Wed, Aug 19, 2015 at 04:48:11PM +0100, Andrew Pinski wrote: > On Wed, Aug 19, 2015 at 11:39 PM, James Greenhalgh > wrote: > > > > Hi, > > > > This patch has been sitting in my tree for a while - it comes in handy > > when trying out bootstrap or test with -mcpu values like -mcpu=cortex-a72 > >

Re: [PATCH] S390: Fix vec_load_bndry.

On Tue, Aug 18, 2015 at 02:49:30PM +0200, Ulrich Weigand wrote: > Dominik Vogt wrote: > > > The attached patch fixes the vec_load_bndry builtin on S390. The second > > argument must be one of 64, 128, 256, ..., 4096, but the table expected that > > value to fit into 3 bits. > > Makes sense. How

Re: Move some flag_unsafe_math_optimizations using simplify and match

On Thu, Aug 20, 2015 at 7:38 AM, Marc Glisse wrote: > On Thu, 20 Aug 2015, Hurugalawadi, Naveen wrote: > >> The following testcase does not generate "x" as needed. >> >> double t (double x) >> { >> x = sqrt (x) * sqrt (x); >> return x; >> } >> > > > With -

Re: [PATCH GCC]Improve loop bound info by simplifying conversions in iv base

On Fri, Aug 14, 2015 at 4:28 PM, Richard Biener wrote: > On Tue, Jul 28, 2015 at 11:38 AM, Bin Cheng wrote: >> Hi, >> For now, SCEV may compute iv base in the form of "(signed T)((unsigned >> T)base + step))". This complicates other optimizations/analysis depending >> on SCEV because it's hard t

RE: [PATCH][AArch64][1/3] Expand signed mod by power of 2 using CSNEG

Ping. https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00710.html Thanks, Kyrill On 03/08/15 14:01, James Greenhalgh wrote: > On Fri, Jul 24, 2015 at 11:55:33AM +0100, Kyrill Tkachov wrote: >> Hi all, >> >> This patch implements an aarch64-specific expansion of the signed modulo by a power of 2. >>

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On 08/20/2015 06:36 AM, Tom Tromey wrote: > Andrew> No, it isn't. It's still a necessity for initial bootstrapping of > Andrew> OpenJDK/IcedTea. > > Andrew Haley said the opposite here: > > https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html if you need bootstrapping OpenJDK 6 or OpenJDK 7,

[Patch] Add to the libgfortran/newlib bodge to "detect" ftruncate support in ARM/AArch64/SH

Hi, Steve's patch in 2013 [1] to fix the MIPS newlib/libgfortran build causes subtle issues for an ARM/AArch64 newlib/libgfortran build. The problem is that ARM/AArch64 (and SH) define a stub function for ftruncate, which we would previously have auto-detected, but which is not part of the hardwi

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On 20/08/15 09:24, Matthias Klose wrote: > On 08/20/2015 06:36 AM, Tom Tromey wrote: >> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of >> Andrew> OpenJDK/IcedTea. >> >> Andrew Haley said the opposite here: >> >> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html >

RE: [PATCH][ARM]Tighten the conditions for arm_movw, arm_movt

Hi Renlin, On 19/08/15 15:37, Renlin Li wrote: > Hi Kyrylo, > > On 19/08/15 13:46, Kyrylo Tkachov wrote: >> Hi Renlin, >> >> Please send patches to gcc-patches for review. >> Redirecting there now... > Thank you! I should really double check after Thunderbird auto complete > the address for me. >

Re: [PATCH] Fix middle-end/67133, part 1

Marek Polacek writes: > PR middle-end/67133 > * gimple-ssa-isolate-paths.c > (insert_trap_and_remove_trailing_statements): Rename to ... > (insert_trap): ... this. Don't remove trailing statements; split > block instead. > (find_explicit_erroneous_behaviour):

Re: [AArch64] Break -mcpu tie between the compiler and assembler

On 20 August 2015 at 09:15, James Greenhalgh wrote: > 2015-08-19 James Greenhalgh > > * common/config/aarch64/aarch64-common.c > (AARCH64_CPU_NAME_LENGTH): Delete. > (aarch64_option_extension): New. > (all_extensions): Likewise. > (processor_name_to_arch

Re: Move some flag_unsafe_math_optimizations using simplify and match

On Thu, 20 Aug 2015, Richard Biener wrote: On Thu, Aug 20, 2015 at 7:38 AM, Marc Glisse wrote: On Thu, 20 Aug 2015, Hurugalawadi, Naveen wrote: The following testcase does not generate "x" as needed. double t (double x) { x = sqrt (x) * sqrt (x); return x; }

Re: Move some flag_unsafe_math_optimizations using simplify and match

Hi, >> Works for me if you specify -fno-math-errno. I think that's a >> "regression" we can accept. Modified the pattern with "fno-math-errno" as a condition. >> Can you re-post with the typo fix and the missing :s? Please find attached the modified patch as per the review comments. Please sug

Re: [PATCH][1/n] dwarf2out refactoring for early (LTO) debug

On Wed, 19 Aug 2015, Richard Biener wrote: > On Tue, 18 Aug 2015, Aldy Hernandez wrote: > > > On 08/18/2015 07:20 AM, Richard Biener wrote: > > > > > > This starts a series of patches (still in development) to refactor > > > dwarf2out.c to better cope with early debug (and LTO debug). > > > > A

Re: [PATCH] Only accept BUILT_IN_NORMAL stringops for interesting_stringop_to_profile_p

Thanks for the comments. Attached please find the updated patch. OK? Index: gcc/value-prof.c === --- gcc/value-prof.c(revision 141081) +++ gcc/value-prof.c(working copy) @@ -209,7 +209,6 @@ gimple_add_histogram_value (stru

[PATCH] Add extra compile options for dg-final only once.

This patch fixes an annoying problem of the dg-final test using the scan-assembler family of tests (and maybe others). For a test file, the option "-ffat-lto-objects" is added to the command line once for each "scan-assembler" test, eventually resulting in an unreadable command line. Can this be

RE: [PATCH, MIPS, Ping] Inline memcpy for MipsR6

Checked in as revision 227026. Thanks, Simon -Original Message- From: Moore, Catherine [mailto:catherine_mo...@mentor.com] Sent: 01 August 2015 20:18 To: Simon Dardis; gcc-patches@gcc.gnu.org Cc: Moore, Catherine Subject: RE: [PATCH, MIPS, Ping] Inline memcpy for MipsR6 > -Origin

Re: [Patch] Add to the libgfortran/newlib bodge to "detect" ftruncate support in ARM/AArch64/SH

On 20 August 2015 at 09:31, James Greenhalgh wrote: > > Hi, > > Steve's patch in 2013 [1] to fix the MIPS newlib/libgfortran build > causes subtle issues for an ARM/AArch64 newlib/libgfortran build. The > problem is that ARM/AArch64 (and SH) define a stub function for > ftruncate, which we would p

[i386] Simplify vector_all_ones_operand

gen_rtx_CONST_VECTOR ensures that there is a single instance of: (const_vector:M [(const_int -1) ... (const_int -1)]) for each M, so pointer equality with CONSTM1_RTX is enough. This seemed like a better fix than using the helper functions that I'm about to post. Bootstrapped & regression-te

Re: [PATCH][1/n] dwarf2out refactoring for early (LTO) debug

On Wed, 19 Aug 2015, Richard Biener wrote: > On Tue, 18 Aug 2015, Aldy Hernandez wrote: > > > On 08/18/2015 07:20 AM, Richard Biener wrote: > > > > > > This starts a series of patches (still in development) to refactor > > > dwarf2out.c to better cope with early debug (and LTO debug). > > > > A

Fix intelmic-mkoffload.c if the temp path contains a '-'

Hi all, during my test of OpenMP 4.0 offloading features I have found a bug in intelmic-mkoffload.c when the temp path contains a '-'. objcopy will in this case replace it with a '_' which wasn't reflected in the original code and resulted in a link error of the symbols '__offload_image_intelmic_s

Re: [PATCH][1/n] dwarf2out refactoring for early (LTO) debug

On Thu, 20 Aug 2015, Richard Biener wrote: > On Wed, 19 Aug 2015, Richard Biener wrote: > > > On Tue, 18 Aug 2015, Aldy Hernandez wrote: > > > > > On 08/18/2015 07:20 AM, Richard Biener wrote: > > > > > > > > This starts a series of patches (still in development) to refactor > > > > dwarf2out.c

[SPARC] Simplify const_all_ones_operand

gen_rtx_CONST_VECTOR ensures that there is a single instance of: (const_vector:M [(const_int -1) ... (const_int -1)]) for each M, so pointer equality with CONSTM1_RTX is enough. Also, HOST_BITS_PER_WIDE_INT == 32 is doubly dead: HOST_WIDE_INT is always 64 bits now, and we always use const_int

Add utility functions for rtx broadcast/duplicate constants

Several pieces of code want to know whether all elements of a CONST_VECTOR are equal, and I'm about to add some more to simplify-rtx.c. This patch adds some utility functions for that. I don't think we're really helping ourselves by having the shift amount in "v16qi << 3" be: (const_vector:V

Re: [PATCH] Fix middle-end/67133, part 1

On Thu, Aug 20, 2015 at 11:02:17AM +0200, Andreas Schwab wrote: > Marek Polacek writes: > > > PR middle-end/67133 > > * gimple-ssa-isolate-paths.c > > (insert_trap_and_remove_trailing_statements): Rename to ... > > (insert_trap): ... this. Don't remove trailing statements; split

[patch] Restore installation of libstdc++.so.6.0.??-gdb.py

Matthias noticed that my backport of the Filesystem library removed the libstdc++.so.6.0.21-gdb.py file, which was now getting installed as libstdc++fs.a-gdb.py instead. Fixed by changing the glob we use to find the candidate library files that we use for the name of the installed gdb.py file. T

Re: [PATCH] Fix middle-end/67133, part 1

Marek Polacek writes: > Whilst I'm struggling with building cross libgo to reproduce this, is > there something like preprocessed source for go? I don't think so. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "An

Re: Move some flag_unsafe_math_optimizations using simplify and match

On Thu, Aug 20, 2015 at 11:18 AM, Hurugalawadi, Naveen wrote: > Hi, > >>> Works for me if you specify -fno-math-errno. I think that's a >>> "regression" we can accept. > > Modified the pattern with "fno-math-errno" as a condition. > >>> Can you re-post with the typo fix and the missing :s? > > Pl

[PATCH] Move late_global_decl call

This moves it where it really belongs, also avoiding extra work for the slim LTO compile phase. Bootstrapped and tested and gdb tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-08-20 Richard Biener * toplev.c (compile_file): Remove loop calling late_global_decl on

Re: [PATCH][2/n] Change dw2_asm_output_offset to allow assembling extra offset

On Aug 20, 2015, at 12:29 AM, Richard Biener wrote: > > where the references always use positive offset and are based on the > next previous lable (so Ldebug_info_from_t1.c is not refering to > an entity at Ldebug_info_from_t2.c or beyond). So that seems to > follow the restrictions you laid out

Re: [PATCH GCC]Improve loop bound info by simplifying conversions in iv base

On Thu, Aug 20, 2015 at 10:22 AM, Bin.Cheng wrote: > On Fri, Aug 14, 2015 at 4:28 PM, Richard Biener > wrote: >> On Tue, Jul 28, 2015 at 11:38 AM, Bin Cheng wrote: >>> Hi, >>> For now, SCEV may compute iv base in the form of "(signed T)((unsigned >>> T)base + step))". This complicates other opt

Re: [i386] Simplify vector_all_ones_operand

On Thu, Aug 20, 2015 at 12:02 PM, Richard Sandiford wrote: > gen_rtx_CONST_VECTOR ensures that there is a single instance of: > >(const_vector:M [(const_int -1) ... (const_int -1)]) > > for each M, so pointer equality with CONSTM1_RTX is enough. > > This seemed like a better fix than using the

Re: [PATCH] Only accept BUILT_IN_NORMAL stringops for interesting_stringop_to_profile_p

On Thu, Aug 20, 2015 at 11:31 AM, Yangfei (Felix) wrote: > Thanks for the comments. Attached please find the updated patch. OK? Ok. Thanks, Richard. > > Index: gcc/value-prof.c > === > --- gcc/value-prof.c(revision 141081) >

Re: [PATCH][2/n] Change dw2_asm_output_offset to allow assembling extra offset

On Thu, 20 Aug 2015, Mike Stump wrote: > On Aug 20, 2015, at 12:29 AM, Richard Biener wrote: > > > > where the references always use positive offset and are based on the > > next previous lable (so Ldebug_info_from_t1.c is not refering to > > an entity at Ldebug_info_from_t2.c or beyond). So th

Re: [PATCH] Add extra compile options for dg-final only once.

On Thu, Aug 20, 2015 at 11:37 AM, Dominik Vogt wrote: > This patch fixes an annoying problem of the dg-final test using the > scan-assembler family of tests (and maybe others). For a test > file, the option "-ffat-lto-objects" is added to the command line > once for each "scan-assembler" test, ev

[ARC] Cleanup A5 references

This patch cleans up the references to obsolete A5 processor. Can this be committed? Thanks, Claudiu 2015-08-20 Claudiu Zissulescu * common/config/arc/arc-common.c, config/arc/arc-opts.h, config/arc/arc.c, config/arc/arc.h, config/arc/arc.md, config/arc/arc.opt, conf

[PATCH] Fix PR67285

The following patch avoids breaking virtual SSA form in fold_stmt by making sure we only ever generate calls to const functions in simplify expression replacements. Bootstrap & regtest running on x86_64-unknown-linux-gnu. Richard. 2015-08-20 Richard Biener PR middle-end/67285

Re: [PATCH 1/15][ARM] Hide existing float16 intrinsics unless we have a scalar __fp16 type

Thanks, pushed with comment and ChangeLog fix as r227033. --Alan Kyrill Tkachov wrote: Hi Alan, On 28/07/15 12:23, Alan Lawrence wrote: This makes the existing float16 vector intrinsics available only when we have an __fp16 type (i.e. when one of the ARM_FP16_FORMAT_... macros is defined). T

Re: [PATCH testsuite, ARM] skip Wno-frame-address tests

Hi Christian, On 20/08/15 14:45, Christian Bruel wrote: Hello, 2 tests from rev 226480 introduced a new failure for ARM testing -Werror because a warning is always emitted regardless -Wframe-address is given or not. From expand_builtin_frame_address: /* Some ports cannot access arbitrary

Re: [PATCH testsuite, ARM] skip Wno-frame-address tests

Kyrill Tkachov writes: >> 015-08-20 Christian Bruel >> >> * gcc.dg/Wno-frame-address.c: Skip for ARM. >> * g++.dg/Wno-frame-address.C: Ditto. >> >> Index: gcc/testsuite/gcc.dg/Wno-frame-address.c >> === >> --- gcc/testsuit

Re: [PATCH] S390: Fix vec_load_bndry.

Dominik Vogt wrote: > gcc/ChangeLog > > * config/s390/s390-builtins.def: Fix value range of vec_load_bndry. > > gcc/testsuite/ChangeLog > > * gcc.target/s390/zvector/vec-load_bndry-1.c: New test. This is OK. Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolch

[avr, 5 + trunk, committed]: Fix "KiB" diagnostic for wrong address space.

https://gcc.gnu.org/r227034 https://gcc.gnu.org/r227035 If an address space is used that's beyond the flash of the current device (number of 64 KiB segments as specified by -mn-flash=) a diagnostic complains and prints the currently specified numbers of flash segments, i.e. 64 KiB chunks, and

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

- Original Message - > On 20/08/15 09:24, Matthias Klose wrote: > > On 08/20/2015 06:36 AM, Tom Tromey wrote: > >> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of > >> Andrew> OpenJDK/IcedTea. > >> > >> Andrew Haley said the opposite here: > >> > >> https://gcc.gnu

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

- Original Message - > Andrew> No, it isn't. It's still a necessity for initial bootstrapping of > Andrew> OpenJDK/IcedTea. > > Andrew Haley said the opposite here: > > https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html > Andrew Haley doesn't do releases of IcedTea 1.x and 2.x eve

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On 08/20/2015 03:57 PM, Andrew Hughes wrote: > - Original Message - >> On 20/08/15 09:24, Matthias Klose wrote: >>> On 08/20/2015 06:36 AM, Tom Tromey wrote: Andrew> No, it isn't. It's still a necessity for initial bootstrapping of Andrew> OpenJDK/IcedTea. Andrew Haley s

RE: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

-Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: Thursday, August 20, 2015 1:13 AM To: Ajit Kumar Agarwal; Richard Biener Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch,tree-optimization]: Add new path Splitt

RE: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

-Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: Thursday, August 20, 2015 3:16 AM To: Ajit Kumar Agarwal; Richard Biener Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch,tree-optimization]: Add new path Splitt

[PATCH, rs6000] A few more vector interfaces

Hi, This patch adds a few more vector interfaces listed in the ELFv2 ABI v1.1: missing flavors of vec_madd, vec_pmsum_be, and vec_shasigma_be. Existing tests have been updated to check for correct code gen. Tested on powerpc64le-unknown-linux-gnu with no regressions. Ok for trunk? Thanks, Bill

Re: [PATCH, rs6000] A few more vector interfaces

On Thu, Aug 20, 2015 at 11:40 AM, Bill Schmidt wrote: > Hi, > > This patch adds a few more vector interfaces listed in the ELFv2 ABI > v1.1: missing flavors of vec_madd, vec_pmsum_be, and vec_shasigma_be. > Existing tests have been updated to check for correct code gen. Tested > on powerpc64le-u

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On 08/20/2015 09:27 AM, Andrew Haley wrote: On 08/20/2015 03:57 PM, Andrew Hughes wrote: - Original Message - On 20/08/15 09:24, Matthias Klose wrote: On 08/20/2015 06:36 AM, Tom Tromey wrote: Andrew> No, it isn't. It's still a necessity for initial bootstrapping of Andrew> OpenJDK/Ic

Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

On 08/20/2015 09:38 AM, Ajit Kumar Agarwal wrote: Bootstrapping with i386 and Microblaze target works fine. No regression is seen in Deja GNU tests for Microblaze. There are lesser failures. Mibench/EEMBC benchmarks were run for Microblaze target and the gain of 9.3% is seen in rgbcmy_lite the

Re: [PATCH] Missing Skylake -march=/-mtune= option

On 2015.08.13 at 12:31 +0300, Yuri Rumyantsev wrote: > Hi All, > > Here is patch for adding march/mtune options for Skylake. http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf states that BMI1 and BMI2 are not supported

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

- Original Message - > On 08/20/2015 03:57 PM, Andrew Hughes wrote: > > - Original Message - > >> On 20/08/15 09:24, Matthias Klose wrote: > >>> On 08/20/2015 06:36 AM, Tom Tromey wrote: > Andrew> No, it isn't. It's still a necessity for initial bootstrapping > of > A

Re: [nvptx] testsuite cleanups

On 08/19/15 16:28, Nathan Sidwell wrote: This patch cleans up a bunch of c testsuite fails, (by skipping them) 1) make nvptx-*-* a freestanding environment. While there is a newlib port, it's not a full c library, and in particular doesn't have all the IO that's generally presumed. 2) added ef

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

- Original Message - > On 08/20/2015 09:27 AM, Andrew Haley wrote: > > On 08/20/2015 03:57 PM, Andrew Hughes wrote: > >> - Original Message - > >>> On 20/08/15 09:24, Matthias Klose wrote: > On 08/20/2015 06:36 AM, Tom Tromey wrote: > > Andrew> No, it isn't. It's still a ne

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On 08/20/2015 05:03 PM, Andrew Hughes wrote: > The issue is that we're still supporting a version of OpenJDK/IcedTea where > there is no previous version (6). Surely OpenJDK 6 can build itself. And in the unlikely event of an entirely new architecture which has No OpenJDK we'd have to grab an old

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

- Original Message - > On 08/20/2015 05:03 PM, Andrew Hughes wrote: > > The issue is that we're still supporting a version of OpenJDK/IcedTea where > > there is no previous version (6). > > Surely OpenJDK 6 can build itself. And in the unlikely event of an > entirely new architecture wh

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On August 20, 2015 5:52:55 PM GMT+02:00, Andrew Hughes wrote: >- Original Message - >> On 08/20/2015 03:57 PM, Andrew Hughes wrote: >> > - Original Message - >> >> On 20/08/15 09:24, Matthias Klose wrote: >> >>> On 08/20/2015 06:36 AM, Tom Tromey wrote: >> Andrew> No, it isn'

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On August 20, 2015 6:08:25 PM GMT+02:00, Andrew Haley wrote: >On 08/20/2015 05:03 PM, Andrew Hughes wrote: >> The issue is that we're still supporting a version of OpenJDK/IcedTea >where >> there is no previous version (6). > >Surely OpenJDK 6 can build itself. And in the unlikely event of an >en

Re: [PATCH testsuite, ARM] skip Wno-frame-address tests

On 08/20/2015 07:45 AM, Christian Bruel wrote: Hello, 2 tests from rev 226480 introduced a new failure for ARM testing -Werror because a warning is always emitted regardless -Wframe-address is given or not. From expand_builtin_frame_address: /* Some ports cannot access arbitrary stack frame

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On 08/20/2015 05:38 PM, Richard Biener wrote: > So gij, witten in C++ is enough? No: the runtime library needs gcj. Andrew.

Re: [PATCH] Fix middle-end/67133, part 1

On 08/20/2015 04:37 AM, Marek Polacek wrote: On Thu, Aug 20, 2015 at 11:02:17AM +0200, Andreas Schwab wrote: Marek Polacek writes: PR middle-end/67133 * gimple-ssa-isolate-paths.c (insert_trap_and_remove_trailing_statements): Rename to ... (insert_trap): ... th

[PATCH] Fix UBSan builtin types

Hi all, GCC builtins BUILT_IN_UBSAN_HANDLE_NONNULL_ARG and BUILT_IN_UBSAN_HANDLE_NONNULL_ARG_ABORT were using BT_FN_VOID_PTR_PTRMODE whereas they are really BT_FN_VOID_PTR: void __ubsan::__ubsan_handle_nonnull_return(NonNullReturnData *Data) The patch fixes it. I only tested ubsan.exp (I d

Re: [PATCH] Fix middle-end/67133, part 1

On Thu, Aug 20, 2015 at 10:41:28AM -0600, Jeff Law wrote: > On 08/20/2015 04:37 AM, Marek Polacek wrote: > >On Thu, Aug 20, 2015 at 11:02:17AM +0200, Andreas Schwab wrote: > >>Marek Polacek writes: > >> > >>> PR middle-end/67133 > >>> * gimple-ssa-isolate-paths.c > >>> (insert_trap_and_remov

Re: [PATCH] Fix middle-end/67133, part 1

On 08/20/2015 10:51 AM, Marek Polacek wrote: Based on the error, I suspect we've got a block ending with a GIMPLE_COND with no successors in the CFG. Except that I'm also seeing a different error: /home/brq/mpolacek/gcc/libgo/go/text/template/exec.go:303:1: error: wrong outgoing edge flags at

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

snip... > > Having classpath (with binary files!) In the GCC SVN (or future git) > repository is a significant burden, not to mention the size of the > distributed source tarball. > > If we can get rid of that that would be a great step in reducing the burden. > > Iff we can even without classpa

Re: [PATCH] Fix middle-end/67133, part 1

On Thu, Aug 20, 2015 at 06:51:45PM +0200, Marek Polacek wrote: > and single_succ_p (bb) is not satisfied, so it must have more outgoing edges. > Not sure how can that happen... Actually the problem seems to be that the BB ends with return but it has *no* outgoing edges. Marek

Re: [PR64164] drop copyrename, integrate into expand

On 08/19/2015 06:00 PM, Alexandre Oliva wrote: On Aug 19, 2015, Alexandre Oliva wrote: I'm having some difficulty getting access to an ia64 box ATM, and for ada bootstraps, a cross won't do, so... if you still have that build tree around, any chance you could recompile par.o with both stage1

Re: [PATCH] Fix middle-end/67133, part 1

On 08/20/2015 11:00 AM, Marek Polacek wrote: On Thu, Aug 20, 2015 at 06:51:45PM +0200, Marek Polacek wrote: and single_succ_p (bb) is not satisfied, so it must have more outgoing edges. Not sure how can that happen... Actually the problem seems to be that the BB ends with return but it has *no

libgo patch committed: Another fix for killing sleep processes in testsuite

I committed this patch to libgo as another fix for killing the sleep processes in the testsuite. This avoids padding issues in the ps output. Ran libgo testsuite. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gc

Re: [PATCH] Fix UBSan builtin types

On 08/20/2015 10:42 AM, Yury Gribov wrote: Hi all, GCC builtins BUILT_IN_UBSAN_HANDLE_NONNULL_ARG and BUILT_IN_UBSAN_HANDLE_NONNULL_ARG_ABORT were using BT_FN_VOID_PTR_PTRMODE whereas they are really BT_FN_VOID_PTR: void __ubsan::__ubsan_handle_nonnull_return(NonNullReturnData *Data) The pat

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On 08/20/2015 10:03 AM, Andrew Hughes wrote: - Original Message - On 08/20/2015 09:27 AM, Andrew Haley wrote: On 08/20/2015 03:57 PM, Andrew Hughes wrote: - Original Message - On 20/08/15 09:24, Matthias Klose wrote: On 08/20/2015 06:36 AM, Tom Tromey wrote: Andrew> No, it i

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

- Original Message - > snip... > > > > Having classpath (with binary files!) In the GCC SVN (or future git) > > repository is a significant burden, not to mention the size of the > > distributed source tarball. > > > > If we can get rid of that that would be a great step in reducing the >

[gomp4] routine calls

I've committed this to gomp4 branch. It augments the call RTL with an optional const int, indicating the partitioning requirements of the target function. This is set from the target function's 'oacc function' attribute. We don't do anything with this information yet -- it'll be needed to get

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

- Original Message - > On 08/20/2015 10:03 AM, Andrew Hughes wrote: > > - Original Message - > >> On 08/20/2015 09:27 AM, Andrew Haley wrote: > >>> On 08/20/2015 03:57 PM, Andrew Hughes wrote: > - Original Message - > > On 20/08/15 09:24, Matthias Klose wrote: > >>>

Go patch commmitted: Don't crash on empty print call

This patch by Chris Manghane fixes the Go frontend to not crash on an empty print call ("print()"). An empty print call is useless as it does nothing, but of course we shouldn't crash. This fixes https://golang.org/issue/11526 . Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Com

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On August 20, 2015 7:35:37 PM GMT+02:00, Andrew Hughes wrote: >- Original Message - >> snip... >> > >> > Having classpath (with binary files!) In the GCC SVN (or future >git) >> > repository is a significant burden, not to mention the size of the >> > distributed source tarball. >> > >>

Re: Add utility functions for rtx broadcast/duplicate constants

On 08/20/2015 04:34 AM, Richard Sandiford wrote: Several pieces of code want to know whether all elements of a CONST_VECTOR are equal, and I'm about to add some more to simplify-rtx.c. This patch adds some utility functions for that. I don't think we're really helping ourselves by having the sh

Re: [RFC][Scalar masks 1/x] Introduce GEN_MASK_EXPR.

On 08/17/2015 10:22 AM, Ilya Enkovich wrote: Hi, This patch starts a series introducing scalar masks support in the vectorizer. It was discussed on the recent Cauldron and changes overiew is available here: https://gcc.gnu.org/wiki/cauldron2015?action=AttachFile&do=view&target=Vectorization+f

Re: [Scalar masks 2/x] Use bool masks in if-conversion

On 08/17/2015 10:25 AM, Ilya Enkovich wrote: Hi, This patch intoriduces a new vectorizer hook use_scalar_mask_p which affects code generated by if-conversion pass (and affects patterns in later patches). Thanks, Ilya -- 2015-08-17 Ilya Enkovich * doc/tm.texi (TARGET_VECTORIZE_USE_S

Re: [PR25529] Convert (unsigned t * 2)/2 into unsigned (t & 0x7FFFFFFF)

On Fri, Aug 7, 2015 at 1:43 AM, Hurugalawadi, Naveen wrote: > Hi, > >>> extend it - it should also work for non-INTEGER_CST >>> divisors and it should work for any kind of division, not just exact_div. > > Please find attached the patch "pr25529.patch" that implements the pattern > for all divisor

Re: [PATCH] Disable -mbranch-likely for -Os when targetting generic architecture

Robert Suchanek writes: > The patch below disables generation of the branch likely instructions for -Os > but only for generic architecture. The branch likely may result in some > code size reduction but the cost of running the code on R6 core is > significant. How about instead splitting PTF_A

Re: [gomp4] New reduction infrastructure for OpenACC

Sigh, pdf's get filtered. Let's try some raw tex ... Here's the design document for the reduction implementation nathan \documentclass[a4paper]{article} \newcommand{\brk}{\linebreak[0]} \newcommand{\codespc}{\pagebreak[2]\\[1ex plus2pt minus1pt]} \newcommand{\codebrk}{\pagebreak[2]\\} \newcomm

[v3 patch] Fix friend declaration so it is visible to name lookup

Jason pointed out this isn't valid, and is going to fail to compile soon with a fix he's making. Tested powerpc64le-linux, committed to trunk. commit 89c676b9c2008823e7bbb7d5db615d908b1ea27d Author: Jonathan Wakely Date: Thu Aug 20 20:51:39 2015 +0100 * include/experimental/any (__any_

[patch] libstdc++/67294 Don't run timed mutex tests on Darwin

I added these tests recently but Darwin doesn't support timed mutexes. Tested powerpc64le-linux, committed to trunk. commit 6d230c89901d56ef429e3cc255b0d2b2d137f94f Author: Jonathan Wakely Date: Thu Aug 20 21:29:29 2015 +0100 libstdc++/67294 Don't run timed mutex tests on Darwin

C++ PATCH to overloaded friend hiding

Someone on the C++ committee pointed out that G++ unqualified lookup could see through one hidden friend, but not two, and not a template. Fixed thus. Tested x86_64-pc-linux-gnu, applying to trunk. commit bef61f4085710822782a462def4a7032c8a91668 Author: Jason Merrill Date: Thu Aug 20 14:40:5

Re: [Patch] Add to the libgfortran/newlib bodge to "detect" ftruncate support in ARM/AArch64/SH

On Thu, 2015-08-20 at 09:31 +0100, James Greenhalgh wrote: > I'd appreciate your help Steve to check that this patch works with > your build system. > > Thanks, > James Yes, this patch works fine with my builds for MIPS. Steve Ellcey sell...@imgtec.com

Should we remove remnants of UWIN support in gcc/config.* files?

UWIN support was apparently removed from GCC in 2008. Yet some traces can still be found in gcc/config.* files. Attached patch would remove them. OK to commit? FX PS: gcc/config.host and gcc/config.build include some other such targets… without checking them all, I think the following could be

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

On Thu, 20 Aug 2015, Richard Biener wrote: > OK, so how about deprecating Java for GCC 6 by removing it from the > default languages and removing it for GCC 7 or before we switch to git > (whatever happens earlier?) I don't think "before we switch to git" should be a relevant consideration for

Re: Should we remove remnants of UWIN support in gcc/config.* files?

On Thu, 20 Aug 2015, FX wrote: > PS: gcc/config.host and gcc/config.build include some other such > targets… without checking them all, I think the following could be > removed: > > powerpc-*-beos > i370-*-opened* | i370-*-mvs* > i386-*-vsta > i[34567]86-*-udk* > i[34567]86-*-sysv4* > i[34567]8

Re: Should we remove remnants of UWIN support in gcc/config.* files?

> Well, they aren't *targets*, but *host* and *build* systems. Yes, but do we maintain a list of support host or build systems, that would be different from our list of supported targets? (That’s a question out of curiosity. I do agree with the rest of your message: in practice, they are not sup

[PATCH], PR target/67211, Fix PowerPC 'insn does not satisfy its constraints' error on GCC 5

PR 67211 is an error that shows up on the GCC 5.x branch when the test case is compiled with -mcpu=power7 -mtune=power8 -O3. In looking at the code, I noticed that the code optimized adjancent 64-bit integer/pointers in a structure from DImode to V2DImode. The compiler optimized these to the vector

Re: Should we remove remnants of UWIN support in gcc/config.* files?

On Thu, 20 Aug 2015, FX wrote: > > Well, they aren't *targets*, but *host* and *build* systems. > > Yes, but do we maintain a list of support host or build systems, that > would be different from our list of supported targets? I don't think there's such a list. For any such system that's not a

RE: [PATCH] Disable -mbranch-likely for -Os when targetting generic architecture

Richard Sandiford writes: > Robert Suchanek writes: > > The patch below disables generation of the branch likely instructions for > > -Os > > but only for generic architecture. The branch likely may result in some > > code size reduction but the cost of running the code on R6 core is > > signi

Re: Should we remove remnants of UWIN support in gcc/config.* files?

On August 20, 2015 5:22:47 PM EDT, Joseph Myers wrote: >On Thu, 20 Aug 2015, FX wrote: > >> > Well, they aren't *targets*, but *host* and *build* systems. >> >> Yes, but do we maintain a list of support host or build systems, that > >> would be different from our list of supported targets? > >I

Re: [v3 patch] Fix friend declaration so it is visible to name lookup

Hi, On 08/20/2015 10:21 PM, Jonathan Wakely wrote: Jason pointed out this isn't valid, and is going to fail to compile soon with a fix he's making. I seem to remember that at some point we had the exact same issue with some member operator<< and operator>> of . Paolo.

  1   2   >