> On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote:
> > > On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> > > > Hi,
> > > > this is cleaned up version of the patch. I removed unfinished
> > > > bits,
> > > > fixed
> > > > propagation, cleaned it up and fixed fallout.
> > >
> > > [...]
Hi,
When investigating the issue from
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549786.html
I find the BB COUNTs of loop seems are not accurate in some case.
For example:
In below figure:
COUNT:268435456 pre-header
|
|
Thanks for the review,
On 2020/9/21 16:31, Richard Biener wrote:
+
+static gimple *
+gimple_expand_vec_set_expr (gimple_stmt_iterator *gsi)
+{
+ enum tree_code code;
+ gcall *new_stmt = NULL;
+ gassign *ass_stmt = NULL;
+
+ /* Only consider code == GIMPLE_ASSIGN. */
+ gassign *stmt = dyn_
Power10: Add IEEE 128-bit fp conditional move.
This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max. Unlike the previous patch, I
decided to keep two separate patterns for fpmask before splitting (one pattern
for normal comp
Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.
This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions. The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.
Rather than trying to ov
These patches are my latest versions of the patches to add IEEE 128-bit min,
max, and conditional move to GCC. They correspond to the earlier patches #3
and #4 (patches #1 and #2 have been installed).
The first patch just adds support for the xsmincqp and xsmaxcqp instructions.
Due to the NaN rul
Hi Richard,
on 2020/9/21 下午2:50, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>> "Kewen.Lin" writes:
Hi,
The commit r11-3230 brings a nice improvement to use full
vectors instead of partial vectors when available. But
it caused some vector with length
In case this patch has gotten over-looked, the three patches in the set plus
the explanation are the rewrite of the PCREL_OPT patches. It has been
rewritten to use the data flow machinery as well as validate_change and
apply_change_group from the last patch.
The PCREL_OPT patches can go anywhere
Bin,
I just tested your patch on current trunk. Here is my summary.
1. About some iv aren't moved out of inner loop (Lijia mentioned in his
last email)
[local count: 955630226]:
# l_32 = PHI <1(12), l_54(21)>
# ivtmp_165 = PHI <_446(12), ivtmp_155(21)>
_26 = (integer(kind=8)) l_32;
Power10 pc-relative code doesn't use or preserve r2 as a TOC pointer.
That means calling between pc-relative and TOC using code can't be
done without intervening linker stubs, and a call from TOC code to
pc-relative code must have a nop after the bl in order to restore r2.
Now the PowerPC libffi a
On Mon, Sep 21, 2020 at 03:58:25PM -0500, Qing Zhao wrote:
> > On Sep 21, 2020, at 3:34 PM, Segher Boessenkool
> > wrote:
> > But you cannot *add* anything with this interface, and it cannot return
> > different results depending on which return insn this is. It is not a
> > good abstraction IMO
Calls from split-stack code to non-split-stack code need to expand
mapped stack memory via __morestack. Even tail calls.
__morestack is quite a surprising function on powerpc in that it calls
back to its caller, and a tail call will continue running in the
context of extra mapped stack.
Bootstra
Segher, Will:
Patch 4 adds the vector 128-bit integer shift instruction support for
the V1TI type.
The following changes were made from the previous version.
Renamed VSX_TI to VEC_TI, put def in vector.md. Didn't get it
separated into a different patch.
Reworked the XXSWAPD_V1TI to not use U
Segher, Will:
Add support for converting to/from 128-bit integers and 128-bit
decimal floating point formats.
The updates from the previous version of the patch:
Removed stray ";; carll" comment.
Removed #if 1 and #endif in the test case.
Replaced TARGET_TI_VECTOR_OPS with POWER10.
The pa
Segher, Will:
Patch 1, adds the 128-bit sign extension instruction support and
corresponding builtin support.
No changes from the previous version.
The patch has been tested on
powerpc64le-unknown-linux-gnu (Power 9 LE)
with no regression errors.
Fixed the issues in the ChangeLog noted by
Will, Segher:
Add support for divide, modulo, shift, compare of 128-bit
integers instructions and builtin support.
The following are the changes from the previous version of the patch.
The TARGET_TI_VECTOR_OPS was removed per comments for patch 3. Just
using TARGET_POWER10.
Removed extra com
Segher, Will:
Patch 5 adds the 128-bit integer to/from 128-floating point
conversions. This patch has to invoke the routines to use the 128-bit
hardware instructions if on Power 10 or use software routines if
running on a pre Power 10 system via the resolve function.
Add ifunc resolves for __f
On Mon, Sep 21, 2020 at 10:49:17AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 17, 2020 at 01:12:19PM +0930, Alan Modra wrote:
> > On Wed, Sep 16, 2020 at 07:02:06PM -0500, Segher Boessenkool wrote:
> > > > + /* Test both regs even though the one in the mask is
> > > > +
Hi!
So, I tested this patch. The test builds Linux for all targets, and the
number reported here is just binary size (usually a good indicator for
combine effectiveness). C0 is the unmodified compiler, C1 is with your
patch. A size of 0 means it did not build.
C0C1
On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote:
> > On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> > > Hi,
> > > this is cleaned up version of the patch. I removed unfinished
> > > bits,
> > > fixed
> > > propagation, cleaned it up and fixed fallout.
> >
> > [...]
> >
> > > While
On Mon, 21 Sep 2020 20:38:07 +0300 (MSK)
Alexander Monakov wrote:
> On Mon, 21 Sep 2020, Martin Liška wrote:
>
> > On 9/6/20 1:24 PM, Sergei Trofimovich wrote:
> > > From: Sergei Trofimovich
> > >
> > > Before the change gcc did not stream correctly TOPN counters
> > > if counters belonged t
This patch to the Go frontend finalizes methods for type aliases of
struct types. Previously we would finalize the methods of the alias
type itself, but since its a type alias we really need to finalize the
methods of the aliased type.
This patch also handles method expressions of unnamed struct
Verify that arguments are pointers before calling handling code
that calls deref_rvalue on them.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-3341-g1e19ecd79b45af6df87a6869d1936b857c9f71fc.
gcc/analyzer/ChangeLog:
PR analyzer/97130
* regio
Whilst debugging the remaining state explosion in PR analyzer/93355
I noticed that half of the states at an exploding program point had:
'malloc': {'&buf': 'non-heap'}
whereas the other half didn't, presumably depending on whether the path
to each enode had used this local buffer:
char buf[400]
libstdc++-v3/ChangeLog:
* include/bits/c++config (__replacement_assert): Add noreturn
attribute.
(__glibcxx_assert_impl): Use __builtin_expect to hint that the
assertion is expected to pass.
Tested powerpc64le-linux. Committed to trunk.
commit 7db5967f1050eb2b45e9
libstdc++-v3/ChangeLog:
* include/std/ranges (drop_view::begin()): Adjust constraints
to match the correct condition for O(1) ranges::next (LWG 3482).
* testsuite/std/ranges/adaptors/drop.cc: Check that iterator is
cached for non-sized_range.
Tested powerpc64le-lin
This libgo patch by Clément Chigot recognizes aixbigafMagic archives.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
1b785ecdc817ee14417beb1fd7389622fd8d035f
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index f79a1f04201..d8db888e4b6 100644
This patch to libgo avoids putting golang.org packages in
zstdpkglist.go. This ensures that internal/goroot.IsStandardPackage
does not treat golang.org packages as being in the standard library.
This fixes https://golang.org/issue/41499. Committed to mainline and
GCC 10 branch.
Ian
507f392ade582
On 9/21/20 3:57 PM, Marek Polacek wrote:
DR 1722 clarifies that the conversion function from lambda to pointer to
function should be noexcept(true).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
gcc/cp/ChangeLog:
PR c++/90583
DR 1722
* lambda.c (ma
On 9/21/20 3:57 PM, Marek Polacek wrote:
On Mon, Sep 21, 2020 at 01:04:27AM -0400, Jason Merrill via Gcc-patches wrote:
On 9/19/20 5:34 PM, Marek Polacek wrote:
I noticed that clang++ has this CTAD warning and thought that it might
be useful to have it. From clang++: "Some style guides want to
On 9/19/20 3:49 PM, Patrick Palka wrote:
In the testcase below, the dependent specializations iter_reference_t
and iter_reference_t share the same tree due to specialization
caching. So when find_template_parameters walks through the
requires-expression (as part of normalization), it sees and in
Will, Segher:
The following is the updated patch set for the 128-bit Binary Integer
Operation. I am reposting the entire set for completeness. I have
noted in each patch the changes made since the previous version.
The patches have been tested on Power 8 and Power 9 to ensure there are
no reg
On 21/09/20 15:07 -0400, Patrick Palka via Libstdc++ wrote:
On Mon, 21 Sep 2020, Patrick Palka wrote:
For a span with empty static extent, we currently model the
preconditions of front(), back(), and operator[] as if they were
mandates, by using a static_assert to verify that extent != 0. This
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html
(I'm working on rebasing the patch on top of the latest trunk which
has changed some of the same code but it'd be helpful to get a go-
ahead on substance the changes. I don't expect the rebase to
require any substantive m
From: Joel Sherrill
* config/i386/t-rtems: Change from mtune to march when building
multilibs. The mtune argument tunes or optimizes for a specific
CPU model but does not ensure the generated code is appropriate
for the CPU model. Prior to this patch, i386 compati
The SRA pass relies on the absence of function type attributes
to enable optimization like unused argument elision. The intent
appears to be to avoid messing with the positions of arguments
that may be relied on by some type attributes.
The recent enhancement to detect out-of-bounds accesses by
> On Sep 21, 2020, at 3:34 PM, Segher Boessenkool
> wrote:
>
> On Mon, Sep 21, 2020 at 09:13:58AM -0500, Qing Zhao wrote:
>>> On Sep 18, 2020, at 5:51 PM, Segher Boessenkool
>>> wrote:
B. Will provide a default definition in middle end to generate the
zeroing insn for selected r
On Mon, Sep 21, 2020 at 09:13:58AM -0500, Qing Zhao wrote:
> > On Sep 18, 2020, at 5:51 PM, Segher Boessenkool
> > wrote:
> >> B. Will provide a default definition in middle end to generate the
> >> zeroing insn for selected registers. Then need to add a new target hook
> >> “ZERO_CALL_USED_RE
> On Sep 21, 2020, at 2:22 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Sep 21, 2020, at 2:11 PM, Richard Sandiford
>> wrote:
>>
>> Qing Zhao writes:
But in cases where there is no underlying concept that can sensibly
be extracted out, it's OK if targets need to override
DR 1722 clarifies that the conversion function from lambda to pointer to
function should be noexcept(true).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/90583
DR 1722
* lambda.c (maybe_add_lambda_conv_op): Mark the conversion funct
On Mon, Sep 21, 2020 at 01:04:27AM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/19/20 5:34 PM, Marek Polacek wrote:
> > I noticed that clang++ has this CTAD warning and thought that it might
> > be useful to have it. From clang++: "Some style guides want to allow
> > using CTAD only on types
On Mon, Sep 21, 2020 at 10:41:19AM -0700, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,
>
> 79f4e20dd1280e6a44736070b0d5213f9a8f85d4 is the first bad commit
> commit 79f4e20dd1280e6a44736070b0d5213f9a8f85d4
> Author: Martin Liska
> Date: Wed Sep 2 14:30:16 2020 +0200
>
> Use SIZ
> On Sep 21, 2020, at 2:11 PM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>> But in cases where there is no underlying concept that can sensibly
>>> be extracted out, it's OK if targets need to override the default
>>> to get correct behaviour.
>>
>> Then, on the target that the defa
Qing Zhao writes:
>> But in cases where there is no underlying concept that can sensibly
>> be extracted out, it's OK if targets need to override the default
>> to get correct behaviour.
>
> Then, on the target that the default code is not right, and we haven’t
> provide overridden implementation
On Mon, 21 Sep 2020, Patrick Palka wrote:
> For a span with empty static extent, we currently model the
> preconditions of front(), back(), and operator[] as if they were
> mandates, by using a static_assert to verify that extent != 0. This
> causes us to incorrectly reject valid programs that in
On Mon, Sep 21, 2020 at 12:04 PM Ian Lance Taylor wrote:
>
> Recent changes to libbacktrace have introduced a few more globally
> symbols. These then need to be renamed in the libsanitizer copy.
> This patch does that. Tested by configuring
> --with-build-config=bootstrap-asan and running a boot
Recent changes to libbacktrace have introduced a few more globally
symbols. These then need to be renamed in the libsanitizer copy.
This patch does that. Tested by configuring
--with-build-config=bootstrap-asan and running a bootstrap. Committed
to mainline as obvious.
Ian
* libbacktrace/backt
I've been forced[*] to look at the bits of name-lookup I ran away from
when reimplementing namespace-scope lookup at the beginning of this
modules project. Here's the first change in an expected series.
We don't need ts_lambda, as IDENTIFIER_LAMBDA_P is sufficient. Killed
thusly.
g
For a span with empty static extent, we currently model the
preconditions of front(), back(), and operator[] as if they were
mandates, by using a static_assert to verify that extent != 0. This
causes us to incorrectly reject valid programs that instantiate these
member functions but never call the
On 9/21/20 12:20 PM, Vaseeharan Vinayagamoorthy wrote:
After this patch, I am seeing this -Warray-parameter error:
In file included from ../include/pthread.h:1,
from ../sysdeps/nptl/thread_db.h:25,
from ../nptl/descr.h:32,
from ../sysdeps/aar
Hi,
The symver support is only available to ELF targets.
tested on x86_64-darwin16,
pushed to master
thanks
Iain
gcc/testsuite/ChangeLog:
* gcc.dg/ipa/symver1.c: Skip for Darwin.
---
gcc/testsuite/gcc.dg/ipa/symver1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gc
After this patch, I am seeing this -Warray-parameter error:
In file included from ../include/pthread.h:1,
from ../sysdeps/nptl/thread_db.h:25,
from ../nptl/descr.h:32,
from ../sysdeps/aarch64/nptl/tls.h:44,
from ../include/errno.h
On Linux/x86_64,
79f4e20dd1280e6a44736070b0d5213f9a8f85d4 is the first bad commit
commit 79f4e20dd1280e6a44736070b0d5213f9a8f85d4
Author: Martin Liska
Date: Wed Sep 2 14:30:16 2020 +0200
Use SIZE_AMOUNT macro for GGC memory allocation numbers.
caused
FAIL: g++.dg/ext/timevar2.C -std=gnu
On Linux/x86_64,
79f4e20dd1280e6a44736070b0d5213f9a8f85d4 is the first bad commit
commit 79f4e20dd1280e6a44736070b0d5213f9a8f85d4
Author: Martin Liska
Date: Wed Sep 2 14:30:16 2020 +0200
Use SIZE_AMOUNT macro for GGC memory allocation numbers.
caused
FAIL: g++.dg/ext/timevar2.C -std=gnu
Thanks, I'll apply locally (and sync those changes to the patch I'm
preparing for upstream).
Jonathan Wakely writes:
> On 21/09/20 08:19 -0700, Thomas Rodgers wrote:
>>
>>
>>> On Sep 21, 2020, at 7:40 AM, Jonathan Wakely wrote:
>>>
>>> On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
From:
On Mon, 21 Sep 2020, Martin Liška wrote:
> On 9/6/20 1:24 PM, Sergei Trofimovich wrote:
> > From: Sergei Trofimovich
> >
> > Before the change gcc did not stream correctly TOPN counters
> > if counters belonged to a non-local shared object.
> >
> > As a result zero-section optimization generate
On 18.09.20 13:10, Stefan Schulze Frielinghaus wrote:
> This patch enables a peephole2 optimization which transforms a load of
> constant zero into a temporary register which is then finally used to
> compare against a floating-point register of interest into a single load
> and test instruction.
> On Sep 21, 2020, at 10:35 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> My major concern with the default implementation of the hook is:
>>
>> If a target has some special registers that should not be zeroed, and we do
>> not provide an overridden implementation for this target
On 21/09/20 08:19 -0700, Thomas Rodgers wrote:
On Sep 21, 2020, at 7:40 AM, Jonathan Wakely wrote:
On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
From llvm-project/pstl @ 0b2e0e80d96
libstdc++-v3/ChangeLog:
* include/pstl/algorithm_impl.h: Update file.
On Tue, Sep 15, 2020 at 04:46:08PM +0930, Alan Modra wrote:
> On Tue, Sep 15, 2020 at 10:49:46AM +0930, Alan Modra wrote:
> > Implement more two insn constants.
>
> And tests. rot_cst1 checks the values generated, rot_cst2 checks
> instruction count.
>
> * gcc.target/powerpc/rot_cst.h,
>
These testcases need thumb mode, which may not be the default.
Using dg-add-options arm_arch_v8_1m_main ensures that -mthumb is used
and makes the test pass in more configurations.
2020-09-21 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/csinc-1.c: Use dg-add-options
Hi!
On Thu, Sep 17, 2020 at 01:12:19PM +0930, Alan Modra wrote:
> On Wed, Sep 16, 2020 at 07:02:06PM -0500, Segher Boessenkool wrote:
> > > + /* Test both regs even though the one in the mask is
> > > + constrained to be equal to the output. Increasing
> > > +
Qing Zhao writes:
> My major concern with the default implementation of the hook is:
>
> If a target has some special registers that should not be zeroed, and we do
> not provide an overridden implementation for this target, then the default
> implementation will generate incorrect code for this
> On Sep 21, 2020, at 7:40 AM, Jonathan Wakely wrote:
>
> On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
>> From: Thomas Rodgers
>>
>> From llvm-project/pstl @ 0b2e0e80d96
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/pstl/algorithm_impl.h: Update file.
>> * include/pstl/executio
On 9/20/20 12:39 AM, Aldy Hernandez wrote:
On 9/19/20 11:22 PM, Martin Sebor wrote:
On 9/18/20 12:29 AM, Aldy Hernandez wrote:
On 9/17/20 10:18 PM, Martin Sebor wrote:
On 9/17/20 12:39 PM, Andrew MacLeod wrote:
On 9/17/20 12:08 PM, Martin Sebor via Gcc-patches wrote:
On 9/16/20 9:23 PM,
On 18/09/20 21:08 -0400, Patrick Palka via Libstdc++ wrote:
This fixes a division by zero in the selection-sampling std::__search
overload when the input range is empty (and hence __unsampled_sz is 0).
Tested on x86_64-pc-linux-gnu.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (__
This fixes SLP live lane extraction with pattern stmts.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2020-09-21 Richard Biener
PR tree-optimization/97139
* tree-vect-slp.c (vect_bb_slp_mark_live_stmts): Only mark the
pattern root, track visited vectorized
On 18/09/20 21:08 -0400, Patrick Palka via Libstdc++ wrote:
As per P0202.
Tested on x86_64-pc-linux-gnu.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (for_each_n): Mark constexpr for C++20.
(search): Likewise for the overload that takes a searcher.
* testsuite/25_a
On 21/09/20 10:42 -0400, Glen Fernandes via Libstdc++ wrote:
On Mon, Sep 14, 2020 at 5:44 PM Thomas Rodgers wrote:
> On Sep 14, 2020, at 7:30 AM, Ville Voutilainen wrote:
>
> On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote:
>> Sounds like a good idea. Updated patch attached.
>
> Looks good
On Mon, Sep 14, 2020 at 5:44 PM Thomas Rodgers wrote:
> > On Sep 14, 2020, at 7:30 AM, Ville Voutilainen wrote:
> >
> > On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote:
> >> Sounds like a good idea. Updated patch attached.
> >
> > Looks good to me.
>
> Agree.
Rebased patch on latest changes
On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
From llvm-project/pstl @ 0b2e0e80d96
libstdc++-v3/ChangeLog:
* include/pstl/algorithm_impl.h: Update file.
* include/pstl/execution_impl.h: Likewise.
* include/pstl/glue_algorithm_impl.h: Likewise.
> On Sep 21, 2020, at 2:23 AM, Richard Sandiford
> wrote:
>
> Qing Zhao mailto:qing.z...@oracle.com>> writes:
>> Hi, Richard,
>>
>> During my implementation of the new version of the patch. I still feel that
>> it’s not practical to add a default definition in the middle end to just use
>>
> On Sep 18, 2020, at 5:51 PM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Fri, Sep 18, 2020 at 03:31:12PM -0500, Qing Zhao wrote:
>> Let me know your opinion:
>>
>> A. Will not provide default definition in middle end to generate the
>> zeroing insn for selected registers. Move the gener
On 9/19/20 4:32 PM, Martin Sebor wrote:
On 9/18/20 3:09 PM, Andrew MacLeod wrote:
On 9/18/20 4:35 PM, Martin Sebor wrote:
Do you really need 6 or 10 subranges to find out the answer to the
questions you are looking for? most of the time, 2 or 3 pairs
carries all the information anyone needs a
Ping.
On 03/09/2020 16:29, Andrew Stubbs wrote:
On 28/08/2020 13:04, Andrew Stubbs wrote:
Hi all,
This patch introduces DWARF CFI support for architectures that require
multiple registers to hold pointers, such as the stack pointer, frame
pointer, and return address. The motivating case is t
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553321.html
On 06/09/2020 17.23, Armin Brauns wrote:
> There were some differences between the actual code in do_spec_1, its
> source comment, and the documentation in doc/invoke.texi. These should
> now be resolved.
>
libstdc++-v3/ChangeLog:
* include/std/ranges (transform_view, elements_view): Relax
constraints on operator- for iterators, as per LWG 3483.
* testsuite/std/ranges/adaptors/elements.cc: Check that we
can take the difference of two iterators from a non-random
The cast from void* to T* in std::assume_aligned is not valid in a
constexpr function. The optimization hint is redundant during constant
evaluation anyway (the compiler can see the object and knows its
alignment). Simply return the original pointer without applying the
__builtin_assume_aligned hin
On 9/21/20 3:09 PM, JonY wrote:
On 9/21/20 11:38 AM, Martin Liška wrote:
Sorry, it's not caused by your patch. It's our SUSE-specific package setup.
How does liblto_plugin.so.0.0.0 get loaded? I find only mentions of
liblto_plugin.so.
We make a symlink to bfd-plugins folder.
Is Suse GCC
On Mon, Sep 21, 2020 at 5:54 AM H.J. Lu wrote:
>
> Since "MASKMOVQ mm1, mm2" is an SSE instruction which requires MMX and
> MMX/SSE ISAs are handled separately, make __builtin_ia32_maskmovq require
> MMX instead of SSE.
>
> gcc/
>
> PR target/97140
> * config/i386/i386-expand.c (ix
On 9/21/20 11:38 AM, Martin Liška wrote:
> Sorry, it's not caused by your patch. It's our SUSE-specific package setup.
>
How does liblto_plugin.so.0.0.0 get loaded? I find only mentions of
liblto_plugin.so.
Is Suse GCC patched to use the versioned library?
signature.asc
Description: OpenPGP d
Since "MASKMOVQ mm1, mm2" is an SSE instruction which requires MMX and
MMX/SSE ISAs are handled separately, make __builtin_ia32_maskmovq require
MMX instead of SSE.
gcc/
PR target/97140
* config/i386/i386-expand.c (ix86_expand_builtin): Require MMX
for __builtin_ia32_maskm
On Fri, 18 Sep 2020, Patrick Palka wrote:
> This fixes a division by zero in the selection-sampling std::__search
Whoops, this line say std::__sample, not std::__search.
> overload when the input range is empty (and hence __unsampled_sz is 0).
>
> Tested on x86_64-pc-linux-gnu.
>
> libstdc++-v
Kyrylo Tkachov writes:
> Hi Andrea,
>
>> -Original Message-
>> From: Gcc-patches On Behalf Of
>> Richard Sandiford
>> Sent: 21 September 2020 11:58
>> To: Andrea Corallo
>> Cc: Richard Earnshaw ; nd ;
>> gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] aarch64: Do not alter value on a fo
The following fixes a dependence check where in the particular place
we cannot ignore self-dependences.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2020-09-21 Richard Biener
PR tree-optimization/97135
* tree-ssa-loop-im.c (sm_seq_push_down): Do not ignore
On 9/21/20 1:37 PM, Richard Biener wrote:
Isn't that eventually just because the 'gcc' package looks for
liblto_plugin.so.0.0.0 instead of liblto_plugin.so?
Yes.
Martin
On 9/21/20 1:33 PM, Martin Liška wrote:
On 9/10/20 1:57 PM, JonY via Gcc-patches wrote:
On 9/10/20 9:44 AM, Richard Biener wrote:
I can confirm liblto is still loaded correctly from the logs, likewise
renaming it away will cause an error.
Seems to be fine on Linux.
OK then.
Thanks,
Richard
On Mon, Sep 21, 2020 at 1:33 PM Martin Liška wrote:
>
> On 9/10/20 1:57 PM, JonY via Gcc-patches wrote:
> > On 9/10/20 9:44 AM, Richard Biener wrote:
> >>>
> >>> I can confirm liblto is still loaded correctly from the logs, likewise
> >>> renaming it away will cause an error.
> >>>
> >>> Seems to
On Mon, Sep 21, 2020 at 12:53 PM Martin Liška wrote:
>
> With SVE we can end up with:
> switch (POLY_INT_CST [2, 2]) [INV], case 2: [INV], case
> 4: [INV]>
> which is fine to expand and we can remove the assert.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
On 9/10/20 1:57 PM, JonY via Gcc-patches wrote:
On 9/10/20 9:44 AM, Richard Biener wrote:
I can confirm liblto is still loaded correctly from the logs, likewise
renaming it away will cause an error.
Seems to be fine on Linux.
OK then.
Thanks,
Richard.
Thanks for reviewing, pushed to mast
On 9/6/20 1:24 PM, Sergei Trofimovich wrote:
From: Sergei Trofimovich
Before the change gcc did not stream correctly TOPN counters
if counters belonged to a non-local shared object.
As a result zero-section optimization generated TOPN sections
in a form not recognizable by '__gcov_merge_topn'.
Hi Andrea,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Richard Sandiford
> Sent: 21 September 2020 11:58
> To: Andrea Corallo
> Cc: Richard Earnshaw ; nd ;
> gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: Do not alter value on a force_reg returned rtx
> expanding __j
Andrea Corallo writes:
> Hi all,
>
> From the `force_reg` description comment I see the returned register
> should not be modified, thus IIUC should not be used as a GEN_FCN
> target.
>
> Assuming my interpretation is correct this fix this case inside
> `aarch64_general_expand_builtin` while expan
With SVE we can end up with:
switch (POLY_INT_CST [2, 2]) [INV], case 2: [INV], case 4:
[INV]>
which is fine to expand and we can remove the assert.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR tree-optimization/96915
* tree-switch-conversion.c (switch_conversion:
Installing as obvious.
Before:
(gdb) p debug_tree(m_index_expr)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x775ec7e0
precision:64 min max
pointer_to_this >
constant
elt0:
constant 2> elt1: >
After:
(gdb) p debug_tr
Hi all,
>From the `force_reg` description comment I see the returned register
should not be modified, thus IIUC should not be used as a GEN_FCN
target.
Assuming my interpretation is correct this fix this case inside
`aarch64_general_expand_builtin` while expanding expanding the
`__jcvt` intrinsic
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/avx-vandnpd-1.c execution test
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/avx-vandnps-1.c execution test
PING^1
On 9/2/20 1:53 PM, Martin Liška wrote:
On 9/1/20 4:50 PM, David Malcolm wrote:
Hope this is constructive
Dave
Thank you David. All of them very very useful!
There's updated version of the patch.
Martin
Richard Sandiford writes:
> Richard Sandiford writes:
>>> @@ -2034,6 +2034,18 @@ aarch64_expand_fpsr_fpcr_setter (int unspec,
>>> machine_mode mode, tree exp)
>>>emit_insn (gen_aarch64_set (unspec, mode, op));
>>> }
>>>
>>> +/* Expand a fpsr or fpcr getter (depending on UNSPEC) using MOD
1 - 100 of 115 matches
Mail list logo
