Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]

One could also simply remove the error in varasm.c. This would preserve the optimization. As a side effect, this would allow register without __asm__ at file scope, but there do not seem to be any disadvantages. (register at file scope is already diagnosed by the C FE when using --pedantic). Best

Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]

On Sat, Feb 29, 2020 at 09:50:00AM +, Uecker, Martin wrote: > One could also simply remove the error in varasm.c. This > would preserve the optimization. As a side effect, this > would allow register without __asm__ at file scope, but > there do not seem to be any disadvantages. (register > at

Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]

Am Samstag, den 29.02.2020, 10:57 +0100 schrieb Jakub Jelinek: > On Sat, Feb 29, 2020 at 09:50:00AM +, Uecker, Martin wrote: > > One could also simply remove the error in varasm.c. This > > would preserve the optimization. As a side effect, this > > would allow register without __asm__ at file

Re: [PATCH 01/10] i386: Properly encode vector registers in vector move

On Fri, Feb 28, 2020 at 6:15 PM H.J. Lu wrote: > > On Fri, Feb 28, 2020 at 4:16 PM Jeff Law wrote: > > > > On Thu, 2020-02-27 at 06:50 -0800, H.J. Lu wrote: > > > > > > How about this? If it looks OK, I will post the whole patch set. > > It's better. I'm guessing the two cases that were previou

[Patch, fortran] PR92959 - ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

This is a another case of the gotcha's that come from trying to use ts.u.cl->backend_decl directly, where deferred length and even, in this case fixed length characters are concerned. The fix is to make use of the string length obtained from evaluation of the expression. Regtested on FC31/x86_64 -

[PATCH] [9/10 Regression] lto: Also copy .note.gnu.property section

On Fri, Feb 28, 2020 at 7:38 AM H.J. Lu wrote: > > On Fri, Feb 28, 2020 at 6:30 AM H.J. Lu wrote: > > > > When generating the separate file with LTO debug sections, we should > > also copy .note.gnu.property section. > > > > OK for master if there is no regression? > > > > Thanks. > > > > H.J. >

V2 [PATCH 0/6] i386: Properly encode xmm16-xmm31/ymm16-ymm31 for vector move

This patch set was originally submitted in Feb 2019: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01841.html I broke it into 6 smaller patches for easy review. On x86, when AVX and AVX512 are enabled, vector move instructions can be encoded with either 2-byte/3-byte VEX (AVX) or 4-byte EVEX (AV

[PATCH 4/6] i386: Use ix86_output_ssemov for DFmode TYPE_SSEMOV

There is no need to set mode attribute to XImode nor V8DFmode since ix86_output_ssemov can properly encode xmm16-xmm31 registers with and without AVX512VL. gcc/ PR target/89229 * config/i386/i386.c (ix86_output_ssemov): Handle MODE_DF. * config/i386/i386.md (*movdf_interna

[PATCH 1/6] i386: Properly encode vector registers in vector move

On x86, when AVX and AVX512 are enabled, vector move instructions can be encoded with either 2-byte/3-byte VEX (AVX) or 4-byte EVEX (AVX512): 0: c5 f9 6f d1 vmovdqa %xmm1,%xmm2 4: 62 f1 fd 08 6f d1 vmovdqa64 %xmm1,%xmm2 We prefer VEX encoding over EVEX since VEX is sho

[PATCH 6/6] i386: Use ix86_output_ssemov for MMX TYPE_SSEMOV

There is no need to set mode attribute to XImode since ix86_output_ssemov can properly encode xmm16-xmm31 registers with and without AVX512VL. Remove ext_sse_reg_operand since it is no longer needed. PR target/89229 * config/i386/i386.c (ix86_output_ssemov): Handle MODE_V1DF and

[PATCH 5/6] i386: Use ix86_output_ssemov for SFmode TYPE_SSEMOV

There is no need to set mode attribute to V16SFmode since ix86_output_ssemov can properly encode xmm16-xmm31 registers with and without AVX512VL. gcc/ PR target/89229 * config/i386/i386.c (ix86_output_ssemov): Handle MODE_SF. * config/i386/i386.md (*movdf_internal): Call i

[PATCH 2/6] i386: Use ix86_output_ssemov for DImode TYPE_SSEMOV

There is no need to set mode attribute to XImode since ix86_output_ssemov can properly encode xmm16-xmm31 registers with and without AVX512VL. gcc/ PR target/89229 * config/i386/i386.c (ix86_output_ssemov): Handle MODE_DI. * config/i386/i386.md (*movdi_internal): Call ix86

[PATCH 3/6] i386: Use ix86_output_ssemov for SImode TYPE_SSEMOV

There is no need to set mode attribute to XImode since ix86_output_ssemov can properly encode xmm16-xmm31 registers with and without AVX512VL. gcc/ PR target/89229 * config/i386/i386.c (ix86_output_ssemov): Handle MODE_SI. * config/i386/i386.md (*movsi_internal): Call ix86

[committed] Fix trivial testsuite fallout from Vlad's recent IRA changes

Vlad's recent IRA changes twiddled register allocation slightly causing some tests to regress. See http://gcc.gnu.org/jenkins And look at the failures in the last 24hrs. Anyway, I'm working through them right now. This is the first issue. xstormy16 fails one test because of the register allo

Re: Minor regression due to recent IRA changes

On Fri, 2020-02-28 at 13:24 -0700, Jeff Law wrote: > This change: > > > commit 3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d > > Author: Vladimir N. Makarov > > Date: Sun Feb 23 16:20:05 2020 -0500 > > > > Changing cost propagation and ordering colorable bucket > > heuristics for > > PR93564. >

Re: Minor regression due to recent IRA changes

On Sun, 2020-03-01 at 00:43 +0900, Oleg Endo wrote: > > > This could well be a target issue. I haven't tried to debug it. If > > it's a > > target issue, I'm fully comfortable punting it to the SH folks for > > resolving. > > The R0_REGS spill failure is a general problem, in particular with ol

Re: Minor regression due to recent IRA changes

On Sat, 2020-02-29 at 08:47 -0700, Jeff Law wrote: > > It's almost certainly the case that the recent IRA changes are going to stress > R0 more. If I'm reading what Vlad did correctly, one of the tie-breakers its > using now is to choose the lowest numbered register when all else is equal. > So

Re: Minor regression due to recent IRA changes

On Sun, 2020-03-01 at 00:55 +0900, Oleg Endo wrote: > On Sat, 2020-02-29 at 08:47 -0700, Jeff Law wrote: > > It's almost certainly the case that the recent IRA changes are going to > > stress > > R0 more. If I'm reading what Vlad did correctly, one of the tie-breakers > > its > > using now is to c

[committed] Trivial or1k fallout from recent IRA changes

The IRA changes twidded the register allocations slightly. Again I verified that the code should be same from a runtime performance and codesize perspective. Committing momentarily. Jeff diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog index 0ea4ffcc5f9..9b2df5596d7 100644 --- a/

Re: Minor regression due to recent IRA changes

On Sat, 2020-02-29 at 08:57 -0700, Jeff Law wrote: > > > It could open a can of worms. Off the top of my head, R0 is used to > > hold the function return value, and R0:R1 to return structs with sizeof > > > 4 bytes. So if DImode is allocated to R0, it implicitly uses R0:R1, > > > > AFAIR, doesn

[committed] Update baseline symbols for hppa-linux

The attached change updates the baseline symbols for hppa-linux-gnu. Tested on hppa-unknown-linux-gnu. Dave 2020-02-29 John David Anglin PR libstdc++/92906 * config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update. diff --git a/libstdc++-v3/config/abi/post/hppa-linux-gn

Re: Minor regression due to recent IRA changes

On Sun, 2020-03-01 at 01:06 +0900, Oleg Endo wrote: > On Sat, 2020-02-29 at 08:57 -0700, Jeff Law wrote: > > > It could open a can of worms. Off the top of my head, R0 is used to > > > hold the function return value, and R0:R1 to return structs with sizeof > > > > 4 bytes. So if DImode is allocat

Re: Minor regression due to recent IRA changes

On Sat, 2020-02-29 at 09:38 -0700, Jeff Law wrote: > > It really would have just been a workaround for some of the R0 issues anyway. > I think at its core R0 on the SH probably needs to be treated more like a > temporary rather than a general register. But that's probably a huge change, > both i

[committed] Add dg-require-visibility to some tests

This fixes the failure of g++.dg/ext/visibility/ref-temp1.C, gfortran.dg/pr90988_4.f and gfortran.dg/pr91372.f90 on hppa2.0w-hp-hpux11.11. Dave 2020-02-29 John David Anglin * g++.dg/ext/visibility/ref-temp1.C: Require visibility. * gfortran.dg/pr90988_4.f: Likewise. *

[Patch, fortran] PR92976 - [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

I am a tiny bit skeptical that this is a regression but I will check. However, it has clearly been there from the early days of OOP without being picked up. The fix is to ensure that the temporary has the correct type of array spec. Regtested on x86_64/FC31 - OK for trunk and 8-/9- branches ? Ch

[committed] Explicitly link against against libatomic in various libstdc++ tests

We need to explicity link against libatomic on hppa. The attached changes add "dg-add-options libatomic" to the test setup where needed. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2020-02-29 John David Anglin

[committed] Skip libstdc++ charset.cc tests on *-*-hpux*

Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk. Dave 2020-02-29 John David Anglin * testsuite/17_intro/headers/c++1998/charset.cc: Skip on *-*-hpux*. * testsuite/17_intro/headers/c++2011/charset.cc: Likewise. * testsuite/17_intro/headers/c

[PATCH] c++: Fix convert_like in template [PR91465, PR93870, PR92031]

The point of this patch is to fix the recurring problem of trees generated by convert_like while processing a template that break when substituting. For instance, when convert_like creates a CALL_EXPR while in a template, substituting such a call breaks in finish_call_expr because we have two 'thi

[committed] XFAIL some IPA tests that are not supported on 32-bit hppa*-*-hpux*

IPA-SRA does not handle structures passed by invisible reference when the callee does copies. This patch xfails test that depend on this feature on 32-bit hppa*-*-hpux*. Dave 2020-02-29 John David Anglin PR ipa/92548 * gcc.dg/ipa/ipa-sra-12.c: xfail parameter split test on 32

Re: Minor regression due to recent IRA changes

On Sun, 2020-03-01 at 01:47 +0900, Oleg Endo wrote: > On Sat, 2020-02-29 at 09:38 -0700, Jeff Law wrote: > > It really would have just been a workaround for some of the R0 issues > > anyway. > > I think at its core R0 on the SH probably needs to be treated more like a > > temporary rather than a g

[PATCH] c++: Add -std=gnu++20 option [PR93958]

One missing bit from r10-6656. The docs and target-supports.exp already handle -std=gnu++20. Ok? 2020-02-29 Marek Polacek PR c++/93958 - add missing -std=gnu++20. * c.opt: Add -std=gnu++20. --- gcc/c-family/c.opt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) di

[committed] Skip/xfail various tests for gcc-10 on hppa*-*-hpux*

This change addresses a bunch of miscellaneous testsuite issues for hppa*-*-hpux*. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Dave 2020-02-29 John David Anglin * g++.dg/pr90981.C: Skip on hppa*-*-hpux*. * gcc.dg/gnu2x-attrs-1.c: Add dg-require-alias. *

[committed] Fix STATIC_CHAIN_REGNUM for v850 port

Wow, I think I wrote the v850 port back in circa 1997 and this bug has been latent all this time. Vlad's IRA changes twiddled register allocation in just the right way to expose this bug. I'm not sure what I was thinking, but apparently I made a spectacularly bad choice for the STATIC_CHAIN_REGN

coroutines: Add a test for non-trivial await_resume return type (NFC).

Hi Just an improvement to test coverage. Tested on x86_64 darwin and linux, applied to master thanks Iain gcc/testsuite/ChangeLog: 2020-02-29 Iain Sandoe * g++.dg/coroutines/coro1-ret-int-yield-int.h: Add templated awaitable. * g++.dg/coroutines/torture/c

[committed] Disable gnat.dg/socket1.adb on hppa*-*-hpux*

Committed to trunk and gcc-9 branch. Dave 2020-02-29 John David Anglin PR ada/91100 * gnat.dg/socket1.adb: Disable on hppa*-*-hpux*. diff --git a/gcc/testsuite/gnat.dg/socket1.adb b/gcc/testsuite/gnat.dg/socket1.adb index a6bdade304b..154a7aff190 100644 --- a/gcc/testsuite/g

Re: Minor regression due to recent IRA changes

On Sat, 2020-02-29 at 12:35 -0700, Jeff Law wrote: > > Yup. That was roughly what I was thinking and roughly the worry I had with > trying to squash out the quality regressions. But it may ultimately be the > only way to really resolve these issues. Another idea would be to let RA see R0, but i