Re: [patch,avr][Ping #3] PR81075: Move jump-tables out of .text

I'm sorry for so long delay. Please apply the patch. 2017-07-05 14:19 GMT+04:00 Georg-Johann Lay : > Ping #3 > > http://gcc.gnu.org/ml/gcc-patches/2017-06/msg01029.html > > As avr maintainers are off-line, would a global maintainer have > a look at this? > > Thanks, > > Johann > >

Re: [patch,avr] Fix PR20296 / PR81268: Better ISR prologues / epilogues

2017-07-07 18:31 GMT+04:00 Georg-Johann Lay : > Hi, > > this patch addresses a very old issue, the non-optimal > generation of ISR prologues and epilogues. > > As GAS now provides the __gcc_isr pseudo instruction to > overcome some problems, see > >

Re: [PATCHv2][PR 57371] Remove useless floating point casts in comparisons

On Sat, Jul 8, 2017 at 5:30 AM, Yuri Gribov wrote: > On Fri, Jul 7, 2017 at 11:51 PM, Joseph Myers wrote: >> On Fri, 7 Jul 2017, Yuri Gribov wrote: >> >>> > I suspect infinities would already work with the patch as-is (the logic >>> > dealing with

Re: [PATCHv2][PR 57371] Remove useless floating point casts in comparisons

On Fri, Jul 7, 2017 at 11:51 PM, Joseph Myers wrote: > On Fri, 7 Jul 2017, Yuri Gribov wrote: > >> > I suspect infinities would already work with the patch as-is (the logic >> > dealing with constants outside the range of the integer type). I'm less >> > clear that NaNs

[PATCH] i386: Avoid stack realignment if possible

On Fri, Jul 07, 2017 at 09:58:42AM -0700, H.J. Lu wrote: > On Fri, Dec 20, 2013 at 8:06 AM, Jakub Jelinek wrote: > > Hi! > > > > Honza recently changed the i?86 backend, so that it often doesn't > > do -maccumulate-outgoing-args by default on x86_64. > > Unfortunately, on some

Re: [PATCH, rs6000] Modify libgcc's float128 IFUNC resolver functions to use __builtin_cpu_supports()

On 7/7/17 4:13 PM, Peter Bergner wrote: > On 7/7/17 10:18 AM, Segher Boessenkool wrote: >> On Thu, Jul 06, 2017 at 04:21:48PM -0500, Peter Bergner wrote: >>> * config/rs6000/float128-ifunc.c: Don't include auxv.h. >>> (have_ieee_hw_p): Delete function. >>> (SW_OR_HW) Use

[patch] Fix Unwind support on DragonFly BSD after sigtramp move

Right after DragonFly 4.8 was released (27 Mar 2017), the signal trampoline was moved (twice) in response to a Ryzen bug. This broke GCC's unwind support for DragonFly. To avoid hardcoding the sigtramp location to avoid issues like this in the future, a new sysctl was added to DragonFly to

[Committed/AARCH64] Fix ICE with -mcpu=thunderx2t99

Hi, After https://gcc.gnu.org/ml/gcc-cvs/2017-06/msg01066.html, there was many crashes with -mcpu=thunderx2t99. This patch fixes the crashes. Committed after bootstrap and test. Thanks, Andrew Pinski ChangeLog: * config/aarch64/aarch64.c (aarch_macro_fusion_pair_p): Check prev_set and

Re: [PATCHv2][PR 57371] Remove useless floating point casts in comparisons

On Fri, 7 Jul 2017, Yuri Gribov wrote: > > I suspect infinities would already work with the patch as-is (the logic > > dealing with constants outside the range of the integer type). I'm less > > clear that NaNs would work properly. (If the comparison is == or != you > > can optimize it for

Re: [PATCHv2][PR 57371] Remove useless floating point casts in comparisons

On Fri, Jul 7, 2017 at 6:07 PM, Joseph Myers wrote: > On Fri, 7 Jul 2017, Yuri Gribov wrote: > >> Hi all, >> >> This is an updated version of patch in >> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00034.html . It should >> be much more complete, both in functionality

Re: [PATCH, rs6000] Modify libgcc's float128 IFUNC resolver functions to use __builtin_cpu_supports()

On 7/7/17 10:18 AM, Segher Boessenkool wrote: > On Thu, Jul 06, 2017 at 04:21:48PM -0500, Peter Bergner wrote: >> * config/rs6000/float128-ifunc.c: Don't include auxv.h. >> (have_ieee_hw_p): Delete function. >> (SW_OR_HW) Use __builtin_cpu_supports(). > > Okay for trunk. Thanks!

[PATCH, rs6000] Fix builtins-1-p9-runnable.c

GCC Maintainers: The following patch causes the builtins-1-p9-runnable.c to be reported as "unsupported test" rather then "unexpected fail" on non-power9 systems. The patched test does compile and run successfully on Power 9 with a report of 2 "expected passes". I was expecting the test to fail

Re: [PATCH] gcc/doc: list what version each attribute was introduced in

On Jul 7, 2017, at 10:01 AM, Jeff Law wrote: > > On 07/06/2017 07:25 AM, Daniel P. Berrange wrote: >> There are several hundred named attribute keys that have been >> introduced over many GCC releases. Applications typically need >> to be compilable with multiple GCC versions,

[PATCH v12] add -fpatchable-function-entry=N,M option

Change since v11: < +#if TARGET_HAVE_NAMED_SECTIONS > + if (record_p && targetm_common.have_named_sections) (plus > +#include "common/common-target.h" ) Torsten gcc/c-family/ChangeLog 2017-07-07 Torsten Duwe * c-attribs.c (c_common_attribute_table): Add

[PATCH] document IntegerRange in internals manual

A conflict in my patch for bug 81345 made me notice that r249734 recently added a new option property, IntegerRange. The change below adds brief documentation of the property to the manual. Martin, can you please check to make sure I didn't miss anything? Btw., while experimenting with the

[committed] libcpp: preserve ranges within macro expansions (PR c++/79300)

Comment #4 of PR c++/79300 noted a place in which we fail to underline the full token of a macro name in maybe_unwind_expanded_macro_loc. Root cause is that linemap_macro_loc_to_def_point drops range information too early when following the macro expansions; fixed thusly. Successfully

Re: [PATCH], PowerPC target_clones minor support

On Fri, Jul 07, 2017 at 07:22:04AM -0500, Segher Boessenkool wrote: > On Wed, Jun 28, 2017 at 02:28:23PM -0400, Michael Meissner wrote: > > Some minor changes to the PowerPC target_clones support: > > > > 1) I added a warning if target_clones was used and the compiler whas > > configured > >

Re: Avoid global optimize flag checks in LTO

> On 7 July 2017 15:31:55 CEST, Jan Hubicka wrote: > >Hi, > >this patch fixes some places where we check global optimize flag rather > >than > >doing it per-function. This makes optimization attribute work closer to > >what one gets when passing the same flag at command line. >

Re: Avoid global optimize flag checks in LTO

On 7 July 2017 15:31:55 CEST, Jan Hubicka wrote: >Hi, >this patch fixes some places where we check global optimize flag rather >than >doing it per-function. This makes optimization attribute work closer to >what one gets when passing the same flag at command line. >This requires

Re: [PATCHv2][PR 57371] Remove useless floating point casts in comparisons

On Fri, 7 Jul 2017, Yuri Gribov wrote: > Hi all, > > This is an updated version of patch in > https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00034.html . It should > be much more complete, both in functionality and in tests. I think there should be tests when the constant is an infinity (of

Re: [PATCH] gcc/doc: list what version each attribute was introduced in

On 07/06/2017 07:25 AM, Daniel P. Berrange wrote: > There are several hundred named attribute keys that have been > introduced over many GCC releases. Applications typically need > to be compilable with multiple GCC versions, so it is important > for developers to know when GCC introduced support

Re: [PATCH] Improve i?86/x86_64 prologue_and_epilogue for leaf functions (PR target/59501)

On Fri, Dec 20, 2013 at 8:06 AM, Jakub Jelinek wrote: > Hi! > > Honza recently changed the i?86 backend, so that it often doesn't > do -maccumulate-outgoing-args by default on x86_64. > Unfortunately, on some of the here included testcases this regressed > quite a bit the

Re: [PATCH] prevent -Wall from resetting -Wstringop-overflow=2 to 1 (pr 81345)

This patch is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH][PR 57371] Remove useless floating point casts in comparisons

On 07/03/2017 12:59 PM, Marc Glisse wrote: >> What happens if @0 is a floating point type? Based on the variable name >> "itype" and passing TYPE_PRECISION (itype) to real_to_integer, it seems >> like you're expecting @0 to be an integer. If so, you should verify >> that it really is an integer

Re: [PATCH][2/2] PR60510, reduction chain vectorization w/o SLP

On 03/07/17 14:42, Richard Biener wrote: > > The following is the patch enabling non-SLP vectorization of failed SLP > reduction chains. It simply dissolves the group composing the SLP > reduction chain when vect_analyze_slp fails to detect the SLP and then > fixes up the remaining pieces in

Re: [PATCH-v3] [SPARC] Add a workaround for the LEON3FT store-store errata

> Great! Would you mind to apply the patch for us? The only person here > with write access just went on vacation. I have submitted a new version > (v4) with the change that applies to both main and 7. OK, will do. -- Eric Botcazou

Re: Handle data dependence relations with different bases

> Ah, yeah. And doing that shows that I'd not handled safelen for > DDR_COULD_BE_INDEPENDENT_P. I've fixed that locally. > > How does this look? Tested on x86_64-linux-gnu both without the > vectoriser changes and with the fixed vectoriser patch. > > Thanks, > Richard > > > 2017-07-07

Re: [PATCH] add vec_pack_to_short builtin.

On Fri, Jul 07, 2017 at 08:17:22AM -0700, Carl Love wrote: > The following patch adds support for the vec_pack_to_short builtin. The > patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE) and > powerpc64-unknown-linux-gnu(Power 9 LE). > > Please let me know if the following patch

Re: [PATCH V2 0/7] Support for the SPARC M8 cpu

> See the individual patch descriptions for more information and > associated ChangeLog entries. > > After this serie gets integrated upstream we will be contributing more > support for M8 capabilities, such as support for using the new >

Re: [PATCH], PR target/81348: Fix compiler segfault on -mcpu=power9 code

On Fri, Jul 07, 2017 at 09:19:56AM -0400, Michael Meissner wrote: > This patch fixes a typo where the wrong operand was used (a memory was used > where a register was intended), and the compiler segfaulted. > > I did the bootstrap and make check with no regression on a little endian > power8 >

Re: [PATCH, rs6000] Modify libgcc's float128 IFUNC resolver functions to use __builtin_cpu_supports()

On Thu, Jul 06, 2017 at 04:21:48PM -0500, Peter Bergner wrote: > * config/rs6000/float128-ifunc.c: Don't include auxv.h. > (have_ieee_hw_p): Delete function. > (SW_OR_HW) Use __builtin_cpu_supports(). Okay for trunk. Thanks! Segher

[PATCH] add vec_pack_to_short builtin.

GCC Maintainers: The following patch adds support for the vec_pack_to_short builtin. The patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE) and powerpc64-unknown-linux-gnu(Power 9 LE). Please let me know if the following patch is acceptable. Thanks.

Re: [PATCH, rs6000] 1/2 Add x86 MMX <mmintrin,h> intrinsics to GCC PPC64LE taget

On Thu, Jul 06, 2017 at 09:41:00AM -0500, Steven Munroe wrote: > + Net. Most MMX intrinsic operations can be performed efficiently as > + C language 64-bit scalar operation or optimized to use the newer > + 128-bit SSE/Altivec operations. */ I don't understand what "Net." is, maybe you can

Re: [PATCH, VAX] Correct ffs instruction constraint

Am 06.07.2017 um 20:53 schrieb Jeff Law: > Hmm, unfortunately I consistently get a call to into libgcc for the > __builtin_ffs code rather than an ffs instruction. That's with a > gcc-4.8.3 as well as with trunk compiler. > > Can you include "-v" output from compiling scsipi_base? Hope this is

[patch,avr] Fix PR20296 / PR81268: Better ISR prologues / epilogues

Hi, this patch addresses a very old issue, the non-optimal generation of ISR prologues and epilogues. As GAS now provides the __gcc_isr pseudo instruction to overcome some problems, see https://sourceware.org/bugzilla/show_bug.cgi?id=21683 this can now be used to address PR20296. This patch

Re: [PATCH, GCC/ARM] Remove ARMv8-M code for D17-D31

On 06/07/17 13:36, Thomas Preudhomme wrote: > Hi Richard, > > On 28/06/17 16:56, Richard Earnshaw (lists) wrote: > >>> >> >> This is silently baking in dangerous assumptions about GCC's internal >> numbering of the registers. That's not a good idea from a long-term >> portability perspective.

Re: Handle data dependence relations with different bases

Eric Botcazou writes: > [Sorry for missing the previous messages] > >> Thanks. Just been retesting, and I think I must have forgotten >> to include Ada last time. It turns out that the patch causes a dg-scan >> regression in gnat.dg/vect17.adb, because we now think that

Re: [PATCH v11] add -fpatchable-function-entry=N,M option

On 06/07/17 15:03, Torsten Duwe wrote: > Permit A 38 > > gcc/c-family/ChangeLog > 2017-07-06 Torsten Duwe > > * c-attribs.c (c_common_attribute_table): Add entry for > "patchable_function_entry". > > gcc/lto/ChangeLog > 2017-07-06 Torsten Duwe > >

Avoid global optimize flag checks in LTO

Hi, this patch fixes some places where we check global optimize flag rather than doing it per-function. This makes optimization attribute work closer to what one gets when passing the same flag at command line. This requires to run IPA passes even with !optimize, but having fast way through which

[PATCH], PR target/81348: Fix compiler segfault on -mcpu=power9 code

This patch fixes a typo where the wrong operand was used (a memory was used where a register was intended), and the compiler segfaulted. I did the bootstrap and make check with no regression on a little endian power8 system. Can I install this in the trunk and the gcc 7.x branch (it isn't an

Re: [PATCH], PowerPC target_clones minor support

On Wed, Jun 28, 2017 at 02:28:23PM -0400, Michael Meissner wrote: > Some minor changes to the PowerPC target_clones support: > > 1) I added a warning if target_clones was used and the compiler whas > configured > with an older glibc where __builtin_cpu_supports always returns 0; > > 2) I

Re: [PR80693] drop value of parallel SETs dropped by combine

Hi again, sorry for the delay, On Fri, Jun 23, 2017 at 11:01:12PM -0300, Alexandre Oliva wrote: > > Things should probably be restructured a bit so we keep the sets count > > correct, if that is possible? > > I'll have to think a bit to figure out the exact conditions in which to > decrement the

Re: [PATCH] Fix expand_builtin_atomic_fetch_op for pre-op (PR80902)

On Thu, Jun 22, 2017 at 10:59:05PM -0600, Jeff Law wrote: > On 05/28/2017 06:31 AM, Segher Boessenkool wrote: > > __atomic_add_fetch adds a value to some memory, and returns the result. > > If there is no direct support for this, expand_builtin_atomic_fetch_op > > is asked to implement this as

Re: [PATCH-v3] [SPARC] Add a workaround for the LEON3FT store-store errata

On 2017-07-07 12:01, Eric Botcazou wrote: We can drop the define if necessary, but we would like to keep the two flags. Would that be OK to apply? Yes, OK to apply on mainline and 7 branch with this change, thanks. Great! Would you mind to apply the patch for us? The only person here with

[PATCH-v4] [SPARC] Add a workaround for the LEON3FT store-store errata

This patch adds a workaround to the Sparc backend for the LEON3FT store-store errata. It is enabled when using the -mfix-ut699, -mfix-ut700, or -mfix-gr712rc flag. The workaround inserts NOP instructions to prevent the following two instruction sequences from being generated: std ->

[PATCH][AArch64] Improve aarch64_legitimate_constant_p

This patch further improves aarch64_legitimate_constant_p. Allow all integer, floating point and vector constants. Allow label references and non-anchor symbols with an immediate offset. This allows such constants to be rematerialized, resulting in smaller code and fewer stack spills. SPEC2006

[patch] Fix ICE on CONSTRUCTOR containing absolute addresses

Hi, this fixes the following ICE in decode_addr_const: +===GNAT BUG DETECTED==+ | 8.0.0 20170704 (experimental) [trunk revision 249942] (x86_64-suse-linux) GCC error:| | in decode_addr_const, at varasm.c:2880 stemming from a CONSTRUCTOR

Re: [PATCH V2 0/7] Support for the SPARC M8 cpu

From: jose.march...@oracle.com (Jose E. Marchesi) Date: Fri, 07 Jul 2017 12:53:37 +0200 > I will be committing to svn in both trunk and the gcc 7 branch. Thank you for doing this work.

Re: [PATCH V2 0/7] Support for the SPARC M8 cpu

Hi Eric. > This patch serie adds support for the SPARC M8 processor to GCC. > The SPARC M8 processor implements the Oracle SPARC Architecture 2017. Thanks for the contribution! Thank you for the review :) > The first four patches are preparatory work: > > -

Re: [PATCH V2 0/7] Support for the SPARC M8 cpu

> This patch serie adds support for the SPARC M8 processor to GCC. > The SPARC M8 processor implements the Oracle SPARC Architecture 2017. Thanks for the contribution! > The first four patches are preparatory work: > > - bmask* instructions are put in their own instruction type. It makes >

Re: [PATCH, rs6000] Modify libgcc's float128 IFUNC resolver functions to use __builtin_cpu_supports()

On 07/06/2017 11:21 PM, Peter Bergner wrote: > I will note that this patch causes issues in some tests in the GLIBC > testsiute, > which Tulio is working on fixing (it's a GLIBC issue, not a GCC issue), so if > this patch is "ok", I plan on holding off on committing this, until the GLIBC > fix is

Re: [PATCH-v3] [SPARC] Add a workaround for the LEON3FT store-store errata

> We can drop the define if necessary, but we would like to keep the two > flags. Would that be OK to apply? Yes, OK to apply on mainline and 7 branch with this change, thanks. -- Eric Botcazou

[PING^3][PATCH][Aarch64] Relational compare zero not merged into subtract

Ping^3. Original patch posted here: https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00091.html