Re: [PATCH V2] correct COUNT and PROB for unrolled loop

Jiufu Guo writes: Hi! I'd like to ping following patch. just in case it may make sense to include in GCC 10. Thanks! https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00927.html Jiufu > Hi Honza and all, > > I updated the patch a little as below. Bootstrap and regtest are ok > on powerpc64le. >

Re: collect2.exe errors not pruned

On Thu, Feb 27, 2020 at 9:17 PM Alexandre Oliva wrote: > > > Testing on platforms with an executable suffix gets a few excess output > failures because e.g. collect2.exe errors do not get pruned. > > I'm not sure it's appropriate for the error to not omit the host > platform's executable suffix,

[PATCH], PR target/93937, Fix variable vec_extract insn that will never match

As part of my work in adding support for -mcpu=future, I noticed an insn that would never match. Here is the insn: (define_insn_and_split "*vsx_extract__mode_var" [(set (match_operand: 0 "gpc_reg_operand" "=r,r,r") (zero_extend: (unspec: [(match_operand:VSX_EXTRACT_I

Re: maxval on -inf and nan in Fortran

On Fri, Feb 28, 2020 at 01:02:28PM +0800, Jiufu Guo wrote: > > With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g. ppc64le/x86. > IMHO, using -ffast-math with Fortran code is never correct. With this option, you got exactly what you wanted. -- Steve

collect2.exe errors not pruned

Testing on platforms with an executable suffix gets a few excess output failures because e.g. collect2.exe errors do not get pruned. I'm not sure it's appropriate for the error to not omit the host platform's executable suffix, just as it omits directory components from argv[0], so I'm

maxval on -inf and nan in Fortran

Hi, When I check a PR93709, I find the testcase maxlocval_4.f90 and minlocval_4.f90 are checking `maxval/minval` on `-inf` and `nan`. https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=blob_plain;f=gcc/testsuite/gfortran.dg/maxlocval_4.f90;hb=HEAD There are code like: ``` l5 = .true. l5(1,1) =

maxval on -inf and nan in Fortran

Hi, When I check a PR93709, I find the testcase maxlocval_4.f90 and minlocval_4.f90 are checking `maxval/minval` on `-inf` and `nan`. https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=blob_plain;f=gcc/testsuite/gfortran.dg/maxlocval_4.f90;hb=HEAD There are code like: ``` l5 = .true. l5(1,1) =

[PATCH v3 4/4] libgomp/test: Remove a build sysroot fix regression

Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation for build sysroot") that caused a regression in some standalone test environments where testsuite/libgomp-test-support.exp is used, but the compiler is expected to be determined by `[find_gcc]', and set the GCC_UNDER_TEST

[PATCH v3 3/4] libgo/test: Complement compilation fix for build sysroot

Complement commit b72813a68c94 ("libgo: fix DejaGNU testsuite compiler when using build sysroot") and move testsuite/libgo-test-support.exp.in to testsuite/libgo-site-extra.exp.in. Update testsuite/lib/libgo.exp to handle the `--tool_exec' option to `runtest' as with other top-level GCC

[PATCH v3 0/4] Fix library testsuite compilation for build sysroot

Hi, This is v3 of patch series, originally posted here:

[PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

Fix a problem with the libffi testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the inability to actually choose any compiler at all in a cross-compilation

[PATCH v3 1/4] libatomic/test: Fix compilation for build sysroot

Fix a problem with the libatomic testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the lack of a suitable `--sysroot=' option where the `--with-build-sysroot='

[committed] correct -Wbuiltin-declaration-mismatch default in manual

Pushed. Martin commit ab466f73bb3bd24965cb2c7635b0339509dafbe3 (HEAD -> master) Author: Martin Sebor Date: Thu Feb 27 16:53:01 2020 -0700 Document that -Wbuiltin-declaration-mismatch is enabled by default. gcc/ChangeLog: * doc/invoke.texi

Re: [PATCH], PR target/93932, GCC 9 backport, Do not use input_operand for variable vector extract insns on PowerPC

On Thu, Feb 27, 2020 at 04:57:28PM -0600, Segher Boessenkool wrote: > Hi, > > On Thu, Feb 27, 2020 at 03:38:54PM -0500, Michael Meissner wrote: > > Here are the equivalent changes for PR target/93932 for the GCC 9 branch. I > > have built both big and little endian PowerPC linux compilers and

Re: gcov: reduce code quality loss by reproducible topn merging [PR92924]

On Thu, 27 Feb 2020, Gerald Pfeifer wrote: >> This (or rather its predecessor?) breaks bootstrap on 32-bit >> i386-unknown-freebsd11.3. >> >> /scratch/tmp/gerald/gcc10-devel-work/gcc-10-20200223/gcc/value-prof.c: In >> function 'void dump_histogram_value(FILE*, histogram_value)': >>

Re: [PATCH], PR target/93932, GCC 9 backport, Do not use input_operand for variable vector extract insns on PowerPC

Hi, On Thu, Feb 27, 2020 at 03:38:54PM -0500, Michael Meissner wrote: > Here are the equivalent changes for PR target/93932 for the GCC 9 branch. I > have built both big and little endian PowerPC linux compilers and both > bootstrapped. The make check actually fixes the tests that were broken

[PATCH] tighten up validation of built-in redeclarations (PR 93926)

GCC considers valid explicit declarations of built-ins whose return types match in their modes, even if the types themselves are incompatible (say integer and pointer of the same size). This is more permissive than for argument types where a pointer/integer mismatch disqualifies the

Re: GLIBC libmvec status

On 2/27/20 2:21 PM, Bill Schmidt wrote: On 2/27/20 12:48 PM, GT wrote: Done. The updated document is at: https://sourceware.org/glibc/wiki/HomePage?action=AttachFile=view=powerarchvectfuncabi.html Looks good. Can you please also remove the 'c' ABI from the mangling, as earlier agreed?

[committed] libstdc++: Disable diagnostic URLs in testsuite

* testsuite/lib/libstdc++.exp (v3_target_compile): Add -fdiagnostics-urls=never to options. Tested x86_64-linux, committed to master. commit 449494943e65e4c9cf668a566b0da13e44d79f3b Author: Jonathan Wakely Date: Thu Feb 27 17:45:06 2020 + libstdc++: Disable diagnostic

[PATCH], PR target/93932, GCC 9 backport, Do not use input_operand for variable vector extract insns on PowerPC

Here are the equivalent changes for PR target/93932 for the GCC 9 branch. I have built both big and little endian PowerPC linux compilers and both bootstrapped. The make check actually fixes the tests that were broken by the register allocation behavior. Can I check these patches into GCC 9?

Re: GLIBC libmvec status

On 2/27/20 12:48 PM, GT wrote: ‐‐‐ Original Message ‐‐‐ On Thursday, February 27, 2020 9:26 AM, Bill Schmidt wrote: Upon reflection, I agree. Bert, we need to make changes to the document to reflect this: (1) "Calling convention" should refer to ELFv1 for powerpc64 and ELFv2 for

Re: gcov: reduce code quality loss by reproducible topn merging [PR92924]

On Mon, 24 Feb 2020, Gerald Pfeifer wrote: > This (or rather its predecessor?) breaks bootstrap on 32-bit > i386-unknown-freebsd11.3. > > /scratch/tmp/gerald/gcc10-devel-work/gcc-10-20200223/gcc/value-prof.c: In > function 'void dump_histogram_value(FILE*, histogram_value)': >

Re: [PATCH] libstdc++: Memoize {drop,drop_while,filter,reverse}_view::begin

On Wed, 26 Feb 2020, Patrick Palka wrote: > On Tue, 11 Feb 2020, Patrick Palka wrote: > > > This patch adds memoization for these four views so that their begin() has > > the > > required constant time amortized complexity. > > > > In the general case we use std::optional to cache the result.

Re: GLIBC libmvec status

‐‐‐ Original Message ‐‐‐ On Thursday, February 27, 2020 9:26 AM, Bill Schmidt wrote: > > Upon reflection, I agree. Bert, we need to make changes to the document to > reflect this: > > (1) "Calling convention" should refer to ELFv1 for powerpc64 and ELFv2 for > powerpc64le. Done. Have

[PATCH] Limit includes in hashtable_policy.h

When I use std::is_permutation in hashtable_policy.h I included stl_algo.h which is a large header. No other header in include/bits does this, I would prefer not being the first to do such a thing. As it is a recent change I prefer to submit this patch now. Git commit message:     libstdc++

Re: [PATCH] libstdc++: -D_GLIBCXX_DEBUG fixes in the constrained algos tests

On 27/02/20 10:42 -0500, Patrick Palka wrote: This fixes some failures in the constrained algos tests when run in debug mode. libstdc++-v3/ChangeLog: * testsuite/25_algorithms/copy/constrained.cc: Don't assume that the base() of an vector<>::iterator is a pointer. *

Re: [PATCH] libstdc++: Add missing friend declarations in some range adaptors

On 27/02/20 11:27 -0500, Patrick Palka wrote: Some of the range adaptors have distinct constant and non-constant iterator/sentinel types, along with converting constructors that can convert a non-constant iterator/sentinel to a constant iterator/sentinel. This patch adds the missing appropriate

[committed] amdgcn: sub-dword vector min/max/shift/bit operators

This patch adds V64QI and V64HI implementations of smin, umin, smax, umax, ashift, ashiftrt, lshiftrt, and, ior, xor, not, and popcount. None of these operators have a specific machine instruction, so they need to use V64SI instructions. For scalar code expr.c can DTRT automatically, but not

Re: [GCC][PATCH][ARM] Add multilib mapping for Armv8.1-M+MVE with -mfloat-abi=hard

Hi Mihail, On 2/20/20 4:15 PM, Mihail Ionescu wrote: Hi, This patch adds a new multilib for armv8.1-m.main+mve with hard float abi. For armv8.1-m.main+mve soft and softfp, the v8-M multilibs will be reused. The following mappings are also updated: "-mfloat-abi=hard

Re: [GCC][PATCH][ARM] Add vreinterpret, vdup, vget and vset bfloat16 intrinsic

Hi Mihail, On 2/27/20 2:44 PM, Mihail Ionescu wrote: Hi Kyrill, On 02/27/2020 11:09 AM, Kyrill Tkachov wrote: Hi Mihail, On 2/27/20 10:27 AM, Mihail Ionescu wrote: Hi, This patch adds support for the bf16 vector create, get, set, duplicate and reinterpret intrinsics. ACLE documents are at

[PATCH] libstdc++: Add missing friend declarations in some range adaptors

Some of the range adaptors have distinct constant and non-constant iterator/sentinel types, along with converting constructors that can convert a non-constant iterator/sentinel to a constant iterator/sentinel. This patch adds the missing appropriate friend declarations in order to make these

New French PO file for 'gcc' (version 10.1-b20200209)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/gcc/fr.po (This file,

Re: [PATCH], PR target/93932, Do not use input_operand for variable vector extract insns on PowerPC

Hi! On Wed, Feb 26, 2020 at 05:32:23PM -0500, Michael Meissner wrote: > What is happening is in some instances, we want to do a vector extract with a > variable element where the vector is in a register: > >#include > > long long > foo (vector long long v, unsigned long n)

Re: structurally compare type_arg_packs [93933]

On 2/27/20 10:33 AM, Nathan Sidwell wrote: On 2/26/20 5:00 PM, Jason Merrill wrote: On 2/25/20 4:09 PM, Nathan Sidwell wrote: We consider all TYPE_ARGUMENT_PACKS distinct types, leading to problems with redeclarations. I'd think that the bug is that we're treating them as types in the first

Re: GLIBC libmvec status

On 2/27/20 9:30 AM, Jakub Jelinek wrote: On Thu, Feb 27, 2020 at 09:19:25AM -0600, Bill Schmidt wrote: On 2/27/20 8:52 AM, Jakub Jelinek wrote: On Thu, Feb 27, 2020 at 08:47:19AM -0600, Bill Schmidt wrote: But is this actually a good idea? It seems to me this will generate lousy code in

[PATCH] libstdc++: -D_GLIBCXX_DEBUG fixes in the constrained algos tests

This fixes some failures in the constrained algos tests when run in debug mode. libstdc++-v3/ChangeLog: * testsuite/25_algorithms/copy/constrained.cc: Don't assume that the base() of an vector<>::iterator is a pointer. *

Re: structurally compare type_arg_packs [93933]

On 2/26/20 5:00 PM, Jason Merrill wrote: On 2/25/20 4:09 PM, Nathan Sidwell wrote: We consider all TYPE_ARGUMENT_PACKS distinct types, leading to problems with redeclarations. I'd think that the bug is that we're treating them as types in the first place; they aren't types, so they shouldn't

Re: GLIBC libmvec status

On Thu, Feb 27, 2020 at 09:19:25AM -0600, Bill Schmidt wrote: > On 2/27/20 8:52 AM, Jakub Jelinek wrote: > > On Thu, Feb 27, 2020 at 08:47:19AM -0600, Bill Schmidt wrote: > > > But is this actually a good idea? It seems to me this will generate lousy > > > code in the absence of hardware support.

Re: GLIBC libmvec status

On 2/27/20 8:52 AM, Jakub Jelinek wrote: On Thu, Feb 27, 2020 at 08:47:19AM -0600, Bill Schmidt wrote: But is this actually a good idea? It seems to me this will generate lousy code in the absence of hardware support. Won't we be better off warning and ignoring the directive, leaving the code

[committed] libstdc++: Fix debug mode test failures

Three fixes for test failures when debug mode is enabled. Tested x86_64-linux, committed to master. commit ae7051590d4bf9b844874e727791f236315c835a Author: Jonathan Wakely Date: Thu Feb 27 15:13:16 2020 + libstdc++: Define <=> for Debug Mode array This fixes a test failure

Re: patch to fix PR93564

On 2020-02-27 7:33 a.m., Andrew Stubbs wrote: On 26/02/2020 15:16, Andrew Stubbs wrote: The problem appears to be that the high-part of a register pair is not marked as "ever live".  I'm trying to figure out whether this is some kind of target-specific issue that has merely been exposed, but

Re: GLIBC libmvec status

On Thu, Feb 27, 2020 at 08:47:19AM -0600, Bill Schmidt wrote: > But is this actually a good idea? It seems to me this will generate lousy > code in the absence of hardware support. Won't we be better off warning and > ignoring the directive, leaving the code in scalar form? Depends on the exact

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

On Wed, Feb 26, 2020 at 4:24 PM Jeff Law wrote: > > On Wed, 2020-02-26 at 16:02 -0800, H.J. Lu wrote: > > On Wed, Feb 26, 2020 at 2:42 PM Jeff Law wrote: > > > On Sat, 2020-02-15 at 07:26 -0800, H.J. Lu wrote: > > > > On x86, when AVX and AVX512 are enabled, vector move instructions can > > > >

Re: GLIBC libmvec status

On 2/26/20 8:31 AM, Jakub Jelinek wrote: On Wed, Feb 26, 2020 at 07:55:53AM -0600, Bill Schmidt wrote: The hope is that we can create a vectorized version that returns values in registers rather than the by-ref parameters, and add code to GCC to copy things around correctly following the call.

Re: [GCC][PATCH][ARM] Add vreinterpret, vdup, vget and vset bfloat16 intrinsic

Hi Kyrill, On 02/27/2020 11:09 AM, Kyrill Tkachov wrote: Hi Mihail, On 2/27/20 10:27 AM, Mihail Ionescu wrote: Hi, This patch adds support for the bf16 vector create, get, set, duplicate and reinterpret intrinsics. ACLE documents are at https://developer.arm.com/docs/101028/latest ISA

Re: [GCC] Fix misleading aarch64 mcpu/march warning string

Hi Joel, On 2/27/20 2:31 PM, Joel Hutton wrote: The message for conflicting mcpu and march previously printed the architecture of the CPU instead of the CPU name, as well as omitting the extensions to the march string. This patch corrects both errors. This patch fixes PR target/87612. before:

[PATCH] Fix broken assert

In implementing Jason's suggested direction for 93933, the compiler exploded in a surprising way. Turns out an assert had been passing NULLS to comptypes, and therefore not checking what it intended. Further comptypes, could silently accept such nulls under most circumstances. Applying

[GCC] Fix misleading aarch64 mcpu/march warning string

The message for conflicting mcpu and march previously printed the architecture of the CPU instead of the CPU name, as well as omitting the extensions to the march string. This patch corrects both errors. This patch fixes PR target/87612. before: $ aarch64-unknown-linux-gnu-gcc -S -O3

Re: GLIBC libmvec status

On 2/27/20 4:52 AM, Segher Boessenkool wrote: On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote: The reason that homogeneous aggregates matter (at least somewhat) is that the ABI ^H^H^H^HAPI requires establishing a calling convention and a name- mangling formula that includes the

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote: On 22/01/2020 17:45, Richard Earnshaw (lists) wrote: [updated based on v2 discussions] This patch proposes some new (additional) rules for email subject lines when contributing to GCC.  The goal is to make sure that, as far as possible, the

[PATCH] Improvements to valid range checks in debug mode

These should wait for stage 1 but I'm posting them now for comment. With the change to __gnu_debug::__valid_range we now get a debug assertion for: std::string s; std::min_element(std::string::iterator{}, s.end()); where previously it would just crash with undefined behaviour. commit

[committed] libstdc++: Support N3644 "Null Forward Iterators" for testsuite iterators

Comparing value-initialized forward_iterator_wrapper objects fails an assertion, but should be valid in C++14 and later. * testsuite/util/testsuite_iterators.h (forward_iterator_wrapper): Add equality comparisons that support value-initialized iterators. Tested powerpc64le-linux,

Re: [PATCH] tree-optimization/93508 - make VN translate through _chk and valueize length

On Thu, 30 Jan 2020, Richard Biener wrote: > > Value-numbering failed to handle __builtin_{memcpy,memset,...}_chk > variants when removing abstraction and also failed to use the > value-numbering lattice when requiring the length argument of the > call to be constant. > > Bootstrapped and

Re: patch to fix PR93564

On 26/02/2020 15:16, Andrew Stubbs wrote: The problem appears to be that the high-part of a register pair is not marked as "ever live".  I'm trying to figure out whether this is some kind of target-specific issue that has merely been exposed, but it's difficult to see what's going on. I'm

[committed] amdgcn: fix ICE on subreg of BI reg

This patch fixes an LRA ICE that was exposed by another patch on Sunday. I can't see any reason why that patch should cause an ICE, so presumably it merely perturbed something. The problem was that LRA with checking enabled was confirming that all the registers it had allocated are considered

Re: [PATCH Coroutines]Insert the default return_void call at correct position

On 2/3/20 12:55 AM, bin.cheng wrote: Hi, Exception in coroutine is not correctly handled because the default return_void call is now inserted before the finish suspend point, rather than at the end of the original coroutine body. This patch fixes the issue by generating following code:

[Patch, fortran] PR fortran/93957 - [10 Regression] ICE (regression) passing assumed rank arrays with bind(c)

Hi all! Proposed patch to solve ICE. Patch tested only on x86_64-pc-linux-gnu. The code currently calls gfc_trans_deferred_array even when it is not necessary triggering an assertion error inside gfc_trans_deferred_array. Please notice the addition of "sym->ts.type == BT_CLASS" to the

Re: GLIBC libmvec status

On Thu, Feb 27, 2020 at 11:56:49AM +0100, Richard Biener wrote: > > > This calling convention would also be useful in the future for vectorizing > > > functions that return complex values either by value or by reference. > > > > Only by value, you really don't know what the code does if something

Re: [GCC][PATCH][ARM] Add vreinterpret, vdup, vget and vset bfloat16 intrinsic

Hi Mihail, On 2/27/20 10:27 AM, Mihail Ionescu wrote: Hi, This patch adds support for the bf16 vector create, get, set, duplicate and reinterpret intrinsics. ACLE documents are at https://developer.arm.com/docs/101028/latest ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Re: GLIBC libmvec status

On Wed, Feb 26, 2020 at 3:31 PM Jakub Jelinek wrote: > > On Wed, Feb 26, 2020 at 07:55:53AM -0600, Bill Schmidt wrote: > > The hope is that we can create a vectorized version that returns values > > in registers rather than the by-ref parameters, and add code to GCC to > > copy things around

[PATCH] libstdc++: Make _GLIBCXX_CONCEPT_CHECKS more constexpr-friendly

Although most of the old-style "concept checks" are only really usable with C++98 because they enforce the wrong things, this is a simple change that makes them a bit more useful for C++14 and up. * include/bits/boost_concept_check.h (__function_requires): Add

Re: GLIBC libmvec status

On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote: > The reason that homogeneous aggregates matter (at least somewhat) is that > the ABI ^H^H^H^HAPI requires establishing a calling convention and a name- > mangling formula that includes the length of parameters and return values. >

[PATCH] tree-optimization/93953 - avoid reference into hash-map

When possibly expanding a hash-map avoid keeping a reference to an entry. Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2020-02-27 Richard Biener PR tree-optimization/93953 * tree-vect-slp.c (slp_copy_subtree): Avoid keeping a reference to the

Re: [PATCH] fix -fdebug-prefix-map without gas .file support

On Wed, 26 Feb 2020, Jason Merrill wrote: > On 2/21/20 5:02 AM, Richard Biener wrote: > > This applies file mapping when emitting the directory table > > directly instead of using the assemblers .file directive where > > we already correctly apply the map. Notably the non-assembler > > path is

Re: PowerPC Add has_arch_pwr* checks

Hi! On Tue, Feb 25, 2020 at 05:02:06PM -0600, will schmidt wrote: >This adds some procs to target-supports.exp that will allow > our testcases to accurately determine which -mcpu= option > is enabled at the time of our testcase compile. Thanks! I had to think about the names a bit (this

[GCC][PATCH][ARM] Add vreinterpret, vdup, vget and vset bfloat16 intrinsic

diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h index 09297831cdcd6e695843c17b7724c114f3a129fe..5901a8f1fb84f204ae95f0ccc97bf5ae944c482c 100644 --- a/gcc/config/arm/arm_neon.h +++ b/gcc/config/arm/arm_neon.h @@ -42,6 +42,15 @@ extern "C" { #include #include +#ifdef

Re: [PATCH] sccvn: Punt on overflows during vn_reference_lookup_3

On Thu, 27 Feb 2020, Jakub Jelinek wrote: > On Thu, Feb 27, 2020 at 10:30:21AM +0100, Richard Biener wrote: > > Obviously I don't like the repetitive boiler-plate after > > the ranges_known_overlap_p checks so I wonder if we can at least > > factor those into a VN-local

Re: [PATCH] sccvn: Punt on ref->size not multiple of 8 for memset (, 123, ) in 9.x [PR93945]

On Thu, 27 Feb 2020, Jakub Jelinek wrote: > Hi! > > And here is the corresponding 9.x change where we the patch just punts if > ref->size is not whole bytes, like we already punt if offseti is not byte > aligned. > > Tested on x86_64-linux and powerpc64-linux, ok for 9.3? OK. Thanks, Richard.

[PATCH] sccvn: Punt on ref->size not multiple of 8 for memset (, 123, ) in 9.x [PR93945]

Hi! And here is the corresponding 9.x change where we the patch just punts if ref->size is not whole bytes, like we already punt if offseti is not byte aligned. Tested on x86_64-linux and powerpc64-linux, ok for 9.3? 2020-02-27 Jakub Jelinek PR tree-optimization/93945 *

Re: [PATCH] optabs: Don't use scalar conversions for vectors [PR93843]

Jakub Jelinek writes: > On Wed, Feb 26, 2020 at 11:43:10AM +, Richard Sandiford wrote: >> In this PR we had a conversion between two integer vectors that >> both had scalar integer modes. We then tried to implement the >> conversion using the scalar optab for those modes, instead of >> doing

Re: [PATCH] sccvn: Punt on overflows during vn_reference_lookup_3

On Thu, Feb 27, 2020 at 10:30:21AM +0100, Richard Biener wrote: > Obviously I don't like the repetitive boiler-plate after > the ranges_known_overlap_p checks so I wonder if we can at least > factor those into a VN-local ranges_known_overlap_for_pd_p predicate. I can do that. > Wouldn't it be

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

On Thu, 27 Feb 2020, Jakub Jelinek wrote: > Hi! > > The following testcase is rejected, while it was accepted in 3.4 and earlier > (before tree-ssa merge). > The problem is that we decide to promote the const variable to TREE_STATIC, > but TREE_STATIC DECL_REGISTER VAR_DECLs may only be the

Re: [PATCH] sccvn: Punt on overflows during vn_reference_lookup_3

On Thu, 27 Feb 2020, Jakub Jelinek wrote: > Hi! > > I admit I don't have testcases, but I'm afraid very bad things will happen > if either the offset2i - offseti or pd.offset + pd.size computations > overflow. All are computed in (signed) HOST_WIDE_INT, and at least for the > memset or

Re: [PATCH] sccvn: Handle non-byte aligned offset or size for memset (, 123, ) [PR93945]

On Thu, 27 Feb 2020, Jakub Jelinek wrote: > Hi! > > The following is the last spot in vn_reference_lookup_3 that didn't allow > non-byte aligned offsets or sizes. To be precise, it did allow size that > wasn't multiple of byte size and that caused a wrong-code issue on > big-endian, as the

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

Hi! The following testcase is rejected, while it was accepted in 3.4 and earlier (before tree-ssa merge). The problem is that we decide to promote the const variable to TREE_STATIC, but TREE_STATIC DECL_REGISTER VAR_DECLs may only be the global register vars and so assemble_variable/make_decl_rtl

Re: middle-end: Fix wrong code caused by disagreemed between FRE and access path oracle [PR 92152]

On Wed, 26 Feb 2020, Jan Hubicka wrote: > Hi, > this is and TBAA stat for building cc1 with -flto-partition=none. > > From: > > Alias oracle query stats: > refs_may_alias_p: 46099243 disambiguations, 55677716 queries > ref_maybe_used_by_call_p: 124351 disambiguations, 46883813 queries >

[PATCH] sccvn: Punt on overflows during vn_reference_lookup_3

Hi! I admit I don't have testcases, but I'm afraid very bad things will happen if either the offset2i - offseti or pd.offset + pd.size computations overflow. All are computed in (signed) HOST_WIDE_INT, and at least for the memset or CONSTRUCTOR cases I'd fear the stores could be extremely large.

[PATCH] sccvn: Handle non-byte aligned offset or size for memset (, 123, ) [PR93945]

Hi! The following is the last spot in vn_reference_lookup_3 that didn't allow non-byte aligned offsets or sizes. To be precise, it did allow size that wasn't multiple of byte size and that caused a wrong-code issue on big-endian, as the pr93945.c testcase shows, so for GCC 9 we should add &&

Re: Binaries page modifications

On 27/02/20 08:23 +, CHIGOT, CLEMENT wrote: Hi everyone, I'm one of the owner of the BullFreeware website and I'm seeing that, in https://gcc.gnu.org/install/binaries.html, our website is described for "Bull’s Open Source Software Archive for for AIX 5L and AIX 6;". Would it be possible