When adding new features to I included the required headers
adjacent to the new code. This cleans it up by moving all the includes
to the start of the file.
libstdc++-v3/ChangeLog:
* include/std/numeric: Move all #include directives to the top
of the header.
*
On 06/10/20 00:25 +0100, Jonathan Wakely wrote:
I'm sorry it's taken a year to review this properly. Comments below ...
On 27/09/19 14:18 -0400, Daniel Lemire wrote:
(This is a revised patch proposal. I am revising both the description
and the code itself.)
Even on recent processors, integer
I was notified that our P0634R3 (Down with typename) implementation has
a flaw: when we have an out-of-class member function definition, we
still required 'typename' for its parameters. For example here:
template struct S {
int simple(T::type);
};
template
int S::simple(/* typename
I'm sorry it's taken a year to review this properly. Comments below ...
On 27/09/19 14:18 -0400, Daniel Lemire wrote:
(This is a revised patch proposal. I am revising both the description
and the code itself.)
Even on recent processors, integer division is relatively expensive.
The current
From: Thomas Rodgers
This *should* be the correct patch this time.
Add support for -
* atomic_flag::wait/notify_one/notify_all
* atomic::wait/notify_one/notify_all
* counting_semaphore
* binary_semaphore
* latch
libstdc++-v3/ChangeLog:
* include/Makefile.am (bits_headers):
On 06/10/20 00:25 +0100, Jonathan Wakely wrote:
I'm sorry it's taken a year to review this properly. Comments below ...
On 27/09/19 14:18 -0400, Daniel Lemire wrote:
(This is a revised patch proposal. I am revising both the description
and the code itself.)
Even on recent processors, integer
On 10/5/20 4:16 PM, Martin Sebor wrote:
On 10/5/20 8:50 AM, Aldy Hernandez via Gcc-patches wrote:
[Martin, as the original author of this pass, do you have any concerns?]
@@ -1270,7 +1271,21 @@ get_size_range (tree exp, tree range[2], bool
allow_zero /* = false */)
enum
This avoids unnecessary instantiations of std::numeric_limits or
inclusion of when a more lightweight alternative would work.
Some uses can be replaced with __gnu_cxx::__int_traits and some can just
use size_t(-1) directly where SIZE_MAX is needed.
libstdc++-v3/ChangeLog:
*
This Go frontend patch by Nikhil Benesch fixes the file reading logic
in the Stream_from_file class. That class is almost never used, and I
guess nobody noticed these problems. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
This is a first step towards enabling the sincos optimization in Ada.
The issue this patch solves is that sincos takes the type to be looked
up with mathfn_built_in from variables or temporaries in which results
of sin and cos are stored. In Ada, sin and cos are declared in an
internal aux
> The 10/05/2020 17:28, Szabolcs Nagy via Gcc-patches wrote:
> > The 10/05/2020 12:52, Vaseeharan Vinayagamoorthy wrote:
> > > Hi,
> > >
> > > After this patch, I am noticing that some glibc crypto tests get stuck in
> > > scanf which goes into busy loop.
> > >
> > > My build/host/target setup
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* cp-tree.h (NON_UNION_CLASS_TYPE_P): Fix typo in a comment.
---
gcc/cp/cp-tree.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index c9ad75117ad..c7b5e7915ae
This work-in-progress patch generalizes the malloc/free problem-checking
in -fanalyzer so that it can work on arbitrary acquire/release API pairs.
It adds a new __attribute__((deallocated_by(FOO))) that could be used
like this in a library header:
struct foo;
extern void foo_release (struct
On Mon, Oct 5, 2020 at 9:09 AM Martin Liška wrote:
>
> The previous patch was not correct. This one should be.
>
> Ready for master?
I don't understand why this code uses symtab_indices_shndx at all.
There should only be one SHT_SYMTAB_SHNDX section. There shouldn't be
any need for the
Will, Segher:
Patch 1, adds the 128-bit sign extension instruction support and
corresponding builtin support.
I updated the change log per the comments from Will.
Patch has been retested on Power 9 LE.
Pet me know if it is ready to commit to mainline.
Carl
On 10/5/20 8:50 AM, Aldy Hernandez via Gcc-patches wrote:
[Martin, as the original author of this pass, do you have any concerns?]
No concerns, just a few minor things.
This patch converts the -Wrestrict pass to use an on-demand ranger
instead of global ranges.
No effort was made to
On 10/5/20 11:51 AM, Aldy Hernandez wrote:
More changes from the ranger branch that been tested and retested,
including a full Fedora build.
These are cleanups so that multi-range union/intersect doesn't have to
deal with legacy code. Instead, these should be done in legacy mode.
OK
The 10/05/2020 12:52, Vaseeharan Vinayagamoorthy wrote:
> Hi,
>
> After this patch, I am noticing that some glibc crypto tests get stuck in
> scanf which goes into busy loop.
>
> My build/host/target setup is:
> Build: aarch64-none-linux-gnu
> Host: aarch64-none-linux-gnu
> Target:
The implementation of the functions __absv?i2(), __addv?i3() etc. for
trapping integer overflow provided in libgcc2.c is rather bad.
Same for __cmp?i2() and __ucmp?i2()
At least for AMD64 and i386 processors GCC creates awful to horrible
code for them: see
Will, Segher:
Patch 4 adds the vector 128-bit integer shift instruction support for
the V1TI type.
The changes from the previous version include:
Fixed up the change log entry issues noted by Will.
Regression tests reran on Power 9 LE with no regression errors.
Please let me know if it looks
Will and Segher:
This is the rest of the second patch which adds the 128-bit integer
support for divide, modulo, shift, compare of 128-bit
integers instructions and builtin support.
In the last round of changes, the flag for the 128-bit operations was
removed. Per Will's comments, the
Will, Segher:
This patch adds support for converting to/from 128-bit integers and
128-bit decimal floating point formats using the new P10 instructions
dcffixqq and dctfixqq. The new instructions are only used on P10 HW,
otherwise the conversions continue to use the existing SW routines.
The
Will, Segher:
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:
Just a fix for the change log per Will's comments.
No regression failures were found when run on a P9.
Please let me know if this
Will, Segher:
The following changes were made from the previous version:
Per Will's comments, I split the bug fix from patch 2 into a separate
patch. This patch is the bug fix for the vec_rlnm builtin.
Regression tests reran on Power 9 LE with no regression errors.
Please let me know if it
On Wed, 30 Sep 2020, Jason Merrill wrote:
> On 9/29/20 5:01 PM, Patrick Palka wrote:
> > This patch fixes an "unguarded" call to coerce_template_parms in
> > build_standard_check: processing_template_decl could be zero if we
> > we get here during processing of the first 'auto' parameter of an
>
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554893.html
On 9/25/20 12:58 PM, Martin Sebor wrote:
The C and C++ representations of zero-length arrays are different:
C uses a null upper bound of the type's domain while C++ uses
SIZE_MAX. This makes the middle end logic more
On 10/5/20 3:51 AM, Aldy Hernandez via Gcc-patches wrote:
The walloca pass is a mess. It has all sorts of heuristics to divine
problematic ranges fed into alloca, none of them very good, and all of
them unreadable. The mess therein was actually one of the original
motivators for the ranger
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555019.html
On 9/28/20 4:01 PM, Martin Sebor wrote:
On 9/25/20 11:17 PM, Jason Merrill wrote:
On 9/22/20 4:05 PM, Martin Sebor wrote:
The rebased and retested patches are attached.
On 9/21/20 3:17 PM, Martin Sebor wrote:
Ping:
On Mon, 5 Oct 2020 at 01:15, Ville Voutilainen
wrote:
> The patch is borked, doesn't pass tests, fixing...
Unborked, ok for trunk if full testsuite passes?
2020-10-05 Ville Voutilainen
PR libstdc++/95904
* include/std/variant (__deduce_visit_result): Add a nested ::type.
Hi.
The previous patch was not correct. This one should be.
Ready for master?
Thanks,
Martin
>From a96f7ae39b5d56ce886edf1bfb9ca6475a857652 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 5 Oct 2020 18:03:08 +0200
Subject: [PATCH] lto: fix LTO debug sections copying.
MIME-Version: 1.0
On Sun, 4 Oct 2020, H.J. Lu via Gcc-patches wrote:
> This email is generated by an automated script. Does GCC BZ have
> an email gateway?
Bugzilla has a REST API that you can use to interact with it via JSON
messages over HTTP. contrib/mark_spam.py has an example to mark bugs as
spam.
The 10/05/2020 17:28, Szabolcs Nagy via Gcc-patches wrote:
> The 10/05/2020 12:52, Vaseeharan Vinayagamoorthy wrote:
> > Hi,
> >
> > After this patch, I am noticing that some glibc crypto tests get stuck in
> > scanf which goes into busy loop.
> >
> > My build/host/target setup is:
> > Build:
Hi Segher,
> On 3 Oct 2020, at 00:43, Segher Boessenkool
> wrote:
>
> Hi Olivier,
>
> On Thu, Oct 01, 2020 at 11:30:55AM +0200, Olivier Hainque wrote:
>> This change reworks CPP_BUILTINS_SPEC for powerpc-vxworks to
>> prepare for the upcoming addition of 32 and 64 bit ports for
>> VxWorks
Ping?
Tulio Magno Quites Machado Filho via Gcc-patches
writes:
> Replace them with a whitespace in order to avoid artifacts in the HTML
> document.
>
> 2020-08-19 Tulio Magno Quites Machado Filho
>
> gcc/
> * doc/extend.texi (PowerPC Built-in Functions): Replace
> extraneous
On October 6, 2020 3:15:02 AM GMT+02:00, Alexandre Oliva
wrote:
>
>This is a first step towards enabling the sincos optimization in Ada.
>
>The issue this patch solves is that sincos takes the type to be looked
>up with mathfn_built_in from variables or temporaries in which results
>of sin and
On 10/1/20 1:08 PM, Marek Polacek wrote:
This PR points out that when we're invoking a non-static member function
on a null instance during constant evaluation, we should reject.
cxx_eval_call_expression calls cxx_bind_parameters_in_call which
evaluates function arguments, but it won't detect
I thought LWG approved the other option in the PR (changing views::join to
not use CTAD)?
On Mon, Aug 24, 2020 at 10:22 AM Jonathan Wakely via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> This implements the proposed resolution for LWG 3474.
>
> libstdc++-v3/ChangeLog:
>
> *
[ was: Re: [PATCH][omp, ftracer] Don't duplicate blocks in SIMT region ]
On 10/5/20 9:05 AM, Tom de Vries wrote:
> Ack, updated the patch accordingly, and split it up in two bits, one
> that does refactoring, and one that adds the actual caching:
> - [ftracer] Factor out can_duplicate_bb_p
> -
On 9/22/20 6:38 PM, Tom de Vries wrote:
> [ was: Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB
> with SIMT LANE [PR95654] ]
>
> On 9/16/20 8:20 PM, Alexander Monakov wrote:
>>
>>
>> On Wed, 16 Sep 2020, Tom de Vries wrote:
>>
>>> [ cc-ing author omp support for nvptx. ]
>>
>> The
On 9/24/20 2:44 PM, Richard Biener wrote:
> On Thu, 24 Sep 2020, Tom de Vries wrote:
>
>> On 9/24/20 1:42 PM, Richard Biener wrote:
>>> On Wed, 23 Sep 2020, Tom de Vries wrote:
>>>
On 9/23/20 9:28 AM, Richard Biener wrote:
> On Tue, 22 Sep 2020, Tom de Vries wrote:
>
>> [ was:
* Paul Eggert:
> On 10/2/20 12:01 PM, Alejandro Colomar wrote:
>> If you propose not to document the stdint types either,
>
> This is not a stdint.h issue. __int128 is not in stdint.h and is not a
> system data type in any real sense; it's purely a compiler
> issue. Besides, do we start repeating
On October 5, 2020 9:08:41 AM GMT+02:00, Jakub Jelinek wrote:
>On Sun, Oct 04, 2020 at 09:16:00PM +0200, Jakub Jelinek via Gcc-patches
>wrote:
>> On Sun, Oct 04, 2020 at 09:13:29AM +0200, Andreas Schwab wrote:
>> > This breaks ia64:
>> >
>> > In file included from ./tm.h:23,
>> >
On Sun, Oct 04, 2020 at 09:16:00PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Sun, Oct 04, 2020 at 09:13:29AM +0200, Andreas Schwab wrote:
> > This breaks ia64:
> >
> > In file included from ./tm.h:23,
> > from ../../gcc/gencheck.c:23:
> > ./options.h:7816:40: error: ISO
[ was: Re: [PATCH][omp, ftracer] Don't duplicate blocks in SIMT region ]
On 10/5/20 9:05 AM, Tom de Vries wrote:
> Ack, updated the patch accordingly, and split it up in two bits, one
> that does refactoring, and one that adds the actual caching:
> - [ftracer] Factor out can_duplicate_bb_p
> -
Hi!
I've noticed a -Wnarrowing warning on gimple-ssa-store-merging.c, this
change fixes that up.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2020-10-05 Jakub Jelinek
* gimple-ssa-store-merging.c
The 09/23/2020 21:45, Jeff Law wrote:
> On 9/23/20 11:45 AM, Martin Sebor via Gcc-patches wrote:
> > On 9/23/20 9:44 AM, Szabolcs Nagy wrote:
> > > The 09/23/2020 09:22, Szabolcs Nagy wrote:
> > > > The 09/21/2020 12:45, Martin Sebor via Gcc-patches wrote:
> > > > > On 9/21/20 12:20 PM, Vaseeharan
On Mon, 5 Oct 2020, Tom de Vries wrote:
> I've had to modify this patch in two ways:
> - the original test-case stopped failing, though not the
> minimized one, so I added that one as a test-case
> - only testing for ENTER_ALLOC and EXIT, and not explicitly for VOTE_ANY
> in ignore_bb_p also
ping.
On Fri, Sep 25, 2020 at 2:33 PM Richard Biener wrote:
> On Fri, 25 Sep 2020, Kito Cheng wrote:
>
> > In g:70cdb21e579191fe9f0f1d45e328908e59c0179e, DECL/global variable has
> handled
> > misaligned stores, but it didn't handle PARALLEL values, and I refer the
> > other part of this
On Fri, 2 Oct 2020 at 10:37, Jan Hubicka wrote:
>
> Hi,
> this patch implements tracking of access ranges. This is only applied when
> base pointer is an arugment. Incrementally i will extend it to also track
> TBAA basetype so we can disambiguate ranges for accesses to same basetype
> (which
The walloca pass is a mess. It has all sorts of heuristics to divine
problematic ranges fed into alloca, none of them very good, and all of
them unreadable. The mess therein was actually one of the original
motivators for the ranger project (along with array bounds checking).
The attached
On Mon, Sep 14, 2020 at 11:47:56AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 14, 2020 at 11:02:26AM +0200, Jan Hubicka wrote:
> > Especially for the new param machinery, most of streamed values are
> > probably going to be the default values. Perhaps somehow we could
> > stream
Hi!
I'd like to ping a few patches:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552451.html
- allow plugins to deal with global_options layout changes
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553420.html
- --enable-link-serialization{,=N} support
On Thu, 1 Oct 2020 at 16:10, Richard Sandiford via Gcc-patches
wrote:
>
> This patch does several things at once:
>
> (1) Add vector compare patterns (vec_cmp and vec_cmpu).
>
> (2) Add vector selects between floating-point modes when the
> values being compared are integers (affects vcond
- Disable kasan if target is unsupported and -fasan-shadow-offset= is not
given, no matter `--param asan-stack=1` is given or not.
- Moving KASAN option checking testcase to gcc.dg, those testcase could be
useful for all other target which not support asan.
- Verifed on riscv and x86.
On Fri, 2 Oct 2020 at 20:23, Nathan Sidwell wrote:
>
>
> For 'no such binding' errors, we iterate over binding levels to find a
> close match. At the namespace level we were using DECL_ANTICIPATED to
> skip undeclared builtins. But (a) there are other unnameable things
> there and (b)
On Mon, Oct 05, 2020 at 11:48:32AM +0200, Christophe Lyon via Gcc-patches wrote:
> > For 'no such binding' errors, we iterate over binding levels to find a
> > close match. At the namespace level we were using DECL_ANTICIPATED to
> > skip undeclared builtins. But (a) there are other unnameable
__arm_vcvtnq_u32_f32 was missing from arm_mve.h, although the s32_f32 and
[su]16_f16 versions were present.
This patch adds the missing version and testcase, which are
cut-and-paste from the other versions.
2020-10-05 Christophe Lyon
gcc/
* config/arm/arm_mve.h
Ping.
On 21/09/2020 14:51, Andrew Stubbs wrote:
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
On 19/09/20 11:50 +0100, Mike Crowe wrote:
On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote:
> > diff --git a/libstdc++-v3/include/bits/atomic_futex.h
b/libstdc++-v3/include/bits/atomic_futex.h
> > index 5f95ade..aa137a7 100644
> > --- a/libstdc++-v3/include/bits/atomic_futex.h
> > +++
On 19/09/20 11:37 +0100, Mike Crowe wrote:
On Friday 11 September 2020 at 19:59:36 +0100, Jonathan Wakely wrote:
commit 53ad6b1979f4bd7121e977c4a44151b14d8a0147
Author: Jonathan Wakely
Date: Fri Sep 11 19:59:11 2020
libstdc++: Fix chrono::__detail::ceil to work with C++11
In C++11
On 10/5/20 5:09 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
I'd like to ping a few patches:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554845.html
- PR97197 - support TARGET_MEM_REF in C/C++ error pretty-printing
ok, but could you add a comment on what it's printing out.
On Tue, Sep 22, 2020 at 02:59:30PM +0200, Andreas Krebbel wrote:
> On 15.09.20 17:02, Stefan Schulze Frielinghaus wrote:
> > Over the last couple of months quite a few warnings about uninitialized
> > variables were raised while building GCC. A reason why these warnings
> > show up on S/390 only
This patch adds:
vqdmlashq_m_n_s16
vqdmlashq_m_n_s32
vqdmlashq_m_n_s8
vqdmlashq_n_s16
vqdmlashq_n_s32
vqdmlashq_n_s8
2020-10-05 Christophe Lyon
gcc/
* config/arm/arm_mve.h (vqdmlashq, vqdmlashq_m): Define.
* config/arm/arm_mve_builtins.def (vqdmlashq_n_s,
[ was: Re: [PATCH][omp, ftracer] Don't duplicate blocks in SIMT region ]
On 10/5/20 10:51 AM, Alexander Monakov wrote:
>> + The IFN_GOMP_SIMT_VOTE_ANY is currently part of such a group,
>> + so the same holds there, but it could be argued that the
>> + IFN_GOMP_SIMT_VOTE_ANY could be
On 10/5/20 8:09 AM, Jakub Jelinek wrote:
On Fri, Oct 02, 2020 at 12:59:54PM -0400, Andrew MacLeod via Gcc-patches wrote:
The ranger is needed to map those values to the switch variable, and also
apply any previous ranges or derived values (ie, if you ask for the range of
'y' in case 2, it will
On 2/7/20 4:29 PM, Jakub Jelinek wrote:
> On Fri, Feb 07, 2020 at 09:56:38AM +0100, Harwath, Frederik wrote:
>> * {target-32.c, thread-limit-2.c}:
>> no "usleep" implemented for nvptx. Cf. https://gcc.gnu.org/PR81690
>
> Please don't, I want to deal with that using declare variant, just didn't
>
On 10/5/20 5:48 AM, Christophe Lyon wrote:
On Fri, 2 Oct 2020 at 20:23, Nathan Sidwell wrote:
Hi Nathan,
This is causing regressions on aarch64 and arm when using
-mfloat-abi=hard (or configuring for arm-linux-gnueabihf).
The logs says:
FAIL: c-c++-common/spellcheck-reserved.c
Hi,
After this patch, I am noticing that some glibc crypto tests get stuck in scanf
which goes into busy loop.
My build/host/target setup is:
Build: aarch64-none-linux-gnu
Host: aarch64-none-linux-gnu
Target: aarch64-none-linux-gnu
Kind regards
Vasee
On 27/09/2020, 22:46, "Gcc-patches on
On Fri, Oct 02, 2020 at 12:59:54PM -0400, Andrew MacLeod via Gcc-patches wrote:
>
> The ranger is needed to map those values to the switch variable, and also
> apply any previous ranges or derived values (ie, if you ask for the range of
> 'y' in case 2, it will return unsigned int [6,6].
>
>
[ was: Re: [PATCH][omp, ftracer] Don't duplicate blocks in SIMT region ]
On 10/5/20 10:51 AM, Alexander Monakov wrote:
>> + if (is_gimple_call (g)
>> + && (gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
>> + || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
>> +
[Martin, as the original author of this pass, do you have any concerns?]
This patch converts the -Wrestrict pass to use an on-demand ranger
instead of global ranges.
No effort was made to convert value_range's into multi-ranges.
Basically, the places that were using value_range's, and
My change to namespace-scope spell corrections ignored the issue that
different targets might have different builtins, and therefore perturb
iteration order. This fixes it by using an intermediate array of
identifier, which we sort before considering.
gcc/cp/
* name-lookup.c
On Mon, Oct 05, 2020 at 09:39:01AM -0400, Nathan Sidwell wrote:
> My change to namespace-scope spell corrections ignored the issue that
> different targets might have different builtins, and therefore perturb
> iteration order. This fixes it by using an intermediate array of
> identifier,
[ was: Re: [PATCH][omp, ftracer] Don't duplicate blocks in SIMT region ]
On 10/5/20 10:51 AM, Alexander Monakov wrote:
> On Mon, 5 Oct 2020, Tom de Vries wrote:
>
>> I've had to modify this patch in two ways:
>> - the original test-case stopped failing, though not the
>> minimized one, so I
Not exactly a patch ping, but I was hoping we could re-engage the discussion on
this and figure out how we can make POImode work for powerpc.
How does x86 solve this? There was some suggestion that it has some similar
situations?
Thanks,
Aaron Sawdey, Ph.D. saw...@linux.ibm.com
IBM Linux
std::allocator and std::pmr::polymorphic_allocator should throw
std::bad_array_new_length from their allocate member functions if the
number of bytes required cannot be represented in std::size_t.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver: Add new symbol.
*
Hi!
On Sun, Oct 04, 2020 at 11:09:11PM +1030, Alan Modra wrote:
> On Fri, Oct 02, 2020 at 01:50:24PM -0500, Segher Boessenkool wrote:
> > > + /* If reg parm stack space increases, we cannot sibcall. */
> > > + if (REG_PARM_STACK_SPACE (decl ? decl : fntype)
> > > + > REG_PARM_STACK_SPACE
On Sun, Oct 04, 2020 at 09:51:23AM -0700, H.J. Lu wrote:
> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> wrote:
> > On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
> > wrote:
> > > On Linux/x86_64,
> > >
> > > c34db4b6f8a5d80367c709309f9b00cb32630054 is the first
This patch imports three fixes from the ranger branch:
1. Fold division by zero into varying instead of undefined.
This provides compatibility with existing stuff on trunk.
2. Solver changes for lshift and rshift.
This should not affect anything on trunk, as it only involves
the GORI solver
As seen in the PR, we get to situation where we have a big number
of symbols (~125K) and thus we reach .symtab_shndx section usage.
For .symtab we get the following sh_link:
(gdb) p strtab
$1 = 81997
readelf -S prints:
There are 81999 section headers, starting at offset 0x1f488060:
Section
On 10/5/20 11:19 AM, Aldy Hernandez wrote:
This patch imports three fixes from the ranger branch:
1. Fold division by zero into varying instead of undefined.
This provides compatibility with existing stuff on trunk.
2. Solver changes for lshift and rshift.
This should not affect anything on
Adding Ian (and Richi) to CC.
On 10/5/20 5:20 PM, Martin Liška wrote:
As seen in the PR, we get to situation where we have a big number
of symbols (~125K) and thus we reach .symtab_shndx section usage.
For .symtab we get the following sh_link:
(gdb) p strtab
$1 = 81997
readelf -S prints:
And now with changelog entry :).
gcc/ChangeLog:
* range-op.cc (operator_div::wi_fold): Return varying for
division by zero.
(class operator_rshift): Move class up.
(operator_abs::wi_fold): Return [-MIN,-MIN] for ABS([-MIN,-MIN]).
(operator_tests): Adjust
On Mon, 2020-10-05 at 11:51 +0200, Aldy Hernandez via Gcc-patches
wrote:
> The walloca pass is a mess. It has all sorts of heuristics to
> divine
> problematic ranges fed into alloca, none of them very good, and all
> of
> them unreadable. The mess therein was actually one of the original
>
Hi!
On Sun, Oct 04, 2020 at 09:56:01PM -0400, Hans-Peter Nilsson wrote:
> Please excuse a comment from the gallery:
>
> On Mon, 28 Sep 2020, will schmidt via Gcc-patches wrote:
> > On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches
> > wrote:
> > > +(define_expand
On 10/5/20 10:17 AM, Jakub Jelinek wrote:
On Mon, Oct 05, 2020 at 09:39:01AM -0400, Nathan Sidwell wrote:
My change to namespace-scope spell corrections ignored the issue that
different targets might have different builtins, and therefore perturb
iteration order. This fixes it by using an
On 10/5/20 11:28 AM, David Malcolm via Gcc-patches wrote:
On Mon, 2020-10-05 at 11:51 +0200, Aldy Hernandez via Gcc-patches
wrote:
The walloca pass is a mess. It has all sorts of heuristics to
divine
problematic ranges fed into alloca, none of them very good, and all
of
them unreadable. The
More changes from the ranger branch that been tested and retested,
including a full Fedora build.
These are cleanups so that multi-range union/intersect doesn't have to
deal with legacy code. Instead, these should be done in legacy mode.
OK pending new tests against trunk?
gcc/ChangeLog:
88 matches
Mail list logo
