Re: [PATCH] [X86] Delete Deadcode.

> Hi: > This patch is about to delete dead code in ix86_expand_special_args_builtin. > > Bootstrap and regression test are ok. > > gcc/ChangeLog: > * config/i386/i386-expand.c > (ix86_expand_special_args_builtin): Delete last_arg_constant. @@ -10824,48 +10823,37 @@ ix86_expand_s

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

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 = __builtin_nan ("") >= 0.0; constexpr bool f = __builtin_nans ("") >= 0

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

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 precedent for that already - e.g. division by zero fails to opti

Re: [PATCH] [X86] Delete Deadcode.

On Thu, Nov 26, 2020 at 4:11 PM Uros Bizjak wrote: > > > Hi: > > This patch is about to delete dead code in > > ix86_expand_special_args_builtin. > > > > Bootstrap and regression test are ok. > > > > gcc/ChangeLog: > > * config/i386/i386-expand.c > > (ix86_expand_special_args_b

[PATCH] driver: Don't imply -dD for -g3 -g0 [PR97989]

Hi! The driver enables -dD when preprocessing when -g3 is specified, for obvious reasons that we need the macros to be preserved somewhere for them to make up the debug info. But it enables it even if -g3 is later overridden to -g2, -g1 or -g0, where we in the end don't emit .debug_mac{ros,info}

[Ada] Compiler crash on named association in return aggregate

This patch fixes an error in the compiler whereby static accessibility checks were incorrectly performed on non-discriminant components in return aggregates featuring named associations - causing spurious errors and crashes. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * se

[Ada] Spurious error on formal package with overloaded subprograms

Compiler rejects an instantiation involving a formal package that contains adjacent subprogram declarations with the same name, because in the matching between entities in the formal package and the corresponding actual package, it maps two successive entities in the formal with the same entity (wi

[Ada] Issue advice for error regarding Old/Loop_Entry on unevaluated expr.

Ada puts some restrictions on the use of attributes Old, that SPARK mimics for attribute Loop_Entry, inside a "potentially unevaluated context". These restrictions can be lifted by using pragma Unevaluated_Use_Of_Old with argument Allow. Issue a message to indicate that to the user. Tested on x86_

[Ada] Simplify checks for library unit pragmas

If a library unit pragma is ignored then Check_Valid_Library_Unit_Pragma was rewriting it into a null statement; this null statement then was then detected by at the callsites to terminate analysis of the pragma. Now if a pragma is ignored, then Check_Valid_Library_Unit_Pragma raises an exception

[Ada] Incorrect runtime accessibility check on access discriminant

This patch fixes an error in the compiler whereby returning an anonymous access discriminant of an anonymous access formal within a function that returns an anonymous access type may cause a malformed accessibility check to be generated. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/

[Ada] New warning on questionable missing parentheses

Warn on unparenthesized (in)equality as operand of and/or/xor, as this is a known source of confusion. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_res.adb (Resolve_Equality_Op): Warn when -gnatwq is used (the default) and the problematic case is encountered.d

[Ada] Reuse Is_Access_Object_Type where possible

Simplify calls to Is_Access_Type followed by Is_Access_Subprogram_Type with Is_Access_Object_Type, which does exactly the same. Cleanup related to support for access-to-subprogram in flow analysis of GNATprove; semantics unaffected. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/

[Ada] Pass base type to Set_Has_Own_Invariants

Set_Has_Own_Invariants is a [base type only] field, so should be passed the base type. Set_Has_Own_Invariants and Set_Has_Inherited_Invariants should assert that its parameter is a base type, but we don't do that as part of this change. That will happen as part of the variable-sized nodes change.

[Ada] Adjust documentation of Aft_Value and Scale_Value

This clears some confusion between them by citing the definition of the eponymous attributes in the RM and writing down their relationship. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * einfo.ads (Aft_Value): Adjust documentation. (Scale_Value): Likewise.diff --git

[Ada] Constraint_Error in Task_Wrapper and -u0

When using the gnatbind switch -u0 and a runtime built with checks on, we could get a range check error in System.Tasking.Stages.Task_Wrapper, now fixed. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * libgnarl/s-tassta.adb (Task_Wrapper): Fix computation of Pattern_

[Ada] Memory leak in concatenation with Initialize_Scalars

This patch fixes a memory leak in concatenation when pragma Initialize_Scalars or Normalize_Scalars is used. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * exp_ch4.adb (Expand_Concatenate): Call Set_No_Initialization on the N_Allocator node that is supposed to alloc

[Ada] Warn on slices of the form A (subtype) for all objects

GNAT emits a warning on slices of the form "A (subtype)" if A is a constant; a similar warning is now emitted if A is any object, e.g. formal parameter, loop parameter (when iterating over an array-of-arrays) or component. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_

[Ada] Sync wide Ada.String hashing units

The Wide_Wide_Hash version of Ada.Strings.Hash was instantiated as a library unit. Now all versions are instantiated in wrapper functions. Minor inconsistency, spotted while cleaning up code for categorization pragmas on instance units. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/

[Ada] Remove duplicated calls to Set_Entity

Routine Set_Entity_With_Checks called Set_Entity, did some checks, and then called Set_Entity again. This second call was redundant and had no effect; this patch removes it. Those two calls appear to come from a sequence of refactorings: initially there was just a call to Set_Entity at the end; wh

[Ada] Crash on task declaration with Restriction_Warning (No_Tasking)

Compiler aborts when the Restriction_Warning (No_Tasking) appears as a configuration pragma, and the main unit includes a task declaration. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_prag.adb (Process_Restrictions_Or_Restriction_Warnings): when the restricti

[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 (Analyze_Call_And_Resolve

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

[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 (An

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

[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. * cs

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

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 o

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

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 p

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

[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 * gcc.dg/strn

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

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] 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 = __builtin_n

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 precedent

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 wr

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 w

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 are

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

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

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

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

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 added

[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

[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 powerpc64le-linux.

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

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 ty

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 Solaris/S

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 C

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 th

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.

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

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

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 -frecord-gcc-switches-for

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 fl

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 no_stack_protector

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

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

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

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 sim

[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. gcc/

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 imple

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 eli

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 tha

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

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 really

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

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

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

[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 x86_64-unknown-li

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

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 form

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

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

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 in

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

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

[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: * testsuite/28_regex/alg

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

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

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

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: "'-mfloat-abi=ha

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 hav

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 no

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: [PATCH] libgfortran: Correct FP feature macro checks

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

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

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 oth

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 in

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

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 = 1.701412e

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

[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: gcc.target/

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

  1   2   >