Re: [PATCH v2 01/31] PR target/58901: reload: Handle SUBREG of MEM with a mode-dependent address

On Thu, 26 Nov 2020, Maciej W. Rozycki wrote: > > > PR target/58901 > > > * reload.c (push_reload): Also reload the inner expression of a > > > SUBREG for pseudos associated with a mode-dependent memory > > > reference. > > > (find_reloads): Force a reload likewise. > > > > Thanks for

Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

Segher,   Thanks for your comments. I have modified the patch according to your advice and committed. On 24/11/2020 上午 6:25, Segher Boessenkool wrote: Hi! Sorry this took so long. On Thu, Oct 15, 2020 at 04:46:01PM +0800, HAO CHEN GUI wrote: On 29/9/2020 上午 6:46, Segher Boessenkool wrote:

Re: [PATCH 3/4] rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8

Hi Segher, Thanks for the approval of [PATCH 1/4] and [PATCH 2/4], what's your opinion of this [PATCH 3/4] for P8, please? xxinsertw only exists since v3.0, so we had to implement by another way. Xionghu On 2020/10/10 16:08, Xionghu Luo wrote: > gcc/ChangeLog: > > 2020-10-10 Xionghu Luo

Re: [committed obvious][arm] Add test that was missing from old commit [PR91816]

On 26/11/2020 09:01, Christophe Lyon wrote: On Wed, 25 Nov 2020 at 14:24, Stam Markianos-Wright via Gcc-patches wrote: Hi all, A while back I submitted GCC10 commit: 44f77a6dea2f312ee1743f3dde465c1b8453ee13 for PR91816. Turns out I was an idiot and forgot to include the test in the

[committed] libstdc++: Define (and use) _GLIBCXX_HAVE_ATOMIC_WAIT

In order to simplify the preprocessor checks for whether __atomic_wait is available, this commit does: -#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX +#ifdef _GLIBCXX_HAVE_ATOMIC_WAIT The original was wrong anyway, as it should have used 'defined' to check

Re: [committed] libstdc++: Add "futex" and "gthreads" effective-target keywords

On 26/11/20 17:10 +, Jonathan Wakely wrote: On 26/11/20 16:25 +, Jonathan Wakely wrote: +# Return 1 if futex syscall is available +proc check_effective_target_gthreads { } { +return [check_v3_target_gthreads_timed] Oops, I've just noticed the comment is wrong and this calls the

Re: More new AIX errors

On 26/11/20 22:33 +, Jonathan Wakely wrote: On 26/11/20 15:33 -0500, David Edelsohn via Libstdc++ wrote: Hi, Jonathan Thanks for the recent fixes. I still see a few errors that have crept in on AIX. All the same: FAIL: 17_intro/headers/c++2020/all_no_rtti.cc (test for excess errors)

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, Nov 26, 2020 at 01:56:03PM -, Roger Sayle wrote: > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -3998,7 +3998,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > (cmp @0 { build_real (TREE_TYPE (@1), dconst0); })) > /* x != NaN is always true, other ops are always false. */ > (if

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Thu, 26 Nov 2020, Thomas Koenig wrote: > If you want to look at something quite close to the standard, you can > check out https://j3-fortran.org/doc/year/18/18-007r1.pdf . Thanks! Maciej

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Rainer Orth wrote: maybe this is enough to cover all bases without having to do any version or target checks. (untested) objdump is not available on quite a few Darwin versions with perfectly functional uleb128 - so I don’t want to punt on those for absence of it. We already check for

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Thu, 26 Nov 2020, Thomas Koenig wrote: > > What do you need this information for anyway? > > It's a check if the simplification to constants of these > floating point types is done correctly. Well, GCC's handling of the various FP formats is in the middle end (see gcc/real.c and the

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi Iain, > maybe this is enough to cover all bases without having to do any version or > target checks. (untested) > > objdump is not available on quite a few Darwin versions with perfectly > functional > uleb128 - so I don’t want to punt on those for absence of it. We already > check for >

[PATCH fortran/95342] - [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913

Dear all, two almost obvious, trivial issues issues with NULL pointer dereferences. Steve found the locations, but his solution changes the error messages as compared to 7/8. I've chosen the conservative way which keeps the documented intent of the source code. Regtested on x86_64-pc-linux-gnu.

Re: [PATCH/RFC] rs6000: Disable HTM for Power10 and later

Hi! On Thu, Nov 26, 2020 at 06:15:04PM +0800, Kewen.Lin wrote: > During previous Power10 testing, I noticed that ISA 3.1 has > dropped TM support. I think we should not generate TM > related instructions for Power10 and later, or no? > > This patch is to turn off HTM support once we know the

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi folks, Rainer Orth wrote: On Thu, Nov 26, 2020 at 02:26:58PM +0100, Rainer Orth wrote: which shows that the problem is detected in the depths of libbacktrace's DWARF reader. There's something completely off in places, like line numbers well beyond the end of dwarf.c. TBH, I don't

Re: [PATCH] libgfortran: Correct FP feature macro checks

Am 26.11.20 um 19:05 schrieb Maciej W. Rozycki: What do you need this information for anyway? It's a check if the simplification to constants of these floating point types is done correctly. Another interesting thing to look at would be selected_real_kind. selected_real_kind(precision,

Re: [PATCH] libgfortran: Correct FP feature macro checks

Am 26.11.20 um 18:34 schrieb Maciej W. Rozycki: Yeah, I've seen it my Fortran reference (not an official standard though; I don't remember where to get them from and given I don't seem to have a copy, I suspect they are charged for). If you want to look at something quite close to the

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Thu, 26 Nov 2020, Maciej W. Rozycki wrote: > > Also, this is amazing work! > > Thanks, appreciated, although I've been doing this kind of things for > some 20 years now (and much longer when it comes to all kinds of computer > programming and fiddling with microprocessors), so it's bread

[PATCH] Introduce can_vec_cmp_compare_p

Bootstrapped and regtested on x86_64-redhat-linux and s390x-redhat-linux. Ok for master? This is the same as dcd2ca63ec5c ("Introduce can_vcond_compare_p function"), but for vec_cmp. The reason it's needed is that since 5d9ade39b872 ("IBM Z: Fix PR97326: Enable fp compares in vec_cmp") and

[PATCH] rtl_dump_bb: fix segfault when reporting internal error

Bootstrapped and regtested on x86_64-redhat-linux and s390x-redhat-linux. Ok for master? During ICE reporting, sometimes rtl_dump_bb is called on partially initialized basic blocks. This produces another ICE, obscuring the original problem. Fix by checking that that basic blocks are

[PATCH] profopt-execute: unset testname_with_flags if create_gcov fails

Bootstrapped and regtested on x86_64-redhat-linux and s390x-redhat-linux. Ok for master? When diffing test results, there sometimes occur spurious "New tests that PASS" / "Old tests that passed, that have disappeared" messages. The reason is that if create_gcov is not installed, then the

[r11-5398 Regression] FAIL: gcc.target/i386/pr96906-1.c scan-assembler-times \tvpminuw[^\n\r]*ymm 2 on Linux/x86_64

On Linux/x86_64, 32b0abb24b8702ec9954448739682ace6fa5ccf5 is the first bad commit commit 32b0abb24b8702ec9954448739682ace6fa5ccf5 Author: Jakub Jelinek Date: Thu Nov 26 08:44:15 2020 +0100 i386: Optimize psubusw compared to 0 into pminuw compared to op0 [PR96906] caused FAIL:

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Wed, 25 Nov 2020, Joseph Myers wrote: > > For the other pieces that are missing perhaps my work I did many years > > ago to port glibc 2.4 (the last one I was able to cook up without NPTL), > > and specifically libm within, to the never-upstreamed VAX/Linux target > > might be useful to

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Thu, Nov 26, 2020 at 06:01:31PM +, Maciej W. Rozycki wrote: > The VAX/NetBSD port however does use hardware FP in their libm as far as > I can tell, so I guess it would be reasonable for libgfortran to do so as > well. I haven't checked how correct their implementation actually is, but

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Thu, 26 Nov 2020, Ian Lance Taylor wrote: > I just want to note that as far as I can tell this is not a bug in the > Go frontend code. Ack. I thought it might be the case as the file in question hasn't changed for a while now, so it wasn't a Go frontend change that triggered the warning.

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Thu, 26 Nov 2020, Thomas Koenig wrote: > On my (IEEE) box, this prints > > r = 3.402823e+38 d = 1.797693e+308 i = 4 > > so if you have a working printf (or some other way to display > floating-point-variables) for C, you can examine the > values. This prints: r = 1.701412e+38 d =

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Wed, 25 Nov 2020, co...@sdf.org wrote: > I've been building successfully with setting: > export ac_cv_func_freelocale=no > export ac_cv_func_newlocale=no > export ac_cv_func_uselocale=no It's a workaround really, though surely one that works; I've done things like this myself regularly,

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Wed, 25 Nov 2020, Tobias Burnus wrote: > > Well, it does not link, for the somewhat unsurprising reason of a missing > > libgfortran runtime. I have modified the program with whatever little > > Fortran skills I gained a while ago to get something that can be parseable > > for a human being

Re: [PATCH] libgfortran: Verify the presence of all functions for POSIX 2008 locale

On Wed, 25 Nov 2020, Tobias Burnus wrote: > Patch looks good to me. This has now been committed, thank you for your review. > PS: Are there still remaining issues to be solved? Or does libgfortran > now build? Sadly this is not enough for VAX/NetBSD, but as I gather from a comment in the

[PATCH] aarch64: Introduce --param=aarch64-autovec-preference to select autovec preference in backend

Hi all, This is a patch that introduces the aarch64-autovec-preference that can take values from 0 - 4, 0 being the default. It can be used to override the autovectorisation preferences in the backend: 0 - use default scheme 1 - only use Advanced SIMD 2 - only use SVE 3 - use Advanced SIMD and

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Wed, 25 Nov 2020, Tobias Burnus wrote: > LGTM. Applied now, thank you for your review. Maciej

Re: [PATCH v2 01/31] PR target/58901: reload: Handle SUBREG of MEM with a mode-dependent address

On Tue, 24 Nov 2020, Eric Botcazou wrote: > > First posted at: . > > > > 2020-11-24 Matt Thomas > > Maciej W. Rozycki > > > > gcc/ > > PR target/58901 > > * reload.c (push_reload): Also reload the inner expression of a >

Re: [committed] libstdc++: Add "futex" and "gthreads" effective-target keywords

On 26/11/20 16:25 +, Jonathan Wakely wrote: +# Return 1 if futex syscall is available +proc check_effective_target_gthreads { } { +return [check_v3_target_gthreads_timed] Oops, I've just noticed the comment is wrong and this calls the wrong proc. It should be check_v3_target_gthreads

Re: [07/23] Add a class that multiplexes two pointer types

Martin Sebor writes: > I do have one concern: the tendency to prioritize efficiency > over safety (this can be said about most GCC code). Specifically > in this class, the address bit twiddling makes me uneasy. I don't > think the object model in either language (certainly not C but > I don't

Re: [PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard

"Richard Earnshaw (lists)" writes: > On 26/11/2020 13:53, Andrea Corallo via Gcc-patches wrote: >> Hi all, >> >> I'd like to submit the following simple patch to clean some Low Loop >> Overhead test failing on hard float configurations. >> >> lob2.c and lob5.c are failing with:

Re: [PATCH] clean up more -Wformat-diag (PR 94982)

H.J. Lu via Gcc-patches wrote: On Tue, Nov 24, 2020 at 5:13 PM Martin Sebor via Gcc-patches wrote: The attached patch cleans up most remaining -Wformat-diag instances in an x86_64-build. I tried to minimize using #pragma diagnostic so I tweaked the code instead. A preferable solution might

[PATCH] doc: Fix description of dg-require-effective-target

The optional target selector for the dg-require-effective-target directive needs to be { target selector } not just { selector } as currently documented. gcc/ChangeLog: * doc/sourcebuild.texi (Directives): Fix description of dg-require-effective-target to include "target" in

Re: [PATCH] libstdc++: Add C++2a synchronization support

On 25/11/20 18:39 +, Jonathan Wakely wrote: On 25/11/20 10:35 +, Jonathan Wakely wrote: I've pushed that as ad9cbcee543ecccd79fa49dafcd925532d2ce210 but there are still other FAILs to be fixed. I think the other FAILs are due to a race condition in the tests, fixed by this patch.

[committed] libstdc++: Set dg-timeout-factor for some slow tests

These tests are very, very slow to compile. If the testsuite is run with a low tool_timeout value they are likely to fail. By adding a multiplication factor to those tests, it's still possible to use a low timeout without spurious failures. libstdc++-v3/ChangeLog: *

[committed] libstdc++: Allow dejagnu tool_timeout to be overridden

This allows the default timeout for libstdc++ tests to be set by the user, either in ~/.dejagnurc or a site.exp file that $DEJAGNU names. libstdc++-v3/ChangeLog: * testsuite/lib/libstdc++.exp (libstdc++_init): Only set tool_timeout if it hasn't been set by the user already.

[committed] libstdc++: Add "futex" and "gthreads" effective-target keywords

This adds a new "futex" effective-target keyword that can be used to selectively enable/disable tests based on _GLIBCXX_HAVE_LINUX_FUTEX, instead of checking for that macro in the code. It also adds "gthreads" as another one, to make the result of the dg-require-gthreads directive usable in

Re: [07/23] Add a class that multiplexes two pointer types

Jeff Law writes: > On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote: >> This patch adds a pointer_mux class that provides similar >> functionality to: >> >> union { T1 *a; T2 *b; }; >> ... >> bool is_b_rather_than_a; >> >> except that the is_b_rather_than_a tag is stored

Re: [00/23] Make fwprop use an on-the-side RTL SSA representation

Thanks for the reviews. Jeff Law via Gcc-patches writes: > On 11/13/20 1:10 AM, Richard Sandiford via Gcc-patches wrote: >> Just after GCC 10 stage 1 closed (oops), I posted a patch to add a new >> combine pass. One of its main aims was to allow instructions to move >> around where necessary in

[SPARC] Fix PR target/96607

After 15 years trying to find out what can go into the delay slot of the call to __tls_get_addr with the Solaris linker, it's time to concede defeat. As Vita says in the PR: "Solaris linker doesn't expect anything in the branch delay slot of the above call instruction. An optimized sequence

Re: [PATCH] clean up more -Wformat-diag (PR 94982)

On Tue, Nov 24, 2020 at 5:13 PM Martin Sebor via Gcc-patches wrote: > > The attached patch cleans up most remaining -Wformat-diag instances > in an x86_64-build. I tried to minimize using #pragma diagnostic > so I tweaked the code instead. A preferable solution might be to > introduce a new

Re: [PATCH 1/7] arm: Auto-vectorization for MVE: vand

Hi Andre, Thanks for the quick feedback. On Wed, 25 Nov 2020 at 18:17, Andre Simoes Dias Vieira wrote: > > Hi Christophe, > > Thanks for these! See some inline comments. > > On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote: > > This patch enables MVE vandq instructions for

[PATCH] tree-optimization/97953 - fix bougs range recorded by EVRP

EVRP records some ranges from asserts into SSA_NAME_RANGE_INFO but fails to assert that the condition the range is derived from is always true after the SSA names definition. The patch implements the simplest post-dominance check, basic-block equality. Bootstrapped and tested on

[PATCH] tree-optimization/98015 - fix VEC_COND_EXPR lowering condition

This fixes the condition to match the comment and only lower VECTOR_BOOLEAN_TYPE_P VEC_COND_EXPRs. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2020-11-26 Richard Biener * gimple-isel.c (gimple_expand_vec_cond_expr): Only lower VECTOR_BOOLEAN_TYPE_P

Re: [PATCH] gimple-fold: Fix another __builtin_clear_padding ICE

On Thu, 26 Nov 2020, Jakub Jelinek wrote: > Hi! > > When playing with __builtin_bit_cast, I have noticed __builtin_clear_padding > ICE on the G class below. The artificial field with D type has offset 0 > and size 8 bytes, but the following artificial field with E type has offset > 0 and size

[PATCH] c++: v3: Add __builtin_bit_cast to implement std::bit_cast [PR93121]

On Wed, Nov 25, 2020 at 07:52:44PM -0500, Jason Merrill wrote: > > > I think you want to check DECL_PADDING_P here; the C and C++ front ends > > > set > > > it on unnamed bit-fields, and that's what is_empty_type looks at. > > > > Ok, changed in my copy. I'll also post a patch for > >

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi Jakub, > On Thu, Nov 26, 2020 at 02:26:58PM +0100, Rainer Orth wrote: >> which shows that the problem is detected in the depths of >> libbacktrace's DWARF reader. There's something completely off in >> places, like line numbers well beyond the end of dwarf.c. >> >> TBH, I don't

[PATCH] gimple-fold: Fix another __builtin_clear_padding ICE

Hi! When playing with __builtin_bit_cast, I have noticed __builtin_clear_padding ICE on the G class below. The artificial field with D type has offset 0 and size 8 bytes, but the following artificial field with E type has offset 0 and size 0, so it triggers the asserts that we don't move current

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

On 26/11/2020 14:48, Iain Sandoe wrote: Rainer Orth wrote: unfortunately, Solaris/SPARC results are miserable: So without further investigation, we cannot use the leb128 directives with Solaris/SPARC as. I think Andrew was running GCN (not sure of the results there) - but, I suppose

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Rainer Orth wrote: unfortunately, Solaris/SPARC results are miserable: So without further investigation, we cannot use the leb128 directives with Solaris/SPARC as. I think Andrew was running GCN (not sure of the results there) - but, I suppose that the simplest modification is to do

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Wed, Nov 25, 2020 at 10:36 AM Maciej W. Rozycki wrote: > > On Fri, 20 Nov 2020, Maciej W. Rozycki wrote: > > > These changes have been regression-tested throughout development with the > > `vax-netbsdelf' target running NetBSD 9.0, using said VAXstation 4000/60, > > which uses the Mariah

[committed] amdgcn: Fix early-debug relocations

This patch fixes an error in GCN mkoffload that corrupted relocations in the early-debug info. The code now updates the relocation code without zeroing the symbol index. Andrew Fix early-debug relocations The relocation symbols were inadvertantly wiped when the type was set in mkoffload.

RE: [PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard

Hi Andrea, > -Original Message- > From: Andrea Corallo > Sent: 26 November 2020 13:54 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ; Richard Earnshaw > ; nd > Subject: [PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard > > Hi all, > > I'd like to submit the following

Re: [PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard

On 26/11/2020 13:53, Andrea Corallo via Gcc-patches wrote: > Hi all, > > I'd like to submit the following simple patch to clean some Low Loop > Overhead test failing on hard float configurations. > > lob2.c and lob5.c are failing with: "'-mfloat-abi=hard': selected > processor lacks an FPU". >

i386: Cleanup argument handling in ix86_expand_*_builtin functions.

There is no need for struct with rtx and mode members since mode is never used. 2020-11-26 Uroš Bizjak gcc/ * config/i386/i386-expand.c (ix86_expand_multi_arg_builtin): Remove args array of structs, declare rtx xops array instead. Update all uses. (ix86_expand_args_builtin):

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, Nov 26, 2020 at 03:13:22PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Thu, Nov 26, 2020 at 01:56:03PM -, Roger Sayle wrote: > > My completely untested solution is the attached patch. My apologies, I'm > > not > > even set up to compile things on the laptop that I'm composing

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, Nov 26, 2020 at 01:56:03PM -, Roger Sayle wrote: > My completely untested solution is the attached patch. My apologies, I'm > not > even set up to compile things on the laptop that I'm composing this e-mail > on, > but my notes/proposals on tackling PR97965 are easier expressed as the

Re: [PATCH] Optimize macro: make it more predictable

PING^1 On 11/9/20 11:35 AM, Martin Liška wrote: On 11/3/20 2:34 PM, Jakub Jelinek wrote: On Tue, Nov 03, 2020 at 02:27:52PM +0100, Richard Biener wrote: On Fri, Oct 23, 2020 at 1:47 PM Martin Liška wrote: This is a follow-up of the discussion that happened in thread about

RE: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

Many thanks for including me on this discussion. It's extremely interesting... NaNs have a sign-bit, so copyexpr (and negate and ABS_EXPR) are well-defined, and it's reasonable for nonnegative_p to reflect this. IMHO, the true bug is that we can't fold away (any) comparisons against NaN when

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

On 11/25/20 2:48 PM, Richard Biener wrote: On Mon, Nov 23, 2020 at 2:02 PM Martin Liška wrote: On 11/23/20 12:00 PM, Richard Biener wrote: Can you split out the unifying of -[gf]record-gcc-switches processing and the target hook adjustment from the change introducing

[PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard

Hi all, I'd like to submit the following simple patch to clean some Low Loop Overhead test failing on hard float configurations. lob2.c and lob5.c are failing with: "'-mfloat-abi=hard': selected processor lacks an FPU". lob3.c and lob5.c got "-mfloat-abi=soft and -mfloat-abi=hard may not be

Re: [PATCH] match.pd: Use ranges to optimize some x * y / y to x [PR97997]

On Thu, 26 Nov 2020, Jakub Jelinek wrote: > On Thu, Nov 26, 2020 at 09:24:30AM +, Richard Biener wrote: > > > For signed integers with undefined overflow we already optimize x * y / y > > > into x, but for signed integers with -fwrapv or unsigned integers we > > > don't. > > > The following

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

On Thu, Nov 26, 2020 at 02:26:58PM +0100, Rainer Orth wrote: > which shows that the problem is detected in the depths of > libbacktrace's DWARF reader. There's something completely off in > places, like line numbers well beyond the end of dwarf.c. > > TBH, I don't really feel like diving

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi Iain, >> unfortunately, Solaris/SPARC results are miserable: >> >> * About 1600 Go tests FAIL, spread across go.*, libgo, and gotools, all >> in the same way, it seems: >> >> +FAIL: go.go-torture/execute/array-1.go execution, -O0 >> >> fatal error: DWARF underflow in .debug_line at 3266879

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi Rainer, Rainer Orth wrote: The ports I know of that can benefit from a change here are: [...] Solaris (bootstrapped and tests running on GCC211, but maybe Rainer would want wider checks). I've just manually tried the augmented test on Solaris 10-11.4, SPARC and x86. While

Re: Add -std=c2x, -std=gnu2x, -Wc11-c2x-compat, C2X _Static_assert support

On 11/23/20 5:19 PM, Joseph Myers wrote: On Mon, 23 Nov 2020, Martin Liška wrote: On 10/18/18 1:59 AM, Joseph Myers wrote: - || strcmp (language_string, "GNU C17") == 0) + || strcmp (language_string, "GNU C17") == 0 + || strcmp (language_string, "GNU

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi Iain, >> The ports I know of that can benefit from a change here are: > [...] >> Solaris (bootstrapped and tests running on GCC211, but maybe Rainer would >> want wider checks). > > I've just manually tried the augmented test on Solaris 10-11.4, SPARC > and x86. While the

Re: [wwwdocs] Document libstdc++ header dependency changes

On 26/11/20 11:33 +, Jonathan Wakely via Libstdc++ wrote: Also explain how to replace dynamic exception specifications. And a small correction. Committed to wwwdocs. commit df8e807fa3d534472e1b2084b5fcfc761888ccbc Author: Jonathan Wakely Date: Thu Nov 26 11:51:57 2020 + Fix

[wwwdocs] Document libstdc++ header dependency changes

Also explain how to replace dynamic exception specifications. Committed to wwwdocs. commit 611da69f7782376d2737fe683f5db7ea7a5cdb31 Author: Jonathan Wakely Date: Thu Nov 26 11:31:02 2020 + Document libstdc++ header dependency changes Also explain how to replace dynamic

[committed] libstdc++: Fix undefined FILE* operations in test

We only need to check that the constructor doesn't clear errno, so there's no need to use an invalid FILE* for that. libstdc++-v3/ChangeLog: PR libstdc++/98001 * testsuite/ext/stdio_filebuf/char/79820.cc: Do not pass invalid FILE* to constructor. Tested

[committed] libstdc++: Add new headers to stdc++.h

libstdc++-v3/ChangeLog: * include/precompiled/stdc++.h: Add new headers. * include/std/stop_token: Include unconditionally. Tested powerpc64le-linux. Committed to trunk. commit 127aa17e162384034254e93cd1ae37224c0ce197 Author: Jonathan Wakely Date: Thu Nov 26 11:25:55 2020

Re: [PATCH 3/7] arm: Auto-vectorization for MVE: veor

LGTM,  but please wait for maintainer review. On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote: This patch enables MVE veorq instructions for auto-vectorization. MVE veorq insns in mve.md are modified to use xor instead of unspec expression to support xor3. The xor3 expander is

[PATCH/RFC] rs6000: Disable HTM for Power10 and later

Hi, During previous Power10 testing, I noticed that ISA 3.1 has dropped TM support. I think we should not generate TM related instructions for Power10 and later, or no? This patch is to turn off HTM support once we know the cpu setting is power10 or later, and warn something if the explicit

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, 26 Nov 2020, Jakub Jelinek wrote: > On Thu, Nov 26, 2020 at 09:16:29AM +, Richard Biener wrote: > > > So, I really don't know if we want this or not, posting it for > > > discussions. > > > > Is copysign (x, NaN) supposed to be well-defined? We'd stop folding > > this then, no? >

Re: Don't create location wrapper nodes within OpenACC clauses (was: [WIP] Fold 'NON_LVALUE_EXPR' some more (was: C++ 'NON_LVALUE_EXPR' in OMP array section handling))

On Thu, Nov 26, 2020 at 10:36:43AM +0100, Thomas Schwinge wrote: > So, I understand, 'NON_LVALUE_EXPR's are primarily a C/C++ (only?) front > end construct to wrap nodes that must not be used as a lvalue (per the > programming language standards); rejecting code like 'int x; &(x + 0);', > I

[PATCH] gcc-11/changes: Document new configure flag --enable-s390-excess-float-precision

Hi, To document the new behavior around FLT_EVAL_METHOD and configure flag --enable-s390-excess-float-precision on s390, I propose this update to the Release Notes. Please commit to git-wwwdocs if you agree. Checked against the w3c validator. Thanks, Marius --- htdocs/gcc-11/changes.html | 15

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, Nov 26, 2020 at 09:16:29AM +, Richard Biener wrote: > > So, I really don't know if we want this or not, posting it for discussions. > > Is copysign (x, NaN) supposed to be well-defined? We'd stop folding > this then, no? Yes, we'd stop folding several cases with NaNs. > I think

Re: [PATCH] match.pd: Use ranges to optimize some x * y / y to x [PR97997]

On Thu, Nov 26, 2020 at 09:24:30AM +, Richard Biener wrote: > > For signed integers with undefined overflow we already optimize x * y / y > > into x, but for signed integers with -fwrapv or unsigned integers we don't. > > The following patch allows optimizing that into just x if value ranges >

Re: [PATCH] match.pd: Avoid ICE with shifts [PR97979]

On Thu, Nov 26, 2020 at 09:21:53AM +, Richard Biener wrote: > Btw, when looking I figured that int_const_binop loses the sign > of arg2 when folding a signed shift by an unsigned shift amount > and thus these out-of-bound shifts get interpreted as signed > by wide_int_binop even though they

Re: [PATCH] match.pd: Use ranges to optimize some x * y / y to x [PR97997]

On Thu, 26 Nov 2020, Jakub Jelinek wrote: > Hi! > > For signed integers with undefined overflow we already optimize x * y / y > into x, but for signed integers with -fwrapv or unsigned integers we don't. > The following patch allows optimizing that into just x if value ranges > prove that x * y

Re: [PATCH] gimple-fold: Use DECL_PADDING_P in __builtin_clear_padding

On Thu, 26 Nov 2020, Jakub Jelinek wrote: > Hi! > > On Wed, Nov 25, 2020 at 12:26:17PM -0500, Jason Merrill wrote: > > I think you want to check DECL_PADDING_P here; the C and C++ front ends set > > it on unnamed bit-fields, and that's what is_empty_type looks at. > > While the above has been

Re: [PATCH] match.pd: Avoid ICE with shifts [PR97979]

On Thu, 26 Nov 2020, Jakub Jelinek wrote: > Hi! > > My recent wide_int_binop changes caused ICE on this testcase. > The problem is that for shift where amount has MSB set now fails to optimize > into a constant (IMHO we should treat out of bounds shifts the same later), > but there is a

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, 26 Nov 2020, Jakub Jelinek wrote: > Hi! > > The testcase in the PR > constexpr bool a = __builtin_nan ("") > 0.0; > constexpr bool b = __builtin_nans ("") > 0.0; > constexpr bool c = __builtin_nan ("") < 0.0; > constexpr bool d = __builtin_nans ("") < 0.0; > constexpr bool e =

Re: [PATCH] libgcc: Thumb-1 Floating-Point Library for Cortex M0

Hi, On Fri, 13 Nov 2020 at 00:03, Daniel Engel wrote: > > Hi, > > This patch adds an efficient assembly-language implementation of IEEE-754 > compliant floating point routines for Cortex M0 EABI (v6m, thumb-1). This is > the libgcc portion of a larger library originally described in 2018: > >

Re: [PATCH] testsuite/98002 - fix gcc.dg/strncmp-2.c

On Thu, Nov 26, 2020 at 10:09:11AM +0100, Richard Biener wrote: > This makes sure not to free() memory we have mprotected to PROT_NONE > by calling mprotect again with PROT_READ|PROT_WRITE. This avoids > crashing the allocator when in debug mode. > > Tested on x86_64-unknown-linux-gnu. > > OK?

[PATCH] testsuite/98002 - fix gcc.dg/strncmp-2.c

This makes sure not to free() memory we have mprotected to PROT_NONE by calling mprotect again with PROT_READ|PROT_WRITE. This avoids crashing the allocator when in debug mode. Tested on x86_64-unknown-linux-gnu. OK? 2020-11-16 Richard Biener PR testsuite/98002 *

[PATCH] Fix print_multilib_info when default arguments appear in the option list with '!'

This issue is found when we try to always define MULTILIB_DEFAULTS for -march and -mabi for RISC-V back-end, however `-print-multi-lib` will skip multi-lib setting if match any one of flag in MULTILIB_DEFAULTS, even some options are specified in the option list with '!'. e.g. We have default

Re: [committed obvious][arm] Add test that was missing from old commit [PR91816]

On Wed, 25 Nov 2020 at 14:24, Stam Markianos-Wright via Gcc-patches wrote: > > Hi all, > > A while back I submitted GCC10 commit: > > 44f77a6dea2f312ee1743f3dde465c1b8453ee13 > > for PR91816. > > Turns out I was an idiot and forgot to include the test in the actual > git commit, even my entire

[PATCH] match.pd: Use ranges to optimize some x * y / y to x [PR97997]

Hi! For signed integers with undefined overflow we already optimize x * y / y into x, but for signed integers with -fwrapv or unsigned integers we don't. The following patch allows optimizing that into just x if value ranges prove that x * y will never overflow. It uses the global

i386: Use SDWIM mode iterator for abs and maxmin [PR97873]

Generate special double mode sequence also for QImode and HImode. Without QImode and HImode patterns, middle-end extends operands to SImode and emits SImode conditional move instruction with paradoxical SImode output register. This form is not recognized by STV pass, but a single abs with input

[PATCH] gimple-fold: Use DECL_PADDING_P in __builtin_clear_padding

Hi! On Wed, Nov 25, 2020 at 12:26:17PM -0500, Jason Merrill wrote: > I think you want to check DECL_PADDING_P here; the C and C++ front ends set > it on unnamed bit-fields, and that's what is_empty_type looks at. While the above has been written in the context of __builtin_bit_cast patch, I

[Ada] Add support for 128-bit fixed-point types on 64-bit platforms

This also reimplements the I/O support for all fixed-point types. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * Makefile.rtl (GNATRTL_NONTASKING_OBJS): Likewise. (GNATRTL_128BIT_OBJS): Likewise. (GNATRTL_128BIT_PAIRS): Add new 128-bit variants. *

[Ada] Ada.Numerics.Big_Numbers.Big_Reals.To_Big_Real looses precision

The initial implementation was simply using 'Image which will loose precision in some cases. Fixed by always using a sufficient number of digits. To_Big_Real could be made more efficient by not going through strings, this is left for a later step. Tested on x86_64-pc-linux-gnu, committed on

[Ada] Ada 2020 AI12-0401 Renaming of qualified expression of variable

This AI restricts renaming of a qualified expression to cases where the operand is a constant, or the target subtype statically matches the nominal subtype of the operand, or is unconstrained with no predicates. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_ch8.adb

[Ada] Replace warning suppression with assertion

Routine Resolve_Membership_Op didn't reference its Typ parameter and instead suppressed warning with a suspicious pragma Warning. This could be rather pragma Unreferenced, but actually we can reference the type in assertion that enforces an existing comment. Tested on x86_64-pc-linux-gnu,

[Ada] Improve error message on illegal prefixed procedure call

This patch improves an error message on an illegal prefixed procedure call Obj.Name (Args) when Name denotes a visible component of Obj, as well as a primitive operation of the type of Obj. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_ch6.adb

  1   2   >